外部ループを所有せよ
(substack.com/addyo)- エージェントが調査・実装・検証を反復する内部実行ループを担うとしても、エンジニアはデプロイ可否を決め、結果に責任を持つ外部ループを所有すべき
- エージェントシステムは、事前チェックを意味する品質（Quality）、本番投入可否を決める判定（Verdict）、判断理由を説明できるようにする**説明責任（Answerability）**を基盤に運用される
- Sonarの2026年調査では、コミットされたコードの42%がAI生成または大幅なAI支援を受けていたことが示され、生成速度が統制速度を上回るにつれて、レビュー・検証・理解・保守が希少な資源になった
- AI活用には、誤った答えをそのまま受け入れる認知的降伏、コード理解を弱める認知負債、複数のエージェントを限られた人間の注意力で管理しなければならないオーケストレーションコストが伴う
- スケーラブルなソフトウェアファクトリーは、エージェントに最大限の自律性ではなく、停止・調整・検証可能な自律性を与え、人間が制約・サンプルレビュー・監査・所有権と最終結果に責任を持つときに可能になる
エージェント型エンジニアリングの外部ループ
- エージェント型エンジニアリングの議論は、エージェントのハーネスとループ、フリート、ソフトウェアファクトリーへと移っている
- FableやGPT-5.6のような強力なモデルが登場するほど、エンジニアはシステムに対する責任を意味する外部ループを自ら所有しなければならない
- エージェントの高いレバレッジは、それに見合う義務を生む
- 何が変わったのかを正確に説明できなければならない
- その変更がなぜ安全だったのかを説明しなければならない
- 判断が誤っていた場合に何が起きるかを知っていなければならない
- この条件を満たせなければ、エージェントの行動を正当化できず、組織もそのようなシステムを使いにくい
品質・判定・説明責任
- **品質（Quality）**とは、システムを解き放つ前に設置するすべてのチェックを指し、そこで得られた証拠が判定の基盤になる
- **判定（Verdict）**とは、作業が依存システムに入る前に人間が下す最終的な本番判断である
- モデルがコードを書いても、自分の名前で作業をデプロイする人が判定責任を負う
- デプロイ、ブロック、経路変更、応答範囲の縮小、ガードレール追加、全面拒否のいずれかを決める
- **説明責任（Answerability）**とは、誰かに理由を問われたときに、その判断を説明できるという保証である
- モデルはコードを1行書けるかもしれないが、依存システムへ渡すかどうかを決める責任まで代行するわけではない
モデル・ハーネス・ループ・ファクトリー
- エージェントは単一のモデルではなく、ファイル・ツール・メモリ・技術・サンドボックス・権限・可観測性・復旧機能を組み合わせたハーネスまで含む
- モデルがエンジンなら、ハーネスは実作業を安全に行えるようエンジンの周囲に作られた自動車に相当する
- ツールとメモリは作業能力を提供する
- 権限とサンドボックスは実行範囲を制限する
- テストと可観測性は作業結果を確認できるようにする
- エージェントの実行ループは、調査 → 実装 → 検証 → 反復で構成される
- 反復可能な周期が、1回限りの成功を再び信頼できるプロセスへ変える
- 作業完了の有無は、モデル自身の判断ではなく独立したチェックで決めるべきである
- 複数のループを同時に運用すると、ソフトウェアファクトリーになる
- 内部ではエージェントが作業を産出する
- 境界では人間が本番判断を所有する
システムの内側と外側を分ける境界
- ソフトウェアファクトリーの中心には、システムの内側と外側を分ける境界がある
- 内部システムは、プロダクトチームの意図、過去のデプロイ作業に関する知識、最近の障害、具体的なユーザーフィードバックを入力として収集する
- エージェントループは作業を調査し、計画を実装したうえで結果を検証する
- 検証で生成された証拠がシステム境界を越えてくると、依存システムを所有する人間が進行可否を決める
- 以前はエージェントが実行過程の一部だけを担っていたが、今では内部実行ループ全体を担い、エンジニアが外部ループを担当する
- 境界内のエージェントが提供するものは**能力（capability）**である
- 作業の調査
- 計画の実装
- 結果のテスト
- 結果の報告
- 境界外の人間が行使するものは**行為主体性（agency）**である
- 決定
- 検証
- 承認
- 所有
AIコードが生んだ信頼・検証ギャップ
- AIコードの割合は、もはや周辺的な水準にとどまっていない
- Sonarの2026 State of Codeレポートによると、コミットされたコードの42%がAI生成または大幅なAI支援を受けており、回答者はその割合が横ばいではなく今後も増え続けると予想している
- コード生成コストが下がるにつれて、レビュー・検証・理解・保守がより希少な資源になった
- 生成速度が統制速度より速く伸びることで、信頼・検証ギャップが生じる
- 多くの人がAIコードに不信感を示している
- その不信感を一貫した検証手順として実装している例はさらに少ない
- AIコードの信頼性を、より安価かつ明確に確認する方法が必要である
事後ガバナンスの限界
- GitLabの2026年6月AI責任研究によると、AI活用における現在のボトルネックはレビューと検証である
- ガバナンスは主に、コードが作られた後に適用される
- この時点では、組織はすでにリスクを受け入れた状態にある
- 作業所有権に対する統制も弱まった後である
- AIガバナンスは単なるシステム統制を超えて、次の事項を定めなければならない
- システムにどのような制約を置くか
- どの証拠で作業を検査するか
- チームにどのように責任を問うか
- AIライフサイクルの各部分を誰が所有するか
品質を生む逆圧
- 品質は、システムに作用する**逆圧（back pressure）**として理解できる
- 目標は、エージェントが行使できる最大限の自律性を与えることではない
- エージェントを停止し、調整し、作業を検査し、人間の役割を保持できる程度にだけ自律性を与えるべきである
- 既存のエンジニアリングには、作業が正しい方向へ進んでいるかを示すシグナルがすでに存在する
- 型チェック
- テスト
- フック
- サンドボックス上限
- 監査ログ
- モニター
- エージェントも同じシグナルを発するなら、既存のエンジニアリング体系で適切な逆圧を提供できる
人間が入るべき4つのループ
- システムを信頼するということは、人間をループから外すという意味ではない
- 人間は内部実行ループではなく、次の4つの外部統制ループにいるべきである
- 制約ループ: どの入力、アーキテクチャ、指針、不変条件を設定するかを決める
- サンプルレビューループ: 出力のうちどの程度を抽出してレビューするかを定める
- 監査ループ: どの証拠を保存し、監査ログの有効性をどう保証するかを決める
- 所有権ループ: 本番境界のどの部分を誰が所有するかを明確にする
- エージェントは、人間がレビューできる量を超える作業を産出できる
- したがって希少資源は、ログやテストのような品質シグナルに基づいて行使される人間の中核的判断力である
- OpenAIのエージェントと仕事の未来に関する研究が扱った実験環境では、時間単位の範囲でのエージェント型委任がすでに可能な段階に達している
- システムがレビュー可能量を超える作業を出す前に、所有権境界を確立しなければならない
長時間実行エージェントと説明責任
- 時間単位で実行される長時間エージェントが下す選択は、すべて決定に該当する
- すべての決定が記録されるわけではなく、それぞれを入力トークンまで遡跡できるわけでもない
- 結果が問題に対する正しい選択だと信じるだけなら、その結果に至った決定の連鎖を再構成するのに、数百または数千時間の人間の労働が必要になる可能性がある
- このような決定の連鎖は事実上再構成が難しいため、説明責任をシステム設計の中心に置かなければならない
AI委任の3つの隠れたコスト
-
認知的降伏
- **認知的降伏（cognitive surrender）**とは、AIが出した結果を盲目的に受け入れる現象である
- 作業をエージェントに任せても、成果物はユーザーの作業、評判、責任につながる
- 欠陥はユーザーのソフトウェアに残る
- 出力に合わせて変更しなければならない対象もユーザーのソフトウェアである
- エージェントの答えは最終的にユーザーの答えとなり、責任も伴う
- Whartonの研究では、AIが誤っていた場合でも参加者のほぼ4分の3がその答えを受け入れ、AIなしで判断した場合よりも高い自信を示した
-
認知負債
- **認知負債（cognitive debt）**とは、問題解決法に対する理解と記憶が弱まる現象である
- エージェントに作業を委任すると、思考過程も同時に外部化される
- 大規模コードベースを自力で理解するために必要な時間とエネルギーは、学習過程で確保しにくい場合がある
- その結果、エージェントが作った成果物が、ユーザーの現在の能力では到達しにくい水準になることもある
- エージェントの計画時間が長くなるほど、生成されたコードと人間の理解の間のギャップは広がる
- このギャップは累積し、学習曲線を再び登るコストもほぼ幾何級数的に増加する
- Anthropicのランダム化比較試験では、AIでコードを書いたエンジニアの理解度クイズのスコアは**50%で、自分で書いた集団の67%**より17ポイント低かった
-
オーケストレーションコスト
- **オーケストレーションコスト（orchestration tax）**は、多数のエージェントを同時に実行できても、人間の認知帯域幅は同じようには並列化されないことから生じる
- 人間は次の作業を自ら行わなければならない
- エージェントが最悪の行動を避けるよう調整する
- 成果物の中から注意が必要な作業を選び出す
- 重要な作業を先に処理するよう指示する
- 実行前に主要な制約と危険な仮定を検証する
- この作業は自動化できず、人間の判断を代替することはできない
ブラウンフィールドで注意力を守る方法
- ブラウンフィールドシステムは、監査すべき挙動がコードだけでなく、積み重なった傷跡と歴史にも残っているため、とりわけ危険である
- アーキテクチャ上の決定では、人間の注意力を優先すべきである
- worktree・範囲・証拠を使えば、初期計画と実行中に新たに明らかになった作業との結合度を下げられる
- 実行できない段階の解決試行には時間制限を設けるべきである
- ソフトウェア変更権限は、厳格なオプトイン方式で付与すべきである
Alpha・decay・taste
- キャリアと複数分野での成果を形作る3つの中核パターンは、alpha・decay・tasteである
- Alphaは、競争で最も高い成果を出す人が占める先導領域であり、最も価値の高い手を打っている状態である
- Decayは、反復と観察を通じて誰もが学んだ定着済みのパターンであり、一種の停滞区間と見なせる
- Tasteは、alphaの先導やdecayの変化を、証拠が現れる前に感知する判断力である
- Paul Grahamの議論は、誰もが何でも作れるようになると、何を作るかを選ぶことがより重要になるというものだ
- Mitchell Hashimotoの定義では、tasteはまだ客観的な測定基準がないときに下す高品質な定性的判断である
- alphaの移動はtasteの変化によって起こり、decayは人々が別のものを好み始めたときに消える
Tasteを運用可能な能力にする
- 直感にとどまっていたtasteを意識的な能力へ移すには、まず名前を付ける必要がある
- 批評と具体的な事例を通じて、その判断を練習しなければならない
- 判断の根拠も明示的に表現しなければならない
- 持続可能な競争優位を高めるには、役割の境界を継続的に上へ移動させなければならない
- 作業を自ら実行する
- 他者やシステムに作業を教える
- 作業を体系化する
- いつ実行すべきかを決める
- 結果を所有する
開発者とエンジニアの違い
- 誰もが開発者になれるが、全員がエンジニアであるわけではない
- 開発者は、より厳格な作業規律を受け入れたときにエンジニアになる
- 徹底的で論理的に妥当な推論
- 制約とトレードオフへの配慮
- リスクと露出範囲の認識
- 実質的な責任
- エンジニアリングがより難しくなると、人々は管理的な作業から離れ、職人技に結び付いていた役割を分離して、それぞれの機能を明確にするようになる
- プロトタイプを作る人
- 構築する人
- 整理する人
- 成長させる人
- 保守する人
人間だけが守れるシステム境界
- 人間は、システムの反対側の境界でもalphaを高める役割を担う
- 何が行う価値があるかを選ぶ
- どの制約の中で実行するかを定める
- 進めるのに証拠が十分かを判断する
- 結果を面倒見る
- 1チームであれ100チームであれ、この境界は人間だけが所有できる
- 注意力・taste・責任は、ソフトウェアファクトリーを機能させる中核要素である
- 責任がなければ、ルール、質問への対応、トレードオフ、リスク、セーフティネットも成り立たない
- 決定の結果を所有する人がいなければ、高い行為主体性は混乱につながる
技術より長く残る署名
- 技術的優位の半減期は1つのリリースかもしれないが、作業に残した**署名（signature）**の半減期はキャリア全体に及ぶ
- 署名とは、デプロイした結果に自分の名前をかけて支持できるという意味である
- 技術はレバレッジを生み、責任はそのレバレッジを信頼へ変える
- 選び、結果を引き受ける主体は人間だけである
- エージェントはポリシーの中で選択、経路指定、マージ、エスカレーションを実行できるが、その結果を引き受けることはできない
コードベースの責任契約
- 各コードベースには、変更を受け入れる際の条件を明示する責任契約が必要になる可能性がある
- 承認時に理解した内容を確認するチェックリスト
- 判断に使用した証拠
- 変更に責任を持つ人
- 変更をブロックした後のシステム状態
- 契約は、注意力とtaste、証拠・判定・所有権、alpha・decay・tasteのような結び付き関係を明示的に扱うべきである
高い行為主体性のはしご
- エージェント型ワークフローにおける高い行為主体性とは、いつ委任し、検査し、停止し、結果を所有するかを知る能力である
- 行為主体性のはしごは、低い段階から高い段階へと続く
- 潜在的な問題を示す
- 問題を調査する
- 対応作業を実行する
- 原因を診断する
- 解決策を提案する
- 修正案を推奨する
- 問題を解決する
- より高い段階には、問題を発見したが直す価値はないと判断して先へ進む分別も含まれる
ブラウンフィールドがソフトウェアファクトリーの最前線である理由
- ブラウンフィールドは、拡張を望むソフトウェアファクトリーが直面する最前線である
- グリーンフィールドシステムは全体を統制できるため、十分な逆圧装置を計画し実装することが比較的容易である
- レガシーシステムに知的エージェントを追加するときは、コードの外にある複雑性まで扱わなければならない
- 本番環境全体の挙動
- 顧客の将来の期待
- マイグレーション履歴
- リリースおよび予算サイクル
- 暗黙の仮定
- 例外状況
- データの特異性
- ランブック手順
- 管理されないまま蓄積した傷跡
- ブラウンフィールドをケアするには、持続可能なエンジニアリングが必要である
- 暗黙知を明示的な制約へ変える
- チームや世代を越えて知識を一貫して維持する
- 知識をテスト手順と機能仕様として公式化する
- その知識を客観的な証拠に結び付ける
- 失敗を追加の学習として蓄積する
- 従来受けていた水準の管理が途切れると、システム全体が崩壊する可能性がある
規模が大きくなるほど生まれる新しい作業
- 既存の構成要素が自動化されると、人間は自らの職人的経験から得たalphaとtasteを使って新しい作業を設計するようになる
- ソフトウェアファクトリーに組み込む新しいループを設計する
- ファクトリーで得た知識を活用して、原則に基づくグリーンフィールドシステムを構築する
- 新しいシステムを検証できる新しい証拠形式を作る
- 専任管理が必要なほど複雑になったブラウンフィールドシステムをケアする
- 新しい逆圧装置を設計し管理する
- 新しいエージェントを設計する
- 新しい行為主体性の体系を構築する
- こうした活動もすべて実際のエンジニアリング作業であり、規模が大きくなるほど、より興味深い問題になる
自動化が移動させるボトルネック
- 自動化は産業的規模に対する統制力を与える一方で、新しいボトルネックを生む
- 過去のボトルネックが「これを作れるか？」だったなら、今後は「これは存在すべきか、その結果を説明し責任を負えるか？」へ移る
- 本番環境で新たに生じるボトルネックは、人間が自ら所有する価値がある
エージェント型エンジニアリングの運用モデル
- 内部ループは実際の作業が行われる場所であり、各ループは可能な限り独立して設計すべきである
- すべての品質保証と検証を内部ループに入れなければならない
- ループ自体を設計し検証した後は、実行速度と作業範囲を統制する逆圧装置を設置して自律性を与える
- 人間はすべての内部段階に介入するのではなく、適切な決定地点に配置すべきである
- 理解を単なる引き継ぎやリリースゲートとして扱わず、人間が洞察を提供する準備ができた意思決定地点として扱うべきである
- 成果物が本番環境や新しいチーム・エンジニアへ再び供給されるたびに、以前より良い成果物と証拠を残さなければならない
- ソフトウェアファクトリーを構築し、運用し続ける一方で、作業を読めて、検証でき、所有者がいる状態に保たなければならない
- エージェントがコードを書いたとしても、ユーザーに届く前に人間は次の問いに答えなければならない
- なぜこのコードは存在すべきなのか
- なぜ本番環境に含めても十分に安全なのか
- 誤っていたときに何をするのか
- この判断と責任を果たすことが、エージェント型エンジニアリングの外部ループである
まだコメントはありません。