第一原理からループ工学を構築 — HumanLayer の Kyle Mistele氏

4 万行の PR は作らない：制御理論で構築する「安全な AI エージェント・ループ」の実践法

大規模コードベースや規制の厳しい環境において、AI エージェントを単なるプロンプトとループの組み合わせとして扱うだけでは限界があります。人間がレビュー可能な範囲に抑えながら漸進的に改善を続けるためには、制御理論に基づいた「ループ工学」の導入が不可欠です。

盲信ループの罠：4 万行の PR はレビュー不能である

現在の AI エージェント活用における最大の誤解は、「プロンプトとループをつなげばソフトウェアが自動生成される」という楽観論にあります。多くのチームが検証エージェントを複数導入しても、最終的に出力されるのは「誰も読みたくない 4 万行の Pull Request（PR）」です。

これは Jeff Huntley 氏や Open Claw の事例に見られるような「盲目的なループ」の典型的な失敗例です。特定の課題解決には鋭いツールですが、チーム開発やクリティカルなシステム構築においては、このアプローチは破綻します。

「すべてのコードを読み切れないなら、読むのをやめてもよい」という発想は危険です。これは検証とレビューへの投資を意味しますが、実際に生成されるコード量は膨大で、品質管理が追いつきません。

特に注目すべきは、この「盲信ループ」がもたらすコストの増大です。Matt Pocock 氏が指摘するように、AI エージェント時代において「悪いコード」は過去どの時期よりも高価になります。安定性の問題や修正に数ヶ月を要するケース（例：Open Claw のターミナル flicker 修正）が発生する一方で、人間が書いたコードは数分で解決できることが往々にしてあります。

制御理論によるアプローチ：センサー・コントローラー・アクチュエーター

実世界で機能するループを構築するには、ソフトウェア工学の基本原理である「制御理論」を適用する必要があります。これは単なる自動化ではなく、動的なシステム（コードベース）を所望の状態へ導くためのフィードバック機構です。

制御ループは以下の 3 つの要素で構成されます。

1. センサー（Sensor）：現在の状態を測定する。例えば、未移行関数の検出や ESLint ルールによるエラー計測。
2. コントローラー（Controller）：目標値（セットポイント）と現在の状態の差（誤差）を読み取り、システムに適用すべき増分的な変更信号を生成する。
3. アクチュエーター（Actuator）：コントローラーの指示に基づき、実際にシステムに変更を加える実行部。

この仕組みは、エアコンのサーモスタットや Kubernetes の自動スケーリング、PostgreSQL の autovacuum など、私たちが日常的に利用している技術の根幹です。制御理論の最大の特徴は、「一度にすべてを解決しようとする」のではなく「増分的に変更を加え、その結果を再測定する」点にあります。

制御ループは、システムを暴走させたり過度な操作（オーバーシュート）で不安定化させたりするリスクを最小限に抑えるために存在します。これは、4 万行の PR を一度にリリースしようとする「盲目的なループ」とは対極にある考え方です。

HumanLayer の実践：RPC API 移行における制御ループ設計

HumanLayer では、この制御理論を実践的に適用した事例として、社内コードベースの RPC API から Effect への漸進的移行プロジェクトを推進しています。Effect は副作用管理に優れたライブラリですが、構文が独特で導入ハードルが高いため、全量一括移行は不可能です。

ステップ 1：センサーとしての「as-grep」

まず、未移行の関数を検出するセンサーを構築します。ここではエージェントや ESLint に依存せず、言語に依存しない強力なツールである as-grep を採用しました。

「Claude がインラインコメントで ESLint ルールを無効化してしまう」というリスクを回避するため、設定ファイルとは独立した「アウトオブバンド」の検出手段が必要です。as-grep はこの要件に完璧に合致します。

スキャン結果は膨大（1 回のスキャンで約 50 の違反が検出される）となるため、重要な 4 つのパターンに絞り込み、かつ決定論的にソートしてリスト化します。これにより、システムの「現在状態」を明確なデータとして定義できます。

ステップ 2：フロー制御と「外乱の減衰」

移行ループを開始する前に、新たな違反（未移行関数）が混入しないよう防止策を講じます。これは制御理論における「外乱（Disturbance）」に対する対策です。

メインブランチに対して一度フルスキャンを行い、その結果をバージョン管理下に置きます。そして、新しい PR が作成された際、そのブランチに未移行関数が追加されていないかをチェックします。もし追加されていれば、ループの成果が台無しになるのを防ぎます。

これは「外乱減衰器（Disturbance Dampener）」として機能し、チームメンバーが意図せずとも新しい違反コードを投入するリスクをブロックします。

ステップ 3：コントローラーとアクチュエーターの連携

移行対象の決定には、単純にリストの先頭を選ぶ方法や、as-grep で「最も小さな未移行関数」を選定してリスクを最小化する戦略があります。さらに高度なケースでは、エージェントがどの関数を移行するかを判断し、同時に実行（アクチュエーター）するハイブリッド構成も可能です。

エージェントに決定権を持たせる場合でも、最終的なコード変更は人間がレビュー可能な範囲内に留める設計が必要です。

このアプローチにより、HumanLayer は「Effect への完全移行」という目標に対して、安全かつ計画的に進化を続けるループを実現しています。API の仕様準拠、MCP サーバーのバージョン管理、Python から TypeScript へのミラーリングなど、測定可能で増分的な変更が可能な課題には、この制御理論に基づくアプローチが極めて有効です。

まとめ：人間が介入できるフィードバックループへ

AI エージェントを「実験室レベル」から「エンタープライズ実用レベル」へと引き上げる鍵は、盲信する自動ループではなく、人間が介入しやすく、可読性を保ちながら漸進的に改善を続ける制御ループの構築にあります。センサーで現状を把握し、コントローラーで判断し、アクチュエーターで実行するこのサイクルこそが、大規模コードベースにおける安全な AI 活用の正解です。