自律型IDEか、ターミナル駆動か。WSL厳格環境における “AIパートナー” の選び方

2026-02-15

導入：制御 vs 委任の選択

最近、開発者のタイムラインを賑わせている「Google Antigravity」のような自律型IDE（Agentic IDE）と、AnthropicがリリースしたCLI型の「Claude Code」。

どちらも強力なツールですが、「環境を汚さない」ことに命を懸けているWSLユーザーにとって、この選択は単なる好みの問題ではありません。

これは「制御」と「委任」の戦争です。

今回は、厳格なパッケージ管理（mise, fvm, uv）を敷くWSL環境において、どちらを採用すべきか、その葛藤と結論を記します。

前提：私の “聖域” (Tech Stack)

私の開発環境は、無秩序な pip install や npm install -g を許しません。

全てのランタイムは厳密に管理されています。

WSL 2 (Ubuntu)
├── ⚡ Shell: Zsh (Pure & Fast)
├── 🐍 Python: uv (No poetry, No pip direct)
├── 🎯 Flutter: FVM (Strict versioning)
└── 📦 Node/Go: mise (The only version manager allowed)

この「整えられた庭」に、土足で踏み込んでくるAIツールは不要です。

なぜここまで厳格にするのか

環境管理を厳格にする理由は、再現性とクリーンな状態の維持です。

プロジェクトごとの独立性: uvでPython環境を隔離し、miseでNode.jsバージョンを固定
グローバル汚染の回避: システムPythonやNode.jsに影響を与えない
高速な環境復元: mise install一発で全ての依存関係が揃う

この環境に「AI開発アシスタント」を導入する際、彼らがこのルールを守ってくれるかが最重要課題です。

葛藤：Antigravity (自律型IDE) の誘惑とリスク

Google Antigravity（Project IDX系譜の自律型IDE）は魅力的です。

「これ直して」と言えば、ファイルを開き、修正し、コミットまでしてくれる未来。しかし、そこに落とし穴があります。

1. コンテキストの断絶

Antigravityのエージェントは、私の .zshrc を深く理解してくれるでしょうか？

彼らがパッケージを追加する際、以下のようなリスクがあります：

期待する動作	実際に起こりうる動作	結果
`uv add requests`	`pip install requests`	システムPythonが汚染される
`fvm flutter pub get`	`flutter pub get` (システムFlutter)	バージョン不整合が発生
`mise exec -- npm install`	`npm install -g`	グローバル環境に依存関係が追加される

「動くけど、環境が汚れる」 —— これが最大の懸念です。

2. リモート接続のオーバーヘッド

WSL環境でAntigravityを使う場合、多くの場合Remote接続（VS Code Remote – WSL的な）を経由します。

これは、ネイティブなWSLターミナル操作に比べて、1レイヤー余分な抽象化が入ることを意味します。

3. 透明性の欠如

自律型IDEは「裏で勝手にやってくれる」のが魅力ですが、裏を返せば「何をやっているか見えない」リスクでもあります。

特に、パッケージ管理やファイル操作において、意図しない副作用が発生する可能性があります。

解法：VS Code + Claude Code (CLI)

対して、VS Codeの統合ターミナルで動かす claude (Claude Code) は、アプローチが異なります。

Claude Codeの3つの強み

1. 実行権限の継承

私が mise でセットアップしたシェル環境の中で動きます。

# .zshrc で設定したパスとツールがそのまま使える
$ which python
/home/user/.local/share/uv/python

$ claude "Pythonのバージョンを確認して"
# → uv管理下のPythonが使われる

2. ツールの活用

fd や rg といった高速なRust製ツールを自然に使いこなします。

# Claude Codeは私のツールセットをそのまま使う
$ claude "TypeScriptファイルの中からTODOコメントを探して"
# → 内部的に `rg "TODO" --type ts` を実行

3. 透明性

ターミナルに出力されるコマンドが見えるため、pip を叩こうとしたら即座にキャンセルできます。

これは「AIと協働する」感覚であり、「AIに丸投げする」感覚ではありません。

比較：制御と自律のトレードオフ

特徴	Antigravity / Cursor (Agent IDE)	VS Code + Claude Code (CLI)
環境認識	不安定 (コンテナや独自シェルに依存しがち)	完全 (現在のZsh環境をそのまま継承)
ツール遵守	⚠️ `pip` や system node を使いがち	✅ `uv`, `mise`, `fvm` のパスに従う
操作感	マジック (裏で勝手にやる)	オペレーター (横でコマンドを叩く)
透明性	低 (何をやっているか見えにくい)	高 (全てのコマンドが可視化される)
WSL親和性	Remote接続のレイヤーが一枚増える	Native (WSL内部で完結)
学習曲線	低 (すぐ使える)	中 (ターミナル操作の理解が必要)

結論：私は “CLIの魔人” を選ぶ

私の結論は 「VS Code を母艦とし、そのターミナルで Claude Code を飼う」 です。

開発効率の真の意味

開発効率とは、単にコードを書く速さだけではありません。

「環境の一貫性を保ち、将来の負債を作らないこと」も含まれます。

mise や uv で構築した高速で堅牢な環境をフル活用するには、AIにもそのルール（CLIコマンド）に従ってもらう必要があります。

推奨ワークフロー

私が実践している、WSL + Claude Codeの理想的なワークフローです。

ステップ1: 環境セットアップ

# VS Codeでプロジェクトを開く
code ~/projects/my-app

# ターミナル (Zsh) で必要なツールを確認
mise current
# node  20.11.0  (set by ~/projects/my-app/.tool-versions)
# python  3.12.1  (set by ~/projects/my-app/.tool-versions)

ステップ2: Claude Codeを起動

# WSL内のターミナルでClaude Codeを起動
claude

ステップ3: 依頼する（具体例）

# 例1: 検索と修正
「`fd` で対象を探して、`uv` 環境下でテストを通すように修正して」

# 例2: 依存関係の追加
「`uv add httpx` でhttpxを追加して、requests の代わりに使うように書き換えて」

# 例3: Flutterプロジェクト
「`fvm flutter pub outdated` で古いパッケージを確認して、安全にアップデートして」

これが、WSL使いにとっての「秩序あるAI開発」の解です。

まとめ：あなたはどちらを選ぶ？

最終的な選択は、あなたの優先順位次第です。

あなたのタイプ	おすすめ
環境の完全制御を重視	VS Code + Claude Code (CLI)
スピード重視、環境は多少汚れてもOK	Antigravity / Cursor (自律型IDE)
ターミナル操作に慣れている	Claude Code
GUI中心の開発スタイル	Antigravity

私の場合、長期的な環境の健全性と透明性を重視した結果、Claude Codeを選びました。

AIツールは「魔法の杖」ではなく、「賢い相棒」であるべきです。その相棒が、あなたのルールを理解して動いてくれるかどうか。それが、WSL環境における最重要の選定基準です。