最近、AIの各サービスにおける「Skills」について、めちゃくちゃ考えているんですよね。
きっかけはClaudeのSKILL.mdの仕組みを深掘りしたことなんですけど、調べていくうちに「これ自分の仕事の根っこに関わる話だな」って思ったんです。
で、気づいたらOpenClawやらGemini CLIやらn8nやらを横断的に比較しながら、自動化の本質みたいなところまで潜っていってしまった。そんな話です。
Skillsって結局なんなのか
まず前提として、各AIサービスごとに「Skills」の意味というか定義が若干バラバラなのかなと感じています。
GeminiのGemはSkillsかって言われるとちょっと違う。あれはペルソナ設定、トーン調整に近い。「こういうキャラで喋って」っていう指示であって、再現可能なワークフローを体系的に定義するものじゃない。
一方で、Claude CodeのSKILL.mdやGemini CLIのAgent Skillsは、「スキル」なんですよね。
SKILL.mdというマークダウンファイルをベースに、Pythonスクリプト、フォント、テンプレート、参考資料なんかをフォルダにまとめて、AIエージェントがそれを読み込んで実行する。しかもこのSKILL.mdフォーマット、もともとAnthropicが提唱したオープンスタンダードで、Claude Code、Gemini CLI、GitHub Copilot、Cursorなんかで横断的に使えるポータブルな仕様になっている。
つまり!自分が作ったスキルは特定のAIサービスに縛られない。ツールが変わっても、資産として持ち運べるってことです。
そしてOpenClaw。Peter Steinbergerがオーストリアで個人プロジェクトとして作って、あっという間にGitHubで爆発的に広がり、最終的にOpenAIに事実上買収されたもの。
あれのSkillsはもっとアクション寄りで、メール送信、予約、ブラウザ操作みたいな「実際に何かをする」ためのもの。ClawHubっていうスキルマーケットプレイスがあって、ユーザーがスキルを作ってアップロードして共有できる仕組みになっていました(悪意あるスキルが10%以上混入していたっていうセキュリティの問題はあったけど)。
方向性は違うけど、「AIの振る舞いをユーザーがカスタマイズする」という本質は同じなんですよね。
データが流れるか、質が求められるか
で、ここからが本題なんですけど。
n8nみたいなノードベースのワークフロー自動化ツールと、SKILL.md型のアプローチって、役割がまったく違うんです。
n8nは「データのフロー」が価値の中心。フォーム入力→スプレッドシートに記録→メール送信→カレンダーに予約、みたいに、外部サービス間でデータが正確に流れればそれでいい。
そこに文体もデザインも要らない。僕のMitoflow40で言えば、例えば申し込み→顧客情報をNotionに登録→血液検査のリマインド→3ヶ月後のフォロー通知。これはn8nで組むのが良いと思います。
一方、記事や資料は「質」が価値の核心。この記事が僕の文体や実体験で書かれていること自体に意味がある。それはAPIの接続で実現するものじゃなくて、スキルの中に定義された語り口やリズム、構成のルールが生み出すもの。
データが流れる → n8n
質が求められる → Skills
この二層構造で捉えると、何をどう自動化すべきかがクリアになるなと感じています。
量は質を高め、質はフローに乗る
で、もうひとつ気づいたことがあって。
よく「質と量」って対比で語られます。量を追うと質が落ちるみたいな。
でも、僕はそうじゃないと思っていて。量は質を高めるために必要なプロセスなんですよね。
こうしてジャーナルを今まで書き続けてきたから、自分の文体のパターンが見えてきた。何百本も書いた蓄積があるから、それをSKILL.mdとして定義できるだけの「型」が固まったんです。量がなかったらスキルは書けませんからね。
そして、質が固まった瞬間に「フロー」させる準備が整う。
自分が書かなくてもAIがその質を再現できるようになるから、パイプラインに乗せられる。スキルとして固定資産化した文体は、ノードの一つとしてワークフローに組み込める。
逆に言うと、質が固まっていないものをフローさせると、薄いものが大量に流れるだけになる。
つまり、AIを本当の意味で使えるかどうかの分かれ道はここにあると僕は感じているのです。
量は修行、質は型、フローは仕組み。
この三段構えで考えると、「何をスキル化すべきか」の判断基準にもなる。「これはまだ量のフェーズだから、もっと手を動かす時期だな」「これはもう型が見えたから、スキルに落とし込もう」と。
スキルは固定資産になる
結局のところ、Skillsっていうのは自分の仕事の「型」をファイルとして外部化したものなんですよね。
デザインテンプレート、文体ルール、ワークフローの手順、チェックリスト。これらをスキルフォルダにまとめておけば、毎回同じクオリティのアウトプットが出る。しかもオープンスタンダードだから、実行するAIが変わっても資産は残る。
これはフリーランスや小さなチームにとってはめちゃくちゃ大きい話なんですよ。今まで「自分の頭の中」にしかなかったノウハウが、ポータブルな固定資産になる。
量をこなして型を見つけ、型をスキルに落とし込み、スキルをフローに乗せる。
僕はこのサイクルをこれからもっと加速度的に回していくつもりです。
ええ、もちろんこの記事も実験的にSKILL.mdと定義したものを読み込ませて書いているんですよ(笑)
ちなみに、僕は映像制作やWeb制作、AIを使ったワークフロー構築を仕事にしています。「自分の仕事の型をスキル化してみたい」「発信や業務の自動化を一緒に考えてほしい」という方がいたら、気軽にお声をかけてください!
クライアント、スポンサー、協働者、仲間を常に探しています。
→ 相談・お問い合わせはこちらからどうぞ!
https://www.shinealight.jp/#contact
Comments by daisuke kobayashi
絶対にムカデを寄せ付けないアイテム4選
Warning: Attempt to read property "comment_post_ID" on string in /home/c7471475/public_html/hyperpast-journal.xyz/wp-content/plugins/wp-multibyte-patch/wp-multibyte-patch.php on line 248
Warning: Attempt to read property "comment_content" on string in /home/c7471475/public_html/hyperpast-journal.xyz/wp-content/plugins/wp-multibyte-patch/wp-multibyte-patch.php on line 249
徳島県南下の沖合に浮かぶ「出羽島」を空撮してきました
Warning: Attempt to read property "comment_post_ID" on string in /home/c7471475/public_html/hyperpast-journal.xyz/wp-content/plugins/wp-multibyte-patch/wp-multibyte-patch.php on line 248
Warning: Attempt to read property "comment_content" on string in /home/c7471475/public_html/hyperpast-journal.xyz/wp-content/plugins/wp-multibyte-patch/wp-multibyte-patch.php on line 249