LayerX エンジニアブログ

LayerX の エンジニアブログです。

人からAIへのフィードバックデザインパターン

こんにちは。バクラク事業部で機械学習エンジニアをしている伊藤（@sbrf248）です。最近はオンライン上で日々流れてくる情報が膨大なので、頭の整理のため紙とペンをよく使うようになりました。GWには（手の届く範囲で）少し高価なボールペンを買ってみました。

さて、近頃はAI・LLMを組み込んだプロダクトやシステムが当たり前になってきています。

私の携わる「バクラク」でも様々なAIエージェントをプロダクトに組み込み、あらゆるバックオフィス業務の自動化を進めています。

bakuraku.jp

AI・LLMを組み込む場合、最初に作ったものがそのまま完成ということはあまりなく、継続的な性能の改善が求められるケースが多くあります。特に、ユーザーごとに体験を最適化するパーソナライズされたシステムの場合は、ユーザーのフィードバックをいかにして収集し活用するかが重要です。

日々重要性が高まってきている「ユーザーのフィードバックをいかにして収集し活用するか」について、先日開催されていたHuman-Computer Interactionの学会であるCHI（CHI2026, CHI2025）の論文を中心に事例を調査してみました。このブログでは、調査した研究事例やポイントを紹介します。

全体像

LLMに限らず、機械学習モデル等を組み込むAIシステムは多々ありますが、ここではLLMを中心に考えます。LLMを組み込んだシステムは、大まかには次のような構成になると思います。

流れとしては、何らかの出力に対してユーザーからのフィードバックがシステムに与えられると、それを使ってシステムの一部が更新され、結果的に出力に反映されます。

更新する対象は、大まかに3種類に分けられます。

  • モデル自体
  • プロンプト
  • その他（入力データや前処理、LLMの出力のフィルタ処理など）

LLM本体を自前でservingするのは運用コストが大きいため、OpenAIなどのプロバイダが提供するAPIを利用するのが一般的だと思います。また、フィードバックを反映するコストを踏まえると、多くのケースで更新対象はプロンプトやその他の部分になるでしょう。

ここからは、「ユーザーから何らかの形式で与えられたフィードバックをプロンプトやその他の部分に反映し、システムの出力を改善する」問題についての研究事例を見ていきます。

研究事例

Feedback by Design: Understanding and Overcoming User Feedback Barriers in Conversational Agents [1]

この論文では、会話エージェントにおけるユーザーのフィードバックの品質について調査しています。

会話エージェントはチャットを使ってAIとやりとりするプロダクトで、代表的なものにChatGPTやClaude Codeなどが挙げられます。ここで、ユーザーのフィードバックは「自然言語」として与えられます。つまり、「〜〜みたいに修正して」のような文章を入力してシステムに送信することで、それがプロンプトなどの形式でLLMに渡され、出力が更新されます。

この論文の著者は、会話エージェントのフィードバックは低頻度・低品質になりやすいと指摘しています。理由は大きく4つ挙げられています。

  1. AIの出力が文脈・目的からずれていく: 会話エージェントが元々あったゴールを維持できず、制約を無視したり別の方向に進んだりした結果、ユーザーが「追加で説明しても直らない」と判断してしまう。
  2. 出力を検証するコストが高い: 出力にハルシネーションや存在しない引用があると、ユーザーはまず文章自体の正しさを確認しなければならず、負荷が重くなる。
  3. モデルが曖昧さを確認しないため、ユーザーだけが説明責任を負う: ユーザーの指摘が曖昧でも、モデルが確認質問をせず修正を入れてしまうことがある。そのためユーザーは「何を・どの粒度で・どう直すべきか」を自分で言語化し続ける必要がある。
  4. どの程度の情報を与えればよいかわからない: モデルが重要な点を落としたり、逆に不要な変更を加えたりする。それら1つ1つに対するフィードバックが難しく、「try again」のような最小限の指示になってしまう。

要するに、どこをどう直せばいいのかユーザーにとってわかりづらい状況で、かつ自由形式の入力欄だけが与えられていると、今の出力をより良くするためにどうフィードバックすればいいかをユーザーが考えて言語化する必要があります。これは負荷が大きく、結果として短く曖昧な修正やセッションのリセットなどに退避してしまうため、品質の低下やそもそもフィードバック自体を避けてしまう結果につながってしまいます。

これを踏まえて、論文では出力の一部をハイライトして「この部分が違う」と指摘できるようにする、修正前後の差分を見せる、AIがどのようにフィードバックを解釈したかを明示する、Undo/Redoを用意する、といったインターフェース設計を考案・検証し、体験の改善を確認しています。

この研究から、ユーザーの操作にある程度の型を用意し、その中で試行錯誤しやすい状況を作り出すことで、高品質なフィードバックが期待できるようになると示唆されます。

End User Authoring of Personalized Content Classification [2]

この論文では、ユーザーが自身の好みに合わせてYouTubeコメントの分類器を作るというタスクについて、3つのフィードバック方式を実験的に比較しています。

  1. Label System: サンプルとなるコメントが与えられるので、それを分類器の学習に使うかどうかを選択する。分類器は簡単なMLベースのモデルを利用する。

    [2] より引用

  2. Rule System: 用意されたインターフェースを使い、コンテンツを分類するルールを作成する。

    [2] より引用

  3. Prompt System: LLM分類器のプロンプトを調整（文章の修正やfew-shot exampleの変更）する。

    [2] より引用

結果としては、Prompt Systemが最も早く高精度の分類器を作成できました。一方で、参加者はLabel SystemやRule Systemの方が、やることが明確で使いやすいと感じたようです。またRule Systemについては、特定の語句やイベントに基づくフィルタリングという観点では高い精度を出していたようです。

この結果を踏まえて著者は、それぞれのメリットを活かすハイブリッドな手法が適切ではないかと述べています。例えば、少数のLabel Exampleからプロンプトを生成したり、Rule SystemとPrompt Systemを併用した手法などが挙げられています。

この研究からも、プロンプトをユーザーが直接編集するよりは、操作にある程度の制約を設けつつ、ユーザーが迷わない形でフィードバックを送れる設計が良い選択肢となり得ることがわかります。

Promptimizer: User-Led Prompt Optimization for Personal Content Classification [3]

この論文は、ユーザーに様々な形態のフィードバック方式を提供しつつ、コンテンツ分類器のプロンプトを改善する手法を提案しています。

[3] より引用

具体的には、ユーザーは初期説明の記述、誤分類された例へのラベル付け、失敗パターンの優先付けなど、複数の粒度のフィードバックを段階的に与えることができます。重要なのは、最終的に出来上がるプロンプトがユーザーにとって読める・解釈可能な形で残ることです。完全自動の最適化だと、内部でプロンプトがどんどんブラックボックス化していき、ユーザーがよくわからないままプロンプトが更新されていく状況に陥ってしまう場合があります。

論文中の実験では、ユーザーは完全自動のプロンプト最適化よりもPromptimizerの方式（人間が途中に介入できる形）を有意に好むという結果が示されています。また、YouTubeのコメント管理ツールへの組み込み実験では、3週間の実利用を通じて、ユーザーがそれぞれの目的に合った多様なフィルタを作り、運用できることが確認されています。

この研究からは、自動最適化を導入する場合でも、ユーザーが過程に関与できる余地と、結果を解釈できる出力を残すことが重要だとわかります。

Preference-Guided Prompt Optimization for Text-to-Image Generation [4]

この論文も同様にプロンプト最適化の手法ですが、ユーザーは2つの選択肢からより良いものを選ぶだけというかなり限定的なフィードバック方式です。

[4] より引用

対象タスクはtext-to-imageの画像生成で、ユーザーが画像生成のプロンプトを直接書いて調整するのは負担が大きいという課題に取り組んでいます。画像生成は出力が予測しにくく、頭の中のイメージを文章に落とし込むこと自体が難しい一方で、「2つ並べたらどちらが好みか」は比較的簡単に判断できます。この性質を利用して、ユーザーには2択選好だけを返してもらい、システム側がプロンプトを自動的に更新していきます。

提案手法の特徴は、ユーザーのフィードバックを使って探索方向を狭めていく（exploit）一方で、適度に新しい方向も試す（explore）バランスを取っている点です。選好フィードバックだけでは、初期の好みに引きずられて局所最適に陥りやすいので、このバランスは実用上重要です。実験では、手動でプロンプトを書き換える場合に比べて少ない反復回数・低い認知負荷で満足のいく結果に到達できることが示されています。

ここから言えるのは、「ユーザーに言語化させずに済むフィードバック方式」も有力な選択肢になるということです。タスクによっては、自由記述や明示的なルール記述よりも、選好比較の方がユーザーの認知負荷が小さく、フィードバックを継続的に集めやすくなります。

Data-Prompt Co-Evolution: Growing Test Sets to Refine LLM Behavior [5]

この論文は、フィードバックループの中でプロンプトの更新とそれを検証するテストデータの更新を同時に行う手法を提案しています。

[5] より引用

ここで扱っているのは、「プロンプトを直してもそれが過去にうまく動いていたケースを壊していないかわからない」という問題です。

従来の機械学習開発でもありましたが、テストデータを十分に整備せずプロンプトエンジニアリングを進めると、今注目しているサンプルの精度は改善したものの、実は過去問題なかったサンプルの精度が悪化する、といった問題に直面する可能性があります。

論文は、この問題に対して、テストデータとプロンプト指示を一緒に育てていくワークフローを提案しています。具体的には、ユーザーが運用中に見つけたエッジケースをテストセットに追加し、なぜその挙動が望ましいのか・望ましくないのかという根拠を明文化し、修正したプロンプトを成長したテストセットに対して評価する、というループを回します。

この研究の重要な視点は、ユーザーからのフィードバックを「単発の修正要求」で終わらせず、「テストケース＋期待挙動＋根拠」というセットで保存していくところにあります。こうしておくと、後からプロンプトを変更した際にも回帰的に検証でき、改善の積み上げが効きやすくなります。

まとめ

ここまで、人間からAIへのフィードバック方式を、研究事例をふまえて紹介しました。個人的には、適切な制約を加えることで、自由記述形式よりもユーザーが使いやすく、かつ高品質なフィードバックが実現できる事例が見られたのが印象的でした。

もちろん前提として、考えているタスクの性質やシステムへの組み込み方によって、最適なフィードバック体験は異なります。その上で、（当たり前のことではありますが、）ユーザーが迷わずにフィードバックでき、それが出力の改善に納得できる形で結びつくような一連の体験を目指すべき、ということは一貫していると感じます。

LLMの表現力が高まっているからこそ、プロダクトを作って提供するだけでなく、使っていただくユーザーと共にプロダクトを磨き込めるような体験を目指していきたいと思います。

最後になりましたが、LayerXではAI・機械学習に携わるエンジニアを募集中です。ユーザー価値を第一に考えたAIエージェントの社会実装に興味のある方は、ぜひご応募ください！

open.talentio.com

jobs.layerx.co.jp

参考文献