AIに渡せない入力を止める手順 — 判定・遮断・案内の設計

社内向けのAI機能を作ると、ほぼ必ず同じ相談が来ます。「社員が機密情報を貼り付けたらどうなるのか」「変な指示を書かれて、AIが想定外の動きをしないか」。どちらも正しい心配です。そして対策は、AIモデルそのものを賢くすることではなく、AIに渡す前の入力をどう検査し、止めたときに利用者へ何を返すかという、業務システム側の設計で決まります。

この記事では、攻撃に使われる具体的な文字列やコードには触れません。中小企業の経営者・システム担当者が、開発会社と話すときに判断できるよう、考え方と手順だけを整理します。

まず「何を止めたいのか」を分けて書き出す

「危ない入力を止めてください」という依頼は、そのままでは実装できません。止めたい対象は性質が違い、検査の置き場所も判定方法も変わるからです。発注前に、次のような区分で自社の心配事を仕分けておくと話が早く進みます。

この5区分のうち、自社でどれが実際に起こりそうかを選ぶところが出発点です。すべてに同じ強度の対策を入れると、使い勝手が落ちて現場が使わなくなります。

検査は1か所ではなく、層で置く

入力の検査を「AIに送る直前の関数ひとつ」で済ませようとすると、たいてい抜けが出ます。入力はいくつもの経路からAIに届くためです。設計では次の層をそれぞれ検討します。

• 画面の層：入力欄の脇に注意書きを出す、添付できるファイル種別を限る、文字数の上限を設ける。利用者の誤操作を減らす役割です。
• アプリケーションの層：送信された内容を機械的に検査する。ここが主戦場になります。
• 参照データの層：社内文書を検索してAIに渡す仕組み（RAG）では、文書そのものに紛れ込んだ指示文が、利用者を経由せずAIに届きます。これを間接的な入力と呼び、見落としが起きやすい箇所です。
• 出力の層：AIの応答に、本来出してはいけない情報や操作指示が含まれていないかを確認する。入力で止めきれなかったものの最後の受け皿です。
• 権限の層：そもそもAIが使えるデータと操作を、利用者の権限より広くしない。これは検査ではなく前提条件です。

最後の権限設計は、検査よりも先に手を付けるべき項目です。AI機能に渡す情報と権限の線引きについては、AI コーディング支援の事故は「渡しすぎ」から起きる — 情報と権限の線引き方で整理しています。検査でふるい落とす前に、AIが触れられる範囲を狭めておくほうが確実です。

判定は「通す・確認して通す・止める」の三段にする

実装でよく失敗するのが、判定を「安全か、危険か」の二択にしてしまうことです。二択にすると、しきい値を厳しくすれば業務が止まり、緩めれば意味がなくなります。現場で続く設計は三段構えです。

判定の方法も組み合わせます。形式が決まっているもの（マイナンバーのような桁数と並びが定まった番号、社内の文書分類ラベルなど）は、決定論的なチェック、つまり毎回同じ結果が返る機械的な照合で判定します。文脈を読む必要があるもの（この質問は業務の範囲内か、指示の乗っ取りを狙っていそうか）は、別のAIに判定させる方法が使えますが、判定役のAI自身も入力の影響を受ける点に注意が必要です。判定AIの結果を唯一の防御線にせず、権限設計と決定論的チェックの上に重ねる補助として位置づけます。

また、業務システムとしての指示文（システムプロンプト）と、利用者が入力した文を構造として分けて渡すことも基本です。両者を一本の文字列に結合してしまうと、どこまでが社内の指示でどこからが利用者の文なのか、AIから見て区別がつかなくなります。

止めたあとの案内で、導入の成否が分かれる

検査の仕組みより、現場での評判を左右するのは「止めたあとの画面」です。「この入力は送信できません」とだけ表示されるシステムは、数週間で使われなくなります。止める以上、次の4点を一緒に返す設計にしてください。

1. 何が引っかかったのか：どの種類の検査に該当したかを、利用者の言葉で示す。ただし検査の判定条件そのものを細かく出すと、回避方法を教えることになります。粒度は「個人情報と思われる記述が含まれています」程度にとどめます。
2. どうすれば進めるのか：該当箇所を伏せ字にして再送する、社内環境の別機能を使う、といった代替手段を示す。
3. 例外が要るときの申請先：どうしてもその情報を扱う必要がある業務は現実に存在します。誰に申請すれば検討されるのか、導線を画面から示します。これが無いと、利用者は個人のAIサービスへ逃げます。これがいわゆるシャドーITで、最も避けたい結果です。
4. 問い合わせ用の識別子：止めた事象ごとに短い識別番号を発行し、画面に出す。担当者はその番号でログを引けるようにしておきます。

4番目は運用上とても効きます。「さっきエラーが出た」という申告は再現できませんが、番号があれば調査が成立します。何をログに残すかの設計はAIの「なぜこの答えになったか」を後から追う — ログ設計で決めるべき7項目と合わせて検討すると無駄がありません。

実装で詰まりやすい5つの箇所

見積もりの段階で話題に出ないまま、開発後半で発覚しやすい論点を挙げます。

• 誤検知の扱い：検査を厳しくすると、正常な業務入力が止まります。たとえば次のような場面です。建設会社で、協力会社の担当者名と携帯番号を含む作業メモを要約させたい。個人情報として止めるのが正しいのか、業務上必要として通すのか。これは技術ではなく社内ルールの判断であり、発注側が決める領域です。
• ログに機密を残す矛盾：止めた入力を調査用に全文保存すると、「社外に出したくない情報」が別の場所にたまります。保存するのは判定結果と識別子だけにし、全文は短期間で消すか、暗号化して権限を絞るかを先に決めます。
• 検査の抜け道になる経路：画面からの入力だけを検査し、ファイル取り込み、メール連携、バッチ処理からの呼び出しが素通りしている構成はよく見ます。AI呼び出しの入口を一本にまとめ、そこを必ず通す設計にします。
• 検査ルールの更新手順：ルールは必ず後から変わります。誰が変更を承認し、どこに記録し、問題があったときにどう戻すか。プロンプトと同様に、検査ルールも「壊れたら戻せる」形で管理する必要があります。
• テストのやり方：攻撃的な入力を集めて試すだけでなく、通るべき入力が通るかのテストを同じ数だけ用意します。検収条件は「危険な入力を止めた件数」ではなく、「正常な業務入力を誤って止めた割合」を含めて書くべきです。

発注時に文書へ残しておく項目

外部へ依頼する場合、次の項目が仕様書か議事録に残っていれば、後の揉め事はかなり減ります。

• 止める対象の区分と、各区分の判定（通す/確認して通す/止める）
• 検査を置く層と、AI呼び出しの入口を一本化する方針
• 止めたときの画面文言と、例外申請の導線
• ログに残す項目と保存期間、閲覧できる役職
• 検査ルールの変更手順と承認者
• 検収時に確認する指標（止めた精度と、誤って止めた割合の両方）

なお、社内のルールづくりの参考になる公的な文書として、個人情報の取り扱いについては個人情報保護法および個人情報保護委員会の資料、AIの利用全般については経済産業省・総務省の「AI事業者ガイドライン」、技術面の整理としてはOWASPが公開しているLLMアプリケーション向けのリスク一覧、情報処理推進機構（IPA）の各種資料があります。いずれも内容は改訂されるため、参照するときは最新版を確認してください。

まとめ

AIに渡してはいけない入力を止める作業は、賢い判定ロジックを一つ作れば終わるものではありません。実務で効くのは、次の順序です。

1. 止めたい対象を5つの区分に仕分け、自社に当てはまるものだけを選ぶ
2. AIが触れられるデータと操作を、権限設計で先に狭める
3. 検査を層で置き、AI呼び出しの入口を一本化する
4. 判定を「通す・確認して通す・止める」の三段にし、誤検知の逃げ道を用意する
5. 止めたあとの案内と例外申請の導線を画面に実装する
6. ルールの変更手順と、誤って止めた割合を含む検収条件を文書に残す

利用者から見れば、止められた瞬間がそのシステムへの評価が決まる瞬間です。止める仕組みと同じだけの手間を、止めたあとの案内にかけてください。それが、現場に使われ続けるAI機能と、半年で放置されるAI機能を分けます。