ops-ruleslisted

# Operations Guidelines デプロイ・インフラ・運用に関わる作業時の確認事項。 開発方法論は同梱の dev-rules 規範を参照。 詳細チェックリストは [エンジニア歴20年の私が、素人バイブコーディング勢に物申す（Qiita）](https://qiita.com/Akira-Isegawa/items/00f23d206c504db2ac3b) を参照。 --- ## 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 に指示 - **プロンプトインジェクション検知