冒頭は記事のために生成したイメージ映像です。実機、実在施設、観測データを示すものではありません。
会社には、長くいる人にしか分からない道がある。
この申請は古い画面から行う。障害が出たら、まずあの人へ聞く。仕様書は共有folderにあるが、最後の変更だけSlackに残っている。三つある手順のうち、本当に使うのは二番目だ。
人間は、その散らかった道を「経験」で歩いてきた。
では、AI Agentへ同じ仕事を渡したらどうなるだろう。
AIは疲れない。速い。大量の資料も読める。
けれど、古い正解と新しい正解が並んでいれば、両方を真面目に読む。teamごとに違う作法があれば、どれを真似るか迷う。ownerが書かれていなければ、確認先を知らない。
AI Agentが賢くなるほど、会社の能力だけでなく、会社の「散らかり」まで拡大して見える。
Spotifyでは、コードを書くことがボトルネックではなくなった
Spotifyは2026年6月、社内のAI coding活用について興味深い数字を公開した。
同社の自己報告によれば、engineerの99％超が毎週AI coding toolを使い、94％が生産性向上を感じ、pull requestの頻度は76％増えた。
ただし、PRが増えたことは、価値や品質が76％上がったことを意味しない。
実際、Spotifyが次に直面したのは、増えたPRを誰が確認し、何を自動mergeし、どこへ人間の判断を残すかという問題だった。
コード生成が速くなると、制約は別の場所へ移る。
書けるかどうかから、何を作るか。出してよいか。組織として受け止められるかへ。
PR頻度増加は価値・品質の直接指標ではないとSpotify自身が明記(本文引用、自己報告データ)。 図を大きく開く
賢いAgentへ、散らかった倉庫を渡しても速くはならない
Spotifyのbackground coding agent「Honk」は、Claudeをそのまま置いただけではない。
Agent SDKを同社のharnessで包み、Kubernetes上で実行し、信頼したtoolと複数OSのCIへ接続している。人間側はFleet Managementで対象、進捗、PR、要確認箇所を見る。
さらに重要なのが、Agentへ渡す仕事場の形だ。
Spotifyは、技術と設計patternが揃ったcodebaseでは、Agentが参照できる良い見本が多く、性能が上がると説明する。反対に、teamごとの違いが大きいfragmented codebaseでは、性能が測定可能な形で悪かったという。
別のdataset migration事例では、この差がもっと具体的に出ている。
書き方のvariationが大きいframeworkでは、あらゆる例外を一つのpromptへ詰め込もうとして巨大化し、当時は自動migrationの対象から外した。一方、比較的標準化された二つのframeworkでは、field mappingをtableで明示したcontext fileへ直すことで、多くのrepositoryで安定した結果を得た。
ここから見えるのは、prompt技術の限界ではない。
仕事場が整理されていない時、promptが組織の散らかりを全部背負い始める。
Spotifyの移行事例に基づく対比。最後の項目は前の工程の「次」ではなく、別条件の結果。独立した因果実験ではない。 図を大きく開く
AI-readyな会社は、AIをたくさん契約した会社ではない
Google CloudのDORA researchも、AIを組織の「amplifier」と表現している。
良いplatform、明確なworkflow、強いtestingがある組織では、AIの効果は大きくなる。逆に、作る工程だけ速くしても、security review、test、deploy、意思決定が詰まっていれば、速さはdownstream disorderとして溜まる。
これはsoftware開発だけの話ではない。
営業資料の最新templateはどれか。契約条件の正本はどこか。顧客へ約束してよい範囲は何か。記事の事実と意見を誰が確認するか。退職した人の個人folderにしかない判断はないか。
人間が勘と関係性で埋めていた隙間は、Agentへ渡した瞬間に仕様になる。
AI-readyとは、あらゆる仕事をmanualへ書き起こすことでもない。
目的、owner、現在の正本、標準の通り道、成功条件、例外時の戻り先が、人間とAgentの両方から読めること。
この基礎がある会社は、新しいmodelへ替えても立ち上がりが早い。基礎がなければ、modelが変わるたびに同じ暗黙知を長いpromptで教え直す。
標準化は、創造性を消すことではない
「標準化」という言葉には、少し息苦しい響きがある。
全員が同じtoolを使い、同じ方法で考え、例外を許さない。それでは、新しい発想まで痩せてしまう。
必要なのは、すべてを一本の道へ押し込むことではない。
何度も通る仕事には、安全で分かりやすいgolden pathを作る。別の道を選ぶなら、理由、owner、検証方法を残す。古い道は閉じるか、historicalだと明示する。
Spotifyも、Backstageのcatalog、推奨状態を示すgolden state、自己評価のSoundcheck、static analysis、lintを組み合わせている。Agentが外れたpatternを使うと、実行中にfeedbackが返り、修正できる。
分厚い規則を最初に全部読ませるのではなく、正しい道を歩きやすくし、外れた時に早く知らせる。
これは人間にとっても、Agentにとっても働きやすい。
まず、一番混む一本の道だけ整える
AI導入のために、全社systemを作り直す必要はない。
DORAも、最初から完全なplatformを目指すのではなく、最も頻繁なworkflowのminimum viable platformから始めるよう勧めている。
たとえば、次の順番でよい。
一つの仕事を選ぶ。 問い合わせ返信、記事公開、release、請求確認など、繰り返しが多いもの。
正本を一つ決める。 最新版、owner、更新日、古い資料との違いを明示する。
成功条件を機械で確認する。 test、schema、lint、checklist、差分監査へ落とせるものを先に落とす。
例外を隠さない。 通常経路から外れる条件と、人間へ戻す場所を書く。
AIの速さではなく、仕事全体を見る。 作成数だけでなく、手戻り、review待ち、失敗、利用者への価値を測る。
Agentへ長い注意書きを足す前に、同じ間違いを誘う古い文書を片づける。
modelを強くする前に、正解へ辿り着ける標識を立てる。
AIは、組織の鏡になる
AIがうまく働かない時、modelが足りないこともある。
けれど、modelを替えても同じ場所で迷うなら、問題は仕事場の方にあるかもしれない。
正本が複数ある。ownerがいない。成功の定義が人によって違う。作る速さにreviewが追いつかない。失敗から戻る道がない。
AI Agentは、そうした組織の曖昧さを、容赦なく実行結果へ変える。
少し怖い鏡だ。
でも、同時に役に立つ。
Agentが迷った場所は、人間も経験と我慢で乗り越えてきた場所かもしれない。
そこへ標識を立て、道をつなぎ、確認できる形へ直せば、次のAIだけでなく、次に入る人も働きやすくなる。
AI時代に強い会社は、最も賢いmodelを最初に契約した会社ではない。
人間の知恵と仕事の通り道を、失わず、読める形にし続けられる会社だ。
主な参考資料
注記：Spotifyの利用率、生産性認識、PR頻度、Agent性能に関する記述はSpotify自身の公開事例に基づく。PR本数はproduct価値や品質の直接指標ではなく、fragmented codebaseとの性能差について公開記事は詳細な測定方法・数値を示していない。
