Ops Rules

---
name: ops-rules
description: Operational readiness checklist (security, cost, legal, data design, performance, incident response, LLM integration defenses) applied when a change touches deployment, infrastructure, external services, secrets, or user data.
---

# Operations Guidelines

本規範は単体で完結する（メイン会話・サブエージェントのどちらで読まれても前提を欠かない）。
開発方法論は同梱の dev-rules 規範を参照。
詳細チェックリストは [エンジニア歴20年の私が、素人バイブコーディング勢に物申す（Qiita）](https://qiita.com/Akira-Isegawa/items/00f23d206c504db2ac3b) を参照。

## 適用条件

変更が次のいずれかに触れるとき、着手前に本規範の該当節を確認する。ファイルパスではなく**変更の性質**で判定する（Dockerfile や `.env` のような設定ファイルに限らず、OAuth 認可・API クライアント・課金処理を持つアプリケーションコードも含む）:

- **デプロイ・インフラ** — コンテナ定義、CI/CD、PaaS 設定、環境変数の配線
- **外部サービス連携** — 外部 API の呼び出し・受け口、Webhook、OAuth、決済
- **秘匿値** — トークン・鍵・認可 ID の生成、保存、注入、ローテーション
- **ユーザーデータ** — 個人情報・関係者情報の取得、永続化、送信、削除
- **課金・レート** — 従量課金 API の呼び出し、クレジット消費、レート制限

該当しない変更（純粋なロジック・テスト・ドキュメント）では読み流してよい。

---

## 1. セキュリティ

- **シークレットをコードに直書きしない** — 環境変数 or シークレット管理サービスを使う
- **認証 ≠ 認可** — ログインできることと、他人のデータにアクセスできないことは別問題（IDOR）
- **入力は全て疑う** — サーバーサイドバリデーション必須、クライアント側は UX のためだけ
- **デフォルト設定を信用しない** — PaaS/BaaS のデフォルトは「開発者が楽」であって「安全」ではない
- **ログを残す** — 認証イベント、エラー、異常アクセスは記録する。ログにシークレットを含めない
- **本番でスタックトレースを返さない** — テーブル名・ファイルパス・SQL が漏れる。本番は抽象的なエラーメッセージのみ
- **AI 提案ライブラリを鵜呑みにしない** — ハルシネーション・タイポスクワッティングのリスク。npm/PyPI で実在確認、最終更新・スター数・ライセンスを検証

## 2. コスト管理

- **課金単位を事前に把握する** — リクエスト課金か、時間課金か、ストレージ課金か
- **予算アラートをコードより先に設定する**
- **リリース後に定期確認する** — 想定外のスパイクは早期発見

## 3. 法的確認

- **外部データ取得時** — スクレイピング可否、利用規約、robots.txt を確認
- **個人情報を扱う場合** — 個人情報保護法への準拠、プライバシーポリシーの必要性
- **OSSライセンス** — 依存ライブラリのライセンス互換性を確認

## 4. データ設計（永続性の判断）

使い捨てでないなら：
- **スキーマ設計を先にやる** — 後からの変更コストは指数関数的に増える
- **トランザクション境界を明確にする** — 部分的な書き込みが起きない設計
- **冪等性を確保する** — リトライで壊れない API 設計
- **開発環境と本番環境を分離する**

## 5. 性能見積もり

- **N+1 問題** — ORM 利用時は特に注意、クエリログで確認
- **インデックス設計** — 頻繁な検索条件には事前にインデックスを張る
- **想定負荷を明示する** — 「何人が同時に使うか」を設計前に確認

## 6. 障害対応

障害発生時の優先順位：
1. **止める** — 被害拡大を防ぐ
2. **記録する** — ログ、スクリーンショット、タイムスタンプ
3. **通知する** — 影響範囲を関係者に伝える
4. **原因を究明する** — 推測ではなくログから追う
5. **仕組みで再発防止する** — 人の注意力に頼らない

## 7. LLM 統合アプリの防御

LLM を組み込んだアプリは通常の Web セキュリティに加えて以下を必要とする：

- **プロンプトフェンシング** — ユーザー入力を XML タグ等で隔離し「データとして扱え」と LLM に指示
- **プロンプトインジェクション検知** — role override、system prompt 抽出、credential 要求をパターン検出。
  ブロックせずフラグのみ（偽陽性リスク回避、本来の防御は fencing 側）
- **出力漏洩スキャン** — LLM 応答に API キー、環境変数名、system prompt 本文が混入していないか
  post-generation でチェック
- **レート制限** — LLM 呼び出しは IP/ユーザー単位で sliding window 制限（コスト暴走と DoS 両方の防御）
- **入力正規化** — 全角/半角、Unicode 異体字、サロゲートペアを正規化してから validation

---

## Compliance Marker

本規範の適用条件に該当する作業では、作業報告・最終応答の末尾に `[ops-rules applied]` と一行記す。該当作業でこの行が無ければ、規範が届いていないか適用判断が漏れたかのどちらかであり、後から検分できる観測点として機能する。