AIエージェントを隔離した実行環境で動かす開発用OSS「Flue」を解説

「開発部門が、AIエージェントを自社のサービスに組み込む部品を使い始めたらしい。どこまで任せる作りなのか分からない」「隔離した環境で動かすと説明されたが、その隔離がどこまで効くのか確かめようがない」——AIエージェントを業務に組み込む動きを見守る情報システムやセキュリティの担当者から、最近よく聞く二つの声です。こうした不安は、使う部品が信頼できるかどうかの問題に見えます。しかし問われているのは、部品の評判ではありません。本当は、部品が用意した守りの仕組みのうち、どれを使い、どれを人が補うのかを、組み込む側が決めているかです。この記事では、AIエージェントを組み立てるための開発用OSS「Flue」を取り上げ、一次情報で確かめられる仕組みと、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

Flueとは何か。2026年10月時点で確かめられる事実

Flueは、GitHubで公開されているOSSです。リポジトリの説明は「サンドボックス（外と切り離した実行の場）を備えたエージェントの枠組み」で、READMEの冒頭では、AIエージェントを組み立てるためのハーネス（モデルに道具や作業環境を与えて動かす外枠）の枠組みと名乗っています。TypeScriptで書く開発者向けの部品で、利用者が画面から操作する製品ではありません。

公開元を確かめます。リポジトリは、ウェブサイトを作る枠組みとして知られるAstroの開発組織のアカウントにあります。この組織のアカウントは2018年11月に作られ、公開しているリポジトリは60件、フォロワーは約4,500です。Flueのリポジトリは2026年2月7日に作られ、10月26日時点でスターは8,538、派生は518、最後の更新は10月17日でした。ライセンスは商用を含めて使えるApache-2.0です。一日あたりのスターの伸びは約32.7件で、作ったばかりのアカウントが急に注目を集めている形ではありません。

READMEによると、部品は役割ごとに分かれています。中核となる実行の部品、開発用の組み立て道具とつなぐ部品、コマンドから使う部品、動いているエージェントとやり取りする部品、記録を書き出す部品、会話の記録をデータベースに保存する部品です。リリースの一覧では、2.2系の版が複数の部品でまとめて公開されていました。部品ごとに版が上がる作りである点は、後の注意点につながります。

なぜ今、AIエージェントの外枠を組み立てる道具が注目されるのか

READMEは、初期のエージェントは大規模言語モデルの呼び出しを直接組み合わせて作られ、簡単な対話や決まった手順の作業には足りたが、それ以上には向かなかった、と説明しています。そのうえで、Claude CodeやCodexのように、決まった手順ではなく課題そのものを渡して任せる形のエージェントが出てきたことを、転換点として挙げています。

こうした任せる形のエージェントには、モデルのほかに多くのものが要ります。会話の続きを覚える仕組み、道具、手順書、指示、ファイルを読み書きする場所、そして安全に動かす場です。READMEは、これらをひとまとめに与えるのがFlueの役割だとしています。言い換えると、AIエージェントの外枠を、自社のサービスの中に自分たちで組み込むための部品です。

守る側から見ると、ここに大事な変化があります。これまで社内で使うAIエージェントは、提供元が用意した製品を使う形が中心でした。Flueのような部品が広がると、開発部門が自社のサービスや社内の仕組みの中に、独自のエージェントを作り込む場面が増えます。その分、隔離や権限の決め方を、製品の提供元ではなく自社が担うことになります。

三種類のサンドボックスと、それぞれの隔離の強さ

公式の文書によると、エージェントが作業する場は三種類から選べます。一つ目は「仮想」の場で、記憶領域の中だけにあるファイルの置き場と、まねて作った命令の受け口で動きます。実際の処理は起動されず、手元の機械のファイル、処理、環境の設定値には届かないと説明されています。外への通信は既定で切られ、使うときは許す宛先を並べて開ける形です。

二つ目は「手元」の場です。手元の機械の本物のファイルを読み書きし、本物の処理として命令を動かします。文書は、これを設計として隔離の無い方式と明記し、信頼できない依頼や、複数の利用者が同居する用途の隔離の境界として使わないよう注意しています。開発用の道具や、すでに別の仕組みで切り離された環境での利用が想定されています。

三つ目は「外部の提供者」の場です。Daytona、E2B、Cloudflareなどが用意する実行環境に、つなぎの部品を通して接続します。隔離の強さは提供者しだいで、文書は提供者ごとの保証の詳細までは示していません。また、多くの提供者では動いている命令を途中で取り消せず、取り消したつもりでも向こう側で命令が動き続けることがあるとも書かれています。

手元の方式で気をつけたい、鍵と環境の設定値

手元の方式には、一つ配慮された点があります。文書によると、命令を動かす環境には、動作に欠かせない最小限の設定値だけが渡され、外部サービスの鍵や認証情報、クラウドの資格情報は既定で外されます。ほかの設定値は、組み込む側が明示して渡す形です。

一方で、文書は、手元の機械の設定値をまとめて渡すと、秘密の値も含めてすべてがエージェントの手の届く所に置かれると警告し、完全に信頼できる環境に限るよう求めています。つまり、既定の守りはあっても、開発者の一つの判断で、手元の鍵がまるごとAIの作業場所に入る作りだということです。

文書はさらに、モデルが使う命令の受け口に渡す資格情報はできるだけ減らし、特権の要る操作は範囲を絞った専用の道具で行うよう勧めています。何でもできる命令の受け口に強い鍵を持たせないという考え方です。社内で審査するときは、どの方式を使い、どの設定値を渡しているかを最初に確かめる項目にすると、議論が具体的になります。

道具の型と、権限の結びつけ方

Flueでは、エージェントが呼び出す道具ごとに、受け取る値の形を決めておけます。文書によると、値は道具が動く前に形を確かめられ、合わなければ道具は動かずに、誤りがモデルに返されます。道具の中で起きた誤りも、エージェントを止めずに結果として返す作りです。

ただし、文書は形を確かめることと、権限を確かめることを分けています。道具に渡される値はモデルが選んだ入力であって、権限の境界ではないとはっきり書かれています。どの顧客、どのアカウント、どの保管場所、どの資格情報を道具が使えるかは、組み込む側のプログラムが決めるべきだという立場です。

具体的には、顧客ごとのエージェントであれば、相手を示す識別子はモデルが出した値ではなく、呼び出し元を確かめたうえで信頼できるプログラムが付けた値を使うよう勧めています。鍵や宛先は信頼できるプログラムの側で固定し、任意の宛先や機能を呼べる汎用の道具は、権限の設計なしに渡さないことも求めています。なお、人の承認を挟む専用の機能は文書に見当たらず、承認を確かめてから次の道具を載せる組み方が例として示されていました。

外部の道具とつなぐ仕組みと、手順書の扱い

Flueは、外部の道具をつなぐ共通の取り決めであるMCPにも対応しています。文書によると、接続先から見つかった道具のうち、名前を挙げたものだけを載せる絞り込みができます。認証にはOAuthの考え方に沿った鍵を使いますが、Flueは鍵を保存も管理もしないと明記され、認可の流れ、保管、更新は組み込む側が受け持ちます。

文書は、つないだ接続先がエージェントに影響を与えうる点にも触れています。接続先の道具の説明文は指示の中に入り、道具の結果は会話の中に入ります。そのため、自社で管理していない接続先は、ほかの外部の依存先と同じように扱うよう求めています。ここは、外部の文章に紛れ込ませた命令でAIを操るプロンプトインジェクションの入口になりうる所です。

手順書（スキル）は、作業の進め方を文章で書いたもので、エージェントが必要なときに読み込みます。文書によると、手順書をまとめて同梱するとき、鍵のファイルや秘密鍵などは含めないよう拒まれ、同梱した手順書は読み取り専用で、エージェントが書き換えられません。一方で、手順書に書ける「使ってよい道具」の欄は受け付けるだけで、実際の制限には使われないとも書かれています。作業場所の決まった位置にある手順書を、起動時に自動で読み込む仕組みもあります。

中断に強い作りと、二重実行の注意

READMEが特徴に挙げる一つが、中断からの立ち直りです。文書によると、受け付けた依頼はモデルが動く前に記録され、会話ごとに一件ずつ受け付けた順に処理されます。障害や再起動、入れ替えがあっても、記録をもとに続きから再開し、最後は完了・失敗・中止のいずれかで締めくくられます。既定では、一件の依頼につき10回の試行と1時間が上限です。

道具の扱いは慎重に設計されています。中断の前に結果が記録された道具は再び動かず、結果が分からないまま中断した通常の道具も再実行されず、結果不明の誤りとしてモデルに伝えられます。一方、再実行を許すと印を付けた道具は動き直します。文書は、記録は一度きりでも、実行は一度以上になりうると説明し、メールの送信、支払い、外部のデータベースへの書き込みなどが、まれに二重に起きうると注意しています。

もう一つ見落としやすい点があります。Node上で動かす場合、既定の保存先は記憶領域の中にあり、再起動ですべて消えると書かれています。仮想の作業場所のファイルも、再開すると失われます。「中断に強い」は、保存先と道具の作りを正しく選んだときに初めて成り立つ性質で、入れただけで得られるものではありません。

子エージェントへの委任と、共有される作業場所

Flueでは、特定の仕事を受け持つ子エージェントを用意し、親のエージェントに任せさせることができます。文書によると、子は新しい文脈で動き、最後の答えだけを親に返します。委任は四段まで重ねられ、同じ一括の仕事は並べて動きます。誰に任せるかは、親のモデルが説明文を読んで判断します。

ここで押さえたいのは、何が切り離され、何が共有されるかです。子は、親の会話の履歴、指示、道具、手順書を引き継ぎません。一方で、親と同じ作業場所と、作業場所に付いた道具は共有すると書かれています。文書の言い方では、切り離されるのは文脈であって、ファイルや環境ではありません。

守る側から見ると、子エージェントに仕事を与えることは、親の作業場所に触れる手をもう一本増やすことと同じです。子の数や役割が増えるほど、誰が何に触れたかを追う必要が出てきます。子エージェントは使うと明示したときだけ有効になる作りで、どの子を載せるかをプログラムの状態で切り替えることもできると説明されています。

外部サービスからの受け口と、記録の書き出し

Flueには、外部のサービスから届く知らせを受け取る「チャネル」という仕組みがあります。文書によると、Slack、Teams、Discord、GitHub、Stripe、Shopify、Notionなど17の提供元向けの部品が公開されています。届いた知らせは、提供元ごとの検証用の秘密の値で署名を確かめ、古い知らせは受け付けず、検証を通ったものだけが処理に回る作りです。

文書は受け口についても具体的な注意を挙げています。返信用の一時的な鍵や宛先を知らせの中に入れたままにしないこと。知らせはモデルの文脈と、中断に備えた記録の両方に入るためです。また、会話の識別子は会話を指すだけで、利用の権限を与えるものではないため、エージェントには別に守りを付けるよう求めています。

記録の書き出しは、OpenTelemetry、Sentry、Braintrust、Cloudflareの監視機能などに対応しています。文書によると、記録には指示文、モデルの推論、道具に渡した値と結果、誤りの詳細が含まれうるとされ、Cloudflare向けとBraintrust向けの書き出しは、既定で会話の中身を取り込むと書かれています。中身を取り込まない設定や、伏せ字にする仕組みも用意されています。

似た手段と何が違うのか

AIエージェントを業務に組み込む方法は、Flueのような部品を使うほかにもあります。一次情報で確かめられた範囲をもとに、代表的なやり方と比べます。優劣ではなく、誰が守りを決めるのかの違いとして読んでください。

見る点	提供元のAIエージェント製品	モデルを直接呼び出して自作	Flueで組み立てる
作り手	提供元	自社	自社（外枠はFlueが用意）
実行の場の隔離	製品の仕様に従う	自社で一から用意する	仮想・手元・外部の提供者から選ぶ
道具の権限	製品の管理画面で決める	自社で一から設計する	形の確認はあるが、権限は自社のプログラムで決める
中断からの回復	製品しだい	自社で作る	受け付けた依頼を記録して再開する仕組みがある
記録	製品の記録機能	自社で作る	主な監視の仕組みへ書き出せる。中身の扱いは設定しだい
守りの責任	主に提供元と契約	すべて自社	部品の範囲はFlue、選び方と使い方は自社

表から分かるのは、Flueが「一から作る」と「製品を使う」の間に位置することです。外枠の多くを用意してくれる一方、どの守りを有効にするかの選択は、組み込む側に残ります。外部の提供者の場を選べば、守りの一部はさらにその提供者に移ります。部品の評判だけで判断せず、選んだ組み合わせの全体で考える必要があります。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけを基に精査しています。OSSを入手したり動かしたりはしていません。Flueの判定は「紹介可」です。

根拠にした事実は次のとおりです。ライセンスはApache-2.0です。運営はAstroの公式の組織アカウントで、2018年に作られ、フォロワーは約4,500あります。スターの伸びは1日あたり約32.7件で、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、取り込みのときに自動で動く処理を含む設定も見当たりませんでした。脆弱性は公開の場ではなく、Astroの開発組織あてにメールで報告する方針が示されています。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。加えて、部品が多く、外部の提供者の場やチャネルの部品も別々に公開されています。使う部品ごとに同じ確認が要ります。

導入前に知っておきたい注意点

第一に、隔離の無い方式を選べる点です。手元の方式は、開発者の手元や、すでに切り離された環境で使う前提です。社外の利用者から依頼を受けるサービスでこの方式を使えば、利用者の依頼が、手元の機械の本物のファイルと処理に届くことになります。どの方式を使っているかは、審査で必ず確かめたい点です。

第二に、版の動きが速く、部品が多い点です。2月に公開されたリポジトリが、10月の時点で2系の版まで進んでいます。どの部品のどの版を使っているかを一覧にしておかないと、更新の影響範囲を追えません。第三に、記録の中身です。書き出し先によっては会話の中身が既定で送られるため、書き出し先の保存期間と閲覧できる人を確かめる必要があります。

第四に、日本語の資料がほとんど見当たらない点です。確認した範囲では、日本語で仕組みや注意点を整理した資料は見つけられませんでした。公式の文書は英語で、内容は具体的ですが、守りに関わる注意書きが機能ごとの頁に散らばっているため、読み落としが起きやすい構成です。この記事で触れた注意書きも、それぞれ別の頁にあります。

悪用されうるリスク

Flueは攻撃のための道具ではなく、AIエージェントを組み立てるための部品です。それでも、使い方しだいで生まれうる危険はあります。最も現実的なのは、攻撃ではなく「隔離の場が付いた部品だから安全」という思い込みのまま、隔離の無い方式や強い鍵を使うことです。

次に挙げるのは推測ですが、検討の材料として無視できません。外部から届いた知らせや、つないだ接続先の道具の説明文に命令が紛れ込めば、エージェントは許された道具の範囲で、意図しない操作をする可能性があります。道具の宛先や鍵をモデルが選べる作りにしていれば、その被害は広がります。文書が宛先と鍵を信頼できるプログラムの側で固定するよう求めているのは、この経路をふさぐためと読めます。

もう一つは、記録や同梱物を通じた情報の広がりです。記録の書き出し先に会話の中身が送られれば、本来見せない人の目に触れる場所に情報が残りえます。守りの仕組みがあっても、使っていなければ効かないという点が共通しています。なお、Flueが実際に悪用された事例は、2026年10月26日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

開発部門からFlueを使いたいという相談があったときに、動かす前に資料と社内の取り決めで確かめられる点を、順に整理します。どれも、コードを読まなくても開発者への聞き取りで確かめられる項目です。

この手順の要は、部品が用意した守りのどれを実際に使っているかを、言葉で説明できる状態にすることです。Flueの文書には守りの仕組みと注意書きがそろっていますが、使うかどうかは組み込む側の選択です。選択の結果を記録に残しておけば、後で問題が起きたときにたどれます。

企業が取るべき対策

一つ目は、社内で作るAIエージェントの一覧を持つことです。製品として入れるAIだけでなく、開発部門が部品を使って作り込むエージェントも把握の対象に入れます。誰が作り、何の業務に使い、どの実行の場で動いているかを記録します。

二つ目は、作る側の決まりを用意することです。隔離の無い方式を使ってよい場面、作業場所に渡してよい鍵、モデルに選ばせてはいけない値、外部の接続先の審査の仕方を、開発部門と情報システム部門が共有する決まりとして文書にすると、相談のたびに一から議論せずに済みます。

三つ目は、記録の確認です。記録の書き出し先ごとに確かめる観点を整理しておくと、点検の抜けを防げます。下の表は、文書で確認できた記録の中身をもとにした観点の例です。

確かめる対象	何が分かるか	気にすべき兆候
道具の呼び出し	どの道具に、どんな値が渡ったか	想定していない宛先や顧客への操作がある
依頼の結末	完了・失敗・中止の内訳	失敗や試行の繰り返しが急に増えている
子エージェントの仕事	誰に何を任せたか	想定より深い委任や多い並列がある
受け口の検証	署名を確かめて受けた知らせ	検証に失敗した知らせが増えている
書き出した中身	記録に入った指示文や結果	個人情報や鍵が記録に残っている

AIに任せる範囲と、人が決める範囲

Flueは、AIエージェントに課題そのものを渡して任せる形を支える部品です。任せる範囲が広がるほど、何が起きたかを人が追いにくくなります。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、どの実行の場を使うか、どの鍵を渡すか、どの宛先と顧客に触れてよいか、どの外部の接続先を許すか、記録に何を残し誰が見るか。これらはAIにも部品にも委ねず、人が決めて記録に残します。AIには、作業の結果だけでなく、どの道具を使い、なぜそう判断したかの根拠を書かせ、人が確かめられる形にします。やってはいけない向き合い方を挙げます。

• 「隔離の場が付いた部品だから」を理由に、どの方式を使っているかを確かめない
• 社外の利用者から依頼を受けるサービスで、手元の機械で直接動かす方式を使う
• 手元の機械の設定値をまとめて作業場所に渡し、鍵まで手の届く所に置く
• 顧客や宛先をモデルが選べる汎用の道具を、権限の設計なしに渡す
• 手順書の「使ってよい道具」の欄を、実際の制限だと思い込む
• 記録を書き出しているが、中身に何が入り、誰が見られるかを確かめていない

裏を返せば、人が決める範囲ははっきりしています。どこで動かすか、どの鍵を渡すか、何に触れさせるか、誰が記録を見るか。この四つが決まっていれば、Flueの守りの仕組みはその決まりを支える道具として働きます。決まっていなければ、仕組みがそろっていても守りの厚みは増えません。

よくある質問：社内で使うときに迷いやすい点

最初に出やすいのは「仮想の場を使えば安全か」という問いです。文書では、仮想の場は手元の機械のファイルや処理、設定値に届かず、外への通信も既定で切られていると説明されています。隔離の強さでは三つの中で最も強い部類です。ただし、つないだ道具や外部の接続先は作業場所の外で動くため、道具に強い権限を持たせれば、仮想の場の外で影響が出る点は変わりません。

次に「開発部門が使うだけなら、情報システム部門は関わらなくてよいか」という問いです。Flueで作ったエージェントが社内の資料や顧客のデータに触れるなら、関わる必要があります。審査の入口は、この記事の手順で挙げた五つの確認です。コードを読めなくても、開発者への聞き取りで確かめられます。

最後に「Astroの組織が公開しているなら信頼できるか」という問いです。公開元の実績は判断材料の一つですが、それだけで十分ではありません。部品が多く、外部の提供者の部品も組み合わせる作りなので、使う部品ごとに確認が要ります。公開元が実績のある組織であることと、自社の使い方が安全であることは別の話です。

• Flueの機能・版・注意書きは、GitHubのリポジトリ、リリースの一覧、脆弱性の報告方針、公式の文書の各頁を2026年10月26日に確かめた範囲に基づきます。内容は変わる可能性があります
• 外部の提供者ごとの隔離の保証、手元の方式での通信の既定値は、確認した一次情報の範囲では確かめられませんでした。導入の判断では最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Flueは、Astroの開発組織が公開する、AIエージェントを組み立てるための開発用のOSSです。道具、手順書、作業場所、中断からの回復、子エージェントへの委任、外部サービスからの受け口、記録の書き出しをひとまとめに扱えます。Apache-2.0で公開され、GitHub上にセキュリティ勧告は登録されていません。公式の文書には、守りに関わる注意書きが具体的に書かれています。

一方で、その注意書きが示すとおり、隔離の無い方式も選べ、道具に渡す値は権限の境界ではなく、記録には会話の中身が入りえます。どの守りを使うかは組み込む側の選択です。どこで動かし、どの鍵を渡し、何に触れさせ、誰が記録を見るかを人が先に決めたうえで使うことが、自社でAIエージェントを作る時代のFlueとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。