🎸
Claude Code の MCP と commands で実現する開発ワークフロー最適化

2025/10/19に公開
 はじめに複数のプロジェクトを並行して進める開発現場では、それぞれのプロジェクトのドキュメンテーション、コーディング規約、開発フローを効率的に管理することが重要です。しかし、プロジェクトごとの独自ルール、クラウドプロバイダーごとの設計ガイドライン、リポジトリ間の知識の分散など、管理すべき情報は膨大です。
本記事では、Claude Code の MCP（Model Context Protocol） と commands 機能を活用して、複数プロジェクトのドキュメンテーションとコーディングを体系的に管理し、開発効率を劇的に向上させる実践的な手法を紹介します。

 従来のマルチプロジェクト開発の課題
 よくある問題
コンテキストスイッチコスト: プロジェクト間移動時の認知負荷が高い

ドキュメント散在: 設計書、ガイドライン、仕様書が各所に散らばる

設計標準の参照: Azure、AWS など、プロバイダーごとの設計指針を都度調べる手間

コーディング規約の不統一: プロジェクトごとの独自ルールの把握が困難

AI への指示の非効率: 毎回同じ前提条件を説明する必要がある

PR レビュー対応: コメントへの対応で仕様書やガイドラインを何度も参照

 解決すべき課題プロジェクト固有の知識を体系的に管理
AI に対する指示の効率化と品質向上
クラウドサービスの公式ドキュメントへの素早いアクセス
リポジトリ間のナレッジ共有
PR レビューコメント対応の効率化

 解決アプローチ: Claude Code の MCP + commands エコシステム本記事で提案する解決策は、Claude Code の MCP（Model Context Protocol）と commands 機能を中核とした、体系的なプロジェクト管理システムです。以下、その全体像と各コンポーネントの役割を詳しく説明していきます。

 全体アーキテクチャまず、システム全体の構造を見てみましょう。ナレッジハブとなる documents リポジトリを中心に、各開発リポジトリを効率的に管理します。
documents/                          # ナレッジハブリポジトリ
├── .claude/
│   └── commands/                   # プロジェクト固有の AI 指示
│       ├── projectx-docs.md        # ProjectX ドキュメンテーション用
│       ├── projectx-docs-pr.md     # PR レビュー対応用
│       └── projectx-infra.md       # インフラ構築用
├── projects/                       # プロジェクトドキュメント管理
│   ├── projectx/
│   │   ├── knowledges/
│   │   │   ├── 設計ガイドライン/
│   │   │   └── 要件定義書サンプル/
│   │   └── docs/                   # 作業成果物
│   ├── projecty/
│   └── blog-drafts/
└── repos/                          # 開発リポジトリへの参照（symlink）
    ├── projectx-infra -> /path/to/repo
    ├── projectx-backend -> /path/to/repo
    └── other-projects...

開発リポジトリ（実体）/
├── .claude/
│   └── commands/                   # リポジトリ固有の開発指示
│       └── implement-feature.md
└── src/                            # ソースコード

 1. プロジェクト管理の基盤構築 - projects ディレクトリ設計プロジェクトごとのドキュメントや参照資料を体系的に管理するために、projects ディレクトリを設計します。ここでは、各プロジェクトの知識を独立して管理しつつ、共通のフォーマットで統一することで、AI が効率的に情報を理解できるようにします。

 構造設計の原則プロジェクトは独立した単位として管理し、それぞれに必要な参照資料と成果物を整理します。以下は基本的なディレクトリ構造です。
projects/
├── [プロジェクト名]/
│   ├── README.md                   # プロジェクト概要・目標
│   ├── knowledges/                 # 参照資料
│   │   ├── 設計ガイドライン/          # 設計指針
│   │   ├── 要件定義書サンプル/        # 仕様テンプレート
│   │   └── API設計ガイド/
│   └── docs/                       # 作業成果物
│       ├── 要件定義書/
│       ├── 設計書/
│       └── 運用手順書/
この構造により、プロジェクト固有の知識（設計ガイドライン、要件定義書サンプル等）と、作業成果物（実際の設計書、運用手順書等）を明確に分離できます。
実際のプロジェクトでは、以下のような README を配置して、プロジェクトの概要と目標を明確にします。
# projects/projectx/README.md

## プロジェクト概要

Azure クラウド基盤上に構築される Web サービスのシステム開発プロジェクト

## ドキュメンテーションのゴール

- [ ] 設計ガイドライン準拠の設計書作成
- [ ] Azure DevOps 連携の要件定義書整備
- [ ] Infrastructure as Code の設計ドキュメント
- [ ] PR レビューコメントへの効率的対応

## 制約・前提条件

- 設計ガイドライン準拠必須
- Azure DevOps での管理
- Infrastructure as Code（Terraform）採用
- セキュリティ設計優先

## 参照資料

- `knowledges/設計ガイドライン/`: 設計原則・ベストプラクティス
- `knowledges/要件定義書サンプル/`: 文書フォーマット

 2. MCP サーバーの戦略的活用Claude Code は複数の MCP サーバーに対応しており、それぞれが特定のドメインに特化した強力な機能を提供します。

 MCP サーバーの選択ガイドタスクに応じて適切な MCP を選択することで、効率的な開発が可能になります。


タスク
推奨 MCP
用途・理由


Azure ドキュメント参照
ms-learn-docs
公式ドキュメントへの直接アクセス、コードサンプル取得

AWS ドキュメント参照
aws-docs
公式ドキュメントの検索、ページ取得、関連ページ推薦

Azure DevOps 操作
ado
Work Item、PR、Wiki、Build/Pipeline の統合管理

Azure リソース情報取得
azure-terraform
サブスクリプション一覧、リソースグループ一覧

コードベース解析
serena
シンボル検索、リファレンス検索、リファクタリング

Web ページ操作
playwright
UI テスト、スクリーンショット、フォーム入力


 Azure プロジェクトでの MCP 活用例ここでは、Azure プロジェクトを例に、各 MCP サーバーの具体的な活用方法を見ていきます。
1. Azure 公式ドキュメントの即座参照 - ms-learn-docs MCP
Azure の公式ドキュメントを参照する作業を、従来の手作業から MCP を使った自動化に変えることで、大幅な時間短縮が可能です。
従来のワークフロー：
1. ブラウザで Azure Portal を開く
2. ドキュメント検索
3. 該当ページを読む
4. 情報をコピー
5. 設計書に転記
MCP 活用後：
# Claude Code に指示

「Azure App Service の料金プランについて、Standard と Premium の違いを
ms-learn-docs MCP で調べて、比較表を作成してください」

→ Claude が自動的に公式ドキュメントを検索・取得して比較表を生成
実行例
// Claude が内部的に実行する処理
mcp__ms-learn-docs__microsoft_docs_search({
  query: "Azure App Service pricing tiers Standard Premium comparison"
})

// 結果を元に設計書に記載
2. Azure DevOps との統合 - ado MCP
Azure DevOps との連携により、PR レビューコメントへの対応を大幅に効率化できます。以下は、PR レビュー対応を自動化する command の例です。
# .claude/commands/projectx-docs-pr.md

# ProjectX ドキュメンテーション PR レビュー対応

## 実行手順

1. ado MCP で PR コメント一覧を取得
2. 各コメントの内容を分析
3. 設計ガイドラインを参照して修正案を作成
4. 修正内容を適用
5. 修正理由をコメントで返信

## 使用 MCP

- `mcp__ado__repo_list_pull_request_threads`: PR コメント取得
- `mcp__ado__repo_reply_to_comment`: コメント返信
- `mcp__ms-learn-docs__microsoft_docs_search`: Azure ドキュメント参照
3. コードベース解析 - serena MCP
大規模なコードベースでは、特定のクラスやメソッドがどこで使われているかを把握するのが困難です。serena MCP を使えば、セマンティックな解析により、効率的にコードの関連性を理解できます。
# リポジトリ内の特定クラスの参照箇所を調査

serena MCP の `find_referencing_symbols` を使用して、
`UserService` クラスを参照している全箇所を把握

 AWS プロジェクトでの MCP 活用例Azure だけでなく、AWS プロジェクトでも同様に MCP を活用できます。aws-docs MCP を使えば、AWS の公式ドキュメントを素早く参照し、ベストプラクティスに基づいた設計が可能です。
aws-docs MCP でベストプラクティスを参照
# Claude Code に指示

「AWS Lambda の同時実行数制限について、aws-docs MCP で
公式ドキュメントを確認し、設計書に反映してください」

→ Claude が公式ドキュメントを取得して要約・設計書に記載

 3. .claude/commands の活用 - プロジェクト固有の AI 指示体系化
 commands の設計思想commands は、頻繁に行う作業の AI への指示をテンプレート化し、再利用可能にする Claude Code の強力な機能です。これにより、以下のような効果が得られます。
commands を使うことで得られる効果
毎回同じ前提条件を説明する手間を削減
品質の一貫性を確保
チーム内での指示の標準化

 実践例: プロジェクト固有の commands実際のプロジェクトでは、用途に応じて複数の command を作成します。ここでは、3つの代表的な command の例を紹介します。
1. ドキュメンテーション作業用 - projectx-docs.md
# ProjectX ドキュメンテーション作成

## 前提条件の読み込み

作業開始前に、以下のドキュメントを必ず読み込んでください：

1. **設計ガイドライン**
   - `projects/projectx/knowledges/設計ガイドライン/README.md`
   - 特に以下のセクションを重点的に確認：
     - セキュリティ設計
     - クラウドアーキテクチャ構成
     - 可用性設計

2. **要件定義書サンプル**
   - `projects/projectx/knowledges/要件定義書サンプル/`
   - 文書フォーマットとして参照

## 作業指針

### ドキュメント作成時

- 設計ガイドライン準拠を最優先
- ms-learn-docs MCP で Azure 公式ドキュメントを参照
- 設計根拠を明確に記載
- セキュリティ・可用性の考慮を明記

### 使用ツール

- **ms-learn-docs MCP**: Azure 公式ドキュメント参照
- **ado MCP**: Azure DevOps Work Item との連携
- **serena MCP**: リポジトリのコード解析

## 出力形式

- Markdown 形式
- 図表は Mermaid 記法を使用
- コードブロックは言語指定必須
2. PR レビュー対応用 - projectx-docs-pr.md
# ProjectX PR レビューコメント対応

## 目的

Azure DevOps の PR レビューコメントに対して、設計ガイドラインに
準拠した修正を効率的に実施する。

## 実行手順

### Step 1: PR コメント取得

```bash
# ado MCP を使用して PR のコメントスレッド一覧を取得
mcp__ado__repo_list_pull_request_threads({
  project: "ProjectX",
  repositoryId: "[repo-id]",
  pullRequestId: [pr-id]
})
\```

### Step 2: 各コメントの分析

- コメント内容の分類
  - セキュリティ指摘
  - 可用性指摘
  - 設計変更要求
  - その他

### Step 3: 設計ガイドライン参照

指摘内容に応じて、関連するガイドラインセクションを確認：

- セキュリティ → セキュリティ設計ドキュメント
- 可用性 → 可用性設計ドキュメント
- Azure 構成 → クラウドアーキテクチャ構成ドキュメント

### Step 4: 修正案作成

- 設計ガイドライン準拠の修正案を作成
- ms-learn-docs MCP で Azure 公式ドキュメントを確認
- 修正理由を明確に記述

### Step 5: コメント返信

```bash
# ado MCP でコメント返信
mcp__ado__repo_reply_to_comment({
  repositoryId: "[repo-id]",
  pullRequestId: [pr-id],
  threadId: [thread-id],
  content: "修正内容と理由"
})
\```

## 注意事項

- 全ての修正は設計ガイドライン準拠
- セキュリティ関連の変更は特に慎重に
- 修正理由を必ず記載
3. インフラ構築用 - projectx-infra.md
# ProjectX Infrastructure as Code

## 前提条件

### 参照ドキュメント

1. `projects/projectx/knowledges/設計ガイドライン/`
   - クラウドアーキテクチャ構成
   - ネットワーク設計
   - セキュリティ設計

2. リポジトリ: `repos/projectx-infra`
   - Terraform コードベース
   - 既存のモジュール構成を確認

### 使用 MCP

- **azure-terraform MCP**: Azure リソース情報取得
- **ms-learn-docs MCP**: Azure サービス仕様確認
- **serena MCP**: Terraform コード解析

## 設計原則

### セキュリティ

- Private Endpoint の利用
- NSG による通信制御
- Key Vault による機密情報管理
- マネージド ID の活用

### 可用性

- Availability Zone の活用
- 自動スケーリング設定
- バックアップ戦略

### コスト最適化

- 適切な SKU 選択
- Auto-Shutdown 設定
- Reserved Instance の検討

## 作業フロー

1. **要件確認**: Work Item から要件を確認
2. **設計**: 設計ガイドラインに基づき設計
3. **実装**: Terraform コード作成
4. **レビュー**: 設計書と照合
5. **テスト**: terraform plan での確認

 4. リポジトリ管理戦略 - repos ディレクトリ + symlink
 Symlink を使った効率的な参照システム複数の開発リポジトリを効率的に管理するために、symlink（シンボリックリンク）を活用します。これにより、documents リポジトリから各開発リポジトリを参照し、AI が複数のコードベースを横断的に理解できるようになります。
この仕組みには以下のメリットがあります。
Symlink 活用の目的
documents リポジトリから開発リポジトリを参照
AI が複数リポジトリのコードベースを理解
リポジトリ間のナレッジ共有
以下は、具体的なディレクトリ構造と symlink の作成例です。
構造
documents/
└── repos/
    ├── projectx-infra -> ~/workspace/projectx/infra
    ├── projectx-backend -> ~/workspace/projectx/backend
    ├── projectx-frontend -> ~/workspace/projectx/frontend
    └── other-project -> ~/workspace/other-project

# symlink 作成例
cd documents/repos
ln -s ~/workspace/projectx/infra projectx-infra
この構造により、Claude Code は symlink を通じて実際のリポジトリを参照し、設計ガイドラインとコードベースを照合した分析が可能になります。
活用シーン
実際の利用例を見てみましょう。以下のように指示することで、Claude が自動的にコードを確認し、設計書を更新します。
# Claude Code に指示

「repos/projectx-infra の Terraform コードを確認して、
現在のネットワーク構成を設計書に反映してください。
設計ガイドラインのネットワーク設計と照合して、
準拠状況を確認してください。」

→ Claude が symlink 経由でリポジトリを参照し、
  ガイドラインと照合して設計書を更新

 5. wasabeef/claude-code-cookbook の活用Claude Code を使いこなすには、コミュニティのナレッジも重要です。wasabeef/claude-code-cookbook は、Claude Code の実践的な使い方をまとめた貴重なリソースで、様々なユースケースやベストプラクティスが公開されています。

 活用ポイント1. commands のテンプレート参照
cookbook には、様々なシナリオに対応した command のテンプレートが掲載されています。これらを参考にすることで、自分のプロジェクトに適した command を素早く作成できます。
主な参考例：
テスト自動生成のコマンド
リファクタリングのベストプラクティス
ドキュメント生成の効率的な指示方法
2. MCP の実践的な使い方
cookbook には様々な MCP の使用例が掲載されており、自分のプロジェクトに応用できます。特に、複数の MCP を組み合わせた高度な活用例は参考になります。
3. プロジェクト構造のベストプラクティス
効果的なプロジェクト構造の設計方法も学べます。
.claude ディレクトリの効果的な構成
commands の命名規則
チーム開発での運用方法

 6. 統合ワークフロー例ここまで紹介した各機能を組み合わせることで、実際の業務フローがどのように改善されるか、具体的なシナリオで見ていきましょう。

 シナリオ: Azure DevOps PR レビューコメントへの対応PR レビューコメントへの対応は、設計ガイドラインやクラウドサービスの公式ドキュメントを何度も参照する必要があり、時間のかかる作業です。MCP と commands を活用することで、この作業を大幅に効率化できます。
従来のワークフロー（約 2 時間）
1. Azure DevOps で PR を開く
2. レビューコメントを確認
3. 設計ガイドラインをブラウザで開く
4. 該当セクションを検索
5. Azure ドキュメントで仕様確認
6. 修正内容を検討
7. 設計書を修正
8. PR コメントに返信
MCP + commands 活用後（約 20 分）
# Claude Code で `/projectx-docs-pr` コマンドを実行

→ Claude が自動的に：

1. ado MCP で PR コメント取得
2. コメント内容を分析
3. 設計ガイドラインを参照
4. ms-learn-docs MCP で Azure 公式ドキュメント確認
5. 修正案を作成
6. 設計書を更新
7. ado MCP でコメント返信

ユーザーは最終確認のみ実施
実際の Claude への指示例
このシンプルな指示だけで、Claude が自動的に一連の作業を実行します。
/projectx-docs-pr

PR #36 のレビューコメントに対応してください。
特にセキュリティに関する指摘については、
設計ガイドラインのセキュリティ設計を
厳密に確認してください。

 シナリオ: 新規 Azure リソースの設計書作成もう一つの実例として、新規リソースの設計書作成のワークフローを見てみましょう。ここでも、複数の MCP を組み合わせて効率的に作業を進めます。
MCP + commands 活用ワークフロー
# Claude Code で `/projectx-infra` コマンドを実行

「Azure App Service の新規構築設計書を作成してください。
要件は Work Item #1234 を参照。」

→ Claude が自動的に：

1. ado MCP で Work Item #1234 取得
2. 設計ガイドラインを確認
   - クラウドアーキテクチャ構成
   - 可用性設計
   - セキュリティ設計
3. ms-learn-docs MCP で App Service の仕様確認
4. azure-terraform MCP で既存リソース確認
5. 設計書を生成
   - セキュリティ設計
   - 可用性設計
   - ネットワーク設計
   - コスト見積もり
6. Mermaid 図を含む包括的なドキュメント作成

 実装結果と効果測定ここまで紹介してきた手法を実際のプロジェクトに導入した結果、以下のような顕著な効果が得られました。定量的なデータとともに、具体的な改善内容を見ていきます。

 導入前後の比較まず、主要な作業項目における導入前後の比較です。ほとんどの項目で大幅な効率化が実現できています。


項目
導入前
導入後
改善率


PR レビュー対応時間
2 時間
20 分
83%短縮

設計書作成時間
1-2 日
3-4 時間
80%短縮

ガイドライン参照回数
毎回検索
自動参照
95%削減

ドキュメント品質一貫性
個人差大
統一
大幅改善

プロジェクト間移動の認知負荷
高
低
60%削減


 具体的な成果
 1. PR レビュー対応の劇的な効率化従来の作業（約 2 時間）
- コメント確認: 15 分
- 設計ガイドライン検索: 30 分
- Azure ドキュメント確認: 30 分
- 修正内容検討: 30 分
- 設計書修正: 15 分
- コメント返信: 10 分
MCP + commands 活用後（約 20 分）
- コマンド実行: 1 分
- AI による自動処理: 15 分
- ユーザーの最終確認: 4 分

 2. マルチプロジェクト管理の効率化複数プロジェクトの並行管理も、以下のような構造で効率化されました。各プロジェクトで同じ commands を実行するだけで、自動的に適切なガイドラインと MCP が使用されます。
projects/
├── projectx/           # Azure プロジェクト
│   ├── knowledges/
│   │   └── 設計ガイドライン/      # Azure 設計指針
│   └── docs/
├── projecty/           # AWS プロジェクト
│   ├── knowledges/
│   │   └── 設計ガイドライン/      # AWS 設計指針
│   └── docs/
└── [その他のプロジェクト]/

各プロジェクトで commands を実行すれば、
自動的に適切なガイドラインと MCP を使用

 3. 知識の体系的蓄積プロジェクトの知識が体系的に蓄積され、チーム資産として継続的に価値を生み出す仕組みが確立されました。
documents/
├── projects/
│   └── [プロジェクト別の整理された知識]
├── repos/
│   └── [リポジトリコードへの参照]
└── .claude/
    └── commands/
        └── [再利用可能な AI 指示]

→ チーム資産として継続的に価値を生み出す

 導入時の注意点とコツここまで紹介してきた MCP と commands を活用したワークフローを実際に導入する際の、実践的なアプローチと注意点を解説します。段階的に導入することで、チーム全体でスムーズに移行できます。

 1. 段階的な導入ステップ
 Phase 1: 基盤構築最初のフェーズでは、プロジェクトの基本的な構造を整備し、最小限の commands を作成して動作を確認します。
## 基本構造の整備

### プロジェクト構造設計
- projects/ ディレクトリ設計
- README.md テンプレート作成

### 最初の commands 作成
- 最も頻繁に行う作業を特定
- コマンドテンプレート作成

### MCP 接続確認
- 必要な MCP サーバーの特定
- 接続テスト・動作確認

 Phase 2: 実践・改善基盤が整ったら、実際の業務で使い始め、フィードバックを収集して改善を重ねます。
## 実運用での検証

- 実際のタスクで commands を使用
- フィードバック収集
- commands の改善・追加
- チームメンバーへの共有

 Phase 3: 拡張・最適化ワークフローが定着したら、新しいユースケースを発見し、継続的に改善していきます。
## 継続的改善

- 新しいユースケースの発見
- commands の充実化
- ベストプラクティスのチーム内共有

 2. commands 設計のベストプラクティスcommands の品質は、その具体性と実行可能性で決まります。良い commands と悪い commands の違いを具体例で見ていきましょう。

 ✅ 良い commands の特徴# ✅ 良い例: 具体的で実行可能

# ProjectX セキュリティ設計書作成

## 前提条件
[具体的なファイルパスを明記]

## 実行手順
[ステップバイステップで記載]

## 使用 MCP
[明示的に指定]

## 出力形式
[具体的な期待値]

 ❌ 避けるべき commands# ❌ 悪い例: 曖昧で抽象的

「設計書を作成してください」

→ 前提条件が不明確
→ どの MCP を使うべきか不明
→ 出力形式が不明確

 3. セキュリティとアクセス管理MCP サーバーとの接続には認証情報が必要です。これらの機密情報を適切に管理し、セキュリティリスクを最小化することが重要です。

 MCP 認証情報の管理# 環境変数での管理
export AZURE_DEVOPS_PAT="xxx"
export AZURE_SUBSCRIPTION_ID="xxx"
export AWS_PROFILE="your-profile"

# .gitignore に追加
.env
.claude/secrets/

 アクセス権限の最小化MCP サーバーに付与する権限は、必要最小限に留めることがセキュリティのベストプラクティスです。以下は Azure DevOps の例です。
## Azure DevOps PAT の権限設定

最小権限の原則に従い、必要な権限のみ付与：

- Work Items: Read & Write
- Code: Read
- Build: Read
- Wiki: Read & Write

 4. チーム展開のコツ個人での活用から、チーム全体への展開を成功させるには、適切なオンボーディング資料とサポート体制が重要です。

 ドキュメント整備# team-onboarding.md

## セットアップ手順

1. documents リポジトリのクローン
2. .claude/commands/ の確認
3. 必要な MCP の接続設定
4. 最初のコマンド実行テスト

## よく使うコマンド

- `/projectx-docs`: ドキュメント作成
- `/projectx-docs-pr`: PR レビュー対応
- `/projectx-infra`: インフラ設計

## トラブルシューティング

[よくある問題と解決方法]

 まとめClaude Code の MCP と commands を活用することで、マルチプロジェクト開発における以下の課題を解決できます：

 主要な効果作業効率の劇的向上
PR レビュー対応: 83%時間短縮
設計書作成: 80%時間短縮
ガイドライン参照: 95%削減
品質の一貫性確保
設計ガイドライン準拠の自動確認
公式ドキュメントに基づく設計
チーム全体での標準化
知識の体系的管理
プロジェクト単位での整理
再利用可能な commands
チーム資産としての蓄積
認知負荷の削減
プロジェクト間移動のスムーズ化
前提条件の自動適用
コンテキストスイッチコストの最小化

 成功の鍵体系的な構造設計
projects/ でのプロジェクト管理
repos/ での開発リポジトリ参照
.claude/commands/ での指示体系化
MCP の戦略的活用
タスクに応じた適切な MCP 選択
複数 MCP の組み合わせ
公式ドキュメントへの直接アクセス
再利用可能な commands
具体的で実行可能な指示
プロジェクト固有の知識の埋め込み
チーム内での共有と改善
段階的な導入
小さく始めて徐々に拡大
フィードバックに基づく改善
チーム全体への展開
この手法により、開発作業が「個人の属人的なスキル」から「チーム全体で共有・改善できる体系的なプロセス」へと進化し、継続的な価値創造が可能になります。
Claude Code の MCP と commands は、単なるツールではなく、チーム開発の新しいパラダイムを提供します。ぜひ、あなたのプロジェクトでも実践してみてください。

 関連リソース
 公式ドキュメントClaude Code 公式ドキュメント
Model Context Protocol (MCP) 仕様
Azure DevOps API ドキュメント

 コミュニティリソース
wasabeef/claude-code-cookbook - Claude Code のベストプラクティス集

MCP Servers リスト - 公式 MCP サーバー一覧
タスク	推奨 MCP	用途・理由
Azure ドキュメント参照	ms-learn-docs	公式ドキュメントへの直接アクセス、コードサンプル取得
AWS ドキュメント参照	aws-docs	公式ドキュメントの検索、ページ取得、関連ページ推薦
Azure DevOps 操作	ado	Work Item、PR、Wiki、Build/Pipeline の統合管理
Azure リソース情報取得	azure-terraform	サブスクリプション一覧、リソースグループ一覧
コードベース解析	serena	シンボル検索、リファレンス検索、リファクタリング
Web ページ操作	playwright	UI テスト、スクリーンショット、フォーム入力
項目	導入前	導入後	改善率
PR レビュー対応時間	2 時間	20 分	83%短縮
設計書作成時間	1-2 日	3-4 時間	80%短縮
ガイドライン参照回数	毎回検索	自動参照	95%削減
ドキュメント品質一貫性	個人差大	統一	大幅改善
プロジェクト間移動の認知負荷	高	低	60%削減
はじめに

従来のマルチプロジェクト開発の課題

よくある問題

解決すべき課題

解決アプローチ: Claude Code の MCP + commands エコシステム

全体アーキテクチャ

1. プロジェクト管理の基盤構築 - projects ディレクトリ設計

構造設計の原則

2. MCP サーバーの戦略的活用

MCP サーバーの選択ガイド

Azure プロジェクトでの MCP 活用例

AWS プロジェクトでの MCP 活用例

3. .claude/commands の活用 - プロジェクト固有の AI 指示体系化

commands の設計思想

実践例: プロジェクト固有の commands

4. リポジトリ管理戦略 - repos ディレクトリ + symlink

Symlink を使った効率的な参照システム

5. wasabeef/claude-code-cookbook の活用

活用ポイント

6. 統合ワークフロー例

シナリオ: Azure DevOps PR レビューコメントへの対応

シナリオ: 新規 Azure リソースの設計書作成

実装結果と効果測定

導入前後の比較

具体的な成果

1. PR レビュー対応の劇的な効率化

2. マルチプロジェクト管理の効率化

3. 知識の体系的蓄積

導入時の注意点とコツ

1. 段階的な導入ステップ

Phase 1: 基盤構築

Phase 2: 実践・改善

Phase 3: 拡張・最適化

2. commands 設計のベストプラクティス

✅ 良い commands の特徴

❌ 避けるべき commands

3. セキュリティとアクセス管理

MCP 認証情報の管理

アクセス権限の最小化

4. チーム展開のコツ

ドキュメント整備

まとめ

主要な効果

成功の鍵

関連リソース

公式ドキュメント

コミュニティリソース

Discussion
