AI駆動開発の基礎用語集｜AIDDを理解するための30語

AI駆動開発の周辺では、開発手法を表す言葉と、生成AIの仕組みを表す言葉、AIエージェント製品の機能名が混在しています。 似た言葉の違いが分からないままでは、「AIに何を任せるのか」「人間はどこを確認するのか」という話も噛み合いません。

この用語集では、AI駆動開発を理解するために必要な30項目を、実際の開発で登場する順序に沿って整理します。 個別の製品だけで使われる名称はその旨を明記し、一般的な概念と区別します。

AI駆動開発の進め方を表す用語

1. AI駆動開発（AIDD）

AI駆動開発（AI-Driven Development、AIDD）は、生成AIを開発工程の中心に置き、人間が方針の決定と成果物の検証を担う開発スタイルです。 AIにコードを書かせるだけでなく、要件整理、設計、実装、テスト、レビュー、ドキュメント更新までをAIが作業できるように工程を組み直します。

厳密に統一された標準規格ではなく、組織や発信者によって含める範囲には差があります。 本サイトでは、AIコーディングエージェントが実装を進め、人間が目的、制約、受け入れ条件を管理する開発全体を指します。

AI駆動開発（AIDD）とは？従来の開発との違いと導入の考え方

AI駆動開発（AIDD）とは、生成AIを開発工程の主役に置き、人間が方針決定と検証を担う開発スタイルです。コード補完との違い、開発工程がどう変わるか、導入の順序と注意点を解説します。

2026年7月25日

2. AI支援開発

AI支援開発（AI-Assisted Development）は、人間が従来の開発工程を主導し、コード補完、質問への回答、テストの下書きなどにAIを使う進め方です。 AI駆動開発との境界は、製品名だけで一意に決まるものではありません。 本稿では、人間とAIのどちらが作業手順を組み立てるかで区別します。

人間がファイルを開き、書く箇所を決め、AIの提案を一つずつ採用するならAI支援開発です。 タスクを渡されたAIがリポジトリを調べ、複数のファイルを変更し、テストまで実行するならAI駆動開発に近づきます。

3. バイブコーディング

バイブコーディング（Vibe Coding）は、自然言語でAIへ指示を出し、生成されたコードの詳細を追わず、動作の手応えを頼りに修正を重ねる開発スタイルです。 短時間で試作品を作る用途には向きますが、仕様との一致や変更理由を説明できることが求められる本番開発には、そのまま持ち込めません。

AI駆動開発はバイブコーディングを内包する上位語ではありません。 生成されたコードの内容と変更理由を人間が把握せず、動作の手応えを中心に受け入れるかどうかが、両者の違いです。 AI駆動開発では、テスト、レビュー、権限制御などを使い、成果物と実行過程を検証します。

バイブコーディング（Vibe Coding）とは？意味と、本番開発に持ち込むときの注意点

バイブコーディングとは、生成コードの中身を確認せず動作の手応えだけで開発を進めるスタイルです。語の由来、プロトタイプでの強み、本番開発に持ち込むときの注意点を解説します。

2026年7月25日

4. SDD（仕様駆動開発）

SDD（Spec-Driven Development、仕様駆動開発）は、コードを書く前に仕様を文書化し、その仕様を基準に設計、タスク分解、実装、検証を進める手法です。 AIが曖昧な要件を一般的なパターンで補ってしまう問題に対し、入力となる仕様を先に整えることでズレを減らします。

仕様を実装後も更新し続けるかは、採用する運用によって異なります。 継続して管理する場合、自然言語の仕様書は人間同士の合意とAIへの指示を兼ねる成果物になります。

SDD（仕様駆動開発）とは？AIコーディングを仕様で制御する開発手法を解説

SDD（Spec-Driven Development、仕様駆動開発）とは、AIにコードを書かせる前に仕様を文書として確定させ、その文書を基準に実装と検証を進める開発手法です。vibe codingとの違い、Spec KitとKiroの使い分け、TDDやウォーターフォールとの違い、導入判断の考え方までを、現場でAI駆動開発を回している立場から解説します。

2026年7月18日

5. TDD（テスト駆動開発）

TDD（Test-Driven Development、テスト駆動開発）は、期待する振る舞いをテストとして先に書き、失敗を確認してから実装し、テストを通したあとに設計を整える手法です。 一般にRed、Green、Refactorの短いサイクルで説明されます。

AI駆動開発では、テストがAIの成果物を機械的に判定する基準になります。 ただし、AIに実装とテストの両方を同じ曖昧な指示から作らせると、同じ誤解を共有したままテストが通るため、受け入れ条件は人間が確認する必要があります。

6. AI-DLC

AI-DLC（AI-Driven Development Life Cycle）は、AIを補助役として既存工程へ足すのではなく、開発ライフサイクル全体をAI主導で組み直す方法論です。 AWSが2025年に公表した方法論では、AIが計画を作って確認事項を提示し、人間が重要な判断を検証したうえで、AIが次の作業へ進む流れを繰り返します。

AI駆動開発が広い開発スタイルを指すのに対し、AI-DLCは工程とチームの進め方まで定義しようとする特定の方法論です。 略称が似ていますが、AIDDの言い換えではありません。

生成AIとコンテキストの基礎用語

7. LLM（大規模言語モデル）

LLM（Large Language Model、大規模言語モデル）は、大量のテキストやコードを学習し、入力に続く内容を生成するモデルです。 AIコーディングエージェントは、LLMにファイル操作やコマンド実行などの機能を組み合わせて作られます。

LLMは知識のデータベースを検索して回答しているわけではありません。 学習したパターンと、その時点で渡されたコンテキストをもとに出力するため、もっともらしく誤る可能性が残ります。

8. トークン

トークンは、LLMが文章やコードを処理するときの分割単位です。 日本語の一文字や英単語が常に一トークンになるわけではなく、使用するモデルの分割方式によって数え方が変わります。

モデルへの入力と出力、ツールの実行結果、会話履歴はトークンとして消費されます。 トークン数はAPIの利用料金だけでなく、どれだけの情報を一度に扱えるか、応答にどれだけ時間がかかるかにも影響します。

9. コンテキストウィンドウ

コンテキストウィンドウは、LLMが一度の処理で参照できるトークン数の上限です。 会話履歴、指示、コード、ツールの実行結果、生成中の回答が同じ枠を使います。

上限が大きくても、リポジトリ全体を無条件に詰め込めばよいわけではありません。 関係の薄い情報が増えると、必要な制約を見つけにくくなり、処理時間と料金も増えるため、タスクに必要な情報を選んで渡します。

10. プロンプト

プロンプトは、LLMへ渡す入力のうち、実行してほしい作業や回答条件を自然言語などで示したものです。 AI駆動開発では、チャット欄に入力する一回の依頼だけでなく、仕様書、エラー内容、対象ファイル、完了条件を合わせた入力全体が結果を左右します。

長く丁寧に書けば精度が上がるとは限りません。 目的、対象範囲、制約、確認方法を区別して書く方が、修飾語を増やすよりも解釈のズレを減らせます。

11. システムプロンプト

システムプロンプトは、利用者の依頼より上位で、AIの役割や守るべき基本ルールを与える指示です。 製品によっては開発者メッセージやポリシーといった別の指示階層もあり、利用者から全文が見えるとは限りません。

リポジトリに置く AGENTS.md や CLAUDE.md は、製品が読み込んで指示へ加えるプロジェクト側の文書です。 仕組み上のシステムプロンプトと同じものではありません。

12. コンテキストエンジニアリング

コンテキストエンジニアリングは、LLMが作業するときに参照する情報を選び、構造化し、必要なタイミングで渡す設計です。 一回の指示文を工夫するだけでなく、仕様書、コード、過去の判断、検索結果、ツール、会話の状態をどう組み合わせるかまで含みます。

AI駆動開発では、モデルの性能差よりもコンテキストの不足が失敗原因になる場面があります。 事業固有のルールや既存設計の理由はモデルが推測できないため、リポジトリ内の文書として渡せる状態にします。

13. ハルシネーション

ハルシネーションは、LLMが事実と異なる内容や、根拠から導けない内容を、もっともらしい形で生成する現象です。 存在しないAPI、実際にはない設定項目、確認していないファイルの内容を提示する例があります。

「AIが嘘をつく」という意思の問題ではなく、出力を生成する仕組みから生じる誤りです。 公式ドキュメントの参照、型検査、テスト、実ファイルの確認など、外部の検証手段で補います。

AIエージェントとツール連携の基礎用語

14. AIエージェント

AIエージェントは、与えられた目標に対してLLMが次の行動を選び、ツールを使いながら複数の手順を進めるシステムです。 単発の質問に文章で答えるだけのチャットボットとは異なり、途中結果を観察して行動を変えます。

一般的な構成要素は、判断を担うモデル、行動に使うツール、振る舞いを定める指示です。 どの程度を自律的に進めるかは製品と権限設定によって異なります。

AIエージェントとは？チャットボットとの違いと業務での使いどころ

AIエージェントとは、目標を与えるとAIが計画とツール実行を繰り返して作業を完了させるシステムです。チャットボットとの違い、LLMとツールとループという仕組み、業務での注意点を解説します。

2026年7月25日

15. AIコーディングエージェント

AIコーディングエージェントは、ソフトウェア開発に特化したAIエージェントです。 コードベースの検索、ファイル編集、コマンド実行、テスト、差分確認といったツールを使い、機能追加や不具合修正をタスク単位で進めます。

コード補完との違いは、提案する範囲の広さではなく、エージェント自身が作業手順と対象ファイルを選ぶ点にあります。 Claude CodeやCodex、CursorのAgentなどがこの分類に含まれます。

AIコーディングエージェントとは？補完型AIとの違いと主要ツール

AIコーディングエージェントとは、タスク単位で実装からテストまでを自律的に進めるAI開発ツールです。補完型との違い、ターミナル型、IDE型、クラウド型の主要ツール分類と選び方を解説します。

2026年7月25日

16. エージェントループ

エージェントループは、AIエージェントが現在の状態を読み、次の行動を選び、ツールの結果を観察して、終了条件を満たすまで作業を繰り返す仕組みです。 「調査する、編集する、テストする、失敗を読んで直す」という開発作業も、このループとして実行されます。

終了条件が曖昧だと、同じ修正を繰り返したり、目的から外れた作業を増やしたりします。 最大試行回数、予算、完了条件、失敗時に人間へ戻す条件を設定します。

17. Tool Use／Function Calling

Tool Use（ツール利用）は、モデルに外部ツールを利用させる機能を表す呼称です。 Function Calling（関数呼び出し）は、そのために関数名と引数を構造化して出力させるAPI上の仕組みを指します。 製品によって呼称とAPI設計が異なるため、両者がほぼ同じ意味で使われる場合もあります。 ファイルの読み書き、検索、データベース照会、APIの実行などがツールとして定義されます。

LLM自身がコマンドやAPIを直接実行するわけではありません。 ホストとなるアプリケーションやプロバイダー側の実行環境が呼び出し内容を受け取り、実際の処理を実行して、その結果をLLMへ返します。

18. MCP（Model Context Protocol）

MCP（Model Context Protocol）は、AIアプリケーションと外部のツールやデータソースを接続するためのオープンな共通規格です。 MCPサーバは、AIが実行できるツール、参照できるリソース、利用者が選べるプロンプトなどを公開します。

Tool Use／Function Callingは、モデルとホストアプリケーションの間でツール呼び出しを表現する仕組みです。 一方、MCPはAIアプリケーションと外部サーバの間でツール、リソース、プロンプトなどを公開し、接続するためのプロトコルです。 両者は競合せず、MCPで接続したツールをホストアプリケーションがモデルへ提供し、Tool Useで呼び出す構成が成り立ちます。

MCP（Model Context Protocol）とは？仕組みとできること

MCP（Model Context Protocol）とは、AIアプリと外部ツールをつなぐオープンな共通規格です。ホスト、クライアント、サーバの仕組みと、社内システム接続での使いどころ、セキュリティ上の注意点を解説します。

2026年7月25日

19. マルチエージェント

マルチエージェントは、複数のAIエージェントに役割を分け、協調させて一つの目標を達成する構成です。 調査、実装、テスト、レビューを別のエージェントへ割り当てる例があります。

複数のチャットを同時に開くだけでは、結果の統合や依存関係の管理がないため、マルチエージェントの仕組みにはなりません。 並列化で時間を短縮できる一方、重複作業、編集の競合、トークン消費が増えるため、分割可能なタスクに使います。

20. サブエージェント

サブエージェントは、中心となるエージェントから限定された作業を委譲され、結果を返す別のエージェントです。 親の会話をすべて引き継がず、担当に必要な情報だけを受け取る構成もあります。

調査結果や長いログを別のコンテキストに隔離できるため、親エージェントのコンテキスト消費を抑えられます。 ただし、前提の共有が不足すると別方向の成果物を返すため、目的、対象範囲、返却形式を委譲時に指定します。

21. オーケストレーション

オーケストレーションは、複数のエージェントやツールを、どの順番と条件で動かすかを制御することです。 中心のエージェントが担当を割り当てる管理者型、エージェント同士で担当を引き継ぐハンドオフ型、手順を固定したワークフロー型などがあります。

担当を増やすこと自体が目的ではありません。 一つのエージェントで処理できる作業まで分割する必要はありません。 専門性、権限分離、並列化の利点がある箇所だけを分ける方が、評価と障害調査を行いやすくなります。

リポジトリと実行環境の用語

22. リポジトリ指示ファイル（AGENTS.md、CLAUDE.md）

リポジトリ指示ファイルは、プロジェクト固有の構成、コーディング規約、使用するコマンド、禁止事項などをAIコーディングエージェントへ伝えるMarkdown文書です。 AGENTS.md は複数製品で使われるオープンな形式で、CLAUDE.md はClaude Codeが読み込む指示ファイルです。

READMEが人間向けの導入説明を担うのに対し、リポジトリ指示ファイルにはエージェントが作業中に守る具体的なルールを書きます。 モデルが学習済みであることを期待せず、テスト方法やディレクトリごとの制約をコードと一緒にバージョン管理します。

23. エージェントスキル（Agent Skills）

エージェントスキル（Agent Skills）は、特定の作業を再現可能にするため、指示、参照資料、テンプレート、スクリプトなどを一つのディレクトリにまとめ、必要なときにエージェントへ読み込ませる仕組みです。 記事の執筆、コードレビュー、デプロイといった作業ごとに、判断基準と手順をエージェントへ追加します。

Agent Skillsはオープン標準として公開されていますが、配置場所、検出方法、実行権限は製品によって異なります。 常時読み込む長いプロンプトとは異なり、関連する作業で必要な資料だけを段階的に読み込ませる運用単位として使われます。

24. フック

フックは、セッション開始、ツール実行の前後、作業終了など、製品が定めたイベントに応じてコマンドや検査を自動実行する拡張機能です。 利用できるイベントと処理形式は製品によって異なります。 フォーマッターの実行、危険なコマンドの拒否、操作ログの保存などに使います。

自然言語の指示はモデルの判断を介しますが、コマンド型のフックは条件に一致すれば機械的に動きます。 必ず実行したい検証や禁止処理は、指示文だけに頼らずフックやCIへ移します。

25. サンドボックスと権限

サンドボックスは、エージェントが読み書きできるファイル、実行できるプロセス、接続できるネットワークなどを技術的に隔離する仕組みです。 権限は、どの操作を自動で許可し、どの操作を拒否または人間の承認対象にするかという方針です。

両者は同じではありません。 権限設定が操作を許可してもサンドボックスの外へは到達できず、サンドボックス内の操作でも権限方針によって確認が必要になる場合があります。

品質とリスクを管理する用語

26. Human-in-the-Loop（HITL）

Human-in-the-Loop（HITL）は、AIが進める処理の過程に人間の判断を組み込む設計です。 AI駆動開発では、要件の確定、設計上の選択、マージ、本番デプロイなどが代表的な確認地点になります。

すべての操作を人間が承認すると、確認が形式化してAI導入の速度も失われます。 失敗したときの影響が大きい操作、元に戻しにくい操作、事業判断を含む操作へ確認を絞ります。

27. Evals（AI評価）

Evals（evaluations、評価）は、AIシステムの出力や行動を、テストケースと採点基準に照らして測る評価手法です。 データセット、採点方法、実行記録などを組み合わせて評価を再現できる形にします。 回答の正確さだけでなく、適切なツールを選んだか、禁止された操作をしていないか、完了条件を満たしたかも評価対象になります。

ソフトウェアの単体テストと似ていますが、出力が一つに定まらない作業も扱います。 モデルやプロンプトを変更する前後で同じ課題を実行し、成功率、費用、所要時間の変化を比較します。

28. ガードレール

ガードレールは、AIの入力、出力、ツール実行を許容範囲に収めるため、制限、検査、修正、停止などを行う制御の総称です。 禁止語の検査、スキーマによる出力検証、機密情報のマスキング、権限確認、危険な操作の承認などが含まれます。

一つのプロンプトで「安全に行動すること」と指示するだけでは、強制力のあるガードレールになりません。 認証、アクセス制御、サンドボックス、ルールベースの検査、人間の承認を重ねて、どこか一つの判断ミスで事故が成立しないようにします。

29. プロンプトインジェクション

プロンプトインジェクションは、AIが処理する入力へ悪意ある指示を混ぜ、元の目的や制約を無視させようとする攻撃です。 利用者が直接入力する場合だけでなく、Webページ、Issue、ログ、ドキュメントなど、エージェントが読み込む外部データに指示を埋め込む間接型があります。

文章の内容と命令を完全に見分けることをLLMだけへ任せるのは困難です。 外部データを信頼しない前提で扱い、機密情報へのアクセスを絞り、外部送信や破壊的操作の前に別の検査と承認を置きます。

30. 理解負債

理解負債（Comprehension Debt）は、コードベースに存在するコードの量と、チームの人間が実際に理解している範囲の差が広がった状態です。 AIが短時間に大量のコードを生成すると、レビューと知識共有が追いつかず、テストが通っていても変更理由や設計判断を説明できないコードが残ります。

技術的負債がコードの構造や保守コストに現れるのに対し、理解負債は人間の知識に生じます。 仕様と設計判断を記録し、差分を小さく保ち、レビューで「動くか」だけでなく「なぜこの実装なのか」を確認することで蓄積を抑えます。

Addy Osmaniは2026年3月に公開したComprehension Debtで、この状態をAI生成コードの増加と人間の理解の差として整理しました。

まとめ

AI駆動開発の用語は、開発スタイル、生成AIの仕組み、エージェントとツール連携、リポジトリと実行環境、品質とリスク管理という5つの層に分けると整理しやすくなります。 新しい製品名や機能名が登場しても、どの層の言葉かを見分ければ、既存の知識に接続して理解できます。

用語をそろえる目的は、言葉を正確に使うこと自体ではありません。 「AIにどこまで任せるのか」「人間はどこを確認するのか」という合意は、境界を示す言葉がチームで共有されて初めて成り立ちます。

個別の用語をさらに詳しく知りたい場合は、本文中にリンクした各解説記事を参照してください。