ブラックボックス

出典: フリー百科事典『ウィキペディア（Wikipedia）』

ブラックボックス（Black box）とは、外部から見た機能や使い方のみを知り、内部の動作原理や構造の理解は無用とされ得られる結果を利用する、装置や機構の概念。転じて、内部機構を見ることが出来ないよう密閉された機械装置を指してこう呼ぶ。

航空事故で扱われるブラックボックスについてはブラックボックス (航空)を参照されたし。

ネットワーク機器の商標としてのブラックボックスに関しては、メーカーであるブラックボックスネットワークサービス株式会社を参照されたし。

イタリアのテクノグループはブラック・ボックス (バンド)を参照されたし。

[編集] 概要

一般消費者にとって、今日の工業製品の大半はブラックボックスである。例えばテレビ受像機である。テレビのスイッチを入れて見たい番組にチャンネルを合わせることは、今日では幼児でもできる。だが、一般消費者の中で、テレビ受像機の動作原理を理解しているものは限られている。さらに、テレビの部品と回路図から、テレビ受像機を組み立てる事が出来るのは、一般消費者の中では非常に稀な存在だと言える。

逆にテレビ受像機の設計を専門とする技術者にとっては、テレビの内部構造は当たり前の知識である。ところが、もし仮に「全く未知の機構によって」たまたまテレビ受像機と同じような動作をする、（例えば原始家族フリントストーンの「石器テレビ」みたいな）装置があったとすれば、これは技術者にとってもブラックボックスである。今日では、テレビ受像機のような電子回路は、樹脂パッケージによって密封された集積回路によって構成されている。専門の技術者であっても、大規模な集積回路の内部動作の詳細を完全に理解している者は限られており、これは技術者にとってのブラックボックスにも成り得るものである。

一般的に考えられているブラックボックスの概念は、以上のような物ではあるが、今日の技術進歩の過程では、様々な物がブラックボックスとなりうる。

[編集] 技術の変化に伴うブラックボックス化

技術体系の変化に伴って、旧来の技術がブラックボックス化することもある。最も顕著な例としては、日本の電卓（電子式卓上計算機）が挙げられる。

電卓という装置は、ボタンを叩いて計算式を入力し、内部の電子回路の働きによって計算結果を画面に表示する。この装置は1960年代から急速に小型化と低価格化が進んで普及した。このようなコモディティ化が進んだ結果、電卓は利益の少ないありふれた商品となった。そのため、日本の電卓メーカーは1990年代後半からは生産拠点を海外へ移し、更には開発技術者までも現地で採用するようになって、海外で設計製造することが一般的になった。その結果、電卓よりもはるかに複雑で高機能な電子回路を設計できる技術者は国内にいるのに、電卓のような単純な電子回路を、低消費電力や信頼性・低生産コストといった求められる性能・条件を満たして適切に設計できる技術者が、日本国内にいなくなってしまったという話さえ出ている。こうなると日本国内では、電卓はブラックボックスと大差ない物になってしまったと言える。

失われた技術（ロストテクノロジー）によって作られた機械装置は、ブラックボックスの中でも、特に解析が困難なものである。

[編集] ソフトウェアとブラックボックス

なおこの概念は、物理的な機構を持つハードウェアに限らない。初期のマイコンではユーザー自身がソフトウェアを作成していたが、今日のパソコンなどのコンピュータのユーザーは既成のソフトウェアを使用するのが普通であり、使用するソフトウェアの内部を理解していることは稀である。つまり、ソフトウェアに関してもブラックボックス化が進んでいると言える。

これはソフトウェアの開発者についても言える。特に商用のOSやミドルウェアがアプリケーションソフトウェアに機能を提供するために用意しているAPI群は、開発者に対して仕様は公開しているが内部は公開していないのが普通である。ソースコードを公開していないソフトウェアの内部構造は、逆アセンブルという、非常に高度なスキルを持つエンジニアが膨大な手間と労力をかけてのみ達成できる作業によってしか知ることはできない。Windowsのような巨大なソフトウェアの全貌を逆アセンブルすることは到底不可能であるし、商用ソフトウェアは使用契約によって逆アセンブルを禁止していることが普通である。

一方でLinuxのようなオープンソースのソフトウェアでは内部構造も公開しているが、その内容は膨大であるためアプリケーションソフトウェアの開発者が理解することは時間的に困難である。そもそもAPIを介してソフトウェアの機能を利用するだけならば、わざわざ内部の詳細を知る必要はない。結局、商用・非商用を問わず、上位のソフトウェアの開発者は、下位のソフトウェアをブラックボックスとして扱っていることに違いはない。

このようなAPI群は、公開された仕様通りに機能する限りは、優れたブラックボックスであると言える。下位のソフトウェアがAPIを介してブラックボックス化されることによって、上位のソフトウェアの開発者は下位のソフトウェアやハードウェアの詳細を理解し、それらを自らの設計に折り込む労苦から解放されるのである。ソフトウェアの発展の歴史とは、このような抽象化の積み重ねの歴史である、と言うことも可能であろう。

逆にそのようなOSやライブラリのAPIが仕様と異なる動作をすると、利用しているソフトウェアにとって非常に根の深いバグの原因になりうる。残念ながらこのようなケースは稀ではないし、また市場で広く利用されているOSやライブラリのバグを修正することは困難であるから、アプリケーションソフトウェアの開発者はバグを回避してAPIを利用する必要に迫られることもある。

一方でオープンソースのソフトウェアの場合は、アプリケーションソフトウェアの開発者がソースコードを読んで内部構造を理解してバグを修正するという最終手段を取ることは不可能ではない。もっとも現実には、それができるスキルがある技術者や、それに必要な時間を割く開発組織は少ない。