開発TODO

Summary

Waterfall Chart（ウォーターフォールチャート）の作成

経緯: Sankey → Waterfall への変更

当初は財務データの流れを可視化する予定でSankey Diagram（サンキーダイアグラム）を採用していたが、段階損益のマイナス値（費用・損失）が表現できないことに気づいた。

Sankey Diagramは「流量」を可視化するもので、本質的にマイナスの流れを持てない。一方、Waterfall Chartは：

• ✅ プラス（収益）とマイナス（費用）を明確に区別できる
• ✅ 段階的な損益の積み上げ・減算を直感的に表現
• ✅ Sankeyと同様の「流れ」の感覚を維持

結論: Waterfall Chart を採用

表示する指標

実装ライブラリ

• Plotly.js を採用（waterfall chart をネイティブサポート）

ステータス

• ライブラリ選定（Plotly.js）
• サンプルデータ構造の設計
• Vue コンポーネント作成
• 実際の財務データで表示

actual-consensus ページへのデータテーブル機能追加 🔴未了

nvidia-financial-chart のようなデータテーブル＋チャート連動機能を既存の actual-consensus ページに追加する。

📎 対象ページ: https://log.eurekapu.com/financial-quiz/actual-consensus 📎 参考実装: https://log.eurekapu.com/financial-data/nvidia-financial-chart

実装する機能

1. データテーブル表示
   • チャート下部に全指標のデータテーブルを表示
   • 四半期ごとの時系列データ
2. 指標のチェックボックス選択
   • チェックを付けた指標のみグラフに表示
   • Metricsセクションで表示/非表示を切り替え
3. 左軸・右軸の切り替え機能（重要）
   • 左軸: 金額ベースの指標（売上、利益など）
   • 右軸: マージン率・成長率
   • 「L/R」ボタンで軸の割り当てを操作

タスク

• nvidia-financial-chart の実装を参考に設計
• データテーブルコンポーネント作成
• 指標選択UI（チェックボックス）実装
• 左軸/右軸切り替え機能実装
• actual-consensus ページに統合

FastAPI + htmx プロトタイプ開発 ⏸️保留

AIスタートアップの初期フェーズ向けモック開発スタック。

📎 参考: https://zenn.dev/livetoon/articles/04dccf642d324c

検討結果

📎 詳細比較: 技術スタック比較

結論: FastAPI + Nuxt の組み合わせで十分

理由:

• AIモデルを使う場合でも、Pythonバックエンド（FastAPI）+ 現在のNuxtフロントエンドという構成で問題ない
• Nuxtの立ち上げはそれほど面倒ではない
• htmxを使う必要性が薄い（Nuxtで十分なUXを実現できる）

元々のなぜ FastAPI + htmx？

• Python統一: AI/LLM開発でPython必須の環境に最適
• セットアップ最小限: pip install fastapi uvicorn jinja2 のみ
• 単一サーバー: CORS設定不要、管理が楽
• htmx: HTML属性だけでJS不要の非同期通信

技術スタック

タスク（保留中）

• 新規プロジェクト作成（別リポジトリ）
• FastAPI + htmx 環境セットアップ
• SQLModelでモデル定義
• 基本的なCRUDサンプル作成
• htmxパターン（自動更新、検索、SSE）を試す

Hono + htmx + Cloudflare スタック ⏸️保留

Hono作者 yusukebe 提唱のシンプル＆高速スタック。

📎 参考: https://zenn.dev/yusukebe/articles/e8ff26c8507799

検討結果

結論: 現時点では保留

理由:

• TypeScriptで軽量アプリ向けには良い選択肢
• ただし、バックグラウンド処理（FFmpegなど）はCloudflare Workersでは実行不可
• MP4変換のようなヘビーな処理は Railway 等の別環境が必要
• 現在のNuxt + Cloudflare Pages構成で十分

技術スタック

なぜ Hono + htmx？

• JSXをサーバーサイドテンプレートとして使用: ハイドレーション不要で高速
• エッジ実行: Cloudflare Workersで低レイテンシ
• 超軽量: TODOアプリが100行程度、Gzip時22KB
• PHP/Rails的アプローチの現代版: シンプルなSSR + htmxでSPA不要

タスク（保留中）

• Hono + htmx のサンプル作成を検討
• D1との連携を試す

アニメーション動画のMP4変換バックエンド 🔴未了

現在のWebM出力をMP4に変換するバックエンド機能の検討。

現状の課題

• ブラウザ側でWebM生成 → MP4への変換が必要
• MP4の方が互換性が高い（iOS Safari、SNS共有など）

技術選定: FastAPI + FFmpeg

結論: MP4変換には FastAPI + FFmpeg が最適

Cloudflare Workers はサーバーレス/エッジの制約でFFmpegを直接実行できない。 動画変換は重い処理のため、サーバーフル環境が必要。

推奨アーキテクチャ

┌─────────────────────────────────────────────────────────┐
│  フロントエンド: Nuxt (SSR/SSG)                          │
│  - SEO対応（企業ページは静的生成）                        │
│  - 財務データ閲覧は誰でも可能                             │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  動画ダウンロード機能（会員限定）                         │
│  - 会員登録 → ログイン必須                               │
│  - WebM生成（ブラウザ）→ FastAPI に送信                  │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  バックエンド: FastAPI + FFmpeg                          │
│  - WebM → MP4 変換                                      │
│  - ホスト: Railway / Render / EC2 など                   │
└─────────────────────────────────────────────────────────┘

ビジネスモデル

重要: 静的MP4 vs 動的生成の判断

まず考えるべきこと: 本当にバックエンドが必要か？

パターン A: 静的MP4配信（バックエンド不要）⭐推奨

適用条件:

• データが固定（決算期ごとの更新のみ）
• ユーザーがカスタマイズしない
• 全ユーザーに同じ動画を提供

現在の財務データページ（QQQ構成銘柄等）はこれに該当！

❌ 非効率（毎回サーバーで生成）
ユーザーがボタン押す → WebM生成 → サーバーでMP4変換 → ダウンロード
（毎回同じ動画を生成...コストと時間の無駄！）

✅ 効率的（事前生成して静的配信）
事前にローカルでMP4生成 → /public/videos/ に配置 → ボタンでダウンロード

メリット:

• サーバーコスト $0（Cloudflare Pagesの静的配信のみ）
• ダウンロード 爆速（生成待ち時間なし）
• バックエンド 不要

パターン B: 動的生成（バックエンド必要）

適用条件:

• ユーザーが期間を自由に選べる
• ユーザーが表示指標をカスタマイズできる
• リアルタイムデータを使用する
• ユーザー固有のデータで動画生成

この場合のみ Railway 等のバックエンドが必要

バックエンドホスティングの詳細: バックエンドホスティングサービス比較

現プロジェクトの結論

QQQ構成銘柄ページ → パターン A（静的MP4）を採用

• データは固定（決算期更新のみ）
• カスタマイズ機能なし
• バックエンド不要、コスト $0

ただし、将来的にカスタマイズ機能を追加する場合はパターンBを検討。

タスク

• 静的MP4生成のワークフロー構築
• 動的生成が必要になった場合の Railway デプロイ準備
• 会員認証機能の設計（将来課題）