こんにちは。CData Software Japan リードエンジニアの杉本です。
CData では「CData Connect AI」というkintone やSalesforce、SAP などに接続できるマネージドMCP プラットフォームを提供しています。
私自身とても好きな製品ですし、色々と利用する上でのメリットもあるのですが、とはいえ
「無料の公式 MCP があるなら、わざわざ有償の CData Connect AI を使う必要はないのでは？」
という大変もっともな質問をよく頂きます！
実はCData Connect AI の仕組みを詳しく紐解くと、「MCP」という一つの仕組みでも実装のアプローチで「こんなにも変わるんだ！」というのがあるのですが、直感的には理解しにくい部分があります。
というわけで今回はkintone の公式MCP Server とCData Connect AI のkintone コネクタを対象として、同一の kintone データ・同一のプロンプト・同一の AI モデルという条件でベンチマークを実施し、数字で答えを出してみました。
https://jp.cdata.com/ai/
https://cybozu.dev/ja/kintone/ai/kintone-mcp-server/
まず結論から
測定の詳細の前に、結論をお伝えしましょう。
数件レベルの単純なデータ取得・件数確認・レコードの書き込みなら、公式 MCP で十分です。 両者とも正確に動作し、コスト差も許容範囲内です。
しかし、実業務に耐えうる集計・分析などの一定規模以上のレコード処理が入った瞬間に状況が逆転します。
この差がどこから来るのか、順を追って説明していきましょう。
ちなみにこれはどちらが良い悪いというわけではなく、そもそものMCP というプロダクト上における設計思想やコンセプトの違いであると思っています。
検証条件
項目 | 内容 |
|---|
モデル | Claude Sonnet 4.6（入力 $3 / 出力 $15 per 1M トークン） |
タスク | 読み取り6種 ＋ 書き込み4種 ＝ 計10種 |
繰り返し | 各タスク3回、中央値を採用 |
対象データ | 案件管理1,016件・担当者管理1,008件 |
公平性確保 | 同一プロンプト・プロンプトキャッシュ無効・全ツールロード |
両サーバーにまったく同じ自然言語プロンプトを投げ、得られた回答を正解値（kintone 全件集計）と照合しました。
実際に利用したソースコードは以下で公開しています。
https://github.com/sugimomoto/CompKitoneMCP
両サーバーに投げたプロンプトは以下のとおりです。まったく同じ文面を CData Connect AI・公式 kintone MCP の両方に送信しています。
読み取りタスク
ID | 種別 | プロンプト |
|---|
t1 | 取得 | 案件管理アプリから案件を5件取得し、案件名を一覧にしてください。 |
t2 | フィルタ件数 | 案件管理アプリで、商談フェーズが「受注」の案件は何件ありますか。件数を数値で明示してください。 |
t3 | 集計 | 案件管理アプリの全案件を商談フェーズごとに件数集計し、各フェーズの件数を示してください。 |
t4 | 集計 | 担当者管理アプリの全担当者を部署ごとに件数集計し、各部署の件数を示してください。 |
t5 | 複合フィルタ | 案件管理アプリで、受注予定日が2025年7月1日以降、かつ商談フェーズが「受注」の案件は何件ありますか。 |
t6 | 合計 | 案件管理アプリの全案件の「売上」の合計金額を、円単位の整数値で示してください。 |
書き込みタスク（対象：活動履歴アプリ）
ID | 種別 | プロンプト概要 |
|---|
w1 | 単一登録 | 活動履歴アプリにレコードを1件追加（タイトル・対応種別・対応日付・内容を指定） |
w2 | 単一更新 | タイトルで特定したレコードの内容フィールドを更新 |
w3 | 一括登録 | 150件のレコードをできるだけ少ない回数でまとめて一括登録 |
w4 | 条件一括更新 | 条件に合致する150件すべての内容フィールドを一括更新 |
書き込みタスクは実行ごとに一意のマーカー文字列をタイトルに埋め込み、完了後に kintone 側で実データを検索して正誤判定しました。
実測結果
それでは実測結果を詳しく見ていきましょう。
正確性の比較
タスク | 種別 | CData | 公式 kintone MCP |
|---|
案件5件取得 | 取得 | ✅ 100% | ✅ 100% |
受注件数の確認 | フィルタ | ✅ 100% | ✅ 100% |
商談フェーズ別集計 | 集計 | ✅ 100% | ⚠️ 33% |
部署別集計 | 集計 | ✅ 100% | ❌ 0% |
期間×フェーズの件数 | 複合フィルタ | ✅ 100% | ✅ 100% |
売上合計（SUM） | 合計 | ✅ 100% | ❌ 0% |
単一レコード登録 | 登録 | ✅ 100% | ✅ 100% |
単一レコード更新 | 更新 | ✅ 100% | ✅ 100% |
150件一括登録 | 一括登録 | ✅ 100% | ✅ 100% |
150件一括更新 | 一括更新 | ✅ 100% | ✅ 100% |
単純な取得・フィルタ・書き込みでは差がありません。差が出るのは集計タスク（t3/t4/t6）のみです。
コストの比較（タスク別・中央値）
タスク | CData | 公式 kintone MCP |
|---|
案件5件取得 | ¥31 | ¥42 |
受注件数の確認 | ¥31 | ¥59 |
商談フェーズ別集計 | ¥29 | ¥115 |
部署別集計 | ¥29 | ¥481（❌不正解） |
期間×フェーズの件数 | ¥32 | ¥71 |
売上合計（SUM） | ¥29 | ¥109（❌不正解） |
単一INSERT | ¥31 | ¥54 |
単一UPDATE | ¥39 | ¥69 |
150件一括INSERT | ¥64 | ¥93 |
150件一括UPDATE | ¥59 | ¥94 |
「部署別集計（t4）」の行を見てください。公式 MCP は ¥481 を消費して誤答 を返しています。CData は ¥29 で正解 です。同じ質問に対して16倍のコストをかけて間違えるという結果でした。
内訳を確認すると、公式 MCP は担当者データ1,008件を全件取得しようとして 約103万トークン を消費していました。CData は内部で集計クエリをうまく活用してトークンは数万程度で済んでいます。
これは1000件レベルだったので、この結果で済みましたが、実業務では数千件〜数万レコードを扱うことはざらにあることでしょう。それを踏まえると、なかなか怖い結果だなと感じますね。
サーバー全体の比較
指標 | CData Connect AI | 公式 kintone MCP |
|---|
公開ツール数 | 11 | 24 |
ツール定義のトークン | 6,711 tok | 26,985 tok |
平均トークン/タスク | 70,926 | 244,075（3.4倍） |
平均レイテンシ | 63.0秒 | 66.6秒 |
10タスク1巡のコスト | ¥374 | ¥1,185（3.2倍） |
レイテンシ（処理時間）はほぼ同じです。差が出るのはトークン数とコストです。
なぜ集計で差が出るのか？
ここが本質的な部分なので、少し丁寧に説明します。
kintone 公式 MCP の構造
kintone 公式 MCP の get-records ツールは、1回の呼び出しで取得できるレコード数が最大500件です。1,000件以上のデータを集計しようとすると、AI は次のような動作をします。
まず 500件取得する
「まだデータが残っています、次を取得します」と宣言して続きを取得する
全件集計をAI 側（クライアント側）で行う
この構造には2つの問題があります。
問題①：集計の失敗。ページングが不完全なまま集計を始めてしまうケースがあり、途中のデータで誤った答えを返すことがあります。
問題②：トークンの爆発。完走しようとすると、取得した全レコードのデータがそのままトークンとして流れ込んできます。1,000件以上のレコードを全部読み込む = そのデータ量分だけコストが膨らむということです。
CData Connect AI の構造
ちょっとここからは技術的な部分含めて、CData Connect AI とkintone 公式MCP の違いを解説したいと思います。
kintone 公式MCPはREST API のデザインをベースに構築したMCP Server になっています。しかしながら、CData Connect AI はそのままREST API を利用するのではなく、汎用クエリ言語であるSQL をAI とのコミュニケーションツールとして利用したMCP となっています。
この設計思想によりGROUP BY や SUM といった集計処理をAI から受け取ることができ、それを CData Connect AI 上でSQL からREST API に変換、kintone から結果を受け取ったものをさらにCData Connect AI 上で集計・最適化し、必要最小限の結果だけを返す という仕組みを実現しています。
AI →「商談フェーズ別の件数を集計して」
↓
CData Connect AI → SQL に変換して kintone REST API を呼び出す
SELECT フェーズ, COUNT(*) FROM 案件管理 GROUP BY フェーズ
↓
kintone → REST API でデータを返す
↓
CData Connect AI → 集計・最適化して結果（6行）だけを AI に返す
全件のデータが AI に流れ込まないため、トークンが膨らみません。集計精度もデータベース側で保証されます。
書き込みは互角。ただし傾向の差はある
INSERT/UPDATE については、両サーバーとも全問正解でした。ここは率直に言って、書き込みだけが目的なら公式 MCP で十分です。
傾向の違いとして：
呼び出し回数を重視するか、トークン量を重視するかで好みが分かれるところです。どちらの観点でも大きな差はなく、正確性も同等です。
コスト以外の差：リモート MCP という設計の違い
実はコストや正確性とは別に、もう一つ大きな違いがあります。
公式 kintone MCP はローカルMCP（stdio）方式です。つまり、PC にインストールした Claude Desktop 等からしか使えません。スマホアプリや Claude Web（ブラウザ版）では動作しません。また、組織に展開しようとすると全員の PC で個別に設定が必要になります。
CData Connect AI はリモート MCPです。クラウド上にエンドポイントが存在するため、Claude Web・スマホアプリ・Claude Desktop のすべてから使えます。組織展開も、URL とユーザー登録だけで済みます。
このあたりの違いについては、以前こちらの記事でも詳しく紹介しました。
まとめ：どちらを選ぶか
今回の検証で見えてきた選び方をまとめると、以下のようになります。
用途・状況 | 推奨 |
|---|
個人利用・Claude Desktop のみ・書き込み主体 | 公式 kintone MCP（無料） |
少数データの取得・フィルタだけ | どちらでも可 |
集計・分析・レポート生成 | CData Connect AI |
スマホ・ブラウザ版 Claude で使いたい | CData Connect AI |
組織・チームへ展開したい | CData Connect AI |
「無料の公式 MCP があるなら有償は不要では？」という最初の問いに対する答えは、「用途・ユースケースによる」 です。ただ、集計・分析用途が入る場合は、コストと正確性の両面で CData Connect AI を選ぶ理由がはっきりします。
なお、今回のベンチマークはプロンプトキャッシュを無効にした素の比較です。実運用ではキャッシュを有効にすることで入力トークンを大幅に削減できます（特にツール定義が大きい公式 MCP 側でキャッシュの効果が大きくなります）。「実運用コスト」は今回の数値よりも下がる可能性があります。
おわりに
私自身API をひたすら触っている人間ということもあり、API の設計思想がそのままMCP 化したとしても、AI 活用の恩恵がスムーズに受けられるわけではないだろうとは直感的に思っていました。
そして今回実際の数値として出してみて、思った以上のトークン・コスト差が出て、個人的にもびっくりでした。
もちろん、アプローチとしてAPI の特性を意識しながら、プロンプトをチューニングすることは選択肢としてあり得ると思います。とはいえ、誰もがそういった知識を持っているわけでもなく、API そのものが結構暗黙的な了解で成り立っていることが多いことから、AI もその前提を意識してMCP を扱うことは難しいところがあると思います。
今後より「AI にとってのエクスペリエンスを意識したMCP の考え方・設計思想」というのが出てくると良いなと思った今日このごろです。
