あなたはたった今、100万人のダメ社員を雇った
企業が無制限のAgentとtoken予算を全社員に配れば、悪いフローは秒単位で複製されます。次に学ぶべきはモデルの追加購入ではなく、このデジタル部隊のマネジメントです。
- Hebbia創業者のGeorge Sivulkaが長文を投稿。企業が全社員にほぼ無制限のAgentとtoken予算を与えた結果、ボトルネックは「モデルの性能」から「このデジタル部隊をマネジメントできるか」へと移った。
- 主軸は19世紀の鉄道にたとえた比喩——線路(能力)が先に敷かれ、運行管理(マネジメント)は後から追いつく。Agentは曖昧なタスクと悪いフローを秒単位で増幅する。
- 7つの対照——tokenの積み増し↔人海戦術、循環(loop)↔会議のための会議、tokenの浪費↔人員の肥大化、100Xコンテキスト↔10倍エンジニア、コンテキストの抱え込み↔保身、Evals↔OKR、トランスフォーメーション企業↔次世代の産業ポジション。
- スケールを支えるのはevals(再現可能な検収基準)。コーディングの領域が先に立ち上がったのは、結果の合否を自動判定できるからだ。
- ビジネス面の結論は、「AI変革企業」が既存企業の差別化されたプロセスをAgentに落とし込む、という賭けに置かれている。本文中の図表の多くには外挿値やillustrative(例示)の注記があり、マネジメントのフレームワークとして読むべきで、監査済みのレポートとして読んではいけない。
立場についての注記:筆者はHebbiaの創業者兼CEO。同社は金融・法務などのチームでAIを実務フローに組み込む支援をしており、事業の形は本文で言う「AI変革」に近い。後半では変革企業がNeofirmより一桁大きくなると書かれており、これは筆者自身のビジネスポジションと同じ方向を向いている。立場を持つ実務家による長文として読むべきで、中立的な市場調査ではない。
帳簿上は生産性、現場では止まらない部隊
企業は「生産性」を買っているつもりです——モデルの利用枠を契約し、全社員にアシスタントを開放し、さらに自分でツールを叩けるAgentを組み込む。しかし実際に起きているのは別のことです。ほぼ無制限のデジタル人員枠と予算が、タスクを言語化するのが一番苦手な人も含めて、社員一人ひとりの手に渡っているのです。タスクが曖昧なままだと、Agentは手を止めて人に聞くことはせず、ただ動き続け、tokenを消費し続けます。以前は悪いフローも人の手を介してゆっくり広がっていましたが、今は秒単位で複製されます。
一言で言えば、あなたが雇ったのは「間違えても無限に残業してくれる」社員です。
例示(原文の事例ではなく、自社の現場と照らし合わせるためのもの)
「このクライアントフォルダを整理して、更新しておいて」
- 成果物が不明確:議事録が欲しいのか、リスク一覧が欲しいのか、それとも顧客に送れるメールが欲しいのか?
- 範囲が不明確:どの3つのファイルを対象とし、どのチャット履歴は無視していいのか?
- 停止条件が不明確:どこまでやれば「十分」なのか、どんな場合に手を止めて人に聞くべきなのか?
- 検収基準が不明確:誰がどんな基準で「合格」と言うのか?
同じ曖昧な指示でも、人の時代とAgentの時代とでは「壊れ方」が違います。下の2つのタブをクリックして対照を見てください(見出しは常に表示されます)。
人も詰まるが、壊れ方は遅い
同僚がこの指示を受け取ったら、まず「誰に送るの?数字は入れる?明日の会議までに必要?」と聞き返すのが普通です。それでもはっきりしなければ短い打ち合わせを開き、長くても1日遅れる程度。無駄になるのはカレンダーと忍耐であって、請求額が勝手に雪だるま式に増えることはありません。
Agentは文句を言わないが、無限にリトライする
同じ指示をClaude Code / Copilot / 任意のharnessに投げ込むと、アウトラインを作り、構成を直し、もう一度自己評価し、また自分を呼び出して直す、というプロセスが始まります。停止条件がなければ「終わり」もありません。失敗していても、完璧なレイアウトで自信満々に提出してきます。tokenはモデルの読み書き課金の基本単位で、AIが作業する際に消費する文字数の枠と考えればおおむね近く、この枠が請求額の上で勝手に膨らんでいきます。
上の「Agent」側を分解すると、現場は大体こういう形になります(悪循環の一例を示すもので、監査済みデータではありません)。
曖昧なタスクを受け取る
「クライアントフォルダを整理して」には成果物の定義も、「完了」の姿もない。
まず一見完成しているものを書く
アウトライン、要約、表がひと通り揃い、体裁は綺麗だが、合格かどうかは分からない。
自己評価で不合格、もう一周回す
Agentが自分を呼び出して自分を直す——素材を追加し、構成を変え、検索をやり直す。人が介入しない限り、循環は止まらない。
請求額は上がるが、ビジネス上の結果はほぼ動かない
tokenは消費され続けるが、実際に使える成果物は依然として足りない。これが「tokenで、さらにtokenを使い続ける権利を買う」ということだ。
原文と照らし合わせると:loopは「タスクを明確に書ける人がほとんどいない」ことへの応急処置であり、力任せの全探索がシステムの唯一の前進手段になっている。
データ側の症状もこのストーリーと符合します。以下の2枚の図は原文からの引用です——1人当たりのAI支出は上昇を続け、AIを高強度で導入したグループでも人員は縮小していません。読み方としては「金も人も増えているからといって、AIが信頼できる形で成果を出しているとは限らない」であって、「AIが雇用を生み出した」と直接読んではいけません。
問題は「モデルが賢いかどうか」ではなく、企業が無制限の実行力を配る際に、成果物・境界・停止条件・検収基準を同時に配っていないことにあります。この4つがなければ、Agentは曖昧なタスクを大規模な手戻りに変えるだけです。
能力が先に到着すると、旧来の運行管理は事故を起こす
蒸気機関は「走るのが遅い」という問題を解決しました。次の瞬間、問題は「誰が調整し、誰が責任を持ち、衝突したらどうするか」に変わりました。Agentは「人手不足」を解決しました。次の瞬間、問題は「誰がタスクを定義し、誰が検収し、間違えたらどう止めるか」に変わります。
1830年代、米国の鉄道の総延長はおよそ120倍に増えました。輸送能力が爆発的に伸びた後の1841年10月5日、マサチューセッツ州のWestern Railroadで、調整の失敗により2本の列車が衝突し死者を出す事故が起きました。蒸気機関はすでに十分速かったのですが、車掌1人の判断だけでは、どんどん広がっていくネットワークを管理しきれなかったのです。
その後、鉄道会社は地区マネージャー、文書化された職務、報告系統を整備しました。現代の大企業の管理構造の大きな部分は、「能力が拡大した後、誰が調整するのか」という問いから生まれたものです。鉄道はこうして当時最大級の産業へと成長し、ピーク時には米国株式市場の時価総額の約6割を占めるまでになりました。
Agentをめぐる今回の局面も、Sivulkaは構造は同じだと考えています。モデルとツールが新しい線路である一方、企業はまだ「単一区間」レベルの運行管理を続けています。さらに悪いことに、タスクを言語化するのが最も苦手な人を含む全社員に、ほぼ無制限のデジタル人員枠と予算が配られてしまっています。
人もAgentも、同じ組織の病で崩れる
7つの対照はただの小話ではありません。同じ病がtokenの帳簿に投影されたものです。タスクを言語化できなければloopで力任せに押し通し、コストは空回りして膨らみ、レバレッジの高いコンテキストは一部の人の手に握られたまま外に出てこず、検収基準がなければスケールする勇気も出ない。最後には、「あなたの会社をシステムに落とし込む」ことを生業にする人が現れます。
tokenを消費しても「使いこなせない」は解決しない
「tokenをたくさん使えば勝てる」という熱狂は、原文によればわずか1カ月でライフサイクルを終えました。本当の問題は使い方にあります。Sivulkaの見立てでは、AIにまともなコンテキストを与えられる社員はおそらく全体の1%程度で、フローを明確に言語化でき、汚染されたコンテキストウィンドウにも耐えられます。残り99%の人はAgentの足場を手にしても、主に生み出すのは「循環」です。
Claude Code、Copilot、KarpathyのAutoresearch、そしてさまざまなharnessにおける循環は、原文では応急処置としてしばしば描かれています。人がタスクを明確に言語化しなかったため、システムは力任せのリトライで前に進むしかない。Agentが自分を呼び出し続けて自分を直す様子は自律性が高いように見えますが、より多い原因は、上流にクリーンな目標・境界・停止条件が欠けていることです。結果として、あなたはtokenを使って「さらにtokenを使い続ける権利」を買っていることになります。
空回りは自己増殖する
筆者は多くの企業の管理の現状を辛辣に描いています。大半の人は本当の意味でビジネスを動かしているわけではなく、各階層でハンコを押しては、存在するために存在する機械を養うためにさらに人を雇っているだけだ、というのです。これもloopingの一種です。輪を切り落とす方が、輪を加えるより効果的な場合があります。筆者はElonがXの人員を約80%削減した後も会社が回り続けた例や、プライベートエクイティのオペレーティングパートナーが冗長性を削ることを生業にしているという常識を挙げています。これをAIに当てはめると——
80%の社員がほとんど成果を生まないのと同じように、今日の80%のtokenもほとんど成果を生んでいません。これは主張の強い比喩であり、業界全体を対象とした監査済みの計量ではありません。
本当に価値があるのは100Xコンテキスト。だが人は必ずしも差し出したがらない
従来型ソフトウェアの約束は、一度書けば低コストでずっと動き続け、ほとんど見張る必要がない、というものでした。AIは「何でもできる」を手に入れた代わりに、「1つのことだけを安定して正しくやり続けるのが難しい」という代償も背負いました。tokenを社員として扱った途端、多くのスローガンにひびが入ります。
- より正確——ただしプロンプトが正しいときに限る
- より速い——ただし100回リトライすれば速さの意味は失われる
- 社内政治とは無縁——だがtoken支出の帝国を築くことはある
- 離職しない——だが新しいモデルや新しいセッションの間で「死ぬ」
- 信頼できる——なのに完璧な体裁で自信満々に間違えることが多い
「100Xコンテキスト」とは何か(高レバレッジなコンテキスト。以下は例示)
- 重要なのは「ハードディスクを丸ごとプロンプトに詰め込む」ことではありません。本当に効くのは、その後の消費量を桁違いに減らせる、ごく短いルールと事例であることが多いです。
- 例えば:契約審査で見るべきリスクポイントが8つに絞られている、絶対に譲れない条項がどれか、過去に「合格」した3件のサンプルがどんな形か、どんな場合に必ず手を止めて弁護士に相談すべきか、といったことです。
- これがあれば、Agentは何十回もの試行錯誤を省けます。なければ、循環で当てずっぽうを続けることになります。
AIが人に確実に勝る点は、拡張スピードです。採用・オンボーディング・離職はどれも非常に高コストですが、tokenを増やすのはほぼ瞬時にできます。だからこそマネジメントを誤ると非常に高くつき、だからこそ100Xコンテキストを見つけて増幅させる必要があるのです。平均すれば人の方がtokenより安いかもしれませんが、規模がかかれば、良質なtokenの方が安くなります。マネジメントとは、この両極の間で交換レートを決める行為です。
企業内部にはもう一つ、次第に重みを増していく政治的な問題があります。社員は自分だけのやり方をAIに教えたがりません。これらのシステムが単に「自分の効率を上げてくれるもの」ではないと気づき始めているからです。原文はMetaの例を挙げています——持株を持つ社員でさえ、自分たちのコンテキストを学習データとして会社が使うことに強く反発したといいます。部族的な知識は何世紀もの間、飯の種であり続けてきました。AIは、労働者に一度きりで全てを差し出すことを求める初めての技術です。100Xコンテキストを握っている人ほど、それを差し出す動機は最も乏しいのです。
スケールできるのは、検収基準と、会社をシステムに落とし込むこと
ここまでは「タスクをどう明確に言語化するか、循環がなぜコストを食うのか」を扱ってきました。このセクションではもう半分の問題を扱います——たまたま一度正しくできたとして、毎回正しいとどうやって分かるのか?再現可能な検収基準(evals)がなければ、Agentはスケールできません。しかも検収基準だけでは不十分で、あなたの会社が実際にどう仕事を回しているかという細かなニュアンスを、システムが実行できるルールに落とし込む必要があります。Sivulkaはこの後半のビジネスを「AI変革」と呼んでいます。
なぜコーディングが先に立ち上がったのか——「合格/不合格」が内蔵されているから
tokenの部隊を管理するのも人を管理するのも、最善の方法は同じです——先に「良い」とは何かを定義すること。今のところ、社内政治の泥沼を抜け出してパイそのものを大きくできている、ほぼ唯一のAI領域がコーディングです。メカニズムは明快です——コードは動くか動かないか、テストは緑か赤か。筆者は「今日のAI収益の圧倒的多数をコーディングが占めている」ことの理由をここに求めています。
「クライアントフォルダの整理」を「CSVをエクスポートするスクリプトを書く」に置き換えてみましょう(例示)。成果物は明確(ファイル)、停止条件は明確(スクリプトがエラーなく終了する)、検収基準も明確(CSVを開いて列が揃っている)。Agentが途中で循環しても、客観的な終点があります。この終点がない仕事は、人が画面に張り付いて見張るしかなく、スケールは即座に行き詰まります。
- 事前に書いておく——何が正解で、何が漏れで、どんな場合に必ず止めるか
- Agentの成果物を自動または半自動で再チェックできる
- 間違えたら再生・検証してルールを直せる。運任せではない
- 同じ基準を100回目のタスクにもそのまま複製できる
- 毎回、人が「まあ良さそう」と言うかどうかに頼る
- 綺麗な体裁が事実の誤りを覆い隠す
- 新しい担当者や新しいモデルに変わるたびに品質がぶれる
- 量を増やす勇気が持てず、結局Agentを見張る人を増やすしかなくなる
コード以外の例を一つ:契約リスクの要約(例示、原文の事例ではない)
「このサプライヤー契約に落とし穴がないか見てほしい」
- evalがない場合:Agentは読みやすい文章を返してきますが、法務担当は結局最初から読み直すことになり、時間はさほど節約できず、レッドラインを見落とす可能性すらあります。
- evalがある場合:あらかじめ「自動更新/責任上限/データの越境移転/解約可能期間」の4項目を必ずカバーすると決めておきます。各項目について該当条項の場所を示させ、1項目でも欠けたら不合格とし、原文の条文を引用させて空虚な言葉を禁止します。
- この基準があって初めて、Agentの出力は「雑談」から「業務フローに組み込める成果物」に変わります。そこまでいって初めて、50人の営業担当に使わせるスケールの話ができます。
だからこそ原文はこう言います——業種横断的なシーンで量を増やすには、誰かが先にその業務に対応するevalを作らなければならない、と。具体的な検収基準セットは、全社員にプロンプトの書き方を教えることや、チャット画面を一つ配ることよりもはるかに重要です。マネジメントの本質とは、曖昧な人間の手順を、できる限り再現可能にチェックできる基準へと書き換えることにあります。会社のevalセットは、最も価値ある資産の一つになるでしょう。汎用的なevalや汎用的なAgentは差別化を生みません。各社独自の判断基準にこそ、堀があるのです。
モデルの調達だけでは足りない——会社を「Agentに落とし込む」必要がある
企業が基盤モデルのコミットメント、アプリケーション層、社内自社開発に投資してきてすでに数年が経ちます。Sivulkaは、こうした支出全体が一つの耳の痛い事実を覆い隠していると考えています——AIをプロダクション級の信頼性で安定稼働させられている企業は、まだどこにもない、という事実です。お金は「使えるモデル」には使われていても、「自分たちのビジネスにおいて何が正しいと言えるか」には使われていないのです。
シリコンバレーがこれに対して打っている賭けの一つは、「今の会社にはこれをやり切れない」という前提に立つものです。そこでNeofirm、つまりAIネイティブなサービス企業に資金を投じ、ナレッジエコノミーにおける約21兆ドル規模のサービス支出を狙いにいく。過去のしがらみを持たないAIサービス部隊をゼロから作り、従来の法律事務所・コンサルティング・アウトソーシングの仕事を直接奪おうというわけです。
Neofirmの賭け方
ゼロからAIネイティブなサービス企業を作り、Agent部隊で従来の人的サービスを置き換え、既存のサービス予算を直接奪いにいきます。
変革企業の賭け方
最も価値あるプロセスは今も既存企業の中にあります。売るのは、その企業が実際のプロセスを発見し、evalを書き、tokenコストを圧縮し、既存システムに接続して、Agentを「その会社のルール」通りに動かす手助けです。
Sivulkaは後者に賭けており、「AI変革企業はどんなNeofirmよりも一桁大きくなる」と書いています。その理由は具体的です——既存企業の手元にはすでに稼げている差別化されたプロセスがあり、加えて既存の顧客とチャネルもある。足りないのは、それらをAgentが実行・検収できるシステムへとコード化することだけです。Neofirmは外部から圧力をかけることはできますが、最大の資産は依然として既存企業(incumbent)の内部にあります。
「会社をシステムに落とし込む」とは具体的に何をすることか(原文の変革論をもとにした例示であり、筆者のチェックリストをそのまま引用したものではない)
実際のプロセスを掘り起こす。PPT上のプロセスではなく
誰が本当に決裁するのか、例外はどう処理するのか、どのステップでいつも手戻りが起きるのか。これらは大抵、古参社員の頭の中にあり、制度マニュアルには書かれていない。
コンテキスト+権限+作業プロトコルとして書き起こす
Agentがどの顧客データを読めるか、何に触れてはいけないか、どこまで進んだら必ず手を止めて人を呼ぶか。
専用のevalsを組み込む
タスクの種類ごとに「合格例/失敗例/自動チェック項目」を用意し、毎回上司の気分で検収するのをやめる。
既存システムに接続し、継続的に改善する
CRM、ファイルサーバー、チケットシステム、権限システムを接続する。失敗事例をフィードバックし、ルールを更新する。これは一度プラグインを入れて終わりではなく、継続的なビジネスだ。
一見すると一度きりのプロジェクトのようですが、ここにはジェヴォンズのパラドックスが働きます——ユースケースを1つ実装すると、しばしば新たに10個が出てきます。能力が安くなるほど利用量は増え、変革にかかる労力はむしろ上がっていきます。だから「変革」は長期的な運用業務になり、鍵を渡して立ち去るような仕事にはなりません。AI時代の変革は、オントロジーのモデリング、カスタムソフトウェア、たまに上手く書けたプロンプトだけでは終わりません。本当に骨が折れるのは、evalであり、tokenの最小化であり、ある事業をプログラム可能なレベルまで理解し尽くすことです。
スケールを支える土台は2つ。evalsは「正しいかどうか」を再現可能に判定できるようにし、変革の作業はあなたの会社の実際のルールをAgentに落とし込みます。どちらか一方でも欠ければ、「全社員がチャット画面を持っているのに、誰も量を増やす勇気がない」という状態で足踏みするしかありません。
そろそろマネジメントの出番
AIブームの各フェーズには、それぞれの決まり文句がありました——ゴールドラッシュでツルハシを売る→インフラが整備された、Service-as-a-Software→Neofirmが次々に生まれた。原文の締めくくりは実に率直です。インフラはもう十分、サービスももう十分。今やるべきは、列車を時間通りに走らせることだ。企業の現場に入り込み、100Xコンテキストを見つけ、本当に効いている循環を記録し、著しく浪費されている知性の向け先を作り直すこと——それが今なすべき仕事です。
人間はつい先ほど、ソフトウェアより安く見え始めたばかりだ。
それでも、両者それぞれに何をすべきか教える人間は、まだ必要だ。
無制限のAgentがまず増幅するのは、会社がもともと言語化できていなかったマネジメントの問題だ
Hebbia創業者George Sivulka——全社員がほぼ無制限のデジタル人員枠を手にした今、次に学ぶべきはモデルの追加購入ではなく、この部隊のマネジメントだ。
↓ 1ページで読み切る・動く図が1枚あります
企業はモデルの利用枠を契約し、全社員にアシスタントとAgentを開放し、生産性を買ったつもりでいる。だが実際に配っているのは、ほぼ無制限の実行力と予算であり、タスクを言語化するのが一番苦手な人にもそれが渡っている。
人手の時代にはできなかった「秒単位の複製」が突然可能になった
✘ 止められない:成果物・境界・停止条件・検収基準がないとき、Agentは自分から人に聞きにいかない
悪いフローは以前、人の手を介してゆっくり広がっていたが、今は秒単位で複製される
主軸となる比喩は19世紀の鉄道——線路(能力)が先に敷かれ、運行管理(マネジメント)は後から追いつく。Agentは新しい線路であり、企業はまだ「単一区間」レベルの運行管理をしているのに、一人ひとりに無制限のデジタル人員枠を配ってしまっている。
曖昧な指示は聞き返され、会議になり、1日遅れる。無駄になるのはカレンダーと忍耐で、請求額は勝手には膨らまない。
「クライアントフォルダを整理して」→ まず誰に送るか、数字が必要かを確認
同じ指示が循環を引き起こす——アウトライン作成、自己評価、また自分を修正。「完了」がなく、tokenが勝手に膨らんでいく。
loop = tokenで「さらにtokenを使い続ける権利」を買うこと
7つの対照は3つのことに集約できる——タスク定義、実行の可視化、知識とインセンティブ。モデルが強くなっても、この3つの層は自動的には埋まらない。
小互(シャオフー)が曖昧なタスクを一つAgentプールに投げ込む——4つのものがなければ、循環は止まらない。
スケールを可能にするのは「Agentをさらに増やす」ことではなく、再現可能な検収基準(evals)+会社の実際のルールをシステムに落とし込むことだ。コーディングの領域が先に立ち上がったのは、合否を自動判定できるからだ。
会社リストはない。
締め切りの基準もない。
予算の上限もない。
タスク分解
ウェブ検索
レポート作成
自己チェック
もう一周
答えはまだ分からない
誰も「完了」を定義していないからだ。
- 対象を8社に指定
- 価格には出典と日付を添付
- 結論には根拠を2つ添付
- 20ドルを超えたら停止
目標が明確になった途端、循環はエラー修正を始め、空回りしなくなった。
マネジメントの失敗も複製する
モデルは誰でも買える。
何が「良い」か、何を必ず止めるべきかは、会社自身にしか書けない。
本文中のコスト図の多くは外挿値や例示値を含んでおり、一般的な実測値として扱ってはいけない。
終ひとつの能力だ


