クイックスタート
Organization を作り、agent version を公開し、最初の session を動かすまで — ターミナルと 1 回の HTTP 呼び出しで、最初から最後まで。
ここでの作業はすべてターミナルで行います。読み終えるころには、organization、workspace、公開済みの agent version、API key、そしてメッセージに応答する session が手元にあるはずです。
CLI をインストールする
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/subako-ai/subako-cli/releases/latest/download/subako-cli-installer.sh | shインストーラは、$XDG_BIN_HOME が設定されていればそこに、なければ ~/.local/bin に subako を配置します。確認してみましょう。
subako --version
Organization を用意する
サインアップする
Organization は請求とアイデンティティの境界です。作成時は Free plan から始まり、試用のための 500 SC が付与されます — 有料 plan で何が増えるか、どう申し込むかは Plan と請求 を参照してください。
subako cloud signup --org acme --name "Acme, Inc."--org は organization の handle です。これが organization
を識別するものであり、重複は許されず、URL にも現れ、organization
が存在する限り変更できません。サインインの際に指定する名前でもあり —
次のステップの subako login --org acme も、それ以降のログインもすべて
そうです — ずっと使い続けられるものを選んでください。--name
は表示名にすぎず、こちらはいつでも変更できます。
このコマンドはローカルには何も保存しません。Organization が置かれる
Core サーバー — 別のものを指定していなければ
https://api.us.cloud.subako.ai — が表示され、次のステップではそこに
サインインします。
サインインする
サインインは OAuth のデバイス認可フローで行われます。CLI
がコードを表示してブラウザを開き、承認すると credential が
~/.config/subako/credentials.json に保存されます。
subako login --org acme--profile を使うと、organization の handle
とは別の名前でログインを保存できます — 複数の organization
や、ステージングと本番のログインを並べて持つ方法です。--server
は、既定の https://api.us.cloud.subako.ai 以外の Core
サーバーにログインを向けます。保存された各 profile
がどのサーバーに紐づいているかは subako profile list が表示します。
subako whoamiworkspace を作る
あらゆる作業単位は workspace に属します — agent、skill、vault、API
key、そしてそれらが動かす session です。use
は選択内容を profile に記録するので、以降のコマンドに --workspace
フラグは要りません。
subako workspace create --name production
subako workspace use production
subako workspace listAgent を公開する
model provider を選ぶ
Subako はあなたに代わってモデルを呼び出すため、version は provider を指定して公開します。どの workspace も最初から platform provider が見えています — こちらで設定済みで、あなた自身のキーは不要なので、まず はここから始めてください。
subako model-provider listworkspace: production (01a0877c-03d9-7823-b997-f42147b8b607)
01a07f90-238c-7de3-b55e-6fe53de063cf type=platform format=openai_responses label=Subako description=(none)
model=crow label=Crow
model=hawk label=Hawk
model=sparrow label=Sparrow自前のものを何も作っていない workspace には、ちょうどこれだけが見えます — Subako の platform provider と、それが提供する 3 つのモデルです。クイックスタートを終えるにはこれで十分で、自分で作った provider はこの横に並びます。
この一覧から 2 つを控えておいてください。公開先となる provider の id と、その下にインデントされている モデル id のいずれかです。provider がどのモデル id を受け付けるかは、この一覧が正解です。
自分のアカウントで動かしたい場合は、自前の provider を作成します。キーはフラグではなく必ず標準入力から読まれるので、シェルの 履歴にもプロセス一覧にも残りません。
subako model-provider create \
--format anthropic \
--display-name "Anthropic production" \
--base-url https://api.anthropic.com < key.txtsubako model-provider formats は、このサーバーが受け付ける format
を一覧します。Agent version は、その model が話す format と一致する
format の provider に対してのみ公開できます。
agent を作る
Agent は名前とアイデンティティにすぎません。設定そのものは持たず — それを持つのは version です。
subako agent create --name support-triageAgent id が表示されます。これが agent publish
に渡す引数です。あとから見直すには subako agent list を使います。
version の設定ファイルを書く
agent config-example は、そのままで公開できる最小の設定を表示します。
サーバーを必要としないので、ほかに何も存在しないうちから編集を始められます。
例は format ごとに異なるので、選んだ provider の format を渡してください。
subako agent config-example --format openai_responses > agent.json{
"system_prompt": "You are a helpful assistant.",
"model": {
"format": "openai_responses",
"model": "your-model-id",
"max_tokens": 8192,
"context_window": 128000
}
}your-model-id を、provider の一覧にあるモデル id — たとえば hawk —
に置き換えます。id は公開時ではなく session
の実行時に検証されるので、本物をここに書いてください。
Grant — MCP サーバーと skill — は任意で、同じドキュメントに書きます。
provider はファイルではなく、公開時の --model-provider で指定します。
公開する
subako agent publish <agent-id> \
--config agent.json \
--model-provider <provider-id>Version はイミュータブルです。もう一度公開すると新しい version が作られ、新しい session は最新の live version に束縛されます。すでに動いている session は、束縛済みの version のままです。
Session を動かす
ここから先は HTTP で、サインインしたのと同じ Core サーバーに対して行います —
以下の呼び出しでは既定の https://api.us.cloud.subako.ai です。別のサーバーに
サインインした場合は、各 profile がどのサーバーに紐づいているかを
subako profile list が表示します。
API key を発行する
API key は、あなたのプロダクトが名乗るマシン用の credential です。そのシークレットは一度だけ表示され、二度と取得できません。
subako api-key mint \
--label "support-triage backend" \
--permission session.create \
--permission session.read \
--permission session.manageminted api key support-triage backend (01a0877e-…) in workspace production (01a0877c-…)
permissions: session.create, session.read, session.manage
expires: (never)
prefix: sbk_ak_4f50c2aa
the secret below is shown once and cannot be retrieved again:
sbk_ak_4f50c2aa8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX最後の行 — sbk_ak_… のシークレット全体 — をコピーしてください。prefix
ではありません。あれは api-key list でキーを見分けるためのラベルです。
以降の呼び出しは SUBAKO_API_KEY から読むので、いま入れておきます。
export SUBAKO_API_KEY=sbk_ak_4f50c2aa8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXこれは curl の例のために、あなた自身が用意するシェル変数です。CLI
がこれを読むことはありません — subako は API key ではなく、subako login で保存されたログインで認証します。
このサーバーがキーに与えられる権限は subako api-key permissions
が一覧します。動作する範囲でもっとも狭い組み合わせを与えてください —
Permission を参照。
session を作成する
curl -X POST https://api.us.cloud.subako.ai/v1/sessions \
-H "Authorization: Bearer $SUBAKO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"agent_id": "<agent-id>", "display_name": "ticket-4192"}'{
"id": "01a0877f-d3b3-7e73-9eed-a16caee8cff7",
"status": "idle",
"session_token": "sbk_st_...",
"session_token_expires_at": "2026-09-09T19:48:16Z"
}session_token はこの session ひとつに限定された credential
で、permission は何も持たず、一度だけ表示されます。ブラウザのタブに渡すの
はこれで、API key はサーバー側に置いたままにします。session_token_expires_at
で失効するので、追加分は API key を使って
POST /v1/sessions/{session_id}/tokens から発行します。
残り 2 つのステップでは session の id
とこのトークンが必要になるので、どちらも控えておいてください —
これもあなた自身のシェル変数です。
export SESSION_ID=<the id from the response>
export SUBAKO_SESSION_TOKEN=<the session_token from the response>どの呼び出しがどちらの credential を取るかに注意してください。session の作成は API key の仕事で、session の中で起きることはすべて session token の仕事です。
メッセージを送る
ユーザーのターンを追記すると run が始まります。
curl -X POST https://api.us.cloud.subako.ai/v1/sessions/$SESSION_ID/events \
-H "Authorization: Bearer $SUBAKO_SESSION_TOKEN" \
-H "Content-Type: application/json" \
-d '{"type": "input", "text": "Summarize ticket 4192."}'応答には、これによって始まった run が示されます。
{ "run_id": "01a08780-611d-7290-a9a0-e8a27b64ad9c", "outcome": "new_run" }動きを見る
ストリームはログの先頭から追尾するので、すでに終わった run
には送るものが残っていません。after_seq=0 を渡すと、session
を最初の event から再生したうえで、そのままライブに続きます。
curl -N "https://api.us.cloud.subako.ai/v1/sessions/$SESSION_ID/events/stream?after_seq=0" \
-H "Authorization: Bearer $SUBAKO_SESSION_TOKEN"Event は SSE として届き、それぞれに再接続の再開点となるシーケンス番号が
付いています。Run は run_completed、run_failed、run_cancelled
のいずれかで終わりです。
id: 2
event: message_user
data: {"seq":2,"type":"message_user",...}
id: 5
event: message_assistant
data: {"seq":5,"type":"message_assistant",...}
id: 6
event: run_completed
data: {"seq":6,"type":"run_completed","run_id":"01a08780-..."}そのあともストリームは次の run
を待って開いたままになります — curl
は自分では終了しないので、run_completed を見たら中断してください。