Projects / 実践記録

AIに任せる仕事は、プロンプトではなくskillにした方がいい

本ページはアフィリエイトプログラムを利用しています

AIに仕事を任せるとき、最初はプロンプトを頑張りがちです。
長い前提を書いて、注意点を書いて、出してほしくない情報を書いて、最後に成果物の形式を書く。

もちろん、それでも動く。
でも、同じ作業を何度もやるようになると、だんだんつらくなってくる。

毎回同じ説明を貼る。
少しずつ表現が変わる。
前回は入れていた注意点を、今回は入れ忘れる。
AIの出力も、そのたびに少しブレる。

ここが気になっていました。

最近は、CodexでもClaude Codeでも、skill という考え方が前に出てきています。
OpenAIのCodex docsでも、skillsは再利用できるworkflowのための形式として説明されている。
Claude Codeでも、SKILL.md と補助ファイルを使って、特定の作業手順を呼び出せる形になっている。

僕も実際に、ブログ運用のいくつかをskill化してみました。
公開前チェック。
公開後の確認。
出典確認。
AIウォッチをtaupeの記事候補に変える作業。

やってみて思ったのは、AIに任せる仕事は、長いプロンプトを毎回書くより、skillとして手順ごと育てた方がいい、ということです。

毎回プロンプトを書く運用は、思ったより再現性が低い

プロンプトは、軽く試すには便利です。

「この記事をチェックして」
「このニュースを要約して」
「taupe向けに構成案を作って」

これくらいなら、毎回書いてもそこまで問題はありません。

ただ、実際の運用になると、依頼はもっと細かくなります。

たとえば、taupeの記事公開前チェックなら、見るべきものは多い。

title。
description。
canonical。
OGP。
見出し。
画像alt。
内部リンク。
外部リンク。
出典の確度。
公開してはいけない情報。
taupeらしい言い回し。

これを毎回プロンプトで書くと、どうしても漏れる。
しかも、漏れたことに気づきにくい。

プロンプトは、その場の会話です。
skillは、手順の置き場です。

この違いが大きい。

プロンプトをうまく書くことより、繰り返す作業を固定して、後から直せる形にする。
AI運用は、そこに移っていくと思っています。

CodexやClaude Codeが「skill」を重視し始めている

OpenAIのCodex docsでは、skillsは再利用できるworkflowを書くための形式として説明されています。
SKILL.md を中心に、必要なら scripts/、references/、assets/ などを持てる。

面白いのは、全部を最初から読み込むわけではないところです。
Codexは、まずskillの名前、説明、ファイルパスだけを見る。
必要だと判断したときに、SKILL.md の中身を読む。

つまり、毎回すべての長い手順をプロンプトに貼るのではなく、必要なときに必要な手順を呼び出す設計になっている。

Claude CodeのSkillsも近い考え方です。
SKILL.md に主要な手順を書き、必要に応じてテンプレート、サンプル、スクリプト、詳細な参考資料を持たせられる。
Claude Codeの仕様そのものをCodexにそのまま当てはめるわけではありませんが、方向性としてはかなり近い。

AIに「毎回説明する」のではなく、AIが「作業に合った手順を取りに行く」。

ここが変化です。

OpenAIは、Codexを開発者だけでなく、分析、マーケティング、営業、クリエイティブなどの知識作業にも広げようとしている。
さらにOna買収の発表では、Codexが長時間作業し、安全で永続的な作業環境を持つ方向も示されています。

そうなると、ますます大事になるのは、いい感じの一発プロンプトではない。
作業ごとの手順。
確認条件。
禁止事項。
人間が承認する境界。
失敗したときの戻し方。

つまり、skill化です。

実験: ブログ運用の公開前チェックと出典確認をskillにした

今回、実際にいくつかskillを作りました。

ひとつは、出典確認のための source-check。
もうひとつは、AIウォッチをtaupeの記事候補に変換する taupe-ai-article-seed。
さらに、ブログ公開前チェック、公開後同期、内部リンク差し込み、公開後観測のskillも作っています。

やっていることは、派手ではありません。

出典確認では、リンクをこう分ける。

公式発表
一次情報
コミュニティ上の反応
二次記事
弱い情報

そして、記事で使えるかも分ける。

そのまま使える
文脈付きなら使える
追加確認が必要
使わない方がいい

これを毎回プロンプトに書くのではなく、skillにしました。

taupeの記事候補化も同じです。
AIニュースをそのまま紹介するのではなく、こう見る。

読者にとって何が変わるのか。
自分が実際に試せるのか。
読者が真似できる小さな実験になるのか。
出典は十分か。
内部情報を出しすぎていないか。

この判断基準をskillに入れておく。

すると、AIウォッチのあとに「この記事にできそうなものを出して」と頼むだけで、ニュース紹介ではなく、taupe向けの実践記事候補に変換しやすくなります。

地味です。
でも、運用ではかなり効く。

skill化してよかった作業、まだ人間が見るべき作業

skill化してよかったのは、チェックリスト型の作業です。

公開前チェック。
出典確認。
公開後のHTML確認。
内部リンク候補の洗い出し。
記事候補の優先順位づけ。
7日、14日、28日で見る観測項目の整理。

こういう作業は、毎回ゼロから考える必要がありません。
むしろ、毎回ゼロから考えると漏れます。

skillにすると、見る順番が固定される。
出力形式も揃う。
前回の反省を、次回の手順に足せる。

これは大きい。

一方で、skill化しない方がいいものもあります。

公開するかどうか。
どの言い回しを残すか。
出典が弱いけれど、どこまで書くか。
セキュリティ的に踏み込んでよいか。
外部投稿やインデックス登録を実行するか。

このあたりは、人間の判断を残した方がいい。

OpenAI CookbookのAgent Improvement Loopでも、traces、feedback、evalsを使って改善する流れが紹介されています。
ただし、完全自動にするか、人間が承認する形にするかは開発者側の判断として扱われている。

僕のブログ運用でも同じです。

AIには、確認、整理、候補出し、差分確認を任せる。
でも、公開、外部送信、セキュリティ判断、最終的な文体の決定は人間が見る。

skill化は、AIに丸投げするためではない。
人間が見るべき場所を残すために、繰り返し作業を片づけるものです。

小さく始めるなら、まずチェックリストをskillにする

いきなり大きな自動化を作る必要はありません。

最初にskill化しやすいのは、チェックリストです。

たとえば、記事公開前チェックなら、最初はこれくらいでいい。

name: blog-publication-check
description: ブログ記事の公開前に、title、description、見出し、画像alt、内部リンク、出典、公開してはいけない情報を確認する

手順:
1. titleとdescriptionが記事内容と合っているか見る
2. H2の流れが読者に伝わるか見る
3. 画像altが空欄になっていないか見る
4. 内部リンクが1〜2件あるか見る
5. 出典が公式・一次情報中心か見る
6. 機密値、アカウント固有情報、内部管理情報を出していないか見る
7. 今すぐ直す点、後でよい点、直さなくてよい点に分けて返す

この程度でも、毎回のプロンプトよりは安定します。

次に、必要なら参考ファイルを分ける。
出力テンプレートを足す。
チェック用スクリプトを足す。
実際に使って漏れた項目を追加する。

skillは、最初から完成品にしなくていい。
むしろ、使いながら育てる方が自然です。

僕の場合も、最初から全部を作ったわけではありません。

公開確認で漏れたこと。
出典確認で迷ったこと。
AI記事候補化でニュース紹介っぽくなりすぎたこと。
公開後のdocs同期で毎回同じ確認をしていたこと。

そのたびに、手順をskillへ移していった。

プロンプトを磨くのではなく、作業そのものを少しずつ部品化していく。
この感覚です。