Jitera Self-Hostedは、アプリケーションマイクロサービス、インフラストラクチャサービス、データストアで構成されるKubernetesベースのプラットフォームです。このページでは、サポートされるデプロイ構成とアーキテクチャの概要を説明します。Documentation Index
Fetch the complete documentation index at: https://docs.jitera.ai/llms.txt
Use this file to discover all available pages before exploring further.
サポートされる構成
Jiteraは、プラットフォームの実行場所（パブリッククラウドまたはオンプレミス）とLLMへのアクセス方法（パブリックまたはプライベート）の2つの軸で定義される、4つのデプロイモデルをサポートしています。| 構成 | ネットワーク分離 | データ管理コントロール | インフラストラクチャ難易度 | インストールガイド |
|---|---|---|---|---|
| パブリッククラウド + パブリックLLM | 低 | 低 | 低 | AWS EKS、Azure AKS |
| パブリッククラウド + プライベートLLM | 中〜高 | 中〜高 | 低〜中 | AWS EKS、Azure AKS |
| オンプレミス + パブリックLLM | 中 | 中 | 高 | オンプレミス |
| オンプレミス + プライベートLLM | 高 | 高 | 非常に高い | オンプレミス |
パブリッククラウドは標準的なマルチテナントIaaS/PaaS環境（AWS、Azure）を指します。専用ハードウェア（例：AWS Dedicated Hosts）やハイブリッド拡張（例：AWS Outposts）は除外されます。オンプレミスは組織の施設内で所有・物理的に保守されるインフラストラクチャを指します。IaaSプロバイダーが管理するホステッドプライベートクラウドサービスは除外されます。パブリックLLMは外部ベンダー（例：OpenAI、Google Gemini）がホストし、API経由でアクセスするモデルを指します。プライベートLLMはユーザーが管理するインフラストラクチャにデプロイされたオープンソースまたはライセンスモデル（例：Qwen、Llama、Mistral）を指します。
パブリッククラウド + パブリックLLM
最もシンプルなデプロイモデルです。Jiteraはマネージド Kubernetes サービス（EKS / AKS）上で実行され、インターネット経由で外部LLMプロバイダーに接続します。- ネットワーク分離 — 低： インフラストラクチャはVPC / Virtual Networkで分離できますが、LLM APIコールはパブリックインターネットを経由します。
- データ管理コントロール — 低： インフラストラクチャとAIモデルの両方がサードパーティによって管理されます。
- インフラストラクチャ難易度 — 低： マネージド Kubernetes によりコントロールプレーン管理が不要です。物理ハードウェアは不要です。
パブリッククラウド + プライベートLLM
Jiteraはマネージド Kubernetes サービス上で実行され、LLMはユーザー自身のクラウド環境（例：同一VPC内のGPUインスタンス）にデプロイされます。- ネットワーク分離 — 中〜高： 閉域ネットワーク（VPC内）を通じてLLMへのアクセスを保護できます。
- データ管理コントロール — 中〜高： LLM実行環境はユーザー自身のクラウドテナント内で構築・管理されます。データはユーザーのクラウド環境内に留まります。
- インフラストラクチャ難易度 — 低〜中： パブリックLLMモデルに加えて、GPUノードのリソース管理（オートスケーリング設定、GPUクォータリクエスト）が追加されます。
オンプレミス + パブリックLLM
Jiteraはユーザー所有のハードウェア上で実行されますが、インターネット経由で外部LLMプロバイダーに接続します。- ネットワーク分離 — 中： インフラストラクチャは完全に分離されていますが、LLM APIコールはパブリックインターネットを経由します。
- データ管理コントロール — 中： データの使用・保持ポリシーはLLMプロバイダーに依存します。オンプレミスのデータは外部に送信されます。
- インフラストラクチャ難易度 — 高： Kubernetesクラスターをゼロから構築する必要があります（HAコントロールプレーン、etcdバックアップ、ロードバランサー、ストレージクラスの設定）。ハードウェアの調達、設置、物理的なメンテナンスが必要です。
オンプレミス + プライベートLLM
最も分離度の高いデプロイモデルです。JiteraとLLMの両方が、組織のネットワーク内のユーザー所有ハードウェア上で完全に実行されます。- ネットワーク分離 — 高： LLMへのアクセスは組織の閉域ネットワーク内で完結します。
- データ管理コントロール — 高： LLM実行環境とすべてのデータが、外部への露出なしに組織内で管理・運用されます。
- インフラストラクチャ難易度 — 非常に高い： オンプレミス Kubernetes 管理に加えて、KubernetesのアップグレードにはNVIDIAドライバーとContainer Toolkitの厳密なテストが必要です。GPUサーバーは高価で、リードタイムが長く、消費電力が大きいため、施設のアップグレード（電源、冷却）が必要になることがあります。
アプリケーションサービス
| コンポーネント | 説明 | テクノロジー |
|---|---|---|
| Frontend | ユーザー向け Web アプリケーション | React, TypeScript |
| Frontend Core | AI チャット、ドキュメント、ナレッジグラフ | React 19, TypeScript |
| SWEF | コード生成インターフェース | React, TypeScript |
| Automation | ビジネスロジック、API エンドポイント、バックグラウンドジョブ | Ruby on Rails, GraphQL |
| Ultron | AI チャット補完、コード生成 | NestJS, LangChain |
| Boost | LLM ルーティング、ワークフローオーケストレーション | Python, FastAPI |
| LiteLLM | LLM プロバイダー抽象化 | Python |
インフラストラクチャサービス
| コンポーネント | 説明 |
|---|---|
| Kong Gateway | API ゲートウェイ、SSL ターミネーション、リクエストルーティング |
| Document Converter | ファイル形式変換 |
| HTML Conversion | HTML ドキュメント処理 |
| Playwright | テストとスクリーンショット用のブラウザ自動化 |
| Hasura | データベースアクセス用のリアルタイム GraphQL API |
データストア
すべてのデータストアは Helm チャートにバンドルされており、デフォルトでクラスター内にデプロイされます。本番環境の高可用性デプロイメントでは、マネージドサービスへの外部化を検討してください。| サービス | 用途 |
|---|---|
| PostgreSQL | プライマリリレーショナルデータベース（ユーザー、プロジェクト、権限） |
| PGVector | AI エンベディング用のベクトル類似検索 |
| MongoDB | ドキュメントストレージ（生成コード、デザイン仕様） |
| Redis | キャッシュ、セッション、ジョブキュー |
| RabbitMQ | 非同期メッセージ処理 |
サイジングとスケーリング
デプロイ規模別のリソースサイジング（小規模、中規模、大規模）についてはサイジングガイドを参照してください。スケーリング戦略とオートスケーリング設定についてはスケーリングガイドを参照してください。関連ドキュメント
サイジングガイド
デプロイ規模別のリソースサイジング
スケーリングガイド
スケーリング戦略とオートスケーリング
要件
必須およびオプションのデプロイ要件