vibe-coding

Vibe coding の方法論

AI コーディングアシスタントを使って、ソフトウェアを効果的に構築するための実践的な戦略です。

ツールの状況は急速に変化します。 このスキルの最終確認日は 2026-05-08 です。方法論（計画、バージョン管理、テスト、バグ修正）は安定していますが、具体的なツール名、指示ファイルの規約、料金の詳細は四半期ごとに変わります。記載されているツールは代表例であり、すべてではないものとして扱ってください。

計画プロセス

まず AI と協力して、詳細な実装計画を Markdown ファイルにまとめます。

スコープ管理：計画を見直して改良し、不要な項目を削除し、複雑な機能には「実装しない」と印を付け、後で実装するアイデア用に別のセクションを用意します。これにより、スコープの拡大を防ぎ、集中力を保てます。

段階的な実装：すべてを一度に構築するのではなく、セクションごとに作業します。実装が成功したら AI にセクションを完了済みとして記録させ、次に進む前に、動作する各セクションを git にコミットします。

進捗を見える化する：ToDo リスト、Markdown のチェックリスト、インラインのステータスマーカーなどを使い、完了した作業と残っている作業を、自分と AI の両方が把握できるようにします。これにより、完了済みの作業をやり直すのを防ぎ、セッションに集中できます。

バージョン管理の戦略

Git は安全策です。AI ツールの元に戻す機能だけに頼らないでください。

試行ごとにブランチを作成する：新しい機能は毎回、新しいフィーチャーブランチ（git switch -c feature/xyz）で開始し、AI が進めるのに合わせて小さな単位でコミットします。ブランチの境界は「手に負えなくなったら捨てる」ための境界です。破棄するのはブランチであり、作業ツリーではありません。

AI が悪い方向に進んだとき：元に戻せるコマンドを優先します。git restore . は未コミットの変更を破棄し、git stash は変更を一時退避し、git switch - は直前のブランチに戻ります。git reset --hard HEAD を使うのは、作業ツリーに残す価値のあるものがないと確認できた場合だけにしてください。破壊的なコマンドは reflog のような安全策を飛ばし、未コミットの実験を消してしまうことがあります。（エージェントが新しいファイルを作成していた場合は、「本当にすべてを捨てる」ために別途 git clean -fd も必要ですが、同様の注意が必要です。）

クリーンな再実装：何度か試した後に動作する解決策が見つかったら、main からブランチを作成して新たに実装し、使い捨てのブランチは破棄します。AI による失敗した試行を重ねると、不要なコードが積み重なり、後々の混乱を招きます。既知の正常な解決策をクリーンに再実装するほうが、複雑に絡み合ったコードを解きほぐすよりも速く、保守しやすくなります。

テストのフレームワーク

ユニットテストよりも、エンドツーエンドの統合テストを優先します。ユーザーの行動を再現することに重点を置き、誰かがサイトやアプリを操作する様子をシミュレーションして機能をテストします。

リグレッションの防止：LLM は、無関係なロジックに不要な変更を加えることがよくあります。テストを行えば、こうしたリグレッションが重なる前に検出できます。

ガードレールとしてのテスト：まずテストケースを用意し、AI が変更すべき内容と変更すべきでない内容の明確な境界を示すことを検討してください。次の機能に進む前に、テストが合格することを確認します。

効果的なバグ修正

エラーメッセージ：エラーメッセージをそのままコピーして貼り付けるだけで、AI が問題を特定して修正するためのコンテキストとして十分な場合がよくあります。

コーディング前に分析する：実装に飛びつく前に、複数の原因の可能性を検討するよう AI に依頼します。これにより、誤った問題を追いかけるのを防げます。

失敗した後はリセットする：修正に失敗するたびに、壊れたコードの上に修正を重ねるのではなく、クリーンな状態から始めます。

戦略的なログ出力：バグの挙動が不明瞭な場合に状況を把握しやすくするため、ログ出力を追加します。

モデルを切り替える：ある AI モデルが問題に行き詰まったら、別の AI モデルを試します。

AIツールの全体像（2026-05時点）

現在のツールは、4つの形態に大別できます。話題性ではなく、作業する場所に合わせて選びましょう。

形態	例	用途
CLI エージェント	Claude Code、Aider、Codex CLI、Gemini CLI、GitHub Copilot CLI、opencode、Goose	リポジトリ全体にわたる変更、複数ファイルのリファクタリング、自動化、ヘッドレス／cron での利用
単体型 IDE	Cursor、Windsurf、Zed、Kiro	チャットとオートコンプリートが緊密に統合された、日々の編集
IDE 拡張機能	GitHub Copilot、Continue、Cline、Roo Code、Amazon Q	既存のエディター（VS Code、JetBrains、Neovim）を使い続ける
クラウドエージェント	Devin、OpenHands、Jules、GitHub Copilot Coding Agent	PR を介した非同期／バックグラウンド作業。ローカルのターミナルは不要

多くの開発者が行き着く一般的な構成は、日々の編集には Cursor または Copilot を使い、リポジトリ全体にわたる作業やエージェント型タスクには Claude Code（または Codex CLI）を使うことです。これらは互いに補完し合います。IDE ではすばやくインライン編集を行い、ターミナルでは長時間のエージェント型ループを実行できます。

AIツールの最適化

指示ファイル：AI アシスタント向けに、プロジェクト固有のコンテキストを記述します。規約は分散していますが、複数のツールで共有形式として AGENTS.md が採用されつつあります。2026-05時点でのファイル名は次のとおりです。

ツール	ファイル	備考
Claude Code	CLAUDE.md（ディレクトリごとに配置、ネスト可能）	自動的に読み込まれます。docs.anthropic.com/en/docs/claude-code/memory を参照してください
Cursor	.cursor/rules/*.mdc（新方式）、Markdown + YAML frontmatter（description、globs、alwaysApply）	従来の単一ファイル .cursorrules も引き続き動作しますが、Cursor は移行を推奨しています
Windsurf	.windsurfrules または .windsurf/rules/*.md	Cursor と同じく、2つの方式があります
GitHub Copilot	.github/copilot-instructions.md	リポジトリ単位の単一ファイル。実用上の上限は約4k文字です
Cline	.clinerules	単一ファイル
Aider	.aider.conf.yml（設定）+ チャット履歴ファイル	Git ネイティブです。指定すれば CONVENTIONS.md を読み込みます
Continue	.continue/config.json	JSON 設定。リポジトリごとに設定します
Codex CLI / Gemini CLI / Aider / Continue	AGENTS.md（ベンダーに依存しない代替形式）	ツール横断の共通形式として定着しつつあります

複数のツールを使う場合は、正式な指針を AGENTS.md にまとめ、ツール固有のファイルから参照してください（CLAUDE.md：「AGENTS.md も読み込んでください。」）。これにより、関連ファイル間の内容のずれを防げます。

ローカルドキュメント：API ドキュメントをプロジェクトフォルダーにダウンロードします。AI ツールは、学習時の記憶データよりもローカルのドキュメントを参照するほうが正確に動作します。特に、学習データの締め切りよりも速いペースで破壊的変更を含むリリースを行うライブラリー（例：Sentry SDK、Google GenAI SDK、Selenium）では効果的です。

複数のツールを実行する：別のタスクを進める Claude Code または Codex CLI のセッションを別のターミナルで動かしながら、Cursor でインライン編集を行っても、特にデメリットはありません。作業に応じて異なる形態を使い分けましょう。

出力を比較する：重大な判断では、異なる2つのプロバイダーのモデルで解決策を生成し、同じ要件に照らして比較します。モデルファミリーによって、間違いの傾向は異なります。

複雑な機能の開発

単体のプロトタイプ：複雑な機能は、まずクリーンなコードベースで構築し、動作するようになってから統合します。問題を切り分けられるため、デバッグが容易になります。

参考実装：AI に、手本として従うべき動作中の例を示します。既存のコードパターンが具体的な指針になります。

明確な境界：外部 API に一貫性を保ちながら、内部の変更を可能にします。明確な境界を備えたサービスベースのアーキテクチャは、AI 支援開発ではモノレポよりも効果的です。

技術スタックに関する考慮事項

実績のあるフレームワーク：Ruby on Rails などの成熟したフレームワークは、20 年以上にわたって一貫した規約がトレーニングデータに含まれているため、うまく機能します。

トレーニングデータが重要です：Rust や Elixir などの新しい言語は、トレーニングデータが少ないため、エラーや古いパターンが増える可能性があります。

モジュール性：小さくモジュール化されたファイルは、人間にも AI にも扱いやすくなります。何千行にもなるファイルは避けてください。コンテキストウィンドウを超え、混乱を招きます。

コーディング以外の用途

AI アシスタントはコードを書く以外にも役立ちます。

• DevOps：サーバー、DNS、ホスティングの設定
• デザイン：ファビコンなどのデザイン要素の生成
• ドキュメント：ドキュメントやマーケティング資料の下書き
• 学習：実装を行ごとに説明
• 視覚入力：UI のバグやデザインの参考のためにスクリーンショットを共有します。最新のアシスタントの多く（貼り付けによる Claude Code、Cursor、Copilot Chat）は、画像を直接入力できます。
• 音声入力：Whisper ベースの文字起こしツール（Whispr Flow、Superwhisper、MacWhisper、Aqua）は、現在の OpenAI / Whisper.cpp モデルで 130～180 wpm に達します。長文のプロンプト作成やラバーダッキングに便利です。

継続的な改善

定期的なリファクタリング：テストを用意したら、頻繁にリファクタリングします。リファクタリング候補を AI に特定してもらいましょう。

最新の状態を保つ：新しいモデルがリリースされたら、すべて試してみましょう。モデルによって得意なタスクは異なるため、ユースケースに最適なものを見つけるために試してください。

参考ファイル

複雑さを見直す作業や、分岐に関する大幅な変更を行う前に、複雑さと可読性を読んでください。

変更が保存された状態、信頼境界、エラー復旧、または報告されたバグに影響する場合は、不変条件と変更規模に応じた慎重さを読んでください。