Codex Skillsで記事執筆と内容確認の手順を再利用する方法

2026年10月4日

毎週 AI を使って記事を書いているのに、そのたびに文体、情報源の確認方法、公開前のチェック項目を伝え直していませんか。Codex Skills を使えば、そうした繰り返しの指示を再利用できる手順としてまとめられます。約 20 分で、ブログ記事の下書きと確認に使う小さな Skill を作り、サンプルのテーマで試します。作業用フォルダーと、そのフォルダーを読み取れる Codex セッションが必要です。

Skill は Codex が手順を覚えておく助けになります。最終結果は引き続きあなたが確認してください。

準備

必要なのは、OpenAI Codex、プロジェクト用またはテスト用のフォルダー、そして品質に自信のある過去の記事です。過去の記事がなければ、読者は誰か、望む文体、公開前の確認基準という三つを書き出すだけで構いません。この記事では初心者向けの AI 解説記事を例にしますが、製品紹介、使い方の説明、社内ニュースレターに置き換えてもよいでしょう。

初めて取り組む場合は、目的と成果物が明確なプロンプトの書き方とバイブコーディングとは何かも参照してください。

手順

1. 具体的な繰り返し作業を一つ選ぶ

最初から「すべてのコンテンツを作る」という Skill を作らないでください。入力と結果がはっきりわかる作業を選びます。ここでは、提供された情報源をもとにブログ記事の下書きを作り、人が確認すべき点を報告することです。入力はテーマ、読者、情報源のリンク、想定する長さです。出力は下書き、使用した情報源の一覧、検証が必要な記述です。

ファイルを作る前に、最初の依頼を自分用に書いておきます。

目的：[読者層]向けに[テーマ]についてのブログ記事を書く。
入力：[情報源へのリンク]、[製品メモ]、[記事の見本]。
出力：導入、各見出し、結論を含む下書き。
確認：根拠となる情報源がない記述を明示する。機能、価格、公開日を推測しない。

AI 製品の情報はすぐに変わります。手順では確認先を示し、推測を断定に変えないようにしてください。

2. Skill のフォルダーを作る

OpenAI の例では、Skill ごとに独立したフォルダーを設け、名前、説明、指示を記した SKILL.md ファイルを入れます。テスト用プロジェクトでは .codex/skills/blog-review/SKILL.md に置けます。自分のマシン上の複数のプロジェクトで使いたい場合、OpenAI のドキュメントには ~/.codex/skills/ に置く例もあります。共有したい範囲に合う場所を選んでください。ほかの人から受け取った Skill を使う前には、ファイルの内容と付属するプログラムを読んでください。

次のサンプル内容でファイルを作ります。説明には Codex が Skill を使うタイミングを書き、本文には何をするかを書きます。

---
name: blog-review
description: ユーザーがテーマ、読者、参考情報源を提供したときにブログ記事を下書きし、確認する。
---

ブログ記事の下書きや確認を依頼されたら：
1. テーマ、読者、目的、使用を許可された情報源を確認する。
2. 書き始める前に情報源を読む。情報源が欠けている、または開けない場合は、不足しているものを明示する。
3. 導入で中心となる問いにすぐ答え、読者の疑問に沿って本文を構成する。
4. 価格、日付、機能、利用可能な範囲に関する検証が必要な主張に印を付ける。
5. 下書きと最終チェックリストを返す。記事を自分で公開しない。

blog-review という名前は一例です。手順に文章による指示だけが必要なら、実行可能なコードやアクセスキーを追加しないでください。

3. 実際の依頼で Skill を呼び出す

OpenAI は Skill の名前を直接指定して試す方法を案内しています。Skill があるフォルダーで Codex を開き、短い依頼を入力します。

$blog-review を使って、[読者]向けに[テーマ]の記事を下書きしてください。
使用する情報源は[リンク 1]と[リンク 2]だけにしてください。
長さは約[語数]語にしてください。まだ公開しないでください。

最初のテストには、情報源の誤用や手順の抜けを見つけやすいよう、よく知っているテーマを選びましょう。Codex が Skill を認識しない場合は、ファイルの場所、SKILL.md という名前、説明、フォルダーの読み取り権限を確認してください。Skill の呼び出し方は Codex の環境によって異なる場合があります。

4. 編集者の目で出力を読む

「読みやすい記事か」だけで判断しないでください。最初に決めた目標を一つずつ確認します。導入は問題に答えていますか。具体的な主張はそれぞれ情報源に裏付けられていますか。同じ内容を繰り返している箇所はありませんか。仮定の例と実際の事実を区別していますか。確認事項の一覧は、まだ根拠のない記述を正確に示していますか。

確認しやすくするため、記事の後に短い表を追加するよう Codex に依頼します。

下書きの後に、次を列挙してください。
1. 重要な主張を三つと、それぞれに対応する情報源。
2. 検証できなかった情報。
3. 公開前に編集者が判断すべき点を二つ。

この表はあくまで補助です。元の情報源を開いて直接確認してください。OpenAI 製品については公式ドキュメントを優先し、情報源にリリース状況が示されている場合は明記してください。

5. 一度試したら手順を修正する

Codex の導入が長すぎるなら、Skill を「導入は最大三文」と修正します。確認日がない価格を書くなら、「すべての価格に情報源と閲覧日を付ける」を追加します。宣伝文句を挿入するなら、売り込み口調を避ける指示を加えます。ルールを修正し、同じ依頼でもう一度試して、何が変わったかを確かめましょう。

繰り返し使うルールは Skill に、今回だけの要件はプロンプトに入れます。たとえば「情報源を必ず確認する」は Skill のルールで、「中学 2 年生向けに説明する」は今回の記事の要件です。

6. 適切な場面で Skill が呼び出されるか確認する

一度うまく動いただけでは十分ではありません。さらに三つの依頼を試してください。$blog-review を明示する依頼、「ブログ記事の確認を手伝って」とだけ書く依頼、そしてこの Skill が関与すべきでない「CSS のバグを修正して」のような別の依頼です。OpenAI のテストガイドによると、名前と説明は Codex が Skill を使うか判断する重要な手がかりです。Skill が広すぎる場面で起動するなら説明を具体化し、必要な場面で起動しないなら用途をより明確に書きます。

この三つの依頼を保存し、Skill を修正するたびに再実行してください。

結果の例

ある AI ツールについての公式ドキュメントを二ページ渡し、初心者向けの記事を依頼したとします。Skill を使った後に期待する成果は下書きだけではありません。次のような確認欄も含まれます。

下書き：このツールで読者ができること、使い始める方法、知っておくべき制限。
使用した情報源：ユーザーが提供したドキュメント二ページ。
検証が必要な点：対応する国とアカウントの種類。
編集者の判断：実際の操作画面のスクリーンショットを追加すべきか。
状態：下書き、未公開。

情報源に価格が書かれていないなら、推測せずに**「価格は未確認」**と記してください。

よりよい結果を得るためのヒント

用途に合わせて説明を書く。「参考情報源があるときにブログ記事を下書きし、確認する」のほうが「うまく書くのを助ける」より役に立ちます。Codex がいつその手順を使うべきか判断できるようにします。

SKILL.md は簡潔にする。 長い評価基準の表、記事のテンプレート、承認済みの例があるなら、Skill の参考資料フォルダーに置き、いつ読むかを指示します。OpenAI のドキュメントでは Skill に references/、assets/、scripts/ を追加できますが、実際に作業に役立つ場合だけ追加してください。

リスクの高い作業を分ける。 下書き、情報源の確認、一般公開はそれぞれ別の工程です。サンプルの Skill は下書きで止まります。実際に公開の手順が必要になったら、一般的な指示に判断を任せず、アクセス権限と確認の工程を明確にしてください。

実際の依頼で評価する。 簡単な記事、情報源が不足した記事、対象外の依頼を一つずつ選びます。Codex が適切な場面で「まだわからない」と言えるか確認してください。AI エージェントとチャットボットの違いの記事では、複数の手順をこなすアシスタントにも制限が必要な理由を説明しています。

知っておくべき制限

Skill は再利用できる指示であり、すべての文が正しいことを保証するものではありません。手順の一貫性は高められますが、誤った情報源、曖昧なプロンプト、質の低い見本記事があれば、下書きの品質は下がります。コンテンツ制作者は、製品名、時期、価格、画像の利用権、読者の判断に影響しうる主張を確認しなければなりません。

共有する予定の Skill にパスワード、API キー、非公開文書を入れないでください。実行可能なプログラムが付属している場合は、利用を許可する前に、ほかのツールのコードと同じように内容を確認してください。OpenAI のドキュメントも、Skill はエージェントのツールの使い方に影響する可能性があると注意を促しています。出所と権限を慎重に確認してください。

コードの確認、画像のデザイン、公開予定の管理に進む場合は、それぞれに合う入力と完了基準を持つ別の手順を作ってください。