Microsoft MAI-Thinking-1とMAIファミリー7モデル——OpenAI依存を切る独自AI戦略

Microsoft Build 2026で、AIモデルの調達地図が静かに書き換わった。MicrosoftのAI Superintelligence Teamが、自社開発の7モデル群「MAIファミリー」を発表したからだ。

中心は同社初の本格reasoningモデルMAI-Thinking-1。盲検の人間評価でClaude Sonnet 4.6を上回り、SWE-Bench ProではClaude Opus 4.6並みと主張する。

本記事は、Microsoft公式・CNBC・Neowinなどの一次〜二次ソースを軸に、確報とベンダー主張を切り分けて整理する。そのうえで、Azure顧客の調達戦略にどう効くかまで通しで示す。

LLMの仕組みや主要モデルの全体像から押さえたい場合は、ピラー記事 LLMとは？仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 に整理してある。本記事はその中の「主要モデルの最新動向」を深掘りする位置づけだ。

30秒で理解する

まず全体像を箇条書きで押さえる。詳細は各H2で一次ソースとともに展開する。

・Microsoft AI Superintelligence Teamが独自開発した7モデル群「MAIファミリー」をBuild 2026で発表した
・主力 MAI-Thinking-1：35B activeのSparse MoE、256Kコンテキスト、商用ライセンス済みデータでゼロディスティレーション学習
・盲検の人間評価でClaude Sonnet 4.6超え、SWE-Bench ProでOpus 4.6並みとMicrosoftが主張（独立再現は未確認）
・Microsoftが「OpenAI囲い込みからの脱却」を本格化、Azure採用企業の調達戦略の前提が変わる
・提供はMicrosoft Foundry中心で、MAI-Thinking-1はprivate preview、軽量coding系は当日から利用可能

ここで一度、事実と主張の境界を明示しておく。7モデルの発表と提供形態は公式確報、ベンチでの「Sonnet 4.6超え・Opus 4.6並み」はMicrosoft自身の評価設定での主張だ。この区別は記事全体で保つ。

何が発表されたか

Build 2026は「Be yourself at work」をテーマに、AIエージェントを業務へ溶け込ませる発表が並んだ。その土台として、Microsoftは推論を支えるモデル層を自前で握る姿勢を鮮明にした。

CNBCの報道によれば、今回の発表の戦略的な核心はOpenAIへの依存を弱め、コストを下げることにある。MicrosoftはこれまでAzure上でOpenAIのGPT系を主力に据えてきたが、その一本足を是正する動きだ。

この動きは突然ではない。Microsoftは前年から音声のMAI-Voice、画像のMAIシリーズと自社モデルを段階的に投入してきた。今回のBuild 2026は、その積み上げの先に「reasoning」という最も難度の高い領域まで自社モデルを揃えた、という到達点に当たる。reasoningは推論コストが最も嵩む領域でもあり、ここを内製化できる意味は経済的にも大きい。

公開された7モデルは、用途別に並ぶ。reasoning、coding、画像生成、音声合成、文字起こしと、業務で必要なモダリティをひと通り自社で揃えた格好だ。

・MAI-Thinking-1：主力reasoningモデル。35B active Sparse MoE、256K
・MAI-Code-1 / MAI-Code-1-Flash：GitHub最適化のコーディングモデル
・MAI-Image-2.5（＋Flash）：text-to-image / image-to-image
・MAI-Voice-2（＋Flash）：15言語以上に対応した音声合成
・MAI-Transcribe-1.5：43言語の文字起こし

これらはMicrosoft Foundry（旧Azure AI Foundry）・GitHub Copilot・Windowsに直接組み込まれ、GPT-5系や他社モデルに対する「ファーストパーティの代替」として位置づけられる。

GitHub Copilotがネイティブアプリ化し、デフォルトモデルの刷新まで進んだ流れは、別記事 GitHub Copilotがネイティブアプリ化、デフォルトモデルもPolarisへ——Build 2026の主戦場 で詳しく扱った。本記事はその「モデル側」を補完する位置づけだ。

MAI-Thinking-1：reasoningモデルの中身

最も注目されているのが、Microsoft初の本格的なreasoningモデルMAI-Thinking-1だ。スペックを一次情報ベースで整理する。

・アーキテクチャ：Sparse MoE。約1T総パラメータのうち35Bがactive
・コンテキスト：256Kトークン
・学習データ：商用ライセンス済みのエンタープライズグレードデータ
・学習方式：ゼロディスティレーション（他社モデルからの蒸留なし）
・提供：Microsoft Foundryのprivate preview（早期パートナー向け）
・API：OpenAI Chat Completions互換エンドポイント

Sparse MoE（Mixture of Experts）は、巨大なモデルの中から入力に応じて一部の「専門家（expert）」だけを起動する方式だ。全パラメータを毎回使わないため、規模を上げつつ推論コストと速度を抑えやすい。

MAI-Thinking-1の「35B active / 約1T total」という数字は、まさにこのMoEの特徴を表す。総容量は1兆規模だが、1トークンの生成に実際に動くのは35B分。これが低トークンコストでの高性能という同社の主張の技術的な裏づけになっている。

学習面で強調されるのが「ゼロディスティレーション」だ。GPTなど他社モデルの出力を教師データに使わず、ライセンスの明確なデータだけでゼロから学習した、という主張である。これは出力の来歴（provenance）を明確にし、エンタープライズでの権利関係リスクを下げる狙いだ。

推論時間の制御も特徴とされる。reasoningモデルは「考える時間」を増やすほど難問の正答率が上がる傾向があり、MAI-Thinking-1も推論の深さを調整できる設計とされる。ただし制御APIの詳細はprivate preview段階で限定的だ。

「ゼロディスティレーション」をここまで前面に出す背景には、エンタープライズAIの「サプライチェーン」問題がある。他社モデルの出力で学習したモデルは、その出力に潜む権利関係や利用規約の制約を間接的に引き継ぎかねない。来歴を遡れないことが、規制業種の調達では減点要因になる。

Microsoftはこの来歴の不透明さを逆手に取り、「学習データの出どころが説明できる」ことを売りにした。reasoningモデルの中身という技術論の裏で、実は「誰のデータで、どんな権利のもとに作られたか」という調達側の関心に応える設計になっている。

MoEを採る理由も、単なる性能だけではない。35B activeという軽量な実効サイズは、推論を動かすGPU/アクセラレータのコストを直接押し下げる。Microsoftが自社のMaia系アクセラレータ上での効率を狙ううえで、巨大密モデルより制御しやすい。

MAI-Code-1：コーディング特化

開発者に直接効くのが、GitHub向けに最適化されたコーディングモデルMAI-Code-1系だ。とくに軽量版のMAI-Code-1-Flashは入手性が高い。

・MAI-Code-1：推論効率重視のコーディングモデル。CopilotとVS Codeで利用可能
・MAI-Code-1-Flash：5Bパラメータ。GitHub Copilot全有料プランに当日ロールアウト
・ベンチ：MAI-Code-1-FlashはClaude Haiku 4.5を4つの主要コーディングベンチで上回ると主張
・SWE-Bench Pro：Haiku 4.5に対し16ポイントリード、複雑タスクで60%少ないトークン
・提供：Copilot / VS Code / OpenRouter経由

SWE-Bench Proは、実際のGitHubリポジトリのIssueを解かせる実務寄りのベンチマークだ。関数単位の小課題（HumanEvalなど）と違い、リポジトリ全体を理解してパッチを当てる能力を測る。

MicrosoftはMAI-Thinking-1について、このSWE-Bench ProでClaude Opus 4.6のコーディング能力に匹敵すると主張する。最上位クラスのモデルと「並ぶ」という強い主張だ。

注意したいのは、MAI-Code-1とProject Polarisの関係だ。Polarisは前掲のCopilot記事で扱ったデフォルトモデル置換の文脈で登場するが、「Polaris＝MAI-Code-1」かどうかはMicrosoft公式に明示されていない。役割分担は今後の確報待ちだ。

MAIファミリー残り5モデル

reasoning・coding以外のモダリティも、MAIファミリーで自社化された。マルチモーダルの主要用途をひと通りカバーする布陣だ。

・MAI-Image-2.5（＋Flash）：text-to-imageでArena AIリーダーボード3位、image-to-imageで2位。PowerPoint・OneDrive・Foundryに展開
・MAI-Voice-2（＋Flash）：15以上の追加言語と新しい音声オプションに対応した音声合成
・MAI-Transcribe-1.5：43言語に対応する文字起こし。ストリーミングは近日対応予定
・Flashバリアント：Image・Voice・Codeに軽量版を用意し、コスト効率を重視
・展開先：Foundryに加え、Fireworks AI・Baseten・OpenRouterでも提供

MAI-Image-2.5は、Microsoft初の画像生成モデルとしてArena AIで上位につけた点が注目される。とくにimage-to-image（画像編集）で2位という評価は、PowerPointやOneDriveへの組み込みと相性がよい。

MAI-Voice-2とMAI-Transcribe-1.5は、多言語対応を前面に出す。43言語の文字起こしは、グローバルなエンタープライズの議事録・コンプライアンス用途を意識した布陣だ。

下図は、MAIファミリー7モデルが用途別にどう配置され、どの製品面に組み込まれるかを示したものだ。

Flashバリアントの存在も戦略的だ。Image・Voice・Codeそれぞれに軽量版を用意することで、品質重視の本体と、コスト・レイテンシ重視の軽量版を使い分けられる。大量バッチ処理やリアルタイム用途ではFlash、最終品質が要る場面では本体、という棲み分けが想定される。

サードパーティ展開も見逃せない。Fireworks AI・Baseten・OpenRouterでMAIが使えるということは、Azureに縛られない経路でもMAIを試せるということだ。これは「Foundryロックイン」という批判への先回りであり、モデル単体の採用障壁を下げる狙いがある。

7モデルを一気に揃えた意味は大きい。reasoningからマルチモーダルまでを自社で持つことで、Microsoftは「業務アプリの裏側を他社モデルに握られない」構図を作ろうとしている。OfficeやWindowsという巨大な配信チャネルを持つMicrosoftにとって、自社モデルを既存製品に同梱できることは、純粋な性能競争とは別次元の強みになる。

ベンチマーク主張の検証

ここが本記事で最も慎重に扱うべき論点だ。Microsoftの主張は具体的だが、独立検証はまだ追いついていない。公開された数値を整理し、読みかたを示す。

・AIME 2025：97.0%（Microsoft公称）
・AIME 2026：94.5%（Microsoft公称）
・SWE-Bench Pro：Claude Opus 4.6のコーディング能力に匹敵すると主張
・人間選好：盲検のside-by-side評価でClaude Sonnet 4.6より好まれたと主張
・評価パートナー：独立した人間評価パートナーSurgeが盲検評価を実施

盲検評価（blind evaluation）の方法論を押さえておきたい。Surgeのような評価者は、どちらの出力がどのモデルかを知らされないまま、2つの回答を見比べて「より良い方」を選ぶ。ブランドバイアスを排除できるのが利点だ。

ただし、盲検選好には限界もある。第一に、それは「どちらが好まれるか」を測るもので、絶対的な正答率や事実性を保証しない。第二に、評価に使うプロンプト集合は評価設計者が選ぶため、設定次第で結果は動く。

AIMEの97.0%という数値も、reasoningの強さを示す一方で注意がいる。AIMEは数学競技の問題で、汚染（学習データへの問題流入）の影響を受けやすいベンチの代表でもある。高スコア＝実務での万能性ではない。

SWE-Bench Proの「Opus 4.6並み」という主張も、評価ハーネスの条件で揺れる。実務寄りベンチは、エージェントが何回までパッチ生成を試せるか、テスト実行環境をどう与えるか、リポジトリの依存解決をどこまで自動化するかで、同じモデルでもスコアが大きく動く。比較の前提条件をそろえないと、数字は意味を持たない。

さらに、Build当日のような新モデル発表では、ベンチ結果は「最も有利な設定」で示されがちだという業界の経験則も忘れたくない。これはMicrosoftに限った話ではなく、新モデルの公称値を読むときの普遍的な留保だ。だからこそ、独立評価が出そろうまでは数字を相対的に受け止めるのが賢い。

公平に言えば、Microsoftが独立の人間評価パートナーを使い、ゼロディスティレーションを明示した点は、来歴の透明性という意味で前向きな姿勢だ。問題は主張の真偽ではなく、「自社ワークロードで再現するか」を各組織が確かめる必要がある、という一点に尽きる。

OpenAI依存からの脱却戦略

今回の発表を一段引いて見ると、Microsoftの狙いは明快だ。AIの推論層を自社で握り、OpenAIへの依存とコストを下げることにある。

MicrosoftとOpenAIの関係は、Azure上でGPT系を独占的に提供する深い提携で知られてきた。だがその一本足は、コスト・調達・交渉力のすべてでMicrosoftの自由度を縛る。MAIファミリーはその是正策だ。

ただしMicrosoftは、関係を断つとは言っていない。同社の説明は「OpenAIとのパートナーシップに深くコミットしている。だが顧客にはモデルのマーケットプレイスが必要だ。MAIは置換ではなく拡張だ」という立場である。

・歴史：AzureでGPT系を主力に据える深い提携を継続
・現在地：MAIファミリーで自社モデル層を確立、選択肢を多重化
・位置づけ：OpenAIの「置換」ではなく「拡張」（補完戦略）
・顧客便益：Foundry上でGPT系・Claude系・MAI系を同一ガバナンスで使い分け
・Copilot統合：GitHub Copilotでモデル選択にMAI系を組み込み

ここで効いてくるのが「Foundry上のマーケットプレイス」という構図だ。Fireworks AIがFoundryでGAになり、どのモデルを選んでもAzureのデータレジデンシーとガバナンスが効く単一プラットフォーム体験が示された。

つまりMicrosoftの賭けは、「最強の単一モデル」ではなく「モデルを束ねる土台（control plane）」を握ることだ。MAIはその土台の上で、コストとデータ主権で選ばれる第一党選択肢として置かれている。

この戦略を補強するのが、Build 2026で同時発表された「IQ」系の基盤だ。エージェントを業務知識に接地するMicrosoft IQ、構造化データの意味基盤Fabric IQ / Foundry IQ、MCPネイティブを掲げるWeb IQなど、モデルの上下にコンテキスト層が積まれた。

ここで重要なのは、これらの基盤が特定モデルに依存しない（model-agnostic）設計を強調している点だ。コンテキスト層を自社で押さえれば、その上で動くモデルがGPTでもClaudeでもMAIでも、Microsoftの土台を経由することになる。

自社アクセラレータMaiaの存在も効いてくる。推論を自社シリコン上で回せれば、外部モデルへの支払いだけでなく、推論インフラのコスト構造そのものを内製化できる。MAIファミリーは、このハードからアプリまでの垂直統合の「モデル層」を埋めるピースだ。

言い換えれば、今回の発表は単発のモデルリリースではない。シリコン（Maia）→ モデル（MAI）→ コンテキスト層（IQ系）→ アプリ（Copilot / Office / Windows）というフルスタックの自社化の一環として読むと、OpenAI依存緩和の射程の広さが見えてくる。

既存企業ユーザーへの影響

では、すでにAzure OpenAI Serviceを使っている企業は、何を見直すべきか。MAI採用の判断ポイントを実務目線で整理する。

・コスト：MAI-Thinking-1の低トークンコスト主張が自社ワークロードで効くか、実測で比較
・レイテンシ：MoEの軽量active構成が応答速度に効くか、ピーク時の挙動を含めて検証
・データ主権：ゼロディスティレーション・ライセンス来歴の明確さが調達要件に合うか
・リージョン：private preview段階の提供リージョンとGA時期、日本対応を確認
・契約・SLA：private previewのSLA・データ取り扱い・表明保証の範囲を精査

最初の判断ポイントはコストとレイテンシだ。MAIの「低トークンコスト」「軽量active」という設計上の利点は、自社の典型的なプロンプト長と並列度で初めて意味を持つ。公称値ではなく実測で比べたい。

次にデータ主権だ。ゼロディスティレーションとライセンス済みデータという来歴の明確さは、規制業種ほど効く。一方で、private preview段階の契約条件（SLA・データ保存場所・知財の表明保証）は、GAと異なる可能性が高い。

加えて見落としやすいのが「ロックインの方向が変わる」点だ。OpenAI互換APIは移行を楽にするが、MAIに最適化したプロンプトやエージェント設計に寄せるほど、今度はMicrosoft Foundryの土台への依存が深まる。依存先がOpenAIからMicrosoftの基盤へ移るだけ、という見方もできる。

実務的には、評価の物差しを「単体モデルの性能」から「運用総コスト」へ広げたい。推論単価だけでなく、移行の手間、監視・評価基盤の整備、データ境界の監査コストまで含めて初めて、MAI併用の損益が見える。発表直後の高揚に流されず、PoCの設計に時間をかける価値がある領域だ。

GitHub Copilotを既に組織導入しているチームは、MAI-Code-1系の評価から始めるのが入りやすい。コーディング用途は成果物の良し悪しを比較しやすく、SWE-Bench Proのような実務ベンチとの対応も取りやすいからだ。reasoning用途のMAI-Thinking-1は、preview解禁とリージョン対応を待ちつつ、非クリティカルな分析タスクで小さく試すのが現実的だ。

比較表：MAI vs Claude 4.6 / GPT-5.5 / Gemini 3

reasoningクラスのモデルを横並びで見ると、MAI-Thinking-1の立ち位置が分かりやすい。公開情報・公称値ベースの比較で、確報でない項目は「—／非公開」とした。

表で際立つのは、MAI-Thinking-1が「来歴の明確さ」と「Azure統合」を差別化軸に置いている点だ。生の性能勝負だけでなく、調達・コンプライアンスで選ばれる設計になっている。

他社のアーキ詳細やコンテキスト上限は非公開部分が多く、厳密な横並び比較は難しい。だからこそ、表の数値は出発点にすぎず、最終判断は自社タスクでの実測に委ねるべきだ。

よくある落とし穴

最後に、MAIファミリーを読み解くうえで誤読しやすい論点を整理する。早とちりを避けるためのチェックリストだ。

・「OpenAI完全置換」と誤読しない：Microsoftの立場は補完・拡張。GPT系は当面併存する
・ベンチ主張は評価設定依存：盲検選好は好まれやすさを測るもので、独自再現は要注意
・Foundry private previewの可用性制限：誰でも即使えるわけではなく、リージョン・SLAも限定的
・エンタープライズデータ学習の知財・コンプライアンス：来歴主張と契約上の表明保証は別物
・MAI-Code-1とProject Polarisの役割分担：両者の関係は公式に明示されておらず確報待ち

とくに注意したいのが1点目だ。「Microsoftが脱OpenAI」という見出しは刺激的だが、実態は「選択肢の多重化」であって「決別」ではない。提携は続き、Azure OpenAIも当面残る。

2点目も実務で効く。盲検でSonnet 4.6に勝ったという結果は印象的だが、それは特定のプロンプト集合での選好だ。自社の典型タスクで同じ優位が出るとは限らない。

総じて、MAIファミリーの登場は「最強モデルの交代」ではなく「調達構造の変化」として読むのが正確だ。Azure顧客にとっての本質的な変化は、推論層の選択肢が増え、コストとデータ主権で交渉できる余地が広がったことにある。

次に確かめるべきは、MAIの公称性能ではなく、自社の実タスクでの再現性だ。Foundryでpreviewが解禁されたら、GPT・Claudeと並走させた小さなevalを組み、品質・コスト・レイテンシの三軸でベースラインを取る。その実測こそが、発表の見出しよりも確かな判断材料になる。MAIが本当にSonnet 4.6を超えるかは、最終的にあなたのワークロードが答えを出す。

参考リンク（一次ソース）

・Microsoft公式ブログ「Microsoft Build 2026: Be yourself at work」：https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
・CNBC「Microsoft unveils new AI models to lessen reliance on OpenAI, lower costs」：https://www.cnbc.com/2026/06/02/microsoft-unveils-new-ai-models-lessen-reliance-on-openai-lower-costs.html
・Neowin「Microsoft unveils MAI-Thinking-1 reasoning and MAI-Code-1 coding models」：https://www.neowin.net/news/microsoft-unveils-mai-thinking-1-reasoning-and-mai-code-1-coding-models/
・Azure AI Foundry / Microsoft Foundry（モデルカタログ・データレジデンシー）：https://ai.azure.com/