AIの説明がわからなくてブチギレた結果、開発がうまく回り始めた話

AI体験談・その他
もやもやしたものが絡み合っているイラスト
第2回では、ログインと記事のCRUD機能を作りました。 基本的な骨格は動くようになったのですが、開発を進めるなかでストレスが溜まっていきました。 今回は、AIとのコミュニケーションで壁にぶつかった話と、そこから生まれたルール、そしてMarkdownエディタと画像アップロード機能の実装について書いています。

「もう何を聞いたらいいのかわからない」

開発が進むにつれて、あるストレスがじわじわと溜まっていきました。

Claudeの説明が、飛ばし飛ばしになるのです。

たとえば、「このファイルを作ってください」とコードを渡されて、書いてみる。でも、そのコードが何のために存在するのか、なぜこの書き方なのかの説明がない。聞けば答えてくれるのですが、聞かないと説明してくれない。
最初のうちは「わからないところがあったら聞こう」と思っていたのですが、そもそも何がわかっていないのかがわからない状態では、質問の仕方すら思いつきません。

一番困ったのは、説明の順番が飛ぶことでした。
「まずAを書き換えます」と言われた直後に「ではBの説明から入ります」と切り出されて、「さっきAって言ったのに、なんでいきなりBなの?」と混乱する。理由を聞けば「BはAが依存するファイルだから先に作る必要がある」と返ってくるのですが、それを最初に言ってほしかったわけです。

こういうことが何度も続きました。
コードの意味を聞いたら概要だけ返ってきて、具体的な1行ずつの説明がない。CSSを読み込む行があるのに、「そのCSSは何に使われているのか」の説明がない。こちらから「全部説明してほしい」と伝えても、次のセクションではまた同じことが起きる。

正直、イラっときました。

我慢できなくなって、かなりきつい言い方でフィードバックしました。
「概要だけじゃなくて、細かくコードを教えてくれないと困る」
「全部説明してほしいと伝えましたよね」
これはかなり抑えた表現ですが、冷静に読み返すと、けっこう感じの悪い言い方をしています。
ただ、その時は本当にフラストレーションが限界でした。

このフィードバックをきっかけに、Claudeとの間で「説明の順序」についてのルールが生まれました。

まず、ユーザー体験として何が変わるかを説明する(「この機能を作ると、画面上で何ができるようになるか」)

なぜそれが必要なのかを説明する

コードを提示する

コードの1行1行の意味を説明する

Claudeのプロジェクトの指示に追加した内容のスクショ

それまでのClaudeは、3(コードを提示する)からいきなり始めることが多かったのです。
でも自分が知りたいのは、まず「何のためにこれをやるのか」で、コードはその後でいい。この順番が共有されてからは、だいぶスムーズに進むようになりました。

振り返ると、このフラストレーションはAI特有の問題というわけではないと思います。
人間同士の仕事でも、「こちらが何をわかっていないか」を相手が正しく把握してくれないと、同じようなすれ違いは起きます。
大事だったのは、「わからない」と言えたことと、どう説明してほしいかを具体的に伝えられたことでした。ブチギレという形ではありましたが。。

テキストエリアからMarkdownエディタへ

記事の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エディタ、画像アップロードと、管理画面としてはひと通りの機能が揃いました。
残る大きなステップは、これを外部の人にも読めるようにする「公開ページ」の実装です。次の記事で、完成までの最後のステップと全体の振り返りを書いています。

感想やコメントをいただけるとうれしいです。