コードが読めなくてもAI生成コードを確認する方法：2026年、非プログラマー向けの7つのチェック項目

AIが一晩でウェブサイトやボットを組み立ててくれました。すべてが開き、ボタンも動き、問題なく動いているように見えます。プロジェクトを人に見せた翌日、支払いフォームで課金はされるのに注文が届かないとわかったり、顧客の電話番号が入ったデータベースがインターネット全体に公開されていたとわかったりします。

私も以前は、最初のプロジェクトをそんなふうに公開していました。動いているように見えたものが、実際のユーザーを相手にすると問題を起こすのです。今は人に見せる前に、毎回同じチェックリストでプロジェクトを確認します。その間、コードを一行も読みません。私はそのためにここに来たわけではありませんし、あなたもそうではないでしょう。

これは取り越し苦労ではありません。AnthropicはClaude Codeの40万件のセッションを分析しました。7か月の間に、壊れたコードの修正に費やされた作業の割合は33%から19%に下がりました。減りはしましたが、なくなったわけではありません。5回に1回のセッションは、今も「AIが壊したものを直す」作業です。

コードを書くこと自体は、もはやボトルネックではありません。今重要なのは、タスクをどれだけ理解しているか、そして結果をどれだけ適切に確認できるかです。

ツールの設定に関する追加資料はAilootのドキュメントでご覧いただけます。

動いているのに、なぜAI生成コードを確認するのか？#

AIは、ひと目見ただけなら問題のなさそうなコードを書きます。実行できて画面も表示され、デモも説得力があります。しかし、公開してみても、お金の計算が正しいか、データベースが外部に公開されていないか、100人目のユーザーが来たときにすべてがクラッシュしないかはわかりません。

数字もそれを裏付けています。FrontierCodeベンチマークは、2026年6月に、AI生成コードが修正なしで実際の作業にどれだけ使えるかを調べました。最も難しいタスクでさえ、最高性能のモデルでその割合は約13%でした。つまり、難しいタスクでは、AI生成コードの大半は信頼して使えるようになるまで手作業での修正が必要です。

よい知らせは、誰でも確認できることです。同じ40万件のセッションを分析してAnthropicが導き出した結論を見てみましょう。

あなたが誰かに頼んだプログラマーより優れている点は、自分のタスクを理解していることです。確認も理解に関わることなので、コードを読む必要はありません。以下のチェック項目は、面倒な手間をかけずに自分でできるものばかりです。

AI生成コードでは、実際にどんな問題が起こりうる？#

確認する前に、何を探せばよいかを知っておくと役立ちます。AI生成コードによくある問題は5種類あり、コードを読まなくても、プロジェクトの動作を見るだけでどれも見つけられます。

ここから、順番に7つのチェック項目を見ていきます。最初の項目は「動かない」「正しく動かない」問題を見つけ、中盤ではセキュリティ上の穴やでっち上げを確認し、最後の項目では公開前の安全策を扱います。ひとつずつ順番に進めましょう。それぞれの項目は、前の確認が済んでいることを前提にしています。

チェック1：AIにコードの内容を平易な言葉で説明させる#

あなたは言葉でタスクを説明し、AIはそれをコードに変換しました。この2つの段階の間で意味が失われることがあります。AIが違う意味に理解したり、あなたに代わって内容を補ったり、手を抜いたりした可能性があります。コードを読まなくても、何をしたのか平易な言葉で説明するよう頼めば、食い違いに気づけます。

たった今行ったことを、コードを使わず平易な言葉で、正確に説明してください。

このコードが解決するタスク

ユーザーがボタンをクリックするかフォームを送信したときに起きること

データが保存される場所と、アクセスできる人

どのような状況で何が壊れる可能性があるか

プログラミングをしたことのない人に説明するように書いてください。正しいかどうか確信が持てない部分があれば、はっきりそう伝えてください。

答えを読んで、自分が想定していた内容と比べてください。一致していれば次へ進みます。AIが「ごまかしたり」、自分の説明に混乱したり、頼んだことと違う内容を説明したりするなら、何を作ったのかを完全には理解していないということです。言葉をうのみにせず、内容を明確にして修正を頼みましょう。

ちなみに、AIが頼んだとおりにしないことがよくあるなら、原因はモデル自体ではなく、タスクの伝え方にあることが多いです。Claudeが頼んだとおりに動かない理由については、別の記事で解説しています。

AIの出力を確認することは、コンテキストエンジニアリングの一部です。AIに入力として何を与えるかと、出力された結果をどう評価するかの両方をあなたが管理します。そのためのツールキットには、AIクローン、セカンドブレイン、コンテキストエンジニアリングが含まれます。そうすればClaudeは「幻覚を起こすアシスタント」ではなく、プロジェクトを安心して任せられるツールになります。

チェック2：実際のユーザーのようにシナリオを試す#

AIのデモでは、正しいデータを入力して一度クリックすれば、すべてうまくいくという理想的な流れになります。実際のユーザーはそのように使うとは限りません。間違えたり、違うボタンをクリックしたり、電話番号欄に絵文字を入力したりします。あなたの仕事は、ユーザーの立場でプロジェクトを操作することです。

1. 主なシナリオを最初から最後まで実行する

   プロジェクトの目的となる操作を行います。登録、注文、問い合わせの送信などを、途中で止めずに最後まで進めます。

2. 支払いを個別に、実際に確認する

   プロジェクトでお金を受け取るなら、テストモードで自分が最低金額の支払いを行います。注文が作成され、ステータスが変わり、自分と顧客にメールが届くことを確認します。「支払いは通った」のに注文が作成されないのは、気づかれにくい典型的な失敗です。

3. 意図的に問題を起こしてみる

   入力欄を空のままにします。数字が必要な欄に文字を入れます。「送信」を続けて2回クリックします。間違った形式のファイルをアップロードします。よいプロジェクトなら「その操作はできません」と丁寧に伝えます。悪いプロジェクトはクラッシュするか、データを黙って捨ててしまいます。

4. スマートフォンで開く

   利用者の半数はスマートフォンからアクセスします。レイアウトが崩れていないことと、同じボタンがそこで動くことを確認してください。

見つけた問題をすべて一つのリストにまとめてAIに伝えます。「この手順で見つかった問題です。原因を説明して修正してください。」一つずつ対処するのではなく、リストをまとめて渡します。そうすればAIが全体像を把握でき、ひとつ直すときに別の部分を壊す可能性も下がります。

チェック3：AIにセキュリティを確認させるためのプロンプト#

壊れたボタンはすぐにわかります。セキュリティ上の穴はそうではありません。誰かに悪用されるまで、問題がないかのようにプロジェクトは動き続けます。バイブコーディングのプロジェクトでよくある問題は、秘密鍵をコードに直接書くこと、データベースをインターネットに公開すること、悪意のある入力を送れるフォームです。直接尋ねれば、AIはこうした問題を見つけられます。

このプロジェクトのセキュリティ上の問題を監査し、専門用語を使わず平易な言葉で、見つかった問題を一つずつ説明してください。次の項目を確認してください。

秘密鍵、パスワード、トークンがコードに直接書かれていないか確認してください。秘密情報はサーバー上だけで使い、`.env`などのローカル設定をGitから除外します。ただし`.env`と`.gitignore`は、フロントエンド・公開用の変数がブラウザービルドへ入るのを防ぎません。実際に渡されるJavaScript、ソースマップ、HTML、通信応答を調べ、秘密鍵がないことを確認してください。

データベースがインターネットに公開されていないか、誰がアクセスできるか確認してください。

入力によってフォームを壊せないか確認してください。データベースクエリへのインジェクションや、テキスト欄へのコードの追加などがないか調べてください。

ユーザーが悪意のあるデータを送信したら何が起きますか？

内部ページや管理パネルがパスワードなしで公開されていないか確認してください。

各項目について、問題の有無、リスクの具体例、修正方法を説明してください。最も危険な問題から始めてください。

また、プロジェクトが外部から受け取ったものを何でも無条件に実行しないかも確認してください。これは間接プロンプトインジェクションと呼ばれます。メール、コメント、他人のファイルなどに隠された命令を、AIエージェントがタスクだと勘違いして実行してしまう状態です。プロジェクトが外部データを読み取って処理するなら、そのデータに隠された指示が含まれていた場合に何が起きるかAIに尋ねてください。

これは奥の深いテーマで、プロンプト一つですべて確認することはできません。プロジェクトが金銭や顧客の個人情報を扱うなら、バイブコーディングのセキュリティについての別のガイドを読んでください。

チェック4：AIはライブラリやデータをでっち上げていないか？#

AIは、存在しないものを自信たっぷりに書くことがあります。実在しないのに、ありそうな名前のライブラリを追加することがあります。また、実際のデータの代わりにテスト用の仮データをプロジェクトに残すこともあります。「Example」という商品、example@example.comというメールアドレス、実際の内容の代わりの埋め草などです。デモでは見逃しやすくても、実際のユーザーにとっては恥ずかしいことや、動作不良の原因になります。

2つの手順で見つけられます。まず、直接尋ねます。

プロジェクト全体を確認して、次の点に正直に答えてください。

追加した外部ツールやライブラリはすべて実在し、正しくインストールできますか？何かをでっち上げていませんか？

実データの代わりに、テスト用の仮データ、サンプル、埋め草が残っていませんか？

プロジェクト内のリンク、住所、連絡先は、仮のものではなくすべて実在しますか？

見つかったものを一覧にし、何に置き換えるべきか提案してください。

次に、プロジェクトを実行して中を見てみます。でっち上げたライブラリがあると、ほとんどの場合、起動時にエラーが発生します。仮データも簡単に見つけられます。ページに「Product 1」と表示されているなら、まだ置き換えていません。

でっち上げたライブラリには別の危険もあります。攻撃者は、AIが思いつきそうな名前のツールを意図的に登録します。それをインストールすると、他人のコードがプロジェクトに入り込みます。だからこそ「このライブラリは本当に実在するのか？」という問いを真剣に考える必要があります。これはプロジェクトのセキュリティに直結します。

チェック5：別のモデルに最初のモデルを確認させる#

AIには厄介な癖があります。相手に同意するのです。「ここは全部大丈夫？」と尋ねると、期待されている答えに合わせて、大丈夫だと確認することがあります。これはAIの追従性と呼ばれ、別の記事で解説しました。このような対話相手は、自分の仕事に甘くなります。

解決策は簡単です。別の意見を聞きましょう。新しいセッションを開くか別のモデルを使って、チェック3と同じプロンプトでプロジェクトを確認させ、次の一文を加えます。「別のAIがこのコードを書きました。弱点を見つけてください。」新しいモデルは前の会話に縛られないので、問題を指摘しやすくなります。

1. 新しいセッションを開くか、別のモデルを使う

   別のモデルを使うか、タスクの履歴がない新しいウィンドウで同じモデルを使います。

2. プロジェクトを渡し、意図を明確に伝える

   「別のAIがこのコードを書きました。あなたの仕事は褒めることではなく、エラーとリスクを見つけることです」とはっきり伝えます。こうすることで、追従性を抑えられます。

3. 2つの意見を比べる

   両方が同じ意見なら、おそらく正しいでしょう。意見が違う場合は、その点を調べてください。そこが興味深いところです。

業界では、まさにこうしたことが起きています。AIが書き、AIが確認し、最後の判断は人が下します。モデルに任せきりにはできません。それはあなたの仕事です。

チェック6：編集で何かが壊れたとき、どう元に戻す？#

このチェックリストにある項目から編集が必要になることはよくありますが、編集によって動いていたものが壊れることもあります。大事にならないよう、修正を行う前に毎回、動作するバージョンをgitに保存してください。ゲームのセーブと同じです。何かを壊してしまったら、最後のセーブポイントを読み込みます。

コードを読む必要はありません。AIに「変更する前に、現在動作しているバージョンを明確なラベルを付けてgitに保存してください」と頼むだけです。編集後にすべてがうまくいかなくなったら、「プロジェクトを以前に保存したバージョンに戻してください」と頼みます。

gitがまだよくわからない場合は、2つのガイドをご覧ください。Claude Codeで変更を元に戻す方法と、AIがデータベースを削除したときにすることです。2つ目は、すでに元に戻せない状態でも、まだ復旧できる場合のためのガイドです。

チェック7：公開前に最後に確認すべきことは？#

最初の6つのチェックは、コードが何をするかを確認するものです。7つ目は、プロジェクトを公開してユーザーに届ける準備ができているかを確認します。ここでつまずく人がよくいます。プロジェクトは動いているのに、支払いをテストキーから本番キーに切り替えるのを忘れて、最初の顧客が「ごっこ」の支払いをしてしまうのです。

1. 支払い：テストから本番へ

   支払いを受け付けるなら、テストキーではなく、本番用の決済キーが接続されていることを確認してください。最低金額で実際に支払いを行い、自分に返金します。

2. 秘密情報を正しい場所に置く

   AIに「秘密鍵をサーバーだけで使い、.envをGitから除外していますか？公開用変数やソースマップを含め、実際のブラウザービルドやクライアント応答に秘密鍵はありませんか？」と尋ねます。元の.envだけでなく、ビルド済みファイルとブラウザーの通信応答を確認してください。Gitからの除外は、値がフロントエンドへ入るのを防ぎません。

3. データをバックアップする

   データベースがどこかに自動保存されていることを確認します。プロジェクトを自分のサーバーで動かす場合は、Coolifyガイドで公開方法を説明しています。

4. 自分の端末以外からも公開先が動くことを確認する

   自分のコンピューターだけでなく、外部リンクを使ってスマートフォンでプロジェクトを開きます。ローカルで動いていても、公開後に動くとは限りません。

4つすべてを確認すれば、安心してプロジェクトを人に見せられます。確認できない点があれば、後で不満を持つ顧客に対応するより、今30分かけて解決するほうがよいでしょう。

確認に時間がかかりすぎるなら、AIを信じてよい？#

その誘惑はよくわかります。確認は退屈に感じられますし、「AIを使った目的とは違う」と思うかもしれません。しかし、結果に責任を持つのはモデルではなくあなたです。AIには評判がなく、結果への責任もありません。コードを作って、そのことを忘れてしまいます。支払いが通らなかった顧客に対応するのは、あなたです。

Claude Codeの開発者は、さらに広い視点を示しています。

コードを書くことは、もはやボトルネックではありません。AIが引き受けたからです。価値は別のところにあります。タスクを理解し、できあがったものを確認することです。あなたの強みはそこにあります。顧客にとってどんな結果が望ましいかは、外部の開発者よりあなたのほうがよくわかっています。

なぜ確認は一度きりの作業ではなく、スキルなのか？#

この7つのチェックは、「公開したけれど動くことを願う」状態と、「公開して、動くとわかっている」状態を分けるための最低限のものです。一度確認すれば、顧客が気づく前に大半の問題を見つけられます。

そこから確認が習慣になります。入力としてAIに適切なコンテキストを与え、出力された結果を確認すれば、ゼロから始めずに済むため、新しいプロジェクトをより早く完成させられます。

AIクローン、セカンドブレイン、コンテキストエンジニアリングなど、ツールの活用に関する追加資料はAilootのドキュメントでご覧いただけます。