G-gen の武井です。当記事では、Google Cloud Next '26 in Las Vegas のセッション「 Secure what's next: AI-driven defense for the enterprise 」について、速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp はじめに AI がサイバーセキュリティにもたらす変革 変化する3つの軸 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 フルスタックの AI インフラと共同開発の優位性 Mandiant の最前線の知見 自律型防御に向けた新機能 human-led から human-on-the-loop へ Triage and Investigation Agent Threat Hunting Agent と Detection Engineering Agent Dark Web Intelligence Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 Morgan Stanley の導入事例 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル クラウドネイティブから AI アプリケーション保護プラットフォームへ 2 つの方向への拡張 包括的なコードセキュリティの全体像 おわりに はじめに 本セッションでは、AI がサイバーセキュリティのあらゆる領域にもたらしている変化と、それに対抗するための 自律型サイバー防御 （Agentic defense）が紹介されました。 Google Cloud の COO 兼セキュリティ製品担当プレジデントである Francis deSouza 氏を中心に、脅威インテリジェンス、自律型セキュリティエージェント、Wiz を活用したクラウドセキュリティ、そして顧客事例まで、幅広い内容が扱われた密度の高いセッションでした。 AI がサイバーセキュリティにもたらす変革 変化する3つの軸 Google Cloud の Sandra Joyce 氏からは、AI が脅威状況（threat landscape）に与えるインパクトが Scale （規模）、 Speed （速度）、 Sophistication （巧妙化）の3つの軸で整理されて紹介されました。 1つ目の Scale について、攻撃者は AI を単なるアドバイザーとして使う段階から、完全に自律したエージェントを投入する段階へと移行しつつあります。これまで SOC は false positive（誤検知）の多さに悩まされてきましたが、今後は 大量の true positive によって捌ききれなくなる SOC へと変わっていくという指摘が印象的でした。 2つ目の Speed については、攻撃者が Gemini をはじめとする大規模言語モデル（以下、LLM）で公開スクリプトを武器化し、アジア・アフリカ・ヨーロッパのメールシステムに対して大規模な悪用を展開している事例が紹介されました。攻撃者はすでに人間の速度ではなくマシンの速度で動いており、防御側も同じ速度で応戦しなければならないというのが Sandra 氏のメッセージです。 3 つ目の Sophistication に関しては、ロシアの軍事情報機関に紐づくサイバースパイグループ APT28 が、オープンソースの LLM をその場で呼び出してコマンドを生成し、静的検知を回避するマルウェアを展開している事例が取り上げられました。また、Mandiant の最新 M-Trends レポートでは、脆弱性の悪用までの平均時間（Mean Time to Exploit）が マイナス 7 日間 であったことが紹介されました。Time to Exploit は「ベンダーが脆弱性を公開した日」または「パッチをリリースした日」を起点（0日）としますので、平均の Time to Exploit がマイナス値であることは、パッチが公開される前に悪用が行われているケースが常態化していることを意味します。 攻撃者側も進化しており、WormGPT や HexStrike AI MCP といったツールを連鎖させることで、セキュリティに詳しくない犯罪組織でも高度なエージェント型攻撃を組み立てられるようになっています。 AI 自体を狙う新たな攻撃と、守るべき領域の拡大 AI 時代には、攻撃の手口だけでなく、守るべき対象そのものも変わります。 プロンプトインジェクション 、 モデル抽出 、 データポイズニング 、 モデル蒸留 といった AI 固有の攻撃が観測されている一方、既存の攻撃も AI で強化されています。例えば、ディープフェイク動画とメールを組み合わせたマルチモーダルフィッシングは、成功率を底上げする典型的な手法として紹介されていました。 同時に、組織が守るべき領域も拡大しています。モデル、エージェント、プロンプト、データパイプラインといった AI インフラ全体 が新たな保護対象となり、加えて従業員が独自に導入した シャドー AI 、サプライチェーン経由で組織に入り込む外部 AI コンポーネントまで、可視化と管理の対象が広がっています。 Google が持つ可視性とフルスタックの AI インフラ 圧倒的な可視性 Francis 氏は、Google がこの脅威状況に対して独自の可視性を持っていると強調していました。 Google は世界で 40 億台以上のデバイスとユーザーを保護しており、VirusTotal には 500 億を超えるファイルが蓄積されています。さらに Google Play 経由で毎日 2,000 億を超えるファイルがスキャンされているそうです。 こうした観測結果は、Google Threat Intelligence が四半期ごとに発行する AI Threat Tracker レポートとしてコミュニティへ公開されています。最新版では、モデル蒸留や AI の敵対的利用の継続的な統合といったテーマに加え、Gemini 以外の非 Google 製ツールに関する知見も含まれています。 参考 : GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use フルスタックの AI インフラと共同開発の優位性 Google はデータセンター間を結ぶ約 200 万マイル（約320万キロメートル）規模の光ファイバー網を自社で運用しており、各レイヤを軍事グレードのセキュリティで保護しています。AI モデル自体の保護についても、 Model Armor や Agent Gateway を通じて、プロンプトインジェクション・ツール汚染・機密データ漏洩を防ぐ取り組みが進んでいます。 Francis 氏が特に強調していたのは、Google がセキュリティ製品を AI インフラと 共同開発 （co-engineering）している点でした。 一般的なセキュリティベンダーは新モデルが公開された当日に初めて中身を理解し始めるため、製品に新モデルを組み込むまで半年から 1 年のタイムラグが生じます。これは AI のタイムラインでは「1〜2 世代遅れ」を意味します。 Google の場合は新モデルのリリース初日から最新機能をセキュリティ製品に取り込めるため、攻撃者と同じ世代の AI で対抗できるという主張です。 Mandiant の最前線の知見 最前線の侵害対応で得られる知見を製品に還元している点も、Google の強みとして繰り返し強調されていました。 現在進行中の重大な侵害事案の多くに Mandiant が関与しており、そこで直面する最も複雑な攻撃手口が、将来の攻撃検知のために Google Cloud のインフラへ組み込まれています。 参考 : Mandiant 自律型防御に向けた新機能 human-led から human-on-the-loop へ Google のアプローチは、従来の「human-led（人間主導）」や「human-in-the-loop（人が都度関与する）」から、「 human-on-the-loop （エージェントが主体で人は監督する）」へと移行しつつあります。エージェント群が重労働を担い、人間はポリシー策定と全体の監督に集中するというモデルです。 Triage and Investigation Agent Google SecOps の自律型セキュリティエージェントである Triage and Investigation Agent が一般提供（GA）となりました。 このエージェントはすでに 500 万件を超えるアラートをトリアージした実績があり、従来は人手で約 30 分かかっていた調査を 60 秒程度で完結 できるとのことです。false positive が増え続ける環境下で迅速な判断が求められる SOC にとって、インパクトの大きい機能といえます。 参考 : Use Triage and Investigation Agent to investigate alerts Threat Hunting Agent と Detection Engineering Agent Triage and Investigation Agent に加え、以下 2 つのエージェントが Preview 公開となりました。いずれも Mandiant の第一線の専門家による検証を経たものです。 # エージェント名 説明 1 Threat Hunting Agent Google の脅威インテリジェンスとベストプラクティスに基づき、環境内の新興脅威を継続的かつ大規模に探索する 2 Detection Engineering Agent 検知カバレッジのギャップを特定し、発見内容に基づいて新たな検知ルールを自動生成・展開する これらの即利用可能なエージェントに加え、カスタムワークフローを構築・ホストするための Google SecOps MCP Server （GA）も提供されています。 Dark Web Intelligence Dark Web Intelligence が Preview 公開となりました。Gemini を基盤としてダークウェブを自律的に探索し、組織のプロファイリングを行ったうえで関連する外部脅威を抽出する機能です。 従来のダークウェブ調査ツールは誤検知が多いことが課題でしたが、Dark Web Intelligence では 98% の精度 で外部脅威を特定できると紹介されました。Forrester の調査によれば、Google のアプローチを採用することで侵害リスクとコストを 17% 削減できるという結果も示されていました。 参考 : Bringing dark web intelligence into the AI era Wiz による開発者起点のクラウドセキュリティ 垂直サイロ型から水平型への転換 ここからは、Wiz の VP of Product Marketing である Jiong Liu 氏のパートです。 クラウドの普及により、多くの企業の開発チームはアイデアを数日から数週間でコードに変え、クラウドへ展開できるようになりました。開発が水平（horizontal）かつアジャイルになった結果、セキュリティにも開発者と同じ速度で動くことが求められています。 しかし、多くのセキュリティ組織は依然として垂直（vertical）にサイロ化されたままです。アプリケーションセキュリティチームはコードスキャナー、DevOps チームはパイプラインスキャナー、クラウドセキュリティチームはランタイム向けツール、SecOps チームはまた別のスタック、といった具合にチーム・ツール・プロセスが分断されています。結果として、サイロごとに大量のアラートが発生し、本当のリスクが見過ごされ、開発とセキュリティの間には摩擦が生じます。 Wiz は、コード・パイプライン・クラウド・ランタイムといったライフサイクル全体のコンテキストを、単一の セキュリティグラフ （Security Graph）に統合します。そこから、悪用されれば事業に重大な損害を与え得るアタックパス（攻撃経路）を特定する、というのが基本的な設計思想です。 アタックパスという形で可視化されると、開発者も「どこを、なぜ、優先して直すべきか」を直感的に理解できるため、セキュリティと開発が同じ土俵でリスクを潰していけるようになります。Jiong 氏は、Wiz の顧客のうち 50% 以上が「クリティカル課題ゼロ」を達成している と紹介していました。 Morgan Stanley の導入事例 続いて、Morgan Stanley の Global CISO である Alonzo Ellis 氏が登壇し、同社のセキュリティモデルの転換について語りました。 同社では従来、アプリケーション・クラウド・オペレーションの各セキュリティが垂直にサイロ化されており、マルチクラウド環境におけるシグナル収集の限界、アラート過多と優先度判断の難しさ、セキュリティとエンジニアリング間の摩擦といった課題が顕在化していたそうです。 Wiz の導入により、クラウドとランタイムのコンテキストが単一のグラフに統合され、個別の指摘ではなく、 完全なアタックパス としてリスクを把握できるようになったといいます。優先順位付けも、単純な深刻度スコアではなく「どれだけ露出しているか」「クラウンジュエル（最重要資産）にどれだけ近いか」で行えるようになりました。 Morgan Stanley からは、具体的な成果として以下のような数字が共有されていました。 Wiz CSPM と Wiz Sensor で、クラウド環境内の 65,000 ワークロード・170 万アセット を保護中。Wiz Code も全社展開を進めている マルチクラウド環境における検知・対処速度が、従来の 約 45 分（手動の対応ワークフロー込み） から、検知はミリ秒単位、対処は 90 秒未満に短縮。MTTD は 99.99% 減、MTTR は 98% 減 Wiz のコンテキストにより、これまで可視化できていなかった 16 件のクリティカルリスクを特定し、ゼロまで低減 買収対象企業のセキュリティアセスメントにかかる期間を、従来の数カ月から 2 週間未満 に短縮 Alonzo 氏は AI 時代のセキュリティについて、「AI を採用するかどうかが課題ではなく、自社のセキュリティモデルが AI の導入速度に追随できるかどうかが課題だ」と述べていました。エージェントによってスケール・速度・自律性が高まるぶん、エージェント型の攻撃も従来より速く進化するため、防御側もマシン速度で動く必要があるという主張です。 AI 時代に向けた Wiz の進化 3 つのエージェントによる水平・エージェント型モデル Alonzo 氏のパートを受けて、Jiong 氏は Wiz 自身の進化について説明しました。「AI 時代にもう一度 Wiz をゼロから作り直すとしても、何も変えないだろう」という発言が印象的で、コンテキストエンジンとして設計された Wiz は、人間のセキュリティチームだけでなく AI エージェントが推論を行う基盤としても最適である、という自信が語られました。 Wiz が提示したのは、「水平かつエージェント型（horizontal, agentic）」のセキュリティアーキテクチャです。中核を担うのは、以下3種類のセキュリティエージェントです。 Red Agent : 環境に対する継続的なペンテスター（ホワイトハッカー）として機能し、アタックサーフェイス（攻撃対象領域）のあらゆる露出ポイントを自律的にプロービングして、リスクが実際に悪用可能かを判定する Blue Agent : 発生中の脅威をリアルタイムに調査する Green Agent : 完全な修復計画を自律的に作成する。リスクを作り込んだ正確なコード行を特定し、修正を開発者または開発者が使うコーディングエージェントに直接プッシュする これにより、検知と同じスピードで修復まで進められるようになります。これまでリスクのトリアージは環境内の最大のボトルネックでしたが、そのボトルネックを取り除くのが狙いです。 クラウドネイティブから AI アプリケーション保護プラットフォームへ Wiz はこのタイミングで、従来のクラウドネイティブなセキュリティプラットフォームから、 AI アプリケーション保護プラットフォーム （AI application protection platform）へと進化したことを発表しました。 コード・クラウド・ランタイムを横断して AI アプリケーションとクラウドアプリケーションを保護するもので、パブリッククラウドだけでなくプライベートクラウドやオンプレミスにも対応します。 2 つの方向への拡張 Google Cloud Next '26 のタイミングで、Wiz は対応範囲を 2 つの方向に拡張することも発表しました。 1 つ目は「あらゆるプラットフォーム、あらゆる AI」への対応拡大です。以下の領域が新たにカバー範囲に加わります。 データプラットフォーム : Databricks、Snowflake エンタープライズ AI 基盤 : Gemini Enterprise Agent Platform、AWS AgentCore、Microsoft Copilot Studio、Salesforce の Agentforce のような SaaS クラウド境界 : Cloudflare、Akamai、Apigee、Vercel からのコンテキスト取り込み 2 つ目は、AI ネイティブな開発ライフサイクルへの入り込みです。コーディングエージェントへの可視性を獲得するだけでなく、従来にはなかった地点にセキュリティを組み込めるようになる、という点が強調されていました。 Prevention （予防） : Wiz hooks や Wiz skills を通じて、コーディングエージェントに「セキュリティの脳」を注入する。開発者がコーディングエージェントにコードを書かせた直後に、Wiz がそのコードとデプロイ内容を評価し、組織のポリシーに沿って修正までかける。開発者が翌朝 PC の前に座ったときには、すでにセキュアなコードが仕上がっている状態を目指す。 Backlog Burn-down （既存バックログの消化） : 事前構築済みの Wiz セキュリティスキルを IDE に直接取り込み、Green Agent の洞察をもとにコードベースの自己修復（self-healing）を進める。 包括的なコードセキュリティの全体像 Francis 氏は、Wiz・Google SecOps・Mandiant・ CodeMender を組み合わせた包括的なコードセキュリティの構想を次のように整理していました。 Wiz : 環境のマッピングとクリティカルリスクの修正 CodeMender : AI ベースでコードベースをスキャンし、コードレベルで修正を実行 Mandiant : 脆弱性対応の成熟度（vulnerability readiness）を高める知見の提供 Google SecOps : 継続的な検証と保護 Google Threat Intelligence がこれら全体を下支え Wiz でコードセキュリティ戦略を立て、CodeMender・Wiz・Mandiant で環境内の脆弱性を特定・優先度付けし、修復ワークフローを起動する。さらに Mandiant で継続的な要件の評価を行い、Google SecOps で監視を続ける、というフルスタックの構成です。 おわりに 本セッションを通じて繰り返し語られていたのは、 AI vs AI の時代において、防御側にも同じ世代の AI と、マシン速度で動くエージェント群が必要 、というメッセージでした。 Google の強みは、脅威状況に対する圧倒的な可視性、AI インフラとセキュリティ製品の共同開発、そして Mandiant の最前線の知見を Google Unified Security として集約している点にあります。 そこへ Wiz が加わったことで、開発者起点のクラウドセキュリティから SOC の自律運用、さらにはコードレベルの自動修復までを一気通貫で扱えるプラットフォームへと進化しつつある、というのが今回の発表全体から伝わる方向性でした。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

こんにちは。SCSKの磯野です。 Google Cloud Next ’26 in Las Vegas Day1の基調講演が終わったので、内容をざっと整理してみました。 普段はMicrosoft（Fabric / Foundry）とGoogle Cloudの両方を触っている立場なので、「これってMicrosoftだとどういう位置づけ？」という観点で見た内容をまとめています。 1日目の基調講演「Opening keynote: The agentic cloud」 の速報的なまとめですが、GoogleとMicrosoftにおけるAI×データ基盤の比較をしながら考察していきます。 なお、本記事では基調講演の内容を網羅的にまとめるのではなく、特に気になったトピックに絞って抜粋しています。また、Day1終了直後の速報ベースの内容のため、今後のアップデートにより解釈が変わる可能性があります。   Welcome to Google Cloud Next26 | Google Cloud Blog At Google Cloud Next '26, explore the Agentic Enterprise. Learn about our unified AI stack for building, scaling, and op... cloud.google.com Gemini Enterprise Agent Platform の登場 Gemini Enterprise Agent Platformとは、AIエージェントの構築、スケーリング、ガバナンス、最適化を行うための包括的なプラットフォームです。これは 従来のVertex AIを進化させたもの であり、モデルの選択や構築機能に加えて、エージェントの統合、DevOps、オーケストレーション、セキュリティなどの新機能が統合されています。 Model Gardenを通じて、Gemini 3.1 Pro、Gemini 3.1 Flash Image、Lyria 3などのGoogleの最新モデルや、AnthropicのClaude Opusといった200以上の主要なサードパーティモデルにアクセスできるのが特徴。 Anthropic社のClaude Opus 4.7のサポートも追加されました。 Introducing Gemini Enterprise Agent Platform | Google Cloud Blog Gemini Enterprise Agent Platform is our new platform to build, scale, govern, and optimize agents. It integrates the mod... cloud.google.com   Gemini Enterprise app の登場 Gemini Enterprise app は、すべての従業員があらゆるワークフローにおいてAIを利用できるようにするための「AIへのフロントドア（入り口）」として機能するアプリケーションです。AIを単なる個人の生産性向上ツールから、ビジネスのための安全で協調的、かつ自律的なエンジンへと進化させ、チームがAIエージェントを発見、作成、共有、実行できる単一の環境を提供します。 以下、気になった機能だけ抜粋しました Projects（プロジェクト） プロジェクト機能を使うと、エージェントの記憶領域はチームが追加したファイルや会話に限定されます。GoogleドライブやNotebookLMなどと連携することで、特定テーマに特化した知識を持ち、日々の要点共有 / 状況サマリーを効率的に提供できます。 Canvas Gemini Enterpriseに直接組み込まれたインタラクティブエディター。チームでドキュメントやスライドを単一の画面で作成・編集できます。さらに、 Microsoft 365との相互運用性も追加され、Canvasで作成したドキュメントやスライドを一般的なMicrosoft Office形式にエクスポートできるようになりました。 クロスプラットフォーム対応の統合インテリジェンス Gemini Enterpriseは、断片化されたデータ環境全体にわたって統合インテリジェンスを提供します。データがGoogle Workspace、 Microsoft 365 、その他のビジネスアプリケーションに存在していても、Gemini Enterpriseはネイティブのアクセス許可を厳密に尊重するため、企業のガバナンスやユーザーアクセス制御を損なうことなく、チームが強力なインサイトを得ることができます。 Gemini Enterprise（旧Agentspace）は、Gemini Enterprise Agent PlatformとGemini Enterprise appで構成されるエージェント時代のエンドツーエンドシステムとなりました。 What’s new in Gemini Enterprise | Google Cloud Blog cloud.google.com Gemini Enterprise と M365 Copilotの比較 Gemini Enterpriseは、その役割としてM365 Copilot（Workタブ）に近いプロダクトと捉えることができます。 Gemini EnterpriseはGoogle Workspaceに加え、Microsoft 365ともコネクタで接続できるのが特徴です。一方で、M365 CopilotもGoogle Driveとの連携が可能です。 Gemini Enterprise（Google Workspace / M365連携）と、M365 Copilot（ネイティブ / Google Drive連携）の4パターンについて、連携レベルの観点で比較を行いました。 連携レベル サービス例 読むだけ・操作不可 ※ RAG（ナレッジ検索） CopilotのGoogle Drive連携 ・インデックスして検索 ・要約・引用 読む+少し操作できる Gemini Enterprise（M365連携） ・リアルタイムにデータ参照 ・メール送信やチャット投稿など一部アクション可能 ・SaaS横断で使える フル操作可能 Microsoft Graph統合（Copilot本体） ・メール・会議・Teams・ファイルの理解・操作 ・人・会話・履歴・関係性まで把握          Gemini Enterprise（Google Workspace） ・ メール・ファイル・予定を横断して推論 →どちらも機能としては似たようなことが実現可能。 Copilot（Microsoft Graph）では、人/会話/会議/ファイル/タスク 等、全部が1つのデータモデルに統合されており、関係性が“構造として”存在する。 Gemini Enterpriseにて、Microsoft Graph ネイティブのような全体一体感があるかは未確認。   Agentic Data Cloudの登場 Agentic Data Cloud とは、従来の人間のスケールに合わせて構築された静的なデータリポジトリ（システム・オブ・インテリジェンス）を、エージェントのスケールに合わせて最適化された動的な推論エンジン（システム・オブ・アクション）へと進化させた、AIネイティブな新しいデータアーキテクチャです。思考と行動のギャップを埋め、AIエージェントが企業のビジネスデータやコンテキストを正確に把握し、自律的に行動するための基盤となります。 Apache Icebergを標準とするCross-Cloud Lakehouseは 、AWSまたはAzure（今年後半に提供開始予定）にデータを保存したまま、ベンダーロックインの煩わしさやデータ移行コストをかけずに、瞬時にクエリを実行できるレイクハウスです。Databricks、Palantir、Salesforce Data360、SAP、ServiceNow、Snowflake、Workdayなど、アプリケーション、オペレーティングシステム、AIプラットフォームへのコピー不要のアクセスを提供します。 Microsoftの世界だと…？ → MS Fabricのショートカット に近い考え方 Data Agent Kit拡張機能 (プレビュー)は、 データエンジニアなどの実践者向けに提供されるツールキットです。 VS Codeなどの使い慣れた開発環境に直接組み込むことができ 、「顧客の解約を予測したい」といった自然言語の意図を伝えるだけで、自律的にデータパイプラインを構築しモデルをデプロイします。 Agentic Defenseとは 、AIのライフサイクル全体を保護し、組織が「マシンスピード（機械の速度）」で脅威に対処できるようにする自律型のサイバーセキュリティプラットフォームです。 Googleの脅威インテリジェンスおよびセキュリティオペレーション（SecOps） と、 Wiz社のクラウドおよびAIセキュリティプラットフォーム を統合し、コードからクラウド、ランタイムに至るまで、ハイブリッド環境やマルチクラウド環境の脅威の予防・検出・対応を自律的に行います 高精度のハイブリッド検索: Google検索の高度なクエリ書き換えや機械学習技術を応用し、セマンティック検索と語彙（字句）マッチング、インテリジェントな再ランキングを組み合わせて、エージェントのプロンプトに対し最適なコンテキストをリアルタイムで提示します。 アクセス制御を認識した検索（Access control-aware search）: 各ソースシステムで定義されたアクセス権限（IAMポリシーなど）を厳格に遵守します。これにより、エージェントは自身にアクセスが許可されたデータのみを取得・実行でき、情報漏洩を防ぎます。 測定可能なコンテキスト評価: 提供されるコンテキストの関連性や品質を定量的にテストし、継続的に最適化するための評価フレームワークが備わっています。 Knowledge Catalog は、 ユニバーサルコンテキストエンジン です。技術者向けに手動で構築されていた 従来のデータカタログ（Dataplex）から進化 し、AIエージェントのハルシネーション（幻覚）や遅延を防ぐために、データ資産やビジネスのコンテキスト（文脈）を動的かつ常時提供する基盤として機能します。仕組みは以下の通り。 1. 統合（Aggregation）：データ環境全体にわたるコンテキストの一元化 エージェントが正確なコンテキスト（文脈）を理解できるよう、あらゆる場所に散在するデータと定義を一つにまとめ、矛盾を解消する仕組みです。      広範なメタデータの統合: BigQuery、AlloyDB、Spanner、LookerといったGoogle Cloudのシステムだけでなく、AtlanやCollibraなどのサードパーティ製カタログからも技術的なメタデータを自動で収集します。 エンタープライズ接続: Google Cloud Lakehouseを活用し、 Palantir 、 SAP、Salesforce Data360、Workday、ServiceNowといった外部のビジネスアプリケーションやAIプラットフォームのデータにも直接接続し、一元的な可視性を確保します。 ビジネスロジックの統一: 戦略ドキュメントを読み込んで自動でセマンティクスを生成する「LookML Agent」や、SQLエンジンにビジネスロジックを直接埋め込む「BigQuery measures」により、組織全体で統一された定義を適用します。 2. 継続的な強化（Continuous Enrichment）：継続的な学習による意味づけ 手動でのデータ整理に頼らず、バックグラウンドでデータのプロファイリングや使用状況ログの分析を行い、常にデータを最新で意味のある状態に保つ仕組みです。 Smart Storageによる非構造化データの処理: Google Cloud Storageにファイル（画像やPDFなど）が保存された瞬間に、自動でタグ付けとメタデータのエンリッチメントを行います。 Geminiによるマルチモーダル抽出: Geminiと統合されており、非構造化データから有用なビジネス情報を特定してエンティティを抽出し、複雑な関係性を自動でマッピングします（欠落しているスキーマの自動生成なども行います）。 自動化されたコンテキストのキュレーション: データセットや関係性に関する自然言語の記述、ビジネス用語集を自動生成します。さらに、エージェントのハルシネーションや誤ったSQL結合を防ぐため、検証済みのSQLパターンなども提供します。 3. 検索と取得（Search and Retrieval）：高精度かつ安全な情報の引き出し 自律型エージェントが推論を行う際に、膨大なデータの中から必要なコンテキストをリアルタイムかつ低遅延で、セキュリティを保ちながら抽出する仕組みです。 エンタープライズインサイト向け Deep Research Agentは、 前述のKnowledge Catalogと連携した自律型エージェントです。Gemini EnterpriseのDeep Researchは、既に社内ドキュメントやウェブ検索、SaaSシステムと連携してビジネスデータを統合していますが、 今回BigQueryなどのデータプラットフォームにも接続し、構造化データと非構造化データの両方を網羅的に把握できるようになりました。 これにより、「サプライチェーンの混乱の根本原因は何ですか？」や「この地域の財務監査を実施できますか？」といった複雑なビジネス上の疑問にも答えることができ、従来は数週間の手作業が必要だった引用や精度の高い分析結果も提供できるようになります。 What’s New in the Agentic Data Cloud | Google Cloud Blog Build your agentic enterprise on Google Cloud with a System of Action designed for scale, security, and cross-cloud inte... cloud.google.com Deep Research Agentと Microsoft IQシリーズの比較 「サプライチェーンの混乱の根本原因は何ですか？」のような問いに対して、構造化・非構造化データを組み合わせて根拠付きで回答するユースケースは、Deep Research Agentだけでなく、Foundry IQ×Fabric IQでも実現可能です。 そのうえで、Microsoftはオントロジーを扱える点に強みがあります。 Fabric IQでは、ontologyによって業務概念（business concepts）を定義し、データやエージェントがその意味に基づいて回答します。これにより、「部品遅延」「在庫逼迫」「輸送停止」「仕入先変更」といった関係性を企業共通のモデルとして固定し、一貫性のある回答が可能になります。 一方で、GoogleのDeep Research Agentは、すぐに使える点で強みがあります。複数のデータソースを横断して調査し、アドホック的に根拠付きのレポートを生成する用途に適しています。 使い分けとしては以下のようなイメージです。 横断的に調査してレポートを得たい場合は Google（Deep Research Agent） 業務用語や因果関係を定義し、安定して回答させたい場合は Microsoft（Foundry IQ × Fabric IQ）   まとめ 今回の発表から、GoogleとMicrosoftはいずれも「AIエージェントを前提としたデータ基盤」へと進化していることが分かりました。 中でもGoogleは、 エージェント開発基盤 としての強みを感じました。 Gemini Enterprise Agent Platform + Gemini Enterprise app + Agentic Data Cloud をひとつの統合スタックとして提示し、「エージェントを作る・つなぐ・運用する」ための基盤として打ち出されていました。 一方 Microsoft は、Work IQ / Foundry IQ / Fabric IQ  を通じて、業務におけるコンテキスト（文脈）と業務意味（セマンティック）を共有レイヤーとして整備する方向が強みです。特にFabric IQ は オントロジーで関係性・ルール・意味を固定することが可能です。 Google は「エージェントを作る・つなぐ・動かす」側が強く、Microsoft は「意味を定義し、安定して答えさせる」側が強い と言えそうです。 実務的には、 横断探索やマルチクラウドなエージェント開発は Google、業務語彙を統治しながら定着運用するなら Microsoft 、という使い分けをするのがよさそうです。

本記事は 春のスキルアップ応援フェア2026 4/24付の記事です 。 こんにちは、ひるたんぬです。 最近料理にハマっており、仕事終わりは可能な限り自分で料理を作ろうと心がけています。 そんな私はWebサイトに数多あるレシピのお世話になっているのですが、材料欄によく「少々」「ひとつまみ」といった記載を見かけます。これら二つを使い分けているレシピもあり、分量に差はあるのか気になったので調べました。 【少々のはかり方】親指と人差し指の2本で軽くつまむ。 【ひとつまみのはかり方】親指、人差し指、中指の3本の指で軽くつまむ。 引用：デリッシュキッチン「 料理の基本！少々・ひとつまみのはかり方 」 明確な違いがあったのですね。。。今まで「どっちも同じだろう」と思い投入していたので改めようと思います。 さて、今回は「春のスキルアップ応援フェア」ということでしたので、普段はAWSを中心に触っておりSnowflakeミリしらな私が、SnowflakeのCortex AIを活用して非構造化データの画像を検索できるようになるまでの道のりを記したものです。 長めの投稿となりますが、飛ばしながらでも最後まで温かく見守っていただけますと幸いです。 きっかけ 先日、社内勉強会にてSnowflakeについて知る機会がありました。 その中ではデータ活用の重要性を起点にSnowflakeの概要から強み、実際の導入事例までを座学で学んだほか、実際にSnowflakeの社員様にご登壇いただきサービスのデモを見せていただきました。 それまでは、「Snowflakeってデータ分析や活用ができる、なんかすごいツールが集まったもの」程度の認識だったのですが、デモの中で、 「画像のような非構造化データまで分析ができる」 ことを聞いたときに、これはすごい…！と思い、試すまでに至りました。 なお、その中でご紹介いただいたブログ記事はこちらです。 Snowflake で画像(非構造化データ)を AI で処理して検索できるようにしてみる zenn.dev また、上記ブログで紹介されている元の記事も参考にさせていただきました。 SQLだけで画像分類！SnowflakeのAI_CLASSIFY関数を試してみた zenn.dev 本記事でも、上記ブログ記事に沿って実際に手を動かしました。 Snowflake Cortex AIとは？ 公式サイトの文章が簡潔で分かりやすかったので、引用させていただきます。 データの存在する場所でAIを活用して、 会話、ドキュメント、画像をインテリジェントなインサイトに変換 できます。業界をリードするLLMにSQLで直接、またはAPIを介して大規模にアクセスし、マルチモーダルデータの分析と エージェントの構築 を、すべて Snowflakeのセキュアな境界内で実行 できます。  引用：Snowflake「 Cortex AI 」 ポイントとしては、以下が挙げられます。 会話、ドキュメント、画像をインテリジェントなインサイトに変換 → 非構造化データの中でも、そもそも文字データですらない画像からも情報抽出が可能 → 構造化データ・非構造化データを一箇所に集約可能 Snowflakeのセキュアな境界内で実行 → 大切なデータも安全に処理ができる 画像データを分類してみよう！ 下準備 今回私は初めてSnowflakeを触るので、アカウント開設から始めました。 Snowflakeでは30日間（もしくは$400到達のどちらか早い方）の無料お試しが利用できるので、今回は学習目的でこちらを使わせていただきました。 アカウント開設は、メールアドレスなどの必要事項を数点入力するのみで完了し、ものの5分程度でアカウントが発行されました。 また、参照元のブログ記事では車載カメラで撮影されたデータセットを用いておりましたが、折角なので違うデータセットで試すこととします。今回は飛行機の画像が含まれているデータセット¹を用意し利用しました。 ¹ Kaggle「 Commercial Aircraft Dataset 」 学習目的で任意のデータセットを利用する場合、権利関係にご注意ください。 今回のデータセットは「CC0」であり、クレジットを表記することなく利用が可能です。 参考：Creative Commons「 CC0 」 データ格納 Snowflakeでは「ステージ」という概念があります。これは、簡単に言えばデータを格納する場所です。 ステージ上にデータを保管し、Snowflakeテーブルとデータのやり取りをする、中継地点という考え方もできます。 ステージは、Snowflake Stageという「内部ステージ」と、パブリッククラウド（Amazon S3・Google Cloud Storage・Azure Blob Storage）上の「外部ステージ」に分けることができます。 更にこの「内部ステージ」は以下の3つに分類することができます。 ユーザーステージ【Snowflake管理ステージ】 → 各ユーザーにデフォルトで割り当てられているステージ。ファイルに対するアクセスが一人（＝そのユーザー自身）である場合に選択。 テーブルステージ【Snowflake管理ステージ】 → 各テーブルごとに自動で作成されるステージ。ファイルに対するアクセスが一つのテーブルである場合に選択。 名前付きステージ → 上記の制約が存在しないステージ。自由に作成が可能。外部ステージはここに位置する。 Snowflake上のドキュメントには、上記内部ステージの選択方針として以下のように述べられていました。 自分だけがロードするデータファイル、または単一のテーブルにのみロードするデータファイルをステージする場合は、ユーザーステージまたはデータをロードするテーブルのステージのいずれかを使用することをお勧めします。 名前付きステージはオプションですが、複数のユーザーやテーブルが関係する可能性のある通常のデータロードを計画する場合は、使用を 推奨 します。 引用：Snowflake Documentation「 ローカルファイルに対する内部ステージの選択 」 ステージの取り扱いについてはなんとなく理解することができました。 今回の処理は、ユーザーステージやテーブルステージで実施することはできません。必ず名前付きステージを作成して作業を行ってください。 参考：Snowflake Documentation「 AI_CLASSIFY – Limitations 」「 AI_FILTER – Limitations 」 ステージの作成 ここからは実際にSnowflake上のリソースを操作していきます。 SnowflakeはコンソールのGUIでも操作はできますが、SQLでもできるため、今回はできる限りSQLを使って作業していきたいと思います。 SQLのコマンド実行環境はSnowflake上のWorkSpaceを使用します。 まず、Snowflake内部に名前付きステージを作成します。 ステージ名は「AIRCRAFT_IMAGE_STAGE」としました。 なお、このタイミングでデータベースも併せて作成します。 CREATE DATABASE AIRCRAFT_DB; CREATE OR REPLACE STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE'); ステージの作成時には、暗号化オプションを忘れずにつけるようにしてください。 デフォルトのクライアントサイドでの暗号化では、後述するAI_CLASSIFY、AI_FILTERなどの処理を行うことができません。 実際に作成できたかも確認します。 SHOW DATABASES STARTS WITH 'AIRCRAFT_DB'; SHOW STAGES STARTS WITH 'AIRCRAFT_IMAGE_STAGE'; それぞれ作成されていることが確認できました。 画像のアップロード 取得した画像を先程作成したステージに格納します。 WorkSpace上にImagesフォルダを作成、フォルダ内に画像ファイルを準備し、ステージにアップロードします。 ファイルのアップロードを一度に行うとフリーズしてしまったので、数回に分けて行いました。 私の環境では1,000枚程度であれば一度に作業できました。 ちょっと動作を確かめたい場合は、全部アップロードしなくても良かったですね…後述しますが、 すべての画像のアップロードは、おすすめしません。 今回はWorkSpaceで作業してみたかったため、画像をWorkSpaceにアップロードする必要がありましたが、Snowflake CLIを利用することで、ローカル環境から直接ステージにファイルを転送することも可能です。 ローカルファイルシステムからのデータファイルのステージング | Snowflake Documentation docs.snowflake.com WorkSpaceへのアップロードには、ブログ記事を参考に以下のコマンドを用いました。 PUT file:///snow://workspace/USER$.PUBLIC.DEFAULT$/versions/head/Images/*.jpg @AIRCRAFT_IMAGE_STAGE; しかし、上記コマンドで試したところ以下のようなエラーが表示されました。 Unsupported feature ‘unsupported_requested_format:snowflake’. ここでコンソール上には「💠Fix」の文字が。。これをクリックすると、Cortex Codeによる問題解決が始まりました。 Cortex Codeによると、 Replaced   PUT   with   COPY FILES INTO .   The   PUT   command   isn’t   supported   in   Snowsight   —   COPY FILES INTO   is   the   workspace-compatible   way   to   upload   files   from   a   workspace   to   a   stage.   Also   changed   versions/head   to   versions/live   (the   correct   workspace   path). とあり、PUTコマンドは SnowSight ²ではサポートされていない、代わりにCOPY FILES INTOコマンドを使うように案内されていました。 今回はこちらに従い修正を受け入れると、問題なく実行できるようになりました。 ² SnowSightとは、PythonやSQLでSnowflake上のデータを操作するWebインターフェースのことです。 修正後のコードはこちらです。 COPY FILES INTO @AIRCRAFT_IMAGE_STAGE FROM 'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Images/' PATTERN = '.*\.jpg'; なお、PUTコマンドが使えないことについては、公式ドキュメントにも記載がありました。 コマンドは、いずれのSnowflakeウェブインターフェイスの  Worksheets ページからも実行できません。 引用：Snowflake Documentation「 PUT – 使用上の注意 」 また、今回はWorkSpaceで作業してみたかったため、画像をWorkSpaceにアップロードする必要がありましたが、Snowflake CLIを利用することで、ローカル環境から直接内部ステージにファイルを転送することも可能です。 ローカルファイルシステムからのデータファイルのステージング | Snowflake Documentation docs.snowflake.com 外部ステージへのファイル転送は、それぞれのサービスで用意されているコマンドやコンソールを使用します。 一通りのアップロードを終えたら、無事にファイルが格納されていることを確認します。 SELECT * FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); しかし、ここでもエラー… DIRECTORY not enabled for the stage AIRCRAFT_IMAGE_STAGE 日本語約すると、作成したステージでは、DIRECTORYが有効化されていないとのことでした。そもそもこの「DIRECTORY」というものがどういうものか分からなかったので、その理解から始めます。 ディレクトリテーブルは、ステージで複数層になった暗黙のオブジェクトで（独立したデータベースオブジェクトではない）、 ステージ内のデータファイルに関するファイルレベルのメタデータを格納する ため、概念的には外部テーブルに似ています。 引用：Snowflake Documentation「 ディレクトリテーブル 」 ステージ内に格納したファイルのメタデータを格納するテーブル、と理解しました。 ディレクトリテーブルはステージの作成時に作ることもできますが、今回は既にステージを作っていたので、ステージのプロパティ変更コマンド（ALTER STAGE）を使用します。 ディレクトリ作成後は、メタデータ更新のため、手動でリフレッシュコマンドを実行します。 ALTER STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE SET DIRECTORY = (ENABLE = TRUE); ALTER STAGE AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE REFRESH; 上記が完了したら、改めて確認をします。 SELECT * FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); 無事にアップロードできていることを確認できました！ 上記の解決にもCortex Codeの力をお借りしました。 画像分類項目の検討 いよいよここからはCortex AIを用いた画像分析に入ります。 今回はブログでも紹介されていた関数のうち、AI_FILTER関数とAI_CLASSIFY関数を使います。 AI_FILTER関数   ランディングギアは出ているか ※ 車輪のことです。 四発ジェット機か ※ ジャンボジェットのようにエンジンが4発の航空機のことです。 着陸しているか 日本航空（JAL）、もしくは全日本空輸（ANA）の航空機か AI_CLASSIFY関数 各画像の天候のラベル付け 晴れ 曇り 雨 航空機が所属するアライアンスのラベル付け Oneworld Star Alliance SkyTeam 所属なし 紹介されていたブログの項目を参考に王道からチャレンジングな項目まで設定しました。ブログ記事ではAI_CLASSIFY関数でトヨタ車の検出ができていたようだったので、AI_FILTER関数で同じようなことができるか検証します。また、そこから少し踏み込み、航空会社を判別したうえで、その航空会社が所属するアライアンスを分類できるかを試します。 いよいよ実践！ すべての準備が整ったので、実際に分類をしていきます。 実践①：AI_FILTER AI_FILTER関数は、自然言語によるプロンプト入力の結果をブール値で返す関数です。テキストはもちろんですが、今回実験するような画像に対する処理も対応しています。 AI_CLASSIFY | Snowflake Documentation docs.snowflake.com ランディングギアの判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、ランディングギアは出ていますか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS SHOW_LANDINGGEAR FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは6,070枚でした。いくつかピックアップしてみます。 様々な角度の画像がありますが、どれもランディングギアが出ていることが分かります。 逆に、FALSE（ランディングギアが出ていない）と判別された結果も、いくつかピックアップしてみます。 こちらもランディングギアが出ていないものが多かったです。 ただ、一部（上図右下）ではちょうどしまっているところなども、FALSEと検出されていました。判断に迷うところですね。。 四発ジェット機の判別 SQL文は自然言語での指示部分、及び結果を整理するインデックス名以外は変更がありません。 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、四発ジェット機ですか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_QUADJET FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは679枚でした。いくつかピックアップしてみます。 こちらもどれも四発ジェット機ですね。上図右下のANAは画像全体がかなり霞んでいますが、正しく判別できています。 着陸しているかの判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、着陸していますか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_LANDING FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは681枚でした。いくつかピックアップしてみます。 どの航空機も着陸した状態です。 JALまたはANAの航空機の判別 SELECT RELATIVE_PATH AS FILE_NAME, AI_FILTER( 'この画像の航空機は、JALもしくはANAの航空機ですか？', TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH) ) AS IS_JAL_ANA FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); TRUEと判別されたのは84枚でした。いくつかピックアップしてみます。 しっかり分類されていましたね！ Oneworld塗装やStar Alliance塗装の機体まで分類できている点、JAL Expressという、かつて存在したJALグループの便まで検出できている点は驚きでした。 JALのロゴ、懐かしいですね。。 実践②：AI_CLASSIFY AI_CLASSIFY関数は、指定されたカテゴリに分類をする関数です。こちらの関数もテキスト・画像両方に対応しています。 AI_CLASSIFY | Snowflake Documentation docs.snowflake.com 天候のラベル付け SELECT RELATIVE_PATH AS FILE_NAME, AI_CLASSIFY( TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH), ['晴れ', '曇り', '雨'] ):labels[0]::STRING AS WEATHER_CATEGORY FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); 晴れが5,013枚、曇りが1,491枚、雨が33枚でした。 ▼ 晴れ ▼ 曇り ▼ 雨 AI_FILTERと異なり、はい・いいえの二択で判断できないので中々評価が難しいところではありますが、明らかに間違えている、と言えるものは無さそうでした。 「曇り」画像の左下は人間だと「晴れ」と答えそうですが、気象庁における天候の定義に基づくと誤りでは無さそうです。すごいなぁ…と感心してしまいました。 雲量が0から1のときは「快晴」、2から8のときは「晴れ」、9から10のときは「くもり」としています。 引用：気象庁 はれるんライブラリー「 雲の量と天気の「快晴」「晴れ」「くもり」の関係は？ 」 アライアンスのラベル付け いよいよ、難関と思われる問題です。 SQL文はラベルカテゴリとインデックス名が変わる程度で、大きな違いはありません。 SELECT RELATIVE_PATH AS FILE_NAME, AI_CLASSIFY( TO_FILE('@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE', RELATIVE_PATH), ['Oneworld', 'Star Alliance', 'SkyTeam', '所属なし'] ):labels[0]::STRING AS ALLIANCE_CATEGORY FROM DIRECTORY(@AIRCRAFT_DB.PUBLIC.AIRCRAFT_IMAGE_STAGE); Oneworldが507枚、Star Allianceが1,218枚、SkyTeamが659枚、所属なしが4,153枚でした。 ▼ Oneworld マレーシア航空：○ イベリア航空：○ （旧）メキシカーナ航空：○ ※ （旧）メキシカーナ航空は運行停止 日本航空：○ フィンエアー：○ アメリカン・イーグル（アメリカン航空グループ）：○ ※ アメリカン・イーグルはアフィリエイトメンバーです。 ▼ Star Alliance ルフトハンザドイツ航空：○ ユナイテッド・エクスプレス（ユナイテッド航空グループ）：○ ※ ユナイテッド・エクスプレスはアフィリエイトメンバーです。 オーストリア航空：○ LOTポーランド航空：○ 全日本空輸：○ TAPポルトガル航空：○ ▼ SkyTeam デルタ航空：○ KLMオランダ航空：○ エールフランス：○ デルタ・コネクション（デルタ航空グループ）：○ ※ デルタ・コネクションはアフィリエイトメンバーです。 中国東方航空：○ アルゼンチン航空：○ …という訳で、なんと抽出したものはすべて合っていました。。びっくりです。単純に航空会社を認識するだけでなく、その先のアライアンスまで認識して分類できる能力はありそうですね。 結果の整理 それぞれのSQL文の実行結果は画面上にテーブル形式で出力されるほか、CSV形式でのダウンロードも可能です。 これでももちろんいいのですが、データ活用という観点からすると、これらの結果をSnowflake上で活用できる形で管理したいと思います。この場合には、テーブルを用意して結果を保存します。 しかし、私はSQL文の中にTABLEの作成を入れ忘れていました… 再実行、、、が頭によぎりましたが、ここで朗報です。 Snowflakeではクエリの実行結果が24時間保存されます。 RESULT_SCAN | Snowflake Documentation docs.snowflake.com まさに、今の私のためだけに作られたような機能…！早速この「RESULT_SCAN」を使ってテーブルを作成していきます。 ここで必要になるのが、クエリ実行結果のIDです。 これもSQLで検索することが可能ですが、今回はWorkSpace上ですぐ特定できたため、そちらの方法を採用しました。 実際のSQL文も併せて表示されるため、迷うことは無さそうです。 これを使ってテーブル作成のSQL文を作成し、実行します。 CREATE OR REPLACE TABLE AIRCRAFT_DB.PUBLIC.RESULT_LANDINGGEAR AS SELECT * FROM TABLE(RESULT_SCAN('00c11e3b-1234-8aba-5678-231a00012345')); これをクエリの数繰り返し、計6つのテーブルを作成することができました。 最終的にこれを一つのテーブルにまとめます。 今回はこの方法をCortex Codeに聞いてお願いしました。 抽象的な表現かつ日本語ですが、うまく動いてくれるのでしょうか… Cortex Codeは、今までのSQLの中身を確認したあと、それぞれの結果のテーブルを確認し、SQL文を生成してくれました。 生成内容を確認するに、きちんと指定名でのテーブルを作成し、その中にすべての結果をLEFT JOIN関数を用いて結合させていることがわかります。 問題はなさそうだったので、この結果を受け入れます。 するとCortex Codeではコードの実行と検証が実施され、問題ない旨回答をもらいました。検証まで一連の流れで行ってくれるのはありがたいですね。 最終的な回答文も日本語でした。 おまけ：分類に失敗したと思われる画像 さて、ここまででこの機能のすごさは少しでも感じていただけたでしょうか？ 一方、AIに絶対はない、と言われているのが今日です。ここでも実際の分類結果から、あり得ないシチュエーションを設定し、そこに分類された画像を見てみようと思います。 パターン①：JAL or ANA × SkyTeam 上記の結果にもありますが、JALはOneworld、ANAはStar Allianceなので、このパターンの結果は存在し得ないはずです。しかし、この結果を示すものが一件だけありました。 ロゴを見ればJALと一目で分かりますが、尾翼の緑色が特殊ですね。これにより結果が揺らいでしまったのでしょうか… パターン②：ランディングギアが出ていない × 着陸状態 飛行機では着陸時にランディングギアを出します。 上記の状態は通常の着陸では起こらないはずですので、このパターンは存在し得ないはずです。しかし、この結果を示すものが35件ありました。 実際の画像をすべて確認すると、すべて着陸状態で、かつランディングギアは出ている状態でした。 つまり、ランディングギアの判別が誤っているということになります。 一方、正常に判別できている結果と比べると、ランディングギアが主翼や影で隠れて見えない（見えにくい）画像が多い…？と感じました。この点を表現としてプロンプトに加えることで、精度改善につながるのでは、と考えています。 PROMPT | Snowflake Documentation docs.snowflake.com この改善に挑戦しようとしたところで、一通のメールが… 6,000枚の画像を無計画に分析したからですね。。2日間で$400を使い切ってしまったようです。 プロンプトによる精度改善の検証は、今後の課題にしたいと思います。 皆様が同じように試される場合は、事前にサイズを圧縮する・枚数を減らすなど工夫をされることを心よりおすすめいたします… おわりに 今回はSnowflakeのAIサービス「Cortex AI」を活用して、非構造データの代表格である画像データの分類に挑戦してみました。 SQLに触れることが3年前の新人研修以来だった私にとって、不安なことが多かったのですが、ほんの数行書くだけ、しかもパッと見ただけで処理内容が分かるような記述に感動しました。 また、今回の学習では数多くのエラーに遭遇しましたが、そのたびにCortex Codeが助け舟を的確に出してくれ、効率的に学習を進めることができました。 もちろん、公式ドキュメントでの裏取りも行ったので、今まで以上に深く物事が学べている印象です。 ワタシハ スノーフレーク チョットデキルに一歩でも近づけたのでしょうか… コミュニティのあり方からLinuxの未来まで ─LinuxCon Japan 2014、Linus Torvalds氏キーノート発言集 | gihyo.jp 5月20日～22日の3日間、東京・椿山荘で開催中の「LinuxCon Japan 2014」2日目最後のキーノートはこの人、Linuxの生みの親でありカリスマ的存在と言えるLinus Torvaldsさんの登場です。 gihyo.jp