Mistral Document AI（with OCR 4）と Mistral Medium 3.5 が Microsoft Foundry に追加されたことで、管理者がまず確認すべきなのは「使えるようになったか」ではなく、誰がデプロイできるか、どのデータを処理してよいか、既存の Document AI ワークロードを移行すべきか、監査ログと費用を追えるかです。
今回の更新は、公式発表上の分類としては Notice であり、直ちに全環境で破壊的変更が発生するタイプの告知ではありません。ただし、文書OCR、構造化抽出、RAG、エージェント、コーディング支援に関わるモデル選択肢が増えるため、Microsoft Foundry の管理者は、PoC 利用を許可する前に権限・課金・監査・データ分類のルールを確認しておく必要があります。Microsoft Foundry Blog では 2026年6月下旬の更新として、Mistral Document AI（OCR 4）と Mistral Medium 3.5 の追加が案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
今回の更新で管理者が押さえるべきポイント
今回の発表で重要なのは、Microsoft Foundry における Mistral 系モデルの使い分けが広がったことです。Mistral の Azure 向けドキュメントでは、Microsoft Azure AI 上で利用できるモデルとして Mistral Medium 3.5 と Document AI（with OCR 4） が含まれており、MaaS のサーバーレスAPIデプロイや、GPUインフラに紐づくリアルタイムエンドポイントという利用形態が説明されています。(Mistral AI Documentation)
| 確認項目 | 管理者が見るべきポイント | 放置した場合のリスク |
|---|---|---|
| モデル追加 | Document AI（with OCR 4）と Mistral Medium 3.5 の利用可否 | 部門ごとに無統制なPoCが始まる |
| 権限 | デプロイ権限、推論権限、APIキー利用の扱い | 誰が使ったか追跡しにくくなる |
| データ分類 | OCR対象のPDF、画像、契約書、請求書、個人情報 | 機密文書を不適切な経路で処理する |
| 監査 | Azure Monitor、Log Analytics、アプリ側ログ | コスト増・障害・情報漏えい調査に対応できない |
| 移行 | 既存の mistral-document-ai-2505 などの利用状況 | モデル引退前に切り替えが間に合わない |
| 周知 | 開発者・業務部門への利用ルール | OCR結果を確定情報として扱ってしまう |
特に注意したいのは、OCR 4 が単なる文字起こしではなく、文書構造を扱うモデルとして位置付けられている点です。Mistral OCR 4 は、抽出テキストに加えてバウンディングボックス、ブロック分類、信頼度スコアを返し、170言語に対応すると説明されています。RAG、エンタープライズ検索、帳票処理などに使いやすい一方で、出力形式が変わると既存の後続処理にも影響します。(Mistral AI)
Mistral Document AI（with OCR 4）は何に効くのか
Mistral Document AI（with OCR 4）は、PDFや画像化された文書からテキストを抽出するだけでなく、表、見出し、数式、署名、画像領域などの構造を扱う用途に向いています。Mistral の説明では、OCR 4 は各ブロックの位置情報、種類、ページ単位・単語単位の信頼度スコアを返すため、後続の検索、引用、確認作業に活用しやすいとされています。(Mistral AI)
実務では、次のような用途で検討しやすくなります。
| 利用シーン | 向いている理由 | 管理者の確認点 |
|---|---|---|
| 請求書・見積書の読み取り | 金額、日付、取引先、明細などを構造化しやすい | 誤読時の承認フローを用意する |
| 契約書レビュー支援 | 条項、見出し、署名欄、別紙を分解しやすい | 法務判断をAIだけに任せない |
| 社内ナレッジ検索 | PDF資料をRAG向けに分割しやすい | 機密ラベルとアクセス制御を維持する |
| 監査・コンプライアンス資料整理 | 参照元ページや位置を追いやすい | 出典ページ、抽出日時、モデル名を記録する |
| 手書き・スキャン文書の一次処理 | 画像化された資料のデジタル化に使える | 低品質スキャンの検証データを用意する |
ただし、OCR 4 は文書理解モデルであり、医療診断、法的判断、高リスクな金融判断、安全クリティカルな意思決定などの「判断者」として使うものではない、と Mistral 側も用途外の例を明示しています。管理者は「抽出・整理・候補提示」までをAIの役割とし、最終判断は人間または既存の承認プロセスに戻す設計にしてください。(Mistral AI)
Mistral Medium 3.5はどこで使うべきか
Mistral Medium 3.5 は、文書抽出そのものよりも、抽出後の要約、推論、コード生成、エージェント処理に向いたモデルです。Mistral の公式情報では、Mistral Medium 3.5 は命令追従、推論、コーディングを単一の重みで扱う 128B の dense モデルで、256k コンテキストウィンドウを持つと説明されています。(Mistral AI)
管理者向けには、次のように役割を分けると整理しやすくなります。
| モデル | 主な役割 | 使いどころ |
|---|---|---|
| OCR 4 | 文書からテキスト・構造・位置・信頼度を抽出 | PDF、画像、帳票、スキャン文書の取り込み |
| Document AI（with OCR 4） | 抽出結果を業務スキーマに合わせて構造化 | 請求書JSON化、契約書項目抽出、帳票分類 |
| Mistral Medium 3.5 | 抽出後の推論、要約、コーディング、エージェント処理 | RAG回答、ワークフロー自動化、開発支援 |
実務上の判断基準は明確です。文書を正確に取り込む段階では Document AI / OCR 4、取り込んだ情報を使って推論・要約・処理する段階では Mistral Medium 3.5 を候補にします。OCRモデルに複雑な業務判断まで担わせたり、汎用LLMだけでPDF構造を無理に読み解かせたりすると、精度検証や監査が難しくなります。
最初に確認すべき管理者チェックリスト
Microsoft Foundry の管理者は、モデルを試す前に以下を確認してください。
| 優先度 | 確認事項 | 具体的な確認内容 |
|---|---|---|
| 高 | 利用可能リージョン | 自社のデータ所在地、リージョン制約、ネットワーク要件に合うか |
| 高 | デプロイ権限 | 誰がモデルをデプロイできるか。Owner / Contributor を広く付けすぎていないか |
| 高 | 推論権限 | 開発者、アプリ、マネージドIDに必要最小限の権限だけを付与しているか |
| 高 | ライセンス・利用条件 | Mistral Medium 3.5 のモデル固有条件を法務・購買が確認したか |
| 高 | 監査ログ | Azure Monitor、診断設定、アプリ側ログで利用状況を追えるか |
| 中 | コスト | ページ単位課金、トークン課金、バッチ処理の費用を見積もったか |
| 中 | 既存モデルの移行 | mistral-document-ai-2505 などの利用有無を棚卸ししたか |
| 中 | 精度検証 | 日本語、縦書き、表、印影、手書き、低解像度スキャンで評価したか |
| 中 | 業務周知 | AI出力の確認ルール、禁止データ、問い合わせ先を明文化したか |
この中でも、権限、データ分類、監査ログは先に固めるべきです。モデルの精度検証は後からでも改善できますが、機密文書を誰がどこに投入したか分からない状態は、後から修正しにくいためです。
権限管理：APIキー前提の運用を避ける
Microsoft Foundry では Microsoft Entra ID と APIキーの両方が扱われますが、本番運用では Entra ID を軸にした認証・認可へ寄せるべきです。Microsoft の認証・認可ドキュメントでは、Entra ID は条件付きアクセス、マネージドID、細かなRBACに適しており、本番ワークロードで推奨されています。一方、APIキーは迅速な試作には便利ですが、ユーザー単位の追跡や細かなスコープ制御が難しいとされています。(Microsoft Learn)
推論を行う開発者やアプリには、Foundry リソースのスコープで必要なロールを割り当てます。Microsoft の keyless authentication の手順では、推論APIを呼び出す開発者には Cognitive Services User ロールが必要で、認証設定を行う管理者にはロール割り当てを操作できる権限が必要と説明されています。(Microsoft Learn)
権限設計の実務ルール
| 対象 | 推奨する扱い | 避けたい状態 |
|---|---|---|
| 開発者 | セキュリティグループ経由で推論権限を付与 | 個人に直接ロールを乱発する |
| 本番アプリ | マネージドIDまたはサービスプリンシパルを利用 | APIキーをアプリ設定に長期保存する |
| PoC環境 | 期限付き・対象モデル限定で許可 | 本番データを自由に投入できる |
| デプロイ権限 | 少数の管理者またはプラットフォームチームに限定 | Contributor を広範囲に付与する |
| APIキー | 短期検証用に限定し、保管・ローテーションを明文化 | GitHub、Teams、Wikiに貼り付ける |
モデルデプロイを組織的に制御したい場合は、Azure Policy の利用も検討します。Microsoft Learn では、Foundry portal で開発者がデプロイできるAIモデルを Azure Policy で制御できると説明されています。(Microsoft Learn)
ライセンスと利用条件：Mistral Medium 3.5は法務確認が必要
Mistral Medium 3.5 は、オープンウェイトである点が魅力ですが、企業利用では「オープンウェイトだから自由に使える」と短絡しないことが重要です。Microsoft のモデル固有条件では、Mistral モデルは Mistral AI が開発したモデルであり、Microsoft Foundry Models での利用には追加条件が適用されると説明されています。さらに Mistral-Medium-3.5 については、一定の月次売上を超える企業には追加の制限が記載されています。(Microsoft Learn)
管理者は、次の確認を法務・購買・セキュリティ部門と行ってください。
| 確認項目 | 見るべき内容 |
|---|---|
| 利用主体 | 自社、子会社、顧客向けSaaS、受託開発のどれに該当するか |
| 収益条件 | モデル固有条件の売上制限や商用ライセンス要否 |
| 派生物 | ファインチューニング、蒸留、組み込み利用の可否 |
| 顧客提供 | エンドユーザーにAI機能として提供する場合の条件 |
| 出力の扱い | 生成結果の責任、第三者権利侵害、免責条項 |
PoCでは問題にならなくても、本番化や顧客向け提供の段階で条件に引っかかることがあります。特に Mistral Medium 3.5 をエージェント基盤や開発支援基盤の標準モデルにする場合は、技術評価と同時に契約評価を進めるべきです。
監査とログ：モデル名・文書数・利用者を追える状態にする
Document AI や OCR は、扱うデータが契約書、請求書、本人確認資料、医療・金融関連資料に近づきやすい領域です。そのため、通常のチャットモデル以上に「誰が、どのアプリから、どのモデルで、何ページ処理したか」を追跡できる設計が必要です。
Microsoft Foundry Models の監視では、Foundry portal のメトリック表示に加え、Azure Monitor の診断設定を使って Log Analytics にログやメトリックを送る構成が説明されています。診断設定ではログカテゴリや AllMetrics を選び、Log Analytics ワークスペースへ送信できます。コストデータは Azure Cost Management から確認できますが、課金イベントから表示まで遅延がある点にも注意が必要です。(Microsoft Learn)
アプリ側で記録したい項目
Azure側のメトリックだけに頼らず、業務アプリ側でも最低限の監査情報を残します。
| ログ項目 | 記録する理由 |
|---|---|
| 利用者IDまたはアプリID | 不正利用・問い合わせ時の追跡 |
| モデル名とデプロイ名 | モデル変更による精度差を追う |
| リクエスト日時 | 障害・費用・監査の突合 |
| 文書種別 | 請求書、契約書、社内資料などの分類 |
| ページ数・ファイルサイズ | コスト増加の原因分析 |
| 抽出スキーマのバージョン | 後続処理の不整合確認 |
| 信頼度スコアのしきい値 | 人手確認に回した理由の説明 |
| エラーコード | 再試行、容量制限、権限問題の切り分け |
| 人手確認の結果 | OCR誤読やモデル更新の品質評価 |
注意点として、監査目的で文書本文やOCR結果をすべて保存すればよいわけではありません。個人情報や機密情報を含む可能性が高いため、保存範囲、保持期間、マスキング、アクセス権を先に決めます。ログには本文そのものではなく、文書ID、分類、ハッシュ、処理結果ステータスを残す設計が現実的です。
データ保護：OCR対象文書の分類を先に決める
Mistral OCR 4 は、文書データをRAGや検索に取り込む入口になり得ます。入口の制御が甘いと、本来アクセス権のない文書が検索インデックスやエージェントの知識に混入します。
管理者は、少なくとも次の3分類で利用可否を決めてください。
| データ分類 | 例 | 推奨ルール |
|---|---|---|
| 利用可 | 公開済み資料、社内一般マニュアル、製品カタログ | PoC利用可。ただし出典管理を行う |
| 条件付き可 | 契約書、請求書、社内議事録、顧客対応履歴 | 承認済みアプリ、指定リージョン、ログ有効化が条件 |
| 原則不可 | 本人確認書類、医療情報、未公開決算情報、認証情報を含む文書 | 例外承認と専用設計なしに投入しない |
また、OCR 4 は自社インフラでのセルフホストにも対応すると説明されていますが、Microsoft Foundry 経由で使う場合のデータ所在地、ネットワーク、ログ、契約条件は別途確認が必要です。Mistral は、厳格なデータプライバシー要件を持つ組織向けにセルフホストの選択肢を示しています。(Mistral AI)
移行確認：既存のMistral Document AI利用を棚卸しする
今回の追加とは別に、既存モデルのライフサイクルも確認が必要です。Microsoft Learn のモデル引退スケジュールでは、mistral-document-ai-2505 は 2026年7月15日が退職日として示され、置換候補として mistral-document-ai-2512 と mistral-ocr-4-0 が記載されています。mistral-document-ai-2512 についても、置換として mistral-ocr-4-0 が示されています。(Microsoft Learn)
既に Mistral Document AI を使っている場合は、次の順序で移行計画を作ると安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | どのアプリがどのモデル名を呼んでいるか確認 | デプロイ名、エンドポイント、所有者が一覧化されている |
| サンプル抽出 | 実文書に近いPDF・画像を30〜100件用意 | 帳票、表、手書き、低解像度を含む |
| 比較テスト | 旧モデルと新モデルで抽出結果を比較 | 主要フィールドの一致率と差分が分かる |
| スキーマ確認 | JSON項目、型、必須項目、信頼度の扱いを確認 | 後続処理が失敗しない |
| 人手確認 | 誤読しやすい項目を業務担当者が確認 | 許容できる誤差基準が決まる |
| コスト試算 | ページ数、バッチ有無、再処理率をもとに試算 | 月額上限とアラート条件が決まる |
| 段階移行 | 一部部門または一部帳票から切り替え | ロールバック手順がある |
| 本番切替 | 旧デプロイ停止日を設定 | 旧モデル呼び出しが残っていない |
移行で失敗しやすいのは、OCR精度だけを見て後続のJSONスキーマ差分を見落とすパターンです。たとえば、金額欄の文字認識は改善していても、明細行の配列構造や日付形式が変わると、会計システム連携でエラーになります。モデル比較では「人間が読めるか」だけでなく、「既存の自動処理が壊れないか」を必ず確認してください。
日本語文書で検証すべきポイント
OCR 4 は多言語対応をうたっていますが、日本語圏の実務文書では独自の難しさがあります。日本語、英数字、記号、印影、罫線、縦書き、手書きが混在するため、英語PDFのベンチマークだけで判断しないことが重要です。
日本語環境でのテスト観点
| テスト対象 | 確認ポイント |
|---|---|
| 請求書 | 金額、税率、登録番号、振込先、明細行の分割 |
| 契約書 | 条番号、別紙、表、署名欄、押印欄 |
| 申込書 | 手書き文字、チェックボックス、住所、電話番号 |
| 稟議書 | 複数ページ、承認欄、部署名、日付 |
| スキャンPDF | 傾き、かすれ、解像度不足、影 |
| 縦書き資料 | 読み順、見出し、脚注、表との混在 |
| 旧字体・異体字 | 人名、地名、法人名の誤変換 |
| 表形式 | セル結合、罫線なし表、複数明細の順序 |
検証では、単純な正解率だけでなく、業務影響を重み付けします。たとえば、会社名の表記ゆれよりも、金額、日付、口座番号、契約期間の誤読のほうが重大です。信頼度スコアが低い項目は自動処理せず、人手確認へ回すルールを作ると実運用に乗せやすくなります。
コスト管理：ページ課金とトークン課金を分けて考える
Document AI / OCR 系はページ単位の処理量がコストに直結しやすく、Mistral Medium 3.5 のようなLLMは入力・出力トークン量がコストに効きます。つまり、文書処理パイプラインでは「OCRのページ数」と「抽出後にLLMへ渡すテキスト量」の両方を管理しなければなりません。
Mistral のOCR 4発表では、OCR 4 API は1,000ページあたりの価格、Batch API 割引、Document AI の価格が示されています。ただし Microsoft Foundry 経由の最終的な課金は、利用リージョン、提供形態、Azure側の価格表、契約条件により変わる可能性があるため、必ず Azure 側の価格表示と見積もりで確認してください。(Mistral AI)
コストが膨らみやすいパターン
| パターン | なぜ増えるか | 対策 |
|---|---|---|
| 全社ファイルサーバーを一括OCR | ページ数が膨大になりやすい | 対象フォルダーを限定し、段階実行する |
| OCR結果を毎回LLMへ全文投入 | 長文コンテキストでトークンが増える | 必要ブロックだけ抽出して渡す |
| 失敗時に無制限リトライ | 同じ文書を何度も処理する | リトライ回数と重複処理防止IDを設定 |
| 低品質スキャンを大量投入 | 誤読・再処理・人手確認が増える | 事前に解像度・傾き補正を行う |
| PoC環境を放置 | 検証後も処理が継続する | 期限付きリソース、予算アラートを設定 |
管理者は、月間ページ数、平均ページサイズ、抽出後にLLMへ渡す平均文字数、再処理率を使って試算します。最初から全社展開せず、1部門・1帳票・1ワークフローに限定して、実測値を取ってから拡大するのが安全です。
Responsible AIとコンテンツ安全性の確認
Microsoft Foundry のモデル利用では、コンテンツフィルタや Responsible AI の考え方も確認が必要です。Microsoft Learn では、Foundry Models のコンテンツフィルタリングは Azure AI Content Safety によって支えられ、入力プロンプトと出力補完を分類モデルに通すと説明されています。(Microsoft Learn)
ただし、文書OCRでは「有害コンテンツをブロックする」だけでは不十分です。契約書や請求書のOCRでは、むしろ次のような業務リスクを管理する必要があります。
| リスク | 例 | 対策 |
|---|---|---|
| 誤抽出 | 金額、日付、契約期間を誤る | 重要項目は人手確認へ回す |
| 過剰抽出 | 本来不要な個人情報まで取り込む | 抽出スキーマを最小化する |
| 権限逸脱 | 閲覧権限のない文書が検索対象になる | インデックス作成時にACLを引き継ぐ |
| 出典不明 | 回答の根拠ページが分からない | ページ番号、座標、文書IDを保存する |
| 自動判断 | OCR結果から支払い・否認を自動決定する | 承認者を挟むワークフローにする |
AI安全性の設定は、モデルの種類やデプロイ形態によって使える機能が異なる場合があります。Microsoft Learn のデプロイ概要では、標準デプロイ、サーバーレスAPIエンドポイント、マネージドコンピュートで、Private networking、Content filtering、keyless authentication などの対応に差があることが示されています。(Microsoft Learn)
開発者・業務部門へ周知すべき内容
管理者だけがルールを理解していても、現場が知らなければ統制は効きません。新しいモデルを許可する場合は、開発者と業務部門に短いルールを配布します。
周知文に入れるべき項目
| 項目 | 伝える内容 |
|---|---|
| 利用目的 | Document AI / OCR 4 は文書抽出、Mistral Medium 3.5 は推論・要約・エージェント用途 |
| 禁止データ | 未承認の個人情報、認証情報、未公開重要情報は投入禁止 |
| 承認フロー | 本番利用前にセキュリティ、法務、業務責任者の確認が必要 |
| 精度の扱い | OCR結果は必ず誤読の可能性がある |
| コスト | ページ数・トークン数に応じて課金される |
| ログ | 利用者、モデル名、ページ数、処理日時を記録する |
| 問い合わせ先 | モデル申請、障害、精度問題、費用相談の窓口 |
特に業務部門には、「OCRできた＝正しい」ではないことを強調します。AIの出力は入力品質、文書レイアウト、スキャン状態、モデル更新、プロンプトやスキーマに左右されます。高額支払い、契約締結、法的判断、人事判断などに直結する処理は、人間の確認を前提にします。
導入前の実務的な判断基準
Mistral Document AI（with OCR 4）と Mistral Medium 3.5 は強力な選択肢ですが、すべての文書処理を置き換える必要はありません。次の基準で採用可否を判断すると、過剰導入を避けられます。
| 判断基準 | 採用しやすいケース | 慎重にすべきケース |
|---|---|---|
| 文書量 | 月数千〜数十万ページの処理がある | 月数十ページで手作業でも十分 |
| 文書構造 | 表、欄、署名、画像、複数言語が多い | プレーンテキスト中心 |
| 後続活用 | RAG、検索、ワークフロー連携に使う | OCR結果を目視するだけ |
| 精度要件 | 人手確認込みで改善できる | 1文字の誤読も許されない |
| 監査要件 | 出典ページ・処理履歴を残せる | ログ保存が制限されている |
| 権限管理 | Entra ID、RBAC、監査設計が整っている | APIキーを共有する運用しかない |
現時点で最も現実的な導入パターンは、いきなり全社展開するのではなく、1つの帳票、1つの部門、1つの検索基盤に限定して評価することです。そこで、抽出精度、処理時間、費用、運用負荷、監査ログの取りやすさを確認し、合格基準を満たしたものから広げます。
管理者が次に取るべき行動
今回の Microsoft Foundry への Mistral Document AI（with OCR 4）と Mistral Medium 3.5 の追加は、文書処理とエージェント活用の幅を広げる更新です。一方で、文書OCRは機密データに触れやすく、モデル移行やライセンス条件、監査設計も関係します。
まずは、次の5つを実施してください。
| 順番 | 実施内容 |
|---|---|
| 1 | Microsoft Foundry 内で Mistral Document AI / OCR 4 / Mistral Medium 3.5 の利用可否とリージョンを確認する |
| 2 | デプロイ権限と推論権限を棚卸しし、Entra ID とセキュリティグループ中心に整理する |
| 3 | 既存の mistral-document-ai-2505 利用有無を確認し、退職日までの移行計画を作る |
| 4 | Azure Monitor と Log Analytics、アプリ側ログで監査・費用・エラーを追えるようにする |
| 5 | 業務部門向けに、投入可能データ、確認ルール、禁止用途、問い合わせ先を周知する |
モデル追加のニュースとして読むだけでなく、「誰が使えるか」「何を処理してよいか」「どのログを残すか」「いつ旧モデルを止めるか」まで決めることが、Microsoft Foundry 管理者にとっての実務対応です。
コメント