Flue徹底解説｜Astroチーム発、自律エージェントの『ハーネス』フレームワーク

最初のAIエージェントは、LLMのAPIを直接叩いて作られていました。単純なチャットボットや、決められた手順をなぞるスクリプトなら、それで十分でした。しかしClaude CodeやCodexのような「本物のエージェント」——手順ではなくゴールを与えれば、文脈とツールを使って自律的にタスクを完遂するエージェント——を作ろうとすると、話はまるで違ってきます。セッションの継続、ツールの呼び出し、ファイルシステムへのアクセス、そして安全に動かすためのサンドボックス。これらを束ねる「土台」を、一から自前で組むのは骨が折れます。

その土台を、フレームワークとして提供しようとするのが、本記事で解説する Flue（フルー） です。意外なことに、開発元は静的サイトフレームワークで知られる Astro チーム（withastro）。TypeScript・Apache-2.0ライセンス・GitHub約6,900スターのこのプロジェクトは、自らを「The Agent Harness Framework（エージェント・ハーネス・フレームワーク）」と名乗り、冒頭でこう宣言します——「Not another SDK.（また別のSDKではない）」。

「ハーネス（harness）」とは、当サイトでも繰り返し取り上げてきた、エージェントを動かすための実行環境一式を指す言葉です。馬具の「ハーネス」が馬の力を引き出しつつ制御するように、AIのハーネスはモデルの能力を引き出し、安全に実作業へ向かわせます。Claude Code自身も、本質的には強力なハーネスの一例です。Flueは、このハーネスをTypeScriptでプログラム可能な形にし、自律エージェントと強力なAIワークフローを構築できるようにします。Webフレームワークの設計で培われたAstroチームの知見が、AIエージェントの世界にどう持ち込まれたのか——その全体像を、公式情報をもとに読み解きます。

当サイトのAIエージェント基盤の全体像は AIエージェントフレームワーク比較ガイド2026 でも整理しています。あわせてどうぞ。

1. Flueとは — 「SDKではなくハーネス」という宣言

Flueの自己紹介で最も重要なのは、「SDKではない」という線引きです。では、SDKとハーネスは何が違うのでしょうか。

一般的なエージェントSDKは、「LLMを呼ぶ」「ツールを定義する」といった部品を提供します。開発者はその部品を使って、エージェントを動かすループや環境を自分で組み立てます。便利ではありますが、結局のところセッション管理も実行環境の安全性も自前で用意することになり、本番運用に必要な土台づくりは各チームの宿題として残ります。一方ハーネスは、その実行環境一式——セッション管理、ツール、スキル、指示（instructions）、ファイルシステムアクセス、安全なサンドボックス——を最初から備えた「土台」です。Flueの主張は明快です。「どんなモデルにも、真に自律的な作業に必要な文脈と環境を与える」のがハーネスの役割だ、と。

公式READMEのコード例を見ると、その設計思想がよく分かります。バグ報告をエンドツーエンドで処理するエージェント（再現→原因診断→意図の検証→修正の試行）が、わずかな宣言的コードで定義されています。手順を1つずつ書き下すのではなく、エージェントに「ゴールと、それを達成するための道具立て」を渡す——この書き味が、Flueの「本物のエージェント」志向をよく表しています。

// agents/triage.ts
import { defineAgent, type AgentRouteHandler } from '@flue/runtime';
import { local } from '@flue/runtime/node';
import triage from '../skills/triage/SKILL.md' with { type: 'skill' };
import * as githubTools from '../tools/github.ts';

export default defineAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  tools: [...githubTools],
  skills: [triage, verify],
  sandbox: local(),
  instructions,
}));

注目すべきは、SKILL.md を with { type: 'skill' } で直接インポートしている点です。Claude Codeのスキル（Markdownで書かれた再利用可能な専門知識）と同じ思想が、フレームワークのモジュールシステムに組み込まれています。model を1行差し替えればモデルを変えられ、sandbox: local() で実行環境を指定し、tools と skills でエージェントの能力を構成する。「エージェントが本物の仕事をするために必要なハーネス一式を、宣言的に組み立てる」——これがFlueの中核体験です。

ツール（Tools）は、エージェントに「型付きの行動」を与えるための仕組みです。たとえばGitHubのIssueを取得するツールは、おおよそ次のような形で定義され、agents/triage.ts から import * as githubTools で読み込まれます。

// tools/github.ts
import { defineTool } from '@flue/runtime';
import { z } from 'zod';

export const getIssue = defineTool({
  name: 'get_issue',
  description: 'GitHubのIssueを番号で取得する',
  input: z.object({ number: z.number() }),
  async run({ number }) {
    // 実際のAPI呼び出し（認証・制御はアプリ側で）
    return await github.issues.get({ number });
  },
});

入力スキーマを zod で型付けすることで、LLMが渡してくる引数が検証され、エージェントの「制御された行動」が型安全に担保されます。これは、自律エージェントに実世界の操作を任せるうえで重要な安全弁です。

2. 主要機能 — 自律エージェントに必要なものを一通り

Flueは、「安全に行動でき、文脈の連続性を保ち、仕事が実際に行われる場所（Slack・GitHub等）に接続できる」エージェントを作るための機能を、一通り備えています。公式が挙げる主要コンポーネントを整理します。

この一覧から見えるのは、Flueが「エージェント＋ワークフロー」の両刀を狙っていることです。完全に自律的なエージェント（ゴールだけ与える）と、コードで道筋を固めた構造化ワークフロー（入力から完成物まで手順を制御）の、両方を同じフレームワークで書ける。タスクの性質に応じて「どこまでエージェントに任せ、どこをコードで縛るか」を選べる柔軟性は、実用上きわめて重要です。

なかでも Channels（チャネル） は、Flueの「仕事が実際に行われる場所に接続する」という思想を体現する機能です。Slack・Teams・Discord・GitHubなどから検証済みのイベントを受け取れるため、「Slackで特定の文言が投稿されたら起動する」「GitHubでIssueが立ったらトリアージを始める」といった、人間の作業フローに溶け込むエージェントを作れます。エージェントを孤立したチャット画面に閉じ込めるのではなく、チームが日々使っているツールの中に住まわせる——この発想が、実務での定着を大きく左右します。

Skills（スキル） も見逃せません。冒頭のコード例で SKILL.md を直接インポートしていたとおり、Flueは再利用可能な専門知識をMarkdownでパッケージ化し、必要なときにエージェントへ読み込ませます。Claude Codeのスキル機構と同じ思想であり、「特定タスクの専門知識」をエージェント本体から分離して管理できるため、知見の再利用と保守がしやすくなります。

3. サンドボックスと耐久実行 — 「安全に、止まっても続ける」

Flueが特に力を入れているのが、サンドボックス（Sandboxes） と 耐久実行（Durable Execution） です。この2つは、エージェントを「デモ」から「実運用」へ引き上げるための、地味だが決定的な要素です。

サンドボックスは、エージェントがツールを使い、ファイルを変更し、実際の作業を安全に行うための隔離環境です。自律エージェントは、時に予期しない操作をします。本番環境で直接ファイルを書き換えさせるのは危険です。Flueはコード例の sandbox: local() のように、仮想・ローカル・リモートコンテナのサンドボックスを選んで割り当てられます。エージェントの行動を隔離された箱の中に閉じ込めることで、暴走の被害を抑えつつ、本物の作業（コード実行・ファイル編集）を任せられます。開発中はローカルの軽量なサンドボックスで素早く回し、本番ではリモートコンテナで強く隔離する——というように、フェーズに応じて隔離の強度を選べるのも実務的です。

耐久実行は、失敗や再起動をまたいで進捗を保持する仕組みです。長時間動くエージェントは、途中でクラッシュしたり、サーバーが再起動したりします。そのたびに最初からやり直していては、実用になりません。Flueの耐久実行は、承認済みの作業について進捗を保存し、障害から回復できるようにします。これは、当サイトでも触れてきた「会話の外側に状態を持つ」というエージェント運用の定石を、フレームワークレベルで実装したものです。

この2つが噛み合うと、「長時間・安全・回復可能」という、本番エージェントに不可欠な三拍子が揃います。たとえば「バグを再現し、原因を診断し、修正PRを出す」という数十分かかるタスクを、サンドボックスの中で安全に走らせ、途中でサーバーが落ちても耐久実行で再開できる。デモでは見えにくいが実運用では致命的になるこの種の堅牢性に、フレームワークとして正面から取り組んでいる点が、Flueの本気度を示しています。多くのエージェント実装が「動くデモ」で止まりがちななか、Flueは最初から「壊れても続けられる運用」を視野に入れているのです。

4. アーキテクチャ — ハーネスがエージェントを包む構造

Flueにおける「ハーネス」が、エージェントをどう包むのかを概念図で整理します。

この図が示すとおり、Flueの中心には defineAgent で定義されたエージェントがあり、それをハーネス（モデル・スキル・ツール・サンドボックス・セッション）が取り囲みます。外部からはChannels経由で検証済みイベント（Slackのメッセージ、GitHubのIssueなど）が入り、エージェントは必要に応じてSubagentsに委譲し、サンドボックスの中で実作業を行い、成果物やHTTP応答を返します。そして全体の挙動はObservabilityで監視される——という構造です。

特にエレガントなのは、エージェントをHTTPで公開（かつ保護）できる点です。コード例の AgentRouteHandler は、エージェントをHTTPエンドポイントとして露出させつつ、認証などのミドルウェアで保護する仕組みです。これにより、作ったエージェントを「APIとして他のシステムから呼ぶ」運用が自然にできます。Webフレームワークの作法に慣れたAstroチームらしい設計と言えるでしょう。

5. どこでも動く — デプロイ先とパッケージ構成

Flueのもう一つの強みは、デプロイ先を選ばないことです。ローカルのCLIで動かすことも、好みのホスティング環境にデプロイすることもできます。公式が対応を明記する実行先は多彩です。

・Node.js — 標準的なサーバー環境
・Cloudflare Workers — エッジで動かす
・GitHub Actions — CIワークフローの中でエージェントを走らせる
・GitLab CI/CD — 同上、GitLab版
・Daytona — サンドボックス実行環境
・Render — PaaSへのデプロイ

「GitHub ActionsやGitLab CIで動かせる」という点は示唆的です。コードがpushされたらエージェントが起動してトリアージや修正を試みる、といったCIネイティブな自律運用が、Flueの想定する使い方の一つだと分かります。これは、当サイトで解説した loop-engineering の「PR Babysitter」「CI Sweeper」といったループ・パターンとも親和性が高い発想です。常時稼働のサーバーを持たずとも、イベントをトリガーにエージェントを起動できるため、運用のハードルとコストの両方を下げられます。

パッケージ構成も、モノレポとして整理されています。

興味深いのは、@flue/sdk という「クライアントSDK」が別に存在することです。Flue自体は「SDKではなくハーネス」を名乗りますが、作ったエージェントを外部から呼ぶためのSDKは別途用意されている。「エージェントを作る側（ハーネス）」と「エージェントを使う側（SDK）」を明確に分けた、筋の通った設計です。

開発の入り口は @flue/cli の flue バイナリです。ローカルで開発・実行し、準備ができたら任意の環境へデプロイする、というWeb開発に馴染んだ流れになっています。

# CLIで開発サーバーを起動し、ローカルでエージェントを動かす
npx flue dev

# 本番ビルド
npx flue build

ローカルのCLIで素早く試し、@flue/postgres のような永続化アダプタや @flue/opentelemetry の監視アダプタを必要に応じて足していく——という、段階的に本番品質へ引き上げられる構成です。永続化や監視を「最初から抱え込まず、必要になったら差し込む」アダプタ方式は、小さく始めて育てたい開発者にとって扱いやすい設計です。

6. Astroチームが作る意味と、誰に向くか

Flueが Astro チーム の手によることは、単なる豆知識ではありません。Astroは、Webフレームワークの世界で「開発者体験（DX）」と「適切な抽象化」を追求してきたチームです。その設計感覚——宣言的なAPI、モジュールシステムの活用（SKILL.md の直接インポート）、デプロイ先非依存、HTTPネイティブ——が、Flueの随所に表れています。Webフレームワークの成熟した設計思想を、AIエージェントという新領域に持ち込むこと自体が、Flueの独自性です。

エージェント開発はいま、かつてのWeb開発が「生のCGIスクリプト」から「フレームワーク」へと成熟していった過程と、よく似た局面にあります。最初は誰もが生のAPIを直接叩いて個別に作っていたものが、共通の課題（セッション、安全な実行、デプロイ、監視）が見えてくると、それを引き受けるフレームワークが求められるようになる。Flueは、まさにこの「エージェント開発のフレームワーク化」を、Web開発で同じ道を歩んできたチームが手がけている点で、説得力があります。歴史を一度通ってきた作り手だからこそ見える勘所があるのです。

Flueが特に向くのは、次のような開発者です。

第一に、自律エージェントを「実運用」したいエンジニアです。デモ止まりでなく、サンドボックスで安全に動かし、耐久実行で障害に耐え、Observabilityで監視する——本番運用に必要な要素が最初から揃っています。「動くものは作れたが、本番に出す自信がない」という段階を越えたい人に向いています。

第二に、TypeScript中心のチームです。FlueはTypeScriptで一貫しており、型付きツール（Tools）でエージェントの行動を型安全に定義できます。既存のTypeScript資産やWeb開発の知見をそのまま活かせます。Pythonエコシステムが主流のAIエージェント界において、TypeScriptで一気通貫に書ける選択肢は、フロントエンド/フルスタックのチームにとって貴重です。

第三に、CI/イベント駆動でエージェントを動かしたいチームです。GitHub Actions・GitLab CI対応とChannels（Slack/GitHub等のイベント受信）により、「人間が話しかける」だけでなく「システムのイベントで自律起動する」エージェントを自然に作れます。常駐ボットとしてではなく、必要なときだけCI上で起動する運用は、コスト面でも理にかなっています。

第四に、MCPエコシステムを活用したい開発者です。MCP Serversへの接続が組み込まれているため、すでに普及しつつあるMCPツール群を、認証込みでエージェントに繋げられます。車輪の再発明をせず、既存のMCP資産にそのまま乗れるのは大きな利点です。

Flueの立ち位置を、近接する選択肢と並べて整理しておきます。

この比較が示すとおり、Flueは「部品を提供して組み立ては任せる」のではなく、「実運用に必要な土台をまるごと用意する」方向に振り切っています。その分、フレームワークの作法に乗る必要はありますが、サンドボックスや耐久実行を自前で実装する手間から解放されます。

一方で、留意点もあります。Flueは比較的新しいフレームワーク（2026年初頭に公開）であり、エコシステムや実運用の事例はこれから積み上がる段階です。また「ハーネスを宣言的に組む」という設計は強力ですが、エージェントの自律性をどう設計・検証するかという難しさ自体が消えるわけではありません。とはいえ、Astroチームという実績ある作り手が、明確な思想（SDKでなくハーネス）で取り組んでいる点は、長期的な期待を抱かせます。

まとめ

本記事では、Astroチームが公開したエージェント・ハーネス・フレームワーク Flue を解説しました。

Flueの本質は、「本物の自律エージェントを作るための土台（ハーネス）を、フレームワークとして提供する」ことにあります。LLMのAPIを直接叩く時代から、Claude CodeやCodexのような自律エージェントの時代へ——その移行に必要な、セッション・ツール・スキル・サンドボックス・耐久実行・サブエージェント・MCPといった要素を、宣言的なTypeScriptコードで組み立てられます。

「SDKではなくハーネス」という線引き、SKILL.md の直接インポート、サンドボックスと耐久実行による実運用への配慮、デプロイ先非依存とHTTPネイティブ設計——いずれにも、Webフレームワークで実績を重ねたAstroチームの成熟した設計思想が表れています。

エージェント開発が「APIを叩くスクリプト」から「ハーネスの上で動く自律システム」へと進化していくなかで、Flueはその土台を担おうとする有力な候補です。まだ若いプロジェクトだけに、今後のエコシステムの広がりにも注目したいところです。自律エージェントを本気で作り、運用したいと考えるなら、公式ドキュメントとサンプルを覗いて、defineAgent から始めてみてください。

よくある質問（FAQ）

Q1. Flueとは何ですか? Astroチーム（withastro）が公開した「エージェント・ハーネス・フレームワーク」です。TypeScriptで自律エージェントとAIワークフローを構築でき、セッション・ツール・スキル・サンドボックス・耐久実行・サブエージェント・MCPなどを備えます。Apache-2.0ライセンス・GitHub約6,900スター。

Q2. 「SDKではなくハーネス」とはどういう意味ですか? SDKは「LLMを呼ぶ」「ツールを定義する」といった部品を提供し、実行環境は開発者が組み立てます。ハーネスは、その実行環境一式（セッション・サンドボックス・ファイルアクセス等）を最初から備えた土台です。Flueは後者を提供し、どんなモデルにも自律作業に必要な環境を与えます。

Q3. どんなモデルで使えますか? コード例では anthropic/claude-sonnet-4-6 を指定していますが、model を差し替えることで他のモデルにも対応します。モデルに依存しない「ハーネス」として設計されているのが特徴です。

Q4. どこにデプロイできますか? Node.js、Cloudflare Workers、GitHub Actions、GitLab CI/CD、Daytona、Renderなどに対応します。ローカルのCLIで動かすこともでき、デプロイ先を選ばない設計です。

Q5. MCPには対応していますか? 対応しています。MCP Servers経由で、Model Context Protocolの認証済みツール・サービスにエージェントを接続できます。普及が進むMCPエコシステムをそのまま活用できます。

Q6. 自律エージェントと構造化ワークフローのどちらが作れますか? 両方作れます。ゴールだけ与える自律的な「Agents」と、コードで道筋を制御する「Workflows」の両方を同じフレームワークで書け、Subagentsで専門役割への委譲もできます。タスクに応じて自律と制御のバランスを選べます。

参照ソース

・Flue（withastro/flue 公式リポジトリ） — 本記事が解説した一次情報。コード例・機能・パッケージ構成
・Flue 公式サイト・ドキュメント — 各機能のガイドとデプロイ手順
・Model Context Protocol（MCP 公式） — Flueが対応するツール接続の標準プロトコル