Claude Codeのログ・デバッグ完全ガイド【2026年最新】:--debugフラグ・トランスクリプト・OTelまで徹底解説
室谷今回はClaude Codeのログとデバッグの話をしましょう。これ、.AI(ドットエーアイ)のコミュニティでもよく相談が来るテーマで・・・「なんか動かない」「何が起きているのかわからない」という状況のときに、ログをどう見るか知っているかどうかで解決速度が全然違うんですよね。
テキトー教師ほんとそうで。講座で受講生さんが「Claude Codeがエラーを返してくる、何が悪いのかわからない」って言うときの9割は、ログをちゃんと読んでないケースなんですよ(笑)。
Claude Codeにはいくつかログ出力の仕組みがあるので、整理しながら話しましょうか。
Claude Codeにはいくつかログ出力の仕組みがあるので、整理しながら話しましょうか。
室谷そうですね。CLIフラグ・環境変数・セッションのトランスクリプト・OpenTelemetry、大きく4つの切り口があります。
まずはCLIフラグから行きましょうか。
まずはCLIフラグから行きましょうか。
テキトー教師それが一番手軽ですよね。コマンドに1個フラグを付けるだけなので。
--debugフラグ:APIレベルのデバッグ情報を見る

室谷--debugフラグは、公式ドキュメントによると「Enable debug mode with optional category filtering」とあります。つまりデバッグモードを有効にしつつ、カテゴリでフィルタリングもできる。
テキトー教師使い方はシンプルですね。基本はこんな感じです。
# 全デバッグ情報を出力
claude --debug
# 特定カテゴリのみ出力(APIとMCPの情報のみ)
claude --debug "api,mcp"
# 特定カテゴリを除外して出力(statsigとfile以外)
claude --debug "!statsig,!file"
室谷!で除外できるのが便利なんですよ。全部出すと情報量が多すぎるので、「APIのやりとりだけ見たい」「MCPサーバーとの通信だけ絞りたい」という使い方が多いですね。MYUUUでもMCPの接続トラブルが出たときはまず
claude --debug "mcp"で確認しています。
テキトー教師受講生さんでよく見るパターンが「
--debugを付けたら情報が多すぎて逆にわからなくなった」という状況ですね。そういうときはカテゴリを絞るか、後述の--debug-fileでファイルに書き出すのがおすすめです。
室谷あと、
ちゃんとログを読めれば、「あ、レートリミットに当たってる」「トークン残量がほぼゼロ」みたいなことが一発でわかる。
--debug出力のフォーマットがちょっと特殊で。APIレスポンスのヘッダーから、レートリミット情報(anthropic-ratelimit-requests-remaining等)まで全部出てくるんですよ。ちゃんとログを読めれば、「あ、レートリミットに当たってる」「トークン残量がほぼゼロ」みたいなことが一発でわかる。
テキトー教師そういう情報ってUIからは見えないですよね。ターミナル慣れしていない人には最初は辛いけど、一度読み方を覚えると「なんでClaude Codeが止まったのか」の原因究明が速くなります。
--verboseフラグ:ターン単位の詳細出力
室谷--debugの次が--verboseです。これは「Enable verbose logging, shows full turn-by-turn output」とドキュメントにある。つまりターン単位の詳細ログが出ます。
テキトー教師--debugとの違いが気になりますよね。整理すると、こういう違いがあります。| フラグ | 用途 | 出力内容 |
|---|---|---|
--debug | APIレベルのデバッグ | HTTP通信・ヘッダー・レートリミット情報等 |
--verbose | ターン単位の詳細ログ | Claudeの各応答・ツール呼び出し全文 |
--debug "api,mcp" | カテゴリ指定デバッグ | 指定カテゴリのみ |
室谷実際の使い分けとしては、「Claude Codeが何かをしたが理由がわからない」→
--verbose、「ネットワークやAPI認証でおかしい」→--debug "api"、という感じですね。
テキトー教師--verboseは特にPostToolUseのあとに何が起きているか追いたいときに便利で。Hooksとの組み合わせでも、Ctrl+Oで詳細を展開できます。
室谷そうですね。Ctrl+Oのことも覚えておくと便利で、インタラクティブモードでもhookのstderrを
--verboseモードで確認できるんですよ。--debug-fileフラグ:ログをファイルに保存する
室谷ログを画面に出力するだけでは、長い作業の途中で流れてしまいます。そこで使えるのが
--debug-fileです。# ログをファイルに書き出す
claude --debug-file /tmp/claude-debug.log
# もしくは任意のパスに
claude --debug-file ~/Desktop/claude-debug-$(date +%Y%m%d).log
テキトー教師ドキュメントには「Implicitly enables debug mode」とあるので、
--debug-fileだけ付ければ--debugを別途指定しなくてもデバッグモードが自動的に有効になります。これ、受講生さんが知らなかったりするポイントです(笑)。
室谷--debug-fileはCLAUDE_CODE_DEBUG_LOGS_DIR環境変数より優先されるので、「今回だけこのファイルに書きたい」というときはこちらを使えばいい。ファイルに書き出しておくと、後でgrepで絞り込めるのがいいですよね。
テキトー教師あとCI/CDで自動実行しているClaude Codeのデバッグにも便利で。画面にターミナルが出ない環境でもファイルに落とせる。
室谷MYUUUでも自動化系のタスクでClaude Codeを動かすときは
--debug-fileでログ保存するようにしています。後から「あの実行、何をしたっけ」を追いやすい。CLAUDE_CODE_DEBUG_LOGS_DIR環境変数

室谷CLIフラグではなく環境変数でデバッグログの保存先を指定する方法もあります。
CLAUDE_CODE_DEBUG_LOGS_DIRを設定すると、Claude Codeが自動的にそのディレクトリにログを書き出します。# 環境変数で指定
export CLAUDE_CODE_DEBUG_LOGS_DIR=/var/log/claude-code
# または起動時のみ指定
CLAUDE_CODE_DEBUG_LOGS_DIR=/tmp/debug-logs claude
テキトー教師これはシェルの設定ファイル(
.zshrcや.bashrc)に書いておけば、毎回コマンドにフラグを付けなくていいので楽ですよね。「いつも開発中はデバッグログを残しておく」という運用に向いています。
室谷ただ注意点があって、
--debug-fileで明示的にパスを指定した場合、CLAUDE_CODE_DEBUG_LOGS_DIRより--debug-fileが優先されます。「あれ、設定したのにログがない」というときは、起動コマンドに--debug-fileが付いていないか確認するといいですね。
テキトー教師こういう優先順位の話、Claude Code全体にあるんですよ。CLIフラグ > ローカル設定 > プロジェクト設定 > ユーザー設定の順で上書きされる。
ログ設定も同じ考え方で整理できます。
ログ設定も同じ考え方で整理できます。
セッションのトランスクリプト:会話の全ログを読む
室谷ここからが結構知られていない機能で・・・Claude Codeはセッションのやりとりを全部JSONLファイルに記録しているんですよ。
テキトー教師「え、そんな機能あったんですか」って受講生さんによく言われます(笑)。実際どこに保存されているんですか?
室谷Hooksのドキュメントを見ると、
transcript_pathというフィールドがあって、これがセッションの会話ログファイルのパスを指しています。~/.claude/projects/以下のプロジェクト別ディレクトリに、JSONL形式で保存されています。
テキトー教師つまり自分が今日Claude Codeと何をしゃべったか、全部ファイルで確認できるわけですね。
室谷そうです。Hooksを使ってこのパスにアクセスすれば、自動的にログを解析したり、定期的にバックアップしたりもできる。
SessionEndのhookイベントで
SessionEndのhookイベントで
transcript_pathを読めばその日の会話ログが取れます。
テキトー教師さらにセッションを再開するときの
--resumeや-cフラグも、このセッションデータを使っているわけで。
室谷その通りです。
claude -cで「直前の会話を続ける」ができるのも、この会話ログが保存されているから。claude -r "session-name"でセッション名を指定して再開できるのも同じ仕組みです。セッションの保持期間とストレージ管理
テキトー教師セッションデータはずっと保存されるんですか?
室谷デフォルトでは30日間保存されます。
ただし0は設定できません(エラーになる)。
settings.jsonのcleanupPeriodDaysで変更できて、1日から自由に設定できる。ただし0は設定できません(エラーになる)。
テキトー教師大量のプロジェクトで使っていると、セッションデータがどんどん溜まりますよね。これが気になっていた受講生さんがいました。
室谷そこは
cleanupPeriodDaysを短くすることでコントロールできます。またプリントモード(-pフラグ)で使う場合は--no-session-persistenceフラグを付けることで、そもそもセッションをディスクに保存しないようにもできます。# セッションを保存しないプリントモード
claude -p --no-session-persistence "コードをレビューして"
テキトー教師CI/CDで使うときとか、ワンショットの処理では保存しない方がいい場合もありますよね。選択肢があるのがいい。
DEBUG環境変数の落とし穴
室谷ちょっと変なトラブル話をすると・・・プロジェクトの
.envファイルにDEBUG=trueが書いてあったら、Claude Codeが起動するたびに大量のデバッグ出力が出るんですよ。
テキトー教師え、なんでですか?
室谷Claude Codeはnode.jsで動いていて、
プロジェクトで
DEBUGという環境変数を読んでいるんですよ。これはnodeの標準的な仕組みで。プロジェクトで
DEBUG=trueやDEBUG=*を設定していると、Claude Code自体のデバッグ出力がガンガン出てしまう。
テキトー教師これは盲点ですね。プロジェクト側の
DEBUG設定がClaude Codeに影響するとは思わない人が多そうです。
室谷実際、Zennに「Claude Codeでデバッグ出力がやたら出る」という記事が書かれていて。原因は
Claude Codeは
.envのDEBUG=trueでした。Claude Codeは
process.envからDEBUGを読み込んでいるので、プロジェクトで設定している環境変数とバッティングするんです。
テキトー教師解決策はシンプルですね。
# .envファイルのDEBUG=trueをコメントアウトか削除
# DEBUG=true ← これがClaude Codeのデバッグ出力を誘発する
# または一時的に無効化
DEBUG=false claude
室谷あとは
DEBUGを特定のモジュール名に限定する書き方にすれば、Claude Code自体のデバッグ出力は出なくなります。DEBUG=myapp:*のように自分のアプリのネームスペースだけにするのが安全です。
テキトー教師これ、講座で話すと「あ、それだ!」ってなる人が必ずいるんですよ(笑)。知っておくと救われる情報ですね。
OpenTelemetryによるチーム・組織向けロギング

室谷ここからはEnterpriseな話をしましょう。個人利用なら前述のフラグで十分ですが、チームや組織でClaude Codeを使うとなると、誰がどれだけ使っているか、コストはどう推移しているか、といった管理が必要になります。
テキトー教師組織で数十人が使い始めると、「全体で月いくら使っているの?」が気になりますよね。
室谷そこで公式が用意しているのがOpenTelemetry(OTel)の統合です。環境変数で設定すると、メトリクス・ログ・トレースをまとめてバックエンドに送れます。
# OTelを有効化
export CLAUDE_CODE_ENABLE_TELEMETRY=1
# エクスポーター設定
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
# OTLPエンドポイント(GrafanaやDatadog等に送る)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
# 認証が必要な場合
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-token"
テキトー教師これを管理者側の
managed-settings.jsonに書いておけば、全ユーザーに強制適用できるわけですね。
室谷正確にはこうです。
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_LOGS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
"OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
"OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer example-token"
}
}
テキトー教師これを見て受講生さんがよく言うのが「設定が多すぎてよくわからない」なんですけど(笑)、エッセンスは3行なんですよ。「テレメトリを有効にする」「どこに送るか(OTLPエンドポイント)」「どのプロトコルで送るか」この3つさえ決まれば動きます。
室谷送れるデータの種類も整理しておきましょう。
OTelで取得できるメトリクスとイベント
| メトリクス | 説明 |
|---|---|
claude_code.session.count | セッション開始数 |
claude_code.lines_of_code.count | 編集した行数(追加/削除) |
claude_code.commit.count | 作成したgitコミット数 |
claude_code.pull_request.count | 作成したPR数 |
claude_code.cost.usage | セッションのコスト(USD) |
claude_code.token.usage | 使用トークン数 |
claude_code.active_time.total | 実際に使用した時間(秒) |
室谷このあたりのメトリクスがGrafanaやDatadogに流れてくると、「今月はどのユーザーが一番コストをかけているか」「どのプロジェクトでPRが増えたか」がダッシュボードで可視化できます。MYUUUでも組織管理の観点でこれを活用していますよ。
テキトー教師さらに詳細なイベントログも取れるんですよね。
室谷そうです。
ただしデフォルトはオフです。プライバシー面での配慮が必要なので、企業利用では慎重に判断してほしいですね。
OTEL_LOG_USER_PROMPTS=1を設定するとユーザーのプロンプト内容も記録できます。ただしデフォルトはオフです。プライバシー面での配慮が必要なので、企業利用では慎重に判断してほしいですね。
テキトー教師OTEL_LOG_TOOL_DETAILS=1でbashコマンドやMCPサーバーの操作詳細も取れる、と。
室谷コンプライアンス上「Claude Codeが何のコマンドを実行したか」の監査ログが必要な環境では、このオプションが役立ちます。
Hooksでカスタムログを作る
室谷もう少し実践的な話をすると、Claude CodeのHooks機能を使うとかなり柔軟なロギングができます。これ、知っている人と知らない人で使いこなし度が全然違う・・・
テキトー教師Hooksはそれ自体が大きなテーマですが、ロギング目的での使い方は比較的シンプルですよね。
室谷典型的なのがこれ、全ツール実行をログに記録するパターンです。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo \"$(date): $TOOL_NAME - $TOOL_INPUT\" >> ~/claude-tool-log.txt",
"async": true
}
]
}
]
}
}
テキトー教師async: trueを付けると、ログ書き込みがバックグラウンドで走るので、Claudeの作業が遅くなりません。これ重要なポイントです。
室谷MCPサーバーの操作をログに残すパターンもよく使います。公式ドキュメントにもサンプルがあって、こういう書き方です。
{
"hooks": {
"PreToolUse": [
{
"matcher": "mcp__memory__.*",
"hooks": [
{
"type": "command",
"command": "echo 'Memory operation initiated' >> ~/mcp-operations.log",
"async": true
}
]
}
]
}
}
テキトー教師mcp__memory__.*のように正規表現でマッチできるので、特定のMCPサーバーの操作だけを絞ってログに残すことができます。
室谷あと個人的にオススメしているのが、SessionStartとSessionEndのHookでセッションの開始・終了時刻を記録するパターンです。これだけで「今日何時間Claude Codeを使ったか」が可視化できる。
テキトー教師生産性トラッキングとして使っている受講生さんがいますよ。Notionに書き込むHookを作って、毎日のログを自動で蓄積している方がいて・・・こういう工夫がアドバンスドなユーザーらしい使い方だと思います。
PostToolUseFailureでエラーログを残す
室谷もう一個便利なHookが
PostToolUseFailureです。ツールの実行が失敗したときだけ発火するイベントで、エラーだけをログに残せます。{
"hooks": {
"PostToolUseFailure": [
{
"hooks": [
{
"type": "command",
"command": "echo \"ERROR $(date): Tool failed\" >> ~/claude-errors.log",
"async": true
}
]
}
]
}
}
テキトー教師エラーだけ集めておくと、「Claude Codeが何度も同じ失敗をしている」パターンが見えてきます。自分のプロジェクト環境に何かClaude Codeが苦手な操作があるか、把握するのに役立ちますね。
室谷Claude Codeが繰り返し失敗しているとしたら、それはたいてい自分のCLAUDE.mdの設定が足りていないサインなので。ログでパターンを把握して、CLAUDE.mdに「このケースではこうしてほしい」と追記する、というサイクルを回せます。
claude loggingとllogging:ロギングライブラリとの混同に注意
室谷サジェストを見ていると「claude code logging」というKWがあって・・・pythonのloggingライブラリと混同している人が若干いそうですね。
テキトー教師Claude Code自体のロギング機能と、「Claude Codeを使ってPythonのlogging設定を書いてもらう」は全然別の話ですからね(笑)。
室谷Claudeに「loggingの設定を書いて」と頼めば普通にPythonのloggingライブラリのコードを書いてくれます。「claude code logging」という文脈では、Claude Code自体のログ出力の話をしているのか、Claude Codeでloggingコードを生成する話なのか、混在しがちです。
テキトー教師この記事では前者、Claude Code自体のログ機能を扱っています。後者は普通にClaudeに「pythonのlogging設定、structlogを使って書いて」と頼めば一発で出てきます。
/doctorコマンド:環境チェックを1発でやる
室谷ログの話からは少し外れますが、Claude Codeの状態確認に非常に便利なコマンドが
/doctorです。
テキトー教師これ、受講生さんに一番最初に教えるコマンドの一つです。何かおかしいと思ったらまず
/doctorと打ってください、と。
室谷/doctorが確認してくれる内容はこれだけあります。- インストールの種類・バージョン・検索機能の動作確認
- 自動アップデートのステータスと利用可能なバージョン
- 設定ファイルの妥当性(JSON構文エラー・型の誤り等)
- MCPサーバーの設定エラー
- キーバインド設定の問題
- コンテキスト使用状況の警告(CLAUDE.mdが大きすぎる等)
- プラグインとエージェントの読み込みエラー
テキトー教師MCP絡みのトラブルのとき、
/doctorを実行したら「MCPサーバーの設定に問題があります」と一発で出てきたケースを何度も見ています。--debug "mcp"を見る前に/doctorで診断するのが効率的ですね。
室谷あと
/feedbackコマンドもあって、これはAnthropicに直接フィードバックを送れるコマンドです。「このバグは絶対Anthropic側の問題だ」と思ったら/feedbackで報告するのが一番早い。verbose出力とHookのCtrl+Oデバッグ
室谷インタラクティブモードでClaude Codeを使っているとき、Ctrl+OでHookのstderrをその場で確認できます。これがロギングというよりリアルタイムデバッグになるんですよ。
テキトー教師Hookを書いたけど動いているかわからない、というときに便利ですね。
--verboseモードでClaude Codeを起動しておくと、Hookのエラー出力がCtrl+Oで見られる。
室谷もうひとつ、
/hooksというコマンドで現在設定されているHookの一覧を確認できます。Hookが意図した通りに登録されているか確認するのに使います。
テキトー教師/hooksを打つと、イベント・マッチャー・タイプ・ソースファイル・コマンドが一覧で表示されます。設定を変えたのに反映されないときは、これで「ソースファイルが正しいか」「マッチャーが想定通りか」を確認できます。トラブルシューティング実践:ログで原因を特定する
室谷ここからは実際のトラブルシューティングで、ログをどう活用するかを具体的に見ていきましょう。
テキトー教師よくあるパターンをいくつか挙げましょうか。私が受講生さんから相談を受けるケースをベースに。
パターン1:Claude Codeが途中で止まる
室谷これは
--debug "api"で確認するのが一番です。レートリミットに当たっているか、API側でエラーが出ているかがすぐわかります。
テキトー教師デバッグログを見ると
anthropic-ratelimit-requests-remaining: 0みたいな行が出ているはずです。これが0になっているとリクエストできなくなっています。
室谷対策はシンプルで、少し待つか、Maxプランにアップグレードするかですね。ただ「なぜ止まったのか」がわからないまま使い続けると、同じことが繰り返されるので。
ログで原因を確認する習慣は大事です。
ログで原因を確認する習慣は大事です。
パターン2:MCPサーバーが接続できない
テキトー教師claude --debug "mcp"で接続試行のログが出ます。接続できない場合、エラーメッセージがそこに出てくるので原因が特定しやすいです。
室谷よくあるのが、MCPサーバーのパスが間違っている・サーバープロセスが起動していない・ポートが塞がれている、このあたりです。
--debug "mcp"のログに「connection refused」とか「server not found」が出ていれば、その方向で対処できる。
テキトー教師/doctorでも「MCPサーバーの設定エラー」として出てくることがあるので、まず/doctorで試して、次に--debug "mcp"、という順番がスムーズです。パターン3:403 Forbiddenが出る
室谷認証回りのエラーで多いのが
403 Forbiddenです。これは--debug "api"で詳細を確認すると、原因がいくつかに絞れます。- サブスクリプションが失効している
- Console側でClaude Codeのロールが割り当てられていない
ANTHROPIC_API_KEYが古いキーで上書きされている
テキトー教師最後のケースが落とし穴で。以前のプロジェクトやAPIキーが
~/.zshrcにexport ANTHROPIC_API_KEY=...と書かれていて、それが有効なサブスクリプションに干渉するパターンがあります。
室谷claude auth statusで「どの認証方法が使われているか」をJSON形式で確認できます。ANTHROPIC_API_KEYが使われているのか、OAuthが使われているのかがわかります。# 認証状態の確認
claude auth status
# テキスト形式で確認したい場合
claude auth status --text
テキトー教師/statusコマンドをClaude Code内から実行しても同様の情報が確認できます。これで「あ、古いAPIキーが使われていた」と気づくことが多いです。ログの活用:チームでの運用設定
室谷ちょっと俯瞰した話もしておくと、個人のデバッグ用途だけじゃなく、チームでClaude Codeを使うときにログ設計をどうするかが重要になってきます。
テキトー教師たとえば企業導入しているときに「誰がどんなコマンドを実行したか記録しておきたい」という要件が出てくるわけですよね。
室谷そこで実際によく使われる設計が、managed-settings.jsonにOTelの設定を入れてGrafanaやElasticsearchに全部流す、というパターンです。
テキトー教師セキュリティ観点でいうと、
OTEL_LOG_USER_PROMPTS=1はデフォルトで無効なのが正解で。プロンプトの内容が機密情報を含む場合があるので、有効にするかどうかは会社のポリシーに照らして判断が必要です。
室谷MYUUUでは、コスト管理のために
「月間でいくらかかっているか」を把握できれば、個人レベルの管理としては十分なので。
claude_code.cost.usageとclaude_code.token.usageだけを取得するシンプルな設定にしています。プロンプト内容は取得しない。「月間でいくらかかっているか」を把握できれば、個人レベルの管理としては十分なので。
テキトー教師コスト可視化は特に重要で。Claude Codeを使い始めると「思ったより使っていた」ということが起きやすい。
月末に請求が来てびっくりするより、リアルタイムで
月末に請求が来てびっくりするより、リアルタイムで
claude_code.cost.usageを見ておく方がいいですよね。
室谷これはMax 5xや20xプランの人でも関係あって。定額だとしても「どのタスクにどれだけトークンを使っているか」の感覚を掴んでおくと、より効率的な使い方ができます。
Claudeに丸投げしすぎていないか、プロンプトが無駄に長くなっていないか、の気づきにもなるんですよ。
Claudeに丸投げしすぎていないか、プロンプトが無駄に長くなっていないか、の気づきにもなるんですよ。
設定値の早見表
テキトー教師ここまでの話をまとめると、こういう使い分けになりますね。
| 用途 | 設定方法 |
|---|---|
| 即席デバッグ | claude --debug "api,mcp" |
| 詳細な応答確認 | claude --verbose |
| ログをファイルに保存 | claude --debug-file /tmp/debug.log |
| 常時デバッグログを保存 | export CLAUDE_CODE_DEBUG_LOGS_DIR=~/logs |
| 環境変数の競合を回避 | .envのDEBUG=trueを確認・削除 |
| チームのテレメトリ | managed-settings.jsonにOTel設定 |
| 環境診断 | /doctorコマンド |
| 認証確認 | claude auth status |
室谷この表を見て「あ、自分のケースはこれだな」と当てはめてもらえると、解決が早いです。
よくある質問
Q: --debugフラグを付けると速度は落ちますか?
室谷--debugは基本的にログの出力量が増えるだけなので、API呼び出し自体の速度には影響しません。ただしターミナルに大量のテキストが流れるため、画面描画に多少の負荷はかかります。速度を気にする場合は
--debug-fileでファイルに書き出す方が安心です。
テキトー教師CIで自動実行する場合はファイルに書き出す方が、後から確認もしやすいですし。
--verboseも同様で、見かけ上「Claude Codeが何をしているか」が全部表示されるため画面出力は増えますが、処理自体は変わりません。Q: セッションのトランスクリプトはどのくらい溜まりますか?
室谷プロジェクトと使用頻度によりますが、1セッションあたり数KBから数MBのJSONLファイルが生成されます。毎日ヘビーに使うと30日でそれなりのサイズになります。
cleanupPeriodDaysを短くするか、重要なセッションだけ別途バックアップしておくのがいいですね。
テキトー教師セッションの保存場所は
~/.claude/projects/以下なので、定期的にdu -sh ~/.claude/でサイズ確認する習慣をつけておくといいです。Q: 法人導入でプロンプトの内容を全員分ログに残すことはできますか?
室谷OTEL_LOG_USER_PROMPTS=1をmanaged-settings.jsonで設定すれば可能です。ただし、法的・プライバシー上の観点から従業員への事前通知と同意が必要になる場合があります。また、プロンプトに機密情報が含まれる場合のデータ保護も検討が必要です。導入時はIT・法務部門と連携して設定することをお勧めします。
テキトー教師ゼロデータリテンション(ZDR)オプションを使っているOrganizationの場合も、OTelログとZDRポリシーの関係を確認しておくといいですね。公式ドキュメントの「Data usage」「Zero data retention」ページが参考になります。
Q: claude code logとclaude loggingで検索すると全然違う結果が出るのですが
室谷そうなんですよ・・・「claude code logging」で検索すると、PythonのloggingライブラリをClaude Codeで使う方法が出てきたりします。この記事はClaude Code自体のログ出力・デバッグ機能の話です。
Pythonのloggingライブラリを使ったコードを書いてもらいたいなら、そのまま「pythonのlogging設定を書いて」とClaude Codeに話しかければOKです(笑)。
Pythonのloggingライブラリを使ったコードを書いてもらいたいなら、そのまま「pythonのlogging設定を書いて」とClaude Codeに話しかければOKです(笑)。
テキトー教師Claude Codeはloggingライブラリの扱いも得意なので、「structlogを使ってjsonフォーマットでログを出力するPythonコードを書いて」とお願いすれば一発で書いてくれます。ここは混同しないようにしておくといいですね。
まとめ:Claude Codeのログ・デバッグ機能を使いこなす
室谷今回はClaude Codeのログ機能を全部整理しました。まとめると、段階的に使い分けるイメージがいいですね。
テキトー教師まず
/doctorで環境診断、次に--debugや--verboseでリアルタイムのデバッグ情報、長期的なトレースにはセッションのトランスクリプトやHooks、チーム・組織管理にはOTel統合、という流れですね。
室谷特に
DEBUG環境変数の競合は、プロジェクトに.envを使っている人なら誰でも踏む可能性があるので覚えておいてください。「なぜかデバッグ出力が大量に出る」というときは、まず.envの中身を確認です。
テキトー教師あと
claude auth statusコマンドは、認証周りの謎のエラーが出たときに真っ先に使ってほしいです。「どの認証情報が使われているか」が可視化されるだけで、問題が解決することが多いので。
室谷Claude Codeは黒い箱に見えるかもしれないけど、ログを通じて「今何をやっているか」が全部見えるようになっています。ログを読む習慣をつけると、Claudeへの指示の仕方も変わってくるんですよね・・・「あ、このAPIの呼び方でトークンを消費しすぎている」とか気づけたりする。
テキトー教師まさに。ログを読める人は、Claude Codeを道具として使いこなしている人ですね。
次回は、ここで触れたHooksについてもっと深く掘り下げていきましょうか。
次回は、ここで触れたHooksについてもっと深く掘り下げていきましょうか。
室谷そうしましょう。Hooksを使いこなせると、Claude Codeが全然違うツールになりますから。
