ツールは配備した。なのにチームの速さは変わらない

この溝を実際の会社に当てはめると、こんな光景になる。

非IT企業のオペレーション責任者の話です。部下は数千人。AIがなかった頃、チームの速さには大きな問題がありませんでした。そこへClaude Coworkを導入しました。

結果、チームの速さは以前と変わらなかった。責任者の疑問はひとつ。なぜ？

組織内の使い方が分裂しているからです。50 人のチームでも 5000 人のチームでも同じで、いつもバーベル型になる：

その5〜10%のヘビーユーザーは、そもそもCoworkの導入を会社に推した人たちです。彼らは仕事終わりにもAIをいじり、何ができるかを身をもって知っています。

この分布を帳簿に載せると、こういう一文になる：何も速くならなかったが、数百万ドルは確かに燃えた。

あるオペレーション組織の分布。右下の行には「Observed speedup: none」、観測された高速化：なし。出典：Vasuman / Varick Agents

「使える」と「使いこなせる」は別のスキル

だが、なぜこうなるのか？実際に AI を使っている人たちの中でも、スキル差は歴然としている：

自分が何をしているのか分かっていないAIユーザーは、AIを使う前よりも悪い結果になります。 Vasuman

Claudeをインストールして、コードリポジトリを指定して、4語のプロンプトを送って、動くのを見ます。これは簡単です。結果は正しいかもしれませんし、間違っているかもしれません。使いこなすのは別の話で、全部で4つのことが必要です。

1. いつコンテキストをクリアすべきか知っている
2. 2 回やった作業は、毎回プロンプトを打ち直すのではなく、
   スキルファイルにして毎回モデルに読ませるべきだと知っている
3. 自動化プロジェクトのどこ 15% にモデルの判断が必要で、
   どこ 85% が決定的コードで十分かを知っている
4. 最も重要：マージする前に diff をしっかり読む

同じチケットを渡された 2 人のエンジニア、5 分で分岐する

この差を具体的な場面に落とすと、こうなります。同じチケットを 2 人のエンジニアに渡す。

1 人目のエンジニア：Jira のテキストを Claude に貼り付け、送信をクリック。変更は 6 つのファイルに及びました。ひと通り眺めて、テストが通っているのを確認して PR をマージ。3 週間後、本番環境で不具合が出始めて、ようやく誰かが気づく。この PR が理由もなく設定値を 1 つ変えていたのです。

2 人目のエンジニア：同じように Jira のテキストを貼るところから始める。だが、次にコードがリポジトリのどこにあるか、どのフォルダとファイルを触るべきか、どれに触るべきでないかを明示します。彼はすでにスキルファイルを持っていて、Claude が提出するすべての PR が簡潔で冗長でなく、提出前にテストが十分に行われることを保証しています。それから diff を読み、余分な変更を 1 か所見つけ、ひとつのプロンプトで修正します。最終的にマージされた PR は、1 人目の半分のサイズだ。

FIGURE 3 - Same tool, same seat, different outcome。出典：Vasuman / Varick Agents

そして、どの組織でも、少なくとも半分の人は永遠に 2 番目の状態に到達できない。AI を使いこなすのは職人技で、膨大な反復が必要です。まだ AI という船に乗っていない人にとって、その慣性は多くの人に越えられない壁です。プロンプトをめちゃくちゃに打つだけのユーザーを、緻密な使い手に育てるのも同じくらい難しい。

完璧に導入しても、結果はバーベル

では、導入がうまい会社ならどうか？一番ありがちな反論は「それは導入が下手だっただけです。自分がやればうまくいく」というもの。この反論は成り立ちません。完璧に導入したとしても、手に入るのはやはりバーベルです。

もう 1 人の役員の話はもっと直接的です。全組織にエンタープライズ版ライセンスを配備した直後、8 桁ドルの年間コミットメント。結果は：およそ 10% の人が 90% のトークンを消費した。

ここで計算ができる：

FIGURE 4 - 10% of your seats burn 90% of the tokens。出典：Vasuman / Varick Agents

88% の企業が AI を利用、利益に結びついたのは 6% だけ

以上はすべて一次観察です。公開調査はどうか？繰り返し引用される 2 つのレポートが、同じ方向を指しています。

「採用率」という指標の問題もここで見えてくる：採用はイエスかノーかの二択。スキルはスペクトラムです。採用率を指標として追うとき、あなたが問うているのはせいぜい 2 択の抽象概念だけ。「この人は今月ログインしたか」「この人は今年ログインしたか」「この人は毎日 5 件以上プロンプトを送ったか」。

だが、その数字は技術的には本物です。誰も採用率について嘘をついていません。ただ、本当に気にすべきことよりも、はるかに測定が簡単なだけだ。あなたが本当に知りたいのは、社員一人ひとりの AI 習熟度と、トークン 1 つあたりのリターンです。

FIGURE 5 - What the adoption number hides。出典：Vasuman / Varick Agents

ベンダーも企業も社内の達人も、直す気がない

これだけ問題が明白なら、なぜ誰も直さないのか？ベンダー、企業、社内の達人。3 者にはそれぞれの事情があります。

ベンダー

どの AI ベンダーのロードマップも、エージェントの能力がどれだけ向上したかを語ります。チームがそれを使いこなす能力については一言もありません。だから、効果的に使えるのは先端ユーザーだけになります。そして先端ユーザーは声が一番大きいので、彼らが決定権を持つ。彼らは最も喜ばれるサービス対象でもあります。ウィンウィンです。結果として、機能がリリースされるたびに「製品を使いこなす」ためのスキルの下限が上がっていく。人は動かず、下限だけが上がり続け、溝はどんどん広がります。

企業

企業は「社員にプロンプトの書き方を研修しよう！」という発想に最も魅了されやすい。だがこれは、10% のゲームにすぎない。残りの 90% は「どのワークフローを決してモデルに触れさせるべきでないか、どれを完全に自動化すべきかを社員に判断させる研修」です。

これが売れにくいのは、企業ごとに答えが違うからだ。現場に数週間いて初めて分かります。

社内の AI 達人

彼らにも直す動機がありません。彼らのレバレッジこそがこの溝です。作業が 70% 速くなり、あとはサボれます。または 1 人で 3 人分の仕事ができます。全員がこの船に乗ったら、彼らの優位性は消えます。追加のインセンティブもないのに、なぜ彼らが直すのか？

研修は人を見つけるためだけに使える。人を変えるためには使えない

ここまでの観察を並べると、耳の痛い結論になります。彼自身はこう書いている：

この指標を本当に追いかけてみれば分かる。企業の大多数の人々が、AI ネイティブになる見込みはない。
それは彼らに価値がないということか？もちろん違う。ただ、あなたの導入計画と推進計画を、それに合わせて調整する必要があるということだ。 Vasuman

この言葉には 2 つの層があります。片方だけでは偏ります。第 1 の層は現実の直視：どの組織でも少なくとも半分の人は永遠に「使いこなす」段階に到達できず、しかもモデルが更新されるたびにそのハードルは上がっていく。第 2 の層は判断の留保：これは彼らの価値とは無関係で、あなたの計画の設計に関わる話です。

研修の本当の使い道は診断

研修はどうせやるなら、やらなければ誰が先頭にいるのか分からないからだ。社内には AI に興味がある人もいます。ただ時間と取り組みのきっかけがなかっただけです。研修は、一人ひとりの能力と居心地のいい領域をあぶり出す。

その人たちを見つけたら、公開の場を与える。共有データベースのような場所です。彼らが作ったスキルが公開され、ランク付けされ、他の人がインストールできます。彼がこれまで見た中で、一人の人間のブレイクスルーを共有可能なものに変える唯一の仕組みだ。

ここでのインセンティブはランキングです。ヘビーユーザーは自分の優位性を組織内の地位と交換したがります。だが、それでも差は残ります。これらのスキルを全員に押し出しても、50% の人は一度もインストールしないだろう。

つまり、この道がカバーできるのは、その一握りだけです。残りの大多数には、まったく別の発想が必要になります。

AI を裏方に回す。誰にも働き方を変えさせない

残りの大勢にとって、仕事は遂行される必要があります。だが、彼らに働き方を変えることを要求してはいけない。これは妥協のように聞こえるかもしれませんが、実は全体のプランの支点です。つまり AI は表舞台から裏方に下がる必要があります。

「AI を使う」ということは、暗黙のうちに「人間がダイアログを開き、文字を打ち、回答を待つ」ことだと理解されています。この暗黙の前提が、すべての負担を使い手にのしかける。何を聞くべきか、どう聞くべきか、回答のどこを信じてはいけないかを、使い手が知っている必要がある。先ほどのスキル差はすべて、この前提の上に成り立っている。

この前提を外すと、道筋が変わる。具体的には 3 つのステップだ：

具体的なイメージ：買掛金

数十人の買掛金アナリストがいる。彼らは毎日、請求書を処理している。この仕事のうち、おそらく 90% は自動化できる。

だが、彼らに自分でエージェントを立ち上げろとは期待できない。プロンプトを書くだけで本番環境で支障なく安定して処理を完了するのも期待できない。それは彼らが任されている仕事ではないし、そう訓練された人でもない。

だから、方向を変える：毎日自動で動くエージェントを作る。請求書のワークフローを処理させる。アナリストの役割は、承認するか、却下するか、エージェントが処理した結果を修正することに変わる。

彼らの働き方は変わらない（以前と同じシステムで数クリックするだけ）。だが、組織のアウトプットは変わる。

人々は、仕事を片付けてくれるツールを市場で探しているわけではない。ただ、仕事が片付いていればいいだけだ。 Vasuman

上の細い経路は研修（3 人しか通らない）、下の広い経路は裏方エージェント（大勢が通る）。2 つの経路は同じ終点「仕事が片付く」に合流する。経路の幅は実際の人数比で描かれている点に注意。出典：Vasuman / Varick Agents

もう取締役会に採用率を報告しない

最後に、明日から変えられる具体的な行動に落ち着く：報告の指標を変えることだ。

「採用率」の報告はやめろ。

代わりに、今日の仕事のうち、
  · どれだけが手作業で完了したか
  · どれだけが人と機械のハイブリッドで完了したか
  · どれだけが完全自動化で完了したか

これだけが、報告する価値があり、議論する価値のある指標だ。

数千人規模のオペレーション企業が Claude Cowork を導入した後、チームの速さは導入前と同じだった。Vasuman 氏は、すべての顧客で同じ「バーベル」を見てきた：両端が重く、真ん中は空っぽ。

その 5〜10% は、そもそも導入を会社に推した人たちだ。ダッシュボードは今回の導入を「採用成功」と記録する。オペレーション責任者が見た高速化はゼロ。この 2 つは同時に成立する。

同じチケットを 2 人のエンジニアに渡すと、5 分で分岐する。1 人目はチケットを Claude に貼って送信。6 つのファイルに変更が及び、ひと通り見てテストが通ればマージ。3 週間後、本番環境で問題が発生。余計な設定変更がひとつ紛れ込んでいた。2 人目は最初に触るファイルを明示し、既存の作業手順書（スキルファイル）で変更を簡潔に保ち、マージ前に変更記録（diff）をしっかり読んで余計な変更を 1 か所見つけ、最後にマージした PR は前者の半分のサイズだった。

別の企業は、8 桁ドルの年間 AI ライセンスを結んだ直後、全体の 10% が使用量（トークン。AI が処理する文字数の課金単位）の 90% を消費していた。

ベストケースが、ワーストケースになる。

公開調査も同じ形を裏付けている。

採用率が答えられるのは「この人は今月ログインしたか」だけだ。「メールを貼って整形する」と「3 つのエージェントが総勘定元帳を動かす」を区別できない。ここがこの指標が偽である所以だ。

社員全員を AI の達人に育てるのは行き止まりだ。しかもハードルはモデルが更新されるたびに上がる。研修が本当に効くのは健康診断としての使い方だ。もともと先頭にいた人を見つけ、ランキングされ、他の人がインストールできる公開の場を与える。残りの大多数には働き方の変更を要求してはいけない。彼らがすでに使っているシステム（Salesforce など）にエージェントを直接組み込み、確認が必要な時だけ人を呼ぶ。