AIで作る方法は2通り
いまAIで開発しているあらゆるチームを貫いて流れている、静かな議論があります。それはたいてい討論という形ではなく、議論ではなく“気持ち”として現れます。ある人は「こういうものが欲しい」と伝え、モデルの出力をそのまま受け入れて、午後のうちに動くアプリを出荷します。別の人はすべての行を読み、テストを書き、その仕組みを実際に理解しようとします。どちらも同じツールを使っています。違うのは、遊んでいるゲームがまったく別だという点だけです。
この2つのゲームには、もう名前があります。速くて緩い、説明して受け入れるスタイルは「バイブコーディング（vibe coding）」と呼ばれます。モデルの周りに信頼できるシステムを注意深く体系的に組み立てるほうは、「エージェント的エンジニアリング（agentic engineering）」に近い意味です。これを“戦い”と捉えたくなる気持ちはわかります。片方はスピード、もう片方は厳密さを掲げていて、どちらかの陣営に入るべきだ、という構図です。でもその捉え方は的外れです。彼らはライバルではありません。違うのは、違う局面で使うための別の道具であること、そして本当の技術は「今あなたが握っているのはどっちか」を知ることです。
この混乱は解消しておく価値があります。なぜなら賭け金が急速に上がっているからです。モデルからの強力な支援で書かれるソフトウェアがますます増えていき、その結果として人々が今身につける習慣が、そのソフトウェアが私たちが積み上げていけるものになるか、それとも誰も理解していないコードの山になるかを決めます。区別を正しく掴めば、AIは、捨て実験も本格的なシステムも、あらゆる面であなたを速くします。間違えれば、手当たり次第のプロトタイプをうろうろと掘って回るか、推測でつなぎ合わせた本番システムを出荷することになります。
この文章は、最初から最後まで全体を扱います。各モードは実際に何か、なぜバイブコーディングがあれほど魅力的なのか、どちらがどこで活きるのか、いまこの瞬間に見分ける方法、そして「あるタスクが求めているのはどっちか」を自分に嘘をつかずに、両方をどう使うか。途中で比較表、素早い意思決定チェック、いくつかの実際のシナリオ、そして保持しておける2つのチェックリストも用意します。
バイブコーディングとは何か
「バイブコーディング」という言葉は、Andrej Karpathy（アンドレイ・カーパシー）によるもので、モデルにどっぷり身を委ねる新しい働き方を説明しました。平易な言葉でモデルに話しかけ、その提案を細部に神経を使わずに受け入れ、そして多かれ少なかれ「そのコードが存在している」ということを忘れる、というやり方です。差分（diff）を読んでいるのではありません。あなたは“ノリ”に乗っているのです。
セッションが実際にどんな見た目になるか、想像してみると役に立ちます。チャットやエージェントを開き、作りたいものを説明するとコードが出てきます。動かします。何かおかしいのでエラーを貼り付けて修正を頼むと、新しいコードが出てきます。細かく読むことはしないでしょう。もしかするとまったくしないかもしれません。もう一度動かします。うまくいく、あるいは十分にうまくいって次に進み、次の機能でも同じことを繰り返します。ループは速く、ほとんど会話のようで、いずれの時点でも、どの部分がどう噛み合っているのかを頭のモデルとして組み上げるために立ち止まることはありません。モデルがそれを担保している、あるいはより正確に言えば、誰もそんなモデルを持っていないだけです。
これをやったことがある人なら、なぜこれが広まったのかわかります。これは本当に楽しいのです。思考の速度で進められ、アイデアと動くプロトタイプのあいだにある“摩擦”はほとんど消えます。そして、自分で手作業では決して我慢して作れなかったようなものも作れるようになります。スクリプトを書くのもやっとだった人が、今では動くWebアプリを立ち上げられます。経験あるエンジニアは、以前は1つ準備するのに使っていた時間の間に、5つのアプローチを探索できます。週末プロジェクト、すぐ終わる実験、あるいはあなたしか触れないツールにとっては、ほぼスーパーパワーのように感じられ、実際そうでもあります。
ただし決定的な特徴はスピードではありません。降伏です。バイブコーディングでは、入力（タイピング）だけでなく理解まで手放します。コードが動くように見えるから、動くと信じるのであって、どう動いているかは特に気にしません。その取引が、まさに速さを生む理由であり、同時にトラブルの始まりがここでもある理由でもあります。この「降伏」という言葉を忘れないでください。バイブコーディングの良い点も悪い点も、ほぼすべてがここから派生します。
なぜこんなに気持ちがいいのか
バイブコーディングがどこで破綻するかに入る前に、なぜこれに陥るのかを真剣に考える価値があります。実力のある人が多くここに引き込まれてしまうのは、引力が本物だからです。そうでないふりをしても無駄です。
第一の理由は単純にスピードです。スピードは中毒性があります。「こんなものが欲しい」と言って、ほんの少し後にはそれが存在するのを見る喜びは格別で、しかもそれは、最初にこの仕事を楽しく感じさせたのと同じ“かゆみ”を掻きます。手作業でコードを書くのは、いつも長い摩擦の時間があるものです。ボイラープレート、設定、何百回も使ってきたインターフェースを探すこと。バイブコーディングはそれをほぼゼロに圧縮し、摩擦がない感覚は飛ぶように感じられます。
第二の理由はフィードバックループです。小さな要求ごとに、目に見える結果がすぐ出てくる。速い“見える”結果は、脳が得られる最も強い強化のひとつです。ゲームを作るときも強いのと同じループですし、強迫的なものを食べさせるループでもあります。あなたが聞く、返ってくる、また聞く、そして1時間が消える。そのループが気持ちいいので、コードを読むために止まるのは、良いランを中断してフォームを確認するような“中断”に感じてしまいます。
第三の理由はデモです。ソフトウェアにかかるプレッシャーの大部分は「進捗を見せること」です。そしてバイブで作ったプロトタイプは、進捗を美しく見せてしまいます。完成して見えます。クリックして反応し、会議で人を感心させる。外からは「見た目が完成している状態」と「本当に完成している状態」のギャップが見えず、見えない問題は緊急性を生みません。その結果、見た目が済んでいるものが静かにインセンティブで報われ、健全性があるものよりもそちらにチームが流れていくのです。誰かが明確に判断していなくても、自然にバイブコーディングへドリフトします。
これらはどれも性格の欠陥ではありません。現実のインセンティブに対する合理的な反応であり、そもそも本当に良い体験です。命名することでそれを“上に見てやろう”とするのが目的ではありません。引力に気づくことで、抵抗するべきタイミングを決めるためです。検討したことのない“気持ち”に運ばれてしまわないようにするためです。
エージェント的エンジニアリングとは何か
エージェント的エンジニアリングはもう一つの姿勢です。これもAIに大きく依存しますし、バイブコーディングよりも依存することが多いです。なぜなら、モデルを“行動を自分で起こす”実際のシステムの内部に入れるからです。違いは、どれだけAIを使うかではありません。AIが出してくるものを、どれだけ自分の手綱で制御し続けるかです。
エンジニアは、モデルの出力を“慎重なレビュアーが自信満々なジュニアのプルリクエストに向き合うときのように”扱います。仕事そのものはすばらしいかもしれない。でもそれは検討されるべきドラフトであって、受け入れるべき真実ではありません。実際には、それがいくつかの具体的な習慣に落ちていきます。必要なのはテストです。あなたが気にしている振る舞いが固定され、将来の変更がそれをこっそり壊せないようにするためです。次に「システムが何をしたのか、なぜそうしたのか」を見られる方法があることです。何かが壊れたときに推測ではなく追跡できるようにするためです。さらに、システムが触れられる範囲に制限があり、何か高価だったり取り返しがつかなかったりする前に人間が明確にサインオフするポイントがあること。自律エージェントを扱うなら、評価（evals）や、全体が“重要なケースで”ちゃんと仕事をしているかを確かめる再現可能なテストが加わります。デモで一度うまくいったエージェントは、それが本当に動くかどうかをほとんど教えてくれないからです。
そして何よりも理解があります。誰かがその仕組みを知っていて、壊れたら直せる。端の挙動について推論できる。なぜその形で作られているのかを同僚に説明できる。理解は、それ自体が成果物として扱われます。実行中のコードのように、作業の一部として同じくらい重要です。誰も理解していないシステムは、すでに失敗しているシステムだからです。まだ“気づかれていない”だけです。
もしバイブコーディングが“ノリに身を任せる”ことだとしたら、エンジニアリングは“それを拒む”ことです。バイブコーディングが捨ててしまう習慣のうち唯一のものを保持します。信じる前に検証し理解する、という習慣です。たったそれだけの習慣が、違いのすべてであり、真正面から見ておく価値があります。
二択ではなくスペクトラム（連続体）
これ以上進む前に、「選択肢は2つしかない」という考えを捨てると助けになります。バイブコーディングと完全なエンジニアリングは、範囲の両端です。そして、実際のほとんどの仕事はそのどこかにいます。
