本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソリューションアーキテクチャ」カテゴリ第1弾として、ソリューションアーキテクチャ概論について解説する記事です。
EAが「地図」ならソリューションアーキテクチャは個別プロジェクトの走行ルート。ビジネス要件と既存システム・EA方針を踏まえ、予算・納期・組織制約の中で最適解を導く設計領域です。本記事ではEAとの違い、要件定義〜PoCまでの実務フロー、ソリューションアーキテクトの責務と道具を俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ITアーキテクチャのセオリー』も参考にしてみてください。
この記事の結論
- 設計案は必ず複数比較する
- 非機能要件を数値化し、ROIを数字で示す
- Buy / Build / Subscribeを常に選択肢に入れる
この記事を読む前に
本記事はシステム全体の要件や費用対効果の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「サーバーとクラウドの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもソリューションアーキテクチャとは何か
建築設計事務所を想像してください。施主の「こんな家に住みたい」という要望を聞き、予算・土地の制約・建築基準法を踏まえて、現実的に建てられる最善の設計図を描くのが建築士の仕事です。
ソリューションアーキテクチャは、ITにおける建築設計です。ビジネス要件と既存システム・EA方針を踏まえ、予算・納期・組織制約の中で最適な技術設計を導く領域です。EAが「都市計画（全体地図）」なら、ソリューションアーキテクチャは「個別の建物の設計図」です。
もしソリューションアーキテクチャがなければ、技術者は要件を正しく理解しないまま実装を始め、完成後に「これは求めていたものと違う」という手戻りが発生します。
なぜ独立したアーキテクチャとして扱うか
ビジネス要件と技術の翻訳が必要
業務部門が欲しいのは「売上が上がる仕組み」であり、技術は二の次です。要件を技術設計に翻訳する専門性が求められます。
既存システムとの整合が絶対条件
個別プロジェクトでも既存の認証基盤・DB・ネットワークとの接続は必須です。ゼロから作れる案件は稀で、既存にどう接続するかが設計の大半を占めます。
予算・納期の制約で最適解が変わる
理想の設計は潤沢な予算と時間を前提にした空想です。ソリューションアーキテクトは制約の中で最も合理的な設計を選ぶ必要があります。
ソリューションアーキテクトの仕事
時系列で並べると次のようになります。全フェーズに関わる点が特徴で、「要件定義だけ」「設計だけ」ではありません。
| フェーズ | 主な作業 |
|---|---|
| 要件ヒアリング | 業務課題・ユーザー像・規模感の把握 |
| 現状分析 | AS-IS システム・制約・組織の把握 |
| 構想設計 | 複数案の提示・比較・選定 |
| 詳細設計 | コンポーネント分割・データフロー・API設計 |
| 見積もり | 工数・コスト・期間の概算 |
| 実装支援 | 技術課題の相談・設計レビュー |
| リリース後レビュー | 当初の判断が正しかったかの振り返り |
典型的な設計プロセス
ソリューションアーキテクチャは複数案を出して選ぶのが標準です。1案だけ出すと、それが最適かどうかの判断ができません。最低3案を出して比較するのが鉄則です。
例えば「社内申請ワークフローを作りたい」という要件に対しては、以下のような3案が考えられます。
- A案：SaaS（ServiceNow・kintone）を導入
- B案：クラウドのローコード（Power Platform・Glide）で作る
- C案：自社でフルスクラッチ開発
それぞれについて初期コスト・運用コスト・カスタマイズ性・期間・リスクを整理し、顧客と一緒に選びます。A案が100万円・1か月、C案が2000万円・1年なら、要件を見直してA案に寄せるのが賢明な判断です。
機能要件と非機能要件
ソリューションアーキテクチャで最も重要なのが非機能要件の定義です。機能要件は業務部門が書けますが、非機能要件（性能・可用性・セキュリティ・運用）は専門家でないと書けません。ソリューションアーキテクトの腕の見せ所です。
| 種類 | 内容 | 例 |
|---|---|---|
| 機能要件 | システムが何をするか | 申請登録・承認・通知 |
| 性能要件 | どれだけ速く | 応答3秒以内・同時100ユーザー |
| 可用性 | どれだけ止まらないか | 99.9%・月43分以内 |
| セキュリティ | どう守るか | MFA必須・監査ログ7年保存 |
| 運用 | どう運用するか | 24／7・営業時間のみ |
| 拡張性 | 将来どこまで伸びるか | 10倍のトラフィック |
非機能要件を決めずに進めると、完成してから「遅い」「止まる」で大炎上します。
プロジェクトで決めるべきこと
決める項目は要件面と設計面に大別されます。要件面では、解決すべき課題（業務効率化 / 新規事業 / コスト削減）、スコープ（最小機能かフル機能か）、対象ユーザー（社内 / 顧客 / 外部パートナー）、利用規模（10人か100万人か）、予算、そして非機能要件の目標値。設計面では、Buy / Build / Subscribe（既製品・自社開発・SaaS）、クラウドかオンプレか、既存システムとの連携方式（API / ファイル / イベント）、認証基盤（既存SSO活用か新規か）、データ管理、運用体制（内製 / 外部委託）です。
こうした決定はADR（アーキテクチャ決定記録）として残しておくと、後からの見直しに効きます。
ROIと見積もり
ソリューションアーキテクトは ROI（Return on Investment）の計算にも責任を持ちます。この投資がいくら儲けを生むかを示せないと、プロジェクトが承認されません。
例えば「申請ワークフローのデジタル化」なら、以下のような構図になります。
- 投資：初期500万円 + 年間100万円の運用費
- 効果：月間500時間の業務削減 × 時給3000円 × 12か月 ＝ 年間1,800万円の削減
3年回収・5年で数倍のリターンを示します。効果が曖昧だと決裁が通らないため、投資対効果を数値で示すのがソリューションアーキテクトの重要な仕事です。
技術設計ができるだけではダメ。数字で語れる設計ができて一人前です。
PoCの使い所
ソリューションアーキテクチャで不確実な部分がある場合、PoCで小さく試します。PoC は全部作る前に核心の課題だけ検証するための手段で、早く失敗して軌道修正するのが目的です。
PoC で検証すべきは「技術的に可能か」ではなく、ビジネス価値があるかです。技術的に可能でも業務に役立たなければ意味がありません。検証対象は未知技術の性能・品質、ユーザー反応・業務効果、データの質と量に絞り、既知技術の細かい仕様やUIのデザインをPoCで検証するのは時間の無駄です。詳細はPoC設計の記事で扱います。
プロジェクト規模別の設計深度
ソリューションアーキテクチャの深度と工数はプロジェクト規模で変わります。先に結論を言うと、要件定義にプロジェクト全体の20%以上を割くのが中規模以上では鉄則で、ここをケチると後工程で10倍返しになります。以下が業界標準の段階表です。
| プロジェクト規模 | 予算 | 要件定義工数 | 成果物 | バッファ |
|---|---|---|---|---|
| 小規模（〜3か月） | 〜1,000万円 | 1〜2週間（全体の10%） | ユーザーストーリー + Figma | +10〜20% |
| 中規模（6〜12か月） | 1,000万〜1億円 | 1〜3か月（15〜25%） | 要件定義書 + BPMN | +20〜30% |
| 大規模（1〜3年） | 1〜10億円 | 3〜6か月（25〜30%） | AS-IS／To-Be 詳細 + PoC複数 | +30〜50% |
| 超大規模（3年〜） | 10億円〜 | 6か月〜1年（30%以上） | 多段階要件 + 業界認定 | +50〜100% |
ROI評価の数値Gateは、Payback 3年以内・3年ROI 100%以上が承認ライン。見積もりはピッタリではなく幅で──「3000万〜4500万円、バッファ50%」の提示が信頼される書き方です。
規模に応じた設計深度を守る。小規模で大規模の手法は過剰投資、逆は炎上します。
このカテゴリの知識構造
このカテゴリは全5記事で構成されています。プロジェクトのライフサイクルに沿って読み進める構造です。
この5記事は、ソリューションアーキテクトが実際のプロジェクトで踏む手順をそのまま記事にしています。概要で全体像を掴み、要件定義で課題を整理し、非機能要件で品質を数値化し、ROIで投資対効果を示し、不確実な部分をPoCで検証する──この流れが一連の実務プロセスです。
途中から読むことも可能ですが、要件定義の作法を理解せずに非機能要件やROIだけを学んでも、前提が欠けた断片知識になりがちです。時間が限られる場合は、概要（本記事）と要件定義の2本だけでも通すと、残り3本の理解度が大きく変わります。
やってはいけないこと
各論記事で触れる禁じ手のうち、プロジェクト設計レベルで押さえるべき核心を6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 現場観察せずインタビューだけで要件定義 | Target Canada 2015年撤退（20億ドル損失）のパターン → 現場を見る |
| 1案だけを提案書に載せる | 比較不能で最適判断ができない → 最低3案を比較する |
| 機能要件だけ決めて非機能要件を後回し | 完成後に「遅い」「止まる」で大炎上 → 最初に数値化する |
| ピッタリ見積もりで提示 | 自治体基幹刷新3億円→12億円化のパターン → 幅とバッファで提示する |
| PoCのGo/No-Go基準を決めずに開始 | 「まあまあ動きました」の玉虫色報告で終わる → 数値基準と期限を先に決める |
| 技術論理だけの提案書 | 役員会で「で、いくら儲かるの？」と撃沈 → ROIのスライドを最初に置く |
ソリューションアーキテクチャは技術で殴らず数字で殴る。制約の中での合理解が現場を救います。「最新技術で提案すれば通る」という過信も禁物で、最新技術は情報・人材不足のリスクを抱えます。
AI判断軸 ― 提案の作り方が変わった
AIが複数案比較を現実的にした理由
ソリューション提案で最も工数がかかるのは「3案出して比較表を作る」工程です。従来は1案でも設計に数週間かかるため、2案目・3案目は既存事例のコピーで済ませるケースが多くありました。
AIコーディングツールが変えたのは、プロトタイプの初期構築速度です。SaaS組み合わせ案、フルマネージド案、OSS自前構築案のそれぞれについて、技術構成図・概算コスト・移行ステップの骨子を数時間で生成できます。人間の仕事は「どの観点で比較するか」の軸設計と、生成された案の実現可能性を現場知識で検証する部分に移ります。
ただし、AIが出す比較案は学習データ上の典型構成に偏ります。自社固有の制約（既存契約・組織体制・法規制）は人間が明示的に条件として与えない限り反映されません。「3案出して」と丸投げするのではなく、制約条件を箇条書きで渡してから生成させることが精度を分けます。
SaaS+APIファーストがAI活用の前提になる
Buy／Build／Subscribeの判断で、AI時代はSubscribe（SaaS利用）の優位性がさらに高まっています。理由は単純で、主要SaaSはAPIドキュメントが充実しており、AIがそのまま連携コードを生成できるからです。
フルスクラッチで実装した独自システムは、AIが参照できるドキュメントがほぼ存在しません。結果として保守・拡張のたびに人間が全コンテキストを読み解く必要があり、AI時代の生産性向上から取り残されます。
差別化領域だけをBuild（自前実装）し、それ以外はSaaSのAPIを組み合わせる設計にしておくと、AI活用の恩恵を最大限受けられます。提案書を書く際も「なぜ自前実装するのか」の説明責任が以前より重くなっていることを意識してください。
筆者メモ — 「技術論理だけの提案書」が役員会で撃沈する話
技術的に美しい提案書を書き上げて意気揚々と持ち込んだら、役員会で「で、いくら儲かるの？」の一言で撃沈する──というのは、ソリューション提案の現場で繰り返される失敗の典型です。
アーキテクチャ図も技術選定理由も完璧、性能試算も網羅、移行リスク評価も丁寧──それでも費用対効果の数字が一行もなければ稟議は通りません。役員会では、技術論ではなく「年間いくら浮くか」「いくら稼ぐか」が判断軸になるからです。
「技術で殴っても稟議は通らない。数字で殴れ」という現場の格言が示すように、どんな設計書でも最初に年間いくら浮くか・いくら稼ぐかのスライドを置けば通過率が格段に上がる、と言われる所以です。技術設計の質を上げる努力と同じくらい、数字で語る訓練を積むのが、ソリューションアーキテクトの実力差になります。
まとめ
本記事はソリューションアーキテクチャ概論について、複数案比較・非機能要件・ROI・PoC・規模別設計深度・AI時代の役割シフトまで含めて解説しました。如何だったでしょうか。
複数案を比較し、非機能要件を数値化し、Buy/Build/Subscribeを意識し、ROIを数字で示す。これが2026年のソリューションアーキテクチャの現実解です。
次回は「要件から設計への橋渡し」について解説します。要件定義の作法と落とし穴を、現場観察・3案比較・トレーサビリティの観点から掘り下げる予定です。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS ソリューションライブラリ も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（81/95）