AI時代の開発用語マップ

Transcript

1. AI時代のソフトウェア開発 AI時代の開発用語マップ 迷子にならないための「階層」と「軸」 AI駆動開発・SDD・TDD・EDD・LLMOpsを一枚の地図に
2. 結論：一文でいうと AI時代の開発用語は「階層」と「軸」で整理できる AI駆動開発は「AIに作らせる」という前提。 人間はSDDで決め、TDDで確かめ、LLMを含むならEDDでも確かめる 01 02 03 04 階層が違う 軸が違う 一本の流れ 運用も同じ構図 AI駆動開発は「あり方」、AIDLCは「方法論」、SDDは「手 法」、Claude Codeは「ツール 」。階層の違うものは比べない AI駆動開発は「AIに作らせる 」側、EDD・LLMOpsは「製品 にLLMが入る」側の言葉 SDDで合格条件を決め、それ を実行できる形にしたのがテス ト（TDD）と評価（EDD） TDDをCI/CD・DevOpsで回す ように、EDDの評価はLLMOps で本番まで回し続ける 2
3. 混乱の原因は2つ よく同じ列に並べられる言葉には、「階層」と「軸」の2種類のズレが混ざっている よく同じ列に並べられる言葉 AI駆動開発 AI-DLC SDD TDD 階層が違う 方法論 LLMOps DevOps Claude Code AIとの関わり方の軸が違う 「あり方」「方法論」「実践手法」「運用の仕組み」「ツール」 が混ざっている。例：AI駆動開発（あり方）とSDD（手法）は比 べられない あり方 EDD 実践手法 運用の仕組み ツール 「AIに作らせる」話、「製品にLLMが入る」話、「AI以前からあ る」話が混ざっている。例：SDDとEDDは別の軸の言葉 AIに作らせる AI以前から 製品にLLMが入る 3
4. 用語マップ 縦は「階層」、横は「AIとの関わり方」。主要な用語はすべてこの表のどこかに入る 軸A あり方 方法論 実践手法 運用の仕組み ツール AIに作らせる・回させる 共通 AI以前からある AI駆動開発 ウォーターフォール 支援型・駆動型・自律型 アジャイル AI-DLC・BMAD Method 任意。なくても始められる スクラム・カンバン 軸B 製品にLLMが入る ― ― SDD TDD EDD 仕様駆動開発 テスト駆動開発 評価駆動開発 AIOps AIで運用する CI/CD・DevOps MLOps・LLMOps LLM製品を運用する Claude Code・Kiro Jenkins・GitHub Actions 評価・監視ツール Copilot・Spec Kit Git LangSmith・Langfuse など 迷ったら「どの階層か」「どの軸か」を確かめる。違うマスの言葉同士は、比べたり置き換えたりしない 4
5. 軸は2本 「誰が作るか」と「何を作るか」は独立している 軸A 作り方 軸B 作るもの 誰がコードを書くか 製品にLLMが入っているか 人が書く AIが書く AI駆動開発 人間の仕事が「書く」から「決める・確かめる」に移る。だから SDD・TDDの重要度が上がる 入っていない 入っている LLMを含む製品 出力が毎回揺れるので、合格／不合格では測れない。だからEDD が必要になる AIで普通の業務アプリを作ることも、人の手でLLMアプリを作ることもある。2つの軸は別々に考える 5
6. AI駆動開発は「開発のあり方」 手法ではない。AIに作らせると、人間に残る仕事は「決める」と「確かめる」になる 人間主導 AI主導 AI支援型 AI駆動型 AI自律型 人間が書き、AIが補完・提案する AIが計画・実装し、人間が判断・承認する 要件を渡すとAIがほぼ全部作る AIが書くようになると、人間に残る仕事は2つ 決める 何を作るか、何をもって合格とするか SDD 確かめる できたものが本当に正しいか TDD・EDD AI駆動開発は手法ではない。SDDやTDDと横並びで比べるものではない 6
7. 2つの軸を掛け合わせる SDD・TDDは「AIが書く」ことで、EDDは「LLMを含む」ことで必要になる LLMを含まない製品 人が書く 従来の開発 AIが書く AI駆動開発 LLMを含む製品 従来どおり TDD ＋ EDD TDDなどはチームの判断 骨格はTDD、LLMの振る舞いはEDD SDD ＋ TDD SDD ＋ TDD ＋ EDD 仕様をAIへの入力にし、テストで確かめる 3つすべて。AIエージェント自体を作る場合など EDDは「AIが書くかどうか」ではなく「製品にLLMが入るかどうか」で決まる 7
8. 「決める→確かめる」の一本の流れ テストと評価は、仕様に書いた合格条件を実行できる形にしたもの 確かめる（決定的な部分） → 決める TDD 仕様に書く 確かめる（LLMの部分） SDD ・何を作るか ・何をもって合格とするか 判定：人間がレビュー・承認 → EDD テストコード 合格か不合格か。1回で決まる 評価データと評価基準 スコア・合格率。複数回試して揺らぎも見る CI/CDで毎回自動実行し、リリース条件にする 違いは、確かめる対象が決定的か、揺らぐか。それだけ 8
9. 3つの手法を並べて比べる 問い・作るもの・判定の仕方がそれぞれ違う SDD（仕様駆動開発） TDD（テスト駆動開発） EDD（評価駆動開発） 問い 何を作るか ロジックは正しいか LLMの振る舞いは十分良く、安定しているか 作るもの 仕様書（要件・設計・合格条件） テストコード 評価データ・評価基準 判定 人間のレビュー・承認 合格か不合格か（アサーション） スコア・合格率（正解照合、ルール、LLM採点 、人の評価） 実行回数 ― 1回で十分 同じ入力を複数回試し、揺らぎを見る AIにとって 作業の入力。書かれていないことは伝 わらない 通るまで自分で直せる、明確なゴール プロンプトやモデル変更の良し悪しを測る物差 し いつ必要か AIに作らせるとき ほぼ常に 製品にLLMが入るとき 9
10. LLMを含む製品でも、TDDとEDDを使い分ける 例：社内問い合わせエージェント ― 検索関数はTDDで、回答の正確さはEDDで確かめる 骨格 振る舞い TDD 決まった入力に決まった出力を返す部分 LLMが判断・生成する部分 • ツール関数・API連携 • どのツールを選ぶか • 入出力のパース・整形 • 回答の正確さ・指示への従い方 • 制御ロジック・エラー処理 • 安全性（言ってはいけないことを言わない） EDD LLMを含む製品でも、骨格のコードはTDDで確かめる。EDDだけでは足りない 10
11. 開発工程ごとの関わり方 合格条件と評価基準は、仕様と同時に作る 工程 SDD 要件定義 ◎ 要件と合格条件を書く 設計 ◎ 設計書・タスク分解 ◦ テスト方針を決める ◦ 評価項目・評価データを準備 実装 ◦ AIが仕様を参照 ◎ テストを先に書き、通るまでAIが修正 ◦ プロンプト調整のたびに評価 テスト・レビュー ◎ 単体・結合テスト ◎ 複数回実行しスコアと揺らぎを確認 リリース ◎ CIで全テスト通過が条件 ◎ 評価スコアが基準以上が条件 ◦ 不具合を回帰テスト化 ◎ 本番品質を継続監視、劣化を検知 運用 ◎ 中心的に関わる ◦ 学びを仕様に反映 TDD EDD（LLMを含む場合） ◦ 求める品質水準を決める ◦ 関わる 11
12. DevOpsとLLMOpsの違い LLMOpsは、DevOpsに「揺らぐもの」を扱う仕組みを足したもの 観点 DevOps LLMOpsで加わるもの 対象 ソフトウェア全般 LLMを組み込んだ製品（チャットボット、エージェントなど） 変更の単位 コード、設定、インフラ プロンプト、モデルのバージョン、RAGの参照データ、ツール定義 リリース前の確認 テスト（合格か不合格か） 評価（スコア・合格率・揺らぎ）＝ EDD 本番で見るもの 稼働率、エラー率、レイテンシ 回答品質、安全性、トークンコスト、LLM呼び出しのトレース 一番の違い：コードを変えていなくても品質が変わる モデル提供元の更新や入力の傾向の変化で挙動が変わりうる。「変更のたびにテスト」だけでは守れず、本番でも品質を測り続ける必要がある 12
13. LLMOpsはDevOpsの上に乗る LLM製品の運用 ＝ DevOps（骨格のコード）＋ LLMOps（LLMの部分） 開発の実践 運用の仕組み 決定的な部分 TDD DevOps（CIでテストを毎回実行 ） LLMの部分 EDD LLMOps（パイプラインと本番で 評価を継続実行） LLMOps 評価・プロンプト管理・品質／コスト／安全性 の監視 MLOps データ・学習・モデル管理（自前で学習しないなら比重は下 がる） DevOps CI/CD・IaC・監視。LLM製品でも骨格のコードはここで回す EDDは評価を軸に作る開発の実践。LLMOpsはその評価をリリース判 定と本番監視に組み込み、回し続ける仕組み EDDとLLMOpsは、TDDとCI/CD（DevOps）と同じ関係。どちらか一方では足りない 13
14. よくある取り違え 言葉の混乱は、だいたいこの6つから生まれる AI駆動開発は手法ではない 「AIが書き、人間が決めて確かめる」とい う開発のあり方。SDDやTDDと横並びに比 べるものではない 「SDD」には2つの意味がある 仕様を先に書く実践そのものと、Spec Kit やKiroのSpec機能のようにそれを進める型 。どちらの話かを揃える SDD・TDDは新しい手法ではな い TDDは2000年代からあり、仕様を先に書く 考え方も昔からある。AIが書くことで価値 が上がり、再注目されている EDDはコーディングAIの評価で はない 自分たちの製品に組み込んだLLMの品質を 測ること。比較的新しい言葉で、指す範囲 はまだ揺れている 方法論は必須ではない LLMOpsとAIOpsは逆向き 今のプロセスのまま手法やツールから始め られる。人数や規模が増えて進め方を揃え たくなったら、AI-DLCなどを検討する LLMOpsはLLMを組み込んだ製品を運用する こと。AIOpsはAIを使って運用作業（障害 検知など）をすること 14
15. まとめ 大事なのは「階層」「軸」「決める→確かめる」の3つ AIに作らせるなら、SDDで決め、TDDで確かめ、LLMを含むならEDDでも確かめる AI駆動開発 前提 AIに作らせる。人間の仕事は「決める」と「確かめる」になる SDD 決める 何を作るか、何をもって合格とするかを仕様に書き、AIへの入力にする TDD 確かめる 決定的なロジックを、合格か不合格かのテストで確かめる EDD 確かめる 製品にLLMが入るときだけ。振る舞いをスコアと揺らぎで確かめる LLMOps 運用 EDDの評価を本番まで回し続ける仕組み。DevOpsの上に乗る 方法論 任意 AI-DLC・BMADなど。手法の組み合わせ方と承認ポイントを決めたレシピ ツール 道具 Claude Code・Kiroなど。CI/CDでテストと評価を自動で回す 迷ったら「その言葉はどの階層か」「どの軸か」を確かめる（→ 用語マップ・付録の用語集） 15
16. 付録 用語集 16
17. 用語集（1/2） あり方・方法論・実践手法 用語 一言でいうと 混同しやすい相手 AI駆動開発 AIがコードを書き、人間が決めて確かめる開発。支援型〜自律 型まで幅がある SDD・AI-DLC（手法でも方法論でもない） 仕様を書かず、AIとの対話で感覚的に作り進める SDD（対極にある） AWS提唱。AIが質問・計画し、人間が承認しながら工程全体 を進める AI駆動開発（その一形態）、SDLC（名前が似 る） 役割を持つAIエージェントでアジャイルチームを再現するOSS の型 AI-DLC（同じ階層の別の選択肢） 何を作るか・合格条件を仕様に書き、AIへの入力にする Spec Kit・KiroのSpec機能（進める道具） GitHub製。仕様→計画→タスク→実装の流れでSDDを進める SDD（実践そのもの） テストを先に書き、通るまで実装する。決定的なロジック向け EDD（揺らぐ出力は合否で測れない） 評価データでLLMの振る舞いをスコアと揺らぎで測りながら作 る コーディングAIの性能評価 あり方 バイブコーディング 進め方のスタイル AI-DLC 方法論 BMAD Method 方法論 SDD 実践手法 Spec-Driven Development Spec Kit 型・ツール TDD 実践手法 Test-Driven Development EDD 実践手法 Eval-Driven Development 17
18. 用語集（2/2） 枠組み・運用の仕組み・ツール 用語 SDLC 枠組み Software Development Life Cycle CI/CD 仕組み Continuous Integration / Delivery DevOps 文化・仕組み MLOps 仕組み LLMOps 仕組み AIOps 仕組み Claude Code・Kiro ツール Jenkins・GitHub Actions ツール 一言でいうと 混同しやすい相手 計画から運用・保守までの開発工程全体 AI-DLC（こちらは方法論） ビルド・テスト・デプロイを自動で回す Jenkins（それを動かす道具） 開発と運用をつなぎ、速く安全にリリースし続ける LLMOps（その上に乗る） 機械学習モデルのデータ・学習・デプロイ・監視を回す LLMOps（LLM向けの派生） LLM製品の評価・プロンプト管理・品質やコストの監視を回し 続ける AIOps（向きが逆） AIを使って運用作業（障害検知・原因分析など）を行う LLMOps AIコーディングエージェント。どの方法論でも使える AI-DLC（方法論） CI/CDを動かす道具 AI-DLC（置き換わる関係ではない） 18