Microsoft 365 環境を日常業務に組み込んでいる税理士事務所・弁護士事務所から、「Microsoft 365 Copilot のようなテナント統合型 AI を入れるか迷っている」 とご相談をいただくことがあります。実際にお話を伺っていると、判断の中身は AI 側の機能比較よりも、自所のデータと運用が現在どこまで整っているかに寄っていることが多いようです。
本稿では、Microsoft 365 Copilot を入り口の例として、 税理士・弁護士事務所がテナント統合型 AI を検討する場面で出てきやすい確認ポイントを、4 つの観点に分けてご紹介します。
税理士・弁護士事務所の既存 Microsoft 365 権限設計が、そのまま Copilot の挙動になる
テナント統合型 AI の公式ドキュメントには、 組織の ID モデル・権限・機密ラベル・保持ポリシーを継承する、 と明記されていることが多いです 1。AI 専用の権限モデルが別に用意されるのではなく、 テナントの既存設定がそのまま AI の参照範囲になる、 という設計です。
この前提に立つと、最初に確認したくなるのは「自所のストレージ・共有ドライブの共有設定は、 AI に参照されることを織り込んだ状態になっているか」 という点です。
たとえば過去に「とりあえずアクセスできるように」 という理由で「組織全体に公開」 や「リンクを知っている全員」 を選んだままになっているライブラリがあり、 そこに顧問先の決算データや個人情報が置かれている場合、 テナント統合型 AI は所員からの質問に対してそのデータを引いてくることがあります。意図的に絞られた権限であれば、 AI も絞られた範囲しか見ません。緩い権限は、 緩い範囲で参照される、 という対応関係になります。
業務統合型グループウェア大手が、 共有領域の高度な管理機能や検索範囲制限機能を AI 展開前の整理として案内しているのも、 同じ構造的な理由のようです。 導入を決める前に確認したいのは AI の機能一覧ではなく、 自所の共有設定が「外に出ても困らない範囲」 と「絞っておきたい範囲」 に分かれているか、 という点になります。
権限設計まわりの考え方は、 関連記事「共有 ID の危うさ」 や「AI 導入前のセキュリティチェック」 と地続きのテーマです。
「閉じている範囲」 と「外に出る範囲」 を分けて見ておく
エンタープライズ向け AI の安全性を考えるとき、「クラウド内で完結する」 と単純化されがちですが、 テナント統合型 AI の場合は、 データ保護追加条項 (DPA) の対象になる範囲と、 ならない範囲が公式ドキュメントで区別されていることが多いです 1。
DPA の対象内とされているのは、 保存時・転送時の暗号化、 テナント間のデータ分離、 プロンプト・応答・テナント内データグラフ経由で参照されたデータが基盤モデルの学習に使われないこと、 GDPR や地域別データ境界、 ISO/IEC 27018 への対応、 といった範囲です。
一方、 DPA の対象外として明示されているものに、 外部 Web 検索エンジン経由の Web 検索クエリがあります。 テナント統合型 AI が Web 上の最新情報で回答を補強する場面で送信されるクエリは、 地域別データ境界適用外であり、 DPA の対象外である、 と明記されていることが多いです。 ユーザー・テナント識別子は取り除かれ、 広告主にも共有されず、 基盤 LLM の学習にも使われない、 とされていますが、「外部の検索サービスにクエリが出ていく」 という事実は残ります。
ここで業務側から確認したいのは、「自所として、 どこまでが許容される外部送信で、 どこからは避けたい外部送信か」 を、 AI 導入前に言語化しておけるか、 という点です。顧問先の固有名詞を含む検索を業務として行いたい場面があるなら、 Web 検索を有効にしたままにするのか、 用途を分けるのか、 所内ルールでどう運用するのか、 を事前に整理しておく流れになります。
検索連動型の生成 AI を業務に組み込むときには、 テナント統合型 AI に限らず似た判断が出てくる場面が多いです。
整っているデータの上では、 AI が動きやすい
統合型 AI の評価が事務所ごとに分かれる理由のひとつに、 参照先データの整理状況の差があります。
テナント統合型 AI は、 テナント内のデータグラフ (メール・チャット・ファイル・予定など) を参照して回答を組み立てる設計です。同じ「議事録を要約して」 という指示でも、 議事録の保管場所が一貫していて、 ファイル名と本文が対応していて、 必要な方にだけ共有されている事務所と、 議事録がメール本文・添付・チャット・個人ストレージに散らばっている事務所では、 出力の品質が変わってきます。
データが整っていれば、 AI は所員の問いに対して関連性の高い文書を引いてきて、 要約や論点抽出を補助します。整っていなければ、 古い議事録や別案件の資料を混ぜて引いてくる、 あるいは「該当データが見つからない」 と返ってくる、 という場面が出てきます。AI の性能の問題というよりも、 参照先が散らかっている分の精度低下が、 そのまま AI の出力に現れるイメージです。
ここから出てくる確認ポイントは、「自所のデータは AI に渡せる状態になっているか」 という点です。整っていないデータの上に AI を載せると、 AI を導入した手応えが薄く、 しばらくして使われなくなる、 という展開もよく見ます。逆に、 整理されたデータの上では、 ライセンス追加と同時に効果を実感しやすくなります。
「データを整える作業」 と「AI を導入する作業」 は通常別の工程になります。順序としては、 データ整理が先で、 AI 導入が後、 になる事務所が多いように見えます。データ整理を後回しにして AI だけ先に入れると、 効果が出にくい領域から使い始めることになりやすいです。
「機能があること」 と「業務に組み込まれること」 は別の話
統合型 AI のセールスマテリアルは「ワープロでこんなことができる」 「メールでこんなことができる」 という機能列挙の形を取りやすいですが、 導入後 3 ヶ月の事務所にお話を伺うと「結局あまり使っていない機能」 も出てきます。
機能としては提供されていても、 自所の業務ルートに組み込まれていない、 というギャップが原因になっている場面が多いようです。たとえば「メール要約機能」 は、 所員の方が普段メールをどう処理しているかと噛み合っていないと使われません。普段から手短にメールを読まれている所員の方にとって、 要約のステップを 1 つ挟むことは、 手数が増える方向に働く場合があります。
ここで確認しておきたいのは、「導入後 3 ヶ月で、 自所のどの業務フローに、 どの所員が、 何回 AI を使う想定か」 を最低限見立てられているか、 という点です。見立てがないまま全所員にライセンスを配ると、 利用率が低いまま月額だけが積み上がる、 という形になりやすいです。
「議事録の要約は所内の○○のミーティングで使う」 「メール返信案は新人所員の方の文体補助として使う」 「表計算の数式サジェストは月次集計の場面で使う」 というように、 具体ユースケースから入る事務所もあります。業務統合型グループウェア提供事業者自身が、 追加ライセンス不要で使える試用向けの軽量版 AI チャットを「まず触ってみる選択肢」 として位置付けていることもあるので、 段階的な検討と整合させやすい部分があります。
段階的に確認していく流れ
ここまでの観点を踏まえると、 テナント統合型 AI を検討する場面では、 自然と段階を踏んだ確認の流れになります。
最初の段階では、 ストレージ・共有ドライブの共有設定を棚卸しします。「組織全体に公開」 「リンクを知っている全員」 になっている範囲を把握し、 顧問先データを含むライブラリの権限を必要な範囲に絞っておきます。AI を入れる前にやっておきたいのは、 AI に触れさせて差し支えのある場所と差し支えのない場所の境界を、 人間側で先に決めておく、 という作業です。
次の段階では、 機密ラベルまたは同等の社内分類を、 最低限のかたちで定義します。すべてのデータに精緻なラベルを付ける必要はなく、「顧問先データを含むものはこのラベル」 という最小限の区別があると、 テナント統合型 AI もそのラベルを引き継いだ動作をします。
その後で、 ライセンスを絞って試す流れに入ります。アドオンの前提となる主要プラン名は契約しているプラン体系によって変わるため、 所内で「AI」 とだけ呼んでいると、 機能の食い違いが起きやすい場面が出てきます。プラン名・対象機能・ライセンス区分を所内で揃えて呼ぶようにすると、 議論がぶれにくくなります。
最後の段階で、 所員ごとの利用ログや運用上の気付きを集約し、 ライセンスを広げる範囲・絞る範囲を判断します。利用が定着した業務フローに重点を置き、 定着しなかった機能は無理に広げない、 という事務所もあります。
この順序は、 Microsoft 365 Copilot に限らずテナント統合型 AI 全般に当てはまる検討手順になっていることが多いです。
士業の守秘義務と Copilot の接続を、書面でどう整えておくか
テナント統合型 AI については、「業務統合型グループウェアにすでに置いているデータを、 同じテナント内の AI が参照する」 という構図ですので、 新たな外部送信が発生するわけではない、 という整理は可能です (Web 検索クエリは別になります)。
ただし、 顧問契約や所属士業会の規程に照らして、 外部クラウドサービスに情報を投入してよい範囲を改めて言語化しておく作業は、 AI 導入と独立に必要になります。個人データを含むプロンプトを入力する場面が業務上発生するなら、 個人情報保護法の取扱原則 (利用目的の特定・必要最小限の利用など) に照らした運用ルールを所内で定義しておきたいところです。
公式ドキュメントでは、 Web 検索クエリは DPA の対象外であることが明示されていることが多いです。「Web 検索クエリは別契約扱い」 という構造そのものは押さえておきたいポイントになります。
社内データを横断参照する構図の背景は、 関連記事「RAG と汎用 AI チャットの使い分け」 と地続きのテーマです。
確認の置きどころ
統合型 AI の検討は、「導入すれば生産性が上がる」 という前提から入ると、 機能比較とライセンス選定に時間が偏りやすくなります。観点を 4 つ (権限設計・外部送信境界・データ整備・運用組み込み) に分けて置いておくと、 AI 側の機能差ではなく、 自所の現在地のほうに目が向きます。
テナント統合型 AI を入れるかどうかは、 最終的にはこの 4 つの観点に対する自所の答え方で決まります。「AI ライセンスを買う稟議」 より先に「ストレージの共有設定を棚卸しする稟議」 を通したほうが、 結果として早く効くこともあります。順序を間違えなければ、 統合型 AI は所内の既存資産を活かす方向に働きやすい道具になります。
本記事はベンダー別連載の Microsoft 365 Copilot 編です。他のベンダーを検討中の方はあわせてどうぞ:
参考
Footnotes
-
業務統合型グループウェア大手のエンタープライズデータ保護に関する公式ドキュメントの一例として、 Microsoft Learn「Enterprise data protection in Microsoft 365 Copilot and Microsoft 365 Copilot Chat」。 https://learn.microsoft.com/en-us/microsoft-365/copilot/enterprise-data-protection 。 各事業者の最新条件は契約時点の規約を確認のこと。 ↩ ↩2