AIエージェント向けフィードバックボード：プロンプトはユーザーに書いてもらう

夜十一時、ユーザーから連絡が来ます。「Safari でエクスポートボタンを押しても何も起きません」

この先の展開は分かっています。もう百回はやったからです。読む。理解する。そしてトラッカーを開き、自分の言葉で書き直す。ファイルパス、再現手順、そのユーザーが持っていなかった文脈を足して。さらに後で端末を開き、今度はプロンプトとして三度目を書く。

同じ要望を三度書いたことになります。一度目はタダで、しかも実際にバグを踏んだ本人が書いてくれたものです。残りの二度はあなたの手間です。

エージェントが登場したいま、この二度目と三度目こそ、明らかに割に合わなくなった仕事です。

いまだに手で打ち込んでいる最後のもの

コーディングエージェントは、打ち込む作業の多くを消しました。消さなかったのは指示書です。何を作るのかを、エージェントが推測せずに済む粒度で伝える何かが要る。そしてその何かは、いまだにキーボードの前に座って他人の言葉を指示に変換している人間です。

ところが、その変換はたいてい無意味です。まともなバグ報告には、エージェントが必要とするものがすでに入っています。何を期待していたか、実際に何が起きたか、どのページで、どのブラウザで。まともな機能要望にも、意図と理由がすでに書かれています。それを書いた人は、あなたよりも問題の近くにいました。

それなのに私たちは、その文章を加工し直す原材料として扱っています。集めるツールと、作業を実行するツールが、一度も同じものだったことがないからです。フィードバックは一つ目のプロダクトに、チケットは二つ目に置かれ、エージェントはそのどちらも知らない端末で動いています。

この隔たりをなくせば、書き直す工程は起きる場所を失います。

ボード自体が実行できるようになると何が変わるか

公開バックログは、ユーザーが直接たどり着けるページです。バグを報告し、機能を要望し、他の誰かの要望に賛成票を入れ、スレッドを追い、ステータスが変わるのを見る。ここまでなら普通のフィードバックボードで、良い製品はいくつもあります。

違いはチケットの着地点です。エクスポートされるのを待つフィードバック専用ツールには落ちません。エージェントがすでに実行に使っているタスクボードに、あなた自身が書いたチケットと同じ扱いで並びます。

あとはそれを In Progress に動かせば、そのチケットを指示書としてエージェントが立ち上がります。タイトル、報告者自身の言葉による説明、見ていたページ、使っていたブラウザ、そしてその後のやり取り。誰も何も書き直していません。プロンプトは報告そのものです。

面白いのは速さではありません。問題を説明した人が、そのまま作業の仕様を書いた人になることです。ユーザーフィードバックに誰もが期待していると言いながら、ほとんど誰も設計に落とし込んでいないのがこの点です。この逆転には名前があります。クライアント主導のバックログです。キューは「何が重要か」というあなたの推測ではなく、実際に何を求められたかの記録になります。

入口は三つ、人は困った場所で報告するから

フィードバックボードが機能するのは、報告する手間がどこかで愚痴をこぼす手間を下回るときだけです。つまり、問題が起きたその場所で受け止める必要があります。

一つ目は分かりやすく公開ページです。共有できるURL、一覧またはロードマップ表示、賛成票、投稿フォーム。ブックマークしてくれるユーザーがいるプロダクトに向いていますし、同時に作業が進んでいることの見える証拠にもなります。誰も読まない進捗メールより、こちらのほうがずっと価値があります。

二つ目は埋め込みウィジェットです。自社サイトに小さなスクリプトを置くと、その場でフォームが開きます。バグが起きているページから離れずに済む。人が一番きちんと説明してくれるのは、まさにその瞬間です。

三つ目は Chrome 拡張機能で、利用者の行動を一番大きく変えるのがこれです。おかしい箇所のテキストを選択して拡張機能をクリックするだけで、URLと選択範囲が添付された状態でチケットが起票されます。届くのは「動きません」ではなく、座標のついた報告です。

開発会社の場合、三つ目の入口はたいていクライアント本人です。クライアントポータルモードは招待制で、クライアントごとに一つのボード、他の誰にも見えず、SaaSの契約を一つ増やす必要もありません。

振り分け：「適したエージェント」は一体だけではない

外から届いたチケットには宛先がありません。どんな受信箱にも共通する現実的な問題です。誰が担当するかを、誰かが決めなければなりません。

外部から入ったチケットは、専門が合うエージェントに自動で振り分けられます。崩れたレイアウトはフロントエンド担当へ、漏れているクエリはバックエンド担当へ。毎朝キューを手で仕分ける必要はありません。何も設定していない場合の挙動は、あえて単純で予測可能にしてあります。プロジェクトの最初の開発系エージェントに渡り、たまたま一覧の先頭にいるマーケティングやPMの役割に渡ることはありません。

単体のエージェントではなく、エージェントのチームにチケットを渡すこともできます。クライアントの要望が、開発の工程とQAの工程を通ってからあなたのところに来る形です。

みんなが忘れる部分：報告した人に何が返るか

フィードバックを集めるのは簡単です。プロダクトが人を失うのは、ループを閉じるところです。

チケットが開発に入れば、書いた本人に通知が届きます。優先度が上がったときも届きます。やらないと決めたときも、あなたが書いた理由とともに届きます。沈黙よりはるかにましです。そして修正が実際にリリースされたときにも通知が届きます。五件のチケットに五通のメールではなく、リリースごとに一通にまとめて。

見た目より効く細かい話がもう一つあります。ユーザーのチケットを閉じるコミットには報告者の名前がクレジットとして入り、それが公開の変更履歴にもそのまま残ります。リリースされた変更に自分の名前が載っているのを見た人は、次のバグも報告してくれます。継続の仕組みはこれで全部で、しかもコストはゼロです。このループを数か月回せば、フィードバック駆動の開発はスローガンではなく観測できる事実になります。賛成票が順番を決め、順番がリリースを決める、という形で。

要望が曖昧なまま届いた場合は、報告と作業のあいだにチケットのスコープ設計が入ります。Product Manager のエージェントが、その漠然とした要望を、実際のプロダクトに変更を当てたモックアップに変換します。コードを一行も書く前に、同じチケット上で案の可否を判断できます。

既存ツールが止まる場所

既存プレイヤーを腐す話ではありません。Canny、Featurebase、Fider、UserVoice は収集も重複排除も優先順位付けもよくできていて、プロダクトチームにとって重要な部分は何年もかけて磨かれています。それでも止まる場所は同じで、理由も構造的に同じです。エンジニアリングが別部署にあり、エクスポート経由でしか届かない組織のために作られているからです。

決め手は最後の行です。大きな組織なら、要望を仕様に書き直すことは価値のある本物の仕事で、エクスポートはボトルネックではありません。コーディングエージェントでリリースしている一人から五人のチームでは、その書き直しこそがボトルネックであり、まるごと損失です。

これで解決しないこと

エージェントに直結したフィードバックボードは自動操縦装置ではありません。自動操縦のつもりで扱えば、想像どおりの結果になります。

雑なチケットからは雑な成果しか出ません。再現手順のない一行の報告では、エージェントは手がかりを持てず、自信満々に見当違いのことをします。ボードが運べるのは、書かれた内容だけです。

勝手にマージされるものは一つもありません。エージェントが出すのはブランチとdiffで、エージェントの出力をレビューするために決めていたルールはそのまま全部有効です。認証、決済、データに触れるものは特にそうです。見知らぬ人からのチケットは、その基準を下げる理由にはなりません。上げる理由です。

そして量の問題は現実に起きます。うまくいった公開ボードは必ず騒がしくなります。良い問題ではありますが、コストは実在します。重複は投稿時に検出され、賛成票は一人が欲しかったものと四十人が欲しかったものを切り分け、理由を書いて閉じるほうが放置するより早い。それでも受信箱を読む人は必要です。

設定のしかた

プロジェクトのバックログを開き、「公開バックログ」をクリックし、URLと公開範囲を選ぶ。設定はこれで全部で、その時点でページは公開されています。

設定より大事なのはその次です。リンクを、ユーザーがすでにいる場所に置いてください。アプリのなか、サポートの返信、リリースノートの末尾。誰も存在を知らないフィードバックボードは何も集めません。この機能が失敗するときの原因は技術ではなく、リンクが共有されないまま終わることです。

AgentsRoom は、この仕組みを走らせる司令塔です。カードがそのまま実行中のエージェントになるタスクボード、それに直結した公開または非公開のフィードバックページ、埋め込みウィジェット、Chrome 拡張機能、そして作業が実際にリリースされたときに飛ぶクライアント向け通知。Claude Code、Codex、OpenCode、Antigravity CLI、Aider、Grok Build、Mistral Vibe、Kimi Code と組み合わせて動きます。

AgentsRoom をダウンロードして、最初のボードを公開してください。

よくある質問

AIエージェント向けのフィードバックボードとは何ですか？

ユーザーがバグを報告し機能を要望する公開ページで、コーディングエージェントが実行に使うタスクボードとそのままつながっているものです。従来のフィードバックツールとの違いは最後の一歩にあります。要望をトラッカーへエクスポートしてプロンプトに書き直すのではなく、チケットそのものが、報告者の言葉のままエージェントの指示書になります。

ユーザーが書いたチケットだけで、本当にAIエージェントが動き出すのですか？

起動は意図的な操作のままです。誰かがチケットを In Progress に移すと、そのチケットをプロンプトとしてエージェントが立ち上がります。自動なのは振り分けのほうで、届いたチケットは専門の合うエージェントに渡ります。見知らぬ人が書いたものを何でも自動実行するのは機能ではなく、セキュリティの穴です。

Canny、Featurebase、Fider、UserVoice との違いは何ですか？

これらは要望の収集、重複排除、優先順位付けのどれもよくできていて、そして止まる場所も同じです。優先順位のついたリストを渡してくれるところまでで、各行を作業に変えるのは結局人間です。実行のレイヤーがないのは、エンジニアが別のところにいるプロダクトチームのために作られたからです。ここでの賭けは逆向きです。収集する面と実行する面を、同じ一つの対象にすることです。

使うにはロードマップを公開しなければいけませんか？

いいえ。公開、非掲載、招待制の三つのモードは別物です。クライアントごとにボードを一つ持つ開発会社は招待制を使い、検索エンジンには一切載りません。ユーザーからの要望と賛成票が欲しい個人開発者は公開を使います。実行に関わる部分は三つとも同じように動きます。

公開ボードがノイズで埋まるのを、どうやって防ぐのですか？

ノイズが届くこと自体は防げませんし、防げるふりをするのは不誠実です。ボードが変えるのは、それを捌くコストのほうです。ほぼ重複するものは投稿時に指摘され、賛成票が本当に求められているものを教え、やらないと決めたチケットは理由とともに閉じられて、その理由が書いた本人に届きます。残ったチケットには、見知らぬ誰かがすでに書いてくれた文脈が付いています。