こんにちは。よっしーです(^^)
背景
この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。
一言でいうと何か
Windows のデスクトップアプリで、Code タブのセッションを Windows 本体ではなく WSL 2 ディストリビューション内で実行する機能です。セッションの Claude Code プロセス・ツール・git がすべてディストリビューション内で動き、その Linux ツールチェーンとネイティブな Linux パスを使います。つまり、プロジェクトが実際に対象とする Linux 環境と同じ場所で作業できる、というのが要点です。
どういう場面で役立つか
リポジトリが WSL ディストリビューションのファイルシステム内にあるとき。こうしたファイルを Windows 側から扱うと、ネットワークファイルシステムを経由するため遅く、ファイル監視(ファイル変更の検知)も機能しません。セッションをディストリビューション内で実行すれば、この2つの問題をどちらも回避できます。
プロジェクトの対象環境が Linux で、同じツールチェーンとパスで動かしたいとき。git や各種ツールがディストリビューション内のものになるため、/home/you/project のような Linux パス前提の挙動が、本番や CI と食い違いにくくなります。Windows と Linux でパスや改行、ツールのバージョンが異なることに起因する差異を避けたい場合に効いてきます。
不要・向かないケース：リポジトリが Windows 側にあるなら、わざわざ WSL セッションにする利点は薄くなります。また WSL セッションではまだ使えない機能があり、統合ターミナル、コネクタとプラグイン、セッションフォーク、ファイルブラウザペイン、そしてコンポーザーで @ を入力したときのファイル提案は利用できません。これらが必要な作業には向きません。前提として WSL 2 が必要で、WSL 1 はサポートされません。組織の管理対象デバイスでは、管理者によって WSL セッションが無効化されている場合があります。
要件と開始手順、利用可否
このページには “` で囲むコードブロックはなく、/home/you/project や \\wsl.localhost\... などのパス、git や @ のインライン言及があるのみです。ここでは前提・手順・機能の利用可否を順に説明します。
前提(要件)
必要なのは、WSL 2 がインストールされた Windows 10 または 11(WSL 1 は非対応)、少なくとも1つのインストール済みディストリビューション(例:Ubuntu)、そしてそのディストリビューション内にインストールされた git です。git はディストリビューション側に入っている必要がある点に注意します(Windows 側の git ではありません)。セッションはディストリビューション内で完結して動くため、必要なツールチェーンもそのディストリビューションに用意されている前提になります。
WSL セッションを開始する
手順は3ステップです。まず Code タブで新しいセッションを開始し、環境ピッカーを開くと、インストール済みの WSL 2 ディストリビューションが WSL セクションに表示されるので、1つ選びます。次にフォルダを選びます。セッションはそのディストリビューションのホームディレクトリで始まり、フォルダのブラウジングはディストリビューション内で行われて /home/you/project のような Linux パスが使われます。最後に、フォルダ内の最初のセッションではワークスペース信頼ダイアログが出るので信頼を付与します。信頼はディストリビューションとフォルダの組み合わせごとに与えられ、あるディストリビューションでフォルダを信頼しても、別のディストリビューションや Windows 上の同じパスには適用されません。
補足として、ディストリビューション内の「最初の」セッションは、Claude が内部をセットアップする間、少し時間がかかります(元ページは最初のセッションについてのみこの点に触れています)。通常のフォルダピッカーから \\wsl.localhost\... のフォルダを開くこともでき、その場合はそのディストリビューション内で改めて開かれます。最近使ったフォルダはディストリビューションごとにピッカーへ表示されるため、プロジェクトへの再接続は1クリックで済みます。
WSL セッションで機能するもの・しないもの
機能するのは、並列セッション、サイドチャット、ビジュアル diff レビュー、ブランチとプルリクエストのステータス、そして worktree で、いずれもディストリビューション内の git とツールチェーンに支えられて動きます。「エディタで開く」は、Remote – WSL を通じてディストリビューションに接続された VS Code を開きます。
一方、前述のとおり WSL セッションではまだ使えない機能があります。統合ターミナル、コネクタとプラグイン、セッションフォーク、ファイルブラウザペイン、コンポーザーでの @ 入力によるファイル提案です。これらを多用するワークフローでは、機能が揃うまではローカル(Windows)セッションや CLI を併用する判断になります。
管理対象デバイスでの注意
組織によって管理されているデバイスでは、WSL セッションが利用できないことがあります。セッション開始が「デバイスが管理されている」旨のメッセージで失敗する場合、それは自分の設定の問題ではなく、管理者によって制御されている状態です。この場合はまず組織の管理者に確認するのが早く、管理者向けには、設定がどのようにデバイスへ到達するかを扱うデプロイメントガイドの該当セクションが案内されています。
まとめ
WSL セッションは、Windows のデスクトップアプリで Code タブのセッションを WSL 2 ディストリビューション内で実行し、Linux のツールチェーンとネイティブパスで作業できるようにする機能です。リポジトリがディストリビューションのファイルシステム内にある場合に特に有効で、Windows 経由の遅さやファイル監視が効かない問題を回避できます。前提は WSL 2(WSL 1 不可)・1つ以上のディストリビューション・ディストリ内の git で、開始はディストリビューション選択→フォルダ選択→信頼付与の3ステップです。並列セッションや diff レビュー・worktree は使えますが、統合ターミナル・コネクタ/プラグイン・ファイルブラウザペイン・@ ファイル提案などは未対応で、管理対象デバイスでは無効化されている場合があります。
次回は、残る Desktop 周辺の未執筆ページ(Desktop スケジュール済みタスクなど)か、あるいは長く保留している引き継ぎ課題(第5回欠番の補完・第1/2回の照合)に着手する予定です。
この記事は執筆時点の公式ドキュメントに基づいています。最新の情報は必ず公式ドキュメントをご確認ください。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント