世界初のバグ（本物の蛾）

何のコードか（背景と何が有名か）

「世界初のバグ」として語り継がれるのは、ソースコードではなく1冊の作業ログに貼り付けられた1匹の蛾です。1947年9月9日、米ハーバード大学の電気機械式計算機 Harvard Mark II（海軍向けに稼働していた大型リレー計算機）が誤動作し、原因を追った作業員がリレーの接点に挟まった蛾を見つけました。取り出した蛾をログのページにテープで貼り、その脇にこう書き添えました。

First actual case of bug being found.

このページは現在、スミソニアン協会の米国国立歴史博物館（National Museum of American History）に収蔵されています。有名なのは、抽象的な用語だった「バグ（bug、不具合）」が、文字どおり物理的な虫として計算機の中から見つかった一致の妙にあります。そしてこの逸話の周りには「バグという言葉はここで生まれた」「Grace Hopper が命名した」という俗説が厚く積もっており、一次資料と突き合わせて切り分ける題材としても格好の一例です。

コードと仕組みの解説

横にスクロール

貼り付けられた「コード」は上のログ1行ですが、決定的なのは actual（本物の・実際の）という語です。もし「バグ」という言葉がこの日に生まれたなら、わざわざ「実際に見つかった最初の事例」とは書きません。この一語は、当時すでに技術者が不具合を日常的に bug と呼んでいたことを前提にした、いわば楽屋落ちのジョークです。つまりログの筆致自体が「語源はここではない」ことを内側から証言しています。

なぜ本物の虫が計算機を止めたのかは、Mark II が電子式ではなく電気機械式リレーで論理を組んでいたことに尽きます。リレーは電磁石で金属接点を機械的に開閉して 0/1 を表現する部品で、その接点は物理的にわずかな隙間を持ちます。

論理を電子ではなく物理的な接触で表現していたからこそ、接点に入り込んだ小さな虫が絶縁物として働き、その桁の演算が狂いました。真空管やトランジスタ主体の後年の計算機なら、同じ大きさの虫がこの形で1桁を止めることはまず起きません。世界初の「実物のバグ」がこの時代・この方式で記録されたのは、リレー機の宿命だったといえます。

逸話と経緯（誰が・いつ・どんな状況で書いたか）

日付は1947年9月9日、場所はハーバードの計算研究所、機械は海軍向けに動いていた Harvard Mark II です。ここで俗説と史実を丁寧に分けます。広く流布した物語では「Grace Hopper が蛾を見つけ、バグという言葉を生み、デバッグ（debug）という動詞を作った」とされます。しかし Hopper 本人が後年、自分は発見者でも記入者でもないと繰り返し証言しています。当時40歳の海軍予備役・数学者だった彼女は Mark II のチームにいましたが、蛾を取り出しログに書いたのは別のチームメンバーでした。

では、なぜ彼女の逸話になったのか。理由は語りの力です。Hopper はその後およそ45年にわたって講演でこの一件を魅力的に語り続け、いつしか物語は彼女のものとして定着しました。象徴を広めた立役者であることは間違いありませんが、それは「発見した」「命名した」とは別の事実です。

語源そのものは1947年よりはるかに古く、技術的な欠陥を bug と呼ぶ用法は Edison の時代までさかのぼります。Edison は1870年代、四重電信（1本の線で複数信号を送る方式）の開発中に生じる小さな障害を bug と呼び、1878年の書簡では「bug——こうした小さな欠陥や困難はこう呼ばれる」と記しています。1880年代には電信技術者の間で Edison 由来の語として通用していました。1947年の蛾は、この既存の言葉に「本物の虫」という文字どおりの実例を与えた出来事だったのです。

遺産と教訓（今に残す影響、そこから学べること）

この蛾がプログラミングに直接与えた技術的影響はありません。デバッガの発明でもアルゴリズムの発見でもなく、リレー機に固有の物理現象の記録です。それでも計算機史の象徴として残り続けるのは、抽象的なソフトウェアの用語と目に見える現実が偶然一致した稀有な瞬間だからです。実際、貼り付けられた蛾の写真は「バグ」という不可視の概念を可視化する図像として、いまも教材や記事で繰り返し使われます。

より本質的な遺産は、事実確認の作法にあります。この逸話は「もっともらしく、感動的で、記憶しやすい」三拍子ゆえに、語源説明としてそのまま広まりました。しかし一次資料（ログの actual の一語）と年代（Edison の1870年代の用例）を突き合わせれば、俗説は容易に崩れます。技術者が日々向き合う障害調査もこれと同型で、印象的で流通しやすい説明ほど裏取りが要ります。原因の由来を確かめずに「たぶんこれだろう」を採用する態度は、語源の誤伝と同じ構造の誤りを生みます。

障害の原因を体系立てて追う考え方はプログラミングを、部品レベルの物理がどう論理を支えるかはOSの観点も参照してください。用語の由来にせよ不具合の原因にせよ、印象ではなく一次資料で確かめる——この一件が今に残す最大の教訓です。