2025年に入り、「Vibe Coding（バイブコーディング）」という言葉が急速に広まりました。生成AIに“雰囲気（バイブ）”で指示を出し、コードやUIを一気に立ち上げる。そんな体験に驚いた人も多いのではないでしょうか。一方で、「実務でどこまで通用するのか？」「レビューや設計のあり方はどう変わるのか？」といった疑問の声も数多く寄せられています。
今回は、2025年12月10日に開催されたオンラインイベント「Vibe Codingの一歩先へ〜 プロダクト開発でつまずきやすいポイントの乗り越え方」のアフタートークとして、江島 健太郎（@kenn）さんに改めてお話を伺いました。当日寄せられた質問をもとに、イベント本編では語りきれなかったVibe Codingの思想から実務での活用、AI時代のキャリアまでを掘り下げます。
本インタビューは、当日のイベントでもモデレーターを務めたFindyの北川が聞き手となりPodcastとしても配信しています。ぜひ合わせてご視聴ください。
【前編】Vibe CodingとAIエージェントは急接近している？ 〜Ejimaさんと語るイベントアフタートーク〜 | Voicy
※ 後編は近日中に公開予定です
Vibe Codingの思想と、進化する開発プロセス
―― まずは、Vibe Codingの思想や開発プロセス上の位置付けについて伺います。仕様駆動、モデル駆動、テスト駆動など様々な手法がある中で、Vibe Codingを含む生成AI活用の開発手法はどのように整理されますか？
古くからあるテスト駆動開発（TDD）に対して、AI時代になって目立ってきたものとしては、やはり「仕様駆動開発」だと思っています。
AIに実装計画を立てさせ、人間がレビューしてから実装に入る。このプロセスが実用レベルになったのは、AIの進化が大きな要因です。
それまでのCursor時代でもできなくはありませんでしたが、ハーネスが弱くて、プランの精度に課題がありました。それが、Claude CodeがClaude 4に対応した2025年5月くらいから、潮流が変わった感覚があります。
―― Claude Codeが登場したことで、Vibe CodingなどAIを用いた開発手法が確立し、変化していったイメージでしょうか。
そうですね。ただ、これもまだ発展途上です。一時期はMarkdownでルールを記述する手法が流行りましたが、現在はClaude以外のモデルでも、AIエージェントが確実に解釈できる業界共通のルールファイルとして「AGENTS.md」の標準化が進んでいます。
AGENTS.mdの面白いところは、サブフォルダに置いたものも含めて、ディレクトリ構造を遡る仕様です。「対象ファイルに最も近い階層のルールが優先される」という考え方は、単なるドキュメント管理を超えて、ハーネスや実装とセットで運用される新しい開発手法、という感じがしています。
Vibe CodingとAIエージェントコーディングは、すでに融合している
―― 「Vibe CodingとAIエージェントコーディングは対立するのか、補完関係なのか？」という質問もありました。
私の認識では、両者はすでに「急接近」していると思っています。
かつてのAIエージェントコーディングは「プロのエンジニアがAIを駆使して開発する」という文脈でしたよね。一方で、Vibe Codingは「エンジニアではない人がワンショットでプロトタイプを作る」という感覚で切り分けられていました。
しかし今は、プロのエンジニアこそ“Vibe”でコードを書いています。これが2025年後半に一気に加速した現象です。
例えば、仕様書を策定するプロセス。AIと対話しながら「これを見落としていた」「これもやろう」と叩き上げていく、このインタラクティブなプロセスそのものが、もはや“Vibe”なんですよね。かっちりとした仕様駆動開発とVibe Codingの境界が、徐々になくなっている感覚があります。
AIのメタ視点をどう補うか
―― 「AIはメタ視点が弱く、プロダクト全体を任せるのは難しいのではないか」という意見についてはどう思われますか？
「メタ視点」をどのレベルで捉えるかによりますが、アーキテクチャの骨格まで完全に任せると、いわゆる「フランケンシュタイン・アーキテクチャ」に陥るリスクがあります。技術スタックの選定など、上位の意思決定を人間が行わないと確かにうまくいきません。その意味では、メタ視点が弱いという指摘はその通りだと思います。
なぜメタ視点が弱いのかというと、AIは可能性空間を自由に探索するため、出発点（指示）が自由すぎると出力が散ってしまうからです。だからこそ、出力の方向性を絞るための「ガードレール」が必要になります。
もう1つ、「非機能要件」もポイントです。エンジニア職ではないバイブコーダーの方の場合、画面遷移のような「機能」は想像しやすいですが、クッキーの保持やセキュリティといった実装のディテールまではイメージしづらいですよね。そういったメタな意思決定は、依然として人間によるガイドが必要です。
―― AIがあらゆる可能性の中から最適な選択肢を提示してくれるわけではなく、やはりインプットによって変わるものということですね。
そうですね。重要なのは、AIのミスに人間が気づけるかどうかです。高度なディテールはわからなくても、「何を決めたか」という過去の意思決定を一定の粒度で記憶しておかないと、事故を招きます。
ただ、作るものや用途によってはAI任せでも実現できます。例えば、私が作っている「Gista.js」は必要なガードレールが最初から揃っているので、Webアプリを作るだけならばAIに任せても問題ありません。ただし、MVPを超えてスケールさせる段階は、さすがに人間の高度な視点が必要になると思います。
「動いた」で終わるか、「作れる」に進むか
―― AIコーディング初学者が有料環境を検討する場合、何から始めるべきでしょうか？
今はプロンプトを投げて「あ、動いた！楽しい！」というフェーズの方が多いかと思います。
そこから実際のプロダクト開発へ踏み出すなら、やはりIDE（統合開発環境）が欲しくなります。個人的には、ChatGPT PlusでCodex（GPT-5.2等）を使うか、AnthropicのClaude ProでClaude Codeを触ることをおすすめします。
初心者の方はCLIに壁を感じやすいので、まずはVS Codeの拡張機能を使ってGUIから入るのが良いでしょう。20ドル前後のサブスク範囲であれば、トークンを使いすぎる事故も起きにくいです。まずは、今使い慣れているツールで少し課金して触ってみるのが良いんじゃないでしょうか。
―― 関連して、「エンジニアではないのですが、Replitはどこまで使えるでしょうか？」という質問もあります。
「どこまで使えるか」というのは本質的な問いですね。確かにReplitは手軽なツールです。ただ以前、有名なポッドキャスターがReplitで構築・本番運用していたアプリにおいて、AIがデータベースを誤って消去した事故がありました。
本番運用を見据えるなら、早い段階でプロのエンジニアと同じ道具（IDE）に切り替えた方が良い、というのが私の考えです。
―― 初心者の場合「AIにすべて書かせる」のと「一部を自ら修正する」のは、どちらがおすすめでしょうか？
確かに最初は迷いますよね。人間は安きに流れるのでAIに任せたくなってしまうと思いますが、自分で書いた方が勉強になるのは間違いありません。ただ、「バイブコーディング・ネイティブ」の世代がどういう成長曲線を辿るのかは、まだ誰も知らないわけですよ。
私もまだわかりませんが、実は手で書く必要は全くなかった、という答えも全然あり得ると思っています。我々のようにゼロから書いてきた世代にはわかり得ない世界だとも感じています。最後は自分の心に聞いてみてください（笑）。何年後かに答え合わせしたいですね。
レビューは「AI対AI」の戦い
―― コードレビューの効率化や、AIへの頼み方のコツはありますか？
私のやり方は「AI対AIの戦い」です。
課金している前提になってしまいますが、Claude 4.5 Opusにコードを書かせ、それをGPT-5.2などのモデルにレビューさせています。Opusは実装が速いですが少し雑なところがあり、一方でGPTは非常に賢いけれど出力が遅いという特性があります。
Opusにさっと書かせ、GPTに「ここが間違っている」と突っ込みを入れさせ、それをOpusに伝えて直させる。この往復をひたすらやっています。これが現時点のベストプラクティスです。
―― モデルごとの特性や仕様は、どのようにキャッチアップしているんですか？
ドキュメントも見ますが、使っていれば動きでわかります。その中で「呼吸」をしていれば、身体的な感覚として理解できるようになってくると言いますか。毎日コードを書いている人とそうでない人とでは、「AIに対する直感力」に大きな差がついていると思います。こういったモデルの変化も含めて全部が「情報」なので、ぜひ毎日AIに触ってコードを書きましょう。
Gista.jsは、開発知識がない人のための発射台
―― ここからは、江島さんが作られた「Gista.js」についてお聞きします。エンジニア以外でもプロダクトが作れる環境とのことですが、既存の手法で作るアプリと違いはありますか？
違いはありません。知識がある人ならGistaは不要です。あくまで、開発の知識がない人が出発点として使うための「ちょうどいいスターターテンプレート」だと思ってください。カスタマイズは何でもできますし、コア部分はMITライセンスでオープンソースとして公開予定です。
―― React Router v7やDrizzle ORMを優先して採用した理由を教えてください。
一番良いものを選定した結果です。Next.jsはApp Routerになってから複雑になり、セキュリティ事故のリスクも増えています。それに対してReact Routerは非常にシンプルで、記述量も少なく間違いが起きにくい。エンジニアではない人が「型」などで挫折しないための選択です。
また、Drizzleに関しては私がJavaScript界のORMをずっと探していた中で、ようやく出会えた理想的なツールだからです。これをRuby on RailsのActiveRecord風にラップして搭載しています。ノイズのない、スリムでシンプルなコードであることを大事にしています。
AI時代のキャリア、エンジニアは「上のレイヤー」へ
―― 実装がAIによって自動化される中で、エンジニアはどうスキルアップすべきでしょうか？
実装が自動化されても、ビジネス要件を解釈し「AIに実装させる仕組み」を設計する人の需要は減りません。エンジニアはより上のレイヤー、つまりユーザーの言葉でビジネスを語り、AIと議論できる存在になる必要があります。
また、UIの作り込みには依然として無限に時間が溶けます。そのため、シリコンバレーでは最近「デザインエンジニア」という職種が生まれて価値が上がっています。ビジネス要件とビジュアルは不可分です。「上のレイヤー」を目指すなら、UIやデザインそのものもエンジニアの仕事に含めて捉えた方が良いと思います。
―― PdMのキャリアアップについてはどうですか？
シリコンバレーでは「テクニカルPM」がベースラインになりつつあります。「プロトタイプのコードくらいは自分で作る」スキルが求められています。最近のCursorではFigmaのように見た目そのままを直接コード化できるようになりましたが、これは「デザインをHTMLに落とす」のではなく、「いきなり動くコードを書く」というシフトを意味しています。PdMも、より開発環境やコードに近い部分に接して、AIを使いこなしていくのが良いですね。
―― 最後に、テクノロジーの民主化でエンジニアリングの価値は下がってしまうのでしょうか？
極めて厳しい、二極化の時代が来ると思います。AIを完璧に使いこなす側の価値はうなぎ上りですが、従来の受託的な開発をAIで少し加速させているだけでは、内製化の波にのまれてしまうでしょう。
しかし、このソフトウェア産業革命の真っただ中にいることはまたとないチャンスです。AIは誰も逃げられない、みんなに平等にやってきた脅威であり機会です。AIでの開発は、楽しいことしかありませんよ。
イベント本編のアーカイブ
イベント本編は、アーカイブ動画を公開しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。