「どのAIがいいですか」は、3番目の質問です──バイブコーディングは、AI選びの前に順番がある

「バイブコーディングを始めたいんですが、おすすめの AI とエディタは何ですか？」

よく聞かれます。そして毎回、答える前に一度立ち止まります。その質問は、順番としては 3 番目だからです。

意地悪で言っているのではありません。先に決めるべきことを決めないままツールを選ぶと、どのツールを選んでも同じところで詰まるからです。

この記事では、なぜそう言えるのかを、実際に起きたことを材料に説明します。

※ お断り：当ブログでは普段 Claude を推奨しています。以下でその Claude の評判が悪かった時期の話をしますが、都合よく書かないよう気をつけました。

思い出してほしいこと:あの時期も、作れる人は作れていた

2026 年の前半、Claude Opus 4.8 の評判が、かなり荒れた時期がありました。

「冷たい」「うっとうしい」「説教くさい」。以前の Claude が「ノリのいい相棒」だったのに対して「少し厳しめの同僚」になった、という評され方をしていました。

これは印象論だけではありません。Anthropic 自身のシステムカードにも、リリース前の試用フィードバックとして次のような報告が記載されていました。

事実主張に対する過度な議論好き
対話型のエージェント作業で、不要な追加質問をして手を止める傾向
なぜかユーザーに寝るよう促す、奇妙な反復例

さらに 6 月には、Fable / Mythos の提供停止のあと「性能が落ちたのではないか」という声が広がりました。ある技術者は、この「劣化疑惑」を検証する記事を書いています。その結論は慎重で、API のモデル ID を明示している限り重みは固定されるが、リクエストの振り分けや安全機構といった提供側の仕組みは変わりうる——つまり「本当に劣化したのか」を確かめること自体が難しい、というものでした。

ここまでが、荒れていた側の話です。

でも、同じ時期の評価は、正反対にも割れていた

一方で、まったく同じ Opus 4.8 について、こういう評価も出ていました。

指標	結果
SWE-bench Verified	88.6%
SWE-bench Pro	64.3% → 69.2%（エージェント型コーディングの完走率）
GPT-5.5 との比較	13 指標中 12 で勝利（負けたのはターミナル操作のみ）
知識労働スコア	1753 → 1890

実際に使った人からは「一つのプロンプトでフィールド探索・バトル・捕獲まで実装してしまうのは率直に驚いた」「コーディングの精度と完成度は明らかに頭一つ抜けている」という評価も出ています。

つまり——

同じモデルを、同じ時期に使っていた人たちの評価が、正反対に割れていた。

そして重要なのは、この時期も、作れる人はちゃんと作れていたということです。「劣化した」と言われていた最中に、動くものを次々に出していた人がいる。

もしモデルの性能が成否を決めているなら、評価はここまで割れません。

割れるということは、変数がモデル側にないということです。

では、変数はどこにあるのか

答えは、複数の場所で独立に、ほぼ同じ形で出ています。

バイブコーディングの入門記事を書いている会社は、失敗の原因をこう分析しています。

失敗の原因は「要件定義不足」「情報管理ミス」「運用ルール不在」に集約されます。バイブコーディングは速い分、間違った方向にも速く進みます。

そして、始め方についてはこう書いています。

始め方で決めるべきは「目的」「対象業務」「成功条件」「禁止事項」の 4 点です。 ツール選定や実装はその後で問題ありません。

別の技術者は、AI 時代の要件定義を論じるなかで、こう整理しています。

コンテキスト工学に投資しても、そもそもの要件が曖昧なら、AI の出力品質は上がらない（Garbage In, Garbage Out）。

どれも、モデルの話をしていません。 全部、渡す側の話です。

これはワールドの記事で書いた「AI が期待外れになる理由の多くは、モデルの性能ではなく、人間側が判断基準を言葉にしていないこと」と、まったく同じ構図です。

正しい順番は、こうなります

順番	やること	決まらないと
①	要件定義——何を作るのか、何を作らないのか	AI がどこへ向かえばいいか分からない
②	技術選定——どこに置き、何で作るのか	作った後に置き場所がなくて詰まる
③	AI・エディタ選び	——（①② が決まっていれば、ここの差は小さい）

順に見ていきます。

① 要件定義:バイブコーディングでこそ、要る

「バイブコーディングは、ざっくり指示して作らせるものでしょう。要件定義なんて、それこそ古い開発のやり方では？」

そう思われるかもしれません。逆です。 バイブコーディングだからこそ、ここが効きます。

理由は、さっき引用した一行に尽きます。

バイブコーディングは速い分、間違った方向にも速く進みます。

手で書いていた頃は、間違った方向に進むにも時間がかかりました。だから途中で気づけた。AI は、間違った方向に、猛烈な速度で完成させます。 そして「動くもの」ができてしまうので、間違いに気づきにくい。

最低限、決めておく 4 つ

難しく考える必要はありません。この 4 つを、文章で書くだけです。

1. 目的——誰の、何の時間を減らすのか。一文で書けるか 2. 対象業務——どの業務の、どこからどこまでか 3. 成功条件——何ができていれば「完成」なのか 4. 禁止事項——やらないこと。ここがいちばん抜けます

4 番目を強調するのには理由があります。費用の記事で書いた通り、例外を全部拾おうとすると手間は倍以上になります。「これはやらない」を先に決めておかないと、AI は律儀に全部作ろうとします。

要件定義書は「資産」になる

もう一つ、実務上の大きな利点があります。

小規模アプリでバイブコーディングを試した技術者が、こう書いています。

要件定義書があるため、それを AI に再入力することでアプリケーション全体を一から再生成できるようになりました。要件定義書を修正してアプリケーションを作り直すことで仕様変更に対応でき、対応時間が大幅に短縮されました。

これは重要な発見だと思います。**AI に作らせる時代の要件定義書は、書類ではなく「設計図兼・再生成の種」**です。

コードは AI が何度でも書き直せる。書き直せないのは、何を作りたいかの定義のほうです。

そして——Git の記事で「変更の履歴を残す」と書きましたが、いちばん履歴を残すべきなのは、この要件定義書かもしれません。

② 技術選定:要件が決まって、初めてできる

要件が決まったら、次は「どこに置き、何で作るか」です。

この順番でないと成立しません。 なぜなら、技術の選択肢は要件によって絞られるからです。

社内 30 人が使うのか、社外の不特定多数が使うのか
データはどれくらいの量になるのか
止まったら業務が止まるのか、止まっても困らないのか
既存システムと繋ぐ必要があるのか

これが決まっていない状態で「何で作りますか」を聞かれても、答えようがありません。

プロトタイプの「錯覚」に注意

ここで、見落とされがちな落とし穴があります。あるコンサルティング会社が的確に指摘しています。

バイブコーディングで作るプロトタイプは、手元の環境や少量のダミーデータで動かすため、非常に軽快に動作します。この「サクサク」とした快適な体験により、本番環境でもこのスピードで動くのが当然だと錯覚しがちです。その結果、応答速度や同時アクセス数、データ容量といった「非機能要件」の定義を疎かにしてしまう危険性があります。

手元で 10 件のデータを扱うのと、本番で 10 万件を扱うのは、まったく別の設計です。「動いた」と「使える」の間には、この差があります。

なお、私たちが業務アプリで何を選んでいるかは、別記事にまとめています。

▶ 業務アプリを作るなら、まず Cloudflare と D1 を検討してほしい サーバー管理が発生しない、起動待ちがない、必要なものが 1 か所に揃う——選定の理由と、他の選択肢との比較。

そして正直に言うと、私たちも一度ここで失敗しています。AI の言うとおりに置き場所を決めて、翌月に請求が来ました。その話も上の記事に書いてあります。

③ AI・エディタ選び:ここで、ようやく

そして 3 番目です。

「じゃあ AI は何でもいいのか」——そうは言いません。 実際、当ブログは Claude を推奨していますし、上位モデルと中堅モデルには明確な差があるとも書きました。

ただし、それは順番の話です。

①② が決まっていれば、どの主要モデルでも、だいたい形になる
①② が決まっていなければ、どのモデルを使っても、同じところで詰まる

エディタも同じです。VS Code でも、他のものでも構いません。非エンジニア向けの記事で VS Code を勧めたのは、コードを書くためではなく「ファイルとテキストを扱う一枚の窓」としてでした。

道具の差が効いてくるのは、①② を通過した後です。そこまで来れば、モデルの違いは体感できます。逆に言えば、そこまで来ていない段階でモデルを比べても、何を比べているのか自分でも分からないはずです。

最初の 30 分で、やること

具体的にどうするか。コードを書き始める前の 30 分を、こう使ってください。

1.（10 分）4 つを文章で書く 目的・対象業務・成功条件・禁止事項。テキストファイル 1 枚で構いません。

2.（10 分）AI に読ませて、質問させる

「この要件定義を読んで、作る前に確認すべき曖昧な点を挙げて。実装はまだしないで」

これが効きます。AI は、こちらが気づいていない穴を指摘してきます。その質問に答えていく作業が、要件定義そのものです。

3.（5 分）技術選定を相談する

「この要件なら、どこに置いて何で作るのが適切か。選択肢を 3 つ、理由と費用の目安つきで」

ここでも、出てきた答えをそのまま採用しない。料金体系は変わりますし、AI の知識は古いことがあります。

4.（5 分）要件定義書をファイルとして保存する

そして、この 1 枚をGit で管理してください。コードより、こちらのほうが失いたくない資産です。

まとめ

「おすすめの AI とエディタは？」は、順番としては 3 番目の質問
Claude Opus 4.8 の評判が荒れていた時期も、作れる人はちゃんと作れていた。そして同じモデル・同じ時期に、評価は正反対に割れていた
もしモデルが成否を決めているなら、評価はここまで割れない。割れるということは、変数がモデル側にないということ
各社の失敗分析も、独立に同じ結論に至っている。失敗の原因は要件定義不足に集約され、ツール選定はその後でいい
順番は ① 要件定義 → ② 技術選定 → ③ AI・エディタ選び
要件定義で決めるのは 目的・対象業務・成功条件・禁止事項の 4 つ。特に禁止事項が抜けやすい
要件定義書は書類ではなく再生成の種。コードは AI が何度でも書き直せるが、何を作りたいかの定義は書き直せない
①② が決まっていれば、③ の差は小さい。決まっていなければ、どのモデルでも同じところで詰まる

バイブコーディングは速い。だから、向かう方向を先に決めてください。 速く走れる道具を手に入れたときにいちばん大事なのは、走る速さではなく、行き先です。

Acetyl:Tech は、この ① と ② ——何を作るかの整理と、どこに置くかの選定——から支援しています。 「社内で作り始めたが、このまま進めていいか分からない」というご相談も承ります。詳しくは「業務アプリ開発」のページをご覧ください。