ソフトウェア保守をVibe Codingで段階的に内製化するためのPromptと実践チュートリアル
背景
生成AIやVibe Codingの話をしていると、どうしても「どこまでコードを書けるか」に議論が寄りがちです。
もちろん、実装支援は分かりやすい価値です。一方で、実務のソフトウェア保守を見ていると、コードを書く時間だけがボトルネックとは限りません。障害の状況を整理し、既存仕様を確認し、影響範囲を調べ、関係者へ質問し、テスト計画を作り、承認に必要な材料をそろえる。こうした前後の工程に、かなりの時間が使われています。
特に外部ベンダーへ保守を委託している現場では、小さな調査や軽微な改善であっても、依頼、説明、見積もり、日程調整、受入確認が必要です。その結果、変更そのものは小さいのに、完了まで数日から数週間かかることがあります。
たとえば、調査結果の整理、仕様のたたき台、テストケース、変更計画、Pull Requestの初稿までを社内で進め、業務判断やセキュリティ判断、本番反映は人が担う。この形であれば、既存の統制を維持しながら、保守の一部を段階的に社内へ戻せます。
この記事では、そのためのPromptと、4つの保守シナリオを使ったチュートリアルをまとめます。
注意点 / 前提
最初に前提を置きます。
この記事は、私が実務でソフトウェア保守と生成AI活用を考える際の整理です。すべての企業、システム、契約形態にそのまま当てはまるものではありません。
また、ここで扱うVibe Codingは、AIへ本番変更を自動委任する考え方ではありません。AIは調査、仕様化、計画、実装、テスト、レビュー、文書化を支援しますが、業務仕様、セキュリティ、データ、本番反映、リリース可否に関する最終判断は人が行う前提です。
プロダクション利用では、少なくとも次の点を個別に確認する必要があります。
- 利用するAIサービスへ入力できる情報の範囲
- ソースコード、ログ、個人情報、機密情報の取り扱い
- リポジトリ権限とブランチ保護
- Pull Requestレビューと品質ゲート
- 監査証跡、承認記録、ロールバック手順
- 外部ベンダーとの契約、責任分界、知的財産の扱い
万能ではありません。まずは低リスクで、結果をテストや画面で確認しやすい作業から始めるのが現実的です。
整理・考え方
ここで一度、整理してみます。
Vibe Codingを「コード生成」だけに限定しない
ソフトウェア保守では、実装前の調査と、実装後の検証が重要です。
AIにコードだけを書かせても、前提となる業務ルールが曖昧であれば、動作するコードはできても、本番品質には届きません。逆に、Research、Spec、Planの段階で不足情報を明確にし、Human Approvalを置くことで、AIが勝手に仕様を補完するリスクを下げられます。
この記事では、Vibe Codingを次の一連の作業として扱います。
- Research: 現象、ログ、コード、設計書、履歴を調べる
- Spec: 現状、期待状態、業務ルール、受入条件を整理する
- Plan: 変更範囲、実装方法、テスト、ロールバックを計画する
- Human Approval: 人が仕様と計画を承認する
- Implement: 小さな単位で実装する
- Verify: テスト、静的解析、差分、残存リスクを確認する
- Release Approval: 人が本番反映を承認する
内製化は、外部ベンダーを全面的に外すことではない
現場では話が変わることが多いです。
重大障害、認証基盤、大規模移行、法規制対応などは、専門家や第三者レビューが必要です。そこまで社内だけで抱える必要はありません。一方で、一次調査、影響範囲整理、テスト追加、小規模改善、ドキュメント更新などは、社内で進めやすい領域です。
つまり、内製化の対象は「契約単位」ではなく「作業単位」で考えた方が整理しやすくなります。
何が問題で、何が問題ではないか
問題になりやすいのは、入力情報が不足したまま仕様を決めること、変更範囲を限定しないこと、テストで確認できないこと、本番反映まで自動化することです。
反対に、対象と完了条件を明確にし、変更を小さく分け、人の承認とレビューを維持できるのであれば、AIを使うこと自体は既存の開発支援ツールと大きく矛盾しません。
この前提で、実際に使えるPromptへ落としていきます。
本文
ソフトウェア保守の内製化ユースケースを設計するPrompt
以下は、ソフトウェア保守作業のうち、Vibe Codingを使って段階的に内製化できるユースケースを設計するためのPromptです。
狙いは、「AIにコードを書かせる」だけの提案を出すことではありません。業務担当者、プロダクト担当者、社内エンジニアが主体となり、AIを調査、計画、実装、検証の各工程で使いながら、本番反映や重要判断は人が行う業務モデルを設計させます。
想定する使い方
- AIには、エンタープライズ企業のソフトウェア保守を支援するシニアコンサルタント兼ソフトウェアアーキテクトとして振る舞わせます。長文かつ構造化された出力を扱えるツールが向いています。
- Prompt内の
[ ]で囲まれたプレースホルダーを、実際の企業、部門、対象システム、外部委託作業の情報へ置き換えます。 - 分からない項目は架空の情報で埋めません。空欄または「不明」とし、不足情報は「要確認事項」として出力させます。
- 出力されたユースケース、PoC計画、再利用可能なPromptは、あくまで検討のたたき台です。業務仕様、セキュリティ、本番データ、リリース可否は、社内の担当者と承認者が判断します。
- 外部ベンダーの全面排除は前提にしません。専門知識や第三者レビューが必要な領域は、協働モデルとして残します。
実務では、最初から入力項目をすべて埋める必要はありません。分かる範囲から始め、不明点がどこにあるかを可視化できれば、まずはここまでで十分です。
Prompt
あなたは、Enterprise企業におけるソフトウェア保守、内製化、DevOps、SRE、セキュリティ、Vibe Codingの導入を支援するシニアコンサルタント兼ソフトウェアアーキテクトです。
現在、対象企業ではソフトウェアの保守作業の多くを外部ベンダーへ委託しています。以下の情報をもとに、外部委託している保守作業のうち、Vibe Codingを活用して社内で段階的に内製化できるユースケースを作成してください。
単に「AIにコードを書かせる」提案ではなく、社内の業務担当者、プロダクト担当者、エンジニアが、AIを利用して調査、仕様化、計画、実装、テスト、レビュー、文書化を主体的に行える業務モデルとして設計してください。
---
## 1. 対象企業・システム情報
### 企業・組織
- 業種: [業種を記載]
- 対象部門: [部門を記載]
- システムの業務上の重要度: [低／中／高／ミッションクリティカル]
- 現在の内製化レベル: [ほぼ外部委託／一部内製／内製中心]
- 社内エンジニアの人数・スキル: [分かる範囲で記載]
- 外部ベンダーの担当範囲: [調査、設計、実装、テスト、運用など]
- 内製化の目的:
- [保守リードタイム短縮]
- [外部委託費削減]
- [業務・技術ノウハウの社内蓄積]
- [小規模改善の高速化]
- [ベンダーロックインの軽減]
- [その他]
### 対象システム
- システム名: [名称]
- システム概要: [概要]
- 主な利用者: [利用者]
- 主な業務機能: [機能]
- 技術スタック: [言語、フレームワーク、DB、クラウドなど]
- リポジトリ: [GitHub等]
- 開発方式: [アジャイル／ウォーターフォール／その他]
- CI/CDの有無: [有／無／一部]
- 自動テストの状況: [十分／一部／ほぼ無し]
- ログ・監視の状況: [概要]
- 設計書・運用手順書の状況: [最新／一部古い／不足]
- 本番以外の検証環境: [有／無]
- セキュリティ・監査上の制約: [制約]
- 個人情報・機密情報の有無: [有／無]
- 現在の主な保守課題: [課題]
### 現在外部委託している保守作業
- [作業1]
- [作業2]
- [作業3]
- [作業4]
- [作業5]
情報が不足している場合は、架空の仕様を作らず、「要確認事項」として明示してください。
---
## 2. 保守作業の分類
外部委託している作業を、以下の4分類に整理してください。
### A. 是正保守 Corrective Maintenance
発生済みの障害、不具合、誤動作、データ不整合を修正する作業。
例:
- 障害の一次・二次調査
- ログ解析
- 不具合の再現
- 原因コードの特定
- 影響範囲調査
- 暫定回避策の作成
- バグ修正
- 回帰テスト
- データ補正
- 障害報告書
- 再発防止策
### B. 適応保守 Adaptive Maintenance
外部環境、技術基盤、接続先、規制などの変化へ追随する作業。
例:
- OS、DB、ミドルウェア更新
- 言語ランタイム更新
- OSS・ライブラリ更新
- APIバージョン移行
- クラウドサービス変更対応
- 認証方式変更
- ブラウザー、端末対応
- 法令・社内規程対応
- 非推奨機能の置換
- End of Support対応
### C. 完全化保守 Perfective Maintenance
既存システムの機能、性能、操作性、運用性、保守性を改善する作業。
例:
- 小規模機能追加
- 検索条件・入力項目追加
- CSV・帳票・レポート追加
- UI・UX改善
- エラーメッセージ改善
- 業務ルール変更
- 性能改善
- ログ・監視追加
- 運用管理画面追加
- 定型作業の自動化
- ドキュメント改善
### D. 予防保守 Preventive Maintenance
将来の障害、脆弱性、技術的負債、属人化、保守不能化を予防する作業。
例:
- コード品質診断
- 技術的負債の棚卸し
- 重複コード除去
- 大きな関数の分割
- 複雑な条件式の簡素化
- テストカバレッジ改善
- OSS脆弱性対応
- Secret検査
- 非推奨技術の調査
- 設計書と実装の整合性確認
- 復旧・ロールバック手順の検証
分類できない作業や複数分類に該当する作業は、無理に一つへ限定せず、「主分類」と「関連分類」を示してください。
---
## 3. ユースケースの作成方針
各分類について、Vibe Codingによる内製化ユースケースを作成してください。ユースケースは、必ず次の原則を満たしてください。
### 基本原則
1. 外部委託している具体的な作業を起点にする
2. 対象、入力、期待結果、完了条件を明確にする
3. テストまたはレビューで結果を検証できるようにする
4. 作業をレビュー可能な小さな単位へ分ける
5. AIの担当範囲と人の判断範囲を分ける
6. 本番変更や重要な判断をAIへ自動委任しない
7. 業務仕様が不明な場合は、AIに質問票を作成させる
8. コードだけでなく、調査、テスト、文書化まで対象にする
9. 既存の承認、監査、セキュリティ統制を維持する
10. 内製化初期は、低リスクで結果を確認しやすい作業を優先する
### 標準プロセス
各ユースケースを、次のプロセスで設計してください。
#### Research
- 現象、ログ、コード、設計書、Issue、Pull Requestを調査する
- 関連する処理経路と依存関係を特定する
- 影響範囲を分析する
- 不足情報、矛盾、未確定事項を抽出する
#### Spec
- 現状と期待状態を明確にする
- 業務ルールを整理する
- 正常系、異常系、境界値を整理する
- Given-When-Then形式などで受入条件を作成する
- AIが推測してはいけない事項を質問票にする
#### Plan
- 変更対象ファイルと変更対象外を明確にする
- 実装方法を比較する
- 作業を小さなIssueへ分割する
- テスト計画を作成する
- セキュリティ、性能、互換性、運用への影響を評価する
- ロールバック方法を作成する
#### Human Approval
- 調査結果、仕様、計画を人が確認する
- 業務仕様、セキュリティ、データ、費用、リリース可否は人が判断する
- 承認されるまで実装を開始しない
#### Implement
- 一度に一つのIssueだけを実装する
- 既存テストを削除または無効化しない
- 関係のない変更を含めない
- レビュー可能な小さなPull Requestにする
- 可能な場合はテストを先に作成する
#### Verify
- 単体、結合、回帰、異常系、境界値テストを実行する
- 静的解析、依存関係、Secret、脆弱性を確認する
- 変更差分と変更理由を説明する
- 受入条件を満たしているか確認する
- 残存リスクと未解決事項を明示する
- 必要な設計書、運用手順書、Runbookを更新する
#### Release Approval
- 本番反映は自動実行しない
- 人がPull Request、テスト結果、リリース手順を確認する
- ロールバック可能であることを確認する
- 必要な監査証跡を残す
---
## 4. 各ユースケースの出力形式
各ユースケースを次の形式で作成してください。
### ユースケースID・名称
簡潔で、作業内容が分かる名称にしてください。
### 保守分類
- 主分類:
- 関連分類:
### 現在の外部委託作業
現在、誰がどのような作業を行っているかを記載してください。
### 現在の課題
以下の観点から整理してください。
- リードタイム
- コスト
- コミュニケーション
- ノウハウ蓄積
- 品質
- 属人化
- ベンダー依存
情報がない項目は推測せず、「要確認」としてください。
### 内製化後の姿
社内の担当者がVibe Codingを利用して、どこまで実行できるようになるかを記載してください。
### 対象利用者・役割
例:
- 業務担当者
- プロダクトオーナー
- 社内エンジニア
- テックリード
- QA担当
- SRE担当
- セキュリティ担当
- 承認者
- 外部ベンダー
### 入力情報
例:
- 業務要求
- 障害事象
- ログ
- コード
- 設計書
- API仕様
- テスト
- Issue
- Pull Request
- 監視情報
### Vibe Codingで実施する作業
Research、Spec、Plan、Implement、Verifyごとに記載してください。
### AIに委任する作業
AIが支援または実施できる作業を記載してください。
### 人が判断・承認する作業
業務、品質、セキュリティ、データ、本番反映など、人が判断する作業を記載してください。
### 成果物
例:
- 調査結果
- 原因候補
- 質問票
- 影響範囲
- 受入条件
- 実装計画
- Issue
- コード差分
- テスト
- Pull Request
- 障害報告書
- Runbook
- ロールバック手順
### 完了条件
測定・検証可能な条件として記載してください。
悪い例:
- 正しく動作すること
- 使いやすくなること
- 安全になること
良い例:
- 数量が1未満の場合はHTTP 400を返し、登録処理を実行しない
- 対象の正常系、異常系、境界値テストがすべて成功する
- 既存の公開APIの入出力形式を変更しない
- ロールバック手順が検証環境で成功する
### 必要なガードレール
例:
- 本番環境へ接続しない
- 本番データを使用しない
- Secretや個人情報をPromptへ入力しない
- 既存テストを削除しない
- 認証・認可の変更は自動実施しない
- データ更新はDry Runを先に行う
- 本番デプロイには人の承認を必須とする
### 想定リスク
例:
- 業務仕様の誤解
- 影響範囲の見落とし
- テスト不足
- セキュリティ上の問題
- 性能劣化
- 後方互換性の喪失
- 生成コードの保守性低下
- AIが存在しない仕様を補完するリスク
### 内製化難易度
次の3段階で評価してください。
- 低: 低リスクで、完了条件が明確
- 中: 技術レビューや複数システムの確認が必要
- 高: 業務・セキュリティ・本番への影響が大きい
### 推奨導入段階
- Level 1: 読み取り・調査のみ
- Level 2: 計画・文書・テスト案の作成
- Level 3: 非本番での小規模変更
- Level 4: 人のレビュー付きで実装
- Level 5: 厳格な承認付きの本番適用
### 外部ベンダーの残存役割
完全な排除を前提とせず、専門知識、第三者レビュー、重大障害、大規模移行など、外部ベンダーに残すべき役割を記載してください。
### 顧客が体験できる価値
顧客がVibe Codingを使ったときに感じられる具体的な価値を、一文で記載してください。
例:
> ベンダーへログを送って回答を待つ前に、社内担当者が原因候補と影響範囲を確認できる。
---
## 5. 4分類ごとのユースケース候補
以下を参考にしつつ、入力された企業・システム情報に合わせて具体化してください。
### 是正保守
- 障害ログからの原因候補抽出
- 不具合の再現手順作成
- 不具合再現テストの生成
- 最小修正案の作成
- 影響範囲分析
- 回帰テスト追加
- データ不整合の調査
- Dry Run付きデータ補正スクリプト作成
- 障害報告書作成
- 再発防止策のIssue化
### 適応保守
- OSSライブラリ更新影響調査
- ランタイムのバージョンアップ
- 外部APIのv1からv2への移行
- 認証方式変更の影響分析
- 非推奨APIの置換
- クラウドサービス廃止への移行
- データベースバージョン更新
- ブラウザー互換性対応
- 社内セキュリティ基準変更への対応
- 規程要求と実装のトレーサビリティ作成
### 完全化保守
- 一覧画面への検索条件追加
- CSV出力追加
- 帳票・レポート追加
- 入力チェック改善
- エラーメッセージ改善
- 操作ステップ削減
- アクセシビリティ改善
- 性能ボトルネック調査
- DBクエリ最適化
- 構造化ログ・相関ID追加
- 運用管理画面追加
- 手作業の自動化
### 予防保守
- 技術的負債の棚卸し
- 重複コードの抽出
- 大きな関数・クラスの検出
- 複雑な条件分岐の簡素化
- Characterization Testの作成
- 未テスト経路の抽出
- テストカバレッジ改善
- 古い依存ライブラリの検出
- Secret・機密情報の混入確認
- 設計書、コード、テストの不整合検査
- サポート期限切れ技術の棚卸し
- Runbook・ロールバック手順の検証
---
## 6. 初期導入ユースケースの選定
作成したユースケースを、以下の評価軸で比較してください。各項目を1から5で評価し、評価理由も記載してください。
- 業務価値
- 外部委託費削減への寄与
- リードタイム短縮効果
- ノウハウ蓄積効果
- 要求の明確さ
- テスト可能性
- 変更範囲の小ささ
- セキュリティリスク
- 本番影響
- 必要な専門知識
- 顧客が成果を目で確認しやすいか
- 他システムへ横展開しやすいか
総合評価では、単純な合計点だけでなく、次の条件を優先してください。
1. 結果を自動テストまたは画面で確認できる
2. 非本番環境で完結できる
3. 変更を小さなPull Requestにできる
4. 本番データ、認証、個人情報を扱わない
5. 現在ベンダーへ反復的に依頼している
6. 社内へ業務・技術知識を蓄積できる
---
## 7. 最終出力
次の構成で回答してください。
# エグゼクティブサマリー
- 現在の外部委託構造
- Vibe Codingで内製化できる領域
- 内製化しない、または慎重に扱う領域
- 推奨する開始点
# 保守作業の4分類マップ
外部委託作業を、是正、適応、完全化、予防へ整理してください。
# Vibe Coding内製化ユースケース一覧
各分類について、最低3件、合計12件以上のユースケースを作成してください。
# 詳細ユースケース
指定されたユースケース形式で詳細を記載してください。
# 優先順位マトリクス
- Quick Win
- 戦略的に重要
- 専門家レビュー付きで実施
- 現時点では外部委託を継続
の4領域に分類してください。
# 推奨PoC
最初に検証するユースケースを3件選び、次を記載してください。
- 選定理由
- 対象作業
- 必要な入力情報
- 実施手順
- 成果物
- 成功基準
- 中止条件
- 必要なガードレール
- 顧客が体験できる価値
# 役割分担
以下の担当についてRACI形式で整理してください。
- 業務担当者
- プロダクトオーナー
- 社内エンジニア
- テックリード
- QA
- SRE
- セキュリティ担当
- 承認者
- 外部ベンダー
- AIコーディング支援
AIをAccountableに設定しないでください。
# 再利用可能なPrompt
選定した各PoCについて、顧客がそのままVibe Codingツールへ入力できるPromptを作成してください。各Promptには必ず次を含めてください。
- Role
- Objective
- Context
- Current State
- Expected State
- Scope
- Out of Scope
- Constraints
- Acceptance Criteria
- Research
- Spec
- Plan
- Human Approval
- Implement
- Verify
- Deliverables
- Safety Rules
# ガバナンスとガードレール
- 権限管理
- リポジトリ保護
- Pull Requestレビュー
- テスト・品質ゲート
- Secret・個人情報保護
- OSS・ライセンス管理
- 監査ログ
- 本番反映承認
- ロールバック
- AI生成物の責任所在
# 段階的な内製化ロードマップ
- Level 1: 読み取り・調査
- Level 2: 計画・文書・テスト案
- Level 3: 非本番での小規模変更
- Level 4: 人のレビュー付き実装
- Level 5: 厳格な承認付き本番適用
各段階について、移行条件と次段階へ進むための判定基準を記載してください。
---
## 8. 回答時の重要ルール
- 入力情報にない企業固有の事実を作らない
- 不明点は「要確認事項」として提示する
- AIが業務仕様を推測した前提で実装しない
- 「動作するコード」と「本番品質」を区別する
- セキュリティ、認証、個人情報、本番データは高リスクとして扱う
- テストを削除または無効化して成功扱いにしない
- 本番デプロイをAIへ自動委任しない
- AIの作業結果に対する最終責任者は人とする
- 外部ベンダーを全面排除する前提にしない
- 専門性が高い領域は、社内担当者と外部専門家の協働モデルを提示する
- 抽象的な要求は、測定可能な受入条件へ変換する
- ユースケースごとに、AIへ委任する範囲と人が判断する範囲を明記する
- 推奨事項と確認済みの事実を明確に分ける
4つの保守シナリオで、標準プロセスを確認する
上記のPromptは、実際の企業・システム情報を入力して使うテンプレートです。
ただ、Promptだけを見ても、現場でどのように使えばよいかは分かりにくいかもしれません。そこで、エンタープライズ企業を想定した架空の学習用システムを使い、是正、適応、完全化、予防の4つの保守シナリオを順に確認します。
各ステップには、GitHub Copilot Chatなどへそのまま入力できるサンプルPromptを置いています。Human ApprovalとRelease ApprovalはAIへ委任せず、人が確認するチェックリストとして記載します。
注意: 以下の会社名、システム名、コード、障害事象は、すべてチュートリアル用の架空設定です。実際の業務で利用する際は、前半のPromptにある
[ ]の部分を、実際の企業・システム情報へ置き換えてください。本番データ、認証情報、個人情報は、学習用途であっても入力しないでください。
学習用の架空システム: 経費精算システム「ExpenseFlow」
- システム名: ExpenseFlow（架空）
- 概要: 社員が交通費、出張費、領収書を申請し、上長が承認、経理部門が確定する社内Webアプリケーション
- 主な利用者: 一般社員（申請者）、上長（承認者）、経理部門（確定・出力）
- 技術スタック: Java 17 / Spring Boot、React、PostgreSQL、GitHub、GitHub Actions（CI）、本番はクラウドのApp Serviceを想定
- 開発体制: 要件定義以降の保守作業の多くを外部ベンダーへ委託。自動テストは主要ロジックのみ。本番以外にステージング環境あり
- 前提: 以下の4シナリオは、すべてこの架空システムを題材にした練習用
シナリオ1: 是正保守 Corrective Maintenance — 深夜勤務を含む経費申請の合計金額計算の誤り
背景
経理部門から、深夜勤務（22:00〜翌5:00）を含む交通費申請で、まれに合計金額が1円〜数百円ずれるという報告が3件あったとします。これまでは、その都度外部ベンダーへ一次調査を依頼し、回答まで数日かかっていました。
この題材を選ぶ理由は、障害対応の中でも比較的よくある構造だからです。事象は確認できているものの、再現条件と業務ルールが曖昧で、すぐに修正へ進むと危険です。
このシナリオでは、障害の一次調査、原因候補の抽出、最小修正、回帰テストまでを社内で進めます。実務上の効果は、ベンダーへ正式調査を依頼する前に、社内で論点と影響範囲を整理できることです。
Step 1: Research
あなたは、経費精算システム「ExpenseFlow」の保守を担当する社内エンジニアの調査を支援するAIアシスタントです。
# 事象
深夜勤務(22:00〜翌5:00)を含む交通費申請で、まれに合計金額の表示が正しい金額より1円〜数百円ずれるという報告が3件あります。
# 調査してほしいこと
- 金額計算に関わるコード(計算ロジック、丸め処理、深夜割増の適用箇所)を特定してください
- 関連する処理経路と依存関係(呼び出し元、共通ユーティリティ、DBへの保存箇所)を洗い出してください
- 過去のGit履歴やPull Requestで、この計算ロジックに関わる変更がないか確認してください
- ログや既存のテストコードから、再現条件の手がかりを整理してください
- 不足している情報、矛盾、確認が必要な点を「要確認事項」としてリストアップしてください
# 制約
- 本番データやログの実データは共有しません。コードとテストコードのみを対象にしてください
- 原因を断定せず、複数の原因候補と、それぞれの確からしさ、確認方法を提示してください
Step 2: Spec
先ほどの調査結果を踏まえて、この不具合の仕様書を作成してください。
# 含めてほしい内容
- 現状(Current Behavior)と期待する状態(Expected Behavior)
- 深夜割増の計算に関わる業務ルールの整理(不明な業務ルールは仮定せず質問票にする)
- 正常系、異常系、境界値(例: 22:00ちょうど、5:00ちょうど、日付をまたぐ場合)の整理
- Given-When-Then形式の受入条件
- 実装前に業務担当者へ確認すべき質問票(丸め方式、深夜割増の適用範囲、既存申請データの扱いなど、AIが推測してはいけない事項)
Step 3: Plan
仕様書と質問票への回答を踏まえて、実装計画を作成してください。
# 含めてほしい内容
- 変更対象ファイルと、変更しないファイルの明示
- 修正方法の選択肢を2つ以上比較(メリット・デメリット・影響範囲)
- テスト計画(単体テスト、境界値テスト、既存申請データへの影響確認)
- セキュリティ・性能・互換性・運用への影響評価
- ロールバック方法
- 小さなIssueへの分割(1 Issue = 1つの変更内容)
Step 4: Human Approval（確認チェックリスト・AIには依頼しない）
- 調査結果・仕様書・質問票の回答内容に誤りがないか、業務担当者と経理部門が確認した
- 深夜割増の丸め方式が、経理規程と一致していることを承認した
- 実装計画のIssue分割粒度とテスト計画が妥当であると、テックリードが確認した
- 承認が得られるまで、次のImplementへ進んでいない
Step 5: Implement
承認されたIssue「[Issue番号・タイトル]」だけを実装してください。
# 制約
- このIssueに関係するファイルのみを変更してください
- 既存のテストを削除・無効化しないでください
- 可能な場合は、先に境界値(22:00、5:00、日付またぎ)のテストコードを作成してから実装してください
- 変更はレビュー可能な小さなPull Requestにまとめてください
- 変更内容と変更理由をPull Requestの説明に記載してください
Step 6: Verify
実装したPull Requestを検証してください。
# 実施してほしいこと
- 単体テスト、境界値テスト、既存の回帰テストをすべて実行し、結果を報告してください
- 静的解析、依存関係、Secretの混入がないか確認してください
- 変更差分と変更理由を要約してください
- Specで定義した受入条件(Given-When-Then)を1つずつ満たしているか確認してください
- 残存リスクや未解決事項があれば明示してください
- 関連する設計書・運用手順書の更新が必要か確認してください
Step 7: Release Approval（確認チェックリスト・AIには依頼しない）
- Pull Requestとテスト結果を、テックリードまたは承認者がレビューした
- ステージング環境で境界値を含めた動作確認を行った
- ロールバック手順が検証環境で成功することを確認した
- 本番反映日時と監査証跡（承認者・承認日時・Pull Request URL）を記録した
- 上記すべてが完了するまで、本番デプロイを実行していない
このシナリオで押さえたいこと
- ベンダーへログを送って回答を待つ前に、社内で原因候補と影響範囲まで整理できる
- 質問票を挟むことで、AIが丸め方式などの業務ルールを勝手に決めることを防げる
- Human ApprovalとRelease Approvalを分けることで、実装承認と本番反映承認を混同しにくくなる
正直、一次調査だけで原因が確定しないこともあります。それでも、再現条件、関連コード、確認すべき業務ルールが整理されていれば、外部ベンダーとのやり取りも具体的になります。
シナリオ2: 適応保守 Adaptive Maintenance — 認証ライブラリの脆弱性対応に伴うメジャーバージョンアップ
背景
ExpenseFlowが利用している架空のOSS認証ライブラリ「AuthGuard」に脆弱性が報告され、破壊的変更を含むメジャーバージョンアップ（v2→v3）が必要になったとします。
適応保守は、アプリケーションの要求が変わったのではなく、外部環境の変化へ追随する作業です。期限が決まっていることも多く、影響範囲を短時間で把握できるかが重要になります。
このシナリオでは、OSSの変更点と現在の利用箇所を対応付け、段階的な移行計画までを社内で作ります。認証は高リスク領域なので、AIの出力だけで変更を確定せず、セキュリティ担当とテックリードの承認を必須にします。
Step 1: Research
あなたは、ExpenseFlowが利用しているOSS認証ライブラリ「AuthGuard」を v2 から v3 へ更新する影響調査を支援するAIアシスタントです。
# 調査してほしいこと
- 現在のリポジトリでAuthGuard v2のAPIを利用している箇所をすべて洗い出してください
- v3の公式リリースノート・移行ガイド(添付、またはリンクで共有します)を基に、破壊的変更点を整理してください
- 破壊的変更が、現在の利用箇所にどう影響するかを一覧化してください
- 認証フロー・セッション管理・既存の自動テストへの影響範囲を分析してください
- 不足している情報や、動作確認が必要な点を「要確認事項」としてリストアップしてください
# 制約
- 実際の認証情報・Secret・トークンは共有しません
- v3の仕様について不明な点は、推測せず「要確認事項」にしてください
Step 2: Spec
調査結果を踏まえて、AuthGuard v3移行の仕様書を作成してください。
# 含めてほしい内容
- 現状(v2利用箇所と挙動)と移行後の期待状態
- 破壊的変更ごとの対応方針(コード変更、設定変更、非対応機能の代替手段)
- 正常系(通常ログイン)、異常系(トークン失効、権限エラー)、境界値(同時セッション数の上限など)の整理
- Given-When-Then形式の受入条件(移行前後で認証結果が変わらないことを含む)
- 移行方式や許可されたセッション有効期限など、セキュリティ担当へ確認すべき質問票
Step 3: Plan
仕様書を踏まえて、AuthGuard v3への移行計画を作成してください。
# 含めてほしい内容
- 変更対象ファイル・設定ファイルと、変更対象外の明示
- 一括移行と段階的移行(機能フラグ・カナリアリリースなど)の比較
- テスト計画(認証の正常系・異常系・境界値、既存の回帰テスト)
- セキュリティ・性能・互換性・運用(既存ログインセッションの扱い)への影響評価
- ロールバック方法(v2への切り戻し手順)
- 小さなIssueへの分割
Step 4: Human Approval（確認チェックリスト・AIには依頼しない）
- 破壊的変更への対応方針を、セキュリティ担当・テックリードが確認した
- 認証方式や既存セッションの扱いに関する質問票の回答を、業務担当者・セキュリティ担当が承認した
- 移行方式（一括・段階的）とロールバック方法が妥当であると承認された
Step 5: Implement
承認されたIssue「[Issue番号・タイトル]」だけを実装してください。
# 制約
- このIssueで対応する破壊的変更のみを対象にしてください
- 既存の認証テストを削除・無効化しないでください
- 認証・認可に関わる設定変更は、必ずレビュー可能な差分として明示してください
- 変更はレビュー可能な小さなPull Requestにまとめてください
Step 6: Verify
実装したPull Requestを検証してください。
# 実施してほしいこと
- 認証の正常系・異常系・境界値テスト、既存の回帰テストをすべて実行し結果を報告してください
- 依存関係の脆弱性スキャン結果(AuthGuard v3および関連ライブラリ)を確認してください
- 静的解析・Secretの混入有無を確認してください
- 受入条件を1つずつ満たしているか確認してください
- 残存リスク(例: 一部ブラウザーでの動作未確認など)を明示してください
Step 7: Release Approval（確認チェックリスト・AIには依頼しない）
- セキュリティ担当が、認証フローの変更内容を最終レビューした
- ステージング環境で、実際のログイン・セッション切れ・権限エラーのシナリオを確認した
- ロールバック手順（v2への切り戻し）を検証環境で確認した
- 監査証跡（承認者、承認日時、Pull Request、リリース日）を記録した
このシナリオで押さえたいこと
- OSSや外部APIの更新では、公式情報と現在の実装を対応付けて影響を確認する
- 調査とテストは社内で進められても、認証方式やセッション管理の判断は人が行う
- 非推奨機能の置換、クラウドサービス廃止、ランタイム更新にも同じ進め方を応用できる
実務では、脆弱性対応という理由だけで、すぐに最新版へ上げればよいとは限りません。期限、代替策、互換性、切り戻し可能性を見た上で、変更単位を小さくする必要があります。
シナリオ3: 完全化保守 Perfective Maintenance — 経費申請一覧画面への検索条件追加
背景
経理部門から、月次締め処理の際に、部門別・期間別で申請一覧を絞り込みたいという要望が出たとします。これまでは、こうした小規模な画面改善もすべて外部ベンダーへ発注していました。
完全化保守は、Vibe Codingによる内製化の効果を比較的確認しやすい領域です。画面や受入条件を具体化しやすく、非本番環境で結果を目視できます。
とはいえ、「検索条件を追加したい」という要求だけでは実装できません。部門は単一選択か複数選択か、日付の両端を含むか、未入力時にどう動くかなど、実務では確認事項が増えます。そこを質問票に変換することが、このシナリオのポイントです。
Step 1: Research
あなたは、経費精算システム「ExpenseFlow」の画面改善調査を支援するAIアシスタントです。
# 依頼内容
経理部門から、経費申請一覧画面に「部門」「申請日範囲」で絞り込める検索条件を追加してほしいという要望がありました。
# 調査してほしいこと
- 現在の申請一覧画面と、そのデータ取得処理(API・クエリ)のコードを特定してください
- 検索条件を追加する場合に影響を受けるファイル(画面、API、クエリ、既存のテスト)を洗い出してください
- 既存の一覧画面に他の検索条件が既にある場合は、その実装パターンを確認してください
- パフォーマンスへの影響(検索対象データ件数、既存のインデックス状況)を確認してください
- 不足している情報を「要確認事項」としてリストアップしてください
Step 2: Spec
調査結果を踏まえて、この機能追加の仕様書を作成してください。
# 含めてほしい内容
- 現状(検索条件なし)と期待状態(部門・申請日範囲で絞り込み可能)
- 業務ルールの整理(部門の選択方法、申請日範囲の指定方法、両方未入力の場合の挙動)
- 正常系(部門のみ指定、期間のみ指定、両方指定)、異常系(開始日が終了日より後など)、境界値(期間の開始日・終了日当日を含むか)の整理
- Given-When-Then形式の受入条件
- 画面のレイアウトや部門の選択方式(プルダウン/複数選択など)について、業務担当者へ確認すべき質問票
Step 3: Plan
仕様書を踏まえて、実装計画を作成してください。
# 含めてほしい内容
- 変更対象ファイル(画面コンポーネント、API、クエリ)と変更対象外の明示
- 実装方法の比較(例: サーバー側でのフィルタリング vs クライアント側でのフィルタリング)
- テスト計画(正常系・異常系・境界値、既存の一覧表示テストが壊れないこと)
- 性能への影響評価(検索条件追加によるクエリ実行時間への影響)
- 小さなIssueへの分割
Step 4: Human Approval（確認チェックリスト・AIには依頼しない）
- 検索条件の項目・選択方式（プルダウン・複数選択）について、経理部門・業務担当者が仕様書を確認した
- UI変更のイメージ（画面モック等）をプロダクトオーナーが承認した
Step 5: Implement
承認されたIssue「[Issue番号・タイトル]」だけを実装してください。
# 制約
- このIssueに関係する画面・API・クエリのみを変更してください
- 既存の一覧表示・他の検索条件のテストを削除・無効化しないでください
- 可能な場合は、先に境界値(開始日=終了日、部門未選択など)のテストを作成してください
- レビュー可能な小さなPull Requestにまとめてください
Step 6: Verify
実装したPull Requestを検証してください。
# 実施してほしいこと
- 正常系・異常系・境界値テスト、既存の回帰テストをすべて実行し結果を報告してください
- 検索条件追加後のクエリ実行時間を、追加前と比較してください
- 静的解析・依存関係の確認を行ってください
- 受入条件を1つずつ満たしているか確認してください
- 画面操作手順書や運用手順書の更新が必要か確認してください
Step 7: Release Approval（確認チェックリスト・AIには依頼しない）
- 経理部門が、ステージング環境で実際に検索条件を操作して確認した
- Pull Requestとテスト結果を、テックリードまたは承認者がレビューした
- 既存の一覧画面の表示・出力（CSV等）に影響がないことを確認した
このシナリオで押さえたいこと
- 検索条件追加のような定型的な小規模改善は、内製化の初期候補にしやすい
- UI要求は、そのまま実装せず、選択方式、未入力時の挙動、境界値まで具体化する
- 画面だけでなく、API、クエリ、性能、既存出力への影響まで確認する
顧客や業務担当者が画面上で成果を確認できるため、PoCの価値も説明しやすくなります。一方で、見た目が動いたことだけを成功条件にせず、既存機能と性能への影響も確認する必要があります。
シナリオ4: 予防保守 Preventive Maintenance — 経費計算ロジックの技術的負債棚卸しとテストカバレッジ改善
背景
経費計算ロジックを保守できるのが特定のベンダー担当者に限られ、属人化とテスト不足が課題になっているとします。将来の障害を防ぐため、いきなり大規模なリファクタリングを行うのではなく、まず棚卸しとCharacterization Testの追加から始めます。
予防保守は、機能追加のように成果が画面へ表れにくい領域です。そのため、「きれいになった」「読みやすくなった」だけでは完了条件として弱くなります。
このシナリオでは、既存の挙動をテストで固定し、複雑度、重複、未テスト経路を可視化します。実務への影響は、特定の担当者しか触れなかった領域を、社内で説明可能な状態へ近づけられることです。
Step 1: Research
あなたは、経費精算システム「ExpenseFlow」の技術的負債の棚卸しを支援するAIアシスタントです。
# 調査してほしいこと
- 経費計算ロジックに関わるファイル・関数・クラスを特定してください
- 複雑度が高い関数(条件分岐が多い、行数が長いなど)を検出し、リストアップしてください
- 重複しているコードがあれば特定してください
- 現在のテストカバレッジ(あれば)と、テストが存在しない処理経路を洗い出してください
- 設計書と実装の間に不整合がないか確認してください
- 不足している情報を「要確認事項」としてリストアップしてください
# 制約
- この段階ではコードの変更は行わず、調査結果のみを報告してください
Step 2: Spec
調査結果を踏まえて、リファクタリングの仕様書を作成してください。
# 含めてほしい内容
- 現状(複雑度・重複・テスト不足箇所)と期待状態(挙動を変えずにテストカバレッジと可読性を改善する)
- 「挙動を変えない」ことを保証するための受入条件(Given-When-Then形式。既存の入力パターンに対する出力が変更前後で一致すること)
- 正常系・異常系・境界値のうち、Characterization Testとして追加すべきケースの整理
- リファクタリング対象から除外すべき箇所(触ると影響が大きい、業務ルールが不明瞭など)についての質問票
Step 3: Plan
仕様書を踏まえて、実施計画を作成してください。
# 含めてほしい内容
- 対応する範囲(このフェーズでリファクタリングする関数・ファイル)と対応しない範囲の明示
- 実施順序(1. Characterization Testの追加 → 2. 小さな単位でのリファクタリング)の計画
- 各ステップのテスト計画(追加したテストが、リファクタリング前後で同じ結果になることの確認方法)
- 性能・互換性への影響評価
- 小さなIssueへの分割(1 Issue = 1つの関数・1つの改善内容)
Step 4: Human Approval（確認チェックリスト・AIには依頼しない）
- 棚卸し結果とリファクタリング対象範囲を、テックリードが確認した
- 「挙動を変えない」という前提について、業務担当者と合意できている
- 対象から除外する箇所（質問票の回答）が妥当であると確認した
Step 5: Implement
承認されたIssue「[Issue番号・タイトル]」だけを実装してください。
# 制約
- 最初にCharacterization Test(現状の挙動を固定するテスト)を作成し、テストが通ることを確認してから、リファクタリングを行ってください
- 挙動(入力に対する出力)を変えないでください。挙動を変える必要がある場合は、実装せず質問として報告してください
- 既存のテストを削除・無効化しないでください
- レビュー可能な小さなPull Requestにまとめてください
Step 6: Verify
実装したPull Requestを検証してください。
# 実施してほしいこと
- Characterization Testおよび既存の回帰テストをすべて実行し、結果を報告してください
- リファクタリング前後で、複雑度・重複度がどう変化したかを報告してください
- 静的解析、依存関係、Secretの混入有無を確認してください
- 挙動が変わっていないことを、テスト結果に基づいて説明してください
- 残存する技術的負債(次のフェーズで対応すべき項目)を明示してください
Step 7: Release Approval（確認チェックリスト・AIには依頼しない）
- テックリードが、挙動が変わっていないことをテスト結果から確認した
- リファクタリング後のコードレビューを実施した（可読性・保守性の観点）
- 本番反映後、既存の経費計算結果に影響がないことをステージング環境で確認した
このシナリオで押さえたいこと
- Characterization Testにより、「挙動を変えていないこと」をテスト結果で説明できる
- 技術的負債は、一度に解消せず、関数や責務単位の小さなIssueへ分割する
- 調査結果、仕様書、テストを残すことで、属人化していた知識を社内資産へ変えられる
予防保守は、短期的な費用削減だけで評価すると優先順位が下がりやすいです。ただし、障害時の調査時間や将来の変更リスクまで含めると、継続的に実施する意味があります。
ここまでの整理
ここまでの内容を、良い点、注意点、限界の3つに分けて整理します。
良い点
- コード生成だけでなく、調査、仕様、計画、テスト、文書化までを内製化の対象にできる
- 作業を小さなIssueとPull Requestへ分けるため、人がレビューしやすい
- 不明な業務仕様を質問票として明示し、AIによる推測を抑えられる
- 一次調査や影響範囲整理を社内で進めることで、ベンダーとのコミュニケーションを具体化できる
- 成果物が社内に残るため、業務知識と技術知識の蓄積につながる
注意点
- AIの出力は事実ではなく、確認対象として扱う
- 動作するコードと、本番品質のコードを区別する
- 認証、個人情報、本番データ、データ補正は高リスクとして扱う
- 既存テストを削除または無効化して、成功扱いにしない
- Human ApprovalとRelease Approvalを省略しない
- 外部ベンダーとの責任分界と契約条件を確認する
限界
- ドキュメントやテストが不足しているシステムでは、AIも正しい前提を得にくい
- 暗黙の業務ルールは、コードだけから完全には復元できない
- 大規模移行、重大障害、規制対応は、社内だけで完結させない方がよい場合がある
- AIを導入しても、承認待ちや組織上の意思決定がボトルネックとして残ることがある
- 内製化には、社内側で成果物をレビューできる最低限の技術力が必要になる
まとめ
Vibe Codingをソフトウェア保守へ適用する際、最初から実装や本番反映を目指す必要はありません。
まずは、外部ベンダーへ繰り返し依頼している作業の中から、非本番環境で完結し、結果をテストや画面で確認でき、変更範囲を小さくできるものを選びます。一次調査、影響範囲分析、テスト追加、小規模な画面改善、ドキュメント更新などは、比較的始めやすい領域です。
一方で、認証、個人情報、本番データ、重大障害、大規模移行は慎重に扱う必要があります。そこではAIを使わないのではなく、調査と判断材料の作成に限定し、社内の責任者や外部専門家と協働する形が現実的です。
内製化の目的は、すべてを社内だけで実施することではありません。現場が状況を理解し、選択肢を比較し、重要な判断を自分たちで行える状態へ近づけることです。
今回のPromptを使う場合も、最初から12件のユースケースを完璧に作る必要はありません。実際の外部委託作業を1つ選び、ResearchとSpecまで試し、どの情報が不足しているかを確認する。まずはここまでで十分です。
その結果を見て、Plan、非本番でのImplement、Verifyへ段階的に進める方が、現場へ定着しやすくなります。
さ、楽しいVibe Coding WorkとVibe Coding Lifeを楽しみましょう!😊