SIerがバイブコーディングを「導入できない」本当の理由
# SIerがバイブコーディングを「導入できない」本当の理由
「バイブコーディングをやってみたいんですが、うちの現場では無理で…」
SIerの開発現場で働く人たちと話すと、こういった声をよく聞く。興味はある。試したこともある。でも、プロジェクトに本格導入するには至らない。
技術的な問題ではない。多くの場合、その理由はもっと構造的なところにある。
バイブコーディングとは何か（改めて整理する）
バイブコーディングとは、AIに自然言語で指示を与えながら、コードの詳細をAIに委ねて進める開発スタイルだ。「こういう感じのものを作って」という曖昧な指示でも、AIが補完してコードを生成する。
スタートアップや個人開発者の間では広まっており、プロトタイプを数時間で作れるようになったという話も珍しくない。
一方でSIerの現場では、同じ手法がなかなか定着しない。なぜか。
理由1：固定価格契約と仕様書の呪縛
SIerのプロジェクトの多くは、固定価格・固定スコープの契約形態をとる。
顧客と合意した仕様書があり、その仕様書に基づいて成果物を納品する。追加変更があれば変更管理プロセスが走り、コストと工期が見直される。
バイブコーディングは、この仕組みと根本的に相性が悪い。
なぜなら、バイブコーディングでは「正確に何を作るか」をAIと対話しながら決めていく。つまり、仕様が後から確定する。固定価格契約では、仕様が先に確定していなければ見積もりができない。
「AIと話しながら要件を詰めていくプ ロセス」は、顧客との契約構造と衝突する。変更のたびに追加費用が発生するか、仕様の解釈で揉めるか、どちらかになりやすい。
理由2：品質保証の証跡問題
SIerのプロジェクトでは、品質管理の観点から設計書・テスト仕様書・レビュー記録が求められることが多い。
金融・製造・公共系の案件では、第三者監査やシステム監査に耐えられる証跡が必要だ。「AIが生成したコードを動かしてみたら動いた」は、証跡にならない。
バイブコーディングの快適さの一つは、細かいドキュメントを書かなくていいことだ。しかしSIerの現場では、ドキュメントを省略することが契約違反や監査指摘につながるリスクがある。
理由3：多重請負構造とコードの所有権
SIerのプロジェクトは、多くの場合多層の請負構造を持つ。元請けがあり、一次請けがあり、実際の開発は二次・三次請けが担うことも珍しくない。
この構造では、誰がどのコードに責任を持つかが明確である必要がある。バイブコーディングで生成されたコードは、その生成過程が不透明になりやすく、どの人間が設計判断をしたのかが追跡しにくい。
下請け企業がAIで生成したコードを 、元請け企業がレビューする体制があるかどうか。品質の最終責任がどこにあるのか。こういった問いへの答えが、まだ業界として整備されていない。
理由4：人月ビジネスモデルとの矛盾
もう一つ、見えにくい構造的問題がある。
SIerのビジネスモデルの多くは、人月単価で収益を立てている。工数が多いほど売上が増える仕組みだ。
バイブコーディングで開発効率が劇的に上がると、同じ成果物を作るのに必要な工数が減る。これは顧客にとっては良いことだが、受注者にとっては収益減を意味する。
契約構造が人月ベースである限り、AI活用による効率化は「自社の首を絞める」側面がある。この矛盾を解消しないままバイブコーディングを推進しても、現場レベルでの抵抗は避けられない。
問題の本質：「仕様」という基盤の欠如
ここまで4つの理由を挙げたが、共通しているのは一点だ。
バイブコーディングは「仕様が曖昧でも動くもの」を前提にしている。しかしSIerの現場は「仕様が明確であること」を前提に設計されている。
この前提の違いが、すべての摩擦の源泉だ。
バイブコーディングが個人開発やスタートアップで有効なのは、作る人と使う人が近く、仕様の変更に対して柔軟に対応できるからだ。SIerの多重請負・固定価格・監査要件という環境は、それとは真逆の条件が揃っている。
仕様駆動開発（SDD）が架け橋になる
では、SIerはAI活用を諦めるべきなのか。そうではない。
ここで有力な選択肢になるのが仕様駆動開発（SDD）だ。
SDDの基本的な考え方は、「AIが理解できる形式で仕様を記述し、その仕様からAIにコードを生成させる」というものだ。
バイブコーディングとの違いは明確だ。
| バイブコーディング | 仕様駆動開発（SDD） | |
|---|---|---|
| 仕様の扱い | 曖昧なまま進む | 先に構造化して固める |
| AIへの指示 | 自然言語・感覚的 | 構造化仕様を渡す |
| 成果物の証跡 | 残りにくい | 仕様書として残る |
| 変更管理 | 後追いが難しい | 仕様の差分として管理できる |
| 契約との相性 | 低い（固定価格と衝突） | 高い（仕様書ベースの契約と整合） |
SDDは「AIを使いたいがドキュメントは捨てられない」というSIerのジレンマに、一つの現実的な答えを提供する。
SIerにとってのAI活用の正しい入口
バイブコーディングが「コードを書くプロセス」をAI化するものだとすれば、SDDは「仕様を整理するプロセス」からAI化を始める。
SIerにとってより自然な入口は後者だ。
- 要件定義フェーズでAIに仕様の矛盾を検出させる
- 設計ドキュメントをAI が読める形式に変換する
- 仕様から自動的にテストケースを生成する
これらはどれも、現行の契約構造・品質管理プロセス・多重請負体制の中に組み込める。
バイブコーディングの「感覚的なコーディング体験」は、SIerの現場と馴染みが悪い。しかし「仕様を起点にAIを活用する」という発想は、SIer文化と相性が良い。
まとめ
SIerがバイブコーディングを導入できないのは、エンジニアの保守性の問題でも、経営者の理解不足の問題でもない。
契約・品質・多重請負・ビジネスモデルという構造的な問題だ。
この構造に向き合わずにバイブコーディングを推進しても、現場の混乱を招くだけになる。
一方で、仕様書を起点としたAI活用（SDD）は、この構造の中で実装可能だ。SIerのAI活用は、上流から始めるのが現実的な選択だ。
*アツメル株式会社は、SIerや事業会社のDX推進チームが仕様駆動開発を実践するためのAI開発パートナーサービスを提供しています。要件定義からAI活用を始めたい方は、お気軽にお問い合わせください。*
