昔のMacintoshの仕組み3 意外と原始的なイベントドリブンとマルチタスク化

GUIな環境では基本的に上から下への手続き、バッチ処理的なプログラムではなく、マウスクリックやウィンドウの表示、サイズ変更といった各種イベントに従って動作を記述する「イベントドリブン」というプログラミング手法が必要になる。当然初期のMacもイベントドリブンなのだが、そのイベントの扱い方が今想像されるものとは若干異なっていた。

現代的なGUI OSにおいてイベント処理はどうするのが普通だろうか。各種イベントをOS側で監視して、アプリケーションが設定した適切なイベントハンドラを呼び出すのが普通の考え方だろう。それがオブジェクト指向っぽいし。

ところが昔のMacでは、OS側がやってくれるのはイベントをキューに追加するところまでである。アプリケーション側でGetNextEvent()という関数を呼んで、キューからイベントを取り出し、それがどんなイベントであるかイベントマスクで検査し、「あ、マウスクリックだね、じゃあこれ」「ウィンドウ隠れたのね、じゃあこれ」みたいにいちいち自分で分岐処理を書かなければいけなかった。なので一般的なアプリケーションは、初期化処理のあとで無限ループを書いて、その中でGetNextEvent()を呼び、必要な処理を行うということになる。こういう形だとスムーズなタスク切り替え出来ないんじゃないかと思うでしょう。ご安心下さい。Macはもともとシングルタスクでした。Macを起動すると、デスクトップを表示し、アイコンを操作するFinderというアプリケーションが自動的に起動するけど、これは単にディスクのブートブロックに書かれているので優先的に起動するだけの、ただのアプリケーション。Finderの上でアイコンをダブルクリックすると、FInderは終了し、ダブルクリックしたアプリケーションが起動する。アプリケーションはメモリもCPUも、すべての資源を独占して動作するわけで、マルチタスク的な気を使う部分はなかったわけである。Macの前のLisaがマルチタスクだったのに、Macがいろいろ捨ててたのはなんでか。それはやはりメモリが128KBと、とても少なかったことに起因するのだと思う。

Macのメモリが512KBになった頃 Switcherというアプリケーションがリリースされる。これはFInderを作ったアンディ・ハーツフェルドという天才プログラマが作ったもので、複数のアプリケーションを同時に立ち上げて、素早く切り替えられるようにしたものだ。それまでMacの全メモリをアプリケーションに割り当てていたのを、Switcherが適切なメモリを分割して割当てるのだが、もともとマルチタスクに対応していなかったMacで極力互換性の問題が生じないようにしたためだろう。画面には同時に立ちあがっているプログラムの一つだけが表示される仕組みだった。これはシングルタスクのMacの画面そのものである。メニューバーの右端にタスク切り替えボタンが表示され、これをクリックすると、メニューバーを含む画面全体が「ズバッ！」と横にスライドして次の画面が現れるのである。なお、これは正確にはマルチタスクとはいえない。複数のアプリケーションが同時にメモリ上に読み込まれて入るが、バックグランドに行っているアプリケーションは停止状態で待機することになる。しかし、Macの多くのアプリケーションはバックグラウンドで長時間計算し続けるようなたぐいのものではなく、ユーザーがインタラクティブに操作するものであったので、十分実用的だった。

Switcherは大変安定動作したうえ、増えたメモリを有効活用できたため、Appleから商品化されることになり、それなりに普及していた。その後アンディ・ハーツフェルドはさらに考えを進めたServantというソフトを作り上げる。

Switcherの場合、「Switcherというアプリケーションの設定画面」で同時起動するアプリケーションを登録する必要があった。だが、Servantは、Finderを置き換える本格的なGUIシェルであり、かつFinderとほとんど画面も操作も一緒でいわば拡張されたFinderであった。デスクトップから普通に次々アプリケーションを立ち上げ、後ろには他のアプリケーションのウィンドウがそのまま見えていて、クリックすれば前面にきて操作ができる。今のMacやWindowsとほぼ同じである。ただし、やはり後ろに回ったアプリケーションはCPUタイムをもらえず。停止状態であった。まあ、OSそのものに時分割機能もないし、アプリケーションからタスクを他に回すAPIなんかもServantというアプリケーションでは追加しようがなかったし。しょうがない。

Servantではバックに回ったアプリケーションにイベントもいかないし、前面のウィンドウによって隠れたりした部分がどうなるか、白く抜けてしまってウィンドウ動かしたらみっともないことになるんじゃないかと思ったが、そういうことは起きず。前面ウィンドウの移動に従って隠れていた部分がきれいに復帰するのだ。おそらくアプリケーションの前後関係が変更されるタイミングでアプリケーション配下のウィンドウのビットマップを保存していたのだろうと思う。

Switcherでは各アプリケーションが使用するメモリ割り当てはSwitcherが勝手に行っていたが、Servantではユーザーがアプリケーションの情報ウィンドウで最大メモリサイズを設定することができるようになった。

他にもServantは、ファインダー上のアイコンのサイズを手軽に変更できたり、スクロールバー以外の部分をハンドツールでスクロールできるようにしたり、さらにはファイルの中に収められたリソースを覗くことができたりと、ずいぶんラジカルに機能を追加していた。ただ、このソフトはついに正式版になることはなく、β版として流通した後開発は中止される。

Servantがすっかり過去のものになった頃、ついにMacがマルチタスク化されることになった。Finderが MultiFinderになったのだ。これが出た時驚いた。Servantのラジカルすぎる部分をそぎ落として、今までのFinderにマルチタスク機能を足したものにしか見えなかったからだ。起動アプリの一覧表示、「情報を見る」からのメモリ割り当てなど、MultiFinderとServantは驚くほど似ていた。ただし、こんどはバックグラウンドアプリにもタスクが回されるようになって、ほんとに一応マルチタスクになってはいたのだけど。当時のAppleの公式見解として、「Servantとは独立して開発された」というものがあった。逆にそう言わざるをえないほど似ていたという話だ。

「一応マルチタスクになった」と書いたのはわけがある。このときのマルチタスク化は、今のMacOSやWindowsのような、プリエンプティブ・マルチタスクではなく、コオペラティブ・マルチタスクだった。プリエンプティブ・マルチタスクというのは、OSが強制的にアプリケーションのタスクを区切って次次タスクを切り替える方式だが、コオペラティブ・マルチタスクというのは、アプリケーションが「はい一旦スタジオにお返しします」とOSに制御を戻し、OSが次のアプリケーションに仕事を回すという手順が必要な方式だ。協調的マルチタスクとも言う。

さて、もともとシングルタスクだったMacのアプリケーションは、行儀よく協調的に書かれているわけではない。他のアプリケーションが同時に動くことなんかそもそも想定してすらいない。それなのにこの方式で動いたのはなぜか。

どんなMacアプリでもまず確実に、超頻繁に呼び出すAPIがある。GetNextEvent()だ。なので、GetNextEvent()を呼び出されたタイミングでOSが他のアプリに切り替えるようにしたのだ。これでスムーズにタスクスイッチングが可能になった。ただし、もともとGetNextEvent()は、「今最新のイベントを返して」っていうAPIであり、この呼び出しに時間がかかることは想定されていない。アプリケーションとしては即座に返事が帰ると思ってるAPIであまり長々よそ見をしてもらっては困る。なのでOSもこのAPIで呼ばれたときには、タスク切り替え一周したらできるだけ速やかに戻ってくるようにしていた。

ただ、イベント取得は実際には必ずしもすぐに来なくてもいいものだ。「キー入力が来るまで待ちたい」ときに「まだ？まだキー来ない？」となんども呼び出すのは効率が悪い。自分だけがMacを専有していたときはそれでもよかったのだが、複数のアプリが強調するなら、ここは効率を重視したい。

というわけで、MultiFInder導入と同時に、GetNextEvent()の上位版API。WaitNextEvent()が登場する。これはGetNextEvent()とほぼ同じだが、待ち時間の引数が追加されて指定した時間の間待つから帰ってこなくていいよ。というものだ。つまりあるアプリケーションが「100msの間もどってこなくていいよ」といえば他のタスクにその分CPUを割り当てることが可能になる。

なお、これもやはり待ち時間をどうするかなどめんどくさいところが多かったし、プリエンプティブ・マルチタスクのMacOSXが導入されるとプリエンプティブなタスク切り替えとコオペラティブなそれが競合してしまってはなおさら無意味になる、結局昔のMacの互換APIであるCarbonは、Carbon Event Modelという、イベントハンドラをOSが適切に呼び出す形式のAPIを追加することになった。まあ、そんなすったもんだのあげくに互換性を保ちながらモダンになりかけてたCarbonもあっさり64bit非対応で廃止されちゃったんですけどね。

昔のMacintoshの仕組み2 リソースとファイルタイプ

一般的なコンピューターのファイルと言うものは、ファイル名で検索される単一データの塊である。「ファイル」の「中身」は当然一つであった。"readme.txt"というファイルはテキストファイルであり、その中身はユーザーに読んでもらうためのテキストであるのが当たり前と思うだろう。

ところがMacにおいてファイルと言うものは２つの「中身」からなっていた。あるファイル名で示されるファイルには２つの「中身」があった。それはデータフォークとリソースフォークである。データフォークは通常のデータであり、他のコンピューターでいう「ファイルの中身」である。一方リソースフォークには整理された任意の、様々な情報を格納できた。ファイルマネージャーがファイルのデータフォークを読み書きする。これは他のOSにおける基本的なファイルI/Oとだいたい同じで、オープンし、頭から読み書きし、あるいは任意のバイト数までシークし、クローズする。一方同じファイルをリソースマネージャーを通じてアクセスすると、４バイトのリソースタイプと、整数のリソースIDで管理されるデータの塊にアクセすることが出来た。リソースはバイト数での位置などを考慮することなく、様々なデータ、画像や文字の属性、アイコンなどといったものを名前で格納することができた。つまりリソースはもう一つのファイルシステムのように扱えたのだ。

アプリケーション・プログラムの実行コードはCODEリソースとして格納されていたし、アプリケーションや書類のアイコンはICONリソースだった。スプラッシュスクリーンに表示される画像などは「PICT」リソースとして格納されていた。

Macにおいてアプリケーションや書類のアイコンは、アプリケーションファイルのリソースフォークに収められていた。アプリケーションバイナリの収録されたフロッピーディスクをMacに挿入すればマウントされているハードディスクなどの上にある「デスクトップファイル」もしくは「デスクトップデータベース」に「アプリケーションのアイコン」「そのアプリケーションで作成される書類のアイコン」「アプリケーションと書類の関係」がコピーされ、自動的に書類のアイコンも更新された。なのでファイルの関連付けを行うインストーラは不要で、アプリケーションファイルをハードディスクにコピーするだけでOKだったのだ。

昔のMacintoshにおいて、拡張子というものはなかった。書類の種類を示す情報はファイルのメタ情報である「ファイルタイプ」に収められていた。テキストファイルのファイルタイプは「TEXT」であり、アプリケーションファイルのファイルタイプは「APPL」と決められていた。デスクトップでアイコンをダブルクリックすると、ファインダーがそのファイルのタイプがなんであるかを調べ、「APPL」であれば実行ファイルとしてメモリに読み込み実行する。「TEXT」であれば、デスクトップデータベースを検索してテキストファイルを扱えるアプリケーションを探し、それを実行する。

このとき、テキストファイルを扱えるアプリケーションが複数あったらどうしたらいいのだろう。その場合、ファイルに付けられたもう一つのメタデータ「クリエイター」を調べる。「クリエイター」は、そのファイルを作成したアプリケーションのID情報である。すべてのアプリケーションは「クリエイター」をもち、それらは重なってはいけないものとされていた。たとえばPhotoshopのクリエイターコードは「8BIM」だった。なお、Photoshopが作成するPSDファイルのファイルタイプは「8BPS」である。クリエイターコードは、アプリケーションを開発したらAppleに登録する必要があった。ファイル保存時には、ファイルタイプと自分自身のクリエイターをメタデータに保存する。

なので、基本的にファイルをダブルクリックすれば、前回それを編集したアプリケーションが立ちあがって、それを開くことになっていた。

このような、複数の中身を持ち、ファイルタイプやクリエイターと言うメタデータを持つファイルはパソコン通信やインターネットでは扱いにくかった。Macにおいては当然保持すべき情報だが、他機種では無意味である。Macは拡張子を使わない文化だった（拡張子にあたる情報がファイルタイプだった）ため、ファイル名にいちいち「.txt」だの「.psd」だの付ける必要がなかった。ネットワークでファイルをやり取りする際にもメタデータやリソースフォークを保持するようにした。これがMacBinaryである。メタデータやリソースフォーク、データフォークをシリアル化して送受信する仕組みで、本来通信ソフトが勝手にエンコード、デコードすることを想定したものだった。つまりMacから送信時自動的にMacBinaryにエンコードされ、別のMacで受信する際Macのファイルシステムに会うようにデコードされるはずだった。ところが、ただのJPEGやGIFファイルみたいな汎用データにもメタデータがついてしまうため、これを他機種でダウンロードすると表示できないということになった。汎用の通信に出す場合MacBinaryエンコードせずに送信するなどの工夫が必要だったのだが、Mac初心者がよくわからないままMacBinaryデータをばらまき、他機種ユーザーに蛇蝎の如く嫌われることになったのだった。

昔のMacintosh仕組み1 メモリ管理

ちょっと今日から何回か、昔のMacのプログラミングとかOSの構造とかについて話していきたいと思う。初期のMacのUIはいまのパソコンの殆どに影響与えてるし、ぱっと見いまのWindowsやLinuxのGUIと変わらないけど、そこには昔ならではの違いとかいろいろあるので面白いと思うんだよね。

Macintoshはほぼ初めてのGUI専用パソコンだった。ほぼというのは、その前年に同じAppleからLisaが出ていたからだけど。Lisaはそのプロジェクトから追い出されたジョブズがすげえdisったのでほとんどなかったことにされている。

それはさておき、Macにおいてもプログラムを組む際、ヒープ領域にメモリブロックを確保する必要はあるわけで、そのためのAPIが用意されていた。NewPtr()とNewHandle()である。NewPtr()は、引数に指定したバイト数のメモリブロックを確保し、その先頭アドレスを返す。HewHandle()は、指定したバイト数のメモリブロックを確保し、その先頭アドレスを、OSが管理するマスターポインタエリアに格納し、そのマスターポインタが格納されているアドレスを返す。Macにおいて、「ポインタ」は領域の先頭アドレスを指し、「ハンドル」は「領域のアドレスを収めたマスターポインタのアドレス」を指す。つまり、ハンドルというのは二重参照ポインタである。

ハンドルにアクセスするためには二回アドレス解決しないといけないのでポインタより遅い。なぜそんな仕組みがあったかというと、Macのメモリが少なく、また、MMUなんて高級なハードウエアを備えていなかったことによる。少ないメモリで、ハードの助けを借りずなんとかやりくりするための工夫が「ハンドル」という仕組みだったのだ。

必要な領域を次々確保していった場合、いつかメモリが足りなくなる。NewHandle()でメモリを確保する際、必要な連続領域が残されていなかったらどうなるか。

その場合OSはヒープ空間上でメモリ領域を「ごそっと」ブロック転送するのだ。必要な領域を確保。必要なくなった領域を開放という作業を続けると、メモリ上に島のようにあちこちにブロックが残っているが、連続した領域が必要なだけ残らないという状況になる。つまりメモリの断片化である。このとき、空き領域を詰めて、大きな空きを確保しようとする。昔NetNews上でこの話をしたら、UNIX使ってる人たちに「うそ！、そんな原始的なことやってんの？？」と驚かれた。実際やってたんです。MMUなかったからね。しょーがねえ。

ヒープ上でメモリブロックが移動すると、マスターポインタが書き換えられる。なので、ハンドルから二重参照でアクセスする限りなんら問題は起きない。けれど、ビットマップ画像の書き換えなど、大量のデータを高速に扱う必要がある場合、ハンドルを毎回二重参照するのではなく、ローカル変数にマスターポインタの値を入れて使うことがよくあった。こういう場合ハンドルを「ロック」するのだ。ロックされたハンドルはOSによって移動させられることはない。もちろんメモリ資源の有効活用のため、操作が終わったらすぐに「アンロック」する必要があった。

さらにハンドルには、「パージ可能フラグ」という属性があって、これをONにしていると、メモリブロック移動で必要な領域を確保できない場合、パージ可能なハンドル領域を「潰す」ことになっていた。これをONにするのは、ハンドルのデータをディスクに書き出すなどして、あとで復旧できる状態のものに限られた。つまり、OSの都合で消されてもアプリケーションの責任で復旧できるメモリ領域だけこのフラグをONにしていたのだ。

なお、GUIの象徴ともいえるウィンドウの各種属性を保持するWindow構造体に関して、Macintoshはハンドルではなく、ポインタで確保していた。画面表示の根幹に関わる部分なので少しでも高速化したかったのだと思う。そのおかげで、初期Macのプログラムでは書類ウィンドウを予め決めた数しか開けないというアプリケーションが多かった。ハンドルでないポインタ領域は移動もパージもできないので、メモリ断片化しないためには、プログラム起動時にWindow構造体を必要なだけ確保しておく必要があったのだ。

そういうふうに、プログラマがメモリ領域の移動や開放を意識する必要があったため、Cが普及し始めた頃、UNIXを使う大学生や研究者がMacでmalloc()を使って酷い目に遭う状況が頻発した。malloc()はポインタを返す関数なので、当然Macにおいては内部でNewPtr()を使用している。つまりメモリが足りなくなったときにハンドルみたいによろしくやってくれないのだ。当時「Macでmalloc()使うなんて素人が！」的な視線が浴びせられた。結果としてUNIX使いからMacに対するヘイトが溜まってしまった事情があったりする。なんというか文化の違いだよねえ。

西崎義展という人

「宇宙戦艦ヤマト」は松本零士監督作品であり、ヤマト以降流行した一連の「松本アニメ」のはしりと思われているきらいがあるが、キャプテンハーロックや銀河鉄道999といった「松本零士作品」とはやはり趣が異なる。それは結局のところ稀代の山師、西崎義展プロデューサーの個性なのだろう。

西崎義展氏の伝説は数多い。ガイナックスにヤマトのリメイクを作らせようとして札束の入ったトランクケースを持ってきて「すきなだけ持っていきなさい」と言ったとか（あとで秘書が回収）いう話は岡田斗司夫氏の話だが、それ以前に大塚康生氏の話として、東京ムービーにすげえリムジンで乗り付け、同じく稀代の山師だった東京ムービーの藤岡豊氏（「リトルニモの監督にスター・ウォーズ帝国の逆襲のゲイリー・カーツを引っ張ってきて何十億円もドブに捨てた人）と会談。その際大塚氏に「お手を拝借」と手を出させ、その手の中で指を一本二本立てて、「これでどうです？」とヤマトへの参加をもちかけたとか。指一本が一億だとか、そういうとんでもない人なのである。リムジン、手の中ですげえ金額の交渉。トランクいっぱいの札束。こういいう「漫画みてえな金持ちぶり」を実際にやってた人が実在したってだけですげえよなあ。

そもそも手塚治虫の虫プロで働いてて、いつのまにか「海のトリトン」の権利を自分のものにしてたり、「宇宙戦艦ヤマト」を虫プロで作る予定が、虫プロ潰れたので自分の「オフィスアカデミー」で作ったりしてるのだけど、すげえトラブルマンだったのだ。当然手塚治虫からはすげえ嫌われたらしいよ。

ヤマトに関しては、第一作の放送は「アルプスの少女ハイジ」と「猿の軍団」に視聴率取られて撃沈。ぼくらみたいな一部熱心なファンを生んで終了するはずだったのが、再編集映画が大ヒット。続編の「さらば宇宙戦艦ヤマト」で完全に1980年代アニメブームの牽引者になった。さらばのTV版「ヤマト２」から、「TVスペシャル、宇宙戦艦ヤマト新たなる旅立ち」「ヤマトよ永遠に」までは本当にアニメ業界のトップにヤマトありで人気を誇っていた。「ヤマトIII」が初代と同様視聴率不振に陥って2クールで終了してしまったのだけどその後の「宇宙戦艦ヤマト完結編」は、こと作画と言う点では最高峰だった。それ以外はほんとうにグダグダだったのだけど…

ヤマト完結編発表時、沖田艦長の復活がうたわれ、西崎氏は「ファンが納得する方法を考えた。がっかりさせない」みたいなことを雑誌で言っていたのだが、その内容は「佐渡先生の誤診で実は脳死に至ってなかった」、佐渡先生が客席を向いて「全国の皆さんに坊主になって詫びにゃならん」とお詫びするという前代未聞の「納得する方法」だった。

ちなみに、ヤマト完結編直後から復活編の構想は語られていて、ヤマト復活三カ年計画というものがぶちあげられていた。その第一弾が「オーディーン　光子帆船スターライト」である。あれは一応ヤマトと同じ世界の過去の話だったのだ。その後、若き日のデスラーの戦いを描く「デスラーズウォー」があって、「ヤマト誕生編」とかなんかいろいろ構想はあったっぽいが、結局オーディーンが赤字になったので、手っ取り早く完結編のあとの「復活編」を劇場向けにプレゼンしながらOVAシリーズのYAMATO2520を作っていたらウエストケープコーポレーションが倒産しちゃって未完に終わる。そう、ヤマト復活編はずい分昔に予告されていたのだ。だけど会社の倒産。西崎氏の逮捕などが重なって長くお蔵入りになってしまう。西崎氏、最初は覚醒剤所持で、後に銃刀法違反で何度か捕まってるのだ。なんかメディアの業界人として麻薬や覚醒剤ってのはわりかし違和感ないのだけど、銃刀法違反が謎すぎる。クルーザーに擲弾筒付きの自動小銃と実弾、擲弾を大量に所持していたのだ。海賊対策とか、尖閣諸島に上陸した石原慎太郎の護衛用とか言ってたらしいけど、異様だろう。

西崎氏が刑務所行きになっていた時期。獄中からの手記を公開するWebサイトがあった。腰痛がひどいのに手当してもらえない、もう獄中で死んじゃうかもみたいな話とか、初期のヤマトの企画書や、お蔵入りしかけていた復活編のプロットなんかを公開してたので、実は非常に貴重な資料だったりする。Webアーカイブに残っているのでリンクしておく。

西崎義展の手記（Web Archive)

宇宙戦艦ヤマト2199のすごい所と残念なところ

宇宙戦艦ヤマト2199は、初代宇宙戦艦ヤマトのリメイクアニメなのだが、1974年放送の初代にはなかった展開を多く含んでいる。それらのいくつかは、初代の企画段階でやるはずだったプロットを拾い上げたものだったりする。ヤマト艦内での反乱や、デスラーの暗殺騒ぎなんかがそれだったと思う。ただし、なぜそれらが初代の放送時にカットされたかというと、最初の企画が52話。放送決定時39話。放送開始したら視聴率が低く、話数短縮され実際の放送話数が26話と、どんどん話数が削られた結果なのだ。ヤマト2199は26話で初代と同じ話数である。同じ話数でカットされた話を入れ込むのだから、余裕がなくなる。70年代と現代では望まれるテンポも違うので、昔より詰め込むのは正しい判断だが、どうしても省略される「間」とか「雰囲気」が出てきてしまう。こういう部分が「恐怖」「不安」「絶望」といったものを担っていたわけで、テンポが速くなったことでそれらの感情作用がオミットされた部分はあると思う。さらに、ヤマトIIIのシャルバート星の過去をイスカンダルに移植したり、同じくIIIで登場した次元潜航艇のガルマンウルフことフラーケンを主要なキャラに採用したり、なおさら詰め込んでいる。脇役だがさらばとIIのガトランティスも登場している。

ヤマトが作られ、伝説になり、各種資料が発掘され、表も裏も掘り尽くされた。だからこそ最大限に「ヤマト」を詰め込んだ2199はすばらしい。ヤマトファンならあの作品のあらゆる部分で「おー、こう来たか！」「あーこれ入れたんだ」「すげー」って感動するんだよ。

今の時代にヤマトを作るメインスタッフはほぼ間違いなく子供の頃ヤマトファンだったのだ。キムタクの実写ヤマトだって2199だってそう。みんな自分なりの「ヤマト」を再現したくて作る。だから同じ立場で視聴するこちらは「おおー」と感動するしかないのだ。実写ヤマトは、実写で今作るなら、顔の青い日本人をガミラスと言い張るのは無理があったから当然ああなった。今の時代に実写で、地球人と全く同じ容姿の異星人を出すのはさすがに無理があるのだ。だからあれはあれで正しいのだ。

では2199の肌色が違うだけの異星人は良いのかといえば、アニメならまだそれが通じるとしか言いようがない。ついでに言わせてもらうと、2199では古代アケーリアス文明が設定されていて、星間ゲートを作った文明とされており、さらにあらゆるヒューマノイドの遺伝子の源とされている。これは昔のヤマト完結編の回遊水惑星アクエリアスと相同なのだけど、アクエリアスが生命の起源、単細胞生物のDNAを供給したのに比べ、アケーリアスはもっと近い「人類の遺伝子」を担っていたっぽい。このへんはね。SF業界ではJ.P.ホーガンの「星を継ぐ者」発表以降、逃げ場を塞がれてしまっているのだよ。単細胞生物の時点で同じ起源を持っていたと言うだけでは、同じ類人猿になりようがない。同じなら比較的近い時代、ホモサピエンス発生の時代に別れていないといけないという制限が課せられた。初代ヤマトの1974年にはまだJ.Pホーガンは小説発表してなかったのでしょうがない。

そういう前提で、今の時代に作られたヤマト2199は、昔のヤマトファンがどうしても大好きにならざるをえないところまで作り込まれたすごいアニメなのだ。それでも不満点は残ってしまう。それは後の時代に作り直しているからしょうがないことではあるのだけど。

初代ヤマトは、もう後がない地球、ヤマトが間に合うのかわからないという点を常に強調していた。特に前半毎回「人類滅亡まであと何日」と強調し、恐怖を煽っていた。イスカンダルの技術を移転したことでヤマトは前半無双するのだが、常にギリギリの勝利を得、なにか一つ間違ったら負ける恐怖を煽っていた。火星までの最初の短距離ワープだけで艦体を損傷するほどのダメージを得たり、木星の浮遊大陸を破壊する波動砲を使った後、冥王星で波動砲より強力な反射衛星砲に何度も撃たれたり、常にギリギリ感を出していた。

ドメル将軍が登場してからはむしろ勝てたのは敵の社会的な瑕疵のせいみたいな勢いだった。後半ヤマトが勝ち続けたのはデスラーがアホだったせいだ。そう、後に誇り高い好敵手、さらには頼りになる同盟者になるデスラーだが、第一作ではひたすらええカッこしいでヤマトを倒す機会を自ら葬りさる無能君主だった。

七色星団の決戦において、ドメルはヤマトに万全の体制でのぞみ、ヤマトの方は本当になんで沈まなかったのがわからないくらいに追い詰められる。瞬間物質移送器による戦闘爆撃機の波状攻撃に、ヤマトは全くても足も出なかった。戦闘機、急降下爆撃機の連続攻撃に振り回されて一切有効な手を打てなかったあと、一息ついて気の緩んだヤマトの正面にドリルミサイルを搭載した超大型爆撃機がワープアウトした瞬間。みな驚愕に囚われ、森雪は恐怖のあまり床にへたり込む。あの絶望感はすごい。残念ながら、2199ではあの絶望感を表現できていなかった。

その後ドリルミサイルを反転させてドメル艦体を殲滅した後も、旧作では艦艇にとりついたドメルが自爆を敢行するその瞬間。沖田艦長が艦艇部の乗組員に即座の避難勧告、乗組員が本当に慌ててハシゴを登るが自爆に巻き込まれる。ヤマトの艦底がごっそり破壊される大被害を被ることになるのだが、2199では波動防壁の修復に成功してドメル自爆による人的被害なしになるため、あの自爆から逃げようとする恐怖がほんとに薄まってしまっていた。

旧作の無理や無茶を、ある程度納得できる設定にまとめ上げたのはすごいのだけど、そのためにどうしても緊張感が薄れてしまったのだよなあ。

宇宙戦艦ヤマト（旧＆2199）における科学力、真田さんの異常性

そもそも宇宙戦艦ヤマトという作品は無理がある。いくら異星の技術を取り入れ、人類最後の力を結集したとは言え、たった一隻の戦艦で宇宙に覇を唱える軍事国家の支配する宙域を踏破し、成り行きというか必然というか、旧作では敵国を滅ぼすほどの戦果を上げるなんて無茶も良いところだ。それを可能にしたのは戦術に優れた沖田艦長の采配もあるが、なんといってもチート技術者、真田技師長であろう。

そもそもイスカンダルから送られたのはあくまで超光速航行を可能にする波動エンジンの設計図であって戦う力は与えられていない。ヤマト以前の地球の戦艦はガミラスの駆逐艦に有効なダメージを与えることすら難しい状況だったのだ。ここにもたらされた波動エンジン。これを地球の技術者（おそらくここでの中心も真田さんだったろう）は強烈な武装に応用する。主砲のショックカノンがそもそもそれまでと違い、ほとんどの敵を一撃で屠る異様な威力を誇っているのだが、あれも波動エンジンの潤沢なエネルギーを使用できたことによるものではないかと思う。そして何と言っても波動砲である。波動エンジンはおそらくあの世界の恒星間宇宙船では一般的に使われているものであると思うのだが、あのような大量破壊兵器に応用した例は旧作では最終回のデスラー砲以外になかった。2199ではヤマトが使った時点で、ガミラスでも研究中の兵器であった事が明かされるが。また、2199ではヤマトの波動砲を発明したのが真田さんであることもはっきり言われている。さらに、2199では波動防壁という反則級のバリアを実用化している点も見逃せない。ガミラスもガトランティスもあのような防壁を展開している場面がないことから、あれを作ったのはほんとに真田さんだけなのだろう。まあ、あれは旧作最終回で使われ、あまりの反則技に以後存在がなかったことになってる空間磁力メッキの2199版なのだろうなあと思うけど。

真田さんの凄さは観察と応用。与えられた物を見た途端にその応用を考える力だと思う。波動エンジンの理論から、イスカンダルが過去の反省からどこにも技術供与しなかった波動砲を独力で思いついて実装する。ついでに波動防壁も作る。捕獲したガミロイドから対ガミロイド戦を想定したウィルスを作り上げる。ほんとに何かを見たら「あれもできる」「これもできる」「これに対抗するには」と考え、実装してしまえる天才といえよう。こういう人はどうも他国には少なそうだ。それでもガミラスは有能な技術者をそれなりに抱えてるっぽいし、大型の掘削機械をドリルミサイルにするなどの応用力もあるのだが、どうも2199のガトランティスはダメっぽい。

2199でガミラスが常にガトランティスを「蛮族」と呼称しているのに違和感があった。旧作ではガトランティスはアンドロメダからやってくる先進的な大国である。モデルはアメリカじゃないかと言われているくらいの国だったのだ。（ガミラス＝ドイツ、ボラー＝ソ連というのは共通認識だが、ガトランティス＝アメリカは有力ではあるが異論もある説だ）

ところが、「星巡る方舟」で描かれたガトランティスは容姿や肩書（大都督、丞相）から古代中国やモンゴル帝国風の描かれ方をしていた。ガミラスを圧倒する火炎直撃砲を備えているが、これが攫ったガミラス人技術者を「科学奴隷」として開発させた瞬間物質移送器の派生物なのだ。ここから2199世界のガトランティスは科学技術に関して地力は弱く、他から奪ってばかりいるということが伺える。ヤマトと戦うときに「使えるものは科学奴隷として確保、他は全員殺せ」などと言ってるし、なるほど蛮族だわ。

ところで2199におけるイスカンダルは、かつて波動砲を使用して大マゼラン星雲を支配した事を悔いている設定なのだが、これはヤマトIIIにおけるシャルバート星の設定から来てるのだろうなあ。シャルバートはかつて高度に発達した武力で銀河を支配したが、それを反省して一切の武力を封印して隠遁、襲われても武力で対抗せず、結果滅んでもかまわないという覚悟を決めた設定になっている。今の時代に放映されたら、9条教とか言われて馬鹿にされるんではないだろうか。まあ当時もウケなくて話数半分に短縮されたんだけどね、ヤマトIII。

PETボトル普及以前のだるまボトル

現在のコンビニの冷蔵ケースにはPETボトル飲料が大量に陳列されているが、実は500ml以下のPETボトル飲料は長い間業界の自主規制で作られなかった。

食品衛生法の改正で清涼飲料の容器にPETボトルが使用可能になったのは1982年である。ところが当初PETボトルは1l、1.5lといった大瓶の用途でのみ使用され、小瓶のものは製造されることがなかった。1980年代のコンビニに陳列された飲料の主流は300mlスクリューキャップ式の通称「だるまボトル」と呼ばれるガラス瓶だった。

1970年代までの主流だった王冠付きの200ml前後の飲料便は、リターナブルと言って、飲み終わった瓶を販売店に持ち込めば10円で引き取ってもらえたのだが、1980年代のだるまボトルは確かリターナブルではなかったと思う。当時250mlの缶飲料も、300mlのだるまボトルも100円だったので、だるまボトルは店頭でよく売られていた。自販機は落下の衝撃もあるので缶が主流だった。

だるまボトルのラベルは当初ただのプラシートだったと思うが、後に薄い発泡スチロールシートのような素材になり、断熱性がよくなったと記憶している。

さて、なぜ小型PETボトルがなかったかというと、プラゴミが盛大に増えることを危惧した業界や自治体の思惑があったらしい。しかしいち早く普及した海外のPETボトル飲料が輸入されるようになると、国内で作って売れないのは不合理に感じるようになる。最終的に1996年に業界の自主規制は撤廃され、小型PETボトルボトル飲料が一気に普及することになる。

余談だが、缶飲料のプルトップが分離式からステイオン式に切り替わったのも1980年代末から1990年代初頭にかけて、これも当初海外で普及し、輸入物で見かけるようになっていたが「外側に向いている部分を中に押し込んで飲料に浸すのは不衛生で日本では普及しない」と言われてなかなか切り替わらなかった。分離式のプルトップをみんなその場で捨てていたため、路上とか砂浜とかにアルミのゴミが散らばり問題になった。海水浴場などでは裸足で歩くため、プルトップを踏んで怪我をする人も多かった。その対策として作られたのが「プルトップを集めて車いすを寄付しよう」運動である。この運動は、缶飲料がステイオン式になった後もなんとなく続き、小学校などで延々行われ続けた。そのため分離式でないプルタブを無理やり引きちぎって集めるという本末転倒な事になってしまっていた。

1986年のCMから。真ん中がだるまボトル。右の1.5l瓶はPETボトルである。