Buda vs MiMo Code：長いタスクを、プロジェクトの記憶と持続する作業環境からどう再開するか

会話を越えて残すべき状態と、再開後の検収方法から選びます。

昨日、Agentは仕事の3分の2を終えました。今日再開すると、変更済みファイルは見つかるのに、別案を却下した理由を忘れ、未実行のテストにも気づきません。ファイルは残っていても、仕事がつながったとはいえません。

BudaとMiMo Codeはこの問題から比較できます。ただし「記憶のあるプラットフォーム対、記憶のないCLI」と説明するのは不正確です。MiMoの公式READMEには会話間の記憶、自動チェックポイント、進捗管理、停止条件、複数のworkflowがあり、Desktop betaはオフィス作業やブラウザー操作も扱います。Budaの違いは、相手の能力を削るのではなく、作業環境と確認方法で説明する必要があります。

開発プロジェクトを中心に、モデル接続、記憶、開発手順を自分で管理したいならMiMo Codeを試す価値があります。多様な業務で資料、ブラウザー、ターミナル、成果物を一つの継続環境に置きたいならBudaのAgent Workspaceを評価してください。

MiMoが保持する状態は少なくとも四種類

READMEはSQLite FTS5による全文検索と、プロジェクト知識、会話チェックポイント、一時メモ、タスク進捗の分離を説明しています。

過去の会話を丸ごと戻すより構造的です。会話上限に近づくと、最新チェックポイント、記憶、進捗、保持した直近メッセージから文脈を再構築します。注入にはtoken予算と重要度の順位付けがあり、圧縮を早める設定もあります。

再探索を減らし、試した方向を残せるのは長い仕事で重要です。しかし、記憶ファイルに必要な事実がすべて正しく記録される保証はありません。誤った判断や古い制約も残り得ます。評価するのは記憶機能の有無ではなく、再開後の行動です。

出典：公式README。2026-09-30撮影。英語原文を保持し、翻訳を製品画面として見せていません。

長い仕事の実行経路も一つではない

主なAgentは、実行のbuild、読み取り専用分析のplan、編成のcomposeです。READMEは特定の先端モデルでbuildから/compose-nextを呼び、要件、仕様、実装、検証、レビューへ進む経路を推奨します。独立compose Agentは別の経路です。

JavaScriptによる決定的workflowとしてcompose、deep-research、fact-check、research-experimentも記載されています。段階の順序、再試行や並列数の制限、チェックポイントを設定できます。compose workflowでは分離したGit worktree、TDD、構造化した段階間出力が説明されています。途中で方向を変えるなら対話経路、範囲が明確で分割可能なら非対話workflowが候補です。

/goalでは終了しようとすると別のjudgeモデルが目標達成を確認します。検査を一つ増やせますが、モデルの判断である点は変わりません。実行できるテスト、照合可能なファイル、本番操作には独立した証拠と人の放行判断が必要です。

MiMoの評価理由は端末操作だけではありません。復旧、段階編成、終了判定が具体的に設計されています。それが自社の重要課題なら実際のリポジトリで検証してください。

Budaでは、作業環境に何を残せるかを見る

Budaは会話、Drive、ターミナル、ブラウザー、Gitを継続可能な環境にまとめます。Driveには原資料、作業ファイル、成果物が残り、人は実行中に確認し、後続タスクでも利用できます。

違いは「記憶ファイル対、記憶が不要」ではありません。どちらも入力、文脈、検収条件が必要です。プロジェクトディレクトリを中心に設定・確認するか、多種類の仕事を統一環境で整理するかが選択点です。

公開された仕組みと評価入口の表です。同条件の実測なしに速度や信頼性の順位には変えられません。

Desktopは版と提供範囲を別に確認する

Desktop betaの説明には複数形式のファイル、PPT、Webページ、3D素材、部分編集、版の巻き戻し、ブラウザー制御があります。国際版にはcomputer controlとRecord & Replayも記載されています。MiMo Codeが中核エンジンですが、申請が必要なbetaで、版ごとに範囲が異なります。

資料からスライドを作りWebで確認する仕事に、MiMoは対応しないと決めつけてはいけません。実際の入口と版を確認し、全工程を試します。READMEの最大キャッシュヒット率はベンダーの説明であり、自社の節約額やBudaとの比較結果ではありません。

モデル接続にはプラットフォームログイン、一部OAuth、API key、OpenAI-compatibleの独自提供者があります。モデル、endpoint、認証、文脈予算を確認してください。Budaでも公開されているモデル・プランの提供範囲を確認します。上流token単価と別製品のCreditsを同じ価格単位として扱いません。

記憶量ではなく、中断後の再開を試す

以下は提案する評価方法で、実測ベンチマークではありません。原資料3件、旧版レポート、引用規則、新しいデータを渡し、旧結論の確認、二節の更新、納品版の作成を依頼します。

最初は資料整理と変更計画まで進めて中断します。再開時は仕事を説明し直さず、新資料だけを渡して確認します。

• 確認済み情報源と版を維持し、古い資料を最新と扱わないか。
• 却下した結論が再登場せず、却下理由を探せるか。
• 未完了の検査が要約圧縮で消えず、明示されるか。
• 修正の根拠を追え、未解決の矛盾を一覧にできるか。

MiMoではチェックポイントとタスク記録、BudaではDriveの情報源、修正記録、出力を確認します。どちらも独立した検収表を残し、Agentの「完了」を唯一の基準にしません。

さらに一つの情報源を撤回し、依存する結論を直すよう求めます。古い事実が正しく置き換わるかを確認できます。継続性は過去を保持するだけでなく、無効になった過去を識別することも含みます。

チームが引き受けられる管理方法から選ぶ

開発プロジェクト中心で、設定やファイルを確認し、モデル提供者を選びたいチームはMiMoを試せます。復旧品質、workflowの段階証拠、停止条件、権限を見てください。ページ生成デモだけでは足りません。

調査、ファイル処理、ツール実行、後続タスクを同じ作業環境で続けたいならBudaが候補です。情報源、出力、確認手順を定め、Buda AIのMarketplaceで必要なSkillを検索・導入できます。定期実行は安定した手順に追加します。

同じチームでMiMoを開発に、Budaを別の業務に使うこともできます。引き継ぐのは確認可能なファイル、版、未決事項です。「できた」とする会話要約だけでは不十分です。

よくある質問

Xiaomiのモデルしか使えませんか？

いいえ。READMEには複数提供者、一部OAuth、独自OpenAI-compatible APIがあります。選択した提供者の認証と利用可能モデルを確認します。

持続記憶は過去の全会話を完全に保持しますか？

注入予算、重要度順位、再構築があるため、すべてが次の文脈にそのまま入るとは限りません。重要制約が残るかを検証します。

build、compose、workflowはどう選びますか？

途中で対話による方向変更が必要かを見ます。buildと/compose-nextは推奨経路の一つで、決定的workflowは明確で分割可能な仕事向けです。現在のREADMEのモデル推奨に従い、単純な仕事を無理に多Agent化しません。

CLIとDesktopの能力を同一として書けますか？

いいえ。DesktopはCLIを中核とするbetaですが、版と申請条件があります。computer controlには国際版の境界があります。

どちらが「偽の完了」を防げますか？

MiMoはjudgeと段階検証を、Budaは確認できる成果物と実行過程を提供します。同条件実測なしに完全防止を主張できません。実行可能な検収と責任者が必要です。

情報源

• MiMo Code公式英語README
• Buda Agent Workspace

確認日：2026-09-30。機能は公開資料に基づきます。レポート再開テストは提案する方法であり、速度や効率の実測ではありません。