久しぶりに参加のDevelopers Summitは、開発生産性カンファレンスと同じ会場。ちょっと狭いけど駅から近いのが良い。 https://event.shoeisha.jp/devsumi/20250717
参加証印刷してなかったから早めに行ったら早く着きすぎた。
開発生産性カンファレンスの時も思ったけど、ホール内の空調が効きすぎて寒い。
仕組みから学ぶLLMエージェント開発の勘所──基礎理解と実践開発手法
AIエージェントはソフトウェア技術者を置き換える？
熟練者の生産性は低下？
- 特定の条件に限られる
置き換えられるのはソフトウェア技術者だけではない
- あらゆるものに及んでいく
AIエージェントとは
- LLM＋ツール
- 例）LLMは計算が苦手なので計算用のツールと組み合わせる、など
Vibe Coding
- コーディングは人手からAIエージェントへ
AIエージェントの特徴
- 間違えることがある
- 一番良い答えとは限らない
- →教えてあげる必要がある
- フィードバックを反映できる
アジャイル開発とのマッピング
- 人間はプロダクトオーナー一人でも回せる
エキスパートvs初心者の対比
- エキスパートが指示出ししたほうがより良い成果物により早く到達できる
これからのソフトウェア開発に必要な力
- AIエージェントを導く力
- 仕組みの理解
- AIエージェント
- LLM
- 計算機科学
- 仕組みの理解
- ドメイン知識
- プロジェクトマネジメント
- AIエージェントを導く力
AIエージェントの仕組み
- ツールを駆使して与えられたタスクを解決
- ReAct（Reasoning+Action）が基本
ReAct
- Reasonting→Action→Observaionの反復ループ
- LLMが思考を言語化しながら外部ツールを呼び出し、得られた観察結果を次の思考へフィードバック
ツール/関数呼出しAPI
- ReActのAPI化
Vibe Codingエージェントのツール例
- タスク例
- コード中の2038年問題を解消する
- 必要なツール
- セマンティック検索ツール
- 引数：クエリ、最大返却数
- 戻り値：マッチ配列
- ファイル名、開始行、最終行、スコア
- ファイル読み出しツール
- ファイル書き込みツール
- シンボル参照ツール
- セマンティック検索ツール
- タスク例
エージェント実装のベストプラクティス
- 計画を立てる
- Plannerがタスクをサブゴールに分割
- 計画を実行する
- 各サブゴールをReActで実行
- 計画を振り返る
- 成果物を検証、ミス発覚時は再試行
- 計画を立てる
数学者の解き方と同じ
エージェント作成のヒント
- エージェントを用いたコード最適化
- ルールベース以外にアルゴリズム自体を変更する最適化もできる
- 正しい結果が得られるとは限らない
- 検証を利用する
- 検証自体もLLMに作成させ、フィードバックする
- エージェントを用いたコード最適化
実験結果
- 競技プログラミングの問題を最適化
- 18%で人手による最速のコードより速くなっている
- 競技プログラミングの問題を最適化
エージェント開発の勘所
- AIは間違える
- AIの答えは最善とは限らない
- フィードバックを与えることで改善
- エージェントに与えるツール
- 改善につながるフィードバックを出力とする
エン・ジャパン株式会社事例ご登壇 - Tricentis Testimによる継続的テストの実践
困りごと
- 自動化スクリプトの作成が追いつかない
- UI変更が頻繁に起こる
- テスト環境を準備するのに時間がかかる
導入した効果
- 別E2Eテストツールを利用していた
- 契約面、機能面、運用面での課題
- ポイント
- ローコード、豊富な機能、実行環境、費用対効果
- 導入効果
- 実行回数３倍、カバレッジ70%+、テスト時間-50%、運用コスト-50%
- 予想外の恩恵
- ユーザー増加、心理的ハードルの低下、社内認知の向上
- 改善してほしいところ
- ローカライズ、GUIアクション拡充、UI/UX改善、AIエージェント機能
- 別E2Eテストツールを利用していた
30年間続いたレガシープロダクトをクラウドネイティブに生まれ変わらせるには？
なぜクラウドネイティブ化しなければいけないのか
- クラウドネイティブ化したくてする組織はない
- 目的
- 新技術への対応
- 柔軟にシステムをアップデートしたい
- 運用
- インフラレベルの問題をクラウドベンダーに任せたい
- 人材確保
- 市場にエンジニアが多い技術を採用して人材の確保を容易にしたい
- 新技術への対応
- 目的
- クラウドネイティブ化したくてする組織はない
クラウドネイティブのための壁
- 技術的課題
- 開発部門が技術的専門性で検討する課題
- 組織的課題
- 社内全体が体制的に対応する課題
- 契約的課題
- クラウドベンダー側との契約上の課題
- 技術的課題
いかにしてクラウドネイティブ化したか
- 技術的課題
- ベンダーのサービスをフル活用
- 早い、ベンダーロックイン
- コンテナオーケストレーションに対応
- 移植性が高い←重視
- ベンダーのサービスをフル活用
- ベストプラクティスとの付き合い方
- そのまま移行してからベストプラクティスに寄せる
- 短期間、技術的負債が残る
- MVPをベストプラクティスで再構築して絵優先度の高い機能を順次実装
- 長期間、柔軟な方向転換→途中で新サービス、新機能が出ることがあるのでそれに対応できる
- 技術的負債が残らない方を採用
- マーケットプレイスを使う場合、ベストプラクティスの審査もある
- そのまま移行してからベストプラクティスに寄せる
- 組織的課題
- コミュニケーションコストは軽視してはいけない
- 契約的課題
- 早めにやってみて気軽に問い合わせる
- 技術的課題
「LANSCOPE」の運用における脆弱性対策：自社診断を活用した実践事例
写真撮影禁止
予測が難しい時代こそ、組織全体でセキュリティを維持向上する
Renovaate：アプリ依存ライブラリの検出
DMMを支える決済基盤の技術的負債にどう立ち向かうか
決済基盤の状態
- 複数の支払手段
- 2013年から現在のコードベース
- マイクロサービス
- 各システムは異なる言語、異なる実行環境、異なるCI/CD
取り組み方
as-isからto-beを得て差分から課題を抽出
- システムのアーキテクチャに注目
- ビューポイントとパースペクティブ
- C4モデル
- コンテキスト、コンテナ、コンポーネント、コード
- as-isの時点ではコードはモデル化しない
- 抽象度を統一して記述する
- コンテキスト、コンテナ、コンポーネント、コード
- as-isをもとにステークホルダーと対話、to-beとなる情報を集める
- 発散と収束を繰り返す
to-beを実現するとどうなるのか
- 期待値を言語化しておく
- 指標につながる
- 期待値を言語化しておく
課題と打ち手
- 課題は多い
- 一気に解決することはできない
- 段階的に解決していく戦略（EBM）が必要
- エビデンスベースドマネジメント？
戦略的ゴール（長期的）
- システムのモダナイゼーション
- 運用体制の強化
中間ゴール（中期的）
- 購入システムの一部をモダン化し、テスト運用
- モダン化した購入システムをテスト運用から本格運用へ
即時戦術ゴール（短期的）
- スプリントゴール
得たい価値はなにか
- 重要価値領域を参考にする
- 技術的負債の返済は、市場価値を高めない
2-4名のチーム
- トライ＆エラーのサイクルを早めたい
- 意思伝達のパスを少なくしたい
たたき台を作る
- デファクトとなるモジュールを小さなチームで立ち上げる
- 構造的に堅牢な作りを整える
- 腐敗防止層が大事
「AI？ダメ絶対！」とは言わせない！ 伝統的な企業文化のなかでも、ソフトウェア開発にAIを導入するための3つの方法とは？
GitLab Duo：AIがチームメンバーかのように支援してくれる
AIがチームの一員になると、
- 議論はソースコードの提案に活用される
- CI失敗原因分析に活用される
AI活用に対する不安や懸念
- 漠然としている
- 外部への知的財産流出の懸念
- AIが作ったものに脆弱性は含まれないのか
- AIが作ったものをレビューできるか
- GitLabが考える解決策
- Local LLMも可能
- セキュリティスキャンを実施可能
- AIがレビューを実施させることが可能
- レビュー観点なども指示可能
- 漠然としている
“QAを早期に巻き込む”ってどうやるの？モヤモヤから抜け出す実践知
QA as “Question Asker”
遅れて入るQAあるある
- テストだけやる人と思われている
モヤモヤの正体
- 早期QAあるあるによるメリット提示方法は？
QAを巻き込めないあるある
- いつから呼んだらよいかわからない
モヤモヤの正体
- 改善効果の測定
QAチームのミッション、ビジョンをプレゼン
- QAが何者かを宣言
リグレッションテスト省エネ化
- 新機能開発に関与できる時間を確保
不具合件数を計測、グラフ化
- 現在地の認識合わせ
仕様確認や提案、テスト活動
- QAから問いを投げる
- テスト設計＝対話ツール
自分が一番貢献できることをやりきる
- プロジェクトの進捗報告
- ユーザー視点、俯瞰した視点
その結果
- 徐々に仕様決定の前に呼ばれるようになった
- QAの立ち位置の変化
- リリース直前の不具合検出
「普段はわからないが、潮が引いたときに、誰が全裸で泳いでいたかがわかる」
- 『リーディングクオリティ』
QAはロール。QAエンジニアに限らなくても良い。
プロダクトも事業も開発する、プロダクトエンジニアの役割
プロダクトエンジニアとは？
- ユーザーの価値、事業の成長を最大化させるエンジニア
- 何を作るのか（ユーザー体験）
- なぜ作るのか（事業）
- どうやって作るのか（技術）
- プロダクトを作るために必要な技術を一通り有する（フルスタックエンジニア）
なぜこれからプロダクトエンジニアが重要なのか？
- AIエージェントの登場
- １人のできる範囲が広がる
- コードを書くという体験が変わる
- 今までもプロダクトエンジニアは重要だった
- AIエージェントの登場
属人性の高まり
- マイルストーンごとにプロジェクトのアサインを変更し、ドメイン知識の共有を行う
- チーム内での情報共有方法の改善
- プロジェクトの目的や背景の共有
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
AIに対するスタンス
できないことはなんだろう
- 責任をとること
エンジニアの責務は、専門性を踏まえて説明責任を果たすこと
説明責任を果たせる意思決定と行動をすること
誰に対する説明責任？
- ユーザー、社会・未来に常に責任がある
機能要件、非機能要件
- 機能要件（有用性）はAIでもできるようになりつつある
- 非機能要件（保証）はまだ
- 保証の部分を「地力」とする
知識→論理的判断
価値の認識→倫理的判断
両方重要だが、価値の認識は局所性が高くて難易度高め
どうやって価値の認識を獲得するか
場数を踏む
データと向き合って深く考慮する
対話する
継続する
根性と執念
OJT/実践での定点観測会が一番のおすすめ
- 定点観測会の例）
- ログからエラーレートを見る
- コストのグラフを見る
- OODAループを意識して継続する
- 定点観測会の例）
HowよりもWhyやWhatに向き合う
- WhyやWhatを過去の経験に照らしてみる
知識の獲得よりも対話・ディスカッションを重視
価値観の違いを知る