2 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • MAI-Code-1-Flash は、日常的な開発者ワークフローでの高速かつ効率的なコーディング支援を目指した Microsoft の新しいコーディングモデルであり、VS Code の GitHub Copilot 個人ユーザーに展開中
  • Microsoft はこのモデルを GitHub Copilot ハーネス 上で直接学習させ、実際の開発環境のツールやシステムとより適切に相互作用できるよう設計した
  • 適応型応答長制御 により、単純な要求には簡潔に答え、複雑な作業にはより多くの推論予算を使い、最大 60% 少ないトークンでより難しい問題を解決する {p:60}
  • Microsoft の本番ハーネス評価では、Claude Haiku 4.5 を 4 つの主要コーディングベンチマークすべてで上回る合格率を示し、SWE-Bench Pro では 51.2% 対 35.2% で 16 ポイント先行した
  • 別の敵対的推論ベンチマークでは、186 問・34 カテゴリで 85.8% の調整精度 を記録したが、Einstellung trap のような主要な敵対カテゴリでは精度が 50% 未満にとどまり、改善の余地がある

リリースと展開

  • MAI-Code-1-Flash は、高速で効率的な日常的開発者支援のために作られた Microsoft の新しいコーディングモデル
  • Microsoft がエンドツーエンドで構築し、クリーンで適切にライセンスされたデータを使用している
  • GitHub Copilot 個人ユーザーの VS Code に展開中で、モデルセレクターおよび既定の Auto picker の下で利用できる
  • 追加設定は不要で、展開が進むと GitHub Copilot が Auto picker を通じてタスクを MAI-Code-1-Flash にルーティングするか、モデルセレクターに直接表示する
  • フィードバックは GitHub Community で受け付ける予定

開発者ワークフロー中心の設計

  • MAI-Code-1-Flash は、ベンチマーク最適化だけでなく、開発者が毎日使う本番ワークフローを中心に据えて作られた
  • 本番環境で使われる GitHub Copilot ハーネスで直接学習し、エージェント型コーディング作業で周辺ツールやシステムを扱う方法を習得するよう設計されている
  • 学習中には、主要なソフトウェアエンジニアリング作業、リポジトリ Q&A、リファクタリング、実際の GitHub Copilot 利用から派生したテレメトリベースの作業でチェックポイントを評価した
  • 学習・評価・本番環境をそろえることで、オフライン改善が実際の開発者品質につながるよう支援することを設計目標としている

トークン効率と応答方式

  • 適応型ソリューション長制御を学習し、タスク難度に応じて応答の深さを調整する
  • 単純な要求には簡潔に答え、より深い分析やより広範なコード変更が必要な問題には、より多くの推論予算を使用する
  • 開発者は有用な出力をより早く見始められる
  • MAI-Code-1-Flash は最大 60% 少ないトークンでより難しい問題を解決し、レイテンシ低減、コスト削減、トークン当たり収益の改善、よりスムーズな対話型ワークフローを目指す

コーディングベンチマーク結果

  • Microsoft は SWE-Bench Verified、SWE-Bench Pro、SWE-Bench Multilingual、Terminal Bench 2 で、MAI-Code-1-Flash と Claude Haiku 4.5 を同じ本番ハーネスで評価した
  • 評価では、タスク成功率と各タスク完了に必要な平均ソリューショントークン数を測定した
  • MAI-Code-1-Flash は、テストした 4 つの主要コーディングベンチマークすべてで Claude Haiku 4.5 より高い合格率を記録した
  • SWE-Bench Pro の多様な実世界タスクでは、51.2% 対 35.2% で 16 ポイント先行した
  • SWE-Bench Verified では、最大 60% 少ないトークンでより難しい問題を解決し、精度と効率を同時に改善できることを示した

指示追従・推論・限界

  • MAI-Code-1-Flash は、表に示されたすべてのベンチマークで Claude Haiku 4.5 を上回り、IF Bench の精密な指示追従では +28.9 で最大の差を示した
  • Advanced IF のルーブリックベース評価では、+14.5 で最も小さい差となった
  • 強い指示追従性能は、エージェント型ツール利用にもつながる
  • 数学、科学、視覚生成コーディングの中核的な推論能力でも Claude Haiku 4.5 を上回る
  • 標準ベンチマークは、推論と同じくらい暗記も報いることがあり、Monty Hall 問題を見たことのあるモデルは正解できても、賞品を入れ替えると失敗する可能性がある
  • Microsoft は、inverted classics、impossible tasks、underdetermined scenarios のような敵対的トラップを中心に、186 問・34 カテゴリのベンチマークを作成した
  • MAI-Code-1-Flash は、この敵対的ベンチマークで Claude Haiku 4.5 を全体として上回り、85.8% の調整精度に到達した
  • 推論、指示追従、不可能な問題の認識で特に強い性能を示したが、Einstellung trap のような主要な敵対カテゴリでは精度が 50% 未満にとどまり、改善の余地が残っている

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見
  • モデルカードによると、これは合計 137Bパラメータ のモデルとのこと
    性能はそれほど良く見えない: MAI-Code-1-Flash (137B-A5B) は SWE-bench pro 51%、Qwen3.6-35B-A3B は SWE-bench pro 49.5%(https://huggingface.co/Qwen/Qwen3.6-35B-A3B)
    Claude Haiku と比較しているが、Haiku は良いモデルではなく、ローカルや API でコスト 10% 程度で動かせる小さなオープンモデルよりも劣る

    • 要点は、このモデルが Haiku と競合する小型モデル だということのようで、次は「Sonnet」級、その次は Opus 級の競合モデルが出てくることを期待している
      Microsoft がなぜ Copilot で自社製モデルの提供をこれほど引き延ばしているのか不思議だったが、OpenAI との契約の一部だった可能性もあると思えてきた
    • 137B-A5B なら、先のタイトルが示唆していた 5B パラメータモデルではない
  • 出だしとしては良いし競争は歓迎だが、Haiku 4.5 のような 小型クラウドモデル をコーディングに使ったことはほとんどない
    かわいくはあっても、本気のコーディングでは高価な自分の時間を無駄にすることが多く、昨日解約した GitHub Copilot に戻ろうと思えるほどでもない
    GitHub Copilot は昨日までは価格競争力があったが、リクエストごとの課金で最も高額な部類のトークン割当方式に変わった。笑いたければ炎上中のサブレディットを見るといい: https://www.reddit.com/r/GithubCopilot
    その後、ほぼ無料で Sonnet+ 級の DeepSeek Flash high に切り替え、さらに賢いモデルが必要なら月額 $20 の Codex に加入して、今アクセス可能な中で最高だと思う GPT 5.5 を使うつもり

    • 大きなモデルで作業を 位相ソートされたタスクグラフ として編成し、複雑さに応じて小さなモデルを各タスクに割り当て、その後で大きなモデルに評価させて必要な箇所を修正させる
      この方式では日常的な作業に Haiku をかなり頻繁に使っており、何時間もかかる高複雑度の作業でも、より良い結果をはるかに低いコストで処理できる。親オーケストレーターが作業を効果的に整理し、品質をレビューし、必要なところで統合することで、単一のコンテキストウィンドウ内で膨大な労働をこなす
      Haiku を直接使っているわけではないが、大きな作業のトークン使用量の 30〜40% を占めることが多い。完了時間とコストの両方が改善され、Haiku は文字どおりの指示や計画を「再解釈」せずに従う点でより優れている一方、Opus 級のモデルは思考過程で常に疑ったり聞き返したりしがちだ
      だから Haiku は時間の無駄どころか、ものすごい時間節約になる。ただし、ここまで来るためにまずオーケストレーションシステムを作り、それを継続的に反復改善するのに多くの時間を費やした。興味深いことに、ディレクター、そしてその後 distinguished engineer として働いた経験が、これを最後まで安定して回すための道具を与えてくれたし、多様な能力を持つマルチエージェントの流れは 1000 人規模のエンジニア組織の力学と大きくは違わない
    • 難しいセキュリティバグを見つける用途で複数モデルをベンチマークしてみたところ、その過程で Haiku と Sonnet への信頼 が急激に落ちた
      セルフホストした Qwen 3.6 27B がセキュリティバグ検出でその両方を一貫して上回り、かなり衝撃的な結果だった。Qwen は Haiku レベルか少し劣るくらいで、Sonnet よりは確実に下だと思っていた
      DeepSeek と MiMo は Haiku と Sonnet よりはるかに優れており、コストはその一部にすぎないのに Opus/GPT 5.5 レベルに近い
      無料でもらえるか、たいてい使い切れないサブスクリプションに含まれているのでなければ、Haiku や Sonnet を使う理由はほとんどなさそうだ
    • ほぼ同じ状況だ。DeepSeek は拒否もほとんどなく、中国的価値観のおかげで リバースエンジニアリング、著作権付きファイル探し、出所が疑わしいソースコード作業のようなことでも摩擦がはるかに少なかった
      Copilot の価格を 90% 下げても戻らないと思う
    • これは Qwen 3.6、Gemma 4、Nemotron 3 Super あたりのレンジに見える
      Haiku と同程度に競争力のあるモデルは多く、Qwen 3.6 35B-A3B のようにずっと小さくて安いものもある。こうしたものはノートPCで動かせるので、Microsoft から借りる必要はない
      新しい Copilot の請求には面食らったが、エコシステムに残りたい人には使える選択肢にはなるだろうが、たいていの人にはもっと良い選択肢があふれている
    • 月額 $20 の ChatGPT プラン に Codex が含まれるのはコスパが良い
      プレミアム ChatGPT だけでも十分で、定期的に使用量制限に引っかかるとしても、たいていの仕事はこなせる
  • 実際にこういう小さなモデルをコーディングに使う人はいるのか? いるならどう使っているのか気になる
    普通は全部Opusで処理している。より重いモデルで計画/設計/アーキテクチャを固めて、構造化された作業をこうした小さなモデルに委任するやり方なのか、両方試してテストした人の意見を聞いてみたい

    • 職場ではOpus 4.xを使い、家ではこうした「小さな」モデル(20〜80B、アクティブ3〜4B)を使っている
      残念ながら、まだ比較にならない
      Opusなら複雑なコードベースでも、設計、アーキテクチャ提案、コード変更を信頼して任せられる
      小さなモデルは「試みてはいる」という感じだ。小さな作業には使えるが、複雑な作業では自分でやるより手間が増えることがよくある
      そうではなくなってほしいし、1〜2年後には変わっているかもしれない
    • より重いモデルで計画/設計/アーキテクチャを行い、構造化された作業を小さなモデルに任せるのはずっとそういうやり方だった
      claude codeにはopusplanがあり、計画モードではOpusを使い、実行はSonnetに切り替える
      https://code.claude.com/docs/en/model-config#opusplan-model-...
      修正: 計画はSonnet、実行はHaikuにする、あるいは望む別の組み合わせにもできる
      https://code.claude.com/docs/en/model-config#control-the-mod...
    • Haikuはかなり安く、それでいて大きく壊さないので、以前のCopilotプランでは既存プロジェクトの対話型コーディングに使っていた
      単純な機能なら完全な計画は立てない。少しコードを書いて、短いプロンプト1行でモデルにやるべきことを伝える。ときどき一時的なコメントをコードに入れて方向づけする
      たいていコード変更が1つのファイルやパッケージ内に収まるなら、Haikuでも要求についてこられるし、ひどく壊さない程度には十分だ。時間とともに方向づけのスキルも身についた。GitHub Copilotを使っていた数か月の間、月末に余ったクレジットを慌てて使い切ろうとしたこともあった
      AIコード補完だけでもかなり良いことがある。コードが何をすべきかを一時コメントで書き、Tab-Tab-Tabを押すだけで関数全体が完成することもある
      上位モデルのほうが壊しにくいと考えて人はそちらに行きがちだが、コードを本当に理解しているなら、低位モデルで対話的に作業するほうがむしろ簡単だ
    • 変更作業の実行を別責任として分ける
      メインチャットを「オーケストレーター」であるOpusに設定し、目標を定めたうえで次のサブエージェントを順番に使って到達するまで押し進めさせる
      1. ステップ実行(Sonnet): オーケストレーターの指示に従い、30分/100kトークンのあいだ作業
      2. レビュー(Opus): 前段階の作業についてエラーと指示順守を綿密に確認し、修正したうえで、エラーとトークン使用量を減らすためのエージェント設定+ツール改善の機会をファイルに記録
      3. 自己改善(Opus): ユーザー介入が不要なもののうち、影響の大きい自己改善項目を実装
        反復: オーケストレーターのセッショントークン予算が尽きるまで進める。1Mのような値に設定すればよい
        基本ロジックは、各段階を管理可能な大きさに保って指示順守率を上げ、コストを下げることだ。キャッシュされたトークンにもコストがかかるからだ。プロンプトトークンは生成トークンよりはるかに安いので、Opusが主導するより主にレビューさせるようにしたほうが、コストも大きく節約できる
        自己改善段階は非常に高価だが、改善は蓄積する。数日や数週間にわたる作業を回すなら、やらないほうがはるかに高くつく
        修正: Claude CodeでもAnthropicモデルで行い、オフライン利用ではQwen系モデルでも行っている
    • Claude Code自体も多くのサブエージェントをHaikuで起動している
      このモデルは幻覚率が低いので探索作業に向いており、ここで出ているモデルも最適な用途は似たものになりそうだ。多くの作業は計画や修正の前に複数の探索エージェントを走らせ、その後は数回のツール呼び出しで終わるため、トークン使用量も大きい
  • このモデルをHaiku 4.5と比較している
    OpusでもSonnetでもなく、Anthropicの最小モデルであるHaiku、それも3バージョン前のモデルとの比較ということになる

    • 4.5がまだ最新のHaikuモデルだ
  • なぜみんなウィンドウスクロールをこんなにひどく再実装するのだろう?

    • たぶんバイブコーディングで作ったのだと思う。自分はStopTheMadnessで防いでいる
    • すぐ目について、その場で閉じた
  • ベンチマークは相変わらずこんなに低いのに、モデルが革命的であるかのようにマーケティングされるのがとても妙だ
    コーディング能力が低くても問題ないと言うなら、トークン価格の値上げと「汎用」モデル設定をあわせて見る必要がある
    なぜ数学エージェントとして売らないのだろう? なぜ互いの作業を確認する4つのエージェントを自分で設定しなければならないのか?

    • 理解している限りでは、他のモデルと違ってMAIモデルは、ベンチマークスコアを引き上げるよう特別に設計された合成データセットでまだファインチューニングされていないからだ
    • 核心は価格対性能
      5Bパラメータでその程度のスコアならかなり良く、少し前まではほとんど信じがたいレベルだった
      小さなモデルは今後ますます良くなるだろうし、クラウドの最先端モデルも小さくなっていくと思う
      現在のインフラ大規模増強が鉄道のような感じになる、もう1つの理由だ
  • 紹介ブログ記事のほうに情報がずっと多い
    https://microsoft.ai/news/introducingmai-code-1-flash/
    そしてモデルカードもある
    https://microsoft.ai/pdf/MAI-Code-1-Flash-Model-Card.PDF
    タイトルのアクティブ5Bは、7つのMAIモデルに関するより広い発表から来ているようだ
    https://microsoft.ai/news/building-a-hillclimbing-machine-la...

  • Haikuがそもそも何のためのモデルなのかを、もう一度思い出す必要があった。
    Anthropicは最近、Haikuのマーケティングにそれほど力を入れていなかった。
    軽量なモデルが必要ならSonnetを使う。Maxプランではほとんど無料同然で、かなり速い。一般的なコーディングでHaikuの出番はあまり見当たらない。
    Haikuは大規模な要約/分類が必要なときに使うモデルなのだと思う。
    MicrosoftがHaikuを基準点にしたのは低い基準だ。

    • 「Maxプランではほとんど無料同然」というのは、笑える矛盾だ。
  • ウェブサイトはSafariでテストしてほしい。
    iOSユーザーはほぼ全員がデフォルトでSafariを使っているし、デスクトップ体験もモバイルとかなり似ているのでテストしやすい。
    あのスクロール効果は、私の環境では完全にカクつく。Chrome/Edgeでは問題なく動くのは分かる。

    • Firefox+macOSでも明らかにスクロールジャックのようなものがあって、ひどい感触だ。
  • 昨日リリースされていれば、Copilotの自動モデル選択が9倍のモデルを使って、たった半日で月間割り当てをひっそり焼き尽くす事態は避けられたかもしれない。