AIが曖昧なプロンプトを本番対応のアーキテクチャに変える方法

「プロンプトからアーキテクチャ」が本当に意味すること

「曖昧なプロンプト」は普通の出発点です。ほとんどのアイデアは意図として始まり、仕様ではありません：「カスタマーポータルを作る」「AI検索を追加する」「イベントをリアルタイムでストリームする」など。人々は望む成果は知っていても、実現可能にする境界、リスク、エンジニアリング上の選択肢はまだわかっていません。

「プロンプトからアーキテクチャ」とは、その意図を一貫した計画に変えるワークフローです：何を作るか、部品がどう組み合わさるか、データがどのように流れるか、本番で動くために何が必要か。

「本番対応のアーキテクチャ」が意味するもの

本番対応は「図がある」ということではありません。設計が明示的に次を扱っていることを意味します：

• 信頼性（Reliability）： 何が壊れるか、どのように復旧するか、負荷時の挙動
• セキュリティ（Security）： アクセス制御、シークレットの保管、脅威軽減
• コスト（Cost）： 何が支出を生むか、監視と制御の方法
• 運用性（Operability）： 監視、バックアップ、デプロイ、深夜の障害をどうデバッグするか

AIが役立つ点と誤解を招く点

AIは初期の思考を加速するのに強みがあります：候補アーキテクチャの生成、一般的なパターン（キュー、キャッシュ、サービス境界）の提案、見落としがちな非機能要件の指摘、インターフェース契約やチェックリストの草案作成など。

一方で文脈を検証できない細部について自信満々に語ると誤導されます：状況に応じた技術選定の提案、運用の複雑さの過小評価、組織固有の制約（コンプライアンス、既存プラットフォーム、チームのスキル）を見落とすなど。AIの出力は受け入れる答えではなく、挑戦すべき提案として扱ってください。

この投稿が扱うこと／扱わないこと

この投稿は、プロンプト → 要件 → 仮定 → 選択肢 → 決定、という実用的で再現可能なワークフローと、追跡可能なトレードオフを扱います。

ただしドメイン専門知識、詳細なサイズ見積り、セキュリティレビューの代替にはなりませんし、すべてのプロンプトに対する単一の「正しい」アーキテクチャがあると主張もしません。

ステップ1：プロンプトを明確な問題文に変える

曖昧なプロンプトは通常、目的（「ダッシュボードを作る」）、解決策（「マイクロサービスを使う」）、意見（「高速にする」）を混ぜます。コンポーネントを描く前に、検証や議論が可能な十分に具体的な問題文が必要です。

問題文（誰が何を、なぜ今）

主要ユーザー、彼らが達成したい仕事、緊急性を1〜2文で書きます。

例：「カスタマーサポートマネージャーが、未解決チケットとSLAリスクを一元で見て毎日優先度を決め、今四半期のSLA見逃しを減らせるようにする必要がある。」

プロンプトが現実のユーザーを特定していないなら尋ねてください。今すぐ必要な理由がなければ、後でトレードオフを順位付けできません。

成功指標（どうなったら成功か）

「良い」を測定可能な結果に変えます。製品指標と運用指標の混合を好みます。

• 製品： 主タスク完了時間、採用率、エラー率、コンバージョン、NPS
• 運用： p95 レイテンシ、稼働率目標、リクエスト当たりコスト、オンコールのページ数/週

3〜5個程度に絞りましょう。多すぎると混乱し、少なすぎるとリスクが隠れます。

ユーザージャーニーと重要なフロー

「ハッピーパス」を平易な言葉で説明し、アーキテクチャを左右するエッジケースを列挙します。

ハッピーパス例：ユーザーがサインイン → 顧客を検索 → 現在ステータスを見る → フィールドを更新 → 監査ログが記録される。

早期に表面化すべきエッジケース：オフラインや接続品質低下、部分的な権限、重複レコード、大量インポート、タイムアウト、リトライ、依存先がダウンしたときの挙動。

範囲外（設計の拡散を防ぐため）

このバージョンで作らないものを明示します：未対応の統合、上級分析、マルチリージョン、カスタムワークフロー、完全な管理者ツールなど。明確な境界はスケジュールを守り、後の「フェーズ2」議論を容易にします。

これら4つが書かれれば、プロンプトは共有可能な契約になります。AIは改善の助けになりますが、発明してはいけません。

ステップ2：要件と制約を抽出する

曖昧なプロンプトはしばしば「使いやすくする（目標）」「通知を送る（機能）」「サーバーレスを使う（好み）」のように混ざっています。このステップでは、それらを設計に使える要件リストに分離します。

機能要件（何をするか）

具体的な振る舞いとそれが触る移動要素を引き出します：

• 機能： ユーザー登録/ログイン、検索、チェックアウト、管理ダッシュボード、監査ログ
• データ： 何を保存するか（ユーザー、注文、イベント）、保存期間、誰がアクセスできるか
• 統合： 決済プロバイダ、メール/SMS、CRM、分析、既存の内部API

良いチェック：各要件に対して画面、APIエンドポイント、またはバッチジョブを指せますか？

非機能要件（どの程度の品質で行うか）

これらは想像以上にアーキテクチャを形作ります。曖昧な語句を測定可能な目標に翻訳してください：

• レイテンシ： 「ページが速い」 → 「95%のリクエストを300ms未満」
• 稼働率： 「常に利用可能」 → 「月間99.9%」
• プライバシー/コンプライアンス： 「EU顧客を扱う」 → 「GDPRの基本：削除要求、データエクスポート、最小保持」

制約（変更できないこと）

早い段階で境界を捕まえ、理想設計を作っても出せない事態を避けます：

• 予算 & タイムライン： 固定のローンチ日、クラウド支出上限
• チームスキル： Pythonは得意だがKubernetes経験は限定的
• 既存システム： 既存のDB、SSO、メッセージバスを使用しなければならない

完了条件（受け入れ基準）を平易な言葉で

誰が見ても検証できる「完了の定義」をいくつか書きます。例：

• 「新規ユーザーは2分以内に登録、メール確認、ログインできる」
• 「サポートは注文を返金し、顧客に1分以内に確認を送れる」
• 「個人データは削除要求後30日以内にバックアップを含め削除できる」

これらの要件と制約が、次に比較する候補アーキテクチャの入力になります。

ステップ3：仮定と未確定事項を早期に表面化する

曖昧なプロンプトは多くの場合、技術的失敗よりも「各自が黙って足りない情報を補ってしまう」ことが原因で失敗します。設計を提案する前に、AIを使ってその黙示の仮定を明示化し、真実と推測を分離してください。

よくある隠れた仮定

通常暗黙に使われる「デフォルト」を書き出します：

• トラフィックと成長率： 1日50ユーザー向けか、同時50kユーザー向けか？ローンチでスパイクするか安定か？
• データ品質： 入力データはきれいで構造化されているか、それとも重複・欠損・フォーマット不整合が多いか？
• ユーザー行動： ユーザーは遅延を許容するか？積極的にリトライするか？リアルタイム更新を期待するか？
• 運用： 誰がサポートするか？オンコールはいるか？週末障害は許容できるか？

これらの仮定が、キャッシュ、キュー、ストレージ、監視、コストなどの選択を強く形作ります。

「既知」vs「不明」vs「調査が必要」に分ける

AIに簡単な表（または3つの短いリスト）を作らせます：

• 既知（Knowns）： プロンプトやステークホルダーから確認できる要件
• 不明（Unknowns）： 自信を持った決定を阻む不足情報
• 調査が必要（Needs research）： スパイク検証、ベンダーチェック、ベンチマーク、法務、ユーザーテストが必要な質問

これによりAI（とチーム）が推測を事実として扱うのを防げます。

設計に踏み切る前にAIに尋ねるべき質問例

• トップ3のユーザージャーニーは何か、それぞれで「十分に速い」とは何msか？
• どのデータをどのくらいの期間保存し、誰がアクセスできるか？
• 受け入れられる障害モードは何か（部分的な停止、遅延処理、読み取り専用モード）？
• 統合先のレート制限と信頼性は？
• 固定の制約は何か：予算、期限、クラウド/プロバイダ、コンプライアンス？

仮定を文書化して後で挑戦できるようにする

仮定を明示的に書きます（例：「ピーク2,000 req/minを想定」や「PIIが存在すると仮定」）。誰がいつ確認したかを付けてドラフト入力として扱い、後で見直せるようにします。これにより後のトレードオフや設計変更の説明・擁護・巻き戻しが容易になります。

ステップ4：単一解ではなく候補アーキテクチャを提案する

曖昧なプロンプトは通常、単一の「正しい」設計を暗示しません。最速で本番対応に近づく方法は、いくつかの実行可能なオプションをスケッチし、デフォルトを選び、いつ切り替えるかを明示することです。

オプションA（デフォルト第一案）：シンプルなモノリス＋マネージドサービス

多くの初期プロダクトは、1つのデプロイ可能なバックエンド（API＋ビジネスロジック）、単一のデータベース、認証やメール、オブジェクトストレージなど少数のマネージドサービスで始めるべきです。デプロイやデバッグ、変更が簡単になります。

選ぶべき状況：チームが小さく、要件が変わりやすく、トラフィックが不確定なとき。

オプションB：標準的なモジュラー・モノリス＋非同期ジョブ

同一のデプロイ可能な実体だが内部モジュール（課金、ユーザー、レポーティング）を明確にし、インポートや通知、AI呼び出しなどの遅い処理用にバックグラウンドワーカーを追加する。キューとリトライポリシーを入れる。

選ぶべき状況：長時間実行タスクや定期スパイクがある、所有権の境界を明確にしたいがマイクロサービス分割はまだ早いとき。

オプションC：スケール可能なサービス群（要件が強く求める場合のみ）

隔離が必須（コンプライアンス）、ホットスポットを個別にスケールする必要がある（メディア処理等）、あるいはリリースサイクルが分かれている場合に一部を別サービスに分割する。

選ぶべき状況：特定の負荷パターンや組織の境界、リスク制約があり、運用負荷の増加が正当化されるとき。

オプション間で変わる点

これらのオプションで明確にするべき差分：

• コンポーネント： 単一API vs API+ワーカー vs 複数デプロイ可能ユニット
• コスト： 部品が少ないほど低め。キューや追加サービスで増える
• 複雑さ： 開発の単純さ vs デプロイ/バージョン管理/障害モードの増加

AIの有用な出力は小さな決定表です："デフォルト = A、バックグラウンドジョブがあればBに切り替え、Xが真ならCに移行" のように。これにより早期のマイクロサービス化を防ぎ、アーキテクチャを実際の要件に結びつけます。

ステップ5：データと境界をモデル化する

意外に多くの「アーキテクチャ」は、システムのデータが何であるか、それがどこにあり誰が変更できるかに合意することです。早めにこれをモデル化すれば、以降のコンポーネント、インターフェース、スケーリング、セキュリティの設計がずっと確実になります。

コアドメインオブジェクトを定義し、所有権を決める

システムの中心となる数個のオブジェクト（プロンプトに現れる名詞）を名付けます：User, Organization, Subscription, Order, Ticket, Document, Event など。各オブジェクトについて：

• 真のソース（Source of truth）： どのシステム/サービスが書き込みを許可するか
• 読み手（Readers）： 誰が消費するか（他サービス、分析、サポート）
• ライフサイクル： 作成/更新/削除、ソフトデリート規則

AIはプロンプトから初期のドメインモデルを提案できます。そこから現実と暗黙の想定を確認します。

アクセスニーズに合う保存パターンを選ぶ

各オブジェクトが主にトランザクショナル（OLTP：小さい読み書きが多く一貫性が必要）か、分析用途（集計や傾向）かを決めます。これらを同じDBに混在させると摩擦が生じがちです。

一般的なパターン：アプリ用のOLTP DBと、イベントやエクスポートで更新される別の分析ストアを用意する。重要なのはデータが「どう使われるか」に合わせて保存を決めることです。

エンドツーエンドのデータフローを計画する

データがシステムをどのように流れるかをスケッチします：

• 取り込み（Ingestion）： API、アップロード、Webhook、バッチインポート
• 変換（Transformation）： バリデーション、強化、重複排除
• 保持と削除（Retention/Deletion）： 保存期間と削除方法

早期にデータリスクを表面化する

明確にするリスク：PII の取り扱い、重複レコード、複数ソース間の競合（どちらが真のソースか）、不明瞭な削除セマンティクス。これらは境界を定めます：内部に留めるべきもの、共有してよいもの、監査証跡やアクセス制御が必要なもの。

ステップ6：コンポーネントとインターフェースをマップする

境界とデータが定まったら、何が存在しそれが何を所有しどうやって他と話すかを具体的なコンポーネントマップに変換します。ここでAIは「言葉で書くダイアグラム生成器」として有用で、きれいな分離を提案し欠けているインターフェースを指摘してくれます。

モジュールと責務を定義する

少数のコンポーネントに明確な所有権を割り当てることを目標にします。チェック："これが壊れたら誰が直すか、何を変えるか？" が明確であること。例：

• API Gateway / BFF： リクエストのルーティング、認可適用、レート制限
• コアサービス群： ビジネスルールとワークフロー
• データストア群： 永続化とクエリパターン（ただの「データベース」ではなく）
• 非同期ワーカー： 長時間処理、リトライ、スケジュールジョブ
• 観測可能性： ログ、メトリクス、トレース（ファーストクラスのコンポーネントとして）

コンポーネント間の通信方式を選び、その理由を示す

デフォルトの通信スタイルを選び、例外を正当化します：

• REST/HTTP：シンプルな要求/応答と人間によるデバッグ向け
• イベント/ pub-sub：同じ変更に複数の消費者が反応する場合
• キュー：バックグラウンド処理、スパイクの吸収、信頼性の確保

AIは各ユースケースに対して、遅延と信頼性要件を満たす最も単純なインターフェースをマップするのに役立ちます。

外部依存と障害時の振る舞い

サードパーティや外部システムを列挙し、障害時の挙動を決めます：

• タイムアウト、バックオフ付きリトライ、サーキットブレーカー
• 劣化モード（キャッシュを返す、読み取り専用化）
• 明確なエラー契約（クライアントが期待できる内容）

統合マップ（システム、API、認証）

簡潔な統合表を書きます：

• 決済 → プロバイダAPI（REST）、OAuth2 client credentials、冪等キー
• Email/SMS → メッセージングAPI（REST）、APIキー、5xx発生時はリトライキュー
• 分析 → イベントストリーム、サービストークン、オーバーロード時は破棄方針

このマップが実装チケットとレビューの骨格になります。

ステップ7：コーディング前に本番の問題を設計に反映する

ホワイトボード上で完璧に見える設計でも、初日に本番で失敗することがあります。コードを書く前に「本番契約」を明確にします：負荷時、障害時、攻撃時にどう振る舞い、どう検知するか。

信頼性：故障パスに備える

依存先が遅いかダウンしているときの挙動を定義します。タイムアウト、ジッター付きのリトライ、明確なサーキットブレーカールールを加え、操作を冪等化してください（リクエストIDや冪等キー使用）。

外部API呼び出しにはレート制限があると仮定し、バックプレッシャー（キュー、バウンディング）や優雅な劣化（"後で試して"レスポンス）を組み込みます。

セキュリティ：誰が何をできるかを決める

認証（Identity）と認可（Authorization）を指定し、関連する主要な脅威シナリオを列挙します：トークン窃取、公開エンドポイントの悪用、入力によるインジェクション、権限昇格など。

シークレットの保管場所、誰が読めるか、ローテーション頻度、監査ログについても定義します。

パフォーマンス：感覚ではなく目標を定める

キャパシティとレイテンシ目標（大まかでも可）を定め、次の戦術を選びます：キャッシュ（何を、どこに、TTL）、バッチ処理、非同期化、共有リソース保護のための制限。

観測可能性：見えないものは直せない

構造化ログ、主要メトリクス（レイテンシ、エラーレート、キュー深度）、分散トレーシングの境界、基本的なアラートを決めます。各アラートには対応者、確認ポイント、「安全モード」を紐づけます。

これらはエンドポイントやデータベースと同等にファーストクラスのアーキテクチャ要素です。

ステップ8：トレードオフを明示的かつ追跡可能にする

アーキテクチャは「最良の一つの解」ではなく、制約下の選択の集合です。AIは選択肢を素早く列挙するのに役立ちますが、なぜその道を選んだのか、何を犠牲にしたのか、将来何が切り替えトリガーになるのかを明確に残す必要があります。

単純なトレードオフ表を使う

リスクを受容する場所と防御に投資する場所を決める

"許容できる障害"（例：時折の遅延したメール）と"絶対に失敗できない領域"（例：決済、データ損失）を決め、失敗が高コストな箇所にバックアップ、冪等性、レート制限、明確なロールバック経路を配置します。

チームに影響する運用上のトレードオフ

一部の設計はオンコール負荷とデバッグの難易度を上げます（部品数の増加、リトライの増加、分散ログ）。サポート体制に合う選択を優先してください：サービス数を減らす、観測可能性を明確にする、予測可能な障害モードにするなど。

技術的トレードオフ：マネージド vs セルフホスト

決定基準を明示します：コンプライアンス、カスタマイズ性、レイテンシ、要員。コスト節約でセルフホストを選ぶ場合、パッチ適用、アップグレード、容量計画、インシデント対応という隠れたコストがあることを記録してください。

ステップ9：決定・代替案・可逆性を記録する

優れたアーキテクチャは偶然ではなく多くの小さな選択の結果です。これらがチャットログや誰かの記憶だけにあると、同じ議論が繰り返され、矛盾した実装が出て、要件変更時に苦労します。

ADRで決定を検索可能にする

主要な選択ごとに**Architecture Decision Record（ADR）**を作り、短く一貫した形式で：

• コンテキスト： 解く問題と制約
• 決定： 選んだこと
• 検討した代替案： 2–3案
• なぜその決定か（Why）： 理由とトレードオフ
• 帰結： 何を可能にし何を制限するか

AIは議論から要点を抜き出してADRの草案を作るのが得意で、あなたはそれを正確に編集すればよいです。

「出口戦略（exit ramps）」を設計に入れる

仮定は変わります：トラフィックが予想より早く伸びる、コンプライアンス要件が厳しくなる、外部APIが不安定になる。各主要仮定について出口戦略を入れておきます：

• 「Xリクエスト/秒を超えたら単一DBからリードレプリカに移行する」
• 「ベンダーAPIのSLAがYを下回ったらキュー＋リトライワーカーを導入する」

将来の変化を火事対応ではなく計画的な移行にします。

証拠となるポイントと決定のバージョニング

リスキーな選択には検証可能なマイルストーン（スパイクテスト、ベンチマーク、小さなプロトタイプ、負荷試験）を付け、期待される結果と成功基準を記録します。

最後にADRsを要件の変化に合わせてバージョン管理し、履歴を書き換えずに追記して何がいつ変わったかを追跡できるようにします。軽い構造が必要なら内部テンプレート（/blog/adr-template など）にリンクしてください。

ステップ10：レビューと証拠で設計を検証する

ドラフトのアーキテクチャは、図がきれいになった時点で「完了」ではありません。構築・運用・支払う人々がこれで動くと合意し、トリッキーな部分に対する証拠があるときが完了です。

集中したアーキテクチャレビューを行う

短いチェックリストを使って重要な質問を早期に表面化させます：

• セキュリティ： 認証/認可モデル、シークレット管理、最小権限、監査ログ
• プライバシー： データ分類、保持、アクセス制御、PIIのフロー、削除要求
• 障害モード： 劣化挙動、リトライ・バックオフ、冪等性、DLQ（デッドレターキュー）、レート制限
• 運用準備： 監視、アラート、ランブック、オンコールの所有、バックアップ/復元

出力は具体的に：「何をするか？」と「誰が担当か？」で書きます。

数値で検証する（レンジで）

単一のスループット推定値ではなく、不確実性を反映したレンジを出します：

• トラフィック： P50 / P95 のRPSレンジ（例：通常50–200 RPS、ピーク500–1,000 RPS）
• ストレージ増加： 月間レンジと保持仮定
• コスト要因： モデル/API利用、コンピュートのオートスケール、データ転送料金、マネージドDB

AIに計算根拠と仮定を示させ、それを現在の解析や類似システムと照合してください。

依存とベンダーリスクの評価

クリティカルな依存先（LLMプロバイダ、ベクトルDB、キュー、認証サービス）を列挙し、各々について：

• 利用不可になったら何が壊れるか？
• ベンダーを切り替える難易度は？
• 契約上・地域的・コンプライアンス上の制約はあるか？

人の合意（サインオフ）ポイントを定義する

レビューを明確にします：

• プロダクト： ユーザーフロー、SLA、スコープ境界
• セキュリティ/プライバシー： 脅威モデルの結果、データ処理の承認
• 運用/SRE： 観測性プラン、インシデント対応、容量仮定
• エンジニアリング： インターフェース、マイルストーン、移行計画

意見の不一致が残る場合、それらを「検討すべき決定」として所有者と期日を付けて記録し、前に進む明確さを保ちます。

AIと協働して設計するには

AIをジュニアアーキテクトのように扱うと効果的です：オプションを速く出せるが、明確なコンテキスト、検証、指示が必要です。

仮定と制約を明示するプロンプトを書け

AIにはビジネスゴール、ユーザー、スケール、予算、期限、変更不可の条件（技術スタック、コンプライアンス、ホスティング、データ居住性）を与えてから、まず仮定と未解決点を列挙させ、その後に解決案を出させます。

ルール：制約が重要なら明示的に書け。モデルに推測させない。

実装に移す際のワークフローツール活用

設計から実際のシステムに移す際に意思決定が手渡しで失われないワークフローが重要です。Koder.ai のようなプラットフォームは、要件を明確化するチャットから実装用のアーティファクトをエクスポートできるため役立ちます。

ただしこれがアーキテクチャレビューを不要にするわけではなく、むしろ要件や非機能要件の文書化の水準を上げる必要があります。

再利用できるプロンプトテンプレート

短いテンプレートを使って構造化された出力を得ます：

You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)

（このコードブロックの内容は翻訳せず原文のまま残しています。）

「批評して改善する」ループで反復する

最初の案を出させたら、すぐに批評を要求します：

• 「この設計の脆い点は何か？」
• 「どの要件がまだ満たされていないか？」
• 「時間が半分なら何を簡素化するか？」

これによりモデルが一つの道に早期収束するのを防げます。

よくある失敗モードに注意する

AIは自信満々に間違うことがあります。注意点：

• 幻想（hallucination）されたサービスや機能—リンクや不確かさを要求する
• 制約（コスト、データ居住性、チームスキル）を無視—各設計選択を要件に紐づけさせる
• 過剰設計—「最小実行可能アーキテクチャ」オプションを強制する

出力を軽量ADRとして保存し、リポジトリに並べておくと良いでしょう（例：/blog/architecture-decision-records）。

ミニウォークスルー：曖昧なプロンプトから構築可能な計画へ

曖昧なプロンプト：「配送が遅れると顧客に通知するシステムを作って」

1) 要件に落とす

AIがこれを具体的ニーズに翻訳します：

• ユーザー： オペレーションチーム、エンド顧客
• コアフロー： 出荷ステータスを取り込み → 遅延リスクを検出 → 通知 → 結果を追跡
• 非機能： ステータス変化から2分以内のアラート、99.9%の可用性、紛争のための監査証跡

2) アーキテクチャを変える仮定

早期の2つの質問が設計を大きく変えます：

• 仮定A： キャリアからリアルタイムでステータス更新が来る（Webhook）。その場合はイベント駆動が適する。
• 仮定B： 15分ごとにポーリングしている。そうならスケジューリングやレート制御が必要で、「2分」SLAは入力を再交渉しない限り不可能。

これらを文書化することで誤ったものを早く作るのを防ぎます。

3) オプション → トレードオフの判断

AIが候補を提案します：

• オプション1：同期API: キャリアWebhook → 遅延スコアリングサービス → 通知サービス

  • 長所：単純で部品が少ない
  • 短所：Webhookのタイムアウトで更新を失う可能性、スパイクでスコアリングが溢れる

• オプション2：キューを使う: Webhook → イベントをキューに投入 → ワーカーが遅延判定 → 通知

  • 長所：バーストを吸収、リトライが安全、観測性が向上
  • 短所：コンポーネント数が増え、一貫性が最終的になる

トレードオフ：キャリアの信頼性やトラフィックのスパイクが懸念ならキュー方式を選び、ボリュームが低くキャリアSLAが強ければ同期で十分です。

4) 最終計画と成果物

実装可能にするための成果物：

• コンテキストとシーケンス図
• データモデル＋イベントスキーマ
• キュー対同期の選択に関するADR
• ランブック（障害モード、リトライ、オンコールチェック）
• バックログのエピック（キャリア統合、スコアリングルール、通知テンプレート、監視）