Serverless
読み: サーバーレス
サーバーレスとはAI基盤の最適化
AIインフラにおけるサーバーレスとはサーバーの構築や保守管理をクラウド事業者に任せAIモデルの実行やデータ処理に必要な計算リソースを必要な分だけ動的に割り当てる仕組みである。常時稼働の仮想マシンを維持する手間とコストを省きコードの実行時間に対してのみ課金される。
かんたんに言うと
蛇口をひねった時だけ水が出てその分の水道代を払うシステムと同じである。貯水タンクのメンテナンスや水圧の調整はすべて水道局がやってくれるため利用者は水を使うことだけに集中できる。
サーバー管理から解放されるServerlessアーキテクチャの基本構造
サーバーレスという言葉は嘘をついている。物理的なサーバーが消滅するわけではない。単に私たちがOSのパッチ当てやミドルウェアのバージョン管理から解放されるだけである。
AWS Lambdaを例に挙げよう。API経由でリクエストが飛んできた瞬間だけコンテナが立ち上がり処理が終われば消える。開発者は推論用のPythonコードを書くだけでいい。
インフラエンジニアの仕事が奪われるわけではない。むしろネットワーク設計や権限管理の複雑さは増す。どこまでをマネージドサービスに任せるべきか現場の判断が分かれるところである。
ビジネス現場での具体的な活用事例と代表的なクラウドサービス
経理部門の領収書OCR処理を想像してほしい。月末の3日間だけアクセスが集中しそれ以外の日は閑古鳥が鳴く。こんなワークロードに常時稼働のGPUサーバーを用意するのは正気の沙汰ではない。
ここでGoogle Cloud RunやAzure Functionsの出番となる。
Amazon Bedrockのようなフルマネージドの生成AIサービスも広義のサーバーレスである。APIを叩くだけで基盤モデルを呼び出せる。物流の配送ルート最適化バッチなど不定期に重い計算が走る業務とサーバーレスの相性は抜群に良い。あなたの会社でも無駄にアイドリングしているAIサーバーはないだろうか。
サーバーレスアーキテクチャを採用する利点と技術的な制約
スケーラビリティの高さと固定費削減ばかりがもてはやされるが現場の落とし穴は深い。
最大の敵はコールドスタートである。
しばらくリクエストがない状態から突然APIが呼ばれるとコンテナの起動からモデルのロードまでに数秒から数十秒の遅延が発生する。リアルタイム性が命のチャットボットでこれをやるとユーザーは離脱する。
対策としてプロビジョンド同時実行などを設定すると結局固定費がかかって本末転倒になる。非常に悩ましい問題である。さらに特定のクラウド事業者の独自仕様に依存するベンダーロックインのリスクも常につきまとう。
自社AIプロジェクトにサーバーレスを導入するための評価基準
トラフィックの波が激しいかそれとも24時間一定の負荷がかかり続けるか。これが最初の分岐点になる。
常時高負荷なら専用の仮想マシンを立てた方がTCOは安くつくことが多い。まずはPoCの段階でサーバーレスを選びインフラ構築の時間を省いて素早く仮説検証を回す。そして本番稼働後にトラフィックの傾向を見てアーキテクチャを見直すのが現実的なアプローチだろう。
ただしAIモデルのサイズが大きすぎるとサーバーレスのメモリ制限に引っかかる。結局のところ銀の弾丸はない。自社の要件と技術的制約の境界線をどこに引くか実務家の腕が試される。
当社の見解
当社は機密情報のマスキング処理を全てローカルAIで行っている。これにより機密情報を外部に送信せずにAI処理できるようになった。だが、AIが嘘をつくハルシネーションの問題は依然としてある。確認していないのに「確認しました」と言う。当社はこの前提で運用を設計している。事実と推測の強制分離、ファクトチェック機能、3つのAIと人間の同士の三重検証を行っている。どこまでいっても、AIは完璧ではない。理論上100%安全設計をしていても、AIも人間も想定しないことは起こるものだ。その万が一に備えておくことが、AIを使う上では前提になっている。だろうではなく、かもしれない運用がAIを使う上での安全基盤となっている。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。