ブランチ戦略のポリシーについて述べる。具体的なブランチ戦略（e.g., Git Flow, GitHub Flow, etc)には踏み込まない。
ブランチ戦略の目的
コードの品質と本番環境の安定性を、開発フローの構造によって担保する。
- オペミスやAIの暴走によってコードの破壊や開発中のコードがリリースされるのを防ぐため、本番用のブランチを保護する
- 品質保証のため、本番への変更は必ずレビューとCIによる自動テストを経てから行う
- 後から追跡しやすいようブランチを用途によって区分する
また、これらは極力仕組みで保証し、個人の注意力に頼らないようにする。
ブランチ戦略とマージ戦略
なるべく独自戦略は避け、広く知られたブランチ戦略を用いる。実績に支えられた品質が期待できること、メンバーの学習コストを軽減できることが理由である。
どの戦略を用いるとしても、運用のブレを最小限に抑えられるよう、なるべくカスタマイズを避ける。
混乱防止のため、マージ戦略も同一のリポジトリでは単一のマージ戦略を用いる。その場その場で異なるマージ戦略を用いたり、あるいは複数のマージ戦略を混入させない。
命名規則
原則として採用したブランチ戦略の命名規則に従う。
命名規則は極力自動検証する（例：Git hook / CI）。
バージョン番号はセマンティックバージョニングで統一する（例: 1.2.0）。
仕組みによる強制
いずれのルールも仕組みによっておのずから守られるようにする。品質と保守性向上のため開発ルールは極力守られるべきであるが、人の注意力あるいはAIのプロンプト順守には100%を期待し得ない。これらの仕組みはGitHub Rulesetのような元から用意されている仕組みだけでなく、Git フックやGitHub Actionsのように後から追加できる仕組みを用いる。
例）
- GitHub Ruleset によるmainブランチの保護
- Gitフックによるコミットメッセージの整形
- GitHub Actionsによる自動テストの強制
緊急時・想定外のケースのため管理者が保護ルールをバイパスする仕組みは残しておく。ただし常時バイパスできる必要はなく、ブレイクグラス方式でもよい。
バイパスした際は、その理由を後で追えるよう理由を記録する（コメントでよい）
常にバイパスが必要になる運用は問題であるため是正する。
ルールの管理
属人性の防止・トレーサビリティの向上のため、保護ルールは極力IaCで管理し手動での設定変更を避ける。どうしても避けられない場合は記録を残す。
リリース方法
- オペレーション品質向上のため、リリースは人手を挟まずにCI/CDで完結させる。
- 逆に人手を介する運用（例：タグを切る際に担当者が元のコミットとバージョンを手入力する）は避ける。
AIを活用した開発におけるポリシーについて述べる。
セーフティファーストとリスクコントロール
AIは安全を確保した上で利用する。ただしここでいう安全の確保とはリスクゼロのことではなく、リスクを許容できる範囲内に収めることである。
たとえAIが有用と思われる業務であっても、許容できないリスクがある場合は利用してはならない。例えば下記のようなことは行わないこと。
- 例）機密情報を読ませる、重要データの削除権限を与える
リスクが許容範囲内に収まっている場合、リスクの度合いに応じた防御策を講じた上で利用する（リスクコントロール）。
- 例) データの流用リスクに対して利用が許可されるデータの明示と流用禁止の契約で対応
なお上記を実現するための防御策は、AI自体の機能に頼ってはならない（例えば.gitignoreを用いた閲覧禁止設定）。
積極的な活用
AIを積極的に活用する。
セキュリティ上許容できる範囲内で、必要な情報やツールへのアクセスを十分に提供すること。
精度を上げ、かつコストを減らすため、AIには成果物の生成に必要な情報を十分渡し、一方でノイズ情報を極力減らすこと。
精度に応じたプロンプトの作りこみ
プロンプトは要求精度に応じて調整すること。
- さほどの精度が必要ない内容はワンショットプロンプトでよい
- 高い精度が必要な作業はコンテキストエンジニアリングやプロンプトエンジニアリングを考える
- プロンプトの作り込み自体に工数がかかるため、可能なら使いまわしや共有できるようにする
なおプロンプトを書くより手で行ったほうが早いことは、手で行うこと。
コンテキストエンジニアリング（プロンプトエンジニアリング含む）
- 気づきづらいノイズ源は最小限にすること。
- 例えば自動挿入コンテキスト。より具体的にはClaude CodeのCLAUDE.mdと履歴
- 巨大すぎるプロンプトが必要になるなら、タスクを分割して小さくすること
- スクリプトやツールで済むものはそちらを使うこと
- そのためのスクリプトやツールをAIに作らせればよい
- 指示を出す前に調査・確認させること
- 公式MCP, 公式プラグインなどは積極的に利用すること
- 重要な指示はどのような指示を出したか後から追跡できるようにすること
- 繰り返し行う指示は再現可能にしておくこと
品質安定化
- 再現性の確保と品質安定化のため、ポリシーやルール、手順を整えること。
- また、なるべく自動化すること
- ただし、プロセスの整備や自動化にかかるコストがメリットに見合わない場合は避けること
- 「プロジェクトの頭で整え、末で保証する」。すなわち最初に要求と実現方式を整えた上でAIに実行させる。品質を保証するのはテストである。
- AI駆動開発も「システムの品質はテストの品質によって決まる」
- AIの生成はランダム。品質もランダム。AIにチェックさせても、チェック品質自体がランダム。 -> どれほどプロセス構築を頑張ってもこの品質のばらつきの壁を越えられず、プロダクト品質に届かない
コスト管理
- AI利用額は監視するか、あるいは上限を設定すること
AIファースト
- AIが管理しやすい設計を行う。
- 凝集やモジュール化などにより、長大なプロンプトや広範なコンテキストがなくとも高い精度がだせるようにする
- コンテキストに用いれるよう、意図を保存して振り返れるようにしておく
- 人手を介さずともコンテキストを取得できるようにする
- 仕様駆動開発（Spec Driven Development）を積極的に利用する
