Snowflake Summit 2026 最速レポート 1日目
【セッション解説】Snowflake社内事例に学ぶ、Cortex Agentsで実現するクラウドコスト最適化
エージェント「ARGUS」

DATUM STUDIOの唐内です。

現在アメリカ・サンフランシスコで開催中のSnowflake最大の年次イベント「Snowflake Summit 2026」のセッション内容についてご紹介します！

今回ご紹介するセッションは、Snowflake社による「Building AI-Powered Cloud Spend Intelligence on Snowflake」です。Snowflakeが、「自社のクラウドコストをSnowflake上で構築したAIエージェントで最適化した」社内事例で、Cortex Agents・Semantic Views・Snowflake Intelligence・MCPがどう組み合わさるのかが具体的にわかる、非常に学びの多い内容でした。

はじめに：なぜ「クラウドコスト管理」がこれほど難しいのか？

クラウド活用が当たり前になった今、多くの企業が直面しているのがクラウドコストの可視化とガバナンスです。AWS CUR、Azure Billing、Configなどがそれぞれ別の場所に散らばり、「どこに、誰のために、いくら使っているのか」を即答できる組織は多くありません。

このセッションでは、Snowflake自身がまさにこの課題に直面し、Snowflake上でAIエージェント「ARGUS」を構築して解決したという事例が語られました。ベンダー自身が自社で本番運用しているという点で、非常に説得力のある内容です。

課題：急成長するAIデータクラウド企業のコスト

まず提示されたのは、Snowflake自身のクラウド支出のスケール感です。

AWS	約48.6万ドル / 月
Azure	約43.4万ドル / 月
処理すべき請求行	6.11億行
ガバナンス対象	40以上のクラウドアカウント

そのうえで、コスト管理を阻む4つの構造的な問題が挙げられました。

• 1.統一ビューがない（No Unified View）：
  AWS CUR・Azure Billing・Configがサイロ化し、信頼できる単一の真実が存在しない
• 2.オーナーシップの盲点（Ownership Blind Spots）：
  タグなしで起動されたリソースが放置され、担当者が退職してもコストだけが残り続ける
• 3.リアクティブで遅い（Reactive Not Proactive）：
  財務チームが質問しても、回答が出るまで数日かかる
• 4.自然言語で聞けない（No Natural Language）：
  すべての分析にカスタムSQLが必要で、非エンジニアがセルフサービスできない

このあたりは、社内のクラウド検証環境を管理している立場として、強く共感する内容でした。

解決策：Cloud Spend Intelligence のアーキテクチャ

提示された解決策は「Built on Snowflake, by Snowflake（Snowflakeの上に、Snowflake自身が構築）」というメッセージそのものでした。

全体のパイプラインは大きく4段構成です。

1.データソース	AWS / Azure / Okta
2.Snowflake	データ取り込み → Dynamic Tables・Views → Cortex Analyst
3.AI / Intelligence層	Cortex Code（コードネーム「COCO」＝ARGUS本体）と Snowflake Intelligence
4.出力先	AWS、Azure MCP、Slack、Jira、Terraform、Git

請求データをSnowflakeに集約し、Dynamic Tablesで整形、その上にAIエージェントと各種連携ツールを載せる、という構成です。

Semantic Views + Snowflake Intelligence：請求データを”ビジネス言語”に変える層

このセッションの肝のひとつが、Semantic Viewsの活用です。生の請求データを、組織の誰もが理解できる”ビジネス言語”に翻訳する層として位置づけられていました。

Semantic Views側では以下が定義されています。

テーブル&結合	AWS 17テーブル、Azure 28ディメンション。結合はセマンティックビュー内で一度だけ宣言
メジャー	COST_USD、AMORTIZED_COST、SAVINGS、RESOURCE_COUNT といったビジネスで使える指標
ディメンション	SERVICE、BU、OWNER、ACCOUNT、REGION を全社共通の語彙として標準化
検証済みクエリ	50以上の事前承認済みSQLパターンで、正確で一貫した回答を担保

この層の上でSnowflake Intelligenceが動くことで、たとえば「今月事業部別のEC2支出は？」と自然言語で聞くと、「EC2合計14.2万ドル。トップはEngineeringで6.7万ドル（前月比+12%）、次いでSales 3.1万ドル」のように即答を得られます。

さらに「どの事業部の増加が一番大きい？」と重ねて聞くと、「Engineeringが7.2万ドル増。原因はus-west-2で起動された新規GPUインスタンス3台、いずれもdata-scienceチームのタグ」と、根本原因まで掘り下げて返してくれます。裏側は、Semantic Views + Cortex Analyst という構成です。

「一度定義すれば、あとは自然言語で永遠に問い合わせられる（Define once, query in natural language forever）」というメッセージが、セマンティックレイヤーの価値をよく表していました。月並みではありますが、いい仕組みだなと思います。

ARGUS：Cloud FinOps のためのAIエージェント

そしてセッションの主役が、Cortex Agentsをベースに構築されたエージェント「ARGUS」（”All-seeing. All-acting.” ＝全てを見て、全てに動く）です。ARGUSは次の7つのコア機能を持ちます。

1.Cost Requirements	分析の前に対象範囲（スコープ）を設定する
2.Cloud Finance Data	Cortex Analyst 経由でセマンティックビューに問い合わせる
3.Savings Recommendations	無駄を検出し、節約額＋リスクレベル付きで提示する
4.Resource Investigation	AWS 12 + Azure 8 のMCPツールでリソースの”ライブ状態”を確認する
5.Slack Communication	リソースのオーナーにDMし、スレッドやキャンバスで追跡する
6.Action Plan & Execution	承認付きで Terraform PR や MCP書き込みを実行する
7.Jira Tickets	アクションごとにクリーンアップ用チケットを作成・追跡する

「検出 → 通知 → 推奨 → 実行 → チケット化」の一連のフローを1つのエージェントがカバーしているのがポイントです。

ARGUSの仕組みとガードレール

ARGUSは「質問やトリガーから、1つの会話の中でアクションまで到達する」多段推論で動きます。

そして、エージェントを本番で安全に動かすための4つのガードレールが、明確に設計されていました。

1.Grounded in Semantic Views	すべてのSQLはガバナンスされたセマンティックモデルから生成される
2.90-day MCP verification	CloudWatch/Azure Monitorの裏付け（過去90日の実績）なしにクリーンアップを推奨しない
3.Human-in-the-loop	管理者がすべてのアクションを実行前に承認する
4.Full audit trail	すべてのクエリ・アクション・応答をログに記録する

特に「Monitorの実績で90日間アイドルだと確認できなければ、削除を勧めない」「最終的な実行は、必ず人間が承認する」という設計は、エージェントを実運用に乗せるうえで非常に現実的だと感じました。

デモ：質問から実アクションまで一気通貫

デモでは、ARGUSがどのように動くかが順を追って示されました。

まず /argus を起動すると、ARGUSは「AWS+Azure MCP設定済み」「過去の調査履歴」などをメモリから把握したうえで、何を調べたいかを尋ねてきます。ここでユーザーが「Savings opportunities（節約機会）」を選択します。

するとARGUSは「クラウド＝AWS / スコープ＝トップ支出者/種別＝アイドルリソース」とスコープを自分で確定し、Cortex Analystでクエリを実行していきます。途中、CUR データが4/19時点で古いことに気づき、より新しいデイリーサマリーテーブル（5/31時点で最新）に自動的に切り替えるといった、自律的な試行錯誤が見られたのが印象的でした。

最終的に「ARGUS Savings Report（直近30日のアイドルリソース）」が生成されます。AWS総支出は月約26.5万ドル。そのうち、

• ・優先度1：EKS Extended Support — 月12,299ドル（年14.7万ドル）。古いK8sバージョンへの追加課金で、純粋な無駄
• ・優先度2：アイドルRDSインスタンス — 月約9,300ドル（年11.2万ドル）

といった節約候補が、アカウント・インスタンス単位の表で具体的に提示されました。

そして実際のアクションとして、Jiraチケット（[ARGUS] IT-DevのアイドルRDSインスタンス database-1 のクリーンアップ）が「DONE」になっていました。

中身を確認すると、「最終スナップショット作成 → RDSインスタンス削除 → 復旧用にスナップショット保持」が実行済みで、節約見込みは93ドル / 月（1,116ドル / 年）。実行者やCloudTrailとの紐付けまで記録されており、まさに「インサイトからアクションまで」が一気通貫である様子を確認できました。

結果：4ヶ月未満で年間100万ドルの目標を達成

最後の「Key Takeaways & Results」では、ARGUS導入の成果が示されました。

• ・年間100万ドルの節約目標を、4ヶ月未満で達成
• ・現在の節約は年換算で229万ドル（目標の228%）
• ・月間の節約パイプラインは19.1万ドル

そして5つのキーメッセージで締めくくられました。

• 1.Data-First Cloud Cost：コスト課題をSnowflakeという最適なデータ基盤の上で解く
• 2.Semantic Multiplier：一度定義すれば、あとは自然言語で永続的にクエリできる
• 3.Proactive FinOps：Cortex Agentが検出・通知・推奨・実行を担う
• 4.Democratized Insight：英語（自然言語）のQ&Aでガバナンスされた回答を全員に
• 5.Unlocked Attribution：CloudTrail経由で「すべての支出をオーナーに紐付け」

まとめ：エージェントを”安全に動かす”ための設計に学ぶ

このセッションで特に学びになったのは、「Semantic Viewsをエージェントの土台に据える」という設計思想と「MCPによるライブ検証 ＋ 人間の承認 ＋ 監査ログ」という現実的なガードレールの組み合わせです。

AIエージェントは「自律的に何でもやってくれる」というイメージが先行しがちですが、実際に本番のクラウドリソースを操作させるとなると、誤検知や誤操作のリスクをどう抑えるかが、最大の論点になります。

ARGUSは、

• ・SQLは、ガバナンスされたセマンティックモデルからしか生成しない
• ・削除推奨は、Monitorの実績で裏付けが取れたものだけ
• ・実行は、必ず人間が承認
• ・すべてを監査ログに残す

という形で、この論点に真正面から答えていました。

DATUM STUDIOでもSnowflake・Cortex Analyst・dbt・MCP連携を活用したデータ基盤の構築を数多く手がけていますが、「セマンティックレイヤーを整えること」がそのままAIエージェントの精度と安全性に直結する、という点は、今後あらゆる生成AI活用プロジェクトで重要な示唆だと感じました。

クラウドコストの最適化に限らず、社内データを”ビジネス言語”で安全に扱うための一つの完成形として、多くの企業にとってヒントになる事例ではないでしょうか。