Claude Microsoft 365の必須レビュー、本当に必須なのはどこか

Claude Microsoft 365の必須レビューとは何か

Claude for Excel・Word・PowerPoint・Outlookには、変更を確定する前に人間の目を通す仕組みがあります。ただし、その強制力はアプリごとに違います。もっとも強いのはOutlookです。アドイン自体がMail.Send権限を要求しないため、Claudeがメールや招待を単独で送信する経路がそもそも存在しません。これは設定で無効化できない、構造そのものの制約です。

Wordのトラッキング編集モードはこれとは性質が違います。Claudeの編集を追跡された変更として残す仕組みですが、これは利用者がWord側で切り替える設定であり、既定で常に有効なわけではありません。Excel・PowerPointはさらに限定的です。Claudeがリスクのある操作を提案するときに限り実行前確認が入りますが、それ以外の変更を都度見直すかどうかは公式ドキュメントが挙げるベストプラクティスの範囲にとどまり、アプリがそれを強制するわけではありません。単独送信を構造的に塞いでいるのはOutlookだけです。他の3アプリでは、確定前に人の目を通す運用になるかどうかは設定と利用者の判断に委ねられています。

CopilotとClaudeの料金・機能・提携関係の全体比較はClaude Microsoft 365 Copilot比較にまとめてあり、本記事はそこでは扱っていない、このレビュー機構の強制力の違いと、それが監査・コンプライアンス担当者にとって何を意味するかに絞って掘り下げます。

Word・Excel・PowerPointは変更をどう人の目に通すか

Wordの実装が最も具体的です。トラッキング編集モードに入ると、Claudeの編集はすべて追跡された変更として反映されます。元のテキストは削除として、新しいテキストは挿入として表示され、Wordのネイティブなレビューペインでどちらも確認できます。1件ずつ承認するか、Ctrl+Z(MacならCmd+Z)で元に戻すかは、常に人間の操作です。このモードに入っていない通常の編集では、この仕組みは働きません。

ExcelとPowerPointには、Wordのようなトラッキング機能そのものはありませんが、共通の安全弁があります。Claudeがリスクのある操作を提案するときは、実行前に確認を求められます。これは外部由来のファイル(取引先から届いたテンプレートやダウンロードしたデータなど)にプロンプトインジェクション(ファイルに埋め込まれた、Claudeを操る意図の隠し指示)が含まれていて、Claudeがそれを正規の指示と誤認するリスクへの対策として設計されています。これは強制される確認です。一方で、リスクがないと判定された変更まで含めてすべてを見直すことは、公式ドキュメントが推奨する運用習慣であって、アプリが求める必須の手順ではありません。

Outlookはなぜ自動送信ができない設計になっているか

Outlookの実装は、他の3アプリよりも踏み込んでいます。Claude for Outlookのアドインは、そもそもMail.Send権限を要求しません。つまりOutlook自身に組み込まれた仕組みとして、Claudeがメールや招待を単独で送信する経路自体が存在しません。Claudeが作った下書きは常にOutlookの作成画面や予定表フォームに未送信の状態で置かれ、送信ボタンを押すのは人間です。

これは設定で無効化できる安全機能ではなく、アドインが要求する権限の範囲そのものに組み込まれた制約です。ベータ期間中の推奨事項として、公式ドキュメントは無人送信を避けるよう明記しています。下読みなしでの取引先送付や、法的特権情報や規制対象データを含む受信箱での無制限運用も避けるべき使い方として挙げられています。とくに外部の送信者からのメールは、プロンプトインジェクションを意図した隠し指示を含む可能性がある「信頼できない入力」として扱う必要があります。

ローカルに残るデータは保持ポリシーにどう影響するか

必須レビューが「確定前の確認」を扱うのに対し、確定した後のデータがどこにどれだけ残るかは別の論点です。Claude for M365は会話履歴・アップロード済みSkill・コネクタの登録情報・サインイン認証情報を、Anthropicのサーバーではなく各ユーザーのデバイス上のブラウザストレージに保存します。Anthropicはこのデータのコピーを保持せず、デバイス間・ブラウザ間の同期も行われません。

この設計は監査担当者にとって両義的です。会話履歴やスキル・認証情報がAnthropic側のサーバーに蓄積されない点はデータ主権の観点で有利に働きます。ただし、これはローカル保存されるデータの話であって、Claudeに処理させたプロンプトや文書内容そのものが完全にAnthropicを素通りするわけではありません。Anthropicへ直接サインインする第一者デプロイでは、バックエンドへ渡された入出力は受信・生成から30日以内に削除されます。第三者プラットフォーム経由のデプロイでは、文書内容は自社で設定したBedrock・Vertex AI・Azure・ゲートウェイのエンドポイントへ流れる仕組みに変わります。BedrockまたはVertex AI経由の場合は、そもそもAnthropicに届きません。

ローカルに保存されるデータの保持期間は、このバックエンド側の30日ルールとは別の仕組みで区切られています。会話履歴は1ユーザー・1組織・1Officeアプリあたり直近50件が古い順から自動的に削除される仕組みで、年数による有効期限や、管理者が設定できる保持期間は存在しません。ローカルに保存されるこれらのデータには、組織で設定したカスタムデータ保持設定も適用されません。

保持期間の制御という点では、ローカル側のデータは組織のポリシーではなくデバイスのライフサイクルに委ねられます。組織の情報保持ポリシーがこのローカルデータに独自の保持期間を求める場合、実務上の制御点はローミングプロファイルの掃除やデバイスの再イメージ化といった、デバイス側の運用にしかありません。

サインイン認証情報も同じローカルストレージ上に平文に近い形で置かれ、保護境界はOSアカウントとディスク暗号化です。デバイスを廃棄・譲渡する前にエクスポートし忘れると、その端末の会話履歴と認証情報はまとめて失われます。逆にエクスポートを行う場合は、エクスポート先のフォルダに認証情報も一緒にコピーされるため、そのフォルダ自体を機密情報として扱う必要があります。

デプロイ方式によって監査の主体はどう変わるか

Claude for M365には、Anthropicへ直接サインインする第一者デプロイと、Amazon Bedrock・Google Cloud Vertex AI・Azure AI Foundry・LLMゲートウェイを経由する第三者プラットフォームデプロイの2通りがあります。この選択は、レビュー機構の挙動には影響しませんが、利用量・支出の追跡とテレメトリの送信先を丸ごと入れ替えます。

第一者デプロイでは、利用状況はClaude Enterprise Analytics APIから、支出はTeam・Enterprise向けの管理コンソールのCSVエクスポートから追跡します。第三者プラットフォーム経由の場合、この2つはAnthropic側の仕組みではなく、クラウドプロバイダーの請求コンソールとゲートウェイ自身のログ機能に置き換わります。監査担当者がどちらの経路を前提に証跡を集めればよいかは、この選択によって変わるということです。

監査証跡はどこまで追えるか

企業がAIをOffice文書に組み込むとき、変更の確認と同じくらい重要なのが「誰が何を確認して承認したか」を後から追跡できることです。Anthropicの信頼性センター(Trust Center)は、前節で見た2つのデプロイ方式それぞれに対応するアーキテクチャ図を公開しており、プロンプト・文書内容・応答がどこを流れるかを導入前に確認できます。

Enterpriseプランの組織は、カスタムのOpenTelemetryコレクターへ監査証跡を転送できます。転送される内容にはセッションID・利用面(Excel/Word/PowerPoint/Outlookのどれか)・ツールの入出力・プロンプトの内容・参照した文書の情報まで含まれます。これはAnthropic自身のコレクター向け経路とは異なる点に注意が必要です。既定の経路は機微な属性を取り除くフィルタがかかっていますが、カスタムエンドポイントを設定した時点でこのフィルタは経由しなくなります。なお、OpenTelemetryエクスポートの利用可否をプランごとに公式が明記しているのはOutlookのみで、Enterpriseプランでのみ利用でき、Pro・Max・Teamプランには観測性・監査エクスポートの機能自体がありません。

カスタムOTelを設定しても、Enterprise監査ログに載るわけではありません。4アプリの利用は常にEnterprise監査ログの対象外です。この抜け穴を補うのがCompliance APIです。EnterpriseでCompliance APIを有効にしている組織では、4アプリすべてのセッションがパブリックベータの対象として、既存のCompliance Access Keyのまま参照できます。追加設定は不要です。

OTelコレクターを受け入れる側の技術要件も、監査観点で押さえておく必要があります。エクスポート元は各ユーザーのブラウザ内のタスクペインで、コレクターのエンドポイントへ直接送信するクロスオリジンリクエストになるため、エンドポイント側はCORSのプリフライト(OPTIONS)応答とPOSTレスポンスの両方で許可ヘッダーを返す必要があります。Grafana Cloudのようなサーバー間送信を前提としたマネージドOTLPの受け口は、このプリフライトに応答しないことが多く、その場合ブラウザは認証ヘッダーを送る前に送信を遮断します。回避策として、自前で運用するOpenTelemetry Collectorを立て、そのCollectorからバックエンドへ転送する構成が案内されています。この経路にはプロンプトと文書内容がそのまま流れるため、エンドポイントへのアクセス権限は、文書内容そのものへのアクセス権限と同じ重さで扱う必要があります。

この設計は監査担当者の何を軽くするか

必須レビューという設計は、「AIが何かを勝手に確定させた」という事故そのものを構造的に起こりにくくします。ただし、それが構造として保証されているのはOutlookの送信行為だけです。Outlookでは、送信という最終行為の手前でレビューが行われたかどうかを個別に確認する作業自体が発生しません。

アプリごとに、確認の跡がどう残るかは異なります。Wordの変更履歴は、利用者がトラッキング編集モードに切り替えたときだけ、その場に残る形で「人間が確認して進めた」ことを示します。Excel・PowerPointの確認は、Claudeがリスクのある操作を提案したときに限って操作の前に入るだけで、承認したあとには何も残りません。Outlookの未送信の下書きは、その場に残っている間だけ、送信前に人の目を通したことの痕跡になります。ただし、この変更履歴・確認・下書きのいずれも記録として保存されるという記載は公式ドキュメントになく、事後に遡って確認できる証跡にするには、前節で見たEnterpriseの監査エクスポートやCompliance API側の記録に頼る必要があります。

この設計は万能でもありません。Word・Excel・PowerPointの確認ステップも、内容を読まずに承認ボタンを押してしまえば形骸化します。プロンプトインジェクションへの対策として公式が案内している「外部ファイル・外部送信者のメールを信頼できない入力として扱う」という運用は、ツールの設計ではなく利用者の習慣に委ねられている部分です。構造的な制約を持つOutlookは事故の発生率そのものを下げますが、Word・Excel・PowerPointの確認ステップは運用しだいで機能もすれば形骸化もします。レビューの質までを保証する設計は、4アプリのどれにもありません。

まとめ

Claude Microsoft 365のレビュー機構は、OutlookのMail.Send権限不在のように構造そのものに組み込まれた制約もあれば、Wordのトラッキング編集モードのように利用者が切り替えて初めて働く仕組みや、Excel・PowerPointのようにリスクのある操作に限って確認が入る仕組みも混在しています。監査・コンプライアンス担当者にとって重要なのは、この違いを踏まえたうえで、Enterprise監査ログが対象外である以上はCompliance APIやOpenTelemetryコレクターへの転送を自ら設定しない限り、事後に遡れる証跡は残らないという点です。Excel領域でのCopilotとの監査要件比較はClaude for ExcelとCopilotの比較、Microsoft 365コネクタ自体のセキュリティモデルはMicrosoft 365コネクタのセキュリティにまとめています。