クラウドコンピューティング

CLOUD COMPUTING
読み: クラウドコンピューティング

読み: クラウドコンピューティング

クラウドとはAI開発を支えるIT基盤

クラウドコンピューティングとは、サーバーやストレージ、データベースといったITリソースをインターネット経由で利用するサービス形態のこと。自社でハードウェアを保有・管理する代わりに、必要なときに必要なぶんだけリソースを調達できる。AI開発においては、GPU計算資源の確保や大規模データの処理基盤として中核的な役割を担っている。

かんたんに言うと

自社ビルに発電機を置く代わりに、電力会社から必要なぶんだけ電気を買うようなもの。使った量に応じて料金が変わり、設備の維持管理は事業者側が行う。

AI開発に不可欠なクラウドコンピューティングの基本概念

クラウドサービスはよく3つの層に分類される。
IaaSは仮想マシンやネットワークといったインフラそのものを提供する。AWS EC2やGoogle Compute Engineがこれにあたる。OSやミドルウェアの設定は利用者の責任になる。
PaaSはインフラに加えてアプリケーションの実行環境まで提供する。AWS LambdaやGoogle Cloud Runは、サーバーの存在を意識せずにコードを動かせる。
SaaSはアプリケーションそのものをサービスとして提供する。GmailやSlackを思い浮かべればわかりやすい。
この3つの境界は年々曖昧になっている。コンテナ技術の普及で、IaaSとPaaSの中間のようなサービスが増えた。

AI開発基盤としてのクラウドの実態

LLMの学習にはNVIDIAのA100やH100といった高価なGPUが大量に必要になる。1台あたり数百万円するハードウェアを自社で何十台も調達するのは、資金力のある大企業でなければ現実的ではない。
ここでクラウドの従量課金モデルが生きる。学習フェーズだけGPUインスタンスを大量に起動し、終わったら停止する。推論フェーズでは小さめのインスタンスに切り替える。リソースの柔軟な増減がクラウドの強みである。
とはいえ、GPUインスタンスの時間単価は安くない。学習ジョブの設計を誤って無駄に回し続ければ、月末の請求書に青ざめることになる。コスト管理はクラウドAI開発の最重要スキルのひとつである。

<a href="/ai-glossary/on-premises/">オンプレミス</a>との使い分けが問われる場面

クラウド一択という時代は終わりつつある。
金融機関や医療機関では、データの外部送信自体が規制で禁じられているケースがある。こうした業界ではローカルLLMをオンプレミス環境で稼働させる選択肢が現実味を帯びている。
ハイブリッドクラウドという折衷案もある。機密データはオンプレミスに置き、学習済みモデルの推論だけクラウドで実行する。ただし、オンプレミスとクラウドの間でデータを安全にやり取りする設計は簡単ではなく、ネットワーク設計とセキュリティポリシーの整合が求められる。

マルチクラウドとベンダーロックインの現実

AWS、Azure、Google Cloudの3大プロバイダに加え、Oracle CloudやIBM Cloudも独自の強みを打ち出している。複数のクラウドを使い分けるマルチクラウド戦略は障害リスクの分散やベンダー交渉力の確保に有効だが、運用の複雑さは跳ね上がる。
一方で、特定プロバイダの独自サービスに深く依存すると、他社への移行が困難になる。これがベンダーロックインの問題である。
現実的な判断としては、コア機能にはKubernetesのようなポータブルな技術を使い、差別化が必要な部分だけプロバイダ固有のサービスを活用する。そのバランスは事業規模と技術チームの体力次第で変わる。

当社の見解

当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。

同じ失敗を二度としないAIエージェント

今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。

当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。

古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。

相談する