Jido 2.0 - Elixirベースのエージェントフレームワークを公開

 (jido.run)
7 ポイント 投稿者 GN⁺ 2026-03-07 | 1件のコメント | WhatsAppで共有
  • 純粋関数型エージェントアーキテクチャにより、状態と振る舞いをデータとして定義し、副作用を**命令的ディレクティブ（directive）**として分離して、テストとデバッグを簡素化
  • 簡潔なAPIとBEAM中心設計を採用し、jido_action、jido_signal などのモジュールを分離して標準化されたアクション・シグナルシステムを提供
  • 上位レイヤーのJido AIは、ReAct、Chain-of-Thought など6種類の推論戦略をサポートし、ReqLLMベースのLLM統合により11のプロバイダーと665のモデルを利用可能
  • Jidoは現在、エージェントエコシステムプラットフォームへと拡張中であり、Ash Frameworkとの統合（ash_jido）を通じてAIから呼び出し可能なCRUDツール化をサポート

Jido 2.0 概要

  • Jido 2.0は、18か月にわたる開発と再設計を経て完成したElixirベースのエージェントフレームワーク
    • 当初は2024年にBotHiveというボットプラットフォームとして始まり、その後BEAMランタイムをエージェントシステムの基盤として採用
    • TypeScriptやPythonベースのフレームワークの限界を克服するため、BEAMの並行性・安定性を活用

1.0から2.0への変化

  • Jido 1.0は過度な抽象化によって使い勝手が低下していたが、2.0では簡素化されたAPIとBEAM中心の構造へと改善
    • ユーザーフィードバックを反映して不要な複雑さを取り除き、基本機能を実行する際の摩擦を最小化
    • 「エージェントを作りたいのであって、フレームワークと格闘したいわけではない」という要望を反映

強力で堅牢なエージェントコア

  • Jido 2.0の中核は純粋関数型エージェントアーキテクチャ
    • エージェントは、状態（state）、アクション（actions）、ツール（tools）を持つ単純な構造体として定義
    • すべての動作は cmd/2 関数で処理され、入力されたアクションに応じて更新されたエージェントとディレクティブの一覧を返す
    • 副作用はディレクティブとして表現され、ランタイムが実行するため、テストとデバッグが容易
  • Jido.AgentServer はエージェントを監視されたGenServerでラップし、シグナルルーティングと親子エージェント階層をサポート
  • 戦略（strategy）は拡張ポイントであり、**Direct（逐次実行）とFSM（状態機械）**の2種類を標準提供
    • ReAct、Chain-of-Thought などのAI戦略も同じインターフェースで動作

アクションとシグナルのモジュール分離

  • jido_action: すべてのエージェント機能を定義する汎用アクション契約
    • コンパイル時のスキーマ検証、ライフサイクルフック、ReqLLMツール形式への自動変換機能を含む
    • 25以上の事前構築ツールとDAGベースのワークフロープランナーを提供
  • jido_signal: CloudEvents v1.0.2ベースのメッセージングシステム
    • 標準化されたシグナル形式、トライベースのルーター、pub/subバス、9つのディスパッチアダプターを提供
    • 非標準プロトコルなしでさまざまなシステムと統合可能

Jido AI 統合レイヤー

  • jido_ai は、LLM呼び出しを構造化されたエージェント知能へ変換する統合レイヤー
    • ReAct、Chain-of-Thought、Tree-of-Thoughts、Graph-of-Thoughts、TRM、Adaptive など6種類の推論戦略を内蔵
    • 同じ cmd/2 契約とディレクティブシステムを維持し、AIレイヤーを別世界ではなく拡張として統合
  • ReqLLMベースで動作し、11のプロバイダーと665以上のモデルをサポート
    • ストリーミング優先設計、マルチプロバイダー構成、活発なコミュニティ貢献

拡大するエコシステム

  • Jidoは単なるフレームワークを超えてエージェントエコシステムへと発展中
    • コミュニティはBEAM上でコーディングアシスタント、ワークフローオーケストレーター、リサーチエージェント、運用支援システムなどを構築
    • ブラウザ自動化、メモリシステム、評価ハーネス、MCP統合など多様なパッケージが登場
  • Ash Framework統合（ash_jido）
    • Ashリソースに jido DSLブロックを追加すると、CRUDアクションがAIから呼び出し可能なツールに変換
    • 権限ポリシー、データレイヤー、型安全性を維持
    • ash_ai もReqLLMへ移行中で、両エコシステムの収束が進行

コミュニティと謝辞

  • Jido 2.0はElixirコミュニティのエコシステムの上に構築
    • Phoenix、LiveView、Ash、Req、Telemetry、NimbleOptions など主要ライブラリの貢献によって強化

始め方

関連記事

1件のコメント

 
GN⁺ 2026-03-07
Hacker Newsのコメント

  • まだJidoを実際に使ったことはないけれど、月に1回くらいは必ずチェックしている
    BEAMはエージェントフレームワークに完璧に合うと思うが、エコシステムがまだ限られているので深く掘り下げられていない
    2.0版が楽しみ。ちなみにコードサンプルの一部ではエンティティエスケープの問題があるように見える

    • ありがとう！ すぐに修正中です

  • 記事の冒頭から強調されていた「データと純粋関数」中心のアプローチが本当に気に入った
    BEAMの実行モデルがAIに適しているという話はよく見るが、実際にはノード障害やローリングデプロイのような状況での堅牢性がしばしば見過ごされている
    Elixirが位置透過性を提供するという誤解もあるが、実際にはそうではない。ノードが落ちれば、その中のプロセスも一緒に終了する
    各API呼び出しの段階ごとに明確で純粋なエージェント状態を維持すれば、こうした問題を解決できる。MnesiaやRedisに状態を保存し、別のノードで引き継げばよい。結局のところチェックポイントが核心だ

    • 私の考えでは、Jidoの最も重要な原則は、LLMを使う前にLLMなしでも構造的に正しいエージェントを作ることだ
      だからJidoコアにはLLMサポートがまったくない。
      40年以上続いてきたエージェント研究があるのに、LLMの登場でそれを全部忘れてしまったかのようだ。だから私はその歴史を学び直し、それをJidoに取り込もうとした
      もちろんLLMは好きだが、それはJido AIパッケージの役割だ

  • タイミングが完璧だ。私はgen serverとObanを組み合わせて自分でエージェントフレームワークを作ったが、本当につらい作業だった
    このプロジェクトは開発の苦痛を大きく減らしてくれそうだ。本当にありがとう

    • ❤️

  • これが OpenAI Symphony と似たものなのか気になる
    私はAIよりもElixirのほうをよく追っているが、こうしたオーケストレーションワークロードにElixirとBEAMが使われているのを見るのは新鮮だ

    • OpenAIがElixirを活用しているのを見るのはうれしい。Symphonyは、Jidoでできることを直接実装した事例だ

  • サイトがトラフィック急増でアクセスしづらい。なので archive.orgのバックアップリンク を共有する

    • これは今後2週間、私の個人的な恥として残りそうだ……良い問題ではあるけれど、本当に準備不足だった
    • 関連する問題かどうかは分からないが、ページが最初は普通に開くのに、数秒後に404へリフレッシュされる。結局読むのを諦めた

  • 共有ありがとう！ ぜひチェックしてみる
    私は最近LLMでA2Aパッケージを作ったが、GenServerに似た抽象化だ
    すでに別のA2A実装はあったが、自分のパッケージは意味論が異なるのでそのまま公開した
    興味がある人は こちらで確認できる

    • すごい！ さっそくスターを付けた

  • 数か月前からこのプロジェクトを追っているが、Elixir/BEAMはエージェント実行の完璧なプラットフォームだ
    BEAMは本当に軽量で効率的なので、理論上は1台のサーバーで数千のエージェントを動かすこともできる
    これを理解した人たちが今後どんなものを作るのか楽しみだ

    • JidoのコアはRaspberry Piでも動かせる
      さらに、BEAMをベアメタル（組み込み）環境にデプロイして、その中でエージェントを動かそうという試みもあった
      未来は本当に面白くなりそうだ

  • observerでエージェントがアクティブな状態のプロセスツリーのスクリーンショットが見たい
    ちなみにobserverは、BEAM VM内部のErlangプロセスを可視化してくれるツールだ
    例のスクリーンショットは Fly.ioのドキュメント で見られる

    • まもなく jido_studio というダッシュボードを公開する予定だ。プロセス構造を可視化してくれる
      ティーザースクリーンショットは ここ で見られる
      AgentRuntimeでラップしたエージェントは一般的には1つのGenServerプロセスとして動作するが、より大きなトポロジーが必要な場合は例外もある

  • 完璧なタイミングだ。私も自分でErlangエージェントフレームワークを作っていたが、こちらのほうがずっと良い

  • セキュリティをどう担保しているのか気になる。コンテナ分離がないなら、本番シークレットの漏えいを防ぐのは難しい

    • SignalsとPluginsを使えば、エージェント間のデータを暗号化できる
      実際にそのように実装したJidoの事例も見た
      ただしこれはユースケース次第であり、セキュリティは単に「コンテナ内のエージェント」の問題よりはるかに広いテーマだ
      Jidoの目的はセキュリティを直接解決することではなく、ユーザーが必要な方法で解決できるツールを提供することだ