AIエージェントの防護フィルタと記録を一か所にまとめるOSS「Plano」の仕組みと導入前の注意点

「AIエージェントが部署ごとに増えて、どれが何を送り、どこで止める仕組みがあるのか把握できない」「防護の仕組みや記録を、エージェントを作るたびに一から組み込むのはもう限界だ」——AIエージェントを試作から本番へ移そうとしている企業の、情報システムやセキュリティの担当者から聞こえてくる声です。こうした悩みに、エージェントの外側に共通の中継役を置いて応えようとするOSSが出てきています。ただ、中継役を置けば統制が効く、という単純な話ではありません。本当は、防護・記録・振り分けを一か所に集めるほど、その一か所で何が判断され、何がどこへ送られるかを人が把握しておく必要があるのです。この記事では、AIエージェント向けの中継・データ層のOSS「Plano」について、一次情報で確かめられる仕組みと、導入前に企業が確かめておきたい注意点を整理します。導入や設定の手順は扱いません。

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

Plano は、Katanemo という組織がGitHubで公開している、AIエージェント向けの中継役（プロキシ）兼データ層のOSSです。READMEでは、エージェントへの振り分けと連携、エージェントの振る舞いを示す信号と通信の記録、安全のための防護フィルタ（ガードレール）、モデルの振り分けといった、どのエージェントでも毎回作り直しがちな周辺の仕組みを、アプリの外の一か所にまとめるものと説明されています。

規模と時期も確かめておきます。組織のアカウントは2022年9月2日、リポジトリは2024年7月9日に作られています。2026年10月22日時点でスターはおよそ7,100、複製（フォーク）は488で、最後の更新は2026年10月7日です。リリースの一覧では、2026年8月から9月にかけて0.4.33版から0.4.37版まで、数日から数週間おきに版が出ています。ライセンスは、OSI（オープンソースの定義を管理する団体）が承認した Apache-2.0 です。

土台には、通信の中継役として広く使われているOSSの Envoy が使われています。READMEは、Envoy の中心的な開発者が作ったと説明しています。また、運営元の Katanemo Labs は、2026年4月2日にクラウド事業者の DigitalOcean に買収されたと発表されています。発表文は Plano をOSSの取り組みとして紹介していますが、今後のライセンスの扱いには触れていません。公式サイトのリンク先のリポジトリが別の名前になっていることから、以前は別の名前で公開されていた可能性がありますが、確かめきれていません。

なぜ今、AIエージェントの「中継・データ層」が求められるのか

READMEは、エージェントの試作は簡単でも、安全に、確実に、繰り返し本番へ出すのは難しい、と問題を立てています。試作のあとに、正しいエージェントへ届ける振り分け、安全と節度のための防護の仕組み、評価と監視のためのつなぎ込み、モデルや提供元ごとの癖への対応が、各アプリの中に「隠れた中間処理」として散らばっていくという指摘です。

企業の統制の目線で言い換えると、これは「守りの仕組みがエージェントごとにばらばら」という状態です。あるエージェントには入力の点検があり、別のエージェントにはない。記録の取り方も保存先も違う。こうなると、監査の場面で社内のAIエージェント全体で、何が止められ、何が記録されているかを一度に答えられません。Plano はこれを、アプリとは別の処理として外に出す（アウトオブプロセス）ことで解こうとしています。

前日に紹介した GoModel のような中継役は、主にアプリとAIの提供元の間に立ち、鍵と費用をまとめるものでした。Plano はそれに加えて、利用者とエージェントの間にも立ち、どのエージェントに渡すか、渡す前に何を通すかまでを受け持つ点が特徴です。エージェントの入り口と、エージェントからモデルへの出口の両方に置ける作りと説明されています。

仕組み1：エージェントの手前で問い合わせを振り分ける

READMEによると、Plano では、エージェントの住所と、そのエージェントが何を受け持つかを自然な文章で書いた説明を、設定ファイルで宣言します。利用者からの問い合わせが来ると、Plano が中身を読み取り、どのエージェントに、どの順で渡すかを決めて取り次ぐとされています。READMEの例では、一つの会話の中で天気のエージェントと航空便のエージェントの両方へ順に渡しています。

この振り分けの判断には、Katanemo が作った専用の言語モデルが使われます。READMEでは振り分け用のモデルを「40億規模のモデル」と紹介し、エージェントを追加するときもアプリのコードを書き換えず、設定に足して再起動するだけで済むとしています。各エージェントは、OpenAI の形式に合わせた窓口を持つ普通のサーバーとして作ればよく、言語や部品は問わないと説明されています。

統制の目線で押さえたいのは、どのエージェントに渡すかを、規則ではなくAIのモデルが判断しているという点です。説明文の書き方しだいで振り分けの結果が変わりうるため、権限の強いエージェントほど、誤って渡される場面がないかを人が確かめる必要があります。振り分けの判断が記録に残るかどうかも、導入前に確かめておきたいところです。

仕組み2：防護フィルタを順に通す「フィルタの連鎖」

Plano の防護の中心は「フィルタの連鎖」と呼ばれる仕組みです。公式の説明書きによると、問い合わせがエージェントやモデル、道具に届く前に、あらかじめ決めた順番で複数のフィルタを通すものです。各フィルタは問い合わせの文章や付帯情報、会話の状態を読み、書き換えたり、情報を足したり、その場で返答して流れを打ち切ったりできます。

フィルタは、MCP（AIエージェントが外部の道具やデータを呼び出すための共通の約束事）の形式で作るのが既定で、普通の通信の窓口を持つ別のサービスとして作ることもできます。フィルタが「規則に反する」という応答を返すと、問い合わせはそこで止まり、呼び出し元に理由が返されます。モデルの手前に置いた場合は、止めた問い合わせがモデルに届くことはないと説明されています。フィルタ自体が故障した場合も、その結果が呼び出し元に返り、記録に残ります。

公式の説明書きが挙げる使いみちは、内容の決まりを守らせる、機密の情報を伏せる・取り除く、危ない問い合わせや担当外の問い合わせを止める、といったものです。防護の手引きでは、AIの振る舞いを変えさせようとする入力（脱獄）の阻止や、財務の話題だけに絞るといった担当範囲の制限が例に挙がっています。この連鎖は、問い合わせが届く前の側で働くものとして説明されており、答えの側を点検する仕組みは、確認した説明書きには書かれていませんでした。

防護フィルタの「中身」は利用者が作るもの

ここが Plano を理解するうえで最も大事な点です。防護の手引きを読むと、脱獄の阻止は目標として挙げられているものの、組み込みの検知モデルがあるとは書かれていません。示されている例は、担当範囲かどうかをAIに問い合わせて確かめる自作のフィルタで、それも「簡略化した例」と明記されています。

つまり Plano が提供するのは、フィルタを決まった順に通し、止めたら呼び出し元に返し、記録に残す、という防護をかけるための枠組みです。何を危険とみなし、どこで止めるかの中身は、使う側が作るか、別の製品やOSSを組み合わせて用意することになります。手引きには、見落としや誤って止める割合、処理の遅れ、どの種類の攻撃に効くかといった限界の記述もありません。

これは欠点というより、作りの考え方の違いです。社内の規程に合わせて防護の中身を差し替えやすい一方で、Plano を入れただけで防護が効いていると考えるのは誤りです。導入の検討では、フィルタの中身を誰が作り、どう試し、誰が見直すのかを、仕組みの導入と同じ重さで決める必要があります。

仕組み3：会話の様子を数値で拾う「シグナル」と通信の記録

Plano は、エージェントのやり取りを外から観察して、うまくいっていない兆しを拾う「シグナル」という機能を持ちます。公式の説明書きによると、会話ごとに別のAIで採点するのではなく、モデルを使わない軽い方法で兆しを数える仕組みです。利用者が言い直した、同じような答えが続いた、人の担当者を求めた、感謝を示した、といった会話の様子を拾います。

ほかに、存在しない道具を呼んだ、同じ道具を同じ引数で何度も呼び続けた、といったエージェント側の失敗や、時間切れや回数制限といった外部の要因も分けて数えます。会話ごとに「優」から「深刻」までの五段階の評価と点数が付き、通信の記録の標準形式である OpenTelemetry の記録に情報として書き足されます。2026年9月の0.4.37版では、同じ動作の繰り返しを見つける処理の改良がリリースの説明に挙がっています。

通信の記録（トレース）は、受付、振り分け、フィルタ、エージェント、モデルの呼び出しといった段階ごとに残ります。モデルの呼び出しの記録には、モデル名、提供元、使った量などが残ると説明されています。記録を取る割合は0から100まで決められ、READMEの例は100、つまりすべての問い合わせを記録する設定です。記録の送り先は、社内の監視の仕組みや外部の分析サービスなどから選べます。

記録に会話の断片が残りうる点

監視の説明書きでは、モデルの呼び出しの記録は付帯情報と量が中心で、会話の本文をまるごと記録に残すとは書かれていません。一方で、例外もあります。シグナルの記録には、兆しの根拠になった発言の一部が残ることがあり、説明書きの例では利用者の短い発言がそのまま記録に入っています。

外部の分析サービスの PostHog へ送る設定では、利用者の発言を短く切った見本を送るかどうかを選べ、既定では送らないとされています。説明書きも、問い合わせの中身を社外へ出してはいけない場合は、この設定を切ったままにするよう書いています。また、指定した接頭辞を持つ通信の付帯情報を記録に写す機能があり、接頭辞の選び方によっては、意図しない情報が記録に入る可能性があります。

記録から機密を自動で伏せる専用の機能は、確認した説明書きには見当たりませんでした。シグナルの機能は設定で止められます。記録は統制の要ですが、記録そのものが社員の発言や顧客の情報を含む「守るべきデータ」になりうることを前提に、送り先、保存期間、閲覧できる人を決めておく必要があります。

仕組み4：モデルの振り分けと、振り分け専用の小型モデル

Plano は、エージェントからAIのモデルへの出口でも働きます。モデルの振り分けの説明書きによると、方法は三つあります。提供元とモデル名を名指しする方法、「速いモデル」のような社内の呼び名を実際のモデルに対応づける方法、そして問い合わせの分野と作業の種類を専用のモデルが読み取り、決めておいた好みに沿ってモデルを選ぶ方法です。

三つ目の方法を担うのが Plano-Orchestrator という専用のモデルです。Hugging Face の公開ページでは、Qwen の言語モデルをもとに作られた、複数のエージェントの連携向けのモデルの一群と説明されています。説明書きの自前で動かす例では、それより小さい Arch-Router という約15億規模のモデルが使われています。説明書きによると、このモデルは画像や音声をそのままは扱えず、道具の呼び出しの判断には向かず、利用者側の会話だけを見て、システムへの指示（システムプロンプト）は見ないとされています。

候補のモデルは順番付きで並べ、先頭が主、残りが予備です。回数制限や提供元の障害のときは予備に切り替わります。2026年8月の版では、問い合わせごとに切り替えにかけてよい費用の割合を指定する仕組みや、振り分けの応答に「切り替えたかどうか」を示す項目が足されています。どの問い合わせがどのモデルに届いたかが、設定と専用モデルの判断で変わるため、予備の切り替え先も含めて、社内で認めた提供元だけを並べることが前提になります。

似た手段との違い

Plano の位置づけを、エージェントごとに作り込む場合と、モデルの手前だけに置く中継役と比べます。後者は前日に扱った GoModel のような仕組みを想定した一般的な比較で、個別の製品の優劣を示すものではありません。

観点	エージェントごとに作り込む	モデルの手前だけに置く中継役	Plano
置く場所	各アプリの中	アプリとAIの提供元の間	利用者とエージェントの間、エージェントとモデルの間の両方
エージェントへの振り分け	アプリごとに作る	扱わないことが多い	専用のAIのモデルが判断して取り次ぐ
防護フィルタ	アプリごとにばらばら	製品により組み込みの点検がある	順に通す枠組みを提供。中身は利用者が作る
記録	取り方も保存先もばらばら	モデルの利用の記録が中心	段階ごとの通信の記録と、会話の様子のシグナル
統制上の新たな注意	全体像が見えにくい	鍵が集まる場所の守り	振り分けの判断の確認、専用モデルの置き場所とライセンス

安全性の評価：注意付きとした根拠

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Plano の判定は「注意付き」です。本体については、ライセンスが Apache-2.0 で条件が明快なこと、運営元が2022年作成の組織で、のちに上場企業による買収が公表されていること、公開済みのセキュリティ勧告が無いこと、精査の範囲で導入時に自動で動く処理が見当たらなかったことを確かめました。それでも注意付きとしたのは、振り分け用の専用モデルが本体と別のライセンスで配られ、商用で使うには別の契約が要ると書かれていること、そして弱点の報告窓口の方針が文書で示されていないことの二点からです。

開発の様子も、外から確かめられる範囲では落ち着いています。2026年8月の0.4.35版では、配布しているコンテナの中身を点検する仕組みで見つかった深刻度の高い指摘を直したことがリリースの説明に書かれており、配布物の点検に手を入れている様子がうかがえます。一方で、リポジトリには報告窓口の方針の文書が置かれていません。弱点を見つけた人が非公開で知らせる経路が文書で示されていない点は、調達の確認で押さえておきたいところです。

後で述べるとおり、振り分け用の専用モデルは別のライセンスで配られ、初期の状態では提供元の環境で動きます。そして、精査で問題が見つからなかったことは、安全の保証ではありません。中継役は社内のAIエージェントの通信がすべて通る場所なので、他の道具以上に慎重な確認が要ります。

注意点1：振り分け用モデルの既定は提供元の預かり環境

READMEの重要事項の欄には、Plano と専用のモデルの一群が、米国中部の地域で無料で預かり運用されていると書かれています。初めて試す人の手間を減らすためで、本番で規模を広げるには、モデルを自前で動かすか、提供元に連絡して利用の鍵を受け取るよう案内されています。

モデルの振り分けの説明書きでも、既定では提供元が預かる専用モデルの窓口を使うとされています。専用モデルは利用者の会話の履歴を読んで分類するため、初期の状態のまま使うと、社員や顧客の会話が提供元の環境へ送られることになります。説明書きには、その窓口で会話がどう保存・記録・利用されるかは書かれていませんでした。

企業で使う場合、この点は社内の情報の区分や、海外への持ち出しの規程と照らして判断する必要があります。説明書きが示す自前で動かす方法を選べば、会話を社外へ出さずに済む可能性がありますが、そのぶん専用モデルを動かす環境の用意と保守が要ります。Plano 本体はAIの計算に特別な装置を必要としないと説明されていますが、専用モデルを自前で動かす場合は別に考える必要があります。

注意点2：OSS本体と専用モデルでライセンスが違う

Plano 本体は Apache-2.0 ですが、振り分け用の専用モデルは違います。Hugging Face の公開ページでは、Plano-Orchestrator も Arch-Router も「Katanemo のライセンス」で配られています。Arch-Router のライセンスの文書を読むと、商用の目的で使う・改変する・配る場合は、DigitalOcean から別に商用のライセンスを受ける必要があると書かれています。許諾するかどうかは同社の判断に委ねられています。

ほかにも、配る場合には「DigitalOcean で作った」と目立つ形で示すこと、そのモデルをもとに作ったモデルの名前の先頭に社名を付けることなどの条件があります。準拠する法は米国コロラド州の法と定められています。Plano-Orchestrator のページは、同じ名前のライセンスの文書にリンクしていますが、個別の条件をこの記事で一つずつ確かめたのは Arch-Router の文書だけです。

つまり、本体はOSSとして自由に使えても、振り分けの判断を担うモデルを本番で使う段階で、別の契約の検討が要る可能性があります。専用モデルを使わず、名指しや社内の呼び名による振り分けだけにとどめれば、この問題は避けられるかもしれません。いずれにしても、本体とモデルのライセンスを分けて法務の確認にかけることが、導入前の必須の作業になります。

悪用されうるリスク：すべての通信が通る場所になる

Plano のような中継・データ層は、社内のAIエージェントへの問い合わせと、エージェントからモデルへの問い合わせがすべて通る場所になります。そのため、そこを乗っ取られたり、設定を書き換えられたりすると、防護フィルタを外す、振り分け先を差し替える、記録を止めるといったことが一か所でできてしまう可能性があります。これは中継役一般に言える推測で、Plano で実際にそうした被害が起きたという報告は、確認した範囲では見当たりませんでした。

振り分けをAIのモデルが判断する作りには、別の危険もあります。エージェントの説明文や利用者の発言の書き方によって、本来渡すべきでない権限の強いエージェントに問い合わせが渡る可能性です。また、専用モデルはシステムへの指示を見ずに利用者側の会話だけで判断するとされているため、会話に紛れ込ませた命令で振り分けの判断が揺さぶられる余地は、一般論として考えておくべきです。手口の詳細はこの記事では扱いません。

加えて、防護フィルタの中身が弱ければ、枠組みがあっても素通りされます。フィルタは問い合わせの手前で働くと説明されているため、エージェントが外から読み込んだ文書や道具の結果に紛れた命令は、別の守りで受け止める必要があります。中継役は守りを強める道具であると同時に、それ自体が最も固く守るべき対象でもある、という二面性を前提にしてください。

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

Plano を社内の共通の中継役として使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Plano を使うかどうかにかかわらず、AIエージェントの共通の中継役を置く企業に共通する対策があります。第一に、中継役の設定を変えられる人を絞り、変更の記録を残すことです。防護フィルタの並びや振り分け先は、一行の変更で会社全体の守りを変えうるため、変更は申請と承認を経る形にします。

第二に、エージェントやモデルへの直接の経路を残さないことです。中継役を素通りしてエージェントやモデルに届く経路があれば、フィルタも記録も効きません。第三に、振り分けの判断と防護フィルタの結果を定期的に人が抜き出して確かめます。権限の強いエージェントへ渡った問い合わせは、特に重点的に見ます。

第四に、報告窓口の方針の文書が無いことを踏まえ、更新と勧告を自分たちで見張る担当者を決めることです。リリースの一覧と勧告の欄を確かめる頻度を決めておきます。第五に、社内のAI利用の規程に、使ってよいエージェントとモデル、会話を送ってよい先、記録の保存期間、中継役の管理者、見直しの頻度を書き込みます。仕組みと規程の両方がそろって、初めて中継役は統制の役に立ちます。

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

Plano は、どのエージェントに渡すか、どのモデルを使うかの判断にAIのモデルを使います。便利な仕組みですが、何を許し、何を止めるかの判断そのものをAIに委ねてはいけません。AIに任せてよいのは、人が決めた候補と規則の範囲の中での振り分けと、怪しい兆しを拾って知らせるところまでです。

人が決めるのは、渡してよいエージェント、使ってよいモデルと提供元、防護フィルタで止める内容、記録の範囲です。AIのモデルが振り分けた結果や、フィルタが止めた結果については、なぜそう判断したかの根拠を記録に書かせ、人が確認する範囲を先に決めておくことが大切です。避けたい使い方を挙げます。

• 防護フィルタの枠組みを入れただけで、中身を作らないまま「防護済み」と扱う
• 試すための初期の状態のまま、社員や顧客の会話を提供元の預かり環境へ送り続ける
• 専用モデルのライセンスを確かめずに、商用の本番で使い始める
• 権限の強いエージェントへの振り分けを、AIのモデルの判断だけに任せて結果を確かめない
• 記録の割合を最大にしたまま、会話の断片が入る記録の保存先と閲覧できる人を決めない

中継・データ層は、うまく使えば社内のAIエージェント全体を見える形にする強い道具です。そのぶん、一か所の設定と判断の誤りが、すべてのエージェントに広がることを前提に、人の確認を運用に組み込んでください。

よくある質問：Planoを入れれば紛れ込んだ命令への備えは十分か

答えは「備えをかける場所はできるが、それだけでは足りない」です。Plano のフィルタの連鎖は、問い合わせがエージェントやモデルに届く前に点検をかける場所を用意します。しかし、何を危険とみなすかの中身は利用者が用意するもので、公式の説明書きには、どの種類の攻撃にどこまで効くかの記述はありません。

また、AIエージェントへの攻撃でよく問題になるのは、エージェントが読み込んだ外部の文書や道具の結果に命令が紛れ込む形です。フィルタが問い合わせの手前で働く作りである以上、エージェントが途中で読む情報への備えは、道具の権限を絞るなど別の守りと組み合わせる必要があります。答えの側の点検も、確認した説明書きには書かれていませんでした。

「振り分けをAIに任せず、名指しだけで使えばよいのか」という問いもありそうです。説明書きでは、名指しや社内の呼び名での振り分けは、結果が予測しやすい方法とされています。権限の強いエージェントやモデルは名指しで扱い、AIの判断による振り分けは影響の小さい範囲から試す、という分け方は、一つの現実的な選択肢と考えられます。

• Plano の機能・設定の既定値・ライセンス・リリースは、GitHubのリポジトリ（README・リリースの一覧・セキュリティの欄）、公式の説明書き、Hugging Face の専用モデルの公開ページとライセンスの文書、公式サイト、DigitalOcean の買収の発表文を2026年10月22日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 提供元の預かり環境で会話がどう保存・利用されるか、答えの側を点検する仕組みの有無、Plano-Orchestrator のライセンスの個別の条件、以前の名前は、確認できませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Plano は、AIエージェントの手前とモデルの手前に置き、エージェントへの振り分け、防護フィルタ、通信の記録とシグナル、モデルの振り分けを一か所にまとめる Apache-2.0 のOSSです。エージェントごとにばらばらだった守りと記録を共通の場所に集められる点は、企業のAI統制にとって大きな利点です。

一方で、防護フィルタは枠組みで中身は利用者が作ること、振り分け用の専用モデルは初期の状態では提供元の米国の環境で動き、本体とは別の商用条件付きのライセンスであることを押さえておく必要があります。防護の中身と会話の送り先とライセンスを先に確かめ、振り分けと遮断の根拠を人が確かめることが、Plano のような中継・データ層との現実的な付き合い方です。

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