Agentic Task System (ATS)

あなたが使っていないだけで、タスクマネージャーは最高のエージェントメモリーです。

ats は、すでに管理しているタスクシステム（TickTick、Taskmaster、Beads、Obsidian、Notion、GitHub、Airtable、Google、または複合アダプターを介した複数のシステム）に AI エージェントのコンテキストを保持するMCP サーバー兼 CLIです。出典情報を添えて関連するタスク、メモ、決定事項、手順書を取得し、アクティブなアダプターが書き込みに対応していれば、結果を元のシステムに書き戻すこともできます。Claude Code、Claude Desktop、Cursor、およびあらゆる MCP クライアントで動作します。

移行ではなく、アダプターです。 タスクアプリ、リポジトリ、保管庫は、引き続き信頼できる情報源です。ATS はそのソースを共通のタスク契約にマッピングします。任意のキャッシュやベクトルインデックスは検索を改善しますが、ユーザーが編集しなければならない第二の記録にはなりません。ATS はタスク優先です。タスクを軸とし、GitHub の issue や Notion の仕様書などの補足資料を、その背景となるコンテキストとして取得します。

タスクとナレッジグラフの二層構造を、ひとつの CLI で。 タスク層は意図的にレコードベースになっています。各エントリーはひとつのバックエンドのプロジェクトやフィールドに属し、そのバックエンドが信頼できる情報源であり続けます。しかし、レコードベースの層では、エージェントが蓄積するもうひとつのもの、つまりあらゆるソースから、さまざまな対象について、ひとつの場所に書き込まれる永続的な知識を構造上保持できません。ナレッジグラフ層の**ats kg**（kg は knowledge graph の略）は、まさにその課題に対する ATS の答えです。出典情報と時間的な有効性を備えた、主語・述語・目的語の事実を、エージェントがどこからでも（通話、タスク、リポジトリ、チャットから）提案し、人間が承認し、周囲の作業がどのバックエンドにあるかにかかわらず、ひとつの場所で検索できます。組み込みストアは、依存関係のない組み込み型です。専用のグラフエンジンには、**グラフデータベースサーバーとしてGraphiti、組み込み型グラフデータベースとしてLadybugDB**を組み合わせることを推奨します。ats kg export --cypher は LadybugDB で読み込み可能なスクリプトを出力し（サーバーエンジンには --dialect neo4j|falkordb を指定でき、再実行可能です）、ats kg export --graphiti は Graphiti の取り込みパイプライン向けに出典記録を含むエピソード JSONL を出力します。

npm install -g @reneza/ats-cli @reneza/ats-adapter-ticktick
ats config use ticktick
ats auth login
ats find "deployment runbook"

GitHub + Notion + TickTickを横断するひとつのats find。ATS は利用可能な検索ブランチを RRF でランキングし、結果の出典情報を保持します。

## アーキテクチャと信頼境界

ATS は、信頼できる正本と、その周囲の検索機構を分離します。

AI client or operator
        |
        | local stdio, or token-gated HTTP when self-hosted
        v
ATS CLI / MCP server
        |
        +-- Core: task contract, links, lifecycle, ledger, events
        +-- Retrieval: keyword + native + optional dense branches -> RRF
        |
        v
Adapter boundary (auth, mapping, reads, patch-style writes)
        |
        +-- TickTick / Notion / GitHub / Airtable / Google
        +-- Obsidian / Taskmaster / Beads / OKF files
        |
        +-- derived retrieval state
            corpus cache + optional Qdrant/Ollama index

• バックエンドが引き続き正本です。 ATS は、重複するメモリデータベースをユーザーに編集させることはありません。書き込みはアクティブなアダプターを通じて行われ、アダプターがバックエンド固有の認証、フィールドマッピング、ディープリンクを管理します。
• 検索状態は正本ではなく、派生データです。 Core はデフォルトでコーパスを5分間キャッシュします。密ベクトル検索は任意です。アダプターは埋め込みを提供でき、TickTick のリファレンスアダプターは Qdrant と Ollama を利用できます。ベクトルがなくても、キーワード検索とアダプター固有の検索ブランチは引き続き実行されます。
• 認証情報はアダプター境界内にとどまります。 複合アダプターは各子アダプターに認証を委任し、ソース間で共有する追加の認証情報は保持しません。ただし、各子アダプターは同じ ATS プロセス内で実行されます。これはルーティングの分離であり、プロセスの分離ではありません。ローカル stdio は MCP ポートを公開しません。ホスト型ブループリントでは、ベアラートークンゲートウェイ、プライベートな Qdrant／Ollama サービス、および任意のオペレーターデッキ用の独立したパブリックデモバックエンドが追加されます。
• Core は検知可能な障害を報告します。 検索ブランチと最上位の複合コーパスの障害は、degraded と warnings を返します。アダプターのフォールバック内部で既知の情報が欠落する経路については、トレードオフと制限で説明しています。
• 状態の変更は追跡可能です。 結果にはソースの出所情報が含まれます。find --explain では RRF の寄与を確認でき、書き込みにはパッチセマンティクスが適用されます。また、対応する書き込みでは、取り消し用に変更前の状態を保持できます。

コーパスキャッシュにはタスクレコード全体が含まれる場合があり、クエリログには検索テキストが含まれます。アクション台帳には書き込み前の状態が含まれる場合があり、Qdrant のペイロードには埋め込みに加えてタスクテキストやメタデータが含まれる場合があります。ATS は、これらのコピーに対してアプリケーションレベルの暗号化や実行時の秘匿化を行いません。基盤となるタスクシステムの機密性に応じて、ホストへのアクセス、バックアップ、保持期間、デプロイ先を設定してください。詳しい動作については、検索、状態の整合性、デプロイガイドを参照してください。

デプロイ方法

モード	検索	信頼境界と運用境界
ローカル stdio	デフォルトではキーワード検索とネイティブ検索を使用します。密ベクトル検索を使うのは、アダプターが提供している場合のみです。	MCP エンドポイントはネットワークに公開されません。アダプターの呼び出し先はソースシステムに到達する場合があります。認証情報とキャッシュファイルは ATS を実行するマシンに保持されます。
複合アダプター	子アダプターのコーパスを結合し、Core がキーワード検索ブランチと、統合したネイティブ検索ブランチを順位付けします。利用可能なブランチ間では RRF を使用します。複合アダプターは現在、子アダプターのベクトル検索を公開しません。	各子アダプターが認証とマッピングを管理しますが、同じ ATS プロセス内で実行されます。最上位の子コーパスで障害が発生した場合は degraded として報告されます。既知のフォールバックの不足については、以下を参照してください。
ホスト型ブループリント	キーワード検索とネイティブ検索に加え、プライベートな Qdrant／Ollama サービスを使用します。	ベアラートークンを使う MCP ゲートウェイと、任意のオペレーターデッキ用バックエンドはパブリックに公開されます。Qdrant と Ollama はプライベートなサービスネットワーク内にとどまります。Qdrant／Ollama にはディスクが割り当てられますが、ats-mcp の実行時ファイルはデフォルトで一時的です。トークンのローテーション、永続化、バックアップ、可用性、ホスティングコストは運用者が管理します。

「移行なし」とは、2つ目の正本を作らないという意味です。派生データを一切保存しないという意味ではありません。

比較

アプローチ	正式な記録	追加の状態	検索
CLAUDE.md / メモリファイル	エージェント用に管理される Markdown	ファイル自体	ファイル全体、またはハーネス固有の検索
独立したメモリサービス	エージェント固有のデータベース	維持が必要なコーパスと取り込み経路	製品固有
通常のバックエンドコネクター	ソースとなるタスクアプリ、リポジトリ、またはボルト	通常、コネクターの状態以外はなし	直接取得、またはバックエンド標準の検索
ATS	ソースとなるタスクアプリ、リポジトリ、またはボルト	キャッシュ、クエリ／アクション／イベントの状態。任意の派生ベクトルインデックス	キーワード検索＋ネイティブ検索＋任意の高密度検索、RRF、出典情報、型付きコンテキスト

運用コンテキストがすでにタスクシステムや接続された業務ツールにあり、エージェントがそれらを横断して順位付けされた追跡可能な検索を必要とする場合、ATS は適しています。整理された Markdown がすでに完全な信頼できる情報源であり、ファイル全体の読み込み量が少ないままであれば、ファイル中心のワークフローのほうがシンプルな場合があります。

得られるもの

• 双方向のバス。 エージェントはアダプターが提供するタスクフィールドを読み取り、アダプターが書き込みに対応している場合は、結果を確認できる場所に書き戻します。
• 初回取得の関連性。 キーワード検索やアダプター固有の検索、利用可能な場合は高密度検索といった、機能に応じた分岐を出典情報とともにRRFで統合し、検索と絞り込みの繰り返しを減らします。すべての find は分岐間の一致度に基づく信頼度判定を返し（対応するゲートは --min-sources N）、--project で対象を単一プロジェクトに限定できます。古くなったコーパスキャッシュはバックグラウンドで更新される間も即座に応答し、完全一致する項目がない場合（notes find、search、get）は何も返さずに終わるのではなく、最も近い項目を返します。
• 再試行や同時実行にも耐える書き込み。 update --append / --prepend は既存の本文に追加します。--if-match <contentHash> は本文が変更されていない場合にのみ適用されます。create --if-absent と --idempotency-key を使うと、再試行された作成リクエストは最初のリクエストで生成されたものを返します。共有HTTPリクエストには期限があり、キャンセルにも対応します。読み取りは一時的な失敗時に再試行しますが、変更操作は明示的なレート制限による拒否の場合にのみ再試行するため、結果が不確かな失敗でも書き込みを再実行しません。
• 永続的な型付きリンク。 あるエージェントが decision / depends-on / output / supersedes リンクを追加すると、後から新しいコンテキストで作業するエージェントが ats context を通じて受け取れます。引き継ぎ情報はチャットログではなく、タスクアプリに保存されます。
• 実行コンテキスト。 ats intent は成果／理由／完了条件を記録します。ats lifecycle は古いコンテキストが現在の作業に影響しないようにします。ats security は連携するクライアント向けに対象を限定した許可／拒否の判断を記録します。ats ledger はエージェントが行ったこととタスクが進展したかどうかを記録します。ats promote は調査段階の内容を確定した目標に変換します。ats hierarchy evaluate はローカルの作業が引き続き親タスクを支えているか確認します。
• 範囲を限定したイベント。 ats events watch --json は決定論的な task.created/updated/completed/... NDJSONを出力します。保留／確認応答からの復旧に対応し、安定した重複排除IDとともに、パーミッション 0600 でスプールに保存されます。ATSが出力するのは観測結果のみです。利用側は動作する前に、意図、有効性、セキュリティを評価する必要があります。
• エージェント向けタスクグラフ。 タスクは自由形式のメモリテキストではなく、証明、書き戻し、レビュー、ライフサイクル、リンクのエッジを持つ構造化ノードになります。詳しくは docs/task-graph-for-agents.md をご覧ください。
• ファクトレイヤー。 ats kg はタスクとともに、永続的な主語–述語–目的語の知識を保持します。エージェントはファクトを提案し（トリプル1件、または --file を使ったJSONLバッチ）、人間が承認します（唯一の書き込み経路）。ats kg ask は決定論的な語彙スコアリング、信頼度判定、完全な出典情報を使って回答します。LLMもグラフサーバーも不要で、ats state export と一緒に持ち運べる追記専用ファイルを使用します。何かがステージングされる前にゲートが判定します。重複は何もしません。矛盾には --supersedes または --additive が必要です。レビュー担当者が却下したファクトには --acknowledge-rejected が必要です（終了コード4）。ats kg pending を使うと、レビュー担当者は各提案がどのような変更を行うか確認できます。撤回と置き換えではファクトを削除せず、有効期間を終了します。--as-of はその時点でストアが何を信じていたかを回答し、ats kg history はファクトの履歴を示します。ats kg nodes はストアが誰について何を知っているかを示し、ats context はタスクに関するファクトを引き継ぎます。--semantic はオプトイン可能な高密度検索の分岐としてアダプターの埋め込みモデルを追加し、ats kg export はLadybugDB/Kùzu、Neo4j、FalkorDB、Graphitiに対応します。
• セッションインデックスによる引き継ぎ。 コーディングエージェントのセッションブラウザーは生のトランスクリプト分析を保持しつつ、ATSはタスクに紐づく永続的な要約を保存できます。詳しくは docs/agent-session-index.md をご覧ください。 ATS が管理する実行メタデータはタスク本文にエンコードできます。型付きリンクは ## Related に、参照したソースは ## References に記載します。管理用ヘルパーは、人が作成した行やリンクを保持するように設計されています。update --content は本文全体を置き換えるため、本文に内容を追加する場合は --append ／ --prepend を使い、読み取った contentHash を --if-match に指定して、結果を確認してください。npm run prove:intent は、実行コンテキストの経路を決定論的な合成データで検証します。

信頼性の高い自動化や鮮度を保つワークフローについては、CLI の信頼性をご覧ください。スコープ付きページネーション、上限を設けたリクエスト、ペイロードにひも付いた再試行／再開キー、レビュー済みの事実確認について説明しています。

アダプターに依存しない最小限のワークフロー

1. アダプターを選択して検証します： ats config use <adapter> を実行し、README の説明に従って認証した後、ats doctor を実行します。
2. 作業対象を取得します： ats find "deployment runbook" --json を実行すると、そのアダプターから利用できるブランチが順位付けされ、出所情報も保持されます。
3. 信頼できる項目とそのコンテキストを確認します： ats context <project> <task> は共通のアダプター契約を使用するため、アダプター固有のメモレイヤーは必要ありません。
4. 永続的な実行コンテキストを追加します： ats intent set <project> <task> --outcome "..." --done-when "a,b" と ats link add <src-project> <src-task> <dst-project> <dst-task> --type depends-on を実行します。
5. 組み立てた引き継ぎを検証します： ats context <project> <task> を再実行し、リンクされた決定、依存関係、証明、ライフサイクルの状態、関連する検索結果を読み戻します。
6. アダプターまたはソースアプリから書き込み、読み戻します。 次のエージェントがチャットだけの引き継ぎではなく、永続的な状態を受け取れるよう、信頼できるバックエンドを最新の状態に保ってください。

自分でデプロイする

オプションのオペレーターデッキは、Cloudflare Pages にデプロイできる、スマートフォン向けの静的ウェブアプリです。付属の Render ブループリントは、MCP ゲートウェイ／サーバーに加えて、プライベートな Qdrant および Ollama サービスをビルドします。

デプロイ後、ats-mcp サービスの Environment タブから自動生成された ATS_MCP_TOKEN をコピーし、ヘッダー Authorization: Bearer <ATS_MCP_TOKEN> を指定して、MCP クライアントから https://<your-mcp-url>/mcp に接続します。実際のタスクを読み取るには、TICKTICK_ACCESS_TOKEN を設定してください。自分のマシンや VPS を使いたい場合も、通常の Docker コンテナと同じ構成で利用できます。デプロイガイドをご覧ください。

利用可能なアダプター

バックエンドコネクターを使うと、エージェントは Notion、GitHub、タスク管理システムにアクセスできますが、アクセスできるだけでは、「認証移行について何がわかっているか」といった質問に対する、ランク付けされた回答をひとつ提示できません。ATS は共通の検索レイヤーを追加します。複合アダプター は、インストール済みの子コーパスを結合し、プロジェクト ID に名前空間を割り当て、サポートされているネイティブ検索の結果を統合します。また、Core が出典情報とともに利用可能な分岐をランク付けできるようにします。各子アダプターはそれぞれの認証情報を読み取りますが、設定されたすべての子アダプターは同じ ATS プロセス内で実行されます。

アダプター	信頼できる情報源	検索または書き込みに関する補足
ticktick	TickTick OpenAPI v1	ベクトルなしでもキーワード検索／ネイティブ検索を利用できます。オプションの Qdrant + Ollama により、密検索を追加できます。
obsidian	ローカルの Markdown 保管庫	ファイルネイティブなパッチ形式の書き込みにより、不明なフロントマターを保持します。
okf	Open Knowledge Format の Markdown バンドル	ローカルバンドルです。
taskmaster	ローカルの .taskmaster/tasks/tasks.json	リポジトリ内のタスク状態です。
beads	bd --json を介したリポジトリ内の Beads	依存関係を考慮したローカルのタスク状態です。
airtable	Airtable REST API（テーブル = プロジェクト）	アダプターごとにスコープされた API アクセスです。
google	Google Sheets / Docs / Slides	読み取り専用です。
notion	Notion のデータベース + ページ	インテグレーションごとにスコープされたアクセスです。
github	GitHub の issue + ディスカッション	リポジトリごとにスコープされたアクセスです。
composite	インストール済みの子バックエンド	子コーパスを結合し、プロジェクト ID に名前空間を割り当て、ネイティブ検索のヒットを統合して、書き込みをルーティングします。独立したレコードストアではなく、現時点では子アダプターの埋め込みを公開していません。
things / apple-notes / google-tasks	—	要望のみで、未実装です。

アダプターごとの認証とマッピングについては、各パッケージの README を参照してください。PR を歓迎します。次の手順でスキャフォールドを作成し、コントラクトに照らして検証してください。

ats adapter new linear              # writes a contract-complete skeleton
ats adapter test ./ats-adapter-linear   # pass/fail/skip per contract check

各リポジトリでの Beads の使用

.beads を含むリポジトリ内で ATS を実行してください。そのディレクトリ名がデフォルトのプロジェクト ID になります。別のリポジトリを明示的に指定するには、そのコマンドに対してルートとプロジェクト ID を設定します。

cd /path/to/my-repo
ats config use beads
export ATS_AGENT_ID=worker-a BEADS_ACTOR=worker-a
ats tasks ready --json
ats update my-repo ISSUE --claim
ats link add my-repo ISSUE my-repo PREREQUISITE --type depends-on --native --dry-run

ATS_AGENT_ID と BEADS_ACTOR には同じワーカー名を使用してください。Beads は、claim 済み issue の完了時にも、claim したアクターを再確認します。

別のディレクトリからは、ATS_ADAPTER=@reneza/ats-adapter-beads ATS_BEADS_ROOT=/path/to/my-repo ATS_BEADS_PROJECT_ID=my-repo ats tasks ready --json を使用します。準備完了のタスクは名前付きの RRF 分岐に反映されます。claim とネイティブな依存関係の書き込みには、既存のレビューゲートが適用されます。ワーカー ID、依存関係の意味、実際の CLI による検証については、Beads アダプターガイドを参照してください。

トレードオフと制限事項

• 鮮度はアダプターに依存します。 Core のコーパスキャッシュのデフォルト TTL は 5 分です。バックエンドの同期動作、ページネーション、完了済み作業を含めるかどうかはアダプターによって異なります。ATS は、あらゆるケースでリアルタイムに読み取れることを保証しません。ats cache sync は必要に応じてキャッシュを更新します（cron からの実行に適しています）。アダプターが bulkFetchDelta() を実装している場合は差分更新し、それ以外の場合は全件を再取得します。
• 高密度検索にはインフラストラクチャが追加で必要です。 Qdrant と Ollama はセマンティックな再現率を高める可能性がありますが、インデックス作成、永続化、リソース、バックアップの作業が増えます。ベクトルを利用できない場合でも、ベースラインの find はキーワード検索やネイティブ検索の結果を返します。ただし、ベクトル検索の分岐を試みると、応答が劣化することがあります。ベクトル検索のみを行う hybrid と similar の各操作には、引き続きそのインフラストラクチャが必要です。
• 共通の契約は意図的に小さくしています。 アダプターインターフェースには 6 つのストレージメソッドと認証ライフサイクルフックが定義されていますが、実際の書き込み対応範囲、より豊富なフィールド、ネイティブ検索の対応状況は異なります。バックエンド間で同等の機能があると想定する前に、アダプターの README を確認してください。
• 劣化した結果も部分的な結果にすぎません。 ATS は、Core の分岐で失敗またはタイムアウトしたもの、複合フォールバック取得内のプロジェクト単位の失敗や TickTick のプロジェクト取得失敗を含む、取り込めなかったコーパスソース、そしてバックエンドが読み取れなかったネイティブ検索ソースを報告します。部分的なコンテキストを許容できるかどうかは、引き続き呼び出し元が判断する必要があります。warnings は不足しているものを示しますが、それが重要かどうかまでは示しません。
• 複合検索はセマンティックな重複排除ではありません。 ats dedup は独立した分析コマンドです。統合時の識別子はバックエンドごとに名前空間が分かれている（<backend>:<taskId>）ため、異なるバックエンドに同一の生 ID があっても別々の結果として扱われます。セマンティックに重複するタスクも、リンクするまでは別々に表示されます。
• ホスト型ブループリントは参照用のデプロイ構成であり、マネージドサービスではありません。 1 つのベアラートークンで MCP ツール全体を利用できます。ブループリントはユーザー単位またはツール単位のスコープ、マルチテナント RBAC、高可用性、SLA を提供しません。
• ホスト型 ATS のランタイム状態は、デフォルトでは一時的です。 ブループリントは Qdrant と Ollama のデータを永続化しますが、ats-mcp 用のディスクはマウントしません。そのため、キャッシュ、クエリログ、アクション台帳と取り消し用の変更前イメージ、イベントスプール、ベクトル同期メタデータは、再起動または再デプロイ時に失われます。
• イベントは観測情報であり、認可ではありません。 ats events watch はタスクの変更を報告できますが、外部アクションを実行する前に、コンシューマーが意図、有効性、セキュリティを評価する必要があります。
• ファクトレイヤーはデフォルトでは字句ベースで、人間による承認が必要です。 ats kg ask は、出典情報と信頼度判定を伴う決定論的なキーワードスコアリングです。--semantic を指定すると、オプトイン方式の高密度検索分岐として、アクティブなアダプターの埋め込みモデルを追加します。そのためには埋め込みモデルが必要です。人間の承認なしにファクトストアへ追加されるものはありません。エージェントからの提案が一度に大量に届いた場合、設計上、レビュー待ちになります。また、重複、矛盾、または却下済みファクトの繰り返しは、その旨を示さずにレビューキューへ追加されることはありません。
• ATS のポリシーはサンドボックスではありません。 CLI は、宣言された承認メタデータを適用します。つまり、対象の intent.approvalRequired が設定されている書き込み、またはアクションが security.approvalRequiredFor に列挙されている書き込みは、バックエンドに到達せず ats review に送られます（ATS_REVIEW_ALL=1 を設定すると、すべての書き込みが対象になります）。ただし、これは ATS 独自の書き込み経路のみを保護します。ats security check は、連携するクライアントが判断を行うアプリケーションレベルのチェックポイントのままです。また、ATS の外部におけるシェル、ファイルシステム、ネットワーク、モデル、シークレットへのアクセスは、ここではいずれも傍受されません。アダプターを直接呼び出すクライアントは、CLI のゲートを回避します。

検証と運用上の証拠

50問の合成リコールベンチマークでは、 同一のメモリーとクエリを使って、ATS と Engram v2.2.1 を比較しています。

検索経路	Recall@5
ATS のキーワードのみ	12/50 (24%)
ATS のローカルな dense + sparse、ハイブリッド RRF	47/50 (94%)
Engram SQLite FTS5、デフォルトの all	20/50 (40%)
Engram SQLite FTS5、any	32/50 (64%)

Engram と ATS のハイブリッド検索は、完全一致するタイトルと簡潔なクエリの対象をすべて想起しました。 この小規模な作者作成のテストデータは、10個の異なる意思決定メモリーに対する自然な質問をそのままテストするものであり、製品全体の優位性を示すものではありません。ハイブリッド検索の結果にはローカル埋め込みが必要ですが、ベクトルデータベースやホスト型モデルのキーは不要です。データセット、生の出力、失敗例、再現手順は上記にリンクされています。

• CI は Node 20 と 22 でリポジトリ全体のチェックを実行します。リンティング、公開時のクレームチェック、PII チェック、ユニットテスト、アダプターとインテントの検証、進捗ベンチマークが含まれます。
• 公開安全性ゲートは、リポジトリの対象範囲と npm パッケージの tarball の両方をスキャンし、シークレット、個人用パス、設定済みの個人データパターン、ローカルで設定された拒否リストの用語を検出します。これは公開対象を保護するものです。実行時には、複合アダプターで設定済みの墨消しパターンを用いてバックエンドごとの信頼レベルをさらに適用できます。パターンに一致する書き込みが "trust": "public" の子にルーティングされた場合、ブロックされ、黙って削除されることはありません（複合アダプターの README を参照）。このチェックが保護するのは ATS 独自の複合書き込み経路であり、汎用的なデータ損失防止ではありません。
• 状態整合性テストと規約では、パッチ形式の書き込み、未知のフィールドの保持、ストアから Task への明示的なマッピング、結果の出所、説明可能な RRF の寄与を扱っています。
• 検索動作では、Core の分岐、コーパスキャッシュ、時間予算、分岐の障害時の適切な処理、使用状況のログ記録、レイテンシに影響する要因を説明しています。

これらのチェックはリポジトリの動作を検証するものであり、本番環境での可用性やセキュリティを認定するものではありません。

CLI の仕様

# Lifecycle
ats init [adapter]                  # select an adapter and run a health check
ats config use <adapter>            # switch the active adapter
ats auth login                      # delegate login to the active adapter
ats doctor                          # inspect adapter and service health

# Retrieval  (any read command takes --json for piping to jq / agents)
ats find <query> [--explain]       # parallel + RRF + provenance + confidence verdict — DEFAULT
ats find <query> --project <id|name>   # bind retrieval to a project (--projects a,b for several)
ats find <query> --min-sources 2   # keep only results two branches agree on
ats find <query> --fresh           # refresh a stale corpus cache before answering
ats open <project> <task>          # open any adapter item by explicit ids
ats context <project> <task>       # task + valid linked/retrieved context
ats link list <project> <task>     # list portable typed links
ats hybrid <query>                 # dense+sparse retrieval when embeddings exist
ats similar <id>                   # related items when embeddings exist

# Notes-layer shortcuts (currently TickTick and Obsidian)
ats get <id-or-title> [--extract raw|json|yaml]
ats url <id-or-title>              # paste-ready note cross-reference
ats links <project> <task>         # resolve deep-links in a note body

# Authoring
ats create "<title>" [--content ..][--project <id>]
ats create <project> "<title>" --if-absent --idempotency-key <k>   # never a duplicate on retry
ats update <project> <task> [--content ..][--title ..]
ats update <project> <task> --append "- 2026-09-05: shipped" --if-match <contentHash>   # add to the body; write only if unchanged

# Agent execution context (portable across adapters)
ats intent set <project> <task> --outcome ".." --done-when "a,b"
ats promote <src-proj> <src-task> <target-proj> --outcome ".." --done-when "a,b"
ats hierarchy set <project> <task> --kind task
ats hierarchy evaluate <project> <task>
ats lifecycle set <project> <task> --status active --valid-until 2026-12-31
ats link add <src-proj> <src-task> <dst-proj> <dst-task> --type decision --dry-run --explain
ats graph <project> <task> --depth 3 --max-nodes 500
ats context <project> <task>
ats snapshot <project> <task> --depth 3 --max-nodes 500  # content-addressed context with completeness
ats history <project> <task>                   # revisions and field-level changes
ats history <project> <task> --restore <revision> --dry-run

# Facts layer (proposed by agents, ratified by you)
ats kg propose "Acme GmbH" "prefers" "invoices as PDF" --domain sales --source "call 2026-08-01"
ats kg propose "Acme GmbH" "prefers" "invoices as XML" --domain sales --supersedes <fact-id>  # replaces, in one ratification
ats kg propose --file facts.jsonl --domain sales   # one JSON object per line, every line through the gate
ats kg propose "Acme GmbH" "signed" "renewal" --source task://<project>/<task> --tier action-record
ats kg pending                                     # what each queued proposal would do to the graph
ats review approve <id> && ats kg ratify --all     # approval comes from someone other than the proposer
ats kg verify                                      # recheck every fact's source; exit 2 when one is gone or changed
ats kg ask "what does Acme prefer" --domain sales --json            # + confidence.verdict
ats kg ask "what does Acme prefer" --domain sales --as-of 2026-06-30 # what the store believed then
ats kg ask "invoices" --center "Acme GmbH" --semantic               # anchored on one entity, embedder-backed
ats kg nodes acme                                  # what the store knows about whom
ats kg history <fact-id>                           # events and supersession chain
ats kg export --cypher > facts.cypher      # load into LadybugDB / Kùzu, full provenance on every fact
ats kg export --dialect falkordb           # openCypher for FalkorDB / Neo4j, re-runnable
ats kg export --graphiti > episodes.jsonl  # Graphiti episodes with the provenance record
ats kg export --cypher --include-retracted # closed facts too, with tInvalid and who closed them
ats ledger record <project> <task> --action release.verified --advanced true
ats ledger list --actor-kind agent --session <id>   # who acted, agent or human, in which session
ats ledger verify                                   # hash-chained ledger; prints head for --expect-head
ats security set <project> <task> --trust trusted --allow-actions read --allow-resources task:self
ats security check <project> <task> --action read --resource task:self --reason "load context"
ats events watch --json            # NDJSON observations; never launches agents

# Ops
ats create --input task.json --dry-run       # strict JSON file, or --input - for stdin
ats batch changes.jsonl --dry-run             # validate a mutation batch
ats batch changes.jsonl --journal run.jsonl   # apply and resume by stable item id
ats state doctor                              # validate local schemas and file permissions
ats state import bundle.json --force --dry-run
ats auth status --non-interactive             # bounded to 15s; override with --timeout-ms
ats tasks completed 30 --projects <id> --require-complete   # every completion in the window, paged
ats review list                 # writes staged by approvalRequired targets
ats review approve ID && ats review apply --all
ats cache sync                  # refresh the corpus cache (find also refreshes a stale one in the background)
ats cache status                # age, stale / servable / revalidating
ats bench run
ats bench score
ats bench progress --json
ats bench analyze-usage --days 7
npm run prove:intent
npm run prove:taskmaster
npm run prove:beads
npm run prove:progress

レビュー済みタスクの書き込みでは、承認をステージ済みの正確なペイロードに紐付け、適用前に現在のタスクのリビジョンを確認します。項目を取得できるプロセスは一度に1つだけです。適用が中断された場合は、ats review list --all を確認してください。applying または failed の項目は、提案を新たにステージングする前にバックエンドを確認する必要があります。ペイロードダイジェストのない古い承認も、再度ステージングして承認する必要があります。

完全な読み取りが必要な自動化では、ats find QUERY --require-complete --fresh --json を使用してください。古い結果、機能低下した結果、または明示的に不完全な結果は JSON 出力を維持し、終了コード 2 を返します。通常の読み取りでは、従来の寛容な終了動作が維持されます。Doctor でも同じ厳格なオプションをサポートし、各プローブに制限時間を設けます。ats doctor --timeout-ms 1000 --require-complete --json を実行してください。 状態のインポートでは、--dry-run を指定した場合も、ファイルを書き込む前に認識可能なファイル内容と、指定されているチェックサムを検証します。

あらゆる MCP クライアント（Claude Code、Claude Desktop、Cursor、Windsurf、OpenCode）から利用する

@reneza/ats-mcp は、取得、CRUD、実行コンテキストにわたるツールセットとして、アクティブなアダプターを公開します（find、get_task、create_task、set_task_intent、add_task_link、resolve_task_links、context_for_task、record_action、undo_write、poll_task_events など）。Claude Code では、タスクシステムを信頼できる唯一の情報源として維持しながら、セッション間で永続的なコンテキストを提供します。オプションのキャッシュとベクトルインデックスは、引き続き派生した取得状態として扱われます。

ATS は stdio 経由で MCP を使用するため、stdio MCP サーバーを起動できるクライアントであれば、どれでも動作します。異なるのは設定ファイルとラッパーキーだけです。バイナリ（ats-mcp）と ATS_ADAPTER 環境変数は、どこでも同じです。

クライアント	設定ファイルの場所	ラッパーキー
Claude Code	claude mcp add（下記）	該当なし
Claude Desktop	claude_desktop_config.json	mcpServers
Cursor	~/.cursor/mcp.json	mcpServers
Windsurf	~/.codeium/windsurf/mcp_config.json	mcpServers
OpenCode	opencode.json	mcp（形式は異なります。下記参照）

# Claude Code
claude mcp add ats -e ATS_ADAPTER=@reneza/ats-adapter-ticktick -- ats-mcp

// Claude Desktop / Cursor / Windsurf — identical `mcpServers` shape
{
  "mcpServers": {
    "ats": { "command": "ats-mcp", "env": { "ATS_ADAPTER": "@reneza/ats-adapter-ticktick" } }
  }
}

// OpenCode (opencode.json) — local stdio server, note `command` is an array
{
  "mcp": {
    "ats": {
      "type": "local",
      "command": ["ats-mcp"],
      "environment": { "ATS_ADAPTER": "@reneza/ats-adapter-ticktick" },
      "enabled": true
    }
  }
}

まずバイナリを PATH にインストールするか（npm i -g @reneza/ats-cli）、クライアントがシェルの PATH を継承しない場合は ats-mcp の絶対パスを使用してください。

規約

• Wiki プロジェクト。 指定されたプロジェクト（デフォルトは Permanent Notes）に永続的なナレッジを保存し、その他のプロジェクトには一時的なタスクを保存します。
• エージェントデータノート = 本文にフェンス付きの json / yaml ブロックを含むノート。ats get <title> --extract json で抽出します。
• 相互参照 = アダプター標準のディープリンクです。ats url <title> で生成し、手書きしないでください。
• 完全なパターンについては、docs/wiki-conventions.md を参照してください。

状態の整合性

ATS は、人が作成したフィールドを保持するため、管理対象メタデータの書き換えをテストし、ストアから Task への明示的なマッピングを必須とし、結果の出所情報（sources、find --explain）を保持します。カバレッジと生の更新の動作は、引き続きアダプターごとに異なります。公開安全性ゲート（check-no-pii.mjs）は、リポジトリまたはパッケージ内で対象となる個人データのパターンが見つかった場合、ビルドを失敗させます。詳細については、docs/state-integrity.md を参照してください。

エージェント側の運用モデルについては、docs/task-graph-for-agents.md を参照してください。タスクのテキストは人向けの表現ですが、実行レイヤーには構造化されたリンク、証明コマンド、レビュー要件、書き戻し先が必要です。

ATS の開発

貢献を歓迎します。バグ修正、特に packages/adapter-* への新しいアダプターの追加をお待ちしています。 開発環境のセットアップとアダプターパターンについては CONTRIBUTING.md を、リポジトリ上でコーディングエージェントを動かす場合は AGENTS.md を参照してください。ソースを扱う際、 pi-codegraph は、モノレポの呼び出しグラフをエージェントに提供します。アダプターパターンとコア変更の影響範囲が分かるため、各セッションでツリー全体を読み直さずに済みます。

リリースとライセンス

v0.17.0 では、ブロッカーを考慮した Beads の実行可能タスク取得、名前付きアトミッククレーム、ネイティブな依存関係の書き込み、実際の CLI 並行性チェックが追加されました。また、名前を指定した取り消し対象の選択を修正し、互換性のある依存関係を更新しました。全履歴については、CHANGELOG.md を参照してください。

MIT。詳細は LICENSE を参照してください。

ATS が役に立った場合は、⭐ を付けることをご検討ください。他の人が見つけやすくなります。