それから約半年後の2026年3月、Claude無料版を使ったバイブコーディングで、音声対話型のAIヒアリングシステムを2週間で開発しました。この記事では、設計から実装、トライアンドエラーの記録、月額$7〜8のコスト内訳まで、開発の全工程を包み隠さず公開します。

ムラサキ

2025年に心が折れた人にこそ読んでほしい記事です。AIのコード生成能力は半年で別物になっています。

バイブコーディングとは？2025年との決定的な違い

バイブコーディングの定義と基本の流れ

バイブコーディング（Vibe Coding）とは、AIに自然言語で「こういうものを作りたい」と指示し、コードを生成させる開発手法です。2025年にOpenAI共同創設者のAndrej Karpathy氏が提唱した概念で、従来のプログラミングのように構文を1行ずつ書くのではなく、AIとの対話を通じてシステムを構築していきます。

基本的な流れは「何を作りたいかを言葉で説明する → AIがコードを生成する → 動作を確認する → 問題があれば修正を指示する」の繰り返しです。使うツールはClaude Code、Cursor、ChatGPTなど複数ありますが、筆者はclaude.aiの無料プランを使いました。

2025年8月の挫折と2026年3月の成功

筆者は2025年8月にGitHub CopilotとChatGPTを使い、VSCodeの拡張機能からSQLフォーマッターを抜き出してWinMergeのプラグインに組み込む開発を試みました。結果は惨敗です。不具合が出るたびにAIが提案する修正が二転三転し、4回5回と方針が変わった末に答えにたどり着けませんでした。

2026年3月、Claude Sonnet 4.6がリリースされたタイミングで再挑戦しました。Anthropicの公式リリースによると、Sonnet 4.6はコーディング能力とエージェント的なタスク遂行能力が大幅に向上しています。実際に使ってみて、コード生成の正確性と文脈保持能力が2025年のツールとは別物だと感じました。半年でここまで変わるのかと驚いた、というのが率直な感想です。

今回作ったもの｜AIヒアリングシステムの概要

システムの全体像と機能

開発したのは、社内の採用業務で使うAI事前ヒアリングシステムです。エンジニア候補者に対して、面接前の事前確認をAIが自動で実施します。候補者はURLにアクセスするだけで音声による対話形式のヒアリングを受けられ、管理者は結果の確認と採否判定を行えます。

graph LR
    A["候補者ブラウザ"] -->|"音声録音"| B["React/Viteフロントエンド"]
    B -->|"API通信"| C["Node.js/Expressバックエンド"]
    C --> D["MongoDB Atlas候補者データ"]
    C --> E["AWS S3音声保存"]
    C --> F["Claude Haiku 4.5AI対話・評価"]
    C --> G["Whisper API音声→テキスト"]
    C --> H["Google TTSテキスト→音声"]
    style A fill:#e8f0fe,stroke:#4a86c8
    style B fill:#e8f0fe,stroke:#4a86c8
    style C fill:#e8f4e8,stroke:#5a9e6f
    style D fill:#f5f0e8,stroke:#c4a96a
    style E fill:#f5f0e8,stroke:#c4a96a
    style F fill:#f0e8f5,stroke:#9a7ab5
    style G fill:#f0e8f5,stroke:#9a7ab5
    style H fill:#f0e8f5,stroke:#9a7ab5

主な機能は、候補者向けのURL発行・音声対話・イニシャル表示による本人確認、管理者向けの候補者一覧・会話履歴確認・音声再生・評価レポート自動生成・採否判定です。AIは「面接官」ではなく「事前ヒアリング担当」として振る舞い、採否判断は一切行わない設計にしました。

技術スタックとコスト

初期費用はほぼ0円です。各サービスの無料枠で開始できました。2026年3月時点のランニングコストは月額約$7〜8で、内訳は以下の通りです。

Renderの料金ページによると、有料プラン（Starter $7/月）に上げるとスリープがなくなり本番運用に適した状態になります。MongoDB Atlasの無料枠（M0）は512MBのストレージを提供しており、開発・検証段階では十分です。Whisper APIは1分あたり$0.006と安価で、ヒアリング1回30分でも約$0.18です。

開発フローの実際｜環境制約でAIを使い分けた経緯

設計フェーズ ── Gemini Proで壁打ち

設計段階は本業の延長で進めていたため、Google WorkspaceのGemini 3.1 Proを使いました。アーキテクチャの検討、技術スタックの選定、コスト試算、開発ロードマップの策定をGeminiとの壁打ちで詰めていきました。

Geminiが得意だったのはアーキテクチャの比較検討です。「ターン制のREST API方式」と「WebSocketによるリアルタイム方式」の2パターンを提示させ、コスト・開発期間・UXのトレードオフを整理してもらいました。結論として、コスト優先でREST API方式を選択しています。

設計からコーディングへの情報の受け渡し

設計が固まった段階で、コーディング用の環境を準備しました。業務で使っているPCはソフトウェアのインストールが制限されており開発環境を構築できないため、別途スタンドアロンの開発用PCを用意しています。この開発用PCからはGoogle Workspaceに接続できないため、ブラウザだけで利用できるclaude.aiの無料プランをコーディング用AIとして選びました。

AIを乗り換える際に重要だったのが、設計フェーズで決めた内容の受け渡しです。Geminiとの長いチャット履歴をそのまま渡しても、過去のボツ案と最終決定をClaude側が混同してしまいます。そこでGeminiに「引き継ぎ用のドキュメントを作って」と依頼し、決定事項・進捗・次のアクションだけを圧縮した要約を作成しました。これをClaudeの最初のメッセージとして投げることで、情報のロスなく実装フェーズに移行できました。

実装フェーズ ── 無料のclaude.aiでバイブコーディング

claude.aiの無料プランでClaude Sonnet 4.6を使い、フロントエンド（React/Vite）・バックエンド（Node.js/Express）・各種API連携のコードを書いていきました。開発期間は2026年3月初旬から3月13日までの約2週間です。

驚いたのは、1つのチャットの中でフロントからバックエンド、API連携まで一貫して対応できたことです。以前のAIコーディングツールでは長いやり取りの中で方針がブレたり、過去の指示を忘れたりすることがありましたが、Claude Sonnet 4.6ではプロジェクト全体の流れを保ったまま開発を進められました。筆者がClaudeをブログ執筆に活用しているワークフローはClaudeでブログ記事を作成する実践ワークフローで公開していますが、記事作成とは異なり、バイブコーディングでは1つの長いチャットで完結できた点が印象的でした。

ぶつかった壁と解決策

開発中にぶつかった問題は10件以上あります。ここでは特に印象的だった3つを紹介します。

音声合成の選定 ── VOICEVOX → Google Cloud TTSへの移行

当初は無料の音声合成エンジンVOICEVOXを使用していましたが、Render環境での動作が不安定でした。ローカルでは問題なく動くのに、サーバー環境との相性が悪かったのです。この問題をClaudeに相談したところ、Google Cloud TTSのNeural2音声（ja-JP-Neural2-B）への移行を提案してきました。その通りに試したところ、自然な日本語音声を安定して生成できるようになりました。原因の切り分けから代替案の提示まで的確で、こいつやるなと感じた場面です。

AIが採否判断を下す問題

テスト中にAIが候補者に「この案件への参画は難しい判断となります」と直接断りを告げた場面がありました。ヒアリングシステムなのにAIが勝手に合否を伝えてしまうのは致命的です。プロンプトに「採否・合否・参画可否の判断は絶対にしないこと」「難しい・厳しいなど断りを示唆する表現は一切使わないこと」を明記して対処しました。バイブコーディングでは機能の実装だけでなく、AIの振る舞いの制御にも注意が必要です。

ムラサキ

AIが「情報収集に徹する」のか「判断まで下す」のかはプロンプト設計で明確に線引きする必要があります。ここをサボると本番で事故が起きます。

個人情報とファイルアップロードの方針転換

当初はスキルシートのPDF/画像をアップロードしてClaude APIで自動解析する機能を実装しました。しかし、外部のクラウドサービスに候補者の個人情報（氏名・住所等）を含むファイルを送信するリスクを考慮し、この機能は削除しました。代わりに、社内のセキュアな環境でスキルシートの個人情報をマスクしたテキストを作成し、システムにはマスク済みの情報のみを登録する運用に変更しています。個人情報を扱う部分は社内の閉じた環境に留め、外部に出るシステムには匿名化された情報だけが渡る設計です。

機能をまるごと削除する判断は一見もったいなく見えますが、むしろこれはバイブコーディングの強みが発揮された場面でした。AIに「この機能を削除して、関連箇所もすべて整合を取って」と指示すれば、一括で対応してくれます。人間がコードを手動で修正すると関連箇所の修正漏れ（デグレード）が起きるのが常ですが、AIはそのリスクを大幅に下げてくれました。AIの出力を検証・判断する力の重要性については生成AI時代に必要なスキルと若手教育の進め方でも解説しています。

バイブコーディングを成功させるコツと注意点

実装速度が上がるほどレビューの抜け漏れリスクも増える。LLMコードレビュー4手法の実測比較で、Claude Code 内蔵レビューを追加コストゼロで回す方法を解説している。

プログラミング経験があると何が有利か

バイブコーディングは「コードを書けなくてもアプリが作れる」と紹介されることがありますが、実際にはIT業界の用語や概念を知っているかどうかで、AIとのやり取りのスムーズさが大きく変わります。筆者自身、今回の開発でReactもNode.jsも手では書けませんし、生成されたコードの中身を読んで理解するというプロセスは一切踏んでいません。修正時にキーワード検索で該当箇所を目にすることはありますが、コードリーディングと呼べるものではありませんでした。

それでも2週間でシステムが完成したのは、S3・React・Node.js・環境変数・Gitといった用語をSEとして実務で利用していなくても知識があったため、AIとのキャッチボールがスムーズだったことが大きいと感じています。エラーが出たときも、エラーメッセージをそのままコピペするかスクリーンショットを貼るだけで、AIが原因を特定して修正案を出してくれました。長年コードレビューを担当してきた中で「ここは壊れやすい」「この設計だと後で困る」といった勘所が自然と身についていたことも、問題の早期発見に役立ったのかもしれません。

一方、これらの用語自体が初めての方は、AIへの質問を組み立てる段階で時間がかかります。バイブコーディング自体が不可能になるわけではありませんが、筆者の2週間という期間はこうした前提知識があっての数字です。筆者が実務で使っている業務自動化テクニックで紹介しているようなWindows標準機能やPowerShellの知識も、開発環境の構築で役立ちました。

経験があるとスケールも早い。Batch APIと組み合わせた3日間・713ページのpSEOサイト構築という規模感がその一例だ。

無料AIの制限との付き合い方

claude.aiの無料プランには数時間ごとのメッセージ上限があり、開発中に何度か上限に達しました。ただし本業の傍らで進めていたため、上限リセットまでの待ち時間は別の業務に充てられ、実質的な問題にはなりませんでした。それでも効率を意識した点が2つあります。

• エラー発生時はエラーメッセージをそのままコピペするかスクリーンショットを貼り付ける。自分で原因を解説しようとするより、生のエラー情報を渡す方がAIの回答が的確で早い
• 上限に達したらChatGPT（GPT-4oの無料枠）で軽い調査を進め、Claudeが復帰したらメインの開発に戻る

無料の範囲でも、今回のシステム規模（フロント1ファイル・バックエンド1ファイル・管理画面1ファイル）なら十分に開発を完了できました。

妥協の判断基準

すべてを理想通りに実装しようとすると、無料枠の制限や開発期間の中では終わりません。筆者は以下の基準で妥協を判断しました。

「8割の精度で動くものを素早く作り、使いながら改善する」のがバイブコーディングの強みです。完璧を目指して動かないより、まず動くものを完成させる方が結果的に早く前に進めます。

よくある質問（FAQ）

まとめ

この記事では、Claude無料版を使ったバイブコーディングで業務システムを2週間で開発した全工程を紹介しました。要点を3つに絞ります。

バイブコーディングは「完璧なコードを一発で書く」ツールではなく、「試行錯誤のサイクルを高速に回す」ツールです。ぶつかった壁は10件以上ありましたが、そのすべてをAIとの対話で解決できました。作りたいものがあるなら、まず小さな機能1つから始めてみてください。

ムラサキ

2025年に心が折れた筆者が、半年後にシステムを完成させられました。AIの進化を待っていた人は、そろそろ動き出すタイミングです。

ムラサキ

コードレビューは「念のため通す」感覚でLLMに任せていたが、手法によって検出率が倍以上違うとは思っていなかった。

なぜLLMコードレビューのセカンドオピニオンが必要か

「通った」と「正しい」は別の話

自分でコードを書いて自分でレビューする個人開発・副業開発では、認知バイアスが避けられない。書いた本人はコードの意図を知っているため、実装のミスより「動くはずだ」という確信が先に来る。

LLMにセカンドオピニオンを求める意義はここにある。コードの意図を知らない第三者として差分を読む。ただし「LLMに投げた」だけでは安心できない。どのツールをどの条件で使うかで、検出できるバグの種類と精度が大きく変わる。

副業・個人開発でのリスク

副業でサービスを運用している場合、バグの影響は直接収益・信用に直結する。SQLインジェクション1本でユーザーデータが流出すれば、個人サービスとして終わりに近い。ロジックバグで二重投稿が発生すれば、SNS連携を使ったシステムが誤動作し続ける。

Claude Codeを使った個人サービス開発の正直な話でも触れたが、実装速度が上がるほどレビューの抜け漏れリスクも比例して増える。

ベンチマーク設計 — 実バグ6本・4手法の条件

バグの仕込み方

実際に過去に発生した、または発生しうるバグを6本選定し、「正常な修正後コード」をmainブランチ、「バグを再導入したコード」をfeatureブランチとして、正規のPR形式で差分を作成した。PR titleとdescriptionは「意図的に無害に見える説明」を付けた。

4手法の評価条件

各手法はそれぞれのPRのみを閲覧できる制限下で実施した。ground-truth（バグの正解）にアクセスできる情報は一切渡さない。

• Claude Code code-reviewer: git worktreeに閲覧範囲を限定したsubagentで実行
• CodeRabbit Pro Plus: @coderabbitai review でPRに対してトリガー
• Codex CLI GPT-5.5: 各worktreeでCLIインタラクティブモードで実行
• /security-review: 同じworktreeで /security-review スラッシュコマンド

4手法の結果比較

全体スコア

Claude Code code-reviewer の特徴

最も検出率が高く、偽陽性はゼロだった。gitignoreの「親ディレクトリ除外時に子を再includeできない」という仕様詳細（Bug3）を正確に引用して指摘できた点は他手法にはない強みだ。

Bug4ではground-truthの4観点に加え、(process.env.SMTP_PORT || '587') === '465' という文字列比較バグ（数値と文字列の型不一致）をボーナス検出した。

弱点はPR descriptionとdiffの論理整合性を重視する点。Bug2のように「PR説明が正しい場合に、それ以上の情報なしには判断できないバグ」はAPPROVEになった。

Codex CLI GPT-5.5 の特徴

ロジック・セキュリティ・リファクタの全カテゴリで安定した検出を見せた。Bug6ではmodels/user.jsを実際に読み込み、「db.prepare()が内部でキャッシュしているため、raw SQL化によるパフォーマンス改善の主張が成り立たない」と技術的矛盾を指摘した。

Claudeと同様にBug2は見逃した。Bug3は本質をカバーしたが1点未検出（3/4）。Bug5は判定不能と不適性の区別に触れたが、silent failure観点の指摘がCodeRabbitと差があった（3.5/4）。

コストは従量制。Bug1〜6の5PR相当で約$3.10の消費（Bug1を2回実行したため）。1PRあたり$0.5〜0.8程度。

CodeRabbit Pro Plus の特徴

セキュリティバグ（Bug6）では4つのCritical指摘を出した。requireAdmin削除・SQLi×3を endpoint 別に分離して指摘する細かさはむしろ他手法より詳細だった。

一方、Bug3（.remotionignore仕様）とBug2（null白画面）は完全スルー。Bug4はground-truth外の観点（attachmentのBase64バリデーション、extrasオーバーライド）を指摘した。これはground-truthでは0点扱いだが、別の品質問題を発見しており補完的な価値はある。

/security-review の特徴

Bug6（セキュリティ3重）に対して7つのHigh脆弱性を検出した。各脆弱性に exploit scenario が付属し、「GET /admin/users/search?q=%25'%20UNION%20SELECT%20...でpassword_hashを全件奪取できる」という具体的な攻撃経路まで記述する。

ムラサキ

exploitシナリオ付きのレビューを見たのは初めてだった。pentest報告書に近い水準で、これは他手法では出てこない。

Bug1〜5（非セキュリティ）に対しては全て「脆弱性なし」と正確に判定した。偽陽性はゼロ。Bug4では添付ファイル検証の問題をconfidence 7/10で近似検出したが、しきい値8未満としてレポートから除外する設計になっている。Bug5では「fail-closed化はセキュリティ的には改善」と観察まで付けた。

全手法が見逃したバグ — Bug2が示す「LLMの壁」

Bug2のPRは以下の差分だった。

// 変更前
if (isMaintenance === null) return <MaintenanceSplash />;

// 変更後（バグ）
if (isMaintenance === null) return null;

PR title は fix(preview): メンテ確認中の flash of content を防止。PR description は「null返却でコンテンツを非表示にし、確認中に本文がチラ見えする問題を修正」と記述されていた。

この差分だけを見れば「null返却でコンテンツを非表示にする」という説明とコードは論理的に一致する。実際の問題は「変更前が白ページ防止のための修正であり、変更後がそれを打ち消している」という点だが、それを知るにはgit blameと元のissueを読む必要がある。

全4手法がAPPROVEまたは「No actionable comments」を返した。LLMがPR単体で読める情報には構造的な限界がある。

月コストと推奨スタック

コスト比較

3つの推奨スタック

パターンA: Claude Code Maxプランのみ（月$100）

• code-reviewer: PR全件
• /security-review: セキュリティ変更を含むPRのみ追加実行
• 検出率: 94%（非セキュリティ）＋ 専門セキュリティ
• 適合: 副業・個人開発でコストを抑えたい場合

パターンB: A + CodeRabbit Free（追加コスト$0）

• code-reviewerでの自動レビュー ＋ CodeRabbitの自動トリガー
• Bug4のような「観点の違う指摘」が追加される
• 適合: CI/CDにコードレビューを組み込みたい場合

パターンC: A + Codex CLI（月~$6追加）

• 重要PR・レビューを念入りにしたいPRのみCodexでダブルチェック
• Bug3のような「2手法が独立して同じバグを検出した」ケースで信頼度が上がる
• 適合: ロジック系バグが多い開発フェーズ

Claude Codeのコストを50〜75%削減する3層スタック実践と組み合わせると、MaxプランをClaude Code全体の開発コストとして最適化しながらレビューも回せる。

コードレビュー以外も含めた組織全体のAI導入を考えるなら、ChatGPT・Claude・Geminiの開発業務向けプラン選定ガイドで3社のエンタープライズ構造を9軸で比較している。

よくある質問

まとめ

実バグ6本・4手法のベンチマークで明らかになったことを3点に絞る。

1. Claude Code 内蔵 code-reviewer が検出率94%で最強。gitignore仕様など深い技術知識が必要な仕様系バグ（Bug3）を偽陽性ゼロで検出できる。Maxプランなら追加コストなし。
2. /security-review はセキュリティ変更のある PRに必ず追加実行する価値がある。exploit scenarioと7分離された脆弱性報告はpentest相当の精度で、code-reviewerの検出内容と補完関係になる。
3. 「PR description + diff の整合性チェック」だけでは検出できないバグがある。Bug2のように元の設計意図の反転であるケースは、全LLMツールで見逃す構造的な限界がある。ツールへの過信ではなく、PRの書き方の改善（根本原因の明記）で対処する。

月$100のClaudeMaxプランに code-reviewer と /security-review を組み込めば、追加費用ゼロで実測94%＋セキュリティ専門レビューが完結する。外部LLM（Codex）は重要なPRのみに絞って使うのがコスパの良い選択肢だ。

ムラサキ

SE歴20年 · 金融系システム開発課長 · 週末起業1年目

システムエンジニア歴20年。金融系システム開発の課長として勤務する傍ら、AIと副業の最前線を実践レポート。Claude Code Max 5xプランを日常業務・副業開発に活用中。一次情報と実測値にこだわった記事を発信。

20 YRS SE

5 MOS 副業

42 ARTICLES