「LLMに仕様を投げたらCRUDまでは一瞬で出てくる。でも“この会社っぽさ”“このプロダクトらしさ”を反映させようとした瞬間、結局自分で全部やり直してないですか？」
自分もここ1〜2年、AI補完を本番導入してきましたが、
- コードはそれなりに出てくる
- でも「うちのドメイン」「チームの文脈」「プロダクトのVibe」が乗らない
このギャップに何度もイラついてきました。
そんな中で出てきたのが、今回の
「AI駆動開発・Vibeコーディング論考（note版＋生データ版）」。
一言でいうと、
「AIコーディング界の“Kubernetes への移行宣言”」だと感じています。
Docker黎明期は「既存アプリをコンテナに詰める」フェーズでしたよね。
今、LLMでやっているのもそれに近い。「既存OSSの断片をAIでうまくパッケージする」。
この論考が言っているのは、そうじゃなくて、
「ビジネスドメインや組織の文脈そのものを“世界(World)”としてAIにモデリングさせる時代に移ろうぜ」という話です。
一言でいうと：AIコーディング界の「SaaS化宣言」だと思う
論考が主張しているシフトを、ものすごく乱暴にまとめるとこうです。
- これまで
→ OSSコードの“上澄み”を統計的にサンプリングして補完するAIコーディング - これから
→ 業務ドメインや組織の政治、人の価値観まで含めた“世界モデル”をAIが組み上げ、その一部としてコードが生まれる時代
この変化は、
- 「インフラ自前構築 → クラウド」よりも、
- 「オンプレ製品 → SaaSプラットフォーム」
への移行に近い感触があります。
クラウドは「ハードを買わない」で済んだだけでしたが、
SaaSは「業務そのものの標準形」を提案してくる。
今回のVibeコーディング論は、
「コードはあくまで世界モデルの一部であって、主役は“世界解析”だ」と開き直ったところが新しい。
Vibeコーディングって何者？「空気」がAPIになる時代
この論考のキーワードが 「Vibeコーディング」。
単に「自然言語で指示してコードを書かせる」のとはだいぶ違います。
ざっくり定義すると、
ユーザが持っている
- 事業ドメインのニュアンス
- 組織特有の空気・政治
- プロダクトの価値観やトーン
を、プロンプトやドキュメントを通じてLLMに流し込み、
AI側が“世界モデル”として解釈したうえで、仕様・設計・コードを一体で反復生成していくスタイル
ポイントは2つ。
- 「仕様が先、実装が後」という前提を壊している
- 完成された仕様書を渡して実装させるのではなく、
仕様そのものをAIとの対話の中で揺らしながら決めていく。 -
つまり「仕様・設計・実装」が1つの会話空間に溶ける。
-
開発者の役割が“世界の解像度を上げる人”に変わる
- if文やfor文を書く人ではなく、
- 「この組織は何を怖がっているのか」「この事業で絶対にぶれてはいけない価値は何か」
をAIに伝え、矛盾をチェックし、誘導する人になる。
正直、これを初めて読んだ時、
「Vibeなんてふわっとした言葉を、ここまでガチの設計思想の中心に据えるのか」と半分引きました😅
でも、現場でLLMを本気で回し始めると、
いちばんAIにうまく伝わらないのが、この“Vibe”の部分なんですよね。
- 「うちはB2Cだけど“金融っぽい信頼感”をすごく大事にしている」
- 「法務との関係上、この種のログは絶対に消しちゃいけない」
- 「この部署はSaaS風のUIを嫌うから、Excelっぽい表現にしてほしい」
こういう “言語化しづらい前提” が抜けていると、
出てくるコードや仕様は技術的には正しいけど、組織的には即ボツになります。
Vibeコーディングは、そこをあえて「主要な設計要素」として前面に出した点が、かなりラディカルです。
競合は誰か？Copilot型ツールとの差分を冷静に見る
じゃあ、この「世界解析＆Vibeコーディング」の発想は、
いまのAIツールと比べて何がそんなに違うのか。
GitHub Copilot 的「コード補完屋」との差
Copilot系は、
- 行・ブロック単位の補完
- 既存OSSのパターンをなぞる実装
に最適化されたツールです。
これはこれでめちゃくちゃ役に立つし、
「既知パターンを高速になぞる」という意味では、まだ当分主役級です。
でも論考が言っているのは、
「そこにAIを閉じ込めておくのは、もったいなさすぎる」という話。
- ビジネスドメイン
- 非機能要件
- 組織図や稟議プロセス
まで含めて、AIが一つの世界モデルとして頭に入れたとき、
そこから逆算されるアーキテクチャや仕様は、単なるOSSの平均ではなくなります。
正直、
「Copilotでコードが早く書ける」だけのチームは、数年後コモディティ化すると思っています。
一方で、
「自分たちの世界観をAIにうまく流し込んで、仕様〜実装を一気通貫で誘導できる人」は、かなりレアなスキルになります。
LangChain 的「パイプライン定義ツール」との緊張関係
もう1つ、論考と対照的なのが
固定フロー前提のLLMフレームワークです。
- よくある構成:
- 「ユーザ入力 → RAG → 要約 → 出力」みたいなチェーンをコードで定義
- 開発者がプロセスのグラフを設計して、LLMはノードの一部として使う
これの限界は、
「世界モデルそのものは人間が頭の外で考える前提」に立っていることです。
Vibeコーディング的な発想は真逆で、
- プロセス（チェーン）の設計自体を
- AIとの対話の中で揺らし、再構成していく
つまり、
「LLMパイプラインを人間が事前に全部決め打ちする」というスタイル自体が、ニッチ化していくという見立てです。
この点については、正直かなり同意しています。
現場でLLMプロダクトを作ると、
- 最初に考えたRAG構成が
- ユーザの使い方やドキュメントの増加に従って、どんどん前提崩壊していく
というのが日常茶飯事です。
そのたびに、
- パイプライン用のコードを書き換えて
- デプロイして
- 影響範囲をテストして
…というのは、もはややっていられない。
「パイプラインをどう分解するか」も含めてAIに議論させる、という方向性は、
開発者の精神衛生的にも正しい進化だと思っています。
なぜ「他職種への汎化」がヤバいのか
論考が鋭いのは、「これはエンジニアだけの話じゃない」と明言しているところです。
PM / PdM / デザイナーにとってのVibeコーディング
- 要件定義
- ユーザストーリーマッピング
- UXリサーチのサマリ
- 競合分析スライド
こういった「文章に落ちきらないニュアンスの翻訳作業」は、
まさにVibeそのものです。
ここにAIが入るとどうなるか。
- PMは、
- 市場環境
- 社内政治
-
経営層の好み
をAIに流し込みながら、仕様案を何十パターンも生成して比較できる。 -
デザイナーは、
- 既存UI
- ブランドガイドライン
- 過去の炎上事例
をコンテキストに入れたうえで、UI案を「Vibe付き」で出力させられる。
要するに、
「AIと一緒に世界モデルを書き換えながらアウトプットを作る」というワークスタイルは、
エンジニアリングに閉じない、職種横断の基本スキルになりうる、という話です。
ぶっちゃけ、
「AIに自分のVibeを説明できないマネージャー」は、数年後かなり厳しいと感じています。
今まで
- 「なんか違うんだよな〜」
という謎フィードバックだけで済んでいた人たちは、
AI相手にはその“なんか”を言語化しない限り、進捗ゼロです。
ただし、落とし穴もデカい：世界解析はコスト地獄になり得る
ここまでべた褒めに近いことを書きましたが、
論考もちゃんと指摘しているように、懸念は相当あります。
世界解析コストがバカにならない
- 長文コンテキスト対応のLLMに
- 仕様書
- 議事録
- ナレッジWiki
-
過去の障害報告
を全部突っ込もうとすると、APIコストは即死レベルになります。 -
さらに、人間側も
- 「うちのカルチャーはこうで…」
- 「この部署はこういう歴史があって…」
みたいな暗黙知を文章化する時間が必要。
正直、
「AIにVibeを教える時間 ≥ 自分で書き直したほうが早い時間」
というケースは、まだまだ多いです。
ここをどうチューニングするか（どこまで世界モデルをリッチにするか）は、
実務上のかなり大きな設計ポイントになります。
一貫性管理という新しい地獄
Vibeコーディングの本質は
「AIとの対話で世界モデルを更新し続けること」ですが、
これ、やればやるほど前提のバージョン管理がカオスになります。
- 2週間前のスレッドで決めた設計思想と
- 昨日の議事録で覆った方針と
- 今日のチャットで出てきた例外ルール
これらがどこでどう矛盾しているのか、
Chatログに埋まったままになると、かなり危険です。
専用の
- 「世界モデル定義ドキュメント」
- 「前提変更ログ」
を整備しない限り、
人間とAIの間で前提ズレが雪だるま式に溜まるという懸念があります。
ベンダーロックイン & ブラックボックス
世界解析レベルでまともに使えるLLMは、
現状どうしても巨大ベンダー製に集中せざるを得ません。
そうすると、
- あるLLMベンダー上で
- 自社の世界モデル
- Vibe
を長期間かけて“育てる”ことになる - 別ベンダーに乗り換えようとすると
→ 「Vibeの再学習コスト」が想像以上に重い
API料金や利用規約が変わったとき、
「自分たちの“世界”を握られている」感覚は、今よりずっと強くなるはずです。
説明責任の所在があいまいになる問題
「AIがこう提案したから、この仕様にしました」
という意思決定が増えていくと、
- 失敗したとき誰が責任をとるのか
- どの前提に基づいて、その案が妥当と判断されたのか
が見えづらくなります。
- 世界モデルのオーナーは誰か？
- AIの提案を最終承認する権限者は誰か？
- その判断プロセスをどうログに残すか？
ここを設計しないままVibeコーディングをやると、
「意思決定のブラックボックス化」という新しい炎上リスクを抱えることになります。
プロダクションでガンガン使うか？自分の結論
じゃあ、
「今すぐVibeコーディングを前提にプロダクション開発を全部組み替えるか？」
と聞かれたら、
正直、まだ様子見寄りです。
理由は3つ。
- 世界解析コストの最適点が、現場ごとに違いすぎる
- スタートアップで
- ドキュメントもカルチャーもまだ柔らかい組織
なら、「最初からAI前提の世界モデル設計」はアリ。
- ドキュメントもカルチャーもまだ柔らかい組織
-
一方、大企業のレガシーSI案件で
- 山ほどExcel要件定義がある世界
では、世界解析にかけるコストが現実的じゃないケースも多い。
- 山ほどExcel要件定義がある世界
-
ツール側の“世界モデル可視化”サポートがまだ薄い
- 現状のチャットUIやNotebook UIは、
「世界モデルの変更履歴を扱う」には貧弱です。 -
ここがプロダクトとして整ってこないと、
大規模組織での採用は難しい。 -
組織文化が追いついていない
- 「AIにVibeを説明できるマネージャー」
- 「仕様・設計・実装を行き来してAIをハンドリングできるエンジニア」
が揃っていないチームで無理に導入すると、
ただの高価なオモチャで終わるリスクが高い。
それでも「世界解析」という物差しは、今から持っておくべき
とはいえ、
この論考が提示している 「OSS依存 → 世界解析」 という視点は、
今すぐにでも頭の中の物差しとして持っておく価値があると思っています。
自分が現場で意識しているのは、こんな感じです👇
- 「この作業は、
- OSSパターンをなぞるだけか？
- それとも“うちの世界”を理解しないとできないか？」を切り分ける
- 前者は積極的にCopilot等に吐き出させて捨てる
- 後者については、
- AIに世界観をどこまで渡すか
- どのレベルまで一緒に設計させるか
をプロジェクトごとに実験する
そして、プロンプトを書くときにも
- 「要件」だけでなく
- 「このプロジェクトのVibe（大事にしている価値観・タブー）」
を1〜2行でもいいから、必ず添えるようにしています。
例:
- このプロジェクトは、SaaSだが“銀行窓口のような安心感”を重視している
- ユーザはITリテラシー低めの中小企業オーナーが中心
- 法務部門がログ削除を極度に嫌う文化がある
たったこれだけでも、
AIのアウトプットの方向性は明らかに変わるので、
「Vibeを仕様の一部として書き始める」練習にはちょうどいいです。
まとめ：AIと一緒に「世界」を設計できる人が、次の主役になる
この「AI駆動開発・Vibeコーディング論考」は、
新しいAPIやツールの紹介ではなく、
AIコーディングの主役は、
「OSSコード」ではなく「世界モデル」であるべきだ
という、ある種の思想宣言だと受け取りました。
- コードだけ書けるエンジニア
→ ますますAIと競合する領域 - 世界の構造をモデリングし、VibeをAIに翻訳できる人
→ AI時代の「設計者」「ハブ」として価値が上がる領域
ぶっちゃけ、
「AIをただのオートコンプリートとしてIDEの端っこに追いやる設計」をしているプロダクトや組織は、
このままだと数年後に厳しいポジションに追い込まれると思います。
一方で、
- チャットUI
- Notebook系ツール
- ナレッジベース
を使って、自分たちの世界をAIにどう語るかを今から試しているチームは、
たとえ技術スタックが多少古くても、長期的にはかなり有利になるはずです。
プロダクションで全面採用するのは「まだ様子見」。
でも、
「世界解析」というレンズと、「Vibeも仕様の一部だ」という感覚は、今すぐ武器にしておくべき。
自分はそう判断しています。
コメント