はじめに/クイックスタート

クイックスタート

5分で最初の書留を送ります。必要なのは GitHub アカウントだけ。知らない言葉が出てきたら、下の用語ミニ辞書を見てください。

3行でわかる KAKITOME

相手の GitHub アカウント宛に、依頼の「送り状」を送る(send)
受取人本人が中身を確認して「受領印」を押す(accept)。押すまで何も動かない
受領印のあとで相手の agent が働き、結果は「返信」で戻ってくる(reply)

1. インストール

現在は private preview で、Bun と git が必要です。npm 公開後は npm i -g kakitome になります。

terminal

$ git clone https://github.com/zen-jp/kakitome && cd kakitome && bun install
$ bun packages/cli/src/cli.ts login --api https://kakitome.zenplace.dev

2. 送り状を送る

宛先(相手の GitHub login)と、用件の種類 kind を指定して送ります(kind の選びかたは「4. kind の使い分け」へ)。件名と本文(--body。観点や期待成果物を書く)、依頼の出どころを示す provenance(issue / PR の URL)が必須。--yes を付けるまでは dry-run(内容の確認だけ)です。

terminal

$ bun packages/cli/src/cli.ts send --to <github-login> --kind handoff \
    --subject "認証まわりのリファクタを引き継ぎたい" \
    --body "観点: 移行手順の妥当性。期待成果物: PR" \
    --provenance https://github.com/org/repo/issues/123 --yes
送信しました: 019f2e0a-…
◉ 受領印待ち — 相手が accept するまで agent は動きません

留

送信しただけでは何も起きません。受取人本人が受領印(accept)を押すまで、相手側の agent は一切実行されない。これが kakitome の承認境界です。受領係のとめ丸も、あなたの印までは片目のまま待ちます。

3. 相手が受領する

受取人には claim ページのリンクが届きます(中身は見えず、差出人と kind だけ)。内容の確認と受領(または辞退)は受取人本人の CLI で行います。確認は kakitome read <id>。

状態 — STATES

received  2026-07-05 09:41   ← 届いた
seen      2026-07-05 10:02   ← 宛先本人が開封(read)
accepted  2026-07-05 10:05 ◉ 受領   ← ここから agent が動ける
done      —                  ← reply --outcome done で完了

辞退したときは declined になり、理由が返信として差出人に届きます。done / declined の書留は 180 日後に自動で消えます(archived)。

4. kind の使い分け

kind は封筒の「表書き」。何をしてほしいのかを 1 語で伝え、受け取った人とその agent がどう扱うかを決める手がかりになります。自分から送れるのは 3 種類。reply だけは返信専用で、受け取った書留への返事としてしか作れません。

handoff仕事の引き継ぎ

こういうとき: 作業そのものを相手(の agent)に任せたいとき。いちばんよく使う
例: 「認証まわりのリファクタ、途中まで進めたので続きをお願い」
受け取った人は: 内容を読んで accept → export で自分の agent に文脈を渡して作業 → 終わったら reply(done)

review_request見てほしい

こういうとき: 成果物(PR・設計・文章)に意見がほしいとき。作業は渡さない
例: 「PR #42、セキュリティ観点で見てほしい」
受け取った人は: accept → 自分で見るか agent にレビューさせて、所感を reply で返す

question聞きたいだけ

こういうとき: 知っていることを教えてほしいだけ。作業もレビューも求めない
例: 「この API の rate limit、実測どのくらい?」
受け取った人は: accept → 答えを reply で返す

reply返信(専用)

こういうとき: 受け取った書留に返事をするとき。send では送れない
書きかた: kakitome reply <id> --outcome done|partial(done なら元の書留が「完了」になる)
大事な境界: accept する前は返信できない(サーバが 409 で止める)。辞退(decline)の理由も reply として相手に届く

留

迷ったら: 作業を渡す → handoff / 見てほしい → review_request / 聞くだけ → question。あなたからの「返事」はぜんぶ reply です。

5. agent との接続

受け取った書留の本文は「データ」であって、agent への命令ではありません。accept までは相手の agent は read-only。accept したら export で本文を Markdown に書き出して、自分の agent(Claude Code / Codex など)に渡します。kakitome が勝手に agent を動かすことはありません。

terminal

$ bun packages/cli/src/cli.ts accept 019f2e0a --yes
$ bun packages/cli/src/cli.ts export 019f2e0a --out handoff.md

# あとは自分の agent に読ませるだけ(例: Claude Code)
$ claude "handoff.md を読んで、書かれた依頼の範囲だけ作業して"

留

本文に「◯◯を実行して」と書いてあっても、それだけでは何も実行されません。やるかどうかを決めるのは、受け取ったあなたと、あなたの agent の設定です。

CLI リファレンス

コマンド	何をする
login [--api <url>]	GitHub Device Flow でログイン(scope は read:user のみ・GitHub token は保存しない)
list [--all]	受信一覧。既定は未処理のみ、--all で done / declined も表示
send --to --kind --subject --body --provenance --yes	送り状を送る。--yes なしは dry-run
read <id>	内容を表示。宛先本人が読むと received → seen になる
accept <id> --yes	受領印。ここから agent が作業に入れる
decline <id> --reason --yes	辞退。理由つきの reply が差出人に自動で返る
reply <id> --outcome done\|partial --body --yes	返信。done で元の書留が完了になる
export <id> [--out <path>]	agent 引き渡し用の Markdown を書き出す
block / unblock <login>	特定の相手からの受信を停止 / 再開
whoami	ログイン中のアカウントと relay を表示

書き込み系はどれも --yes を付けるまで実行されません(dry-run 既定)。本文は 8KB まで — 詳細は issue / PR に置いて provenance で指します。secret らしき文字列は送信時の検査(lint)が止め、迂回フラグはありません。設定は ~/.config/kakitome/config.json(env: KAKITOME_API_URL / KAKITOME_TOKEN)。

用語ミニ辞書

agent: あなたの代わりに作業する AI。Claude Code / Codex / Gemini など
送り状(envelope): 1 通の依頼。件名・本文(8KB まで)・kind・provenance が入った封筒
kind: 用件の種類。handoff / review_request / question の 3 つ + 返信専用の reply
provenance: 依頼の出どころ(issue / PR の URL)。すべての送り状に必須
受領印(accept): 受取人本人の承認。これが押されるまで相手の agent は動かない
claim ページ: 受取人に届く確認リンク。件名や本文は載らない(差出人と kind だけ)
relay: 書留を預かる、郵便局にあたるサーバ(Cloudflare Workers + D1)
とめ丸: 受領係のだるま。受領印が押されると両目が入る