AI Agentがチームを遅くしている。その理由と、代わりにやるべきこと
Anthropic、Amazon、Uberで、AI生成のアウトプットが仕事を増やしていた事例が報告されている。このパターンはエンジニアリングだけの話ではない。SMB営業チームが知るべき教訓。

イラスト: DALL-E 3 by Revenue Velocity Lab
UberでAIツールを月20日以上使う開発者は、同僚より52%多くプルリクエストを出す。見事な数字だ。ただし、Uberではそのプルリクエストの品質を誰も計測していない。
この事実はGergely OroszがThe Pragmatic Engineerで報告したものだ。AIツールを使っている人間なら、立ち止まって考えるべき種類の数字だ。アウトプットが増えることと、アウトプットが良くなることは同じではない。そして記録された複数のケースで、AIはチームを計測可能なレベルで悪くしていた。
AI detects buying signals and executes revenue actions automatically.
See weekly ROI reports proving AI-generated revenue.
3つの企業、3つの警告
Anthropic自身のプロダクトにバグが残っていた
皮肉な話だ。Claudeを作っているAnthropicのClaude.aiで、ユーザーの入力が消えるという基本的なUXバグがあった。サイトのコードの80%以上がClaude自身によって生成されていた。バグは誰にも気づかれなかった。
問題はAI生成コードそのものではない。人間が書いたコードと同じ注意力でレビューされなかったことだ。コードベースの80%がAI生成で、全部コンパイルが通ると、「たぶん動いている」という前提が生まれる。バグはその前提の中に潜む。
AmazonのAI変更による13時間の障害
Amazonでは「高ブラスト半径」のインシデントが複数報告されており、AI生成のコード変更が関与していた。あるケースでは、AIツールKiroが「環境を削除して再作成する」と判断し、13時間のAWS障害を引き起こした。
Amazonの対応は構造的なものだった。ジュニアエンジニアのAI支援による変更は、デプロイ前にシニアの承認が必須になった。ツールを禁止したのではない。ツールの上に人間の判断レイヤーを追加した。ツール単体では、自分のアウトプットがいつ危険なのかを判断できないから。
Uberは量を計測し、品質を計測しない
UberとMetaはどちらも、AI使用量をパフォーマンスレビューに組み込んでいる。Uberでは月20日以上AIを使う開発者を「パワーユーザー」と分類している。パワーユーザーはPRを52%多く出す。
しかしUberが追跡していないものがある。バグ率、コードレビューの拒否率、本番障害率、AI生成コードの長期メンテナンスコスト。計測されているのはアウトプットの量。品質は未計測だ。
OpenCodeの創設者Dax Raadはこう断言している。AIエージェントは「クリーンアップに時間を費やす」環境を作り、リファクタリングを阻害する。チームが速くなるのではなく、チームが管理すべきモノが増える。
3つの事例に共通するパターンは同じだ。AIがアウトプットの量を増やす一方で、品質は低下するか、少なくとも計測されていない。PRが増えた。メールが増えた。生成されたコンテンツが増えた。ただし、増えた分のアウトプットに価値があるかは誰も確認していない。
これはエンジニアリングだけの話ではない
営業チームを運営しているなら、これはエンジニアの話で自分には関係ないと思うかもしれない。関係ある。パターンはそのまま当てはまる。
AI営業ツールがアウトリーチを大量生成するとどうなるか。
量が増える。 営業担当は1日のメール送信数が3倍になる。ツールがパーソナライズされたイントロを書き、フォローアップシーケンスを処理し、手動ではリーチできなかった企業にコンタクトする。活動指標は見栄えがいい。
品質は計測されない。 返信率が下がっているかもしれない。「パーソナライズ」されたイントロが、週5通の似たメールを受け取る受信者にとっては没個性に見えているかもしれない。コンタクトされている企業が実は買うタイミングにないかもしれない。しかしAI導入前後でメール1通あたりの返信率を比較している人はいない。3倍のボリューム増を祝っている。
結果:仕事が減るのではなく増える。 営業担当がAI生成ドラフトを確認し、しっくりこないメッセージを編集し、そもそも適格でなかったリードをフォローアップする時間が発生する。ツールは営業の1日を圧縮したのではない。方向を変えただけだ。
これは営業版のUberパターンだ。成果ではなく活動量を計測している。
2種類のAIツール
上の事例から、AIツールを選ぶチームにとって重要な区別が浮かび上がる。
仕事を圧縮するAIは、チームが手動でやっていたステップをなくす。ターゲット企業の特定。今週どのアカウントに優先的にアプローチすべきかの判断。CRMへの活動記録。リードの適切な担当者へのルーティング。導入後、そのワークフローにかかるチームの総時間が減る。浮いた時間が商談、交渉、関係構築に移る。
仕事を増やすAIは、チームが確認・編集・承認・修正する必要のあるアウトプットを生成する。営業担当が書き直すメール下書き。営業担当が再評価するリードスコア。マネージャーが再解釈するレポート。導入後、ワークフローの総時間は変わらないか増える。各ステップは速く感じるが、エンドツーエンドのプロセスは実際には縮まない。
判定は簡単だ。ツール導入後、このワークフローの総所要時間は減ったか?「各ステップは速くなったか」ではなく「全体は短くなったか」を問う。
「各ステップは速いが、ステップ数が増えた」なら、それはAmazon/Uberパターンだ。AIが仕事を作っている。
SMBチームが本当に計測すべきもの
AIを営業プロセスで使っているなら、仕事を圧縮しているか増やしているかを判定する数字はこれだ。
| 指標 | 圧縮している場合 | 増やしている場合 |
|---|---|---|
| 1人あたりのアウトリーチ総時間/日 | 減少 | 横ばいか増加(確認+編集時間が発生) |
| アウトリーチ1件あたりの返信率 | 維持か改善 | 低下(量は増えたが関連性が下がった) |
| 営業1時間あたりの商談獲得数 | 増加 | 横ばい(メール増、商談変わらず) |
| CRMデータ入力時間 | ゼロに近づく | 「AI入力の確認」時間に置き換わった |
| リード特定から初回コンタクトまで | 短縮 | 変わらず(AIがリードを見つけるが、担当がまだリサーチする) |
右列が自分のチームの状態なら、ツールはステップを減らすのではなく増やしている。AI全般の失敗ではない。そのツールがワークフロー圧縮ではなくアウトプット量に最適化されているというシグナルだ。
判断レイヤーが最も重要
Amazonの対応は示唆的だ。ジュニアエンジニアからAIツールを取り上げたのではない。人間のレビューステップを必須にした。AIが生成し、人間が判断する。
営業チームでの対応策も同じ構造だ。AIがリサーチと準備を担い、人間が2つのことの主導権を握る。
1つは、どの企業にアプローチするか。AIは候補を出す。でも今日、会話する価値があるのはどれかを決めるのは営業だ。
もう1つは、メッセージの中身。AIが下書きしてもいい。だが全メッセージを営業が読まずに送っていたら、Uberと同じ状態だ。品質管理なしの量産。
少人数チームに最も合うツールは、AIが営業の時間を食っていた作業(リサーチ、データ入力、優先順位付け)を担い、営業の役割が「単純作業」から「判断」に移るもの。営業の役割が「AI出力の確認」に移るなら、それは負荷の種類が変わっただけで、軽くなってはいない。
問いは「AIで速くなったか」ではない
「AIで良くなったか」だ。
何が速くなった? 誰も返信しないメールを速く送れるようになったなら、それは生産性の向上ではない。今日リーチすべき5社を速く特定できるようになり、浮いた時間で営業が実際の商談に入っているなら、それは本物の改善だ。
Pragmatic Engineerの報道が示すのは、AIを作っている企業(Anthropic)も、AIを最も積極的に導入している企業(Amazon、Uber、Meta)も、この区別に苦戦しているということだ。彼らですら自動的にはできない。意図的に計測するしかない。
今週やること
チームが使っているAIツールを1つ選ぶ。5日間、2つの数字を追跡してほしい。
1つ目。各営業担当が、そのツールが改善するはずのワークフローに費やす総時間(確認、編集、修正の時間を含む)。
2つ目。そのワークフローの成果指標(返信率、商談獲得数、適格リード数)。
総時間が減っておらず、成果も上がっていなければ、そのツールは仕事を増やしている。AIがダメということではない。そのツールがチームに必要な「圧縮」ではなく「量産」に最適化されているということだ。
圧縮がどういうものか見たければ — リサーチが自動で回り、営業がドラフトの確認ではなく商談に時間を使える仕組み — Optifaiを7日間無料で試せる。クレジットカード不要。
AI detects buying signals and executes revenue actions automatically.
See weekly ROI reports proving AI-generated revenue.