TL;DR

Xiaomiが2026年6月、ターミナルネイティブのAIコーディングエージェント MiMo Code をMITライセンスでOSS公開した。実体は OpenCodeのフォーク で、「モデル」ではなく ハーネス（エージェント基盤） である点が重要だ。
注目は性能数値そのものより、同じモデルを使ってもハーネスの違いだけでベンチが約5ポイント動いたという事実。エージェント開発の競争軸が「モデル」から「ハーネス設計」へ移りつつあることを示している。
MiMo Codeの設計思想（永続メモリ／自己メンテナンス／サブエージェント／ゴール駆動ループ）は、日本企業がコードを海外APIに出さずにセルフホストでAIコーディングを回すための具体的な設計図として読める。
ただしベンチマークは自己申告で公式リーダーボード未掲載。鵜呑みにせず「アーキテクチャから何を学ぶか」という視点で読むことを勧める。

1. なぜ今これを取り上げるのか

2026年に入り、日本のエンジニアの多くがClaude CodeやGemini CLI、各種コーディングエージェントを業務に組み込み始めた。一方で実務の現場では、いまだ次の3つの壁にぶつかっている。

コンテキストの喪失 — セッションをまたぐと「先週決めた設計判断」を忘れる
データ主権 — 自社の機密コードを海外SaaSのAPIに送ってよいのか、という法務・セキュリティ上の懸念
ベンダーロックイン — クローズドなエージェントに業務フローを握られる不安

そんな中、Xiaomiが2026年6月にOSS公開した MiMo Code は、これら3つの壁に正面から答えるアーキテクチャを持っている。しかも「Claude Codeを200ステップ超の長時間タスクで上回った」という挑発的な主張つきだ。

ここで多くの日本語記事は「Xiaomiの新モデルすごい」で終わる。だが本質はそこではない。本記事は 「ハーネスのアーキテクチャ」 に焦点を当て、日本のエンジニアが自社のAIコーディング基盤を設計するときに何を盗めるかを掘り下げる。

2. 何が起きているか（事実の整理）

複数の一次ソースを突き合わせると、事実関係は次のとおりだ。

MiMo Code（v0.1.0）は OpenCodeのフォーク として構築されている。OpenCodeのコア機能（マルチプロバイダ対応、TUI、LSP、MCP、プラグイン）をそのまま継承し、その上に独自レイヤーを追加した。
ライセンスは MIT（ただし USE_RESTRICTIONS.md に利用制限あり）。weightsを含むモデル MiMo-V2.5-Pro も別途Hugging Faceで公開されている。
モデル MiMo-V2.5-Pro は 総パラメータ1.02兆 / アクティブ42億のMoE、コンテキスト長100万トークン、FP8（E4M3）混合精度。
インストールはワンライナー。

# macOS / Linux
curl -fsSL https://mimo.xiaomi.com/install | bash

# Windows / npm 経由
npm install -g @mimo-ai/cli

ベンチマークについては、ベンダー（Xiaomi）側が次の数値を主張している。

ベンチマーク	MiMo Code	Claude Code
SWE-bench Verified	82%	79%
SWE-bench Pro	62%	57%
Terminal-Bench 2	73%	68%

そして「200ステップ未満ではほぼ五分だが、200ステップを超えると勝率が65%超に上がる」という長時間タスクでの優位を主張している。

⚠️ 重要な注意：これらは自己申告値であり、執筆時点でMiMo Codeは公式リーダーボードに掲載されていない。HackerNewsのコメントでは「無料モデルを試したがSonnet 4.6には遠く及ばない」「スレッドのコメントがbotくさい（ステマ疑惑）」という声もある。数値は鵜呑みにせず、検証用の話題として扱うべきだ。

それでも私が面白いと思うのは次の一点だ。同じ MiMo-V2.5-Pro をMiMo CodeとClaude Codeの両ハーネスで動かした場合でも、SWE-bench Proで62% vs 57%、Terminal-Bench 2で73% vs 68%と、約5ポイントの差が出たという。これはモデルではなくハーネス（足回り）に由来する差だ。

3. 技術的な核心：差を生む「ハーネス4点セット」

ここが本記事の中心だ。MiMo CodeがOpenCodeに追加した独自レイヤーは、ざっくり4つに分類できる。いずれも「コンテキストウィンドウへの過依存」という現代エージェントの構造的弱点への処方箋になっている。

3-1. 永続メモリ（コンテキストウィンドウの外に記憶を持つ）

多くのコーディングエージェントは記憶をモデルのコンテキストウィンドウに丸投げしている。だから窓が埋まると過去の決定を忘れる。MiMo Codeは記憶をコンテキストの外側に持つ。

SQLite FTS5 による全文検索付きのクロスセッションメモリ
プロジェクトメモリ（MEMORY.md）、セッションチェックポイント、スクラッチノート、タスク進捗
コンテキストウィンドウの残量を見て自動でチェックポイントを保存

.mimocode/
├── mimocode.json      # 設定（プロバイダ, MCP, LSP など）
├── MEMORY.md          # プロジェクト長期記憶
└── (SQLite FTS5 store) # セッション横断の検索可能な記憶

設計のキモは「記憶＝検索可能な外部ストア」という考え方だ。これはRAGの発想をエージェント自身の作業記憶に適用したもので、自前でエージェントを組む際にも真似できる。

3-2. 自己メンテナンス：`/dream` と `/distill`

/dream は7日ごとに自動起動し、別の保守用エージェントが過去セッションとメモリファイルをレビューする。重複を削除し、ファイルパスの有効性を検証し、長期記憶として圧縮し直す。/distill はワークフローを抽出・自動化する。

つまりエージェントが自分の記憶を定期的に「掃除」する。長期運用でメモリが汚れて精度が落ちる問題への、運用設計としての回答だ。

3-3. サブエージェント・オーケストレーション

primaryエージェントが必要に応じてサブエージェントを生成でき、ライフサイクル管理・キャンセル・バックグラウンド実行を備える。エージェントは役割で分かれている。

build：デフォルト。フル権限で実装する
plan：読み取り専用で分析する（破壊的操作をさせない）
compose：仕様駆動開発（Tabキーで起動。要件→設計→実装→テスト→レビューを一気通貫）

plan を読み取り専用に固定している点は、後述する日本の現場での安全運用に直結する。

3-4. ゴール駆動の自律ループ

/goal でセッションの停止条件を設定すると、独立したジャッジモデルが会話を評価して「ゴール達成か否か」を判定する。さらに experimental.maxMode（並列best-of-N推論＋ジャッジ選択）も用意される。

「いつ止めるか」を別モデルに判定させる構造は、前回の記事で触れた“暴走するエージェント”問題（自律実行がコストや事故を生む）への、ハーネス側からの歯止めとも言える。

4. 日本の実務への示唆

4-1. 「データ主権」要件に効く

MiMo Codeは MIT + OpenAI互換API + セルフホスト可能 という組み合わせだ。設定でプロバイダを差し替えられる。

// .mimocode/mimocode.json （イメージ）
{
  "provider": {
    "type": "openai-compatible",
    "baseUrl": "https://llm.internal.example.co.jp/v1", // 社内推論基盤
    "apiKey": "${INTERNAL_LLM_KEY}"
  }
}

金融・公共・製造など「ソースコードを海外SaaSに送れない」業種にとって、これは大きい。ハーネスはOSSで自社管理し、推論はオンプレ／国内リージョンの社内モデルに向けるという構成が、追加開発なしで取れる。海外フロンティアモデルのAPIに依存しない選択肢を、業務フローを変えずに持てるわけだ。

4-2. 「モデル選定」より「ハーネス選定」を真剣にやる

今回の5ポイント差が示す教訓は明快だ。同じモデルでもハーネスで成果が変わる。日本企業のAI導入は「どのモデルが賢いか」に偏りがちだが、実際の生産性は

メモリ管理（セッションをまたいで設計判断を保持できるか）
コンテキスト圧縮の賢さ
サブエージェントの権限分離

といった足回りで決まる。MiMo Codeのアーキテクチャは、自社でハーネスを評価・内製する際のチェックリストとして使える。

4-3. 権限分離を運用に落とす

plan（読み取り専用）と build（フル権限）の分離は、そのままレビュー運用に転用できる。たとえば「本番に近いリポジトリではまず plan で調査 → 人間がレビュー → build で実装」というゲートを設ければ、自律エージェントの事故を構造的に減らせる。

4-4. 警戒すべき点

ベンチは自己申告。PoCで自社タスクの実測を取るまで性能を信じない。
MITだが USE_RESTRICTIONS.md あり。商用利用前に必ず制限条項を確認する。
MiMo Auto（無料枠）は中国・Xiaomiの推論基盤を経由する。試用は良いが、機密コードを通すなら前述のセルフホスト構成に切り替える。
インストールが curl | bash ワンライナーなので、社内導入時はスクリプト内容を必ず監査する。

5. まとめ：エンジニアへのアクションアイテム

MiMo Codeのニュースの本質は「Xiaomiが速いモデルを出した」ではなく、AIコーディングの競争軸がモデルからハーネス（エージェント基盤）へ移ったことの可視化だ。明日からできることを挙げる。

ハーネスを評価軸に加える：モデル比較表だけでなく「メモリ管理・コンテキスト圧縮・権限分離」を評価項目にする。
永続メモリの発想を自前エージェントに移植：コンテキスト窓に頼らず、検索可能な外部メモリ（SQLite FTS5やベクタDB）に作業記憶を逃がす。
権限分離をワークフロー化：plan相当の読み取り専用フェーズを必ず挟み、buildは人間ゲート後に。
データ主権構成を試す：OpenAI互換の社内推論基盤にハーネスを向け、コードを外に出さないPoCを1本回す。
ベンチは自分で取る：公開数値ではなく、自社の典型タスクで長時間（200ステップ級）の実測を取る。

「賢いモデルを選ぶ」時代から、「賢い足回りを設計する」時代へ。MiMo CodeはそのOSSのお手本として、たとえ自社で採用しなくても読む価値のあるリファレンス実装だ。

参考ソース

本記事はベンダー公表値を含みます。ベンチマークは執筆時点で自己申告・公式リーダーボード未掲載のため、導入判断は必ず自社環境での実測に基づいてください。