Addy Osmani ・ 翻訳

エージェントの自律性レベル ― 調整された自律性（Calibrated Autonomy）

単一軸のラダーでは測れない。「Agency（個別エージェントをどこまで手放すか）」と「Orchestration（多数のエージェントを調整するスキル）」の2軸、レベル0〜5の詳細、実行前の契約8項目、4つのアンチパターンまで。検証こそが常にボトルネック。

読了目安 約 18 分日本語訳

エージェント・エンジニアリング（AIエージェントを活用した開発手法）をめぐる議論の多くにおいて、その焦点は「プロンプティング」から「オペレーティング（運用）」へと移り変わっています。霧の向こうに広がるフロンティアには、ソフトウェア・ファクトリー、ゴール、ループ、バックグラウンド・セッション、サブエージェント、フック、サンドボックス、そしてエージェントを承認するエージェントといった概念が姿を現しています。未来のクリエイターにとって、こうした挙動は製品開発の初日から組み込まれるものになるでしょう。Claude CodeやCodexは、このパラダイムシフトを直接的に示しています。

エンジニアの視点からは、リスクを抑え、可逆性（元に戻しやすさ）を高めるために、あえて自律性の低い設定を利用することもあるでしょう。一方で、明確な活動や、巨大なコードベースを安全にリファクタリングする並列エージェント群に対しては、高い自律性を付与することになります。アクションに関する核心的な問いは常に、「このタスクにはどの程度の自律レベルがふさわしいか」、そして「そのレベルが妥当であると言えるだけの検証手段があるか」という点に集約されます。

フロンティアの最前線にいるのは、トリガーによって起動し、補助エージェントに仕事を委任し、その出力を継続的に検証しながら、人間が判断すべき事項だけを持って戻ってくる「マネージャー・エージェント」です。このような環境を構築している人々は、すでに数百、数千のエージェントを、主にメンテナンスの行き届いた（evergreen）コードベース上で走らせているかもしれません。自律性に関するあらゆる考察がそうであるように、その規模をどう捉えるかは人によって異なります。

よく引用される指標として、Steve Yeggeが「Welcome to Gas Town」や「The Pragmatic Engineer」で述べた単一軸のラダー（はしご）があります。これは、自分がどれだけ「AIネイティブ」であるかを示す数値を知るための良いリファレンスです。このラダーは、個別のエージェントに対する信頼度を測定するための単一の数値を与えてくれます。その一例が以下のようなものです。

2026年初頭、業務が「委任」から「オーケストレーション（編成）」へと移り変わりつつあった時期でも、これはリスクを測るためのかなり優れた代用指標でした。しかし今日では、多くのエージェントを同時に走らせることができるようになったため、多くのスキルセットがより大きな意味とレバレッジを持つようになっています。単一の「段」だけでは、マルチエージェントを扱うスキルを測ることはできません。

実際、自律性に関する議論のほとんどで、本来分けるべき2つの問いが混同されています。それは、「個別のエージェントを自分からどれだけ離れたところまで行かせるか」という問いと、「多数のエージェントをコーディネート（調整）するスキルがどれだけあるか」という問いです。

これら2つの次元を個別に捉えるために、「Agency（主体性）」と「Orchestration（オーケストレーション）」の2軸を用います。

Agency（主体性）軸において、レベルが低い状態とは、エージェントがアクションの候補を提案し、人間の判断を待つ状態を指します。 中レベルでは、エージェントは特定のタスクに取り組みますが、その範囲を限定し、常にエビデンス（根拠）を添えて進捗を報告するため、人間が進行方向を修正し続けることができます。 高レベルになると、エージェントは目標に向かって自律的に動き、実験、学習、テストを行い、問題解決の方法を探ります。行き詰まったら質問をし、異なるアプローチを試し、その全工程をエビデンスとして提出します。

Orchestration（オーケストレーション）軸では、レベルが低い状態は「1エージェント、1スレッド」を意味します。中レベルでは、複数のエージェントがそれぞれ独自のワークツリーで稼働し、異なる目標に向かっているかもしれませんが、互いに隔離されています。高レベルでは、バックログ、課題トラッカー、スケジュール、その他のキューを受け取り、それを継続的なワークフローに変換できる「オーケストレーター」が存在します。人間は、何かが失敗したときにだけ介入する「例外による管理（Management by Exception）」を行うことになります。

これらのアイデアを取り入れた製品や機能には、以下のようなものがあります。

これらの機能は、単一のラダーには収まりきりません。

登るべき階段：3つの時代と1つのスタック

ラダーを下から上に読んでいくと、主体性とオーケストレーションの両方を同時に高めていく様子がイメージできるでしょう。実質的に、この6つのレベルは、私たちが通り過ぎる3つの異なる時代を表しています。

  1. 第一段階：人間が運転席に座り、エージェントは主に補助に徹し、人間の指示を待ちます。
  2. 第二段階：エージェントが限定的なタスクや目標を担当しますが、人間は依然として近くにいて、舵取りや検証を行います。
  3. 第三段階（オーケストレーションの時代）：システム自体が全体を運営し、多数のエージェントに仕事を割り振ります。人間は問題が発生したときにだけ介入する「例外による管理」へと移行します。

こう考えると話がシンプルになります。ラダーの垂直的な位置が2つの軸をうまく捉えており（オーケストレーションは上位レベルで本格化するため）、一段ずつ着実に登っていくプロセスとして理解できるからです。それでも、この登頂は私たち全員が経験している大きな変化の一部です。

エンジニアリングにおける「良い一日」とは、複数の段に触れることを意味し、時にはそれ以上の場合もあります。一つのタスクをこなす間に、これらの時代を数回行き来するのが普通です。

6つのレベルの詳細

レベル0：アシスト (Assist)

エージェントは、大抵の場合に適切で、しばしば完璧な提案をしますが、それを実行に移すかどうかは常に人間が判断します。オートコンプリート、インライン編集の提案、あるいは誰もまだ着手していない変更についてチャットで相談するような状態を想像してください。間違いの代償が大きい場合や、ごく小さな変更、あるいは自分自身の判断を形成している最中に適しています。検証は主にローカルで行われます。

レベル1：監視下の実行 (Supervised action)

エージェントはユーザーに代わって編集やコマンドの実行を行いますが、影響の大きい操作の前には必ず確認を求めます。これが多くの人にとってのデフォルトの姿勢でしょう。ローカルのサンドボックス内で実行し、変更を適用する前に承認を得る形（各承認は変更を適用しても良いという独立した検証になる）、あるいは対話型セッションで行われます。失敗のパターンは「承認疲れ」です。何を承認しているかにかかわらず、すべての承認作業が同じに感じられてしまうのです。これに対処するには、差分（diff）を精査する、ヒューリスティックに従う、承認前に別の人に確認する、あるいは「エージェントに責任を持たせる」と決めることなどが挙げられます。CodexのAuto-review機能は、境界条件の最終承認を別のレビュアー・エージェントに委任することでこの問題を解決しています。

レベル2：範囲限定のタスク委任 (Scoped task delegation)

範囲の限定されたタスクをエージェントに任せます。そのタスクには明確な目標、制約、そして「完了」の定義が必要です。人間は近くにいて、必要に応じて割り込むことはできますが、基本的には関与しません。これが現在のソフトウェアエンジニアリング界の重心です。検証の主体は人間（休息や睡眠が必要な存在）から、エージェントが生成できるエビデンスへと移ります。自動テストのパス、適切な型定義、リンターの提案、スクリーンショット、再現手順、実例による裏付けなどがそれにあたります。

レベル3：目標駆動型の自律性 (Goal-driven autonomy)

エージェントは目標を達成するために必要なあらゆることを行い、特定の条件が満たされたときだけ停止します。プロンプト・モードでは、プロンプト自体が目標になります（例：「このページのTime-to-Interactiveを1秒未満に短縮して」）。Codexではこれが「Goalモード」であり、エージェントは「計画→実行→テスト→レビュー」のステップを、成功基準を満たすまで繰り返します。Claude Codeでは、/goal, /loop, /schedule コマンドがこれにあたります。このレベルが有用であるためには、停止条件が自動化可能な方法で測定できなければなりません。

「ユーザー体験を全体的に向上させる」や「コードベースをよりテストしやすくする」といった曖昧で漠然とした目標をエージェントに与えてはいけません。静的解析をすり抜ける本番環境のバグの特定、ロード時間の短縮、明示的な any のない厳格なTypeScriptビルドの徹底、内容を把握しテストをパスした依存関係のみを残す選別など、具体的で測定可能、かつ自動化されたものを選んでください。そして、本番環境のバグを見つけるには、エージェントが本番に近い環境にいる必要があります。

レベル4：並列委任 (Parallel delegation)

多数のエージェントを並列に稼働させます。各エージェントは、タスクの隔離された一部分を担当します。このレベルでの最大のボトルネックは「分解（decomposition）」、つまり委任するための適切な切り分けを定義することです。これを支える機能には、サブエージェント、バックグラウンド・セッション、/batch、ワークツリー、エージェント・チームなどがあります。失敗のパターンは「偽の並列化」です。重複する範囲に対して多数のエージェントを同時に走らせてしまい、成果が増える代わりにマージコンフリクトや判断の重複が発生する状態です。これをうまく行うには、エージェントを互いに隔離し、それぞれが自分のファイルとステータスを所有する必要があります。また、それぞれに独自のレビューキューが必要です。そして当然、同時に走らせるエージェントの数に比例して、トークン消費のコストがかかります。人間側から見ると、オーケストレーションの負荷（税）があるため、数台を超えるとエージェントを追加する限界費用が増大します。

レベル5：例外管理によるオーケストレーション (Managed-by-exception orchestration)

何をもって成功とするか、どのようなポリシーを適用するかを定義します。マネージャー・エージェントがトリガー（新しい課題、タスク、時刻など）に基づいて起動し、ワーカー・エージェントを派遣し、進捗を監視し、出力を検証し、失敗すればリトライし、条件を満たせばより有能なエージェントや人間にエスカレーションし、結果を集約して、最終的に成果物（PRなど）とエビデンスを外部システムに返します。工場をイメージしてください。課題トラッカーやバックログが投入（インプット）であり、工場の成果物（アウトプット）が修正された課題やバグです。エージェントは、多くの障壁（および必要に応じた脱出口）を備えた適切に隔離された環境で動作し、マネージャー・エージェントによって定義された「オペレーティング・システム」だけが、その工場に期待される役割を規定します。

このオペレーティング・システムの設計は人間に委ねられます。OpenAIは「Symphony」という仕様を提案しており、そこではLinearボードが中心に据えられています。各課題がそれぞれのエージェント・ワークスペースを持ち、エージェントは自身のワークスペースにある仕様ファイルで定義された目標に向かって進捗していることを継続的に保証します。人間によるレビューは、エビデンスが生成された段階で行うことができますが、この分野の最前線（オーケストレーションの世界で最も強力なもの）は、数百、数千のエージェントを備えた「継続的なエージェント・ファクトリー」を構築することです。この段階に達すると、独立した検証がますます重要になります。実装者とレビュアー、テスト実行者とQA、セキュリティチェック、承認のためのプロセスゲートをそれぞれ分離する必要があります。

リスクと可逆性が「天井」を決める

Claude Codeを用いた高難度タスクに関するAnthropicの初期の調査では、ユーザーが途中で割り込む回数よりも、エージェント側が説明を求める回数のほうが2倍以上多かったと記憶しています。経験豊富なユーザー（50セッション未満に対し約750セッション）は、進捗を監視しつつ、自動承認や割り込みをより活用する傾向にありました。

また、人々がどのようにClaude Codeを使っているかについても幅広い分析が行われました。2025年10月から2026年4月の間に、約23万5千人による約40万セッションが調査されました。各セッションから、プロンプトごとにいくつのアクションを求めたか、どれを自動承認したか、どの頻度で割り込んだかといった判断を把握できました。結果として、計画に関する判断の約70%は人間が行っていますが、実行の約80%はClaudeが行っています。高い自律性とは、人間をループから外すことではなく、人間が「すべてのステップを実行する」段階から「次にどの方向に進むかを決定する」段階へと移行することを意味します。

大規模なAIシステムが高い自律性を持って動作しているかどうかを判断するには、以下の3つの問いを立てるべきです。

  1. エージェントの行動が間違っていると、どれくらい早く気づけるか？
  2. エージェントが行っていることを、どれくらい綺麗に元に戻せるか？
  3. エージェントの行動が正しいと、何をもって証明できるか？

もし答えが「すぐには分からない」「戻すのは非常に困難」「要約を信じるしかない」であれば、それは高い自律性とは呼べません。

エージェントの実行前には、その目的を定義する「契約」が必要です。

メトリクスが自律性の信頼を高める

事後に指標（メトリクス）を決めるだけでは不十分かもしれません。メトリクスを事前に簡潔なドキュメントにまとめておくことで、自律性はより信頼できるものになり、信頼への飛躍が少し容易になります。

成功を測る方法はたくさんありますが、自律性のレベルごとに次のようなメトリクスのトラッキングを検討してください。

これらのメトリクスは物語を語ってくれます。人間の手渡しによって忙しく働いている単一のエージェントは、「ダッシュボード付きのレベル4」と言えるかもしれません。自動取り込み、リトライ、適切なエビデンスがなければ先に進もうとしない保守的なエージェントは、「本物のゲートを備えたレベル5」です。

準備ができているかを考える

リスクの大きさと、元に戻しやすさ（可逆性）によって仕事を分類してください。自律性の適用は保守的に行い、高いレベルを裏付けるエビデンスが蓄積されるに従ってのみレベルを上げてください。強力なテストとレビュアー・エージェントに守られ、クリーンなロールバック・パスがある決済エンジンのリファクタリングは、正解となる基準（canonical truth）を欠いたドキュメントの自動化タスクよりも、はるかに高い自律性を許容できます。自律レベルはタスク名ではなく、検証プロセスに従うべきです。

4つのアンチパターン

どのようなシステムも、注意深く避けない限り、以下の4つのアンチパターンの餌食になりがちです。

  1. ステータスとしての自律性 (Autonomy as status)：エージェントの自律性評価が、無意味なステータスシンボルになってしまうこと。高い自律性が「安全性の証明」ではなく「能力の証明」として扱われ、検証が追いつかないほど過剰な負荷でエージェントを走らせてしまう。
  1. 権限のロンダリング (Permission laundering)：承認疲れという暴君に屈し、AIエージェントやツールに対して必要以上に広範なアクセス権限を与えてしまうこと。
  1. 要約による代用 (Summary substitution)：エージェントによる作業の要約がレビューの代わりになり、要約だけで十分だと思い込んでしまうこと。
  1. フリートのコスプレ (Fleet cosplay)：数十のエージェントを並列に走らせているものの、人間が依然としてすべての依存関係を手動で調整し続けている状態。

キャリブレーションの演習

エージェントの支援を受けて行った最近の10個のタスクを振り返ってみてください。各タスクについて、行使された自律レベル、関わったリスク、元に戻しやすさ、検証要件を満たすために生成されたエビデンス、レビュー時間、手戻りが必要だったか、そして選択した自律レベルが次回も適切であるかを記録してください。

安全に階段を登る方法

一度に一つの軸だけを動かしてください。まずは、防御可能な成功のエビデンス（十分に整理されていれば自律レベル1に相当）を生成する、単一の監視付きエージェントに範囲を絞ったタスクを任せることから始めます。そこから、直交する3つの方向に徐々に拡張していきます。

レベルを上げるたびに、新しい安全メカニズム（新しい失敗モードへの対処など）が必要になります。

問題を言語化しましょう。単一エージェントの長時間実行は、ドリフト（乖離）、コンテキストの腐敗、コミュニケーションの欠落、あるいは目標の逸脱を招く可能性があります。バックグラウンド作業は、前提条件の風化や不十分な引き継ぎを招く可能性があります。過剰な並列作業は、マージコンフリクトや判断の重複を招きます。過剰な定期実行は、気づかないうちにトークンを消費したり、プロンプトが古くなったりします。「例外による管理」は、長いレビュー待ち行列やアラート疲れを招く可能性があります。対策は「もっと強く信じること」ではありません。範囲を狭め、より良いエビデンスを確保し、安価なロールバック・パスを有効にし、ゲートを強化し、より明確な所有ルールを定義することです。

自律レベルの使い分け：

検証こそが常にボトルネックとなります。

現在の威勢のいい風潮やツールがどうあれ、AIエージェントと共に働くエンジニアリングチームの成熟した姿勢とは、「調整された自律性（calibrated autonomy）」です。

ボトルネックとなるのは、コーディネート、検証、メンテナンス、製品の判断、そしてインシデントからの学習です。

近い将来、私たちは「いつ働き、いつ検証し、いつ質問すべきか」を知っているループを設計することになるでしょう。しかし、エンジニアのスキルは依然として、「適切な自律レベルを選択すること」、そして「自律性の負の側面から身を守るためのパターンと防御可能なエビデンスを構築すること」にあり続けるはずです。

注：Pangramはこの記事を100%人間によって書かれたものとしてラベル付けしています：https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26