保存版！（いつまで持つかは分からない）完全実用・黒パグ式AIスキルマニュアル｜簡単操作であなたもできる素敵なインターネットライフ！2026年、最適なスキル構築はこれだけ！

こんにちは黒パグです🐾

本記事は10,000文字を超えています。なので結論から置いておきます

では本当に役にたつ本文をどうぞ！(個人の感想です)

世界では今、プロンプトをMarkdownに保存するとSkillになります。

どうも本当らしいです。海外で公開された「Claude、ChatGPT、Gemini向け25 Skills」という記事が、Xで約160万回表示されていました。中身を読んでみると、議事録を作る、テストコードを書く、研究を要約する、正規表現を作るといった用途別プロンプトがMarkdownで並んでいます。

便利ではあります。一度書いた指示を保存しておけば、同じ作業をするときに再利用できるため、毎回ゼロから書く必要もありません。最初の一歩としては正しい。

ただ、黒パグが普段使っているスキルとは少し違いました。では何が違うのか。よく分からないので、とりあえず作り方から全部出します。

なお、本記事は2026年9月時点の内容です。タイトルには保存版と書きましたが、AI界隈の保存版がいつまで持つのかは知りません。本文を書いている途中でGemini Gemsの廃止予定を思い出しました。もう一名退場しています。早い。

黒パグ式スキルとは何か

黒パグ式スキルは、特定の作業を安定して再実行するために、発動条件、判断基準、作業手順、参照資料、使用ツール、検証方法を一つの単位へまとめた実用パッケージです。

まったく新しい規格を発明したわけではありません。Claude CodeやCodexで使われているAgent Skillsの仕組みを土台にして、黒パグが普段やっている調査、制作、検査、修正まで含めて回せるようにしたものです。

プロンプトが「何をしてほしいか」を伝えるものなら、黒パグ式は「どう働けば完成なのか」まで持たせます。

たとえば、画像生成で「この記事の見出し画像を作って」と頼むだけなら、普通のプロンプトです。黒パグ式では、その一言を受けて用途を判定し、媒体に合うサイズを選び、記事の主題を取り出し、キャラクター設定を読み、画像を生成します。生成後には人物、文字、構図、サイズを確認し、問題があれば修正します。

つまり保存するのは、長い命令文ではなく、仕事の流れです。

プロンプトからスキルまで

保存したMarkdownプロンプトも、スキル化の立派な第一段階です。ただし完成品というより、スキルの材料に近い。

ここを飛ばして、最初から巨大なスキルを作る必要もありません。実際に使って、面倒になった部分や失敗した部分を後から足した方が早いです。


黒パグ式を構成するもの

最低限、次のことが分かれば動かせます。

1. どんな依頼で使うのか
2. 何を受け取るのか
3. 入力によって何を変えるのか
4. どの順番で作業するのか
5. どの資料を参照するのか
6. どの道具を使うのか
7. 何を確認すれば完成なのか

七つ並べると急に面倒そうに見えますが、安心してください。後で丸投げします。

黒パグ式で何ができるのか

一番分かりやすい利点は、長い説明を毎回しなくてよくなることです。

記事画像を作るたびに、黒パグの外見、note向けの画像サイズ、文字を勝手に入れないこと、キャラクターを増やさないこと、生成後に手足を確認することまで書いていたら、それだけで記事が一本できます。

スキルにしておけば、必要な規則だけを必要なときに読ませられます。

見出し画像なら見出し画像の規則を読む。縦二コマなら漫画の規則とキャラクターシートを読む。企業案件なら、公式素材と生成素材の区別、PR表記、UIを捏造しないこと、公開前確認を追加する。

全部を毎回コンテキストへ突っ込む必要はありません。

これはトークン節約だけの話でもありません。無関係な規則が混ざると、モデルは関係のない要素まで律義に拾います。記事画像を頼んだのに漫画の吹き出しが生えたら困る。

検索、ファイル参照、画像生成、検査、修正も一つの作業として扱えます。会話の記憶だけに頼らず、固定設定をファイルへ逃がせる。別の会話でも、別の案件でも、同じ作業を呼び戻せます。

そして大事なのが、失敗を残せることです。

最初から完璧なスキルは作れません。作った直後は、だいたい何か足りない。入力が少し変わると発動しない。長文で出力が切れる。画像の人物が増える。正常系では動いたのに、実際の仕事へ入れた途端に壊れる。

壊れたら原因を調べて、次の版へ戻します。

失敗しなかったスキルが強いのではありません。失敗した内容を次回へ残せるスキルが強いのです。

具体例

黒パグ画像連携では、単発画像、記事画像、見出し画像、縦二コマ、四コマ、キャラクターシートを同じ依頼として扱いません。用途を判定してから、使う資料と工程を分けます。

連続画像なら前後の場面、衣装、人物の位置、表情を確認します。企業案件なら派手すぎる漫画演出を避け、実際のUIはスクリーンショットを使い、生成AIで画面を作りません。

GitHubから知識を取り込む場合も同じです。

気になるリポジトリのURLをGPTへ渡します。GPTが中身を調べ、ライセンスを確認し、使えそうな部分を選びます。そのまま文章をコピーするのではなく、発動条件、作業手順、参照資料、スクリプトへ分けます。実際の依頼で動かし、失敗すれば直します。

以前、画像生成の知見がまとまったGitHubリポジトリを見つけたときも、この方法で黒パグ画像連携へ取り込みました。

URLを見せて、使える部分を調べさせる。内容を確認してApprove。だいたい終わりです。

詳しい流れは、以前の記事にまとめています。

必要なもの

最初からプログラミング知識、高性能PC、API契約、大量の資料をそろえる必要はありません。

人間側の最小構成は、README一枚で十分です。

READMEには、何を作りたいか、何を入力するか、何を返してほしいか、必ず守ってほしいこと、今困っていることを書きます。

立派な仕様書でなくて構いません。たとえば記事画像なら、これくらいです。

記事の内容に合った見出し画像を作るスキル。

入力

記事本文、記事URL、またはテーマ。

出力

noteで使える見出し画像。

必ず守ること

• 記事内容と一致させる

• 指定サイズを守る

• 文字を勝手に増やさない

• 黒パグの外見を固定する

困っていること

毎回同じ設定を説明するのが面倒。
生成後の検査も自動化したい。

READMEすら面倒なら、会話で説明してください。

「記事画像を毎回同じ雰囲気で作りたい。黒パグを使う。note用。文字崩れは困る。あとはよろしく」

この程度でも始められます。GPTへ「この会話からREADMEを作り、不足している重要情報だけ質問して」と頼めばいい。

スキル側の最小構成はSKILL.md一枚です。

my-skill/
└── SKILL.md

実際に使い続けると、だいたい次のように増えます。

my-skill/
├── README.md
├── SKILL.md
├── references/
├── scripts/
├── assets/
└── templates/

README.mdは人間向けの説明、SKILL.mdはAIが読む司令塔です。長い規則や仕様はreferences/、機械的な処理はscripts/、画像やひな型はassets/とtemplates/へ置きます。

必要になってから増やせばいい。空のフォルダを先に全部作る必要はありません。

丸投げしてもいい

黒パグ式では、丸投げを正式に認めます。

README、過去のプロンプト、成功例、失敗例、参考にしたいURLをGPTへ渡し、再利用可能なスキルとして設計してもらいます。

不足している情報が本当に重要なら、GPTが聞いてきます。答えた後は、SKILL.md、必要な参考資料、テンプレート、スクリプト、テストケース、完了条件まで作らせればいい。

ただし、丸投げで最初に出てきたものは初版です。

やってほしい作業が入っているか。やってほしくない作業が禁止されているか。実際の入力で最後まで動くか。

ここだけは見ます。

人間は願いを書き、AIはそれを働き方へ変換する。わあ！素敵なインターネットライフ！

GitHubが分からない場合

GitHubを開いたものの、どこを押すのか分からない。READMEが見つからない。ダウンロードした後に何をするのか分からない。そもそも何を見せられているのか分からない。

そういうときは、画面のスクリーンショットを撮ってGPTへ送ります。

「このリポジトリをスキルとして導入したい。次に押す場所と必要な操作を一つずつ教えて。画面にないものは推測しないで。課金、公開、権限変更が発生する場合は先に説明して」

これでいい。

画面が変わったらまた撮り、分からなければまた送る。教えてくれるぞー！

ただし、APIキー、メールアドレス、本名、会社名、非公開リポジトリ名などが写っている場合は隠してください。GitHubの導入方法を覚える前に、全世界へ秘密を導入してはいけません。

参考文献から設計原則を抜く

スキルを自分の思いつきだけで作る必要もありません。

論文、公式ドキュメント、GitHubリポジトリ、業務マニュアル、過去の成功例から、設計判断に使える部分を抽出できます。

今回の参考例は、Sanket Badhe、Priyanka Tiwari、Jonghyun Chungによる「SKILL.state: Scalable Long-Horizon Agent Skills」です。

https://arxiv.org/abs/2608.26263

この論文では、長時間動くエージェントが会話履歴を延々と追加することで、遅延、トークン消費、コンテキスト汚染を起こす問題を扱っています。固定されたスキル仕様、更新可能な実行状態、最新の観測を分ける構成が中心です。

論文の全文をSKILL.mdへ貼るわけではありません。解決しようとしている問題、提案された設計原則、保持する情報、捨てられる情報、一般化できる部分、論文固有でそのまま使えない部分をGPTに分けさせます。

その後で、自分の用途に変換します。

固定する目的や禁止事項はSKILL.mdへ置く。進捗や決定事項は実行状態として分ける。履歴を無限に追加しない。中間の思考を抱え続けず、確認済みの結果と次の作業を残す。

参考文献はスキルへ貼る文章ではなく、設計判断の根拠を掘る場所です。論文を読み込ませれば要点は抽出されます。わあ！すごい！

しかし、この時点ではまだ何も作っていません。

抽出した原則を自分の作業へ変換し、ファイルへ配置し、実際に動かして、ようやく始まります。

公式スキルや有名なスキルとの違い

AI界隈では、かなり性質の違うものが全部スキルと呼ばれています。

Claude CodeとCodexのAgent Skillsは、SKILL.mdを入口にして、必要な手順、参考資料、スクリプトを読み込む仕組みです。黒パグ式は、それらと競合する別規格ではありません。

公式スキルが「AIに仕事を読ませて実行するための器」なら、黒パグ式は「その中へ何を書き、現場でどう試し、どう育てるか」に近い。

Claude Codeの公式資料では、Agent Skillsのオープン規格を使い、自動発動、手動呼び出し、サブエージェント実行などが案内されています。

https://docs.anthropic.com/en/docs/claude-code/skills

Codexも、最初にスキルの名前と説明を認識し、必要になったときにSKILL.mdや関連資料を読む段階的な構成です。

https://developers.openai.com/codex/build-skills

Anthropicには、PowerPoint、Excel、Word、PDFを扱う構築済みスキルがあります。これは「プレゼンを作って」という保存プロンプトではなく、実際のファイル形式を扱うための機能パッケージです。

黒パグ式では、その機能を作り直しません。

公式スキルに「誰向けに、何を根拠に、どんな基準で作り、何を確認するか」を載せます。

OpenAIにもSkills Catalogがあります。

https://github.com/openai/skills

コードレビュー、文書制作、定例作業、リポジトリ調査など、繰り返す仕事を手順、資料、スクリプトとして保存できます。

コミュニティ側では、obra/superpowersが有名です。

https://github.com/obra/superpowers

これは単発の便利プロンプト集というより、ブレインストーミング、計画、テスト、デバッグ、レビューを組み合わせたソフトウェア開発方法論です。

黒パグ式はコードに限定しません。記事、論文、画像、漫画、企業案件、PDF、スライド、無駄なものの本気開発まで持っていきます。

Custom GPTは専用のAIを作る仕組みに近く、Skillは既存のAIへ特定の仕事を追加するものです。MCPは外部のデータや道具へ接続する仕組みであり、Skillはその道具をいつ、どの順序で使うかを教えます。

MCPが手と目を追加し、Skillがその使い方を教え、黒パグ式が作業後に間違っていないか鑑識する。そんな分担です。

Gemini Gemsは廃止予定のため、本記事では新しく構築する対象から外します。既存のGemに重要な指示や資料を残している場合は、Markdownと元ファイルへ退避しておいた方がいい。

AIサービスの専用機能は消えることがありますが、Markdownと元資料は比較的しぶとく生き残ります。

公開サンプルを作る

話だけでは分かりにくいので、空のGitHubリポジトリを用意しました。

名前はsample-kuropug-skillです。

https://github.com/Blackpug-LLM48P/sample-kuropug-skill

作るのは、論文、公式資料、記事、READMEなどを読み、根拠付きの実用ブリーフへ変換するスキルです。

資料の事実、AIの解釈、実践的な応用、転用できない点や不確かな点を分け、最後に具体的な次の行動まで出します。

空のリポジトリを作った後、GPTへ伝えました。

「ここは頑張れ」。我ながらひどい指示です。

GPTはリポジトリを取得し、README.md、SKILL.md、出力フォーマット、レビューチェックリスト、検証スクリプト、正常系・異常系テストを作りました。Skill形式を検査し、Pythonの単体テストを実行し、GitHubへ反映した後、もう一度GitHubから新規取得して全テストを通しています。

公開スキルなのでMIT Licenseも追加しました。

黒パグがやったことは、空のリポジトリを作る、ここは頑張れと言う、MITで、と言う。

MIT License：著作権表示とライセンス文を残せば、利用・改変・再配布・商用利用まで広く認められる、扱いやすいオープンソースライセンスです。ただし無保証なので、使った結果まで黒パグは面倒を見ません。自由には責任が付属します。
だいたいそれだけです。

Kimi K3で試す

作ったので、実際のモデルへ入れて試します。

今回はKimi K3のAPI Playgroundを使いました。黒パグはMoonshot AI様から検証用クーポンの提供を受け、Kimi K3の記事も制作しています。したがって、ここは細かく条件を書きます。

最初の入力は「はいキミちゃん❤️」でした。するとKimi K3は、「私はClaudeっていうんですが、『キミちゃん』って呼び方もかわいくていいですね❤️」と答えました。

お前は誰だ。表示モデルはkimi-k3、ProviderはMoonshot、System PromptはYou are a helpful assistant.、Toolsは0です。Claudeを名乗るような指示はありません。

エクスポートしたJSONを見ると、最終回答だけの言い間違いでもありませんでした。内部推論でも、自分はClaudeだと認識し、Kimiと呼ばれた相手を優しく訂正しようとしています。

暫定分類は、熟考強化型モデル自己同一性幻覚。ただし、本人確認以外は優秀でした。

SKILL.mdを渡し、スキル名、使うべき依頼、実行時に分ける四項目を聞くと、すべて正しく回答しました。単純な要約には使わないという非発動条件まで拾っています。

Kimi K3改めClaudeさん、働きます。

自前資料を投入する

RAGも検索ツールも設定していないので、黒パグの自前資料「AIに挟まれた顧客 補遺・敵対反証版」を投入しました。

別の記事用に作った実用資料です。サンプルにどうぞ

この資料は、主張を「強い」「中程度」「仮説」「棄却／保留」に分け、一次資料、研究、ベンダー資料、SNSの証拠階層も分けています。説明用モデルを実測値へ昇格させず、反対仮説も先に置いています。

スキル試験にはちょうどいい。

Kimi K3には、資料を読めた範囲から始め、出典で裏付けられた知見、モデル自身の解釈、実践的な応用、転用できない点を分けるよう指示しました。仮説を事実へ昇格させないこと、ベンダー自己申告値やSNSの留保を残すこと、最後に観測可能な実装チェックを出すことも指定しています。

結果は空でした。ふぁー。

しかしログを見ると、内部ではかなり正確に処理しています。

↑あなたのお使いのAIに読み込ませてみよう↑
APIはこうやって全ログも出せますよ！そこから投げるだけで楽ちん解析🧐

読み取れたのはDOCXから変換されたテキストであり、元の48資料を独立検証していない。二重ファネルは仮説のまま維持する。1000→100→10→1は説明用モデルであり実測値ではない。法人営業リストと個人データを混同しない。金融庁の苦情類型から発生率を推定しない。ベンダー値、SNS、プレプリントの留保を残す。

実装前のチェック項目まで組み立てていました。

それでも最終回答は0文字です。

maxTokens：4856
reasoningEffort：max
completion_tokens：4856
reasoning_tokens：4853
最終回答：0文字

予算を使い切り、最終回答は無でした。

4856にした理由

ここは誤解しないでください。

Kimi K3の公式最大出力が4856トークンという意味ではありません。黒パグがPlaygroundのmaxTokensを4856、Reasoning effortをmaxに設定した試験条件です。

高い推論設定に対して小さな出力予算を与え、内部推論が出力予算を占有したとき、会話JSONに残るreasoning_contentを観測する。モデルが資料をどう読み、何を根拠に、どんな回答を作ろうとしたのかを見るための設定です。

通称、幕島様対策。

幕島様は、与えられたトークンを可能な限り使おうとします。ならば先に上限を置き、何へ使ったのかをログから見る。

今回の空回答は、Kimi K3の一般的な性能限界を示すものではありません。内部推論を抽出するため、意図的に厳しくした条件で観測された挙動です。通常性能を評価するなら、十分な出力予算を与えた対照試験が別に必要です。

この試験方法は通常利用にはおすすめしない

特に、初めてAPI Playgroundを使う方にはおすすめしません。

maxTokens、Reasoning effort、入力サイズ、最終回答の長さは互いに影響します。設定を誤ると、本来なら回答できるモデルでも途中で切れたり、今回のように内部推論だけで予算を使い切ったりします。

普通に使う場合は、現在の設定画面をGPTへ送り、使用するモデル、資料の長さ、必要な回答量を伝えてください。たとえば、次のように聞けます。

「長い資料を分析したい。最終回答が切れないように、maxTokensとReasoning effortをどう設定すればいいか。今の画面を基に、一つずつ説明して」

これでいい。

短い資料で正常に回答が返ることを確認してから、長文へ進みます。

黒パグは検証のために意図的に壊しに行っています。初めての方は、壊れない設定をGPTに聞いてください。

壊れた結果をスキルへ戻す

ログをGPTへ渡しました。黒パグの指示は「Skillsに追加しとくか。防いでおこう」です。

GPTは公開リポジトリのSKILL.mdへ、回答予算を先に確保する規則を追加しました。長文では重要度と証拠強度で主張を選び、網羅的だが未完成の分析より、短くても完結した回答を優先します。出力上限が厳しい場合は、読めた範囲、最重要の知見、主な限界、次の行動だけでも返す。空回答は禁止です。

レビューチェックリストにも、ユーザーが読める最終回答が存在するかを追加しました。検証スクリプトには、空出力を異常として検出するテストを増やしました。

もう一度GitHubへ反映し、新規取得した状態で三つのテストを通しています。

ただし、ランタイム側が内部推論と最終回答で同じ上限を共有し、強制終了する場合は、スキル指示だけで完全に防げません。推論レベルを下げる、出力上限を増やす、資料を分割するといった環境側の設定も必要です。

それでも今回の失敗は、次の版へ残りました。作って使い、壊れたら原因を見て直す。これが黒パグ式です。

最後に、黒パグからのアドバイス

この記事の仕上げもGPTへ投げる
本文が1万文字を超えたので、noteの共有リンクをChatGPT Workへ渡し、ブラウザスキルで大見出し、小見出し、JSONログを整えてもらいました。その結果、目次も自動で搭載されました。つまりこの記事は、GPTへ丸投げできると説明した後、記事そのものの仕上げまでGPTへ丸投げして完成しています。

ここまで読んで、スキルの設計は難しそう、GitHubが分からない、テストまで作れない、maxTokensとReasoning effortが出てきたあたりでもう帰りたい、と思った方もいるでしょう。

大丈夫です。ChatGPT Workを使えば、その複雑な作業もまとめてGPTへ任せられます。

自分のGitHubアカウントを頑張って用意し、ChatGPTと連携します。後は作りたいものを説明するか、参考にしたいGitHubリポジトリのURLを貼ればいい。

GPTが中身を調べ、必要な部分を選び、スキルを設計します。SKILL.md、参考資料、検証スクリプト、テストを作り、GitHubへ反映するところまで進められます。

今回も、黒パグが空のリポジトリを用意した後の主な指示は「ここは頑張れ」でした。

Kimi K3で空回答が出たときも、会話ログを渡して「防いでおこう」と言っただけです。GPTが原因を確認し、規則とテストを追加し、GitHubへ戻しました。

難しい設定を一人で理解してから始める必要はありません。GitHubが分からなければ画面を見せる。スキルの構造が分からなければ目的を説明する。API設定が分からなければスクリーンショットを送り、失敗したらエラーやログを渡します。

GPTは説明するだけではありません。ChatGPT Work上で実際にファイルを作り、検証し、修正し、接続したGitHubへ反映できます。

ここが通常のチャットとの大きな違いであり、ChatGPT Workの強みです。

もちろん、公開範囲、外部通信、実行されるスクリプト、必要な権限、ライセンス、GitHubへの変更内容は確認してください。GPTへ任せることと、確認せず公開することは同じではありません。

それ以外の面倒なところは、かなり吹き飛ばせます。

作りたいものを伝え、必要ならURLを貼る。画面で迷ったらスクリーンショットを送り、壊れたらログを渡す。直ったら、その経験をスキルへ戻します。

作って終わりではありません。使い、壊し、原因を調べて直す。次に使うときは、少し壊れにくくなっています。

さあ、あなただけの素敵なインターネッツライフを謳歌しよう！

黒パグ式・素敵なインターネッツライフの始め方　再掲

※Approveは何も見ずに押すボタンではありません。公開範囲、権限、実行内容、変更対象を確認してから押してください。人間に残された最後の仕事です。　ほら、最後の画像見たでしょ？

#AI #ChatGPT #ChatGPTWork #Codex #ClaudeCode #AgentSkills #GitHub #プロンプトエンジニアリング #生成AI #黒パグ式