【ITニュース解説】Earnings week from the filings, not the headlines: one script on a free API key

このニュース記事は、株式の決算情報を取得し分析するシステムを構築した開発者の実体験について解説している。システムエンジニアを目指す皆さんにとって、実際の開発現場でどのように問題に直面し、解決していくのか、そして外部のAPI（Application Programming Interface）を利用する際にどのような注意が必要かを知る貴重な事例となるだろう。

開発の目的は、投資家が関心を持つ銘柄（ウォッチリスト）について、毎決算発表期に生じる三つの疑問に自動で答えることだった。一つ目は、今週どの銘柄が決算を発表するのか。二つ目は、すでに発表された銘柄の決算内容が、ニュースの見出しに惑わされず、実際にどうだったのか。そして三つ目は、決算発表と同じ期間にどのようなマクロ経済指標（例：政策金利の発表など）が公開されるか、という点である。これらの情報を手作業で集めるのは手間がかかり、見出しに偏った情報に流されるリスクもあるため、客観的かつ効率的に情報を得るシステムが必要とされたのである。

このシステム構築には、AlphAIという情報提供サービスのAPIが利用された。開発者は、新しいユーザーが試すように、無料のAPIキーを使用して開発を進めた。無料のAPIキーには厳しい利用制限がある。具体的には、1分間に20回、1日あたり100回までしかAPIリクエスト（APIへのデータ要求）ができないという制約である。この制約の中で、いかに効率的にデータを取得するかが開発の出発点となった。

スクリプトは主にPythonというプログラミング言語で記述された。AlphAIが提供するPython用のSDK（Software Development Kit）であるalphai-sdkを使って、銘柄ごとの決算情報を取得した。しかし、マクロ経済カレンダーの情報を取得するAPIは、当時SDKでサポートされていなかったため、httpxというライブラリを使って直接HTTPリクエストを送信し、データを取得する必要があった。これは、外部APIを利用する際によくある状況で、SDKが提供されていない機能は自分でHTTPリクエストを構築して対応しなければならないことを示している。スクリプトのほとんどは取得したデータを整形し、人間が読みやすい形式（MarkdownカードやJSONログ）に出力するための処理で、APIとの直接のやり取りは比較的少なかった。

実際にスクリプトを実行して取得できた情報は多岐にわたる。マクロ経済カレンダーからは、FOMC（連邦公開市場委員会）の政策金利決定や小売売上高といった重要な経済イベントの日程が確認できた。これは、個別企業の決算発表が、その時の経済状況によってどのように評価されるかに影響するため、非常に重要な情報である。個別の銘柄については、会社が公式に発表した次の決算発表日、そして過去の決算に対する「read」（構造化された分析レポート）が得られた。例えば、OracleやAdobeの決算は「strong」（強い）と評価され、詳細な財務指標や将来の業績見通し（ガイダンス）、さらには報告書に記載されなかった項目まで網羅されていた。この「read」は、ニュースの見出しだけでは分からない、企業の実際の状況を把握するために役立つ。ただし、このAPIは会社が公式に発表した決算日しか提供しないため、まだ発表日が確定していない銘柄については情報が得られなかった。また、「read」は2026年7月28日以降に提出された決算報告書に限定されており、それ以前の決算には適用されないというカバレッジの限界もあった。

開発を進める中で、いくつかの問題に直面したが、その多くは迅速に解決された。当初、決算報告に含まれる財務数値の単位やスケール（例：百万ドル、十億ドル）が統一されておらず、比較が困難であった。しかし、この問題はAPI側で修正され、数値データに加えて単位とスケールが明示的に提供されるようになった。これにより、スクリプトで数値を正確に比較・分析できるようになったのである。また、APIからの応答が空（データなし）の場合に、SDKがエラーを発生させる問題も発生したが、これも修正され、SDKが適切にNone（データなし）を返すように改善された。特定の銘柄コードの形式（例：BRK.BではなくBRK-B）の入力ミスや、SDKが検索パラメータを適切に扱えない問題も修正された。これらの問題がわずか1日で解決されたことは、開発チームの迅速な対応力を示している。

しかし、まだいくつかの課題は残っている。前述の通り、「read」が利用できる決算報告は2026年7月28日以降のものに限られており、それ以前のデータは不足している。また、会社が公式に発表した決算日しか提供されないため、未発表の銘柄には日付情報がない。さらに、特定の企業の決算報告書がAPIに取り込まれないという、データ取り込み側のバグも発見された。API自体にも、カレンダー情報を取得する際の日付範囲指定の解釈が、他のニュース情報取得APIと異なるという一貫性のない部分が残っている。SDKについても、APIの全機能を網羅しておらず、リトライ（再試行）のデフォルト設定が不十分であるといった点が挙げられている。これらの課題は、APIを継続的に改善していく上で重要なフィードバックとなるだろう。

特に重要な課題の一つは、APIのレート制限（利用頻度制限）への対応であった。開発者は、無料ティアの「1分間に20リクエスト」という制限が、実際にどのように動作するのかを検証した。実験の結果、リクエストとリクエストの間に3.2秒の遅延を入れると、制限に達することなくスムーズに処理が完了した。しかし、制限を意識せずフルスピードでリクエストを送ると、多くのリクエストが「429 Too Many Requests」（リクエストが多すぎる）というエラーで拒否された。これは、APIがリクエスト数を「スライディングウィンドウ」という方式で計算しているためである。つまり、直近1分間のリクエスト数が常に監視されており、瞬間的な集中アクセスではすぐに制限に達してしまうのだ。さらに、APIが返す「Retry-After」という、次にリクエストを送信できるまでの推奨待機時間も、当初は不正確で、その情報を信頼すると再びエラーになるという問題があった。この問題もAPI側で修正されたが、この経験から、APIのレート制限に効率的に対応するための実践的なルールが導き出された。それは、「最初のリクエストから、APIが許容するペース（今回の場合は約3秒に1回）でリクエストを分散させて送信する」というものである。この方法が、エラーを避け、最も効率的にデータを取得する道であると結論付けられた。

この一連の開発経験は、システムエンジニアを目指す皆さんにとって多くの学びがある。外部APIを利用したシステム開発では、APIの利用規約や制限を事前にしっかりと理解することが不可欠である。また、SDKが常に完全であるとは限らず、不足する部分は自分で実装する能力も求められる。そして、開発中に予期せぬ問題（データ形式の不統一、APIのバグ、レート制限の複雑な挙動など）に直面することは避けられないが、それらを一つ一つ特定し、解決していくプロセスが、より堅牢で信頼性の高いシステムを構築するために重要である。今回の記事は、単に情報取得スクリプトを作ったというだけでなく、その裏側で繰り広げられた試行錯誤と問題解決のリアルな記録なのである。