Grace Hopperの「最初のバグ」を所蔵記録で確かめる：記録が述べていること、述べていないこと

「最初のバグ」の逸話は、コンピュータの歴史の話として広く知られています。この記事では、その逸話を、米国立アメリカ歴史博物館（スミソニアン）の所蔵記録の本文で確かめ、記録が述べていることと、述べていないことを分けて整理します。そのうえで、デバッグの記録の取り方について、筆者の提案を短く添えます。

所蔵記録が述べていること

• アメリカの技術者は、機械の小さな欠陥を、1世紀以上にわたって「bug」と呼んできた。Thomas Edison は、1870年代に、電気回路の bug について語っていた。
• 1947年、ハーバード大学の Mark II コンピュータに取り組んでいた技術者が、部品の一つに蛾（moth）が挟まっているのを見つけた。蛾はログブックにテープで貼られ、「first actual case of bug being found」と書き添えられた。
• 「bug」と「debug」という言葉は、その後まもなく、プログラマーの言葉の標準的な一部になった。
• 1947年に Mark II に取り組んでいた人々の中に、数学者でプログラマーの Grace Hopper（のちに海軍少将）がいた。このログブックは、おそらく Hopper のものではなかったが、Hopper と Mark II のチームは、「bug」と「debug」という言葉を広める助けになった。
• ログブックの現物は、同館の所蔵で、現在は展示されていない。

所蔵記録の付帯情報

• 作成年は1947年、作成された場所はアメリカのマサチューセッツ州ケンブリッジ。作成者として、ハーバード大学と IBM が挙げられ、関連する人物として、Howard Aiken（Director）が挙げられている。
• 入手の経緯は、アメリカ国防総省・海軍（Naval Surface Warfare Center）からの移管。
• 物の種類は「log book」で、ID 番号は 1994.0191.01。

記録の本文では確認できないこと

次の点は、上の所蔵記録の本文からは確認できませんでした。逸話を語るときは、記録が言っていないことを足さないよう注意が必要です。

• 蛾が、機械の不具合の原因だったかどうか。
• 蛾を見つけた人が、誰であるか（記録は「技術者たち」としています）。
• Hopper 本人が、この蛾の発見の場にいたかどうか（記録は、Mark II に取り組んでいた人々の中に Hopper がいた、と述べるにとどまります）。

記録の末尾には、参考文献として、Grace Murray Hopper「The First Bug」（Annals of the History of Computing、第3巻第3号、1981年）と、P. A. Kidwell「Stalking the Elusive Computer Bug」（IEEE Annals of the History of Computing、第20巻第4号、1998年）が挙げられています。この記事では、これらの文献は開いていません。

この逸話から読み取れること（筆者の解釈）

• 現象と証拠を、記録に残す：蛾をログブックに貼って記録したことは、現象を記録に残した例として読めます。現代のデバッグでは、再現手順・環境・エラーメッセージを残すことに当たります。
• 逸話は、記録に即して語る：この逸話は、「Hopper が発明した」「Hopper が見つけた」と語られがちですが、所蔵記録の述べる範囲は、それより控えめです。ソフトウェアの不具合報告でも、「確認できた事実」と「推測」を分けて書くことが、原因の特定を助けます。

この2点は、記録が述べているものではなく、筆者の解釈です。

ラバーダック・デバッグ

Wikipedia によると、ラバーダック・デバッグ（rubber duck debugging）は、プログラマーが自分のコードを、一行ずつ、自然な言葉で（声に出すか、文章で）説明することで、間違いや思い込みに気づく技法です。名前は、Andy Hunt と Dave Thomas の著書「The Pragmatic Programmer」（Addison-Wesley、1999年）にある逸話に由来するとされています。人に説明しようとして、その途中で問題に気づく、という経験を指す、とされています。

デバッグの記録の取り方の例（筆者の提案）

逸話の「現象を記録に残す」を、日々のデバッグに当てはめるための例です。効果の大きさや、必要な時間の目安は、示せません。

1. 症状：何が起きたか（エラーメッセージは、そのまま写す）。
2. 再現手順：何をしたら起きるか。毎回起きるか、時々か。
3. 環境：OS、言語やライブラリの版、直前に変えたこと。
4. 仮説：原因として考えられること。確認できた事実と、推測を分けて書く。
5. 確認と結果：仮説ごとに、何を確かめ、何が分かったか。
6. 修正と再確認：何を直し、再現手順で再度確かめた結果。

次は、書式を示すために作った例です。実際に起きた不具合の記録ではありません。

1. 症状：集計スクリプトが、途中で IndexError: list index out of range を出して止まる。
2. 再現手順：空のファイルを渡すと毎回起きる。データが入っているファイルでは起きない。
3. 環境：Python 3系（例）。直前に、入力ファイルの読み込み部分を書き換えた。
4. 仮説：（確認済み）空のファイルでのみ起きる。（推測）空の場合を想定せずに、先頭の要素を読んでいる。
5. 確認と結果：エラーの行を見ると、リストの先頭の要素を読んでいた。空のリストでは要素がないため、エラーになることが分かった。
6. 修正と再確認：空のときは、メッセージを出して終了するよう直した。再現手順の空のファイルで、エラーが出ず、メッセージが出ることを確認した。

練習の機会は、自分が直した不具合を、あとからこの書式で書き直してみることです。仕事のコードや機密情報は、記録に持ち込まないよう、職場のルールを確認してください。

更新履歴

2026年10月29日：全面的に改訂しました。題名を内容に合わせて変更しました。スミソニアンの所蔵記録の本文を開いて、記録が述べていることと、確認できないことを整理しました。根拠のなかった「8週間のロードマップ」と、練習ステップの日数の目安を削除しました。確認できなかった書籍の記述（Agans の個別の原則）を削除しました。

参考文献・出典（2026年10月29日確認）

• National Museum of American History (Smithsonian), “Log Book With Computer Bug”（ID 1994.0191.01）：所蔵記録
• Wikipedia, “Rubber duck debugging”：Wikipedia
• Andrew Hunt, David Thomas, “The Pragmatic Programmer,” Addison-Wesley, 1999（書誌情報：Wikipedia「The Pragmatic Programmer」。書籍そのものは未確認）
• David J. Agans, “Debugging,” AMACOM, 2002。書籍サイトに載る推薦コメント（Howard Johnson 氏のもの）に、9つの原則を述べた本という評がある。個々の原則は、確認できなかったため、本文では扱っていません（書誌情報：書籍サイトの著作権表示。書籍そのものは未確認）

あわせて読みたい記事

小さな単位で読む・設計するという点で、次の2本とつながります。

• コードリーディングの基本技法：トップダウンとボトムアップ、kiloを題材にした5日間の練習計画（小さなプログラムを読む）
• UNIX哲学入門：1978年の原典で確かめる、小さく作って組み合わせる設計の考え方（小さな部品の設計）