オーケストレーションとは

tako の目玉機能である「オーケストレーション」を、予備知識ゼロから説明します。実際の使い方は tako master 実践ガイドを参照してください。

そもそもオーケストレーションとは

オーケストラでは、指揮者が全体を見渡し、演奏者それぞれに役割を与えて 1 つの曲を作り上げます。AI 開発におけるオーケストレーションも同じ発想です。

• 指揮者（master）: あなたの指示を受け取り、作業を分解して割り振る AI
• 演奏者（worker）: 割り振られた作業を実際にこなす AI たち

Claude Code のような AI エージェントは、1 人でも十分に優秀です。しかし 1 人である以上、「A プロジェクトのバグ修正」と「B プロジェクトのドキュメント更新」を同時には進められません。そこで、司令塔となる AI（master）に依頼を投げ、master が作業ごとに担当 AI（worker）を立ち上げて並列に働かせる——これがオーケストレーションです。

あなたがやることは、master に日本語で話しかけることだけです。

「webapp のログイン周りにテストを追加して。あと docs サイトの誤字も直しておいて」

master はこの依頼を 2 つの作業に分解し、それぞれの worker を起動して、完了を見届けて報告してくれます。worker をどう立ち上げるか・どう監視するか・終わったらどう片付けるか——そうした段取りはすべて master が自動でこなすので、あなたが覚えることはありません。

なぜターミナルに組み込むのか

オーケストレーション自体は、スクリプトや tmux を駆使すれば自作もできます。しかし実際にやってみると、こんな壁にぶつかります。

• worker がどこで動いているのか見えない。進捗はログを掘らないと分からない
• worker が質問待ちで止まっていることに気づけない
• 環境構築が大変。tmux・スクリプト・MCP 設定を自分で繋ぎ込む必要がある

tako はターミナル自身がオーケストレーションの舞台になることで、この壁をまとめて解決します。外部スクリプト依存ゼロ、tako master の 1 コマンドで始められます。

tako のオーケストレーション体験

作業が目の前で見える

master が worker を起動すると、同じタブの中でペインが分割され、worker の画面がそのまま現れます。worker が今何を考え、どんなコマンドを打っているかがリアルタイムで見える。ブラックボックスの中で何かが起きているのではなく、オーケストラの演奏を客席から眺めるように、複数の AI が並んで働く様子を一望できます。

┌─ master タブ ──────────────────────────────┐
│ ┌────────────┬──────────────┬─────────────┐ │
│ │  master    │  worker 1    │  worker 2   │ │
│ │  （司令塔）  │  テスト追加中… │  誤字修正中… │ │
│ └────────────┴──────────────┴─────────────┘ │
└─────────────────────────────────────────────┘

気になる worker があれば、そのペインをクリックして直接会話に割り込むこともできます。「あ、その方針じゃなくてこっちで」と、現場に降りて口を出せるのは、画面がそこにあるからこそです。

左が司令塔の master、右が担当の worker 2 体。誰が何をしているかが 1 画面で分かる

監視と回収まで自動で起きる

worker を起動しっぱなしで放置しない、が tako の設計です。あなたが依頼を出すと、裏ではこんなことが自動で起きています。

• master が依頼内容から対象プロジェクトを判断し、その作業ディレクトリで worker を起動する
• 指示文は送達確認付きで worker に渡される。「指示が入力欄に残ったまま Enter が空振りしていた」という自作スクリプトにありがちな事故は仕組みで防がれる
• master は worker の完了・入力待ち・消滅を自動で検知し、結果を確認してあなたに報告、役目を終えたペインを片付ける

あなたは最初の依頼と、最後の報告の確認だけ。途中経過は「見たければ見える」状態で流れていきます。

右パネルの orch ビュー。master と worker の親子関係・稼働時間・コンテキスト使用率を俯瞰できる

品質は仕組みで作り込まれる

master は「worker に投げて終わり」の司令塔ではありません。依頼から報告までの各段階に、品質の関門が組み込まれています。

• 依頼はまず分解する — 1 メッセージに複数の依頼が入っていたら、master は独立した成果物ごとに worker を分けます（1 worker = 1 成果物）。まとめて 1 体に投げて全部が中途半端になる事故を、手順で防ぎます。分担計画は spawn 前に 1 行ずつ提示されるので、意図と違えばその場で止められます
• worker への指示は「型」で渡す — 背景・スコープ・受け入れ条件・検証手順・報告様式まで埋めた定型プロンプトで指示します。worker は完了報告の前にビルド・テスト・実際の動作確認を義務付けられます。「ビルドが通った ≠ 動く」が前提です
• master が検収してから報告する — worker の「完了しました」を鵜呑みにせず、受け入れ条件ごとの証拠（実行したコマンドと出力・diff）を master が検査してからあなたに届けます。検証できなかった領域（UI の見た目や実機依存の挙動など）は「未検証」と正直に伝えます

設定ファイルを触らなくていい

どのプロジェクトを管理対象にするか、どのモデルで動かすか——こうした設定も、master に日本語で頼むだけです。

「~/Documents/api-server のリポジトリも管理対象に追加して」

master が設定ファイルへの登録まで済ませてくれます。YAML を開いて手で書く必要はありません。

再起動しても壊れない

worker たちは tmux バックエンドの上で動いています。長時間タスクの途中で tako を閉じても、worker のプロセスは裏で生き続け、次回起動時に画面ごと復元されます。「一晩かかる作業を任せて寝る」が現実的にできます。

プロジェクトをまたげる

worker はそれぞれ別の作業ディレクトリで動けます。フロントエンドのリポジトリ、API サーバーのリポジトリ、ドキュメントのリポジトリ——複数プロジェクトを 1 人（1 匹？）の master に任せて、タブ 1 つで面倒を見られます。

1 対 1 で十分なら tako solo

worker への分担が要らず、AI と 1 対 1 で直接作業したいだけのときは tako solo を使います。オーケストレーション（worker の起動）をあえて禁止し、その AI 自身が手を動かして——ファイルを読み、コードを書き、テストを走らせ、コミットまで——直接こなします。

tako solo            # そのまま起動
tako solo -fast      # プロファイルを指定して起動

master と同じく projects.yaml を把握しているので、cd で移動しなくても「demo の README を直して」のようにプロジェクト名で話しかけられます。トークン消費を抑えたエコ設計（既定の思考量は master より控えめ）です。「まず 1 つのことを AI に任せたい」なら solo、「複数を並行で回したい」なら master、と覚えておけば十分です。

3 分で始める

# 1. セットアップ（未実施なら。検出・前回値・既定値で質問ゼロ）
tako setup

# 2. master を起動（1 対 1 でよければ tako solo）
tako master

今いるペインに、profile で選ばれた master（claude または codex）が立ち上がります（専用タブにしたいときは tako master --tab）。あとは話しかけるだけです。

「~/Documents/webapp のリポジトリを管理対象に追加して、README を最新のコマンド体系に合わせて書き直して」

ペインが割れ、worker が現れ、作業が始まる——その様子をぜひ一度眺めてみてください。

次に読む

• クイックスタート — 最短 3 ステップの体験手順
• tako master 実践ガイド — 話しかけ方の実例・つまずきポイント・仕組みの詳細
• 内蔵 MCP サーバー — オーケストレーションを支える AI 連携の仕組み