AI・自動化

AWS Graviton5がGA｜エージェントAI向け設計で最大25%性能向上——「LLMのAPI代」だけがAIコストではない

2026年6月11日12分で読める

READ LATER / FREE NEWSLETTER

今すぐ読み切れなくても、判断材料を逃さない

あとで読む保存は登録不要。無料メルマガはメール1項目で仮登録でき、この記事に近いテーマの判断チェックを受け取れます。

保存はこの端末だけ・メール不要／メルマガは営業電話なし・確認メール承認後に開始

GXO COLUMN

AI・自動化

結論：AIエージェント本番化のコスト設計で「実行基盤のCPU選定」を無視できなくなった

AWSは2026年6月10日、独自設計CPUGraviton5を搭載したAmazon EC2のM9gおよびM9gdインスタンスの一般提供（GA）を開始した。AWSの公表によれば、M9gインスタンスのコンピュート性能は前世代比で最大25%向上し、ウェブアプリケーションで35%、機械学習推論で35%、データベースで30%の高速化を実現するという。

注目すべきは位置づけだ。AWSはGraviton5を**「エージェントAIの要求——リアルタイム推論・コード生成・マルチステップのタスクオーケストレーション——のために設計した」**と明言した。エージェントの本番運用では、LLMのAPI呼び出しの裏でツール実行・データ取得・検証といった大量の並行処理が汎用CPU上で走る。AI運用コストの正体はAPI代だけでなく、この「足回り」のインフラ費を含めた総額であり、その足回りの価格性能比が世代交代したのが本質だ。

なおよく語られる「Graviton移行で3〜4割のコスト改善」は、x86からの移行で報告されてきた一般的な知見・ワークロード依存の経験則であり、Graviton5で保証された削減率ではない。自社の削減幅は自社ワークロードでの計測でしか確定しない。

押さえるべき1点：AIエージェントの本番コスト試算に「LLM API費」しか入っていないなら、実行基盤・データ基盤・監視を加えて見直す必要がある。実行基盤・データ基盤・監視まで含めた総コストで、CPU世代と構成の選択肢を比較すること。

RETAIL & EC DX

実店舗とECの在庫分断、1本のOMSで解消しませんか？

POS／自社EC／モールを統合するオムニチャネル基幹。同規模小売・D2Cの概算費用・導入期間・事例をその場で確認できます。

OMS／ヘッドレスECの概算を見る

Graviton5の公表スペックとコストの読み方

AWSが公表している主な数値は次のとおり（いずれもAWS公式発表値）。

横にスクロールして確認できます

項目	公表値
コンピュート性能（M9g）	前世代比最大25%向上
ウェブアプリケーション	35%高速化
機械学習推論	35%高速化
データベース	30%高速化
コア数	1パッケージ192コア
L3キャッシュ	コアあたりGraviton4比2.6倍
GA対象インスタンス	M9g（汎用）/ M9gd（ローカルNVMeストレージ付き）

コスト面では、AWSの発表ページに顧客事例として、SiemensがGraviton4で他のAWSインスタンス比30%のコンピュートコスト削減を公表したことが掲載されている。削減できるかどうかは、ワークロードのCPUバウンド度合いとARM対応状況で決まる。

推論そのものはGPUや外部APIが担っても、エージェントのループを回す側——計画・ツール呼び出し・結果検証・リトライ——はCPU上の処理だ。並列数が増えるほど、この層のコストが効いてくる。

「AIのコスト」を見積もるときに落ちやすい3つの層

AI導入の稟議で「月額=LLM API費」とだけ書かれた試算は、本番運用で必ず破綻する。落ちやすいのは次の3層だ。

第一に実行基盤。オーケストレーション、RAGの検索・埋め込み、ツール実行サンドボックスなどが常時稼働するコンピュート費だ。Graviton5のような世代・アーキテクチャ選択で総額が変わる（参考：AI・クラウドコストの見積もり方）。

第二にデータ基盤。データの収集・整形・ベクトル化・更新のパイプラインは、モデルと独立に費用が発生し続ける。設計はデータ基盤構築サービスの領域だ。

第三に暴走の保険。エージェントは設計を誤るとループ・過剰呼び出しでコストが青天井になる。トークン予算・停止条件・監視はコスト暴走制御チェックリストで詳説している。

なおAWS利用企業は足元の塩漬け資産も見てほしい。2026年6月30日にはAmazon Linux 2のサポートが終了する。新CPUの検討と旧OSの放置が同居している環境は珍しくない。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

Graviton5移行・採用を検討する際の確認手順

ワークロードを「GPU/外部API」と「CPU実行層」に仕分けする——CPU側の月額が見えなければ比較は始まらない。
ARM（aarch64）対応を確認する——商用ミドルウェアやネイティブ依存ライブラリは個別確認が要る。
代表ワークロードでベンチマークを取る——公表値は条件付きの最大値。自社処理での実測が唯一の根拠になる。
単価×必要台数の総額で比較する——性能向上による台数削減まで含めて試算する。
コミット契約（Savings Plans等）との整合——消化計画と矛盾する移行は割引を失う。
移行の検証コスト自体を見積もる——CI/CDのマルチアーキテクチャ対応・回帰テスト工数を忘れると削減効果を食い潰す。

チェックの勘所：「新世代だから速い・安い」で一括移行を決めない。CPUバウンドでスケールしているワークロードから順に移し、実測で削減率を確定させてから横展開するのが定石だ。

稟議に入れるべきコスト項目

Graviton5の採用可否を判断する稟議では、単価表だけを比較しても意味がない。最低限、実行基盤、RAG検索、ジョブキュー、監視ログ、検証環境、CI/CD、障害時の冗長構成を分けて試算する必要がある。AIエージェントは小さな処理を多数回実行するため、ピーク時の並列数とリトライ回数がCPUコストを押し上げる。

また、ARM対応の確認は「アプリが起動する」だけでは足りない。ネイティブ拡張、商用ミドルウェア、監視エージェント、セキュリティ製品、バックアップ製品が同じアーキテクチャで動くかを確認する。ここを見落とすと、本番移行後に一部の運用機能だけがx86に残り、期待した削減効果が出ない。

よくある質問（FAQ）

Q. Graviton5に移行すれば本当に3〜4割安くなるのか？ A. 保証されない。「3〜4割」はx86からGraviton系への移行事例で報告されてきた一般的な経験則で、CPUバウンド度合い・ARM対応・台数削減効果に依存する。AWS掲載事例のSiemens30%削減もGraviton4・特定条件下の値だ。自社ワークロードでの実測が唯一の根拠になる。

Q. LLMを外部APIで動かしている場合も関係あるか？ A. ある。推論が外部でも、オーケストレーション・RAG検索・ツール実行・ログ処理は自社のコンピュート上で動く。エージェントの並列数が増えるほどこの層の費用が膨らむ。

Q. まだPoC段階の会社は何をすべきか？ A. 移行判断は不要だが、本番化の見積もりに「実行基盤・データ基盤・監視」の3層を含めた総コスト欄を作っておくべきだ。PoCのAPI費を12倍して年額にする試算は本番でほぼ確実に外れる。