🙄

ぼくのかんがえたさいきょうのIDE (app-hub)

に公開
テーマ「この春、始めたこと」
AI
HTML
IDE
Claude
Codex
idea

正直に書くと、もう、自分でコードをほとんど書いていない。

打ち込んでいるのは指示と判断だけで、コードそのものはAIが書く。最初のうちは「ちょっとズルしてるな」という後ろめたさがあった。でもしばらくして、その後ろめたさの正体に気づいた。手元のIDEが、いまの自分のやり方とまるで噛み合っていないのだ。

VS Codeを開いても、補完もキーバインドももうほとんど使わない。代わりにやっているのは、AIが書いたものを読んで「これで合っているか」を判断する作業だ。それなのにIDEは、相変わらず「人間がいかに速くタイプするか」のための道具のままだった。

だから自分で作ることにした。「書く」を速くするIDEではなく、「判断」を速くするIDEを。この記事は、その発想と、実際に動いているものの話だ。

1. なぜ作ったのか — いまのIDEへの不満

いまのIDE（エディタ）は、そのほとんどの機能が**「人間がコードをタイプする」という前提**で作られている。

  • 補完・スニペット・カーソル移動・マルチカーソル → 速く打つための機能
  • ファイルツリー・タブ・分割ビュー → 自分が書いた場所に戻るための機能
  • 豊富なキーバインド → 手を止めないための機能

どれも本当によくできている。人間が書くなら、の話だけど。

ところが、コードをAIに書かせるようになった途端、自分のボトルネックがまるごと別の場所に移ってしまった。もう「書くこと」ではない。**「AIが書いたものを理解して、採用するか・やり直させるかを判断すること」**になったのだ。

そして今のIDEは、この新しいボトルネックを驚くほど助けてくれない。

  • AIが100行書いた。でも見えるのはテキストの差分だけで、動かした見た目は分からない。
  • UIを作らせた。どう表示されるか確かめるには、手元でビルドして、別タブで開く。判断にたどり着くまでが遠い。
  • リッチなHTMLを生成させた。なのにエディタの中ではただの文字列で、レンダリングはしてくれない。
  • 「結局なにをやったのか」を知るには、ログと差分を自分で追うしかない。

要するに、AIのアウトプットが読みにくく・見えにくいせいで、こちらの判断が遅くなる。書く速度はAIのおかげで何十倍にもなったのに、判断の速度は人間のままだ。気づけば、ここが開発全体の足かせになっていた。

個人開発でいちばん時間を食うのが「タイピング」だった時代は、もう終わりつつある。次に詰まるのは「判断」だ。

不満を一言でまとめると、こうなる。「速く書く」ための道具はいくらでもあるのに、「速く判断する」ための道具がない。

2. 発想の転換 — IDEの仕事は「判断を速くする」ことだ

ここがこの記事でいちばん言いたいところだ。

AI時代のIDEがやるべきなのは、タイピングを速くすることではない。人間に残された唯一の仕事、つまり「判断」を速くすることだ。

人間がコードを書かなくなると、手元に残るのは「方向を決める」「合っているかを確かめる」「育てるか畳むかを決める」——要するに判断だけになる。だとしたら、IDEが最適化すべきは判断の速さのほうだろう。

そして判断が遅くなる原因は、たいてい「見えにくさ」にある。だから設計の原則はとてもシンプルにした。

AIが作ったものを、人間が一目で判断できる形に「可視化」して、判断する場所にそのまま並べる。

テキストの差分ではなく、動く見た目を。ログの羅列ではなく、なにをやったかの要約を。別タブを開く前に、その場でレンダリングを。判断に必要なものを、判断する場所まで持ってくる。それだけだ。

これを形にしたのが、僕がいま作っている管制塔のようなダッシュボードだ。次の章から、その「判断を速くする」具体を見せていく。

3. 判断を速くする① — AIが書いたリッチHTMLを“その場で見る”

いちばん効いたのがこれだった。AIが生成したHTMLを、エディタの中でそのままレンダリングして見る。

UIを作らせたとき、テキストの差分をいくら読んでも「良いかどうか」は判断できない。見た目を見ないと判断できないのだ。そこでコンソールには、AIが生成したモックHTMLをその場で描画するプレビューを組み込んだ。

ところが、これが素直に実装すると動かない。iframe の srcdoc にHTMLを流し込むと、親ページのCSP（script-src 'self' + nonce）をそのまま継承してしまい、Tailwind CDNもインラインの <script>も軒並みブロックされる。AIが作った凝ったモックが、白紙同然になってしまう。

ローカルに常駐する sidecar（runner）に、HTMLを POST /preview で登録する。そしてrunner自身のオリジンから /preview/:id/ として配信し、iframeにはそこを読ませる。隔離は sandbox="allow-scripts"（allow-same-origin なし＝opaque origin）が担保していて、プレビューはアプリのcookieにもDOMにも触れられない。

地味な仕掛けだが、これが判断の速さをいちばん変えた。「ビルドして別タブで開いて確認」という往復がまるごと消えて、生成された瞬間に、その場で本物として見える。 あとは見た目で良し悪しを即決するだけだ。可視化というのは、結局こういう泥臭い工夫の上に成り立っている。

左の入力欄でAIに指示を出すと、右のプレビューに生成されたUIが即座にレンダリングされる。テキストの差分ではなく「動く見た目」で判断する。

4. 判断を速くする② — モック・仕様・コード・差分を、横に並べる

「見た目」だけで判断しきれるわけではない。判断の材料はいくつもあるので、1つのアプリの管制画面に、AIのアウトプットを種類ごとに並べた。

  • mock ビュー … AIが作ったUIモックを③のプレビューで描画する。「方向性、合ってる？」を見た目で判断。
  • spec ビュー … AIにまとめさせた仕様書。「作ろうとしているものの認識、ズレてない？」を文章で判断。
  • dev コンソール … 実際にコードを書かせる場所。エージェントのスレッドとメッセージで「なにをしたか」を時系列で追える。
  • コード・差分のハイライト … 差分には色をつける。読む負荷を下げることが、そのまま判断を速くする。
  • dev URL を新タブで開くボタン … 動いている実物に一発で飛ぶ。「で、結局ちゃんと動くの？」という最後の判断のために。

しかも書き手は Claude だけではない。スレッドごとに Claude と Codex を選べる——同じUI・同じ操作感のまま、エンジンだけを差し替えられる（仕組みは §7 で）。**「どのAIに書かせたか」よりも「出てきたものをどう判断するか」**に主役を移したかったからだ。エージェントはあくまで取り替え可能な“手”であって、可視化と判断の層こそがIDEの本体——という考えが、ここに表れている。

判断に要る材料（見た目／仕様／やったこと／動く実物）が、タブをあちこち探さなくても同じ画面に揃っている。これが「判断を速くする」の中身だ。

実際の管制画面がこれだ。上部のステッパーが「いまこのアプリは“開発”段階で、次にやるべきは仕様を固めること」を示し、タブ（概要・開発・データ連携など）の下に、仕様・UIモック・KPI判定・状態変更（開発中／公開／塩漬け／終了）がまとまっている。

1アプリの管制画面。「いまどの段階か」「仕様は固まっているか」「次の一手は何か」が一目で分かる。AIに作らせる入口（AIで仕様を固める／AIでUIモックを作る）も、すべてここから。

5. 判断を速くする③ — 「このアプリ、続ける？」も判断だ

判断するのは、コードの良し悪しだけではない。個人開発でいちばん難しい判断は——**「このアプリ、育てる？ それとも畳む？」**だと思う。人は、自分が作ったものを感情では殺せない。

だからこの判断も、数字に肩代わりさせることにした。直近2週間のメトリクスから「当たり / 様子見 / 外れ」を機械的に出す、KPIゲートだ（実物は domain/gate.ts）。

export const KPI_GATE = { windowWeeks: 2, visits: 1000, paying: 3, shares: 50, watchVisits: 300 }

export function gateVerdict(s, hasMetrics, state, gate = KPI_GATE) {
  if (!hasMetrics || state === 'developing') return { v: 'na', label: '判定前' }
  const totalVisits = sumAll(s.visits)
  // 当たり: 訪問が基準超え かつ（課金 or シェア）が伸びている
  if (totalVisits >= gate.visits && (latest(s.paying) >= gate.paying || sumAll(s.shares) >= gate.shares))
    return { v: 'hit', label: '当たり' }
  if (totalVisits >= gate.watchVisits) return { v: 'watch', label: '様子見' }
  return { v: 'miss', label: '外れ' }   // 伸びていない
}

// 判定 → 次にどう状態を動かすかの“おすすめ”まで出す
export function recommendedState(v) {
  if (v === 'hit') return 'live'       // 当たり → 育てる
  if (v === 'miss') return 'dormant'   // 外れ  → 畳む
  return null                           // 様子見 → 据え置き
}

やっていることは、コードのプレビューと本質的に同じだ。判断に必要な情報を、人間が一目で決められる形に可視化する。 ③では「コードを見て判断」を速くし、ここでは「数字を見て判断」を速くしている。そして可視化を突き詰めた先にあるのが、意思決定そのものの自動化だ。当たり/外れがダッシュボードのトップに並び、感情ではなく数字のほうが「育てる/畳む」を告げてくる。

しきい値は僕の肌感で置いた仮の値でしかない。大事なのは数字が正しいことではなく、「判断」が毎週止まらずに回り続けることだ。

ダッシュボードのKPIゲート判定ボード。アプリが「当たり／様子見／外れ／判定前」に自動で振り分けられる。感情ではなく、数字が育てる／畳むを告げてくる。

6. 全体像 — これが僕の考える「AI時代のIDE」

ここまでをつなげると、1枚の絵になる。

        ┌──────── AI時代のIDE（判断の管制塔）────────┐
        │                                              │
 アイデア│  作らせる → 見る → 判断する → 育てる/畳む   │ 数字
   ─────▶│   (dev)   (mock)   (spec)     (KPIゲート)    │◀─────
        │     ▲                                        │
        │     └─ Claude / Codex（取り替え可能な手）     │
        └──────────────────────────────────────────────┘

普通のIDEが「ファイルを開いて書く」場所だとすれば、これは**「AIに作らせて、見て、判断する」場所**だ。アイデアを採用するとアプリになり、AIがコードを書き、その成果物がその場で可視化され、公開後は数字がゲートで判断される。作る・見る・判断する・育てる/畳む——その全部が、ひとつの画面に同居している。

トップのダッシュボード。全アプリ横断のKPI・ファネル・ゲート判定が一望できる。「次にどれを触るか」をここで決める。

「IDE」と呼ぶと大げさに聞こえるかもしれない。でも、一日のうちいちばん長く開いていて、開発の判断をすべてそこで下しているなら、それはもう自分にとってのIDEだ。 エディタである必要は、どこにもない。

7. 裏側 — ブラウザとAIをつなぐローカルエンジン（agent-runner）

ここまで「ブラウザの画面でAIに作らせて、見て、判断する」と書いてきた。でも、ブラウザは単独ではClaudeを起動できないし、ファイルも書けないし、ターミナルも開けない。その溝を埋めているのが、手元で常駐している小さな sidecar——agent-runner だ。これがこのIDEの“エンジン”にあたる。

127.0.0.1:7878 で待ち受けるローカル専用プロセスで、ブラウザとはトークン付きのHTTP＋WebSocketで会話する。外には一切出ない。役割を並べると、こうなる。

① Claudeを“サブスクのまま”動かす。 チャットは Claude Agent SDK の query() で駆動している。肝は、APIキーで従量課金するのではなく、手元の claude バイナリをそのまま使うことだ。

// チャットは Claude Agent SDK（query()）で駆動する。サブスク認証のまま
// pathToClaudeCodeExecutable 経由で claude バイナリを使う（API キー不要）。
const q = query({ options: { pathToClaudeCodeExecutable: claudeBinary, /* ... */ } })

個人開発でAIに大量に書かせると、API従量課金はあっという間に効いてくる。サブスクのまま回せるかどうかは、この使い方が現実的かどうかを左右する。

② AIの作業をストリームで見せて、判断点を人間に返す。 query() は複数ターンに跨る長命のジェネレータとして動き、その途中経過がイベントに変換されてWebSocketでブラウザに流れてくる。だから「AIがいま何をしているか」がそのまま見える。さらに大事なのが、ツールの実行をモードで制御していることだ。

// auto: 常に即許可 / plan: 計画自体を承認 / supervised: 許可済み以外は承認を求める
export function gateTool(mode, toolName, sessionAllowed) {
  if (mode === 'auto' || mode === 'plan') return 'allow'
  if (sessionAllowed.has(toolName)) return 'allow'
  return 'ask' // ← UI に承認を出す
}

supervised にしておけば、ファイル書き換えのような危険なツールは一つずつ「やっていい？」とブラウザに確認してくる。plan モードなら、まず計画全体を見せて承認させてから動く。AIが勝手に突っ走らず、判断点がちゃんと人間に返ってくる。これも「判断を速くするIDE」の大事な一部だ。

③ 自作スキルを / メニューに出す。 SDKのinitメッセージから利用可能なスキル一覧を受け取り、ブラウザの / メニューに並べる（さっきのスクショの SKILLS 29/29 がこれだ）。アプリ側でON/OFFも切り替えられる。§8で触れる「手順のスキル化」が、そのまま画面から呼べるようになっている。

④ 手は取り替えられる — Claude でも Codex でも。 バックエンドは Claude（Agent SDK）と Codex（codex を JSON-RPC の app-server として起動）の2系統を持っている。ルーター（RouterAgentBackend）が、スレッド単位でどちらを使うかをピン留めする。あるスレッドは Claude、別のスレッドは Codex、という並行運用もできる。

// threadId 毎に provider を1つにピン留めし、対応するバックエンドへ委譲する。
private resolve(threadId, hint) {
  const provider = hint ?? this.pinned.get(threadId) ?? 'claude'
  this.pinned.set(threadId, provider)
  return this.backends[provider] // 'claude' | 'codex'
}

しかも両者は同じ AgentBackend インターフェース（プロンプト送信／承認応答／モード切替…）を実装しているので、画面の操作も、ストリーミングも、ツール承認の流れも、どちらを選んでも同じだ。§4で書いた「どのAIに書かせたかより、出てきたものをどう判断するか」を、ここで物理的に担保している。AIエンジンは取り替え可能な部品、判断の枠組みは共通——この設計が、いちばん効いている。

そして、この「スレッド単位で手を選べる」が本領を発揮するのが、同じ課題を Claude と Codex の両方に投げて、出てきたものを見比べる使い方だ。片方のスレッドで Claude に、もう片方で Codex に、まったく同じ指示を出す。あとは §3 のプレビューや差分で結果を並べて、良かったほうを採る。どちらが速いか・どちらが意図を汲むかはタスクによって変わるので、**「先に選ぶ」より「両方走らせて、人間が判定する」**ほうが結局は速いことが多い。賢さを競うのはエンジンで、最後に勝ち負けを決めるのは人間——これもまた、人間に残った仕事が“判断”であることの、ひとつの形だ。

⑤ ついでに、ターミナルも、留守番も。 sidecar はログインシェルのPTYも握っていて、ブラウザから普通にコマンドも打てる。さらにスケジューラを内蔵していて、定期実行のジョブ（トレンド調査など）を“見ていない間”にも回す。落ちると全部のチャットが切れてしまうので、未処理例外が出てもログだけ吐いて生き続けるようにしてある。

ローカルにプロセスを1個常駐させる——たったそれだけのことが、「ブラウザがAI時代のIDEになる」ための土台になっている。可視化（§3）も、判断点を人間に返すこと（このセクション）も、すべてこのエンジンの上に乗っている。

8. どう作ったのか — “書かない”まま、このIDE自体をAIに作らせた

おもしろいのは、この「AIが書いたものを判断するためのIDE」を、自分ではほとんどコードを書かずに、AIに書かせて作ったことだ。きれいに再帰している。

  • 13日 / 約1,200コミット / 約44,000行 / 12機能を、ほぼ一人で。
  • やり方は、Claude Code に自作スキルを持たせる運用。「機能追加は research → plan → implement の順で進める」「レビューは find → refute → referee の対立構造で回す（1体のAIの“迎合”を潰すため）」——こうした手順そのものをスキルにして、繰り返しをAIに任せた。
  • 土台として、12機能すべてを domain / repositories / usecases / openapi という同じ4層・Effect-TS で揃えた。型を固定したぶん、AIに書かせても構造が崩れない。

開発コンソール。モデル（Claude / Codex）や自作スキル（SKILLS 29/29）を選んで指示を出す。ここでAIにコードを書かせ、その成果を §3・§4 の各ビューで判断する。

ここで得た教訓が、まさにこの記事のテーマと重なる。速く書けるようになるほど、「判断（検証）」を自分の手元に残しておかないと事故る。 実際、こんなことがあった。

  • DB接続のプール化を「速くなるはず」と思って入れたら、計測したらむしろ遅かった。思い込みの最適化を、計測があっさり否定した。
  • マイグレーションが一度だけ黙ってスキップされた。台帳に古い偽の記録が残っていたせいだ。以来、「成功しました」の表示を鵜呑みにせず、実スキーマを自分の目で確かめる癖がついた。

書く速度はAIがくれる。でも、「本当に合っているか」を見抜く判断は、最後まで人間に残る。だからこそ、その判断を速くする道具——AI時代のIDE——が要る。作っている途中で、その必要性を自分自身で証明してしまっていた、というわけだ。

9. まとめ

  • もう自分ではコードを書かない。するとボトルネックが「書く」から「判断する」へ移る。
  • いまのIDEは「速く書く」ための道具であって、「速く判断する」ための道具ではない。だから作った。
  • 設計の原則はひとつ。AIの成果物を、人間が一目で判断できる形に可視化して、その場に並べる。
    • リッチなHTMLをその場でレンダリングする（CSPは runner オリジンで回避）
    • モック / 仕様 / コード / 差分 / 動く実物のURLを、同じ画面に
    • 「続ける？」という判断さえ、KPIゲートで数字に可視化＝自動化する
  • それを支えるエンジンは、手元に常駐するローカル sidecar（agent-runner）。Claude/Codexをサブスクのまま動かし、ツール承認で“判断点”を人間に返す。
  • そして、このIDE自体を**“書かない”ままAIに作らせた**。「速さはAIがくれるが、判断は人間に残る」を、作りながら証明していた。

エディタの進化は、ずっと「いかに速く書くか」だった。けれどAIがコードを書く時代に次に進化すべきなのは、**「いかに速く判断するか」**だと思う。その実験として、僕はこれを作っている。

「この可視化の中身をもっと見たい」「自分ならこう判断を速くする」——そんな声があれば、コメントかリプで教えてほしい。 反響の大きかったところから、続編で深掘りしていく。

Discussion