Microsoft 365 Copilotのようなテナント統合型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のセールスマテリアルは「ワープロでこんなことができる」 「メールでこんなことができる」 という機能列挙の形を取りやすいですが、 導入後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。各事業者の最新条件は契約時点の規約を確認のこと。 ↩ ↩2