メインコンテンツへスキップ
PromptQuorum人のために設計。 AI向けに構造化。
ホーム/ローカルLLM活用
Overview & Reference

Plano レビュー: エージェント型アプリ向けEnvoyベースAIプロキシ

·11分で読めるHans Kuepper 著 · PromptQuorum創設者 · オープンウェイト/オープンソースAIの発見エンジン

Planoは、Katanemoが開発した、エージェント型アプリケーション向けの無料・オープンソースなEnvoyベースAIネイティブプロキシサーバー兼データプレーンであり、アプリケーションコードの外側でLLMルーティング、エージェントオーケストレーション、可観測性、ガードレールを処理します。 Apache 2.0ライセンスで、セルフホスト型のアウトオブプロセスプロキシとして動作し(ホスト型SaaSではない)、bring-your-own-model方式です——OpenAI、Anthropic、その他のプロバイダーに対して設定するか、ローカルモデルに向けて設定でき、ルーティングの判断自体はPlano自身の小型オーケストレーターモデルが担います。

重要なポイント

  • Plano(github.com/katanemo/plano)は無料・オープンソースのセルフホスト型AIプロキシ兼データプレーンであり、ホスト型SaaS製品ではない
  • Katanemoが開発、Envoy自身のコアコントリビューターによってEnvoy上に構築
  • GitHubリポジトリのライセンスファイルで確認済みのApache 2.0ライセンス
  • 自身のREADMEによる4つの中核機能: エージェントオーケストレーション、モデルルーティング(「Model Agility」)、ゼロコード可観測性(「Agentic Signals」とOpenTelemetry)、ガードレール/モデレーションのFilter Chains
  • ルーティングは、汎用LLMやルールのみのフレームワークではなく、専用の約40億パラメータのオーケストレーターモデル(「Plano-Orchestrator」)を通じて実行される
  • このレビュー時点でGitHubスター7,050以上、フォーク480以上

📍 一文で説明

Planoは、Katanemoが開発した、GitHubスター7,050以上を持つ無料・オープンソース(Apache 2.0)のEnvoyベースAIネイティブプロキシサーバー兼データプレーンで、アプリケーションコードの外側でエージェント型アプリケーションにLLMルーティング、エージェントオーケストレーション、可観測性、ガードレールを追加します。

💬 簡潔に説明

Planoは、AIエージェントの前段に配置して実行するセルフホスト型プロキシです。ルーティングロジック、テレメトリ、安全フィルターを各エージェントに自作する代わりに、YAML設定ファイルでエージェントとモデルプロバイダーを宣言すれば、適切なモデルの選択、何が起きたかのトレース、ガードレールの適用をPlanoが処理します——Plano自体にライセンス料はかからないため無料です。

Plano(github.com/katanemo/plano)は、Envoy自身のコアコントリビューターによってEnvoy上に構築され、Katanemoが開発した、無料・オープンソース・Apache 2.0ライセンスのAIネイティブなプロキシサーバー兼データプレーンです。エージェント型アプリケーションが本来コードベースごとに再実装する「隠れたミドルウェア」——エージェントのルーティングとオーケストレーション、LLMモデルのルーティング、可観測性シグナルとトレース、安全性とモデレーションのためのガードレールフィルター——を一元化しており、GitHubスターは7,050を超えます。このレビューでは、Planoが実際に何をするか、インストールと実行の方法、費用、そして誰に向いているかを扱います。

Planoとは何か?

Planoは、エージェント型アプリケーションと、それらが呼び出すLLMプロバイダーやサブエージェントの間に配置され、ルーティング・オーケストレーション・可観測性・ガードレールを1つの層で処理する、セルフホスト型のアウトオブプロセスプロキシ兼データプレーンです。 自身のGitHubの説明では「エージェント型アプリ向けのAIネイティブなプロキシサーバー兼データプレーン」と呼ばれており、ルーティングやモデレーションといったインフラ的な関心事をアプリケーションコードから切り離し、共有された設定可能な層に移すことを目指しています。

  • 製品の種類: 自分でデプロイするセルフホスト型プロキシ/データプレーン(Dockerコンテナまたはビルド済みバイナリ)——ホスト型APIやSaaSゲートウェイではない
  • 開発元: Katanemo、リポジトリをホストするGitHub組織による
  • リポジトリ: github.com/katanemo/plano、2024年7月9日作成
  • ライセンス: Apache 2.0、GitHubリポジトリのライセンスファイルによる
  • 基盤: 広く使われているオープンソースのエッジ/サービスプロキシであるEnvoy上に、Envoy自身に携わったコントリビューターによって構築——Plano自身のREADMEによる
  • 規模: このレビュー時点でGitHubスター7,050以上、フォーク480以上、オープンイシュー140件

Planoのプロジェクト沿革とバージョンの節目

PlanoのGitHubリポジトリは2024年7月に作成され、それ以来プロジェクトは継続的にリリースを重ね、LLMルーティング、エージェントオーケストレーション、可観測性の機能を活発に開発しています。Planoは、ルーティングの判断に使われる専用のオーケストレーターモデルを含め、Katanemo自身のLLM研究に裏打ちされていると位置づけています。

  1. 1
    リポジトリ作成 — 2024年7月9日
    Why it matters: GitHubのリポジトリメタデータによると、Planoの正式なGitHubリポジトリ(katanemo/plano)が作成されました。
  2. 2
    v0.4.36 — 2026年8月19日: このレビュー時点で最新のタグ付きリリース
    Why it matters: このレビュー時点でGitHub上に公開された最新のリリースです。このレビューの公開日以降に出たものについては、[リリースページ](https://github.com/katanemo/plano/releases)を直接確認してください。
  3. 3
    メインブランチでの継続的な開発
    Why it matters: GitHubのリポジトリメタデータでは、最新のタグ付きリリース後にもメインブランチへのコミットが確認でき、最新のバージョンタグを超えた継続的な開発が示唆されています——最新のコミットとの機能的な同等性を前提とする前に、現在のリリース状況を確認してください。

Planoは実際に何をするか?

Planoの機能セットは、エージェント型アプリのインフラ的な関心事をアプリケーションコードから切り離し、共有のセルフホスト型プロキシ層に移すことに主眼を置いています。以下は、Plano自身のGitHubのREADMEとドキュメントによる、各機能が実際に行うことです。

  • エージェントオーケストレーション — アプリケーションコードを変更することなく、YAML設定で宣言されたエージェント間を低レイテンシでルーティング。新しいエージェントは、ルーティングロジックを書き直すのではなく設定を編集するだけで追加可能
  • モデルルーティング(「Model Agility」) — 明示的なモデル名、セマンティックエイリアス、または設定された優先度による自動選択でリクエストをルーティングし、アプリケーションコードが特定のプロバイダーをハードコードするのではなく、論理的なモデル名を呼び出せるようにする
  • Agentic Signals — Plano独自の用語で、使用状況/挙動シグナルのゼロコード取得を指し、プロキシするすべてのエージェントにわたって発行されるOpenTelemetry互換のトレースとメトリクスも含む
  • ガードレールおよびモデレーションのFilter Chains — ジェイルブレイク対策、モデレーションポリシー、メモリ一貫性の挙動を、個々のエージェントではなくプロキシ層に組み込むための設定可能な仕組み
  • 専用のルーティングモデル — Planoのreadmeによれば、ルーティングの判断は汎用のLLM呼び出しや純粋なルールベースのルーターではなく、Plano自身の約40億パラメータの「Plano-Orchestrator」モデルを通じて行われる
  • フレームワークおよび言語に非依存 — エージェントはOpenAI互換のチャット補完エンドポイントを実装する単なるHTTPサーバーであるため、Planoはどの言語・AIフレームワークで書かれたエージェントとも動作する
  • LLMゲートウェイモード — 自身のドキュメントによれば、Planoはエージェントオーケストレーション機能とは独立して、アプリケーションサービスからの純粋なLLMルーティングゲートウェイとしても使用できる

使用例: Planoの2つの使い方

これらは、Plano自身のREADMEに文書化された例から構成した具体的なワークフローであり、仮定的なユースケースではありません。

ルーティングロジックを書かずにマルチエージェントアプリをルーティングする

config.yamlファイルに、エージェント(例えば天気エージェントとフライトエージェント。それぞれOpenAI互換の/v1/chat/completionsエンドポイントを持つ単なるHTTPサーバー)とモデルプロバイダーを宣言し、Planoのplano_orchestrator_v1ルーターを使うリスナーも合わせて定義します。planoai up config.yamlを実行してから、Planoのリスナーポートに1つの会話リクエストを送信すると——アプリケーションコードにルーティングロジックを一切含めることなく、Planoが意図を分類して自ら正しいエージェント(または複数のエージェント)にルーティングします。

Planoを純粋にLLMゲートウェイとして使う

既存のエージェントやアプリケーションコードのOpenAIクライアントのベースURLを、特定のプロバイダーのAPIではなくPlanoのローカルゲートウェイポートに向けます。すると、フルのエージェントオーケストレーション設定を必要とせずに、Planoは自身のモデルルーティング設定に基づき、そのトラフィックのモデル選択・フォールバック・トレーシングを処理します——マルチエージェントオーケストレーションではなく集中管理されたLLMルーティングのみが必要な場合に有用です。

Planoの料金: 本当に無料か?

Plano自体は無料でオープンソース(Apache 2.0)であり、セルフホストにライセンス料はかかりません。 微妙な点は、そのルーティングを何が動かしているかです。PlanoとPlanoファミリーのLLM(Plano-Orchestratorなど)は、セットアップなしの初回利用体験を開発者に提供する目的で、KatanemoによってUS-central地域で無料ホストされています——プロジェクト自身のREADMEによれば、この無料ホスト層は開発用であり、本番規模を想定したものではありません。

  • Plano自体のソフトウェア: 無料、オープンソース、Apache 2.0ライセンスで、プロキシ自体に有料プランはない
  • Planoファミリーのルーティング/オーケストレーターモデル: Plano自身のREADMEによれば、初回利用の開発者体験のためUS-centralで無料ホストされる
  • KatanemoのREADMEによれば、本番規模で運用するには、これらのルーティングモデルを自分でローカルにセルフホストするか、Discord経由でKatanemoに連絡してホスト型APIキーを取得する必要がある——このホスト型キーオプションについて、このレビューでは公開のセルフサービス料金ページは見つからなかった
  • LLMプロバイダーの費用は別: Planoを通じてOpenAI、Anthropic、その他のプロバイダーにリクエストをルーティングしても、そのプロバイダーが請求する分の費用はかかる——Planoはモデルルーティング層としての役割上、自身でマークアップを追加することはない

Plano vs. LiteLLM

PlanoとLiteLLMはどちらもLLMトラフィックを管理するセルフホスト型の層ですが、出発点が異なります。LiteLLMは主に、100以上のLLMプロバイダーをOpenAI互換の単一インターフェースで呼び出すための統一API/SDKおよびプロキシであるのに対し、Planoは単なるモデルルーティングではなく、エージェントオーケストレーションを第一級機能とするEnvoyベースのデータプレーンとして構築されています。

基盤

Plano vs. LiteLLM:
PlanoはEnvoyプロキシ上に構築されている。LiteLLMはPythonネイティブのSDKおよびプロキシサーバーで、Envoyベースではない。

エージェントオーケストレーション

Plano vs. LiteLLM:
PlanoはYAMLで宣言されたエージェントを介したマルチエージェントルーティングを中核の第一級機能として扱う。LiteLLMは主にエージェント間オーケストレーションではなくLLM/プロバイダーのルーティングに重点を置く。

ルーティングの仕組み

Plano vs. LiteLLM:
Planoは意図ベースのルーティングのために専用の約40億パラメータのオーケストレーターモデルを使用する。LiteLLMは主に明示的な設定ルール、負荷分散、フォールバックリストによってルーティングする。

可観測性

Plano vs. LiteLLM:
Planoはそのテレメトリを「Agentic Signals」とOpenTelemetryと呼ぶ。LiteLLMは使用状況の追跡、支出ログ、Langfuseなどの可観測性ツールとの統合を提供する。

ライセンス

Plano vs. LiteLLM:
両方とも、各プロジェクト自身のリポジトリによれば、コアのオープンソース提供物についてApache 2.0である。

どちらのツールもコア部分はセルフホスト型で無料です。実務上の選択は、Envoy級のプロキシインフラとネイティブなエージェントオーケストレーション(Plano)が必要か、それとも幅広いプロバイダー互換リストを備えた、よりシンプルでプロバイダールーティング中心のゲートウェイ(LiteLLM)が必要かによります。両者とも頻繁に更新されるため、選択前に各プロジェクト自身のドキュメントで現在の機能的な同等性を確認してください。

ディレクトリで比較する

Planoは誰に向いているか?

Planoが適しているかどうかは、単一の単純なLLM呼び出しではなく、ルーティング・可観測性・ガードレールのための共有インフラを必要とするマルチエージェントアプリケーションを構築しているかどうかによります。

こんな方にはPlanoがおすすめ

  • 複数のエージェントやモデルプロバイダーを持つエージェント型アプリケーションを構築しており、ルーティング・オーケストレーション・可観測性を自分のアプリケーションコードの外側で処理したい方
  • 軽量なアプリケーション層のラッパーではなく、Envoyベースの本番グレードのプロキシ基盤が欲しい方
  • 共有のFilter Chain層を通じて、エージェント間で一貫してガードレールとモデレーションポリシーを適用する必要がある方
  • DockerやビルドしたバイナリでのインフラのセルフホストとYAMLでの設定に抵抗がない方
  • PlanoがOpenAI互換のHTTPエンドポイントしか必要としないため、エージェントをどの言語・フレームワークのままにしておきたい方

こんな方には他の選択肢がおすすめ

  • マルチエージェントのルーティングやオーケストレーションの要件がなく、単一プロバイダーへのシンプルなLLM呼び出しだけが必要な方——直接のSDK呼び出しの方がシンプルかもしれません
  • セルフホストや設定ファイルのセットアップなしで、完全にマネージドなホスト型ゲートウェイが欲しい方——このレビューでは、無料の開発層のホスト型ルーティングモデルを超えるような、Katanemoによるマネージド提供は見つかりませんでした
  • Envoyベースのプロキシではなく、軽量でPythonネイティブなルーティングライブラリが必要な方——上記のPlano vs. LiteLLM比較を参照してください
  • ノーコードのターンキーセットアップが欲しい方——Planoは、YAML設定の編集と前提条件ガイドに従うことが必要です

競合とその他の選択肢

Planoが最もよく比較されるのはLiteLLM、AIClient2API、Langfuseです——最大の差別化要因は、純粋にアプリケーション層のルーティングライブラリや可観測性専用ツールではなく、ネイティブなマルチエージェントオーケストレーションを備えたEnvoyベースのデータプレーンであることです。

Tool
Best known for
Link
LiteLLMOpenAI互換の単一APIを通じて100以上のLLMプロバイダーを呼び出す統一プロキシ/SDKLiteLLM レビュー
AIClient2APIさまざまなAIクライアントプロトコルを統一APIエンドポイントに変換する軽量なローカルプロキシAIClient2API レビュー
LangfuseオープンソースのLLM可観測性・トレーシング・評価プラットフォームLangfuse レビュー

このリストは、ルーティング/ゲートウェイ/可観測性の分野でPlanoと比較されることが多いツールを反映したものであり、PromptQuorumによる独自ランキングではありません——PlanoのエントリーもあるPromptQuorumの、定期的に更新される全カタログについてはLocal LLM Software Directoryを参照してください。選ぶ前に各ツールの現在の料金と機能を確認してください。

ディレクトリで比較する

Plano評価時のよくある間違い

Planoに関する混乱の多くは、その一般的すぎる名前、ホスト型SaaSであるという思い込み、あるいは「無料」が何をカバーするかについての不明瞭な想定から生じます。

間違い1: 無関係な「Plano」プロジェクトと混同する

「Plano」はよくある言葉(テキサス州の都市名、「計画」を意味するポルトガル語/スペイン語の単語)であるため、無関係なリポジトリや製品が同じ名前を共有しています。このPlanoについての事実を引用する前に、具体的にgithub.com/katanemo/planoを見ているか確認してください。

間違い2: Planoをホスト型SaaSゲートウェイだと思い込む

Planoは自分でデプロイするセルフホスト型ソフトウェア(Dockerコンテナまたはビルド済みバイナリ)です——サインアップしてすぐ使えるホスト型APIサービスではありません。ただし、KatanemoはPlanoファミリーのルーティングモデルを開発用に無料でホストしています。

間違い3: 「無料」がホスト型ルーティングモデルの無制限の本番利用をカバーすると思い込む

Plano自身のオーケストレーターモデルの無料US-centralホスティングは、PlanoのREADMEによれば、明示的に初回利用の開発者体験として位置づけられています。本番規模の利用には、これらのモデルを自分でセルフホストするか、Katanemoにホスト型APIキーを問い合わせる必要があります。

間違い4: PlanoがLLM推論自体を実行すると思い込む

Planoはルーティングおよびオーケストレーション層であり、トラフィックをルーティングする先のモデル(自身の小型オーケストレーターモデルを除く)の推論エンジンではありません——リクエストをプロキシする先のLLMプロバイダーやローカルモデルサーバーへのアクセスは引き続き必要です。

よくある質問

Planoとは何ですか?

Plano(github.com/katanemo/plano)は、Katanemoが開発した、エージェント型アプリケーション向けの無料・オープンソース(Apache 2.0)のEnvoyベースAIネイティブなプロキシサーバー兼データプレーンで、LLMルーティング、エージェントオーケストレーション、可観測性、ガードレールを処理します。

Planoは無料ですか?

はい、Plano自体は無料でオープンソースであり、セルフホストにライセンス料はかかりません。Katanemoは初回利用の開発者体験のため、Plano自身のルーティング/オーケストレーターモデルもUS-centralで無料ホストしています。これらのモデルを本番規模で利用するには、セルフホストするかDiscord経由でホスト型APIキーを取得する必要があります。

Planoのインストール方法は?

Plano自身のクイックスタートガイドに従って前提条件をインストールし、エージェントとモデルプロバイダーを宣言するYAML設定に対してplanoai up config.yamlを実行します。

Planoはホスト型サービスですか、それともセルフホスト型ソフトウェアですか?

Planoはセルフホスト型です。DockerコンテナまたはビルドしたバイナリとしてPlano自体を、自分のエージェントやサービスと並べて自分でデプロイします。Katanemoは別途、Plano自身の小型オーケストレーターモデルを開発利用レベルで無料ホストしています。

Planoは実際に何をルーティングしますか?

PlanoはLLMおよびエージェントのトラフィックをルーティングします。意図に基づいて複数のエージェント間をルーティングでき、また明示的なモデル名、セマンティックエイリアス、自動的な優先度ベースの選択により、LLM APIの呼び出しを特定のモデルにルーティングできます。

PlanoはEnvoy上に構築されていますか?

はい、自身のREADMEによれば、PlanoはEnvoy自身に携わったコントリビューターによってEnvoy上に構築されており、インプロセスのライブラリではなくアウトオブプロセスのデータプレーンとして機能します。

Planoを開発しているのは誰ですか?

katanemo/planoリポジトリをホストするGitHub組織によれば、KatanemoがPlanoを開発しています。

Planoはどのプログラミング言語やフレームワークでも動作しますか?

はい——自身のドキュメントによれば、エージェントはOpenAI互換のチャット補完HTTPエンドポイントを実装するだけでよいため、Planoはどの言語・AIフレームワークで書かれたエージェントとも動作します。

Planoが機能するには自身のモデルが必要ですか?

Planoのルーティングの判断は、専用の約40億パラメータのオーケストレーターモデルを通じて行われますが、エージェントが実際に使用するLLMの応答自体は、Planoがトラフィックをルーティングする、設定済みの任意のプロバイダー(OpenAI、Anthropic、ローカルモデルなど)から来ることができます。

PlanoはLiteLLMとどう違いますか?

Planoはネイティブなマルチエージェントオーケストレーションを中核機能とするEnvoyベースのデータプレーンです。LiteLLMは主に100以上のLLMプロバイダーへの呼び出しを統一することに重点を置くPythonネイティブのSDK/プロキシです。詳細は上記のPlano vs. LiteLLM比較を参照してください。

PromptQuorumはPlanoの主張を独自に検証しましたか?

このレビューは、PromptQuorumによる実機ベンチマークではなく、Plano自身のGitHubリポジトリ、README、ドキュメントに基づいています。

情報源

← ローカルLLM活用 に戻る

MCP