はじめに：学ぶべき技術が多すぎて不安な方へ
RAG、LLM、ベクトルDB、ファインチューニング、プロンプトエンジニアリング……。AI関連の技術トピックは次々と増え、「全部学ばないと置いていかれるのでは」と感じている方も多いのではないでしょうか。
しかし、少し立ち止まって考えてみてください。あなたがSEとして積み重ねてきた経験——業務知識の整理、ドキュメント管理、データベース設計——は、実はRAGやKnowledge MCPを活用するうえでそのまま武器になるスキルです。
本記事では、「何から手をつけるべきか」の判断基準として、SE経験とRAG/Knowledge MCPの接点を整理します。
RAGとは何か：SE視点で捉え直す
RAG（Retrieval-Augmented Generation）は、LLMが回答を生成する前に外部の知識ソースから関連情報を検索・取得し、それをコンテキストとして与える仕組みです。
SEの日常業務に置き換えると、次のようなイメージです。
| SE業務の例 | RAGでの対応 |
|---|---|
| 過去の障害対応記録を検索 | ナレッジDBからの検索 |
| 設計書を参照しながらレビュー | ドキュメント検索＋コンテキスト付与 |
| FAQからの回答作成 | 検索結果をもとに生成 |
つまりRAGは「調べてから答える」という、SEが日常的に行っている知的作業をシステム化したものです。
Knowledge MCPとは何か
Knowledge MCPは、AIエージェントが利用する知識基盤をMCP（Model Context Protocol）として標準化したものです。具体的には以下の操作を提供します。
- knowledge_upsert: 知識の登録・更新
- search_knowledge: セマンティック検索
- knowledge_list: 登録済み知識の一覧
- knowledge_delete: 不要な知識の削除
ポイントは、これらの操作がSEにとって馴染みのある**CRUD操作（Create/Read/Update/Delete）**そのものだということです。新しい概念を学ぶのではなく、既存のメンタルモデルをそのまま適用できます。
SE経験がRAG活用に直結する3つの理由
理由1: 業務知識の構造化スキル
SEは日常的に「この情報はどのカテゴリに属するか」「どのような粒度で分割すべきか」を判断しています。RAGの精度を高めるには、知識を適切な粒度で分割し、メタデータを付与する必要があります。これはまさに、テーブル設計や分類体系設計と同じスキルです。
理由2: ドキュメント管理の経験
設計書、手順書、議事録——SEはさまざまなドキュメントを管理してきました。Knowledge MCPに登録する知識も、結局はドキュメントの管理です。「どこに何が書いてあるか」を把握する力は、そのままナレッジの分類・検索設計に活きます。
理由3: 「検索してから判断する」ワークフロー
SEは障害対応でも設計レビューでも、まず過去の記録を検索してから判断を下します。RAGのワークフロー（検索→取得→生成）は、このSEの行動パターンをそのままシステム化したものです。
Knowledge MCPで始める知識管理：最小構成
実際にKnowledge MCPを使った知識管理を始めるには、以下の最小構成から始めることを提案します。
知識管理の最小構成:
├── 名前空間の設計（プロジェクト単位）
├── 知識の粒度ルール（1トピック1エントリ）
├── メタデータの定義（カテゴリ、タグ、日付）
└── 検索・更新の運用ルール
名前空間の設計例
{
"namespace": "project_harness",
"categories": [
"design_decision",
"troubleshooting",
"api_reference",
"meeting_notes"
]
}
この構造は、ファイルサーバーのフォルダ設計やWikiのカテゴリ設計と同じ考え方です。
知識管理方針テンプレート
以下に、知識管理方針の策定テンプレートを示します。これが本記事の成果物です。
| 項目 | 方針 | 判断基準 |
|---|---|---|
| 登録対象 | 繰り返し参照する情報 | 2回以上参照したら登録候補 |
| 粒度 | 1トピック＝1エントリ | 検索時に必要十分な単位 |
| メタデータ | カテゴリ＋タグ＋日付 | 検索精度の向上に必要なもの |
| 更新頻度 | 変更発生時に即時更新 | 古い情報が害になる場合は優先 |
| 削除基準 | 6ヶ月参照なし＋代替あり | 安全側に倒す（アーカイブ優先） |
| レビュー周期 | 月次で棚卸し | 陳腐化チェック |
よくある懸念と判断基準
「ベクトルDBの知識がないと使えないのでは？」
Knowledge MCPはベクトルDBの複雑さを抽象化しています。SQLを直接書かなくてもORMで操作できるように、ベクトルDBの内部実装を知らなくても、MCPのインターフェースから操作できます。
「登録する知識の品質をどう担保するか？」
完璧な知識を目指す必要はありません。まずは「検索して見つかる」状態を作り、使いながら品質を改善するアプローチが現実的です。これはアジャイル開発と同じ考え方です。
「既存のWikiやConfluenceとどう使い分けるか？」
人が読むドキュメントはWiki、AIが参照するコンテキストはKnowledge MCPと役割分担するのが一つの判断基準です。ただし、明確な正解はありません。プロジェクトの規模や運用体制に応じて使い分けてください。
小規模な検証の始め方
以下のステップで、小さく始めることを推奨します。
- 対象を1プロジェクトに絞る: 全社展開ではなく、自分の担当プロジェクト1つで試す
- 10件程度から登録: まず設計メモや障害対応記録を10件登録する
- 検索精度を確認: 実際に検索してみて、期待する結果が返るかを確認
- メタデータを調整: 検索精度が低ければ、粒度やメタデータを調整する
- 1週間運用して振り返る: 運用してみて初めてわかることを記録する
RAG vs ファインチューニング：判断基準
AI活用の学習対象を絞るために、RAGとファインチューニングの使い分けの判断基準を整理します。
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 知識の更新頻度 | 高い（リアルタイム更新可能） | 低い（再学習が必要） |
| 導入コスト | 低い（外部DB＋検索） | 高い（GPUリソース＋データセット） |
| SE経験の活用度 | 高い（知識管理スキル直結） | 中程度（データ整備スキル） |
| 適用場面 | 社内ナレッジ、FAQ、設計情報 | 特定ドメインの文体・判断基準 |
SE経験者が最初に取り組むなら、RAG/Knowledge MCPが投資対効果の高い選択肢である可能性が高いでしょう。
連載の中でのこの記事の位置づけ
本連載では、AIエージェントを「制御する側」に立つためのハーネス（制御装置）を設計しています。第8回ではFastMCPを使ったMCPサーバーの最小実装を通じて、MCPツールの作り方を体験しました。
今回は、ハーネスの知識基盤にあたるRAG/Knowledge MCPの概念を整理しました。ここで策定した知識管理方針は、今後の設計メモ管理やログ分析の基盤となります。
まとめ
- RAGは「調べてから答える」というSEの日常行動をシステム化したもの
- Knowledge MCPのCRUD操作は、SE経験者のメンタルモデルと一致する
- 知識管理方針を策定し、小規模から検証を始めるのが現実的なアプローチ
- SE経験（業務知識の構造化、ドキュメント管理、検索→判断のワークフロー）はRAG活用に直結する
次回予告：設計メモをKnowledge MCPへ登録する前提のMarkdownテンプレート
第10回では、今回策定した知識管理方針を実際に運用するためのMarkdownテンプレートを設計します。
具体的には以下の内容を扱います。
- Knowledge MCPに登録しやすいMarkdownの構造設計
- メタデータ（YAML Front Matter）の標準フォーマット
- 「設計メモ」「障害対応記録」「API仕様」など種別ごとのテンプレート例
- テンプレートからKnowledge MCPへの登録フローの概要
「知識管理方針は立てたけど、具体的にどんなフォーマットで書けばいいの？」という疑問に答える回です。ぜひお楽しみに。
連載: AIに仕事を奪われる不安から始めるハーネス作成入門
著者: @singula00991 ｜ 週2回更新
次回（第10回）: 設計メモをKnowledge MCPへ登録する前提のMarkdownテンプレート