投稿者: daichi_admin

はじめに：「読んだだけ」で終わらせない

Claude Cowork modeの解説記事を読んで、「自分の業務でも使えそう」と思った人は多いはずだ。だが、実際に手を動かして導入する人は、その10分の1もいない。

理由はシンプルで、「何から始めればいいか分からない」からだ。アカウント作成、デスクトップアプリのインストール、MCP接続、Skillの作成、スケジュールタスクの設定──手順が分散していて、最初の一歩が重い。

この記事は、Cowork modeを今日30分で動き出す状態にするためのチェックリストだ。読みながら手を動かせば、明日の朝にはAIアシスタントが勝手に動いている状態になる。

用意するもの:

• パソコン（Windows / Mac）
• メールアドレス
• 30分の時間

それだけだ。クレジットカードは、後半のステップでMaxプラン契約時に必要になる（無料プランで試したい場合は不要）。

⏱ タイムライン全体像

すべてのチェックボックスを埋めれば、明日の朝9時にはClaudeが自動で動き出している。

STEP 1（0〜5分）：登録 + ダウンロード

☑ 1-1. 招待リンクでアカウントを作成

まだClaudeアカウントを持っていない場合、招待リンク経由で登録すると双方に少額の特典が付く。せっかくなら特典付きで始めるのがお得だ。

👉 Claudeを試す（招待リンク・Cowork mode用）

1. 上記リンクをクリック
2. メールアドレスを入力 → 認証メールを開く
3. パスワード設定 → プロフィール入力

所要時間: 2分

☑ 1-2. プラン選択 — まずは無料 or Pro でOK

ここで多くの人が「いきなりMax契約しなきゃ」と思いがちだが、Cowork modeの手触りを試すだけなら無料・Proでも十分始められる。

• 無料プラン: Claudeとの対話・基本操作に慣れる
• Pro（月20ドル）: Skills対応。初心者の練習場として最適
• Max 5x（月100ドル）: Cowork modeフル機能 + MCP対応。本記事のチェックリストはここから本領発揮

最も失敗が少ないのは「無料で1週間 → Pro で1ヶ月 → Max 5x で本格運用」のパスだ。

☑ 1-3. デスクトップアプリのダウンロード

Cowork modeはブラウザ版ではなくデスクトップアプリでのみ利用できる。

1. claude.ai にログインした状態で右上メニューを開く
2. 「Download desktop app」をクリック
3. インストール実行 → アプリを起動
4. アプリ内でClaudeアカウントにログイン

STEP 2（5〜10分）：初期設定 + 権限付与

☑ 2-1. ファイルアクセス権限を許可

Cowork modeはローカルファイルを読み書きするため、フォルダアクセス権限が必須だ。アプリの設定 → Cowork mode → 「Allow file access」をONにして、アクセス許可するフォルダを選択する。推奨は ~/Documents/Claude-Cowork/（専用フォルダを作る）。

重要: 全ディスクアクセスを許可するのは避ける。Cowork用フォルダだけに絞ること。

☑ 2-2. テスト用フォルダ構造を準備

後のSkill作成で使うフォルダをあらかじめ作っておく。

~/Documents/Claude-Cowork/
├── skills/
├── inputs/
├── outputs/
└── logs/

☑ 2-3. Cowork modeの動作確認

「Claude-Cowork フォルダの中にあるファイルを一覧して」

フォルダ内のファイル名が返ってくれば、ファイルアクセスは正常に動いている。

STEP 3（10〜15分）：最初のMCP接続

MCP（Model Context Protocol）は、ClaudeをGmail・Slack・Notion・Googleカレンダーなどの外部サービスに繋ぐ仕組みだ。初回は1つだけ接続する。複数同時に設定すると認証エラーで止まったときに原因切り分けが面倒だからだ。

☑ 3-1. 最初の接続先を選ぶ

推奨は Gmail。OAuth認証が1クリックで終わり、効果も実感しやすい。

☑ 3-2. MCP接続を実行（Gmail）

1. 設定 → Connectors → 「Add Connector」
2. Gmail を選択
3. ブラウザが開く → Googleアカウントでログイン
4. 権限承認（読み取り・ラベル付与のみ）
5. 「Connected」と表示されればOK

☑ 3-3. 接続テスト

「今日の未読メールを件数だけ教えて」

数値が返ってくれば接続成功。エラーが出る場合は、Step 3-2をやり直す。

STEP 4（15〜25分）：最初のSkill「デイリーブリーフィング」を作成

ここからが本番。最初のSkillとして「デイリーブリーフィング」を作る。Cowork modeの効果を最も早く実感できるSkillだ。

☑ 4-1. SKILL.md を作成

~/Documents/Claude-Cowork/skills/daily-briefing/ フォルダを作り、その中に SKILL.md を作成。以下をそのままコピペしてOK（後でカスタマイズ可能）:

# デイリーブリーフィング

## 目的
毎朝の情報巡回（メール確認、優先度付け）を自動化する。

## 処理ステップ

### 1. Gmail から未読メールを取得
- 過去24時間以内に届いた未読メール
- 差出人、件名、受信日時、本文プレビュー（100字）を構造化

### 2. 優先度スコアを付与
- 差出人が既知のクライアント → +10点
- 件名に「至急」「重要」「URGENT」を含む → +5点
- 件名に「ご請求」「契約」を含む → +3点
- それ以外 → +1点

### 3. スコア順に上位5件を表示

### 4. サマリーを最後に表示
- 未読総数
- 要対応メール数（スコア5以上）
- 推定対応時間（要対応 × 5分）

☑ 4-2. Skill を Claude に登録

1. アプリの設定 → Skills → 「Add Skill」
2. パスを指定: ~/Documents/Claude-Cowork/skills/daily-briefing/SKILL.md
3. 「Save」をクリック
4. Skill一覧に「daily-briefing」が表示されればOK

STEP 5（25〜30分）：動作確認 + スケジュールタスク登録

☑ 5-1. 手動実行で動作確認

「今日のブリーフィング、お願い」

うまくいけば、未読メールの優先度付きリストが返ってくる。

よくある失敗:

• 未読が0件 → 適当な未読メールを残しておいてから再実行
• 認証エラー → Step 3-2のMCP接続をやり直す
• 出力フォーマットが想定と違う → SKILL.mdの「処理ステップ」を明確化

☑ 5-2. スケジュールタスクに登録

1. アプリの設定 → Scheduled Tasks → 「New Task」
2. Name: daily-briefing / Schedule: 0 9 * * 1-5（毎平日 9:00） / Skill: daily-briefing
3. 「Save」をクリック

☑ 5-3. 翌朝の動作を確認する準備

• アプリがバックグラウンドで起動している必要がある
• PCの自動起動設定に追加しておくと確実

🎉 ここまで30分。明日の朝に何が起きるか

お疲れさまでした。これで明日の朝9:00、PCを開いた瞬間に以下が表示される:

• 未読メールの優先度付きトップ5
• 要対応メール数と推定対応時間
• 推奨アクション付きのサマリー

今まで毎朝30分かけていたメール確認が、Claudeのウィンドウを開くだけになる。

つまずいたら見るリスト

Q1. MCP接続でエラーが出る: ブラウザのキャッシュをクリアして、もう一度OAuth認証をやり直す。

Q2. Skillが実行されない: SKILL.mdの冒頭フォーマットが正しいか確認。見出しが必須。

Q3. スケジュールタスクが動かない: デスクトップアプリがバックグラウンドで起動しているか確認。

Q4. 出力が雑で使いにくい: SKILL.mdの「処理ステップ」を具体化する。制約を入れると安定する。

Q5. Cowork modeが見当たらない: Cowork modeはMax以上が必須。プランを確認してください。

次の一歩：2つ目のSkillを作る

デイリーブリーフィングが動き出したら、次に取り組むべきSkillは「自分の事務作業で一番時間を取られているもの」だ。

1. ✅ デイリーブリーフィング（このチェックリストで完了）
2. 経費処理（領収書PDFから仕訳Excel生成）
3. 議事録QA抽出（会議テキストから質疑応答を整形）
4. 案件セットアップ（新規クライアントのフォルダ構造を自動生成）

各Skillの設計詳細は、関連記事「Cowork modeで個人事業の事務作業が消えた話」で解説している。

まとめ：踏み出さなければ何も変わらない

「読んでみて気になっている」と「実際にやってみる」の間には、想像以上の崖がある。この記事は、その崖を30分の階段にするためのチェックリストだ。

30分後、あなたのデスクトップにはAIアシスタントが常駐し、明日の朝から勝手に働き始める。月20ドル〜100ドルで「初めての従業員」を雇うようなものだ。

まずは無料 or Pro から触ってみて、価値を実感したらMaxへ。いきなり大きく賭ける必要はない。

👉 まずはClaudeを試す（招待リンク）
👉 Cowork modeを今すぐ試す（招待リンク）

この記事は紹介リンク（アフィリエイト）を含みます。掲載しているのは私が実際に1ヶ月以上使い、業務インパクトを検証したサービスのみです。

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でブログを書く時代、差がつくのはインプットだった