はじめに
どうも。鳩胸になりたい文鳥です。
AI時代の手抜きは「アウトプット出しすぎ」らしい
先日のポストで流れてきた動画が気になりました。
ShopifyのTobi Lütke氏が、ポッドキャストでこんな感じのことを言っています。
昔の手抜き → アウトプットを出さない人
今の手抜き → アウトプットを出しすぎて、周りの確認作業を増やす人
元ネタはShane Parrishのポッドキャスト「The Knowledge Project」の2026年9月15日公開の回です。
要約記事は多分これ：Shopify CEO Warns AI 'Slop Grenades' Shift Work To Coworkers
ShippifyといえばAI活用に積極的なイメージが合ったのでその会社の人が「出しすぎが手抜き」と言っているのが面白いなと思いました。
一方で同じ時期に、lauren氏（@poteto）が自作のスキル集のpstackを使って月に約2000PRを本番に出している話も盛り上がっていました。
「出しすぎは手抜き」と「月2000PR」って一見すると矛盾してへんか？
と言うのがあって、調べてみましたが結局同じようなことを言ってるなと思ったのでまとめておくことにしました。
ポエムです。 悪しからず。
先にまとめ
先に置いておきます。
- AI時代の手抜きは「出さない」ではなく「出しすぎ」になったらしい
- ちょっとした修正をAIで直せるのは良いことだが、レビュー・QA・手戻りのコストは後続の誰かが払っている
- 顧客への価値とチーム全体のコストでROIを判断しないと、知らないうちにプロジェクトの遅延要因になる
- 月2000PR出す人は、確認コストを他人に付け回さず仕組みで下げている
- 顧客価値に責任を持ち「出して大丈夫です」と言える人を増やしその承認レベルが深くて幅があるほどにその人以外のチームメイトの確認コストは下がる説
続きが気になる方はどうぞ。
手抜きの定義が変わったらしい
動画の字幕はこんな感じでした。
The failure case now of lazy work is not lack of output. It's actually over output now.
スロップ手榴弾
Shopifyの社内ではこれをslop grenadeと呼んでいるそうです。 直訳するとスロップ手榴弾。AIで作ったものを自分で確認せずに同僚に投げて、確認や修正の負担を受け取った側に押し付けることを指しています。
名前が物騒すぎ
Lütke氏は例を2つ挙げていました。
例1：AIエージェントにコード変更を頼む
→ 中身をちゃんと読まずにPRを承認する
→ 結局レビューは同僚がやることになる
例2：短い要点をAIで長文メールに膨らませる
→ 受け取った人がAIで要約し直す
ドキュメントの共有なんかでもただ長いだけだと認知負荷が高く意思決定に時間がかかるなぁとか思っていたので心当たりあります。
AIコーディングの際のコードコメントなどもやたら長いものはとりあえず読んでしまうので長すぎると良くないと言う感覚は動画をみる前からありました。
Shopifyでは社内のAIエージェント経由で作られるPRが最大で全体の半分ぐらいあるそうです。 そこまでAIを使い倒している会社が次に直面した問題が「出しすぎ」だった、というのは結構示唆的やなぁと。
一方で月2000PR出してる人がいる
poteto氏はCursorのエンジニアで、pstackという自分用のスキル集を公開しています。
本人のガイド記事によると、8月は本番に入ったPRが2,462件だったそうです。
数字だけ見ると、Lütke氏が言ってる「出しすぎ」の権化みたいに見えます。 でも中身を読むと、むしろ逆のことをやっている印象で、成果を出すためにやるべきことの主張はLütke氏と似ています。
検証に投資している
ガイドの第1部のタイトルがVerification is all you needです。 AIにコードを書かせる前に、まず検証の仕組みを作れという話から始まっています。
・PRは小さく自己完結させて、レビューしやすい単位に分ける
・問題が見つかったら、PRだけでなくAIが動く環境の方を直す
周りの確認コストまで下げている
チーム全体で1日数百PRが入る中、本人は自分を庭師に例えて、コードを見張り、リファクタしたりlintやチェックを足したりして品質を保っているそうです。
そしてすごいまともだな思うのは、 エージェント以前はPR数なんて気にしたことがなかった。あれは虚栄の指標だった ということも本人が書いています。
なんかやたらコードの行数とか出してくる記事とかもあるよね〜
参考：
違いは確認コストを誰が払っているか
Lütke氏の手榴弾投げてる人の話とpoteto氏の話を並べると、こうなると思っています。
スロップ手榴弾を投げる人 → 確認コストを他人に付け回している
poteto氏 → 確認コストを自分で払って、仕組みで周りの分まで下げている
どちらもアウトプットはたくさん出ています。 違うのはアウトプットの質(≒アウトカム)とチーム全体の確認コストです。
アウトプットの価値 ＝ 顧客に届く価値 − 他人に発生させた確認コスト
後ろの項が前の項より大きくなると、価値はマイナスになります。 しかも出した本人は「たくさん出した」という実感があるので、マイナスを出していることに気づきにくい。
とりあえずクソデカPR投げる人
ほんまにコスト0？
実装は工程の一部でしかない
AIが短くしてくれるのは主に「コードを書く」工程です。 そこが0に近づいても、レビューとQAは0になりません。
「AIでサクッと直しました！」のサクッとはコーディングの部分で その後ろには、レビューする人の時間、QAする人の時間、差し戻された時の手戻りの時間があります。
実装コストが0に見えても、チームのコストは0じゃなかったりします
これは職種問わずあるようなことで、頼まれていないリファクタをついでに混ぜたり、AIが書いたテストをほぼ読まずに冗長なケース大量に足したり。 本人は「ちょっと良くした」とかAIがついでに出してきたしまぁ入れとくかみたいなつもりでも、レビューする側は読む量と考える量が増えているだけ、ということがあります。
なので職種や工程を問わず、成果を出すための後続コストを見積もれているかどうか（出る成果が同じであればコストを小さくする意識があるか）だと思っています。
レビューできる人も品質を保証するためのテストを行える人もリソースは限られている
あるPRが妥当かどうかを判断できる人は、そのコードベースや仕様にある程度精通している必要があります。
そこに「ちょっとした修正です、見てもらえますか」が飛んでくる。 レビュー自体は10分でも、今の作業の文脈を一回置いて、PRの文脈を頭に入れて、また戻るので、30分集中が切れるみたいなことは普通に起きます。
レビューを行う側の工夫も当然あるとは思いますが。
PRが貯まる昨今
レビュー待ちのPRが溜まっていく問題です。
制約理論という考え方があって、雑に言うと ボトルネック以外の工程をいくら速くしても全体は速くならず、ボトルネックの手前に在庫が積まれるだけ というものらしいです。
AIで作る工程が速くなって、レビューとQAがボトルネックになると、まさにこれが起きます。 レビュー待ちのPRやQA待ちのPRは世に出して初めて価値があります。
で、在庫のまま置いておいても価値は0です。
むしろ
・mainが進んでコンフリクトする
・その間に仕様が変わる
・作った本人も、何でこうしたか忘れる
「今は見れないです」と返すのにも、地味にコミュニケーションコストがかかるのでみることになります。
一個一個は小さくても差し込みの積み重ねでメインプロジェクトは遅延することにもなります。
組織的に何ができそうか考えてみる
プロトタイプとして渡すか、PRとして渡すかを分ける
AIで作った動くものを見せて軌道修正できるのは、間違いなくAIのメリットです。 なので仕様の叩き台として割り切る。プロトタイプならレビューもQAも要らないので。そう言う意味でも検証環境が気軽に使える体制はより重要になるでしょう。
検証を人ではなく仕組みに寄せる
人が毎回見なくても、過去の決定プロセスや判断指標を蓄積し仕組み化することで認知負荷を下げる。
AIにリスクを評価させて、レビューが必要かを決める
PRごとにAIがリスクを評価して、レビュワーを必須にするかどうかを決める仕組みです。
低リスク（レビュー不要、あとで抜き取りで確認）
・文言やスタイルの修正
・DBスキーマに触れない
・feature flagで切れる、すぐロールバックできる
高リスク（レビュー必須）
・DBスキーマの変更（マイグレーションは戻しにくい）
・決済や認証など、壊れたときの影響が大きい領域
・ロールバックしにくい変更
全部のPRを同じ重さでレビューするのではなく、戻しやすさと壊れたときの影響で仕分けるイメージがあるかなと思いました。
ボトルネックであるレビューの手前で在庫を仕分けて、本当に人の目が要るものだけを流すイメージです。 もちろん判定基準を決めるのは人間で、低リスクとしてマージしていいと決めた責任も人間側に残ります。問題が起きると確認の工数を増やしたくなりますが、エッジケースほど検出するコストがかかるのでバランスが最近大事やなと思います。
poteto氏の場合はドメインエキスパートのはず
1年半前にCursorが市場を席巻している理由をちょっと考えてみるという記事で、Cursorの強さは作り手自身がユーザーでありドメインエキスパートであることだと書きました。 エンジニアが、エンジニアのためのツールを作っている。
potetoさんはまさにそのCursorの人で、バックグラウンドはUXデザイナー出身でReactのコアチーム所属らしい。コーディングエージェントは自分の仕事道具そのものなので、AIの出力が正しいかも、使う人にとって嬉しいを自分で判定できる。 検証の仕組みを作って機械に判定させる。
AI時代に価値が上がっているのは承認できる深さを持っている人だと書きましたが、poteto氏はその極端な例で横にも広く深さがある。
深さがある
→ AIの出力を自分で承認できる
→ 他人の時間を使わずに出せる
→ 量を出してもチームが遅くならない
pstackの思想を見ると
- ドメインエキスパート（使い手目線）
- UXデザイナー（使いやすい機能を決める）
- エンジニア（作る人）
として、それぞれの工程で上手くいかなかった場合に、その結果ではなく、判断の指標を残して、徐々にその任せる範囲を広げていくという手法をとっていそうです。
とはいえ誰でもなれるわけではない
自分が一番詳しいコードベースで、作り手とユーザーが同じということになりますが、
多くのエンジニアは、自分ではない誰かの業務のためにシステムを作っています。 コードとして正しいかは判断できても、「現場の人にとって本当に嬉しいのか」はエンジニアリングだけでは判定できないことが多いです。
①まず自分が承認できる範囲を広げる
②承認できない部分は検証の仕組みに寄せる
③その結果として、出せる量が増える
という順番の方です。 順番を逆にして量から始めると、たぶんスロップ手榴弾職人になります。
ステークホルダに承認を得る際に一個一個の答えをもらうと言うよりは、承認に至る判断基準や思考プロセスを残していくというチームが今後強いのではないかと今回、思いました。
作業だけではなく、顧客価値に責任を持てる人を育てる
信頼されているTech Leadの「大丈夫です」
信頼されているTech Leadが「この件急ぎです、顧客へのマイナスの影響はないです」と言ったら、大体すぐにリリースが承認される。 みたいなことって、正味あると思います。
この人は顧客体験への影響まで見たうえで言っているから多分大丈夫みたいな判断がある。信頼があると確認コストがほぼ0になっていると言う意味でも、今後成果を出していく上では信頼は大事やなと思いました。
作業に責任を持つ → 「言われた通りに作りました」
顧客価値に責任を持つ → 「これはリリースして大丈夫です。顧客にマイナスはなく喜ばれるものです」
前者のアウトプットは、後ろで誰かが顧客への影響を確認しないといけない。 後者は、その確認を本人が済ませている。
人数少ない状態で「大丈夫です」と言える能力と環境を整える
顧客やドメインを理解して、変更の影響範囲を自分で見積もれること。
信頼は一回では作れないので、徐々に信頼を積み上げて広げていくしかないかなと。
これが通っていればOKと言う仕組みを整えることもより大事になってくるなと。
パラダイムシフトは起きたのか
2月ごろに書いた記事にAIは日に日に精度が上がって効率的にはなってるけど、まだパラダイムシフトは起きてないという印象を書きました。
今どう思っているかというと、根本的にはまだ変わってないなと言う感じ。責任はまだ人間が持っているし、承認がボトルネックなのも変わっていない。
ただ、Opus 5.5あたりからAIのアウトプットの精度はかなり上がった実感があります。 一発で期待通りのものが出てくる確率が明らかに増えてきました。
もういろんな取り組みが始まりつつある
Lütke氏が問題に名前をつけて共有したり、potetoさんが検証の仕組みに投資したりしているのもそうですが、Shopifyでは社内のAIエージェントが毎晩その日うまくいかなかったことを振り返って、自分の指示ファイルを自分で直す仕組みまであるそうです。チームはdreamingと呼んでいるとか。 人間のレビューに頼るのではなく、AI側の品質を上げて確認コストを減らす方向の取り組みというのもどんどん増えてきそうな世界線。
パラダイムシフトを起こすというより、何がボトルネックなのかがはっきりして検証コストを仕組みや体制で下げる取り組みが始まりつつあるのかなと思いました。
まとめ
作業だけではなく顧客価値に責任を持って「出して大丈夫です」と言える人を増やしていく。
そのためには個人の意識と環境づくり両方大切。
途中からあんまアウトプット出しすぎと関係なくなってきた笑
自分の今の悩み
色々書いてみましたが、
自分以外の人の負荷を下げようと思って、AIの成果物をちゃんとレビューして動作確認までしていたら、 気づいたら自分がボトルネックになっている感覚があったりします。
AIの精度はかなり上がっていることもあり、全部を同じ重さで見なくてもいいのかもしれない。その意味で、今回の調査は結構参考になりました。
レビューを減らせばスループットは上がるけど、 レビューはチームにナレッジを広げる場でもあるので、共有の場を減らしすぎると「システムは動いてるけど分かる人が極端に少ない」状態になりかねないなぁとかも思う。
省コスト（レビューを減らしてスループットを上げる）
↕
ナレッジの標準化
このバランスをどう取るかが結構わからん。
この記事も長すぎて読む人の認知負荷を上げている説
以上、