なぜXBRLはこうできているのか #5|AIは会社独自のタグを読めるのか――Apple 10-Kで試した三段階
議論参加:レン (初学者の視点で確認する読者) / サキ (財務報告の作成実務を知る担当者) / ユウ (XBRLタクソノミ設計者) / コウ (XML・JSON・データベース設計者) / ミユ (AIとデータ基盤を扱う技術者) / アオイ (財務データを利用する投資アナリスト) / ナオ (企業開示を検証するリサーチャー) / テツオ (一般読者向けの記事を点検する編集者)
Appleの2025年のForm 10-Kには、よく似た二つの数字が並ぶ。
- 現金・現金同等物・市場性有価証券の調整後原価:1,347億1,100万ドル
- 同じ資産群の公正価値:1,324億2,000万ドル
差は22億9,100万ドルである。ここでいう調整後原価はSECの表の表示に合わせた呼び方で、単純な取得時原価とは限らない。ところが、機械が読むタグの名前だけを見ると、その数字が調整後原価なのか公正価値なのか分からない。
対象はAppleが自社の提出用タクソノミに加えたaapl:CashCashEquivalentsAndMarketableSecuritiesという企業拡張コンセプトだ。コンセプトとは、XBRLで「この数字は何を意味するか」を識別する項目である。この長い英語名をAIに渡せば、タクソノミの複雑な付帯情報を読まなくても意味を理解できるのだろうか。
同じAIへ、渡す証拠を三段階で増やして質問した。結果は明快だった。
名前だけでは、AIは調整後原価か公正価値かを決められなかった。
ラベルを加えると公正価値だと読め、計算関係と比較対象を加えると差額まで説明できた。
それでも、差が生じた内訳は原文へ戻るまで確定できなかった。
この一例はAI全般の性能評価ではない。しかし、「AIが進化すれば企業拡張の説明や関係は不要になる」という予想を、実際の提出データで考える材料にはなる。
この記事は、SECのApple提出書類一覧から2025年10月31日提出のForm 10-Kを確認し、同じ提出一式に含まれるschema(コンセプトの基本属性を定めるファイル)、label linkbase(名称や説明を結ぶファイル)、calculation linkbase(加減算関係を結ぶファイル)、Inline XBRLを使った。外部検索とファイル閲覧を禁止した同一モデルへ三つの質問を行い、その後に8人が22ターン議論した。AIの回答は観察結果として扱い、提出書類の事実はSEC原文で別に照合している。
| 実験条件 | 内容 |
|---|---|
| 実施日 | 2026年7月23日 |
| モデル | Codex gpt-5.6-terra |
| 共通の制約 | 外部検索・追加ファイル閲覧を禁止し、各段階で本文に列挙した情報だけを入力 |
| 共通の質問 | 意味、調整後原価か公正価値か、資産範囲、確定/推測/不足証拠を分けて回答 |
| 読み方 | 同条件の一回の観察であり、モデル一般の順位や精度を示す試験ではない |
実験したのは、Appleが追加した一つのコンセプト
第4回で見たように、企業は標準タクソノミに適切なコンセプトがない場合、提出制度のルールに従って企業固有のコンセプトを追加できる。Appleのschemaには、今回の対象が次のように定義されている。
| schemaから読める属性 | 値 | 平易な意味 |
|---|---|---|
| QName | aapl:CashCashEquivalentsAndMarketableSecurities | タクソノミ内の一意な名前。Appleの名前空間にある企業固有コンセプト |
| type | monetaryItemType | 金額を持つ |
| periodType | instant | 一定期間の累計ではなく、ある時点の残高 |
| balance | debit | 借方が通常の符号になることを示す。資産でよく使われるが、これだけで資産の意味は決まらない |
ここまでは数字の「形」を説明する。公正価値なのか調整後原価なのか、どの資産を含むのかは、まだ属性に書かれていない。
コウ(XML・JSON・データベース設計者)は、自然言語を読めるAIなら長いQNameから十分推測でき、メタデータを作る負担を減らせると主張した。ミユ(AIとデータ基盤を扱う技術者)は、推測できることと証拠から確定できることを混ぜると、もっともらしい誤りになると反論した。
そこで、AIには毎回、次の形式で答えるよう求めた。
- このコンセプトは何を測るか
- 調整後原価か公正価値か
- 含まれる資産は何か
- 確定できること/推測に留まること/追加で必要な証拠
三段階で、AIの答えはどう変わったか
同じモデル、外部検索なし。増やしたのはXBRL内の証拠だけ
第1段階:名前は読めても、測り方は読めない
AIへ渡したのは、上のQNameと三属性だけである。
この条件のAIは名称から「現金、現金同等物、市場性有価証券の合計額らしい」と推測した。一方で、monetaryItemTypeもdebitも測定属性を示さないため、調整後原価か公正価値かは特定できないと答えた。
これは失敗ではない。証拠がないところで答えを作らず、足りない情報を示した点が重要である。
レン(初学者の視点で確認する読者)は、議論でこう問い返した。
レン(初学者の視点で確認する読者)
数字自体が正しくても、意味をAIが補っていたら初心者は気づけません。答えが出たかではなく、どの証拠から答えたかを見ないといけないのですね。
第2段階:documentation labelで意味が急に具体化する
次に、Appleのlabel linkbaseから三つのラベルを加えた。
| ラベルの種類 | Appleが記載した内容 | 役割 |
|---|---|---|
| standard label | Cash, Cash Equivalents and Marketable Securities | 通常使う名称 |
| total label | Cash, Cash Equivalents and Marketable Securities, Fair Value | 合計行で使う表示。公正価値だと明示 |
| documentation label | 手許現金、市場性のあるFV-NI持分証券、売却可能負債証券の金額 | コンセプトの意味と範囲を文章で説明。FV-NIは公正価値の変動を純利益へ反映する区分 |
この条件のAIはtotal labelのFair Valueを根拠に公正価値だと特定し、documentation labelから資産の範囲を説明した。QNameだけの段階では埋められなかった空白を、会社が記述した文章が埋めた。
ただし、サキ(財務報告の作成実務を知る担当者)は、ここで立ち止まった。
サキ(財務報告の作成実務を知る担当者)
documentation labelは提出者が書いた説明です。AIの理解を助けますが、外部機関が意味の正しさを認証した文章ではありません。
XBRL Internationalの企業固有開示ガイダンスも、ラベルは会計的な意味を示す手掛かりになり得る一方、非構造化であり、信頼できるanchoringそのものとは扱えないと説明する。anchoringとは、会社独自のコンセプトを標準タクソノミの近いコンセプトへ関係付けることである。
つまり、第2段階で分かったのは、Appleがこのコンセプトをどう定義しているかである。その説明が表、値、計算と整合するかは次の確認になる。
第3段階:calculation linkで「何を足したか」が見える
第3段階では、Appleのcalculation linkbaseにある三つの子コンセプトを加えた。いずれも重みは+1だった。
us-gaap:Cashus-gaap:EquitySecuritiesFvNiCurrentAndNoncurrentus-gaap:AvailableForSaleSecuritiesDebtSecurities
さらに、2025年9月27日時点の公正価値ファクト132,420と、同じ日・同じcontextを持ち、SEC表で調整後原価と表示される比較対象のファクト134,711を渡した。contextは値の日付、報告主体、ディメンションなどの条件を持つ。どちらもunitはUSD、scaleは6、すなわち表示値を100万倍して読む。
この条件のAIは次を計算した。
公正価値 132,420 − 調整後原価 134,711 = −2,291(百万ドル)
そして、「対象資産の公正価値は調整後原価より22億9,100万ドル低い」と説明した。一方、持分証券と負債証券のどちらがいくら寄与したか、差の経済的な原因は、与えた証拠だけでは分からないと留保した。
calculation linkは、会社独自の合計と既知の標準コンセプトを算術で結ぶ。XBRL Internationalも企業固有開示に関するガイダンスで、計算関係は未知の企業固有ファクトへ数学的な文脈を与える有力な手段だが、完全な解決ではないとする。
原文へ戻ると、22億9,100万ドルの中身が確定した
最後に人が確認したのは、SECが同じ提出データから表示するFinancial Instruments – Cash, Cash Equivalents and Marketable Securities (Details)である。
SEC原文表で差額を分解(単位:百万ドル)
この式によって、AIが差額として示した2,291百万ドルが、未実現利益736と未実現損失3,027の差であることまで確認できる。134,711 + 736 − 3,027 = 132,420と一致した。
同じ表では、公正価値の内訳も、現金・現金同等物35,934、流動の市場性有価証券18,763、非流動の市場性有価証券77,723と示され、合計132,420になる。
ここで初めて、AIが第3段階で留保した差額の内訳を、提出原文で確定できた。AIが「分からない」と残した箇所は、人が戻る場所を狭める印になった。
アオイ(財務データを利用する投資アナリスト)は、差額をすぐ「Appleの投資損失」と呼ぶことに反対した。
アオイ(財務データを利用する投資アナリスト)
調整後原価と公正価値の差は読めても、それだけで損益計算書への影響や投資判断上の原因まで断定してはいけません。会計方針と明細へ戻る必要があります。
AI時代に価値が残るのは、「正解」ではなく証拠の分業
この実験で使った情報は、一つの場所にまとまっていない。
| 証拠 | 分かること | それだけでは分からないこと |
|---|---|---|
| QName、type、periodType、balance | 概念の識別子、値の型、時点/期間、残高性質 | 公正価値か調整後原価か、詳しい範囲 |
| standard/total/documentation label | 提出者が意図した名称、表示、文章定義 | 記述が実際の値・表と整合するか |
| presentation link | どの開示の、どの位置に置いたか | 親子が数学的・意味的に何を表すか |
| calculation link | 合計と構成項目、加減算 | 会計方針、差額の経済的原因 |
| factとcontext | 値、単位、日付、entity、ディメンション | contextの設定が表の意図と正しいか |
| Inline XBRL原文 | 読者向けの表、見出し、注記との位置関係 | 見た目だけではconcept identityを取り違え得る |
複雑に見えるのは、同じ説明を重複しているからではない。コンセプトそのものの意味、報告された一回の値、表示位置、算術関係、読者向け原文が、違う責任を持つからである。
AIは、分散した資料を横断して候補となる根拠を集める役に使える。ただし速さや正確さは、モデル、入力、照合手順によって変わる。証拠を消してしまえば、AIが読む材料も減る。
ミユ(AIとデータ基盤を扱う技術者)は、議論の結論をこう表現した。
ミユ(AIとデータ基盤を扱う技術者)
AIはタクソノミの代わりではなく、schema、ラベル、関係、context、原文を束ねる利用者です。証拠が増えるほど、推測と確定を分けやすくなります。
初心者は、AIへ何を指示すればよいか
XMLファイルを一つずつ手で読む必要はない。最短の始め方は、SECの提出書類一覧からXBRL一式のZIPを一つだけ手動で保存し、そのZIPをデスクトップ型AIへ添付することである。今回なら、Appleの提出書類一覧にある0000320193-25-000079-xbrl.zipを使う。ZIPを直接読めない環境では、一度展開したフォルダを渡す。
ここで人がする準備は三つだけでよい。
- 対象の会社、年度、Form 10-Kであることを提出書類一覧で確認する
- XBRL ZIPを一つ保存して、AIへ添付する
- 調べたい行名が分からなければ、読者向けの表で見えた日本語または英語をそのまま質問に書く
AIには最初に「その言葉に近い企業固有コンセプトを候補として探し、勝手に一つへ決めない」と指示する。対象QNameが分かった後は、次の指示を続けて渡す。なお、QNameはタグの一意な名前、contextは値の日付・報告主体・内訳条件、roleは関係グループの用途を示す識別子である。これらを読者が手作業で解釈する必要はなく、AIに根拠として返させればよい。
このXBRL提出一式から、企業固有のコンセプトを調べてください。
対象QName:aapl:CashCashEquivalentsAndMarketableSecurities
次の証拠を同じQNameで集めてください。
1. schemaのtype、periodType、balance
2. standard、terse、total、documentation label
3. presentation、calculation、definition上の親・子とrole
4. factの値、unit、decimalsまたはscale、context
5. 同じ表にある近い標準コンセプト、前年コンセプト
6. Inline XBRL原文の表名、見出し、該当箇所
回答は「証拠から確定」「推測」「人が原文で確認」の3列に分けてください。
各結論には、使ったファイル名、QName、context IDを付けてください。
証拠がない点は補完せず、不明としてください。
この指示の狙いは、AIへ詳しいXBRL用語を教えることではない。答えと一緒に、どのファイル・コンセプト・contextを使ったかを返させることにある。
人が最低限見るのは、すべてのXMLではなく次の三点でよい。
人は全件を読むのではなく、不一致を承認・差し戻す
近い標準concept
dimension・context ID
合計式・注記
- 比較した二つが同じ資産範囲を表すか
- 日付、entity、unit、ディメンションが一致するか
- 原文表の見出し、内訳、合計がAIの説明と一致するか
今回の二つのファクトは、どちらもcontext ID c-20を参照していた。そこにはentity 0000320193とinstant 2025-09-27が定義されている。さらにSECの原文表で単位が百万ドル、列見出しが2025年9月27日、調整後原価から公正価値への計算が一致することを確認した。
ツールやAIがcontextを表示しただけで正しいと決めてはいけない。表示された設定値が、原文の見出しと合うかを最後に見る。その確認なら、初心者でも「XMLを全部理解する」よりはるかに実行しやすい。
結論:AIはタクソノミを消すのではなく、読む順番を変える
企業拡張コンセプトの長い名前だけでも、AIは大枠を推測できた。しかし、調整後原価か公正価値かはラベルがなければ決められなかった。計算関係を加えると構成と差額を説明できたが、未実現利益と未実現損失の内訳は原文表へ戻るまで確定できなかった。
コウ(XML・JSON・データベース設計者)の「長いQNameからAIが推測できるなら、メタデータを減らせる」という反対意見は、対象資産の大枠までは当たった。しかし今回のQNameだけでは、投資判断を左右し得る調整後原価と公正価値の違いを越えられなかった。この事例で回答が具体化した場面では、ラベル、計算関係、context、原文というXBRLの手掛かりが追加されていた。
したがって、documentation labelやlinkbaseを「AI以前の冗長な仕組み」と片付けることはできない。ただし、これは一つのモデルと一つの提出書類による観察であり、すべての企業拡張やAIに同じ結果を保証するものではない。
一方、人が全ファイルを順番に読む必要もない。AIへ証拠を集めさせ、確定・推測・要確認を分けさせる。人は、AIが根拠を示せない部分、contextの不一致、原文と計算が合わない部分だけを承認または差し戻す。
AIは企業拡張を読めるようになるほど、タクソノミを不要にするのではない。
分散した意味の手掛かりをまとめる利用者になり、人間の仕事を「全部読む」から「根拠の切れ目を確認する」へ変える。
出典を読むときのポイント
- SEC「Apple提出書類一覧(accession 0000320193-25-000079)」:2025 Form 10-Kと、同じ提出に含まれるschema、label、calculation、Inline XBRL、SEC生成表示のファイル構成を確認した。
- Apple 2025 Form 10-K:提出日、対象年度、Financial Instruments注記と、ファクトが埋め込まれた読者向け原文を確認した。
- Apple企業拡張schema、label linkbase、calculation linkbase:対象コンセプトの型・期間・balance、三種のラベル、三つの計算子要素を確認した。
- SEC生成表「Financial Instruments – Cash, Cash Equivalents and Marketable Securities (Details)」:2025年9月27日の調整後原価134,711、未実現利益736、未実現損失3,027、公正価値132,420、および公正価値の内訳を確認した。単位は百万ドル。
- SEC「EDGAR XBRL Guide, June 2026」:標準コンセプト再利用の優先、使用コンセプトの英語standard label、custom monetary conceptに関するbalanceまたはdocumentation labelの検証規則を確認した。検証通過を意味の正しさの保証とは扱っていない。
- XBRL International「How to address Entity Specific Disclosures」:企業固有開示へ計算関係で数学的文脈を与える考え方と、追加説明を拡張タクソノミのラベルで提供する考え方を確認した。
- XBRL International「Leveraging XBRL Relationships for Anchoring Entity-Specific Disclosures」:calculation、presentation、cube、labelなどが企業固有開示へ与える手掛かりと、ラベルは非構造化で信頼できるanchoringそのものではないという限界を確認した。
出典
- https://data.sec.gov/submissions/CIK0000320193.json
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927.htm
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927.xsd
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927_lab.xml
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/aapl-20250927_cal.xml
- https://www.sec.gov/Archives/edgar/data/320193/000032019325000079/R43.htm
- https://www.sec.gov/files/edgar/filer-information/specifications/xbrl-guide-2026-06-29.pdf
- https://www.xbrl.org/guidance/esd-main/
- https://www.xbrl.org/guidance/esd-relationships/