生成AI利用停止対策で会社が先に決める社内ルール

生成AIを社内で使うほど、気になるのは「便利かどうか」だけではありません。ある日、社内判断や規約変更、障害、モデル廃止で使えなくなった時、今日の顧客対応や制作、調査、社内文書作成が止まらないかも見ておく必要があります。

生成AI利用停止対策は、AIを使うか禁止するかの議論ではなく、止まっても業務が続く状態を作ることです。この記事では、会社が先に決めておきたい社内ルールを、入力情報、停止判断、代替手順、保存先、月次点検の順で整理します。

生成AI利用停止対策は「禁止」ではなく業務継続の設計で考える

生成AIの社内利用を考える時、話が「使わせるか、禁止するか」に寄りがちです。しかし会社として必要なのは、AIが止まった時に、どの業務をどの手順で戻すかを先に決めることです。

総務省・経済産業省のAI事業者ガイドライン第1.2版は、AIの便益とリスクの大きさに応じて対策を調整する考え方を示す文書です。中小企業の実務でも、この考え方は使えます。低リスク業務まで一律禁止にするより、危ない入力と止める条件を明確にする方が、現場の無断利用も抑えやすくなるでしょう。

出典: 総務省・経済産業省「AI事業者ガイドライン 第1.2版」

使っていたAIが急に止まる理由やベンダー依存の考え方は、使っていたAIが急に使えなくなる理由の記事でも整理しています。本記事では、その前提をさらに社内ルールへ落とし込みます。

止まる理由	起きる例	先に決めること
社外要因	障害・モデル廃止・規約変更	代替手順と告知確認
社内判断	漏えい疑い・監査指摘	停止判断者と再開条件
業務要因	誤回答増加・品質低下	人間確認と差し戻し基準
運用要因	権限・請求・APIキー不備	管理者と復旧連絡先

まず棚卸しするのはAIツール名ではなく業務への入り込み方

最初に棚卸しするのは、AIツール名ではなく業務への入り込み方です。ChatGPT、Claude、Gemini、Copilotのどれを使っているかだけを聞いても、停止時の影響は見えません。

見るべきなのは、どの部署が、どの業務で、どんな情報を入れ、どこに成果物を残しているかという点です。たとえば営業メールの下書きなら、停止しても人手で戻せます。一方、顧客問い合わせの一次回答や社内文書検索に深く組み込まれている場合は、止まった日の影響が大きくなるでしょう。

社内利用の初期ルールをまだ作っていない場合は、生成AIの社内利用ガイドラインの作り方を先に読むと、棚卸し項目を作りやすくなります。

• 部署: 営業、制作、管理、採用、カスタマーサポートなど
• 業務: 調査、要約、返信案、議事録、文書検索、コード生成など
• 入力情報: 公開情報、社内資料、顧客情報、個人情報、契約情報など
• 成果物: 下書き、回答文、分析表、プロンプト、判断メモなど
• 保存先: 会社のDrive、Notion、Microsoft 365、CRM、ローカル端末など

入力禁止情報と承認制情報を3区分で分ける

入力情報は、入力可、承認制、入力禁止の3区分に分けると運用しやすくなります。すべてを禁止すると現場は使いにくくなり、すべてを許可すると事故の入口が広がります。

個人情報保護委員会は、個人情報を含むプロンプトを生成AIサービスに入力する場合、利用目的の範囲や入力情報が学習に使われるかを確認する必要があると注意喚起しています。会社のルールでは、この考え方を「入れてよい情報」と「入れる前に確認する情報」へ落とし込むのが現実的です。

出典: 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」

区分	例	運用ルール
入力可	公開情報、一般的な文章案	通常利用可
承認制	匿名化した顧客傾向、社内資料	管理者確認後に利用
入力禁止	個人情報、認証情報、営業秘密	AI入力不可

過去の情報漏えいリスクや入力時の考え方は、チャットGPT情報漏洩の実例まとめも参考になります。実例を先に見ておくと、社内ルールの説得力が上がります。

AIを一時停止する条件を社内ルールにする

生成AIリスク管理を会社で行うなら、使い始める条件だけでなく、止める条件も必要です。停止条件がないと、現場は「不安だけど使い続ける」か「念のため全部止める」の二択になりやすくなります。

NISTの生成AI Profileは、生成AIのリスクとしてデータプライバシー、情報完全性、情報セキュリティ、知的財産、過度な依存などを整理しています。日本企業の実務では、これを細かい専門用語のまま運用するより、漏えい疑い、規約変更、品質低下、顧客契約違反、過度な依存のような停止条件に翻訳すると使いやすくなります。

出典: NIST「AI RMF Generative AI Profile」(英語)

停止条件	一次判断	再開条件
漏えい疑い	IT・法務	影響範囲確認
規約変更	管理者	入力情報の再判定
誤回答増加	現場責任者	確認手順の追加
顧客契約	営業・法務	契約条件の確認

ルールの診断項目は、生成AI利用ルール診断の記事に近い考え方で見直せます。導入直後より、使い慣れた後の方がルールの抜けは見つかりやすくなります。

止まった時の代替手順を業務別に作る

代替AIを決める前に、AIなしで最低限戻せる人手復旧ラインを決めます。これは「AIを使わない方がよい」という意味ではありません。AIが止まっても顧客対応や納期を守るための最低ラインです。

たとえば顧客対応なら、AIチャットボットを止めた後に誰が一次返信を受けるのか。制作業務なら、AIで作った構成案やプロンプトがどこに残っているのか。調査業務なら、出典URLと判断メモが会社側に保存されているのか。ここが決まっていないと、代替AIへ切り替えても作業を再現できません。

業務	止まる影響	最低復旧ライン
顧客対応	返信遅延	人手一次返信
制作	納期遅れ	構成案を保存
調査	根拠不明	出典URLを保存
社内文書	検索停止	原本場所を明記

代替AIや主軸AIの考え方は、生成AIは会社でどれを選ぶべきかでも扱っています。ただし本記事の優先順位では、選定より先に復旧ラインと保存ルールを置きます。

モデル廃止・仕様変更に備えるチェック項目

AIモデル停止の代替策は、開発者だけの話ではありません。自社ツールや外部ベンダーのサービスがAI APIを使っている場合、モデル名、廃止予定、置換先、影響業務を確認する必要があります。

OpenAIのAPIドキュメントには、一般提供モデルの廃止通知期間やプレビュー系モデルの短期告知に関する説明があります。Anthropicも、モデルライフサイクルとしてActive、Legacy、Deprecated、Retiredを示し、Retiredになったモデルへのリクエストは失敗するという扱いです。自社ツールや外部連携では、この点を業務継続リスクとして棚卸しに入れてください。

出典: OpenAI API「Deprecations」(英語)

出典: Anthropic Docs「Model deprecations」(英語)

• 自社ツールで指定しているモデル名があるか
• 外部ベンダーがAI APIを使っているか
• 廃止予定や仕様変更の通知先が誰か
• 置換先をテストする担当者が誰か
• チャット型サービスでも出力品質や履歴保存が変わった時の確認手順があるか

クラウドAIへの依存をどこまで下げるかは、ローカルLLMは中小企業に必要かのような観点もあります。ただし、いきなりローカル化を目指すより、まずは使っているAIと業務影響を棚卸しする方が現実的です。

経営者が月1回見るべきAIリスク管理表

生成AIリスク管理を会社で続けるには、重い委員会より、月1回の短い確認表から始める方が続きます。確認するのは、利用状況、事故、コスト、規約、代替策の5つです。

確認項目	見る内容	判断
利用状況	部署と業務	増減を見る
事故	誤回答・漏えい疑い	停止要否
コスト	請求と上限	予算内か
規約	変更通知	入力基準更新
代替策	人手復旧ライン	実行可能か

この表は、AIを細かく管理するためではなく、事業に影響する変化を早めに見つけるためのものです。使う範囲が広がったら、禁止情報と承認制情報を見直す。誤回答が増えたら、人間確認を厚くする。規約変更があれば、入力基準を更新する。小さく回すだけで、停止時の混乱はかなり減ります。

よくある質問

生成AIの利用停止対策は、AIを疑うためのルールではありません。便利さを残したまま、止まった時の混乱を小さくするための業務設計です。まずは1枚の棚卸し表から始め、入力情報、停止条件、代替手順、保存先を月1回だけ見直してください。