KiroのGPT-5.6が100万トークンに対応
KiroのIDE、CLI、Webで利用できるGPT-5.6のSol、Terra、Lunaが、100万トークンのコンテキストウィンドウに対応しました。
これにより、従来は複数回に分けたり、要約を挟んだりして扱っていた大規模なコードベース、長文の仕様書、長期間にわたるエージェントの対話履歴を、1回のリクエストに含めて処理できる可能性が広がります。
今回のポイントは、単に「大量のテキストを入力できる」ということではありません。AIコーディングツールが、個別のファイル単位ではなく、システム全体の関係性を踏まえて推論しやすくなる点にあります。
100万トークンで変わる開発現場
巨大なリポジトリの理解が容易になる
大規模なシステムでは、1つの変更が複数のサービス、ライブラリ、設定ファイル、テストコードに影響します。従来のように関連ファイルだけを選んでAIへ渡す方法では、呼び出し元やデータの流れを見落とすことがありました。
100万トークンのコンテキストを活用すれば、次のような調査を一度の依頼で実行しやすくなります。
- 認証処理がどのサービスから呼び出されているかを追跡する
- APIの定義と各クライアントの実装差分を調べる
- 共通ライブラリの変更による影響範囲を洗い出す
- 既存テストがカバーしていない分岐を特定する
- 複数サービスにまたがるエラーハンドリングを確認する
特に、開発に参加したばかりのエンジニアがリポジトリの構造を把握する場面で効果が期待できます。ファイルを個別に説明させるのではなく、「このシステムの主要な処理経路と責務の分担を説明してほしい」と依頼できるためです。
長期化したエージェント作業を継続しやすい
AIエージェントによる実装では、調査、設計、編集、テスト、修正という工程が何度も繰り返されます。対話が長くなると、過去の判断理由や未解決の課題を要約して引き継ぐ必要があり、その過程で重要な細部が失われることがあります。
大きなコンテキストウィンドウでは、過去のやり取り、実行結果、変更方針を同じセッションで保持しやすくなります。たとえば、次のような作業が考えられます。
- 既存実装と関連する仕様を調査する
- 変更方針と制約条件を整理する
- 複数ファイルを修正する
- テストや静的解析の結果を確認する
- 失敗した理由を過去の判断と照合して再修正する
ただし、コンテキストに残っていることと、AIがすべての情報を同じ精度で参照できることは同義ではありません。長い履歴を活用する場合も、現在の目的、変更してよい範囲、完了条件を節目ごとに明示することが重要です。
仕様書とコードを横断して分析できる
仕様書、設計書、APIドキュメント、移行計画、コード、テストを同じコンテキストに含められると、文書と実装の不一致を調べる作業にも活用できます。
たとえば、次の観点で分析できます。
- 仕様書に記載されたAPIと実装されたエンドポイントの差異
- データモデルの定義とデータベースマイグレーションの不一致
- 要件にあるエラーケースとテストケースの対応状況
- 非推奨とされた機能がコード内に残っていないか
- 運用手順と実際の設定項目が一致しているか
この使い方では、単なるコード生成よりも、レビューや保守の支援ツールとしての価値が大きくなります。
コンテキストが大きければ十分なのか
100万トークン対応は強力な基盤ですが、入力できる量が増えるだけで、回答の品質が自動的に向上するわけではありません。
情報量が増えるほど、重要情報の指定が必要になる
大規模リポジトリには、生成物、古い実装、サンプルコード、利用していない依存関係なども含まれます。これらを無差別に入力すると、AIが重要な情報と参考情報を区別しにくくなる可能性があります。
依頼時には、次のような条件を明示すると分析の焦点を保ちやすくなります。
- 対象とするサービスやディレクトリ
- 変更してよいファイルの範囲
- 現行仕様として優先する文書
- 互換性を維持すべきAPI
- 回答に含めるべき根拠やファイルパス
- 推測とコードから確認できる事実の区別
「リポジトリ全体を見て修正して」と依頼するよりも、「注文作成APIのタイムアウト処理について、仕様書、実装、テストの差異を列挙し、変更案は提示するが編集は行わない」と指定する方が、レビュー可能な結果になりやすいでしょう。
処理速度と料金は別に評価する必要がある
100万トークンを扱えることは、毎回100万トークンを送るべきという意味ではありません。入力が大きくなれば、処理時間、応答までの待ち時間、利用コストに影響する可能性があります。今回のニュース概要では、具体的な料金や処理速度は示されていません。
実務では、次のように使い分けるのが現実的です。
- 小さな修正は対象ファイルと関連テストだけを渡す
- 初回のアーキテクチャ調査では広いコンテキストを使う
- 影響範囲の確認では関連サービスを限定する
- 長期タスクでは節目ごとに作業状態を整理する
- 同じ大規模入力を繰り返さず、必要な情報を段階的に絞る
利用量が増えるチームでは、モデルの能力だけでなく、リクエスト単位のコスト、完了までの時間、レビューに要する人手を含めて評価する必要があります。
モデル間の違いはコンテキスト長だけでは決まらない
Sol、Terra、Lunaはいずれも100万トークンのコンテキストウィンドウに対応しますが、実際の選択ではコンテキスト長以外の特性も重要です。推論の得意分野、コード編集の安定性、応答速度、利用コストなどが異なる場合、タスクに応じた使い分けが必要になります。
ニュース概要から確認できるのは、3モデルが100万トークンに対応したという点です。モデルごとの性能差や料金差を前提に運用設計する場合は、実際の開発タスクで比較するのが適切です。
開発チームでの導入ポイント
まずは「読む」作業から始める
いきなり自動編集に使うのではなく、コードベースの理解やレビュー補助から導入すると、効果を測りやすくなります。
- リポジトリの構成と主要な依存関係を説明させる
- 変更予定の機能について影響範囲を列挙させる
- 仕様と実装の差分を検出させる
- テスト不足の可能性がある箇所を洗い出させる
- 過去の修正履歴を踏まえてリスクを整理させる
この段階では、AIの出力をそのまま採用するのではなく、根拠となるファイルやコード箇所を示させることが重要です。
コンテキストの投入ルールを決める
チームで利用する場合は、個々のエンジニアのプロンプト技術だけに依存しない運用が必要です。対象範囲や機密情報の扱いについて、最低限のルールを定めておきます。
- 本番の認証情報や秘密鍵を入力しない
- 個人情報や顧客データを必要以上に含めない
- 生成物や不要なバイナリを分析対象から除外する
- AIが変更したファイルと検証結果を記録する
- コードレビューとテストをAI利用の有無にかかわらず実施する
コンテキストが大きくなるほど、入力する情報の範囲も広がりやすくなります。利便性だけでなく、ソースコードやドキュメントの取り扱い、アクセス権限、ログの管理も同時に考えるべきです。
100万トークン対応を活かすプロンプト例
大規模なコードベースを対象にする場合は、目的と出力形式を明確にします。
このリポジトリを対象に、注文作成処理の実行経路を調査してください。
目的:
- API受付からデータベース登録までの呼び出し関係を把握する
- タイムアウトとリトライの実装箇所を特定する
- 仕様書とテストで不足しているケースを列挙する
条件:
- 推測ではなく、根拠となるファイルパスと関数名を示す
- 仕様書、実装、テストの差異を分けて記載する
- コードの変更は行わず、最後に変更候補を整理する
このように、広いコンテキストを「丸ごと投入して自由に判断させる」のではなく、調査対象と評価軸を指定することで、結果をレビューしやすくなります。
まとめ：大容量コンテキストは開発の土台を広げる
KiroのGPT-5.6における100万トークン対応は、コードベース全体、長文ドキュメント、長期的なエージェント履歴を扱うための選択肢を広げます。特に、巨大なリポジトリの理解、仕様と実装の横断分析、複数工程にまたがる保守作業で効果を発揮しやすい機能です。
一方で、コンテキストの大きさだけでは開発品質は決まりません。入力情報の選別、目的の明確化、モデルの使い分け、処理時間とコストの管理、そして人間によるレビューが欠かせません。
100万トークン対応を最大限に活かす鍵は、AIに「すべてを読ませる」ことではなく、システム全体を見せたうえで、何を判断させるかを設計することです。
出典： AWS公式ブログ