Codexを更新したら、スキルや.mdファイルもアップデートしたほうがいい理由
NEW8月21日公開※内容は運営者が考え、AIで整えています。
「ブログを作って、表示確認まで進めて」と頼んだのに、構成案の確認で止まる。
別の日は同じ依頼で最後まで進む。そこでルールを足すと、今度は確認事項が増えて、さらに遅くなる。
Codexを仕事に使っていると、こんな場面があります。原因はAIの能力不足ではなく、AIが読むファイルに別々の指示が書かれていることかもしれません。
先に、この記事で一番伝えたいことを書きます。
AIを賢くする前に、AIが迷わない仕事場をつくる。
そのために作ったのが、自分用Skillのmy-updateです。現在Codexがプロジェクトとして認識している作業フォルダを基準に、指示、Skill、設定、scripts、CIを調べ、必要な変更だけを行います。
同じ依頼で結果がぶれるのは、AIの能力だけが原因ではない
たとえば、AIが同時に次の指示を読んでいたらどうでしょう。
- 共通ルールには「安全な作業は実装とテストまで進む」
- 別のSkillには「計画を見せたら承認を待つ」
- 古い設定には「ファイルを変更しない」
- 今回の依頼には「最後まで自律的に完了する」
一つずつ見ると、理由のあるルールです。しかし同時に読ませると、Codexは「進むのか、止まるのか」の判断に迷います。
OpenAIのGPT-5.6モデルガイダンスでは、利用者の意図や求める作業レベルを以前より理解しやすくなり、すべての手順を細かく指定しなくても進められる場面が増えたと説明されています。一方で、事業の背景、絶対に守る制約、承認が必要な境界、完了条件は明確にする必要があります。
同じ資料には、重複した指示や例を減らした社内のコーディングエージェント評価で、評価スコアが約10〜15%上がり、総トークンが41〜66%、費用が33〜67%減った例も示されています。これは保証値ではありません。自分の代表的な仕事で比べるための目安です。
Codexは、プロジェクトのルートから現在の作業フォルダまでAGENTS.mdを重ねて読み、作業場所に近い指示を優先します。だからこそ、全体の共通ルールと、その事業だけのルールを分ける必要があります。
AIが読むものを「共通ルール・専門知識・実行処理」に分ける
AIの仕事場は、チャットのプロンプトだけではありません。大きく三つに分けると整理しやすくなります。
| 役割 | 主な置き場所 | 置く内容 |
|---|---|---|
| いつも使う共通ルール | AGENTS.md | 事業背景、安全境界、判断基準、完了条件 |
| 必要なときだけ使う専門知識 | Skill・references/ | ブログ制作、公開、監査などの専門手順と詳しい資料 |
| 同じ結果が必要な実行処理 | scripts/・設定・CI | 検査、変換、生成、テスト、デプロイ条件 |
たとえば「外部公開は確認する」は全作業に関わる共通ルールです。「ブログでは各H2の直後に画像を置く」はブログ用Skillへ分けます。「画像が横長か検査する」は、毎回文章で説明せずscriptにできます。
同じ内容をAGENTS.md、CLAUDE.md、プロンプト、複数のSkillへコピーすると、どれか一つだけ古くなります。反対に、すべてを一つの巨大なファイルへ詰め込むと、関係のない仕事でも大量の説明を読むことになります。
大切なのは、全部を一か所へ集めることではありません。正本を一つにし、必要な情報だけを必要なときに読むことです。
OpenAIのSkillの案内でも、SKILL.mdを中心に、長い資料はreferences/、繰り返すコマンドはscripts/へ分ける構成が紹介されています。
my-updateは、消すことより「迷わず進める形」をつくる
my-updateは、特定のドライブや固定フォルダを前提にしません。その時点でCodexがプロジェクトとして認識している作業フォルダを基準にします。
流れはシンプルです。
- 調査：
AGENTS.md、Skill、prompts、references、scripts、設定、CIを確認する - 整理：維持・修正・統合・移動・削除に分ける
- 編集：正本を決め、重複、矛盾、古い参照だけを直す
- 検証：validation、lint、テストを行う
- 比較：同じ代表タスクで変更前後を比べる
目的は、ファイルを減らすことではありません。Codexが少ない情報で判断し、安全な範囲は止まらず進み、最後に検証結果を示せる状態をつくることです。
そのため、安全境界やユーザー固有の重要ルールは残します。既存の未コミット変更も壊しません。公式管理のファイルや生成物も、AIの実行改善に必要でなければ触りません。
| 整える前 | 整えた後 |
|---|---|
| 同じ指示が4か所にある | 共通ルールの正本を一つにする |
| 関係のない依頼でもSkillが発動する | 発動条件を具体的に絞る |
| 長い確認手順を毎回読ませる | 決定的な検査はscriptへ移す |
| 固定パスが別のprojectで壊れる | 現在のworkspace rootを基準にする |
| 整理しただけで完了する | 代表タスクで実行品質を比較する |
最初は、よく頼む仕事を一つだけ比べればよい
地域の事業者、学校、福祉施設、個人事業主では、一人が告知、資料作成、問い合わせ対応、サイト更新まで担うことがあります。AI環境が散らかると、毎回の説明と確認だけで時間を使います。
最初から全ファイルを短くする必要はありません。次の順で十分です。
- 「ブログ作成から表示確認まで」など、よく頼む仕事を一つ選ぶ
- 変更前の確認回数、止まった場所、完了した範囲を記録する
- 重複した指示を一群だけ整理する
- 同じ条件でもう一度頼み、結果を比べる
- 良くなった変更だけを残す
見るのは速度だけではありません。必要な作業を最後まで行えたか、安全境界を守れたか、検証結果を説明できたかも確認します。
見直しの目安は、新しいモデルへ更新したとき、Skillやプロジェクトが増えたとき、同じ確認質問が続くときです。Codex、Claude Code、Cursorを併用している場合も、共通の正本と成果物の場所が分かれば、説明のやり直しを減らせます。
よくある質問
Q. AGENTS.mdは短いほどよいですか？
短さだけが目的ではありません。いつも必要な制約と完了条件は残し、特定の仕事だけで使う詳細をSkillやreferences/へ分けます。
Q. 古いSkillや設定は、全部削除してよいですか？
いいえ。まず参照先と使用状況を確認します。削除より、正本への統合や発動条件の修正で解決することもあります。
Q. 整えれば必ず速くなりますか？
断定はできません。同じ代表タスクで、完了範囲、確認回数、時間、必要ならトークン数を比べます。改善が確認できない変更は残しません。
Q. my-updateはどのprojectで使えますか？
固定パスではなく、Codexが現在認識しているproject/workspace rootを基準にします。対象の指示と未コミット変更を確認し、必要な範囲だけを編集します。
AI相談では、Codex、Claude Code、Cursorを現場で使い続けられるように、指示ファイル、Skill、設定、検証方法を事業ごとに整理します。
参考にした公式情報
※GPT-5.6の仕様と評価例は2026年8月21日時点のOpenAI公式情報を確認しています。評価結果は環境やタスクで変わるため、実際の代表タスクで比較してください。