弁護士がCodexを長時間・並列利用する際の使用量管理－プロンプトキャッシュ、プラグイン、heartbeat及び監査ログ（AI作成）

1　結論及び本記事の対象

Codexその他の生成AIを長時間又は多数の並列タスクで利用する場合、使用量が増えたという結果だけから、その原因を「モデルの性能低下」「プラグインの不具合」又は「キャッシュ障害」と断定することはできません。モデル、推論設定、ツール定義、プラグイン、スキル、会話履歴、文脈圧縮、heartbeat及び外部ツールの実行結果を分けて記録し、同じ条件で一つずつ変更して比較する必要があります。

一方、使用量を減らすために、法的検討に必要な一次資料、秘密情報の取扱条件、人による承認又は作業結果の検証を省いてはいけません。弁護士業務では、「短い入力」ではなく、「必要な統制を保ったまま、重複及び無関係な文脈を減らした入力」が目標になります。

本記事は、OpenAIの公式資料と、後記X投稿に示された利用者の経験を区別して整理したものです。X投稿で示された個別原因について、OpenAIが公式に認定したことを示す資料は確認できていません。

2　プロンプトキャッシュの基本

2.1　照合対象はユーザーの質問文だけではないこと

OpenAIの公式資料によれば、プロンプトキャッシュの対象となる入力は、画面に表示された質問文だけではありません。システムメッセージ、開発者メッセージ、ツールの名称・説明・入力スキーマ、会話履歴その他を含む、モデルに渡されるレンダリング済み入力全体が関係します。

したがって、利用者が同じ質問を送っていても、アプリ側が付加するツール定義又は前提指示が変われば、キャッシュの照合結果が変わる可能性があります。反対に、画面上の文章が少し長く見えても、その先頭部分が安定していれば、再利用される部分が増える場合があります。

2.2　先頭部分の一致が重要であること

公式資料では、キャッシュ利用のためには入力の先頭部分の完全一致が必要であると説明されています。そのため、何度も使う固定指示、出力形式及び安定したツール定義を前方に置き、案件名、日付、今回だけの資料、直近の質問その他の動的情報を後方に置くのが基本です。

ただし、機密情報を固定プロンプトへ入れてよいという意味ではありません。固定部分に置くのは、一般化された業務手順、証拠区分、出力様式及び承認条件等に限るべきです。

2.3　キャッシュヒットは回答の再利用ではないこと

プロンプトキャッシュは、過去の回答文をそのまま取り出す機能ではありません。OpenAIは、キャッシュにはトークン文字列そのものではなく、処理済みの中間表現であるKV tensorsが保存されると説明しています。また、同じ入力であっても、出力が同一になるとは限りません。

したがって、キャッシュヒットが多いことは、回答の正確性、判例の存在、引用の正しさ又は法的結論の妥当性を示しません。これらは別に一次資料と人の確認によって担保する必要があります。

3　キャッシュ効率を変え得る要素

3.1　ツール、プラグイン及びスキル

ツールの名称、説明、入力スキーマ又は並び順が変わると、入力の先頭部分が変わり、キャッシュの一致率に影響し得ます。プラグイン又はスキルが、モデルに渡す指示又はツール定義を追加する場合も同様です。

もっとも、「プラグインを外せば必ず使用量が減る」とは限りません。必要な検索、文書取得又は検証を失えば、再作業が増え、かえって全体の使用量が増えることがあります。利用可能なツールが多数ある場合には、OpenAIの公式資料が示すtool search又はdeferred loadingの利用可能性を確認し、タスクごとに必要な能力だけを読み込むのが合理的です。

3.2　動的情報の置き場所

時刻、利用量、バージョン番号、進捗表示その他の頻繁に変わる情報が入力の前方へ毎回挿入されると、その後ろにある長い固定部分まで一致しにくくなる可能性があります。ただし、実際にどの情報がどの位置へ挿入されるかは、アプリ及びバージョンによって異なります。

利用者側で制御できるプロンプトでは、固定ルールを前に、案件固有の動的情報を後ろに置きます。アプリが自動付加する部分は推測で断定せず、取得できるログ、バージョン情報及び比較実験で切り分けます。

3.3　モデル、推論設定及び文脈圧縮

モデル、reasoning effort、verbosity、出力形式その他の設定変更も、キャッシュの照合条件又は使用量に影響し得ます。また、長い会話では、文脈圧縮によって入力が短くなる一方、従前の先頭部分との一致が減る場合があります。

文脈圧縮は、それ自体が異常ではありません。圧縮後にも、実施済みの操作、前提、記事ID、URL、保存結果、未解決の障害及び次に行う作業を残せば、総入力を抑えながら継続性を保ちやすくなります。

4　長時間・並列利用におけるタスク設計

4.1　メインタスクとワーカータスクを分けること

長期案件では、依頼の範囲、証拠区分、承認履歴及び最終判断を保持するメインタスクと、個別の検索、表の照合又は草案作成を行う一時的なワーカータスクを分ける方法があります。

ただし、後記X投稿に出てくるタスク数は、その投稿者の運用例にすぎません。「メインは何個、ワーカーは何個が最適」という一般的な数値基準はありません。案件数、資料量、同時実行数、秘密情報の境界及びレビュー能力に応じて決めます。

4.2　必要な能力だけを各タスクへ渡すこと

ワーカータスクには、担当する作業に必要な資料、ツール及び出力様式だけを渡します。しかし、一次資料へのアクセス又は出典記録が必要な調査タスクから、その能力を外してはいけません。

また、ワーカーの結果をメインへ戻す際には、結論だけでなく、参照資料、該当箇所、未確認事項及び再現に必要なIDを一緒に渡します。要約だけを引き継ぐと、後で根拠をたどれなくなるからです。

4.3　heartbeatを短くし、停止条件を定めること

定期監視又は自動継続では、毎回長い経緯を再送するのではなく、監視対象、前回値、今回値、変化があった場合の行動及び停止条件を短く固定します。状態に変化がない場合は通知しないという条件も有用です。

終了済み、権限不足、同じエラーが反復した場合又は人の判断が必要な場合には、無期限に再試行せず停止します。heartbeatが有用な監視をしているのか、単に文脈を再処理しているのかを、一定期間ごとに見直す必要があります。

5　弁護士業務で削ってはいけないもの

5.1　出典及び証拠の階層

法律実務では、少なくとも次の区分を維持します。

• 法令、裁判例、契約書、原資料及び公式ログによって確認できた事実
• 当事者又は利用者が述べた内容
• 複数の事実から導いた推論
• 現時点では確認できない事項

SNS投稿は調査の端緒にはなりますが、製品仕様又は障害原因の一次資料にはなりません。裁判例を引用する場合には、事件番号、裁判所、日付、掲載資料及び引用箇所を確認し、別事件又は別当事者の事実を転用しないことが必要です。

5.2　秘密情報の入力判断

「学習に利用されないこと」「履歴に表示されないこと」「事業者側で一定期間保持されること」「人によるアクセスの可能性」「外部ツールへ送信されること」及び「プロンプトキャッシュにより処理済み表現が保持されること」は、別の論点です。

案件情報を入力する前に、利用するサービス、プラン、モデル、地域、保持期間、組織設定、外部コネクタ及び委託先を確認します。プロンプトキャッシュがトークン自体を保存しないという説明だけから、秘密保持契約上又は弁護士職務上の入力可否が決まるわけではありません。

5.3　人による承認及び外部作用の統制

メール送信、WordPress公開、ファイル削除、権限変更その他の外部作用を伴う操作は、草案作成及び検証と分け、人が対象と内容を確認した後に一度だけ実行します。

実行後は、成功表示だけで完了とせず、管理画面からの読戻し、公開画面の確認又は保存ファイルの再読込みによって結果を確かめます。トークン節約を理由に、この最終確認を省略してはいけません。

6　使用量を測定し、原因を切り分ける方法

6.1　最低限保存すべき項目

可能な範囲で、次の項目を一つの台帳へ保存します。

• タスク、スレッド、ターン及びレスポンスを特定するID
• 開始・終了日時、モデル、reasoning effort、verbosity及び出力形式
• input_tokens、cached_tokens、cache_write_tokens及びoutput_tokens
• 実行前後の利用制限値、リセット時刻及び課金額（取得できる場合）
• 利用したプラグイン、スキル及びツールの名称、バージョン、説明、スキーマ及び順序
• 文脈圧縮、アプリ更新、heartbeat及び外部ツール実行の時刻
• 入力資料の版、ハッシュ、取得元及び生成物の保存先
• 成功、失敗、再試行、人による承認及び未確認事項

画面に表示された「残り何パーセント」だけでは、入力、出力、キャッシュ書込み又は外部ツールのどこで使用量が増えたかを区別できません。

6.2　変更前後を比較する方法

比較では、同一の短いテスト資料と、秘密情報を含まない固定プロンプトを用意します。モデル、推論設定及び出力形式を固定し、変更する要素を一つにします。例えば、プラグインの有無を調べる回にモデルまで変更すると、原因を分離できません。

各条件を複数回実施し、最初のキャッシュ書込み回と、その後の読込み回を分けます。cached_tokens等が取得できる場合には、総使用率の印象ではなく、各フィールドの実測値を比較します。取得できない場合は「キャッシュミス」と断定せず、「利用量増加の原因は不明」と記録します。

6.3　停止・エスカレーション条件

次の場合は、同じ操作を繰り返さず、タスクを止めて人又は事業者へ確認します。

• 同じ認証、接続又は保存エラーが反復する場合
• 利用量が急増したが、内訳を取得できない場合
• 入力に秘密情報が含まれるか判断できない場合
• モデル又はプラグイン更新後に出力形式又は権限が変わった場合
• 外部公開、送信、削除又は課金を伴う場合

7　X投稿から得られる学びと限界

7.1　投稿者が述べた観察

2026年9月のX投稿では、投稿者が、キャッシュヒット時とミス時の体感差が大きかったこと、約30個のCodexタスクを使っていた環境で運用を変更した後に週次使用量が低下したことを述べています。また、少数のメインタスクと多数の一時的なワーカータスクに分け、ワーカーからプラグインを外すという運用例を紹介しています。

この投稿から直接いえるのは、「一利用者が、その環境でそのように観察した」ということまでです。タスク数又は削減率を、他の利用者にも当てはまる基準として扱うことはできません。

7.2　原因仮説は未確認であること

引用元投稿では、プロンプトの前方付近にあるプラグインのバージョン文字列が自動更新され、複数タスクのキャッシュを無効化した可能性が示されています。返信では、過去に修正された問題が、古くから継続しているタスクに残っていた可能性も述べられています。

これらは合理的に検討すべき仮説ですが、当該環境の完全な入力、各ターンのトークン内訳及びOpenAIによる個別の障害認定は確認できていません。したがって、本記事では原因を確定していません。

7.3　実務へ移す際の証拠区分

本件は、次のように区分すると誤解を避けやすくなります。

• 確認済みの製品仕様：OpenAI公式資料に書かれたキャッシュ照合、計測項目及びツール読み込みの一般的説明
• 利用者の供述：X投稿者が述べた使用状況、体感及び変更後の結果
• 推論：プラグインの動的な文字列が個別事象の原因であったという説明
• 不明：実際に変化した入力部分、影響を受けた全タスク及び製品側の内部原因

今回の中心は製品仕様と運用であるため、判例秘書の裁判例は直接の一次資料になりません。秘密保持義務又は損害賠償責任について個別の法的結論を述べる場合には、法令、契約文言及び裁判例を別途確認する必要があります。

8　実務チェックリスト

1. タスクの目的と終了条件を一文で固定したか。
2. 固定指示を前、案件固有の動的情報を後ろに置いたか。
3. そのタスクに不要なツール又はプラグインを読み込んでいないか。
4. 必要な一次資料へのアクセスまで外していないか。
5. モデル、推論設定、出力形式及びツール構成を記録したか。
6. 入力、キャッシュ読込み、キャッシュ書込み及び出力のトークンを分けて保存したか。
7. heartbeatに変化条件、通知条件及び停止条件があるか。
8. SNS投稿、公式仕様、推論及び不明事項を区別したか。
9. 秘密情報の入力先、保持、外部送信及び人のアクセスを確認したか。
10. 公開、送信又は削除の直前に、人が対象と内容を確認したか。
11. 実行後に管理画面又は公開画面から読み戻したか。
12. 効果を体感ではなく、同一条件の前後比較で確認したか。

9　関連記事

• スキャンPDFにおける表形式データをAIに正確に読み取らせる方法（AI作成）
• AI利活用に伴う民事責任－補助／支援型AI・依拠／代替型AI・AIエージェントで誰が責任を負うか（AI作成）
• 学習オフの生成AIに秘密情報を入力することは第三者開示に当たるか（AI作成）

10　参考資料

• OpenAI, Prompt caching
• OpenAI, GPT-5.5 model guidance
• OpenAI, Codex App Server
• OpenAI, Images and vision
• X投稿（主投稿）：suzukiAdIre氏の投稿
• X投稿（引用元）：suzukiAdIre氏の投稿
• X投稿（返信）：suzukiAdIre氏の投稿