AIが書いたコードを信用していい所・確認すべき所【2026】
AIに「作って」と頼んだら、それらしいものが動いた。画面もちゃんと表示される。——でも、このまま公開して大丈夫だろうか？ vibe coding（AIにコードを書かせる作り方）でいちばん心細くなるのが、この瞬間だ。
コードを読めない自分に、AIの出力の良し悪しなんて判断できない。そう思うかもしれない。でも、コードの中身を1行も読まなくても、「どこを信じてどこを疑うか」は判断できる。プロの開発者も、AIが書いたコードを1文字ずつ読んで検算しているわけではない。要点だけ見ている。
まだ vibe coding 自体がピンとこない人は Vibe Coding（バイブコーディング）とは？ から読むと、この記事の話が入りやすい。
「動いた＝OK」ではない、これだけの理由
画面が動くことと、中身が正しく安全なことは別物。AIは「それっぽく動くもの」を出すのは得意だが、「安全で正しいもの」を毎回出すとは限らない。
AIが書いたコードは、見た目は完成していても中に落とし穴が残っていることがある。2026年の調査でも、最新のAIモデルが書いたコードの相当な割合に、何らかの脆弱性（悪用されうる弱点）が見つかったという報告がある（出典は後述）。これは「AIがダメ」という話ではなく、AIの出力は下書きであって、そのまま最終稿ではないという話だ。
とくに非エンジニアが引っかかりやすいのが、次の「動くのに危ない」パターン。
| 見た目 | 実際に起きていること |
|---|---|
| ちゃんと表示される | パスワードやAPIキー（サービスの合鍵）がコードにむき出しで書かれている |
| 入力フォームが動く | 誰でも他人のデータを見られる状態になっている |
| 保存できている | 一部の入力でだけ壊れる・データが消える |
| 「完成しました」と言われた | 頼んでいない余計な機能まで勝手に足されている |
「動いた」で気を抜かない
テストして動くのは最低ラインであって、合格ラインではない。とくに「他人が使う」「お金や個人情報が絡む」「ネットに公開する」ものは、動いた後にもう一段の確認が要る。
信用していい所・自分で確認すべき所
見た目・文章・レイアウトなど「目で結果が分かる部分」はAIに任せてよい。データの扱い・お金・公開・秘密情報が絡む部分は、必ず自分（と後述のAIチェック）で確認する。
丸暗記する必要はない。「間違ってもやり直せばいい所」か「間違うと取り返しがつかない所」かで線を引くと分かりやすい。
| 信用していい（任せてよい） | 自分で確認すべき（疑う） |
|---|---|
| 見た目・色・レイアウト | ログインや「本人だけ見られる」の仕組み |
| 文言・ボタンの配置 | 保存・削除など元に戻せない操作 |
| ちょっとした計算や並び替え | パスワード・APIキーなど秘密情報の扱い |
| サンプルデータでの動作 | お金・決済・個人情報が絡む処理 |
| 見て正しさが分かるもの | ネットに公開して誰でも触れる部分 |
ポイントは、「見て結果が分かるもの」は信用しやすく、「見えない所で起きること」は疑う、という切り分け。色がおかしければ一目で分かるが、「裏で他人のデータが見えている」は画面を見ても分からない。だから後者だけ、意識して確認する。
コードを読めなくてもできる4つの確認
「実際に触る」「頼んでないことをしていないか」「秘密がむき出しでないか」「AI自身に説明させる」。この4つはコードが読めなくてもできる。
わざと変な使い方をして触る
正しい入力だけでなく、空欄で送信・記号や超長文を入力・同じボタンを連打——と、いじわるに触る。ここで壊れたら「こういう時に壊れた。直して」と伝えればいい。ユーザーは平気で想定外の使い方をする。
5〜10分頼んでいないことをしていないか見る
AIは親切心で余計な機能やサービス連携を足すことがある。「今回の変更で、私が頼んでいないことを足した？あれば理由と一緒に一覧にして」と聞く。不要なら削らせる。
2〜3分秘密情報がむき出しになっていないか聞く
「パスワード・APIキー・秘密の鍵が、コードの中に直接書かれていない？あるなら安全なやり方に直して」と依頼。むき出しのままネットに公開すると、悪用される。
2〜3分AI自身に「危ない所」を説明させる
「このコードで、他人に見られたら困るデータや、壊れると困る処理はどこ？初心者にも分かる言葉で説明して」と聞く。自分で書いたコードの弱点をAIに解説させると、確認すべき場所が浮かび上がる。
3〜5分コツは、確認もぜんぶ日本語でAIに投げていいこと。あなたがコードを読む必要はない。「怪しい所を教えて」「直して」を繰り返すだけで、確認の大半は進む。エラーが出た時の直し方は AIと一緒にデバッグする にまとめている。
1つずつ小分けで頼むほど確認しやすい
一度に大量の変更をさせると、どこがどう変わったか追えなくなる。「まず◯◯だけ作って」と小分けで頼むと、変更が小さいぶん確認もラク。AIへの指示の出し方 の考え方がそのまま効く。
AIにAIをチェックさせる（Claude Codeの機能）
Claude Code には、AIが書いたコードをAIが点検する専用コマンドがある。人が読めなくても、機械的な見落としはここで拾える。
Claude Code を使っているなら、次のコマンドが使える。どれも「今の変更（差分）」だけを見て、要点を報告してくれる。
| コマンド | すること | こんな時に |
|---|---|---|
/review | 変更点を「正しさ・安全性・速度・書き方」の観点で点検 | ひと区切りついて公開前 |
/security-review | 変更点に潜むセキュリティ上の弱点を集中チェック | 公開する・他人が使う前 |
/rewind | AIが編集する前の状態に巻き戻す | 直させたら余計おかしくなった時 |
/security-review は、SQLインジェクション（データベースを不正操作される攻撃）やアクセス権限の抜け、秘密情報のむき出しといった「初心者が気づけない弱点」を、変更したコードに絞って数秒〜数十秒で洗い出してくれる（公式ヘルプ）。出てきた指摘は、そのまま「これ直して」と頼めばいい。
巻き戻し（チェックポイント）は自動で効いている
Claude Code は編集のたびに直前の状態を自動保存している。おかしくなったら /rewind（CLIでは入力欄が空の状態で Esc を2回でも開く）で、編集前まで戻せる。「怖くて直させられない」がなくなるので、確認と修正を気軽に回せる。
アプリとCLIで入り方が違う点に注意
これらはスラッシュコマンド（先頭に / を付ける命令）で、Claude Code を使っていれば「Claudeアプリ（デスクトップや claude.ai）」でも「CLI（ターミナルの黒い画面）」でも、入力欄に /review などと打てば呼び出せる。違うのは巻き戻しの近道で、Esc を2回押して巻き戻すのはCLI（ターミナル）だけ。アプリでは /rewind と打つ方法を使う。自分がどちらを使っているか分からない時は、送信ボタン近くにモード選択メニューが見えればアプリ、文字だけの黒い画面ならCLIだ。
特に気をつける「危ない指示」を出していないか
「本番データを触る」「そのまま公開する」「お金・個人情報を扱う」——この3つが絡む依頼だけは、動いても即OKにしない。
AIの出力そのものより、あなたが出した依頼が危ないケースもある。次のような時は、一段ていねいに進める。
- すでに公開・運用中のものを触る時
- 壊すと本物のユーザーに影響が出る。先に計画を出させてから作らせる（プランモードの使い方）
- お金・決済・個人情報を扱う時
- 「動いた」で公開しない。
/security-reviewを通し、可能なら詳しい人に一度見てもらう
- 「動いた」で公開しない。
- ネットに公開する時
- 秘密情報がコードに残っていないか（確認3）を必ずやってから公開する。公開手順は デプロイの基本 を参照
迷ったら「公開しない・本番を触らない」側に倒す
非エンジニアのうちは、判断に迷った時ほど慎重側が正解。「テスト用の場所で試す」「本番のコピーで試す」だけで、取り返しのつかない事故はほぼ防げる。AIに「これは本番に影響する操作？」と一言確認するのも有効だ。
自分でプロジェクトの前提（使う技術・してほしくないこと）を CLAUDE.mdの書き方 の要領で書いておくと、AIが最初から危ない実装を避けてくれるので、確認の手間そのものが減る。
よくある質問（FAQ）
Q. コードが読めないのに、確認なんて本当にできる？
できる。 この記事の4つの確認（実際に触る／頼んでないことの有無／秘密情報／AIに弱点を説明させる）は、すべて日本語のやり取りだけで進む。コードを読むのではなく、「怪しい所を教えて」「直して」とAIに投げるのが、非エンジニアの確認スタイルだ。
Q. /security-review を通せば、もう安全と考えていい？
「これで完璧」ではない。 機械的な弱点の多くは拾えるが、すべてを保証するものではない。お金・個人情報が絡む本番公開では、それに加えて「本番のコピーで試す」「詳しい人に見てもらう」を重ねるのが安全。あくまで確認の一段目と考える。
Q. AIが「完成しました」「問題ありません」と言ったら信じていい？
言葉は鵜呑みにしない。 AIは自信たっぷりに間違えることがある。「問題ない」と言われても、実際に変な使い方で触る（確認1）と壊れることは珍しくない。言葉ではなく、触った結果と点検コマンドの出力で判断する。
Q. 確認していたら、直すたびに別の所が壊れる。どうすれば？
小分けに戻る。 一度に多くを直そうとすると連鎖的に壊れやすい。/rewind で一度戻し、「◯◯だけ直して。他は変えないで」と1つずつ頼む。変更が小さいほど、原因も確認もはっきりする。
Q. どこまで確認したら「公開していい」と言える？
目安は3つ。「変な使い方で触っても壊れない」「秘密情報がコードに残っていない」「/security-review の指摘に対処済み」。この3点がそろえば、個人の小さなサイトなら公開してよいライン。お金・個人情報が絡むなら、さらに慎重に。
Q. Claude Code 以外のツールでも同じ確認はできる？
考え方はどのツールでも使える。 /review のような専用コマンドはツールごとに有無が違うが、「頼んでないことをした？」「秘密情報はむき出しじゃない？」「危ない所を初心者向けに説明して」という質問は、どのAIツールにもそのまま投げられる。
まとめ
- 「動いた＝OK」ではない。 見た目が完成でも、見えない所に落とし穴が残ることがある。
- 信用していい所（見た目・文言）と、疑う所（データ・お金・公開・秘密情報）を切り分ける。
- コードを読めなくても、4つの確認（触る・頼んでないこと・秘密情報・AIに説明させる）はできる。
- Claude Code の
/review・/security-review・/rewindで、AIにAIを点検・巻き戻しさせる。 - 迷ったら**「本番を触らない・公開しない」側**に倒す。それだけで大事故はほぼ防げる。
次のステップ
確認して直す流れをもっと上達させたいなら、次は AIと一緒にデバッグする へ。エラーが出ても慌てず、AIに自分で直させる指示の型が身につく。作る前の設計で事故を減らしたいなら プランモードの使い方 が先だ。
出典：AIが書いたコードの脆弱性割合・攻撃パターンに関する2026年の報告は Is AI-Generated Code Safe? The 2026 Data、Claude Code のセキュリティレビュー機能は Anthropic公式ヘルプ を参照（2026年7月時点）。
