結論：Notionにチケットを書くだけで、PRが出てSlackに通知が届く
Notionにチケットを書いたら、Claude Codeがブランチを切り、実装し、PRを出し、Slackに通知する——そんなパイプラインを実際に作りました。
本記事では、3つのMCPサーバー（Notion・GitHub・Slack）をClaude Codeで束ねて全自動開発パイプラインを構築する方法を、設定ファイル・glueスクリプト・運用実績データまで含めて解説します。
構築にかかった時間は約半日。運用1ヶ月で定型的な実装タスクの約65%を自動化できました。
環境・前提条件
| 項目 | バージョン / プラン |
|---|---|
| Claude Code | 最新版（Claude Max プラン） |
| Node.js | v20 以上 |
| MCP SDK |
@modelcontextprotocol/sdk 最新 |
| Notion API | 2023-08-01 |
| GitHub API | REST API v3 / GraphQL v4 |
| Slack API | Web API（Bot Token） |
前提として、各サービスのAPIトークンが取得済みであること、Claude Codeがインストール済みであることを想定しています。
1. 完成形デモ：全自動フローの全体像
完成したパイプラインの流れはシンプルです。
- Notionでチケットを起票（ステータスを「Ready」に変更）
- Claude Codeがチケット内容を取得し、要件を解析
- GitHubにブランチを作成し、コードを実装してPRを生成
- Slackに完了通知を送信（PR URLとチケットリンク付き）
- Notionのチケットステータスを「In Review」に更新
人間が行う操作は「Notionでチケットを書いてステータスを変える」だけです。
2. 全体アーキテクチャ：3つのMCPサーバーの役割と接続構成
このパイプラインの中核は、Claude CodeがMCPクライアントとして3つのMCPサーバーに接続するハブ構成です。
各MCPサーバーの責務を明確に分離することで、個別の差し替えやテストが容易になります。
3. Step1：Notion MCPサーバーのセットアップとタスク取得
Notion APIトークンの取得
- Notion Developers でインテグレーションを作成
- タスク管理用データベースにインテグレーションを接続
- Internal Integration Tokenを控える
MCP設定
Claude Codeの~/.claude/claude_code_config.json（またはプロジェクトルートの.claude/settings.json）にMCPサーバーを登録します。
Notion MCPサーバーには、公開されているコミュニティ実装を使うか、公式の@notionhq/clientを使って自作する方法があります。ここでは広く使われている@suekou/mcp-notion-serverを例にします。
{
"mcpServers": {
"notion": {
"command": "npx",
"args": ["-y", "@suekou/mcp-notion-server"],
"env": {
"NOTION_API_TOKEN": "ntn_xxxxxxxxxxxx"
}
}
}
}
タスク取得のプロンプト設計
Claude Codeに渡すプロンプトで、Notionからタスクを取得する指示を書きます。
## タスク取得
Notion MCPを使って、データベースID「xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx」から
ステータスが「Ready」のタスクを1件取得してください。
取得するプロパティ:
- タイトル（Name）
- 説明（Description）
- 受け入れ基準（Acceptance Criteria）
- 優先度（Priority）
- 関連ファイルパス（File Paths）
Notionデータベースのプロパティ名は自分の環境に合わせて調整してください。受け入れ基準（Acceptance Criteria）を書いておくと、Claude Codeの実装精度が大幅に向上します。
4. Step2：GitHub MCPサーバーでブランチ作成・PR自動生成
GitHub MCPサーバーの設定
GitHub公式のMCPサーバーを使います。
{
"mcpServers": {
"notion": { "..." : "（前述の設定）" },
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
}
}
}
}
GitHub Personal Access Tokenには以下のスコープが必要です。
-
repo（リポジトリ全般） -
workflow（GitHub Actions連携する場合）
ブランチ命名規則の指示
Claude Codeへのプロンプト（またはCLAUDE.md）にブランチ命名規則を記述しておきます。
## ブランチ命名規則
- feature/[notion-task-id]-[短い説明（kebab-case）]
- 例: feature/TASK-123-add-user-validation
## PR作成ルール
- PRタイトル: Notionタスクのタイトルをそのまま使用
- PR本文: 変更内容の要約 + Notionタスクへのリンク + テスト方針
- ラベル: "ai-generated" を必ず付与
- ドラフトPRとして作成すること
ドラフトPRにする指示は重要です。 人間のレビューを必ず挟むことで、意図しないマージを防ぎます。
実装フェーズ
Claude Codeは取得したタスクの要件を元に、通常のコード実装を行います。ここはMCPではなくClaude Code本来のコーディング機能が担います。
実装完了後、GitHub MCPのcreate_pull_requestツールでPRが自動生成されます。
5. Step3：Slack MCPサーバーで完了通知を飛ばす
Slack Appの準備
- Slack API でAppを作成
- Bot Token Scopes:
chat:write,channels:read - 通知先チャンネルにAppをインストール
MCP設定の追加
{
"mcpServers": {
"notion": { "..." : "（前述の設定）" },
"github": { "..." : "（前述の設定）" },
"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "xoxb-xxxxxxxxxxxx",
"SLACK_TEAM_ID": "T0XXXXXXX"
}
}
}
}
通知メッセージの設計
## Slack通知フォーマット
PR作成後、#dev-notifications チャンネルに以下の形式で通知:
✅ *AI実装完了*
• タスク: [Notionタスクタイトル](NotionタスクURL)
• PR: [PRタイトル](PR URL)
• 変更ファイル数: X files
• レビューをお願いします @channel
6. Claude Codeのhooksで各MCPを連携させるglueスクリプト
ここまでの各MCPサーバーはそれぞれ独立して動きます。これらを一連のパイプラインとして繋ぐ方法は2つあります。
方法A：単一プロンプトで全ステップを指示する
最もシンプルな方法です。CLAUDE.mdにワークフロー全体を記述し、Claude Codeに一気通貫で実行させます。
<!-- CLAUDE.md に追記 -->
## 自動開発パイプライン手順
以下の手順を上から順に実行してください:
1. Notion MCPでデータベースからステータス「Ready」のタスクを1件取得
2. 取得したタスクの要件を分析し、実装計画を立てる
3. GitHub MCPでfeatureブランチを作成
4. 要件に基づいてコードを実装（テストも含む）
5. GitHub MCPでドラフトPRを作成
6. Notion MCPでタスクのステータスを「In Review」に更新
7. Slack MCPで#dev-notificationsに完了通知を送信
方法B：hooksで自動トリガーする
Claude Codeのhooks機能を使い、特定のイベントをトリガーにスクリプトを実行する方法です。.claude/settings.jsonに設定します。
{
"hooks": {
"PostToolUse": [
{
"matcher": "create_pull_request",
"hooks": [
{
"type": "command",
"command": "bash .claude/hooks/post-pr-notify.sh \"$CLAUDE_TOOL_RESULT\""
}
]
}
]
}
}
post-pr-notify.shの中身の例：
#!/bin/bash
# PR作成後にSlack通知をトリガーするglueスクリプト
PR_RESULT="$1"
# Claude Codeに後続タスクを指示するメッセージを標準出力
echo "PRが作成されました。次のステップを実行してください:"
echo "1. Notion MCPでタスクステータスを「In Review」に更新"
echo "2. Slack MCPで完了通知を送信"
実運用では方法Aをベースにし、方法Bを安全装置として併用するのがおすすめです。方法Aだけでも十分機能しますが、hooksを入れておくとPR作成後の通知が確実に実行されます。
実行方法
設定が完了したら、以下のコマンドで一発実行できます。
claude -p "CLAUDE.mdの自動開発パイプライン手順に従って、Notionから最新のReadyタスクを取得し、実装からPR作成・通知まで実行してください。"
--allowedToolsフラグでMCPツールの使用を明示的に許可することもできます。
claude -p "..." \
--allowedTools "mcp__notion__*,mcp__github__*,mcp__slack__*,Bash,Write,Read"
7. 運用1ヶ月の実績：自動化できたタスクとできなかったタスクの境界線
1ヶ月運用した結果をまとめます。
数値実績
| 指標 | 値 |
|---|---|
| パイプライン実行回数 | 47回 |
| 成功（PRマージまで到達） | 31回（65.9%） |
| 軽微な修正後マージ | 10回（21.3%） |
| 大幅な手直しが必要 | 4回（8.5%） |
| 失敗・中断 | 2回（4.3%） |
自動化に向いていたタスク
- CRUDのエンドポイント追加：テンプレート的な実装は高精度
- バリデーションロジックの追加：受け入れ基準が明確なもの
- テストの追加・修正：既存パターンの踏襲
- 設定ファイルの変更：環境変数追加、CI設定修正など
- ドキュメント更新：READMEやAPI仕様書の更新
自動化が難しかったタスク
- 複数サービスにまたがるアーキテクチャ変更：影響範囲の判断が困難
- パフォーマンスチューニング：計測→分析→改善のサイクルが必要
- UI/UXの実装：デザイン意図の解釈にずれが生じやすい
- 既存コードの大規模リファクタリング：全体設計の理解が不十分になりがち
重要な知見：Notionチケットの「受け入れ基準」の粒度が成功率に直結します。 「〜ができること」「〜の場合はエラーを返すこと」のように具体的なテストケースレベルで書かれたチケットは、成功率が90%を超えました。
8. コスト：トークン消費量と月額費用の内訳
トークン消費の実績
| タスク種別 | 平均入力トークン | 平均出力トークン | 平均コスト/回 |
|---|---|---|---|
| 小規模（CRUD追加等） | ~30,000 | ~8,000 | 約$0.40 |
| 中規模（機能実装） | ~80,000 | ~20,000 | 約$1.10 |
| 大規模（複数ファイル変更） | ~150,000 | ~40,000 | 約$2.20 |
※ Claude Sonnet 4をAPI経由で利用した場合の概算。Claude Maxプラン利用時は定額内に収まります。
月額費用の内訳
| 項目 | 月額 |
|---|---|
| Claude Max（5xプラン） | $100 |
| Notion API | 無料（プランに含まれる） |
| GitHub API | 無料（パブリック/プライベートリポジトリ） |
| Slack API | 無料（Free/Proプランに含まれる） |
| 合計 | 約$100 |
API従量課金で使う場合は、月47回の実行で約$40〜$50でした。Claude Maxプランなら定額で気兼ねなく回せるため、頻繁に実行するならMaxプランの方がコスパが良いです。
まとめ
- 3つのMCPサーバー（Notion・GitHub・Slack）をClaude Codeに接続するだけで、チケット起票からPR作成・通知までの全自動パイプラインが構築できる。 設定ファイルの記述量は最小限で、半日あれば動く環境が作れます。
- 自動化の成功率はNotionチケットの記述品質に依存する。 受け入れ基準をテストケースレベルで具体的に書くことが、パイプライン成功の最大のレバレッジポイントです。
- 月額$100以下で運用可能。 定型タスクの65%を自動化できたことで、チームの開発速度は体感で1.3〜1.5倍に向上しました。エンジニアはアーキテクチャ設計やレビューに集中できるようになります。