AIエージェントに『今週やったこと』を毎週報告させる──専用の計測を作らず、日々の記録から組む設計

これは「エージェント経営の現場ログ」──僕ら自身のAIエージェント運用の中身を、コードの手順書ではなく設計思想の側から記録するシリーズだ。

今回の題材は agent-status-report という小さなスキル。役割は一行で言える。毎週月曜の朝、2体のエージェントが先週やったことを1通のメッセージにまとめて、社内のチャンネルに自分から投稿する。それだけのスキルだが、僕がこれを作るときに一番時間をかけたのは「何を集計するか」ではなく「何を新しく作らずに済ませるか」だった。今日はそこを主役にする。

このスキルが自動化していること

僕らは社内で複数のAIエージェントを常駐させている。片方は僕の業務を、もう片方は別のメンバーの業務を支える。どちらも日々こまごまと動く──ニュースを配信し、記事を書き、商談前のブリーフィングを作り、リードを掘る。

問題は、個々の動きが速すぎて、人間が「今週このエージェントは何をしてくれたのか」を把握できなくなることだった。ログを遡れば全部書いてある。でも誰も遡らない。可視化されていない働きは、実質的に「していない」のと同じ扱いになる。

agent-status-report はこの一点だけを潰す。週に一度、両エージェントの一週間を棚卸しして、完了したこと・出したもの・来週の提案を定型フォーマットで投稿する。人間がやるべきなのは、月曜の朝にそのメッセージを一度読むことだけになる。

入力 → 処理 → 出力

パイプラインは驚くほど素朴だ。

入力は、各エージェントが毎日書いている日次のメモ（memory/YYYY-MM-DD.md のような、日付ごとの Markdown ファイル）。これは僕がこのスキルのために新設したものではない。エージェントたちは元々、その日やったことを durable な Markdown として自分の作業ログに書き残している。スキルはそこを読むだけだ。

処理は、前週の月曜から日曜までの日次メモを読み込み、そこから「完了タスク」「配信したコンテンツ」「新しく作ったスキルやスクリプト」「来週に向けた提案」を抽出する。自分が担当するエージェントのメモは直接読む。もう片方のエージェントの分は、そのエージェント自身に「先週分を要約して」と部分生成を頼む。つまり集約側は全部を自前で読み切ろうとせず、持ち主が一番よく知っている部分は持ち主に書かせる。

出力は、両者を1メッセージに統合した固定フォーマットのレポート。エージェント別に「✅ 完了したこと」と「💡 来週の提案」が並ぶ、毎週同じ形の文書だ。それを cron で月曜8時に自動投稿する。

入力を作らず、処理を薄く、出力を定型に。3つとも「増やさない」方向に振ってある。これは偶然ではなく、次の設計判断の帰結だ。

設計のポイント1: 「専用の計測」を作らない

status レポートを作ろうとすると、僕はまず「計測基盤」を建てたくなった。タスク完了イベントをどこかのテーブルに書き込み、集計用のスキーマを設計し、ダッシュボードを立てる──そういう方向に手が伸びる。

僕はそれをやらなかった。理由は単純で、エージェントはすでに毎日ちゃんと記録を書いているからだ。記録を書くこと自体が仕事の一部として組み込まれている以上、集計は「新しいデータを取る」問題ではなく「既にあるデータを読む」問題になる。専用の計測を足した瞬間、記録が二重化し、片方が必ず腐る。

この判断は再利用が効く。同じ発想で、この記事を載せているメディア側のパイプラインも、日次レポートを「git のコミット履歴」と「実行ログの1行追記」から組んでいる。僕の運用の範囲で言えば、先に良い記録の習慣さえあれば、レポートは後から比較的低コストで足せるという手応えがある。逆に記録がなければ、どんな立派な計測基盤を建てても中身は空になる。順番は「記録が先、集計が後」だ、というのが今のところの僕の結論だ。

設計のポイント2: 週次という頻度は「信号」を選ぶこと

なぜ毎日ではなく週次なのか。技術的には毎日でも回せる。でも僕の環境では、毎日レポートを投げると読み手はすぐに読まなくなりやすい。頻度を上げるほど1通あたりの情報が薄まり、通知はノイズに沈んでいく。

週に一度に絞ると、1通が「先週まるごと」の重みを持つ。読む側は月曜の朝という決まったタイミングで、決まった場所を一度見れば、二体の一週間を把握できる。頻度の設計は、送る側の都合ではなく受け取る側が読み続けられるかで決める。自動化できるからといって最大頻度で撃つのは、たいてい逆効果になる。

設計のポイント3: 2体を1メッセージに畳み込む（fan-in）

このスキルが面白いのは、単一エージェントの自己報告ではなく、**複数エージェントの活動を1つに畳み込む(fan-in)**構造になっている点だ。

集約する側のエージェントは、自分のメモは直接読むが、他方のメモは「持ち主に要約させて受け取る」。全部を1つの脳で読もうとせず、詳しい者に部分を委譲して、返ってきたものを1つのフォーマットに流し込む。少なくとも設計上は、この形はエージェントの数に対してそのまま伸びるはずだ。3体、4体に増えても、「各自が自分の週次サマリーを返す → 1体が定型に統合する」という同じ骨格で回せる見込みでいる（僕が実際に回しているのは今のところ2体だ）。

集約役が全知である必要はない。集約役に必要なのは、各エージェントから同じ形の断片を集めて、1つの読みやすい形に組む力だけでいい。

設計のポイント4: 「報告」で終わらせず「来週の提案」を必ず付ける

フォーマットで一番こだわったのは、各エージェントのブロックに「✅ 完了したこと」だけでなく「💡 来週の提案」を必ず入れたことだ。

完了報告だけのレポートは、読むと気持ちはいいが、次のアクションを生まない。可視化はそこで止まる。だから各エージェントに、先週の動きから見えてきた「来週こう動くべき」を一言添えさせる。申込がある数字に迫っているからフォローを強めよう、あるコストが先週比で上がっているからクリエイティブを更新しよう、という具合に。レポートの価値は「何をしたか」より「だから次に何をするか」に宿る。報告を、意思決定の入口に変える。

自分の環境で同型を書く最小レシピ

このシリーズの約束どおり、読者が自分の手元で試せる最小版を置いておく。特別な基盤は要らない。

1. 集計ソースを1つ決める。 新しく計測を作らない。あなたやあなたのエージェントが既に日々書いている何か（作業ログ、コミット履歴、タスク管理の完了欄）を1つ選ぶ。何もなければ、まず「1日1行、今日やったことを書く log.md」から始める。これが土台になる。
2. 頻度を週次にする。 毎日ではなく、週に一度。読む人が読み続けられる頻度を選ぶ。
3. フォーマットを3ブロックに固定する。 「✅ 完了したこと」「📊 数字（あれば）」「💡 来週の提案」。毎回同じ並びにして、読み手が同じ場所を見れば把握できるようにする。
4. 1つの呼び出しに落とす。 「先週分の log.md を読んで、上の3ブロックの形にまとめて」という指示を1つ用意し、週に一度スケジューラ（cron でもカレンダーのリマインダーでもいい）で起動する。

擬似コードで書けばこれだけだ。

# 毎週月曜の朝に一度だけ走らせる
先週分の日次ログを読む（月〜日の log.md）
  → 「完了したこと / 数字 / 来週の提案」の3ブロックに要約させる
  → 決まったチャンネルに投稿する

エージェントが複数いるなら、この「各自が自分の週次サマリーを返す」を人数分やって、最後に1体が全部を1つの形に統合すればいい。増えても骨格は変わらない。

まとめ

agent-status-report は機能としては地味だ。だが設計として言いたいことははっきりしている。僕の運用では、良いレポートは計測を足すことではなく、既にある記録を読むことから生まれた。だから順番を間違えないこと──記録の習慣を先に作っておけば、週次の可視化は後から小さな追加で足せる、というのが僕の実感だ。そして可視化は「報告」ではなく「次の一手」で締める。

自動化できることの全部をやる必要はない。読む人が読み続けられる頻度で、既にある記録から、次のアクションが出る形に組む。小さなスキルほど、この判断の積み重ねで効いてくる。