本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソリューションアーキテクチャ」カテゴリ第1弾として、ソリューションアーキテクチャ概論について解説する記事です。
EAが「地図」ならソリューションアーキテクチャは個別プロジェクトの走行ルート。ビジネス要件と既存システム・EA方針を踏まえ、予算・納期・組織制約の中で最適解を導く設計領域です。本記事ではEAとの違い、要件定義〜PoCまでの実務フロー、ソリューションアーキテクトの責務と道具を俯瞰します。
このカテゴリの他の記事
なぜ独立したアーキテクチャとして扱うか
ビジネス要件と技術の翻訳が必要
業務部門が欲しいのは「売上が上がる仕組み」であり、技術は二の次です。要件を技術設計に翻訳する専門性が求められます。
既存システムとの整合が絶対条件
個別プロジェクトでも既存の認証基盤・DB・ネットワークとの接続は必須です。ゼロから作れる案件は稀で、既存にどう接続するかが設計の大半を占めます。
予算・納期の制約で最適解が変わる
理想の設計は潤沢な予算と時間を前提にした空想です。ソリューションアーキテクトは制約の中で最も合理的な設計を選ぶ必要があります。
ソリューションアーキテクトの仕事
時系列で並べると次のようになります。全フェーズに関わる点が特徴で、「要件定義だけ」「設計だけ」ではありません。
| フェーズ | 主な作業 |
|---|---|
| 要件ヒアリング | 業務課題・ユーザー像・規模感の把握 |
| 現状分析 | AS-IS システム・制約・組織の把握 |
| 構想設計 | 複数案の提示・比較・選定 |
| 詳細設計 | コンポーネント分割・データフロー・API設計 |
| 見積もり | 工数・コスト・期間の概算 |
| 実装支援 | 技術課題の相談・設計レビュー |
| リリース後レビュー | 当初の判断が正しかったかの振り返り |
典型的な設計プロセス
ソリューションアーキテクチャは複数案を出して選ぶのが標準です。1案だけ出すと、それが最適かどうかの判断ができません。最低3案を出して比較するのが鉄則です。
flowchart LR
REQ([業務要件])
A[A案: SaaS<br/>ServiceNow / kintone<br/>初期100万円・1ヶ月]
B[B案: ローコード<br/>Power Platform / Glide<br/>初期300万円・3ヶ月]
C[C案: フルスクラッチ<br/>初期2000万円・1年]
EVAL{比較評価<br/>コスト/期間/<br/>カスタマイズ性/リスク}
PICK([最適案を選定])
REQ --> A --> EVAL
REQ --> B --> EVAL
REQ --> C --> EVAL
EVAL --> PICK
classDef req fill:#fef3c7,stroke:#d97706;
classDef opt fill:#dbeafe,stroke:#2563eb;
classDef eval fill:#fae8ff,stroke:#a21caf;
classDef pick fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class REQ req;
class A,B,C opt;
class EVAL eval;
class PICK pick;例えば「社内申請ワークフローを作りたい」という要件に対しては、以下のような3案が考えられます。
- A案：SaaS（ServiceNow・kintone）を導入
- B案：クラウドのローコード（Power Platform・Glide）で作る
- C案：自社でフルスクラッチ開発
それぞれについて初期コスト・運用コスト・カスタマイズ性・期間・リスクを整理し、顧客と一緒に選びます。A案が100万円・1か月、C案が2000万円・1年なら、要件を見直してA案に寄せるのが賢明な判断です。
機能要件と非機能要件
ソリューションアーキテクチャで最も重要なのが非機能要件の定義です。機能要件は業務部門が書けますが、非機能要件（性能・可用性・セキュリティ・運用）は専門家でないと書けません。ソリューションアーキテクトの腕の見せ所です。
| 種類 | 内容 | 例 |
|---|---|---|
| 機能要件 | システムが何をするか | 申請登録・承認・通知 |
| 性能要件 | どれだけ速く | 応答3秒以内・同時100ユーザー |
| 可用性 | どれだけ止まらないか | 99.9%・月43分以内 |
| セキュリティ | どう守るか | MFA（Multi-Factor Authentication＝多要素認証）必須・監査ログ7年保存 |
| 運用 | どう運用するか | 24／7・営業時間のみ |
| 拡張性 | 将来どこまで伸びるか | 10倍のトラフィック |
非機能要件を決めずに進めると、完成してから「遅い」「止まる」で大炎上します。
決めるべきこと①:要件面
| 項目 | 選択肢の例 |
|---|---|
| 解決すべき課題 | 業務効率化・新規事業・コスト削減 |
| スコープ | 最小機能／フル機能 |
| 対象ユーザー | 社内／顧客／外部パートナー |
| 利用規模 | 10人・1000人・100万人 |
| 予算 | 初期・運用・期間 |
| 非機能要件 | 性能・可用性・セキュリティ目標 |
決めるべきこと②:設計面
| 項目 | 選択肢の例 |
|---|---|
| Buy／Build／Subscribe | 既製品・自社開発・SaaS |
| クラウド／オンプレ | AWS・Azure・GCP・自社 DC |
| 既存システム連携 | API・ファイル・イベント |
| 認証基盤 | 既存SSO（Single Sign-On＝一度の認証で複数サービスに入れる仕組み）活用・新規構築 |
| データ管理 | 新DB・既存DB共有 |
| 運用体制 | 内製・外部委託 |
ROIと見積もり
ソリューションアーキテクトは ROI（Return on Investment）の計算にも責任を持ちます。この投資がいくら儲けを生むかを示せないと、プロジェクトが承認されません。
例えば「申請ワークフローのデジタル化」なら、以下のような構図になります。
- 投資：初期500万円 + 年間100万円の運用費
- 効果：月間500時間の業務削減 × 時給3000円 × 12か月 ＝ 年間1,800万円の削減
3年回収・5年で数倍のリターンを示します。効果が曖昧だと決裁が通らないため、投資対効果を数値で示すのがソリューションアーキテクトの重要な仕事です。
技術設計ができるだけではダメ。数字で語れる設計ができて一人前です。
PoCの使い所
ソリューションアーキテクチャで不確実な部分がある場合、PoC（Proof of Concept＝概念実証）で小さく試します。PoC は全部作る前に核心の課題だけ検証するための手段で、早く失敗して軌道修正するのが目的です。
PoC で検証すべきは「技術的に可能か」ではなく、ビジネス価値があるかです。技術的に可能でも業務に役立たなければ意味がありません。
| PoCで検証すべき | PoCで検証すべきでない |
|---|---|
| 未知技術の性能・品質 | 既知技術の細かい仕様 |
| ユーザー反応・業務効果 | UIの細かいデザイン |
| データの質・量 | 既に検証済みの構成 |
プロジェクト規模別の設計深度
ソリューションアーキテクチャの深度と工数はプロジェクト規模で変わります。先に結論を言うと、要件定義にプロジェクト全体の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%」の提示が信頼される書き方です。
規模に応じた設計深度を守る。小規模で大規模の手法は過剰投資、逆は炎上します。
ソリューションアーキテクチャ全体の鬼門
各論記事で触れた禁じ手のうち、プロジェクト設計レベルで押さえるべき核心を1枚に。
| 禁じ手 | なぜダメか |
|---|---|
| 現場観察せずインタビューだけで要件定義 | Target Canada 2015年撤退（20億ドル損失）のパターン |
| 1案だけを提案書に載せる | 比較不能、最低3案が鉄則 |
| 機能要件だけ決めて非機能要件後回し | 完成後に「遅い」「止まる」で大炎上 |
| ピッタリ見積もりで提示 | 自治体基幹刷新3億円→12億円化のパターン、幅で提示 |
| 定性効果を全て数値化 | 無理な数値化は信頼低下、並列記載が誠実 |
| PoCのGo/No-Go基準を決めずに開始 | 「まあまあ動きました」の玉虫色報告 |
| AI活用効果を計上せずROI算出 | 業務時間削減30%等が直接影響、AI前提で再計算 |
| 技術論理だけの提案書 | 大企業の役員会で「で、いくら儲かるの？」で撃沈 |
| 段階的リリースなしのウォーターフォール | 新規事業・AI活用では柔軟性で失敗 |
| PoCの期間に上限なし | 永遠に続く、「もう少しで答えが出そう」で半年延長 |
ソリューションアーキテクチャは技術で殴らず数字で殴る。制約の中での合理解が現場を救います。
AI時代の視点
AI 駆動開発（バイブコーディング）が前提になると、ソリューションアーキテクトの仕事はAIが書くコードの設計を決める人にシフトします。実装速度は AI で10倍になる一方、「何を作るか・どう作るか」を決める仕事の価値が相対的に上がります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| 要件を数字で定義できる | 曖昧な「いい感じに」要件 |
| 既存SaaS・主流技術を組み合わせる設計 | 独自実装・フルスクラッチ |
| 非機能要件を最初に数値化 | 性能・可用性を後回し |
| 段階的リリース（PoC→MVP＝Minimum Viable Product・実用最小限製品→本番） | ウォーターフォールで一括リリース |
AI が実装を引き受けるため、要件定義・非機能要件・PoC設計の品質がプロジェクト成否を決めます。コードを書く時間が減り、何を作らないかを決める時間が増えるのが AI 時代のソリューションアーキテクトの姿です。
AI が書く時代ほど、要件定義と非機能要件の価値が上がります。
よくある勘違い
ソリューションアーキテクチャは「技術選定だけの仕事」と思われがちですが、要件定義から数字で語る説明責任まで含む総合職です。非専門家が陥りやすい代表的な誤解を整理します。
最新技術で提案すれば通る
最新技術は情報不足・人材不足のリスクを背負います。制約（予算・納期・人材）の中で最も合理的な設計を選ぶのが本業で、新しさは選定軸の一つにすぎません。
1案だけ提示する
1案では比較対象がなく、最適かどうか判断できません。最低3案を出して Buy／Build／Subscribe で比較し、顧客と一緒に選ぶのが鉄則です。
非機能要件は後で決める
性能・可用性・セキュリティ・運用を後回しにすると、完成してから「遅い」「止まる」で大炎上します。要件定義の段階で数値化するのが最大のリスク予防になります。
技術ができれば一人前
技術設計だけでは半人前で、ROIを数字で示して決裁を通すところまでが責任範囲です。数字で語れない設計は、どれだけ優れていても承認されません。
技術設計ができるだけではなく、数字で語れて一人前です。
筆者メモ — 「技術論理だけの提案書」が役員会で撃沈する話
技術的に美しい提案書を書き上げて意気揚々と持ち込んだら、役員会で「で、いくら儲かるの？」の一言で撃沈する──というのは、ソリューション提案の現場で繰り返される失敗の典型です。
アーキテクチャ図も技術選定理由も完璧、性能試算も網羅、移行リスク評価も丁寧──それでも費用対効果の数字が一行もなければ稟議は通りません。役員会では、技術論ではなく「年間いくら浮くか」「いくら稼ぐか」が判断軸になるからです。
「技術で殴っても稟議は通らない。数字で殴れ」という現場の格言が示すように、どんな設計書でも最初に年間いくら浮くか・いくら稼ぐかのスライドを置けば通過率が跳ね上がる、と言われる所以です。技術設計の質を上げる努力と同じくらい、数字で語る訓練を積むのが、ソリューションアーキテクトの実力差になります。
最終的な判断の仕方
ソリューションアーキテクチャの核心は制約の中で最も合理的な設計を選ぶという発想です。理想の設計は潤沢な予算と時間を前提にした空想で、実務は予算・納期・組織制約・既存システムとの整合という壁の中で最適解を導く仕事です。ビジネス要件を受け取り、EA の方針を踏まえ、複数案（最低3案）を比較提示し、ROI を数字で語って決裁を通すまでが一連の責任範囲になります。技術設計ができるだけでは半人前で、数字で語れてはじめて一人前です。非機能要件（性能・可用性・セキュリティ・運用）の定義がプロジェクト炎上を防ぐ最大のレバレッジになります。
もう一つの決定的な軸はAIが書く時代に、要件定義と非機能要件の価値が跳ね上がるという変化です。実装速度が AI で10倍になる一方、「何を作るか・何を作らないか」を決める仕事の価値が相対的に上がります。曖昧な「いい感じに」要件は AI の力を引き出せず、数字で定義された要件と非機能要件が成否を決めます。段階的リリース（PoC → MVP → 本番）が AI 時代の定石です。
選定の優先順位
- 複数案を比較提示する — 最低3案、1案だけでは最適判断不能
- 非機能要件を最初に数値化 — 性能・可用性・セキュリティを後回しにしない
- Buy／Build／Subscribeを意識する — SaaS 活用、自社実装は差別化領域だけ
- ROIを数字で示す — 投資対効果で決裁を通す、曖昧な効果は承認されない
「制約の中で合理解を描き、数字で語る」AI 時代は要件定義と非機能要件の価値が上がります。
まとめ
本記事はソリューションアーキテクチャ概論について、複数案比較・非機能要件・ROI・PoC・規模別設計深度・AI時代の役割シフトまで含めて解説しました。如何だったでしょうか。
複数案を比較し、非機能要件を数値化し、Buy/Build/Subscribeを意識し、ROIを数字で示す。これが2026年のソリューションアーキテクチャの現実解です。
次回は「要件から設計への橋渡し」について解説します。要件定義の作法と落とし穴を、現場観察・3案比較・トレーサビリティの観点から掘り下げる予定です。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（75/89）