初めてのClaude Codeで、自分だけのメモアプリを作った話【前編：設計編】

Claude.aiとClaude Code、何が違うのか

最初に、これだけは押さえておいてほしいことがあります。

「Claude.ai」と「Claude Code」は、名前は似ているけど、別のものです。
僕は最初ここがよく分かっていなくて、途中で混乱しました。
なので、先に整理しておきます。

Claude.ai は、ブラウザで使うチャットです。

なんでも相談できて、「こういうアプリを作りたいんだけど、どう設計すればいい？」と聞けば、考え方を教えてくれます。
コードの意味を質問すれば、丁寧に説明してくれます。役割としては「相談相手」に近いです。

Claude Code は、ターミナル（黒い画面）で動くツールです。

こっちは実際にファイルを作り、コードを書き、コマンドを実行してくれます。
「このアプリを作って」と伝えると、本当にコードを書いて動くものを作ってくれるので、「一緒に手を動かしてくれるエンジニア」のような存在です。

今回の開発では、この2つを使い分けました。
Claude.aiで「なぜこう作るのか」を理解して、Claude Codeで「実際に作る」という流れです。
振り返ると、この二段構えが一番よかった判断だったと思っています。

何を作るか？ — 対話の中で見えてきた「本当に欲しいもの」

Claude Codeを使うにしても、最初に「何を作るか」を決めなきゃいけません。

僕はもともと「AI学習記録アプリ」を作るつもりでした。
本を読んで学んだことを記録するようなツールです。
Claude.aiに相談したところ、3つのアプリ案を提示してくれて、その中から「学習マイルストーン管理ツール」を選びました。

ところが、Claude.aiと対話を重ねるうちに、方向性が変わっていきました。

きっかけは、記録フォームの項目を決めているときです。
「本のタイトル」という入力欄を作ろうとしていたのですが、メモするなら、本からの学びだけじゃなくて「電車で聞こえてきた言葉」「カフェで考えたこと」「散歩中にふと浮かんだアイデア」から「何か気づいたこと」を残したいなぁって、ふと思ったんです。

Claude.aiにそう伝えたら、こう返ってきました。
「本のタイトル」という名前は狭すぎる、記録したいのは本からの気づきだけではないはずだ、と。
そして「ソース」「きっかけ」「出所」など、いくつかの代替案を出してくれました。

僕は「きっかけ」という言葉がしっくりきたので、それに決めました。
プレースホルダーには「例：OSHO『存在の詩』p.42 / 渋谷のカフェで / 朝の散歩中に」と表示することにしました。

こうして、「AI学習記録アプリ」は「心の気づきメモ」に変わりました。

この変化は、自分だけで考えていたら起きなかったと思います。
Claude.aiとのやり取りの中で、「本当に自分が欲しいものは何か」が少しずつ言語化されていきました。
設計の相談をしているつもりが、自分自身のニーズを発見する過程になっていたんです。

要求定義書 — 「何を作るか」を言葉にする

アプリの方向性が見えてきたところで、Claude.aiと一緒に「要求定義書」を作りました。

要求定義書と聞くと堅い印象がありますが、要するに「このアプリで何ができて、何はやらないか」を書き出したものです。
Claude.aiに「こういうアプリを作りたいんだけど、要求定義書を作ってくれる？」とお願いして、対話しながら仕上げてもらいました。

たとえば、こんなことを決めていきました。

「きっかけ」欄は任意入力にしました。
「これはどこから来た気づきなのか、自分でもわからない」という瞬間もあるので、入力を強制すると自由な記録ができなくなってしまうからです。

「きっかけ」欄にはオートコンプリート機能をつけることにしました。
同じ本から何度も気づきを記録するとき、毎回タイトルを手入力するのは面倒なので。

フォルダ分けやタグ付けは、最初のバージョンではやらないことに決めました。
まずは「書いて、保存して、読み返せる」だけの最小限で作ります。

この「あえてやらないこと」を決めるのが、実は一番大事でした。
Claude.aiはよく「全てを一度に作ろうとすると、途中で挫折する可能性が高い、それは能力の問題ではなく、開発というものの性質だ」と言っていたのが印象的です。

最初は「フォルダ分けも、スマホ対応も、エクスポートも欲しい！」と思っていました。
でもClaude.aiとの対話で、「フェーズ1はこれだけ」「残りはフェーズ2以降」と整理できました。
この切り分けができたことで、「まずは動くものを作る」という目標がはっきりしました。

技術設計書 — 「どう作るか」を決める

要求定義書の次は、技術設計書です。
こちらも、Claude.aiに教わりながら作ってもらいました。

技術設計書では、たとえばこういうことを決めていきました。

データベースは insights というテーブルを作って、id、user_id、trigger（きっかけ）、body（本文）、created_at、updated_at というカラムを持たせます。

認証方式は、このアプリが僕だけが使うものなので、本格的なログイン機能は作りませんでした。
代わりに、固定のUUID（ユーザーを識別する文字列）を環境変数に入れておく方式にしています。

ページ構成は、一覧ページ（/）、新規作成ページ（/new）、詳細ページ（/[id]）、編集ページ（/[id]/edit）の4画面です。

技術スタックは、Next.js + Supabase + TypeScript + Tailwind CSSを使います。

ここで大事なのは、僕がこれを「自分で書いた」わけではないということです。Claude.aiに「こういうアプリを作りたいんだけど、どう設計すればいい？」と聞いて、対話しながら作ってもらいました。

でも、その対話の過程で「なぜSupabaseを使うのか」「なぜログイン機能を作らないのか」「なぜこのテーブル構造なのか」が、自分の中で腹落ちしていきました。
Claude.aiが「こうしましょう」と言うだけじゃなく、「なぜそうするのか」を毎回説明してくれたからです。

たとえば、認証方式を決めるとき、Claude.aiは「ログイン機能を作る方法」と「固定UUIDを使う方法」を比較して、こう説明してくれました。
Noriさん専用のアプリなら、固定UUIDで十分ですよ、将来ほかの人にも使ってもらいたくなったら、その時にSupabaseの認証機能を追加すればいいですよ、と。

ただ「こうしてください」ではなく、「なぜこうするのか」「将来どう変えられるのか」まで含めて教えてくれるので、この丁寧さがすごく理解を助けてくれました。

ここまでで、1行もコードを書いていない

ここまでの過程を振り返ると、まだ、コードを1行も書いていないんです。

やったことは、Claude.aiとひたすら対話しただけです。
「何を作るか」「誰が使うか」「何をやって、何をやらないか」「どういう技術で、どういう構造で作るか」を、全部言葉で決めました。

正直、最初は「早くコードを書いてもらいたい」という気持ちがありました。
でも今振り返ると、この設計フェーズをしっかりやったおかげで、後の実装がびっくりするくらいスムーズに進みました。

Claude Codeに要求定義書と技術設計書を渡したら、それを読み取って、設計書の通りにコードを書いてくれました。
もしこの設計書がなかったら、Claude Codeは「何を作ればいいのか」が曖昧なまま動くことになって、出てくるコードも的外れになっていたと思います。

「設計書を作るなんて面倒だ」と感じるかもしれません。
でも、Claude.aiと対話しながら作ってもらえるので、自分でゼロから書く必要はありません。
大事なのは、その対話の中で「自分が本当に何を作りたいのか」が明確になることで、そこさえ固まっていれば、実装は思った以上に速く進みます。

前編のまとめ

前編で書いたことを整理します。

まず、Claude.aiとClaude Codeは別物だということ。Claude.aiは相談相手で、Claude Codeは作業してくれるエンジニアなので、両方を使い分けるのが大事でした。

次に、Claude.aiとの対話の中で、「AI学習記録アプリ」が「心の気づきメモ」に変わったこと。
自分だけで考えていたら気づかなかった「本当に欲しいもの」が、対話の中で見えてきました。

そして、要求定義書と技術設計書をClaude.aiと一緒に作ったこと。
自分で書いたのではなく、対話しながら作ってもらいましたが、その過程で「なぜこう設計するのか」が理解できました。

結果として、コードを1行も書かずに設計だけで半日以上かけましたが、これが後の実装をスムーズにしてくれました。

後編では、Claude Codeを使って実際にアプリを作り、デプロイするまでの体験を書きます。
セットアップでつまずいた話や、ローカルで動いた瞬間の話、本番環境でエラーが出た話などをお伝えします。