2026年のAIオープンソースエコシステムは、もはや「また ChatGPT のラッパー」だけではありません。GitHub で Star が急増しているのは、汚れた PDF をきれいな Markdown に変えるツール、Agent にセッションをまたぐ記憶を与えるミドルウェア、さらには4GB の旧 GPU で 70B を動かすインフラ層です。RAG、企業ナレッジベース、マルチ Agent プロダクトを作るなら、より大きなクローズドモデルに乗り換えるより、適切なオープンソース部品を選ぶほうがコスパが良い場面が増えています。
本記事では、Kvmzen チームの実装経験とコミュニティ観察に基づき、2026年に注目すべき AI オープンソース 10 プロジェクトを厳選します。PDF 処理、Agent メモリ、極小 VRAM 推論、オーケストレーションとローカルデプロイの 4 ラインで選定ポイント、組み合わせ方、よくある落とし穴を整理し、クラウド Mac との接続方法も示します。
選定基準：「話題」とは何か
単なる Star 数ランキングではなく、次の 4 つを検証可能な基準にしています。
- 直近 12 ヶ月の活発なメンテナンス— 安定したリリース、Issue 対応、ドキュメント更新があること
- 実際の痛みを解く— PDF の文字化け、Agent の記憶喪失、VRAM 不足、API プロバイダの分散
- 既存スタックに組み込める— Python SDK や OpenAI 互換 API を提供し、ブラックボックスにならないこと
- 本番運用の見通し— ログ・メトリクス、または実験/本番の明確な位置づけがあり、「デモしか動かない」状態を避けられること
Agent 開発を体系的に学びたい方は、先に AI Agent 学習ロードマップ（2026）：初心者必読の書籍・講座・オープンソース を読んでから、本記事の各プロジェクトを手を動かして検証するのがおすすめです。
PDF・ドキュメント処理の三強
RAG プロジェクトで「ゴミを入れればゴミが出る」最大の原因は、しばしば PDF 解析の品質です。2026年のコミュニティ合意は「万能パーサーはない」というものですが、次の 3 つで 80% のシーンをカバーできます。
1. Docling（IBM）
MIT ライセンスで IBM Research が保守。PDF、DOCX、PPTX、HTML などに対応し、表・ヘッダ/フッタ・多段組レイアウトの構造化復元が強みです。JSON または Markdown を出力し、下流のインデックスに渡せます。企業ナレッジベースの統一入口として Docker 化しやすく、LangChain / LlamaIndex 向けの公式統合例も揃っています。
2. Marker
PDF・EPUB を高品質な Markdown に変換することに特化。学術論文や技術ホワイトペーパーの数式・脚注処理は、多くの汎用 OCR を上回ります。GPU 上では数十ページ/分の速度も可能です。英語 PDF が中心で、きれいな Markdown を経てチャンク分割するなら、最初の一手として Marker がコスパ良いことが多いです。
3. MinerU
中国発のオープンソースで、中国語スキャン文書・複雑な表・教材レイアウトの認識精度がコミュニティで高く評価されています。国内の行政文書、決算資料、教材コーパスに向きます。Docling と連携する構成も有効：MinerU で OCR を強化し、Docling で統一スキーマに出力する、といった使い分けです。
Agent メモリ：Mem0 と Zep
記憶のない Agent は、毎回初対面の相手と同じです。2026年のメモリ層は「履歴を Context に詰める」段階から、検索可能・更新可能・監査可能な独立サービスへ進化しています。
4. Mem0
「memory layer for AI apps」を掲げ、ユーザー単位・セッション単位の長期記憶 API を提供。会話から事実を自動抽出し重複を除去します。LangGraph、CrewAI、AutoGen との統合ドキュメントが充実しており、最も手早く試せる選択肢です。パーソナルアシスタント、コーディング Agent、ユーザー設定を覚える SaaS プロトタイプに向きます。
5. Zep
2025–2026年に Graphiti 時系列ナレッジグラフを前面に押し出しています。「ユーザーはダークモードを好む」だけでなく、事実がいつ有効になりいつ覆されたかを記録し、グラフクエリとコンプライアンス監査に対応。追跡可能な記憶チェーンが必要なカスタマーサポート、CRM、医療などでは Zep が有力です。一方、Mem0 よりデプロイとモデリングの負荷は高くなります。
4GB GPU で 70B：AirLLM
6. AirLLM
タイトルの「4GB GPU で 70B」は、ほぼ AirLLM を指します。層単位推論により重みは SSD に置き、GPU には Transformer 層を 1 枚ずつだけロード。Llama 3.1 70B の VRAM ピークは約 4GB で、Apple Silicon + MLX にも対応しています。トレードオフは速度（通常 0.5–3 tokens/s）と、初回の約 130GB モデルダウンロード・分割です。
同日公開の専門記事で詳細な実測を掲載しています。4GB GPU で 70B 大規模言語モデルは動く？AirLLM 実測と設定ガイド を参照してください。ひとことで言えば、AirLLM は実現可能性の検証ツールであり、本番 API 向けではありません。
Agent オーケストレーション：LangGraph と CrewAI
7. LangGraph
LangChain チームによるステートフルなグラフオーケストレーションフレームワーク。Agent フローをノードとエッジでモデル化し、ループ、人間による承認中断、checkpoint の永続化をネイティブにサポート。2026年時点でエンタープライズ Agent のデファクトの一つとなり、ツール呼び出し順序と失敗時リトライを細かく制御するバックエンド向きです。
8. CrewAI
「役割 + タスク委任」でマルチ Agent 協調を抽象化。YAML で Researcher、Writer、Reviewer などの役割を定義でき、LangGraph より学習曲線が緩やかでプロトタイプとデモが速いのが強みです。本番では CrewAI で役割分担、LangGraph でステートマシンと観測性を担う、という併用もよく見られます。
ローカルデプロイ：Ollama と LiteLLM
9. Ollama
一行コマンドでオープンウェイトを取得・実行。macOS / Linux / Windows 全対応。2026年は多様な量子化モデルとマルチモーダル派生も揃い、ローカル開発の最初の一台としての定番です。Open WebUI と組み合わせれば、チーム内ネットワーク向け Chat 画面もすぐ立ち上がります。
10. LiteLLM
OpenAI 互換ゲートウェイとして、Ollama、Anthropic、Azure、Bedrock などを同一 APIにまとめ、ルーティング・リトライ・コスト追跡を内蔵。Cursor、CLI、自社 Agent がモデルを共有するチームでは、「クライアントごとに Key を再設定する」混乱を防げます。Kvmzen ブログで紹介した OmniRoute 系ゲートウェイに近い思想ですが、LiteLLM は LLM 推論層に特化しています。
横断比較と推奨スタック
| プロジェクト | カテゴリ | 最適な用途 | 主なトレードオフ |
|---|---|---|---|
| Docling | 企業の多形式ドキュメントパイプライン | 複雑なスキャンは前置 OCR が必要 | |
| Marker | 英文学術 PDF → Markdown | 中国語・手書きは弱め | |
| MinerU | 中国語スキャン・教材 | 英語圏エコシステム連携はやや少ない | |
| Mem0 | メモリ | ユーザー長期記憶の迅速な追加 | 複雑なグラフ推論は限定的 |
| Zep | メモリ | 時系列事実と監査 | デプロイ・運用が重い |
| AirLLM | 推論 | 4GB VRAM で 70B を検証 | 極端に遅い・大容量ディスク |
| LangGraph | オーケストレーション | ステートフル本番 Agent | 概念が多く学習コスト高 |
| CrewAI | オーケストレーション | 多役割プロトタイプ | 細かい制御は LangGraph に劣る |
| Ollama | デプロイ | ローカルでモデル取得・開発 | 大モデルはメモリ/ディスクを消費 |
| LiteLLM | ゲートウェイ | 複数プロバイダ API の統一 | 高可用性は自前で担保 |
推奨 MVP スタック：Ollama でモデル提供 → LiteLLM で OpenAI 互換エンドポイント → LangGraph でツールをオーケストレーション → Mem0 で記憶を書き込み → Marker でアップロード PDF を処理。2 週間以内にエンドツーエンドのデモを通せる構成です。
クラウド Mac / Apple Silicon との接続
上記プロジェクトの多くは macOS ネイティブで動きますが、ディスク・メモリ・長時間推論がボトルネックになりやすいです。
- PDF バッチ処理— Marker、MinerU は GPU 上のほうが速い。Mac mini の CPU パスでも可能ですが、大量処理はクラウドノードで夜間バッチが現実的です
- 70B 実験— AirLLM は Apple Silicon + MLX に対応。24GB ユニファイドメモリは 4GB ディスクリート GPU より体感が一段上です
- Agent 長時間タスク— LangGraph の checkpoint、Ollama のモデルファイルは数十 GB 単位。クラウド Mac なら固定環境と十分な SSD で、ローカルディスクを圧迫しません
iOS / Flutter 開発者が Windows 本機を使っている場合、Ollama + LangGraph の実験をクラウド Mac に移せば、Unix ツールチェーンと Apple Silicon 推論の両方を一度に得られ、WSL やドライバ互換の維持から解放されます。
コスト・性能・リスク
コスト面では、純オープンソーススタックの「隠れた請求書」はエンジニア時間 + 電気代 + ディスクです。4GB ディスクリート GPU + AirLLM は API 料金ゼロに見えても、130GB モデルと極端に遅い速度が検証サイクルを伸ばします。月額のクラウド Mac は 2–3 週間で時間コストを回収できることも多いです。トラフィックが読めない初期プロダクトなら Token 従量の API も有効で、ローカルスタックと並行運用するのが現実的です——開発は Ollama、本番は LiteLLM 経由でクラウドへ、という切り分けです。
よくある質問
2026年の PDF 解析は Docling と Marker、どちらを選ぶべき？
Docling は企業パイプラインと多形式向け、Marker は英文学術 PDF の Markdown 変換向け、中国語スキャンは MinerU を優先。20 ページのサンプルで A/B してから決め、Star 数だけで判断しないでください。
Mem0 と Zep はどう選ぶ？
Agent にユーザー記憶を素早く足すなら Mem0。時系列事実・関係推論・監査が必要なら Zep。併用も可能：Mem0 で好み、Zep で業務事実グラフ、という分担です。
4GB GPU で 70B は動きますか？
はい。AirLLM の層単位推論で VRAM ピークは約 4GB、速度は 0.5–3 tokens/s、大容量 SSD が必要です。詳細は当サイトの AirLLM 実測記事を参照してください。
ローカル Agent スタックを手軽に組むには？
Ollama + LiteLLM + LangGraph + Mem0 + いずれかの PDF パーサー。macOS が依存最少、Windows はクラウド Mac または WSL を検討。
Mac mini でこのオープンソーススタックを組むと、もっと楽
本記事の 10 プロジェクトの大半は macOS でネイティブ動作します。Homebrew で Python、Ollama でモデル一発取得、MLX で AirLLM とローカル推論を加速。Apple Silicon のユニファイドメモリなら、24GB 構成の Mac mini で PDF バッチと量子化 70B を同時に回せ、Windows で CUDA と WSL をいじる必要がありません。M4 のアイドル消費電力は約 4W で、長時間の Agent タスクや夜間インデックスに向いています。
同価格帯の PC と比べ、macOS の低いクラッシュ率、Gatekeeper と FileVault によるセキュリティは、チーム共有のリモート開発ノードとしても安心です。コンパクトでファンレスな筐体は 7×24 運用の設備コストも抑えます。Windows 本機で iOS / Flutter を開発中なら、AI 実験環境をクラウド Mac に移すほうが、新 GPU 購入より合理的な選択になることも多いです。
PDF 解析から Agent メモリ、4GB での検証から本番オーケストレーションまで、ハードが試行錯誤の天井になる必要はありません——プランを確認する、クラウド Mac mini で 2026 年のオープンソーススタックを一度に走らせましょう。