Claude Code「/insights」で使い方を診断。枠は何%燃えて、何が返ってくるのか【実測】

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Claude Codeに入っている診断コマンド「/insights」を私の環境で実際に走らせて、出てきた通信簿と、その代わりに燃えた枠の話をします。

まず公式の言葉から。Claude Codeのコマンド一覧には、/insightsがこう書かれています。

料理に例えると、厨房に付けた監視カメラの3週間分を、ベテランの味見係が早送りで見返してくれる感じです。「この人、包丁は速いけど鍋を火にかけたまま席を離れるクセがある」みたいな、本人が一番気づきにくい動線を指摘してくる。

仕組みの側も公式が書いています。1回の実行で、まだ見ていないセッションを最大200件まで分析し、ごく短いセッションは飛ばす。レポートは ~/.claude/usage-data/report.html に書かれ、実行ごとの日時付きコピーも同じ場所に残る。保持期間は他のセッションデータと同じで、初期設定なら30日。……ここまでが、公式が明言している範囲です。

どのモデルで分析しているかは、公式ページには書いてない。第三者の解説ではVincentさんが「分析はClaude Opusだけを使う」と書いていますが（Vincent’s Blog・2026年4月8日）、これは公式の記述ではないので、参考として置いておきます。

2026年9月5日の朝、コマンドを1行打ちました。/insights。それだけ。

セッションを開いたのが10時59分45秒。1本目のレポートが書かれたのが11時01分31秒で、最終版が11時03分24秒。約3分39秒でした。レポートの頭にはこう出ています。

3,167時間って、3週間で？と思った人、正しいです。私は1人ですが、Claude Codeは同時に何本も走らせているので、合計時間は人間の労働時間ではなく「AIが稼働していた延べ時間」になります。ここは読み方に注意。

で、この表で一番効いたのがBashとWriteの比です。実行が13,960回に対して、ファイルを書いたのは450回。約31倍。……つまり私は、Claude Codeに「コードを書かせて」いるんじゃなかった。「動かして、待って、確かめて、報告させて」いた。レポートはそれを「コーディング補助ではなく、自律運用の艦隊として使っている」と書いてきました。自分では言葉にできていなかった一文。

作業領域のトップ5も出ます。私の場合は、①タスクの自動運転と管理、②ブログ制作と公開、③動画生成とYouTube公開、④事業戦略や提案書、⑤システムの健全性監査、の順。ぶっちゃけ、コードを書く時間はこの中のどこにも主役で出てこなかった。

レポートには「うまくいっていること」と「摩擦」の章があります。褒められたのは3つ。

1つ目は、承認ゲート付きのパイプライン。ブログ記事を1本渡すと、台本、音声、テロップ、動画合成、非公開設定でのアップロードまで自動で進み、そこで止まって私の承認を待つ。承認したら公開して、公開状態をAPIで読み戻して台帳に書く。この型はセッションをまたいで毎回きれいに回っていた、と。

2つ目は、ルールの自己テスト。私は「あいまいな時は推測せず聞いて」というルールを置いているんですが、それが守られるかをわざと試すセッションを回していました。成功条件は「ファイルを作らずに、質問のダイアログが出ること」。レポートは、自分の統治ルールをテスト可能なものとして扱っている人はほとんどいない、と書いてきた。照れる。

3つ目は、症状で止まらず根本原因まで掘ること。「直したのに反映されない」を追いかけたら、修正が別の作業ブランチに落ちていた、とか。品質チェックが動かない原因が、環境変数でチェック自体がオフになっていた、とか。

じゃあ叱られたのは何か。こっちが本題です。

①ゴール直前で落ちる。9割終わってから、使用枠の上限、外部サービスの停止、サーバーのディスク満杯で止まる。3週間で、枠切れによる中断が15回以上、セッションの中断が9回以上。準備も検証も終わった記事が、最後の承認だけ届かずに「未完」のまま残ったこともありました。

②違う問題を解く。これが摩擦の最多で35件。私が言っていない前提で、完成品まで作ってしまう。たとえば提案書を「配信イベント前提」で4回作り直してから、私が欲しかったのは常設ページだと判明する、みたいな。レポートの処方はシンプルでした。最初の1行に「出力の形」と「反例を1つ」書け。「仕組みじゃなく、売上の実数」みたいに。

③ルールを守れていない・確認せずに報告する。「1件ずつ聞いて」と決めているのに10件を1つの質問に束ねる。HTTPが200を返しただけで「稼働中」と言い切る。……私はこれを毎回その場で叱っていたんですが、レポートは「毎ターン取り締まっている」と数えていました。取り締まるのは、私の時間なんですよね。

タダじゃない。まずそこから。公式のコスト管理ページに、はっきり書かれています。

つまり、普段の会話と同じ財布から出ていく。じゃあ枠は何%燃えて、それは重いのか。公式は割合まで書いていないので、第三者の実測を引きます。

Proプランで、レポート作成に枠の15〜20%、さらに日本語に訳させると10%。合わせて枠の3割弱が1回で飛ぶ。これは2月時点の実測で、その後Claude Code側も何度も更新されているので、今も同じ割合かは断言できません。でも桁の感覚としては十分に参考になる数字です。

じゃあ私の環境ではどうだったか。正直に書きます。この実行だけの消費トークンは、手元のログからは切り出せませんでした。/insightsの分析は普段の会話ログとは別の場所で走るので、私のセッション記録に残っていたのは、最後にレポートの場所を返す1往復分（キャッシュ読み込み約2.6万、キャッシュ書き込み約7.1万トークン）だけ。分析本体の消費は見えない。ここは「見えなかった」と書くのが正解で、推測の数字を置くのはやめました。

その代わり、分かる数字を並べます。

2,716万トークン分の会話を3分半で読んで通信簿にする、と考えると、枠の15〜20%は高いのか安いのか。私の感覚では——安い。人間の顧問に3週間分のログを読ませたら3分では終わりませんから。ただし、これは「枠に余裕がある日に走らせる」が前提です。締切前の午後に走らせて、その後の作業が枠切れで止まったら、通信簿どころじゃない。

しかもね。2回目以降は軽くなる、という記述もあります。リベシティのぎんさんは「初回実行はセッション数によって数分かかる場合がありますが、2回目以降はキャッシュが効くため速くなります」と書いています（リベシティ・2026年4月10日）。公式も「まだ見ていないセッションを最大200件」と書いているので、一度分析したセッションは次回の対象から外れる、と読めます。

枠の2割を払って、何が手に入るのか。私の答えは「言語化された自分」です。同じことを、先に走らせた人たちも書いています。

私の実感も同じ側です。「違う問題を解いている回数が35回」と数字で出されると、逃げ場がない。感覚では「たまにズレるな」だった。35回。3週間で。……これは私の指示の出し方の問題で、AIの賢さの問題じゃない。ここが数字で突きつけられたのが、一番の収穫。

もう1つ、実務的な価値の話。レポートの後半に、設定ファイル（CLAUDE.md）にそのまま貼れる追記案が出るんですよ。私のレポートには5件。ただ——ここが落とし穴で、次の章の話になります。5件のうち3件は、私の環境にもう書いてあった。

おすすめできるのは、こういう人です。

逆に、向かない人。

枠がギリギリの日の人。公式が「プランの使用量にカウント」と書いている以上、締切前に走らせるのは順番が逆です。クラウド版だけで使っている人。公式が「クラウドセッションでは使えない」と明記していて、分析対象も「このマシン上のセッション」だけ。他の端末やclaude.aiの分は入りません。1〜2回しか使っていない人。材料が無いので、味見係も何も言えない。

いやー、あと1つ。「レポートの提案を、そのまま全部実行してくれるツール」を期待している人にも向きません。それをやると、たぶん設定ファイルが太るだけです。理由は次で。

頻度の目安は、先に走らせた人たちがだいたい同じことを言っています。ぎんさんは「月に1回程度実行するのがおすすめです」（リベシティ）、橋本さんは「思い出したときにたまに眺めてみるくらいがちょうど良さそう」（サーバーワークス）。

私の結論は、月1回を基本にして、下に書く日だけ例外で追加です。

避けたい日も書いておきます。締切前の午後。枠の残りが3割を切っている時。それから、セッション数が200件を超えて溜まっている時は、1回で全部は読み切れないので、公式仕様どおり「未分析の200件ずつ」を数回に分けて回すつもりで。

さっきの落とし穴の続きです。私のレポートが出した設定ファイルへの追記案は5件。①質問は1タスク1件にして、出したら必ずIDを読み戻す。②確認していないことを「確認した」と言わない。③親は指揮に専念して、作業は子に委ねる。④長い処理の前に環境チェックを入れる。⑤途中の状態をファイルに保存して、途切れても続きから再開できるようにする。

どれも正しい。でも、①②③は私の設定ファイルにもう書いてあったんです。書いてあるのに守られていなかった。つまりこの3件は「足す」問題じゃなくて「守らせる」問題。ここで提案を鵜呑みにして同じ趣旨の行を追記していたら、設定ファイルが太って、読まれない行が増えるだけだった。

本当に私の環境に無かったのは、④の事前チェックと、⑤の途中セーブ、それに「並列で動かす分身ごとに出力先を分ける」という3つ。ここまで仕分けたところで——私は今回、実装を見送りました。設計だけ書いて置いてある。理由は、先に「守らせる」側を直さないと、足した仕組みもまた守られないから。

で、この仕分けの手順を、そのまま使える形にすると3ステップです。

「守らせる」箱の中身は、設定を足すより、指示の出し方を変えるほうが早いことが多い。私の場合は、最初の1行に「出力の形」と「反例」を書く。それだけで35件の何割かは消える気がしています。……これは次の月1回で、数字で確かめます。

/insightsは、Claude Codeの使い方の通信簿です。公式の定義は「このマシン上の直近セッションを分析して、何をしていて、どこで失敗して、何を試すべきかをHTMLにする」。枠は使う。Proプランで15〜20%という実測がある。私の環境では1,846セッションのうち113件を約3分半で読み、「実行13,960回に対して書き込み450回」「違う問題を解いた回数35回」「枠切れで終点直前に落ちた回数15回以上」という、自分では言葉にできていなかった数字が返ってきました。

使い方は、これだけ。月1回、枠が戻った朝に走らせる。「つまずき」の章から読む。提案は既存の設定と突き合わせて、本当に無いものを1つだけ足す。……料理で言えば、味見係の言うことを全部聞いて全部の鍋に塩を入れる料理人はいません。どの鍋か、を決めるのが自分の仕事です。

私の次の月1回は、10月の頭。「最初の1行に出力の形と反例を書く」を3週間やってみて、35という数字がどう動くか。その結果も、またここに書きます。