クイックスタート

Jitera Self-Hostedをデプロイする最も素早い方法は、コンパニオンTerraformスクリプトを使用することです。クラウドインフラストラクチャ、マネージドデータベース、ストレージ、メール、DNS、Helmチャートのデプロイ、CLI認証まで、ワークフロー全体を自動化します。

このガイドに記載されているパラメータと値は例です。すべてのプレースホルダーの値を実際の構成に置き換えてください。

このクイックスタートはTerraformを使用して評価環境をデプロイします。手動によるステップバイステップのデプロイや本番環境向けのカスタマイズについては、プラットフォーム別のガイドを参照してください：AWS EKSまたはAzure AKS。

スクリプトがプロビジョニングするもの

	AWS EKS	Azure AKS
Kubernetes	EKS（マネージドノードグループ）	AKS（システム + アプリノードプール）
PostgreSQL 14 (Automation)	RDS	Azure Flexible Server
PostgreSQL 16 (PGVector)	RDS	Azure Flexible Server
MongoDB 5.0	DocumentDB	Cosmos DB（サーバーレス）
Redis 6	ElastiCache	Azure Cache for Redis
RabbitMQ	Amazon MQ	クラスター内（Bitnami）
ストレージ	S3 (`ap-northeast-1`)	Azure Blob Storage
メール	SES	Azure Communication Services
DNS	Route 53	Azure DNS
TLS	ACM（ワイルドカード証明書）	cert-manager + Let’s Encrypt
エグレスファイアウォール	AWS Network Firewall（オプション）	Azure Firewall（オプション）
スポット/プリエンプティブ	設定可能（`use_spot_instances`）	設定可能（`use_spot_instances`）

前提条件

Terraform >= 1.5.0
クラウドCLIがインストール・認証済み（aws / az）
kubectl がインストール済み
Jitera Helmチャートzip（Jiteraから提供）
Jitera ACR認証情報（Jiteraから提供）
Azureサブスクリプション（Azure OpenAI用 — AWSのみのデプロイでも必要）

Azure OpenAI — 新規作成または既存を使用

Jiteraには6つのモデルデプロイメントを持つAzure OpenAIインスタンスが必要です。Terraformスクリプトは1つの変数で制御される2つのモードをサポートしています：

新規インスタンスを作成
既存のインスタンスを使用

terraform.tfvars に設定：

create_azure_openai         = true
azure_openai_resource_group = "my-openai-rg"           # 新規作成されます
azure_openai_account_name   = "my-openai"              # 新しいアカウントの名前
azure_openai_location       = "swedencentral"           # gpt-4.1をサポートするリージョン

Terraformは以下を作成します：

新しいリソースグループ
新しいAzure OpenAIアカウント（azure_openai_account_name で指定した名前）
6つのモデルデプロイメント：gpt-4.1、gpt-4.1-mini、gpt-4.1-nano、gpt-4o、gpt-4o-mini、text-embedding-ada-002
ローカルNATゲートウェイIPが自動追加されたネットワークACL（許可IPを除きすべて拒否）

terraform.tfvars に設定：

create_azure_openai         = false
azure_openai_resource_group = "existing-rg-name"        # インスタンスが存在するリソースグループ
azure_openai_account_name   = "existing-openai-account"  # アカウント名

これらの値を確認するには：

az cognitiveservices account list \
  --query "[?kind=='OpenAI'].{name:name, rg:resourceGroup}" -o table

Terraformは既存のアカウントを参照し、そのAPIキーとエンドポイントを使用します — リソースの作成や変更は行いません。

どちらを選ぶべきか？

AWSのみデプロイ — create_azure_openai = true を設定（AWSスタックが作成）
Azureのみデプロイ — create_azure_openai = true を設定（Azureスタックが作成）
AWSとAzureの両方をデプロイ — 最初にデプロイする方で true を設定し、2番目のスタックでは false を設定して最初のスタックが作成したインスタンスを参照
Terraform外で既にプロビジョニング済み — false を設定して既存のアカウント情報を提供

AWS EKSとAzure AKSの両方のスクリプトに同じ変数があり、同じように動作します。全環境で必要なAzure OpenAIインスタンスは1つだけです。

AWS EKS

ステップ 1: 準備

cd aws-eks/
unzip jitera-helm-chart.zip -d ./jitera
cp terraform.tfvars.example terraform.tfvars

ステップ 2: terraform.tfvarsを記入する

必須の値:

変数	取得方法
`aws_region`	ターゲットリージョン（例: `ap-northeast-1`）
`aws_profile`	AWS CLIプロファイル名
`azure_subscription_id`	`az account show --query id -o tsv`
`route53_zone_name` / `app_domain` / `chat_domain`	DNSゾーンとホスト名
`ses_domain` / `sender_email`	SESドメインIDと送信者アドレス
`registry_server` / `registry_username` / `registry_password`	Jiteraから提供
`azure_openai_resource_group`	OpenAI用リソースグループ（新規作成または参照）
`azure_openai_account_name`	OpenAIアカウント名（新規作成または参照）。既存の確認: `az cognitiveservices account list --query "[?kind=='OpenAI'].{name:name, rg:resourceGroup}" -o table`
`jwt_secret`	`pwgen 64 1`
`db_password` / `pgvector_db_password`	`pwgen 24 1`（それぞれ）
`documentdb_password`	`pwgen 24 1`（`/`、`"`、`@` を含まないこと）
`redis_auth_token`	`pwgen 32 1`
`rabbitmq_password`	`pwgen 24 1`

オプションの値:

変数	デフォルト	説明
`create_azure_openai`	`true`	新規OpenAIインスタンスを作成または既存を使用
`use_spot_instances`	`false`	スポット（約70%コスト削減） vs オンデマンド
`use_firewall`	`false`	エグレスフィルタリング用AWS Network Firewall（約$300/月）
`inbound_allow_cidrs`	`[]`	Kong LBアクセス制限用CIDRリスト（空 = 公開）
`extra_ca_cert_path`	`""`	追加CA証明書のパス（例: 企業TLSプロキシ用）

ステップ 3: デプロイ

terraform init
terraform plan    # プランを確認
terraform apply   # 約30-40分

ステップ 4: kubectlの設定

aws eks update-kubeconfig \
  --profile <your-aws-profile> \
  --region $(terraform output -raw aws_region) \
  --name $(terraform output -raw cluster_name)

ステップ 5: 検証

kubectl get pods -n jitera          # すべてRunning
curl -I https://$(terraform output -raw app_url | sed 's|https://||')

ステップ 6: SES本番アクセス

新しいAWSアカウントはSESサンドボックスで開始されます。メールは検証済みのアドレスにのみ送信できます。 テスト/パイロット用: 個別の受信者を検証します:

aws ses verify-email-identity \
  --profile <your-aws-profile> \
  --region $(terraform output -raw aws_region) \
  --email-address <recipient>

本番用: 本番アクセスをリクエストします（承認には通常約24時間かかります）:

aws sesv2 put-account-details \
  --profile <your-aws-profile> \
  --region $(terraform output -raw aws_region) \
  --production-access-enabled \
  --mail-type TRANSACTIONAL \
  --website-url "$(terraform output -raw app_url)" \
  --use-case-description "Jitera Self-Hosted platform emails"

詳細についてはAmazon SESサンドボックスのドキュメントを参照してください。

ステップ 7: CLIアクセス（オプション）

terraform output -raw cli_public_key > public_key.pem
jitera set PRIVATE_API_ENDPOINT=$(terraform output -raw app_url)/automation/private
jitera set STUDIO_URL=$(terraform output -raw app_url)
jitera set ENCRYPTED_PUBLIC_KEY="$(cat public_key.pem)"

Azure AKS

ステップ 1: 準備

cd azure-aks/
unzip jitera-helm-chart.zip -d ./jitera
cp terraform.tfvars.example terraform.tfvars

ステップ 2: terraform.tfvarsを記入する

必須の値:

変数	取得方法
`azure_subscription_id`	`az account show --query id -o tsv`
`dns_zone_name` / `dns_zone_resource_group`	既存のAzure DNSゾーンとそのリソースグループ
`app_domain` / `chat_domain`	アプリとチャットの完全なFQDN
`letsencrypt_email`	チームのメールアドレス
`registry_server` / `registry_username` / `registry_password`	Jiteraから提供
`azure_openai_resource_group`	OpenAI用リソースグループ（新規作成または参照）
`azure_openai_account_name`	OpenAIアカウント名（新規作成または参照）。既存の確認: `az cognitiveservices account list --query "[?kind=='OpenAI'].{name:name, rg:resourceGroup}" -o table`
`jwt_secret`	`pwgen 64 1`
`db_password` / `pgvector_db_password`	`pwgen 24 1`（それぞれ）
`sender_email`	初回apply後に設定 — Azureポータルから MailFrom をコピー（ステップ 7を参照）

オプションの値:

変数	デフォルト	説明
`create_azure_openai`	`false`	新規OpenAIインスタンスを作成または既存を使用
`use_spot_instances`	`false`	スポット（約70%コスト削減） vs 通常VM
`use_firewall`	`false`	エグレスフィルタリング用Azure Firewall（約$900/月）
`inbound_allow_cidrs`	`[]`	Kong LBアクセス制限用CIDRリスト（空 = 公開）
`location`	`japaneast`	Azureリージョン（PG Flexible Serverの利用可能性を確認）
`extra_ca_cert_path`	`""`	追加CA証明書のパス（例: 企業TLSプロキシ用）

ステップ 3: ログインとデプロイ

az login
az account set --subscription "<subscription-id>"
terraform init
terraform plan
terraform apply   # 約30-40分

ステップ 4: 企業プロキシ（該当する場合）

TLSインターセプトを行う企業プロキシ（Netskope、Zscalerなど）を使用している場合、AKS APIサーバーのFQDNをSSLバイパスリストに追加してください:

*.hcp.<region>.azmk8s.io

ステップ 5: kubectlの設定

az aks get-credentials \
  --resource-group $(terraform output -raw resource_group_name) \
  --name $(terraform output -raw cluster_name)

ステップ 6: 検証

kubectl get pods -n jitera          # すべてRunning
curl -I https://$(terraform output -raw app_url | sed 's|https://||')

ステップ 7: メール設定（手動のポータル操作）

Azure Communication Services SMTPでは、terraform apply の後に2つの手動ステップが必要です:

Portal > Communication Services > <cluster>-comm > Email > Domains > Connect domain に移動します
<cluster>-email > AzureManagedDomain > Connect を選択します
ドメインから MailFrom アドレスを確認します（例: DoNotReply@<random-uuid>.azurecomm.net）
terraform.tfvars の sender_email を MailFrom アドレスに更新します
再適用します: terraform apply -target=helm_release.jitera

Azure Communication Services はグローバルリソースタイプです。Azure CLI でデプロイする場合は --location global の指定が必要ですが、azurerm_communication_service Terraform リソースではプロバイダーが内部的に location = "global" を設定するため、location フィールドは公開されていません。ユーザーが設定できるのは data_location（メールデータの格納リージョン。例："United States"、"Europe"、"Asia Pacific"）のみです。

	Azure CLI	Terraform（`azurerm_communication_service`）
デプロイリージョン	`--location global`（必須）	プロバイダーがハードコード — フィールドなし
データレジデンシー	`--data-location "United States"`	`data_location = "United States"`

ステップ 8: CLIアクセス（オプション）

terraform output -raw cli_public_key > public_key.pem
jitera set PRIVATE_API_ENDPOINT=https://<app_domain>/automation/private
jitera set STUDIO_URL=https://<app_domain>
jitera set ENCRYPTED_PUBLIC_KEY="$(cat public_key.pem)"

設定可能なオプション

機能	変数	AWSデフォルト	Azureデフォルト	影響
Azure OpenAI	`create_azure_openai`	`true`	`false`	新規インスタンスの作成または既存の再利用
OpenAIアカウント名	`azure_openai_account_name`	（必須）	（必須）	作成時のリソース名および再利用時のルックアップキーとして使用
OpenAIサブスクリプション	`azure_openai_subscription_id`	`""`	`""`	OpenAIが別のAzureサブスクリプションにある場合のみ設定（同一テナント）
OpenAI許可IP	`azure_openai_allowed_ips`	`[]`	`[]`	OpenAIアクセス用の追加IP。ローカルNATゲートウェイIPは自動追加されます。
スポットインスタンス	`use_spot_instances`	`false`	`false`	`true` = 約70%のコスト削減、エビクションのリスクあり
エグレスファイアウォール	`use_firewall`	`false`	`false`	FQDNアローリストフィルタリング、+$300-900/月
インバウンド制限	`inbound_allow_cidrs`	`[]`	`[]`	Kong LBアクセス用CIDRリスト（空 = 公開）
企業プロキシCA	`extra_ca_cert_path`	`""`	`""`	TLSインターセプトプロキシ用の追加CA証明書パス
ノード数	`node_min` / `node_max`	3 / 4	3 / 4	3ノード = 評価用の最小構成（12 vCPU）
Helmリリース名	`helm_release_name`	`jitera`	`jitera`	すべてのK8sリソース名のプレフィックス
名前空間	`helm_namespace`	`jitera`	`jitera`	すべてのJitera PodのK8s名前空間
GitHub連携	`github_app_name` など	空	空	オプション、GitHub連携を参照

Azure OpenAI ネットワークアクセス

create_azure_openai = true の場合、OpenAIインスタンスは network_acls.default_action = "Deny"（IP許可リストのみ）で作成されます。ローカルクラスターのNATゲートウェイIPは自動的に追加されるため、作成側のスタックがOpenAIにアクセスするための手動設定は不要です。 他のクラスターや開発者からのアクセスを許可するには、azure_openai_allowed_ips にIPを追加します：

# 例：AWSがOpenAIを作成し、Azure AKSもアクセスが必要な場合
azure_openai_allowed_ips = [
  "20.96.49.36",    # Azure AKS NATゲートウェイIP（Azureスタックから: terraform output nat_gateway_ip）
  "106.72.157.66"   # 開発者のノートPC（オプション、テスト用）
]

IPはCIDR表記なしのプレーンなアドレスで指定します（Azure OpenAI ip_rules の形式）。

既知の制限事項

S3リージョンは ap-northeast-1 である必要があります — Jiteraアプリは署名付きURLのリージョンを東京にハードコーディングしています。S3バケットはEKSリージョンに関係なく ap-northeast-1 に作成されます。
CLI_ZIPPER_PRIVATE_KEYの改行 — HelmチャートがPEMの改行を除去します。Terraformは terraform_data.cli_zipper_patch を通じてデプロイ後にシークレットをパッチし、Ultronを自動的に再起動します。
Azureメールにはポータル操作が必要 — ドメインのリンクと送信者アドレスの設定はTerraformで自動化できません（上記のステップ 7を参照）。
Azure SLB + ソース範囲でヘアピンが失敗 — Azureで inbound_allow_cidrs を設定すると、Standard LB のソース範囲フィルタが同一 VNet 内トラフィックの DSR セッション追跡と正しく連携しません。Terraformはクラスター内部から公開 Ingress ドメインを Kong の ClusterIP に解決する CoreDNS リライト（coredns_rewrite.tf）をインストールし、内部トラフィックに対して SLB をバイパスします。外部クライアントには影響しません。
スポット/通常の切り替え — ノードプールの破棄と再作成が発生します（約5-10分のダウンタイム）。
ファイアウォールのオン/オフ切り替え — Azureではクラスターの再作成が必要です（AKSの outbound_type は変更不可）。
Azure PG Flexible Serverのリージョン制限 — 一部のリージョンではプロビジョニングが制限される場合があります。次のコマンドで確認してください: az postgres flexible-server list-skus --location <region>

環境の削除

terraform destroy   # すべてのリソースを削除 — 元に戻せません

terraform destroy はデータベースやストレージを含むすべてのインフラストラクチャを削除します。この操作は元に戻せません。このコマンドを実行する前にデータをバックアップしてください。

AWS EKSインストール

手動によるAWSデプロイのステップバイステップガイド

Azure AKSインストール

手動によるAzureデプロイのステップバイステップガイド

CLI設定

手動によるRSAキーペアの生成とCLIセットアップ

デプロイ要件

クラスター仕様、認証情報、前提条件

リリースノート

クイックスタート

スクリプトがプロビジョニングするもの

前提条件

Azure OpenAI — 新規作成または既存を使用

AWS EKS

ステップ 1: 準備

ステップ 2: terraform.tfvarsを記入する

ステップ 3: デプロイ

ステップ 4: kubectlの設定

ステップ 5: 検証

ステップ 6: SES本番アクセス

ステップ 7: CLIアクセス（オプション）

Azure AKS

ステップ 1: 準備

ステップ 2: terraform.tfvarsを記入する

ステップ 3: ログインとデプロイ

ステップ 4: 企業プロキシ（該当する場合）

ステップ 5: kubectlの設定

ステップ 6: 検証

ステップ 7: メール設定（手動のポータル操作）

ステップ 8: CLIアクセス（オプション）

設定可能なオプション

Azure OpenAI ネットワークアクセス

既知の制限事項

環境の削除

関連ドキュメント

AWS EKSインストール

Azure AKSインストール

CLI設定

デプロイ要件

リリースノート

Documentation Index

​スクリプトがプロビジョニングするもの

​前提条件

​Azure OpenAI — 新規作成または既存を使用

​AWS EKS

​ステップ 1: 準備

​ステップ 2: terraform.tfvarsを記入する

​ステップ 3: デプロイ

​ステップ 4: kubectlの設定

​ステップ 5: 検証

​ステップ 6: SES本番アクセス

​ステップ 7: CLIアクセス（オプション）

​Azure AKS

​ステップ 1: 準備

​ステップ 2: terraform.tfvarsを記入する

​ステップ 3: ログインとデプロイ

​ステップ 4: 企業プロキシ（該当する場合）

​ステップ 5: kubectlの設定

​ステップ 6: 検証

​ステップ 7: メール設定（手動のポータル操作）

​ステップ 8: CLIアクセス（オプション）

​設定可能なオプション

​Azure OpenAI ネットワークアクセス

​既知の制限事項

​環境の削除

​関連ドキュメント

AWS EKSインストール

Azure AKSインストール

CLI設定

デプロイ要件

スクリプトがプロビジョニングするもの

前提条件

Azure OpenAI — 新規作成または既存を使用

AWS EKS

ステップ 1: 準備

ステップ 2: terraform.tfvarsを記入する

ステップ 3: デプロイ

ステップ 4: kubectlの設定

ステップ 5: 検証

ステップ 6: SES本番アクセス

ステップ 7: CLIアクセス（オプション）

Azure AKS

ステップ 1: 準備

ステップ 2: terraform.tfvarsを記入する

ステップ 3: ログインとデプロイ

ステップ 4: 企業プロキシ（該当する場合）

ステップ 5: kubectlの設定

ステップ 6: 検証

ステップ 7: メール設定（手動のポータル操作）

ステップ 8: CLIアクセス（オプション）

設定可能なオプション

Azure OpenAI ネットワークアクセス

既知の制限事項

環境の削除

関連ドキュメント