この1年、「エージェンティックエンジニアリング」に関する議論は、ハーネスやループ、フリート、ソフトウェアファクトリーへと移ってきました。私の意見としては、エンジニアはアウターループ、つまりこれらのシステムに対する説明責任を所有すべきです。これは、Fable や GPT-5.6 のような強力なモデルが利用可能になるにつれて、ますます重要になります。
エージェントにはレバレッジがあり、レバレッジには義務が伴います。何が変わったのか、なぜそれが安全だったのか、そして間違っていた場合に何が起こるのかを、正確に説明できる人がいなければなりません。 そうでなければ、その行動を正当化することはできません。その結果、そもそも組織が彼らを求める可能性は低くなります。
そこで、3 つの用語についてお話ししたいと思います。1 つ目は、品質です。これは、システムを公開する前に導入するすべてのチェックを指します。これらのチェックはエビデンスを生成し、そのエビデンスから私たちは判定を導き出します。
2 つ目は、判定です。これは、成果物が依存システムに入る前に行う最終的な決定を指します。私はこのコンテンツのライン責任者です。私の名前で出荷される成果物を生み出すチームを率いています。モデルが文章を書くかもしれませんが、判定を下すのは私です。私の決定なしに、私のチームの成果物が依存システムに入ることはありません。判定とは、出荷、ブロック、リダイレクト、応答の絞り込み、ガードレールの追加、または完全な拒否といった、本番運用上の決定です。
3 つ目は、応答可能性です。これは、誰かに尋ねられたら、その理由を説明できるという保証を指します。
言い換えれば、私たちのエージェント（私はこれを、モデルと、ファイル、ツール、メモリ、スキル、サンドボックス、パーミッション、可観測性、リカバリからなるハーネスと定義します）が、私たちのループ（私はこれを、調査、実装、検証、そして繰り返しと定義します）を実行するものです。そして、それが私たちのソフトウェアファクトリーを生み出します。
モデルは単なるエンジンです。ハーネス（ツール、メモリ、パーミッション、サンドボックス、テスト）は、そのエンジンの周りに構築する車のようなもので、実際の作業を安全に実行できるようにするものです。
そのハーネスを繰り返し可能なサイクル（調査、実装、検証、繰り返し）で包み込みます。ループとは、1 回の良好な実行が、再び実行できる信頼できるプロセスになるための仕組みです。そのハーネスを繰り返し可能なサイクル（調査、実装、検証、繰り返し）で包み込みます。このサイクルでは、モデル自身の主張ではなく、独立したチェックが作業の完了を判断します。
ここで、複数のループを同時に実行します。ファクトリーとは、ループをスケールさせたものです。エージェントは内部で作業を出荷し、人間は境界部分での決定を所有します。
そして、そのファクトリーの核心にあるのは、システムの内部と外部の間の慎重な境界です。 システム内部では、私たちは入力を収集します（プロダクトチームの意向、以前に出荷した作業の知識、最近のインシデント、ユーザーからの具体的なフィードバックなど）。エージェントループはタスクを調査し、計画を実装し、結果を検証します。その後、エビデンスがその境界を越えます。依存システムを所有する人間は、そのエビデンスを確認し、続行するかどうかを判断します。
そして、これこそが、私たちが実現しようとしている変化です。以前は、エージェントは実行ループの内部ループを行っていました。今では、彼らは内部の実行ループを実行しています。エンジニアはアウターループを所有します。
システム内部では、エージェントが行っていることは実質的に 1 種類だけです。それは「能力」です。タスクを調査し、計画を実装し、結果をテストし、報告する能力です。これはモデルの能力です。そして、前述したように、その未来はすでに到来しています。
システム外部には、1 種類のものがあります。それは「主体性」です。決定し、検証し、承認し、所有するという主体性です。
結局のところ、私たちはまだコードについて話しているのです。それが適切な場所に存在し、自分のやっていることを理解している人々によって実行される必要があるだけです。
AI コードの可能性は、もはや限界的なものではありません。Sonar の 2026 年の調査では、チームに AI の支援を受けたコミットの割合を尋ねました。その割合は小さかったものの、無視できるものではありませんでした。そして、回答者の数名は、AI 支援を受けたコミットの割合が大幅に増加すると予想していました。Sonar の 2026 年「State of Code」レポート によると、コミットされたコードの 42% が AI によって生成されたか、AI の大幅な支援を受けたものであり、その割合は頭打ちになることなく、今後も増加し続けると予想されています。
つまり、創造は安価になっています。より希少なリソースは、レビュー、検証、理解、そしてメンテナンスです。
私たちは、生成の速度を、制御の速度よりも速く進めてしまいました。その結果、信頼と検証のギャップが生じています。私たちが話を聞く多くの人々は、依然として AI コードに対してある程度の不信感を表明しています。しかし、その不信感を一貫して検証プロセスに組み込んでいる人は、それほど多くないようです。
そして、それは危険な立場です。AI コードの信頼性を検証するための、より安価で明確な方法が必要になります。
GitLab の 2026 年 6 月のレポートを見ると、ガバナンスに関する質問が変化していることがわかります。GitLab の 2026 年 6 月の AI 説明責任に関する調査 では、レビューと検証が AI を使用する際の現在のボトルネックであり、さらに憂慮すべきことに、ガバナンスは通常、コード作成後、つまりリスクを受け入れ、所有権を失った後に行われることが示されています。今日、重要なのは制御だけではありません。システムにどのような制約を設定するかです。エビデンスを使ってどのように作業をチェックし、チームにどのように説明責任を課すかです。AI ライフサイクルのどの部分を誰が所有するかです。
この連載における最後の区別は、プロセスと品質の間のものです。品質とは、バックプレッシャーの概念です。文字通りの意味です。私たちはエージェントに、可能な限りの自律性を与えたいわけではありません。 エージェントを停止し、規制し、作業をチェックし、人間性を確保するのに十分なバックプレッシャーが得られる程度の自律性を与えたいのです。
通常のエンジニアリングは、行われている作業が正しいことを示す多くのシグナルを提供します。型チェック、テスト、フック、サンドボックス制限、監査ログ、モニターなどです。私たちのエンジニアリングシステムは、このようなシグナルで満ちており、システムの誠実さを保つための十分なバックプレッシャーを提供するように設計されています。
したがって、私たちのエージェントがこれらの同じシグナルを発している限り、通常のエンジニアリングが適切なバックプレッシャーを提供してくれると信頼できます。
システムを信頼するということは、人間がループ内にいる必要がないという意味ではありません。 それは単に、人間が内部ループにいる必要がないということです。人間には、制約ループ（どのような入力、アーキテクチャ、指示、不変条件を設定すべきか？）、サンプリングループ（どの程度の出力をサンプリングしレビューすべきか？）、監査ループ（どのようなエビデンスを保持すべきか、監査ログを効果的にするにはどうすればよいか？）、そして所有ループ（本番環境の境界のどの部分を所有すべきか）に存在してほしいのです。
しかし、人間が内部ループにいる必要はありません。
エージェントは、あなたがレビューできる量よりも多くを出荷できます。
そして、希少なリソースは、ログやテストなどの品質シグナルによって情報を得た、あなた自身の中核となる人間の判断力です。
AI 2026 年 6 月のレポートは、実験的な環境では、時間単位のタイムホライズンにわたるエージェント委任が基本的に実現していることを示しています。今年の OpenAI によるエージェントと仕事の未来に関する研究 は、これらのアイデアの優れた情報源でした。そのため、システムが私たちのレビュー能力を超えて出荷し始める中で、この所有権の境界をどのように確立するかを考え始める必要があります。
そして、ここで応答可能性が重要になります。
なぜなら、長時間稼働するエージェントの場合、時間単位のタイムホライズンにわたって下される決定は、まさに決定だからです。そして、すべての決定が記録されるわけではありません。それらすべてを入力トークンまで追跡することはできません。あなたがしていることが、目前の問題に対して得られた出力が正しい選択であると信頼することだけなら、それに至るまでの一連の決定を再構築するために必要な、数百、あるいは数千もの人間時間の作業は不可能になります。したがって、繰り返しになりますが、応答可能性は、システム設計の中核に据えなければならないものになります。
3 つの隠れたコスト
そして、3 つの隠れたコストがあります。
認知的降伏 ~ AI が与えるものを盲目的に受け入れること。 エージェントに作業を委任するとき、その作業自体はエージェントの作業のように見えるかもしれません。しかし、それは実際にはあなたの作業です。それはあなたの評判です。それはあなたの責任です。そして、出力の欠陥に悩まされるのはあなたのソフトウェアです。そして、その出力を反映させるために変更が必要なのはあなたのソフトウェアです。つまり、エージェントの出力があなたの回答となるのです。そして、それに伴ってすべての説明責任が生じます。これをまとめたウォートン校の研究は、AI が正しい場合には心強いものです。しかし、AI が間違っている場合、状況は良くありません。AI が間違っていた場合でも、約 4 分の 3 の人がそれを受け入れ、AI がいなかった場合よりも自信を持っていると感じていました。
認知的負債 ~ 問題解決方法に関するあなたの理解と記憶の侵食。 エージェントに作業を委任するとき、あなたはすべての思考作業をエージェントにオフロードしています。自分ですべてを考え抜くには時間とエネルギーが必要ですが、大規模なコードベースで考え抜くには、学習曲線を駆け上がろうとしているときには利用できないリソースが必要です。そのため、得られる出力は、自分では達成できないものであることがよくあります。そして、エージェントの計画のタイムホライゾンが長ければ長いほど、エージェントが生成するコードとあなたの理解との間のギャップは大きくなります。そのギャップは複合的に拡大します。負債は蓄積されます。そして、学習曲線を克服するためのコストはほぼ指数関数的に増加します。Anthropic のランダム化比較試験では、AI に頼ってコードを書くエンジニアは、自分でコードを書くエンジニアと同様にコードを理解しているかどうかが調査されました。結論は暗澹たるものでした。理解度クイズでは、AI を介して作業したエンジニアは、そうでないエンジニアよりも 17 パーセントポイント低いスコア（50% 対 67%）でした。
そして、オーケストレーション税があります。今では多くのエージェントを立ち上げるのは簡単ですが、あなたの認知帯域幅は同じようには並列化しません。エージェントを最悪の行動から遠ざけ、エージェントが生成した作業を選別して注意を払うべきものを見極め、まずあなたが気にかける作業に集中するよう指示し、最も重要な制約と最も危険な前提を実行前に検証する...
これらすべてには作業が必要であり、自動化することはできません。
人間の判断に代わるものはありません。
ブラウンフィールドシステムはここで特に危険です。なぜなら、監査しなければならないシステムの振る舞いはコード内に存在しないからです。それは「傷跡」の中に存在します。
解決策は？ アーキテクチャ上の決定において、注意を最優先事項にすることです。ワークツリー、スコープ、エビデンスを使用して、初期計画とそこから生まれる作業との間の結合を減らします。アクション不能なステップを解決するための努力には時間制限を設けます。そして、ソフトウェアへの変更を厳密にオプトインの許可制にします。
アルファ、ディケイ、テイスト：これらは、分野を問わずキャリアとパフォーマンスを形成する 3 つの中核的なパターンです。
アルファとは、競争において最も高い成果を上げる者が担う主導的な役割であり、あなたが最も価値の高いゲームの手を打っている状態です。ディケイとは、繰り返しと他者の観察を通じて誰もが学ぶ確立されたパターン（プラトー、と言ってもいいでしょう）です。テイストとは、アルファの兆候やディケイの変化を最も早く感知できる能力です。何かが起こっているというエビデンスを得る前に、何が起こるかを判断する力です。ポール・グレアムの指摘は、誰もが何でも作れる時代には、何を作るかの選択がより重要になるというものであり、ミッチェル・ハシモトの定義は運用面でのものです。すなわち、客観的な指標がまだ存在しない状況で、質の高い定性的判断を下すことです。今後は、テイストがすべてを動かします。アルファのシフトはテイストの変化です。そして、ディケイは、私たちが何か別のものを味わい始めるために消えていきます。
次のステップは？ あなたのテイストを運用可能にすることです。どうやって？ 大脳辺縁系から意識へと移行させようとしているものを反映した名前を付けます。批評や事例を通じてそれを練習します。その根拠を明確にします。
そして、あなたの業界で最も持続可能な競争優位性をもたらす手を打ち続けてください。それは何か？ タスクを単に実行することから、それを教え、体系化し、いつ実行すべきかを判断し、結果を所有することへと、常に限界を押し上げていくことです。
誰もがデベロッパーですが、誰もがエンジニアであるわけではありません。エンジニアリングとは、デベロッパーがより厳格な作業規律（徹底的で論理的に健全な推論、制約とトレードオフの考慮、リスクとエクスポージャーの認識、実践的な説明責任）を受け入れたときに変貌するものです。
将来、人々はエンジニアリングの管理業務から離れ、エンジニアリングがより要求の厳しいものになるにつれて出現する新しい役割を受け入れるでしょう。それは、クラフトの精神からは切り離されているものの、各個人が何を行うかを明確にする役割です。プロトタイプを作成する人、構築する人、掃除する人、成長させる人、維持する人々がいるでしょう。
人間は、別の方向でもシステムの限界を担います。別の方向でアルファを高めます。すなわち、何をする価値があるかを選択し、それを実行すべき制約を定義し、エビデンスが十分かどうかを判断し、結果を気にかけることです。それが単一のチームであろうと 100 のチームであろうと、これは人間だけが担える限界です。
説明責任がファクトリーをスケールさせます。 注意力やテイストと同様に、説明責任もまた、すべてを機能させる 3 つの二重性の 1 つです。説明責任がなければ、ルールはありません。 質問者とのやり取りも、トレードオフも、リスクも、セーフティネットもありません。もし誰も決定の結果を所有しなければ、高い主体性は混乱をもたらすだけです。
限界の半減期は 1 リリースですが、署名の半減期はキャリアです。署名とは、あなたが自分の仕事に名前を記すことであり、出荷されたものに対して責任を持てると感じられることです。スキルはレバレッジをもたらします。説明責任はレバレッジを信頼に変えます。
選択できるのは人間だけです。結果を受け継ぐのは人間だけです。エージェントは、ポリシーの範囲内で安全に選択、ルーティング、マージ、エスカレーションを依頼されることはあっても、結果を受け継ぐことはできません。
すべてのコードベースには、おそらく何らかの説明責任契約が付属するべきです。その契約には、変更が受け入れられた際に理解されていたチェックリスト、判断の根拠となったエビデンス、変更に対して責任を負う人物、そして変更がブロックされた後のシステムステータスが明示的に記載されているべきです。例えば、以下のように：
- あなたの注意力とテイスト
- あなたのエビデンス、判定、所有権
- あなたのアルファ、ディケイ、テイスト
高い主体性
典型的なエージェンティックワークフローにおいて、高い主体性とは、いつ委任し、いつ検査し、いつ停止し、いつプロセスの結果を所有するかを知る技術です。主体性のラダーは、低い方から高い方へと続きます：潜在的な問題をフラグする、調査する、実行する、診断する、解決策を提案する、修正を推奨する、問題を解決する。主体性のラダーにおける高い段は、識別力です：問題を見つけたが、修正する価値はないので、次に進む。
ソフトウェアファクトリーを支える 12 の柱
ブラウンフィールドは、スケールを目指すファクトリーにとってのフロンティアです。これらすべての巧妙な小さな革新は、まだ大したものに感じられないかもしれませんが、本番環境は大きなものです。まったく新しいシステムを構築する場合、十分なバックプレッシャー機構を計画し実装するのははるかに簡単です。なぜなら、完全な制御が可能だからです。しかし、レガシーシステムにインテリジェントエージェントを追加するとなると、それはまったく別の問題です。
レガシーシステムには、本番環境の振る舞い全体、顧客からの将来の期待、移行履歴、リリースサイクルと予算サイクルの期間、暗黙の前提、エッジケース、データの異常、ランブック手順、そしてシステムを気にかけようという意志なしに蓄積されたすべての「傷跡」が含まれます。
ブラウンフィールドの管理者になるには、永続的なエンジニアリングの形態が必要です。暗黙の知識を明示的な制約に変換し、チーム間や世代を超えて一貫性を保ち、その知識をテスト手順や機能仕様に形式化し、その知識を客観的なエビデンスに結びつける作業を行わなければなりません。その間ずっと、失敗をより多くの学習へと活用していきます。なぜなら、システムがこれまで受けてきたケアを受けられなければ、すべてが崩壊してしまうからです。
新しい仕事は本物の仕事である
スケールするにつれて、仕事はより面白くなります。なぜなら、他のすべてが構築されたとき、人々は新しいものを構築したいと望むからです。 彼らは、自分のクラフトを通じて培ってきたアルファとテイストを駆使して、ソフトウェアファクトリーに接ぎ木できる新しいループを設計したいと望むでしょう。あるいは、ソフトウェアファクトリーの知識をすべて、1 つのエレガントで意図に満ちた原則的な取り組みに活用するグリーンフィールドシステムを構築したいと望むでしょう。彼らは、新しいシステムの検証レベルに達する新しい形式のエビデンスを設計し実装したいと望むでしょう。彼らは、非常に複雑になったため専用の注意を必要とするブラウンフィールドシステムを管理したいと望むでしょう。彼らは、新しいバックプレッシャー機構を設計し管理したいと望むでしょう。彼らは、新しいエージェントを設計したいと望むでしょう。そして、彼らは主体性を構築したいと望むでしょう。
そして、そうするにつれて、これらすべてが本物の仕事であることに気づくでしょう。それは良いことです。
自動化はボトルネックを生み出します。それは、所有する価値のある生産上のボトルネックです。なぜなら、自動化は産業規模の制御を私たちに与えるからです。しかし、産業規模から生じる新しいボトルネックもあります。ボトルネックは「これを構築できるか？」から「これは存在すべきか、それに対して説明できるか？」へと移ります。
私が提案しているのは、エージェンティックエンジニアリングをスケールさせるための実用的な運用モデルです。内部ループと外部ループがあります。内部ループは作業が行われる場所です。ループは可能な限り独立するように設計されています。すべての品質保証と検証をループ内に配置します。ループ自体を設計し検証したら、あとは、ループが実行される速度とその動作範囲を制御するバックプレッシャー機構を設置することで自律性を付与するだけです。そして、人間を本来の場所、つまり適切な決定に配置します。 理解を引き継ぎやリリースゲートとして扱うのではなく、人間が洞察を提供するために最適化された決定のポイントとして扱います。そして、存在するすべてのアーティファクトが本番環境や新しいチームやエンジニアにフィードバックされるたびに、より良いアーティファクトを残します。
ファクトリーを構築し、灯りを絶やさず、作業を判読可能で、検証可能で、所有されたものにします。
エージェントはそれを書くことができます。しかし、それがユーザーに届く前に、誰かが、なぜそれが存在すべきなのか、なぜ本番環境の一部として十分に安全なのか、そしてそれが間違っていた場合に何をするのかを説明できなければなりません。
それがアウターループにおけるエージェンティックエンジニアリングです。それが今の仕事です。
Pangram はこの記事を 100% 人間が書いたものと評価しました： https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
