共有IDという古い論点が、AIで再点火しています
公的な情報セキュリティの脅威ランキングを見ると、「内部不正による情報漏えい等」や「不注意による情報漏えい等」が長年にわたって上位に並んでいます。いずれの脅威も10年近く連続して選出されているテーマです。共有IDは、この両方の脅威に静かに効いてくる古典的な論点と言えます。
ChatGPTの有料プランを1契約だけ取って所員数名で使い回す、生成AIのセッションを共用PCに開きっぱなしにする——コスト最適化として一定の合理性がある選択肢でした。月20ドル前後の有料プランを人数分契約すると、それなりの固定費が積み上がります。AIを試行段階で導入した事務所では、こうした節約方式が珍しくありませんでした。
ところがAIが顧客対応や申告書類のドラフト作成に踏み込み始めた現在、「誰がいつ何を入力したか」を追えない構造は、従来のSaaS共有以上に重い意味を持ち始めています。AIには会話履歴・カスタム指示・連携アプリ・メモリ機能といった「セッションをまたいで残るもの」が多く、これらが共有IDと組み合わさると、追跡不能性が広い面で表面化しやすくなります。
本稿は共有IDを使うこと自体を否定するのではなく、「どこにリスクが寄っているか」「どこから運用を切り替える価値があるか」を構造として整理することを目的としています。
監査追跡の不可能性が、AIで広範囲化します
IDと利用者が1対1で対応している前提は、情報セキュリティの基本原則として古くから扱われてきました。国際的な認証管理ガイドラインや情報セキュリティマネジメントの管理策でも、利用者単位での識別とアクセスログは基本要件として位置付けられています。共有IDの本質的な問題は、この監査追跡が成立しないことに尽きます。
共有IDがAIと組み合わさったときに、特に効いてくる構造を3点に分けて見ていきます。
履歴の混在。チャット履歴に職員A・B・所長の業務が時系列で流れ込み、後から「あの顧問先の論点を整理した会話はどれか」と探そうとしても、誰の作業だったかを判別できません。メモリ機能やカスタム指示を使っている場合、ある利用者の前提が別の利用者の出力に静かに影響することもあります。
退職・交代時の引き継ぎ困難。退職者が出たとき、共有IDのパスワードを変更すると残った全員がログインし直す必要が出てきます。変えないと退職者が外部から引き続きアクセス可能な状態が残ります。AIには長期の会話履歴という記憶領域があるぶん、退職者がアクセスし続ける状態の影響範囲は、SaaS一般より広くなる傾向があります。
インシデント時の責任所在の不在。顧客情報をAIに誤入力した、不適切な出力をそのまま顧客に送ってしまった——こうした事象が起きたとき、共有IDだと「誰がやったか」を技術的に特定できません。事務所内の口頭確認に頼ることになり、再発防止策の精度も落ちやすくなります。
3点ともAI以前から存在していた論点ですが、AI時代は「履歴・メモリ・連携」という長期に残る要素が増えたぶん、影響が広い面に拡散していると整理しておきたい場面です。
プラン差で「学習除外」「監査ログ」の有無が分かれます
AIツールには、個人向けと法人向けで管理機能の差が大きく開いている、という構造があります。ここを理解しないまま共有IDを続けると、契約上の盲点が積み上がっていきます。
個人向けの有料プランと法人向けのTeam / Enterpriseプランでは、入力データが学習に使われるかどうかの初期設定、データ保持期間の制御、監査ログの取得可否がそれぞれ異なります。共有IDの多くは個人プランで運用されているため、法人プランで提供される「学習除外」「保持期間の制御」「管理者ダッシュボード」「監査ログ」といった機能が、そもそも選択肢として存在しない状態に置かれているケースが少なくありません。
加えて、最近のAIツールはカレンダー・メール・ストレージとの連携機能や、長期メモリ、カスタム指示（GPTs / Projects等）を提供しています。共有IDでこれらを使うと、ある利用者が設定した連携や前提が、別の利用者の出力に影響する場合があります。意図しない情報がAI側で「事務所の共通前提」として保持され続ける構造が生まれやすくなります。
公的機関からも、生成AIサービスの利用にあたっては「入力する情報の範囲」と「サービス提供者側でのデータ取り扱い」を理解した上で利用するよう注意喚起が出されています。最新の方針は公的機関の公式情報を確認のことになりますが、共有IDは「誰がどの情報を入力したか」を後追いできない運用を前提に置く形態であり、こうした注意喚起の趣旨と整合させるには工夫が要ります。
移行先は「法人プラン一本化」だけではありません
共有IDからの移行は、いきなり全面切り替えではなく、複数の段階的な選択肢があります。それぞれの特性を整理しておくと、自所の規模に合った判断がしやすくなります。
| 選択肢 | 利用者単位ID | 監査ログ・管理機能 | データ学習除外 | 想定コスト感 |
|---|---|---|---|---|
| A. 法人プラン一本化 | あり | あり（管理画面） | 公表されている | 個人プラン×人数より割安になる場合あり |
| B. 個人プラン人数分 | あり | 弱い（個人設定のみ） | プラン次第 | 個人プラン×人数 |
| C. 用途限定で共有継続 | なし | なし | 共有のまま | 既存契約のまま |
選択肢A: 法人プラン（Team / Enterprise）への一本化。法人向けプランは、利用者単位のアカウント発行、管理者ダッシュボード、データ学習除外を備えているとされています。月額は個人プランより高めですが、人数で割ると個人プランを人数分契約するより割安になる構造もあります。最新の料金・機能はベンダー公式ページで確認するのが前提です。
選択肢B: 個人プランを人数分契約。法人プランへの移行が早急に難しい場合、当面は個人プランを人数分契約して、共有運用だけ先に解消するという折衷案があります。管理機能は弱いままですが、「誰のIDか」だけは1対1にできます。
選択肢C: 用途を絞って共有を継続。顧客情報を入力しない・調査用途のみ、という業務範囲を限定した上で共有IDを継続する判断も、理屈上はあり得ます。ただし「使っているうちに用途が広がる」のは現場でよく観察される現象なので、運用ルールの明文化と定期点検をセットで設計しておきたいところです。
どれを選ぶかは、事務所の規模・取り扱う情報の機微度・予算によって変わってきます。一律に法人プラン移行を推奨するより、「いま自分たちが取っているリスクを把握した上で意識的に選ぶ」ことが、先に来る作業だと整理しておきたい場面です。
個別ID化の前後で詰まりやすい3つの論点
切り替えを進めるときに、実際の現場で詰まりやすい論点を整理しておきます。
履歴の棚卸し。共有IDに蓄積されたチャット履歴は、誰の業務記録が混在しているかを棚卸しした上で、必要なものをエクスポート、不要なものは削除しておきたいところです。顧客情報を含むチャットは、移行後のアカウントに無条件で移すのではなく、「個別の業務メモに転記して履歴は削除」のように分離するほうが安全側に寄せられます。
顧客情報の取り扱いルール明文化。個別IDへ切り替えるタイミングは、「どの情報までAIに入力してよいか」「顧客名・マイナンバー・口座番号などのマスキングルール」を文書化する好機でもあります。人が変わっても運用が続く前提を作っておくと、退職・新規採用のたびにルールが揺らがなくなります。
退職時のオフボーディング手順。個別IDになると、退職時に該当IDを失効させれば済みます。法人プランの管理者画面から退職者の履歴をエクスポート・移管・削除できるかは、プランごとに仕様が異なります。契約前に管理者向けドキュメントで確認しておくと、退職者が出たときに慌てる場面を減らせます。
設計の手がかり
共有IDの是非を「正解／不正解」で割り切ろうとすると、自所の規模に合わない選択を急ぐことになりがちです。代わりに、次の3点が自所でどこまで運用できているかで方向性を決めるのが扱いやすい進め方です。
- 利用ログ（誰が・いつ・どのAIに・何を入力したか）が、最低限の粒度で残っているか
- 退職者オフボーディング手順が、口頭ではなく文書として存在するか
- 顧客情報・機微情報を入力するときの権限設計（誰がアクセスできるか）が決まっているか
3点とも未整備なら、個別ID化を含む見直しを検討する余地があります。3点が運用に乗っているなら、共有IDのまま続けるのか、法人プランに乗せ替えるのかをコストベースで判断する次の段階に進めます。AIの利便性は確かに高いのですが、追跡可能性を最初から組み込んでおくほうが、後からの手戻りは小さくなります。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ - 独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2025」
https://www.ipa.go.jp/security/10threats/10threats2025.html - NIST SP 800-53 Rev.5 アクセス制御ファミリ（AC-2 Account Management 等）
https://csrc.nist.gov/projects/risk-management/sp800-53-controls/release-search - ISO/IEC 27001:2022（情報セキュリティマネジメントシステム — 認証・アクセス制御に関する一般的な国際規格）