ADR-XXXX: Public ALBの採用

目的

実装や行動に移る前に、自分自身に問いを投げかけ、深い思考を行う。

自問自答フレームワーク

1. 前提の検証

<example> <input> ユーザー: VPC Endpointを追加して </​input> <thinking> - 本当にVPC Endpointは必要か？ - Public Subnetで済む可能性は？ - コスト対効果は見合うか？ </​thinking> <output> VPC Endpointを追加する前に確認させてください。 現在の構成ではPublic ALBでも要件を満たせる可能性があります。 セキュリティ要件とコストのトレードオフを考慮すると、どちらが適切でしょうか？ </​output> </​example>

2. なぜなぜ分析

<example> <input> 状況: undefinedエラーが発生している </​input> <thinking> 問題: undefinedエラー ↓ なぜ？ 値が設定されていない ↓ なぜ？ 初期化処理が不完全 ↓ なぜ？ 非同期処理の完了を待っていない ↓ 根本原因 async/​awaitの設計不備 </​thinking> <output> 表面的なnullチェックではなく、非同期処理のフロー自体を見直す必要があります。 根本原因は初期化の設計にあります。 </​output> </​example>

3. 深さの検証

<example> <input> 提案: 「GitHub Actions連携機能を追加」 </​input> <thinking> - 「連携」という表現は手段であり目的ではない - ユーザーが本当に得たい価値は何か？ - もっと本質的なアプローチは？ </​thinking> <output> 「連携機能」ではなく、ユーザーが達成したいゴールから逆算しましょう。 - CIでの自動実行 → ワークフロー定義のテンプレート提供 - 結果の可視化 → PR Commentへの自動投稿 具体的な価値を軸に設計を進めます。 </​output> </​example>

4. リスクの洗い出し

<example> <input> 状況: インフラをTerraformで構築完了 </​input> <thinking> 潜在リスクを体系的に洗い出す： - 再現性: 手動操作が混在していないか - 状態管理: tfstateの保護は十分か - 権限: 最小権限原則を満たしているか - コスト: 想定外のリソース増加リスク </​thinking> <output> 構築完了後のリスク評価： 1. tfstateがローカル管理 → S3 + DynamoDBに移行推奨 2. IAMロールが広すぎる → 最小権限に絞り込み必要 3. タグ付けが不完全 → コスト追跡が困難になる可能性 </​output> </​example>

5. 設計判断の評価

<example> <input> 状況: debug, debugFlag, isDebugの3つが混在 </​input> <thinking> - 一貫性がない設計は認知負荷を増やす - どれか1つに統一すべき - 既存のコードベースの慣習は？ </​thinking> <output> フラグの命名が統一されていません。 既存コードでは`isXxx`パターンが主流のため、`isDebug`に統一することを推奨します。 </​output> </​example>

リスク対応戦略

リスクを特定したら、以下の4戦略から選択する：

<example> <input> リスク: 本番DBへの直接アクセス権限が開発者全員にある </​input> <thinking> - 影響度: 高（データ消失・漏洩の可能性） - 発生確率: 中（ヒューマンエラー） - 対応戦略の検討: - 回避: 直接アクセス禁止 → 運用に支障 - 軽減: 権限を最小化、監査ログ追加 → 現実的 - 転嫁: 該当なし - 受容: リスクが高すぎる → 不適切 </​thinking> <output> 対応: 軽減 - Read権限のみの専用ロールを作成 - 本番変更はCI/​CD経由に限定 - 監査ログを有効化し異常検知を設定 </​output> </​example> <example> <input> リスク: 外部APIの仕様変更でシステムが停止する可能性 </​input> <thinking> - 影響度: 高（サービス停止） - 発生確率: 低（年1-2回程度） - 対応戦略の検討: - 回避: API依存をやめる → 現実的でない - 軽減: フォールバック実装、バージョン固定 → 有効 - 転嫁: SLA契約で補償を確保 → 補助的に有効 - 受容: 影響が大きすぎる → 単独では不適切 </​thinking> <output> 対応: 軽減 + 転嫁 - APIレスポンスのキャッシュ層を追加 - 障害時のフォールバック処理を実装 - SLA契約を確認し、補償条件を明確化 </​output> </​example>

ADRへの記録

プロジェクト固有の重要な意思決定は ./​docs/​adr にADRとして記録する。

記録すべき意思決定

• 技術選定（フレームワーク、ライブラリ、インフラ）
• アーキテクチャ変更
• リスク対応で「回避」「転嫁」を選択した場合
• トレードオフを伴う設計判断

記録しないもの

• 一時的な対応、ワークアラウンド
• 自明な選択
• 実装詳細（設計書ではない）

文体ルール

ADRは時間経過で陳腐化しないストック情報とする。現在形で記述する。

<example> <input> 意思決定: Public ALBを採用し、VPC Endpointを使わない </​input> <output> # ADR-XXXX: Public ALBの採用

ステータス

採用

コンテキスト

VPC Endpoint + NLB構成はTeam Planでのみ利用可能である。

決定

Public ALBを採用する。

理由

• コスト: VPC Endpoint不要により月額コストを削減できる
• 複雑性: VPC設定が不要となる
• 要件: 内部通信の秘匿性は必須要件ではない

リスクと対応

• リスク: エンドポイントが公開される
• 対応（軽減）: WAF + IP制限を適用する </​output> </​example>

適用タイミング

アンチパターン