はじめに

生成AIの活用は、チャット画面で人間が都度プロンプトを投げる段階から、AIがツールを使い、ファイルを読み書きし、外部サービスと連携しながらタスクを進める段階に移りつつあります。

ただし、業務で使えるAIエージェントを作るには、LLM APIを呼ぶ関数だけでは足りません。エージェントごとの状態管理、ツール呼び出し、サンドボックス、SlackやGitHubなどからのイベント受付、復旧、ログ、監視、フロントエンドやSDKからの操作、デプロイ先の選択まで必要になります。

Flueは、こうした「AIエージェントをアプリケーションとして動かすための土台」をTypeScriptで提供するフレームワークです。公式サイトでは「The Open Agent Framework」と説明され、耐久性のあるAIエージェントやワークフローを作り、任意のLLMを使い、どこにでもデプロイできることを掲げています。

Flueとは

Flueは、AIエージェントを構築するためのTypeScriptフレームワークです。公式ドキュメントでは、Claude Codeなどのコーディングエージェントで使われているような harness-driven architecture を、任意のモデルで利用できるようにするものだと説明されています。

ここでいうharnessは、モデルに対して、指示、ツール、スキル、セッション、ファイルアクセス、サンドボックスなどをまとめて与える実行環境のようなものです。従来のLLM API利用では、開発者がAPI呼び出しの順番や中間結果の受け渡しを細かく書くことが多かったと思います。

Flueが重視しているのは、モデルに手順を直接スクリプトすることではなく、モデルが作業できる環境を構成することです。

何が嬉しいのか

Flueの価値は、AIエージェントを一回限りのLLM呼び出しではなく、継続的に動作するソフトウェアとして扱える点にあります。

たとえば、GitHub Issueを受け取って、バグを再現し、原因を調査し、修正案を作り、検証して、結果をIssueに返信するエージェントを考えます。この場合、必要なのは「LLMに質問する関数」だけではありません。

• リポジトリを読む
• ファイルを変更する
• テストを実行する
• GitHub APIを呼ぶ
• 作業途中の状態を保持する
• サーバー再起動後も受け付けた作業を失わない

Flueは、このような「実作業をするAIエージェント」に必要な構成要素を、Agents、Workflows、Sandboxes、Durable Execution、Subagents、Tools、Skills、MCP Servers、Observability、Chat連携などとしてまとめています。

AgentとWorkflowの違い

Flueには大きく分けて、AgentとWorkflowという2つの重要な概念があります。Agentは、継続的なコンテキストを持ち、自律的に問題を解くためのものです。一方、Workflowは、明確な入力から明確な出力まで、開発者が定義した手順に沿って実行する構造化された自動化です。

Flue 1.0 Betaの発表では、Agentsはオープンエンドな問題を自分で解き、Workflowsは開発者が定義した正確な手順を実行するものとして説明されています。

問い合わせ内容を読んで分類するだけならWorkflowで十分かもしれません。しかし、関連ログを調べ、過去Issueを検索し、必要なら修正PRまで作るような処理はAgentのほうが向いています。Flueでは、この2つを同じ基盤上で組み合わせて使えます。

基本的なコードイメージ

Flueでは、AgentをTypeScriptのファイルとして定義します。公式ドキュメントの例では、src/agents/ 配下のファイルに defineAgent() を使ってエージェントを定義します。ファイル名がエージェント名になり、HTTPエンドポイントやCLIから呼び出せるようになります。

import { defineAgent } from '@flue/runtime';
import { local } from '@flue/runtime/node';

export default defineAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  instructions: 'Review the requested change and report only findings supported by evidence.',
  tools: repositoryTools,
  skills: [reviewChecklist],
  sandbox: local(),
}));

ここで定義しているのは、単なるプロンプトではありません。モデル、指示、ツール、スキル、サンドボックスなど、エージェントが作業するための環境そのものです。

Durable Agents：落ちても続きから再開する

実運用でエージェントを動かす場合、サーバー再起動、デプロイ、接続切断、LLMプロバイダのタイムアウトなどは普通に起こります。そのたびに作業中のエージェントが消えてしまうと、業務では使いづらいです。

Flueは、会話、モデルの出力、ツール呼び出し、ツール結果などをdurable streamに記録し、プロセスが落ちたあとでも復旧できるように設計されています。公式ドキュメントでは、Agentは継続的で状態を持つコンテキストであり、各Agent instanceがcanonical conversation streamを持つと説明されています。

Cloudflareでは、Agent instanceごとにDurable Objectを使い、受け付けたプロンプトや非同期dispatchを同じ順序付きキューに入れる構成になります。接続が切れてもバックエンド処理は継続でき、クライアントはdurable offsetから再接続できます。

Node.jsで使う場合は注意が必要です。db.ts を用意しない場合、NodeではプロセスローカルのインメモリSQLiteが使われるため、プロセス再起動で会話や受け付けた作業の状態が失われます。永続化したい場合は、durable adapterを設定する必要があります。また、複数Nodeレプリカで同じAgent instanceを同時に所有する構成は安全ではなく、1つのlive ownerにルーティングする必要があります。

Sandboxes：安全な作業場を与える

AIエージェントが実作業をするには、ファイルを読んだり、コマンドを実行したり、コードを変更したりする場所が必要です。FlueはSandboxesを提供しており、エージェントに安全な作業環境を与えられます。

この考え方は、Claude CodeやCodexのようなコーディングエージェントに近いです。ただし、重要なのは、サンドボックスのファイル状態と会話の永続化は別物だという点です。会話を永続化しても、サンドボックス内のファイルが自動的に永続化されるわけではありません。

Channels：SlackやGitHubから呼び出す

Flueの面白いところは、エージェントをHTTPやCLIだけでなく、Slack、GitHub、Linearなどのイベントから起動するためのChannelsという仕組みを持っている点です。

Flue 1.0 Betaの発表では、ChannelsはSlack、GitHub、Linearなどの外部ソースとエージェントを接続し、イベントの受信や検証のボイラープレートを扱うものとして説明されています。これにより、AIエージェントをチャットUIの中だけの存在ではなく、業務イベントに反応するアプリケーションとして配置できます。

• Slackでメンションされたら社内ドキュメントを調査して回答する
• GitHub Issueが作成されたら再現調査を開始する
• Linearのチケット更新をトリガーに仕様確認を行う
• Stripe webhookを受けてサポート調査を開始する
• GitHubやGitLabのMRに対してレビュー観点を生成する

Tools、Skills、Subagents

Flueには、エージェントに能力を与えるための概念としてTools、Skills、Subagentsがあります。

複雑な業務では、1つの巨大なエージェントにすべてを任せるより、調査担当、コードレビュー担当、テスト実行担当、セキュリティ確認担当、ドキュメント作成担当のように役割を分けるほうが扱いやすくなります。Subagentsは、単なる高速化というより、コンテキスト分割、役割分担、専門性の注入に近い設計です。

Observability：監視とトレース

AIエージェントを本番運用するなら、何が起きたかを追えることが重要です。FlueはObservability機能を持ち、OpenTelemetry、Braintrust、Sentryなどへのテレメトリ出力をサポートしています。

エージェントは通常のアプリケーションよりも挙動が予測しづらいため、どのプロンプトで起動したのか、どのツールを呼んだのか、どの外部APIにアクセスしたのか、どこで失敗したのか、復旧時にどこから再開したのか、コストがどれくらいかかったのかを追える必要があります。

Open by default：ロックインしない設計

Flueの設計原則の1つに「Open by default」があります。公式ドキュメントでは、Flueはモデル、サンドボックス、デプロイ先の各レイヤーでオープンであり、特定のモデル、特定のサンドボックス、特定のクラウドに閉じないことを重視していると説明されています。

• Open models：任意のサポート済みLLMプロバイダを接続できる
• Open sandboxes：組み込みvirtual sandboxやリモートsandbox providerを選べる
• Open deploys：Node.js、Cloudflare、GitHub、GitLabなどにデプロイできる

AIエージェント基盤は、一度作ると周辺システムとの結合が強くなりがちです。特定ベンダーのモデル、実行環境、クラウドに閉じると、後から移行しづらくなります。Flueは、そのロックインを避けつつ、TypeScriptでエージェント基盤を作れることを狙っているように見えます。

AI-firstな開発体験

Flueの特徴として面白いのは、最初から「開発者がコーディングエージェントと一緒に使う」ことを前提にしている点です。Getting Startedでも、まず https://flueframework.com/start.md を読ませて、コーディングエージェントに最初のAgent作成を手伝わせる流れが推奨されています。

Flue 1.0 Betaの発表でも、flue add はMarkdown blueprintをコーディングエージェントに渡し、エージェントが実際のコードベースを理解しながら統合を進める設計だと説明されています。従来のCLIやcodemodよりも、AIが既存コードの文脈を読んで統合する前提に寄せている点が象徴的です。

導入方法の概要

Flueを手動で導入する場合、Getting Startedでは次のような手順が示されています。Node.jsは >=22.19.0 が必要です。また、利用するLLMプロバイダのAPIキーやモデル指定が必要になります。

npm install @flue/runtime
npm install --save-dev @flue/cli
npx flue init --target node

最小のAgentは、次のように defineAgent() で定義できます。

import { defineAgent } from '@flue/runtime';

export default defineAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  instructions: 'Tell a funny "hello world" engineering joke.',
}));

実行はCLIから行えます。

npx flue run hello-world --input '{"message":"Tell me a joke."}'

どんな用途に向いているか

Flueは、単純なチャットボットよりも、業務システムや開発ワークフローに深く入り込むAIエージェントに向いています。

1. GitHubやGitLabのIssue、MRをトリガーにして、調査、コードレビュー、テスト実行、修正提案を行う開発支援エージェント
2. SlackやTeamsから質問を受け取り、社内ドキュメント、リポジトリ、チケット、ログなどを調べて回答する問い合わせ対応エージェント
3. 仕様書、コード、Issue、テスト結果を横断して、仕様確認やQA観点の洗い出しを行うQAエージェント
4. Slack、GitHub、Linear、Stripeなどのイベントを起点に、AIが必要な確認や処理を進める業務イベント駆動の自動化

注意点

Flueは面白いフレームワークですが、導入時には注意点もあります。Flue 1.0 Betaは2026年6月16日に発表された段階であり、公式記事でもstable 1.0に向けてpolish、documentation、feedback対応を進める段階だと説明されています。breaking changeは減るが、まだ発生しうるとも書かれています。

そのため、今すぐ基幹業務に深く組み込むというより、まずは検証や社内向けPoCから始めるのがよさそうです。また、Node.jsで耐久性を持たせる場合は、永続化アダプタや単一オーナー制約を理解する必要があります。

Flueは土台を提供してくれますが、業務システムとして安全に使うための権限管理、監査、承認フロー、副作用の扱いは別途設計する必要があります。

まとめ

Flueは、AIエージェントを「LLM APIを呼ぶスクリプト」ではなく、「状態を持ち、ツールを使い、サンドボックスで作業し、外部イベントに反応し、監視されながら動くアプリケーション」として構築するためのTypeScriptフレームワークです。

• AgentとWorkflowを使い分けられる
• harness-firstの思想で、モデルに作業環境を与える
• Sandboxesで安全な作業場を用意できる
• ChannelsでSlack、GitHub、Linearなどと接続できる
• Durable Agentsにより、作業途中の復旧を意識している
• Tools、Skills、Subagentsで複雑な業務を構成できる
• OpenTelemetryなどによるObservabilityを備えている
• Claude CodeやCodexのようなコーディングエージェントとの併用を前提にしている

個人的には、Flueは「AIエージェント版のアプリケーションフレームワーク」に近い存在だと感じました。LangChainのようにLLMアプリケーションの部品をつなぐというより、Claude CodeやCodexのようなエージェント体験を、自社アプリケーションや社内業務に組み込むための実行基盤に見えます。

最初のPoCとしては、Slack mentionに反応してドキュメントを調査するAgent、GitHub Issueを読んで再現手順と調査方針を返すAgent、MR差分を読んでQA観点を出すAgent、仕様質問に対してコードとドキュメントを横断して回答するAgentなどが向いていそうです。