Kaggleで開催された心電図画像のデジタル化をテーマにした医療系コンペティションの参加レポートです。画像の正規化やセグメンテーション技術を活用したAIモデルの構築手法について詳しく解説しています。

G-gen のバロキです。当記事では、Anthropic の Claude Code と Google Cloud の データサイエンスエージェント という 2 つの AI ツールに、同一のデータセットと指示を与えて比較しました。自動生成されるデータ分析ノートブックに、どのような違いが生まれるかを検証しました。 概要 はじめに データサイエンスエージェントとは Claude Code とは 検証の前提条件 使用したデータセット 投入したプロンプト 評価の観点 生成されたノートブックの全体像 データサイエンスエージェントの特徴 Claude Code の特徴 観点別の比較 コードの量と構造 可視化のスタイル 説明可能性 データクレンジングへの姿勢 コードの再利用性 設計思想の対比 ユースケース別の使い分け データサイエンスエージェントが向いているケース Claude Code が向いているケース 概要 はじめに 「データを渡すと、AI が分析ノートブックを生成してくれる」という体験が、一般的になりつつあります。Google Cloud のデータサイエンスエージェントや、Claude Code をはじめとする大規模言語モデル（Large Language Model、以下、LLM）ベースのエージェントツールは、いずれもデータ分析の自動化を可能にします。 しかし実際に検証してみると、同じデータセットと同じ指示を与えても、ツールによって出力されるノートブックに違いがあるケースがあります。当記事では、両者の成果物を並べて比較し、その差がどこから生まれるのかを読み解きます。 結論を先に述べると、2 つのツールに優劣はなく、想定されている用途やユーザー層が異なります。なお、当記事の内容は、検証を行った2026年5月現在の仕様に基づいています。 データサイエンスエージェントとは データサイエンスエージェント は、Google Cloud の Colab Enterprise に組み込まれた、 Gemini をベースとするデータ分析エージェントです。タスクをサブタスクに分解し、ステップごとに思考プロセスを示しながら処理を進める点が特徴です。BigQuery テーブルや CSV ファイルを入力に、自然言語の指示から動作する Colab ノートブックを生成します。 参考 : データ サイエンス エージェントを使用する - Colab Enterprise 以下の記事も参照してください。 blog.g-gen.co.jp Claude Code とは Claude Code は、Anthropic が提供する、ターミナル上で動作するエージェント型のコーディングツールです。プロンプトを受け取ると、ノートブック全体の構成をあらかじめ設計し、一括で書き下ろすスタイルが特徴です。 参考 : Claude Code overview 検証の前提条件 使用したデータセット 検証には、Kaggle で公開されている「Japanese Universities」データセットを使用しました。1872 年以降の日本の大学情報を網羅したオープンデータです。 参考 : Japanese Universities - Kaggle データセットの主な仕様は以下のとおりです。 項目 仕様 公開者 webdevbadger 内容 1872 年以降の日本の大学情報（所在地、創立年、評判、難易度など） ライセンス Open Data Commons Public Domain Dedication and License（ODC-PDDL） 行数 / 列数 813 校 / 22 列 対象範囲 47 都道府県すべてを網羅 創立年範囲 1872 年 11 月（明治期）〜 2022 年 4 月（近年） 設置主体内訳 Private 626 校 / Public 101 校 / National 86 校 主なカラム code 、 name 、 name_jp 、 type （National / Public / Private）、 address 、 state_jp 、 latitude 、 longitude 、 found （YYYY-MM）、 faculty_count 、 department_count 、 review_rating 、 review_count 、 difficulty_SD 、 difficulty_rank （A〜F） 当データセットは、設置主体や地域の分布に明確な構造を持ち、創立年の時間軸も広いため、探索的データ分析（exploratory data analysis、以下 EDA）の検証素材として適しています。EDA とは、本格的なモデリングに入る前に、データの分布や欠損、変数間の関係を可視化しながら把握する作業です。AI に EDA を依頼し、その出力の質を比較する用途にも向いています。 投入したプロンプト 両者には、以下の 4 つの観点を網羅する EDA を依頼する同一の本文を、いずれも日本語のプロンプトで与えました。 データ品質 : 欠損、重複、異常値、基本特性、数値変数間の関係 地理的分析 : 大学の空間分布と都道府県・地域別の設置主体構成 機関特性 : National / Public / Private を規模と評判の両面から比較 時系列分析 : 創立の経年トレンドと設立時期別の設置主体構成 加えて、最終成果物に「分析から得られた重要な気づきを 5 つ」を含めること、および日本語テキストが正しく表示されることを条件としました。 なお、公平性のため分析を依頼する本文は両者で同一にしていますが、成果物の保存先の指示だけは実行環境に合わせて変えています。Claude Code はローカルのターミナルで動作するため、「成果物を output/ フォルダに保存する」よう明示的に指示しました。一方、データサイエンスエージェントは Colab Enterprise 上でノートブック自体が保存されるため、この指示は与えていません。 データサイエンスエージェントに入力したプロンプト（分析本文は Claude Code と同一） Claude Code のターミナルに入力したプロンプト 評価の観点 生成されたノートブックの品質を、以下の軸で観察しました。 実行性（エラーなく走るか） カバレッジ（プロンプトの要求項目を満たしているか） コード品質（慣用的か、再利用可能か） 可視化の量と質 説明可能性（各ステップの意図が読み取れるか） 構造の見通しの良さ 生成されたノートブックの全体像 データサイエンスエージェントの特徴 データサイエンスエージェントは、タスクをサブタスクに分解し、各ステップの目的を明示してから実行します。出力されたノートブックでは、各コードセルの直前に「 Reasoning : ...」という Markdown セルが配置され、これから何を行うか、なぜその処理が必要なのかが自然言語で解説されます。 主な特徴は以下のとおりです。 各セルが自己完結する（必要なインポートをセル内で都度実行する） 「データの読み込み → 欠損値の確認 → 補完処理 → 可視化」のように段階を明示する 各ステップに Reasoning ブロックを付与する エラーや警告が発生した場合、それを検知して次のセルでリカバリするプロセスが記録される ステップごとの透明性の確保が、データサイエンスエージェントの設計思想の中核と言えます。 データサイエンスエージェントのコードセル上部に表示される Reasoning マークダウン Claude Code の特徴 Claude Code は、ノートブック全体を 1 つの完成品として設計してから書き下ろします。プロンプトを受けると、内部で全体構造をプランニングし、必要なライブラリ、再利用するカラーパレットや定数、セクション構成を最初に決定したうえで、一括でノートブックを出力します。 主な特徴は以下のとおりです。 インポート文とグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE など）を冒頭に集約する 同じ可視化スタイルを全セクションで一貫させる セルあたりのコード密度が高く、1 つのセルで複数のグラフを配置する 各セクションの最後に「ポイント」として短い解釈を記述する 観点別の比較 コードの量と構造 出力されたノートブックの構成を数値で示します。 項目 Claude Code データサイエンスエージェント 総セル数 55 41 コードセル 30 16 Markdown セル 25 25 総コード行数 約 353 行 約 286 行 インポートの位置 冒頭に集約 各セルで都度実行 セル数やコード行数の違いは、それぞれの設計思想を反映しています。Claude Code は完成されたレポートとしての密度を重視し、データサイエンスエージェントはステップごとの実行ログとしての読みやすさを重視していると言えます。 可視化のスタイル Claude Code はライブラリ選択の幅が広く、 folium による地図プロット、 seaborn の violinplot 、 pairplot 、 heatmap などを柔軟に使い分けます。1 つの観点に対して多角的にアプローチする構成です。 データサイエンスエージェントは、 plotly express による地図プロットや、 matplotlib と seaborn を組み合わせたシンプルな boxplot 、積み上げ棒グラフが中心です。種類を絞ることで、初学者でもプロセスを追いやすい一貫性を持たせています。 Claude Code が生成した Folium 地図と violinplot/heatmap データサイエンスエージェントが生成した Plotly Express 地図と box plot 説明可能性 ここが 2 つのアプローチで最も大きく分かれるポイントです。 Claude Code が生成するノートブックは、コードは洗練されているものの、「なぜその可視化手法を選んだのか」といった意図はコードから読み解く必要があります。一定以上のデータ分析リテラシーを前提としたレポート構成です。 一方、データサイエンスエージェントでは、各セルの直前に処理の意図が明記されます。例えば欠損値処理のフェーズでは、以下のような Reasoning が出力されます。 Reasoning: Based on the analysis of missing values, I will impute phone with 'Unknown' as it is a categorical identifier. For numerical columns review_rating, review_count, and difficulty_SD, I will use median imputation as it is more robust to outliers. For the categorical column difficulty_rank, I will use mode imputation. データサイエンスエージェントの Reasoning 付き欠損値補完セル Claude Code の可視化中心の欠損値処理セル 「何を、どう処理して、なぜそうするのか」が逐一言語化されるため、データ分析を学習中のメンバーにとって、ノートブック自体が良質なチュートリアル教材となります。 データクレンジングへの姿勢 データクレンジングに対する姿勢も対照的です。 Claude Code は欠損値を可視化して報告するに留め、欠損のまま分析を進めます。EDA としては伝統的な進め方で、欠損のパターン自体に情報があるため、むしろ望ましいという見方もあります。 データサイエンスエージェントは、欠損値を統計的に補完（インピュテーション）します。インピュテーションとは、欠損したセルを平均値や中央値などで埋める処理のことです。 phone は 'Unknown' 、数値カラムは中央値、カテゴリカラムは最頻値で埋める、という戦略を文章で宣言してから実行します。下流のモデリングに繋ぐパイプラインを想定すると、この明示性は実務で有用です。 どちらが正解ということはなく、Claude Code は分析者の判断を読者に委ね、データサイエンスエージェントは判断を逐一表に出す、という思想の違いです。 コードの再利用性 Claude Code はグローバル定数（ TYPE_ORDER 、 TYPE_PALETTE ）と再利用可能なヘルパー関数（ iqr_outliers ）を冒頭で定義し、以降のセルがそれを参照する構造になっています。コードベースとして手入れし続ける用途に適しています。 データサイエンスエージェントはセルごとに自己完結しているため、一部のセルだけを別のノートブックにコピーして流用するのが容易です。「特定の処理だけ使い回したい」というユースケースには、データサイエンスエージェントのスタイルが向きます。 設計思想の対比 これまでの検証を踏まえ、両者の設計思想の違いを一覧にまとめます。 観点 Claude Code データサイエンスエージェント 出力の性格 完成形のレポート 実行ログ・チュートリアル プランニング 上位から一括生成 ステップ単位で漸進的に実行 説明可能性 サマリでの論評 各セルに Reasoning を配置 カバレッジ 網羅的かつ深層的 コアとなる観点に集中 エラーハンドリング エラーを起こさない前提のコード エラー時は次セルでリカバリを実行 コードの密度 高い 低い（可読性重視） 再利用性 グローバル定義による一元管理 セルごとの自己完結型 介入の容易さ 低い 高い 想定ユーザー 経験豊富なアナリスト 学習者・ビジネス層・探索的分析 ユースケース別の使い分け データサイエンスエージェントが向いているケース データ分析の学習フェーズ Reasoning が併記されるため、分析者の思考プロセスを追体験する教材として使用できます。 対話的な探索フェーズ 「ここまでの結果を踏まえ、次は別の切り口で検証したい」といった、人間が途中で介入しながら進める探索に適しています。 ビジネス層によるデータ探索 非開発者が自然言語でデータを問い合わせる際、処理がブラックボックス化せず、結果の根拠をステップごとに確認できます。 Colab 環境での完結 Colab 起動を前提とした環境設定コードも含まれるため、ブラウザのみで即座に分析を開始したい場合に最適です。 パイプラインの部分流用 セル自己完結型のため、データクレンジングのセルだけを別ノートブックにコピーするといった部分流用がしやすくなります。 Claude Code が向いているケース 迅速なレポート作成 分析結果を素早くレポートとして共有したいケースで、一括生成が強みを発揮します。可視化のバリエーションが豊富で、レポートとしての完成度が高い特徴があります。 経験豊富なアナリストの叩き台 コードが慣用的で密度が高いため、これをベースに独自のカスタマイズや手動の書き換えを素早く行う用途に適しています。 要求項目の網羅（カバレッジ重視） プロンプトに指定したチェックリスト的な要求に対して、抜け漏れなく一括で対応させたい場合に有利です。 カスタムビジュアライゼーションの使用 folium のクラスタリング地図、scatter matrix、violin plot など、データ分析で慣習的に使われる可視化を幅広く使いたい場合に引き出しが多くなります。 ハサナル・バロキ (記事一覧) クラウドソリューション部 クラウドサポート課。インドネシア北スマトラ州ビンジャイ市出身。 YKK株式会社での金型設計を経て IT 業界へ転身。AI／システムエンジニアとしての経験を積み、現在は G-gen にてクラウドサポートに従事。 趣味は水泳と RAG チャットボット開発（OpenAI・Gemini・Vector Search 等）。好きな食べ物はラーメンと寿司。

本記事は 春のスキルアップ応援フェア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