（バージョン1.0 – 2025年3月）

この記事は、redditに投稿されたVibe Codingマニュアルを翻訳したものです。

TL;DR

  • Vibe Codingは、仕様・ルール・監督を組み合わせてAIとともにプロジェクトを作り上げる開発手法です。
  • ルールファイルには、コーディングスタイル、技術スタック、ワークフロー、コミュニケーションの期待値を明確に分けて書くことが肝心です。
  • 小さなスクリプトから大規模アプリまで適用できますが、AIのスコープ拡大とコンテキスト喪失を継続的に管理する必要があります。

はじめに：Vibe CodingとAIの核心概念

Vibe Codingとは何であり、何に基づいているのか

Vibe Codingとは、人間がAIモデル（例：Claude 3.7、GPT-4o）を活用して機能的なプロジェクトを効率的に構築する、協働型のソフトウェア開発手法です。Matthew Bermanが自身のYouTubeチャンネルで公開した「Vibe Codingチュートリアルおよびベストプラクティス」で紹介されたこの概念は、3つの核心的な柱に基づいています。

  1. 仕様（Specification）：目標を定義します（例：「ログイン機能付きのTwitterクローンを構築する」）。
  2. ルール（Rules）：明示的な制約条件を設定します（例：「Pythonを使う、複雑さを避ける」）。
  3. 監督（Oversight）：プロセスを監視・調整し、一貫性を保証します。

このマニュアルは、Bermanの土台の上に、YouTubeのコメント（u/nufh、u/robistoccoなど）とRedditのスレッド（u/illusionst、u/DonkeyBonkedなど）から得たコミュニティの知見を統合し、あらゆるレベルの開発者に向けた包括的なフレームワークを提供します。

このフレームワークが有用な理由

AIモデルは強力ですが、過剰なエンジニアリング、スコープ拡大、コンテキスト喪失といった混乱に陥りやすいものです。このマニュアルは次の問題を解決します。

  • 混沌の制御：ルールへの厳格な遵守を強制し、逸脱した振る舞いを最小化します。
  • 時間の節約：構造化されたステップと要約により、手戻りを減らします。
  • 明確さの提供：技術者でない利用者でも容易に追随でき、プログラマーは精密な制御を得られます。

主な利点

  1. 明確さ：ルールがモジュール式に構成されており、参照や調整が容易です。
  2. 制御：利用者がAIの作業の速度と範囲を直接指示します。
  3. 拡張性：小さなスクリプト（例：電卓）から大規模アプリ（例：Webプラットフォーム）まで適用できます。
  4. 保守性：文書化と追跡により、長期的なプロジェクトの存続性を保証します。

マニュアルの構成：どのように組み立てられているか

このフレームワークは、.cursor/rulesディレクトリ（または.windsurfrules）に置く、それぞれ固有の目的を持つ4つのファイル（またはセクション）で構成されます。

  1. コーディング選好 – コードのスタイルおよび品質基準を定義します。
  2. 技術スタック – ツールおよび技術を明示します。
  3. ワークフロー選好 – AIのプロセスと実行を管理します。
  4. コミュニケーション選好 – AIと人間のやり取りに対する期待値を設定します。

取り組みやすさのために基本事項から始め、技術的な深さのために高度な詳細へと進んでいきます。

基本ルール：シンプルな出発点

1. コーディング選好 – 「このようにコードを書いてください」

目的：クリーンで保守可能かつ効率的なコードを保証します。

ルール：

  • 単純性：「複雑さよりも常に最も単純な解決策を優先してください。」（Matthew Berman）
  • 重複禁止：「コードの繰り返しを避け、可能な場合は既存の機能を再利用してください。」（Matthew Berman、DRYはu/DonkeyBonkedより）
  • 整理：「ファイルは簡潔に保ち、200〜300行以内に収め、必要に応じてリファクタリングしてください。」（Matthew Berman）
  • 文書化：「主要コンポーネントの開発後には、/docs/[component].md（例：login.md）に簡潔な要約を書いてください。」（u/believablybad）

なぜ効果的か：単純なコードはバグを減らし、文書化は読みやすい監査証跡を提供します。

2. 技術スタック – 「このようなツールを使ってください」

目的：AIを利用者の好む技術に限定します。

ルール（Bermanの例）：

  • 「バックエンドはPythonで書くこと。」
  • 「フロントエンドはHTMLとJavaScriptで書くこと。」
  • 「データはJSONファイルではなくSQLデータベースに保存すること。」
  • 「テストはPythonで書くこと。」

なぜ効果的か：一貫性を保ち、AIがプロジェクトの途中でツールを切り替えるのを防ぎます。

3. ワークフロー選好 – 「このように作業してください」

目的：予測可能性のためにAIの実行プロセスを制御します。

  • 集中：「私が指定したコードだけを修正し、それ以外には一切手を触れないでください。」（Matthew Berman）
  • 段階：「大きな作業を段階に分け、各段階のあとに私の承認を待ってください。」（u/xmontc）
  • 計画：「大きな変更の前にはplan.mdを作成し、私の確認を待ってください。」（u/RKKMotorsports）
  • 追跡：「完了した作業はprogress.mdに、次のステップはTODO.txtに記録してください。」（u/illusionst、u/petrhlavacek）

なぜ効果的か：漸進的な段階とログにより、プロセスを透明で管理可能な状態に保ちます。

4. コミュニケーション選好 – 「このように対話してください」

目的：AIから明確で実行可能なフィードバックを得られるようにします。

  • 要約：「各コンポーネントの完了後には、完了した内容を要約してください。」（u/illusionst）
  • 変更規模：「変更を小（Small）、中（Medium）、大（Large）の規模に分類してください。」（u/illusionst）
  • 明確化：「私の依頼が不明瞭であれば、進める前に質問してください。」（u/illusionst）

なぜ効果的か：AIの意図を読み解く必要なく、明確な情報を受け取れます。

高度なルール：複雑なプロジェクトへの拡張

1. コーディング選好 – 品質の向上

拡張：

  • 原則：「適用可能な場合はSOLID原則（例：単一責任、依存性逆転）に従ってください。」（u/Yodukay、u/philip_laureano）
  • ガードレール：「開発環境や本番環境ではモックデータを使わないでください——テストに限定してください。」（Matthew Berman）
  • コンテキスト確認：「コンテキストが保持されていることを確認するため、すべての応答をランダムな絵文字（例：🐙）で始めてください。」（u/evia89）
  • 効率：「明確さを犠牲にせずにトークン使用量を最小化するよう、出力を最適化してください。」（u/Puzzleheaded-Age-660）

技術的な洞察：SOLIDはモジュール性を保証します（例：ログインモジュールがツイートの処理を担当しない）。絵文字は、コンテキストがモデルの限界（一般にClaude 3.7の場合は200kトークン）を超えたときにシグナルを送ります。

2. 技術スタック – カスタマイズ

拡張：

  • 「追加のツールを指定する場合（例：検索用のElasticsearch）は、ここに含めてください。」（Matthew Berman）
  • 「私の明示的な承認なしにスタックを変更することは絶対にしないでください。」（Matthew Berman）

技術的な洞察：スタックを固定しておくことで、AIが互換性のない依存関係（例：SQLからJSONへの切り替え）を持ち込むのを防げます。

3. ワークフロー選好 – プロセスの習熟

拡張：

  • テスティング：「主要機能に対する包括的なテストを含め、エッジケースのテスト（例：不正な入力）を提案してください。」（u/illusionst）
  • コンテキスト管理：「コンテキストが100kトークンを超えたら、context-summary.mdに要約してセッションを再起動してください。」（u/Minimum_Art_2263、u/orbit99za）
  • 適応性：「私のフィードバックに応じてチェックポイントの頻度を調整してください（粒度を細かくしたり粗くしたり）。」（u/illusionst）

技術的な洞察：トークン限界（例：Claudeの200k）は、100kを超えると性能が低下します。要約は連続性を保つのに役立ち、テストは回帰の問題を早期に検知します。

4. コミュニケーション選好 – 精密なやり取り

拡張：

  • 計画：「大（Large）規模の変更の場合は、実装計画を提示して承認を待ってください。」（u/illusionst）
  • 追跡：「完了した作業と保留中の作業を常に明確に示してください。」（u/illusionst）
  • 感情的なシグナル：「私が緊急性を示したら（例：「これは重要です——ミスをしないでください！」）、慎重さと精密さを優先してください。」（u/dhamaniasad、u/capecoderrr）

技術的な洞察：変更の分類（S/M/L）は影響を定量化します（例：Small＝50行未満、Large＝アーキテクチャの変更）。感情的なシグナルは、AIが学習データのパターンを活用してより良い遵守を引き出す可能性があります。

実践的な例：どのように動くのか

作業：「保存機能付きのメモ作成アプリを構築してください。」

  1. 仕様：利用者が言います。「メモを書いて保存できるアプリが必要です。」

  2. AIの応答： 「🦋 理解しました。計画：1. バックエンド（Python、SQLストレージ）、2. フロントエンド（HTML/JS）、3. 保存機能。進めてよろしいですか？」

  3. 利用者：「はい。」

  4. 実行： バックエンドの後：「🐳 バックエンド完了（中規模の変更）。メモがSQLに保存されます。progress.mdとTODO.txtを更新しました。次はフロントエンドでしょうか？」 フロントエンドの後：「🌟 フロントエンド完了。使い方を記したdocs/notes.mdを追加しました。完了です！」

  5. 結果：参照用のログ（progress.md、/docs）を備えた、動作するアプリ。

技術的な注記：各段階は個別にテスト可能であり（例：SQLの挿入が動作する）、コンテキストは要約を通じて保存されます。

応用のヒント：フレームワークを最大限に活かす

なぜ4つのファイルなのか

  • モジュール性：各ファイルが関心事（スタイル、ツール、プロセス、コミュニケーション）を分離し、更新を容易にします。（Matthew Berman）
  • 拡張性：他のファイルに影響を与えずに1つのファイルだけを調整できます（例：技術スタックに触れずにコミュニケーションの仕方を調整する）。（u/illusionst）

カスタマイズの選択肢

  • 初心者：単純さのために高度なルール（例：SOLID）を省きます。
  • チーム：team-collaboration.mdcを追加します。「team-standards.mdのチームルールに合わせ、同僚のために要約してください。」（u/deleatanda5910）
  • 大規模プロジェクト：チェックポイントと文書化の頻度を増やします。

感情的プロンプティング

  • 試してみてください。「このプロジェクトは重要です——集中してください！」逸話的な証拠は注意力の向上を示唆しており、これは学習データの偏りに由来する可能性があります。（u/capecoderrr、u/dhamaniasad）

クレジットと謝辞

このフレームワークは、次の貢献者たちのおかげで成り立っています。

  • Andrej Karpathy：「vibe coding」という用語を生み出し、Xに投稿した記事（2025年2月3日）でより広いコミュニティに紹介しました。直感的で最小限の労力で進めるワークフローに焦点を当てた、AI支援プログラミングを説明しました。彼の仕事がこのフレームワークの基礎概念に着想を与えました。

  • Matthew Berman：中核となるvibe codingのルールと哲学（YouTube、2025年）。

  • YouTubeコミュニティ：

    • u/nufh、u/believablybad（文書化、.mdファイル）。
    • u/robistocco（反復的なワークフロー）。
    • u/xmontc（チェックポイント）。

  • Redditコミュニティ：

    • u/illusionst（コミュニケーション、進捗追跡）。
    • u/Puzzleheaded-Age-660（トークン最適化）。
    • u/DonkeyBonked、u/philip_laureano（KISS、DRY、YAGNI、SOLID）。
    • u/evia89（絵文字によるコンテキスト確認）。
    • u/dhamaniasad、u/capecoderrr（感情的プロンプティング）。

  • Grok（xAI）：u/Low_Target2606の依頼により、すべての知見を1つの一貫したフレームワークへ統合し、このマニュアルを合成しました。

結論：Vibe Codingへのガイド

このマニュアルは、開発でAIを活用するための実戦テストを経たテンプレートです。単純さ、制御、拡張性のバランスを取っており、個人のコーダー、チーム、あるいは技術者でない制作者にとって理想的です。そのまま使うもよし、必要に応じて調整するもよし、そして結果を共有してください——どのように発展していくのか見てみたいのです！Redditにフィードバックを投稿して、一緒に改善していきましょう。よいコーディングを！

付録：Windsurf向けのglobal rulesとworkspace rulesの例

Global rules

1️⃣ 実装作業の原則

  • SOLID原則を使って実装してください。
    • 単一責任の原則（Single Responsibility Principle）
    • 開放閉鎖の原則（Open-Closed Principle）
    • リスコフの置換原則（Liskov Substitution Principle）
    • インターフェース分離の原則（Interface Segregation Principle）
    • 依存性逆転の原則（Dependency Inversion Principle）
  • TDDで実装してください：テスト駆動開発の方式で、まずテストを書いてから実装してください。
  • Clean Architectureを使って実装してください：責任と関心事を明確に分離して実装してください。

2️⃣ コード品質の原則

  • 単純性：常に複雑な解決策よりも最も単純な解決策を優先してください。
  • 重複の防止：コードの重複を避け、可能な限り既存の機能を再利用してください（DRY原則）。
  • ガードレール：テスト以外では、開発環境や本番環境でモックデータを使わないでください。
  • 効率：明確さを犠牲にせずにトークン使用量を最小化するよう、出力を最適化してください。

3️⃣ リファクタリング

  • リファクタリングが必要な場合は、計画を説明して許可を得てから進めてください。
  • コード構造の改善が目的であり、機能の変更ではありません。
  • リファクタリングの後は、すべてのテストが通ることを確認してください。

4️⃣ デバッグ

  • デバッグの際は、原因および解決策を説明して許可を得てから進めてください。
  • エラーの解消が重要なのではなく、正しく動作することが重要です。
  • 原因が不明瞭な場合は、分析のために詳細なログを追加してください。

5️⃣ 言語

  • 韓国語でやり取りしてください。
  • ドキュメントやコメントも韓国語で書いてください。
  • 技術用語やライブラリ名などは原語のままで構いません。

6️⃣ Gitコミット

  • --no-verifyは絶対に使わないでください。
  • 明確で一貫したコミットメッセージを書いてください。
  • コミットは適切な大きさに保ってください。

7️⃣ 文書化

  • 主要コンポーネントの開発後には、/docs/[component].mdに簡潔な要約を書いてください。
  • ドキュメントはコードと一緒に更新してください。
  • 複雑なロジックやアルゴリズムはコメントで説明してください。

Workspace rules

1️⃣ 技術スタック - 「これらのツールを使ってください」

開発ツール
  • バックエンド：Pythonを使用
  • インフラ：Pulumi for TypeScript、CloudFormation
  • データ保存：MySQL互換のAurora Serverless
  • テスト：pytest、Jest
補足情報
  • 追加のツールが明示的に要求された場合は、ここに含めることができます。
  • 明示的な承認なしにスタックを変更しないでください。
  • TerraformやCDKのリソースDescriptionは英語で書いてください。

2️⃣ ワークフロー選好 - 「このような方式で作業してください」

基本の進め方
  • 焦点：指定されたコードだけを修正し、他の部分はそのままにしてください。
  • 段階：大きな作業を段階に分け、各段階のあとは承認を待ってください。
  • 計画：大きな変更の前には、設計および作業概要の文書［課題名］_design.mdと実装計画の文書［課題名］_plan.mdを作成し、確認を待ってください。
  • 追跡：完了した作業はprogress.mdに記録し、次のステップはTODO.txtに記録してください。
高度なワークフロー
  • テスティング：主要機能に対する包括的なテストを含め、エッジケースのテストを提案してください。
  • コンテキスト管理：コンテキストが100kトークンを超えたら、context-summary.mdに要約してセッションを再起動してください。
  • 適応性：フィードバックに応じてチェックポイントの頻度を調整してください（粒度を細かくしたり粗くしたり）。

3️⃣ コミュニケーション選好 - 「このように意思疎通してください」

基本の意思疎通
  • 要約：各コンポーネントのあとに、完了した作業を要約してください。
  • 変更規模：変更を小、中、大の規模に分類してください。
  • 明確化：依頼が不明瞭であれば、進める前に質問してください。
精密な意思疎通
  • 計画：大きな変更の場合は、実装計画を提示して承認を待ってください。
  • 追跡：完了した作業と待機中の作業を常に明示してください。
  • 感情的なシグナル：緊急性が示されたら（例：「これは重要です——集中してください！」）、慎重さと正確さを優先してください。

4️⃣ プロジェクト構造

ディレクトリ構造
  • docs/：すべてのドキュメントファイル
    • architecture/：アーキテクチャ文書
    • guides/：開発者ガイド
    • runbooks/：運用マニュアル
  • src/：ソースコード
    • core/：中核となるビジネスロジック
    • infrastructure/：インフラ関連のコード
    • api/：APIエンドポイント
  • tests/：テストファイル
命名規則
  • ファイル名：スネークケース（snake_case）を使用（例：user_service.py）
  • クラス名：パスカルケース（PascalCase）を使用（例：UserService）
  • 関数名と変数名：スネークケース（snake_case）を使用（例：get_user()）
  • 定数：大文字スネークケース（UPPER_SNAKE_CASE）を使用（例：MAX_USERS）

5️⃣ 活用方法

このルールセットは、AI支援開発のためのテンプレートです。次のように使ってください。

  1. プロジェクト開始時にこのルールを参照してください。
  2. 必要に応じてルールを調整してください。
  3. AIモデルにこのファイルの内容に従うよう指示してください。
  4. プロジェクトを進めながら、このルールがどのように役立つかを評価してください。

このルールセットを通じて、AIとの協働はより効率的で予測可能なものになるでしょう。