GitHub Copilotに「OpenAI由来じゃない自社モデル」が静かに入った — Claude Haiku 4.5を16ポイント上回るMAI-Code-1-Flash

GitHub Copilotのモデルピッカーを開いた人なら、6月2日以降、見慣れない名前が一つ増えていることに気づくはずだ。

「MAI-Code-1-Flash」。Microsoftが自社で訓練し、Build 2026のキーノートで発表したコーディング特化モデルだ。Anthropic、OpenAI、xAI、DeepSeekに続く形で、ついに**「Microsoftブランドの本気のコーディングモデル」**が現役プロダクトに刺さった。

派手な発表ではない。Auto選択でも個別選択でも、ユーザー側からはただ「新しい選択肢が増えた」だけに見える。だが中身を見ると、これは Copilot 戦略の方向転換の合図だ。

5Bで Claude Haiku 4.5を16ポイント上回る

数字から先に確認したい。

Microsoft AIの公式ブログによると、MAI-Code-1-Flashの主要ベンチマーク結果は以下の通り。

ベンチマーク	MAI-Code-1-Flash	Claude Haiku 4.5
SWE-Bench Pro	51.2%	35.2%
SWE-Bench Verified	71.6%	—
SWE-Bench Multilingual	65.5%	—

SWE-Bench Proで+16ポイントの差は、ベンチマークの世界で言えば「ほぼ別物のクラスに昇格した」レベル。しかも本モデルはわずか5Bパラメータ（実装ヒントから推察。Microsoftは正式数値を出していないが、報道では5B級と複数のメディアが報じている）。Claude Haiku 4.5のパラメータ数は非公開だが、Anthropicが「小型・高速」と位置付けているHaikuと比較しても、より軽いMAI-Code-1-Flashが上回ったことは、Microsoftの内製ファインチューニング戦略の説得力を一気に上げた。

ついでに付け加えると、同じ難易度の問題を解くのに使うトークンが60%少ない。これは推論コスト・レイテンシー両方への直接的な利益で、Copilotのような「日常的に何百回も呼び出される」用途では効きが違ってくる。

なぜ Microsoft が自分で作ったのか

Microsoftが「自社モデル」を出してきた背景には、いくつかの圧力が重なっている。

まず、コスト。GitHub Copilotは2025年から有料化を強化し、2026年6月にはAI Credits制の従量課金へ移行した（既存記事「GitHub Copilot、6月から月額200ドルのCopilot Maxを追加」参照）。ユーザーが利用すればするほど、OpenAIやAnthropicへのAPIコストがそのまま跳ね返ってくる構造だった。

そこで、社内で「主要なルーチンタスクは自社の安いモデルで吸収する」必要が出てきた。MAI-Code-1-Flashはまさにその役割を担う。CNBCの6月2日付の報道も、「OpenAIへの依存度を下げ、開発者のコストを下げる」狙いを明確に書いている。

もう一つは、訓練データの質。

MAI-Code-1-Flashの一番面白い点は、**「Copilotの実本番ハーネスの中で直接訓練された」**ことだ。

普通のコーディングモデルは、GitHubのオープンソースコードや合成データを大量に流し込んで作る。だが Microsoft は、Copilot 内部の「ファイル読み取り → コード提案 → ユーザー受諾/編集」のループを、訓練段階からそのまま使った。つまり、モデルが**「Copilotとして動くときに何をすべきか」を訓練時から学んでいる**。

これは小さい話ではない。SWE-Bench Proの数字が、単純な「コード生成スコア」ではなく「実際の開発フローでの問題解決」を反映していると主張できる根拠になる。

Adaptive Solution Length という地味だが大事な機能

ベンチマーク以外で個人的に注目しているのが、Adaptive Solution Length（適応的解答長制御）という機能。

簡単な要求には短く返し、複雑な問題にはリーゾニング・バジェットを増やして深く考える。要するに「無駄な長文を吐かない」モデルだ。

Cursorや Claude Codeを長く使っている人なら分かると思うが、AIコーディングツールの不満は「正しいけど長すぎる」回答だ。500行のリファクタを頼んでないのに、ちょっとした関数修正の提案で延々と前後のコンテキストを書き直してくる。それが課金的にも、認知負荷的にもストレスになる。

Adaptive Solution Lengthは、この「冗長性問題」をモデルレベルで解決しようとしている。Copilotがインラインで補完するときと、エージェントモードで長期タスクをこなすときで、出力の長さを自動的に変える。

これがうまく機能すれば、Copilotの体感速度が結構変わる可能性がある。

何ができるようになるか

MAI-Code-1-Flashが既存の選択肢の中でどこに収まるかを整理すると、こうなる。

• GPT-5.5 / Claude Opus 4.8: 大型・高精度。複雑なリファクタや設計レビュー向き
• Claude Haiku 4.5 / GPT-5.5 Mini: 軽量・速い。日常タスク向き
• MAI-Code-1-Flash: 軽量で日常タスク向きだが、ベンチマーク上は重量級に近づく層

特に「Copilotの自動補完」「リアルタイム提案」「短いチャット」あたりはこのモデルが主力になる可能性が高い。Microsoft側にとっては、これらの低単価・高頻度ユースケースを自社モデルで巻き取れれば、外部API依存を一気に減らせる。

開発者にとっての具体的な変化として考えられるのは:

1. Copilotのレスポンスが速くなる — トークン数60%削減と軽量モデルの恩恵。インライン補完の体感が変わる可能性
2. エンタープライズ層でのオフライン/プライベート展開が現実的になる — 5B級ならオンプレやプライベートクラウドでも動かしやすい
3. Anthropic/OpenAI のコーディングモデルへの価格圧力 — 「Microsoftの内製で十分」が成立する領域が増えれば、上位モデルの値段にも影響する

3つ目は時間がかかる話だが、もし MAI-Code-1-Flash 2 や Pro 版が同じペースで出てくるなら、コーディングモデル市場の競争構造が変わる引き金になりうる。

微妙な点・懸念

良い話ばかりではない。冷静に見ると、いくつか引っかかる点がある。

ベンチマーク数値の独立検証がまだない。 SWE-Bench Pro 51.2%は Microsoft の自己申告であって、外部の独立評価で再現されたものではない。MAI-Thinking-1のときと同じく、「自社ベンチマークで自社モデルが強いのは当然」という古典的な疑念は残る。

「Copilotハーネスで訓練」の裏側を考えると、Copilot以外で使いにくい可能性がある。 モデルが Copilotの動作パターンに最適化されているなら、汎用APIとして他の環境（Cursorなど）に組み込んだときに性能が出ない可能性は十分ある。Microsoft が API公開や Foundry 経由の配布をどうするかが分岐点になる。

MAI-Thinking-1との位置づけが整理しきれていない。 Build 2026では Reasoning 系の MAI-Thinking-1 と コーディング系の MAI-Code-1-Flash が同時発表されたが、エージェント的なコーディングタスクで両者がどう住み分けるのか、Microsoftからの説明はまだ薄い。

それと、Microsoft の MAI シリーズはまだ「7モデル並べて見せる」段階で、各モデルの個性がユーザーの選択に落とし込めるレベルまで言語化されていない。これは数ヶ月で解消されるかもしれないが、現時点では「とりあえず Auto に任せて出てくるのを見る」という運用になりそうだ。

まとめ — 静かな転換点

派手なアップデートではない。「Anthropic Opus 4.8がリリース！」のような賑やかさはない。

だが、**「MicrosoftがGitHub Copilotの中核モデルを自社で持ち始めた」**という事実は、AIコーディング市場の権力構造を中長期で変える可能性がある。

Copilotユーザーは、モデルピッカーで一度 MAI-Code-1-Flash を選んで触ってみると面白いはずだ。Auto選択でも自然に使われ始めるが、自分で意識して切り替えると、レスポンス速度と回答の簡潔さで「ああ、これは確かに違うモデルだ」と分かる場面がある。

そして、競合の Cursor、Windsurf、Cline などにとっては、これは脅威でも好機でもある。「Microsoftが自社で内製化を進める」流れが続けば、APIモデル市場で安価な小型モデルの供給が増え、エージェント型ツールのコスト構造が変わる。

ベンチマーク数値の独立検証と、API公開の有無、そして数ヶ月後の MAI-Code-1（Flashなしの本体版）の登場を見て、この記事を読み返したい。