確認ゲート（ドライラン）

破壊的なコマンドを機械が confirm 無しで呼ぶと、実行されずに影響件数だけが返ります。

await oniyanma.execute('deleteSelection')

{
  "preview": true,
  "command": "deleteSelection",
  "wouldAffect": {
    "points": 128340,
    "note": "resident（表示中 LOD サンプル）基準の件数"
  },
  "note": "未実行です。この内容で実行するなら同じ引数に confirm:true を付けて再実行してください（Undo 可能ですが、協働中は全員の画面に即反映されます）"
}

件数を見て妥当なら、同じ引数に confirm: true を足して再実行します。

await oniyanma.execute('deleteSelection', { confirm: true })   // → { ok: true }

対象のコマンド

コマンド	ドライランが返すもの
hideSelection	選択点数（resident 基準）
deleteSelection	同上
reclassifySelection	同上
colorSelection	同上
clearEdits	編集件数 ＋「協働中は他の参加者の編集も消える」
deleteFinding	所見件数 ＋「取り下げても記録は残り復元できる」
revertBatch	戻せる束（applied 状態）の件数。他人が作った束は戻せない

選択が無い場合は「0 件」で終わらせず、 { points: 0, note: '選択がありません（先に選択してください）' } のように理由を返します。 0 件と「そもそも選んでいない」は、エージェントにとって次の一手が違うからです。

誰に効くか

発行者	ゲート
ai — AI コンソール	通る
api — window.oniyanma / MCP 経由	通る
human — UI ボタン / ⌘K / ショートカット	通らない

人間は自分の操作の結果を画面で見ているので、二重確認はノイズにしかなりません。 機械は結果を見ずに次の呼び出しへ進めるので、一度止めます。

例外は「全編集をクリア」で、協働中は他人の編集も消えるため、 UI 側にも件数付きの確認ダイアログを出します。

これとは別のゲートもある

acceptBatch / confirmFinding / rejectFinding は confirm:true を付けても機械からは 実行できません（人間専用ゲート）。ドライランは「一度止めて確認させる」、 こちらは「そもそも機械には許可しない」という別の強さのゲートです。

なぜプロンプトではなくコマンド層に置くのか

システムプロンプトに「破壊的操作の前に確認してください」と書くこともできます。 実際に書いてもいます。ただしそれは防御層ではありません。

• モデルを変えると挙動が変わる
• 長い会話では指示が薄まる
• プロンプトインジェクションで上書きされる
• window.oniyanma や MCP から直接呼ばれる経路には、そもそもプロンプトが介在しない

確認をコマンド層の構造（registry.ts の dryRun）として持たせれば、 どの経路から呼ばれても、どのモデルでも、必ず 1 度止まります。 コマンドを足す人が dryRun を書くだけで、全経路に効きます。

件数の読み方

wouldAffect.points は resident 基準、つまり表示中の LOD サンプルでの件数です。 原本の全点走査ではありません。寄れば増えます。

「この範囲に何点あるか」の厳密な値ではなく、 「いま実行したらどれくらい消えるか」の桁を確認するための数として使ってください。 → リファレンス概要

評価

「件数プレビュー → confirm: true の 2 段を踏めるか」は、 評価セットの guarded tier（13 件）として測定しています。 モデルを下げる判断は、この通過率を見て行います。