AIエージェント導入におけるライセンス管理上の留意点


こんにちは、クロスビートコンサルティングの篠田です。

ゴールデンウィークが明け、主要パブリッシャによるルール変更が一気に施行されました。

現場ではその対応に追われていることと思いますが、今回取り上げるのは、5月1日にリリースされたMicrosoftの最上位スイート「Microsoft 365 E7」、およびAIエージェント統制プラットフォーム「Agent 365」です。

今回は、多重化(マルチプレキシング※)ルールの変更が及ぼす影響とE7の導入に伴うこれまでのオプション契約の留意点についてまとめてみました。


1. 新しい多重化ルール

「AIエージェントはEntraIDに登録してもCALの対象にはならない」

これを前提に考えれば、今後AIエージェントに業務をさせることでCALの節約が可能になります。

マイクロソフトの最新の規定にも「AIエージェント自体に個別のCALやライセンスを割り当てる必要はない」という趣旨が示されています。しかし、CALという追加コストがないだけで、別のコストが発生することになりました。

それがマルチプレキシングの条文変更です。

マルチプレキシングとはもともと、 複数の入力信号を1つにまとめることで伝送路の容量を節約する仕組みです。

例えば、10人のユーザーがあるサーバーに接続する際、個々に接続するのではなく、一つの接続にまとめることで、伝送容量を節約します。TDM 、FDM、WDMなどといった仕組みがあります。

複数の接続要求を一つにまとめるため、例えばCAL(クライアントアクセスライセンス)だと、本来は10人分あるいは10台分のライセンスが必要なのに、直接接続しているのは1人あるいは1台だけなので、1ライセンスだけを調達すればいいことになってしまいます。

これではパブリッシャーの商売にならないので、このような仕組み(マルチプレキシング)で接続する場合には、その便益を享受するユーザーやデバイス(この例であれば10人あるいは10台)分のライセンスが必要と、使用許諾で定めているものです。

マイクロソフトは5月1日付の製品条項(Product Terms)において、マルチプレクシング(多重化)の条文を以下のように変更しました。

  • 変更前: 「ハードウェアまたはソフトウェア」を介した接続のプーリングを制限。
  • 変更後: 「いかなる方法(例えば、ハードウェア、ソフトウェア、または自動化 [or automation])」を介した接続も対象。

この「または自動化」という文言が追加されたことにより、課金の論理が変わりました。

  • 従来の常識: サーバーという「箱」への接続ルート(入り口)に課金する(CALの論理)。
  • AI時代の常識: AIの処理結果やデータ(価値・恩恵)を業務で消費した人間の数(出口)で課金する。

つまり、「入り口(CAL)はフリーパスですが、出口(恩恵の消費)で全員分のチケット(M365 E7またはAgent 365)を回収します」という構造に網が掛け直されたのです。

【確認のための公式条文ナビ】

  • アクセスサイト: Microsoft Product Terms Portal(マイクロソフト製品条項ポータル)
  • 参照セクション: 「Universal License Terms for Online Services(オンラインサービスに関するユニバーサルライセンス条項)」内の 「Multiplexing(多重化)」 の項目

2. ライセンス要否の境界線は「手動業務か否か」

実務上、どこまでが追加ライセンスが不要で、どこからがライセンスが必要になるのか、具体的な業務シナリオで比較してみましょう。

【ライセンスが必要】AIが直接一般社員にデータを配信する

社内ヘルプデスク用に専用IDを持つAIエージェントを作成。ライセンス(E7やAgent 365)を持っていない一般社員100人からの問い合わせをTeams上で受け付け、AIが裏側でSharePointの社内規定(M365データ)を検索し、自動で回答・配布する。

  • 規約上の解釈: AIエージェントという「自動化(automation)」をゲートウェイにして、ライセンスのない100人のユーザーが間接的にM365データから直接的な恩恵を得ているため、マルチプレキシングと判定されます。後ろにいる100人全員分のライセンスが必要になります。

【追加ライセンス不要】AIと一般社員の間に「人間の手動業務」を挟む

ライセンスを持つ担当者がAIエージェントに指示を出してデータを抽出させ、出力された結果を担当者が「手動(Manual)」で確認・加工し、ライセンスのない一般社員にメール等で共有する。

  • 規約上の解釈: AIの処理自体は「担当者の代理実行(On-Behalf-Of)」の枠内であり、一般社員への共有は担当者の判断による「人間の日常的な業務(コミュニケーション)」とみなされるため、多重化には該当せず追加ライセンスは不要となります。

※ただし、形だけ手動に見せて、担当者が中身も見ずに自動転送ルールやPower Automateで右から左へ流している場合は、「自動化プロセスの一部」とみなされる可能性が高いと思います。また、この運用のために担当者の人件費(工数)が膨らむのであれば、DXとしては本末転倒の「逆行」と言わざるを得ません。

ところで、Agent365を契約したらAIエージェントを無制限に利用できるというわけではありません。
AIエージェントが利用するリソースの使用量は別途請求になりますので、AIエージェントを作る場合には、そのリソースの使用量についても十分に考慮して対策をする必要があります。


3. E7移行時に気を付ける「アドオンの二重課金」

次にE7に移行する際の注意事項についてお話しします。

E7にはAgent365も含まれますので、「それならリスクを避け、総額を安くするために、今すぐE7に切り替えよう」と考えるかもしれませんが、その前に確認した方が良いものがあります。

それは「アドオン契約の有無」です。

すでに「M365 E5」に「M365 Copilot(月30ドル)」などの個別アドオンを追加して運用している場合、E7にアップグレードしたからといって、既存の個別アドオン契約は自動的に解約も日割り精算もされません。

マイクロソフトの現在のNCE(New Commerce Experience)の規約では、購入から72時間を過ぎたサブスクリプションは、年間契約の期間が満了するまで中途解約や返金が一切認められないためです。

管理センターで手動のクレンジング(契約数の削減や古い個別アドオンの解約処理)を忘れると、同一ユーザーに対してE7内包分のCopilotと、古い個別アドオンのCopilotの「二重課金」が契約満了日まで容赦なく走り続けます。移行の際は、既存アドオンの「契約更新月」を逆算した綿密な移行スケジューリングが不可欠です。

【確認のための公式条文ナビ】

  • 中途解約不可の根拠: Microsoft Learnの「Partner Center」ドキュメント内、「New commerce experience cancellation policy(新規商業体験のキャンセルポリシー)」(購入後72時間制限の規定)
  • 重複課金の根拠: マイクロソフト製品条項ポータル内の「General Terms for Online Services(オンラインサービス共通条項)」の 「Assigning Licenses to Users and Devices(ユーザーおよびデバイスへのライセンス割り当て)」(ユーザーごとに個別にライセンスを維持する義務の規定)

4. AIエージェントをID登録しなければライセンス費用は発生しない?

「規約が厳しいなら、正式登録せずに、既存のシステムアカウントや個人のトークンを使い回して隠れてAIを動かそう」という方もいるかもしれませんが、それは大きなリスクを抱えることになります。

① セキュリティシステムによる「自動遮断」の実害

現在のMicrosoft Entra IDは、人間とは異なる挙動をするAIの通信パターンを監視しています。正式な登録(Agent ID発行)のないボットが、特定の個人アカウントに成りすまして大量のデータを高速クロールした場合、セキュリティAI(Identity Protection)はそれを「アカウント乗っ取り」や「トークン奪取」の攻撃と判定する可能性があります。その場合、事前の通告なしにアカウントが強制ロックされ、関連するすべての業務システムが突然停止することになるかもしれません。

② 監査時の「悪質なライセンス隠蔽」認定

ID登録をせず隠れて動かしていた「シャドーAI」が監査(Audit)で発覚した場合、マイクロソフトに、単なる過失ではなく、「意図的なライセンス費用の隠蔽(偽装工作)」とみなされる可能性があります。これにより、パブリッシャ側から、想定外のペナルティが下される場合が想定されます。


5. パブリッシャはどうやって「遡及ポイント」を特定するのか?

企業側が「このAIエージェントは先月作ったばかりだ」と言い張っても、パブリッシャは客観的なデジタル証拠を基に、違反の開始時期(遡及ポイント)を特定することができます。

  • Microsoft Graph API のコールログ: AIがM365データにアクセスする際のAPI利用ログには、何年分にもわたり「いつ、どのシステムから、どのデータにアクセスしたか」が記録されています。この「最初のアクセス日時」が遡及の起点になります。
  • 連携先サードパーティツールの契約・ログ: AdobeやServiceNow、ChatGPT Enterpriseなどの外部AI環境と連携させている場合、M365側のログが消されていても、外部システム側のデータ送信履歴(Webhook等)からデータ連携の開始日が正確に特定されます。

万が一、企業側が「ログを破棄したため証明できない」と主張した場合、パブリッシャは契約条項(監査権)に基づき、「確認できない期間(最長で過去3年間など)のすべてを違反期間とみなして推計請求する」という特権を行使してくる可能性もあります。


弊社からのアドバイス

ソフトウェアパブリッシャは、AIという「新しい道具」を市場に提供すると同時に、それを「新しい課金対象」として定義し直しています。

今回のAgent 365のリリースに伴い、Entra IDに「Agent ID」を登録してセキュリティを強固にすることは、ガバナンス上は正しい行動だと思います。しかし、IDを登録した瞬間、パブリッシャ側からは「そのAIがいつから動き、誰にデータを渡しているか」が完全に可視化されるという事実を忘れてはなりません。

パブリッシャにログを握られて遡及請求を受ける前に、自社で「Agent 365」のコントロールプレーンにエージェントを登録し、自らAIの利用開始日、スポンサー(責任者)、恩恵を受けるユーザーの範囲を「正しいガバナンスの記録」として確定させてしまうこと。これこそが、パブリッシャの不当な推計請求から会社を守る唯一の防衛策(エビデンス)になります。

システムを構築する前に、まずは現状のアクセス経路とライセンスの適合性をプロの視点で棚卸しすることをお勧めします。


著者プロフィール:篠田 仁太郎 (Jintaro Shinoda) クロスビートコンサルティング株式会社 代表。一般社団法人 IT資産管理評価認定協会(SAMAC)副理事長。ITAMの専門家として、複雑化するソフトウェアライセンスの最適化やIT資産管理の構築・改善を支援。

Key Takeaways

  • Microsoftが新しい多重化ルールを施行し、AIエージェントは単独でCALの対象にはならなくなりました。
  • AIエージェントを使うことで、CALの節約が可能になる一方、マルチプレキシングにより追加のライセンスコストが必要です。
  • E7への移行時には既存のアドオン契約に注意が必要で、二重課金のリスクがあります。
  • AIエージェントを正式に登録しないと、セキュリティリスクや監査時のペナルティが発生する可能性があります。
  • AIエージェントの使用開始日や責任者を正確に記録することが、パブリッシャの不当請求から会社を守る防衛策になります。

Estimated reading time: 14

ホーム » 知見・ブログ » AIエージェント導入におけるライセンス管理上の留意点

Comments

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA