AIコーディングエージェント開発_全体像

Transcript

1. AIコーディング エージェント開発 コード開発・テスト・全体の自動化 ── 手法の全体像と関係性 コード開発時 テスト どこから始めて、どう積み上げる？ 全体の自動化
2. 全体マップ：3つのレイヤーと関係性 コード開発・テスト・全体の自動化 全体の自動化：AI-DLC（どう作るか）× LLMOps（どう運用するか） 統制・再現性が高まる → コード開発時 バイブコーディング Vibe-to-Spec 開発 仕様駆動開発 対話で即興的に書く 仕様を後追いで同期 仕様を起点に実装 ↓ 仕様・受け入れ基準を渡す テスト 要 AIによるテスト駆動開発 「正しく動くか」を確定的に検証 ↑ 結果・スコアを返す ＋ AIによる評価駆動開発 「どれだけ良いか」を指標で測定 AI-DLCが工程全体をAI主導にし（人は判断・承認）、LLMOpsが本番のLLM機能の品質を評価・監視で守る AIコーディングエージェント開発 ── 手法の全体像と関係性 ※ Vibe-to-Spec 開発（仮称）：アイディアのひとつ 2
3. コード開発時：3つのスタイル 自由度・スピード重視 → 統制・再現性重視 バイブコーディング Vibe-to-Spec 開発 仕様駆動開発 仕様はなし。対話がすべて 仕様は後追いで同期 仕様が唯一の正 自然言語で「雰囲気」を伝え、AIが 書いたコードを動かしながら対話で 直していく。意図はチャット履歴と コードにしか残らない。 バイブコーディングで進めつつ、実 装内容からAIに仕様書を書き起こさ せ、変更のたびに更新させる。暗黙 知を文書に変える橋渡し。 要件・設計・タスクを先に仕様書と して固め、AIはそれを正として実装 する。変更はまず仕様を直してから 。 向いている場面 向いている場面 向いている場面 PoC・試作・個人ツール 試作の本格化・既存の可視化 チーム開発・本番・長期保守 AIコーディングエージェント開発 ── 手法の全体像と関係性 ※ Vibe-to-Spec 開発（仮称）：アイディアのひとつ 3
4. 違いは「仕様の位置づけ」にある 3つのスタイルを並べて比べる バイブコーディング Vibe-to-Spec 開発 仕様駆動開発 仕様の位置づけ なし（頭の中） コードの後追い コードの起点 情報の正 コード コード（仕様は写し） 仕様書 立ち上がりの速さ ◎ 最速 ◦ 速い △ 準備が要る 再現性・引き継ぎ △ 属人的 ◦ 文書で共有可 ◎ 誰でも再生成可 AIへの指示 その場の会話 会話＋仕様の更新依頼 仕様書とタスク よくある移行パス バイブで探索して 動くものを作る AIコーディングエージェント開発 ── 手法の全体像と関係性 AIに仕様書を 書き起こさせる 以降は仕様を正に して機能追加 ※ Vibe-to-Spec 開発（仮称）：アイディアのひとつ 4
5. テスト：2つの駆動開発 TDDとEDDは補完し合う両輪 AIによるテスト駆動開発 AIによる評価駆動開発 壊れていないか？（正解が一つ） どれだけ良いか？（正解が幅を持つ） 仕様からAIが先にテストを書き、テストが通るまでAIが実装 を繰り返す。テストがAIの暴走を止めるガードレールになる 。 評価データセットと採点基準（ルール・LLM-as-a-Judge・ 人手）を先に用意し、スコアを指標に改善を繰り返す。 テストを書く 実装する 全件パス 整理する 評価セット 実行する 採点する 改善する くり返し：合格するまでAIが自律的に反復 くり返し：合格するまでAIが自律的に反復 対象 ロジック・API・データ変換など、期待値が一意に決 まるもの 対象 LLMを使う機能・エージェントの振る舞い・プロンプ ト 関係性：TDDで「確定的な正しさ」、EDDで「確率的な品質」を担保する ── 補完し合う両輪 AIコーディングエージェント開発 ── 手法の全体像と関係性 5
6. 仕様からテスト・評価、そして実装へ 仕様が明確なほど、AIに任せられる YES → 完了 テストケース TDD：期待値で判定 仕様書 AIエージェント 要件・受け入れ基準 が実装 評価データセット 合格？ EDD：スコアで判定 NO → 再実装（AIが自律反復） → エージェントへ戻る 仕様が明確なほどテスト・評価が書ける。テスト・評価があるほどAIに任せられる。不合格の原因が仕様の曖昧さなら 、仕様へ戻して直す。 AIコーディングエージェント開発 ── 手法の全体像と関係性 6
7. 全体の自動化：AI-DLCで作り、LLMOpsで運用する 4つのフェーズを回し続ける 構想 Inception AIが要件・仕様を起案 人が確認・承認 構築 Construction AIが仕様駆動で実装 TDD／EDDで検証 AI-DLC 「AIでどう作るか」の方法論。構想・構築・運用の3フェー ズで、AIが計画・実装を主導し、人が各フェーズで判断・承 認する（AWSが提唱）。 LLMOps 「LLMをどう運用するか」の実務。プロンプト管理・評価・ 品質監視・ガードレール・コスト管理で本番のLLM機能を守 る。 改善 LLMOps LLM出力を評価・監視 プロンプト等を更新 運用 Operations デプロイ・監視 障害対応・改善 AIコーディングエージェント開発 ── 手法の全体像と関係性 関係性：枠組みと、その中の実務 AI-DLCが開発プロセス全体の枠組み。作るものがLLMアプリ なら、LLMOpsが構築（評価設計）と運用（監視・評価）に組 み込まれ、本番の結果が次の仕様へ還流する。 7
8. AI-DLCとLLMOpsの違いは「AIの役割」 上位の枠組みと、その中の実務 AI-DLC LLMOps 主な問い AIで「どう作るか」 LLMを「どう運用するか」 AIの役割 開発の担い手（エージェント） プロダクトの構成要素 対象 開発プロセス全体 本番のLLM機能（プロンプト・RAG等） 主な活動 起案・承認・仕様駆動実装・検証 評価・監視・ガードレール・コスト管理 位置づけ 上位の枠組み（方法論） 枠組みの中で品質を担う実務 交わる3つのポイント LLMアプリを作るなら 構築・運用にLLMOpsが入る AIコーディングエージェント開発 ── 手法の全体像と関係性 開発エージェントもLLM 開発基盤にもLLMOpsが要る 人の承認・記録・評価 という思想は共通 8
9. まとめ：段階的に積み上げる どの段階から始めてもよい 6 5 4 3 2 1 仕様を残す バイブで試す 仕様を正にする 正しさを守る 品質を測る 全体を回す AI-DLC × LLMOps AIによるEDD AIによるTDD 仕様駆動開発 Vibe-to-Spec 開発 バイブコーディング 要 どの段階から始めてもよいが、上に行くほどAIに安心して任せられる範囲が広がる AIコーディングエージェント開発 ── 手法の全体像と関係性 ※ Vibe-to-Spec 開発（仮称）：アイディアのひとつ 9