開発ナレッジ2026.02.20

自社システム専用のMCPサーバーを作ったら開発体験が変わった話

株式会社Bizmarq

Bizmarq Media

開発ナレッジ

私たちは日々の開発に Claude Code をはじめとする AI 開発ツールを取り入れています。その中でここ最近もっとも手応えがあったのが、自分たちのシステムに特化した MCP サーバーを自作するという取り組みでした。結論から言えば、開発中のコンテキストスイッチが劇的に減り、毎日の作業が明らかに軽くなりました。本記事ではその実践知見を共有します。

MCP とは何か

MCP（Model Context Protocol） は Anthropic が 2024 年 11 月にオープンソースとして公開した標準プロトコルで、AI モデルと外部ツールをつなぐための共通規格です。2025 年には他の主要ベンダーもサポートを表明しており、いまや AI ツール連携のデファクトスタンダードになりつつあります。特定の AI 専用の仕組みではなく、業界全体で採用が進むオープンな規格だと捉えてもらえれば十分です。

Claude Code のような AI 開発ツールに MCP サーバーを接続すると、チャットの流れのまま API やデータベースを直接操作できるようになります。

コンテキストスイッチという静かなコスト

MCP を本格導入する前、私たちの開発現場では次のようなパターンが日常的に繰り返されていました。

AI に「このテーブルのスキーマは？」と聞く
AI は DB に触れないので、自分で管理ツール（pgAdmin / DBeaver など）を開いて確認する
スキーマをコピーしてチャットに貼り付ける
「最新データを 10 件見たい」と言われれば、また管理ツールを操作
API を試すなら Postman や curl を起動

このサイクルが 1 時間の作業のうちに何度も発生します。DB 管理ツール、API クライアント、ターミナル、エディタと、4 つ以上のアプリを行き来するたびに集中状態がリセットされる。これがコンテキストスイッチです。

タスクを切り替えてから元の集中に戻るまでには相応の時間がかかることが知られており、1 時間に何度も切り替えていれば、まとまった集中時間はほとんど残りません。そこで「これ、AI から直接叩けたらいいのに」という発想に至りました。

作ったもの

TypeScript で書いた小さな MCP サーバーです。機能はシンプルですが、日常の開発で必要な操作は一通りカバーしています。

DB スキーマの探索 — テーブル一覧の取得、特定テーブルのカラム名・型・制約・外部キーの表示
SQL クエリの実行 — SELECT でのデータ確認。書き込み操作は明示的な許可を必須にして誤操作を防止
認証付き API 呼び出し — 自社 API を叩く際の JWT トークン取得・更新を裏側で自動管理
安全対策 — パラメータ化クエリでインジェクションを防ぎ、破壊的操作は自動検出してブロック

実装のコアは、ツールを定義して AI クライアントに接続するだけです。たとえばテーブル情報を返すツールはこのようなイメージになります。

server.tool(
  "describe_table",
  { table: z.string() },
  async ({ table }) => {
    const rows = await db.query(
      `SELECT column_name, data_type, is_nullable
       FROM information_schema.columns
       WHERE table_name = $1`,
      [table] // パラメータ化クエリでインジェクション対策
    );
    return { content: [{ type: "text", text: format(rows) }] };
  }
);

何が変わったか

スキーマ確認が会話のまま完結する

管理ツールを開いてカラム一覧をコピーして貼り付ける、という一連の動作が消えました。「users テーブルの構成を教えて」と聞けば、AI が MCP 経由でスキーマを取得し、そのまま回答します。1 回あたりの節約は数分でも、ブラウザに切り替えて戻る動作がゼロになる効果は体感で大きく、集中が途切れません。

バグ調査が短時間で終わる

以前はコードを読み、関連テーブルを特定し、管理ツールでレコードを検索し、関連テーブルも辿る、という往復を繰り返していました。MCP があれば「この user_id の登録状況を全テーブルで追跡して」と依頼するだけで、AI が複数テーブルをまたいでデータを追い、異常箇所まで指摘してくれます。SQL に詳しくないメンバーでも自然言語で調査に参加できるようになったのも副次的な効果でした。

API テストがチャットで完結する

新しいエンドポイントの動作確認では、従来は Postman を起動し、ログイン API でトークンを取得し、それを別リクエストのヘッダーに貼り付ける、という手間が毎回発生していました。MCP なら認証は自動管理され、「このエンドポイントを POST で、ボディはこれで実行して」と伝えるだけで結果までチャットで確認できます。

思わぬ副産物 — セーフティネット

作って初めて気づいたのは、この仕組みが事故防止としても機能することでした。AI に雑に「このレコードを削除して」と頼んでも、書き込み許可フラグがなければブロックされます。WHERE 句のない DELETE も止まります。セキュリティ目的で入れた対策が、開発中の人的ミスまで構造的に防いでくれたのです。

万能ではない — 割り切りも必要

一方で限界もあります。複数人で使うなら DB ユーザーの権限分離やアクセスログの監視が必要になります。何十行もの JOIN やチューニングが必要な場面では、素直に専用の DB ツールを使ったほうが早い。MCP は日常業務の大部分を効率化するツールであって、専門的な作業まで置き換えるものではない、という割り切りが大切です。

汎用ツールにない価値

公開されている汎用 DB 向けの MCP サーバーもありますが、自社 API との連携やカスタム認証フローには対応していません。自分たちのワークフローに特化して育てられることこそが、内製 MCP サーバーの最大の価値です。今後はログ検索、デプロイ情報、プロジェクト管理連携などを少しずつ足していく予定です。

まとめ

MCP は AI と自社システムをつなぐオープンな仕組みで、導入に特別な難しさはありませんでした。TypeScript でいくつかのツールを定義して接続するだけで、最初のバージョンは短期間で動きます。得られたのはコンテキストスイッチの削減、集中力の維持、うっかりミスの自動防止、そしてチーム全体の底上げです。

自社システムを持ち、AI 開発ツールを日常的に使っているなら、専用の MCP サーバーを作る選択肢は検討する価値があります。小規模なチームほど ROI は高い。自分たちの開発体験を自分たちで良くしていく——それが今の開発現場の面白さだと感じています。

メディア一覧へ戻る