米国上場企業の財務データを頑張って解析しようとした話 (XBRL)

# はじめに

自分は数年前から米国株式投資をしており投資対象を絞る際にyahoo financeで業績情報を見るのですが、何千企業とあるのでなかなか比較が大変です。

そこでこのプロセスを一部でもよいので自動化できないかと思い、そのために業績データ（売上・売上総利益・営業利益など）のデータベースを作りたいなと思いました。必要となる株価や業績のデータはお金さえ払えば色々なベンダーが色々な形式（API, CSVダウンロード...）で提供しています。しかし、もちろんお金がかからないに越したことはないので無償で使えるものが無いかを調べたところ、業績データに関してはSEC（日本で言う証券取引委員会のような機関）がXMLベースのXBRLという形式で無償で公開していました。

今回は公開されているXBRL財務データを解析し、Yahoo financeに載っているような財務データの粒度でデータベースが構築できることを目指して取り組んだ結果を共有します。

# 前提知識 - XBRLとは

XBRLとはeXtensible Business Reporting Languageの略語で、訳すと「事業における報告のための、拡張性のある言語」といった感じです。「事業における報告」なので財務データの報告に特化したものではなく、どのような報告内容でも電子データとして報告できるような抽象度の高い、「拡張性のある」形式です。技術的にはただのXMLですが、抽象的で直観的にはわかりづらいルールとなっています。[ここ](https://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html)でXBRLの定義が読めます。

XBLR形式の報告データはタクソノミとインスタンスという大きく2つの要素で構成されています。タクソノミは報告する要素（例：売上高、売上原価、事業のリスク）やその要素同士の関係などを定義しています。会計基準であるus-gaapのタクソノミやSECのタクソノミなどが存在します。インスタンスはそのタクソノミに沿った報告内容の実体（例：売上高の数字、売上原価の数字、事業のリスクを説明した文章）です。

# 実際にXBRL形式のデータを解析してみる
XBRL形式のデータの解析には、公式ウェブサイトで公開されているような既存の無料ツールもあります。有名なものだとArelleとかです。
https://www.xbrl.org/the-standard/how/tools-and-services/

しかしそれらのツールを使おうにもXBRLの仕様について知っていないと簡単には使え無さそうでしたので、今回は自力でXBRLの仕様を読みながらXBRLを解析していきました。試行錯誤しながらだったのでかなり汚いですが、githubにソースを置きましたのでよろしければご参照ください。

https://github.com/YokoMasa/Earnings-Analysis

## Fact (報告データ) の抽出
実際にインスタンスのファイルの中身を見てみます。インスタンスは報告内容の実体(fact)と、その付随情報(contextやunitなど)で構成されています。
2021年のApple(ticker: AAPL)のform 10-K(通期の有価証券報告書にあたるもの)のインスタンスから2つfactを抜き出してみました。(インスタンスは[こちら](https://www.sec.gov/Archives/edgar/data/0000320193/000032019321000105/aapl-20210925_htm.xml)から見られます。)

```xml:aapl-20210925_htm.xml
<dei:EntityRegistrantName contextRef="i55e5364a9af5491886caee077afe8d44_D20200927-20210925" id="id3VybDovL2RvY3MudjEvZG9jOmNmZmVjMmQ1YzU1MzQ5MjA4OWUxNzg0MDQ0ZTNjYzUzL3NlYzpjZmZlYzJkNWM1NTM0OTIwODllMTc4NDA0NGUzY2M1M18xL2ZyYWc6OWE4YTdjYTcxMDUwNDU4NTk4OTYyZTA0ZjZiMDYxYTYvdGV4dHJlZ2lvbjo5YThhN2NhNzEwNTA0NTg1OTg5NjJlMDRmNmIwNjFhNl8zODA2_a0c882d6-3e0f-4dca-939c-93ddbb6bbc8b">Apple Inc.</dei:EntityRegistrantName>
<us-gaap:GrossProfit contextRef="i55e5364a9af5491886caee077afe8d44_D20200927-20210925" decimals="-6" id="id3VybDovL2RvY3MudjEvZG9jOmNmZmVjMmQ1YzU1MzQ5MjA4OWUxNzg0MDQ0ZTNjYzUzL3NlYzpjZmZlYzJkNWM1NTM0OTIwODllMTc4NDA0NGUzY2M1M184NS9mcmFnOmI5ZTdlYTIyZTdiMzRhZTg5ODlmZTdhOWMyOGE0MjY0L3RhYmxlOjg3MWRjOTM3MzFkNTQwZDQ4NWRlZjlhNTdjZTZkYTMwL3RhYmxlcmFuZ2U6ODcxZGM5MzczMWQ1NDBkNDg1ZGVmOWE1N2NlNmRhMzBfMTEtMS0xLTEtMA_53c906ed-9ab7-49a3-b345-2eb33b90e0f3" unitRef="usd">152836000000</us-gaap:GrossProfit>
```

1つ目のfactは`dei:EntityRegistrantName`というタグ名で値が`Apple Inc.`となっています。この報告書の報告者名を表しているものだと推測できます。
2つ目のfactは`us-gaap:GrossProfit`というタグ名で値が`152836000000`となっています。売上総利益を表しているものだと推測できます。

それぞれ`dei:`、`us-gaap:`という接頭辞がついていますが、これらは実は別々のタクソノミで定義された報告要素となっています。タクソノミ定義はタクソノミスキーマと呼ばれており、インスタンスの冒頭部分で↓のように参照されています。

```xml:aapl-20210925_htm.xml
<link:schemaRef xlink:href="aapl-20210925.xsd" xlink:type="simple"/>
```

`schemaRef`で参照されたスキーマからさらに別のスキーマ(上述のus-gaapやdei)がインポートされ、、、ということを繰り返し最終的にこのインスタンスに適用されるスキーマの総体をDTS (Discoverable Taxonomy Set)と言うそうです。
インスタンスでは報告要素が定義されたタクソノミスキーマの名前空間でfactが記載されます。

また、factには`contextRef`という属性がついていますが、これはその名の通りcontextへの参照を表しています。contextはfactの"背景"のようなもので、いつからいつまでのデータなのか、どの報告セグメントのデータなのかといった情報を持っています。
例えば上記の`us-gaap:GrossProfit`の`contextRef`と同じidを持つcontextをインスタンス内で探すと、以下のようになっています。

```xml:aapl-20210925_htm.xml
<context id="i55e5364a9af5491886caee077afe8d44_D20200927-20210925">
  <entity>
    <identifier scheme="http://www.sec.gov/CIK">0000320193</identifier>
  </entity>
  <period>
    <startDate>2020-09-27</startDate>
    <endDate>2021-09-25</endDate>
  </period>
</context>
```
factとcontextを組み合わせると、2020年9月27日 ~ 2021年9月25日までの売上総利益は152836000000ドルだったということが分かりました。

ここまでインスタンスからfactを取り出してみましたが実は代表的なタクソノミ(us-gaap, dei, srt等)に沿ったfactだけであれば、インスタンスを解析しなくてもSEC公式のAPIで取得することができます。
https://www.sec.gov/edgar/sec-api-documentation

ただ実際は代表的なタクソノミでは報告したい要素が表現できずに、それぞれの企業が独自のタクソノミを定義していたりするのでこのAPIだけでは情報が抜け落ちてしまう可能性があります。
(2020年時点で報告内容の20%くらいは独自タクソノミによるものだったらしいです。https://www.datatracks.com/blog/sec-publishes-updated-xbrl-custom-tag-rates-for-us-gaap-and-ifrs/)

## Fact同士の関係（計算関係）を抽出

factを抜き出し羅列することはできました。タクソノミには報告要素の定義だけでなく報告要素の構造（文書上の構造や計算構造など）も定義しているので、そちらも見てみます。
インスタンスで参照されていたAppleのタクソノミスキーマを見ると、以下のような部分があります。

```xml:aapl-20210925.xsd
<link:linkbaseRef xmlns:xlink="http://www.w3.org/1999/xlink" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="aapl-20210925_lab.xml" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef" xlink:type="simple"/>
<link:linkbaseRef xmlns:xlink="http://www.w3.org/1999/xlink" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="aapl-20210925_pre.xml" xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef" xlink:type="simple"/>
<link:linkbaseRef xmlns:xlink="http://www.w3.org/1999/xlink" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="aapl-20210925_cal.xml" xlink:role="http://www.xbrl.org/2003/role/calculationLinkbaseRef" xlink:type="simple"/>
<link:linkbaseRef xmlns:xlink="http://www.w3.org/1999/xlink" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="aapl-20210925_def.xml" xlink:role="http://www.xbrl.org/2003/role/definitionLinkbaseRef" xlink:type="simple"/>
```

これらはExtended linksと呼ばれるものへの参照で、それぞれのExtended linksは何かしらの報告要素の構造などを定義しています。
今回はその中から要素同士の計算構造の定義(Calculation linkbase)を見てみましょう。

Calculation linkbaseの中身は大体以下のような構造になっています。

```xml:aapl-20210925_cal.xml
<link:calculationLink xlink:role="http://www.apple.com/role/CONSOLIDATEDSTATEMENTSOFOPERATIONS" xlink:type="extended">
  <link:loc xlink:type="locator" xlink:label="loc_us-gaap_GrossProfit_19ef13ef-f5d3-47e8-9fc9-76cdddcee0a9" xlink:href="https://xbrl.fasb.org/us-gaap/2021/elts/us-gaap-2021-01-31.xsd#us-gaap_GrossProfit"/>
  <link:loc xlink:type="locator" xlink:label="loc_us-gaap_RevenueFromContractWithCustomerExcludingAssessedTax_2b967b9d-1c08-47d1-80cf-0d62e7ae4d11" xlink:href="https://xbrl.fasb.org/us-gaap/2021/elts/us-gaap-2021-01-31.xsd#us-gaap_RevenueFromContractWithCustomerExcludingAssessedTax"/>
  <link:calculationArc order="1" weight="1.0" xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" xlink:from="loc_us-gaap_GrossProfit_19ef13ef-f5d3-47e8-9fc9-76cdddcee0a9" xlink:to="loc_us-gaap_RevenueFromContractWithCustomerExcludingAssessedTax_2b967b9d-1c08-47d1-80cf-0d62e7ae4d11" xlink:type="arc"/>
  <link:loc xlink:type="locator" xlink:label="loc_us-gaap_CostOfGoodsAndServicesSold_f40937f3-af28-421b-ba02-7e3e90d72401" xlink:href="https://xbrl.fasb.org/us-gaap/2021/elts/us-gaap-2021-01-31.xsd#us-gaap_CostOfGoodsAndServicesSold"/>
  <link:calculationArc order="2" weight="-1.0" xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" xlink:from="loc_us-gaap_GrossProfit_19ef13ef-f5d3-47e8-9fc9-76cdddcee0a9" xlink:to="loc_us-gaap_CostOfGoodsAndServicesSold_f40937f3-af28-421b-ba02-7e3e90d72401" xlink:type="arc"/>
</link:calculationLink>
<link:calculationLink xlink:role="http://www.apple.com/role/CONSOLIDATEDBALANCESHEETS" xlink:type="extended">
  ...
</link:calculationLink>
...
```

`link:loc`タグは報告要素へのポインタのようなもので、`xlink:href`属性を見ていただければわかるようにus-gaapのGrossProfit(売上総利益)やCostOfGoodsAndServicesSold(売上原価)などを参照しています。

`link:calculationArc`タグは要素同士の計算関係を表しており、`xlink:from`属性と`xlink:to`属性で示されている2つのloc(がさらに指し示す要素)同士が計算関係にあることを表しています。
どのような計算関係かというのは`xlink:arcrole`属性で示されており、現状は`http://www.xbrl.org/2003/arcrole/summation-item`の加算関係のみが存在するようです。
さらに加算する際にかけ合わせる係数の定義も用意されており、`weight`属性で表されます。

上記の例で定義されている計算関係を数式化すると以下のようになります。

```
GrossProfit = 1 * RevenueFromContractWithCustomerExcludingAssessedTax + (-1) * CostOfGoodsAndServicesSold
```

売上総利益は売上から売上原価を引いたものだ、という馴染みのある計算構造になっているかと思います。

最後に、計算構造の定義は`link:calculationLink`タグによりまとめられていることが分かりますが、このタグの`xlink:role`見るとこの計算構造の役割を知ることができます。
上記の数式の`xlink:role`は`http://www.apple.com/role/CONSOLIDATEDSTATEMENTSOFOPERATIONS`なので損益計算の役割があることが推測できます。
(ちなみにrole自体の定義はタクソノミスキーマaapl-20210925.xsdで行われていました。)

## FactとFact同士の関係を結びつける
FactとFactの損益計算の計算構造が分かりましたのでそれらを組み合わせると以下のようになります。
![aapl_tree.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2289954/60e3fc91-4d96-b2ac-b7aa-090f3e66fa1f.png)

yahoo financeでAppleの財務情報を見てみると内容がほぼ一致していることが分かります。

![aapl_yahoo.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2289954/eaff5a6b-bf81-745c-98ea-85c5d1ba87ad.png)

この調子で全企業の財務情報が取得できそうです・・！(フラグ)


## 様々な企業の財務データ
ここで初めてApple以外の企業のインスタンスを解析してみます。

### google(ticker: GOOG)
![goog_tree.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2289954/9d1aa6c3-a89e-3fe1-7079-16f05efe3c57.png)
Appleと見比べると大きく以下のような差異があることが分かるかと思います。
- 売上が`Revenues`タグになっている
- 売上総利益`GrossProfit`が存在せず、売上原価と販管費が`CostsAndExpenses`に集約されている

### ファイザー(ticker: PFE)
![pfe_tree.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2289954/855a06e9-f566-2c6e-7be8-3db3bd739831.png)
Appleと見比べると以下のような差異があります。
- 売上と税引前利益(IncomeLossFromContinuingOperationsBeforeIncomeTaxesExtraordinaryItemsNoncontrollingInterest)までの全コスト等が同じ階層に集約されている。どこまでが売上原価、販管費、営業外費用なのかが構造化されていない。

### カーニバル(ticker: CCL)
![ccl_tree.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2289954/3c14c5ad-b58c-89ea-4212-bb98bfb50104.png)
今度は見慣れないタグ(CostsAndExpensesXxxxxシリーズ)があります。これらはus-gaapで定義されている一般的なタグではなく、ccl独自のタグになります。また、googleと同じように売上原価と販管費が集約されています。

## 様々な企業の財務データを見ての気づき
上記3社の財務データを見てお気づきになったかと思いますが、Yahoo Financeのようなデータを取り出すうえで以下2点、障壁になりそうなものが見つかりました。
・使用タグが微妙に違う
・財務情報の分解度が違う

このあたりは特にガイドライン等は見当たらず、各企業の自由となっているようです。
なかなか困った展開ですが、様々な企業の財務データを見てみるとある程度パターンはありそうな感じがしたので、主要な財務情報を以下のロジックで取得することにしました。

|財務情報|ロジック|
|---|---|
|売上高|Revenues<br>または<br>RevenueFromContractWithCustomerExcludingAssessedTax<br>または<br>RevenueFromContractWithCustomerIncludingAssessedTax|
|売上原価|CostOfGoodsAndServicesSold<br>または<br>CostOfRevenue|
|売上総利益|GrossProfit<br>または<br>売上高 - 売上原価|
|営業費用|OperatingExpenses<br>または<br>CostsAndExpenses - CostOfRevenue|
|営業利益|OperatingIncomeLoss|
|税引き前利益|IncomeLossFromContinuingOperationsBeforeIncomeTaxesExtraordinaryItemsNoncontrollingInterest<br>または<br>IncomeLossFromContinuingOperationsBeforeIncomeTaxesMinorityInterestAndIncomeLossFromEquityMethodInvestments|

## S&P500の企業のデータを分析してみる
S&P500に含まれる企業の最新のForm10Kから前述のロジックに従って財務データを抜き出してみました。
結果としては以下のようになりました。
ちなみに一応抜き出したデータはデータベースに格納しており、csvの形で[gitリポジトリ](https://github.com/YokoMasa/Earnings-Analysis/tree/master/sp500data)に入れていますのでよかったらご参照ください。

|区分|件数|
|---|---|
|全量|494|
|売上、売上総利益、営業利益、税引き前利益<br>すべて揃っているXBRL|313|
|売上、営業利益、税引き前利益のみが揃っているXBRL|69|

個人的に自動スクリーニングのために最低限欲しかった情報は売上・営業利益・税引き前利益の3つなので、S&P内でいえば77%の企業の財務データしか取得できなかったことになります。
上記に当てはまらなかったものを詳細に見てみると、一部業種で使っているタグが異なっているケースであったり、売上原価や営業費用などが構造化されておらず機械的には判断できないものが多かったです。

# 結び
結構頑張ってみたものの、いまいちな結果となってしまいました。
機会損失を無くすために、もれなく全企業の財務データ（最低限、売上・売上総利益・営業利益・税引き前利益）をデータベース化したかったのですが難しかったです。

SECの[ウェブサイト](https://www.sec.gov/structureddata/what-is-structured-data)には「投資家が企業の年毎の業績比較、企業間の業績比較などを効率的に行えるようにするためにXBRLという電子データ形式で業績情報を公開している」といったような記述があります。
しかし、いち個人としては企業間の業績比較には簡単には使えなさそうだなと感じてしまいました。
（もしかしたら「投資家」というのは膨大なリソースを持っているプロのことで、自分みたいな一般人ではないのかもしれませんが・・・）

「必ず売上・営業利益・税引き前利益は報告対象とし、〇〇タグを利用して報告する」のようなガイドラインがあれば、分析する側からすれば使いやすいデータになるのにな、という惜しい気分です。

近年、国や都市を始め様々な組織などが「データ活用」をうたってデータを公開しています。しかし「ただ公開すればよい」といったスタンスではなく、データを利用する人たちが本当に利用しやすいようなデータを公開していければ、よりみんながハッピーになるのかな思いました。

P.S.
[バフェットコード](https://www.buffett-code.com/)はXBRLをソースに業績データをデータベース化しているみたいだけど、どうやってるんだろう・・・