ChatGPTを業務で使う前に決めておく社内ルール、最初の1枚に書くこと：つづきの技術室

ある日、営業部の誰かが「見積もりのお詫びメール、ChatGPTに書かせたら早かったですよ」と話しているのを情シスの方が耳にする。使っているのは個人で登録したアカウントで、貼り付けたのは取引先の担当者名と金額が入ったメールのやり取りでした。悪気はまったくありません。仕事を早く片づけたかっただけです。

生成AIの社内ルールづくりは、たいていこういう場面から始まります。そして多くの場合、最初に出てくる案は「当面、業務での利用は禁止」です。

私たちは業務システムを作り、保守する会社です。お客様のシステムにAIの機能を組み込む相談も受けますし、その前段で「社内ルールはどうしていますか」と伺うこともあります。ただ、禁止から始めたルールは、守られないまま形だけ残りやすいと私たちは考えています。この記事では、禁止の代わりに最初の1枚に何を書けばよいか、そして社内のシステムにAIをつなぐ段階になったら何を足すべきかを書きます。読んでいただきたいのは、ルールづくりを任された情シスや総務の方、それを承認する立場の方です。

禁止すると、使われ方が見えなくなる

IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入りました。2026年版で初めて選ばれた脅威です（IPA 情報セキュリティ10大脅威 2026）。解説書では、職場でAIサービスが用意されていないときに、従業員が個人で使っているAIサービスを業務に使ってしまう「シャドーAI」を、情報漏えいにつながるリスクとして挙げています。職場の側が、個人アカウントでの業務利用を把握できないこと自体もリスクだ、という書き方です。

冒頭の営業の方は、まさにこれです。そして「禁止」と通知したところで、この人がAIを使うのをやめるとは限りません。言わなくなるだけ、という可能性のほうが高いと思います。

IPAのサイトで公開されている「生成AIおよびAIエージェントを安全に活用するための手引書」（IPA産業サイバーセキュリティセンターの人材育成プログラムの成果物で、IPAの公式見解ではなく著者の見解とされています）も、同じ点を指摘しています。シャドーAIは多くの場合、悪意ではなく業務上の必要から生まれるので、禁止を先に出すだけでは申告されない利用が増え、実態がかえってつかめなくなる。対策の前提として、会社が安全性を確かめたAIを公式に用意することを挙げ、過度に厳しいルールは回避を招くので、禁止一辺倒ではなく代わりの手段とセットで決めるのが望ましいとしています（IPA 生成AIおよびAIエージェントを安全に活用するための手引書 2.3）。

ですから、ルールの最初の1枚は「何を禁止するか」より先に「会社として何を使ってよいことにするか」から書くことをおすすめします。

最初の1枚に書くこと

完璧なガイドラインを作ろうとすると、何か月もかかります。その間に現場の利用は勝手に進みます。上の手引書も、最低限の内容から始めて更新していくのが現実的だとしています。

そこで、A4で1〜2枚に収まる最初の版を考えてみました。項目は手引書の「ガイドラインに記載すべき事項」の表を参考にしつつ、社員数十人から数百人の会社で、まず決めないと困るものに絞っています。

使ってよいサービスと契約。会社で契約したサービス名を書き、個人で登録したアカウントでの業務利用はしないと決める
入れてよい情報と、入れてはいけない情報。次の節で書く3段階の線引きを載せる
出てきた答えの扱い。社外に出すもの、数字や固有名詞を含むものは、人が元の資料で確かめてから使う
迷ったときの相談先。部署名と担当者名まで書く
入れてはいけないものを入れてしまったときの連絡先。叱られる窓口ではなく、報告すれば一緒に対応してくれる窓口として書く
見直す時期。次にいつ改定するかを日付で書いておく

「使ってよいサービス」が空欄のままだと、残りの5つは全部「禁止」の言い換えになってしまいます。どのサービスを会社として契約するかは、ルールより先に決めておく必要があります。

もう一つ、ルールを配るときに一言添えてほしいのが、4と5の窓口のことです。冒頭の営業の方が、取引先の情報を貼り付けてしまったと後で気づいたとき、正直に言える相手がいるかどうか。そこで黙ってしまわれると、会社は事故があったことすら知らないままになります。

入れてよい情報を3段階で決める

ルールの中で、いちばん質問が集まるのがここです。「社内の資料は入れていいのか」「お客様の名前は」と聞かれて、毎回判断していたら担当者がもちません。

個人データについては、個人情報保護委員会が2023年6月に注意喚起を出しています。事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合は、その個人情報の利用目的の範囲内かを十分に確認すること。あらかじめ本人の同意を得ずに個人データを含むプロンプトを入力し、それが応答の出力以外の目的で扱われる場合は、個人情報保護法に違反する可能性がある。そのため、提供事業者がその個人データを機械学習に使わないことなどを十分に確認すること、という内容です（個人情報保護委員会生成AIサービスの利用に関する注意喚起等）。

政府の例も参考になります。デジタル庁の「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（DS-920、2026年6月12日改定版）には、各府省庁向けの利活用ルールのひな形が付いています。そこでは、不特定多数の人に提供され、利用規約への同意だけで使えるクラウド型の生成AIを業務で使う場合、原則として要機密情報は扱わないとしています。国外にサーバーがある場合には現地の法令が適用されうることにも触れています（デジタル庁 DS-920 別紙2）。民間企業がそのまま守る義務のある文書ではありませんが、線の引き方の見本としては使いやすいものです。

これらを踏まえて、私たちなら次のような3段階で書きます。

区分	例	入力
公開してよい情報	自社サイトに載っている文章、公開済みのプレスリリース、一般的な質問	会社で契約したサービスなら入力してよい
社内の情報	社内向けの手順書、会議のメモ、まだ公開していない企画の概要	入力が学習に使われない設定や契約になっていることを確かめたサービスだけ
個人情報・取引先の秘密	顧客名簿、問い合わせ内容、取引先の見積や契約、従業員の評価	原則入れない。業務上どうしても必要なら、相談先の許可を取る

真ん中の段で書いている「学習に使われない設定や契約」は、サービスによって、また同じサービスでも個人向けと法人向けのプランによって扱いが違います。ルールに書く前に、契約するサービスの利用規約とプライバシーポリシーを読み、どの設定で使うのかを決めておいてください。IPAの10大脅威の解説書も、経営者層の対策として、入力データを学習対象から外す設定の徹底と、契約時の約款の確認を挙げています。

一点、現場の方に伝えておきたいのは、名前を伏せれば安全とは限らないことです。手引書には「業界最大手A社を買収する件についてのプレスリリース案を書いて」という例が出てきます。社名を書かなくても、文脈そのものが機密です。こうした文脈に埋め込まれた機密を技術的に完全に見つけるのは極めて難しく、まずはルールと利用画面での注意喚起で、使う人の入力を整えることが中心になるとされています。だからこそ、表を配るだけでなく、こうした例を一つ添えて説明するほうが伝わります。

社内のシステムにAIをつなぐときは、決めることが変わる

ここからは、私たちの仕事にいちばん近い話です。

ChatGPTの画面で文章を作ってもらう段階から一歩進むと、「問い合わせ管理のシステムに、返信の下書きを作るボタンを付けたい」「社内の規程集を読み込ませて、質問に答える仕組みがほしい」という相談になります。業務システムからAIのサービスを呼び出す形です。

総務省と経済産業省の「AI事業者ガイドライン（第1.2版）」は、AIに関わる事業者を「AI開発者」「AI提供者」「AI利用者」に分けています。AIのサービスを事業で使う会社はAI利用者、AIを既存のシステムや業務の流れに組み込んだサービスとして提供する事業者がAI提供者です。対象には事業者の中の部門も含まれ、同じ会社が複数を兼ねることもある、とガイドラインは書いています（AI事業者ガイドライン第1.2版）。

この整理に当てはめると、自社の業務システムにAIを組み込んだ時点で、会社は「AIを使う側」だけでなく「AIを社員に提供する側」の役割も持つことになる、と私たちは考えています。最初の1枚のルールは社員がAIを使うときの決まりなので、それだけでは足りなくなります。システムを作る側の私たちが、つなぐ前にお客様と決めておきたいと考えているのは、次のようなことです。

まず、システムがAIのサービスに渡すデータの範囲です。画面に入力した文章だけを送るのか、顧客の情報や過去の履歴まで一緒に送るのか。社員が手で貼り付けるときは一回ごとに人が判断しますが、システムに組み込むと、決めた範囲のデータが毎回自動で送られます。上の3段階の表のどこまでを送ってよいかを、作る前に決めておく必要があります。

次に、利用料の上限です。AIのサービスは、使った量に応じて料金がかかるものが多くあります。手引書は、AIで起こりうる被害の一つに「過剰課金」を挙げ、盗まれた認証情報でクラウド上のAIが不正に使われた事例を紹介しています。原因として、APIキー（システムがAIのサービスに接続するための鍵）の管理不備、異常な利用量を見つける監視の欠如、そしてコストの上限を設定していなかったことが挙げられています。情報漏えいではなく請求書で被害に気づく、というのは、これまでの業務システムではあまりなかった種類の事故です。

それから、記録の残し方です。何を入力して、どんな答えが返ってきたのかを、どこに、どれくらいの期間残すのか。残さなければ後から何も調べられませんし、残しすぎれば、そのログ自体が個人情報や機密情報の置き場所になります。

最後に、やめるときのことです。手引書は、AIの仕組みを廃止するときには入力の履歴や会話の履歴、APIキーなどが特に残りやすいので注意するよう書いています。業務システムの保守を引き継ぐと、もう誰も使っていない外部サービスの鍵が設定ファイルに残っていることは珍しくありません。AIのサービスも、使い始めた日に「誰の名義で契約し、どの鍵をどこに設定したか」を一覧にしておけば、止めるときに困りません。退職者や前の委託先が残した鍵の探し方は、アカウント棚卸しの記事で書きました。

AI機能の付いた業務システムを保守する立場で見ると、AIのサービスは「毎月お金がかかり、こちらの都合と関係なく中身が変わる外部の部品」です。デジタル庁のガイドラインにも、生成AIのモデルが大きく更新されたときには、出力が期待した品質を満たしているかや、必要なコストの変化などを確かめてから提供するように、という記載があります。同じ質問に対する答え方が、ある月から変わることがある。この前提で、変わったときに誰が気づき、誰が確かめるのかまで決めておくのが、保守まで考えた組み込み方だと私たちは考えています。

見直す日を最初に決めておく

最初の1枚は、半年もすれば実態に合わなくなります。新しいサービスが出て、現場から「これも使いたい」という声が上がるからです。

手引書は、ガイドラインを最低でも年1回程度は改定することを基本とし、それが難しくても、新しい攻撃手法の顕在化、関連する法令や公的ガイドラインの改定、社内や業界での重大な事故といったタイミングで改定すると決めておくことを勧めています。普遍的な考え方を本体に書き、具体例は補足資料に分ける二段構えにすると、改定の手間を減らせる、とも書かれています。

私たちが付け加えるとすれば、改定のときに相談窓口に寄せられた質問を見返すことです。「これは入れていいですか」と何度も聞かれた情報があれば、それは表の書き方が曖昧だったということです。逆に誰からも質問が来ていないなら、ルールが読まれていないのかもしれません。

AIを業務システムに組み込む相談について

ディレクターズ・リベロでは、MVP開発・AI受託開発を4つのフェーズに分けて進めており、最初の1か月（リサーチ／要件定義）で「作るべきか」を判断します。ここで作らないという結論になることもあります。社内ルールの文面を作るサービスではありませんが、この記事の後半で挙げた「どのデータをAIに渡すか」「利用料や記録をどう管理するか」は、作り始める前に言葉にしておきたい要件です。まだ決まっていない段階からご相談ください。進め方は新規事業のMVP開発・プロトタイプ開発（AI受託開発）のページに書いています。

今ある業務システムにAIの機能を足したい、という場合はWeb受託開発、他社が作ったシステムで、どの外部サービスとつながっているのかも分からないという場合は、実行環境の調査から行うシステム引き継ぎ・保守もご覧ください。何から決めればいいか分からない段階でも構いません。info@directorz-libero.co.jp までご連絡ください。