Zeroshot：コードを書いた AI に自己承認させない、独立レビューと上限付き修復ループ

解決しようとしている問題

AI コーディングエージェントの典型的な欠点は、コードを書けないことではありません。書き終えたあとに、自分で「完了しました」と宣言してしまうことです。同じモデルが実装も検収も担うのは、受験者が自分で採点するのと同じです。

Zeroshot の主張は一文に尽きます。コードを書いたエージェントが、そのコードが動くかどうかを決めるべきではない、というものです。開発チームは、壊れたコードを「準備完了」と言い張るエージェントに振り回されることにうんざりして、このツールを作ったと説明しています。

中核アーキテクチャ：明示的なマルチエージェントグラフ

Zeroshot は、ソフトウェアの目標を明示的なマルチエージェントグラフに変換します。1 つのエージェントが実装し、独立した複数のエージェントがレビューします。レビューに失敗すると、作業は上限付きの修復ループに戻ります。グラフ上のチェックがすべて通るまで、成果物は納品されません。実装したエージェントが自分の作業を承認することは決してありません。これが設計上の絶対的な制約です。

位置づけも重要です。Zeroshot は Claude Code、Codex、GitHub Copilot の代わりにはなりません。そのうちの 1 つを worker としても reviewer としても実行します。つまり新しいコーディングモデルではなく、既存のエージェントを包むオーケストレーションと説明責任の層です。組み込みのグラフを使うことも、独自のトポロジーを持ち込むこともできます。レビュアー、テスト、修復ループを足し、その構成をプロファイルとして保存して次のタスクに使えます。

動作の仕組みと使い方

インストールは npm install -g @the-open-engine-company/zeroshot の 1 行です。Node.js 18 以上が必要で、Linux の x64 または arm64、macOS の x64 または arm64、Windows の x64 向けに、検証済みのネイティブバイナリが入ります。あわせて、Codex、GitHub Copilot、Claude Code 向けの Zeroshot スキルがユーザースコープで 1 つインストールされます。 ローカル実行では、Codex、Claude Code、GitHub Copilot のいずれかを先にインストールしてサインインしておきます。Zeroshot は、サブスクリプション型のセッションを含め、そのハーネスの既存ログインを再利用できます。 実行には 2 つの JSON ファイルが必要です。input.json にはタスクを書きます。たとえば「status コマンドに JSON 出力を追加し、焦点を絞ったテストを付ける」です。runtime.json にはハーネス（例：codex）、プロバイダー（例：openai）、モデル、effort（例：high）を指定します。そのうえで --template software-change と --uniform-runtime-config runtime.json を付けて zeroshot run を実行します。オプション名から、グラフ内の各エージェントに同じランタイム設定を適用するものだと読み取れます。--validate-only を付けると、実際に起動する前に、グラフ、ランタイム設定、入力を検証できます。

注意すべき事実が 1 つあります。worker は現在の Git ワークツリーを直接編集します。そのため、公式はそのタスク専用のクリーンなワークツリーで始めるよう案内しています。

独立レビューが妥当な設計である理由

ここからは当方の分析であり、プロジェクトが公表したデータではありません。第一に、実装者と検証者を分けると、自己確認のループが断ち切られます。実装側の文脈には「この変更は正しい」という理由が詰まっています。その履歴を持たないレビュアーのほうが、見落としに気づきやすくなります。第二に、修復ループに上限があることです。

上限のない「レビュー、修正、再レビュー」は、クォータを際限なく消費しかねません。上限があれば、コストと時間を見通せる量にできます。第三に、トポロジーが固定のパイプラインではなく設定可能なデータであることです。リスクに応じてグラフを選べます。1 行のドキュメント修正なら軽いグラフ、決済ロジックの変更ならレビュアーを増やしてテストも加えた重いグラフ、という使い分けです。

性能とコスト

率直に述べます。私たちが確認した資料には、公表されたベンチマーク数値がありません。合格率、欠陥検出率、レイテンシの改善幅は示せません。README の動画は台本付きと明記されており、説明用であって証拠ではありません。

一方、コスト構造は明らかです。エージェントが増えれば、モデル呼び出しも増え、実時間も延びます。ローカル実行でサブスクリプションのログインを再利用する場合、限界費用はその利用枠にかかります。Zeroshot Cloud の料金は、製品サイト zeroshot.sh で確認してください。

開発者と企業への影響

個人の開発者にとっては、「別のエージェントにもう一度見てもらう」という手作業の習慣が、再現できる 1 つのコマンドになります。チームにとっては、特定のモデルベンダーに依存しない検証層になります。下で動くのは Codex でも Claude Code でも Copilot でも構いません。

ライセンスは MIT で、npm で配布されます。リポジトリにはビルド、カバレッジ、ドキュメントの CI バッジがあり、正式なソフトウェアとして保守されていることがうかがえます。また、大手テクノロジー企業のエンジニアからスターを受けているとも主張していますが、これはプロジェクト側の自己申告で、当方では独立に確認していません。

限界と課題

第一に、公開ベンチマークがないため、価値の主張は現時点では設計の論理に支えられています。第二に、独立レビューの価値は独立性の度合いで決まります。レビュアーと実装者が同じモデルファミリーなら、同じ盲点を共有するかもしれません。第三に、上限付きの修復ループでは、上限内で通らないタスクも出ます。

その結果への対処を、利用者が用意する必要があります。第四に、worker が現在のワークツリーを直接書き換えるため、クリーンな出発点なしで実行するのは危険です。第五に、v8 はインターフェースの強制的な切り替えで、Node.js ランタイムがネイティブバイナリに置き換わりました。旧版の利用者は移行が必要です。

今後の展開

保守側が再現可能なベンチマークを公開すれば、このタイプのツールの価値は測定できるようになります。たとえば同じタスク群で、単独エージェントとレビューグラフの合格率と総コストを比べる形です。

もう 1 つ注目したいのは、プロファイルの共有です。リスクの水準ごとに調整したグラフを蓄積すれば、組織内の納品基準が少しずつできあがります。いずれにしても、書いた者が自分で承認してはならないという原則は、AI 支援プログラミングで避けて通れない土台になりつつあります。