現実世界のCASE FILE 現実世界のCASE FILE

ブレッチリー・パーククリブからボンブへ――暗号解読はどう機械化されたのか

複数のドラム列と配線、操作部を備えたBombeを抽象化した概念イラスト
AI-generated conceptual illustration for REAL CASE FILE; not a historical photograph 出典 GENERATED_WORKFLOW_ASSET

ブレッチリー・パークが傍受、暗号解析、機械処理、翻訳、情報配布を分業できる組織へ成長しても、それだけで毎日のエニグマ設定が分かるわけではない。

必要だったのは、人間が見つけた「この暗号文には、たぶんこの言葉が含まれている」という手掛かりを、機械が調べられる形へ変えることだった。

その接点にあったのが、クリブ(crib)、メニュー(menu)、そして英国製ボンブ(Bombe)である。

クリブ――「正解文」ではなく、ありそうな平文

クリブとは、暗号文の一部に対応していると推定した平文断片である。

ここで重要なのは、クリブが「すでに分かっている全文」ではないことだ。暗号解読者は、通信の形式、既知の軍事状況、通信網の性格、過去の文面、定型的な表現、送信者の習慣などから、ある文字列が含まれている可能性を見積もった。

GCHQが紹介するショーン・ワイリー(Shaun Wylie)はHut 8の「cribs」部門を率い、共通するドイツ語断片や、同じ文字が繰り返し現れる構造などから有効なクリブを探していた。GCHQは別の解説で、From/Toのような通信形式や、traffic analysisによって予測された通信内容がクリブの根拠になり得たと説明している。

つまり、クリブ作りは単なる「よく出る単語当て」ではなかった。

誰が送っているか
どの通信網か
何が起きている時期か
以前どのような形式で送っていたか

という周辺情報を使って、「この位置には、この平文があるかもしれない」という仮説を作る作業だった。

エニグマ固有の性質も、仮説の絞り込みに使えた。

反射板を持つ軍用エニグマでは、ある文字が同じ文字自身へ暗号化されることはない。たとえば暗号文のある位置が `A` なら、その位置の平文を `A` と仮定する配置は成立しない。

そのため、推定した平文を暗号文の下で少しずつ位置をずらして重ね、同じ文字同士が重なる配置を除外することで、あり得る位置合わせを絞ることができた。

ただし、これも「そのクリブが正しい」と証明する操作ではない。まず不可能な配置を落とし、その後に機械探索へ渡せる仮説を作る段階である。

メニュー――文章を、機械が追える関係へ変える

クリブの候補位置が決まると、次に作られたのがメニューだった。

メニューは暗号鍵でも、平文そのものでもない。

暗号文の文字と、その位置にあると推定した平文の文字との対応を拾い出し、それらを「どの文字とどの文字が、エニグマ内部の変換を通じて結び付くはずか」という連鎖として整理したものである。

たとえば、ある位置で平文 `A` が暗号文 `G` に対応し、別の位置では `G` が `R` に対応すると仮定できるなら、A―G―Rというように関係をつなげていく。

実際のメニューは単なる文章ではなく、文字同士のリンクを図として表した。

Bletchley Park TrustのAnn Mitchellは、Hut 6のMachine Roomで、傍受された文字列の下に「それがドイツ語で何を意味すると思うか」が書かれた紙を受け取り、その対応から「links and chains of letters」をつないでメニューを作ったと証言している。作成されたメニューは、Eastcote、Wavendon、Stanmore、Gayhurstなどのボンブ拠点へ送られた。

つまり、

人間が考えた平文仮説
↓
暗号文との文字対応
↓
関係の連鎖
↓
メニュー

という変換を経て、初めて人間の推測が機械へ渡せる形になった。

ボンブは「全文を解読する機械」ではない

ここが最も誤解されやすい。

ボンブに暗号文を入れれば、紙にドイツ語の平文が印刷される――という仕組みではない。

Bletchley Park Trustは、ボンブについて「暗号そのものを解くのではなく、人間が最初の作業を行った後に、エニグマの可能な設定を調べる機械」と説明している。

メニューに従ってボンブを配線・設定すると、機械は設定されたローター順序やローター位置などの候補について、メニューで要求された文字関係が成立し得るかを系統的に調べた。

考え方の中心は、矛盾の排除である。

ある仮定の下で文字関係を追った結果、

この文字はAにつながるはず
↓
しかし同じ条件からAにはつながれない

というような矛盾が生じれば、その機械状態は候補から外せる。

このような検査を大量の候補に対して機械化することで、人間が一つずつエニグマの状態を試す必要を減らした。

したがって、ボンブが行っていたことを「総当たり」とだけ表現するのも正確ではない。

機械は無条件に全宇宙のエニグマ設定を順に試していたのではなく、クリブとメニューが与える論理的な制約を使い、成立しない候補を高速に排除していた。

チューリングが変えた「探索の前提」

英国のボンブは、ポーランドで開発されたボンバ(bomba)をそのままコピーした機械ではない。

前の記事で見たように、ポーランドのボンバは当時のドイツ軍が使用していた指標手順の反復関係を利用していた。ところがドイツ側が手順を変更すれば、その前提は崩れる。

アラン・チューリング(Alan Turing)は、ポーランド側から得た成果を出発点にしながら、特定の指標手順に依存しない方向へ考え方を進めた。

NSAのBombe史では、チューリングは「indicatorの一致」ではなく、通信内容から推定した平文を使う機械を構想したと説明されている。つまり、クリブから作った論理条件を機械に与え、エニグマ設定の候補をふるい落とす方式である。

これは、

ポーランド方式を捨てた

という意味でも、

チューリングがゼロから一人で発明した

という意味でもない。

ポーランド側が示した「機械による暗号解析」という出発点と、軍用エニグマの構造に関する知識を受け継ぎながら、戦時下の英国が直面した新しい運用条件に合わせて別の探索方式へ発展させたのである。

ウェルチマンのDiagonal Board

チューリングの構想を大きく改善したのが、ゴードン・ウェルチマン(Gordon Welchman)のDiagonal Boardだった。

エニグマのプラグボードには相互性がある。

たとえばAとEが接続されていれば、

A → E

であると同時に、

E → A

でもある。

ウェルチマンは、この相互関係をボンブ内の追加の論理制約として利用できるようにした。

GCHQはDiagonal Boardを「TuringのBombeに対する劇的な改善」と位置付けている。NSAの技術史でも、チューリングのテスト機構とDiagonal Boardを組み合わせることで、残る候補を大幅に絞れるようになったと説明されている。

ここで重要なのは、Diagonal Boardが「別の暗号解読法」だったのではなく、メニューから引き出せる文字関係をより強く機械へ伝え、矛盾を早く見つけるための改善だったことである。

ボンブはチューリング一人の完成品ではない。

チューリングの論理設計、ウェルチマンの改善、そしてBritish Tabulating MachinesのHarold “Doc” Keenらによる実際の機械設計・製造が結び付いて初めて、運用できるシステムになった。

「停止」は正解ではない

ボンブが動き始めると、ローター群が回転し、設定された条件を検査していく。

やがて機械が止まることがある。

しかし、この「ストップ」は、

正しい鍵を発見した

という意味ではない。

より正確には、

この候補は、
メニューから導かれた条件と
直ちには矛盾しなかった

という意味に近い。

したがって、停止候補は必ず確認する必要があった。

Eastcoteでボンブを操作したJean Millarの証言では、ボンブが止まるとオペレーターはその設定を記録し、checkerが同じローター条件と停止設定をchecking machineへ入れて確認した。チェックを通った結果だけが、暗号化された電話回線でBletchley Parkへ返された。

Torfrida Coxも、メニューに従ってボンブを設定し、possible matchで止まった結果を、エニグマを模擬するよう改造されたTypexで確認したと証言している。

つまり実際の工程は、

Bombe stop
↓
candidate
↓
checking
↓
reject / pass
↓
usable setting

だった。

「ストップ」と「確定した設定」の間には、人間と別機械による検証工程があった。

暗号文とクリブからメニューを作り、Bombeの候補探索、停止候補の確認、設定採用、復号へ進む工程。
クリブはどのようにBombeの探索と確認へつながったのか。

設定が分かってから、初めて暗号文を読む

チェックを通過した候補から、使用可能なエニグマ設定が得られれば、その情報を使って実際の傍受通信を復号できる。

Bletchley Park Trustの資料では、ボンブによって設定候補を得た後、改造Typexなどを使って傍受文を復号したことが説明されている。

この順序を逆にしてはいけない。

暗号文
↓
Bombe
↓
完成した平文

ではなく、

暗号文 + クリブ
↓
メニュー
↓
Bombeによる候補探索
↓
停止候補
↓
確認
↓
利用可能な設定
↓
暗号文の復号

である。

さらに、その復号文を翻訳・評価し、軍事情報として配布する工程は、前の記事で見たように別の組織作業だった。

機械を回した人々

ボンブの歴史を機械設計者だけで語ると、実際の運用が消えてしまう。

ボンブは、暗号解読者がクリブを考え、別の担当者がメニューを作り、オペレーターが配線し、checkerが停止候補を確認し、技術者が機械を維持することで初めて働いた。

Jean MillarはEastcoteで8時間交代勤務に入り、二人一組でオペレーターとcheckerを担当した。メニューに指定されたドラムを取り付け、背面を配線し、停止を記録した。故障時にはPost Office engineersを呼び、日常的なブラシの手入れはオペレーター自身も行った。

これは単なる「機械の監視」ではない。

メニューどおりに正確に設定し、結果を読み取り、確認工程へ渡すこと自体が暗号解読システムの一部だった。

また、ボンブ運用はブレッチリー・パーク本体だけで完結していなかった。

Ann Mitchellの証言では、Hut 6で作ったメニューはEastcote、Wavendon、Stanmore、Gayhurstなどへ送られ、ボンブで得たストップが電話で戻された。後期のボンブ運用は、複数拠点を通信で結んだ分散処理でもあった。

この意味でも、ボンブは単体の「魔法の機械」ではなく、

cribster
↓
menu maker
↓
Bombe operator
↓
checker
↓
engineer
↓
Bletchley Park cryptanalytic section

をつないだ運用システムだった。

機械化が解決したこと、解決しなかったこと

英国製ボンブの重要性は、人間の暗号解析を不要にしたことではない。

反対に、人間が見つけた有望な仮説を、機械が大量の候補へ適用できるようにしたことにある。

クリブが悪ければ、有効なメニューも作れない。メニューが弱ければ、多くの候補が残る。ボンブが止まっても、確認を通らなければ使えない。そして正しい設定が得られて初めて、暗号文そのものの復号へ進める。

人間の推測
+
論理的な制約
+
機械的探索
+
人間による確認

この連鎖が、エニグマ解読の機械化だった。

ただし、ボンブという仕組みが成立しても、すべてのエニグマ通信を常に読めたわけではない。手順、ローター構成、利用できるクリブ、通信量、そして敵側の変更によって、難しさは大きく変わった。

特に海軍とUボートの通信では、その問題がより厳しく現れる。

次の記事では、海軍エニグマがなぜ特に難しく、読み続けられる時期と読めない時期が生まれたのかを追う。

参考文献

  1. National Security Agency, Center for Cryptologic History, Solving the ENIGMA: History of the Cryptanalytic Bombe, revised 2024. 資料を確認(到達確認済み)
  2. GCHQ, Bletchley Park & WWII, institutional history. 資料を確認(到達確認済み)

検証ノート

確認した事項:crib、menu、Bombe、Diagonal Boardが候補設定を絞る工程。[1][2]

資料の読み分け:公的・博物館・公文書・査読資料が一致する範囲をSUPPORTEDとして採用した。Bombeが平文を自動印刷する機械だったという俗説を採用していない。

直接引用:本記事では原文の長い直接引用を追加せず、検証可能な範囲を要約し、出典との対応を示した。

  1. 01 ブレッチリー・パーク|エニグマはなぜ「読めない暗号」に見えたのか
  2. 02 ブレッチリー・パーク|英国より先に進んでいたポーランド暗号局
  3. 03 ブレッチリー・パークはどう「解読工場」になったのか
  4. 04 ブレッチリー・パーク|クリブからボンブへ――暗号解読はどう機械化されたのか
  5. 05 ブレッチリー・パーク|海軍エニグマ――Uボート通信はなぜ特に難しかったのか
  6. 06 ブレッチリー・パーク|解読文はどう「ウルトラ情報」になったのか
  7. 07 ブレッチリー・パーク|解読された情報は戦争でどう使われたのか
  8. 08 ブレッチリー・パーク|秘密の30年と、エニグマ解読の「英雄物語」

RSS FEED

RSSで更新を受け取る

RSSリーダーへ次のURLを登録すると、新着記事を確認できます。

フィードを直接開く