【Vibe Coding実践③】"自分に合ったやり方"が見つかるペルソナ別活用ガイド
この記事のまとめ
- 3つのペルソナ（プログラミング経験者・SE未経験者・非SE）別に最適なVibe Codingアプローチを整理
- 実施者のスキルに応じてサポート体制・品質担保方法が異なる
- 実践①・実践②の実事例に基づく実践的なガイドライン
対象読者
- Vibe Codingを始めたいが、自分に合ったやり方が分からない方
- チームメンバーにVibe Codingを導入したいリーダー・マネージャー
- 実践①（非プログラマ編）・実践②（ドキュメント駆動編）を読んだ方
前回までのおさらい
本シリーズでは、2つの実事例を通じてVibe Codingの可能性と課題を検証してきました。
実践①: 非プログラマのVibe Coding
実践①の記事では、プログラミング未経験のSEがChatGPT + Codex CLIを使い、
業務の合間10日間で2600行超のJavaバッチツールを完成させた事例を紹介しました。
| 項目 | 結果 |
|---|---|
| 実施者 | プログラミング未経験SE |
| アプローチ | 継ぎ足しスタイル |
| コード行数 | 2633行（App.java単一ファイル） |
| テスト | なし |
| 結論 | 動くけど保守できない |
AIとの逐次的な対話で機能を追加していく「継ぎ足しスタイル」は、速くて手軽。しかし全体設計がないまま機能が積み重なり、2600行が1ファイルに集中する構造になりました。
実践②: ドキュメント駆動型Vibe Coding
実践②の記事では、筆者自身がドキュメント駆動型Vibe Codingで
25時間・8900行のSpring Bootアプリを開発した事例を紹介しました。
| 項目 | 結果 |
|---|---|
| 実施者 | プログラミング経験者 |
| アプローチ | ドキュメント駆動 |
| コード行数 | 約8900行（31ソース + 19テスト） |
| テスト | 125件（成功率100%） |
| 結論 | 設計書がAI出力の品質を決める |
実装前に設計ドキュメントを整備し、それをAIの「プロンプト」として参照させることで、意図通りのコードが一発で生成されました。
2つの事例から見えたこと
この2つの事例を並べて気づくのは、成果の違いはツールの違いではなく、実施者のスキルとアプローチの違いに起因するということです。
つまり、Vibe Codingの「正解」は一つではない。実施者のスキルレベルに応じて、最適なアプローチを選ぶべきなのです。
本記事では、この知見を体系化し、3つのペルソナ別にVibe Codingの活用ガイドラインを提示します。
3つのペルソナ定義
まず、Vibe Codingの実施者を3つのタイプに分類します。
| タイプ | 定義 | 典型的な職種 | 本シリーズとの対応 |
|---|---|---|---|
| プログラミング経験者 | コードを読み書きできる開発者 | アプリケーションエンジニア、テックリード | 実践②の実施者 |
| SEのプログラミング未経験者 | IT業界でPM・設計・テスト等を担当（コードは書かない） | PM、業務SE、テスト担当 | 実践①の実施者に近い |
| 非SE | IT業界外の業務担当者 | 営業、事務、企画、マーケティング | 考察から導出 |
プログラミング経験者向けガイド
アプローチ: ドキュメント駆動型の完全自律開発
プログラミング経験者にとってのVibe Codingは、「コードを書く」作業をAIに委譲し、自分は設計と品質管理に集中するスタイルです。
実践②の事例で実証されたように、ドキュメント駆動型であれば設計からテストまで一人で完結できます。
フェーズ別の進め方
| フェーズ | 実施方法 | AIの役割 | 開発経験者のサポート |
|---|---|---|---|
| 要件定義 | 自身で作成 | レビュー・補完 | 不要 |
| 設計 | 自身で作成（詳細設計書、処理フロー） | 設計案の提示、整合性チェック | 不要 |
| 実装 | AIに委譲 | コード生成 | 不要 |
| テスト | テスト設計は自身、実装はAI | テストコード生成・実行 | 不要 |
| 品質管理 | 自身でレビュー・修正 | 問題箇所の特定・修正提案 | 不要 |
具体的なシナリオ
シナリオ: 社内の業務自動化ツールを新規開発する
- 要件定義: 業務フローを分析し、自動化したい範囲をMarkdownで整理。ChatGPTに壁打ちして要件を構造化
- 設計: パッケージ構成、クラス設計、処理フローを設計書として作成。技術選定（Spring Boot、JPA等）は自身の知識で判断
- 実装: 設計書をClaude Codeに参照させ、一括でコードを生成。生成結果をレビューし、必要に応じて修正指示
- テスト: テスト戦略（単体・結合・E2E）を策定し、AIにテストコードを生成させる。カバレッジを確認して不足分を追加
- 品質管理: 生成コードの構造・命名・エラーハンドリングをレビュー。セキュリティ観点も自身でチェック
成功のポイント
- 設計書の粒度にこだわる — AIが実装可能な詳細度まで記述する。クラス名・メソッド名まで定義すれば、命名の揺らぎがなくなる
- 技術選定を明示的に指定する — 「Spring Boot 3.x + JPA + H2」のように具体的に。曖昧にすると、AIが対話のたびに異なるライブラリを選ぶ
- 反復的にフィードバックする — AI出力をレビューし、設計書にフィードバックして改善する。一発完成を目指さない
- 品質ゲートを設ける — 「テストカバレッジ80%以上」「全テスト成功」など、次フェーズに進む基準を事前に決めておく
実践②事例のデータが示す根拠
| 指標 | 結果 |
|---|---|
| 設計投資 | 約10時間（全体の40%） |
| 実装速度 | 約4800行が瞬時に生成 |
| テスト成功率 | 125件中125件成功 |
| リトライ頻度 | ほぼゼロ（設計書参照で一発生成） |
設計に40%の時間を投資したことで、実装フェーズの試行錯誤がほぼゼロになりました。「急がば回れ」が数字で証明された事例です。
SEのプログラミング未経験者向けガイド
アプローチ: 上流工程主導型のハイブリッド開発
SEのプログラミング未経験者は、要件定義・設計という上流工程のスキルを活かせるのが強みです。
ただし、生成されたコードの品質を自力で判断するのが難しいため、実装以降は開発経験者のサポートを組み合わせる「ハイブリッド開発」が最適です。
フェーズ別の進め方
| フェーズ | 実施方法 | AIの役割 | 開発経験者のサポート |
|---|---|---|---|
| 要件定義 | 自身で作成 | レビュー・補完 | 不要 |
| 設計 | 自身で作成 | 設計案の提示 | 技術選定時に推奨 |
| 実装 | AIに委譲 | コード生成 | コードレビュー必須 |
| テスト | テスト設計は自身、実装はAI | テストコード生成 | 結果判断時に推奨 |
| 品質管理 | 開発経験者と協働 | 問題箇所の特定 | 必須 |
具体的なシナリオ
シナリオ: 担当プロジェクトのレポート生成ツールを作りたい
-
要件定義: 「CSVを読み込んで、部門別にExcelレポートを生成したい」「月次で使う」
「他のメンバーも使えるようにしたい」 — 業務知識を活かして要件を明確化 -
設計: AIと対話しながら設計書を作成。
「どんなクラス構成がいい？」「ライブラリは何を使うべき？」とAIに相談。技術選定の妥当性は開発経験者に確認 - 実装: 設計書をAIに参照させてコードを生成。動かしてみて、期待通りに動くか確認
-
テスト: 「このCSVを読み込んだらこういうExcelができるはず」という業務シナリオでテストを設計。
実行結果は開発経験者と一緒に確認 - 品質管理: 開発経験者にコードレビューを依頼。構造や品質の問題があれば、AIに修正を指示
成功のポイント
- 設計書テンプレートを活用する — ゼロから設計書を書くのは難しい。実践②事例の設計書構造（要件定義書→基本設計書→詳細設計書→処理フロー図）をテンプレートとして参考にする
- 技術選定は開発経験者に相談する — フレームワークやライブラリの選定は、実装経験がないと妥当性を判断できない。「AIがこれを勧めてきたけど、どう思う？」と聞く
- 定期的に開発経験者のレビューを受ける — 実装が進んでからまとめてレビューすると、手戻りが大きくなる。こまめにチェックポイントを設ける
- テスト重視で品質を担保する — コードが読めなくても、「この入力に対してこの出力が出るべき」というテストは設計できる。業務知識を活かしたテスト設計が品質の鍵
実践①事例の経験を踏まえた改善提案
実践①の事例では、以下の問題が発生しました。
| 実践①で起きた問題 | 原因 | 改善策 |
|---|---|---|
| 2600行が1ファイルに集中 | 全体設計なしに機能を継ぎ足した | 事前に設計書を作成する |
| デグレが頻発 | テストなしで機能追加 | テストファーストで進める |
| コードの意味が分からない | コードを理解する機会がなかった | AIに「このコードの意味を教えて」と聞く習慣をつける |
| 品質への不安 | 判断基準を持っていなかった | 開発経験者のレビューを組み込む |
これらの改善策を最初から組み込むことで、実践①の課題を回避できます。
非SE向けガイド
アプローチ: 要件言語化型のプロトタイピング開発
非SEの最大の強みは業務知識です。「何を実現したいか」を最もよく知っているのは、現場の業務担当者です。
Vibe Codingを使えば、その業務知識を直接プロトタイプに変換できます。ただし、設計以降の技術的な工程には開発経験者のサポートが必須です。
フェーズ別の進め方
| フェーズ | 実施方法 | AIの役割 | 開発経験者のサポート |
|---|---|---|---|
| 要件定義 | 業務視点で記述 | 要件の構造化支援 | 推奨 |
| 設計 | AIと対話的に作成 | 設計書生成 | 必須 |
| 実装 | AIに委譲 | コード生成 | 必須 |
| テスト | 業務シナリオの提供 | テスト実行 | 必須 |
| 品質管理 | 開発経験者に委譲 | 問題箇所の特定 | 必須 |
具体的なシナリオ
シナリオ: 営業部門の月次レポート作成を自動化したい
- 要件定義: 「毎月、売上CSVをExcelに貼り付けてグラフを作っている。これを自動化したい」「部門別・製品別の集計が必要」「上司に提出するフォーマットが決まっている」— 業務フローと要望を自然言語で記述
- 設計: AIに「この要件を実現するにはどうすればいい？」と相談。AIが設計案を出してくれるが、その妥当性は開発経験者に確認してもらう
- 実装: 開発経験者のサポートのもと、AIにコードを生成させる。「動くかどうか」の確認は自分でもできる
- テスト: 「先月のCSVを入力して、正しいExcelが出力されるか」を確認。業務観点でのテストは自分が最も適任
- 品質管理: 開発経験者に品質面を確認してもらう。自分は「業務要件を満たしているか」の最終確認を担当
推奨される用途
非SEがVibe Codingを活用する場合、以下のような用途が特に適しています。
| 用途 | 具体例 | 理由 |
|---|---|---|
| 小規模ツール | CSV変換、レポート生成、ファイル整理 | 単機能で検証が容易 |
| プロトタイプ | 業務フローの自動化案を可視化 | 完成度より「動くイメージ」が重要 |
| モックアップ | IT部門への要件伝達用デモ | 言葉だけでは伝わらない要件を具体化 |
成功のポイント
- 業務要件の言語化に注力する — 「何を実現したいか」を具体的に記述する。「便利なツール」ではなく、「毎月のCSVを読み込んで、部門別集計のExcelを出力するツール」のように具体化する
- サポート体制を事前に確保する — 設計以降は開発経験者のサポートが必須。始める前に「困ったら相談できる人」を確保しておく
- スコープを限定する — 最初から大きなものを作ろうとしない。「まず1つの機能だけ」から始めて、成功体験を積む
- AIとの対話を通じて学ぶ — Vibe Codingの過程で「変数」「関数」「ファイル構成」といったIT用語に自然と触れる。これは学習機会でもある
ペルソナ別比較表
3つのペルソナを横断的に比較します。
総合比較
| 観点 | プログラミング経験者 | SEのプログラミング未経験者 | 非SE |
|---|---|---|---|
| 推奨アプローチ | ドキュメント駆動型 | 上流工程主導型 | 要件言語化型 |
| AIで対応できる工程 | 全工程 | 要件定義〜設計 | 要件の言語化のみ |
| 開発経験者の支援が必要な工程 | なし | 実装レビュー、品質管理 | 設計以降の全工程 |
| 推奨用途 | プロトタイプ〜本番システム | プロトタイプ〜小規模システム | 小規模ツール、プロトタイプ |
| 品質の守り方 | 自身でレビュー・修正 | テスト重視＋開発経験者レビュー | 開発経験者による品質保証 |
| 始めるまでのハードル | 低 （既存スキルを転用） |
中 （設計書テンプレート習得） |
高 （IT基礎概念の習得） |
| 活かせるスキル | 設計力、コードレビュー力 | 要件定義力、テスト設計力 | 業務知識、要件の言語化力 |
アプローチ選択フローチャート
自分がどのアプローチを取るべきか迷ったら、以下のフローで判断できます。
導入判断のポイント
ペルソナに合ったアプローチを選んだ上で、Vibe Codingの導入を判断する際に検討すべき3つの観点を整理します。
1. ドキュメント整備体制
実践②の事例で明らかになった通り、ドキュメントの品質がAI出力の品質を直接左右します。
| 状況 | 判断 |
|---|---|
| 質の高い設計書を書ける人材がいる | ドキュメント駆動型が有効 |
| ドキュメント文化が根付いていない | まず継ぎ足しスタイルで小さく始める |
| ドキュメントはあるが、形骸化している | 「AIに読ませる」前提で書き直す |
ドキュメント駆動型では、設計書が「AIへの一貫したプロンプト」として機能します。
つまり、ドキュメントを書く力がそのままAI活用力になるのです。
2. 実施者のスキルレベル見極め
実施者のスキルを正確に把握し、適切なサポート体制を用意することが重要です。
| 見極めポイント | 確認方法 |
|---|---|
| コードを読めるか | 簡単なコードスニペットを見せて意味を聞く |
| 設計書を書けるか | 要件を渡して設計書を書いてもらう |
| 問題を言語化できるか | エラーが起きたときの報告の的確さを見る |
| AIとの対話力 | 「何を、どう伝えるか」の精度を確認 |
特に3つ目の「問題を言語化できるか」は、ペルソナを問わず重要なスキルです。
実践②の事例でも、ドキュメント駆動の真の価値は「完璧な事前設計」ではなく、問題が起きたときに的確にAIに伝えるための基盤を持つことでした。
3. プロジェクト特性との適合
すべてのプロジェクトがVibe Codingに向いているわけではありません。
| プロジェクト特性 | Vibe Codingとの相性 | 理由 |
|---|---|---|
| 新規の小中規模開発 | 高い | AIが全体を把握しやすい |
| 個人の業務効率化ツール | 高い | 小さく始めて改善できる |
| AIの学習データが豊富な技術 | 高い | Java、Python、TypeScript等 |
| 大規模プロジェクト（数万行以上） | 低い | AIのコンテキスト制限に抵触 |
| マイナーな技術スタック | 低い | AI出力の品質が低下 |
| 高度なセキュリティ要件 | 要注意 | 人間による厳格なレビューが必須 |
まとめ
シリーズ全体の振り返り
本シリーズでは、3回にわたってVibe Codingの実態を多角的に検証しました。
| 回 | テーマ | 主要な知見 |
|---|---|---|
| 実践① | 非プログラマのVibe Coding | 「動くけど保守できない」— 継ぎ足しスタイルの限界 |
| 実践② | ドキュメント駆動型Vibe Coding | 「ドキュメント ≈ プロンプト」— 設計書がAI出力の品質を決める |
| 本記事 | ペルソナ別活用ガイド | 「正解はスキルで変わる」— 実施者に合ったアプローチ選択が鍵 |
「自分はどうVibe Codingと向き合うべきか」
最後に、ペルソナ別の判断基準をまとめます。
プログラミング経験者なら —
ドキュメント駆動型で「コードを書く」から「設計と品質管理に集中する」へ役割をシフトしましょう。
AIは優秀な実装者ですが、設計判断と品質保証は人間の仕事です。
SEのプログラミング未経験者なら —
上流工程のスキルはそのまま活かせます。
設計書を書いてAIに渡す。ただし、コードの品質チェックは開発経験者の力を借りましょう。
あなたの設計力とAIの実装力の組み合わせは、思った以上に強力です。
非SEなら —
まずは小さなツールから。業務知識を活かして「何を実現したいか」を明確にすることに集中しましょう。
技術的な部分はAIと開発経験者に任せれば大丈夫です。動くプロトタイプを作れるだけで、IT部門とのコミュニケーションが劇的に変わります。
Vibe Codingは「ゴール」ではなく「スタート地点」
実践①の記事で書いた言葉を、シリーズの締めくくりとしてもう一度。
Vibe Codingは、プログラミングへの入口として非常に有効です。AIが心理的障壁を大幅に下げてくれます。
しかし、「AIがあればプログラミングを学ばなくていい」わけではないことも、
3回の検証を通じて明らかになりました。Vibe Codingで作ったものを長く使い、
育てていくためには、設計の知識、品質管理の手法、そして問題をAIに的確に伝える力が必要です。
ペルソナに応じたアプローチを選び、自分のスキルを活かしながら、Vibe Codingという新しいスタート地点から一歩を踏み出してみてください。
Discussion