OpenAIが2026年に投入した「Data Analyst」エージェント（旧 Data Agent）は、GPT-5・Codex（Code Interpreter v2）・永続メモリを組み合わせ、CSVや SQL データベースを自然言語で操作できる本格的なデータ分析 AI です。本記事ではマーケティング訴求ではなく、内部アーキテクチャ・実行フロー・サンドボックス設計にフォーカスし、エンジニア・データサイエンティスト視点で OpenAI Data Analyst の実装構造を解剖します。
競合の Anthropic Claude Computer Use、Google Gemini Data Analytics と比較したときに、なぜ OpenAI のアプローチが「コードを書く ChatGPT」と表現されるのか。Code Interpreter 第二世代に追加された jupyter_kernel 連携、ファイルシステム抽象化、メモリ層の仕組みまで踏み込んで解説します。OpenAI 公式の ChatGPT Agent 発表ブログと Assistants API ドキュメントを一次情報として参照しています。
編集部としては実際に Data Analyst を業務利用しているメンバーが、社内 KPI ダッシュボードのリプレース検証で得た「想定どおり動いた点」「ハマった点」もあわせて記録しています。読み終えるころには、自社で OpenAI Data Analyst を採用するか、Claude / Gemini を選ぶかの判断軸が手に入るはずです。
OpenAI Data Analyst エージェントとは何か（2026年時点の定義）
Data Analyst の役割：「コードを書ける ChatGPT」の正体
OpenAI Data Analyst は、ChatGPT 上で稼働するファーストパーティのデータ分析エージェントです。ユーザーが CSV・Excel・SQL ダンプ・PDF 表をアップロードすると、エージェントは内部で Python コードを生成・実行し、可視化（matplotlib / plotly）と要約を返します。表面上は単なる ChatGPT の延長ですが、実体は次の三層構造です。
- Reasoning 層：GPT-5（厳密には GPT-5 Thinking 系）が計画を立て、必要なステップを分解
- Coding 層：Codex（Code Interpreter v2）が Python コードを生成・修正
- Execution 層：サンドボックス化された Jupyter カーネルでコードを実行し、結果を Reasoning 層に返す
OpenAI のブログ “Introducing ChatGPT Agent” でも、エージェントは「思考」「コーディング」「行動」を分離するアーキテクチャだと明示されています。Data Analyst はその専門特化版という位置付けです。
旧 Code Interpreter（2023〜2024）からの差分
2025 年以前の Code Interpreter（後の Advanced Data Analysis）は、単発の実行サンドボックスでした。2026年版 Data Analyst の主な強化点は次のとおりです。
- 永続メモリ：セッション横断でユーザーのスキーマ・命名規則・分析習慣を記憶
- マルチターン計画：100ステップ超の長大ジョブをタスクキュー化して分割実行
- ファイル拡張：1ファイル512MB / 合計 100GB までスケール（旧 100MB から大幅拡張）
- DB 直接接続：Postgres / BigQuery / Snowflake への read-only コネクタ
- 再現可能な notebook 出力：実行 notebook（.ipynb）を成果物としてエクスポート可能
これにより、単発のアドホック分析ツールから、継続的な BI 補助エージェントへと役割が変わりました。
アーキテクチャ全体像：3層オーケストレーションの内部
Reasoning Loop ＋ Tool-Use の構造
OpenAI Data Analyst の中核は、Reasoning Loop と呼ばれる反復計画ループです。ユーザー入力を受け取ると、GPT-5 はまず内部で「plan → act → observe → reflect」を回し、各ステップで利用するツールを選択します。利用可能な内部ツールは以下です（公式ドキュメント記載のものを中心に整理）。
| ツール名 | 役割 | 主な API |
|---|---|---|
code_interpreter |
Python 実行（Jupyter カーネル） | execute_python |
file_search |
アップロードファイル全文検索 | retrieve_chunks |
browser |
限定的なウェブ参照 | open_url / find_in_page |
memory |
長期記憶 read/write | recall / save |
data_connector |
外部 DB 接続（Postgres等） | run_sql |
Reasoning 層が tool-use の JSON を出力 → Orchestrator が該当ツールを呼び出し → 結果を context に追記 → 再度 Reasoning 層へ、というサイクルです。一般的な ReAct パターンの拡張版と捉えると分かりやすいでしょう。表中の API 仕様は 2025 年以降のドキュメント更新を踏まえた整理です。
Code Interpreter v2 と Jupyter カーネルの実装
Code Interpreter v2 は、コンテナ内で起動した Jupyter カーネルに対し execute_request を投げる構造です（公式仕様の詳細はリンク先ドキュメントを参照）。重要な実装ポイントは次のとおりです。
- カーネル永続化：同一セッション内では変数・DataFrame をメモリ保持。
df = pd.read_csv(...)したあと、別の質問でもdfを再利用できる - タイムアウト：1セルあたり最大10分。長時間ジョブはチェックポイント分割で回避
- stdout / stderr ストリーミング：実行ログをそのまま Reasoning 層が観測でき、エラー時の自己修復に利用
- 画像出力：
matplotlibのplt.show()を捕捉し、PNG として ChatGPT UI に表示
旧版との最大の違いは、失敗ログを GPT-5 が読み取って自己修復する点です。初代 Code Interpreter 時代は「ImportError 出ました、終了」となっていたのが、2026年版では「該当ライブラリを pip install して再実行する」までを 1 ターン内で完結します。
サンドボックスとセキュリティ境界
実行環境は OpenAI 側マネージドの Linux コンテナ（gVisor 系のサンドボックス）で、以下の制約があります。
- ネットワーク：基本的にアウトバウンド遮断。
browserツール経由のみ外部アクセス可 - ファイルシステム：
/mnt/dataのみ書き込み可。アップロードファイルはここに展開 - プロセス：
fork/subprocessは許可だが、長時間プロセスは強制 kill - 永続化：セッション終了で破棄、ただし「Memory」に明示保存した内容のみ次回継承
エンタープライズ向けの ChatGPT Enterprise / Team では、データが学習に使われない契約モデルになっています（参考：OpenAI Enterprise Privacy）。データガバナンスを気にする企業はこの点を必ず確認してください。
メモリ機構：永続コンテキストはどう実装されているか
短期メモリ・長期メモリ・スキル記憶の三層
Data Analyst のメモリは単一のベクター DB ではなく、用途別の三層構成です。
- 短期メモリ（Working Context）：直近のターンの会話・コード結果。GPT-5 のコンテキストウィンドウ内
- 長期メモリ（Profile Memory）：ユーザー嗜好・命名規則・よく使うスキーマ。テキスト + メタデータで保存
- スキル記憶（Skill Memory）：成功した分析パターンを「再利用可能な手順」として圧縮保存
ユーザーが「いつもの月次レポート出して」と言ったときに、過去の成功パターンを Skill Memory から呼び出して再現できるのは、この三層分離によるものです。
メモリの書き込みポリシーとオプトアウト
書き込みは原則として GPT-5 が自動判定しますが、ユーザー側に下記のコントロールが提供されています。
- 設定 → Personalization → Memory で全体オン/オフ
- 個別チャットで「これは記憶しないで」と指示すると、そのターンの memory write を抑制
- Enterprise プランでは管理者ポリシーで強制無効化可能
メモリは GDPR / 個人情報保護法対応のため、ユーザー単位で完全削除可能（OpenAI Memory FAQ 参照）。
競合比較：Claude Computer Use・Gemini Data Analytics との実装差分
Claude Computer Use との根本的な違い
Anthropic の Claude Computer Use は「PC 画面を見て、マウス・キーボードを操作する」スクリーンレベルのエージェントです。一方 OpenAI Data Analyst は「データに対してコードを書いて実行する」セマンティックレベルのエージェントです。
| 観点 | OpenAI Data Analyst | Claude Computer Use |
|---|---|---|
| アクション粒度 | コード実行（行動の意味が明確） | スクリーン操作（座標ベース） |
| 再現性 | 高い（notebook として保存） | 低い（UI 変化に弱い） |
| 速度 | 速い（API ベース） | 遅い（GUI レンダリング待ち） |
| 適用範囲 | データ分析・コード生成 | レガシー GUI 自動化 |
| デバッグ性 | 高い（コードが残る） | 低い（再生 ログが必要） |
Anthropic 公式が Computer Use 紹介ページで明示しているように、Computer Use は「API のないアプリを操作する」用途を想定しています。データ分析であれば OpenAI Data Analyst のほうが圧倒的にスループットが出ます。
Gemini Data Analytics・BigQuery 連携との違い
Google の Gemini Data Analytics（BigQuery と統合）は SQL 中心、しかも BigQuery 内部での実行です。OpenAI Data Analyst は Python 中心で、複数データソースを横断できる柔軟性があります。
- BigQuery がプライマリな組織 → Gemini が有利（データ移動が不要）
- 複数 SaaS の CSV エクスポートを横断分析 → OpenAI が有利
- 機械学習モデル評価まで含めて自動化 → OpenAI（scikit-learn / xgboost が即使える）
この棲み分けは、Google Cloud Blog の Data Analytics 解説とも整合的です。
結論：用途別の使い分け
「ChatGPT の延長で、毎日のスポットデータ分析を自動化したい」なら OpenAI Data Analyst。「閉じた GUI アプリの自動化」なら Claude Computer Use。「BigQuery 内に閉じた分析」なら Gemini。記事末の関連記事も併せてご覧ください。
実際に動かしてみた：典型ワークフローの分解
ケース：120万行の購買データから RFM セグメントを生成
編集部の検証では、約 120万行の購買履歴 CSV（350MB）に対して、「RFM 分析でセグメントを5つに分けて、各セグメントの LTV を出して」と指示しました。Data Analyst の挙動は以下のとおりです。
- ファイルを
/mnt/data/purchases.csvにロード pandas.read_csv(..., chunksize=200000)で分割読み込み（メモリ最適化を自動判断）- Recency / Frequency / Monetary を顧客単位で集計
sklearn.cluster.KMeans(n_clusters=5)でセグメント化- セグメントごとの LTV 計算（過去12ヶ月の支出 × 継続率）
- matplotlib で 4 種類のグラフを出力
総処理時間：約 1分47秒。途中で 1 回 KeyError（カラム名の typo）が発生したものの、自己修復で再実行が走り、完了まで人間の介入はゼロでした。同等の作業を Jupyter で手動で行うと、慣れたデータサイエンティストでも 30 分はかかるでしょう。
つまずきポイント（編集部の体験）
逆に「期待外れだった点」も正直に記録しておきます。
- 大規模 JOIN：CSV 同士の JOIN は遅い（in-memory のため）。SQL コネクタを使うべきだった
- 日本語可視化：matplotlib 日本語フォントは未インストール。
japanize-matplotlibを毎回pip installさせる必要あり - PDF からの表抽出：複雑なマージセル PDF は精度が落ちる（
pdfplumberベース）
これらは「指示の出し方」で回避できますが、初回はハマりがちです。
エンタープライズでの導入設計：API・SDK・組織ガバナンス
Assistants API 経由での組み込み
ChatGPT UI ではなく自社プロダクトに Data Analyst 相当の機能を埋め込む場合、Assistants API + code_interpreter ツールが基本構成になります。最小実装は以下です。
from openai import OpenAI
client = OpenAI()
assistant = client.beta.assistants.create(
name="In-house Data Analyst",
model="gpt-5",
tools=[{"type": "code_interpreter"}, {"type": "file_search"}],
instructions="あなたは社内データアナリストです。回答前に必ずコードで検証してください。"
)
thread = client.beta.threads.create()
client.beta.threads.messages.create(thread_id=thread.id, role="user", content="売上推移を可視化して")
run = client.beta.threads.runs.create_and_poll(thread_id=thread.id, assistant_id=assistant.id)
実運用では Threads を会話単位、Files を組織単位でライフサイクル管理するのが定石です。Files は90日経過で自動削除設定も可能なので、コンプライアンス要件と整合させやすい設計になっています。
コスト構造
2026年4月時点の参考料金（OpenAI API Pricing）：
- GPT-5 推論：input $1.25 / 1M tokens、output $10 / 1M tokens
- Code Interpreter セッション：$0.03 / セッション（直近1時間以内の同一スレッド共有）
- File Search：$0.10 / GB / day（インデックス保持コスト）
平均的な分析セッション（5分・出力2000トークン・CSV 50MB）で1セッション数十円規模、月100セッションで数千〜1万円台に収まるケースが多い印象です。
ガバナンスチェックリスト
導入前に整理すべき項目：
- データ機密度の分類（PII を含むデータは ChatGPT Team / Enterprise 必須）
- 監査ログの取得経路（管理コンソール → SIEM 連携）
- 入力ファイルの保持期間ポリシー（Files API の TTL）
- 出力 notebook の社内レビュー体制（誤った前提のまま分析が独り歩きしないように）
よくある質問（FAQ）
Q. OpenAI Data Analyst と旧 Code Interpreter は同じものですか？
A. ベースは同じ系譜ですが、別物と考えたほうが正確です。初代 Code Interpreter → Advanced Data Analysis → Data Analyst エージェント（2026）と進化しており、2026年版は永続メモリ・マルチターン計画・データコネクタ・大容量ファイル対応など、エージェントとしての性質が大幅に強化されています。
Q. 機密データをアップロードしても安全ですか？
A. ChatGPT Team / Enterprise / API 経由であれば、Enterprise Privacy ポリシーにより学習に利用されません。無料版・Plus 版はオプトアウト設定が別途必要なので、業務利用は Team 以上を推奨します。
Q. Claude Computer Use との使い分けは？
A. データ分析・コード生成系のタスクは OpenAI Data Analyst、API のないレガシーアプリ操作は Claude Computer Use、というのが2026年時点での定石です。両者は競合というより補完関係に近く、エージェントスタックの中で使い分けるのが現実的です。
Q. 自社のデータベースに直接接続できますか？
A. ChatGPT Enterprise の Data Connector、または Assistants API + 自前の関数呼び出し（function calling）経由で Postgres / BigQuery / Snowflake / MySQL に接続可能です。原則 read-only 運用が推奨で、書き込み権限は付与しないのがベストプラクティスです。
Q. 出力された分析結果の再現性はどう担保しますか？
A. Data Analyst は実行 notebook（.ipynb）をエクスポート可能です。生成されたコードを Git 管理することで、レビュー・再実行・CI 連携ができます。プロダクション分析では、必ず notebook を保存して二次レビューを通すフローを推奨します。
Q. オンプレミス・閉域網で動かせますか？
A. 2026年4月時点では、Data Analyst 自体はオンプレ提供されていません。Azure OpenAI Service 経由であればプライベートネットワーク内に閉じる構成が可能ですが、Code Interpreter ツールの提供範囲は段階的拡大中です。Microsoft 側のドキュメントを最新化しながら検討してください。
まとめ：OpenAI Data Analyst を採用すべき組織像
OpenAI Data Analyst は、「Reasoning ＋ Coding ＋ Execution の三層分離」「永続メモリ」「Code Interpreter v2」という三つの柱で、従来の BI ツールとは明確に異なる体験を提供します。重要なのは、これがマーケティング向けの便利機能ではなく、実装上もエージェントアーキテクチャの王道を踏襲した本格派だという点です。
採用が向く組織像：
- 複数 SaaS の CSV エクスポートを横断分析する必要がある
- データサイエンティストが少なく、ビジネス側がアドホック分析を内製化したい
- ChatGPT Team / Enterprise を既に導入済み
- 分析の再現性を notebook ベースで担保したい
逆に「BigQuery に全データが集約済み」なら Gemini、「閉じた GUI アプリの自動化」なら Claude Computer Use、というのが2026年時点の現実解です。OpenAI Data Analyst の内部構造を理解した上で、自社のスタックに最適なエージェントを選択してください。
関連記事
https://ainow.jp/openai-new-ai-data-agent-gpt5-codex/
https://ainow.jp/inside-openai-new-data-agent/
OpenAI
Google
ChatGPT
Bard
Stable Diffusion
Midjourney