ひとり情シスが社内AI利用ルールをゼロから作った話｜運用中の判定軸・申請フロー・月次レビュー

社内で生成AIを使わせてほしい、という声がうちで出はじめたとき、情シスは私ひとりでした。専任担当もいなければ社内の前例もなく、とりあえず「個人情報を入れない」「機密情報を入れない」「社外秘資料を入力しない」といった禁止事項を並べたルールをA4で配りました。まず情報漏えいを止めたかったからです。

ところが現場から返ってきたのは、「結局これは入れていいの？ダメなの？」「この資料は機密に入るの？」「文章を整えるだけなら大丈夫？」という確認ばかりでした。禁止事項は書いてあるのに、日々の業務で出てくるデータ——議事メモ、顧客名を伏せた問い合わせ、社内向けの説明資料——が、アウトなのかグレーなのか判断できなかったのです。

結果として、真面目な人ほど毎回確認してくる一方で、「よく分からないから個人アカウントで軽く使ってしまう」空気も出ました。悪意ではなく、ルールが”使う前提”になっていないから、聞くのも面倒だったのだと思います。禁止事項だけの文書は、現場にとって”守らされる資料”であって、”業務で使える資料”ではありませんでした。

このときに痛感したのは、生成AIのルールは「何を入れてはいけないか」だけでは足りないということです。現場が本当に欲しかったのは「どこまでなら使ってよいか」「迷ったときどう判断するか」という基準でした。そこで方針を変え、分厚い規程ではなく「現場がその場で判断できる基準」と「迷ったら相談できる入口」の2つを先に作ることにしました。この記事は、私が実際にその順番で作って今も運用しているルールの中身を、判断の理由ごと公開するものです。考え方の土台には、総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」のリスクベースアプローチ（リスクの大きさに応じて対策の程度を決める考え方）を参照しています。

まず決めたのは「ツール名」ではなく4つの判定軸

最初、私はツール名でホワイトリストを作ろうとしました。「ChatGPTは可、◯◯は不可」という形です。でもこれはすぐ破綻しました。同じChatGPTでも、個人アカウントで顧客情報を入れるのと、会社管理の法人環境で公開情報を整形するのとでは、リスクがまったく違うからです。ツール名だけでは、現場の「で、これは使っていいの？」に答えられませんでした。

そこで、ツールではなく次の4軸で判断する形に切り替えました。

この4軸にしてから、「このAIは使えるか」ではなく「この業務・このデータ・この出力なら使えるか」で答えられるようになり、現場からの相談がぐっと答えやすくなりました。

利用可否は「許可・条件付き許可・禁止」の3段階にした

可否を白黒で分けようとしたのですが、グレーゾーンを全部禁止にすると業務改善が止まり、全部許可にすると事故が怖い。そこで間に「条件付き許可」を置いて3段階にしました。

運用してみて分かったのは、相談のほとんどが真ん中の「条件付き許可」に集まるということでした。一番多かったのは、問い合わせ内容や社内メール、議事メモの要約・文章化です。「長い文章を短くしたいだけ」「お客様に送る前に言い回しを整えたいだけ」という、業務改善としてはごく自然な使い方なのですが、元データには顧客名・担当者名・製品名・障害内容・金額・社内の判断途中の内容がにじみ出ています。

特に印象に残っているのは、会議メモの要約です。本人はただのメモのつもりで持ってきたのですが、よく見ると「どの部署が反対しているか」「まだ決裁前の方針」「外部に出ていないスケジュール」まで書かれていました。名前や住所が入っていないから安全、というわけではないと痛感した一件です。だからこの層は、禁止でも許可でもなく「固有名詞を外せば要約・言い換えに使ってよい／そのまま貼るのは禁止」という条件付きにしました。現場にも一番説明しやすい線引きでした。

個人情報の入力は、ルール化する前に一度ヒヤリとした

一番ヒヤッとしたのは、営業が問い合わせ履歴をそのままAIに貼って、要約させようとしていた場面です。本人に悪気はまったくなく、「議事録っぽく整えたい」「長い問い合わせを短くしたい」という普通の使い方でした。ただ画面を見せてもらうと、そこには顧客の会社名、担当者名、問い合わせ内容、過去のやり取り、見積に近い内容まで入っていました。

本人は「パスワードや住所を入れているわけではないので大丈夫だと思った」と言っていて、そこが一番怖かったです。こちらが想定する”機密情報”と、現場がイメージする”入れてはいけない情報”に、大きなズレがありました。情シスから見れば、顧客名と問い合わせ内容がセットになった時点でかなり危ない。しかもそこには「どの製品で困っているか」「どの時期に何を検討しているか」という、外に出すべきでない文脈が含まれていました。送信前に隣で気づいて止められましたが、見ていなければそのまま貼っていたと思います。

法令面の裏付けとしては、個人情報保護委員会が、生成AIサービスに個人情報を含むプロンプトを入力する場合は利用目的の範囲内かを十分確認するよう注意喚起しています。また、本人同意なく個人データを入力し、それが応答結果の出力以外の目的で扱われる場合は個人情報保護法違反の可能性があるとして、提供者が当該データを機械学習に使わないこと等の確認を求めています。

この一件以降、私はルールの書き方を「氏名・住所・電話番号を入れない」から、現場の作業に近い言い方に直しました。現場は”個人情報”を狭く捉えますし、真面目に効率化しようとする人ほど「これくらいなら大丈夫だろう」と踏み抜くからです。

個人情報の入力ルール案（現場の作業に寄せた版）

・顧客名と相談内容をセットで入力しない
・問い合わせ履歴やメール本文をそのまま貼らない
・社内システムの画面をコピーして入れない
・要約に使う場合は、会社名・人名・金額・案件名を伏せてから使う
・判断に迷う場合は、AI利用相談フォームから申請する

部門ごとに追加ルールを足した（一番もめたのは人事）

全社共通ルールだけでは現場の判断には足りませんでした。営業は顧客情報、法務は契約情報、サポートは問い合わせ履歴と、部門ごとに危ないデータが違うからです。共通ルールの上に部門別の追加ルールを重ねる形にしています。

この中で一番調整に時間がかかったのは人事でした。発端は採用関係で、「応募者の職務経歴書を読ませて面接の質問を作れないか」「面接メモを入れて評価コメントを整えられないか」という相談です。業務としては非常に自然で、効率化したい気持ちはよく分かります。ただ、職務経歴書や面接メモには、氏名や連絡先だけでなく、職歴・年収希望・転職理由・家庭事情に近い話・面接官の主観コメントまで入りえます。

特に引っかかったのは「評価コメントを整える」という使い方でした。文章をきれいにするだけに見えて、実際には採否や評価に関わる情報です。AIが整えた言い回しをそのまま使うと、判断の根拠があいまいになり、本人が書いた判断なのかAIが整えた判断なのか分からなくなります。人事側からは「名前を消せば使えますよね？」とも言われましたが、名前を消しても経歴・部署・応募職種・面接内容で個人が特定できる場合があり、ここは何度か説明が必要でした。

最終的に、人事は履歴書・職務経歴書・面接メモ・評価コメントを原則そのまま入力禁止とし、使う場合は個人を特定できる情報を削って「質問例や評価観点のたたき台作成」に限定、採否判断や評価そのものはAIに任せず、出力は必ず人事担当者が確認して判断理由は人が持つ、という形にしました。振り返ると、人事でもめたというより「便利に使えそうな業務ほど、入力データが重い」というのが一番の発見でした。人事は”人そのもの”に近い情報が多く、部門別ルールの中では一番神経を使いました。

著作権は、細かい法解釈より「公開前の確認行動」に落とした

著作権については、法解釈をルールに細かく書くのをやめました。読んでも現場は動けないからです。文化庁が令和6年3月に「AIと著作権に関する考え方について」を取りまとめていますが、これは法的拘束力を持つものではなく、個別事案は最終的に個別判断が必要、という整理です。

そこでうちのルールでは、「AIで作った文章・画像・コード・スライドを社外公開する前に、既存著作物への類似・引用元・利用規約・商用利用条件・社内承認を確認する」という”行動”に落としました。特に広告・採用広報・製品ページ・セミナー資料は、広報か法務の確認を必須にしています。

例外申請は、メール運用で失敗してからワークフロー化した

現場からは必ず例外相談が出ます。「顧客名を伏せれば問い合わせ文を要約していいか」「無料の拡張機能を使っていいか」といった相談です。相談先がないと現場は自己判断してしまうので、例外申請は”抜け道”ではなく”安全に使う条件を確認する正式ルート”として用意しました。

ただ、これは最初メールで運用していて失敗しました。「◯◯さんがいつか許可してくれたはず」という記憶頼みになり、後から「これ誰がいつ承認したの？」を誰も答えられなくなったんです。そこで、申請→業務責任者承認→情シス確認の回付を、AgileWorksのワークフローに乗せました。口頭やメールと違い、決裁の証跡が自動で残るので、「誰が・いつ・何を承認したか」が後から確実に追えます。これが実際の承認回付・申請画面です（社名等はマスキング済み）。

申請フォームのひな型は、実際に運用しているものをそのまま載せておきます。

AI利用申請フォームのひな型

• 利用部署：
• 業務責任者：
• 利用したいAIサービス名：
• 利用環境：会社管理アカウント／個人アカウント／API／拡張機能／その他
• 入力するデータ：公開情報／社内情報／機密情報／個人情報／認証情報
• 入力データの加工方法：匿名化／マスキング／要約のみ／加工なし
• 出力の用途：社内利用／顧客送信／公開／重要判断の補助
• 人の確認者：
• ログ保存方法：保存先（AIサービス管理画面／社内ログ基盤／申請管理システム等）、保存期間、閲覧権限を記載
• 停止条件と連絡先：

ログは「全部保存」をやめて、リスク別に決めた

ログ保存は、最初かなり単純に「何かあったとき追えるよう、できるだけ全部残すのが安全だろう」と考えていました。考えを変えるきっかけは、テスト的にログ項目を洗い出したときです。「プロンプト全文を残せば後から確認しやすい」と思っていたのですが、そのプロンプトの中には顧客名・社内事情・問い合わせ内容、場合によっては個人情報に近いものが入りえます。その瞬間に、「ログは証跡であると同時に、漏えいしたら困るデータそのものだ」と感じました。守るために残したログ自体が、新しいリスクになるわけです。

そこで一律の長期保存はやめ、リスク別に分けました。通常利用のアクセスログ・利用実績は1年（年度単位の棚卸しや「この時期に誰がどのサービスを使っていたか」を追うには現実的な期間）。機密・個人情報に関わりそうな申請・承認記録、例外利用、インシデント対応の記録は3年（社内の文書管理規程やセキュリティ関連の保存期間に寄せました）。重大な事故や監査対応に関わるものは、社内規程や監査部門の判断に合わせて必要な期間だけ延長します。

残す中身も変えました。プロンプト全文は原則残さず、利用者・日時・利用サービス・利用目的・リスク区分・承認有無といった、監査に必要なメタ情報を中心に残す。内容まで残すのはインシデント調査など必要なケースに限定する。「全部保存」は一見安全そうですが、誰も見ない大量の機微情報を抱えることになり、情シスとしてはむしろ怖い運用でした。最終的には「監査で説明できるだけ残す。ただし残しすぎてログ自体がリスクにならないようにする」という方針に落ち着いています。

法人AIサービスは「公式仕様」と「自社契約」を分けて確認した

データ保護はプラン・契約・管理設定で変わるので、私は「公式が何と言っているか」と「自社の契約で実際どうなっているか」を分けて確認しました。たとえばOpenAIはビジネス向けに、API・ChatGPT Business・ChatGPT Enterpriseの顧客データを学習に使わない旨や、保存時・転送時の暗号化、SSO、ドメイン認証などを説明しています。MicrosoftはMicrosoft 365 CopilotとCopilot Chatのエンタープライズデータ保護を、DPAと製品条項に基づく制御、プロンプトと応答の保護、アクセス制御や保持ポリシーなどとして説明しています。

ただし、ログの保存場所・保存期間・DPAの適用範囲・管理者が閲覧できるログの範囲・監査ログ・リージョン・SLAなどは、契約内容や管理画面、社内規程によって変わります。そのため、ひな型では固定値を断定せず「自社で確認すべき項目」として整理しました。

月次レビューは、プリザンターの申請台帳を使って回している

ルールは一度作って終わりにできませんでした。新しいAIサービスが出るたびに確認が必要ですし、部門ごとの使い方も少しずつ違います。AI事業者ガイドライン（第1.2版）もLiving Documentとして適宜更新する考え方を示していますが、実務でも相談・ログ・ヒヤリハット・機能追加を見て毎月直しています。

このとき効いているのが、相談・申請の入口をプリザンターでフォーム化したことです。申請がそのままレコードとして台帳に貯まるので、「どの部門が、どのデータで、どう申請したか」を一覧で見返せます。月次レビューでは、この台帳から繰り返し出てくる例外を拾って、共通ルール側に格上げできないか検討しています。最初は部署ごとのExcelを毎月手で転記していたのですが、台帳化してからその手間がゼロになりました。

実際に月次で見ている項目はこの通りです。

最初に配る社内ルールの短文テンプレート

最後に、いま実際に初版として配っている短いルール文を載せておきます。長い規程よりも、まずこの1枚から始めるのがうちには合っていました。

社内生成AI利用ルール（初版）

当社では、業務効率化と品質向上のため、会社が承認した生成AIサービスを利用できます。ただし、顧客情報、社員情報、応募者情報、未公開資料、契約条件、認証情報、APIキー、秘密鍵、内部ネットワーク情報を、未承認のAIサービスへ入力してはいけません。

AIの出力は誤りを含む可能性があります。社外に送信する文書、契約・請求・返金・採用・人事評価・セキュリティ対応に関わる内容は、必ず担当者または承認者が確認してください。

判断に迷う場合、または個人情報・機密情報を扱う可能性がある場合は、AI利用相談フォームから申請してください。誤って禁止情報を入力した場合は、削除や隠蔽をせず、速やかに情シスへ連絡してください。

運用してみて変わったこと

運用してみて一番変わったのは、現場がいきなりAIを使うのではなく、「これは使っていいですか？」と相談してくるようになったことです。正直、ルールを作った翌日から劇的に変わったわけではありません。AI利用がきれいに整理されたというより、今まで見えなかった相談が情シス側に上がってくるようになった、という感覚に近いです。

ルールを作る前は、現場も遠慮していたのか、こっそり個人アカウントで試している空気がありました。「会社として使っていいか分からない。でも便利そうだから個人的に少しだけ」という感じです。こちらからすると、その”少しだけ”が一番怖かった。どんな情報を入れているのか、どのサービスを使っているのか、誰も把握できないからです。

負荷という意味では、最初はむしろ増えました。「顧客名を消せばよいのか」「社内資料は全部だめなのか」「無料版と会社契約版で扱いは違うのか」といった似た質問が何度も来ます。ただ、同じ質問が集まることで、現場がどこで迷っているのかが見えるようになり、FAQや具体例を足していけました。特に効果があったのは、「禁止」だけでなく「条件付きなら使える」と書いたことです。これがなかったら、現場はたぶん「結局AIは使うなということですね」と受け取っていたと思います。

相談の質も変わりました。運用前は「使っていいか悪いか」のざっくりした質問が多かったのですが、運用後は「この情報を伏せれば使えますか」「この業務は条件付き許可に入りますか」という具体的な相談になっていきました。小さいようで、これはかなり大きな変化です。現場が”AIを使うかどうか”ではなく”どうすれば安全に使えるか”を考えるようになったからです。

もちろん手間がなくなったわけではありません。新しいサービスが出るたびに確認が要りますし、ルールは一度作って終わりではなく、問い合わせを見ながら直し続ける運用になりました。それでも、こっそり使われるより相談が来るほうがずっといい。情シスとしては少し忙しくなりましたが、危ない使い方が表に出るようになっただけでも、ルールを作った意味はあったと感じています。最終的に、「AIを禁止するためのルール」ではなく「安心して相談できるためのルール」に近づけたことが、一番の手応えでした。