社内業務ツールをMCP化する — Hello Worldの次の一歩

MCPのHello Worldはできた。ツールが1つ動いて、AIから呼び出せることも確認した。では、次は何を作ればいいのか？　この壁にぶつかっている方は多いはずです。この記事では、勤怠・在庫・顧客管理といった社内の既存業務ツールをMCPサーバーとして公開し、AIエージェントから操作できるようにするまでの実践手順を、設計判断のポイントとともに解説します。「最小構成MCPサーバーHello World」の続編という位置づけです。

チュートリアルと実務のあいだにある溝は、コードの難しさではありません。「何をMCP化すべきか」「どう定義すればAIが正しく使えるか」「事故らない権限設計はどうするか」という3つの設計判断です。本記事はこの3点を順番に潰していきます。

1. MCP化する価値があるツールの見極め方

社内には数え切れないほどのツールがあります。全部をMCP化するのは非現実的ですし、その必要もありません。判断軸はシンプルに2つ、「AIに聞かれる頻度」と「APIの有無」です。

「AIに聞かれる頻度」は、裏を返せば人間が日常的に調べたり転記したりしている頻度です。「今月の残り有給は？」「この商品の在庫は？」「この顧客の契約プランは？」──こうした質問に答えるためだけに人がツールを開いてコピペしているなら、そこがMCP化の一等地です。

最初の1本は「読み取り専用・社内限定」が鉄則

最初のMCPサーバーで更新系（書き込み・削除）まで作り込むのはおすすめしません。理由は3つあります。

• 事故のインパクトが桁違い：読み取りの失敗は「答えが返らない」だけですが、書き込みの失敗は業務データの破壊です。
• 読み取りだけでも価値が大きい：社内ツール活用の大半は「調べて、まとめて、答える」で完結します。
• 運用の勘所を安全に学べる：ログの取り方、認証の回し方、AIの使われ方の実態を、低リスクで観察できます。

全体像としては、次のような3層構成になります。既存システムには手を入れず、MCPサーバーを「翻訳層」として間に挟むのがポイントです。

2. 設計編：ツール定義のコツ

ツール名と説明文が「プロンプト」になる

MCPで最も見落とされがちな事実がこれです。ツール名と説明文は、そのままAIのプロンプトの一部になります。AIは説明文を読んで「どのツールをいつ使うか」を判断するため、ここの品質がMCPサーバーの使われ方を決めます。

コツは、新人に業務マニュアルを書くつもりで説明文を書くことです。「いつ使うか」「入力は何か」「何が返るか」の3点セットを、自然文で盛り込みます。

巨大なレスポンスを返さない

既存APIのレスポンスをそのまま返すと、往々にして数千行のJSONがAIのコンテキストに流れ込みます。これはトークン費用の無駄遣いであると同時に、AIの回答精度も下げます。MCPサーバー側で次の3つを必ず行ってください。

• フィールドの絞り込み：AIの回答に必要な項目だけに削る（内部ID、監査用メタデータなどは落とす）
• ページング・件数上限：limitパラメータを設け、デフォルトを10〜20件程度にする
• 検索条件の必須化：「全件取得」を作らない。必ずキーワードやIDで絞らせる

破壊的操作には確認ステップを挟む

更新系ツールをどうしても提供する場合は、「実行前に変更内容の要約を返し、確認パラメータ付きの再呼び出しで初めて実行する」という2段階設計にします。1回のツール呼び出しで即座にデータが書き換わる設計は、AIの誤解釈がそのまま事故になります。

// 1回目の呼び出し（confirm なし）→ 実行せずプレビューを返す
{
  "preview": "顧客 C-0042 の契約プランを Basic → Pro に変更します",
  "confirmation_token": "a1b2c3",
  "message": "実行するには confirmation_token を付けて再度呼び出してください"
}

3. 実装編：既存REST APIをMCPでラップする

設計が決まれば実装は薄いラッパーです。公式TypeScript SDK（@modelcontextprotocol/sdk）を使った、勤怠管理APIをラップする最小構成の例を示します。Hello Worldからの差分は「実APIへのfetch」と「レスポンスの絞り込み」だけです。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const KINTAI_API = process.env.KINTAI_API_BASE; // 例: https://kintai.example.internal/api
const API_TOKEN = process.env.KINTAI_API_TOKEN; // 読み取り専用スコープのトークン

const server = new McpServer({ name: "kintai-mcp", version: "1.0.0" });

server.tool(
  "get_employee_leave_balance",
  "指定した社員の有給休暇の残日数を返します。社員は社員ID（例: E1234）で指定します。" +
    "『有給あと何日？』のような質問に使います。",
  { employeeId: z.string().describe("社員ID（例: E1234）") },
  async ({ employeeId }) => {
    const res = await fetch(
      `${KINTAI_API}/employees/${encodeURIComponent(employeeId)}/leave`,
      { headers: { Authorization: `Bearer ${API_TOKEN}` } }
    );
    if (!res.ok) {
      return {
        content: [{ type: "text", text: `取得に失敗しました（HTTP ${res.status}）` }],
        isError: true,
      };
    }
    const data = await res.json();
    // レスポンスはAIに必要な項目だけに絞る
    const summary = {
      employeeId: data.employee_id,
      remainingDays: data.paid_leave.remaining_days,
      expiringDays: data.paid_leave.expiring_within_60days,
      asOf: data.updated_at,
    };
    return { content: [{ type: "text", text: JSON.stringify(summary) }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Claude Desktopなどのクライアントへの登録方法やstdioトランスポートの仕組みは、前回記事「最小構成MCPサーバーHello WorldでMCPの仕組みを完全に学ぶ」で解説したとおりです。複数のMCPサーバーをまとめて管理したい場合は「Docker Desktop MCP Toolkit」も参考になります。

認証情報の扱い

• トークンは環境変数で渡す：コードやMCPクライアントの設定ファイルへの平文書き込みは避け、シークレット管理の仕組みから注入します。
• スコープは最小化する：MCPサーバー専用に「読み取り専用」のAPIトークンを新規発行します。人間用の管理者トークンの流用は厳禁です。
• ツールごとではなくサーバーごとに権限を分ける：読み取り用MCPサーバーと更新用MCPサーバーを別プロセス・別トークンに分離すると、権限管理が単純になります。

4. 運用編：セキュリティと権限

読み取り／書き込みの権限分離

運用フェーズで効いてくるのが、実装編でも触れたサーバー単位の読み書き分離です。「誰に読み取りサーバーを配るか」「更新サーバーは誰の環境にだけ入れるか」という配布の問題に置き換えられるため、棚卸しが圧倒的に楽になります。全社員のAIに更新権限が行き渡っている状態は、それ自体がインシデントの一歩手前だと考えてください。

ログ・監査の設計：「誰のAIが何を実行したか」

MCP経由のアクセスは、既存システムから見ると「MCPサーバー用トークンのアクセス」に見えるため、そのままでは利用者個人まで遡れません。最低限、MCPサーバー側で次の項目を構造化ログとして残します。

また、AIエージェント経由のアクセスにはプロンプトインジェクションのような固有のリスクもあります。防御側の考え方は「Claude Securityがついに公開 — AI時代の防御側エンジニアが今すぐやるべきこと」で詳しく書いたので、あわせてご覧ください。

5. まとめ：MCP化は「AIのためのAPI設計」である

本記事のポイントを振り返ります。

• MCP化の対象は「AIに聞かれる頻度 × APIの有無」で選ぶ。最初の1本は読み取り専用・社内限定
• ツール名と説明文はプロンプトの一部。新人向けマニュアルのつもりで書く
• レスポンスは絞る・ページングする。破壊的操作は2段階確認にする
• 実装は既存REST APIの薄いラッパーで十分。トークンは読み取り専用スコープで新規発行
• 運用では読み書きのサーバー分離と「誰のAIが何を実行したか」の監査ログが要

突き詰めると、MCPサーバー作りとは「AIという新しい利用者のためのAPI設計」です。人間の開発者にとって良いAPIがドキュメントで決まるように、AIにとって良いMCPサーバーはツール定義の説明文で決まります。良いMCPサーバー＝良いドキュメント。この感覚を持って、まずは社内で一番「聞かれている」ツールを1本、読み取り専用でMCP化するところから始めてみてください。