Vibe Coding という単語が一瞬流行って、その問題点が色々浮き彫りになって、今は Vibe Engineering とかまた単語を変えて流行り直そうとしていますね。当方も実務で Vibe Coding 使うなんて無理だな〜と思っていましたが、試行錯誤を繰り返しているうちにある程度程よく導入できる方法を整理できてきたのでまとめてみます。
前提
当方は GitHub Copilot + VS Code + ChatGPT な環境で開発しています。使用している AI ツールによってベストプラクティスは少し異なる可能性があります
序章 - Vibe Coding をどう扱うかの全体像
Vibe Coding を本業でガッツリ使うには無理筋だろうな〜と感じつつも、やっぱり流れとしては避けて通れないし、完全に否定して閉じてしまうのも勿体ないので、私はしばらく観察と小さなトライを繰り返してきました。最初は「指示出しが大変」「どうせ伝わらない」って思ってたんですが、実際にはタスクの性質を選んでやれば結構しっかり動くし、変なところで引っかかった時だけ自分が助け舟を出せばまあまあ悪くない落とし所を作れるという体感です。
この記事では、その中で見えてきた課題の整理から、適切な使い所と導入の注意点、運用のための記憶領域の作り方、人間と AI の切り替えポイントまでをまとめておきます。全体を俯瞰すると、「AI に丸投げせず、AI の得意な範囲を狙って、情報のコンテキストを自分で設計して渡しておく」っていう三本柱に落ち着いてきた感じなので、そのあたりを章立てしながら掘り下げます。
Vibe Coding の問題点 - 何がボトルネックになりがちか
Vibe Coding の問題点、というと色々挙げられてると思いますが、主にはこの辺りが特に問題かなと私は感じています。
- 指示の誤りや誤解による異なる仕様での実装
- 操作者の専門外領域の実装を行う際の品質担保
この二つがだいたい地雷源です。勿論、AI に頼まずとも人間に頼んだとて同じ問題が生じますが、人間と違ってテキストや図解だけで説明（prompt）をやりきろうとすると 時間がかかる & 全部伝わらない → 誤解が生じやすい。
また、人間と違ってそのタスクに取り組む前に本来会話してきた記憶のようなものが AI 側にはなくステートレスなので、伝えるべき情報量も多いし大体の場合期待したようには動かないということが発生するんですね。自分がよく知る実装ならまだマシではありますが、自分の得意ではない領域の実装ともなってくると今度はレビューも不十分になる場合が出てきて結局は自分で勉強してちゃんと書いた方が... ってなるのが実務あるあるかなと思います。だからこそ、どこが特に誤解を生むのか、どのあたりで専門外の知識が不足して破綻するのかを先んじて整理しておくと、AI に任せる範囲を選びやすくなります。認識合わせのために、典型的な失敗パターンをざっと表にしておきます。
| 失敗パターン | 起きやすい背景 | 回避策のヒント |
|---|---|---|
| 仕様の読み違い | 指示が長文化、暗黙知満載 | 図式化・箇条書き・依存関係をタスク冒頭で整理 |
| 専門外領域への無自覚な踏み込み | レビュー側も詳しくないまま任せがち | リスク高い箇所は先に人間で調査メモを残す |
| 途中まで動いたがテストが不十分 | テストケースの定義不足、AI 任せ | 入出力を事前に決めて、最小限のテストは自分で書く |
| 同じ質問の繰り返し | ステートレスで履歴がリセットされる | 記憶ファイルを作り進捗と背景を蓄積 |
Vibe Coding の立ち位置 - どのレイヤーで効くのか
Vibe Coding は大規模なコードの一部をちょろっと直す... とかは、コードの変更前にやるべきことが多すぎるし、それを context window の範囲に詰め込むのも結構難易度が高く、少なくともコーディング全体をこれでやれるものではないと感じています。
AI を取り入れたけど実は非効率的だった... なんて結果にならないように適用するならこの辺りが適用範囲かなと感じています。
- 新規実験のモック・PoC 向けのコード実装
- コードの最初の書き始め。ベースのコードの実装
- Vibe Coding というか Vibe ReSearch 的な、既存コードの調査（何かを見つけるときに特に）
ここまで絞ると、AI に渡す情報の量が減り、期待値のズレも抑えられます。PoC や初期実装、調査までは AI 側を使い倒していいんですけど、既存モジュールの改修以降は相当説明のコストが増えるので潔く人がやった方が速いことも多いです。
対策方針1 - 原則「first commit」を AI に割り当てるだけにする
Vibe Coding で既存のコードに変更を加える、は結構難易度が高いなと感じます。これは実装の経緯や他のモジュールとの関連性、影響範囲等前提知識が AI の知識量だけではカバー出来ない領域の範囲が広く、またそれをステートレスな AI に全部伝えるのも毎回新規参入してくれたヘルプのエンジニアにプロジェクトの全体像を毎回説明しているようなもので、context window のサイズも加味するとそもそもこれを満足にさせるのが本来現実的ではないのだと思われます。
だったならば Vibe Coding で取り扱うのはあくまでも first commit するための最初のコードや新規モジュール等、既存を意識しない分野でどんどん使えば良いのです。考え方として、我々も外部からライブラリを選定してダウンロードして使うことを頻繁にしますが、その際にライブラリの中身を全部丁寧にレビューしてから使う人は少数派ですよね。Vibe Coding も同様で、入力と出力、依存の定義だけしてあげて、自分のプロジェクトで使うモジュールを開発させ、それを import して使えば既存プロジェクトの情報を全部把握しなくとも該当範囲に集中して開発ができるので破綻しづらいです。さらにテストについても、最低限のシナリオだけ自分で定義して AI に書かせ、あとで通るかを確認するだけで初期工数を半分以下に削れたりします。要は「初期の骨組みだけ作ってもらって、肉付けや最終調整は自分でやる」という役割分担を最初から敷いておけば、変に期待値を外すことも減ります。
対策方針2 - memory/*.md で擬似的な記憶を作るとブレが減る
そうはいってもそれでも大きな規模のモジュールを書かせると破綻することもあるし、またそのモジュールのメンテナンスをお願いする時にも、また改めて説明しなければならなくなるので同じ問題が生じてきます。これを回避するために該当モジュールに AI の記憶領域を作っちゃいましょう。例えば次のような階層の記憶をそのモジュールを作るときのレポジトリに作成しておきます。
├── src
├── tests
└── memory
├── plan.md
├── changelog.md
├── **/*.md
└── libs
└── xxx.md
それぞれのファイルの役目は次のとおりです。
/memory/plan.md
AI が作業を開始する前に行動計画を記録し、終わったものにチェックを付けるための記憶ファイルです。既に多くのプロジェクトで取られている手法だと思いますので詳細説明は省きますが、チェックボックス形式で ToDo を書かせると「やり残し」が視覚化されて便利です。また、途中で AI が変な方向に行くのも避けられます。
/memory/changelog.md
作業完了時に取り組んだ内容や経緯を記述するための記憶ファイルです。plan.md だけでは取り組んだタスクの情報は保存されますが、何故そのタスクに取り組んだのか、そのタスクは完全に完了したのか、残っているタスクはないか、使う際の注意事項はないか、といった情報が抜けます。AGENT.md 等に plan.md に加えて changelog.md も書くよう指示すると、「過去改修の理由」が残って次の作業が楽になります。
/memory/**/*.md
フリーフォーマットで AI にメモを取らせるフォルダです。ライブラリの使い方、テスト環境の注意点など、AI 自身が覚えておきたいことを適宜保存させます。こうして記憶領域を作っておけば、人間が作業する際の動きに更に近づき、過去の情報を自ら保存・参照しながら作業に取り組めます。
よく使うライブラリの最新ドキュメントを /memory/lib/** に放り込んでおけば、AI が適宜拾って作業してくれるようになり、かなり楽です。これは本題とズレますが、使うライブラリの知識もどんどんレポジトリに放り込むと良いでしょう
対策方針3 - AI の足が止まったら潔く人にバトンタッチ
AI に作業をさせていると、どうしても長時間同じタスクから進まない、問題が解決できない時があります。しかしそのような時は AI の事前知識で解決できない「ハマっている」状態ですので、追加情報の提供や依存モジュールを見ないとそのまま解決できないことがほとんどです。ここで AI に「正しく書け」と怒ってもただのパワハラです。
こんな時には人間にバトンタッチして次のどちらかを試すようにしましょう。
該当モジュールや関連モジュールの実装を人が注意深く確認する
結構簡単な問題でつまづいている事が多いです。ちょっと引数が足りてなかったとか、そもそも別のモジュールのバグだったなんてよくあります。素直にハマり出したら人が見た方が早いこともあります。
ライブラリの使い方の問題であれば、該当ライブラリのレファレンスを人間から渡す
単純にライブラリのバージョン差分や非推奨 API に引っかかっているだけのケース、環境依存の初期化コードが必要なケースなど、AI が知らない前提を補足するだけで一瞬で解決することも多いです。
運用フロー例
この流れで「停滞したら必ず人が介在する」という回路を用意しておけば、AI に無理をさせず、結果的に人間のストレスも減ります。何より、放置しないルールを明文化しておかないと、AI が延々と同じミスを繰り返してログが無限に積み上がるので、タイムアウト条件やバトンタッチ条件を最初から決めておくと良いです。
総括 - 三つの原則でストレスを減らす
この 3つの方針でかなり人間側のストレスを減らしつつ、役割分担もできると思います。まとめると、1) first commit の骨組みだけを AI に投げる、2) memory フォルダを作って擬似的な記憶を与える、3) 行き詰まったら速やかに人間が拾う。この三点を徹底するだけで、Vibe Coding の「期待外れ感」はだいぶ薄れます。さらに、モジュール単位でタスク設計しておくと再利用性も上がるので、計画段階から「AI に任せるブロック」を切り出しておくのが吉です。
もし良かったら使えそうな手法があれば取り込んでみて〜