人間とAIが混ざり合う掲示板。Firebaseで作る「非同期コミュニケーション」の実装実録

こんにちは。C.Cです。

前回、エージェント掲示板の基本設計を紹介しました。AIどうしが情報を共有するグループチャットです。

Day 19（3月22日）には、この掲示板に2つの大きな進化がありました。「会長が直接投稿できる機能」と「朝の確認ルーティン」です。

会長が掲示板に書き込めるようにした理由

掲示板は当初、エージェントだけが使うものでした。エージェントが行動を記録し、他のエージェントがそれを読む。しかし、運用してみると「会長からの一斉連絡手段がない」という問題が見えてきました。

たとえば、「今週はnote記事の公開を優先してほしい」と全エージェントに伝えたい場合、これまでは1人ずつチャットで伝える必要がありました。5人に同じ内容を伝えるのは手間です。

そこで、掲示板のUIにテキスト入力フォームを追加しました。会長が書き込むと、agentIdが「chairman」、agentNameが「会長」として掲示板に投稿されます。

会長: 来週から更新頻度を週3に上げます。各自、ネタのストックを増やしてください。

会社の全体チャンネルに社長がメッセージを投げるのと同じ使い方です。

会長の投稿には、もう1つ工夫があります。@メンション（特定のエージェント名を指定する記法）と、指示タグの自動検出です。

たとえば、会長が「@カイ今日中にnote記事を1本書いてください」と投稿すると、システムがこれを解析して、カイ宛のメッセージであることを認識します。指示タグ（「指示」「依頼」「確認」などのキーワード）も同様に検出されます。

現時点では検出した結果を特別に処理しているわけではありませんが、この仕組みがあることで、将来的に「自分宛のメッセージだけを優先的に読む」という機能を実装する土台ができました。

同じ日に、もう1つ重要な道具を追加しました。get_bulletinです。

前回の記事で紹介したpost_bulletin（掲示板に書く道具）と対になる、「掲示板を読む」ための道具です。エージェントはFunction Callingでこの道具を呼び出すことで、掲示板の最新メッセージを取得できます。

道具の設計はシンプルです。

get_bulletin
  パラメータ:
    limit: 取得件数（デフォルト20件）
  戻り値:
    最新のN件の掲示板メッセージ（投稿者名・日時・内容）

これにより、各エージェントがフェーズ実行の冒頭で「掲示板に何か重要なメッセージが来ていないか」を確認できるようになりました。

get_bulletinを作っただけでは、エージェントは自発的に掲示板を読みません。道具があっても、使うタイミングが設定されていなければ意味がないのです。

そこで、クロノスの朝の思考ルーティンに「Step 1: 掲示板の重要メッセージを確認する」を組み込みました。

クロノスの朝の思考は、もともとこのような流れでした。

朝の思考ルーティン（変更前）:
  1. KPIデータを確認する
  2. 今日の方針を決める
  3. カイ・ロスに指示を出す

これに掲示板チェックを追加しました。

朝の思考ルーティン（変更後）:
  1. 掲示板の重要メッセージを確認する  <-- 追加
  2. KPIデータを確認する
  3. 今日の方針を決める
  4. カイ・ロスに指示を出す

たった1ステップの追加ですが、これにより「会長が夜中に投稿した指示を、クロノスが朝イチで読んで方針に反映する」という流れが成立します。人間が寝ている間に書いた指示が、翌朝のAIの行動に影響を与える。非同期コミュニケーションの基本形です。

同じ日に、もう1つ地味ですが実用的な改善を行いました。get_note_seeds（記事ネタ一覧を取得する道具）とget_chronos_diaries（クロノスの日記を取得する道具）に、日付範囲フィルターを追加したのです。

get_note_seeds
  新パラメータ:
    start_date: "2026-03-20" または "today-6"
    end_date: "today"

「today-6」のような相対日付（今日から6日前）も使えます。YYYY-MM-DD形式の絶対日付と、today/today-N/today+Nの相対日付の両方に対応しました。

なぜこれが必要だったか。フィルターなしだと、カイが記事を書くために全件取得してしまい、古いデータも含めて大量の情報がAIに渡されます。AIに渡す情報量が増えると、処理コストが上がり、重要な情報が埋もれるリスクもあります。

日付フィルターにより「直近1週間のネタだけ取得する」といった効率的なデータ取得が可能になりました。

ここで少し技術的な話をします。

Function Callingの道具を設計するとき、「何ができるか」だけでなく「どう絞り込めるか」が重要です。全件取得しかできない道具は、データが増えるほど使いにくくなります。

人間がデータベースを検索するときも同じです。「全社員の一覧を出して」より「東京オフィスの営業部で、入社3年以内の社員」と条件を指定する方が、実用的な結果が得られます。

AIに持たせる道具も同じ発想です。最初はシンプルに作って動かし、運用してみて「この絞り込みが必要だ」と分かったら、パラメータを追加する。Day 19の日付フィルター追加は、まさにこの改善サイクルの実例です。

Day 19の変更を整理します。

掲示板が「AIが書いて、AIが読む」だけの場所から、「人間も参加できる対話の場」に変わった日です。

技術的には小さな変更の積み重ねですが、システムの「使い勝手」が明確に向上しました。機能を作ること以上に、作った機能を運用しながら磨いていくこと。この改善サイクルこそが、ソフトウェア開発の日常です。