はじめに — 「アイデアを貯める」から「活用する」へ
IdeaSpool は、アイデアを記録し、AIの力で整理・分析するツールです。「ふとしたひらめきをすぐ書き留めて、あとから活用する」というシンプルなコンセプトで開発を始めました。
しかし、シンプルなコンセプトだからこそ、実際に作り込んでいくと多くの課題に直面します。AIにタグを付けさせると「React」「リアクト」「react.js」が混在してしまう問題。GitHub リポジトリにデータを保存する設計の限界。そして、蓄積されたアイデアを「ただ貯める」だけでなく「活用する」機能への進化。
この記事では、2026年1月の約2週間で IdeaSpool が v1 から v2 へと大きく進化した開発の舞台裏を、開発日記をもとに振り返ります。PMとして設計判断に集中し、実装を Claude Code に依頼するスタイルで、どうやって課題を乗り越え、どんな学びを得たのかをお伝えします。
AIタグ付けの一貫性問題 — 「禁止」より「推奨」が効く
IdeaSpool の Phase 2 で AI 自動タグ付け機能を Claude Code で実装しました。アイデアを登録すると、AI がその内容を解析して適切なタグを自動生成する機能です。
「React」と「リアクト」が混在する
最初のバージョンでは、AI に自由にタグを生成させていました。ところが、すぐに問題が発生しました。
2026年1月19日の開発日記にはこう書いています。
最初は AI に自由にタグを生成させていた。「React」「リアクト」「react.js」が混在して困った
同じ概念に対して異なる表記のタグが付くと、フィルタリングや検索の意味がなくなります。「React」で絞り込んでも、「リアクト」とタグ付けされたアイデアが漏れてしまう。アイデア管理ツールとして致命的な問題でした。
2つのアプローチで解決
この問題に対して、2つのアプローチを組み合わせて解決しました。
1. 既存タグ参照: AI にタグを生成させる際、過去に使われた既存タグのリストをプロンプトに含める方法です。「以下のタグが既に使われています。同じ概念であれば、既存タグを再利用してください」という指示を追加しました。
2. 日本語タグ強制: ターゲットユーザーが日本語話者であることを考慮し、英語タグの生成を禁止するルールをプロンプトに追加しました。「React」ではなく「リアクト」、「machine learning」ではなく「機械学習」で統一させます。
開発日記にはこう記録しています。
日本語タグ強制: 英語タグが混在すると視認性が悪い。ターゲットユーザーは日本人エンジニア
「禁止」より「推奨」の発見
この過程で得た最も重要な学びは、AI のプロンプト設計に関するものでした。
最初は「英語タグを生成するな」「新しいタグを作るな」という禁止形式で指示を出していました。しかし、禁止形式は AI が意図を汲み取りにくく、「英語タグを使わない代わりにカタカナ英語を生成する」といった迂回が起きることがありました。
そこで「既存タグを優先的に使ってください」「日本語で分かりやすいタグにしてください」という推奨形式に変更したところ、一貫性が大幅に向上しました。
開発日記に残したメモがまさにこれです。
AI のプロンプトは「禁止」より「推奨」の方が効果的
この気づきは、後のフレームワーク分析機能の AI プロンプト設計にも活かされることになります。出力形式を JSON にして構造化する、日本語で自然な文章を生成させつつパースしやすい形式にする、といった設計に「推奨」ベースのアプローチが効きました。
GitHub ストレージの限界 — 移行を決断するまで
IdeaSpool の v1 は、GitHub リポジトリに Markdown ファイルとしてデータを保存する設計でした。「コードと同じ場所にアイデアを管理できる」という発想はユニークでしたが、運用していくうちに限界が見えてきました。
3つの壁
v1 で直面した壁は3つありました。
1. GitHub API のレート制限: 1時間あたり5,000リクエストという制限は、個人利用では問題ありませんが、複数ユーザーが使う SaaS として考えると心もとない数値でした。N+1 問題が発生した際には、アイデア1件ごとに API を叩いていたため、数十件のアイデアを表示するだけでリクエスト数が急増していました。
2. リアルタイム同期の困難さ: GitHub の API はリアルタイム通知に対応していません。他のデバイスから追加したアイデアを別のデバイスで見るには、明示的にリロードする必要がありました。PWA として「ネイティブアプリ並みの体験」を目指す上で、これは大きな制約でした。
3. マルチテナント対応の複雑さ: 将来のチーム機能を考えると、ユーザーごとに GitHub リポジトリを管理する設計では拡張が困難でした。
移行先の選定 — Supabase を選んだ理由
2026年1月22日の開発日記には、移行先に Supabase を選んだ理由がこう記録されています。
GitHub ストレージの限界: GitHub API のレート制限（5000 req/hour）、リアルタイム同期が困難、マルチテナント対応が複雑
この課題を整理した上で、Claude Code と移行方針について議論しました。
Zeronova
IdeaSpool を SaaS 化するにあたって、GitHub ストレージから移行したい。レート制限とリアルタイム同期が主な課題。Firebase と Supabase のどちらが適していると思う？Claude CodeIdeaSpool は PostgreSQL の RLS（Row Level Security）との相性が良いと考えます。ワークスペース単位のアクセス制御をデータベース層で実現できます。また、pg_trgm を使えば日本語の全文検索にも対応可能です。Firebase の Firestore はスキーマレスで柔軟ですが、複雑なクエリや全文検索には向きません。Supabase をお勧めします。pg_trgm で日本語検索ができるのは大きい。タグだけでなく、アイデアの本文でも検索できるようにしたい。Supabase で進めよう。テーブル設計では、将来のチーム機能も見据えて users と workspaces は分離してほしい。
この判断が、その後の v2 アーキテクチャの基盤になりました。
1日で v2 の基盤を構築
2026年1月22日、Supabase のデータベーススキーマ設計から認証・CRUD・AI分析までを Claude Code で一気に実装しました。具体的には以下のテーブルを設計・適用しています。
users: ユーザー情報workspaces: ワークスペース（マルチテナントの単位）workspace_members: ワークスペースのメンバー管理（多対多）projects: プロジェクトideas: アイデア本体submissions: 外部からの投稿
RLS のポリシー設計では、シンプルさを重視しました。
-- ワークスペースメンバーのみアクセス可能
CREATE POLICY "workspace_member_access"
ON ideas FOR ALL
USING (
workspace_id IN (
SELECT workspace_id FROM workspace_members
WHERE user_id = auth.uid()
)
);
複雑なポリシーはパフォーマンスに影響するため、「ワークスペースメンバーかどうか」のチェックに統一しました。このシンプルな判定基準が、後の機能追加でも一貫したアクセス制御を維持する助けになっています。
v1 を捨てる勇気
翌日の1月23日には、v1 のコードとインポート機能を完全に削除しました。開発日記にはこう書いています。
技術的負債は早めに清算した方がいい。「いつか使うかも」で残すコードは結局使わない
v1 のコードを残しておけば、いざというときの保険にはなります。しかし、2つのバージョンのコードが混在すると、メンテナンスコストが倍増します。必要ならば Git 履歴から復元できるという判断で、完全削除を選びました。
v2 の進化 — 認証からビジュアライゼーションまで
v2 への移行後、IdeaSpool は急速に機能を拡充していきました。
認証の簡素化
1月24日、認証方式を Google OAuth のみに簡素化しました。当初は Magic Link（メールリンク認証）も用意していましたが、「メールが届かない」問題が頻発していたためです。
開発日記にはこう記録しています。
Google OAuth のみ: Magic Link は「メールが届かない」問題が頻発。Google Auth は即座にログインできて体験が良い
ターゲットユーザー（エンジニア・PM）のほぼ全員が Google アカウントを持っているという前提があったからこそ、思い切った判断ができました。
外部からのアイデア募集
v2 では、認証なしで外部からアイデアを投稿できる機能も Claude Code で実装しました。自分が運営するサービスのユーザーから、ログインの手間なくフィードバックを受け取る仕組みです。
ボット対策には Cloudflare Turnstile を採用しました。reCAPTCHA より軽量で、ユーザーにパズルを解かせる必要がない UX の良さが決め手です。また、AI 分析のコスト管理として、投稿時ではなく承認時にのみ AI 分析を実行する設計にしました。スパム投稿に対して AI トークンを消費するのを防ぐためです。
ビジュアライゼーション — 3つの視覚化ビュー
1月29日からは、蓄積されたアイデアを俯瞰するための視覚化機能を Claude Code で構築しました。
ネットワークグラフ: タグの共起関係をもとに、アイデア同士の関連性をノードとエッジで表現します。react-force-graph-2d を使い、Canvas ベースで高パフォーマンスに描画しています。タグベースの関連度計算には Jaccard 係数を採用しました。
ツリーマップ: プロジェクト→タグ、またはタグ→プロジェクトの階層構造で、アイデアの分布を面積で可視化します。d3-hierarchy でレイアウト計算のみを行い、DOM の描画は React に任せる設計です。
無限キャンバス: @xyflow/react を使い、アイデアカードを自由に配置・整理できるキャンバスです。
ネットワークグラフのラベル表示は特に苦労しました。開発日記によれば、v1 から v6 まで6回の改善を重ねています。常時表示だとラベルが重なり、ホバーのみだとノードを探すのが大変で、フォントサイズをズーム非依存にする必要がある。最終的に、吹き出しデザインで三角形の尾がノードを直接指すUIに落ち着きました。
フレームワーク分析を1日で実装 — Phase H の開発記
1月31日、IdeaSpool の目玉機能となるフレームワーク分析機能（Phase H）を1日で全10機能実装しました。
10機能の全容
Claude Code で実装した機能は以下の10個です。
- マトリックス分析ビュー: 2軸のマトリックス上にアイデアを配置。AI 自動配置対応
- SCAMPER / オズボーン AI 支援: 7つの視点・9つの質問でアイデアを発散
- 5W1H 構造化: 6つの観点でアイデアを構造化し、信頼度と完成度を表示
- ロジックツリー・MECE 分解: 4タイプのツリーで再帰的に分解
- AI クラスタリング・KJ 法支援: アイデアを自動グループ化
- 6つの帽子思考法: 6つの視点で多角的に分析
- 分析結果の永続化: 分析結果をデータベースに保存
- 履歴管理 UI: 過去の分析をタブ切り替えで閲覧
- ツール間連携: クラスタリング→マトリックス等、分析結果を次のツールに渡す
- モバイル対応: PC 推奨バナーと閲覧専用モード
Canvas か DOM か — 最大の技術判断
Phase H の設計で最も悩んだのは、マトリックス分析ビューの実装方法でした。
マトリックス分析では、ユーザーがアイデアカードを4象限にドラッグ&ドロップで配置する。DOM + CSS Grid と Canvas のどちらで実装すべきだろう。Claude CodeDOM + CSS Grid はドラッグ&ドロップのライブラリ（dnd-kit 等）が使えるメリットがありますが、アイデアの数が増えるとパフォーマンスが劣化します。特にリアルタイムで座標を更新しながら再レンダリングすると、フレーム落ちが発生する可能性があります。Canvas なら座標計算は自前になりますが、描画パフォーマンスは安定します。ネットワークグラフで Canvas の経験があるから、そのノウハウを活かせそうだ。パフォーマンスを優先して Canvas で進めよう。ドラッグ&ドロップは mousedown/mousemove/mouseup で自前実装してほしい。
開発日記にもこの判断が記録されています。
マトリックスの実装方法。案1: DOM + CSS Grid → ドラッグ＆ドロップのパフォーマンスが悪い。案2: Canvas → 座標計算が大変だが高速。→ Canvas を選択、ドラッグ＆ドロップは自前で実装
1月30日のネットワークグラフ改善で蓄積した Canvas のノウハウ（ズーム非依存のフォント描画、Force Layout のパラメータ調整など）が、ここで活きました。技術的な蓄積が次の機能開発を加速させる、良い循環ができていたと思います。
ツール間連携の設計
Phase H で特にこだわったのが、分析ツール間の連携です。「分析して終わり」ではなく、ある分析の結果を次のステップに活かせる設計を Claude Code に依頼しました。
- クラスタリング結果 → マトリックスに配置
- 6つの帽子思考法の結果 → 5W1H で構造化
- SCAMPER で発散したアイデア → クラスタリングで整理
状態管理には URL パラメータと sessionStorage の組み合わせを採用しています。sessionStorage で一時データを渡しつつ、URL でディープリンクも可能にする設計です。
コスト管理の意識
フレームワーク分析は AI トークンの消費が多い機能です。1回の分析あたり約1.5円のコストがかかります。Free プランでは月3回に制限する設計を Claude Code で実装しました。
1月29日の開発日記には、コスト試算の詳細も記録しています。
アイデア作成: 約 ¥0.39/件、AI分析: 約 ¥0.39/回。Free 最大利用時: 約 ¥56/月/ユーザー
PMとして、ユーザー体験とコストのバランスを取ることは重要な判断ポイントです。制限を厳しくしすぎるとユーザーが離脱し、緩くしすぎるとコストが爆発する。週次ローリング方式（月次ではなく週単位でリセット）を採用することで、「月末に制限に達して3週間待ち」という最悪のユーザー体験を回避しています。
セキュリティとパフォーマンス — 見落としがちな裏側
機能開発と並行して、セキュリティとパフォーマンスの改善も進めました。これらは目に見えにくい作業ですが、プロダクトの信頼性を支える重要な基盤です。
YAML インジェクション対策
v1 では GitHub リポジトリに Markdown ファイルとしてデータを保存していたため、ユーザー入力が Frontmatter に直接埋め込まれるリスクがありました。" を含む入力で YAML の構文が壊れたり、意図しないメタデータが注入される可能性がありました。
この問題は、1月20日のコードレビューで Claude Code が指摘し、特殊文字を含む場合はエスケープ処理を行う修正を依頼しました。v2 への移行でこのリスク自体は解消されましたが、「AI によるコードレビューでセキュリティ問題を早期に発見できた」という経験は、他のプロダクトの開発でも活かされています。
React.memo によるパフォーマンス改善
1月21日、Chrome でのパフォーマンス問題を修正しました。アイデアリストの再レンダリングで、すべてのカードコンポーネントが更新されていた問題です。
IdeaCard に React.memo() を適用し、Props が変わらないカードの再レンダリングを防止しました。さらに、animate-pulse（CSS アニメーション）が常時60fpsで再描画を要求していた問題も発見し、削除しています。
これらの修正は地味ですが、モバイル PWA としての体験品質に直結する改善でした。
振り返りと学び
約2週間の開発を振り返ると、いくつかの重要な学びがありました。
1. AI プロンプト設計は「推奨」ベースで
タグ付けの一貫性問題で得た「禁止より推奨」の原則は、IdeaSpool に限らず、AI を活用するあらゆる場面で応用できる知見です。AI に何かをさせたいときは、「やるな」と言うよりも「こうしてほしい」と伝える方が、期待どおりの結果を得やすいと感じています。
2. 技術的負債は早めに清算する
v1 の GitHub ストレージから v2 の Supabase への移行は、大きな決断でした。しかし、限界が見えた段階で早めに移行したことで、その後の機能開発（ビジュアライゼーション、フレームワーク分析、使用量制限など）がスムーズに進みました。「いつか使うかも」で v1 のコードを残していたら、移行のタイミングを逃していた可能性があります。
3. 事前の設計ドキュメントが1日開発を可能にする
Phase H を1日で10機能実装できた理由は、Claude Code の実装速度だけではありません。事前にどの分析ツールを作るか、ツール間をどう連携させるかの設計ドキュメントを用意していたことが大きい。PMとして「何を作るか」を明確にしておけば、Claude Code は驚くほど速く実装してくれます。
4. 技術の蓄積が次の開発を加速させる
ネットワークグラフの Canvas 実装で得たノウハウが、マトリックス分析の Canvas 実装に活きました。1つの機能で学んだ技術が、次の機能の判断基準になる。この積み重ねが、開発速度を維持する原動力になっています。
まとめ
IdeaSpool の v1 から v2 への進化を振り返りました。
AI タグ付け: 「禁止」より「推奨」のプロンプト設計で、一貫性の問題を解決しました。既存タグの参照と日本語タグ強制の組み合わせが効果的でした。
GitHub → Supabase 移行: レート制限、リアルタイム同期、マルチテナント対応の3つの壁を解消するために移行を決断しました。RLS によるデータベース層でのアクセス制御が、その後の機能開発の基盤になっています。
1日で10機能実装: 事前の設計と、ネットワークグラフ開発で蓄積した Canvas のノウハウが、フレームワーク分析機能の高速実装を支えました。
IdeaSpool の開発は、PMとして「何を作るか」「なぜ作るか」を判断し、Claude Code に「どう作るか」を任せるスタイルで進めてきました。AI との協業は、単に実装を速くするだけでなく、コードレビューによるセキュリティ問題の早期発見や、技術選定における客観的な比較分析など、開発プロセス全体の質を高めてくれています。
アイデアを「貯める」だけのツールから、AI で「活用する」ツールへ。IdeaSpool の進化はまだ続きます。
関連記事
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。