最近の記事

DevOps Policy Implementation Guide

参考・優先順位をつけるなら？

1. バージョン管理システムの導入 … ないとは思えないが、もしないなら
2. DevSecOps … 特にIAMとSecurityGroupは本番リリースされると権限縮小が困難
3. 予算アラート … 悪くするとビジネス継続に関わるリスクになるので予算アラートだけは優先
4. 監査ログ管理 … すぐできる、記録が残らず悪用を牽制できないのは危険
5. ログ管理、メトリクス監視 … 障害の予兆・発生に気が付けないのは不味い
6. IaC … 生成AIが利用できる今なら手間も少ない。変更管理や自動化の基盤
7. CI/CD … 最低限の品質ゲートだけでも確保
8. その他 … あとは状況次第で

Development Document Management

開発用ドキュメントの管理に関するポリシーを述べる。

整合性の方針

• 仕様・設計・コード間の整合性を維持するよう努めること。
  • ただし全ドキュメントの整合性を100%保証しようとする仕組みは構築しない。コスト・期間・精度などの面から現実的でないためである。次善策としてAIと人間のレビューによって不整合を減らすことをベストエフォートで行う。
  • チェックリストや自動テスト等を通し、用途に応じた品質を担保すること。決済などクリティカルな機能は速度より齟齬や抜け漏れがないことのほうが重要である。
• 整合性維持コストが高い仕様・設計は必要最小限に抑えること。
  • 仕様に重要でない詳細を含めない。コードのサマリーが必要であれば生成する（例: terraform-docs）。
  • ドキュメントはDRYに保ち、同一情報の重複管理を避ける。すなわち他のドキュメントに既に書かれていることを再度書かない。同じ内容を別の言葉で繰り返さない。
  • 整合性を維持しないでよいドキュメントを明示する
    • 例） コード生成のための作業指示書
• 仕様とコードのどちらが正しいかについて、機械的な優先順位を定めない。正しいコードを間違った仕様に合わせて変更してはならない。
  • 注） 生成AIの暴走の防止が主な趣旨である

Development Charter

コーディング、設計、インフラストラクチャ、運用に関わるすべての活動は本文書に準拠させること。

1. セキュリティ

常日頃（Business As Usual）から対応

セキュリティは後付けではなく、最初から組み込むこと。 各セキュリティスキャンやレビューは定期的またはリリース前に実施し、検出事項は放置せず何らかの対処を行うこと。

注） 対処は解決だけでなく、他の施策による対応、あるいは対応不要の判断も含む。ただし対応不要とする場合は理由を記録しレビューで承認を得ること。

権限管理

必要ない権限は極力渡さないこと（最小権限の原則）。

どうしても必要な場合はそのときだけ権限を付与すること（例・ブレイクグラスやJust-In-Timeアクセスの利用）。

2. 信頼性

コード品質

すべてのコードはプロダクション品質の基準を満たさなければならない。コード品質はリンター、静的解析ツール、フォーマッタなどのツールと人間またはAIによるレビューによって向上させ、テストによって保証する。コードは仕様とコーディング標準に準拠させること。

厳密なテストファースト開発は必須ではないが、自動テストは常に実装すること。ユニットテストのコードカバレッジはあくまで参考とし、重要ロジックが網羅されていることを優先する。ただし決済などのクリティカルな箇所は100%のカバレッジを実施すること。また全ての関数が一度は呼ばれること。

結合テスト機能のカバレッジは全機能を網羅すること。

仕組みによる信頼性向上

信頼性向上は仕組みによって担保すること。一個人の能力や注意力、献身に組織として依存しないこと。

自動化の推進

頻繁に行う作業や信頼性が重要な作業はなるべくコード化・自動化すること。手動作業と比べてオペミスが少なく、再現性に勝り、かつAIの活用も容易である。

変更管理

重要な変更は内容・理由・影響を記録すること。 また独断で行わず、レビューを経て承認を受けること。

3. 運用上の優秀性

設計・コード・UIの標準化

どの作業も標準化を推進すること。誰であれ同じタスクは同じ方法で対応できるべきであるし、同じ目的を持つ設計は同じ構造を持つべきである。

可観測性、モニタリング

ログやメトリクスを用意し、テストや障害調査を可能にしておくこと。すべてのシステムコンポーネントは可能な限り可観測であるべきである。 障害の予兆や発生をシステム的に検知できるようにすること。

トレーサビリティ

重要な事項は記録を残すこと。（例・本番作業やアーキテクチャ決定など）

成果物ベースの評価

十分な品質の成果物の生成を目的とすること。既存プロセスを守っていれば不十分な品質の成果物を出してもよい、とはならない。必要に応じてプロセス改善や例外対応を行い、品質を確保すること。その理由と影響を記録し、適切な担当者の承認を得ていれば、例外対応も差し支えない。

ただし正当な理由なく定められたプロセスを無視してはならない。（例・面倒だからテストせずリリース）

※ これは結果責任を作業者に負わせることではなく、劣化あるいは硬直化したプロセスの弊害の軽減を目的としたポリシーである。

非難なき事後分析

障害発生時は個人のミスを責めるのではなく、ミスを誘発した、あるいは防げなかった『システムやプロセスの欠陥』を特定し、根本原因を解決すること。

継続的改善

作った仕組みは定期的または必要時に見直すこと。

4. パフォーマンス効率

設計段階からのパフォーマンス考慮

パフォーマンス要件は事前に定義し、継続的に検証すること。本番相当のデータ量でスケーラビリティを確かめること。

ただし最適化はバランスを保たなければならない。明確なパフォーマンス上の必要性がない限り、早すぎる最適化や過度な最適化は避ける。

5. コスト最適化

開発・運用のコスト最適化は要件を満たす範囲内で行うこと。ただし不要な支出は避ける。

AI Governance

AIの活用による生産性向上とリスク低減を両立するため、最低限の原則と禁止事項を定める。

基本方針

AIは目的に対して妥当で、かつリスクを許容できる場合に用いる。 全ての用途を一律で許可あるいは禁止するのではなく、用途やリスクに応じた取り扱いを行う。

AI利用の定義

本ポリシーにおけるAI利用とは、生成AI、機械学習モデル、推論API、外部AIサービスその他これに準ずる仕組みを業務やサービスに使うことを指す。

利用の原則

AIの出力は最終的に人間が持たねばならない。 出力の結果にだれも責任が持てない使い方をしてはならない。

リスクに応じた取り扱い

AI利用は一律に扱わず、影響の大きさに応じて管理レベルを変える。

• 低リスク: 例） 公開情報を元にした下書き、要約、作業の軽微な補助
• 中リスク: 例） 内部データを使う処理、対外文書の作成補助
• 高リスク: 例） 決済、契約、個人情報、機密情報、影響が大きい意思決定

影響が大きいものは、確認や記録の作業を強く行う。 リスクが高すぎて許容しがたい場合はAIを利用してはならない。

人による裁可

重要な判断は最後に人が確認し、裁可すること。

最初から全自動化ありきで設計せず、自動化してよい範囲、人が承認すべき範囲をリスクに応じて決定すること。

入力データの取り扱い

個人情報、機密情報、秘密情報をそのまま外部AIサービスに投入してはならない。 分析に用いる場合は事前に匿名化・マスキングし、流出しても問題ない状態まで無毒化すること。

学習利用、再利用は拒否すること。

誤りを織り込んだ出力の扱い

AIの出力は常に誤りうる前提で扱う。

• 数値や契約、対外説明など重要情報は原典確認する
• コードや設定変更はレビューとテストを実行する

禁止事項

以下は禁止する。

• 法令、契約、社内規程に反する形でAIを利用すること
• 差別、不当な不利益、権利侵害を招く用途に使うこと
  • 商用利用・再利用が規約で禁止されている生成物やAIによるライセンス汚染が問題となるOSSの導入にも注意すること
• AIサービスに機密情報を入力すること
• 高リスク領域で人の確認を省くこと

記録と文書化

AI利用を業務に導入する場合は、黙って行うのではなく、明示的に証跡を残した上で行うこと。

保存形式やフォーマットは自由だが、下記が含まれるようにすること。

• 目的・用途と対象業務
• 利用開始日
• 利用者および責任者
• 利用するAIやサービスの名称
• 入力するデータの種類
• 想定リスク

また見直し日、変更履歴、事故や問題も随時記録すること。

導入後の見直し

AIの利用は継続的に見直すこと。

確認対象の例

• 利用のされかた
• 想定外の使われ方
• コスト
• 外部サービスやモデルの仕様変更
• 法令、契約、社内ルールの変更
• 苦情、事故、ヒヤリハット

レビュー頻度は影響に応じて決める。

• 高リスク: 必要時および定期的（例・四半期ごと）
• 中リスク: 変更時および定期的（例・半年ごと）
• 低リスク: 必要時

問題発生時の対応

AI利用で問題が起きた場合は、まず被害拡大を止め、その後に原因と再発防止を確認する。

対応の基本

• 利用停止
• 関係者への連絡、エスカレーション
• 影響範囲の確認
• ログと証跡の保全
• 原因調査
• 再発防止
• 必要に応じて公表、報告、顧客対応

例外

業務上やむを得ず本ポリシーの例外運用が必要な場合は、記録を残し、かつ責任者の承認を得て行うこと。

AI-Driven Development

AIを活用した開発におけるポリシーについて述べる。

セーフティファーストとリスクコントロール

AIは安全を確保した上で利用する。ただしここでいう安全の確保とはリスクゼロのことではなく、リスクを許容できる範囲内に収めることである。

たとえAIが有用と思われる業務であっても、許容できないリスクがある場合は利用してはならない。例えば下記のようなことは行わないこと。

• 例）機密情報を読ませる、重要データの削除権限を与える

リスクが許容範囲内に収まっている場合、リスクの度合いに応じた防御策を講じた上で利用する（リスクコントロール）。

• 例) データの流用リスクに対して利用が許可されるデータの明示と流用禁止の契約で対応

なお上記を実現するための防御策は、AI自体の機能に頼ってはならない（例えば.gitignoreを用いた閲覧禁止設定）。

積極的な活用

AIを積極的に活用する。

セキュリティ上許容できる範囲内で、必要な情報やツールへのアクセスを十分に提供すること。

精度を上げ、かつコストを減らすため、AIには成果物の生成に必要な情報を十分渡し、一方でノイズ情報を極力減らすこと。

精度に応じたプロンプトの作りこみ

プロンプトは要求精度に応じて調整すること。

• さほどの精度が必要ない内容はワンショットプロンプトでよい
• 高い精度が必要な作業はコンテキストエンジニアリングやプロンプトエンジニアリングを考える
  • プロンプトの作り込み自体に工数がかかるため、可能なら使いまわしや共有できるようにする

なおプロンプトを書くより手で行ったほうが早いことは、手で行うこと。

コンテキストエンジニアリング（プロンプトエンジニアリング含む）

• 気づきづらいノイズ源は最小限にすること。
  • 例えば自動挿入コンテキスト。より具体的にはClaude CodeのCLAUDE.mdと履歴
• 巨大すぎるプロンプトが必要になるなら、タスクを分割して小さくすること
• スクリプトやツールで済むものはそちらを使うこと
  • そのためのスクリプトやツールをAIに作らせればよい
• 指示を出す前に調査・確認させること
• 公式MCP, 公式プラグインなどは積極的に利用すること
• 重要な指示はどのような指示を出したか後から追跡できるようにすること
• 繰り返し行う指示は再現可能にしておくこと

品質安定化

• 再現性の確保と品質安定化のため、ポリシーやルール、手順を整えること。
• また、なるべく自動化すること
• ただし、プロセスの整備や自動化にかかるコストがメリットに見合わない場合は避けること
• 「プロジェクトの頭で整え、末で保証する」。すなわち最初に要求と実現方式を整えた上でAIに実行させる。品質を保証するのはテストである。
  • AI駆動開発も「システムの品質はテストの品質によって決まる」
  • AIの生成はランダム。品質もランダム。AIにチェックさせても、チェック品質自体がランダム。 -> どれほどプロセス構築を頑張ってもこの品質のばらつきの壁を越えられず、プロダクト品質に届かない

コスト管理

• AI利用額は監視するか、あるいは上限を設定すること

AIファースト

• AIが管理しやすい設計を行う。
  • 凝集やモジュール化などにより、長大なプロンプトや広範なコンテキストがなくとも高い精度がだせるようにする
  • コンテキストに用いれるよう、意図を保存して振り返れるようにしておく
  • 人手を介さずともコンテキストを取得できるようにする
• 仕様駆動開発（Spec Driven Development）を積極的に利用する

Log Management

ログ管理について述べる。

ログを管理する目的

ログは開発・運用に欠かせないものであるから、適切に収集と保管を行う。

• 監視: 例）正常に動作していることを確認する
• 調査: 例）障害調査のための現状把握に使う
• 分析: 例）ユーザーの挙動から導線の有効性を確認する
• 監査: 例）記録されていることを見せて悪用をけん制する

ログの基本要件

ログは目的に応じ以下の要件を満たした状態で保存する。

• 重要度に応じて適切に分類されていること
• 検索および分析が可能な形式であること
• 個々の処理や操作を追跡可能であること

取得するログは例えば下記のようなものがあげられる。

• インフラやアプリケーションの重要な処理の結果。例）エラーやバッチの処理結果など
• ユーザーの動向記録 例）アクセスログ
• 設定変更などの重要な操作。例）管理権限を持つユーザーの追加

何を記録してはいけないか

セキュリティおよびコスト最適化の観点から、下記のようなログを記録してはならない。

• 機密情報（個人情報、パスワードやAPIキー等）
  • 適切なマスキングまたは除去を行う
• 利用価値の低いログ(一時的なデバッグログなど)
  • 出力しないか、あるいは受け入れ元でフィルタ/サンプリングする

いつまで保持するか

ログの保持期間は用途によって変更する。例えば下記のようにする。

• 本番環境の決済などの重要なログ -> 最低数年（関連の法令やガイドラインがあるなら必ず満たすこと）
• 本番環境のアプリケーションのエラーログ -> 最低1年
• 開発環境のログ -> 最低保持期間は定めないがおおむね数カ月

必要以上に保持しないほうがコスト最適化のためにはよいが、必要になった際に消してしまっているほうが通常は問題が大きいため、余裕をもって設定する。

保持期間を過ぎたログは、速やかに削除または適切にアーカイブする。

セキュリティ

ログの保全のため、業務に必要なものに対してのみ操作権限を与える。例えば下記のようにする。

• ログの閲覧は必要な人員のみ可能
• ログの削除は管理者のみ可能
• ログの改変は誰であれ禁止。どうしてもやむを得ない場合は、記録を残した上で特例措置として実施する（ブレイクグラス）

ログの保管場所

ログの保管はセキュリティが保て、かつ毀損しないよう十分な信頼性を持った手段で行う。例）AWS S3 ただし障害対応や監査対応に支障が出ない程度の時間で参照できること。

Monitoring

システムの監視ポリシーについて述べる。

監視の定義

あるべき状態が保たれていることを、適切な頻度で確認し続けること。そして保たれなくなったら検知すること。

1. あるべき状態の例
   • サービスが動いている
   • SaaSの費用をちゃんと払っている。そして金額も妥当な範囲に収まっている
   • バッチが時間内に終わっている。途中で停止せず処理が最後まで行われている

-> どういう状態であってほしいのかから入る。手段からスタートしない。

2. 適切な頻度で確認し続けることの例
   • DBの停止や再起動は起きたら即
   • WEBサービスの外形監視はN分おき
   • 指標のトレンド確認は週次でいいことがほとんど

-> 対応の緊急性に応じて合理的に設定。やりすぎはコストを増やす。

3. 保たれなくなったら検知することの例
   • 緊急性の高いアラートはメールだけでなく電話も使って受け損ねを防止
   • 重要だが緊急ではないエラーのアラートは随時メール
   • 重要でも緊急でもないエラーはサマリーレポートを毎日決まった時間に確認

-> こちらも緊急性に応じて受ける方法を用意。監視漏れも監視疲れもよくない

なにを監視すべきか、すべきでないか

監視対象は、まずあるべき姿を洗い出し、そこからどう正常性を確認するのかを考えていく。あるべき姿はプロジェクトの性格によって異なるため、プロジェクトの性格に応じてカスタマイズする。監視内容によってはアプリケーションに可観測性のための機能を持たせる。どんなサービスでもこれだけやっておけば妥当と保証できるチートシートは元から存在しないのであり、手段から対象を決めるべきでない。

監視対象の違いの例)

• B2Cの情報提供系サービス : 24時間365日サービスが落ちないこと、レスポンス速度も妥当であること -> サービスの外形監視、レスポンス速度の監視等
• バッチ処理系のサービス: 処理時間が突き抜けないこと、途中で止まっていないこと、また過去の実施時と比べて極端に取り扱うデータ量が減っていないこと -> 処理時間や実行結果をログでだすようにした上でのログ監視、アプリケーション組み込みの簡易なレポートを定期的に確認する等

また監視は対応とセットである。対応ノウハウの共有のため、可能なものは手順や判断基準をあらかじめドキュメント化しておく。それが難しいものは対応後に記録を残して関係者が（許されるならAIも）いつでも参照できるようにする。

ノイズアラートの防止

不要な監視は行わない。メンバーの疲弊やアラートの見落としを誘発するためである。 このため追加は本当に必要か検討した上で行う。一度追加してしまうと、実際はフォールスポジティブばかりで役に立たないアラートでさえ、責任問題となるリスクにより削除しづらくなる。

まず、アラートの発報を伴う監視は対応可能性とセットで考える。対応不要あるいは対応不能なことに発報すべきでない。

意味のあるアラートの例

• データベース用サーバーのメモリ残量のひっ迫 -> スケールアップやスケールアウト
• 特定IPからの大量不正アクセス -> WAFやアプリケーションにフィルタ追加

意味のないアラートの例

• オートスケールの実行時にアラート -> 対応が必要ない
• AWSのCloudFrontの死活監視 -> 対応できることがない

具体例

ポリシーとしては上記のみであるが、理解の促進のためWEBアプリケーションを例にとって具体例を付け加える。

この場合、まずエンドユーザーつまり利用者にサービスが提供し続けられていること。ひっくり返すと、提供し続けられなくなるような事態になっていないこと（異常検知）、もしくはいずれ重大な障害が出ると予想されないこと（予兆検知）が必要である。この前提で、WEBアプリケーションで各レイヤごとに監視すると例えばこのようになる。

• ユーザー体験: 外形監視、レイテンシ監視など
• アプリケーション: ログ監視、エラー時の直接発報、ジョブキューの過剰滞留など
• インフラ: リクエストのエラー率（5XX）、アプリケーションサーバの稼働数（スケールアウトに関係）、マネージドサービスの強制メンテナンス予定、EOL予定、ドメインや証明書の残り日数など

次にそのサービスを続けていけること。このために具体的にはセキュリティやコストを監視する。

• セキュリティ: 脆弱性、マルウェア、悪意のあるアクティビティなど
• コスト: 通常ではありえない額の課金、Reserved Instance等割引サービスの残り日数など

また監視はアラートだけセットするのではなく、トレンドを見るためのメトリクスとそれをまとめたダッシュボードも用意する。問題の存在を告げるトレンドが出ていたら対応が必要である。例えばレイテンシが悪化していく一方であったり、メモリの残量が下がっていく一方であったりするなら、なんらかの不具合が隠れている可能性が高い。

• CPU使用率・メモリ使用率
• レイテンシ

一方で必要性の薄いアラート、有用性の低いアラートは流さない。

CI/CD

Why CI/CD?

• 手順実行の確実化
  • 手作業は漏れやすい、間違いやすい
  • 自動化で確実に
• 効率化
  • 毎回人力で行うのは手間がかかる。特にビルドを挟むものや手順が多いものは威力大
  • 自動化で効率よく
• 明確化
  • 人力だと見えない手順が隠れていて暗黙知になることも
  • 明文化で作業の透明性確保
  • 誰が実行したかもしっかり記録（トレーサビリティ）

セキュリティ重視

• 乗っ取られると被害が大きい。対策はしっかりと
• 基本は最小権限の原則とアカウント管理
• 最小権限の原則
  • 完璧主義でなくてもいい、ただしリスクを許容できる域まで落とす
  • 管理者権限は以ての外
• アカウント管理
  • CI/CDを編集できるアカウントはMFA必須
    • 業務利用のCI/CDにID・Passwordだけでログインしているアカウントは関与させない
  • APIキーもできる限り使わない
    • 短時間トークンやOIDCで回す
• GitHub Actionsはやや特殊。コード管理と権限管理を同時に行う
  • でないとセキュリティの穴が開きやすい

信頼性

• pre-buildコンテナの活用
  • 高速化というメリットもあるが、外部リポジトリに依存しなくて済む点もメリット
• バージョンは極力指定する
  • latest運用は思わぬ仕様変更で挙動が変わる恐れがある
  • 脆弱性の問題もあるので定期的な更新は必要
  • 手間はかかる
  • 重要なものだけ。完璧主義は報われない

なにで組むか？

• 利便性重視でいいならGitHub Actions、セキュリティ優先ならAWS CodePipeline
• 便利なのはGitHub Actions
  • GitHubとの連携が楽
    • コードも読めるPRもIssueも作れる
  • 開発者体験もいい
  • コスパも悪くない
  • 信頼できるメンバーで集まって小規模開発をするならこれでいい
    • シュッと作ってすぐCI/CDを実現できるのは強み
  • 一方セキュリティの穴を作らないように組むのはかなり気を遣う
    • GitHubと一体な分、守るべき場所が多い
    • アカウント管理もAWS IAM Identity Centerと比べると緩い
  • ビジネスの根幹となってるインフラのIaCを任せるべきかは考えどころ
    • IaCでCI/CDをやるなら強い権限を渡さざるを得ない
    • 強すぎる権限を渡すと設定の穴を突かれた際に被害が大きい
    • それなのに穴があきやすい
      • 「設定を完璧にやれば問題ない」はその通りだが、何年も運用する間ずっと完璧でいられるかが問題
• セキュリティ優先ならAWS CodePipeline
  • AWS・IaC・CI/CDで重要システムを構築するならこれが手堅い
    • フロントエンドやバックエンド（データ操作系以外）はGHA、インフラやマイグレーション等はこちらという使い分けもあり
  • アカウント管理は堅牢そのもの
    • 「SCP(サービスコントロールポリシー)を使った権限制限」「MFA必須」様々な工夫がある
  • 権限管理もGitHub Actionsよりさらに細かく設定可能
  • ただし設定が手間
    • AIのおかげでマシになったが、それでも設定には苦労する
    • セキュリティに強いのと裏表だが権限設定はとても細かいので大変
  • UXももっさり感ある
    • 大昔と比べると遥かに良くなってはいるがGitHub Actionsほど手軽かと言われると辛い
      • もっともGHAはその分セキュリティ面で泣き所がある

高速化

• ジョブの並列実行
  • 基本
• CPU数を確保できるインスタンスを利用しつつ、ジョブの中でも並列実行
  • 並列化して早くなればコスパもそこまで悪化しない
• キャッシュも実行
  • pre-buildを使うほどでなければ特に効く
• pre-buildコンテナの活用
  • 必要なツールを先に入れておく
  • 安定する、早い
  • ただし管理が手間
• それでも重いビルドやテストはGitHub ActionsのSelf Hosted Runnerも手
  • ハイスペックなマシンを使いやすい
  • 費用もお手頃

CI/CDをあえて避けるケースも

• つまりはオーバーエンジニアリングを避ける
• 実験環境で作業効率優先の場合
  • Try&Errorが多い場合はCI/CDを挟むと辛い
    • GHAがコンテナを立ち上げている暇に、ローカルでちょろっとなおしたスクリプトをすぐsync

Branching Strategy

ブランチ戦略のポリシーについて述べる。具体的なブランチ戦略（e.g., Git Flow, GitHub Flow, etc)には踏み込まない。

ブランチ戦略の目的

コードの品質と本番環境の安定性を、開発フローの構造によって担保する。

1. オペミスやAIの暴走によってコードの破壊や開発中のコードがリリースされるのを防ぐため、本番用のブランチを保護する
2. 品質保証のため、本番への変更は必ずレビューとCIによる自動テストを経てから行う
3. 後から追跡しやすいようブランチを用途によって区分する

また、これらは極力仕組みで保証し、個人の注意力に頼らないようにする。

ブランチ戦略とマージ戦略

なるべく独自戦略は避け、広く知られたブランチ戦略を用いる。実績に支えられた品質が期待できること、メンバーの学習コストを軽減できることが理由である。

どの戦略を用いるとしても、運用のブレを最小限に抑えられるよう、なるべくカスタマイズを避ける。

混乱防止のため、マージ戦略も同一のリポジトリでは単一のマージ戦略を用いる。その場その場で異なるマージ戦略を用いたり、あるいは複数のマージ戦略を混入させない。

命名規則

原則として採用したブランチ戦略の命名規則に従う。

命名規則は極力自動検証する（例：Git hook / CI）。

バージョン番号はセマンティックバージョニングで統一する（例: 1.2.0）。

仕組みによる強制

いずれのルールも仕組みによっておのずから守られるようにする。品質と保守性向上のため開発ルールは極力守られるべきであるが、人の注意力あるいはAIのプロンプト順守には100%を期待し得ない。これらの仕組みはGitHub Rulesetのような元から用意されている仕組みだけでなく、Git フックやGitHub Actionsのように後から追加できる仕組みを用いる。

例）

• GitHub Ruleset によるmainブランチの保護
• Gitフックによるコミットメッセージの整形
• GitHub Actionsによる自動テストの強制

緊急時・想定外のケースのため管理者が保護ルールをバイパスする仕組みは残しておく。ただし常時バイパスできる必要はなく、ブレイクグラス方式でもよい。

バイパスした際は、その理由を後で追えるよう理由を記録する（コメントでよい）

常にバイパスが必要になる運用は問題であるため是正する。

ルールの管理

属人性の防止・トレーサビリティの向上のため、保護ルールは極力IaCで管理し手動での設定変更を避ける。どうしても避けられない場合は記録を残す。

リリース方法

• オペレーション品質向上のため、リリースは人手を挟まずにCI/CDで完結させる。
  • 逆に人手を介する運用（例：タグを切る際に担当者が元のコミットとバージョンを手入力する）は避ける。

GitHub Access Security Tiers

さまざまな権限付与方式

AIにGitHubを操作させる方法としては、HITL（Human In The Loop）、プロキシ利用、GitHub App、PAT格納などの方式があり、それぞれ利便性やリスクが異なる。単独で他のすべてに勝る方式はないため、用途に応じて選択するとよい。

※ 流出リスクについて: 上記はあくまでAIによるPAT流出リスクについての評価である。オペミス等別の要因によって流出するケースは議論の外である。

使い分け

• 極めて高いセキュリティを求められており、わずかなリスクの可能性すら許容しがたい -> HITL
• PRスパム程度ならともかくPAT漏洩リスクの可能性は一切許容できない、あるいは諸事情でGitHub Appが使えない -> プロキシ
• 他の施策と合わせればインシデント発生時の被害を許容範囲内に抑えられる -> GitHub App
• 漏洩してもさして問題ない環境（実験用など）である -> PAT直渡し

利用方法

HITL

手動で利用するのと同じ。

AIはコマンドを指示したり、テキストを作ったりする程度である。

プロキシ利用

PAT/Tokenをプロキシに配置し、AIがアクセスできないようにする。AIはHTTP経由でGitHub APIを呼ぶだけである。

理屈は難しくなく、docker-composeでDevContainerを起動してサイドカーにNginxを使い

  gh-proxy:
    image: nginx:alpine
    volumes:
      - ./gh-proxy/default.conf.template:/etc/nginx/templates/default.conf.template:ro
    environment:
      GH_PAT: ${GITHUB_CLAUDECODE_KEY}

環境変数でPATをこのような設定を読み込ませるだけでも利用できる。なお、なるべくFine-grained personal access tokensを用い、強すぎる権限を付与しないこと。