
目次
開発が進むにつれて、あるストレスがじわじわと溜まっていきました。
Claudeの説明が、飛ばし飛ばしになるのです。
たとえば、「このファイルを作ってください」とコードを渡されて、書いてみる。でも、そのコードが何のために存在するのか、なぜこの書き方なのかの説明がない。聞けば答えてくれるのですが、聞かないと説明してくれない。
最初のうちは「わからないところがあったら聞こう」と思っていたのですが、そもそも何がわかっていないのかがわからない状態では、質問の仕方すら思いつきません。
一番困ったのは、説明の順番が飛ぶことでした。
「まずAを書き換えます」と言われた直後に「ではBの説明から入ります」と切り出されて、「さっきAって言ったのに、なんでいきなりBなの?」と混乱する。理由を聞けば「BはAが依存するファイルだから先に作る必要がある」と返ってくるのですが、それを最初に言ってほしかったわけです。
こういうことが何度も続きました。
コードの意味を聞いたら概要だけ返ってきて、具体的な1行ずつの説明がない。CSSを読み込む行があるのに、「そのCSSは何に使われているのか」の説明がない。こちらから「全部説明してほしい」と伝えても、次のセクションではまた同じことが起きる。
正直、イラっときました。
我慢できなくなって、かなりきつい言い方でフィードバックしました。
「概要だけじゃなくて、細かくコードを教えてくれないと困る」
「全部説明してほしいと伝えましたよね」
これはかなり抑えた表現ですが、冷静に読み返すと、けっこう感じの悪い言い方をしています。
ただ、その時は本当にフラストレーションが限界でした。
このフィードバックをきっかけに、Claudeとの間で「説明の順序」についてのルールが生まれました。
まず、ユーザー体験として何が変わるかを説明する(「この機能を作ると、画面上で何ができるようになるか」)
なぜそれが必要なのかを説明する
コードを提示する
コードの1行1行の意味を説明する

それまでのClaudeは、3(コードを提示する)からいきなり始めることが多かったのです。
でも自分が知りたいのは、まず「何のためにこれをやるのか」で、コードはその後でいい。この順番が共有されてからは、だいぶスムーズに進むようになりました。
振り返ると、このフラストレーションはAI特有の問題というわけではないと思います。
人間同士の仕事でも、「こちらが何をわかっていないか」を相手が正しく把握してくれないと、同じようなすれ違いは起きます。
大事だったのは、「わからない」と言えたことと、どう説明してほしいかを具体的に伝えられたことでした。ブチギレという形ではありましたが。。
記事のCRUDが動くようになって、「基本機能はこれでおしまいですか?」とClaudeに聞いてみました。
返ってきた答えは、「動く骨格はできたけど、CMSとして使えるかというとまだ足りない」でした。
確かに、今の状態だと本文の入力はただのテキストエリアで、見出しも太字も使えない。リッチテキストエディタは「あったら便利な装飾」ではなく、CMSの本質的な機能だと言われて、なるほどと思いました。
エディタの方式は、MarkdownとWYSIWYG(Notionのような操作感のエディタ)の2択で、Markdownを選びました。
ブログ用途ならMarkdownで十分だし、実装もシンプルだとClaudeに言われたのと、自分もMarkdownの基本的な書き方は知っていたからです。
実装が終わって、ただのテキストエリアだった編集画面にツールバー付きのMarkdownエディタが入ったときは、見た目の変化に驚きました。
左側にMarkdownを書くと、右側にプレビューがリアルタイムで表示される。太字や見出しのボタンもツールバーに並んでいる。急に「それっぽいツール」になった感じがしました。


ただ、このセクションの実装でも説明が飛ぶ場面がありました。
CSSを読み込む1行があるのに、そのCSSが何に使われているのか説明がない。聞いたら「エディタの見た目を作るスタイルシートです」と返ってきたのですが、それを先に言ってほしかった。
前のセクションで共有した「説明の順序ルール」が、まだ完全には馴染んでいない時期の話です。
Markdownエディタの次は、画像のアップロード機能です。
記事に画像を入れるには、まず「画像をどこに保存するか」という箱を用意する必要がありました。Supabase Storageという機能を使って、「article-images」というバケット(保管場所)を作るところから始めます。
このバケットの設定で、「Public bucket」をONにするかどうかという判断がありました。Claudeに説明されて納得したのですが、ブログの記事に埋め込む画像は「ログインしていない読者にも見える」必要があるので、ONにしておかないと公開ページで画像が表示されなくなります。
設定を終えて、アップロード機能を実装して、いざテスト。画像を選択したら「アップロード中...」と表示されて、そのまま待っていたら「画像のアップロードに失敗しました」というエラーが出ました。

ブラウザの開発者ツールを開いてエラーの詳細を確認する、という手順をClaudeに教わりながら進めました。
エラーログを修正してもう一度試してみたところ、今度は成功しました。
左側のエディタに画像のMarkdown記法が自動で挿入されて、右側のプレビューに画像が表示されている。初めて自分のアプリに画像が載った瞬間でした。

最初のエラーは一時的な接続の問題だった可能性が高く、コード自体に問題があったわけではなさそうです。
ただ、エラーが出たときに「何が原因かわからない」という状態はやっぱり不安でした。
Claudeが「エラーの詳細をコンソールに出力するようにコードを修正しましょう」と提案してくれたおかげで、原因の切り分けができました。
ここまでで、ログイン、記事のCRUD、Markdownエディタ、画像アップロードと、管理画面としてはひと通りの機能が揃いました。
残る大きなステップは、これを外部の人にも読めるようにする「公開ページ」の実装です。次の記事で、完成までの最後のステップと全体の振り返りを書いています。