3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

レイヤーの進化がコンピューターを変えた:OSの導入とBIOSの役割

Last updated at Posted at 2025-02-25

レイヤー構造とコンピュータ

はじめに

前回はレイヤーの意識を持つこと、学習の軸をはっきりさせ両輪を回すこと。をお伝えしました。
今回は実際のコンピューターの構成を例に、レイヤー、インターフェースの役割とメリットを示します。また、そうしない場合に起こることなどを、hdwとOSの狭間を例に説明したいと思います。
先の記事もあるとおり、この記事は僕個人のノウハウの共有を目的としています。初めて勉強される。伸び悩んでいる人のヒントになれば幸いです。
また、この記事は概念についての記事ですので、全詳細な手順とか、新規性厨の観点でのご指摘はご遠慮ください。軸がそもそも違います。

おことわり

この記事は、コンピューターの「歴史」を語るものではありません

これから、この記事ではコンピューターの歴史っぽいことを書こうと思います。いいですか?歴史「っぽい」ですよ?ここ大事。
技術の進化の流れとその大まかな考え方、課題感の説明と流れの説明です。歴史ではないですからね。こういう話をすると、実際にはこのメーカーが先に実装していたとか。間にこういうのがあってとか枝葉末節なツッコミ増えるので。やんなっちゃう。

技術者を目指される方に課題感とその解決のための抽象化。それを模式的に整理してお話するだけです。歴史が必要なら歴史の本を読んでください。

好意的に読んでくださる、読み手の方もそこの区別はお願いしますね。


アプリケーションでハードウェアを制御するということ

最初はアプリケーションとハードウェアなんて区別もなかなかできなかったんじゃないかな。一体になって一つの「コンピューター」を作っていたんだと思います。いきなり余談になりますが、川崎の富士通さんの企業ラボに行くと、現存する最古の「稼働可能な」リレー式コンピューターがあります。すごいですよ。スイッチをいれると、ガシャガシャリレー回路が動いて、円周率を計算してくれるんです。でも、それだけ。

ああいう世界だと、回路設計とそのコンピューターでやらせたいことは割と近くにある。

このときの構成イメージを絵にするとこんな感じ。

これが許される前提条件を整理すると。

  • コンピューターが高価で、市場が狭く、天才レベルの数学者、物理学者が一眼となって開発できる
  • 開発のための時間も十分に取れる

こんな感じです。ここでの課題って何でしょう?

Container-Step0.png

  • 同じコンピューターを作っているはずなのに、変化の早いところと、変化の遅いところが出てしまう
  • 変化の遅い部分を待ってのリリースになるので、開発速度が上がらない
  • 開発に天才レベルの数学者、物理学者を湯水のように使うので、数を作れない。だから歩留まりが悪い

最初のレイヤ分裂

開発速度とライフサイクルの違いの問題を解決するために、レイヤを次第に分割していきます。そう。ソフトウェアとハードウェアです。

Container-Step1.png
この分割により、それぞれのレイヤーで開発スケジュールを作り、開発していくことができるようになりました。

同時に機械への指示の与え方も、ユーザーライクなものが開発されていきます。そう。コンピューター開発言語の爆誕です。みんな大好きプログラマーの爆誕でももあります。

もう一度レイヤー分割のメリットを考えてみましょう。

  • アプリケーションとハードウェアの設計、開発をそれぞれ別に進められる
  • 同時に開発難易度を下げることで、開発に必要な人のスキルレベル。知識レベルをぐっと下げることができる
  • 要員の確保が容易になり、たくさんのコンピューターを作れるようになってくる(これだけが原因じゃないけど)

そんなメリットがあったのです。だいぶ楽になりました。

この状態しばらく続いたあと、事態は変化していきます。皮肉にも開発難易度を下げたことで価格がこなれてきます。工業製品化していくのです。
最初の大口顧客は金融業界でした。彼らは取引の内容、残高状況、債権の情報、大量の情報を蓄積し、管理する必要がありました。金融商品が複雑化していくと到底紙と人手では間に合わなくなったのです。
金融業界のニーズに火が付くと、内包されていた課題が顕在化します。

  • ハードウェアを直接ユーザープログラムで開発するため、同じようなコード(ボイラープレートコード)をアプリケーションごとに書く必要がある
  • ハードウェアの変更影響がアプリケーションの広範にわたる
  • 実質的にハードウェアのライフサイクルの終了がソフトウェアのライフサイクルの終了となってしまう

すでにコンピューターは巨大産業になりつつありました。このまま放っておくことはできません。

こういった課題に対応することが急務になって来たのです。

新たなレイヤー分割

コンピューターの世界は不思議なものでこの問題にも、あらたなレイヤーを分割することで対応していきます。

アプリケーションとハードウェアの間にもう一つ別の層を追加することにしました。初期のOSの誕生です。
Container-Step2.png
初期のOSはリッチなメモリ管理もスケジュール管理もマルチプロセスもない。ユーザーですらシングルユーザーを前提としていて今のものとは全く趣が異なります。初期のOSの目的は、あくまで前述の課題に応えることでした。すなわち、ボイラープレートコードの削減です。

  • ハードウェア制御:各種デバイスを制御するためのルーチン
  • メモリ管理:最初期はメモリ領域予約程度の簡素なルーチン
  • ジョブ管理:プログラムのロード、実行、終了を制御する仕組み
  • 標準ライブラリ:数値計算、文字列処理などの基本的なライブラリ

まだまだOSと呼ぶには貧弱で、機能的には標準ライブラリの集合に近い状態でした。しかし、それでも小さな薄いレイヤが誕生したことは大きな意味を持ちます。このささやかなレイヤがこのあとのコンピューターの発展を支えていくことになることは皆さんご存知のとおりです。

さて、一旦「ボイラープレートコードの削減」という目標は達成れました。その副次的な意味は

  • 開発者が単位時間あたりに開発できるコードの増加=開発生産性の向上
  • 品質の向上

と、とても意義の大きなものでした。この時期、市場の要求に応えるため、ハードウェアもOSも猛烈な速度で進化しようとしていました。しかし、ここで一つの問題が生じます。

どんなにハードウェアを進化させても、OSのコードが進化するまでその能力は引き出せません。そればかりかドラスティックにハードウェアが変わると、OS自体が動作しません。

OSが複雑化したくても、ハードウェアが変われば最初から作り直しです。迂闊にコストをかけて進化させることができません。

こうして、OSとハードウェアは互いに足かせとなり、進化を妨げるようになっていきました。

IBMのアンバンドリングと、見えないレイヤーの形成

OSとハードウェアが互いに進化の足かせになっていたこの時代、IBMが決断したのは ハードウェアとソフトウェアの分離(アンバンドリング) でした。これは単なる商業的な戦略ではなく、結果としてコンピューターのアーキテクチャに新たなレイヤーを加えることになりました。

それまでは、ハードウェアとOSは一体のものとして提供されていました。各メーカーは自社のコンピューターに最適化されたOSを開発し、セットで販売していたのです。しかし、これではハードウェアの改良がOSの対応を待たねばならず、逆にOSの進化もハードウェアの制約を受けてしまいます。

IBMが行ったアンバンドリングは、 「OSはOSベンダーが作る」「ハードウェアはハードウェアメーカーが作る」 という、新たな分業体制を生み出しました。これによって、ハードウェアの進化とOSの進化を切り離し、それぞれが独立して進化できるようになったのです。

Container-Step3.png

つまり、ハードウェアとOSの間に「市場レイヤー」という新しい見えないレイヤーが誕生したといえます。OSを独立した製品として販売することで、多くのOSベンダーが参入し、ハードウェアメーカーも多様なソフトウェア環境を提供できるようになりました。

しかし、レイヤーを増やせば、新たな課題が生まれるのもまた歴史の必然です。ハードウェアとOSが分離したことで、今度は 「異なるハードウェア間での互換性をどう確保するか?」 という問題が生じました。

増えすぎた多様性の問題

ハードウェアメーカーが独自に製品を開発し、OSベンダーがそれぞれのOSを提供するようになると、次に直面するのは 互換性の問題 です。

異なるメーカーのハードウェアは、それぞれ異なる設計を持ち、メモリアクセスの方法、周辺機器の制御、ブートプロセスの仕様などが機種ごとにバラバラでした。つまり、あるOSをあるハードウェアに移植するたびに、大量のコードを書き換えなければならないという状況が生まれてしまったのです。

これは、まるで「プログラムを毎回違う言語で書き直さなければならない」ようなもので、せっかくハードウェアとOSを分離しても、結局は個別対応のコストが膨らんでしまうという本末転倒な結果を招きました。

もう一つのレイヤーの追加=BIOSの登場

この問題を解決するために登場したのが、BIOS(Basic Input/Output System) です。

Container-Step4.png
BIOSは、OSとハードウェアの間に新たな抽象化レイヤーを設けることで、異なるハードウェアでも同じOSが動作できるようにする仕組みでした。具体的には、BIOSが以下のような役割を果たします。

ハードウェアの初期化(電源投入時に基本的なデバイスを設定)

OSへのインターフェース提供(OSが統一された方法でハードウェアを扱える)

ブートプロセスの管理(ストレージからOSをロードする処理を標準化)

BIOSが導入されたことで、OSは特定のハードウェアの詳細を意識することなく、標準化されたインターフェースを通じて動作できるようになりました。つまり、BIOSというレイヤーの追加により、OSはハードウェアの違いを吸収し、移植性を高めることができたのです。

こうして、ハードウェアの多様性を受け入れながら、OSの開発をスムーズにする新たな見えないレイヤーが導入されました。

長くなりました。この話はまたまだ続きますが、一旦ここで中締めと致します。

まとめ:レイヤーがもたらした変化

ここまでの話をまとめます

  1. ハードとソフトの分離
  2. OSの誕生:ハードウェアとアプリケーションの間にレイヤーを設け、ボイラープレートコードを削減。
  3. アンバンドリング:OSとハードウェアを分離し、「市場レイヤー」を導入することで進化の自由度を確保。
  4. BIOSの導入:OSとハードウェアの橋渡し役を担い、異なるハードウェア上でも統一的にOSを動作させる仕組みを提供。

このように、コンピュータの世界では技術的な課題に対して「レイヤー」を導入することで、ソフトウェアとハードウェアの進化を加速させてきました。

しかし、BIOSの導入によってすべてが解決したわけではありません。むしろ、これにより新たな問いが生まれます。

  • BIOSだけでハードウェアのすべてを抽象化できるのか?

  • OSはどこまでハードウェアを意識するべきなのか?

  • より複雑なハードウェア構成にどう対応するのか?

こうして次なる段階として、OS自体がさらに強力なハードウェア抽象化機能を持つようになっていきます。


次回予告:OSによるハードウェア抽象化の進化

BIOSによって基本的な互換性が確保されたものの、ハードウェアはますます多様化し、OS側でもさらなる対応が求められるようになりました。そこで登場するのが、OSカーネルによるハードウェア抽象化の進化です。

次回は、OSがどのようにしてハードウェアを抽象化し、より柔軟で強力なシステムを実現していったのかを掘り下げていきます。
・OS内部の層分裂
・デバイスドライバの役割
・メモリ管理の複雑化
・HAL(Hardware Abstraction Layer)の登場
・仮想化技術による抽象化の進展

次回も、コンピューターの進化をレイヤーの視点から紐解いていきましょう!

諸般の事情により、この連載は今回が最終回です。モグ先生の次回作にご期待ください。

長い間応援ありがとう

第一部 完

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?