2 ポイント 投稿者 GN⁺ 2026-04-29 | 1件のコメント | WhatsAppで共有
  • 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のようなクラウドのおかげで少ない資本でも会社を始められるように変わった
    • colo スペースを借りてサーバーを組み立て、大きな資金を先に集めなければならなかった障壁が大きく下がった
    • サーバー費用だけで数万ドルかかるという前提が崩れ、少資本での起業構造が可能になった
  • スタートアップは大きなプラットフォーム転換期において、より短いサイクルとより少ない資本で動けるとき、大企業に勝ちやすい
    • 現在のAIの上でもその方向性は似ている
    • YC内部では、バッチの開始から終了までの間に優れた企業の売上期待値が変わるほど、売上成長のスピードが過去よりはるかに速く動いている
  • AWSは今も多くの拡大段階のスタートアップが使うクラウドとして位置づけられている
    • scale、availability、security、reliabilityと、AWS内のISVパートナーエコシステム、AWS内の顧客基盤が一体となって強みを成す
    • クレジットだけでなく、システム設計の助言や go-to-market の助言も提供し、スタートアップをAWSの中核基盤として引き続き扱っている
    • 四半期ごとに直接スタートアップと会い、製品が実際に適合しているかを確認する
  • 今日のスタートアップでは、一般的なコンピュートはAWSAIは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はこれをオープンなエコシステムとして扱っている
    • 必要な能力を組み合わせて自前で構築するやり方は、今後も続きうる
    • 自宅で自作PCを組む人のように、長く自分でエージェントを作りたいビルダーも残ると見ている
  • 多くの顧客は、すべての部品を自分で設定しなくてよいより簡単な方法を求めており、今回の協業リリースはその需要を狙ったもの
  • 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が必要だという点で一致している
  • 現在の構造では、ユーザーとのやり取りを担う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 により近いと言い直した
    • 顧客が求めているのはトークン数ではなく、最小のコストで最高の知能単位を十分な容量で受け取ることである
  • 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 は当初から partner 中心戦略を取ってきており、パートナーが成功すれば AWS も成功するという構造を志向してきた
    • すべてを自社で所有しなければならないという方式とは異なり、パイを大きくする発想に近い
    • 顧客が自分に最も適したものを選べるべきであり、それが自社製品であってもパートナー製品であっても構わないという立場だ
  • Bedrock もこうした戦略の上に、幅広いモデルと多様な機能を支援できるよう設計されている
    • データベース、コンピュートプラットフォームなど他の領域でも同様のアプローチを維持してきた
  • AWS はインフラ層では S3 のような自社の中核コンポーネントを強く推進する一方、スタックの上位に行くほど、より広いパートナーエコシステムを受け入れるほうが顧客にとっても有利だと見ている
  • 両社の役割は OpenAI が SoftwareAWS が Infrastructure、そして共同で Platform を作るという構図だ
  • 今後 1 年でモデル能力が急速に進化すると予想されるだけに、今このタイミングで共同でプラットフォームを構築するのは良いタイミングだと考えている

1件のコメント

 
GN⁺ 2026-04-29
Hacker Newsの意見
  • 私が働くプライバシーに敏感な組織では、Claudeのほうがはるかに受け入れられていた
    Amazonという「信頼された」仲介者を通じてアクセスできたからだ。OpenAIは禁止されていて、信頼もされていない
    こうした組織の法務判断に私が必ずしも同意するわけではないが、利用規約は私よりずっと丁寧に読んでいるのだろう
    この発表が流れを変えるかは様子見だが、今の体感ではOpenAIはさまざまな面でかなり後れを取っているように見える
    ただ、AI業界では2〜8週間の差はとてつもなく大きい隔たりというほどでもないので、実際の影響より認識の問題かもしれない
    少なくとも私の情報バブルでは、Sam AltmanのせいでOpenAIの評判は地に落ちており、非倫理的に見えるうえ、fabs関連の要求のような話を見るとかなり不安定にも見えるので、あまり好かれていない
    • 主要なLLMプロバイダーは、どこもZDR契約を結ぶことができる
      AWSを使うだけで十分というわけではなく、AWSがモデルを動かしていても、きちんとしたZDRが欲しいなら別途そちらと協議する必要がある [0]
      [0]: https://platform.claude.com/docs/en/build-with-claude/claude...
    • Anthropicが最高のモデルとぶれの少ないリーダーシップを持っているのはその通りだが、エンタープライズでの到達性を大きく高めたのはやはりAWSのおかげだと思う
      両者とも確実に得をしており、AWS顧客のフィードバックループ文化が、Anthropicがエンタープライズ対応をより早く整える助けにもなったのだろう
    • 法的条件、SLA、データ懸念の面で、これがOpenAI on Azureより本当に優れているのか気になる
      Azure側にはすでに以前から存在していた
    • OpenAIはLLMひとつだけを売ることに集中せず、動画や画像生成もあわせてやっている
      一方でAnthropicはひとつのことに集中しており、だからこそSWEベンチマークで常に最上位に入るのだと思う
    • これはAWSが単に「信頼された仲介者」だからという話ではなく、モデルが顧客自身のAWSアカウント内で別の契約の下に実行される点が重要だ
      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/
  • 大手テックで働いていて、2つのチーム間で小さな機能ひとつのデプロイ調整をするだけでも終わりのない会議をする立場からすると、こうしたモデルをBedrockのハードウェアに載せるために行われた会議や6-pagerの量は想像もつかない
    • このレベルになると、ただ決めてSWATチームを組み、数週間で押し切ることも多い
      政治的駆け引きや官僚的レビューは、たいてい下のレベルの人たちを機能の残りかすや運用作業で忙しく縛りつけておくためのものに近いと思う
    • 実装方式にもよるが、Amazonはすでにgpt-oss-20bを入れている
      モデルがGPTのOSS派生版と十分似ているなら、思ったほど複雑ではなかった可能性もある
  • 異なる推論プラットフォームで動かす同じモデルが、必ずしもまったく同じ結果を出すとは限らない
    量子化、カスタム配信用シリコン、バッチング、その他の推論最適化によって、元の提供者版とホスティング版の挙動が変わることがある
    この論文はまったく同じ状況ではなく、監査可能なオープンウェイトのLlamaを扱っているが、似た症状をよく示している
    https://arxiv.org/pdf/2410.20247
    • OpenAIMicrosoft経由でgpt-xの両方を使ったことがある人なら、この違いを非常にはっきり感じたはずだ
  • 私たちの組織でも、Bedrock提供がAnthropic利用を後押しした中核要因だった
    そこでは実際かなりのマージンも残せそうだ
    これがMicrosoftとの決別の流れと直接つながっているのかも気になる
    私の周りの事例を見るだけでも、本格的なエンタープライズ導入ではOpenAIはほとんど無視されている。Azureでの提供がいまひとつで、それ以外に企業向けに優しい経路もないからだ
    AnthropicとAWSの組み合わせにエンタープライズ市場を渡し続けるのが致命的だと気づき、OpenAIが追いつくために動いたように見える
  • ここで興味深いのはエンタープライズ営業の動線だ
    金融・ヘルスケアのような規制産業は、すでにAWSとデータ所在地に関する取り決めを含む契約を結んでいることが多い
    Bedrock上のOpenAIは、こうした組織がOpenAIと別途DPA交渉をしなくて済むようにするので、書類上の見た目以上に大きな突破口になりうる
  • これはコンプライアンスの観点でかなり歓迎できる変化だ
    サブプロセッサが1つ減り、データもすでにAWS内にあるので、別の場所へ送られる心配が減る
  • OpenAIは見たところ、Anthropicのすぐ後ろを追っているようだ
  • これでAWS経由でOpenAIを買えるようになったが、私のツール群と完全互換ではないインターフェースをまた使わなければならないという意味でもある
    AWSがついに諦めて、Bedrockを少しは使いものになるようOpenAI API互換性を入れたのでなければ、だが
  • 思ったより早く出てきた
    • 実際の準備には長くかかったのだろうが、一般に見えるPRの流れは精巧によく回る機械のようだ
      今回のHN投稿だけ見ても、発表リンクが同時に4つも出てきたのは偶然ではない
      誤った発言が誤ったタイミングで出れば数十億ドルの投資資金が揺らぐので、メッセージは非常に慎重に磨き上げ、段階的に出していくしかない
  • OpenAIは結局、dumb pipeの方向に進んでいるようだ