はじめに
本記事は、Tech-Verse 2025で発表予定の内容を詳しくまとめたものです。個人の実践経験をもとに、AIコーディングの現場で得た知見や手法を紹介します。
AIコーディングを進めるにあたり、私は「Lean & Mean Teams（少数精鋭のチーム）」というLINEヤフーのバリューから大きなインスピレーションを受けています。少人数の開発チームがAIエージェントと緊密に協調し、開発期間を短縮しつつ品質を守る体制を目指すことが、私自身のAIコーディング戦略の中心です。高い技術力を土台に、信頼性の高いAIパイプラインの設計と実装を心がけています。
とはいえ、数行のプロンプトでプロトタイプ が動く “Vibe Coding” の甘い誘惑は、テクニカルデットやバグを招きがちです。本稿では「速いけれど雑」を回避するため、私自身の実戦経験から得た8つのプラクティスを紹介します。タスクの AI-friendly な細分化、コンテキスト管理、超短サイクルのテストループなどを通じて、AI を気まぐれなインターンではなく規律あるチームメイトへと昇華させ、速くクリーンで長持ちするソフトウェアを実現しましょう。
Vibe Codingとは？
あなたはタインという開発者で、プロジェクト管理アプリを作るよう依頼されたと想像してください。ChatGPT（またはお好きなAI）に「Reactでプロジェクト管理アプリを書いてください」と入力すると、1時間ほどでプロトタイプが完成します。まるでAIがすべてを自動で実装してくれるような感覚です。これが「Vibe Coding」です。インスピレーションに任せて高速に開発を進め、AIが生成したコードを十分に確認せずに進めてしまう開発スタイルを指します。
しかし、必ずしもすべてが順調に進むわけではありません。Simon Willisonの定義によれば、「Vibe Coding」とはLLMを使ってソフトウェアを構築しながら、その生成物を十分に吟味しないことを指します。その結果、コードベースが構造化されず、場当たり的な実装が増えてしまいます。顧客から機能追加の要望があった際、どこから手を付ければよいか分からず、対応に苦慮することも あります。
「Vibe Coding」が必ずしも悪いというわけではありません。短時間でプロトタイプを作成でき、従来よりも大幅に効率化できる場合もあります。Steve Yeggeが「Revenge of the Junior Developer」で指摘しているように、vibe codingは「従来のプログラミングより5倍効率的」になることもあり（と主張しています）、coding agentなどの登場によって今後も広がっていくと考えられます[1]。しかし、その一方でリスクも存在します。CSET（2024年11月）のレポートによれば、AIが生成したコードの約半数にバグや脆弱性が含まれていました。スピードを重視するあまり、基礎知識が不足していると、セキュリティ上の問題を引き起こす可能性があります。Addy Osmaniも「A Field Guide to Responsible AI-Assisted Development」で「品質が伴わなければ、いくら速くても意味がない」と強調し、vibe codingを低品質の言い訳にすべきではないと述べています[2]。
それでは、スピードを維持しつつ品質も確保するにはどうすればよいのでしょうか。その答えが「AIを用いたプロフェッショナル開発」です。
AI を用いたプロフェッショナル開発
次に登場するのはタンという開発者です。タンはタインのように焦らず、計画を立ててアーキテクチャを設計し、スクラムマスターのようにスプリントを分割します。その結果、2週間後には拡張や保守が容易な堅牢なプロダクトを完成させました。最初は時間がかかるように感じても、価値あるものは時間をかけて作るべきだと考えます。
AIを使ったプロフェッショ ナル開発は「Vibe Coding」と何が違うのでしょうか。AIをただ使うのではなく、しっかりと制御して活用することが重要です。私がまとめる2つの基盤マインドセットを意識してください：
- Trust the Process（プロセスを信じる）：AIは明確なプロセスに組み込まれたときに最も力を発揮します。AIを自由に使うのではなく、進むべき「地図」を与えることが大切です。
- AI as Teammate（AIを仲間として）：AIはあなたの代わりではなく、同僚です。チームメイトと同じように、アウトプットを評価・調整しながら協力して進めましょう。
この考え方はAnthropicのCPO、Mike Kriegerも支持しています。彼は将来の開発者がコードを書くよりも「AIオーケストレーター」としてAIを調整し、システムを設計し、品質を保証する役割へ移行すると述べています。AnthropicではPMとAI研究者を組ませることで効果が10倍に向上し、人とAIが同僚として協働する重要性が示されました[3]。
AIが仲間になる様子を示したのが次の図です：
この図ではあなた（Product Owner）が方向性を示し、AIが要件定義・調査・コーディングなどを担当します。重要なのはフィードバックループが存在し、あなたとAIが共に評価・調整する点です。まさに“AI as Teammate”の精神です。
8 つのプラクティス
マインドセットがわかったところで、“Vibe Coding”からAIプロフェッショナル開発へ進化するための8つのプラクティスを、ソフトウェア開発でよく使われる4段階（Preparation, Planning, Development, Troubleshooting）に分けて紹介します。
Preparation
準備段階は家の土台作りに似ています。基礎が弱ければすべてが崩れてしまいます。まず2つのプラクティスから始めましょう。
Practice 1: 複数 AI ツールの協調
単一のAIに頼らず、各AIに固有の役割を与えたパイプラインを構築しましょう。例：
- Reasoning AI：要件、設計、実装ガイドを作成
- Internet Search AI：フレームワークの最新情報やコミュニティの知見を検索
- Coding AI Agent：コードを書くことに専念
あるAIのアウトプットを次のAIのインプットにし、一貫性と品質を担保します。個人の力よりもチームワークが重要です。この考え方はSteve Yeggeが「agent clusters（エージェント・クラスター：AIエージェントの集団）」「agent fleets（エージェント・フリート：AIエージェントの艦隊）」の登場を予測した際にも支持されています[1]。
Practice 2: 詳細な要件準備
要件はAIのロードマップです。地図が曖昧だとAIはバグの多い実装に導いてしまいます。AIをブレスト相手にし、同僚のように会話して初期要件の抜けや視点を発見しましょう。この詳細な要件作成プロセスについては、後日公開予定のブログ記事で詳しく解説する予定です。Addy Osmaniも、AIは実装を助けるべきで基礎アーキテクチャを決めるのは人間であるべきと強調し、要件を明確に定義する重要性を説いています[2]。
この段階のマインドセットは“Preparation is the foundation of success”です。急がず、チームを組み、作りたいものを明確にしましょう。
Planning
計画段階は「何をやるか」を具体化する時期です。スクラムで言えばスプリントプランニングにあたります。次の2つのプラクティスを紹介します。
Practice 3: AI 向けタスク分割
AIは小さく独立したタスクで最も力を発揮します。「AI-friendly tasks」のルールで分割しましょう：
- 各タスクは100～200行以内
- 入力／出力が明確
- 他タスクへの依存が少ない
- 検証用テストケースがある
タスクリストと実装プランはソースのフォルダに保存し、Coding Agentがコンテキストを把握できるようにします。Steve Yeggeも大きなタスクを与えるとエージェントが「壁に頭突きする（行き詰まる）」と警告しています[1]。
Practice 4: Implementation Rule の設定
AI用の「社内ハンドブック」、Implementation Ruleを作成しましょう。コーディング規約、推奨パターン、ワークフローを定義します。AIに明確なルールがあれば、推測せずビジネスロジックに集中できます。Addy Osmaniも標準化を推奨し、AIの生成コードを統合前に必ず整形・調整すべきと述べています[2]。マインドセットは“Structure enables creativity”です。良い構造は制約ではなく、創造性を引き出します。
Development
DevelopmentはあなたとAIがアイデアを現実にする段階です。重要な2つのプラクティスを紹介します。
Practice 5: Edit-Test ループ
Edit-TestループはAIと協力する上で最も効率的な方法です。各サイクルは15～30分です：
- 小さなインクリメントを決定（15～30分）
- そのインクリメント用の失敗テストを書く
- AIにテストを通過するコードを実装させる
- AIが自動でテスト実行
- 失敗ならAIが解析し修正、成功ならレビューしてコミット
Addy OsmaniはAI生成コードの徹底テストを推奨し[2]、Mike KriegerはAnthropicでAIが他のAIのコードをレビューし、人間は受け入れテストのみ行う事例を紹介しています[3]。
図は短いループで進捗を管理する様子を示しています。マインドセットは“Small iterations（小さな反復）、continuous feedback（継続的なフィードバック）”です。AIに過度な負担をかけず、一歩ずつ進めましょう。
Practice 6: コンテキスト管理
コンテキストはAIの「記憶」です。長すぎるとAIは「混乱」し一貫性を欠きます。管理方法：
- ファイルを@参照で追 加
- 50～100メッセージを超えたら新チャット開始
- コードベースを頻繁に同期
- Gitコミットをチェックポイントに
- セッション後にサマリーを作成
Troubleshooting
AIは完璧ではありません。問題を解決できず行き詰まることもあります。慌てず次の2つのプラクティスを実践しましょう。
Practice 7: Problem Report System
AIが行き詰まったら、状態・エラーメッセージ・試した解決策を含むProblem Reportを生成させます。それを別のSearch AIに渡して新たな視点を得ましょう。Addy Osmaniも反復利用や、場合によってはAIを諦め自分で書く柔軟さを勧めています[2]。
Practice 8: Context Reset Strategy
混乱が極まったら「リセット」しましょう。リセットはAIが誤った方向へ進んだ際の緊急ブレーキです。目安は会話が100メッセージを超えた、ハルシネーション（hallucination：AIが事実と異なる出力や誤った情報を生成する現象）が増えた、無限ループした時です。効果的なリセットは進捗をProblem Reportにまとめ、新しいクリーンなコンテキストで始めることです。
マインドセットは“Systematic beats random（体系的なアプローチが偶然に勝る）”です。行き当たりばったりではなく、文書化・分析・相談・構造的アプローチで進めましょう。
Trust The Process
AIとの全プロセスを俯瞰する「Trust the Process」図をご覧ください。PreparationからTroubleshootingまでの流れを網羅しています。
図が示す通り、AI中心ではなくプロセス中心です。明確なフレームワークの中でAIは実行ツールに過ぎません。コンテキストは保存・再利用され、AIが常に十分な情報で働けるようにします。Mike KriegerもAIがコードの90～95%を生成するAnthropicで、ボトルネックが機能決定やマージキューに移ったと指摘し、プロセス再設計の必要性を説いています[3]。
結び
ソフトウェア開発は新しい時代に突入しました。AIは受動的なツールではなく、一行一行のコードを共に書くパートナーです。ここで立ち止まり、私たちが長年どのように協働してきたかを振り返りましょう。
開発チームを作る際、人を集めて「何か面白いことをしてほしい」とは言いません。代わりに適材適所を行います。UIはフロントエンド、APIはバックエンド、インフラはDevOps。入力と出力を明確に定義し、デザイナーがモックをフロントエンドに、フロントエンドがAPIスペックをバックエンドに渡します。そして何より、各メンバーのア ウトプットを早期にレビューします。コードレビュー、デイリースタンドアップ、スプリントデモなど、誰もフィードバックなしに「自由に創造」することはありません。
AIとの仕事も同じです。AIにすべてを任せて解決してもらうことはできません。新人開発者をオンボードするように丁寧に手順を示し、同僚のコードをレビューするように各AIのアウトプットを調整する必要があります。「AIチーム」の各メンバーに明確な役割と入力/出力を与え、その成果は次工程へ進む前に厳しくチェックします。正しいアプローチを取れば、AIは得意分野で人間より速く、質の高いアウトプットを生み出せます。そして各「AIメンバー」が有効に機能すれば、プロジェクト全体のアウトプットも大幅に向上します。
効果的に協働するために、2つのマインドセットを忘れないでください：Trust the ProcessとAI as Teammate。プロセスを信じ、計画・テスト・継続的改善に時間を投資しましょう。AIを真の同僚として扱い、目標を共有し、フィードバックし、共に問題を解決しましょう。
AIで成功できるかどうかは、あなたが最高にコードを書く能力ではなく、チームとプロセスをマネジメントするスキルにかかっています。上記の8つのプラクティスを試せば、コードを書くスピードが上がるだけでなく、課題をより深く捉え、より効果的に解決できる自分に気づくでしょう。Steve Yeggeが言うように、「AIがあなたより賢いことを証明する必要はない。あなたがAIによって賢くなるべきだ」[1]。彼はまた、開発者の役割が「agent fleets（エージェント・フリート）」を管理する方向へシフトすると予測しており、適応できない者は取り残されると指摘しています。特に、AIを素早く受け入れている開発者に対し、AIを回避する開発者が後れを取る危険があります（Sourcegraph Blog）。あなたはAIオーケストレーターとして、AIのエコシステム全体を調整する準備ができているでしょうか。
さあ、今日から始めましょう。AIとの旅は人間と働くのと同じで、計画が必要で、協調が必要で、そして忍耐も必要です。楽しいコーディングを！
参考文献
[1] Steve Yegge. "Revenge of the Junior Developer". Sourcegraph Blog. https://sourcegraph.com/blog/revenge-of-the-junior-developer
[2] Addy Osmani. "A Field Guide to Responsible AI-Assisted Development". Addy Osmani Blog. https://addyo.substack.com/p/vibe-coding-is-not-an-excuse-for
[3] Mike Krieger. "Interview with Mike Krieger". Video. https://www.youtube.com/watch?v=DKrBGOFs0GY
