元記事は、ポートフォリオアプリの中にAIデータチャットを組み込んだという話です。
やっていることはシンプルで、ユーザーがCSVやXLSXなどのファイルをアップロードして、たとえば
みたいに日本語や英語の自然な質問を投げると、AIが中身を読んで答えてくれる、というもの。
これ、ぱっと見は「またAIで何でもやる系かな？」と思うかもしれません。
でも実際はかなり実用的です。というのも、データを扱う現場では、SQLを書ける人に毎回頼るほどでもない小さな確認作業が山ほどあるからです。
「ちょっとこの列の欠損率見たい」「カテゴリごとの売上をざっくり見たい」みたいなやつですね。こういう場面で、自然文で聞けるのはかなり便利だと思います。
元記事の構成をざっくり言うと、こんな流れです。
ここで重要なのは、AIにいきなり「答えを考えさせる」のではなく、先にファイルの構造をちゃんと見せていることです。
これがかなり大事で、AIが列名を勝手に想像してしまう事故を減らせます。
個人的には、この「まず観察、次に推論」という流れがとても良いと思いました。AIっぽい派手さはないけれど、実運用ではこういう地味な設計のほうが強いんですよね。
元記事では、フルスタック構成が表でまとめられています。要点だけ抜き出すとこうです。
ここで初心者向けに補足すると、
元記事では、Gemma 4 の複数モデルについても紹介されています。
特にこのプロジェクトでは、google/gemma-4-31B-it と google/gemma-4-26B-A4B-it を Hugging Face のエンドポイント経由で使っているとのことです。
大きな特徴は、長いコンテキストを扱えること。
コンテキストというのは、AIが一度に覚えていられる文脈の長さのことです。ファイルのスキーマ情報やユーザーの意図をまとめて渡すには、ここがけっこう重要です。
元記事では、Gemma 4 が
を扱えるモデルとして紹介されていますが、このデータチャットでは主にSQL生成のためのテキスト推論に使っています。
派手なマルチモーダル機能そのものよりも、複雑な指示をちゃんとSQLに落とし込めるかが勝負、というわけです。
CrewAIの説明も、元記事の見どころです。
AIを1体の万能ロボットとして扱うのではなく、役割を分けます。
たとえば、
みたいな感じです。
こういう設計の良さは、何をしているのか追いやすいことだと思います。
AIアプリって、裏側がブラックボックスだと怖いんですよね。
でも役割が分かれていれば、「今どこで間違ったのか」を見つけやすい。これは開発者にとってかなりありがたいです。
バックエンド側の流れも、かなり実用寄りです。
ユーザーがアップロードしたファイルを一時ディレクトリに保存します。
CSV、Parquet、Arrow、JSON、XLSX などを見分けます。
読み込んだデータをDuckDBのテーブルとして扱えるようにします。
DESCRIBE data のような形で、列名や型を確認します。
同時に総行数も数えます。
スキーマ情報、行数、ユーザーの質問をまとめて CrewAI + Gemma 4 に渡します。
生成されたSQLをDuckDBで実行し、結果を返します。
この順番がとてもまともです。
「AIに全部おまかせ」ではなく、まずデータを観察してからSQLを書く。
当たり前に聞こえるかもしれませんが、こういう基本を守るアーキテクチャは強いです。
元記事では、49行・18列のe-commerce売上CSVを使って6つの質問を試しています。
ここがかなり楽しいところです。
生成されたSQLはシンプルに
SELECT * FROM data LIMIT 10
です。
これは当然といえば当然ですが、まず最初の確認としては理にかなっています。
「中身をざっと見る」という行為は、データ分析の入口としてすごく大事です。
ここがちょっと面白いです。
Gemma 4 は各列について、欠損がどれくらいあるかを全部計算するSQLを作っています。
つまり、ただのSELECTではなく、データ品質チェックまで自動化しているわけです。
結果としては、49行・18列すべてで null率0% だったとのこと。
これは地味にすごいです。
普通は、こういう確認のために列ごとにSQLを書くのが面倒で、つい後回しになりがちです。
でも自然文で聞いて一発で出るなら、かなり使い勝手がいいと思います。
記事では途中までしか見えませんが、カテゴリごとの集計SQLを生成していることがわかります。
SUM(sales) や SUM(profit) を使って、売上合計と利益率を出す流れです。
このへんになると、もはや単なる検索ではなく、分析の入口をAIが肩代わりしている感じがあります。
個人的には、このレベルまで自然文でこなせるのはかなり実用的だと思いました。
この記事で本当に面白いのは、AIの派手さよりも、データ分析の面倒を削る設計にあります。
たとえば現場では、
という手順が必要です。
これを毎回やるのは、正直かなりだるい。
元記事のツールは、その最初の数段をかなり短縮してくれます。
もちろん、AIが作ったSQLは常に正しいとは限りません。
そこは過信しないほうがいいです。
でも、「たたき台を高速で出す」という役割なら、かなり有望だと思います。
個人的には、このプロジェクトはかなり好印象です。
理由は3つあります。
特に3つ目が大事で、結果だけ返すAIは便利な反面、どうやってその答えに至ったのかが見えにくいです。
でもこのツールは、実際にどのSQLが走ったかをUIに表示するので、納得感があります。
これはデータ系のアプリとしてかなり誠実だと思います。
この手の仕組みは、次のような人に向いていそうです。
逆に、厳密な分析や本番の意思決定では、まだ人間のチェックは必要です。
でも、探索の初速を上げるツールとしてはかなり魅力的だと思います。
元記事は、Gemma 4、CrewAI、DuckDB、Supabase Edge Functions、Google Cloud Run を組み合わせて、「データに自然文で質問できるチャット」を実装した話でした。
このプロジェクトの良さは、AIをただ飾りとして使っているのではなく、
スキーマ確認 → SQL生成 → 実行 → 結果表示 という流れをきれいに分業しているところです。
つまりこれは、「AIがなんとなく答えるデモ」ではなく、
実際のデータ分析をちょっと楽にするための、かなり筋のいい設計なんですよね。
こういう実装は、見た目以上に価値があると思います。