MENU
シニアが日々の課題をAIを使って解決しようとするサイト
  1. ホーム
  2. スマートホーム
  3. AIエージェントのHAダッシュボード構築

AIエージェントのHAダッシュボード構築

スマートホーム ＡＩ

Xで、Stream Deck+で、Claude Codeの処理状況の表示や承認処理を行えるように構成した例が紹介されていたので、HOME Assistantで、Claude CodeやCodexなどのAIエージェントの処理状況を表示するダッシュボードが作れないかを検討してみた。試作段階の例を紹介する。
当初、Claude Opus 4.8やClaude Codeに相談しながら検討をすすめたが、なかなか進展しない状況が続いたので、その後は、Codexと相談しながら、トラブル解消、ダッシュボードの外観調整などを行った。

（注）本記事の内容は正確性を保証するものではない。

（2026年6月21日 追記）YouTube動画を追加しました。　　https://youtu.be/wKfhWg01Q0c

目次

ダッシュボード試作例

試作段階のものではあるが、ダッシュボードの外観は下図の通りで下記項目を表示するように構成している。

使用量

・直近24時間のトークン使用量
・コンテキスト使用量（使用率：Claude Codeは推定%、Codexは実測%）
・制限表示（5時間枠、7日枠、リセット日時）
・モデル（履歴をもとに直近24時間以内に使用されたモデルを表示）

実行中・最近の処理

・状態（進行中や完了など）
・段階（何段階目まで進んだかの目安）
・開始時刻（どのセッションか区別しやすいように表示）

承認待ち

承認待ち処理が表形式で表示される。確認済みの処理の履歴が残るように修正予定。

承認ボタン・否認ボタン

早く発生した承認確認処理から順に1処理ずつ確認処理を行うためのボタン。（試験的機能）

システム

・集約サーバー（処理結果などを受け付けるMQTTブローカーからの情報を整理して出力するサーバー）の稼働状態を表示

Claude Code ルーチン

ルーチン（定型処理）の状況を表示する。

Codex オートメーション

登録されたオートメーションの状況を表示する。「経過」（時間）は次回開始日時などに変更予定。

Claude Opus 4.8への仕様相談（一部省略）

Claude CodeやCodexの処理状況（進行状況）をHOME Assistantに表示するようにできますか

はい、できます。Claude Code / Codex の処理状況を Home Assistant に表示する方法をいくつか紹介します。

基本構成

Claude Code/Codex 側から状態を送信 → Home Assistant が受信 → ダッシュボードに表示、という流れになります。

方法1: Hooks + REST API（おすすめ）

Claude Code にはHooks 機能があり、処理の開始・終了・通知などのイベントで任意のコマンドを実行できます。
これを使って Home Assistant の REST API を叩きます。

Home Assistant 側で input_text などのヘルパーを作成しておきます。

# configuration.yaml
input_text:
  claude_code_status:
    name: Claude Code Status
    max: 255

Claude Code の .claude/settings.json に Hook を設定:

{
  "hooks": {
    "Notification": [{
      "hooks": [{
        "type": "command",
        "command": "curl -X POST http://YOUR_HA_IP:8123/api/states/input_text.claude_code_status -H 'Authorization: Bearer YOUR_LONG_LIVED_TOKEN' -H 'Content-Type: application/json' -d '{\"state\": \"処理中\"}'"
      }]
    }],
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "curl -X POST http://YOUR_HA_IP:8123/api/states/input_text.claude_code_status -H 'Authorization: Bearer YOUR_LONG_LIVED_TOKEN' -H 'Content-Type: application/json' -d '{\"state\": \"完了\"}'"
      }]
    }]
  }
}

利用可能な Hook イベント: SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Notification、Stop、SessionEnd など。
これで「セッション開始」「ツール実行中」「完了」といった状態をきめ細かく送れます。

方法2: MQTT

Home Assistant で MQTT を使っているなら、Hook から mosquitto_pub でトピックに publish し、MQTT センサーとして表示する方法もスマートです。

mosquitto_pub -h YOUR_HA_IP -t "claude/status" -m "処理中"
# configuration.yaml
mqtt:
  sensor:
    - name: "Claude Code Status"
      state_topic: "claude/status"

Codex について

Codex（OpenAI の CLI）にも Claude Code の Hooks 相当の仕組みがあるか、利用しているバージョンによって異なります。最新の対応状況は確認が必要なので、お使いの Codex のバージョンを教えていただければ調べます。
シェルラッパーで CLI 実行の前後に curl を挟む方法なら、どのツールでも汎用的に使えます。

ダッシュボード表示

受信した状態は Lovelace の Entities カードや Markdown カードで表示できます。
LED ライトの色を状態に連動させる（処理中=黄、完了=緑、要確認=赤）といった演出も自動化（Automation）で組めます。

どの方式が良いか、また具体的な設定を詰めたいので教えてください。

  • 使っている主なツール（Claude Code / Codex / 両方）
  • Home Assistant で MQTT は使っていますか
  • 表示だけでいいか、ライト点灯などの連動もしたいか

ここが決まれば、コピペで動く設定一式を作成します。

下記仕様とした。

・使っている主なツール：Claude CodeとCodexの両方
・Home Assistantで MQTTを使っていないので新規導入
・現状は表示だけ

MQTTは使っていませんが、状態が保持されるなどの利点があれば使いたいと思います。
利点を教えてください

MQTT を使う利点と、使わない場合（REST API 直叩き）との比較を整理します。

MQTT の主な利点

1. 状態保持（Retained Message）
これが一番の利点です。MQTT には「retain フラグ」があり、最後に送ったメッセージをブローカーが保持します。
Home Assistant を再起動しても、購読した瞬間に最新状態が即座に復元されます。
REST API 直叩きだと、再起動後に次のイベントが来るまで状態が空白になります。

2. 疎結合・送りっぱなしでよい
publish 側（Claude Code）は Home Assistant が起動しているか気にせず投げるだけで済みます。
HA が落ちていてもコマンドはエラーになりません（ブローカーが受け取る）。
REST API だと HA がダウン中は curl が失敗します。

3. 認証がシンプル
REST API はロングリブドトークンを Hook の設定ファイルに平文で埋め込む必要があります。
MQTT はブローカーのユーザー/パスワードで、トークンよりは管理しやすい面があります（どちらも平文保存には注意が必要ですが）。

4. 複数の購読者に同時配信
状態を HA だけでなく、別の通知システムやログ収集にも同時に流したい場合、MQTT なら自然に複数購読できます。

5. 双方向通信がしやすい
将来「HA 側から Claude Code に指示を送る」ようなことをしたくなった場合、MQTT は subscribe で受信側も簡単に作れます。

デメリット・注意点

  • ブローカー（Mosquitto）の導入が必要。
    HA OS / Supervised なら「Mosquitto broker」アドオンをワンクリックで追加できますが、Core インストールだと別途用意が要ります。
  • セットアップの手順が REST API より一段増えます。

比較まとめ

項目MQTTREST API 直叩き
再起動後の状態復元◎ 自動復元△ 次イベントまで空白
HA ダウン時◎ 投げて OK× curl 失敗
導入の手軽さ△ ブローカー必要◎ 追加導入不要
双方向・拡張性◎△
認証管理○△ トークン平文

結論

「状態が保持される」「HA の再起動・停止に強い」という今回挙げられた観点では、MQTT が明確に有利です。
状態表示用途なら retain の恩恵は大きいので、Mosquitto アドオンが使える環境（HA OS / Supervised）であれば MQTT をおすすめします。

お使いの Home Assistant のインストール形態（HA OS / Supervised / Container / Core）を教えていただければ、Mosquitto の導入から MQTT センサー設定、Claude Code の Hook まで、コピペで動く一式を用意します。

HOME Assistantは、Mac miniのVM上にCoreをインスールしたので、Mosquitto アドオンは利用できなかったため、ターミナルを使って、”brew install mosquitto”によるインストール、”sudo mosquitto_passwd -c /etc/mosquitto/passwd claude”によるユーザー名・パスワードの設定を行い、MQTTの統合を導入した。

項目どう決まるか例
MQTT_HOSTブローカーを動かすマシンの IP192.168.0.216
MQTT_PORTMosquitto の待ち受けポート（通常固定）1883
MQTT_USERmosquitto_passwd で作るユーザー名claude
MQTT_PASS同コマンドで自分が入力する値（任意の強固なパスワード）

「権限承認待ち」の処理に対する承認処理を入力したい場合はどのように構成できますか

これは表示だけでなく Home Assistant 側から Claude Code に「承認/拒否」を返す双方向通信が必要になります。
ここで前に触れた「MQTT は双方向がしやすい」という利点が効いてきます。構成を整理します。

全体の流れ

Claude Code（権限承認待ちで一時停止）
   │ ①「承認待ち」を publish
   ▼
Home Assistant（カードに承認/拒否ボタン表示）
   │ ②ユーザーがボタンを押す
   ▼
HA が応答を publish（claude/approve/{job_id} → "approve"/"deny"）
   │ ③Claude Code 側が応答を subscribe で受信
   ▼
Claude Code が処理を続行／中止

ポイントは、Claude Code 側が承認を待っている間ブロックして、HA からの応答を待ち受ける必要があることです。

モバイル通知から直接承認する手も

承認はすぐ対応したいことが多いので、HA のモバイルアプリ通知に「承認」「拒否」のアクションボタンを付ける方法も実用的です。
スマホの通知をタップするだけで mqtt.publish が走り、ダッシュボードを開く必要がありません。これも組めます。

試験的な機能であり、まだ安定しないことがあるが、承認待ちの処理が発生した場合、iPhoneにも即時通知されるように設定した。通知が来た場合、通知を長押しすると承認するかどうかの選択肢が表示される。
また、アプリの画面に表示されている「承認」ボタンや「否認」ボタンをクリックすれば1件ずつ、確認が行えるように構成している。ただし、現時点での設定では、ジョブの詳細内容を表示できているわけではないので、実際はスマホのChatGPTアプリのCodexで確認を行う。

下記の内容で、仕様を一旦まとめて他に決めることはないかを教えてください。
仕様は表でまとめてください。

MQTTを導入。Codex のバージョン：Version 26.616.32156。使っている主なツール：Claude Code と Codex の 両方。ライト点灯などの連動：今は行わないが後で手動でオートメーション設定したい。HACS導入。ジョブ表示で出したい項目（ツール名・ジョブ名・状態・進捗%・経過時間・開始時刻 ・終了時刻）。完了したジョブは終了から1日経過後に表示削除。モバイル通知から直接承認する。

仕様を表でまとめます。

確定済み仕様

項目内容
メッセージ基盤MQTT（Mosquitto ブローカー）を導入
対象ツールClaude Code と Codex の両方
Codex バージョン26.616.32156
カスタムカードHACS を導入（auto-entities 等を利用）
表示構成固定枠（Claude Code ルーチン／Codex オートメーション）＋ 動的リスト（adhoc 処理は自動増減）
状態保持retain フラグで最新状態を保持（HA 再起動後も復元）
ジョブ表示項目ツール名・ジョブ名・状態・進捗%・経過時間・開始時刻・終了時刻
完了ジョブの扱い終了から1日経過後に表示から自動削除
承認フロー「権限承認待ち」をモバイル通知で受け、通知のアクションボタンから直接承認／拒否
ライト連動今回は実装しない（後日ユーザーが手動でオートメーション設定）

決めておくとよい項目

仕様として詰めておくと、構成依頼がスムーズになる点です。

未決項目補足・推奨
Home Assistant のインストール形態HA OS / Supervised / Container / Core のどれか。
Mosquitto アドオン導入手順や HACS 導入難易度が変わる（必須確認）
HA の IP アドレス／ホスト名publish 先。後で実値に置き換える形でも可
MQTT 認証ブローカーのユーザー名／パスワードを設定するか（推奨：設定する）
進捗% の取得方法Claude Code / Codex は明確な進捗%を出さないことが多い。
「取れる範囲で。なければ状態表示のみ」で割り切るか要判断
経過時間の表示方式HA 側で開始時刻から自動計算するか、ツール側から送るか（推奨：HA 側で計算）
承認のタイムアウト例：5分応答なしで自動拒否、など。設けるか無制限か
状態の種類（語彙）例：待機中／実行中／権限承認待ち／完了／エラー。
確定しておくと色分けや分岐が楽
Codex 側の状態送信方法Codex に Claude Code の Hook 相当があるか要確認。
なければシェルラッパーで CLI 前後に publish を挟む方式になる（バージョン 26.616.32156 の仕様確認が必要）
ジョブ集約スクリプトの稼働場所固定枠常駐・1日後削除のロジックを担うスクリプトをどのマシンで常駐させるか（HA アドオン／別サーバー／開発マシン等）

ダッシュボートの仕様がほぼ決まったので、実装をClaude Codeに依頼すべきかについてClaudeに質問した。

実装の依頼先：Claude か Claude Code か

役割が分かれます。両方使うのが現実的です。

作業依頼先理由
設計・設定ファイルの生成
（configuration.yaml、MQTT センサー、スクリプト、カード YAML、Hook スクリプトの中身）		Claude（この場）設計の相談・調整をしながら、コピペで使える成果物を一式作るのに向く
実際の環境への適用
（ファイル配置、Mosquitto 導入、HACS 設定、Hook 登録、動作確認、エラー修正）		Claude Codeローカル環境のファイルを直接読み書き・実行でき、その場で動かして直せる

おすすめの進め方は次の通りです。
まずこの場（Claude）で設計を確定し、設定一式とセットアップ手順書を作成します。
次にそれを Claude Code に渡して環境へ適用・デバッグしてもらいます。
Claude Code には「この手順書どおりに導入して、動かして、エラーが出たら直して」と頼めば、ファイル操作と動作確認まで一貫してやってくれます。

なお Codex 側の Hook／ラッパー設定や、Mosquitto・HACS の導入といった実機操作を伴う部分は Claude Code が得意な領域です。
設計は私（Claude）、適用は Claude Code、と分担するのが最もスムーズです。

下記の内容で、設定一式とセットアップ手順書を作成してください。

Home Assistant のインストール形態ですが、このMac miniとは別のMac miniのVM上にcoreが導入されていると思います。 HA の IP アドレス：192.168.0.216 承認のタイムアウト例：無制限
Codex に Claude Code の Hook 相当があるかを質問したところ、添付書の回答が行われた。

設定一式とセットアップ手順書を作成します。
まず、Core インストール（VM 上）という構成に合わせて全体を組み立てます。
重要な制約として、Core インストールでは Mosquitto アドオンが使えないため、ブローカーは別途用意する必要があります。この点も手順書に反映します。

成果物の中身

セットアップ手順書.docx（全8章）に、概要・確定仕様・注意点・ファイル一覧・手順（STEP1〜8）・固定枠登録・状態語彙・トラブルシュート・依頼先までまとめています。
ha-claude-monitor.zip に動作するファイル一式が入っています。

種別ファイル役割
集約サーバーaggregator.py全ジョブを集約し retain publish、1日後の自動削除、固定枠の常駐管理
〃claude-aggregator.servicesystemd 常駐化
Hookjob_notify.sh状態送信ヘルパー
Hookawait_approval.sh承認待ち（HA 応答まで無制限ブロック）
Hook 設定claude_code_settings.json / codex_config.toml各ツールのフック設定例
HAconfiguration_additions.yamlMQTT センサー＋承認待ち件数
HAscripts_additions.yaml / automations_additions.yaml承認/拒否＋モバイル通知
HAlovelace_cards.yaml固定枠2＋動的リスト（標準機能のみ）

集約サーバーのロジック（開始/終了時刻の自動記録、固定枠は残し adhoc は24時間後削除、拒否時の扱い）はテスト済みで、手順書も実際に開いて表示確認しています。

必ず確認いただきたい重要点（手順書 第2章）

ご提示の HA Core という構成のため、設計に1つ大きな制約があります。

Core では Mosquitto アドオンが使えません（アドオン機能は HA OS / Supervised 専用）。
そのため MQTT ブローカーを別途用意する必要があります。
手順書では、常時起動マシン（HA の VM か、この Mac mini など）に Mosquitto を直接インストールする手順を STEP1 に入れています。
ここだけは前提が変わるので、どのマシンにブローカーと集約サーバーを置くか決めておいてください（常時起動が条件です）。

適用作業の依頼先

設計と設定ファイルはこの場（Claude）で完成しました。
実機への導入は Claude Code に任せるのが効率的です。
zip と手順書を渡して「この手順書のとおり、このマシンと HA（192.168.0.216）に導入して、Mosquitto の用意から動作確認まで進めて」と頼めば、ファイル配置・常駐化・HA 設定追記・デバッグまで一貫してやってもらえます。

適用前に置き換える値は3つだけです。
MQTT 接続情報（ホスト/ユーザー/パスワード）、スクリプトの絶対パス、モバイル通知先の端末名（notify.mobile_app_YOUR_PHONE）。
詳細は README と手順書に記載しています。

Claude Codeへの実装依頼

Claude Opus 4.8が作成した、設定一式とセットアップ手順書をClaude Codeに渡して実装を依頼した。

MQTT は準備完了。ブローカーは 192.168.0.30:1883 / ユーザー claude、HA(192.168.0.216)からの接続も登録済み。
この Mac mini(macOS)に、補足手順の STEP A〜C を実施して。
集約サーバーは ~/claude-monitor/aggregator に置き、com.claude.aggregator.plist の python3 パス・配置パス・MQTT_PASS を実値に直して launchd で常駐化。
Hook は ~/claude-monitor/hooks に置いて各設定のパスを反映。
最後にテスト送信で HA に反映されるか確認して、エラーが出たら直して。
続けて元手順書の STEP3〜8(Hook 登録・HA 設定追記・ダッシュボード・承認通知)も進めて

（長いので途中省略、実装をCodexに依頼することにしたので、最終的にどういう処理を行ったかを一覧表にしてもらった）

何を行ってきたかについての詳細ステップをまとめて一覧表にしてください

承知しました。これまでの全作業を時系列・カテゴリ別に一覧化します。
最後に「動いているもの/未解決」も明記します。

A. 事前調査・環境確認

#実施内容結果
1zip展開・補足docx/手順書docx・全ソース読込構成把握
2このMacの素性確認(whoami/IP/python/mosquitto)Mac-mini-2 = 192.168.0.30、broker稼働、user claude
3which python3/opt/anaconda3/bin/python3(plistの既定と相違→要修正)
4mosquitto設定確認listener 1883 / allow_anonymous false / user claude

（途中省略）

G. ダッシュボードの表描画(難航・未解決)

#実施内容結果
33折りたたみ>→\n埋め込み→リテラルブロック→表前に見出し行、と段階的に修正表は描画されず
34長期アクセストークン取得 → /api/template・/api/statesで検証テンプレ出力は正しい表
/データは4件
35静的テーブルのテストカード(v2)グリッド描画OK(=カードは表対応)
36キャッシュ判定(v3マーカー+HA再起動+アプリ完全終了)v3反映確認・ただし表は出ず「処理なし」表示
37リスト形式へ切替を提案(承認フック一時解除のEdit)あなたが拒否 → ここで停止中

現在の状態(正直な整理)

✅ 動作確認済み

  • 集約サーバー常駐(online)、MQTT、sensor.claude_jobs(=4件保持)
  • スマホ通知での承認/拒否の往復、ダッシュボードの承認/拒否ボタン
  • カードの空表示(「処理なし」「登録なし」「承認待ちはありません」)は出る
  • Bash限定承認フック(別セッションで承認→実行 確認済み)

❌ 未解決

  • ダッシュボードのジョブ一覧(表)が画面に出ない。
    データもテンプレ出力も正しいのに、テンプレ生成の表だけが描画されない。
    リスト形式への切替を試そうとした直前で停止。

Codexへの実装依頼

Claude Codeでの実装は進展が見られなかったため、以降、Codexにトラブルの解消や、ダッシュボード外観調整を依頼した。

Codexに実装を依頼したことにより、表示が出ないなどのトラブルが解消されたが、すぐに解消されたわけではなく、何度か修正を行うことによって徐々に解消されていった。

Claude CodeやCodexの処理状況（進行状況）をHOME Assistantに表示するようにできますか。
Claudeに添付の手順書を作成してもらいましたので現状を確認し実装を行ってください

できました。
既存のMQTT/Home Assistant表示は活かし、止まっていた原因だった「空のセッションID通知」を修正しました。

変更した主な内容:

  • [ha_agent_hook.py]を追加し、Claude Code/CodexのHook入力JSONを読んでHAへ通知するようにしました。
  • [job_notify.sh]を堅牢化し、空ID通知を捨てるようにしました。
  • [await_approval.sh]を新ラッパー経由に変更しました。
  • [Claude設定]と [Codex設定]を差し替えました。

確認結果:

  • sensor.claude_aggregator_status = online
  • sensor.claude_jobs に以下が反映済み
    • claude-code-current: routine, 待機中, 0%
    • codex-current: automation, 完了, 100%
    • codex-ha-monitor-setup: adhoc, 完了, 100%
  • sensor.claude_pending_approvals = 0

スクリーンショットの「Claude Code ルーチン」「Codex オートメーション」の「登録なし」は、いまは解消されているはずです。バックアップは [backups]に置いてあります。

Codexのオートメーションには、現在、1件の登録があるので、添付画像の通りで正しいのですが、「Claude Code ルーチン」のルーチンは、Codexのオートメーションに相当する機能であり、現在は1件もないはずです。また、「実行中・最近の処理」には、このセッションの表示もなく、Claude Codeのセッションも表示されていません

ご指摘の通りです。
前回こちらが「通常セッション」と「登録済みルーチン/オートメーション」を混ぜていました。直しました。

現在のHome Assistant上の分類はこうなっています。

  • Claude Code ルーチン: 0件
  • Codex オートメーション: 1件
    • 環境省WBGT 65042をHome Assistantへ送信
  • 実行中・最近の処理: Codexセッション、Claude Codeセッションが表示される分類に変更済み

設定も修正済みです。

  • Claude CodeのHookは通常セッションを adhoc として送信
  • CodexのHookも通常セッションを adhoc として送信
  • Codexの登録済みオートメーションは automation として別管理

Home Assistantアプリ側は一度画面を下に引っ張って更新、またはダッシュボードを開き直すと反映されるはずです。

「実行中・最近の処理」にはどちらのセッションも表示されていません。Codexオートメーションは1件表示されています

直しました。原因は、既存YAMLダッシュボードの「実行中・最近の処理」カード内で時刻変換が失敗し、本文全体が空になっていたことでした。

今は既存ダッシュボード側でも描画できるよう、adhoc の表示用データから started/finished を外して再配信しています。
Home Assistantのテンプレート描画確認では、以下が出ています。

  • Claude Code セッション
  • Codex セッション
  • HA表示連携セットアップ
  • 過去のテスト処理

分類も維持されています。

  • Claude Code ルーチン: 0件
  • Codex オートメーション: 1件
  • 実行中・最近の処理: 7件

画面を下に引っ張って更新、またはダッシュボードを開き直すと表示されるはずです。
念のため、APIで直接保存できる修正版のStorageダッシュボード Claude Monitor Live も追加してあります。

ここまでの修正により、「Claude Code ルーチン」や「実行中・最近の処理」の表に、処理のリストが表形式で表示されるようになった。

以降は、主にダッシュボードの外観調整に関する修正の内容である。

「実行中・最近の処理」の処理で、終了から1日経過したものを表から削除するようにできますか。
完了していないものは表から削除しないようにしてください

対応しました。

変更内容:

  • 実行中・最近の処理 は、status = 完了 かつ finished から24時間以上経過したものだけ表から除外します。
  • 実行中、待機中、権限承認待ち など未完了のものは削除しません。
  • エラー / 拒否 も「完了」ではないので、自動削除しないようにしました。
  • 集約サーバーも再起動済みで、現在 online です。

現在の確認結果:

  • Claude Code ルーチン: 0件
  • Codex オートメーション: 1件
  • 実行中・最近の処理: 8件
  • 承認待ち件数: 0

現時点では完了から1日経過した項目がまだないため、今すぐ件数は減っていません。
条件を満たしたものは、次回の状態更新または集約サーバーの定期処理で表から消えます。

Claude CodeやCodexの使用量に関する情報をダッシュボードに表示することはできませんか

できます。実装まで完了しました。

Home Assistant の 「Claude Monitor ダッシュボード」に 使用量 カードを追加しました。
現在は直近24時間について、Codex / Claude Code それぞれのセッション数、処理数、入力/出力/キャッシュ系トークン、最終利用時刻を表示します。
Codex についてはログに残っている範囲で、5時間枠・7日枠の使用率も表示します。

確認時点では、カードは次のようにレンダリングできています。

Codex: 6セッション / 92ターン / 5時間枠 20.0% / 7日枠 24.0%
Claude Code: 3セッション / 396応答

集約サーバーも再起動済みで、Home Assistant 側では sensor.claude_jobs に usage 属性が入り、状態は online です。

注意点として、これはローカル履歴からの集計です。
公式の請求額、厳密な残量、サブスクリプションの正確な消費量とは一致しない場合があります。
ただ、日々の利用感を Home Assistant で見る目的にはかなり使える形になっています。

Claude Codeの制限表示は表示できないのですか

現状では、Claude Code は Codex と同じ形の「使用率」「リセット時刻」を表示できません。

確認した範囲では、Claude Code のローカル履歴に残っているのは主に以下です。

  • 入力トークン
  • 出力トークン
  • キャッシュ読み取り/作成トークン
  • モデル名
  • 最終利用時刻

一方で、Codex 側にあるような 5時間枠 37% や リセット 06/20 16:17 に相当する情報は、Claude Code のログにも CLI の通常ヘルプにも見つかりませんでした。

そのため、Claude Code 使用量 カードには 制限表示 欄を追加して、次のように明示する形にしました。

使用率: 取得不可
リセット時刻: 取得不可

これで「表示漏れ」ではなく「Claude Code側から取得できない情報」だと分かるようになっています。

「実行中・最近の処理」の「進捗」の数字（パーセント）は、何の情報に基づいて算出したものですか

実行中・最近の処理 の 進捗% は、実際の作業量やトークン量から自動計算しているものではありません。

現在は、Claude Code / Codex のフックが発火した段階に応じて、固定値を入れています。

Claude Code は今こうです。

セッション開始: 0%
ユーザー入力送信後: 30%
Bash実行後: 70%
停止/終了: 100%

Codex は今こうです。

セッション開始: 0%
ユーザー入力送信後: 30%
ツール実行前: 60%
ツール実行後: 80%
停止/終了: 100%

つまり、60% や 80% は「全体の6割/8割まで本当に終わった」という意味ではなく、現在どの段階のフックまで進んだかを見やすくするための目安です。

より正確にするなら、進捗 という列名を 段階 や 状態目安 に変える、またはパーセント表示をやめて 入力受付済み / ツール実行中 / ツール完了後 / 完了 のような文字表示にする方が誤解は少ないです。

「段階」という名称で、例えば、「1/4」のように表示できませんか。何番目の段階まで進んでいるかの目安も知りたいので

できます。変更しました。

実行中・最近の処理 の列名を 進捗 から 段階 に変更し、パーセントではなく次の形式で表示するようにしました。

Claude Code: 1/4 〜 4/4
Codex: 1/5 〜 5/5

Codex はフック段階が Claude Code より1つ多いため、1/5 形式にしています。
現在の表示確認では、例えばこう出ています。

Codex セッション: 実行中 4/5
Claude Code セッション: 完了 4/4
HA表示連携セットアップ: 完了 5/5

Claude Codeの「制限表示」の情報の取得方法を、Claude Codeに質問し、その回答をCodexに渡して検討してもらった。

Claude Codeの「制限表示」の情報の取得方法を、Claude Codeに検討してもらいました。
その回答（下記回答）と、まとめ資料「claude_limits_実装指示書.md」も添付しますので、内容を確認し、実装を検討してください。

承知しました。Codex に渡せる実装指示書としてまとめます。

指示書を作成しました → claude_limits_実装指示書.md(~/claude-monitor/docs/claude_limits_実装指示書.md)。
Codex にこのファイルを渡せばそのまま着手できます。
念のため、この調査結果(再発見にコストがかかる内部仕様)をメモに残します。
指示書ができました。内容の要点は以下です。
（表示省略）
このまま Codex に渡してください。実装後の検証(テスト手順7)まで指示済みです。
何か追記したい観点(例:Opus週次枠も出す/失敗時の表示文言の指定など)があれば言ってください。

実装を検討したうえで、実装できる部分は入れました。

追加・変更した内容は次です。

  • [claude_limits.py]を新規追加
    Claude Code のKeychain認証情報から、Claude制限情報をライブ取得するためのモジュールです。
  • [usage_summary.py]に claude.rate_limits を追加
  • Claude Code 使用量 カードを、制限情報が取れた場合は 5時間枠 / 7日枠 / 7日(Opus) の表で表示するよう更新
  • 取得失敗時は連続アクセスしないよう、失敗キャッシュも入れました
  • 集約サーバーは再起動済みで、状態は online です

ただし、現時点ではClaude Code側の認証が失効しているようです。
確認したところ、Claude Code本体の最小実行でも次の状態でした。

401 Invalid authentication credentials

そのため、現在のダッシュボードではまだ Claude Code 使用量 > 制限表示 は 取得不可 のままです。
これは実装側の表示漏れではなく、Claude CodeのKeychain内トークンが現在API利用に使えない状態のためです。

なお、添付指示書ではトークン更新先が console.anthropic.com とありましたが、この環境のClaude Codeバンドルでは https://platform.claude.com/v1/oauth/token が確認できたため、実装ではそちらを優先しています。

次に必要なのは、Claude Codeの再認証です。
ターミナルで次を実行して再ログインすると、制限表示の取得を再テストできます。

claude auth login

再ログイン後にこちらで再取得テストすれば、成功した場合はHome Assistantの Claude Code 使用量 に制限表示が出るはずです。

再ログインしました

再ログイン後、取得できました。

Claude Code 使用量 の 制限表示 は、Home Assistant 側で次のように表示される状態まで確認済みです。

5時間枠: 40.0% / リセット 06/20 15:10
7日枠: 4.0% / リセット 06/22 15:00

usage.claude.rate_limits も sensor.claude_jobs に入っています。集約サーバーも online、承認待ちも 0 です。

補足すると、今回のAPI応答では 7日(Opus) 枠は返ってきていないため、表示は 5時間枠 と 7日枠 の2行です。Home Assistantアプリでまだ古い表示なら、画面の再読み込みで反映されます。

Claude Codeの「制限表示」
Codexの「制限表示」

各使用量を、横向きのバーグラフでも表示できませんか

はい、追加しました。

Claude Code 使用量 と Codex 使用量 の両方に、次の横向きバーを入れています。

  • 制限表示: 5時間枠・7日枠の使用率にバー列を追加

数値表は残したままなので、詳細な数字も見られます。
制限バーは 0〜100% の使用率として表示します。

スマホ（iPhone17）HOME Assistantアプリでもこのダッシュボードを表示できるので、Mac mini上のCodexで処理を行うたびに使用率が、例えば、1つの処理ごとに数%ずつ上昇していくのをスマホでモニターできる。スマホではスクロールする必要があるが、Claude CodeとCodexの使用率を1画面で確認できる。
例えば、使える量が残り8％の状態で、この処理を制限に引っかかる前に終了できるかを考える際、前の処理で何%使ったから、この処理がいけそうかと考えることができる。
ChatGPT 5.5 Thinking（推論：非常に高い）を使っただけあって、使える量がみるみる減っていくのを目視で確認できた。本記事の質疑応答を行った際、3〜4回ぐらい制限に引っかかった。Codexでこれほど制限を受けたのは初めてだった。

「処理中・最近の処理」のリストの順番はどのようになっていますか。
また、「状態」に応じて、色を変えることができますか

現在の「実行中・最近の処理」の順番は、新しい順ではありません。

集約側でいったん次の順に並べています。

  1. routine
  2. automation
  3. adhoc

そのうえで、各カード側では adhoc かつ Claude Code / Codex だけを抜き出して表示しています。
つまり、今の2つの「実行中・最近の処理」カードでは、実質的には ジョブ名順 で並んでいます。
開始時刻順・更新時刻順ではありません。

あわせて、状態 欄の色分けを追加しました。

  • 実行中: 青
  • 権限承認待ち: オレンジ
  • 待機中: グレー
  • 完了: 緑
  • エラー: 赤
  • 拒否: 赤

Home Assistant 側にも反映済みで、テンプレート展開でも色付き状態が出ることを確認しました。
画面を再読み込みすると反映されます。
新しい順や「実行中を先頭」に変えるなら、次は並び順のルールを変更するのがよさそうです。

新しい順に変更した。

コンテキスト（コンテキストウィンドウ）の使用量（パーセント）は分かりますか

はい、一部は分かります。

結論としてはこうです。

対象コンテキスト使用率
Codexかなり正確に算出可能
Claude Code正確値は難しいが、推定なら可能

Codex の履歴には model_context_window と last_token_usage.total_tokens が残っていました。なので、

直近リクエストの total_tokens ÷ model_context_window × 100

で計算できます。直近履歴の例では、93,785 / 258,400 = 36.3% のように出せます。

Claude Code 側は、ログに input_tokens、cache_read_input_tokens、cache_creation_input_tokens、output_tokens はありますが、Codex のような model_context_window が見当たりませんでした。そのため、Claude Code は「モデルごとの上限値をこちらで固定して推定する」形になります。

ダッシュボードに出すなら、私は次の表示が良いと思います。

  • Codex コンテキスト: 実測に近い%
  • Claude Code コンテキスト: 推定%
  • 取得できない場合は - または 推定不可

Codex使用量の項目に、「推論出力」があります。これについて説明してください

推論出力 は、Codex が回答やツール実行の方針を決めるために内部で使った reasoning tokens の量です。

通常の 出力トークン は、画面に返される文章や結果に近いものです。
一方で 推論出力 は、表示されない内部処理のためのトークンです。
たとえば、複雑なコード修正、手順の検討、複数ファイルの整合確認などで増えやすくなります。

今のダッシュボードでは、Codex のローカル履歴にある reasoning_output_tokens を直近24時間で集計して表示しています。

つまり、

  • 入力トークン: Codex に渡した文脈や指示
  • キャッシュ: 再利用された入力文脈
  • 出力トークン: 実際に返された応答
  • 推論出力: Codex が内部推論に使った見えない出力

という意味です。

注意点として、推論出力 の中身そのものは取得できません。
取得できるのはトークン数だけです。
名称としては、内部推論トークン の方が少し分かりやすいかもしれません。

下記の複数の値からどのようなことが推定できますか。

入力トークン: Codex に渡した文脈や指示
キャッシュ: 再利用された入力文脈
出力トークン: 実際に返された応答
推論出力: Codex が内部推論に使った見えない出力

これらを組み合わせると、主に 「処理の重さ」「文脈の再利用効率」「応答の長さ」「内部でどれだけ考えたか」 が推定できます。

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

組み合わせで見ると、かなり意味が出ます。

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

実用的には、次のように見るとよいです。

  • キャッシュ率が高い: 長い作業を効率よく継続できている
  • 推論出力が急に増える: Codex が難しい判断をしている
  • 入力トークンが増え続ける: コンテキストが膨らんでいる
  • コンテキスト使用量も高い: そろそろ新しいセッションや要約が必要かもしれない

ただし、これはあくまで推定です。
推論出力 の中身そのものは見えないため、「何を考えたか」ではなく「どのくらい内部処理が重かったか」を見る指標です。

複数セッションの合計値ということですね

はい、その理解で合っています。

いまの Codex 使用量 の

  • 入力トークン
  • キャッシュ
  • 出力トークン
  • 推論出力

は、直近24時間に記録された複数セッション分の合計値です。

一方で、コンテキスト使用量（実測%） は合計値ではなく、直近で取得できた1回分のコンテキスト使用率です。
ここは少し性質が違います。

つまり、

  • 直近24時間 の表: 24時間内の合計
  • コンテキスト使用量: 最新セッション/最新リクエストに近い単発値
  • 制限表示: 現在の利用制限枠の状態

という見方になります。

「モデル」が表示されていますが、どのような条件に当てはまるモデルが表示されているのですか

現在の実装では、モデル に表示されるのは 直近でスキャン対象になったローカル履歴の中で、出現回数が多い上位5件のモデル名です。

条件は次のとおりです。

  • 対象ログは、最近更新された .jsonl ファイル
  • スキャン範囲は現在の設定では、おおむね 直近3日以内に更新された履歴ファイル
  • Codex は turn_context に記録された model
  • Claude Code は assistant メッセージ内の message.model
  • 空のモデル名や <synthetic> のように < で始まる内部用モデル名は除外
  • 多く出現した順に最大5件まで表示

少し注意点があります。
直近24時間 のトークン表は24時間内の合計ですが、モデル は現状では厳密に24時間内だけではなく、最近更新された履歴ファイル全体から拾ったモデルです。

つまり、表示されているモデルは「この24時間で必ず使ったモデル」ではなく、より正確には 最近の履歴でよく出ているモデルです。
必要なら、ここも 直近24時間に実際に使われたモデルだけ に揃えることができます。

「直近24時間に実際に使われたモデルだけ」に変更した。

「承認待ち」に一旦表示された処理を履歴として10件表示するようにしてください。
表には確認結果（承認（緑色文字）か否認（赤色文字）か）と、確認日時を入れてください

対応しました。

承認待ちカードの下に、承認履歴（直近10件）を表示するようにしました。履歴には ツール / ジョブ / 確認結果 / 確認日時 が出ます。
確認結果は、承認を緑、否認を赤で表示します。

概ね、実装したい機能は実現できたが、「制限表示」の5時間枠の数字などは、処理のログから情報を得ており、処理が行われないと更新されないため、リセット日時を過ぎているのに使用量が更新されないという現象が見られた。この現象に対しては、リセット日時を過ぎている場合は強制的に使用量を0にするように修正したが、リアルタイムに更新されない場合もあることを知っておかなければならない。
また、推定している情報もあり、正確な情報ではなく目安として考えておかなければならない情報もある。

スマートホーム ＡＩ
Claude Claude Code Codex context Dashboard Home Assistant iPhone Mac Mosquitto MQTT Opus コンテキスト ダッシュボード
目次