AI・クラウド / 第3章・全8章

計算資源、モデル、業務サービスのお金の流れ

売上と費用を層ごとの取引に分ける。従量料金と設備の固定負担を区別する。

約18分 / 内容確認日:2026-10-31

一つの回答に複数の取引が重なる

利用者がAIサービスに月額料金を支払う場合でも、その提供者が裏で計算基盤やモデルの利用料を支払っている場合があります。モデルを提供する企業も、計算機、記憶装置、施設、通信、人材へ支出します。売上高を業界全体で単純に足すと、企業間の取引が重なります。産業規模の数字を読む前に、どの層の売上を数えた指標かを確かめる必要があります。

モデルのAPIは、画面を持たない機能の呼び出し口として考えられます。アプリケーションの提供者は、そのAPIを自社の業務画面やデータ処理へ組み込みます。利用者の課題を整理して使いやすい形にする仕事と、モデル自体を学習する仕事は異なります。同じAI企業という分類でも、自社で持つ資産、外部へ支払う費用、顧客が選ぶ理由を分けると、利益の生まれる場所を考えやすくなります。

直接の顧客と最終的な利用者も一致するとは限りません。計算基盤の顧客がモデル提供者で、その先に業務サービス企業、さらに先に一般企業の従業員がいる構造もあります。一つの契約が終了した場合にどの利用者へ影響が及ぶか、料金変更を誰が吸収するかは、この連鎖に左右されます。企業研究では、提供機能の一覧に加えて、支払う相手と受け取る相手を矢印で描いてみます。

参照資料:The NIST Definition of Cloud Computing責任共有モデル

従量課金と固定的な設備負担

従量課金は、利用者が使った量に応じて支払う方式です。計算時間、保存量、通信量、問い合わせ量など、何を計測するかはサービスにより異なります。利用者から見れば小さく試しやすい一方、利用が急に増えると費用の見通しを立て直す必要があります。提供者にとっては、設備や開発の負担を先に支払い、将来の利用によって回収する場合があります。

単価の低下と利益率の上昇も同じではありません。計算効率が改善して一件あたりの費用が下がっても、顧客への値下げ、競争、利用の増加、開発費の増加が同時に起こり得ます。反対に単価が高いサービスでも、利用者が少なく設備を十分に使えなければ採算が難しい場合があります。料金表だけを比べず、稼働、利用頻度、品質要求、運用の手間を合わせて確認しましょう。

架空の問い合わせサービスで、定額料金と従量料金を比べてみます。平常時の問い合わせ量、繁忙期の上限、長い入力の割合、人の確認が必要な割合を別に置きます。一回の質問だけなら安い仕組みでも、再試行や確認作業まで含めると総費用が変わります。これは実際の価格予測ではなく、どの費用を数えるかを学ぶ計算枠組みです。契約で制限される処理量や、上限時の扱いまで調べると比較が具体的になります。

参照資料:The NIST Definition of Cloud ComputingAI Risk Management Framework

契約と責任を先に設計する

AWSの責任共有モデルは、施設や基盤を提供する側と、その上で設定やデータを扱う利用者との分担を示します。ただし、その分担は使うサービスで異なります。仮想計算機では利用者が管理する部分が広く、抽象度の高いサービスでは提供者が引き受ける部分が増えます。企業研究で外部委託という言葉を見たら、業務を丸ごと渡したのか、特定の作業だけを渡したのかを確認します。

契約上の可用性、つまり使い続けられることの約束も、業務の継続そのものと一致しません。ある基盤が正常でも、アプリケーションの設定ミスや利用権限の問題で業務が止まる場合があります。バックアップも、データが保存されているだけでは十分ではありません。必要な時間内に戻せるか、誰が復旧操作を判断するか、復旧後の内容をどう確かめるかまで決めて初めて業務の計画になります。

比較表では、機能、費用、責任、出口という四列を使います。出口とは契約終了時や別サービスへ移る際の扱いです。データをどの形式で取り出せるか、別の実行基盤で動かせるか、移行中に二重運用が必要かを調べます。目の前の機能が同じでも、将来の選択を変える条件が異なる場合があります。この観点を持てば、単価の小さな差だけで企業の優劣を決めることを避けられます。

比較軸提供者へ確認すること利用企業で設計すること
機能処理できる対象と制限業務手順との適合
費用計測単位と上限再試行や人の確認を含む総費用
責任基盤の運用範囲権限、データ、復旧判断
出口取出形式と契約終了時の扱い移行手順と二重運用

参照資料:責任共有モデルSecurity in Amazon EC2

料金表から損益の問いを作る

架空のサービスに、月額基本料と利用量に応じた追加料金があるとします。利用者側では、通常月、繁忙月、導入直後の試行期間を分けて見積もります。入力が長い、失敗して再試行する、複数の処理を連続して呼ぶといった条件も利用量を変えます。問い合わせの件数が同じでも、一件の処理の中身が違えば支払額が変わるため、表面上の利用者数から費用を直接予測することはできません。

提供者側では、顧客から受け取る料金と、外部へ支払う計算費用を並べます。さらに開発、支援、監視、契約管理などの費用があります。利用が増えるほど利益が増えると考える前に、一件追加する際の支出と、一定の規模まで変わらない支出を分けます。販売価格が決まっていても、入力の偏りや高負荷の利用者が採算に影響する場合があります。契約の利用制限も、このような費用構造と関係することがあります。

この表に実在企業の未公開の利益率を推定して書く必要はありません。公開されている料金の計測単位と、サービスが引き受ける作業を使い、追加でどんな情報が必要かを整理します。企業の事業を理解する練習では、数字を一つ置くことより、数字が変わる理由と範囲を説明することが重要です。

また、料金が定額であることと、無制限に処理できることは同じではありません。契約で定められた機能、利用量、支援範囲を確かめます。利用者側と提供者側の双方から費用を描くことで、料金表を事業の仕組みへ読み替える基礎ができます。

参照資料:The NIST Definition of Cloud Computing責任共有モデルAI Risk Management Framework

この章の要点

  • 売上と費用を層ごとの取引に分ける
  • 従量料金と設備の固定負担を区別する
  • 契約終了時まで責任と手順を考える

自分の言葉で考える

利用者に従量料金を請求できれば、基盤提供者の設備負担も同じ割合で変動しますか。

考え方の例を読む

必ずしも変動しません。設備や開発への支出は先行し、利用が少なくても維持費がかかる場合があります。利用率と回収期間を合わせて読みます。

AI・クラウド・計算資源、モデル、業務サービスのお金の流れについて質問する

出典と確認時点

統計や企業の説明は、資料の対象時点と確認日を分けて読んでください。

  1. The NIST Definition of Cloud Computing ↗NIST / 公表日の記載なし / 確認日:2026-10-31
  2. 責任共有モデル ↗AWS / 公表日の記載なし / 確認日:2026-10-31
  3. Security in Amazon EC2 ↗AWS / 公表日の記載なし / 確認日:2026-10-31
  4. Energy and AI ↗IEA / 公表日の記載なし / 確認日:2026-10-31
  5. AI Risk Management Framework ↗NIST / 公表日の記載なし / 確認日:2026-10-31