増えたAI契約の整理は統合より棚卸しから

「気づいたら、経理も営業も開発も、それぞれ別のAIサービスを契約していた」——中小企業の現場で、ここ1〜2年でよく聞くようになった話です。部署ごとの小さな契約は1件あたり月数千円から数万円で、稟議を通さずに部門の裁量で買えてしまいます。だから増えます。そして増えたことに誰も気づかないまま、退職者のアカウントが生き続けていたり、同じ機能に二重で払っていたりします。

この状態を前にすると「全社で1つのサービスに統合しよう」と言いたくなります。ですが、いきなり統合に動くと、現場の業務が止まるか、反発で骨抜きになるかのどちらかになりがちです。先にやるべきは棚卸しです。この記事では、棚卸しで何を記録するか、何を統合して何を残すか、そしてアカウント管理と契約条項で詰まりやすい箇所を、順に整理します。

なぜ部署ごとに増えるのか — 現場の判断は間違っていない

AIサービスの契約が分散する原因は、担当者の勝手な行動ではなく、仕組みのほうにあります。

• 単価が低い：1アカウント月額数千円なら、部門の消耗品費や交際費の枠で決済できてしまう
• 導入が速い：クレジットカードとメールアドレスがあれば当日から使える
• 業務が違う：議事録の文字起こし、翻訳、画像生成、コード補助は、それぞれ得意なサービスが異なる
• 全社標準が遅い：情報システム部門が検討している間に、現場は目の前の締め切りに追われている

いわゆるシャドーIT（情報システム部門が把握していない、現場が独自に導入したツールやサービス）ですが、AIの場合は「業務に効いているシャドーIT」であることが多いのが厄介な点です。一律に禁止すると生産性が下がり、放置すると情報漏えいと無駄なコストが積み上がります。整理の目的は、使わせないことではなく、把握した上で続けるか替えるかを決められる状態にすることです。

棚卸しシートに書く7項目

最初の作業は、全部署に対する調査です。メールで「使っているAIサービスを教えてください」と聞くだけでは、半分も出てきません。経理のクレジットカード明細、SaaS購買の請求書、ブラウザのログ（取得している場合）を突き合わせる必要があります。そのうえで、1サービスにつき次の項目を埋めます。

この7項目のうち、多くの会社で空欄のまま残るのが「投入しているデータ」と「学習利用の設定」です。ここが埋まらないサービスは、金額の大小にかかわらず優先的に確認してください。何を入れてよくて何を入れてはいけないかの線引きそのものについては、AIに渡せない入力を止める手順で扱った考え方が土台になります。

統合するもの、残すもの、止めるもの

棚卸しが終わると、どうしても「一本化しよう」という方向に話が流れます。ですが、AIサービスは用途によって得意分野が分かれるため、全部を1社にまとめると、どこかの部署の品質が確実に落ちます。次の3分類で判断するのが現実的です。

「残す」に分類したものを無理に統合しないことが、この整理を現場に受け入れてもらう鍵です。全部取り上げられると身構えている部署に対して、「専門用途は認める。ただし会社として把握する」と伝えられれば、協力が得やすくなります。

なお、統合によってコストが下がると期待しすぎないでください。企業向けプランは1人あたり単価が個人プランより高いことが珍しくありません。削減効果が出るのは主に休眠アカウントの整理と重複契約の解消からで、API（プログラムから呼び出す仕組み）の従量課金分は別の設計が必要です。この部分はLLMの料金は「安いモデルに替える」では下がらないで整理した、呼び出し回数と文脈量の観点で見るほうが実態に合います。

アカウント管理で詰まる4箇所

契約をまとめた後、実装段階で手が止まりやすいのは次の4つです。

1. SSOが上位プラン限定になっている

SSO（シングルサインオン。社内の1つのIDで複数サービスにログインできる仕組み）に対応していても、企業向けの上位プランでないと使えないサービスが多くあります。SSOを前提に設計を進めた後で「そのプランでは不可」と分かると、料金計画をやり直すことになります。見積もり段階でプラン名まで確認してください。

2. 退職者のアカウントが消えない

SCIM（アカウントの作成・停止を人事システムやIDの管理基盤から自動で反映させる規格）に未対応のサービスでは、退職者のアカウント停止が手作業になります。手作業は必ず漏れます。SCIM非対応のサービスを残す場合は、「毎月1日に全サービスのユーザー一覧を出力して人事データと突き合わせる」といった、人の作業としての手順を明文化しておく必要があります。

3. 個人のメールアドレスで契約されている

個人のGoogleアカウントやフリーメールで作られたテナント（契約単位の環境）は、会社側から中身を確認できません。移行時にチャット履歴や保存したプロンプトが引き継げず、現場が移行を嫌がる原因になります。会社ドメインのメールアドレスで作り直し、必要なものだけエクスポートして移す段取りを先に決めておきます。

4. APIキーの持ち主が分からない

画面から使うアカウントだけでなく、開発や自動化のために発行されたAPIキー（プログラムから接続するための認証文字列）も棚卸しの対象です。発行者が退職していて誰も更新できない、どのシステムが使っているか分からず止められない、という状態は実務でよく起きます。キーごとに「発行者・用途・接続元システム・有効期限」を記録し、期限のないキーには見直し日を設定してください。

契約条項で確認する5点

金額とプランだけ見て契約を更新すると、後から問題になりやすい箇所があります。少なくとも次の5点は、更新時に確認しておきたい項目です。

1. 入力データの学習利用：既定で学習に使われるか、オプトアウト（利用しない設定）が可能か。無料プランと有料プランで扱いが違うことが多い
2. データの保存場所：どの国・地域のサーバーに保存されるか。顧客との契約で国内保管を求められている場合は必須の確認項目
3. 再委託先（サブプロセッサ）：そのサービスがさらに別の事業者のモデルや基盤を使っていないか。個人データを扱う場合、委託先の監督義務との関係で確認が必要になります
4. 解約時のデータ取り扱い：解約後に何日でデータが削除されるか、エクスポートの手段があるか
5. 自動更新と解約予告：年間契約で解約予告が30日前などと定められていると、気づいた時には1年延長されている

個人情報を含むデータを外部サービスに入れる場合は、個人情報の保護に関する法律（個人情報保護法）における委託先の監督や第三者提供の考え方と照らす必要があります。また、国内では関係省庁がまとめたAI事業者ガイドラインがあり、事業者が自主的に確認すべき観点が整理されています。自社の業種や扱うデータによって必要な対応は変わるため、判断に迷う部分は顧問弁護士や社内の法務担当に確認してください。

整理を一度きりで終わらせない仕組み

棚卸しは、やった直後は正しく、半年後には古くなります。続ける仕組みを同時に作っておかないと、1年後に同じ作業を繰り返すことになります。最低限、次の3つを決めておきます。

• 台帳の置き場所と更新担当：表計算ソフト1枚で十分です。重要なのは、誰が更新するかを名前で決めること
• 新規導入の申請ルート：「申請は面倒」と思われた瞬間に迂回されます。扱うデータが社外秘を含まない場合は簡易承認にするなど、重さを使い分けてください
• 年1回の見直し日：契約更新月が分散しているなら、期初など決まった時期に一斉点検する日を決めます

たとえば次のような運用が考えられます。四半期ごとに経理がクレジットカード明細から「AI」「GPT」などの文字列を含む決済を抽出し、台帳と突き合わせる。差分があれば該当部署に用途を確認する——この程度でも、把握できていない契約が静かに増え続ける状態は防げます。

台帳が整ってくると、「この業務は外部サービスの組み合わせより、自社の業務システムに組み込んだほうが安く確実ではないか」という判断ができるようになります。その段階で初めて、社内開発や受託開発の検討が意味を持ちます。判断材料の整え方はAI導入の稟議を通す──経営層から必ず出る5つの質問で挙げた質問の型が参考になります。

まとめ

部署ごとに増えたAIサービスの契約は、「無駄遣い」ではなく「現場が自力で解決した結果」です。だからこそ、いきなり統合や禁止に向かうのではなく、把握から始めるのが遠回りに見えて確実です。

• まず7項目の棚卸しシートで、何を誰がどのデータを入れて使っているかを可視化する
• 統合する・残す・止めるの3分類で判断し、専門用途は無理に一本化しない
• SSO対応プラン、退職者のアカウント停止、個人名義の契約、APIキーの管理者の4箇所で詰まりやすい
• 契約条項は学習利用・保存場所・再委託先・解約時のデータ・自動更新の5点を確認する
• 台帳の更新担当と見直し日を決めて、一度きりの作業にしない

この整理が終わると、次に出てくるのは「どのサービスを社内システムと連携させるか」という設計の話です。契約とアカウントの見取り図がないまま連携の検討に入ると、どのデータがどこを通っているか追えなくなります。順番としては、棚卸しが先です。