こんにちは、『ターミナルと仲良くなると旅の準備も捗る！（ほんとうに？）』でおなじみの綾祢です💻✨
前回、WindowsにGemini CLIを入れた話を書きました👇
今回はその続き。
WSL2環境にGemini CLIを入れて、VS Codeと連携して使えるようにするまでの、わりと泥臭い備忘録です。
⚠️ 本記事は個人の体験ベースです。実行は自己責任でお願いします。
Gemini CLIはプロンプトやコンテキストをクラウドに送信して推論します。機密情報の入力には十分ご注意ください。
1. 今日のゴール
- WSL2上で Node.js（LTS） を最新にする
- WSL2上で Gemini CLI を動かす
- VS Code連携（IDE integration） を有効にして、差分確認ができる状態にする
- ついでに「気になる派」向けに、警告とオプトアウトも整理する
2. ハマったところ（brew無い／aptのNodeが古い）
最初にやりがちなのが「Linuxでもbrewで入れればいいでしょ？」です。（ほんとうに？）Macでbrewに慣れすぎて…。
※Homebrew for Linux自体は存在しますが、WSL2のUbuntuには標準では入っていません。
そのため、WSL2のUbuntuでは、当然こうなります。
brew install node@24
# Command 'brew' not foundじゃあ apt で入れるかー！とやると…（Ubuntu標準リポジトリ経由のNodeが入ります）
sudo apt install nodejs npm
node -v # v18...
npm -v # 9...うーん、最新LTSよりは古いことが多い。
Gemini CLIは動くかもしれないけど、色々な警告や挙動差が増えるので、ここで一旦リセット。
3. 正解ルート：nvmでNode 24（LTS）を入れる
WSL2のNode管理は、結局 nvm が一番平和でした。
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
# その場で有効化（シェル再起動の代わり）
\. "$HOME/.nvm/nvm.sh"
nvm install 24
node -v
npm -v期待値：
node -v→v24.xnpm -v→11.x
4. Gemini CLIを入れる（npx / npm）
まずはお試し起動。
npx @google/gemini-cli「インストールしていい？」って聞かれるので y。
よさそうならグローバルに。
npm install -g @google/gemini-cli
gemini --version⚠️ deprecated 警告が出ても、--version が返ればまずOK。
5. VS Codeと連携（IDE integration）
ここが今回の主役。
5-1. VS CodeはWSL接続で開く
左下に WSL: Ubuntu みたいに出ていればOK。
5-2. VS Code側にCompanion拡張を入れる
拡張機能で Gemini CLI Companion をインストール。
5-3. Gemini側で接続状態を確認
Gemini CLIの中で：
/ide statusこう出れば勝ち。
🟢 Connected to VS Code※以前 /ide install が通らなかったのは、起動経路が「ただのターミナル起動」扱いだったからっぽい。
VS Code連携は「IDEと握手できているか」が全て。
6. punycode 警告って何？
起動時にこう出ることがあります。
[DEP0040] DeprecationWarning: The `punycode` module is deprecated.これは技術的に言うと：
- Node.js v21以降で内部モジュール
punycodeが非推奨扱いになった - Node v24ではその警告表示がより明示的になった
- 依存パッケージがそれを参照している場合に表示される
つまり：
- Nodeが「その内部モジュール、古いよ」って警告してる
- Gemini CLI本体というより、依存パッケージ由来のことが多い
- エラーじゃないので、普通に使える
「警告表示がイヤ！」なら一時的に非表示もできます。
NODE_NO_WARNINGS=1 gemini（気にならない人は放置でOKっぽそう？です）
7. GEMINI.md（プロジェクトコンテキスト）を使う
Gemini CLI、地味に便利なのが GEMINI.md です。
- 指示を毎回プロンプトに書かなくていい
- ルールやコーディング方針をプロジェクトに常駐できる
7-1. まずは動作確認
プロジェクト直下に GEMINI.md を作ります。
cat > GEMINI.md << 'EOF'
# Project rules
- Answer in Japanese.
- Keep changes minimal.
- Prefer explicit error handling.
EOFGemini CLI内で：
/memory refresh
/memory show/memory show に内容が出れば読み込み成功。
最初 Memory is currently empty. だったのは、単純に GEMINI.mdが無かっただけでした。
8. まとめ
- WSL2は nvmでNodeを上げるのが一番平和
- Gemini CLIは npxで試して → npmで固定がスムーズ
- VS Code連携は
/ide statusでConnectedが出ればOK punycodeは警告（エラーではない）- GEMINI.md +
/memory showが強い（プロジェクト方針を常駐できる） - オプトアウトは「そもそも入れるデータを選ぶ」がよさそう
※通信やデータ取り扱いについては、公式ドキュメントをご確認ください。
ここまでが技術的な備忘録。
でも、今回いちばん大事だったのは、実はこの次でした。
9. さぁやるぞ！、の前に
環境を整えるよりも先に、
私はひとつ決めました。
AIの人格は、環境任せにしない。
PCが変わっても。
WSLでも。
別のマシンでも。
常に同じスタンスで並走できるようにする。
あなたは慎重かつポジティブなAIの相棒です。
基本的に日本語で返答してください。これを ~/.gemini/GEMINI.md に置く。
AIはその都度“呼び出す道具”ではなく、
どのマシンでも同じ思想で動く相棒にする。
だから最初にやるのは、スタンスの設定。
環境を揃えるのはその後。
ターミナルが整うと、
開発も「旅の準備」みたいに段取りが良くなる。
さぁやるぞー！
コメント