1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Kimi K3がAmazon Bedrockに登場:1MコンテキストとExplicit Prompt Cachingをどう使うか

1
Posted at

AWSは2026年9月18日、Moonshot AIの「Kimi K3」をAmazon Bedrockで提供開始した。Kimi K3は、テキストと画像を入力できるopen-weightモデルで、100万トークンのコンテキストウィンドウを持つ。AWSは、大規模なコードベースや文書を扱う長時間のコーディング、知識処理を主な用途として挙げている。[1][2]

Moonshot AIによれば、Kimi K3の総パラメータ数は2.8兆で、Kimi K2に対するスケーリング効率は約2.5倍に改善したという。これらはモデル提供元による説明であり、実際の業務での性能は対象タスクやプロンプト、利用するツールを含めて評価する必要がある。[1]

Amazon Bedrock上のKimi K3には、モデルそのものの規模とは別に、エージェントを構成するときに使いやすい機能がそろっている。Responses APIとChat Completions API、Tool Calling、Structured Outputs、ストリーミング、Prompt Cachingを利用できるためだ。[2]

Bedrock版Kimi K3の仕様

Amazon Bedrockのモデルカードに記載されている主な仕様は次のとおりである。[2]

項目 Kimi K3 on Amazon Bedrock
コンテキストウィンドウ 1M tokens
入力 Text / Image
出力 Text
Responses API 対応
Chat Completions API 対応
Converse API 対応
Invoke API 対応
Response Streaming 対応
Tool Calling 対応
Structured Outputs 対応
Implicit Prompt Caching 対応
Explicit Prompt Caching Responses / Chat Completionsで対応
Knowledge Bases 非対応
Video入力 非対応

100万トークンのコンテキストは、大量の情報を一度に入力できることを意味する。ただし、100万トークンを毎回入力する使い方が適切とは限らない。入力が増えれば推論時間と料金も増えるため、固定された文脈を再利用する処理ではPrompt Cachingと組み合わせる方が合理的である。

1MコンテキストがCoding Agentで使いやすい理由

Coding Agentは、一度コードを生成して終わる処理よりも多くの情報を保持する。リポジトリの構成、実装済みのコード、仕様書、テスト結果、ツールの実行結果、過去に行った修正などを参照しながら、次の操作を決めるためだ。

たとえば大規模な改修では、次のような処理が繰り返される。

リポジトリを調査
      ↓
関連コードを特定
      ↓
修正
      ↓
テスト実行
      ↓
ログを解析
      ↓
追加修正
      ↓
レビュー

コンテキストが不足すると、途中までに確認した設計上の制約やファイル間の関係を再取得する必要が生じる。1Mコンテキストは、その再取得を減らせる余地を広げる。

一方で、リポジトリ全体を無条件に投入すれば精度が上がるとは限らない。無関係な情報が増えれば、モデルが参照すべき箇所も増える。検索やファイル選択を行うエージェント側の設計は、長いコンテキストを利用する場合でも残る。

Explicit Prompt Cachingが長時間タスクの料金を変える

長時間動作するエージェントでは、毎回変化する情報より、繰り返し送る固定情報の方が大きくなる場合がある。システムプロンプト、リポジトリの共通ルール、ツール定義、参照文書などがその例である。

Kimi K3は、Amazon Bedrock上のopen-weightモデルとして初めてExplicit Prompt Cachingに対応した。Responses APIまたはChat Completions APIでは、1,024トークン以上の再利用可能なプレフィックスにキャッシュ境界を設定できる。書き込まれたキャッシュは少なくとも30分保持され、後続リクエストが一致すればCache Readとして処理される。[1][2]

処理の形は次のようになる。

固定コンテキスト
  ├─ システムプロンプト
  ├─ 開発ルール
  ├─ ツール定義
  └─ 参照文書
        ↓
  Prompt Cache
        ↓
  ┌───────────┐
  │ Request 1 │ + 個別の指示
  │ Request 2 │ + テスト結果
  │ Request 3 │ + 修正内容
  └───────────┘

Global CRISのStandard料金では、通常のInputが100万トークンあたり3.00ドルなのに対し、Cache Readは0.30ドルである。キャッシュへの書き込みは3.75ドルなので、一度しか使わない情報をキャッシュすると通常入力より高くなる。複数回再利用する固定コンテキストを選ぶ必要がある。[2][3]

料金はKimi K2.5より高い

Kimi K3のStandard Tierは、Global CRISとUS CRISで料金が分かれている。[2][3]

推論方式 Input / 1M tokens Output / 1M tokens Cache Read Cache Write
Global CRIS $3.00 $15.00 $0.30 $3.75
US CRIS $3.30 $16.50 $0.33 $4.125

Kimi K3はPriorityとFlexのService Tierにも対応する。PriorityはStandardの1.75倍、Flexは0.5倍である。ただし、Service Tierを指定できるのはResponses APIとChat Completions APIで、Converse APIとInvoke APIはStandardのみとなる。[2]

比較対象として、東京リージョンのKimi K2.5はInputが0.72ドル、Outputが3.60ドルである。[3] Kimi K3は単価が大きく上がっているため、短い問い合わせや単純な生成処理まで一律にK3へ移す構成は料金面で不利になりやすい。

モデルを分けて使うなら、短い処理を低価格のモデルへ送り、大量の文脈や長時間のツール実行が必要な処理だけをKimi K3へ送る構成を取りやすい。

OpenAI互換APIから呼び出せる

Kimi K3はAmazon Bedrockのbedrock-runtimeエンドポイントから、OpenAI互換のResponses APIとChat Completions APIで呼び出せる。モデルIDはGlobal Cross-Region Inferenceを使う場合、global.moonshotai.kimi-k3である。[1][2]

AWS公式ブログでは、OpenAI Python SDKを使った例が示されている。

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

region = "us-west-2"

client = OpenAI(
    api_key=provide_token(region=region),
    base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
)

response = client.responses.create(
    model="global.moonshotai.kimi-k3",
    input="このリポジトリの構成を説明してください。",
)

print(response.output_text)

OpenAI互換のインターフェースを採用しているため、アプリケーション側でプロバイダーを抽象化している場合は既存コードを流用しやすい。ただし、各プロバイダーで完全に同一の挙動が保証されるわけではない。Tool Calling、Reasoning、画像入力、キャッシュなど、モデル固有の機能を使う箇所は実装と動作確認が必要になる。

Converse APIには既知の制約がある

Kimi K3はConverse APIでも呼び出せるが、AWSは可能な場合にはOpenAI互換のResponses APIまたはChat Completions APIを使うよう案内している。[2]

理由の一つは、過去ターンのreasoning contentを含めたマルチターンリクエストでInternalServerExceptionが発生する既知の制約である。この挙動は、Converse APIを標準利用するLangChainやStrands Agentsの構成にも影響する可能性がある。Converse APIではPDFやHTMLなどの添付文書にも制限がある。[2]

したがって、Kimi K3を使った新規エージェントでは、利用するフレームワークがどのBedrock APIを呼び出すかまで確認した方がよい。「Amazon Bedrockに対応している」という事実だけでは、Kimi K3の全機能を利用できるとは限らない。

東京から使えても、東京In-Regionではない

Kimi K3はIn-Region推論ではなく、US GeoまたはGlobal Cross-Region Inferenceで提供されている。東京リージョンap-northeast-1からGlobal profileを呼び出すことはできるが、推論処理を東京リージョン内だけに固定する構成ではない。[2][4]

Global profileのモデルIDは次のとおりである。

global.moonshotai.kimi-k3

AWSによれば、Global Cross-Region Inferenceは、リクエストを対応する商用AWSリージョンへルーティングする。データレジデンシー要件によって処理地域を限定する必要があるシステムでは、Global profileを採用できるかを先に確認する必要がある。[1][2]

一方、AWSはBedrock上のopen-weightモデルへの推論データについて、モデル提供元へ共有せず、基盤モデルの学習にも使用しないとしている。Kimi K3の推論リクエストにはZero Data Retentionが適用され、AWSのオペレーターもプロンプトと応答へアクセスできないZero Operator Accessを提供すると説明している。[1]

データがモデル提供元へ渡らないことと、処理リージョンを一地域に固定できることは別の要件である。企業利用では、この二つを分けて確認する必要がある。

どの処理をKimi K3へ任せるか

Kimi K3の仕様は、大量の固定コンテキストを持ちながら複数回の推論を行う処理と組み合わせやすい。

たとえば、次のような処理が候補になる。

  • 大規模リポジトリを横断するコード調査と改修
  • テストやシェルを繰り返し実行するCoding Agent
  • 多数の設計資料とコードを同時に参照する技術調査
  • スクリーンショットを確認しながらUIを修正するエージェント
  • 長い参照文書を維持したまま複数のTool Callを行う業務エージェント

反対に、短いFAQ、単発の要約、簡単な分類などは、1MコンテキストやExplicit Prompt Cachingの利点を使わない。そうした処理では、Kimi K2.5を含む低価格なモデルも比較対象になる。

Kimi K3の採用判断では、モデル単体のベンチマークだけでなく、1回のタスクで何トークンを再送するか、何回モデルを呼ぶか、Prompt Cacheが何回再利用されるかまで測る必要がある。長時間エージェントでは、この呼び出し方が料金とレイテンシーを大きく左右する。

Kimi K3を試すときの確認項目

検証では、モデルの回答精度だけを測るとシステム全体の特性を見落とす。少なくとも次の項目を同じタスクで比較したい。

  1. 必要なファイルや文書を正しく参照できるか
  2. 長いタスクで前の判断を維持できるか
  3. Tool Callingを連続して実行したときに破綻しないか
  4. Prompt Cacheのヒット率がどの程度になるか
  5. 1タスクあたりのInput、Output、Cache Read、Cache Writeの料金
  6. StandardとFlexで許容できるレイテンシーになるか
  7. 利用するフレームワークがResponses / Chat Completionsを選択できるか
  8. Cross-Region Inferenceが組織のデータ処理要件を満たすか

この計測を行えば、「1Mコンテキストを持つ高性能モデルだから採用する」という判断ではなく、対象ワークロードに対する処理時間、品質、料金の組み合わせで比較できる。

おわりに

Amazon Bedrock版Kimi K3は、100万トークンのコンテキスト、画像入力、Tool Calling、Structured Outputs、OpenAI互換API、Explicit Prompt Cachingを一つのモデルで利用できる。特に、固定された大きな文脈を保持しながら複数回の推論を行うCoding Agentや業務エージェントでは、Prompt Cachingを含めた設計を試す価値がある。

一方、Kimi K2.5より単価は高く、Converse APIには既知の制約があり、Kimi K3は東京In-Region推論にも対応していない。モデルを選ぶときは、最大コンテキスト長だけでなく、API、キャッシュ、Service Tier、データレジデンシーまで含めて比較する必要がある。

Kimi K3を「すべての処理を置き換えるモデル」と考えるより、大規模な文脈と長時間のエージェント処理を必要とするタスクへ割り当てる方が、Bedrockのマルチモデル構成を利用しやすい。


参考資料

  1. AWS Blog: Introducing Kimi K3 on Amazon Bedrock
  2. Amazon Bedrock User Guide: Kimi K3
  3. Amazon Bedrock Pricing
  4. Amazon Bedrock: Regional availability by models

情報は2026年9月19日時点。料金、提供リージョン、API仕様は変更される可能性があるため、導入時にはAWS公式ドキュメントを確認してください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?