Operations Guidelines

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

適用条件

変更が次のいずれかに触れるとき、着手前に本規範の該当節を確認する。ファイルパスではなく変更の性質で判定する（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] と一行記す。該当作業でこの行が無ければ、規範が届いていないか適用判断が漏れたかのどちらかであり、後から検分できる観測点として機能する。