日本の上場企業は、金融庁の電子開示システムEDINETを通じて、財務諸表をXBRL形式で開示しています。データは公開されていますが、活用は容易ではありません。書類の数は膨大で、タクソノミは日本語で定義されており、同じ数値が報告書ごとに変わることもあります。

Kabukenは、日本株のファンダメンタル分析のために当社が自ら開発したプラットフォームです。EDINETのXBRL書類から財務データを抽出して構造化し、日本語と英語で提供します。提供方法は、Webアプリケーションと、ClaudeなどMCP対応のAIアシスタントが企業の開示書類を直接照会できるMCPサーバーの2つです。

Kabukenの設計・開発・運用はすべて当社で行っています。以下では、お客様のシステムにも活かしている設計判断のうち2つを詳しく紹介し、最後に短い補足を添えます。

制約。 当社が利用しているデータベース基盤では、インデックスのエントリー1件ごとに書き込みとして課金されます。テーブルのインデックスが増えるほど、行を1件挿入するたびの課金額が膨らみます。そして、財務書類の処理は本質的に書き込みの多い処理です。

実施したこと。 スキーマの進化とともにインデックスが積み重なっていました。これはよくあることで、見直されることはほとんどありません。私たちは、インデックスがコストに見合っていると決めつけず、監査を行いました。コードベースを2通りの独立した方法で追跡し、さらに本番スキーマに対してクエリプランを分析した結果、到達し得るすべてのクエリが文書IDで解決されていること、そして実際に使われていたインデックスはごく一部であることが確認できました。残りはすべて削除しました。

結果。 文書1件あたりの課金対象の書き込み回数は大幅に減り、ストレージ使用量も大きく削減されました。

意義。 書き直したコードはなく、失われた機能もありません。コストが、データの実際の照会方法と一度も照らし合わされていなかっただけです。確認にかかったのは数日ですが、削減効果は恒久的に続きます。

制約。 日本の上場企業は、開示書類の間で数値を訂正することがあります。四半期報告書で報告された財務項目が、有価証券報告書で改めて報告される際に、正当な理由で異なる値になる場合があります。

実施したこと。 各ファクトは、それを報告した特定の書類に属します。書類を再処理しても、置き換えられるのはその書類自身のファクトだけです。書類をまたいで値を重複排除したり統合したりすることはありません。また、財務項目を名前だけで識別することはなく、必ずそれが記載された報告コンテキストと組み合わせて識別します。

意義。 ここでは、一見当然の最適化が誤りになります。書類間で重複する値をまとめればデータ量は減りますが、ユーザーが最も重視する情報が失われます。書類間の変化そのものが重要なシグナルであり、訂正はそれによって初めて見えるようになるからです。ストレージは安価ですが、失われた監査証跡は取り戻せません。

本番環境に書き込むツールはすべて、実行前に累積の課金対象書き込み数を固定の上限と照合し、その数値を確認できない場合は実行を拒否します。自らのコストを確認できないバックフィルは開始されません。従量課金のデータベースに対する一括再処理こそ、クラウド費用が際限なく膨らむ原因になるからです。

同じエンジニアが、お客様のシステムのアーキテクチャコンサルティングとミッションクリティカルなソフトウェア開発を担当します。