AIに開発を手伝わせる方法は、コードの続きを提案する「補完」から、作業をまとめて引き受ける「エージェント」へ広がっている。コーディングエージェントは、指示を受けるとコードを読み、ファイルを編集し、コマンドやテストを実行して、変更をまとめて返す。こうしたエージェントに実装やテストを任せ、人は仕様と判断を持つ進め方が、日本では「AI駆動開発」と呼ばれている。
ただし、AIを使えば開発が速くなるとは限らない。経験のある開発者を対象にした2025年の比較実験では、AIを使った作業のほうが19%長くかかった。一方で、参加者は20%速くなったと感じていた。導入の成否は、ツールの性能より、何を任せてどう確かめるかの設計で決まる。
- AI駆動開発は、コーディングエージェントに実装・テスト・修正を任せ、人が仕様・レビュー・マージの判断を持つ開発の進め方である。公的な定義はまだ定まっていない
- 似た言葉に仕様駆動開発とバイブコーディングがある。前者は仕様書を先に書いてAIに実装させる方法、後者は生成されたコードを読まずに受け入れる遊びの開発で、業務には向かない
- 主要なツールは、サンドボックス、承認の段階、利用者が上書きできない管理者の設定などの統制機能を備える。使うかどうかは導入する企業が決める
- 企業での導入は、任せる範囲、権限と実行環境、リポジトリの指示書、検証の関門、計測と育成の5点を先に決めると進めやすい
本記事は、各社の公式ドキュメントと研究機関の一次資料を2026年11月5日に確認した内容で書いている。
この記事の対象読者
主な読者は、開発チームにClaude Code、Codex、GitHub Copilotなどのコーディングエージェントを入れるか判断したいCTOや開発部門長である。現場のエンジニアが個人でエージェントを使い始め、社内のルールを作る必要がある情報システム部門やセキュリティ担当者にも向けている。エンジニアの育成計画にAI駆動開発を組み込みたい人事・研修担当者は、5つの設計のうち「計測して育てる」から読むとよい。
AI駆動開発とは（要点3行）
- コーディングエージェントに、コードの調査・編集・コマンド実行・テストをまとめて任せる開発の進め方
- 人は「何を作るか」を仕様と受け入れ条件で伝え、出てきた変更をレビューしてマージするかを決める
- 作業をまとめて任せられる分、確かめ方を先に決めないと品質と安全が崩れる
AIによる開発支援の3つの段階
開発を支援するAIは、任せる単位の大きさで3つの段階に分けられる。
| 段階 | AIに任せる単位 | 人が確かめる単位 | 代表的な使い方 |
|---|---|---|---|
| 補完 | 数行から関数 | 提案の1件ごと | 書きかけのコードの続きを提案させる |
| 対話 | 質問への回答、ファイル単位の修正 | 回答ごと | エラーの原因を聞く、関数を書き直させる |
| エージェント | タスク（調査・編集・コマンド実行・テスト） | プルリクエスト（変更のまとまり） | 不具合の修正を依頼し、テストが通った変更を受け取る |
AWSの規範ガイダンスは、コーディングエージェントを、プログラミングの課題について推論し、コードを生成・修正し、開発環境とやり取りできるものと説明している。補完のツールと違い、目的を解釈して環境から文脈を集め、行動を提案して実行する点が異なる。
エージェントには、開発者のPCで動く型と、クラウドで動いてプルリクエストを返す型がある。前者はClaude CodeやCodex CLIのように端末やエディタの中で動き、開発者がその場で確認しながら進める。後者はGitHub Copilot cloud agentのように、Issueを割り当てると隔離された環境で作業し、結果をプルリクエストで返す。
仕様駆動開発・バイブコーディングとの違い
AI駆動開発の周辺には、似た言葉がいくつかある。「AI駆動開発」には標準化団体や政府による公式の定義がなく、使う人によって範囲が違う。比較の軸をそろえるため、本記事では次のように区別する。
| 言葉 | 中身 | 出どころ | 業務での位置づけ |
|---|---|---|---|
| AI駆動開発 | エージェントに実装を任せ、人が仕様と判断を持つ開発の進め方の総称 | 日本で広く使われる呼び方。定義は一つに定まっていない | 本記事の対象 |
| 仕様駆動開発（SDD） | 何をなぜ作るかを仕様書に書き、そこから計画・タスク・コードへ落とす方法 | GitHubのSpec Kit、AWSのKiroなどが採用 | AI駆動開発の中の進め方の一つ。仕様が残るので業務に向く |
| AI-DLC | AIが計画と実行を担い、重要な判断は人が下す開発ライフサイクル | AWSが2025年7月に公開した方法論 | ベンダーの方法論として参考にできる |
| バイブコーディング | 生成されたコードを読まずに受け入れ、エラーはそのままAIに貼る開発 | Andrej Karpathy氏の2025年2月の投稿 | 本人が週末の使い捨てプロジェクト向けと限定している。業務の開発には向かない |
GitHubのSpec Kitは仕様駆動開発を、何をなぜ作るかを定め、仕様を計画・タスク・動くコードに変える方法と説明している。AWSのKiroは、要件（requirements.md）、設計（design.md）、タスク（tasks.md）の3つのファイルを作ってから実装に入る。
バイブコーディングという言葉は、AIで開発すること全般を指す意味で使われることもある。もともとの投稿は、差分を読まずに受け入れる遊びのやり方を書いたもので、業務の品質の基準とは別物である。
主なコーディングエージェントと統制機能
企業で使うときに見るべきは、生成の性能より、管理者が何を制限できるかである。主要なツールの統制機能を整理する。製品の名前と機能は変わりやすいため、導入時に公式ドキュメントで確かめたい。
| ツール | 動く場所 | 主な統制機能 |
|---|---|---|
| Claude Code（Anthropic） | 端末・エディタ。クラウドでの実行もある | 権限のモード、拒否・確認・許可のルール、管理者の設定（managed settings）、操作の前後に処理を挟むhooks、サンドボックス |
| Codex（OpenAI） | 端末・エディタ・クラウド | サンドボックスの3段階（読み取りのみ・作業フォルダへの書き込み・制限なし）、承認のポリシー、既定でネットワーク接続なし、管理者の設定 |
| GitHub Copilot cloud agent | GitHub上の隔離された環境 | 起動は書き込み権限のある利用者だけ、1つのブランチにしか書き込めない、承認とマージは不可、既定ではワークフローの実行に人の承認が要る、ファイアウォール |
| Kiro（AWS） | エディタ・端末 | 仕様駆動開発の機能、組織単位のMCPの許可リスト（IAM Identity CenterかAPIキーで認証した利用者が対象） |
Claude Codeでは、ルールは拒否、確認、許可の順に評価され、最初に一致したもので結果が決まる。確認なしで実行するモードや自動のモードは、管理者の設定で禁止でき、利用者の設定では上書きできない。公式ドキュメントは、CLAUDE.mdなどに書いた指示はClaudeの行動を方向づけるだけで、許可の範囲は変えないと明記している。
Codexは、Git管理下のフォルダでは作業フォルダへの書き込みと必要時の承認を組み合わせた設定を勧め、既定ではネットワークに接続しない。GitHub Copilot cloud agentは、作業したプルリクエストを自分で承認もマージもできず、依頼した本人もそのプルリクエストを承認できない。
製品の再編も続いている。GitHubはエージェントの名前をcoding agentからcloud agentに改めた。AWSは2026年4月30日、Amazon Q DeveloperのIDEプラグインと有料プランのサポートを2027年4月30日で終えると発表し、移行先としてKiroを案内している。
なお、各ツールで使う指示書の書き方は、AGENTS.mdという共通の形式に寄ってきている。AGENTS.mdはOpenAIが作り、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈された。公式サイトによると6万以上のオープンソースのプロジェクトで使われ、Codex、GitHub Copilot、Gemini CLI、Cursorなどが対応している。
生産性の研究結果は割れている
AI駆動開発の効果は、測り方によって結果が分かれる。導入の判断では、体感の数字と実測の数字を分けて読む必要がある。
| 調査 | 対象 | 主な結果 |
|---|---|---|
| METR（2025年7月） | 経験のあるオープンソースの開発者16人、246件の課題 | AIを使うと作業時間が19%長くなった。事前の予想は24%短縮、終了後の体感も20%短縮 |
| METR（2026年2月の追試） | 57人、800件以上のタスク | 作業時間の短縮の推定が出た（元の参加者で18%、新しい参加者で4%）。ただし参加を見送る開発者が大きく増えたため、METR自身が現在の効果を示す信頼できる結果ではないとしている |
| DORA（Google、2025年9月） | 約5,000人の技術者 | 90%がAIを仕事で使い、80%超が生産性が上がったと考えている。30%はAIが生成したコードをほとんど、または全く信頼していない |
| Stack Overflow開発者調査（2025年） | 開発者 | 84%がAIを使っているか使う予定。正確さを信頼しない人が46%で、信頼する人の33%を上回る。66%が「ほぼ正しいが完全ではない」出力に不満を持つ |
METRの2025年の実験は、使われたツールが当時のものであり、METR自身がページ上で結果は古くなったと注記している。それでも、本人の体感と実測が逆向きにずれた点は、導入の評価方法を考えるうえで今も参考になる。
DORAの2025年の報告書は、AIはチームを直すのではなく、すでにある長所と短所を増幅すると結論づけた。あわせて、AIの効果を引き出す7つの能力として、明確に伝えられたAIの方針、健全なデータの基盤、AIが使える社内データ、強いバージョン管理、小さな単位での作業、利用者中心の姿勢、質の高い社内プラットフォームを挙げている。テストやレビューの仕組みが弱いチームにエージェントを入れると、弱さも大きくなる。
企業で使うときに起きやすい問題
コーディングエージェントは、ファイルを読み、コマンドを実行し、外部と通信できる。人が1件ずつ確かめない分、問題が起きたときの影響が広がりやすい。
| 問題 | 起きること | 一次資料での報告 |
|---|---|---|
| 指示の乗っ取り（プロンプトインジェクション） | Issue、README、依存パッケージの中に書かれた指示にエージェントが従う | Invariant Labsは2025年5月、公開リポジトリの悪意あるIssueを読ませることで、エージェントに非公開リポジトリの情報を公開のプルリクエストへ書き出させられると報告した |
| 存在しないパッケージ | AIが実在しないパッケージ名を書き、攻撃者が同じ名前で悪意あるパッケージを公開する | 2025年のUSENIX Securityの論文は、16のモデルで57万6,000件のコードを生成し、コードが参照したパッケージのうち存在しないものの割合が、平均で商用モデルは5.2%以上、オープンソースのモデルは21.7%以上だったと報告した |
| 秘密情報の読み取り | .envや鍵ファイルをエージェントが読み、ログや外部への通信に出る | Claude Codeの公式ドキュメントは、.envなどの読み取りを拒否するルールの例を示している |
| レビューの詰まり | 変更の量が増え、レビューが追いつかず、読まずに通す変更が出る | DORAは、AIが既存の弱さも増幅すると指摘している |
| 個人契約での利用 | 会社が把握しない個人のアカウントで社内のコードを扱う | Anthropicは、Team・Enterprise・APIなど商用の規約の下ではコードやプロンプトを学習に使わないとしている。個人向けプランでは利用者の選択で扱いが変わる |
OWASPは2025年12月、エージェント型のAIに固有のリスクを10項目にまとめた「Top 10 for Agentic Applications」を公開した。目的の乗っ取り、ツールの誤用、権限の濫用、想定外のコード実行などが並び、コーディングエージェントにもそのまま当てはまる。国内では、AIセーフティ・インスティテュート（AISI）が2026年7月の「AIセーフティに関する評価観点ガイド」第1.20版で、AIエージェントの普及を踏まえて評価の観点を更新した。
企業導入で決める5つの設計
ここからは、コーディングエージェントを企業で使うときに先に決めておく5つの設計を、編集部の設計例として示す。
1. 任せる範囲を決める
最初に、どのリポジトリのどの作業をエージェントに任せるかを決める。全社に一度に開放すると、問題が起きたときに原因を絞れない。
| 区分 | 作業の例 | 扱い |
|---|---|---|
| 任せやすい | テストの追加、小さな不具合の修正、ドキュメントの更新、型やlintのエラーの解消 | パイロットの対象にする |
| 条件付き | 機能の追加、リファクタリング、ライブラリの更新 | 仕様と受け入れ条件を書いてから任せる |
| 当面は任せない | 認証、決済、個人情報を扱う処理、本番の設定 | 人が書き、エージェントは調査と説明だけに使う |
2. 権限と実行環境を決める
次に、エージェントが動く環境と、確認なしで実行できる操作の範囲を決める。開発者のPCで動く型では、サンドボックスとネットワークの制限を使い、.envや鍵ファイルの読み取りを拒否する。Claude CodeやCodexには、管理者が配布し利用者が上書きできない設定があり、確認なしで実行するモードの禁止もここで行う。
クラウドで動く型では、エージェントが使える認証情報と通信先を確かめる。GitHub Copilot cloud agentは、インターネットへの接続をファイアウォールで制限し、書き込めるブランチを1つに限っている。社内の環境で同じことをするなら、エージェント用のアカウントに最小の権限だけを与える。
3. リポジトリに指示書を置く
エージェントは、リポジトリに置いた指示書を読んで作業する。AGENTS.mdやCLAUDE.mdに、ビルドとテストのコマンド、コードの規約、触ってはいけないディレクトリを書くと、出てくる変更がそろう。Codexは、リポジトリのルートから作業中のフォルダまでのAGENTS.mdを順に読み、深い階層のものを優先する。
ただし、指示書は強制力を持たない。Claude Codeの公式ドキュメントは、確実に止めたい操作は権限のルールや操作の前に処理を挟むhooksで止めるよう求めている。「本番のデータベースに接続しない」は指示書に書くだけでなく、設定で接続できなくする。
4. 検証の関門を持つ
エージェントの変更は、人が書いた変更と同じかそれ以上に確かめる。テスト、型チェック、lint、セキュリティの検査をCIで必ず通し、依存パッケージを追加した変更では、そのパッケージが実在し信頼できるかを確かめる。
レビューとマージは人が持つ。GitHub Copilot cloud agentは、エージェントが自分でマージできず、依頼した本人も承認できない作りになっている。社内のルールでも、依頼した人とは別の人がレビューしてマージする形にすると、読まずに通す変更を減らせる。
5. 計測して育てる
効果は体感ではなく、開発の指標で測る。METRの実験が示したとおり、本人の感覚は実測と逆向きにずれることがある。導入前後で、変更のリードタイム、レビューにかかる時間、マージ後の手戻りや障害の件数を比べる。
使い方の差も大きい。仕様の書き方、任せる単位の切り方、レビューで見る点がそろっていないと、同じツールでも人によって成果が大きく変わる。研修で基本の使い方をそろえ、うまくいった指示書や設定をチームで共有する。
導入の進め方
5つの設計を踏まえた進め方の例を示す。期間は、開発チームが数チームの企業を想定した目安である。
| 段階 | 期間の目安 | やること |
|---|---|---|
| 1. 方針と対象を決める | 2週間 | 使うツールと契約（商用プラン）、任せる範囲、禁止する操作を決める。現場での個人利用の実態を調べる |
| 2. パイロット | 4〜6週間 | 1〜2チームで、任せやすい作業から始める。指示書と設定のひな形を作り、導入前の指標を測っておく |
| 3. 標準化 | 4週間 | 管理者の設定を配布し、CIの関門とレビューのルールを全リポジトリにそろえる。研修で使い方をそろえる |
| 4. 展開と見直し | 継続 | 対象のチームと作業を広げ、四半期ごとに指標と設定を見直す |
FDXの支援
FDXはAX（AI Transformation）の実装パートナーとして、業務の分解から実装・現場定着・運用移管までを対応領域とする。AI駆動開発では、ツールを配って終わりにせず、任せ方と確かめ方をチームの標準として残すことを重視する。
- Claude Code 実践研修（エンジニア向け）：Claude Code・Cursor・GitHub Copilotを組み合わせ、設計・実装・テスト・レビューをAI駆動で回す実践研修。社内のコード規約とガードレールの設計まで扱う
- 生成AI活用研修（エンジニア基礎）：コード生成・デバッグ・レビューをAIで回す基礎を、ハンズオン中心で学ぶ
- Claude Code 活用研修（非エンジニア向け）：エンジニアのいない部署で、業務の自動化を自分たちで作れるようにする
- 1Day FDE：FDE（Forward Deployed Engineer）が週1日常駐し、午前はツールの設定や自動化を現場の隣で実装し、午後は運用手順を現場に引き継ぐ
どのチームから始めるべきかを相談したい場合はお問い合わせから、まず自社の状況を確かめたい場合はAX診断からどうぞ。
よくある質問（FAQ）
Q1. AI駆動開発とは何か？
A. コーディングエージェントに、コードの調査・編集・コマンド実行・テストをまとめて任せ、人が仕様とレビュー、マージの判断を持つ開発の進め方である。標準化団体や政府による公式の定義はなく、日本で広く使われる呼び方である。AWSはAI-DLC、GitHubやAWSは仕様駆動開発という名前で、近い進め方を示している。
Q2. 仕様駆動開発との違いは？
A. 仕様駆動開発は、AI駆動開発の中の進め方の一つである。何をなぜ作るかを仕様書に書き、そこから計画・タスク・コードへ落とす。仕様がファイルとして残るため、レビューや引き継ぎがしやすく、業務の開発に向いている。
Q3. バイブコーディングは業務で使えるか？
A. 業務の開発には向かない。バイブコーディングは、Andrej Karpathy氏が2025年2月に投稿した言葉で、生成されたコードを読まずに受け入れるやり方を指す。本人も週末の使い捨てプロジェクト向けと限定している。業務では、仕様を書き、変更をレビューしてから取り込む。
Q4. AI駆動開発で開発は速くなるのか？
A. 条件による。METRの2025年の実験では、経験のある開発者の作業時間がAIを使うと19%長くなり、本人は20%速くなったと感じていた。DORAの2025年の報告書は、AIはチームの長所も短所も増幅すると結論づけている。テストとレビューの仕組みを整え、体感ではなくリードタイムや手戻りで効果を測る。
Q5. コーディングエージェントのセキュリティ上の注意点は？
A. エージェントはファイルを読み、コマンドを実行し、外部と通信できるため、指示の乗っ取り、秘密情報の読み取り、存在しないパッケージの取り込みに注意する。サンドボックスとネットワークの制限を使い、.envなどの読み取りを拒否し、依存パッケージの追加は人が確かめる。会社の商用プランで契約し、個人のアカウントで社内のコードを扱わせない。
Q6. AGENTS.mdとは何か？
A. コーディングエージェントに、ビルドやテストのコマンド、コードの規約を伝えるための共通の指示書の形式である。OpenAIが作り、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈された。Codex、GitHub Copilot、Gemini CLI、Cursorなどが対応している。指示書は強制力を持たないため、確実に止めたい操作は各ツールの権限の設定で止める。
次に読むべき記事
- MCPとは？MCPサーバーの仕組みと企業導入の権限設計：エージェントを社内システムにつなぐ規格と権限の決め方
- ループエンジニアリング入門｜自律エージェントを動かし続けるハーネス設計の体系：エージェントを止める条件と検証の階層
- AIエージェントとは？開発方法と企業導入の5ステップ：業務で使うエージェントの構成
- AIガバナンスと実装セキュリティ｜6つの制御点：権限・入力の信頼境界・監査ログの全社設計
- シャドーAI対策｜禁止だけで防げない理由と4つの制御点：個人契約のAIツールの利用を減らす方法
まとめ
- AI駆動開発は、コーディングエージェントに実装・テスト・修正を任せ、人が仕様とレビュー、マージの判断を持つ開発の進め方である
- 仕様駆動開発はその中の進め方の一つで、仕様が残るため業務に向く。バイブコーディングは業務の開発には向かない
- 主要なツールは、サンドボックス、承認の段階、利用者が上書きできない管理者の設定を備える。使うかどうかは導入する企業が決める
- 生産性の研究結果は割れている。体感と実測がずれるため、リードタイムや手戻りで効果を測る
- 企業では、任せる範囲、権限と実行環境、リポジトリの指示書、検証の関門、計測と育成の5点を先に決める
- 指示書は強制力を持たない。止めたい操作は設定で止め、レビューとマージは依頼した人とは別の人が持つ
出典・参考文献
- AWS「Coding agents（AWS Prescriptive Guidance）」（コーディングエージェントの説明。2026年11月5日確認）
- AWS DevOps Blog「AI-Driven Development Life Cycle: Reimagining Software Engineering」（2025年7月31日。AI-DLCの考え方）
- GitHub「Spec Kit」（仕様駆動開発の説明。2026年11月5日確認）
- Kiro「Specs」（requirements.md、design.md、tasks.mdの3つのファイル。2026年11月5日確認）
- Andrej Karpathy「X（旧Twitter）への投稿」（2025年2月2日。バイブコーディングという言葉の初出）
- Anthropic「Configure permissions（Claude Code Docs）」（権限のモード、拒否・確認・許可の評価順、管理者の設定、CLAUDE.mdは許可の範囲を変えないこと。2026年11月5日確認）
- Anthropic「Sandboxing（Claude Code Docs）」（サンドボックスの範囲と既定の設定。2026年11月5日確認）
- Anthropic「Data usage（Claude Code Docs）」（商用の規約での学習への不使用とデータの保持期間。2026年11月5日確認）
- OpenAI「Agent approvals & security（Codex）」（サンドボックスの3段階、承認のポリシー、既定でネットワーク接続なし、管理者の設定。2026年11月5日確認）
- OpenAI「AGENTS.md（Codex）」（AGENTS.mdを読む順序。2026年11月5日確認）
- GitHub Docs「Risks and mitigations for GitHub Copilot cloud agent」（起動できる利用者、書き込めるブランチ、承認とマージの制限、ワークフローの承認、ファイアウォール。2026年11月5日確認）
- AWS DevOps Blog「Amazon Q Developer end of support announcement」（2026年4月30日。IDEプラグインと有料プランのサポート終了、Kiroへの移行）
- AGENTS.md「AGENTS.md」（Agentic AI Foundationによる管理、利用プロジェクト数、対応ツール。2026年11月5日確認）
- Linux Foundation「Linux Foundation Announces the Formation of the Agentic AI Foundation」（2025年12月9日。MCP、goose、AGENTS.mdの寄贈）
- METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025年7月10日）
- METR「We are Changing our Developer Productivity Experiment Design」（2026年2月24日。追試の結果と選択の偏り）
- Google Cloud Blog「Announcing the 2025 DORA Report」（2025年9月）
- Google Cloud Blog「Introducing the DORA AI Capabilities Model: 7 keys to succeeding in AI-assisted software development」（2025年9月。7つの能力）
- Stack Overflow「2025 Developer Survey: AI」（AIの利用率と信頼。2026年11月5日確認）
- Invariant Labs「GitHub MCP Exploited: Accessing private repositories via MCP」（2025年5月26日）
- Joseph Spracklen ほか「We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs」（USENIX Security 2025）
- OWASP GenAI Security Project「OWASP Top 10 for Agentic Applications」（2025年12月9日）
- AIセーフティ・インスティテュート「AIセーフティに関する評価観点ガイド」（第1.20版、2026年7月7日。AIエージェントの普及を踏まえた更新）
※ 英語資料からの引用・要約は編集部による翻訳である。5つの設計、任せる範囲の区分表、導入の進め方の表は、公開情報を踏まえた編集部の設計例であり、特定の製品の機能を保証するものではない。各製品の名前と機能は変わるため、導入時に公式ドキュメントで確認されたい。