AIエージェントを作ったことがある人なら、この徒労感に覚えがあるはずです。頑張って1体組み上げても、評価は手作業、改善は思いつきで、気づけば放置——「作って終わり」で、育てるサイクルが回らない。しかも便利なSaaSに乗せれば、今度は大事なデータを他社に預ける不安がついて回る。agent-platform-railway（agno-agi製）は、この2つの痛みに同時に答える、“エージェントがエージェントを育てる”自走型のエージェント基盤テンプレートです。GitHubの一文がそのものずばりで、「エージェントで、エージェントを作り・動かし・評価し・改善するプラットフォーム」。土台にはAIエージェントフレームワークのAgnoを採用し、ライセンスはApache-2.0です。

この記事を読むと、①agent-platform-railwayで結局何ができるのか（Agnoベースのエージェント基盤を自分のクラウドに立て、コーディングエージェント自身にエージェントを作成・評価・改善させる）、②どんな課題を解決するのか（「作って終わり」問題と、データをSaaSに預ける不安）、③何を代替できるのか（自前のエージェント基盤構築＋評価パイプライン＋デプロイ設定）が分かります。エージェントフレームワークの全体像を先に押さえたい方は、AIエージェントフレームワーク徹底比較2026を合わせて読むと、Agnoとこのテンプレートの立ち位置が立体的に掴めます。

agent-platform-railway：Agnoフレームワーク上に構築された、エージェント自身がエージェントを作成・評価・改善する自走型のエージェント基盤テンプレート。データは自分のDB・自分のクラウドに残る
agent-platform-railwayは、コーディングエージェント自身がエージェントを育てる自走ループを、自分のクラウドの中で回す基盤テンプレート。
この記事のポイント
  • ・agent-platform-railwayは、Agno上に構築された“自走型”エージェント基盤テンプレート（Apache-2.0）。
  • ・コーディングエージェント（Claude等）がスキルでエージェントを作成・拡張・改善・評価する。
  • ・UIのAgent Builderで、自然文からエージェント・チーム・ワークフローを作れる。
  • ・「すべて自分のクラウドで動き、データは自分のDBに残る」——SaaSにデータを預けない設計。
  • ・ローカルはDocker、本番はRailwayスクリプト1発。本番はJWT認可がデフォルト。

1. agent-platform-railwayとは：エージェントがエージェントを育てる自走型基盤

agent-platform-railwayの全体像：Agnoを土台に、コーディングエージェントがスキルでエージェントを作り、UIのAgent Builderで自然文から構築、すべて自分のクラウドとDBで動く構造
agent-platform-railwayの全体像。Agnoを土台に、AI自身がエージェントを育てるループを自分のクラウドで回す。

agent-platform-railwayは、AIエージェントを「作る・動かす・評価する・改善する」までを、エージェント自身の力で回すためのプラットフォームのテンプレートです。作者はAgnoを開発するagno-agi。ここでまず区別すべきは、Agno（フレームワーク）とこのリポジトリ（テンプレート）の関係です。

・Agno：AIエージェントを構造的に開発するためのフレームワーク（土台のライブラリ）
・agent-platform-railway：そのAgnoの上に、エージェント本体・評価・ワークフロー・デプロイスクリプト・コーディングエージェント用スキルまで一式そろえた、すぐ動かせる雛形

つまりこのリポジトリは、「Agnoで何ができるか」を自走型プラットフォームという完成形で見せてくれる出発点です。名前に「railway」が付くとおり、クラウドのRailwayへの本番デプロイまで含めて設計されているのが特徴です。

そして最大の思想が、「エージェントで、エージェントを育てる」という再帰的な発想です。普通のエージェント開発では人間が作って人間が直しますが、このプラットフォームではコーディングエージェント（Claude・Codex・Cursorなど）自身が、用意されたスキルを使ってエージェントを作り、改善し、評価します。人間は「エージェントを作る人」から「エージェントを育てる仕組みを運営する人」へと役割が上がる——これがこのテンプレートの核心です。

ひとことで
  • ・agent-platform-railway＝Agnoで作る「自走型エージェント基盤」の完成テンプレート。
  • ・エージェント自身がエージェントを作り・評価し・改善する再帰ループが回るのが本質。

2. なぜ必要か：「作って終わり」と評価・改善の手間を解決する

従来のエージェント開発の課題（作って終わり・手作業の評価・SaaSにデータを預ける）を、agent-platform-railwayが自走ループ・自動評価・自分のクラウドで解決する対比図
解決するのは「作って終わり」問題と、SaaSにデータを預ける不安の2つ。

agent-platform-railwayが解決するのは、エージェント開発につきまとう2つの根深い課題です。

1つ目は「作って終わり」問題。エージェントは作った瞬間がゴールではなく、実際に使いながら評価し、弱点を直し、維持し続けて初めて価値が出ます。ところが現実には、評価は手作業でばらつき、改善は場当たり的で、やがて放置される——という末路をたどりがちです。2つ目はデータの預け先問題。手軽なSaaSにエージェントを乗せると開発は速い反面、トレースや会話データが他社のクラウドに蓄積され、機微な業務では採用のハードルになります。

agent-platform-railwayは、これらを設計思想のレベルで反転させます。

・「作って終わり」には → 自走ループで応える：エージェント自身が作成・改善・評価・保守を継続的に回す
・評価の手作業には → 評価スイート（evals）で応える：python -m evals で評価をコード化し、再現可能にする
・データの預け先には → 自分のクラウドで応える：「すべて自分のクラウドで動き、データは自分のDBに残る」

誤解しないでほしい点
  • ・「完全自動でエージェントが勝手に賢くなる魔法」ではない。人間が方針と評価基準を定義する前提の自走。
  • ・手軽さはSaaSに軍配。Docker・Railway・Agnoの知識が要る“自分で建てる”タイプの基盤。

この2つの課題が効いてくるのは、エージェントを本気で運用に載せ、かつ扱うデータの機微度が上がるほどです。デモを1回動かすだけなら手作業の評価でも困りませんが、継続的に改善し続ける必要が出た瞬間に「作って終わり」の壁が、社外に出せないデータを扱う瞬間にSaaSの壁が、それぞれ立ち上がります。agent-platform-railwayは、その両方を最初から取り払っておくための土台です。

3. 2つの自走ループ：コーディングエージェントのスキルとAgent Builder UI

agent-platform-railwayの2つの自走ループ：コーディングエージェント向けスキル（create/extend/improve/review/evals）と、UIのAgent Builder（自然文でエージェント・チーム・ワークフローを構築）
自走は2系統。開発者はコーディングエージェントのスキルで、非開発者はUIのAgent Builderで。

このプラットフォームには、2つの自走ループが用意されています。使う人のスタイルに応じて入口が分かれているのが特徴です。

ループ①：コーディングエージェント向けのスキル——Claude CodeなどのコーディングエージェントがCLIから使う、エージェント開発ライフサイクルのスキル群です。主なものは次のとおりです。

・/create-new-agent：新しいエージェントを生成し、自動で登録する
・/extend-agent：ツールや機能を追加し、指示（instructions）を洗練する
・/improve-agent：シナリオをシミュレートし、応答を反復的に改善する
・/review-and-improve：ドキュメントやコードのズレ（ドリフト）を掃除する
・python -m evals：評価スイートを実行し、品質を測る

ループ②：Agent Builder（UI）——コードを書かない人向けの入口です。UI上で自然文からエージェント・チーム・ワークフローを作れます。README曰く「Agent BuilderはAgentOS Studioのツールでエージェント・チーム・ワークフローを作り、AgnoドキュメントのMCPと安全なレジストリで裏打ちされる」。つまり、Agnoの正しい作法に沿ったエージェントを、自然文の指示から安全に組み立てられます。

この2ループの関係を図にすると次のようになります。開発者はコード側から、非開発者はUI側から、同じエージェント基盤を育てられる構造です。

flowchart TD Dev["開発者"] --> S["コーディングエージェント
のスキル"] S --> C1["/create-new-agent"] S --> C2["/extend-agent"] S --> C3["/improve-agent"] NonDev["非開発者"] --> AB["Agent Builder（UI）
自然文で構築"] AB --> R["安全なレジストリ
＋Agno docs MCP"] C1 --> Plat["エージェント基盤
（自分のクラウド）"] C2 --> Plat C3 --> Plat R --> Plat Plat --> Obs["トレース/評価/ログ
を可観測化"] Obs -.->|"自己改善の根拠"| S

この図の点線が重要です。基盤が生み出すトレース・評価・ログが、そのまま自走ループの自己改善の根拠として戻っていく。「動かした結果」が「次の改善の材料」に直結する——この循環こそが「自走」の実体です。自然文からエージェントを組む発想に興味がある方は、Open Agent Builder徹底ガイドも併読すると、UI駆動のエージェント構築の潮流が見えてきます。

4. 仕組み：create→improve→evaluate→maintainと完全な可観測性

agent-platform-railwayの設計は、create → improve → evaluate → maintain（作る→改善する→評価する→保守する）という明確なワークフローを軸にしています。エージェント開発を「1回のイベント」ではなく「回り続けるサイクル」として捉えているのが肝です。

このサイクルが機能する前提が、完全な可観測性（observability）です。具体的には、次のすべてにエージェント自身がアクセスできるように設計されています。

・トレースデータ：エージェントが実際にどう動いたかの実行履歴
・エージェントのコード：エージェント自身の定義・実装
・評価結果：evalsによる品質の測定結果
・ログ：動作中に出力された記録

普通のシステムでは、これらは「人間が後から見るための記録」です。しかしこのプラットフォームでは、エージェントが自分の実行履歴・評価結果・ログを読んで、自分を直す——という自己参照の構造になっています。だからこそ「作って終わり」にならず、サイクルが回り続けます。

設計思想が効くところ
  • ・可観測データ（トレース/評価/ログ）を人間用でなく“エージェント用”に開いたのが核心。
  • ・create→improve→evaluate→maintainを「回り続けるループ」として実装している。

この自己参照の構造は、リポジトリの構成にも表れています。主なディレクトリを見ると、プラットフォームが何を大事にしているかが読み取れます。

・.agents/skills/：コーディングエージェント用のスキル（自走ループ①の実体）
・agents/：エージェントの定義本体
・app/：メインのアプリケーションコード
・db/：データベース設定（PostgreSQL）
・evals/：評価のテストケース（品質を測る土台）
・workflows/：ワークフロー定義
・scripts/railway/：Railwayデプロイ用のスクリプト群

注目すべきは、evals/ が独立したディレクトリとして最初から用意されている点です。多くのプロジェクトで評価は後回しにされがちですが、agent-platform-railwayは「評価を最初から一級市民として扱う」構成になっています。自走ループが機能するには「良し悪しを測る物差し」が不可欠で、それをコードとして持つことがこのテンプレートの設計思想を体現しています。

言い換えると、agent-platform-railwayは「エージェントに自分の成績表と作業ログを渡し、自分で復習させる」仕組みです。人間の開発では当たり前の「振り返って直す」を、エージェントのワークフローの内側に埋め込んだ——ここがこのテンプレートの技術的な面白さです。エージェントを堅牢に運用するための原則論に関心があれば、12-Factor Agents原則ガイドが、可観測性や状態管理の考え方の補助線になります。

5. セキュリティと「自分のクラウドで動く」設計

agent-platform-railwayのセキュリティ設計：本番はJWT認可がデフォルト、リクエストごとのユーザー/セッションID識別、ユーザー/管理者の権限分離、デフォルト非公開のプライベートクラウド配置
本番はJWTがデフォルト。データは自分のDBに残り、デフォルトで外部非公開。

「自分のクラウドで動く」ことを掲げる以上、セキュリティ設計は要です。agent-platform-railwayは、本番運用を見据えたガードを標準で備えています。

・JWTによるトークンベース認可：本番（production）ではデフォルトで有効。開発時は無効にでき、環境フラグで切り替える
・リクエストごとの識別：ユーザーIDとセッションIDで、誰のどのセッションかを追跡
・粒度のある権限：ユーザー用トークンと管理者用トークンで、できることを分ける
・デフォルト非公開：プライベートなクラウド配置が前提で、既定では外部にパブリック公開されない

そして根底にあるのが、「すべて自分のクラウドで動き、データは自分のDBに残る」という方針です。PostgreSQLを自分のインフラ（ローカルやRailway）に立て、そこにデータが保存されます。トレースや会話データが他社のSaaSに蓄積されないため、機微なデータを扱う業務でも「まず自分の管理下に置く」ことから始められるのが強みです。

運用上の注意
  • ・実験的テンプレートである以上、JWT鍵の管理と公開範囲の設定は自己責任で正しく行う。
  • ・開発時はJWTを無効化できる＝そのまま公開すると無防備。本番フラグの取り違えに注意。

エージェント基盤は、外部ツールを呼び、コードを実行し、データに触れます。だからこそ「誰が・何を・どこまで」を制御できることが、実運用では機能の豊富さと同じくらい重要になります。agent-platform-railwayが認可とプライバシーを最初から組み込んでいるのは、この基盤をおもちゃではなく実務のインフラとして設計している証だと言えます。

6. 導入：ローカル（Docker）とRailway本番デプロイ

agent-platform-railwayの導入フロー：ローカルはDockerでgit clone→.env設定→docker compose up、本番はRailwayスクリプトでPostgreSQLとアプリをプライベート構築しJWT設定する流れ
ローカルはDocker、本番はRailwayスクリプト1発。JWT設定のために処理が一時停止する。

導入は2段構えです。まずローカル開発はDockerで動かします。前提はDockerが動いていることだけです。

git clone https://github.com/agno-agi/agent-platform-railway.git agent-platform
cd agent-platform
cp example.env .env
# .env に OPENAI_API_KEY を設定する
docker compose up -d --build

起動後は http://localhost:8000/docs にアクセスし、管理UIとして AgentOS Studio（os.agno.com） に接続します。まずはここまでで、エージェントの作成・実行・評価をひととおり試せます。

次に本番デプロイ。クラウドのRailwayを使い、スクリプト1発で環境が立ち上がります。

./scripts/railway/up.sh

このスクリプトは、PostgreSQLとアプリのサービスをプライベートネットワーク上に構築します。途中で、JWT鍵をos.agno.com経由で設定するために処理が一時停止する設計になっており、鍵の設定が済んでからデプロイが続行します。コードを変更した後は ./scripts/railway/redeploy.sh で再デプロイするか、GitHubリポジトリからの自動デプロイを有効にできます。導入の流れをまとめると、こうなります。

・ローカル：clone → .envにOPENAI_API_KEY → docker compose up → localhost:8000/docs
・本番：.env.productionを用意 → up.sh実行 → JWT鍵をos.agno.comで設定 → デプロイ確認
・更新：redeploy.sh またはGitHub連携の自動デプロイ

「ローカルはDockerで即起動、本番はRailwayスクリプト1発」——このデプロイ体験の軽さが、テンプレートとして配られていることの価値です。スタックはPython＋Agno＋PostgreSQL＋Docker＋Railwayが基本で、オプションでSlackボットや、Web検索用のParallel SDKにも対応します。

7. 導入判断：向いている人・注意点

agent-platform-railwayの導入判断：自分のクラウドでエージェント基盤を持ちたいチーム・評価と改善を回したい開発者に刺さる一方、Agno/Docker/Railway前提や実験的である点が注意
導入判断の観点。青は価値が出る条件、⚠️は前提知識・実験段階などの注意点。

最後に、導入すべきかの判断材料を整理します。

agent-platform-railwayが向いている人

・自分のクラウドでエージェント基盤を持ち、データを手元に残したいチーム
・エージェントの評価と改善を継続的に回す運用を組みたい開発者
・コーディングエージェント（Claude等）にエージェント開発そのものを任せたい人
・Agnoでエージェントを作っており、本番デプロイの雛形が欲しい人

慎重に判断すべきケース

・すぐ使える完成SaaSが欲しい（Docker・Railway・Agnoの前提知識が要る）
・Agno以外のフレームワークに強く紐づいている（このテンプレートはAgno前提）
・スター数が示すとおりまだ新しいプロジェクトで、枯れた安定性を最優先したい

いくつか具体的な注意点も押さえましょう。まずAgno前提であること。このテンプレートはAgnoの作法に沿って設計されているため、Agnoの理解が導入の前提になります。次に「自動で賢くなる魔法」ではないこと。自走ループは強力ですが、何を良しとするか（評価基準）や改善の方針は人間が定義します。エージェントは、人間が引いたレールの上で自己改善するのです。そしてまだ若いプロジェクトであること。スター数は控えめで、活発に開発中の段階です。仕様変更の可能性を前提に、バージョンを固定して使うのが安全です。

導入前チェック
  • ・Agno＋Docker＋Railwayの前提知識が要る。“自分で建てる”タイプの基盤。
  • ・本番はJWTデフォルト有効だが、開発時は無効化可。公開設定の取り違えに注意。
  • ・実験的テンプレート。評価基準と改善方針は人間が定義する前提で使う。

エージェントフレームワークは群雄割拠で、Agnoはそのなかの有力な選択肢の1つです。どのフレームワークが自分の用途に合うかは、AIエージェントフレームワーク徹底比較2026で全体像を掴んだうえで、agent-platform-railwayのような「デプロイまで含んだテンプレート」を評価すると、選択の精度が上がります。

まとめ

agent-platform-railwayは、「エージェント開発を、作って終わりのイベントから、回り続けるループへ」という思想を、Agnoの上に具体化したテンプレートです。コーディングエージェント自身にエージェントを作らせ・評価させ・改善させ、しかもそのすべてを自分のクラウド・自分のDBの中で回す——エージェント運用の「継続性」と「データ主権」を同時に握りにいった設計です。

結論
  • ・agent-platform-railwayは、Agno上に構築された自走型エージェント基盤テンプレート（Apache-2.0）。
  • ・コーディングエージェント向けスキルとUIのAgent Builderという2つの自走ループを持つ。
  • ・create→improve→evaluate→maintainを、可観測データを根拠に回し続ける。
  • ・「すべて自分のクラウドで動き、データは自分のDBに残る」——SaaSにデータを預けない。
  • ・ローカルはDocker、本番はRailwayスクリプト1発。本番はJWT認可がデフォルト。

「エージェントを、エージェントに育てさせる」時代の入口を触ってみたいなら、まずは docker compose up でローカルに立てて、/create-new-agent から始めてみてください。フレームワーク選びの全体像はAIエージェントフレームワーク徹底比較2026を、UI駆動の構築はOpen Agent Builder徹底ガイドを、堅牢運用の原則は12-Factor Agents原則ガイドを、それぞれ合わせて読むと理解が立体化します。

参照ソース

・agno-agi/agent-platform-railway (GitHub) — 公式リポジトリ。2つの自走ループ・スキル・デプロイ手順・セキュリティ方針の一次ソース。
・Agno 公式ドキュメント — 土台となるAgnoフレームワークの仕様・使い方の一次ソース。
・AgentOS / os.agno.com — 管理UI（AgentOS Studio）とJWT設定の入口となる公式サービス。