結論: 共有IDはAI連携で追跡不能性が拡大するため、履歴棚卸し・オフボーディング手順・権限設計の3点が未整備なら個別ID化を検討する価値があります。
共有IDのリスクがAI時代に高まる理由
公的な情報セキュリティの脅威ランキングを見ると、「内部不正による情報漏えい等」や「不注意による情報漏えい等」が長年にわたって上位に並んでいます。いずれの脅威も10年近く連続して選出されているテーマです。共有IDは、この両方の脅威に静かに効いてくる古典的な論点と言えます。
ChatGPTの有料プランを1契約だけ取って所員数名で使い回す、生成AIのセッションを共用PCに開きっぱなしにする——コスト最適化として一定の合理性がある選択肢でした。月20ドル前後の有料プランを人数分契約すると、それなりの固定費が積み上がります。AIを試行段階で導入した事務所では、こうした節約方式が珍しくありませんでした。退職者が出た際、「共有IDのパスワードを変えるべきか、在籍者の混乱を避けて変えないでおくべきか」という判断に迷う場面が増えています。
ところがAIが顧客対応や申告書類のドラフト作成に踏み込み始めた現在、「誰がいつ何を入力したか」を追えない構造は、従来のSaaS共有以上に重い意味を持ち始めています。AIには会話履歴・カスタム指示・連携アプリ・メモリ機能といった「セッションをまたいで残るもの」が多く、これらが共有IDと組み合わさると、追跡不能性が広い面で表面化しやすくなります。
ID共用のリスクは、統計にもすでに表れています。IPA（情報処理推進機構）が2026年1月に公表した「情報セキュリティ10大脅威2026【組織編】」の解説書は、ID共用の問題点を次のように明記しています。「複数人で端末やアカウントを共用している場合、誰が不正アクセスしたのか確認できない」。対策として挙げられているのも「利用者IDの共用禁止等を検討する」という、共用そのものを見直す方向です（出典）。同じ2026年版では「AIの利用をめぐるサイバーリスク」が組織編の脅威として新規に3位で選出されており、ID管理の甘さとAI利用が別々の脅威ではなく重なり合う局面に入っていることがうかがえます。
警察庁が2025年3月に公表した「不正アクセス行為の発生状況」（令和6年分）でも、ID・パスワード管理の甘さが実際の被害につながっている様子が数字で確認できます。識別符号窃用型の不正アクセス検挙511件のうち、手口別では「パスワードの設定・管理の甘さにつけ込んで入手」が174件（34.1%）で最多、「識別符号を知り得る立場にあった元従業員や知人等による犯行」が107件（20.9%、前年比約1.57倍）で続いています（出典）。この統計は共有IDに限定した調査ではありませんが、「元従業員が識別符号を知り得る立場にあった」ことが手口として認識されている点は、共有IDの運用実態と重なります。
対策の実施状況にも目を向けておきたいところです。警察庁が2023年12月に公表した「不正アクセス行為対策等の実態調査」（社外接続時にID・パスワード認証を用いる179団体が対象）では、「IDを複数ユーザーで使わせない」という対策を実施していると回答した団体は54.7%にとどまっています。裏を返せば、調査対象の半数近くが、この基本的な対策を取れていないということです。
本稿は共有IDを使うこと自体を否定するのではなく、「どこにリスクが寄っているか」「どこから運用を切り替える価値があるか」を構造として整理することを目的としています。
共有IDで「誰が入力したか」が分からなくなる問題
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からの移行先3つの選択肢
共有IDからの移行は、いきなり全面切り替えではなく、複数の段階的な選択肢があります。それぞれの特性を整理しておくと、自所の規模に合った判断がしやすくなります。
| 選択肢 | 利用者単位ID | 監査ログ・管理機能 | データ学習除外 | 想定コスト感 |
|---|---|---|---|---|
| A.法人プラン一本化 | あり | あり（管理画面） | 公表されている | 個人プラン×人数より割安になる場合あり |
| B.個人プラン人数分 | あり | 弱い（個人設定のみ） | プラン次第 | 個人プラン×人数 |
| C.用途限定で共有継続 | なし | なし | 共有のまま | 既存契約のまま |
選択肢A: 法人プラン（Team / Enterprise）への一本化。法人向けプランは、利用者単位のアカウント発行、管理者ダッシュボード、データ学習除外を備えているとされています。月額は個人プランより高めですが、人数で割ると個人プランを人数分契約するより割安になる構造もあります。最新の料金・機能はベンダー公式ページで確認するのが前提です。
選択肢B: 個人プランを人数分契約。法人プランへの移行が早急に難しい場合、当面は個人プランを人数分契約して、共有運用だけ先に解消するという折衷案があります。管理機能は弱いままですが、「誰のIDか」だけは1対1にできます。
選択肢C: 用途を絞って共有を継続。顧客情報を入力しない・調査用途のみ、という業務範囲を限定した上で共有IDを継続する判断も、理屈上はあり得ます。ただし当初決めた用途の範囲が、運用しているうちに広がっていくことは起こり得ます。範囲が広がったこと自体に気づく仕組みがなければ、いつの間にか当初の前提が崩れます。運用ルールの明文化と定期点検をセットで設計しておきたいところです。
どれを選ぶかは、事務所の規模・取り扱う情報の機微度・予算によって変わってきます。一律に法人プラン移行を推奨するより、「いま自分たちが取っているリスクを把握した上で意識的に選ぶ」ことが、先に来る作業だと整理しておきたい場面です。
ChatGPTの個別ID移行にかかる費用はどれくらいか
共有IDから個別IDへの移行を検討し始めると、必ず出てくるのが「どれくらいの手間とコストがかかるのか」という疑問です。抽象的な検討のまま止まってしまう事務所も少なくないため、移行作業をタスクに分解して整理しておきます。
移行作業は大きく分けて、既存チャット履歴の棚卸しとエクスポート、個別アカウントの発行と初期設定、顧客情報の取り扱いルールの文書化、職員向けの操作研修とアナウンス、退職者オフボーディング手順の整備という5つの工程に分解できます。事務所の人数やAI利用の定着度によって前後しますが、目安として整理すると次のようになります。
所員5名程度でAI利用が所長中心の小規模な事務所であれば、履歴の棚卸しも限定的で済むため、上記5工程の合計で概ね2〜3人日程度が目安になります。所員10名前後で複数名がAIを日常的に併用している中規模な事務所になると、履歴の混在が進んでいる分だけ棚卸しに時間がかかり、5〜7人日程度を見ておくと現実的です。20名を超える事務所では、部署ごとにAI利用状況が異なることが多く、ヒアリングを含めて10人日を超えるケースも珍しくありません。
これを外部委託せず所内担当者が対応する前提で人件費換算すると、担当者の日給を2〜3万円程度と仮定した場合、小規模事務所で5〜9万円程度、中規模事務所で15〜21万円程度、20名超の事務所で30万円前後という試算になります。ここに、契約プランの切り替えに伴う月額費用の差分(個人プランを人数分契約する場合と法人プランへの一本化を比較した差額)が別途乗ってきます。
| 事務所規模 | 想定作業人日 | 人件費換算(目安) | 主な作業内容 |
|---|---|---|---|
| 5名程度 | 2〜3人日 | 5〜9万円 | 履歴棚卸し・アカウント発行・簡易研修 |
| 10名前後 | 5〜7人日 | 15〜21万円 | 上記に加えルール文書化・複数名研修 |
| 20名超 | 10人日以上 | 30万円〜 | 上記に加え部署別ヒアリング・段階移行 |
この試算はあくまで目安であり、既存のパスワード管理や情報セキュリティ規程の整備状況によって前後します。すでに退職者オフボーディング手順が文書化されている事務所であれば、上記の人日から1〜2人日程度は圧縮できる見込みです。逆に、共有IDを複数のAIツールで併用している場合は、棚卸し対象が増える分だけ人日が積み上がる点には注意が必要です。
小規模事務所での2〜3人日の内訳をさらに分解すると、チャット履歴の棚卸しとエクスポートに半日〜1日、個別アカウントの発行と初期設定に半日、顧客情報の取り扱いルールを1ページ程度の文書にまとめるのに半日、職員向けの説明会と質疑応答に半日、という配分になることが多く見られます。退職時のオフボーディング手順は、この移行作業の中で一緒に文書化しておくと、次に退職者が出たときに慌てずに済みます。
見落とされがちなのが、移行そのものの人日だけでなく、移行直後の生産性の一時的な低下です。個別ログインへの切り替え直後は、パスワード管理の手間が増えたと感じる職員も出てきます。この慣れの期間をあらかじめ移行計画に織り込んでおくと、切り替え直後の所内の不満を過度に大きく見積もらずに済みます。
この移行コストをどう評価するかは、情報漏えいや誤送信インシデントが実際に起きた場合の対応コストと比べてみると判断しやすくなります。顧客情報の誤入力や誤送信が起きたときの原因調査・顧客への説明・信用回復には、上記の移行人日を上回る工数がかかることが一般的です。移行コストだけを単体で見るのではなく、インシデント発生時の対応コストと比較する視点を持っておくと、経営判断としての優先順位がつけやすくなります。既存のAI契約やSaaS契約の更新タイミングに合わせて移行を計画すると、プラン切り替えに伴う追加コストを抑えやすくなる点も、あわせて確認しておきたいところです。
また、ChatGPTだけでなくClaudeやGeminiなど複数のAIツールを共有IDで併用している事務所では、移行対象がツールの数だけ増える点にも注意が必要です。1ツールあたりの人日試算をそのままツール数倍にするのではなく、履歴棚卸しやルール文書化といった共通工程はまとめて一度に進め、アカウント発行と研修だけをツールごとに行うようにすると、全体の人日を圧縮しやすくなります。
法人向けIDaaS(Okta/Azure AD/Google Workspace SSO)は検討に値するか
個別ID化を進める過程で、ChatGPTやClaudeなど個々のAIツールのアカウントだけでなく、事務所で使っているSaaS全体の認証をまとめて管理する法人向けID管理基盤(IDaaS: Identity as a Serviceと呼ばれる領域)を検討する事務所も出てきます。代表的なものに、Okta、Microsoft Entra ID(旧称Azure AD)、Google Workspaceのシングルサインオン機能があります。
これらのIDaaSを導入すると、AIツールを含む複数のSaaSへのログインを1つのIDに集約でき、退職時のオフボーディングも管理画面から一括で行えるようになります。共有IDの問題点として整理してきた「誰がいつ何を使ったか分からない」「退職時にIDを一つずつ止めて回る手間」を、AI以外のツールも含めて構造的に解消できる点が、AIツール単体の法人プラン移行との大きな違いです。
一方で、IDaaSの導入は、AIツール単体の法人プランへの移行に比べて規模の大きい取り組みになります。既存のSaaS一覧の棚卸し、シングルサインオン対応の可否確認、職員の認証方式の切り替えといった工程が追加で発生するため、小規模事務所がAI利用のためだけに導入するには、費用・工数ともに見合わない場合があります。
| 選択肢 | 対応範囲 | 導入期間の目安 | 士業事務所での適合ポイント |
|---|---|---|---|
| Okta | 全社SaaSの認証統合 | 数週間〜数ヶ月 | 複数拠点・SaaS契約数が多い事務所向け |
| Microsoft Entra ID | Microsoft 365中心の認証統合 | 既存契約があれば比較的短期 | すでにMicrosoft 365を導入済みの事務所 |
| Google Workspace SSO | Google Workspace中心の認証統合 | 既存契約があれば比較的短期 | すでにGoogle Workspaceを導入済みの事務所 |
事務所の規模感で言うと、SaaSの契約数が数個程度にとどまる小規模事務所であれば、AIツールごとの法人プランへの個別移行で当面は足りるという判断も十分に成立します。逆に、複数のSaaSを横断して認証管理を一本化したいという課題がAI導入をきっかけに顕在化したのであれば、既存のMicrosoft 365やGoogle Workspaceの契約状況を起点にIDaaSを検討する価値が出てきます。どちらを選ぶかは、AIの共有ID問題だけでなく、事務所全体の認証管理をどこまで一本化したいかという、一段上の判断軸で決める話になります。料金体系や対応機能は各社の公式サイトで随時更新されるため、最新情報は導入検討のタイミングで必ず確認することが前提です。
どの選択肢を取るにしても、移行の意思決定を誰が担うかをあらかじめ決めておくことも欠かせません。所長がすべてを抱え込むのではなく、日常的にAI利用の実態を把握している職員を移行担当として明確にしておくと、履歴の棚卸しや研修といった実務が滞りにくくなります。担当者を決めないまま検討だけを重ねると、法人プランへの一本化もIDaaS導入も、いつまでも「検討中」のまま止まりやすい点には注意が必要です。
すでにMicrosoft 365やGoogle Workspaceを契約している事務所であれば、シングルサインオン機能が標準機能または低価格の追加オプションとして含まれているケースもあります。新規にIDaaSを契約する前に、既存契約の管理者向けドキュメントを確認し、追加費用なしで使える機能が眠っていないかを見ておくと、無駄な追加投資を避けられます。
IDaaSの検討が現実的になるタイミングとしては、拠点が増えて認証管理の複雑さが増した、一般事務スタッフも含めてクラウドサービスの利用者数が急増した、といった事務所の成長局面が挙げられます。逆に、事務所規模がしばらく変わらない見込みであれば、AIツール単体の法人プラン移行にとどめておき、認証管理の一本化は次の成長局面まで持ち越すという判断も十分に合理的です。
個別ID化の前後で詰まりやすい3つの論点
切り替えを進めるときに、実際の現場で詰まりやすい論点を整理しておきます。
履歴の棚卸し。共有IDに蓄積されたチャット履歴は、誰の業務記録が混在しているかを棚卸しした上で、必要なものをエクスポート、不要なものは削除しておきたいところです。顧客情報を含むチャットは、移行後のアカウントに無条件で移すのではなく、「個別の業務メモに転記して履歴は削除」のように分離するほうが安全側に寄せられます。
顧客情報の取り扱いルール明文化。個別IDへ切り替えるタイミングは、「どの情報までAIに入力してよいか」「顧客名・マイナンバー・口座番号などのマスキングルール」を文書化する好機でもあります。人が変わっても運用が続く前提を作っておくと、退職・新規採用のたびにルールが揺らがなくなります。
退職時のオフボーディング手順。個別IDになると、退職時に該当IDを失効させれば済みます。法人プランの管理者画面から退職者の履歴をエクスポート・移管・削除できるかは、プランごとに仕様が異なります。契約前に管理者向けドキュメントで確認しておくと、退職者が出たときに慌てる場面を減らせます(退職時に棚卸しすべき対象を法人契約・個人契約・OAuth連携の3層に分けて整理した手順は、退職者アカウントとAIツール連携の見落としで扱っています)。
退職時のオフボーディングでは、AIアカウントの停止そのものだけでなく、そのアカウントに紐づいたカスタム指示・保存済みプロンプト・連携していたクラウドストレージのアクセス権も合わせて確認しておく必要があります。特に、顧問先ごとのひな形をカスタム指示やプロジェクト機能に保存している場合、退職者のアカウントを停止する前に、その内容を組織側のアカウントに複製しておかないと、蓄積してきたノウハウごと失われてしまいます。
個別ID化を検討すべきかの判断基準
共有IDの是非を「正解／不正解」で割り切ろうとすると、自所の規模に合わない選択を急ぐことになりがちです。代わりに、次の3点が自所でどこまで運用できているかで方向性を決めるのが扱いやすい進め方です。
- 利用ログ（誰が・いつ・どのAIに・何を入力したか）が、最低限の粒度で残っているか
- 退職者オフボーディング手順が、口頭ではなく文書として存在するか
- 顧客情報・機微情報を入力するときの権限設計（誰がアクセスできるか）が決まっているか
3点とも未整備なら、個別ID化を含む見直しを検討する余地があります。3点が運用に乗っているなら、共有IDのまま続けるのか、法人プランに乗せ替えるのかをコストベースで判断する次の段階に進めます。AIの利便性は確かに高いのですが、追跡可能性を最初から組み込んでおくほうが、後からの手戻りは小さくなります。
コストベースで判断する際は、上記で示した移行人日・費用の試算や、法人向けIDaaSまで踏み込むかどうかの比較を参照し、自所の規模に見合った投資かどうかを具体的な数字で確認しておくと、判断の根拠が曖昧なまま先送りになる事態を避けやすくなります。
押さえておきたいポイント
共有IDでChatGPTを使うこと自体は違法ですか。
共有ID利用そのものを直接禁じる法令はありません。ただし個人情報保護委員会が生成AIサービス利用時の注意喚起を出しており、「誰がどの情報を入力したか」を後追いできない運用は、この注意喚起の趣旨と整合させにくい構造にあります。違法性の判断は個別の契約・業務内容によるため、最新の公的情報や顧問の見解で確認するのが安全です。
個別ID化するとコストはどれくらい増えますか。
個人プランを人数分契約する場合は単純に人数倍のコストがかかりますが、法人プラン（Team / Enterprise）に一本化すると、月額単価は個人プランより高くても人数で割った場合に個人プラン×人数より割安になる場合があります。最新の料金体系はベンダー公式ページでの確認が前提です。
退職者が出たとき、共有IDのままだと何が問題ですか。
共有IDのパスワードを変えないと退職者が外部から引き続きアクセスできる状態が残り、変えると在籍者全員がログインし直す必要が出ます。個別IDであれば該当IDを失効させるだけで済むため、退職・交代のたびに運用が揺らぐ構造そのものを解消できます。
小規模事務所でも個別ID化は必要ですか。
規模の大小よりも、利用ログの有無・オフボーディング手順の文書化・顧客情報の権限設計という3点が自所でどこまで運用できているかで判断するのが扱いやすい進め方です。3点が未整備なら規模に関わらず見直しの余地があり、整備済みなら共有IDのまま続けるかコストベースで判断する段階に進めます。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ - 独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威2026」
https://www.ipa.go.jp/security/10threats/10threats2026.html - 警察庁「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」（令和7年3月13日公表、令和6年中データ）
https://www.npa.go.jp/bureau/cyber/pdf/R070313_access.pdf - 警察庁「不正アクセス行為対策等の実態調査」（令和5年12月公表、社外接続時にID・パスワード認証を用いる179団体対象）
https://www.npa.go.jp/bureau/cyber/pdf/R5countermeasures.pdf - 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（情報セキュリティマネジメントシステム — 認証・アクセス制御に関する一般的な国際規格）