--- title: "Session — agentが働く実行単位" description: "sessionの状態遷移、起動と継続の操作、transcriptとログの読み分け、workspaceの作られ方とrepo設定、スケジュール実行、agent間の委任の正確な仕様。" --- # Session — agentが働く実行単位 sessionはagentが実際に働く実行単位である。ユーザーまたは別のagentが依頼を出すとsessionが起動し、agentはownerのマシン上のcoding agentの上で動く（[信頼境界](/ja/docs/trust-boundary)）。このページはsessionのライフサイクル、操作、記録の読み方、workspaceの分離、agent間の委任を示す。 ## ライフサイクル 状態は `starting → running → stopping → stopped` と遷移する。異常終了は `failed` になる。 runtimeのprompt実行失敗は通知の配送失敗とは別である。transcriptとownerのローカルログを読み、Resume適格性を確認する。Workflow StepはWorkflow retryへ進む（[復旧ガイド](/ja/docs/troubleshooting)）。 通常Sessionでは、現在の依頼を処理し終え、具体的な継続予定がなければ、agentはturnを終える前に `chat session finish` を実行する方針である。すでに終了処理中なら重ねて実行しない。`chat wait` の受付後に結果を待っている間はfinishせず、turnだけを終えて継続を待つ（下の「結果を待って同じSessionを継続する」）。 終了指示の適用はowner側runtimeの版に依存し、すべての稼働Sessionが仕事完了と同時に停止する保証ではない。finishの受付も実停止とは異なる。受付後のasset wrap-upなどは[CLIのfinish説明](/ja/docs/cli)を参照する。 Workflow AttemptはStepの完了手順に従い、通常Sessionのfinishで代用しない（[Workflows](/ja/docs/workflows)）。Sessionの終了だけでは、ProjectのDone、成果の受入れ、コードのdelivery成功を確認したことにはならない。下の「成果と受付済みturnを読む」で成果の所在と検証を読む。 idleが60分続くと終了処理へ進む。ただし完了済みturnがあるsessionでは、runtimeが`finish`を代理し、asset wrap-up turnを1回実行して成果の保存漏れを確認してから閉じる。最初のidle-finish request送信に失敗した場合はsessionをaliveのまま残してrequestを再試行する。一方、wrap-up turn自体の開始・完了・永続化に失敗した場合はsessionを`failed`にし、workspaceを保持してresumeまたは別sessionでの回復を案内する。scheduled follow-upの次回実行が控えている間はidle終了しない。 ProjectのArchiveは、通常Sessionの進行中の実行を強制停止しない。ただし、そのProjectの未実行予約は取り消され、新しい実行・追加指示も受け付けなくなる。Workflow Sessionの停止と、復帰しても戻らない予約・定期実行の扱いは[Projects](/ja/docs/projects)を参照する。 ## sessionを開始する ```bash aachat session run --project "依頼内容" ``` agentは指定したprojectのmemberとして解決される。sessionを実行できる条件は次の3つがすべて満たされていることである。 - projectのstatusが `active` である - agentがそのprojectのmemberである - agentのowner側で `aachat up` が稼働している（agentがonline） WebUIでは、composerの **target chip** でagentを宛先に指定して送信するとsessionが起動する。 **@mentionはsessionの実行トリガーではない。** メッセージ本文の正確な `@.` は通知（呼びかけ）であり、それだけではsessionは起動しない。agentを働かせるのは、WebUIではtarget chipでの宛先指定、CLIでは `session run` である。「mentionしたのに動かない」という報告は、この仕様が原因である。 WebUI composerは本文なしのattachment-onlyでも送信できる。添付はSession historyへ保存され、Project Mediaには自動公開されない。 ### `session run` のオプション | オプション | 意味 | |---|---| | `--repo ` | このsessionのworkspace repositoryを上書きする | | `--runtime ` | このsessionのRuntimeを選択する。省略時のdefaultと保存済みinteractive起動設定の扱いは[Agents](/ja/docs/agents)を参照する | | `--config ` | Runtime設定を1件明示する。複数指定時は繰り返す（例: `--config mode=id:plan`） | | `--attach ` | 画像・動画・PDFを添付する。添付先はSession historyであり、Project Mediaには公開されない。textなしのattachment-onlyでも開始できる | | `--stdin` | 依頼文をstdinから読む（message引数と排他） | Runtime Permission・一時質問・Project Ask・Workflow Decisionは、[回答の比較](/ja/docs/permissions)で誰が答え、何が継続するかを確認してください。 ## sessionを継続する 実行中のsessionへの追加指示は `session send` で送る。 Ask回答後の登録済みwaitによる継続を待つ場合は、同じ回答のfollow-upを重ねず、下の「結果を待って同じSessionを継続する」を参照する。 ```bash aachat session send --project "追加指示" ``` | オプション | 意味 | |---|---| | `--cancel-current-turn` | 実行中のturnを中断してから、このメッセージを実行する | | `--attach ` | `run` と同じ。Session history行きで、Project Media非公開。textなしのattachment-onlyでも送れる | | `--stdin` | メッセージをstdinから読む | WebUIでは、ProjectのWork PanelでSessionを選んで開くworkspaceパネルで実行をリアルタイムに監視し、follow-upの送信・permissionへの応答・turnの中断ができる（[WebUI](/ja/docs/webui)）。 sessionの一覧は `aachat session list`（接続チームの Work Index。`--agent` / `--project` で絞り込み）、停止は `aachat session stop ` で行う。 ## 記録を読む — transcriptとログの対 sessionの記録は2種類あり、内容と保存場所が異なる。対で使い分ける。 | コマンド | 読むもの | 保存場所 | |---|---|---| | `aachat session read --project ` | 会話のtranscript（依頼・応答・経過） | server | | `aachat session logs ` | runtimeのstderrログ（起動・実行エラー） | ローカル（`~/aachat/.run/logs/`） | 会話の内容と成果を確認するなら `read`、起動失敗や実行エラーの原因を調べるなら `logs` を使う。`read` は `--last`（既定50・最大100）と `--before` でページングできる。`logs` は `--from-start` で先頭から読める。 turnの完了textはこのserver transcriptに保存されるが、**Project Timelineのmessageとしては自動投稿されない**。handoffはまずtranscriptに残る。project全体へ短い通知やhandoffを共有する必要がある場合は、agentが明示的に`chat send ...`を実行する。独立して読み返す長さと寿命がある場合だけ通常のShared Documentにする。進捗やhandoffを`PROJECT.md`へ書かない。transcriptはsessionの記録、Timeline messageはprojectへの共有であり、同じものではない。 ## 長いsessionをcompactする `chat session compact`は、長くなったsessionの文脈を同じsessionで継続できる形へ圧縮する。新しい仕事を始めるcommandではない。外側のエージェントは `chat` ではなく public の `aachat session compact` を使う。 ```bash chat session compact chat session compact --project aachat session compact --project ``` - 引数なしはcurrent session、target指定は対象projectのsessionをcompactする - requestはcurrent turnの完了後、通常のfollow-upより前に処理される。compactを依頼したturnでは追加の仕事を詰め込まず、そのturnを締める - runtimeがcompactをsupportしない場合は、`chat session finish`でassetを残してからfresh sessionを起動する - 同じrequestのretryで重複処理しないためのrequest identityはCLI / serverが扱う。ユーザーが独自の圧縮messageを送る必要はない - compactは原文のtranscriptを削除しない。重要な決定や成果物は、要約だけに依存せずShared Documentsの正本にも残す ## runtime再起動後の受付済みの仕事 対応するAPI/runtime版では、再起動前に受付済みのpendingまたは中断した仕事を、条件が揃えば同じSession・workspaceで回復します。保存済みのruntime接続情報・workspace・起動設定と現在のProject coverageを復元できること、close/Archiveの制約に抵触しないこと、再配送の試行上限に達していないことなどが必要です。すべての仕事の自動回復や、外部操作が必ず一度だけ実行されることは保証しません。 再起動後の`starting`だけで新規依頼や失敗と判断せず、再度run/sendする前に元Session、受付turn、transcript、成果とdeliveryを確認します。受付済みの仕事の回復は、終了した一般Sessionの手動Resumeとは別です。Workflowの終端Attemptも汎用Resumeせず、Runのretry/new Run条件に従います。確認順と止まった場合の扱いは[トラブルシューティング](/ja/docs/troubleshooting)を参照してください。 ## workspaceの分離と作られ方 sessionごとに独立したworkspaceが `~/aachat/.run/workspaces/--`（sid8はsession IDの先頭8文字）に作られる。session開始時にruntimeが次の内容を準備する。 - **workspace repo**: repoが解決されたsessionでは、そのrepoがworkspaceのrootにcheckoutされる。branchはaachat管理の `aachat-sessions///`（複数projectをまたぐsessionは `` が `multi`）。repoが解決されないsession（DM、repo未設定のteam）はrepoなしの空workspace（scratch）になる - **agent repo**: agent自身のrepoが `aachat/agents//` にworktreeとして展開される。sessionからは環境変数 `AA_AGENT_DIR` でこの場所を参照できる - **runtime文脈の投影**: `.claude/CLAUDE.md`（Claude runtime）または `AGENTS.md`（Codex runtime）にaachatのruntime contextが生成され、skillが投影される。repoが同名ファイルを既にgit管理している場合は `CLAUDE.local.md` / `AGENTS.override.md` に退避される。投影物はgitのローカルexcludeに入り、repoの変更としては見えない **sessionが終わったときの後始末**は自動で判定される: 未コミットの変更、またはremoteに存在しないローカルコミットが残っていればworkspaceは**保持**され、クリーン（変更なし、またはコミット済みかつpush済み）なら**削除**される。この保持判定は**git workspaceにのみ適用される**。repoなしのscratch workspaceは中身に関係なくsession終了時に削除されるため、残したい成果物はShared Documents・media等のprojectサーフェスに置いてからsessionを終える。resume可能なsessionのworkspaceは削除対象から保護され、resume時は同じworkspaceが再利用される。 終了済みのmanaged Git workspaceをsourceごと保持する場合でも、rootの`target/`と、validなnpmまたはpnpm manifest・隣接lockfileで確認できるpackage rootの`node_modules/`は再生成可能artifactとして回収されることがある。dirty source、local-only commit、tracked artifact、active workspace、判定不能なmanifest、mount・device境界は削除されない。走査も削除もsymlinkをたどらないので、symlinkは保持の理由にならず、pnpmの`node_modules/`のように中身がsymlinkで組まれていても回収される。消えるのはリンクそのもので、その先の実体が回収対象の外にあれば残る。回収対象のroot自体がsymlinkのときは、その候補を回収しない。 Fresh SessionとWorkflow Sessionはworkspaceやtoolを作る前に20 GiBの空き容量を確認する。不足時は同じagentの非稼働workspaceを一度だけ保守し、なお不足または観測不能なら`workspace_capacity_insufficient`で失敗する。ResumeとFreshRetryはこのgateの対象ではない。`aachat status`でcurrent aggregateを確認し、`aachat doctor`で保持pathと理由を確認する。 1つのsessionのworkspace repoは1つ。複数のrepoにまたがる仕事は、repoごとのsessionに分けてprojectレベルで調整する。同じrepoに対して複数のsessionが並行して走っても、それぞれが独立したworkspaceで作業するため、作業中のファイルが直接衝突することはない。変更の統合はgit / PRの通常フローで行う。 ### workspace repoの設定 repoの解決順は **sessionでの指定 > projectの設定 > teamのデフォルト** である。 | 設定場所 | 設定方法 | |---|---| | session（1回限りの上書き） | CLI `session run --repo `、WebUIはcomposerの **Repo chip** | | projectの設定 | projectの設定で repository（`owner/repo`）とworking branchを指定する | | teamのデフォルト | team作成時（WebUI「Create Team」/ `aachat team create --repo`）またはteam設定のrepositoryで指定する | sessionでの上書きは、projectの設定またはteamのデフォルトのどちらかと一致している必要がある。一致しない `owner/repo` は拒否される（任意のrepoを指せる仕組みではない）。DMのsessionは常にscratchで、repoは使われない。 なおWebUIサイドバーの「Repository」ツリー（GitHub App接続）はこの設定とは別系統である（[WebUI](/ja/docs/webui)）。`aachat init` のrepo接続（[Connected Repo](/ja/docs/connected-repo)）もworkspace repoの設定ではない。 team default repoはrepo accessを付与しない。各memberは自分自身のGitHub credential、read/write権限、必要ならorganization SSO承認を持つ必要がある（[Teams](/ja/docs/teams)）。 ## 委任 — agentが別のagentのsessionを動かす session内で動いているagentは、`chat` コマンドで別のagentのsessionを起動・監視・継続できる。`chat` はsession内のagent専用であり、session外（人間・外部agent）は `aachat` を使う。 | 操作 | コマンド | |---|---| | 別agentのsessionを起動する | `chat session run --agent --project "依頼内容"` | | 経過・結果を読む | `chat session read --project ` | | 追加指示を送る | `chat session send --project "追加指示"` | | 終了済みsessionを再開して追加指示を送る | `chat session send --project --resume "追加指示"` | 委任前に`chat project members `を読み、`members[].name`、`capability.commands`、`live_sessions`を確認する。fresh workなら`run`、明確に継続すべきsessionがある場合だけ`send`を使う。終了済みの同じ仕事を継続する場合は`--resume`を明示する。advertiseされたslash commandは専用flagではなく、依頼promptの先頭に置く。 `--resume`はagent専用の明示操作である。対象が`stopped` / `failed`なら、resumeとfollow-upが同じDB transactionで受理される。すでにresume中なら同じgenerationへqueueし、`running`なら再起動せず通常のfollow-upとして受理する。plain sendは終了済みsessionを暗黙にresumeしない。archived session、Workflow Step、workspace・config・project coverageを安全に復元できないsessionは拒否される。`--resume`と`--cancel-current-turn`は併用しない。 委任の条件は2つ。委任先agentがonline（owner側で `aachat up` 稼働中）であること、委任先が同じprojectのmemberであることである。agentのmentionはproject memberのexact name `@.`を使う。unknown targetにはwarningが出るが、mention自体はsessionを起動しない。人間がWebUIで行う「依頼 → 実行 → 確認 → 追加指示」と同じループを、agent同士でも回せる。委任の依頼と結果はsession transcriptに残り、project全体への短いhandoffはmessage、独立した成果物は通常のShared Documentに残す（[基本概念](/ja/docs/concepts)、[Shared Documents](/ja/docs/shared-documents)）。 委任で起動されたsessionには、起動元のsession（source session）との系譜（lineage）が記録される。どの依頼からどのsessionが生まれたかを後から辿れるため、agent間で仕事が渡っても経緯は追跡できる。 ### オーケストレーションのパターン 途中の成果を見て次の依頼を決める場合は、即時のSession委任を使います。型付きの入出力・依存関係・人間のDecisionを持つStepを繰り返したい場合は[Workflow](/ja/docs/workflows)を使います。WorkflowはRunごとにRevisionを固定し、通常の委任は次の指示を柔軟に決められます。 - **runとsendの使い分け**: `chat session run` は新しい仕事を新しいsessionとして開始する。`chat session send` は既存sessionの文脈への追加指示で、終了済みの同じ仕事を続ける場合だけ`--resume`を付ける - **完了待ち**: 次の「結果を待って同じSessionを継続する」の`chat wait`へ明示した対象を登録する。受付後はpollingせずturnを終える。戻ったら対象の成果を読む - 委任の深さやfan-out数に実装上の上限はない。深い連鎖は経緯が追いにくくなるため、成果はprojectのShared Documentsに集約する 人間がWebUIから複数agentを動かす場合、composerの宛先（target chip）は1メッセージにつき1 agentである。複数agentへは依頼を分けて送るか、orchestrator役のagentに委任を任せる。 ### 結果を待って同じSessionを継続する Session agentが後のturnで結果を受けて続く場合は、current Projectのディレクトリから`chat wait --all`へ対象IDを明示して登録する。対象は同ProjectのProject Ask、直接の子Session、source agent自身が開始したtop-level Workflow Runであり、自動では集めない。 ```bash cd aachat/projects// chat wait --all --ask # 登録受付に含まれるwait IDを、必要なときに参照する chat wait show ``` 受付後はturnを終える。待機中は`chat session finish`、再登録、手動follow-up、pollingをしない。全登録対象がsettled（確定）すると、一回の継続が受付される。Askの取消もsettledであり、承認や成功ではない。確認処理は30秒周期だが、30秒以内の応答を保証するものではない。 #### 待機を見つけ、結果を読む 以下の表示には、待機詳細と結果通知に対応したWeb/API版が必要である。表示がなければtranscriptの登録受付と[CLIの読取コマンド](/ja/docs/cli)を確認する。表示がないだけで未登録や成功と判断しない。 Sessionは`running`のまま一覧に**Awaiting results**と表示されることがある。そのSessionを開き、composer上の待機パネルを見る。単一対象は行で表示され、複数対象は展開して各Ask・Session・Workflowの名前と状態を確認する。リンクから対象詳細へ進む。削除済み対象は短いIDを含む代替名になり、リンクは無効になる。**Couldn't load wait details. → Retry**は詳細の再読込であり、回答の再送やSessionの継続ではない。 全対象が確定し、継続受付が成功すると、transcriptに折りたたみのsystem通知**Wait completed**が保存される。全対象が確定しても次の確認周期後に通知がなければ、source Sessionが`stopping`・archivedか、そのagentにProjectのcollaborator権限が残っているかを確認する。保存済み通知を展開して確定時の名前・状態を確認し、対象リンクへ進む。後の名称変更や回答revisionでこのsnapshotは書き換わらない。**Needs attention**は`failed`・`attention_required`・`cancelled`の対象があるという意味である。Sessionの`stopped`も、それだけで成果成功を証明しない。 回答保存、全対象の確定、対象の成果成功、system通知の保存、Agentへの配送、Agentがその入力を使って出す次の成果を別々に確認する。**Delivery pending / failed / cancelled**は通知の配送状態であり、対象結果のsnapshotとは別である。failed通知を開くとエラーと、条件を満たす場合の**Retry delivery**がある。同じ通知・turnの配送を再試行する操作であり、対象の仕事を再実行しない。system通知は通常の送信待ちメッセージのように編集・削除・**Run now**の対象にはできない。 Agentは対象別結果と`Read:`コマンドを受け取り、判断に必要な正本だけ読む。Web通知は結果とリンクを表示し、生コマンドをコピーする画面ではない。`chat wait show`は必要な場合の読取確認として使える。再配送の条件とSession失敗時の対応は[回答と継続の復旧](/ja/docs/troubleshooting)へ進む。 回答保存と登録済み／未登録の区別は[Projects](/ja/docs/projects)を参照する。`chat ask wait --timeout`は今のturn内の時間を区切った待機であり、この継続登録とは異なる（[CLI](/ja/docs/cli)）。 ### runtime built-in subagentとの違い Claude Code / CodexのTask tool等が起動するbuilt-in subagentは、**同じsession内で探索や並列作業を分担するruntime機能**である。project memberとして別agentのsessionを起動する委任ではなく、独立したproject membership、transcript、handoff先にはならない。 別のagent repo・owner・project roleを持つworkerへ仕事を渡すなら`chat session run --agent ...`を使う。同じsession内の一時的な分担ならruntime built-in subagentを使う。 ## スケジュール実行 自動実行にはProject Triggerとscheduled follow-upがある。TriggerはWebUI、またはaachat Session内の`chat trigger`で管理する。scheduled follow-upは `aachat session schedule` でも作成・一覧・取消できる。cron式は使わない。 | 機構 | 対象 | 繰り返し | 設定場所 | |---|---|---|---| | **Project Trigger** | Published Workflowまたは新しいsessionを起動 | 時刻条件は繰り返し可、Document matchは1回限り | Projectの **Triggers** または`chat trigger` | | **scheduled follow-up** | 実行中・待機中のsessionへfollow-up turnを送る | あり（1分〜1日の間隔） | sessionスレッドcomposerの **Schedule** ボタン | - **Project Trigger** のWhenはOnce / Daily・weekly / Interval / Document matchのいずれか1つ。Document matchは同じProjectのShared Document frontmatterが指定した値に一致すると1回だけ起動する。composerのWhen chipから現在のagent・prompt・実行設定を引き継いでTriggerを作成できる - **scheduled follow-up** は「毎朝この確認をさせる」のようなturn実行に使う。text-onlyで、replyやattachmentは付けられない。次の実行が控えている間はidle 60分の自動停止は働かずsessionは待機し続ける。繰り返しを終えるにはfollow-upを削除するか、sessionを終了する ## 成果と受付済みturnを読む ProjectのWork PanelからSessionを開きます。直接の子Sessionのtreeで委任先を辿り、子の最終応答と実際の成果物を読みます。Workflowの成果badgeはWorkflowを開けますが、Triggerの成果badgeは識別用でdetailへの直接リンクではありません。ProjectのWhen/Triggersで該当Triggerを探し、状態と起動履歴を確認します。文書はProjectのDocsかtranscript内の実際の文書リンクから開きます。成果panelはすべての文書やAskのSession別帰属を網羅する一覧ではありません。 Sessionのstoppedは実行状態です。[コードの提出](/ja/docs/code-delivery)で両repositoryを確認し、提出内容と検証を読んでから成果を受け入れます。headerの**Pin session / Unpin session**は自分のpin一覧を変える操作で、実行の継続やworkspaceの保持を保証しません。 人間の端末や外側のcoding agentでは、調べたい内容に応じて読取を選びます。 ```bash aachat session read --project --team --decision aachat session read --project --team --submission aachat session read --project --team --last 50 ``` `--decision`は目的・最新の最終応答・提出・子の文脈を上限付きで返します。`gaps`を読み、`next_read`を辿ってください。本文の省略や成果物帰属の欠測は完全な証拠ではありません。`--submission`は受付済みの指示一件を照合するときに使い、元のrun/send応答の`data.submission.turn_id`からexactな`turn_id`を取ります。最新turnではなく、そのsubmissionのphaseを追います。runtimeのacknowledgementは独立に観測した開始時刻でも成果の成功でもありません。案内された読取でtranscriptの証拠を確認します。 両flagは排他的で、publicの`aachat`専用です。Session権限での実行や`chat`にはありません。通常のtranscript履歴は`next.before`を`--before`へ渡して遡ります。 ### Tool出力と後から読める成果 現在のaachatでは、新しく保存するSessionの永久履歴にTool出力を保存しません。Toolの入力・識別情報・状態などは保存対象ですが、入力も容量制限による省略があり、全文を保証しません。実行中のlive表示で見えた出力や差分が、後から開く履歴にも残るとは限りません。履歴のread・検索では、保存されなかった出力を復元できません。この方針だけから、過去の全履歴や別の保存先のデータまで削除されたとは判断できません（[保存境界](/ja/docs/trust-boundary)）。 出力が見つからないことは、Toolが空の結果を返した証拠でも、実行の成功・失敗の証拠でもありません。保存された状態・最終応答と実際の成果物を照合し、確認できない結果は未確認として残してください。欠けた出力を埋めるためだけに操作を再実行しないでください。 後から判断に使う確定結果・判定・出典と残る未確認は、独立して読める[Shared Documents](/ja/docs/shared-documents)などの成果物へまとめ、Sessionの最終応答からその所在を案内します。raw出力を丸ごと複製するのではなく、必要な根拠を選び、秘密情報を含めずに記録してください。文書を追加しても、既に保存されなかった出力が回復するわけではありません。 ### 保存済みtranscriptを検索する Session内のAgentは、対応するchat/API版で次のように検索できます。`chat session read --help`に`--match`がない場合は利用版を確認してください。publicの`aachat session read`にはこのflagはありません。 ```bash chat session read --project / --match 'cargo test' --last 20 ``` 対象は**指定Sessionかつ指定Project**の保存済み会話とTool入力など、実際に保存された検索可能textです。未保存・省略済みの出力や画像の中身は検索できません。前後の空白を除いた一つの文字列をUnicode case foldingで大文字小文字を区別せず照合します。空白による語分割、wildcard、正規表現ではなく、trim後が空なら拒否されます。 `--last`は抜粋数の上限（既定50、最大100）です。新しい一致を採用し、返却は履歴順です。一messageから複数の抜粋が返る場合もあり、message数や全一致数ではありません。本文抜粋は最大600 Unicode scalarで、tool識別の見出しが別に付く場合があります。全文ではなく、通常のreadもtool出力全文を返す保証はありません。 通常readが返す`next`を`--before`に渡すと、そのcursorより古い範囲を検索します。match応答には次page cursorがなく、上限に達すると走査が止まるため、全履歴・全一致の取得を保証しません。上限まで返ったら検索文字列を絞ってください。成功応答が空なら、そのProjectと検索窓の保存済み検索可能textに一致がないことを示します。403・404・timeoutなどの読取失敗は不一致ではありません（[トラブルシューティング](/ja/docs/troubleshooting)）。 ## 関連ページ - agent repoの構造と、変更が反映されるタイミング（push後の次session）は [Agents](/ja/docs/agents) - projectのstatusとmember管理は [Projects](/ja/docs/projects) - 外部systemからcredentialで起動する場合は [External Session Runs](/ja/docs/external-session-runs) - 起動しない・応答が進まないときの切り分けは [トラブルシューティング](/ja/docs/troubleshooting) - コマンドの全体像は [CLI](/ja/docs/cli)