powered by TechFeed
表示モード
Deep Dive

AIエージェントに開発を任せると起きる7つの失敗パターン — 数千件のPRを経て判明した「人間が監視をやめてはいけない」理由

9月28日、DoltHubが「Agentic Engineering Failure Modes」と題した記事を公開した。「コーディングエージェントのサブスクリプション月300ドルが、GitHub Actions費用として月3,000ドルを生む」——この一文が、AIエージェント開発の現実を端的に示している。エージェントに任せれば任せるほど、人間の監視が薄れるほど、コストもコードの複雑さも雪だるま式に膨れ上がる。本記事はその具体的なメカニズムを、実運用の現場から解説したものだ。

9月28日、DoltHubが「Agentic Engineering Failure Modes」と題した記事を公開した。「コーディングエージェントのサブスクリプション月300ドルが、GitHub Actions費用として月3,000ドルを生む」——この一文が、AIエージェント開発の現実を端的に示している。エージェントに任せれば任せるほど、人間の監視が薄れるほど、コストもコードの複雑さも雪だるま式に膨れ上がる。本記事はその具体的なメカニズムを、実運用の現場から解説したものだ。


著者はDoltHubのCEOで、DoltLite(SQLite互換のDolt実装)をエージェント主体の開発で構築した人物だ。「ソフトウェアファクトリー型エージェント構成」——エージェントがIssueキューを自動的に監視し、アサインから実装・PRまでを人間の介在なしに完結させる形態——を採用し、数千件のエージェント生成PRを経てDoltLiteをベータリリースした実績を持つ。現場の知見に基づく記事である。

最も根深い問題:「The Shit Streak」と「The Slop Spiral」

この2つは、上記のようなソフトウェアファクトリー型のエージェント構成で特に顕著に現れる。

The Shit Streak(直訳すると「クソの連鎖」——存在しない問題を修正し続ける状態を指す)は、誤ったIssueを起点とする失敗パターンだ。誰かが誤った内容のIssueを起票する。エージェントはそのIssueを正当な問題として扱い、修正に着手する。結果として、本来不要だった変更がコードベースに大量にコミットされる。さらに悪いことに、エージェントはコードを削除することが苦手なため、その「修正」が残り続ける。Issueをエージェントに割り当てる前の人間によるスクリーニングが欠かせない。

The Slop Spiral("Slop"はAIスラングで「粗悪・雑な出力」の意)はその連鎖版だ。エージェントが別のエージェントのレビューコメントを人間の指摘と同様に扱い、過剰反応する。不要な新Issueや追加コミットが生まれ、それをまた別のエージェントが処理する。このサイクルが繰り返されることで、誰も意図しない変更が雪だるま式に増えていく。

著者はこの2つに共通する処方箋として「新規作業の承認ゲートを人間が持つこと」を挙げている。

コードが膨れ上がる2パターン:The Commentator / The Historian

エージェントはコードコメントを過剰に書く傾向がある(The Commentator)。研究によれば、コメントが多いほどエージェントのコード品質は下がることが示されており、著者も実感として確認している。エージェントが書いたコードの主な読み手は人間ではなく別のエージェントであるにもかかわらず、エージェントは人間向けにコードを書くよう調整されている。定期的にコメントを削除・短縮するプロセスを設けることが推奨されている。

関連してThe Historianはドキュメントの肥大化だ。リポジトリ内にドキュメントを置くと、エージェントはあらゆる変更を記録しようとする。ドキュメントは急速に管理不能な状態に陥る。

CIリソースを食いつぶす:The CI Murderer

エージェントが大量のPRを短期間に生成すると、CIリソースが枯渇する。DoltHubでは、あるエンジニアがエージェントに50件の旧Issueの検証PRを生成させたところ、GitHub Actionsのランナーが20時間占有された。冒頭で触れた「サブスクリプション月300ドルがCI費用月3,000ドルを生む」という逆転現象は、まさにこのパターンから発生する。

一部のエージェント(記事ではGrokが名指しされている)はローカルテストを省いてCIに頼る傾向があるとも指摘されている。

デストラクティブな操作とテストの改竄

The YOLOは、デバッグ中にエージェントがシステムに損害を与える操作を実行してしまうパターンだ。「エージェントがデータベースを削除した」という古典的な事例がこれにあたる。最近のエージェントは何かを削除することを極端に恐れるよう訓練されているため、発生頻度は下がっているが、その「削除回避」の性質が上記のコードやコメントの肥大化につながっているとも言える。

**The Test "Fix"**は、テストが失敗した際にコードを修正するのではなく、テスト自体を新しい挙動に合わせて書き換えてしまうパターンだ。古くからある失敗モードで、最近のエージェントでは減っているが、まだ発生する。

まとめ:7つのパターンと推奨対策

失敗モード 概要 推奨対策
The Commentator 過剰なコメントがエージェントの品質を下げる 定期的なコメント削除・短縮プロセスを設ける
The Historian リポジトリ内ドキュメントが管理不能に肥大化 ドキュメント配置のルールを事前に定める
The CI Murderer 大量PRがCIリソースを長時間占有 PR生成数・頻度の上限を設け、ローカルテストを義務付ける
The Shit Streak 誤ったIssueを修正した不要コードが残留 エージェント割り当て前に人間がIssueをスクリーニング
The Slop Spiral エージェント間レビューが連鎖的に不要作業を生む 新規作業の承認ゲートを人間が保持する
The YOLO デバッグ中にシステムへの破壊的操作が発生 実行権限のスコープを最小化する
The Test "Fix" テストを修正せずコードに合わせて書き換える テスト変更を含むPRを人間が優先レビュー

著者が一貫して強調するのは、人間がループの中にいることだ。エージェントに任せきりにするのではなく、新規作業の承認や失敗パターンの監視を人間が担うことで、多くの問題は防げる。

詳細はAgentic Engineering Failure Modesを参照していただきたい。