SlackからCodexへタスクを投げる前に決めること

3行まとめ

Thread

会話。

Scope

範囲。

Permission

権限。

Evidence

証跡。

Report

報告。

Slackの会話を、そのまま実装依頼にしないことが出発点です。

• Slack threadからCodexへtaskを投げる時は、会話をそのまま実装指示にせず、目的、repo、scope、完了条件へ変換します。
• Codexへ渡す前に、触ってよい範囲、触らない範囲、権限、外部情報、PRやissueへ戻す証跡を決めます。
• 完了報告はSlackだけで終わらせず、PR、issue、test結果、未確認事項へリンクして残します。

この記事では、OpenAI公式のCodex use cases、Codex app Features、Worktrees、Permissions、AGENTS.md、Commands docsを確認し、2026年6月1日時点の情報として整理しています。Codex app、Slack連携、cloud task、Worktrees、権限設定は更新され得るため、導入前に最新docsと自社のSlack/Git運用を確認してください。

この記事でわかること

Repo

対象。

Branch

開始点。

Ask

不足確認。

PR

戻し先。

依頼文ではなく、reviewできるtaskへ変換します。

• Slack threadをCodex taskへ変換する時の順番
• repo、branch、対象file、触らない範囲の固定方法
• Slackに含まれる情報をCodexへ渡してよいか分ける考え方
• issueやPRへ戻す証跡の型
• Slackへ返す完了報告と未確認事項
• 初週に試す低riskな導入例

OpenAIのCodex use casesでは、Slack threadをscoped cloud tasksへ変換する使い方が紹介されています。Slackには、バグ報告、顧客要望、UIの違和感、運用中の相談、緊急修正の芽が集まります。そこからCodexへ作業を渡せると、会話から実装までの距離は短くなります。

ただし、Slackの会話はそのままでは実装指示として粗いことが多いです。「これ直して」「昨日の件」「この画面変」だけでは、repoもbranchも完了条件も分かりません。Codexへ渡す前に、会話をreviewできるtaskへ変換します。

Codex活用をSlack、PRレビュー、CLI、Skillへ広げる順番は、公開済み記事のCodex活用をチームに広げる順番でも扱っています。この記事ではSlack threadをtask化する部分だけに絞ります。

前提知識

項目	内容	見方
Use cases		Slack task化。
Features		app機能。
Worktrees		background。
Permissions		権限。
Commands		呼び出し。

Slack起点でも、Codex側の作業場所と権限を確認します。

OpenAI公式のCodex use casesでは、Kick off coding tasks from Slackとして、Slack threadsをscoped cloud tasksへ変換する用途が示されています。Codex use cases全体では、PR review、Goal、Workflows、Skills、Computer Useなど、会話や外部toolから作業へつなぐ使い方が並んでいます。

Codex app Featuresでは、Codex appがproject、thread、worktree、browser、skillsなどを扱う開発作業の入口として説明されています。Worktrees docsでは、Git repositoryで独立した作業場所を作り、background作業やHandoffに使えることが説明されています。

Permissions docsでは、filesystemやnetworkの境界をprofileとして決める考え方が示されています。Slack起点のtaskでも、読むだけか、変更してよいか、外部情報を参照してよいか、公開やdeployへ進んでよいかを分けます。

公式情報で確認する範囲

確認先	見ること
Codex use cases	Slack threadからscoped cloud tasksへの考え方
Codex app Features	project、thread、worktreeの位置づけ
Worktrees	background作業とHandoff
Permissions	filesystem、network、権限
Commands	taskを呼び出す入口
AGENTS.md	repoごとの作業契約

注意点

この記事は、Slackの会話をすべてCodexへ流すことを勧めるものではありません。顧客情報、secret、契約情報、障害対応、請求、権限変更、本番操作を含むthreadは、渡す前に情報を分けます。

また、Slackは流れやすい場所です。決定事項をSlackにだけ残すと、あとからPR reviewや監査で追いにくくなります。作業に進むなら、issue、PR、台帳、release noteなど、後で参照する場所へ戻します。

まずSlack threadをtaskへ変換する

1. 1Read

   threadを読む。

2. 2Extract

   目的を抜く。

3. 3Ask

   不足確認。

4. 4Task

   依頼にする。

会話の勢いを、実装できる単位へ変換します。

Slack threadをCodexへ渡す前に、会話をtaskへ変換します。

変換項目	Slackでありがちな状態	taskに必要な形
目的	「これ変」	何を直すか
対象	screenshotだけ	URL、repo、file、画面
期待	「良い感じに」	期待挙動、文言、状態
制約	後出し	触らない範囲
完了	返事だけ	PR、test、公開確認

依頼の種類

Slack発の依頼は、種類ごとに分けます。

種類	例	Codexへ渡す形
bug	画面が壊れている	再現手順と期待結果
copy	文言が分かりにくい	対象文言と置換方針
small fix	link切れ、style崩れ	対象fileと確認方法
investigation	原因を調べたい	read-only調査
feature	新機能の相談	issueやPRDへ分ける

bugやsmall fixはCodex taskへ向きます。feature相談や仕様変更は、そのまま実装へ進めず、issueやPRDへ変換します。

task化前の質問

Slack threadだけでは情報が足りない時は、先に質問します。

質問	理由
どのrepoですか	作業場所を固定する
どの環境ですか	local、staging、本番を分ける
期待挙動は何ですか	修正方向を決める
触ってよい範囲はどこですか	scopeを絞る
いつまでに必要ですか	優先度を決める

taskに足りない情報

Slack threadには、contextが省略されます。「この前のやつ」「あの画面」「田中さんが言ってた件」のような表現は、そのままCodexへ渡せません。

Codexへ渡すtaskには、最低限次を含めます。

項目	例
Slack thread URL	発端を追える
repo	frontend-app
branch/base	main、対象release branch
scope	src/pages/settings
expected	保存後にtoastを出す
not allowed	billing、auth、migrationは触らない
review	PRで人間review

scopeとrepoを固定する

項目	内容	見方
Repo		対象repository。
Path		対象file。
Base		開始branch。
Out		触らない範囲。

repoと範囲を固定すると、Slack発の依頼でもreviewしやすくなります。

Slack起点の依頼は、scopeが広がりやすいです。Codexへ渡す前に、repo、branch、対象path、触らない範囲を固定します。

固定するもの	書き方
repo	repository名、project名
base	main、release branch、issue branch
path	directory、component、test file
out of scope	認証、課金、DB migration
done	test、PR、URL確認

対象範囲

対象範囲は、広すぎるより狭いほうが良いです。「設定画面を直す」ではなく、「settings/profileの保存button周りを確認する」と書きます。広い依頼なら、調査taskと実装taskに分けます。

Codex Worktreesを使うなら、Slack依頼から作業用の独立場所を作れます。詳しくはCodex Worktreesで並列作業する前に決めることで整理しています。

触らない範囲

触らない範囲は、明示します。Slackでは「そこまでは変えないで」が暗黙になりがちです。

触らない範囲	理由
auth	影響が広い
billing	金銭影響がある
database migration	rollbackが必要
notification	外部送信がある
secrets	機密情報を扱う

scopeが広い時の分割

scopeが広い場合は、次の順番で分割します。

step	内容
1	read-only調査
2	修正候補の提示
3	人間がscope確認
4	小さな実装task
5	PR review

いきなり修正へ進めず、調査と実装を分けるだけで事故が減ります。

権限と外部情報を分ける

Read

調査。

Write

限定変更。

Network

外部確認。

Secrets

渡さない。

Slack threadにある情報を、Codexへ渡してよい情報と分けます。

Slack threadには、顧客名、内部URL、ログ、screenshot、障害情報、secretに近い情報が混ざることがあります。Codexへ渡す前に、渡してよい情報を分けます。

情報	扱い
public URL	渡しやすい
internal URL	権限と必要性を確認
screenshot	個人情報を隠す
logs	secretやtokenを除く
customer data	原則そのまま渡さない
credentials	渡さない

read-only調査

最初はread-only調査にします。Slack thread、関連issue、docs、コード、過去PRを読み、何を直すべきかをまとめます。

調査結果には、結論、根拠、未確認、次のactionを入れます。原因が分からないまま変更へ進めないようにします。

変更を伴う作業

変更を伴う場合は、write権限、対象path、test command、PR作成、reviewerを決めます。外部APIや本番環境を触る場合は、別の承認条件を入れます。

Codexの権限やrulesの整理は、Codex設定を増やす前に決めることでも扱っています。

証跡をissueやPRへ戻す

項目	内容	見方
Thread URL		発端。
Decision		判断。
Diff		変更。
Tests		確認。
Review		見る人。

証跡をPRやissueへ戻すと、Slackを追わなくても判断できます。

Slackだけで完了させると、あとで追えません。Codexへ投げたtaskは、issueやPRへ証跡を戻します。

証跡	戻す場所
Slack thread URL	issue/PR本文
変換メモ	issue description
実装方針	PR description
test結果	PR checklist
未確認	PRのrisk欄
人間判断	review comment

変換メモ

変換メモには、Slack threadから何をtaskとして採用したかを書きます。

項目	例
Source	Slack thread URL
Request	設定画面の保存feedbackが分かりにくい
Scope	profile settingsのみ
Decision	toast文言を変更する
Out	auth、billing、DBは対象外

review条件

PRへ戻すなら、review条件も書きます。Slackで依頼した人がreviewするのか、code ownerが見るのか、QAが見るのかを分けます。

CodexレビューをGitHubへ入れる考え方は、CodexレビューをGitHubに入れる前に決めることでも整理しています。

Slackに戻す報告を決める

項目	内容	見方
Done		終わったこと。
Link		PRやURL。
Test		確認結果。
Risk		未確認。

Slackへの返答は短く、判断に必要なリンクを含めます。

Slackへ戻す報告は、短く、リンク中心にします。

項目	内容
Done	何をしたか
Link	PR、issue、preview、public URL
Test	実行した確認
Risk	未確認や残件
Need	review、承認、追加情報

完了報告

完了報告は、Slack threadの最後に残します。ただし、証跡の本体はPRやissueへ置きます。Slackには「PRを作った」「testは通った」「ここを見てほしい」までを短く返します。

未確認

未確認をSlackで隠さないようにします。たとえば、「stagingで確認済み、本番反映は未実施」「mobile幅は未確認」「billing flowは触っていない」といった形です。

Slack返信テンプレート

Slackへ戻す時は、次の型が使えます。

項目	例
対応	profile settingsの保存feedbackを修正しました
PR	PR #123
確認	unit testとstaging preview確認済み
未確認	billing/authは対象外
お願い	依頼者reviewをお願いします

導入初週の進め方

1. 1日目

   thread整理。

2. 2日目

   repo固定。

3. 3日目

   小修正。

4. 5日目

   PR証跡。

5. 7日目

   skill化。

最初は低riskなSlack依頼を、PRへ戻す流れで試します。

最初の1週間は、低riskなSlack依頼だけを対象にします。

日	やること	見ること
1日目	threadをtaskへ変換する	不足情報が見えるか
2日目	repoとscopeを固定する	依頼が小さくなるか
3日目	小修正を1件PRへ戻す	証跡が残るか
5日目	read-only調査を試す	無理に変更しないか
7日目	変換手順をskill化する	再利用できるか

初週の成功条件は、Slackからたくさん実装することではありません。会話からtaskへ変換し、PRやissueへ証跡を戻せることです。

小さく始める例

最初は次のような依頼が向いています。

依頼	理由
文言修正	scopeが狭い
link切れ	確認しやすい
docs更新	本番影響が低い
UIの軽い崩れ	previewで確認しやすい
read-only調査	安全に始められる

本番障害、顧客データ、billing、権限変更、deployを含む依頼は、運用が固まってから扱います。

FAQ

DM?

共有へ戻す。

Urgent?

scope確認。

Prod?

承認。

No repo?

質問。

迷ったら、Slack会話がreview可能なtaskになっているかを見ます。

SlackのDMからCodexへ投げてもよいですか？

可能でも、重要な依頼は共有channelやissueへ戻すほうが安全です。DMだけに決定が残ると、reviewや監査で追いにくくなります。

Slack threadの全文をそのまま渡してよいですか？

顧客情報、secret、内部URL、障害情報が含まれる場合があります。必要な部分だけ抜き出し、渡してよい情報へ変換します。

すぐ直してほしい時はscope確認を省いてよいですか？

省かないほうがよいです。緊急時ほど、repo、branch、触らない範囲、rollback、reviewerを短く固定します。

PRを作らずSlackで完了報告だけでもよいですか？

docs修正や調査報告だけならよい場合もあります。ただしcode changeがあるなら、PRやissueへ証跡を戻すほうが安全です。

Slack起点のtaskはGoalやAutomationにできますか？

複数件の依頼整理や定期的なtriageならGoalやAutomationにできます。単発の小修正は通常taskで十分です。

次に読むなら

参照した主な情報源

• Codex use cases – OpenAI Developers
• Codex app features – OpenAI Developers
• Worktrees – Codex app – OpenAI Developers
• Permissions – Codex – OpenAI Developers
• Codex app commands – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

導入時には最新のCodex use casesとapp docsを確認してください。

• 2026年6月1日: OpenAI公式Codex use cases、Codex app docs、Worktrees、Permissions、AGENTS.mdを確認し、初版を作成しました。