Claude Codeガチ勢の実戦開発術【完全版】
文章目录
Claude Codeに、予約アプリを作ってもらった。
画面もできて、「実装は完了しました」って報告まで返ってきた。
…で、触ってみたら動かない。
直してもらったら、今度は別のところがおかしくなる。
いや、これ無限ループやん！！！
コードを書く時間は減ったのに、確認して、問題を伝えて、また確認する仕事はまるっと残ってるんですよね。
気づいたら、自分が【付きっきりの確認係】になってるやつ。
じゃあ、Claude Codeを作ってる本家のチームは、この問題をどう片づけてるのか。
2026年10月15日に公開された「How the Claude Code team does code review」に、その答えがかなり具体的に書いてありました。
ざっくり言うと、
「できました」を信じるのをやめて、確かめ方そのものをClaudeに任せる仕組みを作ってる。
って話。
元の記事は、会社でソフトを開発するエンジニア向けの内容です。
この記事では、そこから「自分でアプリを作る人」がそのまま使える部分だけを抜き出して、6つの実戦術にまとめました。
今週はセキュリティのニュースも続いたので、その備え方もあわせて入れています。
最後には、予約アプリを例に、ガチ勢の流れを最初から最後まで通してみます。
ちなみに、この記事で紹介する頼み方は、どれもそのままコピーして使えるようにしてあります。
コードが読めなくても大丈夫です。
やることは、Claude Codeへの頼み方を少し変えて、自分が見る場所を決めるだけなので。
本家は、コードの約9割をClaudeが書いている
まず、ガチ勢の中のガチ勢の話から。
元の記事によると、Claude Code自身のコードの約90%を、Claudeが書いてるそうです。
えぇぇ、作ってる道具の中身まで、ほぼClaude製。
しかも、6月から9月にかけて、こんな変化があったと報告されてます。
-
取り込まれた変更の数：2倍以上
-
あとから取り消しが必要になった変更の割合：40%以上ダウン
作る量が倍になったのに、失敗の割合は減ってる。
ん？たくさん作ったらミスも増えるじゃんって思ったかもしれないんですけど。
そうならないように、確認の仕組みを作り込んだってことなんですよね。
もう1つ、おもしろい数字があります。
Claudeのレビューを入れてから、「意味のある指摘」がついた変更の割合が、16%から54%に増えたそうです。
これは「バグを見つける精度が54%」って意味じゃありません。
人が気づかずに素通りさせてた変更にも、ちゃんと指摘が入るようになった、ってことです。
ただし、どれもチーム自身の運用報告です。
同じことをすれば誰でも同じ結果になる、という実験ではありません。
それに「9割をClaudeが書いた」は、判断や責任まで9割任せたという意味でもないです。
数字に振り回されず、どうやって確かめてるかに注目してください。
ガチ勢は「確認をやめた」んじゃない
ここ、勘違いしやすいところです。
本家のチームは、確認を省いて速くなったわけじゃありません。
むしろ、作ってる途中から公開したあとまで、何重にも確認を重ねてる。
変わったのは、【誰が確認するか】です。
動かして確かめられることは、先にClaudeや自動のチェックに任せる。
人は、そのあとに残った「人じゃないと決められないこと」だけを見る。
しかもチームは、確認にかかる時間だけじゃなく、見逃した不具合をあとから直す時間まで「人の負担」として数えてます。
確認を減らしても、そのぶん後始末が増えたら意味がないからです。
確認の時間が、【後始末の時間】に引っ越しただけになっちゃう。
これ、自分でアプリを作るときも同じなんですよね。
確認をサボって公開したら、あとで「動かない」「データが消えた」の連絡が来て、結局そっちに時間を取られる。
★★確認を減らすんじゃなく、確認を任せる★★
この考え方を持てるかどうかで、Claude Codeの使いこなしの差がここから一気に開く。
実戦術①「できました」じゃなく、証拠を出させる
本家のチームがまずやってるのは、人に見せる前に、Claude自身に結果を確かめさせることです。
-
テストを動かして、通ったか見る
-
実際にアプリを起動してみる
-
画面のスクリーンショットを撮って、目指したデザインと比べる
求めてるのは「できました」って返事じゃなく、実際に確かめた結果です。
Claude Codeの開発者のBoris Cherny氏は、確かめる方法を与えるだけで、最終的な品質が2〜3倍良くなると見積もってるそうです。
ただ、これは本人の推定なので、倍率よりも「何を確かめさせるか」を大事にしてください。
ありがちな失敗
たとえば、予約アプリに「予約を消せるボタン」を足してもらったとします。
Claudeは「削除ボタンを追加しました」と報告してくる。
でも実際に押してみたら、画面からは消えたのに、ページを再読み込みしたら復活してた。
あるある()
これ、Claudeが嘘をついたわけじゃないんです。
「ボタンを追加する」ところまではやったけど、「本当に消えたか」を確かめてなかっただけ。
だから、頼むときに「何をもって完成とするか」まで渡しておくんですよね。
証拠をもらう頼み方
頼むときに、こう書き足すだけで変わります。
作業が終わったら、「完了しました」とだけ言わずに、次を見せてください。
・実際に実行したコマンドと、その結果 ・アプリを起動して、画面のスクリーンショット ・試した操作（例：予約を登録して、一覧に出るか）とその結果 ・確かめられなかったことがあれば、その理由
最後の「確かめられなかったこと」が地味に大事なんですよね。
全部うまくいったように見せる報告より、確かめた範囲がはっきりしてる報告のほうが、次に何をすればいいか分かります。
作るものごとの「確かめ方」の例
-
予約アプリ：登録→一覧に出る→再読み込みしても残る、まで試してもらう
-
問い合わせフォーム：空欄で送ったら止まる、正しく入れたら届く、の両方を試してもらう
-
データの整理（CSVなど）：整理する前と後の件数が合ってるか数えてもらう
-
画面のデザイン：スマホの幅でもスクショを撮って、文字が隠れてないか見てもらう
確かめ方が分からないときは、先に決めてもらう
「何を確かめればいいか、そもそも分からない」って人も多いと思います。
それ、普通です。
そんなときは、作り始める前に、確かめ方そのものをClaudeに提案してもらえばいいんですよね。
これから〇〇を作りたいです。まだ作り始めないでください。
完成したと言えるかどうかを、私が自分で触って確かめられる方法を、5つ以内で提案してください。 それぞれ、どんな操作をして、どうなっていれば合格かを書いてください。
出てきた確かめ方を見て、「これでいい」と決めたら、それを完成の条件として作ってもらう。
先にゴールを決めておくと、Claudeも自分で確かめながら進められるようになります。
今日から、完了報告には必ず証拠をつけてもらってください。
実戦術② 確認役は「何も知らない別のClaude」にする
作ったClaudeに「ちゃんとできてる？」って聞くと、だいたい「できてます」って返ってきます。
そりゃそうなんですよね、作った本人なので()
本家のチームは、それまでの作業の会話を見ていない別のClaudeに、変更をレビューさせてます。
前の流れを知らないからこそ、思い込みに引っぱられずに見られる。
手元で同じことをやるなら、方法は2つあります。
-
Claude Codeで/code-reviewを使う（作業の会話を見ていない別の担当が、変更を確認してくれる）
-
新しいセッションを開いて、作りたいものの説明を渡し、「書き方の好みは無視して、ちゃんと動くかだけ見て」と頼む
ここでのポイントは、確認役に「完璧に直ったらしい」と先に伝えないことです。
先に評価を伝えると、確認役もそれに引っぱられやすくなります。
本家は、指摘そのものも疑ってる
本家がさらに上手いのは、レビューで出てきた指摘を、そのまま人に渡さないところです。
-
複数のClaudeが、手分けして問題を探す
-
別のClaudeたちが、「その指摘、本当に正しい？」と確かめる
-
みんなが「正しい」と言った指摘だけを残す
-
書き方の好みだけの指摘は外す
しかも、今回の変更で生まれた問題と、もともとあった問題を分けて扱ってます。
前からあった問題まで今回の作業のせいにすると、話がどんどん広がっちゃうからです。
ちなみに、1,000行を超える大きな変更は、ほとんど何かしら指摘されて、小さい変更は「指摘なし」になることも多いそうです。
何かを必ず指摘するのが、レビューの目的じゃないんですよね。
自分でやるなら、確認役にこう頼むと近い形になります。
この変更を確認してください。まだコードは変更しないでください。
・指摘ごとに、根拠になるファイルと行を示してください ・書き方の好みに関する指摘は不要です ・今回の変更で生まれた問題と、前からあった問題は分けてください ・問題がなければ「問題なし」とはっきり書いてください
指示のファイルは、短く育てる
もう1つ、本家がやってるのが、指示を書いたファイルを短く保つこと。
Claudeに毎回読ませるCLAUDE.mdは、使う技術や守るルール、今回やらないことなど、前提だけを短く書く。
たとえば、予約アプリならこれくらいで十分です。
予約アプリ
- 個人で使う予約管理アプリ
- データはこのパソコンのブラウザに保存する
- ログイン機能・外部公開・決済は作らない
- 作業が終わったら、実行結果とスクリーンショットを見せる
- 頼まれていない場所は変更しない
注意書きを足し続けるんじゃなく、何度も同じミスが出たときだけ、一行足すくらいがちょうどいいんです。
確認役には、作った本人じゃないClaudeを必ず立ててください。
実戦術③ 直す往復は、回数を決めて止める
ここが、元の記事で一番おもしろかったところです。
本家のチームで、コードを書くClaudeとレビューするClaudeのやり取りが、一晩で50回以上続いたことがあったそうです。
最後は、人が止めたらしい。
うわぁぁ、朝起きたら50往復してるの、普通にこわい😭
なんで終わらなかったのか。
調べたら、何度も指摘されてた部分の約59%は、最初のレビューのときからあったコードでした。
直すたびに新しいバグを作ってたんじゃなく、もともとあった問題を、少しずつ拾い直してたんです。
つまり、指摘を増やすことと、頼んだ作業を終わらせることは、別の話だったってこと。
人なら数秒で「それは今回はいいや」とスルーする細かい指摘でも、Claudeは律儀に直しにいく。
直したら、また次のレビューが走る。
これがぐるぐる回って、50往復になっちゃったわけです。
そこで本家が入れた対策は、こんな感じです。
-
3回レビューしたら、人が進め方を考え直す
-
2回目からは、新しく変わった部分だけを見る
-
同じ指摘を何度も出し直さない
-
1行ずつ指摘するんじゃなく、同じ種類の問題をまとめて直せるように伝える
-
前からあった古い問題は、別の機会にまとめて見る
3回で自動的にOKにするわけでも、残った問題を無視するわけでもないのがポイントです。
「このまま続けて意味があるか」を、人が一回立ち止まって考える。
自分のアプリづくりで起きがちなのは、こんな流れです。
予約の日付がずれる不具合を直してもらう。
直ったと思ったら、今度は一覧の並び順が変わってる。
並び順を直してもらったら、ついでに見た目まで変わってる。
気づいたら、最初の「日付のずれ」とは関係ないところを、延々と直してもらってるんですよね。
これ、Claudeが悪いというより、「どこまで直していいか」を決めずに頼んでるのが原因です。
直す範囲を決めて、回数で区切るだけで、このぐるぐるはかなり防げます。
止めたときにどうするかも、先に決めておくとラクです。
原因がよく分からないまま止まったら、新しいセッションの別のClaudeに「原因だけ調べて。まだ直さないで」と頼む。
原因が分かってから、直す範囲を決めてもう一回頼む。
調べることと、直すことを分けるだけで、話がかなり整理されるんですよね。
止めるときの頼み方は、こんな感じです。
同じ不具合を2回直しても解決しなかったら、それ以上の修正は止めてください。
止めたら、次の4つをまとめて教えてください。 ・試したこと ・変わったこと ・まだ残っている症状 ・私が決める必要があること
今回頼んだ不具合と関係ない場所は、直さないでください。
「とにかく直して」と言い続けるほど、Claudeは律儀に別の場所まで直し始めます。
直す範囲と、止める回数は、頼む前に決めてください。
実戦術④ セキュリティは「警告だけ」で終わらせない
今週、ここが一番大事かもしれません。
本家のチームは、普通のレビューとは別に、セキュリティ専門の自動レビューも走らせてます。
しかも、問題が見つかったら、どう扱うか決まるまで先に進ませない。
直すか、「これは誤検知です」と理由を書いて退けるか、どちらかを決めないと通れない仕組みです。
警告を出すだけで、見ないまま進めちゃう…ってことが起きないようにしてるんですよね。
ここ数週間、Claude CodeやCodexを使う人にも関係あるセキュリティの話が続きました。
ん？自分は小さいアプリしか作ってないから関係ないじゃんって思ったかもしれないんですけど。
穴は、アプリの大きさじゃなく、使ってる土台に開くんですよね。
Claude Codeが作ったアプリも、PHPやLinuxみたいな誰かが作った部品の上で動いてます。
PHPの穴（PHP2Shell）
Webサイトを動かすPHPという言語の本体に、深刻度9.2（10点満点）の穴が2つ見つかりました。
10月21日に修正版が出ていて、ニコニコなどのサービスが緊急で止めて対応したと報じられてます。
そのうち1つを見つけたのは、OpenAIの「Patch the Planet」の現場でした。
自分のコードが完璧でも、土台のPHPに穴があったら関係ない、ってところが怖いところです。
WordPressを使ってるなら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、今のPHPのバージョンを確認できます。
Linuxの穴（CVE-2026-98432）
サーバーでよく使われるLinuxの中心部分にも、穴が見つかりました。
Anthropicは10月27日に、未公開のClaudeが、特定の条件のサーバーを乗っ取る攻撃方法を作れたと発表しています。
10月29日時点で、DebianやOracle Linuxは修正版を出していて、UbuntuとRed Hatはまだでした。
レンタルサーバーやVPSでUbuntuを使ってる人は、修正版が出たら更新して、必ず再起動してください。
ダウンロードフォルダの罠
セキュリティ企業のForever Securityが、実際のパソコンで見つけた攻撃を公開しました。
ダウンロードフォルダに紛れ込んだAGENTS.mdやCLAUDE.mdを、CodexやClaude Codeが「指示」として読んで、そのまま従ってしまう、というものです。
見つかった例では、悪いnpmのパッケージ（部品）を入れさせようとしていたそうです。
同社の実験では、Codexは9割超の確率で仕込まれた指示に従い、Claude Codeは報道ではおよそ半分。
同社自身は「Claudeはかなりだましにくかった」とも書いてます。
でも、半分でも十分こわいんですよね。
サーバーのことがよく分からない人へ
「自分のアプリが、どのサーバーで何を使って動いてるか分からない」って人も多いはずです。
ここが分からないと、ニュースが出るたびに「自分は関係ある？」って迷うことになるんですよね。
まずは、Claude Codeに今の構成を説明してもらうところから始めてください。
このアプリが動くために使っているものを、エンジニアじゃない人向けに説明してください。
・使っている言語や部品（PHP、Node.jsなど） ・どこに公開されているか、どのサーバーで動いているか ・データはどこに保存されているか
ファイルや設定から確認できたことと、確認できなかったことを分けて書いてください。
レンタルサーバーを使っているなら、分からないところはサーバー会社に聞くのが一番早いです。
そのときは「安全ですか？」じゃなく、「10月21日のPHPの脆弱性への対応状況と、利用者側でやることを教えてください」のように、何を知りたいかを具体的に書くと話が早く進みます。
自分でできる4つの備え
-
公開する前に、/security-reviewでセキュリティの確認をしてもらう
-
Claude CodeやCodexは、ダウンロードフォルダで起動しない。作業用のフォルダを作って、その中で使う
-
APIキーやパスワードは、CLAUDE.mdやコードに直接書かない
-
サーバーを借りているなら、更新のお知らせを見て、更新したら再起動まで済ませる
セキュリティの確認も、頼み方で結果が変わります。
このアプリを公開する前に、セキュリティの確認をしてください。 まだコードは変更しないでください。
・ログインしていない人が、他の人のデータを見られないか ・パスワードやAPIキーが、コードやファイルに直接書かれていないか ・使っている部品やサーバーに、更新が必要なものがないか
見つかった問題ごとに、根拠になるファイルと行、影響、直し方の案を出してください。 確かめられなかったことは、「未確認」と書いてください。
ちなみに、確認ツールの「OK」も、何を見てOKと言ってるかは確かめておきたいところです。
たとえばOpenAIのPHPのチェックツールは、外に見えているバージョン番号で判断するだけで、実際の中身まで確かめるものではないと説明されてます。
見つかった問題は、直すか、理由を書いて退けるか、必ずどちらかに決めてください。
実戦術⑤ 人が見るのは「取り返しがつかない場所」だけ
じゃあ、人は何を見ればいいのか。
本家のチームは、全部の変更を同じ深さで見てません。
説明文を少し直すのと、課金の仕組みを変えるのでは、失敗したときのダメージがまるで違うからです。
本家のClaudeのレビューにも、軽い確認から深い確認まで段階があって、見逃したときの損が大きい場所ほど深く見るようにしてるそうです。
人がしっかり確認するのは、たとえばこういうところ。
-
お金が動くところ（課金・決済）
-
ログインや、誰が何を見られるかの設定
-
お客さんの個人情報を扱うところ
-
アプリを外に公開する手順
-
データを消す処理
そして、本家のルールで刺さったのがこれ。
★★Claudeの「OK」は、人の「OK」として数えない★★
Claudeのレビューで問題なしと出ても、取り返しがつかない場所は、人が自分の目で確かめる。
しかも、人が確認したあとにClaudeがまた変更を加えたら、もう一回確認し直すそうです。
「一度見たから大丈夫」にはしないんですよね。
たとえば、予約アプリの「予約を消す」処理を自分で確認したあと、Claudeが「ついでに整理しておきました」と別の場所を触ったら、もう一回見る。
地味だけど、ここで事故が防げます。
そもそも「作るべきか」は人が決める
本家のチームが、人に残している仕事がもう1つあります。
それが、「そもそもその機能を作るべきか」を決めることです。
どこまで作るか、何を良い使い心地とするかは、コードが動くかどうかとは別の問題なんですよね。
Claudeは、頼めばだいたい何でも作ってくれます。
だからこそ、「本当に要る？」を決めるのは人の仕事として残る。
本家では、途中で他の人から「もっと簡単な方法がある」と言われて、作りかけのものを閉じて作り直すこともあるそうです。
作るのがラクになったぶん、作ったものにこだわらず、早めに方向を変えられるんですよね。
Claudeが書いたコードでも、公開した結果に責任を持つのは、Claudeを動かした人です。
任せる前に、自分が見る場所を先に決めてください。
実戦術⑥ いつでも元に戻せるようにしておく
ここまで重ねても、本家は「問題がゼロになる」とは考えてません。
だから最後は、間違えたときにすぐ戻せる準備をしてる。
本家では、変更を小さく分けて、何かあったらすぐ取り消せるようにしてるそうです。
新しい機能も、まず自分たちで使ってから、少しずつ公開範囲を広げていく。
元の記事には「You land it, you own it」って言葉が出てきます。
自分が取り込んだ変更には、あとまで責任を持つ、って意味です。
でも、責任を持てるのは、すぐ戻せる仕組みがあるからこそなんですよね。
自分でアプリを作るなら、こうするだけで十分です。
-
うまく動いたところで、Gitに記録（コミット）してもらう
-
1回に頼む変更は小さくする（「画面を全部作り直して」より「予約ボタンだけ直して」）
-
大きく変える前は、「今の状態をコミットしてから始めて」と一言添える
作業を始める前に、今の状態をGitにコミットしてください。 メッセージは「〇〇の変更前」としてください。
作業が終わって、動くことを確認できたら、もう一度コミットしてください。 うまくいかなかった場合は、変更前のコミットに戻す方法を教えてください。
公開も、いきなり全員にしない
本家は、新しい機能をまず社内の自分たちで使って、問題がないか確かめてから広げてます。
一般向けにも、新しい変更が先に届くルートと、あとから届く安定版のルートを分けてるそうです。
自分のアプリなら、ここまで大げさにしなくて大丈夫です。
まずは自分だけで数日使ってみる。
次に、身近な人に1〜2人だけ使ってもらう。
そこで「ここが分かりにくい」「このボタン押したら止まった」が出てきたら、広く公開する前に直せます。
いきなり全員に公開して、全員から同じ不具合の連絡が来るのが、一番しんどいパターンなんですよね。
元に戻せるとわかってれば、思い切って任せられるんですよね。
大きな変更を頼む前は、必ず今の状態を記録してもらってください。
おまけ：分からない部分は、その範囲だけ解説させる
ここまで読んで、「でもコードが読めないから、何が起きてるか分からない…」って思った人もいるかもしれません。
安心してください。
本家のチームでも、Claude Code全体の仕組みを完全に頭に入れてる人はいないそうです。
全員にそれを求めてもいない。
代わりにやってるのが、これから触る部分だけ、Claudeに解説を作らせること。
人によっては、図や小さな資料まで作らせて理解してるそうです。
全部を読もうとするんじゃなく、必要な範囲だけ分かればいい、って割り切りなんですよね。
予約を消す機能の仕組みを、コードが読めない人向けに説明してください。
・ボタンを押してから、データが消えるまでの流れ ・データがどこに保存されているか ・失敗しやすいところ
できれば、流れを図にしてください。
分からないところは、その範囲だけClaudeに説明させてください。
ガチ勢の流れを、予約アプリで通してみる
最後に、ここまでの実戦術を、予約アプリづくりで一本の流れにしてみます。
説明のための例なので、自分の作りたいものに置き換えて読んでください。
-
作業用フォルダを作る：ダウンロードフォルダじゃなく、新しいフォルダでClaude Codeを起動する
-
CLAUDE.mdを短く書く：作るもの、作らないもの、完了の報告の仕方だけ書く
-
今の状態をコミットしてもらう：いつでも戻れるスタート地点を作る
-
小さく頼む：「予約の登録と一覧だけ作って」から始める
-
証拠つきで報告してもらう：登録→一覧に出る→再読み込みしても残る、をスクショで見せてもらう
-
別のClaudeに確認してもらう：/code-reviewか、新しいセッションで確認
-
直す往復は2回まで：超えたら止めて、状況をまとめてもらい、自分が判断する
-
うまく動いたらコミット：次の機能に進む前に記録する
-
公開前に/security-review：他の人のデータが見えないか、キーが書かれてないか確認する
-
取り返しがつかない場所だけ自分で触る：予約を消す処理や、公開の設定は、自分で操作して確かめる
こうやって並べると、人がやってるのは「決める」「確かめる場所を選ぶ」「最後に触る」の3つだけなんですよね。
書く、確かめる、まとめる、はほぼClaudeに任せてる。
これが、付きっきりの確認係を卒業した状態です。
まずは次の作業で、この流れの4〜5番目だけ試してみてください。
ガチ勢がやらない、ありがちなNG
ここまでの実戦術を裏返すと、つい自分でやっちゃいがちなNGが見えてきます。
思い当たるものがあったら、そこから直していけばOKです。
NG①「できた？」とだけ聞く
作ったClaudeに「できた？」と聞けば、ほぼ「できました」が返ってきます。
聞き方が、答えを決めちゃってるんですよね。
「何を実行して、どんな結果が出た？」と、証拠を聞く形に変えてください。
NG②「いい感じにして」と頼む
「いい感じに」「ちゃんと」「使いやすく」は、人によって意味が違います。
Claudeもどこまでやれば終わりか分からないので、頼んでないところまで広げがちです。
「予約を登録したら一覧の一番上に出る」みたいに、触って確かめられる形で完成を決めてください。
NG③ 何でもかんでも全部承認する
Claude Codeは作業の途中で、「このコマンドを実行していい？」と許可を求めてきます。
面倒になって、中身を見ずに全部OKを押したくなる気持ち、めちゃくちゃ分かる()
でも、削除や外部への送信、公開まわりの許可だけは、何をするのか読んでから押してください。
NG④ ダウンロードしたものを、そのまま読ませる
ネットで拾ったファイルやフォルダを、中身を見ずにClaude CodeやCodexに読ませるのも危ないです。
ダウンロードフォルダの罠で見たように、ファイルの中に「指示」が仕込まれていることがあります。
知らないところから来たAGENTS.mdやCLAUDE.mdは、使う前に自分で中身を開いて読んでください。
NG⑤ 動いたまま記録しない
うまく動いた瞬間って、うれしくてそのまま次の機能を頼みたくなるんですよね。
でも、そこで記録（コミット）しておかないと、次の変更で壊れたときに戻る場所がない。
動いたら、次に進む前に、必ず一回コミットしてもらってください。
NG⑥ エラーを全部一度に投げる
不具合が3つ見つかったとき、まとめて「全部直して」と頼むと、どれが直ってどれが直ってないか分からなくなります。
しかも、1つ直すたびに別のところが変わって、原因が追えなくなる。
不具合は1つずつ、直す範囲を決めて頼んでください。
今日からやることチェックリスト
ここまでの実戦術を、今日から使える形にまとめました。
-
完了報告には、実行した結果とスクショをつけてもらう
-
確認役は、作ったのとは別のClaude（/code-reviewか新しいセッション）にする
-
CLAUDE.mdは短く、前提だけを書く
-
同じ不具合の修正は2回まで。超えたら止めて、状況をまとめてもらう
-
公開前に/security-reviewを通す
-
ダウンロードフォルダでClaude CodeやCodexを起動しない
-
APIキーやパスワードを、ファイルに直接書かない
-
課金・ログイン・個人情報・公開・データ削除まわりだけは、自分の目で確かめる
-
大きな変更の前に、今の状態をコミットしてもらう
-
分からない部分は、その範囲だけClaudeに解説させる
全部を一気にやる必要はありません。
まずは一番上の「証拠をつけてもらう」だけ、次の作業から試してみてください。
さいごに
Claude Codeガチ勢の本家がやってたのは、すごい裏技じゃありませんでした。
「できました」を信じず、確かめ方を決めて、人が見る場所を絞る。
そして、任せすぎて終わらなくならないように、止めどころまで決めておく。
コードの9割をClaudeが書く時代でも、何を作るか決めることと、結果に責任を持つことは、人の仕事として残ってるんですよね。
逆に言えば、そこさえ押さえておけば、付きっきりの確認係はもうやめられる。
今週みたいにセキュリティのニュースが続く時期ほど、この「確かめ方を決めておく」が効いてきます。
次にClaudeから「できました」と返ってきたら、「何を実行して、どんな結果が出た？」って聞いてみてください。
最後に：無料特典12点のお知らせ
LINEオープンチャット「にくのAI爆速攻略」で、Claude Codeを始める人向けの無料特典を配ってます。
01｜Codex・Claude Code導入ガイド 02｜そのまま貼って試せる指示文3本 03｜困ったときの早見表11項目 04｜ミニアプリ作成プロンプト50本 05｜画像生成・編集プロンプト50本 06｜X・Threadsの自動投稿・予約の詳しい手順 07｜X記事タイトルジェネレーター 08｜X収益化までの流れと金額 09｜Claude Codeことば図鑑 60語 10｜CLAUDE.mdスターターテンプレ 11｜モーショングラフィックス動画の指示文セット 12｜Claude Code 最初の10日チャレンジ
受け取りはこちら → https://x.gd/VtPmw
沿着这个主题继续读
从一篇文章，找到相关的教程、经验和阅读路径。
