さようなら Claude、こんにちは Pi
Claude Code を 1 年以上使った後、Caleb は開発環境をオープンソースの harness Pi に切り替え、その過程で積み重なった小さな不満も併せて挙げた。
日本語
コピー
Claude Code はかなり長く使ってきた。Claude Pro のサブスクリプションで使えるようになった 1 年以上前からだ。初めて触ったとき、週末の小規模プロジェクトの要件を適当に投げたら、ぐちゃぐちゃの Python コードがどっと出てきて、それだけで興奮したのを覚えている。数年後に振り返れば、あのリリースは現在のソフトウェア開発の新時代を押し進めた主要な力のひとつだったと見なされるだろう。
それでも、小さな不満が積み重なった末に、メインのコーディングツールとして使うのをやめ、開発環境を Pi に移すことにした。
Anthropic 側も当然それを察知していたのだろう……決断を下したわずか1日後に、彼らは Claude Code がついに AGENTS.md ファイルをサポートするようになったと発表し、引き留めにかかった。残念ながら、私には遅すぎたし、これだけでは足りなかった。
不満
正式な死亡記事があるわけでもないので、これを機に Claude Code で最も気に入らなかった点、つまり Pi で避けられると期待している点をいくつか書いておく。
AGENTS.md の一件は、Claude Code をやめると決めた理由をほぼすべて凝縮している。誤解しないでほしいが、GitHub の趣味プロジェクトのリポジトリに CLAUDE.md ファイルが散らばっているのは、なかなか良いゲリラマーケティングだ。ただ、ユーザーが自分で2つの形式の間を行き来してコピーしたりシンボリックリンクを張ったりしなければならないのは、体験としてあまりにひどい。
古い人間なので、コミットする前に生成されたコードの大半には目を通すようにしている。以前は VSCode で Claude Code を使っていて、ツールを IDE に接続できた。これはかなり便利だった。ファイル内のテキストを選択すると、質問や修正の指示を出すときに、その選択範囲が自動でコンテキストに入る。
問題は、同時にひとつのセッションしか IDE に「接続」できないことだ。別の作業のために2つ目のタブを開き、1つ目がまだ動いていると、2つ目のセッションには IDE のテキスト選択イベントがまったく届かない。この問題は少なくとも 2025 年 12 月から報告されていて……まったく無関係なバグの重複としてクローズされた。1
もちろん、公式の Claude Code VSCode GUI 拡張を使えばいい。こちらは複数のタブを同時に開き、選択したテキストを各タブのコンテキストに読み込める。だが、この拡張自体にも不具合が多い。組み込みのスラッシュコマンドの半分は GUI ではまったく動かない。カスタムステータスバーには一切対応していない。サブエージェントの出力メッセージは時系列でメインの会話スレッドに積まれるだけなので、複数のサブエージェントを同時に走らせると読むのがひどく煩わしい。まだまだ数え上げられる。
こうした問題があるにもかかわらず、Anthropic はほとんど狂ったような速さで Claude Code に機能を詰め込んでいて、品質や安定性にはあまり関心がないように見える。Dynamic workflows や agent teams、ultrareviews は、企業顧客が毎日消費するトークンを増やすのにはうってつけだが、私が欲しいもの、必要なものではない。
こうした機能リリースに加えて、彼らはいつもどこかで手を加え、私の個人設定をかき乱す。本稿執筆時点で、Claude Code は今年すでに 244 回リリースされている。その4分の3以上がシステムプロンプトやツールの説明を変更しており、これは LLM の挙動を大きく変える（特に新しい指示がユーザーのプロンプトやリポジトリの規約と衝突する場合）。
それは何のためなのか。システムプロンプトを80% 削ったにもかかわらず、Claude Code のコストは Pi よりはるかに高く、その利点も見当たらない。デフォルトの Bash ツールの説明は 3,000 トークン近くあり、その大半は git の使い方や GitHub で PR を開くことに関する雑多な内容だ。2 ちなみに、モデルはもともとそういうことを知っているので、細かい説明は要らない。3
これから
この記事ではずいぶん愚痴をこぼした。すまない。いつもの自分のスタイルではないし、Anthropic がクールなソフトウェアを作っているのは確かだと思っている。最初から自分が Claude Code を担当していたらもっとうまくやれた、などという妄想も抱いていない。LLM のコーディング harness は非常に新しい領域で、ある分野で最初に革新を起こすのは極めて難しい。Pi のような後発ツールには、何がうまくいき何がうまくいかないか、どれが中核機能でどれが削れるかを、後から見て学べるという利点がある。
結局のところ、CC は明確なビジョンと方向性を欠いた製品のように感じられる。興奮したエンジニアと PM の集団が、手近な機能をどんどん積み上げていく……それが他のユーザーにとって使いにくくなるかどうかは気にせずに。こうした要求に「ノー」と言う責任を負う上の立場の人間がいないように見えるが、プロダクトエンジニアリングではそれが極めて重要だ。というわけで、当面は離れる。
Pi への移行を楽しみにしている。最初の数日は手間がかかったが、それ以降はすんなり進んでいる。安定性、ミニマルなアプローチ、そして高いカスタマイズ性が気に入っている。自分の用途に合わせていくつか拡張を書いたので、整理して早めに公開するつもりだ。同じような不満を抱えているなら、オープンソースの harness を試すことを強く勧める。