概要
自社データを LLM につなぐときの設計パターン。LLM には検索・集計の「条件指定」だけを任せ、算術はサーバー側で実行する。 デジタル庁が公開した行政手続データ(約75,000件)の MCP サーバー実装がこの形を採っている。
中核となる原則
LLM に算術をさせない
LLM は自然言語から「何を集計したいか」を読み取るのは得意だが、数値計算そのものは不確実。役割を分ける。
- LLM の担当 — 検索条件・集計軸の指定
- サーバーの担当 — 実際の集計・算術
この分離により、出力の数値がハルシネーションで変わることがなくなる。
意味定義を構造化して持つ
dataset.yaml のような形でカラムの意味・単位・取りうる値を定義し、LLM がスキーマを推測しなくて済むようにする。セマンティックレイヤーに相当する。
ファジーマッチの適用範囲を絞る
曖昧一致は便利だが、適用範囲を限定しないと誤った行を拾う。どのフィールドに対して許すかを明示的に決める。
列指向フォーマットを使う
Parquet を採用することで、集計クエリのスキャン量を抑える。
転用のポイント
自社データを AI につなぐ際、まず「LLM に何をさせないか」を決めるところから始める。検索インターフェースを提供するのであって、計算エンジンを LLM に肩代わりさせるのではない。
関連ページ
ソース記事
- デジタル庁の行政手続 MCP サーバーに学ぶ「LLM に計算させない」データ設計 — 2026-08-16
- NEC「部署が丸ごとAI」の中身 — コーポレートAI・Workforce部門の4階層と、人が手放さなかった仕事 — 2026-09-02