Kiro の GPT-5.6 が 1M トークンのコンテキストウィンドウに対応。新しいクレジット倍率も確認してみた

Kiro の GPT-5.6 が 1M トークンのコンテキストウィンドウに対応。新しいクレジット倍率も確認してみた

Kiro の GPT-5.6 が、最大 1M トークンのコンテキストウィンドウをサポートしました。一方で、272K トークンを超えるリクエストには新しいクレジット倍率が適用されます。Kiro CLI を使い、長い入力を扱えることと、境界前後のクレジット消費の変化を確認しました。

はじめに

2026 年 9 月 14 日、Kiro のアップデートで、GPT-5.6 Sol / Terra / Luna のコンテキストウィンドウが、従来の 272K トークンから 1M トークンへ拡張されました。

https://kiro.dev/changelog/models/gpt-5-6-1m-context-window/

同時に、GPT-5.6 のクレジット倍率が改定されています。

本記事では、GPT-5.6 Luna で 272K トークンを超える入力を扱えることを確認しました。あわせて、272K トークンの境界前後における 4 モデル(GPT-5.6 Luna、Claude Sonnet 5、Claude Opus 5、Auto)のクレジット消費の傾向を測定しました。

GPT-5.6 の 1M トークンサポート

Kiro CLI の --list-models でモデル情報を確認したところ、GPT-5.6 Sol / Terra / Luna はいずれも 1M トークンのコンテキストウィンドウが有効になっていました。

`--list-models` の表示値
kiro-cli chat --list-models -f json

見やすさのため model_namedescription を省き、1 行 1 件に整形しています。

{"model_id":"gpt-5.6-sol","context_window_tokens":1000000,"rate_multiplier":4.4,"rate_unit":"Credit"}
{"model_id":"gpt-5.6-terra","context_window_tokens":1000000,"rate_multiplier":2.2,"rate_unit":"Credit"}
{"model_id":"gpt-5.6-luna","context_window_tokens":1000000,"rate_multiplier":1.1,"rate_unit":"Credit"}

GPT-5.6 のクレジット倍率

1M トークンのコンテキストウィンドウをサポートする Kiro の GPT-5.6 では、入出力トークン数が 272K を境にクレジット倍率が変化します。

モデル 272K 以下 272K 超
GPT-5.6 Sol 4.4x 8.8x
GPT-5.6 Terra 2.2x 4.4x
GPT-5.6 Luna 1.1x 2.2x
Claude Opus 5 2.2x 2.2x
Claude Sonnet 5 1.3x 1.3x
Auto 1.0x 1.0x

272K を超えると倍率が変わるのは、現時点では GPT-5.6 ファミリーだけです。

検証方法

botocore の Python ソースコードから、480KB、1200KB、1400KB の測定用入力ファイルを作成しました。Kiro CLI をヘッドレスで実行し、これらを同じプロンプトとともに渡してソースコード全体を要約させ、コンテキスト消費率とクレジット消費を確認しました。

測定環境

  • Kiro CLI 2.21.4
  • botocore 1.43.33 / Python 3.14.7
  • モデル:GPT-5.6 Luna / Claude Sonnet 5 / Claude Opus 5 / Auto
  • effort:デフォルト(Claude Opus 5 のみ medium

入力データの準備

インストール済みの botocore に含まれる *.py をパス順に連結し、先頭から 480,000 文字、1,200,000 文字、1,400,000 文字を切り出しました。以降、それぞれを 480KB、1200KB、1400KB と表記します。

Luna のコンテキスト消費量が 272K トークンの境界をまたぐように、この 3 つのサイズを選びました。

make-inputs.py の全文
#!/usr/bin/env python3
"""botocore のソースコードから決まったサイズの入力ファイルを作る。

同一の入力を複数モデルへ渡してコンテキスト消費とクレジット消費を比べるための素材。
ファイル一覧はパス順に固定し、先頭から必要な文字数で切るだけなので、
同じ botocore バージョンなら誰が実行しても同じ内容になる。
"""
import pathlib
import sys

import botocore

ROOT = pathlib.Path(botocore.__file__).parent
SIZES = {"input-480k.txt": 480_000, "input-1200k.txt": 1_200_000, "input-1400k.txt": 1_400_000}

def build_corpus(limit: int) -> str:
    parts: list[str] = []
    total = 0
    for path in sorted(ROOT.rglob("*.py")):
        try:
            text = path.read_text(encoding="utf-8")
        except (UnicodeDecodeError, OSError):
            continue
        header = f"\n===== FILE: botocore/{path.relative_to(ROOT)} =====\n"
        parts.append(header + text)
        total += len(header) + len(text)
        if total >= limit:
            break
    return "".join(parts)

def main() -> int:
    outdir = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else ".")
    outdir.mkdir(parents=True, exist_ok=True)
    corpus = build_corpus(max(SIZES.values()))
    print(f"botocore {botocore.__version__} at {ROOT}")
    print(f"corpus: {len(corpus)} chars")
    if len(corpus) < max(SIZES.values()):
        print("ERROR: corpus is smaller than the largest target size", file=sys.stderr)
        return 1
    for name, size in SIZES.items():
        body = corpus[:size]
        (outdir / name).write_text(body, encoding="utf-8")
        print(f"{name}: {len(body)} chars / {len(body.encode('utf-8'))} bytes")
    return 0

if __name__ == "__main__":
    raise SystemExit(main())

入力ファイルの先頭は次のようになります。各ファイルのあいだに ===== FILE: ... ===== を挟んでいます。

===== FILE: botocore/__init__.py =====
# Copyright (c) 2012-2013 Mitch Garnaat http://garnaat.org/
# Copyright 2012-2014 Amazon.com, Inc. or its affiliates. All Rights Reserved.

Kiro CLI のヘッドレス実行

プロンプトと入力ファイルは標準入力から渡しました。

PROMPT='以下は botocore のソースコードです。このコード全体が何をするものか、日本語3行で要約してください。各行は1文にしてください。'

{ printf '%s\n\n' "$PROMPT"; cat "$INPUT_DIR/$input"; } \
  | (cd "$work" && timeout 1200 kiro-cli chat --no-interactive --model "$model") >>"$log" 2>&1

要約に使用したセッションを --resume で再開し、/context の表示からコンテキスト消費率を取得しました。

(cd "$work" && timeout 180 kiro-cli chat --no-interactive --resume --model "$model" "/context") >>"$log" 2>&1

結果

コンテキスト消費率

同じ入力でも、コンテキスト消費率はモデルごとに異なりました。

モデル 480KB 1200KB 1400KB
Luna 11.2%(112K) 26.3%(263K) 30.7%(307K)
Opus 5 19.0%(190K) 43.5%(435K) 50.6%(506K)
Sonnet 5 18.9%(189K) 43.5%(435K) 50.6%(506K)
Auto 18.8%(188K) 43.4%(434K) 50.5%(505K)

括弧内は、/context の表示(0.1% 刻み)から換算したトークン数の概算です。

クレジット消費

モデル 480KB 1200KB 1400KB
Luna 2.05 4.82 11.23
Opus 5 1.40 3.07 3.57
Sonnet 5 0.82 1.80 2.10
Auto 0.61 1.39 1.61

クレジット消費は倍率だけで決まらず、生成トークン数、内部の思考量、トークナイザの違いなどによっても変わります。

272K 超過時のクレジット

Luna のクレジット消費は、1200KB で 4.82、1400KB で 11.23 でした。換算トークン数は 263K から 307K へと約 1.17 倍になった一方で、クレジットは約 2.33 倍になりました。

クレジットの増加倍率を換算トークン数の増加倍率で割ると、2.33 ÷ 1.17 ≒ 2.0 です。今回の測定では、272K を超えると入力量あたりのクレジットが約 2 倍になることを確認できました。

Claude 系と Auto

Opus 5、Sonnet 5、Auto は、最大 506K 相当までの範囲で、1K トークンあたりのクレジットがほぼ一定でした。今回の測定範囲では、Luna のような 272K 付近での倍率変化は見られませんでした。

出力

4 モデルの要約は要点が一致しており、違いは主に書き方でした。今回のプロンプトでは、Luna と Auto は簡潔で、Opus 5 と Sonnet 5 はより詳しく説明しました。

今回測定したのは、長い入力に対する 3 行の要約だけであり、モデルの性能差は評価していません。

480KB入力に対する各モデルの出力

Luna

AWSサービスのモデルや設定を読み込み、各サービス向けのクライアントを動的に生成します。
エンドポイント解決、認証情報管理、リクエストのシリアライズ、圧縮、再試行、AWS署名を処理します。
HTTP通信やS3などのサービス固有機能を提供し、APIクライアントやパラメータ、例外、ドキュメントも生成します。

Claude Opus 5

botocore は AWS の各サービス API を Python から呼び出すための低レベル SDK 基盤であり、JSON のサービス定義モデルを読み込んでクライアントとそのメソッドを動的に生成します。

この抜粋には、クライアント生成と設定解決(client.py/args.py/config.py/configprovider.py/configloader.py)、認証情報の取得と自動更新(credentials.py)、SigV2/V3/V4/SigV4a・ベアラー等による署名(auth.py/crt/auth.py)、HTTP リクエストの組み立てと送信(awsrequest.py/compress.py)が含まれます。

さらに、エンドポイントの動的ディスカバリ(discovery.py)、リトライやチェックサム等の挙動を制御する設定群、API ドキュメント文字列を生成する docs パッケージといった周辺機能も備え、boto3 や AWS CLI の土台として機能します。

Claude Sonnet 5

botocoreはAWS SDK for PythonおよびAWS CLIの基盤となるコアライブラリで、サービスモデル(JSON定義)からクライアントを動的生成し、リクエストの構築・シリアライズ・署名(SigV2/V4/V4a/S3Express等)・送信・レスポンス解析までを担う。
認証情報の取得(環境変数、共有設定ファイル、IMDS、AssumeRole、SSO、コンテナ、aws loginなど多数のプロバイダ)、エンドポイント解決、リトライ、圧縮、ユーザーエージェント生成、ドキュメント生成といった横断的な機能も内包する。
提示されたファイル群は__init__、args、auth、awsrequest、client、compat、compress、config、configloader、configprovider、context、credentials、crt、discovery、docsなど、これらの責務ごとにモジュール分割された実装コードである。

Auto

botocore は AWS の各サービスに HTTP リクエストを送るための低レベル Python SDK であり、サービス定義モデルから動的にクライアントとメソッドを生成する。

認証情報の解決(環境変数・共有ファイル・SSO・IAM ロールなど)や SigV2/V3/V4/V4a・ベアラートークンといった各種方式でのリクエスト署名を担当する。

さらに、設定の階層的な読み込み、エンドポイント解決、リトライ・圧縮・エンドポイント探索などの処理と、API リファレンス文書の自動生成機能を提供する。

Bedrock の GPT-5.6 料金

Amazon Bedrock の GPT-5.6 では、272K トークンを境に入力単価と出力単価が切り替わります。272K トークンを超えると、入力単価は 2 倍、出力単価は 1.5 倍になります。

モデル 272K 以下の入力 272K 以下の出力 272K 超の入力 272K 超の出力
GPT-5.6 Sol $4.40 $22.00 $8.80 $33.00
GPT-5.6 Terra $2.20 $13.20 $4.40 $19.80
GPT-5.6 Luna $0.22 $1.32 $0.44 $1.98

表の料金は、Standard ティアのリージョン内推論における 100 万トークンあたりの金額です。出力単価の上昇倍率は入力単価より小さいものの、出力単価そのものは入力単価より高く設定されています。

Kiro のクレジット倍率と Bedrock の入出力単価は、いずれも同じ 272K トークンを境に切り替わる仕様でした。

https://aws.amazon.com/bedrock/pricing/

まとめ

Kiro の GPT-5.6 のコンテキストウィンドウが 1M トークンへ拡張されたことで、従来よりもコンテキスト不足に陥りにくくなりました。今回の測定では、同じ botocore の入力に対して、GPT-5.6 Luna は Claude 系モデルよりもコンテキスト消費率が低く、より大きな入力を扱える余地があることも確認できました。

一方、拡張に伴うクレジット倍率の見直しにより、GPT-5.6 系の費用対効果については改めて検討する必要があります。
クレジット倍率に加えて、Kiro IDE や CLI の実行後に表示される推定クレジット消費も参考にしながら、タスクに適したモデルを選ぶことをおすすめします。


AI白書2026 配布中

クラスメソッドが独自に行なったAI診断調査をもとに、企業のAI活用の現在地を調査レポートとしてまとめました。企業規模別の活用度傾向に加え、規模を超えてAI活用を進める企業に共通する取り組みまで、自社の現在地を捉えるためのヒントにぜひ。

AI白書2026

無料でダウンロードする

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事