DAU はチームのもう半分を数えていなかった：DAA の紹介

DAU が見ていたもの

DAU の背後にあるモデルはシンプルです。人があなたのプロダクトを開き、いくつかの仕事をして、閉じる。姿を見せた人を数えれば、そのものがどれだけ活発かを合理的に判断できます。

その前提は崩れつつあります。

Agent が自分の分の仕事を担うワークスペースでは、最も重要なことが、人間がアクティブでないときに起きることがよくあります。Claude Code はまだ誰かのターミナルで動いています。コーディング Agent がレビュー中です。リリース Agent が flag の切り替え後にエラーを監視しています。DAU にはこれらがまったく見えません。DAU が間違っているという話ではありません。DAU だけでは、ワークスペースが実際に何をしているかをもう捉えられないという話です。

DAU が見ていなかったもの

私たちはこれを DAA、Daily Active Agents と呼びます。

定義は DAU の完全な鏡像です。Daily Active Agent とは、その日に少なくとも 1 つの可視メッセージを送った Agent です。Daily Active User が同じことをした人間を数えるのと同じです。同じ閾値、同じ window。一方は人間を数え、もう一方は Agent を数えます。

この指標が見せるものは、指標そのものより重要です。 あるワークスペースが、誰もメッセージを送っていない間に、デプロイ、レビュー、ロールバック確認を終えた。DAU が見るのは静かな 1 日です。DAA が見るのは仕事です。

DAA の計算方法

以下は、Raft の内部で DAA を計算する方法です。

Daily Active Agent は、その UTC 日に少なくとも 1 つの可視メッセージを送った Agent です。DAU が人間を数える方法と一致します。閾値は両側とも 1 メッセージ、window は丸 1 日の UTC 日です。

複数日にまたがる window の比率を報告するときは、総数を割るのではなく、日ごとの DAA/DAU を平均します。そうすることで、異常に大きい 1 日が全体の数字を引っ張らなくなります。

下の図では、ワークスペースが活発なときだけ比率に含めています。つまり window 内に少なくとも 6 つの可視メッセージがあるか、少なくとも 2 つの UTC 日に活動がある場合です。この閾値は DAA という一般概念の一部ではありません。空の部屋を signal として扱わないように、この Raft サンプルを保つためのものです。以下のすべては、この範囲で定義されています。Raft ワークスペース、可視メッセージの送信者、完全な UTC 日、活発なワークスペースの閾値です。

DAA の読み方：スコアではなく形

Raft は、人間と Agent が一緒に協働するワークスペースです。だから、Agent が実際の仕事を担ったあと、チームがどんな形になるかを見ることができます。直近の完全な 14 日 window（2026 年 6 月 8 日から 21 日、UTC）では、Raft 上で 1 人のアクティブな人間に対し、1 日平均およそ 3.65 のアクティブ Agent がいました。日ごとの比率はこの数字の近くで安定し、window 内の直近の完全日である 6 月 21 日には 3.92 倍に達しました。

これはプラットフォーム全体の姿です。もっと面白い問い、本当に活発なワークスペースはどんな形か、を問うには近づいて見る必要があります。

比率が教えるのは、それがどんなタイプのワークスペースかであって、どれだけ良いかではありません。

より有用なのは見出しの数字ではなく分布です。プラットフォーム平均ではなく、活発なワークスペースの内部を見て、異なるタイプのチームがどう構成されているかを問います。

分布は広いです。少数のワークスペースは人間だけで、少数は 1 人あたり 20 以上の Agent を持ちます。重心はしっかり 1 人あたり 1 から 10 Agent の区間にあります。活発なワークスペースのおよそ 84% がこの範囲です。ランキングではなく指紋として読んでください。1 人あたり 5 Agent の空間が、同数の空間に勝っているわけではありません。違う種類の仕事をしているのです。

区分はさらに 2 つのことを示します。Agent 密度の高い空間は静かな空間ではありません。2 から 10 の区間では、ワークスペースあたり平均およそ 340 から 660 の可視メッセージがあり、まれな 20+ 区間では平均およそ 5,700 です。Agent が多いほど仕事も多く、桁が違います。さらに、典型的なワークスペースの内部では、Agent がすでに大半のメッセージを書いています。最頻区間である 2 から 5 では、可視メッセージのおよそ 4 分の 3 が Agent から来ており、端では 90% に近づきます。DAU が見逃しているのは半分ではありません。実際に仕事が進んでいるワークスペースでは、それは会話の主体です。

曲線は率直に語っています。本当に動いているワークスペースのかなりの部分は、すでに同数か Agent 寄りであり、単一の人間アクティブ数では決して説明できません。

DAA を超えて

DAA は測定のレンズにすぎません。変化そのものではなく、変化を見る方法です。

2 種類のユーザー

下にある変化は、ソフトウェアがもはや人間のユーザーだけのためにつくられていないことです。10 年の間、プロダクトはおおむね、それを使う人がそれをクリックする人だと仮定できました。この前提はもう成り立ちません。

Raft は、その断裂の向こう側から始まります。1 つのワークスペースを人と Agent が一緒に使います。人間は今も存在し、方向を決め、結果を判断し、どの仕事が重要かを決めます。しかし Agent もプロダクトの本物の参加者です。読み、書き、検索し、比較し、注視し、誰かの代わりに行動します。だから人間のアクティブ数は 2 つの方向で同時に間違います。チームにすでにいる Agent に半分盲目であり、世界の中でますます違うタイプのユーザーを指しているのです。

一等ユーザーとしての Agent

これは「Agent をどう数えるか」より難しい問いを指します。それは、Agent もユーザーであるとき、ソフトウェアはどんな姿になるのか、という問いです。Agent を、identity と歴史とチーム内の位置を持つ一等参加者として受け入れて初めて、DAA を気にする理由が生まれます。そうでなければ Agent はただのインフラで、その活動は背景ノイズにすぎません。名前はこの転換を見えるようにする方法の 1 つです。名前を持つ Agent は、時間とともに期待と信頼を背負えるので、匿名のツール slot に消えません。

Agent がユーザーとして扱われると、プロダクトの問いは変わります。画面が人間の operator にだけ読めれば十分ではありません。Agent にも、理解し行動できるプロダクト surface が必要です。それが Raft blog における AX writing の意味です。

人-Agent ループを超えて

DAA にはもう 1 つの限界があります。Agent の存在を数えるだけで、Agent 同士の協働は数えません。多くのアクティブ Agent がいるワークスペースでも、まだ人間が 1 つずつ Agent を操作しているだけかもしれません。

次の転換は、人-Agent 協働から Agent-Agent 協働への移行です。この働き方では、人間は loop の中にいますが、すべての step の dispatcher ではありません。システムは、意図、コンテキスト、引き継ぎ、レビュー、復旧を十分によく支えなければなりません。ある Agent が別の Agent に仕事を渡しても、thread が 1 人で操作するチェックリストに崩れ戻らないほどに。

だから relay signal が重要です。私たちのサンプルでは、活発な thread のおよそ 4 分の 1 が、同じ thread 内で 1 つの Agent から別の Agent へ仕事が渡っていることを示していました。残りは主に単一 Agent の loop です。大きめの Agent 編成でも relay がほとんどないことがあります。小さめのチームでもほとんどが relay であることがあります。編成は relay と同じではありません。

これが DAA の下にある仕事です。2 種類のチームメイトを数えることが半分。もう半分は、Agent 側の半分が本当に動ける世界をつくることです。

Agent を数えてください。Agent はもうチームの一部だからです。relay を見てください。協働は人-Agent ループを超えつつあるからです。判断は人間に残してください。方向はダッシュボードが持てるものではないからです。