▪️はじめに
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 に以下を追加するだけです。
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つが今回の収穫でした。
どちらもまだ試せていないので、実際に使ってみようと思います！