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

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

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

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

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

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

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

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

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

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

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

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

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

数字そのものより、空けた CPU とメモリの行き先のほうが大事です。claude は 1 本あたり 340 MB ほど使うので 4 本で 1.3 GB になりますが、こちら側を 40 MB に畳んでおけば、そのぶんはまるごと 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 に置いてあります。先ほどの 40 MB は、ここを削った結果です。

索引が更新されるのは、プロジェクトを開いたときと、ターンが終わったときと、ファイルを保存したとき。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.6 GB あった記録が 40 MB の索引に収まり、検索は 1 ms 前後で返ります。人は ⌘⌥F で全プロジェクトを横断して引き、AI には同じ索引を、そのプロジェクトのぶんだけ渡しています。

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

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

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

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

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