Skill on 向叔の手帳

AIがブログを書くという件、結局は工学的なものにする必要がある（1）

Fri, 03 Apr 2026 20:58:02 +0800

昨年、多くの AI に関する記事を書きました。あの頃の最も手間のかかるプロセスは、まず自分でアウトラインや問題リストを整理し、大規模言語モデルに本文を出力させてもらい、その後その内容をローカルの md ドキュメントにコピー＆ペーストし、フロントマター、タグ、カテゴリ、タイトルなどを補完してから公開するというものでした。このプロセスが使えないわけではありませんが、非常に面倒です。本当に時間がかかるのは本文ではなく、本文の外側の繰り返しの作業です。特に最近 Codex を使いすぎてからは、その不自然さがより強く感じられます。それはリポジトリを読み込めるし、ファイルを編集でき、資料を補完できるだけでなく、記事を直接ディレクトリに書き込むこともできます。もし私がまだ手動でコピー＆ペーストを繰り返していると、まるで人間がツールの足を縛っているような気分になります。

この一連の記事は、実は一つのことを伝えたいのです。AI によるブログ執筆は、単なるプロンプト一つに頼るだけでは限界が来ています。今回の記事ではまず blog-writer がなぜ生まれてきたのかを説明します。次の記事では AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（2）：blog-style-suite でスタイル学習とトークンコストをどう分離するかを続けます。そして最終回は AIによるブログ執筆という事柄は、結局エンジニアリングとしてやる必要がある（3）：ローカルモデル、オンラインモデル、Minimax は最後にどう分業するかで締めくくります。

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

初期のワークフローは、端的に言えば外部委託されたパイプラインのようだった。私自身がまず問題を明確にするか、あるいは大まかなアウトラインを立てる。モデルが本文を骨子として展開する。その後、人間が戻ってきて残りの公開作業を補完する。

ローカルの md にコピーする
title、date、slug を補完する
タグとカテゴリを入力する
 を補完する
参考資料を整理する
どのディレクトリに配置するかを決定するこの一連の作業は、一つ一つのステップを見れば難しくはないが、繋げると非常に面倒だ。面倒なのは技術的な難しさではなく、それらがすべて機械的であるにもかかわらず、やらざるを得ない点にある。だからこそ、私は後になって、「[コマンドラインベースのAIコーディングインタラクション](/ja/p/command-line-ai-coding-interaction/）」のような変化は、単に「入り口が変わった」だけではないと感じるようになった。AIがリポジトリ内で直接ファイルの読み書きができるようになった今、ブログ執筆がまだ「本文をローカルドキュメントにコピーする」レベルに留まっているとしたら、ワークフロー全体がすでに時代遅れになっているのだ。

blog-writer 最初の価値は文体ではなく、契約を固定化すること

blog-writer の最も初期のノードは、2026年4月1日17:00の 991536a です。gitコミット履歴を見ると、このバージョンではすでに SKILL.md、write_post.py、そして一連の初期のスタイル資料が組み込まれています。

しかし、後から振り返ってみると、このドラフトの最も価値のある点は「AI が私の文体を学んだ」ことではなく、執筆の契約を固定化したことです。

「契約を固定化する」とはどういうことか？

入力には最低限、アウトラインとファクトアンカー（事実の錨点）が必要であること
出力は必ず完全なMarkdown形式であり、未完成品であってはならないこと
frontmatter は人手に頼ることはできないこと
記事はチャットウィンドウ内に留まるのではなく、直接 content/post に配置されること

この点は非常に重要です。なぜなら、プロンプト自体が不安定だからです。「以前のように書いて」と今日言っても、それはトーンが少し似ていると解釈されるかもしれません。明日もう一度同じことを言っても、表面的な構文しか学べないかもしれません。しかし、それが Skill として書かれると、ルールは「その場での即興」から「固定された工程」へと変わります。

後続のいくつかのノードも、実質的にこの契約を補強し続けています。

2026年4月2日22:54の 8eb735a では、著者フィールド、執筆に関する注記、元のプロンプトなどが固定されました。この段階に至ると、ブログ記事の完成は単に「本文が書き終われば完了」ではなくなり、メタ情報、トレーサビリティ（追跡可能性）、公開される注記までが標準化されたのです。

したがって、blog-writer の最初の価値は、モデルをより文章を書くのが上手に見せかけることではなく、執筆という行為自体に、再現可能な境界線を持たせたことなのです。

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

単発の記事で安定して書けるようになると、次の問題がすぐに浮上します。あるテーマは、そもそも一つの記事に詰め込むのが適していません。無理に詰め込もうとすると、結局は情報量が多すぎてメインの筋が散漫になり、どの点も深く掘り下げきれない長文になってしまいがちです。これが、2026年4月2日 23:55 の 1a5604e が重要だった理由です。あの時、シリーズ形式と write_post_series.py をまとめて追加しました。記事間は relref で繋ぎ、一括書き込みの際に統一的に置換するようにしたのです。これは単なるファイル生成スクリプトの小さなアップグレードに見えますが、実際はそうではありません。それは一つのことを示しています。執筆の工程化は、「この一篇をどう生成するか」だけを考える段階から、「この一連のコンテンツをどう安定して配置し、順序をどう保証し、サイト内で相互にリンクさせるか」という視点に移ってきたということです。翌日の2026年4月3日 09:29 の 04dccb9 は、この件をさらに一歩進めました。シリーズ記事のタイムスタンプが分単位で増加し、もはや共通の時間を使用しないようにしたのです。この変更は非常に小さいものですが、エンジニアリング的な深みがあります。なぜなら、Hugoのリストページ、前後の記事リンク、シリーズの順序といった「実際の問題」を解決しているからです。端的に言えば、シリーズ形式というのは、格好良く見せるためではなく、「複数の記事をまとめて公開する」という作業が、もはや手動でのフォローアップに頼らなくて済むようにするためなのです。

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

問題はここにあります。文体学習を真剣に行い始めると、blog-writer のコンテキストがすぐに肥大化します。ただ書くだけでなく、以前あなたのように書くことも期待するわけです。最も自然な方法は、過去の記事も一気に詰め込むことです。これなら、一度だけは実行できます。しかし、たまに記事を書くだけではなく、長期的なワークフローにしたいと思うと、すぐに問題が発生します：

トークン消費量が高い
毎回同じ古い記事を繰り返し与えることになる
モデルの注意力が古い材料によって希釈される
原稿執筆とスタイル維持が絡み合い、どちらも容易ではないここから、私はblog-writerは、すべてを任せる側（生成側）というよりは、消費する側として使う方が適していることに気づき始めました。原稿執筆という動作は、できるだけ軽く、直接的に、そしてできれば公開されたバージョンのみを参照するようにすべきです。一方、スタイルデータの生成方法、選別方法、圧縮方法は、別の生産側のパイプラインの問題なのです。この判断が、私を次のステップへと導き、それがAIでブログを書くという件は、結局エンジニアリングにする必要がある（2）：blog-style-suiteでスタイル学習とトークンコストをどう分離するかへと繋がりました。

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

今振り返ると、blog-writer が生まれたのは、私が突然ブログライティングアシスタントを作りたいと思ったからではない。むしろ、これまでのワークフロー自体が、新しい働き方に合わなくなってきたことが原因だ。 Codex のようなツールがインターネットに接続して資料を補完できたり、リポジトリ内での読み書きができたり、スクリプトを直接呼び出せるようになった場合、「ブログを書く」という行為は「本文をローカルドキュメントにコピーする」という段階で止まっているべきではない。この部分を自動化しなければ、かえって全体のプロセスの中で最も非効率な工程になってしまう。そのため、最初の記事の結論はここまでとする。 blog-writer が最初に解決したのは、文体ではなく、公開作業における反復的な手作業だった。このレイヤー（層）という契約がなければ、後からトークンやデータ構造、ローカルモデルについて語っても、実際には根拠がない。

参考資料

リポジトリコミット：991536a237d04aba7c44dec501b3d98c644040c8
リポジトリコミット：8eb735aa8448c97deb2af1ea46b86772008fa9e3
リポジトリコミット：1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892
リポジトリコミット：04dccb98c55a6ea3b81408012b33a6219cf8ab77
リポジトリファイル：.agents/skills/blog-writer/SKILL.md
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post.py
リポジトリファイル：.agents/skills/blog-writer/scripts/write_post_series.py

作成上の注記

元のプロンプト

$blog-writer 今回の内容は多いため、シリーズ記事に分割しました。昨年も多くの原稿が大規模言語モデルによって書かれました。その時は、自分でアウトラインや質問リストを作成し、AIに原稿を生成させ、内容をローカルのmdドキュメントにコピーし、ヘッダー情報、タグ情報などを記入して投稿するという流れでした。最近はCodexを多く使用し、Codexのインターネット検索能力が非常に強力だと気づきました。そこで、これらの作業を自動化するスキルを作成できないかと考えたのが、skill blog-writer の初稿です。さらに、AIに以前の記事のスタイルを学習させたいと考えたため、blog-writerの実行時にトークンを大量に消費するという問題が発生しました。その後、私はblog-writerに対して複数のバージョンの最適化を行いました。データモジュールとデータ生成モジュールに分割したのですが、元々のデータ生成モジュールは独立したスキルでした。書き進めるうちに、Pythonプロジェクトとしてまとめた方がより適していることに気づき、それが blog-style-suite の誕生につながりました。さらに、スタイルデータの学習もトークンを消費することが多いと感じたため、ローカルの大規模言語モデルを使用することにしました。ローカルの大規模言語モデルとオンライン版の違いを比較したいと考え、minimaxとも連携させました。blog-style-suite と blog-writer の進化の歴史は、gitのコミット履歴から分析できます。ついでに、ローカルの blog-writer および blog-style-suite のコードを基にして、設計思想や、どのようにトークン節約を実現したか、データ構造はどう設計したか、といった核となる設計思想について説明することができます。トークンが潤沢であれば過去の記事を丸ごと処理できますし、前処理を行うことで多くのトークンを節約できます。

ライティングのアイデア概要

最初の記事はワークフローのトリガーポイントに焦点を当て、トークンとモデルの役割分担を急ぎすぎず、3つの記事でメインテーマを奪い合うのを避ける。
「本文自体は難しくないが、公開前後の一連の機械的な作業が面倒である」という判断を重点的に残した。
991536a、8eb735a、1a5604e、04dccb9 などのノードを通じて、「プロセスを契約化する」ことを実際のGitの進化に落とし込む。
シリーズ形式はこの記事で取り上げることで、ブログ執筆が単発の記事生成から一連の成果物（セット）へと移行したことを示すためである。
最後に意図的に問題をトークンウォールに引きつけ、次の記事でのデータエンジニアリングと前処理のための布石とする。

Skill は新しいプロンプトではなく、エージェントに職種マニュアルを提供するものです。

Thu, 02 Apr 2026 22:43:16 +0800

この数日、AIプログラミングについて見てきましたが、さっきまでみんながMCPの話をしていて、次の瞬間にはまたSkillの話をしています。この言葉を初めて目にする人は、本能的にこれをまた新しいプロトコルか、あるいは高度なプロンプトだと捉えがちです。

私の判断は非常にシンプルで、SkillはMCPの座を奪いに来たものではなく、むしろエージェントに職種マニュアルのようなものを提供している感じです。MCPが解決するのは「エージェントが外部世界と接続できるか」という点であり、Skillが解決するのは「接続した後、どのような手順で確実にタスクを遂行するか」という点です。これらは代替関係ではなく、むしろ前後関係に近いです。

端的に言えば、MCPはエージェントに手足を与え、Skillはエージェントが勝手に動かないようにするためのものです。

Skill とは一体何なのか

最も分かりやすい言葉で説明するなら、こう言います。ベテラン社員の頭の中にある熟練したやり方を、再利用可能で、トリガーでき、実際に実行できるマニュアルとしてまとめたものが Skill です。

OpenAI の公式ドキュメントの定義も非常に直接的です。Skill は特定のタスクに向けた能力パッケージの一種であり、指示（プロンプト）、参考資料、そしてオプションのスクリプトを格納できます。目的はモデルを「より賢くする」ことではなく、ある種のタスクにおいて固定されたワークフローに従って安定的に出力をさせることです。

何に最も近いか？

通常のプロンプトとは異なり、一度話して終わりではないからです。
MCP とも異なります。なぜなら、ツールやデータソースを接続する責任を持たないからです。
また、AGENTS.md のようなものでもないからです。全リポジトリで通用するルールではないからです。

むしろ、専門の SOP（標準作業手順書）や、職種マニュアルのようなものです。

例えば：

GitHub PR のコメントを処理する場合：まずどのコメントを処理すべきかを確認し、次にユーザーにどのコメントを処理するか尋ね、コードを修正し、最後に結果をフィードバックする。
CI の失敗を調査する場合：まず GitHub Actions のログを取得し、次に失敗した部分を抽出して要約し、修復計画を立て、承認されてから作業に取り掛かる。
ブログ記事を書く場合：まず固定の文体でタイトルを生成し、次に事実情報を補完し、さらにフロントマター（メタデータ）を追加し、最後に公開する。

これらの事柄に共通しているのは、「モデルがどう回答すべきか知らない」ということではなく、「モデルのやり方が毎回異なり、逸脱しやすい」という点です。ここで Skill の価値が出てくるのです。

Skill と MCP、結局どこが違うのか

これは実際のワークフローに当てはめて見ないと分かりにくいので、単なる説明だけでは誤解を招きやすいです。

MCP はインターフェース層のようなものです。

公式における MCP の定義は、「AI アプリケーションを外部システムに接続するためのオープンスタンダード」です。ファイル、ローカルデータベース、検索エンジン、デザイン稿、サードパーティサービスなど、これらすべてを MCP を通じて取り込むことができます。つまり、これが解決しているのは「取り込み（コネクション）」の部分です。

一方、Skill はプロセス層のようなものです。

OpenAI の Agent Skills ドキュメントには明確に書かれていますが、Skill は再利用可能なワークフローを記述するためのフォーマットです。一つの Skill には最低限 SKILL.md が必要で、さらに scripts/、references/、assets/ を含めることができます。Codex はまずその name と description を読み込み、実際に使用する必要があると判断した場合にのみ、完全な説明をコンテキストにロードします。これが公式が言う「プログレッシブ・ディスクロージャー（段階的開示）」です。

したがって、両者の役割分担は非常に明確です。

MCP: 能力を取り込む（コネクションする）
Skill: 行う手順の順序を定める

非常に分かりやすい例で言うと、「Figma からコードへの変換」のような作業です。もしエージェントがデザイン稿自体を読み取れていない場合、まず補うべきなのは MCP です。しかし、すでにデザイン稿を読み取れるようになったのに、毎回バラバラにコーディングしてしまう（今日はコンポーネントから書き始め、明日はページ分割から始め、明後日にはビジュアルチェックを忘れる）という状況であれば、補うべきは Skill なのです。

スキルの開発方法

これは思ったほど重くありません。 OpenAIの公式推奨では、まず組み込みの$skill-creatorを使用し、トリガー条件、範囲、スクリプトが必要かどうかといった骨格部分を構築してもらうことです。デフォルトではinstruction-only（指示のみ）が優先されるため、焦ってスクリプトを書くのではなく、まずは説明を明確にすることが重要です。手動で記述する場合でも、最小限の構造は非常にシンプルです：

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

この中で真に必要なのはSKILL.mdだけです。そして、このファイルには最低限2つのメタデータが必要です：

---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---

私が考えるに、Skillを開発する上で最も重要なのは以下のステップです。

1. 「繰り返し現れるバイアス」を探す

すべてのタスクが Skill にする価値があるわけではありません。エージェントに単発で作業をさせるだけであれば、通常のプロンプトで十分です。真に Skill として抽出するのに適しているのは、通常以下のようなケースです：

同じことを何度も繰り返して指示している場合
エージェントには能力があるはずなのに、実行順序がいつも変わってしまう場合
間違いが発生する箇所が毎回似ている場合つまり、「能力不足」なのではなく、「手順（ノウハウ）が安定していない」ということです。

2. `description` をトリガー条件として記述し、宣伝文句にしないこと

このステップは非常に重要です。公式ドキュメントでは、Codex がどの Skill を暗黙的に呼び出すかについて、description に大きく依存すると強調しています。「これはとても便利なスキルだ」といった表現ではなく、「いつ使うべきか、いつ使ってはいけないか」を記述してください。例えば、gh-fix-ci の公式スキルの説明は非常に明確です：「ユーザーが GitHub PR チェックの失敗をデバッグまたは修正してほしい場合に使用する」というものです。重要なのは、ログを確認し、失敗の原因を要約し、修正計画を提示することであり、そして明示的な承認を得てから実行することです。これを見るだけで、その境界線がどこにあるかがわかります。

3. 説明で対応できるなら、まずスクリプト化しない

OpenAIのドキュメントでも非常に実用的なアドバイスをしています。明確な決定論的動作や外部ツールが必要でない限りは、いきなりスクリプトにするのではなく、まずは説明（プロンプト）を使うべきです。なぜか？スクリプトが増えれば増えるほど、メンテナンスコストが上がってくるからです。多くのSkillは、最初は単に手順を明確に説明するだけで十分です：

何から始めるか
次に何をするか
出力形式はどうするか
どのような状況でユーザーに確認を求めるべきかこれだけでも大半の問題は解決します。あるステップが非常に安定していて、非常に機械的で、自動化に適している場合にのみ、scripts/に落とし込むようにしましょう。

4. 資料、テンプレート、リソースを分離する

Skill は書き進めるうちに、非常に長い説明文になりがちです。そんな時は分割すべきです。

SKILL.md はルールと手順を担当する
references/ には背景ドキュメントや参照資料を置く
assets/ にはテンプレート、アイコン、サンプルを置く
scripts/ には安定して実行できるアクションを置くこのようにすることで、2つの利点があります。第一に、メインファイルが肥大化しすぎるのを防げます。第二に、モデルが必要なときだけ詳細を読み込む形になり、「プログレッシブ・ディスクロージャー（段階的開示）」という考え方に沿えます。

5. ローカルで先に使い、プロジェクトをまたいで配布する

公式ドキュメントでもこの点は明確に分けられています。もしご自身の現在のリポジトリでのみ使用するのであれば、.agents/skills/ に配置するだけで十分です。Codex はリポジトリ、ユーザー、システムなどの場所からスキルディレクトリをスキャンします。しかし、この仕組みが単一のリポジトリだけでなく複数の場所で使えることに気づいた場合や、複数のスキルをまとめてパッケージ化して配布したい場合は、skill folderの層に留まらず、plugin を検討すべきです。OpenAI公式ドキュメントの記述も非常に明確で、Skill はワークフローそのものであり、真にインストールおよび配布に適した単位は plugin です。

スキルが適しているシナリオ

Skill は多ければ良いというものではなく、以下の種類のタスクに最も適しています。

高頻度で繰り返すタスク

毎週行う、そして毎回手順がほぼ同じもの。例えば：

PRレビューコメントの処理
ブログ記事の執筆とフロントマターの追記
CI失敗の調査
リリース前のチェックこのような作業は、モデルができないことよりも、毎回説明し直さなければならないことが一番面倒です。

固定フローのタスク

ある事柄には、生まれながらにして順序があるものがあります。例えば問題の調査をする場合、まずログを確認し、次に範囲を絞り込み、それから計画を立て、そして修正するという流れになります。このような場面では、Skill が特に適しています。なぜなら、順番を固定できるため、モデルがその場しのぎで対応するのを減らせるからです。

専門的な文脈に紐づける必要があるタスク

手順が固定されているだけでなく、強い制約を伴うタスクもあります。例えば：

公式ドキュメントのみを参照すること
特定のレビュー形式で出力しなければならないこと
チーム内の既存の用語を保持しなければならないこと
特定のリポジトリの記述または開発規約を遵守しなければならないことこのような作業は、毎回プロンプトに頼って一時的に指示を出すだけでは、漏れが生じやすいです。

ツールとプロセスを併用するタスク

このシナリオは特に典型的なものです。単に「GitHubに接続する」だけで終わるのではなく、接続した後も、何らかの方法でログを確認し、問題を分類し、修正が必要かどうかを判断し、最後にどのようにフィードバックするかという一連の作業が必要です。つまり、外部接続と内部プロセスが組み合わさって機能しなければなりません。このような場合、しばしば MCP + Skill が組み合わさって登場します。

スキルとして実装する必要がないシナリオ

逆に、どこまでを「スキル」とするのかを明確に伝える必要があります。そうしないと、何でもかんでもSkillにしようとしてしまいがちです。

一回限りの気軽なタスク

ユーザーが一時的に質問する場合、通常のプロンプトで十分なことが多いです。

あなたが望んでいるのは「外部システムへの接続」だけだ

その場合は、Skill ではなく MCP を優先的に検討してください。

リポジトリ全体の長期的な振る舞いを制約したい場合

これは Skill の仕事というよりは、AGENTS.md の仕事に近いです。したがって、簡単にまとめると以下のようになります：

接続が不足している場合、MCP を使う
プロセスが不足している場合、Skill を使う
グローバルなルールが不足している場合、AGENTS.md を使う

代表的な事例をいくつか

概念をどれだけ説明しても、実際の事例を見る方が良いです。

1. `roll-dice`：最小限の入門ケース

このケースはOpenAI公式のAgent Skillsドキュメントからのものです。非常に小さく、ディレクトリ内にはほとんどSKILL.mdしかなく、エージェントがユーザーからサイコロを振るよう要求された際に、PowerShellの乱数コマンドを呼び出すようにします。なぜこの例が良いのか？それはSkillの最も核となる骨格を直接示しているからです：

明確なトリガー条件がある
明確な実行方法がある
明確な境界線があるこれは、Skillが必ずしも大きくなくて良いことを示しています。あることが繰り返し発生し、モデルに無作為な振る舞いをさせたくない場合、それをSkillとして実装できるということです。

2. `gh-address-comments`：GitHub コメント処理のワークフロー例

このケースは、OpenAI 公式の openai/skills リポジトリから来ました。目的は「GitHubに接続する」ことではなく、「現在のブランチのPRのコメントを処理する」という一連のプロセスを固定化することです。公式バージョンでの手順が非常に典型的です：

まずghが認証済みか確認する
次に、現在のPRのコメントとレビュースレッドを取得する
これらのコメントに番号を振り、要約する
ユーザーにどのコメントを処理するか明確に選択させる
その後で初めて処理を開始するこの例は、Skill の価値を特に示しています。多くのエンジニアリングタスクにおいて、難しさは「モデルがGitHubとは何かを知っているか」という点ではなく、「正しい順序で物事を処理できるか」という点にあります。gh-address-comments が解決しているのは、まさにこのような順序の問題です。

3. `gh-fix-ci`：CI 失敗のエンジニアリングケースの調査

これも openai/skills リポジトリ内の公式スキルです。これは別の非常に典型的なエンジニアリングタスクを対象としています。それは、PR のチェックが失敗したとき、「直すべきか」「どう直すか」というものです。この Skill で定義されているワークフローも非常に代表的です：

まず gh のログイン状態を確認する
現在の PR を見つける
GitHub Actions の失敗したチェックとログを取得する
失敗した部分を抽出する
まず修正計画を立てる
承認を得てから実行するこれは、「CI がなぜ失敗したか見て」という単なるプロンプトでは安定して対応できないシナリオです。なぜなら、権限、ログ、外部ツール、承認の境界線、実行順序など、これらすべてを定義する必要があるからです。

4. リポジトリ固有のスキル：チーム独自のノウハウを蓄積する

公式なサンプル例以外で、私が考える Skill のより大きな価値は、実はプライベートリポジトリ内にあります。例えば、目の前のブログリポジトリにある blog-writer は、本質的には非常に典型的な repo-scoped skill です。これは「モデルに中国語の書き方を学ばせる」ことを担当しているのではなく、このリポジトリで既に固定された文体、構造、ファクトチェック、出力パス、データ保存形式などをワークフローとして記述したものです。このような Skill は、最も現実的な価値を持つことが多いです。なぜなら、すべての人に向けられているわけではなく、「あなたはこのリポジトリで、どのような種類の作業が繰り返し発生し、かつ逸脱しやすいか」という点に特化して解決するものだからです。

実際に「Skill」を使うべき時

そこで、最後に最も実用的な問題に戻ります。いつ真剣に Skill を作るべきでしょうか？私の答えは以下の通りです。それは、問題がもはや「モデルの能力不足」ではなく、「毎回同じ行動が安定しない」と感じたときです。この段階でプロンプトを積み重ねても、得られる利益は通常低くなる一方です。今日一文追加し、明日また一文追加するうちに、プロンプトはまるで出来事の羅列になり、モデルはやはりミスを犯します。むしろ、それを Skill として整理し、トリガー条件、手順、境界線、スクリプト、資料などを分けて管理する方が、効果が安定しやすく、再利用性も高まります。 MCP は外部世界と接続し、Skill は内部のノウハウを固定化します。前者は「できるかどうか」を解決し、後者は「どうすれば安定してできるか」を解決します。これが私が今理解している Skill です。それは新しいプロンプトでも、新しいプロトコルでもありません。むしろ、エージェントに職種マニュアルを渡すようなものです。

参考資料

作成上の注記

元のプロンプト

プロンプト：AI大規模言語モデルによるプログラミングについて、まずMCPが登場し、次にSkillが登場しました。平易な言葉で、Skillが何か、どのようにSkillを開発するか、どのようなシナリオに適しているか、それぞれ具体的な代表的な事例を挙げて説明してください。

ライティングの骨子まとめ

「MCP と Skill の概念レビュー」として繰り返し書くのではなく、重点を Skill の役割と使用範囲に置いた。
「職種マニュアル」「特定作業手順書（SOP）」といった平易な比喩を用いて、抽象的な定義を実際のワークフローに落とし込んだ。
開発部分は公式ドキュメントの実構造に沿って記述し、description、progressive disclosure、instruction-only といった重要な点を保持した。
ケーススタディは可能な限り公式ソースを選定し、それぞれ公式ドキュメント内の roll-dice、および openai/skills リポジトリ内の gh-address-comments と gh-fix-ci を使用した。
最後に、読者が読み終えた後も混同しないよう、MCP、Skill、AGENTS.md の三者の境界線を改めて整理した。

Skill on 向叔の手帳

AIがブログを書くという件、結局は工学的なものにする必要がある（1）

本当に面倒なのは、原稿を書くことではなく、あの一連の機械的な動作だ

blog-writer 最初の価値は文体ではなく、契約を固定化すること

シリーズ形式は、実は執筆の契約をさらに一歩進めたもの

しかし、単一のスキルだけでは、後でトークン制限にぶつかることになる

まずプロセスを安定させてから、スタイルやモデルについて語る資格が生まれる

参考資料

作成上の注記

元のプロンプト

ライティングのアイデア概要

Skill は新しいプロンプトではなく、エージェントに職種マニュアルを提供するものです。

Skill とは一体何なのか

Skill と MCP、結局どこが違うのか

スキルの開発方法

1. 「繰り返し現れるバイアス」を探す

2. description をトリガー条件として記述し、宣伝文句にしないこと

3. 説明で対応できるなら、まずスクリプト化しない

4. 資料、テンプレート、リソースを分離する

5. ローカルで先に使い、プロジェクトをまたいで配布する

スキルが適しているシナリオ

高頻度で繰り返すタスク

固定フローのタスク

専門的な文脈に紐づける必要があるタスク

ツールとプロセスを併用するタスク

スキルとして実装する必要がないシナリオ

一回限りの気軽なタスク

あなたが望んでいるのは「外部システムへの接続」だけだ

リポジトリ全体の長期的な振る舞いを制約したい場合

代表的な事例をいくつか

1. roll-dice：最小限の入門ケース

2. gh-address-comments：GitHub コメント処理のワークフロー例

3. gh-fix-ci：CI 失敗のエンジニアリングケースの調査

4. リポジトリ固有のスキル：チーム独自のノウハウを蓄積する

実際に「Skill」を使うべき時

参考資料

作成上の注記

元のプロンプト

ライティングの骨子まとめ

2. `description` をトリガー条件として記述し、宣伝文句にしないこと

1. `roll-dice`：最小限の入門ケース

2. `gh-address-comments`：GitHub コメント処理のワークフロー例

3. `gh-fix-ci`：CI 失敗のエンジニアリングケースの調査