Agent Task Journalの保存と書き出し（開発中）
概要
Portal 0.36.1では保存知識の参照だけを本番で先行提供しています。このページのTask Journal作成・更新・引き継ぎは、引き続きローカル開発版の検証範囲です。保存知識の端末登録でJournalの権限を自動追加しません。
現在開発中です。 2026年10月16日に確認したローカル開発版の機能で、配布済みPRO 0.35.20やPortal 0.36.0の正式機能ではありません。専用の開発用補助アプリを起動すると、AIの作業目的、進行状態、根拠、実施結果、残作業をTaskごとに記録できます。
作業一覧・詳細・エージェントの履歴は、ローカルの AI Workspace → Task Journal で確認します。「開始・再開する」「中断する」「完了にする」で状態を更新できます。MCPのTask IDから、別のエージェントも同じ作業を読み出せます。
利用条件
新しいMyMem画面の「公開中のProjectをPortalに登録」は、現在は保存知識の参照だけです。その登録からJournalの参照・更新が自動で許可されることはありません。Journalは以下の専用の登録・起動条件を使います。
開発版 mymem-mcp、登録済みのローカルMCPプロファイル、利用者が指定するProject IDが必要です。起動時に許可するProjectを固定し、書き込みは --allow-journal-write を付けた起動だけで許可します。提供プランは未確定です。Portalの作業一覧からも、公開した端末とProjectに限ってJournalを開けます。法令参照とJournal参照・更新は別々の許可です。
JournalはChromeのDuckDBとは別の、端末内の補助アプリ用フォルダーに保存します。user_id はこのPoCではローカルMCPのプロファイルIDです。PortalのアカウントIDとは別で、端末登録のprofileIdとProjectを使ってPortalの許可へ対応付けます。法令参照用OAuthの許可がJournalにも適用されるわけではありません。
使い方
作業記録を確認する
開発用補助アプリで次を実行し、表示された http://127.0.0.1:<ポート> を同じ端末で開きます。PROFILE_ID と PROJECT_ID は実際に許可する識別子に置き換えます。正式配布版にはこのサブコマンドはまだ含まれません。
mymem-mcp workspace-ui --profile PROFILE_ID --project PROJECT_ID --allow-journal-write
- 一覧で作業を選び、目的、制約、参照元、残作業を確認します。
- 履歴の「根拠付きの確認記録」「エージェントの推測・記録」「提案」を区別します。根拠付きもエージェントによる申告なので、引き継ぐときは参照元を確認します。
- 利用者として確定した判断は、詳細の「利用者として確定事項を記録」から入力します。MCPのエージェントはこの区分を直接追加できません。
- 他のエージェントが更新した場合は競合として止まります。作業を開き直し、現在の内容を確認してから操作します。
Portalで確認する
ローカル開発版の「Portal → MCP接続 → 確認用の画面 → 作業一覧」から、同じ正本をMCP経由で参照・更新できます。操作はAI Workspaceを確認してください。状態の開始・中断・完了は記録の変更で、AIを実際に起動・停止しません。
書き出す・復元する
画面左の「Journalを書き出す」で、許可ProjectのJSONを取得します。コマンドでも書き出せます。
mymem-mcp workspace-export --profile PROFILE_ID --project PROJECT_ID --output ./journal-export.json
mymem-mcp workspace-import --profile PROFILE_ID --project PROJECT_ID --allow-journal-write --input ./journal-export.json
復元は明示的なローカル操作です。同じローカルプロファイル・同じProjectのファイルだけを受け付け、既に存在するTask IDを上書きしません。復元先に同じTaskがあれば処理全体を拒否します。異なるPC・プロファイルへIDを変換して移す機能は未実装です。
Portalで調査・結果を保存する
Portalの作業一覧から、同じTaskへ調査記録、関連チケット、結果、残作業を保存できます。一連の操作を参照してください。正本・書き出しJSONのschema_version 1と各項目の型は維持します。
- 資料やチケットを「根拠候補」に追加した段階では、画面内の下書きです。保存すると
events[].evidenceの文字列配列へ、ID、ハッシュ、参照日時等と短い本文抜粋を記録します。新しい参照用テーブルやオブジェクト型には変換しません。根拠文字列の書式は表示用で、復元時に解釈・実行しません。 - 「今回分かったこと」は
events[].text、区分はclaimへ保存します。verified/inferred/proposedを区別し、verifiedには根拠を必要とします。Task.findingsのまとめとは別の履歴です。 - 関連付けは
related_issues、結果はresults、残作業・判断待ちはpending_itemsに保存します。外部チケットの投稿・更新はしません。
通常のMCP更新と同じ改訂チェックと操作ID台帳を使用します。既存のSQL参照・復元に新しい列や結合先は不要です。旧schema 1の記録も、従来の文字列配列としてそのまま読みます。
引き継ぎメモと復元用JSONの違い
「引き継ぎメモを作る」は、1つのTaskと取得した履歴からMarkdownを生成します。目的、制約、結果、残作業、関連チケット、記録の区分と根拠を載せます。履歴は10件ずつ取得し、改訂が途中で変わった場合は混在させません。全履歴を取得していなければ一部収録であることを明記します。
メモは画面のメモリ内で生成し、利用者の操作でコピーまたはmymem-task-<Task ID>-handoff.mdへ保存します。認証情報・操作ID台帳は含めず、復元には使えません。Portalの制御DBや通常ZIPへ追加しません。全文の保管・復元にはJournalの書き出しJSONを使います。
通常バックアップとの違い
| 保存物 | 内容 | 通常のバックアップZIP |
|---|---|---|
profiles/<profile>/workspace/journal.json | プロファイル内のTask、イベント、操作ID台帳の正本 | 含まれない |
journal.lock | 複数エージェントの更新を排他するためのファイル。作業本文を保存しない | 含まれない。復元対象にも不要 |
| Journalの書き出しJSON | 起動時に許可したProjectのTask・イベント・重複防止台帳 | 別ファイルとして保管する |
引き継ぎメモ .md | 1つのTaskの参照用メモ。履歴の収録範囲を表示し、復元には使わない | 含まれない |
通常の duckdb/*.duckdb | 従来の記憶・会話・Source・Skillなど | 従来どおり収録する |
Journalは通常ZIPの formatVersion: 6 を変更しません。既存DuckDBのテーブル・列・キー・インデックス・ビュー・復元対象も変更していません。古いZIPにJournalがないことは破損ではありません。通常ZIPの復元だけではJournalは復元できません。
JSONの構造
正本と書き出しJSONはどちらも schema_version: 1 です。正本の tasks と events はTask IDで引くオブジェクト、書き出しJSONでは各々配列です。未指定の配列項目は null の場合もあります。互いをそのまま置き換えず、復元コマンドを使います。復元ファイルの入力者や根拠を暗号的に証明する形式ではないため、自分が保管したファイルを使ってください。
| 項目 | 型と意味 | 画面・関係 |
|---|---|---|
tasks[].task_id | 文字列。Taskの一意なID | Task詳細・MCPのget/handoffの指定 |
user_id / project_id | 文字列。ローカルプロファイルと許可Project | 一覧・検索・書き出しの境界。別Projectを混ぜない |
title / goal / constraints | タイトル・目的の文字列、制約の文字列配列 | 作業一覧・詳細 |
status | planned / running / paused / blocked / completed / cancelled | 予定・進行中・中断中・確認待ち・完了・終了 |
related_issues | provider・connection_id・project_id・issue_id・任意URLの配列 | 接続ごとの元チケットとの対応。外部Project IDとローカルProject IDは別 |
agent_id | 最後に変更したエージェントの表示用ID | 詳細・引き継ぎ。認証済みクライアントの本人証明ではない |
findings / evidence / actions / results / pending_items | それぞれ文字列配列 | 調査・根拠・実施・結果・残作業。記録内容を自動で検証しない |
user_decisions | 利用者がローカル画面から入力した文字列配列 | 利用者の確定事項。通常のMCP更新からは指定できない |
revision | 1から始まる整数。更新ごとに増加 | 更新前のexpected_revisionと照合し、古い状態での更新を拒否 |
created_at / updated_at | UTCのISO日時文字列 | 一覧の最終更新・作業順序 |
events[] | event_id・task_id・agent_id・kind・claim・text・evidence・created_at | task_idでTaskへ結び付く履歴。claimはverified / inferred / proposed / user_decision |
operations | スコープとoperation_idをキーに、引数のSHA-256とTask ID・revision・削除状態の受領記録を保存 | 再送の二重記録を防ぐ。作業本文・資格情報は格納しない。復元でも保持する |
イベントは現在状態と分けて保存し、状態更新とそのイベント・重複防止台帳を一緒に確定します。Taskを削除すると、本文とイベントを正本から削除し、本文のない受領記録を保持します。以前に書き出したファイルや他のAIが保持するコピーは自動削除されません。
DuckDBで書き出しJSONを参照する例
Journal用のSQLテーブルは追加されていません。以下はDuckDBのJSON読み込み機能を使った参照例です。2026年10月16日にDuckDB 1.4.3と架空データの書き出しJSON（Task 3件・イベント8件）で実行し、件数とTask行の取得を確認しました。
SELECT schema_version, len(tasks) AS task_count, len(events) AS event_count
FROM read_json_auto('journal-export.json');
SELECT task.task_id, task.project_id, task.title, task.status, task.revision
FROM (
SELECT unnest(tasks) AS task
FROM read_json_auto('journal-export.json')
);
同日の一連の作業フロー後にも、架空の書き出しJSON（Task 5件・イベント12件）で上の2本を再実行しました。次のSQLでは、作成・更新・削除以外の記録4件を確認しました（根拠あり3件）。kindは表示区分であり、それだけで記録者や内容の正しさを証明しません。
SELECT event.task_id, event.claim, event.text, event.evidence
FROM (
SELECT unnest(events) AS event
FROM read_json_auto('journal-export.json')
)
WHERE event.kind NOT IN ('create', 'update', 'delete');
注意点
Journal正本は最大16MiB、操作ID台帳は最大50,000件です。上限に達した場合は更新を拒否し、古い記録を黙って削除しません。検索・履歴はページ単位で読み、大きい書き出しはCLIを使います。
未対応の schema_version や壊れた正本は上書きせず拒否します。Task削除や復元の前に必要な書き出しを保管してください。Journalファイルを実行中に手で編集しないでください。
旧Memory、Source、Skill、Timelineへ内容を自動転記する機能はありません。Project IDもこの段階では起動時の許可情報であり、既存Projectの自動登録・存在確認やDBの外部キー制約を追加していません。