TL;DR
AIエージェントへ作業を委任するときは、少なくとも次の4点を人間側に残します。
- 目的：なぜ実行するのか
- 合格条件：何をもって完了とするのか
- 証拠：何を根拠に結果を信頼するのか
- 停止条件：どの状態で人間へ戻すのか
AIが生成、実行、自己評価まで担当し、結果だけを人間が受け取る構成では、正常時の速度と引き換えに障害時の状況理解を失う可能性があります。
この記事は実装や性能の実測記事ではありません。Anthropicの公開資料をもとに、AIエージェント運用の設計観点を整理したものです。未検証のコード、コマンド、ベンチマークは追加していません。
対象読者と適用範囲
対象は、Claude CodeなどのAIエージェントへ、コード変更、調査、資料作成、業務自動化を任せている人です。
特定のOS、モデルバージョン、エージェント実装には依存しません。技術的な設定方法ではなく、委任する業務の境界と検証方法を扱います。
問題：「完了した」と「理解できる」は違う
Anthropicの『When AI builds itself』には、ある社員のコメントが掲載されています。
すべてが順調な日は自分の仕事に意味がないように感じる一方、すべてが壊れた日は原因が分からず、自分が何をしてきたのかも分からなくなる、という内容です。
関連動画では、この状態を「Don't Think」と表現していました。これはAnthropicの公式用語ではありません。
運用上の問題として整理すると、次の状態です。
- AIがタスクを実行する
- AIが結果を自己評価する
- 人間は完了報告だけを受け取る
- 成功が続き、中間状態を確認しなくなる
- 例外発生時に、前提、変更理由、復旧地点を説明できない
AIのタスク成功率が低いときは、人間が頻繁に介入します。成功率が上がるほど介入が減るため、状況理解を保つ仕組みは意識的に追加する必要があります。
委任と丸投げの差分
| 観点 | 委任 | 丸投げ |
|---|---|---|
| 目的 | 人間が明示する | 依頼文からAIが推定する |
| 合格条件 | 実行前に固定する | 出力後に合わせる |
| 実行方法 | AIに任せる | AIに任せる |
| 証拠 | ログ、差分、一次資料を残す | 最終回答だけを受け取る |
| 例外処理 | 停止条件と人間への戻し先を決める | AIが継続判断する |
| 完了判断 | 独立した証拠で確認する | AIの自己申告を採用する |
実行方法をAIに任せること自体は、両者で同じです。違うのは、目的、検証、例外処理、最終判断の所有者です。
失われやすい四つのコンテキスト
1. 目的
何を実装するかは残っていても、なぜ必要なのかが残っていない状態です。
目的がなければ、仕様を満たしていても、利用者の問題を解決していない変更を棄却できません。
2. 判断理由
最終的なコードや資料だけが残り、比較した選択肢と採用理由が失われた状態です。
後から前提が変わったとき、どの判断を見直せばよいか分かりません。
3. 検証証拠
AIが「確認済み」と報告していても、実行したテスト、参照した一次資料、確認した画面が残っていない状態です。
完了報告ではなく、再確認できる証拠が必要です。
4. 復旧地点
変更単位、直前の正常状態、停止理由が残っていない状態です。
障害時に全体をやり直すしかなくなります。
運用チェックリスト
実行前
- 目的を一文で説明できる
- 対象範囲と対象外を明記した
- 合格条件を出力を見る前に決めた
- 禁止事項と権限境界を決めた
- 情報不足、数値不一致、テスト失敗時の停止条件を決めた
実行中
- 参照した一次資料を記録している
- 変更したファイルまたはデータ範囲を記録している
- 重要な選択と理由を記録している
- 失敗した試行と修正内容を記録している
- AIが担当外へ変更を広げていない
完了時
- AIとは別の経路で結果を確認した
- 合格条件を証拠と対応づけた
- 主要な変更を人間が説明できる
- ロールバックまたは再実行の起点が分かる
- 未解決事項と適用範囲を残した
独立評価を入れる
生成したAI自身に合格を出させるだけでは、生成時と同じ誤解を評価へ持ち込む可能性があります。
対象に応じて、別の評価経路を使います。
| 対象 | 生成経路とは別の証拠 |
|---|---|
| コード | 自動テスト、静的解析、差分レビュー、実行結果 |
| 調査 | 一次資料、複数資料の照合、日付と対象範囲 |
| 記事 | 出典確認、引用照合、事実と解釈の分離 |
| 業務自動化 | 対象件数、実行ログ、権限、例外ケース |
| 資料 | 元データ、計算式、ページ単位の目視確認 |
「別のAIで確認した」だけでは、独立性が十分とは限りません。同じ入力、同じ評価基準、同じ誤情報を使えば、モデルが別でも同じ誤りを見逃す可能性があります。
Anthropicのデータから読み取れること
Anthropicは、2026年5月時点で、同社のコードベースへマージされたコードの80%以上をClaudeが作成したと報告しています。
この数字は、AIが補助ツールから実行主体へ移っていることを示します。一方で、コードの割合は品質や生産性の割合ではありません。Anthropic自身も、コード行数は不完全な生産性指標だと注意しています。
同じ記事では、人間の比較優位として、どの問題を選ぶか、どの結果を信頼するか、いつ行き止まりと判断するかが挙げられています。
つまり、AIが実行を担当する割合が増えるほど、人間側の役割は次の判断へ移ります。
- 目的の選択
- 合格条件の設計
- 証拠の検証
- 例外時の停止
- 運用責任の引き受け
制約と未検証事項
- この記事のチェックリストは、特定のプロジェクトで効果を測定したものではありません
- 導入前後の時間、障害件数、復旧時間は実測していません
- Anthropicの80%という数字は同社の内部データに基づき、第三者が全面的に再現できるデータではありません
- 「Don't Think」は関連動画の表現で、Anthropicの公式概念ではありません
- 業務の重要度、法令、セキュリティ要件に応じて追加の統制が必要です
まとめ
AIエージェントに任せる対象は、実行方法です。目的、合格条件、証拠、停止条件まで手放す必要はありません。
正常時の速度だけで運用を評価すると、例外発生時の説明可能性と復旧可能性を見落とします。
次のAIタスクでは、依頼文の前に次の4行を追加するところから始められます。
- 目的
- 合格条件
- 確認に使う証拠
- 停止条件