その1行は「5階建てのビル」で動いている：ジュニアエンジニアのためのコンピュータサイエンス地図【第1回】

エラーが出たとき、あなたはまずどこを見るだろうか。その一手の精度を決めているのは、知識の量ではなく「地図」です。この記事を読み終えると、コンピュータを5つの階に分けた一枚の地図を持ち、「この不具合は何階の問題か」を自分で切り分けられるようになります。ジュニアエンジニア向けコンピュータサイエンス入門シリーズ（全8回）の第1回です。

🎯 テーマの主役：「階層（レイヤー）」という見方

今回の主役は、特定の技術ではなく「階層（レイヤー）」という見方そのものです。一言で言えば、コンピュータは「上の階が下の階に乗っかる」構造でできていて、各階は下の階の複雑さを隠してくれている、という捉え方になります。

日常の例えで言うなら、5階建てのビルです。あなたは4階のテナントで仕事をしています。蛇口をひねれば水が出るし、エレベーターのボタンを押せば5階に行ける。でも、配管がどうなっているか、モーターがどう回っているかを知っている必要はありません。それは1階の機械室と2階の管理室が引き受けてくれています。コンピュータも同じで、あなたが書いたコードは4階に住んでいて、その下には3階（言語の実行環境）、2階（OS）、1階（ハードウェア）が控えています。

この地図を手に入れると、次の3つができるようになります。第一に、不具合が起きたときに「これは何階の問題か」の当たりを付けられること。第二に、新しい技術を覚えるときに「地図のどこに置くか」で記憶できること（丸暗記が減ります）。第三に、次に何を学ぶかの順番に迷わなくなること。順番に掘っていけばいいからです。

ここで大事なのは、下の階ほど「見えない」のに「止まると全部が止まる」という点です。4階のコードを1行直せば5階の体験が変わりますが、1階のディスクが満杯になっても5階の体験は壊れます。上の階だけを見ていると、この2種類の変化を区別できません。

5つの階を、名前・中身・あなたとの関係で整理しておきます。

😓 動機：書けるのに、説明できない

相談に来るジュニアエンジニアの多くが、同じ壁にぶつかります。フレームワークの使い方は分かる。チュートリアル通りに動かせる。CSSも書ける。でも「なぜそうなるのか」を聞かれると、言葉が止まってしまう。

具体的に、よくある4つの瞬間を挙げます。ひとつ目は、エラーが出たときに「自分が直すべきものか、それとも環境やインフラの人に聞くべきものか」が判断できない場面。ふたつ目は、レビューで「なんでこの書き方にしたの？」と聞かれて「動いたので」と答えてしまう場面。みっつ目は、技術書を読んでも実務のどこに繋がるのか分からないまま、記憶に残らず流れてしまう場面。よっつ目は、AIが書いたコードを前にして「たぶん大丈夫だと思います」しか言えない場面です。

ここ数年で、この4つ目の重みは確実に増えました。Stack Overflow Developer Survey 2025 では、AIツールを使う（または導入予定の）開発者が84%に達したと報告されています。書く量そのものは増えているのに、「これは何階の話か」を説明できる人と、できない人の差は開く一方です。コードを書く速さがコモディティ化したぶん、判断の根拠を言葉にできるかどうかが評価に直結するようになりました。

🧪 仮説：理解が浅く見えるのは、記憶力の問題ではない

ここで仮説を立てます。ジュニアエンジニアの「理解が浅い」という評価は、記憶力や努力量の問題ではなく、地図を持っていないことの症状ではないか。

この仮説を支持する観察が3つあります。第一に、同じ人が「フレームワークの使い方」は驚くほど速く覚えるのに、「なぜそれが動くのか」は覚えられない、という非対称が起きます。記憶力の問題なら、両方できないはずです。第二に、一度だけ下の階を覗いた人は、その後ずっと説明が具体的になります。第三に、地図がある人は新しい技術を学ぶとき「これは3階の話だな」と既存の知識に接続できるため、覚え直す量が減ります。

つまり、必要なのは大量の暗記ではなく、「どの階の話か」を判定する能力です。そしてこれは、訓練で身につきます。身につけ方は単純で、エラーに遭遇するたびに階を判定し、分からなければ「分からない」と記録する。それだけです。

🔬 検証①：1行のコードが辿る旅

地図が本当に役に立つのか、実際に1行を旅させて確かめます。題材は、あなたがエディタに書いた次の1行です。

console.log("こんにちは");

この1行が、画面に文字が出るまでに何が起きているのかを、階ごとに追いかけます。

4階では「意味」があります。 console.log("こんにちは") は人間にとって「文字を出力せよ」という意味を持った文です。ただしコンピュータにとっては、まだただの文字列にすぎません。

3階で「意味」が「命令」に変わります。 ランタイム（言語を実行するための土台）がコードを読み、構文を解析し、機械が扱える中間表現に変換します。JavaScriptのV8エンジンのように、実行中に頻繁に通る部分だけを機械語へ翻訳する仕組み（JITコンパイル）を使うものもあります。旅行先で即興通訳を頼むようなもので、必要な場面になって初めて翻訳が走ります。

2階で「許可」と「資源」が配られます。 OSはこのプログラムをプロセス（実行中のプログラムの単位）として登録し、CPU時間とメモリを割り当てます。画面やファイルへの出力は、OSに依頼する形を取ります。この依頼の窓口がシステムコールです。ここで権限がなければ EACCES（アクセス拒否）が返り、資源が足りなければ別のエラーが返ります。つまり2階は、失敗の種類が豊富な階です。

1階では、意味が完全に消えます。 CPUは命令を実行し、メモリから値を読み、計算し、デバイスに電気信号を送ります。ここにあるのは0と1と電圧だけです。あなたが書いた「こんにちは」という意味は、1階のどこにも保存されていません。

5階で結果が戻ってきます。 画面に文字が出ます。あなたが見ているのは5階の景色ですが、そこに至るまでに4つの階を通っています。

ここで一度、立ち止まって考えてみてください。あなたが普段書いているコードは、1階では電気のパターンになっている。この落差が、コンピュータという機械の正体です。

🔬 検証②：なぜ階を分けるのか——抽象化はエレベーター

階を分ける理由は、下の階の複雑さを隠すためです。この「複雑さを隠して簡単な入口だけを見せる」ことを抽象化と呼びます。

エレベーターが分かりやすい例です。乗るとき、あなたは「5」のボタンを押すだけです。モーターのトルクやワイヤーの張力、制御盤の配線を知る必要はありません。もし知る必要があったら、ビルの利用者は全員エレベーター技師にならなければいけません。抽象化は、使う人に全部を知ることを要求しないための仕組みです。

ただし、ここに落とし穴があります。エレベーターが止まったとき、点検の人は機械室に降りなければならないということです。普段は隠してくれていた仕組みが、壊れたときだけ姿を現す。この性質は「抽象の漏れ（The Law of Leaky Abstractions）」として知られています（Joel Spolsky が2002年に発表した有名な指摘です）。

抽象的でかまいません、というのが抽象化の約束です。しかしその約束には「壊れたときは例外」という但し書きが付いています。だからこそ、普段は4階にいていいけれど、下の階の知識には価値が生まれます。下の階の知識は、普段は使わないが、漏れたときに効くのです。

🔬 検証③：エラーは、どの階で起きるのか

地図の実用性が最もはっきり出るのは、エラーの切り分けです。実際のエラーメッセージを見ながら、どの階の話なのかを判定してみます。

実際に、よく出会うエラーを階ごとに整理してみます。ここで大事なのは、エラーの「名前」が階を教えてくれるという点です。

ここで注意したいのは、最後の行です。「全部遅い」は階を特定できないので、地図がないと一番つらい症状になります。逆に言えば、地図がある人は「まず計測する」という正しい一手を選べます。地図の価値は、答えを教えてくれることではなく、次にどこを見るかを絞ってくれることにあります。

📊 結果：階を言えるだけで、会話が変わる

地図を持つ前と後で、日常の仕事がどう変わるのかを並べてみます。どちらも同じ人が、同じ技術を持ったまま変わります。変わったのは言葉にできるかどうかだけです。

特に最後の2行が、これからの時代に効いてきます。AIが生成したコードは、4階の見た目が整っていることが多い。動くし、読みやすいし、テストも通る。しかし2階や1階の資源の使い方まで考えているかというと、そうとは限りません。階を言える人だけが「どこが危ないか」を指摘できます。

💭 考察：上の階ほど短命で、下の階ほど長寿

地図を眺めていると、ひとつの法則に気づきます。上の階ほど寿命が短く、下の階ほど寿命が長いのです。

4階の技術は数年単位で入れ替わります。JavaScriptのUIフレームワークは、AngularJSからReact、Vue、Svelteへと主役が移り変わりました。3階の言語処理系やDBサーバは10年単位で生き残りますが、それでも置き換わります。2階のOSの基本概念（プロセス・メモリ・ファイル）は数十年単位です。Unixの開発が始まったのは1969年、POSIX（UNIX系OSの標準規格）の最初の版が1988年。そして1階の基本構造であるノイマン型（プログラムもデータも同じメモリに置く方式）は、1945年の設計にさかのぼります。

この法則から、実務的な結論が3つ出ます。第一に、上の階の知識は「流行に合わせて入れ替える」ものであり、必死に固守する価値はありません。第二に、下の階の知識は投資回収期間が長い。一度理解すれば10年以上効きます。第三に、ジュニアの最初の1年は、縦に1回通すのが効率的です。横（同じ階の隣人を増やす）に広げるのは、縦が1本通ってからでも遅くありません。

もうひとつ、地図を持つと見え方が変わるものがあります。それは「分からないことが、分かる」という感覚です。地図がなければ、分からないものはただの霧です。地図があれば、分からないものは「まだ掘っていない階」になります。霧と空白は、まったく違います。空白には名前を付けられます。

📌 注目ポイント

この記事の核心を4点に絞ります。

第一に、エラーは階で切り分けられます。 エラーメッセージの名前（EACCES、TypeError、ENOSPC）は、どの階で拒否されたかを教えてくれます。これは暗記ではなく、地図に照らすだけの作業です。

第二に、抽象は普段は味方で、壊れたときだけ漏れます。 抽象のおかげで私たちは4階で仕事ができます。しかし抽象が漏れた瞬間だけ、下の階の知識が決定的な差になります。だから下の階の勉強は「無駄」ではありません。保険であり、切り札です。

第三に、上の階の変更は下の階に波及します。 4階の1行が、1階の資源を枯渇させることがあります。正規表現を1つ書き換えただけでCPUが100%になる、という事故は実際に起きます。階をまたいだ影響を想像できるかどうかが、レビューの質を決めます。

第四に、学ぶ順番は「今ぶつかっている階」で決められます。 網羅的に下から積む必要はありません。むしろ、実務で出会ったエラーの階から掘るのが、記憶にも残り、回収も早いやり方です。

💡 活用事例：30分弱で世界を止めた、ある1行

抽象化の層をまたいだ事故の実例として、Cloudflare の 2019年7月2日の障害があります。Cloudflare は世界の膨大なWebサイトの手前に立って、通信を仲介している企業です。その日、Webアプリケーションファイアウォール（WAF）の設定変更が世界のサーバーへ配信されました。

問題は、そのルールに含まれていた正規表現（文字列のパターンを表す記法）でした。特定の条件の入力に対して、計算量が爆発的に増える書き方になっていたのです。結果、世界中のサーバーのCPUが使い尽くされ、Cloudflare を経由していた大量のサイトが応答しなくなりました。Cloudflare の公開した報告によれば、停止は30分弱で復旧しています。

ここで注目したいのは、当たりの付け方です。復旧にあたった人たちは、まず「CPUが枯渇している」という1階の事実を確認し、次に「どの処理がCPUを食っているか」を3階・4階へさかのぼり、原因のルールを止めました。もし彼らが5階（サイトが見えない）や4階（自社のコード）だけを見ていたら、もっと時間がかかっていたでしょう。

この事例の構造を図にすると、次のようになります。4階の一行が、1階の資源を枯渇させ、5階の体験を破壊したのです。

同じ構造の事故は、これが最初でも最後でもありません。2012年には、米国の証券会社 Knight Capital で、8台のサーバーのうち1台だけに古いコードが残っていたために意図しない注文が繰り返され、約45分で4億ドルを超える損失が発生したと報告されています。こちらは4Fの配備手順の問題が、5Fの市場を揺らした例です。階の名前は違っても、「どの階で何が起きたか」を順にたどるという復旧の作法は同じです。

✅ 要点まとめ

読み終えたあなたが持ち帰るべきエッセンスを、5つに圧縮します。

• コンピュータは5階建てのビル。5Fが体験、4Fがあなたのコード、3Fが実行環境、2FがOS、1Fがハードウェア
• エラーメッセージの名前は「どの階で断られたか」を教えてくれる。切り分けは暗記ではなく地図の照合
• 抽象化は普段は複雑さを隠してくれるが、壊れたときだけ漏れる。下の階の知識はそのときの切り札になる
• 上の階の技術は短命で、下の階の知識は長寿。下に1段掘る投資は、回収期間が長い
• 「分からない」は霧ではなく空白。地図があれば、そこに名前を付けて、次の学習対象にできる

🚀 取り込み方

「明日から使うには何をすればいいか」を、期間ごとに分けて示します。大事なのは、最初の一歩を5分で終わる大きさにすることです。

今日（5分でできること）

直近で見たエラーメッセージを1つ思い出して、この記事の切り分け表に照らし、「何階の話か」を1行だけ書いてください。分からなければ「分からない」と書きます。それで十分です。この1行が、あなたの学習リストの最初の項目になります。

今週（小さく試す）

エラーに遭遇するたびに、次の3点をメモします。(1) エラーメッセージの先頭、(2) 自分が判定した階、(3) 実際に直った場所。1週間で5件たまったら見返してください。自分のエラーがどの階に偏っているかが見えてきます。多くのジュニアエンジニアは、4Fと2Fに集中しているはずです。

環境に応じて、次のコマンドが階の見方を教えてくれます。LinuxやmacOSなら df -h（ディスク容量＝1F）、free -h（メモリ＝1F/2F）、ulimit -n（開けるファイル数の上限＝2F）、dmesg | tail（カーネルのメッセージ＝1F/2F）を一度実行してみてください。ブラウザなら、DevToolsのConsoleタブ（4Fのエラー）とNetworkタブ（3F/5Fの通信）を見る癖を付けるだけで十分です。

今月（業務に組み込む）

偏りの大きかった階を1つ選び、一次情報を1つ読みます。2FならOSのマニュアル（Linuxの man ページなど）、4Fなら言語の公式ドキュメントの「エラー」の章、1Fならディスクとメモリの見方。この記事のシリーズを第2回から順に追うのも同じ効果があります。1か月で1つの階を「説明できる」状態にするのが、無理のないペースです。

🔥 ハマりポイント

先に進む前に、つまずきやすい4つの落とし穴を確認します。どれも「〜と思いがちだが、実は〜」という形で整理しました。

その1：下の階を全部勉強してから書こうとする

症状は、教科書が3章で止まり、実務のコードも書けなくなることです。原因は、出口のない学習を始めてしまったこと。対処法は、今ぶつかっているエラーの階から掘ることです。「CPUの設計から始める」必要はありません。あなたの場合は「配列の添字が範囲外になる理由」から始めれば十分です。

その2：エラーメッセージの後半だけ読む

症状は、関係のない記事にたどり着いて時間を溶かすことです。原因は、前半に「種類」が書いてあることに気づいていないこと。対処法は、1行目と、最初のコロンの直前を読むことです。TypeError なのか ENOENT なのかが分かれば、見る階が決まります。

その3：上の階の言葉だけで説明した気になる

症状は、「Dockerは仮想マシンより軽い」と言えるのに、なぜ軽いのかは言えない状態です。原因は、抽象を理解ではなく暗唱していること。対処法は、1段下の階の言葉で言い直すことです。言い直せなければ、そこが次の学習ポイントです。

その4：分からないことを記録しない

症状は、何が分からないのか分からなくなり、学習の優先順位が組めなくなることです。原因は、曖昧さをそのまま流してしまうこと。対処法は、分からないことを1行で書くことです。地図と組み合わせれば、「2Fの権限まわりが曖昧」のように場所を特定できます。これは最速の学習計画になります。

🔄 他の学び方との比較

基礎の学び方には、大きく3つの型があります。どれが正解ということはなく、状況で使い分けるものです。正直に、それぞれの弱点も書いておきます。

この記事がおすすめするのは、3つの併用です。トップダウンで作り、トラブル駆動で階を掘り、シリーズで縦を1回通す。 ボトムアップの長所（体系性）は、シリーズのような順序立てた読み物で補えます。ひとりで最初から最後まで積む必要はありません。

📅 今後の展望

抽象化は、これからもっと厚くなります。クラウドがインフラを隠し、フレームワークが設計を隠し、AIがコードそのものを書く。4階で完結しているように見える仕事は、今後ますます増えるでしょう。

ただし、抽象は漏れます。これは2002年に指摘されてから20年以上たっても変わっていません。むしろ、抽象が厚くなるほど、漏れたときに降りなければならない階数が増えます。だから「下の階の知識は不要になる」ではなく、「漏れたときに掘れる人だけが残る」という方向に進むと考えられます。

ハードウェア側の変化も見逃せません。単体CPUの性能向上が鈍り、並列化と専用チップ（GPUやNPU）へ重心が移ったことは、2005年にHerb Sutterが「The Free Lunch Is Over」で指摘した流れの延長にあります。この変化は、シリーズ第8回で扱う「並行と並列」の重要度を押し上げています。

そして、AIがコードを書くようになった今、評価される側から評価する側へ回る人が増えました。評価する側に必要なのは、暗記した用語ではなく「これは何階の話か」を言える力です。地図を持っているかどうかが、そのまま差になります。

🗺️ シリーズの予告：全8回で縦を1回通す

この記事はシリーズの第1回です。ここから下の階を、1回ずつ掘っていきます。すべて読む必要はありません。今ぶつかっている階から読み始めてもらって構いません。

まとめ

この記事を読んだあなたは、次にエラーに遭遇したとき、「これはどの階の問題か」を最初に考えるようになります。そして、判定できなかった階が見つかったとき、それが次に学ぶべき場所になります。

コンピュータサイエンスの基礎は、暗記する科目ではありません。地図を持ち、現在地を確認する習慣です。5階建てのビルのどこにいるのかが分かれば、次に進む方向は自分で決められます。エレベーターに乗るとき、モーターのことを考える必要はありません。ただし、止まったときのために、機械室の場所だけは知っておきましょう。

参考文献

1. Alan M. Turing, “On Computable Numbers, with an Application to the Entscheidungsproblem”, Proceedings of the London Mathematical Society, 1936 — https://doi.org/10.1112/plms/s2-42.1.230
2. John von Neumann, “First Draft of a Report on the EDVAC”, Moore School of Electrical Engineering, University of Pennsylvania, 1945（概要は Wikipedia の該当項目を参照） — https://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC
3. Joel Spolsky, “The Law of Leaky Abstractions”, 2002 — https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
4. IEEE, “IEEE Standard for Floating-Point Arithmetic (IEEE 754-2019)” — https://standards.ieee.org/
5. R. Fielding, M. Nottingham, J. Reschke (eds.), “RFC 9110: HTTP Semantics”, IETF, 2022 — https://www.rfc-editor.org/rfc/rfc9110
6. W. Eddy (ed.), “RFC 9293: Transmission Control Protocol (TCP)”, IETF, 2022 — https://www.rfc-editor.org/rfc/rfc9293
7. J. Postel (ed.), “RFC 791: Internet Protocol”, IETF, 1981 — https://www.rfc-editor.org/rfc/rfc791
8. The Open Group, “POSIX.1-2017 (IEEE Std 1003.1-2017)” — https://pubs.opengroup.org/onlinepubs/9699919799/
9. Remzi H. Arpaci-Dusseau, Andrea C. Arpaci-Dusseau, “Operating Systems: Three Easy Pieces” — https://pages.cs.wisc.edu/~remzi/OSTEP/
10. Randal E. Bryant, David R. O’Hallaron, “Computer Systems: A Programmer’s Perspective” (3rd ed.), Pearson — https://csapp.cs.cmu.edu/
11. Noam Nisan, Shimon Schocken, “The Elements of Computing Systems” (Nand2Tetris) — https://www.nand2tetris.org/
12. ACM/IEEE-CS Joint Task Force, “Computer Science Curricula 2023 (CS2023)” — https://csed.acm.org/
13. Herb Sutter, “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”, Dr. Dobb’s Journal, 2005 — http://www.gotw.ca/publications/concurrency-ddj.htm
14. Cloudflare, “Details of the Cloudflare outage on July 2, 2019”, 2019 — https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/
15. U.S. Securities and Exchange Commission, “SEC Charges Knight Capital With Violations of Market Access Rule” (Press Release 2013-222), 2013 — https://www.sec.gov/
16. Linux man-pages project, “Linux Programmer’s Manual” — https://www.kernel.org/doc/man-pages/