意思決定モデルで agent を見張る

コーディング agent は、このモデルが最も密に使われている領域で、 しかも三か所に集中しています。三つに共通する構造は同じです。 判断を生成モデルから取り出し、より安く速いものに渡し、コードが型付きの答えを 受け取って動く。

一、ツール呼び出しの前：通すかどうか

最も直接的な場所です。Claude Code の PreToolUse フックはこうします。

Noul を一つ問う。このシェルコマンドは厳密に読み取り専用か。 0.95 で自動承認し、それ以外は通常の許可プロンプトに戻す —— そして決して deny しない。

設計上の判断が三つあります。

• 0.95 は高い。 自動承認の基準は「危険そうか」の基準よりずっと上です。 誤って通すコストはマシン一台、誤って止めるコストは確認一回。 非対称なコストは非対称なしきい値に置きます。
• 決して deny しない。 承認を増やすことだけを行い、それ以外は元の系統に戻します。 能力を足すだけのゲートははるかに試験しやすい —— 最悪の場合でも 「役に立たなかった」で済みます。
• 危険なコマンドはモデルに届かない。 ローカルの hard-no リストと インジェクションフィルタが先に止めます。これはしきい値より重要です （コードに置かねばならないものを参照）。

実測：状態を変えるコマンド 8 件のうち、自動承認されたのは 0 件。

二、agent が終わろうとするとき：本当に終わったか

もう一つの頻出箇所です。Stop フックは、意思決定モデルに 早すぎる終了かどうかを問います。自然言語で書いた完了条件をそのまま渡します。

より抑制的な版はこうです。

「ファイルが変更され、その後通った検査が一つもない」ときにだけ、 4 問の呼び出しを一度使う。いかなるエラーでも通す（fail-open）。

「問う価値があるときだけ問う」がこの種の要諦です。これらのフックは毎ターン走るので、 無条件に呼ぶとコストがターン数倍になります。上の条件は「未検証の変更」—— agent が「やりました」と言いつつ実際には検証していない、最も起きやすい瞬間です。

同種の実装に、自然言語の完了ルールを判定させて早期終了を防ぐフックもあります。

三、コンテキストが埋まるとき：何を残すか

三つ目はコンテキスト圧縮で、ここは手法の差が最も大きく、最も面白いところです。

従来の圧縮は要約です。会話の一部をモデルに渡し、文章に縮めます。 原文は失われ、要約は不可逆です。

意思決定モデルを使うやり方は違います。採点だけを行い、書き換えません。

共通する一文：ここでの意思決定モデルの役割は「残す / 残さない」の二値判断であり、 書き換えではありません。 これはまさにこのモデルが得意で生成モデルが苦手なことで、 しかも「削除せず折りたたむ」という選択が、判断を誤ったときの代償を 「情報が永久に失われる」から「もう一度展開する」に変えます。

対照：安全ゲートと効率ゲートは逆に倒れる

この領域で最も示唆的な対比です。同じ「エラー時どうするか」に対して、 プロジェクトは逆の答えを選び、そしてどちらも正しい。

• ある権限判定器：エラーやタイムアウトで拒否。
• ある Stop フック：いかなるエラーでも許可。

基準は「どちらが安全か」ではなく、このゲートが守っているのはリスクか スループットかです。リスクを守るゲート（権限、秘密、危険なコマンド）は 良いものを止める方が 悪いものを通すよりましであり、スループットを守るゲート （完了検査、書式検査）は通す方がフローを止めるよりましです。

一文で

agent はこのモデルにとって最も自然な着地点です。多くの安い判断を必要とし、 その結果がすぐコードに消費されるからです。ただしそのどの地点でも、先に決めるべきは このゲートは壊れたときどちらに倒れるべきかです。