AI時代のシステム設計 「なんとなく」を排除する要件定量化と評価軸、重みづけのフレームワーク：ディシジョン・ドリブン・アーキテクチャ AI時代の「決める」技術

生成AIで設計案作成が容易になった一方、人間の本質的役割は要件の定量化や前提条件の言語化を通じた意志決定にある。本稿ではSQSとKafkaの比較を基に、曖昧な要件を数値化するStep1と、3パターンから評価軸を導き重みづけを行うStep2の実務手法を解説する。

[前出祐吾（アクセンチュア），ITmedia]

この連載について

生成AIによってシステムの設計案を作ることは容易になったが、何を優先し何を諦めるかを決める責任は人間に残されている。アーキテクチャに正解はなく、重要なのは「なぜその選択をしたか」を説明できることだ。本連載ではケーススタディーを通じ、トレードオフの可視化や意思決定の考え方を掘り下げ、良い設計を目指すだけでなく、良い意思決定を目指す。

　前回は生成AIの台頭によってシステム設計案の作成が容易になったからこそ、「何を優先し何を諦めるか」という意思決定の理由を人間が明確に示す重要性を解説した。そして、この意思決定のプロセスを「要件の定量化」「評価軸・重みづけの決定」「案の比較と決定」「結果の記録」という4つのステップとして示した。

　しかし、この4ステップを実際に自分のプロジェクトで実行しようとすると、「評価軸はどう導き出すのか？」「重みは誰がどう決めるのか？」「候補案のスコアはどう計算し、結果をどう読めばいいのか？」と思った方もいるだろう。

図1　設計判断の4ステップ　要件定義から判断の記録まで（作成：アクセンチュア）

　生成AIは、こうした問いに対して候補技術の比較表やユースケース一覧を瞬時に生成できる。しかし「このプロジェクトの期限と体制で、どの評価軸にどのくらいの重みを置くべきか」という判断は、AIには下せない。AIが自社の前提条件を知らないからではなく、その前提条件を言語化し、意思決定に必要な形に整えること自体が、設計者に求められる本質的な仕事だからだ。

　「要件を定量的に定義する」「評価軸を決める（重みづけ）」「案を比較して意思決定する」「結果を記録する」というStep1〜4を、実践手法として複数回にわたり解説する。なかでもStep2と3は実務上、特に手が止まりやすい部分であり、考え方とあわせて具体的な手順や例を交えながら丁寧に掘り下げる。

　今回は、まず要件を定量的に定義するStep1と、評価軸と重みづけを決めるStep2を解説する。

Step1．要件を定量的に定義する

　Step1では、非機能要件定義書や提案依頼書（RFP）、プロジェクト方針から、設計判断に必要な情報を定量的に整理する。

なぜ定量化が必要か

　この段階を曖昧にしたままStep2に進むと、評価軸の重みや候補案のスコアが主観に依存しやすくなる。「パフォーマンスが重要」という表現では、それが「応答時間200ms以内」を意味するのか「1日1億件のスループット」を意味するのかが判別できない。数値や条件として表現されて初めて、評価軸の重みに根拠が生まれ、スコアの妥当性を検証できるようになる。

　「ChatGPT」や「Claude」などの生成AIに「Amazon SQS（Simple Queue Service）とApache Kafkaどちらがよいか」と問えば、即座に比較表が返ってくる。しかし、その問いに「自社のスループット要件は1000件／分以上」という情報を加えると推奨が変わり、さらに「Kafkaの運用経験者がチームにいない」という条件を加えると、また変わる。生成AIの回答は入力する文脈の質に強く依存する。要件の定量化は、AIを実際に使えるパートナーにするための前提作業でもある。

　非機能要件の整理に当たっては、情報処理推進機構（IPA）が提供する「非機能要求グレード」を参照すると体系的に網羅しやすい。可用性や性能・拡張性、セキュリティなど6つの大項目にわたる観点が整理されており、抜け漏れを防ぐチェックリストとして機能する。

確認する情報の種別：

• システムに求められる非機能要件：スループット、レイテンシ、可用性、信頼性など
• 業務要件に由来する条件：メッセージロスト許容度、順序保証の厳密さなど
• 体制・スケジュール条件：構築期限、予算上限、チーム規模、スキルセット

図2　定量化の表現例　曖昧な声を数値・条件に変換する（作成：アクセンチュア）

SQS vs Kafkaの例

　「なぜSQSとKafkaなのか。もう使い古した事例ではないか」と思う読者もいるかもしれない。今日、この2択を初めて迎えるチームは多くない。それでも本稿がこの事例を使う理由は、技術の新しさではなく構造の典型性にある。

　SQSはクラウドマネージドのシンプルなキュー、Kafkaは高スループットとパーティション単位の順序保証を備えた分散ストリーミング基盤。この2択が持つ「速度・シンプルさ vs 機能・運用コスト」というトレードオフは、LLM（大規模言語モデル）の推論APIを選ぶか自社ホスティングにするか、ベクトルDBをマネージドにするかオープンソースソフトウェア（OSS）にするか、という現代の選択でも同じ構造で現れる。事例が変わっても、判断を構造化するフレームは変わらない。

　本稿では、メッセージ基盤としてSQSとKafkaのどちらを採用するかを題材に、以下のように整理した。

図3　SQS vs Kafkaの要件整理　定量化した5項目（作成：アクセンチュア）

　これらを整理することで、次のStep2では「なぜその評価軸を設けたか」「なぜその重みなのか」を根拠とともに説明できるようになる。逆にこの段階を省いて進むと、重みの議論が主観のぶつけ合いになり、スコアリングの根拠も後から説明できなくなる。

Step2．評価軸と重みづけを決める

　ここからは評価軸の設定から重みづけの決定に至る具体的手順を解説する。必須要件による候補の絞り込み、3つのパターンを使った評価軸の導出、重みづけで難航する原因の整理、そして実際の重み設定の作成という流れでプロセスを進めていく。

必須要件による候補の絞り込み

　評価軸を設定する前に、Step1で整理した要件を必須と任意に分類し、必須条件を満たさない候補を比較対象から除外する。

図4　必須/任意の分類　要件の足切り基準と評価軸の区別（作成：アクセンチュア）

　必須要件を任意要件と混在させてスコアリングすると、他の軸の高スコアで補完され「合計は高いが絶対条件を満たしていない」候補が選ばれるリスクがある。

必須条件と判断する基準：

• 満たさない場合に業務・法令上の重大な問題が生じる
• 代替手段や後工程での補完が不可能
• プロダクトオーナーが「これだけは絶対に外せない」と明言している

　なお、生成AIを使って非機能要件の洗い出しや整理を補助するケースも増えてきた。ただし、必須／任意の分類は業務上の優先度やステークホルダーの意図を踏まえた判断が必要であり、この振り分けには人間が責任を持つ必要がある。

　SQS vs Kafkaの例では、「メッセージロストは不可（少なくとも1回の配信保証）」が必須要件だが、SQS・Kafkaともにこれを満たすため両候補がスコアリングに進む。「メッセージ順序保証」は業務要件として明記されているが、本例では実装方式による対応余地があるため任意要件として評価軸に含める。ただし、もし順序保証が業務上絶対に外せない要件であれば、標準SQSはこの段階で比較対象から外れ、スコアリング自体が不要になる。

評価軸の導出　3つのパターンと落とし穴

　評価軸を洗い出す作業では、「軸が多過ぎて決められない」か「暗黙の前提が軸に現れない」のいずれかに行き着くことが多い。他のつまずき方もあり得るが、この二つが特に多い。前者は議論が拡散し、後者は議論すべき論点が埋もれる。

　意思決定の質を左右するのは「評価軸を幾つ設定したか」ではなく、「本当に判断を分ける軸を見つけられたか」だ。そのためには、次の3つのパターンを使い分けるとよい。

図5　評価軸導出の3パターン　要件逆引き型／制約起点型／失敗逆算型（作成：アクセンチュア）

パターン1：要件逆引き型

　最もオーソドックスな方法。非機能要件定義書やRFPから評価軸を直接導出する。

手順：

1. 非機能要件定義書（またはIPAの非機能要求グレード）から、対象領域に関連する要求項目を抽出する
2. 各要求を「この選択によって差がつくか？」でフィルタリングする
3. 差がつく項目は評価軸として採用し、差がつかない項目は削除せずに「検討済み・差なし」と明記して残す

例：

　メッセージ基盤の選定であれば、非機能要件の「スループット拡張性」「メッセージ順序保証」「運用性」「コスト」から、メッセージ基盤に関係する項目を抽出する。「セキュリティ」はSQSもKafkaも同水準で実現可能なため、「検討済み・差なし」と明記して評価表に残す。なお「信頼性（配信保証）」はStep1で必須要件として既に整理済みのため、ここでは評価軸に含めない。

　この状態を明記することが重要だ。単に項目を削除すると、後から見直したときに「検討したのか、見落としたのか」が判別できなくなる。「検討済み・差なし」として一目で分かる形で残しておけば、後工程で前提が変わったときにも「もう一度差がつくかを確認すべき軸」としてすぐに参照できる。一方で、重みを配分するときは「検討済み・差なし」の軸には0％を割り当て、重みの分散を防ぐ。

パターン2：制約起点型

　要件が曖昧な段階、あるいは新規事業でRFPが存在しない場合に有効。プロジェクトの制約条件から逆算して評価軸を導出する。

手順：

1. 期限、予算、チームスキル、既存システムとの互換性、規制要件などプロジェクトの制約を列挙する
2. 各制約を「○○が不足すると、何が起きるか？」の形に変換する
3. 変換結果を評価軸として定義する

例：

• 「構築期間が2週間」→（構築速度が不足すると期限を超過する）→ 構築速度
• 「Kafkaの運用経験者がチームにいない」→（運用スキルが不足すると障害対応が困難になる）→運用負荷の低さ

　制約起点型は、チームの暗黙の前提を明示的な評価軸に変換する効果がある。本稿のSQS vs Kafka事例で「構築速度」が軸に入ったのは、まさにこのパターンの適用だ。

パターン3：失敗逆算型

　過去の設計判断で問題が起きたケースから評価軸を逆算する方法。特に、暗黙の判断が原因となり後工程でトラブルが発生した経験があるチームに効果的だ。

手順：

• 過去の障害や手戻りの事例を3〜5件収集する
• 各事例について「何を評価していれば防げたか？」を問う
• その答えを評価軸として追加する

例：

• 「セキュリティ方式が途中で変わり、大幅な手戻りが発生した」→変更容易性を評価軸に追加
• 「運用引き継ぎ時に設計経緯が不明で混乱した」→説明可能性を評価軸に追加

　なお、蓄積された障害報告書やポストモーテムをAIに分析させ、評価軸候補を導き出す補助に使うことも可能だ。ただし「何を評価していれば防げたか」という問いの設計と、導き出された軸の妥当性の判断は、人間が担う必要がある。

3つのパターンの使い分けと組み合わせ

　3つのパターンは、どれか1つを選ぶというより、プロジェクトの状況に応じて使い分け、必要に応じて組み合わせることが実務的だ。

使い分けの考え方：

• パターン1（要件逆引き型）を基本とする：非機能要件定義書やRFPが存在する場合は、このパターンから始めるのがオーソドックスで、実務でも最頻出だ
• パターン2（制約起点型）を追加する：要件が曖昧な新規事業フェーズや、期限、予算、チームスキル不足などプロジェクト固有の制約が判断を左右する場合
• パターン3（失敗逆算型）を活用する：チームが過去に似た判断で失敗した経験がある、あるいは判断後に「これを評価していれば防げた」という学習がある場合

組み合わせの例：

　本稿のSQS vs Kafkaの事例では、パターン1で非機能要件から「スループット拡張性」「メッセージ順序保証」「運用性」「コスト」を抽出し、パターン2で制約「構築期間が2週間」「Kafka運用経験者がいない」から「構築速度」「運用負荷の低さ」を導出した。

　パターン1の「運用性」とパターン2の「運用負荷の低さ」を統合すると、結果として5つの軸に収まる。各軸の由来を整理すると、スループット拡張性・メッセージ順序保証・コストがパターン1由来、構築速度・運用負荷の低さがパターン2由来となる。パターン3についても過去の障害事例からの逆算を試みたが、このチームには類似判断での失敗経験がなく、新たな軸は生まれなかった。

　3つのパターンから導き出した全ての軸を集め、「本当に判断を分ける軸」に絞り込む過程で、単一のパターンでは見落としていた論点も拾い上げられる。

図6　3パターンから5軸への導出マッピング　SQS vs Kafka 事例（作成：アクセンチュア）

軸の数の目安

　実務上、評価軸は4〜7個が適切だ。3個以下だと判断の解像度が粗過ぎてしまい、8個以上だと重みづけの合意に時間がかかり過ぎる。7個を超えた場合は、類似した軸を統合するか、優先度の低い軸を除外する。

重みづけ　なぜ難航するのか

　評価軸が決まっても、各軸の重み（優先度）を決める段階で手が止まることが多い。原因は議論の進め方にあるのではなく、判断の対象と前提の整理が済んでいないことにある。典型的なのは次の3つだ。

1. 判断の単位が広過ぎる：システム全体で1つの重みを決めようとすると、可用性重視の決済処理と、応答速度重視の参照系が同じ土俵に乗ってしまう。重みは、サブシステムや処理特性の単位まで判断対象を絞って初めて決まる
2. 前提条件が言語化されていない：フェーズ、期限、運用体制、要員スキルといった前提が共有されないまま重みだけを議論すると、根拠を欠いた主観のぶつけ合いになる。重みは前提条件の従属変数であり、前提がそろえば配分の多くは自ずと決まる
3. 検討済み・差なしの軸を削除してしまう：候補間で差が出ない軸を評価表から削除すると、後から見た人はその軸を検討したのかどうかを判別できなくなる。検討済み・差なしと明記して軸を残し、重み0％を割り当てることで、前提が変わったときの再検討も容易になる

　さらに、重みは一度決めれば終わりという性質のものでもない。その重みで結論が変わるかどうかを検証しない限り、配分の議論に意味があるかすら判断できない。0.1ポイントの差にこだわっても結論が動かない軸があれば、そこは議論の対象ではない。逆に、わずかな変動で結論が入れ替わる軸こそ、前提条件までさかのぼって詰めるべき論点になる。

重み設定を作成する

　まず、評価軸ごとに重みを設定する。ここでは「なぜその重みなのか」を簡潔に言語化しておくことが重要だ。

重み設定の作成ルール：

• 合計が100％になるように配分する
• 1つの軸に偏り過ぎないよう、最大50％を目安にする
• 各軸に1行で根拠を書く（例：順序保証は業務要件で優先度高、など）
• 前提条件を明記する（フェーズ、期限、運用体制、要員スキル）

　この時点で重み設定と前提条件を固めておくことで、後続のスコアリングと検証を迷いなく進められる。

図7　重み設定例。SQS vs Kafka 評価軸と重みづけ（作成：アクセンチュア）

本稿の整理と次回予告

　今回は、設計判断のStep1とStep2を解説した。

　Step1では、曖昧な声を数値・条件に変換する定量化と、要件を必須／任意に分類して比較候補を絞り込む考え方を示した。Step2では、3つのパターン（要件逆引き型、制約起点型、失敗逆算型）を使って「本当に判断を分ける軸」を導出し、前提条件を言語化しながら重みを設定するプロセスを扱った。

　次回は、この評価軸と重みを使って実際にどう候補案を比較し、意思決定を確定させるかを解説する。スコアリングの組み立て方・感度分析による判断の検証・アーキテクチャレビューでの確定という3つの作業を、SQS vs Kafkaの例を通じて順に示す。

著者プロフィール：前出 祐吾（まえで ゆうご）

アクセンチュア デジタルコア シニア・マネジャー。SIerでアプリケーション基盤の構築・プロジェクト展開などの経験を経て2023年アクセンチュア入社。金融系システムを軸としたアーキテクトとしてプロジェクトに参画する傍ら、昨今は生成AIを使ったソリューション開発などにも携わっている。