概要
https://bitmovin.com/blog/hackathon-debugging-ai-tools-llms/
詳細内容
## 二つのAIの失敗談：LLMで簡単なバグをデバッグする
https://bitmovin.com/blog/hackathon-debugging-ai-tools-llms/
**Original Title**: A Tale of Two AI Failures: Debugging a Simple Bug with LLMs
AIコーディングツールが微妙なAPIバグのデバッグに苦戦し、異なる失敗モード（沈黙の固執と自信に満ちた幻覚）を露呈させ、人間によるデバッグの優位性を浮き彫りにする。
**Content Type**: ⚙️ Tools
**Language**: en
**Scores**: Signal:4/5 | Depth:4/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:5/5
**Main Journal**: 88/100 | **Annex Potential**: 87/100 | **Overall**: 88/100
**Topics**: [[AIデバッグ, LLMの限界, API連携, コーディングアシスタント, 開発ワークフロー]]
Bitmovinのエンジニアリング担当SVPであるステファン・グルーバー氏は、社内ハッカソンでAPI統合を試みた際に、AIコーディングアシスタント（CursorとClaude）が簡単なバグで失敗した事例を紹介しています。彼の目標は、太陽光発電データを返すAPIと連携することでしたが、標準的なHMAC-SHA256ハッシュ関数を使用してリクエストの署名を生成するプロセスで、予期せぬ困難に直面しました。
問題の核心は、HTTPメソッド、APIパス、認証トークン、タイムスタンプ、JSONリクエストボディを連結して署名文字列を作成する際の、微妙な文字列フォーマット要件にありました。APIドキュメントでは、これらの要素を改行文字（`\n`）で連結するよう指定されていましたが、実際には`\n`を単なる連結演算子としてではなく、文字列リテラルとして構造内に含める必要があったのです。
最初に試したAIエディタであるCursorは、問題の箇所を特定できたものの、入力文字列の構築方法を根本的に疑うことができませんでした。何時間ものデバッグセッションを通じて、Cursorはエンコーディングやハッシュライブラリの変更といった定型的な修正案を繰り返し提案し、論理的な行き止まりに陥り、沈黙のうちに同じ「不正な署名」エラーを吐き続けました。
次に試したClaudeは、より会話的で助けになるように感じられましたが、その出力はさらに誤解を招くものでした。基本的な文字列連結のバグを見逃しただけでなく、エラーメッセージに自信満々に「システムクロックが1年進んでいる」という全くの誤った診断を下し、デバッグの時間を無駄にさせました。これは、Claudeが実際のコードの問題に対処する代わりに、もっともらしいが虚偽のシステムレベルの問題を幻覚した「最高レベルの誤誘導」でした。
著者はこの経験から、AIアシスタントを使用したコーディングにおける重要な教訓を導き出しています。LLMは強力なパターンマッチングシステムであるため、一般的なパターン（例: `string + "\n" + string`）が、特定のAPIの厳密な要件に合わない場合、両モデルが同じ間違いを繰り返す傾向があることを指摘しています。AIは複雑なハッシュ処理はこなせるものの、ドキュメントを批判的に読み解き、バイトレベルの正確さで文字列構造をマスターする能力を欠いていると主張します。微妙なコンテキストを持つ非標準的なコーディングにおいて、`print(signature_string)`のような基本的なデバッグ手法を駆使する人間開発者の方が、依然として優れたデバッガーであるという結論に至っています。