CodexのCommandsを増やす前に決めること

3行まとめ

Command

threadで呼ぶ。

Action

terminal作業。

Skill

手順を固定。

AGENTS

repo指示。

Permission

権限を絞る。

定型化する前に、どこへ置く作業かを決めます。

• CodexのCommandsは、便利な入力短縮だけでなく、thread内で何を呼び出すかを整理する入口として扱います。
• Local environmentsのActions、Skills、AGENTS.md、Permissionsまで同じ場所に押し込むと、再利用したい依頼ほど壊れやすくなります。
• command化する前に、対象project、必要な入力、使うtool、権限、返してほしい成果物を固定します。

この記事では、OpenAI公式のCodex app Commands、Features、Local environments、Skills、Permissions、AGENTS.md docsを確認し、2026年6月1日時点の情報として整理しています。Codex appのcommand、shortcut、slash command、project設定は更新され得るため、導入前に最新docsと手元の設定を確認してください。

この記事でわかること

Scope

対象project。

Input

必要情報。

Tool

使う機能。

Output

返す型。

同じ依頼を何度も使うなら、入力と成果物を先にそろえます。

• Codex appのCommandsを増やす前に見る判断軸
• slash command、project action、skill、AGENTS.mdの分け方
• 同じ依頼を何度も使うときに固定する入力
• read-only調査、限定変更、外部tool利用を分ける考え方
• 完了報告と未確認事項を崩さない成果物の型
• チームで導入するときの初週の進め方

Codex appのCommands docsでは、keyboard shortcutやslash commandが整理されています。thread composerで / を入力してcommandを選ぶ流れや、$ でskillを明示的に呼び出せることも説明されています。

一方で、Local environmentsのActions docsでは、開発サーバーの起動やテスト実行のような共通taskをprojectに設定し、Codex app上部から実行できるものとして説明されています。つまり、Commandsはthread内の操作、Actionsはprojectでよく使うterminal作業、と分けて考えるほうが実務では扱いやすいです。

Codexの定型化は「毎回打つ文字を減らす」だけではありません。依頼の入口、実行する場所、読み込む前提、許す権限、返す成果物を分けることです。ここを曖昧にしたまま増やすと、便利なはずのcommandが、誰も保守できないprompt置き場になります。

Codex app全体のproject、worktree、local設定は、公開済み記事のCodexのLocal environmentsをチームで使う前に決めることでも整理しています。この記事ではCommands周りの切り分けに絞ります。

前提知識

項目	内容	見方
Commands		composer操作。
Features		app機能。
Actions		共通task。
Skills		手順化。
Permissions		権限。
AGENTS.md		作業契約。

Codex appの入口とproject設定を分けて確認します。

OpenAI公式のCodex app Commands docsでは、Command menu、Settings、thread search、Find in thread、slash commandsなどが扱われています。slash commandはthread composerからCodexを操作するための入口で、利用できるcommandは環境やaccessによって変わるとされています。

Local environments docsでは、setup scriptsとActionsが扱われています。Actionsは、開発サーバー起動やtest suite実行など、projectで繰り返すtaskを定義するものです。実行はCodex appのintegrated terminal内で行われます。

Features docsでは、Codex appが複数projectやthread、worktree、automations、Git機能を扱うdesktop体験として説明されています。Skillsについても、CLIやIDE Extensionと同じagent skillsをappで扱えることが説明されています。

Permissions docsでは、filesystemやnetworkの権限をprofileとして定義する考え方が示されています。AGENTS.md docsでは、global scopeとproject scopeの指示を重ね、repoごとの作業契約をCodexへ渡す仕組みが説明されています。

公式情報で確認する範囲

確認先	見ること
Codex app Commands	shortcut、slash command、thread内操作
Codex app Features	app、project、thread、skillsの位置づけ
Local environments	setup scripts、Actions
Skills	繰り返し手順の固定
Permissions	filesystem、network、profile
AGENTS.md	global/projectの作業指示

注意点

この記事は、独自のslash commandを無制限に増やす話ではありません。公式docsで扱われるcommandやshortcut、skill呼び出し、project actionを、チーム運用の中でどう分けるかを整理します。

また、command名や利用できるslash commandは環境によって変わります。記事内では個別commandの網羅より、増やす前に決める作業分類を優先します。

まずCommand化する作業を分ける

1. 1Ask

   依頼文。

2. 2Route

   入口を選ぶ。

3. 3Run

   実行する。

4. 4Report

   結果を返す。

便利そうな依頼をすぐ増やさず、作業の性質を見ます。

Command化したい作業が出てきたら、最初に3種類へ分けます。

種類	例	置き場所
thread内の操作	status確認、review開始、goal設定	slash command
terminalで動かす作業	dev server起動、test、build	Local environmentsのActions
手順として残す作業	release手順、記事公開、PR整理	Skill
repoの前提	test方針、触らないfile、review基準	AGENTS.md

この分類をしないまま「よく使うからcommandにする」と、定型依頼が大きくなりすぎます。たとえば「PRを見て、関連issueを読み、testを実行し、必要なら修正し、summaryを書いて」は、1つの入口だけで解決するには重い作業です。

thread内の操作

thread内の操作は、composerからすぐ呼べる形が向いています。公式docsでは、/status、/review、/plan、/goal、/mcp などのslash commandが例として示されています。

これらは、Codexに「いまのthreadで何をするか」を伝える入口です。作業の中身を長く書くより、状態確認、review開始、plan mode、goal設定のように、Codex app内の操作へ寄せます。

terminalで動かす作業

開発サーバー起動、test、build、lintのようなtaskは、Local environmentsのActionsに寄せます。Actionsはprojectの共通taskとして置けるため、毎回composerにcommandを打つより、project設定として扱いやすくなります。

たとえばNode.js projectなら、公式docsの例のように npm start をRun actionにできます。チームで共有するなら、macOS、Windows、Linuxで差が出るscriptも分けておきます。

手順として残す作業

手順が長い作業は、skill化の候補です。たとえば「公開前にvalidatorを3つ通し、失敗したら差し戻し、公開後にURLを確認し、台帳を更新する」のような作業は、入口だけでは足りません。

skillにするなら、入力、確認順、使うtool、停止条件、報告形式まで入れます。毎回promptで説明するのではなく、作業契約として残すほうがチームで再利用しやすくなります。

CommandsとActionsとSkillsを分ける

項目	内容	見方
Commands		thread内の操作。
Actions		projectの共通command。
Skills		繰り返し手順。
AGENTS.md		repoの前提。

呼び出し口、実行内容、作業契約を分けると保守しやすくなります。

Commands、Actions、Skills、AGENTS.mdは、似ているようで役割が違います。

置き場所	向いているもの	向いていないもの
Commands	thread内の操作をすぐ呼ぶ	長い業務手順の保管
Actions	projectの共通terminal task	判断やreviewの代替
Skills	手順、確認順、成果物の型	1回だけの単純依頼
AGENTS.md	repo固有の前提、守る基準	日々変わる作業メモ
Permissions	filesystem/networkの境界	作業目的の説明

ここを分けると、「どこを直せば定型依頼が改善するか」が明確になります。操作が見つけにくいならCommandsを見る。実行commandが古いならActionsを見る。手順が曖昧ならSkillsを見る。repo前提がずれているならAGENTS.mdを見る。権限が広すぎるならPermissionsを見る、という具合です。

Commands

Commandsは、Codex app内で作業を呼び出す入口です。shortcutやslash commandは、threadを移動したり、reviewを始めたり、goalを設定したりするために使います。

Commandsへ入れる発想は、「この操作を素早く呼びたいか」です。作業の中身すべてをcommandに詰めるのではなく、Codexが次に進むための合図として扱います。

Actions

Actionsは、projectでよく使うterminal作業です。開発サーバー起動、test suite、build、storybook、local DBの準備などが向いています。

Actionsへ入れる発想は、「このprojectで同じshell taskを何度も実行するか」です。判断やレビューを含む作業はActionsだけでは足りないため、skillやAGENTS.mdと組み合わせます。

Skills

Skillsは、繰り返し使う作業手順をCodexに渡す仕組みです。Codex appでもskillsを見たり呼び出したりできます。thread composerで $ を入力してskillを明示的に呼べることも、Commands docsで説明されています。

Skillsへ入れる発想は、「作業の順番や停止条件を固定したいか」です。手順を毎回promptに書く状態が続いているなら、skill化を検討します。

入力と対象projectを固定する

項目	内容	見方
Project		対象repo。
Target		fileやURL。
Mode		調査か変更か。
Limit		触らない範囲。

projectをまたぐ依頼ほど、対象と制約を明示します。

同じ依頼を再利用するなら、入力を固定します。入力が曖昧なcommandほど、実行結果が毎回ぶれます。

入力	例	固定する理由
対象project	frontend、api、docs	sandboxとfile範囲を狭める
対象物	PR番号、issue URL、file path	調査範囲を明確にする
作業mode	調査、review、修正、公開	権限と成果物を変える
完了条件	test、URL確認、差分なし	終了判断を揃える
除外範囲	secrets、migration、本番設定	触らないものを守る

Codex appは複数projectを扱えるため、projectをまたぐ依頼ほど入力が重要です。ひとつのrepositoryに複数appやpackageがある場合、公式docsでもdistinct projectsを分ける考え方が示されています。

依頼に必要な入力

たとえば「レビューして」だけでは、何を基準に見るのかが曖昧です。PRなのか、未committed changesなのか、特定fileなのか。bug中心なのか、security中心なのか。testを実行してよいのか、読むだけなのか。

定型依頼にするなら、最低限次を固定します。

項目	書き方
対象	PR URL、branch、file path、URL
目的	bug確認、仕様整理、公開、修正
許可	読むだけ、変更可、外部接続可
成果物	findings、diff、公開URL、未確認
停止条件	情報不足、権限不足、失敗時

入力が足りない時の停止条件

定型依頼では、足りない入力をCodexが推測で埋めないようにします。対象PRがない、projectが不明、test可否が不明、外部接続の許可が不明な場合は、作業を進めず質問へ戻す条件を入れます。

特に公開、deploy、外部API、credential、database、migrationに関わる依頼は、入力不足を「保留」として返すほうが安全です。止まる条件まで含めて定型化すると、commandの再利用が安定します。

projectをまたぐ依頼

複数projectで同じcommand風の依頼を使う場合、projectごとの違いをAGENTS.mdやskill側に寄せます。frontendとbackendでtest commandが違うなら、Actionsで分けます。review基準が違うなら、projectのAGENTS.mdへ置きます。

共通の依頼文だけで全部を吸収しようとすると、promptが長くなり、更新漏れも増えます。共有する部分とproject固有の部分を分けるほうが、結果的に短く保てます。

権限と外部toolを決める

Read

読むだけ。

Write

限定変更。

Network

接続先を絞る。

MCP

toolを選ぶ。

よく使う依頼ほど、広すぎる権限を標準にしないようにします。

定型依頼で怖いのは、よく使うからこそ広い権限が当たり前になることです。Permissions docsでは、filesystemやnetworkをprofileとして分け、read、write、deny、network domainsなどを設定する考え方が説明されています。

Commandsやskillsから呼ぶ作業も、必要な権限を分けて考えます。

作業	権限の考え方
docs調査	read-only中心
PR review	読み取りと必要な差分確認
test実行	workspace内の実行権限
修正	対象directoryのwrite
外部API確認	domainを絞ったnetwork
MCP利用	serverごとのtool確認

read-onlyで足りる作業

調査、仕様確認、PR review、公開URL確認は、read-onlyで足りる場面が多いです。最初からwriteや広いnetworkを前提にせず、読むだけで終わる依頼を別にしておくと安全です。

「まず調べて、必要なら修正して」は便利に見えますが、権限の境界が曖昧になります。調査commandと修正commandを分けると、実行前の判断がしやすくなります。

変更と外部接続を伴う作業

修正、publish、deploy、外部API、MCP tool利用は、別扱いにします。権限だけでなく、成果物と承認も変えます。

たとえば外部toolを使う依頼なら、どのMCP serverを使うか、どのdomainへ接続するか、結果をどこまで保存するかを決めます。networkを使う依頼は、成功時だけでなく失敗時の報告も重要です。

Codex設定やpermission profileの考え方は、公開済み記事のCodex設定を増やす前に決めることでも扱っています。

成果物の型を決める

項目	内容	見方
Summary		結論。
Evidence		根拠。
Diff		変更点。
Not checked		未確認。

定型依頼は、返答の型まで決めるとreviewしやすくなります。

定型依頼は、呼び出し方より返し方が大事です。成果物の型がないと、毎回「で、何が終わったのか」を読み直すことになります。

作業	返してほしいもの
調査	結論、根拠、未確認、次の行動
review	findings、severity、file/line、test gap
修正	変更概要、触ったfile、test結果、残リスク
公開	公開URL、post ID、public QA、失敗時の処理
定期実行	実行日時、対象、結果、次回までの課題

完了報告

完了報告には、成功したことだけでなく、確認した範囲を入れます。ただし、記事本文の早い位置に「確認した前提」のような読者にとって重いsectionを置く必要はありません。作業報告としての確認範囲と、読者向け本文の流れは分けます。

良い完了報告は短く、判断に必要な証跡を含みます。

項目	例
Done	何を終えたか
Evidence	command結果、URL、file
Not run	実行していないtest
Risk	残る不確実性
Next	次に人間が見ること

未確認の残し方

未確認を隠すと、定型依頼は危険になります。特に外部サービス、価格、権限、API仕様、公開状態は変わりやすいため、確認日と情報源を残します。

「たぶん動く」ではなく、「ここまでは確認済み、ここは未確認」と返す型にします。これだけで、Codexの結果をreviewしやすくなります。

導入初週の進め方

1. 1日目

   よく使う依頼を集める。

2. 2日目

   Actionsと分ける。

3. 3日目

   skill候補を選ぶ。

4. 5日目

   権限を見直す。

5. 7日目

   成果物の型を固定。

最初は数を増やすより、同じ依頼を安定して使える形にします。

最初の1週間は、Commandsを増やすより、すでに繰り返している依頼を観察します。

日	やること	見ること
1日目	よく打つ依頼を集める	何を短縮したいか
2日目	CommandsとActionsを分ける	thread操作かterminal taskか
3日目	skill候補を選ぶ	手順として残す価値
5日目	権限を見直す	read/write/network
7日目	成果物の型を固定する	報告が読めるか

初週で見るべき失敗は、「便利になったか」だけではありません。対象projectを間違えないか、test commandが古くないか、外部toolを使う依頼が広すぎないか、未確認が残るかを見ます。

小さく始める例

最初に作るなら、次のような粒度が扱いやすいです。

候補	置き場所	理由
PR reviewを開始する	slash command	thread内操作として明確
dev serverを起動する	Action	projectの共通task
release前QAを行う	Skill	手順と停止条件が必要
repoのtest方針を渡す	AGENTS.md	毎回読む前提
external API調査を許す	Permissions	network境界が必要

小さく始めると、どこに置くべきかの判断が育ちます。いきなり「全部やるcommand」を作らないほうが、あとから直しやすいです。

FAQ

Slash?

thread操作。

Action?

terminal作業。

Skill?

手順化。

Rule?

repo前提。

迷ったら、どの場所で再利用したい作業かへ戻ります。

Commandsだけで全部まとめてよいですか？

おすすめしません。Commandsは入口として便利ですが、長い手順やproject固有の実行commandまで抱えると保守しにくくなります。terminal taskはActions、手順はSkills、repo前提はAGENTS.mdへ分けます。

/review と自作のreview手順はどう分けますか？

/review はreviewを始める入口として使い、review観点や報告形式はAGENTS.mdやskillへ寄せます。たとえば「security、regression、test gapを必ず見る」は、毎回promptへ書くより作業契約として残します。

Actionsにtestを入れればskillはいらないですか？

test実行だけならActionsで足ります。失敗時にどこを見るか、修正してよい範囲、報告形式、公開前の停止条件まで含むならskillが向いています。

teamで共有するなら何から整えますか？

まずAGENTS.mdでrepoの前提を揃えます。次にActionsで共通taskを揃えます。その後、繰り返し使う複雑な作業をskillにします。Commandsは入口として、必要なものを呼びやすくします。

外部toolを使う依頼はどう扱いますか？

外部toolを使う依頼は、通常の定型依頼と分けます。どのtoolを使うか、どのdomainへ接続するか、取得した情報をどう扱うか、失敗時にどう報告するかを決めます。

次に読むなら

参照した主な情報源

• Codex app commands – OpenAI Developers
• Codex app features – OpenAI Developers
• Local environments – Codex app – OpenAI Developers
• Permissions – Codex – OpenAI Developers
• Skills – Codex – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

更新履歴

1. 2026年6月1日

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

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

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