Amazon BedrockにOpenAIモデルを導入：OpenAIとAWS CEOインタビュー
(stratechery.com)- OpenAIのfrontierモデルがAmazon BedrockのAWSネイティブなエージェントランタイムに組み込まれ、単なるモデル提供を超えて企業向けのmanaged agentとして統合される
- Bedrock Managed Agentsは identity、permissions、logging、governance、deployment をまとめて提供し、顧客が個別に組み立てていた要素なしで、企業環境でより迅速にエージェントを運用できるようにする
- 現在のエージェント性能はモデルそのものだけでなく、tools、state、memory、permissions、evals を含むharnessとの結合度に大きく左右されており、AWSとOpenAIはこの結合を共同製品として扱っている
- 顧客データはAWS VPC内に残り、OpenAIモデルはBedrock経由で実行され、サポート窓口もAWS中心で運営される
- 初期クラウドがスタートアップの参入障壁を下げたのと同じように、今回の統合もAI導入の障壁を下げる流れの上にあり、急拡大する frontier 需要とともに新たなプラットフォーム層として位置づけられようとしている
AWSとスタートアップ、AI導入の速度
- AWS初期のクラウドモデルは、大企業しか持てなかったインフラを数ドルとクレジットカードだけで使えるようにし、開発者が何を作るかを事前に決めないまま、インターネット上の創造の幅を大きく広げた
- AI導入の波及力も、それと同等かそれ以上と評価されている
- コーディングを10年学ばなければアプリケーションを作れないという構造が弱まっている
- 数百人規模のチームや長い開発期間がなくても、小規模チームが素早く作って反復改善できるようになっている
- 世界のさまざまな領域で新たなイノベーションを開く手段として機能している
- クラウド黎明期と違い、AIの採用速度は非常に速い
- 2006年のクラウドは「書店会社がなぜコンピューティングを提供するのか」を長く説明する必要があったが、AIは人々にずっと速く理解されている
- 単純な知的チャットボットから企業内部の業務遂行へ移る過程では教育が必要だったが、技術変化の速度という基準では比較的速く進んでいる
- スタートアップにおけるプラットフォーム転換は Internet、cloud、mobile、AI の4回に整理される
- YC初期には AWS のようなクラウドのおかげで、少ない資本でも会社を始められるように変わった
- コロケーションスペースを借り、サーバーを組み立て、大金を先に集めなければならなかった障壁が大きく下がった
- サーバー費用だけで数万ドルかかるという前提が崩れ、小資本での起業が可能になった
- スタートアップは大規模なプラットフォーム転換期に、より短いサイクルと少ない資本で動けるとき、大企業に勝ちやすい
- 現在のAIでもその方向性は似ている
- YC内部では、バッチの開始から終了の間にも有望企業の売上期待値が変わるほど、売上成長の速度が過去よりはるかに速く動いている
- AWSは今も多くの成長段階スタートアップが使うクラウドとして示されている
- scale、availability、security、reliability と、AWS内の ISV パートナーエコシステム、AWS上の顧客基盤が強みとして結びついている
- クレジットだけでなく、システム設計の助言、go-to-market の助言も提供し、スタートアップをAWSの中核基盤として引き続き扱っている
- 四半期ごとに直接スタートアップと会い、製品が実際に適合しているかを確認している
- 今日のスタートアップでは、一般的なコンピュートはAWS、AIはOpenAI API を使うパターンが非常に一般的になっている
Bedrock Managed Agentsと共同製品の方向性
- Bedrock Managed Agentsは、OpenAIモデルがAWSに入るというレベルではなく、OpenAIの frontier モデルをAWSネイティブなエージェントランタイムに組み込む形として提示されている
- identity、permission state、logging、governance、deployment といった運用要素が一体で提供される
- 次の段階のAIは、テキストを入力してテキストを受け取る段階を超え、社内で実際に仕事をするstateful agentへ移行しつつある
- 「virtual co-workers」という表現は完璧ではないが、最も違和感の少ない言い方として扱われている
- 業界全体としても、これを何と呼び、どう使うかはまだ完全には定まっていない
- Codexはこの流れの明確な例として示される
- 実際に望む仕事が起きることが核心であり、ユーザーはモデルとハーネスのどちらがより貢献したかを区別しなくなる
- モデルとハーネスの結合度がエージェント性能の核心として扱われる
- tools、state、memory、permissions、evals が実際の動作を左右する
- pre-training とまったく同じではないが、post-training と prompt の両方のレベルで結合が起きている
- 初期には分離して見えたtool-callingも、時間とともに学習過程へより深く統合されている
- 今後は model と harness、さらに pre-training と post-training も、より強く結びつく可能性が示されている
- 産業の成熟度は、まだHomebrew Computer Club時代にたとえられるほど初期段階だと描写される
- AWSとOpenAIの共同作業は、顧客が自分で組み立てる必要があった要素をまとめ、企業環境でより早く価値に到達できるようにすることに焦点を当てる
- 顧客は、モデルとエージェントが記憶を維持しながらうまく協調して動くことを望んでいる
- サードパーティツールだけでなく、自社ツール、自社データ、自社アプリケーション、自社運用環境まで接続したいと考えている
- こうした統合作業は、これまで各顧客が自分で担わなければならない領域だった
- 共同製品では identity が組み込まれ、データベース認証もAWS VPC内で行われるよう設計されている
- 目標は単なる利便性向上ではなく、従来方式では苦労して組み立てても信頼性高く実装できなかったものまで可能にすることにある
- 現在の開発者は、モデルを活用して何かを作る際に過剰な苦痛と手作業を経験している状態だと描写される
- ChatGPT の利用でもコピー＆ペーストや複雑なプロンプトの組み合わせが多い
- こうした摩擦は消えていくはずで、今はまだ非常に早期で不便な段階だとされる
- 今回の協業は、AWSに既にいる顧客がOpenAI technologyを求めている需要と、OpenAIがAWS顧客へのアクセス性を広げようとする方向性が重なった結果でもある
- 単なるモデル流通を超え、新しい製品を一緒に作る性格がより強調されている
- 1年後に振り返ったとき、「AWSからOpenAIモデルにアクセスできるようになった」ことよりも、この新製品の重要性の方が大きく残ってほしいという構図である
- model、harness、capability の次元で、従来のモデル API 呼び出しとは異なる新しいコンピューティング方式に近づいている
AgentCore、Managed Agents、運用モデル
- AgentCore は、メモリ、安全な実行環境、権限付与といったエージェントのプリミティブの集合として紹介される
- Bedrock Managed Agentsは、AgentCore の構成要素の上に OpenAI モデルと複数の運用要素を組み合わせ、AWSとOpenAIが共同構築した上位製品として位置づけられる
- AgentCore だけでも、直接agentic workflowを作ることができる
- すでに production でこれを動かし、実運用している顧客もいる
- 現在でも AgentCore を使いながら、OpenAIモデルを外部呼び出しする方式は可能である
- Bedrock にネイティブ統合された形ではないが、他クラウド上の OpenAI モデルを直接呼び出している顧客がいる
- AWSはこれをオープンなエコシステムとして扱う
- 欲しい能力を組み合わせて自分で構築する方法は、今後も続きうる
- 自宅で直接コンピューターを組む人のように、長く自分でエージェントを作りたいビルダーも残ると見ている
- 多くの顧客は、すべての部品を自分で設定しなくてもよいより簡単な方法を望んでおり、今回の協業リリースはその需要を狙っている
- AzureでのOpenAI利用は API への直接アクセス体験であり、Amazonでの今回の発表はそれとは異なるmanaged serviceとして整理される
- この managed agent サービスは現在Amazonと独占的に進められている
- 単に Amazon API を使うレベルではなく、両社が共に進めるjoint effortとして扱われている
- 顧客データはAWS内部に残る
- 全体が VPC 内に留まり、Bedrock 環境内で保護される
- OpenAIモデルは Bedrock 経由で実行され、インフラはTrainiumとGPUを混在させて使う
- 一部はタイミングの問題であり、一部は capabilities の問題として整理される
- 時間とともに、より多くの比重が Trainium に移る方向性が示されている
- OpenAI も自社モデルが Trainium 上で動くことに大きな期待を示している
- OpenAIモデルをAWS環境で運用する際の一次サポート窓口はAWSが担う
- 顧客は AWS support と AWS のアカウント担当者を通じて支援を受ける
- 構築過程では OpenAI 側の人員も参加し、活用方法を一緒に調整する
- OpenAI の支援が必要なバグは、AWSがOpenAIへエスカレーションする
ローカル、クラウド、権限とセキュリティ境界
- Codexは最初はクラウドから始まったが、実際にはローカル実行へ戻った流れが示される
- ローカルが容易な理由は、環境がすでにそこにあるからである
- コンピューター設定、データ、ファイルアクセスがすでに整っており、追加構成が少ない
- 最終形ではなくても、短期的には使いやすさの方が重要に働く
- 長期的には、エージェントがクラウドで実行され、非常に重い作業やコンピューターを閉じる必要がある状況ではクラウドへ渡す形が有用な方向として扱われる
- ローカルクライアントには依然として利点がある
- iPhone アプリにもローカルコンポーネントがあるように、connectivity、latency、local compute、ファイルやアプリケーションへのアクセスの面で利点がある
- ただしノートPC自体を scale-out することはできないため、拡張性の限界は明確である
- 企業環境ではローカル方式はより難しくなる
- 2人の間で共有するだけでも難易度が上がる
- permissions と security boundary を扱うのがより複雑になる
- 結局、ローカルとクラウドをつなぐbridgeが必要になる
- エージェントは、配備する環境と同じ環境で開発する方が自然であり、identity と permission の設計はまだ多くが未完成な領域として残っている
- 人間のアカウントをエージェントがそのまま使うべきか
- エージェントが別アカウントを持つべきか
- 複数のエージェントを置くときにどう区別するかといった問題が残る
- 「Ben のエージェントが Ben としてログインしつつ、実際の Ben ではなくエージェントであることを示す」ようなprimitiveすらまだ存在しない
- エージェントが労働力に組み込まれ、自律性と作業複雑性が高まるほど、社内およびインターネット全体のアクセス制御と権限モデルも一緒に進化する必要がある
- クラウドへ移すほど、中央組織はセキュリティ統制をより強く持てる
- 顧客は強力なモデルとエージェントの可能性を好む一方で、ミスによって会社が致命傷を負うような事態を最も懸念している
- VPC内で動かしたり、特定の gateway を通したり、環境内の role のように権限を付与したりすることで境界を制御できる
- AWSが20年間積み上げてきたセキュリティ構造により、スタートアップだけでなく、世界的な銀行、医療機関、政府機関も利用できてきたという点につながる
- リスク回避的な組織ほど、sandbox内のガードレールがむしろ導入を広げる
AIスタックと企業向けアーキテクチャ
- 企業顧客は、データとエージェントを接続し、トークン支出の追跡と監督を提供する管理レイヤーを求めている
- 大企業顧客は、agent runtime environment、管理レイヤー、従業員向け workspace を束ねた形を一貫して求めている
- 従業員向け workspace としては Codex のような形が例として挙げられる
- こうしたパッケージ需要はかなり一貫しているが、実際の提供物はまださらに構築が必要である
- 組織内には、複数のデータベースや SaaS アプリ、分散データをまたぐmiddleware / middle layerが必要だという点で一致している
- 関連文脈として OpenAI Frontier もあわせて参照されている
- 現在の構造では、ユーザーとの相互作用を担うuser agent layerと、企業管理レイヤーの両方が必要に見える
- ユーザー側では複数のエージェントとやり取りし、それぞれのエージェント同士が会話するように構築する形が使われる
- 企業管理レイヤーでは、AIがファイルシステムなどを探索するときに必要な各種controlが重要である
- ただし、モデルが十分に賢くなれば、この構造全体を再設計する可能性も開かれている
- 今の二重レイヤー構造は現在の世界に合わせた形である
- 将来のアーキテクチャが正確にどうなるかはまだ分からない
- ある時点では「これは単にモデルの中にあるべきだ」という判断につながるかもしれない
- 顧客が実際に使い、構築していく過程を通じて、何をより簡単に、より速く、より良くすべきかを学んでいくことになる
需要、容量、モデルの階層化
- OpenAIはこの事業に大量のコンピュート調達と相当な努力を投入しており、それに見合う売上も期待している
- 知能への需要は、価格が十分下がれば事実上上限のない需要に近い性質として扱われる
- 現在は価格より容量不足の方が大きな制約に見える
- 価格に関係なく、より多くの capacity を望み追加コストも支払うという顧客の方が、価格を争う顧客より多い
- 現在水準の知能コストは、今後も劇的に低下するという確信が示されている
- 市場全体の需要のかなりの部分がabsolute frontierに集中している点は、予想以上に驚くべきシグナルとして扱われる
- 旧世代モデルで十分だろうという想定より、最新の最前線モデルを引き続き求める流れの方が強く現れている
- コンピュートコストが数十年にわたり大きく下がっても販売量は増え続けたように、AIも同様の需要拡大の経路をたどる可能性が示される
- 今は有用な仕事をするには多くの場合frontierモデルが必要で、誰もがそちらを求めている
- 時間がたてば、小さく安く速いモデルと超大型モデルが共存する混合構造が形成されると予想される
- 一部の小型モデルは、時間とともに、現在の最新 OpenAI モデルですらまだできない作業まで処理できるようになる可能性がある
- 超大型モデルはがん治療のような、より大きな問題を狙うようになるかもしれない
- 今はまだ初期段階であり、この水準の需要と成長が同時に現れていることが、今後の可能性を大きく広げている
Trainium、抽象化、内部コンピュート
- Trainiumは名前に反して、今後は inference 面での存在感がより大きくなるのではないかという問いに対し、AWSは training と inference の両方に有用だと答えている
- 顧客は Trainium を直接扱うより、managed service の抽象化を通じて接する方向が強調される
- GPUも大半の顧客が直接相手にしないのと同じく、OpenAI や Claude を使うとき、実際には GPU、Trainium、TPU ではなくinterfaceとやり取りすることになる
- 今後も accelerator chip は少数の大規模モデルとサービスの背後で動く可能性が高い
- 5個、10個、20個、100個という水準にはなっても、これを直接プログラムする人が数百万人規模に増えることはないと見られている
- モデル学習は費用も大きく、運用の専門性も高く求められる
- OpenAIチームは大規模コンピュートクラスタから価値を引き出す能力に優れているが、そのようなチームを持つ場所は多くない
- OpenAIは、自分たちを最初はtoken factoryのように考えると述べた後、すぐにintelligence factoryに近いと言い直している
- 顧客が欲しいのはトークン数ではなく、最低コストで最高の知能単位を十分な capacity とともに受け取ることだからである
- GPT-5.5 は、トークン単価は5.4より高いが、同じ答えを得るのに必要なトークン数ははるかに少ない例として提示される
- ユーザーは回答に何トークンかかったかより、望む作業が完了したかどうかを気にする
- より大きなモデルが少ないトークンで動く場合でも、より小さなモデルが多くのトークンで動く場合でも、GPUであっても Trainium であっても、顧客が求めるのは内部実装ではなく低コストで大きな効用である
- Codexや、Amazon Bedrock向けの Stateful Runtime Environment 内で新しいエージェントを作るときも、ユーザーは内部コンピュートの選択を意識する必要がないはずだとされる
- トークン使用量の減少は主にモデル改善の結果であり、ハーネスの影響は一部にとどまる
- AWSは、類似の managed service を他モデルにも拡張するかについて、現時点ではOpenAIとの協業に集中しているとだけ答えている
市場展開とプラットフォーム戦略
- ChatGPTは、Facebook以来の最初の大規模な新規コンシューマー製品と評価される
- OpenAIは ChatGPT だけでなく、API、特にCodexでもかなり良い成果を上げたと述べている
- 過去には、新しい言語インターフェースがインターネット上で情報を探す方法を変える可能性に、より焦点を当てていたという回顧もある
- Google は依然として breadth と depth の面でphenomenal companyと評価されている
- AWSは当初からパートナー中心戦略を取ってきており、パートナーが成功すればAWSも成功する構造を志向してきたと整理される
- すべてを自前で所有すべきだという方式とは異なり、パイを大きくする発想に近い
- 顧客が自分に最適なものを選べるべきであり、それが自社製品であってもパートナー製品であっても構わないという立場である
- Bedrockもこの戦略の上で、幅広いモデルと多様な機能を支援するよう設計されている
- データベース、コンピュートプラットフォームなど他領域でも同様のアプローチを維持してきたと整理される
- AWSはインフラ層では S3 のような自社コア構成要素を強く押し出す一方、スタック上位へ行くほど、より広いパートナーエコシステムを受け入れる方が顧客にも有利だと見ている
- 両社の役割は、OpenAIがSoftware、AWSがInfrastructure、そして共同でPlatformを作る構図として整理される
- 今後1年でモデル能力が急速に進化すると予想されるだけに、いま共同でプラットフォームを構築するタイミングは良いタイミングとして提示される
1件のコメント
Hacker Newsの意見
Amazonという「信頼された」仲介者を通じてアクセスできたからだ。OpenAIは禁止されていて、信頼もされていない
こうした組織の法務判断に私が必ずしも同意するわけではないが、利用規約は私よりずっと丁寧に読んでいるのだろう
この発表が流れを変えるかは様子見だが、今の体感ではOpenAIはさまざまな面でかなり後れを取っているように見える
ただ、AI業界では2〜8週間の差はとてつもなく大きい隔たりというほどでもないので、実際の影響より認識の問題かもしれない
少なくとも私の情報バブルでは、Sam AltmanのせいでOpenAIの評判は地に落ちており、非倫理的に見えるうえ、fabs関連の要求のような話を見るとかなり不安定にも見えるので、あまり好かれていない
AWSを使うだけで十分というわけではなく、AWSがモデルを動かしていても、きちんとしたZDRが欲しいなら別途そちらと協議する必要がある [0]
[0]: https://platform.claude.com/docs/en/build-with-claude/claude...
両者とも確実に得をしており、AWS顧客のフィードバックループ文化が、Anthropicがエンタープライズ対応をより早く整える助けにもなったのだろう
Azure側にはすでに以前から存在していた
一方でAnthropicはひとつのことに集中しており、だからこそSWEベンチマークで常に最上位に入るのだと思う
AWSは、入力と出力がモデル提供者と共有されず、基盤モデルの学習にも使われないと明記している [1]
さらにOpenAIはNYT v. OpenAIで2025年5月の保存命令を受けており、裁判所はChatGPTの出力ログを事実上無期限に保管するよう強制している
これには、本来30日以内に削除されていたはずの、ユーザーが削除した会話も含まれる [2]
そのため、HIPAA/GDPRに縛られる組織にとっては、そもそもスタートラインにも立てない条件になっている
[1] https://aws.amazon.com/bedrock/faqs/
[2] https://openai.com/index/response-to-nyt-data-demands/
政治的駆け引きや官僚的レビューは、たいてい下のレベルの人たちを機能の残りかすや運用作業で忙しく縛りつけておくためのものに近いと思う
モデルがGPTのOSS派生版と十分似ているなら、思ったほど複雑ではなかった可能性もある
量子化、カスタム配信用シリコン、バッチング、その他の推論最適化によって、元の提供者版とホスティング版の挙動が変わることがある
この論文はまったく同じ状況ではなく、監査可能なオープンウェイトのLlamaを扱っているが、似た症状をよく示している
https://arxiv.org/pdf/2410.20247
そこでは実際かなりのマージンも残せそうだ
これがMicrosoftとの決別の流れと直接つながっているのかも気になる
私の周りの事例を見るだけでも、本格的なエンタープライズ導入ではOpenAIはほとんど無視されている。Azureでの提供がいまひとつで、それ以外に企業向けに優しい経路もないからだ
AnthropicとAWSの組み合わせにエンタープライズ市場を渡し続けるのが致命的だと気づき、OpenAIが追いつくために動いたように見える
https://news.ycombinator.com/item?id=47921248
金融・ヘルスケアのような規制産業は、すでにAWSとデータ所在地に関する取り決めを含む契約を結んでいることが多い
Bedrock上のOpenAIは、こうした組織がOpenAIと別途DPA交渉をしなくて済むようにするので、書類上の見た目以上に大きな突破口になりうる
サブプロセッサが1つ減り、データもすでにAWS内にあるので、別の場所へ送られる心配が減る
AWSがついに諦めて、Bedrockを少しは使いものになるようOpenAI API互換性を入れたのでなければ、だが
ResponsesとChat Completionsをサポートしているので、こちらを参照してほしい https://docs.aws.amazon.com/bedrock/latest/userguide/endpoin...
今回のHN投稿だけ見ても、発表リンクが同時に4つも出てきたのは偶然ではない
誤った発言が誤ったタイミングで出れば数十億ドルの投資資金が揺らぐので、メッセージは非常に慎重に磨き上げ、段階的に出していくしかない