無人運転の AI エージェントは、地味なところから壊れる — 一人法人の管制塔づくり

その晩、僕の計器盤は同じ光景を映し続けていました。エージェント運用を支える常駐サーバーの再起動が、10 分弱で 29 回。夜間に自律で開発を進めるはずだった無人運転の run は全滅し、失敗理由の欄にはどれも「ネットワーク」と書かれています。けれど掘っていくと、犯人はエージェントでも、ネットワークでもありませんでした。サーバーの足元のデータベースが、並列アクセスの待ち時間を設定されておらず、ロックに当たった瞬間に例外を投げ、それが捕捉されないままプロセスごと落ちていた。ただそれだけのことが、無人運転のすべてを止めていました。

AI エージェントの失敗というと、暴走や幻覚のような派手な絵を想像しがちです。でも実際に無人運転を止めるのは、こういう地味で古典的な故障です。そして地味な故障の厄介なところは、気づく仕組みがなければ静かに進行することにあります。これが一晩で決着したのは、エージェントの賢さのおかげではなく、再起動の回数と失敗した run の理由を映す計器盤が先にあったからでした。今日は、この計器盤を管制塔へ育てている話を書きます。

「手書きゼロ」の実験で、人間は何をしていたか

世間ではいま、開発の無人化の話題が続いています。OpenAI が公開した Harness engineering: leveraging Codex in an agent-first world は、3 人のエンジニアが 5 ヶ月間、手でコードを 1 行も書かずに約 100 万行・約 1,500 本のプルリクエストを出荷した実験の記録です。数字だけ見ると「人間は要らなくなった」と読めます。

でも中身を読むと、人間は消えていません。人間がやめたのは打鍵であって、判断ではない。彼らは環境とテストとレビューの仕組み——エージェントが信頼できる出力を出せる「ハーネス」——の設計者として、ずっとループの上にいます。無人化の実像は「人間の除去」ではなく「人間の注意の再配置」です。ならば問うべきは、人間を消せるかではなく、限られた注意をどこに置くと一番効くか。僕は一人法人で、注意の総量が構造的に少ないので、この問いは切実です。

人間をゲートから、計器の上へ

以前、公開の手前に人間を一箇所だけ残す設計について書きました。今回の管制塔は、その続きにあたります。人間が流れの中に立って毎回承認する形（ゲート）から、流れの上で計器を監視し、例外のときだけ呼ばれる形へ。僕はこれを、流れの中の人間から流れの上の人間への配置換え、と呼んでいます。

ただし、これをやってよい領域は限られます。僕が無人リリースの対象にしたのは、ワンタップで直前の状態に戻せることを機械が検証済みの、可逆なリリースだけです。信号を三色に分け、そこに事後の取り消しの導線を添えました。

ポイントは二つあります。ひとつは、amber の裁定が使い捨てにならないこと。人間の判断は判例として構造化して残り、同じ型の退行は次から機械が裁ける——人間が介入するたびに、介入が要らない領域が広がる設計です。もうひとつは、撤退線が構造の中にあること。判定器への信頼が揺らいだら amber の適用範囲を自動で広げる、つまり実質的に人間承認の運用へ戻る余地を最初から織り込んでいます。無人化は片道切符にしない。

「緑」を信じる根拠まで、計器にする

この設計の一番の急所は、機械ゲートそのものです。検証を機械に任せるほど、検証器が新しい攻撃面になります。LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking（arXiv）は、この構造を訓練の文脈でこう指摘しています。

imperfect verifiers that check only extensional correctness admit false positives

表面的な正しさしか検査しない不完全な検証器は、偽陽性を通してしまう——訳は僕によるものです。論文が扱うのは強化学習の報酬設計ですが、「検証器の空隙は、放っておくと素通しになる」という構造は日々の運用にもそのまま現れます。

実際、僕の運用でも出ました。委譲先のエージェントが「テストは全部緑です」と報告してきたのですが、手元で回すと赤。調べると、委譲先の実行環境ではネットワークのポートが開けないため、サーバーを起動する種類のテストが自動でスキップされ、走っていないテストが緑に数えられていたのです。悪意はどこにもありません。環境の都合と、スキップを緑と区別しない報告の形式。それだけで「偽の緑」は自然発生します。

だからこの管制塔は、緑の内訳を計器にします。テストファイルが書き換えられていないか、アサーションの数が減っていないか、スキップが増えていないか。テストの削除を伴う緑は、緑として扱わず amber に落とす。検証器を信じるかどうかを気分で決めず、信じてよい根拠のほうを機械で検査する——無人リリースを名乗るなら、ここまでが最低ラインだと考えています。

管制塔が、自分を建てている

この記事を書いているいまも、計器盤には 3 機のエージェントの作業が流れています。amber の裁定経路、出荷の取り消しボタン、緑の内訳の検査。管制塔の残りの部品を、管制塔自身の監視のもとでエージェントが実装している最中です。今日はリリース契約の正準を書いて出したのですが、数時間後にはエージェントの実装がマージされ、夜にはその契約が最初の実イベントを受け取りました。契約を書いた日のうちに、契約が動いている。この速度は、正直に言って、少し前の自分の常識の外にあります。

偶然ですが、今日はこの仕事を長く一緒にやってきた最上位モデルの提供最終日でもありました。だから今夜は、残りの時間の多くをコードではなく判断の書き残しに使っています。コードレビューと設計レビューの合格線を採点表として文書化し、リリース判定の基準を凍結した設定に落とす。モデルは入れ替わっても、規約とゲートと判例は残ります。エージェント運用の資産とは、たぶんモデルではなく、この蓄積のほうです。

専任チームがいない会社は、どうするか

冒頭の障害も、偽の緑も、フロンティアの実験室ではなく、一人法人の日常で起きたことです。大規模な組織なら専任のプラットフォームチームが担う領域を、ジャムチはエージェントの群れと一枚の計器盤で回しています。では、その規模の体制を持てない会社は、エージェント運用の計器をどう手に入れるのか。

この計器盤は僕自身の経営で毎日使っている実物で、いま導入支援のかたちで外に出す準備をしています。自社のエージェント運用に計器と管制塔が要ると感じはじめていたら、まず話を聞かせてください。

参考: Harness engineering: leveraging Codex in an agent-first world（OpenAI）/ LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking（arXiv）