社内に複数のデータ基盤があり、資産管理や問い合わせ対応がシステムをまたいでいる組織は少なくありません。
ハードウェア資産はSnowflake（クラウド型のデータウェアハウス）、ソフトウェア資産はServiceNow（ITSM・業務ワークフロー基盤）というように、データの置き場所が分かれているケースです。
こうした環境で「Timが管理している資産は何か」のような横断的な質問にAIエージェントで答えさせたい、と考えたときに検討候補になるのがMCP（Model Context Protocol、AIエージェントが外部ツールやデータソースを呼び出すための標準プロトコル）を使った連携です。
この記事では、ServiceNowが提供するMCP Server（ServiceNow内のフローやナレッジグラフをAIエージェントから呼び出し可能なツールとして公開する機能）と、Snowflakeが提供するCortex Agent（自然言語クエリからSQLを組み立てて回答するAI機能）を組み合わせる構成が、自分のプロジェクトに合うかどうかを判断する材料を整理します。
どんな場面でこの選定が必要になるか
典型的なのは、資産管理・問い合わせ対応・監査対応などで、複数システムに分散したデータを1つの窓口で検索したい場面です。
具体的には、ハードウェア資産台帳がSnowflakeのテーブルにあり、ソフトウェアライセンスや保守契約の情報がServiceNowのテーブルとナレッジグラフ（テーブル同士をエッジでつなぎ、グラフ構造として自然言語検索できるようにする機能）にある、という構成です。
この状態でユーザーがChatOpsやAIエージェント経由で質問したとき、どちらのシステムにデータがあるかを意識させずに回答を返したい、というニーズが出てきます。
この構成では、Claude Code（Anthropicが提供するAIコーディング・エージェントツール）がMCPクライアントとして動作し、ServiceNow MCP Serverに接続して質問を投げる形を取ります。MCP Server側は内部で「Snowflakeを呼ぶツール」と「ServiceNow内を検索するツール」を使い分け、クライアントはどちらのツールがどのデータを持っているかを知る必要がありません。
判断軸1: データの分散度合い
最初に確認すべきは、参照したいデータが本当に複数システムにまたがっているかどうかです。
Snowflake単体、あるいはServiceNow単体で完結するデータであれば、わざわざMCP Serverを間に挟んで橋渡しする必要はありません。Snowflake側ならCortex Agentを直接使う、ServiceNow側ならKnowledge Graphの検索機能をそのまま使う方がシンプルです。
逆に、ハードウェアとソフトウェアのように管理主体が異なるデータが常態的に分かれている組織では、横断検索の価値が大きくなります。
判断軸2: 認証・権限管理の複雑さを許容できるか
この構成ではOAuth（外部サービス間でトークンをやり取りして認証する仕組み）による認証設定が複数レイヤーで必要になります。
Snowflake側ではACCOUNTADMINロールでセキュリティインテグレーションを作成し、ServiceNowからのOAuthリダイレクトを受け付ける設定を行います。加えてCortex Agentを呼び出すための実行用ユーザーと権限、ServiceNow側ではMCP Serverのゲートウェイ設定とサブフロー（Flow Designerで作成する再利用可能な処理単位）の構築が必要です。
つまり、単純なAPI連携1本を通すのとは違い、認証チェーンが「Claude Code→ServiceNow MCP Server→ServiceNowサブフロー→Snowflake Cortex Agent」という4段構成になります。この段数を運用チームが管理・監査できる体制かどうかは、事前に確認しておく価値があります。
判断軸3: Semantic View / Knowledge Graphを整備する工数を確保できるか
Cortex Agentが自然言語からSQLを組み立てるには、Semantic View（テーブルの列や関係にビジネス上の意味を付与する定義）が前提になります。
Semantic Viewがないと、Cortex Agentは物理的なテーブル構造にそのまま依存することになり、精度の低い回答になりがちです。同様にServiceNow側でも、Knowledge Graphでテーブル間のエッジ（関連性）を定義しておく作業が必要です。
これらは一度作れば終わりではなく、テーブル構造が変わるたびにメンテナンスが発生します。データモデルの変更頻度が高い環境では、この保守コストを継続的に払えるかを見積もっておく必要があります。
判断軸4: MCPクライアントとして何を使うか
今回の構成ではClaude CodeがMCPクライアントとして使われていますが、MCP対応のクライアントであれば原則として置き換え可能です。
社内でどのAIエージェント基盤を標準にしているか、Claude Code以外のツール（他のMCP対応クライアント）を既に使っているかによって、導入の摩擦が変わります。既存のAIツール運用にMCP対応クライアントが含まれていれば、追加コストは接続設定だけで済みます。
選択肢の比較
| 選択肢 | 向いている状況 | 主なコスト |
|---|---|---|
| ServiceNow MCP Server経由で統合 | ハードウェア・ソフトウェアなどデータが複数基盤に分散し、横断検索の需要が継続的にある | OAuth設定4段、Semantic View/Knowledge Graphの継続保守 |
| Snowflake Cortex Agentのみ利用 | 参照データがSnowflakeに集約されている | Semantic Viewの作成・保守のみ |
| ServiceNow Knowledge Graphのみ利用 | 参照データがServiceNow内で完結する | ナレッジグラフの定義・保守のみ |
| 個別のダッシュボード・レポートで対応 | 質問のパターンが固定的で少数 | ダッシュボード開発・更新の工数 |
ケース別の推奨
資産管理・問い合わせ対応などで、担当者が「このデータはどこにあるか」を都度確認している状態が常態化しているなら、MCP Server経由の統合を検討する価値があります。
一方、参照先がSnowflakeまたはServiceNowのどちらか一方に収まっているなら、それぞれの機能単体（Cortex Agent単体、Knowledge Graph単体）で十分です。無理に両方を連携させる構成にする必要はありません。
質問パターンが月に数件程度で固定的なら、AIエージェント連携よりも既存のレポートやダッシュボードの整備で足りる可能性もあります。導入前に、実際にどれくらいの頻度で横断検索のニーズが発生しているか、ログや問い合わせ履歴から確認してみることをおすすめします。
あえて見送るべき条件
次のような条件に当てはまる場合は、いったん見送るのが妥当です。
- OAuthやセキュリティインテグレーションの設定・監査を担当できるチームがいない
- Semantic ViewやKnowledge Graphを継続的にメンテナンスする体制がない
- テーブル構造の変更が頻繁で、メタデータ定義がすぐ陳腐化する
- 横断検索したいデータ量・頻度がまだ小さく、費用対効果が見えない
特にSemantic ViewとKnowledge Graphの二重メンテナンスは見落とされがちなコストです。片方だけでも継続運用できるか、まず小さく試してから範囲を広げる進め方が現実的です。
まとめ
ServiceNow MCP ServerとSnowflake Cortex Agentの連携は、データが複数基盤に分散していて横断検索の需要が継続的にある組織に向いた構成です。
判断のポイントは、データの分散度合い、OAuth認証チェーンの管理体制、Semantic ViewとKnowledge Graphの保守工数、そしてMCPクライアントの選定という4点に整理できます。
導入を検討するなら、まず自組織の問い合わせ履歴から横断検索の頻度を洗い出し、次にSnowflakeとServiceNowそれぞれの管理者に、OAuth設定とメタデータ定義を継続運用できるかを確認するところから始めてみてください。