テック羅針盤
ツール活用

AI計算資源は自前・クラウド・APIのどれを選ぶ？

AI向けGPUやアクセラレータを確保するとき、自分で機材を持つ、クラウドを借りる、APIだけ使う選択を、入手しやすさと運用責任から判断します。

公開日 更新日
  • #生成AI
  • #GPU
  • #クラウド
  • #API
  • #計算資源

AIを使うために高性能GPUを買う必要はありません。モデルを作り変えないならAPI、実行環境まで制御したいならクラウド、機密・オフライン・継続利用が購入負担を上回るなら自前機材が出発点です。必要なGPUを必要な日時に確保できるとは限らないため、機種名より先に「待てるか」「止められるか」「運用を持てるか」を決めます。

この記事は半導体の製造工程ではなく、生成AIを開発・運用する人が計算資源をどう確保するかを扱います。既存のローカルAIとクラウドAIの比較がデータ、費用、保守を広く比べるのに対し、本記事はGPU・アクセラレータの入手方法と、確保できない時の設計に範囲を絞ります。

計算資源が「一覧にあるのに使えない」理由

クラウドの製品一覧にGPUが載っていても、今すぐ自分の環境で起動できるとは限りません。少なくとも次の条件がそろう必要があります。

  • 希望する種類が、使いたい地域やゾーンで提供されている
  • アカウントやプロジェクトの割り当て上限（クォータ）に余裕がある
  • その時点で実機の空き容量がある
  • OS、ドライバー、機械学習ライブラリが組み合わせに対応する
  • 予約方式を使う場合は、対象機種と利用期間が条件に合う

クォータは、一人の利用者が使える量の上限です。たとえるなら「店に在庫があるか」と「自分の購入上限に収まるか」は別の確認です。上限が承認されても在庫を保証しない方式があり、反対に予約が成立しても、指定した地域や期間から自由に動かせない場合があります。

そのため、設計書へ「GPUを使う」とだけ書くのは不十分です。「第一候補が起動できなければ別地域へ移す」「処理を小さくして別の種類を使う」「APIへ退避する」「開始日を予約に合わせる」のどれを許すかまで決めます。

主要クラウドのAI向け計算資源を一次資料で照合

以下は、2026年8月24日に各社の公式文書を実際に開いて確認した表です。種類は全製品ではなく、AI用途を検討するときの代表例です。提供地域、クォータ、対象となる予約方式は変わり得るため、表に名前があることは利用可能性の保証ではありません。

提供元代表的な種類公式に案内されている入手方法出典URL確認日
Amazon Web Services（EC2）NVIDIA GPUを使うP5系、AWS Trainiumを使うTrn1・Trn2系など通常のEC2起動に加え、公式文書はOn-Demand、Spot、Capacity Blocks for ML、On-Demand Capacity ReservationsをAI/ML向けの購入選択肢として案内。Capacity Blocksは対象機種・地域を将来日時に確保する方式https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html
https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html		2026-08-24
Google Cloud（Compute Engine）A3（NVIDIA H100）、A2（NVIDIA A100）、G2（NVIDIA L4）、N1へ接続するGPUなどStandard、Spot、Flex-start、Reservation-boundなどのプロビジョニング方式を案内。通常の予約、将来予約、期間を定めるcalendar modeなどは対象資源と条件が異なるhttps://docs.cloud.google.com/compute/docs/gpus/about-gpus
https://docs.cloud.google.com/compute/docs/instances/provisioning-models
https://docs.cloud.google.com/compute/docs/instances/choose-reservation-type		2026-08-24
Microsoft Azure（Virtual Machines／Azure Machine Learning）NCads_A100_v4、NDasrA100_v4、NCads_H100_v5、ND-H100-v5、ND-H200-v5などAzure Machine Learningのコンピューティングインスタンス／クラスターとして対応サイズを選ぶ。Virtual Machinesでは、対象地域でCapacity Reservation対応と示されるサイズだけ予約グループへ確保できるhttps://learn.microsoft.com/en-us/azure/machine-learning/concept-compute-target?view=azureml-api-2
https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-create		2026-08-24

この表で最も大事なのは、3社とも「GPU」という一種類の商品を売っているわけではない点です。同じ事業者の中にも、すぐ起動を試す方式、中断を許容して空き資源を使う方式、開始日時を待てる方式、将来の容量を予約する方式があります。

AWSのCapacity Blocks for MLは、対象となるGPU系インスタンスなどを将来の日時に予約し、短期間の学習や調整に使う方法として案内されています。公式文書では、対象のインスタンスタイプと地域が限定されています。したがって「AWSなら予約できる」ではなく、「希望する型と地域がCapacity Blocksの対象か」を確認します。

Google Cloudは、A3、A2、G2などのアクセラレータ最適化マシンを案内しています。GPUにはプロジェクトのクォータがあり、公式文書はStandard、Spot、Flex-start、Reservation-boundなどを分けています。Flex-startは、すぐ開始する代わりに空きを待てる処理へ使う方式です。予約とFlex-startは同じものではなく、Flex-start VMには予約を適用できないという制約も公式文書にあります。

Azure Machine Learningは、A100、H100、H200などを搭載する複数のVM系列をコンピューティングインスタンスやクラスターの候補として示しています。ただし、公式文書はすべての系列が全地域で使えるわけではないと明記しています。Capacity Reservationも、地域ごとに対応能力が示されるVMサイズを先に確認してから作成します。代表名を設計へ固定する前に、実際に使うサブスクリプションと地域で候補が表示されるかを確かめる必要があります。

自前機材・クラウド・APIの違い

APIは、他社が運用するAIへ決められた接続口から入力を渡し、結果を受け取る方式です。たとえるなら、厨房を借りたり調理器具を買ったりせず、完成した料理を注文する方法です。モデル内部やGPUを直接操作できる範囲は狭い一方、GPUの型、ドライバー、故障対応を利用者が管理する必要は通常ありません。

クラウドGPUは、設備を買わずに、仮想マシンやクラスターの単位で計算環境を借りる方式です。たとえるなら、設備付きの厨房を時間単位で借り、自分の手順で調理する方法です。モデル、ライブラリ、処理の並列化を選べますが、起動、保存、停止、クォータ、認証、監視は利用者側の仕事です。

自前機材は、手元のPC、ワークステーション、社内サーバーなどを所有・管理する方式です。空き容量を他社へ予約する必要はありませんが、購入した時点で能力の上限が固定され、故障、電力、冷却、更新、バックアップを自分で持ちます。機材を買えば、使いたいモデルが必ず動くという意味ではありません。メモリ量、対応する数値形式、ドライバー、実行ソフトを事前に照合します。

判断の分岐表

自分の条件第一候補その理由見送り・再検討の条件
既存モデルへ文章・画像・音声を渡し、結果だけ受け取れればよいAPIGPUの調達と運用をサービス側へ任せられるモデルの重みや実行環境を変更する必要がある。入力を外部へ送れない
学習、追加学習、大量推論などで実行環境を制御したいが、機材を常時使わないクラウド必要な期間だけ候補資源を申請・起動できる希望日時の容量を確保できず、待機・別地域・別機種のいずれも許容できない
開始日時をずらせ、処理が止まっても再開できるクラウドのSpot／Flex-start等を検討空きや待機を前提にした方式を選べる中断で結果を失う。期限が固定。チェックポイントを保存できない
数日・数週間など計画した期間に、対象機種を確実に使いたい対応する予約方式を検討対象資源と期間が合えば、通常起動より容量の見通しを持ちやすい対象地域・機種・期間が予約条件にない。取消条件や終了時刻を受け入れられない
同じ処理を継続し、外部送信を避ける必要があり、運用担当も置ける自前機材または管理下の基盤設備とデータ経路を自分の管理範囲へ置ける購入前の実機検証ができない。更新、故障、冷却、復旧を担当できない
どのモデルや必要量が合うかまだ分からないAPIまたは小さなクラウド検証先に仕事と必要能力を確認できる検証前に高額機材を固定購入することは見送る
機密条件、必要性能、利用頻度のどれも整理できていない見送り方式を選ぶ根拠が不足している代表入力、送信可否、期限、停止許容、担当者を決めてから再判定する

入手しにくさを設計へ織り込む5手順

1. GPU名ではなく、完了条件を書く

「H100を使う」ではなく、「このモデルをこの入力で実行し、必要な出力を保存できる」と書きます。特定のアクセラレータが必須なのか、対応する別の種類でもよいのかを分けます。モデル配布元の要件に特定の機能やメモリ条件がある場合だけ、それを必須条件へ追加します。

2. 待機と中断の可否を決める

開始が遅れてよいなら、空きを待つ方式が候補になります。途中停止を許容できるなら、進行状態を一定間隔で永続ストレージへ保存する設計を検討できます。停止すると最初からやり直しになる処理は、中断され得る方式へ載せない方が安全です。

3. 地域、クォータ、容量を別々に確認する

コンソールやCLIで候補の種類が見えること、クォータが承認されていること、実際に起動できることは別の結果です。本番日より前に、同じアカウント、同じ地域、同じ起動方法で小さい構成を作成し、停止と再開まで確認します。期待する結果は、対象のリソースが作成済みとして表示され、処理終了後に停止または削除済みと確認できることです。

4. 第一候補がない時の順番を決める

代替順を「別ゾーン→別地域→別アクセラレータ→API→日程変更」のように事前に固定します。ただし、地域変更でデータ保管や契約条件が変わる場合は自動で移しません。別アクセラレータでは、モデルとライブラリの対応を改めて確認します。

5. 終了処理まで試す

クラウドでは、処理が終わっても仮想マシンやディスクが残れば管理対象が残ります。APIでは利用上限と失敗時の再送、自己管理では温度、保存先、復元方法を確認します。「出力が一度出た」ではなく、結果を保存し、不要な資源を止め、再実行方法を残したところを完了にします。

失敗と戻し方

何が起きるか影響事前の対策起きた後の戻し方
希望するGPUを起動できない作業開始が遅れる地域、クォータ、実容量を事前に小さく確認。代替順を決める別候補へ切り替えるか、予約可能日へ日程を移す。条件外の地域へ無断でデータを移さない
中断可能な方式で処理が止まる途中結果を失う状態と成果物を永続ストレージへ保存する最後に保存した地点から再開。再開できない設計なら方式を変更する
高性能機材を買ったがモデルが動かない購入負担と保守だけが残る配布元要件、メモリ、実行環境を照合し、可能なら購入前に同等環境で試す小さいモデルや対応形式へ変更する。推測で追加購入しない
APIの制約が後から分かる必要な制御やデータ条件を満たせない送信可能な情報、モデル機能、出力形式、上限を先に確認する入力を分離・匿名化するか、条件を満たす管理下環境へ戻す
一つの事業者・地域へ固定しすぎる障害や在庫不足で全工程が止まる入出力形式と保存先を持ち運べる形にする検証済みの代替経路へ切り替え、未検証環境を本番扱いしない

結論：まずAPI、制御が必要ならクラウド、継続条件が合えば自前

計算資源の選択は、GPUの性能順位ではなく、責任の置き場所を決める作業です。モデルを利用するだけならAPIから始め、実行環境を変える必要が出たらクラウドを検討します。自前機材は、継続利用、外部送信不可、オフライン、運用担当といった条件がそろった時に初めて比較対象へ入れます。

クラウドを選ぶ場合も、製品一覧を在庫表として読まないでください。地域、クォータ、容量、予約条件を分けて確認し、第一候補が使えない場合の順序まで設計すれば、「GPUが取れなかったので全部止まる」という失敗を小さくできます。

一次資料

確認日: 2026-08-24

見たソース数: 8