AIデバッグとは
1947年9月9日、ハーバード大学のMark IIコンピューターのエンジニアたちは、リレーの一つに蛾が入り込んでいるのを発見し、それをログブックに貼り付け、「バグ発見の最初の実例」と記録しました。そのページは現在、スミソニアン博物館に所蔵されています1。Mark IIチームのコンピューター科学者であるグレース・ホッパー氏がこの話を広めましたが、「バグ」という用語自体は彼女以前から存在していました。トーマス・エジソンは1878年の手紙で「バグ」について言及しており、オックスフォード英語辞典では、この工学用語の使用は1870年代から1880年代にさかのぼるとされています2。
エンジニアリングにおけるバグは、通常3つの種類に分類されます3。構文エラーは、プログラミング言語の文法上の誤り（例えば、かっこが不足している場合など）であり、プログラムの実行前に検出されます。ランタイム・エラーは、有効なコードであっても、実行中に失敗した場合に発生します（ゼロ除算など）。ロジック・エラーは最も見つけにくく、プログラムは正常に実行されても、誤った結果を返します。
開発者は、期待される結果に照らしてコードの各部分を検証する単体テストなどの自動テストや、実行中のプログラムを一時停止して調査できるデバッガーを利用して、これらの問題に対処できます。ブレークポイント（実行を停止する位置を示す目印）を設定すると、開発者はプログラムをステップ実行しながら変数を確認できます。Pythonに組み込まれているpdbは、その代表的な例です。プログラムがクラッシュすると通常はスタック・トレースが生成され、エラーに至るまでの関数呼び出しが記録されます4。
2013年のケンブリッジ・ジャッジ・ビジネススクールの調査によると、開発者はプログラミング時間の平均半分をバグの発見と修正に費やしており、世界全体で年間約3,120億ドルの費用がかかっていると推定されています5。もちろん、AI支援デバッグに期待されるのは、そのコストを削減することです。
The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。本ニュースレターは【日本語】で配信しています。登録の際はIBMプライバシー・ステートメントをご覧ください。
LLMとは、膨大な量のテキストとコードを学習し、次の「トークン」（単語、単語の一部、または記号）を予測する機械学習システムです。これは、ChatGPTやClaudeなどのAIチャットボットを支える自然言語処理テクノロジーと同じものです。トレーニングでは、数十億行に及ぶ公開コードに加え、それに関連するエラー・メッセージ、バグ・レポート、修正内容を実質的に「読み込んで」います。LLMが市場に投入される頃には、何百万件ものバグとその解決方法を学習している可能性があります。
公開されているコードの学習データには、GitHubの「Issue」や「プルリクエスト」でのやり取りも含まれています。これらは、開発者がバグや修正内容を報告する記録であり、特別に学習されたモデルは、人間の開発者が壊れたコードをどのように修正していくかという履歴を参照できます。
一般的なAIデバッグのワークフローでは、開発者は関連するコードとエラー・メッセージまたはスタックトレースをモデルに提供します。その後、モデルは考えられる原因を説明し、修正候補を提案します。ChatDBGなどの研究システムはさらに一歩進み、LLMをGDB、LLDB、Pythonのpdbなどの標準的なデバッガーと連携させることで、モデルが実行中のプログラムを調査し、根本原因を分析して修正候補を提案する一方で、開発者は「なぜxはnullなのか」のような自然な言葉で質問できるようにしています。6
AIデバッグを初めて利用する人が知っておくべき制限がいくつかあります。まず、コンテキストが重要です。これはプロンプト・エンジニアリングに関連する考え方です。曖昧なプロンプトでは曖昧な診断結果になりがちです。より効果的なのは、正確なエラー、失敗したテスト、疑わしいコードの該当箇所を提示することです。また、ユーザーはモデルのコンテキスト・ウィンドウにも注意する必要があります。これは、モデルが一度に考慮できるテキストの最大量（「トークン」、つまり数文字ごとのチャンクで測定）を指します。SWE-benchが実際のGitHubのIssueで示しているように、複雑なコードベースにおける実際のバグは複数のファイルにまたがることが多く、関連するコードをすべてコンテキスト内に収められないモデルでは、それらについて適切に推論することが難しくなる可能性があります。
AIデバッグは通常、開発者のコーディング・ワークスペース（一般的には統合開発環境（IDE））に組み込まれた、またはその周辺で動作するAIコーディング・アシスタントを通じて行われます。例えば、GitHub Copilotは一般的なIDE内でコードを提案できるコーディング・アシスタントです。一方、CursorやWindsurfはAI指向のコーディング・ワークスペースであり、同様の支援機能をプログラミング体験の中心に据えています7。さらに、「エージェント型エンジニアリング」が普及するにつれて、一部のソフトウェアでは、コーディング・アシスタントのチャット・ウィンドウが、人間のユーザーがIDEとやり取りするための主要なインターフェースとなるよう設計されています。IBM Bobも、そのような利用方法の一例です。
多くのコーディング・アシスタントは特定のモデルに依存しません。例えば、GitHub Copilotでは、OpenAI、Anthropic、Googleなどのプロバイダーが提供するモデルを利用できます。また、xAIは、Grok Code Fast 1がコーディング・エージェントのワークフロー向けに設計されており、Copilot、Cursor、Windsurfなどのツールを通じて利用できると説明しています8 9。一方、IBM Bobは複数のモデルを使用し、複雑さやコストに応じて適切なモデルへクエリを自動的にルーティングします。2026年のリリース資料では、「Anthropic Claude、Mistralのオープンソース・モデル、IBM Graniteなどのフロンティア・モデルに加え、コード推論、セキュリティー、次回編集予測向けに特別にファインチューニングされたモデルを組み合わせている」と説明されています。
AIデバッグ・エージェントには、汎用型のものもあれば、特定用途に特化したものもあります。汎用型の例としては、2025年に導入されたGitHubのCopilotコーディング・エージェントがあります。このエージェントはGitHubのIssueを割り当てられ、GitHub Actionsを使用してバックグラウンドで作業し、その変更案をプルリクエスト（人間の開発者がレビューするためのコード変更のまとまり）として提出できます10。複数のモデルを組み合わせて利用するIBM Bobも、汎用型に分類されます。一方、Copilot Autofixは、セキュリティー上の脆弱性への対応に特化したツールです。これは、GitHubのコード・スキャン・エンジンであるCodeQLと、AIが生成する説明や修正候補を組み合わせることで実現されています。時間短縮の効果も大きく、GitHubによると、修正時間の中央値は手動の場合の1.5時間に対し、28分となっています11。
印象的ではあるものの、生成AIの最前線における成果にはばらつきがあります。IBMが最近実施した2,000人の最高経営責任者（CEO）を対象とするCEOスタディによると、近年のAIの取り組みのうち、期待どおりの投資収益率（ROI）を達成したのはわずか25％でした。
同様の傾向は、AIデバッグにも当てはまります。2024年のDebugBenchの調査では、クローズドソース・モデルは依然として全体的に人間の性能には及ばず、ロジック・エラーは構文エラーや参照エラーよりも大幅に修正が難しいことが明らかになりました12。
一方で、より優れた専門性の高いツールによって、状況は改善しつつあります。例えば、ChatDBGはLLMをライブ・デバッガーに接続することで、疑わしいコードだけでなく、プログラムが失敗した時点で実際に何を実行していたのかを把握できます。ある評価では、1回のChatDBGへのクエリだけで、67％の割合でPythonプログラムに対する実用的な修正案が得られました。さらに1回だけフォローアップの質問を許可した場合、その割合は85％まで向上しました13。
さらに状況を複雑にしているのは、モデルを評価する基準そのものが絶えず変化していることです。有名なSWE-benchの後継として14、より現実的でデータ汚染の影響を受けにくいSWE-bench Proが開発されました。最近の評価では、最先端のモデルでも25％に届かず、GPT-5は23.3％でした15。
開発者の行動は、科学的に測定できる以上の速さで変化している可能性があります。METRが2025年初頭に実施したランダム化比較試験では、経験豊富なオープンソース開発者はAIツールを使用すると19%長く時間がかかることが示されました。しかし、METRはすぐに、この結果は既に古くなっているとの見解を示しました。2026年に実施した継続調査では、生産性が向上していることを示す証拠も得られましたが、その向上を正確に測定することは依然として困難であるとしています16。METRは、その理由について次のように説明しています。「AIを使わずに作業したくないという理由で研究への参加を辞退する開発者が大幅に増えており、その結果、AI支援による速度向上の推定値が実際より低く見積もられている可能性があります。」
AI支援による開発やデバッグは、今後もなくなることはないでしょう。しかし現時点では、AIデバッグ・ツールは信頼できる自動操縦ではなく、強力なアシスタントとして捉えるのが適切です。これらのツールは、スタックトレースの説明、構文エラーの検出、修正候補の迅速な作成を行うことができます。しかし、ロジック・エラー、複雑なコードベース、セキュリティー上重要なコードといった難しいケースでは、コードベースにマージする前に、テストやブレークポイントによる確認に加え、熟練した開発者によるレビューが依然として必要です。
参考情報
セキュリティーで保護された意図認識型の開発を実現するAIパートナー、IBM® Bobにより、ソフトウェア・デリバリーを加速します。
企業向けツールを活用し、AIアプリケーションの開発、デプロイ、管理をより迅速に実行します。
インテリジェントなAIモダナイゼーションにより、レガシー・システムを再構築します。
脚注
1. Smithsonian National Museum of American History, “Log Book With Computer Bug.”
2. JSTOR Daily, “The Bug in the Computer Bug Story.”
3. Khan Academy, Intro to Python
4. Reddit, “What is a Stack Trace“
5. Cambridge Judge Business School, “Research by Cambridge MBAs for tech firm Undo finds software bugs cost the industry $312 billion a year” (2013).
6. Arxiv, ChatDBG: Augmenting Debugging with Large Language Models
7. Github, “Intro to Copilot“
8. Github, “Models Comparison“
9. XAI, “Grok Fast-1”
10. Github, “Meet Copilot“
11. Github, “Secure Code With Copilot Autofix“
12. Arxiv, “Debug Bench”
13. Arxiv, ChatDBG: Augmenting Debugging with Large Language Models
14. Reddit, “SWE Bench is benchmaxxed“
15. Arxiv, “SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?“
16. METR, “Uplift Update“