目次
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投稿に出てくるタスク数は、その投稿者の運用例にすぎません。「メインは何個、ワーカーは何個が最適」という一般的な数値基準はありません。案件数、資料量、同時実行数、秘密情報の境界及びレビュー能力に応じて決めます。
並列数の上限を考えるときは、チャットの数と、その中で実際に動く処理の数を分けます。
同じ一つのタスクでも、検索、変換、ブラウザ操作等を同時に始めることがあるため、チャット数だけを負荷の指標にしません。
別々のファイルを担当させていても、同じPCのCPU、ストレージ、ファイル変更の確認、検査又は同期の処理が重なる可能性があります。
送信・公開・同じ完成物への書込みを担当ごとに整理した上で、通常の文書入力と確認作業を続けられるかも比較します。
これは運用上の評価方法であり、「何並列なら安全」という製品共通の基準ではありません。
一端末では，Codex関連プロセスが15個以上で長時間稼働しても異常終了がなかった一方，複数チャットと監視用セッションを短時間に起動した際にCodex・Node・総プロセス数及びCPU使用率が急増しました。
このため，最大本数を決める場合も，絶対数だけでなく一定時間内の増加数を停止条件へ加えます。
例えば，主チャットを最大15本としつつ，2分間に3本までの段階起動とし，負荷の急増時には新規起動を保留する方法が考えられます。
これは一端末の暫定運用例であり，製品共通の推奨値ではありません。
4.2 必要な能力だけを各タスクへ渡すこと
ワーカータスクには、担当する作業に必要な資料、ツール及び出力様式だけを渡します。しかし、一次資料へのアクセス又は出典記録が必要な調査タスクから、その能力を外してはいけません。
また、ワーカーの結果をメインへ戻す際には、結論だけでなく、参照資料、該当箇所、未確認事項及び再現に必要なIDを一緒に渡します。要約だけを引き継ぐと、後で根拠をたどれなくなるからです。
4.3 heartbeatを短くし、停止条件を定めること
定期監視又は自動継続では、毎回長い経緯を再送するのではなく、監視対象、前回値、今回値、変化があった場合の行動及び停止条件を短く固定します。状態に変化がない場合は通知しないという条件も有用です。
終了済み、権限不足、同じエラーが反復した場合又は人の判断が必要な場合には、無期限に再試行せず停止します。heartbeatが有用な監視をしているのか、単に文脈を再処理しているのかを、一定期間ごとに見直す必要があります。
待機の呼出しが長く続いたという記録と、その間ずっとCPUを占有したという記録は異なります。
実行中の表示や待機時間だけから負荷を決めず、実際のツール呼出しとPC側の測定区間を照合します。
停止後に引継ぎの作成まで依頼する場合は、本体の作業と引継ぎの作業を分け、終了条件をそれぞれ記録します。
確認のための短い呼出しを無制限に増やさず、状態の変化がないときの確認間隔も決めておきます。
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及び外部ツール実行の時刻
- 入力資料の版、ハッシュ、取得元及び生成物の保存先
- 成功、失敗、再試行、人による承認及び未確認事項
- ローカルPCで動かした場合は、同時タスク数、利用可能メモリ、コミット、CPU、ディスク待ち、表示系ログ及び遠隔接続の有無
PC側の測定を特定タスクと対応させる場合は、取得可能なPID、プロセスの開始時刻、起動元、処理の内容及び測定区間を残します。
同名プロセスや、一つのプロセスを複数のタスクが共用する場合には、名前と個数だけでタスク別の使用率を算定しません。
主チャット数，監視・保護・継続用セッション数，Codex関連プロセス数，Node関連プロセス数，PC全体のプロセス数及び各数値の5分間増加量も分けて記録します。
「チャットを閉じた」「停止を依頼した」という画面上の状態だけで，子プロセス又は補助処理が終了したとは扱いません。
CPUの累積時間と区間使用率、プロセスのI/O転送量と物理ディスクの入出力も別々に扱います。
必要な情報を権限等により取得できない場合は、対応付けられなかった範囲を明示し、読めた部分だけで内訳全体を説明しません。
画面に表示された「残り何パーセント」だけでは、入力、出力、キャッシュ書込み又は外部ツールのどこで使用量が増えたかを区別できません。
また、ChatGPT又はAPIの使用量と、Codexが手元のPCで検索、変換、ビルド、ブラウザ操作又は多数の子プロセスを動かしたときの負荷は別です。ローカルPCの停止を調べる場合は、トークン台帳だけでなくWindows側の性能ログを同じ時刻で照合します。
自宅PCから事務所PCへ遠隔接続した場合は、遠隔画面だけの切断、表示系の停止及びWindows全体の停止を分け、直接操作時と同じ条件で比較します。期限、送信成否及び安全な再開は、弁護士・税理士のAI業務用PCがフリーズしたときの初動－期限管理，送信成否，ログ保全及び安全な再開（AI作成）を参照してください。
6.2 変更前後を比較する方法
比較では、同一の短いテスト資料と、秘密情報を含まない固定プロンプトを用意します。モデル、推論設定及び出力形式を固定し、変更する要素を一つにします。例えば、プラグインの有無を調べる回にモデルまで変更すると、原因を分離できません。
各条件を複数回実施し、最初のキャッシュ書込み回と、その後の読込み回を分けます。cached_tokens等が取得できる場合には、総使用率の印象ではなく、各フィールドの実測値を比較します。取得できない場合は「キャッシュミス」と断定せず、「利用量増加の原因は不明」と記録します。
並列化の比較では、同じ種類・分量の複製資料と同程度の時間を使い、一度に変える条件を一つにします。
完了・検証済みの成果物数、人の確認時間、入力や保存を妨げた時間、復旧に要した時間を併せて記録します。
重要な事件資料の上書き、提出又は公開を、負荷を再現するためだけに繰り返しません。
手元のPCの症状を調べる場合の詳細は、Claude Code・Codexでパソコンがフリーズする原因を参照してください。
6.3 停止・エスカレーション条件
次の場合は、同じ操作を繰り返さず、タスクを止めて人又は事業者へ確認します。
- 同じ認証、接続又は保存エラーが反復する場合
- 利用量が急増したが、内訳を取得できない場合
- 入力に秘密情報が含まれるか判断できない場合
- モデル又はプラグイン更新後に出力形式又は権限が変わった場合
- 外部公開、送信、削除又は課金を伴う場合
HTTP 429又は「Too Many Requests」が表示された場合も、同じ操作を連打せず、ChatGPTプランの使用上限、APIのリクエスト・トークン上限、残高・支出上限及びファイル処理上限をエラーコードで分けて確認します。
同じアカウント又は同じAPI組織・プロジェクトのまま別IP・別PCへ移っても通常の上限はリセットされないため、原因別の確認方法は、Codexで４２９エラーが出る原因と対策－別IP・別PCで回避できるか（AI作成）を参照してください。
6.4 残量の回復を節約効果と取り違えないこと
使用量を比較するときは，アカウント，ワークスペース，対象の利用枠，残量，次回の回復日時及び保存済みリセットの使用状況も記録します。
OpenAIは，通常の周期更新とは別に，対象者の利用枠へ直接適用する自動リセットを説明しています。
リセットによって次回の回復日時が変わる場合もあるため，残量が増えたことだけでは，キャッシュの改善やプロンプト短縮の効果を測定できません。
比較する期間の途中に周期更新やリセットがあれば，その前後を区切って記録します。
実行量，モデル，設定及び対象枠が異なる結果も，同じ条件の節約率として扱わないようにします。
グローバルリセットは保存済みリセットの履歴に表示されず，残量や日時の変化だけでは個別の適用を特定できない点も残しておきます。
回復の仕組みと確認方法は，Codexの週間使用枠が予定日前に回復する理由で整理しています。
出典：OpenAI「How resets work in Codex」（令和８年１０月２８日確認）。
通常の文字入力や確認作業を妨げる状態が続く場合も、新たな重い処理を増やさず、作業を区切って状態を確認する条件に含めます。
送信・保存の成否と未保存データを確認し、本体の停止、引継ぎの継続、別に動く処理の確認を分けます。
反応が改善したことは原因を絞る手掛かりですが、一度に複数の条件が変わった場合は、一つのタスクや製品だけを原因と断定しません。
調査・復旧のための処理も記録し、必要な作業を保持した上で再開する範囲を決めます。
7 X投稿から得られる学びと限界
7.1 投稿者が述べた観察
2026年9月のX投稿では、投稿者が、キャッシュヒット時とミス時の体感差が大きかったこと、約30個のCodexタスクを使っていた環境で運用を変更した後に週次使用量が低下したことを述べています。また、少数のメインタスクと多数の一時的なワーカータスクに分け、ワーカーからプラグインを外すという運用例を紹介しています。
この投稿から直接いえるのは、「一利用者が、その環境でそのように観察した」ということまでです。タスク数又は削減率を、他の利用者にも当てはまる基準として扱うことはできません。
7.2 原因仮説は未確認であること
引用元投稿では、プロンプトの前方付近にあるプラグインのバージョン文字列が自動更新され、複数タスクのキャッシュを無効化した可能性が示されています。返信では、過去に修正された問題が、古くから継続しているタスクに残っていた可能性も述べられています。
これらは合理的に検討すべき仮説ですが、当該環境の完全な入力、各ターンのトークン内訳及びOpenAIによる個別の障害認定は確認できていません。したがって、本記事では原因を確定していません。
7.3 実務へ移す際の証拠区分
本件は、次のように区分すると誤解を避けやすくなります。
- 確認済みの製品仕様：OpenAI公式資料に書かれたキャッシュ照合、計測項目及びツール読み込みの一般的説明
- 利用者の供述：X投稿者が述べた使用状況、体感及び変更後の結果
- 推論：プラグインの動的な文字列が個別事象の原因であったという説明
- 不明：実際に変化した入力部分、影響を受けた全タスク及び製品側の内部原因
今回の中心は製品仕様と運用であるため、判例秘書の裁判例は直接の一次資料になりません。秘密保持義務又は損害賠償責任について個別の法的結論を述べる場合には、法令、契約文言及び裁判例を別途確認する必要があります。
8 実務チェックリスト
- タスクの目的と終了条件を一文で固定したか。
- 固定指示を前、案件固有の動的情報を後ろに置いたか。
- そのタスクに不要なツール又はプラグインを読み込んでいないか。
- 必要な一次資料へのアクセスまで外していないか。
- モデル、推論設定、出力形式及びツール構成を記録したか。
- 入力、キャッシュ読込み、キャッシュ書込み及び出力のトークンを分けて保存したか。
- ローカルPCで動かした場合は、トークン使用量とWindows側のメモリ、CPU、ディスク及び表示系を別々に記録したか。
- heartbeatに変化条件、通知条件及び停止条件があるか。
- SNS投稿、公式仕様、推論及び不明事項を区別したか。
- 秘密情報の入力先、保持、外部送信及び人のアクセスを確認したか。
- 公開、送信又は削除の直前に、人が対象と内容を確認したか。
- 実行後に管理画面又は公開画面から読み戻したか。
- 効果を体感ではなく、同一条件の前後比較で確認したか。
9 関連記事
- スキャンPDF・文字データのあるPDFの表をAIに正確に読み取らせる方法（AI作成）
- AI利活用に伴う民事責任－補助／支援型AI・依拠／代替型AI・AIエージェントで誰が責任を負うか（AI作成）
- 学習オフの生成AIに秘密情報を入力することは第三者開示に当たるか（AI作成）
- Claude Code・Codexでパソコンがフリーズする原因－メモリ8GB・16GB・32GB・64GBの違い（AI作成）
- Windows 11がフリーズした原因を後から調べる方法―最後のコマンド，パフォーマンスモニター及びイベントビューアー（AI作成）
- Kernel-Power Event 41とは―BugcheckCode，PowerButtonTimestamp及び強制終了時刻の読み方（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氏の投稿
- Microsoft, Collecting Performance Data（CPU使用率の区間計算，同名プロセスの識別）
- Microsoft, Win32_PerfRawData_PerfProc_Process)（プロセスのI/O指標の範囲）