Kimi K3 の 1M コンテキスト活用法:リポジトリ全体・長文書・節約術

Kimi K3 はコンテキストウィンドウを 1,048,576 トークンまで拡張しました。K2 のおよそ4倍です。これまでチャンク分割や RAG、繰り返しの継ぎ合わせが必要だった作業の多くを、今では「一度にまとめて投入」できます。ただし 1M は何も考えずに埋め尽くすためのものではありません。使いこなせば手間もコストも省け、使い方を誤れば遅く高くつきます。ここでは 1M コンテキストの実践的な使い方を整理します。

1M トークンに何が入るか

ざっくりした換算(日英混在、経験値ベース)では、1M トークンはおよそ次に相当します:

• 中規模のコードリポジトリ:数百のソースファイルの中核部分;
• 一冊の本:数百ページの技術マニュアルや長文ドキュメント;
• 数十本の PDF / 契約書:プロジェクト一式の文書を一度に読み込み;
• 超長尺の会話履歴:長時間動くエージェントが多数のツール呼び出しを経た後の完全なコンテキスト。

言い換えれば、これまで「入りきらない」ために分割が必須だったタスクの多くを、K3 は単一リクエストの完全な文脈の中で処理できます。モデルが全体像を把握でき、回答の一貫性と情報欠落の少なさが最大のメリットです。

リポジトリ全体のコード解析の組み立て方

K3 にコードを渡すときは、量を積むよりも構造が重要です。推奨する messages の組み立て方は次のとおりです:

system_prompt = "あなたはシニアエンジニアです。以下はリポジトリ全体です。回答では具体的なファイルと行番号を引用してください。"

repo_dump = "\n\n".join(
    f"### FILE: {path}\n```\n{code}\n```"
    for path, code in files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": repo_dump + "\n\n質問:ログイン認証のロジックはどのファイルにありますか?統合できる重複コードはありますか?"},
    ],
)

いくつかのポイント:

• 各ファイルに明確なパス表記を付ける(### FILE: path)ことで、モデルが正確に引用できます;
• 変わらない部分(リポジトリの内容)を前に置き、毎回異なる質問を後ろに置く。こうすれば固定プレフィックスがキャッシュに乗ります;
• モデルにファイル / 行番号を引用させることで、漠然とした回答ではなく検証可能な出力になります。

長文書 Q&A とキャッシュ

長文書のシナリオ(法的契約、論文、マニュアル)は 1M コンテキストの最も手間のかからない使い方です。文書全体を system か最初の user メッセージに入れ、あとは続けて質問するだけ。自分でチャンク分割して検索する必要はありません。

節約の要点:K3 はコンテキストキャッシュがデフォルトで有効です。 同じ長文書に異なる質問を繰り返すと、その文書プレフィックスがキャッシュにヒットし、入力価格は ¥20/M から ¥2/M へ下がります。そこで組み立て順は次のようにします:

[system: 役割 + 指示]     ← 固定
[user: 文書全体]          ← 固定、キャッシュにヒット
[user: 今回の具体的な質問]  ← 毎回変化

固定内容を前に、変化する内容を後ろに置くのが、ロングコンテキスト節約の第一原則です。価格とキャッシュの詳しい計算は Kimi K3 価格の詳細解説 をご覧ください。

いつ RAG を使うべきか

1M は大きいですが、万能ではありません:

• 知識ベースが 1M を大きく超える場合(会社の wiki 全体、百万行のコードなど):やはり先に検索してから投入する必要があり、RAG は廃れません;
• 少数の関連断片だけが必要な場合:全部詰め込むのは無駄で、入力トークンを無駄に消費し、レイテンシも上がります;
• 強いリアルタイム性 / 高並行性:コンテキストが長いほど1回あたりが遅く高くつくので、高頻度の場面では削るべきです。

実用的な原則:一度に収まり、内容の大半が関連しているなら、そのまま詰め込む。そうでなければ先に検索し、ヒットした断片を K3 に渡す。 両方を組み合わせることもできます。RAG で範囲を数十万トークンに絞り、その「大きいが関連する」コンテキストの中で K3 に深く回答させるのです。

注意事項

• 長いほど高く遅い:1M は上限であって目標ではありません。必要な分だけ使いましょう;
• キャッシュを活用する:固定プレフィックスを前に置き、長文 / マルチターンでは必ずキャッシュに乗せる;
• 視覚も文脈に含まれる:画像 / 動画のトークンも予算を消費するので、長いマルチモーダルタスクでは総量に注意;
• content だけを残さない:マルチターン / ツール呼び出しでは、完全な assistant メッセージをそのまま返送し、状態を落とさない。

導入コード一式とエラーのトラブルシューティングは Kimi K3 API 接続チュートリアル をご覧ください。1つの Key で K3 と他社モデルを同時に呼び出し、長文タスクと短いタスクを振り分けたいなら、GetModel ダッシュボード から始めるのが一番手軽です。