Codex処理のトークン量データの活用方法

2026年6月24日2026年6月25日

下記の記事を作成した際、Codexに、「使用量に関する情報をHA（HOME Assistant）のダッシュボードに表示することはできませんか」と質問したところ、下図の項目（セッション、ターン、入力トークン、出力トークン、キャッシュ、推論出力、最終利用）が回答された。
トークンの量に関係する項目が回答されることは予想できたが、キャッシュとか推論出力とか、予想外の項目も回答された。

これらの項目が回答されたため、下記の記事でも、これらの項目からどのようなことが推定できるかと追加質問したところ、下記の2つの表のように回答され、実行中にAIがどのような状態にあったかや、実行した処理がAIにとってどのようなものであったかについての目安のような情報が得られることが分かった。本記事では、これらの情報の活用方法をさらに検討した。
結論としては下記の用途に使えるのではないかということだが、そこに至るまで試行錯誤した過程も紹介する。

1. Codexの各処理にかかった費用（目安）算出
　各トークン量から算出した各処理の費用（目安）を、HAダッシュボードの処理一覧表の項目に追加表示する。
2. Codexが処理の状況・要望をユーザーに通知
　例えば、「推論が難航しているので時間がかかりそうです」というユーザー向けメッセージ生成に利用する。
3. 評価指標
　例えば、どのファイル形式でCodexにデータを入力するのがよいかを判断するための評価指標として利用する。

見方	推定できること
入力トークンが多い	Codex に渡された文脈が大きい。長い会話、複数ファイル、ログ、添付資料、過去履歴を多く読んでいる可能性
キャッシュが多い	以前渡した文脈を再利用できている。長いセッションでも効率よく続けられている可能性
出力トークンが多い	Codex が長い説明、コード、設定、レポートなどを多く返した
推論出力が多い	表には出ない内部検討が多い。複雑な判断、デバッグ、複数案比較、手順設計が多かった可能性

パターン	解釈
入力多い + キャッシュ多い	大きな文脈を使っているが、再利用が効いている
入力多い + キャッシュ少ない	新しい資料やファイルを大量に読んでいる。初回処理や大きな探索の可能性
出力多い + 推論出力少ない	比較的まっすぐな生成作業。文章作成、設定出力、一覧化など
出力少ない + 推論出力多い	表には短く出ているが、内部ではかなり考えている。原因調査や設計判断で起きやすい
入力多い + 推論出力多い	大きな文脈を踏まえた難しい処理。複数ファイル修正や障害調査など
キャッシュ少ない状態が続く	セッションや文脈再利用がうまく効いていない可能性

推論出力の費用と、費用に関係するトークン量の計算方法

ChatGPTのAPIを利用する場合、入力トークンと出力トークンの量に応じて費用が発生しますが、このセッションの回答に含まれる「推論出力」のトークン量は費用に関係しないのですか。また、費用に関係するトークン量の計算方法について教えてください

はい。OpenAI APIとして使う場合、「推論出力」は費用に関係します。
理由は、推論トークンはAPIから見える本文ではありませんが、出力トークンとして課金されるためです。
OpenAI公式ドキュメントでも、reasoning tokens はAPIでは見えないが、コンテキストを使い、output tokensとして課金されると説明されています。

大事なのはここです。

項目	課金上の扱い
入力トークン	入力料金
キャッシュ入力トークン	キャッシュ入力料金
出力トークン	出力料金
推論出力	出力トークンの内訳。別枠で二重加算しない
合計トークン	`入力 + 出力`。ただし費用計算では単純に合計だけでは不十分

APIの usage では、たとえば次のように出ます。

{
  "input_tokens": 139,
  "input_tokens_details": {
    "cached_tokens": 0
  },
  "output_tokens": 438,
  "output_tokens_details": {
    "reasoning_tokens": 64
  },
  "total_tokens": 577
}

この例では、reasoning_tokens: 64 は output_tokens: 438 の中に含まれています。
つまり、費用計算で 438 + 64 としてはいけません。

基本式

非キャッシュ入力 = input_tokens - cached_tokens

費用 =
  非キャッシュ入力 × 入力単価
+ キャッシュ入力 × キャッシュ入力単価
+ output_tokens × 出力単価

reasoning_tokens はすでに output_tokens に含まれるので、追加で足しません。

例

仮に GPT-5.4 mini の料金を使うと、公式価格は以下です。

区分	単価
Input	$0.75 / 1M tokens
Cached input	$0.075 / 1M tokens
Output	$4.50 / 1M tokens

たとえば：

input_tokens = 10,000
cached_tokens = 4,000
output_tokens = 2,000
reasoning_tokens = 1,500

この場合：

非キャッシュ入力 = 10,000 - 4,000 = 6,000

費用 =
  6,000 / 1,000,000 × $0.75
+ 4,000 / 1,000,000 × $0.075
+ 2,000 / 1,000,000 × $4.50

= $0.0045
+ $0.0003
+ $0.0090
= $0.0138

ここで reasoning_tokens = 1,500 は、output_tokens = 2,000 の内訳なので、別途課金に足しません。

注意点として、max_output_tokens は、見える回答だけでなく、推論トークンも含めた生成トークン上限です。
推論中に上限へ達すると、見える回答がほとんど出なくても入力と推論分の費用が発生し得ます。

なお、ChatGPTアプリやCodexアプリのサブスクリプション利用と、OpenAI APIの従量課金は別物です。
APIキーを使って直接APIを呼ぶ場合は上記の考え方で、アプリ内表示の「推論出力」はAPI課金に近い内訳として見るのがよいです。

この質問で次のことが分かった。
・推論出力のトークンは、出力トークンに含まれている
・キャッシュ入力料金も費用に含まれる

ある処理を実行する前の各トークン量と、その処理を実行した後の各トークン量との差分から、今実行した処理にかかった費用を算出できますか

はい、できます。
ただし条件があります。
その処理の前後で、他のCodex/API処理が混ざっていないこと、または 処理単位でトークン量を分けて記録できていること が必要です。

ポイントは、推論出力 の扱いです。

OpenAI API上では、reasoning tokens は見えない推論ですが、出力トークンとして課金対象です。
公式ドキュメントでも、reasoning tokens はAPIでは見えないが、context windowを使い、output tokensとして課金されると説明されています。
ただし、APIの usage.output_tokens は通常、reasoning tokensを含んだ出力合計です。
一方、あなたのダッシュボードで 出力トークン を「見える回答だけ」として集計している場合は、費用計算では 出力トークン + 推論出力 にする必要があります。

差分での計算方法

処理前後で次を取ります。

Δ入力 = 後の入力トークン - 前の入力トークン
Δキャッシュ = 後のキャッシュ - 前のキャッシュ
Δ出力 = 後の出力トークン - 前の出力トークン
Δ推論出力 = 後の推論出力 - 前の推論出力

APIの output_tokens が推論込みなら：

費用 =
  (Δ入力 - Δキャッシュ) × 入力単価
+ Δキャッシュ × キャッシュ入力単価
+ Δ出力 × 出力単価

ダッシュボードの 出力トークン が見える回答だけなら：

費用 =
  (Δ入力 - Δキャッシュ) × 入力単価
+ Δキャッシュ × キャッシュ入力単価
+ (Δ出力 + Δ推論出力) × 出力単価

例

GPT-5.4 mini の現在の標準価格例では、公式価格は：

区分	単価
入力	$0.75 / 100万tokens
キャッシュ入力	$0.075 / 100万tokens
出力	$4.50 / 100万tokens

差分が次だとします。

Δ入力 = 20,000
Δキャッシュ = 8,000
Δ出力 = 3,000
Δ推論出力 = 2,000

もし Δ出力 が見える回答だけなら：

非キャッシュ入力 = 20,000 - 8,000 = 12,000
課金出力 = 3,000 + 2,000 = 5,000

費用 =
  12,000 / 1,000,000 × $0.75
+  8,000 / 1,000,000 × $0.075
+  5,000 / 1,000,000 × $4.50

= $0.009
+ $0.0006
+ $0.0225
= $0.0321

つまり、この処理は約 $0.0321 です。

注意点は3つあります。

複数モデルが混ざる場合は、モデルごとに差分を分ける必要があります。
同じ時間に別セッションが動くと、差分に混ざります。
Batch、Priority、Data residency、画像・音声・ツール利用などは別料金体系になることがあります。

なので、ダッシュボードでやるなら、処理開始時スナップショット と 処理終了時スナップショット を保存し、モデル別に差分を出すとかなり実用的です。

参考: Responses API usage object、Reasoning models guide、OpenAI API Pricing

本セッションでは、HOME Assistantのダッシュボードに、添付画像の「使用量」を表示するように構成しています。また、「実行中・最近の処理」の表に処理が表示されています。この構成を修正して、「実行中・最近の処理」に表示された完了処理に「費用」の列を追加できるかを知りたいわけです。

はい、追加できます。
ただし、今の「Codex 使用量」は 直近24時間の合計値 なので、そのままでは「この完了処理1件にいくらかかったか」は正確には出せません。
正確に出すには、各処理の 開始時点の使用量スナップショット と 終了時点の使用量スナップショット を保存して、その差分から費用を計算する必要があります。

実装方針

対象	表示
実行中の処理	`計測中` または `-`
完了した処理	`$0.0123` のような費用
古い完了処理	スナップショットがなければ `算出不可`
複数モデル混在	モデル別に差分計算して合算

費用計算はこうです。

非キャッシュ入力 = 入力差分 - キャッシュ差分

費用 =
  非キャッシュ入力 × 入力単価
+ キャッシュ差分 × キャッシュ入力単価
+ 出力課金トークン × 出力単価

現在のダッシュボードでは 出力トークン と 推論出力 が別項目として見えているので、費用用には原則こう扱います。

出力課金トークン = 出力トークン差分 + 推論出力差分

OpenAIのAPIでは reasoning tokens は見えない推論ですが、出力トークンとして課金対象です。
公式のusage例でも output_tokens_details.reasoning_tokens として内訳表示され、reasoning tokens はAPIでは見えないが output tokens として課金される、と説明されています。
参考: Responses usage object、Reasoning models guide、OpenAI API Pricing

注意点

複数のCodex処理が同時に動くと、単純な前後差分では混ざります。
正確にするなら、処理IDごとに開始・終了スナップショットを保存し、できればモデル別の差分も持つ必要があります。

つまり結論は、「費用」列は追加可能です。
ただし、既存の24時間合計値から過去処理へ正確に割り当てるのではなく、今後の処理について開始時・終了時の差分を記録する方式にするのがよいです。

処理終了後の各トークン量を記録する履歴を残すようにし、次の処理が終了した際の各トークン量との差分を算出して、費用を、ダッシュボードの「実行中・最近の処理」の新しい列項目として追加してください

実装しました。実行中・最近の処理 の Claude Code / Codex 両方の表に 費用 列を追加し、ライブダッシュボード Claude Monitor Live にも反映済みです。

集約サーバー側では、完了時に使用量スナップショットを履歴として残し、次の完了時に前回スナップショットとの差分を計算するようにしました。実装箇所は [aggregator.py (line 308)] と [aggregator.py (line 640)]です。
履歴は jobs_state.json の cost_history に保存されます。

表示の動きは次の通りです。

実行中: 計測中
既存の古い完了行: -
変更後、最初に完了した処理: 基準
2件目以降: 単価設定があれば $0.0009 のように表示
単価未設定: 未設定

単価は変わり得るため、捏造せず設定ファイル方式にしました。
雛形は [model_cost_rates.example.json (line 1)]です。
実運用では同じ場所に model_cost_rates.json を置くと、input_per_million、cached_input_per_million、output_per_million から自動計算します。

検証は、Python構文チェック、YAML構文チェック、モック使用量での差分計算テスト、ライブダッシュボードへの反映確認、集約サーバー再起動後の稼働確認まで完了しています。
なお、公式料金表はこの実行環境からは保護ページが返って取得できなかったため、現時点では実単価をこちらで入れていません。そこだけ誠実に空欄です。

公式料金表のURLを教えてください。手動で取得し、このチャットに入力します

公式料金表はこちらです。

OpenAI API Pricing

このページで、使っているモデルごとの次の3つを確認してください。

Input
Cached input
Output

こちらに貼っていただければ、model_cost_rates.json に入れる形へこちらで整えます。

貼りました

PDFから料金を読み取り、設定しました。

作成した設定: [model_cost_rates.json (line 1)]

入れた単価は次の通りです。

モデル	Input	Cached input	Output
`gpt-5.5`	$5.00 / 1M tokens	$0.50 / 1M tokens	$30.00 / 1M tokens
`gpt-5.4`	$2.50 / 1M tokens	$0.25 / 1M tokens	$15.00 / 1M tokens
`gpt-5.4-mini`	$0.75 / 1M tokens	$0.075 / 1M tokens	$4.50 / 1M tokens

あわせて、gpt-5.4-mini-... のような接尾辞付きモデル名が gpt-5.4 ではなく gpt-5.4-mini の料金に当たるように修正しました。集約サーバーも再起動済みで、現在 running です。

次に完了する処理から、費用欄は 未設定 ではなく金額表示になるはずです。
最初の完了処理は差分の基準になるので 基準、その次から実際の差分費用が出ます。

費用は日本円で表示するようにしてください

対応しました。費用欄は今後、日本円で ¥0.93 や ¥12 のように表示されます。

変更した内容は、[aggregator.py (line 237)]で費用ラベルを円表示に変換し、[model_cost_rates.json (line 1)]に換算レートを追加しました。

現在の換算設定は次の通りです。

1 USD = 161.53 JPY
基準日: 2026-06-23
取得元: Frankfurter

参照: Frankfurter USD to JPY API

集約サーバーも再起動済みで、現在 running です。次に完了する処理から円表示になります。既に保存済みの過去行は、完了時に記録済みの表示文字列を持っている場合は自動再計算されません。

まだ調整中であるが、Codexの処理の費用の列をダッシュボードの「実行中・最近の処理」の表に追加してみた。

このセッションでは、HOME Assistantのダッシュボードを作成しましたが、作成したダッシュボードに表示される処理は、プロンプトに手動で入力して依頼した処理だけでなく、外部からCodexのAPIを利用する処理も表示され、トークン表示されると考えていいですか

結論から言うと、「Codex経由で動いている処理」なら表示・トークン集計の対象になりますが、外部のOpenAI APIを直接叩く処理は、そのままでは対象外です。

今の構成では、次の2つは別系統です。

項目	今の取得元	対象になるもの
実行中・最近の処理	`claude/job_update` に送られたジョブ状態	Codex/Claude Codeのフック、承認待ち、手動テスト、登録済みオートメーション
使用量・トークン	ローカルのCodex/Claude Codeセッションログ	Codexアプリ/Claude Codeが実際に使ったトークン

つまり、

処理の種類	処理一覧に出るか	トークン表示に入るか
このCodexセッションで手動依頼した処理	入る	入る
Codexオートメーションとして実行される処理	条件付きで入る	Codexセッションログに残れば入る
Claude Codeフック経由の処理	入る	Claude Codeログに残れば入る
Python等からOpenAI APIを直接呼ぶ処理	そのままでは入らない	そのままでは入らない
外部API処理が `job_notify` と使用量送信を実装している場合	入れられる	入れられる

ここでいう「APIを利用する処理」が、Codexアプリ/ Codexオートメーションの中で実行される処理という意味なら、基本的には対象になります。

一方で、たとえば別のPythonスクリプトが OPENAI_API_KEY を使ってOpenAI APIを直接呼ぶ場合、そのAPI使用量は Codexのローカルセッションログには自動では入りません。
その場合は、APIレスポンスの usage をそのスクリプト側で取得し、Home Assistant向けの集約サーバーへ送る仕組みが必要です。

現在の実装上も、Codex使用量は [usage_summary.py (line 167)]でローカルログを読んでいます。
処理一覧は [aggregator.py (line 8)]が claude/job_update を受け取って表示しています。

なので、正確にはこうです。

今のまま表示されるもの
Codex/Claude Codeのフックやセッションログで把握できる処理。

追加実装すれば表示できるもの
外部スクリプトやAPI処理。
開始・終了・使用量をMQTTなどで送れば、同じダッシュボードに載せられます。

費用列まで入れるなら、外部API処理については特に、APIレスポンスの usage を処理単位で記録する必要があります。

ダッシュボードの「実行中・最近の処理」に表示する処理は、現状のまま、Codexセッションで手動依頼した処理のみとする。外部スクリプトやAPI処理の法要については、必要であれば別途検討することとする。

追加費用についての調査

ついでに、Web検索などを伴う処理の場合の費用についても調べてみた。

Web検索、画像、音声、Container、Batch、Priority/Flexなどを使う場合の費用（概算）の計算方法は分かりますか

はい、概算方法は分かります。
考え方は 「通常のモデル使用料」＋「追加機能の料金」＋「サービス階層の補正」 です。

種類	概算方法
Web検索	通常の入力/出力トークン費用に、web_search_call の検索回数分を加算します。公式価格表では Web search は `$10 / 1k calls`、検索結果本文のトークンは無料扱いです。検索アクション自体に tool call cost が発生します。
画像入力	画像はトークンに変換されて課金されます。画像サイズ、`detail`、モデルにより計算方式が変わります。最も安全なのは API の `usage` または公式の画像料金計算を使うことです。
画像生成/編集	テキスト入力、画像入力、画像出力の各トークンに、画像モデル用の単価を掛けます。通常のテキストモデルとは別単価の場合があります。
音声/Reatime	会話型Realtimeは `response.done` の `usage` にある text/audio/image/cached tokens を記録して計算します。音声入力は目安としてユーザー音声100msで1 audio token、音声出力は50msで1 audio tokenです。
音声の文字起こし/翻訳	Realtimeのストリーミング翻訳・文字起こしは、通常のResponse単位ではなく、時間単位の料金で見る方式です。
Container / Code Interpreter	モデルのトークン費用に加えて、コンテナのメモリ階層と利用セッション単位の料金を足します。価格表ではContainerは1GB/64GBなどの料金が示されています。
Batch	通常の同期APIより入力/出力が50%安い扱いです。つまり通常計算した金額に概ね `0.5` を掛けます。
Priority	`service_tier="priority"` の場合、通常より高いPriority用の入力/キャッシュ入力/出力単価を使います。実際にStandardで処理された場合はStandard料金です。
Flex	`service_tier="flex"` の場合、Batch API rates相当で計算します。リソース不足で失敗した場合は課金されない扱いです。

したがって、Pythonスクリプトでは、各API呼び出しごとに次を保存すればかなり実用的です。

model
service_tier
input_tokens
cached_tokens
output_tokens
reasoning_tokens
text/audio/image別トークン
web_search_call件数
container_id / memory_limit / 利用時間
batchかどうか
エラー時に課金対象かどうか

最終式はざっくりこうです。

概算費用 =
  通常モデル費用
+ Web検索回数 × Web検索単価
+ 画像/音声/Containerなどの追加費用

そのうえで Batch や Flex なら割引単価、Priority ならPriority単価に切り替える、という形です。

公式情報では、Web search料金、Container料金、Batchの50%割引、Priority/Flexの考え方、画像のトークン課金、Realtime音声のusage取得方法が確認できます。
料金は変わるので、単価は設定ファイル化しておくのがよいです。
参照: OpenAI API Pricing、Batch API、Flex processing、Priority processing、Images and vision、Realtime costs。

様々な費用が発生していることが分かったが、そこまで費用の内訳を細かく分類表示する必要も無いので、ダッシュボードの費用は現状のままとし、費用に関する調査、費用に関するトークン量データの活用検討「1. Codexの各処理にかかった費用（目安）算出」はここまでとする。

次に、実行中にAIの活動状態を知ってユーザーに通知する検討（「2. Codexが処理中に状況・要望をユーザーに通知」）にうつる。

AIの活動状態を知る手がかりとなるか

まず、AIの活動状態を判断するための指標を各トークン量から作れないかを確認した。

回答してもらった各トークン量の数値から、いくつかの指標が作れませんか。
例えは、他の数値との関係（例えば相対的関係）によって「推論出力」が多い度合いを「パニック度」として、そのパニック度の値または変化を何かの役に立てられませんか。

はい、作れます。かなり面白い指標になります。
ただし「推論出力が多い = Codexがパニック」と断定はできないので、正式名は少し中立的にして、表示名として「パニック度（推論負荷）」のようにするのがよさそうです。

作れそうな指標

指標	計算例	意味
パニック度	`推論出力 ÷ (出力トークン + 1)`	表に出た回答量に対して、内部検討がどれだけ多かったか
推論比率	`推論出力 ÷ (出力トークン + 推論出力)`	生成全体のうち、見えない推論が占める割合
キャッシュ率	`キャッシュ ÷ 入力トークン`	文脈再利用が効いている度合い
新規文脈率	`(入力トークン - キャッシュ) ÷ 入力トークン`	新しく読んだ情報が多い度合い
応答密度	`出力トークン ÷ 入力トークン`	読んだ量に対して、どれだけ返答したか
文脈負荷	`入力トークン ÷ コンテキスト上限`	コンテキストウィンドウの圧迫度
重作業度	`(入力 + 出力 + 推論出力) の合計`	その時間帯の処理の重さ
迷走・難航サイン	`パニック度上昇 + キャッシュ率低下 + 文脈負荷上昇`	調査が難航している可能性

特に使えそうなのは パニック度 と キャッシュ率 の組み合わせです。

状態	解釈
パニック度高い + キャッシュ率高い	既存文脈を使いながら難しい判断をしている
パニック度高い + キャッシュ率低い	新しい情報を大量に読みながら悩んでいる。調査・障害対応で起きやすい
パニック度低い + 出力多い	比較的まっすぐな生成作業
パニック度急上昇	途中で難しい分岐、エラー、設計判断に入った可能性
キャッシュ率急低下	新しい資料・ファイル・セッション文脈が増えた可能性

実用面では、次のように役立てられます。

パニック度が高い状態が続く
作業が難航している可能性。ユーザーに確認を求める、方針を整理する、ログを見る、などの合図にできる。
文脈負荷が高く、キャッシュ率も高い
長いセッションをうまく継続できているが、そろそろ要約や新スレッド化を検討する目安になる。
文脈負荷が高く、キャッシュ率が低い
新しい情報を詰め込みすぎている可能性。添付資料・ログ・ファイル読み込みが重くなっているサイン。
推論比率が急に上がる
見た目の返答は短くても、内部では難しい判断をしている。障害調査や設計変更のタイミングを検知できる。

おすすめの表示名は、少し遊びを残すなら：

パニック度
推論負荷
迷い度
難航度
内部検討比率

ダッシュボードに出すなら、まずはこの3つがよいです。

パニック度 = 推論出力 ÷ 出力トークン
キャッシュ率 = キャッシュ ÷ 入力トークン
文脈負荷 = コンテキスト使用量

この3つだけでも、「重い作業なのか」「文脈を再利用できているのか」「そろそろ整理が必要か」がかなり見やすくなります。

複数のトークン量から作れる指標を回答してもらいましたが、それらに基づくメッセージをダッシュボードに表示する場合の表示案を、下記の形式で回答してください。表形式にしてください。
・文書（例：推論が難航しており時間がかかりそうです）
・絵文字（例: 😂, ✨, 🔥, 👍）
・顔文字（例：(^^) （笑顔）、(T_T) （泣き顔）、＼(^o^)／（お手上げ／オワタ））

以下のように、トークン指標からダッシュボード用メッセージを出し分ける案がよいと思います。

指標・状態	文書	絵文字	顔文字
推論比率が低い	順調に処理しています	👍	(^^)
推論比率がやや高い	少し考えながら進めています	🤔	(・・?)
推論比率が高い	推論が難航しており時間がかかりそうです	🔥	(-_-;)
推論出力が急増	判断が複雑になっています。中間確認が必要かもしれません	⚠️	(；・∀・)
入力トークンが多い	読み込んでいる情報量が多いです	📚	(◎_◎;)
入力多い + 推論多い	大量の情報を踏まえて慎重に判断しています	🧠	(｀・ω・´)
出力多い + 推論少ない	生成中心の処理です。比較的まっすぐ進んでいます	✨	(^_^)
出力少ない + 推論多い	表示は短いですが、内部ではかなり検討しています	🔍	(￣^￣)
キャッシュ率が高い	文脈の再利用が効いています	♻️	(^^)v
キャッシュ率が低い	新しい情報の読み込みが多めです	📥	(・_・;)
コンテキスト使用量が高い	コンテキストが膨らんでいます。区切り時かもしれません	🧱	(汗)
迷走・難航サイン	処理が迷っています。方針確認をおすすめします	🚧	＼(^o^)／（これはお手上げの意）
費用増加ペースが高い	この処理は費用が大きくなりやすいです	💸	(T_T)
全体的に軽い処理	軽い処理として完了できそうです	🟢	(^^♪)
完了時・問題なし	処理は安定して完了しました	✅	(^o^)

個人的には、ダッシュボードでは「文書 + 絵文字」までで十分見やすく、顔文字は詳細表示や遊び要素として入れるくらいがちょうどよさそうです。

ダッシュボードに表示するのとは別の話ですが、Codexに依頼した処理の完了後にこれらのメッセージを、回答の最後に添付してもらうことはできますか。例えば、プロンプトに入力する指示内容に、これらのメッセージを追加する指示を追加しておくとか、「カスタム指示」にこれらのメッセージを追加するように入力しておくとかの方法で。

はい、できます。おすすめは「カスタム指示」または AGENTS.md に入れる方法です。

ただし注意点があります。
回答の最後に付けられるのは、基本的には Codex自身の作業感に基づく推定メッセージ です。
実際の「推論出力トークン」「キャッシュ率」「費用差分」などは、処理後にログや集約スクリプト側で確定するため、回答生成中のCodexが完全に正確な数値として参照できるとは限りません。

入れるなら、例えばこういう指示がよいです。

各作業の最終回答の末尾に、以下の「処理メッセージ」を1行追加してください。

処理メッセージは、作業中の状況から推定して選んでください。
厳密なトークン値ではなく、入力量、調査量、判断の難しさ、出力量、エラー対応の有無に基づく目安で構いません。

形式:
処理メッセージ: 文書 / 絵文字 / 顔文字

例:
処理メッセージ: 順調に処理できました / ✅ / (^o^)
処理メッセージ: 推論が難航しており時間がかかりました / 🔥 / (-_-;)
処理メッセージ: 大量の情報を踏まえて慎重に判断しました / 🧠 / (｀・ω・´)

より実用的には、最後の1行だけに絞るのがよいです。

最終回答の末尾に、作業状況を表す短い「処理メッセージ」を必ず1行追加してください。
形式は「処理メッセージ: 文書 / 絵文字 / 顔文字」としてください。

一方で、本当にトークン量に基づく正確なメッセージにしたい場合は、回答本文ではなく、現在作っている Home Assistant 側の集約処理で判定して表示する方が向いています。
回答末尾に付ける方式は「Codexの自己評価」、ダッシュボード方式は「ログに基づく後判定」と考えるのが一番きれいです。

処理メッセージ: 回答末尾への追加は可能ですが、正確な数値判定は外部集計向きです / 👍 / (^^)

AIの処理完了後に報告する方法だが、ユーザーに、各トークン量に基づく通知を行えることが確認できたので、「2. Codexが処理中に状況・要望をユーザーに通知」）の検討はここまでとする。

次は、各トークン量を、入力データなどの評価指標に使えないかを検討する。

評価指標としての活用

各トークン量及びそれらのトークン量から算出される指標の活用方法として、下記の方法はどうですか。評価してください。

・複数の質問を、表現を変えて行い、どの表現が良かったかの評価に、推論比率やキャッシュ率の指標を利用する。
・複数の質問を、データ形式やファイル形式を変えて行い、どの方法が良いかを、処理速度、処理費用、入力効率などに基づいて判断するのに活用する。
・複数の文書を入力して、それらの推論比率を比較して、内容の難しさの比較に使う。
・迷い度とか難航度とかから、回答の信頼性を算出し、回答とともに信頼性の数値を伝える。

かなり良い活用案です。ただし、トークン指標は「品質そのもの」ではなく、処理の重さ・効率・難しさの代理指標として扱うのが安全です。

活用方法	評価	使える指標	注意点	おすすめ度
質問表現を変えて、どの表現が良かったか評価する	有効。ただし補助指標向き	推論比率、出力量、処理時間、再質問回数	推論比率が高い質問が「良い」とは限りません。難しく伝わっているだけの場合もあります	高
データ形式・ファイル形式を変えて、効率を比較する	とても有効	入力トークン、キャッシュ率、処理時間、費用、エラー率	同じ内容・同じモデル・同じ指示で比較する必要があります	非常に高
複数文書の推論比率を比較して、内容の難しさを見る	使えるが慎重に	推論比率、推論出力/入力、処理時間、要約失敗率	文書の長さや構造の違いを補正しないと不公平です	中〜高
迷い度・難航度から回答の信頼性を算出する	そのまま信頼性にするのは危険	推論比率、修正回数、ツール失敗、検証回数	「難航した＝不正確」とも「簡単だった＝正確」とも言えません	中

特に良いのは2つ目です。
データ形式の比較は、トークン指標と相性がかなり良いです。
例えば同じ内容を PDF、Markdown、CSV、JSON、テキスト貼り付けで試し、以下を比較できます。

比較項目	見るもの
入力効率	入力トークンが少ないか
再利用効率	キャッシュ率が高いか
費用効率	1処理あたりの概算費用
処理安定性	エラー、確認要求、やり直しが少ないか
出力品質	必要な答えに到達しているか

一方、1つ目の「質問表現の改善」は、推論比率だけで判定しない方がよいです。
良いプロンプトは、場合によっては推論比率が下がります。
つまり、Codexが迷わず処理できた、という意味です。
逆に、良い質問だから深く考えた結果、推論比率が上がることもあります。

そのため、質問表現の評価はこう見るのがよいです。

状態	解釈
推論比率が低く、回答品質が高い	良い質問。意図が明確
推論比率が高く、回答品質が高い	難しいが、深い検討を引き出せた質問
推論比率が高く、回答品質が低い	質問が曖昧、条件不足、または難しすぎる可能性
推論比率が低く、回答品質が低い	表面的に処理されている可能性

4つ目の「信頼性スコア」は、名前を少し変えた方が安全です。
「回答の信頼性」と言い切るより、検証推奨度、難航度、注意度のようにした方が実態に合います。

例えばこうです。

指標名	意味
難航度	内部処理が重かった度合い
迷い度	試行錯誤や判断の複雑さ
検証推奨度	ユーザー確認や追加検証を勧める度合い
効率スコア	入力・キャッシュ・費用の効率
生成負荷	出力や推論にどれだけコストがかかったか

結論としては、提案された使い方はかなり実用的です。
ただし、品質評価や信頼性評価に直接使うのではなく、「比較」「改善」「注意喚起」「検証優先度」のために使うのが一番よいと思います。

どの評価方法も補助的なものであるが、入力したデータやプロンプトがAIにとってどのようなものであるかを評価するのに補助的に使える可能性があることが分かった。

画像・音声・動画を入力して、どの形式で入力するのが最適かを判断するための比較試験を行う場合、変えるべき条件をそれぞれ教えてください。

はい。比較試験では、画像・音声・動画ごとに、変えるべき条件が少し違います。
基本は「1回の試験で変える条件は1つだけ」にすると、どの条件が効いたか分かりやすいです。

共通で固定する条件

固定するもの	理由
同じモデル	モデル差を排除するため
同じプロンプト	指示の違いによる影響をなくすため
同じ評価基準	正確性、処理時間、費用などを同じ物差しで見るため
同じ入力内容	形式だけを比較するため
同じセッション条件	メモリや前文脈の影響を減らすため

画像入力

変える条件	比較する例	見るべき指標
ファイル形式	PNG / JPEG / WebP / PDF内画像	読み取り精度、ファイルサイズ、費用
解像度	原寸 / 50%縮小 / 25%縮小	文字・細部の認識精度、処理速度
圧縮率	高画質JPEG / 中画質JPEG / 低画質JPEG	画質劣化による誤認識
色	カラー / グレースケール / 白黒	OCRや図表認識への影響
トリミング	全体画像 / 必要部分だけ切り出し	入力効率、認識精度
余白・背景	余白あり / 余白削除	無駄な入力の削減効果
画像枚数	1枚 / 複数枚分割	文脈理解、処理時間
文字の向き	正位置 / 回転補正済み	OCR精度

画像では、まず PNG原寸、JPEG中圧縮、必要部分だけトリミング の3パターンを比べると実用的です。

音声入力

変える条件	比較する例	見るべき指標
ファイル形式	WAV / FLAC / MP3 / M4A	文字起こし精度、容量、処理時間
圧縮率	非圧縮 / 高音質圧縮 / 低音質圧縮	聞き間違い、固有名詞の精度
サンプリングレート	16kHz / 44.1kHz / 48kHz	音声認識精度と容量
モノラル・ステレオ	モノラル / ステレオ	話者分離、容量
ノイズ処理	未処理 / ノイズ除去済み	認識精度、音声の不自然さ
音量正規化	未処理 / 正規化済み	小さい声の認識
無音削除	無音あり / 無音削除済み	処理時間、費用
分割単位	全体一括 / 5分ごと / 話題ごと	文脈維持、誤認識、処理失敗率
入力方法	音声そのもの / 事前文字起こしテキスト	費用、精度、要約品質

音声では、WAV/FLACの高品質版 と M4A/MP3の軽量版、さらに 文字起こし済みテキスト版 を比較すると判断しやすいです。

動画入力

変える条件	比較する例	見るべき指標
入力形式	動画そのもの / 静止画抽出 / 音声文字起こし	精度、費用、処理時間
解像度	1080p / 720p / 480p	画面内文字・細部の認識
フレームレート	30fps / 10fps / 1fps抽出	動きの理解、入力量
静止画抽出間隔	1秒ごと / 5秒ごと / シーン変化ごと	重要場面の拾い漏れ
音声の扱い	音声あり / 音声なし / 文字起こし別添付	内容理解、費用
字幕・テロップ	動画内字幕 / 別テキスト化	OCR精度、要約精度
分割単位	全体一括 / シーンごと / 章ごと	文脈維持、処理安定性
圧縮率	高画質 / 中画質 / 低画質	視覚情報の劣化
画面範囲	全画面 / 注目領域だけクロップ	入力効率、認識精度

動画では、いきなり動画全体を入れるより、次の3方式を比べるのが現実的です。

方式	向いている用途
動画そのもの	動きや流れを見たい場合
静止画を数秒ごとに抽出	画面内容、UI、資料、作業手順の分析
音声を文字起こしして入力	会話、講義、会議、ナレーション中心の分析

おすすめの試験設計

試験	目的
画像: PNG原寸 vs JPEG圧縮 vs トリミングPNG	画質と入力効率の比較
音声: WAV vs M4A vs 文字起こしテキスト	音声入力とテキスト化の比較
動画: 動画全体 vs 静止画抽出 vs 音声文字起こし	動画をどう分解すると効率が良いか比較

最終的には、単純に「一番高画質・高音質」が最適とは限りません。
AIにとっては、必要な情報だけを、読み取りやすく、無駄なく渡す形式が一番よいことが多いです。

複数の評価試験を行う場合、試験条件を揃え、既に行った試験の影響をなくすために、各試験を新規セッションで行うことのほかに、設定しておくことはありますか。例えば、パーソナライズや、学習をOFFにしておくとかです。

はい。新規セッションに分けるだけでは不十分で、比較試験として見るなら、以下もそろえた方がよいです。

項目	推奨設定	理由
モデル	同じモデルに固定	モデルが違うと推論量・費用・速度が比較できません
推論強度	同じ設定に固定	`high` / `xhigh` などが違うと推論出力が大きく変わります
新規セッション	各試験ごとに新規作成	直前の会話文脈の影響を減らせます
メモリ・パーソナライズ	可能ならOFF	過去チャットや保存メモリが回答に混ざるのを防げます
カスタム指示	同一内容に固定、または空にする	文体・判断基準・回答形式に影響します
Codexのメモリ機能	厳密試験ではOFFまたは影響を記録	Codex側の過去作業メモリが挙動に影響する可能性があります
AGENTS.md / プロジェクト指示	同じ作業フォルダ・同じ内容に固定	Codexではリポジトリ内指示が強く効きます
ツール利用条件	同じ許可状態にする	Web検索、ファイル読取、コマンド実行の有無で結果が変わります
入力データ	同じ内容・同じ量にする	形式比較以外では、内容差をなくす必要があります
実行順	できれば順番を入れ替える	時間帯、負荷、キャッシュの偏りを減らせます
反復回数	各条件を複数回試す	1回だけだと偶然の揺れを拾いやすいです
学習設定	OFF推奨。ただし即時比較への影響は小さい	将来の学習利用を避ける意味が中心です

特に重要なのは、メモリ・パーソナライズ・カスタム指示・プロジェクト指示です。
新規セッションにしても、これらが有効だと「過去の好み」「以前の作業方針」「この環境の前提」が入る可能性があります。

OpenAI公式情報では、ChatGPTのMemoryは Settings > Personalization > Memory で制御でき、Temporary Chat は履歴に残らず、メモリを使わず、学習にも使われないとされています。
また、学習利用を止めるには Data Controls の Improve the model for everyone をOFFにします。
Codexについては、ChatGPT側とは別に full-environment Codex settings がある点も注意です。
参考: Memory FAQ, Data Controls FAQ, How your data is used

結論としては、厳密に比較するなら次の構成がよいです。

1. 同じモデル
2. 同じ推論強度
3. メモリ・パーソナライズOFF
4. 学習利用OFF
5. カスタム指示を固定または空にする
6. 同じ作業フォルダ、同じAGENTS.md
7. 各条件を新規セッションで実行
8. 各条件を2〜3回繰り返す

「学習OFF」は比較結果の即時の公平性というより、データ管理と将来影響の遮断の意味が大きいです。
比較精度に直接効くのは、むしろメモリ、カスタム指示、モデル、推論強度、ツール条件の固定です。

Claude Codeで推論出力は出せるか

Codexにトークン量の出力を依頼したところ、Claude Codeの推論出力は回答されなかった。それは、Codexを使ったから回答されなかった可能性があるのでは考えたため、Opus 4.8にも聞いてみた。

Codexにトークン量について設問したところ、入力トークン、出力トークン、キャッシュトークン、推論出力トークン（reasoning tokens）が回答されました。Claude Codeにも推論出力トークンはありますか

結論から言うと、Claude（Claude Code / Claude API）には Codex のような独立した「推論出力トークン（reasoning tokens）」という項目はありません。

Claude のトークン会計

Claude API の usage オブジェクトが返すのは次の4つです:

フィールド	意味
`input_tokens`	キャッシュされなかった入力トークン（フル課金）
`output_tokens`	出力トークン
`cache_creation_input_tokens`	キャッシュに書き込んだトークン（約1.25倍課金）
`cache_read_input_tokens`	キャッシュから読んだトークン（約0.1倍課金）

Codex が挙げた「入力 / 出力 / キャッシュ」の3つは Claude にもほぼ対応しますが、4つ目の「推論出力トークン」に当たる独立フィールドは存在しません。

推論（thinking）トークンの扱い

Claude にも拡張思考（extended thinking / adaptive thinking）はあり、思考にもトークンを消費して課金されます。
ただしその思考トークンは output_tokens の中に含めて計上されるのが OpenAI 系との違いです。

OpenAI / Codex … completion_tokens とは別に reasoning_tokens を分離して報告する
Claude … 思考分も output_tokens に合算。別建てのカウンタは返さない

つまり「思考にどれだけ使ったか」を API レスポンスから内訳として直接取り出すことはできません。
display 設定（summarized / omitted）は思考内容の表示を変えるだけで、課金やトークン計上には影響しません（思考自体はどの設定でも行われ、同じだけ課金されます）。

まとめ

Codex の4分類（入力・出力・キャッシュ・推論）のうち、Claude が明示フィールドで返すのは最初の3つ系統のみ
推論（thinking）トークンは独立項目ではなく output_tokens に内包される、という設計の違いがあります

もし「思考にどれくらいトークンを使っているか把握したい」ということであれば、output_config: {effort: ...} で思考の深さ（=トークン消費量）を制御する、というのが Claude 側の対応する手段になります。

Codexは、推論出力は出力トークンに含まれると回答しているので、その点はOpus 4.8の回答と食い違うが、Claude Codeの場合も、出力トークンに含まれているが、それ単独では回答されないとのこと。