エージェンティックエンジニアリングに関するほとんどの議論では、アクションはプロンプトから操作へと変化しています。ここでは霧の中のフロンティアを覗いています：ソフトウェアファクトリー、ゴール、ループ、バックグラウンドセッション、サブエージェント、フック、サンドボックス、エージェントを承認するエージェント。未来のクリエイターの多くにとって、この振る舞いは初日から製品に組み込まれるでしょう：Claude Code や Codex はそのシフトを直接的に示しています。
エンジニアの観点からは、リスクを制限し可逆性を高めるために低自律性を使用しますが、明示的なアクティビティにはより高い自律性を使用し、並列エージェント群で大規模なコードベースを安全にリファクタリングします。アクションに関する中心的な問いは常に次のようになります：このタスクにはどのレベルが適切で、そのレベルを正当化する検証は何か？
フロンティアの最先端はマネージャーエージェントです。これはトリガーで起動し、ヘルパーに委任しながら出力を継続的に検証し、人間が判断すべき決定のみを返します。このようなセットアップを使用している人々は、すでに数百または数千のエージェントを、主に常緑のコードベースで実行しているかもしれません。自律性に関するほとんどの考えと同様に、規模の捉え方は依然として人それぞれ異なります。
最もよく言及されるスケールは、Steve Yegge の単一軸のラダーで、「Welcome to Gas Town」や The Pragmatic Engineer で言及されています。これは、自分がどれだけ AI ネイティブかを示す数値が欲しい場合の良い参考になります。このラダーは、単一のエージェントに対する信頼度を測定するための単一の数値を提供します。以下がその一例です：
2026 年初頭には、作業が委任からオーケストレーションへと移行し始めていたとしても、これはリスクを測定するためのかなり良い指標でした。しかし今日では、多くのスキルセットは、一度に多数のエージェントを実行できる場合に重要性とレバレッジが増す可能性があります。単一のラングでは、マルチエージェントのスキルを位置づけることはできません。
その代わりに、私が見てきた自律性に関する議論のほとんどは、分離されるべき 2 つの質問を混同しています：この単一のエージェントを自分からどれだけ遠くまで離すことを許すのか、そして多数のエージェントを調整するスキルは何か？
これら 2 つの次元を別々に捉えるために、2 つの軸を使用します：エージェンシーとオーケストレーション。
エージェンシー軸では、低い方はアクション候補を提案し、決定を待つことを含みます。
中間は、エージェントが特定のタスクに取り組んでいるが、その範囲を区切り、継続的に報告を行い、その作業内容と証拠を提供するため、あなたが steer し続けられる状態です。
高いエージェンシーの端では、エージェントは目標に向かって作業し、実験、学習、テスト、問題解決方法の模索、障害発生、質問、異なるアプローチの試行を行い、これらすべての作業を証拠として返します。
オーケストレーション軸では、低いは 1 つのエージェント、1 つのスレッドを意味します。中間では、複数のエージェントがそれぞれ独自のワークツリーで作業し、おそらく異なる目標に向かって作業していますが、分離されています。高い端では、バックログ、課題トラッカー、スケジュール、その他のキューを受け取り、それを継続的な作業に変えるオーケストレーターがあり、障害が発生した場合にのみ介入する必要があります：「例外による管理」。これらのアイデアを取り入れた製品や機能には以下が含まれます：
- Claude Code の /plan、/goal、/loop、/background、/batch、/code-review、/security-review モード、サブエージェント、フック、チェックポイント、エージェント委任と管理プラクティス、バックグラウンドセッション、エージェントチームパターン、/schedule 引数
- Codex のローカル/クラウドスレッド、Goal モード、ワークツリー、Automations、サブエージェント、レビューペイン、GitHub コードレビュー、フック、サンドボックス、Auto-review、および再実行
これらの機能は、単一のラダーには当てはまりません。
登攀：3 つの時代と単一のスタック
ラダーを下から上へ読むと、エージェンシーとオーケストレーションの両方を同時に登っていることになります。実際には、6 つのレベルは、私たち全員が通過する 3 つの異なる時代を表しています：
まず、あなたがドライバーズシートに座り、エージェントは主に支援し、あなたが steer するのを待っています。
第二に、エージェントが境界のあるタスクや目標を担当しますが、あなたは依然として steer し、その作業を検証するために近くにいます。
そして第三に、オーケストレーションの時代では、システムがショーを運営し、多くのエージェントに作業を分散でき、あなたは主に問題が発生した場合に介入する必要があります：「例外による管理」。
これにより物事は単純化されます。なぜなら、ラダー上の垂直位置が 2 つの軸をきれいに捉えているからです（オーケストレーションは上部近くでのみキックインします）。そのため、ラングを通じた単一の安定した登攀となります。それでもなお、この登攀は私たち全員が経験しているシフトの一部です。
エンジニアリングの良い日には、複数のラングに触れることがあり、時にはそれ以上になることもあります：タスクの過程で時代を数回切り替えるのは普通のことです。
6 つのレベルの詳細
レベル 0：アシスト
エージェントは、ほとんどが良好で、しばしば完璧な提案を行いますが、それらが実行に値するかどうかは常にあなたが決定します。オートコンプリート、インライン編集提案、または誰も所有権を主張していない変更について議論するチャットセッションなどが考えられます。コストのかかるエラー、小さな変更、または自分自身の判断を形成している場合に使用します。検証は主にローカルで行われます。
レベル 1：監視付きアクション
エージェントがあなたに代わって編集やコマンドの実行を行い、重要なことを実行する前にあなたに尋ねます。これはほとんどの人にとってデフォルトの姿勢です。変更を適用する前に承認を得るローカルサンドボックスで行うことができます（各承認は、変更を適用しても問題ないという独立した検証です）。またはインタラクティブセッションで行うこともできます。障害モードは承認疲れです。承認する内容に関係なく、すべての承認が同じように感じられます。これを解決するには、差分を一目確認し、いくつかのヒューリスティックに従い、承認前に別の人に確認するか、単にエージェントに責任を任せることに同意するかもしれません。Codex Auto-review は、境界条件の最終承認を別のレビューアエージェントに委任することでこの問題を解決します。
レベル 2：スコープ付きタスク委任
境界のあるタスクをエージェントに引き渡します。そのタスクには明確な目標、制約、および完了の定義があります。あなたは近くに留まり、中断することはできますが、基本的には関与しません。これはソフトウェアエンジニアリングの世界における重心です。検証はあなたから（休息や睡眠が必要かもしれません）、エージェントが生成できる証拠（自動テストの合格、適切な型、lint の提案、スクリーンショット、再現手順、例による来歴など）へと移行しています。
レベル 3：目標駆動型自律性
エージェントは目標を達成するために必要なことをすべて行い、何らかの条件が満たされた場合にのみ停止します。プロンプトモードでは、プロンプト自体が目標になります（例：「このページの time-to-interactive を 1 秒未満にできますか？」）。Codex では、これは Goal モードです。エージェントは、成功基準を満たさなくなるまで plan -> act -> test -> review のステップを繰り返します。Claude Code では、/goal、/loop、/schedule コマンドです。このレベルが有用であるためには、停止条件が自動化可能な方法で測定可能でなければなりません。
漠然とした曖昧な目標（「ユーザー体験を全体的に改善する」「コードベースをよりテストしやすくする」など）については、エージェントに支援を依頼しないでください。具体的で測定可能かつ自動化されたものを選びましょう：静的解析では発見できない本番環境のバグを見つける、読み込み時間を短縮する、明示的な any なしで厳格な TypeScript ビルドを確保する、理解していてテストに合格するものだけを保持するようにすべての依存関係をトリアージする、など。そして最後に、本番環境のバグを見つけるには、エージェントが本番環境に近い環境にいる必要があります。
レベル 4：並列委任
多くのエージェントを並列に作業させます。各エージェントはタスクの分離されたスライスに取り組みます。このレベルでの最大のボトルネックは分解です：委任する適切なスライスを定義することです。サポートには以下が含まれます：サブエージェント、バックグラウンドセッション、/batch、ワークツリー、エージェントチームなど。障害モードは疑似並列処理です：重複するスライスに対して一度に多数のエージェントを実行すると、より多くの作業の代わりにマージ競合や重複した決定が発生します。これを適切に行うには、エージェントは互いに分離され、それぞれが独自のファイルとステータスを所有する必要があります。また、各エージェントには独自のレビューキューが必要です。そして最後に、各エージェントは、同時に実行されるエージェントの数に比例したコスト（消費されるトークンの観点から）を負担します。人間側では、オーケストレーション税により、エージェントを追加する限界コストは数台を超えると上昇します。
レベル 5：例外による管理のオーケストレーション
成功の姿と適用すべきポリシーを定義します。マネージャーエージェントはトリガー（新しいイシュー、新しいタスク、時計など）に基づいて起動し、ワーカーエージェントをディスパッチし、その進捗を監視し、出力を検証し、障害時に再試行し、条件が満たされた場合により有能なエージェントや人間にエスカレートし、結果を集約し、最終的に成果物（PR など）と証拠を外部システムに返します。工場を想像してください：課題トラッカーやバックログが入力であり、工場の成果物が出力です（つまり、多くの修正されたイシューやバグ）。エージェントは、多くの壁（そして必要に応じて脱出ハッチ）を備えた適切に分離された環境で動作し、マネージャーエージェントによって定義されたオペレーティングシステムのみが、工場が何を行うことが期待されているかを定義します。
このオペレーティングシステムの設計は人間に委ねられています。OpenAI は、中心に Linear ボードを持つ Symphony の仕様を提案しています：各イシューは独自のエージェントワークスペースを取得し、エージェントは独自のワークスペース内のスペックファイルで定義された目標に向かって進捗していることを継続的に確認します。人間のレビューは証拠が生成される高度で行うことができますが、フロンティア（つまり、オーケストレーションの世界で最も強力なもの）は、数百または数千ものエージェントを擁する継続的なエージェントファクトリーを構築することです。この登攀の時点では、独立した検証（実装者とレビューアの分離、テストランナーと QA の分離、セキュリティチェックの分離、受け入れのためのプロセスゲート）がますます重要になります。
リスクと可逆性が天井を設定する。
以前、Anthropic の研究を読んだことを覚えています。Claude Code を使った最も難しいタスクのいくつかで、エージェントはユーザーが中断した回数の 2 倍以上も明確化を求めたというものです。経験豊富なユーザー（約 750 セッション対 50 未満）は、自動承認して中断し、進捗を監視する傾向が高かったです。
また、人々が Claude Code をどのように使用しているかについて、より広範な分析も行いました。2025 年 10 月から 2026 年 4 月までの間に、約 235,000 人から約 400,000 セッションを調査しました。各セッションから、各プロンプトで何回のアクションを依頼するか、そのうちどれを自動承認するか、どれくらいの頻度で中断するかなど、人々が行う決定を把握できました。人々は計画決定の約 70% を行いますが、Claude は実行の約 80% を行います。高い自律性とは、人々をループから排除することではなく、すべてのステップを実行させることから、次にどの方向に進むかを決定させることへの移行です。
大規模な AI システムが高い自律性で動作しているかどうかを判断したい場合、尋ねるべき 3 つの質問は次のとおりです：
- その動作について自分たちが間違っていることを、どれだけ早く知ることができるか？
- その動作をどれだけきれいに元に戻すことができるか？
- その動作について自分たちが正しいことを証明するものは何か？
これら 3 つすべての答えが「すぐにはわからない、非常に困難である、サマリーを信頼する」であれば、それは高い自律性ではありません。
エージェントの実行はすべて、それが何をしようとしているのかを定義する契約が先行する必要があります。
目標：達成しようとしていること（アクティビティやテクニックではなく、成果）。
スコープ：どのドメインで動作し、どのテクニックが許可されているか。
非目標：目的の一部ではないもの。
ツールと権限：エージェントが世界とどのように相互運用できるか。
停止条件：いつ停止するか。理想的には測定可能な変数。
証拠：何かが行われたことを確認するために使用できる特定のテスト、スクリーンショット、ログ、データベースレコード、またはその他の指標（エージェントから独立）。
エスカレーション：どのような状況で誰が関与するか（エージェントを実行する人を含む）。
そして予算：タスクに費やされる時間、労力、トークンの制限（トークンは大規模 AI モデルの予算です。タスクを試行できる回数の制限や並列度の制限を含めることもできます）。
メトリクスが自律性を少しだけ信頼性の高いものにする
事後的にメトリクスを決定するだけではおそらく不十分です。メトリクスは事前に、簡潔なドキュメントで設定することができます。そして、それは自律性をより信頼できるものに感じさせ、信仰の飛躍を少しだけ容易にします。
成功を測定する方法はたくさんありますが、各レベルの自律性に対してこれらのメトリクスのいくつかのバージョンを追跡することを検討してください：
- 介入間の平均時間
- 受け入れられた作業で最長の成功した無人実行
- サンドボックスで実行されたアクションとエスカレーションされたアクションの割合
- 自動承認されたアクションと拒否されたアクションの割合
- 人間の指示あたりのエージェントアクションの平均数
- 明確化要求率 / 中断要求率
- 受け入れられた変更あたりのレビュー時間
- 各信頼レベルでの手戻り率
- 各信頼レベルでの欠陥流出率
- 受け入れられた変更あたりのトークンコスト
このようなメトリクスはストーリーを語ることができます：人間の引き継ぎで忙しくしている単一のエージェントは、ダッシュボード付きのレベル 4 です。自動化された intake、リトライ、および適切な証拠なしには進もうとしない保守的なエージェントは、実際のゲートがあるレベル 5 です。
準備態勢について考える
リスクと元に戻しやすさによって作業を分類します。自律性は保守的に適用し、より高いレベルをサポートする証拠が蓄積された場合にのみ上昇させます。強力なテストとレビューアエージェントによって保護され、クリーンなロールバックパスを持つペイメントエンジンのリファクタリングは、正規の真実が欠如しているドキュメント自動化タスクよりもはるかに高い自律性をサポートできます。自律性のレベルは、検証プロセスに従うべきであり、タスク名に従うべきではありません。
4 つのアンチパターン
どのシステムも、注意深く回避しない限り、これら 4 つの自律性アンチパターンの犠牲になりがちです。
ステータスとしての自律性 - エージェントの自律性評価が意味のないステータスのバッジになる。高い自律性は安全性ではなく能力の証明として扱われ、検証がサポートする以上にエージェントが酷使される。修正：正しい自律性レベルに落ち着き、越境を執拗に回避する人々を称賛し報いる。
許可のロンダリング - 承認疲れの暴政により、必要以上に大幅に広いアクセス権を AI エージェントやツールに付与してしまう。修正：より良い境界が常に修正であり、サンドボックスプロファイル、スコープ付き書き込み可能ルート、許可リスト化されたコマンド、フック、Auto-review など。
サマリーによる代替 - エージェントの作業サマリーがレビューに取って代わり、サマリーで十分であると仮定する。修正：完全な手動レビューと同じ証拠パッケージ（差分、テスト、ログ、スクリーンショット、レビューア所見、リスク、ギャップなど）をバンドルし、認知的降伏を避ける。
フリートのコスプレ - 数十のエージェントが並列に実行されるが、人間はすべての依存関係を手動でオーケストレーションし続ける。修正：共有状態、所有権ルール、およびより良い依存関係追跡により、手動で調整する必要性が徐々に減少する。WIP 制限を小さくすることで、オーケストレーションが自動化されるまで、調整されたステップのエンコードと文書化に集中せざるを得なくなる。
キャリブレーション演習
エージェント支援で行った直近の 10 個のタスクをレビューしてください。各タスクについて、行使された自律性レベル、関連するリスク、作業の元に戻しやすさ、検証要件を満たすために生成された証拠、レビュー時間、必要だった手戻りの有無、次回も選択された自律性レベルが適切かどうかを記録してください。
安全に登る方法
一度に 1 つの軸を移動します。まず、単一の監視付きエージェントで、防御可能な成功の証拠を生成する単一のスコープ付きタスクを実行します（十分に整理されていれば自律性レベル 1）。次に、3 つの直交する方向に徐々に拡大します。読み取り主体の探索タスクを並列化します（自律性レベル 4）。ファイル所有権ルールが制約された別々のワークツリーで動作する書き込みエージェントを追加します（自律性レベル 4）。定期的な自動化を追加し、次にイシュー、音声などに基づくエージェント主導のオーケストレーションを追加します。レバーを一段上げるごとに、新しい安全機構（新しい障害モードなど）が必要になります。
名前を付けてください：より長い単一エージェント実行は、ドリフト、コンテキストの腐敗、コミュニケーションの欠落、または目的の逸脱につながる可能性があります。バックグラウンド作業は、古い前提と弱い引き継ぎにつながる可能性があります。並列作業が多すぎると、マージ競合や重複した決定につながる可能性があります。繰り返し作業が多すぎると、サイレントなトークン消費や古いプロンプトにつながる可能性があります。例外による管理は、長いレビューキューとアラート疲れにつながる可能性があります。より強く信頼するのではなく、スコープを狭め、より良い証拠を確保し、より安価なロールバックパスを有効にし、ゲートを強化し、より明確な所有権ルールを定義します。
自律性レベルを使用する：
- レベル 0 は、繊細な作業や、まだ判断を形成している場合に最適です。
- レベル 1 は、よく理解されている境界の近くで作業が行われる場合、ほとんどの探索に最適です。
- レベル 2 は、未知の依存関係や予期せぬ落とし穴がある可能性を認識した上で、ほとんどの境界のあるタスクに最適です。
- レベル 3 は、成功条件を十分な明確さで述べることができる場合に最適です。
- レベル 4 は、作業をこれらの成功条件に沿ってきれいに分割できる場合に最適です。
- レベル 5 は、さまざまな成功条件にわたって必要な調整とコミュニケーションが完全にエンコードされた場合に最適です。
検証は常にボトルネックになります。
現在の虚勢と現在のツールにもかかわらず、AI エージェントと協力するエンジニアリングチームの成熟した姿勢は、較正された自律性です。
ボトルネックは、調整、検証、メンテナンス、製品判断、インシデント学習です。
近い将来、いつ作業し、いつ検証し、いつ質問するかを知るループを設計したいと思うでしょうが、エンジニアのスキルは依然として、適切な自律性レベルを選択し、その暗い側面から守るパターンと防御可能な証拠を構築することにあります。
注：Pangram はこの記事を 100% 人間が書いたものとラベル付けしています：https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
