この記事は「AIでコード書けるらしいけど、実際どうなの？」と思っている人へ向けて書いています。
「バイブコーディングって最近よく聞くけど、本当に使えるの？」——僕もそう思ってました。で、実際に自分のプロジェクトで3ヶ月間やってみた結果をまとめます。
僕は福祉事業のIT全般をCTOとして担当しつつ、個人事業でAI×SaaS開発もやっています。今回の「実験台」になったのは、Mac mini M4 Proで24時間動かしている個人用AIエージェントシステム（Discord Bot + ダッシュボード + 自動タスク実行）です。このシステムをほぼClaude Codeだけで開発しました。
この記事を読むと、バイブコーディングの正体、Claude CodeとCursorの使い分け、そして「雰囲気で作る」の光と影がわかります。
バイブコーディングとは？ —「雰囲気で作る」の正体
バイブコーディング（Vibe Coding）は、2025年2月にOpenAIの共同創設者 Andrej Karpathy が提唱した開発手法です。
一言でいうと、「AIに自然言語で指示して、コードを生成させるスタイル」。
従来のプログラミングは1行1行自分でコードを書くもの。バイブコーディングでは「こういう機能がほしい」と日本語で伝えるだけで、AIがコードを書いてくれます。
ただし、大事な注意点があります。プログラマーの Simon Willison が指摘しているのですが、「すべてのAI支援プログラミングがバイブコーディングではない」 ということ。AIにコードを生成させつつ、自分でレビューしてテストを書くのはバイブコーディングとは別物です。
バイブコーディングの本来の意味は、「コードの中身を深く理解せずにAIの出力を受け入れるスタイル」。この違いを意識しておくと、後の話がスッと入ってきます。
実際にやってみた — Claude Code でAIエージェントシステムを作った話
やったこと
僕が Claude Code で作ったのは「masu-agent」という個人用AIエージェントシステムです。
- Discord Bot: ニュース配信、コンタクト管理、定期タスク通知
- ダッシュボード: React + Express で作ったWebUI。目標管理、成果物管理、ナレッジベース
- 自動化オーケストレーター: cronで動く定期ジョブ群（AIニュース収集、カレンダー通知など）
- MCPサーバー: SQLiteのCRUDをClaudeが直接操作できるようにするサーバー
TypeScriptモノレポで、パッケージ数は5つ。ファイル数でいうと100以上あります。
「雰囲気で伝えて」うまくいった瞬間
最初にバイブコーディングの凄さを実感したのは、ダッシュボードのUI実装です。
「RPGのステータス画面みたいなダッシュボードにして。glassmorphismで、DotGothic16フォントで見出し、ブランドカラーは #39b7ff」
これだけで、Reactコンポーネントが5個くらいバーッと生成されました。見た目はかなり良い。正直「これでいいじゃん」と思いました。
ここがバイブコーディングの「光」の部分です。 UIのプロトタイプや、構造が決まっている画面を作るのは異常に速い。
「雰囲気で伝えて」ハマった瞬間
問題は、その後です。
「ダッシュボードの統計APIで、tmuxセッションの子プロセスの起動時刻から稼働時間を計算して」
Claude Codeは pgrep -P <pid> を使ったコードを生成しました。macOSでは、自プロセスツリー内の親PIDに対してこのコマンドが失敗します。でもClaudeはそれを知らない。テストは通る（モック環境だから）。本番で動かすと壊れる。
結局、ps -eo pid=,ppid=,lstart= で全プロセスを取得してJSでフィルタする方法に書き直しました。この修正に半日かかった。 AIが書いたコードをデバッグする時間は、自分で書く時間の3倍かかることもある。これは本当にそう。
もう一つの失敗: Discord Bot のメッセージ送信
「Discord にAIニュースを毎朝配信する機能を追加して」
Claude CodeはチャンネルIDをハードコードしたコードを生成しました。動く。でも用途別にチャンネルを分けたくなったとき、全部書き直し。最初から環境変数で DISCORD_NEWS_CHANNEL_ID、DISCORD_CONTACTS_CHANNEL_ID と分けておけばよかった。
教訓：AIは「今動くコード」は書けるが、「将来の拡張性」は人間が設計しないとダメ。
Claude Code と Cursor の使い分け
Claude Code — プロジェクト全体を見渡す「設計者タイプ」
ターミナル上で動くAIエージェント。最大の特徴は、プロジェクト全体を俯瞰して複数ファイルにまたがる変更を一気にやってくれること。
僕の場合、Ghostty + tmux + Claude Code という環境で開発しています。tmuxのウィンドウを分けて、1つ目でClaude Code、2つ目でサーバー起動、3つ目でログ監視。
Claude Codeでよく使うのはPlan Mode。実装前に計画を立てさせて、それを確認してから実装に入る。この「計画と実装を分ける」が一番の学びでした。混ぜると中途半端な実装になりがち。
実際のプロンプト例:
「apps/dashboard-api/src/routes/stats.ts の /api/stats エンドポイントで、
tmux masu-agent セッションの子プロセス起動時刻を取得して稼働時間を返して。
macOS の pgrep は自プロセスツリーで失敗するから、
ps -eo pid=,ppid=,lstart= で一括取得してJSでフィルタする方式で。」
こういう「制約を先に伝える」のがコツ。失敗した経験があるから、次からはプロンプトに入れるようになります。
Cursor — エディタ内で「今のこの行」を直す高速ツール
一方Cursorは、VS Codeベースのエディタに統合されたAI環境。コードを書いている流れの中で「この関数を最適化して」「このエラーの原因は？」とサッと聞ける。
正直、masu-agentの開発ではCursorはほとんど使っていません。理由は単純で、ターミナル派だから。Claude Codeでプロジェクト全体を扱うワークフローが確立してしまうと、エディタベースのツールは「ちょっとした修正」にしか使わなくなりました。
ただ、Cursorが活きる場面もある:
- フロントエンドの細かいCSS調整: エディタで見ながら「ここの余白を12pxに」みたいな微調整
- 既存コードのリーディング: 知らないコードベースを読むときに「この関数は何をしている？」と聞く
- デバッグ: エラーログを貼り付けて「原因は？」と聞く即レス
僕の結論: 使い分けは「プロジェクトの規模」で決まる
- 新規プロジェクト or 大規模変更 → Claude Code（設計から入れる）
- 既存プロジェクトの保守・小修正 → Cursor（エディタ内で完結）
- 両方使える場面 → Claude Codeを先に使って全体設計、細部をCursorで仕上げ
バイブコーディングの「光と影」— 3ヶ月やってわかったこと
光: 驚くほど速い場面
- UIコンポーネントの生成: デザインリファレンスを渡せば、ほぼ一発で形になる
- CRUD APIの実装: テーブル定義を見せれば、ルーティング・バリデーション・エラーハンドリングまで出てくる
- テスト生成: 既存コードを見せて「テスト書いて」で網羅的なテストが出る
影: 人間がサボると壊れる場面
- OS固有の挙動: macOSとLinuxの差分をClaudeは知らないことがある（前述のpgrep問題）
- 設計判断: 「チャンネルIDをハードコードするか環境変数にするか」は人間が決めるべき
- セキュリティ: APIキーの扱い、認証ミドルウェアの設計は自分で考えないと危ない
Karpathy自身も1周年の振り返りで「楽しかったけど、ほぼうまくいっただけ」と総括していて、「Agentic Engineering」——AIエージェントを規律を持って監督するスタイルへの転換を提唱しています。
僕の実感もまさにこれ。「雰囲気で伝える」フェーズを卒業して、CLAUDE.mdにプロジェクトルールを書き、Plan Modeで設計を固め、セキュリティルールを明文化する。仕組みを整えてからAIに委任すると、出力の質が段違いに上がる。
バイブコーディングを知らないままだと何が起きるか
「まだ様子を見よう」と思うかもしれません。でも、この3ヶ月で僕が実感したのは、AIを使う人と使わない人の開発速度の差が、もう埋められないレベルになりつつあるということ。
masu-agentは、TypeScriptモノレポで100ファイル以上。Discord Bot、Webダッシュボード、自動化オーケストレーター、MCPサーバー。これを一人で3ヶ月で作れたのは、Claude Codeがなければ絶対に無理でした。
特にフリーランスや小規模チームにとって、AIコーディングは「使えたらいいな」ではなく「使えないと戦えない」ツールになっています。
この記事を書いた理由
僕はSESエンジニアからキャリアをスタートして、人材教育で550名以上のキャリア面談を経験し、今はCTO × 個人事業の複業スタイルで働いています。
バイブコーディングについて書こうと思ったのは、ネット上の記事がほとんど「解説」ばかりで、「実際にやった人の話」が少なかったからです。データや引用を並べるだけなら誰でもできる。でも「pgrepがmacOSで動かなくてハマった」「チャンネルIDハードコードして後悔した」みたいなリアルは、やった人にしか書けない。
この記事が、これからバイブコーディングを試す人の参考になれば嬉しいです。
まとめ — バイブコーディングは「使いこなす技術」になった
バイブコーディングは「雰囲気で伝えれば勝手にできる魔法」ではないです。でも、使いこなせば一人で100ファイルのシステムを3ヶ月で作れる。
大事なのは3つ:
- 設計を先にやる — いきなりコードを書かせない
- 制約をプロンプトに入れる — 過去の失敗を次のプロンプトに反映する
- レビューをサボらない — 「動いたからOK」は危険
まずは今抱えている小さなタスクを1つ、AIに投げてみてください。それがバイブコーディングの第一歩です。
もっと具体的な使い方を知りたい方は、ぜひXやブログのコメントで声をかけてください。一緒にAI時代の開発スタイルを探っていきましょう。
