2026年1月、スノーボード駆動開発に辿り着いた 〜 オレのバイブコーディング 〜
はじめに
こんにちは、淡路です。
最近 AI エージェントを自在に作り出して汎用的な業務を支援するアプリを実装しています。まだ公開していませんが、雰囲気が伝わる画像だけ載せておきます。
汎用アシスタントを始め、様々なエージェントを選択して対話できるチャットUI
さまざまなエージェントを選択・作成でき、ツールを組み合わせて業務を効率化できます。
Data Analyst、Code Review Agent など用途別のエージェントを選択可能
新しいエージェントを作成。名前、説明、システムプロンプトを設定
エージェントに持たせるツールを選択。execute_command、file_editor など 40 以上のツールから選択可能
AgentCore Gateway で利用可能なツール一覧。自然言語で検索も可能
エージェントの定期実行設定。毎日・毎週・カスタム cron 式に対応
また、このアプリ自体がリモート型のコーディングエージェントとしても機能します。GitHub の Issue を読み解き、実装・テストを行って Pull Request を作成してくれます。つまり、エージェントを作るためのアプリを、エージェントが開発している状態です。
この記事では、このソフトウェアの開発において私が意識していたバイブコーディングやソフトウェア開発のテクニックを文書として残しておこうと思います。
バイブコーディングを始める前に
新規に全くのゼロからソフトウェアを作り出す局面において、まずは利用するユーザー層やどのようなユースケースで使用するのか、深掘り検証をしておきます。Claude のウェブアプリで Chat を活用しながら自分の感覚と要件を整理する。誰が幸せになるかを考えます。まだどう作るかは考えません。
私の場合は「AWS で AI エージェントを作る開発者がユーザーへの業務ニーズのヒアリングをするために必要となる必要最小限のエージェントカスタマイズアプリ」を作ることが目標でした。
彼らが幸せになるソフトウェアを作ろうと決めました。
ソフトウェアの骨格をつくる
ディレクトリ構成と CI を整える
要件が整理できたら、ソフトウェアの骨格を作りはじめます。「〜という機能をもつTODOアプリを作って」のように、ただ機能的な要件を指示するのではなくて、まずはソフトウェアの骨格、構造を作ります。
プロンプトの例
TODOアプリを作るためのソフトウェアの基本的な構造を作ります。
Frontend は React, TypeScript, Zod, Zustand, React Router を活用して、
シンプルなページルーティングとグローバル状態管理ができるところまで実装します。
Backend は Node.js, TypeScript, Express, jest を使用します。
ユニットテストを1ケースだけ実行できる構造を作りましょう。
まずは計画を立ててディレクトリ構造を含めていくつかの案を提案してください。
一般的なウェブアプリケーションだとしても AI の提案をそのまま受け入れてしまうと、そのままでは進化可能性の低い、あるいは保守性が低い構造になってしまうので、まずは構造を固めて、linter, unit test が実行できる仕組みを整えるところまで進めます。
何度か AI と対話を繰り返して最適な構造を見極めましょう。エンジニアリングスキルが試されます。
計画を細かく立てて実装するには Spec 駆動開発が得意な Kiro を使っても良いですね。Kiro を使わずとも計画を立てることは重要です。
認証・認可を設計する
昨今のウェブアプリケーションでは JWT によるステートレスな認可制御の仕組みを採用することが一般化していますが、機能の実装より前に作り込んでおくと後からごちゃごちゃ考えることが減り幸せになります。
特に以下は整備しておくべきです。
| レイヤー | 整備すべき項目 |
|---|---|
| Backend | API の middleware 的な機構 |
| Frontend | API Client 的な共通処理 |
デプロイする
驚かれることが多いですが、私はアプリケーションの機能を作る前に AWS 環境にデプロイします。
- Frontend と Backend が通信できること
- 認証・認可の制御ができていること
これらを確認します。
その次に、ローカル環境での開発効率性にも目を向けます。例えば AWS Lambda で Backend が稼働するとして毎回デプロイしないと動作確認ができないとなると開発者にとっても AI にとってもフィードバックループが長くなり、厄介です。
私は Backend は Docker で開発しておき、Docker コンテナとして Lambda にデプロイする構成が好きです。これなら ECS に載せ替える必要が出てきても安心できますね。
さて、デプロイができたら以下を確認しておきましょう。
- ログは正常に出力できているか
- IAM Role によるサービス間の認可はできているか
これから開発を進めるために下地となる重要な要素です。
CI/CD の仕組みを整える
GitHub（あるいは GitLab などのリポジトリ）に Pull Request を立てると自動的に CI（lint, test）が実行される仕組みを作ります。main ブランチにマージができたらスタックをデプロイする仕組みも作っておくと幸せです。
わたしはここからさらに Pull Request ごとにテスト環境となるスタックを自動的にデプロイする仕組みまで整備しています。この仕組みがあると、リモート型のコーディングエージェントが勝手に Pull Request を作ってもすぐに人間が受け入れ確認できるので便利です。
この仕組みにより、複数の PR が並行して存在しても、それぞれ独立した環境で動作確認ができます。スマホから確認してそのままマージ、という開発フローが実現できます。
バイブコーディングを始める
ソフトウェアの骨格、構造ができたら機能を実装していく準備が整いました。
AI にとってもこの基礎があるだけで、機能を実装しやすく、誤った出力をしても CI によってガードレールが設けられているため、改善のサイクルを回しやすくなるでしょう。
バックログの管理について
ここから AI とのブレストを行いながらデータモデリングや画面設計、UI のインタラクションデザインまで幅広い機能の実装を進めていきますが、大まかに自分の頭の中で、バックログを作っておきます。
これはメモ帳に書いておいても良いですが、リポジトリにファイルとして保存はしません。AI にまだ長期的な計画は読んでほしくないからです。
最小単位の機能開発
AI に依頼する機能開発には様々な種類があります。使用するモデルにも依存しますが「これくらいなら AI に依頼してもうまくいくだろう」という感覚を身につけることが重要です。
私は機能開発の作業内容によって以下のように分けています。
| タイプ | LLM の情報 | 難易度 | 細かな指示 |
|---|---|---|---|
| 1 | 不十分 | 高い | 必要 |
| 2 | 十分 | 低い | 不要 |
| 3 | 十分 | 高い | 必要 |
| 4 | 十分 | 低い | 必要 |
タイプ 1: LLM に十分に情報がなく、難易度が高く、細かな指示を必要とする作業
これは最も難しいケースです。
例
- 新しくリリースされたばかりの AWS サービスの API を使う実装
- 社内独自のドメインロジックを含む機能
このケースでは、AI に丸投げせず、公式ドキュメントや API リファレンスをコンテキストとして渡します。「このドキュメントを読んで実装して」と指示しますが、場合によっては自分で実装した方が早いこともあります。
タイプ 2: LLM に十分に情報があり、難易度が低く、細かな指示を必要としない作業
バイブコーディングが最も輝くケースです。
例
- 「ユーザー一覧を表示するページを作って」
- 「この API にバリデーションを追加して」
といった一般的なタスクは、ほぼ一発で期待通りの結果が得られます。
このケースでは、指示を簡潔にして、AI の自律性に任せます。細かく指示しすぎると、かえって実装の柔軟性が失われることがあります。
年末に地元へ帰省してスノーボードを楽しんでいたのですが、リフトに乗っている間にスマホからリモート型のコーディングエージェントに指示を出しておき、滑り降りた頃には Pull Request が作成されてテスト環境にデプロイされていました。🏂
デプロイされた環境をスマホから動作確認して、マージする。そしてリフトに乗る。このサイクルを回すことでストレスなくソフトウェア開発に取り組めました。
スノーボード駆動開発とでも言いましょうか。ワークライフバランスも充実しますね。
タイプ 3: LLM に十分に情報があるが、難易度が高く、細かな指示を必要とする作業
例
- 複雑なビジネスロジック
- 複数のコンポーネントにまたがる機能
AI は一般的な実装パターンを知っていますが、コードベース固有の制約やパターンを理解していません。
もちろん CLAUDE.md のようなルールを整備してコンテキストに多くの情報を含めるやり方もありますが、私は最低限のコーディングルールを書く程度に留めています。
このケースでは、作業を分割します。
1. 「まず既存コードを調査して」
2. 「次に実装計画を立てて」
3. 「計画をレビューしてから実装開始」
計画段階で認識の齟齬を潰しておくことで、手戻りを減らせます。
タイプ 4: LLM に十分に情報があり、難易度が低いが、細かな指示を必要とする作業
例
- UI の微調整やスタイリング
- 特定のフォーマットに従った出力
AI は「良い感じ」に作れますが、私の「良い感じ」とは異なることがあります。
このケースでは、具体的な例やスクリーンショットを提示しましょう。
❌ 「このボタンを良い感じにして」
✅ 「このボタンの色を #3182CE にして」
✅ 「このモーダルと同じレイアウトで」
ローカル型のコーディングエージェントを使います。
Pull Request をレビューさせる
コードを書くだけが AI の仕事ではありません。レビュアーとしても優秀です。
Pull Request を作成したら、自動的に AI がレビューします。特に、以下のような観点を指摘してくれるように CI を構成しておくと、通常バイブコーディングで見落としがちな観点を補佐してくれます。
- エッジケースの考慮漏れ
- セキュリティ上の懸念
- パフォーマンスの問題
- コーディング規約違反
GitHub の PR を自動レビューしてくれるサービスとしては AWS Security Agent がおすすめです。GitHub App をインストールするだけで、PR 作成時に OWASP Top Ten の脆弱性や組織のセキュリティポリシー違反を自動検出してコメントしてくれます。
リファクタリングのタイミング
バイブコーディングを続けていると、気づけばファイルが肥大化し、責務が曖昧になっていることがあります。これは避けられません。AI は「今この機能を動かす」ことに集中するため、長期的なコードの健全性は二の次になりがちです。
700 行を超えたらリファクタリング
私の経験則として、1 ファイルが 700 行を超えたらリファクタリングを検討します。
実際に packages/agent/index.ts が 705 行になったとき、AI に依頼して 15 の独立したモジュールに分割しました。
Before: index.ts (705行)
↓
After: 15 modules
├── agent-executor.ts
├── message-handler.ts
├── tool-manager.ts
└── ... (12 files)
もちろん常にリファクタリングの心を持ってコーディングすべきですが、目安として覚えておくと良いでしょう。
デバッグとの向き合い方
AI が生成したコードが動かないことは日常茶飯事です。エラーメッセージをそのまま貼り付けて「これを直して」と依頼するのが基本ですが、いくつかコツがあります。
エラーの文脈を伝える
「このエラーが出た」だけでなく、以下の情報を伝えましょう。
| 情報 | 例 |
|---|---|
| 何をしようとしていたか | 「ユーザー登録機能をテストしていた」 |
| どういう操作をしたか | 「フォームに入力して送信ボタンを押した」 |
| どのエラーが出たか | 「TypeError: Cannot read property...」 |
AI はエラーメッセージだけでなく、再現手順から問題の本質を推測できます。また、エラーになっている箇所のコードにあたりがつけられれば該当箇所のコードも指摘しましょう。
仮説を立てさせる
「このエラーの原因として考えられることを 3 つ挙げて」と依頼すると、AI は複数の可能性を検討してくれます。その中から最も可能性が高いものを選び、検証を進めます。
いきなり修正を試みるより、仮説検証のサイクルを回す方が効率的なことが多いです。
人間が担う責務
バイブコーディングにおいて、AI に任せられることは増えましたが、人間が担うべき責務は依然として存在します。
プロダクトの方向性を決める
何を作るか、誰のために作るか、何を優先するか。これらの判断は AI には委ねられません。
品質の最終責任を持つ
AI が生成したコードをレビューし、本番環境にデプロイする判断を下すのは人間です。
ユーザーの声を聞く
実際にアプリを使うユーザーからのフィードバックを収集し、次の開発に活かすのは人間の仕事です。AI はユーザーインタビューを代行できません。
まとめ
本記事ではバイブコーディングの実践テクニックについてご紹介しました。
| フェーズ | ポイント |
|---|---|
| 始める前に | 誰が幸せになるかを考える |
| 骨格づくり | ディレクトリ構成、CI/CD、認証認可を先に |
| デプロイ | 機能実装前に AWS 環境へデプロイ |
| 機能開発 | タスクの種類に応じてアプローチを変える |
| レビュー | AI をレビュアーとしても活用 |
| リファクタリング | 700 行超えたら分割を検討 |
| デバッグ | 文脈を伝え、仮説を立てさせる |
| 人間の責務 | 方向性、品質、ユーザーの声 |
バイブコーディングは、ソフトウェア開発の新しいスタイルですが、その本質は変わりません。良いソフトウェアを作るためには、良い設計、良いテスト、良いデプロイ、良いフィードバックループが必要です。AI はそれらを加速するツールであり、代替するものではありません。
私がバイブコーディングで最も大切にしていることは「AI との信頼関係を築く」ことです。AI の得意なことを理解し、苦手なことを補い、適切なコンテキストを与え、適切なフィードバックを返す。この繰り返しが、バイブコーディングの真髄だと思います。
制作過程
この記事の制作過程をツイートしています。よろしければご覧ください。
Discussion