いま注目のオープンソース (1) AIエージェントとLLMツール

• はじめに — ひとかたまりだったスタックが層に分かれた
• スナップショット
• 第1層 — モデルを実際に動かす場所
• 第2層 — プロバイダーを抽象化するゲートウェイ
• 第3層 — オーケストレーションとRAG
• 第4層 — エージェント
• インターフェース — ライセンスを必ず見てから使ってください
• 導入前の確認
• リンク

はじめに — ひとかたまりだったスタックが層に分かれた

2023年にLLMアプリケーションを作るというのは、フレームワークを一つ選んでAPIキーを挿し、チェーンを組むことでした。

いまは、モデルをどこで動かすか、複数のプロバイダーをどうやって一つのインターフェースの背後に置くか、検索を付けるか、エージェントにツールをどれだけ渡すかが、すべて別々の判断です。判断ごとに別のプロジェクトが居場所を確保しました。

以下のリストは順位ではありません。役割ごとにまとめた地図であり、同じ層の中のプロジェクト同士だけが実際に競合関係にあります。

スナップショット

すべて2026-08-12時点です。

第1層 — モデルを実際に動かす場所

ggml-org/llama.cpp は、GGUF量子化モデルをCPUとコンシューマー向けGPUで動かすC++の推論エンジンです。上の層のかなりの部分が、このプロジェクトかその派生物の上に立っています。リポジトリが個人アカウントから組織アカウントへ移されたので、古いドキュメントのパスをそのまま信じないでください。GPUを複数枚使って大規模な同時リクエストを受ける用途ではありません。

ollama/ollama は、その上にモデルの配布とライフサイクル管理を載せ、ローカル実行を一行にまで縮めました。OpenAI互換のエンドポイントがあるので、既存のクライアントコードをほぼそのまま接続できます。開発環境や個人のワークステーションには合いますが、マルチテナントの本番サービングを狙った代物ではありません。

# 例: ローカルで起動してOpenAI互換のパスで呼び出す
ollama serve &
ollama pull <model-name>
curl http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"<model-name>","messages":[{"role":"user","content":"ping"}]}'

vllm-project/vllm は反対の端にあります。PagedAttentionと連続バッチングでGPUのスループットを引き上げるサービングエンジンで、セルフホスト推論の事実上のデフォルトに最も近い存在です。その代わりGPUとドライバーの組み合わせに敏感で、メモリのチューニングが必要なので、一日に数百件の規模なら過剰です。

sgl-project/sglang は、プレフィックスキャッシュの再利用（RadixAttention）に焦点を当てており、プロンプトの前半が繰り返されるワークロードで利点が大きくなります。2024年1月にできた若いリポジトリなので、運用の経験はvLLM側のほうが厚みがあります。

第2層 — プロバイダーを抽象化するゲートウェイ

BerriAI/litellm は、数多くのモデルプロバイダーをOpenAI形式の一つに統一し、プロキシモードではキー管理と予算上限、フォールバック、使用量のロギングを担当します。プロバイダーを変えるたびにアプリケーションコードを直す作業をなくしてくれます。

ライセンスは正確に見る必要があります。リポジトリのLICENSEファイルは、enterprise/ ディレクトリはその中で定義された別のライセンスに従い、それ以外はMITだと宣言しています。全体が一律のMITではありません。

第3層 — オーケストレーションとRAG

langchain-ai/langchain は、統合の面が最も広いフレームワークです。初期の過剰な抽象化への批判以降、構造が何度も再編されているので、学習資料の作成時点を必ず確認してください。呼び出しが一つか二つの段階しかない作業に載せると、得るものより失うもののほうが多くなります。

run-llama/llama_index は、ドキュメントの取り込み、チャンキング、インデックス作成、検索というRAGの軸により集中しています。検索品質を手直しする作業が仕事の大半なら、こちらがよく合います。

infiniflow/ragflow はライブラリではなく、デプロイして使うRAGエンジンで、表とレイアウトが複雑なPDFのパースに重点を置いています。インフラをもう一つ運用しなければならないので、チームが小さいなら負担を先に計算してください。

第4層 — エージェント

crewAIInc/crewAI は、役割を分けたマルチエージェントの協働を標準パターンにしました。問題を人の組織のように切り分けられるときによく合います。逆に、決定論的な結果が必要なパイプラインにマルチエージェントを入れるのは、たいてい損です。

browser-use/browser-use は、LLMに実際のブラウザを操作させて、APIのない画面を自動化する通路を開きます。ただしリポジトリは2024年10月にでき、スターが108,900個まで伸びる間にインターフェースも変わり続けました。信頼性とプロンプトインジェクションへの露出という面では、まだ慎重に扱う必要があります。

Aider-AI/aider は、ターミナルからリポジトリを編集してコミットまで作るペアプログラミングツールです。活動のシグナルはそのまま伝えます。確認時点の最近のプッシュは2026-05-22で、他のプロジェクトが同じ日にプッシュされているのと対照的です。死んでいるという意味ではありませんが、導入前に最近のコミットとイシューへの応答を自分で確認してください。

インターフェース — ライセンスを必ず見てから使ってください

open-webui/open-webui は、ローカルモデル用のチャットUIとして広く使われています。ところがLICENSEファイルが重要です。BSD 3条項の形に条項が一つ追加されており、その条項はOpen WebUIのブランディング（名称、ロゴなど）の変更や削除を禁止します。使用制限が付いているため、OSIが定義するオープンソースではなく、ソース公開ライセンスです。

社内ポータルにホワイトラベルで載せようという計画なら、ここで引っかかります。例外条件も一緒にあるので、全文を自分で読んでください。

導入前の確認

ライセンスの全文を自分で確認し、商用導入は法務レビューを通してください。この記事は法律上の助言ではありません。

この領域だけに当てはまる注意もあります。LLMツールはインターフェースが速く変わるので、バージョンを固定し、アップグレードを定期的な予算に入れてください。エージェントにツール実行の権限を与えるときは、信頼できない入力がそのまま命令になる経路が開くという点を、設計の段階で扱う必要があります。

リポジトリの情報（スター数・ライセンス・最近の活動）は、2026-08-12にGitHubで直接確認した時点の値です。数値と状態は変わります。

リンク

シリーズの次の記事: いま注目のオープンソース (2) 開発者ツール

このブログの関連記事:

• RAGパイプラインとベクトルデータベースの本番適用
• RAGパイプラインの最適化 — チャンキング、リランキング、ハイブリッド検索
• 2026年のオープンソースライセンスの変化

ツール: curlコマンドビルダー · JSONフォーマッター