クラウドの勉強を進めると、求人や資格の話で「ソリューションアーキテクト」という言葉を目にします。設計だけをする上の立場のようにも聞こえますし、クラウドエンジニアと何が違うのか、SAA を取れば名乗れるのかも分かりにくいところです。この記事では、肩書きではなく仕事の中身から見分ける考え方を整理します。職種の比較そのものはクラウドエンジニアとは何かに任せ、ここでは SA の側から掘り下げます。
この記事の結論
- SA の中心は構築ではなく、要件を構成に変えて、判断の理由を説明することです。
- 所属（ベンダー・SIer・MSP・内製）によって形が変わり、肩書きと仕事は一致しないことが多いです。
- クラウドエンジニアとは仕事が重なり、違いは「何を聞いて何を決めるか」の比重に出ます。
- 必要な力は、サービスの知識、トレードオフを言葉にする力、図で伝える力、聞く力の四つです。
- SAA は構成を選ぶ力を学ぶ目安であり、職種の資格や名乗る条件ではありません。
ソリューションアーキテクトとは何か（要件を構成に変える役割）
ソリューションアーキテクト（SA）は、この記事では「相手の困りごとと制約を聞き、AWS のサービスを選んで構成として組み立て、その判断の理由を説明する役割」と整理します。公式の職務定義ページは確認できなかったため、一般論の定義は置かず、AWS の SAA 試験ページと Well-Architected フレームワークの記述を足場にします。
SAA の公式ページでは、対象が Solutions Architect の役割として書かれており、コストと性能を最適化した設計に焦点があり、コーディングの比重は小さいと説明されています。つまり公式の側でも、SA の仕事は「作る手」より「設計の判断」に軸足があると読めます。
ここで大事なのは、アーキテクトという言葉が「偉い人」を指すのではなく、「選んだ理由を説明できる人」を指す点です。構成は正解が一つに決まりません。可用性を優先すればコストが上がり、コストを抑えれば止まるリスクが残ります。この天秤の傾け方を、相手の事情に合わせて決めて、納得してもらうところまでが役割です。トレードオフの考え方は、次の記事で扱っています。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
CHECK 1ここまでの確認
ソリューションアーキテクトの中心の仕事として、最も近いものはどれ?
答えと解説
答え: 1. 相手の困りごとと制約を聞き、構成として組み立てて、その理由を説明する
SA の中心は「要件を構成に変えて、判断の理由を説明すること」です。構築そのものが中心ではありません。読み直すのは「SA は具体的に何をするのか」の章です。
SA は具体的に何をするのか（聞く → 選ぶ → 描く → 説明する → 見直す）
SA の仕事は、次の五つの駅を順に通る流れとして捉えると掴みやすくなります。
FROM ASK TO EXPLAINSA の仕事の流れ
要望が聞く・選ぶ・描く・説明するを通って、見直されていく
-
聞く
困りごとを聞く
-
整理
制約に直す
-
選ぶ
サービスを決める
-
描く
構成図にする
-
説明
理由を伝える
-
見直す
変化に合わせる
要望を聞き、制約を整理する
最初の仕事は作ることではなく聞くことです。相手の言う「早く」「安く」「止まらないように」は、そのままでは構成にできません。何が止まると困るのか、いつまでに必要か、予算の上限はあるか、既に使っているものは何か、守るべきルールはあるか。聞き出した内容を、優先順位つきの制約として整理します。この整理が、あとの全部の判断の根拠になります。
サービスを選び、構成に描く
制約が決まったら、サービスを選びます。マネージドサービスに任せて運用を軽くするのか、自分で細かく制御できる形にするのか。選択肢ごとに長所と短所があります。選んだ結果は、構成図として描きます。図は自分の理解のためだけでなく、相手と他のメンバーに伝える道具です。
理由を説明し、見直す
構成ができたら、なぜその構成なのかを説明します。「このサービスが良いから」ではなく、「この制約があるから、この選び方になった」と制約から結びます。説明の中で相手の新しい事情が出てくれば、構成を直します。運用が始まってからも、使われ方が変われば見直します。Well-Architected フレームワークは、決定の長所と短所を理解したうえで設計することを目的にしており、レビューも監査ではなく建設的な対話だと書かれています。SA の「説明して見直す」は、この考え方と同じ方向にあります。
クラウドエンジニア・インフラエンジニアとどう違うのか
結論から言うと、二つの職種は重なる部分が大きく、肩書きだけで線を引くことはできません。違いは「聞く・決める・作る・回す」のどこに仕事の比重があるかに出ます。
WEIGHT, NOT TITLE比重の違い
違いは肩書きでなく、どこに比重があるか
SA
聞いて決めて説明する
- 相手の制約を聞き出す
- サービスと構成を選ぶ
- 判断の理由を説明する
クラウドエンジニア
作って回して自動化する
- 構成を実際に作る
- 日々の運用と障害対応
- 手作業をコードにする
| 観点 | SA に比重があるもの | クラウドエンジニアに比重があるもの |
|---|---|---|
| 聞く | 相手の困りごとと制約を聞き出す | 決まった要件を受け取って確認する |
| 決める | サービスと構成の選択、判断理由の言語化 | 決まった構成の中での細かな設計 |
| 作る | 構成図・説明資料を作る | 実際に作る（構築、コード化） |
| 回す | 運用結果を見て構成を見直す | 日々の運用、障害対応、自動化 |
この表は「比重」の話で、SA が作らないという意味ではありません。小さな組織では一人が両方を担いますし、大きな組織では分業されます。従来のインフラエンジニアとの違いはクラウドエンジニアとは何かで整理済みなので、ここでは繰り返しません。
CHECK 2ここまでの確認
SA とクラウドエンジニアの違いを見分ける考え方として、適切なものはどれ?
答えと解説
答え: 2. 聞く・決める・作る・回すのどこに比重があるかで見る
二つの職種は重なる仕事が多く、肩書きは所属先によって変わります。違いは仕事の比重に出ます。読み直すのは「どう違うのか」の章です。
所属によって SA の仕事はどう変わるか
SA という名前が付く場所は一つではありません。誰を相手にするか、何を成果物にするかが所属で変わります。
WHERE SA WORKS所属ごとの違い
同じ SA でも、相手と成果物は所属で変わる
作る前 → 運用後
ベンダー
多くの顧客にサービスの使い方を説明する
SIer
特定の顧客の要件を構成に落とす
MSP
運用しやすい構成を提案する
内製
自社の事業の変化に合わせて見直す
相手が不特定 → 特定
- ベンダー: 多くの顧客に、自社サービスをどう使えば課題が解けるかを説明する立場です。サービスの幅広い知識が求められます。
- SIer: 特定の顧客のシステムを、要件定義から構成に落とす立場です。顧客との合意を取りながら構成を決めます。
- MSP: 運用を引き受ける立場から、運用しやすい構成を提案します。運用を見据えた判断が中心になります。
- 内製: 自社の事業部門が相手です。事業の変化に合わせて構成を見直し続けます。
同じ「SA」という名前でも、相手も成果物も違うため、求人を見るときは肩書きより仕事の説明を読むのが確実です。以上は仕事の型の整理であり、各社の実際の職務内容は募集要項で確認してください。
SA に必要な力は何か（段2の記事とのつながり）
必要な力は四つに分けられます。それぞれ、この媒体の段2の記事が材料になります。
- サービスの知識: 何をどのサービスが解くのかを知ること。EC2・RDS・Lambda などの「とは」から積み上げます。
- トレードオフを言葉にする力: 選んだ理由と、選ばなかった理由を並べること。
- 図で伝える力: 構成を一枚の図に描き、相手の知識に合わせて詳しさを変えること。
- 聞く力: 言葉の裏にある制約を引き出すこと。
READ ALSO — 学習中向け・段2 構成
ADR（設計判断の記録）の書き方｜「なぜそうしたか」を文脈・決定・結果の3点で残す
判断の理由を記録に残す書き方は、上の記事が扱っています。力を伸ばす近道は、読むだけではなく、自分で構成を決めて説明することです。
SAA は SA になるための資格か
SAA（AWS Certified Solutions Architect - Associate）は、公式ページで Solutions Architect の役割を対象にしていると書かれています。ただし、これは「その役割に必要な知識を確かめる試験」であり、取れば SA を名乗れるという職種の資格ではありません。名乗る条件は、所属先が決めることです。
使い方としては、構成を選ぶ力を学ぶ際の目安として使うのが向いています。試験範囲の問いは、要件から構成を選ぶ形になっているため、この記事の「聞く → 選ぶ」の練習と相性が良いです。試験の問題数や料金などの数値は版によって変わるので、受ける前に公式ページで確認してください（現行の版は台帳では SAA-C03 です）。
READ ALSO — 学習中向け・段2 構成
Solutions Architect Associate（SAA-C03）とは｜「構成を選ぶ力」の証明と段2の対応
CHECK 3ここまでの確認
SAA（AWS Certified Solutions Architect - Associate）の位置づけとして、適切なものはどれ?
答えと解説
答え: 2. 構成を選ぶ力を学ぶときの目安になる試験
SAA は構成を選ぶ力を確かめる試験で、職種の資格や名乗る条件ではありません。読み直すのは「SAA は SA になるための資格か」の章です。
学習者が今日からできる SA の練習（自分の構成を判断理由つきで説明する）
実務の経験が無くても、練習はできます。
- 題材を一つ決める（例: 小さな Web サイトを公開したい）。
- 制約を三つ書く（予算、止まったときの影響、運用に使える人数など）。
- サービスを選び、構成図を描く。
- 「なぜこの選び方か」「選ばなかった案は何か」を、制約と結びつけて書く。
- 一週間後に読み返し、制約が変わったらどう直すかを考える。
四番の「選ばなかった案」を書くのが肝心です。これが言えるようになると、構成を説明する力が付いてきます。
Cloudory 執筆者（AWS 認定 全冠）
SA は「作れない人の職種」でも「偉い人の肩書き」でもありません。聞いて、選んで、理由を説明するという仕事の比重の名前です。自分がどの比重に向いているかは、練習で自分の説明を書いてみると見えてきます。
この記事のまとめ
- SA の中心は、要件を構成に変えて判断の理由を説明することです。
- クラウドエンジニアとは重なり、違いは聞く・決める・作る・回すの比重に出ます。
- 所属で形が変わるため、肩書きより仕事の説明で見分けます。
- SAA は構成を選ぶ力の目安で、職種の資格ではありません。
参照ソース
- AWS Certified Solutions Architect - Associate（AWS 認定） — SAA の対象が Solutions Architect の役割であること、コスト・性能を最適化した設計に焦点があり、コーディングの比重が小さいことの根拠
- AWS Well-Architected Framework（AWS ドキュメント） — 決定の長所と短所を理解して設計すること、レビューが監査ではなく建設的な対話であることの根拠
