Claudeにコードを書かせている人へ。Anthropicでは、そのClaudeを開発する仕事にもAIを組み込んでいます。
Anthropicの公開報告では、2026年8月時点で研究開発の26%をClaudeが主導。最も使われる社内エージェント基盤では、約3万のエージェントが同時に研究・開発を進めていました。
3万です。あなたがエディタで1体のAIに修正を頼んでいる間に、開発元ではこの規模で仕事を委任している。
ただ、数を増やせば開発が回るわけではありません。途中で止まる。別のエージェントと同じ作業をする。終わっていないのに完了と報告する。同社の技術記事にも、そうした失敗が登場します。
その失敗をどう扱ったのか。ここに、自分たちの開発へ持ち帰れる話があります。
AIによる分担、検証、承認を研究工場に見立てたAI生成イラスト。Anthropicの実際の施設やシステム構成ではありません。
結論から言うと
任せる単位が、コードの一部分から、調査と検証を含む一連の仕事へ広がっています。
報告の「AI主導」は、人間が監督しながら、大まかな指示から作業の大部分を進める段階です。測定対象に完全自律の仕事はありません。
以下では、この社内運用報告と、Anthropicが別途公開したエージェント実装の技術記事を読み解きます。後者は主に2025年の資料で、3万体の社内基盤と同じ実装だと確認されたものではありません。それぞれが何を解決した設計なのかを見ていきます。
「ここを直して」から「この障害を調べて」へ
報告の脚注には、夜間データパイプラインの障害対応が登場します。自動化レベルを説明するための例で、実際の障害記録ではありません。
AI主導の例では、Claudeへ渡すのは障害通知です。Claudeがログを調べ、修正し、テストする。さらにデータのコピーで再実行し、最後に正常終了したときの出力と比較する。本番へ出す判断は人間へ戻します。
ここで変わるのは、入力するプロンプトの長さだけではありません。
人が原因を特定してからAIへ修正を頼むなら、原因調査は人の仕事です。障害通知から任せるなら、どのログを見るか、どの仮説を試すかも作業に含まれます。途中で分かったことに応じて次の手を選ぶ必要があります。
「例外が出るので、この行にtryを追加して」と頼むのと、「なぜこの入力だけ失敗するのか調べて」と頼むのでは、完了条件が違うのです。
テストが緑でも、データが消えていたら失敗
バッチ処理で考えてみてください。
不正なレコードで例外が発生している。そこで、そのレコードを読み飛ばすように変更した。プログラムは最後まで走り、終了コードも0になった。
これで直ったと言えるでしょうか。
そのレコードが本来処理すべき注文だったら、エラーを消した代わりに売上を落としています。以下は、この種の修正をレビューするための確認例です。
| 確認するもの | 終了コードだけでは分からないこと |
|---|---|
| 入出力の件数 | 処理対象を黙って捨てていないか |
| 一意キーと重複 | 再実行で同じ注文を二重に登録していないか |
| 金額などの集計値 | 型変換や丸め方で結果が変わっていないか |
| 入力・設定・コードの版 | 同じ条件で比較できているか |
| 想定した差分 | 直した部分以外まで変えていないか |
AIから受け取るものを、修正コードだけで終わらせない。
どの入力で失敗を再現し、何を変え、どの比較で直ったと判断したのか。そこまで残れば、人間は調査を最初からやり直さずにレビューを始められます。
長く動かすと、AIは引き継ぎでつまずく
障害対応を一度任せられても、数時間、数日と開発を続けるなら別の問題が出ます。
Anthropicが公開した長時間稼働エージェントの実験では、一度に実装しすぎて途中の状態を残したり、後続のセッションが一部の完成を見て全体を完了扱いしたりする失敗がありました。対策は、初期環境を作る担当と、少しずつ実装する担当を分け、機能一覧、進捗記録、Git履歴で引き継ぐ構成です。
「続きをやって」と伝えるだけでは、何の続きかが足りません。
実装済みなのか。テストまで済んだのか。途中で失敗して戻したのか。この3つが同じ「作業しました」に圧縮されると、次のセッションは状態を推測することになります。
自分のプロジェクトで引き継ぐなら、たとえば次の記録が使えます。これは記事用に作った例で、同社の内部ファイルではありません。
対象: 注文CSVの取り込み
変更: 空欄の配送先を検出してエラーとして返す処理を追加
検証済み: 正常入力、空欄入力、同じファイルの再投入
未確認: 大容量ファイルでのメモリ使用量
現在位置: 修正は作業ブランチ上。本番へは未反映
次の作業: 大容量ケースを検証し、結果をレビューへ渡す
「実装完了」と「本番反映済み」が混ざっていない点が重要です。長く動くほど、現在位置を間違えたときの影響も大きくなります。
進捗ファイル自体も自己申告です。テスト出力や差分など、裏付けをたどれるようにしておく。次のエージェントが読むのは前任者の説明ですが、確認する対象は実際の成果物です。
画面のコードを書いた。でも画面は動かなかった
同じ技術記事では、コード変更や単体テストを行っても、ユーザーの操作を最後まで試さずに機能を完了とする問題も報告されています。ブラウザ操作による検証を明示すると、コードだけでは気づきにくい不具合を見つけられたとしています。
たとえば保存APIのテストが通っていても、画面のボタンがそのAPIを呼んでいなければユーザーは保存できません。
完了条件を「保存APIのテストが通る」に置くと、ここは抜けます。「入力して保存し、再読み込み後にも値が残る」に置けば、画面から永続化までのつながりを確認できます。
テストの本数を増やす前に、ユーザーが何をできたら完成なのか。その操作を一つ書くほうが、欠けた確認に気づける場合があります。
エージェントを増やしたら、同じ調査を始めた
1体が足りないなら、複数に任せる。自然な発想です。
しかしAnthropicのResearch機能の開発では、曖昧な依頼によって、サブエージェントが同じ検索を繰り返したり、別の時期の話を調べたりする問題がありました。担当ごとの目的、出力形式、使用する情報源、作業範囲を明確にすることが対策として挙げられています。
「調べておいて」を3体に送れば、3種類の答えが返ってくるとは限りません。同じ検索上位ページを読み、似た要約を3つ作ることもあります。
開発作業に置き換えた分担例なら、こうです。
| 担当 | 渡す仕事 | 返す成果物 |
|---|---|---|
| 調査 | 障害を起こす入力と失敗箇所を絞る | 再現条件、ログへの参照、原因候補 |
| 修正 | 合意した原因候補に対して変更する | 差分、変更理由、影響範囲 |
| 検証 | 修正前後で同じ入力を試す | 比較結果、残っている失敗、未確認事項 |
これは役割を整理した例です。3体を常に同時起動するという意味ではありません。原因が絞れていない段階の修正と、その修正を使う検証には依存関係があります。
同時に進めやすいのは、別々のログの調査や、互いに影響しない再現条件の確認。順番を守る必要があるのは、原因の合意、修正、修正後の検証です。
人数を増やす前に、仕事を分ける。
担当を分けても、全員に同じファイルを自由に編集させれば競合が起きます。成果物をどこへ置くか、誰が取り込むかまで決めて初めて、分担が実装になります。
3体が賛成した。それで証拠は増えたのか
同社のResearch設計では、サブエージェントの成果物を外部に保存し、参照を渡す方法も説明されています。何段も要約し直す過程で情報を落とす問題を減らすためです。
ここから自分たちの開発に持ち込めるのは、報告を根拠へつなぐ習慣です。
「テストは通りました」という文章だけを受け渡すと、次の担当が確認できるのは前任者の主張まで。「このコミット、この入力、このテスト結果」を渡せば、確認対象が残ります。
3体が同じ説明を繰り返しても、独立した検証が3回行われたとは限りません。レビュー担当には、賛成するための要約だけでなく、疑って確かめられる材料を渡す必要があります。
3万体を監督するために、行動と発言を結び付ける
社内運用報告に戻ると、エージェントには個別の識別子があり、共有メッセージと実行記録を関連付けています。操作前に検査するオンライン監視と、活動を事後に読むオフライン監視も分けています。
誰が、どの判断を受けて、何を実行したか。複数のエージェントが関わると、このつながりが必要になります。
実装時に考えるべき違いは、操作を止められるタイミングです。
| 監視するタイミング | 設計上の役割 | 例 |
|---|---|---|
| 実行前 | 実行してよいか判定する | 許可されていない宛先への送信を拒否する |
| 実行後 | 一連の進め方を点検する | テスト条件の変更と成功報告を突き合わせる |
例は説明用です。実行前の検査なら、送信を止める余地があります。事後の記録だけでは、送信済みのデータを回収できるとは限りません。
一方、個々には許された編集でも、失敗するテストを順に除外した結果として「全部成功」になっていたらどうでしょう。コマンド一つの許可判定だけでは分かりません。元の依頼、変更履歴、検証結果をまとめて読む必要があります。
ログを保存する処理と、ログから問題を見つけて介入する処理は、それぞれ実装が必要です。監視を入れるなら、警告を受けた誰が止めるのかまでつなげます。
「毎回承認」から、動いてよい範囲を決める設計へ
人間が監督するなら、すべてのコマンドを毎回承認すればよいのでしょうか。
AnthropicはClaude Codeのサンドボックス設計で、承認の繰り返しによる疲労を問題として挙げています。公開された設計では、ファイルへのアクセスとネットワーク接続をOS側で制限し、その範囲内の作業を進められるようにしています。制限は起動した子プロセスにも及びます。
「本番に触らないで」と文章で指示するだけなら、本番へ接続できる資格情報は残っているかもしれません。実行環境からその資格情報を外し、接続先も制限すれば、越境できる経路を減らせます。
ここで、書き込み先だけを絞って終わらせない。読み取れる情報と送信できる宛先も確認します。ファイルを変更できなくても、その内容を外へ送れるなら別の問題が残るからです。
同社のクラウド側Git連携の説明には、認証と送信先の制御もあります。サンドボックス内のスコープ付き認証情報をプロキシが検査し、リポジトリやブランチなどを確認してから、上流向けの認証情報を付けて送る構成です。
これを読んで自分のエージェント環境を点検するなら、まず次の3つです。
- 作業に必要のない秘密情報まで、実行環境から読めないか。
- 許可したツールの先で起動されるスクリプトにも、制限がかかるか。
- 承認が必要な操作を、別の経路から実行できないか。
安全性をモデルの返事だけで判断せず、実際に何が許可されているかを見る。そのうえで、範囲を越える判断を人間へ戻します。
あなたのエージェントに渡す「仕事の仕様」
ここまでを、1体の開発エージェントへの依頼に落とすとどうなるか。
以下は、夜間バッチの修正を想定した依頼文の例です。Anthropicのプロンプトや、そのまま動く設定ファイルではありません。
目的:
夜間バッチの失敗原因を特定し、修正案を検証する。
作業範囲:
指定した作業ブランチと、検証用データのコピーを使う。
本番データ、本番設定、認証情報は変更しない。
完了条件:
1. 修正前に失敗を再現する。
2. 修正後に同じ入力で成功を確認する。
3. 件数、一意キー、重要な集計値を比較する。
4. 差分、検証結果、未確認事項をまとめる。
停止条件:
本番アクセスが必要になった。
想定外のデータ削除や仕様変更が必要になった。
原因を確認できず、変更が推測に依存する状態になった。
人間へ戻す判断:
本番反映、データの補正、検証基準の変更。
この文章と合わせて、実行環境の権限もそろえます。「本番データを変更しない」と書きながら、本番DBの管理者権限を渡してしまえば、設計が食い違います。
返却形式も決めておくとレビューしやすくなります。
原因: 再現できた条件と、根拠となるログ
変更: 対象ファイル、変更理由、影響範囲
検証: 入力の識別子、実行した確認、結果への参照
残件: 未確認の条件、失敗した確認、追加で必要な判断
状態: 作業ブランチに保存済み。本番反映は未実施
「修正しました」の一文では、採用してよいか判断できません。変更と証拠と残件を受け取れば、レビューすべき場所を絞れます。
冒頭の26%は作業分類を重み付きで集計した指標で、削減できた時間の割合ではありません。ただ、開発を任せる範囲を考える材料にはなります。
AIに仕事を渡すなら、結果を確認する方法も一緒に渡す。
あなたのエージェントが「完了」と言ったとき、何を見れば本当に終わったと分かりますか。次の依頼では、その確認を一つだけでも完了条件に加えてみてください。
参考資料
Anthropic — Measurements for understanding the pace of AI development inside frontier labs
https://www.anthropic.com/institute/measuring-pace-of-ai-development
Anthropic — Effective harnesses for long-running agents（2025年11月26日）
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic — How we built our multi-agent research system（2025年6月13日）
https://www.anthropic.com/engineering/multi-agent-research-system
Anthropic — Beyond permission prompts: making Claude Code more secure and autonomous（2025年10月20日）
https://www.anthropic.com/engineering/claude-code-sandboxing