read-claude-web-conversation

Claude.ai Web 会話を読み取る

Claude.ai のウェブ会話を、すべてのメッセージとツール呼び出しを含む、完全で構造化されたトランスクリプトとして取得します。現在画面に表示されている内容だけではありません。

2026 年 7 月時点の Claude.ai ウェブ API で検証済みです。これらは Claude.ai のフロントエンドが呼び出すものと同じ非公開の JSON エンドポイントです。ドキュメント化されたものでも、バージョンが安定した公開 API でもないため、リクエストが 404 を返した場合は、Network タブから形式を再度確認してください（references/claude-web-api-extraction.md を参照）。

このスキルと関連スキルの使い分け

「conversation」という言葉ではなく、手元にあるソースを基準に選んでください。

ソース	使用するもの
実際の claude.ai/chat/… または claude.ai/share/… URL	このスキル
ローカルの Claude Code セッション（~/.claude/projects/*.jsonl）	read-claude-code-history
すでにエクスポートされた .txt／.json 会話ファイル	claude-export-txt-better

よくある方法が失敗する理由（最初にお読みください）

落とし穴は 4 つあり、どれも気づかないうちに失敗します。完全なエクスポートに見えるものが返されるため、会話の実際の長さを知っている場合にしか欠落に気づけません。まずは何かが欠落していると考えてください。Step 4 の忠実性チェックは、その欠落を検知できるようにするものです。

1. ログインの壁。 curl と WebFetch は認証リダイレクトを受け取らず、Cloudflare のチャレンジページ（HTTP 403、Just a moment...）を受け取ります。ヘッダーをどう変更しても解決しません。このページはユーザーの Chrome にあるセッションで保護されています。ここでは絶対に curl を使わないでください。「ちょっと確認する」場合でも同じです。
2. 仮想スクロール。 会話を開いていても、get_page_text と DOM スクレイピングで取得できるのは、現在レンダリングされている数件のメッセージだけです。多くの場合、最後の 1 件だけです。40 件のスレッドが 1 件として返ってくることがあります。
3. デフォルトのレンダリングではツール呼び出しが折りたたまれます。 API のデフォルトのレンダリングでは、すべてのツール呼び出しが「お使いの現在のデバイスではサポートされていません」というプレースホルダーになります。調査／エージェントの会話では、ツールのブロックがコンテンツそのものです。実際の会話で計測したところ、デフォルトのレンダリングでは render_all_tools=true を指定した場合の 173k 文字に対して 9.4k 文字しか返されず、わずか 5% でした。必ず完全なレンダリングをリクエストしてください。
4. /chat/ 形式のレンダラーでは /share/ のブロックが気づかないうちに欠落します。 share ペイロードでは、web_search の結果は text 項目ではなく knowledge 項目として返されます。text しか扱えないレンダラーは、それらに対して空の文字列を返し、エラーも報告しません。同じ実際の会話をレンダリングしたところ、**146k 文字ではなく 8k 文字（保持率 4.8%）**しか出力されませんでしたが、見た目にはまったく問題がないように見えました。

**信頼できる方法：**ユーザーがログインしているページ内で JavaScript を実行し、fetch にセッション Cookie を引き継がせてから、忠実性チェックを通してローカルでレンダリングします。

Step 0 — 注入方法を選ぶ

ユーザーのページ内で JS を実行できる方法は 3 つあります。違いは接続方法だけですが、それぞれ異なる理由で失敗するため、次の順に選び、推測で済ませず動作を確認してください。

順序	方法	使用する条件	失敗する条件
1	claude-in-chrome extension	list_connected_browsers がブラウザーを返す場合	[] が返る → 拡張機能の claude.ai ログインが Claude Code アカウントと異なります。これは構造上の問題です。再試行、再インストール、switch_browser はすべて失敗します。すぐに次へ進んでください。
2	CDP（scripts/cdp_channel.py probe）	probe が available: true を示す場合。これは最良の方法です	通常は利用できませんが、これは不具合ではなく正常な状態です。詳しくは以下を参照してください。Probe は低コストなので、その結果を信頼して次へ進んでください。
3	AppleScript（macOS のみ）	拡張機能と接続できない場合の現実的な代替手段	以下の振り分けに関する落とし穴を参照してください。ユーザーのせいにする前に確認してください
✗	curl / WebFetch	絶対に使用しない	Cloudflare 403 が返されます。解決するヘッダーはありません。
⚠️ CDP は利用できないものと想定し、決して無理に使おうとしないでください。 Chrome 136
（2025 年 4 月）以降、デバッグポートは デフォルトの user-data-dir では無視されます。これは、CDP を使って Cookie を盗むマルウェアへの意図的なセキュリティ強化です。リッスン中のソケットや、ディスク上に古い DevToolsActivePort が見つかっても、WebSocket ハンドシェイクには応答せず、/json/* は 404 を返すことがあります。

しかも、利用可否は変動します。 Chrome 150 を使い、1 台のマシンで 1 回のブラウザーセッション中に確認したところ、エンドポイントは動作した後、完全に応答しなくなり、その後また応答するようになりました。再起動はしていません。したがって、毎回プローブし、判定をキャッシュしないでください。 「5 分前には CDP が動作した」は、今も動作する証拠ではありません。「一度 CDP に失敗した」も、このマシンでは使えない証拠ではありません。プローブは安価なので、何度でも確認できます。

次に試したくなる方法が落とし穴です。ウェブ上の対処法はどれも「--user-data-dir=/tmp/whatever を付けて Chrome を再起動する」と案内しています。このスキルでは、これは役に立たないどころか逆効果です。新しいプロファイルはサインアウト状態であり、サインアウト状態のブラウザーではユーザーの会話を 1 つも読めません。 必要なセッションは、まさに Chrome が公開を拒んでいるプロファイルにあります。ですから、プローブして結果を受け取り、フォールバックしてください。ポートを使うために、ユーザーのブラウザーを再設定したり再起動したりしてはいけません。

Chrome がデフォルト以外の --user-data-dir を指定して意図的に起動され、かつ claude.ai にサインインしている場合、CDP は動作します。そうした状況もあり、その場合はこのチャネルが他のチャネルより明らかに優れています（メニュー切り替えが不要で、以下の Apple Events によるキャプチャの影響を受けず、すべてのタブを列挙でき、ペイロード全体を stdout に返します）。そのため、次の手順に進む前に、安価なプローブを 1 回実行する価値があります。

チャネル 1 を試すには、 1 回の ToolSearch 呼び出しで拡張機能のツールを読み込みます（これらのツールは遅延読み込みされます。API パスでは get_page_text / read_page は不要です）。

ToolSearch: select:mcp__claude-in-chrome__tabs_context_mcp,mcp__claude-in-chrome__navigate,mcp__claude-in-chrome__javascript_tool

次に list_connected_browsers を呼び出します。リストが空の場合はアカウントが一致していません。再試行せずにチャネル 2 に進んでください。

チャネル 2 を試すには：

uv run --with websockets python scripts/cdp_channel.py probe

probe は、CDP が利用可能か、ユーザーの 実際の ブラウザーを指しているか（ページ数と、すでに開いている claude.ai のタブの有無）、さらに 複数の Chrome インスタンスが実行中かどうかを一度に確認します。出力によって、以下のすべての処理が決まります。AppleScript を使うかどうかも同様です。Apple Events が正しいブラウザーに届くかどうかは、chrome_instances.automation のリストで判断できます。

終了コードは契約になっているため、フォールバックすべきかどうかを推測する必要はありません。

code	意味	対応
0	成功	続行します
1	入力不正（--js を読み取れないなど）	呼び出しを修正します
2	TAB_NOT_FOUND	open を使うか、ページを開くようユーザーに依頼します
3	CDP を利用できません	別のチャネルにフォールバックします。これは通常の結果です
4	ブラウザーがエラーを返しました	コマンドが誤っているか、呼び出し中にタブが消えました。フォールバックしても解決しません

終了コード 3 でも chrome_instances は出力されます。この情報の取得にデバッグポートは不要だからです。これはルーティングに関する事実であり、エラーではありません。内容を確認してチャネル 3 に進み、デバッグポートについてユーザーには何も伝えないでください。

AppleScript のルーティングの落とし穴（ユーザーのせいにする前にお読みください）

AppleScript は バンドル ID で Chrome を指定します。2 つ目の Chrome インスタンスが実行中の場合（chrome-devtools-mcp、puppeteer、playwright、独自の --user-data-dir を指定して起動されたものなど）、Apple Events がそのインスタンスに送られることがあります。macOS では pid を指定して最初のインスタンスを対象にする方法はありません。回避策もありません。

これが本当に危険なのは、次のように見えるからです。自動化用プロファイルでは「Apple Events からの JavaScript を許可」がオフになっているため、JS の実行を試みると 「AppleScript 経由での JavaScript の実行はオフです」 というエラーになります。そして、ユーザーがメニューの切り替えを忘れたのだと判断し、設定を切り替えるよう頼んでしまいます。しかし、実際に使っているブラウザーでは、最初からずっと有効になっていたのです。実際に、AppleScript は windows=1 tabs=1 と報告する一方、ユーザーの実際の Chrome では 35 個のタブが開いている事例が確認されています。

そのため、AppleScript にフォールバックする前に probe（または cdp_channel.py の chrome_instances()）を実行し、automation リストを確認してください。空でなければ、そのことをはっきり伝えてください――"自動化用 Chrome が Apple Events の経路を占有しているため、AppleScript は別のブラウザーを操作します"――そのうえで CDP を使うか、そのインスタンスを終了できるか尋ねてください。原因を特定できない切り替えエラーを伝えてはいけません。

チャネルの詳細と base64 バイナリブリッジ：references/applescript_fallback_channel.md。

ステップ 1 — アカウントのケースを特定する（取得できる内容が決まります）

取得できる会話の範囲は、ブラウザーでどのアカウントにサインインしているかによって異なります。 早い段階で確認してください。完全なアーカイブになるか、復元不可能な欠落があるアーカイブになるかの違いであり、ユーザーには渡す前にどちらなのかを知らせる必要があります。

ケース	シグナル	取得できる内容
A · 未サインイン	/api/organizations が組織を返さない	/chat/ リンクからは何も取得できません。ここで停止し、Chrome で claude.ai にサインインするようユーザーに依頼してください。ログインを自動化してはいけません。
B · サインイン済みで、会話がこのアカウントに属している	GET .../chat_conversations/<conversation-id> が 200 を返す	添付ファイルの内容を含むすべて。利用できる場合は常に、この方法を優先してください。
C · サインイン済みだが、他の人が共有したリンク	会話の取得が 404 になり、スナップショットの creator ≠ このアカウント	スナップショットのみ。プラットフォームは、共有者がアップロードしたファイルに触れたすべてのツール呼び出しについて、引数と結果を削除します。 このリンクからは復元できません。

/share/… リンクでは、スナップショットのペイロード自体から該当するケースを判別できます。元の会話の conversation_uuid と creator が含まれているためです。まずスナップショットを取得し、次に conversation_uuid を使って元の会話の取得を試してください。200 が返ればケース B なので、スナップショットは情報がより欠落しているため、そちらから再エクスポートしてください。404 が返ればケース C です。そのことをはっきり伝え、トランスクリプトのヘッダーでレンダリング手順に欠落を開示させてください（自動で行われます）。

ケース C の欠落は実際にあり、正確に説明する価値があります。エクスポートの不具合に見えますが、そうではありません。アップロードされたファイルの view は名前を保持しますが、path とファイルの内容全体は失われます。通常、そのファイルのユーザー自身のコピーはディスク上にあります。エクスポートが壊れているのではなく、プラットフォームが共有を拒否したファイルについては内容を示せないだけです。

ステップ 2 — 会話を開く

拡張機能：tabs_context_mcp に { "createIfEmpty": true } を指定し、その後 navigate を実行します。
CDP：cdp_channel.py open --url <url>（既存のタブを再利用し、Cloudflare のインタースティシャルが終わるまで待機します。ブラウザーが自動で解除します）。

どちらの場合も、実際に読み込まれ、サインイン済みであることを確認してください。タブのタイトルは「ログイン」ではなく、会話の名前になっているはずです。ログインページが表示された場合は、そこで停止してユーザーに伝えてください。ログインを自動化してはいけません。

ステップ 3 — ペイロードを取得する

常にツールの完全なレンダリングをリクエストしてください。 render_all_tools=true を指定しないと、分析部分がプレースホルダーになります（上記の落とし穴 3）。

リンクの種類	エンドポイント
/chat/<conversation-id>	GET /api/organizations/<org-uuid>/chat_conversations/<conversation-id>?tree=True&rendering_mode=messages&render_all_tools=true
/share/<snapshot-id>	GET /api/chat_snapshots/<snapshot-id>?rendering_mode=messages&render_all_tools=true

共有エンドポイントが参照するのは、URL 内のスナップショット IDであり、会話 ID ではないことに注意してください。スナップショット ID を chat_conversations に渡すと 404 になりますが、この 404 は「アクセス権がない」ではなく、「ID が違う」という意味です。どちらの ID も不透明な値です。必ず固定値を使わず、開いている URL から取得してください。

• 拡張機能チャネル → ページ内で scripts/export_conversation.js を実行し（実行してから結果をポーリングする手順はヘッダーにあります）、その後、window.__claudeExport.rawJson を約 16k の .slice() ウィンドウでページ分割して出力します。
• CDP チャネル → scripts/fetch_cdp.js を実行します。このスクリプトは会話の完全な JSON を Promise として直接返すため、cdp_channel.py eval が 1 回の呼び出しで解決し、結果をファイルにストリーミングします。

  uv run --with websockets python scripts/cdp_channel.py eval \
      --match <conversation-or-snapshot-id> --js scripts/fetch_cdp.js --out conversation.json
  

  awaitPromise は非同期フェッチを 1 回の呼び出しで解決し、値は標準出力に返されるため、数メガバイトのペイロードをコンテキストウィンドウに渡す必要はありません。
• AppleScript チャネル → scripts/runjs.applescript を使って scripts/export_conversation.js を実行し、その後、window.__claudeExport.rawJson をポーリングして読み出します（実行してからポーリングします。チャネルのリファレンスを参照してください）。

ツール呼び出しのない通常のチャットで、テキストをすぐに取得するだけでよい場合は、references/claude-web-api-extraction.md のインラインスニペットを使うと、ページ内で 1 回の呼び出しでトランスクリプトを組み立てられます。

ステップ 4 — 忠実性ゲートを通してローカルでレンダリングする

uv run python scripts/render_transcript.py conversation.json -o transcript.md \
    --source-url <url>

これは両方のペイロード形式（/chat/ と /share/）に対応し、すべてのツール呼び出しをレンダリングして、ツールの出力を <details> に折りたたみ、web_search の引用を「引用元」リストにまとめます。

情報が失われたトランスクリプトの書き込みも拒否します。 出力する前にすべてのブロックを監査し、「このブロックには N 文字が含まれていたが、レンダラーは何かを出力したか？」を確認します。テキストを含むブロックから何も出力されなかった場合は 2 で終了します。これが罠 4 による失敗であり、このチェックがなければ見えません。Markdown は問題なく見え、終了コードは 0 なのに、会話の 95% が失われています。レンダリング対象の量をパーサーに尋ねるゲートでは、パーサー自身の見落としを確認することしかできないため、予算は意図的にレンダリング経路ではなく、未加工のペイロードを基に計測します。

失敗した場合は、問題のブロックと確認するためのコマンドが表示されます。新しい形式に対応するよう result_item_text()／render_block() を修正してください。--allow-lossy を使うのは、損失を許容すると意識的に判断した場合だけにしてください。それが正しい答えであることはほとんどなく、最初に選ぶべき答えでは決してありません。

プラットフォーム側で空にされたブロック（ケース C）は、損失ではなく、明示された欠落として別に計上され、トランスクリプトのヘッダーに表示されます。問題なく完了すると、計測結果も出力されます。

fidelity: 143,088/143,088 chars rendered (100.0%)
known gap: 12 tool blocks were emptied by the platform (view) — disclosed in the
           transcript header, NOT recoverable from a shared link

このゲートはブロック単位ではなく、アイテム単位で監査します。実際にコンテンツが失われる粒度はアイテム単位です。ブロック単位のチェックでは、ブロックの一部でも出力されればブロック全体がレンダリングされたと見なされるため、38k 文字のアイテムが消えても、16 文字の兄弟アイテムに隠れて 100% と判定されていました。また、content[] だけを対象とする監査では構造上確認できないものも対象にします。メッセージレベルの添付ファイル本文（貼り付けられたドキュメントはブロックではなく、ここに格納されます）、トップレベルの text、そしてアクティブなパスの走査で到達しなかったメッセージです。何も含まれないペイロードのスコアは 100% ではなく 0% です。空の取得は、このゲートが防ぐべき損失の極端な例です。

レンダラーを変更した場合は、回帰テストスイートを実行してください。 その中の各ケースは、以前のバージョンのゲートをすり抜けた形式です。

uv run python scripts/selftest_fidelity.py

出力形式とナビゲーション（--toc）

デフォルトの出力形式は Obsidian です。Obsidian のライブプレビューでは HTML の <details> がレンダリングされないため、そうしないと折りたたみ可能なツール出力、思考、ファイル本文がそのまま並んでしまいます。デフォルトでは各 <details> ブロックを、ネイティブの > [!info]- 折りたたみ可能なコールアウトに変換します。

uv run python scripts/render_transcript.py conversation.json -o transcript.md \
    --source-url <url> --toc

従来の HTML <details> 出力が必要な場合は、--format markdown を使用してください。

この変換は、<details> 形式の Markdown に対する忠実性ゲートの通過後にのみ実行されます。ペイロード文字列に触れない見た目上の後処理であるため、保持の検証に影響することはありません（ゲートより前に移動しないでください）。--toc はリンク付きの目次を先頭に追加し、メッセージごとのアンカー（<a id="turn-N">）を挿入することで、長い会話をナビゲートしやすくします。--extract-file の出力は形式を変換しません。

ほかのモードは変更ありません。--list-files は、ダウンロード可能なすべてのファイルと、それぞれに必要なエンドポイントファミリーを一覧表示します。--extract-file <sandbox-path> は、create_file とそれ以降のすべての str_replace を再適用して、サンドボックスで作成されたファイルを復元します。置換が見つからない場合や曖昧な場合は、古い内容を返すのではなく、何も出力せずに終了します。

完了確認 — ファイルが残っている間はレンダリングは完了していません

render_transcript.py は、トランスクリプトを書き出すときに stderr に2行を出力します。 レンダリングが完了したと宣言する前に、両方を確認してください。

fidelity: 143,088/143,088 chars rendered (100.0%) across 7 message(s)
files: 2 downloadable file(s) in this conversation — the transcript names them but does NOT carry the bytes, so a text-only export is an INCOMPLETE archive. ...

fidelity: 行は保持の証明です。files: 行は完了シグナルです。ファイルが報告されている場合、トランスクリプトには名前だけが記載され、ファイルのバイトデータは含まれていません。テキストのみのエクスポートは、不完全なアーカイブです。この行が fidelity: と同じ stderr ストリームに出力されるのは、そうしないと完了を急ぐ処理が 100% を見てファイルが取得される前に停止し、テキストエクスポートを完全なアーカイブと取り違えてしまうからです。（files: 行がまったくない場合、会話にはダウンロード可能なファイルがありません。その場合、レンダリングだけで本当に完了しています。）

したがって、files: が N > 0 を報告した場合、それらをダウンロードすることはこの手順の一部であり、任意の追加作業ではありません。 「アーカイブ／エクスポート／ローカルに保存」と依頼したユーザーが求めているのは完全なアーカイブです。参照先のファイルが未ダウンロードのままトランスクリプトを渡すのは、不完全なアーカイブを渡すことになります。（--list-files／--extract-file はこの通知を出力しません。レンダリングの分岐に入る前に戻るためです。）

scripts/download_files.js を使って、アップロード、アシスタントの画像、サンドボックスの成果物をすべて一覧化し、適切なエンドポイント群から取得してください。このスクリプトはチャネルに依存しない JS です。取得に使用したチャネルと同じチャネルで実行してください。CDP の場合（1回の呼び出しで結果は stdout に出力）：

# 1. Fire the inventory/download
uv run --with websockets python scripts/cdp_channel.py eval \
    --match <conversation-or-snapshot-id> --js scripts/download_files.js
# 2. Poll until the status line is no longer 'pending' (a few seconds)
echo "window.__dlStatus" > /tmp/check_dl.js
uv run --with websockets python scripts/cdp_channel.py eval \
    --match <conversation-or-snapshot-id> --js /tmp/check_dl.js
# 3. Extract one file at a time (repeat for each name the status line listed)
echo "window.__dl['filename.png']" > /tmp/read_one.js
uv run --with websockets python scripts/cdp_channel.py eval \
    --match <conversation-or-snapshot-id> --js /tmp/read_one.js 2>/dev/null \
  | tr -d '\n' | base64 -d > filename.png

AppleScript チャネル — CDP が利用できない場合の現実的な代替手段（Step 0 にあるとおり、デフォルトプロファイルでは通常 CDP は無視されるため、ポインターの差し替えだけでなく、具体例も示します）：

# 1. Fire the inventory/download
osascript scripts/runjs.applescript scripts/download_files.js <conversation-id>
# 2. Poll until the status line is no longer 'pending' (a few seconds)
echo "window.__dlStatus" > /tmp/check_dl.js
osascript scripts/runjs.applescript /tmp/check_dl.js <conversation-id>
# 3. Extract one file at a time (repeat for each name the status line listed)
echo "window.__dl['filename.png']" > /tmp/read_one.js
osascript scripts/runjs.applescript /tmp/read_one.js <conversation-id> \
  2>/dev/null | tr -d '\n' | base64 -d > filename.png

拡張機能チャネル：他の大きな戻り値と同様に、スクリプト本体を javascript_tool 経由で実行し、window.__dl を約16kのスライスでページ分割して取得してください。

各ファイルに対して file <name> を実行し、ファイル形式を確認してください（マジックバイトを確認します。PNG image data や Microsoft Excel 2007+ が想定され、ASCII text ではありません）。また、バイトサイズを会話 JSON のメタデータと照合してください（アップロードの場合は files[].size_bytes、成果物の場合は download_files.js のステータス行）。ダウンロードしたファイルはトランスクリプトの隣に保存してください。通常は兄弟ディレクトリの <transcript-basename>_附件/ に保存し、トランスクリプト内の画像参照先をローカルコピーに付け替えてください。

Step 5 — ページ分割（拡張機能チャネルのみ）

javascript_tool は大きな戻り値を切り詰めます。まず chars の数を取得してから、後続のウィンドウを返すよう再実行してください。取得処理は同一のまま、最後の式だけを変更します。

transcript.slice(14000, 32000);   // then (32000, 50000) … until you've covered `chars`

約14～18kのウィンドウを推奨します。それより大きいと、再び上限に達するおそれがあります。CDP と AppleScript のチャネルでは、これは不要です。 どちらもペイロード全体を stdout に返すため、大規模なアーカイブエクスポートではこれらのチャネルを優先する理由になります。

注意点

• sender の値は 'human' と 'assistant' です（'user'／'claude' ではありません）。
• メッセージには m.text と m.content[] の両方が含まれることがあります。 エージェントのターンでは、最終回答が m.text に含まれ、content[] に thinking／tool_use／tool_result ブロックが含まれることがよくあります。まず content[] から組み立てて、m.text を取り込んでください。m.text || (content…) のようにしてはいけません。m.text が設定されていると短絡評価され、すべてのブロックが失われます。メッセージが空白で表示されたら、次のように生データを確認してください。 Object.keys(msgs[0]) と msgs[0].content?.map(b => b.type)。
• /share/ のペイロードは /chat/ とは異なる形式です。 name は null です（タイトルは snapshot_name にあります）。web_search の結果は text 項目ではなく knowledge 項目（title／url／text）で、citations はテキストブロックに付属します。付属のレンダラーはこの3つすべてに対応していますが、手作業で作成したレンダラーは通常対応しておらず、これが落とし穴4です。
• ツールブロック内の空の input: {}／content: [] はバグではありません。 共有スナップショットでは、プラットフォームが共有者の非公開ファイルの内容を伏せています。その旨を伝えてください。不思議な何もしないブロックとして表示したり、データ損失として数えたりしないでください。
• rendering_mode=raw で本文が空または短い場合は、rendering_mode=messages で再試行してください。 この2つでは、公開されるフィールドがわずかに異なります。
• 会話のファイルもダウンロードできます — アップロードファイルと、ダウンロードカードにある成果物が対象です。エンドポイントは2種類あり、キーが異なります（画像は uuid、アップロードファイル／出力は conversations/<id>/wiggle/download-file を介したサンドボックスパス）。アップロードファイルに uuid を推測して使うと404になり、「未対応」に見えますが、実際にはそうではありません。scripts/download_files.js は会話を調べ、各ファイルを適切なエンドポイントからダウンロードします。試す前に利用不可と判断しないでください。
• tree=True は、編集や再生成で破棄された分岐も含め、ツリー全体を返します。 current_leaf_message_uuid から parent_message_uuid をたどってアクティブなパスを取得し、不要な分岐がトランスクリプトに混入したり、メッセージ数を水増ししたりしないようにしてください。レンダラーはこの処理を行い、これらのフィールドがない場合は配列順にフォールバックします（単一チェーンの会話と、すでに直線的な共有スナップショットではこれが正しい方法です）。
• 複数の組織がある場合： orgs[0] が正しいとは限りません。会話が404になった場合は、組織の一覧を取得し、orgs.map(o => ({uuid: o.uuid, name: o.name})) を確認して、アクセス不可と判断する前に、各組織について取得を試みてください。
• 読むだけにして、クリックしないでください。 このスキルで会話のUIを操作する必要はありません。取得中にナビゲーションやダイアログを起動しないようにしてください。
• デバッグポートを開くために、ユーザーのブラウザーを再起動してはいけません。 通常の理由（ユーザーのブラウザーであり、あなたのものではない）に加え、ここでは逆効果です。Chrome はデフォルト以外のプロファイルでのみポートを有効にしますが、新しいプロファイルではサインアウトされているため、起動したブラウザーからユーザーの会話を読むことはできません。必要なセッションを捨てて、不要なポートを得ることになります。ポートが利用できないのは回避すべき事実であり、変更すべき設定ではありません。

エンドポイント一覧、フィールドごとのレスポンススキーマ、完全なエクスポートスクリプト、トラブルシューティング表については、references/claude-web-api-extraction.md を参照してください。

次のステップ

トランスクリプトを書き出し、ファイルもダウンロードしたら、自然な次のステップを提案してください。ファイルがあったかどうかは、Step 4 の Completion check にある files: の stderr 行で確認できます。ファイル数が0でない場合、テキストのみのエクスポートは未完成のままです。提案はオプトインとし、自動では行わないでください。

Got the full conversation (<N> messages, "<title>", <retention>% fidelity);
<N> files downloaded to <dir>.

Options:
A) Clean it up — run transcript-fixer if it's ASR/garbled (only if relevant)
B) Summarize / extract the decisions and action items
C) Save it to a file — tell me where
D) Nothing else — you just needed it read