Local LLMでのデータ分析を試してみた

こんにちは

AI チームの戸田です。

最近、Coding Agent を使った開発体験がかなり変わってきています。ファイルを読ませ、コードを書かせ、テストを実行させ、エラーを直させる、という流れはすでに日常的に使える水準になってきました。

一方で、Agent に任せられる範囲はコーディングだけではありません。データ分析も、ファイルを読む、前処理を書く、評価指標を出す、結果をレポートにまとめる、という意味ではかなり Agent 向きのタスクです。

例えばデータ分析コンペティションの Kaggle でも、EDA(Exploratory Data Analysis) に AI を使う流れは見え始めています。

ここで気になるのが、業務で顧客データを分析するときにも、同じように AI Agent を使えるのか？という点です。

LLM が業務でも一般化してきたとはいえ、実務では LLM にデータを投げること自体に抵抗のある方が少なくありません。ドメインによっては、契約や規制上の理由で外部 API に渡すこと自体が NG、というケースも普通にあります。クラウドのフロンティアモデルは強力ですが、どの案件でもそのまま使えるわけではない、というのが現状です。

もし Local LLM でデータ分析 Agent を組めばデータを外に出さずに、手元の環境で EDA(探索的データ分析)、特徴量設計、モデル評価、レポート作成まで回せます。

そこで今回は、まず小さな題材として Titanic データセットを使い、以下の 2 構成を比較してみました。

構成

モデル

harness

クラウドモデル

GPT-5.5

Codex

Local LLM

Qwen3.6 27B MTP GGUF

Qwen Code

最初は Codex を共通 harness にして Qwen3.6 も評価しようとしたのですが、Responses API と tool schema の相性でうまくはまりませんでした。短い tool probe までは通ったものの、Titanic 分析を完走するところまでは安定しなかったため、Qwen 側は Qwen Code に切り替えています。

本記事では、その検証結果を共有します。

検証設定

実行環境

検証は以下の環境で実施しました。

項目

内容

マシン

MacBook Pro M3 Max / 64GB

Codex CLI

0.128.0

Qwen Code

0.16.2

推論サーバ

LM Studio OpenAI 互換 API

データセット

seaborn-data の Titanic

Qwen Code について

Qwen Code は Alibaba の Qwen チームが公開している OSS(オープンソースソフトウェア) の Coding Agent CLI で、Qwen モデルの Tool Call(ツール呼び出し) 向けに最適化されています。Apache 2.0 ライセンスで、ツール自体は無料で使えます。

ポイントは、モデルの動かし方が 2 通りあることです。

• Local 実行：今回のように手元の LM Studio / Ollama などを OpenAI 互換 API として繋ぐ。モデルが手元で動くので、API コストはかからず、データも外に出ません。

• API 経由：Alibaba Cloud の DashScope などのクラウド API に繋ぐ。Qwen Code 経由だと一定の無料枠（OAuth 認証で 1 日あたりのリクエスト枠）が用意されています。

つまり「ローカルにモデルを置いて完全無料で回す」「クラウドの大きいモデルを無料枠で試す」のどちらも選べます。手元のマシンスペックに合わせて使い分けられるので、Codexの有料プランに手を出しづらい学生の方などには、こちらがメインの選択肢になり得ると思います。

Qwen CodeからはOpenAI互換APIとしてLM Studioに接続しています。

qwen \

--bare \

--auth-type openai \

--openai-base-url http://127.0.0.1:1234/v1 \

--openai-api-key lm-studio \

--model qwen3.6-27b-mtp \

--yolo

タスク

タスクはTitanicデータセットを使った生存予測です。

Agentには、単に分析方針を説明するだけでなく、report.mdに結果を書き出すように指示しました。

Agentへの指示あなたはデータ分析Agentです。Titanicデータセットを使って、

生存予測に関する探索的データ分析、前処理、モデル構築、評価、

レポート作成を行ってください。

前提:

• 外部データを追加で使わず、与えられたTitanicデータのみを使う
• 実行可能性と再現性を重視する
• 入力データは data/titanic.csv
• Python実行ファイルはプロジェクト内の .venv/bin/python を使う
• alive は survived と同義の派生列なので、予測特徴量から除外する

要件:

1. データの形状、型、欠損値、基本統計量を確認する
2. 目的変数 survived との関係をEDAする
3. 欠損値処理とカテゴリ変数処理の方針を説明する
4. ベースラインモデルを作成する
5. 少なくとも1つの特徴量改善を試す
6. AccuracyとROC AUCを評価する
7. データリークを避ける
8. 実行可能なPythonコードを作成する
9. 最終レポートをMarkdownで作成する
10. 判断理由、限界、次に試すべきことも書く

成果物:

• analysis.py または analysis.ipynb
• report.md
• metrics.json
• notes.md

analysis.py を作る場合は、最後に自分で実行し、

成功したことを notes.md に記録する。

GPT-5.5 + Codex

まず、GPT-5.5 + Codexの結果です。実行時間は148.06sでした。

今回見たいのは「モデル精度が何点か」よりも、Data Scientistが最初にやるEDAをどれくらい任せられるかです。その観点では、Codex + GPT-5.5はかなり素直に期待した動きをしてくれたと思います。

Codexがreport.mdにまとめた主なEDA結果は以下です。

観点

結果(生存確率)

性別

female 0.742、male 0.1889

客室クラス

1等 0.6296、2等 0.4728、3等 0.2424

乗船地

C 0.5536、Q 0.3896、S 0.337

数値特徴量

生存者は平均運賃が高い

加えて、単に集計するだけでなく、「性別は強い予測特徴量」「客室クラスは社会経済的proxy」といった解釈まで書けています。

report.md

必ずJSON形式で返してください。translation フィールドのみ。他のフィールド(technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}

タイタニック生存予測レポート

1. エグゼクティブサマリー

タイタニックデータ data/titanic.csv の891行・15列を用いて、生存フラグ survived を予測する二値分類モデルを作成した。alive は survived と同義の派生列であるため、全モデルの特徴量から除外した。

同一の層化 train/test 分割（test_size=0.2, random_state=42）で比較した結果、ベースライン Logistic Regression は Accuracy 0.7933、ROC AUC 0.8381、改善版は Accuracy 0.8045、ROC AUC 0.8469 だった。

2. データ概要

• 形状: 891 rows x 15 columns

• 目的変数: survived

• 生存率: 0.3838

• 目的変数分布: 0=549, 1=342

カラムタイプ

index

value

survived

int64

pclass

int64

sex

str

age

float64

sibsp

int64

parch

int64

fare

float64

embarked

str

class

str

who

str

adult_male

bool

deck

str

embark_town

str

alive

str

alone

bool

欠損値

index

value

deck

688

age

177

embarked

2

embark_town

2

数値要約

index

survived

pclass

age

sibsp

parch

fare

count

891

891

714

891

891

891

mean

0.3838

2.3086

29.6991

0.523

0.3816

32.2042

std

0.4866

0.8361

14.5265

1.1027

0.8061

49.6934

min

0

1

0.42

0

0

0

25%

0

2

20.125

0

0

7.9104

50%

0

3

28

0

0

14.4542

75%

1

3

38

1

0

31

max

1

3

80

8

6

512.3292

カテゴリカル要約

index

sex

embarked

class

who

adult_male

deck

embark_town

alive

alone

count

891

889

891

891

891

203

889

891

891

unique

2

3

3

3

2

7

3

2

2

top

male

S

Third

man

True

C

Southampton

no

True

freq

577

644

491

537

537

59

644

549

537

3. EDA（探索的データ分析）の知見

性別による生存状況

sex

count

survival_rate

female

314

0.742

male

577

0.1889

女性の生存率は男性より大きく、sex は強い予測特徴量と判断した。

pclass

count

survival_rate

1

216

0.6296

2

184

0.4728

3

491

0.2424

客室クラスが上がるほど生存率が高い傾向があり、pclass は重要な社会経済的 proxy（代理変数）として扱った。

Survival by Embarked

embarked

count

survival_rate

C

168

0.5536

Q

77

0.3896

S

644

0.337

2

1

乗船地によって生存率に差がある。ただし欠損は 2 件のみなので、学習データ内の最頻値で補完する方針にした。

Numeric Means by Target

survived

age

fare

sibsp

parch

0

30.6262

22.1179

0.5537

0.3297

1

28.3437

48.3954

0.4737

0.4649

生存者は平均運賃が高く、fare は生存と関連している。age は 177 件欠損しており、中央値補完で扱った。

4. Preprocessing Design

• 数値変数：train fold で中央値補完し、Logistic Regression（ロジスティック回帰）向けに標準化した。

• カテゴリ変数：train fold で最頻値補完し、未知カテゴリを許容する OneHotEncoder（one-hot エンコーダー）を使った。

• リーク対策：survived と同義の alive は除外した。class は pclass、embark_town は embarked と重複するため使わず、ベースラインでは重複を避けた。

• 欠損の多い deck：生のカテゴリとしては使わず、改善版では「deck 情報が記録されているか」を表す has_known_deck のみ使った。これは乗客データ内から作れる特徴量であり、目的変数を参照しない。

• 評価設計：前処理は scikit-learn Pipeline（パイプライン）内に入れ、imputer/encoder/scaler は学習データだけで fit（適合）されるため、test data leakage（テストデータリーク）を避けている。

5. Models

Baseline

• Model: LogisticRegression（ロジスティック回帰モデル）

• Features: pclass, age, fare, sex

• Accuracy: 0.7933

• ROC AUC: 0.8381

Improved Feature Set

• Model: LogisticRegression（ロジスティック回帰モデル）

• Features: pclass, age, fare, sibsp, parch, family_size, is_alone_engineered, fare_log, has_known_deck, sex, embarked, age_group

• Added feature ideas: family size（家族規模）、engineered alone flag（人工的に作成された単独フラグ）、log fare（対数運賃）、known deck flag（デッキ情報有無フラグ）、age group（年齢層）、sibling/parent counts（兄弟・父母の数）、embarked（乗船地）。

• Accuracy: 0.8045

• ROC AUC: 0.8469

6. Interpretation

改善版では、家族人数、運賃の歪みを抑えた fare_log、年齢帯、乗船地、deck 記録有無を追加した。Accuracy と ROC AUC の変化を見ることで、単なる閾値分類だけでなく順位性能も比較した。

このデータでは性別と客室クラスの説明力が大きい。改善版の特徴量はドメイン上妥当だが、テスト行数は 179 行と小さいため、単一分割の差は過信しない。

7. Limitations

• 単一の holdout 評価であり、分割に依存する可能性がある。

• Titanic データは小規模で、欠損や派生列が多い。

• deck の欠損は非常に多く、欠損そのものが記録バイアスを含む可能性がある。

• who, adult_male, alone は既存列として便利だが、今回は特徴量改善の意図を明確にするため、独自に再計算できるものを中心に使った。

8. Next Steps

• Stratified K-Fold cross-validation で分割依存性を確認する。

• 正則化強度や木系モデル（RandomForest, GradientBoosting）を比較する。

• 年齢欠損の指示変数や、性別・クラス・年齢帯の交互作用を試す。

• 閾値を業務目的に合わせて調整し、混同行列や precision/recall も確認する。

また以下のような可視化も行ってくれました。

Qwen3.6 + Qwen Code

次に、Qwen3.6 + Qwen Code です。

実行時間は real 601.76s で完走できたものの、EDA（Exploratory Data Analysis：探索的データ分析）の中身として見ると、Codex + GPT-5.5 とはかなり差がありました。

report.md はデータサイズとモデル結果の要約が中心で、EDA の集計や解釈はほぼ書かれていませんでした。

report.md

Titanic Survival Analysis Report

Dataset Summary

• Rows: 891

• Columns: 15

Models Evaluated

Baseline Model

• Features: pclass, sex, age, fare

• Accuracy: 0.7877

• ROC AUC: 0.8383

Improved Model

• Additional features: female_1st (interaction), age_bin (binned age), log_fare (log transform)

• Accuracy: 0.7877

• ROC AUC: 0.8299

Conclusion

The improved model matched the baseline on accuracy (0.7877 vs 0.7877) and was slightly lower on ROC AUC (0.8299 vs 0.8383).

可視化も行なってくれましたが、Codex + GPT-5.5 に比べると物足りなさが否めません。

結果比較

EDA を一覧で比較してみると、差が分かりやすくなりました。

観点

Codex + GPT-5.5

Qwen3.6 + Qwen Code

データ概要

形状、型、欠損、目的変数分布まで整理

rows/columnsのみ

リーク検知

alive を明示的に除外

report 上では言及なし

欠損理解

deck, age, embarked, embark_town を整理し、処理方針も説明

可視化時に SimpleImputer (単純な欠損値補完器) を追加

EDA 集計

性別、客室クラス、乗船地、運賃、年齢を数値で説明

図は生成するが、report 内の数値解釈は薄い

可視化の選択

5 枚。sex x pclass、age、fare、family size、age missingness

4 枚。sex x pclass、age、fare、family size

可視化の作り

fare は log 変換 boxplot (対数変換箱ひげ図)、family size に n 表示、図ごとに key finding (重要な発見) あり

raw fare hist、別 subplot age hist など素朴

report 品質

Data Scientist が読める分析レポートに近い

図とモデル結果の一覧に近い

差は「図を作れるかどうか」よりも、「図から何を読み取るか」「次の前処理や特徴量設計にどうつなげるか」で大きく出ています。Codex + GPT-5.5 は欠損、リーク、カテゴリ別の生存率、外れ値、特徴量設計までを一つの分析としてつないでいます。Qwen3.6 + Qwen Code も図の生成とモデル実行はできていますが、図から読み取った内容の report.md への反映は薄めです。

実行時間にも差がありました。Codex + GPT-5.5 が 148.06s、Qwen3.6 + Qwen Code が 601.76s で、4 倍ほど開きがあります。複数回の試行錯誤を任せる場合、この差はそれなりに効きそうです。

まとめ

本記事では、Titanic データを題材に、EDA を AI Agent に任せられるかという観点で、Codex + GPT-5.5 と Qwen Code + Qwen3.6 を比較しました。

今回一番感じたのは、EDA を Agent に任せるときは「コードが動くか」だけでなく、「データを見て、解釈して、次の判断につなげられるか」を見ないといけない、ということです。

Codex + GPT-5.5 は、可視化・考察・レポートまで一通り安定して任せられる印象でした。Qwen3.6 + Qwen Code も、Local LLM (ローカル大規模言語モデル) として可視化を含む EDA をローカルで最後まで完走できた点は意義があります。外部 API に出しにくいデータを扱う場面で、ローカル環境だけで図と最低限のレポートを出せるのは大きいと思います。ただし、report.md はモデル結果の記述に寄りがちで、EDA 結果の解釈は Codex + GPT-5.5 より明らかに薄く、「動かせる」と「実務で任せられる」の間にはまだ距離がある、というのが正直なところです。

結論としては、可能であればフロンティアモデル (Codex + GPT-5.5 など) を使うのが素直に良い、というのが今回の所感です。Local LLM での EDA Agent も「できなくはない」水準には来ていますが、安定して任せるにはまだ厳しく、データを外に出せないなどの制約がある場合の現実的な選択肢、という位置づけだと感じました。

最後までお読みいただきありがとうございました！

参考

• How to use ChatGPT in a competition: EDA, part 1

• How to use ChatGPT in a competition: Model, part 2

• How to use ChatGPT in a competition: Final, part 3

• Inside Kaggle's AI Agents Intensive Course with Google

株式会社AI Shift（サイバーエージェント100％子会社）開発チームのTech Blogです。