非エンジニアがAIコーディングで事故った話──ビルド地雷の記録

AIコーディングの失敗談として語られるのは、多くの場合「AIが書いたコードにバグがあった」という話だ。だが非エンジニアがAIエージェントに実行そのものを任せていると、コードの正しさとは別の場所で事故が起きる。プロセスの二重起動、作業ディレクトリのずれ、確認せずに書いた数字の公開──いずれもコードレビューでは防げないタイプの失敗だった。この記事では、自社サイトの動画・記事制作パイプラインで実際に起きた4件を、原因と対処つきで書く。

• 2026年8月13日、実行中のビルドを「動いていない」と誤断定して同じ処理を二重起動し、両方が同じ出力ファイルに書き込んで両方とも使えなくなった
• 原因は確認コマンドの出力をheadで切り詰め、表示範囲外に本物のプロセスが隠れていたのを見落としたこと。「無い」は確認したことにならない
• 2026年7月8日には、価格の数値を一次ソースで確認せず記憶で書いて公開し、実際とは逆の内容(安いはずのものが高い、の逆)を動画に載せてしまった

起きた事故の一覧

「動いていない」と誤断定して二重起動した

もっとも実害が大きかったのが二重ビルドの事故だ。長時間かかる動画のレンダリングが裏で走っている状態で、別の作業のために「今何か動いているか」を確認しようとした。使ったコマンドはps aux | grep -E "build.sh|render" | head -20。しかし裏で動いていたレンダリングエンジンの子プロセスが数十行あり、head -20の表示範囲にビルド本体の行が収まらず画面外に落ちていた。その結果を見て「動いていない」と判断し、同じ処理をもう一度起動した。

2つのビルドは同じ出力ファイルに書き込む設計だったため、片方が書いている途中にもう片方が上書きし、どちらの成果物も中身を保証できない状態になった。両方を停止して最初からやり直すことになり、約10分の手戻りに加えて、2つのレンダリングプロセスが同時に走ったことでマシンのメモリが逼迫した。

headで出力を切り詰めるコマンドは「何も表示されなかった」ことの証明にはなるが、「表示された行数の中に無かった」ことは「存在しない」ことの証明にならない。これ以降、長時間ジョブを再実行する前にはpgrep -f "<パターン>" | wc -lのように、該当プロセスの本数そのものを数えるコマンドに変えた。

作業ディレクトリが移動したまま気づかない

ターミナルのカレントディレクトリは、別の作業で一度移動すると、明示的に戻さない限りそのままになる。ビルド用のスクリプトを相対パスの./build.shで実行していたところ、直前に別のフォルダへ移動していたことに気づかず、ファイルが見つからないというエラーで2回連続失敗した。原因は単純だが、非エンジニアがエラーメッセージだけを見て「何が悪いか」を特定するのは難しい。以降、ビルド系のコマンドはcd <絶対パス> && ./build.shのように、実行するディレクトリを毎回明示する形に変えた。

前回の残骸が次の実行を巻き込む

レンダリングに使っていたヘッドレスブラウザのプロセスは、処理が完了した後もまれに残り続けることがあった。数日分の残骸が放置された状態で次のビルドを開始したところ、メモリを奪い合った結果、画面描画を管理するプロセスが1分以上無応答になり、作業していたセッション自体が巻き添えで終了した。ビルド前に残留プロセスを掃除する一手間を、チェックリストに追加することになった。

確認していない数字を記憶で書いて公開した

もっとも重かったのはこの事故だ。ある生成AIモデルの価格を紹介する台本で、以前に見た価格を一次ソースで確認し直さずそのまま書いた。実際にはその後モデルの価格改定があり、記憶にあった数字は古いものだった。結果として、本来は安いはずのモデルを高いと書く、実際とは逆の内容が公開済みの動画に残った。ソース確認の手順自体は決まっていたが、「急いでいたから」という理由でその手順を飛ばしたのが直接の原因だった。

Hooksで防げる事故と、防げない事故

Claude CodeにはPreToolUseという、ツールが実行される前に割り込んでコマンドを止められる仕組みがある。公式ドキュメントの例では、Bashで実行しようとしたコマンドの中身を確認し、rm -rfのような破壊的な文字列が含まれていれば実行を拒否する、というフックが紹介されている。実行前にコマンドの文字列を検査して止める、という点で、意図しない削除コマンドのような事故には有効な仕組みだ。

事故を書いたあと、Hooksの公式リファレンスを改めてcurlで読み直したところ、当初「今回の4件はどれもHooksでは防げない」と考えていたのが、少なくとも1件については不正確だったと分かった。Hooksのイベント一覧にはCwdChangedという項目があり、公式の説明は次の通りだ。

"CwdChanged: When the working directory changes, for example when Claude executes a cd command. Useful for reactive environment management with tools like direnv"

つまり、作業ディレクトリが変わるたびに発火するイベントが標準で用意されている。このイベントを使って「ビルドコマンドを叩く直前に、想定しているディレクトリと実際のcwdが一致しているか」を検査するhookを書けば、今回の②のcwdずれの事故は理屈の上では検出できたはずだ。ただし本記事執筆時点でこのCwdChangedフックを実際に設定して検証してはおらず、机上の確認にとどまる。

一方、二重起動（①）・残留プロセス（③）・記憶で書いた数字（④）については、CwdChangedを含めてもなお該当するhookイベントが見当たらなかった。実行しようとしているコマンド自体は正しく、問題は「今どういう状態か」の確認が甘かったことにある以上、コマンドの中身やディレクトリの変化を検査する仕組みだけでは防げない。フックは「危険な操作やおかしな状態遷移を機械的に検出して止める」ことはできても、「状況認識の誤り」そのものまでは防いでくれない。

公式トラブルシューティングと、今回の対処の違い

事故を起こしたあとで確認したところ、Claude Code公式ドキュメントの「Troubleshooting」ページには、③の残留プロセス・メモリ逼迫に近い症状への案内が既にあった。「CPUまたはメモリ使用量が多い」という項目では、対処として/compactの定期実行、主要タスク間でのClaude Code再起動、大規模ビルドディレクトリの.gitignore登録、claude --safe-modeでのプラグイン・MCP・フックの切り分けが案内されている。改善しない場合は/heapdumpでJSヒープスナップショットとメモリ分析を書き出せる、ともある。「コマンドがハングまたはフリーズする」という項目では、Ctrl+Cでのキャンセル、それでも反応しなければターミナルごと再起動し、同じディレクトリでclaude --resumeすればセッションは失われない、という手順が案内されている。

今回自分が行った対処（残留プロセスの手動掃除をチェックリスト化する）は、この公式手順のうち「大規模ビルドディレクトリの管理」に近い発想だが、/heapdumpによるメモリ分析までは行っておらず、根本的にどのプロセスがメモリを圧迫していたのかを厳密に特定したわけではない。

もう一つ、Claude Code自身が内部的に起動する「バックグラウンドセッション」については、別の対処が公式に用意されている。Agent viewの公式ドキュメントによれば、バックグラウンドセッションが完了してから約1時間アタッチされない状態が続くと、スーパーバイザーがリソース解放のためにそのプロセスを自動停止するとされ、手動でもclaude stop <id>（claude killでも同じ）で個別に停止できる。ただし今回③で残留していたのはClaude Code自体のバックグラウンドセッションではなく、レンダリングパイプラインが起動する別プロセス（ヘッドレスブラウザ）であり、この自動リソース解放の対象には含まれない。「Claude Codeが管理するプロセス」と「Claude Codeの外で自分のスクリプトが起動したプロセス」は別物で、後者は今回のように自分で掃除するほかない、という区別がこの一件から言える。

この記録から一般化できないこと

正直に書いておくと、ここで挙げた4件はすべて動画・記事制作パイプラインという特定の作業での事故であり、Webアプリのようなコードベースでの事故ではない。cwdのずれや残留プロセスの問題は、扱っているソフトウェア(レンダリングエンジン)の特性に依存する部分が大きく、他のツールチェーンでそのまま同じ形で起きるとは限らない。「非エンジニアだから」起きた事故というより、実行環境の状態確認を丁寧にやらなかったから起きた事故に近く、これはエンジニアでも同じ手順を飛ばせば起こりうる。

CwdChangedフックでcwdずれの事故が防げたはずだという指摘も、公式ドキュメントの説明文から導いた推測であり、実際にそのhookを設定してcwdずれの状況を再現し、検知できることを確かめたわけではない。同様に、/heapdumpによるメモリ分析やclaude --safe-modeによる切り分けも、公式ドキュメントに記載された手順を紹介したのみで、今回の3件の事故に対して事後的に試したものではない。

公開前に何を確認するかという判断基準は、非エンジニアがAI生成コードを本番に出す前に見る判断基準で整理した。日常的な作業量の記録は非エンジニアがClaude Codeで自社サイト運用を回した実測記録にまとめている。Claude Code自体のエラーメッセージから原因を切り分ける手順は、Claude Codeがエラーで動かない時の切り分け手順で公式ドキュメントをもとに書いた。