本業は経理、個人開発は趣味の たび です。上場企業の決算（有価証券報告書）を全社ぶんまとめて集め、平均年収・勤続年数・離職率などをランキングで見られるWebアプリ 「kessan-tracker」 を作って公開しました。→ kessan.pgsideworks.com
たび「あの会社の平均年収、実は有報に載ってる」。それを全上場企業ぶん集めて、横断で比べられるようにしました。
何を作ったか
EDINET（金融庁の開示システム）のAPIから、全上場企業約3,800社 × 最大10年分の有価証券報告書を取得し、自前のWebアプリで公開しています。見られるのは、企業一覧・決算履歴に加えて、平均給与／平均勤続年数／平均年齢／離職率のランキング。数字はすべて一次情報（有報）が出どころです。
なぜ作ったか
決算情報は公開されているのに、横断で比べる・ランキングで見るのは意外と面倒です。「経理のデータ」を「個人開発」で触ってみる実験として、いちばん興味のある決算×お金をテーマに選びました。
仕組み（ざっくり）
- 取得バッチ（Python）：EDINET APIからXBRL（決算データの構造化フォーマット）を取得・解析
- 表示（Next.js／TypeScript）：サーバー側で直接データベースを読んで描画（SSR）
- データベース（PostgreSQL）：約3,800社・約39,000件の報告書データを格納（容量は25MBほど）
一番ハマったのはXBRLのタグ差異
決算データは会社ごとにバラバラではなく、XBRLという共通形式で公開されています。ところが実際に取り込むと、会計基準や業種でタグが違う。J-GAAPとIFRS、さらに銀行・保険といった業種、単体決算——それぞれ「同じ項目」でもタグ名が変わります。ここを吸収する処理が、このアプリで一番手間のかかった部分でした。
デプロイは「VPS」から「AWS」に方針転換
最初はVPSにセルフホストするつもりでした。でも既存の自分のインフラを確認したら、実際はAWS（Lightsail）ベース。「既存に合わせる」という当初の判断根拠が、そもそもAWSを指していたわけです。そこでAWS Lightsailへ転換しました。
- 月$7の最小プラン1台に、Web・DB・バッチを同居（DBが小さく低トラフィックなので十分）
- TLSはCaddyの自動取得（Let’s Encrypt）。CloudFrontは今回は使いませんでした——SSRでフロントとバックが同じプロセスのため分離の旨みが薄く、低トラフィックではコスト差もほぼ無いからです
- 決算は毎日自動で差分更新（スケジュール実行）
学び
「既存パターンに合わせる」は正しい。ただし「“既存”が何か」を事実で確認してからでないと、判断の土台ごとズレます。ここは反省点でした。
AIとの協働（今回も）
役割分担は前回のテーマ自作と同じです。要件定義・設計・優先順位は自分、実装のたたき台はAI、レビューと本番反映の判断は自分。決算データは「どのタグをどの項目に対応させるか」の見極めが肝で、ここは経理の実務感覚がそのまま効きました。コードが書けるかより、何を作るかを決められるか、です。
まとめ
公開されているデータでも、集めて・揃えて・見せ方を工夫すると価値が変わる。個人でも、AIと組めば「全上場企業ぶん」みたいな規模に手が届きます。
個人開発の前作（自作WordPressテーマ）はこちら。→ AIで自作WordPressテーマに乗り換えた話｜表示速度3倍・PageSpeed96点
経理×AIの実践は連載にまとめています。→ 連載「経理をAIに任せる」（全4回）
このブログ「経理のAI仕訳帳」では、経理×AIの業務改善・個人開発・お金の実験を、再現できる形で記録していきます。
