結論：Claude Codeは魔法じゃありません。非エンジニアの自分でも5回はガッツリやらかしました。先に笑って読んでおくと、たぶん同じ失敗を踏まずに済みます。
- ハマった時間の合計：たぶん15時間以上
- 一番ヒヤッとした失敗：APIキーをGitHubに公開しかけた話
- 一番損失が大きかった失敗：理解してないコードを放置した話
Claude Codeって賢いよね。ぼくみたいな非エンジニアでも、お願いすればなんでも作ってくれる感じ。
うん、確かに賢いです。でも **「お願いすれば全部やってくれる」** と思っていると、わりとガッツリ転びます。今日はぼくの転倒記録を5つ、笑い話にして共有させてください。
「Claude Code、これから触ってみたいけど、なんか怖いな」 — そんな人向けの予防接種記事です。
誰向けの記事か
これ、誰が読むといいの?
**Claude Code をこれから触る人** と、**すでに触っているけど時々事故っている人** です。失敗のパターンを先に知っておくと、同じ轍を踏まずに済みます。
具体的には次のような方を想定しています。
- Claude Code に興味はあるけど、何が危ないのか分かっていない
- 触り始めて1〜3ヶ月、楽しいけど時々ヒヤッとする
- 「Claude が書いたコード、自分はあんまり分かってない」と薄々気づいている
技術解説ではなく、「先に笑って読んでおくと、いざという時に踏ん張れる失敗集」 として書きました。
失敗1：「全部いい感じにして」で3時間ハマった話
やばい度：★★★☆☆
最初の失敗、なに?
**指示が雑すぎて、Claude Code が「いい感じ」を勝手に解釈した** 失敗です。3時間溶けました。
ある日、ブログのデザインを少し変えたくて、こう頼みました。
ブログのトップページ、もうちょっといい感じにして
3時間後、出てきた画面はぼくが想像していたものと全然違いました。
- 想像：ヘッダーの色を少し変える、フォント大きさを微調整する
- 現実：トップページのレイアウトが2カラムに変わり、サイドバーが出現し、配色がダークモードに
Claude Code は悪くないんです。「いい感じ」の幅が広すぎて、彼が知ってる「いい感じのブログ」を全力で作ってくれただけです。
⚠️ Claude Code への雑な指示が事故る理由
- 「いい感じ」「ちょっと」は人によって基準が違う — Claudeは平均的な「いい感じ」で作ってくる
- 修正範囲が指定されていないと、全部触る — 「色だけ」「フォントだけ」と限定しないと全面改修される
- 3時間の作業を「ちょっと」と思っていない — Claude Codeはお仕事しすぎる
📌 指示は「やりたいこと」だけでなく「やりたくないこと」も書く が事故防止の鉄則。「ヘッダーの色だけを #333 から #555 に。それ以外は触らないで」と言えば、3時間ハマることはなかったです。
教訓：「いい感じ」は禁句。具体的な変更先と「触らない場所」を必ず指定する。
失敗2：APIキーをGitHubに公開しかけた話
やばい度：★★★★★
2つ目、もしかしてセキュリティ系?
**Cloudflareの API トークンを `.env` に書いて、`.gitignore` に追加するのを忘れて push しかけた** 話です。気づいた瞬間、血の気が引きました。
シーンはこうです。
- 個人開発を始めて1週間目
- Cloudflare Workers にデプロイするため、API トークンを
.envファイルに保存 - 「とりあえず GitHub にコミットしておこう」と
git add .を実行 git statusを見たら、.envがコミット対象に含まれていた
push する前に気づいたから良かったものの、もし気づかずに push していたら…
| もし公開していたら | リスク |
|---|---|
| Cloudflare API トークン | 第三者がぼくのアカウントを操作可能 |
| Workers のデプロイ権限 | 任意のコードを本番に流し込まれる可能性 |
| ドメインのDNS設定権限 | サイト乗っ取り |
⚠️ APIキーをGitHub公開リポにpushすると、数分で世界中のbotにスキャンされて悪用 されます。盗まれた後にトークンを無効化しても、悪用済みのリスクは残ります。
📌 リポジトリを作った瞬間にやるべきこと
- .gitignore に .env を追加（最初に書く、後から書くと忘れる）
- リポジトリは Private で作る（公開しないなら絶対 Private）
- Cloudflare Workers は wrangler secret put でシークレット管理（コードに直書きしない）
教訓：.gitignore は リポジトリを作った瞬間 に書く。後回しにすると忘れる。
失敗3：個人情報をうっかり記事に書いてしまった話
やばい度：★★★★☆
3つ目、なに?
**ブログの下書きに自分の本名と住所を書いていて、公開前にプレビューして気づいた** 話です。気づいたから良かったものの、もし公開していたら一生消せません。
シーンはこうです。
- ブログ記事を書く時、最初は自分用メモとして本名や住所を書いてしまうことがある
- 例：「○○区××町の家賃相場を調べて、自分の家賃と比べたら…」
- 推敲しているうちに、メモ部分を消し忘れる
- プレビュー画面で 「あ、自分の名前が残ってる」 と気づく
幸い、公開前に気づいたので大事には至りませんでした。しかし 公開していたら GitHub の履歴・Wayback Machine・スクショ等で永久に残る ので、取り返しがつきません。
⚠️ 公開後に消しても、痕跡は残ります
| 痕跡が残る場所 | 消せる? |
|---|---|
| GitHubの履歴（rebase で消すのは事故のもと） | ほぼ消せない |
| Wayback Machine（archive.org） | 申請で消せる場合あり、確実ではない |
| Google検索のキャッシュ | 数日で更新されるが、その間は晒される |
| 読者のスクショ・SNS拡散 | 永久に消せない |
📌 公開前のセルフチェック手順 1. Ctrl+F で「自分の本名」を検索 → ヒットゼロを確認 2. Ctrl+F で「自分の住所」（都道府県・市区町村）を検索 → ヒットゼロを確認 3. Ctrl+F で「自分のメールアドレス」を検索 → ヒットゼロを確認 4. Ctrl+F で「自分の電話番号」を検索 → ヒットゼロを確認
教訓：個人情報は 「下書き段階でも書かない」 が一番安全。書く必要があれば「○○」「××」と伏せ字でメモする。
失敗4：PR表記なしでアフィリエイトリンクを貼ってしまった話
やばい度：★★★★☆
4つ目、これも法律系?
**ステマ規制（景品表示法5条3項）に違反する状態で記事を公開しかけた** 話です。1記事目を書いた直後に「あ、PR表記つけ忘れた」と気づきました。
シーンはこうです。
- ASP（アフィリエイト・サービス・プロバイダ）の申請が通り、初めてアフィリエイトリンクを記事に埋め込んだ
- 「これで収益化スタートだ!」とテンション上がって公開ボタンを押す寸前
- PR表記がない ことに気づく
- 公開ボタンを押す前に止まれて、慌ててPR表記を追加
ステマ規制は2023年10月から施行されていて、違反すると消費者庁から 措置命令・課徴金（売上の3%）・社名公表 の対象になります。広告主であるアフィリエイター本人が責任を負います。
⚠️ ステマ規制のポイント
| 項目 | 内容 |
|---|---|
| 施行日 | 2023年10月1日 |
| 義務の主体 | アフィリエイト記事を書く運営者 |
| 違反時の措置 | 措置命令・課徴金・社名公表 |
| 表記基準 | 一般消費者に 明瞭に分かる 位置 |
📌 手書きのPR表記運用は事故ります。書き忘れが構造的に起こるので、テンプレ化してフラグ管理に振り切るのが正解。当サイトでは is_pr: true を JSON に1行追加するだけで、PRバッジと通知ボックスが自動表示される仕組みにしています。
詳しい仕組みは 前回の記事「PR表記を is_pr: true 1行で自動化した話」 で解説しています。
教訓：ASP申請が通った瞬間に、1記事目を書く前に PR表記のテンプレを作る。後から直すのは10倍コストがかかる。
失敗5：理解してないコードを放置 → 動かなくなって詰んだ話
やばい度：★★★★★
5つ目、これが一番痛かったやつ?
**Claude Code が書いたコードを「動いてるからOK」で放置していたら、数日後にAPIの仕様変更で動かなくなり、自分で読めず、Claudeに聞いても再現できず詰んだ** 話です。最終的に該当機能を作り直しました。
シーンはこうです。
- Claude Code に「○○APIを叩いて××を取得するスクリプトを書いて」と依頼
- スクリプトが完成、動いた
- 「動いてるからヨシ!」と中身を読まずに本番運用に組み込む
- 3日後、突然動かなくなる
- エラーメッセージを見ても、自分が書いたわけじゃないので何のことか分からない
- Claudeに「直して」と頼む → 別の書き方で実装し直され、また理解できないコードになる
- 修正のたびに別物になっていく → デバッグ不能
これが 「動いてるからOK」症候群 です。短期的には楽ですが、長期では破綻します。
⚠️ 理解してないコードが負債になる流れ
- 「動いた」で満足する — その瞬間は嬉しい
- 何が書かれているか説明できない — 「Claudeがやってくれた」状態
- 動かなくなる — APIの仕様変更・依存ライブラリの更新で必ず起きる
- 直せない — 自分が読めない＋Claudeも前のコードを覚えていない
- 詰む — 作り直すしかない、時間も精神もごっそり削られる
📌 Claude Codeが書いたコードは、自分の言葉で説明できる状態にする - 各関数に「ここで何をしているか」のコメントを書かせる（日本語で） - 重要な処理は 「これはどういう意味?」と Claude に聞く クセをつける - 動いたらすぐ commit、修正前のバージョンを残す（git の出番）
教訓：「Claude が書いたコード」は 「自分が書いたコード」と同じ責任を負う。動いた瞬間に「これは何をしているコードか」を口頭で説明できる状態にする。
5つの失敗を一覧で振り返る
5つの失敗、一覧で見たい!
表にしました。**やばい度と時間損失** で並べると、優先して対策すべきものが見えてきます。
| # | 失敗 | やばい度 | 時間損失 | 一言で言うと |
|---|---|---|---|---|
| 1 | 「いい感じにして」で3時間 | ★★★ | 3時間 | 雑な指示は事故のもと |
| 2 | APIキーをGitHubに公開しかけ | ★★★★★ | 5分（気づいた時点） | .gitignore は最初に書く |
| 3 | 個人情報を記事に書いてた | ★★★★ | 10分（気づいた時点） | 公開前にCtrl+F |
| 4 | PR表記なしで公開しかけ | ★★★★ | 30分（修正） | テンプレ化で構造的に防ぐ |
| 5 | 理解してないコードを放置 | ★★★★★ | 12時間以上（作り直し） | 動いた瞬間に説明できる状態に |
📌 対策コストが安いのは1〜4番。1番は指示の書き方を変えるだけ、2〜4番はテンプレを1回作れば終わり。5番だけは習慣の問題 なので、毎回意識する必要があります。
失敗から学んだ3つの習慣
これからClaude Codeを触る人に、何を伝えたい?
3つの習慣だけ覚えてください。これで90%の事故は防げます。
✅ Claude Code を1年触って身についた3つの習慣
- 指示は「やる」と「やらない」をセットで書く — 「ヘッダーの色だけ変える、それ以外は触らない」
.gitignoreと PR表記テンプレは初日に書く — 後回しにすると100%忘れる- 動いたコードは「説明できる状態」にする — 自分の言葉で何をしているか言えなければ、まだ完成じゃない
特に3番は、最初は面倒に感じますが、長期で運用するなら必須の習慣 です。
やっておくと安心な「予防接種」リスト
Claude Code を触り始める前に、何をしておくと良い?
3つだけ、初日にやっておくと安心です。
1. GitHubリポジトリは必ず Private で作る
公開リポジトリは「全世界から見える」状態です。個人開発で公開する必要は基本ありません。
| 公開設定 | 用途 |
|---|---|
| Private（推奨） | 個人開発・社内開発・実験用 |
| Public | OSS として配布する場合のみ |
2. .gitignore のテンプレを最初に用意する
最低限、以下を .gitignore に書いておきます。
.env
.env.local
.env.production
*.log
node_modules/
.DS_Store
__pycache__/
3. PR表記のテンプレを「ASP申請前」に仕込む
ASP申請が通った瞬間に1記事目を書きたくなりますが、先にPR表記テンプレを作る のが正解です。詳細は 前回記事 を参照してください。
やる前に絶対知っておくべき注意点
他に注意点ってある?
2つだけ、絶対知っておいてください。
1. Claude Code は「やりすぎる」ことがある
「ちょっと直して」と頼むと、関連する10箇所を直してくることがあります。「触ってほしい範囲」を明示 することで防げます。
ヘッダーの背景色を #333 から #555 に変更してください。
他のファイル・他のCSSプロパティ・HTML構造は一切変えないでください。
このくらい強めに書くと、意図通りの変更だけが行われます。
2. 動いた瞬間が一番危ない
「動いた!」のテンションで本番運用に組み込むと、理解してないコード が本番に紛れ込みます。1日寝かせて、翌日に「これは何をしているコードか」を自分で説明できるか確認するクセをつけると安全です。
💡 個人開発は 「速度」より「読めるコードを残す」 が長期では勝ちます。Claude Code は速いので、説明できる状態にする時間を意識的に取る価値があります。
学んだ3つのこと
今回の振り返りで得た一番の学びは?
失敗は最高の教科書だ、ということです。**特に「やばい度★5」の失敗は、本に書いていない肌感** を教えてくれます。
✅ 5つの失敗から学んだ3つのこと
- Claude Code は賢いが、ぼくの意図は読めない — 指示の質が結果の質を決める
- セキュリティと法律対応は「初日に仕込む」が最安 — 後から直すと10倍コストがかかる
- 「動いた」より「説明できる」が本当のゴール — 短期の楽さが長期の負債を生む
最後に：自分の思い
これから Claude Code を触る非エンジニアに、何を伝えたい?
**「失敗するのは普通です」** ということです。ぼくは1年で5回ガッツリやらかしました。たぶん、これからも何回かやらかします。
非エンジニアの自分が Claude Code を触り始めた時、最初に思ったのは「賢いAIが全部やってくれる」でした。
しかし1年触ってみて、「Claude Code は最高の相棒だけど、ぼくの責任は全部ぼくのもの」 だと分かりました。指示の質も、セキュリティも、PR表記も、コードの理解度も — 全部、自分が責任を持つ範囲です。
それでも Claude Code を使い続けるのは、失敗のコストより、作れるものの楽しさが圧倒的に大きい からです。
5回やらかしたけど、5回とも復帰できました。全部、誰でもやる失敗 だったからです。
💡 これから Claude Code を触る人へ。「やらかしても大丈夫」 です。やらかしてから対策する、を繰り返すうちに、いつの間にか上手くなっています。
「失敗しないように」じゃなく、「失敗してもすぐ立ち上がれるように」 仕組みを整える — これがぼくが1年で身につけた、Claude Code との付き合い方です。
これからも、笑い飛ばせる失敗を量産しつつ、楽しく作っていきます。
この記事のシリーズ：ブログ立ち上げ全工程・プライバシーポリシー作成・PR表記の自動化 と合わせて読むと、「非エンジニアがブログを安全に運営する全体像」が見えます。
この記事も Claude Code に書いてもらいました。「結論先行・一文60文字以内・数字を使う・誰向けか明確・自分の思いで締める」の5点を意識した版です。