Flue 1.0 Betaをローカルで触ってみたら、Quickstartの一文でいきなり止まった

Astroチームが出しているAIエージェントフレームワーク、Flueの1.0 Betaが出ていたので、正直リリースノートを読むだけでは温度感がつかめず、手元で触ってみました。Agent / Workflow / Channels がひとつのストーリーに揃った、というアナウンスだったので、まずはWorkflowのサンプルコードをそのまま動かすところから始めています。

環境とインストール

Node 22系で、npm install @flue/runtime と npm install -D @flue/cli を素直に叩くだけで詰まりはありませんでした。CLIのバージョンも 1.0.0-beta.1 で固定されており、ここまでは想定どおりです。

いきなりQuickstartと挙動がズレた

公式のスタートプロンプトは「npx flue init を実行してプロジェクトを作る」という体験を前提にした書き方になっています。ところが実際に打つと、こうなりました。

Missing required --target flag for init command.

--target node か --target cloudflare を明示しないと先に進めない仕様です。エラーメッセージ自体は親切で、使い方一覧もそのまま表示されるので詰まりとしては軽いのですが、「コピペしたプロンプトをコーディングエージェントに渡すだけで動く」という訴求とは、初手で少しズレている印象を受けました。--target node を付けて通したところ、生成されたのは次のだけの薄い flue.config.ts でした。

import { defineConfig } from '@flue/cli/config';

export default defineConfig({
	target: 'node',
});

エージェントやワークフローのひな型自体は生成されないので、init はあくまで設定ファイルの土台作りに役割が絞られている、という理解で進めました。

Workflowサンプルはビルドまで素直に通る

ブログ記事内の summarize ワークフローのサンプルコードを src/workflows/summarize.ts にそのまま置いて flue build --target node を叩くと、ワークフローが自動検出され、ビルド自体は問題なく完了しました。CLIが src/workflows 配下を規約として読みにいく作りになっている点は、Astroのファイルベースルーティングに近い感覚で、違和感なく馴染みました。

ただしビルド時に MODULE_TYPELESS_PACKAGE_JSON の警告が出ています。package.json に "type": "module" を足していないとesm判定の再解析が走る、というNode側の一般的な注意ですが、betaのテンプレート自体がこの一手間を埋めていない点は、初回体験としては惜しいと感じました。

実行はAPIキー未設定で意図どおり止まる

flue run summarize --target node --payload '{"text": "..."}' を実行すると、ローカルでrun IDが発行され、SQLiteを使った実行管理が動いていることが分かるログが出ます。その後、想定どおり次のエラーで止まりました。

Error: Workflow failed: [internal_error] prompt failed: No API key for provider: anthropic

ここはAPIキーを渡していない自分の検証環境の都合なので不具合ではありません。注目したのは、エラーに至るまでの過程でrunごとのIDが見えたことです。記事中で説明されている「Durable Streamsによる追記専用ログを正とする」という設計が、ローカル実行の時点から実際に機能している様子がうかがえました。ただし、このログが具体的にどこにどう永続化されるのかまでは、今回の短い検証では追い切れておらず未検証です。

docsコマンドはオフラインで実際に効く

地味に良かったのが flue docs です。npx flue docs を打つだけで、APIリファレンスやチャンネル別ドキュメントなど110ページ分の一覧がオフラインで返ってきました。コーディングエージェントに作業させる前提のフレームワークなら、ネット越しに毎回ドキュメントを取りに行かせるより、こうしてローカルに検索可能な形で持たせておくほうが、エージェントの調査コストを下げる設計として筋が良いと感じます。

まとめ

短い時間での検証なので踏み込めた範囲は限定的ですが、initとbuildの間にQuickstartの体験とCLIの実仕様で小さなギャップがあること、ビルド自体はサンプルコードそのままで問題なく通ること、実行管理の土台にDurable Streamsらしき仕組みが見えることまでは確認できました。Agent側のサンプル（tools / skills / sandbox を絡めたフルセット）はAPIキーを用意したうえで別途試したいので、続きはまた別の記事にします。