オーケストレーション

これは、clikae で 複数のアカウントに作業を振り分ける ための実践ガイドです。 あなた がキーボードの前にいる場合でも、LLM エージェントが代わりに clikae を動かす 場合でも変わりません（たとえば Claude Code がバックグラウンドで clikae burn / clikae conduct を走らせるケース）。内容はタスク本位です。コマンドの完全なリファレンスは usage.md を、言語そのものについては grammar.md をご覧ください。

もしあなたがこのページを読んでいるエージェントなら、ここが契約書です。§3 のルールに従えば、空振りすることはありません。

1. 基本の考え方 — 頭脳と筋肉

clikae は筋肉です。各エンジンがどこに設定やトランスクリプトを置いているか、それぞれがどう使用上限を知らせるか、どのタンクにまだ残量があるか、特定のアカウントへジョブをどう振り向けるかを把握しています。ただし、作業の良し悪しを 判断はしません。

頭脳は指揮者（コンダクター）です。あなた自身、またはその役を担うセッションモデルがこれにあたります。頭脳はプロンプトを書き、どのタンク／エンジン／努力度を使うかを決め、勝者を選びます。clikae は状態を運び、適切なサブスクリプションを投入する。何が良いかを決めるのは頭脳です。

両者をきちんと分けておけば、全体が監査可能なまま保たれます。clikae が変えるのは 状態がどこに置かれるか だけであり、リクエストの途中に割り込むことも、出力を採点することもありません。

2. 振り分けの三つの方法

やりたいこと	使うもの	かたち
1 タスクをヘッドレスで、タンクが切れても完走させたい	`clikae burn`	1 タンク → 成果物（artifact）で検証 → 切れたら次の予備タンクへ自動で再ルーティング
同じプロンプトを N 個のアカウントで走らせ、勝者を選びたい	`clikae conduct`（BETA）	読み取り専用で並列にファンアウト → N 個の出力を集める → 判断はあなた
指揮者が決めた一発を、努力度ノブと完全な記録つきで	conductor スキルのレッグ（`claude-leg.sh` / `codex-leg.sh`）	名前付きタンク上での単発。やり取りを重ねるかは指揮者の裁量

burn は予備タンクの巡回を担います（切れたら次のタンクへ。アカウントを意識し、対話セッションが乗っているタンクは避けます）。どこかで 必ず終わらせたい、無人実行のタスクに使ってください。
conduct は best-of-N、つまり幅を取るためのものです。監査、分析、設計案をアカウントをまたいで集めます。再ルーティングも判断もせず、ファイルをあなたに渡します。
レッグ（conductor という Claude Code スキル）は、 Agent ツールが露出していない --effort ノブを追加します。--tank <name> は clikae env 経由でルーティングするので、レッグは実在する名前付きアカウント上で走ります（--write レッグの場合は、そのタンクの git アイデンティティも引き継ぎます — §6 参照）。レッグは単発です。タンクが切れても生き延びさせたいなら、代わりに burn を使ってください。

agy（Antigravity）は例外です — 振り分ける前に必ずこれを読んでください

agy は中途半端な扱いです。conduct なら読み取り専用レッグを振れます（安価で速い幅出し — --leg agy/<tank>）が、burn と conductor のレッグは振れません。agy のログインは グローバル な Keychain エントリ 1 つだけなので、シェルごとに切り替える env が存在せず、 burn はこれを再ルーティングできません（「burn できない」≠「使えない」）。conduct レッグは、 アクティブな agy タンク上で走らせることでこれを回避します（切り替えはしません。別のタンクを指定したレッグは、実行されずに報告されるだけです。~/.gemini の入れ替えはマシン全体に効く排他的なものなので、2 つの agy タンクを並列に走らせることはできません）。

# agy を best-of-N の幅出しレッグとして claude/codex と並べる（agy はアクティブなタンク上で走る）:
clikae conduct --prompt-file review.md --leg claude/C --leg codex/H --leg agy/c --add-dir "$PWD"

# あるいは agy を直接ヘッドレスで動かし、メイン予算の代わりに agy のクォータを使う:
clikae agy <tank> -- --print-timeout 900s -p "$(cat /tmp/prompt.txt)"

agy のヘッドレス時の挙動は claude/codex とかなり違うため、いつもの調子で手組みすると空振りします（大きな stdout をバッファに溜めて何も返さない、あてどなくさまよってタイムアウトを使い切る、-i は TTY なしで死ぬ）。agy にヘッドレスのジョブを送る前に、専用のレシピ — docs/agy-dispatch.md — を読んでください。 これは本物の有料エンジンです。このレシピが、無駄遣いを止める方法です。

3. 誠実さを保つルール（苦労して得た教訓 — 一つでも破ると空振りします）

判断は成果物／出力で行い、終了コードを当てにしないこと。 ヘッドレスの codex exec や claude -p は、使用上限に当たって何も書かなかったときでも 0 を返して終了します。burn は成果物の存在＋新しい mtime で、conduct は捕捉した出力で、レッグは --out の中身で判断します。$? を決して信用しないでください。
タスクには楽な道を与えること — エンジンのフラグを手組みしないこと。 --prompt-file <f>（または --prompt）＋ --add-dir <dir> を使えば、clikae が各エンジンのヘッドレス書き込み方言を埋めてくれます（claude の -p … --dangerously-skip-permissions --add-dir、codex の exec -C … -s workspace-write）。-- -p '…' を手書きするのは、書き込めない ジョブを出荷するいちばんの近道です（§4 参照）。
成果物は、タスクが本当に生み出すファイルでなければならない。 burn は --artifact が現れたとき（または mtime が変わったとき）に成功とみなします。コード生成タスクの成果物は 実際に書かれるコードファイル であって、ついでに出してくれたらいいなと思っている /tmp/report.md ではありません。--artifact は本当の出力を指してください。さもないと、burn は本物の成功を失敗と呼んでしまいます。
正しいリポジトリを指すこと。 書き込みタスクには --add-dir <repo> が必要です（clikae がこれをエンジンの書き込み権限＋作業ディレクトリのフラグに変換します）。 --add-dir なしで間違ったディレクトリから走らせると、エンジンはあなたのファイルすら見えません。
複数行のプロンプトは --prompt-file を通すこと。 プロンプトはデータとして渡されるので（内部では NUL で区切られます）、複数行のプロンプトもそのまま残ります。段落をシェルでクォートした -p '…' に詰め込もうとしないでください。
入力はあらかじめ /tmp に置き、タスクを冪等にすること。 投入されるタンクに、遅い iCloud バックアップの I/O を渡してはいけません。また、成果物で検証できる冪等なタスクなら、あるタンクが切れても別のタンクで無料で再実行できます。

4. アンチパターン — 実際に設定を誤った burn（とその修正）

実際に見かけた例です。

cd /Users/me
clikae burn claude L --artifact /tmp/reef-core-seam1-report.md --timeout 1200 --fresh \
  -- -p 'Execute the first seam of the refactor — write real code and commit …'

すべて生の -- -p … 形式に由来する、3 つの危険信号があります。

書き込めない。 -- -p '…' には --dangerously-skip-permissions がないので、ヘッドレスの claude は読み取り専用で走ります — 「本物のコードを書く」タスクがファイルに触れられません。
場所が違う。 cwd がホームディレクトリで --add-dir <repo> もないので、エンジンは編集すべきリポジトリに到達できません。
成果物の不一致。 タスクはコードを書くのに、--artifact はタスクが決して生み出さない /tmp のレポートを指しています → たとえコードが書かれていても、burn は失敗と報告します。

修正です — 便利なインターフェースが、3 つすべてを代わりにやってくれます。

clikae burn claude L \
  --artifact ~/dev/reef/src/editor_backend/__init__.py   `# the file the task really creates` \
  --prompt-file /tmp/reef-seam1.md \
  --add-dir ~/dev/reef \
  --timeout 1200 --fresh

5. 艦隊を見渡す

ターミナルから: clikae（ボード — タンクごとに信号機式の残量ドット）と clikae tanks（アカウント一覧）。これが、誰が満タンで誰が切れているかを示す、権威あるビューです。

clikae を動かしている Claude Code セッションの中から: 入力フッターに · N shells · が表示されます — このセッションが走らせているバックグラウンドシェルの数です。 ↓ を押すと管理できます（Enter で出力を表示、x で停止）。このカウントはシェル単位で、タンクは意識しません。いくつ ジョブがあるかを教えてくれ、それぞれが何かはマネージャが見せてくれます。

マネージャに自分の名を名乗らせましょう。 マネージャは各コマンドの 冒頭部分 を切り詰めてプレビューします。バックグラウンドコマンドの先頭にタンク＋役割を置けば、すべてのジョブがひと目で自分を名乗ってくれます。

# 先頭に [tank·role] トークンを置く → ↓ マネージャに汎用の接頭辞ではなく "[L·deadlinks]" が出る
tag='[L·deadlinks]'
clikae burn claude L --artifact … --prompt-file … --add-dir …

これがないと、先頭の cd … / VAR=… 接頭辞を共有する複数のジョブがすべて同じようにプレビューされ、見分けがつかなくなります。（clikae にネイティブの集約ロスターを持たせる案はバックログにあります。それまでは、トークン先頭の慣習がハーネス自身のビューに無料で乗っかります。）

6. アカウントをまたぐこと、切れること、アイデンティティ

各タンクは自分のサブスクリプションを投入します。 タンクをまたいでファンアウトすると、メインの対話セッションの予算ではなく、各アカウントのクォータが消費されます。これこそが狙いです — 高価な監督役は眠ったまま、安価なワーカーがガスの残っているアカウントを投入します。
切れたときの扱い。 burn は切れに当たると次の予備タンクへ自動で再ルーティングします（アカウントを意識します。すでに切れたログインを共有する兄弟タンクや、対話セッションが生きているタンクは飛ばします）。conduct は再ルーティングしません — 各レッグを捕捉済み／切れ／空として報告するので、あなたが判断します。
同一アカウント内のファンアウトは 1 つのバケツを共有します。 同じタンク上の 3 つのレッグは並列に走りますが、引くクォータは 1 つです — 速さ（実時間の並列）であって、 3 倍のスループットではなく、まとめて切れます。独立したクォータがほしいなら、別々の アカウントにファンアウトしてください。
書き込みジョブの git アイデンティティ。 コミットする --write レッグを振り分ける前に、タンクのアイデンティティを設定し、コミットがエンジンのアカウントメールで刻まれないようにしましょう。clikae git-id claude L --name "You" --email you@example.com。すると clikae env（--tank がこれに乗ります）が、そのシェル向けに GIT_AUTHOR_* / GIT_COMMITTER_* をエクスポートします。

7. 境界線 — まだ人間が必要なこと

clikae が証明するのは配管です。ジョブが走った、どのアカウントで、どのファイルを生み出した、ということ。判断できないのは次の点です。

出力の品質 — 監査が正しいか、生成されたコードが良いか。中立な採点者（別のモデル、またはあなた）が決めます。
実行時の振る舞い — 描画される UI、応答するサーバー。burn が向くのは、成功が 名指しできるファイル であるタスクだけです。
出力のように見える API エラー。 stdout に書かれた一時的な API Error: … という文字列は空ではないので、素朴な「出力があるか」チェックは成功と読み違えかねません — 短い結果は、信用する前にざっと目を通してください。

この、どうしても残る人間（または独立したモデル）の判断は、欠陥ではなく機能です。 clikae はスイッチャーのまま、指揮者は頭脳のままでいられます。

8. タスクのリスクに応じたモデル階層分け

実際のマルチモデル艦隊でのドッグフーディング（claude + codex + agy をまたいだアプリのフルビルド）から、どのモデル階層をどこに置くかの実用ルールが得られました。

役割	モデル階層	理由
オーケストレーター／検証役	高性能（例: claude Max）	計画を立て、出力を判断し、タスクをまたぐ決定を下す — ここでのミスは連鎖する
実装役	中堅（例: claude Sonnet / codex）	新規で信頼が要となる作業: 新しい統合コード、セキュリティに隣接する経路
機械的な力仕事	安価（例: stdin 経由の agy、Sonnet 未満のモデル）	整形、要約、定型 — すでに十分に仕様化され、検証も容易

レッドライン: 新規で信頼が要となる統合作業では、中堅を下回ってはいけません。「安価」が理にかなうのは、出力を目視やテストで完全に検証できるタスクです。微妙なバグを捕まえるのに検証役自身が実装役と同等の能力を要するようなタスクでは、危険です。

並列 ≠ 冗長。 同じタスクを同じ階層でアカウントにまたいでファンアウトすると、速さ＋タンク切れのフォールバックは得られますが、正しさの多数決にはなりません。正しさの多数決がほしいなら、clikae conduct を使い、レッグごとに 異なる モデル階層を割り当ててください — そして、出力を生み出したのと同じモデルではなく、中立な第三のモデルが採点します。

9. 独立した検証 — 中立採点者の原則

オーケストレーターは、サブエージェントの自己申告を鵜呑みにせず、その主張を 独立して検証 しなければなりません。出力を生み出したモデルは、その出力が正しいかどうかの判断役としては不適だからです。微妙な誤りを犯していてもなお、自分の成果を自信たっぷりに高く評価しがちです（「自信満々で間違う」という失敗モード）。

clikae 艦隊での実践的なチェックです。

「完了」の自己申告を信じる前に、成果物を直接 grep / stat する。 ファイルが存在しない、または空なら、エージェントが何と言おうとジョブは失敗です。
書き込みレッグのあとは、テストスイートか狙いを定めた不変条件チェックを オーケストレーターから走らせる — コードを書いたのと同じレッグからではなく。
clikae conduct を使い（同じタスクを N レッグ）、出力を別のモデルに採点役として通す — 推論ではなく出力だけを見るモデルに。N 個の盲検出力を読む採点者は、生み出した側の自己評価が見落とす誤りを見つけます。
口調から正しさを推測しないこと。 自信に満ちて整った完了メッセージ（「X を実装し、テストを追加し、ドキュメントも更新しました」）は、実装が正しい証拠にはなりません。不変条件を grep し、バイナリを走らせてください。

オーケストレーターの仕事は、ワーカー自身が持てない認識上の基準を、代わりに保つことです。

8. 手早いレシピ集

# アカウントをまたぐ best-of-N 監査 — 読み取り専用、並列、勝者はあなたが選ぶ
clikae conduct --prompt-file review.md \
  --leg codex/H --leg claude/C --leg claude/L --add-dir "$PWD"

# タンクが切れたら自動でフェイルオーバーするヘッドレスのコード生成
clikae burn claude C --artifact out/feature.ts \
  --prompt-file task.md --add-dir "$PWD" --timeout 900

# 壁に当たったら生きたセッションをそのまま先へ運ぶ（同じエンジンなら会話を再開、別なら要約ブリーフ）
clikae to L          # 次の満タンのタンクへ、会話はそのまま
clikae to codex      # ベンダーをまたぐ: 端末上で要約された書面ブリーフ

あわせてどうぞ: grammar.md（言語）、usage.md（完全リファレンス）、 EXPECTATIONS.md（「これはバグ？」— 意図的な驚き）、そしてセッション主導のレッグルーティングのための conductor Claude Code スキル。

clikae をヘッドレスで動かす — オーケストレーションの手引き