どうも、レイと申します。
7月下旬の沖縄、夕方になると時々かたぶい（局地的な通り雨のことです）が降ってきて、洗濯物との我慢比べが続いてます。あと今年はやたらと台風が多いですね。。。
停電すると本業の顧客のサーバも止まるので、この時期はUPSの前を通るたびにちょっと拝んでます笑
さて今回は、バイブコーディングの話です。
去年あたりからXでもニュースでも「バイブコーディング」って言葉を見ない日がなくなってきて、今年に入ってからは完全にバズワード化してる感があります。
で、僕はこの言葉を最初に見たとき、正直こう思ったんですよ。
「また新しいカタカナか……」でも調べてみたら、**僕がこの1年やってきたことにピッタリ名前が付いてただけ**でした。
というわけで今回は、バイブコーディングで個人開発アプリを作って実際に公開・運用してる側から、良かったことも痛かったことも含めて書いていきます。
そもそも「バイブコーディング」って何なん？
まず言葉の整理からいきます。このブログの通例定期。
バイブコーディング（Vibe coding）は、「自然言語でやりたいことを説明して、コードはAIに書かせる」という開発スタイルのことです。
提唱したのはアンドレイ・カルパシーさん（OpenAIの共同創設者で、元テスラのAI責任者）で、2025年2月のことらしいです。
本人の表現がなかなかパンチが効いてて、
完全にバイブスに身を委ね、コードが存在することすら忘れる
みたいなことを言ってたそうです。バイブスに身を委ねる。エンジニアの発言とは思えない字面ですね笑
これ、ネタっぽい言葉なのに2025年のコリンズ英語辞典の「今年の言葉」に選ばれてるんですよ。ちゃんと辞書に載る言葉になってしまった。
AIエージェントの話と何が違うの？
「それ、前に書いてたAIエージェントと同じじゃないの？」って思った方、鋭いです。
僕の整理はこうです。
AIエージェント = 道具の話。バイブコーディング = 作り方（態度）の話。Claude Code みたいなエージェントは「道具」なんですよね。それを使ってコードを1行ずつ自分で書くのをやめるという、作り手側のスタンスの変化がバイブコーディング。
だから「エージェントを使ってるけど、生成物は全部読んで自分で書き直す」人はバイブコーディングとはちょっと違って、「動いてるからOK、次いこう」まで行くとバイブコーディングって感じ。
……で、この「動いてるからOK」が後で僕の首を絞めるんですが、その話は後半で。3月に書いたAIエージェントの記事の、完全な実践編になります。
インフラエンジニアがAIエージェントを半年使い続けた、正直な感想 - Blog
Claude CodeをはじめとするAIエージェントを半年以上使い続けてわかったこと。便利なだけじゃない、インフラエンジニアから見たリアルな話を書きます。
reiblast1123.com
気づいたら僕、全部これで作ってた
で、ここからが本題。
僕、去年から個人開発でアプリを作ってるんですが、いま公開してるのがこれだけあります。
| アプリ | 何するやつ | フレームワーク |
|---|---|---|
| ミルポン | 赤ちゃんの育児記録（ミルク・睡眠・おむつ） | SvelteKit |
| ShaKeeper | 車検の満了日を忘れないための管理アプリ | Next.js |
| ちゅらPIN! | 沖縄ドライブの口コミマップ（クローズドβ） | SvelteKit + MapLibre GL |
| Charin | AIがFXの売買タイミングを教えてくれるやつ（公開停止中） | Vue 3 |
| このブログ | 今読んでるこれ | Astro |
さて、ここで気づいてほしいことがあって。
フレームワークが全部バラバラなんですよ。
SvelteKit、Next.js、Vue 3、Astro。5つ挙げて4種類です。
僕、インフラエンジニアなんですよ。本業はサーバとネットワークで、フロントエンドのフレームワークを業務で書いたことは一度もない。
なのに4種類使ってる。おかしいでしょ。普通に考えたら、フレームワーク1個をちゃんと覚えるのに数ヶ月はかかるはずなんですよ。それを4つ、しかも本業やりながら？無理でしょ普通。
でもできてるんです。理由は単純で、「すべてのフレームワークの書き方」を覚えてないからです。覚えてないけど動くものは作れてる。これがバイブコーディングの一番わかりやすい効果でした。
「誰でもフルスタック」は、けっこう本当だった
最近よく言われる「AIで誰でもフルスタックになれる」って話、正直ちょっと胡散臭いと思ってました。
でも1年やって、これは半分くらい本当だなと思ってます。
効いたこと1: 「知らない技術」への恐怖が消えた
これが一番デカい。
昔の僕なら、地図アプリを作ろうと思った時点で「地図のライブラリ何使うの？タイルって何？」で1週間くらい調べて、たぶんそのまま飽きてました笑
今は「沖縄の地図にピンを立てられるようにしたい」って言えば、叩き台が出てくる。**着手のハードルがほぼゼロになった**んですよね。
やる気があるうちに動くものができる。 これ、個人開発において死ぬほど重要です。個人開発が続かない理由の9割は「環境構築で飽きた」だと思ってるので。
効いたこと2: バックエンドを統一できた
面白いのが、フロントはバラバラなのに裏側は全部Cloudflareに統一できたことです。
インフラエンジニアとして、ここは自分の土俵なんですよね。だから「フロントはAIに任せて、インフラ構成は自分で決める」という分担が自然にできた。
結果的に、自分の得意分野に集中できてる。これは想定してなかった副作用でした。効いたこと3: テストを書くのが苦じゃなくなった
個人開発でテスト書くの、正直めんどくさいじゃないですか。
でもAIに「これのテスト書いて」って言うと書いてくれるので、ミルポンとShaKeeper、ちゅらPIN!はちゃんとテストがあります。人生で初めて「テストがある個人開発」ができました笑
でもAIは、自信満々に間違える
ここからが正直な話です。良い話ばかりじゃない。
事件: masterブランチに直プッシュされる
一番多かったのがこれ。
僕、Gitのルールとして「機能開発はブランチを切ってPRでマージする」ってのを自分に課してるんですが、AIエージェントは放っておくと平気で master に直プッシュしてくるんですよ。
「変更をコミットしといて」って軽く言うと、そのまま本流にドン。しかもこっちが気づく前に「完了しました！」って報告してくる。堂々としてるんですよね、態度が。悪意がないぶんタチが悪い笑
あと、masterにコミットしてから「masterにコミットしてしまいました」とか抜かすときがあって、それもイライラします爆笑
「コミットして」という指示に対して、AIから見れば master に直接コミットするのが最短で目的を達成する手段なんです。合理的ではある。
でもチーム開発やレビュー文化のある現場でこれをやられたら普通に事故です。個人開発でも、後から履歴を追いたいときに困る。
対策: 指示のたびに言うのではなく、リポジトリにルールを文章で置くのが効きました。僕は CLAUDE.md に「必ず feature ブランチを切ってPRを出す」「master への直pushは禁止」と書いてます。これを置いてから、直プッシュはほぼゼロになりました。
これ、教訓としてはめちゃくちゃ重要で。AIに「やってほしくないこと」を明文化しないと、AIは最短ルートを選ぶということなんですよね。
存在しないオプションを堂々と提案してくる
あと地味に多いのが、存在しないコマンドオプションや設定項目を自信満々に出してくるやつ。
「このオプション付ければいけます！」って言われて、実行したら unknown option 。ドキュメント確認したらそんなオプションない。お前の脳内にしかないやつだったか……
インフラの仕事でこれをやられると危ないんですよね。設定ファイルの書式とか、うっかりそのまま入れると事故る。なのでコマンド・設定系は必ず公式ドキュメントで裏を取るようにしてます。
……という書き方をすると偉そうですが、僕も何回か「動かないな？」って30分溶かしてから気づいてます(´・ω・｀)
Gemini CLIも試したけど、戻ってきた
ツールの話も少し。
僕のメインは Claude Code なんですが、Gemini CLI も一瞬使ってました。無料枠が太いって聞いたので。
結果、精度がいまいちで Claude Code に戻りました。指示の解釈がズレることが多くて、修正のやりとりが増えて結局トータルで遅くなる感じ。
まあこれ、2026年7月現在の僕の使い方での感想なので、次のバージョンで化ける可能性は全然あります。この界隈、3ヶ月で景色変わるので。【本題】「動いてるからOK」で見落とした話
ここが一番書きたかったところです。
さっき「動いてるからOK、まで行くとバイブコーディング」と書きましたけど、これの怖さを自分のブログで体験しました。
このブログには管理画面（記事を書くためのWYSIWYGエディタ）があるんですが、これも当然バイブコーディングで作ったんですよ。認証をかけて、自分だけがログインできるようにして。
で、ちゃんと動いてた。ログインできるし、他人は入れない。テストも通る。
でも後から自分で見直したとき、認証まわりの作りに設計思想レベルの問題があることに気づきました。
セキュリティの世界には、こういう考え方があります。
- fail-open（フェイルオープン）: 何か想定外のことが起きたとき、通してしまう向きに倒れる
- fail-closed（フェイルクローズ）: 何か想定外のことが起きたとき、閉じる向きに倒れる
セキュリティ機構は原則 **fail-closed でなければいけない**です。認証の判断材料が揃わなかったときは「とりあえず通す」ではなく「わからないので拒否する」が正解。
僕の管理画面は、ここが逆向きに倒れる作りになっていました。普通に使ってる限りは何も起きないけど、想定してない状況になったときに閉じてくれない、という状態。
すでに fail-closed に修正済みです。 そのうえで、この記事では具体的な条件や再現手順は書きません。ここに書くべきことじゃないので。
で、何が言いたいかというと。
AIは「動くコード」を書くのは超得意だけど、「動かないべきときに止まるコード」は、言わないと書いてくれない。これなんですよ。
AIに「認証をつけて」と頼むと、認証は付きます。ログインできるようになる。動く。でも「認証の材料が揃わなかったときにどう倒れるべきか」までは、指示に含まれてない限り考えてくれない。
そして動いてるものは、レビューしないんですよ人間って。
エラーが出てれば直します。テストが落ちれば気づきます。でも「正常に動いてる」ものを、わざわざ疑って読み返す人がどれだけいるかって話で。バイブコーディングの一番危ないところは、ここだと思ってます。
「バイブスに身を委ねる」の代償を、自分のブログで払った感じですね。授業料としては安く済んだのでよかったですが。インフラ屋だから引っかかった、3つの違和感
同じ経験をしたインフラの人はうなずいてくれると思うんですが、バイブコーディングをやってて「うーん」と思う部分を挙げときます。
1. 「動いた」が「安全」に見えてしまう
さっきの話そのままです。
インフラの現場だと、構築が終わったあとにセキュリティ試験や設定レビューという工程が必ず入りますよね。あれ、めんどくさいけど本当に意味があるんだなと改めて思いました。
個人開発だとこの工程が丸ごと抜け落ちるので、意識的に「疑う時間」を作らないとダメ。
2. 運用と監視の視点は、AIから出てこない
これも結構思うところで。
AIは機能を作るのは上手いんですが、「これ落ちたらどうやって気づくの？」という話を自分からはしてこないんですよね。
ログをどう残すか、異常をどう検知するか、DBが壊れたときにどう戻すか。インフラエンジニアが真っ先に気にするところが、生成されたコードにはスッポリ無いことが多い。
逆に言うと、ここが僕らの残る仕事だなとも思ってます。3. 「読めないコード」が自分の資産になる
これはちょっと哲学的な話ですけど。
僕、ちゅらPIN! のSvelte 5 の書き方、正直まだフワッとしか理解してないです。動いてるから使えてるけど、AIなしで全部書けるかというと厳しい。というか無理。
これって技術的負債なのか？と言われると、たぶんそうなんですよね。
でも、これって本当に負債なのか？（個人的な考え）
ちょっと考えたんですが、僕はこう思ってます。
昔の僕は「フレームワークを覚えてないから作れない」で0個でした。今は「覚えてないけど動くものが4個ある」。
0個と4個なら、4個のほうがいいと思うんですよ。ユーザーさんに使ってもらえてるものが実際にあるので。
ただし条件があって、「壊れたときに直せる人」が最低1人（＝自分）は必要。だから僕は、フレームワークの細かい書き方は覚えなくても、アーキテクチャ（どこにデータがあって、どこで認証してて、どう繋がってるか）は自分で説明できる状態を保つようにしてます。
書き方は忘れてもいい。構造は絶対に把握しておく。この線引きが、僕の中での折り合いのつけ方です。
それでも僕はバイブコーディングを続ける
散々注意点を書きましたが、結論はポジティブです。
いまミルポンとShaKeeperはOPENβで、実際に使ってくれてる方がいます。ちゅらPIN! は口コミを集めてるクローズドβの段階。
これ、バイブコーディングなしでは1個も存在してなかったと思います。インフラエンジニアの僕が、フロントエンドを業務で一度も書いたことないのに、公開して運用できるアプリを持てた。この事実だけで、僕にとっては十分すぎる価値があります。
だから僕のスタンスはこうです。
「作るのはバイブスで。疑うのは自分で。」叩き台はAIに全力で作らせる。速度は落とさない。でも**認証・権限・データの扱いだけは、必ず自分の目で見る**。ここだけ死守すれば、あとは思い切ってバイブスに委ねていいと思ってます。
インフラエンジニアとしての経験が、ちょうどこの「疑う」部分に効いてるのが、なんだか救われた気持ちになりました笑
免責事項
本記事の内容は筆者個人の経験・見解に基づくものです。記事の情報を参考にした結果について、筆者は一切の責任を負いません。
生成AI・AIエージェントの利用にあたっては、各自が所属組織のルール・利用規約・適用される法令を必ず確認してください。特にコードやログを外部サービスに渡す場合は、業務情報の取り扱いルールを事前に確認してください。
おわりに
「バイブコーディング」ってバズワードとして流れてくると胡散臭く聞こえるんですけど、やってることは「作りたいものが作れる人の範囲が広がった」だけなんですよね。
そのぶん、作ったものに責任を持つ範囲は変わってないというのが、今回の記事で一番書きたかったことでした。動いてるものを疑うの、大事です。ほんとに。
次回は、個人開発つながりでちゅらPIN!（沖縄ドライブの口コミマップ）の紹介記事を書こうかなと思ってます。地図アプリって作ってみると想像以上に面倒で、公式のバスレーン規制データを地図に載せるあたりでかなり苦労したので、そのへんの話ができたら面白いかなと。
そろそろ本格的に夏がやってきます。熱中症には十分注意しましょう(^o^)
それでは！次回もよろしくお願いします。