個人開発でAIエージェントに運用を任せて起きたヒヤリ事例

個人開発でAIコーディングエージェントにツール呼び出しや運用を任せると、便利な反面「壊れたことに気づかない」形で失敗が起きることがある。攻撃者に狙われるような派手なセキュリティ事故ではなく、認証やプロセス管理といった地味な場所で、エラーが静かに積み重なっていた記録を、実際に自分の運用で起きた2つの事例から振り返る。どちらも当サイトの別記事で詳しく記録済みのものを、この記事では「個人開発者が気づきにくいリスクのパターン」として要約し直す。同じように「自動化した工程の中に人間の確認が必要だった」という話は、AIで作ったゲームキャラクターの取り違えを記録した個人開発でAIとゲームを作って詰まったところにもある。

3行まとめ

1. Google認証のリフレッシュトークンが失効し、YouTube統計ツールの呼び出し74件が全部同じエラーで失敗し続けていたのに、少なくとも29日間気づかなかった
2. 長時間レンダリングを止めるために打ったpkillコマンドが、実は1本もプロセスを殺せておらず、エラーも出さずに終了コード1を返すだけだった
3. 2つに共通していたのは、コマンドやAPI呼び出しが「失敗した時に何も言わずに失敗する」場面だったこと。個人開発では、この手の沈黙する失敗に気づく仕組みを自分で作る必要がある

事例1: 認証トークンが29日間死んでいたのに気づかなかった

YouTube Data APIを使ったツールをMCP経由でClaude Codeから呼び出す運用をしていたところ、ある時期から呼び出しがすべてinvalid_grant: Bad Requestという同じ1行のエラーを返すようになっていた。このエラー文字列は失敗の理由を1つも教えてくれない。トークンが失効したのか、リクエストの組み立てが悪いのか、クライアントIDが違うのか、文面からは区別できない。

原因の手がかりになったのは、トークンを保存しているファイルの更新時刻だった。認証ライブラリの典型的な実装は「リフレッシュに成功した時だけ」トークンファイルを書き戻すため、ファイルの更新時刻が「最後に認証が通った瞬間」を指す。手元に残っていたClaude Codeのやり取りの記録を数えると、2026年7月16日から8月14日までの間に74回このツールを呼び出しており、そのすべてが失敗していた。つまり、少なくとも29日間、このツールは1回も成功していなかったことになる。

これに気づけなかった理由は単純で、エラーが出ても「なぜか失敗する」程度の認識で終わっていて、失敗が続いている期間そのものを数えて確認する習慣がなかったからだ。個人開発で自動化ツールをAIエージェント経由で回している場合、こうした「呼び出すたびに同じエラーで静かに失敗し続ける」状態は、意識して過去のログを見返さない限り気づけない。

事例2: 止めたつもりのプロセスが生き残っていた

長時間かかる動画レンダリング処理をpkill render.mjsで止めようとしたところ、実際にはプロセスが1本も死んでいなかった。macOSのpkillは既定でプロセス「名」だけを見て一致判定をするため、node render.mjsというコマンドで起動したプロセスの名前はnodeであり、スクリプトファイル名のrender.mjsはどこにも一致しない。そして一致しなかったpkillは、エラーメッセージを出さずに終了コード1を返すだけで終わる。

この結果、止まっていないレンダリングプロセスが生き残ったまま次のビルドを開始し、同じ出力ファイルに書き込みが競合する形になった。実測では、孤児化したレンダ用プロセス（chrome-headless-shell）が36個残っていたことが確認されており、これがmacOSの画面描画を管理するWindowServerを73秒間無応答にした。加えて、ps aux | grep ... | head -20で出力を確認して「もう走っていない」と判断し、実際には走っていたプロセスの上に新しいビルドを重ねて始めてしまい、約10分の作業時間を失う二重ビルドも起きている。

直し方自体はシンプルで、pkillのパターンを-f付き（コマンドライン全体に一致させる）にすることと、kill実行後に必ずpgrep -f "パターン" | wc -lで残数が0であることを確認することだった。問題は直し方の単純さではなく、「一致0件で何も殺せなかった」場合と「もともと走っていなかった」場合が、pkillの出力上まったく見分けがつかないという点にあった。

2つの事例を数字で並べる

元記事に残っている実測値を、発生から発覚・対処までの流れで並べ直すと次のようになる。

（表の数値は元記事2本（Google認証トークン編・pkill編）に実測値として記録済みのものを転記。この記事のために新たに計測した数値はない。）

2つに共通していたパターン

この2つの事例は、一見すると全く別の技術領域の話だが、共通点がある。どちらも、AIエージェント自体が何か危険な操作を実行したわけではなく、正当なコマンドやAPI呼び出しが、失敗した時に何のシグナルも出さずに沈黙するという場面で起きていた。Claude Codeの公式ドキュメントが説明している権限システムやサンドボックスは、AIが意図しない操作を実行することを防ぐための仕組みであり、「ユーザーが打ったコマンド自体が期待通りに動いていない」ことまでは検知してくれない。公式ドキュメントも次のように明記している。

Claude Code only has the permissions you grant it. You're responsible for reviewing proposed code and commands for safety before approval.

権限の範囲内で実行された操作が「成功したように見えて実は失敗している」場合、それを見つけるのは結局、個人開発者自身が結果を確認する習慣を持つかどうかにかかっている。今回の2つの事例では、それぞれ「トークンファイルの更新時刻を見る」「pgrepで残存プロセス数を数える」という、実行後に必ず数値で確認する一手間が、事故の再発防止策になった。AIに運用の実行そのものを任せることと、その結果が本当に成功したかを確認することは別の作業で、後者を省略すると、今回のように何週間も気づかない形で失敗が積み重なる。

個人開発で実際に変えたこと

この2つの事例の後、運用のやり方を2点変えた。1つは、定期的に動かしているツールについて「最後に成功したのはいつか」を月に一度は見返す習慣を作ったことだ。認証トークンの事例では、成功時にしか更新されないファイルの更新時刻さえ確認していれば、29日間ではなくもっと早い段階で異常に気づけたはずだった。もう1つは、プロセスを止めるコマンドを打った後、必ずpgrepなどで実際に0件になったかを数値で確認するようにしたことだ。「コマンドを打った」ことと「意図通りの結果になった」ことは別で、後者を確認する一手間を省くと、個人開発では気づく人間が自分しかいない分、失敗が長く放置されやすい。

Claude Codeの認証エラー全般の切り分け方は、Claude Codeがエラーで動かない時の切り分け手順にまとめている。当サイト自身も過去に設定ファイルの書き換えで認証が401ループに陥る事故を起こしており、あわせて参考にしてほしい。個々の事例の実測値やコマンドの詳細は、それぞれの元記事（Google認証トークン編、pkill編）に譲る。

invalid_grantの根本原因は、元記事の時点でも特定できていない

この記事は2本の元記事を要約したものなので、元記事自体が明記している未確定点をそのまま引き継いでおく。

• 事例1のリフレッシュトークン失効の根本原因は、6つの候補（ユーザーによる取り消し／付与済みトークンの上限超過／時間制限付きアクセスの期限切れ／管理者設定のセッション長超過／同意画面Testingの7日失効／1クライアントIDあたり100本上限）のうちどれなのか、元記事の時点でも判定されていない。 トークンファイルの作成〜最終更新が6日18時間48分55秒と7日ルールに近いが、その最終更新自体が「リフレッシュ成功による書き戻し」なのか「別スクリプトによる新規保存」なのかを区別できておらず、断定はしていない。
• 事例2のpkillについて、man pageに書かれている「-fなしで19文字を超える名前は黙って失敗する」という挙動は、元記事の検証環境（macOS 15.1.1）では再現できなかった。 36文字のプロセス名でも-fなしで一致するケースがあり、条件を特定できないままになっている。
• 事例2の「孤児36個」「WindowServer 73秒無応答」「約35分の損失」「約10分の損失」といった数字は、いずれも発生当時の作業記録からの転記であり、この記事のために再測定したものではない。 事故の再現になるため、再測定はできない。
• どちらの事例も、筆者自身の個人開発環境（macOS、Claude Code経由の運用）で起きたものであり、他の環境・他のツール構成で同じ頻度・同じ実害が起きるとは限らない。 一般化できる主張は「失敗が沈黙する場面がある」という構造の部分だけで、具体的な数字（29日、74件、36個など）は再現性を主張するものではない。