9月24日、AWSが「Use open weight models as your AI coding agent with Amazon Bedrock」と題した記事を公開した。この記事では、Amazon BedrockのオープンウェイトモデルをターミナルネイティブなAIコーディングエージェント「OpenCode」と組み合わせ、データをAWSアカウント内に留めたまま運用する方法について詳しく紹介されている。

GitHub CopilotやCursorのようなAIコーディングツールは急速に普及しているが、いずれも「コードをサードパーティのAPIに送信する」「モデルプロバイダーにロックインされる」「使用量にかかわらずシート課金が発生する」という問題を抱える。特にデータの所在地（データレジデンシー）要件がある企業にとって、この構造は採用の壁になる。

本記事はその問題を解消する構成として、Amazon Bedrock × OpenCodeの組み合わせを提示している。

OpenCodeとは何か

OpenCodeはGo製のオープンソース・ターミナルAIコーディングエージェントだ。ファイルの読み書き、シェルコマンドの実行、Language Server Protocol（LSP）を通じたプロジェクト構造の把握が可能で、75以上のLLMプロバイダーに接続できる。Amazon Bedrockもその一つだ。

インストールは1行で完了する：

curl -fsSL https://opencode.ai/install | bash

npmやHomebrewでも導入できる。

なぜAmazon Bedrockをバックエンドに使うのか

Bedrockを使う最大の利点はデータがAWSアカウントの外に出ない点だ。プロンプトもレスポンスもコードも、すべて自分のアカウント内で処理される。IAMポリシー、CloudTrailのログ記録、PrivateLink接続、暗号化といったエンタープライズセキュリティ統制がそのまま適用される。

コスト面では3つの料金ティアが用意されている：

• Priority：レイテンシ重視の本番ワークロード向け
• Standard：オンデマンドのトークン従量課金
• Flex：可変レイテンシを許容する代わりにStandardより50%安い

デフォルト上限は毎分1億トークン、毎分1万リクエスト。チームでのスケールアップに対応できる容量設計になっている。

また、McKinseyの2025年レポートによると、76%の組織がオープンソースAIの利用を増やす予定で、AIの先進的採用者はオープンウェイトモデルを使う割合が40%高いという。コーディング用途でのオープンウェイトへのシフトは業界全体のトレンドでもある。

3モデルを使い分けるマルチモデルワークフロー

本記事の核心は、タスクの性質ごとに最適なモデルを自動で振り分ける設定だ。opencode.jsonに以下を記述するだけで実現できる：

{
  "$schema": "https://opencode.ai/config.json",
  "model": "amazon-bedrock/us.openai.gpt-oss-120b-1:0",
  "agent": {
    "plan": {
      "model": "amazon-bedrock/global.moonshotai.kimi-k3"
    },
    "build": {
      "model": "amazon-bedrock/us.nvidia.nemotron-super-3-120b"
    }
  }
}

記事では以下の3モデルを用途別に使い分けている：

Kimi K3は推論強化型モデル（元記事での表現はextended thinking / reasoning model）で、reasoning_configをlow/high/maxで指定することで推論の深さとレイテンシをトレードオフできる。コンテキストウィンドウは100万トークンで、数万行規模のコードベース全体をロードできる水準だ。

OpenAI GPT-OSS 120Bは、Amazon Bedrockを通じて提供されるオープンウェイト版のモデルで、デフォルトの汎用コーディングエージェントとして機能する。複数ファイルにまたがる実装のような、幅広いコーディングタスクに向いている。

Nemotron 3 Super 120BはMixture-of-Experts（MoE）アーキテクチャを採用し、1200億パラメータのうちトークンごとに120億パラメータのみを活性化する。NVIDIAによれば最大7倍のスループット向上が報告されており、大量生成やバッチ処理のような高スループットが求められるワークフローに適している。

3モデルの使い分けの判断軸を整理すると、「何を問うか」「どれだけ大きなコンテキストが必要か」「どのくらいの生成量が求められるか」という3点に帰着する。計画・分析フェーズのようにステップを丁寧にトレースしたい場合はKimi K3、実装フェーズで複数ファイルを横断する生成はGPT-OSS 120B、CIパイプラインへの組み込みなど大量・反復的な生成はNemotron 3 Super 120Bという棲み分けだ。セッション中にモデルを切り替えたい場合は/modelsコマンドを使えばよい。

実際の使用例

記事では具体的な2つのユースケースが示されている。

複雑な実装の生成（GPT-OSS 120B）：FastAPIとDynamoDBを使ったイベントソーシング + CQRSのオーダーサービスを、CDKインフラ込みで生成する例。モデルはハンドラー、イベントストア、プロジェクション、CDKスタックをローカルのファイルシステムに直接書き出す。複数ファイルを横断する生成においてもコンテキストの一貫性が保たれることが示されている。

分散デッドロックの診断（Kimi K3）：Step Functionsのワークフローが負荷時に約2%の確率でハングする問題の分析例。@ファイル名記法でローカルコードをコンテキストとして渡すと、Kimi K3が並行実行パスをトレースして原因と修正案を提示する。推論強化型モデルの特性が、ステップを追った原因特定に活きるユースケースだ。

生産環境での採用事例

記事ではEthara.AIがこのアーキテクチャを本番環境に採用していることも紹介されている。マルチエージェントオーケストレーションと組み合わせて、AIエンジニアリングおよびリサーチワークフローの大規模運用に活用しているという。具体的には、複数のエージェントが並列で動作する構成においても、Bedrockのデフォルト上限（毎分1億トークン・毎分1万リクエスト）が十分なキャパシティとして機能しているとされており、チームスケールでの運用実績として参考になる。

なお、オープンウェイトモデルの性能比較にはArtificial Analysis Coding Indexが参考になる。SWE-Bench、Terminal-Bench、SWE-Atlasをまとめたコンポジットベンチマークで、コスト・レイテンシとあわせて比較できる。

詳細はUse open weight models as your AI coding agent with Amazon Bedrockを参照していただきたい。