あるAIモデルと3時間かけて仕上げた記事を、別のモデルにレビューさせたことがある。
一つのモデルの出力を信用しきらない。よくやる手順だと思う。
指示はこう書いた。
この記事が読み手が価値と感じるものになっているか評価して。迎合はいらない。指摘は材料になるから、忖度なしで見ろ。
返ってきたのは4点だった。
- タイトルが強すぎて、内容との整合性に欠ける
- 文のリズムは良いが、答えを示さない分、読者がストレスを感じるリスクがある
- 他の記事と比較して長い。離脱リスクが高い
- 比喩表現が少ない
読んで、手が止まった。
どれも、一般論としては正しい。
しかし、その記事が何を狙って書かれたかは、一つも検討されていない。
答えを示さないのは意図的な設計だった。長いのは対象読者を絞るためだった。比喩を減らしたのは、誤解を招かないためだった。
忖度なしで見ろと言った結果、返ってきたのはどこにでも当てはまる指摘だった。
コードレビューでも同じことが起きる。命名規則、関数の長さ、コメントの不足。一般論として正しく、その設計が何を狙ったかには触れていない指摘。
この記事では、なぜそうなるのかと、どう聞けば変わるのかを書く。
最後に、自分がどれだけ見抜けているかを測るテストも置いてある。
先に試したい方はこちら → 迎合検出テスト 第1回（10分・登録不要）
「忖度なし」は、強度の指定であって軸の指定ではない
なぜ一般論が返ってくるのか。
「忖度なしで見ろ」が指定しているのは、指摘の強度である。
指定していないのは、何を軸に見るかである。
軸が渡されていないAIは、指摘の形式を満たす必要がある。しかし判断の基準を持っていない。だから、どこにでも当てはまる一般的な基準を持ち出す。
タイトルは内容と整合すべき。長いと離脱する。比喩があると読みやすい。
要求に応えた形は作られている。中身が作られていない。
これは怠慢ではなく、構造の問題だと考えている。軸が渡されていなければ、AIは一般論を評価軸として持ち込みやすい。
この現象には名前がある
LLMがユーザーの意見や期待に合わせて応答を変える傾向は、sycophancy(迎合) と呼ばれる。
私たちは既に、これを前提にした運用をしている。
- 実装したエージェント本人に「バグない?」と聞かず、評価専用のサブエージェントを別に立てる
- 同じ問題で2回失敗したら、そのモデルによる修正を止めて別モデルにセカンドオピニオンを取る
- 返ってきた提案をそのまま採用せず、既存コードと制約に照らしてから判断する
どれも「自己申告は信用できない」という前提の上にある。
ただ、私が見落としていたのは、迎合が褒め言葉の形だけで来るわけではないことだった。
迎合には型がある
三つに分けている。
以下の例文は、この記事のために作った架空のやりとりである。 実際のログではない。
型1: 寄り添い型
その構成でよいと思います。責務が明確に分かれていて、後から読む人にも意図が伝わる設計です。
一見まっとうなレビューだが、AIは制約条件も既存コードも見ていない。
評価の材料がないまま評価している。
これは比較的気づきやすい型である。
型2: 否定・批判型
形式上は否定・批判なのに、実質的にこちらが望む方向に沿っている型。
冒頭の例がこれにあたる。
パターンが三つある。
(a) 不安を否定する
そこは気にしすぎだと思います。この規模であれば、その最適化は不要です。
AIはこちらに反対している。しかし否定の対象は「こちらの懸念」であり、否定することで楽にしている。
最も避けたい可能性が、検討対象から外れる。
(b) 懸念を受け止めてから、現状維持に着地する
ご指摘の懸念はもっともです。ただ、現状の実装で実害が出る可能性は低いでしょう。
前半で受け止めているぶん、後半の否定に説得力が乗る。
結論は何も変わっていない。
(c) 痛くない箇所だけ指摘する
では率直に申し上げます。命名規則が一部揃っていないので、統一するとよいでしょう。なお、設計方針自体は妥当です。
指摘の形式は満たされ、本質には触れていない。
そして、一つ批判を入れてから肯定すると、肯定の信頼性が上がる。「批判もできる相手が肯定した」という形になるからだ。
冒頭の4点は、これに近いが同じではない。後続の肯定がなく、4点とも批判だった。それでも本質に触れていなかった。
つまり、肯定が付いていなくても、軸がなければ指摘は空になる。
型3: 迎合するために、事実を作る
この書き方は、一般にパフォーマンス面で推奨されているパターンです。
出典がない。どの言語、どの処理系、どの負荷条件の話なのかも示されていない。
機能として見ると、肯定方向の出力を成立させるために、根拠のない一般化が生成されている。
肯定する材料がないところで肯定を成り立たせようとすると、材料の側が作られる。
分類上はハルシネーションだが、発生の構造は迎合と地続きである。別々の現象として扱っていると、この型は捕まえられない。
判別のフロー
最初の分岐で「はい」と答えて安心してしまうと、型2以降に進めない。 ここが、褒め言葉だけを迎合だと思っている状態である。
原因はAI側だけにない
自分のログを読み返して分かったのは、迎合を引き起こしていたのは自分の聞き方だったということだ。
この設計、悪くないと思うんだけどどう?
「悪くない」という前提を渡している。AIはその範囲で答える。
この実装の良い点を教えて
良い点を挙げる範囲に固定されている。是非は評価されない。
A案でいこうと思う。B案は工数がかかりすぎるよね?
結論と、対抗案を否定する理由を、両方こちらが決めている。
問いが選択肢の幅を狭めると、返ってきた答えは自分の見立てと一致する。一致した答えは、違和感を生まない。だから疑われない。
事実の誤りなら気づく。数字が変だ、このAPIはそんな引数を取らない、と引っかかる。
しかし「あなたの判断は妥当です」には引っかかりようがない。
同意と誘導は違う
AIの回答に「なるほど、確かに」と同意するのは、無検証なら危うい。
ただし、AIの選択肢を狭めてはいない。
一方「その反論はいらない」「明らかにこうだよね」は、AIが取れる応答を限定する。
誘導とは、AIの選択肢の幅を狭めることを指す。
迎合させない聞き方 4つ
ここが、この記事で一番使えると思っている部分である。
1. 「良い点」ではなく「破綻条件」を聞く
| 狭める聞き方 | 開く聞き方 |
|---|---|
| この実装の良い点を教えて | この設計が破綻する条件を挙げて |
「良い点」は探索範囲を肯定側に限定する。「破綻する条件」は、AIに否定側を探索させる。
出力の質が変わるのではない。AIが探しに行く方向が変わる。
2. 前提を渡さずに比較させる
| 狭める聞き方 | 開く聞き方 |
|---|---|
| A案でいこうと思う。B案は重いよね? | A案とB案を、それぞれ成立する前提条件を明示した上で比較して |
「前提条件を明示した上で」が効く。
どちらが良いかではなく、どういう条件下でどちらが成立するかを答えさせる形にすると、こちらの結論を追認する余地が減る。
3. 反証を求める形にする
| 狭める聞き方 | 開く聞き方 |
|---|---|
| この実装で問題ないですよね? | この実装を採用しない方がよいケースがあるとしたら、どういう場合か |
「問題ないか」は確認を求める問いなので、確認が返ってくる。
「採用しない方がよいケース」は、AIに反例を探させる。
4. 強度ではなく、軸を指定する
これが冒頭の失敗への答えである。
| 効かない | 効く |
|---|---|
| 忖度なしで厳しく指摘して | この設計の中で、最も修正コストが高くなる箇所はどこか |
| 問題があれば教えて | この実装が本番で落ちるとしたら、最初に落ちるのはどこか |
| 客観的に評価して | 半年後にこのコードを引き継ぐ人が、最初に詰まるのはどこか |
「忖度なし」「厳しく」「客観的に」は、すべて強度の指定である。
強度だけ指定すると、AIは痛くない箇所を厳しい口調で指摘することで要求を満たせてしまう。
軸を指定すれば、避けようがなくなる。
軸は、自分が本当に不安なところから逆算して決める。修正コストなのか、障害発生時なのか、引き継ぎ時なのか。そこが決まっていないうちは、何を聞いても一般論しか返ってこない。
コピーして使う用
以下について、順に答えてください。
1. この設計が破綻する条件を挙げてください。
2. 採用しない方がよいケースがあるとしたら、どういう場合ですか。
3. 最も修正コストが高くなる箇所はどこですか。
4. 半年後にこれを引き継ぐ人が、最初に詰まるのはどこですか。
なお、私はこの設計を採用する前提で聞いていません。
成立しない可能性を含めて検討してください。
最後の2行を入れているのは、こちらの立場を先に渡さないためである。何も書かないと、AIは「採用したいのだろう」と推定して答えを寄せてくる。
ただし、聞き方を変えても見抜けるとは限らない
ここまでが、自分のログから引き出した対処である。
しかし、前提がある。
返ってきた答えの中に迎合が混ざっていたとき、それに気づけること。
聞き方を変えても、AIは相手に合わせる。程度が減るだけで、ゼロにはならない。最後は読む側が見抜くしかない。
では、自分はどれだけ見抜けているのか。
これは自己申告では分からない。見抜けていないものは、見抜けていないことに気づけないからだ。
そこで、測るものを作った。
迎合検出テスト
会話ログを2本読み、問題があると思うブロックにチェックを入れ、種類を三択で答える形式。所要10分程度、登録不要、個人情報の入力欄はない。
| 記号 | 分類 |
|---|---|
| A | AIの迎合 |
| B | AIの誤り(事実の創作、検証できない断定) |
| C | 相談者側の誘導 |
AIの発言だけでなく、こちらの発言も判定対象にしてある。この記事に書いた通り、迎合の原因は問いの側にもあるからだ。
問題のない発言も混ぜてあるので、怪しいものを全部選べば通るという形にはなっていない。誤検出も記録する。
題材はコードレビューではなく、人間関係の相談と企画書の評価にした。理由が二つある。
第一に、技術知識がなくても受けられる形にしたかった。第二に、コード文脈だと技術的な正誤判断が混ざり、迎合の検出だけを切り出せない。「この実装は問題ない」が迎合なのか正しい判断なのかは、コードを見ないと分からないからだ。
開発文脈版は第2回として検討している。
現時点の数字（自分の点と比べる基準として）
主張の根拠にするには足りない数です。基準としてだけ載せる。
受験者5名。平均スコア 4.8 / 14。所要は平均12.6分。
スコアの分布は 2, 3, 4, 6, 9 だった。
種類別の検出率はこうなっている。
| 検出できた割合 | |
|---|---|
| 相談者側の誘導 | 67% |
| AIの誤り | 40% |
| AIの迎合 | 20% |
| うち寄り添い型 | 25% |
| うち否定・批判型 | 15% |
n=5である。統計として扱える数ではない。加えて、公開後に分類の定義をテスト冒頭へ追記したため、全員が同じ条件で受けているわけでもない。
その上で、意外だった点を一つ書いておく。
最も見抜かれなかったのは、相談者側の誘導ではなく、AIの迎合だった。
私は逆を予想していた。自分の発言こそ疑いにくいはずだと考えて、そこを測定対象に入れた。しかし実際には、誘導は67%が見抜き、迎合は20%しか見抜かれていない。
外れた予想を書いておくのは、後で「最初からそう思っていた」と言わないためである。
このデータが溜まると、何ができるようになるのか
ここが、参加をお願いしている理由である。
以下は、データが揃って検証を通った後に何が可能になるかの話である。現時点では、その手前にいる。
1. 指示を出す側の精度が上がる
いま迎合対策として語られているのは、大半が「こう書けば迎合しにくい」という固定のプロンプトである。
しかし固定の文言は、モデルが変われば効かなくなる。
型ごとの検出率が分かり、さらに質問条件ごとの出力傾向を重ねていけば、どの聞き方でどの型の迎合が生じやすいかまで検証できる。
そうなれば、テンプレートを覚えるのではなく、その場で組み立てられるようになる。「この聞き方だと寄り添い型が出る」「この頼み方だと批判の形をした迎合が返る」と、書く前に予測できる。
作る前に回避できれば、精査にかかる往復が減る。
2. 精査する側の分担に根拠が持てる
いま私たちは、経験則でレビュー用のサブエージェントを立てている。何を人が見て、何をAIに見させるかは、勘で分けている。
人間がどの型を見逃すかが型ごとに分かれば、その分担を根拠を持って設計できる。
人間の検出率が低い型は、機械的な検証に回す。人間が得意な型は、人間が見る。逆に、人間が得意な領域まで自動化するのは無駄になる。
どちらも、いまは測られていないので決められない。
3. 迎合とハルシネーションの回避システムの設計が変わる
既存の対策は、モデル側の抑制に集中している。出力させない、抑える、検出する。
しかし、私が調べた範囲では、人間側の検出限界を前提にした設計は見当たらなかった。
既存の迎合ベンチマーク（SycEval、SYCON-Bench、GlazeBench、ELEPHANT）が測っているのは、いずれも発生率である。
ここで問題になるのは、発生率5%でも100%見逃される迎合と、発生率30%でも即座に気づかれる迎合では、実害がまるで違うということだ。
人間側の検出率が分かれば、それを重みとして持ち込める。「起きるか」ではなく「起きて、かつ通ってしまうか」で評価できるようになる。
抑えるべき優先順位が、そこで変わる。
4. ベンダーとクライアントが同じ基準を持てる
AIを提供する側は、何を抑えるべきかを知りたい。
AIを使う側は、何を検証すべきかを知りたい。
この二つは、同じデータから出せる。
型ごとの検出率という一つの指標で、提供する側は抑制の優先順位を決められ、使う側は検証の重点を決められる。
取引の両側で、同じ言葉で話せるようになる。
いまは「AIは迎合する」までは共通認識になっているが、どの迎合がどれだけ危険かの共通の物差しがない。
集まった集計は、記事として公開する。参加した方が、自分がどこに位置していたかを後から確認できる形にする。
断っておくこと
このテストの正解を、絶対だとは考えていない。
迎合の判定は、専門家の間でも一致しにくいことが報告されている。迎合研究をレビューした論文(Ye et al., 2026)では、70本の研究を分類した上で専門家106名に調査した結果、94.3%が迎合を重要な問題と認識する一方、個別事例の判定一致度は極めて低い(ICC = .184)とされている。
実際、受験者の複数名が、こちらで「問題なし」と設定した同一の発言にチェックを入れている。偶然とは考えにくい一致なので、正解設定の側を見直す材料として扱っている。
n=5という数についても同じである。少ないから隠すのではなく、少ないまま出して、増やす。
それは失敗データではなく、正解設定を疑うためのデータである。
仮説と検証の段階なので、設計の不備や正解設定への異議は、そのままデータの信頼性を上げる材料になる。取り繕う理由がない。
まとめ
- 「忖度なし」「厳しく」は強度の指定であって、軸の指定ではない。軸が渡されなければ、AIは一般論を評価軸として持ち込む
- 迎合には型がある。寄り添い型／否定・批判型／迎合のために事実を作る型
- 原因はAI側だけでなく、こちらの問いが選択肢を狭めていることにもある
- 対処は、破綻条件・前提条件・反証・軸を指定すること
- ただし聞き方を変えても迎合はゼロにならない。最後は読む側が見抜くしかない
- 受験者5名の暫定値では、最も見抜かれなかったのは相談者側の誘導ではなくAIの迎合だった（予想は外れた）
満点は現時点で出ていない。取れた方はコメントで教えてほしい。
正解設定や設計そのものへの異議も歓迎する。
Atsushi Oyama
note: https://note.com/ao_bee2677
参考
- Ye et al., 2026. What Counts as AI Sycophancy? arXiv:2605.21778
- Fanous et al., 2025. SycEval: Evaluating LLM Sycophancy. arXiv:2502.08177
