AI時代の開発環境・インフラ構築ガイド【初心者向け2026年版】

Claude Codeの「プロジェクト」が作り直されました。これまでのプロジェクトは会話と資料をまとめておくフォルダでしたが、新しいプロジェクトは1本の会話です。あなたが用件を書くと、Claudeがそれをスレッドに切り分け、スレッドはクラウドで並列に走り、終わるとプルリクエストを置いて報告してきます。パソコンを閉じても止まりません。ただし飛びつく前に確かめることが3つあります。使えるアカウントがまだ限られていること（Pro・Max限定の公開ベータで、既存プロジェクトを持たないアカウントから配布）、github.comとClaude GitHub Appが事実上の必須条件であること、そしてトークンの減り方が単発のセッションとは比べものにならないことです。この記事では、配布条件の見分け方、スレッドが最初から持っている前提（リポジトリが複数になると権限ルールとフックが効かなくなる落とし穴を含む）、既定がOpusのhighであることを含むトークン消費の内訳、そしてサブエージェント・agent view・エージェントチーム・動的ワークフローを含む5つの並列手段の使い分けまでを、公式ドキュメントと公式ブログから整理します。

計画を立てるところだけ賢いモデルに任せ、実装は速くて安いモデルに回したい。Claude Code の opusplan は、それを自動でやるモデルの指定です。プランモードの間は Opus、それ以外は Sonnet で動き、/model opusplan か settings.json の model で使えます。ただし /model の一覧には出てこず、プランモードに入るたび・出るたびにモデルが切り替わるので、そのたびに会話全体をキャッシュなしで読み直します。この記事では、2026年9月15日時点の公式ドキュメント、変更履歴、GitHub の issue をもとに、設定のしかた（版の固定や 1M 文脈を含む）、プランモードから承認して実装に移る流れ、v2.0.0 で選択画面から外された経緯と Anthropic の担当者の説明、切り替えで生じるキャッシュの費用の試算とその抑え方、advisor ツールやサブエージェントとの違い、向いている使い方と向いていない使い方をまとめます。

Claude Code の本体は Opus 5 のまま、翻訳や大量の確認のような仕事だけを Sonnet や Haiku のサブエージェントに任せられるのか。結論はできます。サブエージェントのモデルは、呼び出すときの指定、定義ファイルの model、環境変数 CLAUDE_CODE_SUBAGENT_MODEL、本体のモデルの順に決まり、工数（effort）もサブエージェントごとに指定できます。この記事では、2026年9月15日時点の公式ドキュメントから、順番の版ごとの違い、全部を1つのモデルに固定する CLAUDE_CODE_SUBAGENT_MODEL_FORCE、接続先で変わるエイリアスの行き先、組み込みの Explore が v2.1.198 から本体のモデルを引き継ぐようになった点を整理します。そのうえで、実際に別のモデルで起動して会話ログで確かめた結果を載せます。指定どおりのモデルで動いたこと、起動するだけで数万トークンを読み込み、サブスクリプションでもサブエージェントのキャッシュは5分で切れること、そして同じ翻訳を Opus 5・Sonnet 5・Haiku 4.5 に2回ずつ任せたときの時間・料金・訳の出来の違いです。最後に、料金と使用量への効き方と、どの仕事を下げるかの判断材料をまとめます。

複数のセッションを並行して走らせていると、どれが週の上限を食っているのかが気になります。ところが Claude Code の /usage が出すのは、今のセッションの数字と、プラン全体の消費をスキル・サブエージェント・プラグイン・MCPサーバー別に分けた割合までで、「どのセッションが何割使ったか」は、デスクトップアプリの使用量リングにも claude.ai の設定画面にも出ません（2026年9月時点）。答えは手元に残っている会話ログ（~/.claude/projects の JSONL）にありますが、そのまま足すと数え間違えます。1回の応答が中身のかたまりごとに複数行へ書かれ、サブエージェントの記録は別のファイルにあるからです。筆者の環境で実測すると、素朴な合計は正しい値の約2倍になり、しかも誤差の倍率がセッションごとに違うため順位まで入れ替わりました。この記事では、公式の画面で見られるもの・見られないものの整理、ログの正しい数え方と約50行の集計スクリプト、1つのセッションが3割を占めていた実測結果、数字の読み方の限界、そして継続的に見たい場合の OpenTelemetry の設定までをまとめます。

日本語で頼んだのに、Claude が英語で返してくる——公式リポジトリには同じ報告が繰り返し上がっており、研究でも、依頼と返答で言語をまたぐ条件では最も強いモデルでも指定した言語で一貫して返せないことがわかっています。ただし原因は1つではありません。コードやツール出力を読むうちにじわじわ英語へ流れる型、会話を要約するコンパクトの直後に言語を忘れる型、英語ではなく別の言語に化ける型の3つに分かれ、効く対策もそれぞれ違います。この記事では、各型の見分け方と、システムプロンプトに指示を固定する Claude Code の language 設定がなぜコンパクト後も効き続けるのか、そして2026年9月に報告が出始めた「長いセッションで出力そのものが崩れる」問題を、確かな情報と未確認の情報を分けて整理します。

「スキルを入れすぎるとコンテキストを圧迫する」——半分は正しく、半分は間違いです。Claude Code の公式ドキュメントによれば、スキル一覧が使うのはモデルの文脈窓の1%という決まった予算で、いくらスキルを増やしてもそこで頭打ちになります。膨らまないかわりに起きるのは「呼ばれなくなる」こと——予算からあふれると、Claude Code は呼び出し回数の少ないスキルから説明文を落とし、名前だけを残します。説明を失ったスキルは依頼と結び付かなくなりますが、エラーは出ず、遅くもなりません。この記事では、3つの計測手段（/context・/usage・/skill-doctor）の役割の違い、キャッシュミスが「5%かつ2,000トークン」で定義されること、キャッシュの寿命が契約形態で1時間から5分へ変わること、MCPのツール定義が既定で遅延読み込みになった今もCLIのほうが軽い理由、CLAUDE.mdを200行以下に保つ根拠、そして測ったあとに何から削るかを、すべて公式ドキュメントで確認できた範囲だけで整理します。

Claudeを使っていて手が止まり、出た文言をそのまま検索しても何も出てこない——そういう文字列がある。The model returned no content because the response was blocked by content filtering／The response was blocked by the provider's content filter／Streaming response ended before any complete data was received／Could not locate the Claude CLI on PATH／Connection to Claude's response was lost. Claude may still be working の5つがその例だ。共通しているのは「Claudeを使っていて出たのに、Claudeの資料を探しても見つからない（ように見える）」点で、理由は単純——いま画面に出ている文言を書いたのが、思っているプログラムとは限らないからである。本記事は個別の原因を一から解説するのではなく、その文言を書いたのは誰かを特定し、正しい記事へ振り分けるための入口として書いた。まず文言を書きうる層を4つに分ける（モデル提供元のバックエンド／Claude Code本体／起動元のIDE拡張やラッパー／第三者クライアント）。そのうえで実際に照合すると、5つのうち2つはClaude Code公式のエラーリファレンスに項目として存在していた。Streaming response ended… の公式の定義は「ヘッダは返ったがボディにClaude APIのメッセージが無い」であり、途中で切れた話ではない。Could not locate the Claude CLI on PATH は公式が「Wrapper and IDE errors＝起動元のプログラムが印字するもの」として独立の章に置いている。一方でcontent filter系の2つは第三者側の語彙で、しかもOpenCodeのIssue #35736は、Vertexの404・ソケット断・本物の拒否という3つの別々の失敗がすべて同一の「blocked by content filter」として表示されると報告している。文言が正しいのは3つのうち1つだけだ。GitHubの公式ドキュメントもClaude利用時に入出力がGitHub Copilotのコンテンツフィルタを通ると明記しており、Claudeを使っていても止めたのがAnthropicのフィルタとは限らない。残る1つは公式にもRemote Controlのドキュメントにも文字列が無く、出どころを特定できなかったので名前を挙げず、自分で突き止める4手を置いた。確定・未確定はラベルで分けてある。

Claude Fable 5.1 の移行は、モデルIDを差し替えて終わりではない。公式が「3つは破壊的変更」と明記しており、しかもそのうち2つはエラーが出る場所と原因が離れている。①強制ツール呼び出しが400になる——tool_choice の any と tool が invalid_request_error を返す。思考が常時ONのモデルで強制すると思考が飛ばされ、引数の質が落ちるためだ。②思考ブロックがモデルに紐づく——前世代からFable 5.1へ移る会話は推論を保てるが、逆向きは失われる。しかも既定では読めないブロックがモデルに届く前に破棄され、input_tokens に数えられず課金にも出ない。ルーターやフォールバックでモデルを切り替える作りでは、動いているように見えて推論だけが抜け落ちる。気づくには thinking-binding-controls-2026-08-01 ベータヘッダが要る。③過去のターンを編集すると、それ以降の思考ブロックが無効になる。system プロンプトや tools の作り直し、リマインダーを差し込んで消す書き方が該当する。この検査は2026年8月31日以降に作成されたアカウントで強制されるため、新しい検証環境では落ちるのに本番では落ちない、という食い違いが起きうる。位置づけの誤解も避けたい——Fable 5.1 はフラグシップの交代ではなく、公式は「ほとんどの用途はOpus 5から」と明記している。値上げはなく、変わったのはキャッシュ読み取りだけで、基本入力の0.1倍から0.025倍へ下がった。効果は同じ前置きを何度読み直すかで決まり、公式は典型的な負荷で約25%減、エージェント色の強い作業で最大約45%減としている。さらにコードを変えなくても挙動が7つ変わる（並列ツール呼び出しが減る、進捗の発話が減る、low effortで記憶から答えがち、散文が密になる、整形が減る、要約で引用を明示しない、小さな修正でも全文を書き直す）。追加機能5つ（うちキャッシュ値下げは第5章で独立して扱う）と移行手順5点まで、すべてAnthropic公式ドキュメントに基づいて整理する。

自分のPCで動かすモデルにコードを書かせる——それ自体は前からできたが、できたのは「書きかけの行の続きを埋める」補完までだった。リポジトリを読んで複数ファイルを直しテストを走らせるエージェント型は、ローカルには重すぎた。そこが2025年末から2026年にかけて動いた。Qwenの公式モデルカードには「Qwen CodeやCLINEといったほとんどのプラットフォームをサポートし、専用に設計されたfunction call形式を備える」とエディタ拡張が名指しで書かれ、Mistralも2025年12月9日にエージェント型コーディング専用のDevstral 2を発表、小さいDevstral Small 2（24B）をApache 2.0で公開した。本記事は一次情報だけで「いまどこまでできて、どこで詰まるか」を整理する。最大の関門はOllamaの既定コンテキスト長で、これは固定値ではなくVRAM量で決まる——24GiB未満なら4k、24〜48GiBで32k、48GiB以上で256k。一般的なゲーミングPCは4kに落ち、エージェントはシステムプロンプトとファイル内容とツール往復で軽く超えるため、会話の頭から静かに切り落とされる。エラーは出ないので「モデルが馬鹿」に見えるが、原因は入り口で文脈が捨てられていることだ。Ollama公式はコーディングツール用途に「少なくとも64000トークン」を明記し、伸ばした後はollama psでGPUに載っているか確認せよと案内している。モデル選定は公式発表のみで比較する——Qwen3.6-35B-A3B（活性3B・262,144コンテキスト・Apache 2.0・SWE-bench Verified 73.4）とDevstral Small 2（24B・256K・Apache 2.0・68.0%）。ContinueとClineの設計差（役割ごとに別モデルを割り当てる補完型と、自律エージェント）、そして「クラウドの何％」という比較がもはや成立しない理由——AnthropicのOpus 5発表にはSWE-bench Verifiedの数値が無く、フロンティア側はこの指標から離れつつある——まで扱う。

作業中に 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 版では「アクセスが拒否されました」で弾かれ、アプリの更新でも直るとは限らない。Anthropic はこの症状について公式の原因説明も修正告知も出していない。

「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 の 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倍の速さ）、セッションはローカルで動くためマシンのシャットダウンで止まる。サブエージェント・エージェントチーム・動的ワークフローとの使い分け、安全に回すための手順（ディスパッチ前・実行中・終了後）も公式仕様にもとづいて整理する。