もはやIDEは買うものではなく、自分で作る時代へ

開発の道具を買うのをやめて、自分で作りました。WispというmacOS専用の統合開発環境で、複数プロジェクトのClaude Codeを1つのウィンドウで並行して走らせるためのものです。

気づけばIDEの用途は4つに減っていた

コードを書くのがAIに移ってから、IDEを開いたままにしている理由を数えてみたところ、4つしか残っていませんでした。diffのレビュー、手でコミットするためのgitツール、そのdiffをグラフィカルに眺めること、そしてMarkdownのドキュメントを読むこと。補完もインスペクションもリファクタリングも、ここしばらく一度も使っていません。

IDEは「書く道具」から「読む道具」に変わっていたのに、こちらが払っているコストは書く道具のままだった、ということです。しかも並行しているプロジェクトの数だけウィンドウが開き、そのそれぞれが独立したインデックスを抱えます。実測すると重量級のIDEは1インスタンスで4.9GBを使っていて、それが4つ並んでいる状態は、本来AIとそのツールに回すべきメモリとCPUを寝かせているのと変わりません。

買うのではなく作れるようになった

数年前なら、IDEを自作するという発想そのものが正気ではありませんでした。実装コストがはっきり下がったこと（→ AIコーディングがもたらすパラダイム・シフト）に加えて、もうひとつ大きいのが自分専用でよいという点です。

売り物の道具は誰にでも合うように作らなければならず、その汎用性がそのまま重さになります。自作なら先ほどの4用途を満たせば済むので、要らないものを積まないという判断を、そのまま実装に落とせます。

Wisp — ひとつのウィンドウに複数のClaude Code

3ペインの単一ウィンドウで、タブもターミナルもありません。左がプロジェクト一覧とSessions / Files / Changesの3タブ、中央がチャット、右がコード・diff・Markdownの兼用席です。

プロジェクトを開くとclaudeが1本起動し、別のプロジェクトへ移っても止まりません。4つ開いていれば4本が同時に走っていることになり、どれが自分の返事を待っているのかが常に見えるところに出ています。

ネイティブで作ると常駐40MBで収まる

SwiftとAppKitで書いています。4プロジェクトを開いた状態での実測は次のとおりです。

数字そのものより、空けたCPUとメモリの行き先のほうが大事です。claudeは1本あたり340MBほど使うので4本で1.3GBになりますが、こちら側を40MBに畳んでおけば、そのぶんはまるごとAIとそのツールに回せます。

気づかないことがいちばん損をする

複数プロジェクトを並行させて実際に困ったのは性能ではなく、合図を取りこぼすことでした。ターンが回っているあいだ、人は別のウィンドウを見ています。

そこで状態（実行中 / 入力待ち / 完了 / エラー）を5つの層に出しました。メニューバーの常駐項目、Dockバッジ、通知センター、サイドバーのドット、そして音です。本命はメニューバーで、通知が流れて消えるのに対してこちらは残り続けます。開けばプロジェクトごとに「いま何を待っているか」がBash · 4.2sのように並び、クリックすればその会話まで飛べます。

さらに、通知のバナーからそのままAllow / Denyを返せます。 ただしボタンを付けるのは、バナーの本文が要求を言い切れているときだけにしました。押す人が読んでいる文が、許可の対象そのものでなければならないからです。この粒度は、ネイティブでなければ出せませんでした。

Claude Desktopでできることはひととおりできる

ここは自作でいちばん妥協したくないところなので、基準を1行だけ決めてあります——Claude Desktop版のClaude CodeでできてWispでできないことがあれば、それは穴として数える。

端末エミュレータを埋め込むのではなく、claudeをstream-jsonで駆動してネイティブのUIに描いています。応答はMarkdownとして描画され、ツールの呼び出しはカード、権限の確認はモーダルではなく入力欄の真上に出るバーです。planの承認、AskUserQuestionの質問カード、サブエージェントの入れ子、バックグラウンドタスク、推論Effortのスライダ、チェックポイントからの巻き戻し、画像の添付——ひととおり揃っています。

権限の確認をモーダルにしなかったのは、複数プロジェクトを並行させることと正面からぶつかるからです。答えないまま別のプロジェクトへ行ってよく、その要求は自分の会話の中で待ち続けます。

読むための機能だけをIDEから持ってくる

AIがコードを書くのであれば、人間の側にLSPは要りません。例外は定義ジャンプ（Go to Definition）だけで、これはレビューに必須です。

索引はtree-sitterの単層だけで、型解決はしません。名前ベースなので候補が複数になることは前提で、そのときは候補リストが出ます。インデクサのプロセスは1つも起動せず、索引はin-processのSQLiteに置いてあります。先ほどの40MBは、ここを削った結果です。

索引が更新されるのは、プロジェクトを開いたときと、ターンが終わったときと、ファイルを保存したとき。Claude Codeが書いたコードは、そのターンの終わりには⌘Bから見えます。

索引は人だけのものではない

今回いちばん効いたのがここです。Wisp自身がMCPサーバーになり、起動したclaudeに自分の索引と右ペインを4つのツールとして渡します。

前の2つは、AIが他の手段では届かない索引に答えさせるものです。「この名前はどこで定義されているか」という同じ問いを、索引ツールで解かせた場合とgrepとReadで解かせた場合とで比べると、入力トークンが1/12、所要時間が1/6になりました。grep経路は8ターンかけて249,957トークンを読み、索引ツールは2ターンの20,424トークンで同じ答えに着いています（1問だけの比較なので倍率をそのまま一般化はできませんが、桁が違います）。索引はもともと⌘Bのために持っているものなので、渡すための追加コストはほぼありません。

後ろの2つは向きが逆で、AIが画面を動かします。 「この関数はここです」と文章で説明する代わりに、右ペインにその行を開いてしまう。読む席が1つしかないので、開けば必ずそこに出ます。

過去の会話を文脈に戻す

past_sessionsを別に立てたのは、これが並行開発でいちばん失われやすいものだからです。

Claude Codeは会話の記録をJSONLで残しますが、それを探す手段は実質ありません。「前に試して駄目だったよね」「その方針は却下したはず」を覚えているのは人間だけで、プロジェクトが4つあれば人間も覚えていません。

Wispは全プロジェクトの過去セッションをFTS5 + bigramで索引しています（日本語で引けます）。3.6GBあった記録が40MBの索引に収まり、検索は1ms前後で返ります。人は⌘⌥Fで全プロジェクトを横断して引き、AIには同じ索引を、そのプロジェクトのぶんだけ渡しています。

効果があるのは「提案する前に、前に決めたことを見に行かせる」ことです。同じ議論を2回やらずに済み、一度却下した案が別の会話で復活することも減ります。

買うのをやめると道具が自分の側に来る

エンドユーザー向けのドキュメントを書き終えたところで、近くLabsから公開する予定です。

作ってみて分かったのは、道具のほうを自分のワークフローに合わせられることの効果の大きさでした。IDEを買うと、そこに用意された作業の流れに人が合わせることになります。ひとつのウィンドウに4本のclaudeを並べ、返事を待っているものを常に見えるところに置く——この形は、売り物の中には見当たりませんでした。

書くことがAIに移ったあと、人間の側に残るのは読むこと・判断すること・差し戻すことです。その3つのためだけの道具は、まだ誰も売っていません。