Xiaomi MiMo 2026年6月10日の公式ブログ解説: MiMo Code は長時間コーディングエージェントをどう設計するか

Xiaomi MiMo は 2026年6月10日、MiMo Code の設計思想を説明する公式ブログ「MiMo Code: Scaling Coding Agents to Long-Horizon Tasks」を公開しました。これは単なる配布リリースではなく、ターミナル型コーディングエージェントを長時間タスクに耐えさせるための設計を、計算、メモリ、継続的改善という三つの観点から説明する記事です。

要点

• MiMo Code は、Xiaomi の MiMo チームが OpenCode を土台に構築し、MITライセンスで公開しているターミナル型コーディングエージェントです。
• 公式ブログは、短い補助ではなく、数十から数百ステップに及ぶ長時間の自動プログラミングを主な問題設定にしています。
• 単発判断の信頼性を上げるために、Maxモード、Goal、ツール呼び出し構文、動的ワークフローが説明されています。
• 長いセッションを続けるために、チェックポイント、writer subagent、セッション / プロジェクト / グローバル / 履歴の四層メモリ、再構築時の注入が紹介されています。
• 評価結果として、MiMo Code + MiMo-V2.5-Pro が複数ベンチマークで Claude Code + Claude Sonnet 4.6 を上回るという主張と、実プロジェクトでのダブルブラインドA/B評価が示されています。

今回のブログ記事で語られていること

今回の公式ブログは、MiMo Code を「AIがコードを書くCLI」としてだけ見ると読み落としやすい内容です。中心にあるのは、モデルをランタイムの中で何度も呼び出すエージェント構造が、長い開発作業になるほどどこで壊れるのかという問題意識です。短い作業であれば、会話履歴をそのまま渡すだけでも十分に動きます。しかし、ツール出力、コード片、エラーログ、途中判断が積み重なると、コンテキストは埋まり、要約で遠い情報が弱まり、長い入力の中で重要な制約が薄まります。MiMo Code のブログは、この問題を「より大きいコンテキストに詰め込む」だけではなく、何を記録し、いつ取り出し、どこで検証し、次のセッションへどう引き継ぐかというランタイム設計の問題として扱っています。

計算の章では、1回ごとの判断品質を上げる仕組みが説明されています。Maxモードは各ターンで複数の候補を並列に作り、実行前に最もよい計画を選ぶ方式です。公式ブログでは、デフォルトで5候補を使い、SWE-Bench Pro で単一サンプリングより10から20%改善する一方、トークン消費はおおむね4から5倍になるとされています。Goal は別の方向の仕組みです。エージェントが完了を宣言しようとしたとき、独立したモデル呼び出しで「本当にユーザーの停止条件を満たしたか」を確認し、不足があれば作業へ戻します。これは、長時間タスクでありがちな早すぎる終了を抑えるための設計です。

メモリの章では、会話履歴の単純な要約ではなく、実行状態を段階的にファイルへ落とす考え方が示されています。MiMo Code は、コンテキストが上限に近づいてから慌てて圧縮するのではなく、20%、45%、70%付近のチェックポイントで独立した writer subagent を走らせ、現在の意図、次の行動、制約、作業中のファイル、エラーと修正、設計判断などを構造化して保存します。さらに、セッションメモリ、プロジェクトメモリ、グローバルメモリ、履歴という層を分け、セッション内の状態、プロジェクト固有の知識、ユーザー横断の好み、元の会話ログを役割別に扱います。長い作業を任せる場合、これは性能機能であると同時に、レビュー可能性や機密情報管理にも関わる設計です。

継続的改善の章では、1回の作業を超えて経験を残す仕組みが説明されています。プロジェクトメモリは、プロジェクト背景、ユーザーが明示したルール、設計判断、繰り返し検証された技術的事実をMarkdownファイルとして保持します。公式ブログは、純粋なベクトルデータベースではなくファイルを使う理由として、ユーザーが見て、消して、直せることを挙げています。さらに、Dream は7日ごとにメモリの重複や古い参照を整理し、Distill は30日ごとに繰り返し現れる作業パターンをスキルやコマンド、SOPのような再利用可能な形へ固める、と説明されています。これは、コーディングエージェントを「毎回リセットされるチャット」ではなく、プロジェクトに居続ける実行環境として設計する発想です。

何が新しい論点か

MiMo Code のブログで重要なのは、モデル性能の主張よりも、エージェント実行の失敗点をかなり具体的に分解していることです。長いタスクでは、モデルが賢いかどうかだけでなく、途中で完了判定を誤らないか、不要なループに入らないか、古い判断をどう修正するか、プロジェクト固有の制約をどう保存するかが効いてきます。Maxモードはコストを使って単発判断を安定させる設計、Goal は終了判定を別系統で検証する設計、チェックポイントと writer はセッション状態を外部化する設計です。それぞれは派手なUI機能ではありませんが、長時間の開発自動化では実務上の差になりやすい部分です。

評価結果はどう読むべきか

公式ブログは、MiMo Code + MiMo-V2.5-Pro が三つのベンチマークで Claude Code + Claude Sonnet 4.6 を上回ると説明しています。また、576人の開発者、474の非公開リポジトリ、1,213組のA/B比較による内部ベータ評価にも触れ、実行ステップが200を超えるタスクでは MiMo Code の勝率が65%を超えたとしています。これは注目に値する主張ですが、ベンダー自身の評価である点は切り分けて読むべきです。導入判断では、同じモデル、同じ権限、同じリポジトリ、同じテスト条件で、自社の作業に対して成功率、修正回数、レビュー負荷、コスト、ログの追跡可能性を確認する必要があります。

導入・評価時に見るべきこと

MiMo Code を試すなら、最初に見るべきなのは「どれだけ自動で進むか」だけではありません。ファイル書き込み、コマンド実行、Git操作、永続メモリ、外部モデル接続の境界をどう制御できるかが重要です。特にプロジェクトメモリや履歴は便利ですが、リポジトリ固有の情報や社内の作業手順が残る可能性があります。評価環境では、メモリファイルの場所、削除や編集の方法、ログの保存範囲、権限の初期設定、CIやテスト実行時の挙動を先に確認した方がよさそうです。

また、Maxモードのような仕組みは品質改善と引き換えにコストを増やします。長時間タスクでどの段階に計算資源を使うべきかは、チームのタスク特性によって変わります。レビューが重いリファクタリングでは Goal やチェックポイントの効果が大きいかもしれませんし、短い修正では通常モードで十分かもしれません。MiMo Code の価値は、ベンチマーク順位だけでなく、こうしたスイッチを実務の作業単位に合わせて調整できるかで判断するのが自然です。

今回のブログ記事が関係する人

AIコーディングエージェントを比較している開発基盤チーム、既存のClaude CodeやCursorとの使い分けを考えている技術責任者、長時間リファクタリングや移行作業を自動化したいチームに関係します。特に、複数ファイルにまたがる変更、テスト実行を伴う修正、途中状態の引き継ぎが必要な作業をAIに任せたい場合は、MiMo Code のメモリと完了検証の設計を確認する価値があります。

結局、今回のブログ記事をどう読むべきか

この公式ブログは、MiMo Code を単なるCLI配布物ではなく、長時間コーディングエージェントのランタイム設計として読むための記事です。2026年6月15日の v0.1.1 リリースは配布単位として重要ですが、6月10日のブログは「なぜこのエージェントが長いタスクを扱えると主張しているのか」を説明する別の公式発表です。MiMo Code を評価するなら、このブログで示された計算、メモリ、継続的改善の三層を、自社の開発作業で本当に機能するか検証するのが出発点になります。