AIエージェントの自律度を実測 — Claude Codeの最長ターンは45分超に
Anthropicが数百万件のやり取りで測ったエージェントの自律度。最長級のターンは3か月で約2倍、ツール呼び出しの約半数はソフトウェア開発。承認設計への含意を読み解きます。
エージェントにどこまで任せているかを、実際の利用データで測った研究があります。Anthropicは、Claude Codeと公開APIの数百万件のやり取りを分析し、2026年2月18日に結果を公表しました。
結論から言うと、伸びたのは「平均」ではなく「最長級のターン」です。中央値は約45秒のまま、99.9パーセンタイルのターンが3か月で25分未満から45分超になりました。ツール呼び出しの約半数がソフトウェア開発という偏りも、承認設計の前提になります。
どう測った研究か — 2つのデータ源の使い分け
研究はエージェントを「コード実行・外部API呼び出し・他エージェントへのメッセージ送信など、行動を起こすツールを持つAIシステム」と定義しています。ツールの使い方を見れば、世の中で何をしているかがかなり分かるという立場です。
使ったデータ源は2つあり、見えるものが逆になっています。
2つのデータ源が見せるもの
公開API
数千の顧客のエージェントを横断して見られます。ただしツール呼び出し1件ずつの分析で、複数の呼び出しがどう連なったかは再構成できません。
Claude Code
自社製品なので、リクエストをセッションにつなげて最初から最後まで追えます。ただし1製品で、用途もソフトウェア開発に偏ります。
自律度の指標として使われたのは、Claudeが作業を始めてから止まるまでの経過時間(ターン時間)です。止まる理由は、完了・質問・ユーザーの中断のどれでも構いません。
研究自身が、ターン時間は「不完全な代理指標」だと断っています。モデルが速くなればターンは短くなり、サブエージェントで並列化しても短くなります。逆に、ユーザーがより野心的な課題を任せればターンは長くなります。観測値はこれらの綱引きの結果です。
伸びたのは最長級のターンだけ
ターン時間の分布は、中央値と裾でまったく違う動きをしています。
Claude Codeのターン時間(インタラクティブセッション)
中央値
約45秒
この数か月は40〜55秒の範囲
99.9パーセンタイル(2025年10月)
25分未満
99.9パーセンタイル(2026年1月)
45分超
約3か月で約2倍
99パーセンタイルより下のほぼすべての区分は安定していました。急成長中のプロダクトでは新規ユーザーが増え続け、彼らはまだClaudeに全面的な裁量を与えないため、ここが安定するのは自然だと研究は説明しています。
注目点は、この伸びがモデルのリリースをまたいで滑らかだったことです。能力だけで決まるなら、新モデルのたびに段差が出るはずです。背景には、使い込んだユーザーの信頼の蓄積、課題の高難度化、製品の改善が重なったとみられます。
1月中旬以降は、極端に長いターンがやや減りました。ユーザー数が1月から2月中旬にかけて倍増したことと、年末年始明けに趣味のプロジェクトから範囲の絞られた業務タスクへ中身が移った可能性が、仮説として挙げられています。
社内データでは成功率が倍、介入は5.4回から3.3回
Anthropic社内のClaude Code利用では、8月から12月にかけて、最も難しい課題の成功率が倍になりました。1セッションあたりの人間の介入は5.4回から3.3回に減っています。
つまり社内では「任せる量が増え、成果も良く、介入は減った」という方向です。研究はここから、モデルが扱える自律度が実際に使われている自律度を上回る「デプロイメントの余剰(overhang)」があると述べます。
METRの評価との対比も載っています。METRは、Claude Opus 4.5が50%の成功率で完了できる課題を、人間なら5時間近くかかる規模と見積もりました。Claude Codeの99.9パーセンタイルは約42分です(上の45分超は2026年1月の値で、集計の時期と対象が異なります)。ただし前者は「人間が何時間かかる課題か」という難度の指標で、後者は実際に走った時間です。研究自身が直接比較できないと明記しているので、「5時間と42分の差」を能力の差として読むのは誤りになります。
経験を積むと、自動承認も中断も増える
次の発見は一見矛盾しています。
| 経験の度合い | 全自動承認で走るセッション | 中断が起きるターン |
|---|---|---|
| 新規ユーザー(50セッション未満) | 全自動承認で走るセッション約20% | 中断が起きるターン約5%(10セッション前後) |
| 経験者(750セッション) | 全自動承認で走るセッション40%超 | 中断が起きるターン約9% |
自動承認を増やしたのに、中断も増えているわけです。研究はこれを、監督の戦略が変わったと解釈しています。新規ユーザーは1手ずつ承認するので、実行中に割り込む必要がほとんどありません。経験者は任せて走らせ、おかしくなったときだけ割り込みます。
見落としやすい留保が2つあります。
- 当時のClaude Codeの既定は「毎回手動承認」で、自動承認の増加には、慣れた人が設定を変えた分が含まれる
- 中断率の上昇は、経験者がより難しい課題をやっていることの反映でもありうる
公開APIでも似た傾向が出ています。最小難度のタスクのツール呼び出しでは87%に何らかの人間の関与があるのに、高難度のタスクでは67%です。手順が増えるほど1手ずつの承認は現実的でなくなるためで、人間の関与の推定値は上限として読む必要があります。研究が手動検証したところ、Claudeは人間の関与を過大に見積もる傾向があったからです。
研究が引き出す結論は、「効果的な監督とは、全アクションを承認することではなく、肝心なときに介入できる位置にいることだ」というものです。
Claudeは人間の割り込みより多く自分から止まる
自律度を決めるのは人間だけではありません。Claude自身が迷ったときに質問して止まります。最も複雑なタスクでは、Claude Codeが確認のために止まる頻度は、最小複雑度のタスクの2倍超でした。人間の中断よりも速いペースで増えています。
止まる理由と中断する理由は、Claudeに分類させた結果が表で示されています(50万件の中断と50万件の完了ターンの標本)。
| Claudeが自分で止まる理由 | 割合 | 人間が中断する理由 | 割合 |
|---|---|---|---|
| 方針の選択肢をユーザーに提示する | 割合35% | 人間が中断する理由不足した技術情報や訂正を与える | 割合32% |
| 診断情報やテスト結果を集める | 割合21% | 人間が中断する理由Claudeが遅い・固まる・やりすぎ | 割合17% |
| 曖昧な依頼を明確にする | 割合13% | 人間が中断する理由十分な助けを得て自力で進められる | 割合7% |
| 認証情報やトークン、アクセスの要求 | 割合12% | 人間が中断する理由次の手(手動テスト・デプロイ・コミット等)を自分でやりたい | 割合7% |
| 実行前の承認・確認を得る | 割合11% | 人間が中断する理由要件を途中で変える | 割合5% |
左右の行は対応関係を持たない並びです。表は、止まる理由の最多が「選択肢の提示」で、人間が割り込む理由の最多が「技術的な文脈の補足・訂正」だという点だけを示しています。
過大解釈には注意が要ります。Claudeが適切な場面で止まっているとは限らず、不要な質問をしている可能性もあり、Planモードのような製品機能の影響も受けるからです。それでも、難しい課題ほどClaudeが自分で自律度を絞ってから人間を呼ぶ、という方向は読み取れます。モデルが自分の不確実性を認識して表に出す性質は、権限システムや人間の監督と補い合う安全上の性質だとされています。
公開APIではツール呼び出しの約半数がソフトウェア開発
もう一つの柱が、公開APIの約99.8万件のツール呼び出しの標本です。ここではClaudeがリスクと自律度を1〜10で採点し、似た行動をクラスタにまとめて平均を出しています。
- ソフトウェア開発がツール呼び出しの約50%を占め、それ以外はビジネスインテリジェンス、カスタマーサービス、営業、金融、Eコマースなどが並ぶが、どれも数パーセント程度にとどまる
- 呼び出しの80%は、権限の制限や人間の承認といった何らかの安全策を持つエージェントから来ている
- 73%は何らかの形で人間が関与している
- 不可逆に見える行動(顧客へのメール送信など)は0.8%
落とし穴
「半分がソフトウェア開発」はClaude Codeの内訳ではない
約50%という数字は公開APIのツール呼び出しの分布で、Claude Codeの利用内訳ではありません。さらに標本はツール呼び出し単位なので、ファイル編集を何度も繰り返すソフトウェア開発のワークフローは、少ない手数で終わる用途より過大に代表されます。「業界の半分がコーディングエージェント」という意味には読めません。
リスクが高いクラスタの多くは、セキュリティ評価(レッドチーム演習)とみられるものでした。APIキーを盗むバックドアの実装や、医療記録の取得、暗号資産の自動取引が例に挙がりますが、研究自身が実取引かどうかは判別できないと断っています。リスクの採点は低い側に集中し、自律度の採点は幅広く分布しています。
この数字を読むときの限界
研究が「何が言えないか」を自分で列挙している点は、引用するときの安全弁になります。
- 分析対象はAnthropicのトラフィックのみで、他社モデルのエージェントは含まない
- 強い発見の多くはClaude Codeのデータに基づき、他の領域や製品に一般化できるとは限らない
- 分類はClaudeが生成しており、プライバシー上の制約から元データを人手で確認できていない
- 期間は2025年後半から2026年初頭まで
また、研究は「ソフトウェアは出力をテスト・比較・レビューしやすい領域だ」という点を重く見ています。法務・医療・金融のように検証に同等の専門性が要る領域では、同じ形で信頼が育つとは限りません。
承認設計に落とすなら — Claude Codeでの具体策
研究の提言は、承認を全面的に義務づけるのは時期尚早で、人間が効果的に監視・介入できる位置にいることを重視せよ、というものです。Claude Codeでこれを運用に落とすと、次の3点になります。
1. 開始モードを「自分が何を見ているか」で選ぶ
権限モードの公式ドキュメントでは、default(Manual)は読み取りだけ、acceptEditsはファイル編集まで、autoはバックグラウンドの安全チェック付きで、全アクションを承認なしで実行する、と整理されています。autoでは分類器モデルが人間の代わりに各アクションを審査します。
同じドキュメントによると、v2.1.283以降は対話型ターミナルとVS Codeセッションの開始モードがautoです。研究期間の既定が手動承認だった点とは前提が変わっているため、研究の「自動承認率20%→40%」を今の自分の環境にそのまま当てはめることはできません。なおHIPAA構成が適用された組織で対象のセッションは、v2.1.285以降default(Manual)で始まり、autoは切り替えて使います。
個人の既定を変えるなら、~/.claude/settings.jsonに書きます。
{
"permissions": {
"defaultMode": "acceptEdits"
}
}プロジェクトの.claude/settings.jsonに書いたdefaultModeは、autoとbypassPermissionsの値が効きません。チームの共有設定で全員を自律側に倒すことはできない設計です。権限モードの変遷はClaude Code権限モデルの変遷に、起動時のフラグ指定は--permission-modeの使い方にまとめています。
2. 長い作業の前にPlanモードで方針をそろえる
研究では、Claudeが自分で止まる最多の理由が「方針の選択肢の提示」でした。走り出してから止まるより、先に計画で分岐を潰しておくほうが、最長級のターンを無駄にしにくくなります。手順はClaude Code Planモード完全ガイドにあります。
3. 「何を承認したか」を計測してから緩める
研究は、監督の鍵は信頼できる可視性だと述べ、Claude Code側の取り組みとしてリアルタイムのステアリングとOpenTelemetryを挙げています。OpenTelemetryのログに出るtool_decisionイベントにはdecision(acceptまたはreject)とsourceが付きます。
sourceの値は次のとおりです。
| source | 意味 |
|---|---|
config | 意味設定・許可ルール・権限モードなどによる自動判定 |
hook | 意味PreToolUseまたはPermissionRequestフックの判定 |
user_temporary | 意味プロンプトでの1回限りの許可(またはセッション中の許可) |
user_permanent | 意味「今後は確認しない」を選んで許可ルールを保存 |
user_abort / user_reject | 意味応答せず閉じた/拒否した(いずれも拒否扱い) |
次の環境変数でログをエクスポートできます(公式のクイックスタートに沿った最小形です)。
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=console # まず標準出力で中身を見る
claudeconfigの比率とuser_*の比率を週単位で並べれば、研究の「自動承認率」に近い数字を自分のチームで出せます。これは研究の測定法そのものではなく、同じ問いを自前のデータで立てるための代用です。configには「毎回の承認を外した結果」だけでなく、元から安全とみなされる読み取りも含まれる点に注意が要ります。導入手順はClaude CodeのOpenTelemetryで利用量とコストを可視化を参照してください。
リポジトリ側の.claude/settings.jsonにOpenTelemetryのエクスポーター変数を書いても無視されます。管理設定か、各開発者のシェル・~/.claude/settings.jsonに置く構成です。
読み解き — 自律度は「3者の共同構築」
研究の中心的な教訓は、エージェントが実際に発揮する自律度はモデル・ユーザー・製品の三者で共同構築される、という一文にあります。モデルは迷ったら止まり、ユーザーは経験で監督の型を変え、製品は既定値と可視化で選択肢を形づくります。
ここから言えるのは、承認の厳しさだけを議論しても自律度の実態は決まらない、という点です。たとえば、同じ「自動承認40%」でも、中断のしやすさと可視化が整った環境なら監督は保たれ、整っていない環境では監督が空洞になります。承認のON/OFFより、割り込める画面と記録が先に要ります。
複数のエージェントを動かす構成では、さらに別の失敗が出ます。協調の失敗はマルチエージェントの協調失敗パターンに、サブエージェントによる並列化はClaude Codeのサブエージェント完全活用に整理しています。ターン時間が並列化で短くなりうるという研究の留保は、後者の使い方と地続きです。
まとめ
数字で押さえるのは4点です。中央値約45秒は動かず、99.9パーセンタイルのターンが25分未満から45分超へ。新規と経験者の全自動承認が約20%から40%超で、中断率も5%から約9%へ。Claudeの自発的な停止は人間の中断より増えやすい。API側のツール呼び出しの約50%がソフトウェア開発。
使い方としては、これらを「世の中の標準」ではなく、Claude Codeとソフトウェア開発に偏った一つの観測として扱うのが安全です。自分のチームの承認設計を見直すときは、先にtool_decisionで現状を数え、そのうえでモードやルールを動かす順番が、研究の示す方向とも整合します。