Back to Insights企業文化と運営

AIの怠慢問題:なぜあなたのチームは速いのに、あなたの会社はそうではないのか

By James Huang2026年6月8日·Updated 2026年6月1日9 min read
AI Generated Cover for: The AI Slacking Problem: Why Your Team Is Faster and Your Company Isn't

私がこの言葉を初めて聞いた時のことを覚えています「AIモウユウ学」—AI怠慢理論です。2023年頃、中国のテック界で広まっていて、同時に面白くもあり、非常に落胆させる現象を説明していました。

それはこういう仕組みです:工場の従業員がAIツールにアクセスします。以前は8時間かかっていた報告書が、今では20分で終わります。では、残りの7時間40分で彼は何をするのでしょうか?彼はタイピングしているふりをします。彼は画面をじっと見つめます。長いトイレ休憩を取ります。そして午後5時59分に、完璧な報告書を提出して帰宅します。

従業員は大喜びです—何もしなくても給料がもらえるのです。上司は困惑しています—みんながより生産的に見えるのに、四半期の数字は昨年とまったく同じです。

私はこれを初めて聞いたとき、笑いました。しかし、笑うのをやめたのは、次のことに気づいたからです:これは怠け者の従業員の話ではありません。これは愚かな組織の話です。

先週、私はこれらすべてを思い出しました。 2026年中国オープンクローエコシステムレポート —これは、Growth BlackboxとNetEase Intelligence Enterpriseによる共同研究です。彼らは2,000人の個人ユーザーと100人の企業マネージャーを調査しました。そして、そのデータは私が何年も感じていたことを確認しました: AI時代の本当のマネジメントの盲点はツールではありません。それはスピードの差です。 個人がどれだけ早く動けるかと、組織がどれだけ遅く変わるかのギャップです。

ここに私の心に残った三つのことがあります—そしてマーキュリーがそれに対して実際に何をしているかです。

1. 痛みのポイントがなければ、採用はない

ほとんどの上司はこう考えています:「皆のためにAIツールを購入します。彼らにとっては無料で、手間を省き、きっと気に入るでしょう。生産性は急上昇します。」

レポートは2,000人のユーザーを五つのカテゴリーに分けました:

  • シュリンプ初心者(21.7%):インストールしたが、ほとんど使っていない。月に一度、偶然に開く。
  • シュリンプワーカー(25.7%):仕事が必要な時に使う。それ以外は閉じている。週に三回から五回。
  • シュリンプメンター(22.9%):使用し、同僚の設定を手伝う。
  • エビエリート (21.2%):ワークフローに深く組み込まれています。毎日使用されています。
  • エビゴッドファーザー (8.6%):毎日複数回のセッションがあります。3人以上の同僚のために設定されています。

見覚えがありますか? これがあなたのオフィスです。

重要な詳細はこちらです:エビニュービーの中で、インストールしたものの再度触れなかった人々の中で、最も高い割合は経営陣と創業者でした。なぜでしょうか? 彼らは解決を待っている特定の仕事上の痛みを抱えていなかったからです。誰かが彼らのためにインストールしました。彼らにはかゆみを感じることがありませんでした。

Conversely, the people who actually used the tool were overwhelmingly driven by specific work needs. The report broke down adoption triggers: 36.5% were driven by work requirements. 30.7% by seeing someone else's use case. Combined, that's 67.2%—two-thirds of users arrived with a problem in hand.

The people who adopted because "a colleague installed it for me"? Across every use case—document organization, scheduling, data analysis, coding—they showed ネガティブな好み。彼らは道具を持っていたが、どこにも合わなかった。まるで、頼んでもいない贈り物のキッチン家電が引き出しに入っているようなものだ。

マーキュリーの見解:好奇心を強制することはできない。痛みをさらけ出すことしかできない。

マーキュリーでは、クライアントのためにエージェントシステムを展開する際、決して道具から始めない。ボトルネックから始める。ボトルネック。私たちはチームを3日間影で観察し、彼らが辞めたくなる特定のタスクを見つける。通常、それは「週次競合情報レポートの作成」や「クライアント提案書の15回目のフォーマット変更」のようなものだ。そして、その特定のタスクを処理するエージェントを構築する。

反応は決して「お、素晴らしい技術だ。」ではない。それは「これまでのキャリアの中で、どこにあったのだろうか?」

従業員にAIが彼らを30%効率的にするとは言えません。彼らは気にしません。しかし、毎週火曜日に嫌な三時間の作業が今では十五秒で終わると言えば、彼らの目が変わります。人間は合理的な意思決定者ではありません。私たちは痛みを避ける機械です。リーダーとしてのあなたの仕事は道具を買うことではありません。痛みが見える、否定できない、そして人々が自ら救済を求めるほど緊急性を持つ環境を作ることです。

2. 個人のスピード ≠ 会社のスピード

例えば、100人の伐採者を抱える伐採会社を運営しているとしましょう。全員に高性能のチェーンソーを与えます。会社はすぐにもっとお金を稼げるようになりますか?

いいえ。木を切るのは早くなったが、運搬、検査、会計は変わっていません。切ることで節約した時間は、他のプロセスによって消費されてしまいます。

報告書はまさにこのパターンを見つけました。最前線の従業員は圧倒的に「軽く」そして「速く」感じていると報告しました。しかし、会社全体では?コストと収益は大きく変わりませんでした。

効率はどこに行ったのでしょうか?それは新たな摩擦に消費されました。追加の修正。追加の承認。追加の検証サイクル。

想像してみてください:ある従業員は、ソーシャルメディアの投稿を書くのに丸一日かかっていました。しかし今、彼女はAIを使って5分でそれを生成します。彼女はまるで背中にロケットを取り付けたように感じています。しかし、その後マネージャーがそれを読んで思います:「これはAIのように感じる。手作りの質感が欠けている。」そこで彼は、3つのバージョンを混ぜ合わせるように頼みます。そして、誰もがAIの幻覚を恐れているため、彼女はデータを手動で確認するのに半日を費やします。その後、コンプライアンスリスクプロファイルが変わったため、法務部門がレビューする必要があります。さらに、IT部門はどのモデルがそれを生成したかを記録したいと言います。

彼女はAIを5分間使いました。しかし、組織はその5分間を処理するのに追加で1日を費やしました。投稿はそれでも24時間後に公開されます。

水星の視点:AI時代の効率性は、全員を速くすることではありません。それは役割の圧縮に関するものです。

この報告書は、NetEaseの自社チームの事例を強調しました。彼らの古い製品開発フローは次の通りです:プロダクトマネージャーが要件を書く → インタラクションデザイナーがワイヤーフレームを描く → ビジュアルデザイナーがモックアップを作成する → フロントエンド開発者が実装する。4人が関与し、連続的な引き渡しが行われていました。

彼らはそれを再構築しました:プロダクトマネージャーが要件を直接説明し、AIがインタラクティブなプロトタイプを生成し、デザイナーが判断して微調整を行います。4つのノードが2つになりました。

これが私たちが呼ぶものですプロセスの崩壊メルクリウスにおいて。問題は「各人を30%速くするにはどうすればよいか?」ではありません。問題は:「どの引き渡しを完全に排除できるか?」です。

クライアントのためにエージェンティックなワークフローを設計する際、私たちは既存のプロセスをマッピングしてからAIを追加するのではありません。私たちは既存のプロセスをマッピングしてからノードを削除します。AIエージェントが提案書の初稿を生成できるなら、なぜそのチェーンにジュニアコピーライターがまだ存在するのでしょうか?エージェントがリアルタイムで50の情報源から競争情報をまとめられるなら、なぜアナリストは月曜日の朝にそれを手作業で行うのでしょうか?

不快な真実:AIのROIを従業員がAIを使って作成したプレゼンテーションの数で測っているなら、それは間違ったことを測っています。本当の質問はもっと厳しいものです:

  • どのプロセスを完全に削除できますか?
  • どの役割を再スキルではなく再設計する必要がありますか?
  • 現在、コミュニケーションのオーバーヘッドが効率の向上よりも大きくなっているのはどこですか?

それに答えられないなら、あなたはAIを購入していません。高価なチェーンソーを100台買って、同じ伐採作業を続けているだけです。

3. ガバナンスのギャップ:従業員はすでに去っています

これがすべてのCTOを夜も眠れなくさせるべき問題です。

レポートによると、従業員が自分でAIツールを使用し始めると、 2週間から4週間 IT部門やコンプライアンス部門がそれに気づくまでかかるそうです。それを考えてみてください。半月の間、従業員は会社の機械でAIツールを使用し、会社のデータを処理し、外部APIに接続しているのに、ガバナンス機能はただ「人々がこのようなものを使っている」と気づくのです。 「ああ、人々がこのようなものを使っているんだ。」

「AIを導入した」88の企業の中で、 21.6% が完全なガバナンスフレームワークを持っていました。5社中4社は無防備で運営されていました。

業界の反応は予測通りでした:より厳しい禁止措置。ブラックリスト。データ漏洩防止。必須の承認ワークフロー。

それが機能しない理由は、報告書によれば次の通りです:より厳しいガバナンスは、利用をグレーゾーンの奥深くに押し込むだけです。従業員は個人の電話に切り替えます。カフェのWiFiを利用します。個人アカウントを登録します。あなたは管理を強化したと思っていますが、実際には見えない場所に活動を移しただけです。

マーキュリービュー:AI時代において、ガバナンスは厳格であることではありません。それは追いつくために十分に速くあることです。

報告書は逆説的な道を提案しました:本社がツールを選び、全員を訓練し、使用を義務付けるのではなく—その逆を行ってください。従業員に先に進ませましょう。彼らに実験させてください。そして、組織が彼らがすでに使用しているものを特定し、カタログ化し、取り入れるようにします。マネージャーの役割は「調達担当者」から「キャッチアップ担当者」にシフトします。

これは、私たちがずっと主張してきたことと完全に一致します。従来のITガバナンスモデルは、組織が買い手であり、従業員がユーザーであると仮定しています。AI時代では、従業員が買い手であり、組織が 遅れた採用者です。あなたの仕事はもはやツールを選ぶことではありません。あなたのチームがすでに選んだものを発見し、それにガバナンスを組み込むことです。専有データが漏れ始める前に。

私はこれを 高速鉄道モデルと呼んでいます。従来の組織では、機関車が車両を引っ張ります。AIネイティブな組織では、各車両が独自のエンジンを持っています。しかし、重要なアップグレードはこれです: 機関車は、各車両がすでにどこに行ったかを知っている必要があります。見えないものを支配することはできません。可視性は制御に先立ちます。

より深刻な問題:労働の分業の死?

この報告書を読みながら、私を不安にさせる何かに繰り返し戻ってきました。

現代経済学は、基盤となる石の上に築かれています:労働の分業は効率を生み出します。アダム・スミスのピン工場。専門化。各人が一つのことを上手に行い、総生産量が増加します。

しかし、私はますます逆の動態を見ています。アイデアがあり、それを他の人に伝え、実行させ、レビューし、修正する必要がある場合、コミュニケーションと調整のコストは、分業自体の効率向上をしばしば上回ります。

最近オンラインで見た一文が私に強く響きました:「この時代において、労働分業のコミュニケーションオーバーヘッドは、労働分業の効率向上をしばしば上回ります。」

メルクリウスでは、私たちはこれを直接体験しました。クライアントのGEOアーキテクチャについて戦略的な洞察を持ったとき、従来の流れはこうです:私がそれを戦略家に説明し、戦略家がライターにブリーフし、ライターが草案を作成し、それを私がレビューし、再修正のために戻します。このループには数日かかります。整合性のずれは常に存在します。

新しい流れは?私はエージェントにそれを話します。エージェントは私の声で、私の構造的枠組みの中で、リアルタイムで草案を作成します。私は編集し、エージェントは修正します。私たちは1時間で出荷します。アイデア出しと実行の「分業」は一つのループに統合されました。

これが千人規模の組織でどのようにスケールするかについて、明確な答えはありません。しかし、私はこれを知っています:組織の効率に関する古典的理論がリアルタイムでストレステストされています。そして、既存の労働分業のアーキテクチャにAIを追加し続ける企業は、単に遅い機械を速く動かすだけで、速い機械を構築しているわけではないことに気づくでしょう。

勝つのは、次のように勇気を持って問いかける企業です:どの部門がもはや存在する必要がないのか?

— ジェームズ、CEO、マーキュリーテクノロジーソリューションズ 詳しくはご覧ください www.mtsoln.com 香港、2026年5月

Originally published on MTS Blog & Research