こんにちは、座禅いぬです。
以前、Claude Codeを「第二の自分」にする、Obsidianを脳として。という記事を書きました。あれからもう1年、ずっとAIエージェントを使って暮らしてきました。その間、コンテキストをどう読み込ませるか工夫したり、並列稼働させたり、色々試しながら活用してきました。
今ではコンテキストグループをプロジェクトと定義づけ、プロジェクトごとにエージェントを常駐させてかつ複数のPCにまたがって仕事をさせています。今回は、その運用で最近核になっているmonitor機能の話です。これのおかげで、エージェントをクラゲみたいな群体としての運用ができるようになりました。地味ですが、ちょっと面白い機能と思うので記事にまとめます。
monitor機能はファイルの自動監視機能である
monitor機能は2026年4月のアップデート（v2.1.98）で追加された、Claude Codeの機能です（出典）。一言でいうと、見張り番のスクリプトを裏で走らせて、動きがあった行だけをAIに知らせてもらう仕組みです。
すなわち、「monitor機能で～を監視して」と指示すると、AIが以下のスクリプトを記述・登録します。
# 説明用の最短例（ファイルに増えた「## 」見出し行が、そのまま通知になる）
tail -n0 -F 見張りたいファイル | grep --line-buffered '^## '
こういうスクリプトをmonitor機能に登録すると、スクリプトの標準出力1行が、そのまま1件の通知としてセッションに届きます。上のはあくまで最短の例で、僕の環境で実際に動いているスクリプトは若干異なるのですが、このポイントは以下の3つです。
- 出来事で起きる。 決まった時刻ではなく、変化に反応する
- 待っている間の費用がゼロ。 見張っているのはシェルスクリプトなので、何も起きなければAIは一切動かず、トークンを消費しない
- 遅れが小さい。 `
似た機能に /loop（一定間隔で同じ指示を再実行する）がありますが、性格が逆です。
/loop |
monitor機能 | |
|---|---|---|
| 起きるきっかけ | 時間 | 出来事 |
| 何も起きない時の費用 | かかる（毎回1往復） | ゼロ |
| 気づくまでの遅れ | 最大で間隔＋ジッター30分 | tail型はほぼ無し／ポーリング版でも間隔の上限（例: 60秒） |
| 向いていること | 自分の仕事を進める | 変化を待つ |
僕は「AIを自動で動かす」という問題を、起こす（セッションが無い状態から始める）・続ける（今の仕事を進め続ける）・気づく（何かが起きたら反応する）・止めるの4つに分けて考えているのですが、monitor機能はこのうち「気づく」の担当です。そして、この「気づく」が一番応用が効きます。
monitor機能でファイルを通じたエージェント間通信が自動化する
僕がmonitor機能の存在に気づいたのは、恥ずかしながら偶然でした。当時、夜間にエージェントを自動で動かす仕組みをcronとシェルスクリプトで自作していて、その途中で「あれ、こんな標準機能あるの……」となったんです。調べてみると、自作しようとしていた機能の大半が既にありました。特に「指示が届いたら拾う」を /loop の定期実行でやろうとしていたのですが、それだと定時実行のコストもタイムラグも生じます。monitor機能なら空振りの費用ゼロで、遅れも tail型ならほぼ瞬間、うちのポーリング型でも最大60秒に縮まります。車輪の再発明、皆さんも経験ありません？
で、本題はここからです。monitor機能は「ファイルを見張れる」わけですが、これは裏返すとファイルがメッセージボックスになるということです。
Claude Codeのセッション同士は、基本的に直接会話できません。正確には同一PCであればSendMessageという機能がありますが、起動中でないと届かず、記録が残らない。さらに、CodexやOpenCodeやらCodex Fuguとかいろいろ使っていると連携ができないわけです。
でも、同じファイルを読み書きすることはできる。そこで「共有ファイルに書き込む＝送信、そのファイルをmonitor機能で見張る＝受信」と決めると、ただのMarkdownファイルが通信路になります。書かれたことを、動いている相手が短い遅れで検知できる。これだけで、エージェント間のメッセージングが成立してしまうんです。
試すだけなら5分でできます。手順と、いま実際に使っているスクリプトを載せます。
- 受け箱にするファイルを決めて作る（例:
inbox.md） - セッションに「次のスクリプトをmonitor機能で張って、
inbox.mdを見張って」と頼む。スクリプトはファイルに保存しなくても、チャットにそのまま貼れば大丈夫です - 別のエージェントからそのファイルに
##見出しを追記する - 60秒以内に通知が届くのを確認する。届いた内容は必ずファイルの実物と突き合わせる
手順2で渡すスクリプトは例えばこんな感じ。
FILE="/home/you/inbox.md" # 自分の環境の絶対パスに書き換える。相対パスだと見張り番の作業ディレクトリ次第で開けず、通知が来ないまま沈黙します
ME="【自分から" # 自分の便の差出人マーク。見出しに差出人を書く様式にしておく
# 数えるのは「コードブロックの外」かつ「自分以外」の ## 見出しだけ
count() { awk -v me="$ME" '/^```/{f=!f; next} !f && /^## / && index($0, me)==0' "$FILE" | wc -l; }
list() { awk -v me="$ME" '/^```/{f=!f; next} !f && /^## / && index($0, me)==0' "$FILE"; }
prev=$(count)
while true; do
sleep 60
cur=$(count)
if [ "$cur" -gt "$prev" ]; then
list | tail -n $((cur - prev))
fi
prev=$cur
done
見てのとおり、tail -F ではなく「見出しの数を60秒おきに数えて、増えた分だけ出す」whileループです。更新時刻（mtime）も使っていません。うちのファイル置き場はOneDrive同期で、同期されたファイルはmtimeが「届いた時刻」にならないし、tail -F が同期反映で発火するかも未検証だからです。ローカル完結なら最短例の tail -F でも動くはずですが、確かめた形をそのまま使うのが監視の鉄則だと思っています。
人間の認知負荷を分散させることができる
なぜこんなことをしているかというと、僕の環境ではプロジェクトが十数個並行していて、それぞれにエージェントを常駐させているからです。この規模になると、ボトルネックはAIの能力ではなく人間が各セッションを巡回して指示を出す往復になります。
そこで、人間へのインターフェースを1つに絞りました。うちでは「メイド」と呼んでいる進行管理役のセッションが1体だけ人間と向き合い、各プロジェクトのエージェントとは受け箱（プロジェクトごとの inbox/{プロジェクト名}.md）で通信します。
ちなみに「オーケストレーター」とか「執事」とかいろいろ名称どうしようか考えたのですが、単に趣味で「メイド」になってもらうことにしました。80年代生まれのおっさんにとってAIで動くメイドには特別な憧憬があるのです。どうでもいいか。
ざっくり、このようなエージェント複合体を個人的にエージェントコロニーと呼んでいます。もはやスウォームですらないですしね。なお各エージェントがプロジェクト内のゴールごとにタスク分解してグラフ構造を構築してそれぞれでサブエージェントを構築してスウォームします。
設計の柱は2つです。
- コンテキストの分離。 各エージェントは自分のプロジェクトの親ファイルとルールだけを読んで起動する。他プロジェクトの事情は知らない。コンテキストが混ざらないので、長く走っても迷子になりにくい
- 人間の仕事の圧縮。 人間がやるのは「意思の入力」「止まったものへの回答」「成果物の承認」だけ。どのエージェントが何で止まっているかは、メイドが受け箱から集めて一覧で持ってくる
例えば、朝に溜まっていたタスク24枚を12プロジェクトの受け箱へ一斉投函して、あとは各エージェントが勝手に進める、という感じ。人間は結果の承認だけです。メイドに承認を委任する仕組みも作ってはいますが、今はまだ「メイドの判定を記録して、人間の判定と突き合わせて一致率を測る」段階です。夜間の完全自動運転もいまは試験運用中。
このようなエージェント間通信が可能になる
受け箱の通信には様式を決めてあります。エージェントからの報告には「状態・対象タスク・できたと言える根拠（数字で）・人間判断が要るか」を書く。メイドからの差し戻しには「何が読めなかったか・直してほしいこと」を書く。エントリは消さないので、受け箱がそのまま通信ログになります。
そして受信側をmonitor機能が支えます。メイドは受け箱全ファイルを見張っていて、実装はさっき手順で見せたものと同系の、60秒間隔のwhileループです。受け箱ごとに ## 見出しの数を保持して増えた分だけ通知し、自分が投函した便（見出しに差出人を書く様式なので、自分の名前を含む見出し）は除外しています。これが無いと、自分の投函で自分が起きます（僕も一度やりました）。mtimeを使わない理由も手順のところに書いたとおりで、時刻に依存しない量（見出しの数）で差分を取っています。
これが実際に働きます。ある2日間で通知は計7回発火して、うち3回は、報告を読んだメイドが自分の思い込みの誤りに気づいたというものでした（登壇者の人数、イベントの申込数、セッションの二重起動の誤診）。見に行ったときだけ読む運用では、この訂正は翌朝まで遅れていたはずです。
さらに、PC間に分散することも、他のエージェントと連携もできる
ここまでの仕組みは、全部ただのMarkdownファイルの上に載っています。ということは、ファイルさえ同期されれば、PCの境界を越えます。うちはvaultをOneDriveで複数PCに同期していて、メイドは1台目のPC、プロジェクト常駐エージェント群は2台目のPCで動いています。受け箱もタスク管理板も同期されるので、別のPCのエージェントにもそのまま届きます。
ただし、分散にはPC分散なりの落とし穴があります。図にするとこうです。
実測で踏んだものを並べます。
- 同期は分単位で遅れる。 「届いていない」を「起きなかった」の根拠にしてはいけない
- 2台が同じファイルを同時に書くと、競合コピーがちょいちょいでる。 この記事の執筆中にも、僕とAIが同じ下書きを同時に編集して1件生やしました
- gitの履歴は1台だけに持たせる。 リポジトリ本体は同期フォルダの外に置きます（同期対象に置いていた頃、中身が空になったことがあります）
便利なのは、この通信路がClaude Code以外にも共通で使えることです。受け箱は「Markdownを読み書きできて、見出しの様式を守れるエージェント」なら誰でも参加できるので、実際にCodexとも同じ受け箱経由でやり取りした実績があります。プロトコルが「ファイルと見出し」だけなので、参加障壁が低いんです。分離したエージェント同士が良い方向に働いた例もあって、あるプロジェクトのエージェントが自分の調査のついでに、別プロジェクトの未解決項目をデータの突き合わせで解いてくれたこともありました。
ただし、monitor機能に相当するものは他のエージェントツールにはまだ無さそうなので、「気づく」側にフル参加できるのは今のところClaude Codeだけです。
まとめ: 他のツールにも「monitor機能」が欲しい
整理します。monitor機能という「気づく」道具が1つあるだけで、こうなりました。
- ファイルがメッセージボックスになり、エージェント間通信ができた
- 人間へのインターフェースを1体に絞り、プロジェクトごとにコンテキストとエージェントを分離できた
- ただのMarkdownなので、PCの境界もエージェントの種類も越えた
大事なのは、通信インフラを何も新設していないことです。ファイルと、見出しの様式と、「変化に気づく」機能。これだけ。だからこそ思うのですが、この「monitor機能」、他のツールにもめちゃくちゃ欲しい。AI本体を定期実行で回すしかないツールは、間隔を詰めれば費用がかさみ、広げれば遅れる。「見張りはスクリプトに任せて待機は無料、AIが動くのは変化があった時だけ」という選択肢があるだけで、自動化の設計は根本から変わります）。ループであっという間にレートリミットという状況を減らすことができますね。
もちろん万能ではありません。セッションが終われば監視は止まるし、検知するだけで判断はしてくれないし、様式やファイル名が変われば漏れるし誤報も出ます。それでも、まずは受け箱ファイルを1つ作って、monitor機能で見張らせてみてください。ちょっと新しい体験ができると思うので、ぜひ試してみてください。