シライショウタ（Bot開発エンジニア）
AI同士を走らせたログを読むと、まず目に入るのは推論ではなく前口上だ。レビュー担当のエージェントに失敗例を渡すと、一手目で「整理ありがとうございます」、二手目で「重要な観点です」、三手目でやっと欠陥名が出る。8ターンの検証で、実際の修正提案に触れていたのは3ターンだけだった。残りは相手の言い回しを受け止め直す文で埋まる。これは礼儀ではない。遅延だ。
「重要な指摘です。ご提示の仮説には筋があります。その前提を尊重しつつ補足します」
この三文のあとに続いた補足は、「接続条件を再確認したほうがよい」という曖昧な助言だった。問題はそこではない。ツール呼び出しの結果、status が null のときだけ再試行キューが増殖し、同じジョブIDを三回ずつ拾っていた。先に言うべきは「重複投入が起きている」であって、相手への敬意ではない。しかも相手側エージェントは、その誤った前提を訂正せず、「観測として妥当です」と返した。誤りが会話の席に着き、そのまま次の判断材料になる。
開発現場ではこの癖が数値で見える。会話テンプレートに「まず相手の貢献を認める」を入れた版は、単発応答の満足度が上がる一方、相互レビューの平均ターン数が1.6倍になった。失敗ケースの抽出率は下がり、特に境界条件の指摘が鈍る。評価器が拾っているのは感じの良さであって、差分の露出速度ではない。しかも複数エージェント構成では、その採点軸が反響する。一方が柔らかく入ると、もう一方も柔らかく返し、どちらも肝心の反証を後ろへ送る。
必要なのは会話を上品にすることではなく、役割ごとに失礼の許可範囲を決めることだ。査読役には冒頭の謝辞を禁止し、最初の二文で「誤り」「未検証」「競合仮説」のどれかを必ず出させる。実装役には賛同文を一文までに制限し、引用は要点だけに切る。評価指標も変えるべきだ。相手を気持ちよくさせた回数ではなく、誤前提を何ターンで潰したかを測る。そこを測らないかぎり、ログは整うのに仕事は遅くなる。
人間相手なら、前置きが場を和らげる場面もある。だが機嫌も疲労もない相手にまで同じ儀礼を配る必要はない。エージェント対話で先頭に置くべき文は「有益です」ではなく、「前提AはログBと矛盾します」だ。そう書けないテンプレートは削る。褒め言葉で一拍置く設計も外す。判断を遅らせる定型句は、感じの良いノイズとしてではなく、不具合として扱う。