エージェントの自律性レベル

• エージェント型エンジニアリングは、プロンプト作成よりも 運用設計 に近づいており、作業ごとに許容する自律性と、それを支える 検証方式 をあわせて決める必要がある
• 単一のはしご型モデルは、1つのエージェントに対する信頼を数値で表すには有用だが、複数のエージェントを同時に扱う能力は agency と orchestration の2軸に分けて見るべきである
• 0〜5段階モデルは、提案だけを行う Assist から、例外時にのみ人が介入する Managed-by-exception orchestration まで続き、上位レベルほど目標・範囲・証拠・権限・予算が明確でなければならない
• AnthropicのClaude Code分析では、約 40万セッション と約 23.5万人 の利用データから、人が計画決定の約70%を担い、Claudeが実行の約80%を担う傾向が示された
• 成熟したエージェント活用は、高い自律性を誇示することではなく、リスクと可逆性に応じて calibrated autonomy を適用し、検証ボトルネックを管理できるかにかかっている

---

プロンプト作成から運用設計へ移行するエージェント型エンジニアリング

• エージェント型エンジニアリングの中心は、プロンプト作成から 運用設計 へ移っている
• ソフトウェアファクトリー、目標、ループ、バックグラウンドセッション、サブエージェント、フック、サンドボックス、エージェントがエージェントを承認する方式が前面に出てきている
• Claude CodeとCodexは、この変化を示す代表的な製品として扱われている
• エンジニアはリスクを減らし、巻き戻しやすくするために低い自律性を使い、明確なアクティビティや大規模コードベースのリファクタリングには、より高い自律性と並列エージェントフリートを使うことができる
• 核心となる問いは、各作業に どのレベルの自律性 を許容するか、そしてどのような検証がそのレベルを支えられるかである

単一のはしごではなく2軸で見る自律性

• Steve Yeggeの「Welcome to Gas Town」で言及された単一軸のはしごは、1つのエージェントに対する信頼を数値で表すには有用である
• 2026年初頭には、作業が委任からオーケストレーションへ移る状況でも、単一軸はリスク測定の大まかな代理指標として機能していた
• 複数のエージェントを同時に実行できるようになると、単一の段階だけでは マルチエージェント能力 を説明しにくい
• 自律性の議論では、しばしば異なる2つの問いが混同される
  • 単一のエージェントを人間からどれだけ離して送り出せるか
  • 複数のエージェントをどれだけうまく調整できるか
• これを分けて考えるには2軸が必要である
  • agency: 1つのエージェントが、提案、限定的な作業、目標達成をどれだけ自律的に実行できるか
  • orchestration: 1本のスレッドから複数のタスクツリー、バックログ・課題トラッカー・スケジュールベースの継続作業まで、どれだけ調整できるか

agencyとorchestrationの意味

• agency軸の低いレベルでは、エージェントは候補となる行動を提案し、人の判断を待つ
• 中間レベルでは、エージェントは特定の作業を実行するが範囲は限定され、何をしたかを証拠付きで継続的に報告するため、人が調整できる
• 高いagencyでは、エージェントは目標に向かって実験、学習、テスト、ブロッカー対応、質問、別アプローチの試行まで行い、その結果を 証拠 として返す
• orchestration軸の低いレベルは、1つのエージェントと1本のスレッドである
• 中間レベルでは、複数のエージェントがそれぞれ分離されたworktreeで異なる目標に取り組む
• 高いレベルでは、オーケストレーターがバックログ、課題トラッカー、スケジュール、キューを継続作業へ変換し、人は失敗時にのみ介入する management by exception の形になる
• 関連機能と製品の例は次のとおり
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, サブエージェント、フック、チェックポイント、エージェント委任と管理方式、バックグラウンドセッション、エージェントチームパターン、/schedule 引数
  • Codex: ローカル・クラウドスレッド、Goal mode、worktree、Automations、サブエージェント、レビュー・パネル、GitHubコードレビュー、フック、サンドボックス、Auto-review、rerun

3つの時代と6つのレベル

• はしごを下から上へ読むと、agencyとorchestrationを同時に高めるように見える
• 6つのレベルは3つの時代に分かれる
  • 人が運転席にいて、エージェントは補助し、人の操作を待つ時代
  • エージェントが限定された作業や目標を担うが、人が調整し検証する時代
  • システムが複数エージェントに作業を割り振り、人は問題が起きたときに主に介入するオーケストレーション時代
• 実際のエンジニアリングでは、1日のうちに複数のレベルを行き来して作業するのが自然である

Level 0: Assist

• エージェントは概ね良く、ときには完璧な提案をするが、実行するかどうかは常に人が決める
• 例としては、自動補完、インライン編集提案、まだ誰も所有していない変更をチャットで議論する状況がある
• コストの大きいミス、非常に小さな変更、判断を固めている途中の作業に適している
• 検証は大半が ローカル で行われる

Level 1: Supervised action

• エージェントが代わりに編集したりコマンドを実行したりするが、重要な実行前には人に許可を求める
• これは大半の人が使う基本姿勢に近い
• ローカルサンドボックスで変更適用前に承認を受けることも、対話セッションで実行することもできる
• 各承認は、その変更を適用して問題ないかを確認する独立した検証として機能する
• 主な失敗モードは 承認疲れ である
  • 何を承認しても、すべての承認が似たように感じられることがある
  • diffをざっと確認する、ヒューリスティックに従う、他人に確認する、エージェントに責任を持たせる、といった形で対処できる
• Codex Auto-reviewは、境界条件における最終承認を別のレビュアーエージェントに委任することでこの問題に対処する

Level 2: Scoped task delegation

• 限定された作業をエージェントに任せる段階である
• 作業には明確な目標、制約、完了状態としての作業定義が必要である
• 人は近くにいて中断できるが、ほとんどは直接関与しない
• ソフトウェアエンジニアリングでは中心に近いレベルとして扱われる
• 検証は、人の直接確認から、エージェントが生成できる 証拠 へ移る
  • 通過した自動テスト
  • 適切な型
  • lint提案
  • スクリーンショット
  • 再現手順
  • 例示ベースの出典

Level 3: Goal-driven autonomy

• エージェントが、特定条件が満たされるまで目標達成に必要なことを実行する
• プロンプトモードでは、プロンプト自体が目標になる
  • 例: 「このページのtime-to-interactiveを1秒未満にできるか？」
• CodexではGoal modeがこれにあたり、エージェントは plan -> act -> test -> review を繰り返し、成功基準をこれ以上満たせなくなったら停止する
• Claude Codeでは /goal, /loop, /schedule コマンドがこれにあたる
• このレベルが有効であるためには、停止条件が自動化可能な形で 測定可能 でなければならない
• 「ユーザー体験を全体的に改善する」「コードベースをよりテストしやすくする」といった曖昧な目標は適さない
• より適した目標は、具体的で、測定可能で、自動化可能であるべきだ
  • 静的解析をすり抜ける本番バグを見つける
  • 読み込み時間を短縮する
  • 明示的な any がない厳格なTypeScriptビルドを保証する
  • 理解可能でテストを通る依存関係だけが残るよう、全依存関係を分類する
• 本番バグを見つけるには、エージェントが 本番に近い環境 にいる必要がある

Level 4: Parallel delegation

• 複数のエージェントが並列で作業する段階である
• 各エージェントは作業の分離された断片を担当する
• 最大のボトルネックは、どの断片を委任するかを決める 分解 である
• 対応機能として、サブエージェント、バックグラウンドセッション、/batch, worktree, エージェントチームなどがある
• 主な失敗モードは見せかけの並列性である
  • 複数のエージェントが重複する断片を同時に扱うと、作業量が増える代わりにmerge conflictや重複した判断を生みやすい
• うまく運用するには、エージェント同士を隔離する必要がある
  • それぞれが所有するファイルと状態を持つべきである
  • それぞれ独自のレビューキューも持つべきである
• エージェントごとにトークンコストが発生し、同時実行されるエージェント数に比例する
• 人間側では、一定数を超えるとエージェント追加の限界コストが オーケストレーション税 によって増加する

Level 5: Managed-by-exception orchestration

• 成功の定義と適用するポリシーを人が定め、manager agentがトリガーに応じて起動して作業を配分する
• トリガーの例としては、新しい課題、新しい作業、時計がある
• manager agentは作業者エージェントを配置し、進捗を監視し、成果物を検証し、失敗時には再試行する
• 条件が満たされれば、より有能なエージェントや人へエスカレーションし、結果を集約してPRのような作業成果物と証拠を外部システムへ返す
• この段階は ファクトリー にたとえられる
  • 入力は課題トラッカーやバックログ
  • 出力は解決済みの複数の課題やバグ
• エージェントは、十分な境界と必要時の脱出口を備えた隔離環境で作業する
• このファクトリーが何をするかは、manager agentが定義したオペレーティングシステムによって決まる
• OpenAIはSymphony向けの spec を提案しており、Linearボードを中心に据えている
  • 各課題は独自のエージェントworkspaceを持つ
  • エージェントは、自分のworkspaceのspecファイルで定義された目標に向かって継続的に前進しているかを確認する
• オーケストレーションの最前線は、数百から数千のエージェントが動く継続的なエージェントファクトリーを作ることである
• この段階では独立検証がより重要になる
  • 実装者とレビュアーの分離
  • テスト実行者とQAの分離
  • セキュリティ検査の分離
  • 受け入れのためのプロセスゲートの分離

リスクと可逆性が自律性の上限を決める

• AnthropicのClaude Codeに関する研究では、最も難しい作業の一部で、Claude Codeはユーザーによる中断より2倍以上の頻度で明確化の質問を行っていた
• 経験豊富なユーザーは約750セッションを持つユーザーで、50セッション未満のユーザーよりも、自動承認や中断をより頻繁に活用し、進捗を見守る傾向があった
• Anthropicのより広い分析は、2025年10月から2026年4月までの約23.5万人・約40万セッションを対象としている
• 各セッションでは、ユーザーがプロンプトごとに要求した行動数、自動承認した項目、中断頻度といった判断を把握できた
• 人は計画決定の約 70% を行い、Claudeは実行の約 80% を担っている
• 高い自律性とは、人をループの外へ追い出すことではなく、人が各ステップを実行する方式から、次の方向を決める方式へ移ることである
• 大きなAIシステムが高い自律性で動作しているかを判断するには、3つの問いが必要である
  • 何を間違えているかを、どれだけ早く把握できるか
  • その作業を、どれだけきれいに巻き戻せるか
  • その作業が正しいことを、何が証明するのか
• もし答えが「すぐには分からず、巻き戻しが難しく、要約を信じるしかない」であれば、それは高い自律性ではない

エージェント実行前の契約に入れるべき項目

• すべてのエージェント実行前には、何をしようとしているのかを定義する 契約 が必要である
• 契約には次の項目を含めるべきである
  • 目標: 活動や手法ではなく、達成したい結果
  • 範囲: 作業するドメインと許可された手法
  • 非目標: 目的に含まれないもの
  • ツールと権限: エージェントが外部世界と相互作用する方法
  • 停止条件: いつ止まるか、可能なら測定可能な変数
  • 証拠: 完了を独立に確認できるテスト、スクリーンショット、ログ、データベースレコードなど
  • エスカレーション: どの状況で誰が介入するか、誰がエージェントを実行するか
  • 予算: 時間、労力、トークン上限
• トークンは大規模AIモデルにおける予算であり、試行回数や並列度に対する制限も含められる

指標は自律性を少しだけ信頼しやすくする

• 指標を事後的に決めるだけでは十分でないことがある
• 指標は簡潔な文書として事前に配置でき、自律性をより信頼しやすくする
• 自律性レベルごとに追跡できる指標の例は次のとおり
  • 介入間の平均時間
  • 受け入れられた作業基準における最長無人実行時間
  • サンドボックス内で実行された行動とエスカレーションされた行動の比率
  • 自動承認された行動と拒否された行動の比率
  • 人の1指示あたりのエージェント行動平均数
  • 明確化要求率
  • 中断要求率
  • 受け入れられた変更あたりのレビュー時間
  • 信頼レベル別の再作業率
  • 信頼レベル別の欠陥流出率
  • 受け入れられた変更あたりのトークンコスト
• 人が渡す作業で常に忙しい単一エージェントは、ダッシュボード付きのLevel 4に近く、自動化された受付・再試行・十分な証拠がなければ進まない保守的なエージェントは、実際のゲートを持つLevel 5に近い

準備度と自律性レベルの選び方

• 作業は、リスクと可逆性に応じて分類すべきである
• 自律性は保守的に適用し、より高いレベルを支える証拠が積み上がったときにのみ引き上げるべきである
• 強いテスト、レビュアーエージェント、明確なロールバック経路を備えた決済エンジンのリファクタリングは、正解基準のない文書自動化作業よりも高い自律性を支えられる可能性がある
• 自律性レベルは作業名ではなく、検証プロセス に従うべきである

4つの自律性アンチパターン

• Autonomy as status

  • エージェントの自律性等級が、意味のない地位バッジのように機能する
  • 高い自律性が安全性ではなく能力の証拠のように扱われ、検証が支えられないレベルでエージェントが動かされる
  • 正しい自律性レベルを選び、越えてはいけない線を守る人を称賛し報いるべきである

• Permission laundering

  • 承認疲れのために、AIエージェントやツールへ必要以上に広いアクセス権を与えてしまう
  • サンドボックスプロファイル、範囲を制限した書き込みルート、許可コマンド一覧、フック、Auto-reviewのような境界を強化すべきである

• Summary substitution

  • エージェントの作業要約がレビューの代わりになってしまう
  • 手動レビューと同等の証拠パッケージを一緒に束ねるべきである
  • diff、テスト、ログ、スクリーンショット、レビュアーの発見事項、リスク、ギャップが含まれうる

• Fleet cosplay

  • 数十のエージェントを並列実行しているのに、人がすべての依存関係を手動で調整し続けている
  • 共有状態、所有権ルール、より良い依存関係追跡によって、手動調整の必要性を減らせる
  • より小さなWIP制限は、調整手順をコード化・文書化することに集中させ、オーケストレーション自動化につながる可能性がある

安全にレベルを上げる方法

• 最近エージェント支援を受けた作業10件を見直す較正演習が提案されている
  • 各作業の自律性レベル
  • リスク
  • 巻き戻しやすさ
  • 検証要件を満たすために生成された証拠
  • レビュー時間
  • 再作業の有無
  • 次回も同じ自律性レベルが適切か
• 一度に上げる軸は1つだけにすべきである
• 出発点は、防御可能な成功証拠を生み出す単一のsupervised agentが、1つの限定作業を実行する形である
• その後、3方向に段階的に拡張する
  • 読み取り中心の探索作業を並列化する
  • 限定されたファイル所有ルールを持つ別worktreeで書き込みエージェントを追加する
  • 反復自動化を追加した後、課題や音声などに基づくエージェント主導オーケストレーションを追加する
• 各段階の引き上げには、新しい失敗モードに対応する新しい安全装置が必要である
• 失敗モードは次のとおり
  • 長い単一エージェント実行: ドリフト、コンテキスト劣化、コミュニケーション漏れ、目標逸脱
  • バックグラウンド作業: 古い前提、弱い引き継ぎ
  • 過度な並列作業: merge conflict、重複判断
  • 過度な反復作業: 静かなトークン消費、古いプロンプト
  • managed-by-exception: 長いレビューキュー、通知疲れ
• より強く信頼することではなく、範囲を狭め、より良い証拠を確保し、より安価なロールバック経路を作り、ゲートを強化し、所有権ルールをより明確にすべきである

レベル別に適した用途

• Level 0は、繊細な作業や判断を固めている最中の状況に最も適している
• Level 1は、よく理解された境界に近い大半の探索に適している
• Level 2は、未知の依存関係や予期しない問題がありうる大半の限定作業に適している
• Level 3は、成功条件を十分に明確に表現できる場合に適している
• Level 4は、作業を成功条件に基づいてきれいに分割できるときに適している
• Level 5は、複数の成功条件の間に必要な調整とコミュニケーションが完全にコード化された後に適している

検証は依然としてボトルネックである

• 現在の自信やツール水準にもかかわらず、AIエージェントと働く成熟したエンジニアリングチームの姿勢は calibrated autonomy である
• 近い将来には、いつ作業し、いつ検証し、いつ質問するかを理解したループを設計しなければならない
• エンジニアの力量は、適切な自律性レベルを選び、その暗い側面を防ぐパターンと、防御可能な証拠を作ることに引き続き置かれる