CodexでSlackの未対応事項を並べる前に決めること

3行まとめ

Action

やること。

Owner

担当。

Due

期限。

Evidence

根拠。

Slackの会話は、まず実行ではなくqueueとして整理します。

• Slack threadsやDMsは、まずdecision、request、blocker、FYIに分け、全部をtaskにしないようにします。
• action itemには、owner、期限、根拠、未決事項を付けてranked queueにします。
• Codexには実行まで任せず、まず人間がreviewできる優先順位表として返させます。

Slackには、やるべきことが散らばります。threadの途中にある依頼、DMで来た相談、障害対応中の一言、会議後のメモ。これを人間が追い続けるのは大変です。OpenAI公式のCodex Use Casesにも、Slack threadsやDMsからranked queueを作る「Prioritize Slack action items」が紹介されています。

ただし、Slackの会話をそのまま実行に変えるのは危険です。雑談、提案、仮説、決定、依頼、愚痴、FYIが混ざっているからです。Codexに任せるなら、まず実行ではなく、整理されたqueueを作るところから始めます。

この記事では、2026年6月1日時点のOpenAI公式Codex docsをもとに、Slackの未対応事項をCodexで並べる前の設計を整理します。1件のSlack threadをscoped taskに変える話は、公開済み記事のSlackの会話をCodex taskにする前に決めることで扱っています。ここでは、複数会話をranked queueへ変える話に絞ります。

この記事でわかること

Thread

会話。

Priority

順位。

Status

状態。

Review

確認。

優先順位を決めるには、会話の熱量と実務影響を分けます。

• Slack会話をdecision、request、blocker、FYIに分ける方法
• action itemにowner、期限、根拠を付ける理由
• impact、urgency、dependency、effortで優先度を決める方法
• ranked queueをTop 5、waiting、delegated、parkedに分ける方法
• Codexに読ませるchannel、期間、除外条件
• queue reviewで見る観点

Slack整理は、product backlogでもticket triageでもありません。会話から「次に見るべきもの」を抜き出す中間作業です。だからこそ、queueを作った後に人間が確認する段階を置きます。

前提知識

項目	内容	見方
Use Cases		Slack action。
Features		作業入口。
Permissions		権限。
Computer Use		必要時のみ。
AGENTS.md		報告型。

Slack整理は、実行権限を持つ作業とは分けて始めます。

OpenAI公式のCodex Use Casesでは、Slack threads and DMsをranked queueへ変換する用途が紹介されています。これは、会話からaction itemを抽出し、優先順位を付ける作業です。同じSlack周辺の用途には、Slackからcoding taskを始める流れもあります。

ここで混ぜてはいけないのは、整理と実行です。Slack action queueは、実行前の判断材料です。誰が何をやるべきか、何が待ちなのか、どれが本当に急ぎなのかを人間が見られる形にします。

Codex Use Casesで見る位置づけ

用途	この記事での扱い
Prioritize Slack action items	複数会話からranked queueを作る
Kick off coding tasks from Slack	1件の会話をscoped taskへ変換する
Turn feedback into actions	feedbackを実装候補へ変換する
Draft PRDs from internal context	会話を要件文書へまとめる
Permissions	Slack情報を読ませる範囲を決める

Slack task化との違い

Slack task化は、特定の依頼をCodex taskへ変える作業です。対象repo、branch、実装範囲、PR、確認方法まで決めます。

Slack action queueは、複数会話を見て、次に確認すべきaction itemを並べる作業です。まだ実装には進めません。queue reviewで、人間が実行するもの、ticket化するもの、保留するものを決めます。

Slack会話を4種類に分ける

項目	内容	見方
Decision		決定。
Request		依頼。
Blocker		詰まり。
FYI		共有。

すべてのSlack発言をtaskにしないことが出発点です。

Slack会話は、decision、request、blocker、FYIに分けます。すべてをaction itemにしないことが大事です。

decisionは決定事項です。requestは誰かへの依頼です。blockerは進行を止めている問題です。FYIは共有です。FYIまでtaskにすると、queueが膨らみます。

decision

decisionは、合意済みの内容です。たとえば「この仕様で進める」「releaseは金曜にする」「旧APIは使わない」などです。

decisionはaction itemではないこともあります。ただし、決定に伴う作業があれば、その作業を別に抜き出します。

request

requestは、誰かに何かを頼んでいる発言です。「確認して」「直して」「調べて」「PR作って」のようなものです。

requestはaction item候補です。ただし、ownerと期限がない場合は、queue上で未確定として扱います。

blocker

blockerは、誰かの作業を止めている問題です。環境が動かない、権限がない、仕様が決まっていない、review待ちなどです。

blockerは優先度が高くなりやすいですが、影響範囲を見ます。1人の作業だけ止めているのか、release全体を止めているのかで扱いが変わります。

FYI

FYIは共有です。読む価値はありますが、actionではない場合があります。

Codexには、FYIを無理にtask化しないように指示します。FYIから派生する確認がある場合だけ、action itemにします。

action itemを抽出する

1. 1What

   やること。

2. 2Who

   担当。

3. 3When

   期限。

4. 4Why

   根拠。

action itemは、本文ではなく実行できる単位へ変換します。

action itemは、what、owner、deadline、evidenceを持ちます。これがないものは、queueに入れても動きません。

Slackでは、誰がやるのか、いつまでなのか、なぜ必要なのかが曖昧なまま流れがちです。Codexには、足りない項目を埋めさせるのではなく、未決として残させます。

owner

ownerは、責任を持つ人です。発言者がownerとは限りません。依頼した人、実行する人、承認する人が別の場合があります。

ownerが不明なaction itemは、実行へ進めません。queueでは「owner確認待ち」として扱います。

deadline

deadlineは、期限です。明確な日付、release前、meeting前、customer reply前などがあります。

期限がないものは、impactとdependencyで順位を決めます。緊急そうな言い方だけで上位にしないようにします。

evidence

evidenceは、根拠です。thread URL、発言者、時刻、関連ticket、PR、docs、customer requestなどを残します。

根拠がないaction itemは、あとで揉めます。Codexには、queueの各行にevidenceを付けさせます。

優先度を決める

項目	内容	見方
Impact		影響。
Urgency		急ぎ。
Dependency		依存。
Effort		重さ。

声の大きさではなく、影響と期限で並べます。

優先度は、impact、urgency、dependency、effortで決めます。声の大きさや発言の新しさだけで並べません。

impactは影響の大きさです。urgencyは期限や時間制約です。dependencyは他作業を止めているかです。effortは重さです。

impact

impactでは、顧客影響、売上影響、release影響、security影響、teamの詰まりを見ます。

大きいimpactのものは上位に来ます。ただし、すぐ対応できない場合は、調査やowner確認を先に置きます。

urgency

urgencyでは、期限を見ます。今日中、今週中、release前、customer meeting前などです。

「急ぎ」と書かれていても、具体的な期限がない場合は確認します。

dependency

dependencyでは、他の作業を止めているかを見ます。review待ち、権限待ち、仕様待ち、環境待ちなどです。

dependencyが強いものは、作業自体が小さくても上位にします。止まっている時間を減らせるからです。

effort

effortでは、すぐ終わるか、重い作業かを見ます。5分でowner確認できるものと、1週間の実装は同じqueueで扱い方が違います。

小さく片付くblockerは上位に置く価値があります。重いものは、調査taskやPRDへ分けます。

ranked queueを作る

項目	内容	見方
Top 5		今見る。
Waiting		待ち。
Delegated		委任済み。
Parked		保留。

queueは、やる順番と止まっている理由を一緒に持ちます。

ranked queueは、Top 5、waiting、delegated、parkedに分けます。単なる一覧ではなく、次に見る順番と状態を持たせます。

queueには、action、owner、deadline、priority reason、evidence、status、next actionを入れます。

top 5

Top 5は、次に人間が見るべきaction itemです。数を絞ります。

20件の優先順位表は読まれません。最初はTop 5に絞り、残りはstatus別に分けます。

waiting

waitingは、owner確認、仕様確認、権限、外部回答待ちなどで止まっているものです。

waitingをqueueから消さないことが大事です。止まっている理由と、次に誰が動くかを残します。

delegated

delegatedは、誰かへ渡したものです。担当者、渡した日、期待する返答、期限を残します。

委任済みを未対応として扱い続けると、queueがノイズになります。

Codexに渡す入力

Channels

対象。

Timebox

期間。

Exclude

除外。

Format

出力。

Slack全体ではなく、対象channelと期間を絞って渡します。

Codexに渡す入力は、channels、timeframe、exclusions、output formatです。Slack全体を読ませるのではなく、範囲を絞ります。

特にDMやprivate channelは慎重に扱います。読ませてよい情報か、顧客情報やsecretが混ざらないかを確認します。

channels

channelsは対象範囲です。たとえば、release channel、support escalation channel、team channel、incident channelなどです。

複数channelを見る場合は、目的を分けます。release queueなのか、support queueなのか、engineering blocker queueなのかを決めます。

timeframe

timeframeは期間です。直近24時間、今週、release期間、incident対応中などです。

期間が長すぎると、古い話が混ざります。古いthreadは、まだ有効かを確認します。

exclusions

exclusionsは、読ませないものです。個人情報、secret、顧客固有情報、未公開人事、契約条件、private DMなどです。

Codexに読ませる前に、除外条件を明確にします。必要ならredactionした要約だけを渡します。

reviewで見る観点

項目	内容	見方
Product		優先度。
Engineering		依存。
Ops		期限。
Owner		担当。

ranked queueは、人間が確認してから実行へ進めます。

queue reviewでは、product、engineering、operations、ownerの観点を分けます。

productは影響と優先順位を見ます。engineeringは依存と実装可能性を見ます。operationsは期限と運用影響を見ます。ownerは担当と次actionを確認します。

product

product reviewでは、顧客影響、roadmap、release、support負荷を見ます。

Slackの熱量が高くても、product impactが小さいものは下げる判断があります。

engineering

engineering reviewでは、blocker、依存関係、必要な調査、実装規模を見ます。

実装が重いものは、queueからいきなりtaskへ進めず、調査や設計へ分けます。

operations

operations reviewでは、期限、通知、顧客連絡、障害対応、運用手順との整合を見ます。

外部送信や顧客対応が絡むものは、人間承認を強めにします。

勝手に実行しない

ranked queueは、実行命令ではありません。Codexには、queueを作った後に「実行してよいか」を人間へ戻させます。

Slackの会話は文脈が強いので、誤読したまま実行すると事故になります。

よくある失敗

All task

全部task化。

No owner

担当なし。

No evidence

根拠なし。

Auto execute

勝手に実行。

Slackの整理は、実行ではなく判断材料づくりから始めます。

よくある失敗は、Slack発言を全部taskにする、ownerなしでqueueへ入れる、根拠URLがない、DMを無断で読ませる、急ぎの言葉だけで優先度を上げる、queue作成後に勝手に実行することです。

もう1つは、queueを作って終わることです。queueは人間のreviewと次actionにつなげて初めて意味があります。

Slack整理は、teamの認知負荷を下げるための作業です。実行を急ぐより、判断できる状態へ整えることを優先します。

FAQ

項目	内容	見方
DM?		範囲注意。
Private?		許可確認。
Urgent?		別扱い。
Task?		確認後。

迷ったら、その会話をCodexに読ませてよいかへ戻します。

DMも対象にしてよいですか？

慎重に扱います。DMには個人情報、未公開情報、雑談、秘密情報が混ざります。本人同意や社内ルールに従い、必要なら要約だけを渡します。

private channelは読ませてよいですか？

権限と目的次第です。対象channel、期間、除外情報、出力先を決めます。Codexに読ませることは、その内容を作業文脈に入れることです。

urgentと書かれていたら最優先ですか？

いいえ。期限、影響、依存、実行負荷を見ます。本当に緊急なら、queueとは別にincidentやescalationとして扱います。

queueからそのままtask化してよいですか？

人間review後なら可能です。owner、scope、完了条件、対象repo、確認方法が揃ったものだけtask化します。

参照した主な情報源

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

次に読むなら

更新履歴

1. 2026.06.01

   初版。

CodexのSlack関連use casesは、導入時に公式docsで見直します。

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