Claude for Microsoft 365をBedrock・Vertex・Foundryで使う設定

はじめに

Claude for Microsoft 365は、Excel・PowerPoint・Word・OutlookにClaudeを組み込むOfficeアドインです。既定の接続先はAnthropicのClaudeアカウントです。ただしAmazon Bedrock・Google Cloud Vertex AI・Azure AI Foundry・自社LLMゲートウェイのいずれかをすでに使っている組織は、ユーザー1人ずつにClaudeアカウントを発行せずにアドインを配布できます。プロンプトと応答は自社のインフラ内にとどまります。Bedrock directとFoundryのキーレス構成なら、Microsoft Entra IDでの職場アカウントサインインだけで動きます。Outlook単体での受信トレイ整理や返信作成の使い方はClaude for Outlookの使い方にまとめています。

これはCoworkのMicrosoft 365コネクタ(Outlook・OneDrive・SharePoint・Teamsを横断検索する機能)とは別物です。コネクタ側の連携手順はClaude Cowork×Microsoft 365連携にまとめています。本記事が扱うのは、Excel・PowerPoint・Word・Outlookの中で直接動くアドインを、どの推論基盤に接続するかという管理者向けの設定です。

Claude for Microsoft 365の基本: 入手先・Macでの開き方・Claude Codeとの関係

アドインを使うだけの人と、推論基盤を指定する管理者とでは、読むべき節が違います。次の表で自分の立場を確かめてください。

アドインを自分で入れて使うだけなら、AppSourceからインストールしてClaudeアカウントでサインインします。組織で推論基盤を指定したい管理者は、次の節から読み進めてください。

4つの接続経路

管理者はデプロイ時に接続経路を1つ選びます。エンドユーザーから見える画面はどの経路でも同じです。

いずれの経路でも、pivot.claude.aiとclaude.ai/api/はアドインの画面表示・機能フラグ評価・運用テレメトリに使われ、プロンプトや応答は通りません。

自分の状況から経路を選ぶ

経路によって、使える機能とOutlookの可否が変わります。公式ページの機能差の表と、エンドユーザー向け手順の注記を突き合わせると、次の切り分けになります。

前提条件

全経路で共通して必要なもの:

• Microsoft AppSource経由、または管理者によるテナント配布でインストール済みのClaude for Excel・PowerPoint・Word・Outlook
• Entra IDが有効なMicrosoft 365テナント(admin consent(管理者による一括同意)とトークン発行に使う)
• Outlookを使う場合はMail.ReadWrite・Calendars.Read・User.Read・offline_accessに対するMicrosoft Graphのadmin consent

経路ごとに追加で必要なものは次のとおりです。

これらのリソースは組織のIT部門が管理する対象です。Anthropicが代わりに払い出したりリセットしたりすることはありません。Claude Code Bedrockセットアップで作るIAMロールとは別に、Officeアドイン用のロールが要ります。ウィザードが作るのは、Entra IDトークンを信頼するIAM OIDCアイデンティティプロバイダーです。あわせて、bedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamを許可したロールも作ります。信頼ポリシーはアドインのアプリIDに限定されます。

ネットワーク許可リスト

アクセスを許可するドメインは、Anthropic API直結(1P)かサードパーティ経由(3P)かで変わります。どちらの構成でも、プロンプトと応答が届くのは選んだ推論プロバイダーだけで、pivot.claude.aiのようなAnthropic向けドメインはアドインの画面と運用テレメトリしか扱いません。

3P構成(Entra IDでサインインし、推論はゲートウェイ・Bedrock・Vertex AI・Foundryへ向かう)で許可が必要なドメインは次のとおりです。

表のほかに、見落としやすい条件が3つあります。

• Vertex AI directでは、グローバルのaiplatform.googleapis.comも許可が要ります。リージョン別の<region>-aiplatform.googleapis.comだけでは足りません
• Foundry directでazure_base_urlに自社ゲートウェイを指定している間は、<resource>.services.ai.azure.comへ接続しません。許可するのはゲートウェイのドメインです
• 後述の「組織提供設定」を使う場合は、claude.aiとapi.anthropic.comも許可が必要です。メンバーがclaude.aiでサインインし、設定をapi.anthropic.comから読むためです。推論は設定に書かれたプロバイダーにだけ向かいます

管理者側のデプロイ手順

配布にはclaude-for-msft-365-installプラグインを使います。クラウドリソースのプロビジョニング、マニフェスト生成、admin consentの取得を1つのウィザードにまとめたものです。

claude plugin marketplace add anthropics/financial-services
claude plugin install claude-for-msft-365-install@claude-for-financial-services

デプロイのたびにプラグインが最新か確認します。古ければ更新してからセットアップに進みます。

claude plugin update claude-for-msft-365-install@claude-for-financial-services

インストール後、Claude内からセットアップウィザードを実行します。

/claude-for-msft-365-install:setup

ウィザードは選んだ経路に応じて次の作業をガイドします。ゲートウェイ・Bedrock・Vertex AIでは、最後にマニフェストの生成とAzure admin consentまで進みます。

• Bedrock direct: IAM OIDCアイデンティティプロバイダーとロールを作成します
• Vertex AI direct: Google OAuthクライアントの作成をガイドします
• Foundry direct: リソース名とAPIキーを取得します
• LLMゲートウェイ: リソース作成が不要で、URLとトークンの入力だけでマニフェストが生成されます

BedrockとVertex AIの経路はマニフェスト生成にNode.jsを使うため、未インストールならウィザードが導入を促します。

Foundry directのウィザードは、リソース名とAPIキーだけでマニフェストを作ります。キーレスのEntraサインインにしたいときは、生成されたマニフェストのURLに後述のパラメーターを自分で足します。

プラグインが提供するコマンドは次のとおりです。

接続やサインインで想定外の挙動があれば、まず/claude-for-msft-365-install:debugを実行します。接続失敗画面の「Copy error details」を貼り付けると、症状から原因を切り分けてくれます。

ユーザー別設定の解決順と資格情報の置き場所

チームごとにゲートウェイトークンやAWSロールを変えたいときは、初期設定のあとにユーザー別の値を書き込みます。コマンドは/claude-for-msft-365-install:update-user-attrsです。アドインは起動時に、設定キーごとに次の順で値を探します。

マニフェストのURLに資格情報を直接書く構成には注意点があります。次のキーをクエリ文字列に置くと、ブラウザが読み込みのたびにサーバーへ送ります。

gateway_token・azure_api_key・google_client_secret・otlp_headers・inference_headers・mcp_servers

公式の変更例は次のとおりです。SourceLocationとTaskpane.Urlの両方に適用し、XML内では&を&と書き、Microsoft 365管理センターで再デプロイします。

before: https://pivot.claude.ai/?gateway_url=https://ai-gateway.example.com/v1&gateway_token=sk-gw-xxxxx&m=excel3p-1.0.0.1
after:  https://pivot.claude.ai/?gateway_url=https://ai-gateway.example.com/v1&m=excel3p-1.0.0.1#gateway_token=sk-gw-xxxxx

Outlookは別マニフェスト

メールアプリ向けのスキーマはMicrosoftが別に定めています。そのため、Excel・PowerPoint・Wordとは別のマニフェストファイル(manifest-outlook.xml)が生成されます。Microsoft 365管理センターへは、それぞれを別のカスタムアプリとしてアップロードします。OutlookのメールボックスアクセスはMicrosoft Graphを通るため、どの推論基盤を選んでもGlobal Administratorによる一度きりのGraph admin consentが必要です。サードパーティ基盤経由のOutlookは、Claude Opus 4.7以降とClaude Sonnet 5以降だけに対応します。それより前のモデル世代はOutlookでは使えません。Graphのトークンはユーザーの端末内にとどまり、ゲートウェイにもAnthropicにも送られません。

組織のポリシーでAnthropicが発行するマルチテナントアプリへの同意が認められない場合は、同じ委任権限を持つ自社のシングルテナントEntraアプリを登録し、そのクライアントIDをウィザードにgraph_client_idとして渡します。

Microsoft 365への配布

配布後、Excel・PowerPoint・Wordでは、Windowsなら「ホーム」→「アドイン」、Macなら「ツール」→「アドイン」に並びます。Outlookはメールを開いたときのリボンに出ます。範囲は再デプロイなしで後から変えられるので、最初はパイロットグループに絞る進め方があります。

マニフェスト配布まわりでは、アドインが出ない・更新後も古い設定のまま・サインインやadmin consentがループする、といった問題が起きやすいと公式は説明しています。/claude-for-msft-365-install:debugは、本番へ上げる前にマニフェストをローカルでサイドロードして検証する用途にも使えます。

機能を個別に無効化する

disabled_featuresキーを使うと、ユーザーごと・組織全体で個別機能を止められます。

web_searchを無効化しつつmcp_serversキーで自社の検索ツールを接続すれば、検索クエリを自社インフラ内に留められます。disabled_featuresは、マニフェストのパラメーター(カンマ区切り)でも、Entra IDの拡張属性(カンマ区切り)でも渡せます。bootstrapエンドポイントならJSON配列です。全社共通にもユーザー別にもできます。知らないスラグは無視されるため、新しいバージョンのスラグを古い配備に書いても害はありません。

文書単位で止めたいとき、たとえば特定の秘密度ラベルが付いたファイルだけ機能を切りたいときは、access_policiesキーを使います。リソースを指定しない文はdisabled_featuresと同じ動きになります。

組織提供設定(プレビュー)

マニフェストのパラメーター・拡張属性・bootstrapの代わりに、Anthropicが設定をClaude組織のメンバーへ直接配る方式もあります。メンバーは「Log in」でClaudeアカウントにサインインするだけで、ゲートウェイURLやAPI形式、使えるモデルが入力済みの接続画面が開きます。

この方式は、公式の記述ではプレビュー段階で、本番の組織にはまだ有効化されていません。使う場合の性質は次のとおりです。

• 提供された設定が唯一の設定元になり、マニフェストや拡張属性とはマージされません
• 提供設定がbootstrap_urlを含んでいても無視され、メンバーのトークンはそこへ送られません
• 設定の変更は再デプロイなしで反映されます。Claude組織の管理者とMicrosoft 365の管理者は別の人でかまいません
• サインイン用のトークンは推論には使えず、Office間で引き継がれません。別のOfficeアプリでは再ログインを求められることがあります

ゲートウェイ側の要件

ゲートウェイを選ぶ場合、アドインのタスクペインはhttps://pivot.claude.aiから読み込まれるため、ゲートウェイへの通信はすべてクロスオリジンになります。CORSヘッダーがない応答は、ブラウザが何も言わずに捨てます。

• Access-Control-Allow-Origin: https://pivot.claude.ai(または*)を、すべての応答に付けます。GET・POST・OPTIONSとエラー応答を含み、プリフライトだけでは足りません
• プリフライトではAccess-Control-Allow-Headersに、アドインが送るヘッダーを列挙します。x-api-key, authorization, content-type, anthropic-versionなどです
• *のワイルドカードはFetch仕様上Authorizationを含まないので、gateway_auth_header: authorizationにするなら明示的に書きます

gateway_api_formatで、ゲートウェイが話すAPI形式を指定します。形式ごとに必須のエンドポイントが違います。

モデル一覧の取得も形式で変わります。anthropic形式ではログイン時にGET /v1/modelsで探し、無ければモデルIDの手入力を求めます。bedrockとvertexでは内蔵のモデル一覧を使い、各モデルにゲートウェイ越しの疎通確認をかけます。

LiteLLMを使う場合の設定例も公式にあります。Bedrockへ流す例は次のとおりです。

model_list:
  - model_name: claude-opus-4-7
    litellm_params:
      model: bedrock/us.anthropic.claude-opus-4-7
      aws_region_name: us-east-1
litellm_settings:
  drop_params: true

公式はあわせて、LiteLLMのPyPI版1.82.7と1.82.8に認証情報を盗むマルウェアが含まれていたと警告しています。該当版は入れず、入れてしまった場合はパッケージを削除し、影響を受けた環境の認証情報をすべてローテーションします。

Foundryでは、Azure API Managementのような自社ゲートウェイをazure_base_urlで指定できます。値はClaude CodeのANTHROPIC_FOUNDRY_BASE_URLと同じものを使い、HTTPSが必須です。このときアドインはanthropic-betaヘッダーを送ります。キーレスならauthorizationも送ります。プリフライトで両方を許可し、anthropic-betaをFoundryまで転送してください。

エンドユーザーの接続手順

LLMゲートウェイの場合は、アドインのサインイン画面で「Cloud provider or gateway」を選び、ゲートウェイのURLとAPIトークンを入力します。既定ではトークンをx-api-keyヘッダーで送りますが、管理者がマニフェストでgateway_auth_header: authorizationを指定していればAuthorization: Bearer形式になります。認証情報はブラウザのlocalStorage内(アドインのサンドボックス化されたiframe)に保存され、Anthropicのサーバーには同期されません。Claude Codeと違ってOSのキーチェーンは使えないため、入力するのはゲートウェイが発行したトークンに限ります。クラウドプロバイダーの生の認証情報は入力しません。

ゲートウェイトークンの期限切れや接続先URLの変更では、アカウントメニューから「Logout」して入れ直します。これはゲートウェイ・Bedrock・Vertex AI・Foundryのどのdirect接続でも同じです。

Bedrock・Vertex AI・Foundryのdirect接続では、経路ごとに接続の流れが異なります。

• Bedrock(Excel・PowerPoint・Wordのみ): ユーザーが自分のMicrosoft職場アカウントでサインインすると、Entra IDトークンでAWSロールを引き受けます
• Vertex AI: 管理者が作成したGoogle OAuthクライアント経由でGoogleアカウントサインインを行います
• Foundry: リソース名とAPIキーが事前設定されていれば自動接続します。キーレス設定なら職場アカウントのサインインだけで接続します

FoundryのAPIキーなし接続

共有のリソースキーの代わりに、ユーザーごとのMicrosoft Entra IDトークンで認証する構成も選べます。トークンはOffice内のNested App Authenticationで取得され、<resource>.services.ai.azure.comへAuthorization: Bearerとして送られます。期限が切れる前に自動更新され、端末にキーは保存されません。設定には、Entraアプリ登録へのuser_impersonation委任権限の付与と、対象ユーザーへのCognitive Services Userロール付与の両方が必要です。このアプリ登録は、Claude Desktopのアプリ内Foundryサインインが使うinferenceFoundryClientIdと同じもので、アドインのリダイレクトURIを追加して使います。

マニフェストURLには、azure_api_keyを入れずに次のパラメーターを置きます。

gateway_auth_source=entraのときは、渡されたazure_api_keyも無視されます。管理者がキーレスを選んだものとして扱われるためです。静かなサインインができない場合、ユーザーには初回だけMicrosoftのサインイン画面が出ます。

Claude Codeのゲートウェイ設定との違い

すでにClaude Codeをゲートウェイ経由で運用しているチームにとって、Officeアドインの設定は次の点が異なります。

bootstrapエンドポイントを使う場合、アドインは応答に書かれた有効期限の約5分前にエンドポイントを呼び直し、返ってきたトークンを実行中のセッションに適用します。期限前にゲートウェイが認可エラーを返したときも、1回だけ呼び直して、トークンが変わっていれば再試行します。手入力したトークンにこの仕組みは働きません。

Claude CodeのVS Code拡張で同じ3経路を使う設定は、VS Code拡張でサードパーティプロバイダーを使う設定にあります。

Claudeアカウント接続との機能差

サードパーティ基盤経由では、一部の機能がまだ使えません。

公式は「Support is being added」と述べているので、「対応予定」の行は今後変わる可能性があります。Claudeアカウントで組織提供設定にサインインしたメンバーは、推論が組織のプロバイダーへ向かうため、この表ではサードパーティ基盤の列に入ります。

よくあるつまずき

「Connection refused」やネットワークエラー: ゲートウェイURLやクラウドエンドポイントにユーザーの端末から到達できていません。URLの正しさ、サービスの稼働、ファイアウォールやVPNの制限を確認し、ネットワーク許可リストのドメインが通っているか見直します。

401 Unauthorized・「Invalid token」: 認証トークンが無効または期限切れです。ゲートウェイならIT部門にトークンを確認します。direct接続ならEntra IDアカウントが対象グループに入っているか、OIDC信頼関係やOAuthクライアントの設定を確認します。FoundryのAPIキー構成ならAzure Portalでキーを再生成し、キーレス構成ならentra_scopeがhttps://cognitiveservices.azure.com/.defaultになっているか確認します。

403 Forbidden・「Access denied」: トークンは有効でも権限が足りません。Bedrockならbedrock:InvokeModel権限を確認します。Vertex AIならプロジェクトのVertex AI Userロールを確認します。Foundryならリソースのネットワーク設定やCognitive Services Userロールを確認します。

404 Not found: ゲートウェイのURL欄にベースURLだけを入れているか確認します。/v1/messagesのようなパスまで含めると失敗します。

「No models available」: gateway_api_format: anthropicのゲートウェイがGET /v1/modelsでモデル一覧を返していない可能性があります。BedrockやVertex direct接続なら、対象リージョン・プロジェクトでClaude Sonnet 4.5以降のモデルが有効か確認します。bedrock・vertex形式のゲートウェイなら転送先リージョン・プロジェクトでモデルが有効か、Foundryならリソースのモデルカタログに1つ以上デプロイされているかを確認します。

500などのサーバーエラー: ゲートウェイかクラウドプロバイダーの内部エラーです。LiteLLMならゲートウェイのログ(docker logs litellmなど)で上流のエラーを確認します。

ブラウザのコンソールにCORSエラーが出る・応答が空になる: ゲートウェイが一部の応答にだけCORSヘッダーを付けている可能性があります。前節のとおり、エラー応答を含む全応答に必要です。

ストリーミング応答が止まる・返らない: ゲートウェイがServer-Sent Eventsをそのまま通しているか確認します。プロキシ設定によってはSSE接続をバッファリングしてしまい、ストリーミングが届きません。

データの扱い

Bedrock経由の課金体系は直接APIと単価やリージョン加算の扱いが異なるため、コスト試算はBedrockのClaude料金は直接APIとどう違うかで先に押さえておくと、Officeアドインの利用量が増えたときの見積もりがしやすくなります。

推論を自社インフラ経由にしても、アドインは画面表示のためにpivot.claude.ai、機能フラグ評価のためにclaude.ai/api/と通信します。ここで送られるのは使われた機能・処理時間・エラー率といった運用テレメトリだけで、プロンプトや応答は含まれません。Anthropicは顧客のAWS・Google・Microsoftインスタンス(プロンプトや出力を含む)にアクセスしません。そこからモデルを学習させることもありません。一方でツールの使用状況やトークン数といったメタデータにはアクセスでき、分析と製品改善に使います。プロンプト・ツール入出力を含む完全な監査ログを自社インフラへ流したい場合は、カスタムOpenTelemetryコレクターの設定で対応します。

サインイン時にpivot.claude.aiへリダイレクトされる理由

ブラウザがhttps://pivot.claude.ai/auth/callbackへ戻される場面は3つあります。VertexのGoogleサインイン、Anthropicのサインイン、Microsoftのadmin consentです。セキュリティ審査では、アクセストークンがAnthropicのサーバーを通るのかが論点になります。公式の説明は次のとおりです。

• URLに入るのは、一度きりの認可コード(code)と、アドインが生成したstateだけです。コードは単体ではトークンに交換できません
• 交換にはアドイン側だけが持つ秘密が要ります。AnthropicサインインではPKCEの検証値、Vertexでは組織が作ったGoogle OAuthクライアントのclient_secretです
• コールバックページは静的ページで、コードを表示してコピーさせ、Office内のアドインへ貼り戻させます。サーバー側でコードを保存・転送・交換する処理はありません
• ループバック(localhost)宛にできないのは、OfficeアドインがMicrosoft 365上のサンドボックス化されたフレームで動き、受け側のローカルWebサーバーがないためです
• Microsoftのadmin consentで戻るURLに入るのは、admin_consentの真偽値とテナントIDだけです。Graphのトークンは、Nested App Authenticationでアドインが直接受け取ります

検証したいときは、テスト機でネットワークキャプチャを取ります。リダイレクトにaccess_tokenが現れないこと、コード交換のPOSTがpivot.claude.aiではなくoauth2.googleapis.comなどへ向かうことを確認できます。Anthropicのアプリ登録は、表示名が「Claude for Office」、発行元がAnthropic, PBC(確認済み発行元)です。アプリケーションIDはc2995f31-11e7-4882-b7a7-ef9def0a0266です。同意画面やテナント内のエンタープライズアプリが、この値と一致するかを見てください。

まとめ

設定の難所は、経路の選択と、ユーザー別設定の置き場所の2か所にあります。Outlookが要るならBedrock directは外れ、Web検索やコード実行が要るならFoundry系かVertex directに絞られます。資格情報はURLのクエリ文字列ではなく、bootstrapエンドポイントかEntra IDサインインに寄せておく構成が、2026年10月19日以降の仕様変更にも耐えます。