AI Firstの光と影 ―― 「誰にとって」正しいかが核心だ
AI Firstの光と影 ―― 「誰にとって」正しいかが核心だ
「AI Firstは失敗した」も、「AIが人を代替する」も半分しか正しくない。KlarnaはAIで700人を削減した後、再び人を採用している。MicrosoftはAIでコードの30%を書かせ、6,000人を削減している。同じ技術なのに結果が分かれる。核心は「AIを使うかどうか」ではなく、「どこに、誰が」 使うかだ。
1. 「AI First」実験の決算 ―― Klarnaという教訓
2024年、Klarna CEOのSebastian Siemiatkowskiは自信を持って宣言した。「AIが700人のカスタマーサービス担当者の仕事を代行している。」その発言の後、22%の人員削減が続いた。投資家は歓喜し、テックメディアは「AI First企業の模範事例」というタイトルを付けた。
ところが1年半が経った今、Klarnaは再び人を採用している。
何が起きたのか。AIチャットボットは全顧客問い合わせの2/3〜3/4を処理しており、数字上は悪くなかった。しかし顧客が体感するサービス品質は低下した。 簡単なFAQ回答に20秒以上かかり、最初のやり取りを超えると「亀裂が見え始めた(PolyAI)。」 複雑な決済紛争、感情的な不満、コンテキストの理解が必要な繰り返しクレーム ―― こうした領域でAIは「ポリシーによると…」といった定型化された回答を繰り返すばかりで、結果は未解決問い合わせ25%増加として現れた。顧客は「機械と戦っている」という印象を受けた。
Siemiatkowski自身が認めた。「コストが支配的な評価基準だった。その結果、品質が低下した。」「AI導入をあまりにも攻撃的に推し進めた(Bloomberg、Fast Company)。」 Klarnaは現在、Uberスタイルの柔軟な人材モデル ―― 学生、在宅の親、地方在住者をリモートエージェントとして採用 ―― に転換しながら、AIと人のハイブリッドモデルを構築している(Fortune)。
Klarnaは例外的な事例ではない。Salesforceも同じ道を辿った。カスタマーサポート人員を4,000人削減しAIエージェントを投入したが、その後経営陣が**「AIの実戦準備度を過大評価していた」と公に認めた(CMSWire)。自動化システムがニュアンスのある問題、エスカレーション、ロングテールの顧客課題で苦戦し、サービス品質が低下、苦情が増加した。技術的限界も明らかになった ―― LLMに8つ以上の指示を与えると、一部を無視し始める**ことがSalesforceの実戦経験で判明した。
Gartnerの2026年2月レポートはより広い構図を示している。AIを活用して人員を削減した企業の50%が2027年までに再雇用に動くという予測だ。興味深いのは、再雇用される際の肩書きが変わることだ。「カスタマーサービス担当」ではなく「ソリューションコンサルタント」「トラステッドアドバイザー」「プロダクトスペシャリスト」。実際にカスタマーサービスリーダーのうち**人員を実質的に削減した割合はわずか20%**だった。大多数は人員を維持しながらより多くの顧客をサポートする方を選んだ。
一方、Qualtrics調査によると、AIカスタマーサービスを利用した消費者の5人に1人が何の助けも得られなかったと報告している ―― 他分野のAI活用と比べて失敗率が4倍高い。投資規模も問題だ。2025年上半期にAIに投じられた470億ドルのうち、89%がわずかなリターンしか生み出していない。
「AI First」が失敗したのではない。「無分別なAI First」が失敗したのだ。 そしてその「無分別さ」の本質は、AIが得意なことと苦手なことを区別せず丸ごと押し込んだところにある。
2. しかし ―― AIが実際に機能している場所もある
Klarnaの失敗を見て「AIは誇大広告だ」と結論づけると、それもまた半分しか正しくない判断だ。同時期にAIが実質的な成果を上げている場所は確かに存在する。差を生んでいるのは**「何を任せたか」**だ。
カスタマーサービスでAIが成功した事例を見よう。 FreshworksのFreddy AIは小売の顧客問い合わせの53%を自動処理し、初回応答時間を12分から12秒に、解決時間を1時間以上から2分に短縮した。GrandStay HotelsはAI導入後に顧客満足度が22%上昇した(Freshworks、Sobot)。これらの共通点は明確だ ―― 狭い範囲の定型化された問い合わせにのみAIを適用し、複雑な案件は最初から人につないだ。3年間でROI 210%、6ヶ月未満で投資回収を達成した企業はいずれも「クリーンなデータ、統合されたシステム、狭い初期スコープ、明確なエスカレーションパス」を備えていた。
カスタマーサービスの構造をデータで見ると、パターンはより鮮明になる。全顧客問い合わせの60〜70%は単純な問い合わせだ ―― パスワードリセット、注文確認、FAQ。この領域でのAIの解決率は96〜97%に達し、顧客満足度も人と同等かそれ以上だ。消費者の61%が単純な問い合わせにはむしろセルフサービスを好む。一方、30〜40%は複雑な問い合わせ ―― 紛争、感情的な不満、ポリシー例外処理 ―― であり、ここでAIは体系的に失敗する。AIが「パターンを認識して次に来る言葉を予測する」方式で動作しているのであって、「意味を解釈する」わけではないからだ(HBS Online)。KlarnaとFreddy AIの違いは技術力ではなく、この境界を尊重したかどうかだ。
ソフトウェアエンジニアリングでも同じパターンだ。 Microsoftはコードベースの20〜30%をAIが書くよう転換し、6,000人を削減した。だがこの数字を分解すると話が変わる。AIが書いているコードは主にボイラープレート ―― getter/setter、CRUDオペレーション、単純な関数 ―― だ。アナリストたちはAIのコーディング能力を「おおよそジュニア開発者レベル」と評価する。ワシントン州で削減された2,000人のうち40%以上にあたる817人がソフトウェアエンジニア、373人がプロダクトマネージャーだったが(Seattle Times)、公式目標は「管理レイヤーの削減」だった。アーキテクチャ設計、システムデザイン、複雑なデバッグを担うシニアエンジニアはそのまま残っている。
医療分野は最もドラマチックでありながら、最もニュアンスに富んだ事例だ。 医療文書の文字起こし(transcription)業務の自動化が急速に進み、BLSはこの職種の雇用が2023〜2033年に5%減少すると予測している(BLS)。しかし「99%自動化」という表現は半分しか正しくない。AI文字起こしは人間とは質的に異なるエラーを生み出す。例えば「digoxin 0.25mg」を「digoxin 2.5mg」と自信を持って書き換える ―― 10倍の用量差だ(DeepCura)。結果として医療文字起こし担当者が「消えた」のではなく、「タイピングする人」から「AI出力を検証する人」へと役割が転換した。人数は減ったが、残った人に求められる能力はむしろ高くなった。
放射線科も同様だ。FDAが承認した放射線AI アルゴリズムは873に達し、放射線科医の85%がAIは患者治療を改善すると答えた(RSNA)。しかし「放射線科医をAIが代替する」という初期の予測は外れた。実際に起きたのは、**「AIを使う放射線科医が、AIを使わない放射線科医を代替する」**ということだ。医療コーディングでもAIはエラーを40%削減し生産性を33%向上させたが(PMC)、人間の監督は依然として必須だ。
3つの産業を並べるとパターンが見える。
| 産業 | AIが代替したタスク | AIが代替できなかったタスク |
|---|---|---|
| カスタマーサービス | 単純問い合わせ(FAQ、注文確認、パスワード) | 紛争解決、感情的対応、ポリシー例外判断 |
| ソフトウェア | ボイラープレートコード、単純な関数生成 | アーキテクチャ設計、複雑なデバッグ、セキュリティ設計 |
| 医療 | 文字起こし、基本コーディング | 臨床判断、患者対面、AI出力の検証 |
共通項:入力が定型化されており、出力形式が決まっており、判断の範囲が狭いタスクではAIは人より速く、安く、一貫している。一方、コンテキスト解釈、例外判断、感情的インタラクション、システムレベルの思考が必要なタスクではAIは体系的に失敗する。これは「AIの能力の問題」ではなく、AIという技術の構造的特性だ。
3. 「職業」ではなく「タスク」が分かれる ―― そしてジュニアが危うい
ここからもう一歩踏み込んでみよう。「ある企業は削減し、ある企業は増やしている」という表層的な現象の裏には、研究者たちが捉えたより根本的なパターンがある。
MIT経済学者のDavid Autorは2003年に提示した「ルーティン/非ルーティン」フレームワークをAI時代に合わせてアップデートした。核心的な区分はこうだ(Brookings、NBER):
- 自動化ツール(Automation tool):専門性の必要性そのものを排除する。その仕事をしていた人が不要になる。
- 協業ツール(Collaboration tool):専門性を増幅する。すでに知識を持つ人がより多くの仕事をこなせるようになる。
同じAI技術が、同じ職業の中でもタスクによって自動化ツールにも協業ツールにもなる。医療文字起こしでは「書き取り」は自動化されたが、「検証」という新たな協業タスクが生まれた。コーディングでは「ボイラープレート生成」は自動化されたが、「AIが書いたコードのレビュー」という協業タスクがより重要になった。
ここに、従来の自動化の波とは決定的に異なる点がある。スタンフォード大学の経済学者Erik Brynjolfssonはこれを**「チューリング・トラップ(Turing Trap)」**と呼ぶ(Stanford Digital Economy Lab):
「人間を模倣するAI(自動化)は賃金を下げる。人間にできなかったことを可能にするAI(増幅)は賃金を上げる。」
過去の自動化は主に中程度のスキルのルーティン業務を代替した ―― 工場の組み立て、事務補助、データ入力。しかしLLMベースのAIは高度な知的労働にまで手を伸ばしている。 これは以前の自動化の波の逆転だ。以前は「安全」とされていた高学歴・高収入の職種のタスク ―― 法律文書の分析、コード作成、医療診断補助 ―― が今回は自動化の対象になったのだ。
ところがデータを見ると、結果は直感と異なる。ダラス連邦準備銀行(Dallas Fed)の2026年2月の分析によると、経験プレミアムの高い職種 ―― 弁護士、保険審査官、信用アナリスト ―― ではAI導入後にむしろ賃金が上昇した。弁護士が判例検索に3時間かかっていた仕事をAIが10分に短縮する。しかしその判例を解釈し、戦略を立て、依頼人を説得するのは依然として弁護士の仕事だ。AIが「自動化ツール」ではなく「協業ツール」として機能したのだ。
一方、経験プレミアムの低い職種 ―― 発券担当者、ファストフード店員、データ入力 ―― では雇用が減少し賃金が停滞した。10年選手と1年目の業務処理速度にほとんど差がない職種では、AIがその仕事をできるようになると、人を雇う理由そのものが薄れる。コンピュータシステム設計分野の賃金上昇率が**16.7%であるのに対し、全国平均は7.5%**に留まる。
そして最も痛みを伴うデータがある。 Harvard/SSRNの2025年研究は285,000社の米国企業と6,200万人の労働者を分析した。企業が生成AIを導入すると、ジュニアの雇用が6四半期以内に9〜10%減少する。シニアの雇用にはほぼ変化がない。注目すべきは、これが「解雇」ではなく**「採用停止」**だということだ。ポジションが空いても新たに補充しない。
スタンフォードのデータはより具体的だ。22〜25歳のソフトウェア開発者の雇用が2022年のピークからおよそ20%減少した(Understanding AI)。上位15テック企業のエントリーレベル採用は2023〜2024年に25%減少。500人のテックリーダーを対象とした調査で72%が「エントリーレベル開発者の採用を減らす計画」と答え、64%が「代わりにAIツールに投資する」と答えた(CIO)。
これが生み出す構造的な問題がある。ジュニア開発者はボイラープレートコードを書きながら学ぶ。単純なCRUDを実装しながらデータベースを理解し、ユニットテストを書きながらコード構造を体得する。AIがこの「修練過程」を代替すると、5〜7年後にはシニアになるべき人材がいないパイプラインの断絶が発生する。Companion Groupのあるエンジニアは、AIツールを多用した後に「以前は直感的にやっていた作業が手動で面倒なものになった」と報告している(Stack Overflow)。AIに対する開発者のポジティブな認識は2023〜24年の70%以上から2025年には60%に低下した。
これらのデータが指し示す結論は同じだ。AIは「職業」を丸ごと代替するのではなく、「タスク」を選択的に代替する。 そして代替されるタスクは主に定型化された反復業務だ。AI導入を設計する際にこの区分を正確に行えるかどうかが成否を分ける ―― KlarnaとFreshworksの違いがまさにここにある。
4. 「全社員をAIビルダーに」の落とし穴
この文脈で、最近注目を集めたスタートアップの話をしなければならない。
Gumloopは2026年3月、シリーズBラウンドで5,000万ドルを調達した。ノーコードAIエージェントビルダーを標榜し、「すべての社員がAIエージェントを作れる世界」をビジョンに掲げた。ドラッグ&ドロップでワークフローを設計し、コード一行なしにAIエージェントをデプロイできるという。
魅力的なビジョンだ。開発者でなくてもAIを活用できれば、組織全体の生産性が上がるだろう。正しい ―― 理論上は。
現実のデータは異なる話を語る。RAND Corporationの2025年レポートによるとAIプロジェクトの失敗率は80.3%。さらに絞って生成AIパイロットプロジェクトだけ見ると、95%がPoC段階を越えてスケーリングに失敗する。世界全体でAIに投じられた6,840億ドルのうち80%以上が期待した成果を出していないという分析もある(Pertama Partners)。
なぜ失敗するのか。ツールが不足しているからではない。問題を定義する力が不足しているからだ。
ノーコードAIビルダーが解決するのは「実装のハードル」だ。コードを知らなくてもエージェントを作れる。しかし「この業務のどの部分を自動化すべきか」「入力データの品質をどう保証するか」「エージェントが誤った判断を下した時、どう検知して復旧するか」 ―― こうした問いに答えるのはツールではなく人の力量だ。ノーコードがいくら簡単になっても、何を作るべきか分からなければ、簡単なツールで素早く間違ったものを作るだけだ。
そして「AIが作ってくれるから速く作れる」という体感そのものが錯覚かもしれないというデータがある。METRの2025年ランダム化比較試験(RCT)は衝撃的な結果を出した。16人の熟練したオープンソース開発者(平均2万2千スター以上のリポジトリ管理者)にAIツールを与え実際のタスクを実行させた。AIを使用したグループは実際には19%遅かった。 それなのに本人たちは20%速くなったと信じていた。 実験終了後もこの認識は変わらなかった。原因は不完全なプロンプティング、AIインターフェースとの格闘、高い品質基準とAI提案の不一致、そしてAIを「試す」ことに費やされた認知コストだった。
コード品質のデータはより直接的だ。CodeRabbitの2025年分析はGitHubの470件のPR(AI共同作成320件、人間のみ150件)を比較した。AIが関与したコードはPRあたりの問題が10.83件 vs 人間のみ6.45件で、約1.7倍多かった。単に「バグが多い」というだけでなく、種類が異なる:
- ロジック/正確性エラー:+75%
- セキュリティ脆弱性:1.5〜2倍(パスワード処理の不備、安全でないオブジェクト参照)
- コード可読性の問題:3倍
- パフォーマンス非効率(過剰I/O):ほぼ8倍
- 並行制御エラー:2.29倍
GitClearの5年間2億1,100万行の分析(Google、Microsoft、Metaを含む)はコードベースレベルの変化を示している。コピー&ペーストコードが2020年の8.3%から2024年の12.3%へ48%増加し、リファクタリングされたコードは24.1%から9.5%へ半分以下に減少した。コードチャーン(新しいコードが2週間以内に修正・リバートされる割合)は5.5%から7.9%に上昇した。AIはコードをより速く生成するが、そのコードを直すためにかかる時間も増えているということだ。
結局、ノーコードAIビルダーの本当の受益者は誰か。業務プロセスを理解し、自動化の境界を判断でき、成果物を検証できる人だ。こうした人にとってノーコードは「実装時間を短縮するツール」になる。反対にそうした判断なしにツールだけ渡しても、素早く間違ったものを作るだけだ。
ツールが簡単になることと、そのツールをどこに適用するかを設計することは、まったく異なる領域の仕事だ。 AI導入の成否を分けるのはツールの性能ではなく、適用ポイントを正確に設計する専門性だ。
5. 歴史は同じパターンを繰り返す ―― ただし、今回は速度が違う
不安になるかもしれない。ジュニアの採用が減り、AI失敗率は80%で、コード品質は下がっている。メディアはこうした数字を選択的に取り上げ、恐怖を煽るのが巧みだ。しかしテクノロジーが労働市場を変えるのはこれが初めてではない。 歴史的パターンを見れば、今起きていることの輪郭がもう少し鮮明になる。
ATMと銀行窓口係(1970s〜)。 ATMが登場した時、すべての専門家が窓口係の終焉を予言した。実際に支店あたりの窓口係は1988年の20人から2004年の13人に減った。しかし支店運営コストが下がったことで銀行は都市部に43%多くの支店を出店した。 純雇用はむしろ労働力平均より速く増加した(AEI)。窓口係の役割は「現金の計数」から「リレーションシップ管理と商品コンサルティング」へ転換した。
表計算ソフトと会計士(1980s〜)。 VisiCalc(1979年)、Lotus 1-2-3、Excelの登場で20時間かかっていた手計算が15分に短縮された。結果:経理事務員(bookkeeper)は40万人減少したが、正規の会計士(accountant)は60万人増加した(NPR)。計算が簡単になると企業はそれまで試みなかったシナリオ分析や戦略的モデリングを求め始め、数字を「作る」人の代わりに数字を「解釈する」人の需要が爆発した。
2つの事例で同一の4段階パターンが繰り返される:
- ルーティンの実行タスクが自動化される(現金計数、手計算、手描き製図)
- 当該機能のコストが下がり、需要そのものが増加する(支店増設、シナリオ分析の増加)
- 残った人間のタスクの価値が上昇する(リレーションシップ管理、戦略的解釈、設計判断)
- より広い分野での純雇用は維持または増加する
AIでも同じパターンが見え始めている。コード生成コストが下がることでソフトウェアプロジェクトの総量が増え、アーキテクチャとシステム設計の価値が上がっている。医療では文字起こしコストが消えることで診療記録の量が爆発し、それを検証・分析する能力の需要が増えている。
しかし、決定的な違いが一つある:速度だ。
ATMの転換は40年をかけて起こった。その間に窓口係は新たな役割への再教育を受ける時間があった。表計算ソフトでも経理事務員が正規会計士に転換するための教育と資格取得の時間があった。AIの転換は3年で起きている。ジュニア開発者の採用が20%減るのに2年しかかからなかった。Klarnaが700人を削減して再雇用に至るまでわずか1年半だった。再教育と適応の時間が圧倒的に足りない。
これが歴史的パターンから読み取れる本当の教訓だ。長期的にAIは新たな役割を生み出すだろう。しかし短期的に転換の速度が適応の速度を上回ると、その間に人が傷つく。 「いずれ大丈夫になる」という長期展望は正しいかもしれない。しかしその「いずれ」に至る過程が以前よりはるかに急勾配であることが、今回固有のリスクだ。
6. 「AI Effective」という正解 ―― ただし、条件付き
では正しいアプローチは何か。
近年、業界で登場した概念がある。「AI Effective」 ―― AIを無条件に適用するのではなく、AIが効果的な場所にのみ適用する設計哲学だ。
AI Firstは「あらゆるプロセスにまずAIを適用し、合わない箇所は後から外す」というアプローチだ。攻撃的で速い。しかしKlarnaが示したように、「合わない箇所」を後から発見するコストは大きい。顧客離れ、品質低下、再雇用費用。実験のツケを顧客と従業員が払う。
AI Effectiveはその逆だ。「AIが効果的な場所をまず特定し、そこにだけ適用する。」 Freshworksが小売問い合わせの53%だけをAIに任せ、残りを人に残したのがこのアプローチの例だ。Microsoftがボイラープレートコードの作成にのみAIを投入し、アーキテクチャ設計はシニアに任せたのも同じ。医療で文字起こしはAIに、検証は経験豊富な専門家に任せるのもそうだ。
AI Effectiveは正しい。同意する。しかしここに前提条件がある。
「AIが効果的な場所」を特定するには、まず業務そのものを深く理解していなければならない。 カスタマーサービスで単純問い合わせ60%と複雑問い合わせ40%の境界を知るには、カスタマーサービスの運営経験が必要だ。コードでボイラープレートとコアロジックの境界を知るには、ソフトウェアアーキテクチャへの理解が必要だ。医療文字起こしでAIが「自信を持って間違える」1%を見抜くには、医療ドメイン知識が必要だ。
AI Effectiveの「Effective」を判断すること自体が、専門性の領域だ。 ツールが解決してくれるものではない。ノーコードが解決してくれるものではない。Brynjolfssonが言う「チューリング・トラップ」を避けるには ―― つまりAIを「人を代替するツール」ではなく「人を増幅するツール」として設計するには ―― 何が代替可能で何が増幅可能かを見分ける目が必要だ。その目は現場経験と技術的理解の交差点から生まれる。
だからこそAI時代に重要になるのは逆説的に**「人の専門性」**だ。自社の業務をタスクに分解でき、AIが担う60%と人が担う40%の境界を正確に設計できる力。Klarnaが1年半かけて学んだことを最初から知って設計するのと、試行錯誤で学ぶのとでは、途方もないコストの差がある。AI導入において「正しい設計」ができるパートナーを選ぶことが、結果を左右する。
7. 結論 ―― 同じAI、異なる結果を生むのは「設計」だ
まとめよう。
「AIが仕事を奪う」 ―― 半分だけ正しい。AIが代替するのは「職業」ではなく「タスク」だ。そしてそのタスクは主に定型化された反復業務だ。Dallas Fedのデータ、Harvardの研究、Stanfordのデータがすべて同じ方向を指している ―― AIは専門性を持つ人には増幅器であり、ルーティン業務には代替材だ。
「AI Firstは失敗した」 ―― 半分だけ正しい。失敗したのはカスタマーサービスの60%と40%を区別せず、ボイラープレートとアーキテクチャを区別せず、文字起こしと検証を区別しなかった無分別なAI Firstだ。タスクレベルで正確に適用した企業は実際にROI 210%、コスト50%削減といった成果を上げている。
「全社員がAIビルダーになるべきだ」 ―― 方向は正しいが前提が抜けている。METR実験が示すように、AIツールを使うだけでは速くならない。ツールが簡単になっても「どこに適用するか」を設計する力はツールからは生まれない。FreshworksとKlarnaの違いはAI技術の違いではなく、適用設計の違いだった。
「長期的には大丈夫になる」 ―― 歴史的パターンを見ればおそらく正しい。ATMの後に銀行員数は増え、表計算ソフトの後に会計士数は増えた。しかし40年かかった転換が3年で起きている。だからこそ今すぐ重要なのは、転換の速度に耐えうる設計だ。
結局、AI導入で最も高くつく過ちは「AIを導入しないこと」ではない。**「どこに適用するか設計せずに導入すること」**が最も高くつく過ちだ。Klarnaはその授業料として1年半の顧客離れと再雇用コストを支払った。Salesforceは4,000人を削減した後に「AIの実戦準備度を過大評価していた」と認めざるを得なかった。
一方、同じ時期にFreshworksは53%の問い合わせだけをAIに任せてROI 210%を達成した。MicrosoftはボイラープレートだけをAIに任せ、シニアエンジニアの生産性を引き上げた。医療分野は文字起こしをAIに任せつつ、検証は経験豊富な専門家に残した。
違いを生んだのは技術ではなく、「どこまでAIに任せ、どこから人がやるか」を正確に設計した専門性だ。AIが得意とする60%と人がやるべき40%の境界を知ること。AIが書いたコードのセキュリティ脆弱性(2倍)と並行性エラー(2.3倍)を検証できる力を備えること。AI文字起こしが「自信を持って間違える」1%を見抜けるドメイン知識を確保すること。
AI時代に最も価値ある力はAIそのものではない。AIを正しい場所に配置する設計力だ。そしてその設計は、技術とビジネスの両方を理解する場所からしか生まれない。