Hugging Face MCP Course Unit3: 高度なMCPワークフローサーバー構築学習メモ

Hugging Face MCP Course の Unit3 を学習したメモ。Unit1、2で基礎を学んだ後、実際の開発チームで使える高度なワークフロー自動化システムを構築する。PRエージェント、CI/CD監視、Slack通知を組み合わせた実用的なMCPサーバーの実装方法を学ぶ。

Unit3の全体像：CodeCraft Studiosの課題解決

解決する問題

架空の企業「CodeCraft Studios」が抱える典型的な開発チームの課題：

PR作成の非効率性: 説明不足、テンプレート選択ミス
CI/CD監視の手作業: GitHub Actionsの結果確認漏れ
チーム間コミュニケーション: 重要な情報の伝達遅れ

構築するソリューション

MCPプリミティブを組み合わせた統合ワークフローシステム：

Tools: git diff分析、GitHub Actions監視、Slack通知
Resources: PRテンプレート、チーム設定、プロジェクト情報
Prompts: CI結果分析、通知フォーマット、障害対応ガイド
Integration: 全プリミティブの連携による高度な自動化

Module 1: MCPサーバー構築 - PRエージェント

目標：インテリジェントなPR作成支援

従来の手作業によるPR作成プロセスを、git変更の自動分析とテンプレート提案で効率化する。

実装する3つの主要ツール

Module 1では、server.pyに以下の3つの主要なツールを実装する：

1. `list_files` - ファイル一覧取得

指定ディレクトリのファイル一覧を取得するファイルシステム操作の基本ツール

2. `analyze_code` - コード変更分析

git diffを実行してファイル変更を分析し、結果を構造化データとして返す

3. `get_pr_details` - PR詳細生成

変更内容に基づいてPRタイトルと説明を生成し、適切なPRテンプレートを提案する

重要な設計パターン

作業ディレクトリの考慮

MCPサーバーはデフォルトで自身のインストールディレクトリでコマンドを実行するが、Claudeが操作しているリポジトリのディレクトリでコマンドを実行する必要がある場合がある。mcp.get_context()を使用してClaudeの作業ディレクトリを取得し、subprocess.runのcwd引数に渡す方法が示されている。

大規模出力の処理

git diffの出力が大きすぎてエラーになる問題への対処が重要な学習ポイントとして挙げられている。考えられる対処法の例：

出力切り捨て: 最初の1000行のみ返す
要約生成: 変更ファイル数、追加/削除行数のサマリー
ページネーション: 複数回に分けて取得

エラーハンドリング

ツールが失敗した場合でも、エラー情報をJSON形式で返すことの重要性が説明されている。適切なエラーハンドリングにより、Claudeが問題を理解し、適切に対応できるようになる。

テスト戦略

ruff: コード品質チェック
pytest: 単体テスト実行
Claude Code: 実際の統合テスト

Module 2: GitHub Actions連携 - CI/CD監視

目標：リアルタイムCI/CD監視システム

GitHub ActionsのWebhookイベントを受信し、CI/CDの状況をリアルタイムで監視・分析する。

アーキテクチャ：2つのサーバー構成

Webhookサーバー（ポート8080）

GitHubイベントを受信するポート8080のWebhookサーバー。HTTPの複雑さを処理し、受信したイベントをファイルに保存する。

MCPサーバー（メイン）

Claudeとの通信を行うMCPサーバー。Webhookで保存されたイベントデータを読み取り、分析ツールとプロンプトを提供する。関心の分離により、それぞれが専門的な役割に集中できる。

MCPプロンプトの活用

従来のツール（Claudeが自動呼び出し）とは異なり、プロンプトはユーザーが開始する構造化ワークフロー：

Module 2では4つのMCPプロンプトを実装する：

`analyze_ci_results`

CI/CDの結果分析用プロンプト。最近のイベントを分析し、成功/失敗の概要、原因分析、推奨アクションを構造化して報告する。

`troubleshoot_workflow_failure`

ワークフロー失敗の体系的なトラブルシューティング用プロンプト。エラーログ確認、依存関係検証、環境設定確認、修正手順提案を段階的に実行する。

`create_deployment_summary`

標準化されたデプロイメントサマリー作成用プロンプト。

`generate_pr_status_report`

PRステータスレポート生成用プロンプト。

Cloudflare Tunnelでの外部アクセス

ローカル開発環境でGitHub Webhookを受信するためにCloudflare Tunnelを使用する。MCPサーバー、Cloudflare Tunnel、GitHub Webhookを連携させることで、実際の開発環境をシミュレートし、GitHubからのリアルタイムイベントに基づいてClaudeがコード変更の分析とCI/CDイベントの監視を同時に行えることを確認する。

イベント処理パイプライン

GitHub: ワークフロー実行でWebhook送信
Webhook Server: イベント受信・ファイル保存
MCP Server: イベント読み取り・分析ツール提供
Claude: プロンプト実行・結果分析
次のアクション: Slack通知など

Module 3: Slack通知 - チームコミュニケーション

目標：インテリジェントな通知システム

CI/CDの結果を適切なフォーマットでチームに自動通知し、コミュニケーションギャップを解消する。

Slack連携の実装

Webhook URLの取得

Slackアプリ作成
Incoming Webhooks機能を有効化
チャンネル選択・Webhook URL取得
環境変数に設定: SLACK_WEBHOOK_URL

通知ツールの実装

send_slack_notificationツールをMCPサーバーに追加する。このツールは環境変数からWebhook URLを読み取り、SlackのWebhookにHTTPリクエストを送信してメッセージを投稿する。エラー処理も含まれる。

メッセージフォーマット用プロンプト

Module 3では2つのメッセージフォーマット用プロンプトを実装する：

`format_ci_failure_alert`

CI失敗通知用プロンプト。GitHub ActionsのイベントをSlackメッセージにフォーマットし、リポジトリ名、ブランチ、コミットハッシュ、エラーサマリー、担当者への通知を含む構造化されたメッセージを生成する。

`format_ci_success_summary`

CI成功サマリー用プロンプト。ビルド成功を簡潔にフォーマットし、リポジトリ名、実行時間、テスト結果などを含むメッセージを生成する。

Slack Markdownの活用

効果的な通知のための書式設定：

太字: *重要な情報*
コードブロック: エラーメッセージ
絵文字: 🚨 ✅ ⚠️ で視覚的な区別
メンション: @channel @here で緊急度表現

完全なワークフローテスト

GitHub: プッシュでワークフロー実行
Webhook: イベント受信・保存
Claude: 「最近のイベントをチェックして」
MCP: イベント分析・プロンプト実行
Slack: フォーマット済み通知送信

統合アーキテクチャ：全体像

MCPプリミティブの連携

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   GitHub        │───▶│   Webhook        │───▶│   MCP Server    │
│   Actions       │    │   Server         │    │                 │
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                                         │
                                                         ▼
┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   Slack         │◀───│   Claude Code    │◀───│   Tools +       │
│   Notifications │    │                  │    │   Prompts       │
└─────────────────┘    └──────────────────┘    └─────────────────┘

実用的なユースケース

1. PR作成フロー

開発者: 「このブランチの変更でPRを作りたい」
Claude: analyze_code → get_pr_details → 適切なテンプレート提案

2. CI監視フロー

GitHub: ワークフロー失敗 → Webhook受信
Claude: analyze_ci_results → troubleshoot_workflow_failure

3. チーム通知フロー

Claude: format_ci_failure_alert → send_slack_notification
結果: 構造化された失敗通知がSlackに投稿

学んだベストプラクティス

1. ツール設計の原則

単一責任: 各ツールは1つの明確な機能
再利用性: 他のワークフローでも使える汎用性
エラー耐性: 失敗時の適切な情報提供

2. プロンプト活用法

構造化ガイダンス: 複雑なタスクの段階的実行
一貫性確保: チーム全体で統一されたアウトプット
文脈提供: 利用可能なツールとリソースの最適活用

3. 統合パターン

関心の分離: Webhook受信とMCP機能の分離
イベント駆動: リアルタイム処理とバッチ処理の使い分け
段階的構築: Module単位での機能追加・テスト

4. トラブルシューティング

接続確認: Webhook URL、MCP接続の段階的検証
ログ活用: 各段階での詳細ログ出力
手動テスト: curlコマンドでのWebhookシミュレーション

実践的な応用アイデア

Unit3で学んだMCPパターンは、開発チームの様々な課題解決に応用できる。特に手作業の自動化と情報の可視化において威力を発揮する。

プロジェクト管理の自動化

Jira連携によるチケット自動作成・更新や、変更内容に基づく適切なレビュアー推薦により、プロジェクト管理の負荷を大幅に軽減できる。PRの内容を分析してタスクを自動起票したり、過去の履歴から最適な担当者を提案することで、チームの生産性が向上する。

運用の完全自動化

CI/CD成功時の自動デプロイトリガーや、成功率・所要時間のメトリクス収集により、運用プロセスの完全自動化が実現できる。人的ミスを排除し、一貫した品質でのリリースが可能になる。

マルチプラットフォーム対応

GitLab CI、Azure DevOps、Discord/Teamsなど、既存のツールチェーンに関係なく同じパターンを適用できる。MCPの標準化されたアプローチにより、プラットフォーム固有の実装に縛られることなく、チーム全体のワークフローを統一できる。

個人的な感想

Unit3は実際の開発チームで即座に活用できる実用的な内容だった。特に印象的だったのは：

MCPプリミティブの組み合わせの威力: 単体では単純な機能も、組み合わせることで高度な自動化を実現
段階的な構築アプローチ: Module単位で機能を追加し、最終的に統合する設計の美しさ
実用性の高さ: CodeCraft Studiosの課題は多くの開発チームが抱える現実的な問題である

特に有用だと感じた点

Webhook + MCP の組み合わせ: 外部イベントとAI処理の自然な連携
プロンプトによる標準化: チーム全体で一貫した品質の自動化
段階的テスト手法: 各コンポーネントの独立検証から統合テストまで

MCPの真価は、このような実用的なワークフロー自動化にあると実感した。

参考: Hugging Face MCP Course Unit3

# Hugging Face MCP Course Unit3: 高度なMCPワークフローサーバー構築 学習メモ