AIコーディングのセッションは、みな同じ気まずい瞬間で終わる。エージェントがタスク完了を宣言し、テストは通り、コードは準備万端だという。本当かもしれない。ただ、そう言っているエージェントは、すべての行を書き、その過程で無数の小さな判断を下し、その一つひとつに自分自身を納得させてきた本人だ。自分の仕事が良いかと本人に聞くのは、生徒に自分の試験を採点させるようなものだ。

2026年10月28日、MiniMaxはMCode Stackという公開リポジトリを作成し、翌29日にはClaude CodeとCodex向けのインストール導線を追加した。中身は新しいモデルでもプロンプト集でもない。MiniMax Codeを作っているチーム自身の日々の作業習慣——スキル、チェックリスト、ワークフロー——を、対応するエージェントならそのまま読み込めるファイルとして公開したものだ。そして最も面白いピースが、自分の答案を自分で採点する問題に真正面から答えている。

クリーンなコンテキストのレビュアー

そのスキルの名はindependent-review。ルールは徹底的にシンプルだ。レビュアーが見るのは3つだけ。diff。変更が満たすべき要求事項。そして失敗やスキップを含む、実際のテスト出力。

以上だ。レビュアーには、書き手の会話も計画も途中の推論も自己評価も渡さない。なぜそうするのかというスキル自身の説明は、趣旨を引用する価値がある。書き手の会話を引き継いだレビュアーは、同じ推論をなぞり、同じものを見落としがちだ。だからレビュアーの問いは意図的に置き換えられる。「書き手の論理は正しいか」ではなく、「この変更は要求を満たすか」。この2つは別の問いであり、後者に正直に答えられるのは、執筆の場にいなかった者だけだ。

スキルの工夫はセットアップにとどまらない。レビュアーは具体的な落とし穴を見るよう指示される。コードが前提にしているのに一度も検査していない仮定。diffが黙って飛ばした要求項目。要求を実際には検証せずに通ってしまうテスト——同じエージェントが書いたテストは、そのエージェントの死角を共有する。そして宣言された範囲を外れた挙動の変化。指摘は固定の構造で返ってくる。場所、理由、そしてblocking／should-fix／nitの重大度ラベル付きだ。場所と理由のない指摘は、欠陥ではなく意見として扱われる。

そして、レビュアーを過信から守る最後の一歩。メインのセッションに戻ったら、指摘を鵜呑みにはしない。一つひとつ実際のコードで検証し、できれば失敗するテストで確認してから直す。却下した指摘は理由とともに記録し、次のレビューで同じ指摘が上がらないようにする。

スタックのほかの中身

リポジトリはチームメンバーごとの個人スタックで構成されている。メインとなるのはMiniMax Codeの研究開発リードによるronnyで、作業の時間帯ごとに分類された約15のスキルが入っている。タスクにそもそもサブエージェントが要るかを判断するチェックリスト——independent-reviewの姉妹記事は率直に「サブエージェントは多ければいいわけではない」と題されている。作業を小さくレビュー可能なプルリクエストに分けるスキル。ツールや注入コンテキストがリクエストごとにいくら食っているかを監査するスキル。長いセッションの鈍化を防ぐもの。シェルコマンドにどれだけ待たせるかを決めるもの。パニックマージせずにホットフィックスを処理するもの。もうひとつのスタックには、自分がエージェントの手動ステップになっているループを見つけて脱出するスキルが加わる。

すべて共通のSKILL.md形式なので、ほとんどはMiniMax Code、Claude Code、Codex、その他スキル対応のエージェントに読み込める。インストールはプラグインコマンドを1、2回——claude plugin install ronny --marketplace MiniMax-AI/mcode-stack——か、スキルが1つだけ欲しいなら、フォルダをひとつエージェントのskillsディレクトリにコピーするだけだ。

これは何ではないか

誤読する前に3つ確認しておく。これはMiniMax Code本体のオープンソース化ではない。ツール本体は別リポジトリにあり、ここにあるのはワークフローとスキルだけだ。新しいモデルでもなく、無料の計算資源が付いてくる話でもない。エージェントが使うモデルの料金は従来どおりかかる。そしてリポジトリ全体はMITライセンスだが、エンジニアリング系のレビュースキルはGoogleのEngineering Practices文書からの翻案で、帰属表示を伴うCC-BY 3.0のままだ。再配布を考えているなら関係してくる。

正直な注意書きをもうひとつ。私たちはこれらのスキルを自分たちでインストールして試してはいない。公開されたチェックリストは、それでバグが減るという証拠ではない。まじめなチームが毎日このやり方で働き、共有する価値があると判断した、ということの証拠だ。

それでも注目に値する理由

AIコーディングの議論は生成に偏ってきた。より大きなモデル、より長いコンテキスト、より多くの並列エージェント。MCode Stackが賭けているのは、次の伸びはエージェントの周囲の層から来るという見立てだ。いつエージェントを止めて自分の仕事を点検させるか。誰がレビューするか。レビュアーに何を見せるか。とりわけindependent-reviewは、多くの人が感じていながらめったに形式化されてこなかった失敗の構造に名前を付けている。セカンドオピニオンは一度も独立していなかった。最初の意見の日記を読んでいたからだ、と。

AIがAIをレビューすることが本当のレビューと言えるかは、議論してよい。ただ、きれいな目、固定のチェックリスト、指し示すべき要求事項を持ったレビュアーは、いま多くのチームが実際に回しているやり方——作者が自分の答案を採点し、全員がそれを完了と呼ぶやり方——よりはマシだ。