「スロップ手榴弾」を避ける方法

私がクライアントに伝えている助言はシンプルです。AI の支援なしに競争することはできません。AI のスロップを量産して競争することもできません。 ツールを使い、それを正しく使うために必要な専門性を手放さないことです。

Shopify の CEO であるトビアス・リュトケ氏は先日、レビューを経ないまま同僚に渡される AI の出力を「スロップ手榴弾」と表現しました。彼が挙げた例には、受け取った側が有用な情報を抜き出す作業を押しつけられる、水増しされたメールが含まれていました。誰かが生産的な気分になる一方で、別の誰かが後片付けを引き継ぐわけです。

うまい表現だと思います。ただ、これが組織の内部で起きているとき、私がまず問うのは、経営陣が何を評価すると決めたのか、どの専門性を手元に残したのか、そして誰かが「完了」をクリックした後に発生する仕事を誰かが測っているのか、という点です。

私はソフトウェアを作るために AI を徹底的に使っています。コードを一行ずつ手で打つ世界に戻るつもりはありません。私が勧める組み合わせは、経験のある人間と強力な AI ツールです。そして人間の貢献は、エージェントが何かを書き始める前から始まっています。誰かが方針を選び、制約を定め、作る価値のある解を見分けなければなりません。

これはエンジニアリングの問題か、マネジメントの問題か？

まずマネジメントの問題がある。Shopify は 2022 年 7 月に従業員の約 10% を削減し、リュトケ氏はパンデミック下の EC ブームがどこまで続くかを見誤ったと認めました。2023 年 5 月には、Shopify Logistics の売却とあわせて約 20% のさらなる削減を発表しています。この二度目の発表では、立ち上がりつつある AI 時代の機会にも触れていました。いずれも、会社の方向性、人員、優先順位に関する経営判断です。

2025 年 4 月、リュトケ氏は AI の活用を基本的な前提とし、それを人事評価とピアレビューに組み込み、増員や追加リソースを求めるチームには、なぜ AI ではその需要を満たせないのかを説明するよう求めました。彼のメモでは、人間の技能を AI で何倍にもするという考えも明確に打ち出されています。この原則には私も賛成です。

これらの事実は、Shopify の人員削減がスロップ手榴弾を引き起こしたことを示すものではありませんし、経験豊富なエンジニアが軒並み非技術者のプロンプト操作者に置き換えられたことを示すものでもありません。ただ、なぜマネジメントの問いが重要なのかは示しています。人員方針と AI 活用の期待値を決める人は、その組み合わせを機能させる責任も負っているのです。

私が異議を唱えるのは、AI を使っていることの証明を従業員に求めながら、生成された出力を有用な仕事に変えるために必要な判断・検証・保守に同じだけの重みを置かない運営モデルです。AI にその仕事ができるかを問う前に、経営陣はその結果を正しく届けるには何が必要かを問うべきです。この二つは同じ問いではありません。

エージェントはプルリクエストを出せるか。結構。それが正しい問題を解いているかどうかは誰が分かるのか。アーキテクチャ上の影響は誰が見るのか。壊れたときに誰が責任を持つのか。別の従業員の一日のうち、どれだけがそのレビューと修復に消えるのか。

従業員は自分が提出したものに責任を負い続けます。しかし、互いに評価できない仕事を繰り返し渡し合っているなら、それは期待外れな従業員の寄せ集めではなく、組織設計の問題だと私は見ます。経営陣が生産性向上の手柄だけを取り、後片付けを人材の問題として扱うことは許されません。

AI で何かをつくれば、それはエンジニアリングなのか？

Enter を押すことはエンジニアリングではない。技術者でない人が AI でものを作ること自体に問題はありません。試してみることのハードルが下がったのは、この技術の最も心躍る側面のひとつです。以前はスケッチ止まりだったアイデアを、動くプロトタイプとして探索できるようになったのは素晴らしいことだと思います。

ただし、プロトタイプと本番システムは別の責任です。何が作られたのか、それがどんな前提に依存しているのか、その前提が誤っていると分かる証拠は何か。これを理解する人が依然として必要です。

エージェントとデプロイボタンの間に人間を置いても、それだけで意味のある監督が生まれるわけではありません。その人には、エージェントに異を唱える知識、その仕事を調べる時間、結果を却下する権限が必要です。そうでなければ、承認の工程は儀式にすぎません。

これは AI に懐疑的な人だけの懸念ではありません。GitHub 自身のガイダンスも、同社のエージェントが誤ったコードや安全でないコードを生成しうると警告し、その出力をレビューしテストすることを推奨し、AI によるコードレビューは人間のレビューを置き換えるのではなく補うものだと述べています。

盲目的な承認は「ゴミを入れればゴミが出る」問題ですが、そのゴミはプロンプトの中だけにあるとは限りません。不完全な要件かもしれませんし、欠けた制約、急ぎすぎを促すインセンティブ、あるいは同じシステムに「うまくやれたか」と尋ねるだけのレビュー工程かもしれません。解決策は、いつ異を唱えるべきかを知っている人を雇うことです。

エンジニアリングとは、何をかを尋ねることではなく、どうやるかを知っていること

製品が何をすべきかをエージェントに伝えることと、その製品がどう実装されるべきかを知っていることの間には、大きな隔たりがあります。「これらのレコードを処理するシステムを作って」は結果の記述です。アーキテクチャ、想定される負荷、メモリ予算、セキュリティ境界、障害時の挙動については、ほとんど何も語っていません。

優れた AI 支援エンジニアは、その欠けた方向性を補います。プロジェクトで確立されたコーディング様式に従わせる、既存の抽象を再利用させる、適切なデータ構造を選ばせる、入力が増えるにつれて法外に高くつくアルゴリズムを避けさせる、といった指示ができます。リポジトリの指示書を書くことが役に立つのは、そこに何を書くべきかを知っている人がいる場合だけです。

これは実装の細部をすべて指図するという意味でも、人間の最初の思いつきが必ず優れているという意味でもありません。エージェントには代案を出し、前提を問い直してほしいと思っています。ただ、最も自信ありげに聞こえる説明を受け入れるのではなく、その代案を評価できるだけの理解を持つ人が必要です。

「効率よくして」は効率の理解の代わりにはなりません。「安全にして」はセキュリティモデルではありません。誰かがそれを具体的な要件に翻訳し、実装がそれを満たしていることを検証するまでは、どちらも願望にとどまります。

AI がコードを書くなら、オーダー記法はもう関係ないのか？

オーダー記法はなくなっていない。単純な例を考えてみましょう。二つのコレクションのレコードを、一意な識別子で突き合わせる処理です。ある実装は、一つ目のレコードごとに二つ目のコレクションを何度も走査するかもしれません。それぞれ n 件のコレクションなら、n² 回の比較が必要になりえます。一方、固定長の識別子であればハッシュによる索引を作ることで、突き合わせを期待計算量 O(n) に収めることができます。代わりに O(n) の追加メモリがかかります。これは時間と空間のトレードオフであって、書式の好みの問題ではありません。

小規模なデモでは、どちらの実装も正しい答えを返すかもしれません。エンジニアリング上の問いは、その製品が実際に支えなければならない負荷のもとで何が起きるか、です。扱うデータはどれくらいか。使えるメモリはどれくらいか。これは時折走る処理なのか、それともリクエストのたびに起きるのか。

経験のある担い手なら、エージェントに有用な方向づけができます。「レコードごとにコレクション全体を走査し直さないこと。索引を作り、そのメモリコストも見積もり、想定される入力サイズでベンチマークを取ること。」この指示は問題の理解から出てくるものであって、魔法のプロンプトを見つけたから出てくるものではありません。

同じ理解は、不要な最適化を防ぐはずです。性能を最大化しろと言われたからといって、些細な処理を大仰な仕組みに仕立て上げるエージェントは望みません。担い手には、時間計算量、空間計算量、そして実際の要件を十分に理解したうえで、適切な解を選んでほしいのです。

指示が日本語で書かれるようになったからといって、計算機科学が不要になったわけではありません。変わったのはソフトウェアの頼み方です。ソフトウェアを正しく、効率的に、保守しやすくする性質そのものは変わっていません。

ときには「ステートマシンで作れ」と言う必要がある

待機中、実行中、完了、失敗、キャンセルのいずれかの状態を取りうる、バックグラウンドの取り込み処理を作るとしましょう。ありがちな実装は、進捗を個別のフラグの集まりで追いかけます。しかしその設計では、実行中と完了が同時に成り立つといった矛盾した組み合わせを防がなければなりません。

有限ステートマシンは、その処理に明示的な状態の集合と、状態間の定義された遷移を与えます。次に何が起こりうるかの判断をアプリケーション中に散らすのではなく、どのイベントが処理をある状態から別の状態へ動かしてよいかをモデル化できます。これがステートマシン記法の土台にある基本概念、すなわち状態、イベント、遷移です。

エージェントが自分からその方針を提案することもあるでしょう。結構なことです。しかし提案しないこともあり、指示する側はその問題がそれを求めていることに気づけなければなりません。ときに有用な指示はこうです。「これを有限ステートマシンとして実装してください。正当な遷移を定義し、キャンセルを明示的に扱い、キャンセル後に完了イベントが届いた場合に何が起きるかをテストしてください。」これはシステムの挙動のモデルを選ぶという行為です。

有限ステートマシン、ステートチャート、その他のオートマトンは、人間の担い手の技術的な道具箱に属します。あらゆる機能に形式モデルが要るからではなく、どんなときにそれが問題を明確にし、どんなときに不要な複雑さを足すだけなのかを見分けられるべきだからです。パターンの名前を知っているだけでは足りません。それがどこに当てはまり、何を保証し、何を未解決のまま残すのかを理解する必要があります。

そして「ステートマシンを使え」は、実装を正しくしてくれる呪文ではありません。私は依然として遷移を確認し、挙動をテストしなければなりません。価値は、私が筋道立てて考えられる構造をエージェントに与えたことにあります。ハッピーパスのテストを通ったというだけの条件分岐の寄せ集めを受け入れるのとは違います。

ヒューマン・コンピュータ・インタラクションも省けない

計算機科学だけが、いまも必要とされる専門性ではありません。ヒューマン・コンピュータ・インタラクションも同じく重要であり、エージェントが裏のコードと同じ速さで画面を生成できるからといって、これを任意の仕上げ作業として扱うつもりはありません。

インターネットの多くの部分はエージェント中心になっていくと見ています。それでも私は、人が理解して使う必要のある製品を作っています。その人たちは、いま何が起きているのか、自分の選択が何を意味するのか、操作が成功したのか、うまくいかなかったときにどう立て直せばよいのかを知る必要があります。可視性、一貫性、ユーザーによる制御、エラーの予防は、確立されたインタラクション設計の原則であって、装飾的な好みではありません。

「いい UI にして」は、「アルゴリズムを効率よくして」と同じ程度にしか役に立ちません。熟練した専門家なら、エージェントにずっと具体的な方向づけができます。ユーザーのタスクを軸に情報を組み立てる、慣れた導線を保つ、主要な操作と破壊的な操作を区別する、進行中と失敗の状態を分かるように示す。アクセシビリティは、キーボード操作、可視のフォーカス、意味のあるラベル、支援技術に届く状態メッセージなど、具体的な実装要件を加えます。

ステートマシンの例で挙げたバックグラウンドの取り込み処理を考えてみます。内部状態を正しく設計するのは仕事の一部にすぎません。私は画面にも、開始待ち、取り込み中、一部完了、キャンセル済み、失敗を区別してほしいのです。使う人が、回り続けるスピナーからその違いを推測する羽目になってはいけません。

エージェントへの私の指示はこうなるかもしれません。「失敗後もユーザーの選択を保持してください。どのレコードが取り込まれ、どれが取り込まれなかったかを説明してください。処理が本当に完了するまで成功メッセージを出さないでください。キャンセルがまだ可能かどうかを示し、再試行の挙動を明示してください。」

これは実装の指針であって、もっと綺麗な配色をくれという依頼ではありません。私は出来上がった画面を実際に使い、該当する状態をテストし、人々が理解できるかを観察しなければなりません。よくできたスクリーンショットは、その体験が成立している証拠にはなりません。

同じことはエージェント自身のインターフェースにも当てはまります。メニューを会話に置き換えても、作業範囲、進捗、不確かさ、結果を伝える必要はなくなりません。むしろ複数のシステムをまたいで動くエージェントでは、こうした設計判断はより重要になると私は思います。人間には、その仕事を理解し、中断し、修正し、承認する手段が依然として必要です。

エージェント中心のインターネットは、人間と無関係なインターネットではありません。人が仕事を指示し、その結果とともに生きているかぎり、その関係を設計する誰かが必要です。

エージェントがコードを書くとき、セキュリティの責任は誰にあるのか？

Enter を押すことはセキュリティ戦略でもプライバシー戦略でもない。コードの品質は責任の一部にすぎません。エージェントはファイルへのアクセスを求め、コマンドを実行し、サービスとやり取りし、脆弱性を含むコードを生成することもできます。GitHub 自身のガイダンスは、誤った出力や安全でない出力、そして入念なレビューとテストの必要性について明確に警告しています。

操作を承認する前に、担い手には、それが何にアクセスでき、何を変更でき、データがどこへ行きうるのかを問うてほしいと思います。この作業に本番の認証情報は本当に必要か。そのデバッグログには顧客情報が含まれていないか。読み取るだけでよい処理が、なぜ変更や削除の権限を持っているのか。

これらはデモが動いてから考える細部ではありません。OWASP は、過剰な機能・権限・自律性をエージェント型システムのリスク源として挙げています。その推奨には、能力を限定すること、最小権限を徹底すること、影響の大きい操作には承認を求めること、そして何が許されるかをモデルの判断に委ねるのではなくモデルの外で認可を実装することが含まれます。

あらゆる要求を盲目的に承認する人は、これらのリスクを実質的に評価していません。ただし答えは、経験のある人を雇ってすべてを捕捉してもらう、ということでもありません。その人には、境界が実際に強制される環境、適切なアクセス制御、そして完璧な注意力に依存しないレビュー工程を用意してください。

だからこそ私は担い手の理解力を重視します。その人は承認ボタンの前の席を埋めるだけでなく、防御策の設計に関わる必要があるのです。

コンプライアンスはエンジニアリングの一部

デモで動く製品が、そのまま組織として責任を持って運用できる製品とは限りません。どんな情報を扱うのか、誰がその情報にアクセスできるのか、どの義務が適用されるのか、統制が機能していることを示すために組織はどんな証拠を必要とするのか。これらを理解する人も必要です。

事業によっては、SOC 2、PCI DSS、HIPAA が関わってきます。これらは種類の異なる義務と保証の仕組みであり、交換可能な三つのバッジではありません。

• SOC 2 は、該当する Trust Services Criteria に照らして統制を第三者が検証するものです。その規準には変更管理、すなわちシステム変更の承認、文書化、テスト、許可、実施が含まれます。エージェントがビルドを成功させたことは、組織がその手順を踏んだ証明にはなりません。
• PCI DSS は、決済口座データに関する技術的・運用的なセキュリティ要件を定めています。その適用範囲は、カード会員データ環境のセキュリティに影響するシステムやサービス提供者にも及びうるもので、カード番号を直接保存するデータベースだけではありません。この範囲を理解することも、責任あるシステム設計と運用の一部です。
• HIPAA は、対象事業者およびそのビジネスアソシエイトに適用される場合、電子的な保護対象保健情報を守る要件をもたらします。そのセキュリティ規則には、リスク分析、アクセス制御、監査統制、ビジネスアソシエイトとの適切な契約が含まれます。これらの責任は、AI アシスタントがアプリを書くのを手伝ったからといって消えるものではありません。

開発者全員がコンプライアンス弁護士や監査人である必要はありません。経験あるチームには、これらの要件が設計に影響する場面を見抜き、出荷前に適切な専門性を招き入れてほしいと考えています。「エージェントには誰も伝えなかった」は要件定義の失敗であって、免除事由ではありません。

影響の大きい本番変更については、依頼から実装、テスト、レビュー、承認、デプロイまでをつなぐ監査証跡がほしいところです。何が変わったのか。なぜか。レビューされたのはどのバージョンか。誰がどんな権限で承認したのか。実際に本番へ届いたのは何か。

その記録は作業と同時に生み出されるべきであり、後から誰かの記憶とエージェントの快活な要約をもとに再構成するものではありません。「承認済み」という記録は、誰かがボタンを押したことを示すだけです。それ自体は、意味のあるレビューが行われたことを示しません。

エージェントの仕事を承認するとは、実際には何を意味するのか？

承認は決定であって、キー入力ではない。結果を確かめずに Enter を押すことは、組織にも、その顧客にも、承認した本人にもリスクをもたらしえます。デバッグのために本番ログを外部サービスへアップロードしたい、とエージェントが提案する場面を考えてみてください。その要求を承認する前に、そのログに何が含まれるのか、その送信先は許されているのかを誰かが確かめる必要があります。提案された対処が手軽だということは、そのどちらの問いにも答えていません。

必要な防御策を迂回した従業員に、影響が及ぶこともあります。たとえば HIPAA の制裁方針に関する HHS のガイダンスは、警告から解雇に至るまでの帰結に触れつつ、適切な対応は組織と状況に委ねています。誤った承認のたびに誰かが職を失うべきだ、という主張ではありません。承認が職業上の責任を伴いうる、という注意喚起です。

しかし経営陣は、その責任を果たすために必要な知識、時間、情報、権限を与えないまま、その責任を公平に割り当てることはできません。評価できない承認待ちの列を渡し、それをどれだけ速く片づけたかで人を測り、結果が悪ければその人を責める。これは責任ある委任ではありません。

承認のインターフェース自体も、その決定を支える必要があります。デプロイであれば、レビューする人には実際の差分、対象環境、関連するテスト結果、未解決のリスク、復旧計画が見えていてほしい。これから何が起きるのかの説明の代わりに「続行しますか？ Y/n」が出てくるのは望みません。

一方で、無害な操作のたびに人間の承認を求めるワークフローも望みません。私の狙いは、定められた境界の中で低リスクの作業を自動化し、判断を要する決定に人間の注意を取っておくことです。ボタンを増やすことは、監督を増やすことと同じではありません。

フォードは失った専門性を築き直さねばならなかった

ブルームバーグは 2026 年 6 月、フォードが過去三年間で 350 人のベテランエンジニアを採用し、その中には元従業員やサプライヤーのエンジニアも含まれていたと報じました。彼らは品質問題への対応、若手の育成、そして期待に届かなかった AI ツールの改善を支えていました。これは車両エンジニアリングと品質システムの話であって、生成されたアプリケーションコードを片づけるためにフォードが 350 人のソフトウェア開発者を再雇用した、という話ではありません。

私がソフトウェア企業に持ち込みたい教訓はここです。高給のエンジニアを表計算から消す前に、その人が目に見える成果物の外で何をもたらしているのかを理解してください。何を未然に防いでいるのか、何に早く気づくのか、チームの他のメンバーがその人の理解に何を頼っているのかを問うてください。そのうえで、よりよい道具があればその人が何を成し遂げられるかを考えてください。

給与が下がれば、本当にコストも下がるのか？

給与の安さをコストの低さと取り違えるのはやめよう。経営陣は人件費を下げたい。分かります。私も事業を営んでいますし、見返りを期待せずに支出しろと言っているわけではありません。ただ私は、その見返りを、有用な製品を届けて保守し続けるコストと比べます。働く一人ひとりに紐づいた給与額と比べるのではありません。

友人が先日、ニューヨーク市の出社前提のソフトウェアエンジニア職の募集要項を送ってきました。修士号と業界経験六年を求め、20 万ドルを提示していました。この組み合わせは私には腑に落ちませんでした。影響の大きい AI 支援開発を率いてほしい水準のエンジニアなら、私はこの職を別の形に設計します。

まず、その訓練が本当に効いてくる研究職でない限り、修士号の要件は外します。私が知りたいのは、その人が何を作ってきたか、どの難しい決定を引き受けてきたか、そしてその決定の帰結を理解しているかです。計算機科学の知識を求めることと、特定の学位を求めることは同じではありません。

なぜ別の選択肢ではなくそのアーキテクチャを選んだのかを説明できるか。セキュリティ境界を見分け、性能について筋道立てて考え、障害時に理にかなった振る舞いをするシステムを設計できるか。エージェントを良い実装へ導き、一見うまくいっているが実際の要件を満たさない結果を却下できるか。

私が採用の基準にしたいのはこうした能力です。そのうえで年俸 35 万ドル前後、加えて AI の支援に月あたり最大 2,000 ドルを予算に組み、その投資に見合う人物であることを選考で確かめられるよう期待します。

これは影響の大きい職務についての私の予算案であって、あらゆるエンジニア職を同額にすべきだという主張ではありません。高い給与を提示したからといって、候補者をきちんと評価する経営陣の責任が消えるわけでもありません。要点は、AI のサブスクリプションがその専門性の価値を下げると考えるのではなく、戦略が依存する専門性を本気で取りにいくことです。

エンジニアの道具予算はどれくらいが妥当か？

エンジニアに本気の道具予算を。月 2,000 ドルという枠は AI ツール全体の予算であって、特定のサブスクリプションの価格でも、使い切るべきノルマでもありません。承認された用途については、たとえば Claude Max プランを経費精算し、それに追加の利用分を足すような形を想定しています。Anthropic はプランに含まれる枠を超えた従量課金を、支出管理の仕組みとともに提供しています。

アカウントと利用形態は、組織のセキュリティ、プライバシー、契約上の要件に適合していなければなりません。個人のサブスクリプションを精算することでこれらの問題が片づくわけではありません。扱う情報とシステムに見合った形をチームが選ぶ必要があります。

枠を使い切ると、年間 2.4 万ドルの AI 支出が 35 万ドルの給与に加わります。つまり福利厚生、雇用主負担、賞与、株式などの間接費を除いて、給与とツールで 37.4 万ドルです。ツールは給与の 7% 未満です。私はこの支出を、それがエンジニアに何を届けさせるかで判断します。

給与とツールだけを見る、意図的に単純化した比較では、37.4 万ドルは 20 万ドルの 1.87 倍です。高いほうの組み合わせが、比較可能な有用な仕事を 1.87 倍より多く届けるなら、その仕事一単位あたりのコストはむしろ低くなります。これは経済性の説明であって、予測ではありません。実際の比較には、双方の完全なコストが要ります。

狙いは 10 倍の開発者を 100 倍の開発者にすることです。これらの数字は私が追いかけたい目標を表すものであって、保証された生産性の倍率ではありません。慎重に選んだエンジニアに強力な道具を与えるほうが、より安い人を探して足りない判断力は AI が補ってくれると仮定する採用戦略に勝ると私は考えますが、その見立ては届いた仕事で検証します。

これは若手の開発者が不要だという話ではまったくありません。私は彼らに、経験のある人のそばで学び、AI を使いながら、それを疑えるだけの知識を育ててほしいと思っています。高くつく間違いは、経営陣がエージェントで経験を代替できると判断して、彼らから指導者を取り上げ、まだ引き受ける準備のできていない責任を負わせることです。

人間とエージェントのための組織

これが私が Orgabot で中心に据えている組み合わせです。人間と AI エージェントが組織の中で定義された役割を担い、ワークフローが責任、権限、チェック、承認を明示します。狙いは、組織の働き方を十分に明示的にして、意味のある境界の中で自律的な作業が進むようにすることです。

私が重視する区別は、エージェントが推論してよいことと、周囲のソフトウェアが強制しなければならないことの境目です。柔軟な計画と実装は、ツールへのアクセス、必須の承認、テスト結果、監査証拠に対する統制と並んで存在すべきです。承認を得るという要件が、エージェントが解釈し直せるプロンプト中の提案であってはいけません。

影響の大きい本番変更について、私が望むワークフローは、資格のある人間が目的と制約を定めるところから始まります。エージェントは調査し、方針を提案し、変更を実装し、テストとレビューを助けられます。そのうえで責任者が、リスクに見合った証拠を評価し、承認された変更が本番へ進みます。

承認は、実際にレビューされたバージョンに結びついていてほしい。その後に実装が実質的に変わったなら、必要なレビューをもう一度受けるべきです。依頼、実施した作業、走らせたチェック、下した判断、デプロイの結果についての明確な記録も求めます。

コンプライアンスを念頭に Orgabot を設計するというのは、私にとってこういう意味です。責任と証拠を工程の一部にすること。ツールを入れれば組織が準拠したと宣言できる、という意味ではありません。組織は自らの義務を定め、適切な統制を設定し、それが機能していることを示さなければなりません。

人間の貢献は最初から最後まで重要です。ステートマシンが要ると気づく、高くつくアルゴリズムに異を唱える、プライバシーの境界を守る、当てはまる規制要件を見つける、その画面がなぜ人を迷わせるのかを説明する。誰かがそれをやらなければなりません。これらの責任は複数の熟練した専門家に分かれることもあります。組織図は、その所在をはっきりさせるべきです。

スロップ手榴弾はどう避けるのか？

承認ではなく、当事者責任を前提に人を置く。 影響のある仕事は、結果を評価でき、デプロイ後もその責任を持ち続けられる人に任せる。学位や長い経歴、最新モデルへの熱意だけでなく、示された理解力で採用する。経験の浅い人には指導と、その理解を育てる道筋を与える。

解を生成する前に成功を定義する。 必要な挙動、破ってはならない制約、その仕事を受け入れるために必要な証拠を書き出す。失敗ケースも含める。エージェントがコードを書き、そのコードと辻褄の合うテストを書くだけでは足りません。検証は当初の要件に立ち返る必要があります。

レビューを本物にし、それに見合う原資を付ける。 変更を精査し、前提を問い直し、連携をテストし、実際のユーザー体験を確かめる時間を予算に組む。これらの活動を AI に手伝わせるのはよいが、別のモデルの承認だけを結果を信じる根拠にしない。責任者は、生産性の障害物として扱われることなく、工程を止められなければなりません。

仕事全体を測る。 要件を明確にし、生成し、レビューし、修復し、デプロイし、支え続けるまでの時間を、ツールのコストとあわせて数える。それを届いた成果と比べる。一人が早く終えた裏で三人の同僚が差分を吸収したのなら、その作業は効率的になっていません。

どれも AI を拒むことや、わざと遅く進むことを求めてはいません。求めているのは、「完了」が何を意味するのかについて正直であることです。

条件を握っているのは経営陣

誰かに余計な仕事を生む働き方にリュトケ氏が異を唱えるのは、もっともです。私が異を唱えるのは、その振る舞いを、周囲の人員配置、インセンティブ、基準から切り離して扱うことです。企業の AI 戦略には、誰がツールを使うのか、その人たちが何を理解しているのか、経営陣が何を検証させるつもりなのかが含まれます。

人件費を抑えたい気持ちは理解できます。私はそれを、一人のエンジニアにより多く払うことになっても、投じた一ドルあたりの成果を高めることで追求します。示された専門性で採用し、それを取りにいけるだけの報酬を払い、その専門性が効いてくる道具と労働条件を整えてください。

仕事を生み出す能力を広げながら、仕事を評価する能力を削ること。それはスロップ手榴弾を量産する非常に効率のよい方法です。AI の支援なしに競争することはできません。AI のスロップを量産して競争することもできません。 どちらの結果になるかを決める条件は、経営陣が握っています。

参考資料

• The Knowledge Project
• Shopify の 2023 年の発表
• Shopify の 2022 年の発表
• リュトケ氏の 2025 年 4 月のメモ
• GitHub のガイダンス
• W3C のステートマシン記法
• Nielsen Norman Group のユーザビリティ原則
• W3C のアクセシビリティ指針
• OWASP の過剰な自律性に関するガイダンス
• AICPA の Trust Services Criteria
• PCI Security Standards Council
• HHS によるセキュリティ規則の概要
• HHS の制裁方針に関するガイダンス
• ブルームバーグの報道
• Anthropic の利用に関するドキュメント
• Orgabot