matt1398/claude-devtools とは何ですか？

Claude Code が端末上で省略するツール呼び出し・思考過程・サブエージェントの動きを、~/.claude/ に残るログから再構成する Electron 製デスクトップアプリ。設定不要で既存セッションを読める点が売りだが、ログ形式への依存と Electron アプリ特有の配布コストは把握しておきたい。

matt1398/claude-devtools は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

matt1398/claude-devtools は今もメンテナンスされていますか？

されています。最後のコミットは 125 日前です。

matt1398/claude-devtools はどのプログラミング言語で書かれていますか？

主に TypeScript です（GitHub の言語統計による）。

claude-devtools レビュー: Claude Code のログを可視化するデスクトップツール

ひと目でわかる

これは何？: Claude Code が端末上で省略するツール呼び出し・思考過程・サブエージェントの動きを、~/.claude/ に残るログから再構成する Electron 製デスクトップアプリ。設定不要で既存セッションを読める点が売りだが、ログ形式への依存と Electron アプリ特有の配布コストは把握しておきたい。
誰に向いている？: Claude Code を日常的に使い、端末の要約表示では原因が追えないデバッグを繰り返している個人開発者や小規模チームには、導入の手間が小さく見合います。逆に、CI やサーバーサイドで自動的にログを収集して集計したい場合や、組織でログの保存場所や内容を統制している場合は、ローカルの ~/.claude/ を読む前提のこのツールは土台になりません。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 125 日前です。
何の言語で書かれている？: 主に TypeScript です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · matt1398/claude-devtools

端末が「Read 3 files」としか言わなくなった問題

README は、Claude Code が v2.1.20 以降、詳細な出力を不透明な要約に置き換えたと述べています。ファイルパスも内容も行番号も出ない、というのが作者の主張です。README が挙げる欠落は要約だけにとどまりません。思考ステップは端末では見えず、ツール呼び出しは 1 行の要約だけで実際の入出力が読めず、サブエージェントが入れ子で動いても最終結果しか出ず、コンテキストウィンドウは 3 分割のプログレスバーだけで内訳が分からない、という整理になっています。回避策として README が示すのは --verbose ですが、これは生の JSON と内部システムプロンプトを大量に吐くだけで、中間がないと作者は書いています。この問題設定が正しいかどうかは読者の環境で確かめるしかありませんが、少なくともツールの対象は明確です。端末の表示を置き換えるのではなく、すでにディスクに残っているログを読み直して、失われた粒度を取り戻すという立場を取っています。

~/.claude/ を読むだけで成立する仕組み

このツールの中核は、Claude Code が ~/.claude/ 配下に保存するセッションログとトランスクリプトを読み、UI 上で再構成する点にあります。README はゼロコンフィグ、API キー不要、ラッパー不要を掲げており、過去に実行したすべてのセッションで動くとしています。つまり Claude Code の呼び出し経路に割り込むのではなく、出力側のファイルを後から解釈する設計です。この方式の利点は、既存のワークフローを変えずに済むことです。欠点は、ログ形式が変わればパーサ側の追随が必要になることです。README が v2.1.20 という具体的なバージョンを挙げて出力の変化を説明している事実は、この依存関係が机上の話ではないことを示しています。UI 側では、コンテキスト再構成が 7 カテゴリのトークン帰属として提示されます。CLAUDE.md（グローバル、プロジェクト、ディレクトリ）、skills、@ メンションされたファイル、ツール I/O、thinking、チームのオーバーヘッド、ユーザーテキストの 7 つです。どの時点でコンテキストに何が入っていたかを追う、というのがこの画面の狙いです。

インストール: Homebrew、直接ダウンロード、Docker の 3 経路

macOS では brew install --cask claude-devtools が README に記載されています。直接ダウンロードの場合、macOS は Apple Silicon なら arm64 アセット、Intel なら x64 アセットを選び、初回起動は右クリックから Open します。Linux は .AppImage、.deb、.rpm、.pacman からディストリビューションに合うものを選ぶ形です。Windows は .exe のインストーラで、SmartScreen の警告が出た場合は More info から Run anyway を選ぶ手順が書かれています。サーバーやコンテナで動かす場合は docker compose up の後に http://localhost:3456 を開く、というのが README の案内です。ポート番号が 3456 と明示されているので、既存のサービスと衝突するかどうかは起動前に確認できます。Docker 経路ではログの置き場所をコンテナに渡す必要がありますが、README の抜粋にはボリュームの指定方法までは含まれていないため、compose ファイルの実物を確認するまでは断定できません。設定キーについても、抜粋から読み取れる範囲では API キーやトークン類の項目は登場せず、ローカルのログディレクトリをどう見せるかが設定の中心だと推測されます。

コンテキスト内訳とサブエージェントの実行ツリー

機能のうち、実務で効きそうなのは 2 つです。1 つはコンテキストの可視化で、ターンごとにトークンがどのカテゴリに消費されたかを 7 分類で示し、compaction の可視化も行うと README は説明しています。3 分割のバーでは分からなかった「何がコンテキストを食っているか」を、CLAUDE.md や skills、@ メンション、ツール I/O といった単位に分解する発想です。もう 1 つはサブエージェントの可視化で、エージェントごとの実行ツリーをツールトレース、トークン、所要時間、コストとともに表示するとされています。エージェントがエージェントを呼ぶ構成では、最終結果だけを見ても、どの子エージェントがどこで時間やトークンを使ったかは分かりません。ここを木構造で見せるというのは、端末の 1 行要約に対する直接的な答えになっています。加えて README は、プロジェクトごとの Claude メモリが ~/.claude/projects/.../memory/ に隠れていることを指摘し、MEMORY.md をクリック可能なレイヤーの索引として描画し、任意のレイヤーをエディタで開けるとしています。ログの閲覧とメモリの編集が同じ画面に同居する構成です。

ログ形式への依存という構造的な制約

もっとも大きな制約は、このツールが Claude Code のログ形式に全面的に依存していることです。README 自身が v2.1.20 の出力変更を問題の出発点に据えており、その変更に追随して可視化を成立させている以上、上流が形式を変えればパーサの更新が必要になります。リリース履歴を見ると v0.5.0 が 2026-05-13、v0.4.16 が 2026-05-06、v0.4.15 が 2026-04-30 と、1 週間から 2 週間の間隔で版が重なっています。活発である一方、変化の速い対象を追いかけている証拠でもあります。古いバージョンの Claude Code で生成したログや、独自に加工したログを読ませた場合にどこまで解釈できるかは、README の抜粋からは判断できません。また、これは端末の表示を置き換えるものではなく、事後に読むためのビューアです。実行中のセッションをリアルタイムに監視する用途や、ログを収集して複数マシン横断で集計する用途は、少なくとも提示された資料からは読み取れません。Electron 製のデスクトップアプリである以上、ヘッドレス環境での利用も想定外だと考えたほうが自然です。

代替手段との違い: --verbose とログ集約基盤

README が対置しているのは --verbose です。同じログを読むという点では方向が近いのですが、--verbose は生の JSON と内部システムプロンプトをそのまま流すため、人間が読むにはノイズが多すぎる、というのが作者の評価です。claude-devtools は同じ情報源を使いながら、フィルタと構造化された画面を被せることで中間の粒度を作ろうとしています。つまり違いはデータの取得元ではなく、取得後の提示方法にあります。もう 1 つの方向として、ログをファイルとして収集し、汎用の可観測性基盤に送って検索や集計を行うやり方があります。こちらは複数ホストのログをまとめて扱え、保持期間やアラートの設計も可能ですが、Claude Code 固有のコンテキスト 7 分類やサブエージェントの実行ツリーは自前で組み立てる必要があります。逆に claude-devtools は、その固有の構造を最初から描画してくれる代わりに、単一マシンのローカルログという範囲に閉じます。どちらが優れているという話ではなく、一回性のデバッグを速くしたいのか、長期的な傾向を追いたいのかで選び方が変わります。

ライセンスと更新コストの見積もり

ライセンスは MIT です。デスクトップアプリとして配布され、社内で fork して手を入れることもライセンス上は可能ですが、MIT が保証する範囲や、同梱物の第三者ライセンスの扱いについては、リポジトリの LICENSE と配布物の表記を確認する必要があります。ここで法的な助言はできません。更新コストの面で見ておきたいのは、前述のとおりリリース間隔が短いことです。上流の Claude Code がログ形式や出力を変えるたびに、このツール側で対応が要る可能性があります。バージョンを固定して使うのか、追従して更新するのかを決めておかないと、ある日ログが正しく解釈されない状態に気づかないまま使うことになりかねません。Docker で動かす場合、コンテナのイメージタグを固定するか latest を追うかも同じ判断になります。検証するなら、README の手順どおりに brew install --cask claude-devtools で入れた版と、Docker の http://localhost:3456 で見える版が同じセッションを同じように描画するかを並べて確認するのが手っ取り早いでしょう。

編集部の結論

Claude Code を日常的に使い、端末の要約表示では原因が追えないデバッグを繰り返している個人開発者や小規模チームには、導入の手間が小さく見合います。逆に、CI やサーバーサイドで自動的にログを収集して集計したい場合や、組織でログの保存場所や内容を統制している場合は、ローカルの ~/.claude/ を読む前提のこのツールは土台になりません。導入前に確認すべきは、自分の環境のログ形式が v0.5.0 のパーサで解釈できるか、そして Docker で動かす場合にログをどのボリュームへマウントするかです。まずは直近の失敗セッションを 1 つ開き、ツール呼び出しの入出力とコンテキスト内訳が期待どおりに出るかを確かめてから、常用するかどうかを決めるのが現実的です。

公式情報源

コミュニティノート