８５００の思い出

私は１９６４年４月に日立製作所に入社し、コンピュータ事業部に配属された。どういうわけか昭和３９年に３９人が私と一緒にコンピュータ事業部に配属され、これから力を合わせて一緒にやろうということで、Σ３９という会を作ってしょっちゅう酒を飲んでは騒いでいた。私はコンピュータ事業部配属後すぐ神奈川工場に実習に派遣され、林健治君（現：アスキー）、角行之君と共に、当時の開発課高橋（茂）課長（現：東京工科大学学長）のところの浦城（恒雄）さん（現：日立テレコムテクノロジー取締役）に預けられた。

この６４年４月というのは、コンピュータの歴史に残る出来事があった月であった。それはＩＢＭによるシステム／３６０の発表であった。やがてこのシステム／３６０のマニュアル "Principles of Operation" の第１版が手に入った。われわれ３人の最初の仕事は、もっぱら浦城さんにその講義を聞くことであった。聞いているうちによく分らないのでだんだん眠くなる。大人物の浦城さんは１人や２人眠っても無視して話を続ける。３人とも眠ってしまうと大きい手で机をバンバン叩きだし、われわれはハッと目を覚ます、という具合であった。

命令語の仕様を一通り理解すると、浦城さんの考えた仮想コンピュータのマイクロ命令で３６０の命令のマイクロプログラムを書かされた。これが後で８５００を設計する時に大いに役立った。

この時はとにかくＩＢＭのマニュアルの記述の、数学の本のような論理的完璧さに毎日圧倒され続けた。だいたいは分かっても、細かいところが分からない、細かいところまでやっと分かっても、なぜこういう仕様にしたのかが分からない、の連続であった。そのうち "IBM Systems Journal" に Iverson による３６０アーキテクチャ全仕様の Iverson言語による記述が掲載された。これはまさに暗号解読であったが、これで始めて分かったことも多かった。

いずれにせよ、「このようなコンピュータを実際に開発する日が近い将来に来るとはとても考えられない」、というのが当時の偽らざる実感であった。

これが変わったのは私がＲＣＡに行ってからである。

（２）ＲＣＡへ出張

１９６３～６４年頃ＲＣＡは２８６、２８６１という２機種のコンピュータを開発中であった。これは６ビット単位のいわゆるキャラクタマシンであった。６４年４月にいわゆるバイトマシンの３６０が発表されると、ＲＣＡ社内でこの２８６、２８６１の開発をどうするか激論が戦わされた。結局この開発計画は方針変更となり、３６０と同じ８ビットコードが採用され、ユーザプログラム用の命令語の仕様も３６０と合わせることになった。

ただ割り込み処理と入出力制御の仕様にはＲＣＡ独自のものが採用された。これはＲＣＡの技術者が高速のスクラッチパッドメモリを使った割り込みの４ステータス制御を他社にないＲＣＡの特徴と思っていたことと、３６０の入出力インターフェイスの仕様がその当時入手できなかった為と思う。こうして２８６、２８６１は後日、それぞれＳＰＥＣＴＲＡの７０／４５，７０／５５として世に出ることになった。

この頃日立社内でもちょうど開発が終わったキャラクタマシンの２０１０の扱いについて激しい議論があった。これも結局、「世界の大勢はバイトマシン」との判断から製品化は中止となり、日立もＲＣＡのＳＰＥＣＴＲＡシリーズのアーキテクチャを採用することになった。こうして日立の８０００シリーズが生まれることになった。

先ずＲＣＡ７０／１５を８２００として、また７０／４５を８４００として出すことになった。

ファミリーマシンと言っても７０／１５はテクノロジーも古く、ＩＣでなくトランジスタを使ったもので、またアーキテクチャも７０／４５、７０／５５とは若干異なり、ＩＢＭの３６０シリーズのように完全に互換性のあるものではなかった。そして日立は７０／１５の上位機の７０／２５の製品化はしなかった。

両社にとって、完全に互換性があり、新技術を使った、７０／４５の下位機種の開発が急務であった。そこで両社はこれを共同で開発することになった。後のＲＣＡの７０／３５、日立の８３００である。

６５年に入ると、高橋課長も浦城主任もこの共同開発プロジェクトでフロリダのＲＣＡの工場へ行ってしまい、われわれは北辰電気から移られたばかりの豊沢（弘毅）主任の下で、いささか手持ちぶさたに、時間を持て余して過ごしていた。

ところがこの６５年の４月末に私は突然ＲＣＡへの出張を命じられ、米国のチェリーヒル（ニュージャージー州）とパームビーチガーデン（フロリダ州）に合計４週間滞在した。

このときのドタバタ騒ぎは別冊子「はじめてのアメリカ」に記した。

この出張の最大の収穫は、アメリカの一流のコンピュータメーカーのエンジニアといっても個人的にはたいしたことはない、という率直な感想だった。これならＩＢＭに勝つことはできなくても、ＲＣＡに勝つことはできるのではないかという気がした。この自信はその後８５００を開発するときに私の大きい支えになった。

２．９ヶ月で骨格を固める

（１）４人でスタート

アメリカから帰国するとすぐ８５００の開発が始まった。

８４００はＲＣＡの７０／４５の自製化が、８３００はＲＣＡとの共同開発が既に進んでいた。問題は８５００を７０／５５の自製化でいくか、日立の自力開発でいくかであった。結局、７０／５５はマイクロプログラム方式でない為技術的に古く、また性能も不充分ということで、独自に８５００を開発することになった。しかし問題は開発要員であった。神奈川工場の設計の主力は当時、４０１０、５０２０Ｅ、８４００、８３００にかかりっきりで、他に人がいない。結局豊沢主任の下で、入社２年目の私と、入社したての馬場徳夫君（現：日立電子サービス）、萩原亘喬君（現：日立東北ソフトウェア）の４人で長い戦いのスタートを切ることになった。

６５年６月から約９ヶ月で方式設計を完了した。翌年春の私の研修員発表はこの「８５００の方式設計」だった。質疑応答になると、一番前に座って聞いていた三井忠夫さん（元：日立ＳＥＫ社長）に、

「話は分かったが、ところで君がやったのはどの部分かね」

と聞かれた。分担するほど人がいなかったわけで、私は咄嗟に、

「開発はグループでやったのでどの部分と明確には言えません」

とお答えした。

ない袖は振れなかったのだろうが、いかに当時とはいえ、よくもこのようなメンバーに方式設計を全部任せたものと思う。後で８５００の完成の飲み会の時、開発当時課長だった谷（恭彦）さん（現：日立電子サービス社長）に、

「当時は会社が本気で、真面目に８５００をやろうと思っているのか疑問に思ってましたよ」

と話したことを思い出す。

どういうわけかその後も私の関係するプロジェクトはいつも同じ様なめぐり合わせとなった。次の８３５０の時は、１９７０年前後の３大プロジェクト（８７００、８８００、ＤＩＰＳ）の真っ最中で、仕方なしに大半は電子サービスの人で開発を進めた。いまでも同窓会をやると電子サービスの人の方がはるかに多い。その次のＭ－１５０の時は、開発要員は全部Ｍ－１６０Ⅱ以上の開発を担当していた開発部に集められた後で、残りの部隊で開発せざるをえない状況であった。いつも日陰のプロジェクトとひがんでいたが、一緒に仕事をしてもらった人には大変な苦労をかけた。

（２）「創造力」より「想像力」

８５００を開発するに当たり、まず参考にしたのが、ＩＢＭの文献と、手近にあった８４００、８３００の設計資料であった。しかし当然のことながら、ＩＢＭの機械の詳細は分からず、また８４００、８３００では性能が全く不足であった。そこでＲＣＡから何とか７０／５５の図面を入手しようとＲＣＡに手紙を書いた。すると論理図とステータスフロー（マイクロプログラムマシンのフローチャートに相当するもの）がどさっと送られてきた。説明書の類は何もない。その上図面のリストと突き合わせると随分抜けている。早速その旨連絡して、「残りも送れ」と催促すると「まだできてないからだめだ」という返事。こういうことを何度も繰り返した。

しかたがないから、届いた分だけを調べるのだが、説明書はない、誤りはある、不足図面はある、でまさに暗合解読であった。それでも８５００の演算回路はこうして解読した７０／５５の演算回路を下敷きにしたものとなったし、２進加算回路を使って最優先割り込みを見つける方法はこのステータスフローの解読から得られたものであった。

ユーザー用の命令語の仕様は３６０と同じだったから、分からないことがあると、あやしげなＲＣＡのマニュアルを見るより、ＩＢＭの "Principles of Operation" を調べるのを常とした。

問題は割り込み処理と、入出力制御であった。

これらはＩＢＭと異なる為、ＲＣＡの資料に頼らざるをえない。ところがこれが記述が不完全で、細かい所は分からない点が多い。結局最後には、磁気テープ、カードリーダ等の入出力装置の論理図と、ＯＳのソースリストを取り寄せ、どうしても分からないことがあるとそれらを見て調べた。一番分からなかったのは入出力コマンドのフラッグビットの使い方だった。これが分かったのは通信制御装置の「コオーディネーションメッセージ」という回線情報の処理やディスクのキーサーチのやり方を調べてからだった。

「創造」というより、ＩＢＭやＲＣＡの機械がどうなっているかを限られた情報から「想像」する力が、開発の初期には決め手だった。

（３）ＥＯは何ビット？

先ず最初の仕事は、レジスタ、演算回路等の構成を決める（つまりブロック図を書く）ことと、ＥＯ（ ”Elementary Operation”の略でＲＣＡ用語でマイクロ命令のこと）のフォーマットを決めることであった。

ＥＯのビット数は８４００は５４ビット、８３００はその半分の２７ビットであった。２７ビットというのは当時としては極めて少ないビット数で、これは設計のチーフの Dan Neilson がコストダウン上強く主張し、周囲の反対を押し切って決めたと聞いていた。ＩＢＭは概してビット数が多く、大型機では７０～９０ビットになっていたと思う。

私の最初の案も、確か６０ビット前後はあったと思うが、豊沢さんがコスト上の理由からもっと短くすることを強く主張され、デコーダの複雑化を犠牲にして、フォーマットの圧縮を図り、結局方式設計段階では３６ビットに決めた。その後入出力サービスの割り込み禁止の "Ｉ" ビットとパリティ２ビットが追加され、最終的に３９ビットになった。後でＲＯＭの設計者から「何でこんな変なビット数にしたんだ」とさんざん文句を言われた。

（４）ディレーラインの大軍

タイミング系には、豊沢さんの前の会社での経験から、ディレーライン発振器と、ディレーラインを使ったタイミングパルスの発生・分配方式が採用された。

後で論理規模が膨らむにつれ、ディレーラインのパッケージ枚数が増え、最終的には１００枚近くになったと思う。このディレーラインの大軍が８５００の特徴の一つであった。この方式はきめ細かくタイミングの調整ができ、融通性に富んでいたが、反面調整作業が大変で、試作機の調整の時に大変苦労した。ディレーの値をシンクロで計っては、ディレーラインパッケージのピンをジャンパー線で接続した。

またマシンサイクルは加算回路のゲート段数の見積もりから、開発のかなり早い時期に２１０ｎｓと決められた。その後ＩＣのディレーの見直し等の紆余曲折があったが、結局これが最終的なマシンサイクルの値となった。

ＥＯのビット数の続いてこれも変な値であった。

３．製品化へ

（１）体制本格化

こうして方式検討を終えた後、私は一時８３００の実装設計の応援に駆り出されたりしていた。６６年５月に、８５００をいよいよ本格的に製品化することになり、やっと体制が強化され、波多野（泰吉）課長（現：トキコ）、関（弘）主任（現：国際電気）、井上（武洋）さん（現：トキコ）、の所へ移り、新入社員の野上（康一）君が加わった。その後順次、電子サービスの高木（雄一郎）さんほか、神野、中根、新谷、百瀬、久鍋、渡辺、武田、鈴木、松山、他の皆さんが加わり、やっと設計陣容らしくなった。

私はそれまで東京の自宅から通勤していたが、関さんの所へ移った途端に３日連続して遅刻をしたら、さっさと独身寮（暁光寮）へ入れられてしまった。

（２）裏論理を駆使

関さんの所へ移って、まず最初に問題にされたのが、「ＩＣのディレーの評価が甘く、このままでは動かないのではないか？」ということだった。実際のＩＣのディレーの分布を徹底的に測定する一方、ゲートの並列化によって、特にＥＣＬ回路の Wired-OR を使った「裏論理」（普通の「表論理」の逆極性の論理）を駆使してゲート段数の削減を図った。問題になりそうな加算回路は、入口から出口まで全て表と裏の２通りの論理で組み、制御回路についてもかなり裏論理を使った。その為論理が直感的には全く理解できないものとなり、ブール式を書いてはチェックした。

後日試作機に火を入れて動かしてみると、この対策の結果、論理ゲートの所は概ね充分余裕があり、タイミングのネックはほとんど引っ張りまわした制御信号の配線ディレーにあった。

（３）三和銀行が採用を決定

そうこうしているうちに三和銀行が次期オンラインシステムに８５００を使うことに決まった。為替のオンラインは既にオンライン専用のコンピュータを使って始まっていたが、預金のオンラインはこれから始まるという時代だった。

それまでの８５００は、エラー検出回路としては、メモリのパリティチェック回路しか持っていなかった。今でこそ信じられないような話だが、８４００他、だいたいこんなものであった。

「銀行の金を扱うのだからこれではだめだ」と三和銀行のオンラインシステム担当の不破（康博）さんに言われ、ＩＢＭの文献等調べて、考えられる限りのチェック回路を追加した。メインメモリのほか、スクラッチパッドメモリ、ＲＯＭのデータとアドレスにもパリティビットを追加した。またおもなレジスタ、バスにもパリティを設け、演算回路にもパリティ予測回路を追加した。ＥＯのデコーダも同一回路が複数あるときは、一致をチェックするようにしたが、これが有効に働いたという話はその後聞いたことがなかった。

この対策により障害の検出機能はまずまずであったが、後処理、つまり障害検出時のタイミングの停止とか、障害情報の記録とかが不充分で、後で事故対策の時に大変苦労した。いずれにせよこの分野は文献も経験も少なく、全く手探りの状況だった。

（４） Word Boundary 騒動

論理の詳細がほぼ固まった頃、何がきっかけだったか忘れてしまったが、方式設計上のとんでもないミスが見つかった。

８５００のメモリは３２ビットに１ビットのパリティしか持っていず、ワード単位の読み書きしかできなかった為、１ワード内の１～３バイトを書き換えるときは、まず１ワードを読んで必要な部分を書き換えた後、その１ワードをメモリに書き込んでいた。その為この間に入出力処理などで同じワードの残りのバイトの書き換えがあると、それが無効になってしまうという不良であった。この対策は大変更となることが分かり、日程的にも相当な影響が予想され、われわれは頭を抱えた。関さんと私が、当時の谷課長の所に報告にいくと、余計なことは何一つ言わない谷さんのこの時の一言は、

「不良は直さにゃしゃーない」

であった。

その後われわれは総動員で知恵を出し合い、ハード、ＥＯ両面から対策を進め、何とか事なきを得た。

（５）ベラムとの戦い

論理設計が終わると、実装設計に入った。実装設計で一番大変だったのは、プラッタ上の配線だった。当時は自動配線のＤＡ等なかったから、全部人手で線を引っ張った。ベラムと呼ばれていたシート上の接続する２点にピンを立てては、定規で線を引いた。混んでくるとなかなか配線が入らず、何週間もかかる大変な仕事だった。

ある時危機一髪の出来事があった。

配線を終わりかけていたＭ君の机の方でボッと火の手が上がった。何週間もかけて書き上げたベラムがこれでパーになったかと皆真っ青になった。幸いにしてベラムが少し焦げたぐらいで何とか助かった。タバコの火を大きなマッチ箱の上に落とした為で、早速大きなマッチ箱は使用禁止になった。

（６）徹夜のＤＡオペレーション

プラッタの配置、配線は人手に頼らざるを得なかったが、ピンリスト、ネットリストと呼ばれる、信号名とピンとの対応をコネクタ毎、信号名毎にリストアップしたものは当時の初歩的なＤＡでも打ち出すことができた。

ＤＡには４０１０が使われた。今と違いクローズドショップのＤＡセンタ等なかったから、計算機のオペレーションは全部自分達でやらねばならなかった。長時間計算機をぶっ続けで使う為、だいたい夜のことが多かった。寒い時だったので６６年から６７年にかけての冬だったのだと思う。寒いのでオーバーを着てやっていた。長いソートが始まると、ＭＴの扉を開けて暖をとりながら、ＭＴの廻る音を子守り歌にして眠っていた。慣れてくるとＭＴの音だけでソートがどこまで進んだかがだいたい分かった。

コンソールのオペレーションは４０１０の設計の時から慣れていた井上さんの専門だった。われわれはＭＴを交換したり、カードをしごいたりしていた。

４．最後は体力が勝負

こうして６７年の２月にすべての設計を完了し、試作機の製作に必要な図面を製造部門に出し終わった。試作機の組立てが完了し、火が入ったのは６７年８月のことだった。それから長い長い２交替勤務の調整が始まり、神奈川工場のＤＡセンタに１号機が据付けられたのは、６８年５月のことだった。

２交替勤務の夜勤のシフトは夜の８時頃から始まった。夜中の１２時過ぎにはいつも決まって戸塚の「鉢の木」に食事に行った。調整メンバーの一人の主任が酔っ払って女性同伴で来ていたのと鉢合わせしたこともあった。

「うちの主任もまったくいい気なもんだ」

等と話し合いながら、夜中の食事をした。

夜勤も明け方になると、意識が朦朧として、注意力が散漫になってくる。

ある明け方電源ケーブルの接続替えをして電源を入れたら、ドカンと言う音がして煙が立ちこめた。全世界にこの１台しかない８５００の試作機をオシャカにしたかと真っ青になった。調べたら幸いにしてパッケージ何枚かと終端抵抗が壊れただけと分かり、ほっと胸を撫でおろしたこともあった。

とにかく時間に追われ必死に仕事をしていた。ある時休みの前日の夜中の調整中に電源が壊れた。われわれには手も足も出ず、電源が入らなければ仕事にならないので、しかたなく朝を待った。夜が明けて関係者に電話して聞くと、担当者がある寮にいることが分かった。「さあ遊びに行ったりしないうちに捕まえなければ」と、日曜の朝の戸塚の街を車で飛ばした。寮を探し当てるとまさにその当人は着替えを済ませて遊びに出かける所であった。それを無理矢理車に乗せて工場に連れ帰り、電源を直してもらった。さぞ怨まれたことと思うが、こういうこともせざるをえないような心境だった。

ＲＯＭとスクラッチパッドメモリ（ＳＰＭ）の動作が安定しないのにも随分苦労した。

ＲＯＭは高橋（茂）さんが電気試験所の頃考案された、鉄心のないもので、高瀬（拓士）さん（現：日本コンピュータ開発社長）、村山（典男）さん（現：日立プロセスコンピュータエンジニアリング）、他が取り組んでいた。ワードシートのスタックからセンスアンプへ行くケーブルの状態で動作が変わり、ちょっといじっただけで動かなくなったりした。

ＳＰＭはワイヤメモリで、万代（博亮）さん、滝沢（克彦）さん（現：日立マイコンシステム）、他によるものであった。同じパッケージ同士でも入れ換えると動かなくなってしまい、どのパッケージをどこに挿したらいいか、パッケージに全部ラベルを貼ってあった。

結局このＲＯＭとＳＰＭは改良型の８５００Ｓでチャネルと共に新設計のものに切り替えた。

われわれが少々疲れてきたのを見て、井上さんがスキーに行こうと言い出した。皆で夜行で野沢温泉に行き、翌朝さあこれから滑りに行こうと朝飯を食べていると、関さんから井上さんに電話が入った。「急用ができたのに関係者が一人もいないのはどうしたことだ」ということで井上さんは一人で先に帰ることになった。関さんにあらかじめ断ってなかった度胸にもびっくりしたが、井上さんのおかげでわれわれは久しぶりに頭と体のいいリフレッシュができた。

この調整の時は「最後は体力が勝負」とつくづく思ったものだ。

５．チャネルを再設計

この長い調整で何とか目処が立つやいなや、われわれはチャネルの改造設計にかからねばならなかった。

正直なところ８５００の開発にとりかかった時、われわれには、どんなシステム構成でどんな業務に使われるのか、まったくイメージがないに等しかった。まだ大型ディスクなど存在せず、座席予約等のオンライン業務には専用コンピュータが使われていた時代だった。汎用コンピュータの性能と信頼性が急激に進歩し、いわゆる銀行の第１次オンラインの気運が急速に高まったのは８５００の開発の真っ最中であった。時代の先が読めなかった不明を恥ずかしく思うが、当時の世の中のレベルはまだそんなものだった。

前にも触れたように、三和銀行での採用が決まった時、障害検出機能の強化についてはすぐ手を打った。しかしチャネルスループットの改善は、チャネルの全面的再設計となる為後回しにし、取り合えず原設計のままで進めることにした。その為当初の８５００の調整を終わると直ちにチャネルの再設計にかからねばならない状況にあった。

チャネルを新規に設計すると同時に、その後のハードウェア技術の進歩を取り入れ、動作の安定性の上で問題のあったＲＯＭとＳＰＭを新しいものに切り替えることになった。

ＲＯＭは鉄心のないものからＵＩコアを使ったものに換え、文字通り筋金入りの丈夫で安心できるものになった。これは高橋（茂）さんに引っ張られて電気試験所から日立に移られた松崎（磯一）さんが中心になって開発されたものだった。その松崎さんも残念ながら９３年４月に亡くなられた。「もし松崎さんがいなかったら、その後大量に生産された８５００Ｓの信頼性は一体どうなっていたろう」と思っていた私は、訃報に接して鎌倉のお宅でのお通夜に出かけ、御冥福をお祈りした。

またＳＰＭには当時出はじめたばかりの１６ビットのＩＣメモリが採用された。

こうして８５００Ｓ（Ｓはセレクタチャネルの高速版ということから名付けた）は６８年４月から１２月にかかけて約９ヶ月で設計され、６９年４月に試作機の火が入り、６月まで約３ヶ月かかって調整を終え、７月始めにＤＡセンタに据付けられた。

この間の６８年８月に当初の８５００の顧客第１号機が日立造船に納められた。

６．事故対策に東奔西走

こうして８５００の本格的生産、出荷が始まったが、それと同時に今度は社外事故との格闘が始まった。

入出力動作がらみでインターミッテントな障害が収まらないということで、大阪の三和銀行に、何日間にもわたって、夜になると裏口から入り込んで、床下のケーブルの状態を調べた。行き先不明のケーブルがあるのでフリーアクセスの床をめくってどんどんたどって行くと、隣室のバロースの機械につながっていたりしたこともあった。

新日鐵の大分製鐵所でも原因不明の事故が続いて、飛行機で飛んで行ったが、結局分からずじまいだった。その後半年ぐらいたって電子サービスの新谷君がＡＬＵのプラッタから線くずを見つけやっと一件落着した。

事故対策の時は、夜仕事をして、昼はうるさい町中の旅館で寝ていることが多く、ろくな思い出がないが、一度だけうまくいったことがある。

８５００の電電公社版を大阪の万博に納めた。ところが時々通信回線がらみの障害が起こるという。話を聞いているうちにだいたい原因が分かったので現地に対策を指示したが、念のために現地に来てくれという。現地に着くと予想が当たっていて、既に問題は片付いていた。それではということで出張ついでに一通り万博を見て帰った。

８５００と同じＢＰＵを使った８４５０を含めると、室蘭から熊本まで、しょっちゅう検査の人や、電子サービスの人と飛び回っていた。最後にはいつでも飛び出せるように会社のロッカーに洗面道具を一式置いていた。

これらの事故対策を通じて、肝に銘じて感じたことは、「設計者が何日間も徹夜しても分からないような事故を起こす機械を世の中に出すということは社会的罪悪だ」ということである。事故対策から疲れて帰って旅館で寝ながら、「次の機械は何とかしなければ」と考えていた。次に手懸けた８３５０ではこの反省を踏まえ、電子サービスの人と一緒になって、およそ考えられる限りの障害検出・回復機能を盛り込んだ。

おわりに

　８５００Ｓを含めると約４年にわたる長い戦いであった。大小さまざまな問題を乗り越え乗り越え、数多くの人の力に支えられて、８５００は世に出された。

８５００は三和銀行、日産自動車、新日鐵等の主力システムとして使われ、その後の日立の大型システムの基になった。

この８５００のＢＰＵはそのまま８４５０のＢＰＵとして使われ、完全に２世代の勤めを果たした。振り返ると現在までの８０００シリーズ、Ｍ／Ｌシリーズを通じ、こういうことができたのは、後にも先にもこの８５００だけである。方式的に陳腐化せず、半導体やプリント基板の原価低減をうまく活かせた幸運な機械であった。

そして私は８５００Ｓが片付くや否や、新たに８３５０との戦いに巻き込まれていった。

（完）

第１版　１９９３年１１月

第４版　１９９８年　３月