Cloud Runとは
Cloud Runとは、Google Cloudが提供するフルマネージドのコンテナ実行サービス
読み: クラウドラン
Cloud RunはGoogle Cloudが提供するフルマネージドのコンテナ実行サービス。Dockerコンテナをデプロイするだけで、サーバーの構築・管理・スケーリングを全てGoogle Cloudが処理する。トラフィックがゼロのときはインスタンスもゼロまで縮小するため、使った分だけ課金される。Kubernetesの運用負荷なしにコンテナを本番稼働できる。
かんたんに言うと
コンテナをアップロードするだけで動くGoogle Cloudのサービス。サーバーの面倒を見る必要がない。アクセスがなければ課金もゼロ。Kubernetesを自前で運用するほどでもないが、コンテナで動かしたいときに選ぶ。
Kubernetesとの使い分け
Kubernetesは大規模なマイクロサービスを細かく制御したい場合に向いている。Cloud Runはその制御が不要な場合に使う。社内向けのチャットボット、APIサーバー、バッチ処理など、単体のコンテナで完結するワークロードならCloud Runが適切。Kubernetesはネットワークポリシー、Pod間通信、ストレージ管理の知識が必要だが、Cloud Runはコンテナイメージを渡すだけで済む。
AI推論サービスでの活用
学習済みモデルをFlaskやFastAPIでラップしてコンテナ化し、Cloud Runにデプロイするパターンが増えている。GPUが不要な軽量モデルの推論であれば、Cloud Runの自動スケーリングが活きる。リクエストが来たときだけインスタンスが起動し、処理後に縮小するため、常時稼働のサーバーを維持するよりコストが下がる。ただしGPUインスタンスが必要な大規模モデルの推論には向かない。
AWS App Runnerとの比較
AWS App RunnerはAWS版のCloud Runに相当するサービス。どちらもコンテナをデプロイするだけで動く点は同じだが、Cloud RunはKnativeベースでカスタマイズの幅が広い。App Runnerはよりシンプルだがその分制約も多い。既にGoogle Cloudを使っているならCloud Run、AWSならApp Runnerという選択が現実的。マルチクラウドを考慮する場合はコンテナ自体の可搬性が鍵になる。
導入時の判断基準
コンテナ1つで完結するサービスならCloud Runで十分。複数サービスの連携やサービスメッシュが必要ならKubernetesを検討する。コールドスタート（初回リクエスト時の起動遅延）が許容できない場合は最小インスタンス数を1以上に設定する必要があり、その分常時課金が発生する。レイテンシ要件とコストのバランスで判断する。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。