先月、MCPサーバーを使ったドキュメント管理のセミナーを実施した。
デモの中でうまく説明しきれなかったり、少し躓いた場面もあった。だが、「調達先を変更する」というたった一つの指示から、影響範囲の特定→分析→レポート生成→承認フローまでが自動で流れる様子を見た参加者の反応は、明らかに変わった。
本記事では、セミナーで実演した内容と、その先に見えるMCPの未来像を記録する。
なぜドキュメント管理にMCPなのか
MCP（Model Context Protocol）は、Anthropicが提唱するAIとツールを接続するためのオープンプロトコルだ。Claude DesktopやClaude Codeなどのクライアントから、外部のデータソースやツールにアクセスできるようにする仕組みで、AIの「手足」を拡張する。
ドキュメント管理における課題は明確だ。
- 仕様書、取引先台帳、品質基準書、カタログ——複数部署にまたがるドキュメントが散在している
- 1つの変更が、どのドキュメントに影響するか手作業で追うしかない
- 影響範囲の洗い出しに2〜3時間かかり、見落としが発生する
- Excelで影響範囲表を手作業で作成し、メールで個別に連絡する
MCPサーバーを使えば、Claudeが直接ドキュメントを検索・分析・レポート生成できる。AIがドキュメントを「読んで」「判断して」「レポートにまとめる」——この一連の流れを自動化できるのがMCPの強みだ。
セミナーで実演したデモシナリオ
デモで使った状況設定は以下のとおり。
状況: 部品X-250の調達先を「サンエイ工業」から「タカハシ製作所」に変更する必要が生じた
現場では日常的に起こるシナリオだ。調達先の変更は、仕様書、取引先台帳、品質基準書、製品カタログなど、複数のドキュメントに波及する。どのドキュメントが影響を受けるのか、どの部署に連絡が必要なのか。これを人手で調べるのは骨が折れる。
MCPサーバーに実装した4つのツールで、この課題を解決した。
ステップ1：キーワード横断検索
最初のステップは、「サンエイ工業」がどのドキュメントに記載されているかの特定だ。
MCPサーバーの spec.search ツールに「サンエイ工業」と入力すると、約10秒で全ドキュメントを横断検索する。
結果は即座に返ってくる。
- 設計部の部品仕様書：2箇所
- 購買部の取引先台帳：6箇所
- 品質保証部の品質基準書：2箇所
- 営業部の製品カタログ：6箇所
合計4ドキュメント、16箇所。従来はファイルを1つずつ開いて「Ctrl+F」で検索していた作業が、一発で完了する。部署別のフォルダ構成だろうが関係なく、自動的に探索される。
セミナーでこの結果が表示された瞬間、参加者から「おお」と声が上がった。正直、一番反応が大きかったのはこの瞬間だった。シンプルだが、「今まで手でやっていたこと」が一瞬で終わるインパクトは大きい。
ステップ2：影響範囲分析（部署情報付き）
検索結果だけでは「どこに書いてあるか」しかわからない。次に必要なのは、**「誰に連絡すべきか」「影響度はどの程度か」**という判断だ。
MCPサーバーの analyze_impact_with_departments ツールは、ドキュメントのメタデータ（Frontmatter）から部署情報と関連ドキュメントを自動抽出し、影響範囲を分析する。
このツールが返す分析結果は以下のようなものだ。
| ファイル | 管理部門 | 影響度 | 関連部署 |
|---|---|---|---|
| 部品仕様書_X-250 | 設計部 | high | 購買部, 品質保証部, 営業部 |
| 取引先台帳_サンエイ工業 | 購買部 | high | 設計部, 財務部, 品質保証部 |
| 品質基準書_QS-2024-001 | 品質保証部 | high | 設計部, 購買部, 製造部 |
| 製品カタログ_2024年版 | 営業部 | medium | 設計部, マーケティング部 |
影響度（high/medium/low）は、related_departmentsの数に基づいて自動判定される。関連部署が多いほど影響度が高い。
ポイントはメタデータ駆動であること。各ドキュメントのFrontmatter（YAML形式）に管理部門と関連部署を記述しておくことで、MCPサーバーがこれを読み取り、自動で影響範囲を算出する。人間が毎回判断する必要がない。
ステップ3：Excelレポート自動生成
分析結果を見て「なるほど」と思っても、それだけでは仕事は進まない。関係部署に共有できる形式のレポートが必要だ。
MCPサーバーの generate_impact_report ツールは、影響範囲分析の結果をExcel形式で自動生成する。
生成されるExcelの構成は以下のとおり。
- シート1 - サマリー：影響ファイル数、変更箇所数、影響部署数
- シート2 - 影響ファイル一覧：ファイル名、管理部門、影響度、関連部署の詳細
- シート3 - 影響部署リスト：連絡が必要な全部署
- シート4 - 変更プレビュー：変更前/変更後の具体的な内容
Excel形式にしたのは理由がある。非エンジニアの関係部署にも共有しやすいからだ。設計部や購買部の担当者にJSON形式やMarkdownのレポートを送っても読んでもらえない。Excelなら、そのまま会議資料や承認申請の添付資料として使える。
セミナーでは「Excelで出てくるのか」という反応が多かった。AIツールのアウトプットは往々にして「エンジニア向け」になりがちだが、現場で使えるフォーマットで出力することが実用化の鍵だ。
さらに、レポートの共有と会議設定までMCPで自動化できる。「関係部署にSlackで共有して、来週月曜14時に調整会議を設定して」——この一言で、Slack通知と会議設定が自動実行される。
ステップ4：関連ドキュメントの芋づる式検索
ステップ2で直接的な影響範囲は把握できた。しかし、実際の業務では間接的に影響を受けるドキュメントもある。
MCPサーバーの find_related_documents ツールは、メタデータの related_documents フィールドを辿って、関連するドキュメントを再帰的に検索する。
たとえば、部品仕様書を起点に深度2まで検索すると、直接リンクされている取引先台帳だけでなく、そこからさらにリンクされている品質基準書や製品カタログまで芋づる式に発見できる。
この機能はドキュメント間の依存関係の可視化に役立つ。「この仕様書を変更すると、どこまで影響が波及するのか」という問いに、定量的に答えられる。
ステップ5：GitHub Issueによる承認フロー
影響範囲の分析とレポート生成が完了したら、次は承認プロセスだ。
MCPサーバーの request_change ツールは、分析結果を基にGitHub Issueを自動作成する。Issueには影響範囲のサマリー、変更箇所数、変更理由が記載され、関係者のレビューを経て approved ラベルが付与されると、自動で変更が実装される。
承認フローの流れは以下のとおり。
- 変更申請：MCPサーバーがGitHub Issueを作成（
needs-reviewラベル） - レビュー：関係者がIssue上で内容を確認
- 承認：
approvedラベルを付与 - 自動実装：MCPサーバーが変更を実行し、Pull Requestを作成
- マージ：PRレビュー後にマージして完了
変更履歴の完全なトレーサビリティが確保される。「誰が」「いつ」「なぜ」変更したのかが、すべてGitHubに記録される。監査対応やISO審査でも、この記録が効力を発揮する。
追加デモ：代替部品の比較分析
セミナーでは、ドキュメント管理に加えて代替部品の比較分析も実演した。MCPサーバーがSupabaseの仕入先データベースを横断検索し、条件に合う代替部品を自動でリストアップする。
リストアップだけでなく、詳細比較分析まで自動で行う。価格・納期・品質を多軸で評価し、各部品の総合評価を算出する。
さらに、用途別の選定ガイドラインまで生成される。最高品質が求められる車・医療向け、コストダウン、短納期優先など、シーン別に推奨部品と理由が整理される。
この一連の流れ——データ収集、比較分析、選定ガイドライン生成——が1回の指示で完了する。従来なら担当者が各仕入先に問い合わせ、カタログを取り寄せ、Excelで比較表を作成していた作業だ。
ビフォー・アフター：2〜3時間 → 約1分
セミナーの最後に示した比較スライドは、最もインパクトがあった部分だ。
従来の方法（手作業）
- 全ドキュメントを手動で開いて検索
- Excelで影響範囲表を手作業で作成
- 関係部署をリストアップ
- メールで個別に連絡
- 所要時間：2〜3時間
MCPサーバーを使った方法
- キーワード横断検索（10秒）
- 影響範囲分析（20秒）
- Excelレポート生成（30秒）
- 所要時間：約1分
時間短縮だけではない。品質も上がる。手作業では見落としが発生する。特に部署をまたぐドキュメントの影響は、担当者の知識と経験に依存する。MCPサーバーならメタデータに基づいて機械的に洗い出すため、漏れが発生しない。
MCPサーバーの技術構成
技術的な構成についても触れておく。
- ランタイム：Node.js + TypeScript
- プロトコル：MCP（Model Context Protocol）
- クライアント：Claude Desktop
- メタデータ形式：YAML Frontmatter
- レポート出力：ExcelJS
- 承認フロー：GitHub API（Issue + Pull Request）
MCPサーバーの核心は、ドキュメントにメタデータを付与する設計にある。各ドキュメントの冒頭にYAML形式で管理部門、関連部署、関連ドキュメントを記述する。このメタデータがあるからこそ、MCPサーバーは「検索」だけでなく「分析」まで行える。
逆に言えば、メタデータのない既存ドキュメントにはそのまま適用できない。導入の第一歩はドキュメントへのメタデータ付与だ。ここはAI社員に任せることもできるが、最初の設計は人間が行う必要がある。
セミナーを終えて
デモの中で、説明がうまく噛み合わない場面や、少し躓く場面はあった。だが、参加者の反応から確信したことがある。
響いたポイント
- ステップ1の横断検索は、シンプルさゆえにインパクトが大きかった
- Excel出力は「現場で使える」という反応を得られた
- ビフォー・アフターの比較は説得力があった
- 「会議が1-2回で済む未来」に最も食いつきがあった
次回に向けて
- MCPの概念説明は「AIに手足が生えた」というメタファーで3分にまとめる
- 技術的な詳細より、業務フローがどう変わるかにフォーカスする
- 複数システム連携のデモを追加し、ドキュメント管理以外の応用例も見せる
MCPが変える業務の未来
MCPサーバーの本質は、AIと業務システムの橋渡しだ。今回のデモはドキュメント管理の一例に過ぎない。セミナーの後半では、MCPが実現するさらに大きな未来像を説明した。
複数システム連携によるデータ統合
MCPの真価は、複数のシステムを横断してデータを収集・更新できることにある。
今回のデモではドキュメントの検索・分析に留まったが、MCPサーバーを複数構築すれば、ERPの在庫データ、CRMの顧客情報、プロジェクト管理ツールの進捗状況——これらを一つのAIセッションから横断的に参照・更新できる。
たとえば「調達先をタカハシ製作所に変更する」という指示ひとつで、ドキュメントの更新だけでなく、ERPの取引先マスタの変更、購買システムの発注先切り替え、品質管理システムの認証情報更新まで、関連する全システムの変更を一括で処理できる世界が見えている。
会議を「意思決定の場」に変える
MCPがもたらすもう一つの大きな変化は、会議のあり方そのものを変えることだ。
従来、ひとつの変更を完了させるまでのプロセスはこうだった。
- 情報共有MTG：「こういう変更が必要です」と関係者に説明
- 検討MTG（2〜3回）：影響範囲の洗い出し、対応方針の議論、リスク検討
- 実施後MTG：変更結果の報告と確認
- 合計：約1ヶ月
MCPサーバーがあれば、情報収集・影響分析・レポート作成はすべて事前に自動処理される。会議の参加者は、すでに整理された分析結果とレポートを手元に持った状態で会議に臨める。
つまり、会議の目的が「情報収集」や「影響範囲の議論」から、「意思決定を下す」ことだけに変わる。
MCPで実現できる新しいフローはこうだ。
- MCPが事前処理：影響分析、レポート生成、関係者への共有を自動実行
- 意思決定MTG（1〜2回）：分析結果を基に承認・却下を判断
- 合計：1〜2回のMTGで完結
約1ヶ月かかっていたプロセスが、1〜2回の会議で完結する。 会議設定すらMCPで自動化し、人間は意思決定を下すだけ。これがMCPが実現する業務の未来だ。
AI社員の「能力」を拡張するインフラ
PMBOK-AIの文脈で言えば、MCPサーバーはAI社員の「能力」を拡張するインフラだ。AI社員がドキュメントを検索し、分析し、レポートを生成し、会議を設定し、承認フローを回す。人間のPMは最終判断と承認に集中できる。
MCPはオープンプロトコルなので、自社の業務に合わせたカスタムサーバーを自由に構築できる。ドキュメント管理、在庫管理、顧客対応、品質管理——あらゆる業務にこの仕組みを展開できる。
ドキュメント管理の自動化に興味がある方、MCPサーバーの構築について相談したい方は、お問い合わせからお気軽にご連絡ください。セミナーの内容をベースに、貴社の業務に合わせたカスタマイズも可能です。