- AIユーザー間の生産性格差が急速に拡大しており、「パワーユーザー」はClaude Code、MCPsなどの高度なAIツールを積極活用している一方で、多くの人はいまだにChatGPTレベルの対話型利用にとどまっている
- 大企業はセキュリティポリシー、閉鎖的なIT環境、レガシーシステムのために最新のAIツールを導入しにくい一方、小規模企業は急速にAIを内在化して効率を高めている
- この格差は小さなチームが大企業よりはるかに高い生産性を出せる時代へとつながっており、内部APIと安全なコード実行環境の構築が将来の競争力の中核として浮上している
- プログラミング言語とAPIにアクセスできるbashサンドボックスにエージェントを組み合わせれば、非技術者でもほぼあらゆる生産性アプリを置き換えられ、これが知識労働の未来の姿である
2種類のAIユーザー
- AIユーザー間の生産性格差が急速に拡大している
- 一方ではClaude Code、MCPs、スキルベースのワークフローを活用し、非技術者でさえターミナルでAIを積極的に使っている
- とくに財務部門では、Pythonベースの自動化によってExcelの限界を克服する事例が多い
- もう一方では、いまだにChatGPTレベルの単純な質疑応答型の利用にとどまっている
- 多くの会社員が依然としてこの範疇にあり、AIの潜在力を十分に活用できていない
Microsoft Copilotの限界
- M365 CopilotはOffice 365サブスクリプションにバンドルされているため企業市場でのシェアは高いが、ChatGPTの劣化版レベルのインターフェースである
- 「エージェント」機能は、CLIコーディングエージェント（Microsoft自身のGitHub Copilot CLIを含む）と比べると笑い話のようなレベル
大容量ファイルで頻繁に失敗し、メモリ・CPU制限が過剰である
- Microsoft内部でさえClaude Codeを社内チームに導入している
- これはCopilotが技術的に後れを取っていることを示す事例である
- 企業環境ではCopilotが唯一許可されたAIツールであることが多く、従業員は他のツールを使おうとすると解雇リスクを負うか、多大な労力を払わなければならない
— 上位意思決定者がこうしたツールでひどい結果を経験した後、AI全体を過小評価したり、大手コンサルティング企業に莫大な費用を支払っても成果が出ない状況
大企業が直面する構造的リスク
- セキュリティ重視の閉鎖的なITポリシーがイノベーションを妨げている
- 極端にロックされた環境: 基本的なスクリプトインタプリタすらローカルで実行不可（運が良くてVBA程度で、それすらGroup Policyで制限される）
- レガシーソフトウェア: 基幹ワークフローに内部APIがなく、エージェントが接続する対象そのものがない
- サイロ化されたエンジニアリング部門: 完全に外注化されていることも多く、安全にサンドボックス化されたエージェントを運用するためのインフラを構築できる内部人材がいない
- もちろん、セキュリティ上の懸念は現実のものだ — 本番データベースに対して制御なくコーディングエージェントを無差別に実行するのは危険である
- しかしサンドボックス化は難しい作業であり、それを安全に構築できるエンジニアリングチームが存在しないことが核心的な問題である
小規模企業の急成長
- レガシー制約のない中小企業はAIを素早く導入し、生産性を爆発的に高めている
- 一方にはMicrosoftのExcel向けCopilot（GeminiのGoogle Sheets統合も同様に出来が悪い）を試し、単純作業すらめちゃくちゃに処理されたため二度と触らない財務責任者たちがいる一方で、
- もう一方にはClaude Codeを習得した非技術職の幹部がPythonをローカルで実行している
- 30シートで構成された極めて複雑なExcel財務モデルを、Claude CodeでPythonに変換する作業を2〜3個のプロンプトだけでほぼ完了
- モデルがPythonに移行されれば、Claude Codeによってデータサイエンスチーム級の能力を確保できる
- モンテカルロシミュレーションの実行、外部データソースとの連携、Webダッシュボード構築、モデル（またはビジネス）の弱点分析支援などがすべて可能
- かつては小規模企業の従業員が大企業のリソースやチームをうらやんでいたが、
この環境では小規模チームが大企業よりはるかに高い効率を示し、生産性のトレンドが逆転している
未来の業務構造
- AIによる生産性向上はボトムアップで起きる
- 小規模チームが特定のプロセスにAI支援ワークフローを構築しようと試み、そのプロセスを隅々まで理解しているため良い結果を出す
- プロセス経験がまったくない外注ソフトウェアエンジニアリングチームとは対照的である
- 既存の**「デジタルトランスフォーメーション」**プロジェクトの大半とは正反対の様相
- 内部システム向けAPIを持つ企業は、はるかに多くのことを達成できる
- 従業員が接続してユーザーの代わりにクエリを実行できる読み取り専用データウェアハウスのようなものから、中核的なビジネスプロセスのAPI化まで、その範囲は広い
- セキュリティが制御されたVM環境でコードエージェントを実行する方式が現実的な代替案である
- 読み取り専用のレポーティングには適しているが、データ更新にはまだ限界がある
- レガシーなエンタープライズSaaS企業は、強力なロックイン状態にあるか、見方によっては極めて脆弱な状態にある
- 多くは「API-first」製品ではなく、既存APIは開発者向けに設計されているため、何千人もの従業員が非効率に呼び出す状況には最適化されていない
- しかし会社の単一の信頼できる情報源(source of truth)であるなら移行は非常に難しく、生産性向上のボトルネックになる
- 小規模企業はより新しく、API設計が優れた製品を使う傾向がある
- こうした新興SaaS製品はAPI中心設計で、AI統合に有利である
知識労働の新しい形
- プログラミング言語とシステムAPIにアクセスできるbashサンドボックスとエージェントフレームワークの組み合わせは、非技術者にとっても強力な生産性ツールとして機能する
- ユーザーはプロンプトを入力し、エージェントはAPIを通じて結果を生成する
- レポート作成、データ分析、文書生成など、ユーザーが求めるあらゆるものを望む形式で出力できるため、既存のオフィスアプリの大半を置き換え可能である
- ユーザーがプロンプトを与えると、エージェントがAPIに接続し、要求に応じて成果物を生成するという方式が知識労働の未来である
- この変化は小さなチームが大企業より速く競争優位を確保できる時代を開きつつある
- AI活用格差は実際に存在し、その速度はますます速くなっている
- 歴史上、小規模チームが千倍大きい企業をこれほど容易に上回れたことはない
4件のコメント
Hacker Newsの意見
ユーザーは2つの層に分けられると思う
1つはツールとしてAIを活用する人たちで、限界を認識したうえで、反復的だったり退屈だったりする作業を任せたり、要約を得るために使う
もう1つは思考そのものを外注する人たちで、主題への理解がほとんどなく、結果だけを求め、学ぶ意思もない
後者は、チャットボットがシニア開発者を置き換えられると信じるタイプだ
重要なのは短い納期だけで、顧客フィードバックは半年後にしか来ないので意味がない
今では最低限の労力だけで給料をもらいながら持ちこたえている
自分はドイツ語のリスニング練習用アプリをClaude CodeとElevenLabsで作ったが、教師も驚くほど効果的だった
コード学習には興味がなく、目的はドイツ語力の向上だった
つまり、単なるツール以上に対話型パートナーとして使うケースだ
AIをグリーンフィールド・プロジェクトとブラウンフィールド・プロジェクトで使うと、生産性の差が大きい
新しいプロジェクトの初日には1週間分の仕事をこなせるが、既存システムでは20%程度の改善にとどまる
結局、AIは「イノベーションのジレンマ」を急速に再現させることになる
問題は、AIが複雑なシステムを成熟させる段階でどれだけ役割を果たせるかだ
Hashicorp PackerのビルドファイルをAIでほぼ完成させたが、ローカルAIが大いに役立った
ただし、古いインフラでは予測不能性が大きく、LLMがむしろ壊してしまう可能性が高い
最初は速いが、後になるとアーキテクチャの限界が露呈する
過剰設計を減らすのにも役立つ
プロジェクトが200kトークンを超えると生産性は0になる
結局、組織は記憶に依存しないプロセスによって勝つ
ある役員がClaude Codeで30シートある複雑なExcel財務モデルをPythonに変換したという話を聞いて、ほとんど吐き気がした
数学と地球物理学の背景を持つ身としては、そうしたExcelモデル自体が悪夢だ
それでも、Pythonへの変換版が元より悪い可能性はそれほど高くないとは認める
間違ったモデリングを誰が見つけるのか。ほとんど誰もいない
LLMが作ったシミュレーションには、さらに検証手順が欠けている
初期には素早い実験用に使い、収益が大きくなると技術チームが正式なアプリへ移行させる
元のExcelは何年もかけて修正されてきたのに対し、変換版は偽物の複製にすぎない
AIで金融モデルを作る非専門家たちがいるというのが恐ろしく感じる
今はShadow AIの誕生期だ
2000年代のShadow ITのように、社員たちがこっそりClaude Codeをターミナルで動かしている
公式のCopilotがCSVすらまともに扱えないからだ
CISOたちは恐怖に震えているが、禁止すれば有能な社員たちが去っていくだろう
1980年代風に言えば、本当の革新は現場の従業員が自発的に作ったワークフローから生まれる
彼らがプロセスを最もよく知っているからだ
その後になってようやく、CIO向けのパッケージソフトウェアが後を追う
最近数か月でエージェントが実用的になってきて、みんなようやく使い始めたところだ
MCPやLangChain、ベクタDBのようなものは一時流行したが、今は静かだ
まだトレンドを語るには早すぎる
context7とplaywrightのMCPサーバーを使ってみたが、計画立案とフィードバックループに効果的だった
Microsoft CopilotのExcel統合はひどいものだ
30年間にわたって複雑なXMLフォーマットを作ってきたせいで、LLMには理解できない
だからうちの会社ではWord文書をMarkdownへ移行している。ある種の因果応報のようだ
だが、文書をAIフレンドリーにするためにかかる時間はますます増えている
CopilotはCSV変換の指示すら無視して失敗した
昔聞いた言葉がある。— 「これからは大企業が小企業に勝つのではなく、速い企業が遅い企業に勝つ」
今のAI時代には、この言葉がいっそう真実に思える。問題は、どうすれば速さを維持できるかだ
相変わらず叩かれているCopilot。MSはいつ改善するのだろうか。
下僕1、2、3として使っています
途中でCopilot批判が多いですが、実際には
Claude CodeがMicrosoft社内で急速に広がっている
国内の大企業にも間違いなく当てはまる状況だと思います。
会社が使えと言うから使うものの、ChatGPT/ClaudeはだめでCopilotしか使えない、というところが確実にありそうです。