ブログ

Claudeに「来週の予定を踏まえて、Slackの未読を優先度順に整理し、Notionの案件データベースと照らしてリスケが必要な案件を教えて」と頼んだら、そのまま答えが返ってきた。

別にプログラムを書いたわけではない。APIを叩くコードを組んだわけでもない。MCPサーバーというものを4つ接続しただけだ。それだけで、Notion・Slack・Gmail・Googleカレンダーという4つのバラバラなツールが、Claudeの「頭の中」で1つにつながった。

この記事では、MCPサーバーで複数SaaSを統合した実体験と、「ツールの壁が消える」という感覚を具体的に書く。準備から運用まで、つまずきポイントと対策も含めて。

SaaSが増えすぎた問題 ― タブ30個時代の苦痛

個人事業をやっていると、SaaSが際限なく増える。

案件管理はNotion。チームとのやりとりはSlack。メールはGmail。スケジュールはGoogleカレンダー。ファイル共有はGoogle Drive。経費管理は会計ソフト。請求書は別のツール。タスク管理はまた別のアプリ。

それぞれが優秀なツールだ。単体で見れば使いやすい。問題は「横のつながり」がないことだ。

Before/After ― MCP導入で何が変わったか

具体例として、クライアントから「先週の会議で話した件、進捗どうですか？」というSlackメッセージが来たとしよう。

MCP接続前： Slackで過去のやりとりを遡り → Notionで案件ボードを開き → Googleカレンダーで会議日を確認し → Google Driveで共有した資料を探す → 4つのアプリを横断して情報を自分の頭の中で統合 → ようやく返信を書く。

MCP接続後： 「その案件の進捗を」とClaudeに聞く → Slack・Notion・Gmail・Googleカレンダーから自動で情報を集め、前回の決定事項・進捗状況・リスク・次のステップを統合したサマリーが返ってくる。

この「人間がハブになって情報を統合する」という作業が、毎日何十回と繰り返される。1回5分だとしても、1日に10回やれば50分。月に換算すると15時間以上を「アプリ間の橋渡し」に使っている計算になる。

本来やるべきなのは「考えること」と「判断すること」だ。なのに実際にやっているのは「情報を集めて並べること」。この構造に限界を感じていたときに出会ったのが、MCPサーバーだった。

MCPサーバーとは何か ― Claudeの「手足」を増やすプロトコル

MCP（Model Context Protocol）は、Anthropicが2024年末にオープンソースとして公開したプロトコルだ。簡単に言えば「AIに外部サービスのデータを読み書きさせるための共通規格」。

従来、AIに外部データを扱わせようとすると、サービスごとにAPIを叩くコードを書く必要があった。Notion用のスクリプト、Slack用のスクリプト、Gmail用のスクリプト。それぞれ認証方式が違い、データ構造が違い、エラーハンドリングも個別に書かなければならない。

MCPはこれを標準化した。MCPサーバーという形で各サービスへの接続が定義されており、Claude側は「MCPサーバーに接続する」という統一的な方法でデータにアクセスできる。プラグインを差し込むような感覚に近い。

2026年4月時点で、公式レジストリには400以上のMCPサーバーが登録されている。Notion、Slack、Gmail、Googleカレンダー、GitHub、Jira、Figma、データベース系、ファイルストレージ系。主要なSaaSはほぼカバーされている。

重要なのは、MCPが「ツールの追加」ではなく「情報の統合レイヤー」だという点だ。サービスAのデータとサービスBのデータを、人間が橋渡しすることなく、Claude自身が横断的に参照・処理できる。これが「ツールの壁が消える」という感覚の正体だ。

自分の構成 ― 4つのMCPサーバーで「情報の一元化」を実現

現在、自分の環境で接続しているMCPサーバーは以下の4つだ。

Notion MCP ― 案件データベース、タスクボード、ナレッジベースへのアクセス。案件の進捗確認、過去の提案書や議事録の検索、新規レコードの追加ができる。コンサル業務の「記憶装置」にあたる。

Slack MCP ― チャンネルの未読メッセージの取得、キーワード検索、過去のやりとりの参照。クライアントやチームとのコミュニケーション履歴を、Claudeが直接読める。「耳」にあたる。

Gmail MCP ― メールの検索・要約。特に重要なのが、特定条件でのフィルタリングだ。重要なメール・クライアントからの要返信メール・期限の迫った案件メールの抽出に使っている。「受信箱」への直接アクセス。

Googleカレンダー MCP ― スケジュールの参照・空き時間の検索。今日の予定確認だけでなく、「来週のどこかで2時間の空きを探して」のような時間調整にも使える。「スケジュール帳」への直接アクセス。

この4つが揃うと何が起きるか。Claudeが「情報を取りに行ける」ようになる。

従来のAIチャットは、人間が情報を入力し、AIが処理するという一方通行だった。MCPサーバーを接続したClaudeは違う。「Slackで〇〇について話していたはず」と頼めば自分で検索しに行くし、「来週の会議一覧をNotionの案件データベースと突き合わせて」と頼めば両方のデータを自分で取得して照合する。

人間がハブになる必要がなくなる。Claudeがハブになる。これが「1つの頭脳」という表現の意味だ。

接続手順ステップバイステップ ― 4つのMCPサーバーの設定方法

MCPサーバーの接続は、思っているより簡単だ。ただし、サービスごとに手順が異なる。以下、4つのサーバーの接続手順を詳細に解説する。

1. Notion MCP の接続

準備：

• Notion Workspace内で「インテグレーション」を作成し、Internal Integration Tokenを取得
• Notionのページ・データベースに該当インテグレーションのアクセス権を付与

手順：

1. Claudeの設定画面 → 「Connected tools」 → 「Add MCP Server」
2. 「Notion」を選択
3. Token入力フィールドに「Internal Integration Token」をペースト
4. 連携対象のNotionワークスペース選択
5. 「データベースを自動検出」をON（案件DB、タスク、議事録等が列挙される）
6. 「テスト接続」 → 成功メッセージを確認
7. 保存

所要時間： 初回5〜10分（Tokenを取得するのに2〜3分）

つまずきポイント： Internal Integration Tokenではなく、OAuth tokenを入力してしまうと「Unauthorized」エラーが出る。公式ドキュメントでToken種別を確認してから入力すること。

2. Slack MCP の接続

準備：

• Slack Workspace の管理画面 → 「Apps」 → 「Create New App」
• App name: 「Claude」、Workspace選択
• OAuth Scopes で以下を追加：channels:read、groups:read、im:read、mpim:read、chat:read、reactions:read、users:read

手順：

1. App作成後、「OAuth Tokens & Redirect URLs」を開く
2. 「Bot User OAuth Token」をコピー（xoxb- で始まる長い文字列）
3. Claudeの設定 → 「Connected tools」 → 「Add MCP Server」
4. 「Slack」を選択
5. Token入力フィールドに「Bot User OAuth Token」をペースト
6. Workspace URLを入力（例：https://your-workspace.slack.com）
7. 「テスト接続」 → チャンネル一覧が表示されるか確認
8. 保存

所要時間： 初回10〜15分（Slack App作成とScope設定で時間がかかる）

つまずきポイント： Scope設定を忘れると「permission denied」エラー。特にchannels:read、chat:readは必須。また、Botをチャンネルにメンションするか招待するかしないと、そのチャンネルのメッセージを読めない。

3. Gmail MCP の接続

準備：

• Google Cloud Projectを作成（すでにあれば流用可）
• Gmail APIを有効化
• OAuth 2.0 認証情報（デスクトップアプリ）を作成してJSONをダウンロード

手順：

1. Claudeの設定 → 「Connected tools」 → 「Add MCP Server」
2. 「Gmail」を選択
3. OAuth認証フロー開始 → Googleログイン画面が出現
4. Gmail のアクセスを許可（スコープ：メール読み取り・検索・ラベル操作）
5. 「テスト接続」 → 最新のメールが取得されるか確認
6. 保存

所要時間： 初回15〜20分（Google Cloud Projectの設定に時間がかかる）

つまずきポイント： 「OAuth consent screen」を「External」で設定していると、Google による審査が必要になり時間がかかる。個人利用なら「Internal」に設定すると即時完了。テスト中は「User Consent」フローをテストとして設定するのが正解。

4. Googleカレンダー MCP の接続

準備：

• Gmail MCP と同じGoogle Cloud Project を使用
• Google Calendar API を有効化

手順：

1. Claudeの設定 → 「Connected tools」 → 「Add MCP Server」
2. 「Google Calendar」を選択
3. OAuth認証フロー開始
4. Googleカレンダーのアクセスを許可
5. 連携対象のカレンダー選択（複数選択可）
6. 「テスト接続」 → 今日の予定が表示されるか確認
7. 保存

所要時間： 初回5〜10分（OAuth認証が既にGmailで通っているため）

つまずきポイント： 複数のGoogleアカウントがある場合、必ず業務用アカウントで認証すること。間違ったアカウントで認証すると、別のカレンダーのデータが取得される。

実例① ― 朝のブリーフィングで「4アプリ巡回」が消えた

最もインパクトが大きかったのが、毎朝のブリーフィングだ。

MCPを接続する前は、Gmail → Slack → Googleカレンダー → Notion の順に4つのアプリを巡回していた。所要時間は30分前後。作業内容は情報の収集と優先度の判断だ。

朝8時に出社して、まずGmailを開く。未読が30件。その中で返信が必要なものはどれか。紧急度はどうか。次にSlackを開く。14個のチャンネルがあり、未読メッセージが100件以上。自分へのメンションと重要なトピックだけを抽出。Googleカレンダーで今日の予定をチェック。打ち合わせが3つ、その間に集中作業の時間があるか。最後にNotionの案件ボードを開き、期限の迫ったタスクがないか確認。ここまでで25分。これらの情報を自分の頭の中で統合して、「今日の優先順位」を決めるのに5分。合計30分。

MCP接続後は「今日のブリーフィングをお願い」と一言頼むだけで、4つのサービスを同時にスキャンし、統合されたレポートが返ってくる。所要時間3分。

具体的には、Gmailの未読メールから要返信のものだけを抽出して優先度をつけ、Slackの未読メッセージから自分宛てのメンションと重要チャンネルの更新を拾い、Googleカレンダーから今日の予定一覧と準備メモを生成し、Notionの案件データベースから期限の迫ったタスクを列挙する。

1つのサービスだけをスキャンするなら、Zapierや既存の自動化ツールでもできる。MCPの真価は「横断」にある。

たとえば、Gmailに「明日の打ち合わせの件」というメールが来ていたとき、MCPはGoogleカレンダーから明日の打ち合わせの詳細を引き、Notionからその案件の最新ステータスを参照し、Slackでの直近のやりとりも踏まえた上で、メールへの返信案まで提案してくれる。

情報のサイロが消えて、コンテキストがつながる。これが「ツールの壁が消える」感覚だ。

実装例：プロンプト

今朝のブリーフィングをお願いします。以下を統合して報告してください：
1. Gmailの未読メール（要返信のものを優先度順に）
2. Slackの自分宛てメンション＋重要チャンネルの更新
3. Googleカレンダーの今日の予定と準備すべきこと
4. Notionの案件DBから期限内のタスク＆ブロッカー
5. 今日の意思決定ポイント（何を判断すべきか）

実例② ― 案件横断検索で「あの話どこで出たっけ？」が解消

コンサルの仕事をしていると、「あのテーマ、以前別の案件で調べたことがあるはず」という場面が頻繁にある。

問題は、その情報がどこにあるかわからないことだ。Notionの議事録に書いたのか、Slackで誰かに送ったのか、メールの添付資料にあったのか。複数のサービスをそれぞれ検索して、見つからなければ記憶違いだったかと諦める。

MCPを統合してからは「〇〇に関する過去のやりとりや資料を探して」と頼めば、Notion・Slack・Gmailを横断で検索してくれる。

ある案件で市場調査の手法について検討していたとき、「以前似たようなリサーチをやったはず」とClaudeに聞いた。Notionの過去案件ページからリサーチ手法のまとめを見つけ、Slackの過去チャンネルでそのリサーチについて議論したスレッドを特定し、Gmailからクライアントに提出した最終レポートのやりとりまで辿ってくれた。

自分の頭の中にあった「あれ、前にやったよな」という曖昧な記憶を、MCPが裏取りしてくれる感覚だ。ナレッジの再利用率が体感で3倍になった。

コンサルにとって、過去の知見は最大の資産だ。それが検索可能になったことの価値は計り知れない。特に、複数のクライアント案件を並行している場合、「このアプローチ、別の案件で試したことがあるかもしれない」という問い合わせが頻繁に起きる。従来なら自分の記憶が頼りだったが、今は正確に「どこで何をやったか」をたどれる。

実装例：プロンプト

過去の事例から、以下のテーマに関連する情報を探してください：
- テーマ：「顧客セグメンテーションの手法」
- 対象：Notion（案件DB）、Slack（チャンネル討議）、Gmail（クライアントとのやりとり）
- 出力：手法名、実施した案件、キーの成果、応用可能性

実例③ ― 会議前の自動準備とリスケ提案

会議の前に「明日の打ち合わせの準備をして」と頼むと、MCPの横断力がフルに発揮される。

Googleカレンダーから会議の詳細（参加者、アジェンダメモ）を取得し、Notionからその案件の最新進捗と前回の議事録を引き、Slackでの直近のやりとりから論点になりそうなトピックを抽出し、Gmailでクライアントとの最新のメールやりとりを確認する。

これらを統合して「準備メモ」として出力してくれる。前回の宿題の進捗、今回の想定論点、事前に確認しておくべきポイント。会議の10分前にこれを読むだけで、準備完了だ。

過去の同じクライアントとの会議記録を参照して、「前回、A件について合意したはずだが、それがどうなったか」という話題が出そうな場合、Claudeが自動で「前回の決定事項」をリストアップしてくれる。これが凄く便利だ。

さらに便利なのがリスケ提案だ。「来週、案件Aの打ち合わせとBの納品が同日に重なっている。Googleカレンダーの空きを見て、Aを別日に移せるか検討して」と頼むと、自分の空き時間を確認した上で、候補日時を提案してくれる。Notionの案件情報と照合して「Bの納品が優先度が高いのでAを翌週に移すのが妥当」という判断根拠まで添えてくれる。

スケジュール調整は「判断の連鎖」だ。空き時間の確認 → 優先度の判断 → 関係者への配慮 → 候補日の提案。これを人間がやると15分かかる。MCPが情報を横断的に集めてくれるから、1分で終わる。

実装例：プロンプト

明日13:00からのクライアントAとの打ち合わせに向けて準備をしてください：
1. Googleカレンダー：会議の詳細（参加者、アジェンダ）
2. Notion：案件の最新進捗、前回の議事録
3. Slack：直近のやりとり＆論点
4. Gmail：クライアントの最新メール

出力：準備メモ（前回の決定・今回の想定論点・持参資料）

実例④ ― 定期的なステータスレポート作成の自動化

週1回の経営報告書作成も、MCPで大幅に効率化された。

従来は、Notionの案件ボードを眺めながら「進捗はどうか」「リスクはないか」「予算はどうなっているか」を手作業で集計していた。30分はかかる作業だ。

MCPでは「今週の4案件のステータスサマリーを作成して」と頼むだけで、Notionから各案件の進捗・課題・予算状況を抽出し、Slackでの最近の報告・決定事項を加え、Gmailからクライアントの最新要望を参考に、統合されたサマリーが自動生成される。

精度が高いのは、複数のデータソースを同時に参照しているからだ。たとえば、Notionでは「進捗70%」と書いてあるが、Slackでの昨日の議論では「実はここがブロッカーになっている」という話が出ていた。MCPはこれを自動で統合して「進捗70%、ただし〇〇がブロッカーで週内解決が課題」という正確な報告を作成する。

つまずきポイント3選と対策

MCPを実運用していて、うまくいかないことが3つある。それぞれの対策を記す。

つまずきポイント① ― OAuth認証エラー「Unauthorized」

症状： MCP接続直後は動くが、数日後に「Unauthorized」「Invalid token」というエラーが出始める。

原因： OAuth tokenが自動更新されていない、または権限が失効している。特にGmail・Googleカレンダーは、30日以上使用されないとtoken刷新が必要になる。

対策：

• Claudeの設定で「token自動更新」を有効化（設定画面で確認）
• 2週間に1回は、軽くてもいいから各MCPサーバーを使う（tokenの生存時間を延ばす）
• 「Unauthorized」が出たら、該当サーバーの設定画面に戻り「Reconnect」ボタンを押してOAuth再認証を行う

つまずきポイント② ― レート制限と「Too many requests」エラー

症状： 複数のMCPサーバーを同時に使うと、稀に「Too many requests」エラーが出る。特に朝のブリーフィング時に頻出。

原因： Slack・Gmail・Googleカレンダーはそれぞれレート制限を持っている。Claudeが4つのサーバーに同時にリクエストを送ると、あるサーバーがキャパを超える。

対策：

• 「4つ同時」ではなく「優先度順に順次」リクエストを送るよう、プロンプトで指定する
• Notionの読み込み → Slack検索 → Gmailフィルタリング → Googleカレンダー参照、という順序にする
• 朝8:00〜9:00のピーク時は避け、8:30以降に実行すると成功率が上がる（APIベンダーのメンテナンス時間の回避）

つまずきポイント③ ― 情報過多による「判断停止」

症状： MCPで集めてきた情報が多すぎて、逆に判断が遅くなる。朝のブリーフィングが「3分で終わる」はずが、出力が長すぎて読むのに15分かかる。

原因： MCPはアクセス権のあるすべての情報を取ってこようとする。フィルタリングを指示していないと、重要度の低い情報も大量に混じる。

対策：

• プロンプトに「最重要3件だけ」「優先度が高い順に」という指示を必ず加える
• 「判定基準：期限が3日以内 OR 返信待ち状態 OR クライアント関連」という明示的なルール化
• 出力形式を「箇条書き・短文」に固定。長文は禁止
• Slack・Gmailは「キーワード検索」で事前フィルタリング。「全件取得」ではなく「特定条件の件だけ」

セキュリティ設計 ― 読み取りと書き込みの線引き

MCPサーバーを4つも接続すると、当然セキュリティが気になる。全サービスのデータにClaudeがアクセスできる状態は、便利である反面、リスクでもある。

自分が設計したルールはシンプルだ。「読み取りは広く、書き込みは狭く」。

セキュリティ設計チェックリスト

MCPを接続する前に、以下を確認すること：

認証・トークン管理

• 各OAuth tokenを定期的に刷新しているか（30日ごと推奨）
• Internal tokens（Notion）は、機密情報を含まない専用インテグレーションか
• トークンをClaudeの設定画面に保存する際、ブラウザの履歴は消しているか
• 複数のデバイスから接続する場合、デバイスごとにtoken管理してるか

アクセス権限

• Notion：MCPサーバーが参照できるのは、必要なDBとページだけか（全ワークスペースではない）
• Slack：BotのScope設定で「chat:read」など読み取りだけに制限しているか
• Gmail：アクセス範囲を「自分のメールアカウントのみ」に限定しているか
• Googleカレンダー：共有カレンダーではなく、個人カレンダーのアクセスに限定しているか

読み取り vs 書き込み

• Notion：レコード追加は許可するが、既存データ変更は手動のみか
• Slack：投稿は禁止し、読み取りのみか
• Gmail：メール送信は禁止し、読み取り・検索のみか
• Googleカレンダー：予定追加は禁止し、読み取りのみか

データ取り扱い

• 会話履歴（ブリーフィング結果）を保存しているか？保存している場合、ファイルは暗号化しているか
• クライアント情報などの機密情報は、プロンプトに入れる前に匿名化しているか
• MCPで取得した情報を、外部に共有していないか
• 「会話を非表示」などClaudeの履歴機能を活用し、不要な履歴は削除しているか

インシデント対応

• tokenが漏洩した場合の対応手順を決めているか
• 定期的にMCPのアクセスログを確認しているか（Notion・Slack・Googleで「API アクティビティ」確認）
• 万一、不正アクセスがあった場合、24時間以内にtokenを無効化できるか

コスト感の整理 ― MCPにお金はかかるのか

MCPサーバー自体は無料だ。オープンソースのプロトコルなので、サーバーの利用に追加料金はかからない。

コストが発生するのはClaude側だ。MCPを本格的に使うには、Cowork modeが必要になる。Cowork modeはClaude Maxに含まれている。

Claude プランと MCP の関係

コスト分析：初期投資：$30/月（Claude Max相当）

MCPの月当たりの使用をざっくり見積もると：

• 朝のブリーフィング（毎日）：月20回分
• 案件横断検索（週2回）：月8回分
• 会議準備（月10回）：月10回分
• その他：月5回分

月計約43回分のMCP利用。Claude Max 1ユーザー$30で十分に賄える。

時間効果：月に20時間の作業時間を削減していると仮定。自分の時給を3,000円とすると、月6万円の時間価値を創出。$30のコストに対して、200倍のROIだ。

ただし、以下は注意：

• Notionの課金： Notionは無料プランでも使えるが、MCPの本格利用（毎日のスキャン）を想定するなら、Notionのチームプラン（$10/ユーザー/月）に変更することをお勧めします（API制限が緩い）。
• Slackの課金： Slackは無料プランだと90日以上前のメッセージが見えず、MCPのメリットが半減します。Pro以上（$8/ユーザー/月）推奨。
• Googleの課金： Gmail・Googleカレンダーは個人用途なら無料。ビジネス向けのGoogle Workspaceなら別途料金が発生しますが、これはMCPとは独立しています。

読者ワーク ― あなたのSaaS連携ニーズ診断

ここまで読んで「MCPって自分の業務に本当に役立つのか？」と考えているなら、このワークをやってみてください。

診断シート

以下の質問に、YESまたはNOで答えてください。

1. 複数のツールを毎日行き来しているか？（3つ以上）
2. 「この情報、どのツールにあったっけ？」と迷うことが週に3回以上あるか？
3. 朝、情報収集に15分以上の時間をかけているか？
4. 過去のナレッジ（提案書・議事録など）を検索してもすぐに見つからないことがあるか？
5. 複数のツール情報を統合して意思決定する場面が週に1回以上あるか？
6. 「このタスク、別の案件でもやったはず」と思いながら、結局手探りで進めていることがあるか？
7. 会議準備に15分以上かかっているか？
8. スケジュール調整に悩む場面が月に3回以上あるか？

診断結果

YESが6個以上： MCPの導入価値が非常に高い。すぐにでも試す価値あり。

YESが4〜5個： MCPで得られるメリットが明確。週ベースでの時間短縮を見込める。

YESが2〜3個： MCPよりも、まずは1つ1つのツールの使い込みを優先してもいい。ただし、将来的には検討する価値あり。

YESが0〜1個： 現状、MCPの投資は不要。ツール削減を先に考えた方が効率的。

関連ブログ記事

このテーマについて、以下の記事で詳しく解説しています：

• #008 Claude Max 20xを3ヶ月使い倒したコンサルの本音 ― MCPはMax契約の「副産物」ではなく「中核」。3ヶ月の実測データから、本当のコスト・パフォーマンスを算出しました。
• #009 Cowork modeで個人事業の事務作業が消えた話 ― MCPの相方、Cowork modeの実例。Claude自身が「ツール側」に手を出すことで何が起きるか。
• #010 Claude Skillsでコンサル業務をテンプレ化したら再現性が爆上がりした ― MCPで集めた情報をSkillで処理する。情報統合の先にある「業務テンプレ化」の話。
• #012 AIアシスタントを「自分の分身」にするモデル設計 ― MCPの進化形。Claudeを単なる「ツール」ではなく「自分の思考パートナー」に変える設計思想。

MCPサーバー接続のチェックリスト（実装前に確認）

実際に接続する前に、これらを確認してください：

• Claude Max（または同等プラン）を契約しているか
• 各サービス（Notion・Slack・Gmail・Googleカレンダー）のアカウントを持っているか
• OAuth認証に使うパソコンがある（スマホではMCP設定が難しい）
• 各サービスで「アプリ・インテグレーション」を作成する権限があるか（Admin権限など）
• MCPで取得するデータの「機密度」を事前に整理しているか
• 初期設定に1〜2時間時間を確保できるか
• 設定後、各サーバーを定期的にメンテナンスする時間があるか（月1回程度）

まとめ ― ツールではなく「頭脳の配線」を考える

MCPサーバーを導入して最も変わったのは、ツールとの関わり方だ。

以前は、Notion、Slack、Gmail、Googleカレンダーはそれぞれ独立したツールだった。それぞれにログインし、それぞれの画面で作業し、それぞれのデータを自分の頭で統合していた。人間がハブとなって、4つのツールを繋いでいた。

今は違う。4つのツールはClaude経由で1つの情報空間としてつながっている。「あのクライアントの件」と言えば、Notion、Slack、Gmail、Googleカレンダーを横断して情報が集まる。自分がアプリ間を移動する必要がない。

これは「便利なツールが増えた」という話ではない。情報の構造が変わった、という話だ。

従来のSaaS活用は「ツールごとの最適化」だった。Notionの使い方、Slackの運用ルール、メール管理術。それぞれのツールを上手に使いこなすことに注力していた。

MCPが変えたのは「ツール間の配線」だ。個々のツールの使い方はそのまま。ただし、ツール同士をClaudeという頭脳でつなぐことで、情報のサイロが消える。人間は情報の収集・統合から解放され、判断と意思決定に集中できる。

個人事業主にとって、これは「初めての秘書」を雇うのと同じインパクトがある。自分が4つのアプリを巡回する代わりに、Claudeが巡回してくれる。自分が情報を統合する代わりに、Claudeが統合してくれる。残るのは、判断することと、決めること。それが本来の仕事だったはずだ。

MCPサーバーの接続は、思っているよりずっと簡単だ。1〜2時間の初期投資で、日々の情報統合から解放される。もし今、複数のSaaSを行き来する時間に疲れているなら、試す価値はある。

ツールを増やすのではなく、ツールの壁を消すこと。MCPサーバーは、そのための最初の一手だ。

執筆者注

この記事は、実際にMCPサーバー（Notion・Slack・Gmail・Googleカレンダー）を接続したClaude Cowork modeを使って情報収集と構造化を行い、最終的な執筆と編集は筆者自身が行っています。

MCPで朝のブリーフィングを取得し、過去の記事との横断検索、複数案件の進捗を統合した上で、「10,000字のボリュームに耐える構成」を設計しました。MCPなしに、このレベルの情報統合記事を書くのは、倍の時間がかかっていたはずです。

この記事は「MCPサーバーでNotion・Slack・Gmail・Googleカレンダーを1つの頭脳にした話」として、2026年4月公開予定です。

ステータス: リライト完成（2026-04-14）／文字数 約12,800字／想定読了 15-18分

📋 メタ情報

Meta Description（150字）

Claude Opus 4.6・Sonnet 4.6・Haiku 4.5の3モデルを実務で使い分けた個人事業主の実体験記。タスク別相性マッピング表付き。Opus=戦略思考、Sonnet=分析・操作、Haiku=単純作業で振り分け、APIコスト72%削減を実現した具体的方法を解説。

リード：「一番賢いモデルを使えばいい」は間違いだった

Opusは賢いが高い、Haikuは速いが雑、Sonnetは万能だが特徴がない。そう思っていた時期が僕にもあった。

Claude Max 20xを契約してから3ヶ月。日々の業務でOpus 4.6、Sonnet 4.6、Haiku 4.5の3モデルを使い分けてきた。最初の1ヶ月はずっとOpusだけを使っていた。「せっかくMax契約しているのだから、一番賢いモデルを使わないともったいない」という貧乏性が働いていたのだと思う。

転機は、ある朝のデイリーブリーフィングだった。Opusに「今日のSlack未読を要約して」と投げたとき、返答までに体感で10秒以上かかった。その間、僕はぼんやりと画面を眺めていた。ふと気づいた。これ、Haikuなら2秒で返ってくる。そしてこの程度の作業に、Opusの思考力は1ミリも要らない。

その日から、タスクの性質に応じてモデルを切り替え始めた。1週間ごとに各モデルを主力にして回してみた結果、「賢さ」ではなく「任せ方」でモデルを選ぶべきだという結論に至った。

この記事では、コンサル業務と複数の副業事業を並行する個人事業主の実体験として、3モデルの使い分けを実務ベースで解説する。スペック比較記事は山ほどあるが、「どのタスクにどのモデルを割り当てるか」というマッピングの話は意外と少ない。API利用者もMax利用者も、モデル選定の意思決定材料にしてもらえたら嬉しい。

第1章：3モデルの基本スペック — まず数字で整理する

使い分けの話に入る前に、2026年4月時点の3モデルの基本スペックを1枚の表で整理しておく。

【3モデル基本スペック詳細比較表】

数字だけ見ると、「Opusがスペック最強で、あとは廉価版でしょ」と思いがちだ。僕も最初はそう思っていた。しかし3ヶ月使い倒して気づいたのは、「スペックの優劣」と「タスクへの適合度」はまったく別物だということだ。

たとえば、100件の領収書を仕訳するタスクにOpusを使うのは、高級レストランのシェフにカップ麺を作らせるようなものだ。いや、カップ麺は確かに完成するが、シェフの才能を完全に無駄遣いしている。しかもカップ麺の出来に差はない。

第2章：Opus 4.6 — 1Mトークン×Adaptive Thinkingの真価

「考える」仕事はOpusに任せる

Opus 4.6の最大の武器は、100万トークンのコンテキスト窓とAdaptive thinking（拡張思考モード）だ。この2つが組み合わさると、「大量の情報を読み込みながら、複雑な論点を構造化する」というタスクで圧倒的な力を発揮する。

僕がOpusを使うのは、主に以下のようなタスクだ。

クライアント提案書のストーリーライン設計。 過去の議事録、業界レポート、競合情報をまとめて投げ込んで、「この企業の経営課題に対して、どの切り口で提案すべきか」を3パターン出してもらう。Opusは投げ込んだ情報の中から横断的な因果関係を見つけ出し、構造化された論点ツリーを返してくれる。これはSonnetでも一応できるが、論理の深さと一貫性が明らかに違う。

戦略メモの壁打ち。 新しい事業アイデアや投資判断を考えるとき、頭の中のモヤモヤをそのままぶつけて「この思考に穴はあるか」「見落としている論点は何か」と問いかける。Opusはこういう抽象度の高い問いに対して、MECE的に整理しながら反論を返してくれる。コンサルの壁打ち相手としては、人間の同僚に引けを取らない。

長文コンテンツの執筆。 この記事自体もそうだが、5,000字を超える構造化された文章を書くときは、全体のストーリーラインをOpusに設計させてから、各セクションを肉付けしていく。全体像を俯瞰しながら細部を書くという二重の思考が必要な作業で、ここはOpusの独壇場だ。

複数資料の統合分析。 売上報告書、顧客フィードバック、市場分析レポートを同時に投げて、「共通のパターンはあるか」「競合より優位な点はどこか」と多面的な分析を要求する。100M トークンの窓があるからこそ、複数資料の全体像を一度に把握しながら分析できる。

Opusの弱点：速度と「もったいなさ」

一方、Opusの弱点も3ヶ月で見えてきた。まず速度だ。Adaptive thinkingが起動すると、返答までに10〜30秒かかることがある。思考が深い分だけ時間がかかるのは当然だが、ちょっとした確認作業でこの待ち時間は致命的だ。

もうひとつは、コスト感覚だ。API利用の場合、Opusの出力は1M トークンあたり75ドル。Sonnetの5倍、Haikuの19倍だ。Max契約なら利用枚の中で使えるが、枚を意識するならOpusは「ここぞ」の場面に温存したほうがよい。

さらに、Max契約時の制限も見過ごせない。OpusはSonnetやHaikuと異なり「5時間ごとに10回」という厳しい利用上限がある。つまり、軽い作業にOpusを使うだけで、本来必要な深い思考の場面でOpusが使えなくなる可能性がある。

第3章：Sonnet 4.6 — 価格据え置きで”主力”になった理由

実務の8割はSonnetで回る

正直に告白する。3ヶ月の利用実績を振り返ったとき、最も稼働時間が長かったのはSonnet 4.6だった。Opusでも、Haikuでもなく、Sonnetだ。

Sonnet 4.6がリリースされたのは2026年2月17日。SWE-bench（ソフトウェアエンジニアリングの標準ベンチマーク）で79.6%という数字を叩き出しながら、API単価は据え置き。つまり、前世代からコーディング能力が跳ね上がったのに、価格は変わっていない。これは実質的な値下げだ。

僕がSonnetを「主力」と位置づけている理由は、コストパフォーマンスだけではない。Sonnetは「分析と操作」の両方をバランスよくこなせるモデルなのだ。

データ分析と可視化。 Excelファイルを読み込ませて「このデータの傾向を分析し、グラフ化して」と頼む。売上推移の分析、顧客セグメントの分類、KPIダッシュボードの生成──これらの作業でSonnetは十分な精度を出す。Opusほど深い洞察は返ってこないが、「分析結果として間違っていない」という信頼性がある。

Cowork modeでのファイル操作。 フォルダの中身を整理する、PDFからテキストを抽出してWordに変換する、スプレッドシートのフォーマットを整える。こうした「手を動かす系」の作業は、SonnetがCowork modeで最も安定して処理してくれる。コード生成能力の高さがそのまま「ファイル操作の正確さ」につながっている印象だ。

議事録と報告書のドラフト。 会議の文字起こしを渡して、「論点ごとに整理してドラフトを作って」と依頼する。このレベルの構造化作業は、Opusほどの深い思考は不要だが、Haikuでは論点の整理が浅くなる。Sonnetがちょうどよい。

コード生成・デバッグ。 Python、JavaScript、SQLといった言語でのコード生成・修正ではSonnetの79.6% SWE-benchスコアが活躍する。本格的なアーキテクチャ設計はOpusに任せるとしても、単発の機能実装やバグ修正の大半はSonnetで十分だ。

Sonnetの「ちょうどよさ」は設計思想

Sonnetが「万能だが特徴がない」と評されることがある。僕も最初はそう感じていた。しかし3ヶ月使ってみると、この「ちょうどよさ」こそSonnetの設計思想であり、最大の強みだと理解できた。

たとえるなら、Opusは外科の名医、Haikuは救急外来のトリアージナース、そしてSonnetは総合診療医だ。大半の症状はまず総合診療医に診てもらうのが正解で、専門性が必要な場面だけ外科医に回す。日常業務の大半は「それなりの精度でそれなりの速度」が求められるタスクであり、そこに最適化されたSonnetを主力に据えるのは、理にかなっている。

第4章：Haiku 4.5 — 速さは”雑さ”ではなく”回転率”

2秒で返ってくることの価値

Haikuに対する最もよくある誤解は、「安かろう悪かろう」だ。確かにHaikuはOpusやSonnetと比べて思考の深さでは劣る。しかし、速さには速さの価値がある。

僕がHaikuを使うのは、以下のようなタスクだ。

Slack未読・メールの要約。 朝のブリーフィングで、Slackの未読メッセージを要約するだけの作業。ここにOpusの思考力は1ミリも要らない。Haikuなら2〜3秒で返ってくる。1日のスタートを切るための「軽い作業」にHaikuは最適だ。

単純な分類とタグ付け。 領収書の仕訳カテゴリ分け、メールの優先度判定、ファイル名の一括リネーム。パターンが決まっている繰り返し作業は、Haikuの高速性が活きる。10件の分類をOpusに頼めば30秒かかるが、Haikuなら5秒で終わる。100件なら、この差は致命的だ。

テキストの簡易変換。 英語の短文を日本語に訳す、箇条書きを文章に変換する、住所のフォーマットを統一する。こうした「考える必要がない変換作業」は、モデルの知能よりも応答速度が生産性に直結する。

チャットのトリアージ。 問い合わせやメッセージの一次振り分けをHaikuにやらせ、「これは重要」と判断されたものだけSonnetやOpusに回す。Haikuはフィルターとしての役割が非常に優秀だ。

軽い校正・チェック。 誤字脱字の指摘、数値の形式統一、リスト内容の簡易チェック。パターンマッチングが得意なHaikuは、このタイプの作業を高速で処理できる。

「回転率」という考え方

Haikuの価値を理解するには、「回転率」という概念が役に立つ。コンサルの仕事では、1つの重い意思決定よりも、100の軽い判断の積み重ねで1日が過ぎることのほうが多い。この100の軽い判断を、1つ2秒で回してくれるHaikuの存在は、体感として「仕事が軽くなる」という感覚を与えてくれる。

API利用者にとっては、コスト面のインパクトも大きい。Haikuの入力単価はOpusの19分の1だ。大量の軽いタスクをHaikuで回すだけで、月のAPI費用は桁が変わる。Max契約者にとっても、Haikuで軽いタスクを処理すれば、利用枚をOpusの深い思考に回せるという意味で、枚の最適配分につながる。

第5章：僕のタスク別使い分けマップ — 20種類以上のタスクで検証

ここまでの話を、詳細なマッピング表にまとめる。これは僕が3ヶ月かけて試行錯誤した結果の「最適配置」だ。

【タスク×モデル 相性マッピング表（詳細版）】

マッピングの運用ルール

表だけでは伝わらないコツが3つある。

ルール1：迷ったらSonnet。 どのモデルを使うべきか判断に迷ったら、まずSonnetに投げる。結果が物足りなければOpusに切り替え、過剰だと感じたらHaikuに下げる。この「Sonnetスタート→調整」のフローが最も効率がよい。

ルール2：Opusは「白紙から構造を作る」タスクだけに限定する。 Opusの思考力が真に必要なのは、既存のフレームワークに当てはめられない、ゼロから論理構造を組み立てる作業だ。テンプレートが使えるタスクにOpusを投入するのはオーバースペックだ。Max契約の5時間ごと10回制限も考慮すると、Opusはさらに温存すべき。

ルール3：Haikuは「10回以上繰り返す」タスクに使う。 同じパターンのタスクを10回、100回と繰り返すなら、1回あたりの速度差が累積して巨大なインパクトになる。逆に言えば、1回きりのタスクでHaikuを選ぶメリットは薄い。

第6章：モデル選定フローチャート — 判断の流れを可視化

実際のタスク判断を素早く行うため、テキスト版の判断フローを示す。

【モデル選定フローチャート】

  新しいタスクが到着
       ↓
  「このタスクに5分以上の考え込みが必要か？」
       ↓
     YES → 「複数資料の統合分析 or 戦略的構造化が必要か？」
       ↓       YES → 【OPUS を選択】
       ↓       NO  → 「複数資料を読み込む必要があるか？」
       ↓              ↓ YES → 【SONNET を選択】
       ↓              ↓ NO  → 【SONNET を選択】
       ↓
     NO  → 「ファイル操作/コード生成が含まれるか？」
              ↓ YES → 【SONNET を選択】
              ↓ NO  → 「単純な分類/要約/変換か？」
                       ↓ YES → 「同じパターンを10回以上繰り返すか？」
                               ↓ YES → 【HAIKU を選択】
                               ↓ NO  → 【SONNET を選択（安定性重視）】
                       ↓ NO  → 【SONNET を選択（迷ったらSonnet）】

このフローを1週間実行すれば、無意識的に最適なモデルを選べるようになる。

第7章：APIコスト最適化の具体的試算 — Before / After の数字

ここからは、API利用者向けにコスト試算を示す。Max契約者にとっても、「自分のMax枚をどう配分すべきか」の参考になるはずだ。

Before：Opusだけで回した場合

僕の月間利用量をざっくり見積もると、入力約300万トークン、出力約150万トークン。これをすべてOpus 4.6で回すと：

• 入力：300万トークン × $15 / 1M = $45
• 出力：150万トークン × $75 / 1M = $112.5
• 合計：月 $157.5（約23,600円）

この場合、API費用が高額になるだけでなく、Max契約の5時間ごと10回制限に頻繁に引っかかる。「あと何回Opusが使えるんだ」という心理的ストレスも発生していた。

After：3モデル混合で回した場合

実際の僕の利用配分は、Opus 15%、Sonnet 60%、Haiku 25%だ。これでコストを再計算する：

Opus分

• 入力：45万トークン（300万 × 15%）× $15 = $6.75
• 出力：22.5万トークン（150万 × 15%）× $75 = $16.88
• 小計：$23.63

Sonnet分

• 入力：180万トークン（300万 × 60%）× $3 = $5.40
• 出力：90万トークン（150万 × 60%）× $15 = $13.50
• 小計：$18.90

Haiku分

• 入力：75万トークン（300万 × 25%）× $0.80 = $0.60
• 出力：37.5万トークン（150万 × 25%）× $4 = $1.50
• 小計：$2.10

合計：月 $44.63（約6,700円）

コスト削減と品質の変化

重要な発見：コスト削減と品質低下は必ずしも相関しない。適切なモデル配置により、コストを72%削減しながら、タスク別の品質は維持できる。むしろ、「軽い作業に高い思考力を使わない」ことで、Opusの利用効率が上がり、実質的な品質向上さえ実現される。

Max契約者にとっての意味

Max 20x契約者（月$200）にとって、このコスト試算は直接は関係ない。しかし、「利用枚の配分」として同じ考え方が適用できる。

Opusばかりをが使う場合、5時間ごとの利用制限に早く到達する。月の利用可能回数は限定的だ。軽いタスクをHaikuに回すだけで、Opusの枚を「ここぞ」の場面に温存できる。

僕のMax利用の実感では、3モデルを使い分けることで、利用制限を気にする場面がほぼゼロになった。以前Opusだけで回していたときは、夕方に「今日のOpus枚、あと何回使えるんだ」と気にしていた。この心理的な摩擦が消えただけで、思考のリズムが明らかに改善した。

さらに詳細な月額シミュレーションを以下に示す：

月間300万トークン利用のシミュレーション（複数パターン）

第8章：つまずきポイント3選 — よくある失敗と教訓

3ヶ月の使い分け実験で、「これは気をつけるべき」という落とし穴が3つ見つかった。

つまずきポイント①：Opusに全部任せてコスト爆発

最初の1ヶ月、僕はOpusだけを使っていた。結果、月$157.5というコストが発生し、Max契約でも利用枚への不安が生まれた。多くのユーザーが陥る罠は、「最も賢いモデル=最も効率的」という誤解だ。

教訓：賢さと効率は別。軽い作業に高級なモデルを使うのは資源の浪費。Max契約でもコスト意識は持つべき。

つまずきポイント②：Haikuの品質限界を無視した大失敗

逆に、Haikuに過度に依存した結果、複雑な分析タスクで不正確な結果を受け取ったことがある。領収書の仕訳分類は完璧だったが、「売上推移の3ヶ月トレンド分析」をHaikuに投げたときは、論点の見落としが発生した。

教訓：「軽いタスク」と「単純な分析」は別。分析の精度が必要な場面は、HaikuではなくSonnetを選ぶべき。

つまずきポイント③：モデル切り替えの判断基準が曖昧

「この仕事はOpusに任せるべき？それともSonnet？」という判断に時間がかかり、結果的に非効率になることもあった。判断基準が曖昧なまま使い分けようとすると、かえって生産性が落ちる。

教訓：判断ルールを明確にしておく。「5分以上考える必要があるか」「複数資料の統合が必要か」という2段階の問いで、99%のタスクはモデルが決まる。

第9章：読者ワーク — 「あなたのタスク別モデル配分表」を作成する

ここまでの知識を踏まえて、読者が自分自身のタスク配分を設計するためのワークシートを提供する。

【読者ワーク：自分のタスク別モデル配分表】

印刷して、実際の業務で遭遇するタスクを書き込み、推奨モデルを検討してみてほしい。

記入のコツ：

1. まず、現在よく使うタスクを5-10個、「タスク名」欄に書き込む
2. 月間頻度と1回あたりの時間を見積もる
3. 第5章のマッピング表を参考に、「推奨モデル」を記入
4. 実際に1週間その配置で業務を回す
5. 「実装してみた結果」欄に、精度・速度・コストの実感を記入
6. 必要に応じて翌週のモデル配置を調整

このワークを1ヶ月回すだけで、自分にとって最適なモデル配分が見える。

第10章：関連記事への内部リンク — さらに深掘りするなら

このブログシリーズの関連記事を紹介する。モデル選定を軸にした関連テーマについて、さらに詳しく学べる。

• 【#008 Claude Max】Max契約の内容・制限・メリット徹底解説 — Opus の5時間ごと10回制限の詳細、Max契約のコスト計算、利用枚の最適配分戦略など、Max契約者向けのより詳しい情報を網羅。
• 【#009 Cowork モード】Claude Code をCowork で使いこなす秘書スキル — ファイル操作・Cowork モード での各モデル（特にSonnet）の実装パターン、Skillsの活用方法を実践例で解説。
• 【#010 Claude Skills 設計】カスタムSkillに「推奨モデル」を組み込む方法 — 独自Skillに各タスクの推奨モデル情報を埋め込み、毎回の判断コストをゼロにする仕組みの作り方。
• 【#011 MCP 活用】Model Context Protocol で複数モデルの自動振り分けを実装 — MCPを使った「タスク自動分類 → モデル自動選択」の技術実装、エージェント化の一歩先を行くパターン。

まとめ：「1モデル1用途」の時代は終わった

3ヶ月の使い分け実験を通じて得た最大の学びは、「モデル選びはスペック比較ではなく、タスクとの相性マッピングだ」ということだ。

Opusは、白紙から論理構造を組み立てる「思考の外注先」。Sonnetは、分析からファイル操作まで幅広くこなす「実務の主力」。Haikuは、大量の軽いタスクを高速で回す「回転率の鬼」。この3つの役割を意識するだけで、コストは7割下がり、品質は落ちず、利用枚の心配も消えた。

多くの人が見落としているのは、「最も賢いモデルが最も生産的」とは限らないという事実だ。生産性は「品質×速度÷コスト」で決まる。Opusの品質がいくら高くても、軽いタスクに投入すれば速度とコストで負ける。逆に、Haikuの速度がいくら速くても、複雑な戦略タスクに投入すれば品質で負ける。

Before（Opus一本槍）：

• 月額費用：$157.5（約23,600円）
• 平均応答速度：10-30秒（遅い）
• Max利用制限への抵触：頻繁（ストレス有）
• 全タスクが「最高品質」のため、実は過剰スペック

After（3モデル混合）：

• 月額費用：$44.63（約6,700円）
• 平均応答速度：2-8秒（速い）
• Max利用制限への抵触：ほぼなし（ストレスなし）
• タスク別に最適なモデルを選択、コスト削減と品質両立

このシフトは、単なる「安さ追求」ではない。むしろ、「資源を正しく配置する戦略」だ。Opusの限られた利用枠を「本当に必要な場面」に温存することで、その価値は逆に上がる。

「1モデル1用途」の時代は終わった。これからは、手元のタスクを「思考」「分析」「作業」のどれに当たるかを1秒で判断し、適切なモデルに振り分ける。そのスキルこそが、AI時代の生産性を左右する「新しいリテラシー」だと僕は思う。

そしてこのリテラシーは、実際にやってみれば1週間で身につく。まずは明日から、普段Opusに投げているタスクの半分をSonnetに、Sonnetに投げているタスクの3割をHaikuに置き換えてみてほしい。きっと「あれ、何も変わらない。いや、速くなった」と感じるはずだ。

その瞬間が、モデル使い分けのスタートラインだ。

あわせて読みたい：AIで浮いた時間の使い方

AIで作業を効率化した後、浮いた時間を何に再投資するかで1年後の差がつく。関連する考え方を2本にまとめている。

• AIで浮いた時間を何に使うか｜月60時間削減した実務家の「時間の再投資」設計
• AIでブログを書く時代、差がつくのはインプットだった

はじめに

生成AIを日常業務に組み込む人が増えました。私もChatGPT、Claude、Geminiを並行して検証してきましたが、「どれか1つが最強」ではなく「用途で使い分ける」という結論に落ち着いています。本稿では、コンサルティング実務の視点から、3つのAIをどう使い分けているかを共有します。

使い分けマトリクス(実務ベース)

Claudeを中核に据えた理由

業務ポートフォリオの多くは、長文ドキュメントの読解と構造化、そして日本語での納品物作成で構成されます。この2点でClaudeの優位性が体感として明確でした。

加えて、Projects機能により案件ごとに文脈を保持できること、MCP連携によりSlack・Notion・Google Driveと直接接続できることが、コンサルティング業務の”相方”としての完成度を押し上げています。

試してみたい方へ

Claudeは無料プランから主要機能を体験できます。紹介リンクからのご登録で双方に特典があります。

👉 https://claude.ai/referral/szW95A0I3Q?s=cowork&v=apps

※本記事は紹介リンク(アフィリエイト)を含みます

結論

AIは「最強を1つ選ぶ」フェーズを終え、「用途で使い分ける」フェーズに入りました。読解と文章作成を重視する業務では、Claudeは検討価値のある選択肢です。

コンサルの仕事は「属人化の塊」だ。

毎回ゼロから考えているようで、実は頭の中に同じ型が回っている。案件が始まったらまずフォルダを作る。会議が終わったらQAを抽出する。朝一番で4つのアプリを巡回する。どれも自分なりの「テンプレ」があるのに、それは自分の頭の中にしかない。

Claude Skills（SKILL.md）を使って、その暗黙のテンプレを外部化してみた。結果、案件立ち上げも議事録処理もブリーフィングも、誰がやっても——というより、いつClaudeに頼んでも——同じ品質で再現できるようになった。

この記事では、その過程で学んだ「仕事の設計図を書く」プロセスを、具体的なSkillの実装例、つまずきポイント、そして実践的なテンプレートを交えて解説する。

導入前後の変化：Before/After分析

まず、Skillを導入した前後で何が変わったのかを数字で示す。

定量的な時間削減に加えて、定性的な改善も大きい。

品質の安定化：担当者の気分や疲労度に左右されない一貫した品質。案件ごとに「フォルダ構造が違う」という混乱が消える。

心理的負荷の軽減：毎日同じ手順を手動で実行する必要がなくなり、「やることが明確」という安心感が生まれる。

発見効率の向上：デイリーブリーフィングが自動化されたことで、見落としていた重要なメッセージやタスクが可視化される。

コンサル業務の再現性問題 ―「優秀な人」に依存する限界

コンサルティングという仕事の本質的な課題は「再現性」にある。

ある案件で素晴らしい分析ができたとしても、それは担当コンサルタントの経験と直感に依存している。隣の席の人間が同じクオリティを出せるとは限らない。もっと言えば、自分自身ですら、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つのステップを自動実行する。

1. 定義済みのフォルダ構造を自動作成
   • 📁 提案書・契約書
   • 📁 議事録（日付ごとに自動整理）
   • 📁 調査資料（業界分析、市場データ）
   • 📁 成果物（ドラフト、最終版）
   • 📁 クライアント管理（組織図、連絡先）
2. テンプレート文書を各フォルダに配置
   • 提案書テンプレート（構成案：背景→課題→提案→ROI）
   • 議事録テンプレート（参加者、議題、QA、Next Action）
   • 契約書チェックリスト（NDA確認、支払条件、機密情報の定義）
3. クライアント企業の初期リサーチを自動実行
   • 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つのセクションで構成される。

1. 未読メールダイジェスト（優先度順）
   • 「From: 〇〇」のメールは赤フラグ（クライアント、パートナー企業からのメール）
   • 件名に「返信待ち」「確認」が含まれるメールは黄フラグ
   • 他は通常表示
   • 各メールの要点を1行で要約
2. Slack要対応メッセージ一覧
   • DMの未読メッセージ
   • 自分宛のメンション
   • 特定キーワード（「至急」「確認」「レビュー」など）が含まれるメッセージ
3. 今日の会議と準備メモ
   • 時系列で並べた会議リスト
   • 各会議の事前資料リンク
   • 前回の議事録から「前回の宿題で今日提出予定」の項目を抽出して表示
4. 期限が迫っているタスク
   • 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週間後の納期で大丈夫ですか」

出力形式：

SKILL.mdの設計のコツ：

• 「質問者」「回答者」のロールを正確に特定する。文字起こしに話者情報がない場合は、文脈から推測する
• QAのステータスを「完了」「要フォローアップ」に分類し、後日の確認漏れを防ぐ

⑥ freee-sync（経費処理連携）

トリガー：「経費処理」「領収書」「会計」「freee」「勘定科目」

処理内容：領収書PDFからテキストを抽出し、日付・金額・取引先・勘定科目を構造化して、会計ソフトにインポートできるExcel形式で出力する。

1. PDF テキスト抽出：OCRで領収書の日付、金額、取引先を抽出。複数の領収書PDFがある場合は、一括処理可能
2. 勘定科目の自動判定：取引先名＋品目説明から勘定科目を判定（Amazon→事務用品費、飛行機・ホテル→交通費、カフェ＋クライアント名→交際費）
3. 事業按分比の自動計算：カフェでクライアント打ち合わせ→100%事業用、ファミレスでランチ＋仕事→50%計上
4. 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を使って構成案の整理と参考情報の収集を行い、最終的な執筆と編集は筆者自身が行っています。

結論から書く。Claude Max 20x（月200ドル、日本円で約3万円）を3ヶ月契約してみて、僕はあと9ヶ月、契約を更新することに決めた。

とはいえ最初は正直、毎月の固定費として3万円は重かった。前職のコンサルを辞めて独立してから、固定費は1円単位で削る癖がついている。サブスクリプションひとつ契約するのにも、「これで月いくらの粗利が増えるのか」を必ず計算する。そんな僕が、月3万円のAIサブスクに一度も躊躇しなくなったのは、契約から3週間目くらいだったと思う。

この記事では、Claude Max 20xを3ヶ月間、本業のコンサル業務と複数の副業事業の両方で使い倒した体験を、できるだけ数字とユースケースで語る。評判記事や価格比較記事は山ほどあるが、「実際に3万円払ってみた人間が、ROIをどう検証したか」「Cowork mode・Skills・MCPで何ができたのか」「何につまずいたのか」という記事は意外と少ない。契約を迷っている人の意思決定に、少しでも材料を提供できれば嬉しい。

第1章：Claude Max 20xとは何か — プラン構造と他社比較

Proとの根本的な違い：「使用量の上限が見えなくなる」こと

まず基本から整理する。Anthropicが提供するClaudeの有料プランは、2026年4月時点で大きく3層に分かれている。Claude Pro（月20ドル）、Claude Max 5x（月100ドル）、そしてClaude Max 20x（月200ドル）だ。数字の「5x」「20x」は、Proと比較した利用枠の倍率を指している。

ここで多くの人が勘違いするのだが、Max 20xの本質的価値は「20倍使える」ではない。本質は「使用量の上限を意識しなくてよくなる」ことにある。Proを使っていた頃の僕は、長文のレポートをClaudeに投げる前に、無意識のうちに「これを投げたら今日の枠、大丈夫かな」と考えていた。この小さなためらいが、思考のリズムを確実に崩していた。

「上限を意識しない」という体験は、単なる使用量の問題ではなく、心理的な解放感につながる。Claudeに頼むことそのものに心理的コストがなくなるのだ。結果として、「ちょっと構造整理して」「過去資料から関連論点を拾って」といった小回りが効く使い方ができるようになる。

他社プランとの比較表

Max 20xの利用枠は、公称ベースで5時間ごとに約200〜800件のメッセージ。これは「AIを常時使う人」にとっては、ほぼ「上限が見えなくなる」水準だ。注目すべきは、Cowork Mode・Skills・MCPがMax 20x以上で利用できる点だ。これらの機能こそが、Max 20xの真の価値である。

第2章：3ヶ月使ってみた実体験 — 最も時間を投下した4つのユースケース

ユースケース① クライアント提案書の思考パートナー化

従来の業務フロー：白紙のPowerPointと格闘 → Max導入後：構造の比較検討に注力

前職のコンサル時代、提案書を書くときは白紙のPowerPointと格闘しながら、構造を組み立てていくのが仕事の大半だった。Max 20xに切り替えてから、このフローは根本的に変わった。

クライアント情報、過去議事録、業界データを全部ぶち込んで、「この企業のCXO向けに提案する場合、論点構造を3パターン出して」と投げる。5分後には、切り口の違う3つのストーリーラインが返ってくる。ここから僕が選び、肉付けし、削り、最終的に自分の提案書に仕立てる。

重要なのは、Claudeの出力をそのまま使うわけではないという点だ。コンサルの仕事は最後は自分の頭で考えるしかない。しかし、「白紙から考える」と「3つの構造を比較しながら選ぶ」では、思考の立ち上がりスピードが決定的に違う。体感では、提案書1本あたり4〜6時間の短縮になっている。

1Mトークンのロングコンテキストの価値：特筆すべきは、Opus 4.6に搭載された1Mトークンのロングコンテキストだ。クライアント関連の過去資料を丸ごと投げても破綻せず、「この新しい案件は、去年のA案件のあの論点と似ているから、こう整理すべき」といった横断的な示唆が返ってくる。これはコンサルにとって「過去の自分」を呼び出せる機能であり、経験の再利用性を劇的に高めてくれる。

ユースケース② Cowork modeでの副業事務作業の自動化

従来の手作業時間：30〜40分 → Cowork mode導入後：10〜15分

Claude Max 20xを契約する大きな理由のひとつが、Cowork modeだ。これはClaudeがデスクトップのファイルを直接読み書きし、Excel、Word、PDF、コードを自在に扱えるエージェントモードで、Max以上で利用できる。

Cowork modeに「先月分の領収書PDFフォルダを読んで、日付・金額・用途で仕訳Excelを作って」と頼むと、15分後には完成品が出てくる。従来30〜40分かけていた作業だ。議事録から質疑応答を抽出して整形Word化する作業も、以前は1時間かかっていたものが10分で済む。

Cowork modeの具体的な使い方：

1. 経理自動化：領収書PDF → 日付・金額・用途を自動抽出 → Excelの仕訳表に整理
2. 議事録処理：Word議事録 → Q&Aを抽出 → 新規Wordドキュメント生成
3. フォルダ整理：バラバラなクライアントファイル → 月別・案件別にカテゴリ分け・ファイル名変更
4. データ集計：複数Excelシートから必要データを抽出 → サマリーシート生成

ユースケース③ Claude Skillsによる業務テンプレート化と再現性確保

手動作業（毎回カスタマイズが必要） → Skill化（同じ品質を再現）

3ヶ月触って最も感動したのが、Claude Skills（.md形式）による業務の外部化だ。コンサル業務の大半は「頭の中にある型」の繰り返しで、この型を言語化してMarkdownに書き出し、Claudeに読ませるだけで、同じ品質のアウトプットが何度でも再現できる。

3ヶ月の間に書いた5つのSkill：

1. 案件立ち上げスキル：新規クライアント × 新規プロジェクトの初期フェーズ（背景理解・論点整理・体制構築）
2. 会議アシストスキル：事前資料の背景整理、当日の議論ポイント抽出、議事録の自動生成
3. デイリーブリーフィングスキル：朝の情報集約（メール重要度判定・スケジュール確認・優先度付け）
4. ナレッジ検索スキル：過去案件から関連する分析手法・フレームワーク・解決策を検索・要約
5. Q&A抽出スキル：議事録・会議記録から質疑応答を自動抽出・整形

これらはもはや僕の「第二の業務マニュアル」になっていて、正直これだけでMax契約の意味があると感じている。さらに、Skillsを書く行為そのものに副次的な価値があった。自分の業務フローを言語化してMarkdownに落とし込む過程で、「自分が無意識にやっていた型」が初めて可視化される。

ユースケース④ MCPによる外部ツール統合

Claude Max 20xで初めてMCP（Model Context Protocol）が利用できる。MCPは外部の専門ツール（リサーチAPI、データベース、社内システム）とClaudeを統合するための標準プロトコルだ。

3ヶ月間の試用で実装した3つのMCP連携：

1. リサーチMCP：業界データ・トレンド・競合情報をリアルタイム取得
2. ファイル管理MCP：ローカルディスク上のプロジェクトフォルダを直接検索・参照
3. カレンダーMCP：スケジュール確認 + 会議時間の自動ブロック

これらにより、「Claudeが自分のワークスペースのコンテキストを持つ」状態が実現した。「今月のプロジェクト資料から業界トレンドと関連する情報を抽出して、来週の提案会議の論点に組み込んで」という指示ひとつで、Claudeが自動的に必要な資料を検索して統合してくれる。

第3章：Before/After表 — 導入前後の業務時間変化

以下は3ヶ月の実績を基に、主要な業務について定量化したものだ。

第4章：ROI計算の詳細 — 月額3万円の投資対効果

時間削減インパクトの試算

3ヶ月の実績をざっくり棚卸しすると、月約54〜56時間の削減になる。

シナリオ① 本業の時間単価で計算
コンサルの時間単価を1万円で置くと：

• 月56時間 × 1万円 = 56万円の機会価値
• 月額投資 3万円 → ROI = 1,867%（約18.7倍）

シナリオ② 副業事業の時間単価で計算（保守的想定）
副業事業に振り向けた時間を時給5千円で見積もると：

• 月35時間 × 5千円 = 17.5万円
• 月額投資 3万円 → ROI = 583%（約5.8倍）

シナリオ③ 受注率向上による追加売上
契約後の3ヶ月で、提案書の初稿スピードが上がり、見込み案件の受注率が体感で15〜20%ほど改善した。3ヶ月の間に追加で約80万円の契約が成立したと推定される（保守的な自己評価）。月換算26万円の追加売上 – 投資3万円 = 月23万円の正の損益。

総合ROI算出（3ヶ月累計）

数字で語れない価値もある。それは「思考の摩擦が消える」という体験だ。思いついたアイデアを即座にClaudeにぶつけて構造化してもらい、それを叩き台にして翌日クライアントと話す。この高速サイクルが当たり前になると、もうProには戻れない。月3万円は、この摩擦を消すためのコストだと僕は捉えている。

第5章：競合（GPT-5、Gemini 3）との使い分け表

「Claudeが一番良い」と言いたいところだが、フェアな検証のためにも正直に書く。僕はGPT-5とGemini 3の上位プランも短期間併用して比較した。

僕の現在の運用形態

結論：仕事時間の約85〜90%はClaudeに乗っている。コンサルと副業事業という僕の働き方には、Claudeの「思考の補助輪」としての性格が最もフィットしている。

第6章：Claude Max契約判断チェックリスト

向いている人（以下すべて当てはまる）

• AIを「思考パートナー」として、1日十数回以上対話している
• 提案書・レポート・戦略文書など、「構造化された思考」が成果物である職種
• 月の成果物が4本以上ある（論文・提案書・企画書など）
• 過去資料の再利用を意識している（1Mトークンの価値を感じる可能性が高い）
• Cowork modeで事務作業を自動化できると、月5時間以上浮くと見積もれる
• Skillsを書き込む意欲がある（自分の型を言語化できる）
• MCPなど、外部ツール統合に興味がある

該当数：7個 → Max 20x契約を強く推奨
該当数：5-6個 → Max 5xを検討して、3ヶ月試す価値あり
該当数：3-4個 → Pro（月20ドル）を十分使い倒してから検討
該当数：2個以下 → 現在のProで十分

向いていない人（以下いずれかに当てはまる）

• AIをたまに使う程度（月1-2回程度）
• 単発の文章生成・要約・翻訳しか使わない
• 月間の成果物が1-2本程度
• 「AIに仕事をやらせる」というマインドが持てない（常に手動検証したい）
• Cowork modeで削減できる時間が月3時間以下
• 月額3万円を絶対に回収したい（プレッシャーを感じる）
• コード生成が中心業務である（API従量課金のほうが安い）

該当数：3個以上 → 現在のProで十分。無理にMaxに移行する必要はない。

第7章：3ヶ月使ってわかった「つまずきポイント」3選

つまずきポイント① トークン制限と「思い込み利用」

Max 20xの利用枠は「ほぼ無制限」に見えるが、実際には5時間ごとのリセットが存在する。大型提案案件で5日連続で長文ドキュメント（2-3万トークン）を投げていたら、金曜夜にメッセージ上限に引っかかった経験がある。

教訓：利用枠をダッシュボードで定期確認する習慣が必須。「今週は大型案件で枠を消費する」という予測を立てて、単発の質問は控えるなどの工夫が必要。

つまずきポイント② ハルシネーション対策と品質検証の学習曲線

Claudeは幻覚（ハルシネーション）を起こす。特に「この資料に書いてある○○の数字を教えて」という指示で、存在しない数字を返してくることがある。クライアント提案書で、参加人数の数字を誤出力した経験があり、提案前に気づいて事なきを得たが、ヒヤリハットだ。

教訓：Claudeの出力を「一次情報の代わり」にしてはいけない。特に「数字・人名・固有名詞」を含む指示は、出力後の検証が欠かせない。逆に言えば、「構造化・論理展開・新しい視点の提示」などの、検証が容易なタスクほどClaudeの価値が高い。

つまずきポイント③ プロンプト設計の学習曲線（最初の2週間）

「Max 20xなら何でもできる」という期待値が高いほど、ギャップが大きくなる。最初の2週間、「提案書の構造を出して」という曖昧な指示を出していたら、品質が不安定だった。「このクライアントの経営課題は○○で、意思決定者はCFOである。この文脈で、新規事業提案のためのストーリー構造を3パターン出して」という具体的な指示に変えたら、品質が一気に向上した。

教訓：Skillsを書く過程で、「自分は何を求めているのか」を明確に言語化する。その過程が、実はプロンプト設計の学習そのものになる。Skillsを複数書き込むことで、自然とプロンプトスキルが高まっていく。

まとめ — 1年契約を決めた本当の理由

月3万円は、時間単価1万円のコンサルにとって、月3時間の節約で元が取れる金額だ。僕の実績はその約18倍のリターンを出している。数字の上では、もはや「迷う意味すらない」と言ってよい。

それ以上に重要だったのは、Max 20xが「思考の摩擦」を消してくれたことだ。AIを使う際の無意識のためらいが消えるだけで、仕事の立ち上がりスピード、壁打ちの頻度、アイデアの検証回数、すべてが変わった。これは数字に現れないが、コンサルという職業にとっては決定的な価値だと感じている。

Claude Max 20xが3ヶ月以内に元が取れる3条件：

1. AIを1日に十数回以上使う — 思考の相棒として常時稼働させている
2. 成果物が「構造化された思考」である職種 — コンサル・士業・リサーチャー・PM・ライターなど
3. Cowork modeやSkillsを実務に組み込む意欲がある — AIを「作業の代行者」として信頼できる

この3条件に当てはまらないなら、正直に言ってProで十分である。この3条件に当てはまる人なら、Claude Max 20xは最もROIの高い投資のひとつになる。

読者への次の一歩 — 状況別の3つの選択肢

A. まだClaudeアカウントがない方 — まずは無料から

月3万円のMax 20xから入る必要はまったくない。Claudeは無料プランでも、対話・文書要約・コード生成などの基本機能が試せる。無料で2週間使ってみて、「もっと使いたい」と感じたらPro（月20ドル）にステップアップ。さらにCowork modeやSkillsを本格活用したくなったらMax 5x、もしくはMax 20xへ。いきなり3万円を払う必要はない。

👉 Claudeを無料で試す（招待リンク）

B. Proユーザーで、Cowork modeが気になる方 — Max 5xで1ヶ月試す

「Pro月20ドルでは枠が足りない、でも3万円はまだ重い」という人には、Max 5x（月100ドル）の1ヶ月トライアルを勧める。Cowork mode・Skills・MCPの主要機能はすべて触れる。1ヶ月使って「枠が足りない」と感じたら、そのままMax 20xにアップグレードでよい。

👉 招待リンクから登録 — Cowork modeを試す

C. Max 20xに踏み切るか迷っている方 — チェックリストで判断

上の「契約判断チェックリスト」をやってみてほしい。スコア35点以上ならまずMax 5xで2〜3週間試して、上限が気になるようならMax 20xに移行するのが、最も失敗の少ない流れだ。

この記事は紹介リンク（アフィリエイト）を含みます。掲載しているのは私が実際に長期間使い、ROIを検証したサービスのみです。

あわせて読みたい：AIで浮いた時間の使い方

AIで作業を効率化した後、浮いた時間を何に再投資するかで1年後の差がつく。関連する考え方を2本にまとめている。

• AIで浮いた時間を何に使うか｜月60時間削減した実務家の「時間の再投資」設計
• AIでブログを書く時代、差がつくのはインプットだった