会社で使ってよいAIは、Microsoft 365のCopilotのみ。情報管理やセキュリティの面からそうした運用を行っている企業は多いと思います。

一方で、AIを駆使している人たちはClaude CodeやCodexの話ばかり。。。会社としてセキュアな環境を保ちつつ使いたいがシャドーAIや会社の環境から外れることをするのはこわい。。。

もちろんCopilotでもできることは増えましたが、会社管理の作業フォルダーで複数のファイルを操作し、スクリプトを保存して毎月繰り返し実行する処理などをClaude CodeやCodexで行いたい。

この記事は、その2つを両立させる設計を書きます。会社が契約し管理するAzureを経由して、Claude CodeやCodexを使う環境を、少人数向けに用意する考え方です。両ツールには、Azure側のモデルへ接続する公式の手順があります。Microsoft 365を日常業務の基盤にしている会社の情報システム担当者やAI推進者、AIを駆使したい経営者の方向けです。

結論を先に書きます。

  1. Azure経由のClaude CodeとCodexは、どちらもモデルAPIの利用です。 Microsoft 365の利用承認だけで使える構成ではなく、AzureのモデルAPIと、ツールを動かす端末や仮想環境を、会社の承認対象に加えます。課金もMicrosoft 365 Copilotや各社の月額プランとは別で、Azureの請求に計上されます
  2. 最初の利用者は、経営陣、幹部、AI推進担当がおすすめです。 AIツールへの投資にもお金がかかります。API利用の従量課金となるため、全社員向けはM365のCopilotを、より業務改革を行いたい少人数が使える方法としておすすめさせていただきます
  3. DLPは、ファイルの読み取りとAPIへの送信を分けて設計します。 Microsoft 365 Copilot向けのDLPは、Claude CodeやCodexの通信を自動では守りません。端末のEndpoint DLPで機密ファイルを読ませず、会社が運用するAPIゲートウェイで送信前の検査を行います。このゲートウェイは公式APIを組み合わせて構築する設計案で、別途開発が必要です
  4. Azure OpenAIとMicrosoft FoundryのClaudeでは、契約条件が違います。 FoundryのClaudeはAnthropicが販売者で、Anthropicの契約条件が適用されます。日本国内だけで推論する選択肢は現在ありません。社内規程がAnthropicによる独立したデータ処理を認めない会社では、Azure OpenAI経由のCodexが候補になります

Claude CodeやCodexに任せたいのは、ファイル操作と処理の実行

Claude CodeやCodexを業務で使いたい理由は、プログラミングの支援だけではありません。ファイルの読み書きとコマンドの実行を組み合わせ、複数の手順がある作業を進められることに価値があります。

たとえば、こういう仕事です。

  • 部門ごとに届いたCSVを読み、列名や表記をそろえて集計する
  • 大量のファイルを確認し、命名ルールに沿った整理方法を作る
  • 毎月繰り返しているデータ加工をスクリプトにする
  • 社内の確認作業に使う簡単なツールを試作する

CLIは、文字のコマンドでコンピューターを操作する仕組みです。AIがその操作を扱えると、提案した処理を実際に動かし、結果を見て修正するところまで進みます。依頼の形が変わります。このCSVを集計する方法を教えてから、このフォルダーのCSVを集計し、結果を別のファイルに保存してへ。任せられる仕事の範囲が広がります。

ただし、実務で使うには、できあがった結果が正しいかを確認する手順もセットで考えます。AIが処理を終えたことと、業務に使える品質になったことは別です。この記事の後半で、その確認を含めた導入の順番を書きます。

Azure経由の利用は、モデルAPIを使う方式

この構成のClaude CodeとCodexは、どちらもAPI利用です。利用者が操作するのはClaude CodeやCodexで、AIモデルへの依頼は会社が用意したAzure側のAPIへ送ります。ターミナルから使っても、デスクトップアプリから使っても、この関係は同じです。

APIは、アプリから別のサービスの機能を呼び出す窓口です。接続先と課金は次のようになります。

使うツール モデルの接続先 モデル利用料
Codex Azure OpenAIのResponses API Azure側で課金。少人数で始める場合はトークン量に応じた従量制を選べる
Claude Code Microsoft FoundryのClaude Messages API トークン利用などに基づく従量制。Azureの請求に計上される

Microsoft 365 CopilotやChatGPT、Claudeの月額プランの利用枠を、このAPI利用へ振り替えるものではありません。Claude DesktopのFoundry接続については、Anthropicの席ライセンスを別途購入する必要がなく、推論はAzure側の従量課金になると公式に明記されています。

ここで混同しやすいのが、API利用とAPIキー認証は別の話だ、という点です。APIを使う場合でも、対応するクライアントなら会社のEntra IDで認証できます。両ツールの対応の違いは、利用者の絞り方の節で整理します。

モデルを呼ぶ場所と、作業を実行する場所は別

Azureへ接続しても、ファイル操作やコマンド実行が自動的にAzureの中へ移るわけではありません。モデルを呼び出す場所と、作業を実行する場所の両方を管理します。

モデルを呼ぶ場所と作業を実行する場所を上下2本の流れで示した図。上はClaude CodeやCodexから会社のAPIゲートウェイを経てAzure OpenAIやFoundryへ、下は会社管理のPCか専用の仮想環境で渡したデータを処理し成果物フォルダーに保存して人が確認する流れ

ファイル操作やプログラムの実行は、会社管理のPC、または専用の仮想環境で行います。日常業務のPCと作業場所を分けたければ、Azure上などに専用環境を用意する構成も考えられます。

たとえば、試行用にコピーしたデータだけを作業場所へ渡し、AIにはその範囲で処理を作らせる。結果は指定した出力先へ保存し、人が確認してから実務に反映する。こうすれば、対象を絞って検証を始められます。実行環境の側で触れる範囲をOSの仕組みで制限する考え方は、Microsoft Execution Containersの記事で書きました。この記事の構成でも、実行場所の制限はプロンプトではなく、アクセス権と分離した環境で行います。

最初の利用者を、経営陣とAI推進担当に絞る

この環境は、最初から全社員へ配る必要はありません。役割分担の例を挙げます。

利用する人 主な役割
一般の社員 Microsoft 365の承認済み機能で、日常業務の資料作成や情報整理を行う
経営陣、幹部 自分の担当範囲のデータを分析し、判断に必要な資料や業務改善の試作を行う
AI推進、業務改善の担当 繰り返し作業の自動化や社内ツールの試作を進める
情報システム、管理の担当 利用者、接続先、権限、ログ、費用を管理する

小規模な会社なら、これらの役割を同じ人が兼ねて構いません。決めておくのは、誰が何のために使い、誰が運用の責任を持つのかです。

利用者の管理は、たとえばMicrosoft Entra IDにAI実行環境の利用者グループを作り、専用端末や仮想環境、会社のAPI接続窓口へ入れる人を限定します。ただし、モデルAPIへ直接接続するときの認証は、両ツールで異なります。

接続方法 公式に案内されている認証と利用者管理
Claude Code → Foundry APIキーに加え、Entra ID認証に対応。対象ユーザーやグループに推論権限を付与できる
Claude Desktop → Foundry アプリ内でのEntra IDサインインに対応。会社のアカウントで利用できる
Codex → Azure OpenAIの標準手順 APIキーを使用。Microsoftの現行手順では、CodexのEntra ID対応は利用不可と明記

この違いがあるため、Codexについては、Entraグループを作るだけでAPIキーの利用者まで限定できるとは言えません。

両ツールを利用者ごとに管理するなら、会社が運用するAPIゲートウェイ、つまりモデルへの接続窓口を用意する構成が合います。Codexは組織の認証用プログラムでトークンを取得する仕組みを備え、Claude側も独自ゲートウェイへの接続を公式にサポート済みです。Entra IDで本人を確認し、対象グループだけを通す処理をこの窓口に実装します。これは標準のAzure直結設定に加える構成です。

もう1つ。役職にかかわらず、扱うデータと実行権限は担当業務に合わせて設定します。AIを使う権限、会社のデータを見る権限、Azureの設定を変更する権限は、それぞれ分けて考えます。 社長だから全部、という設定にしないことです。

承認するのは、利用者と作業範囲の組み合わせ

少人数に絞ると、利用目的や実行結果を追いやすくなります。さらに、業務用データを扱う初期構成を次のように限定します。この記事で提案する設計です。

管理する対象 初期構成
利用者 指名した経営陣、幹部、AI推進担当のみ
実行環境 会社管理の専用PC、または個人ごとに分離した仮想環境。通常業務の管理者権限を渡さない
読み取り 利用を許可したデータだけを作業領域へ渡す。全社共有や個人のOneDrive全体を接続しない
書き込み 専用の成果物フォルダー。元データや本番システムへの反映は人が実施
モデルへの送信 会社のAPIゲートウェイを通し、送信前の検査を必須にする
その他の通信 許可した接続先だけに限定。外部連携やプラグインも管理対象にする
記録 利用者、モデル利用量、実行と変更の履歴、DLP判定。ログの閲覧者と保存期間も限定する

ファイルの制限は、AIへのプロンプトに書くだけでなく、OSのアクセス権や分離した実行環境で実施します。プロンプトに書いた禁止事項は約束であって、制限ではありません。Codexの管理設定では、実行権限、承認、MCPなどの外部接続を制限できます。ただし、読み取り専用の設定は書き込みを止めるものであり、機密ファイルを読めなくする設定とは別です。

DLPは、ファイルの読み取りとAPIへの送信を分けて設計する

DLPは、個人情報や機密情報を検出し、許可しない利用や送信を止める仕組みです。公式資料を確認すると、この構成での適用範囲は次のように整理できます。

DLPを3段に分けた図。1段目は端末のEndpoint DLPで機密ファイルを読ませない、2段目は会社のAPIゲートウェイで送信前にPurviewの判定を待ち該当すれば送らない、3段目はネットワークDLPで通信を検査するが検査できない通信を許可する動作があるため唯一の防止策にはしない

Microsoft 365 Copilot用のDLPは、自動では引き継がれない

Microsoft 365 Copilot向けのDLPには、秘密度ラベルが付いたファイルの利用や、機密情報を含むプロンプトの処理を制限する機能があります。ただし、対象は指定されたCopilotの処理です。このポリシーを設定しただけで、Claude CodeやCodexの独自のAPI通信まで保護されるわけではありません。

FoundryにもPurview連携がありますが、現行の標準連携の説明では、ポリシー適用の条件としてユーザーコンテキスト付きのEntra認証と、管理された/chat/completionsエンドポイントが示されています。CodexのResponses APIやClaudeのMessages APIを、そのまま同じ対象とは扱えません。

Endpoint DLPは、機密ファイルを読ませないために使う

会社管理のWindowsやmacOSの端末にEndpoint DLPを導入すると、制限対象のアプリが保護ファイルへアクセスすることをブロックできます。AI作業に使わない機密区分のファイルを、エージェントから読み取れないようにする用途です。

ただし、制御は実際にファイルへアクセスするアプリを対象にします。エージェントが別のプログラムを起動して読む構成では、その経路も含めて制限する設計が必要です。さらに、Claude DesktopのCoworkのように、コードの実行を専用のLinux仮想マシンの中で行う機能もあります。その仮想マシンの中は、端末側のセキュリティツールから見えないというのがAnthropicの説明です。端末のファイルへのアクセスと、仮想マシンの中の処理は分けて検証する必要があります。そのため、この記事の構成では、Endpoint DLPに加えて、作業環境へ渡すファイルそのものを限定し、ゲートウェイの送信前検査と併用します。

また、Endpoint DLPのサービスドメインによるアップロード制御は、対応ブラウザーを対象とした機能です。これを設定するだけで、CLIのAPI通信を検査することにはなりません。

秘密度ラベルは対応ファイルのメタデータとして保持されます。しかし、暗号化を伴わないラベルもあり、別のプログラムで抽出した本文のAPI送信まで、自動的に制御される仕組みではありません。ファイルのラベルと、送信する本文の検査は、それぞれ必要です。

APIへの送信前検査は、会社の接続窓口で実施する

Microsoftは、アプリからPurviewのポリシーを評価できるAPIを公開しています。processContentはMicrosoft Graphのv1.0で提供され、対象ユーザーのポリシーに基づく判定を返します。ただし、ブロック判定を実際の送信停止につなげるのは、APIを呼ぶ側のアプリの役割です。

そこで、この構成ではAzure上のAPIゲートウェイに検査処理を組み込みます。利用者を認証し、送信予定の本文をPurviewへ渡して、判定が返るまでモデルへの転送を待ちます。機密情報の種類に基づく禁止ルールに該当すれば、モデルには送りません。利用者が入力したプロンプトだけでなく、読み取ったファイルの本文やツールの実行結果がモデルへの入力に加わる経路も、検査対象に含めます。

検査が失敗したとき、必要な送信前検査ポリシーの適用を確認できないとき、検査できない形式やサイズの入力が来たときも、送信を止める設計にします。ポリシーが空、または非同期の監査しか適用されていない場合も、そのまま通しません。初期導入は検査できるテキストやCSVなどに範囲を絞り、画像や未対応の添付形式を無条件には通しません。ゲートウェイを通らない直接接続はネットワーク側で遮断し、モデル側の認証情報も窓口側で管理します。

このゲートウェイは、公式APIを組み合わせて構築する設計案で、別途の開発が必要です。 API Managementを用意するだけでは完成しません。Responses APIとMessages APIの通信仕様に合わせ、継続する会話やツール呼び出しを保ったまま検査する実装にします。Entra登録アプリ向けのDLPルールは、現在、PowerShellで対象アプリへスコープして作成する方式です。当社がこの構成を特定の会社の環境で実装して検証した、という記事ではありません。公開仕様を読んで組み立てた設計として読んでください。

なお、AzureのContent Safetyによる有害表現やプロンプト攻撃の検査は、Purviewの機密情報ポリシーとは役割が異なります。これを有効にしたことだけで、機密情報のDLPを実装済みとは扱いません。

ネットワークDLPも使えるが、検査できない通信の扱いに違いがある

Microsoft Entra Global Secure AccessとPurviewを組み合わせると、ブラウザーに加え、アプリやAPIから送るHTTPやHTTPSの内容も検査できます。管理端末の通信を対象経路へ通し、TLS検査と対応するPurview DLPポリシーを設定する方式です。

一方、現行のGlobal Secure Access側の仕様では、Purview検査は最大3MB、OCRは非対応で、利用者をEntra IDに対応付けられない通信は検査されません。さらに、サイズ超過や内部エラーでPurviewが検査できない場合に通信を許可する動作があります。したがって、未検査の入力をモデルへ送らないことが要件なら、この機能だけを唯一の防止策にはできません。 この記事では、送信を停止できるAPIゲートウェイを中心に据えます。

DLPは、定義した機密情報を検出する制御です。すべての営業秘密を自動で理解するものではないため、機密区分によるファイル制限と送信前検査を組み合わせます。導入の完了条件も、通常の処理が動くことに加え、禁止データ、検査エラー、直接接続のそれぞれが止まることまで含めます。

モデルAPI以外の通信と、ローカルの記録も管理する

Azureにモデルの接続先を設定しても、Web検索、MCP、プラグイン、製品の利用状況送信まで一括してAzureへ切り替わるわけではありません。Codexには匿名の利用状況や稼働情報の送信設定があり、Claude Desktopにも停止できるテレメトリがあります。

この記事の初期構成では、不要な外部連携と利用状況送信を無効にし、必要な更新、認証、モデル接続先だけをネットワーク側で許可します。モデルへの送信はゲートウェイ、コマンドや外部連携の通信は実行環境の制御で管理する形です。Codexのコマンド用通信制御だけでは、MCPやアプリ全体の通信までは含まれないと公式資料にも明記されています。

会話履歴、生成物、ツール出力、監査ログも管理対象です。機密情報をログへ複製し過ぎないよう記録項目を絞り、必要なログはアクセス権と保存期間を設定します。

Azure OpenAIとFoundryのClaudeでは、契約条件が異なる

APIの送信経路を管理しても、送信後に適用されるサービス側の契約条件は変わりません。ここは、両者の違いを明確にしておきます。

Azure OpenAIを含むAzureが販売するモデルについて、Microsoftは、入力や出力をOpenAIなどのモデル提供者へ開示せず、許可なく基盤モデルの学習に利用しないと説明しています。

一方、Microsoft FoundryのClaudeは、Azure上でホストする方式でも、Anthropicが販売者と運営者であり、入力と出力の独立したデータ処理者です。適用されるのはAnthropicの契約条件です。Azureホストでは推論はAzureの基盤で行われますが、安全性システムが検知した内容がAnthropicの担当者による例外的な確認へ回る場合があります。Anthropicホストを選ぶと、推論自体がAnthropicの基盤で行われます。

Claude Codeの商用条件では、顧客がモデル改善のためにデータを提供する選択をしない限り、コードやプロンプトを生成モデルの学習に使わないとされています。ただし、学習に使わないことと、保存しないことは別です。 FoundryのClaudeは、新規のAzureサブスクリプションでは保持が有効とされ、保持設定はAnthropicが管理します。Azure OpenAIにも、状態を保持するAPI機能や、不正利用の監視に伴う保存があります。

処理地域についても結論があります。現在のFoundryのClaudeは、AzureホストでもGlobal Standardまたは米国のData Zone Standardで、日本国内だけで推論する要件を満たす選択肢ではありません。 Azure OpenAIは、地域を指定したデプロイなら指定した地理的区域内で処理されると説明されていますが、Globalデプロイでは国外処理があり得ます。使うモデルとResponses APIがその地域で提供されているかは、個別に確かめます。したがって、Azureなので国内で完結する、AzureなのでMicrosoftだけがデータを処理する、という説明はできません。

契約形態にも制限があります。CSPのAzureサブスクリプションは、現在FoundryのClaudeに非対応です。 CSPは販売パートナー経由の契約方式の1つです。Microsoft 365を販売店経由で購入していること自体とは別で、Claudeを利用するAzureサブスクリプションが対象になります。

どちらを選ぶか。判断の順番

ツールの好みより先に、会社の規程と契約で決まる部分があります。上から順に見ていくと、候補が絞れます。

確認すること 当てはまる場合
社内規程が、モデル提供者（Anthropic）による独立したデータ処理を認めない FoundryのClaudeは採用できない。Azure OpenAI経由のCodexが候補
Azureサブスクリプションが CSP 経由 FoundryのClaudeは現在使えない。契約の切り替えか、Codexの検討
認証だけ先に、Entra IDで利用者を確かめたい Claude Code → FoundryはEntra ID認証に対応。Codexの標準手順はAPIキー。ただし、この記事の送信前検査を必須にする構成では、どちらもゲートウェイが別に要る
両ツールを同じ窓口で利用者管理したい 会社のAPIゲートウェイを用意する。どちらもゲートウェイ接続を公式にサポート
日本国内だけで推論させたい FoundryのClaudeには、現時点で国内だけの推論を指定する選択肢がない。Azure OpenAI経由のCodexは、使うモデルとResponses APIで日本の地域限定デプロイが使えるかを個別に確認する

Claude Codeの操作感を優先したい、Codexの管理設定を使いたい、といった理由はこの表の後に来ます。先に表で落ちる構成は、どれだけ使いやすくても採用できません。

ターミナルに慣れていなくても使える

CLIと聞くと、黒い画面にコマンドを入力する姿を想像する人が多いはずです。ただ、操作画面は選べます。

Codexは、Azureへの接続設定を使うVS Code拡張に加え、組織のゲートウェイへ接続するWindowsとmacOSのデスクトップ構成も公式に案内されています。Claudeは、Claude DesktopをMicrosoft Foundryに接続し、アプリからClaude CodeやCoworkを使えます。いずれも、画面はアプリでもモデルの利用はAPIです。

経営陣や幹部が利用する場合は、こうした画面から指示を出し、途中の確認や成果物のレビューを行う構成が向いています。コマンドを打つのはAI側で、人は依頼と確認を担当する形です。

スマホについては、Foundryに接続するClaude Desktopの3Pモードは、Claudeのモバイルアプリやclaude.aiからのアクセスに対応していません。Azureの接続設定だけで、純正モバイルアプリと同じ作業を同期できる構成にはなりません。

PCとスマホから同じ作業環境を操作したければ、会社管理のWindows 365やAzure Virtual Desktopへ、Windows Appから接続する方法があります。ただし、スマホ向けのチャット画面ではなく、遠隔のPC画面を操作する使い方になります。

PCとスマホの両方が必要なら、この記事では専用の仮想デスクトップを作業場所にする構成を採ります。AIの実行とファイルは管理環境に置き、スマホはその画面へ接続する形です。利用者は外出先から途中の状態や成果物を確認できます。

ただし、仮想デスクトップで使うクライアントの動作条件は先に確かめます。特にCoworkは、WindowsではVirtual Machine Platformが必要で、ネストされた仮想化に対応しない仮想マシンやVDI環境では動かないと、Anthropicが明記しています。仮想デスクトップで使うなら、ネストされた仮想化に対応する構成を選び、起動とコードの実行まで試してから採用する順番です。

1つの業務で、効果と運用を確かめる

最初のテーマは、結果を検証しやすい業務が向いています。たとえば、毎月の売上CSVを集計し、経営会議用の資料の元データを作る業務です。

この業務で、ここまでの設計がどう動くかを追ってみます。

  1. データを渡す。 経理担当が、先月分の売上CSVを部門ごとに書き出し、顧客名を取引先コードに置き換えた試行用のコピーを、AI実行環境の入力フォルダーに置く。全社共有フォルダーは接続しない
  2. 処理を作らせる。 AI推進担当が、Claude CodeかCodexに、入力フォルダーのCSVを読み、列名の表記をそろえ、部門別と商品別の月次集計を成果物フォルダーへ保存するスクリプトを作らせる。この依頼の本文と、読み取ったCSVの中身は、会社のゲートウェイで送信前に検査される
  3. 結果を確かめる。 経理担当が、成果物の合計を会計システムの月次残高と見比べる。合わない列があれば、その理由をAI推進担当がAIに調べさせ、スクリプトを直す
  4. 止まることも確かめる。 情報システム担当が、設定した検出ルールに確実に該当する合成データを使い、3つの試験を分けて行う。端末で読み取りが止まるか。隔離した検証環境からゲートウェイまで届けて、モデルへの転送が止まるか。ゲートウェイを通らない直接接続が遮断されるか。それぞれの判定の記録を見る
  5. 費用と時間を記録する。 処理に使ったトークン量と費用、作成にかかった時間、確認と修正にかかった時間を分けて記録する

少人数で試すときに見るのは、処理にかかった時間だけではありません。結果の確認や修正にかかった時間、データの取り扱い、利用費用まで見ます。AIが処理を終えたことと、業務に使える品質になったことを分けて評価するためです。4番目の「止まることの確認」を飛ばすと、通常の処理が動いただけで導入完了と見なしてしまいます。

この設計を会社に入れるときの順番は、次のとおりです。

  1. 利用する人、対象業務、扱うデータを決める
  2. 利用できるAzure契約とモデルを選び、管理された実行環境と認証ゲートウェイを用意する
  3. Endpoint DLPと送信前検査を設定し、コピーした許可データで処理を作る
  4. 集計結果だけでなく、禁止データと検査失敗と直接接続が止まること、利用者の追跡、利用費用も検証する
  5. 再現性を確認できた処理から、実務で使う範囲を広げる

追加するライセンスと費用も整理しておく

Microsoft 365 Business Premiumを使っている場合、基本的なDLPとEndpoint DLPは分けて考えます。基本的なDLPはExchange Online、SharePoint、OneDrive向けで、Endpoint DLPは端末向けです。Business PremiumだけではEndpoint DLPは足りず、Microsoft Purview Suite for Business Premiumなどの追加が必要です。

費用の対象 この記事の構成での扱い
Microsoft 365 Business Premium 全社員の標準環境。基本的なDLPや端末管理の土台
Purview Suite for Business Premiumなど Endpoint DLPを使う対象者へ追加。保護の適用を受けるユーザーに必要な権利を付与
Azure OpenAI、Foundry Claude Microsoft 365とは別のモデルAPI利用料
Purviewのカスタムアプリ連携 Entra登録アプリ向けの従量課金を有効化
APIゲートウェイと検査処理 構築と運用の費用と、利用するAzureリソースの費用
専用PC、仮想環境 端末、仮想マシン、ストレージなどの費用

Purviewの追加ライセンスは、情報システムの担当者1人に付ければ全員を保護できるものではありません。少人数に限定する場合は、利用者と保護ポリシーの対象範囲をそろえます。カスタムAIアプリのPurview連携には、従量課金の有効化が必要です。

ネットワークDLPも追加する場合は、Purview E5相当とEntra Internet Access相当のライセンスが必要です。Global Secure Accessとの連携については、Purviewの従量課金設定は不要とされています。これは、前述のカスタムアプリへのAPI組み込みとは別の課金条件です。

利用量に対しては、Azureの予算通知と、ゲートウェイ側の利用上限を併用します。Azureの予算設定は通知のための仕組みで、到達時に自動で消費を止めるものではありません。 少人数でも反復処理でAPI利用量は増えるため、利用者別の回数とトークンの上限と、超過時に止める処理を窓口側に実装します。

検証した仕組みを、社内へ展開する

少人数で始める利点は、その人たちの仕事を速くすることだけではありません。試作と検証を担う人を決めることで、使える処理を会社の仕組みとして残しやすくなります。

たとえば、AI推進担当がデータの整理と加工の処理を作り、経理担当と結果を確認する。安定して使えるようになったら、社員が必要なときに実行できるツールや、承認された定期処理として整える。全社員がClaude CodeやCodexを直接操作しなくても、改善の成果は全社で使えます。

Microsoft 365を日常業務の基盤として維持しながら、業務改善を担う少人数に、AzureのモデルAPIを利用する実行環境を用意する。利用者、ファイル、送信経路を限定し、成果物を確認してから社内へ広げる。全社員が使う環境と、改善を試作する人の環境を分ければ、Microsoft 365を中心にした情報管理と、Claude CodeやCodexによる業務改善を、1つの設計の中に収められます。

KOIYALの見解

基本的にはM365のCopilotの性能は上がりましたし、できることもものすごく増えました。M365環境のツールを組み合わせるだけでも多くのことができます。

しかし、Claude CodeやCodexならではの便利さやノウハウも存在します。特にAIを使えば使うほど単一のエージェントになんでも頼める良さが手放せなくなると思います。

そのため、セキュアな環境を保ちつつも使いたいときだけ使うという方法をおすすめしました。

もう1つ、当社が強調したいのは、この環境が業務改善を担う人を育てる場所になることです。AI推進担当が集計の処理を作り、経理担当と結果を見比べ、使えると分かった処理を定期処理として整える。この往復を社内で回せるようになった定型処理については、外部に頼んでいた作業の一部を自社で担えます。基盤の構築と保守をどこまで内製するかは、別に判断することです。インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）は、全社員がCLIを操作することではありません。改善を試作する少人数と、その成果を使う全社員の役割分担から始まると、当社は考えています。

設計は書けても、ゲートウェイの実装、Purviewの設定、Azure契約の確認は、会社ごとに条件が違います。この記事の表で落ちる構成が自社にないか、まずそこから確かめてください。

次の行動

  1. 社内規程で、モデル提供者による独立したデータ処理を認めているかを確かめる。認めていなければ、候補はAzure OpenAI経由のCodexに絞られる
  2. 自社のAzureサブスクリプションの契約方式（CSP経由かどうか）を、契約書か販売店に確かめる
  3. 最初の1業務と、その業務で渡してよいデータ、確認を担当する人を1組決める

3つが書けたら、それを持って相談に来てください。AI・DXコンサルティングの初回の打ち合わせでは、利用者、実行場所、送信経路の3点を、自社の契約と規程に合わせて一緒に決めます。ゲートウェイの構築と運用まで含めて社内に残したい会社には、FDE型支援で当社が実装まで担当する形です。お問い合わせの本文に、Microsoft 365のプランと、最初に任せたい業務を1つ書いていただければ、初回の前に当社で候補の構成を仮置きします。

参考