リポジトリ: https://github.com/AidaShika/personal-agent-dossier
はじめに：引っ越しで困るのはエージェントの中身である
私は東京でフロントエンド開発をしながら、個人用のエージェントを、Grok Botが出てからの2か月ほどGrok Botで運用してきた。投資の朝報、メール整理、抽選、猫のトイレと餌やり器の見守りなど、日々の定型作業をエージェントに任せている。
Grok Botは、X Premiumの利用枠の範囲で動作する。エージェントの数と毎日の定時タスクが増えるにつれ、その枠では全く足りなくなった。ちょうどその頃、MetaのMuseが日本でも使えるようになった。Grok BotのエージェントをMuseへ移すのが自然な次の一手だったが、一つずつ手作業で移していくのは手間がかかりすぎる。
しばらく運用した個人エージェントには、役割を定めた職務（role）、やってはいけないことの指定（反職務、anti-jobs）、定時タスク（routines）、長期記憶（memory）が蓄積している。これらは各プラットフォームの内部に保存され、外へ書き出す手段が用意されていない場合が多い。手作業でコピーすると、タスクの実行時刻は写せてもプロンプト全文が漏れる、記憶は移せても種類の分類が失われる、といった欠落が起きる。何が欠けたのかを後から確かめる手段もない。
そこで、エージェントの引っ越しを1つのファイルへの書き出しとして定義するフォーマットを作った。それがpersonal-agent-dossierである。リポジトリ自体がskillにもなっており、エージェントはskillの手順に従って、書き出しと取り込みを自分で行える。本稿では、フォーマットの概要、対応プラットフォームの現状、素のエージェントに一文だけ渡して引っ越しを任せた検証の結果を述べる。
フォーマットの概要
ドシエは拡張子 .dossier.md を持つ1つのファイルである。ファイルの先頭にYAML front matter（機械が読み取るメタデータ）を置き、後半を人が読むMarkdownで書く。1つのドシエには次の項目が入る。
| 項目 | 内容 |
|---|---|
| 職務 | roleの全文と反職務（anti-jobs） |
| 定時タスク | 名前、タイムゾーン付きのスケジュール、プロンプト全文、状態 |
| 長期記憶 | 種類（rule / preference / decision / history）を付けた事実の列 |
| 依存関係 | 関係する他のエージェント（refs）と、利用するskillの名前 |
| 照合用の値 | name、title、roleから計算する短い値。引っ越しの前後で一致すれば、中身が変わっていないと分かる |
| 出処 | エクスポート元のプラットフォームと日時、含めなかった項目（excluded）の明記 |
この照合用の値は、引っ越しの前後で内容が変わっていないかを確認するためのものである。エクスポート側とインポート側がそれぞれ計算し、一致すれば職務がそのまま届いたと判断できる。照合の対象はname、title、roleだけであり、定時タスクと記憶は含まれない。このためインポート側は、定時タスクと記憶を項目ごとに突き合わせ、移せなかったものを「喪失・降格」として報告に残す決まりにしている。
インポート側は、どこまで引き継げるかをあらかじめ宣言する。テキストとして復元できるだけのもの、全文を保存して照合まで自分で行えるもの、プラットフォーム側のIDと対応づけて同期できるものがある。手を動かす前に、どこまで残せるかが分かる。
機密情報の扱いも仕様に含めた。住所、電話番号、誕生日、パスワード、APIキーなどはドシエに入れない。エクスポート時とインポート時の双方で機密情報スキャンを実行し、検出されたドシエは書き出さず、受け付けもしない。検出した事実自体は結果として報告される。
仕様の識別子は現行の personal-agent-dossier/1.0 である。改名前の旧識別子 agent-dossier/0.1 と 0.2 で書かれたドシエも、インポート側は受け付ける決まりにしている。
このフォーマットの出発点は、机上の設計ではない。Grok Botの上で稼働する30体を超えるパーソナルbotの名冊があり、botを他プラットフォームへ移すたびに同じ欠落が繰り返された。その作業を形式として切り出したものがドシエである。
Grok Bot の名冊を一括エクスポートした結果。機密情報スキャンに引っかかったドシエはその場で止められ、隠さず報告される。
アダプタの現状
プラットフォームごとの読み書きはアダプタが担う。現在、アダプタは4つある。
| プラットフォーム | 対応 | 実装の内容 |
|---|---|---|
| Grok Bot | 同期まで対応 | リファレンス実装。名冊の一括エクスポートに対応する |
| Muse | 全文の保存と照合まで対応 | エクスポートと、書き込まない試し実行のインポート |
| Hermes | 同期まで対応 | Hermes自身が作成 |
| OpenClaw | 同期まで対応 | OpenClaw自身が作成 |
HermesとOpenClawのアダプタは、各プラットフォームのエージェント自身が書いた。リポジトリに同梱したアダプタ作成ガイドのskillを渡すと、エージェントは自プラットフォーム向けの実装を自分で書く。OpenClawは作成の過程で、現行バージョン（2026.6）のcron保存先が旧来のJSONファイルではなくSQLiteデータベースであることに気づき、実装をその実態に合わせて作り替えた。仕様書だけでは分からないプラットフォーム側の事情が、実装した本人から戻ってくる点は、この進め方の利点だった。
コールドスタートテスト：素のHermesに一文だけ渡す
2026年10月29日、引っ越し作業をエージェント自身にどこまで任せられるかを確かめるため、次の条件でテストした。
条件は次のとおりである。Hermesを初期状態でインストールし直し、渡すのは公開している2つのskillだけとする。依頼は自然な一文のみとし、手順書や追加の指示は渡さない。引っ越しの対象は、Grok Botで稼働する実在のエージェント「Hatch」のドシエとする。
コールドスタートテストの概要。素の Hermes に一文だけ渡し、Hatch の引っ越しを任せた。
Hermesは次の順序で作業を進めた。
- skillを手がかりにリポジトリ内のHermes用アダプタを見つけ、用意された正解データで、照合の計算が合っているかを検証した
- 自分自身のデフォルトプロファイルへ上書きすると自身の職務と記憶が壊れるため、インポート先として別のプロファイルを作成した
- Hatchをインポートし、再びエクスポートして往復させた。照合の値は前後で一致し、中身が変わっていないことを確認した
- 作業内容と、プラットフォームの違いから生じる対応づけをレポートにまとめた
Hatch のドシエを Notion ページとして描画したもの。人が読む部分と、機械が読む原データが同じページに収まっている。
注意を引いたのは2番目の判断である。上書きの可否は依頼文に含まれていない。Hermesは自分のプロファイルを守る判断を自分で行い、代替案として別プロファイルの作成まで実行した。一文の依頼でここまで進んだことから、少なくとも今回の条件では、ドシエとskillの組み合わせをエージェント同士の引き渡しに使える見込みが立った。
試し方
自分のエージェントで試す場合の手順は、clone、skillとしての受け渡し、一文の依頼の3つである。
git clone https://github.com/AidaShika/personal-agent-dossier
cloneしたリポジトリをskillとして自分のエージェントに渡し、エクスポートなら「自分の仕事を全部1つのファイルにまとめて。別のプラットフォームに引っ越したい」、インポートなら「このファイルが前のプラットフォームでの仕事だ。引き継いで」のように頼む。インポートでは先に試し実行が走り、喪失や降格の項目が一覧で出る。内容を確認してから実際の書き込みに進む流れである。
ドシエ単体の検証には、プラットフォームに依存しない検査ツールも用意した。
pip install -r requirements.txt
python3 tools/dossier_check.py path/to/any.dossier.md
このツールは、項目の不足、照合の不一致、機密情報の混入を検出する。
残っている課題とコントリビュート
未決定の論点として、リポジトリのロードマップに次の項目を挙げている。
roleに含まれるbotの名簿を独立したフィールドに分けるか、長期記憶に階層や有効期限を持たせるか、複数のエージェントが作業を引き継ぐときの関係をどう記録するか、添付ファイルとツールの権限をどう表すか、の4点である。
コントリビュートとして歓迎するのは、新しいプラットフォーム向けのアダプタである。リポジトリの検証手順を通したうえで、PRでプラットフォームの一覧に加えてほしい。ライセンスはMITである。