---
title: オーケストレーション
description: clikae burn と conduct で、ヘッドレスな作業を複数のアカウントに振り分けます。
section: Guides
order: 1
---

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

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

もしあなたがこのページを読んでいるエージェントなら、ここが契約書です。§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`](https://github.com/CVERInc/clikae) という 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 タンクを並列に走らせることはできません）。

```bash
# 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`](agy-dispatch) — を読んでください。** これは本物の有料
エンジンです。このレシピが、無駄遣いを止める方法です。

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

1. **判断は成果物／出力で行い、終了コードを当てにしないこと。** ヘッドレスの
   `codex exec` や `claude -p` は、使用上限に当たって何も書かなかったときでも `0` を
   返して終了します。`burn` は成果物の存在＋新しい mtime で、`conduct` は捕捉した出力で、
   レッグは `--out` の中身で判断します。`$?` を決して信用しないでください。

2. **タスクには楽な道を与えること — エンジンのフラグを手組みしないこと。**
   `--prompt-file <f>`（または `--prompt`）＋ `--add-dir <dir>` を使えば、clikae が各エンジンの
   ヘッドレス書き込み方言を埋めてくれます（`claude` の `-p …
   --dangerously-skip-permissions --add-dir`、`codex` の `exec -C … -s
   workspace-write`）。`-- -p '…'` を手書きするのは、*書き込めない* ジョブを出荷する
   いちばんの近道です（§4 参照）。

3. **成果物は、タスクが本当に生み出すファイルでなければならない。** `burn` は
   `--artifact` が現れたとき（または mtime が変わったとき）に成功とみなします。コード生成
   タスクの成果物は *実際に書かれるコードファイル* であって、ついでに出してくれたらいいなと
   思っている `/tmp/report.md` ではありません。`--artifact` は本当の出力を指してください。
   さもないと、`burn` は本物の成功を失敗と呼んでしまいます。

4. **正しいリポジトリを指すこと。** 書き込みタスクには `--add-dir <repo>` が必要です
   （clikae がこれをエンジンの書き込み権限＋作業ディレクトリのフラグに変換します）。
   `--add-dir` なしで間違ったディレクトリから走らせると、エンジンはあなたのファイルすら
   見えません。

5. **複数行のプロンプトは `--prompt-file` を通すこと。** プロンプトはデータとして
   渡されるので（内部では NUL で区切られます）、複数行のプロンプトもそのまま残ります。
   段落をシェルでクォートした `-p '…'` に詰め込もうとしないでください。

6. **入力はあらかじめ `/tmp` に置き、タスクを冪等にすること。** 投入されるタンクに、
   遅い iCloud バックアップの I/O を渡してはいけません。また、成果物で検証できる冪等な
   タスクなら、あるタンクが切れても別のタンクで無料で再実行できます。

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

実際に見かけた例です。

```bash
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 つの危険信号があります。

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

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

```bash
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` で停止）。このカウントはシェル単位で、
タンクは意識しません。*いくつ* ジョブがあるかを教えてくれ、それぞれが *何か* はマネージャが
見せてくれます。

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

```bash
# 先頭に [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. 手早いレシピ集

```bash
# アカウントをまたぐ 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](grammar)（言語）、[usage.md](usage)（完全リファレンス）、
[EXPECTATIONS.md](EXPECTATIONS)（「これはバグ？」— 意図的な驚き）、そしてセッション主導の
レッグルーティングのための `conductor` Claude Code スキル。
