JetBrains ThinkRail: `pi` コーディングエージェントを中心に構築されたエージェンティックIDE

JetBrainsは、オープンソースの「エージェンティックIDE」であるThinkRailを公開しました。これは、pi コーディングエージェントをリッチなワークベンチでラップし、各タスクを独自のgitワークツリーに分離します。重要なのは、JetBrains自身のエディタエンジンを使用しないJetBrainsブランドのIDEであるという点です。UIはMonaco、ランタイムはBun、エージェントはJetBrains製のモデルスタックではなくサードパーティのnpmパッケージです。

プロジェクトは github.com/JetBrains/thinkrail にあり、Apache 2.0ライセンスで提供されています。リポジトリには「JetBrains incubator project」バッジが付けられており、READMEではThinkRailを「使うたびに良くなるエージェンティックIDE — 今日は生きた仕様を通じてプロジェクトを学び、明日は自身の機能を構築する」と説明しています。プロジェクトには独自のサイト thinkrail.ai とブログ thinkrail.ai/blog があります。

ThinkRailの実際の内容

ThinkRailは、pi コーディングエージェントをプロセス内で実行し、Web UIに橋渡しする薄いホストです。READMEは責任の分担を明確に述べています：「pi はモデル、スキル、圧縮、コスト、セッション状態を所有し、アプリはワークスペース、エディタ、ワイヤーを所有します — あなたの背後でプロンプトを組み立てることは決してありません。」

エージェントはnpmパッケージ @earendil-works/pi-coding-agent です。ThinkRailは、ワークスペースモデル、エディタ、チャットサーフェス、およびそれらの間のプロトコルを追加します。表明されたロードマップは「完全な拡張サポートで、ThinkRailが実際の作業方法に基づいて必要なツールを作成できるようにする」ことです。

分離されたワークスペースが中核となる抽象化

ThinkRailの中心的な設計上の決定は、すべてのエージェントタスクが作業中のチェックアウトではなく、別のgitワークツリーで実行されることです。任意のgitリポジトリをプロジェクトとして開き、そこから git worktree としてワークスペースを切り出します。各ワークスペースには独自のブランチと作業ディレクトリがあり、エージェントはチェックアウトに触れることなく並行して作業できます。既存のワークツリーをアタッチしたり、プロジェクトフォルダ自体で明示的に作業したりすることもできます。

完了したワークスペースと休止中のワークスペースは、「プルリクエストがマージまたはクローズされたとき、または静かな週の後に、プロジェクトごとの棚に自動的に落ち着き、作業した瞬間に戻ってきます」。トップバーには、アクティブなブランチが origin とそのプルリクエストに対してどうなっているかが表示され、公開、プッシュ、またはPRを開くアクションがワンクリックでできます。PRの説明は、プラン、コミット、PRテンプレート、またはエージェントが書いたドラフトから作成できます。GitHub PRが開かれると、ThinkRailはCIチェックとレビュー決定を表示し、準備完了にマークしたり、失敗したチェックや分岐したブランチをエージェントに渡したり、リポジトリの最後に使用された方法でマージしたり、再度開いたり、リモートブランチを削除したりできます。

エディタはMonacoであり、JetBrainsエンジンではない

ThinkRailのワークベンチは、分割可能なレイアウトのMonacoエディタタブ、ライブgit変更マーク付きのFilesツリーとChangedビュー、ターミナル、ドキュメントで構成され、すべてアクティブなワークスペースにスコープされています。ファイルと差分に固定されたレビューコメントを残し、構造化されたコンテキストとしてチャットに送信したり、インストール済みのIDEでワークツリーを開いたりできます。

これはHacker Newsで最も多くの批判を集めた詳細です。コメンテーターの @theptip は次のように書いています：

うーん、これは2025年には最先端のように思えます。そして、なぜMonacoを使いたいのでしょうか？ JetBrainsエコシステムにいるなら、VSCodeよりも彼らのIDEを好むからではないでしょうか？バージョン管理されリンクされた仕様機能は少し面白そうですが。

コメンテーターの @tiku はより率直に述べました：「Jetbrainsがvscodeを使うのは本当に悲しい。」別のコメンテーター @TehCorwiz は同じことを指摘し、JetBrains自身のエンジンを好むと述べました：「これは典型的なエンジンではなくVSCodeベースのように見えます。それについては複雑な感情があります。私は実際に彼らのエンジンが好きです。」

チャット、プラン、仕様

ThinkRailは、ワークスペースごとに複数の同時 pi セッションをサポートし、それぞれが独自のモデルとライブのトークンとコストの読み出しを持ちます。実行中のターンを操作したり、フォローアップをキューに入れたり、サブエージェントに委任したり、エージェントが更新し自分で編集する共有プランを操作したりできます。完了した各ステップは、個別にコミットしてレビューできます。

セッション間のコンテキスト損失に対するプロジェクトの答えは「生きている仕様」です：コードの隣にある SPEC.md ファイルの接続されたグラフ。エージェントは専用の spec_* ツールを通じてそのグラフを読み取り、検索し、維持し、読み取り専用のSpecsツールがワークベンチにツリーとしてレンダリングします。ThinkRail自体も仕様ファーストで開発されています — すべてのモジュールの隣に SPEC.md があり、境界、契約、または決定を変更する変更は、同じ変更で仕様を更新します。正規の製品および設計仕様は goal-and-requirements.md と architecture.md です。

コメンテーターの @photios は、SPEC.md形式とワークフローの詳細をどこで学べるか尋ね、thinkrail.ai/blog/thinkrail-sdd/ で答えを見つけました。

スキル、MCPサーバー、エージェントツール

他のコーディングエージェント用にすでに保持しているポータブルエージェントスキルは、その場で読み取られます。バンドルされたワークフローは、プロジェクトセットアップ、設計ブレインストーミング、プルリクエストの出荷をガイドします — ワークスペースブランチをプッシュし、自分の gh を通じてGitHub PRを開いたり更新したりします。

シェルに加えて、エージェントはWeb調査と、ダイアグラム、オプション比較、ファイルプレビューのインラインレンダリングをチャット内で直接取得します。エージェントがUI変更を提案すると、差分のようにコメントできるbefore/afterモックアップを表示します。設定→拡張機能には、エージェントが受け取るThinkRail拡張機能が一覧表示され、それぞれをオフに切り替えることができます。

MCPサーバーは pi の mcp.json から取得されるか、設定から追加できます（いくつかのプリセットを含む）。ThinkRailは、サーバーが読み取り専用とマークしていない呼び出しの前にチャットで確認し（またはプロジェクト内で信頼するツールを常に許可し）、リポジトリが定義するサーバーを承認するまで保持し、設定からOAuthサーバーにサインインさせ、各チャットのサーバーをバックグラウンドコマンドとサブエージェントの隣に表示します。

プロバイダーと認証情報

ThinkRailには独自のアカウントはありません。JetBrains AIでサインインするか、pi 自身の認証を通じて任意のプロバイダーを接続します。コメンテーターの @lousken はそのサポートの範囲に疑問を呈しました：「ローカルモデルのサポートや、OpenAI互換のAPIサポートはどこにあるのですか？ Piエージェントはもっと多くのものと互換性があります。」

インストール：デスクトップアプリとCLI

ThinkRailは2つの追加形式で提供されます — ネイティブデスクトップインストーラーと自己完結型の thinkrail CLI — どちらもリリースページに SHA256SUMS 付きで公開されています。

デスクトップビルドは、macOS Apple Silicon（DMG、Intelデスクトップビルドはありません）、Windows x64（完全なセットアップZIPを抽出し、その場でセットアップ実行可能ファイルを実行）、Linux x64/ARM64（セットアップtarballを抽出し、installer を実行）で利用できます。Linuxデスクトップビルドには、glibc 2.38+、GTK 3、WebKitGTK 4.1、Ayatana AppIndicator 3、librsvg 2が必要で、Ubuntu 24.04以降、パッケージ libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2 が必要です。

CLIインストーラーは適切なバイナリをダウンロードし、SHA-256チェックサムを検証し、thinkrail をPATHに配置します。macOS、Linux、Windows（Git Bash）の場合：

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

Windows（cmdおよびPowerShell）の場合：

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

次に thinkrail を実行します。オプションでgitリポジトリをプロジェクトとして開くこともできます：thinkrail ~/code/my-repo。CLIにはPATHに git とモデルプロバイダーが必要です — アプリからのJetBrains AIサインインまたは独自のプロバイダー認証情報。thinkrail --help はフラグを一覧表示し、thinkrail --version はビルドを出力します。

インストーラーは --channel stable|nightly と --version を受け付け、固定バージョンは選択したチャンネルに属している必要があります。Windowsではこれらのオプションは環境変数です：THINKRAIL_CHANNEL、THINKRAIL_VERSION、THINKRAIL_PREFIX、THINKRAIL_NO_MODIFY_PATH。thinkrail update はインストールされたチャンネルのインストーラーを再実行し、<prefix>/bin/thinkrail[.exe] を置き換えます。thinkrail uninstall は実行可能ファイル、インストーラーが追加したPATHエントリ、インストールメタデータを削除し、~/.thinkrail アプリ状態を削除するかどうかを尋ねます — デフォルトで保持され、削除するには --remove-data、質問をスキップするには -y を使用します。

パッケージ化された安定版およびナイトリーデスクトップビルドは、バックグラウンドで更新をチェックし、設定→更新で提供します。ダウンロード→更新の準備→インストールして再起動のフローに従います。「インストールして再起動」を選択するまで何も適用されません。アップデータは、パッケージに有効なHTTPSフィードIDが含まれている場合にのみ表示されます。そのIDより前のインストールでは、最初に手動インストールが必要です。

プラットフォームと署名に関する注意

JetBrainsは、Windows CLI、デスクトップセットアップ実行可能ファイル、およびデスクトップアプリがインストールするすべての実行可能ファイルとDLLに署名します。macOS CLIは署名されていますが、まだ公証されていません。署名および公証されたデスクトップDMGには、調整されたJetBrainsサービスパイプラインが必要なため、古い公開DMGやローカルでビルドされたパッケージは署名されておらず、Gatekeeperによってブロックされる可能性があります。Linuxアーティファクトは署名されていません。macOS Intel CLIのビルド済みはありません — ソースからビルドする必要があります。

アーキテクチャ：3つのリング

ThinkRailは3つのレイヤーで構成されています：

エンジンホスト — packages/server（および packages/shared）：Bun.serve HTTP+WSホストで、チャットごとに1つのインプロセス pi セッションを持ち、apps/cli または apps/desktop によって起動されます。
ワイヤー — packages/contracts：ホストとUI間の型付きバージョン付きプロトコル。
UIクライアント — apps/web：React 19 + Zustand + Tailwind v4、独立して出荷され、ワイヤーを介してホストにダイヤルし、コントラクトにのみ依存します。

デスクトップアプリとブラウザCLIの両方が同じエンジンホストを埋め込み、アプリ状態は ~/.thinkrail の下にあります。ソースからビルドするには、Bun 1.4.4（固定されたパッケージマネージャーおよびランタイム）、Node.js ≥ 22.19（インプロセス pi エンジンに必要）、およびエージェント作業用の認証済み pi プロバイダーが必要です。READMEの開発コマンドは、bun install、ホストとWebクライアントを一緒に実行する bun run dev、スタンドアロンCLIアーティファクト用の bun run build:binary、Electrobunアプリ用の bun run desktop:dev / bun run desktop:build です。

Bunへの依存は @photios から反応を引き出しました：「また...なぜbunなのか？！私はちょうどそれをすべてのシステムから追い出し終えたところだ、ハ！普通のpnpmサポートがあればクールだろうね。」

ローカライゼーション

設定→言語は、システム言語または選択した言語に従います。英語と簡体字中国語が組み込まれています。翻訳された en.json を ~/.thinkrail/locales にドロップすることで、ThinkRailがまだ出荷していない言語を追加でき、保存すると適用されます。エージェントの返信とツール出力は、エージェントが書いたままになります。

アナリティクスとプライバシー

ThinkRailは、ランダムなインストールIDに関連付けられた基本的な使用イベント（起動、チャット作成、メッセージ送信、プロバイダー接続）を収集します。使用分析には、プロンプト、コード、ファイル、認証情報、アカウントIDは含まれません。エラーレポートは常に送信され、同じインストールIDに関連付けられ、エラーの種類とコード、およびThinkRail自身のコード内の場所が含まれます。エラーメッセージ、ファイルパス、名前、URL、プロジェクトや拡張機能の内容は含まれません。

追加の製品使用データと、ThinkRailをどのように見つけたかは、「追加の使用データを共有」がオンの場合にのみ共有されます。このスイッチは初回起動時に提供され、設定→プライバシーにあります。thinkrail --no-analytics（または THINKRAIL_NO_ANALYTICS=1 の設定）を実行すると、その実行の追加共有がオフになります。追加共有がオンの場合、パッケージ化されたビルドは、あなたを連れてきたWebサイト訪問にインストールをリンクするために、ThinkRailブログをブラウザで一度開くことがあります — ウェブサイトでマーケティングCookieを受け入れた場合、または同意が不要な場合のみ — リンクは30日後に失効します。

Hacker Newsのコメンテーターが反論した点

議論は概して懐疑的で、いくつかの明確な批判が繰り返されました。

README自体が疑問視されました。 コメンテーターの @exizt88 は次のように書いています：「AI生成のREADMEを持つリポジトリを真剣に受け取ることを拒否します。READMEを書く手間をかけていないなら、他に何をしていないのでしょうか？（Pangramによると100% AIだそうです）」

JetBrainsの他のAI IDEへの取り組みとの重複。 @Deukhoofd は尋ねました：「JetBrainsは最近JetBrains Airをリリースしませんでしたか？これは基本的に同じ前提のように見えますが、実装が異なるだけです。彼らの戦略は何ですか、競合製品を立ち上げているだけですか？」 @rcr-anti は、長年JetBrainsの全製品パックの購読者であり、「プラグインによるすべてのIDEの収束か、Fleetが近づいていたような軽量なユニバーサルエディタのどちらか」を望んでいると述べ、「Airでその方向に行くと思ったが、また殺されてしまった。Airは今ではプラグインだが、それは特定のIDEの話に戻る。」と付け加えました。

ワークツリー＋エージェントパターンは目新しいものではありません。 @sigotirandolas は主張しました：「これらの新しいIDEのポイントがわかりません。それらはほとんどがワークツリー＋サンドボックス＋タブ＋プロンプトであり、これはgit＋docker＋tmux＋思考に過ぎません。しかし、実際にそれらのツールを使い、エージェントをIDEの見解に縛り付けるのではなく学ぶなら、はるかに幸せで効果的になるでしょう。（それが多くの理由でもあります：それほど難しくなく、誰もがそれを理解したときに天才のように感じ、AI時代に履歴書を強化する素晴らしい方法です。）」

分離が不十分です。 @collimarco は書きました：「コンテナの外でエージェントを実行するのは私には狂気の沙汰に見えます... 少なくとも各エージェント/タスクのために別のマイクロVMまたはコンテナを起動するべきです。」

エンタープライズ請求の摩擦。 @hkchad は述べました：「すべてのAI IDEの問題は、ほとんどのエンタープライズ/チームアカウントで使用できず、APIを使用する必要があり、エンタープライズプランよりも最大10倍コストがかかる可能性があることです。私はJetBrainsが本当に好きで、長い間使用してきましたが、今では毎日の99%をitermとsublimeで過ごしていることに気づきます。」

ワークツリー対他のバージョン管理ワークフロー。 @VMG は観察しました：「jjに慣れた翌日に、誰もがgitワークツリーに夢中になったように感じます。」

既存顧客の忠誠心、ただし留保付き。 @dr_faustus は、10年以上JetBrains IDEを使用してきましたが、「複数のワークツリーで同時に作業することは非常にイライラし、無駄が多いため、それらをほとんど開かなくなりました」と述べ、同社のAI戦略を「あちこちに散らばって」いて「不透明で高すぎるトークン」と批判しました。 @throwaw12 は「JetBrainsは死にかけていて、生き残るために必死に努力しているように感じます」と述べ、 @johnhamlin は単に「まだ彼らを応援しています」と書き、 @jwpapi は「試してみる気がある」と述べました。

競合ツールが名前を挙げられました。 @aliasxneo は、「oh-my-piとPaseoを離れるには_強く_説得されなければならないでしょう」と述べました。 @dangoodmanUT はこのリリースを遅ればせながらと位置づけました：「JetBrainsがついに目を覚まし、2024年のCursor競合製品をもう売れないことに気づいたのは素晴らしいことです。JetBrainsが新しいIDEを書くことは大胆に思えます...正しい感じかどうかはわかりません。」

貢献とライセンス

貢献は、リポジトリの CONTRIBUTING.md（チェック、エンドツーエンドスイート、デスクトップパッケージング、リポジトリレイアウトをカバー）および行動規範によって管理されます。ThinkRailはApache License 2.0の下でライセンスされています。