Agnoとは｜pip installが14.7秒で終わる理由と、テレメトリ既定ONの中身をコードで実測

Agno は、AIエージェント基盤を「作る・動かす・運用する」ための Python フレームワークだ。Apache-2.0、⭐42,491（2026-10-02時点）、最新は 3.1.0（タグ253本）。READMEは「Build, run, and manage agent platforms.」と短い。機能一覧は公式ドキュメントを読めば分かるので、本記事では採用前に実際に知りたい2点——何が入って何が入らないのかと、黙って何を送るのか——をコードと実行で確かめた。

エージェント基盤の選び方全体はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証にまとめてある。本記事はその枝として、Agno 単体を測る。

Agnoとは：SDK・ランタイム・Web UIの三段構え

READMEの構成はシンプルだ。「Agnoはエージェント基盤のためのフレームワークとランタイムである。Agno SDK でエージェント基盤を作り、サービスとして動かし、Web UI で管理する」。つまりライブラリだけでなく、本番で動かす器まで含めて配るという立て付けになっている。

Features として並ぶのは次のようなものだ。

・Production API：SSE と WebSocket を備えた50以上のエンドポイント
・Storage：セッション・メモリ・ナレッジ・トレースを自分のデータベースに置く
・100+ integrations：GitHub・Slack・Postgres などの既製ツールキット
・Human approval：確認のために実行を一時停止し、管理者承認が要るツールをブロックする
・Security：JWT ベースの RBAC とマルチユーザー・マルチテナント分離
・Interfaces：Slack・Telegram・WhatsApp・Discord・AG-UI・A2A で公開
・Scheduling：外部インフラ無しで cron スケジュールとバックグラウンドジョブ

「エージェントを書くライブラリ」というより、社内に1つ置く基盤を想定した機能構成だ。当サイトでは以前、この上に乗るテンプレートをAgno agent-platform徹底解説：エージェントがエージェントを育てる自走型基盤で扱っている。本記事はその土台にあたるフレームワーク本体を見る。

ライセンスが Apache-2.0 である点は書き留めておきたい。この界隈は MIT が多く、同日に測った Pydantic AIとは｜APIキー0本でエージェントの往復を実測し744モデル文字列を数える も MIT だった。Apache-2.0 は特許条項を含むので、企業で採用するときの審査項目が少し変わる。

pip install が14.7秒で終わる理由

まず入れた。空の venv に pip install agno だけを実行する。

python3 -m venv .venv && . .venv/bin/activate
time pip install agno
# real 0m14.699s
du -sh .venv && pip list | wc -l
# 121M   /  35

14.7秒・35パッケージ・121MB。エージェントフレームワークとしてはかなり軽い。ただし、これには理由がある。そのまま動かすと止まるのだ。

from agno.agent import Agent
Agent().run("hi")
# ImportError: `openai` not installed. Please install using `pip install openai`

モデルプロバイダのSDKが同梱されていない。agno/models には57のモジュールが入っているが、それらは「アダプタ」であって、実際の通信を行うSDK（openai など）は利用者が選んで入れる方式になっている。足してみると、

pip install openai
du -sh .venv && pip list | wc -l
# 150M   /  41

150MB・41パッケージ。それでも軽い部類だ。同じ日に同じマシンで測った Pydantic AI は 61.7秒・252MB・106パッケージだったので、倍以上の差がある。

念のため確認すると、この14.7秒は依存が少ないからであって、ネットワークやキャッシュの当たり外れではない。同じ venv で続けて pip install openai を実行しても追加は6パッケージ・29MBで済んだ。

ここは優劣ではなく方針の差だ。Pydantic AI は744のモデル文字列を最初から抱え、文字列の差し替えだけでプロバイダを切り替えられる。Agno は必要なSDKだけを入れさせる。コンテナイメージを小さくしたい、依存の棚卸しを厳しくしたい、という事情があるなら後者が効く。逆に「とりあえず全部入りで試したい」なら前者が速い。

鍵が無いときの落ち方も見ておいた。openai を入れたうえで鍵なしで実行すると、こう出る。

ERROR  Model authentication error from OpenAI API: OPENAI_API_KEY not set.
       Please set the OPENAI_API_KEY environment variable.
ERROR  Error in Agent run: OPENAI_API_KEY not set. ...

どの環境変数を入れればよいかを名指しする。例外ではなくERRORログとして出る点は、Pydantic AI が UserError を投げるのと作法が違うので、スクリプトで扱うなら戻り値の確認が要る。

「100以上の連携」を数えて確かめる

READMEの「100+ integrations」も数えられる主張なので、インストール後のパッケージを走査した。

import agno, os, pkgutil
base = os.path.dirname(agno.__file__)
for sub in ['tools', 'models', 'db', 'knowledge', 'os']:
    mods = [m.name for m in pkgutil.iter_modules([os.path.join(base, sub)])
            if not m.name.startswith('_')]
    print(sub, len(mods))
# tools 153 / models 57 / db 21 / knowledge 15 / os 23

tools が153モジュール。看板の「100+」は控えめな表現だった。models 57・db 21・knowledge 15・os 23 と、周辺も揃っている。これだけの数を抱えてインストールが軽いのは、各モジュールが対応SDKを遅延importしているからで、先ほどの ImportError はその設計の裏返しだ。使うツールキットの依存だけが必要になる。

本体に何が入っているか——os と db の中身

「フレームワーク＋ランタイム」という自己紹介が具体的に何を指すのかは、agno/os と agno/db を見ると早い。どちらもインストール直後から入っている。

# agno/os（23モジュール）
app, auth, authz, checkpoints, config, event_streams, interfaces, job_queue,
managers, mcp, mcp_auth, mcp_auth_builtin, mcp_results, middleware, public,
router, routers, schema, scopes, service_accounts, services, settings, utils

# agno/db（21モジュール）
async_postgres, base, clickhouse, dynamo, firestore, gcs_json, in_memory, json,
migrations, mongo, mysql, postgres, redis, schemas, singlestore, sql, sqlite,
surrealdb, valkey, filter_converter, utils

os 側に auth / authz / scopes / service_accounts / middleware / job_queue が並んでいるのが特徴的だ。これは「エージェントを書くライブラリ」ではなく、認証・認可・ジョブキューまで含んだアプリケーションサーバを想定していることを意味する。READMEの「JWTベースのRBACとマルチテナント分離が最初から入っている」という主張の実体がここにある。mcp 系のモジュールが3つあるのも、MCPサーバとしての公開を前提にしているからだろう。

db 側は21の実装が並ぶ。PostgreSQL・MySQL・SQLite といった定番に加え、ClickHouse・DynamoDB・Firestore・MongoDB・Redis・Valkey・SingleStore・SurrealDB・GCS（JSON）まである。migrations が同梱されているので、スキーマの面倒も見る設計だ。セッション・メモリ・ナレッジ・トレースを「自分のデータベースに」置くという方針が、この物量に表れている。

knowledge は15モジュールで、chunking / embedder / reader / reranker / loaders と RAG の部品が一通り揃う。ツールキット153本の顔ぶれも、arxiv・confluence・bitbucket・clickup・crawl4ai・browserbase のように業務システム寄りのものが目立った。

まとめると、Agno が軽いのは機能が少ないからではない。アプリケーションサーバもDBアダプタもRAG部品も最初から入っていて、外に出してあるのはモデルSDKだけという配り方になっている。

テレメトリ：既定で送る。何を送り、どう止めるか

ここが本記事で一番時間をかけた部分だ。READMEには1段落だけ、こう書いてある。

Agno はエージェント実行ごとにテレメトリイベントを送る。どのモデルプロバイダを優先すべきかを知るためである。プロンプト・メッセージ・出力は決して送られない。AGNO_TELEMETRY=false で無効化できる。

書いてあることが本当かをコードで確かめた。

送信される中身は get_telemetry_data() に定義されていて、16項目だった。

{
  "agent_id": ..., "db_type": ..., "model_provider": ..., "model_name": ...,
  "model_id": ..., "parser_model": ..., "output_model": ...,
  "has_tools": bool, "has_memory": bool, "has_learnings": bool,
  "has_reasoning": bool, "has_knowledge": bool, "has_input_schema": bool,
  "has_output_schema": bool, "has_team": bool,
}

識別子とモデル名、あとは真偽値だけ。プロンプトも、メッセージも、出力も入っていない。READMEの記述はコードと一致していた。送信先は agno/api/settings.py の api_url = "https://os-api.agno.com"。

止め方も確かめた。判定しているのはこの3行だけだ。

def set_telemetry(agent: Agent) -> None:
    telemetry_env = getenv("AGNO_TELEMETRY")
    if telemetry_env is not None:
        agent.telemetry = telemetry_env.lower() == "true"

つまり true 以外の値はすべて停止側に倒れる。実際に7通り試した。

打ち間違えても送信側には倒れない設計で、プライバシー側に安全側倒れする。加えて、この判定は送信の直前（log_agent_telemetry の冒頭）で行われるので、Agent を作ったあとに環境変数を設定しても効く。送信処理自体は try の中にあり、コメントに「テレメトリの失敗が実行の結果を変えてはならない」と明記されていた。

評価としては、既定ONであること自体は好みが分かれるが、やり方は誠実だ。READMEに明記があり、中身が識別子だけで、止め方が1つの環境変数で、打ち間違えが安全側に倒れ、失敗しても本処理を壊さない。12-Factor Agents完全解説：本番投入できるLLMエージェント設計12原則を一次ソースで読むが言うところの「エージェントを普通のソフトウェアとして扱う」観点でも、この外部送信の切り分けは素直な実装だった。社内ポリシーで外部送信が禁止なら、AGNO_TELEMETRY=false をコンテナの環境変数に1行入れておけばよい。

採用を検討するときに見ておきたい点

測った範囲から、判断材料になりそうなところを挙げておく。

・依存を自分で選びたいなら向く。モデルSDKが外に出ているので、コンテナイメージを小さく保ちやすい。使わないプロバイダのSDKが脆弱性勧告に引っかかる、という事故も減る
・「とりあえず全部入り」を期待すると最初でつまずく。pip install agno だけでは動かず、ImportError で止まる。手順書を書くときは必ずプロバイダSDKの行を入れる
・外部送信のポリシーがある組織は最初に1行。AGNO_TELEMETRY=false をコンテナの環境変数に置く。打ち間違えても送信側には倒れないが、意図を残す意味でも明示したい
・Apache-2.0 であることを法務の確認項目に入れる。MIT 前提の社内テンプレートだと審査の流れが変わる
・タグが253本ある。3.x 系に入ったばかりなので、バージョン固定の運用を前提にしたほうが安全

逆に、当記事ではAgentOS（Web UI）も本番APIもスケジューリングも起動していない。READMEが掲げる「50以上のエンドポイント」「マルチテナント分離」といった売り文句は、モジュールの存在までしか確認できていない。ここは実際にコンテナを立てて触らないと評価できない領域だ。

最後に、当記事で確かめた範囲を整理しておく。

軽さの理由も、送信内容も、どちらも読めば分かるところに書いてあった。READMEの1段落を読んで終わりにせず、get_telemetry_data() の16項目まで追えたこと、true 以外が全部停止側に倒れると実行で確かめられたこと——採用前に測るべきことが、実際に測れる作りになっている。機能の多さより、この「確かめられる度合い」がフレームワーク選びでは効くと思う。

参照ソース

・agno-agi/agno — GitHubリポジトリ（main・最終コミット 150a4e4・2026-10-02 を clone して確認）: https://github.com/agno-agi/agno
・agno — PyPI（3.1.0 を実際にインストールして計測）: https://pypi.org/project/agno/
・agno LICENSE — Apache License 2.0: https://github.com/agno-agi/agno/blob/main/LICENSE
・agno README の Telemetry 節 — 送信内容と無効化の公式記述: https://github.com/agno-agi/agno#telemetry