> ## Documentation Index
> Fetch the complete documentation index at: https://arkor-92aeef0e-eng-615.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Studio

> 学習を開始し、ストリームを眺め、完成したモデルとチャットし、*.arkor.app URL で公開するためのローカル Web UI。

Studio は `arkor dev` 実行時に立ち上がるローカル Web UI です。別途サインインするサービスではありません。ローカルで起動し、同じ Arkor CLI プロセスと通信し、dev サーバーを止めれば消えます。

## Studio の役割

4 つの仕事:

1. **学習を開始する。** "Run training" ボタンが内部で `arkor start` を起動し、ジョブをマネージドバックエンドに投入します。`arkor start` は既存の `.arkor/build/index.mjs` 成果物を実行し（無いときだけ自動ビルド）、Studio が成果物を最新に保つ仕組みは下記の dev ループのメモを参照してください。
2. **学習を眺める。** ライブステータス付きのジョブ一覧、ストリーム到着とともに更新される Loss チャート、学習イベントのテール。タブで開きっぱなしにして他の作業ができます。
3. **完成モデルを試す。** Playground ページでベースモデルや任意の完了済みジョブの最終アダプターを選んでチャットできます。中間チェックポイントは Playground からはロードしません。学習中の推論には [`onCheckpoint`](/ja/concepts/lifecycle) コールバックをトレーナーで使ってください。
4. **`*.arkor.app` URL でモデルを公開する。** Endpoints ページで OpenAI 互換 chat completions を提供する deployment 専用サブドメインを作成し、その API キーを発行・取り消しできます。同じ操作は [`CloudApiClient`](/ja/sdk/deployments) からプログラマティックにも可能で、Studio が対話的なインターフェイス、SDK が下位レイヤーという位置付けです。

dev ループのメモ: Studio は [Rolldown](https://rolldown.rs) のウォッチャを `src/arkor/` 上で常駐させ、再ビルド通知を Server-Sent Events ストリーム (`/api/dev/events`) で SPA に push します。ファイルを編集して保存すれば、Run training ボタンのトレーナー名表示はリロード無しで更新されます。学習が走っている最中であれば、Studio は再ビルドしたバンドルの Cloud 側 `JobConfig` ハッシュを、spawn 時に保存したハッシュと比較します。

* **ハッシュ一致（コールバックのみ変更）。** ランナーへ SIGUSR2 を送ります。ランナーは再ビルドされた成果物を再 import し、内部 HMR ブランド経由でトレーナーのコールバック cell をその場で差し替えます。Cloud 側の学習はそのまま継続し、GPU 時間を無駄にせず、SPA には "Callbacks hot-swapped" と短く表示されます。注意点が 2 つあります。Windows ではその場での差し替えは行われません: Node は POSIX シグナルを強制終了として扱うため、コールバックのみの編集も下記の再起動経路を通ります（短い再起動を挟んで同じ結果になります）。また hot-swap が差し替えるのはコールバック*関数*のみです: コールバックがモジュールスコープから閉じ込んでいる状態（`createTrainer` の隣で作った `AbortController` や、トレーナー自身への参照）は、再ビルドされたモジュール側の新しいインスタンスを指すようになり、実行中の run には効きません。制御用の状態はコールバックの内部に持たせるか、そうした編集は config 変更と同様に run が再起動されるものとして扱ってください。
* **ハッシュ不一致（モデル / データセット / ハイパーパラメータが変わった）。** ランナーへ SIGTERM を送ります。トレーナー内部の early-stop エントリが次のチェックポイントのアップロードを待ってから `cancel()` を発火し、SPA が再ビルドした成果物で再投入します。Cloud 側の以前のジョブはチェックポイントのアップロード完了後に `cancelled` 状態に遷移するので、ここまでの学習成果は artifact として保全されます。ひとつ注意: early-stop の待機時間（約 5 分）内にチェックポイントが来ない場合は即時 `cancel()` にフォールバックするため、チェックポイント間隔が長い run では直近チェックポイント以降の学習分が失われることがあります。

自前のコードから（dev ループではなく）run を早期停止する場合は、公開 API の [`abortSignal` + `cancel()`](/ja/sdk/trainer-control#abortsignal) を組み合わせます。具体的な手順は [Early Stopping レシピ](/ja/cookbook/early-stopping) にあります。ただしこのペアは「いま止める」ための道具です: `abortSignal` はローカルの待機を止め、`cancel()` はバックエンドにジョブ停止を依頼します。dev ループと同じ「次のチェックポイントを待ってから止める」挙動も欲しい場合は、[`onCheckpoint`](/ja/concepts/lifecycle) コールバックと組み合わせ、次のチェックポイントイベントの中から abort + cancel を発火してください。

## Studio が動く場所

`arkor dev` を起動すると CLI は次を行います:

1. Hono サーバーを `127.0.0.1:4000` で起動（ポートは `-p` で変更可能）。
2. 同一オリジンで Vite + React の SPA を提供し、UI はループバックの `/api/*` 経由で CLI と話します。
3. 起動ごとに CSRF トークンを発行し（`~/.arkor/studio-token` にモード `0600` で保存）、すべてのリクエストにこのトークンを要求します。

サーバーはループバックにのみバインドし、ループバック以外の `Host` ヘッダーのリクエストは拒否します。公開 URL もインバウンド接続もなく、トークンは `arkor dev` のたびにローテートされます。共有の開発環境でも学習データが漏れる心配なく安全に Studio を動かせます。

## マネージドバックエンドとの関係

Studio は CLI の動作を可視化するための画面にすぎません。CLI は認証付き HTTPS でマネージドバックエンドと通信し、Studio は CLI に（ループバック越しに）描画する内容を問い合わせます。

```
Studio（ブラウザータブ）
   │  ループバック上の /api/*、CSRF トークン必須
   ▼
arkor CLI（ローカル）
   │  認証付き HTTPS
   ▼
Arkor マネージドバックエンド（学習、推論）
```

この分離があるからこそ、ブラウザー側で何もログインせずに Studio が動きます。CLI は `~/.arkor/credentials.json` ですでに認証情報を持っており、Studio はローカルで動いている前提のもとその認証情報を引き継ぎます。

`~/.arkor/credentials.json` がない場合の処理はエントリーポイントが決めます。**`arkor dev`** は起動時に匿名セッションを初期化し、必要に応じてアップグレードできるよう `arkor login --oauth` を案内する 1 行のヒントを出します。OAuth フローを自動で起動することはありません。例外は初回起動時に `/v1/auth/cli/config` 自体へ到達できないケースで、同じトランスポートエラーが再スローされて `arkor dev` は fail-fast で終了します（具体的な復旧手順は [`arkor dev`](/ja/cli/dev) を参照）。**Studio サーバーの遅延初期化**（認証情報が無い状態で `/api/*` リクエストが届いたとき）も同じ匿名フォールバックを行います。アカウントセッションを使いたい場合は、Studio をクリックする前（あるいは後）に別途 `arkor login --oauth` を実行してください。認証情報ファイルは共有なので、Studio は次のリクエストでアカウントセッションを拾います。

## 実際に見えるもの

現状のビューはあえて小さく保たれています:

* **Jobs。** ステータス、名前、作成時刻、ID。数秒ごとにポーリング。
* **Job 詳細。** Loss チャート、ログのテール（直近のイベント）、ライブステータス。`Server-Sent Events` 経由でストリームされ、手動リロードなしで最新のままです。
* **Playground。** アダプターセレクター（ベースモデル or 任意の完了済みジョブの最終アダプター）、チャット UI、ストリーミングレスポンス。呼び出しは CLI を経由して、その先のマネージド推論エンドポイントに届きます。Playground は完了済みジョブだけを並べます。学習中に中間チェックポイントで推論したい場合は、代わりに [`onCheckpoint`](/ja/concepts/lifecycle) コールバックを使ってください。
* **Endpoints。** アダプターやベースモデルに紐づく deployment 単位の `*.arkor.app` URL と、その API キーを管理するビュー。slug、target（最終アダプター / 特定 checkpoint / ベースモデル）、auth mode、キー発行・revoke が同じ画面に集約されています。深い操作（既存 deployment の target 差し替え、カスタム run retention、バルク操作のスクリプト化）は [SDK](/ja/sdk/deployments) 側に残されています。

各ビュー（Run training、Job 詳細、Playground、Endpoints）のウォークスルーは [Studio](/ja/studio/overview) セクションにあります。

## Studio を使うべきでない場面

Studio は開発ツールです。ローカルで動き、ループバックのみを受け付け、`arkor dev` が立ち上がっている間だけ存在します。ファインチューン済みモデルをプロダクションで使う際は、Studio をユーザーに見せるのではなく、自分のアプリケーションコード（あるいは推論層）から `infer` を呼んでください。