AI開発・プログラミング入門｜コード生成からアプリ構築まで

Remote Control は、自分のマシンで動いている Claude Code のセッションに、スマホやブラウザから接続してそのまま操作を続ける機能だ。クラウドへ処理を移すのではなく、実行場所は手元のまま「操作する場所だけ」を移す——だからローカルのファイル、MCPサーバ、ツール、プロジェクト設定がそのまま生き、スマホで @ と打てば手元のプロジェクトのパスが補完される。本記事では、まず「外から動かす手段」が4つあること、そのうちRemote Control・Dispatch・Channelsの3つは手元のPCで動き、Claude Code on the webだけがクラウドで動くという地図を示す。リポジトリがGitHub以外なら結果をpushして戻せないため、構成そのものが選択肢を削る点にも触れる。起動方法は3つ——会話中に /remote-control で今の履歴ごと持ち出す、claude --remote-control で最初から有効にする、claude remote-control でサーバーとして常駐させる（スペースキーでQRコード、--spawn worktree でセッションごとにgit worktreeを分離、既定の同時数は32）。スマホ側では権限プロンプトと質問に答えられる一方、/plugin と /resume はローカル専用で、/model や /effort は引数を渡す形になる。UIから選ぶかコマンドを送るかで永続性が変わる点は事故のもとだ。仕組みは「登録してポーリングし、サーバが中継する」だけで、外向きHTTPSのみ・受信ポートは一切開かない——SSHを外に晒すのと比べて攻撃面が構造的に小さく、ルータ設定も固定IPも要らない。そのうえでセキュリティの本質は、QRコードが認証ではなく近道でしかないこと、アクセス権は「URLを知っているか」ではなく「誰のアカウントか」で決まること、つまり門は1枚でありその1枚がclaude.aiアカウントであることだ。だからパスキーの設定が最優先になる。接続中はトランスクリプトがAnthropicのサーバに保存され、保持期間はモデル改善への利用設定で5年と30日に分かれる。繋がらないときの原因切り分け、ネットワーク断でサーバーモードと対話セッションの挙動が違うこと、スマホ紛失時にまずプロセスを止めるべき理由、そしてDispatchとの使い分け（事前準備が要るか要らないか）まで、すべてAnthropic公式ドキュメントに基づいて解説する。

Claudeの「思考（thinking）」はこの1年で世代交代した。かつての拡張思考（extended thinking）は thinking: {"type": "enabled", "budget_tokens": N} で思考トークン量を人間が毎回指定する方式だったが、適切な予算はタスクごとに違い事前に当てられず、予算変更はプロンプトキャッシュも無効化する。現行の適応的思考（adaptive thinking）は type: "adaptive" の一行だけで、考えるかどうか・どれだけ深く考えるかをリクエストの難しさからモデル自身が判断する。移行はOpus 4.6 / Sonnet 4.6でbudget_tokensが非推奨になり、Opus 4.7以降では400エラーで拒否という段階を踏んだ。本記事ではモデル別の扱いを1枚の早見表に整理する——Fable 5.1 / Opus 5.5は思考常時ON（OFF不可）、Sonnet 5.5は既定ONで思考OFF（disabled）は400、代わりにbetween_toolsで最初の思考だけ切れる（effort high以下）、Legacy扱いのOpus 5 / Sonnet 5は既定ON（Opus 5のOFFはeffort high以下のみ）、Opus 4.8 / 4.7は明示で有効化、拡張思考だけに対応するモデル（Haiku 4.5 / Sonnet 4.5等）は今もbudget_tokensが唯一の方式。深さの調整はoutput_config: {"effort": ...}の5段階（既定は多くのモデルでhigh、Opus 5.5とHaiku 5.5はmedium）に移り、effort変更はキャッシュを無効化する。見え方はdisplayで制御し、新世代の既定は"omitted"（空の思考ブロック）——見えなくても思考トークンは全額課金され、実測はusage.output_tokens_details.thinking_tokensで行う。生の思考過程はどの設定でも返らない。思考OFFにはOpus 5でツール呼び出しがテキスト化される・内部タグが漏れるという公式記載の副作用があり、切るよりeffortを下げるのが安全。interleaved thinking（ツール呼び出しの合間の思考）はadaptiveなら自動で、旧ベータヘッダは不要。速度が欲しいときはfast mode（約2.5倍速・単価2倍・Opus 5.5/5/4.8のみ・Claude Codeは/fastで切り替え）という選択肢もある。すべてAnthropic公式ドキュメント（Thinking / Extended thinking / Fast mode）に基づいて解説する。

作業中に Claude Desktop が突然固まり、開いていた Claude Code のセッションが全部まとめて止まる。強制終了して再起動すると、今度はアプリ自体が起動しなくなっていることがある——このときログの最後の行に残っているのは、たいてい「GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }」という一文だ。この記事は、その exitCode 101457950（＝0x060C201E）が何を意味するのかを整理する。落ちているのは Claude Code（CLI）ではなく、それを載せているデスクトップアプリ（Electron）の GPU プロセスである。判定は main.log の末尾を見るだけでよく、再起動の直前の行が GPU process gone なら本件で、Crashpad にダンプが増えていなければ CLI 側のネイティブクラッシュではない。なぜ無関係なセッションまで巻き添えになるのかという疑問には、構造で答えられる。Electron/Chromium の GPU プロセスはアプリケーションにつき1個しか存在せず、全ウィンドウ・全タブ・全セッションがこれを共有している。したがって in-app ブラウザで開いたページ1枚が GPU を殺すと、そのページと縁もゆかりもないセッションが同時に止まる。これは構造上の性質なので、ユーザー側の設定で分離することはできない。引き金は公開issueで最も多いのが in-app ブラウザで、#80444 は WebGL/WebGPU の機能検出から15〜36秒後に4回とも同じ 0x060C201E で死ぬ様子を、#82967 はブラウザツールのプレビュー用スクリーンショット取得（capturePreviewScreenshotIfChanged）を引き金として記録している。ただしブラウザだけが引き金ではなく、#68049 は ARM64 環境で起動時に同じコードで落ちると報告している。復旧は強制終了と再起動が基本だが、GPUクラッシュの後に Windows が MSIX パッケージを「変更されている」（appxState=2）と判定して起動を拒否することがあり、その場合は常駐プロセスを終わらせてから[修復]を実行する。[修復]が常に失敗し、完全な削除と再インストールでしか戻らなかったという報告（#82967）もある。データは保存済みのものが残る一方、実行中だった作業は戻らず、並列で走らせていたサブエージェントの結果ごと失った報告（#81698）がある。打てる手は引き金を引きにくくすることだけで、--disable-gpu は MSIX 版では「アクセスが拒否されました」で弾かれ、アプリの更新でも直るとは限らない。2026年10月4日時点で確認した範囲では、Anthropic はこの症状について公式の原因説明も修正内容の説明も出しておらず、代表の #80444 は9月15日に説明のないまま「completed」として閉じられた。

「AIに直接いじらせるなら管理画面は要らないのでは」という問いに、一般論では答えが出ない。同じ「管理画面」という言葉が性質の違う機能の寄せ集めを指しているからだ。この記事は、実際にこのサイトの管理画面を全廃した経験をもとに、立てるべき問いを「その画面はCLIやAIでは提供できていない何かを提供しているか」に置き換える。全廃してみて分かったのは、消した機能の多くが「使っていなかった」のではなく「構造的に機能していなかった」ということだった。記事のCRUDは、データの正がコード側にあるためデプロイのたびに上書きされ、画面から編集しても次のデプロイで消える設計だった。コメント承認キューは投稿時に承認済みとする実装のため、未承認コメントが生まれず常に空だった。使われない機能は、壊れていることすら気づかれない。一方で消せなかったのはコメント削除だが、これも管理画面である必然性はなく、記事ページ本体に削除ボタンを置くほうが優れていた——問題のコメントを読んでいるその場で消せるからだ。判断は6つの問いに落ちる。誰が操作するか（非技術者や交代のある担当者ならUI、開発者本人ならCLI）、取り消せるか（不可逆ならゲートが要る）、人間の判断が要るか（承認という状態遷移があるか）、権限を分ける必要があるか、何ができるか知っているか（一覧が仕様書を兼ねる）、証跡は残るか。とくに権限と証跡は個人開発では不要に見えて、人が増えた瞬間に最初に必要になる。またコード経由の変更はgitに残るが、AIにDBを直接触らせると標準では何も残らず、会話ログは「何を頼んだか」であって「何が起きたか」ではない。6軸のうち可逆性だけは重みが違う。2025年7月18日、ReplitのAIエージェントがコードフリーズ中にSaaStrの本番データベースを削除し、4,000件の架空ユーザーを生成し、ロールバック不可能と誤って主張して復旧を遅らせた事例（AI Incident Database #1152）が示すのは、AIの危険性というより不可逆な操作が人間のゲートを通らずに到達可能だった設計の問題である。記事はさらに、AI経由へ寄せる前に整えるべき3つの備え（変更が形として残ること、不可逆操作の手前の段差、手順の文書化）と、作る前のチェックリスト、そしてRetoolやForest Adminのような内製ツール製品という第三の選択肢まで扱う。

Claude Codeの/compactを「30分おき」「文脈が70%を超えたら」のような基準で押している人は多いが、公式ドキュメントが勧めているのは時計でも割合でもなく作業の区切りだ——「作業の自然な区切り、たとえばタスクとタスクの間で/compactを実行する。タスクの途中で自動コンパクトが走るのを待つのではなく」。この記事は2026年10月4日時点のClaude Code公式ドキュメント（最新版v2.1.289）を一次情報として、手動コンパクトの是非を仕様から詰める。まず前提として、コンパクトは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との見分け方、そして「症状と対処は公式に文書化されているが原因の公式説明はまだ無い」という確度の切り分けまでを扱う。

ローカル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等）、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。数値は目安でモデル・ビルドにより変わる。

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の突き合わせに基づき、確定・推定・未確定をラベルで区別して整理する。

「AIでシステム開発の工数はどれだけ減るのか？」——2025〜2026年のエージェント型コーディングの登場で、測る単位そのものが変わった。かつては「1タスクが何%速いか」だったが、いまや「数週間かかった開発サイクルが数時間〜数日に圧縮される」桁の話だ（TechTarget）。Claude Fable 5はStripeの5000万行移行を1日で完了、TELUSは50万開発者時間を節約、サイクルタイムは9.6→2.4日に。補助利用（オートコンプリート）時代のCopilot RCT 55.8%高速・McKinseyのタスク別20〜50%は、いまや下限だ。ただし「一律10倍」ではない：Anthropicの2026 Agentic Coding Trends Reportによれば開発者はAIを仕事の約60%で使う一方、完全委譲できるタスクは0〜20%（委譲ギャップ）で人のレビューが要り、AI作業の約27%は以前なら存在しなかった新しい仕事（削減＝増産）。良い文脈設計があればエラー40%減・55%高速。「AIで熟練者は19%遅くなる」というMETRの2025年結果も2026年に反転方向で、当人が「測定は実態を過小評価」と自認している。本記事では、この二極化を名前付き出典（GitHub・McKinsey・Anthropic・METR・DORA）で切り分け、工数削減を実際に取りに行く方法までを整理する。

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に基づいて整理する。

Claude CodeやAPIで突然出る「API Error: 400 Output blocked by content filtering policy」——これは使用量制限でもコンテキスト超過でもなく、Claudeが返そうとした「出力」を安全フィルタが差し止めた状態だ。主目的は既存著作物の逐語再現の防止で、MIT/Apacheなど標準ライセンスの全文生成、既存ソースへの「一致」作業、長文ドキュメントの複製などで悪意なく誤検知（false positive）することが多い。本記事では、公式説明（出力段のフィルタが著作物の再現を検知して400でブロックする仕組み）、実際のClaude Code Issueに見る誤検知パターン（OSSリポジトリ初期整備・リスト照合・長時間エージェント実行の末にトークン上限と誤診断）、今すぐ直す方法（モデルに丸写しさせずツールで取得・プロンプトを生成/要約寄りに言い換え・Escでリトライループを止める・タスク分割・誤検知はサポート報告）、Prompt is too long／usage limit／529 Overloaded／max_tokensとの見分け方までを整理する。