こんにちは。CData Software Japan リードエンジニアの杉本です。

「AIに社内のデータを使わせたい。その手段としてMCPで繋げばいいのは分かった。でも、どのようなアプローチで繋ぐのが正解なんだろう？」

ウェビナーなどのアンケートでもそうなのですが、最近いただくご相談は、この形が増えたなと感じています。MCP の利便性・可能性を訴えてきた人間としては、次のステージに進んでいる会社が増えていてとても嬉しい限りです。

ただ、MCP そのものの解説記事は増えましたが、「複数ある選択肢から、自社はどれを選ぶべきか？ どのようにセキュリティやベネフィットを説明するべきか？」を判断するための材料は、意外と揃っていないように思います。

複数の選択肢とは以下の大きく3点に分けられます。

• スクラッチ：AI などを駆使してスクラッチで自社でMCPを開発する

• ネイティブ：Salesforce やkintone などベンダーが提供しているネイティブのMCP を利用する

• マネージド：CData Connect AI のようなマネージドのMCPサービスを利用する

というわけで今回は、そのような悩みを抱えている方々に向けて、次の2つをゴールを念頭にBlog として書いてみました。

1. 自社の条件に照らして、どの接続方式を選ぶのか（あるいは選ばないのか） を、評価軸・選択肢の採点など根拠をもって説明できるようになること

2. そのうえで、マネージドMCP であるCData Connect AI のポイントを、社内説明に使いやすい形で整理してお届けする こと

前半では改めて「そもそもなぜ MCP なのか」を公開調査データから整理し直します。ここは、皆さんが社内で説明される相手——セキュリティ部門や上長、あるいはお客様——に前提を共有していただくためのパートとしてイメージしてもらえればと思います。

後半で評価軸と選択肢の採点、CData Connect AI のポイント解説に入ります。ちょっと長くなりますが、お付き合いください。

なぜ今、MCP なのか？

日本の「いま」から見る「入れた」は達成、「効果」は6カ国最下位という現実

さてまずは「なぜ今MCPなのか？」について改めて整理してみましょう。

PwC Japan グループの「生成AIに関する実態調査2026 春 6カ国比較」から見ていきます。

https://www.pwc.com/jp/ja/knowledge/thoughtleadership/generative-ai-survey2026.html

日本企業の生成AI活用・推進度は 2026年春時点で87%。前回調査から11ポイント上昇し、米国90%・英国89%・中国91%・ドイツ89%・韓国93% と、ほぼ横並びの水準に到達しました。「日本は生成AIで遅れている」という前提は、少なくとも導入という意味ではもう当てはまらないようです。

問題はどちらかといえば、その先です。

• 効果を「期待以上・期待通り」とする企業の割合は、6カ国中で最下位

• 生成AIの効果を従業員や顧客への財務的な還元につなげた企業は 40% にとどまり、こちらも6カ国最下位（米国75%・英国74%）

同レポートでは、その理由として「日本企業の活用実態はなお既存業務の効率化や個別タスクの支援が中心であり、ツール利用の域を出ない面がある」と指摘されています。

導入では追いついた。けれどもビジネスインパクト・成果では離されている、というのが実情です。

なぜビジネスインパクトが変わらないのか？ AIが自社のデータに届いていない

ヒントは、日本情報経済社会推進協会（JIPDEC）の「企業IT利活用動向調査2026」にありました。

https://www.jipdec.or.jp/library/it-resarch/it-resarch2026-02.html

この調査では、AIを実践・活用している企業は 36% で、残りの多くは試行・検討段階にあるとされています。そして興味深いのが、導入後も残り続ける課題です。

• セキュリティ対策への懸念

• データ化されていない情報の多さ

• プライバシーへの懸念

• 出力結果への信頼性不安

導入前の課題として最も多いのは「人材・スキル不足」なのですが、導入した後まで残るのはこちらの4つでした。要するに、AIを入れてみたものの、自社のデータに届かない・届いても答えが信用できないという状態です。

Gartner も同じ方向を指しています。

https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

• 2026年までに、AI-ready data に支えられていないAIプロジェクトの60%が放棄される見込み

• 63%の組織が、AIに適したデータマネジメント体制を持っていない、または持っているかどうか分からない

先ほどのPwC のレポートでも「生成AIの活用効果が期待を上回っている理由」の部分を見ると、「どの業務でどの価値を出すのかをビジョン起点で選び、その実行に必要な業務プロセス、データ、利用環境、ガバナンスなどを先に整えることが、効果創出の前提」と触れられています。

生成AIが「便利なツール」から「業務の意思決定を支える存在」に変わる分岐点は、自社のライブデータに対してAI Ready な状態で接続されているかどうかにあります。 これが、MCP が必要とされる理由の出発点です。

つなぐ標準は、MCP でほぼ決着

では、どうつなぐか。ここは2026年に入って答えが出た感があります。

MCPの採用状況について、Stacklok の「State of MCP in Software 2026」を引用した統計があります。

https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol

• MCPサーバーが本番稼働している組織は41%（限定的な本番運用29% ＋ 広範な本番運用12%）。ソフトウェア業界では45%

• SDK のダウンロードは2026年初頭で約9,700万/月

もう「MCPとは何か」を説明する段階ではなく、実際に本番で動いている段階です。社内で「MCPはまだ様子見では」という意見が出た場合、この数字が反論の材料になるでしょう。

組織でMCP を採用する判断は「セキュリティ」で止まる

先ほどの Stacklok の調査で、私が一番注目したのは採用の障壁でした。

上から順に、 セキュリティ懸念と要件 → 実装コスト → レガシーシステム統合の複雑性 → トレーニング → ビジネス価値の証明、という順序です。

コストでも、価値の証明でもなく、セキュリティが1位でした。

Palo Alto Networks も、MCPのエンタープライズ採用における課題を整理しています。

https://www.paloaltonetworks.com/cyberpedia/mcp-enterprise-adoption-challenges

過剰な権限を持つMCPツール、信頼できないMCPサーバー経由のデータ漏洩やプロンプトインジェクション、悪意あるツールのなりすまし、認証バイパス。こうしたリスクを挙げたうえで、「MCPの普及速度が、そのセキュリティモデルの成熟を追い越した」と指摘しています。

弊社のウェビナーでも、まったく同じことが起きています

ここまでは公開データの話でしたが、私たちが開催しているウェビナーのアンケートでも同じ傾向がはっきり出ています。社名は伏せたうえで共有させてください。

2026年8月に実施した、kintone のデータをClaude・AI から扱うハンズオンウェビナーでのことです。

https://jp.cdata.com/resources/claude-kintone-handson-2026/

アンケートで「AI とデータ連携を進めるうえでの課題」を伺ったところ、回答の大半がセキュリティとデータ所在に関するものでした。ある企業の情報システムご担当者からは「セキュリティが最重要と考えている」という、はっきりしたコメントもいただいています。

さらに象徴的だったのが Q&A でした。いただいた質問が、

• 会社アカウントで使うときの注意点

• 権限・スコープの扱い

• 売上金額のようなデータを扱う際のセキュリティ懸念

と、3つとも同じ方向に集中しました。 ハンズオン形式なので「どう作るか」という質問が来ると想定していたのですが、実際に来たのは「どう安全に使うか」だったわけですね。

これは単発の傾向ではありません。

• 2026年7月の Microsoft Copilot 連携ウェビナーでは、Q&A が「権限管理・認証方式」「複数データソース連携」といった、アーキテクチャとセキュリティに関する質問に集中しました

• 2026年5月の新機能紹介ウェビナーでは、オンプレミス接続機能について「セキュリティ的な問題がないことが分かる資料があれば助かります」というご要望を複数いただき、開催後の宿題として「セキュリティ解説資料の作成」を起票することになりました

商談の場でも、セキュリティチェックシートや第三者評価サービスの調査票への記入を求められる機会は、この1年で明らかに増えています。予算の承認は取れているのに、セキュリティレビューや法務確認に時間がかかるというケースも、珍しくありません。

つなぐ手段は決まった。でも、つなぐ判断が止まっている。 ここから先が、本題です。

では、何で評価するのか？ Connectivity / Context / Control という3つの軸

選択肢を比べるには、先に物差しが要ります。CData ではこれを Connectivity・Context・Control の「3つのC」として整理しています。

そして重要な前提が一つあります。

これら3つは、個人で試している間は一つも問われません。組織として使うと決めた瞬間に、同時に立ち上がります。

PoC レベルで自分の担当データを自分のアカウントで参照している間は、届く範囲は1〜2システムで足りますし、答えがおかしければ自分で気づけますし、権限も監査も問題になりません。組織のデータに、組織として、継続的につなぐと決めた瞬間に、3つとも必須要件に変わります。

セキュリティが採用障壁の1位になっているのは、まさにこの理由だと考えています。個人の実験では発生しない要件が、組織で使うことによって一斉に発生する。それがガバナンスの問題として現れているわけですね。

Connectivity：「届くか？」だけの話ではない

部門ごとに使っているシステムは違います。営業は Salesforce、経理は会計・基幹システム、製造は閉域網の中のデータベース。全社に広げるなら、接続対象は部門の数だけ増えていきます。

そして必ず「クラウドに出せないデータ」が出てきます。JIPDEC の「データ化されていない情報の多さ」という指摘は、実務的にはここを多く含んでいると思います。

もう一つ、見落とされやすいのが接続の維持です。SaaS の API 仕様は変わりますし、スキーマも変わります。認証トークンの管理も必要です。この保守を誰が背負うのかは、Connectivity 軸の重要な論点です。

Context：各種データの「意味の解決」を、誰がやるのか？

データを渡せば AI が正しく答えるわけではありません。「受注」が自社ではどのオブジェクトを指すのか。「今四半期」をどの日付範囲に変換するのか。「売上」に更新分を含めるのか。こうした知識はスキーマには書かれておらず、組織の暗黙知として存在しています。

この「意味の解決」を、どこでやるのか。 これが Context 軸の核心です。モデルに推測させるのか、接続層で解決するのか。

そして、ここは実際に大きな差が出ます。CData で実施した検証をご紹介します。

モデルを GPT-5 に固定し、temperature を0.2、エージェントフレームワークを LangGraph ReAct に統一したうえで、CRM・プロジェクト管理・クラウドデータウェアハウス・ERP の4プラットフォームについて、それぞれ4種類・合計16種類の標準化プロンプトを用意しました。これを5つの接続アプローチで繰り返し実行し、延べ300回以上のテストを行っています。評価は部分点なしの二値判定です。

出典：CData ホワイトペーパー「25%の精度ギャップ」（2026年3月）

同じモデルを使っているのに、接続の仕方だけで正答率が約59%から98.5%まで開きました。 プラットフォーム別では ERP での差が最も大きく、CData の100%に対して他のアプローチは20%程度でした。

そして、この誤差は複利で効きます。1ステップあたりの精度が75%だとすると、5ステップを連鎖させるエージェントタスクでは、最終的にすべて正しく完了する確率は24%を下回る計算になります。業務ワークフローに載せた瞬間に効いてくる話です。

失敗には典型的なパターンがありました。

• 日付ロジックの解決不足：「今四半期にクローズする案件を教えて」に対し、「今四半期」を日付範囲に変換できず、条件を無視して全件を返す

• スキーママッピングの誤り：「金額順トップ10の注文」を尋ねると、誤ったテーブルを参照して見当違いの結果を返す

Control：AIは指示を「解釈」して動く

通常の Web アプリケーションでは、ユーザーがボタンを押した場合にのみ決まった操作が決まった権限で実行されます。一方、生成AIは与えられた指示を「解釈」して動くため、想定外の操作を自律的に行う可能性があります。

たとえば営業担当者が「先月から動きのない案件のステータスを整理して」と AI に依頼したとします。AI が Salesforce にアクセスでき、更新権限も持っていた場合、「整理＝進捗なし案件を失注に更新」と解釈し、他人が所有している商談まで一括で上書きしてしまう、というリスクがあります。

重要なのは、AIが何かをしたくても物理的にできない設計にしておくことです。AIに良心を持たせるのではなく、できないようにする。

Control 軸は評価項目が多いため、後ほど 後半の章で8つの具体的な評価ポイントとして整理します。

ネイティブ・スクラッチ・マネージドの選択肢を3軸で採点する

物差しが揃ったので、選択肢を並べます。MCPでビジネスデータにつなぐアプローチは、大きく3つです。

違いは「3つの軸を、誰が、どれだけ担保するか」に集約されます。

ネイティブMCPが合理的になる条件

正直に線を引きます。接続先が1〜2システムで、使うのが1部門だけであれば、ネイティブMCPで十分だと思います。

Salesforce や Atlassian といった主要ベンダーは、自社データソース向けのMCPサーバーを提供し始めています。単一システムへの単純な参照なら、わざわざ別のレイヤーを挟む理由はありません。

判断の分かれ目は「横断するデータソースが3つ以上かどうか」あたりだと考えています。3つ以上になると、以下が効いてきます。

• 1データソース＝1プロジェクトになる。実装も保守も3件分で、ベンダー更新のたびに個別対応が必要

• ベンダーが公開を選んだツールしかAIに渡せない。AIの能力がベンダー任せで決まる

• 横断クエリを誰が組むのかという問題が残る。複数システムの結合をネイティブMCPだけで実現するなら、セマンティック検索レイヤーやMCPゲートウェイを自前で設計・運用することになる

• 横断ガバナンスが組めない。権限や監査がベンダーごとにバラバラでは、組織全体のポリシーを適用できない

スクラッチ内製が合理的になる条件

コーディングエージェントの発達で、MCPサーバーの内製ハードルは確実に下がりました。私自身もClaude Code を使いながら、MCP サーバーを開発したことがありますし、MCP やAPI 仕様の知識があれば、開発そのものはそんなに難しいものではありません。

こちらも正直に線を引くと、コードレベルで完全にコントロールしたい、特殊な内部ロジックが必要、対象が限定的で DevOps 体制がある、などの条件が揃うのであれば、スクラッチは十分に合理的な選択です。

一方で、判断の材料として押さえておきたい点が2つあります。

1つめは、差が出るのが運用フェーズだということ。

2つめは、プロトコルの追従コストです。

MCPの仕様はこれまでおよそ4〜8か月おきに更新されてきました。2026年7月28日のリリースは、ステートレス化・拡張機能フレームワーク・認可強化・JSON Schema 2020-12 対応を含む、これまでで最大級の改訂です。

https://jp.cdata.com/blog/mcp-2026-07-28-release

しかも本記事の執筆時点では、公式の TypeScript SDK（1.30.0）が認識するプロトコルバージョンはまだ 2025-11-25 までで、新仕様は @modelcontextprotocol/core という別パッケージの2.0系に切り出されています。Node.js の要件も18以上から20以上に上がりました。つまりバージョンを上げるだけでは終わらず、依存パッケージの構成そのものを組み替える作業になります。

この追従を自社で担い続けるかどうかは、内製判断の重要な変数だと思います。

https://www.cdata.com/jp/blog/mcp-build-vs-buy/

セキュリティをどう評価するか？ 8つの軸

Control 軸は、そのままでは評価が難しい領域です。「セキュリティが心配です」で止まってしまうと、社内の議論が前に進みません。

幸い、2026年に入って拠り所になるフレームワークが2つ揃いました。

一つが OWASP MCP Top 10。MCP専用としては初の公式セキュリティフレームワークで、執筆時点ではベータ版として公開されています。

https://owasp.org/www-project-mcp-top-10/

もう一つが、NSA が2026年5月20日に公開したMCPセキュリティガイダンス（Cybersecurity Information Sheet）です。「Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation」というタイトルで、アクセス制御の欠落・トークンとセッションのセキュリティ・監査ログの不足など8つのリスク類別を挙げています。

https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf

この2つを突き合わせると、MCP固有のリスクに対応する評価ポイントは 6つ に整理できます。

MCP固有のリスクに対応する6つの軸

加えて、社内のセキュリティ審査で必ず問われる2つ

ここで一点、補足させてください。OWASP MCP Top 10 も NSA ガイダンスも、扱っているのは「MCPというプロトコルと、その実装のリスク」です。 サービス提供者そのものを評価するための枠組みではありません。

一方、実際の社内レビューやセキュリティチェックシートでは、これに加えて必ず2つが問われます。私たちが調査票への記入を依頼される際も、この2つは例外なく入っています。上の6つとは出どころが違うことを明示したうえで、評価軸として足しておきます。

この6＋2の表は、そのまま社内のセキュリティレビューの論点表としてお使いいただけると思います。 重要なのは「リスクがあるかどうか」ではなく、「8つの軸それぞれで、誰が何をどこまで担保しているか」を確認することです。

CData Connect AI は、各軸にどう答えるか？

ここまでが評価のフレームです。ここからは、CData Connect AI がそれぞれの軸にどう答えているか？ を整理します。社内でご説明いただく際の材料として使っていただければと思います。

https://jp.cdata.com/ai/

その前に ― CData Connect AI が何をしているのか

各軸の話に入る前に、製品のコンセプトを押さえさせてください。ここを飛ばすと、この後に出てくる「ビュー」や「SQL」といった言葉が唐突に感じられると思います。

CData Connect AI は、しばしば「マネージド型のMCPプラットフォーム」と紹介されます。それは正しいのですが、MCP はあくまで出口の一つです。サービスの中核にあるのは、CData が20年近く手がけてきた データ仮想化 の技術です。

データ仮想化とは、性質の異なる多数のデータソースを、単一の共通インターフェース（リレーショナル＝SQL）に標準化して見せる技術です。

たとえば Salesforce・kintone・SAP・Snowflake は、それぞれまったく違う顔をしています。

Connect AI は、この差異をすべてコネクタ側で吸収します。 その結果、利用する側からは Salesforce も Snowflake も kintone も「テーブルとビューの集まり」に見えます。同じSQLで問い合わせられますし、データソースをまたいだ JOIN もできます。

そして MCP エンドポイントは、この標準化された層の上に乗るインターフェースです。

この構造には、副次的な効果もあります。MCPの仕様が改訂されても、影響を受けるのは上の薄い層だけで、下のデータ仮想化レイヤーは揺れません。 評価軸7（仕様追従）で「追従はプラットフォーム側が吸収する」と書けるのは、この分離があるからです。

そして何より大事なのは、この仮想化レイヤーが3つのCすべての土台になっているという点です。

なお、標準化するといってもデータをどこかに集めるわけではありません。AIから届いたクエリは、その場で各データソースのAPI呼び出しに変換されて実行されます。コピーは作られません（インプレースアクセス）。

この先に出てくる機能の整理

各軸の話に入る前に、この記事で登場する機能名を先に並べておきます。この5つを押さえておけば、以降の説明はすべて追えます。

加えて、Jobs（ジョブ）という機能があります。対象のテーブルを定期的にキャッシュしておく仕組みで、リアルタイム性が不要なデータに使います。

関係を整理すると、こうなります。

Connection（つなぐ）
    ↓
Derived View（自社のルールで加工する）
    ↓
Workspace（見せる範囲を決める）
    ↓
Toolkit（AIに渡すツールを選ぶ／Custom SQL Tool もここに含まれる）
    ↓
MCP エンドポイント

下にいくほど「AIに近い」層だと考えてください。上の層で扱える範囲を広げ、下の層で絞り込んでいく構造になっています。

それでは、各軸への答えを見ていきます。

Connectivity への答え

Connectivity 軸で問われるのは「部門ごとに異なるシステムに、AIが届くか」と「その接続を誰が維持し続けるのか」でした。

データソースを増やす作業が、実装ではなく設定になります。

新しいデータソースをつなぐとき、通常であれば認証方式を調べ、APIの癖を調べ、ページングやレート制限に対応するコードを書くことになります。Connect AI では、その部分はすでにコネクタとして用意されています。接続情報を入力すれば、そのデータソースは他の350種類と同じ「テーブルの集まり」として扱えるようになります。

この「同じ形になる」という性質が、部門横断で効いてきます。 営業がSalesforce、経理が基幹システム、製造が閉域網のDBという状況でも、追加するたびに新しい実装が発生しません。

最後の行が、実は運用フェーズで最も効きます。 SaaS の API 仕様やスキーマは変わります。認証トークンの管理も要ります。データソースが増えるほど、この追従作業は積み上がっていきます。コネクタが標準化を担っているということは、その標準化を維持し続ける責任もプラットフォーム側にあるということです。

Context への答え

Context 軸で問われるのは「意味の解決を、誰がやるのか」でした。Connect AI は、これをAIに丸投げせず、データ仮想化レイヤーで解決します。 順に見ていきます。

第1段：セマンティックレイヤーが解決する3つのこと

先ほど「Connect AI から見ると Salesforce も Snowflake も同じテーブルに見える」と書きました。ただし、ただ形を揃えているだけではありません。 データ仮想化レイヤーには、各プラットフォーム固有の意味を解決する仕組み——セマンティックレイヤー（コンテキストレイヤーとも呼ばれます）——が含まれています。

この層は、AIエージェントが送る自然言語のクエリを、各プラットフォーム固有のスキーマ・状態遷移・日付ロジックに変換します。具体的には次の3要素です。

これが、先の検証で ERP の正答率が100%対20%まで開いた理由です。ネイティブMCPでは「今四半期」の変換も、どのテーブルが「注文」に当たるかの判断も、モデルが学習データから推測するしかありません。Connect AI では、AIにクエリが届く手前で意味が確定しています。

実際に AI がどう動いているかを見ると、イメージしやすいと思います。

AI は、いきなり正解のクエリを書いているわけではありません。メタデータを取得して「商談」が Opportunity テーブルであることを確かめ、列の説明から「クローズ率」が Probability 列だと確かめ、そのうえで標準SQLを組み立てて実行しています。

ここで効いているのが、データ仮想化による標準化です。どのデータソースでもメタデータの形式と SQL が共通なので、AI は「探して・確かめて・組み立てる」という同じ手順を、安定して踏めます。 Salesforce だから SOQL、別のシステムだから独自構文、という切り替えが発生しません。

この3要素については、先ほどの精度検証を扱った記事でも詳しく整理しています。

https://www.cdata.com/jp/blog/ai-accuracy-mcp-server-semantic-layer/

第2段：自社固有のルールを、ビューとして乗せる

コネクタが持っているのは「その製品の一般的な知識」までです。「自社では受注をどう定義しているか」までは知りません。そこを埋めるのが、先ほど挙げた Derived View です。

データ仮想化によってすべてがテーブルとして扱えるため、複数のデータソースをまたいだ結合・フィルタを、SQL で1つのビューとして定義できます。 たとえば「有効な商談とは、どのステージで、どの期間で、どの項目が埋まっているものか」という自社の定義をビュー側に持たせておけば、AIは業務ルールを知らなくても正しいデータセットを受け取れます。

この「複数ソースをまたいで1つのビューにできる」という点は、ネイティブMCPにはない性質です。 データソースごとに別々のMCPサーバーが立っている構成では、結合はAI側でやるしかありません。

第3段：精度が出たあとに残る、トークンと再現性の課題

ここで、先ほどの動作イメージをもう一度思い出してください。AI は「探して・確かめて・組み立てる」を毎回やっています。 意味解決が済んでいるので答えは正しいのですが、探索するという性質そのものは変わりません。

つまり、テーブル一覧を取得し、列を確認し、そのうえでクエリを組み立てる——この往復が毎回発生します。この探索がトークンを消費し、毎回ゼロから始まるため、同じ質問でも回答の組み立て方が安定しません。

CData で実施したベンチマークです。Salesforce・Snowflake・ServiceNow を横断するクエリを Claude Sonnet 4.6 で temperature=0 の条件で実行し、機能ごとにトークン消費量を測定しました。

処理時間も、Derived View で242.8秒から約50秒へ、Custom Tool では19秒まで短縮されました。標準の Salesforce Account スキーマは73カラムありますが、Custom SQL Tool で6カラムに絞れば、ツール定義そのものが約80%小さくなります。

https://www.cdata.com/jp/blog/token-efficient-enterprise-claude-workflows/

なお、汎用ツールが悪いわけではありません。 スキーマが不明で、クエリも未定義という探索フェーズでは、汎用ツールをまるごと使う価値があります。トークン消費は柔軟性の対価です。最適化が効くのは、ワークフローが繰り返しのパターンとして固まってからです。

その場合の推奨順序は次のとおりです。

1. Workspace でデータカタログの範囲を絞る（300のツールではなく、3つだけを見せる）

2. よく使うコネクタに Custom SQL Tool を用意し、スキーマを必要なフィールドだけに絞る

3. 繰り返すマルチソース結合は Derived View にまとめる

4. リアルタイム性が不要なデータは Jobs でキャッシュする

5. 成熟したワークフローは Toolkit としてワークフロー単位に束ねる（営業用・財務用・サポート用）

Control への答え ― 5層のアクセス制御

Control 軸で問われるのは「誰に何を見せ、誰が何にアクセスしたかを説明できるか」でした。

ここでも土台になるのは、やはりデータ仮想化です。すべてのデータソースがテーブル・カラム・行として正規化されているため、権限をその粒度でかけられます。

これは当たり前のことではありません。データソースごとに個別のMCPサーバーが立っている構成では、権限の考え方もサーバーごとにバラバラになります。「Salesforceでは項目レベル、kintoneではアプリ単位、自作サーバーでは実装した人次第」という状態では、組織全体に一つのポリシーを適用しようがありません。

Connect AI では、共通のリレーショナル表現の上に権限が乗るため、どのデータソースに対しても同じ考え方で制御でき、同じ形式で監査ログが残ります。 これが、次に説明する5層のアクセス制御が成立している理由です。（表はAI に近い側から順に並べています。土台は最下段の Layer 1 です）

土台になるのは Layer 1 です。Connect AI 側で許可した操作が、データソース側の権限を超えることはありません。

組織で使ううえで特に重要なのが Layer 2 の Per-User Authentication です。各ユーザーが自分の認証情報でデータソースに接続するモードで、これを使うと AIが返す範囲がユーザーごとに変わります。営業と人事で見えるものが違う、という要件にそのまま対応できます。

Layer 3 では、AIが使うユーザーアカウントに Select のみを付与すれば、AIはデータを参照できても変更・削除は物理的に行えません。Layer 5 の Toolkit では、AIに渡すMCPツールそのものを管理者が定義します。更新系ツールを有効化しなければ、AIはどのようなプロンプトを受け取っても更新を実行できません。

https://www.cdata.com/jp/blog/connect-ai-security-model-5-layers/

セキュリティ8軸への対応

8つの評価軸に対する対応を整理します。すべてが満点というわけではないので、そこも含めて書きます。

正直に補足しておきたい点が3つあります。

評価4の「野良サーバーの検出」は、Connect AI の機能ではありません。 接続を1か所に集約して野良サーバーを減らすことはできますが、「社内で誰かが勝手に立てたMCPサーバーをスキャンして見つける」機能は持っていません。CASBやネットワークスキャンなど、別のレイヤーで手当てする領域です。

評価6のSIEM連携や改ざん不能ログについては、要件次第で個別にご確認ください。 クエリログ・監査ログは取得できますが、お客様の監査要件を満たすかは環境によって変わります。

プロンプトインジェクションのリスクも、マネージドにすればゼロになるわけではありません。 悪意のある指示がデータの中に紛れ込む可能性は残ります。だからこそ、5層アクセス制御で「実行できることの範囲」を絞り込む設計が必要になります。そもそも更新のツールを渡していなければ、AIがどんな指示を受け取っても更新は実行できません。

まとめ：自社はどの条件に当てはまるか

長くなりましたので、判断のポイントを整理します。

まず、接続方式の分岐点。

次に、セキュリティの評価。 8軸を、選定候補それぞれについて埋めてみてください。「リスクがあるか」ではなく「誰が何をどこまで担保しているか」で並べると、社内での議論がかみ合いやすくなります。

そして、CData Connect AI を選ばれる場合の、はじめの一歩。

1. まず読み取り専用から始める。 コネクション権限を Select のみに絞り、Toolkit で更新系ツールを無効にする

2. Workspace で公開範囲を絞る。 AIに見せるアセットを、そのユースケースに本当に必要なものだけにする

3. よく使うクエリを Custom SQL Tool にする。 ここで精度もトークンコストも一気に改善します

4. 部門ごとに Toolkit を切る。 営業用・財務用・サポート用と分けることで、各部門に委ねられる状態をつくる

書き込みを伴う処理は、開発環境やステージング環境で必ずテストしてから本番のデータソースに切り替えるようにしましょう。

CData Connect AI は14日間の無料トライアルをご用意しています（クレジットカード不要）。

https://jp.cdata.com/ai/

セキュリティ評価やアーキテクチャの相談は個別にも承っております。社内のセキュリティレビューで確認事項が出た場合も、お気軽にお問い合わせください。

https://jp.cdata.com/contact/