◈ Cowork/2026-03-31上級

Claude Cowork × MCP サーバー完全統合ガイド — Slack・Notion・GitHub を繋ぐ業務自動化エコシステムの設計と本番運用パターン

Cowork と MCP サーバーを統合し、Slack・Notion・GitHub を跨ぐ業務自動化エコシステムを構築する実践ガイド。スキル・スケジュールタスクとの組み合わせパターンも網羅。

Cowork⁴⁶ MCP⁵⁶ 業務自動化³ Slack⁴ Notion² GitHub⁸ エコシステム

✦ プレミアム記事

Claude Cowork が単体で提供する自動化は強力ですが、ビジネスの現場では Slack・Notion・GitHub・Jira など多数のサービスが共存しています。MCP（Model Context Protocol）コネクターを Cowork に統合することで、これらのツールを横断する「業務自動化エコシステム」が実現します。

MCP と Cowork の関係 — なぜ統合するのか

MCP（Model Context Protocol）とは

MCP は Anthropic が策定したオープンプロトコルで、AI エージェントと外部ツール・データソースを標準化された方法で接続します。Cowork の Claude エンジンは MCP クライアントとして動作し、MCP サーバーとして公開された外部サービスをツールとして呼び出せます。

Cowork における MCP の位置づけは以下の通りです。

標準スキル: Cowork が組み込みで提供するファイル操作・Bash 実行・Web 検索など
MCP コネクター: Slack・Notion・GitHub・Asana など外部サービスへのブリッジ
カスタムプラグイン: ユーザーが定義したスキル集（MCP サーバーとして実装可能）

MCP がない場合、各サービスとの連携は API 呼び出しコードをスキル内に直書きする必要があります。MCP コネクターを使うと、Claude が自然言語でツール呼び出しを判断し、認証・レート制限・エラーハンドリングの多くをコネクター側が吸収します。

Cowork × MCP で何が変わるか

具体的なビフォー・アフターを考えてみましょう。

Before（スキルに API 呼び出しを直書き）

# Slack通知スキルの従来実装
curl -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"#dev","text":"デプロイ完了"}'

After（MCP コネクター経由）

# スキル内の指示（プレーンテキスト）
Slack の #dev チャンネルに「デプロイ完了」と通知してください。

MCP コネクターが接続されていれば、Claude が「Slack 通知が必要」と判断し、適切なツールを自動選択します。スキルファイルはシンプルになり、API キーの管理もコネクターの設定画面で一元化できます。

環境構築 — MCP コネクターの追加と管理

Cowork へのコネクター追加手順

Cowork デスクトップアプリでのコネクター追加は、以下の手順で行います。

ステップ 1: コネクター管理画面を開く

Cowork のサイドバー左下にある「Settings」→「Connectors」または「Plugins」を選択します。画面上部に「+ Add Connector」ボタンが表示されます。

ステップ 2: MCP レジストリから選択

公式 MCP レジストリには主要サービスのコネクターが登録されています。検索バーに「Slack」「Notion」「GitHub」などと入力し、目的のコネクターを選択します。

ステップ 3: 認証設定

各コネクターは OAuth または API キーによる認証が必要です。

Slack: Workspace の OAuth 2.0 トークン（xoxb-... 形式の Bot Token）
Notion: Internal Integration Token（secret_... 形式）
GitHub: Personal Access Token（ghp_... 形式）または GitHub Apps

// コネクター設定例（内部的な構成イメージ）
{
  "connector": "slack-mcp",
  "version": "2.1.0",
  "auth": {
    "type": "bearer_token",
    "token_env": "SLACK_BOT_TOKEN"
  },
  "permissions": ["channels:read", "chat:write", "files:write"]
}

ステップ 4: 動作確認

設定後、Cowork のチャット欄で「Slack の #general チャンネルの最新5件のメッセージを取得して」と入力し、正常にデータが返ってくれば接続成功です。

セキュリティ設計の原則

本番運用では以下の原則を守ることを強くおすすめします。

最小権限の原則: Slack Bot Token には chat:write のみ付与し、admin 権限は絶対に与えない

環境変数の分離: .env.local ではなく、OS のキーチェーン（macOS Keychain）や Secret Manager サービスにトークンを保存する

トークンのローテーション: 90 日ごとに API キーを再発行し、古いトークンを失効させる

スコープ監査: 定期的に各コネクターが実際に使用しているスコープを確認し、不要なものを削除する

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦MCP コネクターを Cowork に組み込んで Slack・Notion・GitHub を横断する自動化パイプラインを構築できる

✦スキルファイルとスケジュールタスクを MCP と連携させる設計パターンと実装コード例を習得できる

✦本番運用を想定したエラーハンドリング・認証管理・ログ設計のベストプラクティスを体系的に学べる

Stripe による安全な決済 · いつでもキャンセル可能

主要コネクターの実践活用パターン

Slack コネクター — 通知・メッセージ収集・ステータス管理

Slack コネクターは通知送信だけでなく、情報収集のハブとしても活用できます。

パターン 1: プロジェクト進捗レポートの自動送信

毎朝 9 時に GitHub の最新コミット・オープン PR・Issues をまとめ、Slack に報告するスケジュールタスクを構築できます。

# スキルファイル（skills/morning-report/SKILL.md）の抜粋
 
## 実行内容
1. GitHub の masakihirokawa/claudelab.net リポジトリから直近24時間のコミットログを取得
2. オープン状態の PR を一覧化（タイトル・作成者・最終更新日）
3. Milestone 付きの Issues をステータス別に集計
4. 上記をまとめて Slack #dev-daily チャンネルに投稿する
 
## フォーマット
- 見出し: 📊 Daily Dev Report (YYYY-MM-DD)
- セクション: Commits / Pull Requests / Issues
- 重要 Issue には 🔴 マーカーを付ける

このスキルをスケジュールタスクで毎朝実行するだけで、朝会の前に情報が揃います。

パターン 2: Slack メッセージをトリガーにしたタスク実行

Slack の特定チャンネルを監視し、「/claude deploy staging」のようなメッセージをトリガーにワークフローを起動することも可能です。ただしこのパターンは Slack App（Event Subscriptions）との連携が必要で、Cowork 側では定期ポーリングで代用することが多いです。

# ポーリングスクリプトの概念実装
# 5分ごとに #commands チャンネルの未処理メッセージを確認
LATEST_MSG=$(slack_mcp get_messages channel=#commands since=5min_ago)
if echo "$LATEST_MSG" | grep -q "/claude deploy"; then
  # デプロイスキルを実行
  run_skill deploy-staging
fi

Notion コネクター — ナレッジベースとドキュメント管理

Notion は「チームの脳」として機能します。Cowork との統合で、AI によるドキュメント生成・更新・検索が自動化できます。

パターン 3: 週次レポートの自動作成と Notion への保存

# weekly-report スキルの指示
 
## 入力
- Google Analytics の週次サマリー（CSV形式、ワークスペースの analytics/ フォルダ）
- Slack #weekly-results チャンネルの今週のメッセージ
 
## 処理
1. GA データから主要 KPI を抽出（PV・UU・直帰率・滞在時間）
2. 先週比・先月比の増減率を計算
3. Slack メッセージから今週のハイライトを3〜5点抽出
4. Notion の「週次レポート」データベースに新規ページとして保存
 
## Notion ページ構造
- タイトル: [YYYY/WW] 週次レポート
- プロパティ: 週番号・作成日・KPI サマリー（数値）
- 本文: ハイライト・課題・来週のアクションアイテム

パターン 4: Notion をスキルのナレッジベースとして活用

Cowork スキルから Notion のデータを参照することで、スキルファイル自体を薄く保ちながら豊富な知識を活用できます。

# notion_knowledge_base の疑似コード
def get_product_faq(question: str) -> str:
    """
    Notion の FAQ データベースから関連するQ&Aを検索する
    """
    results = notion_mcp.query_database(
        database_id="YOUR_FAQ_DB_ID",
        filter={
            "property": "Question",
            "rich_text": {"contains": question}
        }
    )
    return format_results(results)

GitHub コネクター — コードベース管理・Issue 連携・CI/CD 監視

GitHub コネクターは開発ワークフローの中心に位置します。

パターン 5: Issue → ブランチ → PR の自動化チェーン

# issue-to-pr スキルの実行フロー
 
1. GitHub の Issues から "priority: high" ラベルの未着手 Issue を取得
2. Issue 番号とタイトルからブランチ名を生成（例: feat/123-add-dark-mode）
3. ブランチを main から作成（GitHub MCP の create_branch ツール使用）
4. Issue の説明を元に実装方針を Notion の「実装計画」ページに記録
5. Slack の #dev チャンネルに「Issue #123 の作業ブランチを作成しました」と通知
 
## 注意
- 既にブランチが存在する場合はスキップ
- Issue がクローズ済みの場合は処理しない
- エラー時は Slack に詳細をレポート

パターン 6: PR レビュー自動化

# PR作成時にClaude が差分を解析してレビューコメントを投稿
PR_DIFF=$(github_mcp get_pull_request_diff pr_number=$PR_NUMBER)
REVIEW=$(claude analyze "$PR_DIFF" --focus "security,performance,readability")
github_mcp create_review pr_number=$PR_NUMBER body="$REVIEW" event="COMMENT"

スキル × MCP × スケジュールタスク — 三位一体の設計パターン

Cowork の真価は、スキル・MCP コネクター・スケジュールタスクの三つを組み合わせたとき発揮されます。

設計パターン A: データ収集 → 分析 → 通知チェーン

このパターンは定期的なモニタリング・レポーティングに最適です。

[スケジュールタスク: 毎日 9:00]
    ↓ 実行
[スキル: morning-brief]
    ↓ MCP 呼び出し
[GitHub MCP] → 昨日のコミット・PR ステータス取得
[Notion MCP] → 今日の予定タスク取得
[Slack MCP] → #important チャンネルの未読メッセージ取得
    ↓ Claude が統合・要約
[Slack MCP] → #briefing チャンネルに投稿
[Notion MCP] → 日次記録ページに保存

実装例として、スケジュールタスク側は単純です。

# タスク名: claudelab-morning-brief
# Cron: 0 9 * * 1-5 (平日 9:00 JST)
 
ワークスペースの _skills/morning-brief/SKILL.md を読み込み、
Step 0〜5 を全て実行してください。省略厳禁。

スキルファイルに処理の詳細を集約することで、スケジュールタスクのプロンプトを変更せずに機能を拡張できます。これはCowork スキル×スケジュール活用ガイドで解説した「スキルをプロンプトの中核に置く」設計原則です。

設計パターン B: イベント駆動型の条件分岐ワークフロー

単純な定期実行ではなく、「GitHub CI が失敗したら通知する」「Notion に特定のページが追加されたら処理する」というイベント駆動パターンです。

# SKILL.md の条件分岐実装例
 
## Step 1: GitHub Actions の最新ステータスを確認
LATEST_RUN=$(github_mcp list_workflow_runs repo=claudelab.net limit=1)
 
## Step 2: ステータスに応じて分岐
if status == "failure":
  # Step 3a: 失敗詳細をログから抽出
  ERROR_LOG=$(github_mcp get_workflow_run_logs run_id=$LATEST_RUN.id)
 
  # Step 3b: Claude がエラー原因を分析して修正案を生成
  ANALYSIS=$(analyze_error "$ERROR_LOG")
 
  # Step 3c: Slack に緊急通知
  slack_mcp post_message channel=#alerts text="🚨 CI 失敗: $ANALYSIS"
 
  # Step 3d: Notion の障害記録データベースに追記
  notion_mcp create_page database=incidents title="CI Failure $(date)" content="$ANALYSIS"
 
elif status == "success":
  # Step 3e: 成功をログに記録するだけ（通知なし）
  echo "✅ CI passed"

設計パターン C: マルチサービス集約ダッシュボード

複数サービスのデータを Notion の単一ダッシュボードに集約し、毎週自動更新するパターンです。

# weekly-dashboard-update スキル
 
## データ収集フェーズ
1. GitHub: 今週のコミット数・PR マージ数・Issue クローズ数
2. Slack: 今週のメッセージ数・最もリアクションされた投稿トップ3
3. Notion: 今週完了したタスク・未完了のもの
4. ローカルファイル: _updated_article_log/ の今週分ログ
 
## 集計フェーズ
- 全データを JSON に整形
- 先週比の増減を計算
 
## 更新フェーズ
- Notion の「Weekly Dashboard」ページのプロパティをすべて更新
- グラフ用のデータテーブルをページ内に上書き
- Slack #management に「週次ダッシュボード更新完了」と通知

よくあるエラーと対処法

MCP 統合の実装中によく発生するエラーと対処法をまとめます。

エラー 1: `MCP connection timeout` — 接続タイムアウト

原因: MCP サーバーの起動が遅い、またはネットワーク遅延

対処: スキルの先頭に接続確認ステップを入れる

# 接続確認（タイムアウト 10 秒）
if ! timeout 10 slack_mcp ping 2>/dev/null; then
  echo "⚠️ Slack MCP 接続タイムアウト。リトライを実行します..."
  sleep 5
  # 最大3回リトライ
fi

エラー 2: `Tool not found: notion_create_page` — ツール名の不一致

原因: MCP サーバーのバージョンアップでツール名が変更された

対処: コネクターを最新版に更新し、利用可能なツール一覧を再確認する

# 利用可能なツールを確認
notion_mcp list_tools 2>/dev/null | grep "create"
# 出力例: create_page, create_database_item

エラー 3: `Rate limit exceeded` — レート制限超過

原因: Slack API は 1 分あたり 50 メッセージ投稿制限、Notion API は 3 req/s 制限がある

対処: スキルにレート制限対応の待機処理を入れる

# Notion への連続書き込み時の待機
for item in $ITEMS; do
  notion_mcp create_page database=$DB_ID content="$item"
  sleep 0.4  # 3 req/s = 0.33s 間隔 → 余裕を持って 0.4s
done

エラー 4: `Authentication failed: token expired` — トークン期限切れ

原因: GitHub の PAT（Personal Access Token）はデフォルトで 30/90 日有効期限がある

対処: 有効期限を設定し、期限の 7 日前にアラートするスケジュールタスクを設ける

# token-expiry-check スキル（毎週月曜実行）
 
1. 各 MCP コネクターの設定ファイルからトークン設定日を確認
2. 現在日時との差分を計算
3. 7日以内に期限切れになるものを Slack に通知
4. 30日以上経過しているものは再発行を強く推奨

エラー 5: MCP コネクターのバージョン競合

複数のコネクターが同じ内部ライブラリに依存している場合、バージョン競合が起きることがあります。

対処: プラグインの隔離実行環境（サンドボックス）を活用するか、コネクターを個別に更新してテストします。Cowork カスタムプラグイン開発ガイドの「依存関係管理」セクションも参照してください。

本番運用の設計原則

1. 冪等性（べきとう性）の確保

同じスキルが複数回実行されても副作用が出ないよう設計します。

# NG: 重複投稿の危険あり
slack_mcp post_message channel=#reports text="レポート作成完了"
 
# OK: 今日すでに投稿済みかチェックしてから投稿
EXISTING=$(slack_mcp search_messages query="レポート作成完了 after:$(date +%Y-%m-%d)" in=#reports)
if [ -z "$EXISTING" ]; then
  slack_mcp post_message channel=#reports text="レポート作成完了"
fi

2. 構造化ログの設計

Cowork のスケジュールタスクが失敗したとき、何が起きたかを素早く把握できるよう、ログを構造化しておきます。

// ログエントリの推奨フォーマット
{
  "timestamp": "2026-03-31T09:15:00+09:00",
  "task": "morning-brief",
  "step": "github_fetch",
  "status": "success",
  "duration_ms": 342,
  "data_count": 12
}

ログは Notion の「実行ログ」データベースか、ワークスペースの _updated_article_log/ に日付別で保存するのが管理しやすいです。

3. フォールバック戦略

MCP コネクターが使えない場合でも、スキルが完全停止しないよう代替処理を用意します。

# Slack MCP が使えない場合のフォールバック
if ! slack_mcp ping 2>/dev/null; then
  echo "⚠️ Slack MCP 利用不可 — メールフォールバックを使用"
  # メール送信 or ローカルログに記録
  echo "$(date): $REPORT_CONTENT" >> "$WS/_logs/slack_fallback.txt"
fi

4. 認証情報の集中管理

複数の MCP コネクターで多数のトークンを管理するため、認証情報の一元管理が重要です。

推奨構成としては、Cowork のコネクター設定画面で各トークンを登録し、スキルファイルやスクリプト内に直接トークンを記述しない方針を徹底します。CI/CD 環境での実行が必要な場合は、GitHub Actions の Secrets や Cloudflare Workers の Environment Variables を活用してください。

MCP サーバーを自前で構築する高度なユースケースでは、Claude MCP サーバーを自作する完全ガイドで解説している設計パターンも参考になります。