🎙️ Podcast台本: AIエージェントと「Skill」の衝撃

登場人物

• A (話し手): 技術好きエンジニア。今日の企画を持ち込んだ張本人。Agent Skillsにハマっている。
• B (聞き手): 技術好きだが、最近のエージェント界隈の用語ラッシュにはちょっと引き気味。台本の内容は知らされていない。

0. オープニング & 導入 (5分)

A: いややあ、最近さ、AIエージェント界隈、用語多すぎ問題ない？

B: (同意のリアクション: いや、ほんとそれ。ついていけない...)

A: だよね。「CLAUDE.md」とか「MCP」とか「Skill」とか、もうわけわかんないじゃん？

B: (苦笑い: MCPって何？って感じだわ)

A: でしょ？ 今日はね、その中でも特に俺が「これマジで世界変わるわ」って思った「Agent Skills（エージェントスキル）」について、飲み会ノリで語り尽くしたいなと。

B: (興味: お、スキル？ 聞いたことあるような...)

A: そうそう。これを知るとね、AI開発のパラダイムが変わるから。

B: (ツッコミ: なにそれw)

1. そもそも用語が多すぎる問題 (10分)

A: まずさ、Bさん。「コンテキスト」って言葉、エンジニアならよく使うけど、AIにおけるコンテキストって何だと思う？

B: (回答: 文脈...とか？ 履歴？)

A: そう！ 正解は「入力のメッセージリスト」のこと。要はAIに読ませるチャット履歴全部のことね。

B: (なるほど)

A: じゃあ、「コンテキストエンジニアリング」は？

B: (回答: その履歴をいい感じにすること？)

A: 天才かよ。そう、「情報をどう選んで、どうAIに食わせるか」っていう技術のこと。これ、後で大事になるから覚えといて。

2. Agent Skillsって何？ MCPとどう違うの？ (15分)

A: で、本題の「Agent Skills」なんだけど。これ、一言でいうと「AIの脳みそを外付けにする技術」なんだよね。

B: (質問: 外付け？ どういうこと？)

A: 普通、プロンプトに全部指示書くじゃん？ 「お前は優秀なエンジニアで...」とか。

B: (うんうん)

A: でもそれだと、指示が長くなりすぎてAIがアホになるんだよ。だから、指示書（SKILL.md）を別のファイルに書いておいて、AIが必要な時だけ「あ、このスキル使お」って読みに行くの。

B: (驚き: え、自分で読みに行くの？)

A: そう！ これが「遅延ロード」。で、ここでよくある疑問。「MCP（Model Context Protocol）と何が違うの？」って話。

B: (あー、MCPね。よく聞くけどわからん)

A: これね、例えるならMCPは「筋肉」で、Skillは「武術の型（技）」なんだよ。

B: (反応: 筋肉と技？)

A: MCPは外部ツールと繋がるための手足だから、身体能力そのもの。でも、いくら筋肉ムキムキでも、戦い方を知らないとただ暴れるだけでしょ？

B: (納得: 確かに。パワーはあるけど何していいかわからない感じか)

A: そう。そこでSkillっていう「秘伝の巻物」を渡すわけ。「まずは右ストレート、次にアッパー」っていう手順（型）を教えるのがSkill。

B: (なるほど！ じゃあ筋肉（MCP）も鍛えまくったほうがいいんじゃない？ ツールいっぱいあったほうが便利でしょ？)

A: そこが落とし穴なんだよ！ 「ツールを増やせばエージェントは賢くなる」っていうのは大きな誤解なの。

B: (え、違うの？)

A: 道具箱にハンマーとドライバーとノコギリと...って100個入ってたらどうなる？

B: (うーん、どれ使っていいか迷うかも)

A: でしょ？ AIも一緒。選択肢が多すぎると「判断ミス」が増えるんだよ。だから、必要な時に必要なSkill（マニュアル）だけを渡すのが大事。

B: (あー、だからSkillは「必要な時だけ読みに行く」のか)

A: その通り。「コンテキスト（情報量）が増えれば性能が上がる」ってのも誤解で、大事なのは量じゃなくて「密度」なんだよね。これを最適化するのが「コンテキストエンジニアリング」ってやつ。

B: (お、さっきの伏線回収！)

A: だから俺は断言する。「MCPでツールを増やす前に、Skillで脳みそを整理しろ」と。型を知らないのに道具ばっかり増やしても、AIは混乱するだけだからね。

3. 実践！Skillで何が変わったか（体験談） (15分)

具体例 軽めの導入

AIに「専門家の脳」をインストールする。 Agent Skills で爆速開発する方法

A: 理屈はわかったと思うけど、実際に俺がこれ使って何したか聞いてくれる？

B: (反応: お、出た自慢話。聞きましょう)

A: まず軽めのやつから。「WebFileBin」って自作ツールがあるんだけど、これにニュース集計機能をつけたのよ。

B: (うん)

A: で、その機能を「Skill」として切り出して、友達にURL送ったの。「これ叩いてみて」って。そしたら友達の環境でも一発で動いたわけ。

B: (反応: へえ、環境構築とかナシで？)

A: そう！ gemini skills install って打つだけ。感覚としては npm install に近いかな。「俺の技（ニュース集計術）」をパッケージ化して配れるってのが衝撃だったね。

B: (なるほど、知見の共有がコマンド一発なのか)

A: で、もっとビビったのがこれ。人生初のNeovimプラグインを作った話。

B: (お、Vim？ Vimmerの聖域に手を出したか)

A: 普通ならVim scriptとかLuaの勉強から入るじゃん？ 俺、一切やってない。

B: (えっ、どういうこと？)

A: 「Conductor」っていう指揮者役のAIに、「こういう機能が欲しい」って伝えただけ。そしたらAIが勝手に仕様書（spec.md）書いて、実装計画（plan.md）立てて、コード書いて、デバッグまでし始めたの。

B: (驚愕: ...マジで？ お前は何してたの？)

A: 俺は「おー、いいじゃん、進めて」って言うだけ（笑）。完成まで2時間。

B: (呆れ: 2時間は盛りすぎだろ... 俺たちが苦労して書いてたVim scriptは何だったんだ...)

A: 嘘じゃないって！ 証拠のログ全部残ってるから見てよ（リンク）。これが「指揮者（Conductor）」と「技（Skill）」の力なんだよ。

具体例 重めの導入

Gemini CLI ConductorとSkillを駆使して人生初プラグインを2時間で作成した話

リモーションの公式Skillsで死滅回遊のフローチャートを作成

>

呪術廻戦：死滅回游編フローチャートをmermaid.jsで書いてみた!

↓

Remotion Flowchart Dev Log

↓

呪術廻戦：死滅回游 構造解析 動画

↓

==スキルを活用して量産する例==

- 前回指摘した事項が守られていた。

スキル判断フローチャート

A: さらに応用編。RemotionってReactで動画作るやつあるじゃん？

B: (あるね)

A: あれで「フローチャート画像から解説動画を作るSkill」を定義したの。そしたら、「死滅回遊の図」を渡すだけで動画が生成された。

B: (反応: 完全に動画工場じゃん)

A: そう。しかもSkillだから再現性がある。次に別の図を渡しても、同じクオリティで動画ができる。

B: (感心: 単発の生成じゃなくて、プロセスごと自動化してるのか...)

A: まさに。この「スキル判断フローチャート」（リンク）も同じSkillで作ったんだ。

4. これからのエンジニアの立ち回り (10分)

A: こうなってくるとさ、エンジニアの勉強の仕方も変わると思うんだよね。

B: (どう変わるの？)

A: まず、「暗記」と「手作業」の価値が暴落する。

B: (え、メソッド名とか覚えなくていいの？)

A: いい！ HTMLのタグとかAPIの仕様とか、AIに聞けば一発で正確なコードが出てくる時代に、人間が脳のリソース使って覚える意味ないじゃん？

B: (まあ確かに... ググるより早いしな)

A: その代わり、「めちゃくちゃ重要になる領域」がある。それが「アーキテクチャ」と「モデリング」。

B: (設計か... なんか難しそう)

A: AIってさ、局所的なコード書くのは天才的だけど、システム全体の整合性とか将来の拡張性を考えるのは苦手なんだよ。

B: (あー、全体が見えてない感じ？)

A: そう。だから人間は、ソフトウェアアーキテクチャとか、データモデリング、ドメインモデリングみたいな「構造を作る力」に全振りすべき。

B: (なるほど、AIを部下にするための帝王学みたいなもんか)

A: その通り！ で、それって結局「何を作りたいか」っていうプロダクトへの愛に繋がるんだよ。作りたいものがあるから、最適な設計を考えるわけでしょ？

B: (確かに。技術は手段でしかなくなるのか)

A: 今までは「資格勉強」して知識を脳に詰め込んでたけど、これからは「必要な時に、必要なSkillファイルをダウンロードしてAIに食わせる」。で、人間は設計と判断に集中する。ぶちあたった壁があるときに、必要な情報を調査すればいいのさ!

B: (感心: なるほどなぁ... 作ることに集中できるってことか)

5. リスナーの代弁コーナー (5分)

B: ちょっと待って、最後にリスナーの代弁としていくつか聞いていい？

A: お、どうぞどうぞ。

B: まず一つ目。「カスタムインストラクション」ってあるじゃん？ あれとSkillは何が違うの？

A: いい質問。どっちもシステムメッセージを追加する手段だけど、カスタムインストラクションは「直接」書き込むのに対して、Skillは「ポインタ（参照先）」だけを渡すんだよ。

B: (ポインタ？)

A: そう。AIには「ここにマニュアルあるよ」とだけ伝えて、AIが必要だと思った時だけ中身を読みに行く。だから無駄な情報を常時食わせなくて済むわけ。

B: 次。「コンテキストエンジニアリング」って言葉出てきたけど、プロンプトエンジニアリングとは違うの？

A: 全然違う。プロンプトエンジニアリングは「命令文（ユーザーメッセージ）」をどう書くか。

B: (うんうん)

A: 対してコンテキストエンジニアリングは「メッセージリスト全体」をどう設計するか。過去の会話、ツール実行結果、メタデータ...これら全部ひっくるめて「コンテキスト」と呼んで、それを最適化するのがコンテキストエンジニアリング。

B: (なるほど、もっと広い視点なんだな)

B: 三つ目。さっきも出たけど、結局MCPとSkillはどう違うの？

A: 何回でも言うよ。MCPは「外部とデータをやり取りする手段（手足）」。Skillは「タスクに特化した補助情報（脳）」。レイヤーが違うから比較するもんじゃない。

B: (OK、手足と脳ね。覚えた)

B: 最後の質問。じゃあMCPサーバーもスキルもじゃんじゃん登録しちゃっていいの？

A: ダメです（笑）。

B: (即答w)

A: MCPサーバーを登録すると、そのツール定義が全部システムメッセージに追加されちゃうの。ユーザーが見えないところで。

B: (え、そうなの？)

A: そうすると、ツールが多すぎてAIが「どれ使えばいいんだ...」って混乱したり、誤爆したりする確率が上がる。だから「MCPの登録は計画的に」。これ大事です。

B: (うわー、気をつけよ...)

6. エンディング (5分)

A: というわけで、今日は「Skill」について語ったけど、どうだった？

B: (感想: いやー、ちょっとSkill書いてみたくなったわ。あとMCPの断捨離してくる)

A: それな（笑）。ぜひリスナーのみんなも、まずは自分の「得意技」をSKILL.mdに書き出すところから始めてみてほしいね。

A: じゃあ今日はここまで！ お疲れ様でした！

B: (挨拶: お疲れ様でしたー！)

https://webfilebin-share.com/47743a08-8071-706d-22fb-f29c8292831b/codex-log-019c44db.html