AI駆動開発工房

Policies

DevOps Policy Implementation Guide

Policies
大項目ポリシー思想やアーキテクチャツール(例)
セキュリティセキュリティは後付けではなく、最初から組み込むこと。
各セキュリティスキャンやレビューは定期的またはリリース前に実施し、検出事項は放置せず何らかの対処を行うこと。

注） 対処は解決だけでなく、他の施策による対応、あるいは対応不要の判断も含む。ただし対応不要とする場合は理由を記録しレビューで承認を得ること。		DevSecOps、SAST / DAST / SCA、脅威モデリング (Threat Modeling)GitHub Dependabot、Checkov、tflint、Trivy、AWS Inspector
セキュリティ必要ない権限は極力渡さないこと（最小権限の原則）。

どうしても必要な場合はそのときだけ権限を付与すること（例・ブレイクグラスや短命トークンの利用）。		最小権限の原則、RBAC / ABAC、JIT (Just-In-Time) アクセス、PIM、ブレイクグラス手順AWS IAM AssumeRole、IAM Identity Center、AWS SSO (短命トークン発行)、CloudTrail(PIMの一環として監査ログの保存)、AWS サービスコントロールポリシー（ブレイクグラスで利用）
信頼性すべてのコードはプロダクション品質の基準を満たさなければならない。コード品質はリンター、静的解析ツール、フォーマッタなどのツールと人間またはAIによるレビューによって向上させ、テストによって保証する。コードは仕様とコーディング標準に準拠させること。

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

結合テスト機能のカバレッジは全機能を網羅すること。		CI (継続的インテグレーション)、静的コード解析、自動テスト (ユニット / 結合 / E2E)、AI支援コードレビューGitHub Actions、Checkov、tflint、Claude Code、Gemini、各言語の自動テストツール（例・go test）、Playwright
信頼性信頼性向上は仕組みによって担保すること。一個人の能力や注意力、献身に組織として依存しないこと。SRE (Site Reliability Engineering)、IaC、プロセス標準化（例・テストやリリース後の確認、ロールバックの用意の義務付けなど）、フェイルセーフ設計、カオスエンジニアリング、冗長性の確保Terraform、Fault Injection Service AWS
信頼性頻繁に行う作業や信頼性が重要な作業はなるべくコード化・自動化すること。手動作業と比べてオペミスが少なく、再現性に勝り、かつAIの活用も容易である。CI/CD、IaC (Infrastructure as Code)、ChatOpsgit + GitHub、GitHub Actions、Terraform、Docker、Ansible、Slack(連携用)
信頼性重要な変更は内容・理由・影響を記録すること。
また独断で行わず、レビューを経て承認を受けること。		Pull Request、ブランチ保護ルール、GitOps、チケットドリブン、ITS / BTS (課題管理)GitHub、GitHub RuleSet、GitHub Issue
運用上の優秀性どの作業も標準化を推進すること。誰であれ同じタスクは同じ方法で対応できるべきであるし、同じ目的を持つ設計は同じ構造を持つべきである。ベストプラクティスやアーキテクチャの採用、ポリシー、コーディング規約、プロセス標準化Terraform Official Documents、ADR、OpenAPI、GitHub テンプレート機能
運用上の優秀性ログやメトリクスを用意し、テストや障害調査を可能にしておくこと。すべてのシステムコンポーネントは可能な限り可観測であるべきである。障害の予兆や発生をシステム的に検知できるようにすること。可観測性 (Observability)、APM、分散トレーシング、ログ管理、メトリクス監視CloudWatch、AWS X-Ray、S3、Athena、Datadog、OpenTelemetry、AWS Chatbot、Amazon Connect / PagerDuty、Slack、メール
運用上の優秀性重要な事項は記録を残すこと。（例・本番作業やアーキテクチャ決定など）ADR (Architecture Decision Record)、監査ログ管理、バージョン管理履歴AWS CloudTrail、GitHub Issue、Git
運用上の優秀性十分な品質の成果物の生成を目的とすること。既存プロセスを守っていれば不十分な品質の成果物を出してもよい、とはならない。必要に応じてプロセス改善や例外対応を行い、品質を確保すること。その理由と影響を記録し、適切な担当者の承認を得ていれば、例外対応も差し支えない。

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

※ これは結果責任を作業者に負わせることではなく、劣化あるいは硬直化したプロセスの弊害の軽減を目的としたポリシーである。		継続的改善、承認ワークフローSonarQube (Quality Gate機能)、GitHub Environments (承認機能)、Jira Service Management
運用上の優秀性障害発生時は個人のミスを責めるのではなく、ミスを誘発した、あるいは防げなかった『システムやプロセスの欠陥』を特定し、根本原因を解決すること。非難なきポストモーテム (Blameless Postmortem)、根本原因分析 (RCA / 5 Whys)、インシデント管理フレームワークSlack、GitHub Issues、git(リポジトリにドキュメントを直接保存)
運用上の優秀性作った仕組みは定期的または必要時に見直すこと。レトロスペクティブ (KPT等のフレームワーク)、技術的負債の棚卸し、トイル削減Slack、GitHub Issues、git(リポジトリにドキュメントを直接保存)、AWS Well-Architected Tool、AWS Trusted Advisor
パフォーマンス効率パフォーマンス要件は事前に定義し、継続的に検証すること。本番相当のデータ量でスケーラビリティを確かめること。

ただし最適化はバランスを保たなければならない。明確なパフォーマンス上の必要性がない限り、早すぎる最適化や過度な最適化は避ける。		パフォーマンステスト / 負荷テスト、オートスケーリング、キャッシュ戦略、データベースのインデックスチューニングk6、サーバレスのマネージドサービス（AWS LambdaやAmazon Aurora Serverless等）、AWS Auto Scaling、Elasticache、スロークエリログ
コスト最適化開発・運用のコスト最適化は要件を満たす範囲内で行うこと。ただし不要な支出は避ける。FinOps、クラウドコスト監視・アラート、リソースの自動起動・停止スケジューリング、ライフサイクルルールAWS Cost Explorer、AWS Budgets、AWS Trusted Advisor、EventBridge Scheduler、AWS Backup

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

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

Development Document Management

Policies

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

整合性の方針

Development Charter

Policies

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

1. セキュリティ

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

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

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

権限管理

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

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

2. 信頼性

コード品質

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

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

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

仕組みによる信頼性向上

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

自動化の推進

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

変更管理

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

3. 運用上の優秀性

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

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

可観測性、モニタリング

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

トレーサビリティ

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

成果物ベースの評価

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

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

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

非難なき事後分析

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

継続的改善

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

4. パフォーマンス効率

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

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

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

5. コスト最適化

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

AI Governance

Policies

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

基本方針

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

AI利用の定義

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

利用の原則

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

リスクに応じた取り扱い

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

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

人による裁可

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

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

入力データの取り扱い

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

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

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

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

禁止事項

以下は禁止する。

記録と文書化

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

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

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

導入後の見直し

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

確認対象の例

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

問題発生時の対応

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

対応の基本

例外

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

Monitoring

Policies

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

監視の定義

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

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

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

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

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

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

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

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

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

監視対象の違いの例)

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

ノイズアラートの防止

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

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

意味のあるアラートの例

意味のないアラートの例

具体例

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

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

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

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

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

Log Management

Policies

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

ログを管理する目的

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

ログの基本要件

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

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

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

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

いつまで保持するか

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

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

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

セキュリティ

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

ログの保管場所

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

GitHub Access Security Tiers

Policies

さまざまな権限付与方式

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

モデル基本方式漏洩時の権限の寿命効率性流出リスク
HITL(Human In The Loop)AIがアクセスできない場所から人間がghなどで操作を実行（AIにPAT/tokenを渡さない）人手が常に必要ありえない
プロキシ利用PATを格納したプロキシに中継させる（AIにPAT/tokenを渡さない）使えるツールが限定され不便ありえない
GitHub AppGitHub Appが短命トークンを発行。それをAIが利用する短命高いありえるが悪用リスクは限定的
直接トークンPATをAIに直接付与長命高いありえる

※ 流出リスクについて: 上記はあくまでAIによる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を用い、強すぎる権限を付与しないこと。

git worktree

Policies

ポイント

ディレクトリ構成はこのようになる

<repository name>/
 ├─ .claude/
 ├─ .devcontainer/
 ├─ .git/
 ├─ src/
 └─ .worktrees/
     ├─ feature-example/
     └─ bugfix-example/

事前作業

worktree.useRelativePathsを有効化

git config worktree.useRelativePaths true

# useRelativePaths = true があるはず
cat .git/config

.worktrees/ を.gitignoreにいれておく。

ワークツリーの作成

新規のブランチを切る場合

git worktree add -b feature/example .worktrees/feature-example origin/main

すでにあるブランチを使う場合

git worktree add .worktrees/feature-example feature/example

Claude Codeの起動

作成したワークツリーまで移動した後でClaude Codeを立ち上げる。

cd .worktrees/feature-example
claude

ワークツリーの削除

git worktree remove .worktrees/feature-example

Dev Container

Policies

Why Dev Container?

Setup

設定ファイルの保存場所

単一コンテナ VS docker compose

バージョン指定

ベースイメージ管理

セキュリティ維持の取り組み

Claude Codeの動作設定

CI/CD

Policies

Why CI/CD?

セキュリティ重視

信頼性

なにで組むか？

高速化

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