「クラウドの仕事に就きたい」と決めたのに、求人を見ると SIer・MSP・内製・クラウドエンジニア・インフラエンジニアと呼び名が並び、どれが何をする会社で、自分はどこから入ればいいのかが分からない。この記事は、クラウドに関わる仕事を「誰が・何を・どの順で」やっているかの地図として描きます。個人の体験談ではなく、業界の一般的な構造として書きます。
この記事の結論
- 「クラウドの仕事」は1つではなく、作る・守る・運用する・売る・教えるの5つに分かれます。
- 登場人物は AWS 本体・SIer とコンサル・MSP・内製のチーム・フリーランスで、責任の範囲が層のように分かれています。
- 1つの案件は要件 → 設計 → 構築 → 運用と流れ、段階ごとに出てくる人が変わります。
- 未経験の入口として多いのは運用・監視や構築の手伝いで、そこから構築、設計へと上がる道が一般的です。
- 資格は入口の会話の材料として効き、採用を決めるものではありません。
- 自分がどの役割に向いているかは、「動いている状態を見たい」か「作りたい」か「決めたい」かで見ます。
「クラウドの仕事」は1つではない｜作る・守る・運用する・売る・教える
クラウドとは何かで見たとおり、クラウドはコンピュータの資源を借りて使う形です。借りて使うだけなら仕事は要らないように見えますが、実際には「借りたものを組み、守り、動かし続ける」ために多くの人が働いています。その仕事は、大きく5つに分かれます。
| 仕事 | 何をするか | 呼ばれ方の例 |
|---|---|---|
| 作る | 要件を聞き、構成を決め、実際に組む | クラウドエンジニア、インフラエンジニア、アーキテクト |
| 守る | 誰が何にアクセスできるかを決め、攻撃や漏えいを防ぐ | セキュリティエンジニア |
| 運用する | 動いている状態を保つ。監視し、障害に対応し、直す | 運用エンジニア、SRE、監視オペレーター |
| 売る | 顧客に提案し、どのサービスをどう使うかを決める手伝いをする | プリセールス、ソリューションアーキテクト、コンサルタント |
| 教える | 社内や顧客に使い方を教え、人を育てる | トレーナー、テクニカルエバンジェリスト |
求人票の「クラウドエンジニア」は、この5つのうちどれか（多くは「作る」と「運用する」）を指しています。同じ肩書きでも、会社によって中身が違うのはこのためです。求人を読むときは、肩書きより「作る・守る・運用する・売る・教えるのどれか」で見ると、仕事の中身が見えます。
登場人物は誰か｜AWS 本体・SIer・MSP・内製・フリーランス
次に、その仕事を「誰がやっているか」です。登場人物は5種類で、責任の範囲が層のように分かれています。
- AWS 本体。 データセンターの建物・電気・機械・仮想化の土台を持ち、動かし続ける。利用者から見える「サービス」を作る側。
- SIer・コンサル。 顧客から案件を請け負い、要件を聞き、設計し、構築する会社。SIer（システムインテグレーター。仕組みを組み上げて納める会社）と呼ばれる。
- MSP。 作ったあとの運用・監視を代行する会社。MSP（マネージドサービスプロバイダー。運用を引き受ける事業者）と呼ばれる。夜間や休日の監視、障害の初動、日々の変更を担う。
- 内製のチーム。 自社のサービスや業務のために、自社の中でクラウドを組み、運用する人たち。要件を決める人と作る人が同じ会社にいる。
- フリーランス。 上のどれかに、人として入る。特定の段階（設計だけ・構築だけ）を担うことが多い。
この分担は、AWS が公開している責任共有モデル（AWS が担う部分と利用者が担う部分を分けた考え方）を、人に当てたものです。AWS は「クラウド自体」の安全と稼働を担い、「クラウドの中」の設定・データ・運用は利用者が担います。利用者側の仕事を、内製で全部持つのか、構築を SIer に、運用を MSP に頼むのか。その分け方で、登場人物が決まります。
WHO OWNS WHICH LAYER責任を人に当てる
土台は AWS。その上をどこまで自分の会社で持つか
全部内製
- 設備と機械（建物・仮想化）
- 構築（設計どおりに組む）
- 運用（監視・障害・変更）
- 要件と判断
構築を SIer に
- 設備と機械（建物・仮想化）
- 構築（設計どおりに組む）
- 運用（監視・障害・変更）
- 要件と判断
運用も MSP に
- 設備と機械（建物・仮想化）
- 構築（設計どおりに組む）
- 運用（監視・障害・変更）
- 要件と判断
自分の会社が持つ外の会社が担う
なぜこう分かれているか。土台（建物・機械）は規模が大きいほど安くなるので AWS が一手に持ち、その上の「何を作るか」は会社ごとに違うので利用者側に残ります。そして利用者側の仕事のうち、専門性が高く、自社で人を抱えにくい部分（構築の技術、夜間の監視）を外の会社が引き受ける。SIer と MSP は、利用者側の責任を「時間で分けて」引き受けていると見ると、違いが分かります。
CHECK 1ここまでの確認
責任共有モデルの考えを人に当てたとき、「データセンターの建物と機械」を担うのは誰?
答えと解説
答え: 1. AWS 本体
建物・電気・機械・仮想化の土台は AWS が担い、その上の設定・構築・運用を利用者側（内製・SIer・MSP）が分担します。「登場人物」の章を読み直してください。
1つの案件はどう流れるか｜要件 → 設計 → 構築 → 運用
登場人物が分かったら、1つの案件の中で「いつ誰が出てくるか」を見ます。案件は、どんな規模でも4つの段階を通ります。
- 要件。 何を、どれくらいの規模で、いつまでに、いくらで。決めるのは事業側（内製なら自社の担当、外注ならその顧客）。コンサルやプリセールスが横に付く。
- 設計。 要件を満たす構成を決める。どのサービスを、どうつなぎ、どこに境界を引くか。アーキテクトや設計者が担う。SIer なら SIer の設計者、内製ならその会社のエンジニア。
- 構築。 設計どおりに組む。ネットワークを作り、サーバーを立て、権限を設定し、動くことを確かめる。SIer の構築担当、内製のエンジニア、そこに入るフリーランス。
- 運用。 動いている状態を保つ。監視し、障害に対応し、変更を入れ、料金を見る。内製の運用担当か、MSP。
WHO SHOWS UP WHEN案件の流れ
段階ごとに出てくる人が変わる
-
要件
事業側・コンサル
-
設計
アーキテクト・設計者
-
構築
SIer・内製・フリーランス
-
運用
内製の運用担当・MSP
この流れは AWS の Well-Architected Framework（AWS が公開している、良い構成を作るための考え方の集まり）でも、「設計してから作り、作ったら運用で改善し続ける」という順で語られます。段階が分かれているのは、それぞれで要る技能と見るものが違うからです。要件では「何のためか」を、設計では「どう組むか」を、構築では「本当に動くか」を、運用では「動き続けているか」を見ます。
ここで大切なのは、段階ごとに出てくる人が違うが、同じ人が2つ以上の段階を担うこともあることです。内製のチームは要件から運用まで同じ人が見ることが多く、SIer は設計と構築を、MSP は運用を、と分かれます。「どの会社に入るか」は「どの段階を主に担うか」を選ぶことでもあります。
CHECK 2ここまでの確認
1つの案件が「要件 → 設計 → 構築 → 運用」と流れるとき、運用を代行する会社の呼び名はどれ?
答えと解説
答え: 2. MSP
MSP（マネージドサービスプロバイダー）は、作ったあとの運用・監視を代行する役割です。SIer は主に設計と構築を請け負います。「案件の流れ」の章を読み直してください。
未経験の入口はどこか｜運用・監視から構築、そして設計へ
未経験の人が最初に任されることが多いのは、運用・監視と、構築の手伝いです。理由は2つあります。手順が決まっていて、先輩の横で覚えられること。そして「動いている状態」を先に見ることで、あとで設計するときの判断の材料になることです。
FROM OPS TO DESIGN未経験からの道のり
動いている状態を知り、作り方を覚え、決める側へ
-
運用・監視
「正常」を知る
-
構築の手伝い
手順を再現する
-
構築
自分で組んで渡す
-
設計
理由を言葉にする
道のりは一般に、次の順で上がります。
| 段階 | 何を覚えるか | 持ち帰るもの |
|---|---|---|
| 運用・監視 | 動いている状態とは何か。障害の初動。変更の手順 | 「正常」の感覚。何が起きると困るか |
| 構築の手伝い | 設計書どおりに組む。動くことを確かめる | サービスの使い方。手順を再現する力 |
| 構築 | 自分で組み、確認し、引き渡す | 自分で作った構成の一式 |
| 設計 | 要件から構成を決める。境界を引く。理由を説明する | 「なぜこの構成か」を言葉にする力 |
運用から入ることは遠回りではありません。設計の判断の多くは「運用で何に困るか」から出てきます。監視をしたことがある人は、何をどう監視できる構成にすべきかを設計に入れられます。逆に、運用を知らずに設計から入ると、動かしにくい構成を作りがちです。
この道のりを、この媒体では「段」として地図にしています。段0で言葉を揃え、段1で AWS の部品を1つずつ動かし、段2以降で設計と運用に進みます。入口で何をすればよいかは、最初の1か月で何をするかにまとめてあります。
CHECK 3ここまでの確認
未経験の入口として多い役割はどれ?
答えと解説
答え: 2. 運用・監視や、構築の手伝い
手順が決まっていて、先輩の横で覚えられる仕事から入るのが一般的な道です。運用で「動いている状態」を知り、構築で「作り方」を知ってから設計へ上がります。「未経験の入口」の章を読み直してください。
資格はどこで効くか
AWS 認定は、上の道のりのどこで効くのか。結論は「入口の会話の材料として効く」です。未経験の人には実務の実績が無いので、面接で「クラウドを学んでいる」ことを示すものが要ります。資格はそれを分かりやすく示せます。
ただし、資格が採用を決めるわけではありません。決めるのは「入口の段階（運用・監視や構築の手伝い）を任せられそうか」で、資格はその会話に入りやすくする材料です。合格率や合格ラインといった数値は AWS が公表していないので、この媒体では書きません。最初の1つとして位置づけられている資格の受け方は、クラウドプラクティショナー（CLF）の受け方で扱います。
資格が効く場面は、入口だけではありません。SIer や MSP は AWS のパートナー制度に参加していることが多く、社内に認定を持つ人がいることが、会社としての要件に関わる場合があります。そのため、入ってからも取ることを求められることがあります。
自分がどの役割に向いているかの見方
5つの仕事と4つの段階を見てきました。最後に、自分がどこから入るかを見る軸を置きます。向き不向きを決めつけるものではなく、入ったあとの納得感を高めるための軸です。
| 自分の性分 | 合いやすい入口 | 理由 |
|---|---|---|
| まず全体が動いている状態を見て安心したい | 運用・監視（内製の運用、MSP） | 「正常」を先に知れる。異常に気づく力が育つ |
| まず手を動かして作りたい | 構築の手伝い（SIer、内製） | 作り方を再現しながら覚えられる |
| 決める・説明するのが好き | 設計（構築を経てから） | 要件と構成を言葉でつなぐ仕事 |
| 人と話して決めるのが好き | 売る（プリセールス、コンサル） | 技術を顧客の言葉に翻訳する仕事 |
| 分かったことを人に伝えたい | 教える（トレーナー、社内の育成） | 自分の学びの順番がそのまま材料になる |
どれから入っても、次の段階へ移ることはできます。大切なのは、いま自分がどの段階にいて、次にどの段階へ行きたいかを言葉にできることです。それができると、求人票の中身も、面接での話も、自分の学ぶ順番も決まります。
READ ALSO — 未経験向け・段1 入口
未経験がクラウドを学ぶ最初の1か月｜週ごとの順番と、やらないことを先に決める
まとめ
クラウドの仕事は、作る・守る・運用する・売る・教えるの5つに分かれます。登場人物は AWS 本体・SIer とコンサル・MSP・内製のチーム・フリーランスで、責任共有モデルを人に当てたように、土台は AWS が、その上の構築と運用は利用者側が分担します。案件は要件 → 設計 → 構築 → 運用と流れ、段階ごとに出てくる人が変わります。未経験の入口として多いのは運用・監視と構築の手伝いで、そこから構築、設計へ上がるのが一般的な道です。資格は入口の会話の材料として効きます。次は、AWS とは何かで、登場人物たちが実際に触っているものを見ます。
参照ソース
- 責任共有モデル（AWS 公式） — AWS が「クラウド自体」を、利用者が「クラウドの中」を担うという分け方の根拠（2026年9月時点）
- AWS Well-Architected Framework（AWS ドキュメント） — 設計 → 構築 → 運用で改善し続けるという段階の考え方の根拠（2026年9月時点）
- AWS パートナーネットワーク（AWS 公式） — SIer・MSP・コンサルが AWS のパートナーとして案件を担う構造と、パートナーの種類の根拠（2026年9月時点）
- AWS 認定（AWS 公式） — 認定の種類と位置づけの根拠。合格率などの数値は公表されていないため書かない（2026年9月時点）