MCPサーバーを最小構成で作るやり方（非エンジニア向け）

MCPとは？「社内データとAIを安全につなぐ差し込み口」

MCP（Model Context Protocol）は、AI（チャットボットや社内アシスタント）と、あなたの会社が持つデータや業務ツール（ファイル、データベース、チケット管理、社内Wikiなど）をつなぐための共通ルール（プロトコル）です。難しく聞こえますが、イメージは「USB-Cのような規格」です。規格があるから、機器が変わっても同じ形でつながり、運用や保守が楽になります。

ここでいう「MCPサーバー」は、AI側からの依頼（例：このフォルダの最新の見積書を探して、要点をまとめて）を受け取り、許可された範囲のデータにアクセスして、結果だけを返す中継役です。ポイントは、AIに社内の機密を丸ごと渡すのではなく、「必要な時に・必要な分だけ・監査できる形で」渡せること。情シスや管理部門が気にするセキュリティ、アクセス権、ログの観点で整理しやすくなります。

本記事では、開発の専門知識がない方でも意思決定できるように、最小構成（小さく作って検証できる構成）でMCPサーバーを立てる手順を、用語をかみ砕きながら説明します。できるだけ「まず動く」ことを優先し、その後に安全に育てる方法（権限・ログ・運用）もセットで解説します。

最小構成のゴール：まずは「社内ファイル検索」だけ動けばOK

最小構成で狙うべきゴールは、壮大なAIプラットフォームではありません。業務で使う1つの用途（ユースケース）だけを確実に動かすことです。たとえば次のような「情報探索」から入ると失敗しにくいです。

• 共有フォルダ（または特定フォルダ）内のファイル一覧を返す
• 指定ファイルの本文を読み、要点を要約して返す（AI側で要約）
• 「どこに何があるか分からない」を減らす（情シスの問い合わせ削減）

最小構成では、次の3点に絞って設計します。

• データソースは1つ（例：特定フォルダ、または読み取り専用のDB）
• ツール（機能）は1〜2個（例：list_files / read_file）
• アクセス範囲を固定（例：/data 以下のみ、社内規程の公開フォルダのみ）

この形なら、「便利そうだけど危ない」という状態を避けられます。最初から全社の共有ドライブや基幹DBに接続しないのがコツです。小さく作るほど、稟議・監査・説明が通りやすく、後で横展開もしやすくなります。

用意するもの：サーバー1台（PCでも可）＋Node.js＋最小の権限制御

最小構成のMCPサーバーは、クラウド大規模構成がなくても始められます。検証（PoC）なら、社内ネットワーク内の検証用PCや小型サーバー1台でも成立します。必要なものは次の通りです。

• 実行環境：Windows/Mac/Linuxのいずれか（まずは社内で扱いやすいOSでOK）
• ランタイム：Node.js（JavaScriptの実行環境。MCPのサンプルが多い）
• 接続先：最初はローカルの検証フォルダ（例：C:\mcp-data や /var/mcp-data）
• 運用の最小ルール：誰が動かし、どのフォルダを読めて、ログをどこに残すか

「予算はあるが詳しくない」組織ほど、最初に決めるべきは技術よりもガバナンスです。たとえば、次を先に決めておくと安全です。

• 読み取り専用で始める（書き込みや削除ツールは後回し）
• 対象フォルダは公開前提のものだけ（社外秘や個人情報は入れない）
• ログは必ず残す（誰が、何を、いつ読んだか）

なお、MCPはAI製品（クライアント）側から「MCPサーバーに接続してツールを呼ぶ」前提のため、社内で利用するAIクライアント（例：MCP対応のデスクトップアプリや社内チャット連携）も必要です。ただし最小構成の段階では、まずMCPサーバー単体が動き、ツール呼び出しに応答できることを確認すれば十分です。

手順：最小のMCPサーバーを立ち上げる（フォルダの一覧＆ファイル読取）

ここでは「指定フォルダ内のファイル一覧を返す」「指定ファイルを読み取って返す」だけを提供するMCPサーバーを、最小構成で作る流れを示します。ポイントは“できることを増やす”より“できないことを明確にする”ことです。たとえば「/data 以外は読めない」「拡張子は .txt と .md のみ」など、制限を仕様にしてしまいます。

環境準備（インストールと作業フォルダ）

検証端末にNode.js（LTS版）を入れ、作業フォルダを作ります。データは「検証用の公開情報だけ」を入れたフォルダを用意してください。

# 作業フォルダ（例）
mkdir mcp-min
cd mcp-min

# 検証データ用フォルダ（例）
mkdir data

次に、プロジェクトを初期化します。

npm init -y

最小のMCPサーバー（例：Node.js）

実装は「ツールを2つだけ持つサーバー」を作ります。以下は概念が伝わる最小例です（利用するMCPの実装ライブラリにより書き方は変わります）。情シス視点では、コードそのものより、入力を検証して、アクセス範囲を縛っている点を確認してください。

// server.js（最小例：概念サンプル）
// 実際にはMCPのSDK/ライブラリに合わせて書き換えます。

import fs from "fs";
import path from "path";

const DATA_DIR = path.resolve(process.cwd(), "data");

// パスが data 配下に収まっているか検証（パストラバーサル対策の基本）
function safeResolve(relativePath) {
  const resolved = path.resolve(DATA_DIR, relativePath);
  if (!resolved.startsWith(DATA_DIR + path.sep)) {
    throw new Error("Access denied: out of DATA_DIR");
  }
  return resolved;
}

// ツール1：ファイル一覧
async function listFiles() {
  const entries = fs.readdirSync(DATA_DIR, { withFileTypes: true });
  return entries
    .filter((e) => e.isFile())
    .map((e) => ({ name: e.name }));
}

// ツール2：ファイル読み取り（拡張子制限）
async function readFile(relPath) {
  const resolved = safeResolve(relPath);
  const ext = path.extname(resolved).toLowerCase();
  if (![".txt", ".md"].includes(ext)) {
    throw new Error("Only .txt/.md are allowed in minimal setup");
  }
  const content = fs.readFileSync(resolved, "utf-8");
  return { path: relPath, content };
}

// ここでMCPサーバーとして「list_files」「read_file」を公開する処理を書く
// 例：stdio/HTTPなど、採用するMCPクライアントに合わせたトランスポートを設定
console.log("Minimal MCP server placeholder. Implement MCP transport here.");

最小構成の肝は、次の“縛り”を最初から入れることです。

• DATA_DIR配下しか触れない（パストラバーサル対策）
• 拡張子を制限（想定外のファイルをAIが読む事故を防ぐ）
• 読み取りのみ（破壊的操作を防ぐ）

ここまでできたら、次はMCPクライアント側（MCP対応アプリ）からツール呼び出しを行い、ファイル一覧と内容取得ができるかを確認します。製品により設定画面や接続方法が異なるため、社内で採用しているクライアントの手順に沿って「MCPサーバーの接続先」「利用ツール名」を登録してください。

動作確認の観点（非エンジニアのチェックリスト）

• 指定フォルダ以外のファイルを要求すると拒否されるか
• 想定外の拡張子（例：.xlsx）を読もうとすると拒否されるか
• 要求と結果がログに残るか（最低限：日時、ユーザー、ツール名、対象）
• 社内の権限設計（閲覧可能者）がMCPサーバーにも反映できているか

「便利だから全社フォルダに広げたい」が最初に起きる事故の種です。最小構成の段階では、あえて不便に作り、運用ルールを固めてから拡張してください。

失敗しないためのセキュリティと運用：最小でも外してはいけない4点

MCPサーバーは「AIが社内情報に触れる入口」になり得ます。最小構成でも、セキュリティと運用を軽視すると、PoCのつもりが重大事故につながります。ここでは、非エンジニアでも判断できる重要ポイントを4つに絞ります。

認証・認可（誰が使えるか）

“接続できる人”と“読める情報”を分けて管理してください。最小構成では、まず「社内ネットワーク内からのみ接続可」「限定メンバーのみ利用可」から始めます。理想はSSO（社内ID基盤）連携ですが、PoCではネットワーク制限＋利用者限定でも一定の効果があります。

アクセス範囲の固定（何に触れるか）

フォルダ、DB、APIなど、触れてよい範囲をコードと設定で固定します。「設定ファイルで指定したパス以外は読めない」「テーブルは1つだけ」など、監査で説明できる形が重要です。“AIに社内データを渡した”ではなく“この用途に必要なデータだけを、制限付きで参照させた”と言える状態を作ります。

ログ（いつ・誰が・何を）

最低限、次を記録してください：日時、利用者、呼び出したツール名、対象（ファイル名など）、結果の成否。ログは「トラブル時の原因究明」だけでなく、「想定外の利用（覗き見）」の抑止にもなります。保存先は、改ざんされにくい場所（ログサーバー、クラウドの監査ログ基盤など）が望ましいです。

データの取り扱い（個人情報・機密）

最小構成のPoCでは、個人情報・人事情報・顧客情報・契約書などを避け、社内規程や製品資料など「漏れても致命傷になりにくい」データから始めてください。どうしても扱う場合は、マスキング（伏字）、分離保管、監査承認などのプロセスが必要です。“まずは安全なデータで価値検証”→“リスクの高い領域は段階的に”が鉄則です。

業務での使いどころ：情シス・管理部門ほど効果が出やすい

MCPサーバーは、華やかな「自動化」よりも、地味な「問い合わせ削減」「資料探索の短縮」で費用対効果を出しやすいです。特に、開発知識がない部門でも成果を実感しやすい代表例を紹介します。

例：社内規程・マニュアル検索（総務・情シス）

「パスワードポリシーは？」「VPNの申請手順は？」「端末紛失時のフローは？」といった問い合わせは、同じ質問が繰り返されがちです。MCPサーバーで規程フォルダだけを読めるようにし、AIが該当箇所を探して提示すれば、担当者の負荷が下がります。ここで重要なのは、AIが“勝手に回答を作る”のではなく“根拠となる文書を探す”形に寄せることです（根拠提示ができ、誤回答のリスクが下がる）。

例：監査・ISMS対応の証跡集め（情シス・内部監査）

監査対応では「該当する手順書」「運用ログ」「アクセス権の設定」など、散らばった資料を探す作業が重くなります。最小構成のMCPサーバーでも、監査用フォルダの索引（一覧）と本文確認ができれば、資料探索時間を短縮できます。ログが整っていれば「いつ、誰が、何を参照したか」も追え、運用の説明もしやすくなります。

例：営業・見積のナレッジ検索（ただし範囲を厳格に）

見積テンプレ、提案書の過去事例、価格表などは、検索性が悪いと属人化します。まずは公開してよい範囲（社外秘のレベル整理が済んだ資料）だけを対象にし、MCPサーバー経由で「該当テンプレの場所」と「関連資料」を見つけられるようにすると、立ち上がりが早いです。“何でも読ませる”ではなく“読ませてよい棚だけ作る”のが現実的です。

この段階で、効果測定（問い合わせ件数、探索時間、自己解決率）を数字で取ると、次の投資（SSO連携、アクセス制御の高度化、DB連携）に進みやすくなります。

まとめ

MCPサーバーは、AIと社内データをつなぐ「安全な接続口」を作る考え方です。最小構成で始めるなら、まずは用途を1つに絞り、データソースも1つに限定し、「フォルダ一覧」「ファイル読み取り」などの小さなツールだけを提供するのが堅実です。

• MCPは“AI連携の規格”で、ツール連携を共通化しやすい
• 最小構成のゴールは「まず動く」＋「危なくない」こと
• 最初は読み取り専用、範囲固定、拡張子制限、ログ必須が基本
• 効果が出やすいのは、規程検索・問い合わせ削減・監査資料探索など

「何をどこまでAIに触らせるか」は、技術よりも設計と運用が重要です。小さく作って価値検証し、ログと権限を整えながら段階的に拡張すると、情シス・管理部門でも安全に進められます。