連載: AIに仕事を奪われる不安から始めるハーネス作成入門
第9回 ← 前回（第8回）: MCPサーバーの最小実装

はじめに：学ぶべき技術が多すぎて不安な方へ

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テンプレート