Claude CodeのInsightsをもとに、Codexの使い方も分析して改善した

Claude Codeには、これまでの履歴から自分の使い方を分析してくれる/insightsという機能があります。

2026年5月に一度実行したところ、危険なGit操作への保護や、確認していない情報が記事へ混ざることなどを指摘されました。そこで設定を見直し、足りない保護を追加していきました。

8月にもう一度実行しました。ただ、最近はCodexを使うことが増えていて、Claude Code側には直近の作業履歴があまりありませんでした。

それなら、Claude CodeのInsightsと同じような分析をCodexでもできないか。そう聞いてみたのが今回の始まりです。

Claude Codeの/insightsは、AIの使い方を振り返る機能

Claude Codeで次のスラッシュコマンドを入力すると、HTMLレポートが作られます。

/insights

過去の会話をもとに、よく頼んでいる作業、何度もやり直しているところ、まだ使っていない機能などを分析してくれます。

Claude Codeには似たコマンドもありますが、見る範囲が違います。

/contextと/usageが現在や直近の利用状況を見るコマンドなのに対して、/insightsは複数の会話を振り返り、使い方そのものを分析するコマンドです。

公式ドキュメントによると、1回で未分析のセッションを最大200件まで扱い、極端に短いセッションは除外されます。分析には通常利用と同じアカウントのトークンを使います。最新レポートとは別にタイムスタンプ付きのコピーも保存されますが、元のセッションと同じ保持設定の対象です。Claude Code公式ドキュメント

2回実行して、前回から何が変わったかを見た

1回目は三つの問題を指摘された

1回目は2026年5月9日に実行しました。対象は3月22日から5月8日までの181セッション、2,621メッセージです。

大きな指摘は三つありました。

• 破壊的なGit操作に対する保護が足りない
• 確認していない事実が記事や成果物へ混ざる
• 技術や発信などの役割を、会話ごとに説明し直している

中でも重かったのはGitです。過去にgit reset --hardを実行し、コミット前の変更を消してしまったことがありました。Insightsは、そのセッションを具体例として拾っていました。

レポートを読んだ後、現在の設定と照らし合わせました。mainブランチへの直接操作を止める仕組みはすでにありましたが、その後、--no-verifyやforce pushも実行前に止めるHookを追加しました。会話ごとに説明していた役割は、必要なときだけ読み込むSkillへ移しています。

すべてをInsightsがきっかけで一から作ったわけではありません。レポートをチェックリストとして使い、現在の設定に足りないものを確認した、という方が実態に近いです。

Git保護やHookの構成は、以前書いたClaude Codeのハーネス設計とは？手戻りを減らす方法にまとめています。

2回目には、改善前の履歴も含まれていた

2回目は8月14日に実行しました。対象は3月22日から8月10日までの239セッション、3,156メッセージ、496コミットでした。

実際のレポートには、Gitの事故について次のように書かれていました。

Claude recommended git reset --hard without warning it would also wipe uncommitted changes.

2回目の分析対象は3月から始まっています。途中でSkillやHookを追加しても、改善前の会話は分析対象に残ります。そのため、すでに導入している機能が改善案として出てくることもありました。

同じ指摘が出なかったからといって、問題が解消したとは限りません。反対に、レポートへ出ていても、現在は対策済みのことがあります。結果をそのまま採用せず、今の設定やGit履歴と照らし合わせる必要がありました。

この記事を書いている最中にも、main保護を作った日付と、別のHookを追加した日付を取り違えていました。Git履歴を確認して間違いに気づいたので、レポートの解釈にも事実確認が必要だと改めて分かりました。

最近使っていたCodexの履歴も分析した

最近はClaude CodeよりCodexを使うことが増えていたため、Claude Code側の履歴だけでは今の使い方を十分に振り返れませんでした。

2026年8月14日に確認した範囲では、Claude Codeの/insightsと同じ形式の個人向けレポートをCodexで作る公式機能は見つけられませんでした。

そこで、Claude Codeが作ったHTMLレポートをCodexへ渡し、「同じように自分のCodex利用も分析できないか」と頼みました。自分が細かい集計手順を指定したわけではありません。Codexがローカルに残っているデータを調べ、次の流れで分析しました。

1. Claude Codeのレポートから、作業内容、使い方、繰り返している問題、改善案という観点を取り出す
2. CodexのSQLiteを読み取り専用で開き、日時やタスクの親子関係などのメタデータを見る
3. 人が始めたタスク、自動レビュー、そこから起動した子エージェントを分ける
4. 直近30日の人間起点タスクを分類し、必要な会話だけJSONLで確認する
5. 過去に残していたAIの訂正・失敗記録と照らし合わせる

JSONLは、セッションごとの会話やツール実行を1行ずつ記録した履歴ファイルです。集計結果だけでは理由が分からない場合に、該当するセッションの中身を確認しました。

SQLiteは、こんな形で読み取り専用にしました。

sqlite3 -readonly ~/.codex/state_5.sqlite

最初に見えたのは971件です。しかし、その内訳は人が始めたタスク295件、自動レビュー615件、子エージェント61件でした。971件をそのまま「自分がCodexを使った回数」と数えると、実態から大きくずれてしまいます。

直近30日の人間起点タスクは95件でした。朝の状況確認が28件、優先順位に沿って次の作業を進めるタスクが22件で、半分以上を占めています。毎朝同じルーティンを実行しているので、この結果自体に問題はありません。

それより役に立ったのは、内容の違うタスクで同じ失敗が繰り返されていたことです。

• 変化する外部サービスを、現在の公式情報や実際の画面まで確認せず説明する
• コードやファイルがあることを、UI・動画・音声が完成したことと取り違える
• 観測量が少ない段階で結論を急ぐ
• AIが決めてよい通常の判断まで人へ戻す

Claude Codeのレポートでは「確認していない事実が混ざる」と指摘されていました。Codex側の履歴まで見ると、「何を確認したら完成と言ってよいのかが曖昧」という、もう少し具体的な問題として見えてきました。

Codexのローカル履歴を扱うときの注意

ここで気をつけたいのが、ローカル履歴の中身です。セッションにはプロジェクト名、依頼文、コード、ファイルパス、ツールの実行結果などが含まれることがあります。

今回は次のように扱いました。

• SQLiteは読み取り専用で開く
• 先にメタデータだけを集計し、本文が必要な会話だけを確認する
• 生のHTML、SQLite、JSONLを外部サービスへアップロードしたり公開したりしない
• 記事ではプロジェクト名、内部の役割、勤務先、収益、絶対パスを出さない

CodexのSQLiteとJSONLは公開APIではなく、保存形式が変わる可能性があります。ここで紹介しているのは、2026年8月14日時点の手元環境で行った方法です。

分析結果を、二つのルールに変えた

分析して終わりではなく、繰り返していた問題を二つのルールへ反映しました。

画面と操作を確認するまで完成にしない

一つ目は、UIや画面遷移を含む変更を、コードレビューと自動テストだけで完成にしないことです。内部ではProduct Evidence Gateと呼んでいます。

実際にレンダリングした画面、主要な操作、代表的な状態まで確認します。重なり、切れ、操作不能など、客観的に分かる問題はAI側で確認します。使い心地や主要なUXを採用するかどうかは、自分が判断します。

AIが決めてよいことまで、人へ戻さない

二つ目は、AIから人へ確認を戻す条件を決めることです。内部ではDelegation Contractと呼んでいます。

目的と制約が決まっていて、やり直せる通常の判断ならAIが進めます。目的、優先順位、主要UX、外部公開、追加費用、元に戻せない変更、権利や安全に関わることだけを人へ戻します。

この二つを開発用エージェントの完了条件へ反映しました。後続のモバイル開発では、CodexがRelease版をビルドして私のiPhoneへ上書きインストールし、私が実機上で表示と既存データの保持を確認しました。自動テストの合格だけで完成とはしなかった例です。

ただし、これで手戻りが何件減ったかはまだ測っていません。変えたのはAIの能力ではなく、AIが「完成」と報告してよい条件です。

定期的に振り返り、直すところを一つ決める

Claude Codeの/insightsは、自分がAIをどう使っているかを振り返る入口として便利でした。期間を空けてもう一度実行すると、前回の指摘と現在の状態を比べられます。

ただ、レポートには改善前の履歴も含まれます。途中でメインのAIツールを変えた場合は、新しいツール側の履歴も見ないと今の使い方は分かりません。

出てきた提案を全部採用する必要もありません。現在の設定や事実と照らし合わせたうえで、何度も繰り返している失敗を一つ選び、ルール、テスト、Hook、完了条件のどれかを変える。それくらいがちょうどよいと思います。

自分の場合は、「コードがあり、自動テストが通った」から、「実際の画面と操作まで確認した」へ完成の条件を変えました。

/insightsを使ったら、レポートを読むだけで終わらせず、次の作業から何を一つ変えるかまで決めてみてください。