コンサルの仕事は”属人化の塊”だ。
クライアントの課題を聞いて、構造化して、打ち手に落とす。毎回ゼロから考えているように見えて、実は頭の中で同じフレームワーク、同じ段取り、同じ品質基準が回っている。でもそれは自分の頭の中にしかない。だから再現できないし、人に渡せない。
Claude Skills（SKILL.md）を使い始めて、この問題が解けた。
Skillsとは、Claudeに「業務の手順書」を渡す仕組みだ。フォルダにSKILL.mdというファイルを置くだけで、Claudeがその手順を学習し、適切なタイミングで自動的に発動する。プロンプトを毎回書き直す必要がない。1回設計すれば、何度でも同じ品質で再現される。
この記事では、僕が実際に作って業務で回している5つのSkillを紹介しながら、「AIを使いこなす」とは何なのかを考える。
Skillsとは何か — Prompts・Projects・MCPとの違い
Claude周りには似た概念が多い。整理しておく。
Prompts（プロンプト）は一回限りの指示。「この議事録を要約して」と打つたびに、毎回同じ指示を書く必要がある。
Projects（プロジェクト）は背景知識の置き場。「うちのクライアントはこういう業界で、こういう課題を持っている」という文脈をClaudeに常時渡しておく。参照資料のようなもの。
MCP（Model Context Protocol）は外部ツールとの接続口。NotionやSlack、Gmailなど外部サービスにClaudeがアクセスするためのプロトコル。「何にアクセスできるか」を決める。
Skillsは「どうやるか」を教える。MCPが「接続」ならSkillsは「手順」。Projectsが「知識」ならSkillsは「技術」。一度書いたら自動で発動し、同じ品質を再現してくれる。
もっと端的に言えばこうだ。プロンプトは「今だけの指示」。Projectsは「ずっと覚えておいて」。MCPは「あのツールを使えるようにして」。Skillsは「このやり方で毎回やって」。
僕が作った5つの実用Skill
1. case-setup（案件立ち上げ）
新規案件が来たとき、「/case 〇〇社」と打つだけで以下が一気に動く。クライアント名のフォルダ構造を自動作成（提案書・議事録・成果物・参考資料）、テンプレートファイルを配置、企業の基礎情報をWeb検索してPEST分析の初稿を生成。以前は案件立ち上げのたびに15分かけてフォルダを作り、テンプレをコピーしていた。今は30秒。しかも初回リサーチまで付いてくる。
2. mtg-assistant（会議アシスタント）
「/mtg 〇〇社 定例」と打つと、会議前はアジェンダ案と関連資料の検索。会議後は議事録テキストからNext Actionの抽出と整理。会議の前後処理が半自動化された。ポイントは「会議名やクライアント名に言及するだけで発動する」ようにトリガーを設計したこと。わざわざスキル名を覚えなくても、「〇〇社の定例の準備して」と自然に言えば動く。
3. daily-briefing（朝のブリーフィング）
毎朝「/briefing」と打つと、今日のスケジュール確認、未読Slackの要約、重要メールの確認、タスクの優先順位提示が一括で出てくる。これはMCPサーバー（Googleカレンダー・Slack・Gmail）と組み合わせて初めて機能する。MCPが「情報への接続」を担い、Skillsが「何をどの順序で見せるか」を設計している。この2つの組み合わせが、いわば「AI秘書のOS」になっている。
4. knowledge-search（ナレッジ検索）
「前にやった〇〇の分析ってどんなアプローチだった？」と聞くと、過去の支援資料を横断検索して関連する知見を引き出してくれる。コンサルにとって過去事例の再利用は品質とスピードの源泉だ。でも普通のファイル検索では、自分がどういう名前でファイルを保存したか覚えていないと辿り着けない。Skillsに「業界名やテーマ名で聞かれたらトリガーする」と設計しておけば、曖昧な問いかけでも関連ナレッジが返ってくる。
5. meeting-qa-extract（QA抽出）
会議の文字起こしを投げて「/qa」と打つだけで、質疑応答を抽出し、整形されたWord文書として出力する。前回の記事でも触れたが、Cowork modeとSkillsの連携でこれが実現している。
SKILL.mdの書き方 — 設計の勘所
SKILL.mdの構造はシンプルだ。YAMLフロントマター（メタ情報）とマークダウン本文（手順）の2部構成。重要なのは3つ。
①descriptionの精度。YAMLフロントマターのdescriptionが、Claudeがこのスキルを「いつ使うか」を判断する根拠になる。ここが曖昧だと、使いたいときに発動しない。逆に具体的に書きすぎると、想定外の場面で暴発する。「何をするスキルか」と「いつ使うべきか」の両方を明記するのがコツだ。
②トリガーの設計。「/case」のようなスラッシュコマンドで明示的に呼ぶパターンと、「案件立ち上げ」「新しいクライアント」のような自然言語で暗黙的に発動するパターンの両方を設計する。僕は「明示トリガー3つ + 暗黙トリガー5つ」くらいのバランスで書いている。
③手順の粒度。大枠だけ書いて細部はClaudeに任せるか、ステップバイステップで厳密に指定するか。僕の経験では、「判断基準」を書いて「手段」はClaudeに任せるのがベスト。たとえば「勘定科目は税理士基準で分類」とは書くが、「PDFのどのフィールドを読むか」までは書かない。
Skillを作ることで起きた副次効果 — 自分の思考の言語化
正直、いちばん価値があったのはSkill自体ではなく、Skillを書くプロセスだった。
案件立ち上げのSkillを書こうとしたとき、「自分はいつもどういう手順でやっていたんだっけ」を言語化する必要があった。すると「実はこの手順は不要だった」「ここの判断基準が曖昧だった」という気づきが大量に出てきた。
コンサルの仕事は「暗黙知の塊」で、先輩の背中を見て覚える世界だ。でもSkillを書く行為は、その暗黙知を強制的に形式知に変換する。結果として、自分の仕事の設計図が見えるようになった。
これは、AIを「使う」話ではない。AIに「教える」ために自分の仕事を棚卸しした結果、自分の仕事が整理された、という話だ。
チームに展開するときの注意点
Skillsは個人で使うだけでなく、チームで共有できる。同じSKILL.mdをチームメンバーのClaude環境に配置すれば、全員が同じ品質で業務を回せる。ただし注意点がある。
個人情報の取り扱い。Skillの中にクライアント名や具体的な契約条件を埋め込まないこと。Skillは「やり方」を定義するもので、「誰の案件か」は実行時に渡すべきだ。
権限の設計。Skillがファイルの読み書きやMCP経由で外部サービスにアクセスする場合、誰がどこまでの権限を持つのかを先に決めておく。特にSlackへの投稿やGoogleカレンダーへの書き込みなど、副作用のある操作は慎重に。
過度な自動化の誘惑。全部をSkill化したくなるが、「判断が毎回変わるもの」はスキルにしない方がいい。Skillは再現性が武器なので、再現性がないタスクを無理にSkill化すると、かえって品質が下がる。
まとめ — AIの使い方ではなく、仕事の設計図を書く時代
Skills systemの本質は、技術の話ではない。
「自分の仕事はどういう手順で、どういう判断基準で、どういう品質基準で回っているのか」を言語化し、外部化すること。それがSkillを書くという行為の正体だ。
プロンプトエンジニアリングが「AIへの上手な頼み方」だとすれば、Skills設計は「自分の仕事の設計図を書くこと」に近い。前者はAI側の話、後者は自分側の話。
2026年のClaude活用で最も重要なのは、モデルの性能でも、プロンプトの巧みさでもなく、「自分の仕事をどこまで構造化できるか」だと僕は思っている。構造化できた部分はSkillに任せ、構造化できない部分に自分の時間を集中させる。それがコンサルタントとしての僕とAIとの付き合い方だ。
daichi
コンサルタント × 個人事業主。Claude Max 20x契約中。仕事を「構造化して任せる」を実践中。
コメントを残す