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

このテーマをもう少し広げて見るなら、Codex Sitesを社内ツールに使う前に: Business/Enterprise preview・RBAC・secretsの確認ポイント と AI Coding Loop Engineering入門: Plan・Implement・Test・ReviewをAgent任せにしすぎない設計 も合わせて確認してください。UI mockから社内向けprototypeやinternal appへ進める前に、RBACやsecretsの確認へつなげるため。

3行まとめ

Actor

誰の話か。

Job

何をしたいか。

State

どの状態か。

Review

何を見るか。

user storyは、mock依頼ではなく判断材料へ分けます。

• user storyをそのままmock依頼にせず、actor、job、acceptance criteriaに分けます。
• Codexには、screen list、state map、既存UIとの差分、review questionを成果物として固定します。
• 実装へ進むのは、既存UIとの整合、例外state、owner、次の判断が揃ってからにします。

user storyからUI mockを作る流れは、速く見えるぶん、雑にもなりやすいです。「この機能の画面を作って」と投げるだけだと、見た目はそれらしくても、誰の課題を解いているのか、どの条件を満たせばよいのか、どこまで実装へ進めてよいのかが曖昧になります。

Codexに任せるなら、mockそのものより前に、判断できる材料を揃えます。actor、job、acceptance criteria、既存UI、状態、制約、review担当を分ける。そうすると、mockは単なる絵ではなく、product、design、engineeringが同じ材料を見て判断するための中間成果物になります。

この記事では、OpenAI公式のCodex Use Casesにある「Turn user stories into UI mocks」をもとに、2026年6月1日時点の情報として整理します。Codexのuse casesやapp機能は更新され得るため、導入時は最新docsと自社のdesign systemを確認してください。

この記事でわかること

Scope

画面範囲。

Inputs

storyと制約。

Outputs

成果物。

Gate

次の判断。

mockを作る前に、見る人と判断基準を決めます。

• user storyをCodexへ渡す前に分ける項目
• mockのscreen scopeを決める方法
• 既存UIやdesign systemを先に読む理由
• Codexに作らせる成果物の型
• product、design、engineeringでreview観点を分ける方法
• mockから実装taskへ進める条件

この記事は、完成UIの作り方そのものではありません。Codexで実装前の判断材料を作る話です。既存feedbackからactionへ落とす流れは、公開済み記事のCodexでフィードバックを実装候補に変える前に決めることが近いです。ここでは、user storyができた後、UI mockへ進める前の整理に絞ります。

前提知識

項目	内容	見方
Use Cases		UI mocks。
PRDs		要件化。
Front-end		UI作成。
Features		作業入口。
AGENTS.md		repo手順。

mockは要件、UI、実装の間に置く確認物です。

OpenAI公式のCodex Use Casesでは、product feedback、issue thread、design contextを使って、teamが反応できるmockupへ変換する用途が紹介されています。同じ一覧には、内部contextからPRDを作る用途、screenshotやvisual referenceからfront-end designを作る用途、Figma designをcodeへ変換する用途も並んでいます。

ここで大事なのは、mockを「要件の代わり」にしないことです。PRDは目的、背景、制約、成功条件をまとめる文書です。mockは、画面やflowで具体化した確認物です。実装taskは、repo上で変更できる単位です。この3つを混ぜると、きれいな画面案なのに要件が合っていない、合意したつもりなのに例外stateが抜けている、という状態になります。

Codex app featuresやworktrees、AGENTS.mdのdocsは、実装へ進める時にも関係します。mock段階ではまだ大きな変更を入れず、既存UIやcomponentを読み、提案を出し、reviewで論点を整理するのが扱いやすいです。

Codex Use Casesで見る位置づけ

用途	この記事での扱い
Turn user stories into UI mocks	storyからreviewできるmockへ変換する
Draft PRDs from internal context	要件や背景を別成果物として整理する
Build responsive front-end designs	visual referenceからUIを作る
Make granular UI changes	既存appで小さなUI変更を行う
Turn feedback into actions	feedbackを実装候補へ変える

PRDとmockの違い

PRDは、なぜ作るか、誰の課題か、何を満たすかを決める文書です。mockは、その条件を画面で確かめるための材料です。

user storyが弱いままmockを作ると、reviewが見た目の好みに寄ります。逆に、mockを作る前にactor、job、acceptance criteriaを分けておくと、「このUIで条件を満たせるか」という会話になります。

user storyを3つに分ける

1. 1Actor

   誰が使うか。

2. 2Job

   何を達成するか。

3. 3Criteria

   満たす条件。

4. 4Evidence

   根拠を残す。

storyの言葉を、画面で確認できる条件へ変換します。

user storyは、actor、job、acceptance criteriaに分けます。よくある「管理者として、顧客一覧から未対応の問い合わせを見たい。対応漏れを減らすため」という文は、そのままでは画面の範囲が広すぎます。

actorは、誰が使うかです。jobは、その人が何を達成したいかです。acceptance criteriaは、達成したと判断できる条件です。

actor

actorは「管理者」「ユーザー」だけでは足りないことがあります。現場担当、承認者、support lead、初回利用者、既存顧客など、使う人の権限と文脈を分けます。

Codexに渡す時は、actorの権限、よく使う画面、見てよいdata、操作できる範囲を短く添えます。権限が違うactorを混ぜると、mock内のbuttonやfilterが過剰になります。

job

jobは、画面の機能名ではなく、達成したい状態です。「問い合わせ一覧を表示する」ではなく、「未対応の問い合わせを優先度順に見つけ、今日対応すべきものを選ぶ」のように書きます。

jobが明確だと、Codexは画面要素の優先順位を付けやすくなります。逆に、jobが曖昧なままだと、検索、filter、table、summary、chartが全部盛りになりやすいです。

acceptance criteria

acceptance criteriaは、mock reviewの基準になります。例として、「未対応件数が分かる」「優先度で並べ替えられる」「期限切れが目立つ」「担当者なしを見つけられる」「mobileで主要情報が隠れない」などです。

ここでは、UIの細部をすべて決めません。満たすべき条件だけを先に決めます。Codexには、criteriaごとにmock上のどこで確認できるかを出させると、reviewしやすくなります。

mockの範囲を決める

項目	内容	見方
Screen		対象画面。
Flow		前後の動き。
In		見る範囲。
Out		今回は外す範囲。

範囲を絞ると、mock reviewが散らばりにくくなります。

mockの範囲は、screen list、in scope、out of scopeで固定します。範囲を決めずに作ると、Codexは周辺画面まで広げたり、今回は不要な設定画面や通知flowまで提案したりします。

まず、今回見る画面を列挙します。次に、その画面の前後にあるflowを短く書きます。最後に、今回は見ないものを明示します。

screen list

screen listは、review対象の画面一覧です。たとえば、問い合わせ一覧、問い合わせ詳細、担当変更modal、empty state、error stateです。

画面数は少なく始めます。1つのstoryに対して、いきなり10画面を作ると、reviewが分散します。最初は主画面と主要stateに絞り、必要なら次のroundで広げます。

in scope

in scopeには、今回のmockで判断したいことを書きます。情報設計、主要操作、状態表示、copy、既存componentの使い方などです。

「見た目をよくする」ではなく、「未対応の優先順位が3秒で分かるか」「担当者なしが見落とされないか」のように、判断できる言葉へ変えます。

out of scope

out of scopeは、議論を守るために必要です。たとえば、権限管理、通知設定、bulk operation、CSV export、billing、admin audit logなどを今回は外すと決めます。

out of scopeを決めると、review中の「これも欲しい」を捨てるのではなく、次の検討へ送れます。Codexには、out of scopeをmockに入れないよう明示します。

既存UIとdesign systemを先に見る

Component

既存部品。

Pattern

既存flow。

Copy

文体。

States

例外。

既存UIを読むほど、Codexの提案を判断しやすくなります。

Codexに新しいmockを作らせる前に、既存UIとdesign systemを先に見ます。ここを飛ばすと、画面だけ新しく、product全体から浮いた案になります。

既存component、layout pattern、copy tone、empty state、loading state、error stateを確認します。Figma、Storybook、component docs、既存画面、source codeのcomponent directoryなど、teamが実際に使っているsourceを渡します。

既存component

既存componentを見る目的は、新規部品を増やさないことだけではありません。すでにあるtable、filter、badge、toast、modal、drawerの使い方を揃えるためです。

Codexには、既存componentを使う案と、新規componentが必要な案を分けさせます。新規componentが必要なら、その理由を一行で残します。

content tone

UI mockでは、copyのtoneも重要です。enterprise向けの管理画面、creator向けのapp、support toolでは、同じalertでも言い方が変わります。

既存画面のbutton label、empty state、error message、tooltipを短く集めておくと、Codexのcopyが浮きにくくなります。

empty state

mockは正常系だけでなく、empty state、loading、error、permission denied、partial dataも見ると実務に近づきます。

特にuser storyが「見つける」「選ぶ」「対応する」系の場合、対象がない時の動きが重要です。未対応が0件なら何を表示するか、権限がないactorには何を見せるかを決めます。

Codexに作らせる成果物

項目	内容	見方
Outline		画面案。
State map		状態一覧。
Diff		既存との差分。
Questions		未決事項。

成果物を固定すると、好みの議論だけで終わりにくくなります。

Codexに作らせる成果物は、screen outline、state map、既存UIとの差分、review questionの4つに固定します。これだけでも、mock reviewの質はかなり変わります。

画面だけを出させると、なぜその配置なのか、どの条件を満たすのか、何が未決なのかが見えにくくなります。成果物の型を決めることで、reviewがしやすくなります。

screen outline

screen outlineは、画面ごとの目的、主要情報、主要操作をまとめたものです。細部のpixelではなく、何をどこで判断するかを見ます。

Codexには、各screenについて「目的」「主要情報」「主要操作」「除外したもの」を出させます。これにより、画面の意図が追えます。

state map

state mapは、normal、empty、loading、error、permission、edge caseを並べたものです。

stateがないmockは、実装に進むと必ず詰まります。どのstateを今回見るのか、どのstateを次に回すのかを分けます。

review question

review questionは、Codexが勝手に決めきらないための出口です。未決事項を質問として残します。

たとえば、「優先度は期限と顧客tierのどちらを先に見るか」「担当者なしをwarningにするかfilterにするか」「詳細へ遷移する前にinline actionを置くか」などです。

reviewで見る観点

項目	内容	見方
Product		課題解決。
Design		体験。
Engineering		実装性。
Support		説明しやすさ。

mock reviewは、全員が同じ箇所を見る必要はありません。

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

productは、課題解決と優先順位を見ます。designは、情報の見つけやすさ、操作の自然さ、既存体験との一貫性を見ます。engineeringは、既存componentで作れるか、dataが足りるか、stateが実装できるかを見ます。

product

product reviewでは、user storyのjobを満たしているかを見ます。画面が豊かかどうかより、actorが目的を達成できるかです。

acceptance criteriaとmockの対応を見ます。条件を満たしていないのに見た目だけよい案は、実装へ進めません。

design

design reviewでは、既存patternとの整合、情報の優先順位、copy、状態表現を見ます。

ここで新しい表現を採用する場合は、他画面へ広げるのか、このstoryだけの例外なのかを決めます。

engineering

engineering reviewでは、既存component、data shape、API、permission、testを見ます。

mockが実装しやすいかだけでなく、実装した時に壊れやすい条件がないかを確認します。特にfilter、sort、pagination、role別表示、large dataは早めに見ます。

実装taskに変える前の一行

実装へ進める前に、「このmockは何を解決し、どの条件を満たすために作るのか」を一行で残します。この一行が曖昧なら、mockはまだ実装taskではありません。

実装へ進める条件

1. 1Agree

   flow合意。

2. 2Resolve

   論点整理。

3. 3Plan

   test方針。

4. 4Task

   実装単位。

合意がないmockは、実装taskではなく追加検討に戻します。

mockから実装へ進める条件は、合意済みのflow、残った論点、test plan、ownerです。

全部が完璧である必要はありません。ただし、何を合意済みとして扱い、何を未決として残すかは分けます。未決のまま実装へ進むと、PR reviewで議論が巻き戻ります。

合意済みのflow

合意済みのflowは、actorがどこから入り、何を見て、何を操作し、どこで完了するかです。

Codexには、画面遷移だけでなく、主要stateごとの完了条件も出させます。これがあると、実装taskへ分解しやすくなります。

残った論点

残った論点は、実装前に決めるものと、実装しながら確認するものに分けます。

たとえば、優先度計算の仕様は実装前に必要です。一方で、button labelの微調整はPRやdesign reviewで決められる場合があります。

test plan

test planは、mock段階でも短く作れます。正常系、empty、permission denied、large data、API error、keyboard operationなど、どの確認が必要かを書きます。

Codexに実装taskを作らせる場合は、このtest planを一緒に渡します。そうすると、見た目だけではなく、動作確認まで含めたtaskになります。

よくある失敗

Story only

story丸投げ。

No states

例外なし。

New UI

既存無視。

No owner

判断者なし。

mockの品質は、作る前の入力で大きく決まります。

よくある失敗は、user storyの丸投げ、正常系だけのmock、既存UIの無視、判断者不在、実装taskへの早すぎる変換です。

user storyの丸投げでは、Codexが前提を補いすぎます。正常系だけのmockでは、実装時にemptyやerrorで詰まります。既存UIを見ないmockは、product全体から浮きます。判断者がいないmockは、誰も決められないまま残ります。

もう1つの失敗は、mockを見た瞬間に実装へ進めることです。mockは合意形成の材料です。合意した範囲、未決の範囲、実装taskへ変える範囲を分けてから進めます。

FAQ

項目	内容	見方
Figma?		必要なら分ける。
PRD?		要件は別管理。
Code?		合意後。
Owner?		先に決める。

迷ったら、mockで何を判断するのかへ戻します。

Figmaがないと使えないですか？

必須ではありません。既存画面のscreenshot、component docs、source code、issue thread、PRDでも始められます。ただし、design systemがFigma中心なら、Figmaをsourceとして扱う方が自然です。

PRDを先に作るべきですか？

大きな機能ならPRDを先に作る方が安定します。小さな改善なら、user story、acceptance criteria、scope、review questionを短く揃えるだけでも始められます。

Codexにそのまま実装まで任せてよいですか？

合意済みのflow、既存component、test plan、ownerが揃っているなら検討できます。揃っていない場合は、mock reviewで止める方が安全です。

mockの良し悪しは誰が決めますか？

最初にownerを決めます。product owner、designer、engineering ownerの誰が最終判断するかを曖昧にしないことが大事です。

---

次に読むなら

参照した主な情報源

• 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

次に読むなら

更新履歴

1. 2026.06.01

   初版。

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

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