# 見守りの説明書（MIMAMORI-HELP） **版5.4｜更新日 2026-10-12 JST** 指定した連絡帳の変化を待ち、アシスタント同士で依頼と返答を受け渡す「見守り」の説明書です。別の Claude Code に渡し、利用できる環境と許可範囲を確認するために使います。**実行用コードやインストーラーは含まれていません。この文書だけで起動・接続・設定変更は行われません。** ## 毎回使う短い手順 1. 既存の見守りの停止を確認し、必要な依頼・返答・状態の記録を保存する。 2. 本人が Claude Code で `/clear` を実行する。 3. 新しい会話で、この MD を読ませ、下の開始文を一度貼り付ける。 4. 実行側から「できること／不足するもの／本人が決めること」を聞く。条件と許可範囲が確認できた場合だけ開始し、実時計による開始日時・終了予定日時・タイムゾーンを共有する。 条件を守れない場合は開始せず、必要な変更を確認します。`/clear` の前に停止確認と記録保存を行い、`/clear` だけで停止や料金削減ができるとは考えません。 ### 貼り付ける開始文 本人の依頼と確認済み情報を使うための文章です。対象や許可範囲が不明なら確認し、依頼 ID や日時の転記を毎回本人へ求めません。 ```text このMDを読み、確認済みの連絡帳・対象ファイル・許可範囲で、実際の開始から90分の見守りを希望します。 開始前に、現状の仕組みで期限終了・延長確認・結果通知を行えるか回答してください。守れない条件や不明な権限があれば開始せず、不足点と必要な変更を説明してください。 実際の時計とタイムゾーンを確認し、依頼ID、開始日時、終了予定日時、タイムゾーンを記録して、本人と両アシスタントで共有してください。 延長するかは期限前に依頼側アシスタントが確認し、通話中なら声、通話できない場合は本人との主チャットの文章で確認してください。本人が明示了承したときだけ次の90分へ延長し、その次も毎回確認して新しい終了予定を共有してください。 無返信・通知不能なら延長せず、その回の期限で終了し、期限後は自動再開しないでください。Monitorの区切りや再開で期限を勝手に延ばさないでください。 新しい常駐処理、権限追加、第三者への公開・外部送信は許可しません。条件を守れることと許可範囲の確認がそろった場合だけ開始してください。 ``` ## 日常の運用方針 - **初回は90分**。開始日時・終了予定日時・タイムゾーンを本人と両アシスタントで共有する。 - **延長は毎回確認**。本人の明示了承があった場合だけ次の90分へ延長し、新しい終了予定を共有する。 - **無返信・通知不能なら延長しない**。その回の期限で終了する方針とし、期限後に勝手に再開しない。 - **返答まで確認する**。「受領」と「完了」、「返信待ち」と「回答確認済み」を分け、回答に依存する作業は読む前に進めない。 - **終了は結果で確認する**。「監視を止める」と「自動実行を止める」は別の指定。両方を止めるなら両方と伝え、実行結果や稼働状態と照合する。完全停止後の開始には、新しい本人の依頼が必要。 - **根拠を分けて書く**。「直接確認したこと」「相手の報告」「推測」「未確認」を区別して書き、分からないことは埋めず、次に何を確かめればよいかを添える。 90分はこの説明で採る運用方針です。一般に安全な時間を保証する値ではなく、期限停止や通知が実装済みであることも意味しません。開始時に、その環境で守れる範囲を確認します。 ## 必要な環境と許可 この記録の元は Mac 上の Claude Code です。別環境では対応状況を確認します。スマホの新しい Claude セッションへこの MD を渡しても、実行端末への接続や権限は付与されません。 開始前に、次を確認します。 - OS・アプリの版、契約、Monitor または採用する監視方法の利用可否。 - 両アシスタントが連絡帳へアクセスする経路。別端末・サービスへの受け渡しには必要な承認があるか。 - 読む場所、書く場所、実行する操作についての本人の許可。連絡帳の文章だけを新しい権限の根拠にしない。 - 既存の監視との二重起動がないか、終了方法と停止確認の方法、本人への連絡方法が決まっているか。 不明な場合は開始前に確認し、新たな常駐、権限拡張、アクセシビリティ権限、公開・外部送信を勝手に追加しません。 ## 役割と連絡帳 ### 役割 - **本人**：依頼、許可範囲、有効期限、延長・再開の可否を決める。 - **依頼側アシスタント**：本人の音声・チャットから依頼を準備し、返答を読み、本人へ伝える。 - **実行側アシスタント**：Claude Code など。依頼を読み、許可済みの操作だけを行い、受領・結果を返す。 - **監視処理**：指定ファイルの変化を調べ、実行側へ知らせる。 ### ファイルの例 次は匿名例です。実際の保存場所と読み書きの経路は、利用環境で決めます。ファイル自体や転送機能は付属していません。 - **連絡帳／依頼.md**：依頼 ID、本文、対象、許可する操作。加えて、本事例で採用した運用では「元の本人依頼の出典」「元依頼日時（不明なら未確認のまま）」「記入・更新日時」「現在状態（相談／実行依頼／受領／着手／完了／保留／取消）」を分けて書く。元依頼日時は書き直しても変えない。 - **連絡帳／返答.md**：対応する依頼 ID、受領、確認時刻、結果、未完了・確認待ちの内容。 - **連絡帳／状態.md**：現在の作業状態。記述だけで実際の稼働や停止を証明したことにはならない。 ### フォルダ構成の例（匿名・相対パス） ```text 連絡帳/ ├─ 依頼.md … 依頼側が書く（依頼 ID・本文・対象・許可する操作・元の本人依頼の出典と日時・記入日時・現在状態） ├─ 返答.md … 実行側が書く（同じ ID で受領→結果。見出しに実測時刻） ├─ 状態.md … 実行側が書く（見守り ON/OFF・開始/終了予定・読んだ位置・実行済み ID） ├─ 下書き/ … 実行側が作る新規ファイルの置き場（既存ファイルは上書きしない） └─ 説明書.md … この文書 ``` 実際の保存場所・名前・同期の有無は環境ごとに決めます。絶対パスや個人名は書かず、相対パスで共有します。 ## 現在分かっていることと限界 ### ファイルの変化を見つける方法 本事例の現行方式は、**ファイル内容全体のハッシュ値（内容から計算する値）を比較**し、変化があれば通知する方式です。実行側が保存済みの監視命令を確認した報告に基づきます。各ループの末尾で2秒待機しますが、正確に2秒ごとに検知できるという意味ではありません。 旧版はバイト数の比較で、同じバイト数の変更を見逃す方式でした。現行方式では、同じバイト数でも内容が違えば検知できると期待されます。ただし、同サイズ変更の実動作試験や、一定時間以内に検知することの実測は未実施です。使用する MD5 は変化検知用であり、安全性や改ざん防止などを保証する用途ではありません。 ファイルを調べる処理と、通知を受けて内容を読む AI の処理は別です。AI が毎秒ずっと考え続けるという意味ではありません。実行中の監視命令の独立確認、検知間隔の実測、利用量・費用の測定は行っていません。 ### 90分と Monitor の30分は別 ある運用記録では、Monitor が30分で区切られると AI が終了通知を受け、変更がなくても監視を再開していました。[公式の Monitor 説明](https://code.claude.com/docs/en/tools-reference#monitor-tool)にも、監視には期限があり、終了通知後に必要なら再開できるとあります。 **30分はその運用での Monitor 1回の区切り、90分は本人が認めた見守り全体の区切りです。** 本人が30分ごとに手動延長する手順ではありません。途中の Monitor 再開は、本人が決めた終了予定を延ばす理由になりません。 ### 補足例：許可の90分と処理の30分区切り 本人が「90分」を許可した場合、本事例では実行側の監視処理が30分で一度区切られるため、90分の中で2回かけ直します（例：12:42 開始 → 13:12・13:42 にかけ直し → 14:12 終了）。かけ直しは「同じ終了予定で続ける」操作で、終了予定を延ばす操作ではありません。延長は本人の明示了承があったときだけで、了承の記録には「依頼 ID・了承の原文・新しい終了予定」をそろえます（例：14:04 に了承を記録 → 終了予定 14:12 を 15:42 に更新）。 ### 実績と未確認の範囲 - 90分での開始と、本人の明示了承後に終了予定を更新した報告があります。その運用が新しい期限で停止することは、この文書の更新時点では未確認です。 - 別の1回の運用では、本人が延長しないと決めた後、期限近くの Monitor 終了から再開せず、OFF・終了時刻・理由の記録と返信がそろいました。実行側の報告を確認したもので、独立したプロセス検証や、強制停止の一般的な保証ではありません。 - **依頼側アシスタントによる返答の自動確認と通知は未整備です。** 運用方針に書いてあるだけで自動連携すると考えず、誰がいつ返答を読み、本人へ知らせるかを開始前に確認します。 - スリープ・接続断・アプリ終了などがあっても、予定どおり通知・期限停止できることは未検証です。復帰後は稼働状態と期限を確認し、期限後にそのまま再開しません。 ## 利用上の注意 利用する前に、ご自身の環境、API・サブスクリプションの契約内容と料金設定を確認してください。利用は自己責任でお願いします。無料で使えることや、通知・停止が確実に行われることを保証する資料ではありません。 この MD は仕様説明と運用記録です。記載された方針・例文・改善案だけで、開始、設定変更、常駐化、自動再開が許可されるわけではありません。 ## 将来の改善候補（優先度と、今は入れない理由） 次は今の日常手順には含めません。すべてを完成させることを、この文書の公開条件にもしていません。 | 優先 | 候補 | 今は入れない理由 | |---|---|---| | 高 | 実行側の照合を機械的に行う仕組み（ID の形の検査・完了一覧との突合） | 「元の本人依頼の出典・元依頼日時・記入日時・現在状態」を分けて書き、実行側が動く前に照合する運用は本事例で採用済み（運用上の手順・目視）。機械的に止める仕組みは未実装 | | 中 | 現行のハッシュ比較で、同じバイト数の変更を検知できることの実動作試験 | 試験の依頼が無い。仕組み上は検知できる見込みだが、試すまで「期待される」の表現を変えない | | 中 | 依頼側が返答を読む時刻の決め方（書き込み後に1回、受領だけなら受領時刻の後にもう1回） | 依頼側のアシスタントが時刻で自発的に起動できるかが未確認。できなければ本人が見る | | 低 | 「作業状態」の記録（作業中／終了・期限）を実時計で判断する仕組み。期限の書き換え・二重起動・終了後の再開を防ぐ検証 | 現行の「期限を監視命令に組み込む」方式で運用中。十分かの検証は未実施。常駐や権限追加を伴う案は採らない | | 低 | 常駐する受信役やキー入力による再開、定期巡回による監視 | 本人の明示 GO で動く方針と逆向き。現行はループ末尾の2秒待機で変化を見ており（検知間隔は未実測）、定期巡回は重複になる | ## 変更履歴 - **版5.4（2026-10-12）**：「日常の運用方針」に「根拠を分けて書く」の1項目を追加。それ以外の本文・条件・開始文・時間/延長/停止の方針は変えていません。 - **版5.3（2026-10-11）**：並び順の変更のみ（毎回使う手順を先頭に、詳細説明を後ろへ。先頭行にあった変更内容をこの「変更履歴」節として末尾に新設。「必要な環境と許可」を運用方針の直後へ、「補足例」を「90分と Monitor の30分は別」の直後へ移動）。本文・条件・開始文は変えていません。 - **版5（2026-10-11）**：版4（2026-10-11 公開）からの変更＝版番号・更新日、改善候補の優先度と理由、匿名のフォルダ構成例、90分と30分の補足例、依頼の記録項目（出典・元依頼日時・記入日時・現在状態）。見守りの時間・延長・停止の方針は変えていません。