クラウドとは?自前のサーバーを持たずに借りる仕組みを簡単に——オンプレミスとの違い、SaaS/PaaS/IaaS、費用と責任【2026年版】

「提案書に『IaaS上に構築します』と書いてあるのですが、そもそもクラウドとは何なのでしょうか」——システムの置き場所を決める立場の方から、こうした相談をよく受けます。会議では何度も出てきた言葉で、いまさら聞き返しにくい。検索してみると「クラウドコンピューティングの略称で、ネットワークを通じてリソースを提供するサービスモデル」と出てきて、用語が用語で説明されている。3行で閉じてしまった経験をお持ちの方は多いはずです。

結論から言うと、クラウドとは、自前のサーバーを持たずに、必要な分だけ借りて使う仕組みです。自社の事務所やデータセンターに機械を買って置くのが従来のやり方で、これをオンプレミスと呼びます。クラウドはその機械を買わず、他社が用意した設備を、使った分だけ払って借ります。それだけです。借りる範囲がどこまでかでSaaS・PaaS・IaaSに分かれ、誰と共有するかでパブリック・プライベート・ハイブリッドに分かれますが、根っこはこの一点に尽きます。

ただ、システムをどこで動かすか決める立場の方にとって本当に効くのは、区分の暗記ではないと考えています。効くのは2つです。ひとつは費用の出方が「最初にまとめて」から「使った分だけ毎月」に変わること。もうひとつは、借りても手放せない責任が残ることです。総務省の「クラウドの設定ミス対策ガイドブック」(2024年4月)は、開発会社が設定作業を行った場合でも最終的な責任は利用者が負うと明記しています。任せれば安心、という読み方ができないのが実情です。

本記事では、クラウドの語義と5つの条件、オンプレミスとの違い、SaaS/PaaS/IaaSとパブリック/プライベート/ハイブリッドという2つの軸、費用構造の変化、向くケースと向かないケースおよび3つの誤解、そして責任共有モデルと外部チームで作る・運用するときの体制の順に解説します。サーバー障害が起きたときの対応手順、オフショア開発のセキュリティ対策の組み方、システム開発の費用相場、デプロイの仕組みは、本記事では扱わず、それぞれ既存の記事に譲ります。特定のクラウドの操作手順や機能比較も扱いません。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社にはAWS認定11冠の体制がありますが、相談のなかで意外に多いのは技術の質問ではなく、「自社のシステムが動いているクラウドのアカウントは、誰の名義なのか分からない」という状態です。クラウドは技術の話に見えて、その半分は取り決めの話です。この記事を読み終えるころには、開発会社に何を聞き、何を書面に残すべきかが決められるはずです。

クラウドとは——自前のサーバーを持たずに、必要な分だけ借りて使う仕組み

クラウドとは、自前のサーバーを持たずに、必要な分だけ借りて使う仕組みです。これまでは、システムを動かすためのコンピュータを自社で買い、事務所の一室やデータセンターに置いて、自社で面倒を見ていました。この従来のやり方をオンプレミスと呼びます。クラウドは、その機械を買いません。他社が用意して運用している設備を、インターネット越しに、使った分だけ払って借ります。所有から利用へ、と言い換えてもよいでしょう。

簡単に言うと——自家発電するか、電力会社から買うか

もっと簡単に言うなら、電気の話に置き換えるのがいちばん早いと考えています。

工場を建てるとき、敷地内に発電機を置いて自分で発電する方法があります。設備を買う費用がかかり、燃料を調達し、故障したら自分で直します。その代わり、電気の作り方を自分で決められます。これがオンプレミスです。

一方、電力会社と契約すれば、発電機は買いません。コンセントに挿して、使った分だけ月末に請求されます。発電所がどこにあるかは知らなくても困りませんし、設備が壊れれば電力会社が直します。これがクラウドです。

この例えが効くのは、費用の出方と責任の所在が同時に説明できるからです。自家発電なら設備投資が先に出て、止まったら自分の責任。電力会社から買うなら初期費用は小さく、供給が止まれば電力会社の責任です。ただし、工場の中の配線やブレーカーの管理は、電気を買っていても自社の責任として残ります。この「残るもの」が何かという話は、後半で詳しく扱います。

なお、クラウドは「ソフトウェアの提供のされ方」のひとつでもあります。ソフトウェアという言葉自体の整理は『ソフトウェアとは』の記事に譲ります。

NISTの定義と、クラウドを名乗る5つの条件

もう少し厳密な定義も押さえておきましょう。世界的に参照されているのは、米国国立標準技術研究所(NIST)が2011年9月に公表した「The NIST Definition of Cloud Computing」(SP 800-145)です。ここでは、クラウドコンピューティングを「構成可能なコンピューティング資源の共用プールに対して、必要に応じてどこからでもネットワーク経由でアクセスでき、最小限の管理の手間で迅速に提供・解放できるモデル」と定義しています。

そしてこの文書は、クラウドを名乗るために満たすべき5つの必須特性を挙げています。

この5つのうち、発注する側にとって効き方が大きいのは3番目と4番目です。3番目は単価が下がる理由、4番目は増減が効く理由に、そのまま対応しています。逆に言えば、この5つを満たさないものは、名前にクラウドと付いていても中身はただの遠隔にあるサーバーです。要注意です。

なぜ「雲」と呼ぶのか、そして日本企業の8割がすでに使っている

クラウド(cloud)は英語で雲です。この呼び名は、ネットワークの構成図でインターネットを雲の絵で表す慣習に由来すると説明されることが多いものです。図の中で、自社の設備は四角で描かれ、その外側にある「詳しく描かなくてよい領域」は雲で描かれてきました。その雲の中に処理を置く、という言い方が定着したわけです。

普及の度合いも押さえておきましょう。総務省の令和7年版情報通信白書によれば、企業のクラウドサービス利用率は2024年時点で80.6%です。すでに8割を超えており、企業活動に不可欠な存在として浸透した、と白書は整理しています。つまり、いま問われているのは「クラウドを使うかどうか」ではなく、「どこまで、どの形で使うか」という段階に移っています。

では、自前で持つやり方と比べて、具体的に何がどう違うのでしょうか。次に、オンプレミスとの違いを8つの観点で並べます。

クラウドとオンプレミスの違い——「買って所有する」か「借りて使う」か

オンプレミス(on-premises)は「自社の敷地内に」という意味の英語で、システムを動かす機器を自社で購入し、自社または契約したデータセンターに設置して運用する形態を指します。クラウドとの違いは、突き詰めれば所有か利用かの一点です。ただし、その一点から派生する差は、稟議書に書くべき項目のほぼ全部に及びます。順に並べていきます。

8つの観点で並べる比較表

発注する立場から見て意味のある観点だけを選ぶと、次の8つになります。

この表をそのまま社内資料に転用しても構いません。ただし1点だけ補っておくと、「初期費用がほぼ不要」は「総額が安い」という意味ではありません。ここは後半の費用の章で詳しく扱います。

違いが最も効くのは「増やすとき」と「減らすとき」

8つの観点のうち、実務で最も差が出るのは4番目と5番目です。

オンプレミスでは、サーバーを1台増やすのに、選定・見積もり・稟議・発注・納品・設置・設定という工程が必要です。早くて数週間、予算年度をまたげば数か月かかります。そのため、導入時には「3年後の利用者数」を見込んで、余裕を持った構成を買うのが常道でした。結果として、稼働率が低いまま持ち続ける設備が生まれます。

クラウドでは、この工程がほぼ消えます。必要になってから増やせるので、最初から余裕を買っておく必要がありません。そして重要なのは、逆向きにも動くことです。キャンペーン期間だけ増やして、終わったら戻す。テスト環境を夜間と休日は止める。こうした運用は、買った設備では原理的にできません。

新規事業のように利用者数が読めない案件では、この差が決定的になります。3年後の規模を当てられないなら、当てなくてよい形を選ぶのが合理的です。

オンプレミスが時代遅れになったわけではない——いまも選ばれる4つの条件

一方で、オンプレミスが不合理な選択になったわけではありません。次の4条件のどれかに当てはまる場合は、いまも自社で持つほうが合うことがあります。

1. 常時フル稼働で、負荷の波がほとんどない。 24時間同じ量の処理が続くなら、従量課金の利点が働きません。買い切ったほうが総額で下回る場合があります
2. 超低遅延が要件になっている。 工場の制御や、ミリ秒単位の応答が求められる処理では、ネットワークを経由する分の遅れが許容できないことがあります
3. 規制や契約で設置場所が指定されている。 業界のガイドラインや取引先との契約で、データの物理的な所在や管理方法が縛られている場合です
4. 特殊なハードウェアが必要。 専用の計測機器や、特定のライセンス形態のソフトウェアなど、クラウド上に持ち込めない構成があります

どちらが優れているという話ではありません。判断の順番としては、まず上の4条件に当てはまるかを確かめ、当てはまらなければクラウドを既定の選択肢に置く、という進め方が実務的です。なお、この判断は「社内でどこまで持つか」という内製化の議論と近い場所にあります。内製と外注の切り分けそのものは『システム内製化』の記事に譲ります。

クラウドの種類は2つの軸で整理する——「どこまで借りるか」と「誰と共有するか」

クラウドの分類は、SaaS・PaaS・IaaSという3区分と、パブリック・プライベート・ハイブリッドという分け方の2つが同時に語られるため、混ざりやすいところです。しかし、この2つは別の軸を測っています。前者は「どこまで借りるか」、後者は「誰と共有するか」です。軸が違うと分かれば、たとえば「パブリッククラウドのIaaS」のような組み合わせも自然に読めるようになります。

SaaS・PaaS・IaaS——9つの層のどこに線が引かれるか

総務省が2024年4月に公表した「クラウドの設定ミス対策ガイドブック」は、3区分を次のように説明しています。

そして同じガイドブックは、システムを9つの層に分けたうえで、区分ごとに利用者と提供者の責任範囲の線がどこに引かれるかを図示しています。この9層を表にすると、3区分の関係が一目で分かります。

出典: 総務省「クラウドの設定ミス対策ガイドブック」(2024年4月)の責任範囲図を表に整理

いちばん上の2層、データの設定とユーザ設定が、どの区分でも利用者側にあることに注目してください。これが後半で扱う責任共有モデルの出発点になります。

具体的なサービス名で言えば、Web会議ツールや会計ソフトはSaaS、アプリの実行環境やマネージドなデータベースはPaaS、仮想サーバーやストレージはIaaSです。当社が手がけた案件でも、Webサイトはヘッドレスなコンテンツ管理サービス(SaaSにあたる)を使い、決済はStripeのAPIを組み込み、アプリ本体はクラウド上の実行環境に載せる、といった組み合わせになります。ひとつのシステムが3区分にまたがるのは、珍しいことではありません。

発注者にとっての意味——見積もりの範囲と運用の手離れがここで決まる

3区分は、技術の分類であると同時に、見積書の範囲を決める線でもあります。下に行くほど自由度は上がりますが、面倒を見る対象が増えます。

• SaaSを選ぶと、開発費はほぼゼロで、月額の利用料だけになります。その代わり、業務のほうをサービスの形に合わせる必要があります
• PaaSを選ぶと、アプリケーションの開発費はかかりますが、OSの更新やパッチ当ての作業は提供者側にあります。保守費用が軽くなりやすい区分です
• IaaSを選ぶと、構成の自由度は最大になりますが、OSの更新、ミドルウェアの設定、セキュリティの設定まで自社(または委託先)の作業になります。運用の人手がここで効いてきます

見積書に「インフラ構築費」「運用保守費」という行があるとき、その金額が妥当かどうかは、どの区分を前提にしているかで変わります。IaaS前提の見積もりとPaaS前提の見積もりを金額だけで並べても、比べたことになりません。相見積もりを取るときは、まずこの前提を揃えてください。

なお、開発した成果物を実際に環境へ載せて動かす作業そのもの(デプロイ)については『デプロイとは』の記事に、SaaSを事業として作る側の論点については『SaaS開発の外注』の記事に、それぞれ譲ります。

パブリック・プライベート・ハイブリッド・コミュニティ——NISTの4類型

もうひとつの軸が、配置モデルです。NIST SP 800-145は4つを定義しています。

実務でよく検討に上がるのは、パブリックとハイブリッドです。プライベートクラウドは「クラウドの便利さを、専有の設備で」という発想ですが、機器を持つ以上、初期費用と調達期間の問題はオンプレミスに近づきます。コミュニティクラウドは日本ではあまり耳にしませんが、業界共同のシステムを考えるときには選択肢になります。

ここまでで、自社の案件が「どの区分を、どの類型で使うか」の座標は決められるはずです。次は、その選択が費用にどう効くかを見ていきます。

クラウドの費用構造——初期投資が消え、固定費が変動費に変わる

クラウドに移すと安くなる、という説明をよく見かけます。しかし正確には、安くなるのではなく、費用の出方が変わります。まとまった額が最初に出て数年で償却する形から、使った分を毎月払う形に変わる。この違いが自社にとって得なのか損なのかは、事業の性質によって答えが逆になります。順に分解します。

オンプレミスの費用の出方——最初にまとめて出て、5年で償却する

自社でサーバーを持つ場合、費用は大きく分けて次のように出ます。

• 導入時にまとめて出るもの——サーバー機器、ネットワーク機器、ストレージ、OSやミドルウェアのライセンス、設計・構築の作業費
• 毎年ほぼ一定で出るもの——ハードウェア保守料、ライセンスの更新料、設置場所の費用、電気代、運用の人件費
• 数年後にまた出るもの——保守期限切れに伴う機器の更新費用

会計上、機器は資産として計上され、耐用年数にわたって減価償却されます。実務では5年程度で計画を組むことが多いでしょう。ここで起きるのは、買った瞬間に5年分の判断が固定されるということです。利用者が想定の半分でも、倍でも、買った機器は変わりません。

クラウドの費用の出方——秒・容量・回数で数えて、翌月に請求される

クラウドは、使った量を測って課金します。AWSの公式ドキュメントによれば、EC2のオンデマンド料金は「インスタンスが起動してから停止または終了するまでの、インスタンス時間あたり」で計算され、Linuxでは1時間未満の端数が秒単位で課金されます。長期契約は不要で、初期費用もありません。

課金の単位はサービスによって異なり、おおむね次の3種類です。

AWSはこの構造を「初期の固定的な設備投資を、事業に応じて変動する低いコストに置き換えられること」がクラウドの主要な利点だと説明しています。つまり、設備投資(固定費)を運用費(変動費)に振り替えるのが、費用面での本質です。

変動費になると何が変わるか——決め直せる自由と、誰も見直さない怖さ

変動費になると、意思決定の性質が変わります。

良い面から言えば、判断を先送りできます。利用者が読めない立ち上げ期に、3年後の規模を当てる必要がなくなる。事業がうまくいかなければ止められる。撤退のコストが下がることは、挑戦のしやすさに直結します。私は2018年からホーチミンで約100社の開発体制を支援してきましたが、新規事業の相談で「最初から全部を作り込まないでほしい」と伝えるとき、この止められる性質が前提になっています。

悪い面もあります。毎月見直せるということは、誰も見直さないと増え続けるということです。検証用に立てたまま消し忘れた環境、必要のない世代まで保管し続けているバックアップ、退職者が作ったアカウント。オンプレミスなら物理的な機器の増設という壁がありましたが、クラウドには壁がありません。月次で費用を分解して見る担当を決めていない組織では、半年で当初見積もりの1.5倍になることがあります。

見積もりで抜けやすい3つの費用——通信料、バックアップ、為替

見積書の「インフラ費用 月額○○円(従量課金のため変動します)」という行を受け取ったら、次の3つが含まれているかを確認してください。

1. 外向きの通信料。 クラウドから利用者側へ出ていくデータには通信料がかかるのが一般的です。画像や動画を多く配信するサービスでは、ここが想定外に膨らみます
2. バックアップと世代保管。 「バックアップを取ります」とだけ書かれている場合、何世代を何日保持するのかで容量が数倍変わります
3. 為替。 主要なクラウドはドル建てで課金されるため、円換算額は為替で動きます。2026年時点では円安基調が続いており、1USD=150円換算を目安に置いても、月次で上下します

なお、開発費そのものの相場観は本記事では扱いません。『システム開発の費用相場』の記事に譲ります。参考までに、当社のラボ型開発の最小構成は日本人PMフロント+2〜3人月で月額約80万円からですが、この金額にクラウドの利用料は含まれていません。インフラの実費は別勘定になるのが一般的だと考えてください。

いま手元にある見積書に、この3つは書かれているでしょうか。

クラウドが向くケース・向かないケースと、よくある3つの誤解

メリットとデメリットを並べた記事は多いのですが、読んだ側は自社がどちらに当てはまるのか分からないまま終わりがちです。ここでは条件の形で書きます。自社の案件を当てはめて読み進めてください。そのうえで、判断を誤らせやすい3つの誤解に触れます。

向くケース4つ——立ち上げ期、波のある負荷、拠点分散、災害対策

介護記録SaaS「CareViewer」の開発では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、週次で機能の優先順位を判断しながら継続的に開発しています。この進め方が成り立つのは、作った機能をすぐ動く場所に載せて確かめられるからです。設備の調達に数週間かかる前提では、週次で優先順位を決め直す意味が薄れます。

向かないケース4つ——常時フル稼働、超低遅延、規制、特殊なハードウェア

この4つに当てはまる部分だけをオンプレミスに残し、残りをクラウドに置く、というのがハイブリッドの実務的な使い方です。全部か無しかで考える必要はありません。

誤解1: クラウドにすれば安くなる——高くなる3つのパターン

前章で見たとおり、クラウドが変えるのは費用の出方であって、必ずしも総額ではありません。高くなるのは、おおむね次の3パターンです。

1. オンプレミスの構成をそのまま移す。 常時稼働の同じ台数を、そのままクラウド上に並べると、従量課金の利点が一切働きません。「リフト&シフト」で移行した直後に費用が上がるのは、珍しい話ではありません
2. 止めるべきものを止めていない。 検証環境、開発環境、一時的に立てた分析用の環境。使っていない時間帯に課金され続けます
3. データを消さない。 ストレージは静かに増えます。保持期間を決めずに運用すると、数年後の請求書にそれが表れます

安くするためには、クラウドに合わせて構成を作り直す必要があります。移すだけでは安くなりません。

誤解2: クラウドは止まらない——SLAの稼働率が意味すること

クラウドは止まります。提供者自身がそう書いています。

AWSのComputeサービスに関するサービスレベルアグリーメント(SLA)では、同一リージョン内の複数のアベイラビリティーゾーンにまたがって配置したEC2インスタンスについて月間稼働率99.99%以上、個別のEC2インスタンスについてはインスタンスレベルの月間稼働率99.5%以上が約束されています。下回った場合は、利用料に対して10%から100%のサービスクレジットが付与されます。

ここで大事なのは、99.5%という数字が何を許容しているかです。30日を720時間として計算すると、0.5%は約3.6時間にあたります。つまり、1台のサーバーを1台だけ置く構成では、月に3時間半止まってもSLAの範囲内です。複数のゾーンにまたがって置いて初めて99.99%(同じ計算で月あたり約4分)になります。

止まらない仕組みを買ったのではなく、止まったときに切り替わる構成を自分で組む材料を借りた、という理解が正確です。そして、SLAの補償はサービスクレジット(利用料の減額)であって、事業の損害の賠償ではありません。ここは契約前に必ず確認してください。なお、実際に障害が起きたときの一次対応の手順は本記事では扱いません。『サーバー障害の原因と対応』の記事に譲ります。

誤解3: データがどこにあるか分からない——リージョンは利用者が選ぶ

「クラウドに置くと、データがどこの国にあるか分からなくなる」という不安をよく聞きます。これは事実と違います。

AWSのデータプライバシーに関するよくある質問では、顧客が自らのコンテンツを所有すること、コンテンツを保存するリージョン(地理的な区域)を顧客が選ぶこと、そして顧客の同意なく選択されたリージョンの外へコンテンツを移動・複製しないことが明記されています(法令や政府機関の拘束力ある命令に従う場合、および顧客が開始したサービスの提供上必要な場合を除く)。AWSは2026年9月時点で39のリージョンと124のアベイラビリティーゾーンを持っており、東京と大阪にもリージョンがあります。

つまり、どこに置くかは利用者が決める設定項目です。分からなくなるのではなく、決めていないだけ、という場合がほとんどです。契約前に「どのリージョンを使うのか」を書面で確認すれば済みます。

3つの誤解に共通するのは、クラウドを「任せれば全部やってくれるもの」と捉えている点です。実際には、決めるべきことが手元に残ります。次章で、その残るものを整理します。

責任共有モデル——借りても手放せない責任と、外部チームで作る・運用するときの体制

ここまでの内容を、発注する側の文脈に着地させます。クラウドに載せると、設備の面倒を見る仕事の多くは提供者に移ります。しかし、全部が移るわけではありません。移らない部分を書面で確定させないまま運用に入ると、事故が起きた日に誰も決められなくなります。この節で扱うのは、その移らない部分です。

責任共有モデルとは——提供者と利用者で、層ごとに責任を分け合う

総務省の「クラウドの設定ミス対策ガイドブック」(2024年4月)は、クラウドのセキュリティについて、提供者と利用者が責任を分担するという考え方を「責任共有モデル」と呼び、現在多くのクラウドサービス事業者に採用されていると説明しています。そして、SaaS・PaaS・IaaSといった種類によって責任分担の範囲が異なると明記しています。

主要な提供元も、同じ枠組みを公開しています。

3社に共通するのは、データ、ID(アカウント)、設定の3つは、どの形態でも利用者に残るという点です。Microsoftの資料は、デプロイの種類にかかわらず常に保持する責任として、データ、エンドポイント、アカウント、アクセス管理の4つを挙げています。

前章の9層の表を思い出してください。いちばん上の「データの設定」と「ユーザ設定」が、SaaSでもIaaSでも利用者側にありました。責任共有モデルは、あの表の言い換えです。

開発会社が設定しても、最終的な責任は利用者に残る

ここが、発注する立場の方にとって最も重要な一点です。

総務省のガイドブックは、日本ではクラウドを使ったシステム開発をSI事業者(システム開発事業者)に委託することも多いとしたうえで、次のように書いています。SI事業者が入ると責任分担が複雑になるので契約等でよく確認する必要があること、SI事業者もミスをすること、そしてSI事業者が行った設定であっても、最終的な責任は利用者が負うことです。

同じガイドブックは、利用規約や約款に書かれた免責条項・責任制限条項にも注意を促しています。提供者が契約どおりにサービスを提供できなかった場合に責任を免除したり、損害賠償の範囲を限定したりする条項は、信義則に反するような場合を除いて有効です。つまり、止まったときの損害は、原則として利用者側に残ります。

発注前に書面で確定させるべき項目は、次の5つです。

この5つが議事録にも契約書にも書かれていない状態で本番を迎えると、事故が起きた夜に決められなくなります。失敗のもとです。

当社の体制——AWS認定11冠と、運用まで持つ場合の分担

クラウド上のシステムを外部のチームで作り、運用する場合の体制について、当社の例を書きます。

当社はAWS認定11冠の体制を持ち、2,000名以上のIT人財データベースから直接アサインしています。品質は3つの仕組みで担保しています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。設定作業も同じ流れに載せ、1人が設定して1人が確認する形にしています。総務省のガイドブックが言うとおり、プロでもミスはするからです。

体制は1名から組め、最短2週間で開始できます。増員は約1週間、縮小や交代(リプレイスメント)は1か月単位です。契約と支払いは日本国内法人・日本法準拠で、海外送金は発生しません。

そのうえで、当社が担当する案件でも、クラウドアカウントの名義とルート権限はお客様側に残すことを標準にしています。設定作業を担うことと、責任を引き受けることは別だからです。前述のとおり、最終的な責任は利用者に残る以上、権限だけを外に出す構成は発注者にとって不利になります。介護記録SaaS「CareViewer」でも、この線の引き方は変えていません。

なお、海外のチームで開発する場合のセキュリティ対策の組み方そのものは、本記事では扱いません。契約・人・環境・運用・法規制の5層で対策を組む話は『オフショア開発のセキュリティ対策』の記事に譲ります。

向く案件・向かない案件

正直に線を引いておきます。

向かない案件は、本番データを海外に出せない案件、設定作業まで含めて社内の情報システム部門で完結させる方針の案件、そして開発が3か月未満で終わり保守も発生しない案件です。最後のものは、単発の請負で発注したほうが管理の手間が少なく済みます。

向く案件は、作った後も継続して直し続ける前提のシステム、機能追加の優先順位が月単位で変わる案件、そして社内に運用担当を置けないが誰かに任せきりにもしたくない案件です。当社のような外部チームは、設定を担い、レビューを二重にし、記録を残す役を引き受けます。判断と権限はお客様側に残します。この分担なら、任せきりにならずに手は空きます。

【FAQ】クラウドに関するよくある質問

最後に、相談の場でよく出る質問を5つ取り上げます。本文で触れきれなかった周辺の疑問を、短く答えます。

Q1. クラウドを一言で説明するとどうなりますか

自前のサーバーを持たずに、必要な分だけ借りて使う仕組みです。社内で説明するときは「自家発電するか、電力会社から電気を買うか」と置き換えると伝わりやすいと考えています。発電機を買わなくても電気は使えますが、工場の中の配線は自社の責任として残ります。この「残るもの」がデータとアカウントと設定にあたります。

Q2. クラウドとクラウドストレージは同じものですか

違います。クラウドストレージは、クラウドという仕組みの一用途です。ファイルを預けて共有する個人向け・法人向けのサービスを指し、区分で言えばSaaSにあたります。業務システムをクラウドに載せるという話は、その下の層(PaaSやIaaS)を借りる話であることが多く、費用構造も責任範囲も別物になります。提案書に「クラウド化」と書かれていたら、どの層の話なのかを必ず確認してください。

Q3. 社内のシステムは全部クラウドに移すべきですか

いいえ。常時フル稼働で負荷の波がない、ミリ秒単位の応答が要る、規制や契約で設置場所が縛られている、専用のハードウェアが必要——このどれかに当てはまる部分は、自社に残したほうが合理的な場合があります。当てはまる部分だけをオンプレミスに残し、残りをクラウドに置く構成(ハイブリッド)が現実的な落としどころになることが多いものです。全部か無しかで考える必要はありません。

Q4. クラウドにすると社内の情報システム担当は不要になりますか

なりません。役割が変わります。機器の調達と物理的な保守はなくなりますが、アカウントと権限の管理、設定内容のレビュー、月次の費用の点検、契約と責任分界点の管理といった仕事は残ります。むしろ、機器の面倒を見る時間が減った分を、こちらに回す必要があります。総務省のガイドブックも、クラウドの設定に責任のある部署は情報システム部門に限らないとして、事業部門やスタッフ部門も対象に含めています。

Q5. 移行の相談は何から始めればよいですか

現行システムの棚卸しと、前章に挙げた5つの確認項目(アカウント名義、ルート権限、設定作業の範囲、設定内容のレビュー、契約終了時の扱い)の現状確認からです。技術的な移行方式を検討するのは、その後で構いません。外部のチームを使う場合は、当社であれば1名から、最短2週間で体制を組めます。AWS認定11冠の体制で設定を担い、日本人PMがレビューに入る形が標準構成。

まとめ: クラウドは自前で持たずに借りる仕組み——変わるのは費用の出方、変わらないのはデータとIDと設定の責任

クラウドとは、自前のサーバーを持たずに、必要な分だけ借りて使う仕組みです。機械を買って自社に置くのがオンプレミス、買わずに借りるのがクラウド。違いは所有か利用かの一点で、そこから調達期間、初期費用、増減のしやすさ、責任範囲の差が派生します。NIST SP 800-145は、オンデマンドセルフサービス、幅広いネットワークアクセス、リソースの共用、迅速な拡張性、測定可能なサービスの5つを必須特性として挙げています。総務省の令和7年版情報通信白書によれば、企業の利用率は2024年で80.6%。問われているのは使うかどうかではなく、どこまで使うかです。

種類は2つの軸で整理できます。どこまで借りるかがSaaS・PaaS・IaaS、誰と共有するかがパブリック・プライベート・コミュニティ・ハイブリッド。総務省の「クラウドの設定ミス対策ガイドブック」は、システムを9層に分けて責任の線がどこに引かれるかを示していますが、いちばん上のデータの設定とユーザ設定は、どの区分でも利用者側にあります。費用は、まとめて出て5年で償却する形から、使った量を毎月払う形に変わります。安くなるとは限りません。構成をそのまま移す、止めるべきものを止めない、データを消さない——この3つで高くなります。止まらないわけでもありません。AWSのSLAは個別インスタンスで月間稼働率99.5%、30日換算で約3.6時間の停止を許容する水準です。データの置き場所は利用者が選ぶ設定項目で、分からなくなるのではなく、決めていないだけの場合がほとんどです。

そして、借りても手放せない責任があります。データ、アカウント、設定の3つは、SaaSでもIaaSでも利用者に残ります。総務省のガイドブックは、SI事業者が行った設定であっても最終的な責任は利用者が負うと明記しています。発注前に書面で確定させるべきは5つ。アカウントの名義、ルート権限の保持者、設定作業の範囲、設定内容のレビュー体制、契約終了時のデータの引き渡し方法です。海外のチームで開発する場合のセキュリティ対策の組み方はオフショア開発のセキュリティ対策に、専属チームを月額で持つラボ型という契約形態そのものはラボ型開発とはにまとめてあります。当社はホーチミンを拠点に、AWS認定11冠の体制で、日本人PMをフロントに置いたラボ型の開発チームを提供しています。1名から、最短2週間で開始でき、最小構成は日本人PMフロント+2〜3人月で月額約80万円から。クラウドアカウントの名義とルート権限はお客様側に残す形を標準にしています。現在の体制と要件をお聞かせいただければ、どの区分でどう組むかを含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。