”AIを使う” から ”AIに任せる” へ ─ 開発プロセスを再設計してAIを組織標準にするまで

野⼝ 皓平 / MG-DX テックリード

Transcript

1. Noguchi Kohei MG-DX: CTO, Tech lead CyberAgent “AIを使う”から”AIに任せる”へ ─ 開発プロセスを再設計してAIを組織標準にするまで
2. 01 Hook なぜ開発プロセスと 実⾏基盤の再設計に⾏き着いたか 02 Deep Dive AI を前提とした開発プロセスと 実行基盤の再設計 03 Lessons 苦労した点と乗り越え⽅ 04 Observation 指標に現れた開発アウトプットの変化 05 Closing 今後：幅から深さへ Agenda
3. Who we are サイバーエージェント / MG-DX 世の中を本気で良くする薬局に、 AI で役立つ。 1998 サイバーエージェント設⽴ 2020 MG-DX 設⽴ 2021 薬急便リリース 2024 遠隔接客 AI アシスタントリリース 180 万人~ 2026 患者会員数 180 万⼈
4. 担当領域 / Responsibilities • 医療プラットフォーム MG-DX のバックエンド‧ インフラ ◦ Go / GCP / AWS / Kubernetes / データ基盤 ..etc • 組織の AI ドリブン開発移⾏ X: @Koh456wip 野⼝ 皓平 / Kohei Noguchi MG-DX テックリード 株式会社サイバーエージェント / 株式会社MG-DX
5. なぜ開発プロセスと 実⾏基盤の再設計に ⾏き着いたか
6. • ⽣成 AI 徹底理解リスキリング • 年間 4 億円投資 • 組織全体で複数の AI コーディングツールを導⼊ • その他⽉ 200 ドル個⼈予算 前提：会社としての AI に対する投資 → 開発は AI ドリブン化する？
7. 開発プロセスと実⾏基盤が AI を前提として設計されていない 現実とのギャップ 1. 前提情報が整備されていない → エージェントは⽂脈を⾃⼰解釈する 2. 指⽰を積み重ねる → コンテキストがオーバーフローし、判断を誤る 3. ⽣成されたコードは本番で投⼊できるものではない 4. ⾏き着く先は「都度、⼈間が介⼊して軌道修正する」状態
8. AI コーディングが詰まるのは、 AI モデルの問題か？
9. AI のための開発プロセスと 実⾏基盤の再設計が必要ではないか
10. 開発プロセスと 実⾏基盤の再設計
11. 開発プロセスの 再設計 開発プロセス単位の現状評価 実装だけを AI 化しても、レビューやテストで詰まる 移⾏プラン 依存関係、導⼊インパクト..etc AI があるからこそ実現可能な開発プロセス e.g.) コードベースとしたアプリケーション仕様ドキュメント⾃動⽣成
12. 全プロセスの現状評価 開発プロセスを 28 項⽬に分解 × AI ⾃律レベルを L0~L4 評価
13. 移⾏プラン例
14. 実⾏基盤の 再設計 Requirements（要件） Business Context / Functional Requirements / Domain Model Architecture SOLID / DDD / Application Architecture / Coding Rules / Security Infrastructure Google Cloud / AWS / kubernetes Context Engineering attention budget を意識 — context rot を構造的に回避 Generator-Evaluator ループ 実装と評価を分離した⾃律修正ループ
15. AI のスタートラインを整備する — 前提情報 Requirements（要件） Architecture Monitoring • Product Backlog • Issues • Design Doc • Google Cloud / AWS • Kubernetes • Application Architecture • Design Principles • Logs • API / DB / GKE Metrics • Tracer • Event Logs（Big Query） • MCP • Github Issue • Github ◦ docs/services/{context} ◦ mcp.json ◦ setting.json • Github ◦ CLAUDE.md ◦ rules/architecture.md ◦ rules/design_principles. md • MCP ◦ gcloud-mcp ◦ observability-mcp
16. AI のスタートラインを整備する — ハーネス Context Extensions Skills Guardrails CLAUDE.md / .claude/rules/ 外部情報 MCP（Notion / observability / GitHub） Plugins CLI 再利⽤可能な⼿順 パッケージ 権限境界 allow / ask / deny の 3 段階 Subagents 役割特化エージェ ント
17. AI が効果的に動くための設計 Context Engineering Context は有限資源 実装と評価の分離 様々な Workflow パターン Generator-Evaluator 拡張 — Workflow パターン
18. Context Engineering — 概念 Prompt → Context • Prompt Engineering: 書き⽅の最適化 • Context Engineering: ⾼シグナルなトークンの最⼩集合を発⾒ 対象: system prompts / tools / message history / external data • attention budget を意識する • n トークンに対し n² 通りのペアごとの対関係。（計算量の増加） • context rot: 追加するほど効果は逓減 • prompt は会話とともに消える — ナレッジが残らない • context は rules / skills / settings / MCP に事前に積む • 「prompt の上⼿い個⼈」より「同じ context が選択される仕組み」 context は有限資源 リポジトリ上の資産
19. Context Engineering — 実践例 実装 効果 標準 context CLAUDE.md: 常時読み込みは最⼩限 .claude/rules/ : 複数エージェントで参照想定 - design_principles‧architecture‧DDD‧security.. etc 組織での前提標準化 専⽤ context Skills, Subagents で個別定義 個別の prompt から脱却 1 LLM が扱う範囲を⼩さく保ち、context rot を構造的に回避 Examples / Few shot Good / Bad 例を埋め込む / 標準的な参照を明⽰ 期待する出⼒形式が暗黙知ではなく明⽂化 External data （just in time） MCP で repo 外情報を on-demand 取得 （Design Doc / Notion / API メトリクス / GKE メトリクス / GitHub) 「前提情報を都度コピペ」が不要 エージェントが⾃律的に取りに⾏ける alwaysApply 精査 全ルールを常時読み込まない alwaysApply: false で globs 指定 該当ファイルが context に含まれた時だけ発⽕ attention budget を無駄遣いしない
20. なぜ実装と評価を分離するのか Generator-Evaluator — 概念 • ⾃⼰評価は失敗する ◦ ⼀発で完成させない — 評価ループを設計 ◦ 実装エージェントと評価エージェントを分離 • Anthropic: Evaluator-optimizer パターン • 独⽴した判定機構すべてを Evaluator とみなす ◦ LLM サブエージェント ◦ テストランナー ◦ 静的解析 ◦ コマンド実⾏結果 • 両者の組み合わせで⾃律修正ループが堅牢に Evaluator は LLM-based に閉じない
21. Generator-Evaluator — 実践例
22. Workflow パターン — Parallelization（並列化） 事例 PR review • 専⾨ subagent がレビュー • subagent の結果を統合 • 統合結果をレビューコメント middleware-version-scan • 対象 middleware 分 subagent 起動 • subagent の結果を統合 • 統合結果を元に scan 結果を出⼒ 複数 LLM が同時に実⾏出⼒に集約
23. Workflow パターン — Orchestrator-workers 事例 design-doc-impl-orch • orchestrator が design doc を input • 各 generator の中央集権的制御 ◦ 必要な generator の選択 ◦ generator の実⾏順序決定 ◦ 実⾏結果の最終検証
24. 苦労した点と乗り越え⽅
25. Context Engineering ⾜し算 精度が逆に落ちる 最⼩性 ⾼シグナルなトークンの最⼩集合 構造化 rules / docs を章⽴て‧最⼩化
26. 出⼒品質 デモ品質 すぐに完成する 本番品質 ギャップを埋める 継続改善 作ってから磨く
27. エージェント評価 理想 Eval harness を構築 定量 まだ限定的 定性 使⽤者の素直な感想 NPS、出⼒品質、⼯数削減実感 ..etc NPS 例
28. Observation 開発アウトプットの変化
29. 前提：NOT KPI 観察された変化 • Proof ではなく Observation • グッドハートの法則 前提：⼈数の増加はなし • 若⼿中⼼構成へ アウトプットの増加 • ソースの異なる 5 指標が⼀貫して上昇 FY2024H1 → FY2026H1 × 3.27 ベロシティの変化 × 3.45 本番デプロイ数 × 2.57 ⽉平均純増 LOC （⾃動⽣成除く） × 2.56 Application Layer Use Case 数 × 3.36 テストケース数
30. Closing Next: 幅から深さへ
31. Next: 幅から深さへ これまで 幅から深さ 計測の本格整備 あらゆる開発プロセスに AI を • 28 項⽬ × Lv 0〜3+ に分解 • AI が関わらないプロセスはない • コード⽣成 / レビュー / テスト / Doc / モニタリング / 監視 / セ キュリティ... • Context, Extensions, Guardrails の整備は概ね完了 より複雑な処理の⾃律実⾏ • Evaluator の改善 • Evaluator-Optimizer ループの 深化 • ⼈の介⼊をさらに減らす Eval ハーネスの構築 • task / trial / grader / transcript / outcome を分離 • 各エージェント‧ワークフローの 品質を図れる⼟台へ
32. Connect with Me    Tech Blog MG-DX Tech Blog https://zenn.dev/p/mgdx_blog X (Twitter) Koh456wip Official Website https://www.mg-dx.co.jp/