▪️はじめに

2026年10月5日、AWS × OpenAI 共催の実践型ワークショップ「Prototype Challenge with OpenAI on Bedrock」に参加してきました。

Amazon Bedrock上でOpenAIのモデルとCodexを使って、実際にサービスのプロトタイプを作ってみようというイベントです。
セッションで聞いた内容のメモと、参加して自分の考え方が変わったなと思った部分をまとめていきます。
聞きながらのメモなので、間違えて解釈してしまっている箇所もあるかと思いますがご容赦ください…。

▪️イベントのゴール

OpenAI Model on Bedrockについて理解する
実際にCodex on Bedrockでサービスを作る

▪️Working Backwards

最初にアイデアの出し方として、AmazonのWorking Backwardsの紹介がありました。

Amazonが製品やサービスの企画・開発で実践している、顧客の体験を起点にして未来から逆算する手法です。

「お客様は誰か」「どんな課題があるか」を最初に深く考える
サービスが成功してリリースされたと仮定して、そこから現在に向けて逆向きにプロセスを組み立てる
開発者の都合ではなく、お客様にとっての価値を中心に据える
具体的には以下の順番で考えていくそうです。

userは誰？
Issueは？
最も重要なbenefitはなにか
Needsはなにか
user experienceはどうなるか

MITの教授の「アイデアが湧いたら、何かの形にすべき」という話も紹介されていて、プロトタイプを作るイベントの導入としてわかりやすかったです。

▪️そもそもOpenAIのモデルはBedrockでどこまで使えるようになっているのか

イベントの話に入る前に、ここ半年くらいの動きを自分でも調べて整理しておきます。

4月にAWSとOpenAIの提携拡大が発表されて、OpenAIのモデル、Codex、Managed AgentsをBedrockで提供していくという話が出ました。

6月にGPT-5.5、GPT-5.4、CodexがBedrockでGAになっています。

その後は7月にGPT-5.6のSol / Terra / Luna、9月にフラッグシップのGPT-6 Astraと続いていて、モデルのラインナップがかなり増えています。
時系列はこちらのページにまとまっていました。

Astra（フラッグシップ）> Sol > Luna（一番安い）という並びです。

そして9月29日にGPT-6.1 SolがGAになっています。

OpenAIの公式発表によれば、最新のGPT-6.1 SolはGPT-6 Astraと同等のベンチマークスコア（DeepSWE v1.1等）を出しつつ、1タスクあたりのトークンコストを約1/5まで削減しているそうです。

セッションでもこの点が強く強調されていて、「基本はSolを選択するのがよい。もちろん、複雑なタスクでAstraが必要な場合は引き続きそちらを使ってね」というスタンスでした。

▪️OpenAIからのCodexと最新動向の紹介

モデルについて

6.1 Solと6 Astraはベンチマーク的には競っているが、トークンコストは1/5なので基本はSol推奨
もちろんAstraが必要なケースでは引き続き使ってねとのこと

Codex on Bedrock

OpenAIから直接使う場合と多少の差分はあるが、ほぼ同じように使える

Plugin Extensions

ChatGPTで独自機能を開発できる
Pluginを入れるとChatGPTのサイドバーに追加される

Bedrock Managed Agents

Codexのハーネスを AWS上で動かせる

ちょうど9月29日にプレビューが始まったところで、現時点ではバージニア北部、オレゴン、オハイオのリージョンで使えるようです。

なぜAgentic SDLCにCodexなのか

前提として、実装が加速しても他のプロセスがボトルネックになってあまり速度が出ないよね、という話がありました。
Codex on Bedrockの利点として、SDLC全体の加速が可能になるという説明です。

ソフトウェア開発ライフサイクル：Software Development Life Cycle

その上でCodexを選ぶ理由として挙げられていたのが以下です。

モデルの性能がいい
モデルの幅が広いので、タスクに合わせたコスト管理が可能
App / CLI / IDE Extensionと色んなサーフェスがあるが、ハーネスやコアの部分が同じなので品質が安定している
Codex CLI / Coreがオープンソースである
オープンソースであることの利点としては、OSSだからIntegrationも多いし、ハーネスがオープンなのでユーザーに対して真摯であるという話でした。
バージョンごとに何を選ぶかなど、ユーザーに選ぶ権利があるという考え方のようです。

サーフェスはCodex App / Codex CLI / Codex IDE Extensionがあって、OpenAIとしてのおすすめはCodex Appとのことでした。

/plan（Plan Mode）について

必ずしもPlan Modeを使わなくてもいいと思っている、という話が意外でした。

ふわっとしている時は質問に答えていけば簡単に作れる
決まっていたり、対話で決めたい場合はPlan ModeでもOK

/goal（Goal Mode）について

Ralph Loopで生まれた思想を反映した機能で、「長い仕事の契約書」のようなものだそうです。

どういうゴール設定をすべきかについては、完了条件が明示的に示されていることなどがブログに書かれているとのことでした。
OpenAIが出しているGoal設定のベストプラクティスの記事をCodexに渡して、Codex自身にGoalの内容を改善させるのがいいよ、という話もありました。

「Codexに仕事をさせる前段階からCodexを使うという発想をもっと持ってね」という視点をよりもっていこうと思います、確かに自分はプロンプトを書くところは結構自分でやってしまっているなと思いました。

Codex on BedrockでSDLCを自動化する

SDLCをエージェントで回していく例として、以下が紹介されていました。

Software Factory
- AIエージェントを労働者に見立てて、人間がプロセスを設計することでソフトウェアを継続的かつ自律的に量産する開発体制・仕組み
Perf Factory
- 本番の性能劣化を修正に繋げる
- アラート → 調査 → 修正 → PR
Sevbot
- 障害調査で起動して、対応判断を支援する
PR Babysitter
- PR作成後の修正ループを継続する
- PRの状態を監視させて、マージ状態までを搬送する

Perf Factoryの話は、エンジニアがプロンプトを書く必要ある？が起点になっている感じがしました。
例えば営業やカスタマーサポートが修正点を投げたら自動でPRの作成まで行って、エンジニアはレビューだけ行うような仕組みとかのことかなと思っています。

▪️AWSからの紹介

なんでBedrock上でOpenAIのモデルを使うのか

IAMなどの権限管理がそのまま使える
PrivateLinkなどのセキュリティ対策もそのまま乗せられる
色んなモデルを一つの窓口で管理できる
推論を行う地域を指定できる
Bedrockから使う場合は学習に利用されない
請求の一元化ができる

現状はCodingよりもApplicationの中のAIの機能としてBedrockを利用しているケースがほとんどな気がしますが、モデルの切り替えが簡単にできるのは結構Applicationの中に入れるとテストとかしやすくて助かる理由の一つかなと思います。

AWS経由で利用するためにコードの変更は不要で、2行足すだけでいいという話もありました。
手順はAWSのスタートアップブログにまとまっています。

~/.codex/config.toml に以下を追加するだけです。

~/.codex/config.toml

model_provider = "amazon-bedrock"
model = "openai.gpt-6.1-sol"

AWS CLIで認証済みであれば追加の作業は不要で、Codex上で /status を叩いて Providerに amazon-bedrock と表示されていればOKです。

実際にハンズオンでやってみてとても簡単に出来ました。

AIのセキュリティと責任共有モデル

生成AIでも責任共有モデルとしての考え方は他のサービスと同じ
物理、可用性、暗号化などはAWSが担う
AWSの人もデータには触れませんよなどの説明がありました

詳しくは公式の情報を参照してください

AWS Knowledge MCP Server

ドキュメント情報を参照できる
最新サービスなども正しい情報を与えられる

AWS MCP Server

上記のMCP Serverに加えて、API実行まで担える
ただ登録などの設定は必要になる
MCPのエージェントに渡す権限は狭くするように気をつける

作ったAIエージェントをそのままAWSで動かす

Strands AgentsやOpenAI Agents SDKで作って、AgentCore Runtime（マネージドなサーバーレス）やFargateに乗せて、自分のプロダクトから呼び出すという流れが紹介されていました。

サーバーレス大好きなので、基本はサーバーレスらしいAgentCore Runtimeを今度使ってみようと思います

▪️参加して感じたこと

Lunaなどのローティアのモデルも実装なら使えるかもしれない

正直、Lunaのようなローティアのモデルはほとんど使おうという発想がありませんでした。
Claudeでも計画とかだけFableを使用して、他は基本Opusでいいやになってしまっていて、モデルの使い分けはあまりしていなかったです。

セッションの中で、OpenAIが提示するおすすめの一例として以下が紹介されていました。

設計：Sol Medium
実装：Luna Max
レビュー：Sol Medium
修正：Sol Medium（個人的にはここも Luna Max にしようかなと思ってます）

最初は、LunaをMaxで使うのって結構劣化するんじゃないの？と思っていました。

ただ話を聞いていると、計画がしっかり立っている状態のコード生成は、かなり任せられるレベルになってきているそうです。
モデルの性能を抑えてEffortを少し強化するのが、コスパ的にベストプラクティスになるケースもありそうでした。
品質のある程度の部分はハーネスで担保する、という考え方のようです。

設計とレビューはちゃんと考えられるモデルに任せて、決まったものを作る部分は安いモデルにしっかり考えさせる、という分け方は実装では有効に使えるかもしれないなと思いました。

Claudeでも、全部Opusでいいやになってしまっているので、ちゃんと分けて試してみようと思います。

ちなみにCodexで/modelを実行してGPT-6.1 Solを選んだ時、EffortのデフォルトがLowになっていました。
先ほど紹介したOpenAIのオススメの構成ではMediumで紹介されていたので、一旦Mediumにしています。

SDLCをAWSで統括的にやろうという発想が無かった

自分の中では、BedrockはアプリケーションにAIの機能を組み込む時に使うもので、開発プロセスとは別物という認識でした。
コーディングエージェントはそれぞれのサービスで契約して使うもので、AWSは本番環境を置く場所、という感じです。

今回の話を聞いて、以下が全部AWSの中で繋がるんだなと気づきました。

コーディング：Codex on Bedrock（IAM / SSOで認証、請求もAWSにまとまる）
運用・障害対応：Perf FactoryやSevbotのように、アラートや障害を起点にエージェントが調査してPRまで出す
エージェントの実行基盤：Bedrock Managed AgentsやAgentCore Runtime
AWSの操作：AWS MCP Server

本番環境もモニタリングもAWSにあるなら、開発のエージェントもそこに置いた方が、権限やネットワーク、ログ、請求をまとめて管理できます。
実装だけ速くなっても他の工程が詰まるという話とも繋がっていて、SDLCをAWSで統括的にやるという発想はこれまで無かったので新鮮でした。

いきなり全部は難しいので、まずはPR Babysitterのような小さいところから試してみたいと思います。

その他

AWSの新オフィスはとてもきれいでした
リンゴジュースが異次元の美味しさでした
最後のハンズオンで作ったものを発表する会では、作り込まれた発表資料や色んな外部サービスとのインテグレーション、MCP化まで見せていただけて、流石だなと思いました

まとめ

Codex on Bedrockは設定2行で使い始められて、IAMやPrivateLink、請求の一元化といったAWSの仕組みにそのまま乗せられるのが良いなと思いました。

個人的には、ローティアのモデルを実装で使ってみることと、SDLCをAWSでまとめて回すことの2つが今回の収穫でした。
どちらもまだ試せていないので、実際に使ってみようと思います！