AIコーディングエージェント 2026.05.31 更新: 2026.06.01

CodexでPRDを下書きする前に情報源と決定ログを分ける

3行まとめ

VisualPRD前の4分類情報を信頼度で分けます。

Source

出どころ。

Decision

決定済み。

Open

未決。

Owner

判断者。

PRD下書きは、文章を書く前の分類で品質が決まります。

PRDをCodexに下書きさせる前に、情報源、決定済み、未決、仮説、ownerを分けます。
Linear、Slack、source documents、meeting notesを混ぜる時は、どの文がどの根拠から来たのかを残します。
きれいなPRDより、空欄と未決事項が見えるPRDの方がreviewで使えます。

PRDの下書きは、AIと相性がよい作業に見えます。Slackの議論、Linearのissue、会議メモ、古い仕様書を渡せば、まとまった文書が出てくるからです。ただ、その便利さには落とし穴があります。情報源の違い、決定済みと未決、誰かの仮説、過去に却下された案まで、きれいな文章の中で混ざってしまうことです。

Codexに任せるなら、まず文章を書く前の分類が必要です。どの情報源から来たのか。すでに決まったのか。まだ決まっていないのか。仮説なのか。誰が確認するのか。ここを分けると、PRDは「それっぽい文書」ではなく、次の判断を進めるための材料になります。

この記事では、OpenAI公式のCodex Use Casesにある「Draft PRDs from internal context」をもとに、2026年6月1日時点の情報として整理します。Codexのuse casesやapp機能は更新され得るため、導入時は最新docsと自社のproduct運用を確認してください。

この記事でわかること

Visual整理する項目Codexへ渡す前の準備です。

Map

情報源。

Log

決定記録。

Draft

PRD形式。

Gate

引き渡し。

PRDを作る目的は、次の判断をしやすくすることです。

CodexにPRDを下書きさせる前に整理する情報源
Linear、Slack、source documents、meeting notesの扱い分け
決定済み、未決、仮説を分けるdecision logの作り方
PRDの章立てを固定してreviewしやすくする方法
product、engineering、design、supportで見る観点
PRDから実装taskへ渡す前の条件

この記事は、PRDのテンプレート集ではありません。Codexへ渡す前の情報整理と、下書き後のreview観点に絞ります。feedbackを実装候補へ変える前段階は、公開済み記事のCodexでフィードバックを実装候補に変える前に決めることが近いです。PRDからUI mockへ進める場合は、CodexでユーザーストーリーをUIモックにする前に決めることも合わせて使えます。

前提知識

Visual見る公式情報Codex運用に関係するdocsです。

項目	内容	見方
Use Cases		PRD下書き。
Feedback		action化。
UI mocks		画面化。
Features		作業入口。
AGENTS.md		project文脈。

PRDはfeedback、mock、実装taskの間にある要件文書です。

OpenAI公式のCodex Use Casesでは、Linear、Slack、source documents、meeting notesからproduct requirements documentsを作る用途が紹介されています。同じuse casesには、feedbackをactionへ変える用途、user storyをUI mockへ変える用途、front-end designを作る用途も並んでいます。

PRDは、その中間にあります。feedbackや議論をそのまま実装へ流す前に、目的、背景、成功条件、非目標、要件、未決事項を整理する文書です。PRDが弱いと、UI mockも実装taskもぶれます。

Codex Use Casesで見る位置づけ

用途	この記事での扱い
Draft PRDs from internal context	散らばった情報からPRD下書きを作る
Turn feedback into actions	feedbackを実装候補に変える
Turn user stories into UI mocks	要件を画面で確認する
Build responsive front-end designs	visual referenceからUIを作る
Kick off coding tasks from Slack	会話をscoped taskへ変える

PRDに含めるものと含めないもの

PRDに含めるものは、目的、対象user、解く課題、成功条件、requirements、non-goals、リスク、未決事項、ownerです。

含めない方がよいものもあります。実装の細かい手順、未承認のUI案、根拠がない数字、誰かの感想を決定事項に見せる表現です。これらは必要ならappendixやopen questionsへ分けます。

情報源を4つに分ける

Visualsource map情報の出どころを分けます。

項目	内容	見方
Linear		issue。
Slack		議論。
Docs		仕様。
Notes		会議。

情報源を混ぜる前に、どこから来た話かを残します。

PRD下書きの入力は、Linear、Slack、source documents、meeting notesに分けます。全部をひとまとめにすると、Codexはきれいに統合してくれますが、どの文がどの根拠から来たのかが追いにくくなります。

情報源ごとに、強い情報と弱い情報があります。Linearはissue単位の意図が分かりやすい一方で、背景が抜けることがあります。Slackは議論の熱量が残りますが、決定と雑談が混ざります。source documentsは正式な根拠になりやすい一方で、古い場合があります。meeting notesは決定を拾えますが、発言者や合意範囲を確認する必要があります。

Linear

Linearやissue trackerは、課題、担当、優先度、statusを見る場所です。PRDに入れる時は、issue titleだけでなく、description、comments、labels、links、status changeも見ます。

Codexには、issueごとに「課題」「要求」「根拠」「未決」「owner」を分けて要約させます。複数issueをまとめる場合は、重複、矛盾、範囲外を分けます。

Slack

Slackは、現場の文脈が残る場所です。ただし、Slackの発言はそのまま決定ではありません。提案、反対意見、仮説、決定、todoが混ざっています。

PRDへ入れる時は、thread単位で扱います。誰が何を決めたのか、いつの発言か、後続で訂正があるかを確認します。Codexには、発言を「決定済み」「提案」「懸念」「質問」に分けさせると扱いやすくなります。

source documents

source documentsは、既存仕様、roadmap、research note、support docs、sales deck、analytics reportなどです。

強い根拠になりやすいですが、更新日とownerを見ます。古いdocsを最新の決定として扱うと、PRDが過去の前提に引きずられます。Codexには、各documentの更新日、owner、PRDに使う範囲をまとめさせます。

meeting notes

meeting notesは、合意や次actionを拾う場所です。議事録の全文をそのままPRDへ入れるのではなく、決定、未決、宿題、参加者、期限へ分けます。

発言は合意ではありません。「Aさんが言った」だけなら仮説や提案です。「会議で決めた」ならdecision logに入れます。曖昧な場合はopen questionとして残します。

決定済みと未決を分ける

Visualdecision log確定度で分けます。

1Fact
確認済み。
2Decision
決定済み。
3Open
未決。
4Hypothesis
仮説。

未決を空欄として残すと、PRD reviewで判断しやすくなります。

PRD下書きで一番大事なのは、決定済み、未決、仮説を分けることです。AIは空欄を嫌うように見える時があります。足りない情報を自然に補って、読みやすい文書にしてしまうからです。

実務では、空欄が見えている方が助かります。誰が何を決めるべきかが分かるからです。

決定済み

決定済みに入れるのは、明確な根拠があるものだけです。issueのstatus、approved comment、meeting decision、正式なdocs、ownerの承認などです。

PRDでは、「決定済み」と書くだけでなく、根拠リンクや発言元を残します。これにより、review時に巻き戻りにくくなります。

未決

未決は、PRDの弱点ではありません。むしろ、次に決めるべきことです。

未決事項には、質問、決める人、期限、決まらない場合の影響を書きます。たとえば、「無料planに含めるか」「既存customerへ自動適用するか」「admin権限だけにするか」などです。

仮説

仮説は、事実のように書かないことが大事です。「support問い合わせが減るはず」「初回設定率が上がるはず」は仮説です。

PRDでは、仮説と測定方法を一緒に書きます。測れない仮説は、後で成功判断ができません。

Codexに渡す入力を作る

Visualinput bundle下書きに必要な材料です。

Links

source URL。

Quotes

根拠。

Priority

重要度。

Owner

確認先。

入力を束ねる時は、根拠と判断者を一緒に残します。

Codexに渡す入力は、source map、priority、ownerで束ねます。長いcontextを投げるだけではなく、PRDに使う順番と信頼度を示します。

入力を作る時は、情報の量よりも、根拠の追跡しやすさを優先します。どこから来た話かが分からないPRDは、あとで修正しにくくなります。

source map

source mapは、情報源の一覧です。URL、種類、更新日、owner、PRDで使う範囲を書きます。

Codexには、source mapを先に読ませます。そのうえで、本文を書く時に「根拠がある項目」「根拠が弱い項目」「未確認の項目」を分けさせます。

priority

priorityは、すべての情報を同じ重さで扱わないために必要です。正式docs、最新のdecision、owner comment、古いthread、個人の仮説では重みが違います。

Codexには、矛盾がある場合の優先順位を渡します。たとえば、最新のapproved docsを優先し、古いSlack発言は背景として扱う、というように決めます。

owner

ownerは、情報を確認できる人です。PRD ownerだけでなく、sales、support、engineering、legal、designなど、項目ごとに確認先が変わる場合があります。

ownerがない情報は、決定済みにしません。仮説やopen questionとして残します。

PRDの出力形式を固定する

VisualPRD outline章立てを固定します。

項目	内容	見方
Summary		要約。
Goals		目的。
Non-goals		範囲外。
Reqs		要件。
Open		未決。

形式を固定すると、AIが足した部分を見つけやすくなります。

CodexにPRDを下書きさせる時は、出力形式を固定します。おすすめは、summary、background、goals、non-goals、users、requirements、success metrics、risks、open questions、decision logです。

形式を固定すると、足りない章が見えます。さらに、Codexがなめらかに補った部分を発見しやすくなります。

summary

summaryは、何を作る文書かを短く示します。ここで解決する課題、対象user、期待する結果を書きます。

summaryが曖昧なら、本文も曖昧になります。Codexには、summaryの末尾に「このPRDで決めないこと」を一文で入れさせると、範囲が締まります。

goals

goalsは、何を達成したいかです。機能名ではなく、userやbusinessの変化で書きます。

「管理画面を改善する」ではなく、「support担当が未対応問い合わせを見落とさない」「初回設定で迷う項目を減らす」のように書きます。

non-goals

non-goalsは、今回やらないことです。PRDではとても大事です。

やらないことを書かないと、reviewで範囲が広がります。Codexには、source contextから出てきた関連要望のうち、今回外すものをnon-goalsへ分けさせます。

requirements

requirementsは、実装で満たす条件です。画面、data、permission、notification、reporting、admin、analyticsなどを分けます。

requirementsには根拠を添えます。根拠がないものは、Codexの補完かもしれません。

空欄を残す勇気

PRDの下書きでは、空欄を残してよいです。むしろ、未確認の情報を自然な文章で埋める方が危険です。

Codexには、「分からない項目は推測せず、Open Questionsに残す」と明示します。空欄を残せるPRDは、reviewで強いです。

reviewで見る観点

Visualreview roles職能ごとに見る点です。

項目	内容	見方
Product		課題。
Eng		実現性。
Design		体験。
Support		説明。

PRD reviewは、文章の美しさより判断可能性を見ます。

PRD reviewでは、product、engineering、design、supportの観点を分けます。全員が全文を同じ粒度で見る必要はありません。

productは課題と優先順位を見ます。engineeringは実現性、依存関係、data、testを見ます。designはuser flowや体験の矛盾を見ます。supportは説明しやすさ、既存問い合わせ、運用負荷を見ます。

product

product reviewでは、課題が本当に解かれるか、目標が測れるか、範囲が広がりすぎていないかを見ます。

特に、success metricsが「良くなる」「使いやすくなる」だけの場合は弱いです。測れる形に直します。

engineering

engineering reviewでは、data source、API、permission、migration、test、release riskを見ます。

PRD段階で実装詳細を書きすぎる必要はありません。ただし、実現性を左右する制約は早めに出します。

support

support reviewでは、問い合わせが増えそうな点、説明が難しい点、既存顧客への影響を見ます。

Slackやmeeting notesにsupport由来の懸念がある場合は、PRDのrisksへ残します。

実装へ渡す前の条件

Visualhandoff gatetask化する条件です。

1Criteria
受入条件。
2Risk
懸念。
3Owner
責任者。
4Task
実装単位。

PRDは、実装taskへ渡せる状態まで整えてから使います。

PRDから実装へ渡す前に、acceptance criteria、risk、next actionを揃えます。PRDがあるだけでは、まだ実装taskではありません。

実装へ渡す時は、何を作るかだけでなく、何を満たせば完了か、どのリスクを見ながら進めるか、誰がreviewするかを決めます。

acceptance criteria

acceptance criteriaは、実装完了を判断する条件です。PRDのrequirementsから、testableな形へ落とします。

たとえば、「support担当が未対応を見つけやすい」ではなく、「未対応かつ期限切れの問い合わせが一覧上位に表示される」「担当者なしの問い合わせをfilterできる」のように書きます。

risk

riskは、実装前に見える懸念です。data不足、permission、既存顧客への影響、migration、performance、support負荷などです。

Codexには、PRD内のrequirementsごとにriskを出させます。riskが大きいものは、先にspikeや調査taskへ分けます。

next action

next actionは、PRD review後に何をするかです。UI mockへ進む、technical designへ進む、data調査へ戻る、owner判断を待つ、scopeを削る、などです。

PRDが完成しても、次actionが曖昧なら止まります。最後に一つだけ、次に進む作業を明確にします。

よくある失敗

Visual避けたい失敗PRD下書きで崩れやすい点です。

Merge

情報を混ぜる。

Invent

補完しすぎる。

No owner

判断者なし。

No open

未決なし。

不明点を消すほど、PRDは危なくなります。

よくある失敗は、情報源を混ぜる、Codexの補完を決定事項にする、未決事項を消す、ownerを置かない、PRDからすぐ実装へ進むことです。

特に危ないのは、Slackの熱量が高い発言を「決定」として扱うことです。発言者が強い人でも、合意とは限りません。PRDでは、発言、提案、決定を分けます。

もう1つは、きれいな文章を信用しすぎることです。PRDは読みやすさも大事ですが、根拠と未決が見えることの方が大事です。

FAQ

Visualよくある迷い運用前に決める答えです。

項目	内容	見方
Slack?		根拠化。
Linear?		issue単位。
Meeting?		決定だけ。
Mock?		別成果物。

迷ったら、PRDで何を決めるのかへ戻します。

Slack threadだけでPRDを作ってよいですか？

小さな改善なら始められます。ただし、thread内の発言を決定、提案、懸念、質問に分けます。決定者が不明なら、PRDではopen questionに残します。

Linear issueはどこまで入れますか？

issue titleだけでは足りません。description、comments、labels、links、status、関連issueを見ます。複数issueを束ねる場合は、重複と矛盾を先に整理します。

meeting notesはどう扱いますか？

会議メモは、決定、未決、宿題、参加者、期限へ分けます。発言録の全文をPRD本文へ混ぜず、根拠として参照します。

PRDとUI mockはどちらが先ですか？

大きな機能や関係者が多い案件では、PRDを先に置く方が安定します。小さな改善なら、短いPRD相当の整理からUI mockへ進めてもよいです。

参照した主な情報源

https://developers.openai.com/codex/use-cases
https://developers.openai.com/codex/app/features
https://developers.openai.com/codex/app/worktrees
https://developers.openai.com/codex/permissions
https://developers.openai.com/codex/guides/agents-md

次に読むなら

Codexでフィードバックを実装候補に変える前に決めること

PRDの前に、feedbackをactionへ分ける流れを整理したい時に使えます。

CodexでユーザーストーリーをUIモックにする前に決めること

PRDから画面案へ進める時、scopeとreview観点を分けるための記事です。

Slackの会話をCodex taskにする前に決めること

Slack上の相談を、PRDや実装taskへ分けて扱いたい時に向いています。

更新履歴

Visual更新メモ公開時点の整理です。

2026.06.01
初版。

Codexのuse casesやapp機能は、導入時に公式docsで見直します。

2026年6月1日: OpenAI公式Codex docsを確認して初版を作成しました。