Task Master と Codex CLI で PRD をタスクに自動分解

Task Master とは — 要件定義書をタスクに分解する仕組み

Task Master は、Cursor や Windsurf、Claude Code、Codex といった各種のコーディング環境に組み込んで使える AI タスク管理システムだ。公式リポジトリ（https://github.com/eyaltoledano/claude-task-master）の説明によれば、その中心的な役割は「要件定義書（PRD）を、依存関係を意識した構造化タスクへ変換し、CLI・エディタ連携・ダッシュボードが計画から統合まで同じ状態を共有できるようにする」ことにある。

具体的には、まず作りたいものの要件を一つの文書としてまとめ、それを Task Master に読み込ませる。すると内容が解析され、tasks.json という一つのファイルに、タスクとその依存関係、優先度が書き出される。各タスクには複雑さが 1〜10 で採点され、点数が高いものは先に細かく分解してから着手するよう促される。エージェントに「全部やって」と伝えるのではなく、着手する単位を人間が確認できる粒度まで割ってから渡せるのが、素の一括依頼との一番の違いだ。この「地図」があることで、Codex は個々のタスクに集中でき、全体の順序を見失いにくくなる。

なぜ今 Codex CLI との連携が要点なのか

これまで Task Master のような計画ツールを使う際は、計画立案を担うモデルのために別途 API キーを用意し、利用量に応じた課金を管理する必要があった。ここに変化をもたらしたのが、Task Master が Codex CLI をモデルの提供元として正式に扱えるようになった点だ。設定ドキュメント（https://docs.task-master.dev/）によれば、codex login を実行してブラウザから ChatGPT アカウントで一度サインインしておけば、Task Master はその認証情報を自動的に使い、API キーを明示しなくても計画立案を動かせる。

利用できるモデルは gpt-5 と gpt-5-codex の二つで、とりわけ gpt-5-codex はソフトウェア開発のためのエージェント動作に最適化されたモデルだ。OpenAI の Codex モデル解説（https://developers.openai.com/codex/models）によれば、これらは最大 27 万トークン規模の入力と大きな出力に対応しており、長い要件定義書や広いコードベースの文脈を扱いやすい。計画を立てる頭脳とコードを書く手を、同じ Codex の環境と同じサインインで揃えられる。この一体化こそが、いま Task Master と Codex CLI を組み合わせる実利的な理由になっている。

Codex CLI を Task Master のモデルに設定する手順

導入は、必要なツールをそろえる、Codex にサインインする、Task Master 側でモデルを指定する、という流れで進む。順を追えば特別な前提知識がなくても連携まで到達できる。

Step 1: Task Master と Codex CLI を用意する

最初に両方のツールを手元にそろえる。Task Master は npm パッケージ（https://www.npmjs.com/package/task-master-ai）として配布されており、npm install -g task-master-ai でコマンドとして導入できる。あわせて Codex CLI も導入しておく。プロジェクトのルートで task-master init を実行すると、設定ファイルとタスクを保存する領域が作られ、以降のコマンドがそのプロジェクトを対象に動くようになる。ここまでで足場が整う。

Step 2: Codex にサインインする

続いて Codex CLI 側で認証を済ませる。ターミナルで codex login を実行するとブラウザの画面が開き、手持ちの ChatGPT アカウントでサインインできる。認証が終わると資格情報が端末に保存され、Task Master はこの情報を自動的に参照する。ここで一度サインインしておけば、計画立案のたびにキーを入力する必要はなく、別建ての API キーを管理する手間も省ける。ChatGPT の契約をそのまま計画立案の予算として使える点が、この方式の分かりやすさだ。

Step 3: 提供元に Codex CLI を指定する

次に Task Master へ、どのモデルを何の役割で使うかを伝える。計画立案の主役には task-master models --set-main gpt-5-codex --codex-cli を、失敗時の予備には task-master models --set-fallback gpt-5 --codex-cli を実行する。--codex-cli を付けることで、そのモデルを Codex CLI 経由で呼ぶ指定になる。設定後は task-master models を実行すれば、現在どのモデルがどの役割に割り当てられているかを一覧で確認できる。意図した通りに Codex CLI が結び付いているかを、この段階で必ず見ておく。

Step 4: 要件定義書を分解する

準備が整ったら、作りたいものの要件をまとめた文書を用意し、task-master parse-prd で読み込ませる。Task Master が内容を解析し、依存関係つきのタスク一覧を生成する。ここで生成されたタスクを起点に、実装フェーズへ進んでいく。要件が曖昧なままだと分解も曖昧になるため、この文書に何を作りたいかを具体的に書いておくほど、後段のタスクの質が上がる。

実際の開発フロー — parse-prd から next・expand まで

タスクが生成された後の進め方はシンプルだ。task-master next を実行すると、依存関係を満たしていて今すぐ着手できるタスクが一つ提示される。人間はその内容を確認し、Codex にそのタスクの実装を指示する。一つ終わったら状態を更新し、また次のタスクを取り出す。この繰り返しで、全体の順序を保ったまま少しずつ前進できる。

タスクが大きすぎると感じたら、task-master expand でそのタスクをより小さなサブタスクへ割る。公式リポジトリの説明によれば、高い複雑さと採点されたタスクほど、着手前に分解しておくことが推奨されている。展開されたサブタスクには対象ファイルや受け入れ条件が付くため、Codex に渡す指示の解像度が上がり、一度の実装で狙いを外しにくくなる。タスクの状態は着手中・完了・保留・却下などに更新でき、task-master list で全体の進み具合をいつでも見渡せる。計画と実装が同じ tasks.json を共有しているため、どこまで進んだかを人間とエージェントの双方が同じ形で把握できる。

main / research / fallback の三つの役割を使い分ける

Task Master のモデル設定には、計画立案を担う main、追加の調べ物を担う research、そして主モデルが失敗したときに引き継ぐ fallback という三つの役割がある。この分離が、Codex CLI 連携の柔軟さを支えている。設定ドキュメントの例では、main に gpt-5-codex を、fallback に gpt-5 を割り当てている。重い要件分解や複雑なタスクの展開には開発特化の gpt-5-codex を当て、汎用的な処理や予備には gpt-5 を回す、といった配分が可能だ。

Codex CLI を提供元にした場合、このプロバイダはコードベースを直接読み取れる性質を持つ。設定で enableCodebaseAnalysis を有効にしておくと（初期状態で有効）、プロジェクトのファイルを踏まえた分析ができる。これにより、要件定義書だけでなく既存コードの状態も加味したタスク分解が期待できる。役割ごとにモデルを分けられる仕組みと、コードベースを読める提供元の性質が組み合わさることで、計画の質と実装の噛み合いが良くなる。

効果が出る使いどころと注意点

この連携が最も効くのは、一気に作るには大きすぎる機能や、複数の変更が絡み合うリファクタリングのように、順序と依存関係が問われる場面だ。要件を先に文書化し、それを依存関係つきのタスクへ割ってから Codex に渡すことで、途中で目的を見失う事故を減らせる。逆に、数行の修正や単発の質問のような小さな作業では、タスク管理の枠組みをかぶせる手間のほうが上回ることもある。ツールを常に挟むのではなく、規模に応じて使い分けるのが現実的だ。

注意点として、生成されたタスクや分解の結果は必ず人間が目を通す前提で扱いたい。要件定義書の書き方次第でタスクの粒度は大きく変わり、曖昧な要件からは曖昧な計画しか出てこない。また、計画立案を ChatGPT のサインインで動かす場合、その契約の利用枠を計画側でも消費する点は意識しておくとよい。最新の対応モデルやコマンドの細部は更新されることがあるため、導入時には公式リポジトリ（https://github.com/eyaltoledano/claude-task-master）と設定ドキュメントで現状を確認しておくのが確実だ。計画の頭脳と実装の手を Codex で揃えつつ、最後の判断は人間が握る。この配分が、大きな開発を安定して進めるための土台になる。