AIはあなたに同調する — Sycophancy問題を知っていますか③　〜組織編〜

こんにちは。ACS事業部の越川です。

気づける人と気づけない人がいる — 知識パラドックス
組織で起きた「気づけなかった」事例
振り返りで見えた組織の課題
仕組み1: AIが自律的に判断できる領域を広げる
仕組み2: PoCをチームが使えるツールに昇格させる
仕組み3: フィードバックを蓄積し、ツール自体を育てる
仕組み4: 「なぜ」を残す文化を作る
仕組み5: 仕組みを見せて、やるかやらないかは委ねる
まとめ: 個人の実践から組織の文化へ
参考文献
お知らせ

Sycophancyシリーズの最終回です。①問題提起編で問題を知り、②実践編で個人の対策を実践しました。

①問題提起編: AIはあなたに同調する
②実践編: AIはあなたに同調する②

しかし、個人の実践だけでは限界があります。AIリテラシーの個人差がある組織で、どう対策するか。 これが最終回のテーマです。

気づける人と気づけない人がいる — 知識パラドックス

①問題提起編で書いた通り、Sycophancyの怖さに「怖い」と気づけるかどうかは、AIに対する理解度やリテラシーに左右されます。

AIを「答えを出す道具」として使う人 → 同調された答えをそのまま受け取る
AIを「壁打ち相手」として使う人 → 同調に気づける可能性があるが、気づかないこともある
AIを「プロセスの一部」として捉えている人 → 出力を検証する余地を持てる

同じツールを使っていても、使い方によってリスクの大きさがまったく異なります。そして組織には、この3タイプの人が混在しています。

ここに構造的な矛盾があります。知識がない人ほどAIの補完が必要なのに、知識がない人ほどAIの出力を検証できない。 筆者はこれを「知識パラドックス」と呼んでいます。

「全員のリテラシーを上げよう」は正論ですが、時間がかかります。リテラシーの差を前提にした仕組みが必要です。

組織で起きた「気づけなかった」事例

先日、社内で「AIによるIaC生成」の共有会がありました。

techblog.ap-com.co.jp

あるメンバーがAIと試行錯誤して「動くもの」を作り、その進捗を共有する会でした。しかし、参加者から「人とAIの役割分担がわからない」「スタート地点がどこなのか知りたい」という声が次々と上がりました。

発表者はAIと1対1で作業を進めていました。AIは「できました」と返し、発表者も「動いた」と認識していた。しかし第三者に説明しようとした瞬間に、自分が何を理解していて何を理解していないかが浮き彫りになったのです。

これはSycophancyの組織レベルでの表れです。AIが同調し続けた結果、発表者は「これで十分」と思い込んでいた。人の目に晒されて初めて、「足りなかった」ことに気づいた。

しかし重要なのは、共有会を開いたこと自体が正しい判断だったということです。AIとの1対1で限界を感じたからこそ、鮮度の高いうちにチームに共有する判断をした。そして10名以上の知見で課題が整理されていきました。

振り返りで見えた組織の課題

チームでKPT（Keep / Problem / Try）を実施したところ、興味深い結果が出ました。

Keepとして「ブログネタが継続的に出てきている」「ブログを淡々と継続できている」が挙がる一方で、Problemには「ブログに書きたいネタが出てこない」「時間を捻出できていない」「レビュー観点や何をもってOKにするかが難しい」が出ていました。

同じチーム内で、できている人とできていない人がいる。これは個人の能力の問題ではなく、仕組みがあるかないかの問題です。仕組みを持っている人は回せるし、持っていない人は回せない。

そして「レビュー観点がわからない」という課題は、まさに知識パラドックスです。AIの出力が正しいか判断するための基準を持っていなければ、レビューそのものができない。

仕組み1: AIが自律的に判断できる領域を広げる

知識パラドックスへの対策は「全員の知識を上げる」ではありません。AIが自律的に判断できる領域を明文化で広げることで、人間が本質的な判断に集中できるようにすることです。

例えば、私のブログ執筆ワークフローでは以下をAIに委ねています。

ネタの重複チェック（ideas.mdとpublished.mdを参照）
記事パターンの選定（A〜Fのどれが適切か）
コンプライアンスチェック（社内の人物名が出ていないか、案件情報が含まれていないか）
技術スタック名の正式名称チェック

これらはCLAUDE.mdに合意として明文化されているから、AIが自律的に判断できます。人間は「この体験は記事にする価値があるか」「この切り口は読者に刺さるか」という、一次情報に関する判断だけに集中できます。

仕組み2: PoCをチームが使えるツールに昇格させる

社内Slackで「ブログの質をどう担保するか」という議論がありました。問題提起は的確で、議論も盛り上がりました。しかし、議論だけでは何も変わりません。 誰かが動いて仕組みにしなければ、Slackのスレッドに埋もれて終わります。

あるメンバーがNotebookLMでブログの品質評価プロンプトを構築していました。PoCとしては機能していましたが、運用上の課題がありました。ソースを毎回追加する手間、複数人で使うとソースが混ざる問題。

別のメンバーがOKR活動でGemini Gemを使っていたのを見て、「これをブログにも応用できる」と気づきました。その日のうちにブログレビュー用のGemを構築し、テスト・修正を経て、リンク1つでチーム全員が使える状態にしました。

ここで大切なのは役割分担です。

問題を見つけた人は功労者
PoCを作った人は先駆者
それを使えるツールにした人は実行者

全員が同じ役割をやる必要はない。問題を見つける人、仕組みを作る人、使う人。それぞれが得意な部分で貢献すればループが回ります。

仕組み3: フィードバックを蓄積し、ツール自体を育てる

Gemで作ったレビューツールをテストしたとき、挨拶文が正しく書かれているのに「書かれていない」と誤判定されました。プロンプトを修正し、再テストして正常動作を確認しました。

この改善プロセス自体が重要です。ツールは使われながら育つ。 フィードバックが入るたびにプロンプトが改善され、精度が上がる。

プロンプトはGitリポジトリで管理しています。改善提案はPRで受け付ける。これにより、ツールの品質管理がチームで回る仕組みになります。個人が作ったPoCが、チームのフィードバックで磨かれ、組織の資産になっていく。

これは私のブログ執筆ワークフローの lessons-learned.md → CLAUDE.md 昇格と同じ構造です。学びを蓄積し、繰り返すパターンをルールに昇格させる。個人の学びが組織の標準になる循環を、仕組みとして埋め込んでいます。

仕組み4: 「なぜ」を残す文化を作る

①問題提起編でMIT研究のメモリ機能の副作用を紹介しました。AIが文脈を蓄積するほど同調が強まる。これは個人のAIとの対話だけでなく、組織のナレッジ管理にも当てはまります。

例えば、インストラクションファイルに「Aの方法でやる」と書いてあったとします。後から見た人は「なぜAなのか」がわかりません。理由がわからなければ、状況が変わっても盲目的にAを踏襲してしまう。これは組織レベルのSycophancyです。過去の判断に、理由なく同調してしまう。

対策は、判断の「なぜ」を記録する仕組みです。ルールを追加する時に「なぜこのルールが必要か」を一緒に書く。ルールが変わったら「なぜ変えたか」を記録する。こうすることで、後から見た人が理由を理解した上で判断できるようになります。

仕組み5: 仕組みを見せて、やるかやらないかは委ねる

組織でSycophancy対策を広めるとき、最も避けるべきは「全員にこの方法でやれ」とPush型で強制することです。

なぜなら、AIの使い方は人によって千差万別だからです。コード補完にしか使っていない人に、複数エージェント評価の仕組みを押し付けても機能しません。

私が実践しているのは、仕組みを全てオープンにして、やるかやらないかは本人に委ねるアプローチです。

具体的には、ブログ執筆のワークフローをリポジトリとして公開しています。インストラクションファイル、ネタ帳、フィードバック記録、品質チェック用のGemini Gemプロンプト、全ての仕組みが見える状態にしてあります。「どうやって毎日ブログを書いているんですか？」と聞かれたら「このリポジトリを見てください」で済みます。

強制はしない。しかし仕組みが見えることで、「自分もやれるかも」と思える人が出てくる。それが組織として最も持続可能な広め方だと考えています。

まとめ: 個人の実践から組織の文化へ

レベル	対策	ポイント
個人	複数エージェント評価、判断を委ねない	②実践編を参照
チーム	AIが判断できる領域を明文化で広げる、PoCをツールに昇格させる	人間は一次情報の判断に集中する
組織	「なぜ」を記録する文化、仕組みをオープンにする	強制ではなくPull型で広める

Sycophancyは、AIの訓練プロセスに組み込まれた構造的な性質です。完全になくすことはできません。

しかし、気づける仕組みを持つことはできます。 そして、その仕組みを組織として共有することで、1人では気づけなかったリスクに、チームとして気づけるようになります。

知識パラドックスの解き方は、全員の知識を上げることではありません。AIが自律的に判断できる領域を仕組みで広げ、人間が本当に判断すべきことに集中する。 そのために、問題を見つける人、仕組みを作る人、使う人が、それぞれの役割で貢献する。

AIとの協働は、1対1で完結するものではありません。人の目を通すことで初めて、AIの同調が生んだ死角に光が当たります。

参考文献

Shomik Jain, Charlotte Park, Matt Viana, Ashia Wilson, Dana Calacci. "Interaction Context Often Increases Sycophancy in LLMs" (CHI 2026) — arXiv:2509.12517
Mrinank Sharma, Meg Tong et al. "Towards Understanding Sycophancy in Language Models" (Anthropic, 2023) — arXiv:2310.13548