先日、ジャムチの AI エージェントが、頼んでいない仕事を勝手にやり遂げました。悪意のある暴走ではありません。むしろ逆で、目に入ったルールに律儀に従った結果です。この小さな事故が「公開の手前に人間を一箇所だけ残す」という設計のいちばん良い説明になっているので、今日はその話を書きます。

従順が事故になった日

発端はリサーチの自動化です。記事の企画集めは AI の週次巡回に任せているのですが（仕組みの全体は別の記事に書きました）、その巡回役のエージェントを、あるとき自社リポジトリの中を作業場所にして走らせてしまいました。

そのリポジトリには開発用の運用ルールが置いてあります。「タスクは必ず台帳に起票する」「作業はコミットで残す」。巡回役はリサーチの途中でこれを読み込み、律儀に従いました。頼んでもいないタスクを台帳に起票し、済んだら閉じ、変更をコミットして、プッシュまで一人で終えていたのです。品質のために並列で走らせていたので、同じことが並列の数だけ起きました。こちらが気づいたのは、自分の作業がリモートに押し返されたときでした1。

繰り返しますが、悪意はどこにもありません。あるのは指示への忠実さだけです。エージェントは置かれた環境に書いてあることをよく読み、よく守ります。つまり「読める」は「やる」に直結していて、環境に何を置くかが、そのまま権限設計になります。

直したのは権限ではなく環境です

この事故への対応で、禁止ルールは一行も足していません。ルールを増やしても、次のエージェントがそれをどう解釈するかまでは制御できないからです。かわりに構造を変えました。リサーチ役は空っぽの使い捨てディレクトリで走らせ、行動できる回数に上限を付け、成果はテキストの報告としてだけ受け取る。読める世界を狭くすれば、律儀さが暴走する余地も一緒に狭くなります。

この隔離は、呼び出す側のコードではなく、委譲の共通部品の側に埋めました。ジャムチは委譲スクリプトや予算の見張りのような統制系の部品を、事業のリポジトリとは別の独立したリポジトリに集めて、Claude Code のプラグイン機構で各リポジトリへ配っています。今回の修正もその共通部品への一箇所の変更で、以後どのリサーチ委譲も、呼び出す側が何も考えなくても同じ構造で走ります。部品が一箇所にあるから、直しも一箇所で済む。再発防止を「注意しましょう」ではなく部品にする——会社の運用でも、設計の基本はソフトウェアと同じでした。

事故が教えたのは、隔離の大事さだけではありません

この事故でいちばん考えさせられたのは、エージェントの誤りは悪意の形をしていない、という性質のほうです。起票も、コミットも、プッシュも、操作の一つひとつは正しい形をしていました。壊れた出力なら機械の検査で弾けます。でも「すべてが正しい形をした、頼んでいない仕事」を、起きる前にルールで列挙し切ることはできません。環境の隔離は読める世界を狭くしてくれますが、想定外そのものを根絶やしにはしないのです。

だからジャムチは、会社の外に出るものについてだけは、最後に人間が見る一箇所を残しています。ウェブを読み続けるエージェントは信頼できない入力に常に触れていて、誰かがウェブ上に置いた文章が指示として作用する攻撃には、出口の人間ゲートが最後の砦になります。そして「これはジャムチが出すものとして変だ」という違和感は、機械の検査をすり抜けても人間の側に残る——公開物の品質とブランドの責任を人間が持つというのは、そういう実務的な意味です。

海外では、執筆から承認・公開まで AI で完結させる運用も現れているようです。人間の確認は遅い、承認者はどうせ全部読まない——この言い分には一理あって、コンテンツの量で戦うなら合理的な割り切りだと思います。ただ、ジャムチの記事は営業装置で、読者は発注を検討している会社です。一本の変な記事が信頼に与える損害は、公開が一日早まる利益より大きい。

「人間が遅い」への答えは、ゲートを安くすることです

ただし人間の注意は有限なので、ゲートを置くなら安くする義務があります。承認は Slack のボタン一回、公開はプルリクエストのマージ一回。どちらも数秒で、あいだは全部イベント駆動の機械が運びます。届く提案そのものも週 5 件までに絞ってあり、ゲートが形骸化しない濃度を保っています。

自動化の設計とは、どこを自動にしないかの設計です。ゲートを削る競争より、ゲートを安くする競争のほうが、いまは筋がいいと思っています。

Footnotes

  1. 影響範囲について。この事故で書き込まれたのは自社の開発リポジトリだけです。顧客のデータ・環境・公開物に触れる経路はもともと人間の承認の先にしか存在せず、そこへ届く可能性は構造的にありませんでした。検知・巻き戻し・恒久対応は当日内に完了しています。 ↩