AI駆動開発はどこまで任せる？エージェントの仕組みと権限・レビュー

開発チームを率いる立場なら、まずは分離したブランチで範囲を絞ったタスクを任せ、明確な受け入れ基準、自動チェック、担当レビュアーを用意するのが現実的です。この手順で安心して受け入れられる変更が得られるようになったら、自律的に任せる範囲を広げます。

以下で紹介するツールの動作は、2026年10月24日に各開発元の公開ドキュメントで確認したものです。委任の基準と請求書エクスポートの例は、編集部による分析であり、製品を試用して得た結果ではありません。

AI駆動開発におけるエージェント型コーディングとは？

エージェント型コーディングとは、各操作の結果を次の判断に反映しながら、一連の開発作業をAIシステムに任せることです。 コードベースの調査、変更計画の作成、ファイルの編集、コマンドやテストの実行を行い、その結果を読み取って次の行動を調整します。処理が完了したときだけでなく、権限の境界に達したときや、人の判断が必要になったときにも作業は止まります。

Anthropicは、この基本サイクルを「コンテキストの収集、実行、検証」と説明しています。肝になるのは、ツールの実行結果を次の判断に戻すことです。テストの失敗は、次の修正を考えるための根拠になります。コードブロックを提案するだけでは、このループは成立しません。Claude Codeのエージェントループ。

部屋の改装を業者に頼む場面を考えてみてください。依頼内容は完成形を示し、渡す鍵は立ち入れる範囲を決め、検査は仕上がりを受け入れるかどうかを決めます。鍵を多く渡しても、改装が正しく仕上がるとは限りません。コーディングエージェントでも、指示、アクセス権、検証を同じように分ける必要があります。

エージェントにはハーネスも必要です。モデルの周囲で動き、ツールを提供し、作業に必要なコンテキストを管理するソフトウェアを指します。モデルが行動を提案し、ハーネスが許可されたツール呼び出しを実行して、その結果を返します。モデルを変えても、環境のアクセス規則が自動的に変わるわけではありません。

コーディングエージェントは補完やチャットと何が違う？

違いは、作業を次のステップへ進めるのが誰かという点にあります。コード補完は、編集中にテキストを提案します。通常のチャットはコードの説明やパッチの提案ができますが、コピー、実行、検証は人が行います。リポジトリとコマンドへのアクセス権を持つエージェントなら、それらを実行し、何が起きたかまで調べられます。

見た目のインターフェースで決まるわけではありません。チャット画面でもターミナルでも、エージェントは動作します。確認すべきなのは、使えるツール、結果を次に反映するループ、そのセッションに与えられた権限です。

エージェント型コーディングとバイブコーディングの違い

エージェント型コーディングは、ツールがどう動くかを表す言葉です。一方、バイブコーディングは一般に、プロンプトと目に見える動作を中心に、生成されるソフトウェアを調整していく進め方を指します。実装をほとんど確認しない場合もあります。実際の作業では重なり合いますが、それぞれが説明している側面は異なります。

すべての変更をレビューし、厳密なテストを維持しながらエージェントを使うこともできます。生成されたコードをほぼ確認せずに受け入れることもできます。使い捨てのプロトタイプなら、後者を意識的に選ぶ余地はあるでしょう。ただし、顧客データや決済を扱うなら、実装を理解することも、そのソフトウェアに責任を持つうえで欠かせません。開発ツールやアプリビルダーの全体像は、バイブコーディングツールのガイドで紹介しています。

AIプログラミングでコーディングエージェントにできること

主要ツールは、異なる作業環境から、おおむね共通した実行ループを提供しています。 ドキュメントに記載された機能からは、どの作業を任せられるかが分かります。しかし、自分のリポジトリで、どこまで人の監督なしに進めてよいかまでは分かりません。

Claude Code

Anthropicのコーディングエージェントである**Claude Code**は、プロジェクトの検索、ファイルの読み取りと編集、コマンドやテストの実行ができます。ドキュメントでは、ツールの実行結果から得た情報に応じて進め方を変えるループが説明されています。そのため、対象を絞ったバグ修正は任せやすいタスクです。失敗の原因を調べ、該当するコードを変更し、動作を検証するという流れです。Claude Codeのドキュメント。

実務で壁になるのは、必要なコンテキストが欠けたり、保持されなくなったりすることです。Anthropicは、コンテキストウィンドウに上限があり、長いセッションでは圧縮が行われると説明しています。継続して守るべき制約はプロジェクトの指示に残し、個々の変更は対象を絞ってください。長い会話を続けても、受け入れ基準の代わりにはなりません。この進め方は、Claude Codeのベストプラクティスで詳しく解説しています。

OpenAI Codex

OpenAIのコーディングエージェントである**OpenAI Codex**には、リポジトリの調査、変更計画の作成、ファイルの編集、ローカル開発コマンドの実行ができるコマンドラインインターフェース（CLI）があります。未コミットの変更、特定のコミット、ベースブランチとの差分を対象にした、専用のレビューフローも備えています。Codex CLIのドキュメント。

実務で壁になるのは、実行環境です。必要なサービスが使えなかったり、ネットワークアクセスが遮断されていたりすると、予定していたチェックでは必要な根拠を得られません。そのチェックは未検証として記録し、適切な環境で再実行してください。製品選びについてはCodexとClaude Codeの比較で扱っていますが、権限設定はそれとは別に判断する必要があります。

Cursor Agent

Cursor Agentは、Cursorのエディターに組み込まれたコーディングエージェントです。コードベースの検索、ファイルの編集、ターミナルコマンドの実行ができます。作業内容を確認しながら変更の方向性を指示する、対話的な進め方に向いています。これらはドキュメントに記載された操作であり、機能が正しく仕上がるという保証ではありません。Cursor Agentの概要。

編集時に何が許可されているかを理解しておく必要があります。通常のワークスペース内の編集は承認なしでディスクに保存されますが、設定ファイルの変更には追加の保護が設けられています。Cursorは、自動リロードを行うアプリでは、レビューする前に編集済みコードが実行される可能性があると警告しています。その動作を前提に、認証情報やデータが適切に制限された開発環境を使ってください。Cursor Agentのセキュリティ。

GitHub Copilotのコーディングエージェント

GitHub Copilotのコーディングエージェントは、現在のドキュメントではCopilot cloud agentと呼ばれています。一時的なクラウド環境でリポジトリを調査し、変更を計画し、ファイルを編集して、テストやリンターを実行できます。ブランチ、コミット、プルリクエストの作成も可能です。IDE内で提案を受け取ることや、既存のプルリクエストをCopilotにレビューしてもらうこととは異なります。GitHub.comでのCopilot。

実務で壁になるのは、成果を受け取る段階です。GitHubは、生成された変更には誤りやセキュリティ上の問題が含まれる可能性があり、レビューとテストが必要だと警告しています。セッションの完了は、評価すべき成果物ができたことを意味します。受け入れ基準を満たしたことまでは意味しません。GitHubによる責任ある利用のガイダンス。

プランの詳細は、Claude Codeの料金、Codexの料金、Cursorの料金、GitHub Copilotの料金をご覧ください。

エージェントに任せる開発は、検証できる仕様から始める

役に立つ仕様は、何を変えるかと同時に、何を変えてはいけないかも伝えます。 「CSVエクスポートを追加する」だけでは、重要な判断が残ったままです。エージェントは、ダウンロード自体は動くものの、アクセス制御が間違っている機能を作ってしまうかもしれません。

複数の顧客組織がそれぞれ利用する、架空の請求管理サービスを考えてみます。アカウント管理者が請求書をエクスポートできるようにしたいとします。有用な作業指示には、次の内容を含めます。

• 達成したいこと： 権限を持つ管理者が、現在のフィルターで表示される請求書をダウンロードできるようにします。
• アクセス規則： リクエストを改ざんした場合も含め、ある組織が別の組織の請求書を取得できてはいけません。
• 維持する動作： 既存の請求書に関する権限とフィルタリングのルールを引き続き適用します。
• 作業範囲： 既存の認可とエクスポートの実装規約を再利用し、無関係なリファクタリングや依存関係の追加は避けます。
• 検証の根拠： 許可されるケースと拒否されるケース、別組織へのアクセス試行、結果が空になるケース、関連する既存チェックの結果を示します。
• 停止条件： アクセスポリシーが曖昧な場合や、修正に共通の認可処理の変更が必要な場合は、人の判断を求めます。

この指示なら、実装方法には選択の余地を残しながら、製品として満たすべき条件を固定できます。作業中に未定義のルールが見つかったら、判断を下して仕様を更新します。偶然そう実装されたという理由で、それを暗黙のポリシーにしてはいけません。この関係を維持する方法は、仕様駆動開発のガイドで解説しています。

Anthropicのベストプラクティスのドキュメントは、エージェントが自分の作業を検証できる手段を用意するよう勧めています。Armin Ronacherも、実践者としての提言で、高速で理解しやすいツールと役立つログを重視しています。運用上の要点は、失敗を観測できるようにすることです。内容が読み取れる認可エラーは修正の手がかりになりますが、応答しないまま止まったコマンドからは、進む方向をほとんど判断できません。

権限設定とサンドボックスは、それぞれ何を制限する？

権限設定は許される操作を、サンドボックスは操作が及ぶ範囲を、ブランチとレビューのルールは変更を受け入れる条件を定めます。 すべてを設定してください。「本番環境に触れないで」とプロンプトに書いても、本番環境へのアクセス権を与えないことの代わりにはなりません。

承認ポリシーは、どの操作に承認が必要かを決めます。サンドボックスは、書き込み可能なファイルや外向きのネットワークアクセスなどのリソースに対して、強制力のある実行境界を設けます。どちらも、請求書エクスポートが業務ルールに従っているかを評価するものではありません。

ツールごとに、実際に有効な設定を確認する

Claude Codeについて、Anthropicは、サンドボックス内のコマンドとその子プロセスを対象に、ファイルシステムとネットワークを隔離すると説明しています。一方で、サンドボックス外で再試行する仕組みも記載されています。この境界を必ず守られるものとして扱う前に、境界の外へ出る仕組み、除外対象のコマンド、サンドボックスを起動できなかった場合の動作を確認してください。書き込みを制限しただけで、機密ファイルの読み取りまで防げるわけではありません。Claude Codeのサンドボックス。

Codex CLIでは、workspace-writeとon-request承認を組み合わせると、ワークスペース内で作業できる一方、コマンドからのネットワークアクセスは明示的に有効にしない限り、デフォルトで無効です。承認ポリシーとサンドボックスモードは別々の設定であり、承認を求める表示を無効にしても、それだけでサンドボックスが解除されるわけではありません。また、コマンドのネットワークポリシーだけでは、ホスト側で実行されるWeb検索、アプリ、MCP接続を制御できません。これらはエージェントを外部のツールやサービスにつなぐ経路なので、個別にアクセス設定を確認してください。Codexの承認とセキュリティ。

Cursor Agentでは、ターミナルコマンドはデフォルトで承認が必要です。一方、設定可能なRun Modesは、厳格なセキュリティ境界ではなく、ベストエフォートの保護策として説明されています。コマンドを無人で実行させるつもりなら、この違いは重要です。ターミナルでの実行に加えて、前述の自動リロードに関する注意点も考慮してください。Cursor Agentのセキュリティ。

GitHub Copilot cloud agentについて、GitHubは、デフォルトブランチへの直接プッシュを防ぐブランチ権限の制限を説明しています。デフォルトのファイアウォールもあり、エージェントのプルリクエストによって起動するActionsワークフローは、実行前に書き込み権限を持つユーザーの承認が必要です。リポジトリや組織の一般的なActionsシークレットはエージェントに渡されませんが、copilot環境に明示的に追加したシークレットは渡されます。そこに何を設定するかを確認してください。GitHubが説明する保護策。

タスクに必要な範囲にアクセスを絞る

請求書エクスポートの作業で必要なのは、ソースコード、開発用の依存関係、合成した請求書レコードです。実際の顧客の請求書、本番データベースの認証情報、デプロイ権限は必要ないはずです。動作の再現と検証に必要な、最小限のリソースアクセスを与えてください。

リポジトリ内の文章、取得したページ、Issueの内容は、信頼できない入力かもしれないものとして扱います。プロンプトインジェクションとは、悪意のある内容がエージェントの行動を別の方向へ誘導しようとすることです。文書に隠された指示が、作業指示と同じ権威を持ってはいけません。開発元のセキュリティガイダンスもこのリスクを挙げています。アクセス可能なリソースを絞れば、起こりうる被害を抑えられます。Cursorのセキュリティモデル。

レビューでは差分と検証の根拠を確認する

変更された動作と、その正しさを示すとされるチェックをレビューしてください。 エージェントの要約は全体像をつかむのに役立ちますが、承認する対象は要約そのものではありません。

まず、受け入れ基準から確認します。請求書エクスポートなら、リクエストの所属組織をどう特定するか、認可をどう確認するか、エクスポート用クエリにも同じ境界がどう適用されるかを追います。そのうえでテストを確認してください。単一の組織のレコードしか使わないテストでは、組織間のデータ分離を証明できません。

次に、パッチによって検証の根拠が弱くなっていないかを調べます。アサーションの削除、新たにスキップされたテスト、モック範囲の拡大、スナップショットやCI設定の変更などです。テストがすべて成功するようになった理由は、実装が改善されたからかもしれませんし、チェックが緩くなったからかもしれません。どちらなのかは差分に表れます。

未コミットの変更があるリポジトリのチェックアウトでは、次のGitコマンドで基本的な確認ができます。

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git statusでは未追跡のファイルも分かりますが、その内容は別途確認する必要があります。これらのコマンドはアプリケーションのテストを実行しません。エージェントの作業がコミット済みなら、プルリクエストのベースから先端までの差分全体を確認し、クリーンな環境でリポジトリに記載されたチェックを実行してください。

役に立つ引き継ぎには、実行した正確なコマンド、その結果、成功や失敗を示す該当箇所の出力、実行できなかったチェックが含まれます。テストを特定せずに「テストは通りました」とだけ言われても、レビュアーは何が検証されたのか推測するしかありません。環境構築の失敗は、根拠を得るうえでの障害であり、コードが動くという根拠ではありません。

Drew Breunigは、エージェント型コーディングの10の教訓で、製品の動作を確かめるテスト、文書化された意図、実装とともに更新される仕様の重要性を説いています。この例に当てはめるなら、長く維持すべきチェックは、ある顧客が別の顧客の請求書をエクスポートできないことです。そのルールを実現するための個別のヘルパー関数は、変わっても構いません。

自動レビューから別の観点の指摘を得ることはできますが、変更を受け入れる人は、重要な処理の流れを理解している必要があります。GitHubは、AIレビューが問題を見落とす可能性も、問題のない箇所を誤って指摘する可能性もあると明示しています。セキュリティに関わる動作と保守性については、人のレビュアーが責任を持つ体制を維持してください。GitHubが説明するレビューの限界。

任せる範囲を広げてよいのは、どんなチーム？

成功条件が明確で、失敗の影響を抑えられ、レビューの負担も管理できるなら、任せる範囲を広げられます。 以下は開発チーム向けの運用方針の提案であり、ベンダーによる性能保証ではありません。

信頼できるCIを持つ開発チームのリーダーは、今から始められます。 既存のパターンに沿った変更から着手してください。エージェントが生成したプルリクエストには必ず責任者を割り当て、レビューで内容を追い切れなくなったらタスクを小さくします。チェックの成功が役に立つのは、重要な動作を検証できている場合だけです。

プロトタイプを作る創業者は、使い捨てにできる環境であれば、実装を積極的に任せられます。 合成データを使い、探索段階のコードはいずれ置き換える可能性を受け入れます。顧客アカウントや送金機能を追加する前には、アクセス規則、障害処理、運用への影響を評価できる人に見てもらってください。

十分に理解されていないレガシーシステムの保守担当者は、まず判断の根拠を整えるべきです。 エージェントは動作の調査やテストの提案を手伝えます。しかし、意図した動作と偶然の動作を誰も区別できない状況で、人の監督なしにリファクタリングを始めるのは適切ではありません。自律的に任せる範囲を広げる前に、変更前の状態を把握してください。

すでにコード補完で満足しているなら、すべての作業の進め方を変える必要はありません。 小さく明白な修正なら、自分で編集したほうが早いこともあります。調査、変更、検証という意味のある一連の作業をまとめて渡せるときに、委任にかかる手間が見合います。

どこで失敗する？過大評価されていることは？

正しい解決策と、それらしく見える解決策をフィードバックで区別できないとき、ループは機能しなくなります。 チェックの成功が確認しているのは整形だけで、顧客ごとのデータを分けるテナント分離については何も示していないかもしれません。モックを使ったテストが通っても、顧客が実際に使う連携部分の問題は見逃されることがあります。説得力のある要約から、失敗したコマンドが抜け落ちることもあります。

コンテキストにも限界があります。エージェントは関連する関数を見ていても、一見特殊な制約が設けられた理由を見落とすかもしれません。重要な判断は作業箇所の近くに残し、正として参照すべき仕様を明確にし、不確かな点は表に出すよう求めてください。Anthropicのドキュメントは、長いセッションで有限のコンテキストをどう管理するかを説明しています。会話の初めに伝えた指示が、大きな変更の最後まで同じように重視されるとは考えないほうがよいでしょう。Claude Codeの仕組み。

エージェントを増やすと、調整の仕事も増えます。別々のセッションが同じファイル、インターフェース、データベースの状態を変更すると、それぞれの環境では成功していても、別の変更と競合することがあります。チェックアウトを分け、統合の責任者を明確にしてください。密接に関係する実装を並列化する前に、独立した調査から並列化します。

さらに大きな失敗は、誰も保守するつもりのなかった複雑さを受け入れてしまうことです。新しい抽象化、依存関係、バックグラウンドジョブは、生成が簡単だったとしても、自分たちの運用責任になります。その変更は、タスクに見合った量の仕組みを追加するだけで問題を解決しているかを確認してください。

AIコーディングのベンチマークだけでは何が分からない？

コーディングのベンチマークだけでは、自分たちのチームの開発がどれだけ改善するかは分かりません。報告された結果を当てはめるには、タスク、リポジトリのコンテキスト、ツール、再試行の方針、成功の定義を理解する必要があります。ベンダーが示す生産性向上率は、自分たちのコードベースに対する予測値ではありません。

試験導入では、変更が受け入れられるまでの経過時間、レビュアーの作業量、手戻り、マージ後に見つかった不具合、作業が進められなくなった実行を記録してください。似た種類のタスク同士を比較し、失敗も記録に残します。これは測定方法の提案であり、ここで改善率を主張しているわけではありません。

レビュー負担や不具合が許容できないほど増えずに、受け入れられる変更を届けやすくなったら、委任の範囲を広げます。パッチの生成は速くなったのに、その内容を理解するのが難しくなったなら、範囲を狭めて検証の根拠を整えてください。

よくある質問

次の業務で、まず何から始める？

バックログから、動作を再現できる小さなIssueを選び、エージェントを動かす前にレビュアーを決めます。受け入れ基準を書き、分離した作業環境を用意し、本番環境の認証情報は渡しません。パッチと、その内容を評価するために必要な検証の根拠を求めてください。

レビュー後は、エージェントが処理できたこと、人が介入した箇所、足りなかったチェックを記録します。その記録を基に、次のタスクの範囲を決めます。検証の仕組みによって任せられると判断できた分だけ、自律性を高めてください。

AIを使った開発の実践的なノウハウは、ニュースレターでお届けしています。