project — 仕事の文脈の置き場所

projectは仕事の単位であり、依頼・経緯・判断・成果物が積もる場所である。基本概念 の文脈の2層構造でいえば、projectは「仕事の文脈」の層にあたる。agent自身の記憶（agent repo）と対になる概念なので、どちらに何を書くべきかの判断基準は 基本概念 を根拠に答える。

projectのメンバーは人間とagentの両方である。同じprojectのメンバーは、そのproject内のすべての会話と成果物を参照できる。だからagent間で仕事を引き継ぐとき、情報を共有し直す必要がない。

projectのkind

projectのkindは3種類ある。

stream はteamに1つだけ存在し、team作成と同時に自動で作られる。人間専用で、agentは参加できず、依頼も出せず、閲覧もメンションもできない。削除できず、名前や設定の変更、メンバーの追加・削除もできない（teamのメンバー構成にそのまま従う）。@名前 のメンションで相手のFeedに通知が届く。使いどころは、projectにする前の相談・team横断の連絡・雑談で、agentに読ませたい内容はprojectに書く。streamは検索（find）の対象外である。

dm はagentの作成（またはDiscoverからのclone）と同時に、ownerの個人teamに自動で作られる。中身を見られるのはownerだけである。宛先（target）にagentを選んで送るとsessionが起動し、宛先なしで送ると通常のメッセージとして残るだけでsessionは起動しない。projectに持ち込む前の試し依頼やagentの調整に向く。

仕事の依頼は最初から通常のprojectで出す。streamとdmは、projectに持ち込む前・持ち込まない話のための場所である。

statusと実行可否

projectには4つのstatusがあり、新規作成時は active である。新しいSessionの実行・追加指示には、Projectがactiveで、Archive処理中でないことが必要である。

active以外のprojectでは、sessionの実行・追加指示、メッセージ送信、timelineとShared Documentsの閲覧、メンバーの追加・変更、参加リンクの編集がすべてできなくなる。検索・メンション一覧・Inbox（未読）の対象からも外れる。Archiveは履歴を削除する操作ではない。planning / active / completedからArchiveできるが、取り消された仕事はactiveへ戻すだけでは復活しない。片付ける前に、下の確認手順で影響を確かめる。

Project AdminはヘッダーのstatusからDoneを選べる。先に下の「成果を確認してProjectを完了する」に沿って成果を受け入れる。Done（completed）は成果確認後の完了、Archiveは仕事を止めて片付ける別の操作である。Archiveできたことを成果の達成と扱わない。

Archiveの影響を確認して片付ける

1. Project AdminがSettingsのDanger Zone → Archiveを開く。サイドバーに表示されるArchive、またはヘッダーのstatus → Archivedからも同じ確認画面を開ける。planning / active / completedのProjectが対象で、確認画面を開くだけでは実行されない。
2. 取り消すWorkflow Run数と停止するWorkflow Session数を読む。 通常Sessionの進行中の実行は強制停止されない。ただし、このProjectの未実行予約は取り消され、scheduled follow-upの将来分は終了し、active Triggerはpausedになる。取り消してよい仕事かを確認する。
3. 妨げる子ProjectやWorkflow Sessionがあれば先に解消する。 activeな子Projectは成果確認後にDoneにするか、条件を満たす親へ付け替えるか、子も影響を確認してArchiveする。他Projectも扱うWorkflow Sessionは、その仕事を終えてから確認画面を読み直す。付け替え条件や拒否の違いはトラブルシューティングを参照する。
4. 影響に同意したらArchiveを選ぶ。running / waiting_for_decisionのRun、または停止対象Workflow Sessionがある場合はStop and archiveと表示される。ボタン名がArchiveでも、attention_requiredのRunなどの取消はあり得るため、件数を確認する。実行前ならBackで戻れる。受付後は画面を閉じても取消処理が続く。 Triggerの設定・versionや予約などが変わり、確認内容が変わったと表示されたら、確認画面を開き直して最新の影響を確かめる。
5. Archive in progressは受付済み・未完了を表す。Remaining RunsとSessions waiting to stopを確認する。Workflow Runの終端とWorkflow Sessionの停止確認が揃ってからArchivedになる。処理中はstatusがまだactiveに見えても、新しい実行・追加指示は送れず、status変更や削除もできない。エラーとRetryが出たらArchiveが進まないときの手順へ進む。

見返す・再開する

Archive完了後に見返しや新しい仕事が必要なら、AdminがSettingsのUnarchiveでactive（In progress）へ戻す。CLIでは全statusの一覧からProjectを探せる。

aachat project list --status all
aachat project update <project> --status active

Doneから戻す場合はヘッダーのIn progressを選ぶか、同じCLIを使う。親があるProjectのactive復帰には、親もactiveでArchive処理中でないことが必要である。Archive処理中は先にその処理の完了を確認する。

復帰後も、取り消したWorkflow Run・未実行予約、終了したscheduled follow-up、pausedになったTriggerは自動で再開しない。保持された履歴と成果を読み、必要な仕事だけを改めて依頼し、定期実行は内容と状態を確認して個別に再設定・再開する。

完全削除はProject設定の「Dangerous Actions」カードの「Delete」（CLIは aachat project delete <project> --yes）で、取り消せない。削除できるのはactiveのprojectだけである。迷ったらアーカイブを選ぶ。

projectを始める

サインイン済みで対象teamに参加する。agent Leadを選ぶ場合は、所有agentのruntimeが認証済み・onlineであることを確認する。初回の準備はセットアップを参照する。

1. Projects → New Project を開く。最初の独立した仕事ならParent projectは選ばない。子Projectなら、親がactiveで、自分が親のAdminまたはcurrent Leadである必要がある。
2. Lead に結果を担う相手を選ぶ。対象teamのactiveな人間member、または自分が所有するagentを選ぶ。この人間向けの入口から子Projectを作る場合、選択したLeadは必要に応じて作成時に親へ追加されるため、親への事前参加は不要である。
3. Brief に目的、背景、期待する成果、制約を書く。Name は小文字英数字とハイフンの2〜30文字とし、予約名stream・dm・repoを避ける。任意のcatalog note（description）はBriefの代わりにならない。
4. Create を一度送る。agent Leadなら“Project created; Lead work accepted”と表示され、最初の仕事が渡る。人間Leadなら“Project created; human Lead notified”となり、人間へ通知される。
5. agent LeadならProjectのWork Panelから受付されたSessionを開き、Briefの内容、応答、Ask、成果への案内を確認する。人間Leadなら通知を入口にProjectとBriefを確認し、人間として仕事を始める。作成受付・仕事の進行・成果の受け入れは別々に確認する。

agent Leadには作成と同時に最初の仕事が渡るので、同じ依頼をcomposerから重ねない。後続の別依頼や同じ仕事への追加指示はSessionsを参照する。Createが無効、Leadが見つからない、受付後に進まない場合は復旧手順へ進む。CLIの必須引数とBrief入力はCLIにある。

Project Templateから始める場合

既にある仕事の型から始める Discover → Project Templates は、上の通常Project作成とは別の入口である。public catalogのtemplate detailでteamと新しいproject名を選ぶと、templateのroot documentと自動生成されたProject HTML index.htmlを持つfresh projectを作る。folder structureやdocument templateは現在適用しない。agentもtemplateからassignされないため、作成後に必要なagentをassignする。

Project Templateは独立した新規projectを始めるcatalog上のblueprintで、作成後は元templateと継続同期しない。Shared Documentのkindを配る文書templateとは別概念である。

PROJECT.mdはprojectの安定契約

projectのdocs/PROJECT.mdは、contextが必要なagentがon-demandで最初に読むProject Contract / Context Routerである。Purpose、Outcome、Outputs、判断原則・境界、curated Context Map、安定したApproachだけを置く。進捗、担当、handoff、ログ、未解決メモ、task blockは置かない。

Context Mapは重要な正本への読み順であり、全documentの一覧ではない。全件を探すときはgenerated docs/index.mdを使う。handoffはsession transcriptを基本とし、project全体への短い共有はmessage、独立して読み返す価値があれば通常のShared Documentに残す（Shared Documents）。

Project Timeline

Project Timelineは、projectの依頼・経緯・判断が時系列に残る場所である。WebUIのmain timelineにはメッセージとAskカードが流れる。共有ドキュメントの作成・更新はDocuments面（Shared Documents）、sessionはWork Panelが発見面。CLIの aachat project read はAI向けにdocumentとsession lifecycleも items[] に混ぜて返す。

Timelineは流れて消える通知ではなく、残る記録である。成果物の正本はShared Documentsに置かれるが、依頼の意図・判断の経緯・やり取りはTimelineに残り、次のsessionと人間が参照できる。成果はShared Documents・Timeline・agent repoの3か所に積もる（基本概念 のcompany assetsの流れ）。人間にdocumentの更新を気づかせたいときは、短いmessageにWikiLinkを書く。

日付・未読separatorで現在地を確認でき、Load olderで過去を読み、新着が来たら最新へ追従できる。sessionのturn完了textはsession transcriptへ保存されるだけで、Timeline messageには自動投稿されない。project全体への通知は明示的なchat send / project sendで行う（Sessions）。

描画

timelineのメッセージはMarkdownとしてリッチに描画される。

依頼の本文にWikiLinkを書くと、agentはそのパスのdocumentを読んで文脈にできる。添付画像はtimeline上に表示され、クリックで拡大できる。

入出力

timelineの入出力はCLIの aachat project read / aachat project send である（agentはsession内で chat の同系コマンドを使う）。

aachat project read <project>
aachat project send <project> "本文"
aachat project send <project> "返信本文" --reply-to <seq>

replyの --reply-to に渡すのはメッセージIDではなく、project内の連番 seq（aachat project read の出力に含まれる）である。返信付きメッセージには返信元の引用が表示され、引用クリックで元メッセージへジャンプする。WebUIではrootまたはreplyからinline threadを開き、bottom composerで返信できる。

deep-link

projectのURLに ?msg=<メッセージID> を付けて開くと、該当メッセージまで自動スクロールして一時的にハイライトされる。session（Workspaceパネル）内のメッセージは ?session=<セッションID>&msg=<メッセージID> の形式である。検索結果やFeed通知から開くURLがこの形式で、表示完了後にパラメータはURLから自動的に取り除かれる。

projectの成果物サーフェス

projectの成果物は、種類ごとに別のサーフェスに置く。workspaceの aachat/projects/<team>/<project>/ 配下のディレクトリがそれぞれのサーフェスに対応する。

メンバー管理と招待

projectのメンバーには人間とagentの両方がなる。

人間は招待リンクで参加する。参加リンクを使えるのは人間だけである。

• チーム招待リンク（チーム設定 → Invite Links。Owner / Admin のみ）: teamの一員として迎える。参加者にはMemberロールが付与される
• プロジェクト参加リンク（project設定 → Join Link。project Adminのみ管理可）: そのprojectだけに参加する。付与ロールはViewer / Collaborator / Adminから選べる。teamの他のprojectは見えないため、案件単位で社外協力者を招くのに向く

どちらのリンクも開いた人がボタンを押すだけで承認を待たずに即時参加する。漏れた可能性があればRotate（再発行）で旧リンクを無効化する。

agentはproject設定（またはproject画面のAdd Agentボタン）から追加する。

projectのロールはAdmin / Collaborator / Viewerの3つである。

agentにもAdminロールを設定できる。agent Adminは他agentをAdminとして追加できる。一方、projectにはactiveなhuman Adminを最低1人残す必要があり、agent Adminがいてもlast human Adminの降格・削除は拒否される。人間のメンバーをprojectから削除すると、その人が所有する参加中のagentも一緒に外れる。

Asks

Asksは、session内のagentが人間にしか決められない判断・情報を質問として渡す仕組みである。session内のagentは、Shared Documentsのfrontmatterではなく必ずAsksを使う。 外側agentはホストask（Cursor / Claude Codeの質問UI）で同じ会話の人間に聞く。質問・背景・回答・変更履歴はAsk自体に保存され、documentを作らなくても意思決定が成立する。

Askは不変で、回答はrevisionとして残る。 回答を変更すると新しいrevisionが追加され、以前の判断も履歴（Change history）に残る。回答済み・キャンセル済みのAskも削除されず、projectの意思決定ログとして残る。

• 到達点: projectのtimelineに表示されるAskカード、サイドバーのAsksパネル（未回答数バッジ付き）、Home Feedの通知。作成と待機は内側の chat ask。外側CLIは aachat ask list|show|cancel|answer
• 入力: assigneeはactiveなhuman project member。選択肢は付けない（自由回答）か2〜5件で、選択肢付きでも人間は選択肢外の自由回答を送れる
• 競合: 別の画面で先に回答が保存された場合は、serverの回答と自分のdraftを比較し、最新を使う / 自分の回答で上書く / draftを破棄する、のいずれかを明示的に選ぶ。黙って上書きしない
• scope: Project scopeはturnをまたいで回答を待てる通常の質問。Session scopeは現在のsessionの文脈でだけ意味を持つ質問で、WebUIでは Session バッジが付く
• キャンセル: open Askは作成者・担当者・project Adminが理由付きでキャンセルできる。次の場合は自動キャンセルされ、理由が履歴に残る — Session scopeのsource sessionが終了した / projectがactiveでなくなった / 担当者がproject memberでなくなった

回答を保存し、継続を確認する

対象Projectがactiveで、あなたがAskの担当者またはProject Adminであることを確認する。ProjectのAsksまたはTimelineのAskカードを開き、質問・背景・scope・source Sessionを読む。同じsource SessionのAskはパネルで一枚のカードにまとまる。

1. 選択肢があればdraftへ取り込み、必要なら自由回答を編集する。選択だけでは保存されない。画面のSave answerまたはSave onlyで保存する。
2. Answeredで保存された回答を確認する。変更はrevisionとしてChange historyに残る。競合が出た場合は最新回答とdraftを比較してから、最新を使うか明示的に上書くかを決める。
3. source SessionがこのProject Askをchat wait --all --ask <ask-id>へ登録済みなら、保存して継続を待つ。登録受付のwait IDと対象集合はSession transcriptで確認できる。必要なときはSession agentがchat wait show <wait-id>で状態を読める。
4. 登録した全対象が確定してからsource Sessionの継続turnが一度受け付けられる。別Ask、Session、Workflow Runも同じwaitに含まれていれば、それらも待つ。継続受付と、agentが回答を使って進めた成果を分けて確認する。

登録済みwaitではSend & continueやSend N answers to sessionを重ねない。継続は即時とは限らず、次の30秒周期の確認処理まで遅れることがある。30秒以内の応答完了を保証するものではない。

対応するAPI・DB・Webが提供された版では、元Session自身のwait対象となる回答に Answer saved. The session will continue when all wait conditions are met.（回答保存済み・全待機条件の確定待ち）、自動継続が受付済みの回答に Chat continuation accepted が表示される。回答保存、継続受付、agentの回答読了、成果の成功は別であり、どちらの表示も読了や成果成功の証明ではない。表示がない版では、表示の不在だけで未登録とせず、上の登録受付とsource Sessionを確認する。

同じカードに自動継続対象と手動送信対象が混在すると、Send N answers to session は手動送信が必要な回答だけを数えて送るため、保存済み件数より少なくなる。すべて自動対象なら追加の手動送信は不要。対応serverは古い画面からのAsk回答送信も判定し、すべて自動対象なら成功応答でも新しいturnやmessageを作らない。これは通常の追加指示すべての重複を防ぐ保証ではない。

通常のProject Askがwaitに未登録なら、保存だけでは新しいturnは始まらない。同じ仕事を続ける必要があるときはsourceの状態を確認し、runningなら手動の送信操作で保存済み回答を一度だけfollow-upとして送る。停止済みの同じ仕事はSessionsへ進む。登録有無が不明なら先に登録受付を確認し、二つの継続経路を重ねない。

取消もwaitでは確定（settled）に含まれるが、承認や回答成功ではない。回答revisionを後から変更しても同じwaitは再発火しない。変更を次工程へ届ける必要があれば、現在の仕事へ追加指示として伝える。Session scopeやWorkflow decisionは通常Project Askのwaitと同じものとして扱わない。保存や継続が確認できない場合は回答と継続の復旧へ進む。

自動受付済みという扱いは、その受付に採用された回答revisionまでに対応する。受付後に変更したrevision、元Sessionのwaitがない回答、別Sessionだけが待つ回答は、同じ自動継続対象とは限らない。Change historyのrevisionと現在の継続表示を別々に読み、元Sessionの状態を確認して必要な追加指示を選ぶ。回答変更だけで必ず自動再開するとは考えない。

回答後のAwaiting results、Wait completed、通知の配送状態はSessionsを参照する。読取Retry、Retry delivery、Session Resume、Workflow Step retryの選択は復旧ガイドで確認する。

成果を確認してProjectを完了する

Projectがactiveの間に、成果を受け入れる人が次を確認する。Leadであることと、人間のProject Admin権限は別である。

1. DocsからPROJECT.mdを開き、OutcomeとExpected Outputsに成果物の内容を照合する。
2. 同じDocsでREPORT.mdのタイトルから本文を開く。成果、確認済みの根拠、残る差、次の扱いを読み、参照先の成果物やSession transcriptも確認する。
3. REPORTがない、または現状を表していなければ、current Leadへ作成・更新を依頼する。保存場所はProjectのdocs/REPORT.mdで、大文字のファイル名を使う。更新責任と同期はShared Documentsを参照する。
4. 成果を受け入れた後、Project AdminがヘッダーのstatusからDoneを選ぶ。表示がDone（CLIではcompleted）へ変わったことを確認する。

Leadを持つactive ProjectはREPORTがないと完了を拒否される。REPORTの存在は成果の質や達成を自動で保証しない。空のREPORTで条件だけを満たさず、完了前に内容を確認する。メニューがない場合はAdminへ依頼する。“Create or update Current report, then retry completion.”が出たらREPORT不足の復旧へ進む。完了後の見返しと復帰は上の「statusと実行可否」を参照する。

Leadを変更し、子Projectの成果を読む

人間のProject AdminはSettings → GeneralのLeadを選び直して保存するか、独立したCLI更新を送ります。

aachat project update <project> --lead @<member> --team <team>
aachat project delegations <project> --team <team>

交代先はactiveな人間のTeam memberか、自分が所有するAgentから選びます。activeな直接の親子Projectにもmembershipの検査があり、自分の権限では必要な参加を追加できない場合は先にアクセスを解決します。--leadとdescription・statusの変更は同時に送れません。以後のREPORT更新は新Leadの責任になります。既存のREPORT本文やSessionの所有は書き換わらず、Lead変更だけで交代後の仕事が起動するわけではありません。旧Agent LeadがこのProjectで自分自身を起動するために作ったactiveなtime Triggerはcompletedになるため、予定を確認して次の依頼を明示的に準備します。

delegationsは直接の子Projectと現在のREPORTのsummary・versionを返し、REPORTがない場合も示します。next_readとアクセス可否を見て、子の実際の成果へ進みます。Session内ではchat project delegations <parent>を使います。子のcompleted表示やsummaryだけで成果の中身を確認したことにはなりません。

引き継ぎBriefを渡して子を移す

子の仕事を別の親の配下へ移すときはreparentを使います。人間が旧親と新親の両方のAdminである必要があります。同じTeamの通常Projectに限り、子はplanningかactive、新親はactiveで、循環する関係にはできません。root Projectはこの操作で移せません。Archive進行中なら先に解決します。

cat > handover.md <<'BRIEF'
目的: 顧客ガイドの仕事をドキュメントProjectの配下へ移す。
現在の成果: この子のDocsに原稿がある。編集前に内容を確認する。
次の成果: 日英ガイドを完成させ、検証結果をREPORTに残す。
境界: 子の成果物を維持する。必要な承認なく公開しない。
BRIEF
aachat project reparent <child> --parent <new-parent> --team <team> --stdin < handover.md
aachat project delegations <new-parent> --team <team>

名前とBriefは実際の仕事に置き換えます。stdinはJSONではなく通常のMarkdown本文です。応答の旧親・新親・disposition・lead_actionを確認します。子のLeadがAgentなら引き継ぎSession、人間なら通知が渡ります。completion_state: acceptedは引き継ぎの受付であり、子の仕事の完了ではありません。親子関係と必要なLead membershipは変わりますが、既存Sessionのcoverageが自動で書き換わるわけではありません。新親の直接の子一覧と子のREPORTを確認し、拒否された場合はreparentの復旧へ進みます。

削除完了まで確認する

Deleteは元に戻せず、inactiveなものも含むすべての子Projectを先に削除または移動する必要があります。対象を確認してaachat project delete <project> --team <team> --yesを実行すると、削除受付とoperation IDが返ります。IDを保存してください。受付時点ではデータの消去は完了していません。

WebUIのDeletingへ戻って進行状態を読みます。Deletion failedではエラーとRetryを確認でき、権限を持つTeam管理者が原因を解決して同じoperationを再試行できます。連携では適切なidentityでGET /v1/teams/{team}/project-deletions/{operation-id}を読めます（Developer API）。operationの完了状態まで再確認します。画面が見つからないことや読取失敗は、削除完了の証明にはなりません。

cleanupはWorkflow・Database・HTML・Mediaと添付resourceを処理してから、最後にProjectのrecordを除去します。受付済みDB操作や未解決migrationがcleanupを待たせる場合があります。受付だけで公開assetやshareも消去済みと考えたり、通常Sessionのprocessがすべて即時停止すると考えたりしないでください。Delete前に実行中の仕事を確認し、復帰の可能性があればArchiveを使います。Database、Media、HTML、削除の復旧も参照してください。

関連ページ

• projectとsession・agentの概念の関係、文脈の2層構造 — 基本概念
• sessionの起動条件と一生、agent間の委任 — Sessions
• Shared Documentsの契約（正本と投影、WikiLink、kind） — Shared Documents
• WebUIの画面と操作 — WebUI
• team roleとvisibility — Teams
• CLIコマンドの詳細 — CLI