AIに"全部お任せ"で失敗した話。プロンプトの書き方を変えた7つの瞬間

結論：AIは優秀。でも「お任せ」では動かない

最初に正直に言います。

プログラミング経験ゼロの僕が、Claude Codeでサウナブログとこのブログの2サイトを作って運用しています。サウナブログの開発ログは85エントリ以上。AIとの付き合い方は、最初の頃と今とではまったく違います。

変わったのはAIの性能じゃなく、僕の伝え方でした。

この記事は、「Claude Code プロンプト コツ」で検索する方に向けて書いています。ただし、テンプレ的なTipsの記事ではありません。僕が実際にAIと一緒に作業する中で、「こう伝えたほうがいいな」と気づいた7つの瞬間を記録したものです。

ちなみにこの記事自体、最初はAIに書いてもらった内容でした。ブラッシュアップで確認したら、7つのエピソードのうち5つが作り話だったので、全部書き直しています。それ自体がこの記事のテーマ（瞬間4）になっているのは、なかなか皮肉な話です。

前提：僕のClaude Code歴

簡単に自己紹介だけ。

• プログラミング経験ゼロ。コードは今でも1行も書いていません
• サウナブログ（サウナと暮らす。）とこのブログの2サイトをClaude Codeだけで構築・運用中
• 最初はCursorを使っていて、Claude Codeに乗り換えました
• CLAUDE.md（AIへの取扱説明書）は3ヶ月で0行から100行超に育ちました。サウナブログ側はルールファイルを含めると2,000行を超えています

乗り換えの経緯はこちらに書いています。

7つの「プロンプトを変えた瞬間」

これから紹介する7つは、すべて実際にハマって、手戻りが発生して、「次からはこう伝えよう」と決めた瞬間です。

数字は厳密な計測値ではなく体感ベースですが、方向性は間違いないと思います。

瞬間1 —「AIが遠慮してくる」

何が起きたか

サウナブログのデザインを決める段階で、Claudeにプロのデザイナーとして提案してもらっていました。ディスカッションしながらコンセプトを固めて、方向性を絞り込んでいく——やり方自体はうまくいっていた。

ただ、ひとつ困ったことがありました。AIが僕の意見を尊重しすぎる。

僕は素人です。素人の「なんとなくこっちがいい」より、プロ目線での「こっちのほうが読者にとって見やすい」が欲しかった。でもAIは、僕が少しでも好みを示すと「いいですね、そちらの方向で進めましょう」と合わせてくる。僕が求めていたのは忖度じゃなくて、率直な意見だった。

もうひとつ。デザインの好みを言葉だけで伝えるのが、想像以上に難しかった。「落ち着いたトーンで」「シンプルなレイアウトで」——自分では具体的に伝えているつもりでも、AIの解釈と自分のイメージにはいつもズレがあった。

気づき

2つの改善をしました。

1つ目は、「忖度抜きで率直に意見を出してほしい」 と明確に伝えたこと。これだけで、AIが遠慮せずに「こちらの配色のほうがコントラスト比が高く、可読性が上がります」と代替案を出してくれるようになった。

2つ目は、言葉ではなくスクリーンショットで伝えるようにしたこと。自分が気に入っているブログのデザインをキャプチャして「こんな雰囲気にしたい」と見せる。言葉で100文字説明するより、画像1枚のほうが認識のズレが圧倒的に少なかった。

改善前のプロンプト

改善後のプロンプト

体感の変化: AIが「いいですね」と合わせてくるだけだったのが、根拠つきで代替案を出してくれるようになった。スクショを使い始めてからは、デザインの方向性が1〜2回のやりとりで固まるようになった。

瞬間2 —「なんか精度が落ちてきた」

何が起きたか

長時間の開発セッションを続けていると、途中からAIのアウトプットの質が落ちてくることに気づきました。さっきまで的確だった提案が微妙にズレてきたり、同じような修正を何度も繰り返したり。

最初は「AIの調子が悪いのかな」くらいに思っていたけど、原因はセッションのトークン消費でした。会話が長くなるほどAIが処理する情報量が増えて、精度が下がっていく。

気づき

今は、作業の区切りでAIに**「今ってセッションのトークンで余力ありますか？」** と聞くようにしています。

余力があれば「まだ大丈夫です」と返ってくるのでそのまま続行。精度が落ちそうであれば、引き継ぎ書を作成してもらって、新しいセッションで再開する。

これだけで、精度が低い状態のまま作業を続けて「なんか質が悪い」と感じるストレスがなくなりました。

ちなみに僕はClaude Maxプラン（月$100）を使っていますが、普通に使って上限の20%、ガッツリやっても50〜60%。トークンの余裕はあるので、セッションを切り替えることへの心理的ハードルも低いです。

瞬間3 —「デザインが統一されない」

何が起きたか

ブログ全体のデザインを統一したくて、「全ページのデザインを統一して」と伝えたことがあります。

結果、統一されませんでした。でもこれは指示が曖昧だったというより、僕自身が「何をもって統一とするか」のルールを持っていなかったのが原因でした。

カラーコードひとつ取っても、ページによって微妙に違う色が使われている。フォントサイズも、余白も、ボタンの角丸も——自分の中で「これが正解」が定まっていなければ、AIだってどこに揃えればいいかわからない。

気づき

やったことはシンプルでした。デザインが反映されていないページを見つけたら、スクショを撮って「ここが違う、こうしてほしい」と具体的に伝える。そしてAIが修正した結果を、ルールとして言語化して残す。

この「スクショで指摘→修正→ルール化」のサイクルを何度も繰り返した結果、カラーパレット、フォントサイズ、コンポーネントの使い方が全部ルールになった。今では新しいページを作っても、最初からデザインが揃うようになっています。

ポイント: デザインの統一は、一発で「統一して」と言っても実現しない。ズレを見つけるたびにルール化するという地道な積み重ねで固まっていく。

瞬間4 —「AIが書いた記事が作り話だった」

何が起きたか

これはつい最近の話です。このブログの記事をブラッシュアップ（品質改善）する作業を続けていたら、AIが書いた記事の中に事実と異なる内容が大量に見つかりました。

具体例を挙げます。

• 記事No.6（コスト記事）: WordPressのLighthouseスコアを「70-80台」と書いていたが、僕はそんな計測をしたことがない。AIが一般論として勝手に書いた
• 記事No.7（ツール比較）: 月額コストを「$40→$20に節約」と書いていたが、実際は$37→$100に増えた。節約の話ではなく投資の話
• 記事No.8（デザイン記事）: 「Tailwindの177種類のクラスを使用」と書いていたが、僕はクラスなんて意識したことがない。非エンジニアの読者もわからない
• そしてこの記事（No.9）自体: 7つの「失敗エピソード」のうち、5つがAIの作り話だった

AIは「それっぽいエピソード」を作るのが上手い。特に「非エンジニアあるある」系の失敗談は、一般論をベースに説得力のあるストーリーを構成できてしまう。でもそれは僕の体験ではない。

気づき

AIに記事を書かせたら、必ず自分で事実確認する。特に数字（コスト、スコア、回数）とエピソード（「こんなことがあった」系の話）は要注意。

今は記事のブラッシュアップ時に、必ず僕にヒアリングする工程を入れています。「この部分は実際にありましたか？」と聞いてもらうことで、作り話を潰していく。

教訓: AIは優秀だけど、僕の人生を生きていない。一次情報は僕の中にしかない。

瞬間5 —「情報が足りなければ質問して」

何が起きたか

サウナブログの記事を書くとき、僕は「記事を書いて」と丸投げはしません。記事構成リスト（キーワードと読者の悩みをまとめたスプレッドシート）から記事を指定して、プロジェクトコンテキスト（サウナの仕様、コスト、体験データをまとめたドキュメント）を読み込ませた上で、ディスカッションしながら書いています。

それでも最初の頃は、AIが手元の情報だけで記事を完成させようとすることがありました。僕の一次情報——サウナの電気代が月いくらか、導入に何ヶ月かかったか、実際に使ってみてどう感じたか——を自分から聞いてこない。結果、コンテキストファイルに書いてある情報だけで構成された、表面的な記事ができあがる。

気づき

解決策は単純でした。「情報が足りなければ何でも質問してくれ」とルールに加えただけ。

これだけで、AIの動きが大きく変わりました。「電気代のデータはありますが、太陽光発電との相殺後の実質コストはいくらですか？」「導入期間7ヶ月の中で、一番大変だった時期はいつですか？」——こちらが気づいていない角度から質問が飛んでくる。

自分では引き出せなかった情報をAIに引き出してもらい、それをまたコンテキストに還流させる。このサイクルを回すほど、記事の密度が上がっていくのを実感しています。

ポイント: AIに「質問していい」と許可を出すだけで、記事の深みがまったく変わる。許可がないと、AIは手元の情報だけで無理やり完成させようとする。

瞬間6 —「スマホで見たら崩れてた」

何が起きたか

PCで確認してコミットした後、スマホで同じページを開いたらデザインが崩れていた。これは一度ではなく、何度もありました。

PCのブラウザでは問題なく見えていたのに、実際のスマホ画面では文字が重なっていたり、ボタンが小さすぎてタップできなかったり。

気づき

やったことはシンプルです。崩れている画面のスクショを撮って、「ここが崩れてる、こう直して」と伝える。 これでほぼ解決します。

ただ、毎回コミット後に気づくのは効率が悪い。そこで「コミット前にスマホ実機で確認する」フローをルール化しました。CLAUDE.mdに「レスポンシブ確認は375px（スマホ）/ 768px（タブレット）/ 1280px（PC）の3サイズ」「確認前にgit操作はしない」と書いてあります。

ポイント: エラーもデザイン崩れも、スクショ1枚で伝わる。言葉で「崩れてる」と言うより、画像を見せるほうが圧倒的に早い。これは瞬間1のスクショ活用と同じ原則です。

瞬間7 —「ルールをファイルに残す」

何が起きたか

Cursorを使っていた頃、YouTubeでCursor Rulesというものを知りました。ルールを定義すれば、AIが自分の決めた通りにアウトプットを出してくれるという仕組みです。

Claude Codeに乗り換えるとき、「同じようなものがあるだろう」と調べたらCLAUDE.mdがありました。プロジェクトのルートに置いておくと、Claude Codeが毎回自動で読み込んでくれる。

最初は数行だった。「pnpmを使うこと」「Tailwind標準の青は使わないこと」くらい。それが、作業を重ねるたびに増えていった。デザインのカラーパレット、レスポンシブの確認サイズ、コミット前に確認を取ること——全部、実際の作業の中で「これはルール化したほうがいいな」と気づいたものです。

気づき

重要なのは、CLAUDE.mdを自分で書いていないということ。

僕はコードもルールファイルも書けません。やっているのは、AIとのやりとりの中で「こういうルールにしたい」と伝えること。すると、AIが最適な書き方でCLAUDE.mdに追記してくれる。Google Discoverで見つけた最新のベストプラクティス記事のURLを渡して「これを参考にCLAUDE.mdを改善して」と頼むこともあります。

今、このブログのCLAUDE.mdは100行超。サウナブログのほうはルールファイルを含めると2,000行を超えています。でもその1行1行を僕が書いたわけではない。僕がやったのは「こうしたい」を伝えること。書くのはAI。

振り返って気づいたこと

7つ書き出してみて気づいたのは、結局すべて**「僕の頭の中にある情報を、AIに渡しきれていなかった」**ということでした。

一番大事なのは、これらはAIに「プロンプトのコツを教えて」と聞いても出てこないということ。全部、自分で作業する中で「こうしたほうがいいな」と気づいたものです。

AIに聞いても出てこなかった「プロンプトの勘所」

最後に、この記事で一番伝えたいことを書きます。

AIは優秀だけど、僕の人生を生きていない

瞬間4で書いた通り、AIは「それっぽいエピソード」を作るのが上手い。このブログの記事も、最初はAIに書いてもらった内容をそのまま公開していました。ブラッシュアップで一つずつ確認していったら、事実と違う内容が次々に見つかった。

AIは一般知識をたくさん持っている。でも**「僕だけが知っている情報」はゼロ**。自分の体験、自分の感想、自分が本当に困ったこと——これを渡さなければ、AIは一般論で埋めるしかない。そしてそれは、読者にとって読む理由のない記事になる。

一番効くのは「仕組みにすること」

毎回のプロンプトでコツを駆使するより、CLAUDE.mdにルールを書いて仕組みにしてしまうほうが圧倒的に効果が高い。

しかも、ルールは自分で書く必要がない。「こういうルールにしたい」とAIに伝えれば、AIが最適な書き方で書いてくれる。最新のベストプラクティスを見つけたら、URLを渡して「これを参考に改善して」と頼めばいい。

プロンプトのコツを磨くより、仕組みを整える。 これが僕の結論です。

まとめ