AIに読ませる財務データの作り方｜PDF・Excel・CSV・XBRLの作り分けと前処理

結論：AIの財務データ誤読は、モデルの性能より「渡した表の構造」で決まります

生成AIに決算資料の表を読ませて、合計が合わない、桁が1,000倍ずれる、赤字が黒字として集計される。こうした事故の多くは、AIの読解力ではなく渡した表そのものが機械可読になっていないことが原因です。日本の財務資料は、印刷して人が読むことを前提に作られています。結合セル、2段組みのヘッダー、表の外に置かれた「単位：百万円」、負数の「△」、和暦の期間表記。これらはすべて人には親切で、機械には情報が欠けている状態です。

本記事の立場は明確です。プロンプトを磨く前に、データ側を直す。整備には決まった順番があり、順番を守ると手戻りが減ります。①原資料を特定する→②表を抽出する→③構造を正規化する→④単位と符号を正規化する→⑤人が検証する→⑥AIへ投入して出力を照合する、の6工程です。この記事では、7つの誤読パターンを「原因＝データ側の何が悪いか」と「直し方」の対で示し、架空企業の設例で整える前と後で集計結果がどれだけ変わるかを数値で確認します。

なお機械可読なデータの作り方については、総務省が政府統計向けに「統計表における機械判読可能なデータの表記方法の統一ルール」を公表しており、1セル1データ・セルの結合をしない・単位を記載する・和暦に西暦を併記する、といった項目が示されています（令和2年12月18日公表。出典は末尾）。これを財務データとAI利用の文脈に翻案した部分は編集部の提案であり、政府統計の規則が企業の財務資料にそのまま適用されるわけではありません。

全体像：AI-readyデータ整備の6工程

工程3と工程4を分けているのには理由があります。構造の欠陥（結合セル・2段ヘッダー）は列と値の対応そのものを壊すのに対し、表記の欠陥（△・全角・単位）は対応は保たれたまま値だけが間違うためです。前者は先に直さないと、後者を直しても直す対象がずれます。順番を逆にすると、整形済みのつもりの表で列がずれている、という最も見つけにくい事故が起きます。

この記事の守備範囲：「渡し方」ではなく「渡す前」

AI活用の工程は、大きく「データを整える」「AIに渡す」「出力を検証する」に分かれます。本記事は最初の1つだけを扱います。重複を避けるため、隣接する論点は既存記事に委ねます。

言い換えると、本記事が答えるのは「どの形式で渡すか」を決める前に、渡す表をどう作るかです。同じPDFでも、載っている表が機械可読かどうかで結果は変わります。

AIが財務データを誤読する7パターンと、データ側の原因

以下は、日本の決算資料・社内Excelで実際によく見かける構造上の問題を、症状（AIの出力にどう現れるか）から整理したものです。症状と原因の対応づけは編集部の整理であり、特定のAI製品での実測結果ではありません。

変換前後の対比：架空企業「北浜精密工業」のセグメント表

架空の上場企業「北浜精密工業株式会社」の2025年3月期セグメント情報を題材に、整える前後で何が変わるかを確認します。単位はすべて百万円です。

整える前（原資料をそのままコピーした表）

単位：百万円　←この行が表の外にあります

※1 計測器事業には、令和6年3月期に実施した生産拠点再編の影響が含まれています。

この表には、先ほどの7パターンのうち5つが同時に入っています。(a) 単位が表の外、(b) 2段ヘッダーと結合セル、(c) 負数の△表記、(d) 和暦の期間表記、(e) 合計行が明細行と同じ列に同居。さらにセグメント名に脚注記号「※1」が同居しています。

整えた後（縦持ち・1行ヘッダー・単位列つき）

列の役割は、period_end＝期間（ISO形式）、segment・item＝何の何か、unit＝単位、value＝半角数字だけの値、row_type＝明細か合計かの区別、note＝脚注や換算の記録です。実務では source 列（例：「2025年3月期有価証券報告書 p.32 セグメント情報」）も付けます。1行を見るだけで意味が確定するため、AIが前後の行や表外の記述を推測する余地がなくなります。

整えないまま渡すと、集計はどれだけずれるか

ここでは「△85 を負数と解釈できず +85 として扱った場合」に何が起きるかを計算で示します。実際にAIへ入力して測定したものではなく、その誤読が発生した場合の影響を機械的に計算したものです。

検算します。正しい合計は 1,305 +（-85）+ 110 ＝ 1,330。原資料の合計行 1,330 と一致します。△を無視した場合は 1,305 + 85 + 110 ＝ 1,500、差は 170（＝ 85 × 2）です。営業利益率は 1,330 ÷ 20,580 ＝ 6.46%（≒6.5%）に対し、1,500 ÷ 20,580 ＝ 7.29%（≒7.3%）で、差は約0.8ポイント。前期の計測器は △210、当期は △85 ですから、正しくは赤字幅が 125 縮小した改善ですが、△を無視すると 210 → 85 で 125 の悪化に見えます。金額の誤差より、方向の反転のほうが実務上は深刻です。

もう1つ、単位の誤読も見ておきます。「単位：百万円」が表外にあり、AIが単位を「円」と解釈した場合、売上高合計は 20,580百万円（約205.8億円）ではなく 20,580円になります。桁が100万倍ずれますが、表の中だけを見ている限り矛盾がないため、出力は自信満々に返ってきます。単位を列で持たせるべき理由はここにあります。

命名と粒度の規約：列名・1セル1値・縦持ち／横持ち

整備を毎回その場の判断でやると、担当者ごとに違う表ができ、AIに渡すたびにプロンプトを書き直すことになります。先に規約を決めて紙1枚にしておくのが最も効きます。以下は本記事が提案する最小構成です。

列名の付け方

• 1列＝1つの意味。「売上高（百万円）2025年3月期」のように項目・単位・期間を1つの列名に詰め込まない。項目は item、単位は unit、期間は period_end と別の列に分ける
• 列名は半角英小文字とアンダースコア（period_end, row_type, value）。日本語列名でも動きますが、後でPythonやSQLに渡すときに引用符が必要になり事故が増えます（Pythonでの取得・整形を併用する場合は特に）
• 同じ意味の列は全社で同じ名前にする。ある表では segment、別の表では 事業部門、では横断できません

列名の統一は、財務モデルの参照ルールや科目体系の設計と地続きの話です。モデル側の作法をあわせて整えたい場合は講座一覧もご覧ください。

1セル1値とTidy形式

1つのセルに「1,234（前年比+3.2%）」のような複合値を入れないこと、階層をインデントの空白で表現しないことが基本です。そのうえで、財務データは縦持ち（long / Tidy形式）を既定にすることを勧めます。縦持ちとは、1行が「1つの観測値」になる形（つまり period_end / segment / item / unit / value が揃って初めて1行）、という持ち方です。

期間の粒度

期間は「いつからいつまでか」と「どの粒度か」の2つを持たせます。period_end（2025-03-31）だけでは、通期なのか第4四半期なのか累計なのかが判別できません。period_type（full_year / q4 / ytd）を必ず併記します。決算期変更で12か月でない期間がある場合は、months 列（例：15）を足し、年換算の要否を人が判断します。年換算のルールそのものは横断比較の論点なので、複数企業・複数年度の横断比較で扱います。

形式別の作り分け：どの形でAIに渡すか

データを整えたあと、どの形式で保存・提出するかで、伝わる情報が変わります。以下の評価は編集部の整理（本記事の提案）であり、製品ごとの対応可否は各社の公式情報をご確認ください。

実務上の落とし所は、数値分析は値のみCSV、20行程度までの小さな表はMarkdown、原本照合はPDFという併用です。Excelファイルをそのまま渡すのは、モデルのレビュー依頼のように数式の構造を見せたい場面に限るのが安全です。往復させる場合の受け渡し方式は再現可能な受け渡しワークフローで整理しています。

XBRL・EDINETのCSV変換ファイルの扱い

EDINETは有価証券報告書等をXBRL形式で受け付けており、書類取得APIでは必要書類コード「5」を指定することで、提出書類のXBRLデータをCSV形式に変換したファイル（ZIP形式）を取得できると規定されています（金融庁「EDINET API仕様書（Version 2）」）。このCSVは要素ID／項目名／コンテキストID／相対年度／連結・個別／期間・時点／ユニットID／単位／値の9項目が1行目の見出しとして出力される、と金融庁「書類閲覧操作ガイド」（2026年6月）に記載されています。

注目すべきは、この構造がすでに縦持ちで、単位と期間が列として付いている点です。本記事が整備の目標としてきた形を、EDINET側が最初から提供しているわけで、手作業で表を写すより誤りが少なくなります。

ただし、そのまま横断比較に使えるわけではありません。金融庁「EDINETタクソノミの概要説明」には、「EDINETタクソノミには、各様式の報告に必要な標準的な記載項目が定義されていますが、開示書類等提出者は、提出しようとする提出書類によって、開示に必要な項目を取捨選択したり、必要に応じて適宜追加（拡張）したりできます。この拡張されたタクソノミのことを『提出者別タクソノミ』といいます」と説明されています。つまり企業ごとに独自の要素が存在しうるため、要素IDをキーにN社を単純に突き合わせると、同じ概念が別IDに散る／別概念が同じ名前で並ぶといったことが起きます。この正規化は横断比較の記事で扱う領域です。

技術的な注意点も1つ。同ガイドによれば、XBRLからのCSV変換ファイルは拡張子が「csv」ですが区切り文字はタブ、文字コードはUnicode（UTF-16LE）、改行コードはCRLFで、各項目はダブルクォーテーションで囲まれています。UTF-8のカンマ区切りだと思って読み込むと、1列に全部入る・文字化けする、という形で最初に躓きます。値が30,000文字を超える場合は30,000文字までの出力になる旨も記載されているため、長文の記述項目をそのまま分析対象にするときは注意が必要です。

AIに任せる範囲と、人が判断する範囲

境界の引き方の原則はシンプルです。機械的な置換はAI、意味の判定は人。「△を−に置き換える」は機械的ですが、「この行は小計か明細か」は資料の文脈を読む判断であり、間違えると二重計上に直結します。

プロンプト例：原資料の表を整形CSVに変換させる

整形そのものをAIに手伝わせるときのプロンプトです。出力形式・単位・符号・禁止事項・不明時の処理・出典・検算まで指定します。プロンプト設計の一般論は金融実務のためのプロンプトエンジニアリングにまとめています。

【役割】あなたは日本の開示資料を扱う財務データ整備の担当者です。分析・解釈・示唆出しは行いません。
【目的】以下に貼り付けた表を、機械可読な「縦持ち・1行ヘッダー」のCSVに変換してください。

【入力】北浜精密工業 2025年3月期 有価証券報告書 p.32「セグメント情報」の表テキスト
（ここに表をそのまま貼り付ける）

【出力形式】次の列のCSV（UTF-8・カンマ区切り・1行目にヘッダー）。列の追加・削除・並べ替えはしないこと。
company,period_end,period_type,months,segment,item,unit,value,row_type,note,source
- period_end：ISO形式 YYYY-MM-DD。和暦は西暦に変換する（令和7年3月期→2025-03-31）。
- period_type：full_year / q1 / q2 / q3 / q4 / ytd のいずれか。
- months：対象期間の月数（通常12）。
- unit：「百万円」に統一する。原資料が千円・億円の場合は換算し、換算した旨を note に記載する。
- value：半角数字のみ。カンマ・通貨記号・単位・空白を含めない。負数は先頭に半角マイナスを付ける。
  原資料の「△」「▲」「(123)」「（123）」はすべて負数として扱う。
- row_type：detail / subtotal / total のいずれか。小計行・合計行を明細行と混在させない。
- note：脚注記号の内容、単位換算、端数処理を記載する。数値セルには入れない。
- source：「書類名 p.ページ 表名」の形式で各行に記載する。

【計算方法】原資料に記載のない数値を計算・補完しない。合計は原資料に記載がある場合のみ転記し、
記載がなければ value を空欄にして note に「原資料に記載なし」と書く。

【禁止事項】値の推定・四捨五入・単位の暗黙変換をしない。原資料にない行や列を作らない。
セグメント名を勝手に統一・省略しない（脚注記号は名称から外し note に移す）。

【不明情報の処理】判読できないセルは value を空欄にし、note に「判読不能」と理由を書く。推測で埋めない。

【出典表示】各行の source を必ず埋める。複数ページにまたがる場合は該当ページを列挙する。

【検算】CSV出力のあとに、次の3点を自分で確認し結果を箇条書きで報告してください。
1) row_type=detail の value の合計と、原資料の合計行の値が一致するか（一致しない場合は差額を示す）
2) 負数として扱ったセルの一覧（原資料の表記 → 変換後の値）
3) 単位換算を行った行の一覧（換算前の値・倍率・換算後の値）

【レビュー項目】最後に、人間が確認すべき点を3つまで挙げてください（判定に迷った行とその理由）。

このプロンプトの要点は、AI自身に検算結果を出力させたうえで、その検算を人が再確認する二段構えにしていることです。AIの自己申告を信じるのではなく、差額が示されたセルだけを人が集中的に見るための材料として使います。

整備結果の検証方法

AI出力の検証一般（ハルシネーションの見抜き方、数値照合の型）は生成AI出力の検証手順に譲り、ここではデータ整備という工程に固有の検証項目だけを挙げます。いずれも「式で機械的に確認できるもの」を優先しています。

1. 合計の再計算：row_type=detail の value を合計し、row_type=total の値と一致するか。一致しない場合、差額が特定の1セルで説明できるか（説明できれば転記ミス、できなければ構造の取り違え）
2. 符号の一覧照合：負数になった行を全件抜き出し、原資料の△・▲・括弧書きと1対1で対応するか。負数の件数が原資料より少なければ、必ずどこかで符号が落ちています
3. 行数・列数の一致：原資料の明細行数 × 項目数 ＝ 出力行数か。合わない場合、脱落か重複がある
4. 単位換算の逆算：換算した行について「換算後 ÷ 倍率 ＝ 換算前」を確認する
5. 期間の単調性：period_end が想定した期末日のみで構成されているか。決算期変更がないのに月数が12以外になっていないか
6. 抜取照合：無作為に5〜10セルを選び、原資料の該当ページを開いて目視で突き合わせる。選ぶのは人（AIに選ばせると整合が取れている箇所を選びがちです）
7. 空欄率とnoteの整合：value が空欄の行に、必ず理由がnoteに書かれているか

1〜5は式で自動化できるので、Excelの検算セルやPower Queryのステップに組み込み、毎回自動で走る状態にしておくのが現実的です。手作業で毎回やると必ず省略されます。

機密情報・個人情報の注意

データ整備の工程は、機密情報が最も混入しやすい局面です。社内Excelには、分析に不要な別シート、非表示行、コメント、顧客名や従業員個人が特定できる明細が残っていることが珍しくありません。整形の前に、渡す列・行を必要最小限に絞り、不要なシートとコメントを削除してから作業してください。「整えてから絞る」順序にすると、絞る前の原本を投入してしまう事故が起きます。どの情報を外部サービスに入力してよいかの線引きと社内ルールの作り方は生成AIに入れてよい情報・いけない情報を参照し、必ず自社の規程に従ってください。

よくある失敗

• 書式設定だけ直して満足する：セルの表示形式で「△」を消しても、中身が文字列のままなら計算はできません。値そのものを数値属性に直す必要があります。総務省のルールでも、数値データに文字列（円、▲、カンマ）を含めないことが求められています
• 合計行を残したままAIに集計させる：明細と合計が同じ列に並んでいると、合計を含めて足し算され、金額がちょうど2倍前後になります。ぴったり2倍でないため気づきにくいのが厄介です
• 整形をAIに任せて検算しない：整形は機械的な作業に見えますが、判読困難なセルや小計判定では判断が入ります。検算のない整形は、原資料より信頼できないデータを作る作業です
• PDFのコピペで列が壊れていることに気づかない：2段組みや罫線のないPDFからコピーすると、数字が別の行に混ざることがあります。行数と合計を確認するまで、コピペ結果を信用しないでください
• 毎回その場で整形する：同じ月次資料を毎月手作業で整えていると、担当者ごとに違う表ができます。列名と変換ルールを固定し、クリーニング手順を定型化してください

実務チェックリスト：AI-readyデータ整備15項目

• 1シートに1つの表だけになっているか。1行ヘッダーで、結合セルはゼロか
• 1セルに1つの値だけか（「1,234（前年比+3.2%）」のような複合値がないか）
• 見出しの空白・改行・インデントで階層を表現していないか（階層は独立した列にしたか）
• 「〃」「同上」「空欄で前行と同じ」といった省略を残していないか
• 数値セルに単位・通貨記号・カンマ・全角数字・空白が混ざっていないか
• 負数を半角マイナスに統一したか（△・▲・括弧書きをすべて変換したか）
• 単位を独立した列（unit）で持たせたか。千円・百万円・億円が混在する場合、換算列と換算記録を作ったか
• 期間を西暦のISO形式（2025-03-31）で持たせ、和暦は併記に留めたか
• 期間の粒度（period_type）と月数（months）を列で明示したか
• 小計行・合計行に行区分列（detail／subtotal／total）を付けたか
• 脚注記号（※1、*、注3）を数値セル・名称セルから分離し、note列へ移したか
• 機種依存文字（㈱、①、Ⅰ、№ など）と全角英数を、半角・正式表記に置換したか
• 各行に出典列（書類名・ページ・表名）を付けたか
• 整備後の表で「明細の合計＝小計」「小計の合計＝合計」が再計算で一致したか
• 機密区分を確認し、渡す列・行を必要最小限に絞ってから作業を始めたか

日本企業・日本市場での留意点

• 和暦：「令和7年3月期」のような表記は、元号が変わると機械側の変換規則を更新する必要があります。総務省の統一ルールでも、時間軸は西暦表記か、和暦への西暦併記が求められています。社内資料でも西暦の期末日を正とし、和暦は表示用に留めるのが安全です
• △と▲：どちらも負数を表す表記として使われます。総務省の資料では▲が例示され、開示資料では△が多く見られます。両方を変換対象にしておく必要があります
• 決算期の多様性：3月期以外の企業、決算期変更で12か月でない期がある企業があります。months列を持たせないと、期間の長さの違いが見えなくなります
• 単位の混在：同じ資料内で、本表が百万円、注記が千円ということがあります。表単位ではなく行単位で単位を持たせてください
• 文字コード：EDINETのXBRL変換CSVはUTF-16LEのタブ区切り、EDINETコードリストはShift_JISのカンマ区切りと、公式ガイドに記載されています。取り込み時に形式を指定しないと文字化けします
• 機種依存文字：「㈱」「№」「①」「Ⅲ」などは環境によって表示が崩れることがあります。社名は「株式会社」と正式表記に置換しておくと、名寄せの精度も上がります

よくある質問（FAQ）

Q. 紙をスキャンした画像PDFしかない場合、どこから手を付ければよいですか

画像PDFは工程2（抽出）以前の問題なので、まず文字にする必要があります。OCRを使う場合は、数字の誤認識（0と6、1と7、△と全角ハイフンなど）が構造の問題とは別の誤りとして加わる点に注意してください。対策は、OCR結果に必ず合計の再計算をかけることと、桁数が想定と違うセルを機械的に洗い出すことです。件数が少なければ手入力して2名で読み合わせるほうが速く確実な場合もあります。原本照合の観点は開示資料をAIで読む記事と併せてご確認ください。

Q. 整備のコストが分析の価値に見合わないときは、どう判断すればよいですか

判断軸は頻度 × 再利用回数 × 誤りのコストの3つです。一度きりの調査で、桁を間違えても影響が限定的なら、整備は最小限（単位・符号だけ直す）で構いません。毎月繰り返す、複数人が同じデータを使う、外部提出物の根拠になる。このいずれかに当てはまるなら、テンプレート化する価値があります。判断に迷う場合は、まず単位列と符号だけを直すのが費用対効果の高い最初の一歩です。この2つだけで、桁ずれと符号反転という影響の大きい2種類の誤りが消えます。

Q. 整えたデータを「そのままAIに全部渡す」のと「必要な部分だけ渡す」のはどちらがよいですか

本記事の立場は必要な部分だけです。理由は3つあります。第一に、無関係な行が多いほど、AIが別の行を参照して答える余地が増えます。第二に、機密の観点で、渡す範囲は小さいほど安全です（機密管理の記事参照）。第三に、渡した範囲が明確なほど、出力の検証範囲も限定でき、照合が現実的な作業量に収まります。縦持ちで蓄積しておけば、必要な行だけを条件で抜き出すのは容易です。

まとめ

AIに財務データを読ませるときの精度は、プロンプトより先に渡した表の構造で決まります。日本の財務資料に共通する問題は、結合セル・多段ヘッダー・表の外の単位・△表記・和暦・小計行の同居・脚注記号の同居の7つに整理でき、その大半は構造の正規化（工程3）と単位・符号の正規化（工程4）で潰せます。

整備の到達点は、period_end / segment / item / unit / value / row_type / note / source という1行を見れば意味が確定する縦持ちの表です。EDINETがXBRLから変換して提供するCSVは、すでにこれに近い形（要素ID・期間・単位・値が列で付く）になっており、手作業で写すより誤りが少なくなります。ただし提出者ごとの拡張要素があるため、横断比較にはさらに正規化が要ります。

最後に、整備を「終わったこと」にしないための最小要件は検算です。明細の合計と原資料の合計行が一致するか、負数の件数が原資料と合うか。この2つを毎回自動で回すだけで、影響の大きい誤りはほとんど検出できます。今日整えた1枚の表を、明日も使えるテンプレートに変えていってください。

出典・参考（2026-08-16確認）

• 総務省「統計表における機械判読可能なデータの表記方法の統一ルールの策定」（令和2年12月18日） soumu.go.jp／別紙「統計表における機械判読可能なデータ作成に関する表記方法」https://www.soumu.go.jp/main_content/000723626.pdf（1セル1データ、セルの結合、数値属性、単位の記載、和暦への西暦併記の各チェック項目を確認）
• 金融庁「EDINET API仕様書（Version 2）」（書類取得APIの必要書類コード5＝提出書類のXBRLデータをCSV形式に変換したファイル、ZIP形式） disclosure2dl.edinet-fsa.go.jp
• 金融庁「書類閲覧操作ガイド」2026年6月（XBRLからのCSV変換ファイルの出力9項目、タブ区切り・UTF-16LE・CRLF、値30,000文字の上限、EDINETコードリストのShift_JIS） disclosure2dl.edinet-fsa.go.jp
• 金融庁「EDINETタクソノミの概要説明」2024年11月（提出者別タクソノミ＝提出者が必要に応じて項目を追加（拡張）したタクソノミ） fsa.go.jp
• 本記事の設例（北浜精密工業）は架空のものです。形式別の評価、6工程の分け方、チェックリスト15項目は編集部が上記の一次資料を踏まえて構成した提案であり、公的な基準ではありません。AI製品の対応形式・ファイルサイズ上限等は各社の公式ドキュメントをご確認ください。

※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。