Codexの最近の作業を見直して、スキルとサブエージェントに分ける考え方

Codexをうまく使う近道は、いいプロンプトを増やすことではなく、自分が何度も頼んでいる作業を見つけることです。

最近、とてもよかった依頼文がありました。

最近の私のコーデックスセッションを調べて、繰り返されるワークフローや繰り返されるリクエストを特定してください。

私が手動で繰り返し行っているものについては、以下を提案してください：
1. 再利用可能なワークフローの場合、スキル
2. 限定された役割や調査タスクの場合、カスタムサブエージェント

CIの失敗、PRレビュー、変更ログ、ドキュメント更新、リリース準備、デバッグ、テスト分類などの実践的なものに焦点を当ててください。

役立つものだけを作成してください。シンプルに保ってください。

この依頼がよいのは、いきなり「スキルを作って」と言っていないところです。
まず最近の作業を見直し、繰り返しがあるものだけを候補にしています。

つまり、道具から考えるのではなく、手で何度もやっている作業から考える。
ここが強いです。

私がこれをいいと感じた理由は、かなり現実的です。
Codexに作業を頼むと、成功することもあります。失敗することもあります。

でも問題は、失敗そのものではありません。
同じような頼み方をまたして、同じように失敗することです。

さらに言えば、本来やらなくてもよい確認や調査を、毎回こちらがお願いしていることもあります。
これは時間だけでなく、判断の力も使います。

だから、繰り返し出てくる作業をスキルにしておく。
すると次に似た場面が来たとき、Codex側も「ああ、これはこのパターンだな」と入りやすくなります。

毎回その場でがんばるのではなく、次に備えて作業を型にする。
この感覚が、自分にはかなりしっくりきました。

繰り返す手順はスキルにする

スキルに向いているのは、毎回ほぼ同じ流れで進む作業です。

たとえば、次のようなものです。

CIの失敗を見て、ログを読み、原因候補を出す
PRレビューコメントを読み、対応済みと未対応を分ける
変更内容からCHANGELOGの下書きを作る
リリース前にテスト、差分、ドキュメントを確認する
ドキュメント更新時に、関連ファイルとリンク切れを確認する

こういう作業は、毎回ゼロから説明する必要がありません。
見る順番、判断基準、最後の報告形式がだいたい同じだからです。

OpenAI Academyでも、スキルはCodexが従える「playbook」のようなものとして説明されています。
チームや個人の作業手順をCodexに覚えさせ、毎回説明しなくてよくするためのものです。

私の感覚でも、スキルは「AIに能力を足す」というより、自分の作業手順を固定する道具です。

限定された調査はサブエージェントにする

サブエージェントに向いているのは、役割が狭い作業です。

たとえば、次のようなものです。

CIログだけを見る調査役
影響範囲だけを洗い出すレビュー役
テストの失敗を分類する役
PR差分からリスクだけを見る役
ドキュメントの古い記述だけを探す役

ここで大事なのは、サブエージェントに全部任せないことです。
役割を狭くするほど、結果が使いやすくなります。

メインのCodexは全体を見ます。
サブエージェントは、狭い範囲を深く見ます。

この分け方にすると、会話が散らかりにくくなります。
「調査」「判断」「修正」「報告」が混ざりにくいからです。

スキルとサブエージェントの分け方

迷ったら、次のように分けるとわかりやすいです。

作業の種類	向いている形
毎回同じ手順で進む	スキル
見る範囲が狭い	サブエージェント
判断基準や報告形式が決まっている	スキル
並行して調べたい	サブエージェント
外部ツールや社内データを見る	プラグインやMCPも検討

私なら、まずこう考えます。

何度も同じ説明をしているならスキル。
毎回違う場所を調べる専門役ならサブエージェント。

この2つだけで、かなり整理できます。

作る前に、最近のセッションを見る

いちばん大事なのは、作る前に最近のセッションを見ることです。

なぜなら、自分では「重要な作業」だと思っていても、実際にはあまり繰り返していないことがあるからです。
逆に、毎回小さく説明しているのに、自分では気づいていない作業もあります。

最近のセッションを見ると、成功パターンだけでなく失敗パターンも見えます。
「この確認を先にしていれば止まらなかった」「この作業は毎回やっているけれど本当は自動でよい」というものが出てきます。

そこをスキルにすると、作業のたびに少しずつ学習が進みます。
次の依頼で同じ説明を減らせるからです。

たとえば私の場合、こういう作業は繰り返しになりやすいです。

記事の方針整理
公開前チェック
競合との差分確認
アナリティクスから次の改善を選ぶ
本番反映後の確認

こういうものは、毎回「どう進めるか」を説明するより、最初から型にしたほうが速いです。

役立つものだけ作る

この依頼文の最後にある「役立つものだけを作成してください。シンプルに保ってください。」がかなり大事です。

AI運用は、増やしすぎると逆に遅くなります。
スキルもサブエージェントも、作っただけでは価値になりません。

使う場面がすぐ言えるものだけ作る。
名前を見ただけで役割がわかるものだけ残す。
迷うものは、まだ作らない。

このくらいでちょうどいいです。

Codexの公式ユースケースにも、PRレビュー、バグ分類、ドキュメント更新、リリースに近い検証作業など、実務寄りの例が並んでいます。
だからこそ、最初に作るなら「便利そうな抽象スキル」より、実際に何度もやっている仕事がよいです。

そのまま使える依頼文

自分用に使うなら、少し短くしても十分です。

最近のCodexセッションを見て、私が繰り返している作業を3つだけ出してください。

それぞれについて、次のどちらが向いているか判断してください。
- 毎回同じ手順ならスキル
- 狭い調査や役割ならサブエージェント

CI、PRレビュー、ドキュメント更新、リリース準備、デバッグ、テスト分類のような実務作業を優先してください。
作る価値が薄いものは候補から外してください。

最初は3つでいいです。
多く出すより、実際に次回も使うものを残すほうが大事です。