「今月、Claude Code でいくら使っただろう」。月末にコストを集計しようとして、手が止まった経験はないでしょうか。Claude Code だけなら ccusage で十分でした。ところが Codex も Cursor も Gemini CLI も日常的に使うようになると、エージェントごとにログの保存場所が異なり、横断した合計コストがどうしても見えてきません。
さらに厄介なのが、過去セッションの検索です。「あのリファクタリングをやり取りしたのはどのツールの、いつのセッションだったか」を思い出せず、ターミナルの履歴をさかのぼっても見つからない。使うエージェントが増えるほど、コストの全体像も過去の作業履歴も散在していきます。
こうした「複数エージェントのセッションとコストが散らばって把握できない」という課題に、ローカル完結で答えようとしているのが、本記事で取り上げる OSS「agentsview」です。20 種類以上のコーディングエージェントのセッションを 1 つのツールに集約し、横断検索・コスト集計・統計分析をローカルの Web UI から行えます。
本記事では、agentsview が何をするツールなのか、主要機能・対応エージェント・導入形態を整理したうえで、よく比較される ccusage や Agent Sessions との違いを解説します。「いま ccusage を使っているが、乗り換える価値があるのか」を自分で判断できる状態をゴールにします。なお本記事は動作検証を行わず、公開されている README・公式ドキュメント・GitHub メタデータに基づいて構成しています。
agentsviewとは｜複数AIエージェントのセッションとコストをローカルで横断管理するOSS
agentsview は、コーディングエージェントのセッションを横断的に検索・分析し、トークン使用量とコストを集計するローカルファースト（local-first）の OSS です。1 バイナリで動作し、アカウント登録は不要で、セッションデータはすべてローカルに保持されます。外部のホスティングサービスにセッション内容を送信しない設計のため、コードを含むやり取りを手元から出したくないケースに向きます。
公式の説明（GitHub の description）では「Claude Code、Codex、そのほか 20 種類以上のエージェントに対応した、コーディングエージェント向けのローカルファーストなセッション検索・アナリティクス・インサイト・トークン使用統計」と位置づけられています（kenn-io/agentsview - GitHub）。
仕組みはシンプルです。マシン上に保存された各エージェントのセッションファイルを自動で検出し、ローカルの SQLite データベースに同期します。そのうえで、ブラウザから http://127.0.0.1:8080 にアクセスして Web UI で閲覧する、という流れです。冒頭で挙げた「ログが散在して横断把握できない」という課題に対して、複数エージェントのセッションを 1 つのデータベースに集約し、単一の画面から見られるようにする点が、このツールの核になります。
基本情報を整理しておきます。採用判断の前提として、メンテナンス状況が健全かどうかは重要な確認ポイントです。
項目 | 値 |
|---|---|
リポジトリ | |
主要言語 | Go |
ライセンス | MIT |
スター数 | 3,015 |
Fork 数 | 253 |
最終更新（push） | 2026-06-20 |
公開状態 | public（アーカイブ済みではなく、フォークでもない） |
スター数 3,015・Fork 253 という規模に加え、最終更新が 2026-06-20 と直近でプッシュが続いており、リリースも頻繁に重ねられています。アーカイブ（開発停止）されているわけでもフォーク（派生）リポジトリでもなく、本家の現役プロジェクトとして活発に開発されている状態です。ライセンスは MIT で、商用利用を含めて扱いやすいのも、業務で採用を検討するうえでの安心材料になります（数値はいずれも 2026-06-20 時点の GitHub メタデータに基づきます）。
agentsviewの主要機能｜セッション検索・コスト集計・stats分析
agentsview の機能は、大きく 3 つの柱で理解すると整理しやすくなります。「セッションの横断検索」「トークン使用量・コストの集計」「stats によるセッション分析」です。自分の使い方をどこまでカバーしてくれるかを、それぞれの機能から確認していきましょう。
セッションブラウザと全文検索
1 つ目の柱は、Web UI 上のセッションブラウザと全文検索です。SQLite の FTS5（全文検索インデックス）を使い、すべてのメッセージ本文を横断して検索できます。「あの関数について議論したセッション」「このエラーメッセージが出たやり取り」「特定の設計判断をした会話」を、エージェントの種類をまたいで探せるのが、ターミナル履歴をさかのぼる作業との大きな違いです。
UI 面では、SSE（Server-Sent Events）によるライブ更新で、新しいセッションが自動的に反映されます。j / k / [ / ] でのカーソル移動や Cmd+K、ヘルプ表示の ? といったキーボード中心の操作にも対応しており、マウスに持ち替えずに探索できます。見つけたセッションは HTML としてエクスポートしたり、GitHub Gist へ公開して共有したりできます。
トークン使用量・コスト集計
2 つ目の柱が、usage サブコマンドによるトークン使用量とコストの集計です。ここが、ccusage を使ってきた読者にとって最も気になる部分でしょう。README は agentsview の usage を「ccusage 等の高速なローカル代替」と明示しており、ccusage を直接の比較対象として名指ししています（kenn-io/agentsview - GitHub）。
最大の特徴は、Claude Code 専用ではなく全エージェント横断でコストを集計できる点です。日次のコストサマリーは次のように出力します。
agentsview usage daily # print daily cost summary
出典: kenn-io/agentsview（README "Quick Start"）
集計面の特徴を挙げると、LiteLLM のレートによる自動の価格付け（オフライン時はフォールバックあり）、プロンプトキャッシュを考慮したコスト計算、--breakdown によるモデル別の内訳、--since / --until / --all での日付フィルタ、--agent でのエージェント絞り込み、--json での構造化出力に対応しています。サーバーを起動しなくても単体で動作するため、コスト確認だけならコマンド一発で済みます。
速度についても言及があります。セッションデータが SQLite にインデックス済みであるため、生のセッションファイルを実行のたびに再パースするツールよりも高速だと README は主張しています。具体的には、22,000 セッションのローカルデータベースで agentsview usage daily が npx ccusage@latest daily の 80〜220 倍速く、より小規模なデータベースでもサブ秒で結果が返るとされています（kenn-io/agentsview - GitHub）。この数値は公開ドキュメントの主張であり、本記事では動作検証していない点を補足しておきます。
なお、セッション単位の内訳が欲しい場合は agentsview session usage <id> でトークン統計とコスト見積もりを取得できます。REST API（GET /api/v1/sessions/{id}/usage）からも同じデータを取得できるため、自前のダッシュボードに組み込む使い方も想定されています。
statsによるセッション分析
3 つ目の柱が、agentsview stats によるセッション分析です。これは単なるコスト集計を超えて、自分のエージェント利用の「傾向」を定量的に見るための機能です。
stats は、指定したウィンドウ単位で合計値・セッションのアーキタイプ（automation / quick / standard / deep / marathon）・セッション時間やユーザーメッセージ数・ピークコンテキスト・ツールやターンの分布・キャッシュ経済性・ツール/モデル/エージェント構成・時間帯別の内訳などを出力します。「短時間の質問が多いのか、長時間の deep な作業が中心なのか」といった自分の使い方の輪郭が見えてきます。--format json を指定するとバージョン付きの v1 スキーマ（schema_version: 1）で出力されるため、機械的な後処理にも向きます。
加えて、Git / GitHub 由来のアウトカム指標（コミット数・変更行数・PR 数）はオプトイン方式（--include-git-outcomes / --include-github-outcomes）で取り込めます。大規模なリポジトリや一部データが欠損したリポジトリでは処理が遅くなりうるため、既定ではオフになっています。機能詳細は公式の README で確認できます（kenn-io/agentsview - GitHub）。
対応エージェントと検出の仕組み
採用を検討する際、まず気になるのは「自分が使っているエージェントが対応しているか」でしょう。agentsview は 20 種類以上のコーディングエージェントを自動検出します。README には Claude Code（~/.claude/projects/）や Codex（~/.codex/sessions/）をはじめ、Cursor、Gemini CLI、Copilot CLI、Aider、Amp、OpenCode、Forge、Qwen Code、Kiro、Zed など、多数のエージェントが表で列挙されています。
検出に使うディレクトリは環境変数で上書きできます。標準とは異なる場所にセッションを保存している場合でも、設定で対応できる余地があるということです。設定や環境変数の詳細は、公式の設定ドキュメントにまとまっています（agentsview 設定ドキュメント）。
一方で、エージェントによっては検出方法に特殊な事情があります。たとえば Aider は中央集約されたセッションストアを持たないため、リポジトリごとの .aider.chat.history.md を「run 単位で 1 セッション」としてインデックスします（ホームディレクトリ配下 4 階層・2 秒のバジェットで探索範囲を区切る方式）。また Antigravity CLI については、新形式（SQLite の .db）は直接インデックスし、旧形式（AES-GCM で暗号化された .pb）はサマリーモードで扱います（外部ツール agy-reader を併用すればフルトランスクリプト化も可能とされています）。
つまり「対応エージェント一覧に載っていても、ログの保存形式によってインデックスの粒度や挙動が変わる」ケースがあります。自分のメインエージェントがどう扱われるかは、採用前に公式ドキュメントで確認しておくと、導入後の認識のずれを避けられます。
導入形態とチーム運用｜CLI・Docker・PostgreSQL同期
導入のしやすさと、個人利用からチーム共有へのスケール可否は、採用判断の決め手になりやすいポイントです。agentsview は複数の導入形態を用意しています。
インストール手段は、curl / PowerShell のワンライナー、デスクトップアプリ（macOS / Windows、GitHub Releases または brew install --cask agentsview）、Docker イメージ（ghcr.io/kenn-io/agentsview:latest）の 3 系統です。まず個人で試すなら、CLI を入れてサーバーを起動するのが最短です。
agentsview serve # start foreground server
agentsview serve --background # start server and return to the shell
agentsview serve status # show whether a server is running
agentsview serve stop # stop the running server
出典: kenn-io/agentsview（README "Quick Start"）
ストレージは既定で SQLite を使います。個人利用ならこれで完結します。チームで共有したい場合は PostgreSQL 同期に切り替えられ、agentsview pg push でデータを送り、agentsview pg serve で共有ダッシュボードを提供します。--watch を付ければ自動 push のデーモンとして動かせます。さらに DuckDB ミラーや Quack 経由のリモート提供にも対応しており、「個人で試す」から「チームで横断ダッシュボードを共有する」まで、同じツールでスケールできる構成になっています。
運用で見落としたくないのがセキュリティ設計です。サーバーはループバック（127.0.0.1）にバインドし、Host ヘッダの検証によって DNS リバインディング攻撃を防ぐようになっています。SSH ポートフォワードなどで別オリジンからアクセスする場合は --public-url / --public-origin を設定し、ループバックの外に公開する場合は --require-auth の利用が推奨されています。また、設定ファイル config.toml は資格情報を含みうるため、chmod 600 での権限制限が推奨されています。リモートやチームで本番運用する際は、このあたりの設定が前提になる点を押さえておきましょう。配布物やリリース履歴は GitHub のリリースページで確認できます（agentsview Releases - GitHub）。
agentsviewと類似OSS（ccusage・Agent Sessions）の違い
ここまでの機能を踏まえて、よく比較される 2 つの OSS との違いを整理します。結論を先に言うと、agentsview は「コスト集計ツール」と「セッションビューア」の両方を 1 バイナリ + ローカル Web UI に統合している点が、立ち位置の差になります。
観点 | agentsview | ccusage | Agent Sessions |
|---|---|---|---|
種別 | 1 バイナリ + Web UI（Go 製） | ローカル CLI（Node.js 製） | macOS ネイティブアプリ（Swift 製） |
主な焦点 | セッション検索＋コスト集計＋stats 分析の統合 | 使用量・コストの集計 | セッション閲覧・検索・resume |
アーキテクチャ | SQLite にインデックス | 実行のたびに生 JSONL を再パース | macOS ネイティブ |
全文検索 | あり（FTS5） | コスト集計が中心 | あり |
チーム共有 | PostgreSQL 同期で可能 | ローカル単一前提 | ローカル単一マシン前提 |
対応プラットフォーム | macOS / Linux / Windows | クロスプラットフォーム（Node.js） | macOS 専用 |
ccusageとの違い
ccusage（ryoppippi/ccusage）は、npx ccusage で手軽に使える Node.js 製のローカル CLI です。Claude Code や Codex などが書き出すローカルの JSONL ログを解析し、日次・月次・セッション別のトークン/コストレポートをターミナルに出力します。GitHub のスター数は約 16.4k（2026-06-20 時点）と、この分野では最も広く使われているツールの 1 つで、「まずコストを把握したい」というニーズに対して、導入の軽さと使い勝手が際立ちます。
agentsview との違いは 2 点に集約できます。1 つはアーキテクチャです。ccusage は実行のたびに生ファイルを再パースする CLI 寄りの設計なのに対し、agentsview はセッションを SQLite にインデックス済みで、前述のとおり大規模データでの高速性と Web UI・全文検索を備えます。もう 1 つはスコープです。ccusage が「使用量・コストの集計」に焦点を絞っているのに対し、agentsview はコスト集計に加えてセッションの横断検索・stats（アーキタイプ分析）・チーム共有（PostgreSQL）まで含む統合ダッシュボードを目指しています。
裏を返せば、「Claude Code 中心で、ターミナルでサッとコストを見られれば十分」という使い方なら、ccusage のままで困りません。乗り換えの価値が出るのは、後述する「向いているケース」に当てはまる場合です。
Agent Sessionsとの違い
Agent Sessions（jazzyalex/agent-sessions）は、Swift 製の macOS ネイティブアプリです。Codex・Claude・OpenCode・Cursor Agent・Copilot CLI・Gemini CLI などのセッション履歴をブラウズ・検索・分析し、resume（再開）まで行えます。iTerm2 のライブ監視「Agent Cockpit」など、OS との統合が魅力です。
agentsview との違いは、プラットフォームと重点の置き方です。Agent Sessions は macOS 専用のネイティブアプリで、セッションの閲覧・resume・OS 統合（Dock / メニューバー）が中心です。これに対して agentsview は 1 バイナリ + Web UI で macOS / Linux / Windows を問わず動き、コスト/トークン集計と stats という定量分析を一級機能として持ちます。共有面でも、agentsview は PostgreSQL 同期でチーム共有ダッシュボードを構築できるのに対し、Agent Sessions はローカル単一マシンでの利用が前提です。「macOS で使い、resume を重視する」なら Agent Sessions、「OS をまたいで使い、コスト分析とチーム共有まで見据える」なら agentsview、という棲み分けになります。
agentsviewが向いているケース・導入判断のまとめ
最後に、ここまでの内容を「試す/見送る」の判断材料として整理します。
agentsview が向いているのは、次の条件が複数当てはまる人です。
- 複数のコーディングエージェントを併用している：Claude Code 1 本ではなく、Codex・Cursor・Gemini CLI などをまたいで使っており、横断したコスト集計が欲しい
- 過去セッションの全文検索が欲しい：「あの実装をやり取りしたセッション」を、エージェントをまたいで検索したい
- 使い方の傾向を定量的に把握したい：stats でアーキタイプや時間帯別の傾向を見て、自分の利用パターンを振り返りたい
- （任意で）チームで共有したい：PostgreSQL 同期で、チームの横断ダッシュボードを構築したい
逆に、「Claude Code 中心で、ターミナルでコストをサッと見られれば十分」という使い方なら、軽量な ccusage のままで不便はありません。乗り換えの価値が出るのは、コスト集計に加えて「横断検索」「stats 分析」「チーム共有」のいずれかが欲しくなったタイミングです。
メンテナンス状況の観点でも、agentsview は採用検討に値する状態にあります。スター数 3,015・Fork 253 という一定の規模があり、最終更新が 2026-06-20 と直近で、リリースが頻繁に重ねられています。アーカイブもフォークでもない現役プロジェクトで、ライセンスは MIT のため業務での扱いやすさもあります。
なお本記事はドキュメントベースでまとめたもので、動作検証は行っていません。実際に導入する際は、自分のメインエージェントの検出挙動・最新のコマンド仕様・セキュリティ設定を、必ず公式ドキュメント（kenn-io/agentsview - GitHub / 設定ドキュメント）で確認してください。複数エージェントのセッションとコストが散らばって把握できない——その課題に心当たりがあるなら、SQLite に取り込むだけのローカル完結ツールとして、まず手元で試してみる価値はあります。
