CodexでCSVを調査する前に決めること

3行まとめ

Raw

原本。

Schema

列。

Check

検算。

Report

記録。

Codexに集計させる前に、原本と作業結果を分けます。

• CodexにCSVやspreadsheetを読ませる前に、raw、working、outputを分け、原本を直接変更しないようにします。
• 列定義、単位、日付、欠損、重複、外れ値を先に確認すると、集計結果の読み違いを減らせます。
• レポートには、結論だけでなく、使ったfile、前提、集計方法、検算、限界を残します。

Codexに表データを渡すと、集計や要約はかなり速く進みます。CSVを読ませて、「月別にまとめて」「売上の変化を見て」「異常値を探して」と頼むだけで、すぐそれらしい答えが出ます。

ただし、表データは怖いです。列名が同じでも意味が違う。日付がUTCなのかJSTなのか分からない。空欄が0なのか未入力なのか分からない。重複行が実データなのかexportミスなのか分からない。こうした前提が曖昧なままAIに集計させると、見た目のよいレポートが間違った判断材料になります。

この記事では、2026年6月1日時点のOpenAI公式Codex Use Cases、Codex app features、Permissions、AGENTS.md docsをもとに、CSVやspreadsheetをCodexへ渡す前の整理を扱います。社内APIやexportをCodexに使わせる入口は、公開済み記事のCodexにチームCLIを渡す前に決めることで扱っています。ここでは、渡された表データを安全に読む話に絞ります。

この記事でわかること

辞書

列定義。

作業コピー

保護。

質問

絞る。

検算

照合。

表データは、問いを絞るほど結果を確認しやすくなります。

• raw dataを守りながら作業コピーを作る方法
• column dictionaryを先に作る理由
• 欠損、重複、外れ値の扱い方
• 数値、日付、カテゴリの型をそろえる見方
• Codexへ渡す質問を小さくする方法
• 集計結果をrow count、subtotal、sampleで検算する方法
• レポートに残すべき前提と限界

表データの分析では、速さよりも戻れることが大事です。原本、作業コピー、成果物、作業ログが分かれていれば、結論が怪しい時に戻って確認できます。

前提知識

項目	内容	見方
Query		表へ質問。
Clean		前処理。
Analyze		報告。
Permissions		権限。
AGENTS.md		手順。

表データ作業は、読み取り、加工、報告を分けて扱います。

OpenAI公式のCodex Use Casesには、Query tabular data、Clean and prepare messy data、Analyze datasets and ship reportsが含まれています。CSV、spreadsheet、export、data folderへ質問したり、表データを壊さずに整えたり、分析結果をレポートへまとめたりする用途です。

Codex app features、Permissions、AGENTS.md docsは、どのprojectで作業するか、どこまでfileを読ませるか、どの形式で報告させるかを決める時に関係します。

data analysisとcode作業を分ける

CSV調査は、コード実装とは違います。目的は、差分を作ることではなく、dataから判断材料を作ることです。

Codexに任せる時も、最初からfileを書き換えさせません。まずread-onlyで構造を確認し、必要ならworking copyへ加工します。

export生成との違い

export生成は、社内APIやDBからCSVを出す作業です。表データ調査は、既にあるCSVやspreadsheetを読み、問いに答える作業です。

この2つを混ぜると、取得条件の問題と分析方法の問題が分からなくなります。まず、どのexportを使ったのかを固定し、その上で分析します。

原本を残して作業コピーを作る

1. 1Raw

   読取専用。

2. 2Working

   加工。

3. 3Output

   成果物。

4. 4Log

   記録。

原本を守ると、集計ミスが出ても戻れます。

最初に、raw、working、outputを分けます。rawは原本です。workingは加工用です。outputは成果物です。

Codexには、rawを直接編集しないように伝えます。CSVの文字コードを直す、列名を整える、日付を変換する、欠損を補うといった作業は、working copyで行います。

raw

rawは、受け取ったまま保存します。ファイル名、取得元、取得時刻、export条件、件数を記録します。

rawを守ると、後から「どこで数字が変わったか」を追えます。

working

workingは、調査用のコピーです。列名を正規化したり、不要列を落としたり、型を変換したりします。

workingを作る時は、変更内容をlogに残します。Codexには、変換手順を箇条書きで出させます。

output

outputは、集計表、グラフ、Markdown report、CSV、JSONなどの成果物です。

outputだけを見ても、正しいか判断できません。rawとworkingへの参照、使ったfilter、集計式を一緒に残します。

列定義を先に確認する

項目	内容	見方
Name		列名。
Meaning		意味。
Unit		単位。
Source		由来。

列名だけで判断すると、同じ名前の違う意味を取り違えます。

集計前に、column dictionaryを作ります。列名、意味、単位、型、欠損の扱い、由来を確認します。

列名は信用しすぎないほうがよいです。amountが税込なのか税抜なのか、created_atがUTCなのかJSTなのか、statusが現在状態なのかexport時点の状態なのかで、結論は変わります。

column meaning

まず、各列が何を意味するかを確認します。仕様docs、export定義、DB schema、担当者の説明があれば根拠にします。

Codexには、列名から推測させるだけでなく、不明な列を「要確認」として残させます。

units

単位は見落としやすいです。金額、時間、割合、件数、容量、距離などは、単位が違うと集計が壊れます。

円、ドル、税抜、税込、秒、分、ms、パーセント、0から1の率を分けます。

time zone

日付と時刻は、timezoneを確認します。UTC、JST、user local time、server timeが混ざると、日別集計がずれます。

特に月末、深夜、キャンペーン開始日、SLA、障害時間帯の分析では、timezoneが重要です。

欠損と重複を分ける

項目	内容	見方
Missing		欠損。
Duplicate		重複。
Outlier		外れ値。
Invalid		不正。

欠損、重複、外れ値は、それぞれ別の扱いにします。

欠損、重複、外れ値、不正値は、別々に扱います。全部を「汚いデータ」とまとめると、判断を誤ります。

Codexには、集計前にdata quality summaryを出させます。

missing

欠損は、空欄、null、N/A、-、unknownなどです。欠損が0を意味する場合もあれば、未入力を意味する場合もあります。

欠損を勝手に0で埋めると、平均や合計が変わります。補完するなら、補完理由を残します。

duplicate

重複は、完全重複と意味的重複に分けます。同じ行が2回あるのか、同じ注文が複数itemに分かれているのかで扱いが違います。

Codexには、重複keyを明示させます。id、email、order_id、timestampなど、どの列を見て重複と判断したのかを残します。

outlier

外れ値は、異常とは限りません。高額注文、大量アクセス、長時間session、特別な契約など、実データとして正しい場合があります。

外れ値を消す前に、分析目的と影響を確認します。

集計前に型をそろえる

Number

数値。

Date

日付。

Text

文字。

Category

分類。

型が揺れたまま集計すると、見た目は正しくても数字がずれます。

型が揺れたまま集計すると、数字がずれます。数値、日付、文字列、カテゴリをそろえます。

CSVでは、見た目は数字でも文字列として読まれていることがあります。カンマ、通貨記号、全角数字、空白、単位付き文字列が混ざるからです。

number

数値列では、桁区切り、通貨記号、負数、空欄、単位を確認します。

1,200、¥1,200、1200円、-、(1200)のような値は、そのままでは集計できない場合があります。

date

日付列では、format、timezone、日付だけか時刻付きかを確認します。

2026/06/01、06/01/2026、2026-06-01T00:00:00Zは、見た目が似ていても解釈が違います。

category

カテゴリ列では、表記ゆれを確認します。paid、Paid、PAID、有料、契約中が同じ意味なら、正規化が必要です。

ただし、勝手にまとめないようにします。カテゴリの統合は、分析目的に影響します。

localeで崩れる値

localeは、地味に効きます。日付、通貨、小数点、桁区切り、文字コード、改行コードが崩れることがあります。

Codexには、locale由来の怪しい値をsampleで出させます。全件変換の前に、数件を人間が確認します。

Codexに渡す質問を絞る

One

1問。

Filter

範囲。

Metric

指標。

Format

出力。

質問を小さくすると、Codexの集計を人間が追えます。

表データに対する質問は、小さくします。「このCSVから重要なことを全部教えて」では広すぎます。

Codexには、1回に1つの質問を渡します。対象期間、filter、metric、grouping、出力形式を決めます。

single question

質問は1つにします。

悪い例:

このCSVを分析して、売上の変化と顧客傾向と異常値と改善案を出して。

よい例:

2026年5月のpaid plan usersについて、週別のactive user数を集計し、前週比が大きく変わった週を3つまで出してください。

filter

filterを明示します。期間、対象plan、地域、status、除外するtest data、内部accountを決めます。

filterが曖昧だと、Codexはそれらしい範囲で集計します。結果は整って見えても、意図と違うことがあります。

expected output

出力形式も決めます。Markdown table、CSV、短いsummary、chart用データ、SQL、Python notebook風の手順などです。

人間が検算しやすい形式を選びます。

集計結果を検算する

項目	内容	見方
Rows		件数。
Totals		合計。
Sample		抜粋。
Script		再現。

結論だけでなく、そこへ至る件数と式を確認します。

Codexが出した集計結果は、必ず検算します。row count、subtotal、sample、再現手順を見ます。

検算は、AIを疑うためだけではありません。dataの前提をチームで共有するためです。

row count

まず件数を確認します。raw rows、filter後rows、groupごとのrowsを見ます。

たとえば、rawが10,000行、filter後が1,200行、集計対象が1,198行なら、2行がなぜ落ちたのかを確認します。

subtotal

subtotalで合計を確認します。group別合計と全体合計が一致するか、欠損や除外が入っていないかを見ます。

金額や件数の集計では、subtotalが強い検算になります。

sample

sampleで数件を目視します。上位3件、外れ値、欠損、境界日付、カテゴリ統合後の代表例を確認します。

sampleが説明と合っていないなら、集計式を見直します。

レポートに残すこと

項目	内容	見方
Method		方法。
Assume		前提。
Limit		限界。
Files		成果物。

レポートには、数字だけでなく作り方と限界も残します。

レポートには、結論だけでなく、method、assumptions、limitations、files、checksを残します。

きれいなグラフやsummaryだけでは、後から判断できません。どのfileを使い、どんな前提で、何を除外し、どう検算したかが必要です。

method

methodには、読み込んだfile、使った列、filter、grouping、計算式を書きます。

CodexがPythonやSQLを使ったなら、主要な処理を残します。

assumptions

assumptionsには、仮定を書きます。timezone、欠損扱い、test account除外、カテゴリ統合、重複keyなどです。

仮定が多いほど、結論の強さは下がります。

limitations

limitationsには、分からなかったことを書きます。列定義が未確認、特定期間が欠けている、手元のexportが古い、外れ値の理由が不明などです。

限界を書くと、レポートが弱く見えるのではなく、判断しやすくなります。

よくある失敗

Raw edit

原本変更。

No schema

列不明。

One pass

検算なし。

Pretty only

見た目だけ。

表データは、きれいなグラフより先に数字の出どころを見ます。

よくある失敗は、原本を直接編集する、列名だけで意味を決める、欠損を0にする、重複を勝手に消す、日付timezoneを見ない、検算しない、見た目のよいグラフだけ出すことです。

原本を直接編集すると、後で戻れません。列名だけで判断すると、意味を取り違えます。欠損を0にすると、平均や合計がずれます。

重複は、削除してよいとは限りません。日付timezoneは、日別や月別集計で結果を変えます。

検算なしのレポートは、説得力が弱いです。見た目のよいグラフも、元の数字が間違っていれば危険です。

個人情報を含むCSVをそのまま渡す

CSVには個人情報が入りやすいです。email、氏名、住所、電話番号、free text、問い合わせ本文、契約情報、支払い情報が混ざることがあります。

Codexに渡す前に、必要な列だけに絞り、匿名化や集計済みデータを使います。

結論だけ先に作る

AIは、結論をきれいにまとめるのが得意です。だからこそ、結論の前に、row count、filter、subtotal、sampleを確認します。

結論が先にあると、数字を都合よく読んでしまうことがあります。

FAQ

項目	内容	見方
Excel?		可。
個人情報?		伏せる。
大容量?		分割。
可視化?		検算後。

迷ったら、原本を守り、問いを小さくするところへ戻します。

Excelファイルでも同じですか？

基本は同じです。複数sheet、数式、非表示列、結合セル、format、pivot tableがある分、CSVより確認点は増えます。

個人情報を含むCSVは使えますか？

原則として、必要な列だけに絞り、匿名化や集計済みデータにします。顧客名やemailが不要なら削ります。

大きいCSVはどう扱いますか？

まず件数、列数、file sizeを確認します。必要ならsample、chunk、database、duckdb、pythonなどで分けます。大容量のまま全文を貼りません。

可視化はいつ作るべきですか？

検算後です。まず集計表とsampleを確認し、数字が正しいと分かってからchartやslideにします。

Codexに何を報告させるとよいですか？

結論、使ったfile、filter、row count、集計式、検算結果、未確認項目、次に見るべきdataを報告させます。

参照した主な情報源

• Codex Use Cases – OpenAI Developers
• Codex use cases – OpenAI Developers
• Codex app features – OpenAI Developers
• Permissions – Codex – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

次に読むなら

更新履歴

1. 2026.06.01

   初版。

Codexのdata系use casesは、導入時に公式docsで見直します。

• 2026年6月1日: OpenAI公式Codex Use Cases、Codex app features、Permissions、AGENTS.md docsを確認し、初版を作成しました。