InfiniCloud AIのインストール

このドキュメントでは、InfiniCloud AI（Shiraito）を1台のサーバーに導入する手順を説明します。

各ステップの「確認」では、手順が正しく実行できているかを確認する方法を説明しています。エラーが発生した場合や、手順どおりに進まない場合は、「困ったときは」を参照してください。

• インストールの用意
• STEP 1. インストーラーを取得して配置する
• STEP 2. ドライバやミドルウェアのインストール（Docker など）
• STEP 3. 初期化する
• STEP 4. 環境設定
• STEP 5. 点検する（doctor）
• STEP 6. アプリを取得する（set-key・pull-app）
• STEP 7. モデルを取得する（list-models/pull-models）
• STEP 8. ビルドする（build）
• STEP 9. 起動する（up）

インストールの用意

• Ubuntu などの Linux サーバー（22.04 / 24.04 を推奨）と、そのroot権限
• インターネット接続
• ローカルで推論する場合は NVIDIA GPU 搭載機（AMD GPU は現在未対応）。生成 LLM を外部 MaaS に出す maas プロファイルは、ローカル GPU なしで利用できます。
• ディスクの空き容量は選ぶプロファイルとモデルによって変わります。最小構成でも 50GB 以上を用意し、27B / 120B モデルを使う構成は配布元に必要容量を確認してください。

STEP 1. インストーラーを取得して配置する

次の 1 行で、運用コマンド shiraitoctl がサーバーに入ります。

wget -O - -q https://ai-shiraito.dist.infinicloud.com/install.sh | sudo bash

確認

shiraitoctl is ready. と表示されれば成功です。

STEP 2. ドライバやミドルウェアのインストール（Docker など）

Shiraito は Docker 上で動きます。GPU を使うなら NVIDIA ドライバと Container Toolkit も必要です。これらは shiraitoctl setup-host に自動インストールさせることができます。

プロファイルの選択

プロファイルは、GPU だけでなく、使用するモデル、推論ランタイム、FineTune の可否をまとめて初期設定するものです。1 台につき 1 つを選び、STEP 2の setup-host とSTEP 3の init に同じ名前を指定します。

プロファイル一覧

インストール済みの profile を分類して確認するには、次を実行します。

sudo shiraitoctl profiles

新規導入では、VRAM容量に合わせて次のプロファイルから選びます。利用するモデルと対応アプリは、STEP 7と配布元の案内も確認してください。

この構成は、後で選ぶことができます。

96GB / 192GB 級では、-ft なしが推論容量優先、-ft 付きが FineTune用のGPUメモリを確保する構成です。24GB/48GB 級はメモリ容量上、FineTuneに対応しません。

• ft 付きのプロファイル（と、次に挙げる互換用の nvidia-* プロファイル）は config.ini に [finetune] enabled = true を持ち、アプリケーションは初回起動時に1度だけこれを読んで、default プールにLoRA（FineTuneの成果物）を載せる容量を宣言します。既存環境には影響しません。

nvidia-default、nvidia-h100、nvidia-rtx-pro6000 も既存環境との互換用に同梱しています。既存環境は、配布元から変更を案内されるまで、従来のプロファイルを継続してください。amd-rocm は将来対応用のプレースホルダーで、現在は選択できません。

なお、これらのプロファイルの実体は /opt/JPC/shiraito/profiles 以下にあります。setup-host と init には、同じprofile名をそれぞれ明示してください。setup-host で指定したprofileは、後続の init へ自動的には引き継がれません。

自動インストール

# まず何をするか確認（ドライラン。実際には変更しません）
sudo shiraitoctl setup-host --profile vram-96gb

# 問題なければ実行（--yes を付ける）
sudo shiraitoctl setup-host --profile vram-96gb --yes

• --profile は STEP 3と同じ名前を指定します（上の表を参照）。
• GPU ドライバを新しく入れた場合は再起動を求められます。
  • GPUドライバが新しく入った場合のみ再起動して、もう一度同じコマンドを実行すれば続きを行います（何回実行しても安全です）。

sudo reboot

# 再起動後にもう一度:
sudo shiraitoctl setup-host --profile vram-96gb --yes

STEP 3. 初期化する

推論ランタイム設定の初期化をします。推論は、Dockerで動作する shiraito_llm_sm が管理するvLLMです。

# 例: VRAM 80〜96GB 級の NVIDIA GPU の場合
sudo shiraitoctl init --profile vram-96gb

確認

実行すると、最後に「Next steps」が表示されます。STEP 7の表と合わせて、取得するモデルを確認してください。

STEP 4. 環境設定

4-1. 公開ドメイン

公開運用（https）をする場合は、ドメインなどを設定します。

sudo nano /opt/JPC/shiraito/.env

必要な項目を自分の環境に合わせて書き換えます。

• SITE_HOST
  • 公開するドメイン名（例 shiraito.example.com ）。このドメインがインターネットからこのサーバーに向いている必要があります（Let's Encrypt 証明書のため）。
• ACME_EMAIL
  • 証明書通知用のメールアドレス。lan 運用では証明書には使いません。 INITIAL_ADMIN_EMAIL が空なら、初期管理者のメールアドレスの候補にもなります（4-3）。候補は、そのアドレスに届いたコードで確かめるまで使われません。

POSTGRES_PASSWORD と POSTGRES_APP_PASSWORD は init が強いランダム値を自動生成します。初回起動後に変更するとDBに接続できなくなるため、通常は編集しません。古いインストーラから引き継いだ .env に changeme が残っている場合だけ、初回起動前に強い値へ変更してください。

4-2. メール送信（SMTP）

Shiraito は、ログインコード（MFA）・ユーザー招待・パスワード再設定をメールで送ります。SMTP は同じ .env に設定します。この方法は shiraito-app 1.2.7 以降で利用できます。

.env の #SMTP_... で始まるコメント例を、利用するメールサーバーの値で次のように置き換えます。以下は 465番ポート（暗黙TLS）の例です。

SMTP_HOST=smtp.yourprovider.com
SMTP_PORT=465
SMTP_USERNAME=your-account@yourprovider.com
SMTP_PASSWORD='your-smtp-password'
SMTP_USE_TLS=false
SMTP_USE_SSL=true
SMTP_FROM=noreply@yourdomain.com

既存環境の var/config.ini に [email] がある場合は、未設定の SMTP_*  項目だけがそこへフォールバックします。新規導入では設定場所を .env に揃えてください。

4-3. 初期管理者（shiraito-app 2.1.26 以降）

アプリを起動したときに利用者が1人もいなければ、.env の次の値から管理者を 1 人作ります。利用者が 1 人以上いれば読まれないので、既存の環境は変わりません。

• パスワードの確認
  • init は画面に出しません。次で確認します。

sudo grep '^INITIAL_ADMIN_PASSWORD=' /opt/JPC/shiraito/.env

• アプリへの渡し方
  • up が起動の前に、この値を var/secrets/initial_admin_password（root だけが読める）に写し、アプリにはファイルで渡します。コンテナの環境変数には入りません。.env から行を消すと、次の up で写しも消えます。 var/secrets は up が作ったディレクトリのまま使います。var/ はコンテナから書き込めるため、var/secrets が symlink のときや、up を実行する利用者以外の持ち物のときは、 up は写さずにエラーで止まります（行が無いときは、写しを消さずに警告だけ出します）。
• 手で書く場合
  • 値は単引用符で囲みます（ INITIAL_ADMIN_PASSWORD='...' ）。中の $ や # も書いたとおりに使われます。値の中に単引用符は書けません。.env はdocker composeも読むため、囲まない値や二重引用符の中に閉じていない ${ があったり、引用符を閉じていなかったりすると、compose が .env を読めず up が止まります。値の前後の空白はアプリが落とします。

• メールアドレスの候補
  • そのアドレスに届いたコードで確かめるまで、パスワードの再設定にもMFAにも使われません。MFA を強制していなければ、ログイン後にアカウント設定で確かめます。強制していれば、初回ログインの認証コードが候補に届き、通ると確定します。

• MFA を強制したまま導入する場合
  • 初回の up の前に、SMTP（4-2）と、管理者の本物のメールアドレス（ INITIAL_ADMIN_EMAIL ）を .env に書きます。候補が無い・仮の値の場合や、SMTPが未設定の場合は、管理者は作られません（backendのログにERRORが出ます）。

• 初期管理者ができるまで、LDAP・OIDCを有効にしないでください。
  • 誰かが先にログインすると利用者が1人以上になり、初期管理者は作られなくなります。

4-4. MFA（多要素認証）を強制するか（ shiraito-app 2.1.26 以降）

ログインで認証コード（MFA）を求めるかは、var/config.ini の [security] require_mfa で決まります。true は強制する、false は強制しない、です。キーが無ければ、アプリの既定で強制します。require_mfa は .env には書きません（このインストーラの構成では、.env に書いてもbackendに渡らず、効きません。SMTP の設定（4-2）は .env のままです）。

今の値は次で確かめます。何も表示されなければキーが無い（強制する）状態です。

sudo grep -n 'require_mfa' /opt/JPC/shiraito/var/config.ini

• 新規導入
  • `init` が `require_mfa = false` を書くので、強制しません。SMTP（4-2）が無くても、初期管理者（4-3）はパスワードだけでログインできます。
• 強制しないで始めたいのに true になっている・キーが無い場合
  （以前のインストーラで初期化した環境、init --force で作り直した環境など）
  • var/config.ini の [security] の節に require_mfa = false と書きます。[security] の節が無ければ、ファイルの末尾に次の2行を足します。同じ節を2つ作ると、アプリが起動しません。
  • 値は true か false で書きます。綴りを間違えるとアプリが起動しないので、書いた後は sudo shiraitoctl doctor（STEP 5）で require_mfa についての警告が出ないことを確かめます。初回の up（STEP 9）より前に書いた場合は、その up で反映されます。すでに起動している環境（既存の環境の更新など）で書き換えた場合は、sudo shiraitoctl restart で反映します（lan の場合は --env lan を付けます）。

[security]
require_mfa = false

• 強制に切り替える
  • SMTP を設定し、管理画面「設定 > 認証設定」のメール送信テストで届くことを 確かめてから、「設定 > セキュリティ設定」の「多要素認証」で切り替えます。管理画面で一度保存すると、以後はその値が `var/config.ini` より優先されます（`var/config.ini` を書き換えても効きません）。

• 強制したまま SMTP が使えなくなり、ログインできないとき: アプリの文書
  • /opt/JPC/shiraito/app/docs/sysadmin/sys_serveradmin-security.ja.md の節「多要素認証の強制（セキュリティ設定）」にある項目「締め出されたときの戻し方」に沿って戻します。

STEP 5. 点検する（doctor）

ここで一度、前提が揃っているか確認します。build の前に必ず実行してください。

sudo shiraitoctl doctor

確認

doctor: all required checks passed. と出れば、ホストの前提条件は OK です。不足があると → で入れるべきコマンドが出るので、それを実行して（またはSTEP 2の setup-host をやり直して）から doctor をもう一度流します。（ docker-compose.yml not installed yet・app not installed・no key is registered の警告はSTEP 6 の後で消えるので、今は無視可。）

doctor は、導入の後も、アプリの更新の後や困ったときに流せます。failed: は失敗の扱いで、最後に some required checks failed と出ます。warn: と info: は知らせるだけです。鍵（6-1）はアプリの取得（ pull-app ）にだけ使い、up・build・起動時の自動起動は鍵を読みません。そのため、鍵が無い・期限が切れたことは warn: で、動いているサービスは止まりません。doctorは何も消しません。

STEP 6. アプリを取得する（set-key・pull-app）

6-1. ライセンスを登録する（set-key）

配布元から受け取ったライセンスを、pull-app の前に登録します。ライセンスは、このサーバーが取得できるアプリのエディション（ES・EC・CE）を決めます。ライセンスは次のファイルです。

• 発行元証明ファイル（例：jpc-client.pfx ）

sudo shiraitoctl set-key jpc-client.pfx
sudo shiraitoctl key-info

set-key は、証明書が installer に同梱の CA（/opt/JPC/shiraito/share/ca/）から発行されたこと、有効期間の内にあること、CNの形を確かめてから、/opt/JPC/shiraito/license/ に置きます（root だけが読めます）。エディションは使うたびに証明書のCNから読み取り、ほかの場所には保存しません。

• CA:TRUE と出て止まったときは、CAの証明書だけを渡しています。クライアント証明書と秘密鍵を配布元に求めてください。
• correct the clock と出て止まったときは、サーバーの時計を合わせてからやり直します。
• 別のエディションのライセンスに入れ替えるには --force が要ります。ライセンスを入れ替えても、入っているアプリのエディションは変わりません。
• 見本のライセンス（CN に example@infinicloud.com を含むもの）は試験用です。本番では、そのサイト用に発行されたライセンスを登録します。

確認

• key-info の最後に key-info: the key passes every check. と出れば成功です。
• days left は期限までの残りの日数です。期限が来る前に新しいライセンスを受け取り、同じ set-key で入れ替えます。

6-2. アプリを取得する（pull-app）

sudo shiraitoctl pull-app

pull-app は、6-1で登録したライセンスを使って配布サーバーからアプリを取得します。取得の前にライセンスを手元で確かめ（無い・期限切れ・有効期間の前なら、何も送らずに止まります）、ライセンスのエディションで取得先を決めます。ライセンスを出すタイミングはアプリの取得だけで、モデルの取得（ pull-models ）には使いません。

バージョンを指定しなければ、既定ではstableラインの最新版が入ります。

stableは通常の更新ラインです。hardenは、stableの中から追加確認済みの版だけを選んだ慎重な更新ラインです。同じappパッケージを使い、harden用の別ビルドではありません。

保存した選択は /opt/JPC/shiraito/.env.shiraitoctl に記録されます。app設定を持つ .env とは別ファイルです。installerを更新しても既存の選択は上書きされません。

harden対象版がまだない場合や、配信サーバーがhardenに対応していない場合、stableへ自動的に切り替えずエラーで停止します。必要なら --stable を明示してください。

特定バージョンの指定はチャネル設定を参照しません。hardenを既定にしている場合や、チャネル設定ファイルに問題がある場合でも、次の形でロールバックできます。

sudo shiraitoctl pull-app 2.1.20

確認

installed shiraito-app <version> と出れば成功です。

止まったときは、出力の ERROR: の行とその次の行で原因が分かります。どの場合も、ライセンスを使わない取得や別の取得先へのやり直しはせず、何も入れずに止まります。

SHIRAITO_PACKAGES_URL で取得先を変えられますが、配布サーバー以外のホストには鍵を出しません。

STEP 7. モデルを取得する（list-models/pull-models）

プロファイルが使うローカルモデルをすべて取得します。モデルは容量が大きく、取得に時間がかかります。埋め込みモデル intfloat/multilingual-e5-base も必須です。

既存環境との互換用 profile では、nvidia-default は vram-24gb 相当、nvidia-h100 / nvidia-rtx-pro6000 は vram-96gb-ft 相当のモデルを取得します。新規導入では上の vram-* profile を選んでください。

配布可能なモデルと取得済みのモデルは、次のコマンドで確認できます。出力の [*] は取得済み、[ ] は未取得を表します。

sudo shiraitoctl list-models

例として `vram-96gb` のモデルを取得する場合:

sudo shiraitoctl pull-models Qwen/Qwen3.6-27B-FP8 openai/gpt-oss-20b intfloat/multilingual-e5-base

確認

installed model: ... と出れば成功です。

Web UI のモデル設定から別のLLMを選ぶ場合は、そのモデルも事前に取得してください。

STEP 8. ビルドする（build）

sudo shiraitoctl build               # 公開運用(prod)
# 社内・閉域(lan)の場合: sudo shiraitoctl --env lan build

20〜40 分ほどかかります。完了するまでそのまま待ってください。

STEP 9. 起動する（up）

公開運用（https）の場合:

sudo shiraitoctl up

社内・閉域網で HTTP 運用する場合:

sudo shiraitoctl --env lan up

状態を見たいとき

状態を見るには

sudo shiraitoctl status

ログは下記の通りです。

sudo shiraitoctl logs

ブラウザで https://<SITE_HOST>（lan の場合は http://<サーバーのIP> ）にアクセスし、画面が開けば導入完了です。続けて、初期管理者でログインします（4-3）。

HTTP ではブラウザの JavaScript セキュリティ制限により、クリップボード操作などの一部機能が使えない場合があります。

ログインしたら、次を行います。

1. パスワードを変更します。
2. .env から INITIAL_ADMIN_PASSWORD の行を消し、sudo shiraitoctl up を実行します（lan の場合は `--env lan` を付けます）。 var/secrets の写しも消えます。
3. sudo shiraitoctl doctor で、初期管理者のパスワードについての警告が消えたことを確かめます。