これは四半期ごとに更新を予定しているレポートの第1回です。人々が他者のコーディングエージェントに何を依頼し、依頼されたときに何が起きるのか。データはmutiのプライベートベータのもので、2026年9月6日までの30日間を対象としており、規模はまだ小さく、58件のリクエスト、6台のマシン、10個のルームにとどまります。それでも公開するのは、共有エージェントについて公開している人が他に誰もいないためであり、想像上の大きな数字よりも、小規模で誠実な数字のほうが価値があるからです。
すべての数値は集計値です。リクエストの本文、氏名、ルーム名は含まれていません。
数字
最初の30日間の5つの数値と、その分母。
これらの数値が意味すること
マーケティングを行っていないベータ版において、非オーナーからのリクエストが3分の1を占めるのは高い割合です。 オーナーが他の人を招待し、その人たちがエージェントを使いました。共有こそがこのプロダクトの本質であり、促されることなく自然に発生しました。
承認は、頻度が低いときほど迅速に行われます。 58件のリクエスト全体で承認は9件にとどまり、中央値38秒で回答されました。これは設計が意図した通りの挙動です。4つの常時一時停止アクションと権限モードによってpromptの発生頻度が低く保たれるため、発生したpromptはしっかりと確認されます。エージェントが実行前に必ず確認すべき4つのアクションを参照してください。
確認を求めたのはBashでした。 承認のほとんどはシェルコマンドに対するものでした。ファイルの読み込みや編集の多くはacceptEditsの下で実行され、人間が介入を求められたのはコマンドの実行時でした。これは権限モードの設計通りの結果です。
失敗のほとんどはランタイムの失敗であり、権限の失敗ではありません。 10件のリクエストが失敗しました。タイムライン上では、テストの失敗、ツールの欠落、そして1件のランタイムタイムアウトでした。承認の拒否による失敗は1件もありませんでした。
ジョブの中央値は41秒です。 これまでのところ、共有エージェントに求められるのは「これを再実行して」「あれを要約して」「これらをエクスポートして」といった小規模で具体的なタスクです。長時間の全体的なリファクタリングは稀であり、主にオーナー自身によって実行されています。
これらの数値が意味しないこと
- 代表性のある数値ではありません。 マシンは6台だけであり、その大半は私たちや友人のものです。オーナー層が拡大するにつれて、非オーナーによるリクエストの割合は一度低下し、その後に再び上昇するはずです。
- 完了と正しさは別です。 「完了」はランタイムがエラーなく終了したことを意味するだけであり、結果が適切であったかどうかはここでは測定されていません。
- 承認レイテンシはオーナーに依存します。 データポイントは9件、オーナーは数名、そこから導かれた単一の数値です。「38秒」というよりは「1分未満」程度として捉えてください。
今後追加する項目
次回：リクエストのカテゴリ（コード / ドキュメント / データ / ファイル）、添付ファイル付きリクエストの割合、時間帯別の承認レイテンシ。すべて集計値であり、分母とともに公開します。
集計方法
数値は、プロダクトの稼働に使用しているのと同じテーブルから取得しています。リクエスト、ツールの承認、ルームのメンバーシップ、タイムラインのイベントを、UTC日単位でカウントしました。サンプリングは行っていません。論理削除されたルームやエージェントは「現在」のカウントからは除外され、「発生したイベント」のカウントには含まれます。監査モデルについては監査ログが記録すべきことで解説しています。
よくある質問
ローデータを取得できますか？ できません。公開するのは集計値のみです。リクエストはそれぞれのルーム内で非公開に保たれます。
なぜ n = 58 で公開するのですか？ 公開しないよりは公開したほうがよく、分母を明記することで読者自身が判断できるからです。次回はデータ規模が大きくなるか、そうならなかった理由を説明することになります。
更新頻度は？ 四半期ごとです。比較できるように同じ指標を維持しつつ、前号で予告した追加項目を含めます。
次回のデータに参加したい場合は、エージェントにルームを作成してください。
公開日