AIツールを社内利用してよいか判断する基準｜情シス向け実務チェックリスト

現場から最初に来たのは「ChatGPTを使ってもいいですか」という相談でした。私も最初は少し雑に考えていて、「会社契約のものならOK、個人アカウントの無料版はNG」くらいの判断で済むと思っていました。ところが実際に話を聞くと、同じChatGPTでも使い方がまったく違ったのです。

ある人は、社内向けのお知らせ文をやわらかく書き直したいだけでした。社名や個人名、未公開情報を入れなければ、かなり安全に使える部類です。一方で別の人は、問い合わせ履歴をそのまま貼って要約したいと言っていました。そこには顧客名、担当者名、過去の対応内容、製品名、ちょっとしたトラブルの経緯まで入る可能性があります。この2つが、同じ「ChatGPTを使いたいです」という相談として上がってきました。

そのとき痛感したのが、ツール名だけで許可・禁止を決めるのは無理だ、ということです。ChatGPTだから危ない／安全という話ではなく、結局は誰が、どのデータを、何の目的で入れるかでリスクが変わります。印象に残っているのは、要約したいと言った本人が「要約だけなので大丈夫だと思っていました」と話していたことです。現場からすればAIに判断させるわけではなく、文章を短くするだけ。でも情シス側から見ると、要約のために貼る元データのほうが問題でした。この記事は、その一言をきっかけに、私が実際に作って運用しているAIツールの社内利用基準を、判断の理由ごと公開するものです。考え方の土台には、総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」のリスクベースアプローチ（リスクの大きさに応じて対策の程度を決める考え方）を置いています。

ツール名ではなく「利用シーン」で4段階に判定する

あの一件のあと、私は聞き方を変えました。「どのAIツールを使いますか」だけでなく、「誰が使いますか」「何の業務で使いますか」「入力する情報に顧客名・個人名・社外秘情報は含まれますか」「出力結果は社外に出しますか」「そのAIにファイルをアップロードしますか」まで確認するようにしたのです。地味ですが、ここを聞かないと判断を間違えます。同じ翻訳でも公開済みの製品説明を英訳するのと未発表資料や契約書を翻訳するのでは意味が違いますし、同じ議事録作成でも社内の雑談メモを整えるのと人事評価や交渉メモを入れるのでは危険度が違います。

最初は「ツール単位で一覧表を作れば運用できる」と思っていました。でも実際には、ツール名だけの表はあまり役に立ちませんでした。必要だったのは「このツールはOK」ではなく「このツールを、このデータで、この目的に使うならOK」という書き方です。そこで可否は二択ではなく、次の4段階で判定するようにしました。

相談を受けたら、利用目的が業務上必要か、入力する情報は公開情報・社内一般情報・機密・個人情報・認証情報のどれか、会社管理アカウントで使えるか、SSO・MFA・退職者停止・監査ログを確認できるか、保存・学習利用・削除・サブプロセッサを確認できるか、出力を社外送信や契約・人事判断に使わないか、事故時の停止手順が決まっているか、という順で確認します。途中で引っかかっても全面禁止にせず、公開情報のみ・会社管理アカウントのみ・ファイル添付なし・PoC限定といった条件に切り替えます。確認できない項目は推測で埋めず「［要確認：対象プランの管理機能／自社で確認］」と残します。AIツールはプラン改定や機能追加が早いので、過去に確認した内容をそのまま使い続けないことも大事です。

入力してよい情報・入れてはいけない情報

聞き方を変えて一番効いたのは、入力データの線引きを先に決めたことでした。個人情報保護法では個人情報や要配慮個人情報が定義されており、要配慮個人情報には人種、信条、社会的身分、病歴、犯罪の経歴など、本人への不当な差別や不利益につながらないよう特に配慮を要する情報が含まれます。現場が「これは入れていいのか」を迷わないよう、禁止だけでなく代替入力例まで決めておきます。

最初のChatGPTの相談で問題だったのは、まさにこの「要約のために貼る元データ」でした。問い合わせ履歴は、顧客名と相談内容がセットになった時点でかなり危ない。だから「顧客名と相談内容をセットで入れない」「問い合わせ履歴をそのまま貼らない」「要約は会社名・人名・金額・案件名を伏せてから」というように、現場の作業に近い言い方でルール化しています。

無料版と法人版は「別物」として評価する

無料版・個人版のAIツールで一番引っかかったのは、退職者や異動者の管理が会社側でできないことでした。きっかけは、ある現場から「無料で使えるAIツールを業務の文章作成に使ってもいいですか」と相談があったときです。最初は入力情報に顧客情報や個人情報が含まれるかを見れば判断できると思っていました。でも話を聞くと、利用者は個人のメールアドレスでアカウントを作り、そのツール上に入力履歴や生成した文章が残る想定でした。その瞬間に「これは会社として管理できない」と感じました。

私はAgileWorksやプリザンターを運用しているので、退職者・異動者のアカウントを止める、所属グループを外す、誰がどの申請を見られるか確認する、というのは当たり前の感覚です。退職者が出ればSSOやユーザー改定、グループ連携で権限を落とす。部署が変われば閲覧できるサイトや申請箱の権限を見直す。少なくとも「会社側で止められる状態」にしておくのが前提です。ところが個人版のAIツールはそこがまったく違いました。会社が契約しているわけではないので管理者画面がなく、誰が使っているかも一覧で見えず、退職時にアカウントを停止することもできず、過去に何を入力したかも会社側で確認できません。

本人が悪いことをしようとしているわけではありません。むしろ「無料で便利だから、ちょっと使ってみたい」という自然な流れです。ただ情シス側から見ると、その”ちょっと”がかなり怖かった。問い合わせメールのたたき台、社内向け説明文、申請書の下書き、議事メモの要約。ひとつひとつは重大な機密に見えなくても、積み重なると会社の業務内容や社内事情がかなり見えてしまいます。退職後にその個人アカウントが残っていても会社側からは消せませんし、本人がログアウトしたか履歴を削除したかも分かりません。会社のデータを使っているのに、最後の管理権限が会社にない状態になります。この違和感が大きかったので、そのケースはそのまま利用許可にはしませんでした。

法人版であっても、SSO、SCIM、監査ログ、データ保持期間、DPA、SLA、IP制限、データ保管地域などが標準搭載とは限りません。プランや契約条件で変わるため、本文では断定せず「［要確認：対象プランの正式名称・管理機能・契約条件／自社で確認］」として確認欄を残します。見るポイントも、有名なツールかどうかではなく、次の観点に変えました。

この経験で、AIツールも結局は業務システムと同じだと思うようになりました。便利かどうかだけでなく、「辞めた人を止められるか」「誰が何を見られるか」「会社として後から説明できるか」を見ないといけない。AgileWorksやプリザンターで当たり前に気にしていることを、AIツールでも同じように見る。この感覚がないまま個人版を業務利用に広げると、気づいたときには会社の外側に小さな業務データ置き場がいくつもできてしまいます。そこが一番ヒヤッとしたところでした。

管理機能とログは「事故調査に使えるか」で見る

ログまわりで実際に導入を見送ったのは、会議の文字起こし・要約系のAIツールでした。現場からは「会議を録音して、自動で議事録を作れるので使いたい」という相談で、業務改善効果もありそうでした。定例会議や打ち合わせが多い部署ほど、議事メモ作成の手間は大きいので、使いたくなる気持ちはよく分かります。ただ確認していくと、ログで引っかかりました。誰がいつどの会議で使ったのか、録音・文字起こしデータがどこに保存されるのか、管理者側で利用履歴を一覧で確認できるのか、CSVなどでエクスポートできるのか、退職者・異動者の履歴を後から追えるのか、何かあったときに「この会議データがAIに渡ったか」を調べられるのか。当時見たツールは管理者向けログがかなり弱く、画面上で利用状況をざっくり見る程度で、エクスポートもできず、保存期間もこちらで決められず、監査用に必要な形で出せませんでした。その時点で、導入はかなり厳しいと感じました。

JP1で運用監視をしている感覚があると、障害や事故が起きたときに「後から追えるか」をどうしても見ます。システムが止まったときも連携処理が失敗したときも、まずログを見ます。何時何分に何が起きたのか、どのジョブが動いたのか、どこで失敗したのか。それが分からないと原因調査も報告もできません。AIツールも同じで、便利かどうかだけでは判断できませんでした。むしろAIの場合は入力される情報が業務データそのものなので、何かあったときに追えないほうが怖い。会議系AIは、会話の中に社内の未決事項、取引先名、個人名、トラブル対応、まだ外に出せないスケジュールが自然に入ります。本人たちは普通の打ち合わせをしているだけですが、録音・文字起こしされると、かなり濃い業務情報になります。そこでログが取れないと、「誰が使ったか分からない」「どの会議が対象か分からない」「データが残っているのか消えているのか分からない」という状態になり、情シスとしては受けにくい。結局そのツールは、機能が悪いからではなく、事故調査に耐えられるログが取れなかったから見送りました。

ふだんJP1で見ている監視・ログ管理の画面がこれです。何時に何が起きてどこで失敗したかを追える状態が当たり前なので、AIツールにも同じ目線で「後から説明できるか」を求めるようになりました。

監査ログは「ある／ない」だけでは不十分です。情シスが確認すべきなのは、事故や問い合わせが起きたときに、誰が、いつ、どの機能を使い、どの設定を変更し、どの外部連携を追加したかを説明できるかです。ログ保持期間、プロンプト本文の保存有無、エクスポート方法、管理者が閲覧できる範囲は、サービスや契約プランで変わります。だから申請書には、確認すべき項目と未確認時の扱いを分けて残します。

逆に、導入候補として残したツールは、管理者画面で利用者一覧や利用履歴を確認できるもの、ログをCSVで出せるもの、少なくともユーザー・日時・操作種別・利用サービス・ファイルアップロード有無が追えるものに限定しました。クラウドサービスのセキュリティ評価制度としては、政府情報システム向けにISMAPがあり、政府機関等がクラウドサービスを調達する際のセキュリティ・信頼性を評価する制度として運用されています。ただしISMAP登録の有無だけで自社のAI利用が安全と確定するわけではなく、自社の利用データ・契約・運用ルールに合うかは別途確認が必要です。

このとき思ったのは、AIツールの評価では「何ができるか」よりも「何かあったときに説明できるか」がかなり大事だということです。JP1で監視していると、ログがないシステムは本当に怖い。普段は問題なく動いているように見えても、事故が起きた瞬間に何も追えなくなります。AIツールも同じで、ログが取れないものは便利でも業務利用には乗せにくい。「使えるか」ではなく「事故調査に耐えられるか」で見るようになったのは、運用監視をやっている感覚がかなり影響していると思います。

利用部門へ返す「条件付き許可」の文面

情シスの回答は、禁止事項だけでなく、現場が守れる条件に落とし込むことが大切です。次の文面は、そのまま利用部門への返信や申請承認コメントに使えます。

ご相談のAIツールについて、現時点では以下の条件で利用を許可します。

利用目的：公開情報をもとにした文章下書き、要約、表現調整に限定します。
入力禁止：顧客名、個人情報、契約金額、未公開資料、APIキー、パスワードは入力しないでください。
利用者：申請済みメンバーのみ利用できます。共有アカウントは禁止します。
出力確認：社外へ送る文章、契約判断、顧客回答に使う場合は、担当者が内容を確認してください。
ファイル添付：社内資料、顧客資料、議事録ファイルの添付は、別途承認があるまで禁止します。
範囲変更：API利用、外部サービス連携、社内データ連携を行う場合は、再申請してください。

社内利用申請フォームに入れる項目

AIツール利用を場当たり的に判断しないために、申請フォームでは次の項目を必須にします。私はこの申請をプリザンターでフォーム化していて、紙やメールだと「誰がどのデータまで許可したか」が後で追えなくなるため、レコードとして残るようにしています。

・ツール名、提供会社、利用予定プラン、契約主体
・利用部門、利用者数、利用期間、業務目的
・入力予定データの区分
・出力の用途、社外送信の有無、人による確認方法
・SSO、MFA、退職者停止、権限管理の可否
・ログ取得、ログ保持期間、閲覧権限、エクスポート可否
・入力データの保存、学習利用、削除、保管地域、サブプロセッサ
・外部連携、API利用、ファイル添付、社内データ連携の有無
・費用、契約更新日、解約時のデータ削除方法
・例外利用時の承認者と問い合わせ先

最終チェックリスト

AIツールの社内利用判断で大切なのは、流行しているツールを早く許可することではありません。「ChatGPTを使っていいですか」という一言の裏にある業務内容と入力データを確認し、会社として説明できる範囲を決め、ログと契約を確認し、現場が迷わず使える条件に翻訳することです。禁止だけではシャドーIT化しやすく、無条件許可では事故時に説明できません。情シスは、AI活用を止める役割ではなく、使ってよい範囲を具体化する役割を担います。