AIエージェントのためのグラウンドホッグ・デー: Amazon BedrockでOpenAIモデルを利用するためのプロンプトキャッシングパターン

エージェントを起動するたびに、アクションを実行する前にその生涯の物語全体を再読み込みしなければなりません。同じコンテキストを何度も与えなくても覚えておかせる方法を紹介します。

映画の中で グラウンドホッグデーBill Murray演じる主人公は、毎日同じ2月2日を繰り返して生きることになります。彼はラジオから流れる同じ曲とともに目覚め、同じ宿、同じ小さな町で、映画ファンの一部が34年と見積もるほどの長い間、何度も何度も同じ一日を過ごすのです。

前日に達成したことは何一つ、最初からやり直さない限り持ち越されません。AIエージェントは「デイズ・オブ・グラウンドホッグ」のような世界に生きています。エージェントが一歩進むたびに(ツールを呼び出し、結果を読み、次に何をすべきか判断するたびに)、連続性を保つためにモデルにこれまでの全体の履歴を送らなければなりません。ツールの定義、指示、これまでのすべてのツール呼び出し、そしてすべての結果です。モデルは提供された入力に基づいて次のトークンを予測するだけです。リクエスト間で内部メモリを持たないため、すべてを再度読み込む必要があります。コーディングセッションの20ターン目には、モデルは1〜19ターンを再読み込みしており、そのトークンすべての費用を何度も何度も、支払っているのはあなたなのです。

プロンプトキャッシングはこの悪循環を断ち切ります。サービスは入力プロンプト(指示、ツール、コンテンツ)を保存し、次のリクエストでそれを再利用します。入力価格のごく一部で済みます。

この記事では、エージェントの最初のターンから新しいツールを手に入れ、ヘルパーを生み出すまでの、エージェントの一生を順を追ってご紹介します。その過程で、プロンプトキャッシュがコストを抑え、エージェントの応答性と一貫性を保つ仕組みについても解説します。

エージェントがLLMに送信するもの

キャッシュについて話す前に、典型的なエージェントの大規模言語モデル(LLM)への最初の呼び出しに何が含まれているのかを見ておくと役立ちます。

• ツール一覧 – エージェントが呼び出せるすべての関数の定義。新しいリリースを出荷すると変更されます。
• 手順 – 開発者プロンプト:ルール、ペルソナ、ポリシー、例。リリースごとにこれも変化する。
• 歴史 – このセッションでこれまでに起きたすべての内容:タスク、モデルのツール呼び出し、そしてツールの結果(ターンごとに増えていきます)。
• 新たな展開 – 最新のツール結果またはユーザーメッセージ(実行のたびに異なる場合があります)。

キャッシュを設定しない場合、エージェントがターンごとにモデルへ送信する内容は次のとおりです:

図1: エージェントが毎回のターンでモデルに送信する内容

プロンプトキャッシングの仕組み(内部動作)

モデルがプロンプトを読み込むとき、まず次のような書き込み(ライト)を行います。 プリフィル。プリフィルの間、モデルはすべての入力トークンを処理し、キーと値のベクトル(KV、key-valueとも呼ばれる)を構築します。これらはモデルのワーキングステートを形成します。これはモデルが最初のトークンを書き出す前に行われます。

プロンプトキャッシングは、システムプロンプト、ツール、コンテンツ、履歴などを含むその状態を保存します。後続のリクエストが同じ入力トークン(つまり同じテキスト)で始まる場合、プロンプトキャッシングサービスは再計算する代わりに保存された状態を読み込みます。その後、モデルへの次のペイロードで新しく追加された部分のみを処理します。プロンプトキャッシングは、Amazon Bedrock が再利用可能なプレフィックスの終端を選択する暗黙的なものと、コードがその終端を以下のようにマークする明示的なものがあります。 prompt_cache_breakpoint。両方のアプローチを組み合わせて使うことができ、その併用をお勧めします。

ターン1とターン2の比較

図2: ターン1ではプロンプトのプレフィックスをブレークポイントまで保存し、ターン2ではそれを再利用して、新しい質問に対してのみ全額を支払う

暗黙的か明示的か、そしてなぜ両方が必要なのか?

エージェント的なワークロードでは、暗黙的キャッシングにより、会話が進むにつれて Bedrock が何をキャッシュするかを自動的に選択します。明示的キャッシングでは、ツールや指示などの共有コンテンツをマークしておくことで、セッションをまたいだ再利用や、ヘルパーエージェントの起動時に活用できます。両方のキャッシング形式が常に必要なわけではありませんが、組み合わせることで、再利用可能な出発点を確保しつつ、大きくなり続ける会話を Bedrock に自動管理させることができます。

新しいセッションもその共有された開始点を再利用でき、各会話はそれぞれ独自にキャッシュされた履歴をもとに構築されていきます。この記事では、まず最初のターンから始め、その後、キャッシュされた内容を後続のターン、新しいツール、そしてサブエージェント間でどのように引き継ぐかを示します。

こんにちは、キャッシュされた世界

最初の勝利は、プロンプトの静的な部分をキャッシュすることです。つまり、リクエスト間で変わらないツールや指示のことです。これらの例では、既存のAmazon Bedrockクライアントを使用します。 TOOLS, および task。短縮された INSTRUCTIONS 実際のポリシーと例を含む文字列です。再利用可能なプレフィックスが対象となるには、1,024トークンに達する必要があります。

静的コンテンツをキャッシュする際は、明示的モードを使用してください。保存されるプレフィックスがどこで終わるかを指定します。

KEY = "support-agent:v7:gpt-6-astra"
INSTRUCTIONS = "Your full support policies and examples..."

# Rendered context: [provider context][TOOLS][INSTRUCTIONS] | [task]
# Cache starts at the beginning; the marker below chooses its end.
resp = client.responses.create(
    model="us.openai.gpt-6-astra",
    store=False,  # Response storage; prompt caching still works.
    include=["reasoning.encrypted_content"],
    prompt_cache_key=KEY,
    prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    tools=TOOLS,  # Rendered before instructions; keep order stable.
    input=[
        {
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": INSTRUCTIONS,
                # Save through this whole block, including TOOLS.
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        # User message is processed but not cached.
        {"role": "user", "content": task},
    ],
)

その prompt_cache_key そのパラメータは、どのリクエストが同じキャッシュを共有するかをサービスに伝えます。この使い方については、新しいセッションでキャッシュを読み取る方法に触れる際に改めて説明します。明示的キャッシングを使ったテストの一つでは、約4,000トークンのツールと指示のプレフィックスが、最初のリクエストで4,120トークンを書き込み、後続のリクエストでその4,120トークンを読み取りました。 task (またはユーザーリクエスト)がキャッシュ境界の後ろに来るため、これはキャッシュへの書き込みをトリガーしません。

プロンプトキャッシュは、まったく同じテキストを渡した場合にのみ機能する点に留意してください。エージェントの指示やツールリストが毎回同じ方法でシリアライズされるようにしてください。Model Context Protocol(MCP)サーバーなど他の形式のツール提供も、一貫性が保たれるようインデックス化する必要があります。日付、ユーザー名、リクエストIDなど変化するものは、キャッシュされた指示の後ろに置いてください。

コンテンツが増え多様になる（異なるツールやコンテンツ）場合は、インプリシットモードを使ってサービスに会話を追従させてください。ここでは、最初のリクエストに明示的なマーカーがありません。最新の対象メッセージはユーザーのタスクであるため、自動ブレークポイントはそのタスクの後に来て、ツール、指示、タスクをまとめてカバーします。インプリシットがデフォルトであるにもかかわらず、わかりやすさのために、以下の例ではモードを明示的に示しています。設定 store=False は会話履歴をアプリケーション内に残します。キャッシュを無効にするわけではありません。

def ask_with_implicit_cache(history):
    return client.responses.create(
        model="us.openai.gpt-6-astra",
        store=False,
        include=["reasoning.encrypted_content"],
        prompt_cache_key=KEY,
        prompt_cache_options={"mode": "implicit", "ttl": "30m"},
        tools=TOOLS,
        input=history,  # Everything gets cached
    )

history = [
    {"role": "developer", "content": INSTRUCTIONS},
    {"role": "user", "content": task},
]
# Automatic endpoint: the end of the user message.
resp = ask_with_implicit_cache(history)

これは、次のターンが同じタスクを続ける場合に便利です。別のタスクは、古いタスクを経由してプレフィックスと一致しません。また、インプリシット書き込みは、ツールと指示のみに対して必ずしも別のエントリを作成するわけではありません。その短い共有プレフィックスをタスク間で再利用可能にする必要がある場合は、そこで明示的なマーカーを使用してください。

エージェントに共有の開始点と増え続ける履歴の両方が必要な場合は、両方を使用してください。次のコード例では、マークされたデベロッパーブロックから始め、関数 ask_with_implicit_cacheを呼び出します。リクエストレベルのモードはインプリシットのままです。ブロックレベルのマーカーが、指示の後に明示的な保存ポイントを追加します。サービスは、最新の対象メッセージを通じて保存することもできます。これにより、会話が増えても共有プレフィックスを利用可能な状態に保てます。

history = [
    {
        "role": "developer",
        "content": [{
            "type": "input_text",
            "text": INSTRUCTIONS,
            "prompt_cache_breakpoint": {"mode": "explicit"}, 
        }],
    },
    {"role": "user", "content": task},
]
# Still implicit mode, now with an explicit startup save point in the history.
resp = ask_with_implicit_cache(history)

会話履歴とツール結果のキャッシング

モデルは名前でツールをリクエストし、その引数を渡します。アプリケーションがそれらを実行する必要があります。 execute_function は、それらのリクエストを対応するPython関数にルーティングし、その結果を返すために構築するヘルパーです。次のループはこのヘルパーを使って、リクエストされた各ツールを実行します。モデルの出力とすべてのツール結果を history リストに追加し、モデルが最終的な回答を返すまでそのリストを再度送信します。インプリシットモードでは、Amazon Bedrockは変更されていないプレフィックスを再利用し、最後のツール結果を通じて追加されたコンテンツをキャッシュできます。以前のメッセージと最初の TOOLS は変更しないでください。

import json

# Map tool names to their Python implementations.
TOOL_HANDLERS = {
    "get_owner": get_owner,
    # Register your other initial tools here.
}

def execute_function(name, arguments):
    """Run the requested tool and return its result."""
    handler = TOOL_HANDLERS.get(name)
    if handler is None:
        return {"error": f"Unknown tool: {name}"}
    return handler(**arguments)

while True:
    # Preserve all output items, including encrypted reasoning.
    history.extend(resp.output)
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        history.append({
            "type": "function_call_output",
            "call_id": call.call_id,
            "output": json.dumps(result),
        })
    # The last result in this group supplies the automatic endpoint.
    resp = ask_with_implicit_cache(history)

フォローアップの際は、新しいユーザーメッセージを追加し、ヘルパーを再度呼び出します。以前のメッセージを変更しないことで、キャッシュされたエンドポイントを利用可能な状態に保てます。

ローリングブレークポイント：各ターンはそれ以前のすべてを読み取る

図3：ローリングブレークポイント。各ターンはそれ以前のすべてを読み取り、自身のツール結果のみを書き込む

明示的なみの別の実行では、Hello cached worldの統合例から2メッセージの履歴を作り直します。このループはツール結果を input_text ブロックで囲み、各バッチの最終結果をマークします。以前のマーカーは historyに残ります。長い会話については 現在のルックアップルール を参照してください。

import json

while True:
    resp = client.responses.create(
        model="us.openai.gpt-6-astra", store=False,
        include=["reasoning.encrypted_content"],
        tools=TOOLS, prompt_cache_key=KEY, input=history,
        prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    )
    d = resp.usage.input_tokens_details
    print("read", d.cached_tokens, "write", d.cache_write_tokens)
    history.extend(resp.output)  # Includes encrypted reasoning.
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    batch = []
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        batch.append({
            "type": "function_call_output", "call_id": call.call_id,
            "output": [{"type": "input_text", "text": json.dumps(result)}],
        })
    # Add the newest boundary; retain every earlier marker.
    batch[-1]["output"][-1]["prompt_cache_breakpoint"] = {"mode": "explicit"}
    history.extend(batch)

GPT-6 Astraは、この6ターンのワークロードでインプリシットの最良の結果と同率でした：キャッシングなしでの実行と比較して入力コストが約62パーセント低下。同じモデルで明示的なローリングブレークポイントは約61パーセントの節約でした。どちらも、会話が増えるにつれてより多くの履歴を再利用しました。これらはワークロードの結果です。ご自身のエージェントの節約額を測定してください。

図4：GPT-6 Astraにおける各キャッシング設定の入力コスト（キャッシングなしを基準）

注意すべき点：

• 明示的なみのモードでの静的ブレークポイントのみ – ツールと指示はキャッシュされますが、増え続ける履歴は毎ターン再処理されます（0.61）。この制限は、対象となる会話の終端を通じた保存も行う統合例には当てはまりません。
• 単一のブレークポイントを移動すると 、キャッシュの再利用が妨げられ、明示的なみのモードで繰り返し書き込みが発生する可能性があります。前のターンのブレークポイントも維持してください。
• 変化するタスクを通じたインプリシット書き込みのみ – 新しいタスクはツールと指示を共有するかもしれませんが、以前に保存されたエンドポイントは共有しません。異なるタスクでその短いプレフィックスを再利用する必要がある場合は、共有指示の後に明示的なマーカーを追加してください。

ツールが変更される場合

エージェントのツールリストが変更されたり、新しいツールが追加されたりすることがあります。最初のリストは安定させてください：定義の追加、削除、並べ替えはキャッシュされたプレフィックスを無効にする可能性があります。ツールが利用可能になる方法に合ったアプローチを選択してください。

既知のツールがエージェントのフローの異なるステップで呼び出される場合： 同じソート済みの TOOLS を送信し、 allowed_tools モデルが呼び出せる対象を制限すること。With allowed_tools, "mode": "auto" モデルが許可されたツールを呼び出すかどうかを判断でき、 "mode": "required" は少なくとも1つの許可されたツール呼び出しを必須とします。これを tool_choiceとして渡します。この制限によってキャッシュされたカタログは変更されません:

tool_choice={"type": "allowed_tools", "mode": "auto",
             "tools": [{"type": "function", "name": "get_owner"}]}

セッション中の新しいツール。 Amazon Bedrock Runtime と Amazon Bedrock Mantle の両エンドポイントは、 additional_tools という入力項目タイプを GPT-6 Astra、GPT-6.1 Sol、GPT-5.6 Luna で受け付けます。AWS リージョンごとのモデル利用可否については、 Supported models by AWS Region in Amazon Bedrockを参照してください。新しいツール get_due_date をヘルパー関数 execute_functionに登録し、そのスキーマをエージェントループからの完了済み履歴に追加します。初期の TOOLS は変更しないでください:

TOOL_HANDLERS["get_due_date"] = get_due_date
NEW_TOOL = {
    "type": "function", "name": "get_due_date",
    "description": "Return the due date for a support case.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {"case_id": {"type": "string"}},
        "required": ["case_id"], "additionalProperties": False,
    },
}
history.append({
    "type": "additional_tools", "role": "developer",
    "tools": [NEW_TOOL],
})
history.append({
    "role": "user", "content": "Find the due date for case C-123.",
})
# Implicit mode saves through this new user message, including NEW_TOOL.
resp = ask_with_implicit_cache(history)
d = resp.usage.input_tokens_details
print("old prefix read", d.cached_tokens, "new write", d.cache_write_tokens)

# Example output:
# old prefix read 2048 new write 256

セッションの途中で新しいツールが到着する

図5: ツールの追加によって以前のプレフィックスが再利用可能なまま維持される様子。Amazon Bedrock Runtime 上の GPT-6 Astra による実測例の数値付き

新しいレスポンスでツール実行ループを継続します。このループはモデルの出力を historyに追加し、要求されたツールを実行して、その結果を追記します。後続のリクエストでも additional_tools 項目を維持し、新しいツールが引き続き利用可能なようにしてください。インプリシットモードでは、Amazon Bedrock は、その前にあるツール定義を含めて、新しいユーザーメッセージを通じてキャッシュできます。エクスプリシットのみのモードでは、以前のブレークポイントを保持したまま、そのユーザーメッセージ内の input_text ブロックに1つ追加します。 additional_tools 項目自体はブレークポイントを持てません。

ロールが異なれば、カタログも異なる。 異なるエージェントロールが異なるツールを必要とする場合は、各セッションの開始時に、support や billing のような安定したツールプロファイルを選択します。各プロファイルはそれぞれ独自のキャッシュ済みプレフィックスを持ちます。共有される指示をマークしておけば、後で同じプロファイルを使うタスクがそれを再利用でき、会話が長くなるにつれてどちらのモードでも使用できます。

キャッシュされたツールプロファイル

図6: 各ツールプロファイルは独自のキャッシュ済みプレフィックスを持ち、一致するセッションで再利用可能

サブエージェントとサイドコール

委譲のたびに、すべてのヘルパーに同じ背景情報を読み直させるべきではありません。プレフィックスを共有し、各ヘルパーのタスクを末尾に追加します。AI エージェントでキャッシングを使用する場合、ツールやシステムプロンプトが漏洩または悪用される可能性がある点に注意してください。プロンプトキャッシングの実装をガバナンスの一部として含む、責任ある AI のプラクティスを確立してください。

一度ウォームアップし、その後ファンアウトする。 まず通常のリクエストを送信し、ヘルパーを起動する前にその完了を待ちます。モードがインプリシットであっても、すべてのリクエストで共有コンテキストを明示的にマークします:

shared = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
warm = client.responses.create(
    model="us.openai.gpt-6-astra", store=False,
    tools=TOOLS, prompt_cache_key=KEY,
    prompt_cache_options={"mode": "implicit", "ttl": "30m"},
    max_output_tokens=16,
    input=[shared, {"role": "user", "content": "Reply READY."}],
)
d = warm.usage.input_tokens_details
if not (d.cache_write_tokens or d.cached_tokens):
    raise RuntimeError("Shared prefix was not cached.")
from concurrent.futures import ThreadPoolExecutor

# helper_tasks contains the task text for each helper.
helper_inputs = [
    [shared, {"role": "user", "content": task}]
    for task in helper_tasks
]
with ThreadPoolExecutor(max_workers=4) as pool:
    helpers = list(pool.map(ask_with_implicit_cache, helper_inputs))

ヘルパーは、ウォームアップと同じ TOOLS、モデル、および KEY を使用します。出力上限で終了したウォームアップでも、キャッシュを生成できる場合があります。ヘルパーを開始する前に、使用状況チェックでキャッシュの動作を確認します。

サブエージェント: 共有プレフィックスを一度ウォームアップしてからファンアウト

図7: ヘルパーを起動する前に共有プレフィックスをウォームアップし、各ヘルパーはその後、自身のタスクを追加する

サイドコールに同じ冒頭を与える。 エージェントループは、暗号化された推論を含め、すべての history とそれに一致するツール結果を追記することで、 resp.output を構築します。親が終了した後、その完全なリストを要約器やジャッジ用にコピーします。同じヘルパーは、ツール、モデル、キーを変更せずに維持します:

from copy import deepcopy

# history is the completed history built by the agent loop above.
# Copy it so the helper can add instructions without changing the parent.
helper_history = deepcopy(history)
helper_history.append({
    "role": "developer",
    "content": "Summarize this conversation in one sentence. Do not call tools.",
})
summary = ask_with_implicit_cache(helper_history)
d = summary.usage.input_tokens_details
print("history read", d.cached_tokens, "write", d.cache_write_tokens)
print(summary.output_text)

# Example output (assumed values and conversation):
# history read 4096 write 32
# Case C-123 is due on October 31, 2026.

ヘルパーは historyのキャッシュ済み部分を再利用できますが、追加された開発者メッセージによって、要約指示を含むようにキャッシュが自動的に拡張されるわけではありません。後続のリクエストで同じ履歴と指示を再利用する場合は、指示を input_text ブロック内に prompt_cache_breakpointとともに配置します。一回限りの要約であれば、追加のマーカーは不要です。

一時停止、再開、そしてキャッシュキー

一時停止。 キャッシュ済みプレフィックスには最低30分の Time to Live (TTL) があり、正常な再利用によって更新され、それより長く残る場合もあります。セッションがすぐに再開される場合は、プレフィックスが失効する前に通常のウォームアップで更新できます。そのリクエストのコストを、キャッシュの失効に任せる場合と比較してください。TTL のルールについては、Amazon Bedrock のドキュメントを参照してください。

新しいセッション。 プレフィックスを共有することを意図したリクエストでは、 prompt_cache_key を安定したものに保ちます。セッション固有のキーは、プロンプトが一致していてもセッションを分離します。次の例では、共有キーに切り替えたことでセッションがプレフィックスを再利用できるようになりました。

新しいセッションは、キーを共有している場合にのみキャッシュを再利用します

図8: セッション固有のキーはキャッシュエントリを分離し、共有キーにより一致するセッションがそれらを再利用できます

既存のキャッシュ内容を再利用するには、同じモデル、同じ AWS アカウント、同じリージョンであることに加え、利用可能な一致するプレフィックスが必要です。次の例では、明示的なスタートアップマーカーを暗黙的モードと組み合わせています。各セッションは同じ指示とそれぞれ固有のタスクで始まります。どちらも同じ計算済みキーを使用します:

import hashlib

def cache_key(app, model, prompt_version, instructions):
    digest = hashlib.sha256(instructions.encode()).hexdigest()[:12]
    return f"{app}:{prompt_version}:{model}:{digest}"

KEY = cache_key("support-agent", "us.openai.gpt-6-astra", "v7", INSTRUCTIONS)
prefix = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
for label, question in [
    ("session A", "Explain the refund policy without calling tools."),
    ("session B", "Explain the escalation policy without calling tools."),
]:
    # A fresh conversation for each session; the startup prefix matches.
    session_history = [prefix, {"role": "user", "content": question}]
    result = ask_with_implicit_cache(session_history)
    d = result.usage.input_tokens_details
    print(label, "read", d.cached_tokens, "write", d.cache_write_tokens)

コールドスタート時、セッション1が共有プレフィックスを書き込みます。セッション2は、タスクが異なっていてもそれを読み取ることができます。各タスクは暗黙的にキャッシュされることもあります。使用状況カウンターを確認してください: キーとマーカーが一致すれば再利用が可能ですが、キャッシュエントリが利用可能である必要は依然としてあります。

プロンプトキャッシングがもたらすもの

コスト。 8,000 トンのスタートアッププレフィックスと、それぞれ 2,000 トークンを追加する 6 ターンを備えた GPT-6 Astra 搭載エージェントの場合、1 回限りの静的キャッシングでコストは $0.50 に削減され、ローリングブレークポイントによりモデル化された入力コストが 64 パーセント削減されました: セッションあたり $0.87 から $0.32 へ。

図9: サポートエージェントの例におけるセッションあたりの累積入力コスト。GPT-6 Astra について Amazon Bedrock のオンデマンド価格を使用

キャッシングが機能していることを確認する方法

まずレスポンスの使用状況から確認します。 cached_tokens はキャッシュから読み取られた入力を報告し、 cache_write_tokens はキャッシュに書き込まれた入力を報告します。会話が長くなるにつれて、後のターンが以前の履歴を再利用していること、および新しい書き込みが追加された内容を反映していることを確認してください。

Amazon Bedrock Runtime エンドポイントの本番環境の監視には、Amazon CloudWatch の CacheReadInputTokenCount と CacheWriteInputTokenCount のメトリクスを使用してください。個別のリクエスト記録が必要な場合はモデル呼び出しログを有効にし、Amazon CloudWatch Logs Insights でクエリしてください。Amazon Bedrock Mantle エンドポイントについては、レスポンスの使用状況フィールドをアプリケーションログに記録してください。その Amazon CloudWatch 名前空間には現在、個別のキャッシュカウンターがありません。

コストを確認するには、 AWS Cost Explorer を Amazon Bedrock にフィルタリングし、 Usage typeでグループ化します。キャッシュ読み取り、キャッシュ書き込み、およびキャッシュされていない入力は、モデルごとに個別の項目として表示されます。入力コストに占める割合を計算する際は、出力トークンの項目を除外してください。

簡単なチェックリスト

• 再利用可能なプレフィックスを安定したものに保つ。 共有ツールと指示を最初に置き、その後に会話履歴と新しいターンを追加します。タイムスタンプ、メッセージ、またはツール定義を変更すると、その変更以降は再利用ができなくなります。より短いプレフィックスでも、独自に保存されたエンドポイントがあれば再利用できる場合があります。
• 再利用したいコンテンツの周りの境界を選択します。 履歴が伸び続ける場合は暗黙的キャッシュを使い、共有プレフィックスには明示的マーカーを使う、あるいはその両方を使ってください。明示的のみのモードでは、使い捨てのサフィックスを書き込むことを避けられます。明示的のみの会話を拡張する際は、後続のリクエストが保存済みのプレフィックスを見つけられるよう、それ以前のマーカーを保持してください。
• 初期のツールカタログは変更しないでください。 使用 allowed_tools 呼び出し可能なツールを制限するには。既知の定義を以下と共に追加します: additional_tools、または名前空間化されたクライアントサイドからそれらを発見する tool_search。エージェントの役割ごとに異なるカタログが必要な場合は、安定したツールプロファイルを選択してください。
• プレフィックスサイズとライフタイムを確認してください。 キャッシュ可能なプレフィックスには、少なくとも1,024個のトークンが含まれている必要があります。キャッシュされたプレフィックスは、最新の書き込みまたは正常な再利用から少なくとも30分間、再利用の対象として残ります。
• ヘルパーを起動する前に共有コンテンツをウォームアップします。 ウォームアップリクエストとヘルパーリクエストの両方で共有プレフィックスを指定してください。暗黙モードを使用する場合も同様です。並列呼び出しを開始する前に、ウォームアップリクエストを完了させてください。
• キャッシュキーを各共有グループ内で安定させてください。 プレフィックスを再利用する意図のリクエストは、同じキーを使用する必要があります。別々のキーを使用することで、顧客やユーザーごとにキャッシュの計上を区別することができます。
• ワークフロー全体での節約効果を測定します。 キャッシュ書き込みは通常の入力レートの1.25倍のコストがかかります。読み取り価格はモデルによって異なります。書き込みコストを読み取りによる節約と併せて追跡し、開発時はレスポンスのusageを、本番環境ではモニタリングおよび請求データを使用してください。

2月3日の朝を迎える

Bill Murrayは同じ過ちを繰り返すのをやめ、ある日から次の日へ学んだことを持ち越すようになって初めて、『恋はデジャ・ブ』のループから抜け出せます。エージェントも同様の、ただしロマンチックではない形でそこにたどり着きます。プロンプトの先頭をバイト単位で安定させ、履歴が増えていくにつれて自動または明示的なキャッシュ境界を利用することでです。

この記事では、共有ツールと指示をキャッシュする方法、エージェントのターンをまたいでキャッシュを成長させる方法、そしてツールの追加、ヘルパーの起動、新しいセッションの開始の際に再利用を維持する方法を扱いました。共有プレフィックスを安定させ、ワークフローが進むにつれて新しい情報を追記していきます。会話が伸びていく場合には暗黙的キャッシュを、共有コンテンツには明示的なブレークポイントを使います。両方が必要な場合は組み合わせ、変化するサフィックスが再利用される可能性が低い場合には明示的キャッシュのみのモードを選びましょう。キャッシュ読み取り、書き込み、総入力コスト、レイテンシを比較して、あなたのエージェントに最適な方法を見つけてください。これらのパターンを適用するには、以下に従ってください。 「OpenAIモデル向けAmazon Bedrockプロンプトキャッシングのドキュメント」 および確認する AWSリージョンおよびエンドポイント別のモデル利用可能性まずは1つのワークフローから始めて、会話が増える中でどれだけの削減効果があるかを測定してください。

著者について