こんなことで困っていませんか
- Claude Codeを使い始めたいけど、何でやらかすか先に知っておきたい
- 利用量上限や料金が想定外にならないか心配
- すでに使っていて、想定外の動きをされてヒヤッとした
自分は非エンジニアです。Claude Codeを2ヶ月使ってきた間に、3回ヒヤッとしました。そのうち1回は、雑な指示をしたせいで成果物が全部書き換わってしまい、2時間かけて作り直す羽目になっています。最初に知っておけば避けられた失敗ばかりだったので、正直に共有します。
ちなみに、実は自分用に資材在庫管理ツールを作っていて、そのときに最初の失敗が起きました。詳しい話はこの後に書きます。
Claude Code 失敗談1｜利用量上限に気づかず作業が止まった話
最初の失敗は、「夜に放置していれば朝にはツールが完成しているはず」という思い込みでした。結果、月額$20のProプランでは上限に達して止まってしまい、$100のMaxプランに切り替える羽目になっています。
何が起きたか
自分用の資材在庫管理システムを作っているときのことです。指示項目を一気に詰め込んで「あとはよろしく」と投げて寝ました。朝起きてみると、想定した作業の半分くらいしか進んでいません。しかも、途中で利用量上限に達して止まっていました。
その場でどう対処したか
まず、プロンプトを小さく分けて投げ直しました。それでもすぐに上限に達してしまったので、最終的にはプランを変更して対応しました。
最初はProプランを使用していましたが、すぐに上限に達してしまい作業が進まなかったので、Maxプラン（月額$100）へ切り替えました。プラン変更で作業は再開できましたが、「夜放置すれば終わる」という前提そのものが間違っていた、というのが今振り返っての一番の学びです。
今やっている再発防止策
- 大きな依頼は最初から複数のセッション（＝Claude Codeとの一つのまとまった対話）に分割する
- 「夜放置すれば終わる」という期待をやめた
- 利用量は週1回ペースで確認する
放置運用は楽に見えますが、結局は朝に手戻りが出るので、最初から分割したほうが早いというのが今の結論です。具体的な朝30分のルーティンはClaude Code 使い方｜非エンジニアが朝30分でやる5つのことにまとめました。
Claude Code 失敗談2｜雑な指示で全ファイルが書き換わった話
これが一番ヒヤッとした失敗です。雑なプロンプトで全ファイルが書き換わってしまって、今までの成果物が全部ダメになりました。
どんな指示を出してしまったか
あるシステムの改善作業をしていたときのことです。範囲指定が曖昧なまま「全体的に改善して」というようなニュアンスで投げてしまいました。変えなくてもいいところまで書き換わってしまい、しかも雑な指示だったのでうまく改善も進んでいません。
具体的なプロンプトは、すでに消してしまったので原文は残っていません。ただ、振り返ると「範囲を切らないままお願いごとだけ投げた」のが致命的だったと思います。
戻すか、再構築するか
ここで悩んだのが、「git で戻すか、別セッションで再構築するか」という判断です（git＝コードの変更履歴を保存しておく仕組みで、過去のどの時点にも戻せる）。
結論として、自分は再構築のほうが早いと判断しました。理由は次の3つです。
- 戻すべき正しい状態が、自分のなかで明確に思い出せなかった
- もう一度書き直したほうが、前回の反省を反映できる
- 戻す作業の途中でさらにミスをするリスクがあった
別のセッションを開き直して、今度は最初に役割を与えて、範囲を具体的に指定し、プロンプトを分割しながらやり直しました。結果として、想定外リライト前よりもキレイな状態になりました。
結果として、再構築は2時間程度で完了しました。自分は非エンジニアなので、もしgitで戻していたら、どのコミットが正しい状態か特定するだけで30分以上はかかりそうでした。「戻す判断ができない状態で戻そうとするほうが、結果的に時間がかかる」というのが、自分の中での結論です。
今やっている再発防止策
- 依頼前に必ず git commit する習慣をつける（最初のセットアップ手順はClaude Code 始め方｜30分セットアップ全手順に書きました）
- 「このファイルだけ」「この関数だけ」と範囲を必ず書く
- 大きい依頼は分割する
「戻すコスト vs 再構築コスト」を冷静に比較できるかどうかは、git をちゃんと設定しているかにかかっています。これは最初の30分でやっておくべきことだったと、今は強く思います。
Claude Code 失敗談3｜役割指定なしで雑に投げていた時期の話
3つ目は、特定の1回というより、最初の頃ずっと続いていたクセの話です。
何が起きていたか
使い始めの頃、自分はプロンプトに「役割」を一切与えず、ただお願いごとだけを書いて投げていました。たとえばこんな感じです。
「このコード読みやすくして」 「この記事をいい感じにリライトして」
これだと、出てくるアウトプットがやけに汎用的で、自分が期待していた専門性が全然ないんです。なんとなく整っているけど、なんとなく違う。そういうズレが何度も続きました。
たとえばコードを読みやすくしてもらったとき、「リファクタリング」「カプセル化」「依存性注入」といった専門用語が3つも4つも並んだ説明が返ってきて、肝心の「で、何が変わったの？」が結局わからないまま終わる、ということが何度もありました。
具体的なプロンプトのスクショは残っていないのですが、今思えば「誰に頼んでいるかが定義されていない」状態でずっと依頼していました。
何を変えたか
転機は、プロンプトの冒頭に「あなたは○○の専門家です」と書くようになってからです。たとえばこんな感じに変わりました。
「あなたは非エンジニア向けの技術ライターです。このコードの動きを、専門用語を避けて200字以内で説明してください」
役割を与えるだけで、アウトプットの専門性と方向性が劇的に変わりました。同じClaude Codeなのに、別人に頼んでいるくらい違います。
役割なしのときは汎用的な説明で、しかも専門用語が多くてよくわからないままでした。それが「あなたは非エンジニア向けの技術ライターです」と指定するだけで、トーンが揃い、初心者の自分でもわかるような用語説明やわかりやすい解説に変わったんです。同じツールに同じ質問をしているのに、こんなに違うのかと驚きました。
今やっている再発防止策
プロンプトの最初に必ず役割を1行入れる。これだけです。シンプルですが、効果はとても大きいです。
3つの失敗から学んだ Claude Code 安全運用ルール
3つの失敗を経て、自分は今、次の3つのルールでClaude Codeを運用しています。
ルール1：役割を最初に与える
プロンプトの冒頭に「あなたは○○の専門家です」と必ず書きます。専門性をもった役割を与えることで、アウトプットの方向性が安定します。失敗談3の対策です。
ルール2：範囲を具体的に指定する
「全体的に改善して」ではなく、「このファイルのこの関数だけを修正して」と具体的に書きます。範囲を切らないまま投げると、想定外リライトが起きます。失敗談2の対策です。
ルール3：大きい依頼は分割する
一度に複数の作業を投げない。プロンプトを分割して、1セッション1テーマで進めます。失敗談1の対策でもあり、利用量管理にも効きます。
このルールは、AIに前提を共有するコツ｜在庫3,700種で学んだ話で書いた「AIに丸投げしない・前提を渡してから判断は人が残す」という考え方とも繋がっています。
Claude Code をもう一歩使いこなすための3つのコツ
ここからは、3つの運用ルールに慣れてきた方向けに、さらに失敗を減らすコツを3つだけ紹介します。どれも自分が実際に試して効果を感じたものです。
コツ1：プロンプトはクロードAIやチャットGPTで下書きする
最初のプロンプトが思い浮かばないときは、いきなりClaude Codeに書き込まなくて大丈夫です。自分の場合、クロードAI（Claude.ai）やチャットGPTで下書きを作ってから持ち込むようにしています。
理由はシンプルで、Claude Codeはコードを書く強さがある分、プロンプトのトークンも消費します。雑なプロンプトで何度もやり直すと、それだけで上限に近づきます。先に別のチャットAIで整えてから渡したほうが、結果的に早くてお得です。
コツ2：一発で完璧を目指さず、何度も壁打ちする
下書きを作るときも、Claude Codeに依頼するときも、一発で完璧なプロンプトを書こうとしないことをおすすめします。
「こういうツールが作りたい」とだけ書いて、相手から「どんな入力項目が必要ですか」「画面はどんな構成ですか」と聞き返してもらう。そのやり取りを何度か重ねることで、自分の頭の中もだんだん整理されていきます。これが壁打ちです。
最初の頃は「ちゃんと書かないと申し訳ない」と思って身構えていましたが、今はざっくり書いて何度もやり取りするほうが結果的に速いと感じています。
コツ3：プランモードで計画フェーズを挟む
3つ目はClaude Code特有のコツです。いきなりコードを書かせるのではなく、プランモードを使って「何をするか」の計画だけ先に立ててもらうやり方です。
プランモードは、Claude Codeのチャット欄で Shift + Tab を1〜2回押すと切り替わります（モード表示が変わるのですぐにわかります）。
プランモードを使うと、Claude Codeは実装の前に「こういう手順でやります」という計画を出してくれます。そこで自分が「ここは違う」「この順番でやってほしい」と修正できるので、いきなり書かせて全ファイルが書き換わるような事故を防げます。
しかも、計画フェーズはコードを書く段階よりトークン消費が抑えられるので、失敗談1の利用量上限対策にもなりますし、失敗談2の範囲外書き換え対策にもなります。両方に効く、いいとこ取りのコツです。
広告表記
本記事は Google AdSense によるディスプレイ広告を表示しています。広告の表示は Google の配信ロジックによるものであり、筆者は表示される具体的な広告内容を選択していません。広告主と筆者との間に金銭的・契約的関係はありません。なお、本記事中で言及している Claude Code（Anthropic, PBC 提供）について、筆者は Anthropic 社から記事執筆に関する金銭・物品の提供を一切受けていません。料金・仕様は執筆時点（2026年5月）の情報です。
Claude Code を非エンジニアが安全に使い始めるための次の一歩
ここまで読んでくださった方は、おそらく「これからどう始めればいいか」を知りたい段階だと思います。自分が今振り返って、この順番で読みたかったという順で並べました。
- まずは30分でセットアップする：Claude Code 始め方｜30分セットアップ全手順 → 失敗談2で書いた「git commit する習慣」のセットアップ手順もここで完了します
- セットアップ後の最初の1週間：Claude Code 使い方｜非エンジニアが朝30分でやる5つのこと → 失敗談1の「分割して進める」を朝30分の具体的なルーティンに落とし込んだ記事です
- AIに前提を渡すコツを整理したい：AIに前提を共有するコツ｜在庫3,700種で学んだ話 → 「AIに丸投げしない・前提を渡して人の判断を残す」考え方を在庫管理の実例で書いています
迷ったら、まず1番から。30分あればセットアップまで終わります。
読者へのひとこと
最初の2ヶ月で3回ヒヤッとしました。でも、その3回があったから今の運用ルールができた。完璧に使いこなしてから始める必要はないと、自分は思います。
まとめ
- 利用量上限・想定外リライト・指示ミスの3つは、最初に知っておけば回避できる失敗
- 対策はシンプルに3つ：役割を与える／範囲を指定する／大きい依頼は分割する
- もう一歩進めるコツは：他AIで下書き／壁打ちで具体化／プランモードで計画フェーズ
- 失敗してもgit と再構築判断があれば戻せる。だから一歩目を踏み出して大丈夫
- まずは30分セットアップ記事から。git設定さえ済ませておけば、失敗談2のような事故は防げます
