AIエージェントOSSカタログ
AIエージェント開発のためのOSSフレームワーク・ツール・実行環境を継続キュレーション。開発の活発さ、ライセンス、選定時のトレードオフまで明示します。
おすすめプロジェクト編集部が選定・過去30日以内にレビュー済み
すべて表示 →すべての変更がgitコミットとして記録されるため、AIによる編集が同僚の編集と同じようにレビュー可能・巻き戻し可能になります。リポジトリマップの仕組みにより、コンテキストウィンドウを大きく超える規模のコードベースでも作業できます。ターミナル専用という設計は、そこで作業する人には強みですが、エディタ内での利用を求める場合は選択肢になりません。
スクリーンショットからクリック座標を推測させるのではなく、ページ上の操作可能な要素を抽出して構造化リストとしてモデルに渡します。この方式により、フォーム入力やスクレイピングでの安定性が明確に高くなります。一方でcanvas主体のアプリケーションや、bot対策の強いサイトでは読み取れるDOMが存在せず、精度が落ちます。
タスクを、役割と目標を持つエージェントのチームとして表現し、互いに作業を引き渡させます。この比喩によりマルチエージェント設計が一目で読めるようになり、デモ映えする理由にもなっています。ただし、役割を演じる複数エージェントが、よく設計された単一エージェントを実際に上回るかは、導入前に計測する価値があります。答えが「否」であることは珍しくありません。
プロンプトのオーケストレーション、検索、エージェントツール、管理UIまでを備えた統合プラットフォームで、初期構築さえ済めば非エンジニアでも運用できます。ライセンスはApache 2.0に、マルチテナント提供とブランディングに関する追加条件を加えたもので、OSSではなくソース公開型にあたります。この上に製品を構築する前に必ず確認してください。
エージェントが実際に何をしたか——各呼び出し、ツール実行、コスト——を記録し、そのトレースを評価用データセットへ変換できます。マネージド版とDocker Composeでセルフホストする版が同一コードベースのため、どちらの方向にも移行コストが低いのが利点です。一部のエンタープライズ機能はMITのコア部分に含まれないため、必要な機能の提供範囲を事前に確認してください。
エージェントを「中身の見えないループ」ではなく、ノードとエッジの明示的なグラフとして表現します。永続チェックポイントにより実行を人間の承認待ちで中断し、後から再開できるため、本番システムに触れるワークフローで現実的な選択肢になります。反面、単純なツール呼び出しだけのエージェントには記述量が多く、他のフレームワークより初期セットアップが重くなります。
数百のサービスをビジュアルキャンバス上で連携させるツールで、近年はそのフロー内にLLMエージェントを組み込む用途が増えています。最初に確認すべきはライセンスです。OSI承認のオープンソースではなく、Sustainable Use Licenseによるソース公開型にあたります。社内利用やセルフホストは可能ですが、ホスティングサービスとして再販することは認められていません。
モデルのダウンロード、量子化、OpenAI互換サーバーの提供までを引き受け、ローカルモデルをコマンド1つの距離に置きます。ローカル推論を前提とした開発の出発点として妥当な選択です。ただし多数の同時ユーザーへの配信では、スループット重視のサーバーのほうが明確に有利です。
隔離されたコンテナ内でファイル編集・テスト実行・ドキュメント参照を行うため、実行が失敗してもホスト環境を壊しません。SWE-bench系のベンチマークでは上位の成績を出していますが、実際のリポジトリに向ける前にコスト試算を勧めます。長時間の自律実行はトークン消費が大きく、生成結果はマージ前に人間のレビューが前提になります。
PagedAttentionと継続バッチングにより、素朴な実装よりはるかに多くの同時リクエストを1枚のGPUで捌けます。エージェントは呼び出し回数が多くなりがちなため、この差が効いてきます。OpenAI互換エンドポイントを備えており、多くのエージェントフレームワークはベースURLの変更だけで接続できます。一方でGPUメモリの見積もりやモデルのロード時間など、運用面の作業は相応に発生します。