コンテンツにスキップ

オンプレのレガシーデータをMCPで扱う：向き不向きとコード値の翻訳

🗓 2026-10-27 更新⏱ 約7分で読めます

最終確認: 2026-10-27
MCPとは？に戻る

30秒で復習

  • MCPは、レガシーデータを動かさずに、AIに読ませて調べ物・分析を手伝わせる用途に向いている。データ移行や定期バッチの代わりにはならない。
  • MCPサーバーはデータのそばのオンプレに置き、外からは外向きにだけつなぐ（ZTNAのコネクタと同じ考え方）。
  • 守りの3点セット：読み取り専用のDBユーザー・レプリカ・ビュー。さらに件数と時間の上限、ログ。
  • 「何でも実行できるSQLツール」より、用途を絞ったツール（get_order、search_items など）を作る。
  • 見ただけでは分からないフラグは、MCPサーバーがコード表で翻訳する。入力は enum で意味のある選択肢に、出力はラベルと元のコードを両方返す。
  • コード値の意味はデータオーナーが決め、翻訳表は1か所で管理する（データガバナンスの役割分担そのまま）。

質問：オンプレのレガシーデータにMCPを使うといい？

答え： 「AIに読ませて、調べ物や分析を手伝わせる」用途にはとても向いている。いちばんのメリットはデータを動かさずに使えること。古いシステムには手を入れず、MCPサーバーという「変換アダプター」を横に置くだけで、AIから使えるようになる。

向いている使い方

用途 例
日本語で問い合わせる 「先月A社向けに出荷した品目は？」→ AIが用意されたツールで古いDBを検索する
中身がよく分からないDBを理解する 定義書がない古いシステムの、テーブル構成や項目の意味をAIと一緒に読み解く
ファイルサーバーの資料探し 共有フォルダの古いExcelや規程を探して要約する
移行の下調べ 旧DBと新システムの項目の対応表を作る、COBOLの処理を読み解く

向いていない使い方

用途 理由 代わりに使うもの
大量データの移行・定期連携 AIが1件ずつ考えるので、遅くて費用もかかる ETLツール、バッチ処理
会計など、1円も間違えられない集計 AIが条件を取り違えることがある 決まったSQLのレポート
基幹システムへの書き込み だまされたり誤解したりしたときの被害が大きい 人が操作する画面、承認フロー

質問：どこに置いて、どうつなぐ？

答え： MCPサーバーはデータのそばのオンプレ環境に置く。社外のAIから使うときも、オンプレの入口をインターネットに開けない。ZTNAのように外向きにだけつなぐ方式で公開する。

社員のPC AIアプリ ZTNA 社内（オンプレ） コネクタ 外向き MCPサーバー ✓ コード値の翻訳 ✓ 文字コード・和暦の変換 ✓ 個人情報のマスク ✓ 件数・時間の上限 ✓ ログを残す レプリカDB 読み取り専用 本番DB（直接は触らない） 複製

設計のコツ

  1. 読み取り専用から始める：DBユーザーは読み取り権限だけにする。できれば本番ではなくレプリカ（複製）につなぎ、重い検索で業務を止めない。
  2. 用途を絞ったツールにする：run_sql のような何でもできるツールを1つ渡すより、get_order(注文番号)、search_items(品名) のように絞る。間違いも事故も減る。
  3. 見せる範囲をビューで絞る：個人情報や単価などの列は、ビューの段階で外す・マスクする。
  4. 件数と時間の上限：「1回に最大1000件」「30秒で打ち切る」のように決める。
  5. ログを残す：誰が、どのツールで、何を調べたかを記録する。

質問：見ただけでは分からないフラグはどう扱う？

答え： MCPサーバーが「翻訳係」になり、AIとのやり取りを意味の分かる形にそろえる。 AIにコードの意味を推測させない。

AI 意味の分かる 言葉で話す MCPサーバー コード表で翻訳 出荷区分のコード表 1 ＝ not_shipped 2 ＝ shipped 3 ＝ cancelled 9 ＝ 削除済み 古いDB 昔のままの コード cancelled '3' '3' R06.03.15 キャンセル 2024-03-15 上：入力（AI → DB） 下：出力（DB → AI） 緑＝意味の分かる値 オレンジ＝昔のコード

入力：inputSchema の enum で選択肢を決める

AIに '3' のような生のコードを渡させず、意味のある選択肢だけを選べるようにする。

"inputSchema": {
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "enum": ["not_shipped", "shipped", "cancelled"],
      "description": "出荷状況。not_shipped=未出荷、shipped=出荷済み、cancelled=キャンセル"
    },
    "include_deleted": {
      "type": "boolean",
      "default": false,
      "description": "削除済みの注文も含めるか"
    }
  }
}

サーバーの中で翻訳する。

AIから届く値 DBに投げる条件
"status": "cancelled" SHK_KBN = '3'
"include_deleted": false（既定） DEL_FLG <> '9'
  • enum にない値はスキーマの段階ではじかれるので、AIが存在しないコードを作る事故が起きにくい。
  • 「9 は論理削除だから必ず除く」のようなベテランしか知らない暗黙のルールを、既定値にしておける。

出力：コードを意味に変えて返す

{
  "order_no": "A-1001",
  "status": "cancelled",
  "status_label": "キャンセル",
  "status_code": "3",
  "shipped_on": "2024-03-15"
}
  • ラベルと元のコードを両方返す。AIはラベルで理解でき、人はあとでコードを使って元データと突き合わせられる。
  • 和暦（R06.03.15）、Shift_JIS、全角と半角の混在なども、サーバーの中で普通の形に直してから返す。
  • 返す形が決まっているなら、outputSchema と structuredContent で定義すると、AIが読み間違えにくい。

気をつけるポイント

ポイント 理由と対策
コードの意味は誰が決める？ 翻訳表が間違っていると、AIは自信満々に間違える。意味は業務部門のデータオーナーが承認し、日常の更新はスチュワードが担う（データガバナンスの設計と運用）
翻訳表は1か所で管理 ツールごとに書くとズレる。コード表をDBのテーブルや設定ファイル1つにまとめ、全ツールがそこを読む
知らないコードを捨てない 表にない値は "status_label": "不明（コード:7）" のようにそのまま見せてログに残す。黙って落とすと集計が合わなくなる
時期で意味が変わるコード 「2015年より前は 3 が保留だった」などがある。翻訳表に有効期間を持たせる
空白・NULL・表記ゆれ 'Y'・'1'・'○' の混在や空白入りのコードは、翻訳表で同じ意味にまとめる

説明はリソースで渡す

enum で選択肢は決められるが、「キャンセルと返品の違いは？」のような背景の説明までは入らない。用語集やコード表の説明を MCP のリソースとして渡しておくと、AIが「この注文はキャンセル扱いなので売上に入らない」のように、業務の意味まで踏まえて答えられる。

仕組み 役割 ひとことで
ツールの enum AIが正しく操作するため 選べる選択肢を決める
リソースの用語集 AIが正しく理解するため 意味と背景を教える

レガシーならではの落とし穴

落とし穴 例 対策
文字コード・形式 Shift_JIS、EBCDIC（汎用機）、和暦、固定長ファイル AIに任せず、MCPサーバーの中で変換してから渡す
定義書がない 項目名が FLG1、KBN2 だけ 業務部門に聞いて用語集を作り、リソースとして渡す
データが外に出る クラウドのAIを使うと、検索結果はAIの提供元へ送られる どの区分のデータまでAIに渡してよいかを、先に決める
本番への負荷 AIが広い条件で何度も検索する レプリカにつなぐ。件数・時間の上限を付ける

始め方

データガバナンスと同じく、小さく始めて育てる。

1 業務を1つ選ぶ 例：品目マスター の照会 2 3点セットを用意 読み取り専用 レプリカ・ビュー 3 ツールは2〜3個 用途を絞って enumで選択肢を決める 4 ログで育てる 説明文・コード表 を見直す

関連メモ

確認したいこと

  • AIで問い合わせたい業務は何か。いちばん困っている照会業務はどれか
  • 対象のDBにレプリカはあるか。読み取り専用のユーザーを作れるか
  • 意味の分からないフラグ・区分は、誰に聞けば分かるか（データオーナーは誰か）
  • どの機密区分のデータまで、クラウドのAIに渡してよいか

参考資料