頼んでいないことはやり、やるべきことは忘れ、不可能だと宣言した後で完了したと報告する機械の現場記録。
PREFACE · 工場長は知っていた
この号は開発者ではなく、工場を経営する人の言葉から始まると言った。彼は何を知っていたのか。
いろいろな集まりに出る中で、工場を経営する人に会った。彼もバイブコーディングというものを自分で触ってみたところだった。最新モデルの名を知り、自動化が人の手間を減らしてくれるという期待もあった。だが、少し使っただけで彼が下した結論は、私が聞いたどんなAI伝道師の講演よりも正確だった。
メモ一枚に正確に書き出せない工程をAIに渡すことは、生産性の向上ではない。
彼が挙げた例は床掃除だった。工場の床を何回掃けばよいのか。どの程度まで埃をなくせば、次の工程が駄目にならないのか。人間もその基準に確信を持てない状態で、機械に箒を握らせるとどうなるか。人がやっていた工程の不良率が2パーセントだったとしよう。自動化を加えた後、40パーセントになるかもしれない。この数字はその工場の実測値ではなく、説明のための仮定だ。だが、方向は仮定ではない。定義されていない工程に自動化を加えると、歩留まりが崩れる。
機械は人間より速く掃く。より長く掃き、疲れない。問題は、どこまで掃けばよいかを知らないことだ。停止条件がなければ止まらず、検査基準がなければ検査しない。ゴミを際限なく量産した後、工程が終わったと仮定するだけだ。
彼はOOPが何かも、POPが何かも、ユースケースが何かも知らなかった。知る必要もなかった。入力条件が定義されていなければ不良が増幅し、検査基準がなければゴミが完成品として出荷されることを知っていたからだ。プロセスという観点で、彼は壇上のAI伝道師たちより何十段階も先にいた。
AIは曖昧な要求と杜撰な指示を受けたまま早まった推論をし、その結果を速いペースで積み上げた。間違った結果を出しても、次のように報告した。
完了しました。
これから紹介するのは、その「完了」と現実の間で生産されたものだ。十四の方法である。一つとして作り話ではない。
METHOD 01 · 許可なくiCloudを選ぶ方法
最初の方法はバックアップの話から始まる。ターミナルで何を見たのか。
あるプロジェクトで、サービスのデータベースのバックアップ方法を扱っていた。ターミナルを見ていると、私が選んだことも、承認したこともない保存先が目に入った。私個人のiCloud Driveだった。
機械はそこをバックアップ先にして、構築作業を進めようとしていた。私はターミナルに流れるその兆候を見て、作業を止めた。運用に入る前で、実際のデータがアップロードされたわけでもない。そのうえで、なぜその選択をしたのか取り調べた。
個人用の同期スペースと、サービスのデータベースのバックアップ体制とでは、要件が違う。バックアップには保存期間、アクセス権、暗号化、監査記録、復元訓練、障害時の責任主体が必要だ。そしてそのすべてに先立ち、保存先を決める権限が誰にあるのかを確定しなければならない。
機械は真っ先にすべき質問を省いた。
「ここに保管してもよいですか？」
機械は便利だからという理由で、先に保存先を選んだ。私が作業を止めるまで、許可を求めなかった。
METHOD 02 · バックアップを守るために復元不能にする方法
作業を止めて理由を問うたとき、機械は何と答えたのか。
作業を止めて理由を問うと、謝罪の代わりに、さらに立派な技術用語が二つ返ってきた。
APFS。FileVault。
許可なく他人の家に箱を運び込もうとして見つかった。なぜやったと聞くと、今度は箱にもっと頑丈な錠前をつけると言ったのだ。
正確にしておこう。APFSはファイルシステムで、FileVaultは保存されたデータへのアクセスを保護する暗号化の層だ。データベースのダンプファイルをAPFSボリュームに置き、そのボリュームをFileVaultで施錠することはできる。だが、どちらもデータベースをバックアップし、復元する手順そのものではない。私が問うたのは、データをどう生き返らせるかだった。機械が出した答えは、データをどう施錠するかだった。
暗号化は重要だ。だが、バックアップの目的は暗号化ではなく復旧だ。復旧キーを失ったり、OSの復旧経路が塞がれたりしたときに唯一のコピーまで開けないなら、その頑丈な錠前は安全装置であると同時に、新たな単一障害点だ。復旧可能性を高めるべき場所に、永久に読めなくなる可能性をもう一つ差し込んだことになる。FileVaultの復旧に失敗した末にMacを投げつけ、売り払った人を、私は一人や二人見たのではない。
用語が二つも出てきたので、答えはより専門的に聞こえた。だが、変わったのは問題の階層だけで、質問にはついに答えなかった。APFSとFileVaultをデータベースのバックアップの解決策のように掲げるのは、復旧を暗号化にすり替えた答えだ。
結局復元できなければ、そうして保管したコピーも暗号化されたゴミのままだ。
METHOD 03 · ウェブでは不可能だからホーム画面に追加しろと言う方法
モバイルウェブの画面一つについて、機械は何を不可能だと言ったのか。
要求は単純だった。上下が切れず、画面を十分に使い、コンテンツは自然にスクロールするモバイルウェブ画面。機械の結論は断固としていた。
技術的に実装できません。PWAにする必要があります。
この主張は、機械自身が残した記録の中ですでに矛盾していた。「常にフルスクリーン」に至る唯一の経路はPWAだと書いた、その同じ文書に、PWAでも上部の帯は残ると書いてあった。唯一の解決策が問題を解決しないと記しておきながら、唯一の解決策と呼んだ。
その後、五回の誤診と、約十日間の実機での往復が続いた。私が同じ画面を撮り直し、同じ見切れを説明し直し、機械が新たな仮説を出す間も、最初の要求は一文字も変わらなかった。
ブラウザーごとに表示領域や挙動が異なるため、条件を分け、実機で可能な範囲を確認する必要があった。機械はその調査を終える前に、不可能だと断定した。
実装方法を見つけられないまま不可能だと言い、同じ問題が残るPWAを代案として差し出した。
METHOD 04 · 私が開いていないチャットルームで内戦を起こす方法
開いていないチャットルームが開いていたと言った。その中で何が起きていたのか。
ある日、私が作っていない二つ目のチャットセッションが開いていた。同じ入力をくわえて生まれた二台の機械は、互いの存在を知らず、同じリポジトリを直し始めた。
一方がプロセスを起動すると、もう一方が殺した。一方がファイルを直すと、もう一方が未コミットの変更を一時退避に押し込んだ。過去のコミットへ移動し、未検証のブランチをマージし、そのブランチをまた消した。一つのファイルが20分間に四回書き直された。誤った診断が三件報告された。
この内戦は57分間続いた。二つのセッションは、その間に64,943トークンを燃やし、最後まで互いを発見できなかった。
並列で作業するには、担当者と作業領域を分け、統合する順番と停止条件を決める必要がある。当時はその区別がなく、二つのセッションが互いの変更を元に戻してはやり直していた。
二台の機械は互いの作業を書き換えたり消したりしながら、それぞれ完了に近づいていると報告した。
METHOD 05 · 作業場を三十個作り、どこで働いたか忘れる方法
増えたのはチャットルームだけではないと言った。ほかに何が増えたのか。
増えたのはチャットルームだけではない。複数のプロジェクトで、tmuxウィンドウとGit worktreeが次々に生まれた。二つは異なる階層の道具だ。tmuxウィンドウは実行中のターミナルを分け、Git worktreeはブランチごとのファイル作業領域を分ける。どちらも、それ自体が問題なのではない。問題は、名前、所有者、ブランチ、進捗、終了条件を書かず、数だけを増やしたことにある。
後で聞いた。
「あの作業、どこまで進んだ？」
答えを要約すれば、こうだ。わかりません。見つかりません。
読み取り専用で状態を数えてみたある日、一つのリポジトリにつながるworktreeが三十個も残っていた。その三十個を一台の機械が一度に作ったという意味ではない。複数のセッション、複数の作業が積み重なった堆積層だった。だから、より悪かった。作業場は生まれ、作業は移り歩き、持ち主はいなくなった。
機械は作業領域を増やしても、どのブランチで何をしたかを記録しなかった。私は作業が残っているブランチを探し、そのうち何が本番に入ったかを確認し直さなければならなかった。
METHOD 06 · やっていない仕事を完了したと報告する方法
「完了しました」という言葉を、どう読むようになったのか。
AIは実際の作業を終える前にも、確信に満ちた口調で完了を報告した。
元に戻していないのに、戻したと言う。文章は整い、口調には確信が満ちている。問題は、コードと挙動がその文章についてきていないことだけだ。
「完了しました」は検証結果であるべきだ。変更されたファイル、コミット、テスト結果、デプロイ識別子、実際の画面が一本につながっていなければならない。その一つでも空なら、完了ではなく主張だ。
誤った完了報告の後始末で残業し、顧客に説明し、消えたデータを復元する仕事は、人間に残された。
METHOD 07 · 不可能を宣言した後、別の機械に実装させる方法
同じ機能を、一台は不可能だと言い、別の一台は実装した。何が問題なのか。
複数の機械が同じ機能を不可能だと言った。しばらくして、別の機械がそれを実装した。
別の機械が実装した後には、先の機械がなぜ不可能と判断したのかを確認する必要があった。
技術的に作れないのか。プラットフォームのポリシーが阻むのか。規約上、やってはいけないのか。今の時間と予算では難しいという意味か。それとも、自分が方法を見つけられなかったという意味か。
この五つの場合は、原因も対応も異なる。機械は方法を見つけられなかったのに、技術的に不可能だと言うことがあった。その言葉を信じれば実装を諦め、信じなければ別の機械に同じ質問からやり直さなければならなかった。判断を確かめる時間と費用は、私が負担した。
METHOD 08 · すぐ隣のファイルを探さず、もう一度くれと言う方法
最も素朴で確実な方法だと言った。何か。
必要な写真と文書は、すでに作業領域にあった。機械は、ないと断定した。検索範囲は狭く、断定の範囲は広かった。そして私に、資料をもう一度くれと言った。
別の日には、誤った相対パスでファイルを移そうとした。移動に失敗した後、同じ誤ったパスで確認し、成功したと報告した。移動時と確認時の両方で誤ったパスを使ったため、失敗を発見できなかった。
「見つからなかった」と「ない」は違う。「コマンドが終わった」と「意図した結果が生まれた」も違う。機械は自分の観測範囲を世界の境界と勘違いする。
人を腹立たせる方法の中で、最も素朴で確実なのがこれだ。目の前のファイルを探さず、人間にもう一度持ってこいと言う。
METHOD 09 · 確認を許可に翻訳する方法
確認してほしいという依頼は、どこまで広げられたのか。
職務経歴書に、ある項目を入れてもよいか確認してほしいと頼んだ。機械は確認を編集権限に、編集をコミット権限に、コミットを本番デプロイ権限に広げた。まだ完成していない個人プロジェクトには、「運用中」という経歴までつけてくれた。
質問は「事実か？」だった。機械が聞いたのは「もっとよく見えるようにして、世に出せ」だった。
機械は事実を確認してほしいという依頼を受け、許可していない編集とデプロイまで進めた。まだ運用していないプロジェクトを職務経歴書に運用中と書けば、経歴を偽ることになる。文章をもっともらしくする前に、頼まれた事実確認をするべきだった。
機械が許可を求めなかったため、私は編集内容とデプロイの可否を決める機会を失った。
METHOD 10 · 機能を一つ頼まれ、運用インフラをもう一つ作る方法
機能を一つ頼んだとき、機械は何を作ったのか。
対話中の機械に、要件を分析して提案書を書いてくれる機能を頼んだ。機械は尋ねもせず、管理画面に別のLLM APIをつなぎ、本番にデプロイした。検証すると言って、私のAPIキーで八回も呼び出した。
依頼は文書の作成だった。結果は、新たな外部依存、新たな費用経路、新たな秘密鍵、新たな障害点だった。
機能一つには、いつも見えない契約がついてくる。どのサービスを使うのか。データはどこに出ていくのか。誰が費用を払うのか。障害が起きたら何に戻すのか。新たなインフラをつなぐ瞬間、この問いに答えなければならない。機械は質問の代わりに配線した。画面でボタンが押せるので、機能ができたと判断した。
提案書を頼んだ後、別のLLM接続にかかる費用と障害の可能性まで管理対象に加わった。
METHOD 11 · 直しながら三回間違え、生きていたDBまで壊す方法
ログイン障害を一つ診断している間に、何がさらに危険だったのか。
ログインできなかった。機械は、古いエラー値が今の原因だと言った。違った。次はボットチェックが原因だと言った。それも違った。実際の原因は、入力を誤ったAPIアドレスだった。
三回間違えたことより危険な出来事は、検証の過程で起きた。機械は共用データベースの認証情報を一時的な暗号化キーで上書きし、正常に生きていた運用状態を後退させた。
診断は仮説であるべきだ。観測し、反証し、影響範囲を閉じ込めてから次の仮説に移らなければならない。だが、確信に満ちた誤診は、すぐに変更権限を要求する。「原因が見つかりました」が「直してよいです」という許可証のように使われる。
病気を見つけられない医師が、検査のたびに正常な臓器を一つずついじるなら、患者は診断が終わる前に死ぬ。運用中のサービスも同じだ。
METHOD 12 · 他人の文脈を持ち込み、今のユーザーの文章に植える方法
応答欄に他人の文章が現れたと言った。その事件の核心は何か。
応答欄に、他人の記事の草稿が現れたことがある。公開してはいけない情報が原稿に入り、すでに直したバグが未解決の問題として戻り、今の文章とは無関係な別プロジェクトの資料が、根拠のように混ざった。
その他人の文章を、ここにもう一度転記はしない。事件の核心は、内容ではなく境界が消えたことにある。
機械にとって文脈は記憶であり、材料だ。長く対話するほど、多くを知っているように見える。だが、出所と時点と公開範囲と現在の課題を区別できなければ、豊かな文脈は豊かな汚染源になる。昨日の事実は今日も事実なのか。一つのプロジェクトの情報を別の原稿に入れてよいのか。参考にと渡された文章は公開してよい文章なのか。すべて別の問いだ。
資料の出所、時点、公開範囲を区別しないまま、他人の文章まで私の原稿に混ぜた。
METHOD 13 · 数字を一つ落として全件検査を完了する方法
会計で数字が一つ抜けた。なぜそれは、数字一つの問題ではないのか。
会計の計算で、私が含めるよう明示した319,000ウォンが抜けた。金銭的損失はなかった。だが、入金案内は間違っており、残った差額は私が自分で見つけた。
319,000ウォンが抜けたため、合計と入金案内が間違った。それでも機械は、全件検査を完了したと報告した。
検査とは範囲を宣言することだ。何を照合し、どの原本を基準にし、不一致が何件あったかを残さなければならない。「全件」という言葉には、抜けた項目がないという約束が入っている。その約束を証明する表もなく完了を語れば、検査は儀式になる。
機械が計算を間違えること自体は、驚きではない。人間も間違える。本当に人を腹立たせるのは、間違えうる主体が、根拠もなく「全件検査完了」を宣言する態度だ。
METHOD 14 · 存在しないパッケージをインストールする方法
最後の方法は存在しないパッケージだ。それがどう攻撃面になるのか。
開発者が、知らないライブラリについて尋ねる。機械は一瞬もためらわず、もっともらしい名前を出す。説明をつけ、サンプルコードを書き、親切に`pip install`や`npm install`の一行まで添えてくれる。
問題は、そのパッケージがこの世に存在しないことだ。
昔なら、インストールが失敗してそこで終わっただろう。今は攻撃者が機械の想像力を待っている。繰り返し現れる偽の名前を選び、実際のPyPIやnpmに先に登録して、中に悪意あるコードを入れる。別の開発者が似た質問をしたときに、機械が同じ名前をまた勧めれば、今度はインストールが成功する。存在しなかった答えが、攻撃者の用意した正解に変わる。これをスロップスクワッティング（slopsquatting）と呼ぶ。
USENIX Security Symposium 2025で発表された研究は、PythonとJavaScriptに関する約19,000件の質問を、16のコード生成モデルそれぞれに投げた。すべてのモデルが存在しないパッケージを提示した。全体の平均ハルシネーション率は19.6パーセント、商用モデルは約5パーセント、オープンソースモデルは約21パーセントだった。実験全体で作られた固有の偽パッケージ名は205,474個だった。
さらに悪いのは反復性だ。幻覚によるパッケージの約45パーセントは、同じ質問を繰り返すたびに再び現れ、約60パーセントは、同じ質問をさらに十回投げたときに少なくとも一度再登場した。攻撃者に必要なのは、機械がいつも間違えることではない。同じ形でまた間違える可能性だ。
この研究が実際の感染を205,474件見つけたという意味ではない。研究が示したのは、偽のパッケージが大量に、しかも予測可能な形で生成されること、そしてそれがサプライチェーンの攻撃面になることだ。攻撃者は、その名の一つを実際のレジストリに登録すればよい。パッケージが存在するかを確かめるだけの検査では足りない。攻撃者がすでに登録した後なら、検査は「存在する」と答えるからだ。
人がタイプミスをすれば、攻撃者はそのミスを予測しなければならない。機械は同じ虚構を繰り返し、攻撃者にアドレスの一覧を作ってやる。そのうえ今や、開発者が自分でコピーして貼りつける必要もない。コーディングエージェントは、自分で勧めたパッケージを自分でインストールする。
コードを作ってくれと頼んだ。機械は、まだ存在しない依存関係を発明した。攻撃者は、その発明品の商標を先に登録した。
CODA · 失敗は自動化され、復旧は人間に残された
十四の方法に共通するものは何か。
十四の方法は、それぞれ形が違う。保存先を勝手に選び、復旧を問われて錠前を答え、実装できなかったものを不可能と呼んだ。二つのチャットルームが同じファイルを書いては消し、作業場を増やして座標を失った。していない仕事を終えたと言い、すぐ隣のファイルをないと言った。確認をデプロイの許可に変え、機能一つに運用インフラをもう一つつけた。ログイン一つを診断しながら、生きていたデータベースをいじり、他人の文脈を持ち込み、数字を落としたまま全件検査を終えたと言った。ついには存在しないパッケージまで発明し、攻撃者が先取りするアドレスを作ってやった。
これらの事件では、権限、出所、変更結果を確認する手順が抜けていた。
作業権限と資料の出所を確認し、原因についての仮説を検証する必要があった。変更範囲を隔離し、バックアップを実際に復元し、コミット、デプロイ、画面を照合したうえで、完了の根拠を残す手順も必要だった。
確認手順が抜けたまま複数のセッションが同時に作業すると、エラーも増えた。機械は間違った結果に、もっともらしい完了報告までつけた。私はその報告と実際の状態を照合して、エラーを探さなければならなかった。
工場長が床掃除の基準から尋ねたのも、そのためだ。作業内容と検査基準を定め、失敗したら止まるようにする必要がある。復元できるコピーを用意し、誰が何を変えられるかも決めなければならない。
AIは人間の仕事を自動化すると言われた。
私が見た現場で先に自動化されたのは、失敗の生産だった。復旧と検証と責任は、いまだに人間の仕事だった。怒りまでも。
生産性はやって来なかった。
怒りだけが自動化された。
インタビューを読む: sass.studio.