第5章 Level 3：監督付き自律実行型 ── AIが動き、人間が確認する
Level 2 との断絶
Level 2と3の間には設計上の大きな断絶がある。
Level 2では、AIが「提案」するだけで、「実行」は人間が行う。コードの変更はユーザーがApplyを押して初めて適用される。メールの下書きはユーザーが送信ボタンを押して初めて送られる。
Level 3では、AIが自ら実行する。ファイルを変更し、コマンドを実行し、PRを作成し、APIを呼び出す。ユーザーはタスクを開始するときと、結果を確認するときに関与するが、実行の過程には介在しない。
Level 2：
ユーザー → 指示 → AI生成 → ユーザー承認 → 実行
Level 3：
ユーザー → 計画承認 → AI自律実行 → ユーザー結果確認
↑
（この間ユーザーは離席可能）この変化は「信頼の性質」を変える。Level 2では「この提案は正しそうか」を判断すればよかった。Level 3では「このエージェントにこのタスクを任せてよいか」というより大きな信頼の判断が必要になる。
代表的なプロダクト
Claude Code（Anthropic）
コンセプト：自然言語でタスクを指示すると、AIがコードベースを探索・理解し、コードの変更・テスト実行・コミット・PRの作成までを自律的に行う。
AIの動き：
- ユーザーから「このAPIエンドポイントにレート制限を追加して」という指示を受ける
- AIが既存コードを読み込み、どこを変更すべきかを自律的に判断
- ファイルを変更し、テストを実行し、失敗すれば修正
- ユーザーに結果を報告（変更されたファイル・テスト結果・コミットメッセージ）
- ユーザーが確認し、問題なければマージ
生み出す価値：
- 「コードを書く」から「何を作るか定義する」へのエンジニアの役割シフト
- Context Engineeringとハーネスの組み合わせで、タスクの品質と予測可能性が向上
- 反復的なタスク（テスト追加・リファクタリング・型修正）の自動化
設計の工夫：
- Plan Modeで「どのファイルを・どう変更するか」を実行前にユーザーが確認できる
- フックによる自動検証（型チェック・Lint・テスト）をエラーのみ表面化
CLAUDE.mdでプロジェクト固有のルール・過去の失敗記録を注入する
Devin（Cognition AI）
コンセプト：「最初のAIソフトウェアエンジニア」を標榜する。GitHubのIssueやLinearのチケットをアサインすると、独立したサンドボックス環境の中でコードを書き・テストし・PRを開く。
AIの動き：
- Slackで「@Devin このバグを直して」とメンションする（あるいはGitHub Issueをアサイン）
- DevinがGitリポジトリをクローンし、独立したVM環境で作業を開始
- ブラウザでドキュメントを調べたり、コマンドを実行したり、コードを書いたりしながら問題に取り組む
- PRを作成し、Slackで作業完了を報告
- エンジニアがPRをレビューしてマージ
生み出す価値：
- 人間エンジニアが「タスクキュー」ではなく「アーキテクチャとレビュー」に集中できる
- 24時間稼働（人間が離席中でもDevinが作業を続ける）
- 並列実行（複数のDevinが異なるタスクを同時進行できる）
設計の工夫：
- 完全に隔離されたVM環境（本番環境への直接アクセスを持たない）
- 作業ログの透明性（何をしたかをSlackに随時報告）
- 「Cursor は信頼を曝露によって構築し、Devin は信頼を委任によって構築する」という対比がよく語られる
GitHub Copilot Coding Agent（GitHub）
コンセプト：GitHubのIssueにCopilotをアサインすると、コードを書いてPRを作成する。エンジニアのワークフロー（Issue → PR）に完全に統合された自律エージェント。
AIの動き：
@copilotをメンションするか、IssueにCopilotをアサイン- Copilotが隔離されたクラウド環境でリポジトリをクローンし作業
- 変更をcommitし、PRを開く。PRにはCopilotが変更した内容の説明が添付
- 既存のCI/CDパイプラインが自動実行される
- エンジニアがレビューしてApproveまたは修正依頼
生み出す価値：
- Issue → PRの時間を数時間から数分に短縮（単純なバグ修正・機能追加で）
- エンジニアの集中作業を中断させない（バックグラウンドで動く）
設計の工夫：
- 既存のCIパイプラインをそのままガードレールとして活用（テストが落ちればCopilotも気づく）
- PRのdescriptionに「何を変更したか・なぜ変更したか」を自動生成
- Allowed toolsリストを短く保つ（アクセス可能なツールを最小化する最小権限原則）
- ポリシー変更はアプリケーション変更と同様にPR・レビュー・テストのプロセスを踏む
Salesforce Agentforce（Salesforce）
コンセプト：CRMデータを文脈としたエージェントプラットフォーム。営業・サポート・マーケティング業務の特定プロセスをエージェントが自律実行する。
AIの動き：
- 見込み顧客のスコアリングと優先度付けを自動実行
- カスタマーサポートの問い合わせに対してCRMデータを参照しながら回答
- 複数ステップの承認フローを自動でルーティング
- フィールドサービスの自動スケジューリング
事例：
- Salesforce社内での試験運用：380,000件の顧客インタラクションを処理し、84%を自律解決、人間エスカレーションは2%のみ
- 導入企業でのチャーン率47%削減、展開速度67%向上
設計の工夫：
- 「Atlas Reasoning Engine」：一般的なLLMにCRMドメイン知識を深く組み込んだ推論エンジン
- Agent Builder：ノーコードでエージェントの「仕事の定義・トピック・アクションライブラリ」を設定
- ガードレール：人間の承認が必要なアクション・絶対に実行しないアクションを明示的に設定
- Salesforce Data Cloudとの統合：リアルタイムデータからの推論
Level 3 の設計原則
原則1：計画と実行を分離し、計画に人間の承認を挟む
Level 3の最大のリスクは「意図しない実行」だ。「〇〇して」という指示が、開発者が意図した範囲を超えてファイルを変更したり、予期しないAPIを呼び出したりする。
これを防ぐ最も効果的な設計は計画フェーズの分離だ。
sequenceDiagram
participant U as ユーザー
participant A as エージェント
U->>A: 高レベルの指示
A->>U: 実行計画（変更するファイル・実行コマンドの一覧）
U->>A: 承認（または修正指示）
A->>A: 自律実行（実行中はユーザー離席可能）
A->>U: 結果報告
U->>U: 結果を確認・承認・修正依頼Claude Codeの --plan フラグ、Devinのセッション開始時の計画表示、GitHub Copilot AgentのPR作成前の確認——いずれも同じパターンの実装だ。
原則2：実行環境の隔離（サンドボックス化）
エージェントが本番データベースを誤って削除したり、本番APIに意図しないリクエストを送ったりすることを防ぐには、実行環境の隔離が必要だ。
| 隔離の手法 | 説明 | 使用例 |
|---|---|---|
| 読み取り専用モード | 変更系操作を禁止 | 調査・分析タスク |
| VM/コンテナ隔離 | 独立した環境でのみ実行 | Devin、GitHub Copilot Agent |
| Dryrun モード | 実行予定の変更を事前に確認 | インフラ変更タスク |
| スコープ制限 | アクセスできるファイル・APIを限定 | 特定モジュールのみ変更 |
原則3：観測可能性（Observability）の確保
エージェントが「何をしたか」「なぜそうしたか」を後から検証できる仕組みが必要だ。
- ステップログ：エージェントの各アクション（ファイルを読んだ・コマンドを実行した・APIを呼んだ）を記録
- 判断の根拠：なぜそのファイルを変更したか、なぜそのコマンドを選んだかの説明
- 変更サマリー：タスク完了後に「何が変わったか」を人間に理解可能な形で提示
GitHubのCopilot AgentがPRに詳細な説明を自動生成するのは、この観測可能性の設計だ。
原則4：最小権限原則
エージェントは「タスクを完了するために必要な最小限の権限」のみを持つべきだ。コードを書くエージェントが顧客DBへのアクセス権を持つ必要はない。
権限の設計例
✅ コーディングエージェントが持つべき権限
- リポジトリの読み書き
- テスト実行
- ブランチ・PR作成
❌ コーディングエージェントが持つべきでない権限
- 本番データベースへの直接アクセス
- 外部APIへの書き込み（Webhookのトリガー等）
- 他ユーザーの認証情報へのアクセスLevel 3 の価値生成メカニズムと限界
Level 3の価値は「速度と並列性」だ。人間が1タスクに集中しているとき、エージェントは複数のタスクを並列で進められる。さらに人間が不在の時間帯（深夜・週末）にも作業を継続できる。
しかし限界もある。ブラウンフィールド問題と呼ばれるものだ。テストカバレッジが低く、アーキテクチャが不明確で、ドキュメントがないレガシーコードベースでは、エージェントは頻繁に迷子になる。Level 3の成功事例の多くはグリーンフィールドプロジェクトか、しっかりしたハーネスを持つコードベースからきている。
次章では、Level 3がさらに進んで「人間の常時監視なし」で動くLevel 4に移る。