「バイブコーディング」が叩き出す工数8割削減の秘訣とは
トランスコスモスは、コールセンター事業を中核としながら、デジタルマーケティングやEC構築など幅広いBPO事業を展開する企業だ。トランスコスモス・デジタル・テクノロジーは、グループ全体のオペレーションを支えるプラットフォームやシステムを開発する戦略子会社として2024年1月に設立された。外部顧客からの受託開発も手がけている。
所氏は講演の冒頭、バイブコーディングの基本概念を「エンジニアがAIに指示を出して、その指示を受けてAIがソースコードを書いていく、システム開発の新しい方法」と説明した。
従来の開発では、プロジェクトの規模に応じてプロジェクトマネージャー、SE、プログラマーを階層的に配置する必要があった。対してバイブコーディングでは、1人のエンジニアが複数のAIに並行で指示を出し、コンポーネントごとや工程別に作業を割り振る。
その効果を示す具体例として、所氏は社内で実施した検証結果を公開した。小規模なツールアプリケーションの開発において、従来手法では15.5人日を要すると見積もられた案件を、バイブコーディングで実施したところ1.5人日程度で完了した。「マイナス87％の工数削減ができる可能性がある開発手法になっています」と所氏は強調した。小規模システムやツールレベルの開発では、80％の工数削減が常態化しているという。
バイブコーディングという言葉が広まったのは2025年初頭。OpenAIの創設メンバーであるアンドレイ・カーパシー氏がXで唱えたことが発端となった。当初は一部エンジニアが試験的に触れる段階だったが、5月に日本経済新聞が大きく報じたことで経営層にも認知が広がった。9月以降は「システム開発するのにAIを使わない選択肢はもうないぐらいのレベルまで来ている」と所氏は語った。
しかし、バイブコーディングには課題も存在する。所氏は「エンタープライズシステムや大型システムは非常に構築しづらい。20人月×半年といった大規模システムの開発工程には適用しにくい」と大規模で複雑な案件への対応の難しさを挙げた。
トランスコスモスは巨大なオペレーションを支えるプラットフォーム開発を担っており、3年がかりで最大50人月規模のプロジェクトも珍しくない。受託開発でもエンタープライズ向けシステムが多い。
「バイブコーディングを使おうとしても、『エンタープライズ向けだからできない』となっては困る」という課題に直面した同社は、独自の手法を確立することになる。
大規模システムへのAI適用は難しい？ 7割完成で運用へ回す「VibeOpsメソッド」の全貌
エンタープライズ向けシステムへのバイブコーディング適用を可能にするため、トランスコスモス・デジタル・テクノロジーが確立したのが「VibeOpsメソッド」だ。所氏は「基本的には、世間で言われるバイブコーディングの手法を忠実に守りつつ、そこに我々なりの考え方を持ち込んでいる」と説明した。
従来のシステム開発は、ヒアリング・要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、運用保守という7工程で構成される。VibeOpsメソッドでは、これを「ヒアリング・要件定義・設計・計画」「実装・テスト」「結合テスト」「運用保守」の4つに圧縮した。
各工程では使用するツールとインプット内容を明確に定義している。要件定義・設計・計画の工程では、AWSの「Kiro Specs」やGitHub Copilotの「Agent Mode」を使用し、機能要件、非機能要件、アーキテクチャ、環境設定に加え、コーディングルールやデザインポリシーもインプットしていく。
開発・テスト工程では「AIに一度に全てを作らせないこと」を重要視している。「AIに『全部作って』と指示すると、ブラックボックス化したソースコードが出来上がってしまう」と所氏は指摘した。タスクを細かく分割してAIに作業を許可し、生成されたソースコードを人間がレビューする。「仕様を決め、細かく生成させ、人間がレビューする」というサイクルを回す。
VibeOpsメソッドの最大の特徴は、開発途中での考え方の切り替えにある。所氏は「開発の7～8割程度までは新規開発として進める。ここまでは完全に仕様駆動開発だ」と説明した。その後は保守運用に移る。
すでにリリースされたサービスで不具合が発生したときと同様に、新規開発したプログラムで発生している問題だけを見据えて修正する。不具合や機能改修の対象箇所をIssue（課題）として登録し、そのIssueに対してのみソースコードをAIに生成させ、精度を高めていく。こうした工程によってエンタープライズ向けシステムでもAIと協働できる。「余計な工数をかけず、途中で頓挫することもない」と所氏は強調した。
しかし、このVibeOpsメソッドには別の課題も存在する。従来の開発では、上流工程に経験豊富なエンジニアを配置し、詳細設計には中堅エンジニア、実装やテストにはジュニアエンジニアをアサインできた。ところがバイブコーディングでは全工程が圧縮され、要件定義からプロンプティング、コードレビュー、テストまで一気に実施する。よって「開発そのものが、上流工程のスキルを持つエンジニアにしか扱えない」と所氏は指摘した。
だが、上流工程のエンジニアだけをアサインするのは現実的でない。即座に採用することも、その工程の担当者だけを集めることも困難である。だからこそトランスコスモス・デジタル・テクノロジーは、経験の浅いエンジニアでも上流工程ができる仕組みの構築に取り組んだ。
ジュニアでも上流工程を完遂できるAIエージェント活用
上流工程スキルの不足を補うために工夫したのが、AIを活用したシステムドキュメントの品質管理の仕組みだ。
所氏はV字モデルを例に説明した。ウォーターフォール開発では、要件定義書をもとに基本設計書を作成し、基本設計書から詳細設計を作成する。テスト段階では、詳細設計書をもとに単体テスト、基本設計書をもとに結合テスト、要件定義書をもとにシステムテストを実施し、ドキュメントとテストが対になって品質を担保する。
「上流工程をAIに支援してもらい、経験の浅いエンジニアでも適切なシステムドキュメントを書けるようにしようと決めた」と所氏は語った。
エンジニアが要件定義書を作成し、社内規定のフォルダに置くと、AIエージェントが自動的に取得する。5種類のLLMがドキュメントを参照して多数決で判定し、3つ以上のモデルが承認しなければ、次の基本設計工程には進めない。このルールによってシステムドキュメントの質を担保する仕組みだ。
先輩エンジニアにドキュメントのレビューを依頼する場合、時間を取ってもらう必要があり、何度も繰り返すのは気が引けるものだ。しかしAIが相手なら、何度でも壁打ちができる。壁打ちを繰り返すことで、経験が浅いエンジニアでもVibeOpsメソッドを適用できるようになるのだ。
さらに、開発段階でのエンジニアのレベル差を吸収する仕組みも構築中だ。同社は、KiroやGitHub Copilot、Cursorといった開発IDEを単体で使うのではなく、社内の開発ナレッジと連携させる仕組みを開発している。
既存のコンポーネント、ライブラリの規約、コーディングルール、デザインポリシーなどのナレッジに対して、AIエージェントがMCPサーバーを通じてアクセスする。エンジニアが実装したい機能を伝えると、既存コンポーネントがある場合は自動的に適用される。エンジニアに意識させずに標準化を進める仕組みだ。2026年2月頃の完成を目指している。
講演の最後に所氏は「AIを使ったバイブコーディングは、すべてをAIがやってくれるわけではない」と語る。重要なのは「ヒューマン・イン・ザ・ループ」の考え方だという。
AIでできることはAIに任せ、要所で人間が介入してリードする。「特にヒアリングでは、クライアントが抱える課題や本質的に解決すべき問題は、顕在化していないことが多い」と所氏は指摘した。
そこは人間が共感や会話の間を読みながら引き出す。そのヒアリング結果をAIに教えて開発してもらい、人間がチェックする。「AIは人間の作業を潰すものではなく、増幅装置です」と所氏は強調した。
大規模なシステム開発でも、最低3割は確実に工数削減できると所氏はみている。この変化がもたらすのは、単なる効率化ではない。「もの作りからサービス提供への変化が起こると考えています。納品して終わりではなく、今後は受託開発であっても、クライアントに納品せずに自社資産として保有し、サービスとして提供していきます」。人月ベースから成果ベースへ、さらにはサービス提供型への産業構造の転換を、バイブコーディングが後押しする。
2025年10月末、バイブコーディングという言葉を生んだカーパシー氏は、ポッドキャストで「真のAIエージェントができあがるまであと10年ほどかかる」と語った。しかし所氏の見解は異なる。「ヒューマン・イン・ザ・ループの考え方で、人とAIがコラボレーションし、AIを増幅装置として人が機能を拡張していけば、現時点でもバイブコーディングは十分に機能する」と所氏は述べた。同社の取り組みは、バイブコーディングの可能性を現実のものとしつつある。
