公式サイトからダウンロードしたCSVをAIツールに読ませたのに、「0件です」と返ってくる。ファイルは確かに開けるし、中身も見える。なのに、なぜ1行も読めないのか。
壊れているのは、たいていファイルではありません。読む側の思い込みです。
⚠️ この記事の情報は2026年8月時点のものです。筆者のこのデータ収集は相場を観測・研究するためのもので、取得は読み取りのみ（read-only）です。実際のお金での発注はしていません（仮想発注のみ・実発注なし）。内容は確認でき次第、随時更新します。
この記事で分かること
「AIに任せたのに動かない」で止まっている人向けです。日本語のCSVは、海外製のツールやサンプルコードが前提にしている形と、地味にズレます。
- 症状（エラー文・0件・文字化け）から原因を引く早見表
- 原因ごとの確認手順と、やってはいけない直し方
- AIに「完了」と言わせてから、実データで崩れた実録の時系列
先に結論。筆者が実際につまずいた原因は、次の5つでした。①文字コードがShift_JISのまま ②列名が英語版ファイル前提 ③区分や年限の列名が日英で違う ④和暦が混ざっている ⑤実データを一度も流していない。日本語CSVが読めないときに最初に疑う候補として使えます（これで全部というわけではありません）。
筆者は財務省が公表している国債金利のCSV（公的統計）を題材に、このうち②〜⑤を実際に踏み抜きました。①の文字コードだけは踏み抜いていません。読み込み側にcp932を第一候補として試す実装が先に入っていたため、今回は失敗になりませんでした（入っていなければ、おそらく最初にここで止まっていました）。以下は自分の環境での記録であり、「この手順なら必ず読める」と保証するものではありません。
【早見表】症状から原因へ
この表は筆者が実際に踏んだものだけでなく、日本語CSVで起こりうる症状をまとめた確認用の一覧です（筆者が経験していない症状も含みます）。
| 症状 | 疑う原因 | 最初に見る場所 |
|---|---|---|
| 日本語が「?」や記号の羅列になる | 原因1 文字コード（Shift_JIS） | 読み込み時の文字コード指定 |
| 「ヘッダー行が見つからない」で止まる | 原因2 列名が英語版前提 | ファイル1〜2行目の実物 |
| 読めるが数字が別の列とすり替わる | 原因3 列名の部分一致 | 列の照合が完全一致か |
| 日付だけ空・0件になる | 原因4 和暦（R8.8.3など） | 日付列の表記 |
| サンプルでは動いたのに本番で0件 | 原因5 実データ未投入 | 実ファイルを1回流したか |
原因1 文字コードがShift_JISのまま
日本の官公庁や証券会社が配るCSVは、いまもShift_JIS（Windows拡張版はcp932）で配られることがあります。ツール側はUTF-8を既定にしていることが多いので、そのままだと日本語が読めません。
筆者が取得した財務省のCSVも、文字コード（character encoding）はshift_jisでした。取得時の記録はHTTP 200、リダイレクトなし、content-typeはtext/csv、サイズ661バイト。これは自分の環境で1回だけ取得したときの実測値です。
確認手順
- CSVをメモ帳ではなくVS Codeなどで開き、画面右下の文字コード表示を見る
- Excelでダブルクリックして開けるのに、AIツールで化けるならShift_JISを疑う
- 読み込み側で候補を順に試す設計にする（筆者の実装はcp932→UTF-8（BOM付き）→UTF-8の順）
やってはいけない直し方
化けた文字を手作業で置換して「直った」ことにするのは避けてください。次に同じファイルを取り直した瞬間、また化けます。直す場所は、ファイルではなく読み込みの設定です。
なお筆者の場合、この対策は先に入っていたため文字化けは起きませんでした。ここで書いているのは「起きなかった理由」です。
原因2 列名が英語版ファイル前提になっている
同じ統計に、英語版ファイルと日本語版ファイルの両方が用意されていることがあります。AIが書いたコードは、たいてい先に見た方の形に合わせて作られます。
実例
筆者のコードは、ヘッダー行（列名が並ぶ行）を「1列目にdateまたは年月日が入っている行」で探していました。ところが日本語版ファイルの実物は、1列目が「基準日」。
結果は、CsvFormatError「ヘッダー行が見つからない」で処理が止まり、取り込み件数は0件。ファイルは正しく開けていて、日本語も読めていて、それでも1行も解釈できませんでした。
確認手順
- 実ファイルの先頭5行をそのまま目で見る（1行目がタイトル行で、列名は2行目ということがある）
- AIに「このファイルの列名を1行目から順に列挙して」と頼み、コードの想定と突き合わせる
- 英語版と日本語版のどちらを読むつもりなのか、URLの単位で決めておく
筆者が読んだファイルは、1行目に「国債金利情報（令和8年8月）」というタイトル行、2行目に「基準日,1年,……,40年」という列名行が入っていました。1行目だけ見て判断すると、列名を見つける前に諦めることになります。
原因3 区分・年限の列名が日英で違う
列名の言語差は、ヘッダー行だけの問題ではありません。取り出したい列そのものの名前も変わります。
筆者の場合、欲しい列を「10Y」という英語表記で探していました。日本語版の実物では、その列の見出しは「10年」。名前が違えば、当然見つかりません。
部分一致だと取り違う＝完全一致で判定する
ここは実際に間違えたところではなく、間違えかけて踏みとどまったところです。「10年という文字を含む列を探す」という書き方（部分一致）にすると、「1年」や「10年」を並べた表では、意図しない列を拾う余地が生まれます。
読めないエラーはすぐ気づきます。一方、間違った列を読めてしまうエラーは、気づきにくいのが厄介です。
そこで筆者は、もともと完全一致だった照合はそのままに、受け付ける列名の候補へ「10年」を足すだけにしました（候補は「10Y」「10」「10年」の3つ）。エラーを消したくて「含む」「始まる」へ緩める誘惑がありますが、そこは緩めない、というのがこのときの判断です。AIにコードを書かせるときも、「列名は完全一致で判定して」と最初に言い切るほうが安全です。
原因4 和暦が混ざっている
日付列が「R8.8.3」。一般的な日付処理は西暦を前提にしているため、この表記はそのままでは解釈されず、空欄やエラーになることが多いです（和暦に対応した専用ライブラリを使う手もあります）。
筆者の実装では、元号の頭文字と「元年に対応する西暦マイナス1」の対応表を持たせ、令和1年＝2019年として西暦に変換するようにしました。R8.8.3なら2026-08-03です。西暦表記（2026/8/5など）はこれまでどおり読めるままにしてあります。
推測させず、空のまま止める
対応表にない元号記号が来たら、変換せずに「日付なし」を返す設計にしました。あり得ない日付（存在しない月日）も同じです。読めないものを、それらしい日付に仕立てない。
これは安全側に倒す（fail-closed）という考え方です。空欄は後から気づけますが、それっぽく埋まった間違いは誰も見直しません。
原因5 実データを1回も流していない
ここまでの4つは、実データを一度流せば表面化するものばかりでした。逆に言えば、流さないかぎり気づく機会がありません。筆者の場合は、実収集が失敗してから修正が終わるまでが記録上5分でしたが、誰でも5分で終わるという意味ではありません。
「サンプルで動いた」は動作確認ではない
筆者はこの日、公式URLの取得確認を済ませ、この収集まわりの自動テストも209件すべて通っていました。それでも実データを流すと0件でした。
テストが通っていたのは、テストが英語版の形を前提に書かれていたからです。想定が間違っているとき、テストは想定ごと間違えます。
非エンジニアにも使える判定基準はひとつ。本物のファイルを1回流して、1件以上まともに出たか。出ていないなら、まだ何も確認できていません。
実録：「完了」の直後に自分で撤回した日の時系列
2026年8月9日の午後、記録に残る3つのコミットの話です。
公式URLの取得は実測できていた
14:50。財務省の公式CSVのURLを確定し、認証情報なしの読み取りのみで1回だけ取得。HTTP 200、リダイレクトなし、文字コードshift_jis、661バイト、更新日時あり。取得回数は1回に抑え、運用上の上限も1日1回と自分で決めて記録しました。公表されている制限値は不明なので、勝手に数字を作らず「不明」と書いています。
ここまでは事実として成立していたので、タスクを「完了」にしました。
本物を1回流したら0件・完了宣言を撤回
14:53。運用の証跡を取るつもりで実収集を1回走らせたところ、結果はFAILED、取り込み0件。エラーはヘッダー行が見つからない。原因は前述のとおり、「基準日」と「10年」を知らないパーサでした。
3分前の「完了」を、同じ日のうちに取り消しました。進捗の数字も元に戻しています。
詰まった箇所と回避策
14:58。修正はファイル1つ・3箇所だけ。ヘッダー判定に「基準日」を追加、年限の列名に「10年」を完全一致で追加、和暦の変換を追加。英語版の西暦形式が壊れていないことも同時にテストで固定しました。
回避策として効いたのは、外部に取りに行き直さず、保存してあった取得済みの原本を使って直したことです。修正のたびに公式サイトを叩けば、相手に迷惑をかけます。
再実行の結果は成功、取り込み4件。合成データではなく実物をそのまま回帰テスト用に保存し、日本語形式・和暦・列の取り違え・未知の元号・英語版非破壊を12件のテストで固定しました。この収集まわりのテストは221件すべて成功。なお、この収集は観測・研究用で自動発注はしません（read-only）。実際のお金での発注もしていません（仮想発注のみ・実発注なし）。
撤回した記録は消さず残した
間違った「完了」の記録は削除せず、撤回済みの印をつけて保持し、やり直した分は別の記録として追加しました。上書きしていたら、この記事は書けていません。
よくある失敗
- AIの「完了しました」をそのまま信じる。AIが確認したのは、たいていAIが確認できた範囲だけ
- エラーが出た列を、とりあえず部分一致にして通す。読めた気になるのがいちばん危ない
- 読めない日付を「たぶん今年」で埋める。あとから誰も検算できない
- 直すたびに公式サイトへ取りに行く。手元に原本を1つ保存してから直す
- 失敗した記録を消してやり直す。同じ原因を来月もう一度調べることになる
非エンジニアが得た教訓
この日いちばん効いたのは、技術の知識ではなく「完了の定義」を自分で決めていたことでした。
- 完了の条件は「実データで1件以上出たか」。URLが取れた、テストが通ったは途中経過
- 日本語ファイルのズレは、文字コード・列名・日付表記の3系統に整理できる（本文の原因1〜4がこれにあたり、原因5は確認手順の話）。この順に疑う
- 照合は完全一致。曖昧な一致は、静かに間違った答えを出す
- 読めないものは空のまま止める。埋めた瞬間、誤りが見えなくなる
- 撤回は失敗ではなく記録。残しておくと、同じ穴を二度掘らない
AIが書いた数式や計算そのものを点検する話は、AIが生成した数式のチェック方法で別に整理しています。この記事は「読ませるファイル側」の話でした。
まとめと次に読む
日本語CSVが読めないときは、①文字コード ②列名が英語版前提 ③年限などの列名の日英差（部分一致による取り違え）④和暦 ⑤実データ未投入 の5点を、この順に見る。早見表を上から当てはめれば、どこで止まっているかは絞れます。
ただし、ここに書いたのは筆者の環境で起きたことの記録です。同じ手順で必ず読めるようになるとは限りません。原因が分からないうちは、推測で埋めずに止めておくほうが安全です。
次にやるなら、手元の読めないCSVを1つ選び、先頭5行をそのまま目で見るところから。
関連記事
- AIが生成した数式のチェック方法（AIが書いた計算式そのものを点検する側の話）
- マーケットスピード2 RSSの使い方（Excelで相場データを扱う前提の整理）
- AI開発でやりがちな失敗（「動いたつもり」を防ぐ考え方）
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年8月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント