RAG

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...

香港大学データインテリジェンスラボ（HKUDS）が開発したオープンソースの動画生成フレームワーク ViMax が GitHub で急速にスターを伸ばしている（3,800超・MIT ライセンス）。1行のテキストアイデアを入力するだけで、脚本執筆・絵コンテ設計・キャラクター管理・最終動画レンダリングまでを自律的に実行するエンドツーエンドのマルチエージェントシステムだ。 ViMax とは ViMax（Video Maximizer）は「Director（監督）・Screenwriter（脚本家）・Producer（プロデューサー）・Video Generator（映像生成）をひとつに」という設計コンセプトで開発された動画生成フレームワークだ。従来、テキストから動画を生成するには複数のツールを組み合わせる必要があった。ViMax はそのパイプライン全体をマルチエージェント構成で自動化する。 GitHub: HKUDS/ViMax ライセンス: MIT 言語: Python 3.12+ Stars: 3,852+（2026年5月時点） 4つの生成モード ViMax には入力形式に応じた 4 つのモードが用意されている。 Idea2Video 1 行の概念・プロンプトを入力すると、ストーリーテリング・キャラクターデザイン・動画制作まで完全自動化される。「アイデアをそのまま映像に」したいユーザー向けのモードだ。 Novel2Video 小説の章や全文を入力すると、エピソード形式の動画に変換される。RAG（検索拡張生成）ベースのナラティブ圧縮機能でキャラクターの登場追跡とシーンごとの視覚的解釈を行う。長編小説の映像化に適している。 Script2Video ユーザーが書いたシナリオを動画化する。シーン・セリフ・スタイルを明示的に指定でき、映像表現への細かいコントロールが可能。 AutoCameo 自分の写真をアップロードすると、生成された動画に本人が一貫したキャラクターとして登場する機能。個人の顔や姿を主人公として組み込める。 主要な技術的特徴 インテリジェントな長編スクリプト生成（RAG ベース） 小説規模のテキストを解析し、マルチシーン形式に分割する。重要な伏線やキャラクターの台詞を保持しながら、映像に適した脚本へ変換する。 表現力豊かな絵コンテ設計 ショットレベルの絵コンテシステムに映画製作の語彙（カメラアングル・カット・テンポ・ナラティブリズム）を採用している。 マルチカメラ撮影シミュレーション 同一シーン内でのキャラクター配置・背景の一貫性を保ちながら、複数のカメラアングルをシミュレートする。 インテリジェントな参照画像選択 タイムライン上の過去の絵コンテを参照画像として自動選択し、長尺動画でもキャラクターや背景の整合性を維持する。 並列候補生成 + MLLM による一貫性チェック 複数の候補画像を並列生成し、マルチモーダル LLM（MLLM — テキストと画像を同時に扱える大規模言語モデル）が最も一貫性の高い画像を選択する。人間のクリエイターのレビューワークフローを自動化したアプローチだ。 並列ショット生成による高速化 同じカメラからの連続するショットを並列処理することで、生成時間を大幅に短縮する。 音声・映像バインディング 音声・効果音・映像を同期させ、没入感のある最終出力を生成する。 マルチエージェントパイプラインの構造 ViMax の処理パイプラインは以下の層で構成されている。 インストールと設定 動作環境: Linux または Windows / Python 3.12+ / uv（Astral パッケージマネージャー） ...

RAGの長年の課題である「回答の網羅性の欠如」を、ベクトルDBを使わずに解決しようとする論文が登場した。2026年4月16日にarXivに公開された論文「Don’t Retrieve, Navigate」は、Corpus2Skill という新手法を提案している。文書コーパスを階層的スキルディレクトリへ事前変換し、LLMエージェントがナビゲートして回答を構築するアプローチだ。 従来のRAGが抱える課題 RAG（Retrieval-Augmented Generation）はこの数年で大きく進化し、多くの問題が解決されてきた。しかし「AIの回答が網羅的でない」という問題は依然として未解決のままだ。 従来のベクトル検索ベースのRAGでは、クエリに類似したチャンクをいくつか取得して回答を生成する。この方式の弱点は以下の通りだ。 クエリ表現に引きずられ、関連する別の観点の文書を見落とす チャンク間の文脈的なつながりが断ち切られる 広範なトピックをカバーする質問への回答が部分的になりがち Corpus2Skillのアプローチ：「検索するな、ナビゲートせよ」 Corpus2Skillは発想を根本から変える。ベクトル検索で文書を「取ってくる」のではなく、人間が目次や索引を辿るように、エージェントがコーパスの階層構造を「ナビゲートする」。 オフラインのコンパイルパイプライン まず事前処理として、文書コーパスを階層的スキルディレクトリへ変換する。 反復クラスタリング — 全文書をk-meansなどでグループ化する LLM生成サマリー — 各クラスタの内容をLLMが要約する 階層化 — クラスタをさらに上位概念でまとめ、ピラミッド構造を構築する スキルファイルツリーの実体化 — 結果を SKILL.md / INDEX.md の形式でファイルシステムに保存する この処理はオフラインで行われるため、推論時の遅延には影響しない。 推論時のナビゲーション 質問が来たとき、LLMエージェントは次の手順で回答を構築する。 コーパス全体の俯瞰図（ルートサマリー）を受け取る 質問に関連する上位ブランチを選択し、段階的に下位サマリーへ降下する 目的のノードに到達したら、文書IDを使って完全な文書を取得する 必要に応じてバックトラックし、別のブランチも探索する この探索パスが明示的に推論されるため、なぜその文書が取得されたかを追跡できるという副次的なメリットもある。 ベクトルDBが不要になる理由 従来のRAGではベクトルDB（Pinecone, Weaviate, Chromaなど）が必須だった。Corpus2Skillでは、スキルファイルツリーがその役割を置き換える。 項目 従来のRAG Corpus2Skill インデックス形式 ベクトルDB 階層ファイルツリー 検索方式 類似度検索 エージェントによるナビゲーション インフラ依存 ベクトルDBが必要 ファイルシステムのみ スケーラビリティ O(N) O(log N) 探索パスの透明性 低い 高い（明示的に推論） 文書数が10万件でも階層深度はO(log N)に収まるため、大規模コーパスへのスケーラビリティが高い点も特長だ。 実験結果 WixQAベンチマーク Wix社の企業向け顧客サポートを対象とするWixQAベンチマークで評価した。比較対象は以下のベースラインだ。 Dense Retrieval（密集検索）: 従来のベクトル検索RAG RAPTOR: 階層的サマリーを使った検索手法 Agent RAG: エージェントが検索を制御する手法 Corpus2Skillは全品質指標でこれらすべてを上回った。 ...

Andrej Karpathy（元 OpenAI・元 Tesla AI ディレクター）が提唱した「Claude Code での第二の脳の作り方」。 この記事では、Claude Code + Obsidian を組み合わせて知識を蓄積・進化させる「AI 第二の脳」システムの仕組みとセットアップ手順を解説します。 普通の RAG と何が違うのか ChatGPT へのファイルアップロードや NotebookLM のような一般的な RAG は、以下のように動きます。 ファイルを渡す 質問のたびに AI が関連部分を探す 毎回ゼロから答えを生成する 次の質問がきたら、また同じことをゼロから繰り返す 何も積み重ならないのが問題です。 Karpathy が提唱したシステムは根本的に異なり、**AI が「Wiki を育て続ける」**仕組みです。新しい資料を入れるたびに、AI がその内容を読んで既存の知識と統合し、矛盾があれば修正し、関連ページを更新します。知識が一度まとめられると、常に最新状態に保たれます。 システムの全体像 このシステムには 4 つの動く部品があります。 あなたのデータ — 記事・ノート・文字起こし・アイデアなど 整理 — Claude Code が Obsidian に自動で整理 即座の質問 — 育てたデータベースにいつでも質問可能 進化する記憶 — 使えば使うほど賢くなる仕組み 3 つの層構造 層 名称 役割 層 1 生のソース（immutable） 記事・論文・画像・データファイル。AI は読むだけで書き換えない 層 2 Wiki 要約・人物・概念・比較・総合分析ページ。AI が作成・更新し続ける 層 3 スキーマ（CLAUDE.md） Wiki の構造・ルール・ワークフローを AI に教える設定ファイル この 3 層構造により、AI が「汎用チャットボット」ではなく「規律を持った Wiki 管理者」として動きます。 ...

「現在の90%のAI Agentの記憶は偽物だ」——AI研究者 @AYi_AInotes がXでこう発言し、大きな反響を呼んでいる。 多くの開発者が同じ罠にはまっている。「会話履歴や決定ログをMarkdownファイルに溜め込めば長期記憶になる」という誤解だ。 この記事では、なぜMarkdownダンプが「記憶」ではないのか、4つの根本的欠陥と2026年時点で実用可能なグラフ×埋め込みベースの代替設計を解説する。 Markdownファイルへの履歴ダンプが崩壊するまで @AYi_AInotes 自身の失敗談がわかりやすい。失敗は次の順序で進んだ。 全ての会話履歴・決定ログをMarkdownファイルに蓄積 「これで長期記憶が実現できた」と信じる 2週間で崩壊 崩壊の具体的な症状： 同一事実に3つの矛盾バージョンが存在する — 上書きも検証もなく書き足し続けた結果 先月の好みと昨日の重みが同等に扱われる — 時系列の概念がない 毎回全コンテキストを詰め込む — 遅延増大、コンテキスト汚染（クロストーク）が頻発 Markdownベース記憶の4つの根本的欠陥 1. 重複排除がない（No Deduplication） 同じ情報が何度も書き込まれ、どれが最新・正確かわからなくなる。矛盾する記述が増え続け、Agentが混乱する。 2. セマンティック検索ができない（No Semantic Retrieval） キーワードマッチしか使えず、関連情報を文脈で引き出せない。「先月の判断」と「今月の判断」の関係性が見えない。 3. 時系列優先度がない（No Temporal Weighting） 古い情報と新しい情報が同等に扱われる。ユーザーの好みが変化しても、Agentは古い情報に引きずられる。 4. エンティティ間の関係を持てない（No Relationship Modeling） 「AとBは関係がある」「Cの前提はDである」という構造を表現できない。フラットなテキストでは知識の構造化が不可能。 PromptをRAMとして使うことの問題 Markdownダンプを人間の記憶に例えると： 脳に情報を定着させるのではなく、ノートに書いて毎回全文を読み返すようなもの ノートが増えるほど読み返す時間が増え、矛盾も増える これは記憶ではなく、外部ストレージへの都度参照だ 本物の記憶は： 関連情報を索引化して素早く引き出せる 同じ情報を重複して持たない（圧縮・統合） 時間の経過とともに重要度が変化する 事実間の関係性を持つ Markdownダンプはこれを一切満たさない。PromptをRAMとして使っているだけだ。 本物の記憶 = グラフ + ベクトル埋め込み + トラバーサル 本物の記憶の設計原則は3つのコンポーネントで構成される： グラフ（Graph） 知識をノードとエッジで構造化する。エンティティ（人、概念、出来事）をノードとして、その関係をエッジとして保存する。「AはBを好む」「CはDに依存する」という関係が明示的に管理できる。 埋め込み（Embeddings） 各ノードをベクトルに変換することで、意味的に近い情報を検索できる。「先週の決定」と「今週の状況」の意味的類似性を計算し、関連する記憶だけを取り出せる。 トラバーサル（Traversal） グラフを辿ることで、直接リンクされていない関連情報も発見できる。「ユーザーの好みA → 関連する行動B → 影響を受けた決定C」という連鎖をたどれる。 ...

概要 Exa は LLM/AI エージェント向けに最適化されたセマンティック検索 API。Google などのキーワード検索エンジンと異なり、自然言語クエリと意図でドキュメントをマッチングするため、AI エージェントのコンテキスト取得に向く。 公式: https://exa.ai/ 主要機能 Neural Search: 埋め込みベースのセマンティック検索 Keyword Search: 従来型のキーワード一致検索もサポート Find Similar: 与えた URL/ドキュメントと意味的に近いページを取得 Contents API: 検索結果のフルテキスト・要約・ハイライトを返す Live Crawl: 検索時にリアルタイムでクロールするモード Claude / Claude Code での利用 Exa for Claude（MCP プラグイン） として提供されており、Claude Code から MCP 経由で呼び出せる。導入後は通常の Web Search ツールに加えて Exa の高度なセマンティック検索を利用できる。 Model Context Protocol サーバとして接続するため、API キー設定とサーバ起動の標準的な MCP セットアップで動く。 想定ユースケース RAG のクエリリライタ: 「自然言語の質問」→ 関連ドキュメント取得（RAG） エージェントの調査タスク: 競合調査、技術調査、論文検索 コーディング支援: GitHub やドキュメントサイトを横断したコード例・ライブラリ調査 関連ページ MCP（Model Context Protocol） RAG Claude Code ソース記事 Exa for Claude MCP プラグイン — 2026-04-25

概要 Open Notebook は、Google NotebookLM のような「ノートにソース文書を集約 → AI に質問」型のリサーチツールを OSS で実装したプロジェクト。プライベートな文書や機密データを外部 SaaS にアップロードしたくないユースケースで、ローカル LLM や任意の API バックエンドと組み合わせて使える点が特徴。 NotebookLM との関係 NotebookLM は Google が提供するソース駆動の AI ノートで、PDF・Web・YouTube などをノートに追加すると LLM が文脈を理解した回答を返す。Open Notebook はそのオープンソース版として、機能を再現しつつバックエンド LLM を差し替えられる柔軟性を持つ。 想定ユースケース 機密文書の要約・QA: 社外秘・クライアント文書を外部にアップロードせず分析 研究ノート: 論文・ノート・実験ログを統合してエージェント風に質問 個人の知識ベース: Obsidian や Markdown ファイル群と連携した「自分専用 NotebookLM」 関連ページ RAG — 同じ「文書集約 + 質問応答」のパターンの背景概念 Obsidian — 個人ノートとの組み合わせ候補 Ollama — ローカル LLM バックエンド ソース記事 Open Notebook — NotebookLM の OSS 代替 — 2026-04-22

Claude CodeやCodexのようなAgent Harnessは、RAG（Retrieval-Augmented Generation）をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか？Software Engineer兼Database ResearcherのTaro L. Saito（@taroleo）氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点：断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点： 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握（ls、find など） 関連ファイルの直接読み込み（cat、read） 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより： 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか？」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース： 100ファイルを超える大規模コードベース（モノレポ、大企業の内部リポジトリ） 広範なドキュメント検索（社内ナレッジベース、技術文書） リアルタイム情報の取得（外部ドキュメント、最新の仕様） コンテキストに収まる場合に直接読み込みが有効なケース： 中小規模のプロジェクト（スタートアップのコードベース、個人プロジェクト） 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り： ...

概要 旧称 Danswer から改名されたオープンソースの企業向け AI アシスタント＆検索プラットフォーム。Slack・GitHub・Confluence・Google Drive など 50 以上のコネクタで社内ナレッジを統合し、自然言語で検索・質問できる。GitHub スター数 22,000 超。 ライセンス: Community Edition (CE) は MIT ライセンスで無料 GitHub: onyx-dot-app/onyx 主な機能 機能 内容 ハイブリッド検索 ベクトル検索 + キーワード検索の組み合わせ Agentic RAG エージェントが自律的に多段階検索 Deep Research 複数ステップのリサーチでレポート生成 カスタムエージェント 独自の指示・知識・アクションを持つエージェント 50 以上のコネクタ Slack・GitHub・Notion・Jira・Linear など MCP 対応 MCP 経由のカスタムコネクタも可 セルフホスト手順 Docker と Docker Compose があれば数分でデプロイ可能: 1 2 3 curl -fsSL https://raw.githubusercontent.com/onyx-dot-app/onyx/main/deployment/docker_compose/install.sh > install.sh chmod +x install.sh ./install.sh 対応 LLM クラウド LLM（OpenAI・Anthropic・Gemini）とローカル LLM（Ollama・vLLM・LiteLLM）の両方に対応。完全オンプレミス構成で外部 API なしの運用も可能。 ...