人間用ドキュメントとAIのカスタムプロンプトを一体化させる設計案

Last updated at 2026-05-12Posted at 2026-05-12

はじめに

開発中のアプリケーションのE2Eテスト、AIエージェントに任せられますか？

ここ最近のモデル進化で、E2Eテストの一連の手順 (環境立ち上げ → テスト → 確認 → 片付け) を AI エージェントに任せられるようになってきました。社内Wikiには「docker compose up -d で立ち上げて、docker compose down で片付ける」みたいなソフトウェアテスト手順書があって、人間ならそれを読んでターミナルで叩けばいい。

でもAIエージェントに同じことをやらせようとすると、いきなり詰まります。MCPサーバーの設定が個人のVS Codeにない、認証情報がない、そもそもどのMCPサーバーに繋げばいいか分からない — Slackで「ローカル開発環境のリセット用MCPって誰か作ってますか？」と聞いて → 返事を待って → 作業再開、で時間が溶けます。

一方、ドキュメント側は人間用の手順書とAI用のプロンプトが分裂しがちで、メンテコストが最大2倍になります。同じ「開発環境をリセットする」という意味のことを、社内Wikiにも書き、AIエージェント用のカスタムプロンプトファイルにも書き、片方だけ更新されて齟齬が出る。

この問題に対して、社内Wikiで MCP を管理しつつ、人間用ドキュメントとAI用カスタムプロンプトを同じドキュメントに一体化させる構成を考えてみました。MCP Gateway のような専用ツールは必要に応じて後から導入すればよい、というのが基本方針です。本記事はその設計案を共有するものです。

断り書き: 本記事は実運用で検証済みの設計ではなく、現時点で机上で組み立てた構成案です。つまり、思いつきです！エンジニア組織への試験導入を検討している段階で、実装を進める中で前提が崩れたり方針が変わったりする可能性は十分にあります。書き残しておくことで、自分自身の整理と、似た問題を考えている方との議論のきっかけになればと思って公開しています。

なお、本記事の後半では以前公開した KG Hub と組み合わせる話も扱います。KG Hub 自体の作り方は前回の記事を参照してください。

解決しようとしている問題

社内でAI活用 (GitHub Copilot, Claude Code 等) が進んでくると、こんな摩擦が見え始めるのではないかと感じています。

手順書が人間用とAI用で分裂しがち — 社内Wikiの運用手順書とAIエージェント用のカスタムプロンプトファイルに同じ内容を2回書く羽目になり、片方だけ更新されて齟齬が出る。「3か月前のプロンプトには docker compose restart app と書いてあるが、現行手順書では make restart-app 経由」みたいな状態になりやすい。
MCPサーバーの設定がチーム間で揃いにくい — 誰のVS Codeにどの mcp.json が入っているか管理しづらく、「Aさんは動いたのに自分は動かない」が起きやすい。新メンバーがオンボーディングで詰まる場面も想像できる。
業務知識から実行手段が辿りにくい — MCPサーバー一覧みたいなレジストリは作れても、「開発環境をリセットする時に何を使うか」を業務知識から辿る経路がない。一覧表を見て自分でマッピングする必要がある。

加えて、もう一つ重要なのが ガバナンス の観点です。

エージェントに作業させる方法は、shell/CLI を直接叩かせる路線と、MCP 経由で叩かせる路線に大きく分かれます。本構成は後者に寄せています。理由は中央集権的に扱えるかどうかです。

CLI 呼び出し路線は構造的に非中央集権的で、各端末で個別に shell が動くため、権限管理が分散しやすく、極論セキュリティの担保が個人の裁量になります。今は問題なくても、将来的に「誰かの個人 GitHub Copilot が何かのきっかけで本番環境を破壊した」というインシデントが起きうる構造です。一方、MCP 経由なら、「使ってよいMCP」を組織として管理しやすく、ポリシーの一括管理や緊急時の停止が現実的に効きます。

MCPの中央集権的管理という発想自体は割とあるテーマのようで、最近は専用のツールやサービスも出てきているようです。それぞれ詳しく触ったわけではないですが、参考までに：

mcpmanager.ai — SaaS型のMCP管理サービス。Private MCP Registry と RBAC で、管理者がMCPの利用を制御できる作りになっているようです
Finatextの技術ブログ記事 — MCPゲートウェイというコンセプトの解説記事。主要なMCPゲートウェイソリューションの比較もあり参考になります
IBM ContextForge — OSSのMCP Gateway。Admin UI からMCPサーバーの登録・管理ができる作りになっているようです

ただ、こうした専用ツールをいきなり導入するのは初動として重いので、本構成はまず社内Wikiで「MCP一覧」ページを管理するところから始めることを考えています。必要に応じて、後から MCP Gateway のような専用ツールに移行できる設計にしておく方針です。

やりたいこと

シンプルにまとめると、こういう状態を目指します。

人間が読むドキュメントとAIが読むプロンプトを一体化させる
MCPサーバーは必要に応じて配布
業務知識から実行手段が辿れる
任意のMCPに勝手に繋がない (安全側に倒す)

これらが揃うと、社内 GitHub Copilot や Claude Code 利用の摩擦が下がるのではないか、というのが出発点です。

設計の前提

AIエージェントを業務に組み込む時の前提として、LLMは毎回新しいプロセスとして呼び出されるという構造的な制約があります。社内の事情、過去の会話、最新の設定変更などは context window に入れない限り保持されません。基礎能力 (推論、コード生成) は持ってきてくれますが、それ以外は外部から都度渡す必要があります。

このため、AIエージェントを成立させるには、「手順」と「能力 (どのMCPを使うか)」を外部に持たせる必要があると考えました。本構成では、Markdownドキュメントが「手順」を、社内Wikiの「MCP一覧」ページが「能力」を担当します。両者を直接結ぶのではなく、ドキュメントを介して接続する点がポイントです。

(なお「業務知識」を外部に持たせる方法として KG Hub を組み合わせる発想もあって、それは本記事の後半で扱います。)

設計案: Wiki + ドキュメント + カスタムプロンプトファイル

考えている全体構造は次のようになります。

各要素の責務を整理するとこうなります。

要素	役割	採用候補
Markdown手順書	操作手順の記述 (人間/AI共通)	社内Wiki, Git管理のmd
MCP一覧Wiki	利用可能なMCPのカタログ	社内Wiki (Confluence, Notion, esa等)
カスタムプロンプトファイル	エージェント振る舞いポリシー	`copilot-instructions.md` 等
MCP Gateway	必要に応じて中央集権管理を強化	ContextForge, mcpmanager.ai 等

エージェントは手順書 → MCP Wikiページ → 接続情報とリンクを辿ることで、必要なMCPに到達できる予定です。

構成案1: 社内Wikiに「MCP一覧」ページを作る

まず、社内Wikiに次のような階層構造のページを用意します。

社内Wiki/
  MCP一覧/
    MySQL MCP/
    Redis MCP/
    Slack MCP/
    開発環境デプロイMCP/
    ...

各 MCP ページには、エージェントが mcp.json に設定するために必要な最小限の情報をまとめます。

# 開発環境デプロイMCP

開発環境 (Docker Compose) へのデプロイを行うMCPサーバー。

## mcp.json 設定例

```jsonc
{
  "servers": {
    "dev-deploy": {
      "type": "http",
      "url": "https://mcp.internal/dev-deploy"
    }
  }
}
```

このページは人間にとっても「使ってよいMCPカタログ」として機能しますし、AIエージェントにとっては「接続情報の取得元」になります。社内承認プロセスを通った MCP だけがこのページに掲載される運用にすれば、組織として「使ってよいMCP」のホワイトリストがWikiに集約されます。

構成案2: ドキュメントからMCP一覧ページにリンクする

人間用とAI用のドキュメントを分けず、同じドキュメントに両方の実行経路を併記する方針を考えています。社内Wikiでも社内Gitリポジトリのmdファイルでも、Markdownで書ける場所ならどこでも構いません。

例として、アプリAを開発環境にデプロイする手順書はこんな形になりそうです。

# とあるアプリAを開発環境にデプロイする手順書

```bash
ssh user@dev-server
cd ~/apps/app-a
git pull origin feature
docker compose down -v && docker compose up -d
```

MCPでデプロイする場合はこちら:
[社内Wiki/MCP一覧/開発環境デプロイMCP](https://wiki.internal/mcp/dev-deploy)

人間が直接作業する時はbashコマンドをコピー&ペーストして実行できます。AIエージェントは下のMCPリンクを辿って、Wiki から接続情報を取得し、MCP経由でデプロイを実行する流れになります。

同じ1つのドキュメントに「人間用の実行手順」と「AI用のMCP参照リンク」が併記されている点がポイントで、これで「人間用とAI用の手順書を分けない」という SSoT (Single Source of Truth) が成立する想定です。

さらに、bashコマンドの記述はAIエージェントの文脈理解の足場としても機能します。MCPツール名と引数だけでは何が起きているか掴みにくいところを、「ssh して cd して git pull する」という人間用の流れが補ってくれる。仮に将来デプロイが完全にAIエージェント経由になっても、bashコマンドの記述は残るので、人間が監査やトラブルシューティングで「裏で何が起きているか」を確認できる Living Document として機能し続けることも期待できます。

構成案3: カスタムプロンプトファイルと指示プロンプトの役割分担

少し前提を共有しておきます。本構成では、エージェントコーディング (自律的なAIエージェントが計画・コード作成・テスト・修正を最小限の人間介入で行う開発アプローチ) を、こんなディレクトリ構成で運用するスタイルを想定しています。

~/repos/agentic-hub/ に「ハブ的リポジトリ」を1つ作って、そこをVS Codeで開きます。

~/repos/agentic-hub/                    # ハブ的リポジトリ
├── .github/
│   ├── copilot-instructions.md         # 基本ポリシー (カスタムプロンプト)
│   ├── prompts/                        # カスタムプロンプト集
│   │   ├── deploy.prompt.md
│   │   └── code-review.prompt.md
│   └── skills/                         # agent skill定義 (GitHub Copilot)
│       ├── git-operations/
│       │   └── SKILL.md
│       └── e2e-testing/
│           └── SKILL.md
├── .vscode/
│   └── mcp.json                        # MCPサーバー設定
├── .work/                              # 開発作業用 (gitignoreで除外)
│   ├── app-a/                          # 開発対象リポジトリをclone
│   ├── app-b/
│   └── ...
├── .gitignore                          # .work/ を除外
└── README.md                           # ハブリポジトリの使い方

開発対象のリポジトリは .work/ ディレクトリの中に clone して作業します。GitHub Copilot や Claude Code は、このハブリポジトリのルートから見える .github/copilot-instructions.md、prompts/、skills/、.vscode/mcp.json を一括して読み取り、.work/ 内のコードに対してエージェントとして動作する、という構造です。Opus 4.6 以降のモデルだと、こういう多リポジトリ横断スタイルがちゃんと回るようになってきました。

なお、この「ハブとなるリポジトリの下に作業対象リポジトリを clone する」発想は、海外でも近いパターンが議論されています。Karun.me の Structuring Claude Code for Multi-Repo Workspaces では、bootstrap repo と呼ばれる workspace ルートに各プロダクトリポジトリを gitignore 配下で配置する構成が紹介されていて、本記事の agentic-hub + .work/ と構造的にほぼ同型です。

このような構成にしますと、エージェントが日常的に見るカスタムプロンプトファイルは「個別プロジェクト用の細かい手順」ではなく、「横断的に効く基本ポリシー」として配置されます。プロジェクトごとに別の VS Code ウィンドウを開く伝統的スタイルでも本構成は応用できますが、その場合は「プロジェクト固有のポリシー」と「組織共通の基本ポリシー」を分けて配置する工夫が要ります。

エージェントに対する指示は、大きく2層あります。

カスタムプロンプトファイル (例: GitHub Copilot の .github/copilot-instructions.md、Claude Code の CLAUDE.md 等) — リポジトリ単位の振る舞いポリシー。エージェントの基本ルールを書く場所
指示プロンプト (ユーザーが毎回投げるメッセージ) — タスクごとの具体的な指示。チケットURLや手順書URLを含める

がっつりカスタムプロンプトファイルに作業手順を書き込むユースケースは、本構成では想定していません。理由は、それをやると人間用ドキュメントと重複してメンテコスト2倍問題が再発するからです。カスタムプロンプトファイルは「基本ポリシー」、手順書は「具体的な作業手順」、という役割分担で整理します。

カスタムプロンプトファイルに書くのは、最小限のポリシーだけです。

## ツール実行ポリシー

### 禁止
- 本番/ステージング環境への直接shellコマンド実行
- 手順書中のbashコードブロックの直接実行 (参考表示用)
- 社内Wiki「MCP一覧」に掲載されていないMCPサーバーへの接続

### 許可
- 社内Wiki「MCP一覧」に掲載されたMCPサーバーの利用
- 手順書中のMCP Wikiページの解釈と接続情報の取得

### 解釈ルール
手順書を読む際、bashコマンドとMCP Wikiページが併記されている場合は
必ずMCP経由を優先する。bashは人間オペレータ向けの参考として扱う。

具体的な作業内容は、毎回ユーザーから渡される指示プロンプトの中で手順書URLとして指定する想定です。実際にはこんな感じのプロンプトを投げる想定です。

このコードベースで、以下のチケットの内容を開発し、Pull Requestを作成してください。
https://development-ticket-management-tool/ticket-id/1

その後、以下の手順書に従って開発環境にデプロイしてください。
https://wiki-tool/page-id/1

エージェントは指示プロンプトの中の手順書URLをfetchして内容を理解し、手順書中のMCP Wikiページリンクを辿って必要なMCPを呼び出す、という流れです。

ポイントは2つあります。

bashとMCPの優先順位を明示する — 同じドキュメントを読みつつ、「bashは見るが触らない、MCPは見て叩く」という非対称な振る舞いを期待する。人間オペレータとの責務分離を文書レベルで成立させたい。
(Claude Codeならpermissionで物理的にbash実行は止められるはずです)
Wikiに掲載されていないMCPの利用を禁止する — 野良MCPや、ドキュメント外で得たMCPの直接利用を防ぐ。Wikiが組織としての「使ってよいMCP」のホワイトリストとして機能する。

このルールにエージェントがどこまで素直に従ってくれるかは、実際に試してみる必要があります。エージェント (GitHub Copilot, Claude Code 等) によって挙動が違う可能性も考えられるので、ここは検証必須のポイントです。

想定する動作の流れ

ユーザーが指示プロンプトに手順書URLを含めて投げる、というスタイルを想定すると、こんなフローになります。

このコードベースで、以下のチケットの内容を開発し、Pull Requestを作成してください。
https://development-ticket-management-tool/ticket-id/1

その後、以下の手順書に従って開発環境にデプロイしてください。
https://wiki-tool/page-id/1

エージェントはこのプロンプトを受け取って、こんな順で動く想定です。

手順書URLをfetch — プロンプト中の手順書URLを取得して読み込む
手順書を解釈 — 操作内容を理解 (例: アプリAの開発環境へのデプロイ)
MCP Wikiページ発見 — 手順書本文から関連MCP (例: 開発環境デプロイMCP) のWikiページへのリンクを抽出
接続情報取得 — Wikiページから接続情報 (url, type 等) を読み取る
mcp.json確認 — .vscode/mcp.json を確認、未登録なら接続情報を追加
MCP呼び出し — 接続したMCP経由で必要な操作を実行

人間オペレータが同じ手順書を見て作業する場合は、ステップ3以降が「ターミナルでbashコマンド実行」に置き換わるだけで、参照する知識資産は完全に同じになるはずです。

Wikiに登録されたMCPだけを使わせる方針

ここが安全側に倒した設計の肝になります。

任意のドキュメントから任意のMCPサーバー設定を mcp.json に追加できると、tool poisoning の温床になりかねません。

そこで、「社内Wikiの『MCP一覧』に掲載された MCP しか使ってはならない」 というルールをカスタムプロンプトファイルに敷くことを考えています。エージェントがドキュメントから MCP Wikiページへのリンクを発見した時、そのURLが wiki.internal/mcp/* の形式であることを確認し、ページから接続情報を取得する流れです。

このルールが噛めば、次のリスクが低減できる見込みです。

野良MCPの利用 — Wikiに掲載されていないMCPは使えない
Wikiを介さないMCP接続 — copilot-instructions.md で禁止
古いMCPへの一斉切断 — Wikiページを削除/非公開化すれば、新規にmcp.jsonに入る経路は止まる

社内承認プロセスを通った MCP だけが Wiki に掲載されるルールにすれば、Wiki がそのまま社内のMCPホワイトリスト兼カタログとして機能します。

ただし、Wikiベースだと実行時の統制は弱いです。誰かが Wiki に書いてある接続情報を直接 mcp.json にコピペすれば、自分の端末からMCPサーバーを叩けてしまう。実行時の認証集約・スコープ制御・人間承認などが必要になったら、冒頭で触れた MCP Gateway 系のツール (ContextForge, mcpmanager.ai 等) の導入を検討するフェーズに入ります。その場合も、Wikiの「MCP一覧」ページに書いてある接続URLを Gateway 経由の形式に書き換えれば、既存ドキュメントは変更せずに統制を強化できる移行パスは残ります。

mcp.json の自動配布が副次的に成立しそう

この構成、副次的な効果として MCP配布問題 にも効きそうだと考えています。

通常、MCPサーバーの設定は次のいずれかで管理されることが多いと思います。

中央集権push (管理者が全社展開、手動メンテ)
個人手動 (各自READMEを読んで自分で書く)
テンプレート配布 (dotfiles的にgit clone)

どれもそれぞれ難があり、(1)は権限とスケール、(2)は周知コスト、(3)は更新追従が課題になりがちです。

今回の構成では、copilot-instructions.md に「手順書中の MCP Wikiページへのリンクと mcp.json を比較して、未登録なら Wiki の接続情報を読み取って追加する」というポリシーを書いておくことで、エージェントがタスク実行時に自動で mcp.json を更新する流れになります。

手順書内に MCP Wikiページへのリンク
  ↓
mcp.json確認 → 未登録ならカスタムプロンプトファイルの指示で追加

中央管理者がpushする必要も、各自が手動で書く必要も減らせる可能性があります。業務上必要になった時点で必要な設定が降ってくる、という挙動になるとよいなと考えています。

ここまでの基本構成での効果

ここまでの内容で、本記事の主題である「人間用ドキュメントとAIのカスタムプロンプトを一体化させる」は概ね組み立てられた状態になります。

期待する効果はこんなところです。

メンテコストが下がる — 手順書が1箇所に集約され、人間用とAI用が分裂しない
オンボーディング摩擦が減る — 新メンバーがMCP設定でつまずかず、必要なMCPが作業に応じて自動で入る
野良MCPの利用が抑えられる — Wikiが組織のMCPホワイトリストとして機能
軽量に始められる — 社内Wikiさえあれば導入できる。専用ツールの追加導入はオプション
段階的に強化できる — 後から MCP Gateway を入れれば、ドキュメント側を変えずに統制を強化できる

ここまでが「人間用ドキュメントとAIのカスタムプロンプトを一体化させる設計」の話です。

ここから踏み込み: KG Hubと組み合わせると

冒頭では端折りましたが、ここまでの構成にさらに Knowledge Graph Hub(以前私が作ったグラフナレッジベース管理アプリ) を組み合わせると、いくつかの追加効果が見えてきます。ここからは「あれば便利」のオプション層の話になります。

LLMは前向性健忘である

少し迂回しますが、AIエージェントを業務で機能させる時の根本的な制約として、LLMは毎回新しいプロセスとして呼び出されるという性質があります。これは構造的には前向性健忘症と同じ状態です。基礎能力（推論、コード生成）は持っていても、社内の固有事情を覚えていない。それでも業務をやらせるには、外部に「業務知識」を構造化して置いておく必要があります。

健忘症の人が日常生活でメモ・定位置・道具を駆使して機能するのと、新人エンジニアが社内Wikiと先輩と権限を獲得していくプロセスは、構造的に似ていると考えています。AIエージェントを業務で機能させる仕組み設計は、本質的には新人立ち上げの仕組み設計と同じ問題を解いていると言える気がします。

ここまでの「人間用ドキュメントとAIのカスタムプロンプトを一体化させる設計」は、この外部記憶をツリー構造の Wiki で表現していました。これでも十分機能するのですが、ツリー構造で表現しにくい関係を扱う場面では限界が出てきます。

具体例: アプリケーション間の依存関係

実用上、KG が本領を発揮するのは、アプリケーション間の依存関係のようなグラフ構造の知識を扱う時です。

たとえば、こんな依存関係を持つシステムを想像してみてください。

アプリA → Aのログ → バッチB → BのOUTPUTデータ → バッチC → ...

大抵の会社にこういう「複雑なアプリ・バッチ・データの連携」が存在するはずです。これは木構造ではなく、有向グラフになります (あるバッチのOUTPUTは複数の下流バッチから参照される、ログは2つの監視システムから読まれる、といった多対多が出てくる)。Wikiの階層構造ではこれを綺麗に表現できません。

KG Hub では、アプリ・ログ・データをノードとして扱い、それぞれのプロパティに仕様書・デプロイ手順書のリンクを記載します。

各ノードのプロパティに記載されている手順書リンクは、前半で扱った「Markdown手順書」そのものです。手順書がさらに社内Wikiの「MCP一覧」にリンクしているので、ノード → 手順書 → MCP という辿り方ができるようになります。

この構成で狙えること: AIによるシステム間統合テスト

ここからが面白いところで、こういう依存グラフが整備されていると、開発作業のやり方が変わる可能性があると考えています。

開発要件を固めた段階で、複数のアプリを Claude Code などで並行開発し、すべてのアプリを検証環境にデプロイし、システム間インテグレーションテストをAIに任せる、というシナリオが視野に入ってきます。

AIエージェントの動きは、こんな感じになるはずです。

開発要件から、関連するアプリ・バッチ・データを KG Hub で特定
各ノードのプロパティから「デプロイ手順書」を辿って、検証環境に並行デプロイ
依存グラフを traversal して、上流から順に動作確認
各確認ステップで MCP経由のシステム操作 (DBクエリ、ログ確認、ジョブキック、データ突合)
結果を集約してレポート

ポイントは、「依存関係を順に辿る」というAIの動作は、グラフ構造がないと難しいことです。ツリー型Wikiやリスト型の管理だと、「このアプリが影響する全ての下流」とか「このデータを参照する全てのバッチ」みたいなクエリが書けない。KG Hub があって初めて、こういう traversal がエージェントから可能になります。

この一連のフローが回ると、結果として 複数のシステムの上に構築されるサービスのプロトタイプが、検証環境にデプロイされる という状態が実現します。システム間統合テストは、大抵の会社で「人間が時間をかけてやる重い作業」になっているはずです。これがAIで動くようになれば、開発リードタイムを大きく削れる可能性があります。

もう一つの使い方: 改修影響分析

もう一つ、KGがあると実用的に動きそうな使い方として、「アプリAに改修を入れた時、後続のバッチや下流データに何が影響するか」を AI に分析させる、というシナリオがあります。

例えば「アプリA のログフォーマットを変更したい」となった時、AI が KG で (アプリA)-[produces]->(Aのログ)-[consumed_by]->(...) のように辿って、影響を受けるバッチや監視システムを列挙してくれる、というイメージです。

個人的に近い形を試してみたことがあって、なかなか実用的でした。改修レビューや影響範囲調査の重い作業を、AIにある程度任せられるようになるのではと考えています。

KGがなくても基本機能は動く

ここまでが「KG Hub があると嬉しい」ケースですが、繰り返しになりますが、前半で組み立てた Wiki + ドキュメント + カスタムプロンプトファイルの構成は、KG なしでも独立して動きます。KG Hub はドキュメントへのリンクを保持するだけのレイヤーなので、既存のWikiやドキュメント体系を破壊しません。KG Hub を後から外しても、Wikiとドキュメントの繋がりは無傷で残ります。

「KGをまず導入しなければ何も始まらない」という前提依存を作らないように、各レイヤーが独立して動くことを意識して組み立てています。

設計上の特徴: 各レイヤーが疎結合

ここまでの構成、振り返ると次のような3層構造になっています。

レイヤー	役割	単独で機能するか
Wiki + ドキュメント	人間とAIのSSoT、MCP一覧管理	YES (これだけで基本構成完結)
ナレッジグラフ (KG Hub)	業務知識をグラフ構造で保持、依存関係の表現	追加価値 (抜いても下層は動く)
MCP Gateway	実行時統制、認証集約	追加価値 (必要時に導入)

それぞれの層が「他の層がなくても自分の価値で生きていける」設計です。「KGをまず導入しなければ何も始まらない」「Gatewayがないと動かない」といった前提依存をなるべく作らない方針で組み立てています。

期待する効果と想定される課題

机上で組み立てた段階の整理ですが、期待する効果と想定される課題を書き出してみます。

期待する効果

メンテコストが下がる — 手順書が1箇所に集約され、人間用とAI用が分裂しない
オンボーディング摩擦が減る — 新メンバーがMCP設定でつまずかず、必要なMCPが作業に応じて自動で入る
軽量に始められる — 社内Wikiさえあれば導入できる
段階的に強化できる — 後から KG Hub や MCP Gateway を入れられる
(KG導入時) システム間統合テストがAIで回せる可能性 — 依存グラフを辿った検証が成立する
(KG導入時) AIエージェントの挙動をトレースできる — KG Hub に「どんな経路でデータを辿って、どの手順書を参考にしたか教えて」と聞けば、辿った経路を答えてくれます。KG をメンテする時も「この経路でこの情報を拾ってほしい」と制御しやすく、新人エンジニアにとっても、エージェントの動きが見えることで「分かった感」を得られそうです。

想定される課題

MCP Wikiページのフォーマット標準化が要る — ページ構造がバラバラだとエージェントが情報抽出しにくい。社内で1つテンプレートを決めてからスケールさせる必要がありそう
ドキュメントにMCP Wikiリンクを書く文化 — これは技術というより運用慣習の問題で、初期は普及に時間がかかると見込まれる。最重要手順書から始めるのが現実的
(KG層) グラフの整備コスト — アプリ依存関係のような KG を正しく維持するのは継続的な労力が要る。最初は小さく始めて、効果が見えてから広げる方が良さそう

まとめ

本記事の主題である「人間用ドキュメントとAIのカスタムプロンプトを一体化させる」については、社内Wikiの「MCP一覧」ページとMarkdown手順書、カスタムプロンプトファイルの3点セットで組み立てられそうだ、というのが今回の整理です。

MCP の中央集権的管理という発想自体は最近よく見るテーマで、専用ツールも色々出てきていますが、いきなりそこに飛びつくのではなく、まず社内Wikiで「MCP一覧」を管理する最小構成から始めて、必要に応じて MCP Gateway 等に移行する、という段階的なアプローチが現実的かなと考えています。

さらに踏み込めば、ナレッジグラフ (KG Hub) を組み合わせることで、アプリケーション間の依存関係のような複雑な業務知識からAIエージェントの動きを構成できる可能性も見えてきます。ただしこれは「あれば便利」のオプション層で、基本構成は KG なしでも独立に動くように設計しています。

まだ実装も検証もこれからで、本記事の構成がそのまま動くかは分かりません。ただ、社内のドキュメント・MCP管理・ナレッジグラフをどう繋ぐかという問題に対しての一つの設計案として、ここに書き残しておきます。

次のステップとして、社内Wikiに「MCP一覧」ページを最小構成で立てて、ドキュメント1つにMCP Wikiリンクを書いて GitHub Copilot から呼ばせてみる、という最小検証を予定しています。このあたりが動き始めたら、続編で実装結果と詰まったポイントを書きたいと思います。

似たような問題意識で動いている方や、「うちはこう解いている」「この方針はここで詰まりそう」みたいなご意見があれば、ぜひコメントいただけるとありがたいです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up