AI実装録 / 不可逆な操作をどう止めるか
不可逆な操作をどう止めるか — 手順書は飛ぶ、という前提の多層防御
最終更新: 2026年9月2日
システムの運用には、実行した瞬間に取り返しがつかなくなる操作があります。本番環境への反映、データの削除、外部へのメール送信。これらは失敗しても「元に戻す」という選択肢が存在しないか、あっても非常に高くつきます。
こうした操作については、たいていの組織が手順書を持っています。そして手順書は飛びます。急いでいるとき、割り込みが入ったとき、あるいは「今回だけ」と思ったときに。
本稿では、手順が飛ぶことを前提にした多層の防御を、当社の実装を例に論じます。あわせて、実行者が人間ではなく AI エージェントになったときに何が変わるかを扱います。
前提：当社サイトの反映の流れ
先に、例として使う仕組みを説明しておきます。当社サイトの変更は、次の 3 段階で本番に届きます。
- 手元の環境で作成・修正する
- 検証環境（本番と同じ構成の確認用サーバ）に反映し、動作を確かめる
- 人間が承認したうえで本番に反映する
各段階への反映は、ファイル一式を同期するコマンド 1 つで行います。つまり、コマンドの打ち方ひとつで、検証を飛ばして本番に反映することも物理的にはできてしまう構成です。だからこそ、それを防ぐ層が要ります。
手順書が飛んだ実例
以前、当社は本番反映の作業中に届いた別の修正依頼を、そのまま同じ反映に混ぜて本番へ送りました。結果として、検証環境を経ていない変更が 2 件、本番に入りました。
「検証環境で確認してから本番」というルールは、当時すでに文書化されていました。担当者がそれを知らなかったわけでもありません。本番反映の作業中に追加の依頼が届き、「ついでだから」と判断した、それだけです。
ここから引き出せる教訓は「気をつける」ではありません。手順書は、それを守る余裕があるときにしか機能しないということです。そして、守る余裕がないときこそ事故は起きます。手順書だけでは、防御になっていません。
対策として、当社は反映コマンドの側に検査を入れました。本番へ送ろうとしている内容が、検証環境でいま動いているものと一致するかを照合し、一致しなければコマンド自体が中断する。「守るべき手順」を、「破りようのない構造」に置き換えたわけです。
層を数える — 予防・検出・回復
多層防御は、性質の違う 3 系統で考えると設計しやすくなります。
| 系統 | 目的 | 効く場面 |
|---|---|---|
| 予防 | そもそも実行させない | 事故の前 |
| 検出 | 実行されたことに早く気づく | 事故の直後 |
| 回復 | 元に戻せる状態を保つ | 気づいたあと |
予防だけを厚くしても足りません。 予防の仕組みが見ているのは「操作が正しい手続きを踏んだか」であって、「操作の中身が正しいか」ではないからです。検証を通し、承認も得た、しかし修正そのものが間違っていた——この操作はすべての予防をすり抜けて実行されます。だから、実行されたあとの系統（検出・回復）が別に必要になります。
当社サイトの反映経路には、現在この層が入っています。
| 層 | 内容 | 系統 |
|---|---|---|
| 既定は「予行」 | 反映コマンドは、実行の意思を示す引数を付けない限り変更予定の一覧を表示するだけで終わる | 予防 |
| 検証環境との照合 | 本番へ送る内容が検証環境で稼働中のものと一致しなければ、コマンドが中断する | 予防 |
| 対話確認 | 本番のみ、キーボードから yes と 3 文字打たないと進まない（y や Enter の空打ちでは通らない） | 予防 |
| 承認の都度取得 | 過去の承認を使い回さない。変更ごとに承認を取り直す | 予防 |
| 差分の事前提示 | 実行前に、何がどう変わるかの一覧を人間に見せる | 予防・検出 |
| 反映後の照合 | 反映後、本番の応答を機械的に確認する（ページが開くか、変更が届いているか） | 検出 |
| 削除を伝播させない | 同期は追加・更新のみ。手元でファイルを消しても、本番からは自動では消えない | 被害の限定 |
| 環境固有ファイルの除外 | 各サーバの設定ファイルは同期対象から外し、上書き事故を構造的に不可能にする | 被害の限定 |
| 版管理 | すべての変更を履歴として保存し、任意の時点の状態に戻せる | 回復 |
最後の 3 つが要点です。予防と検出がすべて破れても、戻せるなら事故は「手戻り」で済みます。 逆に、回復手段のない対象（送ってしまったメール、消してしまった唯一のデータ）では、予防に頼るしかなくなる。層の厚みは、回復できるかどうかで変えるべきです。
それぞれの層は、単独では破れる
多層防御を名乗るからには、1 枚 1 枚は破れる前提でなければなりません。代表的な層の破れ方を書いておきます。
既定は「予行」 — 破れ方は「実行の引数を付けるのが習慣になる」。予行の出力を読まずに実行するようになれば、この層は消滅します。これは防御ではなく摩擦であり、摩擦は慣れると効かなくなります。
対話確認 — 破れ方は同じく習慣化。それでも y や Enter で通らない設計にしてあるのは、惰性で押せる操作にしないためです。3 文字打つあいだに読み返す余地が生まれる、という程度の効果しか期待していません。
承認の都度取得 — 破れ方は「今日はもう承認をもらっているから」。実務では最も摩擦の大きい層ですが、冒頭の事故はまさにこの層が無かったために起きました。反映作業の途中で届いた依頼は、承認済みの作業と地続きに見えます。だからこそ、承認の単位を機械的に区切る必要があります。
「削除を伝播させない」という層は、誤削除を防ぎます。しかしその裏返しとして、手元で削除したファイルが本番に残り続けます。
当社は不要になったファイル群を整理した際、これを踏みました。手元では消えているのに、本番では公開されたままだったのです。結局、サーバごとに個別の削除作業が必要になりました。
層は無料ではありません。 1 枚足すたびに、その層に固有の失敗モードが増えます。「念のため全部入れる」は設計ではなく、思考の放棄です。
実行者が AI になると何が変わるか
ここからが現在の論点です。当社は自社の開発・運用業務に AI エージェントを使っており、本稿の執筆も含めて、実際の作業の多くを AI が実行しています。
不可逆操作の防御という観点では、人間と AI では壊れ方の性質が違います。
| 人間 | AI エージェント | |
|---|---|---|
| 事故の典型 | 急ぐ・疲れる・慣れる | 指示や状況の前提を取り違える |
| 手順の遵守 | 状況次第で飛ばす | 明確な指示は飛ばさない。曖昧な指示は誤解したまま実行する |
| 危険の察知 | 経験から「なんか変だ」と手が止まる | 違和感による停止は期待できない |
| 繰り返し | 疲れて雑になる | 何度でも同じ精度で実行する |
AI は急ぎませんが、立ち止まりもしません。 決められた手順を守らせること自体は人間より容易な一方、手順の外側で「この操作はおかしい」と気づいて止まることは期待できません。したがって、人間向けに設計された「注意を促す」型の層——警告文、確認ダイアログ、赤い文字——は、AI に対してはほぼ無効です。AI は警告を読み、了解し、実行します。
当社が採っている方針は単純です。AI は提案と検証まで。実行の承認は人間。 具体的には、AI が変更内容と差分を提示し、人間が承認し、承認されたその内容の機械的な実行は AI が行う。判断だけを人間に残しています。
この考え方は AI 開発・運用ポリシー 第 4 項として明文化しました。そこには「AI エージェントが単独の判断で本番環境を変更することはありません」と書いてあります。「AI に本番の権限を与えない」とは書いていません。承認を得たうえで AI が反映作業を実行することは実態としてあり、実態より強く書けば文書が嘘になるからです。この線引きの設計論は 監修型の AI 協働 で扱っています。
摩擦のかけすぎは、迂回を生む
多層防御でよくある失敗が、層を厚くしすぎて日常の運用が回らなくなることです。
回らなくなった手順は守られません。守られない代わりに、手順を通さない裏道が生まれます。「緊急時用」と称した迂回経路が日常的に使われるようになったら、その組織の防御は名目だけのものになっています。
判断の目安として、当社は次のように考えています。
- 不可逆性の高さと、回復できるかどうかに応じて層を増やす。 一律に厳しくしない。検証環境への反映と本番への反映では、要求する手続きを変える
- 例外を設けるなら、例外を通ったことが記録に残る形にする。 迂回を禁止し切るより、迂回が見えるほうが現実的です
- 摩擦は「読み返す時間を作る」ためにかける。 面倒にすること自体が目的ではありません
まとめ
不可逆な操作の防御は、手順書を書くことではありません。手順書が飛ぶ状況を想定して、飛んでも止まる構造を作ることです。
そのために、予防・検出・回復の 3 系統で層を数える。予防は「手続きの正しさ」しか見ていないと知り、実行後の系統を別に持つ。各層が単独では破れることを認め、層を足すたびに増える固有の失敗モードも引き受ける。そして摩擦をかけすぎて迂回を生まないよう、回復できるかどうかに見合った重さに調整する。
実行者が AI エージェントになると、この設計は組み直しになります。AI は手順を飛ばしませんが、危険にも気づきません。「注意を促す」層を、「構造として不可能にする」層へ置き換える必要があります。
本稿の内容は、第三者としてベンダーの構成や運用手順を検証する 技術監修 の実務に基づいています。当社の方針は AI 開発・運用ポリシー に定めています。