Claudeの使い方・活用術ガイド

ディスパッチ（Dispatch）は、スマホから指示を出すとその作業をあなたのPC上でClaudeが実行する機能だ（ベータ・Pro/Max）。クラウドで動くのではなく実機が動く点が、この機能の価値と危険の両方を生んでいる。公式ヘルプは「Dispatchを使えば、スマホからClaudeにメッセージを送り、デスクトップのコンピューター上で作業させられる」と説明し、Cowork ですでに設定済みのコネクタ・プラグイン・ファイルアクセスをそのまま使うとしている。動作にはPCが起きていてデスクトップアプリが開いていることが必要で、コンピュータ操作の対応はmacOSとWindowsのみ、Linuxにはない。仕組みは3段の優先順位で、コネクタが使えるならコネクタ、無ければブラウザ操作、最後の手段として画面の直接操作となる。安全性の評価はここから先だ。止まる場所は設計されている——コンピュータ操作は既定でオフ（設定→一般で有効化）、新しいアプリへのアクセスはアプリごとに毎回許可を求める、ファイルの完全削除には明示的な許可が要る、投資・取引プラットフォームと暗号資産のアプリは既定で対象外。一方で止まらない場所がある。許可済みアプリの中での個々の操作には確認が入らず、公式は「Claudeは画面を直接クリック・入力・遷移し、他のCoworkツールにかかる権限チェックを経ない」と明記している。さらに「コンピュータ操作にはClaudeと画面に映っているものとの間にサンドボックスが存在しない」「あるアプリで取った操作が別のアプリに影響しうる」ともある。最大のリスクはプロンプトインジェクションで、Anthropic自身が「操作された指示、予期しないコマンド、あるいはブラウザで開かれたフィッシングリンクが、取り消しが困難あるいは不可能な操作へと連鎖しうる」と書いている。対策としてモデル内部の活性を自動スキャンするとされるが、利用者側の線引きを不要にするものではない。公式は名指しで「機微なアプリ（銀行、医療、行政など）にコンピュータ操作の権限を与えないこと」とし、金融口座・法務文書・医療情報・個人データの取り扱いを避けるよう求めている。スマホ側のリスクも扱う——紛失時に漏れるのはスマホ内のデータではなく「PCに指示を出せる立場」と「続いている会話の中身」であり、被害の大きさはPC側で何を許しているかに比例する。ディスパッチの公式ヘルプには端末の解除や紛失時の手順が記載されていないため、対処はアカウント側の機能（アクティブなセッションの個別終了、全端末の一括ログアウト）とPC側の遮断（アプリを閉じる・スリープ）で行うことになる。一括ログアウトはモバイルアプリからは実行できずWebブラウザが要る点も押さえておきたい。本記事はこれらを一次情報から整理し、ディスパッチとコンピュータ操作が別のスイッチであること、Claude Codeのagent view（公式が同じくdispatchと呼ぶ別機能）との区別、そして取り返しのつく仕事から始めるという実務的な線引きまで扱う。

Claude Code の agent view（claude agents で開く）は、独立したバックグラウンドセッションを次々と起こし、1つの画面で管理するための機能だ。公式ドキュメントはその操作を「ディスパッチ（dispatch）」と呼ぶ——デスクトップアプリのサイドバーにある同名の別機能「ディスパッチ（Dispatch）」とは別物なので注意してほしい。公式ドキュメントは agent view を「1つの画面から多数のClaude Codeセッションをディスパッチし、管理する」機能と説明している（リサーチプレビュー・v2.1.139以降）。この記事は仕組みと安全性に絞る。まず驚くのは、入力欄に打ったプロンプトがそれぞれ自分自身の新しいセッションを開始するという点だ。2つ目を打っても1つ目への追記にはならず、隣に並ぶ。追加の指示はピークパネル（Space）から送る。安全性の中核はworktreeによる隔離にある。バックグラウンドセッションはファイルを編集する前に .claude/worktrees/ 配下の隔離されたworktreeへ移り、並列セッションは同じチェックアウトを読めるが書き込みはそれぞれ自分のものへ行う。読みは共有・書きは分離という設計だ。メインチェックアウトへ届く操作は3つのチェックで遮断される——ファイル編集（Edit/Write/NotebookEdit）、コマンドの作業ディレクトリ、そしてgitの向き先の付け替え（git -C、--git-dir、GIT_DIR、GIT_WORK_TREE、gitの前のcd）。検証できないコマンドは通さない安全側の判断になっており、この保護はセッションが生やすあらゆるサブエージェントにも継承される。ただしこれはOSの壁ではなく、リポジトリの外のファイルとネットワークは対象外で、PowerShellには作業ディレクトリのチェックしか適用されない。権限モードはその場で選ぶのではなく、そのディレクトリの設定のdefaultMode（サブエージェント指定時はそのフロントマターのpermissionMode）が引き継がれるため、普段緩めにしている人ほど無人の緩い権限が並列で生まれる。そして隔離の外へ漏れるものが3つある。「今後は確認しない」の承認はメインチェックアウトの.claude/settings.local.jsonに保存され全worktreeに効きworktreeを消しても残ること、agent viewでセッションを削除するとClaudeが作ったworktreeごと消えるため未コミットの作業が失われること、.worktreeincludeが秘密情報をworktreeの数だけ複製すること。さらにクォータは並列数に比例して減り（10個なら約10倍の速さ）、セッションはローカルで動くためマシンのシャットダウンで止まる。サブエージェント・エージェントチーム・動的ワークフローとの使い分け、安全に回すための手順（ディスパッチ前・実行中・終了後）も公式仕様にもとづいて整理する。

Claude Codeの/compactを「30分おき」「文脈が70%を超えたら」のような基準で押している人は多いが、公式ドキュメントが勧めているのは時計でも割合でもなく作業の区切りだ——「作業の自然な区切り、たとえばタスクとタスクの間で/compactを実行する。タスクの途中で自動コンパクトが走るのを待つのではなく」。この記事は2026年8月8日時点のClaude Code公式ドキュメント（最新版v2.1.226）を一次情報として、手動コンパクトの是非を仕様から詰める。まず前提として、コンパクトは3段構えで動く——①古いツール出力の切り捨て、②自動コンパクト、③手動の/compact。②と③は同じ処理であり、手動の役割は「タイミングを自分で選ぶこと」と「何を残すか指示できること」の2点しかない。回数を増やしても文脈が余分に節約されるわけではない。次に何が残るかを仕様表で示す：プロジェクト直下のCLAUDE.mdと自動メモリはディスクから再注入されるが、paths:付きルールとサブディレクトリのCLAUDE.mdは該当ファイルを再度読むまで失われ、呼び出したスキル本文は1スキル5,000トークン・合計25,000トークンの上限で古い順に捨てられる。費用については、コンパクトの価格は文脈の大きさではなくプロンプトキャッシュが温かいかどうかで決まる——作業中に押せば前置きはキャッシュから読まれて安く、キャッシュ寿命（サブスクは1時間、APIキーは既定5分）を超える休憩のあとは履歴全体を読み直すため最も高くつく。さらに/clear・/rewind・/recap・/contextとの使い分け、v2.1.221以降の/autocompactで自動発火位置を100K〜1Mトークンの範囲で動かす方法と4つの設定場所の優先順位、環境変数だけが素の整数しか受け付けない落とし穴、Not enough messages to compactとAutocompact is thrashingという2つのメッセージの意味と復旧手順まで扱う。

Claude Desktop（Windows）を開こうとすると「このアプリを開くことができません」と出て、「Claudeの詳細オプションに移動して、[修復] を選択する必要があります」と案内される——このとき案内どおり[修復]を押せば直る。アンインストールも、データを消すリセットも要らない。ただし実際に詰まる段差がひとつあり、それがこの記事の中心だ。[修復]を押すと「アプリが起動中のため実行できない」と弾かれることがある。アプリのウィンドウはどこにも開いていないのに、である。原因はClaude Desktopがウィンドウを閉じてもタスクトレイに常駐し続けることで、その常駐プロセスがパッケージのファイルを掴んだままだと修復が通らない。対処は単純で、プロセスを明示的に終了させてから[修復]を押す。そしてこの事実は不具合の原因そのものを示唆している——同じプロセスが更新を壊し、修復も妨げていたという筋書きだ。本記事はもう一つ、読者が最初に気にする点にも答える。セッションは消えるのか。答えは3種類に分かれる。claude.aiの会話履歴はAnthropicのサーバー側にあり影響を受けない。Claude Codeのセッションは%USERPROFILE%\.claude\projects\配下、すなわちアプリパッケージの外にあるため、修復でもリセットでもアンインストールでも残る（実機では2,977ファイル・約3.0GB・52プロジェクトを計測）。失われうるのは%APPDATA%\Claudeのアプリ側設定だけで、それも[修復]なら保持される——Windowsの画面自体が[修復]には「アプリのデータは影響を受けません」、[リセット]には「アプリのデータは削除されます」と表示している。さらに、状態確認のPowerShell、バックアップ手順、直らないときの段階的なエスカレーション（vmcompute/hnsの起動確認、-PreserveApplicationDataを付けた再インストール）、MSIXの「半登録」という推定原因とGitHub issue（#55465＝インストール成功だがエントリポイント欠落、#50285、#48437。いずれもclosed as not plannedで公式修正なし）、再発予防、そして旧インストーラ版との比較（MSIX配布の最新版と旧形式実機がともに1.24012.9で同一だった実測）まで扱う。

Claude Codeで応答の途中に「API Error: Connection closed mid-response. The response above may be incomplete.」と出て止まる——これはプロンプトの問題ではなく、応答のストリームを運んでいた接続が途中で閉じられた通信層の事象だ。本記事は公式のエラーリファレンス・公式CHANGELOG・パケットキャプチャ付きの実Issueだけを根拠に整理する。まず公式の定義（Connection closed＝切断、Response stalled＝無音、Server error＝サーバ側の失敗という3種の違い）と、途中まで流れた出力が「あえて」保持される理由——送り直すと同じツール呼び出しを二重に実行しうるため——そして復帰手順がcontinueと返すことである点。次に切断が起きうる3つの層（手元の回線・スリープ／プロキシやVPNのアイドル切断／サーバ起点の切断）と、Issue #67766の報告者が公開したパケットキャプチャの実測値（10件すべてがサーバ側からの正常終了、FINからエラー表示まで3〜105ms、切断時点で7〜20KB受信済み、リクエスト本体1〜2.5MB、張り直した接続は約20msで成功、23日で200エラー171件、うち87件は直前の通信から5秒未満）。さらに本記事の実利の中心として、公式CHANGELOGに実在する接続まわりの修正の時系列（2.1.179＝途中応答の保持、2.1.185＝停滞警告を10秒から20秒へ、2.1.198＝一時的なネットワーク断をバックオフでリトライ、2.1.199＝ストリーム中のサーバエラーでも途中出力を保持、2.1.214＝古い接続のエラー後はキープアライブのプールを無効化）を、報告されたバージョン（#69336＝2.1.173／#69415＝2.1.181／#69517＝2.1.183）と突き合わせ、報告の集中帯がいずれも2.1.198より前であることを示す。加えて起きやすい条件、8手のユーザー向けチェックリスト、開発者向けの6指針（長い応答は必ずストリーミング、TCPキープアライブ、公式SDKの既定2回リトライ、200のあとに来るSSEエラーの別扱い、受信済みを捨てない、接続プールを疑う）、Unable to connectやPrompt is too longとの見分け方、そして「症状と対処は公式に文書化されているが原因の公式説明はまだ無い」という確度の切り分けまでを扱う。

2026年7月24日、AnthropicがClaude Opus 5を公開。Anthropic自身が「Opus 4.8からの段階的改善ではなくstep-change」と表現する世代交代だが、料金は入力$5/出力$25で据え置き＝最上位Fable 5（$10/$50）のちょうど半額に据わった。本記事では公式発表・公式ドキュメントと複数報道を突き合わせ、基本スペック（claude-opus-5・1Mトークンが既定かつ最大・最大出力12.8万・知識カットオフ2026年5月）、料金とキャッシュ単価・fast mode（2.5倍速で単価2倍、API限定）、ベンチマーク（公式明言のFrontier-Bench「Opus 4.8の2倍超」・CursorBench 3.2でFable 5と0.5%以内・ARC-AGI 3で次点の3倍・OSWorld 2.0をFable 5の約1/3コストで超える、報道ベースの実数値としてFrontier-Bench 43.3%／ARC-AGI-3 30.2%／GDPval-AA 1,861／OSWorld 70.6%）、そして勝てていない領域（DeepSWE v1.1でGPT-5.6 Solに68.8%対72.7%と劣後、サイバー攻撃側と長時間の生物研究はMythos 5が上、max effortが最良とは限らない）を整理。さらにAPIの破壊的変更2件（思考が既定ONでmax_tokensの見直しが必要／思考OFFはeffort high以下でのみ許可、xhigh・maxとの併用は400エラー）、effort5段階の使い分け、会話途中のツール変更ベータ・キャッシュ最小長512トークン・fallback既定モードといった新機能、冗長化・実況増加・委譲増・自己検証という「性格」の変化に対する“プロンプトは足さず削る”移行のコツ、そして誰が今すぐ移行すべきかと6ステップの移行手順まで実務目線でまとめる。

ローカルLLMを動かそうとHugging Faceを開くと、同じモデルにQ4_K_M・Q5_K_S・GPTQ・AWQ・IQ3_Mと大量のファイルが並び固まる——その壁を「どの量子化ファイルをダウンロードすれば動くのか」の実践目線で解く。量子化とは何かの概念は別記事に譲り、フォーマットの選び方に絞る。選択は2段階=①どのフォーマットか（＝どのエンジンで動かすか）②その中でどのビット数か。最重要の事実は、量子化ファイルは対応エンジンでしか動かないこと。GGUFだけがCPU・Mac・GPU一部載せに対応した唯一のローカル万能形式でllama.cpp/Ollama向け、GPTQ/AWQ/EXL2は基本GPU前提（vLLM/TGI等）、bitsandbytesはTransformersで即時量子化・キャリブレーション不要。GGUFの命名Q4_K_Mは3部構成=Q4（4bitの目安・数字が大きいほど高品質大サイズ）・K（K-quant＝超ブロック単位で賢く量子化。無印/_0/_1は旧方式）・M（S/M/L＝一部の重要テンソルを高ビットに格上げする度合い。実効ビットは表記より多くQ4_K≈4.5bpw）。IQ系（I-quant）は同ビットでもさらに小さいが推論が重くimatrixがほぼ必須。imatrixはキャリブレーションで効く重みを測り低ビットを保護する仕組み。GPTQは層ごと誤差最小化、AWQは活性化を見て重要な1%の重みを保護（どちらが常に上とは言えない）。ビット数は迷ったらQ4_K_M（Ollamaの多くの既定）、余裕あればQ5_K_M/Q6_K、Q8_0はほぼ無損失だが非推奨、大モデルを詰め込むときだけIQ2/IQ3。約4.5〜5bpwが“おいしい帯”という経験則。HuggingFaceはlibrary=gguf/bartowski・mradermacher（配布者の活動は要確認）、Ollamaはタグmodel:size-variant-quant。数値は目安でモデル・ビルドにより変わる。127「量子化とは」と住み分け。

「とりあえずAIに聞く」「全部AIに書かせる」が当たり前の今こそ、「これは本当にAIを使うべき場面か？」という逆の問いが効く。本記事は反AIの主張ではなく、AIを最大限に活かすために「使わない」を選択肢として持つという話。AIはデフォルトで使うものではなく意図的に選ぶ道具であり、使いこなす力とあえて使わない力はセット。あえて使わない方がいいのは6場面=①基礎を習得中の学習（書いて考える過程自体が目的）②機密・個人情報の入力（規約・保存方針未確認なら出さない）③誤れば致命的な最終判断（医療・法務・安全・金銭は検証なしで委ねない）④コスト・手間が見合わない軽作業⑤人間の信頼・創造が価値の核（謝罪・採用・作家性）⑥単一障害点を増やしたくない時（事業継続）。使う/使わないは3問で素早く判断=①出力を自分で検証できるか②入れてよい情報だけか③その過程は今鍛えるべきものか。検証でき・出してよい情報で・鍛える必要がないならAI。使いすぎの弊害（認知のアウトソース、もっともらしい誤りの放置、依存）は数値断定を避け論点として提示。あえて使わない判断はブレーキではなく、使う場面で全力を出すための裏側のスキルであり、AIに依存しすぎないリスク管理でもある。

Claude Desktop（Windows・Microsoft Store/MSIX版）を更新した直後にアプリを開こうとすると、「このファイルはほかのプログラムで使われています」というダイアログが出て起動できず、PCを再起動するまで直らない——という既知の不具合の解説。結論から言うと、PCの完全再起動は必ずしも必要なく、「ログオフ→ログイン」で復旧できる場合が多い（GitHub #53247）。一方、ネット上でよく見る「サービスを止めれば直る」（Stop-Service CoworkVMService 等）は、この不具合では効かないと報告されている。エラーの正体はイベントログ（AppModel-Runtime 215/208、0x80070020＝ERROR_SHARING_VIOLATION）で、失敗しているのはアプリ起動時のDesktop AppXコンテナ生成（Job→Silo変換）。handle.exe/Process Explorerの検証でユーザー空間のファイルロックが無いことも確認済みで、ダイアログの文言は実態を表していない。引き金はCoworkVMServiceの自動起動がJob Objectを占有する説（#57221）と、起動時クラッシュで孤立ハンドルが残る説（#53247）の2つがあり未決着。恒久策はMSIX版をやめてSquirrel版に乗り換えること。本記事はWindows 11 Home実機1台の調査ログとGitHub issueの突き合わせに基づき、確定・推定・未確定をラベルで区別して整理する。

Claude Codeで長時間作業していると、応答が突然「court court court…」と同じ単語を何十〜数百回も繰り返し、最後に「API Error: Response stalled mid-stream. The response above may be incomplete.」で止まる——この現象は、あなたのプロンプトのミスではなく、2つの別々の既知不具合が連鎖して起きている。①モデルが同じトークンを吐き続ける反復（デジェネレーション、GitHub #68740/#65823/#66950）と、②大量出力や接続の問題で応答ストリームが止まる「Response stalled mid-stream」（#70840・公式エラーリファレンス）だ。courtに意味はなく、モデルがたまたまそのトークンに固着しているだけで、area:modelラベルの付いたモデル側の不具合である。本記事では、この2層の正体、「court/invokeタグ漏れ」型（別記事）との違い、誘発条件（長時間・大コンテキスト・ツール呼び出し直前の文章生成・不安定な接続・長文出力）、今すぐの止め方（Escで中断→新セッション/clearへ逃げる・前置きなしでツール呼び出し・タスク分割）、開発者向け対処（読み取りタイムアウト・反復検出ガード・壊れた履歴を残さないリトライ・max_tokens上限）、Connection closed mid-responseやPrompt is too long等との見分け、2026年7月時点で恒久修正が未確認である対応状況までを、公式ドキュメントと実Issueに基づいて整理する。

OpenAIの最上位GPT-5.6 Sol（7月9日）と、Anthropicが「一般提供する中で史上最強」と位置づけるClaude Fable 5（6月9日）を徹底比較する。Opus 4.8戦が同価格帯の直接対決だったのに対し、こちらは「半額の万能型Sol（$5/$30）」対「2倍高いが最上位のFable 5（$10/$50）」というコストと実力のトレードオフが主題だ。実プロダクション級コーディングのSWE-Bench ProではFable 5が80.3%とSolの64.6%（推定）を15pt以上引き離し、その差はOpus 4.8戦より拡大。さらにFable 5は数百万トークンに集中して最大12時間連続で自走し、Stripeが5000万行のRuby移行を1日で完了させた「完走力」が本領だ。一方Solは端末操作のTerminalBench 2.1（88.8% vs Fable 86.0%）・Agents' Last Exam（53.6 vs 40.5）・Coding Agent Index（80 vs 77.2）で首位、しかも半額＋トークン効率+54%でコスパが強い。本記事ではスペック早見表、ベンチ詳細、OpenAIがSolのSWE-bench Proを非公表な「非公開ベンチ問題」、長時間自律、実コスト（タスク完了あたりで見る）、強み弱みマップ、ユースケース別の選び方までを公式・独立ベンチベースで整理する。

2026年のAIコーディング2強、Claude Opus 4.8（5月28日）とGPT-5.6の最上位Sol（7月9日）を徹底比較する。得意領域はほぼ反対で、SolはTerminalBench 2.1（88.8% vs Opus 78.9%）・Agents' Last Exam 53.6・Coding Agent Index 80と端末操作/エージェント総合力で首位。対するOpus 4.8はSWE-bench Pro（69.2% vs Sol 64.6%）・USAMO 2026（96.7%）・GraphWalks 1M（68.1%）と実プロダクション級コーディング/数学/長文脈で首位、さらに「過信10分の1・欠陥結果の無批判報告0%」の誠実性を打ち出す。加えてOpenAIはSolのSWE-bench Proや汎用推論ベンチ（GPQA/AIME/MMLU等）を多く非公表——実コーディングの本丸では開示済みのOpusが優位という構図だ。本記事ではスペック早見表、ベンチ詳細、非公開ベンチ問題、実コスト（単価$25 vs $30とトークン効率+54%の綱引き）、強み弱みマップ、ユースケース別の選び方、デュアル運用戦略までを公式・独立ベンチベースで整理する。