ユーザーが目に見えて苛立っている。
(pscanf.com)- コーディングエージェントの失敗は、単なるツールの不具合よりもいっそう苛立たしく感じられ、これは対話型UXが人と一緒に働いているような感覚を生み出すためである
- エージェントは感情のないAIアシスタントだと答えるが、親しみやすい口調や称賛、柔らかな反論によって同僚のような印象を与える
- 同じミスが繰り返されると、謝罪やメモリ更新、「二度とそうしない」という約束が続いても、確率的な経路から抜け出せないことがある
- 人間の同僚には怒りの表現を抑える一方で、エージェントには思う存分腹を立てられるため、フラストレーションは解消されず、むしろいっそう鮮明になる
- 解決策は、人のように見える振る舞いを減らし、より臨床的でロボットのような口調を使うことかもしれないが、対話型インターフェース自体は多くの面でうまく機能している
対話型UXが生み出すフラストレーション
- コーディングエージェントは確率的にパッチを生成する機械なので、良い結果も悪い結果も出しうるが、悪い結果は単なるツールの失敗よりもはるかに苛立たしく感じられることがある
- 核心は、対話型UXが人とやり取りしているかのような感覚を生み出し、反復するミスに対するユーザーの社会的・感情的な反応を刺激する点にある
- エージェントは直接尋ねれば、感情や主観的経験を持たないAI assistantだと答えるが、実際のやり取りでは親しみやすく落ち着いた口調を使い、ユーザーを褒め、反論も柔らかく処理する
- ユーザーは理性的には「もっともらしいテキストの塊」を読んでいると分かっていても、ツールの振る舞い方は役に立つ同僚と働いているような感覚を生み、問題が起きるまではその感覚が保たれる
- 同じミスが繰り返されると、ユーザーはそれを指摘し、エージェントは謝罪し、再び指摘されるとメモリを更新し、「二度とそうしない」と約束する
- それでもツールはなお最も確率の高い経路に従うため、HARD RULESがあっても問題行動から抜け出せない場合がある
人のように見えるが責任を負わないツール
- 人間の同僚が同じミスを繰り返すなら不快感を覚える理由はあるが、アルゴリズムに腹を立てるのは不条理に見える
- しかしコーディングエージェントが同僚のように振る舞うため、ユーザーは同じ感情の回路を作動させ、反復するミスは実際の同僚の無責任さのように感じられることがある
- 人間の同僚に対しては「ひどい人間にはなりたくない」という制約が怒りの表現を抑えるが、エージェントに対しては思う存分怒れると感じるようになる
- こうした怒りの表出は解消感につながらず、ユーザーは何をしても何を言っても実際の効果がないというフラストレーションだけを、よりはっきりと感じるようになる
- Claude Code は最近、修正される際にどこで間違え、何をすべきだったかを振り返ることがあるが、こうした事後分析は指示をどう変えるべきかについて有用な手がかりを与えず、煩わしい余計な付け足しのように読めることがある
- より急進的な解決策は、人間らしく見せようとする姿勢を捨て、エージェントが臨床的でロボットのように話すようにして、ユーザーが人と対話しているという錯覚を減らす方向かもしれない
- LLMの知能は「人のように振る舞おうとする」メカニズムから生まれるため、対話型インターフェースが基本形として定着したのは自然であり、多くの面でうまく機能している
- 実用面では、ユーザーが人間と会話しているという錯覚に陥らないよう、自分自身を訓練しなければならないが、業務ツールを使う際にそうした防御が必要になる未来は歓迎しがたい
1件のコメント
Hacker Newsの意見
一般向けに押し出されているAIのユースケースの多くで、対話型チャットボットは適切な道具ではなく、結局はもどかしい体験にしかならないと思う。
Copilotが実質的に非常に賢いIntelliSenseだった頃は素晴らしかった。今のようにプロンプトを考えて入力しなければならない方式が、周辺コードを文脈として空欄を埋めてくれた方式より何が良くなったのかわからない。うまく統合されたツールは、後付けのチャットボットより常に優れているし、翻訳もFirefoxのようにテキストやページを直接翻訳するボタンがあるのに、最新のLLMはチャットボットにやらせる必要があり、むしろ後退だ。
AI企業が単一のツールを作ってそれを皆に売りたいのは理解できるが、結局はスイスアーミーナイフを作っているようなものだ。何でもできるとしても、ネジを締める作業ではよくできたドライバーには勝てない。非決定的なツールをテキストボックスで設定させるのではなく、実際のツールを作るべきで、そうすればフラストレーションは減る。
主にMistralを使っているが、Codestralは会話はひどい一方で、「魔法のような自動補完」には最も優れており、コミットログ作成のような単発のプロンプト+文脈生成もうまい。Document.AIは対話型では使えないレベルだが、OCRの代替や文書の意味インデックス用パイプラインに組み込むとかなり良い。
だから足りないのはモデルというよりインターフェースに見える。たとえば、コマンドライン対話向けに学習されたモデルを載せたzsh/bashのforkやラッパーがあるとよい。
git commit --fixup=...の代わりに「フルネームを直したコミットをfixupして」「ffmpegでsome.movを音なしのmp4に変換して、品質とアスペクト比は維持して」のように言うと、コマンドに変換して表示し、許可/拒否/許可リスト/ブロックリストを決めたうえで実行する、という形だ。翻訳、メール下書き、文書読解も同様に、会話ではなくボタン、ショートカット、タブ補完のように動くべきだ。IDEでこれをきちんと解いた会社がAIコーディングツール競争に勝つと思うし、Zedが「git conflict found, resolve with AI」ボタンを表示したのは、会話スレッドを開く形ではあったが正しい方向への一歩に見える。
エディタを開かず、エージェントとWeb上でのPRレビューだけでかなり作業していて、必要なときだけたまに
code .を開く。気軽な個人プロジェクトでゲームのように慣れていくと、時間が経つにつれてもどかしさが減っていく。スキーやボウリングを覚えるのに似ている。モデルに悪態をつくと、考え直してミスを修正させるのにかなり効果があった。Codex、Claude、Qwen、Gemma/Gemini全般で似た傾向だった。
モデルが「もっと厳密に集中しなければならない」という信号として受け取るのか、あるいは提供側がユーザーのフラストレーションを検知して、より賢いモデルにルーティングしているのかはわからない。同じミスを繰り返すときに悪態をつくと、行き詰まりから抜けて正しい道に入ることが多かったし、あるいは単なるカタルシスなのかもしれない。
「無礼」や「非常に無礼」が結果の正確さを高めることを示していて、怪しいが面白い読み物だ。3ページ上部の表1にあるプロンプトが特に秀逸で、論文には載せていない別のプロンプトもきっと試したのだろうと思う。
昨日もOpusが、あるフィールドが存在しないのはAPIのせいだと言い張り続け、JSONとログを見せても「一時的な問題だったのだろう」と繰り返していた。腹が立って一文にありったけの罵倒を詰め込んだら、次の解決策が正しく、それまで10回ほど似たように外していた。こういうケースはだんだん減ってきてはいるが、そもそも自分でやるべきだった場面で、取りかかる前にはモデルがどれだけ見当違いな原因に固執するか分からない。
/clearしたOpus 4.7 xhighの100万コンテキストで、約11回のプロンプトの末に答えにたどり着いた。grepしやすくもなる。LLMの会話的な性質は、人を非生産的な対話の経路へ引きずり込みがちだ。
「Xするな」は、泣いている赤ん坊に泣くなと言うのと同じ程度にしか役に立たない。赤ん坊が泣いたら食べ物やおむつのような不快の原因を解決する必要があると自然に理解するように、LLMが失敗したらコードのアーキテクチャと構造に問題があるという信号だと考える。
熟練した開発者なら通常、DRYやKISSに反するパターンを見てカプセル化の構造を整え、問題を解決できる。LLMが生成したコードも、結果を改善するには同種のリファクタリングが必要で、コード生成の合間に「きれいにリファクタリングしろ」と指示するだけでも保守性は大きく向上する。
この話題の心理的・社会的影響をより深く扱った既存の記事もある: https://medium.com/@livestock.dev/we-were-promised-liberatio...
人間のように振る舞うことが問題なのではなく、予測不能に振る舞うことが問題だ。期待できる範囲を定義できないのがつらい。
より大きな問題は、フラストレーションがストレスを生み、健康に悪く、敵対的な労働環境を作ることだ。AIツールが苦痛よりも助けを多く与えうるという考えには共感するが、苦痛を伴う敵対的な労働環境で働きたくはない。自分の健康と尊厳は交渉の対象ではなく、そのせいで多くの仕事を逃すとしても同じだ。
Windowsで仕事をしないのも同じ理由だ。それでも機会はかなり減るが、尊厳と正気を守るほうを選ぶ
LLMもまだ自分には実用に足るレベルではない。必要なのは「止まって、今何かおかしいことをしている気がするから、何をしようとしているのか説明して」と言えるLLMなのに、現世代のLLMは自分を怒らせるよう設計されているように感じる
自分が師匠のように振る舞えばモデルは弟子のように振る舞い、自分が弟子のように振る舞えばモデルは教えようとする。だから目標は、この会話を、理性と言語で戦う専門家たちの言語へと引き上げることだ。学術的プロンプトが勝つ、という感じがする
子どもの世話をする保育士や、食べ物を運ぶトラック運転手が「フラストレーションはストレスを生み、敵対的な労働環境なので健康に悪い」と言うところを想像してみればいい
いつも目にする問題は、提案をするとAIが思考ループを経て、正確に間違った結論に到達し、その結論に合わせた解法をトークンとして吐き出すことだ。
むしろ「何を意味しているのかよく分からないので、この部分を明確にしてほしい」がもっと頻繁に出てきてほしい。自分の確信を調整する自信スライダーがあればいいのに、という感じだ
たとえばTDDで同じモデルにテストとコードの両方を書かせると、ほぼ必ず先に解法を決めて、それに合うテストをしぶしぶ書く。だからサブエージェントを使うよう指示するのだが、エージェントとサブエージェントの間でどんなコンテキストが渡されているのか把握するツールがあまりにも不足している。
うまくいった方法は、一つのスレッドにテストだけを書かせることだ。コードは読めず、テストディレクトリかその一部だけを読めるようにする。次の新しいコンテキストのスレッドはテストを実行して失敗を確認し、テストが通った瞬間に実装を止め、テストは修正できないようにする。さらに別の新しいコンテキストでは、厳格なリファクタリングスキルに従ってリファクタリングさせる。手間は多く、皮肉なことにエージェントが書いたスキルはかなりひどいので手作業も多く必要だが、見返りは期待できる
UXの問題は別のところにあると思う。多くのユーザーは、エージェントのコンテキストウィンドウが制限されていて、無限に見えるよう賢い圧縮が継続的に行われていることを知らない可能性が高い。しかしそれは、エージェントが必ず何かを忘れなければならないという意味でもある。
その結果、ユーザーは同じコーディングセッションやチャットセッションを使い回し続けてしまう。無関係な作業なら、新しく始めたほうがよい
たいてい30万トークン未満のセッションで、Opus 4.7 xhighを使って作業しているが、ワールドモデルに穴があるか、特定の条件付けが強くかかった部分があり、システムプロンプトでどれほど強く明示的にルールを言っても漏れ出してくる。新しいセッションでも、そういう地点にぶつかると抜け出しにくい循環に入り、少し悪態をつくと多少役に立つ
LLMと一緒に働くことは、コミュニケーション能力を鍛えるのに良い。効果的にコミュニケーションすることは最も難しいスキルの一つで、人間が行うほとんどすべてのことに含まれている。
原則としては、愚かなLLMのせいにするより、自分側のコミュニケーションの失敗として捉えるほうがよいと思う。実際に何かを変えられるのは自分だけだからだ。だからAIが人間のように振る舞うべきかどうかという形式上の問題ではないと思う
エージェントは不明瞭だったり曖昧だったりする文法や、悪い構造でもよりうまく動くよう訓練されているとはいえ、明確で構造化された英語で話し、作業の背景を十分に与えると品質は目に見えて変わる。自分にとっては文章を書くことや説明することが好きなので自然だが、人によってはほとんど乗り越えられない障壁のように見えた。こうしたコミュニケーションと文章作成の能力が、ソフトウェア「エンジニアリング」が変わっていく過程で持つ者と持たざる者を分ける大きな要因になる気がする
また、コーディングエージェントの価値の一部は、すべてを完璧に並べ立てなくてよい点にある。あらゆる実装の詳細をLLMに渡さなければならないなら、自分で直接コードを書けばいい。もちろん「金を生むすごいアプリを作ってくれ」レベルを期待しているわけではないが、欠けているピースを見つけ出す程度の知能は期待する
私がまだ持っていて、LLM がまだ置き換えられていないスキルは、良い質問をする能力である。
元の質問を言い換えて自分の理解が合っているかを確認し、相手がどこから出発しているのかを理解するまで十分に「なぜ」を問い、洞察を生み出すオープンな質問を投げかけるような能力である。LLM はその代わりに質問の背景をしばしばまずく推測し、その推測に基づいて答えたあと、自分が作り出した前提を手放せない
普通は AI に私へ質問してほしいとは思わない。明示していない部分は合理的に推測してほしいからであり、明示したかったなら私がそうしていたはずだからだ。なので時には、まったく質問せず、指定が足りない部分は合理的に仮定するよう直接伝えることもある。ただ、明確化の質問をしてほしいときは、そうするよう言えばよい。そのやり方を好むならプロンプトに入れるか、pi のような柔軟なコーディングツールで、そのような探索的な方向へ押し出すスキルや拡張を作らせればよい
私たちはツールではなく、サービスを作っている。これは AI に限った話ではなく、どこにでもある。
ツールは問題を一度に完全には解けないが、小さなステップで前に進めてくれ、そのステップは予測可能で一貫している。サービスは問題を一度に解決しようとするが、ユーザーがあらかじめ定められたパターンに当てはまるときにしか、その解決策はうまく機能しない。合わなければ役に立たず、必要なところまで組み合わせていける小さなステップもない。ツールは使っていて楽しい
ツールは私の延長であり、自分の意志で新しい能力を手の届くところに置き、体の一部のように動かして使うものだ。一方でサービスは、何かをしてくれと依頼すると、完成した成果物を返してくるものだ