/insights(インサイツ)

スラッシュコマンド
/insights
インサイツ
自分の手元に貯まっているClaude Codeのセッション履歴を横断で集計して、どのプロジェクトを触っていたか・どんな道具をどれくらい呼んでいたか・どこで詰まっていたかをレポートにして画面に出すスラッシュコマンド。コマンドの後ろに何も書き足さず、そのまま叩いて使う

過去1ヶ月のClaude Codeセッションを振り返って、どのプロジェクトに時間を使いすぎてるか・どこで詰まってるかを自分で点検したい個人ユーザー向け

Claude Codeのセッションが数週間〜1ヶ月分くらい貯まったタイミングで、月末の棚卸として叩く。料理ブログと仕事用LPのどっちに時間を使いすぎていたか、どのファイルを何度も書き直していたか、深夜作業に偏っていなかったかを点検したい場面で、ターミナルにそのまま打ち込んでレポートを画面に出す

Claude Codeで毎日コードを書いていると、1ヶ月後には「あれ、先月どのプロジェクトに一番時間を使ってたっけ?」「どこで詰まって書き直しが多かったんだっけ?」が思い出せなくなります。/insights はその振り返りを、自分の手元のセッション履歴から自動でまとめてくれる振り返り用コマンドです。

公式の説明は1文だけ。「あなたのClaude Codeセッションを分析するレポートを生成します。どのプロジェクトを触っていたか、どんなツールの使い方をしていたか、どこで詰まっていたかを含みます」。今のセッションのコストを見る /usage とは違って、過去の積み重ねを横断で点検する側のコマンドです。

噛み砕くと

家計簿アプリの「今月の支出グラフ」みたいなものです。1日ごとの取引を入力しているだけでは「何にお金を使いすぎたか」は見えませんが、月末にカテゴリ別グラフを出すと「あ、外食が突出してる」と気づけます。

/insights はこれのClaude Code版です。1セッションずつ作業しているだけだと「料理ブログと仕事用LP、どっちに時間取られてた?」は分かりません。月末に叩くと、その答えが画面に出てきます。

大事な前提:このコマンドはセッション履歴が貯まっていて初めて意味が出る

叩いた当日にClaude Codeを始めたばかりの状態だと、レポートはほぼ空っぽです。最低でも数週間、できれば1ヶ月くらいの作業履歴があってから叩くと、どのプロジェクトに偏っていたか・どのツールを呼びすぎていたかが見えてきます。

料理ブログだけ触った日が3日続いた直後に叩いても「料理ブログ100%」しか出ないので、月単位での振り返り道具だと思っておくのが安全です。

「月末に料理ブログと仕事用LPの時間配分を棚卸する」を例に、実際の手順を見る

私が想定しているのは、こんな状況です。先月は副業で料理ブログ、つまりHugoで作っている個人サイトと、本業の合間に頼まれた仕事用LP、つまりランディングページの両方をClaude Codeで触っていた。月末になって、「で、どっちに何時間使ってた?」を棚卸したい。

ステップ1:月末になってターミナルを開く

普段使っているターミナルアプリでClaude Codeを起動します。料理ブログでも仕事用LPでも、どの作業フォルダから起動してもかまいません。/insights は今いるプロジェクトだけでなく、過去のセッション全体を横断で見にいくからです。

$ claude

ステップ2:コマンドだけ叩く

起動したら、コマンドの後ろには何も書き足さず、そのまま /insights を打ち込みます。

> /insights

数秒〜十数秒で、レポートが画面にずらっと出てきます。

ステップ3:出てくる画面の構成を読む

表示される情報は、大きく4つのかたまりに分かれています。なお、画面の見た目や項目名のラベルそのものは公式docsに細かく明記されていないので、実際にどう並ぶかはお手元で /insights を叩いて確認してください。ここで書くのは、公式説明から読み取れる「含まれる情報の種類」のほうです。

  • どのプロジェクトを触っていたか:作業フォルダ単位で、どこに時間を使っていたかが並びます。料理ブログと仕事用LPが上位2件に出てくる、みたいなイメージです
  • どのツールをどれくらい呼んでいたか:Read(読む)、Edit(書き換える)、Bash(コマンド実行)、WebFetch(ネットから取ってくる)など、Claude Codeの中で呼ばれた道具の集計
  • 詰まった箇所:エラーが多発した場所や、許可拒否が続いた場所、長時間ぐるぐるしていた箇所
  • 時間帯別グラフ:「Time-of-Day chart」と呼ばれる、何時頃にセッションが集中していたかの棒グラフ

ステップ4:何を見てどう判断するか

私が一番見るのは「どのプロジェクト」と「どのツール」の2つです。料理ブログと仕事用LPの時間比が 7:3 だったとして、自分の感覚では 5:5 のつもりだった、というズレが出ることがあります。これが棚卸の本体です。

感覚と実態のズレは、月単位で見ないと分からないやつです。

ステップ5:詰まった箇所のリストから「同じ場所で何度も書き直していた」を発見する

たとえばEditの呼び出し回数が突出して多かったとします。これは「同じファイルを何度も書き直していた」サインで、私の場合は料理ブログのトップページのレシピカード部分が該当しました。1回で決まらず、CSSを毎回ちょっとずつ直していたわけです。

これに気づけるだけでも、翌月の動き方が変わります。最初に「最終形のラフ」をスケッチしてからClaude Codeに渡す、みたいな方針修正が打てる。

ステップ6:翌月の動かし方を1つだけ決めて閉じる

レポート全部を改善しようとすると重いので、私は「翌月の改善点を1つだけ」決めるルールにしています。料理ブログの作業時間が想定の倍だった月は「料理ブログは週末だけ触る」と決める、みたいに。

振り返りは続けないと意味がないので、軽く終わらせるのがコツです。

つまり /insights は何をしてくれるのか

  • やってくれる:自分の手元に貯まっているClaude Codeのセッション履歴を横断で集計して、プロジェクト別・ツール別・時間帯別・詰まった箇所別のレポートを画面に出す
  • やってくれない:今この瞬間のセッションのコストや使用量の表示は /usage の担当なので、こちらでは出ません。チーム全体のメンバーごとの集計は管理者向けのWebダッシュボードの守備範囲。改善案の提案そのものも返ってきません。出てきた数字を読むのは人間の仕事です
  • 意味が薄い場面:Claude Codeを始めて数日のうち。セッション履歴が貯まっていないので、レポートがほぼ空っぽになる

/insights / /usage / 組織向けダッシュボード / APIプラン向けダッシュボードの違い

同じような名前のものが4つあって、よく混ざります。私も最初は /usage/insights をごっちゃにしていました。違いを表にしておきます。

用途 /insights /usage 組織向けダッシュボード APIプラン向けダッシュボード
範囲 自分の過去セッション横断 今のセッションだけ 組織全体(管理者のみ) APIプラン契約の組織全体
表示場所 ターミナル内 ターミナル内 claude.ai 上のWebページ platform.claude.com/claude-code 上のWebページ
必要な役職 なし(個人で見られる) なし(個人で見られる) OwnerかAdminの役職 UsageView権限。Developer / Billing / Admin / Owner / Primary Owner のいずれかが必要
主な情報 プロジェクト別の時間/ツール別の呼び出し回数/詰まった箇所/時間帯別グラフ 今のセッションの費用/プラン使用率/会話の長さ GitHub上のPR数/Claude Codeで書かれたコード行数/メンバーごとのランキング 受け入れられたコード行数/提案受け入れ率/日次アクティブユーザー数/セッション数/支出
プラン 個人プランで動く(公式docsに限定明示なし) 全プラン Claude for Teams または Enterprise APIプラン。Claude Consoleを利用している顧客向け
注意 GitHub連携の貢献度メトリクスは現時点でAPI顧客向けには提供されていない(公式明記)

ざっくり言うと、/usage は「今日の家計簿」、/insights は「先月のカテゴリ別グラフ」、組織向けダッシュボードは「会社の部署全員の経費まとめ」、APIプラン向けダッシュボードは「API契約している会社向けの専用経費まとめ」みたいな関係です。

使いどころ3シナリオ(具体題材で再現)

シナリオ1:料理ブログ運営者が月末の棚卸をするとき

個人で料理ブログを回しながら、たまにLP案件を請けている兼業の人。月末になって「今月、料理ブログと案件のどっちに時間取られてた?」が知りたい時に叩きます。プロジェクト別の時間配分が一発で出るので、来月「案件月間」にするか「ブログ月間」にするかの判断材料になる。私はこの使い方が一番多いです。

シナリオ2:書き直しの多いファイルを見つけて、最初の指示の出し方を変えるとき

Editの呼び出し回数がやけに多いと感じた時。具体的にどのファイルを何回書き直していたかが見えるので、「あ、毎回トップページのCSSを直してる。最初にラフをFigmaで決めてから渡せばよかった」みたいな反省点が出てきます。翌月の作業フローを1個だけ修正する、というやり方と相性がいい。

シナリオ3:深夜作業ばかりになっていないか健康面で点検するとき

時間帯別グラフを見ると、自分が何時頃に作業していたかが棒で並びます。「平日の22時〜25時に山がある」みたいに出る。私は副業の時間帯がじわじわ深夜寄りになっていた月があって、これで気づきました。健康診断の血液検査みたいな使い方です。

初心者が踏みやすい落とし穴

  • 組織向けダッシュボードと混同する/insights は自分の手元の振り返り、組織向けダッシュボードは管理者が見る組織全体ビュー。これとは別に、APIプラン契約者向けの platform.claude.com/claude-code ダッシュボードも存在する(UsageView権限が必要)。3つを区別すること。公式docsには「Admins and Owners can view the dashboard.」と明記されているので、個人ユーザーが「ダッシュボードが見えない!」と探す必要はない
  • /usage と取り違える/usage は今のセッションのコストと使用率を表示するコマンドで、以前は /cost/stats という別名でも呼ばれていました。過去セッション群を横断で見るのは /insights のほう。両方叩いて見比べるとすぐ分かる
  • 古いバージョンで時間帯グラフがズレている。Claude Code v2.1.117(2026-04-22)で「壊れた時刻情報があるとTime-of-Day chartの軸がズレる」バグが直された。これより古いバージョンを使っていると、時間帯別グラフの数値を信用できないことがある(公式changelog)
  • 古いバージョンでツール集計に「Unrecognized」が出る。一部のバージョンで、サブエージェントが呼んだ標準ツールが詳細表示で「Unrecognized(未認識)」と集計される不具合が報告されている。Edit/Read/Bashなのに「Unrecognized」とだけ並んでいる時は、Claude Code本体を最新版に上げるとこの種の集計ズレは解消する
  • v2.1.135以前ではセッション履歴が壊れていると落ちた。一部のツール呼び出しの記録がおかしいと /insights がクラッシュする不具合があり、v2.1.136(2026-05-08)で修正済み。「叩くと落ちる」場合は本体を上げる
  • 履歴が少ないと詰まった箇所が出ない。1〜2セッションしか貯まっていない状態で叩くと、「friction(詰まった箇所)」のリストがほぼ空になる。最低でも数週間〜1ヶ月分くらい貯めてから叩くのが目安です
  • レポートの送信先は公式docsに明記されていない。「Anthropicに送られている/送られていない」と断言する情報は公式に見当たらない。気になるなら個人プラン(ProやMax)では /privacy-settings で送信ポリシーを確認できるので、そちらを先に見るのが安全

書き方

/insights

やってみるとこうなる

入力

/insights

出力例

※ 以下は読みやすさのために組み立てた構成イメージ。実際の画面レイアウト・数値・項目名は公式docsに明示されていないため、お手元で /insights を叩いて確認してください

Generating insights report...

Project areas:
  ~/projects/cooking-blog ...... 18 sessions / 12.4h
  ~/work/client-lp .............  9 sessions /  5.1h
  ~/projects/aisola-wordpress .   3 sessions /  1.2h

Interaction patterns:
  Edit ........ 312 calls
  Read ........ 287 calls
  Bash ........ 154 calls
  WebFetch ....  42 calls

Friction points:
  Repeated edits on cooking-blog/layouts/index.html (24 retries)
  Permission denied: chmod on client-lp/deploy.sh (5 times)

Time-of-Day:
  09:00-12:00  ████
  13:00-18:00  ██████████
  22:00-25:00  ████████

このページに出てきた言葉

セッション
Claude Codeを起動してから抜けるまでの1回の作業のかたまり。1日に何回も起動と終了を繰り返せば、その回数だけセッションが残る
ツール
Claude Codeの中でClaudeが呼び出す道具の総称。<code>Read</code>はファイルを読む、<code>Edit</code>は書き換える、<code>Bash</code>はターミナルで命令を実行、<code>WebFetch</code>はネットからページを取ってくる、といった役割ごとに分かれている
Time-of-Day chart
<code>/insights</code>が出すグラフのひとつで、時間帯別にセッションがどれくらいあったかを棒で並べたもの。朝型か夜型か、平日業務時間か深夜か、みたいな偏りが見える
詰まった箇所(friction points)
エラーが多発した場所や、許可拒否が続いた場所、長時間ぐるぐるしていた場所のこと。公式docsでは<code>friction points</code>と呼ばれる
組織向けダッシュボード
Claude for TeamsやEnterpriseプランの管理者だけが見られる、claude.ai 上のWebページ。<code>/insights</code>とは別物で、OwnerかAdminの役職でないと開けない
APIプラン向けダッシュボード
APIプラン契約者がClaude Consoleからアクセスする<code>platform.claude.com/claude-code</code>上のダッシュボード。UsageView権限(Developer / Billing / Admin / Owner / Primary Owner)が必要で、GitHub連携の貢献度メトリクスは現時点で提供されていない
/usage
今のセッションのコストやプラン使用率を表示するスラッシュコマンド。過去セッション群を横断で見る<code>/insights</code>とは守備範囲が違う

関連項目

公式ドキュメント

https://code.claude.com/docs/en/commands

-

← 戻る