この連載の読む順番
TDnet①〜④で、書類の役割からXBRLの解析・グラフ化までを順に扱います。その後、EDINET①〜④へ進みます。共通の基本操作はTDnet編を参照し、EDINET編では違いを確認します。
- TDnet解析① TDnetとは？決算短信・適時開示とEDINETの違い
- TDnet解析② XBRLとは？決算短信のPDFと数値データを図解
- TDnet解析③ XBRLの値を比較する前に、期間・単位・欠損を確かめる（準備中）
- TDnet解析④ 累計と四半期単独、実績と予想を分けてグラフにする（準備中）
- EDINET解析① EDINETとは？有価証券報告書から企業を理解する
- EDINET解析② XBRLとは？有価証券報告書の構造とタグの仕組みを理解する（この記事）
- EDINET解析③ TDnetの次に読むXBRL――ファイル・タグ・コンテキストの違いを確かめる（準備中）
- EDINET解析④ 財務データを継続的な分析に使う（準備中）
XBRLでは、値だけでなく「何の値か」を表す情報も読みます。売上高が見つかっても、前年・当年、連結・個別などが違えば、目的の値とは限りません。
この回では、XBRLの基本的な部品を整理します。金融庁の公式サンプルのタグ・コンテキスト・表示リンクを読み、実際の解析コードを確認して整理した処理の考え方も説明します。補助的な架空例は、その旨を明記します。
この回のゴール
TDnet解析②では、数値からコンテキストと単位へたどりました。今回はEDINETでも同じ確認を行い、その後に「表の見出しや並び順はどこから得るのか」「項目の定義は毎回読み直すのか」を考えます。
初読では、まず一つの売上高を確認し、次に階層の例を読みましょう。後半のキャッシュやラベル管理は、企業や年度を増やすときの話です。一度に実装する必要はありません。
タクソノミとインスタンス
タクソノミは、報告項目の定義や関係を表すものです。インスタンスは、それらの項目を使って報告した値などを含みます。まずは「項目の定義」と「今回報告する内容」を分けると理解しやすくなります。
例えば、記入前の帳票には「何を書く欄なのか」という決まりがあり、記入後の帳票には今回の内容があります。それに近い区別として、タクソノミとインスタンスを捉えると入りやすくなります。
ただし、タクソノミは見た目の帳票だけを指すものではありません。要素が数値なのか文章なのか、期間の値なのか時点の値なのか、ほかの要素とどう関係するかなど、機械で確認するための定義も含みます。
| 部品 | 最初の理解 | 何を確認するか |
|---|---|---|
| タクソノミ | 項目の意味を定義するもの | 項目の型や関係など |
| インスタンス | 今回報告する値や条件 | 値、期間、単位など |
| コンテキスト | 値の対象や期間を示す情報 | 企業、時点/期間、区分など |
| 単位 | 数値の単位を示す情報 | 円、株、比率など |
EDINETでは共通のタクソノミに加え、提出者別タクソノミも使われます。企業独自の要素があるため、一つの会社で動いた項目名の検索を、そのまま全社に適用できるとは限りません。金融庁の概要説明
タグは、表の見出しを検索するためだけのものではない
人が財務諸表を読むときは、「売上高」という行名、当期という列名、表の上にある単位を組み合わせます。XBRLでも、一つの値の意味を複数の情報から確かめます。ただし、それらが画面の隣同士に書かれているとは限りません。
数値や文章など、報告された個々の情報を「ファクト」と呼びます。数値ファクトを理解するには、項目の定義、対象を示すコンテキスト、単位などとの対応をたどります。
項目の定義と、日本語のラベルを分ける
日本語で似た名前が付いていても、異なる定義の項目を同じものとして扱ってよいとは限りません。反対に、表示名だけが変わって見えても、項目の定義を確かめると関係が分かる場合があります。
タクソノミは、見出しの単語集というより、報告項目を定義する仕組みです。項目の型や関係も含めて扱います。詳しく調べる際は、表示された言葉だけでなく、その要素が参照する定義に戻ります。XBRL Internationalのタクソノミ解説
入門の段階で、全てのタグ名を暗記する必要はありません。最初は「売上高らしい名前を見つけた」だけで採用を決めず、「この要素は何を報告するためのものか」を一つ確認するところから始めます。
jppfs_cor:NetSalesのコロンは何を分けている？
NetSalesは要素のローカル名です。その前のjppfs_corは名前空間の接頭辞で、「どの名前のグループか」を示す短い呼び名です。接頭辞は、ファイル内のxmlns:jppfs_cor="..."という宣言に対応します。引用符内のURIが、名前空間を識別します。
同姓の人を名前だけで取り違えないように、要素も名前の末尾だけでまとめないようにします。ただし、接頭辞の文字自体も略記なので、プログラムでは宣言先のURIとローカル名の組で区別するのが基本です。「QName」は、このように接頭辞とローカル名で書く名前を指す用語です。
URIは名前を識別するための文字列です。URLのような見た目でも、その文字列を毎回ブラウザで開く操作を指しているわけではありません。実際の定義ファイルへの参照は、スキーマへのリンクなどから確認します。
一つの数値から、参照先へ進む
以下は、実在のタグやファイル構成を再現したものではなく、関係を説明するための概念図です。
| 見つけた情報 | 次に確かめること |
|---|---|
| 売上高に対応する数値ファクト | 項目の定義は目的に合っているか |
| そのファクトが参照するコンテキスト | 対象企業と期間、必要な区分は何か |
| そのファクトが参照する単位 | 円なのか、別の単位なのか |
| 値と精度に関する情報 | 数値をどのように解釈するか |
ここまでを一組として読むと、同じ文書に売上高が複数あっても、すぐに「重複している」とは判断しなくなります。別の期間や区分を報告している可能性があるからです。
図：ファクトの値だけでなく、項目の定義と参照先を組み合わせます。実ファイルの全構造を示す図ではありません。
一つの値から確認すること
架空の「売上高100億円」を、次のように分けてみます。
項目：売上高
値：10,000,000,000
単位：円
期間：2025-04-01〜2026-03-31
範囲：連結
これらの情報が揃うと、何を比較してよいかを考えられます。期間が半分の値や、個別の値を同じ系列へ入れない判断もできます。
コンテキストには識別用のIDが付きます。ただし、その文字列だけを見て内容を決め付けず、参照先にある期間や区分を確認します。IDの名前を読むことと、条件の内容を読むことは別です。
候補を絞り込む例を、コードを書く前に考える
架空の青葉製作所について、次の三つの売上高が見つかったとします。すべて円単位から億円へ換算した説明用の値です。
| 候補 | 期間 | 対象範囲 | 売上高 |
|---|---|---|---|
| A | 前年度の1年間 | 連結 | 90億円 |
| B | 当年度の1年間 | 連結 | 100億円 |
| C | 当年度の1年間 | 個別 | 70億円 |
知りたいことが「当年度の企業グループ全体の売上高」であれば、この例ではBが該当します。Aは期間が違い、Cは対象範囲が違います。金額が最大だからBを選ぶわけでも、文書中で先に登場したから選ぶわけでもありません。
ここで重要なのは、実際のファイルにA、B、Cという分かりやすいラベルが付いているとは限らないことです。プログラムは、数値が参照している情報を読み、必要な条件に合うかを確かめます。
候補が二つ残ったら、無理に一つへ決めない
仮に、当年度・連結という条件まで揃えても二つの候補が残ったら、さらに区分や項目の定義、元の記載箇所を確認します。条件が足りないのに、先頭の一件を返すことで問題を隠さないようにします。
学習のための小さな処理なら、結果を「該当なし」「一件に決まった」「複数候補が残った」の三つに分けるだけでも有効です。どの段階で判断が必要になったかを説明できるからです。
コンテキストIDは内容を指す目印
コンテキストには、ほかの情報から参照するためのIDがあります。IDに年度や区分を連想させる文字が含まれていても、入門例の文字列だけを頼りに全ての書類へ適用しません。
IDをたどって期間や区分を確認することと、IDの名前から条件を推測することは違います。この区別は、後に自分で解析コードを書くときにも役立ちます。
「期間」と「時点」を図で考える
売上高のように、ある期間を通して生じる値があります。一方、期末の資産のように、ある時点の状態を表す値もあります。
2025-04-01 ───────── 2026-03-31
← この期間の売上高 → ● この時点の資産
年間の売上高を前の年と比べる場合と、期末の資産を前の期末と比べる場合では、対象の選び方が違います。見た目の年度ラベルだけで同じ処理をしないことが大切です。
図：期間を線、時点を点で表しました。同じ年度のラベルでも、値が表す時間は異なります。
Inline XBRLは、読める文書とタグをつなぐ
Inline XBRLは、人が読む文書の中にXBRLの情報を埋め込む方法です。ブラウザで見える文章や表と、その中にあるタグの意味を関連付けて読めます。
ただし、見えている文字列をそのまま数値にするだけでは不十分な場合があります。表示の桁区切りや符号、数値の倍率などを、仕様に沿って解釈します。XBRL Internationalのタグ付け解説
単位を確認しないまま「表の数字を全部集める」と、円と株数などが混ざります。グラフの軸にも単位を明示し、比率を金額として描かないようにします。
公式サンプルで、HTMLとXBRLの同じ売上高を比べる
金融庁の操作ガイド等・サンプルインスタンスにある有価証券報告書のサンプルを使います。確認したのはS002XXXX/XBRL/PublicDoc/内の次のファイルです。S002XXXXもサンプル上の識別子で、実在企業の業績を示すものではありません。
jpcrp030000-asr-001_X99001-000_2026-03-31_01_2026-06-12.xbrl
0105030_honbun_jpcrp030000-asr-001_X99001-000_2026-03-31_01_2026-06-12_ixbrl.htm
jpcrp030000-asr-001_X99001-000_2026-03-31_01_2026-06-12_pre.xml
.htmの同じ売上高は、次のように定義されていました。必要な属性を抜粋し、改行を整えています。
<ix:nonFraction name="jppfs_cor:NetSales"
contextRef="CurrentYearDuration" unitRef="JPY"
decimals="-6" scale="6" format="ixt:numdotdecimal"
footnoteRefs="footnote2102">323,609</ix:nonFraction>
一方、通常の.xbrlファイルの同じ値は次のとおりです。比較に不要なid属性は省略しています。
<jppfs_cor:NetSales contextRef="CurrentYearDuration"
unitRef="JPY" decimals="-6">323609000000</jppfs_cor:NetSales>
画面上の323,609をInline XBRLとして読むと、scale="6"に従い円単位の323,609,000,000になります。通常のXBRL側では、その値がすでに入っています。後者へさらに100万倍すると誤りです。
出典：金融庁「報告書インスタンス作成ガイドライン」図表5-6-7（PDFの64ページ目、2026年10月26日確認）。該当箇所の抜粋です。
この図は利益の負数を例にしています。画面に「△」があるかだけで判定するのではなく、タグのsignも確認する理由が分かります。図の例と、本文で読んだ売上高のサンプルは別の数値です。
二つのファイルを手元で照合する手順
- サンプルZIPを展開し、上に挙げた
PublicDoc内の.htmをテキストエディタで開きます。 -
jppfs_cor:NetSalesを検索し、contextRef="CurrentYearDuration"の候補を見ます。同じタグの別期間を混ぜないよう、二つの条件を一緒に確認します。 - その候補の文字列
323,609と、scale="6"、unitRef="JPY"を控えます。 -
.xbrlを開き、同じ要素名と同じcontextRefの候補を探します。 - こちらの値
323609000000と、Inline XBRL側の文字を変換した結果が一致することを確かめます。
カンマを外すと323609、それを100万倍すると323609000000です。今回は、この計算で両者が一致します。普通の.xbrlの値に対して同じ100万倍をもう一度行わない、という点まで説明できれば、この比較の目的は達成です。
EDINETのコンテキストも、参照先から確認する
同じ.xbrl内でid="CurrentYearDuration"を検索すると、このサンプルでは主体X99001-000、開始日2025-04-01、終了日2026-03-31が記録され、scenarioはありませんでした。
出典：金融庁「報告書インスタンス作成ガイドライン」コンテキスト設定例（PDFの50ページ目、2026年10月26日確認）。該当箇所の抜粋です。
TDnetのサマリーではConsolidatedMemberが明示された例を読みましたが、EDINETのこの連結期間の例は同じ形ではありません。デフォルトメンバーなど、対象タクソノミの規則も関係します。「scenarioがないものは全て連結」と全書類へ一般化せず、書類の対象・タクソノミとセットで判断します。報告書内で連結・個別の区別を使わない箇所もあります。
同じIDの名前を別の書類でも使うため、コンテキストの辞書は、少なくとも対象の書類・インスタンス集合を区別して管理します。前に読んだ会社のCurrentYearDurationを、次の会社へそのまま流用してはいけません。複数のInline XBRLファイルが一つの文書を構成する場合には、本文のファクトとリソースの定義が同じHTMLファイルにないこともあります。まず対象セットの参照先を集め、その後で値を結び付けます。
円と「円／株」を区別する
unitRefの先には、単純なmeasureだけでなく、divideがある場合があります。次の公式例では分子が円、分母が株です。
出典：金融庁「報告書インスタンス作成ガイドライン」図表5-5-7（PDFの57ページ目、2026年10月26日確認）。該当箇所の抜粋です。
1株当たり利益を金額の合計と同じ単位として保存すると、後で集計や比較を誤ります。JPYPerSharesというIDだけで判定を固定するより、定義の分子・分母まで読む設計にすると意味を確認できます。
貸借対照表の階層は、どうやって取り出すのか
数値タグを上から順に並べても、貸借対照表の見出しや階層は復元できません。表示上の親子関係を読む入口が、表示リンクベースです。今回のサンプルでは_pre.xmlを開きます。実際の参照関係は.xsdのlinkbaseRefなどから確認し、拡張子やファイル名の推測だけで収集を終えないようにします。
出典：金融庁「提出者別タクソノミ作成ガイドライン」図表6-3-1（PDFの102ページ目、2026年10月26日確認）。該当箇所の抜粋です。
図のlocは、リンク内の呼び名と実際の要素の参照先を対応させる部品です。presentationArcのfromとtoは、その呼び名を使って親から子への関係を表します。タグ名のインデントを見て親子を推測する仕組みではありません。
表示リンクの用語を、先に日本語にする
| 用語 | この場面での意味 |
|---|---|
| 表示リンクベース | 項目をどんな親子関係・順番で表示するかを読む情報 |
| ロール | どの表・表示区分の関係なのかを分ける識別子 |
loc |
このリンク内の呼び名と、参照先の要素を対応させるもの |
presentationArc |
表示上の親から子へ結ぶ関係 |
order |
同じ親の下にある子の並び順 |
preferredLabel |
その場所で優先するラベルの用途 |
「親」「子」は会社の親子関係ではありません。例えば「流動資産」という見出しの下に「現金及び預金」を置く、といった表の構造です。企業の連結範囲の説明とは区別してください。
読む順番は、次のようになります。
-
presentationLinkのxlink:roleで、どの表・表示区分の関係かを分ける。 - 同じリンク内の
locから、xlink:label → xlink:hrefの対応を作る。 -
presentationArcのfrom・toを参照先の要素へ解決する。 - 同じ親の子を
orderで並べる。 -
preferredLabelがあれば、その用途のラベルを選ぶ。
出典：金融庁「提出者別タクソノミ作成ガイドライン」図表6-3-2（PDFの103ページ目、2026年10月26日確認）。該当箇所の抜粋です。
サンプルに実際にある関係を小さな木にする
サンプルのrol_ConsolidatedBalanceSheetにある関係の一部を、orderで並べ直すと次のようになります。jppfs_cor:は読みやすさのため省略しています。日本語は説明用です。
AssetsAbstract（資産の見出し）
└─ CurrentAssetsAbstract（流動資産の見出し）
├─ CashAndDeposits order=1
├─ NotesAndAccountsReceivableTradeAndContractAssets order=2
├─ ShortTermInvestmentSecurities order=3
├─ Inventories order=4
├─ OtherCA order=5
├─ AllowanceForDoubtfulAccountsCA order=6
└─ CurrentAssets order=7 / totalLabel
木の図から、一つの枝だけをたどる
まず図のCurrentAssetsAbstractとCashAndDepositsの二つだけを見ます。前者は流動資産の見出し、後者は現金及び預金に当たる項目です。日本語の説明と英語の要素名を対応させて読んでください。
presentationArcを読むときは、fromに書かれた呼び名を同じリンク内のlocで探し、hrefの参照先が何の要素かを確認します。次にtoについても同じ操作をします。これで「どの要素から、どの要素へつながるか」が分かります。fromとtoの文字列が、そのまま正式な要素名とは限らない点がポイントです。
その関係にorder=1があれば、同じ親に属する子を並べる際の順序として使います。別の親の下にもorder=1はあり得るため、ファイル全体をorderだけで一列に並べるわけではありません。
これをほかの枝にも繰り返すと、上の小さな木になります。最後に数値を表示する段階で、要素名に対応するファクトを探し、期間・単位などを確認して結び付けます。表示リンクを読んだだけでは、どの年度の金額を表示するかまでは決まりません。
元ファイルではCashAndDepositsの関係は売上債権などの後に記述されていました。それでもorder=1なので、表示順では先になります。「XMLに出てきた順」をそのまま使えない、具体的な例です。
AssetsAbstractのような見出しには、数値が付かないことがあります。見出しを0円として作らず、表示構造のノードとして扱います。またCurrentAssetsは合計ラベルで表示する指定があります。親子関係は表示の関係で、親の数値が全ての子の単純合計になることを保証するものではありません。 計算関係は計算リンク、軸とメンバーは定義リンクと、読む対象を分けます。
一つの要素が複数の表示区分に現れることもあります。全てのpresentationLinkを一つの巨大な木にまとめず、ロールごとの関係を保ちます。TDnetの決算短信サマリーは主に定義リンクを使う構成なので、「どのZIPにも_pre.xmlがある」という前提も置きません。
タグは毎回調べるのか、一つにまとめるのか
毎回全てをネットワークからダウンロードする必要はありません。ただし、あらゆる会社・年度を「タグ名 → 日本語名」の一つの辞書へ無条件で上書きしていくのも危険です。参照は書類ごとに確認し、同じ定義は再利用すると分けると設計しやすくなります。
| 情報 | 再利用の考え方 | 残しておきたい手掛かり |
|---|---|---|
| 標準タクソノミ | 取得済みの同じ版をキャッシュする | 名前空間URI、参照URL、版、取得記録 |
| 提出者が追加した要素・名称 | その書類の拡張として読む | 要素名、提出者、出典書類、定義元 |
| 表示順と階層 | 対象書類の関係を読む | ロール、親子、order、preferredLabel |
| ラベル | 言語と用途を分ける | 日本語／英語、標準／合計／期首など |
キャッシュを使う場合でも、最初に確かめること
キャッシュは、一度取得した定義などを保存し、同じものが必要になったときに再利用する仕組みです。次の順に分けると、「毎回全部取得する」と「何も確認せず使い回す」の間を整理できます。
- 新しい書類を読むとき、その書類が参照する定義を確認します。
- 同じ名前空間・参照先・版の定義を取得済みなら、保存済みのものを再利用します。
- 未取得の版なら、新しく取得して別に保存します。
- 提出者独自の要素や、その書類の表示構造は、対象書類に対応させて読みます。
新しいタグを見つけたら、まず「どこに定義され、何というラベルが付いていたか」を記録できます。しかし、名前が似ている既存項目と意味が同じかは、別に確認する作業です。「未知のタグを記録する自動化」と「同じ財務項目へ統合する判断」を分けると、誤った統合を避けやすくなります。
出典：金融庁「提出者別タクソノミ作成ガイドライン」図表6-2-2の抜粋（PDFの96ページ目、2026年10月26日確認）。該当箇所の抜粋です。
jppfs_corは名前空間の接頭辞です。サンプルではhttp://disclosure.edinet-fsa.go.jp/taxonomy/jppfs/2025-11-01/jppfs_corを指していました。同じ接頭辞でも、参照する版が変わる可能性があります。要素の同一性を確かめるときは、接頭辞の見た目や日本語名だけでなく、名前空間URIとローカル名を見ます。
新しく見つかったタグやラベルは、出典付きの候補として蓄積できます。その後、既存定義との衝突、言語、ラベル用途、標準か企業拡張かを確認して採用します。知らないタグが現れるたびに、全社共通の「売上高」などへ自動で割り当てることとは別の処理です。
実際の解析コードを確認すると、標準ラベルのキャッシュ、書類ごとの名称リンクの読取り、新しいラベルの追加、企業拡張ラベルの出典付き保存が別の処理に分かれていました。この記事で示す表は、その分離の考え方を学習向けに整理したものです。全ての具体的なキー設計や例外処理を示すものではありません。
事業別の数値を表すディメンション
売上高には、会社全体だけでなく、事業別などの切り口があります。そのような区分を表現する仕組みとして「ディメンション」が使われます。EDINETの解説では、報告セグメントや連結・個別などを表す軸が説明されています。金融庁の概要説明 第1章
例えば、青葉製作所に機械販売と保守サービスの二つの事業があるとします。売上高という項目と、どの事業かという区分を組み合わせれば、同じ売上高でも別の意味を持つことが分かります。
| 項目 | 区分 | 架空の金額 |
|---|---|---|
| 売上高 | 機械販売事業 | 65億円 |
| 売上高 | 保守サービス事業 | 35億円 |
初心者が最初に覚えるのは、ディメンションの全仕様ではありません。「同じ項目・同じ年度でも、切り口が違う数値がある」ということです。項目名だけをキーにした表では、後から読んだ数値で前の数値を上書きしてしまう可能性があります。
なお、実際の事業別データの扱いは、企業の開示と注記を確認します。この二事業の表は構造を説明するための例であり、全社で同じ事業名や分類が使われることを意味しません。
図：項目名に事業の区分を組み合わせて、別々の値として扱います。実際の集計・調整は開示の注記で確認します。
数値タグと文章のまとまりは違う
XBRLには、細かな項目として扱われるものと、文章や表をまとめて扱うものがあります。文章のまとまりが取得できたからといって、その中の全ての表が統一された数値項目になるわけではありません。
例えば、事業の説明を読む用途と、売上高を年ごとに比較する用途では、必要な処理が違います。最初に「取得できたファイル」を見るだけでなく、「最終的にどんな表や画面を作りたいか」を決めておくと、確認すべき範囲を絞れます。EDINETの操作・技術資料
値がないときも情報を残す
目的の値が見つからない場合は、その理由を確認します。対象書類にないのか、条件が違うのか、取得や解析に失敗したのかを、ゼロという一つの値にまとめません。
欠損をゼロとして折れ線にすると、業績が急減したように見えることがあります。読者が誤解しないため、欠損は欠損として表示し、確認できる範囲を注記します。
ファイルの検証と、分析結果の検証を分ける
XBRLには、決められたルールに従っているかを検証する仕組みがあります。これをバリデーションと呼びます。形式や関係を確かめる検証は、潜在的な問題を見つけるために役立ちます。XBRL Internationalの検証の解説
ただし、ファイルが仕様上の検証を通ったことと、利用者が目的に合う数値を選べたことは同じではありません。正しいファイルから、正しい前年の値を取り出しても、当年の売上高として表示すれば、その分析画面は誤っています。
| 確認する段階 | 例 |
|---|---|
| ファイルの読取り | 構造を解釈できるか |
| 仕様上の検証 | 定義されたルールを満たすか |
| 値の選択 | 目的の会社・期間・区分に合うか |
| 表示の確認 | 単位、年度ラベル、欠損が正しく伝わるか |
人が説明できる一行を完成させる
学習の最初の到達点は、全てのタグを集めることよりも、選んだ一行を説明できることです。
「青葉製作所の、2025年4月から2026年3月までの、連結売上高で、円単位の値を億円へ換算した」と言えれば、その値を使う条件が明確になります。さらに、どの書類を参照したかを残せば、人が元の説明と照合できます。
この一行を前年分にも用意し、条件を比べてから二点のグラフにします。会社を増やしたり、項目を増やしたりするのは、その後です。小さな範囲で仕組みを理解することが、実装の細部へ進むための土台になります。
実践編では、何を作る？
最初は項目と条件が分かっている小さな例で、値を一つ取り出します。その後、ZENITH Codeで実際に取得できる項目と対応を確認し、集計・グラフ作成へ進みます。
可視化では、抽出した値だけでなく、期間・単位・欠損をどう表示するかも確認します。小さな例から、読み手が誤解しないグラフを作っていきます。
確認問題: 同じタグ名で二つの値が見つかったら、先頭の値を採用してよいでしょうか。
答えは、条件の確認が必要です。対象期間、連結・個別などが違う可能性があるからです。抽出する前に、欲しい値の条件を言葉で説明できるようにしましょう。
続けて読む
- 前の記事：EDINET解析① EDINETとは？有価証券報告書から企業を理解する
- 次の記事：EDINET解析③ TDnetの次に読むXBRL――ファイル・タグ・コンテキストの違いを確かめる（準備中）
私たち株式会社Crabgrassは、財務データAPI「ZENITH Code」を開発・提供しています。
本記事は技術解説です。特定の金融商品の売買を推奨するものではありません。