"AI出力をそのまま共有する「ワークスロップ」の実例と3つの教訓"

AIの出力をSlackに張り付けて送った瞬間、職場の信頼が壊れはじめます。

ある日、クライアント企業のSlackにこの一文が投稿されました。

投稿したのは、社内の運用設計を担当していたB氏。自分はAIコンサルタントとして、Google Geminiの「Gem」（カスタムAIアシスタント）を組織的に引き継ぐ方法を提案していた最中でした。

投稿したのは、AI活用の運用設計を担当していたB氏。

自分はAIコンサルタントとして、Google Geminiの「Gem」（カスタムAIアシスタント）を組織的に引き継ぐ方法を提案していた最中でした。

事前に実機で検証し、公式ドキュメントにも「NG」の記載がないことを確認した上での提案です。

しかし、B氏がGeminiに「裏取り」をしようとしたところ、AIは「共有ドライブへの移動はシステム上の不具合の元になる」と回答。
B氏はその出力をそのままSlackに貼り付けました。

検証済みの提案が、根拠のないAI出力に覆されかけた瞬間です。

これは「ワークスロップ」と呼ばれる問題の、典型的なパターンでした。

2人に1人がAIの"残飯"を職場に持ち込んでいる

「ワークスロップ（Work Slop）」

聞き慣れない言葉かもしれません。

Stanford大学とBetterUp Labsの研究チームが2025年秋に提唱した造語で、「体裁は整っているが、実質的な価値が乏しいAI生成の成果物」を指します。SNS上に溢れる低品質なAI生成コンテンツ「AIスロップ」の、職場版です。

ちなみにこの「slop」という言葉、2025年のメリアム・ウェブスター年間ワード・オブ・ザ・イヤーに選ばれています。
辞書に刻まれるほど、AI時代を象徴する概念になりました。

では、職場ではどれくらい広がっているのか。

同チームが米国のデスクワーカー1,150人を対象に行った調査の結果は、衝撃的です。

• 41%が過去1ヶ月にワークスロップを受け取った

• 50%以上がワークスロップを同僚に送ったことがある

• 受け取った人の53%が不満、42%が作成者への信頼低下を報告

• 経済損失は1人あたり約186ドル（約2.8万円）/月

「2人に1人が送っている」という数字は、もはや一部の人の問題ではありません。そして注目すべきは、42%が信頼低下を報告しているという点です。

ワークスロップは生産性の問題ではなく、信頼の問題なのです。

体裁が整っているほど、危険。その理由は、意外なところにあります。
見出しや太字で構造化され、手順番号まで振られた「もっともらしい」AI出力は、公式ドキュメントと見分けがつきません。

ここまでの内容で、ワークスロップの全体像はお伝えしました。

ここからが本題です。

実最も厄介なワークスロップは"6割正しい"ものです。

冒頭で紹介したケースがまさにそうでした。
「6割正しい嘘」がなぜ全部嘘より厄介なのか。
検証済みの専門家の提案が、なぜAIの長文に覆されかけるのか。
そして、AIが「謝った後」にも続くハルシネーションの罠とは何か。

知らないままでいると、根拠のないAI出力が社内の運用ルールとして定着し、現場で手を動かした人間の報告が「AIがそう言っていたから」の一言に負け続けます。

その損失は、生産性ではなく信頼です。

ここから先では、実際に現場で起きた事例の詳細と、そこから導き出した3つの教訓をお伝えします。

この記事が向いている方:

• 部下やチームメンバーがAI出力をそのまま共有していないか気になっている方

• 自分自身のAI出力の扱い方を見直したい方

• AIと専門家の意見が食い違ったとき、どう判断すべきか知りたい方

向いていない方:

• AIを業務で使う予定がない方（今はまだ必要ないかもしれません）

間違ったAI出力が、検証済みの提案を覆す

改めて、何が起きたかを整理します。

Google Geminiの「Gem」を組織で活用しているクライアント企業で、退職・異動時のGem引き継ぎが課題になりました。

私はコンサルタントの立場から、Gemファイルをマイドライブから共有ドライブに移動して管理する方法を提案しました。

• ドライブで管理している＝組織資産⇒誰かがオーナーシップを持っている

• ドライブで管理していない＝個人の作業効率化⇒まだ自分だけのもの

手順ではなく仕組みで、管理状態を判断できるようにしたかったのです。

もちろん、事前に実機で検証済み。共有ドライブへの移動を「NG」とする公式ドキュメントも存在しないことを確認しています。

ところが、B氏がGeminiに確認したところ——AIはこう回答しました。

見出し、太字、手順番号まで整った「もっともらしい」長文です。
そしてその内容は、以下のように正確な部分と嘘が混在していました。

正確だった部分:

• Gemがマイドライブの「Gemini Gems」フォルダに保存されるという説明

• オーナー権限の譲渡手順とその具体的な操作方法

• 「コピーを作成」による自衛策の提案

ハルシネーションだった部分:

• 「システム上マイドライブをベースに機能する仕様」という主張

• 「共有ドライブへの移動は不具合の元になる」という警告

• 「共有ドライブを使ったファイル管理は適していない」という結論

全体の6割は正確な情報。見出しと構造も整っている。
公式ドキュメントに近い信頼感を持つ文書に仕上がっていました。
しかし、根幹の主張——「共有ドライブはNG」——に根拠がありません。
つまり、Geminiの回答の結論の骨子である核心部分は「ハルシネーション」根拠のない作り話だったのです。

私は専門家なので、すぐにハルシネーションだと判断できました。

事前に調査・検証を済ませていたからです。

しかし問題は、見抜けるかどうかではありません。

見抜いた上で、それが間違いであることを相手に説明し、納得してもらうコストを負わされたということです。

B氏はAIの出力をそのまま自分に投げてきました。

悪意はないにせよ、結果として未検証の情報の検証作業を相手に押し付ける形になってしまいます。

「全部間違い」なら誰でも気づけます。
しかし「6割合っている」ものは、まず正確な部分と嘘の部分を切り分ける作業が必要になる。
その上で、嘘の部分が嘘であることを根拠とともに説明しなければならない。

検証と反論のコストが、桁違いに高くなるのです。

専門家の一次情報より、AIの長文が優先される危うさ

少し立場の話をさせてください。

私はこの件について、実機で検証を行い、実際に社内運用の実績も確認した上で提案しています。

にもかかわらず、B氏がGeminiの出力をSlackに貼った瞬間、議論の流れが変わりかけました。

B氏に悪意はありません。
むしろ慎重に裏を取ろうとした結果です。
「迷っています」という言葉が示すように、B氏自身も判断がつかなかった。

しかし構造的に見ると、外部の専門家が検証済みの根拠をもって行った提案が、AIの根拠なき出力によって保留にされたということになります。

これはコンサルタントの立場に限った話ではありません。
弁護士、税理士、社労士
専門知識と実務経験に基づいて助言を行うすべての人に起こり得ます。

クライアントが「AIに聞いたらこう言ってましたけど…」と根拠のないAI出力を持ち出してくる。
専門家が時間をかけて調査・検証した見解と、AIが数秒で生成した「もっともらしい長文」が同じ土俵に並べられてしまう。
そして専門家側が、その誤りを丁寧に説明するコストまで負わされる。

意外なことに、AIの出力は長文で構造的であるほど権威があるように見えるという認知バイアスが働きます。
短い経験談よりも、見出し付きの長文の方が「根拠がありそう」に感じてしまう。

社内でも同じです。現場で手を動かして検証したメンバーの報告が、別の誰かが持ち込んだAIの長文出力によって覆されかける。

Stack Overflowの2025年開発者調査によれば、開発者の84%がAIを使用している一方で、その出力を信頼していると答えたのはわずか29%。
使用率と信頼度のギャップは拡大し続けています。
使っているけれど信じてはいない
にもかかわらず、他人がAI出力を持ち込むと「もっともらしく」見えてしまう。
この矛盾は、どの組織でも、どの専門領域でも起こり得るのです。

AIが「謝罪」した後も警戒すべき理由

興味深いことに、このケースにはもう一つ、見逃せないポイントがあります。

私がB氏に「根拠となるURLを提示してもらってください」と促したところ、B氏がGeminiに問い直しました。

するとGeminiはこう回答しました。

「公式ソースはありません」と認めた直後に、「予期せぬ同期エラーやリンク切れを招くリスクが高いため、実運用上おすすめできない」と、根拠のない警告を繰り返したのです。

さらには「私の推測（システム上のリスク）を含んだ見解を、絶対のルールであるかのように断言してしまい申し訳ありませんでした」と丁寧に謝罪までしている。

断言は撤回しつつ、結論は変えない。

謝罪はするが、主張は引っ込めない。

いわば「謝罪風ハルシネーション」です。

人間の対話であれば論点ずらしと認識される手法ですが、AIの丁寧な文体で出力されると「慎重で誠実な見解」に見えてしまいます。

興味深いのは、B氏自身も「フラットにGeminiに聞いてみても、非推奨と回答が返ってくるのが少し気持ち悪い」と感じていたことです。

違和感を覚えていた。しかしそれでも、この謝罪風ハルシネーションに影響されていました。

B氏の反応は「過去に共有ドライブに移動することでエラー報告があがっているソースはあるようで歯切れが悪いですが」というもの。

『あるようです』——『ありました』ではない、つまり、そのソースが本当に存在するかどうかを自分では確認していない。

Geminiが「公式ソースはない」と認めた同じ回答の中で匂わせた「エラー報告」を、また検証せずにそのまま受け入れてしまっている。

一度の問い直しでは不十分であること。

そしてハルシネーションを指摘された後でも、同じパターンに陥り得ること。

このケースが如実に示しています。

AIの出力を"自分の言葉"に変換できる人が、信頼される

この事例から得られた教訓は、3つあります。