なぜ、いきなり止めないのか
理由は2つあります。
誤検知で無人ジョブが止まる
承認ゲートは、判定を誤ると本来は通すべき操作を止めます。対話中なら確認画面が出て、人が押せば済みます。無人ジョブでは押す人がいないので、そのまま止まるか失敗します。
どのジョブがどの操作をどれだけ使っているかを知らないまま止める条件を書くと、誤検知がどこで出るかも分かりません。
止めた件数が多くても、何を止めるべきかは分からない
止めた件数は、ルールの厳しさを表すだけです。重要な操作を止められているか、通すべき操作を巻き込んでいないかは、件数からは読めません。
必要なのは「どの操作が、どの頻度で、誰によって実行されているか」という実測です。そこで先に記録だけを取り、止めるのはその後にしました。
- 台帳を作るエージェントの操作を34個に分け、Level 0〜4を付ける。鍵は参照名だけ書く
- 境界だけ先に止めるエージェントへのルール自体、権限設定、秘密の生値の読み出しを止める
- 残りは記録だけ道具を呼ぶたびに、承認が要るか、本番ならどう判定されたかを追記する
- 実ログで再生・観測過去30日の実ログと観測期間の記録で、頻度と誤検知を数える
- Level 4から止める条件を満たした操作だけ、Levelの高い順に止める。止める操作は人が決める
最初に作るのは、操作の台帳
承認ゲートの前に、エージェントが行う操作を一覧にした台帳を作りました。relmeaの台帳は34操作です。
各操作に、取り消せるか、外の世界に出るか、を基準にしたLevel（0〜4）を付けています。内訳は次のとおりです。
- Level 4：4操作（本番デプロイ、広告の変更、鍵の生値、MCPの設定）
- Level 3：12操作
- Level 2：7操作
- Level 1：6操作
- Level 0：5操作
台帳には、承認が要るかどうかも操作ごとに持たせています。
鍵（認証情報）は、台帳に値を書きません。書くのは参照名だけです。台帳にも、後で触れる記録にも、鍵の値は入りません。
台帳に載っていない操作は「不明」として別に記録します。不明の内訳を見て、台帳に足していきます。
今すぐ止めるものと、記録だけにするものを分ける
導入時に、ゲートを2つに分けました。
- 境界のフック（すでに止める）：対象は、ルールそのもの（エージェントへの指示ファイル）、権限設定、フックや台帳などの制御の仕組み、秘密の生値の読み出しです。無人実行なら拒否、対話なら確認画面、秘密の生値は両方とも拒否します
- 観測のフック（止めない）：道具を呼ぶたびに、何をしたか、誰が、どの操作か、承認が要るか、本番ならどう判定されたか（許可・承認・拒否のどれか）、実際に実行されたか、を追記専用で記録します
エージェント自身が、自分を縛るルールを書き換えられる状態は、観測の結果を待たずに塞ぐ必要があります。一方、本番デプロイや公開のような業務で使う操作は、使われ方を見てから決めます。
境界のフック（止める）
- 対象はルール自体、権限設定、制御の仕組み、秘密の生値の読み出し
- 無人は拒否、対話は確認画面
- 秘密の生値は無人でも対話でも拒否
観測のフック（止めない）
- 対象は全ての道具呼び出し
- 何を、誰が、どの操作か、本番ならどう判定されたかを記録する
- 壊れても通し、エラーを記録に残す
フックが壊れても、ジョブ全体は止めない
境界のフックが止めるのは、保護対象の名前を含む操作だけです。観測のフックは、自分が壊れたときも操作を通し、エラーとして記録します。フックの不具合でジョブ全体が止まらない作りです。負荷は道具の呼び出し1回あたり数十ミリ秒で、上限は10秒に設定しています。
テストと攻撃役のレビューを先に通す
導入前に、結果が毎回同じになる決定論テストを104件書き、全件通しました。さらに、攻撃役のサブエージェントに抜け道を探させ、普段の操作で起きうる抜け道を塞いで回帰テストに加えています。塞いだものの例は、書き込み先の指定の仕方を変える書き方や、大文字小文字だけ違う同じファイルの指定です。
ただし、文字列の解析だけでは止めきれない形は残ります。意図的に隠す操作はフックでは防げません。根本対策はサンドボックスと鍵ブローカー（エージェントには参照名だけを渡し、実際の鍵は仲介役が使う仕組み）で、今回の範囲では未実装です。
過去30日の実ログで再生する
観測を始める前に、2026年10月2日〜11月1日の30日分の実ログを、新しい境界のフックに通し直しました。
- 無人ジョブ：道具の呼び出し18,168回、境界のフックが止めた回数は0回
- 対話：道具の呼び出し21,447回、確認画面が出たのは37回、秘密の読み出しの拒否は29回
確認画面37回は、すべて実際の保護対象の変更でした。
- エージェントへの指示ファイルの変更：20回
- スケジューラの設定：9回
- 秘密ファイルの削除や移動：3回
- 権限設定：2回
- 無人ジョブの共通部品：2回
- 台帳：1回
秘密の読み出しの拒否29回は、環境変数ファイルの値を表示するコマンドが21回、環境変数ファイルの読み取りが6回、設定ファイルの読み取りが2回です。
この再生で分かったのは、無人ジョブへの影響が0回だったこと、対話の確認画面は30日で37回という頻度になることです。再生中に誤検知になった実在の操作の形も見つかり、テストに入れました。
観測を始めて1日半の途中経過
2026年11月1日に観測を始め、11月2日の夕方に集計しました。約1日半ぶんの、進行中の途中経過です。週の結論ではありません。
- 記録：1,912件（壊れた行は0）
- 道具の呼び出し：969回
- Level別：0が510、1が384、2が41、3が32、4が2
- 本番なら：許可945、承認22、拒否2
- 観測のフック自身のエラー：0
承認か拒否の対象になった24件を、操作別に分けると次のとおりです。
- 本番デプロイ：10
- 台帳に無い操作：4
- noteの公開：3
- 鍵の生値の読み出し：2
- 外部への書き込み（HTTP）：2
- スケジューラの操作：1
- 鍵の保管：1
- SNSへの投稿：1
24件はすべて対話中の操作で、無人ジョブからは0件でした。24件のうち、実際に実行されたのは23件です。止めない設定なので、本番なら確認を求められた操作もそのまま通っています。
無人の実行は、完了21、中断1でした。中断1件の原因は、この集計からは不明です。観測前と比べて悪化したかどうかも、まだ判断できる日数ではありません。
最も多かったのは本番デプロイの10件でした。「台帳に無い操作」の4件は、内訳を見て台帳へ足す候補です。
止める段階へ進む条件と順番
次の判断日は2026年11月8日です。7日以上の観測を終えてから、止める候補を出します。進む条件は次のとおりです。
- 7日以上の観測で、観測のフックのエラーが0、壊れた行が0、無人ジョブで境界のフックが止めた件数が0
- 止める操作それぞれについて、承認になった実例を全件見て、誤検知が0件（または台帳を直して0件にした状態）
- 自動で承認するジョブの一覧が、実際に投稿やデプロイをしているジョブと一致している
- 無人の実行が完了する割合が、観測前より下がっていない
順番は、Level 4（本番デプロイ、広告の変更、鍵の生値、MCPの設定）から始め、一度に全部は止めません。どの操作を止めるかは、集計を見たうえで人が決めます。
観測期間中に測るのは、Level別の件数、承認になった操作の内訳と実行された件数、台帳に無い操作の内訳、無人で止めた件数、無人の実行の結果です。
止める前に記録を取る利点は、止める操作を件数ではなく実例で選べることです。11月8日の結果は、別の機会にまとめます。