「AIといえばChatGPTだけ」だった時期は完全に終わりました。本記事の主役 DEEIX Chat が扱うのは、まさにその先の世界です。OpenAIに加え、Anthropic（Claude）、Google（Gemini）、xAI（Grok）、そしてOpenRouterのような集約サービスまで、実務では複数のLLMプロバイダを同時に使い分けるのが当たり前になっています。ところが、プロバイダが増えるほど困りごとも増えます。APIキーがあちこちに散らばり、課金が別々に発生し、SDKや呼び出し方がプロバイダごとに微妙に違い、どのモデルにいくら使ったのかが横断的に見えない——この「分散の痛み」に心当たりのあるチームは多いはずです。

DEEIX Chat（DEEIX-AI/DEEIX-Chat）は、まさにこの課題に正面から答える、複数のLLMプロバイダを1つの入口に束ねるセルフホスト型のオープンソースAI基盤です。単なるチャットUIではなく、AIゲートウェイ（ルーティング）＋チャットUI＋管理コンソールの3つを一体で提供します。ライセンスはApache-2.0、GitHubスターは約770、フォークは97、最新版はv0.3.0（2026年6月30日）で、デフォルトブランチはdev、言語はGo 54%／TypeScript 45%という構成です。

この記事を読むと、次の3点がはっきり分かります。①DEEIX Chatで結局何ができるのか（複数プロバイダへの単一の入口を、自社サーバー上に持てる）、②何を解決するのか（分散したLLMアクセスを集約し、ルーティング・課金・監査までを一元化する）、③何を代替できるのか（各社APIを直接叩く運用や、それを束ねる自前ゲートウェイ＋セルフホストUIの継ぎはぎ構成）。LLMという技術そのものの全体像を押さえたい方は、先にLLM完全ガイド2026を通読しておくと、本記事のゲートウェイやルーティングの位置づけが一段掴みやすくなります。

この記事のポイント
  • ・DEEIX Chatは複数LLMプロバイダを1つの入口に束ねるセルフホスト型のオープンソースAI基盤（Apache-2.0 / v0.3.0 / ⭐約770）。
  • ・AIゲートウェイ・チャットUI・管理コンソールを「単一ランタイム」で提供し、ルーティング・RAG・MCP・課金・監査までを内蔵する。
  • ・「プラットフォーム-モデル」抽象層で、優先度・重み・サーキットブレイクを効かせた上流プロバイダのルーティングができる。
  • ・フロント（Next.js 16 / React 19）は静的アセット化され、Go 1.26 + Ginのランタイムが配信する構成。データ層はPostgreSQL(pgvector)かSQLite(sqlite-vec)を選べる。
  • ・Docker Composeの3プロファイルで、軽量なお試しから本番規模まで同じコードで対応できる。

1. DEEIX Chatとは：複数LLMを束ねるセルフホスト型AI基盤

DEEIX ChatはAIゲートウェイ・チャットUI・管理コンソールを単一ランタイムで束ねるセルフホスト型AI基盤。言語はGo 54%/TypeScript 45%、Apache-2.0、v0.3.0
DEEIX Chatは「ゲートウェイ＋UI＋管理」の3-in-1をセルフホストで所有できる。⭐約770 / Fork 97 / Apache-2.0（2026年7月時点）。

DEEIX Chatは、ひとことで言えば「複数の上流モデル／プロバイダへの単一の明確な入口」を提供するオープンソースのAI基盤です。公式リポジトリはDEEIX-AI組織下のDEEIX-Chatで、ライセンスはApache-2.0。単なるフロントエンドのチャットアプリではなく、内部にAIゲートウェイ（複数プロバイダへのルーティング層）を持ち、その上にチャットUIと管理コンソールが乗っている——この「3つを1つに束ねている」点が最大の特徴です。

なぜ「入口をひとつに束ねる」ことがそれほど重要なのでしょうか。理由はシンプルで、AIの利用が本格化するほど、プロバイダは増える方向にしか進まないからです。あるタスクはGPT系が得意、別のタスクはClaudeが強い、画像生成はまた別のモデル、コストを抑えたい用途はOpenRouter経由——といった使い分けは、実務では合理的な選択です。しかしその合理性の裏で、キー管理・課金・監査・障害対応といった運用コストが、プロバイダの数だけ線形に増えていきます。DEEIX Chatは、この増えていく運用コストを一箇所に集約する基盤として設計されています。

DEEIX Chatが束ねている3つの層を、もう少し具体的に見てみましょう。

・AIゲートウェイ：複数プロバイダ（OpenAI・Anthropic・Google/Gemini・xAI・OpenRouter・OpenAI互換エンドポイント）への単一の入口。テキスト・画像・ツール呼び出し・プロバイダ固有機能を統一的に扱う
・チャットUI：マルチモーダル対応・ストリーミング・会話の分岐（branching）・リトライ・編集・フィードバック・共有まで備えた、実用的なチャット画面
・管理コンソール：ユーザー・ロール・モデル・料金・使用ログ・監査ログ・システムイベントを集中管理する運用画面

つまりDEEIX Chatは、「エンドユーザーが使うチャット画面」と「その裏でモデルを賢く振り分けるゲートウェイ」と「管理者が全体を統制するコンソール」を、別々のツールとして継ぎ足すのではなく、最初から1つのソフトウェアとして提供しているわけです。セルフホスト型なので、これらすべてを自社のインフラ上で動かし、データも鍵も自分たちの管理下に置けます。

2. DEEIX Chatが解決する課題：分散したLLMアクセスの集約

各社APIを直接叩くとキー・課金・SDKが分散しフェイルオーバーも自前になる。DEEIX Chat経由なら単一APIで接続し優先度・重み・サーキットブレイクで自動切替、ログも一元化
各社APIを直接叩く運用（左）と、DEEIX Chatを単一の入口にした運用（右）の対比。

DEEIX Chatが解決しようとしている中心的な課題は、「複数AIプロバイダへのアクセスが分散し、複雑化する」問題です。これを分解すると、実務では次のような具体的な痛みとして現れます。

・キーとシークレットの分散：OpenAIのキー、Anthropicのキー、Geminiのキー……とプロバイダごとに鍵が増え、それぞれの保管・ローテーション・漏洩対策が個別に必要になる
・課金の断片化：請求書がプロバイダごとに別々に来るため、「今月AIに合計いくら使ったのか」「どのチーム・どのモデルが高いのか」を横断的に把握しづらい
・呼び出し方の差異：プロバイダごとにSDKやエンドポイントの作法が微妙に異なり、アプリ側のコードが分岐だらけになる
・障害時の脆さ：あるプロバイダがダウンしたときに別プロバイダへ切り替える仕組みを、自前で実装しなければならない
・監査の困難：誰がいつどのモデルを使い、どんな入出力があったのかを一元的に追跡できない

DEEIX Chatは、これらをすべて「単一の入口」の背後に隠すことで解決します。アプリケーションから見れば、DEEIX Chatに対してOpenAI互換のリクエストを1回投げるだけ。その先で実際にどのプロバイダのどのモデルへ振り分けるか、障害時にどうフォールバックするか、いくらの課金として記録するか、といった複雑さはすべてゲートウェイ側が引き受けます。

ここがポイント
DEEIX Chatの価値は「新しいLLMを作ること」ではなく、「既にあるLLM群を賢く束ねて運用可能にすること」にあります。モデルそのものの性能で勝負するのではなく、複数モデルを扱う運用レイヤーの複雑さを吸収するのが役割です。

言い換えると、DEEIX Chatが代替するのは「AIモデル」ではなく「AIモデルを複数扱うための面倒な配管（プラミング）」です。各社APIを直接叩く運用、それを束ねるために自前で書いたプロキシやルーター、さらにセルフホストのチャットUI——こうした継ぎはぎの構成を、1つの基盤に置き換えられます。ドキュメントを読み込ませて回答させるRAGの仕組みまで内蔵しているため、たとえばRAG実装完全ガイド2026で解説されるような検索拡張生成のパイプラインを、別立てで構築せずにこの基盤の上で完結させられる点も見逃せません。

3. DEEIX Chatのモデル&ルーティング設計：抽象層の考え方

DEEIX Chatはプラットフォーム-モデル抽象層で、統一API入口から上流チャネル/ルートバインディング、サーキットブレイク、実モデル/プロバイダへとルーティングする
「プラットフォーム-モデル」抽象層。入口の統一APIから、優先度・重み・サーキットブレイクを介して実モデルへ振り分ける。

DEEIX Chatのルーティングを支えているのが、「プラットフォーム-モデル」抽象層と呼べる仕組みです。これは、上流のプロバイダやモデルを直接コードから叩くのではなく、いくつかの概念に分けて管理することで、柔軟な振り分けを可能にしています。主な構成要素は次の通りです。

・上流チャネル（upstream channel）：接続先のプロバイダ単位の設定。どのAPIキーで、どのエンドポイントへつなぐか
・実モデル（real model）：チャネルが提供する具体的なモデル（実体）
・ルートバインディング（route binding）：外部に見せる論理的なモデル名と、実モデルの結びつけ
・優先度・重み：同じ役割を担う複数チャネルの間で、どれを優先し、どの比率で振り分けるか
・サーキットブレイク：あるチャネルで障害が続いたときに一時的に切り離し、別チャネルへ逃がす仕組み
・ベンダーマッピング・能力設定：プロバイダ固有の機能差やモデルの能力（画像対応・ツール対応など）を吸収する設定

この抽象化によって、たとえば「gpt-fastという論理モデル名」を用意し、その実体を「優先度1でOpenAI、優先度2でAnthropic、フォールバックでOpenRouter」に束ねる、といった構成が設定だけで組めます。アプリ側はgpt-fastを呼ぶだけでよく、裏側の切り替えを意識する必要がありません。

このルーティングの流れを図にすると、次のようになります。分岐ロジックを含むため、ここは省略せず精密に追える図として掲載します。

flowchart TD A["クライアント
OpenAI互換リクエスト"] --> B["DEEIX Chat
統一ゲートウェイ"] B --> C{"ルートバインディング
優先度・重み"} C -->|優先度1| D["上流チャネルA
OpenAI"] C -->|優先度2| E["上流チャネルB
Anthropic"] C -->|フォールバック| F["上流チャネルC
OpenRouter"] D --> G{"サーキットブレイク"} G -->|正常| H["実モデルへ送信"] G -->|障害検知| E H --> I["ストリーミング応答
実行メタデータを記録"]

重要なのは、この仕組みが単なる負荷分散にとどまらないという点です。優先度と重みを組み合わせれば「基本は安価なモデル、重要な会話だけ高性能モデル」といったコスト最適化ができますし、サーキットブレイクを効かせれば特定プロバイダの障害がサービス全体の停止に直結しにくくなります。対応プロトコルはOpenAI・Anthropic・Google/Gemini・xAI・OpenRouter・OpenAI互換エンドポイントと幅広く、テキストだけでなく画像・ツール呼び出し・プロバイダ固有機能まで統一的に扱える点も、実運用での柔軟性を高めています。

4. DEEIX Chatのチャット・ファイル・MCPツール機能

DEEIX Chatの画像生成画面。Studio Ghibli風の猫の画像をgpt-image-2で生成し、トークン数・レイテンシ・コストが1件ごとに表示される
マルチモーダル対応の一例。画像生成（gpt-image-2）を実行し、各生成のトークン・レイテンシ・コストがメタデータとして残る。出典: 公式リポジトリ

DEEIX Chatの「使う側」の体験、つまりチャット機能は、単なるメッセージのやり取りにとどまりません。実務で必要になる会話の操作性とドキュメントの取り込み、そして外部ツール連携が一通り揃っています。

まず会話まわりでは、マルチモーダル入力・ストリーミング応答に加えて、分岐（branching）・リトライ・編集・フィードバック・共有・実行メタデータのトレーサビリティが用意されています。分岐は「この返答から別の方向性も試したい」というときに会話をフォークできる機能で、リトライや編集と組み合わせると、試行錯誤の履歴を失わずに複数の案を比較できます。各応答にはトークン数・レイテンシ・コストといった実行メタデータが紐づくため、「どの会話が高コストだったか」を後から追跡できます。

ファイルと検索の機能は、そのままRAG基盤として使える水準です。具体的には次の処理を内蔵しています。

・アップロード／プレビュー／抽出：ファイルを取り込み、内容を抽出する
・OCR：Apache Tika・Docling・RapidOCR・Tesseract・PaddleOCR・MinerUといった複数のエンジンに対応し、画像やスキャンPDFからもテキストを取り出す
・ストレージ枠：ユーザーごとの保存容量を管理する
・全文コンテキスト注入／チャンク化／埋め込み：ドキュメントを分割し、ベクトル化する
・セマンティック検索：意味的に近い箇所を検索し、回答の根拠として使う

この「ドキュメントを読ませて、その内容に基づいて答えさせる」流れは、ノート横断の知識活用ツールと発想が近く、たとえばOpen Notebook（NotebookLM代替）のようなツールが担う領域を、DEEIX Chatはゲートウェイと同じ基盤の中で提供します。

DEEIX ChatのArtifacts機能。チャットでHTML/CSS/JSのコードを生成し、右ペインでライブプレビューとソースを切り替えて確認できる
Artifacts機能。生成したHTML/CSS/JSをその場でプレビューできる（画面はGemini系モデルでの生成例）。出典: 公式リポジトリ

さらに外部連携として、MCP（Model Context Protocol）に対応しています。DEEIX ChatはStreamable HTTPのJSON-RPCでMCPサーバーを扱え、外部ツールの発見・有効化・実行制限・トレーサビリティを効かせられます。加えてプロバイダ純正のツール（各社が提供するツール機能）とも組み合わせられるため、「AIが外部ツールを呼び出して作業を進める」エージェント的な使い方を、実行制限とログを効かせながら安全に運用できます。コンテキスト管理も作り込まれており、メッセージ窓・トークン予算・要約による圧縮・会話メモリ・長期メモリ・RAGのエビデンス記録といった、長い会話や大量のドキュメントを扱う上で欠かせない機能が揃っています。

5. DEEIX Chatのアーキテクチャ：単一ランタイムとデータ層

DEEIX Chatのアーキテクチャ。Next.js 16/React 19を静的アセットにビルドしGo 1.26+Ginが配信する単一ランタイム。データ層はPostgreSQL+pgvectorかSQLite+sqlite-vecを選べる
フロントを静的化してGoランタイムが配信する「単一ランタイム」構成。データ・キャッシュ・ストレージは用途に応じて差し替えられる。

DEEIX Chatのアーキテクチャで最も特徴的なのが、「単一ランタイム」構成です。フロントエンドはNext.js 16 / React 19で作られていますが、これは静的アセットにビルドされ、Goのランタイムがそのまま配信する設計になっています。つまり、フロント用のNode.jsサーバーを別建てで運用する必要がなく、Goのバイナリ（コンテナ）1つでフロントもAPIも完結します。

バックエンドはGo 1.26 + Gin（Webフレームワーク）+ Gorm（ORM）で構成されています。データ層・キャッシュ・ストレージは、それぞれ用途に応じて選択できる柔軟な設計です。

・データ層：PostgreSQL（pgvector拡張でベクトル検索）または SQLite（sqlite-vecでベクトル検索）
・キャッシュ：Redis または インメモリ
・ストレージ：ローカルファイルシステム または S3互換オブジェクトストレージ

この「同じコードのまま、構成だけ差し替えられる」性質が効いてきます。小さく試すならSQLite＋インメモリ＋ローカルストレージで十分ですし、本番規模ならPostgreSQL＋Redis＋S3へ、コードを書き換えずに移行できます。公式リポジトリに掲載されているアーキテクチャ図でも、ユーザー（Web／管理者）→フロントエンド→コアアプリ（Go Gin API）→外部サービス、という流れと、その下にデータ層（PostgreSQL＋pgvector／Redis／S3）がぶら下がる構造が示されています。

DEEIX Chatの公式アーキテクチャ図。USERS→FRONTEND(Next.js静的Webアプリ)→CORE APP(DEEIX Chat App Container/Go Gin API)→EXTERNAL SERVICES(各AIプロバイダ・MCP・OCR・Stripe/ePay)。下部にDATA層としてPostgreSQL+pgvector、Redis、S3ストレージ
DEEIX Chatの公式アーキテクチャ図。単一のGoコンテナがフロント配信とAPIを担い、外部プロバイダ・MCP・OCR・決済へつながる。出典: 公式リポジトリ

リクエストが処理される流れを、単一ランタイムの視点で図示すると次のようになります。

flowchart LR U["Web / Admin
ユーザー"] --> R["Go 1.26 + Gin
単一ランタイム"] R --> S["静的アセット
Next.js 16 を配信"] R --> DB[("PostgreSQL
pgvector")] R --> CA[("Redis / インメモリ
キャッシュ")] R --> ST["ローカル / S3
ストレージ"] R --> P["上流プロバイダ
OpenAI ほか"]

この単一ランタイム構成には、運用上の明確なメリットがあります。デプロイ対象がGoコンテナ1つに集約されるため、フロントとバックエンドのバージョン不整合やCORSまわりの煩わしさが減り、コンテナオーケストレーションもシンプルになります。設定はYAMLファイル（config.yaml）に集約されており、たとえば最小構成のSQLite向け設定はおおむね次のようなイメージです（実際のキーはリポジトリのconfig.sqlite.example.yamlを参照してください）。

# config.yaml（SQLite最小構成のイメージ）
server:
  mode: production        # 本番モードでは危険な既定値を拒否
  listen: "0.0.0.0:8080"
database:
  driver: sqlite          # sqlite-vec でベクトル検索
  dsn: "./data/deeix.db"
cache:
  driver: memory          # Redis or インメモリ
storage:
  driver: local           # local or S3互換
security:
  encryption_key: "<32バイト以上の強い鍵>"  # 弱い鍵は本番モードで拒否

6. DEEIX Chatのセキュリティ・課金・管理：運用の実像

DEEIX Chatが内蔵する運用5領域。AES-GCM暗号化、2FA/SSO(TOTP・OIDC)、課金(Stripe・EPay)、モデル別従量の使用ログ、集中管理の監査ログ
DEEIX Chatは運用に必要な暗号化・認証・課金・使用ログ・監査ログを最初から内蔵する。

セルフホスト型のAI基盤を本番運用するとなると、機能そのものよりセキュリティと課金と管理が現実的な壁になります。DEEIX Chatは、この「地味だが不可欠な部分」を最初から作り込んでいます。

ID＆セキュリティの面では、次の仕組みが用意されています。

・認証方式：ローカルアカウント・セッション・2FA/TOTP・SSO（OIDC/OAuth）に対応
・機密データの暗号化：上流APIキー・SSOシークレット・MCPトークンをAES-GCMで暗号化して保存
・パスワード保護：bcryptでハッシュ化
・トークン設計：短命のアクセストークンをメモリに保持し、リフレッシュはHttpOnly Cookieで行う
・安全な既定値：本番モードでは、弱い暗号鍵やワイルドカードCORSといった危険な既定を拒否するとされる

とりわけ「本番モードで危険な既定値を拒否する」という設計は重要です。セルフホストのソフトウェアは、開発時の緩い設定のまま本番に出てしまう事故が起きやすいものですが、DEEIX Chatは弱い鍵や無制限のCORSをそのまま本番稼働させない方向に倒しています。

DEEIX Chatの課金・使用状況画面。総コスト・総トークン・呼び出し回数・平均レイテンシと、日次の使用量グラフ、モデル別の使用ログ（base billing/service billing/latency）が並ぶ
使用状況ダッシュボード。総コスト・トークン・呼び出し回数・平均レイテンシに加え、モデル別の課金明細（base/service billing）とレイテンシが1件ずつ記録される。出典: 公式リポジトリ

課金＆決済の面では、モデル料金・ツールの従量課金・サブスクリプション・チャージ（残高）に対応し、決済はStripe CheckoutとEPayを扱えます。上のダッシュボードのように、総コスト・総トークン・呼び出し回数・平均レイテンシといった集計に加え、モデルごとの課金明細（基本課金とサービス課金）が1件ずつ記録されるため、「どのモデルにいくら使ったか」を横断的に把握できます。分散課金の痛みを、この一元的な使用ログが解消してくれるわけです。

管理＆監査の面では、ユーザー・ロール・モデル・料金・使用ログ・監査ログ・システムイベントを集中管理できます。ロールベースで権限を分け、誰がいつ何をしたかを監査ログで追える構造は、チームや組織で使う際に欠かせません。この「運用に必要なものが最初から揃っている」点こそ、単なるチャットUIのOSSと、AI基盤を名乗るDEEIX Chatとの差だと言えます。

7. DEEIX Chatのデプロイ手順：Docker Composeの3プロファイル

DEEIX ChatのDocker Compose3プロファイル。軽量(SQLite単体)、標準(既存PostgreSQL+Redis)、フルスタック(PG・Redis同梱)をconfig.yamlとdocker compose up -dで起動
用途に応じて3つのプロファイルを選び、config.yamlを用意してdocker compose up -dするだけで起動できる。

DEEIX Chatの導入は、Docker Composeの3プロファイルとして整理されており、目的に応じて選べます。ここでは公式リポジトリの手順に沿って、代表的な起動方法を紹介します（検証環境: Docker + Docker Compose、2026-07-02時点のv0.3.0系を想定）。

① 軽量プロファイル（SQLite） — まず試したい人向け。データベースにSQLiteを使うため、外部のPostgreSQLやRedisを用意する必要がありません。

# SQLite構成で起動（最も手軽なお試し用）
cp config.sqlite.example.yaml config.yaml
docker compose -f docker-compose.sqlite.yml up -d

② 標準プロファイル（既存のPostgreSQL + Redis） — すでにPostgreSQLとRedisを運用している環境に組み込む場合。

# 既存のPostgreSQL + Redis を使う構成で起動
cp config.example.yaml config.yaml
docker compose up -d

③ フルスタックプロファイル — PostgreSQLもRedisもまとめて同梱し、一式を立ち上げたい場合はdocker-compose.full.ymlを使います。

# PostgreSQL・Redis を同梱したフルスタック構成
cp config.example.yaml config.yaml
docker compose -f docker-compose.full.yml up -d

いずれのプロファイルでも、まずconfig.yamlを用意し、docker compose up -dで起動する、という流れは共通です。設定ファイルの雛形（config.example.yaml / config.sqlite.example.yaml）が同梱されているので、それをコピーして必要な箇所（暗号鍵・プロバイダのAPIキー・ストレージ設定など）を埋めるのが基本手順になります。

ローカルで開発・改造したい場合は、Docker Composeを使わずに直接動かすこともできます。バックエンドとフロントエンドを別々に起動する構成です。

# バックエンド（Go）
cd backend
make run

# フロントエンド（Next.js）は別ターミナルで
cd frontend
pnpm dev
本番運用の注意
DEEIX Chatは本番モードで弱い暗号鍵やワイルドカードCORSを拒否する設計とされていますが、それでもセルフホストである以上、暗号鍵の安全な管理・データベースのバックアップ・アップデート追従・上流プロバイダのキー管理は運用側の責任です。最新版はv0.3.0とまだ0.x系であり、破壊的変更の可能性も念頭に、まずは検証環境で挙動を確認してから本番に載せるのが安全です。

導入後の全体像を、デプロイ観点で他の選択肢と比較すると、DEEIX Chatが「どこを引き受けてくれるのか」がはっきりします。次の比較表を参考にしてください。

観点 各社APIを直接叩く LibreChat等のセルフホストUI DEEIX Chat
複数プロバイダの束ね アプリ側で自前実装 UIレベルで切替（ルーティングは限定的） ゲートウェイとして内蔵（優先度・重み・サーキットブレイク）
ルーティング/フォールバック 自前 限定的 抽象層で設定可能
RAG/ファイル検索 別途構築 実装により差 内蔵（OCR・チャンク化・埋め込み・セマンティック検索）
MCPツール連携 自前 実装により差 内蔵（Streamable HTTP JSON-RPC）
課金/使用ログ プロバイダごとに分散 限定的 モデル別従量・Stripe/EPay・使用/監査ログを一元化
セキュリティ既定 自前で担保 実装により差 AES-GCM暗号化・本番モードで危険既定を拒否
デプロイ アプリに内包 Docker等 Docker Compose 3プロファイル（単一ランタイム）
ライセンス — プロジェクト依存 Apache-2.0

※ LibreChatやその他OSSの機能は各プロジェクトのバージョンにより異なります。上表はDEEIX Chatの位置づけを示すための概念的な整理で、機能の一対一の同等性を保証するものではありません。用途に応じて各プロジェクトの最新ドキュメントで確認してください。なお、複数のAIエージェントやセッションを束ねて扱いたいというニーズでは、ターミナル側で多重化するherdr（エージェント版tmux）のようなアプローチもあり、DEEIX Chatの「サーバー側でプロバイダを束ねる」発想と対比すると理解が深まります。

まとめ

DEEIX Chatは、複数のLLMプロバイダを1つの入口に束ねるセルフホスト型のオープンソースAI基盤です。最後に、この記事の要点を「読者の3問」に沿って整理します。

・①何ができるのか：OpenAI・Anthropic・Google/Gemini・xAI・OpenRouter・OpenAI互換エンドポイントへの単一の入口を、自社インフラ上に持てる。チャットUI・ゲートウェイ・管理コンソールが3-in-1で、会話（分岐・リトライ・共有）、ファイル＆RAG（OCR・埋め込み・セマンティック検索）、MCPツール連携、課金、監査までを内蔵する
・②何を解決するのか：プロバイダが増えるほど分散していくキー・課金・SDK・障害対応・監査を、ゲートウェイの背後に集約する。「プラットフォーム-モデル」抽象層で優先度・重み・サーキットブレイクを効かせ、コスト最適化と可用性を両立できる
・③何を代替できるのか：各社APIを直接叩く運用や、それを束ねる自前ゲートウェイ＋セルフホストUIの継ぎはぎ構成。RAGやMCPまで同じ基盤で完結する

技術構成は、フロント（Next.js 16 / React 19）を静的化してGo 1.26 + Ginが配信する単一ランタイム、データ層はPostgreSQL(pgvector)かSQLite(sqlite-vec)を選択、という現実的で移行しやすい設計です。ライセンスはApache-2.0、最新版はv0.3.0（デフォルトブランチはdev、⭐約770）とまだ0.x系ですが、AIの利用がマルチプロバイダ前提になった2026年において、「複数LLMを束ねる運用レイヤーを自分たちで所有する」という選択肢を、オープンソースで手に入れられる意義は小さくありません。まずはSQLite構成で軽く立ち上げ、自社のユースケースに合うかを試してみるところから始めるのがおすすめです。

参照ソース

・DEEIX-AI/DEEIX-Chat (GitHub) — 公式リポジトリ。README・アーキテクチャ図・設定例・Docker Composeプロファイル
・DEEIX 公式サイト — プロジェクトの公式情報
・ライセンス: Apache-2.0 ／ 最新版: v0.3.0（2026-06-30） ／ デフォルトブランチ: dev（いずれも2026年7月2日時点、公式リポジトリより）