Codex Skillsの作り方｜ブログ執筆スキルを実例公開

Codex Skillsを作りたい。
でも、何を書けばいいのか。
最初はそこで止まりますよね。

検索すると、英語やコードがずらり。
ぼくも「これは開発者向けか」と身構えました。

ところが、最初に要るのは一作業です。
毎回説明している順番を、SKILL.mdへ移します。
完璧な設計図はいりません。

ここから実例を使います。
作成、保存、テストまで順番にたどります。
最後は、自分で作り始められる状態です。

このブログは、AIツールを「むずかしいもの」から
「自分の道具」に変えていく、
その過程を一緒にたどる場所です。

もしもAIが、あなたの仕事の右腕になったら。
その最初の一歩を、ここから始めましょう。

作る前に全体像を押さえたい方は、Codex Skillsの仕組みと使い方を先に読むと迷いません。

Codex Skillsは「繰り返す仕事」を覚えさせる仕組み

先に言うと、Skillsは手順書です。
指示や資料を一つにまとめます。
必要ならスクリプトも置けます。

OpenAIのSkills作成ガイドでも、再利用できる仕事の流れです。
何でも自動化する魔法ではありません。

普通のプロンプトとの違い

一度だけ頼むなら、プロンプトで十分です。
「この文章を短くして」で終わります。

でも、毎回同じ注意を書く。
保存先も毎回伝える。
最後の確認も頼み直す。

こうなると、説明だけでひと仕事です。
Skillsは、その繰り返しを外へ出します。

つまり、長さの違いではありません。
次も使うかどうかが分かれ目です。

外部のデータや操作へつなぐMCPとは、役割が別です。
OpenAIのSkills解説でも、役割の違いを確認できます。

仕様は、2026年7月29日時点です。
保存場所や再起動の案内は、OpenAI公式で確認済みです。

SKILL.mdは必要になったときだけ読み込まれる

Codexは、まず名前と説明を見ます。
仕事に合えば、詳しい手順を読みます。

これは段階的な読み込みです。
全部の手順を、最初から抱えません。
道具箱から必要な物だけ出す感覚です。

だからdescriptionが大切です。
ここは店の看板みたいなもの。
何屋かわからないと、入ってもらえません。

仕組みが見えたら、題材を一つ選びます。

作る前に「1つの仕事」へ絞る

作成前の一番大事な所です。
最初から仕事全部を入れません。
一つのゴールへ絞ります。

ぼくなら「ブログを伸ばす」は選びません。
広すぎて、終わりが見えないからです。

スキル化に向く仕事

候補は、繰り返す仕事です。
順番がだいたい同じ。
終わったかを確認できます。

• 記事の下書き前チェック
• 会議メモの決まった整形
• ファイル名と保存先の確認
• 公開前のリンク切れ確認

二度説明した仕事は、有力候補です。
面倒だと感じた所に、Skillの種があります。

最初から全部入りにしない

大きなSkillは、直す場所も増えます。
使うたび、別の所が気になる状態です。

そこで、作業の境界を切ります。
記事なら「構成だけ」「確認だけ」でも大丈夫。
一回で終わる大きさが目安です。

一つ動けば、次を足せます。
最初から城を建てると、玄関で日が暮れます。

入力・出力・完了条件を先に決める

Skillには入口と出口が必要です。
何を受け取り、何を返すか。
どこで終わるかも決めます。

完了条件は、動詞で書きます。
「保存する」より「読み戻して確認する」。
成功を思い込みにくくなります。

題材が決まったら、いよいよ作成です。

Codex Skillsの作り方は5ステップ

ここから、実際の作成です。
入口は組み込みのskill-creator。
会話しながら土台を作れます。

表の順で進めれば大丈夫です。
作ることより、使えることを優先します。

1. `$skill-creator`へ作りたい仕事を伝える

Codexで$skill-creatorを呼びます。
次に伝えるのは、作りたい仕事と使う場面です。

ブログ記事をWordPress下書きまで進めるSkillを作ってください。キーワードを受け取り、構成だけ確認を取り、本文とFAQを作ります。公開はせず、保存後に下書き状態を読み戻してください。

このくらいで始められます。
ファイル構成を先に暗記しなくても大丈夫です。

creatorは、目的や発動条件を聞きます。
指示だけで足りるかも整理します。

2. 保存範囲を決める

次は、使う人を決める番です。
一つの仕事場だけか。
自分の全プロジェクトか。

プロジェクト用なら.agents/skillsです。
自分用なら$HOME/.agents/skillsへ置けます。

保存場所は用途で分けます。
最初はプロジェクト用が扱いやすいです。
関係ない仕事で呼ばれにくくなります。

3. SKILL.mdへ役割・手順・完了条件を書く

最低限の中心はSKILL.mdです。
先頭にnameとdescriptionを書きます。

descriptionには使う場面を入れます。
使わない場面も書けば境界は明確です。

本文には順番を書きます。
入力、停止、出力、完了条件も必要です。
曖昧な「いい感じに」は外します。

4. 必要な資料とスクリプトを分ける

詳しい資料はreferencesへ分けます。
画像や型はassetsの担当です。
決まった処理はscriptsの出番です。

OpenAIのSkills設計ガイドでは、資料・素材・処理を分けています。
SKILL.mdを倉庫にしない工夫です。

ただし、最初から作りません。
手順だけで回るなら、そのままで十分です。

5. 5パターンで呼び出しをテストする

最後は、発動の確認です。
直接指定する依頼だけでは足りません。

• 直接Skillを指定する依頼
• 同じ目的を別の言葉で頼む依頼
• 情報不足で質問が必要な依頼
• Skillを使わない方がよい依頼
• 情報を勝手に作らない境界例

動くかだけでなく、動きすぎないか。
ここまで見て、初めて実務へ出せます。

次は、ブログ用の中身をそのまま見ます。

ブログ執筆スキルのSKILL.mdを実例公開

ここでは公開用に短くしました。
ぼくのブログ執筆Skillの骨組みです。

調査方法の細部は省いています。
代わりに、止まる所と終わりを残しました。

---
name: blog-draft-writer
description: ブログ記事の執筆とWordPress下書き保存を頼まれたときに使う。公開操作や、既存記事への部分修正だけの依頼には使わない。
---

# 受け取るもの
- メインキーワード
- 対象ブログ

# 手順
1. 公式情報と競合を調べる。
2. 検索意図と記事構成を作る。
3. 構成を示し、ユーザーの確認を待つ。
4. 承認後に本文とFAQを作る。
5. リンク、事実、読みやすさを検査する。
6. WordPressへdraftで保存する。
7. 保存した投稿を読み戻す。

# 完了条件
- statusがdraftである。
- タイトル、slug、本文を読み戻した。
- 予定したリンクと画像を確認した。

# 禁止
- status: publishを送らない。
- 根拠のない数字や体験を作らない。

これでも流れは見えます。
最初のSkillなら、この密度で十分です。

冒頭のnameとdescription

nameはSkillの名前です。
小文字とハイフンで、短くします。

descriptionは発動の入口です。
「ブログ用」だけでは広すぎます。

何を頼まれた時に使うか。
何には使わないか。
この二つを並べます。

着手前・調査・執筆・検証を分ける

手順は、仕事の節目で分けます。
全部を一段落に詰めません。

ぼくの例なら四つです。
着手前、調査、執筆、検証。
どこで止まったかも見えます。

資料が増えたら、別ファイルへ出します。
本文は道順だけで十分です。

「下書き」と「公開」を混同させない

外部へ出る操作は境界を決めます。
ぼくのSkillは下書きまでです。

「WordPressへ保存する」だけだと曖昧です。
draftと書きます。
publishを送らないことも残します。

AIが悪いわけではありません。
言葉が広いと、仕事も広がります。
ここは人が線を引く所です。

読み戻しを完了条件にする

保存成功の表示だけでは終わりません。
保存した投稿をもう一度読みます。

status、slug、本文を確かめます。
画像やリンクも確認対象です。
そこで一致して、ようやく完了。

料理なら、皿へ盛った後の味見です。
鍋の中だけ見て終わらせません。

この読み戻しも、失敗から増えた手順です。

ぼくのブログ執筆スキルは失敗を足して育てた

今のSkillは、最初から整っていません。
むしろ、失敗の寄せ書きから始まりました。

転機は、ブログ画像を作った時です。
H2画像を六枚作りました。
そこからが長かったんです。

画像6枚を正しく保存できなかった

画像の生成自体はできました。
ところが、自動保存できません。

直URL、ブラウザ内取得、Base64。
いろいろ試しました。
まあ、見事に止まりました。

最後は、手動保存へ切り替えました。
許可なく有料APIへ進まない。
この境界をSkillへ足しました。

WordPressの403とH2画像の位置で詰まった

保存できても、次で403です。
画像のアップロードが止まりました。

全画像を再エンコードしました。
メタデータも外しました。
そこで六枚を送れました。

終わったと思ったら、位置も違います。
画像がH2の直下に見えません。

原因はGutenbergのブロックでした。
見出しを閉じる前に、画像が入っていました。

そこで、見出しブロックの後へ移動。
保存後に六件を読み戻しました。

失敗を1行の注意ではなく確認工程へ変えた

「次は気をつける」では弱いです。
疲れた日は、だいたい忘れます。

だから、工程へ変えました。
全画像を再エンコードする。
保存後はH2直後の数を読む。

失敗のたびに一つ足しました。
この一記事が、今の画像制作フローの土台です。

以前は六枚なら六回の手作業でした。
今はまとめて任せられます。
かなり時短できると感じました。

Skillは、完成品を買う感覚ではありません。
自分の仕事で育てる道具です。

では、作ったSkillが動かない時も整理します。

作ったのに動かないときの確認順

呼ばれない時は、順番に見ます。
一度に全部を直しません。
原因がわからなくなるからです。

上から一つずつ直します。
変えたら、同じ依頼でもう一度試します。

descriptionに実際の頼み方が入っているか

説明が抽象的だと、見つかりません。
「文章を助けるSkill」では広すぎます。

読者が使う言葉を入れます。
「ブログ記事を書いて」などです。
使わない依頼も添えます。

descriptionを直す目安は発動です。
名前の格好よさではありません。

保存場所とSKILL.mdの名前は正しいか

プロジェクト用なら、範囲を見ます。
現在地からリポジトリの上までが対象です。

フォルダ内にはSKILL.mdが必要です。
公式要件どおり、ファイル名は大文字のSKILL.mdにそろえます。
ここが、地味に効くポイントです。

変更が見えない時は、再起動も候補です。
公式案内に沿って、一度再起動を試します。

指示が大きすぎないか

途中で迷うなら、仕事を分けましょう。
入力が増えすぎていないかも見ます。

作成、公開、分析を一つにすると重いです。
成功条件も三つに割れます。

まず下書きまでに戻します。
一周してから、次を考えれば十分です。

非対象の依頼でも誤作動しないか

最後は、呼ばれすぎを見ます。
動けば合格ではありません。

短い文章修正でも、ブログSkillが動く。
これでは境界が広すぎます。

直接、言い換え、不足、非対象、境界。
五パターンで試す理由がここにあります。

確認できたら、最初の一作業へ戻ります。

まとめ｜まずは毎回説明している作業を1つスキル化する

作り方は、思ったよりシンプルです。
選ぶのは、繰り返す一作業。
入口と出口をSKILL.mdへ書きます。

• Skillsは繰り返す仕事の手順書
• 最初は一作業へ絞る
• nameとdescriptionが入口になる
• 保存ではなく読み戻しまで決める
• 五パターンで発動と誤作動を試す

覚えておくのは、この五つです。
立派な説明書から始めなくて大丈夫です。

まず、今週二度説明した仕事を一つ書きます。
次の文をCodexへ渡してみてください。

$skill-creator 毎回繰り返している「○○」を、再利用できるSkillにしてください。入力、手順、出力、完了条件を決め、使わない場面もdescriptionへ入れてください。

失敗したら、手順を一つ足す。
その一行が、明日の自分を助けます。

完璧なSkillより、二回使えるSkill。
まず一つ、自分の仕事で育ててみてください。

一問一答（Codex Skillsの作り方）

👉 最初は一作業へ絞り、SKILL.mdへ入口・手順・完了条件を書けば大丈夫です。

Codex Skillsは非エンジニアでも作れますか？

作れます。まず繰り返す一作業を選び、$skill-creatorへ目的と完了条件を伝える所から始められます。

SKILL.mdには最低限何を書けばよいですか？

nameとdescriptionに加え、受け取るもの、手順、出力、完了条件を書きます。使わない場面も入れると誤作動を減らせます。

Codex Skillsはどこへ保存しますか？

プロジェクト用は.agents/skills、自分の全プロジェクトで使うものは$HOME/.agents/skillsへ保存できます。

Codex Skillsが呼び出されない原因は何ですか？

descriptionが実際の頼み方と合わない、保存場所が対象外、SKILL.mdの名前や配置が違う、といった原因があります。一つずつ直して試します。

Codex SkillsとMCPの違いは何ですか？

Skillは仕事の手順を教える仕組みです。MCPは外部のデータや操作へつなぐ仕組みで、両方を組み合わせることもできます。