Codexでブログ運用を続けていると、だんだん便利になる一方で、少し気になることも出てきます。
毎回、同じ前提資料を読み、同じ禁止事項を確認し、同じWordPress保存フローを思い出し、同じSNS運用ルールを確認する。これは安全運用には必要です。しかし、毎回ぜんぶ読む形にしていると、作業のたびにコンテキストが大きくなり、トークン使用量も増えやすくなります。
今回の実験では、半農エンジニアラボの運用ルールをCodexの「スキル」として整理しました。目的は、Codexに任せる範囲を広げることではありません。むしろ逆で、毎回読むべきものを減らしつつ、危ない操作は確実に止めるための運用レールを作ることです。
この記事では、実際にどんなスキルを作ったのか、なぜトークン削減につながるのか、どこで失敗しそうになったのか、そしてWordPress下書き保存やSNS運用とどうつなげるかを、作業ログとしてまとめます。
今回作ったもの
今回作成したスキル名は、hannou-blog-opsです。
役割は、半農エンジニアラボのブログ運用に特化したCodex用の作業ガイドです。記事案の調査、本文作成、WordPress下書き保存、X投稿文案作成、Threads投稿文案作成、WordPress REST APIのタイムアウト対応、PowerShellプロセス掃除までを、ひとつの運用として扱えるようにしました。
スキルの中身は、大きく分けて次の5つです。
SKILL.md：スキルの入口。どんなときに使うか、最初に読むもの、絶対に守るルールを書く。references/research.md：7:00調査タスクや記事案作成の手順。references/write-draft.md：記事本文作成とWordPress下書き保存の手順。references/social.md：X文案、Threads文案、Threads投稿時の安全確認。references/recovery.md：WordPressタイムアウト、重複下書き、PowerShell残留プロセスへの対応。
ポイントは、すべての手順をSKILL.mdに詰め込まなかったことです。入口は軽くしておき、作業内容に応じて必要な参照ファイルだけ読む構成にしました。
なぜスキル化したのか
このプロジェクトには、すでにAGENTS.mdやdocs/配下の運用資料があります。そこには、WordPressへは下書きまで、Xへは自動投稿しない、Threads投稿は公開済み記事だけ、秘密情報は.envで扱う、といった大事なルールがまとまっています。
これらはプロジェクトの憲法のようなものです。なくすべきではありません。ただ、毎回すべてを読ませると、Codex側の作業コンテキストが重くなります。
特にブログ運用では、作業の種類がはっきり分かれています。
- 朝の調査だけをしたい日
- 記事本文を書いて下書き保存したい日
- 公開済み記事をThreadsで紹介したい日
- WordPress APIのタイムアウトを復旧したい日
- CodexやPowerShellの運用そのものを記事にしたい日
全部の作業で、全部の資料を読む必要はありません。そこで、最初に軽量なdocs/runtime-rules.mdを読み、必要なときだけ詳細資料に進む形にしました。
これは、Codex公式マニュアルで触れられている「繰り返し作業をスキル化する」という考え方とも相性が良いです。Codexは、プロジェクト固有のAGENTS.md、設定、MCP、スキル、オートメーションを組み合わせることで、単発のチャットではなく、継続的に改善できる作業環境として使えます。参考：Codex manual
スキル化でトークン使用量は本当に減るのか
ここは大事なので、少し慎重に書きます。
スキル化したからといって、魔法のようにトークン使用量がゼロになるわけではありません。Codexが作業する以上、指示を読み、ファイルを確認し、結果を考えるためのトークンは使います。
ただし、減らせる可能性が高い部分はあります。それは「毎回同じ長い前提を読み直すコスト」です。
たとえば、記事案を3つ作るだけの作業で、WordPress REST APIの詳細な保存手順、Threadsアクセストークン取得手順、PowerShell掃除手順まで読む必要はありません。逆に、WordPress保存中にタイムアウトしたときは、調査記事の書き方よりも、既存下書き確認、フォーム形式での更新、残留PowerShell確認のほうが重要です。
今回のスキルでは、この切り分けを次のようにしました。
- 調査だけなら
research.md - 記事作成と下書き保存なら
write-draft.md - XやThreadsなら
social.md - 復旧や掃除なら
recovery.md
これにより、Codexは最初から巨大な資料群を全部読むのではなく、作業に必要なものだけを選びやすくなります。トークン削減の本質は、短いプロンプトにすることではなく、読むべき文脈を整理しておくことだと感じました。
作業手順1：スキルの土台を作る
最初に、Codexのスキル作成用の仕組みを使って、hannou-blog-opsというスキルのひな形を作りました。
作成先は、Codexの個人スキル置き場です。リポジトリに直接入れたわけではありません。理由は、今回のスキルが「このPCでCodexがどう動くか」に近い個人運用の知識だからです。
ただし、スキルの中で参照するプロジェクトルールは、リポジトリ側に残してあります。つまり、長く残すべきルールはdocs/に置き、Codexがそれをどう読むかをスキルに書く、という分担です。
この分担はかなり大事です。もしスキルの中にすべての運用ルールをコピーしてしまうと、リポジトリ側のルールを更新したときに、スキル側とのズレが生まれます。今回のスキルでは、入口としてdocs/runtime-rules.mdを読むようにしました。詳細が必要なときは、そこからAGENTS.mdや個別ドキュメントへ進みます。
作業手順2：SKILL.mdを軽くする
SKILL.mdには、すべてを書きたくなります。けれど、それをやるとスキル化した意味が薄れます。毎回読む入口が重くなるからです。
そこで、SKILL.mdには次の情報だけを置きました。
- このスキルを使う場面
- 最初に読むファイル
- 作業内容ごとの参照ファイル
- 絶対に破ってはいけないルール
- 完了報告で出すべき情報
絶対ルールには、次のような内容を入れています。
- WordPressは必ず
draft保存まで publish、future、private、trashは使わない- Xには投稿しない
- Threads投稿は公開済み記事URLかURLなし実験ログだけ
- Threads投稿前にはDryRunと人間の明示確認を挟む
- 秘密情報は表示しない、保存しない、コミットしない
- 認証・権限・医療健康・農薬・法律税金・公開状態が不明なら止まる
こうしておくと、Codexが「できそうだから実行する」方向に流れにくくなります。自動化は便利ですが、ブログ運用では止まる力も同じくらい大切です。
作業手順3：参照ファイルを4つに分ける
次に、作業の種類ごとに参照ファイルを分けました。
research.md
research.mdは、朝の調査タスクや記事案作成のためのファイルです。
ここでは、記事候補を3案出すこと、検索需要や読者の悩みを整理すること、技術・健康・農業・税金・法律のような分野では信頼できる情報源を優先することを書きました。
重要なのは、調査だけの作業ではWordPress下書きを作らないことです。調査と執筆を分けることで、作業の暴走を防ぎやすくなります。
write-draft.md
write-draft.mdは、記事本文を書いてWordPress下書き保存するためのファイルです。
ここには、5000字以上を目安にすること、複数ソースを確認すること、オリジナルの文章として再構成すること、ローカルのdrafts/に記事バックアップを置くこと、X文案とThreads文案も作ることを書きました。
さらに、WordPress REST APIのタイムアウト対応もここに入れています。これまでの検証で、長文記事をJSON形式で一括更新するとタイムアウトすることがありました。そのため、同じ作成処理をすぐ再実行せず、まず同じslugの下書きが存在するか確認し、既存下書きがあればフォーム形式で本文を更新する流れにしています。
social.md
social.mdは、XとThreadsの扱いを分けるためのファイルです。
Xについては、文案作成までです。投稿はしません。X APIも使いません。公開後に人間がURLを差し込んで手動投稿する前提です。
Threadsについては、条件付きで投稿できます。ただし、対象は公開済み記事URLかURLなしの実験ログだけです。下書きURLは投稿しません。投稿前にはDryRunで内容を確認し、ユーザーから明示的に依頼があった場合だけ実行します。
この分け方にしたことで、「SNS」とひとまとめにして危ない操作が混ざるのを避けられます。Xは完全に文案だけ、Threadsは条件付きで投稿可能、という違いを明文化しました。
recovery.md
recovery.mdは、トラブル時のためのファイルです。
ここには、WordPress REST APIがタイムアウトしたときの対応と、PowerShellプロセスが残ったときの掃除手順を入れました。
以前、WordPress下書き保存の処理がタイムアウトし、PowerShellが残ってPCのメモリ使用率が高い状態になりました。原因は、コマンドが表面上は止まったように見えても、裏でプロセスが残っていたことです。
この経験から、タイムアウトしやすい作業の後には、残留PowerShellを確認する運用を入れました。いきなり止めるのではなく、まず候補を確認し、このプロジェクトのWordPress/Threads運用スクリプトに関係するものだけ停止します。
作業手順4：文字化けを直す
今回、地味に大事だったのが文字化けです。
最初に作ったSKILL.mdには、日本語のブログ名やWindowsの日本語パスが入っていました。PowerShellで表示したところ、一部が文字化けして見えました。
スキル自体は日本語を含めてもよいのですが、入口ファイルで文字化けが起きると、Codexがスキルを読むときの安定性に不安が残ります。そこで、SKILL.mdの説明文やプロジェクトルート表記はASCII中心に直しました。
日本語の細かい運用ルールは、リポジトリ側のdocs/runtime-rules.mdやAGENTS.mdに残してあります。スキルの入口は壊れにくく、詳細はプロジェクト資料で読む。この形のほうが、長く運用しやすいと判断しました。
作業手順5：検証でつまずいたこと
スキル作成後、検証スクリプトを実行しました。ここで、スキルの内容ではなく、検証用Python環境側にPyYAMLが入っていないため、検証スクリプトが止まりました。
これは今回のスキルの構文エラーではありません。検証スクリプトがYAMLを読むためのライブラリを見つけられなかった、という問題です。
そのため、今回は次のように切り分けました。
SKILL.mdが存在することを確認- frontmatterに
nameとdescriptionがあることを確認 - 参照ファイル4つが存在することを確認
agents/openai.yamlに表示名と説明があることを確認- 文字化けしやすい入口部分をASCII中心に修正
今後、検証スクリプトまで完全に通すなら、検証用Python環境にPyYAMLを用意する必要があります。ただし、今回の目的はスキルの運用設計と記事化なので、検証の未完了点として記録しておく形にしました。
今回のスキルで変わる運用
このスキルがあると、次回からの依頼が少し短くできます。
たとえば、今後は次のように頼めます。
半農ブログ運用スキルで、今日の7:00調査をしてこの場合、Codexはまず軽量ルールを読み、調査に必要なresearch.mdを参照すればよくなります。WordPress保存やThreads投稿の詳細まで読む必要はありません。
また、次のような依頼もできます。
半農ブログ運用スキルで、この記事をWordPress下書き保存まで進めてこの場合は、write-draft.mdを読み、WordPress保存フロー、下書きステータス、記事チェック、X文案作成まで進めます。
トラブル時には、次のように頼めます。
半農ブログ運用スキルで、WordPress保存タイムアウト後の復旧とプロセス掃除をしてこの場合は、recovery.mdを読めばよいので、復旧に必要な確認へすぐ入れます。
安全運用で特に効いたルール
今回スキル化してよかったのは、便利な手順だけでなく、禁止事項も一緒にまとめられたことです。
ブログ運用では、少しの設定ミスで公開済み記事を触ってしまったり、下書きURLをSNSに投稿してしまったり、APIキーをログに出してしまったりする可能性があります。自動化が強くなるほど、そのリスクも大きくなります。
だからこそ、スキルには次のような「止まる条件」を入れました。
- WordPress認証エラーが出たら止まる
- 下書き保存できたか確信が持てなければ止まる
- 公開・予約投稿・非公開化が必要になりそうなら止まる
- Threads投稿の認証や権限に迷ったら止まる
- 医療・健康・農薬・税金・法律の判断が怪しければ止まる
- 秘密情報が必要になったらチャットに貼らせず、
.envで扱う
スキル化は、Codexを自由に動かすためのものではなく、安全に迷わせるためのものでもあります。ここが今回の一番の学びでした。
トークン削減より大事な副作用
当初の目的は、Codexのトークン使用量を抑えることでした。
しかし実際に作ってみると、トークン削減以上に大きい副作用がありました。それは、運用の考え方が整理されたことです。
スキルにするためには、「この作業は何を入口にするのか」「どこまで自動で進めてよいのか」「どこから人間確認が必要なのか」を言語化する必要があります。
たとえば、Threads投稿は便利ですが、下書きURLを投稿してはいけません。公開済み記事URLかURLなしの実験ログだけにする。DryRunを挟む。ユーザーが明示的に投稿を依頼したときだけ実行する。こうした条件をスキルに書くことで、次回以降の判断がぶれにくくなります。
WordPress保存も同じです。タイムアウトしたら、同じ処理をすぐ再実行しない。まず同じslugの下書きを確認する。存在していたら、その投稿IDを更新する。最後に残留PowerShellを掃除する。これは、単なる手順ではなく、失敗を繰り返さないための運用知です。
今回残った課題
今回のスキル化は、ひとまず使える形まで進みました。ただし、課題も残っています。
ひとつ目は、検証スクリプトの実行環境です。PyYAML不足で公式の簡易検証が最後まで通りませんでした。スキル構造の手動確認はできましたが、今後は検証環境を整えたいところです。
ふたつ目は、スキル更新時の管理です。今後、ブログ運用ルールを変えたときに、docs/runtime-rules.mdとスキル側の参照先がズレないようにする必要があります。
三つ目は、定期運用との接続です。Codexのオートメーションは、スキルと組み合わせて使えるとされています。参考：Codex manual。今後は、毎日7:00の調査、12:00の執筆下書き保存に、このスキルをどう接続するかを検証していきたいです。
まとめ
今回は、半農エンジニアラボのCodex運用をhannou-blog-opsというスキルにまとめました。
やったことは、派手な自動化ではありません。むしろ、毎回読む資料を軽くし、必要なときだけ詳細を読むようにし、危ない操作では止まる条件を明確にする作業でした。
結果として、次のような形になりました。
- 調査、執筆、SNS、復旧を別々の参照ファイルに分けた
- WordPressは下書き保存までというルールを入口に置いた
- Xは投稿せず、文案作成だけにした
- Threadsは公開済み記事URLかURLなし実験ログだけに限定した
- WordPressタイムアウト後の重複下書き防止とPowerShell掃除を運用に入れた
- トークン使用量を抑えるため、必要な資料だけ読む構成にした
Codexのスキル化は、作業を速くするだけのものではありません。自分の運用思想を、Codexが迷いにくい形へ翻訳する作業だと感じました。
半農エンジニアラボでは、AIをただ便利に使うだけでなく、失敗したログも含めて運用を育てていきます。今回のスキル化も、その一歩です。
次は、このスキルを使って日次の7:00調査、12:00執筆、WordPress下書き保存、公開後のThreads共有まで、どこまで安定して回せるかを検証していきます。
