連載「Tines 3B を読み解く」の第9回です。
はじめに
「データは自社の環境に置きたい」。業務システムの選定でよく出る要件です。AI ネイティブのワークフロー基盤「Tines 3B」には、Tines が運用する SaaS のほかに、自社の Kubernetes で動かすセルフホストがあります。
この記事では、セルフホストを選ぶと何が前提になり、何が自分たちの責任になるのかを、公式ドキュメントに沿って整理します。
こんな方に向けて書いています。
- SaaS とセルフホストのどちらを選ぶか検討している
- 導入の前に、インフラの前提と運用の負担を見積もりたい
- 「セルフホストなら安心」の中身を確かめたい
先に結論です。セルフホストの前提は具体的で、導入前に試せます。ただし、クラスタ、ロードバランサー、DB、バックアップ、監視、更新はすべて利用者の責任になります。Tines は監視のダッシュボードもアラートも提供しません。
実行の隔離の仕組みは第2回、シークレットと暗号鍵は第3回、料金の体系は第10回で扱っています。
こんな場面、ありませんか
セルフホストを検討すると、こんな場面が出てきます。
- 「Kubernetes に入れるだけ」と聞いたが、ノードの条件で起動しないことがあると知った。
- SaaS より安く済むと思っていたが、運用の人件費を見積もりに入れていなかった。
- バックアップは取っているが、暗号鍵まで含めた復元は試したことがない。
共通するのは、「動かす」ことと「運用し続ける」ことが別の仕事だという点です。
結論:3つの要点
| 要点 | 内容 | 見落とすと |
|---|---|---|
| 前提を先に試す | x86_64、ユーザー名前空間、PostgreSQL 18、ホスト名2つ | 導入の途中で Pod が起動しない |
| 評価と本番を分ける | 評価は単一サーバー、本番は Kubernetes と Helm | 評価用の構成を本番に使ってしまう |
| 運用を自分で持つ | 監視、バックアップ、暗号鍵、更新 | 障害や鍵の紛失で復旧できない |
要点1:前提を先に試す
構成要素と通信の流れ
通信の流れを図にしました。
入口の nginx はチャートに内蔵されているため Ingress コントローラーは不要で、前段にロードバランサーが1つあれば足ります。
4つの前提
| 前提 | 内容 |
|---|---|
| CPU | amd64(x86_64)のみ。Graviton や Ampere などの Arm は動かない |
| ノード | ユーザー名前空間が使えること(containerd 2.x、新しめのカーネル、user.max_user_namespaces が0以外) |
| DB | PostgreSQL 18。wal_level=logical(リアルタイム同期の Zero sync が必要とする) |
| ホスト名 | 2つ(app と public)。public は app と別のホスト名にする。DNS は必須で、IP とポートだけの構成は不可 |
ユーザー名前空間が要るのは、ステップのコードを gVisor のサンドボックスで隔離するからです(第2回)。導入で最も詰まりやすい点ですが、本番の手順の中に導入前の確認(ノード互換テスト)が用意されています。hostUsers: false のテスト用 Pod が起動し、uid_map が恒等でないことを確かめます。
クラウドごとの落とし穴
各クラウドのガイドは「2026年8月時点」の記述で、クラウド側の既定は変わり得ます。
| 環境 | 注意点 |
|---|---|
| AWS EKS | Auto Mode のノードは、ユーザー名前空間の上限が0に強化されており、api と worker が起動しない。既定の StorageClass も無い |
| GCP GKE | Standard を使う。Autopilot は hostUsers: false の Pod を許可せず、回避策は無い |
| Oracle OKE | Enhanced クラスタと管理ノードプールを使う(仮想ノードは不可)。Oracle Linux 8 の x86_64、Kubernetes 1.33 以上 |
もう1つ、全クラウドに共通するのがロードバランサーのタイムアウトです。3B の UI は、リアルタイム同期のために長い WebSocket を保ちます。タイムアウトが短いままだと、「画面は開くが、更新が止まる」状態になります。AWS の ALB(既定60秒)と GCP(既定30秒)のどちらも、大きく延ばす必要があります。
要点2:評価と本番を分ける
| 方式 | 用途 | 特徴 |
|---|---|---|
| 単一サーバー(k3s) | 評価(PoV、PoC) | 1台で動く。冗長性は無く、落ちれば 3B も止まる |
| エアギャップ(単一サーバー) | インターネットに出られないサーバー | 接続できる機械で、全イメージ入りのバンドルを作って持ち込む |
| Kubernetes と Helm | 本番 | サービスごとにスケールできる |
導入に先立って、まず営業窓口(アカウントエグゼクティブか、カスタマーサクセスマネージャー)へ連絡します。そのあと Tines の技術担当が、レジストリへのアクセスと導入を支援します。入手するのは、レジストリの資格情報、リリースのバージョン、署名付きのライセンストークンです。ソフトウェアの入手元は oci.tines.com だけです。
サイジング
出発点の値です。上限ではなく、監視しながら調整する値とされています。
| 構成 | vCPU | メモリ | SSD |
|---|---|---|---|
| 単一サーバー: 動作確認 | 8 | 16 GB | 250 GB |
| 単一サーバー: 推奨の PoC | 8 | 32 GB | 500 GB |
| 単一サーバー: 重い PoC | 16 | 64 GB | 500 GB から 1 TB |
| Helm: クラスタ | 8 vCPU 以上 | 32 GB 以上 | ノードは 4 vCPU / 16 GB 以上 |
Helm の既定(全サービス1レプリカ)では、リクエストの合計が約 5.5 vCPU と 12 GiB です。クラスタ内の PostgreSQL と nginx はリクエストを持たず、サンドボックスは最大 4 GiB までメモリが伸びるので、余裕を持たせる必要があります。永続ボリュームの既定は、PostgreSQL が 10 GiB、blobstore が 50 GiB です。
本番の DB は、管理型(例として AWS RDS)が推奨されています。高可用性が要るなら、外部の PostgreSQL を使います。
ステップごとの資源制限は既定で無効
公平に書いておきたい点です。ステップごとの CPU とメモリの制限(1 vCPU、2 GiB の cgroup v2)は既定で無効で、そのあいだはステップ単位の制限なしで動きます。公式では、ワーカーを増やすときに有効化することが勧められています。有効にするには、書き込み可能な cgroup を持つ containerd のハンドラーをすべてのワーカーノードに用意し、sandboxd.runtimeClassName を合わせます。重いステップが同じノードの他のステップを圧迫する可能性があるため、導入時に決めておくのがよいでしょう。
要点3:運用を自分で持つ
責任の分担
公式では、セルフホストは「利用者が運用するもの」と明記されています。クラスタ、ロードバランサー、TLS 証明書、DNS、バックアップ、監視とアラートは、利用者が自分たちの基準で用意します。
| 領域 | Tines | 利用者 |
|---|---|---|
| ソフトウェア | チャート、イメージ、リリースノート、ライセンス | 取得と、更新の適用 |
| 導入の支援 | 技術担当による支援 | 情報の用意 |
| クラスタ、ノード | 要件の文書化 | 構築、運用、正しい動作 |
| LB、TLS、DNS | 要件の文書化 | 設計、運用 |
| DB、ストレージ | 要件の文書化 | 運用、高可用性、容量 |
| バックアップ | 単一サーバーの手順 | 実施、保管、復元の試験 |
| 監視 | しきい値の推奨 | 基盤、通知、対応 |
この表は筆者の整理です。公式に、責任共有モデルの記事は見当たりません。
監視
Tines は、ダッシュボード、アラート、メトリクス基盤を提供しません。利用者が Prometheus や Datadog などで、しきい値を設けます。出発点として、Pod の CPU が要求の約80%超を10分、メモリが上限の約80%超を15分、ボリュームの使用率が60%、などが示されています。
バックアップと暗号鍵
単一サーバーには、自動のバックアップがありません。次の3つは、サーバーの外に置く必要があります。
-
/opt/3b/.env(設定と暗号鍵) - PostgreSQL のダンプ
- ファイルのボリューム
とくに重要なのは1つ目です。この鍵が無いと、データベースが残っていても保存済みの認証情報を復号できません。パスワード保管庫と同じ扱いにする、というのが公式の表現です。Helm 環境では、更新前の DB のバックアップとボリュームのスナップショットの推奨はありますが、復元の手順は見当たりません。
更新
Helm では、同じ設定ファイルで新しい版を指定してアップグレードします。アプリケーションのシークレットは保持され、鍵は回転しません。v2 から v3 への更新では Blobstore の移行方式(fresh か retain)を選ぶ必要があり、どちらも旧ワークロードを止める1回の保守時間が要ります。本番は事前に Tines へ連絡する必要があります。
テレメトリ
v3.1.0 以降、3B は起動時と12時間ごとに、小さなレポートを Tines へ送ります。送る項目は4つです。
- ライセンス ID(ある場合)
- 当月の Tines units の使用量
- 3B のバージョン
- PostgreSQL のバージョン
ライセンストークン、ワークフローの内容と設定、認証情報、実行データ、ログ、ユーザーの氏名とメールは送らない、と公式では書かれています。送信の失敗はログに残るだけです。ただし、無効化の方法は確認できていません。
守ってくれないこと
- ネットワークの出口: 宛先に一致しない通信は、公開インターネットへ出ます。出口を絞るなら、利用者側のプロキシで制御します。
-
内部宛の許可: 社内への到達は
ALLOWED_CIDR_BLOCKSで許可します。ただし広い範囲を書くと、インスタンスの資格情報がワークフローのコードに見える危険があります(公式の注意)。最小の範囲にします。 -
STACK_NAMEの変更: 初回の起動後は変えません。 - AI プロバイダへの到達: 3B は HTTPS で到達できることが前提で、AI プロバイダへの外向き通信が要ります。エアギャップ環境での AI の構成は、記事にありません。
他のやり方との違い
提供形態を、一般的な分類で比べます(特定の製品の仕様ではなく、考え方の整理です)。
| 観点 | SaaS | セルフホスト | ハイブリッド(SaaS と、社内側の出口ノード) |
|---|---|---|---|
| 運用の負担 | 小さい | 大きい | 小さい(出口ノードは利用者) |
| データの所在 | 提供者の環境 | 自社の環境 | SaaS 側 |
| 立ち上げ | 速い | 前提の確認が先 | 速い |
| 向く場面 | 運用人員が少ない | データを自社に置く要件と、運用体制がある | 社内システムへ届きたいだけ |
社内システムへ届きたいだけなら、SaaS と Tunnel(社内側で出口ノードを動かす方式)で足りる場合があります。Tunnel はデプロイメントごとに有効化が必要です。
おわりに
- 前提(x86_64、ユーザー名前空間、PostgreSQL 18、ホスト名2つ)は具体的で、導入前に試せる。
- 評価は単一サーバー、本番は Kubernetes と Helm。評価の構成を本番に使わない。
- 監視、バックアップ、暗号鍵、更新は利用者の責任。
「自社に置く」ことは、「自社で守る」ことを含みます。
連載の他の回
連載「Tines 3B を読み解く」(全11回):
- 第1回 AIが作るコードの乱立に、どう備えるか。Tines 3B の全体像と5つの強みを読み解く
- 第2回 AIが書いたコードを、動かして大丈夫か。Tines 3B の実行とネットワークの分離を読み解く
- 第3回 AIエージェントに、APIキーを渡さない。Tines 3B の認証情報の設計を読み解く
- 第4回 AIに、誰の権限で何をさせるか。Tines 3B の権限とガードレールを読み解く
- 第5回 「誰が何をしたか」と「いくらかかったか」を、どう見るか。Tines 3B の監視・監査・費用を読み解く
- 第6回 AI にチャットで作らせても、実体はコード。Tines 3B の「コードファースト」を読み解く
- 第7回 本番を壊さずに直す。Tines 3B のドラフトと本番、自己修復(Autofix、Autotune)を読み解く
- 第8回 「ベンダーに縛られない」は、どこまで本当か。Tines 3B の接続口と、持ち出せる範囲を読み解く
- 第9回 自社環境で動かすなら、何を引き受けるか。Tines 3B のセルフホストを読み解く(この記事)
- 第10回 契約の前に、何を書面で確かめるか。Tines 3B の導入・契約・費用を読み解く
- 第11回 Tines 3B か、他の製品か。8つの軸で見分ける
参考
公式ドキュメント(docs.3b.tines.com)。Tines 3B Self Hosted の各記事:
- Before you begin / Accessing the OCI registry
- System overview / Connectivity requirements / Sizing / Deployment telemetry
- Prerequisites / Installation guide / Air-gapped installation / Installing 3B with Helm / Operating the single-server install
- AWS EKS / GCP GKE / Oracle OKE
- Applying a license / Environment variable reference / TLS termination
- What to monitor / How and when to scale
- Upgrading on Kubernetes (Helm) / Upgrading from v2 to v3
補助: Tines 3B pricing and packaging overview / Reach a private network through a secure tunnel / Connect your AI provider