tako master 実践ガイド

tako master は、tako のオーケストレーション機能の入口となるコマンドです。このページでは、起動すると何が起きるか・起動後にどう話しかければいいか・つまずきやすい点を、実際の会話例つきで解説します。「そもそもオーケストレーションとは何か」から知りたい方は、先にオーケストレーションとはをご覧ください。

大前提: あなたが覚えるのは 1 コマンドだけ

tako master

これだけです。プロジェクトの登録も、モデルの設定も、worker の起動・監視・片付けも、すべて master に日本語で頼めば master がやってくれます。設定ファイルを開く必要はありません。

`tako master` で何が起きるか

tako 内のターミナルで tako master を実行すると、次のことが自動で行われます。

今いるペインが master になる — 既定では新しいタブを作らず、その場で司令塔が立ち上がります。以後このタブがオーケストレーションの舞台です（専用タブを立てたいときは tako master --tab）
司令塔モードで起動する — 司令塔としての指示書（system prompt）付きで起動するため、普通のエージェントと違い「自分で手を動かさず、worker に作業を委任して監視する」動き方をします
プロファイル（モデル設定）が読み込まれる — 既定は「エージェント CLI の既定モデル / worker は master と同じ」。どのプランでもそのまま動きます

起動時にはプロファイル名と解決されたモデル・思考量（effort）、アカウントを指定していればその名前も表示されます。あとは master のペインに向かって、やってほしいことを話しかけるだけです。

master ペインと 2 つの worker ペイン、右パネルの orch ビューが同時に表示されている画面 — `tako master` を起動すると、あとは会話するだけ。worker の追加も監視も master がやる

話しかけ方 — 会話例

まずはプロジェクトを覚えてもらう

master が作業できるのは「管理対象として登録されたプロジェクト」です。登録も会話で頼みます。

あなた: 「~/Documents/webapp にあるリポジトリを管理対象に追加して。Web アプリのフロントエンドだよ」

master: webapp を管理対象に追加しました（cwd: ~/Documents/webapp）。何か作業しますか？

これで master は以後「webapp」という呼び名でこのプロジェクトを扱えます。削除や一覧も「webapp を管理対象から外して」「今どのプロジェクトを管理してる？」と聞くだけです。

作業を依頼する

あなた: 「webapp のログインページのテストが落ちてるみたいだから直しておいて」

master は worker を隣のペインに起動し、指示を渡し、完了を検知して結果を報告します。あなたは待つだけ。worker の画面はペインとして見えているので、途中経過を眺めることも、気になったらそのペインをクリックして直接口を出すこともできます。

複数の作業を並行で頼む

あなた: 「webapp のバグ修正と、docs の誤字直しを並行で進めて」

独立した作業なら、master は依頼を成果物ごとに分解し（1 worker = 1 成果物）、分担計画を提示してから worker を複数同時に立ち上げて並列に進めます。1 体にまとめて投げて両方が中途半端になる、という事故は手順で防がれています。

進捗を聞く・割り込む

あなた: 「worker どうなってる？」

master: worker 1（バグ修正）は実行中、worker 2（誤字直し）は完了しています。結果は……

worker が質問待ちで止まったときも master が気づいて伝えてくれます。worker のペインを直接クリックして、自分で答えても構いません。

設定画面のプロファイルタブ。master / solo の切り替え、エージェント・モデル・思考の深さ・アカウントの設定項目が並んでいる — 会話で頼めば master が設定してくれるが、画面（`Cmd`+`,` → プロファイル）から直接編集することもできる

設定も会話で変える

あなた: 「worker は軽いモデルで動かしたい」

モデルや思考量（effort）の設定も master に頼めば変更してくれます。YAML を手で編集する必要はありません（後述のとおり、直接編集したい上級者向けの道も残っています）。

複数マスター・プロファイル切替

# プロファイルを指定して起動（profiles/fast.yaml の設定を使う）
tako master -fast

# ラベルを付けて複数マスターを区別する（"master-frontend" タブになる）
tako master frontend
tako master backend

各マスターは自分が起動した worker を識別して監視するため、「フロントエンド担当」「バックエンド担当」のように役割の違うマスターを並走させられます。プロファイル自体の作成・変更も、tako setup や master への依頼で行えます。

つまずきポイント

「接続情報が見つからない」と言われる

tako master は tako アプリが起動している状態で、tako の中のターミナルから実行してください。tako の外の通常のターミナルからは操作できません。

claude が起動しない・ログインを求められる

master の実体は既定では Claude Code（claude コマンド）です。未インストール・未ログインの場合は先に tako setup を実行するか、Claude Code のドキュメントに従って導入してください。

なお、プロファイルに master_agent: codex を設定すると master を OpenAI Codex CLI で起動することもできます（tako の MCP ツールに接続された状態で立ち上がります）。その場合は codex CLI の導入とログインが必要です。

「このモデルは使えない」と言われて master が落ちる

プロファイルに [1m] 付きモデル（1M コンテキスト版）が設定されていると、Max / API プラン以外では起動できません。起動時に警告も表示されます。master に「モデル指定を解除して」と頼むか、tako setup --review、または次のコマンドで claude 既定モデル（全プランで動作）に戻せます。

tako orchestrator profiles set default --clear-model

依頼したのに worker が動き出さない

対象プロジェクトが未登録の可能性があります。「今どのプロジェクトを管理してる？」と master に聞いてみてください。未登録なら「◯◯のリポジトリを追加して」と頼むだけです。

tako を閉じてしまった / Mac を再起動した

tmux がインストールされていれば、worker のプロセスは裏で生き続け、tako を再起動すると画面ごと復元されます。詳しくは tmux バックエンドを参照してください。

仕組みの補足（読まなくても使えます）

master が裏でやっていることを少しだけ紹介します。すべて自動なので、知らなくても困りません。

依頼の分解: 1 メッセージに複数の依頼があれば、master は成果物ごとに worker を分けます（1 worker = 1 成果物）。spawn 前に分担計画が提示されるので、意図と違えばその場で止められます
worker の起動: master は依頼から対象プロジェクトを判断し、そのディレクトリで claude を新しいペインに起動して指示を渡します。指示は背景・スコープ・受け入れ条件・検証手順・報告様式まで埋めた定型の「型」で渡されます
確実な指示出し: 指示文は「貼り付け → Enter 送信 → 入力欄が空になったかの検証（残っていれば再送）」という送達確認ループで配送されます。長いマルチライン指示が入力欄に残ったまま放置される事故を仕組みで防いでいます。初回フォルダの信頼確認ダイアログも起動前に自動処理されます
監視と回収: master は worker の完了・入力待ち・消滅を自動検知し、出力を読み取って報告し、役目を終えたペインを片付けます
検収してから報告: worker の「完了しました」は鵜呑みにされません。master が受け入れ条件ごとの証拠（実行コマンドと出力・diff）を検査してから、結果があなたに届きます。検証できない項目は「未検証」と明示されます
worker は使い捨て: タスクごとに新しい worker を立てるのが master の流儀です。コンテキストが混ざらず、失敗の切り分けも簡単になります

設定ファイルの場所（上級者・AI 向けの参考情報）

通常は master や MCP tako_setup に頼めば済みますが、設定の実体はすべて ~/Library/Application Support/tako/orchestrator/ 配下のファイルです。直接編集しても構いません。

ファイル	中身
`projects.yaml`	管理対象プロジェクトの登録（key・作業ディレクトリ・説明）
`profiles/<名前>.yaml`	master / worker のエージェント CLI・モデル・effort・worker ポリシー。起動設定の唯一の正
`accounts.yaml`	worker ごとに使い分けるアカウントの登録（`tako orchestrator accounts`）
`workers.yaml`	spawn 済み worker のレジストリ（ペインが消えても追跡できる）
`config.yaml`	セットアップ状態と挙動フラグ（auto_close / auto_push）
`master-system.md`	（置いた場合のみ）master の system prompt を差し替えるカスタムファイル
`conflict-resolver.md`	（置いた場合のみ）git コンフリクト解消エージェントへ渡す文面

worker のモデルはプロファイルの worker_model_policy で決まります: inherit（master と同じ・既定）/ fixed（別の固定モデル）/ delegate（master がタスク内容を見て判断）。master / worker のエージェント CLI は master_agent（claude / codex）・worker_agent（claude / codex / agy）で選べます。master が claude 以外のときは、プロファイルの model / effort は claude worker へ継承されません。

CLI から手動で操作したい場合は CLI リファレンスを参照してください。master が内部で使っているのと同じ操作を、スクリプトからも実行できます。

worker を見失わない仕組み

spawn した worker は workers.yaml のレジストリに記録されます。ペインを閉じてしまっても、tako を再起動しても、worker は ID で追跡し続けられます。

tako orchestrator workers            # spawn 済み worker の一覧（ペインの生死と無関係）
tako orchestrator watch --worker <ID> # ペインが消えた後でも完了を待てる
tako orchestrator report --worker <ID> # 報告内容を取り出す

worker が権限確認のダイアログで止まっているときは WORKER_PERMISSION として検知され、tako orchestrator respond で応答できます。master はこれを自動で扱うので、通常は意識する必要はありません。