チームで迷わないバグ修正の進め方

この記事でわかること（導入）

このページは、チーム開発でバグ修正を「迷わず・安全に・再現性高く」進めるための運用ルールをまとめたものです。

困ったときに辞書のように引けるよう、章ごとに目的と判断基準をはっきり書きます。

「何を先に決めるか」と「何を根拠に直ったと言えるか」を揃えることで、レビューや引き継ぎの摩擦を減らします。

このルールは、個人の職人芸ではなくチームの合意として運用できることを目標にしています。

用語が揺れると議論が噛み合わないので、同じ意味の言い換えを増やさず、同じ単語を使い続けます。

運用の目的は「最短で直す」ではなく「安全に直して再発を減らす」なので、速度は検証とトレードオフだと明示します。

迷ったときに戻る場所を固定することで、個人の不安や焦りに作業が引っ張られないようにします。

まず読む順（通常／本番）

通常のバグ修正は「基本方針→修正前→設計→修正後→禁止事項→テンプレ→チェックリスト」の順で読むと迷いにくいです。

迷ったら「修正前に確認すること」に戻り、再現と影響範囲が固まっているかを確認します。

本番障害のときは「本番障害時の使い方→止血→連絡と記録→修正前→設計→修正後→報告テンプレ→チェックリスト」の順で読むと初動が速くなります。

緊急時は原因究明よりも被害最小化を先に置き、復旧後に落ち着いて恒久対応へ移ります。

本番障害の章は「当番が一人でも動ける」ことを優先し、判断の順番と共有の型を固定します。

復旧後に焦って恒久対応を入れると差分が膨らむので、止血と恒久対応は別のタスクとして切り分けます。

このルールの前提（小さく・安全に・証拠ベース）

バグ修正は最短で直すことよりも「影響を増やさずに直したと言い切れる状態」を作ることを優先します。

直したと言い切るために必要な情報は、再現手順、ログ、差分、テスト結果の4点です。

ログや再現手順などの証拠を軸に進め、推測だけで大きく作り替える行為を避けます。

推測が必要なときは、仮説を一つに絞って観測点を増やし、検証で白黒を付けます。

原因が複合していそうなときも、まずは最も影響が大きい線から一本ずつ切り分けます。

調査・修正・検証のどの段階でも、根拠が薄い判断は「暫定」と明記し、後で修正できる状態を保ちます。

基本方針：バグ修正は「小さく安全に」

バグ修正の成果は「差分の小ささ」と「検証の確かさ」で評価するのがチーム運用に向きます。

差分が小さいほどレビューが速くなり、戻す判断も取りやすくなります。

検証の確かさは、再現と回帰の両方が揃っているかで判断します。

差分の小ささと検証の確かさを両立するために、設計とテストの準備を先に行います。

緊急時であっても、最低限の「戻し方」と「監視の見方」を欠かさないのが安全運用です。

直す範囲を最小化する（いつ拡げるかの基準）

最初の修正案は、影響範囲が読める最小差分に限定します。

小さく直すほど、デバッグのやり直し回数が減り、原因も見失いにくくなります。

仕様の誤りや設計の限界が原因と確定した場合に限り、関係者合意のうえで範囲を拡げます。

範囲を拡げるときは、段階的にコミットして「どこで直ったか」を追える形にします。

範囲拡大はリスクが増えるので、影響範囲と戻し方を先に文章で書いてから着手します。

範囲を拡げる判断が必要なら、止血の有無とユーザー影響の優先順位を先に揃えます。

事実と推測を分けて進める（ログ／再現／仮説）

「何が起きたか」はログと再現結果で書き、推測は仮説として別枠に分けます。

事実は変わらないので、あとから見返しても議論の土台になります。

仮説は一度に一つだけ検証し、複数の推測を同時に混ぜないようにします。

仮説が外れたら、観測点を増やしてから次の仮説に進みます。

仮説の検証は「変える」「観測する」「戻す」をセットにして、検証が終わったら状態を元に戻します。

仮説検証の結果が曖昧なら、次の一手は修正ではなく観測点の追加にします。

ロール分担（担当／レビュー／当番）

担当者は調査と修正を進め、レビュー担当は影響範囲と検証の妥当性を重点的に見ます。

レビュー担当は「安全に戻せるか」と「テストが足りているか」を最後に確認します。

当番やオンコールがいる場合は「止血の判断」と「連絡の窓口」を明確にしておきます。

窓口が決まっていると、情報が散らばらず、意思決定が速くなります。

レビューで詰まりやすい点は事前にテンプレ化し、個人の解釈に依存しないようにします。

役割が足りないチームでは、最低限「担当」と「レビュー」を切り分け、同一人物でも時間を分けて確認します。

修正前に確認すること

着手前に確認すべき項目を固定すると、焦りや思い込みでの事故が減ります。

先に揃えるべきものを揃えないと、修正が当たっていても「直った証明」ができません。

情報が足りない場合は、すぐに直すよりも観測点を増やすほうが最終的に早く終わります。

緊急時でも、最低限の再現と影響整理がないと「どこを直したか」が曖昧になり、次の障害につながります。

再現手順と期待結果を確定する（再現できない時の扱い）

再現手順は「入力・操作・環境・結果」を一文で書ける形まで落とします。

期待結果は「本来どうなるべきか」を短い言葉で固定し、議論のズレを減らします。

再現できない場合は、再現条件の仮説を立てて観測点（ログ・メトリクス）を増やしてから次に進みます。

再現できない状態での修正は、検証が弱くなり再発率が上がるので注意します。

再現が難しい場合は、まず「発生条件を狭める」ことを目標にします。

再現手順は短いほどよいですが、短くしすぎて条件を落とすと検証の根拠が薄くなります。

• 再現環境（OS／ブラウザ／バージョン／権限）
• 発生頻度（必ず／時々／特定条件のみ）
• 期待結果（本来どうなるべきか）
• 観測点（必要なログ、メトリクス、トレース）
• 再現の代替（監視指標での再現、負荷試験での再現）
• 再現の最小化（条件を1つずつ削って境界を探す）

影響範囲を切り分ける（ユーザー／機能／データ）

影響範囲は「誰に」「どの機能に」「どのデータに」影響するかの三点で整理します。

影響範囲が広いほど、まず止血で被害を止める価値が上がります。

リスクが高い場合は、まず止血策（フラグ・縮退・切り戻し）を検討してから恒久対応に入ります。

止血策を先に決めると、調査が長引いたときに判断がブレません。

影響の見落としが怖い場合は、保守的に「広めに見積もる」方針を採ります。

影響範囲の判断は、コードだけでなく運用・サポート・売上への波及も含めて考えます。

• 影響ユーザー（全体／特定プラン／特定権限）
• 影響機能（画面／API／バッチ／外部連携）
• 影響データ（欠損／重複／整合性崩れ／個人情報）
• 影響の大きさ（収益、法務、信頼、サポート負荷）
• 影響の継続性（瞬間的／蓄積する／後から顕在化する）
• 回避策の有無（ユーザー側で回避できるか）

原因候補を絞る（ログ／差分／直近変更）

原因候補は「直近差分」「周辺ログ」「再現条件」の三点から上から順に潰します。

候補が多いときは、まず影響範囲が大きいものから優先して調べます。

調査の途中で得た事実は時系列でメモし、後で報告テンプレにそのまま転記できる形にします。

メモは「観測→判断→実施」を分けて書くと、あとから見ても理解しやすいです。

調査は「止血に直結する情報」と「恒久対応に必要な情報」を分けて集めます。

原因候補が更新されたら、必ず再現手順と影響範囲のメモも更新します。

• 直近の変更（PR・リリース・フラグ切替）
• ログ（エラー・警告・タイムアウト・リトライ）
• 外部要因（依存サービス・ネットワーク・権限変更）
• 再現条件（特定ユーザー、特定データ、特定時間帯）
• 直近の設定変更（環境変数、権限ロール、機能設定）
• 監視の変化（エラー率、レイテンシ、リトライ回数の推移）

修正内容の設計（どう直すか）

実装に入る前に「どう直すか」と「どう直ったと言い切るか」をセットで決めます。

修正方針は、最小差分で止血するのか、恒久対応まで入れるのかを明確にします。

修正の目的が止血なら、将来の改善と混ぜずに短時間で安全に終えることを優先します。

設計の段階で、レビュー観点とテスト観点を一緒に書いておくと、実装後の手戻りが減ります。

最小差分の修正パターン（ガード／分岐／初期化）

最小差分の修正は、ガード追加や分岐条件の修正、初期化の不足補完のような手当てが中心です。

止血が目的のときは「安全に失敗する」方向へ寄せるのが基本です。

再現条件が限定的で影響範囲が広い場合ほど、まずはこの型で安全に止めるのが向きます。

後から恒久対応を追加できるよう、修正意図をPRに短く残します。

最小差分でも「戻し方」と「監視の見方」は必ずセットで残します。

最小差分の修正でも、ログの追加やメトリクスの追加で観測性を上げるのは有効です。

• ガード（nullチェック、境界条件、権限チェック）
• 分岐（条件の反転、優先順位、フォールバック）
• 初期化（デフォルト値、未設定の扱い、キャッシュの無効化）
• 例外設計（握りつぶさず、観測できる形で返す）
• 時限対応（期限付きの暫定措置、撤去チケットを必須にする）
• 観測性（ログ追加、アラート追加、エラー分類の改善）

恒久対応パターン（責務分割／設計見直し）

恒久対応は、責務分割や設計見直しのように将来の再発を抑える改善を含みます。

恒久対応は差分が大きくなりやすいので、計画と合意形成を先に行います。

同じ種類の不具合が繰り返されている場合や仕様が曖昧な場合に、合意形成とセットで選びます。

仕様が揃っていない場合は、まず期待結果の明文化を先に済ませます。

恒久対応を選ぶ場合は、変更の境界を明確にして「どこまでが今回か」を言葉で固定します。

恒久対応は一度にやり切ろうとせず、段階的に改善して安全にリリースします。

• 仕様の言語化（期待結果の明文化）
• 責務分割（モジュール分離、境界の整理）
• 監視の追加（SLO、アラート、ダッシュボード）
• エラーハンドリング統一（リトライ、タイムアウト、フォールバック）
• 依存関係の整理（バージョン固定、互換の確認、移行計画）
• テスト設計の強化（回帰の自動化、重要フローの固定）

逃げ道を用意（ロールバック／フラグ／縮退）

本番に影響する修正は、失敗してもすぐ戻れる逃げ道を用意します。

逃げ道は「戻す手順」と「戻したあとに何を確認するか」まで含めます。

逃げ道の有無はレビュー観点として明示し、後から慌てて作らないようにします。

逃げ道がない場合は、リリースを止める判断も含めて検討します。

逃げ道の手順は、誰でも実行できるようにコマンドや画面遷移を具体的に書きます。

逃げ道を用意するのは保険であり、保険があると落ち着いて検証できます。

• ロールバック手順（誰が、どの順で、どこまで戻すか）
• フラグ運用（有効化条件、対象範囲、戻し方）
• 縮退運転（機能停止、代替表示、遅延許容）
• バックアウト後の確認（監視、問い合わせ、影響範囲の再点検）
• ログと監視の継続（戻したあとに正常化を確認する）
• データ整合（戻すことでデータが壊れないかを確認する）

修正後に行うこと（検証と再発防止）

修正はマージやリリースで終わらず、検証と記録までを含めて完了です。

検証が弱いと、修正が正しくても再発扱いになり、チームの信頼が落ちます。

検証は「直った」だけでなく「直し方が安全だった」ことも示します。

リリース後の数時間は監視が重要なので、担当者が確認できる時間帯に出すのが理想です。

テスト観点を増やす（回帰／境界／異常系）

テストは「再現手順が通る」だけでなく、回帰・境界・異常系を意識して観点を増やします。

修正の種類に応じて、観点の追加ポイントを先に決めておくと抜けが減ります。

観点が多すぎる場合は優先順位を付け、少なくとも回帰と境界だけは落とさないようにします。

テストが書けない修正は、観測点の追加と手順書で補います。

テストの目的は品質保証だけでなく、将来の変更で同じ事故が起きないようにすることです。

テストの追加は負担になるので、優先度の高いシナリオから固定します。

• 回帰（周辺機能が壊れていないか）
• 境界（空、最大、0、負数、上限下限）
• 異常系（タイムアウト、リトライ、権限不足）
• 監視（エラー率、レイテンシ、リトライ回数）
• データ検証（整合性チェック、重複検知、欠損検知）
• 権限差分（管理者／一般／外部連携の違い）

影響範囲の再確認（データ・権限・互換）

修正後は「データ」「権限」「互換性」の観点で影響範囲を再確認します。

修正前に整理した影響範囲と照らし合わせ、漏れがないかを確認します。

特にデータに触れる修正は、移行や復旧の手順が必要かを最後にもう一度チェックします。

権限や互換は、目に見えない差分になりやすいのでレビューで強く意識します。

影響が不確実な場合は、段階リリースや限定公開でリスクを下げます。

リリース後の監視で異常が出たら、修正より先に止血へ戻るのが原則です。

• データ（整合性、二重書き込み、削除の扱い）
• 権限（管理者、一般、外部連携の権限境界）
• 互換（API、スキーマ、バージョン差）
• ロールバック時の整合（戻したときにデータが壊れないか）
• 監視の閾値（異常を検知できる設定になっているか）
• キャッシュ（古いデータが残る可能性があるか）

変更履歴の残し方（PR／チケット／リリースノート）

差分の意図と検証結果は、PRとチケットに残して再利用できる形にします。

あとから追える情報が残っていると、同じ種類の不具合を素早く潰せます。

リリースノートが必要な変更は、影響ユーザーと回避策を短く書いておくと問い合わせ対応が楽になります。

恒久対応の宿題はチケット化し、期限と担当を明確にします。

記録は「何をしたか」だけでなく「なぜそう判断したか」を短く残します。

記録は正確さが重要なので、推測と事実を混ぜずに書きます。

禁止事項（やってはいけないこと）

事故になりやすい行動を禁止事項として明文化し、迷いが出たときのブレーキにします。

禁止事項は「よくやりがちなこと」をあえて書き、当たり前を守るための仕組みにします。

禁止事項は心理的に刺さるので、チームの合意と例外条件も一緒に共有します。

禁止事項は叱るためではなく、事故を起こさないための合意なので、定期的に見直します。

根拠のない大改修で直そうとしない（失敗例つき）

原因が特定できていない段階で大改修に走るのは、影響範囲が読めず火種を増やします。

差分が大きいほど、検証もレビューも弱くなり、再発の温床になります。

失敗例として「ついでにリファクタして別の不具合を生んだ」をチームで共有しておくと抑止になります。

大改修が必要なら、止血と恒久対応を分けて計画します。

大改修に入る場合は、目的と範囲と完了条件を先に文章で合意します。

大改修はレビュー負荷も上がるので、レビュー担当の時間を事前に確保します。

直接本番で試さない／ログを消さない（失敗例つき）

本番での試行錯誤は再現性が下がり、復旧に必要な情報を失うリスクが高いです。

本番は一度の判断ミスが大きな影響につながるので、試す場所を分けます。

失敗例として「ログ削除で原因追跡が不能になった」を具体的に想定して、ログは増やす方向で動きます。

ログの追加は一時的でもよいので、後で削除するチケットを残します。

本番のログは原因究明の唯一の証拠になることがあるので、保持期間も意識します。

ログを減らす議論は、障害対応が落ち着いてから行います。

「直った」判定を体感だけにしない（失敗例つき）

体感で直ったと判断すると、条件が揃った瞬間に再発して信頼を落とします。

直った判定には、再現手順、回帰、監視のどれか一つではなく、複数の根拠が必要です。

失敗例として「一部ユーザーだけ再発した」を避けるため、観測指標とテスト結果を根拠にします。

再現できない不具合は、監視とログの改善が恒久対応の中心になります。

「直った根拠」が書けない場合は、まだ直ったと言い切れない状態だと判断します。

直った判定を早めたいなら、先に根拠となる指標とテストを整えます。

Hooksで修正後のチェックを自動化する

人の注意力に依存する部分は、可能な範囲でHooksやCIに寄せて事故を減らします。

自動化は一度に完成させず、最小セットから育てるのが継続しやすいです。

自動化の目的は「うっかり」を潰すことであり、複雑な運用を増やすことではありません。

自動化の結果、開発体験が悪化する場合は、実行タイミングを分けるなどして現実解を作ります。

推奨最小セット（format＋lint＋型＋unit）

まずはformat、lint、型チェック、最小限のunit testを必須にすると導入が進みます。

最小セットを必須にしたら、次に回帰が多い箇所だけを狙ってテストを増やします。

チームの成熟度に応じて、統合テストやE2Eは後から足していく方が形骸化しにくいです。

重いテストは夜間やマージ後に回すなど、運用で現実解を作ります。

ローカルで重すぎる場合は、CIでのみ必須にするなどの分割も検討します。

最小セットは「必須」と「推奨」に分けると導入しやすいです。

• format（自動整形で差分を読みやすくする）
• lint（危険なパターンを早期に落とす）
• 型（破壊的変更を機械的に検知する）
• unit（再発を最小コストで防ぐ）
• 必要に応じて（依存更新の検知、脆弱性スキャン）
• 変更範囲が広いときは（スモークテスト、簡易E2Eの実行）
• 本番影響が大きいときは（リリース前チェックの追加）

失敗時の運用（例外対応・一時回避のルール）

チェックが失敗したときの例外対応を決めないと、例外が常態化して安全が崩れます。

例外は「本当に必要か」と「いつ戻すか」をセットで扱います。

一時回避は期限と理由を必須にし、後追いの修正チケットを作る運用にします。

例外が多い場合は、ルールが現場に合っていない可能性を疑います。

例外を許す場合も、代替の確認（手動テストや監視強化）を必ず組み合わせます。

例外を許した判断を記録しないと、次のレビューで同じ議論を繰り返します。

• 例外はレビュー承認が必要
• 例外には期限とフォローアップが必要
• 例外が増えたらルール自体を見直す
• 例外はPR本文に残し、後で検索できるようにする
• 例外時の代替確認を明記する
• 例外の実施後に振り返りを行う

チーム導入のコツ（段階導入・合意形成）

いきなり厳格にすると反発が出るので、まずは警告から始めて段階的に必須化します。

導入初期は、失敗のたびに「なぜ落ちたか」を学べる状態にしておくと定着します。

ルールは「なぜ必要か」を短く説明し、最初の1週間はメンテ担当を決めて詰まりを解消します。

ルールの追加や変更は、チームの合意と小さな実験で進めます。

自動化は増やしすぎると遅くなるので、体感速度と品質のバランスを定期的に見直します。

定期的に「遅さの原因」が分かるように、実行時間や失敗率も観測します。

本番障害時の使い方（当番向け）

本番障害は調査よりも被害の最小化を先に行い、次に再現と恒久対応に移ります。

当番が迷う時間を減らすために、判断の順番と共有の型を固定します。

本番障害では「今何が分かっているか」と「次に何をするか」を短い言葉で繰り返し共有します。

焦ると情報が散るので、連絡文はテンプレ化して短い更新を積み重ねます。

初動タイムボックス（5分／15分／60分）

最初の5分は状況把握と止血の候補出しに使い、迷ったら安全側の縮退を選びます。

この段階では「原因を当てる」より「被害を増やさない」ことが目的です。

次の15分は影響範囲の特定と連絡の整理に使い、チームの認知負荷を下げます。

ここで担当割りを決めると、調査と連絡がぶつかりません。

60分以内に復旧の目処が立たない場合は、切り戻しや機能停止の意思決定を上げます。

意思決定が必要な場合に備え、根拠となる観測値を一緒に添えます。

復旧の目処が立った場合でも、監視が安定するまでは更新間隔を決めて連絡を続けます。

復旧後に「いつ障害対応を終えるか」を決めないと、ズルズル長引くのでクローズ条件も決めます。

止血（切り戻し／フラグ／縮退）

止血は「ユーザー影響を止める」ことが目的で、原因究明は後回しでも構いません。

止血を選ぶ基準は、影響の大きさと戻しやすさです。

切り戻しやフラグで戻せる形を普段から準備しておくと、初動が安定します。

止血後に「何が変わったか」を記録しておくと、後から原因を追いやすくなります。

止血の実施後は、影響が本当に下がったかを監視で確認します。

止血は「やったかどうか」ではなく「効いたかどうか」で評価します。

• 切り戻し（前の安定版へ戻す）
• フラグ（影響範囲を絞って無効化する）
• 縮退（重要機能だけ維持する）
• 監視の確認（エラー率、レイテンシ、アラート）
• 代替導線（ユーザーへの回避策、サポート向け案内）
• 追加の観測（ログ増量、ダッシュボードの切り替え）

連絡と記録（誰に何をいつ）

連絡は「現状」「影響」「次の更新時刻」を固定フォーマットで行うと混乱が減ります。

固定フォーマットがあると、受け手が必要な情報を見落としにくくなります。

記録は後で報告テンプレに転記できるように、時刻つきで事実だけを残します。

判断の根拠となった観測値も一緒に残すと、あとから振り返りやすいです。

連絡は短く、記録は丁寧に、を意識すると運用が崩れにくいです。

連絡を減らしたい場合は、更新時刻だけは必ず守り、安心感を作ります。

• 連絡先（当番、責任者、CS、関連チーム）
• 共有内容（影響、暫定対応、次報の予定）
• 記録粒度（時刻、事実、判断、実施）
• 更新間隔（何分ごとに次報を出すか）
• 停止判断（いつ障害対応をクローズするか）
• ログ保全（必要なログを保存しておくか）

バグ報告文を作成する（テンプレ＋短い記入例）

報告文は「再現性」と「次回の学び」を残すための成果物で、修正の一部として扱います。

報告が揃っていると、同種の不具合が起きたときに復旧が速くなります。

報告文は長文よりも、欠落がないことを優先します。

報告テンプレを使うと、個人差を減らし、後から探しやすい記録になります。

概要（例つき）

概要は一文で「どの機能で何が起きたか」を書きます。

事象の表現は主観を避け、観測できた症状をそのまま書きます。

例として「特定条件でログイン後に画面が真っ白になる」などの症状を短く書きます。

可能なら発生率や発生条件も添えると、優先度判断がしやすいです。

概要はサポートや関係者が最初に読むので、専門用語を増やしすぎないようにします。

概要に「ユーザー影響」と「暫定回避策」があるなら、最初に短く書きます。

原因（例つき）

原因は事実と根拠を中心に書き、推測は推測として明示します。

根拠はログ、メトリクス、差分、再現結果のいずれかで示します。

例として「キャッシュが古いまま参照され、権限チェックが誤判定した」などの因果を短く書きます。

原因が未確定なら、確度と次の検証案を書いておきます。

原因が複合する場合は、主原因と副原因を分けて書きます。

原因の説明は「なぜそれが起きたか」だけでなく「なぜ検知が遅れたか」も含めると再発防止に効きます。

修正内容（例つき）

修正内容は差分の意図が伝わるように「何を変えたか」を書きます。

止血と恒久対応を分けた場合は、両方の差分を区別して書きます。

例として「ガード追加と条件修正で、異常系は安全にフォールバックする」などを短く書きます。

変更点が複数なら、要点だけ箇条書きにして読みやすくします。

修正の影響が広い場合は、なぜその方法が安全かも一文で添えます。

修正内容には「戻し方」と「監視の見方」も簡単に添えると、本番運用が安定します。

影響範囲（例つき）

影響範囲はユーザー・機能・データの三点で書きます。

データ影響がある場合は、復旧や補填が必要かも合わせて書きます。

例として「管理者以外の一部ユーザーで、一覧の表示が欠ける」などを短く書きます。

問い合わせの導線が必要なら、暫定回避策も書きます。

影響範囲は過小評価しやすいので、根拠が薄い場合は広めに書きます。

影響範囲を広めに書いた場合は、後で絞れた時点で追記して更新します。

テスト／確認事項（例つき）

テストは再現手順と回帰観点を含めて書き、確認事項は運用の宿題として残します。

確認事項はチケット化し、期限と担当が分かる形にしておきます。

例として「境界値と権限差分のテストを追加し、監視アラートを強化する」などを短く書きます。

監視が追加された場合は、どの指標を見ればよいかも一緒に書きます。

確認事項は「今やること」と「後でやること」に分けると、対応が止まりません。

確認事項は多くなりがちなので、優先度を付けて着手順を決めます。

よくある質問と実務の補助

現場で詰まりやすいテーマを先回りして整理し、運用を安定させます。

章を読んでも判断できないときは、まず「再現」と「影響範囲」の情報が足りているかを見直します。

迷ったまま実装に入ると、差分が増えて検証が弱くなるので、情報収集に戻ります。

質問が出たら、テンプレのどの項目が埋まっていないかに注目すると、次に集める情報が決まります。

Claude Codeに任せすぎると危険なケース

AIに任せるときに危険なのは、要件が曖昧なまま大きな変更を提案させてしまうケースです。

AIはもっともらしい案を出せる一方で、チームの前提や運用ルールは自動では守りません。

差分は必ず人がレビューし、再現手順とテストを先に用意してから生成結果を当てはめます。

影響が重い領域は、AIの出力を「調査の補助」に限定するのが安全です。

AIの出力は便利ですが、責任の所在は人に残ることを常に意識します。

AIに任せるなら「小さな差分」「明確な制約」「観測済みの事実」をセットで渡します。

• 仕様が曖昧で正解が一つに定まらない
• セキュリティや権限、課金のように影響が重い
• データ移行やスキーマ変更を伴う
• ロールバックできない本番変更を含む
• 監視やテストなしで大きな差分を入れたくなる
• 生成物の意図を説明できないまま採用したくなる

チームで使うときの運用ルール

チームでAIを使うなら、入力と出力の保存とレビュー観点を先に決めておくと安全です。

入力に含める情報は最小にし、秘匿情報や個人情報は原則として含めません。

生成物は「提案」として扱い、最終判断は必ず担当者とレビュー担当が行います。

責任の所在を曖昧にしないために、PRには人間の判断理由も残します。

AIの提案を採用しない判断も、後で学びになるので短く残します。

運用ルールは厳しすぎても形骸化するので、最小の必須事項を決めて守り切ります。

• 入力に含めてよい情報の範囲を定める
• 出力はPRに貼り、根拠と検証結果を添える
• 変更点が大きい場合は段階的にコミットする
• 出力の採用可否と理由を短く記録する
• 生成物のレビュー観点（影響範囲、戻し方、テスト）を固定する
• 生成物の撤回基準（危険なら戻す判断）を決める

よく使うバグ修正プロンプト集

プロンプトは「調査」「再現」「テスト」「報告」に分けると再利用しやすいです。

プロンプトは短くてもよいので、観測結果と制約条件を必ずセットで渡します。

必要な文脈だけを渡し、推測で作らせないように観測結果をセットで渡します。

生成結果はそのまま採用せず、差分とテストの観点を人が確認します。

プロンプトの出力は「候補」を出させ、最終的な決定は人が行います。

プロンプトは毎回改善し、よく使う形をテンプレとして残します。

• 調査：このログから原因候補を3つに絞り、検証順を提案して
• 再現：再現手順を最小化し、期待結果と観測点を整理して
• テスト：回帰と境界の観点を列挙し、最小のテストセットを提案して
• 報告：テンプレの各項目を1文で埋める下書きを作って
• 変更：最小差分での修正案を2案出し、リスクと戻し方も書いて
• レビュー：この差分の影響範囲と不足テストを指摘して
• 運用：本番障害向けの連絡文テンプレを3パターン作って

バグ修正後に必ず確認するチェックリスト（完了条件）

最後にチェックリストで抜けを潰し、完了条件を明確にして終えます。

チェックリストは「作業の終わり」を決めるための道具で、精神論ではありません。

チェックリストは毎回使い、例外がある場合は例外として記録します。

チェックリストを使い続けると、チームの暗黙知が明文化され、改善点が見つけやすくなります。

完了条件（全部Yesならマージ／リリース可）

下の最終チェックがすべてYesなら、原則としてマージやリリースに進んでよいと定義します。

完了条件を明確にすると、個人の経験差による判断ブレが減ります。

例外がある場合は、その理由と追加確認をPRに明記します。

例外対応は例外のまま残し、次回の改善点として扱います。

例外が続く場合は、完了条件そのものを見直してチームに合う形へ更新します。

完了条件は「守れること」が重要なので、増やしすぎず、必要なら別途チェックに分離します。

最終チェック項目（再現／回帰／監視／記録）

最終チェックは「再現」「回帰」「監視」「記録」の四分類で確認します。

ここでYesが揃わないなら、修正を追加するか、影響とリスクを説明して判断を仰ぎます。

Yesで答えられない項目があれば、対応か判断のエスカレーションを行います。

エスカレーションは「現状」「影響」「選べる選択肢」をセットで出すと速くなります。

エスカレーションは遅れが致命的になるので、迷ったら早めに出す方針にします。

エスカレーションを出す前に、事実と推測を分けて整理しておくと判断が速くなります。

• 再現：修正前は再現し、修正後は再現しない
• 回帰：周辺機能の主要フローが通る
• 監視：観測指標が想定どおりでアラートが妥当
• 記録：原因、修正、検証、影響、運用宿題が残っている
• 戻し方：問題が出たときの切り戻し手順が明確である
• 周知：必要な関係者へ共有が済んでいる
• 宿題：恒久対応のチケットが作られ担当と期限が決まっている