AI開発の現場で、コードを書く時間よりもドキュメント作成やレビュー、議事録の整理に追われている…そんな悩みを抱えるエンジニアは少なくないでしょう。優れたコードを書く能力はもちろん重要ですが、現代の開発プロセスでは、アイデアを迅速に形にし、チームと円滑に共有する能力がかつてないほど求められています。
もし、あなたが日々書き溜めているObsidianのメモが、たった一つのコマンドで洗練されたプレゼンテーション資料に変わるとしたらどうでしょうか？
これを実現するのが、Anthropic社が提供するClaude Codeの新機能「Skills」です。これは単なる便利機能ではありません。AIとの対話を通じて開発プロセスそのものを変革する「バイブコーディング」という新たな開発スタイルを可能にし、私たちエンジニアのスキルアップを加速させる起爆剤となり得ます。
この記事では、kirekaku.com編集部が実際に「ObsidianのMarkdownメモをスライド化するSkill」を作成した経験を基に、以下の内容を徹底的に解説します。
- Claude Code「Skills」の本質と、それがAI開発にもたらすインパクト
- 実践的なプロンプトエンジニアリングを用いたSkillの設計・実装プロセス
- なぜそのプロンプトが高精度なアウトプットを生み出すのか、その技術的背景
- AI開発の現場で今日から使える「Skills」の応用アイデア
この記事を読み終える頃には、あなたはAIを単なる「コード生成アシスタント」としてではなく、開発ワークフロー全体を最適化する「知的パートナー」として活用するための、具体的かつ実践的なスキルを手にしているはずです。
なぜ今、AIエンジニアに「バイブコーディング」とプロンプトスキルが求められるのか？
結論：単にコードを書くだけでなく、AIとの対話を通じて開発プロセス全体を効率化する「バイブコーディング」が、生産性の次元を変えるから。
近年、LLM（大規模言語モデル）の進化は目覚ましく、GitHub CopilotやAmazon CodeWhispererといったAIコーディング支援ツールは、多くの開発現場で当たり前のように使われるようになりました。しかし、その多くはコードの補完や生成といった「コーディング」そのものに焦点を当てたものが中心でした。
一方で、実際の開発業務はコーディングだけでは完結しません。
- 仕様書や設計書の作成
- プルリクエストの説明文執筆
- コードレビューとフィードバック
- テストケースの作成
- 技術ブログや社内向けドキュメントの執筆
これらのタスクは、プロジェクトの品質と進行に不可欠でありながら、多くのエンジニアにとって大きな時間的負担となっているのが現実です。
ここで注目されるのが「バイブコーディング」という考え方です。これは、自然言語によるAIとの対話（Vibes）を通じて、コーディングだけでなく、上記のような周辺タスクも含めた開発プロセス全体をスムーズに進めていく開発スタイルを指します。
このバイブコーディングを実践する上で、核となるのがプロンプトエンジニアリングのスキルです。AIに対して「何をしてほしいのか」を的確かつ具体的に伝える能力は、もはや一部の専門家だけのものではなく、すべてのAIエンジニアにとって必須の教養となりつつあります。
優れたプロンプトは、AIの性能を最大限に引き出し、人間が意図した通りの高品質なアウトプットを安定して生成させることができます。それはまるで、経験豊富なジュニア開発者に的確な指示を出し、仕事を任せる感覚に近いかもしれません。
本記事で紹介するClaude Codeの「Skills」は、このプロンプトエンジニアリングをさらに一段階進化させ、AIとの対話をより構造的かつ再利用可能なものにする画期的な機能です。
【内部リンクの想定】
プロンプトエンジニアリングの基礎についてさらに詳しく知りたい方は、こちらの記事もご覧ください。
[基礎から学ぶプロンプトエンジニアリング入門]
Claude Codeの新機能「Skills」とは？ その本質は「AIの関数化」にある
結論：「Skills」は、一連の複雑な指示を再利用可能な「スキル」として定義することで、AIとの対話を構造化し、開発を加速させる機能。
Claude Codeに新たに搭載された「Skills」機能は、一言で言えば「一連のプロンプトを一つのパッケージとして名前をつけ、再利用可能にする仕組み」です。
エンジニアの方なら、「関数」や「API」をイメージすると理解しやすいでしょう。
- 関数: 特定の処理（例えば、数値の配列を受け取って合計値を返す）をまとめて名前をつけ、必要な時に呼び出すことができます。
- Skills: 特定のタスク（例えば、Markdownを受け取ってMarp形式のスライドに変換する）を実行するための詳細なプロンプト群をまとめて
slide-generatorのような名前をつけ、必要な時に呼び出すことができます。
これまでのAIとの対話では、同じような作業を依頼するたびに、毎回長いプロンプトをコピー＆ペーストする必要がありました。これは非効率であるだけでなく、プロンプトのバージョン管理が難しく、チーム内での共有も困難でした。
「Skills」は、この課題を根本から解決します。
| 課題 | 「Skills」による解決策 |
| 反復的なプロンプト入力 | 一度Skillを定義すれば、短いコマンドで複雑なタスクを呼び出せる。 |
| 属人性の高さ | 優れたプロンプトをSkillとしてチームで共有でき、誰でも高品質な成果を得られる。 |
| プロンプトの管理・改善の難しさ | Skillの定義を一箇所で管理・改善できるため、メンテナンス性が向上する。 |
| タスクの再現性の欠如 | 同じSkillを使えば、誰が実行しても安定した品質のアウトプットが期待できる。 |
この機能の技術的な背景には、Anthropicが提供するtool-use（Function Callingとも呼ばれる）の考え方があります。これは、モデルが外部のツールや関数を呼び出す能力を持つことで、より複雑で信頼性の高いタスクを実行できるようにするものです。「Skills」は、このtool-useのコンセプトを、ユーザーが定義したプロンプト群（＝ツール）に対して適用したものと捉えることができます。
この「AIの関数化」により、私たちはアドホックな指示の応酬から脱却し、より構造的で再現性の高い方法でAIと協調作業を行うことが可能になるのです。
【出典情報】
Claudeのtool-useに関する公式情報は、Anthropicの公式ドキュメントで確認できます。
【実践】ObsidianのMarkdownメモを秒速でスライドに変換するSkillを作ってみた
結論：わずか数十行のプロンプトで、日々のメモが即戦力のプレゼン資料に変わる自動化の仕組みを構築できる。
ここからは、実際に私たちが作成した「MarkdownをMarp形式のスライドに変換するSkill」を例に、Skillの設計から実装までのプロセスをステップバイステップで解説します。
ステップ1: ゴールの設定と要件定義
まず最初に、何を達成したいのかを明確にします。
- インプット: Obsidianで書かれた一般的なMarkdown形式のテキスト。見出し（
#,##）、リスト（-）、太字（**）などを含む。 - アウトプット: Marp というツールでプレゼンテーションスライドとして表示できる、特別な記法が追記されたMarkdownファイル。
- 変換ルール:
#（h1）見出しは、タイトルスライドに変換する。##（h2）見出しは、新しいスライドの開始点（---で区切る）とし、そのスライドのタイトルにする。- 各h2セクションのコンテンツ（リスト、段落など）は、そのスライドの本文として配置する。
- 全体に統一感のあるシンプルなデザインテーマを適用する。
ステップ2: Skillの設計 – プロンプトの骨子を作る
次に、AIに与える指示書、つまりプロンプトの骨子を設計します。高品質なアウトプットを得るためには、以下の要素を明確に定義することが極めて重要です。
- 役割 (Role): AIにどのような専門家として振る舞ってほしいかを定義します。
- タスク (Task): 具体的かつ明確に、何をしてほしいのかを指示します。
- 制約 (Constraints): やってほしくないこと、守ってほしいルールを明示します。
- アウトプット形式 (Output Format): どのような形式で出力してほしいかを厳密に指定します。
- インプット (Input): 処理対象となるデータをどのように与えるかを定義します。
この骨子に基づいてプロンプトを作成することで、AIの解釈のブレを最小限に抑え、意図した通りの結果を得やすくなります。
ステップ3: プロンプトの実装と改善
それでは、実際にプロンプトを作成していきましょう。ここでは、典型的な「悪い例」と、私たちが試行錯誤の末にたどり着いた「良い例」を比較しながら解説します。
悪いプロンプト例 vs 良いプロンプト例
| 比較項目 | ❌ 悪いプロンプト例 | ✅ 良いプロンプト例 |
| 具体性 | このMarkdownをスライドにして。 | ステップバイステップでの処理、Marpの構文ルール、デザイン指示まで具体的に記述。 |
| 役割設定 | なし | あなたは、Markdownとプレゼンテーション作成ツール「Marp」に精通したフロントエンドエンジニアです。 と明確に役割を指定。 |
| 文脈 | なし | Marpがどのようなツールであるか、なぜこの変換が必要なのかという背景情報を提供。 |
| フォーマット指定 | なし | 最終的なアウトプットは、単一のMarkdownコードブロック内に出力してください。 と厳密に指定。 |
| エラーハンドリング | なし | もし解釈が難しい部分があれば、その部分を指摘し、どのように処理したかをコメントで追記してください。 といった指示を含む。 |
✅ 良いプロンプト（Skill定義）の具体例
以下が、私たちが最終的に作成したSkillのプロンプト定義です。
あなたは、Markdownとプレゼンテーション作成ツール「Marp」に精通したフロントエンドエンジニアです。
あなたのタスクは、ユーザーから提供された標準的なMarkdownドキュメントを、Marpでレンダリング可能な単一のスライド形式のMarkdownファイルに変換することです。
# Marpの基本ルール
- 各スライドは `---` で区切られます。
- スライドの先頭には `--- marp: true theme: uncover ---` というフロントマターを必ず記述します。
- `#` (h1) はタイトルスライドとして扱います。
- `##` (h2) は新しいスライドの開始点とし、そのスライドのタイトルとなります。
- 画像、HTMLタグ、カスタムCSSは今回は使用しません。
# 変換手順
1. まず、提供されたMarkdownドキュメント全体の構造を解析してください。
2. `#` (h1) の内容を最初のタイトルスライドとして設定します。
3. 最初の `##` (h2) 以降、各 `##` (h2) が出現するたびに新しいスライド (`---` で区切る) を開始してください。
4. 各h2セクションの内容（リスト、段落、コードブロックなど）を、それぞれのスライドの本文として配置します。
5. すべての変換が完了したら、最終的な成果物を単一のMarkdownコードブロックとして出力してください。それ以外の余計なテキスト（挨拶、説明文など）は一切含めないでください。
# 制約条件
- 元のMarkdownのコンテンツの順序や内容は変更しないでください。
- Marpの構文に変換することにのみ集中してください。
- もし解釈が難しい部分があれば、その部分を指摘し、どのように処理したかをMarkdownのコメント `` として追記してください。
さあ、準備はできましたか？以下のMarkdownを変換してください。
このプロンプトでは、AIがタスクを正確に遂行するために必要な情報（役割、ルール、手順、制約）が網羅されています。なぜここまで詳細な記述が必要なのかは、次のセクションで深掘りします。
ステップ4: 作成したSkillの実行と結果
このSkillを generate-slide という名前で保存し、実際にObsidianのメモを入力として与えてみます。
入力するMarkdownメモ
Markdown
# AI開発におけるプロンプトエンジニアリング戦略
## なぜプロンプトが重要か
- AIの性能を最大限に引き出すため
- 意図通りのアウトプットを得るため
- 再現性と安定性の確保
## 基本的なテクニック
- **役割設定 (Role-Playing):** AIに専門家として振る舞わせる
- **思考の連鎖 (Chain of Thought):** ステップバイステップで考えさせる
- **制約の明示:** やってほしくないことを伝える
## 今後の展望
- プロンプトの自動生成
- マルチモーダル対応
- より高度な対話管理
Skillによる出力結果 (Marp形式)
Markdown
---
marp: true
theme: uncover
---
# AI開発におけるプロンプトエンジニアリング戦略
---
## なぜプロンプトが重要か
- AIの性能を最大限に引き出すため
- 意図通りのアウトプットを得るため
- 再現性と安定性の確保
---
## 基本的なテクニック
- **役割設定 (Role-Playing):** AIに専門家として振る舞わせる
- **思考の連鎖 (Chain of Thought):** ステップバイステップで考えさせる
- **制約の明示:** やってほしくないことを伝える
---
## 今後の展望
- プロンプトの自動生成
- マルチモーダル対応
- より高度な対話管理
ご覧の通り、元のメモの内容を忠実に維持しながら、Marpでスライドとして表示できる形式に完璧に変換されています。この出力結果を.mdファイルとして保存し、Marpが導入されたVSCodeなどで開けば、即座にプレゼンテーションが完成します。
これが「バイブコーディング」の威力です。エンジニアは、思考の整理という本来の目的に集中してメモを取り、定型的な変換作業はAIに任せることで、生産性を飛躍的に向上させることができるのです。
なぜこのSkillは高精度なのか？プロンプトエンジニアリングの勘所を深掘り
結論：AIの思考プロセスを明確に誘導し、曖昧さを徹底的に排除する構造化プロンプトこそが、安定した高品質なアウトプットを生み出す鍵である。
先ほどの「良いプロンプト例」は、なぜ安定して高精度な結果を生み出すのでしょうか。その背景には、近年のプロンプトエンジニアリング研究で有効性が示されているいくつかの重要なテクニックが組み込まれています。
テクニック1: Role-Playing (役割設定) の重要性
「あなたは、Marpに精通したフロントエンドエンジニアです。」
この一文は、単なる雰囲気作りではありません。AIに対して特定の「ペルソナ」を与えることで、LLMが持つ広大な知識の中から、その役割に関連する情報を優先的に活性化させ、より専門的で精度の高い応答を生成させる効果があります。これをRole-PlayingやPersona-Promptingと呼びます。
この指示により、AIは「Marp」というキーワードに対して、一般的な知識だけでなく、その構文、ベストプラクティス、典型的な使い方といった、より深い文脈を考慮してタスクを遂行しようとします。
テクニック2: Chain of Thought (CoT) を促す
「1. まず、…解析してください。 2. 次に、…設定します。 3. …」
複雑なタスクを依頼する際に、「このMarkdownをスライドにして」と最終結果だけを求める（Zero-Shot）のではなく、タスクを複数のステップに分解し、その思考プロセスを順に示すことで、AIはより論理的で正確な推論を行うことができます。この手法はChain of Thought (CoT) Promptingとして知られており、特に複雑な問題解決においてAIの性能を大幅に向上させることが多くの研究で示されています。
プロンプトに具体的な「変換手順」を記述することで、AIは闇雲に変換を試みるのではなく、人間が設計した論理的なフローに沿って処理を進めるため、エラーや解釈の間違いが劇的に減少します。
【出典情報】
Chain of Thoughtに関する独創的な研究は、Google Researchのチームによる論文で発表されました。
テクニック3: Few-Shot Learningの応用
今回のプロンプト例には直接含めていませんが、さらに精度を高めるための強力なテクニックとしてFew-Shot Learningがあります。これは、AIにいくつかの「お手本（入力と期待される出力のペア）」を提示することで、タスクのパターンを学習させ、未知の入力に対しても同様の処理を適用させる手法です。
例えば、プロンプト内に以下のような具体例を追加します。
# 参考例
## 入力例1:
## タイトル
- 内容1
- 内容2
## 出力例1:
---
## タイトル
- 内容1
- 内容2
このような具体例を1つか2つ（Few-shot）与えるだけで、AIは変換ルールの曖昧な部分を自己補完し、よりロバストな処理が可能になります。
テクニック4: 制約条件の明示化
「それ以外の余計なテキスト（挨拶、説明文など）は一切含めないでください。」
「元のMarkdownのコンテンツの順序や内容は変更しないでください。」
AIは時に「親切心」から、要求されていない余計な説明文や挨拶を付け加えてしまうことがあります。また、指示が曖昧だと、コンテンツを要約したり、表現を勝手に変更したりすることもあります。
プログラムの関数の戻り値の型を厳密に指定するように、プロンプトにおいても「何をすべきか」だけでなく**「何をしてはいけないか」**を明確に伝えることが、出力の安定性と予測可能性を高める上で非常に重要です。これにより、生成されたアウトプットを後続のプログラムで処理する際にも、予期せぬエラーを防ぐことができます。
これらのテクニックを組み合わせることで、私たちのプロンプトは単なる「お願い」から、AIの思考を制御し、望ましい結果へと導くための「設計図」へと昇華されるのです。
「Skills」をAI開発の現場で活かすための3つのアイデア
結論：ドキュメント生成の自動化にとどまらず、コードレビュー、テストケース生成、API仕様書作成など、開発サイクルのあらゆる場面で応用できる。
今回紹介したスライド生成Skillは、ほんの一例に過ぎません。この「プロンプトを関数化する」というアプローチは、AI開発のあらゆるワークフローに応用可能です。ここでは、今日からあなたの現場でも試せる3つの応用アイデアを紹介します。
アイデア1: プルリクエスト要約Skill (summarize-pr)
開発者にとって、プルリクエスト（PR）の差分（diff）を読んで変更内容を把握し、適切な説明文を書く作業は、地味ながらも時間のかかるタスクです。
- インプット:
git diffの出力結果 - タスク:
- 変更の目的（バグ修正、機能追加、リファクタリングなど）を推測する。
- 主要な変更点をファイルごとに箇条書きで要約する。
- 潜在的なリスクやレビューしてほしい観点を提案する。
- 期待される効果:
- PR作成にかかる時間を大幅に短縮。
- レビュワーが変更内容を素早く理解でき、レビューの質とスピードが向上。
- レビュー観点の抜け漏れを防ぐ。
アイデア2: テストケース自動生成Skill (generate-test-cases)
機能仕様書や既存のコードから、テストケースを網羅的に洗い出すのは骨の折れる作業です。
- インプット: 機能仕様書や、テスト対象の関数・クラスのコードスニペット
- タスク:
- 仕様書やコードを解析し、主要なロジックを特定する。
- 正常系のテストケース（典型的な値、境界値）を生成する。
- 異常系のテストケース（不正な入力、null、空文字、エラーが発生する条件）を網羅的に生成する。
- テストフレームワーク（Jest, pytestなど）の形式でコードを出力する。
- 期待される効果:
- テストケース作成の工数を削減し、開発者がより複雑なテストシナリオの設計に集中できる。
- 人力では見落としがちなエッジケースを発見し、品質向上に貢献。
アイデア3: API仕様書（OpenAPI）生成Skill (create-api-docs)
コードとドキュメントの乖離は、多くのプロジェクトが抱える問題です。
- インプット: APIを実装したコントローラーやサービスクラスのコード（JSDocや型定義を含む）
- タスク:
- コード内のアノテーション、関数名、引数の型、返り値の型を解析する。
- エンドポイントのパス、HTTPメソッド、リクエストパラメータ、レスポンスボディを抽出する。
- OpenAPI (Swagger) 3.0 のYAML形式で仕様書を生成する。
- 期待される効果:
- ドキュメント作成を自動化し、常にコードと同期が取れた最新の状態を維持。
- フロントエンドとバックエンド間のコミュニケーションコストを削減。
これらのSkillをチームで共有・活用することで、開発チーム全体の生産性は劇的に向上します。エンジニアは退屈な定型作業から解放され、より創造的で付加価値の高い、本来注力すべき設計や問題解決といった業務に時間を使うことができるようになるでしょう。これは、個人のスキルアップとキャリア形成においても大きなプラスとなるはずです。
まとめ – バイブコーディングでAI時代のエンジニアとして進化し続けるために
本記事では、Claude Codeの新機能「Skills」を題材に、AIとの対話を通じて開発プロセスを変革する「バイブコーディング」と、それを支える実践的なプロンプトエンジニアリングの技術について解説しました。
- バイブコーディングとプロンプトスキルは現代エンジニアの必須科目: AIとの対話能力は、コーディング能力と同様にエンジニアの生産性を左右する重要なスキルとなっています。
- Claude Codeの「Skills」はAIとの対話を構造化する強力なツール: 複雑なプロンプトを「関数化」することで、再現性、共有性、メンテナンス性を飛躍的に高めることができます。
- 高品質なアウトプットは緻密なプロンプト設計から生まれる: 役割設定、思考の連鎖（CoT）、制約条件の明示といったテクニックを駆使することで、AIの能力を最大限に引き出すことが可能です。
- 応用範囲は無限大: ドキュメント生成からコードレビュー、テスト設計まで、開発ワークフローのあらゆる場面でAIとの協調作業を実現できます。
AI技術の進化は、私たちエンジニアから仕事を奪うものではなく、むしろ私たちを定型的で退屈な作業から解放し、より創造的な領域へと導いてくれる強力なパートナーです。
重要なのは、AIを単に便利に「使う」のではなく、その仕組みや特性を理解し、意のままに「使いこなす」ためのスキルを主体的に学び続ける姿勢です。プロンプトエンジニアリングは、まさにそのための核心的な技術と言えるでしょう。
今日紹介したgenerate-slide Skillのように、まずは身の回りの小さな課題を自動化することから始めてみてください。その小さな成功体験の積み重ねが、AI時代のエンジニアとして進化し続けるための、大きな一歩となるはずです。
kirekaku.comでは、これからもAI開発の現場で本当に役立つ、一歩踏み込んだ実践的な情報を発信し続けていきます。
