- Phoenix.newは、ElixirとPhoenixフレームワークに特化した完全オンラインのAIコーディングエージェント
- ユーザーはブラウザベースのIDEで、分離された仮想マシンを通じてコードを書き、エージェントとルートシェルを共有できる
- Phoenix.newエージェントはブラウザを直接操作してUIをテストし、コード修正からデプロイ、GitHub連携まで自動化する
- ユーザーはリアルタイムのアプリプレビューとログ監視を通じて開発状況を確認できる
- 多様な言語とフレームワークへの拡張が計画されており、今後の開発ワークフローの変化を予感させる
紹介
- Chris McCordはElixirのPhoenixフレームワークを作った開発者
- 最近Fly.ioで、ElixirとPhoenixでLLMエージェントがPythonやJavaScriptと同じくらいうまく動作する環境を作るため、非公開プロジェクトに注力していた
- そのプロジェクトの成果としてPhoenix.newが公開された
- Phoenix.newは、あらゆる機能を備え、完全にオンラインで動作するElixirおよびPhoenix向けのAIコーディングエージェント
- リアルタイムコラボレーションと高速なプロトタイピングに最適化されたツールとして強調されている
Phoenix.newの主な特徴
- ブラウザ環境で動作しながら、ユーザーとエージェントの両方に、Fly Machineで生成された分離仮想マシンのルートシェルを提供する
- ユーザーはVSCodeスタイルのインターフェースから、意図したとおりにシェルへアクセスできる
- エージェントはPhoenixに特化しており、リアルタイムコラボレーションアプリケーションの要件を理解している
- Phoenix.newはブラウザを内蔵しており、エージェントがこれを「ヘッドレス」で制御してフロントエンドの変更をテストし、操作できる
- スクリーンショットではなく、実際のページコンテンツとJavaScriptの状態を把握できる
ルートアクセス権の利点
- エージェントはユーザーのように直接シェルを開いて開発実験を行える
- 分離されたVM環境のため、
mix.exsにパッケージを追加したり、システムレベルのAPTパッケージをインストールしたりすることもすべて可能
- この構造により、反復的で煩雑な作業のかなりの部分を自動化できる
- 生成されたすべてのアプリは即座にクラウド上で動作し、プライベート共有URL（
.phx.runドメイン）、統合ポートフォワーディング、GitHub連携、Fly.ioのインフラガードレール（仮想化、WireGuard、分離ネットワーク）などを自動提供する
- GitHubの
gh CLIが標準でインストールされており、エージェントはリポジトリの複製・Issueの閲覧・PR作成などのチームコラボレーション作業も行える
- 自動デプロイとテストのループが整っており、アプリ実行からエラー検知・修正までエージェントが処理する
リアルタイムのビルド確認
- Phoenix.newは実際のブラウザを起動してWebアプリケーションをテストする
- フロントエンド機能を追加する際、コードを書いてコンパイルするだけでなく、直接UIを操作しながら、ページとJavaScriptの状態、サーバーログまで同時に確認する
- 独自UIにライブアプリプレビューが組み込まれており、開発や変更の過程をリアルタイムで監視できる
- 複数の
.phx.runタブでも変更内容がリアルタイムに同期される
単なるプロトタイピング以上のことが可能
- すでにWebSocket、Phoenix Presence、実データベースが連携したフルスタックアプリの開発を行っている
- シェルやブラウザでできるあらゆる作業を、エージェントが自動またはユーザーの指示で処理できる
$DATABASE_URLを設定した後のデータベース探索、Ectoスキーマの提案、MySQLクライアントのインストールなどをサポート
- 最新のLLMは広範な知識と汎化能力を持っているため、新しい言語やフレームワークへの拡張も期待できる
- 例: Phoenix LiveViewのTetrisアプリを「その場で」コーディングできた実績があり、今後はRails、React Native、Svelte、Goなども可能とみられる
- システムプロンプトは現時点ではPhoenix中心だが、他言語・他フレームワークへ拡張する意向を示している
非同期エージェント時代の展望
- 開発者のワークフローに大きな変化が起きている時期だと強調している
- 今後の開発は、ローカルシェルでファイルを扱う方式よりも、非同期のCI環境でエージェントが主導する形へ移行すると予想している
- ローカル開発がなくなるわけではないとしても、大半の反復作業はエージェント中心のクラウド環境へ移るだろうとしている
- 実際にPhoenix.newはすでに
phoenix-coreのIssue分類や問題解決PRの作成など、日常業務で使われている
- Chris McCordは、この変化とPhoenix.newの将来的な可能性に興奮と期待を示している
1件のコメント
Hacker Newsのコメント
このサービスは本当に印象的で、ここで最も重要な革新を2つ挙げたい
claude codeをターミナルで実行するときに自動で隔離環境（ローカルまたはリモート）上でエージェントが起動し、その形で並列作業がしやすくなるとよいと思うKasm Workspaces を勧めたい。Docker ベースの Linux デスクトップ環境をリモートで自由に立ち上げられ、AI 開発環境としても非常によく合っている。ホームディレクトリとパッケージ永続化もサポートしている。docker hub リンク、パッケージ永続化に関する Reddit の議論
コンテナ化された環境でエージェントが自由に動き回れることが革新だという意見があるが、本当に革新的なのか気になる
Phoenix の創設者です。気になることがあれば答えます。参考までに、phoenix.new は世界中に分散配置されたグローバルな Elixir クラスターです。たとえばオーストラリアで登録すると、シドニーに IDE とエージェントが割り当てられます
素晴らしい仕事です。Phoenix.new というブランドを見て少し混乱したのですが、これは既存の Elixir Web フレームワークと同じものなのか、それともそれ以上のものなのか気になります
phoenix.flyio.newのような名前のほうがその目的に合っているのではないかPhoenix.new 環境にはヘッドレス Chrome ブラウザが含まれていて、エージェントがそれを操作できると知った。フロントエンド機能を追加するよう命じると、単にコードを書いてコンパイルと lint を通すだけでなく、実際にアプリを起動して UI を操作し、ページ内容、JavaScript の状態、サーバーログまで同時に確認するとのこと。このヘッドレスブラウザとエージェントを Cursor のような環境でローカル実行することも可能なのか気になる
セキュリティポリシーや、ユーザーが提出したコードが学習用に使われるかどうかについての文書を見つけられなかった。関連するセキュリティポリシーをどこで確認できるのか知りたい
アクセシビリティについてどんなアプローチを取っているのか、phoenix.new UI のアクセシビリティテストをしているのか気になる。Phoenix でフロントエンドも書く人が多いので、生成されたフロントエンドのアクセシビリティ評価もしたことがあるのか聞きたい
Fly API を使った隔離環境のプロビジョニングについて、何か知見があれば共有してほしい。私も low-code サーバーレスワークフローシステムで似たアプローチを試している
Elixir が好きで agentic AI の未来を信じている立場からすると、このサービスはとても素晴らしいと思う。コンテキスト管理や使っているモデルについて気になることがある
Phoenix.new が Fly.io の製品なのか、それともその配下のプロジェクトなのかはっきりしない。価格体系も明確に示されているのか気になる。特に Web サービスの永続デプロイに関する追加費用などがどうなっているのか、モバイルではフロントページでそうした情報を見つけにくかった
Elixir が LLM 支援で出遅れるのではないかと心配していたが、こうした取り組みのおかげでその不安がかなり和らいで、とても嬉しい。積極的な試みによって Elixir の未来がより安心できるものになるという信頼感を得た
LLM が Elixir コードをうまく書けないこと自体が、むしろ Elixir 最大の魅力になるかもしれないという冗談めいた考えもしてしまう
Claude が LiveView を含むフルスタック Elixir アプリも非常にうまく生成してくれた経験がある。この点に関するミームは、実態というより印象だと思う
ここ数か月、Elixir コードを書くのに LLM を使っているが、JS ほど完璧ではないにせよ、かなり良いと思う
ここ数週間、LLM を活用して新しいプロトタイプを作っている。主に Zed で GitHub Copilot 経由の Claude Sonnet 3.7 を使っているが、体験は非常に素晴らしい。ときどき古いやり方を持ち出そうとすることはあるが、あまり問題にはならない。LiveView の新機能も簡単に作ってくれる。全体として、Python や Next.js のプロジェクトで感じた生産性と大差ない。主に大衆的でよく知られたパッケージを使っていたので、その恩恵もあったのだと思う。最初に自分で Phoenix プロジェクトを作成してから LLM に任せたら、変な方向に逸れることも減った
Common Lisp で作業している立場からすると、既存コードベースで LLM を補完学習できるとよいと思う。ドキュメントを読むだけでは、コード生成の精度や一般的な問題解決能力は改善しないように感じる
@chrismccord に聞きたいのだが、これは Chris と Fly.io の共同プロジェクトなのか混乱している。アプリを完全に切り離して自分で運用することはできないのか、つまりこれがオープンソースの Phoenix プロジェクトではないという意味なのか疑問だ
LLM が Elixir をうまく扱えないという意見は意外だ。自分は Phoenix/Elixir のサイドプロジェクトで AI ツールをかなりうまく使えた経験がある
私は Elixir でしか LLM を使ったことがないので比較対象はないが、Claude はしばしば見当違いのやり方をするものの、マニュアルを直接読ませればかなりうまく動く
Elixir に対する LLM の実力は確かに以前より良くなったと感じる。単純な Elixir よりも、Phoenix や LiveView のような複雑な作業はまだ難しさがある。どの LLM が Elixir/Phoenix に最も向いているのか気になる
"Sign in with fly.io" をクリックすると決済ページに飛ぶが、$20 の料金に含まれる
Built-In AI Assistanceにどんな機能が含まれているのか詳細がない。ビルド、リファクタリング、デバッグなどの機能が IDE 内で提供されるとあるが、具体的な範囲が知りたい実際に登録して確認したところ、無料トライアルなしでいきなり $20 のサブスクリプションだけが可能な構造だった。使用量制限のようなものも明記されていない
Phoenix.new は強力そうで、ぜひテストしてみるつもりだ。私が夢見ている、BEAM 環境を最大限活用する agentic フレームワークそのものではまだないが、たぶん jido がその役割を果たせるかもしれない