はじめに

バイブコーディングで開発を行うエンジニアが増えています。自然言語でざっくり指示するだけでコードが出てくる。個人の開発スピードは上がります。しかし、いざチーム開発に持ち込むと「品質がばらつく」「レビューが追いつかない」「ノウハウが個人に閉じる」という壁にぶつかっていないでしょうか。

その壁を越えるヒントになるのがコンテキストエンジニアリングです。本記事では、バイブコーディングの功績と限界を整理した上で、コンテキストエンジニアリングの考え方、CLAUDE.mdや仕様駆動開発といった具体的な実装手段を解説します。

＼ 実践事例をライブで聞く ／

AI駆動開発の最前線
コンテキストエンジニアリングが
変える開発プロセス

サイバーエージェントとDeNAの実践者が登壇。
コンテキスト設計の具体的な運用、AIの任せ方と品質統制について、
現場の知見を直接聞ける機会です。

今すぐお申し込み

バイブコーディングが変えたこと、変えられなかったこと

バイブコーディングの功績

バイブコーディングは、2025年2月にAndrej Karpathy氏がXへの投稿で提唱した概念です※1。「自然言語でAIに指示し、『雰囲気（vibes）』に身を任せソフトウェアを作る」というアプローチを指します。

精緻なプロンプト設計や高度なプログラミングスキルがなくても、自然言語でアイデアを伝えるだけで動くソフトウェアが生まれる。プロトタイピングの速度は大幅に上がり、個人開発やPoCの場面でバイブコーディングは大きな価値を発揮しました。

チーム開発で顕在化する3つの限界

しかし、バイブコーディングをチーム開発にそのまま適用すると、3つの限界が顕在化します。

限界1：品質の不安定さ

バイブコーディングでは、機能自体は素早く実装できても、エラーハンドリングやテストの有無といった品質基準にブレが生じます。

そのため、品質のばらつきを防ぐために、人間がレビューをする必要があります。

ファインディでも、個人のスキルにPR（プルリクエスト）の質が依存している状態が確認されていました。※2

限界2：レビュー負荷の増大

 AI生成コードによるPRが大量に作られる一方、それを検証するレビュー工程は人間に依存したままになっています。文脈なしで生成されたコードは、レビュアーが設計意図を推測する負荷が高く、結果としてレビューがボトルネック化します。

Findy Team+導入企業のデータでも、AI利⽤しているチームの約4割（38.46%）でレビュー速度が悪化していることがわかっています。（※3）

限界3：知見の属人化

 うまくいくプロンプト、効果的なワークフロー、便利な設定が「できる人の頭の中」に閉じたままでは、チーム資産にはなりません。AI活用が個人最適にとどまり、組織全体の生産性向上につながらないという課題は、多くの開発チームが直面しています。

コンテキストエンジニアリングとは何か：プロンプトの「外側」を設計する技術

コンテキストエンジニアリングとは

バイブコーディングの限界の多くは、「コンテキスト設計の不在」に起因します。ここで登場するのがコンテキストエンジニアリングです。

コンテキストエンジニアリングと混同されやすい概念として、プロンプトエンジニアリングがあります。

プロンプトエンジニアリングが「1回の入力を磨く技術」であるのに対し、コンテキストエンジニアリングは「AIが正しい出力を生成するために必要な文脈情報を、あらかじめ構造化して渡す仕組みを設計する」アプローチです※4。プロンプトの「外側」にある、プロジェクト全体の文脈基盤を設計するという点が本質的な違いです。

なぜ「コンテキスト」がAIの出力品質を決めるのか

AIは、与えられた入力をもとに次の出力を生成します。

そのため、AIにどんな情報を渡すかはもちろん、どの情報を・どの順序で・どの粒度で渡すかが、出力の正確性や一貫性を大きく左右します。

たとえば、自然言語の指示と現在開いているファイルだけを手がかりにコードを書かせる場合、AIが参照できるのはその場の局所的な情報に限られます。

一見それで十分に見えても、実際の開発ではそれだけでは足りません。設計思想、命名規約、依存関係の扱い方、過去の意思決定、例外的な実装ルールなど、プロジェクトには明文化されていない前提が数多く存在するからです。

この前提が欠けたまま生成を行うと、AIは「その場ではもっともらしいが、全体には合わない出力」を返しやすくなります。

コード自体は動いても設計方針とずれる。命名は自然でもチーム規約に合わない。既存の責務分割を無視して新しいヘルパーを増やす。こうしたズレは、モデルの能力不足というより、判断に必要な文脈が渡されていないことによって起こります。

つまり、AIの出力品質を高めるうえで重要なのは、AIが判断に使うべき情報へ迷わず到達できるように、関連性の高いコンテキストを整理し、優先順位をつけ、参照しやすい形で配置しておくことです。

同じモデルを使っていても、渡されるコンテキストが違えば、出力は大きく変わります。

だからこそ、AI活用ではプロンプトを書くこと以上に、どの文脈をどう渡すかを設計することが重要になります。

チームで実践するコンテキストエンジニアリング：CLAUDE.mdから仕様駆動開発まで

実装レイヤー別の整理

コンテキストエンジニアリングの実装手段は、以下の4つのレイヤーに整理できます。

チームで最初に取り組むべきはルールファイル層です。リポジトリに1ファイル追加するだけで始められ、チーム全員がAIに共通の文脈を渡せるようになります。

たとえば、CLAUDE.mdには以下のような内容を記述します。

# プロジェクトルール

## アーキテクチャ
- レイヤードアーキテクチャ（Controller → Service → Repository）を採用
- ドメインロジックはService層に集約する

## コーディング規約
- 関数名はキャメルケース、定数はスネークケース大文字
- エラーハンドリングは早期リターンパターンを使う

## 禁止パターン
- Service層からの直接DB接続は禁止（必ずRepositoryを経由）
- any型の使用禁止（型安全性を確保）

# プロジェクトルール

## アーキテクチャ
- レイヤードアーキテクチャ（Controller → Service → Repository）を採用
- ドメインロジックはService層に集約する

## コーディング規約
- 関数名はキャメルケース、定数はスネークケース大文字
- エラーハンドリングは早期リターンパターンを使う

## 禁止パターン
- Service層からの直接DB接続は禁止（必ずRepositoryを経由）
- any型の使用禁止（型安全性を確保）

このファイルがあるだけで、AIは設計規約を踏まえた出力をしやすくなります。

仕様駆動開発による運用設計

ルールファイルの次の段階として派生しやすいのが、仕様駆動開発です。AIに実装を任せる前に仕様を構造化して定義し、「仕様→実装→仕様との照合レビュー」というフローで品質を統制するアプローチを始める企業が増えています。

このアプローチの強みは、レビューの観点が明確になることです。仕様が先に定義されているため、レビュアーは「仕様通りに実装されているか」を検証すればよく、AI生成コードの設計意図を推測する負荷が大きく下がります。

「仕様駆動開発（SDD）」の詳細については、「仕様駆動開発（SDD）とは？TDDとの違いからSpec Kit・Kiroを使った実践まで解説」も参考にしてください。

品質統制の具体策についてさらに詳しく知りたい方は、「AI駆動開発で品質がばらつく原因と対策｜コンテキストエンジニアリングによるチーム標準化」をご覧ください。

AI活用の効果をどう測るか：属人化を超えるデータ駆動の振り返り

コンテキストエンジニアリングを導入しても、「なんとなく良くなった気がする」では改善は続きません。効果を定量的に追跡する仕組みが、属人化脱却の基盤となります。

測定すべき指標の例はこちらです。

• AI利用率：チーム・メンバーごとのAI活用状況の推移
• サイクルタイム変化：AI利用あり vs なしでのPR作成〜マージの所要時間差
• レビュー所要時間：コンテキストエンジニアリング導入前後でのレビュー工程の変化
• 手戻り率：リジェクトPRの割合や修正コミットの頻度

これらを手動で集計するのは現実的ではありません。Findy Team+では、AIツールの利用状況と開発パフォーマンスを自動で可視化できます。AI利用レポートでチーム・メンバーごとのAI利用割合を時系列で確認し、AI効果レポートでAI利用あり/なしのサイクルタイム差分を比較できます。対応するAIツールはGitHub Copilot、Claude Code、Devin、Cursor、Clineなど15種以上です。

「コンテキスト設計を改善する→効果をデータで確認する→さらに設計を改善する」というPDCAサイクルを回すことが、個人の感覚に頼らない組織的なAI活用の基盤になります。

まとめ｜バイブコーディングを卒業し、チームのAIを活用した開発の基盤をつくる

本記事のポイントを整理します。

• バイブコーディングはAIを活用した開発の入口として有効だが、チーム開発では品質ばらつき・レビュー負荷・知見の属人化という壁にぶつかる
• コンテキストエンジニアリングは「プロンプトの外側」を設計する方法論であり、チーム全体のAI活用品質を底上げする

＼ 実践事例をライブで聞く ／

AI駆動開発の最前線
コンテキストエンジニアリングが
変える開発プロセス

サイバーエージェントとDeNAの実践者が登壇。
コンテキスト設計の具体的な運用、AIの任せ方と品質統制について、
現場の知見を直接聞ける機会です。

今すぐお申し込み

品質統制の具体策をさらに深掘りしたい方は、「AI駆動開発で品質がばらつく原因と対策｜コンテキストエンジニアリングによるチーム標準化」もあわせてご覧ください。

参考・出典

※1 Andrej Karpathy “I have a new word for this: vibe coding” X投稿, 2025年2月

※2 ファインディ株式会社「なぜ個人の生産性が大幅に向上しても、組織の生産性は高くならないのか – AI駆動開発を実現するレビュープロセスの再設計 –」https://jp.findy-team.io/blog/ai-casestudy/rethink-review-process/

※3 ファインディ株式会社「定量データで暴く⽣産性の錯覚と感覚頼りを捨てるべき理由」

※4 「Context engineering」という表現は、Tobi Lütke の定式化と、それを受けた Andrej Karpathy の補足によって 2025年6月に広く参照されるようになった。