English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

ゲスト
1 / ?

既に存在していた理論

すべての MOAD 欠陥には、2026 年に体系的な検出が行われる何十年も前から既知の解決策がありました。欠陥が残ったのは、誰もより良い方法を知らなかったからではありません。知っていることと検出することは別だったのです。

MOAD 残存タイムライン:5 つの欠陥それぞれについて、理論が知られていた時期と検出された時期

MOAD-0001: O(N²) list.contains

Donald Knuth, 1973. The Art of Computer Programming, Volume 3: Sorting and Searching. 1973 年にハッシュテーブルによる O(1) ルックアップが解析付きで完全に仕様化されました。O(N) の線形探索と O(1) のハッシュ探索の違いは、文書化・形式化され、広く引用されていました。Java は 1.0(1996 年)で HashSet を出荷し、Python は 2.4(2004 年)で set を第一級型として提供しました。修正策は、あらゆるエコシステムでデフォルトのイディオムになる 30 年前から存在していたのです。

Richard Hamming, 1986. Bell Labs lectures (later published as The Art of Doing Science and Engineering, 1997). Hamming explicitly taught algorithmic complexity, the difference between correct & efficient, & the danger of building systems that work at small scale but fail at large. He called it 'designing for the problem you can see today, not the problem you will face tomorrow.'

MOAD-0002: 共有グローバル状態結合

David Parnas, 1972. 「On the Criteria To Be Used in Decomposing Systems into Modules.」 CACM, 1972年12月. Parnasは、モジュールは情報隠蔽によって分解されるべきだと主張した — 各モジュールは自身の状態を所有し、共有される可変グローバルは存在しない。これはIntertangle修正の直接的な理論的先駆けである。Parnasは明確に述べた:グローバル共有状態は、テストでは明らかにならない不可視の結合を生み出す。

MOAD-0003: ThreadLocal アイデンティティリーク

Java 1.2, 1998. ThreadLocalはJava標準ライブラリクラスとして提供された。スレッドプールとThreadLocalが共存した瞬間、リークのメカニズムが存在した。欠陥は構造的である:キャリアの寿命はスレッドであり、作業単位ではない。この問題はJava EEライフサイクルの初期からドキュメントで警告されていた。

MOAD-0004: ログに記録された認証情報

RFC 1945, 1996. HTTP/1.0はAuthorizationヘッダーを定義した。認証情報ログの欠陥は、Authorizationヘッダーが存在した日から可能になった。OWASPは2001年に設立され、初版ガイドで認証情報ログを脆弱性クラスとして文書化した。パターン:Authorizationヘッダー → ログミドルウェア → ディスク上の平文認証情報。最初のHTTP認証仕様から知られていた。

MOAD-0005: サンダリング・ハード / キャッシュ・スタンピード

Unixカーネル、1993年。 「サンダリング・ハード問題」——共有イベントでN個のプロセスが同時に起動される——は、1990年代初頭のUnixカーネル開発の議論で登場した。Doug SchmidtのReactorパターン(1994年)とHalf-Sync/Half-Async(1995年)の研究は、インフラレベルでの同期問題に対処した。キャッシュ・スタンピードの変種(キャッシュミス時にNスレッドが同じ値を計算する)は、2001年までに分散システムの文献で記録された。

---

理論:完成。検出ツール:不在。「知り得る」状態と「検出された」状態のギャップは、欠陥によって28年から54年におよぶ。

知り得るギャップ

タイムラインは、すべてのMOAD欠陥が体系的な検出より少なくとも28年前に既知の解決策を持っていたことを示している。最短のギャップ(MOAD-0003)は28年。最長のギャップ(MOAD-0002)は54年。

これは無知の物語ではない。Knuth、Parnas、Hamming——これらはコンピュータサイエンスで最も引用される著者たちである。彼らの著作は大学で教材として使われた。彼らの語彙(Big O、情報隠蔽、アルゴリズム的複雑性)は標準カリキュラムとなった。

これらの欠陥クラスについて知っていたことが、なぜ欠陥の存続を防げなかったのか? 1つのMOADを選び、知り得る解決策と実際の検出の間の具体的なギャップを追跡せよ。

Why Code Festers: Five Conditions

欠陥は偶然に残るわけではありません。5つの構造的条件が同時に存在することで、fester環境が生まれます。そのうちの1つでも除去すれば、検出が可能になります。

Five conditions for MOAD festering: causal DAG from theory to fester

Condition 1: Correct Output

リストとセットは、所属判定の質問に対して同一の回答を返します。list.contains(x)set.contains(x) は同じ boolean を返します。ThreadLocal が古いアイデンティティを保持していても、それは依然として ある アイデンティティを保持しています — ただし、それは誤ったリクエストに属しています。ログに記録された認証情報は正しく記録されています — 認証情報はエラーなくログファイルに到達します。欠陥は機能不全ではありません。コストまたはセキュリティ上の結果においてのみ機能不全です。出力チェックを行うテストはパスします。コストまたはセキュリティ上の結果をチェックするテスト:ほとんど書かれていません。

Condition 2: No Complexity Tests in CI

Dijkstra は「テストは欠陥の存在を示すものであり、その不在を示すものではない」と述べました。Hamming はこれを拡張しました:私たちがテストする欠陥は、私たちが発見する欠陥です。2026 年の CI パイプラインは以下をテストします:正しさ、型安全性、API 契約、機能的振る舞い。これらは以下をテストしません:操作ごとのアルゴリズム的複雑度、呼び出しごとのメモリ増加、authorization-header の除去、スレッドアイデンティティのライフサイクル。

テストは実行されません。テストは失敗しません。パイプラインは緑色です。欠陥は不可視です。

Condition 3: Small-N Origin

コードは開発環境で書かれ、レビューされます。開発グラフには 50 ノードがあります。開発リクエスト負荷は 10 同時スレッドです。開発キャッシュミス率は低い(ウォームキャッシュ、少ないキー)です。N=50 では O(N²) コストは 2,500 操作です。不可視です。N=50,000 ではコストは 2,500,000,000 操作です。1 秒のビルドではなく 17 分のビルドになります。

コードを書いた著者は N=50,000 を見たことがありません。コードを承認したレビュアーは N=50,000 を見たことがありません。欠陥は書かれた規模では可視ではありませんでした。

Condition 4: Copy Propagates Without Context

正しいアルゴリズムは教育的である。チュートリアルは正しい例で教える。ドキュメントは動作するコードを示す。同じTarjan SCCの骨格 — visited = []、内部の if n not in visited — がGHC、Maven、Python pip、Cargo、TypeScriptコンパイラ、Kotlinコンパイラ、Scalaコンパイラ、javacに現れる。異なるチーム、異なる言語、異なる時代。同じ化石。原著者のN=50はコードとともに伝播しない。伝播するのは正しい出力。残るのはパフォーマンスの前提。

条件5: 凍結されたコードの周囲で規模が拡大する

コードは劣化しない。インフラはスケールする。2003年に200パッケージ用に書かれた依存関係リゾルバが、2024年に50,000パッケージで動作する。誰も書き直さない — 動作するから。誰もプロファイリングしない — CIは緑色。O(N²)コストを破滅的にするNは、徐々に、目に見えない形で、本番規模で到達する。その頃には原著者はすでに去っている。コードは依存関係である。動作する依存関係には誰も触れない。

診断: 五つの条件

五つの条件: 正しい出力、複雑度テストの不在、小規模Nでの起源、文脈なしのコピー、凍結されたコードの周囲で規模が拡大。

すべてのMOADで五つの条件が同時に存在した。これは偶然ではない — 堆積的欠陥クラスの構造的特徴である。

五つの停滞条件のうち、排除するのが最も難しいのはどれか、そしてその理由は何か? 実際のソフトウェア組織のパイプラインからそれを除去するには何が必要か?

Hammingの言葉

Richard Hammingが1986年にBell Labsで行った講義(1997年に『The Art of Doing Science and Engineering』として出版)には、MOAD欠陥パターンを直接的に描写しているように読める警告が含まれている。彼はMOADについて語っていたわけではない。彼が語っていたのは、局所的には正しい決定が、全体としては高コストになるという、エンジニアリングシステムに内在する構造的傾向についてである。

Hammingの複雑性に関する言葉:「計算の目的は洞察であり、数値ではない。しかし、適切な複雑さのアルゴリズムを持たなければ、数値は得られない。N=100で動作するO(N²)アルゴリズムは、退職するまでにN=1,000,000では動作しないだろう。」

Hammingのコピーに関する言葉:「優れたエンジニアは単に解決策をコピーするのではない。彼らはなぜその解決策が機能するのか、どのような条件下で成り立つのか、そして何がそれを破壊するのかを理解している。条件を伴わないコピーされた解決策は時限爆弾である。」

Hammingのテストに関する言葉:「測定したものをテストすることは、重要なものを測定することとは同じではない。我々はテストすることを選んだ特性に対して精巧なテストスイートを構築する。選ばなかった特性はテストされないままになる。テストされなかったものが、本番環境で我々を驚かせる。」

Hamming on scale: 'The error you make in the first year of a project is the error you are still correcting in the tenth year. Early assumptions calcify. The project scales around them. Nobody rewrites the foundation.'

警告と運用化のギャップ

Hammingの警告は正しかった。それらは教えられ、引用され、カリキュラムに組み込まれた。しかし警告は検知器ではない。Hammingは欠陥の形状を記述した。CIで実行され、O(N²)のホットパス、ThreadLocalの同一性漏洩、または認証情報のログ記録をフラグ付けするツールを構築したわけではない。「知り得る」ことと「検知可能」ことのギャップは、理論と自動化されたインフラとしての運用化との間のギャップである。

MOADが存在するのは、分野が同等のレベルで性能やセキュリティのインフラではなく、正しさのインフラを構築したからである。ユニットテスト:1970年代から標準。プロパティベースのテスト:1990年代から標準。CIにおけるアルゴリズム的複雑度のベンチマーク:2026年でもまだ実験的。

警告の運用化

Hammingは複雑性の石灰化、未テストのプロパティ、条件なしでコピーされた解決策、スケールによる初期仮定の圧壊について警告した。彼は語彙を与えた。検知器は与えなかった。

MOADパイプラインはそのギャップを埋める:スキャン → チケット → パッチ → ユニットテスト → 開示 → PR → 上流マージ。これは運用化されたHammingである:単なる警告ではなく、自動検知と修正パイプライン。

Hammingは「テストしないままにしておくものが、本番環境で私たちを驚かせる」と言った。ソフトウェア業界が体系的にテストしないままにしているプロパティを1つ挙げ、その自動検知がどのようなものになるかを説明せよ。

The Fester Signature

MOAD クラスの欠陥には認識可能な signature があります。5 つの条件が同時に存在します。5 つすべては、スキャンを 1 つも書く前にチェック可能です:

1. 正しい出力か? 標準テストスイートを実行します。パスした場合、その欠陥は正しさではなく、パフォーマンスまたはセキュリティのプロパティに関するものです。つまり、標準 CI では検出されません。

2. 複雑性テストなし? CI 設定を確認せよ。ベンチマークステージはあるか? アルゴリズムの振る舞い(単なる壁時計時間ではなく)を前回のコミットと比較しているか? なければ:条件成立。

3. 小規模 N 起源? git blame と初回コミットを確認せよ。初回実装時のデータセットサイズは? 現在の本番負荷より 100 倍以上小さいか? はいなら:条件成立。

4. コピーが伝播? コードベース全体およびエコシステム全体でパターンを検索せよ。同じ構造パターンが、共通の祖先を持たない独立したコードベースで N≥3 個現れるか? はいなら:化石が伝播した。各コピーが新たな感染源となる。

5. 規模が拡大? 本番メトリクスを確認せよ。初回デプロイ時と比べて現在の N は? 成長率は持続しているか? どの N で欠陥が運用上クリティカルになるか?

5 つすべてを確認・成立させた場合:MOAD クラスの欠陥である。修正は常に 1 行または 1 メソッドの置換で済む。発見こそが難しい部分。修正は簡単な部分である。

これが Hamming の意図したことだ:エンジニアリングは修正についてではない。修正は、一度見えれば単純明快である。エンジニアリングとは、それを見えるようにするシステムを構築することである。

シグネチャを適用せよ

MOAD 感染シグネチャ:正しい出力 + 複雑性テストなし + 小規模 N 起源 + コピー伝播 + 規模拡大。

このシグネチャは5つのMOAD欠陥に限定されません。自動化された品質ゲートが正しさテストのみであるシステムに存在する欠陥のクラスを表しています。

5つのMOAD以外でfesterシグネチャに該当する欠陥クラスを1つ挙げてください。5つの条件のうちどれが存在し、自動検出器はどのようなものになるかを示してください。