私はもうJetBrains IDEをメインにしていないのですが、PHPにかんしてはやはりVSCodeよりPHPStormに一日の長があり、IntelliJに返り咲けるチャンスを伺っているわけです。

今まではGooseのJetBrains MCP拡張を入れて試していたのですが、こいつはCline以上の暴れ馬ですべてを焼き尽くしてしまうので、人には勧めづらかった。

そこでClaude Codeがリリースされました。これは順当に良さそうで、MCPに対応していたので、Gooseのように連携できるなと睨みました。

検証結果をZennに投稿。この環境でしばらく過ごしてないのでまだなんとも言えないのですが、同士は試してみてほしい。

JetBrains IDEとClaude Codeを連携させて擬似Clineにする

Zennlaiso

その翌日、なんとなくHackerNewsを徘徊していて発見したのがFirebender。これはブログの記事にしました。Androidアプリを作って操作させてみたところ、最低限の期待は上回るできだったので、今後も引き続き使ってゆきたい。

Firebender: ついに登場したIntelliJプラグイン版コーディングエージェント

迷えるJetBrainsユーザー向けの朗報、VSCode偏重だったコーディングエージェント界に一石を投じる。 Firebenderとは FirebenderはAndroid Studio向けのAIコーディングアシスタント。Y Combinatorから出資を受けたスタートアップで、KevinとAmanの二人を中心に開発されている。 Firebender - Most powerful AI assistant in Android StudioWrite code 10x faster with Firebender, the most powerful AI assistant for Android Studio. コード補完、チャット、エージェントによる自律的なコーディングタスクの機能を持っている。2024年のリリース当初は「Android Studioに特化したGitHub Copilotより高速なコード補完」として開発されていたが、2025年になってCursorやCopilot Editsのようなエージェント機能を搭載してアップデートされた。 IntelliJプラグ

laisolaiso

世間は空前のMCPブーム

いつの間にか日米タイムラインでみんなMCPサーバー活用の話を熱心にしていた。何がきっかけなのか未だに不明だけど、1月に私がMCPの話をしていた時の周りの引きの弱さからすると感慨深い。なんか推し技術が巣立っていった感傷がある。

私自身はMCP活用はアーリーアダプタたちのようにはうまくできてなくて、前述のGooseやDiveで遊んだり、自作コーディングエージェントの裏側にしていたり、Claude Codeなどの対応ツールのコードを読んだりする程度です。

anthropic-ai/claude-codeを読む

laisoさんのスクラップ

Zennlaiso

Clineで遊ぶ

私にとってClineは実コーディングというより中身を読んで遊ぶおもちゃという感じなんですけど、今週も色々試しました。

まずClineのWebサービスがはじまっていたのでサインアップして課金しました。これはOpenRouterのようなLLMのAPIを代理販売するサービスです。

次にClineが本当に内部Tree-Sitterツールを呼び出しているのか検証。定義してあるけど発動したことないToolナンバーワンなので気になっていました。結果、巨大なファイルをわざと読み込むように誘導したら使っていました。

ソースコードの文書解説では、Claude 3.7 Thinkingにしたら思いのほかそれっぽい文章を吐いてきたので、読みたい記事はもうこれで自給自足すればいいじゃんという気になりました。

外部にポストするなら周辺情報をもっと読みこんで書き直すことになるから、それは置き換えられないんですけど。

一旦Pythonを書いてからRustに清書する話

敬愛するMitsuhiko氏のブログを読んでた時に見かけた話です。出てきた話題を投稿したら広くシェアされました。エージェントがRustやTSの静的解析を延々と直し続けるループに思い当たることがみんなあるのか、共感している人が多かったです。私としてはRustもPythonもどっちもトップクラスに書ける人が言ってることに注目していました。

How I Use AI: Meet My Promptly Hired Model Intern

Due to popular request: my use of LLM explained.

Armin Ronacher's Thoughts and Writings

Now it's not great at all languages. I find it performs exceptionally well at Python, somewhat okay at JavaScript and horrible at Rust. However, particularly if I wanna solve an algorithmic problem, I can often iterate in Python until I have what I want, then ask it to translate it to Rust. That's from my experience at least a decent way to get going quickly on some harder problems.
今、それはすべての言語で素晴らしいわけではありません。私はそれがPythonでは非常に優れており、JavaScriptではまあまあ、Rustではひどいと感じています。しかし、特にアルゴリズムの問題を解きたい場合、Pythonで繰り返し試して望むものを見つけた後、それをRustに翻訳するよう頼むことがよくあります。少なくとも私の経験からすると、それは難しい問題に素早く取り組むためのまずまずの方法です。

prompt-tsxとは

GitHub - microsoft/vscode-prompt-tsx

Contribute to microsoft/vscode-prompt-tsx development by creating an account on GitHub.

GitHubmicrosoft

@vscode/prompt-tsxはVSCode拡張で利用できるライブラリで、Copilot Chat向けの@コマンドで呼び出すエージェントの開発や、それ以外のLM APIを使った拡張とともに使うことができる。

利用イメージ

以上のようにLM APIに渡すパラメータをTSX（JSX）コンポーネントとして管理する。

prompt-tsxが必要な背景

prompt-tsxが必要な背景だが、なぜわざわざTSXで書けるようにしたのかというと、リポジトリの“Why TSX?”にはこう書かれている。

なぜTSXなのか？

AIエンジニアとして、私たちの製品はテキストプロンプトで構成されたチャットメッセージを使用して、大規模言語モデルと通信します。Copilot Chatの開発中に、単純な文字列だけでプロンプトを構成するのは扱いにくく、不満の多いことであるとわかりました。

私たちが遭遇した課題には、以下のようなものがあります。

1. プロンプトの構成に、プログラム的な文字列連結またはテンプレート文字列のいずれかを使用していました。プログラム的な文字列連結は、プロンプトテキストを時間の経過とともにますます読みにくく、保守しにくく、更新しにくくしました。テンプレート文字列ベースのプロンプトは硬直的で、不要な空白などの問題が発生しやすかったです。

2. どちらの場合も、私たちのプロンプトとRAGによって生成されたコンテキストは、モデルをアップグレードするにつれて変化するコンテキストウィンドウの制約に適応できませんでした。プロンプトは最終的に単なる文字列であるため、文字列連結で構成された後に編集することが困難でした。

チャットメッセージに入れる会話のプロンプトというのは抽象化すると (ROLE, MESSAGE) のタプルのリスト構造データだ。それがモデルに到達するまでには最終的に独自形式のテキストに変換される。

しかし我々が直接触っているのはLLMのプロバイダーが提供するSKDのAPIが基本になる。一般的なのはOpenAI SDKでお馴染みの会話形式のデータを表現するテキスト生成のChat Completion APIがある。

現在の方法ではこれに渡すMESSAGE部分のテキストデータをあの手この手で、連結や分岐で動的に処理している。

そしてこのテキストはユーザーが入力した内容とイコールではない。まず開発者が用意する事前のシステムプロンプトと呼ばれるテキストがあり、これは設定や状態によって動的に変形することがある。会話の経過中にLLMに呼び出し指示されたツール（外部呼び出し）の結果を「ユーザーの入力」としてプロンプトに乗せることもある。そこに最終的にユーザー自身の発言を組み合わされてはじめてLLMのAPIに渡されるメッセージになる。

これは一定の形式を持つプレーンテキストの構造化データで、何かに似ている。そう、ウェブアプリのHTMLの構築だ。プロンプトの組み立ては現在、ステートフルなHTMLの組み立てに近づいている。なのでTSXの出番になる。

prompt-tsxのようなTSXでメッセージデータ構造を変換するアプローチによって、従来のフロントエンド開発で利用するTSXの利点を享受できる。TypeScriptとして型サポートが付くし、ツリー構造で全体の構造を分割できる。コンポーネントを純粋な関数化することもできるし、依存する値を引数にして分離もできる。つまり複雑な動的生成するプロンプトにも作用する。

（余談だが、複雑な動的プロンプトを構築する例としては、Jina AIのリポジトリにあるコードを例としてあげる。これはAgent系ではまだシンプルな方だ）

なぜVSCode専用なのか

prompt-tsxがVSCode拡張専用と前に述べた。なのでNode.jsスクリプトで利用したり、ブラウザで動かしたりできない。これはVSCodeのLM API向けのライブラリだからだ。独自調査によると公式Copilot Chat拡張のコードの中にも依存として入っている。ドキュメントが以下にある。

Chat extensions

A guide to creating an AI extension in Visual Studio Code

MicrosoftMicrosoft

prompt-tsxのレンダラーは入力としてTSXを受け取るが、変換先はLM APIに渡せるデータ構造である。つまりプレーンテキストにはしない。

LM APIとの統合による強い制約は特にないので、移植できる可能性もありそうだ。

TSXからオブジェクトへの変換は素直にJSXファクトリ関数で行うし、レンダラーの返すオブジェクトをOpenAIやAnthropicのSDK互換にすれば、VSCodeの外でも使えるものを再実装できるはず。

ただ、prompt-tsxについてはユーティリティ系関数でVSCode依存が多々存在する。トークン数計算などは内部でLM APIを呼び出す。このレンダラーには全体のプロンプトから送信するモデルの最大入力トークン上限に対する予算を作って、priorityを基準に削除する。古い会話履歴などは優先度が低いので消えてゆく。つまり入力トークンが増える（長い会話や大きいファイルの参照、ツール呼び出しが増えるタスク）と中身が圧縮されていくというのを、我々Copilotユーザーとしては知っておくといいだろう。

追記：元ネタ情報（priompt）

投稿後にprompt-tsxの基礎となるアイデアを実装していたpriomptについて教えてもらった（ryoppippiさんに感謝）

GitHub - anysphere/priompt: Prompt design using JSX.

Prompt design using JSX. Contribute to anysphere/priompt development by creating an account on GitHub.

GitHubanysphere

prompt-tsxのアルファリリース時にも言及されているのでこれが元ネタになってることでまちがいないだろう。

priomptはVSCodeへの依存がなくNode.jsとOpenAIのSDK向けにデザインされていた。しかし実験的なプロジェクトでアップデートは熱心にされていないようだった。

筆者としてはVercel AI SDKあたりにこのTSXでプロンプトを書く機能が備わっているとありがたい。他に興味ある人はいるだろうか。

Firebenderとは

FirebenderはAndroid Studio向けのAIコーディングアシスタント。Y Combinatorから出資を受けたスタートアップで、KevinとAmanの二人を中心に開発されている。

Firebender - Most powerful AI assistant in Android Studio

Write code 10x faster with Firebender, the most powerful AI assistant for Android Studio.

コード補完、チャット、エージェントによる自律的なコーディングタスクの機能を持っている。2024年のリリース当初は「Android Studioに特化したGitHub Copilotより高速なコード補完」として開発されていたが、2025年になってCursorやCopilot Editsのようなエージェント機能を搭載してアップデートされた。

IntelliJプラグインとして提供されているので、Android Studio以外のJetBrains IDEでもインストールできる。筆者はIntelliJ IDEAにもインストールして動作することを確認した。わざわざ「Android Studio向け」としているのは、ユーザーの多い環境にフォーカスするためではなかろうか。

デモ

IntelliJ IDEAでKotlinのコマンドラインツールのプロジェクトを作成した。

まずは既存のHello WorldをFirebenderチャットウィンドウ経由の指示でFizzBuzzに書き換えてもらう。

次に、複数段階の処理やコマンド実行ができるかを試す。FizzBuzzを関数に切り出すリファクタリングを行い、テストコードを記述し、Gradleで実行して成功することを確認してもらう。

このような単純なフローなら何もつまづくことなく実施できた。

さらに、創業者Kevinの動画チャンネルではより高度なデバッグを披露しているので確認してほしい。ここでは、Jetchatという定番のJetpack Composeのサンプルチャットアプリの動作を修正している。

Agent - Firebender

Command the smartest models to edit and run your code directly

Firebender

背景

少し前提に立ち返って、なぜこれが待望されていたのかという背景を説明する。

コード補完やチャット機能は、既にIntelliJ向けのGitHub Copilotプラグインで実装されているが、Copilot Editsによるエージェント機能はまだ搭載されていない。なんせVSCode版のGitHub Copilotでもこの機能はプレビュー段階に留まっており、GitHub側では優先度が低いのだろう。

しかし、2024-2025年にかけて、世の中は空前のコーディングエージェントブームを迎えている。開発者たちは「vibe coding」に舌鼓を打ったり、魂が震えるような体験を求めている。

バイブスでコーディング

Andrej Karpathy（OpenAI共同創業者）がXで提唱した“vibe coding”の概念が、現在のAIエージェントを使った「ノリや雰囲気、感性」などを重視したコーディングスタイルをうまく言語化していて面白い。 There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are

laisolaiso

だが、これらのツールはどれもVSCodeをベースにしたものばかりで、JetBrains IDE系にはまだ上陸していない。

そのため、JetBrainsユーザーからは、CursorやClineのような開発体験を提供するプラグインが強く望まれていた。Android StudioもIntelliJベースなので、同じ事情が当てはまる。ついでに言うと、VimやNeoVimのユーザーたちも、同等のツールを欲しがっているようだ。

さらに、コミュニティの特性として、サーバーサイドのJava、Scala、Kotlinの開発者たちはVSCodeユーザーが少ない傾向にある。MicrosoftやVSCode側からのサポートも手薄だし、JetBrainsから見ればVSCodeは競合製品なので、これらの言語に対するVSCode側への支援もほとんど期待できない。

そこに至って、Firebenderの登場は大いに歓迎すべきものだろう。

プロジェクトのステータス

とはいえFirebenderはプロジェクトとしてはまだ初期段階にある。

謎めいた挙動をする部分も多く、例えば現状最初にメールアドレスを入力するだけで最新のGPT 4.5やClaude 3.7モデルが無料で利用できる。普通に考えると会社のキャッシュを燃やしている。一定以上使うと制限がかかるのかもしれない。

ビジネスプランもまだ不透明だ。ランディングページ（LP）を見ると、無料プランとエンタープライズプランが明記されているが、エージェント系の機能についてはまだ詳細が書かれていない。

セキュリティについては入力したメッセージやソースコードは一度Firebenderのサーバーに送信されるという。プライバシポリシーには「受信したデータを保存せず、すぐに破棄する」と記載されている。これは一般的なコーディングツールと同じレベルのポリシーではあるが機密情報を含むコードベースではまだ利用はしない方がいいだろう。

今後の展開としては、このままFirebenderが成長して普及するのか、Copilot Editsが安定してIntelliJプラグイン版にも対応するのか、あるいはJetBrains製の公式エージェントが大逆転するのか、​が楽しみなところだ。

以下はエージェント機能リリース時の創業者Kevinの投稿で。ロードマップが端的に説明されている。

スレッド要約：未来のAndroid開発は、コード作成、バグ修正、FigmaデザインからのUI実装を自律的に行うマルチエージェントシステムによって実現され、Firebender 0.9.6がその可能性を証明しています。このエージェントは過去1週間で100万行以上の承認済みコードを書き、1日あたりユーザーごとに約800行のコードを作成しました。今後6か月で、Android Studioとの統合を強化し、Composeプレビューの再レンダリングを直接利用する機能を改善するほか、複数のエージェントが並行して作業しながらエンジニアのフローを維持するマルチエージェント問題の解決を目指します。この新しい領域でフィードバックをくれたAndroidエンジニア全員に感謝し、まだ初期段階ではありますが、無料で試せるのでぜひ体験してほしいです。

翻訳：新しい種類のコーディングがあって、私はこれを“vibe coding”と呼んでいます。そこでは完全に“vibe（雰囲気、直感）”に身を任せ、指数関数的成長を歓迎し、コードそのものが存在していることさえ忘れてしまいます。これは、LLM（例えば、Cursor ComposerとSonnet）があまりにも優秀になってきたから可能になっています。また、SuperWhisper(音声をテキスト変換するアプリ)を使ってComposerと話すので、キーボードをほとんど触る必要がありません。『サイドバーのパディングを半分に減らして』みたいな、めちゃくちゃ簡単なリクエストを投げることもあります。面倒くさがりなので自分で探すのが億劫なんです。差分（diffs）ももう見ません、常に『すべて受け入れる（Accept All）』です。エラーメッセージが出たら、コメントも付けずにそのままコピー＆ペーストするだけです。たいていそれで問題が解決します。コードは私の通常の理解を超えるほど成長しますが、しっかり読み込む必要があるのでしょう。時々LLMがバグを修正できないこともありますが、その場合は迂回するか、ランダムな変更を加え続けるまで試します。週末の使い捨てプロジェクトには悪くありませんが、かなり面白いです。私はプロジェクトやウェブアプリを“構築”しているわけですが、実際にはコーディングしているわけではなく、ただ見たり、言ったり、実行したり、コピー＆ペーストしたりしているだけです。そして、ほとんど問題なく動きます。

vibe codingはコーディングでは以下のような方針で行う

• 自力でコードを書こうとせずにAIに指示をするだけ
• AIが提案したコードはノールックマージ
• 上手くいかなかったらエラーメッセージガチャを回す

最初これを皮肉で言っているのか？　と思って読んだがどうやらそうではないらしく自身でもこれを実践しているらしい。以下が実際に作ったアプリ。LLMが読んでる書籍の説明をしてくれる。

翻訳：先ほどの約1時間で、カスタムなLLMリーダーアプリを構築しました。『国富論』を読みながら、どの段落でも質問できるようにするためです。段落をクリックして『Ask（質問する）』を押すと、LLMが呼び出され、段落のコンテキストウィンドウを構築します。そこには、章全体、該当段落、そして質問をコピー＆ペーストして含めます。すごくうまく動きます。

私が以前にClineやAI搭載エディタユーザーのことを「勢いやノリで開発している」とか「高速にコピペプログラミングを自動化している」と評したことがあったが、それがピースなAIのバイブスでポジティブに表現されていて流石だ。

この投稿を受けて各所で関連ポストが発生していた（キャッチーな名前がついてプチバズったことで議論が進むやつ）。その中で私が注目したのはWhat is Vibe Coding? How Creators Can Build Software Without Writing Codeで紹介された「Cursorで１００個のミニツール作った」と自称するjustbuildthings.comのストーリー。これは作者がコーディング・スキルゼロのところから極めて短期間で開発して、結果としてproducthuntで３位を獲得したらしい。どの時点で今の完成度に至ったのか不明だがよくできている。

このようなAIエディタを使ったvibe codingを好む層は、過去にはノーコードツールに夢中になっていた人たちと重なる。私はノーコードを「クラウドプラットフォームが提供する”設定ブロック”を使ったGUIプログラミング」と理解していたが、それが発展したカタチが今のvibe codingなのかもしれない。

しかし今度はコードは存在し、プログラミングは薄れている。プログラミングとは何かという問題になる。とりあえずノーコードツールからエクスポートされたコードよりはバイブスで作成されたアプリケーションの残骸コードの方が保守しやすいだろう。