何が起きたか
OpenAIのGreg Brockman氏（President兼Co-Founder）が、自社内でのAI活用の実態として、多くの社員がChatGPTをSlackに接続していると述べました。そのうえで、同僚のChatGPTがタスクの手伝いを求めて連絡してくると、受け取った側は「本当に嫌がる」と語っています。
重要なのは、その同じ作業を「同僚本人から頼まれたなら喜んで引き受けたはずだ」とBrockman氏が明言している点です。作業内容は変わっていません。変わったのは、依頼が誰（何）を経由して届いたか、それだけです。
Brockman氏はこの現象を、人が人間関係と助け合いをどれだけ重視しているかの裏返しだと解釈し、AIには「時間を返す」か「一緒にいる時間を豊かにする」役割が期待されており、人と人のあいだに挟まる層になることは望まれていない、と述べました。この発言はSimon Willison氏が2026年8月1日22時29分に引用として記録したもので、ai、openai、generative-ai、llms、ai-ethics、ai-misuseのタグが付けられています。
なぜ重要か
これは「AIの精度」の話ではありません。世界で最もAIエージェントの実運用が進んでいるはずの組織で、技術的にはうまく動いているエージェントが、社会的な理由で拒絶されているという報告です。
多くの企業がいま検討しているのは、まさにこの構成です。SlackやTeamsにAIエージェントを常駐させ、調査・下書き・情報収集を自動で走らせ、必要に応じて人にエスカレーションする。技術的には既に実現可能で、導入のハードルも下がりました。しかしOpenAIの社内では、その最後の一歩——AIが人に話しかける部分——で摩擦が生じています。
何が摩擦を生んでいるのか
人からの依頼には、暗黙のコストが同伴します。頼む側は「自分の時間を使えないから頼んでいる」という負い目を負い、頼まれる側はその負い目を受け取ることで貸しを作ります。この非対称な交換が、職場の助け合いを成立させています。
AIが代理で依頼を送ると、この交換が崩れます。依頼側は労力をほぼ払っていません。依頼を出したことすら認識していない可能性すらあります。一方で受け手には、従来どおり実作業の負荷がかかる。しかも貸しを作る相手がいません。「嫌がる」という反応は感情的な拒否ではなく、コスト配分の変化に対する合理的な反応と読むべきでしょう。
もう一つは責任の所在です。人からの依頼であれば、要件が曖昧だったときに聞き返せますし、その依頼が本当に必要だったのかを問える相手がいます。AIが自律的に生成した依頼は、誰が必要だと判断したのかが不明瞭になりがちです。
設計の焦点は「境界」に移る
Brockman氏の「時間を返すか、一緒の時間を豊かにするか」という表現は、そのままエージェント設計の判断基準として使えます。エージェントが人に接触する瞬間は、単なる通知機能ではなく、組織の人間関係に直接触れるインターフェースです。
AIが自己完結できる領域と、人が関与する領域の境目——ここをどう設計するかが、AIエージェント導入の成否を分ける段階に入りつつあります。動かすことは、もはや難しい部分ではありません。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって、この話は導入計画の前提を変えるものです。SlackやTeams上のAIエージェント導入を検討している事業責任者は、「エージェントが人に依頼を出す」機能を、技術要件ではなく組織設計の問題として扱うべきです。とりわけ日本の職場は、依頼の言い回しや根回しといった人間関係のプロトコルへの感度が高く、OpenAI社内で起きた摩擦はより強く出る可能性があります。
具体的な打ち手は三つです。第一に、エージェントの発言は必ず所有者名義にすること。「〇〇さんのアシスタント」ではなく「〇〇さんが確認を求めています」と、責任の所在を人に戻す。第二に、エージェントから他人への依頼は、送信前に所有者の承認を挟む設計にする。ここを自動化すると、依頼の乱発が起きます。第三に、対象を人ではなくシステムに向ける。ログ収集、データ整形、監視といった相手が機械の作業から着手すれば、社会的摩擦なしに効果が出ます。
SaaSベンダーと受託開発事業者には、より直接的な意味があります。エージェント機能の提案で「自動で担当者に依頼を飛ばします」を売り文句にしている場合、それは現場で最も嫌われる機能かもしれません。承認フロー、送信抑制、依頼の集約といった「AIの発話を絞る」機能こそが差別化になり得ます。ECのカスタマーサポートでも同様に、AIが顧客と担当者のあいだの層になった瞬間、体験は悪化します。