AIパイプラインを2日間壊し続けて学んだこと ─ Claude CodeとMem0統合のデバッグ奮闘記

お知らせ

毎朝5時に自動実行されるAIリサーチパイプラインに新機能を追加したところ、2日間にわたる障害が発生。9コミットを巻き戻し、シンボリックリンクの競合状態まで踏み抜いた著者が、「AIにもデバッグの認知バイアスがある」という核心的な気づきを得るまでの実録レポートです。Claude CodeとOpus/Sonnetの役割分担、Mem0 MCP連携、そして人間とAIのデバッグ協業の実態が赤裸々に語られています。

この記事のポイント

  • Mem0 MCP統合とOpus 2パスモードを同時に実装し、障害の原因が複合化して切り分け困難に
  • AIデバッグアシスタントには「最近変更したコードを疑いやすい」という認知バイアスがある
  • 人間とAIのデバッグにおける役割分担を明確にすることで、効率的な問題解決が可能になる

2つの機能を同時に追加した代償

著者は以前の記事で、エージェントチーム方式（Opusをオーケストレーター、サブエージェントで並列リサーチ）を評価し、「Opusの真価はトピック選定に集中している」という結論に至っていました。この知見をもとに、2つの機能を同時に実装します。

1つ目はMem0 MCP統合。Mem0はAIアプリケーション向けの永続メモリサービスで、Claude CodeはMCP（Model Context Protocol）経由で外部ツールを接続できます。.mcp.jsonにサーバー設定を定義すれば、claude起動時に自動接続されます。目的は「先週このトピックを深掘りしたから今日はその続きを」「この領域は3回連続で選んでいるので優先度を下げよう」といった、セマンティックレベルでのセッション間コンテキスト引き継ぎでした。

2つ目はOpus 2パストピック選定。Opusがトピック選定のみを担当し、Sonnetがリサーチを実行する分業方式です。個別には合理的な拡張でしたが、問題は同時に実装したことでした。5回の失敗と9コミットの巻き戻しを経験することになります。

Day 1：複合障害との格闘

2パスモードを実装して手動実行するとハング。修正して再実行、再びハング。MCPフォールバックコードを追加するもSSH切断でドロップ。同じターミナルで再実行するとclaude -pがサスペンド。3回目の試行時点で、何をデバッグしているのかすら見失っていました。

claude -pがハングした時、複数の原因候補が同時に存在していました。Mem0 MCPサーバーが初期化時にタイムアウトしているのか？Opusが単に遅いだけなのか？非インタラクティブモード特有の問題なのか？Mem0 MCPサーバーはインタラクティブセッションでは正常に動作するのに、非インタラクティブ実行では無限にハングするという厄介な挙動を示しました。さらに本番環境（launchd）では最小限のPATHしかないため、MCP初期化が即座に失敗するという別の障害モードも発生しました。

Day 2：シンボリックリンクの競合状態

翌朝5時、パイプラインがENOENTエラーでクラッシュします。「gtimeout: failed to run command ‘claude’: No such file or directory」。調査の結果、Claude Codeの自動アップデートプロセスがスクリプト実行中にシンボリックリンクを書き換えていたことが判明しました。これはDay 1の問題とは全く別の、タイミングに依存する競合状態でした。

AIにもデバッグの認知バイアスがある

この記事の最も重要な洞察は、AIデバッグアシスタントにも認知バイアスが存在するという発見です。具体的には、Claude Codeは実際の障害状況に注目するよりも、最近変更されたコードを優先的に調査する傾向がありました。

著者は、人間の介入が決定的だった3つの場面を特定しています。

  1. 無関係なデータのフィルタリング ─ Day 1の障害履歴からDay 2の問題に関係ない情報を除外する判断
  2. 不要な修正の認識 ─ AIが提案したWebSearchスロットリングが実際には不要だと見抜くこと
  3. 過剰な防御策の排除 ─ AIが追加しようとした過保護なガードレールを取り除くこと

人間とAIのデバッグ役割分担

2日間の奮闘から、明確なデバッグパートナーシップの枠組みが浮かび上がりました。

AIの強み：
– 大量のデータ処理と仮説生成
– 修正コードの迅速な実装
– 網羅的なテストケースの作成

人間の強み：
– 関連データと無関連データの判別
– 調査範囲の絞り込み
– 不要な修正の排除と方向修正

つまり、AIは「広く・速く」、人間は「狭く・正確に」という補完関係です。AIに全てを任せるのではなく、人間が適切にフォーカスを与えることで、デバッグの効率が劇的に向上します。

最終的な4つの修正

システムを安定化させた最終修正は以下の4つです。

  1. claudeコマンドのパス解決キャッシュ ─ シンボリックリンク競合を回避
  2. Opus障害時のSonnetフォールバック復元 ─ 単一障害点の排除
  3. gtimeoutの廃止とターン数制限への切り替え ─ 外部コマンド依存の排除
  4. 28件のE2E自動テスト追加 ─ 回帰防止

最終的なパイプラインのコストは1回あたり$1.76で、Opusトピック選定を追加しながらも以前と同等のコストを維持しました。

知っておくと便利なTips

  • 新機能は1つずつ追加し、複合障害を防ぐ。同時実装は障害の切り分けを困難にする
  • AIデバッグアシスタントの提案を鵜呑みにせず、人間が「何が関係ないか」を判断する役割を担う
  • 非インタラクティブ実行（cron/launchd）ではMCPサーバーの挙動がインタラクティブと異なることに注意
  • claude -pの本番運用では、外部タイムアウトコマンドよりもターン数制限が安定する

まとめ

本記事は、AIパイプラインの機能追加で2日間の障害を経験した実録デバッグ記です。技術的にはMem0 MCP統合のハング問題やシンボリックリンク競合状態の解決が語られていますが、真の価値は「AIにもデバッグの認知バイアスがある」という発見にあります。AIは最近変更されたコードに注目しがちで、人間が適切にフォーカスを絞ることで初めて効率的なデバッグが成立します。Claude Codeを日常的に使う開発者にとって、AIとの協業の「型」を知る貴重な事例と言えるでしょう。

📎 元記事: https://dev.to/shimo4228/what-i-learned-from-breaking-my-ai-pipeline-for-two-days-straight-pol

コメント

タイトルとURLをコピーしました