寄稿
アジアクエスト技術顧問 川島 義隆氏
SIer(TIS株式会社)で20年、主にアーキテクトとしてさまざまなプロジェクトに関わり、2018年に独立。以降も、流しのアーキテクトとしてデータモデリングを中心に様々な企業の設計や技術者育成を支援している。あまり語られることがないけれども皆現場で抱えているようなソフトウェア開発上の問題を、見つけ出し一般解をまとめることも生業のひとつ。「中央線Meetup」、「アーキ部」のコミュニティを主催。
X:@kawasima
※本記事は、当社技術顧問として特別に寄稿いただいたものです。
「外部APIが落ちたらどうする?」「リトライは何回?」「整合性は?」
実装が進んだ段階で、こうした非機能要求の考慮漏れが発覚することがあります。設計レビューで気づけば幸運な方で、最悪の場合はリリース後の本番障害として顕在化します。機能要求は明確に定義されても、可用性・性能・セキュリティといった非機能要求は見落とされやすいのです。特に外部サービス連携を含むアーキテクチャでは、考慮すべき観点が爆発的に増えます。
本記事では、生成AIを活用して ADR（Architecture Decision Record）を作成し、非機能要求の考慮漏れを防ぐ方法を紹介します。
Architecturally Significant Requirements（ASR）
非機能要求はIPAの非機能要求グレードを用いて洗い出す現場を多く見かけます。これは観点自体が完全に抜け落ちることを防ぐ手段としては非常に有用なものです。しかし、非機能要求グレードは「網羅性」に優れている一方で、個別のシステム文脈における優先順位や具体的な設計判断までは示してくれません。つまり、「何を検討すべきか」のチェックリストとしては有用ですが、「このアーキテクチャでどの要求が致命的か」「どの設計案を選ぶべきか」といった判断には別のアプローチが必要です。
したがってArchitecturally Significant Requirements（ASR）を明確にし、それぞれに対する設計判断を記録することが重要です。ASRは、システムのアーキテクチャに重大な影響を与える要求のことです。
- システムの構造に影響を与える: 技術スタックの選択、コンポーネントの分割、統合方法などの設計判断を左右する要求
- 品質特性に関わる: 可用性、性能、セキュリティ、保守性、拡張性といった非機能要求。これらは機能要求ほど明確に定義されないため、見落とされやすい
- ビジネス上の制約: コスト、スケジュール、法規制遵守など、アーキテクチャの選択肢を制限する要求
- 技術的な制約: 既存システムとの統合、特定のプラットフォームやライブラリの使用など
つまりASRの見落としが、先に述べた「本番障害」や「設計のやり直し」といった問題を引き起こすのです。ASRの洗い出しには、アーキテクチャ設計の経験と広範な技術知識が必要です。しかし、すべてのプロジェクトに熟練のエンジニアがいるわけではありません。経験の浅いチームでは、以下のような課題に直面します。
- 非機能要求の観点が不足する: 可用性、性能、セキュリティといった非機能要求の重要性は理解していても、具体的にどのような観点で検討すべきかがわからないことがあります。
- 過去の失敗事例を知らない: 「外部APIの障害時にどうするか」「リトライ戦略をどう設計するか」といった論点は、実際に障害を経験したエンジニアでなければ気づきにくいものです。
- トレードオフの判断が難しい: 複数の設計案がある場合、それぞれの利点と欠点を比較検討するには、技術的な深い理解と経験が必要です。
- 質問すべきことがわからない: 設計レビューの場でも、何を聞くべきか、どこに潜在的なリスクがあるのかを見抜けないため、重要な論点が議論されないまま実装に進んでしまいます。
有識者不足のチームにおける実際のトラブル事例
ASRを見落とすと、次のような問題が起きます。
事例1: 決済API障害時の整合性問題
あるECサイトでは、外部決済サービスとの連携において、API呼び出しのタイムアウト処理が適切に設計されていませんでした。決済処理中にネットワーク障害が発生した際、以下のような問題が発生しました。
- カスタマーの画面には「決済失敗」と表示されたが、実際には決済が完了していた
- 同じ注文に対して複数回決済が実行され、二重課金が発生
- カスタマーサポートへの問い合わせが急増し、手動での返金処理に追われる事態に
根本原因は、APIのタイムアウト時の挙動、リトライ戦略、冪等性の担保などが設計段階で議論されていなかったことでした。経験豊富なエンジニアであれば「決済処理は特に慎重に設計すべき」という知見を持っていますが、経験の浅いチームでは気づけませんでした。
事例2: レート制限による本番障害
外部APIを利用する予約管理システムで、本番環境での負荷テストが不十分なまま稼働開始したケースがあります。ピーク時のアクセス集中により、以下の問題が発生しました。
- 外部APIのレート制限に引っかかり、予約処理が大量にエラーになった
- エラー時のリトライ処理がすぐに再実行される設計だったため、さらにAPIを圧迫
- キューイングやバックオフ戦略が実装されておらず、システム全体が停止状態に
設計段階で「外部APIには呼び出し制限がある」という観点が抜けていました。API仕様書には記載されていたものの、それがシステム全体のアーキテクチャにどう影響するかを評価できませんでした。
共通する問題の構造
これらの事例に共通するのは、以下の点です。
- 機能要求は満たしているが、非機能要求が考慮されていない: 「決済ができる」「APIを呼び出せる」という機能は実装されているが、障害時の挙動、性能特性、整合性の担保が設計されていない
- 「正常系」だけで設計が完了している: APIが常に成功する前提で設計され、タイムアウト、レート制限、ネットワーク障害といった異常系が考慮されていない
- 設計レビューで指摘されなかった: チーム全体が経験不足の場合、レビューでも問題が発見されず、実装やテストの段階でも気づかれない
- 本番環境で初めて顕在化する: 開発環境では発生しにくい問題（高負荷、ネットワーク障害、外部サービスの不安定性など）が、本番で初めて表面化する
これらの問題を防ぐには、設計段階でASRを体系的に洗い出し、チームで議論することが不可欠です。生成AIは、経験の浅いチームが「何を聞くべきかわからない」という状況を打破し、議論すべき論点を提示する役割を果たせます。
生成AIを使ったASRの洗い出し
ここまでの事例は、「検討すべき論点が実装の後半や本番で初めて露見する」ことを示していました。言い換えると、設計の早い段階で論点（問い）を意図的に増やすことができれば、手戻りや障害の確率を下げられます。
生成AIは、この「問いを増やす」作業に使うとチームの経験不足を補ってくれます。コンテキスト（外部API連携がある、カスタマ不利益を避けたい、損失も抑えたい、など）を入力として与えると、見落としがちな品質特性や異常系を中心に、チームが議論すべき観点を問いの形で列挙できます。
重要なのは、生成AIが答えを決めることではなく、チームが意思決定するための材料をそろえることです。まずは「どんな問いが存在しうるか」を広げ、次に優先順位を付けて深掘りします。
例題: 動画配信サービスのサブスクリプション決済
例題をもとにこれをみてみましょう。
- 動画配信のNetholicsは、月額サブスクリプションで全コンテンツ見放題サービスを展開している。
- サブスクリプションの支払いは3rdパーティーの決済サービスを利用している
- 3rdパーティーの決済サービスはサブスクリプションの登録、キャンセル、有効化、無効化の4つのREST APIが用意されている。
- カスタマのサブスクリプション設定の変更はアプリ上からいつでもできる。
- カスタマへの不利益がないように設計したい。が、かといってNetholics社が被る金銭的損失も最小限にしたい。
生成AIへのプロンプト
この状況で、チームが議論すべき「設計上の論点（問い）」を重要なものからトップ3挙げてください。
その際、具体的な解決策は含めず、あくまで何を検討・決定すべきかという「問い」の形で提示してください。 生成AIの出力結果（例）
- 外部決済APIの障害や遅延が発生した場合、サブスクリプション状態の整合性をどう保証するか?
カスタマがアプリ上で設定変更を行った際に、3rdパーティーのAPI呼び出しが失敗した場合、Netholics側のデータベースと決済サービス側の状態が不一致になるリスクがあります。この不整合をどのように検知し、どのタイミングで解消するのかを決定する必要があります。また、不整合が解消するまでの間、アプリ上の状態表示とサポート導線をどうするかを決定する必要があります。 - API呼び出しのリトライ戦略をどう設計するか?
決済APIの呼び出しが一時的に失敗した場合、リトライを何回、どの間隔で行うべきか。また、どの時点でリトライを諦め、カスタマにエラーを通知するのか。リトライ中のサブスクリプション状態をどう扱うか（例:有効のまま? 保留状態?）を明確にする必要があります。 - 決済処理とコンテンツアクセス権限の同期タイミングをどう設計するか?
サブスクリプションのキャンセルや無効化が決済サービス側で完了した後、Netholics側でコンテンツへのアクセスをいつ制限するのか。即座に制限するのか、一定の猶予期間を設けるのか。逆に、有効化の場合はいつアクセスを許可するのか。この同期のタイミングとメカニズムをどう決定するかが重要です。
この時点で得られた3つの「問い」は、単なるQ&Aではなく、アーキテクチャに影響しうる要求（ASR候補）です。これをそのまま「正解」として採用することではなく、次のようにチームの議論の入力として扱います。
- 問いをASRの言葉に言い換える
- 例: 「整合性をどう保証するか?」は、外部決済との状態不一致を許容するか/許容するなら検知・収束はどうするか という、整合性・可用性・UXにまたがるASRに展開できます。
- 前提・制約・優先順位を埋める
- 例: カスタマ不利益の定義（返金の扱い、視聴権限の停止タイミング）
- 例: 事業損失の許容量（どこまで無料視聴を許すか）
- 例: 外部APIのSLA、レート制限、Webhook有無などの制約
論点が明らかになれば、ASRに関して決めるべきことも明確に見えてきます。
そこで、これらのASRに対する設計判断をADR（Architecture Decision Record）として記録することが有効です。
ADRは、1つの設計判断を後から説明できる形で記録する短い文書です。ADRには「結論」だけでなく、
- どんな状況（Context）で
- どんな代替案を検討し
- どの案を採用し（Decision）
- その結果として何が起きるか（影響）
を残すことで、意思決定を「再利用できる知識」に変えます。
なお本記事では、アンドリュー・ハーメル＝ロウ氏の著書 『Facilitating Software Architecture』のADRの構成に合わせて、影響セクションに「結果（Consequences）」だけでなく、なぜその案を選び／他の案を退けたか（トレードオフ）も含めて記述します。
たとえば先ほどの3つの問いからは、例えば次のようなADRが必要そうなことが分かります。
- 状態不一致をどう扱うか（検知の方法、収束の期限、許容するズレの範囲）
- リトライ戦略（回数、間隔、バックオフ、冪等性の前提）
- 権限同期のタイミング（いつアクセスを付与/剥奪するか、猶予の有無）
ASRを見つけたら、そのASRを満たすために必要な判断をADRとして記録していきます。
ASRからADRへ
ADRは単に結論を書く文書ではありません。検討した選択肢と、その選択に至った理由（トレードオフ）を残すことで、後から設計意図を説明可能にします。意思決定にまつわる関係者の「思い」が重要で、これが継承されないと、新規参画者は次のどちらかの行動をとるでしょう。
1. 何も考えず意思決定を受け入れる
意思決定がまだ妥当なら、この行動は問題ないかもしれません。しかし、コンテキストが変わって意思決定を見直すべき状況になったら、これは良くありません。プロジェクトに十分理解されないまま積み重なった多くの意思決定があると、開発チームはどんな変更も怖がり、プロジェクトはその重みに耐えられなくなります。
2. 何も考えず決定を覆す
意思決定を見直す必要があるなら、この行動は問題ないかもしれません。しかし、その思いや因果関係を理解せずに決定を覆すことは、プロジェクト全体の価値にダメージを与えます（たとえば、その決定はまだテストされていない非機能要求をサポートするものだった、など）。
継続して成長するビジネスを支えるシステムにおいては、何も考えずに受け入れることも、何も考えずに覆すことも避けなければなりません。
意思決定プロセスの2つの段階
『Facilitating Software Architecture』では、「意思決定する」行為は次の2つの段階に分かれると述べています。
- 代替案を作成する （Decision Making）
利用可能な情報を集め、それらから取りうる選択肢を特定し、形成するプロセスです。代替案を作るには、問題を理解し、そのコンテキストを把握する必要があります。現状はどうなっているのか、関係者は誰で彼らのニーズは何か、制約はあるか、これらの要素が対立しているかなど、すべてが考慮すべき要素です。 - 代替案から1つを選ぶ （Decision Taking）
選択肢のリストを作成した後、その中から一つを選んで行動に移す段階です。
この2つは異なるプロセスなので、主体や関係者が異なっても良いわけです。
生成AIを活用したADR作成: アドバイザーとしての役割
良い代替案を作るには、アーキテクチャや業務に関する豊富な経験と高度なスキルが必要です。ここで生成AIが、諮問型意思決定プロセスにおけるアドバイザーとして機能します。
『Facilitating Software Architecture』では、チームの経験やスキル不足を補うために、代替案を作成するフェーズで積極的にチーム外の有識者に意見を求めることが提唱されています。この有識者の役割は、当然ながら生成AIでも担えるのです。
ただし、良い代替案を作るには、プロジェクト固有の文脈が不可欠です。開発チームのスキルセット、既存システムの技術的負債、組織の制約（予算、納期、人的リソース）、暗黙知（「このチームでこの技術は使いこなせない」など）——これらのコンテキストなしに、的確なアドバイスは生まれません。生成AIを含むアドバイザーに意見を求めるときは、ASRを明示し、具体的な状況を伝えることが重要です。例えば「このチームはGoの経験が浅い」「既存システムはモノリスでDBは共有されている」といった情報があるかないかで、アドバイスの的確さは大きく変わります。
一方で、「代替案から1つを選ぶ」段階は人間が行います。生成AIが提示した代替案を評価し、プロジェクト固有の制約、チームの状況、ビジネス優先順位を踏まえて最終的な判断を下すのはチームです。
なぜ意思決定の主導権を人間が保持すべきなのか
ここで言いたいのは「AIは責任を取れない」みたいな話だけではありません。価値があるのは、自分たちで決めることそのものです。自分たちで決めた瞬間に、問題が起きたときの動き方が変わります。
- 「想定外」が起きても、まず自分たちの前提を見にいける
- 何を捨てて何を守ったかを思い出せる
- 追加の意思決定が必要になったときに、議論の続きができる
逆に、決定が「どこか」や「誰か」のものになっていると、障害対応はだいたい次の形で止まります。
- 原因調査は進むが、直し方が決まらない（トレードオフの引き取り手がいない）
- 関係者が増えるほど、合意形成コストが上がって初動が遅れる
なので、意思決定は「決定権」と「責任（結果の引き取り）」が一致する形であるべきです。この前提に立つと、生成AIは意思決定の材料を増やすのには役立ちますが、決めるのには使わないのが賢明です。
ADRの例
では、例題（外部決済サービス連携のサブスクリプション決済）を、ADRとして書いてみます。
ADR-001: サブスクリプションの正とする状態と不整合の収束方式
コンテキスト
- 3rdパーティー決済サービスが登録/キャンセル/有効化/無効化のREST APIを提供する。
- Netholics側は視聴権限制御のため、サブスクリプション状態を内部にも保持する必要がある。
- 決済APIの失敗・遅延により、決済サービス側の状態と内部状態が一時的に不一致になり得る。
- ASR: 不一致を許容するか。許容するなら、検知・収束・ユーザー体験・損失のバランスをどう設計するか。
決定
決済サービスの状態を正とし、内部状態は一時的なズレを許容して非同期に収束させる。
検討された代替案
- 案1（SELECTED）: 不整合を許容し決済サービス側をSoT（Source of Truth） とする決済サービスAPIの呼び出し結果が不明（タイムアウト・5xx・ネットワーク断など）な場合、Netholics側は確定状態（有効/無効など）へは遷移させない。代わりに未確定として保持し、決済サービスの復旧後に決済サービス側の確定状態を照合してNetholics側を収束させる。
- 案2（REJECTED） : 不整合を許容しNetholics側をSoTとする決済サービスAPIの呼び出し結果が不明な場合でも、Netholics側は先に確定状態へ遷移する。後から決済サービス側の状態が食い違っていた場合は、決済サービスを再実行して追随させる。
- 案3（REJECTED） : 不整合を許容しない
影響
- 案1（SELECTED）不整合を許容し決済サービスをSoTとする
- 誤った確定による二次被害を抑えやすい。
- 照合・再実行（冪等性）・監視・手動介入を前提にし、整合性が取れるまでのSLOを定義する必要がある。
- 案2（REJECTED）不整合を許容しNetholics側をSoTとする
- 内部を先に確定できるが、後から食い違った場合の整合性担保の難易度が高く、決済領域ではリスクが大きいため却下。
- 案3（REJECTED）不整合を許容しない
- 外部APIの遅延・障害が同期処理に直結しやすく、分散トランザクション相当を現実的に成立させにくいため却下。
アドバイス（生成AIに相談して得た観点）
- 結果整合性のために、照合ジョブ（リコンシリエーション） の実行頻度、収束SLO（X分以内）、手動介入の入口（CS/運用）を最初から決めておく。
- APIタイムアウトやリトライによる重複実行に備え、外部決済APIが冪等性キーをサポートしているか確認し、無い場合は 自前で重複排除（操作ID） を持つ。
- 「不整合中のユーザー体験」を状態ごとに決める（例:
PENDING中は見せる文言、再試行の可否、問い合わせ導線）。 - 決済サービス側の更新手段（Webhook/ポーリング/問い合わせAPI）の有無を確認し、照合方式を決める。
未決事項
- 収束SLOの X は、体験と損失のどのバランスで決めるか。
- 決済サービスがWebhook等を提供する場合、照合設計をどう最適化するか。
ADR-002: 決済API呼び出しのリトライ方針（回数・間隔・諦めどころ）
コンテキスト
- 決済APIは外部依存であり、タイムアウト・5xx・一時的ネットワーク障害が起こり得る。
- 無制限リトライは外部のレート制限やスパイクを招き、障害を悪化させ得る。
- ASR: どの失敗をリトライ対象とし、ユーザー操作の待ち時間をどう抑え、いつ「保留」に切り替えるか。
決定
同期リトライは短く、以降は非同期で整合性をとる。
検討された代替案
- 案1（SELECTED）: 同期リトライは短く、以降は非同期で整合性をとる
- 案2（REJECTED）: 同期処理で成功するまで粘る（UIは単純）
- 案3（REJECTED）: 失敗時は即ユーザーに再実行させる
影響
- 案1（SELECTED） 同期リトライは短く、以降は非同期で整合性をとる
- ユーザー操作の待ち時間を上限付きにできる（外部APIが遅い/不安定でも、UIが固まり続けにくい）。
- 決済API障害時でも最終的に成功へ近づけやすい（同期でダメでも、非同期で収束させられる）。
- 完了前に処理が非同期へ移る状態（例:
PENDING）の設計と、表示（またはAPIレスポンス）および問い合わせ導線が必要になる。 - 非同期リトライのために、実行基盤（ジョブ/キュー） と 監視・アラート が必要になる。
- 外部負荷を増やしうるため、指数バックオフ + ジッター を前提にパラメータを定める必要がある。
- エラーを分類し、リトライ対象（タイムアウト、一部の5xx）、即失敗（入力不正などの4xx）を明確に定義する必要がある。
- 同一操作の重複実行が起こりうるため、冪等性キー（Idempotency key） の導入と運用が必要になる。
- リトライの上限（例: 非同期は最大Y回、最大Z時間）をSLOとして決める必要がある。
- 案2（REJECTED） 同期処理で成功するまで粘る（UIは単純）
- 本例題では外部APIの遅延・障害が現実的であり、待ち時間が伸びやすく、外部APIにも負荷を掛け続けやすい（結果として障害を増幅しやすい）。
- 案3（REJECTED） 失敗時は即ユーザーに再実行させる
- 本例題では「整合性/冪等性/不利益最小化」の重要度が高く、ユーザー操作の重複により状態の混乱や二重実行（課金など）を招きやすい。
アドバイス（生成AIに相談して得た観点）
- リトライの前に、外部APIの仕様に合わせて エラー分類表（4xx/5xx/タイムアウト/ネットワーク断）を作り、リトライ可否を決める。
- 非同期実行では 指数バックオフ + ジッター を前提にし、外部のレート制限に触れたときの挙動（待機/停止/アラート）も決める。
- 冪等性キーを「ユーザー操作単位」で固定し、同一操作の重複実行を抑える。
- リトライ失敗が一定数を超えたら、自動リトライを止めて運用へエスカレーションする（手動介入のSLOを決める）。
未決事項
- 同期リトライの回数/待ち時間の上限（UXと成功率のバランス）。
- 冪等性キーの粒度（ユーザー操作単位か、サブスク状態遷移単位か）。
ADR-003: 視聴権限（アクセス）を付与/剥奪するタイミング
コンテキスト
- 決済状態と視聴権限の同期がずれると、
- 未払いで視聴できる（損失）
- 支払い済みで視聴できない（不利益）
- ASR: 「不利益最小化」と「損失最小化」の優先順位と、許容する猶予をどう定義するか。
決定
付与（有効化）は決済側で有効が確認できた時点で行い、剥奪（無効化/キャンセル）は原則即時とする。
ただし、決済サービスに障害が起きていたり、状態の確認ができない場合は、すぐに剥奪すると誤った判断になる可能性がある。そのような場合に限り、短い猶予期間を設けて、後から照合して正しい状態に修正する。
検討された代替案
- 案1（SELECTED） : 付与は確定後、剥奪は基本即時だが条件付きで猶予
- 案2（REJECTED） : 付与も剥奪も常に即時
- 案3（REJECTED） : 付与も剥奪も常に猶予
影響
- 案1（SELECTED） 付与は確定後、剥奪は基本即時だが条件付きで猶予
- 未払い視聴（損失）と、支払い済み視聴不可（不利益）の両極を避けるための、実務的なバランスを取りやすい（通常時は即時、障害時のみ例外）。
- 説明可能なルール（原則と例外）にできるため、CS/運用が判断しやすい。
- 付与が「決済側で有効確認後」になるため、外部障害・遅延時は付与が遅れる可能性があり、その際の表示・問い合わせ導線が必要になる。
- 剥奪が原則即時のため、不一致が起きた場合にアクセス制御の判断が難しくなり、例外時の扱い（猶予条件）を定義する必要がある。
- 猶予を設ける場合、猶予が長いほど損失が増えうるため、猶予の上限目標を定める必要がある。
- 猶予中の扱い（視聴可否、表示、問い合わせ導線）をプロダクト/CSと合意する必要がある。
- 案2（REJECTED） 付与も剥奪も常に即時
- 外部障害時に「払ったのに見れない」が発生しやすく、顧客不利益が増えやすいため却下。
- 案3（REJECTED） 付与も剥奪も常に猶予
- 猶予が長いほど損失が増えやすく、上限（SLO）を定めないと運用が不安定になりやすいので却下。
アドバイス（生成AIに相談して得た観点）
- 「顧客不利益」と「事業損失」のどちらを優先するかを、ケース別に言語化する（有効化/解約/返金/チャージバック）と良い。
- 付与遅延が起きる場合に備え、画面表示（確認中）、問い合わせ導線を先に決める。
- 剥奪に猶予を設けるなら、猶予条件を「例外」に閉じる（例: 外部障害時のみ、最大X分）。
- 猶予中の悪用を想定し、連続キャンセル/再加入、複数端末/共有などの検知と制限（レート制限、監視）を検討する。
未決事項
- 猶予の上限（例: 5分/30分/24時間）を、どの指標（解約率、問い合わせ増、損失）で決めるか。
- 「PENDING中は視聴可」とする場合の悪用対策（アカウント共有、チャーン誘発など）をどう扱うか。
生成AIを活用しつつチームが責任を持って設計する手順
ここに読者の皆さんの現場でも、今日から実践できるように、具体的な手順をまとめます。
- 状況を書き出す
- 外部APIがある。
- どの操作がある（登録/解約/有効化/無効化）。
- 「カスタマ不利益」と「事業損失」の優先順位がある。
- 制約がある（SLA、レート制限、Webhookの有無など）。
- 生成AIに「問い」を出させる
- 解決策は書かせない。
- 「何を決めるべきか？」だけを列挙させる。
- まずはトップ3で良い（起点を作る）。
- 問いをASRとして言い換える
- 「整合性をどうする？」みたいな問いを、要求の言葉に直す。
- 例: 不一致を許容するか。許容するなら検知/収束の期限は？
- ADRの代替案を作る
- ASRをもとにコンテキストをしっかり書く。
- 生成AIにはコンテキストを説明し、トレードオフとなる観点や考慮すべきことをアドバイスとして挙げてもらう。
- 代替案そのものと、各案のメリット/デメリットを作ってもらっても良いが、チームメンバが理解し実行できるものでなくてはならない。
- ADRの代替案を選ぶ
- 代替案の選択はチームでオーナーシップを持っておこなう。
- 選んだ案を決めて、代替案リストの先頭に置く（SELECTED）。
- 「決定」に選択した代替案を書く。
- 「影響」に、選んだ案のプラス面とマイナス面、他の案を選ばなかった理由を残す。
この手順で設計を進めていけば、生成AIは「文章の自動生成ツール」から「意思決定を支援するツール」になるでしょう。
まとめ
生成AIを活用することで、設計初期段階でASRを体系的に洗い出し、見落としがちな非機能要求を特定できます。特に外部サービス連携を含むような複雑なシステムでは、この手法が有効です。
重要なのは、AIが生成した問いをそのまま受け入れるのではなく、チームでしっかり議論し、プロジェクト固有の制約や優先順位を踏まえて意思決定することです。
