ウィキペディアにおけるバグの報告については、「Wikipedia:バグの報告」をご覧ください。

この項目では、コンピュータプログラムの欠陥について説明しています。語源となった用語については「虫」を、その他の用法については「バグ (曖昧さ回避)」をご覧ください。
.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}

この記事には複数の問題があります。改善やノートページでの議論にご協力ください。

出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2013年11月）


独自研究が含まれているおそれがあります。（2019年10月）


言葉を濁した曖昧な記述になっています。（2013年11月）
出典検索?: "バグ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL

バグ (英: bug) とは、英語で「虫」の意である。コンピューター業界ではプログラムの誤りや欠陥を表す用語として使われる。

ソフトウェア・ハードウェア開発における契約文書など、法的な文書ではバグのことを「瑕疵」（かし）と記述する。原因や責任の所在などが不明なものを特定性の低い表現の「不具合」と呼ぶことがある。また、セキュリティ面に関わる脆弱性や欠陥は「セキュリティホール」などと呼ばれることもあり、バグはこれらの原因のひとつになりうる。

多くのバグが含まれ、機能的に正常な役割を果たさないものを、バギー・プログラムと呼ぶことがある。

なお、発生したバグを探して修正する作業はデバッグと呼ばれる。
原因と影響

この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "バグ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2019年10月）

この節には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2019年10月）

プログラミング上の主なバグには、論理的なバグと誤記によるバグがある。

論理的なバグは、プログラムの設計過程において発生する。無限ループや計算間違いなどを引き起こし、時にはコンピュータを暴走させたり、逆に停止させたりすることもある。

誤記によるバグは、プログラムの実装過程において発生する。存在しないプログラムの参照、意図した範囲を超えた計算結果、数値計算の誤りなどを引き起こす。論理的なバグと同様に、コンピュータを暴走させたり停止させたりすることもある。

他に、オペレーティングシステム（OS）、デバイスドライバあるいは仮想マシンなどの実行環境や、コンパイラあるいはライブラリやアプリケーションフレームワークなどの開発環境にバグが含まれていることにより、アプリケーションソフトウェアにバグが発生することがある。2000年問題のように、ソフトウェアが本来予測された耐用年数を超えて運用された結果、仕様がバグになってしまったものも環境依存のバグといえるだろう。

安易な修正（バグフィクス）は避けられる傾向にある。修正内容にバグを含んでいる場合や、関連するプログラムがバグの存在によって正常に動作していた可能性があるためである。「正常に動作しているものは触らない」、「寝ているバグは起こさない」と言われる。しかし現実は、ハードウェアや言語の仕様では定められていない動作などを利用していて「偶然うまく動いているだけ」という壊れている多くのシステムを放置する言い訳として、このような主張がされることが多く、そういった場合には「何が起きるかわからないから、ハードウェアの同等品へのリプレースも、OSや処理系のバージョンアップも、セキュリティフィックスのパッチ当てさえもできない」という、ますます危険になり続けているシステムが放置される結果となる。
語源

「バグ」は英語からの外来語であるが、この言葉はコンピュータの登場以前から、機械装置の原因不明な不具合をあらわす符牒として技術者の間で使われていた。たとえば1878年にエジソンが同僚に宛てた手紙のなかで、彼は機械の不具合のことを「バグ」と呼んでいる[1]。また、第二次世界大戦中には、レーダーの故障をバグと呼んでいたという記録が残っている。現在の米口語では、バグはコンピュータのバグや虫の意味のほかにも、動詞として「人を悩ませる、いらいらさせる」という意味でよく使われる。

コンピュータのソフトウェアに間違いが入るという概念自体は古く、その起源はチャールズ・バベッジによる解析機関にまでさかのぼる。解析機関のプログラミングを担当したエイダ・ラブレスはすでに1842年に残したメモの中で、計算手順を示したカードの入れ間違いにより誤った計算結果が得られる危険性を示唆していた。コンピュータの中に入りこんでいた「虫」の、おそらく最初の写真。

コンピュータに関しては、グレース・ホッパーが、Harvard Mark II（英語版）のプロジェクトで働いていた時に、バグとして本物の虫を発見したという話[2]がある。不調になったMark IIを調べたところ、リレーの間に虫（蛾）が挟まっていたのを別の技術者が発見した。彼女はこれを、作業日誌にテープで貼りつけて「本物の虫が『バグ』として発見された最初の例」[3]と書き残した[4][5][6]。この日誌は米海軍歴史博物館に保管されている。ホッパー自身、1984年の『タイム』誌の取材に対し、「その時以来、コンピュータで何か不具合があると、そこにバグがあると言うようになった」と述べている。

他にも、シェイクスピアの『ヘンリー四世』で忌まわしきものという意味で使われていた「バグ」という単語に由来するという説もある。プログラム上の欠陥を虫に見立てて呼ぶようになったという説もあるが、これは誤りとされている。
対策

通常、ソフトウェアが仕様通り正常に動作するかどうかを確認するソフトウェアテスト（プログラムテスト）を実施し、その過程でバグが発見されればソフトウェアを修正した上で再びテストを実施、仕様通りに正常に動作するよう仕上げていくことになる。

しかし、ソフトウェアに『バグが存在すること』を立証するには、何かひとつの手順によって再現させるだけでよいが、「ソフトウェアに『バグが絶対に存在しないこと』を立証する方法」は@media screen{.mw-parser-output .fix-domain{border-bottom:dashed 1px}}数学的に存在し得ない[疑問点 – ノート][要説明]ので、ある程度の複雑さを持つプログラムにおいて、バグの数を 0 に近付ける以上のことはできない。仮にソフトウェアテストで存在を証明された既知のバグをすべて除去したとしても、そのソフトウェアに他のバグが一切存在しない、ということにはならない。

エドガー・ダイクストラは以下のような格言を残している。Program testing can be used very effectively to show the presence of bugs but never to show their absence.（プログラムテストは、バグが存在することを示すには極めて有効だが、バグが存在しないことを示すことはできない）[7]。

実際に、近年[いつ?]のOSなど膨大なプログラミングを必要とするものには、「バグのないソフトウェアは無い」と言われている。

もしすべてのバグを完全除去したソフトウェアを作成しようとした場合、製品の開発・デバッグ・テストからリリースまでに膨大な時間とコストがかかってしまい、開発費用を回収できなくなってしまう。このため、ソフトウェアメーカーの多くは、ある程度のバグが残っていても、致命的な不具合や主要機能への影響がなく、また別の回避策があるなどの想定範囲内のバグであれば、既知の問題点としてユーザーに告知した上でリリースしたりしている。

例えば銀行のオンラインシステム（勘定系システム）などは、社会基盤を支える重要度の高いシステムであるが、年に数度ダウンする程度が目安となる。それ以上の品質を確保するよりも、問題が顕在化した時点で対処した方が、費用対効果の点で有益であると判断されるからである。

出荷後は、開発元が想定・考慮していない操作を行なった際にバグが発見されることが多い。メーカーのプログラマやテスト担当者は専門家としての知識・経験があるため、無意識のうちに危険な操作や負荷のかかる操作を避けてしまうことも多く、逆に想定外の操作により発生するバグの発見はしばしば困難である。このようなバグは専門知識の無い一般利用者が使用することで発見されることも少なくない。

近年[いつ?]では、バグが残っていることを前提にした上で、最新の機能や修正した機能を搭載したソフトウェアをアルファ版やベータ版として一般利用者に試用してもらい、報告されたバグを正式版までに修正するという手法もよくとられる。特にセキュリティ上の脆弱性や致命的なバグの発見者に対して報奨金を支払うベンダーもある[8]。また、ゲーム製品などでは、素人の一般人に試用してもらいバグを発見する専門の仕事もある。

また、最近[いつ?]では本来想定していない動作ではあるが、基本動作に影響がない場合に「仕様」としてしまうこともある。

バグ修正や機能追加によってソフトウェアに新たなバグが混入してしまうことを防ぐには、既存機能が仕様通り正常に動作することを保証するための単体テストを自動化してリグレッションテストの機会を増やすことが挙げられる。この開発手法はテスト駆動開発と呼ばれ、リファクタリングやアジャイルソフトウェア開発の要となっている。

AIの発達に伴い、プログラマーの書くコードをAIに監視させ、バグにつながりそうなコードを書いたら警告を与えてバグの発生を未然に防ぐ手法もある。難点としては大量の学習用データとマシンパワーが必要とされている[9]。
バグ管理

この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "バグ" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2019年10月）

この節には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2019年10月）

バージョン管理システム

消費者向けアプリケーションソフトウェアの場合、一般的にはバージョン管理システムと呼ばれる数値で行うことが多い。バージョンの数値が大きいほど、バグの修正や機能の追加が行われていることを表す。コンシューマ向けOSなどの場合、メーカーではこれらを定期的に修正した修正プログラムを提供している。既知の問題の修正箇所を、個別に修正の実施と未実施を調べる。近年ではバグ管理システムなどに移行している。

マイクロソフト では毎月第二火曜日（日本ではその翌日で、単なる第二水曜日ではないことに注意）に自社製品のバグの対策プログラムを発表するようになった。以前は修正プログラムが完成した都度に発表していたが、ユーザが頻繁に修正プログラムの発表を調べなくてはならず、修正が行われずに放置されてしまう場合が逆に増えてしまっていた反省によるものである。ただし、既に実害が発生している場合などは即時の発表が行われている。他社もマイクロソフトに倣って第二火曜日近辺に発表することが多くなった。
バグ管理システム

近年、ソフトウェアの開発においてはバグの修正が重要な作業と考えられている。バグを漏らさず修正し、再発を防ぐには、バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報を残し管理する必要がある。開発によっては数千という数のバグが発生し、また多数のテスト担当者や修正担当者が関わっていることを考慮すると、従来のファイルレベルの管理では追いつかなくなっている。このような背景から、バグを管理するソフトウェアであるバグ管理システムが生まれた。バグトラッキングシステム (BTS[10]) とも呼ぶ。

バグ管理システムは、ウェブサーバ上で動作し、ウェブブラウザ経由でアクセスできるようになっている。また電子メールとも連動し、修正時にテスト担当者やバグ報告者にメールが送信されるものもある。

主なバグ管理システムにはBugzillaや影舞などがある。また、最近ではウェブサーバを必要としないP2Pアーキテクチャによるバグ管理システムの ⇒Papilio といったものも登場した。

バグ管理システムは、バージョン管理システムと同様、ソフトウェアを開発する上での必須ツールになりつつある。
バグとソフトウェア工学

ソフトウェアでバグを出さない最も良い方法は、そもそもバグが起こりにくい開発を心がけることだといえる。バグが起こりにくい環境では、その分工数に余裕が持てる上、ソフトウェア自体の性能も良好になりやすいという、正の相関性が見られる。正しい環境の追求は非常に重要な問題である。

どのような方法論をとれば開発過程にひずみを産まないか、安全なプログラムを書くにはどのような言語を用いるべきか、適切な人員配置とコミュニケーションはどのように行われるべきか、等々、そのような知見を扱う分野はソフトウェア工学と呼ばれる。