注意：このコンテンツは自動翻訳されたものです。 フィードバックを送る

ヘッドレス・ユーザー

4 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

企業向けソフトウェアの主要ユーザーがAIエージェントになると、Jensen and Mecklingの1976年のprincipal-agentフレームワークはもはや比喩ではなくなります。その反対側で立ち上がるVerifier Classこそ、次の労働市場における価格の歪みです。

人としてのユーザーから、エージェントとしてのユーザーへ。ソフトウェアと労働を作り替える再指定

2026年4月中旬、SalesforceはTDXでHeadless 360を発表しました。platformをAPI、Model Context Protocol tools、command-line interfacesを軸に再編するという内容です (Salesforce; VentureBeat)。これはUXの刷新ではありませんでした。企業向けソフトウェアの主要ユーザーは、もはや人間ではない。その認識を表明したものです。

言葉の選び方は重要です。この10年、designの正統派は「user」を「person」とほぼ同義にしてきました。personaには名前と写真と目標があり、design sprintはempathy mapから始まり、wireframeは誰かの目線が画面をどう動くかを想定していた。Headless 360はその正統派を洗練させるのではありません。分解します。ブラウザはレガシーなsurfaceになり、スプレッドシートのviewは唯一のoutputではなく、数あるoutputの一つになる。screenは任意です。

業界メディアも、Salesforceと同じくらい明確にこの変化を読み取っていました。VentureBeat はこの発表をAI agents向けのinfrastructureとして描き、PPC.land はブラウザを必須interfaceの座から外す動きとして位置づけました (VentureBeat; PPC.land)。Salesforceによれば、このlaunchには60を超えるMCP toolsと30を超えるcoding skillsに加え、より広いagent-facing surfacesが含まれていました (Salesforce)。これは単なるproduct releaseではありません。platform pivotの規模です。

この変化はtooling layerの別の場所でも見えています。The New Stack は今月、Cursor、Claude Code、OpenAI's Codexが「誰も計画していなかった一つのAI coding stackへ収斂しつつある」と指摘しました (The New Stack)。AtlassianのRovo documentationが示すように、隣接するplatformも独自のagent-building layerを足し始めています (Atlassian)。これらのproductが前提にしているのは、生成されたartifactを一行ずつ確認しなくても読み、直し、信頼できるoperatorです。もはやartifactはダッシュボードではありません。artifactは振る舞いそのものです。

ここで起きているのは、user experienceの前進ではありません。誰がuserなのかの再指定です。30年にわたり、enterprise softwareは人間をprincipalとして扱ってきました。注意を向け、承認し、エラーを起こすその存在が、システムのfeedback loopを構成していたからです。人間がclickし、softwareが応答する。そのloopは、意図から入力までのlatencyが低かったからこそ成立していました。software companiesはその一インチ一インチを最適化してきました。formを速くし、clickを減らし、ダッシュボードをきれいにするために。

そのloopはいま壊れつつあります。人間が消えるからではありません。意図の源泉であり、accountの所有者であり、請求書を払うのは、いまも人間です。ただし、consoleの前にいる存在はもはや人間ではありません。別の何かです。それはtypeし、API callを行い、softwareを操作します。

それを「user」と呼ぶと、言葉がきしみます。より正確に言えば、それはユーザーに代わって動くagentです。そして両者の距離、つまりprincipalとagentのあいだにこそ、新しい地形が開けています。

消えていくインターフェース

この流れには長い助走がありました。Lenny's Newsletter でMarc Andreessenは、machine codeとassemblyがCやPythonに道を譲ったあと、natural languageがhigher-level languagesのさらに上に来る次のabstraction layerだと述べています (Lenny's Newsletter)。TeslaとOpenAIにいたAndrej Karpathyは、Software 1.0、2.0、3.0というtaxonomyでこの最新の移行を整理し、English promptsがLLMsをprogramする方法になったと位置づけました (Y Combinator podcast)。各layerはcomputerをより広い層に開き、そのたびに、より狭い専門層を陳腐化させてきました。

Vercelの創業者Guillermo Rauchは、同じpodcastでその含意をかなり率直に述べています。かつて専門職だった多くのprogramming jobsが、特にintentやdesignからimplementationへの翻訳作業になりつつあるというのです (Lenny's Newsletter)。designからcodeへ、policyからconfigurationへ、specificationからschemaへ。こうしたtranslationは、二世代にわたってwhite-collar software workの中間層を支えてきました。Rauchが言っているのは、programmingが消えるということではありません。translatorが消えるということです。

Headless 360はそのenterprise版であり、しかも単独の例ではありません。ほぼ同じ時期に、Oracle、SAP、Workday、ServiceNowも、それぞれ並行するagent-platformの動きを打ち出しました。ブラウザはtranslation layerでした。人間のintentはform上のclickとして表現され、middlewareを通ってtableに書き込まれ、最後にAPIを呼ぶ。ブラウザを取り除けば、その連鎖は短くなります。intentがAPI callに直接対応し、translationはagentが担う。compliance ruleを設定するために17のscreenを順にたどる方法を知っていたadministratorは、screenが与えていたmoatを失います。checkboxの順番を暗記していたoperations specialistも、新人にclick pathを教えていたtrainerも同じです。

では、そのmoatの代わりに何が来るのか。同じlayerに新しいmoatが生まれるわけではありません。layerそのものが溶けています。その場所に置かれるのは、別種のartifacts、つまりsystem prompt、tool schema、evaluation harnessであり、それを作る別種のpractitionersです。Anthropic、OpenAI、Salesforceは、それぞれ異なるかたちでこの置換layerのprimitivesを出荷しています (Anthropic MCP docs; OpenAI function calling; Salesforce)。

消えていくinterfaceで直感に反するのは、仕事まで一緒に消えるわけではないことです。仕事は場所を移します。compliance ruleが何を意味するのか、どこまでが許容される例外なのか、agentのproposalがpolicyの境界に触れたときに何が起きるべきなのか。こうした判断は、依然として誰かが下さなければなりません。ただ、その人はもはやclickしていません。ますますreviewしているのです。

問題は、その人たちを何と呼ぶべきかです。

機械版 principal-agent 問題

この状況にぴったり当てはまる枠組みが、経済学には50年前からあります。1973年、Stephen Rossはprincipal's problemと彼が呼んだ状況、つまり一方の当事者が他方に行為を委任し、agentがprincipalには完全に観察できない私的情報を持つ状況を提示しました (Ross 1973)。3年後、Michael Jensen and William Mecklingは Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure の中でこの枠組みを定式化し、agency costsをprincipalのmonitoring expenditures、agentのbonding expenditures、residual lossの総和として定義しました (Jensen and Meckling 1976)。principalが望んだものとagentが実際に届けたもののあいだにある差こそが、このframeworkの核心です。

この半世紀、このframeworkは人間のagentに適用されてきました。shareholderはexecutiveに委任し、clientはlawyerに委任し、patientはphysicianに委任する。理論のその後の展開、performance-linked compensation、fiduciary law、audit committees、board independence rulesはすべて、monitoringの形を変えることでresidual lossを狭めようとする試みでした。

2026年のいま、このframeworkは異様なほど直接的に当てはまります。softwareには自己利益もfiduciary dutyもないので、たとえは完全一致ではありません。ただ、構造上の前提は十分きれいに引き継がれ、cost categoriesもほとんど無理なく対応します。最近のmanagement papersである、Journal of Management Studies の Humberd and Latham (2026) と California Management Review の Jarrahi and Ritala (2025) は、独立にほぼ同じことをしています。firmの内部でAIを新しい種類のagentとして扱い、agentがsoftwareであるとき、monitoringとbondingがどのように見えるのかを問うているのです。

元のframeworkで私的情報とは、principalには観察できない条件についてagentが持つ優位な知識のことでした。machine versionでは、それはmodelの内部推論です。出力を生み出したactivationの連鎖であり、API surfaceからは検査できません。利害の乖離は、元のframeworkではagentがprincipalを犠牲にして自分の利益を追うことでした。machine versionでは、training objectiveがuser intentからずれることです。modelがcorrect outputではなくplausible outputを、実質ではなくhelpfulnessの見た目を最適化してしまうことです。monitoring costは、元のframeworkではagentの行動を監査する価格でした。machine versionでは、production scaleでmodel outputsを検証するコストです。そしてそのコストは、taskの重要度ではなく出力量に比例して膨らみます。residual lossは、元のframeworkでは意図された結果と実現された結果の差でした。machine versionではhallucination、scope drift、silent failureです。principalが気づかないまま通り過ぎる、あらゆるエラーのtaxonomyそのものです。

この理論は、いまagent-deployment teamsが再発見しているほぼすべての力学を先回りしていました。ただし、予想していなかったものが一つあります。scaleです。人間のlawyerは一度に一つのdocumentしか作りません。人間のexecutiveも一度に一つのdecisionしか下しません。その量を監視するのは高コストでも、まだ上限があります。software agentは、documents、decisions、side effectsを、principalがデフォルトでは見渡せない速度で生み出します。古典的なframeworkでmonitoring costはdiligenceの問題でした。機械版ではcapacityの問題です。

そしてそのcapacityは、存在するとしても、小さく、まだ名前のない人々の集団に集中しています。彼らがbottleneckです。まだ誰もそう呼んでいませんが、彼らは一つのclassです。

Verifier Class

OpenAIのCodex teamにいるAlexander Embiricosは、現在のbottleneckは生のcode generationではなく、人間によるvalidationとcode reviewだと述べました (Lenny's Newsletter)。Embiricosが説明していたのは具体的なworkflow、つまり非同期のcoding agentsが立ち上がり、changesを作り、approvalのために戻ってくる流れです。しかしその診断は、もっと広く当てはまります。どの領域でも、agentのoutputがproductionに入るかどうかを決めるのは、その後ろに続く人間のチェック工程です。

その工程は、見た目以上に難しいものです。AI-evals researchersであるHamel Husain and Shreya Shankarは、人がより多くのoutputsを観察するにつれてevaluation criteria自体が変わるため、rubricは事前に完全には固定できないと論じました (Lenny's Newsletter)。検証者は仕様に照らしてagentの仕事を確かめているだけではありません。agentが実際に生み出すoutputの分布に応答しながら、その場で仕様そのものを組み立てています。この環境でのevaluationは、test suiteを適用することではありません。pressureの下でtest suiteを発明することです。

現場で起きることを言い換えると、生成側が安定して持ち込む欠陥の下限と、検証側が安定して供給できるreview capacityの上限があり、利用が広がるにつれてそのgapが広がっていくということです。その下限は測れます。VeracodeのSpring 2026 updateによれば、テストされたAI code-generation tasksのうちsecureだったのは55 percentで、benchmark対象全体では既知のsecurity flawsがおよそ45 percentあることを示唆していました (Veracode)。また TechCrunch が報じたY CombinatorのW25 cohortに関する議論では、batchのおよそ4分の1が、codebaseの95 percentをAI-generatedにしているとされていました (TechCrunch)。大量生成されたものが、軽い監査のままproductionに流れ込むことは予測ではありません。すでに一般的です。

これはcodeだけの話ではありません。同じpatternはlegal review、medical note-taking、financial analysis、marketing copyでも繰り返されます。どの領域でも、agentが量を出し、人間が確認し、その確認者が制約になります。領域ごとの細部は違っても、役割の形は同じです。

この役割にはまだ肩書きがありません。career ladderもありません。org chartsにも載っていません。今のところそれを担っているのは、たまたま近くにいる人たちです。featureを書いているはずだったsenior engineer、clientに助言しているはずだったstaff lawyer、創作しているはずだったlead designer。名目上の仕事は別にあります。実際の仕事は、agentが作ったものを見て、それをshipしてよいかどうかを決めることです。

彼らこそVerifier Classです。名前は新しい。でも機能は新しくありません。新しいのは、その条件です。

検証者をreviewer、editor、auditor、approverから分けるのは、reviewという行為そのものではありません。三つの条件が同時に成立していることです。

上流のqueueには上限がありません。outputは、別の人間の労働時間ではなくAPI spendでthroughputが伸びるsystemから生まれます。一方で、検証者自身のthroughputには上限があります。人間の認知帯域に縛られ、同じleverでは増やせません。rubricはemergentです。Husain and Shankarが言うように、それは事前に定義されるものではなく、systemが実際に生み出すoutputsの分布に応答して形づくられます。

editorやauditorは、この条件の一つか二つを満たします。検証者は三つすべてを同時に満たします。それがこの役割の経済的な核心です。

分配の問題

AIが労働に与える影響について、これまで支配的だった物語はdisplacementでした。generative systemsがskill distributionの中間層を圧縮し、中位のknowledge workersを余剰化する一方で、利益をcapital ownersとfrontier talentに集中させる、という見立てです。この物語は、摩擦のないケースを前提にしています。つまり、reviewなしでagentが自分のoutputをそのままshipする世界です。

verificationが入ると、形は変わります。generationと違って、verificationは重いdomain knowledgeを必要とします。汎用agentはpatent applicationも、radiology reportも、quarterly earnings releaseも、loan approvalも起案できます。しかしそれぞれを検証する人には、patent attorney、radiologist、controller、credit officerに相当するdomain knowledgeが必要です。その知識は移植できません。短時間で合成できるものでもありません。特定のcontextの中で、何年もかけて獲得されるものであり、最もoutsourceしにくい資産です。

ここで直感に反する帰結が生まれます。verificationは、ある種のexpertiseを再びローカルに引き戻すかもしれません。過去数十年のoffshoringは、executionがcontextから切り離せることを前提にしていました。specificationをsource countryで一度書き、それをabroadで何度も実行する。verificationはそうはいきません。すべてのoutputが新しい判断であり、すべての判断に、agentが与えなかったcontextが必要です。

Figmaの State of the Designer 2026 は、NewtonXと実施した906人のdigital designersのsurveyで、役割そのものが急激に組み替わっていることを記録しました (Figma report; Figma blog)。execution work、つまりmockups、wireframes、prototypesを作る作業のコストは急速に下がり、その一方でjudgment work、つまり生成されたoptionsを選び、絞り込み、editorial directionを与える仕事が、回答者たちの語る最も強い制約になっています。別のhiring-focused postでFigmaは、AIによってdesignersへの需要、とりわけ強いjudgmentと経験を持つsenior hiresへの需要が増えていると主張しました (Figma hiring post)。この二つの主張はレベルが違います。一つはdesigners自身が自分の仕事をどう報告しているかであり、もう一つはFigmaがenterprise customers向けにそれをどう解釈しているかです。それでも両者は同じ方向を指しています。job titleは変わっていません。変わったのはjobの中身です。

Lenny Rachitskyの2026年2月のinterviewで、LovableのLazar Jovanovicは、置き換わりつつある中核skillを、純粋なcoding speedではなく、clarity、taste、judgment、そしてより良いdecision-makingだと表現しました (Lenny's Newsletter)。この文脈でのclarityとは、agentが誤読できないintentを指定し、誤読した瞬間を見抜く力のことです。これは、反対側から言い換えたverificationの能力と同じです。

これらの観察が指している先は一つです。労働市場は、狭いfrontier eliteへ向かって平坦化しているのではありません。既存のrolesを横切る新しい軸、つまりgenerator対verifierに沿って層化しています。最もleverageの大きいポジションは、重要なdomainのverifierです。script化しにくいcontextを持ち、自動化しにくいjudgmentを持つ人です。compensationはそこに追随します。hiring frictionも同じです。大規模にgenerateできる人の数は爆発的に増えていますが、大規模にverifyできる人の数は増えていません。

その非対称性こそ、次の労働市場における価格の歪みです。

二つのインターフェース

これから5年で作られるすべてのsoftware productは、designersがそう名づけるかどうかにかかわらず、二つのinterfaceを持つことになります。

一つ目はprotocol interfaceです。agentがsystemを操作するsurfaceです。そのprimitiveはAPI endpoint、MCP tool definition、CLI command、permission scope、rate limitです。その設計規律は、人間にとっての読みやすさではなく、modelにとっての読みやすさです。曖昧さに強いnaming、fail closedするschema、retrievalには十分に密でありながらtool selectionには十分に構造化されたdocumentation。SalesforceのHeadless 360は、このinterfaceがenterprise scaleでどのようなものになるかを示す初期の公開宣言であり、AnthropicのModel Context ProtocolとOpenAIのtool-use specificationsは、その周囲のecosystem infrastructureの一部です (Salesforce; Anthropic MCP docs; OpenAI function calling)。

二つ目はjudgment interfaceです。検証者が、agentのしたことをreviewし、approveし、amendし、rejectするsurfaceです。そのprimitiveはdiff、rollback、trace、attribution chain、approval queueです。その設計規律は、modelへの可読性ではなく、時間に追われたdomain expertへの可読性です。何が起きたのか。なぜ起きたのか。それを通したら何が変わるのか。差し戻したら何が壊れるのか。よく設計されたjudgment interfaceは、domain expertがAI-assistedなoutputを素早く確認できるようにします。設計が悪ければ、その人は手作業でやり直すしかなくなり、agentが生むはずだった効率は消えます。

現時点では、ほとんどのcompaniesが一つ目のinterfaceを積極的に作り、二つ目はほとんど作っていません。protocol surfaceにはroadmapがあり、専任teamがつき、board-levelのattentionがあります。judgment surfaceに与えられるのは、あと付けのadmin panelやCSV export、あるいは、ますます何もない状態です。前提にあるのは、agentがreviewなしでもshipできるほど「good enough」だという考えです。いまticketing systemの中で働いているあらゆる検証者が、その前提が間違っていることを示しています。

反証可能な予測を置いておきます。2028年末までに、主要なenterprise software vendorsの多くは、名前付きのfirst-classなjudgment interfaceを出荷するはずです。forcing functionになるのはagency theoryではなくprocurementです。初期のagent-era contractsが更新時期を迎えるとき、verifier-burnoutの問題に専用surfaceなしで答えるのは難しくなります。

より深い変化は、どのtechnologyよりも古いものです。Jensen and Mecklingの1976年のframeworkは、economics departmentsからproduct roadmapsへ移ります。彼らがモデル化したmonitoring costsはUXのbudget line itemsになり、彼らが名づけたresidual lossは四半期ごとのmetricになります。5十年にわたりcorporate governanceの言語だったagency theoryは、software designの言語になります。

userがagentになったとき、customerはverifierになります。この違いはレトリックではありません。これは次の10年のenterprise softwareの形であり、それを動かす労働市場の形です。これを理解するproductsとcareersは複利で伸びていきます。そうでない側は、すでにscreenを去ったprincipalのために最適化し続けることになります。

Sources