TASKS.mdをCodexで使う方法と分担の決め方・導入設計と実践

TASKS.mdとは何か：Codex専用機能ではない

TASKS.mdは、ソースコードの近くに置くMarkdown形式の作業台です。ファイル名や見出しの形に公式の統一仕様があるわけではなく、プロジェクトごとに「次に何をするか」「誰が判断するか」「何をもって終わりとするか」を読み返せるようにします。Issueやチャットに散らばった話を一つの場所へ集めるだけでも、Codexへ依頼する前の確認が早くなります。

大切なのは、TASKS.mdをCodexの特別な設定として扱わないことです。Codexはそのファイル名を見ただけで、そこに書かれた項目を順番に処理したり、状態を更新したりするわけではありません。利用者が「TASKS.mdのこの項目を読んで」と明示し、対象範囲と確認方法を依頼に含めることで、作業メモを会話の材料として活用します。

TASKS.mdに向いているのは、現在の仕事の状態です。たとえば「一覧画面の空状態を調査中」「認証後の戻り先を確認待ち」「テストを追加して差分を見直す」といった、期間や対象が変わりやすい情報を置きます。一方で、言語のバージョン、テストの標準コマンド、編集禁止のディレクトリのように毎回効かせたい情報は、別の指示ファイルに分けた方が長く保てます。

公式の検出ルールを確認する

OpenAIの公式ガイドによると、Codexは作業前にグローバルな場所とプロジェクトのルートから現在の作業ディレクトリまでを確認し、各階層のAGENTS.override.mdまたはAGENTS.mdを組み合わせます。近い階層の内容が後から加わるため、より具体的な条件を下位ディレクトリに置けます。詳細はCodexのAGENTS.mdガイドで確認できます。

公式ガイドには、別名のファイルを使いたい場合に設定項目 project_doc_fallback_filenames で候補名を追加できる説明もあります。つまり、TASKS.mdを指示として扱う選択肢はありますが、追加設定をしない限り標準の探索対象ではありません。まずは作業一覧として明示的に読む運用から始め、指示として常時効かせる必要があるかを後で判断するのが安全です。

TASKS.mdを指示ファイルにしない理由

作業一覧と指示を一つのファイルに混ぜると、古いタスクの文章まで現在のルールのように読まれるおそれがあります。「調査中」「保留」「採用しない」といった過去の記録が残るほど、どの文を守るべきかが曖昧になります。TASKS.mdは状態を記録し、AGENTS.mdは継続的な前提を記録する、と線引きすれば読み手の迷いを減らせます。

もう一つの理由は更新の頻度です。作業一覧は毎日変わる一方、プロジェクト方針は頻繁には変わりません。CodexへTASKS.mdを渡すときは、対象の見出しや項目を指定し、今回必要な部分だけを読ませます。これにより、既に完了した項目や別担当のメモが、現在の依頼へ余計な影響を与えにくくなります。

2026年9月21日に確認するCodex更新とTASKS.mdの位置づけ

今回の導入で押さえたい時事情報は、版番号が二つの公開段階に分かれていることです。GitHubの公式リリースページでは、0.155.1が2026年9月18日公開のLatestとして表示され、ローカルTUIの新規セッションで推論要約を既定で無効にする修正が説明されています。明示的な推論要約の設定は尊重されるため、更新前後で何が変わったかを確認しやすい内容です。出典はCodex 0.155.1の公式リリースです。

一方、0.156.0-alpha.9は2026年9月20日に公開されたPre-releaseです。公式ページで確認できるのは先行版であること、公開日、コミット、配布物などで、ページ本文に日常利用へ切り替えるべき機能一覧が詳しく書かれているわけではありません。版番号の大きさだけで安定性や性能を推測せず、試す目的を一つに絞るのが基本です。出典はCodex 0.156.0-alpha.9の公式リリースです。

この状況でTASKS.mdが役立つのは、更新内容を大きく宣伝するためではなく、確認したい事実を小さく残せるからです。「0.155.1で既存のテストを通す」「alpha版で特定の表示だけを比較する」のように対象を限定すれば、Codexの版変更とコード変更を同じ話にしなくて済みます。作業メモには公開日、使った版、対象、結果を残し、推測と確認済みの事実を分けて書きます。

更新日と確認日を別にする

Codexのリリース日は公式ページで確認できますが、手元のCLIやアプリがいつ切り替わったかは別の事実です。TASKS.mdには Last reviewed: 2026-09-21 のような確認日を置き、別の行に使用した版を記録します。公開日だけを書いてしまうと、読者はいつの環境で検証された内容か判断できません。

たとえば「0.155.1でレビュー表示を確認した」と「0.156.0-alpha.9を試す予定」は、同じ段落に詰め込まず別項目にします。前者は確認済みの記録、後者はこれから行う作業です。状態を分けるだけで、Codexに渡す依頼も「実施する作業」と「参考にする履歴」に整理できます。

先行版の内容を断定しない

先行版を使うときは、まず公式ページに書かれている公開事実と、自分の環境で見えた挙動を別々に記録します。公式に変更点の説明がない場合は「機能が追加された」と書かず、「この版で表示を確認する」と書きます。これが、短い作業メモでも誤った前提を広げないための基本です。

確認結果が出たら、TASKS.mdの項目に日付と観察結果を追記します。期待どおりでなかった場合も、失敗を消すのではなく「どの版で、どの入力を使い、どこまで進んだか」を残します。次に同じ作業を頼む人が、成功したという印象だけでなく、試していない範囲も把握できるからです。

AGENTS.mdとの役割分担を先に決める

Codexに読み込ませる情報は、多ければよいわけではありません。すべての依頼に必要な決まりと、今回だけ必要な作業を分けると、指示の優先順位を保ちやすくなります。AGENTS.mdは「このプロジェクトではどう作業するか」を示し、TASKS.mdは「いま何を進めるか」を示すファイルとして設計します。

この分担はファイル名のためだけに行うものではありません。どの情報が長期間有効か、どの情報が完了後に消えるかを考えるための基準です。迷ったら、次の担当者が別のタスクを始めても同じ内容を必要とするかを問い、答えが「はい」ならAGENTS.md、「今回だけ」ならTASKS.mdへ置きます。

AGENTS.mdに置く内容

AGENTS.mdには、開発言語や主要なコマンド、テストの実行方法、変更してはいけない範囲、レビュー前に見る項目などを置きます。これらは一つのタスクが終わっても次の作業に引き継がれる前提だからです。指示は短い動詞で書き、例外がある場合は「どの条件なら別の方法を選ぶか」まで添えます。

OpenAIの公式リポジトリにもAGENTS.mdが置かれており、プロジェクト固有の作業前提をファイルで共有する考え方を確認できます。自分のプロジェクトで同じ構成を採用する場合も、長い説明文を増やすより、Codexが毎回使う判断材料を小さく保つ方が効果的です。

TASKS.mdに置く内容

TASKS.mdには、着手する作業の目的、対象ファイルや画面、前提となるIssue番号、完了条件、確認方法、保留理由を置きます。ここでのポイントは、作業を「改善する」「対応する」のような抽象語で終わらせず、変更が及ぶ範囲と確認できる結果へ言い換えることです。

一つの項目に複数の目的を詰め込むと、Codexがどこまで進めればよいか迷います。「空状態の表示を直す」と「一覧取得の速度を調べる」は別の項目に分け、関連がある場合だけリンクや前提を書きます。完了した項目は消すのではなく、短い結果を残して履歴として扱うと、同じ問題を再調査しやすくなります。

混ぜないための判定

設定やルールが全タスクに共通するならAGENTS.md、現在の作業にだけ必要ならTASKS.md、入力を受けてから決まる一回限りの条件なら依頼文に置きます。たとえば「テストは必ず実行する」はAGENTS.md、「一覧画面の空状態を確認する」はTASKS.md、「今回は表示文言を変更しない」は依頼文または該当タスクの注記です。

ファイルの置き場所を決めるときは、情報の寿命だけでなく、誤って適用されたときの影響も考えます。広い範囲へ効く内容は短く明確にし、狭い範囲の判断は対象ディレクトリやタスク項目へ閉じ込めます。判断に迷う内容を無理に常設せず、まずTASKS.mdへ期限付きで記録する方が、後から整理しやすい場合もあります。

TASKS.mdの基本構成を作る

最初から複雑な管理表にする必要はありません。現在進行中の項目、次に着手する項目、確認待ちの項目、完了した項目を見出しで分け、各項目には一つの目的と一つの確認方法を対応させます。状態を記号だけで表すのではなく、短い文章で「何が止まっているか」を書くと、Codexへの依頼へ変換しやすくなります。

次の例は、特定のサービスや構成に依存しない最小形です。日付は記事の作成日ではなく、最後に内容を見直した日として扱います。項目のIDを付けておくと、会話の中で「T-02だけ」と指定でき、別のメモを読み込ませずに済みます。

# TASKS.md

Last reviewed: 2026-09-21
Current Codex version: 0.155.1

## Now

### T-01: 一覧画面の空状態を確認する
- Status: in progress
- Scope: resources/views/items と関連テスト
- Goal: データが0件のときに案内文と操作先が一致する
- Done when: 画面確認と関連テストの結果を記録できる

## Next

### T-02: エラー表示の文言を整理する
- Status: queued
- Scope: APIエラーを表示するコンポーネント
- Goal: 利用者が次に取る行動を判断できる
- Done when: 代表的な3ケースの表示を確認する

## Waiting

### T-03: 仕様確認待ち
- Status: blocked
- Question: 空状態から作成画面へ移動できるか
- Owner decision: 確認後にT-01の完了条件を更新する

## Done

### T-00: 既存テストの実行
- Status: done
- Checked: 2026-09-21 / result recorded in the task note

この例で重要なのは、状態の英語表記ではなく、目的と完了条件が分かれていることです。in progress だけでは何が済んだか分かりませんが、「空状態の表示と操作先を確認する」と書けば、作業後に画面とテストの両方を確認すべきだと読めます。状態名はプロジェクト内で統一し、途中で意味を変えないようにします。

タスクの粒度をそろえる

一つの項目は、短い依頼文に変換できる大きさにします。「管理画面を改善する」は広すぎ、「見出しの句読点を一文字直す」は細かすぎる可能性があります。対象の場所、変えたい結果、確認する方法が一つの流れで説明できるなら、Codexへ渡す単位として扱いやすい大きさです。

大きな作業を分割するときは、画面・データ・テストのように観点を分けるだけでなく、前後関係も書きます。先に仕様を確認しないと編集できない項目には、その依存を Waiting に記録します。分割の目的は項目数を増やすことではなく、各項目の完了を人が短時間で判断できるようにすることです。

完了条件を結果で書く

完了条件は「対応済み」ではなく、第三者が確かめられる結果で書きます。「エラーを直す」なら、再現条件、期待する表示、実行するテスト、差分を見る場所を含めます。「調査する」なら、調査対象、確認した資料、採用しなかった案、次に必要な判断を記録します。

完了条件が曖昧なままだと、Codexは変更を増やして埋めようとする可能性があります。TASKS.mdの項目には、変更してよい範囲と、変更しない範囲も書きます。これにより、依頼の成果を大きく見せるために無関係なファイルまで触れることを避け、レビュー時の確認点も絞れます。

TASKS.mdからCodexへの依頼を作る

作業メモをそのまま「全部やって」と渡すより、対象項目を一つ選び、読んでほしい資料、変更範囲、確認方法を順に伝えます。Codexはコードを調べて判断できますが、プロジェクトの優先順位や採用基準まで自動で正しく推測できるとは限りません。TASKS.mdは背景、依頼文は今回の指示として使い分けます。

依頼を作るときは、完了条件を最後に置くと文章が締まります。最初に対象項目を示し、次に現状を調べる範囲、変更の制約、実行する検証を説明します。調査だけで終える場合は「変更はせず、確認結果と候補だけを報告する」と明記し、実装まで進める場合は「差分を示してから検証する」と書きます。

Step 1: 対象項目を一つ選ぶ

最初に TASKS.md の見出しとIDを指定します。「T-01だけを対象にしてください」のように書けば、同じファイルにあるT-02や完了済みの記録が今回の対象外だと伝わります。さらに、項目の目的を一文で言い換え、Codexが読んだ内容と依頼者の意図が一致しているかを確認します。

項目を選ぶ段階で、Now と Waiting を混同しないことも大切です。仕様確認が必要な項目を先に編集させると、後で大きな手戻りが起きます。保留理由が解消されているかを人が見て、着手できる状態に移してから、Codexへ具体的な作業を依頼します。

Step 2: 対象範囲と変更条件を伝える

次に、読むディレクトリ、変更してよいファイル、触れないファイルを明示します。例として「resources/views/items と関連テストを読む」「データ取得層は変更しない」「既存の表示文言は維持する」のように、許可する範囲と除外する範囲を並べます。範囲が書かれているほど、調査で見つけた別の改善案を今回の変更へ混ぜにくくなります。

依頼文の例は次のようになります。

TASKS.mdのT-01だけを対象にしてください。
まず現在の空状態の表示と関連テストを読み、データが0件のときの表示と操作先を確認してください。
変更範囲は一覧画面と関連テストに限り、データ取得層や別画面は変更しないでください。
実装後は関連テストを実行し、画面上で確認できる結果と残った注意点を報告してください。

この形なら、TASKS.mdの背景を読みつつも、今回の作業範囲は依頼文で固定できます。実際のプロジェクトでは、テスト名やディレクトリ名を正確に置き換え、存在しないパスを例として残さないようにします。

Step 3: 先に調査し、変更前の認識をそろえる

いきなり編集を頼むのではなく、関連ファイル、現在の挙動、既存テスト、予想される影響を先に報告させます。調査結果に知らない前提があれば、その場で補足し、変更を始める前に対象を狭めます。特に画面文言やデータ形式のように、コード以外の決定が影響する部分は、判断を保留して質問を返すよう依頼します。

調査の段階では、TASKS.mdに書いたGoalと実際の構造が一致するかを照らし合わせます。もし対象が想定より広い場合は、項目を分割してから続けます。反対に一つのテスト追加だけで済むなら、広い表現を狭い表現へ更新します。ここで認識をそろえると、後で差分を読む負担が小さくなります。

Step 4: 検証結果をTASKS.mdへ戻す

作業が終わったら、Codexの要約だけを採用せず、差分、テスト結果、未確認事項を人が見ます。問題がなければ項目のStatusを done に変え、確認日と結果を一行で残します。追加作業が必要なら Next に新しいIDを作り、元の項目には何が終わって何が残ったかを書きます。

結果を戻すときは、成功したケースだけでなく試していないケースも明記します。「主要画面では確認済み、権限の異なる表示は未確認」のように境界を残せば、次の依頼が過剰な確信から始まることを防げます。TASKS.mdを更新すること自体を完了条件に含めておくと、記録漏れも減らせます。

変更範囲と情報を安全に保つ

TASKS.mdは複数の人やツールが読む可能性のあるファイルです。便利だからといって、認証情報、個人情報、外部サービスの接続文字列、貼り付けたログの全量を保存する場所にはしません。必要な事実だけを短く記録し、詳しい情報が必要なら権限を確認した別の場所を参照する形にします。

また、作業項目の文章には「何をしてはいけないか」だけでなく、「代わりに何を確認するか」を書きます。禁止だけが並ぶと、Codexは停止したままになりやすく、依頼者も次の判断をしにくくなります。OpenAIの承認と安全性に関する公式資料も確認し、実行範囲と確認の境界をプロジェクトのルールに合わせて決めます。

変更範囲を狭くする

一つのTASKS.md項目では、対象ディレクトリ、変更してよいファイルの種類、実行するテストを明示します。変更範囲が広い作業は、調査、実装、整理、検証という複数の項目へ分け、各項目で差分を読みます。最初から全体を任せるより、途中の認識違いを早く見つけられます。

作業中に別の問題を見つけた場合は、その場で直すのではなく、元の項目への影響を確認して別IDへ切り出します。緊急性が高ければ理由と優先順位を書き、そうでなければ Next に置きます。こうしておくと、一つの差分に無関係な変更が混ざらず、TASKS.mdと実際の作業の対応も保ちやすくなります。

認証情報を書かない

TASKS.mdには、パスワード、アクセストークン、個人を特定できる値、顧客データの実値を書きません。再現に必要な場合も、値そのものではなく「テスト用のダミーデータを使う」「担当者が安全な場所から入力する」のように、確認方法だけを残します。ログを貼る場合は、不要な識別子やヘッダーを先に取り除きます。

エージェントに渡すファイルを選ぶときも、TASKS.mdと同じ基準を使います。対象と関係のない設定ファイルやログをまとめて読ませず、必要な行や項目だけを指定します。人が読める作業メモと、取り扱いに注意が必要なデータを分けることで、確認すべき範囲を明確にできます。

人が最終確認する

Codexが作った差分は、TASKS.mdの完了条件に沿って人が確認します。テストが通ったことは一つの材料ですが、要件に合う表示か、対象外のファイルが変わっていないか、将来の修正で読みづらくならないかまでは別に見ます。完了の判断を「返答が終わった」ではなく「結果を確認できた」に変えることが重要です。

レビューで戻した内容は、新しいタスクとして残すか、元の項目の未完了部分として書きます。修正を何度も依頼する場合も、会話だけで終わらせず、最終結果をTASKS.mdへ戻します。記録と差分が一致していれば、別の人が後から見ても、どこまで確認済みかを追跡できます。

定期的に見直すための手順

TASKS.mdは放置すると、完了した項目と現在の項目が混ざり、かえって読む時間が増えます。更新のたびに全体を大きく書き換える必要はありませんが、確認日、状態、完了条件、保留理由の四点だけは見直します。短いレビューを繰り返す方が、長い一覧を一度に整理するより続けやすくなります。

見直しは次の順序で進めます。

1. Now の各項目について、目的と対象範囲が現在のコードと合っているか確認する。
2. Waiting の項目について、保留理由が解消されたか、質問を更新する必要があるか確認する。
3. Done の項目について、確認日と結果が残っているか、後から必要な注意点があるか確認する。
4. Codexへ次に渡す項目を一つ選び、依頼文に範囲と完了条件を写し取る。

この順番にすると、古い項目を先に整理してから次の依頼へ進めます。特に Waiting を放置せず、答えが出たら Now へ移すことが大切です。状態だけを変えるのではなく、なぜ移したかを一行残すと、作業の流れがあとから読み返せます。

ファイルを育てすぎない

TASKS.mdが大きくなったら、項目を削除する前に履歴の置き場所を決めます。完了済みの記録が長くなった場合は、要点だけを残して別の変更履歴へ移し、TASKS.mdには現在の判断に必要な結果を残します。古い背景をすべて保持するより、いまの依頼に必要な情報へ絞る方がCodexにも人にも読みやすくなります。

ディレクトリ別に作業が分かれる場合は、ルートのTASKS.mdに全体の優先順位を置き、細かな項目は各領域のファイルへ分けます。ただし、分けた場所と見方をルート側に一行で示してください。見つけられない情報は、存在しない情報と同じように扱われてしまうためです。

読んだ内容を確認する

CodexにTASKS.mdを渡したあとは、最初の返答に「どの項目を対象にしたか」「どのファイルを読んだか」「変更を始めるか」を含めるよう依頼します。ここで対象が違っていれば、編集前に修正できます。短い確認を一度挟むだけでも、別の項目を処理する事故を抑えられます。

作業後は、TASKS.mdのStatusと実際の差分が一致するかを見ます。done なのに検証結果がない、in progress なのに変更済みファイルが広がっている、といった不一致があれば状態を戻して記録を直します。ファイルの見た目を整えることより、書かれた状態と現実が合っていることを優先します。

まとめ：TASKS.mdは依頼の出発点にする

TASKS.mdはCodexが勝手に処理する特別なファイルではなく、人とエージェントが現在の作業を共有するための軽い作業メモです。Codexが標準で読むAGENTS.mdには継続的なルールを置き、TASKS.mdには対象、状態、完了条件、保留理由を置くと、二つの情報が混ざりません。

2026年9月21日時点では、0.155.1がLatest、0.156.0-alpha.9がPre-releaseとして公開されています。版の違いを記録するだけでなく、何を確認したか、どの結果を採用したかまでTASKS.mdに戻すことで、更新による変化とコードの変更を落ち着いて追えます。公式情報はOpenAIのCodex変更履歴と各リリースページで確かめてください。

まずはT-01のような小さな項目を一つ作り、対象範囲と完了条件を一文ずつ書いてからCodexへ渡します。調査、変更、検証、記録の順序を守れば、TASKS.mdは単なるメモから、依頼の認識をそろえ、結果を確認できる実務的な入口へ育てられます。