Problem
用語は覚えたのに、腹落ちしない。
NISA をきっかけに資産形成を始めた段階で、決算やニュースに出てくる証券用語の意味が驚くほど腹落ちしなかった。
既存の用語辞典には 4 つの共通した問題 がある。
抽象度が高い — 「PER = 株価 ÷ 1 株利益」と読んでも、数値が動いたときに何が変わるのかイメージできない。
関連性が見えない — 用語同士の関係が言葉だけで示され、市場区分のような階層制度が頭に入らない。
プロセスが静的 — 「買建 → 返済」のようなフロー型の概念が文章だけで説明され、時系列の流れを追えない。
試験対策に寄り過ぎ — 証券外務員・FP の暗記本は網羅的でも、初心者が興味を持って読み進められる構成になっていない。
結果として「定義は読んだ」と「見て分かる」の間に大きな溝が残る。その溝を、自分のために 埋めたくなったのが出発点。
Approach
4 カテゴリの UI 型化 × 触って動く可視化。
数千語スケールでも UI が破綻しないよう、用語を最初から 4 カテゴリ に振り分け、カテゴリごとに可視化コンポーネントの型を決め打ちにした。
ファーストビューは React Server Components で静的に出し、スライダーで動くインタラクション部分だけを Client Component として Suspense でストリーミングする 3 層構造。初期描画は HTML だけで完結させ、"触れる" 必要のある部分にのみ JavaScript を届ける。
デザインは Material Design 3 の HCT カラーシステムに乗せ、個人開発で配色に時間を溶かさない構成にしてある。証券特有の「上昇 / 下落 / 市場区分」は標準 role の外なので --md-extended-* として別系統で定義し、WCAG AA だけは独立に担保する。
4 カテゴリの UI 型
A. 相場・分析 (ローソク足) / B. 財務・指標 (ゲージ) / C. 構造・制度 (ダイアグラム) / D. 取引・フロー (ステップ)。数千語でも統一感を崩さない型化。
スライダーシミュレーション
株価を動かすと PER ゲージが「割安 / 適正 / 割高」にリアルタイム連動。入力から描画まで 100ms 以内を目標化。
コマンドパレット検索
CmdK で開く検索。五十音 / カテゴリ / カード・リスト切替を一覧側で提供。
ニュース AI ペルソナコメント
公的機関 RSS に学習者ペルソナ付きで見解を生成。本文中から関連用語ページへ相互リンク。
Material Design 3 準拠
HCT パレット生成でダーク / ライト一貫。金融固有色は --md-extended-* で別系統化。
仕様駆動 × Claude Code
/spec-create → /spec-review → /spec-implement → /spec-verify の slash command 化。承認済み仕様書以外の実装を禁止する運用ルール付き。
Result
MVP はいま、"触って学ぶ" の原型を検証中。
2026-04 時点で、用語メタデータ 3,869 件、MDX 解説ページ 10 件、仕様書 20 件。4 カテゴリそれぞれで代表用語の詳細ページが機能している状態。v1 公開に向けて、コンテンツ執筆と仕上げを並走させている最中。
用語辞典の置換ではなく、"読まずに触る" 学習プレイグラウンドとしての当初の狙いがどこまで刺さるか、引き続き検証していく。
最新版は grahpedia.c12o.net で公開中。
Learnings
作ってみて分かったこと。
"UI の型" を先に絞ると、数千語スケールでも破綻しない
3,000 語を五十音順に並べた瞬間に導線は死ぬ。
先に 4 カテゴリに振り分け、カテゴリごとの UI 型を決め打つことで、コンポーネント設計と情報設計が同時に収束した。
機械分類 × 手動補正の二層構造は再利用できる
分類体系マスターと個別補正テーブルをファイルで分離すると、自動分類の精度不足が "運用で吸収できる問題" に変わる。
役割分担をファイル分離で明示する設計は他プロジェクトでも使いまわせる。
RSC / Client の境界は、ページ設計の "最初" に決める
ファーストビュー = RSC / インタラクション = Client / ディープダイブ = RSC の 3 層を先に決めておくと、コンポーネント分割に迷いが出なくなる。
スライダーで動く部分だけを Client に閉じ込めるのが最小構成の答えだった。
MD3 トークンは "配色に時間を溶かさない" ための投資
途中で独自トークンから MD3 の HCT カラーシステムに移行した。旧 → 新トークンの暫定エイリアスを置いて段階移行する戦略と、"金融固有色は標準 role の外に別系統で置く" 割り切りが効いた。
後から正しい抽象に乗り換えられる余白を残しておく価値は大きい。
仕様書が一次ソース — 書いていないことはやらせない
個人開発でも Claude Code と組むなら、仕様書 → 実装 → 検証のループを最初から固めたほうが早い。
仕様書に書いていない細部を気を利かせて実装されると、別の箇所との整合が崩れる。"仕様書が実装品質の上限" と割り切った運用で安定した。
コンテンツ執筆は必ずボトルネックになる
メタデータ 3,869 件に対して MDX は 10 件。"データ登録の速度" と "ライティングの速度" には 2 桁の差がある。
/register-terms と /term-auto を slash command 化して、人間の判断と Claude に任せる作業を明示的に分離した。
次のプロジェクトでは最初から "書ける範囲で順次公開する" 運用に倒す。