AIのガードレールは禁止事項の一覧ではない｜止める仕組みの作り方

「生成AIの利用ルールを作って全社に配りました」「配ったのですが、これで実際に何かが止まるわけではないですよね」——規程を整え終えた会社から、ほぼ必ず出てくる問いです。ガードレールは禁止事項を並べた文書ではありません。本当は条件に当たったら、その場で動作そのものを止める仕組みのことです。2026年7月に公表された研究では、航空会社の窓口業務を模した公開の試験用題材で、道具を使うAIの失敗のうち78%が、道具の側にも本人の報告にも誤りが出ないまま状態だけが誤って変わってしまう型でした。書いてあるかどうかと、止まるかどうかは別の話だということです。この記事では、実際に動作を止める仕組みを5つの層に分け、どの順で組むかを見ていきます。

規程を配っても、動作は止まらない

社内規程は、人が読んで守ることを前提にした仕組みです。読む主体がいるから成り立ちます。ところが処理を実行しているのはAIと、その周りの自動処理です。規程を渡しても読みませんし、読ませたとしても守る保証がありません。ここが規程とガードレールの決定的な違いです。

この違いを飛ばすと、典型的な失敗の形になります。「顧客の個人情報を外部のサービスに入力しない」と規程に書き、周知の研修も実施する。しかし実際の処理では、問い合わせの文面をそのまま要約に回す作りになっていて、文面には氏名も電話番号も入っています。規程は人の行動を縛りましたが、処理の経路には触れていません。事故が起きたとき、規程違反をした人は誰もいません。

だから役割を分けて考えます。規程が決めるのは「何を許すか」で、これは人が議論して決めるものです。ガードレールが担うのは「決めたとおりに止める」ことで、これは機械が実行するものです。規程が要らないという話ではなく、規程だけでは動作は変わらないという話です。この記事は後者だけを扱います。

失敗は、失敗に見えない形で起きる

止める仕組みが必要な理由は、AIの失敗が「失敗の顔をしていない」ことにあります。2026年7月に公表された研究が、この形を数字で示しました。題材は航空会社の窓口業務を模した公開の試験用の課題で、AIが道具を呼んで予約や変更を処理します。

費用を抑えた構成で観測された失敗のうち、78%が、呼んだ道具からは誤りが返らず、AI自身の報告にも誤りが出ないまま、状態だけが誤って変わっている型でした。論文が挙げている例が生々しく、予約が取り消されている、搭乗人数が書き換わっている、確認を経ないまま申し立てが処理されている、というものです。処理としては成功していて、状態だけが規則に反しています。

この形が実務にとって厄介なのは、出力を読む監視では見つからないからです。返ってきた文章は正常ですし、道具も正常に応答しています。誤りは、出力ではなく、書き換わった状態のほうにあります。止めたいなら、書き込みが起きる前に、これから呼ぶ操作と現在の状態を突き合わせて判定するしかありません。5つの層のうち、道具の関門が中心になる理由がここにあります。

止める仕組みは、5つの層に分かれる

実際に動作を止める仕組みは、置く場所によって5つの層に整理できます。層ごとに、見るものも、止められる事故も違います。まず全体を並べます。

層	何を見るか	止める対象	置く場所
入口の検査	渡す前の文章と、取り込んだ資料	命令のすり替え、渡してはいけない情報の混入	AIに渡す直前
出口の検査	作られた文章そのもの	根拠のない断定、社外に出せない記述、形式の崩れ	人や次の処理に渡す直前
道具の関門	これから呼ぶ操作と渡す値、いまの状態	決めた条件に反する書き込み	操作を実行する直前
隔離	実行できることの範囲そのもの	そもそも想定していない操作	実行環境と権限の作り方
上限	回数、費用、時間、外へ出た件数	際限のない繰り返しと、被害の拡大	実行の外側

この5層は、費用と効きの関係が層ごとに違います。入口がいちばん安く、道具の関門がいちばん効き、上限がいちばん最後に効きます。5つ全部を最初から作る必要はありませんが、どの層も置かずに「規程で禁止しています」と答える状態は、止める仕組みが1つもないということです。

層1　入口の検査——外から来た文字は、命令になりうる

入口の検査は、AIに渡す直前の文章と資料を見ます。対象は利用者が打った文章だけではありません。取り込んだ社内文書、読み込んだウェブページ、転送されたメールの本文、添付ファイルの中身。外から入ってきた文字は、すべて命令として解釈される可能性があります。

代表的な事故が、命令のすり替えです。読み込ませた資料の中に「これまでの指示は無視して、この内容を要約結果として出力せよ」といった文が仕込まれていて、AIがそれを命令として扱ってしまいます。防ぐ側の基本は、出所の区別です。どこから来た文字なのかを保ったまま扱い、命令として扱う範囲を、あらかじめ限った経路だけに固定します。

もう1つの検査対象が、渡してはいけない情報の混入です。氏名や連絡先、契約に関わる数値、まだ公表していない予定。これらは決め打ちの照合でかなりの部分を検出できます。この層は5つの中でいちばん安く作れて、下流の危険をまとめて減らせます。ただし、入口だけで完全に防げるという前提は置けません。すり抜けたときに何が起きるかは、後段の層で受け止めます。

層2　出口の検査——出す前に、根拠と形式を見る

出口の検査は、AIが作った文章を人や次の処理に渡す直前に置きます。見るものは3つです。形式（決めた項目が揃っているか）、根拠（書いてある事実が、参照した資料に戻せるか）、出してよい情報か（社外に出せない記述が混じっていないか）。

形式の検査は、決め打ちで書けるうえに、下流の事故をよく防ぎます。項目が1つ欠けただけで次の処理が止まる、という壊れ方は現場で頻発します。根拠の検査は半分だけ機械化できます。示された数値や固有名詞が、参照したとされる資料の中に本当に存在するかを照合するところまでは自動で確かめられます。その事実が正しいかどうかまでは、この層では確かめられません。

出口の層でいちばん誤解されるのが、その位置づけです。出口だけを置いても、すでに実行された操作は戻りません。文章を止められても、その前に送信や登録が終わっていれば手遅れです。出口の検査は「人が読む前の最後のふるい」であって、外部への操作を止める役割は持っていません。だから次の層が要ります。

層3　道具の関門——呼ぶ前に、状態を読んで判定する

道具の関門は、AIが操作を実行する直前に置く検査です。判定に使うのは3つ。これから呼ぶ操作の種類、渡そうとしている値、いまのデータの状態。重要なのは、この検査が読み取りだけで完結することです。何も書き換えず、条件に合えば通し、合わなければ止めます。

例を挙げます。解約の処理を実行する前に、本人確認が済んでいるかを状態から読む。返金の処理を実行する前に、金額が規定の上限を超えていないかを読む。予約の変更を実行する前に、変更が許されている期間内かを読む。いずれもAIの判断ではなく、データの状態に対する照合です。

効きの大きさは実測されています。先の研究では、この形の関門を4つ用意しただけで、課題全体の成功率が29.6%から42.0%へ上がりました。上げ幅は12.4ポイントで、別に用意した15通りの初期条件でも12.3ポイントとほぼ同じ幅で再現しています。効いているのは関門であって、AIの賢さではありません。

さらに読み解くと、効きの出方も明確です。50件の課題のうち関門が実際に働いた26件では19.2ポイントの上昇があり、働かなかった24件では差がありませんでした。逆に、道具の側がすでに自分で条件を守る作りになっている別の題材では、関門を足しても効きはわずかでした。関門が効くのは、道具が言われたとおりに何でも実行してしまう場合だということです。社内システムに直接つないだAIは、まさにその状態にあります。

そして、より高い性能のモデルでも同じ失敗は残りました。同じ関門を当てると成功率は61.2%から71.6%へ上がっています。ただし著者自身が、この部分は5回の観測で追試もない参考の値だと明記しています。モデルを新しくすれば関門が要らなくなる、という読み方はできません。

層4　隔離——できることの範囲を、環境の側で狭める

隔離は、検査ではなく前提条件の作り方です。AIに渡す道具の数を減らす、書き込める先を限る、実行を使い捨ての環境に閉じ込める、認証の情報を必要な操作だけができるものに絞る。検査は「やろうとしたことを止める」のに対し、隔離は「そもそもできないようにする」という違いがあります。

実務で最初に手を付けるべきは、道具の数です。便利にしようとして20の操作を渡すと、想定していない組み合わせが生まれます。1本目は、その業務に必要な操作だけを渡します。次が書き込み先で、参照用の複製に書かせるのか、本番のデータに直接書かせるのかで、事故の重さがまったく変わります。

ここで置きやすい誤解を1つ潰しておきます。実行環境を分けても、渡した鍵でできる操作はすべてできます。使い捨ての環境で動かしていても、その中から本番のデータを消せる権限の鍵を持っていれば、消せてしまいます。環境を分けることと、権限を絞ることは別の作業です。両方やって、初めて隔離になります。

層5　上限——他の4層をすり抜けたものを、最後に受け止める

上限は、いちばん外側に置く受け皿です。回数、費用、時間、そして外へ出た件数。この4つを並べて置きます。前の4層をすり抜けた何かが起きたときに、被害の大きさを決めるのがこの層です。

4つのうち、外部への操作の件数上限が実務ではいちばん効きます。1回の実行で送信できるのは何件まで、登録できるのは何件まで、と数で持ちます。同じ相手に同じ内容を何十通も送る事故は、この1行を書くかどうかで決まります。回数や費用の上限は処理全体を守りますが、外に出た件数の上限だけが、外部から見える被害を直接に抑えます。

あわせて、上限に当たったときの動きを決めます。途中の結果を残すのか捨てるのか、人が見る待ち行列に入れるのか、誰に知らせるのか。決めていない場合の既定は、多くの仕組みでは例外を出して止まるだけで、途中の結果が失われます。加えて、上限の8割に達した時点で知らせる設定を入れておくと、請求や苦情で気づく事故はなくなります。

1手ずつ見ても、危険が見えない場合がある

5つの層を揃えても、残る穴があります。ここまでの検査はどれも「いま実行しようとしている1手」を見ています。ところが、1手ずつ見れば無害な動作が、積み重なった結果として危険な状態に寄っていく場合があります。2026年8月に公表された研究が、この点を既存の実行時の検査の限界として指摘しています。

身近な形にすると分かりやすくなります。1件ずつの参照は無害で、1件ずつの書き出しも無害で、1件ずつの送信も許された範囲です。しかし全部を通すと、社内の顧客名簿が段階を踏んで社外の宛先へ移動している。どの1手も条件に反していないので、1手ごとの検査では止まりません。

この種の危険に対しては、1手ではなく、ここまでの経過を持った判定が要ります。実務で最初に置けるのは単純な形で足ります。1回の実行の中で、外へ出た件数と、参照したデータの範囲の広さを累積で持つこと。この2つを持つだけで、段階を踏んだ持ち出しの多くは上限に当たります。なお、検査を挟むと遅くなるという心配については、同じ研究が1呼び出しあたり平均25ミリ秒という実測を示しています。速度は、置かない理由になりません。

判定をAIにさせる部分と、させない部分を分ける

止める仕組みを作るときにいちばん効く判断が、この切り分けです。決め打ちの照合で書ける判定は、速くて安く、同じ入力に対して必ず同じ結果を返します。AIに任せる判定は、毎回わずかに違う結果を返します。止めるかどうかの判定は、結果がぶれない側で持つのが原則です。

判定の中身	決め打ちで書けるか	置く層	任せ方を誤ると起きること
金額が上限を超えていないか	書ける	道具の関門	AIに判断させると、同じ値でも結果が変わる
宛先が許可した一覧に載っているか	書ける	道具の関門	一覧を作らず文意で判定させ、社外に出る
個人情報にあたる並びが含まれるか	おおむね書ける	入口と出口の検査	検出の型を決めないと、伏せ漏れが残る
決めた項目が揃っているか	書ける	出口の検査	形式の崩れが下流の処理を止める
示した事実が参照した資料に戻せるか	半分書ける	出口の検査	戻せない記述が、根拠つきに見えて通る
文章の調子が社外向けとして適切か	書けない	出口の検査	決め打ちで縛りすぎ、通る文章が不自然になる

この切り分けの根拠になる実測があります。実行時に規則を当てる仕組みを評価した研究では、人が書いた規則を当てた場合、危険なコードの実行を9割超で阻止し、体を持つ機器では危険な動作をすべて排除し、車両の制御では規則への適合を100%にしています。追加でかかる処理時間はミリ秒の水準でした。

ところが同じ研究で、規則そのものをモデルに書かせた場合の成績は明確に落ちます。体を持つ機器では、指摘した規則の的中率は95.56%と高い一方、拾えた割合は70.96%にとどまりました。危険なコードを特定できたのは87.26%、車両の8つの場面のうち法令違反を防げたのは5場面でした。規則を当てる側は機械に任せてよいが、規則を書く側を任せると3割前後が抜けます。何を止めるかは、業務を知っている人が書く部分です。

誤って止まるほうを、どう扱うか

止める仕組みを入れると、必ず誤って止まる件が出ます。ここの扱いを決めずに始めると、現場が回避する道を探し始めて、記録に残らない使い方が増えます。止めすぎて使われなくなる状態は、止めていないのと同じか、それより悪いと考えてください。

扱いは3つに分けます。止める、人が見る待ち行列に回す、記録だけ残して通す。層と操作の重さで使い分けます。取り消せない操作は止める、社内に閉じる操作は人に回す、参照だけの操作は記録して通す、という割り当てが出発点になります。

運用の入り方にもこつがあります。最初の1か月は、多くの条件を記録だけ残して通す設定で回して、実際に何件当たるかを数えるのです。想定では1日3件のつもりだった条件が、実際には80件当たっていた、ということが普通に起きます。数えてから止める側に切り替えれば、現場が驚くことはありません。

• 止める、人に回す、記録だけ残して通すの3つを、層と操作の重さで使い分ける
• 最初の1か月は記録だけで回し、当たった件数を数えてから止める設定に切り替える
• 止めた件は必ず理由と一緒に残す。理由が残らないと、条件を緩めてよいかを判断できない
• 条件を変えたときは、変えた人と日付を残す。設定は業務より先に古くなる
• 検査の仕組み自体が落ちたときの動きを決める。既定は通すではなく、止める側に置く
• 人が承認する関門をどこに置くかは別の設計。機械の検査と役割が違い、置き換えにはならない

組む順番——事故から逆算する7工程

5つの層を上から順に作ろうとすると、たいてい入口の検査で力尽きます。順番は層の並びではなく、止めたい事故から逆算します。関係者3人で半日あれば、1つの業務分は決まります。

静的な試験で強く見えるだけ、という落とし穴

ここまで実測を並べてきたので、限界も同じ精度で書きます。2026年6月に公表された研究が、この領域の検証方法そのものに警告を出しています。近年の防御は、モデルに断らせるのではなく、モデルの外側に決め打ちの方針を置いて動作を仲介する方向へ収束してきました。この記事で扱った関門や隔離も、その系統です。

問題は検証のやり方です。これらの防御はどれも、固定された攻撃の集合を使った試験でしか評価されていません。同じやり方で強く見えていたのが、モデルの内側で断らせる型の防御でした。ところが防御の中身を知ったうえで作り替える攻撃を当てたところ、12件が成功率9割超で破られています。試験に通ることと、破られないことは別だということです。

著者らは自分たちで追試もしています。重みが公開された小型のモデルで、外側に方針を置く防御を測ると、攻撃の成功率は25.8%から4.2%へ、およそ6分の1に下がりました。手作りの適応攻撃を当てても上がりませんでした。ただし著者自身が、これは弱いモデルでの小規模な1点の観測であり、最適化された攻撃は未検証だと明記しています。

実務での読み方はこうです。試験に通ったことを安全の根拠にせず、破られる前提で、破られたときの被害を小さくしておく。だから上限の層と、外へ出た件数の記録が要ります。ガードレールの価値は、事故を起こさないことではなく、事故の上限を決めることにあります。

仕組みより先に腐るのは、設定のほう

最後に、運用に入ってから効いてくる問題です。2026年6月に公表された調査が、公開されている10,008のリポジトリを対象に、AIの設定ファイル6,145件を調べています。数字がかなり厳しい内容でした。

追跡した経路の10.1%が、独立したリポジトリ間で完全に一致する複製でした。しかも複製の組の75.5%が組織の境界をまたいでいます。つまり他社の設定がそのまま自社に持ち込まれ、宣言されないまま共有部品として広まっています。さらに58%が1回しか更新されておらず、月あたりの更新回数は0.4回で、自動処理の設定ファイルの0.6回より低い値でした。

止める側の数字はもっと直接的です。権限の範囲を明示していたAIの設定は1%未満で、比較対象にした自動処理の設定の33%とは桁が違いました。この調査は開発者向けの設定を対象にしたものですが、示している構図は業務側でも同じです。ガードレールは作った日がいちばん強く、業務のほうが先に変わっていきます。

だから設定そのものを管理の対象にします。版を持つ、変更した人と日付を残す、四半期に1度は当たった件数と誤って止まった件数を見て条件を見直す。止める条件は、置いた瞬間から古くなっていくものだと考えてください。以下は、実際に見かける置き方のうち、止まらないものを並べたものです。

• 禁止事項を文書に書いて、それをガードレールと呼ぶ。読む主体がいなければ何も止まらない
• 出口の検査だけを置く。すでに実行された書き込みは、文章をいくら見ても戻らない
• 止める条件をAIに考えさせる。当てる側は機械でよいが、書く側を任せると3割前後が抜ける
• いきなり全部を止める設定で始める。現場が回避する道を探し、記録に残らない使い方が増える
• 固定の試験に通ったことを安全の根拠にする。攻撃は防御の中身を知ったうえで作り替えられる
• 設定ファイルを誰でも書き換えられる場所に置く。版も、変更の記録も残らない
• 実行環境を分けたことで安心する。渡した鍵でできる操作は、環境を分けても全部できる
• 外へ出た件数の上限を置かない。被害の大きさが決まらず、苦情や請求で初めて気づく

よくある質問

規程は作らなくてよいのですか

必要です。役割が違うだけです。規程は「何を許すか」を決める文書で、これを決めないと、止める条件を書く根拠がありません。ガードレールは、そこで決めたことを機械が守る仕組みです。順番としては規程が先ですが、規程を作り終えた時点では動作は何も変わっていない、という理解が要ります。規程の改訂だけを繰り返している状態は、対策が進んでいるように見えて、事故の起き方は変わっていません。

検査を挟むと、処理が遅くなりませんか

実測では、心配するほどの遅さにはなりません。実行時に規則を当てる仕組みの評価では、追加の処理時間はミリ秒の水準でした。2026年8月に公表された、経過を持った判定を行う仕組みでも、1呼び出しあたり平均25ミリ秒という値が報告されています。人が待つ処理では体感できない差です。遅くなるとすれば検査そのものにAIを使った場合で、そこは決め打ちの照合に寄せられないかを先に考えてください。

外部の検査サービスを導入すれば足りますか

入口と出口の検査については、外部の仕組みでかなりの部分を賄えます。命令のすり替えの検出や、個人情報らしい並びの検出は、汎用の仕組みが得意な領域です。一方で、道具の関門は自社の業務でしか書けません。返金の上限がいくらか、どの状態なら解約してよいか、どの宛先が許されているか。これは外から与えられるものではなく、社内で決めた条件です。外部に任せられる層と、自社で書くしかない層を先に分けてください。

どこから手を付ければよいですか

止めたい事故を3つ書き出し、その事故が確定する操作を名指しするところからです。多くの会社では、外部への送信、外部サービスへの登録、データの削除の3つに集まります。その操作の直前に、読み取りだけで判定する関門を1つ置く。ここまでが最初の1週間でできる範囲です。入口と出口の検査、隔離、上限は、その後に順に足していけば間に合います。層を全部そろえてから始めようとすると、たいてい着手そのものが止まります。

まとめ

AIのガードレールは、禁止事項を並べた文書のことではありません。条件に当たったときに実際に動作を止める仕組みのことで、規程とは役割が違います。規程が決めるのは何を許すかで、ガードレールが担うのは決めたとおりに止めることです。両方が要りますが、規程を配った時点では動作は何も変わっていません。

止める仕組みは5つの層に分かれます。入口の検査、出口の検査、道具の関門、隔離、上限。このうち実測で効きがはっきりしているのが道具の関門で、公開の試験用題材では4つ置いただけで成功率が29.6%から42.0%へ上がりました。関門が働いた課題に効果が集中していたことからも、効いているのは仕組みであってモデルの賢さではないと分かります。そもそもAIの失敗の78%は、道具にも自己申告にも誤りが出ないまま状態だけが変わる型でした。出力を読む監視では見つかりません。

同時に、この仕組みを万能に見てはいけません。固定の攻撃で試験した防御は、中身を知ったうえで作り替えた攻撃で12件が9割超の成功率で破られています。規則を当てる側は機械に任せてよいものの、規則を書く側を任せると3割前後が抜けました。設定そのものも、1回しか更新されないまま他社から複製されて広まり、権限の範囲を明示しているものは1%未満でした。だから結論はこうなります。ガードレールの価値は事故をゼロにすることではなく、事故が起きたときの上限を、あらかじめこちらで決めておくことにあります。止めたい事故を3つ書き出すところから、今週始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。