取り組みの背景：複数 MCP を「繋ぐ」ことの難しさと可能性
Cowork に MCP コネクターを1つ追加すると、その MCP が提供するツールを Claude が使えるようになります。Figma なら Figma、GitHub なら GitHub、Stripe なら Stripe——それぞれ単体では便利です。しかし、個人開発者が本当に欲しいのは「デザインが確定したら自動でコードを更新し、新機能がリリースされたら課金プランのランディングページも更新される」ような 複数サービスを跨いだ自動化ではないでしょうか。
MCPオーケストレーションとは何か
単一 MCP と複数 MCP の違い
単一 MCP 活用の場合、Claude は「1つのサービスに対して操作を行う」エージェントです。例えば Figma MCP だけであれば、「デザインファイルを取得して説明する」ことはできますが、そのデザインを GitHub に自動でコミットすることはできません。
複数 MCP オーケストレーションとは、複数のサービスへのアクセス権を Claude に与えた上で、それらを連携させる手順（スキル）を定義することです。Claude はオーケストレーターとして機能し、各 MCP を適切な順序で呼び出してタスクを完遂します。
オーケストレーションの3つの設計パターン
個人開発の文脈で有用な設計パターンを3つ整理します。
パターン1：シーケンシャル型（逐次実行）
最もシンプルな形。AのMCPから情報を取得し、BのMCPでそれを処理し、CのMCPで結果を保存する直線的なフロー。エラーが起きた場合は即座に停止し、ログに記録します。
例：Figma でデザイントークンを取得 → GitHub にコミット → Slack で通知
パターン2：コンディショナル型（条件分岐）
前のステップの結果に応じて次の処理を分岐させる。例えば「GitHub の最新コミットが特定のフォルダを変更していれば Figma を確認し、変更がなければスキップ」といった条件付き実行が可能になります。
パターン3：ファンアウト・ファンイン型（並列処理）
複数の MCP に並列でリクエストを送り、全ての結果が揃ったところで集約処理を行う高度なパターン。Cowork のスキルは本質的にシングルスレッドですが、スキル内で「以下を順番に確認してください」という指示を与えることで、実質的に並列情報収集に近い動作を実現できます。
システム全体のアーキテクチャ
今回構築するシステムは以下の3つのコンポーネントで構成されます。
コンポーネント1：デザイン同期スキル（Figma → GitHub）
Figma で新しいコンポーネントやデザイントークンが更新されたことを検知し、GitHub リポジトリの該当ファイルを自動更新するスキルです。
コンポーネント2：リリース通知スキル（GitHub → Stripe）
GitHub でリリースタグが作成されると、Stripe の商品説明や価格を自動更新するとともに、ランディングページ用の更新内容をまとめるスキルです。
コンポーネント3：統合ダッシュボードスキル（全MCP横断）
毎朝実行され、Figma のデザイン差分・GitHub の最新コミット・Stripe の売上サマリーを1つのレポートにまとめてワークスペースに保存するスキルです。
実装ステップ1：MCP コネクターの設定
まず Cowork に各 MCP コネクターを追加します。Cowork の「コネクター」セクションから以下の順序で設定してください。
Figma MCP の設定
Figma の Personal Access Token を用意してください。Figma にログインし、「設定 → アカウント → Personal access tokens」から新しいトークンを生成します。スコープは file_read のみで問題ありません。
Cowork でコネクターを追加する際は、以下のMCPサーバー設定が必要です。
{
"figma": {
"command": "npx",
"args": ["-y", "@figma/mcp-server"],
"env": {
"FIGMA_API_KEY": "YOUR_FIGMA_API_KEY"
}
}
}GitHub MCP の設定
GitHub の Personal Access Token（classic）を用意してください。必要なスコープは repo（プライベートリポジトリの場合）または public_repo（公開リポジトリのみの場合）です。
{
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_TOKEN"
}
}
}Stripe MCP の設定
Stripe のダッシュボードから「開発者 → APIキー」でシークレットキーを取得します。本番運用前はテストモードのキー（sk_test_ で始まる）を使用することを強くお勧めします。
{
"stripe": {
"command": "npx",
"args": ["-y", "@stripe/agent-toolkit", "mcp"],
"env": {
"STRIPE_SECRET_KEY": "YOUR_STRIPE_SECRET_KEY"
}
}
}実装ステップ2：デザイン同期スキルの構築
スキルの定義ファイル（SKILL.md）を以下の形式で作成します。
---
name: figma-github-sync
description: Figma のデザイントークンを取得し、GitHub リポジトリの tokens.json を更新する
---
# Figma → GitHub デザイン同期スキル
## 実行手順
1. Figma からデザイントークンを取得する
- ファイルID: {FIGMA_FILE_ID}
- 取得対象: Colorsページのすべての変数
2. 取得したトークンを以下のJSON形式に変換する
```json
{
"colors": {
"primary": "#000000",
"secondary": "#ffffff"
},
"spacing": {
"sm": "8px",
"md": "16px",
"lg": "24px"
}
}-
GitHub の
src/tokens/design-tokens.jsonを更新する- リポジトリ: {GITHUB_OWNER}/{GITHUB_REPO}
- ブランチ: main
- コミットメッセージ: "chore: sync design tokens from Figma [自動更新]"
-
更新が成功したらワークスペースの
_logs/figma-sync.txtに記録する- 記録フォーマット:
[YYYY-MM-DD HH:MM] Synced N tokens
- 記録フォーマット:
エラーハンドリング
- Figma へのアクセスが失敗した場合:
_logs/figma-sync-errors.txtに記録して終了 - GitHub への書き込みが失敗した場合: 同様にエラーログに記録して終了
- トークン形式が変わっていた場合:
_pending/figma-tokens-YYYYMMDD.jsonに生データを保存して手動確認を促す
このスキルのポイントは、**エラーハンドリングを明示的に記述している**ことです。MCP 経由の操作は外部サービスへのリクエストを伴うため、ネットワークエラーや権限エラーが必ず発生します。スキル内で「失敗した場合は〇〇する」という手順を明示することで、Claude が自律的に適切な対応を行えます。
---
## 実装ステップ3：スケジュールタスクへの組み込み
デザイン同期は毎日決まった時刻に実行するのが理想的です。Cowork のスケジュールタスク機能を使って、上記スキルを定期実行に組み込みます。
スケジュールタスクの設定例：
タスク名: figma-github-daily-sync 実行時刻: 毎日 09:00 JST 説明: Figma のデザイントークンを取得して GitHub リポジトリに同期する
実行手順: _skills/figma-github-sync/SKILL.md のワークフローを全て実行すること。 ステップを省略しないこと。エラーが発生した場合は _logs/ にログを記録すること。
スケジュールタスクのプロンプトでは「SKILL.md のワークフローを全て実行すること」と明記するのが重要です。これにより Claude はスキルファイルを読み込み、定義されたステップを順番に実行します。
---
## 実装ステップ4：リリース通知スキルの構築
GitHub でリリースタグが作成されると Stripe の商品情報を更新するスキルです。このスキルはスケジュール実行ではなく**オンデマンド実行**が適しています。
```markdown
---
name: github-stripe-release-sync
description: GitHub の最新リリース情報を取得し、Stripe の商品説明を更新する
---
# GitHub → Stripe リリース同期スキル
## 実行前確認
- リポジトリ名を引数として受け取る（デフォルト: {DEFAULT_REPO}）
- Stripe の対象プロダクト ID: {STRIPE_PRODUCT_ID}
## 実行手順
### Step 1: GitHub から最新リリース情報を取得
リポジトリ {GITHUB_OWNER}/{リポジトリ名} の最新リリースを取得する。
取得する情報:
- バージョンタグ（例: v2.1.0）
- リリースノートの本文
- 公開日時
### Step 2: リリースノートを Stripe 向けに変換
取得したリリースノートを以下のルールで変換する:
- Markdown のヘッダー（##）を取り除く
- 技術的すぎる変更点（内部リファクタリング等）は省略する
- エンドユーザーにとってのメリットを1〜2文で要約する
- 文字数: 200文字以内（Stripe の商品説明に表示される）
変換例:
- 変換前: `## Bug Fixes\n- Fixed crash on iOS 17.4\n- Fixed memory leak in background processing`
- 変換後: `v2.1.0 リリース：iOS 17.4 でのクラッシュを修正し、バックグラウンド処理の安定性を向上しました。`
### Step 3: Stripe の商品説明を更新
Stripe の Product {STRIPE_PRODUCT_ID} の description フィールドを更新する。
更新する値: Step 2 で生成した変換後テキスト + `（最終更新: YYYY-MM-DD）`
### Step 4: ログ記録
ワークスペースの `_logs/stripe-sync.txt` に以下を記録する:
[YYYY-MM-DD HH:MM] Released {VERSION} → Stripe product updated Description: {UPDATED_DESCRIPTION}
## 注意事項
- Stripe の本番環境を直接更新するため、変換後テキストが意図しない内容になっていないか必ず確認してから更新すること
- 「確認してから更新」を省略しないこと
このスキルで特に重要なのは「確認してから更新」のステップです。Stripe は実際の課金システムであり、誤った情報を顧客に見せることは信頼を損ないます。スキル定義の中で「確認ステップを省略しないこと」と明記することで、Claude が自律実行中も確認プロセスを飛ばさないようにできます。
実装ステップ5：統合ダッシュボードスキルの構築
毎朝実行される、全 MCP の情報を集約するスキルです。このスキルがオーケストレーションの核心です。
---
name: daily-dev-dashboard
description: Figma・GitHub・Stripe の情報を集約した朝次レポートを生成する
---
# 個人開発デイリーダッシュボード
今日の開発状況を把握するため、3つのサービスから情報を収集してレポートを生成する。
## 情報収集
### Figma セクション
- {FIGMA_FILE_ID} のファイルを取得
- 最終更新日時を確認
- 未コミットのデザイン変更があるか確認（`_logs/figma-sync.txt` の最終同期日時と比較）
### GitHub セクション
- リポジトリ {GITHUB_OWNER}/{GITHUB_REPO} の過去24時間のコミット一覧を取得
- オープン中の Issue 数を取得
- 最新のリリースバージョンを確認
### Stripe セクション
- 過去24時間の新規サブスクリプション数を取得
- 過去24時間の売上合計を取得（JPY）
- チャーン（解約）があれば件数を確認
## レポート生成
収集した情報を以下の形式でまとめ、ワークスペースの `_reports/dashboard-YYYY-MM-DD.md` に保存する:
```markdown
# 個人開発デイリーダッシュボード — YYYY-MM-DD
## デザイン（Figma）
- 最終更新: YYYY-MM-DD HH:MM
- 未同期変更: あり / なし
- アクション: [未同期の場合] figma-github-sync スキルを実行する
## 開発（GitHub）
- 昨日のコミット数: N件
- オープン Issue: N件
- 最新バージョン: vX.Y.Z
## 収益（Stripe）
- 新規サブスク: N件
- 昨日の売上: ¥XX,XXX
- チャーン: N件
## 本日のアクションアイテム
1. [Figmaの未同期がある場合] デザイン同期を実行する
2. [GitHubにリリースがある場合] Stripeの説明を更新する
3. [Issueが5件以上の場合] Issue のトリアージを行う完了後
レポートのサマリーを3行以内で出力し、本日のアクションアイテムがある場合は冒頭に「⚠️ 要対応あり」と表示する。
このスキルは**条件付きアクションアイテム**の生成が肝です。単に情報を並べるだけでなく「この状況が検出された場合は次のアクションが必要」という判断ロジックをスキル内に埋め込むことで、朝にレポートを確認するだけで次の行動が明確になります。
---
## 本番運用で必要なエラーハンドリング設計
### MCP タイムアウトへの対処
外部 MCP サーバーは稀にタイムアウトします。スキル内に以下のリトライロジックを記述しておくと安全です。
```markdown
## エラーハンドリング共通ルール
各 MCP への操作が失敗した場合:
1. エラーメッセージを記録する
2. 30秒待ってから1回リトライする
3. リトライも失敗した場合は以下のファイルにエラーログを記録して次のステップへ進む:
- ファイル: `_logs/errors/YYYY-MM-DD-errors.txt`
- フォーマット: `[HH:MM] {MCP_NAME} ERROR: {ERROR_MESSAGE}`
4. エラーが発生したステップをスキップし、取得できた情報でレポートを生成する
認証エラーの検出
API トークンの有効期限切れは実運用で最もよく遭遇する問題です。スキル内にこの検出ロジックを追加しておきましょう。
## 認証エラー検出
操作が `401 Unauthorized` または `403 Forbidden` エラーで失敗した場合:
- `_logs/auth-errors.txt` に記録する
- ユーザーへの通知として `_notifications/urgent.txt` に以下を書き込む:
`[URGENT] {MCP_NAME} の API トークンが無効です。ワークスペース → コネクター設定 → トークンの更新が必要です。`
- このスキルの実行を終了する（不完全なデータでレポートを生成しない）よくある設計ミスと対処法
ミス1：スキルが「何でもやる」設計になっている
スケジュールタスクの基本的な設定方法については Claude Cowork スケジュールタスク完全ガイド も合わせてご参照ください。また、スキルとスケジュールの高度な組み合わせパターンは Cowork スキル×スケジュール活用: 業務自動化の設計パターンと実践テクニック で詳しく解説しています。
複数 MCP を1つのスキルで全て扱おうとすると、スキルが肥大化して Claude がどこで何をすべきか混乱することがあります。
対処法：スキルは「1つの責務」に絞ります。figma-github-sync、github-stripe-release-sync、daily-dashboard のように機能ごとに分割し、daily-dashboard スキルから他のスキルを「必要に応じて呼び出す」設計にします。
ミス2：失敗時の挙動が未定義
スキルに「成功した場合の手順」しか書いていないと、エラーが発生したときに Claude が自己判断でサービスに影響のある操作を行う可能性があります。
対処法：すべての主要ステップに「このステップが失敗した場合は〇〇する」を明示します。特に Stripe のような決済サービスへの書き込み操作は、前のステップが失敗していたら絶対に実行しないよう明記する点が肝心です。
ミス3：確認ステップを設けていない
完全自動化のつもりで確認ステップを省いた結果、誤ったデータが本番環境に反映されることがあります。
対処法：本番環境への書き込みを伴うスキルには必ず「以下の内容で更新します。確認して続行してください」という確認ステップを設けます。完全自動化したい場合でも、ログにプレビューを記録する手順を挟みます。
まとめ
MCP サーバーの基礎からより広いエコシステム設計を学びたい方は、Claude Cowork × MCP サーバー完全統合ガイド が参考になります。
- シーケンシャル・コンディショナル・ファンアウトの3つの設計パターン
- 各 MCP コネクターの設定方法
- デザイン同期・リリース通知・統合ダッシュボードの3つのスキル実装
- エラーハンドリング・認証エラー検出の実践的な設計
複数 MCP オーケストレーションの真の価値は「1つ1つのツールを使う手間を省く」ことではなく、**「情報の流れを自動化することで、人間が本当に判断すべきことだけに集中できる環境を作る」**ことにあります。デザインが変わればコードが追いつき、コードが変われば顧客への説明が追いつく——そのような自律的な開発環境の実現に、この設計図が役立てば幸いです。
Cowork のオーケストレーション設計