SageMakerとBedrockの比較は技術的な比較ではない。組織がモデルを所有することを職務とする人材を抱えているかどうかという問いだ。モデルの成果物を訓練し、評価し、ページャー当番まで担うチームがあるなら、SageMakerはそのチームがすでにやっている仕事を言い表しているにすぎない。そのチームがなければ、そしてAI機能を出荷しているほとんどの企業にはそのチームがないのだが、Bedrockは妥協案ではない。組織図を正しく読み取った結果だ。

この比較は通常、制御性、トークン単価、モデル選択肢、ファインチューニング、レイテンシといった機能マトリクスとして行われる。それらの項目は確かに実在するが、下流の話にすぎない。どの項目も、深夜3時にそれを支える責任を誰が負うと想定されているかによって答えが変わる。それは技術的な事実ではなく組織的な事実だ。

それぞれが実際に何を求めるか

マーケティングの言葉を取り除くと、この2つのサービスはまったく異なる要求をしてくる。

Bedrockが求めるのは呼び出しの所有だ。得られるのはAPI、モデルID、そして請求書だ。プロンプト、検索、出力の評価、コストについては責任を負うが、キャパシティ、ハードウェア、モデルの更新、重みのデプロイについては責任を負わない。作業の単位はリクエストだ。

SageMakerが求めるのは成果物の所有だ。得られるのは、自分が説明責任を負うモデルを訓練し、チューニングし、ホストし、監視するためのインフラだ。訓練データの系譜、リリースをゲートする評価ハーネス、エンドポイントのインスタンス群、オートスケーリングポリシー、ドリフト検知、そして新バージョンをロールする判断まで、すべて自分の所有物になる。作業の単位はモデルバージョンであり、モデルバージョンには所有者、変更履歴、ロールバックが伴う。

この2つ目のリストは仕事そのものだ。単発のタスクではなく、オンコールを伴う常設の職務だ。問題は、その職務が今の会社に存在するかどうかだ。

チームトポロジーの議論

現実の組織を3つの形に分類してみよう。

知能を消費するプロダクトチーム

このチームは機能を出荷する。肩書きに「モデル」という言葉を含む人は誰もいない。ロードマップのAI部分は「チケットを要約する」「このフィールドを抽出する」といった内容だ。この形のチームにはBedrockが答えであり、それも僅差ではない。このチームにSageMakerエンドポイントを渡すことは、彼らが維持できない運用面を渡すことに等しい。誰も見ないドリフトモニター、ローンチ時にサイズを決めてから二度と見直されないエンドポイント、理解していた唯一の担当者がチームを離れた瞬間に壊れる訓練パイプライン。プロダクトチームにおけるSageMakerの失敗モードは、悪いモデルではない。所有者のいないモデルだ。

プロダクトチームに奉仕するプラットフォームチーム

ここではプラットフォームチームがゲートウェイ、クォータ、評価インフラ、コスト按分を所有し、プロダクトチームがプロンプトと機能を所有する。プラットフォームチームの直感としては、モデルを所有することが自然な次のステップに思える。だが通常はそうではない。彼らが提供する価値は、プロダクトチームと推論の間の縫い目、つまりルーティング、鍵、予算、評価、監査だ。この縫い目はBedrockの上に構築する価値があり、これはまさにLLM Gateways: Why Every Platform Team Builds One Eventuallyで述べた形そのものだ。SageMakerを追加するということは、すでに他の6つのチームのボトルネックになっているチームに「モデルも我々が運用する」という役割を追加することを意味する。

すでにモデルを所有しているMLチーム

このチームには訓練パイプライン、特徴量ストア、モデルレジストリ、そしてすでにページャー当番を回している既存のエンドポイントがある。彼らにとってSageMakerは新たな負担ではなく、すでに背負っている負担にツールが付いたものにすぎない。ここで興味深いのは選択そのものではなく、両方を運用することを認める点だ。プロダクトそのものであるモデルにはSageMakerを、その周辺の汎用的な言語処理にはBedrockを使う。実際のランキングモデルを運用している会社が、コミットの要約を書くためだけにモデルをファインチューニングする必要はない。

SageMakerが実際に必要になる理由

私の経験では3つあり、いずれも具体的だ。

  • モデルそのものが製品、あるいは差別化要因である場合。不正検知スコアリング、ランキング、予測など、自社の重みが競合他社には買えない何かをエンコードしている場合だ。自分が売っているものをアウトソースすることはできない。
  • 重みやデータが、マネージド推論APIでは満たせない形で、自社の管理境界の外に出せない場合。ただしこれは実際の要件を読み込んだ上での話であり、単に噂を繰り返しているだけではないことが前提だ。この理由は、精査に耐える頻度よりもはるかに頻繁に主張される。
  • 誰もホストしてくれないモデルが必要な場合。特定のオープンウェイトのチェックポイントやドメイン適応済みの派生モデルであり、ホスト型の選択肢との差を想定ではなく実測している場合だ。

リストに含まれていないものに注目してほしい。コストだ。セルフホスティングは高く安定した利用率のもとではトークン単価が安くなるが、それ以外のあらゆる状況ではかなり高くつく。トラフィックがあってもなくてもインスタンス代を払い続けることになり、さらにキャパシティプランニングのための人件費も発生するからだ。コストの議論は、実は稼働率の議論が仮面をかぶったものであり、数字が伴わなければ議論として成立しない。

この意思決定はどこで誤るのか

よくある失敗は、願望としての組織に合わせてアーキテクチャを選んでしまうことだ。あるチームは、ロードマップのスライドに「来年独自モデルを構築する」と書いてあるからという理由でSageMakerを選ぶ。パイプラインを構築し、1回のファインチューンを出荷するが、MLチームの人員は結局確保されず、2年後には誰も説明できないエンドポイントのインスタンスタイプをプロダクトエンジニアがおそるおそる変更している。技術に問題はなかった。前提としていた組織のほうが現れなかったのだ。

逆方向の失敗も存在するが、それは軽微で修正しやすい。Bedrockを使っているチームが、自分たちで所有すべき本物のモデルの必要性を発見し、そのワークロード1つを移行する場合だ。マネージドAPIから所有物の成果物へワークロード1つを移すのは1つのプロジェクトにすぎない。だが所有者のいないMLプラットフォームを廃止するのは発掘調査に近い。

見極め方

設計レビューで1つだけ質問すればいい。このモデルの品質が劣化したとき、誰にページが飛び、その人は何をするのか。

答えが特定の人物を名指しし、ロールバックをゲートする評価スイートを説明でき、その人物のマネージャーも同意しているなら、SageMakerという選択肢は現実的だ。答えが「調べてみます」だったり、まだ存在しないチームの名前だったりするなら、あなたの組織は知能を生産する側ではなく消費する側であることをちょうど発見したことになる。ならばそれに合わせて構築すればいい。それは野心が小さいということではなく、正確だということだ。そしてそうしたチームを縛る制約は、ほとんどの場合モデル所有ではない。評価だ。評価はどちらの道を選んでも必要になる規律であり、両方の道の本当の前提条件だと私は考えている。

結論

チームがオンコールと評価スイートを備えた常設の職務としてモデルの成果物を所有しているならSageMakerを選ぶ。組織がモデルの出力を消費して機能を構築しているなら、つまりほとんどの組織のほとんどの場合はBedrockを選ぶ。この判断を誤ったときの失敗モードは悪いベンチマークではない。所有者のいないインフラが静かに劣化し、やがて派手に壊れることだ。今ある組織図に合わせて選ぶこと。

次に読む

この議論のプラットフォームチーム版、つまりモデルではなくクラスターやパイプラインを誰が所有するかという話はercan.cloudにある。ハブはercanermis.comだ。