コンサルの仕事は「属人化の塊」だ。
毎回ゼロから考えているようで、実は頭の中に同じ型が回っている。案件が始まったらまずフォルダを作る。会議が終わったらQAを抽出する。朝一番で4つのアプリを巡回する。どれも自分なりの「テンプレ」があるのに、それは自分の頭の中にしかない。
Claude Skills（SKILL.md）を使って、その暗黙のテンプレを外部化してみた。結果、案件立ち上げも議事録処理もブリーフィングも、誰がやっても——というより、いつClaudeに頼んでも——同じ品質で再現できるようになった。
この記事では、その過程で学んだ「仕事の設計図を書く」プロセスを、具体的なSkillの実装例、つまずきポイント、そして実践的なテンプレートを交えて解説する。
導入前後の変化：Before/After分析
まず、Skillを導入した前後で何が変わったのかを数字で示す。
| 業務項目 | 導入前 | 導入後 | 改善率 |
|---|---|---|---|
| 案件立ち上げ（初期セットアップ） | 4～8時間 | 5分 | 98% 削減 |
| 会議準備（事前+事後処理） | 2～3時間/回 | 20分 | 85% 削減 |
| デイリーブリーフィング | 30分 | 0分（自動） | 100% 削減 |
| ナレッジ検索 | 1～2時間 | 3～5分 | 95% 削減 |
| QA抽出（議事録から） | 45分 | 10分 | 78% 削減 |
| 経費処理（月末） | 3時間 | 10分 | 94% 削減 |
| 月間定型作業時間 | 約40～50時間 | 約4～5時間 | 90% 削減 |
定量的な時間削減に加えて、定性的な改善も大きい。
品質の安定化：担当者の気分や疲労度に左右されない一貫した品質。案件ごとに「フォルダ構造が違う」という混乱が消える。
心理的負荷の軽減：毎日同じ手順を手動で実行する必要がなくなり、「やることが明確」という安心感が生まれる。
発見効率の向上：デイリーブリーフィングが自動化されたことで、見落としていた重要なメッセージやタスクが可視化される。
コンサル業務の再現性問題 ―「優秀な人」に依存する限界
コンサルティングという仕事の本質的な課題は「再現性」にある。
ある案件で素晴らしい分析ができたとしても、それは担当コンサルタントの経験と直感に依存している。隣の席の人間が同じクオリティを出せるとは限らない。もっと言えば、自分自身ですら、3ヶ月後に同じ品質を再現できる保証はない。
ファームにいた頃、この問題は「ナレッジマネジメント」という名前で呼ばれていた。過去の提案書をSharePointに格納し、分析フレームワークをテンプレート化し、新人研修でケーススタディを共有する。しかし正直に言えば、それらは「置いてあるだけ」のことが多かった。検索しても見つからない。見つかっても文脈が違う。結局、詳しい人に聞くのが最速という属人的な解決策に戻ってくる。
独立してからは、もっと深刻だった。チームがいない。自分の頭の中にあるテンプレを、自分で毎回手動で再現するしかない。会議のたびに同じフォーマットで議事録を作り、案件のたびに同じ構造でフォルダを組み、毎朝同じ順番でアプリを巡回する。「型」はあるのに、その型を実行するのに毎回30分かかる。
この問題の構造を抽象化するとこうなる：
「知識」はある → 「手順」もある → 足りないのは「知識と手順を、人を介さずに実行する仕組み」
Claude Skillsは、まさにその仕組みだった。
Claude Skillsとは何か ―Prompts・Projects・MCPとの違い
Claudeには複数の「カスタマイズ手段」がある。混同しやすいので整理しておく。
Prompts（プロンプト） は、その場限りの指示だ。「この文章を要約して」「表形式にまとめて」。1回使ったら終わり。再利用するにはコピペが必要で、文脈は引き継がれない。
Projects は、特定のプロジェクトに紐づく知識ベースだ。資料をアップロードしておけば、そのプロジェクト内の会話で参照される。ただし、プロジェクトをまたいだ再利用はできない。
MCP（Model Context Protocol） は、外部サービスとの接続だ。Notion、Slack、Gmail、Googleカレンダーなどのデータを読み書きする「手足」を提供する。しかしMCP自体は「何をするか」を知らない。接続手段であって、業務知識ではない。
Skills は、これらとは根本的に異なる。SKILL.mdというマークダウンファイルに「業務の型」を書き出す。いつ起動するか（トリガー条件）、何をするか（手順と判断基準）、どこのデータを使うか（MCPとの連携）。これをCowork modeの所定のディレクトリに置くだけで、Claudeがその業務を再現可能な形で実行する。
わかりやすく言えば、Promptsが「口頭の指示」、Projectsが「プロジェクト資料棚」、MCPが「外部サービスへの配線」だとすると、Skillsは「業務マニュアル」だ。一度書けば何度でも、誰が（どのセッションが）使っても同じ品質で動く。
プロンプトエンジニアリングの先にある概念、と言ってもいい。プロンプトは「うまく聞く技術」だが、Skillsは「仕事の設計図を渡す技術」だ。
実際に作った6つのSkill ―コンサル業務の「型」を外部化する
現在、自分の環境で稼働しているSkillは6つある。すべてコンサル実務から抽出した「型」だ。各Skillがどういう問題を解決し、どのような判断基準で動いているかを詳しく解説する。
① case-setup（案件セットアップ）
トリガー：「新規案件」「案件立ち上げ」「フォルダ作成」「PJ立ち上げ」「セットアップ」
処理内容：新規案件が始まったとき、「〇〇社の案件セットアップをお願い」と一言頼むだけで起動する。以下の3つのステップを自動実行する。
- 定義済みのフォルダ構造を自動作成
- 📁 提案書・契約書
- 📁 議事録（日付ごとに自動整理）
- 📁 調査資料（業界分析、市場データ）
- 📁 成果物（ドラフト、最終版）
- 📁 クライアント管理（組織図、連絡先）
- テンプレート文書を各フォルダに配置
- 提案書テンプレート（構成案：背景→課題→提案→ROI）
- 議事録テンプレート（参加者、議題、QA、Next Action）
- 契約書チェックリスト（NDA確認、支払条件、機密情報の定義）
- クライアント企業の初期リサーチを自動実行
- PEST分析（政治的・経済的・社会的・技術的環境）の枠組みで調査
- 公式サイトから企業規模、事業内容、競合との差異を抽出
- 過去に同業界で支援した案件とのリンクを作成
結果：以前は半日かけていた作業が5分で終わる。しかもフォルダ構造が全案件で統一されるので、「あの資料どこだっけ」という検索コストがゼロになった。これは時間以上に精神的な負荷の軽減が大きい。案件ごとに構造が違っていると、引き継ぎのときに余計な説明が必要になるが、それが完全に消える。
SKILL.mdの設計のコツ：
- クライアント企業の「業界コード」を自動判定し、それに応じて参照すべき過去案件を検索する判定ロジックを明記する
- 「契約金額が100万以上なら契約レビュー、以下ならNDA署名のみ」といった分岐条件を定義する
② mtg-assistant（会議アシスタント）
トリガー：「会議準備」「MTG準備」「議事録」「次の会議」「事前準備」
処理内容：会議の事前準備から事後処理まで一貫してカバーする。以下の5つのフェーズで動作する。
事前フェーズ：
- アジェンダの作成：提供されたテーマから会議の流れを構成（時間配分を含む）
- 関連資料の検索：Skillが内部的にknowledge-searchを呼び出し、過去の類似会議資料を発見
- 過去の議事録サマリー：前回の会議から今回までの宿題事項を抽出し、「確認事項」として提示
事後フェーズ：
- 議事録の整形：会議の文字起こしテキストを、定義されたフォーマット（参加者、日時、議題、決定事項、QA、Next Action）に自動構造化
- QAの自動抽出：meeting-qa-extract Skillを内部呼び出し
- Next Actionの整理と担当者のメンション：「〇〇は△△までに××を提出」という形で責任を明確化
結果：コンサルの会議は「準備8割」と言われる。このSkillを入れてから、事前準備の質が安定した。過去の議事録から前回の宿題事項を自動で拾ってくるので、「前回何を話しましたっけ」という会議冒頭の無駄な5分がなくなった。
また、Next Actionが自動整理されることで、「あの仕事、誰が担当するんだっけ」という曖昧性が消える。特にクライアント側の対応期限が明記されるので、「こちらの提案に対するフィードバックをいつまでに欲しいのか」が可視化される。
SKILL.mdの設計のコツ：
- 会議の「カテゴリ」（初期ヒアリング、定期報告、クライアント決定会議など）を判定し、それぞれ異なるテンプレートを適用する
- 「〇〇が発言 → 疑問形で返してくる → これはQAだ」というパターン認識を組み込む
③ daily-briefing（デイリーブリーフィング）
トリガー：「/briefing」「朝の確認」「ブリーフィング」「今日やること」（スケジュール実行タスクとしても運用）
処理内容：毎朝、MCP経由でGmail・Slack・Googleカレンダー・Notionに同時接続し、その日のブリーフィングレポートを生成する。以下の4つのセクションで構成される。
- 未読メールダイジェスト（優先度順）
- 「From: 〇〇」のメールは赤フラグ（クライアント、パートナー企業からのメール）
- 件名に「返信待ち」「確認」が含まれるメールは黄フラグ
- 他は通常表示
- 各メールの要点を1行で要約
- Slack要対応メッセージ一覧
- DMの未読メッセージ
- 自分宛のメンション
- 特定キーワード（「至急」「確認」「レビュー」など）が含まれるメッセージ
- 今日の会議と準備メモ
- 時系列で並べた会議リスト
- 各会議の事前資料リンク
- 前回の議事録から「前回の宿題で今日提出予定」の項目を抽出して表示
- 期限が迫っているタスク
- Notion データベースから「期限が本日または明日」のタスクを検索
- 優先度順に表示
- 既に完了したタスクは表示から除外
結果：スケジュール実行タスクと組み合わせて毎朝自動実行させているので、PCを開いた時点でブリーフィングが完成している。4つのアプリを巡回する30分のルーティンが消えた。これだけで月に10時間以上の節約になっている。
さらに隠れた効果がある。「朝一番でメールをチェックする習慣」が意識的に設計された流れに変わったので、重要なメッセージを見落とす確率が低下した。人間が「重要そうな件名」を判定するより、システムが「差出人」「件名キーワード」「メンション」などの複合条件で判定する方が、漏れが少ない。
SKILL.mdの設計のコツ：
- 「クライアント=優先度高」という判定ロジックをSKILL.mdに明文化。クライアント一覧をデータベースで管理する
- スケジュール実行の時間を「朝7:00」に固定するか、実行の都度決めるか。通勤時間に読むのか、デスクに着いてから読むのか、ユーザーのルーティンに合わせてトリガー時刻を設計する
④ knowledge-search（ナレッジ検索）
トリガー：「/knowledge」「過去事例」「ナレッジ検索」「前に使ったフレームワーク」「この業界で」「過去に」
処理内容：過去の支援資料・提案書・分析結果を横断検索し、関連する知見を発見・要約する。以下の2つのモードで動作する。
モード1：業界検索
- 「この業界で過去にやった分析ある？」というクエリに対し、Notion データベースから業界コード・案件タイプでフィルタリング
- マッチした過去案件の提案書・分析レポートを自動検索
- 「3年前の〇〇社案件で、同じ課題に対して△△という分析をしました。参考資料：×××」という形で提示
モード2：フレームワーク検索
- 「前に使った4ボックス分析、どこにあったっけ」というクエリに対し、ローカルファイル＋Notion データベースから「フレームワーク名」で検索
- マッチしたフレームワークが使われた案件一覧を表示
- テンプレート形式で「そのまま使える状態」で提供
結果：これはファーム時代に欲しかった機能そのものだ。SharePointに眠っている資料を探し回る必要がなくなった。独立後も案件が増えるにつれてナレッジが散逸しがちだったが、このSkillが「過去の自分」を検索可能にしてくれた。
実運用では、「〇〇という施策を提案したいが、どこかで似たことやったことあるかな」という曖昧なクエリに対しても、複数の過去案件がヒットするようになった。つまり、業界・課題タイプ・分析手法を組み合わせた複合検索が可能になり、直感的な発想から実装へのジャンプが短くなった。
SKILL.mdの設計のコツ：
- 過去資料に「業界コード」「課題タイプ」「分析手法」というメタデータを事前につけておく。メタデータなしでも自動抽出を試みるが、精度は低い
- 検索結果の「関連度スコア」を計算し、完全一致は高スコア、部分一致は低スコアというランキングロジックを定義する
⑤ meeting-qa-extract（QA抽出）
トリガー：「QA抽出」「質疑応答」「Q&A」「議事録からQA」（ファイル、テキスト直接貼り付け）
処理内容：会議の文字起こしテキストからQA（質疑応答）を抽出し、Word文書として整形・出力する。mtg-assistantの一部機能でもあるが、QA抽出だけを単独で使いたい場面が多いので独立させた。
抽出対象となるQAパターンは以下の通り：
- パターン1：直接的な質問 ―「〇〇についてはどうお考えですか」「その場合、〜〜という対応で問題ないでしょうか」
- パターン2：間接的な問いかけ ―「〇〇も気になるところですね」「ただし、〜〜という課題があると思われますが」
- パターン3：意思表示＋条件質問 ―「できれば××になるといいんですが」「2週間後の納期で大丈夫ですか」
出力形式：
| 質問者 | Q（質問・懸念事項） | 回答者 | A（回答） | ステータス |
|---|---|---|---|---|
| クライアント | 〇〇について… | 支援者 | △△のように考えています | 完了 / 要フォローアップ |
SKILL.mdの設計のコツ：
- 「質問者」「回答者」のロールを正確に特定する。文字起こしに話者情報がない場合は、文脈から推測する
- QAのステータスを「完了」「要フォローアップ」に分類し、後日の確認漏れを防ぐ
⑥ freee-sync（経費処理連携）
トリガー：「経費処理」「領収書」「会計」「freee」「勘定科目」
処理内容：領収書PDFからテキストを抽出し、日付・金額・取引先・勘定科目を構造化して、会計ソフトにインポートできるExcel形式で出力する。
- PDF テキスト抽出：OCRで領収書の日付、金額、取引先を抽出。複数の領収書PDFがある場合は、一括処理可能
- 勘定科目の自動判定：取引先名＋品目説明から勘定科目を判定（Amazon→事務用品費、飛行機・ホテル→交通費、カフェ＋クライアント名→交際費）
- 事業按分比の自動計算：カフェでクライアント打ち合わせ→100%事業用、ファミレスでランチ＋仕事→50%計上
- Excel出力：freeeへのインポート形式に自動変換。日付、金額、勘定科目、取引先、摘要、按分比率を列出力
結果：月末の経理処理が3時間から10分の確認作業に圧縮された。ルールが明文化されているので、判定の揺れがない。また、按分ロジックが明文化されることで、税理士との確認時に「なぜこう判定した」という説明が容易になった。
SKILL.mdの書き方 ―トリガーとロケーション、そして判断基準の設計思想
Skillを作る上で最も重要なのは「いつ起動するか」「どこに置くか」「何を根拠に判定するか」の3つの設計だ。
トリガー設計
トリガー設計とは、Claudeがどういう言葉を受け取ったらそのSkillを使うかを定義することだ。
- 日本語の表現揺れを吸収する。「案件立ち上げ」「案件スタート」「PJ開始」「新案件」「案件キックオフ」など、同じ意味の言い回しを複数列挙する
- 短すぎるキーワード（「新規」「立ち上げ」だけ）は避ける。他のSkillと重複する可能性がある
- 実際に自分がどう話しかけるか、を想像する。マニュアル的な言葉だけでなく、会話の中で自然に出てくる表現を含める
ロケーション設計
ロケーション設計は、SkillのSKILL.mdファイルをどのディレクトリに配置するかだ。Cowork modeはスキルフォルダを自動スキャンしてSkillを認識する。
Skills/
├─ Case Management/
│ └─ case-setup/
│ └─ SKILL.md
├─ Meetings/
│ ├─ mtg-assistant/
│ │ └─ SKILL.md
│ └─ meeting-qa-extract/
│ └─ SKILL.md
├─ Daily Ops/
│ └─ daily-briefing/
│ └─ SKILL.md
├─ Knowledge/
│ └─ knowledge-search/
│ └─ SKILL.md
└─ Finance/
└─ freee-sync/
└─ SKILL.md判断基準の明文化
手順だけを書いたSkillは、プロンプトテンプレートと大差ない。Skillが真価を発揮するのは、「こういう場合はAの処理、こういう場合はBの処理」という分岐条件を書いたときだ。
【直接的な質問】
- 「〇〇についてはどうお考えですか」→ QAとして抽出
- 「その場合、~~という対応で問題ないでしょうか」→ QAとして抽出
【間接的な問いかけ】
- 「〇〇も気になるところですね」→ 潜在的な質問と判定し、QAとして抽出
- 「ただし、~~という課題があると思われますが」→ 確認が必要な懸念事項と判定し、QAとして抽出
【判定の根拠】
話者のトーンが「確認を求めている」「判断を委ねている」「異議を唱えている」の3つのパターンで、QAとして抽出する。Skillを設計するためのテンプレート ―あなたの暗黙知を外部化する
以下は、新しいSkillを作るときの空テンプレートだ。このテンプレートを埋めていくプロセスを通じて、自分の業務の「型」が言語化される。
# Skill: [スキル名]
## 目的
このSkillは、何を解決するのか。どの業務の属人化を排除するのか。
（例：新規案件立ち上げの初期セットアップにかかる時間を80%削減し、全案件のフォルダ構造を統一する）
## トリガー
ユーザーが使うと予想される言い回し（複数）
- 「〇〇をお願い」
- 「△△して」
- 「××したい」
## 前提条件
このSkillが正常に動作するために、事前に必要な設定や情報
- 必要なMCP接続：Notion、Gmail など
- ユーザーが事前に準備すべき情報：クライアント一覧、フォルダパス など
## 処理フロー
### ステップ1: 入力の確認
ユーザーからの入力を受け取り、必要な情報が揃っているか確認。足りない情報があれば追加質問。
- 確認項目：（リスト形式で）
- 例外処理：足りない情報があった場合、どうするか
### ステップ2: [処理の名前]
具体的な処理内容を述べる
- やること：（リスト形式で）
- 判断基準：こういう場合はA、こういう場合はB
### ステップ3: [処理の名前]
（以下、ステップ数に応じて繰り返す）
## 判断基準と分岐ロジック
「こういう情報が来たら、このように処理する」という判定ルール。
| 入力の特徴 | 判定 | 処理 |
|---|---|---|
| 〇〇の場合 | パターンA | △△を実行 |
| ××の場合 | パターンB | □□を実行 |
## 出力形式
このSkillの最終出力は、どのような形か。
- ファイル形式：Word, Excel, Markdown など
- 保存場所：ローカル、Notion など
- ファイル命名規則：〇〇_YYYYMMDD.docx など
## 内部呼び出し（他のSkillとの連携）
このSkillが内部的に使用している他のSkill
- knowledge-search Skillを「過去の類似案件を検索」するために呼び出す
- 呼び出し条件：入力に「業界名」が含まれている場合
## テスト用のサンプル入力
実際にこのSkillを試すための入力例
- サンプル1: 「〇〇社の案件立ち上げをお願い」→ こういう出力が期待される
- サンプル2: 「△△について過去に支援した案件ある？」→ こういう出力が期待される
## 更新ログ
Skillを改善するときの記録
- 2026年4月：トリガー「案件スタート」を追加（ユーザーからのフィードバック）
- 2026年3月：判定ロジック「金額別の対応」を追加
## メモ（作成者向け）
このSkillを自分で改善するときに参考になる情報
- よくある質問：「〇〇という業界の場合どうする？」→ △△という基準で処理している
- つまずきやすい点：××という判定が曖昧になりやすい → サンプルを増やして対応業務テンプレ化チェックリスト ―どの業務をSkill化すべきか判断する基準
すべての業務がSkill化に適しているわけではない。以下のチェックリストを使って、Skill化すべき業務と、そうでない業務を見分けよう。
Skill化に向いている業務の特徴
- 月1回以上、繰り返し発生する業務か ―週1回以上なら、ほぼ確実にSkill化の価値がある
- 処理フロー（手順）が決まっているか ―「いつも同じやり方」という習慣がある = Skill化できる
- 判断基準が言語化できるか ―「この場合はA、この場合はB」という分岐が明確か
- 入出力が明確か ―スタート地点とゴール地点がはっきりしている
- データアクセスが可能か ―MCP経由でアクセスできるサービスのデータを扱っている
- クオリティの「ばらつき」が課題か ―「人によって完成度が違う」という問題が起きている
Skill化に向かない業務の特徴
- 創造的な判断が必要か ―Skillはテンプレートを実行するツールであり、創造性を代替しない
- クライアントとの信頼関係が中心か ―営業面談・経営層との交渉・複雑な相談はAIの仲介化は逆効果
- 例外や変動が多いか ―分岐ロジックが複雑になりすぎて、Skillの管理コストが高くなる
- 判断の責任が重いか ―契約判断・法的リスク判定・財務決定は人間による確認を残す設計にする
【新しいSkill候補を評価するときに使うチェック】
□ 月1回以上、繰り返し発生する
□ 処理フロー（手順）が決まっている
□ 判断基準が言語化できる
□ 入出力が明確
□ MCP経由でデータアクセス可能（または、ローカル操作で完結）
□ クオリティのばらつきが課題
□ 創造的な判断が不要（定型処理中心）
□ クライアント/ステークホルダーとの直接対話が不要
□ 例外や変動が少ない
□ 判断の責任が軽い（または、人間による確認プロセスを組み込める）
☞ チェックが7個以上ならSkill化の優先度が高い。
☞ チェックが5個以下なら、Skillより「手順マニュアル」の方が適切かもしれない。副次効果 ―Skillを書くと「自分の思考」が言語化される
予想していなかった効果がある。Skillを書く過程で、自分自身の仕事の「型」が言語化されるのだ。
自分の思考プロセスの可視化
case-setupを作るとき、自分がどういうフォルダ構造で仕事をしているのか、初めて明文化した。長年の習慣で無意識にやっていたことが、文字になって目の前に現れる。すると「あれ、このフォルダ構造は冗長じゃないか」「このフォルダ、実は使ってないな」という改善点が見える。
meeting-qa-extractでは、「自分がQAだと判断する基準」を言語化する必要があった。やってみると、直接的な疑問文だけでなく、語尾の「ですかね」や「気になりますが」も自分はQAとして拾っていたことに気づいた。暗黙知が形式知に変わる瞬間だ。
業務改善の入口になる
Skillを書く過程で「この判断基準、実は矛盾していないか」「この分岐、もっと簡潔に書けないか」という疑問が生じることがある。それは、業務プロセス自体を改善するチャンスだ。
たとえば、freee-syncで「事業按分ルール」を明文化したときに、「カフェでのランチは50%事業用」と「ファミレスでのランチは0%」と分けていたことに気づいた。結果、「クライアント企業の人間が同席していない限り、外食は100%個人費用」とルールを統一した。
チーム内の知見共有が進む
Skillをチームに共有するということは、業務の型を共有するということだ。SKILL.mdという形で可視化される。新人のオンボーディングにも使えるし、チーム内の品質の標準化にもつながる。
コンサルティングファームでは「ナレッジマネジメント」が喧伝されながらも、実際には属人化が進むことが多い。その理由は「知識は文書化されるが、判断基準は口頭でしか伝わらない」からだ。Skillの場合、判断基準まで含めてSKILL.mdに書き込むので、真の意味でのナレッジ共有が起きる。
つまずきポイント3選 ―実装時に「あれ、これどうするんだろう」という瞬間
つまずきポイント①：トリガーの重複と誤発火
問題：「mtg-assistant」と「meeting-qa-extract」の両方が、「QA」というキーワードに反応するように設定していた。すると、2つのSkillが同時に起動してしまい、「どっちを実行したいのか」という曖昧性が生まれた。
対策：
- トリガーキーワードを「QA抽出」「質疑応答の抽出」など、より具体的な言い回しに変更
- 「mtg-assistant」のトリガーには「会議」を含める（会議コンテキストの場合はmtg-assistantが優先）
- 「meeting-qa-extract」は「議事録から」「文字起こしから」など、「抽出元」を明示するキーワードを追加
- Cowork modeの設定で「トリガーの優先度」を定義（1つ以上のSkillがマッチする場合、どれを優先するか）
つまずきポイント②：判定ロジックの「グレーゾーン」
問題：「交通費」「交際費」「給食費」の区分で、微妙なケースが生じた（ビジネスホテルのレストランでの夕食、新幹線乗車中の駅弁、出張当日の空港での朝食など）。
対策：
- 「グレーゾーン判定テーブル」をSKILL.mdに追加し、実例ベースで定義
- グレーケースが生じるたびに、「判定の論理的根拠」をSKILL.mdに追記
- 月1回の「Skill健康診断」時間を設けて、判定ロジックの一貫性を確認
つまずきポイント③：MCP接続の権限と情報漏洩のリスク
問題：daily-briefingスキルがメールを読み込むために、MCPを通じてGmailに接続する必要があった。しかし、チームメンバーに共有した場合、メンバーのGmailには接続すべきではない（プライバシーの侵害）。
対策：
- Skillのロジック（SKILL.md）とMCPの権限設定（実際にどのサービスにアクセスするか）を分離する
- Notionデータベースのアクセス制御を厳密にする。「全員が参照すべきナレッジ」と「プロジェクト固有の機密情報」を明確に分ける
- Skill内にセンシティブ情報を保持しない。出力ファイルは必ずローカル保存に限定する
チーム展開の注意点 ―権限と個人情報の線引き
権限の分離
Skillの処理ロジック（SKILL.md）と、データアクセスの権限（MCP設定）は分離して管理する。Skill自体は共有しても、MCPの接続先は各個人が自分の環境で設定する、という設計が基本になる。
個人情報の扱い
SKILL.md自体にはデータを保持させず、処理のルールだけを記述する。出力ファイルの保存先をローカルに限定し、クラウド同期の対象外にする。「このSkillが参照するNotionデータベースは、このページまで」という範囲を明確にする。
Skill自体の管理と改善
Skillは「属人化を排除する」ツールだが、Skill自体の設計・メンテナンスは属人化しやすい。定期的にSkillの棚卸しをして、トリガー条件や処理ルールが現在の業務実態と乖離していないか確認する。月に1回、Skillの「健康診断」をする時間を取る。グレーケースが発生するたびに、SKILL.mdに「判定ルール」として記録する。
読者ワーク：「あなたの暗黙知を棚卸しする」
ここまでで、Skillの概念や6つの実装例を見てきた。では、あなた自身の業務ではどうか。実際に考えてみるための「ワーク」を用意した。
ステップ1：「毎日やっていることリスト」を作成（5分）
朝起きてから寝るまで、あなたが「習慣的に」「無意識に」やっていることを、全て書き出す。（例：メールをチェックする、SlackのDMを確認する、今日のスケジュール確認、前日の議事録を読む）
ステップ2：「その作業に何が必要か」を分解（10分）
月1回以上繰り返される作業を選び、その作業を構成する「要素」を分解する。（例：「メールをチェックする」→ Gmailを開く→未読メールを確認→重要なメールを判定→返信が必要なメールをピックアップ→スター付け）
ステップ3：「判断基準は何か」を言語化（15分）
「判定」や「分類」が入っている部分を見つけ、その判定基準を言語化する。（例：差出人=クライアント企業 → 重要、件名に「返信待ち」→ 重要、営業時間外のメール→ 緊急）
ステップ4：「これはSkill化できるか」を判定（5分）
ステップ3で言語化した業務について、前述の「業務テンプレ化チェックリスト」を使って評価する。チェック5個以上なら、次のステップへ。
ステップ5：Skill設計テンプレートを埋めてみる（30分）
前述の「Skill設計テンプレート」を実際に埋めてみる。完成度は不問。この「埋めるプロセス」こそが、業務理解を深める。これを3〜4個の業務について繰り返すと、「自分の仕事の型」が見えてくる。
まとめ ―AIの使い方ではなく、仕事の設計図を書く時代
Claude Skillsの本質は「AIを賢く使う技術」ではない。「自分の仕事を構造化し、再現可能な設計図として書き出す技術」だ。
- Prompts → 「うまく聞く力」
- MCP → 「データをつなぐ力」
- Skills → 「仕事を定義する力」
コンサルティングにおける「再現性」は、長らく「優秀な人材を育てる」というアプローチで解決しようとされてきた。研修、OJT、ナレッジ共有。しかしそれは「人」に再現性を求めるアプローチであり、限界がある。
Skillsは「仕組み」に再現性を埋め込むアプローチだ。 人の能力に依存しない分、スケーラビリティがある。
もちろん、Skillsで外部化できるのは仕事の一部に過ぎない。クライアントとの信頼構築、戦略的な意思決定、複雑な交渉。これらは型にできないし、型にすべきでもない。しかし「型にできる部分」を確実に型にすることで、「型にできない部分」に集中する余白が生まれる。
自分の場合、6つのSkillを作ったことで月に20時間以上の定型作業が消えた。その時間は、クライアントとの対話や新しい分析手法の開発に充てている。AIに仕事を奪われたのではなく、AIに仕事を預けて、自分はもっと面白い仕事に移動した。
2026年のいま、AIの使い方を学ぶフェーズは終わりつつある。次は「自分の仕事の設計図を書く」フェーズだ。Claude Skillsは、そのための最初の道具として十分に実用的だと思う。
関連記事
- Cowork modeで個人事業の事務作業が消えた話 ―デスクトップAIの実践記
- Claude Max 20xを3ヶ月使い倒したコンサルの本音 ―サブスク価値検証
この記事は、実際にClaude Skillsを使って構成案の整理と参考情報の収集を行い、最終的な執筆と編集は筆者自身が行っています。
AI実務家コンサルタント
大智（Daichi）
- ▶不動産・金融15年・デューデリジェンス累計30件超
- ▶AI活用で月間作業60時間削減を実現
- ▶地方遊休不動産の稼働率 28%→62% に改善