MoAI-ADK：検証駆動のハーネスでClaude Codeを律し、Factory Modeがリーダーとレーンでコンテキストを分割する

概要

MoAI-ADKは、modu-aiチームが公開しているオープンソースのエージェント編成ハーネスです。Goで書かれており、Go 1.26以降が必要で、ライセンスはApache-2.0です。

リポジトリのリリースバッジはv3.1.3を示し、「What's New」の節ではv3.2のFactory Modeが予告されています。新しいコーディングモデルを訓練するのではなく、Claude Codeのような既存のコーディングエージェントに外側の構造をかぶせ、生成されるコードを信頼できるものにすることが狙いです。英語、韓国語、日本語、中国語のドキュメント、『Practical Agentic Coding with Claude Code』という解説書、Discordコミュニティも用意され、CI、CodeQL、Codecovのバッジも掲げられています。

中心となる主張：三つの責務をモデルの外へ

READMEの冒頭には、設計思想を一文で表す引用があります。モデルはトークンごとに進む確率的な作業者であり、ターンをまたいで何をどれだけ使ったかを覚えておらず、結果が良いかも判断できず、前のセッションがどこまで進んだかも知りません。この三つをハーネスが外側から強制する、という考え方です。

工学的には予算、品質、進捗の三つに当たります。MoAI-ADKはこれらをモデルの責務ではなく、決定的なコードの責務として扱います。プロンプトを長く書き足していく発想とは異なり、モデルにお願いするのではなく、モデルを制限し検査する立場です。

Factory Modeの構造

Factory Modeが狙うのはコンテキストウィンドウの問題です。1つのセッションが使えるウィンドウは1つです。長いSPECがウィンドウを埋めると、以後のすべてのタスクがそれまでの内容を抱えて進むことになります。計画はとうに終わっているのにレビューの間ずっと残り、レビューは書き上げの間ずっと残ります。よくある対処は/clearですが、不要な荷物と一緒に必要な文脈まで捨ててしまいます。

Factory Modeは、作業を1つのリーダーセッションと番号付きの複数のレーンセッションに分けます。リーダーはキューを見張り、空いているレーンにカードを渡します。カードは段階ごとにセッションを移るのではなく、丸ごと1本のレーンに入り、そのレーンが自分のセッション内でplan、run、syncを順に進めます。各段階はAgent()サブエージェントとして起動され、レーン自身は編成だけを行います。上限がなくなるわけではなく、各セッションの制限は残ります。変わるのは履歴のたまる場所です。1枚のカードの履歴は、それを持つレーンにだけ蓄積されます。同じ予算でより遠くまで進め、レーンは1枚終えるたびにコンテキストを空にして次を受け取ります。

動作の詳細

入口は2つのトークンだけです。moai cc -f（長い形は--factory）でリーダーを開き、moai cc -l（長い形は--lane）で稼働中のファクトリーにレーンとして参加します。どちらも値は取らず、レーン番号は自動で割り当てられます。-fと-lの併用はエラーです。moai cc -l lane-2のように後ろへ値を付けた場合も、正しい形を示す1行のエラーで拒否されます。旧マルチセッション・ボードモードの-kは削除され、moai cgは移行案内を出して終了します（moai migrate cgで事前確認できます）。moai gptというコマンドはなく、GPTモデルはmoai codexで動かします。moai codexにはリーダーの入口がなく、レーンとしてのみ参加できます。 バックエンドはレーンごとに選びます。moai cc -lはClaudeレーン、moai glm -lはGLMレーン、moai codex -lはCodexレーンです。ドキュメントは、リーダーの席は判定を下す場所ではなくキューを見て運ぶ場所なので、待たせても安いGLM（moai glm -f）が向くと述べています。あるアカウントで429が出始めたら、レーンを別アカウントに分散できます。この組み合わせは一例にすぎず、全セッションを単一のバックエンドにしても構わないとされています。 多数のカードを同時に処理するには、もう一度-lを実行します。番号が飛ばされるのは、生きているセッションが保持している間だけです。死んだレーンの占有は番号を塞ぎませんが、自動割り当ては常に生きている最大番号に1を足した値を選ぶため、途中の空きを埋め戻すことはありません。レーンの所有情報は~/.moai/db/<project-key>/factory/factory.dbに記録されます。基準ディレクトリが一時ディレクトリで、絶対パスのMOAI_HOME上書きがない場合は、プロジェクトローカルの<base>/.moai/db/<project-key>/factory/以下に記録されます。バックログキューも同じ例外を使います。旧.moai/state/factory/workers.jsonは一度だけ取り込まれ、ロールバックの証跡としてのみ残ります。

1本のレーンは最大10個のAgent()サブエージェントを同時に動かし、書き込み可能な起動は専用のworktreeに隔離されます。推奨は、最初のレーンを起動して実際に出力が出ているのを確認してから、残りを立ち上げる手順です。カードが複数のレーンに分割されることはありません。ファクトリーの実行は、所有するセッションのプロセス識別も記録します。リーダーが死んだ実行は、次のレーンが参加する際に自動で退役し、参加がAMBIGUOUS_FACTORYで止まることはありません。逆に、レーン参加時に実行記録が欠けているか退役済みなのに、生きているリーダーセッションがある場合は、pidとプロセス開始のフィンガープリントでそのリーダーを検証します。

性能とコスト：根拠はどこにあるか

提供されたREADMEの抜粋には、ベンチマークの数値がありません。スループットも、トークンコストの比較も、欠陥率の前後比較もありません。

示されているのは構造的な論拠で、カードの履歴が担当レーン内にだけ残るので同じ予算で遠くまで進める、というものです。筋の通った仕組みですが、測定値が公開されるまでは、実証された利得ではなく仮説として読むべきです。評価する際は、カード当たりの平均コンテキスト使用量、レーンが空になった後の再利用効率、429の発生率、リーダーとレーンの間の調整コストといった、測れる指標を追うとよいでしょう。

開発者とチームへの影響

個人の開発者にとって、Factory Modeは自前のスケジューラなしで並列化できる手段です。端末を複数開き、それぞれでmoai cc -lを実行するだけです。

チームにとっては、状態がプロジェクトキーの下のSQLiteファイルにあるため、監査や復旧がしやすくなります。複数バックエンドへの対応により、1社に賭けず、コストと枠に応じて組み合わせられます。より広く見ると、競争の軸がモデル本体から、モデルを包む工程と検証の層へ移りつつあることを示しています。

限界と今後

第一に、レーンは1つずつ人手で起動する必要があります。セッションが別のセッションを起動できないためで、完全自動化には限界があります。第二に、公開資料に定量的なベンチマークがありません。

第三に、プロセス識別の検証や旧状態の取り込みは、クラッシュ復旧がすでに相応の複雑さを抱えていることを示しており、利用者はその境界条件を理解する必要があります。第四に、カードを分割しない原則のため、非常に大きな単一タスクは1本のレーンのウィンドウを使い切る可能性があります。今後は、測定結果の公開、バックエンドの拡充、より細かいカード分割方針に期待が持てます。総じてMoAI-ADKは注目に値しますが、本番の流れに入れる前に、小規模な実タスクで自分で測定することをお勧めします。