--- title: "TAKTとは？AIエージェントを指揮するOSSの使い方とYAMLワークフロー【2026年10月】" url: "https://www.issoh.co.jp/tech/details/12666/" published: 2026-06-22 updated: 2026-10-17 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # TAKTとは？AIエージェントを指揮するOSSの使い方とYAMLワークフロー【2026年10月】 TAKTは、エンジニアのnrslib（成瀬允宣）氏が公開しているオープンソースのCLIです。Claude CodeやCodexなどのAIコーディングエージェントに、計画→実装→レビュー→修正という工程をYAMLのワークフローどおりに踏ませます。公式READMEの言葉では「AI はコードを書きますが、次に何をするかは workflow が決めます」。この記事では、2026年10月15日公開のv0.71.0を手元に入れて動かした結果をもとに、導入手順、ワークフローの書き方、ここ3か月の破壊的変更、類似ツールとの違いを整理します。なお、製造業の「タクトタイム」、ゲームの「takt op.」、デンマークの家具ブランド「TAKT」とは別物です。 ## まとめ：TAKTの要点と導入判断（v0.71.0時点） - TAKTはMITライセンスのTypeScript製OSS。AIエージェントを信頼して任せるのではなく、stepと遷移ルールを書いたYAMLで外側から制御する。 - 導入は`npm install -g takt`のあとに`takt install claude-sdk`が必要。v0.71.0からSDKを同梱しなくなり、入れないと実行時に止まる。Node.jsは22.22.0以上。 - 2026年7月19日のv0.52.0から10月15日のv0.71.0まで、npmへの公開は27回。既定providerの変更やworkflow YAMLの構文削除が含まれるので、チームで使うなら版を固定する。 - 書いたYAMLは`takt workflow doctor`で実行前に検証できる。存在しないpersona、遷移先の誤記、廃止された`provider`キーはここで止まる。 - 向いているのは、同じ品質保証の工程を毎日回すチーム。単発の修正や捨てるプロトタイプでは、ワークフローを書く手間を回収できない。 以下、基本情報、導入、YAMLの書き方、検証の実測、コマンドの使い分け、類似ツール比較の順に説明します。 ## TAKTの基本情報：作者・ライセンス・設計の考え方 ### nrslib（成瀬允宣）氏のOSS・MITライセンス・Node.js 22.22.0以上 TAKTはGitHubの[nrslib/takt](https://github.com/nrslib/takt)で開発され、npmの`takt`パッケージとして配布されています。npmの初版（0.1.0）は2026年1月25日です。実装はTypeScriptで、ライセンスはMITなので商用利用も改変もできます。npmのパッケージ定義では動作要件が`node >=22.22.0`です。名前は「TAKT Agent Koordination Topology」の頭字語で、オーケストラの指揮で拍を刻む意味のドイツ語「Takt（タクト）」にも掛けています。 ### 「AIを信頼せず外側から制御する」設計と通常のエージェントとの違い READMEは、プロンプトや`CLAUDE.md`やスキルにルールを書き足しても「プロセスを強制できない」と書いています。守るかどうかをAI自身の振る舞いに委ねることになるからです。TAKTはそこで工程をYAMLに移し、stepごとに役割・文脈・権限・遷移ルールを渡します。[公式READMEの日本語版](https://github.com/nrslib/takt/blob/main/docs/README.ja.md)にある対比を要約すると次のとおりです。 | 観点 | 通常のAIコーディングエージェント | TAKT | | ------ | ----------------- | ----------------- | | 工程の管理 | プロンプトでお願いする | YAMLのworkflowが決める | | レビュー | 忘れる・飛ばすことがある | 遷移として強制される | | コンテキスト | 1本が肥大化し続ける | stepごとに必要な分だけ渡す | | 作業場所 | カレントツリーに直接入る | 既定で隔離worktree | | 追跡 | 経路を追いにくい | ログとレポートが残る | TAKTはAIの裁量を減らす側に立っています。レビュー飛ばしのような取りこぼしはモデルの賢さでは防げない、という立場です。 ## TAKTのインストールと始め方：v0.71で変わった手順 ### npm install -g taktからtakt runまでの最小手順 少なくとも1回コミット済みのGitリポジトリで実行します。初回はproviderの認証も必要です。既定のclaude-sdkをAPIキーで使う場合は、環境変数`TAKT_ANTHROPIC_API_KEY`を設定してください。v0.71.0のREADMEにある「5分で試す」の手順を、版を0.71.0に固定して書くと次の5行です。 ``` npm install -g takt@0.71.0 takt install claude-sdk # 既定providerのSDKを入れる（v0.71.0から必須） takt # AIと会話してタスクを決め、/go のあと「タスクにつむ」を選ぶ takt run # 積んだタスクを隔離worktreeで実行する takt list # 差分の確認・マージ・リトライ・削除 ``` `takt`で会話を始め、`/go`で指示書を作ると「タスクにつむ／Issueを建てる／その場で実行する／会話を続ける」のメニューが出ます。既定は「タスクにつむ」で、タスクは`.takt/tasks/`に保存されます。`takt run`は[Claude Codeのgit worktreeで並列エージェント開発を行う方法](/tech/details/11708/)と同じ考え方で、作業ブランチ側のworktreeで計画→実装→レビュー→修正を回し、終わるとPRを作るか尋ねます。`takt add '#6'`のようにGitHub Issueからタスクを積むこともでき、その場合は`gh`コマンドが必要です。 ### takt installを忘れたときに出るエラー（実測） v0.71.0の[CHANGELOG](https://github.com/nrslib/takt/blob/main/docs/CHANGELOG.ja.md)は、Claude Agent SDK・Codex SDK・OpenCode SDK・Pi SDKを本体と一緒に入れないようにした変更をBREAKINGとしています。v0.70以前の手順書どおり`npm install -g takt`だけで止めると、どうなるかを確かめました。SDKを入れていない環境で非対話のパイプラインモードを実行すると、最初のstepに入る前に終了コード3で止まります。 ``` $ takt --pipeline --skip-git -w pir -t "README.mdを作成する" === Running Workflow: plan-implement-review === [ERROR] Managed provider claude-sdk is not installed or failed an integrity check. Run `takt install claude-sdk`. [ERROR] Workflow 'pir' failed ``` 端末で対話的に使うときはインストールするか確認されますが、CIや`takt watch`のような非対話の実行ではこのメッセージで止まります。GitHub Actionsなどでは、ジョブの中で先に`takt install claude-sdk`を実行してください。TAKTを更新したら、SDKを固定版にそろえる`takt update`も必要です（v0.71.0が固定している版はClaude Agent SDK 0.3.300、Codex SDK 0.162.1）。 ### providerの選び方：SDK経由とCLI経由の違い TAKTは特定のAIに縛られません。providerは、Node.jsだけで動くSDK経由と、外部CLIを呼ぶCLI経由に分かれます。v0.68.0で既定が従来のClaude Code CLIから[Claude Agent SDK](/tech/details/7451/)を使う`claude-sdk`に変わり、`provider: claude`は`claude-sdk`の別名になりました。 | 区分 | provider名 | 必要なもの | | ------- | ----------------------- | -------------------------------------------------------------- | | SDK経由 | claude-sdk（既定）・codex・pi | takt install | | SDK経由 | deepseek-harness | takt install・Linux x64/arm64（glibc 2.28以上）・macOS arm64（14.0以上） | | SDK＋CLI | opencode | takt install・OpenCode CLI | | CLI経由 | claude-headless | Claude Code | | CLI経由 | claude-terminal | Claude Code・tmux | | CLI経由 | copilot・cursor・kiro | 各社のCLI | | テスト用 | mock | なし | 最小の設定は`~/.takt/config.yaml`に`provider`・`model`・`language`の3行を書くだけです。これまでClaude Code CLIで動かしていた人は、`provider: claude-headless`へ書き換えないと挙動が変わります。権限設定も`provider_profiles.claude`から`provider_profiles.claude-sdk`（またはclaude-headless）へ移す必要があります。stepごとにproviderやモデルを変えたいときは、`~/.takt/runtime.yaml`か`.takt/runtime.yaml`に書きます（プロジェクト側が優先）。 ## YAMLワークフローの書き方：step・rules・persona・loop\_monitors ### 計画→実装→レビューを回す最小のworkflow workflowはstepの並びで、各stepに担当するpersona、編集の可否（`edit`）、次へ進む条件（`rules`）を書きます。`COMPLETE`が成功終了、`ABORT`が失敗終了です。READMEの最小例を、ビルトインに実在するpersona名（後述）に直したものが次のYAMLで、`.takt/workflows/pir.yaml`に置きました。 ``` name: plan-implement-review initial_step: plan max_steps: 10 steps: - name: plan persona: planner edit: false rules: - condition: Planning complete next: implement - name: implement persona: coder edit: true required_permission_mode: edit rules: - condition: Implementation complete next: review - name: review persona: coding-reviewer edit: false rules: - condition: Approved next: COMPLETE - condition: Needs fix next: implement # レビューで差し戻されたら実装へ戻る ``` レビュー役には`edit: false`を指定します。ただし、実効的な編集制限はproviderと権限設定にも依存します。たとえばCodexで`permission_control: codex`を選ぶ場合は、Codex側のサンドボックス設定も確認してください。`max_steps`はrun全体のstep実行回数の上限で、レビュー⇄修正が収束しないときの最後の歯止めになります。 ### rulesの評価順とrule\_no\_matchで止まる条件 [Workflowガイド](https://github.com/nrslib/takt/blob/main/docs/workflows.ja.md)によると、rulesはYAMLに書いた順に評価され、最初に成立したものが採用されます。暗黙の優先順位やフォールバック遷移は無く、どれも成立しなければworkflowは`rule_no_match`でABORTします。 これをAIを呼ばずに確かめるため、上のYAMLをテスト用の`mock` providerで実行しました。rulesが1つしかないplanとimplementは`auto_select`でそのまま次へ進みました。2つあるreviewでは、ビルトインの`conductor` personaが出力をどの条件に当てはめるかを判定し、mockの定型応答がどちらにも当たらなかったため、`Workflow failed after 3 iterations (4.0s): rule_no_match`で終了しました。分岐を作るときは「どれにも当てはまらない出力」が来る前提で、受け皿の遷移を用意しておく必要があります。 実際の運用でも、「OKなら次へ／NGなら全体を中断」の2択にしたところ、厳しいレビュアーが5回連続で中断させたという[利用者の報告](https://zenn.dev/coji/articles/takt-multi-agent-coding-experience)があります。差し戻しの遷移（上の例では`Needs fix`→`implement`）を用意し、`ABORT`は本当に続けられないときだけにするのが安全です。 ### persona・policy・knowledge・instruction・output contractの5ファセット エージェントへの指示は、Faceted Promptingという考え方で5つに分けます。誰として振る舞うか（persona）、守るルール（policy）、参照する知識（knowledge）、そのstepの具体的な指示（instruction）、成果物の形（output contract）です。必要なstepに必要なファセットだけを渡すので、1本の長いプロンプトにすべてを詰め込むより文脈が汚れません。自作のファセットは`~/.takt/facets/personas/`のようにMarkdownで置き、workflowから`persona: my-reviewer`のように名前で参照します。 v0.71.0で`takt catalog personas`を実行すると、ビルトインのpersonaは29個ありました。planner・coder・coding-reviewer・architecture-reviewer・security-reviewer・testing-reviewer・supervisorなどです。READMEの最小例にある`reviewer`はこの一覧に無いので、そのまま使うと次の章の検証で止まります。 ### loop\_monitorsによるレビュー・修正ループの進捗判定 レビュー⇄修正を遷移で強制すると、指摘と修正が噛み合わずに同じ往復を繰り返すことがあります。`loop_monitors`は、指定したstepの循環が`threshold`回に達したら判定役のpersonaに進捗の有無を評価させ、進捗が無ければ打ち切る仕組みです。前掲の`pir.yaml`の末尾（`steps`と同じ階層）に次のブロックを足すと、reviewとimplementの往復を監視できます（このブロックを足したYAMLも`takt workflow doctor`で終了コード0を確認）。 ``` loop_monitors: - cycle: [review, implement] threshold: 3 judge: persona: supervisor instruction: "implement ループに進捗があるかを評価してください" rules: - condition: "進捗あり" next: implement - condition: "進捗なし" next: ABORT ``` `max_steps`が回数で止める上限なのに対し、`loop_monitors`は中身を見て止めます。両方を設定しておくと、無駄なトークン消費を早めに切れます。 ## takt workflow doctorによるYAMLの静的検証結果（実測） v0.71.0には、workflowの雛形を作る`takt workflow init`と、定義を静的に検証する`takt workflow doctor`があります。AIを1回も呼ばずに動くので、書いたYAMLをコミットする前やCIで確かめるのに使えます。macOS・Node.js v26.5.0・takt 0.71.0の環境で、4種類のYAMLを検証した結果が次の表です（2026年10月16日）。 | 検証したYAML | 終了コード | 出力 | | --------------------------- | ----- | ---------------------------------------------- | | workflow initの雛形 | 0 | Workflow OK | | READMEの最小例そのまま | 1 | persona references missing resource “reviewer” | | next: implementをimplemntと誤記 | 1 | routes to unknown next step／Unreachable steps | | workflowにprovider: codexを追加 | 1 | Unrecognized key: “provider” | 2行目は、公式の例でも実在しないpersona名なら止まることを示しています。personaを`coding-reviewer`に直すと終了コード0になりました。3行目では誤記した遷移先だけでなく、その結果どこからも到達できなくなったstep（implementとreview）も列挙されました。 4行目は版の追随で効きます。v0.60.0で`provider`・`model`・`provider_options`などの実行設定がworkflow YAMLから削除され、`runtime.yaml`へ移りました。それ以前に書かれた解説記事のYAMLをそのまま写すと、このエラーで読み込みに失敗します。版を上げたら、まず手持ちのworkflowすべてに`takt workflow doctor`をかけるのが確実です。 もう一つ確認できたのは、`takt workflow init`が`.takt/.gitignore`も作ることです。中身は「すべて無視したうえで、`config.yaml`・`workflows/`・`steps/`・`facets/`だけを追跡する」設定でした。タスクの指示書や`.takt/runs/`の実行ログはGitの追跡から外れ、リポジトリに載せられるのはこの`.gitignore`自身と上の4種類です。 ## TAKTの主要コマンドと使い分け ### takt run・exec・make・watchの違い v0.71.0の`takt --help`には24個のサブコマンドが並びます。日常的に使うのは次のコマンドです。 | コマンド | 用途 | 追加された版 | | --------------- | ----------------- | --------- | | takt ／ takt add | 会話でタスクを決めて積む | 初期から | | takt run | 積んだタスクをまとめて実行 | 初期から | | takt exec | YAMLを書かずに即実行 | v0.49.0 | | takt watch | キューを監視して自動実行 | v0.68で並列化 | | takt make | 対話でworkflowを作成・修正 | v0.64.0 | | takt ui | ローカルWeb UI（実験的） | v0.63.0 | | takt caccia | CodeRabbitの指摘に対応 | v0.67.0 | | takt merge | PRのレビュー・修正・マージ | v0.71.0 | `takt exec`は、Assistantが要求を整理し、`/go`で会話を`.takt/exec/workflow.yaml`に変換して、Worker・Review・Replanningのエージェントで実行します。ワークフローを書く前に一度試すにはこれが手軽です。毎回同じ工程を回すと決まったら、`takt make`や`takt workflow init`で自分のworkflowにして`takt run`に移ります。同じプロジェクトで`takt run`と`takt watch`は同時に起動できません（v0.71.0から）。 ### takt merge・takt cacciaによるPRレビューと修正・マージ v0.67.0で入った`takt caccia `は、[CodeRabbit](/tech/details/17349/)のレビューを待ち、未解決のbotスレッドに隔離クローンで対応して、反復ごとの判断レポートを残します。v0.71.0の`takt merge`は、開いているPRをworkflowでレビュー・修正・マージします。既定は2件ずつ並行、マージ方法はsquashで、下書きとforkのPRは既定で対象外です。実装からマージ前までをTAKTに任せる構成が、本体の機能だけで組めるようになりました。 ## ハーネスエンジニアリングにおけるTAKTの位置づけ 成瀬氏は、Findy主催のイベント「ハーネスエンジニアリング（Harness Engineering）入門：AIエージェントを制御するアプローチ」（[2026年4月22日開催](https://techplay.jp/event/993802)）で「実践ハーネスエンジニアリング：TAKTで実現するAIエージェント制御」を講演しています。TAKTはこの「ハーネスエンジニアリング」を実装した道具として読むと分かりやすくなります。 [ハーネスエンジニアリングのSpec・Context・Harness三層設計](/tech/details/11691/)でいえば、TAKTが受け持つのは3層目のHarness、つまりエージェントをどう走らせ、どこで止めるかの制御です。何を作るか（Spec）は指示書やoutput contractで、何を知らせるか（Context）はknowledgeとpolicyのファセットで渡します。仕様駆動開発の工程をTAKTで回したい場合は、コミュニティの[j5ik2o/takt-sdd](https://github.com/j5ik2o/takt-sdd)がワークフローとファセットを公開しています（[仕様駆動開発（SDD）](/tech/details/8740/)の考え方をそのままworkflowにしたもの）。 ## 類似ツールとの比較：Claude Code Agent Teams・Microsoft Conductor・CrewAI・LangGraph オーケストレーション系のツールは、AIにどこまで判断させるかで立ち位置が分かれます。2026年10月16日時点の版で並べると次のとおりです。 | ツール | 工程の決め方 | 主な対象 | 現行版・状態 | | ----------------------- | ----------- | ---------------- | ------------ | | TAKT | YAMLで固定 | コーディングエージェント | v0.71.0（MIT） | | Microsoft Conductor | YAMLで固定 | コーディングエージェント | v0.1.42（MIT） | | Claude Code Agent Teams | リーダーがその場で分担 | Claude Codeの並列作業 | 実験的機能 | | LangGraph | コードでグラフ定義 | LLMアプリ全般 | 1.2.15 | | CrewAI | 役割を与えて自律協調 | 汎用マルチエージェント | 1.15.28 | TAKTに最も近いのは、Microsoftが公開している[Conductor](https://github.com/microsoft/conductor/releases)です。こちらもYAMLの`workflow`・`agents`・`routes`でエージェントと遷移条件を定義します。Conductorの比較対象版は2026年10月6日公開のv0.1.42です。製品間で版番号の付け方は異なるため、番号の大小ではなく、必要なproviderへの対応やワークフローの記法で比較してください。どちらも0.x系なので、記法が変わる前提で使います。 [Claude Code Agent Teams](https://code.claude.com/docs/en/agent-teams)は実験的機能で既定では無効になっており、環境変数`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`で有効にします。「このPRを3人のレビュアーで見て」のようなその場限りの協調はAgent Teamsが手軽です。毎回同じ手順で回すならTAKTのYAMLにします。TAKTには、ビルトインのworkflowとpersonaをClaude CodeのSkillとして書き出す`takt export-cc`もあるので、両方を併用できます。複数エージェントにする価値があるかどうかの判断は、[シングルエージェントとマルチエージェントの違い](/tech/details/4261/)で整理しています。 ## TAKTを採用すべき場面と見送るべき場面 ### 採用すべき場面：同じ品質保証の工程を毎日回すチーム 投資に見合うのは、実装→AIレビュー→修正の流れが定型化しているチームです。たとえばcoding-reviewerにレビューを担当させ、指摘があればimplementへ戻るrulesを定義すると、人のレビュー前にAIレビューと修正の工程を実行できます。workflowとファセットをリポジトリでバージョン管理すれば、新しく入ったメンバーも同じ基準で開発を始められます。「あの人のレビューは鋭い」という属人的な品質を、コードとしてレビューできる形にできるのが組織で使う利点です。 TAKTの導入やエージェント開発の工程設計を外部に相談したい場合は、一創の[AIエージェント開発](/service/ai/agent/)でも支援しています。 ### 見送るべき場面：単発の作業と、版を追えないチーム 一度きりの調査、すぐ捨てるプロトタイプ、数行の修正には向きません。ワークフローを書くより、エージェントを直接動かすほうが早く終わります。 もう一つの判断材料が更新の速さです。v0.52.0からv0.71.0までの約3か月でnpmへの公開が27回あり、そのなかに既定providerの変更（v0.68.0）、workflow YAMLからの実行設定の削除（v0.60.0）、ビルトインworkflowの改名（v0.61.0で旧`experimental`が新`default`に）、SDKの別インストール化（v0.71.0）が含まれます。`npm install -g takt@0.71.0`のように版を固定し、上げるときにCHANGELOGのBREAKINGを読んで`takt workflow doctor`を通す作業を担当できる人がいないなら、まだ様子を見るほうが安全です。 ## TAKTに関するよくある質問 ### TAKTは無料で使えますか？商用利用はできますか？ TAKT本体はMITライセンスのOSSなので無料で、商用利用も改変もできます。費用がかかるのは呼び出す側のAIで、Claude（Anthropic API）、Codex（OpenAI API）、GitHub Copilotなどの料金はそれぞれの契約に従います。 ### TAKTはClaude Codeで使えますか？ 使えます。v0.68.0以降の既定providerは、Claude CodeのエンジンをNode.jsから呼ぶ`claude-sdk`（Claude Agent SDK）で、事前に`takt install claude-sdk`が必要です。インストール済みのClaude Code CLIを使いたい場合は`provider: claude-headless`、対話型ターミナルで動かすなら`claude-terminal`（tmuxが必要）を指定します。 ### takt runとtakt execはどう違いますか？ `takt run`は、会話や`takt add`で積んでおいたタスクを、自分で選んだworkflowに沿って隔離worktreeで実行します。`takt exec`は、ワークフローを書かずに会話から入り、`/go`で自動生成したworkflowで即座に実行します。工程を固めて繰り返すなら`takt run`、まず試すなら`takt exec`です。 ### TAKTの作者は誰ですか？ nrslib（成瀬允宣）氏です。GitHubのnrslib/taktで開発されており、質問や議論はREADMEに案内のあるDiscordで受け付けています。成瀬氏はTAKTを「ハーネスエンジニアリング」の文脈で講演しています。 ### TAKTという名前の意味は？タクトタイムとは関係ありますか？ READMEによると、名前はオーケストラの指揮で拍を刻む「拍」「指揮棒の一振り」を意味するドイツ語「Takt（タクト）」に由来し、「TAKT Agent Koordination Topology」の頭字語にもなっています。製造業で稼働可能時間を必要生産数で割って求める「タクトタイム」も語源は同じドイツ語ですが、ソフトウェアとしての関係はありません。 ## 関連記事 - [ハーネスエンジニアリングとは？Spec・Context・Harnessの三層で組む設計と実装](/tech/details/11691/) - [Claude Agent SDK（旧Claude Code SDK）とは？使い方・移行・料金を解説【2026年版】](/tech/details/7451/) - [Claude Codeのgit worktreeで並列エージェント開発を行う方法｜仕組み・使い方・注意点【2026年版】](/tech/details/11708/) - [CodeRabbitの導入手順と.coderabbit.yaml設定・料金と分担の決め方](/tech/details/17349/) - [シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】](/tech/details/4261/) --- 出典: [TAKTとは？AIエージェントを指揮するOSSの使い方とYAMLワークフロー【2026年10月】]()（株式会社一創）