ソリューションアーキテクト（Solutions Architect、略してSA）は、クラウドやソフトウェアの会社で、顧客の課題を自社の製品で解く仕組みを設計する技術職だ。営業と一緒に顧客に会い、技術の面から導入を決めてもらい、導入の途中で出る技術の問題にも答える。
生成AIの会社が人を増やすなかで、SAと名前の近い職種が増えた。プリセールス、セールスエンジニア、AIアーキテクト、そしてFDE（Forward Deployed Engineer）。どれも顧客と技術の間に立つが、どこまで手を動かすか、いつ仕事が終わるかが違う。この記事は、AWSとOpenAIが公開している職種の説明から、SAの仕事内容と、近い職種との違いを整理する。FDEという職種そのものはFDEとは？Forward Deployed Engineerの意味と仕事内容で説明している。
ソリューションアーキテクトの仕事内容
SAの仕事を説明している公開情報のうち、いちばん具体的なのはAWSの日本の採用ページだ。そこでは、SAは顧客のシニアクラス（CxOレベルを含む）と議論してクラウド戦略に影響を与え、同時に顧客のアーキテクトや開発者と技術的な議論を交わし、実現可能性を顧客と確かめながら、既存システムの移行と新しい技術を使ったイノベーションをリードするポジションだと説明している。
同じページは、SAの典型的なタスクとして次を挙げている。
| 典型的なタスク（AWSの採用ページ） | 中身の補足 |
|---|---|
| お客様ヒアリングによるクラウド活用機会の発掘 | 顧客の課題を聞き、製品で解けるところを探す |
| 技術課題を打破するためのディスカッション | 顧客の技術者と、設計や移行の壁を一緒に考える |
| アーキテクチャ設計支援や技術検証 | 構成を描き、動くかを検証で確かめる |
| 技術トレンドの調査・テクニカルコンテンツ作成 | 資料、ブログ、サンプルを作る |
| イベント登壇・ウェブセミナー実施 | 社外に技術を伝える |
AWSは、SAのポジションを大きく、案件対応中心のAccount SA、特定の技術領域を担当するスペシャリスト、パートナー対応中心のパートナーSAに分けている。担当する顧客の数もポジションで違い、一人が1〜3社を担当するポジションもあれば、アクティブな10〜15社が入れ替わりながら担当するポジションもある、と書いている。
SAの仕事を理解するうえで大事なのは、AWSが同じページで、SAはお客様の代わりに実作業を実施することはない、と明記していることだ。サンプルコードを渡したり、デモをしたりはするが、顧客のシステムでの作業を委託されたり請け負ったりはしない。設計と助言までがSAの持ち場で、作るのは顧客の技術者かパートナー企業になる。
プリセールスとの違い
日本では、SAとプリセールスが同じ意味で使われることがある。私の理解では、プリセールスは、受注の前に営業と組んで、技術の面から提案や製品のデモを受け持つ人を指す。
AWSの採用ページは、会社によって違いがあるかもしれないので一般論だとしたうえで、SAはプリセールスと比較して長期間にわたってお客様と関係を維持する、と書いている。顧客に製品を選んでもらうことは大事なミッションの一つだが、それだけでなく、開発・構築中に発生した課題解決の支援や、リリース後の最適化支援も重要な仕事だという。
私の見方では、二つの違いは仕事がどこで終わるかにある。
| プリセールス | ソリューションアーキテクト | |
|---|---|---|
| 主な時期 | 受注の前 | 受注の前から、導入後の改善まで |
| 主な相手 | 顧客の発注を決める人と、その技術の担当者 | 顧客の経営層から、設計と開発を担う技術者まで |
| 成果の見え方 | 受注、製品の選定 | 導入の成功、利用の広がり |
| 手を動かす範囲 | デモ、提案書、検証環境 | 設計、検証、サンプルコード（顧客のシステムの構築はしない） |
求人票の職種名だけでは、どちらの仕事かは分からない。応募や発注の前には、受注のあとも同じ人が担当を続けるかを確かめるとよい。
生成AIの会社のアーキテクトとFDE
生成AIの会社は、SAに近い職種と、FDEを別々に置いていることがある。OpenAIの東京の求人を並べると、二つの持ち場の違いがよく見える。2026年10月21日時点で、OpenAIの採用ページには東京勤務のApplied AI ArchitectとForward Deployed Engineerの求人が両方載っている。
| Applied AI Architect – Tokyo | Forward Deployed Engineer – Tokyo | |
|---|---|---|
| 所属 | Go To MarketのTechnical Success | Forward Deployed Engineering |
| 役割の説明 | 担当する顧客群の技術面の責任者で、顧客の経営陣の技術の窓口。担当顧客の「CTO」として、プリセールスの発見から、評価、展開、定着、事業への効果までを導く | 戦略的に重要な顧客と一緒に、最先端のモデルを本番に展開する仕事を端から端まで率いる。発見、技術的な範囲の決定、設計、構築、本番の展開を受け持つ |
| 実装との距離 | デリバリーのチームが関わり始めたら、実装の実行はそのチームが受け持つようにする | 進捗や明確さがそれに左右されるときは、コードに直接手を入れる |
| 成果の測り方 | 利用、アカウントの健全性、本番の準備、顧客への効果を追う | 本番での採用、業務への測れる効果、評価にもとづく製品へのフィードバックで測る |
アーキテクトは、技術の結果に責任を持ちながら、実装は専門のチームに渡す。FDEは、本番で動くところまで自分で作る。どちらも顧客の現場に深く関わるが、手を動かす範囲が違う。OpenAIとAnthropicがFDEを置いた背景はOpenAI・AnthropicのFDEにまとめた。
FDE・PM・SAの違い
ここまでを、近い職種と並べて整理する。どの職種も会社ごとに定義が違うので、これは私の見方による整理だ。
| 職種 | 何を決めるか | 自分で作るか | 仕事の終わり方 |
|---|---|---|---|
| ソリューションアーキテクト | 自社製品を使った顧客の構成 | 設計と検証まで。構築は顧客かパートナー | 導入が成功し、利用が広がる |
| プリセールス | 提案の中身と、製品が合うかどうか | デモと検証環境まで | 受注 |
| FDE | 顧客の業務のどこにAIを入れ、何を作るか | 作る。本番の運用まで面倒を見る | 本番で使われ、業務の数字が動く |
| PM（プロダクトマネージャー） | 自社の製品に何を作るか | 作らない。開発チームに渡す | 製品が市場で使われる |
| AIエンジニア | モデルとデータの扱い | 作る | 求められた精度と仕組みが動く |
SAとFDEは、顧客の課題から始める点が同じで、作るかどうかが違う。私の見方では、SAは自社製品の「正しい使い方」を顧客に広げる仕事で、FDEは顧客の業務に合わせて「動くもの」を作る仕事だ。FDEとSES・SIer・コンサルなどとの違いはFDEとSESの違いとは？に、AIエンジニアとの違いはAIエンジニアとはに、営業の仕組みを作るGTMエンジニアとの違いはGTMエンジニアとはに書いた。
ソリューションアーキテクトに向く人と、身につけること
私の見方では、SAに向くのは、自分で作るより、設計を説明して相手に作ってもらう方に面白さを感じる人だ。経営層に向けた話と、技術者に向けた細かい話を、同じ日に切り替えられることも求められる。
身につけることは、大きく3つある。
- 担当する製品と、その周りの技術の深い知識。クラウドならネットワーク、データベース、セキュリティまで
- 設計を言葉と図で説明する力。顧客が自分で作れるところまで伝える
- 顧客の事業の理解。技術の選択を、顧客の事業の数字につなげて話す
知識の目安として、クラウドの会社は認定資格を用意している。AWSには、AWS Certified Solutions ArchitectのAssociateとProfessionalがあり、Professionalの試験ガイドは、AWSでのクラウドソリューションの設計と実装について2年以上の経験を推奨している。資格は入口の目安で、顧客の前で設計を説明した経験の方が評価されると私は考えている。
SAから、作るところまで受け持つFDEに移る道もある。その場合に足りなくなりやすいのは、本番で動くコードを書いて運用する経験だ。FDEになる道筋はFDEになるには？にまとめた。
発注する側から見たSAとFDEの使い分け
AIやクラウドを入れる会社から見ると、製品ベンダーのSAは、その製品の正しい使い方を設計の段階から教えてくれる相手だ。ただ、AWSが明記しているように、SAは顧客のシステムを作らない。設計が決まったあと、誰が作り、誰が本番で運用するかは、発注する側が別に決める必要がある。
私の見方では、使う製品が決まっていて、自社に作る人がいるならSAの助言で足りる。作る人がいない、または業務のどこにAIを入れるかから決めたいなら、作るところまで受け持つ相手が要る。私たちの支援の中身はサービス詳細に書いた。