※当サイトにはアフィリエイト広告が含まれます。本記事の本文にアフィリエイトリンクはありませんが、筆者自身の有料noteの案内を1か所含みます。記事の前後には、サイト共通の広告が表示されます。

修正しましたと言われて画面を開くと、何も変わっていない。AIでツールを作り始めた人なら、一度は見た景色だと思います。

Qiitaには、Claude Codeの完了報告について、こんな一文がありました。

確認の言葉だけが返ってきていて、確認の実行は1ミリも起きていなかった。

出典 Qiita（yurukusa）の投稿

画面を見て気づけるうちは、まだ軽いほうです。エラーも出ず、成功の表示だけが出る箇所は、使う人が誰も疑いません。

材料は、私が実務で使う2つのシステムの記録です。そこからバイブコーディングの失敗例を、数字つきで並べます。偽の成功4種と、黙って失敗し続けた再試行の話です。どれにも、あなたのプロジェクトで今日試せる確かめ方を付けました。

Claude Codeの完了報告そのものの確かめ方は、Claude Codeで保存されないときの実録に書きました。この記事は、画面や設定の奥に隠れた偽の成功を扱います。

バイブコーディングの失敗で一番怖いのは何？ 成功表示なのに何もしていない

バイブコーディングの失敗で一番怖いのは、成功と表示して何もしていない箇所です。エラーで止まるコードは、その場で誰かが気づきます。成功表示を出すコードは、気づかれないまま使われ続けます。

バイブコーディングとは、AIに言葉で頼んでコードを書かせる作り方

バイブコーディングは、AIに自然な言葉で指示し、コードを書かせる作り方です。英国のCollins英語辞典は、2025年のWord of the Yearにvibe codingを選びました。

Collinsの定義は、自然言語で指示したAIにコンピューターのコードを書かせること。言葉の出どころは、AI研究者Andrej Karpathy氏のX投稿です。Wikipediaによると、2025年2月の投稿でした。

エラーは目に見える。成功表示は疑われない

動かないコードは、画面が止まるか、赤い文字が出ます。困りはしても、直す場所ははっきりしています。

成功表示の場合は逆です。保存しました、0件です、型チェック通過。どれも正しく見えるので、誰も中を開けて確かめません。

Claude Codeの公式ドキュメントも、この点に触れています。実行できるチェックが無い場合の話です。完了したように見えることが、唯一の手がかりになると書かれています。

この記事で扱う偽の成功4種

偽の成功とは、処理が失敗したか実行されていないのに、画面や報告が成功を示す状態です。私のアプリで記録に残っていたのは、次の4種でした。

この4種に加えて、成功表示すら出さずに失敗し続けた再試行も取り上げます。

失敗例の出どころ 実運用の2システムと328コミット

この記事に出すバイブコーディングの失敗例は、社内の実務で使っている2つのシステムの記録から取りました。数字は2026年9月28日に、gitの履歴と開発ログから数えたものです。

先に1つ正直に書きます。4種の偽の成功は、どれも私が画面で気づいたものではありません。別の不具合を直す途中や、AIにコードを点検し直させた作業の中で出てきました。当時の画面は残っていないので、記録の数字で書きます。

社内のファイル共有アプリ（328コミット）

1つ目は、社内のファイル共有アプリです。ブラウザ版と、Windows用のPC同期アプリがあります。有料のクラウドストレージを置き換えるために作りました。今は約100名が使っています。

画面はReact、認証とデータベースはSupabaseで動いています。どちらも、AIに日本語で指示して組み上げたものです。

コミット（変更の記録）は、2026年1月6日から9月25日までで328件。内訳はfix（修正）が118件、feat（機能追加）が59件です。直した回数が、作った回数の2倍ありました。

最初はBolt、2026年8月にClaude Codeで作り直した

作り始めは、Bolt.new（StackBlitz社のAI開発サービス）でした。2026年8月に、Claude Codeで作り直しています。

ここに並ぶ失敗は、Claude Codeだけのものとは言えません。Bolt時代のコードも混ざっています。私が問題だと考えているのは道具の種類より、検査しないまま使っていた運用のほうです。

道具ごとの向き不向きは、AIコーディングツールの比較記事で7つの基準に分けて書きました。

採用管理のシステム（741コミット）

2つ目は採用管理のシステムで、約20名が使っています。コミットは741件です。後半の章で、同じ日に応急処置を5回重ねた記録を出します。

AIで業務システムを丸ごと作った別の例は、Claude CodeでWordPressの予約決済を作った実録にまとめています。

偽の成功① 「保存しました」が何も保存していなかった

1つ目の偽の成功は、設定画面の保存ボタンです。押すと保存しましたと出ますが、中身は800ミリ秒待って成功の表示を出すだけでした。どこにも何も書き込んでいません。

稼働状況のカードも、4項目すべて固定値だった

同じ設定画面には、サーバーの稼働状況を示すカードが4項目ありました。この4項目も、実際の状態を読まない固定値です。

800ミリ秒の待ち時間まで入っていたので、押した手応えは本物そっくりです。サーバーの状態が変わっても、カードの表示は1文字も変わらない作りでした。2026年8月22日の開発ログに、この2点が記録されています。

確かめ方は、保存してから再読み込み

設定を1つ変えて保存し、ページを再読み込みしてください。値が元に戻っていたら、その保存ボタンは表示だけの可能性が高いです。

もう1つは、数字が一度も動かない画面を探すこと。稼働状況や件数が何日たっても同じなら、固定値を疑ってください。

補足として、ブラウザの開発者ツールでネットワークの欄を開き、保存を押す方法もあります。送信の行が1本も増えなければ、どこにも送っていません。

偽の成功② 取得に失敗した画面が「0件」と表示していた

2つ目は、データの取得に失敗したのに0件と表示する画面です。ファイル一覧の読み込みに失敗すると、最近のファイルはありませんと出ていました。

ファイルの中身を読めなかったときの表示は、中身が空。利用者から見れば、どちらも正常な画面です。

エラーの握り潰しが22件あった

握り潰しとは、エラーを受け取っても何もせず、なかったことにする書き方です。2026年9月18日の修正で、この握り潰しを22件解消しました。

コードの書き方を自動で点検するlintの警告は、151件から129件に減っています。修正のコミットも、gitの履歴に実在します。

0件の表示は、データが本当に無いのか、読めなかったのかを区別できません。画面だけ見ていても、失敗には永遠に気づけない作りでした。

AIのコードは、エラー処理が抜けやすいという調査もある

エラー処理の抜けは、私のアプリだけの話ではありません。CodeRabbitは、470件のプルリクエストを分析した報告を公開しています。

その報告では、AIが関わった変更で、エラー処理と例外経路の欠落がおよそ2倍でした。調査側は、AIが関わったかの判定は完全ではないとも断っています。

確かめ方は、ネットを切って開く

Wi-Fiを切った状態で、一覧の画面を開いてください。ありませんと出たら、その画面は失敗を0件として扱っています。

正しい作りなら、読み込めませんでした、のような失敗の表示が出ます。開発者ツールのネットワーク欄にあるオフラインの設定でも、同じことが試せます。

偽の成功③ わざと壊しても落ちないテスト

3つ目は、テストが緑なのに何も守っていない状態です。コードを1行ずつわざと壊して確かめたら、3箇所が空振りでした。内訳は、テスト2本と、飾りのガード1つです。

テストの緑は、テストが走った証拠でしかない

テストとは、コードが期待どおり動くかを自動で確かめる小さなプログラムです。全部通ると、緑で表示されます。

守るべき行を壊しても緑のままなら、そのテストは何も見ていません。空振りの2本は、まさにその状態でした。

飾りのガードは、働かないのに安心だけくれる

ガードは、おかしな値が来たら処理を止めるための確認です。3箇所目の空振りは、ガードの形をしているのに、どこからも働かない死んだコードでした。

読むと守られているように見えるぶん、テストの空振りよりたちが悪い。私はそう感じています。

確かめ方は、大事な1行を壊して緑のままか見る

金額の計算や権限の判定など、壊れたら困る行を1つ選びます。その行をわざと書き換えてから、テストを走らせてください。

緑のままなら、その行を守るテストはありません。確かめ終わったら、書き換えた行は必ず元に戻します。

この確かめ方は、変異テスト（ミューテーションテスト）と呼ばれます。AIに頼むなら、この行を壊したら落ちるテストはどれかと聞くのが早いです。答えたテストを実際に壊して走らせれば、本当かどうかが分かります。

偽の成功④ 型チェックが1ファイルも検査していなかった

4つ目が、この記事で一番伝えたいバイブコーディングの失敗です。型チェックは毎回成功していたのに、検査したファイルは0件でした。2026年8月25日の開発ログに残っています。

型チェックとtsc –noEmit

型チェックは、数値の欄に文字を入れるような食い違いを、動かす前に見つける検査です。TypeScriptでは、tsc --noEmit というコマンドがよく使われます。

このアプリでも、tsc --noEmit は毎回成功で終わっていました。成功の表示は出るので、通過したものとして扱われます。

設定がreferencesだけで、検査対象が0件だった

原因は設定ファイルの形です。TypeScriptの設定ファイルには、別の設定ファイルを束ねるreferencesという書き方があります。

束ねる側は、filesを空にしてreferencesだけを並べる形になります。TypeScript公式のハンドブックにも載っている構成です。

公式の設定リファレンスによると、filesを書いたときのincludeの既定値は空です。このアプリの設定も、filesが空でreferencesが3本でした。検査するファイルが無いので、失敗のしようがなかったわけです。

効かせた瞬間にエラー13件、うち実バグ2件

検査を各設定に効かせた瞬間、エラーが13件出ました。11件は使っていない変数などの消し忘れ、2件は実際のバグです。

救いは、バグ2件がどちらも画面からたどり着けない死んだコードの中にあったこと。利用者に被害は出ていません。

ただ、画面から届く場所にあったとしても、型チェックは成功と言い続けていました。4種の中でこれが一番こわいと感じたのは、そのためです。

確かめ方は、わざと型を間違えて落ちるか見る

数値が入る変数に、わざと文字を入れる1行を足してください。型チェックが成功のままなら、そのファイルは検査されていません。

補足のコマンドも置いておきます。--listFiles は、検査したファイルの一覧を出す指定です。

<code>npx tsc -p tsconfig.json --noEmit --listFiles | wc -l</code>

一覧に自分の書いたファイルが1つも出なければ、検査は空振りです。このアプリでは、束ねる側の一覧が当時0件でした。今は各設定を順に検査する npm run typecheck を用意しています。

バイブコーディングの失敗で成功表示すら出ない型 再試行が上限の3.1倍を叩いた日

偽の成功の隣には、成功表示すら出さずに失敗し続ける型もあります。2026年9月3日、PC同期アプリで139ファイルの送信が707回失敗していました。

5分おきに、止まらずにやり直していた

失敗したファイルは、5分おきに再試行する作りでした。回数の上限はなく、永久に繰り返します。

ストレージ側には、1日2,500件の上限を自分で設定していました。そこへ届いたのが7,815件で、上限の3.1倍です。

上限に達すると、以後のリクエストはすべて403（アクセス拒否）になりました。同期そのものが止まっています。

画面は「競合の解決に失敗しました」としか言わない

利用者の画面に出たのは、競合の解決に失敗しました、という表示だけでした。上限の話も、再試行の回数も出てきません。

AIも最初は、鍵や地域の設定を疑いました。どちらも外れです。

1日の件数が見えたのは、ストレージの管理画面（Caps & Alerts）でした。私はこの画面で、上限と実際の件数を確かめています。

確かめ方は、再試行の回数と間隔をAIに聞く

やり直す処理があるなら、何回まで、何分おきに、最後にどう知らせるかをAIに聞いてください。回数の上限は無い、と答えたら要注意です。

外部サービスの管理画面で、1日の件数を1回見ておくのも効きます。普段の件数を知っていれば、3倍に跳ねた日に気づけます。

バイブコーディングの危険性はどう減らす？ 4種の見抜き方

バイブコーディングの危険性は、成功表示を疑う確かめ方を種類ごとに1つ持てば減らせます。どれも、壊す、切る、数えるのどれかで、5分あれば試せます。

AIの説明にも、根拠のファイルを聞く

AIの説明も、成功表示と同じで裏付けが要ります。2026年8月24日、AIが本番の配信先を取り違えたことがありました。

根拠は、リポジトリに残っていたvercel.jsonでした。AIはそれを見て、pushすればVercelが反映すると説明したのです。本番は3日前に、Cloudflare Pagesへ移していました。

私はその場で「Vercel？ Cloudflare Pages じゃなくて？」と聞き返しています。何を見てそう言ったのかを聞けば、古いファイルが根拠だと分かります。

AIに頼むときは、証拠を出してと添える

Claude Codeの公式ドキュメントは、成功を主張させる代わりに、証拠を示させるよう勧めています。直った、通った、と返ってきたら、何件を検査したかを数字で聞き返してください。

答えが0件なら、それは4つ目の偽の成功と同じです。数字で答えられない報告は、まだ確かめていない報告として扱います。

検証で報告の誤りを止めた場面は、AI業務自動化の実例と検証の記録にも書いています。係ごとに分けたAIの報告を機械で検査し、304本中23本が落ちた話はClaude CodeのAI社員の作り方で読めます。

毎回手で試すのがつらい人へ

とはいえ、確かめ方が分かっても、毎回手で試すのは続きません。忙しい日ほど、成功の表示をそのまま信じたくなります。

完了報告を機械に確かめさせる手順は、有料noteにまとめました。Claude Code向けの検証スクリプトです。コピペで使えるひな型つきです。Claude Codeを使い始めて数週間で、完了報告を毎回目で追っている人に向けて書いています。

採用管理のシステムでは何が起きた？ 同じ日に応急処置5回

採用管理のシステムでは、デプロイが失敗した2025年11月26日に、応急処置を5回続けて重ねていました。根本の修正は、10か月後の2026年9月25日です。

同じ日に重ねた5つの応急処置

デプロイとは、作ったシステムを本番に反映する作業です。この日のコミットには、次の5つが続けて並んでいます。

この日のデプロイ記録には、失敗とエラーが4件、成功が13件あります。成功の表示が出たことで、5回分の継ぎはぎはそのまま残りました。

デプロイ記録779件の失敗とエラーは計20件

GitHubのデプロイ記録779件を月ごとに数えると、失敗とエラーは次のとおりでした。

2026年9月25日に、ビルドをnpm ciに統一し、Nodeを24.xへ上げる修正を入れました。npm ciは、ロックファイルどおりに部品を入れるコマンドです。

応急処置を重ねる前に、1回目の意味を説明させる

同じ日に2回目の応急処置を頼む前に、1回目で何が変わったかをAIに説明させてください。説明できない変更を重ねると、元の原因が見えなくなります。

通ったから終わり、にしないことも大事です。通った理由を1行で言えない修正は、あとで同じ場所がまた崩れます。

AIで作れるようになったあと、その力を副業にする話は、Claude Code副業の始め方と単価相場で書きました。

まとめ：バイブコーディングの失敗はfixの数に出る（fix 118件、feat 59件）

バイブコーディングの失敗は、fixの数に出ます。社内のファイル共有アプリでは、fixが118件、featが59件でした。

fixが多いこと自体は悪くありません。見つけて直した記録だからです。怖いのは、fixになる前の、成功表示のまま眠っている箇所のほうです。

バイブコーディングの失敗は、成功表示の数だけ隠れている

自分のプロジェクトのfixの数は、次のコマンドで数えられます。

<code>git log --oneline --grep="^fix" | wc -l</code>

今日1つだけ試すなら、保存ボタンを押して再読み込みしてください。バイブコーディングの失敗を減らす一歩目は、成功の表示を1回だけ疑うことです。

それでも作るのは、使う人数に上限がないから

失敗をこれだけ並べても、私はバイブコーディングをやめていません。自作のシステムには、使う人数の上限がないからです。

SaaS（月額で借りるクラウドサービス）では、人数が増えると料金も上がる契約をよく見かけます。自作なら、人を足しても席の料金はかかりません。

採用管理のシステムは約20名、ファイル共有アプリは約100名が使っています。ファイル共有アプリの保存先の利用料は容量で変わり、直近の請求は700円ほどでした。

裏側のサービスは3つです。ファイル置き場のBackblaze B2と、Supabase、Cloudflareを使っています。人数の上限を気にせず配れる代わりに、検査は自分の仕事になります。

バイブコーディングの失敗でよくある質問

Q. バイブコーディングとは何ですか？

AIに自然な言葉で指示して、コードを書かせる作り方です。Collins英語辞典は、vibe codingを2025年のWord of the Yearに選んでいます。

Q. バイブコーディングの失敗で多いのは何ですか？

私の実運用アプリで目立ったのは、成功と表示して何もしていない箇所でした。偽の保存、0件表示、空振りテスト、検査0件の型チェックの4種です。

Q. Claude Codeの完了報告は信用できますか？

私の記録で起きていたのは、確かめていない成功表示でした。成功と言われたら、何件を検査したかを数字で出させてください。

Q. AIの成功表示はどう見抜けばいいですか？

壊す、切る、数えるの3つで確かめます。保存後に再読み込みする、Wi-Fiを切って開く、検査したファイル数を数える、の順が手軽です。

Q. 型チェックが通れば安心ですか？

安心できません。私のアプリでは型チェックが毎回成功していたのに、検査したファイルは0件でした。–listFilesで検査対象の数を確かめてください。

Q. AIが書いたテストは信用できますか？

壊して確かめるまでは、信用しないでください。1行ずつ壊して調べたら、テスト2本と飾りのガード1つが空振りでした。

Q. コードが読めなくても偽の成功は見つけられますか？

見つけられます。保存して再読み込みする方法と、Wi-Fiを切って画面を開く方法は、コードを読まずに試せます。

Q. バイブコーディングの危険性で見落としやすいのは何ですか？

黙って失敗し続ける再試行です。私の同期アプリでは、139ファイルが707回失敗しました。1日の上限2,500件に7,815件が届き、同期が止まっています。

Q. 失敗が多いならClaude Codeは使わないほうがいいですか？

やめる必要はないと考えています。失敗例にはBoltで作っていた時期のコードも混ざっていて、原因は検査しない運用の側にありました。自作なら使う人数に上限がなく、私のファイル共有アプリは約100名が使っています。

Q. 自分のプロジェクトの失敗の多さはどう測れますか？

gitのコミットで、fixとfeatの件数を数えると目安になります。私のファイル共有アプリはfixが118件、featが59件で、直した回数が2倍でした。

公開日: 2026年9月29日　最終更新日: 2026年9月29日