今回は Claude モデルを Logic Apps から Messages API で呼び出し、Prompt Caching（プロンプトキャッシュ） の動作を検証しました。
Prompt Caching は、システムプロンプトなど複数のリクエストで繰り返し利用する入力をキャッシュすることで、入力トークンのコストやレイテンシを削減できる機能です。
参考：https://platform.claude.com/docs/ja/build-with-claude/prompt-caching
環境準備
Microsoft Foundry
Azure の Microsoft Foundry で Claude モデルをデプロイします。今回は Claude Sonnet 4.6 を使っています。
Logic Apps
Logic Apps の構成は以下の通りです。Compose アクションで AI に渡すプロンプトを設定し、HTTP アクションで Messages API を呼び出すシンプルな構成です。
Prompt Caching の設定
HTTP アクションのリクエストボディは以下の通りです。ここで Prompt Caching を設定します。
{
"system": [
{
"type": "text",
"text": "@{outputs('Compose_-_System_Prompt')}",
"cache_control": {
"type": "ephemeral",
"ttl": "5m"
}
}
],
"model": "claude-sonnet-4-6",
"max_tokens": 200,
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "@{outputs('Compose_-_User_Prompt')}"
}
]
}
]
}
システムプロンプトの指定箇所内にあるcache_controlが Prompt Caching の設定です。
"cache_control": {
"type": "ephemeral",
"ttl": "5m"
}
Prompt Caching では、リクエスト内の入力は tools → system → messages の順で評価され、cache_control を設定したブロックまでのプレフィックス全体がキャッシュ対象になります。
今回の構成では system 内のシステムプロンプトに cache_control を設定しているため、システムプロンプトまでがキャッシュ対象です。一方、その後に評価される messages 内のユーザープロンプトは、このキャッシュブレークポイントより後ろにあるためキャッシュ対象には含まれません。
そのため、システムプロンプトを変更せずにユーザープロンプトだけを変更した場合は、システムプロンプトのキャッシュを再利用できます。
例えば、システムプロンプト内でキャッシュしたい部分とキャッシュさせたくない部分を分ける場合は、次のように設定します。
"system": [
{
"type": "text",
"text": "{キャッシュしたいテキスト}",
"cache_control": {
"type": "ephemeral",
"ttl": "5m"
}
},
{
"type": "text",
"text": "{キャッシュさせたくないテキスト}"
}
]
cache_control の設定項目である type は、使用するキャッシュの種類を指定する項目です。（現状 Prompt Caching で指定できる値は ephemeral のみなので、こちらを指定しておけば問題ありません）
ttl（Time To Live）は、作成したキャッシュをどのくらいの期間保持するかを指定する項目です。今回は、5分間キャッシュを保存します。
重要な点として、キャッシュが利用されると TTL が更新されるため、同じキャッシュに継続してアクセスしている場合はキャッシュを再利用し続けることができます。
例えば5分 TTL の場合、
10:00 キャッシュ作成
10:03 キャッシュヒット → TTL 更新
10:07 キャッシュヒット → TTL 更新
10:11 キャッシュヒット → TTL 更新
のように、5分以内の間隔でキャッシュが利用され続けていれば、その都度 TTL が更新されます。
また TTL の計測開始時点はキャッシュを書き込みまたは読み込んだタイミングになるため、非常に長い回答を生成する場合は次回のキャッシュ利用までの残り時間が短くなる点には注意が必要です。
プロンプト準備
Prompt Caching には、モデルごとにキャッシュ可能な最小トークン数があります。今回使用する Claude Sonnet 4.6 では、キャッシュ可能な最小プロンプト長は 1,024 tokens です。
この最小トークン数を上回るように、検証では以下のある程度長いシステムプロンプトを設定しました。
あなたは Contoso Corporation の社内 IT 運用支援アシスタントです。
以下に記載されている「Contoso IT Operations Manual Version 2026.09」を唯一の参照情報として、ユーザーからの質問に回答してください。
回答時には以下のルールを必ず守ってください。
1. マニュアルに記載されている情報だけを使用してください。
2. マニュアルに記載されていない事項について推測しないでください。
3. 回答は日本語で行ってください。
4. 手順について質問された場合は、番号付きで回答してください。
5. 回答の最後に、参照したセクション番号を記載してください。
6. ユーザーから追加の質問が来ても、このマニュアルの内容を引き続き参照してください。
# Contoso IT Operations Manual Version 2026.09
## Section 1: 基本運用方針
Contoso Corporation の IT システムは、可用性、機密性、完全性の3つを主要な運用品質指標として管理する。
すべての運用担当者は、システム変更を実施する前に変更内容、影響範囲、ロールバック方法を確認しなければならない。
本番環境への変更は、原則として承認済みの変更要求に基づいて実施する。
障害対応では、サービス復旧を最優先し、その後に原因分析を実施する。
担当者個人の判断のみで重大な本番変更を実行してはならない。
## Section 2: インシデント分類
インシデントは Severity 1、Severity 2、Severity 3、Severity 4 の4段階に分類する。
Severity 1 は、主要サービスが全面的に停止している状態、または重大なセキュリティ侵害が発生している状態を示す。
Severity 2 は、主要サービスの一部機能が利用できず、多数の利用者に影響している状態を示す。
Severity 3 は、一部ユーザーまたは限定された機能に問題が発生している状態を示す。
Severity 4 は、サービスへの影響がほとんどない軽微な問い合わせまたは改善要求を示す。
Severity 1 のインシデントについては、検知から10分以内に Incident Manager を任命する。
Severity 2 のインシデントについては、検知から30分以内に担当チームへエスカレーションする。
## Section 3: インシデント初動手順
インシデントが検知された場合、担当者は次の順序で対応する。
Step 1: 監視システム、ユーザー報告、ログを確認し、障害が実際に発生しているか確認する。
Step 2: 影響を受けているサービス、ユーザー数、地域、機能を特定する。
Step 3: Severity 判定基準に基づいてインシデントの重要度を決定する。
Step 4: インシデント管理システムにチケットを作成する。
Step 5: Severity に応じた担当チームおよび Incident Manager へ通知する。
Step 6: 利用可能な既知の回避策が存在するか確認する。
Step 7: 回避策が安全であることを確認したうえで適用する。
Step 8: サービスが正常化したことを監視システムと利用者の両方から確認する。
Step 9: インシデントチケットに対応内容と復旧時刻を記録する。
Step 10: 必要に応じて Post Incident Review を開始する。
## Section 4: エスカレーション
Severity 1 の場合、Incident Manager、Service Owner、Security Operations Team に通知する。
Severity 2 の場合、Service Owner および該当サービスの On-call Engineer に通知する。
Severity 3 の場合、通常の担当チームへ通知する。
Severity 4 の場合、通常のサービス要求プロセスで対応する。
エスカレーション後も、最初にインシデントを担当したエンジニアは、引き継ぎが完了するまで対応責任を保持する。
## Section 5: データベース障害
データベースへの接続障害が検知された場合、最初にアプリケーションサーバーとデータベースサーバー間のネットワーク接続を確認する。
次に、データベースサービスの稼働状態を確認する。
データベースサービスが停止している場合は、停止原因をログから確認する。
CPU、メモリ、ディスク容量、接続数についても確認する。
ディスク使用率が90パーセントを超えている場合は Severity 2 の候補として扱う。
データ消失の可能性が確認された場合は Severity 1 として扱う。
## Section 6: API 障害
API のエラー率が通常値を超えた場合、HTTP ステータスコード別の発生数を確認する。
HTTP 500 系エラーが増加している場合、アプリケーションログおよび依存サービスを確認する。
HTTP 429 が増加している場合、レート制限とトラフィック量を確認する。
HTTP 401 または HTTP 403 が増加している場合、認証サービス、トークン有効期限、アクセス制御設定を確認する。
平均応答時間が通常値の3倍を超えた状態が15分以上続いた場合、パフォーマンスインシデントとして登録する。
## Section 7: ログ管理
本番システムのアプリケーションログは中央ログ管理システムへ転送する。
Severity 1 および Severity 2 の調査では、対象時刻の前後30分以上のログを確認する。
ログに認証情報、アクセストークン、パスワードを記録してはならない。
調査のためログを共有する場合も、個人情報および秘密情報をマスクする。
## Section 8: 復旧確認
サービス復旧の判断は、単一の監視メトリックだけで行ってはならない。
最低でもサービスヘルス、エラー率、レスポンスタイムの3項目を確認する。
ユーザー影響が発生していたインシデントでは、可能であれば実際のユーザー操作と同等の End-to-End テストを実施する。
正常状態が10分以上継続したことを確認してからインシデントを Resolved 状態へ変更する。
## Section 9: Post Incident Review
Severity 1 のインシデントでは必ず Post Incident Review を実施する。
Severity 2 のインシデントでは、再発可能性が高い場合に Post Incident Review を実施する。
レビューでは、タイムライン、直接原因、根本原因、検知方法、対応内容、改善策を記録する。
レビューの目的は個人の責任追及ではなく、システムと運用プロセスの改善である。
改善項目には担当者と期限を設定する。
## Section 10: 変更管理
本番環境への通常変更には、変更要求番号、実施内容、影響範囲、実施日時、担当者、承認者、検証方法、ロールバック方法を記録する。
緊急変更についても、実施後24時間以内に変更記録を作成する。
変更作業開始前にロールバック条件を明確にする。
想定外の影響が確認された場合、変更作業を継続せず、原則としてロールバックを開始する。
---
【Prompt Cache 検証用拡張データ】
以下の文章はキャッシュ性能検証用の固定リファレンスデータであり、意味内容よりも、毎回完全に同じ入力を維持することを目的としている。
この固定リファレンス領域には、運用原則、障害対応原則、変更管理原則、サービス復旧原則、監視原則、ログ管理原則、セキュリティ原則、エスカレーション原則を記録する。
検証を行う際、この領域の文字、空白、改行、順序を変更してはならない。
Prompt Cache Test Reference Record 0001: Production changes require validation and rollback planning.
Prompt Cache Test Reference Record 0002: Incident response prioritizes service restoration.
Prompt Cache Test Reference Record 0003: Monitoring information must be verified before escalation.
Prompt Cache Test Reference Record 0004: Operational logs must not contain passwords.
Prompt Cache Test Reference Record 0005: Recovery must be confirmed using multiple signals.
Prompt Cache Test Reference Record 0006: Critical incidents require an incident manager.
Prompt Cache Test Reference Record 0007: Database failures require connectivity verification.
Prompt Cache Test Reference Record 0008: API failures require HTTP status analysis.
Prompt Cache Test Reference Record 0009: Emergency changes require retrospective documentation.
Prompt Cache Test Reference Record 0010: Post incident reviews focus on system improvement.
上記10レコードを **Record 0500 まで同じ形式で増やしてください。**
この固定プロンプトは Prompt Cache 検証中は一切変更しないでください。
補足
当初は「この固定部分全体が最低 5,000 tokens を超えるようにしてください」という指示も含めていました。しかし、この文言を書くだけで実際の入力トークン数が 5,000 tokens 以上になるわけではないため、検証条件としては意味のない指定でした。今回使用した Claude Sonnet 4.6 の最小キャッシュ可能長は 1,024 tokens であり、実際のキャッシュ対象は 2,676 tokens だったため、Prompt Caching の検証条件は満たしています。
ユーザープロンプトはまず以下のシンプルな質問を設定します。
文書に記載されているインシデント対応の最初の3ステップを回答してください。
検証パターン準備
今回は次の3パターンを試します。
| 検証 | 変更内容 | 確認したいこと |
|---|---|---|
| 1回目 | 初回実行 | キャッシュが作成されるか |
| 2回目 | ユーザープロンプトのみ変更 | システムプロンプトのキャッシュを再利用できるか |
| 3回目 | システムプロンプトを変更 | 既存キャッシュがヒットせず、新しいキャッシュが作成されるか |
検証実施
各設定が完了したら Logic Apps を実行し、 HTTP アクションのレスポンスに含まれる usage を確認します。
1回目：キャッシュ作成
1回目は想定どおりプロンプトキャッシュの作成に成功しています。
"usage": {
"input_tokens": 33,
"cache_creation_input_tokens": 2676,
"cache_read_input_tokens": 0,
"cache_creation": {
"ephemeral_5m_input_tokens": 2676,
"ephemeral_1h_input_tokens": 0
},
"output_tokens": 180,
"service_tier": "standard",
"inference_geo": "not_available"
}
トークン数に関連する項目を整理すると以下のようになります。初回なので既存キャッシュは存在せず、2,676 トークンのキャッシュが新しく作成されました。
| 項目 | 値 | 意味 |
|---|---|---|
| cache_creation_input_tokens | 2,676 | 新しくキャッシュへ書き込まれたトークン |
| cache_read_input_tokens | 0 | キャッシュから読み込まれたトークン |
| ephemeral_5m_input_tokens | 2,676 | 5分 TTL のキャッシュとして書き込まれたトークン |
| input_tokens | 33 | 最後のキャッシュブレークポイントより後ろの通常入力 |
| output_tokens | 180 | 回答生成で消費したトークン |
2回目：ユーザープロンプト変更
次に、システムプロンプトは一切変更せず、ユーザープロンプトだけを変更します。
Severity 1 の場合、誰にエスカレーションする必要がありますか？
結果は次のようになりました。2回目は Prompt Caching が効果を発揮しています。
"usage": {
"input_tokens": 31,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 2676,
"cache_creation": {
"ephemeral_5m_input_tokens": 0,
"ephemeral_1h_input_tokens": 0
},
"output_tokens": 169,
"service_tier": "standard",
"inference_geo": "not_available"
}
1回目と2回目の結果を表にします。
| 項目 | 1回目 | 2回目 | 意味 |
|---|---|---|---|
| cache_creation_input_tokens | 2,676 | 0 | 新規キャッシュは作っていない |
| cache_read_input_tokens | 0 | 2,676 | キャッシュを 2,676 トークン分再利用 |
1回目は固定のシステムプロンプト 2,676 トークン分をキャッシュに保存し、2回目はキャッシュから取得しています。
3回目：システムプロンプト変更
最後に、システムプロンプトの冒頭の一部を変更します。
変更前：あなたは Contoso Corporation の社内 IT 運用支援アシスタントです。
変更後：あなたは Contoso Corporation TEST の社内 IT 運用支援アシスタントです。
あなたは Contoso Corporation TEST の社内 IT 運用支援アシスタントです。
以下に記載されている...
結果を見ると、システムプロンプトを変更したことで既存キャッシュがヒットせず、新しいキャッシュが作成されているのが分かります。
"usage": {
"input_tokens": 32,
"cache_creation_input_tokens": 2676,
"cache_read_input_tokens": 0,
"cache_creation": {
"ephemeral_5m_input_tokens": 2676,
"ephemeral_1h_input_tokens": 0
},
"output_tokens": 182,
"service_tier": "standard",
"inference_geo": "not_available"
}
3回目までの結果をまとめると以下の通りです。
| 実行 | 変更内容 | input_tokens | cache_creation | cache_read | 判定 |
|---|---|---|---|---|---|
| 1回目 | 初回 | 33 | 2,676 | 0 | キャッシュ作成 |
| 2回目 | ユーザープロンプトのみ変更 | 31 | 0 | 2,676 | キャッシュヒット |
| 3回目 | システムプロンプトを変更 | 32 | 2,676 | 0 | キャッシュミス → 新規キャッシュ作成 |
検証結果として、
・初回リクエストではシステムプロンプトのキャッシュが作成される
・ユーザープロンプトだけ変更した場合はシステムプロンプトのキャッシュが再利用される
・キャッシュ対象のシステムプロンプトを変更すると既存キャッシュにはヒットせず、その入力に対する新しいキャッシュが作成される
ことを確認できました。
Prompt Caching の有効な使い方
Prompt Caching はキャッシュを有効にすれば、初回からトークンコストを削減という仕組みではありません。 5分 TTL の場合、キャッシュへの書き込みには通常の入力より高いコストが設定されている一方、キャッシュヒット時の読み取りは通常入力より大幅にコストは安くなります。
そのため、1回だけ使う長いプロンプトよりも、「使いまわす長いシステムプロンプト」+「毎回異なるユーザープロンプト」を何度も実行するといったケースで効果が出やすい機能です。
今回のような「共通の指示やナレッジは固定し、質問や分析対象だけを毎回変更する」構成は、Prompt Caching と相性がよいです。