第29号

AIエージェントを長く使う人は、どう仕事を任せ、どう介入してきたのか

Claude Codeの使用記録では、自動承認と作業中断がともに増えていました。何を測定した研究なのか、どこまで解釈できるのかを見ていきます。

AI・テックAIエージェントを長く使う人は、どう仕事を任せ、どう介入してきたのか

Anthropicが2026年2月18日に発表した研究を読みました。Claude Codeと公開APIを通じて行われた数百万件の人間・エージェント間のやり取りを分析した資料です。私はモデルの試験スコアよりも、人々が実際に仕事を任せ、介入するやり方に着目していた点が興味深く感じました。

この研究でいう「エージェント」とは、コードを実行したり外部APIを呼び出したりするなど、ツールを通じて行動できるAIシステムを指します。研究チームは、エージェントがどれくらい長く単独で作業するのか、ユーザーがいつ承認したり中断したりするのか、どの分野でツールが使われているのかを調べました。

私が特に注目した結果は、経験の多いユーザーほど自動承認をより頻繁に使う一方で、作業途中に介入する割合も高かったという点です。AIにより多くを任せることが、必ずしも監督を減らすことを意味するわけではなかったのです。

ほとんどの作業区間は短く、極めて長い区間はさらに長くなった

Claude Code分析の単位は、一度作業を開始してから完了・質問・ユーザーによる中断のいずれかに至るまでの「ターン」です。プロジェクト全体を終えるのにかかった時間とは異なります。

ターンの継続時間の中央値は約45秒でした。観測期間中は40〜55秒の間で比較的安定して推移していました。全体の使用が長時間の自律作業に置き換わったわけではありません。

変化が見られたのは非常に長いターンでした。2025年10月から2026年1月にかけて、長さ順で上位0.1%に入る境界値である99.9パーセンタイル値は、25分未満から45分以上へと伸びました。研究チームは、1月中旬以降はこの値がやや減少したとも説明しています。

新しいモデルが出るたびに急激に跳ね上がるというより、段階的に増えていった点も観察されています。考えられる説明としては、ユーザーの信頼の蓄積、より大きな作業を任せるようになった変化、製品自体の改善などが挙げられます。研究チーム自身も、これらの要因を切り分けて測定することはできなかったと明らかにしています。

したがって、増加の原因をユーザーの信頼だけに求めたり、モデルの性能はもはや重要ではないと言い切ったりすることはできません。より高速なモデルであれば同じ作業をより短時間で終えることもあり得るため、作業時間が長いという理由だけで能力が高いと評価するのも難しいところです。

自動承認を増やしたユーザーも途中で介入していた

50セッション未満の新規ユーザーは、約20%のセッションで全自動承認設定を使用していました。使用経験が750セッション程度の集団では、この割合が40%を超えていました。この数値は個々の行動のうち承認された割合ではなく、当該設定を使用したセッションの割合です。

一方、作業の中断は新規ユーザーではターンの約5%、経験の多いユーザーでは約9%で観察されました。研究チームはこれを、行動ごとに事前承認する方式から、進行を見守りながら必要なときに介入する方式へと変化している兆候だと解釈しています。

ここで確認できたのは、使用経験と監督方式の関係です。中断が増えたという事実だけで、すべての介入が適切だったとか、その方式があらゆる作業でより安全だと証明されたわけではありません。ユーザーが任せる作業や設定自体も同時に変化しうるからです。

私には、承認回数を数えることと、ユーザーが実際に状況を把握していることは区別すべきだという点が重要に思えました。承認ボタンを何度押しても内容をよく理解していない場合もあれば、自動で進めさせていても必要な瞬間に方向を変えることはできるのです。

エージェントが質問することも監督の一部

最も複雑な作業では、Claude Codeが確認の質問をして立ち止まる割合が、ユーザーが中断する割合の2倍以上でした。研究チームは、アプローチの選択、診断情報の収集、不完全な要求の確認、アクセス権限の要求などを主な理由として分類しています。

人が中断する理由としては、不足している技術的な文脈を伝えたり誤りを修正したりしようとする場合、作業が遅い、あるいは長くなりすぎている場合、十分な支援を得て自分で続けようとする場合などがありました。

この結果は、必要な情報を尋ねるという行動もエージェントの自律性を調整していることを示しています。ただし研究チームは、Claudeが常に適切なタイミングで立ち止まるわけではなく、不要な質問をすることもあると指摘しています。製品のプランニングモードのような機能も、質問の頻度に影響を与えることがあります。

結局のところ、質問が多いという事実そのものよりも、必要な質問をしているか、答えを受け取った後に適切に作業を続けているかを見る必要があるでしょう。私はこの点を、自律性とユーザーの介入をともに設計しなければならない理由として読み取りました。

ツール呼び出しの約半分はソフトウェア開発関連だった

公開APIの分析では、個々のツール呼び出し約100万件をサンプルとしました。このうちソフトウェアエンジニアリング関連の呼び出しが約半分でした。金融、医療情報、セキュリティなど、ほかの分野での利用も観察されています。

ここでいう呼び出し数は、ユーザー数や業務件数とは異なります。コードを何度も修正する作業のように、ツールを何度も呼び出す方式は、その分大きく集計される可能性があります。この分布を、AIエージェント市場全体における業種別の比重として読んではいけない理由がここにあります。

研究チームは、呼び出しの80%が、権限制限や承認要件のような安全装置を少なくとも一つ備えたエージェントから出たものと推定しました。73%では何らかの形で人が関与しているものとして、0.8%は取り消しが難しい行動として分類しています。

これらの数値は、個々の呼び出し周辺の文脈をClaudeが分析した結果です。研究チームがすべてのシステムの安全装置や実行結果を直接確認したわけではありません。顧客側で追加の検証が行われている場合もあれば、危険に見える行動が実際の運用ではなくセキュリティテストである場合もあります。

データを扱う立場からすると、この限界はとりわけ重要に思えます。分類結果の数値が小さいからといって危険がないと判断することはできませんし、危険な表現が出てきたという理由だけで、その行動が現実に実行されたとみなすこともできないからです。

ツールをつなぐ方法も実際の使用に影響する

エージェントが仕事を遂行するには、使用するツールの情報と結果を受け取る必要があります。この過程でモデルにどれだけ多くの説明とデータを渡すかも、性能とコストに影響します。ここからは自律性研究とは別に、ツールの接続方式をめぐる議論を併せて見ていきましょう。

MCPは、モデルが外部のツールやデータにアクセスする方式を標準化するプロトコルです。CLIは文字で命令を入力して既存のプログラムを実行するインターフェースです。両者を比較する際は、接続方式の名称よりも実際の実装を見るべきです。

すべてのツールの使用説明を最初からモデルに入れておくMCP構成では、説明だけで多くのトークンを消費することがあります。トークンとは、モデルが処理するテキストの単位です。ただし、すべてのMCP実装がすべての説明を一度に読み込ませることを要求しているわけではありません。

開発者のJannik Reinhardは、Intuneで管理する機器のうち会社の管理基準を満たさない50台の情報をCSVに書き出す独自の比較において、MCP構成では約14万5,000トークン、CLI構成では約4,150トークンを使用したと報告しています。特定のツール構成と作業についての事例であるため、他のシステムでも同じ差が出るとは限りません。ツールの説明だけでなく、コマンドの作成や結果の処理までを含めた全体のコストを、同じ作業のもとで比較する必要があります。

AnthropicもMCPにおいて必要なツールの説明だけを探し出し、コード実行によって中間結果を処理する方式を提案しています。ツールが増えても、そのたびに全体の説明や結果をモデルに渡さずに済むようにするアプローチです。

私はこの議論を、エージェントを実務に合わせて磨き上げていく過程として見ています。モデルに何をあらかじめ伝えておくか、何は必要なときに探させるか、どんな結果をユーザーに見せるかが重要になってくるのです。MCPとCLIのどちらか一方を普遍的な勝者として選ぶ問題に絞り込みたくはありません。

Oswarldの視点

研究チームは、モデルが担うことのできる自律性と、現実に与えられている自律性との間にギャップがあると解釈しています。私はこの「デプロイメント・オーバーハング」という視点が興味深く感じられました。ただし、そのギャップがどれほど大きいのか、何によって生じたのかは、さらに確認が必要です。

性能評価と実際の使用記録は、そもそも異なるものを測定しています。例えばMETRの時間軸(タイムホライズン)は、人がどの程度の時間をかけるような難度の作業を、モデルが一定の成功率で解決できるかを示すものです。モデルがその時間だけ単独で稼働していたという意味ではないため、Claude Codeのターンの長さと直接比較することはできません。

今回の研究がAnthropicの製品だけを扱っているという点も残っています。Claude Codeではセッション全体を見ることができますが、コーディングに偏っており、公開APIでは多様な用途を見ることができますが、個々の呼び出しを一連の完全な作業過程としてつなげるのは難しいです。他の製品や分野でも同じパターンが現れるのかどうか、確認が必要です。

ですから私は、エージェントを導入する際には信頼さえ高めればよいと言いたくはありません。仕事を任せられるだけの能力があるか、誤りを発見できるか、ユーザーが必要な瞬間に介入できるかを併せて見る必要があります。任せる範囲と責任を定める組織の役割もあります。

研究チームは、すべての行動に同じ承認方式を求める規制を急いで定めるよりも、効果的に監督し介入できるかどうかを見極めるべきだと提案しています。私はこの方向性に同意しますが、実際に適用する方式は、作業の影響度と取り消し可能な度合いに応じて定めるべきだと考えます。

今回の研究を読んで、私は自律性というものを、モデルの能力とユーザーの判断、製品設計がともに定めるものとして捉えるようになりました。実際に仕事を任せるやり方まで見なければ、エージェントの活用を理解することはできないという点が残りました。

あなたの視点が次の号をつくります

この号で最も共感した点、あるいは違う経験をした点はどこですか。

読者アカウントがあれば無料でコメントできます。

参考資料と関連リンク

筆者アン・グァンソプ(安光涉)は世宗大学校経営学科教授であり、INLEVEL9のリードコンサルタントである。大学では経営データ管理、ビジネスアナリティクスなど統計およびデータ分析を教える一方、現場ではGTM戦略とAI戦略コンサルティングを主導し、技術とビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ(HEMA)研究で学術論文を発表し、毎日グローバルなAI論文をキュレーションするDaily Arxivプロジェクトを運営している。高麗大学校技術経営専門大学院の修士課程とKMBAを修了した。著書に『考えを任せる人々:ホモ・ブレインレス』がある。

アン・グァンソプ(Oswarld)のイラスト

著者 アン・グァンソプ(Oswarld) は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月:HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。