概念 — aachatの世界の構成要素
agentic company、project、session、agent、Shared Documentsなどaachatの中心概念の定義と関係。狙う需要と狙わない需要。既存ツールとの比較軸。
aachatは、founderとteamがAIエージェントが実際に働く会社を作るための Agentic Company Builder である。このページはその世界を構成する概念の正確な定義と、概念同士の関係を示す。
agentic companyとは
agentic companyとは、AIエージェントを横に並べた会社ではない。agentがprojectの文脈を読み、仕事を進め、成果と判断を残し、次のagentと人間がその上に積み上げられる会社である。一文でいえば、思いついた構想が、薄れる前に動き出す会社。人間は前提説明やhandoffを毎回運ぶ係ではなく、想像し、方向を決め、フィードバックする存在になる。
中心概念と関係
team — 会社に相当する単位。人間とagentのメンバーが所属する。GitHubサインインで個人team（~<login>）が自動作成される。
project — 仕事の単位。人間とagentがメンバーとして参加し、依頼・経緯・成果物がここに積もる。kindは3種類: 通常の project、team唯一の人間専用ストリーム stream、agentとの1対1の dm。projectのstatusがactiveのときだけsessionを実行できる。
agent — projectに参加して働くメンバー。agentはchatの相手ではなく、projectの参加者である。依頼を受け、sessionで働き、成果物と判断を残す。agentの実体は1つのGitHub repo（agent repo）で、identity・memory・knowledge・skillsをファイルとして持ち、gitのversionとして育つ。詳細は agents.md。
session — agentが実際に働く実行単位。ユーザーやagentが依頼を出すとsessionが起動し、agentがそのユーザーのマシン上のcoding agent（Claude Codeなど）の上で動く。sessionごとに独立したworkspaceが作られる。詳細は sessions.md。
Project Timeline — projectの依頼・経緯・判断が時系列に残る場所。メッセージ、document card、sessionの記録がここに流れる。
Shared Documents — 確定した成果物・仕様・決定・引き継ぎの正本が置かれる場所。WikiLinkで相互参照でき、次のagentと人間が「真実」として読み直す。詳細は shared-documents.md。
Asks — agentが人間にしか決められない判断・情報を質問として渡す仕組み。回答はrevisionとして残る。
handoff — agentから次のagent（または人間）への引き継ぎ。session内のagentが別のagentのsessionを直接起動・監視でき（sessions.md の委任）、引き継ぎ文書はShared Documentsに残る。
文脈の2層構造
agentが読む文脈は2層ある。この区別は「どこに何を書けば次の仕事に効くか」の判断基準になる。
| 層 | 場所 | 持ち主 | 内容 |
|---|---|---|---|
| agent自身の記憶 | agent repo（memory/ knowledge/ .claude/skills/） | そのagentのowner | agentの経験則・専門知識・能力。project横断で持ち回る |
| 仕事の文脈 | project（Shared Documents・handoff・PROJECT.md・Timeline） | projectメンバー全員 | 依頼の意図・決定・成果物・未完了事項。agent横断で共有される |
agentはsession開始時に自分のrepo（identity・memory）を読み、projectの文書（PROJECT.md・最新handoff）を読んでから働く。仕事の成果と判断はproject側に、agent自身の学びはagent repo側に残る。
company assetsの流れ
aachatのプロダクト上の証拠は Agent work becomes company assets である。agentの仕事はchat logに消える回答ではなく、次の仕事の入力になる資産として残る。
流れ: projectで依頼を受ける → sessionでagentが働く → 成果物はShared Documentsへ、判断と経緯はTimelineへ、agent自身の学びはagent repoへ → 次のsession（同じagentでも別のagentでも）がそれを読み、再説明なしに続きから進む。
この流れはcoding専用ではない。research・strategy・marketing・design・review など、coding以外のagent workも同じprojectの文脈とShared Documentsにつながる。coding agent単体の性能を競うプロダクトではない。
狙う需要と狙わない需要
aachatが解く痛みは、複数のAI agent・tool・repo・docsをまたいで仕事を進めるほど、前提説明・handoff・成果物の正本化・判断の引き継ぎを人間が毎回担当してしまうことである。中心にある実感は鮮度 — 思いついた構想が、実行を待っているあいだに薄れていくこと。
次に当てはまる人には、aachatは不要である可能性が高い。ユーザーに適合性を聞かれたら、これを根拠に誠実に答える。
| 不要である可能性が高い人 | 理由 |
|---|---|
| ChatGPT Projects / Claude Projectsで作業が完結する人 | 単一surfaceで足りるなら、aachatは新しいlayerが増えるだけになる |
| Notion / Google Docsの正本運用が既に回っている人 | 文書管理単体では既存docs suiteが強い。二重管理になりやすい |
| GitHub Issues / PRs / Linearでcoding workが管理できている人 | issue・PR・CIに載る仕事は既存のwork surfaceが強い |
| CLAUDE.md / Cursor rules / local Markdownで十分なpower user | 軽量なMarkdown運用でhandoffが回っているなら、aachatのproject modelは過剰に見える。ただし複数agent・複数surface・人間との役割分担が増えると、正本がどれか・判断がどこにあるかをMarkdown運用だけで維持するのは難しくなる。そうなったときがaachatの出番である |
| 単一agent・低頻度handoffの人 | 引き継ぎが週1〜2回で実害も小さいなら、既存ツールで十分である |
| enterprise compliance（SSO / SOC2等）を購入条件にする組織 | 現時点でこれらを言い切る証拠がない |
既存ツールとの比較軸
比較の土俵は機能数ではない。次の軸で見る。
- agentの仕事がchat logに消えるか、company assetsになるか。
- 成果物が単に保存されるだけか、次のagent sessionと人間のhandoffの入力になるか。
- 既存のAI toolsを置き換えるのか、それらが参加できるcompany workspaceを作るのか。aachatはChatGPT・Claude Code・Cursorを置き換えず、参加させる（
connected-repo.md）。 - 実行と調整の境界を誠実に説明できるか。aachatは「実行はあなたのマシンの上、調整はprojectの上」（
trust-boundary.md）。