[ 開発室・電車走行キット開発史 ]

1. 前史 - 電車走行キットが誕生するまで

●JavaScriptの衝撃

日本における「鉄道側面画 2D-CG 元年」は、1996年である。
しばのぶさんによる鉄道スクリーンセーバTSVと、H.KumaさんによるTB規格がこの年に誕生している。
* TBが規格として確立したのは翌 1997年。厳密に言えば1996年は H.Kumaさんが画像を公開しはじめた年ということのようである。
* 海外に目を向けると、世界的主流の鉄道スクリーンセーバMM&MMが前年1995年の誕生となっている。また、後にアメリカ版 TBとも言うべき TrainGif規格となる画像を Dan Klitzing 氏が最初に描きはじめたのが 1997年との事。世界的に見ても、この頃に「鉄道側面画CG」という鉄道趣味の一ジャンルがスタートしたと見て間違いはない。
* 詳細は「鉄道側面画各種規格」参照。
 自分はこの頃、一時、鉄道趣味から離れていたこともあり、鉄道側面画という趣味の世界が存在することすら知らなかった。

電車走行キット前史を語るのは、翌 1997年からとなる。
この年に登場したウェブブラウザ Netscape v4は、画面上のものを動かしたり消したりできる「レイヤー機能」を実装していた。追って登場した Internet Explorer v4（以下 IE4）にも同じような機能があり、後に総称して「ダイナミックHTML」と呼ばれることになる。
* 厳密に言えば「レイヤー機能」と「ダイナミックHTML」はイコールではないが、当時の感覚ではそのような区別は存在しなかった。
 この年の末、ネット上でJavaScriptを使った自動車レースゲームを見つけて、ものすごい衝撃を受けた。
画面上のものが動かせるといっても、JavaScriptでまさかここまで出来るとは想像の外だったのだ。これにより、JavaScriptの可能性を知り、ウェブ表現の道具として以後ハマることになる。

●鉄道シーン事始

1998年、JavaScriptにも多少慣れて、初めて鉄道シーンを作った。
下のインラインフレーム内を走っている小田急7000形もどきがそれである。動きはギクシャクしているし出来の悪いプログラムだが「駅停車」はすでにある。
* 1998年の時点では Netscape v4のみに対応。その後、IE対応、Netscape6対応に改造している。出来が悪いだけでなく、つぎはぎだらけで無駄も多く、ソースは穢い。原点ではあるが、プログラム的には現在の電車走行キットとの共通点はないに等しい。

* この頃はまだ Pentium 120MHz の Windows95 マシンを使っていた。この処理速度レベルのマシンでは、電車走行キットの動作すら辛い。このマシンは、腹立たしいほど短寿命で 1999年末に壊れた。これが、もっと長持ちしていれば、電車走行キットの登場はもう少し遅れただろう。


これは自分のウェブサイトに置いた。
といっても、当時の自分のサイトは、江戸時代の文学作品「八犬伝」をテーマにしたものだけであり、鉄道と関係のあるページは全くない。八犬伝の主人公は「八犬士」と呼ばれる八人の若武者だが、そのうちの一人「犬阪毛野」の出身地が現在の小田急沿線であるから、と無理矢理こじつけて、犬阪毛野関係のページに置いたわけだ。
* 上記のページは、八犬伝サイト縮小化計画により 2012年 2月に削除。現在はサーバー上にない。
* 下記↓、八犬士関連地点がどの鉄道沿線なのか、表にしてみた。
　 八犬士 父親の出身地 誕生地の沿線 生育地の沿線 初登場地点
仁 犬江親兵衞 JR総武線 JR内房線 地下鉄東西線
義 犬川莊介 伊豆箱根鉄道 都電荒川線
禮 犬村大角 わたらせ渓谷鐵道
智 犬阪毛野 JR総武線 小田急電鉄 JR横須賀線 地下鉄日比谷線
忠 犬山道節 西武池袋線 地下鉄丸ノ内線
信 犬飼現八 JR内房線 JR東北本線
孝 犬塚信乃 都電荒川線（または地下鉄丸ノ内線）
悌 犬田小文吾 JR内房線 地下鉄東西線
* 八犬伝の舞台は江戸時代の街道に沿っているが、鉄道敷設も昔からの街道に沿っていることが多い。ゆえに、鉄道路線的視点で古典文学を見ても、さほど違和感がなかったりする。といっても東日本の南総里見八犬伝での話であり、西日本の源氏物語でも同じことが言えるかどうかは知らない。ま、どうでもいい話ではあるが。
* 左上フレーム走行見本 No.504 に「八犬士のうち誰か一人が出るだけ」という「八犬士占い」あり。走行しているのは房総の電車。
●自分専用から配布版へ

この「駅停車」のギクシャク感の改善策を思い付いたのは、かなり時が流れて、2000年後半になってから。
* 思い付くまでにやたらと時間がかかっているが、この時間は自分にとってのJavaScript修行時代。縄文時代が長い（No.1197 参照）のと同じ（？）で、黎明期というものは次のステップに進むまでに時間がかかるものである。…というのは単なる言い訳。

* Mac に転向して、JavaScript の互換性の問題（今にして思えば当時はひどいものだった）に苦しんだのも、改善版までの時間を要することになった原因のひとつ。
改善版は、縮尺も意識して画像をリアル化し、踏切や信号、ドア開閉の機能も追加した。
走らせた車輛は京王電鉄8000系。
* 1px=実車の10cm、という縮尺は、京王8000系を描くにあたって寸法計算がやりやすいから採用したもの。それが TSV60dot規格と同一縮尺だと知ったのは、かなり後のことである。
 ……だが、作ってみたものの、八犬伝サイトで公開する理由もないし意味もない。京王沿線には八犬伝の舞台はないのだ。かといって鉄道サイトを開こうにも、写真も模型もやらない自分にはネタがない。発想の転換がなければ、そのまま公開せずにボツになっていただろう。

だが、踏切や信号まで動く自信作だったし、ボツにしてしまうのは惜しい気がした。
色々考えているうちに「他人にも使えるように改造してウェブ上で公開してしまう」という発想に到った。つまり、鉄道走行JavaScriptそのものをコンテンツとして鉄道サイトを開く、ということだ。
このプログラムが自動走行版「A01」となる。
さらに手動版を作り、マニュアルを作り、2001年 4月 29日に公開にこぎつけた。これが基本セットver.1である。
* 以上のような経緯ゆえに、左上フレーム走行見本 No.1 は京王線なのだ。但し、当初のサイトデザインは、走行フレームと本分フレームの上下二段で、走行シーンは横幅があった。フレーム拡張をして、当時の走行見本をほぼ再現したのが No.1361 である。
2. 電車走行キットの誕生 - 基本セットver.1

●制約だらけの「A01」ver.1

自分用だったものを、配布用 A01に改造する上で、最大のネックはドア開閉だった。
画像を入れ替えるプログラムそのものは、JavaScriptの初歩の初歩だから難しいわけではない。ただそのためには画像指定の中に画像IDを入れておく必要がある。「そんなもん JavaScriptで書き出せばいいじゃないか」と思うかもしれないが「CSS指定のある個所にJavaScriptで書き出すとエラーになる」という Netscape4のバグが立ちはだかったのだ。
* ver.2以降では「JavaScriptで書き出す」というオーソドックスな方法を使っている。その後、Netscape4のバグ回避策が見つかったからだ。しかし、この回避策は今度は MacIEのバグにひっかかり、結局 Netscape4とそれ以外のブラウザでは別の方法を使うという二重構造になってしまった。
 「JavaScriptで書き出さない」ということは「使う人が自分で書込む」ということを意味する。
これをどうやって設定してもらうか？
結局よい方法は見つからず、HTMLを少しは知っていないと設定できない上に、あれこれと制約のある代物になってしまった。それでも「あなたのページに鉄道を走らせよう」というキャッチフレーズのとおり、ネット上にページを持つ人を対象として考えていたので大丈夫と判断した。ウェブページを持つぐらいの人ならHTMLぐらい知っているだろう、ということだ。
* 実際はウェブページを持っているからといってHTMLを知っているとは限らず、しかもウェブページを持っていない人にも電車走行キットの需要はあった。
 後に考えれば、制約がありすぎて鉄道シーンの再現上きわめて使いにくかった。
A01 ver.1の構造が今のバージョンに一切痕跡を留めていないのは、この辺の事情にもよる。こんな使いにくいものでも使って下さった方はいた。本当にありがたいことである。

●遅すぎる「M01」

手動運転版「M01」の走行プログラムは、自動走行版「A01」からの改造である。
電車を走らせるかわりに、背景を走らせるだけで基本は同じ。駅停車計算をしなくてよいので、むしろ走行系プログラムは簡単……のはずだった。
しかし出来上がったものは「遅すぎる！」という代物だった。
巨大な背景画像を動かす描画処理がブラウザにとって大きな負担になっていたわけだ。

たとえば時速100km/hで走らせる場合、1/10秒毎に28ピクセルずつ電車は移動する。
しかし現実は描画処理にかかった時間分だけ遅れるため、たとえば自分のMacの処理速度程度では事実上、約1/5秒毎でしか実行されない。つまり見た目、50km/hぐらいにしかならないのだ。
* 処理速度の速いマシンが欲しいと心底思った瞬間でもある。
 この場合、一度に移動する距離を倍の56ピクセルにすれば、見た目 100km/hになる。
かくして手動版には「遅延補正」機能を搭載することにした。プログラム実行の一定回数毎に計時して遅延時間を算出し、それを元に遅れた分だけ移動距離を増やすのだ。これが「速度感優先」モードであり、この機能を解除したのが「精度優先」モード。さらに1/20秒毎動作にして細密な動きにしたのが「倍精度」モードとなる。
* ちなみに自動走行版にはこの遅延補正は使えない。駅停車位置が狂うからだ。……と言いつつ、2007年に自動系「SA20SL」に遅延補正機能を搭載した。停止位置精度がさほど悪くないのは、A01系ではなく、A07系の停止プログラムゆえだ。詳細は後述「番外1- 駅停車システムの変遷」参照。
 結局のところ、自動走行版より簡単というわけにはいかなかった。

── 但し 2000年代初頭の話であり、2010年代のパソコンの速度では問題にもならない。むしろ、低速パソコン用に組込んだ遅延補正処理が、ギクシャクの原因となる場合もあり、かえって邪魔者と化してしまった。
●最大難関の「マニュアル」

電車走行キットを動かしている「DynamicHTML」は、HTML、CSS、JavaScriptという３つの機能から成り立っている。ユーザーがこの３つを熟知している人だけであるならば、簡単な説明だけで使ってもらえる。だが、そうではない。
当初の想定では、HTMLぐらいは知っている人を対象としていたので、これについては除外。CSS部分は触らなくても設定可能なので、これも除外。
* HTMLをあまり知らない人をも対象に含めている現在のバージョンでも、HTML関係の記述は除外したまま。現在のバージョンは、HTML部分をほとんど触る必要がないからだ。
 問題は、JavaScriptである。
簡易言語とはいえ一応プログラムであり、この内部パラメータをユーザーが直接手を加えなければならない。
だからといって「JavaScriptとは〜」といったお固い解説から入ったとしても誰も読むまい。自分だって読みたくないようなものは、他人だって読みたくはないに決まっている。だが、これを読みやすい取扱説明書にまとめるのは至難の技だ。

結局、作業手順に従って解説することにした。
画像をどう組み合わせて出来ているかといった構造を理解してもらい、絵の仕様を解説し、最後に最大難関の設定個所を実例で説明する。考え抜いた末にそんな流れで説明しているが、今もってこれ以上の方法は思い付かない。
* 2003年夏にマニュアルを大幅改訂しているが、基本的な構造は変わっていない。
A01やM01といったプログラム本体より数段手間もかかったし、頭も使った。はっきり言って、こんなものをゼロから作るなんて、二度と御免である。
* マニュアルを読むか否かは使う人の自由だが、ここまで苦労したものを読まずに質問メールされれば、そりゃ面白くないってもんだ。というか、いちいちサポートできないからこそ、詳細なマニュアルを作ったわけだし。
3. 拡張と模索 - A02の誕生から基本セットver.2へ

●核となる「A02」

A01 ver.1で走らせられたのは、たったの２編成。
しかも、２つの編成の車輛数（画像数）が同じでなければならない、という制約付。
これでは再現可能な鉄道シーンは限られ、当初から「両数の制約なし」と「多編成化」を希望する声は寄せられたし、自分でも必要性を感じていた。
* 当サイトの走行見本も、当時は京王8000系と6000系もどきだけ。当時登場したばかりの9000系も走らせるためには、どうしてもプログラムをなんとかする必要があったわけだ。
JavaScriptには、オブジェクト（配置物）の中身を入れ替える innerHTMLという命令がある（Netscape4 にはないが、Netscape4 は別の方法で可能）。これを使って走行車輛オブジェクトの中身を入れ替えることで両数制約の解除も多編成化もできることは分かっていた。
ネックは、Macintosh版 Internet Explorer。
MacIE4は innerHTMLに対応していないし、MacIE5もある条件下で innerHTMLを使うとオブジェクトがとんでもない位置に表示されてしまうバグがある。
これをどう回避するかで悩んだのだが、結局 MacIE4を見捨てる形で多編成版「A02」を作った。
ついでに好きな機関車牽引列車を走らせられる機能も追加した。
* Macの雑誌には「Mac版IEは Windows版にはない機能を搭載している」などと自慢げに書いてあった。見栄えのする部分では確かにそんなこともあるが、DynamicHTML的視点に限って言えば、Windows版より劣る。MacIE4は問題外としても、MacIE5でも苦労させられる。同じ名前のブラウザなんだから同じ仕様にしてくれ、と言いたいが、MacIEは今後のバージョンアップはしないそうなので願いはかなわないままだ。……それどころか、2006年 1月末を以て、MacIEは配布終了。入手すら出来なくなってしまった。
A02は、多編成化したことで「すべての編成をパラメータで設定する」必要が生じた。このため、A01とは設定方法が大きく異なるものになってしまい、専用のマニュアル添付までした。
しかしながら、A02の設定の方が合理的であり、むしろこちらを主流とすべきだと思えた。
それを実行したのが、基本セットver.2。
A01 ver.2の中身は A02ベースに変わり、A01 ver.1との共通点は何もない。
* A01も多編成化したことで、A02は「多編成版」ではなく「機関車版」という位置付けに変わる事になった。
●高すぎたハードル

この頃の基本セットには「無地車輛」しか添付していなかった。
実在形式の塗装済み完成車輛は、A02に添付した「EF64もどき」が唯一であった。しかも「もどき」であり正確な絵ではない。
なぜか？
その答は「電車走行キット」という名前にある。
つまり「完成品」ではなく「組立キット」を強く意識していたのである。それも、模型的に言えば「線路もパワーパックも動力メカも用意した。車体は各自作ってね」という感覚だった。つまり車体に関しては、キットという以前の「スクラッチビルド（完全自作）してね」という方針だったのだ。
A02のEF64もどきは特例で、機関車設定見本として "やむをえず" 添付したもの。あくまで設定見本にすぎないと考えていたため、正確な絵である必要も感じていなかった。だから「もどき」画像だった。
* 今の自分から見れば「もどきにしても、これはちょっと…」という絵である。まだパソコン内に保存している人がいたら、即座に削除してほしいぐらいだ。……と言いつつ、左上フレーム走行見本 No.1202 に、件の EF64もどきが走る「A02 ver.1 初期設定画面」の再現あり。更に No.1201 は、無地車輌しか添付していなかった「A01 ver.1 初期設定画面」の再現。2001年当時の未熟な画像をさらしてみた。
そういうコンセプトであったため「完成品としての電車走行キット用車輛画像を配布する」という考えは全くなく、自分自身の描画欲は、TSV用画像を描くことで満たしていた。以前配布していたTSV車輛は、すべてこの頃に描いたものである。
* この段階でTSV画像を描いたことで、車輛を描くスキルとしてかなり得るものがあった。後にTK車輛を大量に描く上で大変に役立っている。
* 基本セット ver.2から、車輛の基本仕様をTSVと同じ 60px高に変えたのも、自分自身がTSVにハマっていたことも大きい。
* 2011年 12月に TSV公式サイトが消滅したため、当サイトにおける TSV車輌配布も終了にした。
この頃、知人に「自分で車輛をすべて描けっていうのは、ハードルが高すぎるんじゃないか？」と言われたが、今にして思えば、確かにそのとおりであった。

4. 大転換 - 場面限定拡張から基本セットver.3へ

●きっかけは「ED42」

基本セットが ver.2にアップするのとほぼ同時期に追加したプログラムが、場面限定拡張に分類される「既存のプログラムでは再現できない実在路線」を再現するための専用プログラムだ。
「A667 碓氷峠」と「M539 青函トンネル」である。
* A667の「ED42のロッドを動かす」プログラムは蒸気機関車拡張につながる試作、M539は実在路線シミュレータ風プログラムへの試作としての意味も持っていた。
* M539 は、2014年 4月に配布終了。
碓氷峠を再現するために「EF62」「EF63」「ED42」の実在する３つの機関車画像を描いた。
例によって「もどき」だが、実在形式画像をこれほど多く添付したプログラムは初であり、このことが後の「大転換」へのきっかけになったのである。

当時、一時的だが「仮サポート掲示板」があった。
その中で、アムトレック社の「グラフィックトレイン」についての話題が上った。
* 一応書いておくが、仮サポート掲示板の復活はありえない。
 グラフィックトレインは鉄道情景スクリーンセーバとして有名であったが、車輛はすべて完成品状態で提供される（＝ユーザー自身が描いた車輛を走らせられない）ので、自分はそれまで余り興味を持っていなかった。だが、話題に上った以上、それがどんなものなのか知りたくなり、公式サイトを見に行ったのである。
そこで見たクオリティの高い画像！
インパクトがあった。確かにプロが描いた有料ソフトとなれば高質なグラフィックは当然かもしれないが、列車が左右に走るだけという構造そのものは電車走行キットと大差はない。言いかえると、電車走行キットでも画像のクオリティを高くすれば、これと同じようなインパクトを持ちうるということだ。

では、電車走行キットがグラフィックトレインより見た目のクオリティが低いと感じさせている元兇は何か？
それは添付している「もどき車輛」にある、と感じた。
もちろん背景画の要素も大きいのだが、一番の原因はやはり車輛にあると思えたのだ。
ここで、A02添付のEF64、A667添付のEF62、EF63、ED42を「TSV並の精度で描き直す」ことに決めた。
* EF62、63、64を描き直した時点で、EF65も欲しくなり、さらにEF58も欲しくなり、きりがないので「こうなったら機関車は全形式描くしかないな」と思ったのも、この頃である。なお、A02添付機関車は後に EF64から EF65に変更した。後年、A02とがA02SLと統合したことにより、EF65は添付ではなく直接配布に変更。
* グラフィックトレインも後に販売終了となり、今は過去のものとなってしまった。
●大転換のはじまり

もどきではない、ちゃんとした車輛画像を添付するということは、それまでの「車輛は各自、一から自作してね」という方針を転換することになる。
自分的にはどうしても「組立キット」でなければならない理由があり、この基本方針は譲れない。それゆえに、完成品としての画像配布ということに強い抵抗を感じていたのだ。

だが、この頃になると電車走行キットの需要が、ウェブページ用だけではないことも分かってきた。
パソコン内だけで楽しむ「鉄道環境ソフト」としての需要があったのだ。これならば、別に何から何まで完成品で揃えたとしても何ら問題はない。
* ウェブは表現ツールである。そこに完成品（＝他人が作ったもの）だけで鉄道シーンを作ってしまったら、そのウェブサイトを持つ人独自の表現とは何なのであろうか。そこが、環境ソフト＝鑑賞ツールとの決定的な違いであり、ウェブ用としては「組立キット」でなければならないと自分が考える理由である。詳細は後述「番外11- 飽きについて」参照。
 それに、鉄道車輛の形式は数限りなくある。何から何まで自ら制作する、というのも限界がある。スクラッチ模型を作る人だって、完成品車輛を一切買わないわけでもあるまい。ウェブページ用としても、完成品画像があっても、これまた問題がないのではないか？

……完成品としての車輛画像を配布することへの、心理的ブレーキがここで外れたのである。
* だからと言って「組立キット」をやめたわけではないので、完成品車輛のウェブ上での使用条件に「他に自作編成を走らせること」という条項があるわけだ。一部、自作編成不要の特例条件画像もあるが、その場合も「風景画の自作」を代替として条件に入れている。
●仕様の見直し

ED42の動輪ロッドを動かすプログラムが出来た時点で、将来、蒸気機関車を走らせる見通しが立った。
だが、色々考えてゆくうちに問題も見えてきた。それは架線である。
この頃は架線と架線柱はひとつの画像だった。だが、蒸機が架線下を走る場合を考えると、架線は煙に隠れるが手前架線柱は隠れない。これを表現するためには、どうしても架線と架線柱を分離した画像仕様にする必要がある。
他にも、A01/M01系と、00系のプログラムでは線路の画像仕様が異なるという不統一な部分もあり、これも統一したくなった。

仕様の変更というのは、スポーツで言えばルールの変更である。
ユーザーにとっては迷惑至極だ。特に「すでに描いてしまった絵を変更しなければならない」場合は超迷惑な話である。
だが、今度ばかりは変えねばならない。
拡張性について全く考えていない仕様のままでは、先々困ることになる。
* 架線と線路に関して、旧仕様も使えるような設定パラメータがあるのは、迷惑度を最小にするためである。
迷惑な仕様変更ゆえに、今回限りにしたい。
今回限りなら思いきって大変更してしまおう。そう決断した。

●システムとしての見直し

今から振り返ってみれば「なんで？」と思うのだが、A01系、M01系、00系それぞれに、編成指定パラメータが異なっていたし、指定方法も大きく異なっていた。きわめて不統一だったのだ。
* A系はドア開閉の都合上、右端車輛から順の設定、M系は左端車輛から順の設定になっていた。現在はどちらも左端車輛から順に設定するように統一されている。
 行き当たりばったりにプログラムを書いてきたというのもあるが、A系とM系のパラメータを統一できない事情はあったのだ。ただ、この頃になると自分自身の JavaScriptのスキルが向上して、以前はできなかったことができるようになってきた。不統一だった編成パラメータも統一できる方法を見つけていた。

編成パラメータを統一できる見通しが立ったことで「すべてのプログラムが、統一された電車走行キットシステムの一部となる」という、あるべき姿が見えてきた。
要するに「システム」という概念を、この時点で初めて抱いたのだ。
そして、システムとしての完成度を高める目的と、キット設定のハードルを低くする目的で設定支援ツール「X01」を開発した。これを核として、あらゆるプログラムを統一性を以て使用可能となった。

この大改定は 2002年8月。基本セット ver.3となった。
* X01は基本セット ver.3用に開発したものだが、基本セット ver.2時代の最終段階で先行公開している。
5. 更なる拡張 - 確立したシステムの中で

●拡張プログラムの増加

その後、単線版「A05」、機能拡張版「A03」、さらに「A02-Kids」と拡張プログラムの数が一気に増えた。
システムとして確立したことで、新しいプログラム（といっても既存のプログラムからの改造がほとんどだが）の開発がやりやすくなったのが大きい。

その次に公開した「A226 瀬野八」は、初期設定の151系と153系を、ゆめじさんに描いていただいた。
「A667 碓氷峠」ver.2でも、189系を描いていただいたし、自分ひとりではなかなか進まないことも、こういう協力を得られることで進むようになった。ありがたいことである。
* 実は他の方々からもそういう協力の申し出を頂いたが、おぱく堂は傲岸不遜な人間であるため、基本的にはお断りしている。よほどのことがない限り、自分が他の方に協力を依頼することはない。確かに感じの悪い態度だし、人間性にも問題があることは自覚している。
* この事に限らず、色々な方々からの提案やバグ報告などにより、電車走行キットを育ててもらった。本当に感謝の他はない。
●ようやく蒸気機関車

ED42のロッドを動かした時点で、蒸機表現のためのプログラム的問題はほとんど解決していた。
ただ、蒸気機関車に関しては「仕様」が定まらずになかなか進まなかったのだ。前述したとおり「仕様」というのはスポーツでいえばルールと同じ。おいそれと変更できないがゆえに、慎重に決めねばならないわけである。
* 最初の蒸機画像のD51に関して「動輪直径を間違えて描き直した」というのも、遅れた原因だったりする。

そんなこんなで、ついに蒸気機関車まで走るようになり「電車走行キット」という名前にそぐわないことになってしまった。まぁ、英名の「TrainKit」の方は電車に限定していないし、今更名称変更はしないが、名前のギャップは当初の予想以上に進化した証と言えるかもしれない。
* 反面、プログラム容量の増加や、多機能化による低速CPUマシン上での動作の遅さといった問題も生じてきた。これらを含めて考えれば、進化とばかりも言えないかも。ジレンマである。……その後、予想以上にパソコンが進化して、容量や動作速度に悩む時代は過去になった。
* おぱく堂本人も進歩したかもしれない。電車走行キットを公開してから、ゆめじさんを初めとして色々な方から教えられ「なんちゃって鉄道ファン」の一人でしかなかった自分も「まともな鉄道ファン」の世界の住人になれそうな気配である（そうか？）。
●TK界の拡張

電車走行キット用のTK規格車輛の画像作者の方々も増え、この世界は広がった。
画像作者の方々を「シェフ」に喩えれば、自分の役割は「生産農家」ということになろうか。プログラムは表現の道具にすぎない。重要なのは、これを使って表現される鉄道シーンであり、それは画像を描く人のクリエイティビティの世界だ。生産農家にはシェフがどんな料理を作るのかは予想できないが、自分の作った食材でおいしい料理ができれば嬉しいものだ。
* 自分も車輛画像を描いているので、シェフ側にも片足つっこんでいるのではあるが…。
* TSV車輛を「データ」と呼ぶのに対して、TK車輛を「素材」と呼ぶのも、プログラム用のデータというよりも、鉄道シーンを作るための素材という意味を強調するためでもある。
様々な鉄道シーンを表現可能にするため、今後も色々な拡張プログラムを作るであろう。
だが、それはすでに確立した基本システムの延長線であり、大変動のようなものはあるまい。何事であっても草創期は変動が多い激動期だが、電車走行キット開発史的には、もはやそういった草創期は過ぎたと言える。徳川幕府でいえば、家康、秀忠の時代は終わったのである。よって、このページに書くようなネタもこれ以降はそれほど多くはあるまい。
* 草創期が過ぎた事は、良く言えば「成熟」、悪く言えば「停滞」である。どんなものであれ、これは避けようのない宿命だろう。たとえばゲーム機なんかも凄い進化を遂げたが、草創期のファミコンブームのあの熱気は二度と戻って来はしまい。成熟と停滞は同じカードの表裏であって「停滞なき成熟」など言葉の遊びでしかない。
  
6. 海外へ - 野望と挫折!?

●英語版事始

家康、秀忠と来れば、次は家光だ。
家光は所謂「鎖国」で知られるが、電車走行キット的には家光の段階として開国ならぬ「英語版」の追加がある。

当初は英語版の予定はなかった。
しかし海外鉄道シーン用の右側通行バージョンは2001年の段階から計画はあり、それ用の画像もその頃から描きはじめている。これは日本人の海外鉄道ファンを想定したもので、海外に向けたものではない。その後、右側通行に関して、パラメータで切替可能となり、右側通行専用プログラムの計画は中止になった。
* 計画中止で宙に浮いた海外画像は、左上フレーム走行見本用に転用。早い段階（No.11）から海外シーンの走行見本があった理由はこれである。
ある時「海外の鉄道側面画事情はどうなっているんだ？」という疑問を抱き、色々検索してみた。
それで分かったのは、TSVのような鉄道スクリーンセーバにはドイツの MM&MMがあり、TBのようなウェブ素材には アメリカ発の TrainGif（以下 TGと略す）という類似規格が存在するのに対して、電車走行キット的な存在は海外にはない、という事だ。
* 優秀なプログラマは皆「鉄道ゲーム」の方へ行ってしまうようだ。プログラム的には「鉄道シーンを作る」などというのは中途半端なのかもしれず、プログラマ的には食指が動かないのかもしれない。さらに言えば、ソースが丸見えの JavaScriptは金儲けにつながらない。これを使ってあれこれやろうとするのは酔狂な野郎だけなのかも…。
 「JavaScriptで鉄道車輛を走らせる」ということで言えば、アメリカにもあった。
しかし、それは Marqueeの代用（＝Marquee非対応ブラウザ対策）という目的であり、風景やら鉄道構造物やらと組み合わせて総合的な鉄道シーンを作るという目的のものではない。つまり電車走行キットは世界唯一ということになる。
* アメリカの The Train Gif Javascript Project は、2000年に開発されている。その後の発展計画も明らかにされていたが、立ち消えになっているようだ。Marquee非対応ブラウザである Netscape4 の極端なシェア低下でその存在意義を失ってしまったのではないかと推測する。
ここに到って「他に類似品がないうちに英語版を作って海外の鉄道側面画界に日本人の力を見せつけたろか」などという尊大な考えが頭をよぎった。気分は日本海海戦である（違うって…）。
海外用画像はすでにあるし、後は英語だけだ。
といっても、学校の英語のように点数で評価されるわけでもなく、ちょっとした言い間違いが致命傷になりかねないビジネスシーンとも違い、「通じればいい」というレベルの話。間違った英語を使うことを恐れなければ何の事はない。
* 間違った英語を使うことを恥ずかしいと感じてしまう人にとっては気楽な話ではないかもしれない。おぱく堂は「間違いだらけの人生」を送ってきたので、いちいち恥ずかしがっている場合じゃなく、その程度のことはもはや恥ずかしくも何ともない。「おまえの英語は猿以下だ」とかバカにされても、事実そのとおりだからねぇ…。そんなことを言われたら「ウキッ」とか反応してウケを狙っちゃうかも。
* とはいえ「通じてくれなきゃ困る」のも事実だから、自らの英語力不足を嘆くことがないわけではない。
●先行き不透明…

2003年 7月、英語版公開。
といっても、A02SL、M00SL、M02の３つの基本的なプログラムを英語化＆簡略化したものと、TB規格用の MN00を TG規格用に改造した eMZ00の、あわせて４つだけ。
* 但し当時は、日本語サイト側からはリンクしていない。「日本人がアクセスカウンタを踏んでしまうと海外からのアクセス数の推移が分からなくなる」という理由だが、電車走行キットを使って下さっている日本のユーザー諸氏に対して、いささか水臭い態度であったことに違いはなく、申し訳ない限りである。
* 結局、日本語サイト側からリンクをつないだのは ３年が経過した 2006年 7月末である。
* 英語版と日本語版はパラメータ互換性に多少の問題がある。詳細は「英語版を使用する場合の注意」参照。
しかし…
英語版による鉄道シーンが初めてウェブ上に登場したのは、自分の知る限り 2005年 2月。英語版公開から１年半以上の歳月が流れて、ようやくである。
* 最初のネット上の英語版ユーザーは、英語ネイティブではなくオランダの方だった。
 正直、海外へのアピールがここまで難航するとは予想できず、日本海海戦の勢いはどこへやら、である。日本語版と英語版の普及にこれほどの差が生まれた背景に何があるのか、自分なりに分析した結果、最も大きな力となっているのは、画像作者の存在だと分かった。
画像作者の方々に支えられて今の電車走行キットがある。
そのことを改めて強く実感した。英語版も、そういう画像作者の参入があれば、それなりに普及するかもしれないが、先行きは不透明である。
* 人口比から考えると、たとえばアメリカのTG規格は、日本のTB規格の倍近い盛り上がりがあっていいことになるが、実際は日本のTBほどの勢いはない。TKと同じ 1px=10cm縮尺に関しては、ヨーロッパでは MM&MMの画像作者がそれなりにいるが、これとても TSV画像データ作者との人口比的には少なく感じなくもない。鉄道側面画そのものの普及が日本ほどではないのかもしれない。
* 国防上の理由から鉄道施設の撮影を禁止している国も多いと聞く。鉄道趣味そのものが成立しない国々もあるわけだから、鉄道側面画が普及する可能性のある国も限られるはずだ。
尊大な野望からスタートしたわりに情けない状況だが、こんなことは人生にはよくある事さ。
* え？　おぱく堂のへぼい英語が通じていないんじゃないのか？　…そうかも。


番外1- 駅停車システムの変遷 - ２つの方式

A01系プログラムの駅停車の話に触れておく。

プログラム的に一番簡単なのは「駅停車位置に来たら列車を止める」という方法だが、これでは「徐々に減速してきて衝動なく止める」なんてことはできない。
A01では、停止位置目標から逆算して減速開始位置を割り出し、ここを通り過ぎた列車が徐々に減速する仕組みになっている。目標となる停止位置にちゃんと止まるかどうかは、減速開始位置計算の精度による。
ただし、これだけでは精度は確保できない。
たとえば、時速 100km/hの列車は 1/10秒毎に 28ピクセル移動する。計算上の減速開始位置をどれだけ正確に求めても、実際に減速を開始する位置は最大で 28ピクセルの誤差が出ることになる。実はA01 ver.3.0まではこの誤差を自動補正できなかった。
A01 ver.3.1からは、移動ピッチが正確に減速開始位置と重なるように、列車の出発座標も計算して補正している。これで飛躍的に精度は高まったが、後に計算方法を改良して更に停止位置精度を高めた。
以上は「旧システム」の話である。
* ちなみに、左上フレーム走行見本のプログラムも旧システムである。なお、駅停車システムのイメージは No.1475 参照。
路面電車用A07には信号機がある。
赤信号で停止して、更に駅に停車しなければならない。さらには青信号で通過した場合や、赤信号で減速したが途中で青になって減速をやめた場合でも駅にちゃんと停車しなければならない。
これは旧システムの駅停車方法では無理だ。
旧システムは大砲と同じ。弾道計算（減速開始座標計算）をして、後はドカンと撃つ（発車する）だけ。一度飛び出したら、変更はできない。
これを変更可能にするにはミサイルと同じ方法が必要となる。それが、A07用に開発した新システムだ。
A07では、現在の速度、制動距離、停止位置目標との距離から減速開始位置を計算しながら走っている。これなら、どんな状態からでも正しい位置に停止させられる。
ただし、この方式でも100km/hでの最大28ピクセル誤差（A07は路面電車だから速度からしてそんなに大きな誤差にはならないが）は解消されない。かといって旧システムのような補正方法は使えない。
これに関しては、実車と同じ方式になっている。停止位置目標を超えそうになったら強く減速し、不足しそうになったら緩める。これで補正して停止位置目標に限りなく近い座標で停止するようになっているのだ。
* この新システムのベースになったのは、青函トンネルM539の「知内駅・強制停車」プログラムと、瀬野八A226の「走行中補機自動解放」プログラムだったりする。
* 路面電車＋信号機のシーンあり。→ A07走行見本（別窓）
単純な駅停車しかない地下鉄用A08も新システムになっている。
停車だけを考えれば新システムにする必要は何もない。実は新システムには別のメリットがあるのだ。
A07は信号機が何色かで走行パターンを変える処理が必要である。そのため、走行パターンを切替えやすくする構造になっている。さらに事前の減速開始位置計算が必要ないため、事前処理の部分がシンプルにできている。つまり改造しやすいのだ。
新システムが必要ないプログラムであっても、新たなプログラムに関しては新システムベースの方が改造しやすく、開発が楽なのである。
ということでA07、A08に留まらず、以降のA系プログラムはすべて新システムベースとなる予定。A03も新規追加機能の都合上、ver.2からは新システムになった。
* A07用に開発した新システムだが、公開順では A08が新システム採用第一号となった。
* 走行中に補正計算をする A07系システムよりも、事前に補正計算を済ましておく A01系システムの方が改造しやすい場合もないわけではない。
番外2- 00系という異端児 - 単純な構造ゆえにできること

最初の拡張プログラムは、後に00系と総称されるプログラムのルーツ「A00」である。
A01から駅停車、ドア開閉、踏切、信号、編成入替という機能をすべて取り去った、走行部分だけのプログラムだ。背景画像すらなかった。要するにMarqueeでできることをJavaScriptで置き換えただけの代物だ。メリットといえば、Marqueeに対応していない Netscapeでも走行可能なことぐらいしかなかった。

これを多編成化したのが A00-plus（後のA00N）。
但し多編成化の方法はA01系最初の多編成版A02とは異なっていた。A02では「列車オブジェクトの中身を入れ替える」ことで多編成化した。列車オブジェクトは右行左行の２つのみ。それに対して、A00-plusでは「編成の数だけ列車オブジェクトを用意する」という方法で、A02では見捨てざるをえなかった MacIE4での表示を可能とした。
* 但しこの方法で編成数を増やすことにはデメリットがあり、後に設定可能編成数を増やすとともにA02と同じ方法へと切替えた。よって現行の00系プログラムはMacIE4では走らない。
* A00-plusの登場によって存在価値を失ったA00は後に配布をやめた。
A01は複雑な構造ゆえに制約も多いが、00系は構造が簡単ゆえにその制約に縛られない。
そのために、後に背景画像が付いたり、簡易手動運転版が追加されたり、M01系同様の背景スクロール機能が付いたり、独自の進化をすることになった。当初はそういう進化をとげるとは考えていなかったので「A00」などという安易なコード番号にしてしまったが、今にして思えば、A01系ともM01系とも異なる路線なので、AとかMとかではない別の記号にしておけばよかった。
番外3- 手動運転版の種類が少ない理由 - へぼ野郎の限界!?

手動運転版は、自動走行版よりプログラムの数が少ない。理由はコントロール部分の開発が面倒だからである。
特に回転するレバーがややこしい。
絵的にはレバー角度の違う画像を切り替えるだけだが、違和感のない操作感を得るために内部処理的にはレバー角度を計算している。
プログラムで回転とか角度といったものを扱う場合、必須なのが三角関数。
はるかなる昔の学生時代に、数学は常に落第寸前・追試常連だった自分が、こんなところで三角関数なんぞに再会するとは思いもよらなかった。特にM04では、単弁、自弁、逆転機、マスコン、弱メ界磁と５つもの回転レバー処理があり、もう笑うしかない三角関数三昧であった。
* 左上フレーム走行見本 No.1454+、No.1501 に、三角関数を駆使したシーンあり。前者は鉄道とは言い難いが…。
手動運転版はひとつ開発すると、しばらくは次を作ろうという気になれないのが実情だ。
* こんなレベルであるにもかかわらず「いつかは蒸機の手動運転版を作りたい」などと烏滸がましいことを考えている自分であった…。
* ↑というのも過去。もはや次はない。
【追記・レトロ枠？】
ぶっちゃけ、手動運転版は色々終わってる。
ひとつは、想定上限幅が 1600pxで設計されているため、パソコンのモニタの主流 1920pxでは狭く感じてしまうこと。
もうひとつは、スマホなどの小画面非対応な上、タッチ操作に対応していないこと。
* タブレットならサイズ的に丁度いいのだが、タッチ対応してないのが致命的。
 手動運転版は、今後も改良する気力なし。といって廃止するつもりもない。
スマホ登場以前の、西暦2000年代初頭の個人サイト全盛時代のネットの遺物として、レトロ枠として、なんとな〜く残している感じ。
* ちなみに、自動走行プログラムなら、No.1155 のようにタッチ操作で運転可能。同じ事は、A02SL-Expert＋カスタム関数で可能なので、元々シミュレータ性の低い手動運転版など、もはや存在しなくても何の問題もないだろうさ。
番外4- バグという大敵 - ボケている場合じゃない

電車走行キットプログラムは、主として「カスタマイズの幅を広げる」方向に進化してきた。
それは同時にプログラムの複雑化であり、設定の組み合わせ数の極端な増加でもあった。その結果、自分のミスの増加、全ての設定組み合わせをテストできないという状況の発生による見落としとなり、バグの増加というありがたくない問題を生じさせた。
* バグが最も多かったのは、A01より複雑で、かつ常に最優先で新機能を搭載してきたA02系だった。ただA02系への新機能搭載も限度にきて、以後は特別な鉄道シーン毎に独立したプログラムを作ることになる。バグ発生主体もそちらへ移行するのだろうか…。
* 手動運転版は、内容が複雑なわりにバグ発生件数が少ない。カスタマイズの幅が狭いのが幸いしているようだ。
バグが見つかるたびに修正版を出しているが、基本機能の部分でのバグ発生はもはやなく、新機能がらみ（いくつか前のバージョンでの新機能がらみのバグがかなり後になって判明する場合もある）である。新しい機能を追加する作業において、どれだけミスを無くせるか、どれだけ色々な状況を想定できるか（想像力の問題）が鍵なのだが、頭脳をベストな状況に保つのも限界がある。困ったものだ…。
番外5- 見果てぬ夢？ - 電車走行キットの限界

電車走行キットでは表現できないものとして「音」と「勾配」がある。
【注】・勾配表現に関して、かけやまさんよりアイデアを頂いたため、後に実現した。詳細後述。
「音」に関しては、プログラムを改造して「踏切音」を付けた方は存在する。
踏切開閉スクリプト部分に追加改造して「無音」と「踏切音」のBGMを切り替える、という手法だ。但しネット公開はされていない。
仮にウェブ公開しようとしても、ブラウザがIE限定になることや、音データの事前読込にJavaScriptが対応できない（と思うが、おぱく堂が方法を知らないだけかも）こと、あるいは音データの著作権など、問題が多々あるだろう。
「速度に連動した走行音」となると、JavaScriptではどうにもできない。もっとも、JavaScriptは Flashとの連係（LiveConnect機能）が可能であり、Flashの機能を使うことで、あるいは可能かもしれない。まだ自分的に研究不足である。

「勾配」を実現するためには、車輛画像を傾けなければならない。
 ドイツの「BahnLand」という鉄道スクリーンセーバ（自分は持っていないが）では、車輛画像をプログラム側が傾けて勾配線を表現可能にしている。鉄道側面画用プログラムでこんな機能を付けているのは、世界でもこれだけだろう。ウェブ上で同じような勾配表現を可能にする手段は Flashしかない。
JavaScriptやCSSには、画像を傾ける機能がない。WindowsIEなら90度単位で傾けることは可能だが、90度じゃどうしようもない。となると、電車走行キット的には、最初から傾けて描いた画像を使う以外に手はない。しかも、ピクセル単位でしか動かせない以上、様々な制約がある。絵的にも中途半端な傾斜ゆえに生じる段差が、かなり目障りなのは必至だろう。
 （↑CSS3対応ブラウザでは、画像を自由な角度で傾けることが可能になった。追記後述）
結局、ウェブ上で鉄道シーンを作る上で最強のツールは Flashということになる。
ただし、Flashを使って鉄道シーンを作る場合、駅停車、ドア開閉、踏切動作、信号動作という機能のすべてを、表現する人自身が設計しなければならない。最強ではあるが、凝ったシーンを作ろうとすればハードルも高い。
（↑今や、世界は Flash を排除する方向に流れている。最強ではあったが、もはや表現ツールとしては有用ではなくなった）
 * Flashを含めて、電車走行キット以外の走行手段に関しての詳細は「鉄道側面画研究（走行手段篇）」参照。
【追記1・勾配表現について】
当初、勾配表現は不可能だと思っていた。だが、かけやまさんから頂いたアイデアによって可能になった。
地下鉄用A08の明暗切替の応用で「1pxごと列車の走行位置高さをずらしたシーンを重ねれば勾配は可能ではないか」と。実際試したところ、うまくいった。但し重ね枚数が極端に多くなるため、元々の重ね枚数の多いA01系ではなく、簡易走行00系ベースで作った。これが「KA00」である。かけやまさんには大感謝である♪
この表現でも 1px段差は避けられないため、Flashを使った勾配表現（自動的に色補完がされるので段差が目立たない）ほどリアルにはならない。しかし、25‰以下ならさほど段差も気にならないようだ。
* 箱根登山鉄道の 80‰シーンあり。→ KA00走行見本（別窓）
【追記2・もうひとつの勾配表現】
前記「KA00」は極端な急勾配を表現する上では描画上も動作上も問題がある。そのため 90‰の上限を設けてある。だが、世の中には 250‰のラック式鉄道もあるし、それ以上に急勾配のケーブルカーも存在する。これらの鉄道シーンを表現するためには、別の方法が必要であった。
それが「傾斜した状態で描いた車輛を斜めに走らせる」という方法による勾配プログラム「IA01」である。
左右方向だけではなく上下方向にも車輛を動かす IA01では、傾斜 45度の時にギクシャク感が最少となる（左右方向と上下方向の移動ピクセルが同じ数になるため）。それに近い傾斜30度を超えるようなケーブルカーではさほどギクシャク感は目立たない。逆に、通常鉄道の緩い勾配では絵的にも動作的にもギクシャク感が目立ち過ぎる。KA00とは反対の性格を持つため、KA00を補完するという所期の目的には適ったものとなった。
ただ、ラック式鉄道用（つまりケーブルカーよりは緩い勾配用）としてはやや動作に不満はある。かといって、JavaScript的には「1px単位以下の動作時に色補正により中間的表現を可能とする」といった機能はなく（Flashにはある）、これが表現上の限界だろう。
* 左上フレーム走行見本 No.787 等に、IA01方式による勾配シーンあり。
斜に走らせることの副産物として、アイソメトリック投影による疑似3D表現なども可能となり、電車走行キットが「側面画」という枠を超えることになった。とはいえ、立体表現の描画難度は側面画の比ではなく、可能ではあっても、そういう表現用に使う人は限られるだろうと思う。
* 2007年 8月に「IA01用アイソメトリック3Dセット」の配布を開始して多少はハードルを下げた。それでも疑似3D鉄道シーンを作るのが難度の高い作業であることに変わりはない。
* 左上フレーム走行見本 No.510 等に、アイソメトリック3Dのシーンあり。
【追記3・新時代の勾配表現】
Webkit系ブラウザは 2008年から、Mozilla系ブラウザは 2009年から、IEは 2011年から、ウェブページ上の配置物を自由な角度で傾けることができるようになった。電車走行キット的にはちょいと面倒だが、鉄道側面画の世界全体として見れば、勾配表現の可能性が広がったことは確かだ。
* 具体的なブラウザ名でいえば、Safari 3.1以降、Google Chrome、Firefox 3.5以降、IE9以降、ということになる。
* ↓下の箱根登山鉄道モハ２形が傾いて見えていれば、貴方のブラウザはこの機能に対応している。


* この件は、Calciteさん（← Schwertさん）のブログを読んで、2013年に初めて知った。知らぬ間にこんなことが可能になっていたとは、世の中は進歩していたんだねぇ。というか、おぱく堂が最新情報に疎すぎ。
* 電車走行キットでも、ソースの鉄道走行オブジェクト（親子構造の親部分）に CSS指定を直接書き込めば、すぐにでも勾配表現は可能。ただし、そのままでは何でもかんでも傾いてしまうので、表現上、難しい問題を孕んでいる。となれば部分的に傾けるしかなく、JavaScriptで制御する方法も少し試してみた。A02SL-Expertで、カスタム・オブジェクトだけに傾斜指定を入れるという手法だ。しかし、カスタム・オブジェクトはちゃんと傾斜してくれたものの、レイヤの前後重ね順（z-index）指定が無視され、カスタム・オブジェクト以外の本来は背後にあるべきものが手前に出てしまう等の理解できない現象が発生。……当初はこの原因が分からず、カスタム・オブジェクト以外をフレーム画面外の座標に配置するか、すべて消し去るという野蛮な方法でかろうじて勾配表現を成立させた。
* 上記の、カスタムオブジェクトだけを傾斜させ、本来は背後にあるべきものを消去したことでかろうじて実現した勾配表現の例は No.1442。手前に傾斜指定のないオブジェクト（この場合は架線柱）を重ねる分には問題ない。
* もうひとつ、カスタム・オブジェクトを使わず、通常オブジェクト（親）を傾けた上で、傾けたくないものだけ（子を個別に）逆方向に傾けて元に戻すという手法も試してみた。だが、回転の中心となる変形の原点（transform-origin）の設定がややこしい上に、一度傾けたものを元に戻すため、画像がぼやけてしまったりする。試してはみたが、あまり使えない方法だと思う。
* その後、z-index 指定どおりの重ね順にならないのが、スタック文脈（stacking contexts）というものによると知り、傾斜させたオブジェクトの背後にあるべきものを、ちゃんと背後にする方法がようやく分かった。その結果を受けて、瀬野八補機の歴史を辿る No.190+ を勾配付シーンに改造した。さらに、No.27 → No.27+ のように、水平に走行させていた勾配区間のシーンを傾斜させただけのバージョンも追加した。……これら勾配表現の試行錯誤を経て、A02SL-Expert v4.4 に、部分的に傾けやすくする設定を追加。やや難度は高いが、電車走行キットにおける勾配表現はこの手法が定番になろう。
* 勾配表現の違いを比較。大井川鐡道 90‰ → 追記2の IA01方式；No.426／追記3の transform 使用：No.13+。
番外6- 連結と解放 - CA系プログラム誕生の背景

A02等の機関車牽引列車対応プログラムは、機関車と被牽引車輛を連結した状態で「ひとつ」の列車オブジェクト（配置物）にしている。
だが、このままでは機関車と被牽引列車を切り離すことはできない。連結や解放といったシーン用のプログラムは、機関車と被牽引車輛では別々の列車オブジェクトにする必要がある。
* 必要もないのに別々のオブジェクトにすると、プログラム動作を重くする原因になる。よってA02系のプログラムは今後も機関車と被牽引列車を分離することはない。
* と言いつつ、A02SL-Expertにある「機回しもどき」機能では、機関車と列車が分離している。複線のA01系プログラムは元々、左行と右行という２つの列車オブジェクトがある。あれは、左行用を被牽引列車、右行用を機関車に流用しているだけで、新たなオブジェクトを追加したりはしていないのだ。
機関車と被牽引車輛を別々のオブジェクトにした最初のプログラムは「A667（横軽）」である。といっても、このプログラムには連結も解放もない。補機をEF63にするか、ED42にするかを簡単に切り替えられるように、機関車を独立させただけである。
連結や解放に絡んだもので、機関車を独立オブジェクトにした最初のプログラムは「A225（瀬野八）」だ。これには走行中補機自動解放シーンがある。但し解放のみ。この時点では連結用プログラムは作れなかったのだ。

実はそれ以前に連結シーンを作ってはいた。
TSV用のE257系の走行見本を「増結編成を基本編成に連結する」シーンにしていたのだ。
* TSV用車輌画像の配布は 2011年 12月に終了した。
 しかし、これが配布用プログラムに結びつかなかったのには理由がある。
連結シーンでは、手前での一旦停止と連結と２度の停止がある。しかも後者の停止位置精度が1pxの狂いも許されない。
前述のE257見本では、増結編成を停止させてみて座標を調べた上で、そこに基本編成を配置しておいただけである。つまりは計算によるものではなく「現場合わせ」で作ったシーン。指定した座標にちゃんと停止させる機能はなかったのだ。
* 後に、この走行見本は、後述の「ちゃんとした」連結解放系プログラムに置き換えてしまった。→ CA50SL走行見本 E257（別窓）
つまり、解放だけなら簡単だが、連結させるとなると厄介なのであった。

連結シーンが可能になったのは、番外1で書いた「A07用の駅停車システム」である。
信号と電停の２度の停止と駅停止位置精度補正機能。路面電車に必要だった機能は、同時に連結シーンを可能にした。
その結果として生まれたのが、連結・解放がらみのシーン専用のCA系プログラムというわけだ。
* A07公開から、CA系最初のプログラム「CA50SL」完成まで半年以上の時が流れているのは、単にやる気がなかっただけ。
* しかし、CA50SLを作ってみたら意外に面白く感じて、連結解放に絡んだ色々な鉄道シーン用のバリエーションを作ることになった。
  
番外7- 蒸気機関車を走らせる - 仕様の紆余曲折

(1) 車体と動輪を分離した理由。
海外のスクリーンセーバ MM&MMなども動輪が回る蒸機に対応しているが、これは機関車画像まるごと切り替える仕組みになっている。MM&MMは動輪一周４枚に固定されているからまだよいが、発進停止を組込むとなるとスロー時のスムーズ動作から４枚では足りず、最大16枚ぐらいに達し、機関車まるごと16枚では画像容量が無駄に大きくなってしまう。
もうひとつは、日本の近代蒸機は動輪まわりの設計に大きな変化はなく、外観上同じ動輪画像をいくつもの形式に使い回すことが可能であるということだ。だったら、車体と動輪を分離した方が、車体を描くだけで違う形式を揃えられるので合理的だ。
* 以上のことは、蒸機規格の元となったA667のED42のロッド動作プログラムを作った時点では既に考えていた。よってED42も車体と動輪を分離した画像仕様とした。しかし、十分に考えていたわけではないため、その仕様のまま後に蒸気機関車を走らせようとした時に問題がでることになった。結局、ED42に関して、後に蒸気機関車規格に合わせる形での仕様変更を余儀なくされた。
 結果的に、動輪を共用して車体を載せかえる「着せかえ人形」方式となっているが、描画的にはかえって面倒と感じる人もいるかもしれない。


(2) 動輪コードが右行昇順である理由。
動輪を含めて蒸気機関車の画像を描いたことがある人は気付いただろうが、右行動輪と左行動輪の画像は、単純に左右反転するだけでなく、ファイル名に付く動輪コードも逆順にしなければならない。その原因は「右行昇順」というコード付番のルールにある。
これを避けるためには「前進昇順」というコード付番にすればよく、実は当初はそういうルールで考えていた。
しかし、前進昇順には大きな問題があった。
それは後退運転、つまり左向きの機関車が右行するといった場合だ。この場合、右行が前進方向になるため、車体が左向きであるにもかかわらず左行用前進昇順の動輪が使えない。絵は同じなのに、後退用にコード番号を逆順にした別ファイルを用意しなければならなくなる。これに気付いて「右行昇順」にルールを変更したのだ。

(3) 難物の煙。
煙の仕様に関して「簡易仕様」と「詳細仕様」に分けてあり、現状では「簡易仕様」しか存在しない。
これは、あれこれ考えつつ、まだ答が出ていないためであり、状況に応じた煙表現を可能にする「詳細仕様」への道は遠い。
煙突は後述するとして、白い水蒸気が出る個所は複数ある。
ドレインは主として発車直後だけの噴出だが、その他に絶気運転中にも開いている。絶気だから何も噴出しないのかと思っていたが、写真を見る限り、絶気運転中も微妙な水蒸気は出るようだ。また、安全弁は缶圧が上限に達した時に開いて水蒸気を出す。発車前に缶圧がいっぱいになるのは分かっているが、それ以外で圧力が上限になるのがどんな場合なのか今一つ分かりにくく、表現方法に迷う。更には、発電機、汽笛、空気圧縮機、給水機あたりも動作中は水蒸気を出す表現が必要となる。
* それぞれの水蒸気を別々のオブジェクト（配置物）にしなければならないので、列車が走る自動運転系では全てを走らせなければならず厄介ではある。列車が止まっていて背景が動く手動運転系向きの話だ。
 最大難物はやはり煙突から出るものだ。
水蒸気の噴出量は加減弁の開き具合と連動するから、発車時を最大として加速中はそれなりに出して（上り勾配を組込んだプログラムなら、勾配走行時も必要となるが…）、絶気時にはほとんど出さないようにすればよい。だが、石炭（あるいは重油）の排煙は、燃やし具合で量が決まり、燃焼効率で色が決まるという２つの要素のからみが複雑だ。排出されるものは、水蒸気と煙の両者であり、量と色を決める要素が多すぎてややこしい。さらに速度による棚引き具合、ブロワバルブ開閉、集煙装置の開閉等を考慮すると際限がない。
さらにブラストなどの動的表現まで考えると、動輪画像切替との連動も視野に入れなければならず、気が遠くなる。
ついでに言えば「トンネルはどうするんだ？」というのも頭の痛い問題である。
……これらの複雑怪奇な要素を整理したマトリックスを作り、それに合わせて画像を切り替える方法が必要だが、それを考える気力が出ないため、開発が進まないのである。
番外8- 分かりやすいマニュアル - 努力と限界

折角作った電車走行キットを「誰にでも使ってもらいたい」と思うのは当然の心理である。
しかしながら「分かりやすく解説する」というのは高度な技術であって、これを身につけて文章を書くのは難しい話だ。難しい内容を難しく書くなんてのは解説としては低レベルであって、難しい内容を分かりやすく書いてこそ、高レベルの解説ということになる。
* 何を言っているのか分からん書物というのは、内容がどれほど高度であっても、解説力としては低いと言わざるをえない。
* 複雑な内容を無理矢理に単純化して「分かりやすく」擬装した解説も世の中横行しているが、そんなものは高レベルでも何でもない。それどころか、本来複雑なものが単純であるかのように誤解を与えることは時に危険ですらある。
・講談社ブルーバックス「分かりやすい表現の技術」（藤沢晃治著）
この本は非常に学ぶところが多い。マニュアルをどうやって分かりやすくするか、という努力も、この本から得たことの実践に尽きる。現在の電車走行キット・マニュアルが完璧だなどと驕る気はないが、自分にとって最大限の努力の結果でもあり、無料ソフトに添付されているマニュアルとしては、かなり分かりやすい部類にあるとは思う。

とはいえ、分からない人にとっては分かりにくいマニュアルには違いなく、更なる「分かりやすくする努力」は必要であろう。
だが、正直に言って「何が分からないのかが分からない」のが現実であり、何をどう努力したら報われるのか道筋が全く見えず、ある段階からは行き詰まってしまった。自分の解説能力がこれ以上進化するような気もしないし、分かりやすさという事に関しては、現状が事実上の限界かもしれない。つまり「もっと分かりやすく」というのは期待できないということだ（おぃ）。
* これ以上、分かりやすさのために努力しないことの「言い訳」にしかなっていない気もするが…。
* 有料ソフトなら「分かりやすくする → ユーザーが増える → 収益向上」というメリットもあり、分かりやすくする努力へのモチベーションも高められるのかもしれない。もっとも、仮に有料であっても限界ってもんはあるだろうと思う。
【追記1・概念の理解について】
電車走行キットは「概念」が理解できてしまえば、後はさほど難しくはない。
日本語圏でも英語圏でもない異国にキットを使いこなしている人々がいるのが、マニュアルのディテールが理解できなくても何とかなる証拠である。
一方、この「概念」が理解できないと、どれほど言葉を尽したマニュアルがあったとしても、電車走行キットを使うことはできないようだ。
城に例えて言えば「概念の理解」は大手門であり、電車走行キットの世界に入れるか否かの関門となるわけである。ここを越えれば、使えば使うほどキットへの理解が深まってゆくのに対して、ここを越えられないと永遠にキットを使えないことになる。
* 二極分化とも言える。
 概念の理解には想像力（厳密に言えば「直観力」）が大きく影響する。
* この場合は「直感」ではなく「直観」である。意味が異なるので注意。
 言語を通して脳内にイメージを描くことができる人に対しては、マニュアルを分かりやすい文章で書く努力は有効だが、そうでない相手に対するマニュアルのあるべき姿とは如何なるものであろうか。百聞は一見に如かずと言う。百聞に代わる一見を用意できれば、この難問に答が出せるかもしれないが、一見でキットの概念を伝えられる手段とは何なのか。さっぱり思い付かない。
* 相手が美女であれば、言語を超えたコミュニケーションで手取り足取り伝えるのも楽しかろう。荒い息づかいでパラメータ設定を教え、めくるめく官能の中でTK車輌の仕様を教えるのだ。……なんてね。そんなことしか思い付かないよ（おぃ）。
【追記2・類似の経験について】
人間は新しいことを理解しようとする時、過去の経験から似た思考パターンのものを探し出し、それを通して理解しようとする。
それゆえに、似たパターンの思考経験がないものは、かなり簡単なものでも理解できなかったり、逆に、似たパターンを経験していると、相当に難しいものがスッと理解できたりするわけだ。
* 簡単なナゾナゾが解けない、なんてことがある。答を聞いて「なーんだ、そんなに簡単なことだったのか」と思うようなことが、なぜ答に到達できなかったか。それは、似た思考を過去に経験していなかった、ということだ。
 電車走行キットの理解に苦しむ人というのは、過去に似たパターンのものに触れていないのかもしれない。
そういう場合に有効なのは、たとえ話（＝身近な類似パターンを持ってきて、それを通して理解の助けとする話）である。だが、電車走行キットは何にたとえるべきか。これが分からない。
* おぱく堂が得意とするエロ話に似た思考パターンのものがあれば、たとえ話もできるのだろうが…。
番外9- 側面からの逸脱 - あるいはツール論

電車走行キットは当初の側面画専用から拡張し、側面以外に正面画走行プログラムや、上面画垂直走行機能付のプログラムも作った。勾配の応用によるアイソメトリック3D表現も可能になった。
これらの機能は、側面画CGという位置から見ると「逸脱」なのだが、実は自分的には逸脱ではない。
元々「ウェブ上で動く鉄道シーンが作りたい」という一点からスタートしたものであり、側面画でなければならないとは思っていなかった。ただ、GIF画像＋JavaScriptという道具立てで鉄道シーンを表現するには、側面画が最適であり、それ以外の視点の画像を動かすためには画像にも制約があるし、プログラムも当初は実現できなかった、という事なのだ。
* 正面画用プログラム F01の開発開始時期が、電車走行キット公開の翌月、というのも側面画にこだわっていなかった証拠である。
電車走行キットは「ウェブ上に鉄道シーンを表現したい」人のためのツールである。
ツールには選択の幅があった方がよい。写真撮影をする上でもレンズに選択の幅がある方がよいであろう。ひとつしかないレンズであれこれ表現しようとすれば工夫も必要だろうし、時には諦めすら求められる。電車走行キットも側面画以外のシーンをも表現できるようになったことで、ツールとして進化したのだと思う。

GIF＋JavaScript という世界では側面画がベストバランスなのは事実である。
他の視点からの鉄道車輛を走らせるための制約がなくなったわけではないし、側面画用のプログラムとしてのみ使用する人の比率が圧倒的であろう事は予想できる。この文章を書いている時点では正面画用プログラムを使っている実例を見たことがない。しかし、それでよいのである。実際には使わないレンズでも使う可能性として持っていたいという事はあるはずだ。ツールとはそういうものであり、実際に正面画を走らせることがなくても「正面画でも走らせられる」という可能性が大事なのだろうと思っている。
* この項目を書いた後、2006年 5月にネット上における正面画プログラム使用例を初めて見た。
* 左上フレーム走行見本 No.255 等に、正面画のシーンあり。
* 無論、電車走行キットでは表現できない鉄道シーンもまだ存在するし、ツールとしての完成度は十分というわけではない。
* 左上フレーム走行見本でも分かるとおり、おぱく堂自身が「鉄道シーンの表現者」の一人である。単なるツール開発者というより、表現者の一人としてツールを開発している、というのが実態だ。だからと言って、他の表現者の要求がすべて分かるわけでもないし、他の方々から教えを頂くことは多い。感謝♪
* とはいえ、自分自身がまったく使う可能性のないプログラムを開発する気になるかと言えば、それも微妙だなぁ…。偉そうにツール論をぶってみたものの、これでは空論だな。まぁ、世の中、理想と現実が食い違うのは多々あることだし（言い訳）。
  
番外10- 時代の変遷 - さらば Netscape

2008年、Netscapeの終焉がアナウンスされた。
ウェブの黎明期「Netscapeでなければブラウザにあらず」とすら言われた栄華も、はるか遠い昔話。電車走行キットを始めた 2001年には既にライバルだった Internet Explorerに完敗してはいたが、まだ生き残ってはいた。その歴史に幕が降りたのである。
* おぱく堂が最初に買ったパソコンに入っていたブラウザは、Netscape も IE も ver.1だった。その頃を思い出すと、ウェブの世界もずいぶんと変わったものだと、しみじみしてしまうのである。
ブラウザ年表

電車走行キット・プログラムの大半は、Netscapeの中でも古い ver.4でも動作する。
2001年には、Netscape4 は既に過去ブラウザではあったが、そういった過去との互換性をまだ不要として切り捨てることに躊躇する状況ではあった。だが、もはや、その互換性を維持する必要性は皆無となってしまったかもしれない。
* だからといって、Netscape4との互換性のある既存プログラムを無理に Netscape4 非対応化したりはしない。この世に JavaScriptを生み出した Netscapeへの敬意という一種の感傷もある。だが、非対応化などは、やってもやらなくても大勢に影響のない作業であり、ファイル容量もさほど軽くはならない。さらに作業時に記述ミスでもすれば新たなバグを作りかねない、という問題もあるからだ。
【追記1・IE9という境界】
前述の「番外5‐追記3」でも触れたが、スマホやタブレットの普及とほぼ平行して、ブラウザの表現能力が大進化をしている。回転（＝傾斜）もそうだが、拡大縮小、歪みなどということも、CSS指定だけで出来てしまう。電車走行キットを始めた頃のパソコンの性能では難しかったことが、今や簡単にできてしまうわけだ。そして、2011年の IE9 の登場によって、すべての最新ブラウザがこの機能に対応した。つまり、IE9以降と IE8以前という、表現上の境界（あるいは断絶）が生まれたのだ。
とはいえ、誰でも彼でも最新ブラウザを載せられる新しいパソコンを使っているわけでもないし、電車走行キットも IE8以前との互換性を無視して進化させる気はない。だが、IE9以降の機能を使うことでどんな鉄道表現が新たに可能になるのか、気にはなる。
* しかし、ブラウザで可能なことが増えた結果、JavaScriptも過去との互換性のない機能が多々追加され、格段にややこしくなった。面倒くせぇ。……とも思ったが、ややこしくないレベルのスクリプトでも、使いこなせば、かなり色々と表現できそうだというのもわかってきた。よく「中学レベルの英語でも使いこなせば役に立つ」という話を聞くが、あれと同じだ。学ぼうと思って JavaScript 専門サイトを見に行っても「難しくて、さっぱりわからん」ということは多々あるが（多々かよ！）、簡単なスクリプトでも工夫次第でけっこうな表現は可能。
［ ついでに jQuery について ］
* JavaScriptネタにからんだ話だが「本来は複雑なスクリプトコードを書く必要があることを、簡潔な記述で実行可能な JavaScriptライブラリ」というものも存在する。その代表例が巷で話題の jQuery だ。たとえば「わたらせ渓谷鐵道」と書く必要があるスクリプトも、これを使えば「わ鐵」と書くだけで実行できる、というようなこと。しかし、簡潔だからといって簡単とは限らない。jQueryの記述ルールを新たに覚えて習熟する手間と、ややこしくても直接コードを書く手間を比較すると、電車走行キットレベルの話だと直接書いた方が簡単だ。……もうひとつ言えば、jQuery は最先端を走る方針らしく、2013年 4月の時点で IE8以前を考慮しないことにしたらしい。前述のとおり IE8と IE9の間には表現上の断絶があるから、それ以前を見捨てたい気持ちも分からぬではないが、ずいぶんと思い切ったものである。はるかに古い IE6（電車走行キット初期の頃の主流ブラウザ）ですら「IE6 Countdown」によれば、2014年 9月の時点でもまだ、日本では 0.8％のシェアがある。さらに、2016年 8月時点で再度チェックしたが、まだ 0.02%あった。限りなく絶滅に近いが、0 ではないのだ。つまり Windows Me 以前の OS しか走らない古いパソコンがそれだけ現役で使われているということだ。次々と新しいパソコンに買い替えられるほど裕福な人ばかりではないのである。さらに新しく IE8までしか使えない Windows XP ともなれば、まだどれほど多くが現役であることか知れない。それすら見捨てるというのは、過去との互換性を重視する電車走行キットの方針と真逆だ。……さらに言えば、ライブラリという既製品を使った場合、エラーが出た時の原因究明が難しいだろうというのも問題だ。鉄道模型に例えるなら、キットから組み上げたものなら故障しても内部を熟知しているから壊れた個所も見つけやすいだろうが、完成品が故障した場合は壊れた原因の特定は難しいであろう。スクリプトの記述ではエラーとの戦いは日常茶飯事だが、jQuery のようなブラックボックス的なものが紛れ込むと、バグフィックスの難度が上がってしまうのは必定。すべてのコードを直接書いていてもバグを見つけるのは難しいのだ。これ以上見つけにくくなったら堪らない。……という３つの理由から、電車走行キットに jQuery を使う日は来ないだろう。──え？　jQuery を使いこなせないだけだろうって？　まぁ、そうかもね。
【追記2・IE も終焉か】
2015年登場の Windows10 から、標準ブラウザが Microsoft Edge になり、IE11 は奥に隠れて、探さないと使えなくなった。他ブラウザとの相互運用性を重視した Edge と、過去互換性を重視した IE11 の二本立てだというが、扱いはどう見ても同格ではなく、「IEは 11で最後」という公式発表とも相まって、IEは終わりだと誰もが思う。それに、本当に過去互換性を保っていたのは IE9 までで、IE10 に至って IE独自機能がかなり削られてしまい、電車走行キットも IE10 に対応させるために全更新するはめになった。IE10〜11 に本当の過去互換性がない以上、二本立ての前提が成立していない。
* 過去互換性に足を引っ張られて他のブラウザから遅れをとることに焦りがあったのかもしれないが、IE10〜11 は仕様が迷走しているとしか思えない。
 一方で Edge は、少なくとも 2016年初頭時点ではシンプルすぎて未熟であり、他ブラウザの域に達していない。新しい主役が実力不十分なのだ。このため、かえって Firefox や Chrome のような Windows 標準ではないブラウザを使う気になる。その結果、一度でも他のブラウザを使ってしまった人は、未熟なままの Edge や、過去帳入り決定の IE に戻るのだろうか？
* 相互運用性とは、どれでも基本は同じということ。裏返せば、Edge である必然性が薄いという意味でもある。
* 自分の場合は、Mac から Windows10 に転向直後に、IE と Edge のバグのおかげで、リカバリ（Windows の再インストール）するはめになったから、余計に、他のブラウザをメインで使う決意を固めた。
 初代王者 Netscape の栄華と衰退を見て、今再び、二代目王者が退場する姿を見ることになるのか。
諸行無常。
この一言に尽きる。
* まぁ、電車走行キットも衰退しているわけだが…。
* この文章を書いて 2年半後の 2018年秋。それまで使ったことのない技術を使ったシーンを幾つか作ったが、遂に IE11で表示できないシーンが出来てしまった。さらに Edge も未熟なままで Firefox や Chrome に全く追いついていない。IE の終焉だけではなく、Edge も終わってる。……と思ってたら、2020年初頭に、Edge は Chrome と同じエンジンを積んで Chromium の一員となってしまった。旧Edge がそういう形で終わるとは予想外だったが、新生Edge は使えるブラウザにはなった。
* 2021年登場の Windows11では IE廃止。IE11自体も、2022年 6月を以てサポート終了。ついに終焉。
  
番外11- 飽きについて - 人間の宿命か？

とある鉄道模型サイトを見ていたら「知り合いで、Nゲージを始めた人のほとんどが、半年で飽きてしまった」と書いてあった。
その記事を読んで「やはり、そうか」と思った。
人間は飽きる動物である。後述する要件を満たさない限り飽きるのは必至であり、それは電車走行キットとて例外ではあるまい。作り手としては飽きられるのは悲しいが、人間の本質がそうである以上はどうにもならない。
* 男女関係もそうなのかもね。もっとも、モノとは異なりヒトは日々変化するから飽きにくくはあろう。それでも、すぐに飽きるのだとしたら……カウンセリングを受けた方がいいかも!?
一方で、模型にしても側面画CGにしても、飽きずに延々と続けている人がいる。
何が違うのか。
いきなり結論から言えば、飽きないためには「常に新しいものを入手する」か、「常に創造しつづける」か、どちらかが必須である。
模型でいえば、新製品を次々に買い続けるか、車輌キットやレイアウトなどを作りつづけるか、ということになろうか。
電車走行キットでも同じだろうが、新作の車輌画像は飽きる暇もないほどのハイペースで供給されているわけではない。となると、何かを創造しつづける人だけが電車走行キットを飽きずに続けられる、ということになる。手っ取り早く言えば、車輌か風景を自分で描く人だけが、飽きを退けられるのであろう。
* しかし、絵を描くことを楽しめない人はいる。そういう人に「絵を描こう」と言ったところで、楽しめるようにはなるまい。飽きないための方法があるとしても、その方法そのものが誰にでも受け入れられるものではない以上、必然的に何割かの人は飽きてしまうわけだ。
 レイアウトを作るのも、絵を描くのも「表現」である。
表現とは、つまり「自分の表現」であり、そこに「自分」があることが重要なのだろうと思う。与えられただけのものが飽きやすいのは、そこに「自分」が足りないからだ。
* 物自体が自分が作ったものでないとしても、楽しみ方に自分なりの工夫を加えている人は、与えられただけのものであっても、飽きないのかもしれない。
 ──電車走行キットが、完成品ではなく、組立キットとして供給しているのも「表現の道具」を意識してのことだ。
* 裏を返せば、飽きさせないための手段でもあるわけだ。ははは…。
【追記1・七年目の浮気？】
TV番組で科学者が「人間は７年ぐらいで飽きるようにできている」という話をしていた。だから、男女の恋愛においても、その辺でひとつの危機が訪れるのだとか。なるほどねぇ。人間は飽きる動物である、という自分の直観的認識は正しかったのか。

【追記2・マグマと性欲とサイト作り】
趣味のサイト作りは、火山と同じである。最初はドカーンと勢い良く噴火するが、溜っていたマグマが抜けてしまうとそこで力尽きる。
自分の場合も、八犬伝サイトは開設五年で放置。電車走行キットは続いているが、次々と新しいプログラムを作った当初の勢いはすでになく、今や車輌配布や走行シーン追加といった描画ばかりだ。性欲は抜いてもすぐに溜るが、マグマはそうはいかないのだ。といっても、1500種類以上の走行シーンを作っているのだから、これはもう性豪レベルか？
* ふん、リアルの自分は「腎虚」だから「性豪」なんて夢のまた夢さ…。
番外12- 雑誌掲載 - なぜかドイツ

電車走行キットに関して「コンピュータ雑誌、あるいは鉄道雑誌で紹介してもらえるのではないか」などと、当初は期待していたのだが、何年たってもそのような話はやって来なかった。
期待する心も消え、雑誌掲載などという想定すら忘れきっていた 2010年。ドイツの鉄道模型雑誌「MIBA」から、掲載したいとの話があった。しかも、プログラムそのものを DVD-ROM に収録したい、との事。
嬉しい気持ちと同時に悩んだ。自分が定めた再配布禁止の条件に抵触してしまうではないか、と。しかし、ヨーロッパの雑誌に掲載されれば、普及が伸び悩んでいる英語版 TrainKit の活性化に多少はつながるかもしれない。結局、自分の側にもメリットがある以上、特例にしてもよかろうと判断し、許可することにした。

そんなこんなで、2010年 11月に刊行された、MIBA 増刊「Modellbahn digital 11」（写真左）に載った。
* はるか遠くの日本まで、ちゃんと掲載誌を送って来た。日本の出版社の中には、そういうことをちゃんとしない会社もあると聞いていたので、いささか驚きはした。だが、考えてみれば、まっとうな人間なら送ってくるのは当然で、送ってこない方が失礼千万と言うべきだろう。
 しかし、不思議な気がしないでもない。
確かに、鉄道側面画と鉄道模型には共通の要素はあるだろう。そうは言っても別ジャンル。
誌面を見る限り（ドイツ語が読めないから詳しくは分からんが）模型のデジタル化を特集した増刊であり、かなりコアな鉄道模型ファンを対象としたマニアックな内容に見える。DVD-ROMには、MM&MMや Traffic ScreenSaver などのヨーロッパ発の側面画用プログラムも収録されているが、それらも含めて、読者層とは微妙にズレているのではなかろうか。
……となると、TrainKitの普及効果もさほどは期待できないのかもしれない。
だが、それでも構わない。少なくとも雑誌の担当者の目に止まるだけの価値は認められたのだ。それだけでも気分は良い。

【追記1・３ヶ月経過後】 - 2011年 2月
雑誌に掲載されて訪問者数カウンタ上昇率は以前よりアップしたのか？
結論から言えば、まったく効果なし。読者層と一致しないんじゃないか、という予想が的中したわけだ。
* まったく期待しなかったわけでもないので、多少がっかりしたのも事実である。……しかし、世の中、そんなもんだわな。
【追記2・更に…】 - 2011年 12月
2011年 8月発売の「Modellbahn digital 12」（写真中央）添付の DVD-ROM にも掲載。前述のとおり、効果は薄いだろう。だが、何冊も重ねていけば、欧州の側面画ファンの目にとまる確率も上がるかも、といった淡い期待を捨てきれない。
* ２冊を見て、日本の鉄道模型雑誌とはずいぶんと違う感じがした。模型誌というより、デジタル回路誌といった趣で、こういうものが定期的に増刊で出るぐらい、ドイツの鉄道模型はデジタル化が進んでいるということか。鉄道模型の世界を詳しくは知らないので、それ以上のことは分からないが、鉄道趣味に対する考え方が日本と違うのだろうか。だとすれば、電車走行キット英語版も、普及しない原因の一端に、どこか、彼らの趣味のツボを外しているものがあるのやも。
  
番外13- 走行キットの10年 - たま駅長は12歳

2011年 4月 29日──電車走行キットは公開から10年の日（3652日経過）を迎えた。
* ちなみに、かの有名な猫たま駅長の誕生日も 4月 29日。走行キットより２年先輩だったが、この時から４年後の 2015年 6月 22日に 16歳で亡くなってしまった。No.877 参照。
 もっとも、10周年だからといって祝賀という気分ではない。
前月に発生した大震災の心理的影響もあるが、仮にそれがなかったとしても、そういう気分にはならなかっただろう。なぜなら、10年という歳月は「新鮮味」を失わせ、商品であれば何らかのテコ入れが必要な状況である。男女関係でも「ときめき」など消え去って跡形もない。そういう時間なのだ。
* いきなり鬱な展開で申し訳ない。
 ただし、悪い面ばかりではない。
新鮮さはなくても長く続けば信頼できる定番の品となる。また、長い時間を共にした男女にしか到達できない桃源の境地（ふふふ、若者には分かるまい）は、ときめきを失った後に開けるのだ。電車走行キットも、そんな段階の入口にようやく立った。10年というのは、そういう意味でもあろう。
──長い歳月を支持して下さった方々がいてこそ、であり、感謝の他はない。
* 長いつきあいだからといって桃源の境地に達しない男女も多い。修行が足りないのじゃよ。
それで？
商売ではないので、特にテコ入れなどはしないし、このまま淡々と続けてゆくだけだ。

【追記・走行キットの15年】
2016年 4月 29日──電車走行キットは公開から15年の日（5479日経過）を迎えた。
* おぱく堂個人的には、16年も使い続けた古い Mac から、Windows に転向して迎えた最初の公開記念日という特別感がある。

 その後の 5年、淡々と続ける、という言葉どおりではあったが、予期しない「全プログラム更新」も待っていた。
最初は、2014年 4月。詳細は後述（番外15 の追記）しているが、IE10の仕様変更に対応した更新。次は IE以外のブラウザを対象とした同年 6月の「横スクロール禁止の改良」である。さらに、Chrome 対策としての、15年経過後の 2016年 5月の「横スクロール禁止設定廃止、CSS指定で代行」を含めると、計３回もの全プログラム更新を余儀なくされた。いずれも、特定のブラウザに合わせるための更新であり、振り回された感しかない。
* 見る人のブラウザを強制的に指定できない以上、あらゆるブラウザに合わせなければならないのは、宿命である。
それで？
さすがに、IE、Firefox、Chrome での表示に問題がなくなった以上、もはや、全プログラムを更新しなければならないような問題は残っていないだろう。
プログラムは、走行シーン表現という建物を支える土台でしかない。土台がしばしば更新するのは、シーン表現者にとっては面倒で迷惑な話だ。土台は安定すべきであり、以後、更新などないに越したことはない。
* 未来に不安要素があるとすれば、Edge か。……これも「Edge が Chrome と同じエンジンを積む」という意外な方向に進んだ結果、解決してしまった。
  
【追記・走行キットの20年】
2021年 4月 29日──電車走行キットは公開から20年の日（7305日経過）を迎えた。
* その年に生まれた赤子も成人。当然、中年だった自分も、もはや老年と言える還暦超えだ。
 時代は「HTML5」であり、「モバイルファースト」である。
スマホなど存在しなかった HTML4の時代に生まれた電車走行キットは、もはや過去の遺物である。
電車走行キットの使用を想定した個人サイト（サイトデザインを含め個人が一から構築するサイト）というものも、鉄道というジャンルに限らず長年続いている老舗サイトばかりが目立ち、新規の人々は皆ブログに向かって個人サイトは激減。絶滅危惧の文化である。
* 鬱々とした話だが、別に鬱ではない。単なる時代の流れである。
 ……という中で、電車走行キットの更新は、車輌画像の追加以外は、ほぼ途絶えた。
今は、プログラム配布目的というよりも、自分自身の鉄道シーン表現のためにこのサイトを維持している感じである。

つまり、左上フレーム走行見本のためにこのサイトがあるような状態だ。
といっても、時代はモバイルファースト。PCよりスマホでウェブを見る人の方が多い時代である。
走行シーンを作る時に、PCでの見え方と同時に、モバイルビューアでどう見せるかを考える。シーンの風景画を描く段階から、そこを考えている。
* 左上フレームは 220px×80pxを基本とするが、モバイルビューアでは 360px×140pxを標準サイズとしている。一方で、PCでは300px高のシーンも可能だが、モバイルビューアではそんなサイズのシーンはスクロールなしには表現できない。そういった条件の違いから、PCとモバイルビューアで見せ方の違うシーンが増えた。
↑モバイルビューア用 QRコード
20年前は JavaScriptの仕様がブラウザによって不統一で、3種類のコードを書いておく必要があった。今はもう統一され、面倒なことを考える必要はない。
しかし、Android版ブラウザは微妙な差異があって、少しばかり溜息が出る。
まずは、Operaと Samsungブラウザ。ページをスクロールするとインラインフレームの位置固定指定が無視されてしまい、モバイルビューアの表示が成り立たない。
もうひとつは、Chrome系ブラウザの仕様が変更されてしまい、httpプロトコルでは傾斜センサーのデータを取得できなくなってしまった事だ。スマホの傾斜に合わせて変化させるシーンを作ったのに、全滅。唯一、Firefoxで動作するのが救いだが……なんだかなぁ、である。
* Chrome系ブラウザ、傾斜データは取得できないのに、スマホが縦か横かは取得できる。どういう基準なのか不明。
ブラウザ上で動くキットなので、ブラウザの仕様に左右される。
20年を経ても、結局そこはどうにもならない。
* Flashとか HTML+Timeを使った動画表現は、時代の流れとともに表現不可になってしまった。それと比較すれば、JavaScriptは消え去るどころか、さらに未来に続く。JavaScriptベースで動かしておいて良かったとは思う。
  
番外14- 駄菓子化する鉄道側面画 - 高度化するウェブの中で

電車走行キットが生まれた頃、インターネット接続は、ナローバンド（低速回線）からブロードバンド（高速回線）への移行期だった。つまり、低速回線ユーザーはまだまだ多く、サイトで画像を扱う上ではそれを考慮する必要があった。
* ナローバンドがどれほど低速なのかを知らない人もいるだろうから説明しておく。1MBぐらいのファイルに 10分近くかかったのだ。電車走行キットの基本セットのダウンロードも 5分ほどかかり、走行見本も重いものでは 2分以上待たなければ表示されなかった。それでも軽い方であり、ちゃんとしたソフトなんかだと、ダウンロードするのに数時間かかるのは当り前だった。エロ動画を見るのも一苦労だった。
 だから、キットのマニュアルや、当サイトの文章にも「ナローバンドでは…」といった記述があった。
それらを書き直さないまま時が流れ、ナローバンドが死語となっても記述が残っていた。で、2012年末に至ってようやく、該当文章の削除、あるいは注記追加などの修正をした。遅すぎる対応だ。

高速回線が当り前のものとなり、高精細な動画もサクサク動く時代となってみると、鉄道側面画というのは、ずいぶんとプリミティブなものに感じる。
つまり、ウェブの鉄道世界における、電車走行キットの位置づけが「最先端スイーツ」ではなく「駄菓子」的なポジションということだ。まぁ、一度も最先端になったことはないのだろうけれども、それでもウェブ上で走らせることに、かつては多少なりとも驚きはあったはずだ。時は流れたわけだねぇ。……そんな感傷はともかくとして、個人の趣味としての楽しさを考えるに、駄菓子的位置であることは悪くはないようにも思う。ハードルの高すぎる趣味は、やがて楽しさを失いかねないから、低いことにも価値はあるだろうさ。
* 自虐で言っているのではなく、最先端ではないところに別の価値があるのは事実だと思う。マイナーではあるだろうが。
* ついでだから余談。ここで言うマイナーとは、数的少数派のことである。商売の論理からすれば数が出ないのは悪だろうが、趣味は文化だから評価基準は異なる。故障続きだった DD54も、国鉄の営業からすれば否定されるべき存在だっただろうが、鉄道趣味的には価値のある機関車だ。だが、世の中には、金銭が絡まないことでも商売の論理で判断する人々がいて、彼らはたいてい鉄道趣味などというものを理解しない。マイナーな世界にも豊穣な文化があるのに、そういう人と話しても、何も通じない。……マイナーという言葉を使うと、かつて、あまりに話が噛み合わなかった某の記憶が甦るので、つい書いてみたくなった。そんだけ。
【追記・高度化のダークサイド】
HTML5 + CSS3 という最新の機能に対応したブラウザでどこまでの表現ができるのか。ネットで探してみると、非常に高度なものに出会う。Flash を使わなくても、ブラウザだけでここまでできるのか、と驚くほどだ。こんなものを目にしてしまえば、現状の電車走行キットでできる表現が色褪せて見えるのは仕方がない。
だが、HTML5 + CSS3 という道具立てで高度な表現を試みようとすると、そのコーディングは難しい。誰もが手書きできるものではなく、大半の人はオーサリングツールに頼るしかない。結局のところ、表現する側からすれば Flash と何も変わらない作業だ。
* 唱い文句の「ブラウザだけで…」というのは、誰に対しても開かれているかのように聞こえるが、あくまで媒体の特性の話でしかない。
 インターネットがなかった昔、表現は、限られた媒体に乗れた人々だけの特権だった。ネットの登場は、それを誰に対しても開放した。ウェブの黎明期には、初めて表現媒体を手にした人々の熱があったのだ。おぱく堂もその流れに乗ったひとりである。
しかし、ウェブ表現が高度化するに従い、表現へのハードルが上がってしまった。玉石混交が許容された黎明期の自由な空気は薄れ、表現は、再び限られた人々が囲い出した感がある。
* かつては多く存在した無料サーバーが、かなり減ってしまったのも気になるところだ。
ウェブの用途の主流は、最新情報、蓄積情報、エロ視聴、通販、コミュニケーション（掲示板、ブログ、SNS）であり、表現ツールとしての用途は元々傍流である。だから、この変化は大勢に影響はないようにも思えるが、ハードルが高くなるのは良いことばかりではない。
* 電車走行キットのあるサーバーは、Dream Train Internet というプロバイダだ。略して DTI なのだが、エロ系にも別の DTI という名のサーバーが存在する。だから、メールアドレスを教えた時に「えっ？　DTI？」と驚かれたりする。驚いた人はアダルト・サイトをよく見ているということだ。
 日本人は、他国に比べて、自分に自信のない人の割合が多いという。
つまるところ、想定するハードルが高すぎるから、超えられなくて自信喪失してしまうのだ。他国では、ハードルが低すぎて、びっくりするほどのダメ人間が、ものすごい自信を持っていたりするが、日本もまた逆に極端なのだと思う。
* 鉄道ダイヤが正確なことは日本人の自慢ではあるが、それを守るのは高いハードルである。それを超えていることは素晴らしく誇らしいが、同時に、そのプレッシャーがあの尼崎の大事故の引き金になったことを思えば、そういう極端な完璧主義にも負の側面があることがわかる。プレッシャーに負けるのが悪いという意見もあろうが、負けないことを前提にした安全対策など、津波が来ないことを前提にするのと同じだ。危機管理は「〜すべき」という理想論を前提としてはいけない。考えたくないことは考えないのが人間の心理だから難しいのだが、それでも「〜の可能性はゼロではない」という最悪をも想定した冷徹な現実直視が必要だ。心理的プレッシャーも危険要素のひとつとして減らす努力をするのが真の安全対策だろう。
 ただでさえ自信のない日本人にとって、ウェブ表現のハードルを上げることは、心理的には自滅行為ではないのか。ネットが解放区ではなく、他者と自分を比較して自己嫌悪に陥る鬱のツールと化してはいないのか。限られた人々の中に入れないことで、がっくりと来てしまう元凶になってはいないのか。
* 自信のない人間が多いのは、教育（家庭も学校も）に一番の問題があるとは思うが。
 ウェブに限った話ではないかもしれないが、高度化には負の側面がある。高度化で人間は不幸にもなるのだ。
そもそも高度なものしか生き残れない世界なんて、ろくなもんじゃねぇ。獣の世界と決別して、人間が文明を手にしたのは、協力しあうことで誰もが死なないようにするためだったはずだ。弱肉強食なら獣と同じで、文明化した意味がない。科学技術がどれだけ発達したとしても、獣のルールと同じ社会なら、それは野蛮と言うのだ。

その意味で、駄菓子的なプリミティブなものが、確固として存在しつづけることにも意義はあろう。
* 無理矢理そこに話をつなげたって？　いやいや、きわめて論理的な展開だろ。
* 話をエロに戻すが（戻す？）、AV全盛の現代において、江戸の春画が見直されているというのは、プリミティブなものへの回帰も必要だという証拠かもしれない。
  
番外15- 半透明窓小史 - ウェブにおける半透過表現の変遷と絡んで

電車走行キットの歴史を語るページなのに、半透明窓についての記述を忘れていたので、追記する。
ウェブ上で最初に半透明という表現を可能にしたのは、事実上 Windows IE4（1997-）である。CSS filter 機能のひとつとして追加されたものだ。電車走行キットを始めた頃、自分が知っていた方法はこれだけ。しかし、Mac IEにはこの機能がなく、Macユーザーたる自分にとっては無縁な代物だったこともあり、当初は、半透明窓というものはなかった。
但し、濃色の窓の電車も増えつつあり、何らかの対応は必要だろうなぁ、とは感じていた。

発端は 2002年 3月。
手動運転 M01と M02に使えるオプションの「橋セット」を配布開始（後に橋画像を他のM系プログラム添付としてセットの配布は終了）したが、当サイト上の使用見本にて、JR九州 817系に、Windows IEのみ対応の半透明窓を試験的に実装した。
* その時の 817系画像は、左上フレーム走行見本 No.30 にて使用中。
 当時、一時的に存在した「仮サポート掲示板」で、この件が話題になり、2002年 5月に、配布版に半透明窓機能を実装すると予告。同年 12月に追加した A03に実装。しばらくは、他のプログラムには実装しなかった。理由は Windows IEに限定された機能だったことによる。

24bit-PNG 画像を使う、もうひとつの半透明窓が遅れた原因は、それについて知識不足だったからだ。
最初に知ったのは、前述の掲示板。2002年 5月、ぷぅさんから「PNG形式は、アルファブレンディングが可能」と教えていただいた。感謝。
* アルファブレンディングとは、アルファチャンネル（画像の透明度情報。これを持つ画像形式は半透明が可能）のある画像は、半透過部分に関して、背後の色とブレンドして表現可能ということ。
 これは A03配布開始前の話ではあるが、A03に間に合わなかったのは、そこから自分が、24bit-PNGというものを消化するのに時間がかかったため。当時、対応ブラウザは Netscape 6しかないと思っていたので、Netscape 6上でテストしたわけだが、このブラウザは自分の低速マシン上では重くて使いにくかったのだ。後に、自分が使っている Mac IE5が対応していると知ってから、一気にテストが楽になったことで、色々が進むことになった。
* 当時、CSS filter は、Windows IEにあって、Mac IEになし。24bit-PNG対応は、Mac IEにあって、Windows IEになし。同じ名前のブラウザなのに仕様が違いすぎた。
 結局、2003年 11月に、PNGの半透明窓を使える機能を A03に追加。
同時に、他のプログラムにも半透明窓を実装。これで、電車走行キットにおいて、半透明窓は標準装備となった。
* この時点では、Firefoxも、Google Chromeもまだ存在していない。24bit-PNG対応ブラウザは、Windowsでは、斜陽の Netscape 7のみ。もしかしたら Operaも対応していたかもしれないが、その辺はよく分からない。ということで、この 24bit-PNG対応というのは、Mac対応でもあった。Macでは、この年に登場した Safari を含めて全ブラウザが 24bit-PNG対応（しかも CSS filter非対応）だった。
* Windows において 24bit-PNG対応が効いてくるのは、2004年の Firefox誕生から。
──という二種類の画像を単純に使い分ける半透明窓仕様のまま時が流れた。
その間に、ウェブ上における半透明表現について、色々と変化があった。

2006年 11月、Windows IE7登場。これにより、IEにおいても、24bit-PNGの半透明表示が可能となった。
IE7については、少し前から仕様が判明していたので、これに先立ち、2006年 6月に A02SL-Expert に「IE7における半透過画像の扱いを IE6までと同じにするか、24bitアルファチャンネルブラウザとするか」を選択可能な機能をつけた。
* この選択機能は、IE10における CSS filter の廃止を受けて大変更を余儀なくされたバージョン（2014年 4月）で不要になったため廃止。
もうひとつ、半透明表現に関する展開があった。CSSによる opacity 指定である。
IEの CSS filter:Alpha() とは別の指定方法で、画像を半透明にできるのだ。これが、2008年頃までに IE以外のブラウザに実装された。IEも、2011年の IE9に至って実装。
* IEへの実装が遅れたことに批判があるようだが、「CSS指定による半透過」を最初に可能にしたのは、1997年の IE4であって、21世紀になってから参入した他ブラウザが異なる方法を採用しておいて「IEは遅れている」というのは筋違いだろう。そもそも、他のブラウザが CSS filter を実装すれば済んだ話なのだから。……先に実現した主流ブラウザの方法を、後から来た別のブラウザ側が結束してひっくり返す、という仕様争いは他にも色々あったが、ひっくり返す側は常に「W3C勧告準拠」という錦の御旗を立てている。まるで、幕末の幕府 v.s. 薩長のようだ。現実にはウェブの主導権をめぐる権力闘争なのに、権威を味方に付けた者が「正義」となって、既存の権力を「悪（朝敵）」として打倒する様は、まさに同じ。……結局、仕様がころころ変わることで、末端のユーザーは振り回されて迷惑。なのに「新しい仕様に従わないユーザーは悪」と言わんばかりの傲慢な正義面で、迷惑をかけている自覚なし。いや、正義のためなら迷惑をかけても構わないと思っているのか。いずれにしても、末端ユーザーなど塵芥のごとき扱いだ。
GIF（8-bit） GIF（8-bit）＋不透明度指定 PNG（24-bit）
指定なし
（半透明なし）		 CSS filter:Alpha()
（不透明度 35% 指定）		 CSS opacity
（不透明度 0.35 指定）		 Alfa-Channel
（不透明度 35% 画像）
Windows IE の対応 → IE4-IE9 (1997-2012) IE9- (2011-) IE7- (2006-)
他ブラウザの対応 → 無視 2008年頃迄には全て対応 21世紀に登場／全て対応

* ↑配布している 18.5m軽快気動車用の半透明窓を並べてみた。ブラウザが対応していないものは半透過表示はされない。使用のブラウザがどれに対応しているかは、この比較表を見れば一目瞭然。右の３枚がすべて半透明で表示されるのは、IE9 しかない。
【追記1・CSS filter : Alpha() の廃止】
IE10（2013年-）に至って、IE4から続いてきた CSS filter を使った半透明機能が廃止された。
* これについては、2014年 4月に、ゆめじさんに教えていただいた。感謝。
 これは電車走行キットの半透明窓設定の根幹を揺るがす大変更であり、すべてのプログラムを更新する必要に迫られた。
* IEと他のブラウザの仕様が統一されることは悪くはない。CSSも JavaScriptもその分だけシンプルになる。だが、長年提供されてきたIE独自機能の廃止となれば、それを使ってきたユーザーにとっては大迷惑だ。特に「半透明」というのは IEが先駆者であり、他ブラウザは後追いだ。後から来た方が主流になったからといって、なぜ先行した方法を捨てねばならぬのか。……たとえて言えば、千年の京都から東京に遷都して関東語が共通標準語になったとしても、京都の人は京言葉を捨てたりはしない。標準語と京言葉のバイリンガルになるだけだ。IE9はそういうブラウザだった。なのに、IE10は京言葉を捨てたのだ。ありえない話である。共通語を導入したら方言は不要なのか？　共通語に従うのが善で、方言を使いつづけようとするのは悪か？　過去互換を切り捨てる姿勢には、膓が煮えくり返る思いだ。
* 2015年に登場した Microsoft Edge は、IEで引きずってきた過去を切り捨てたブラウザだという。過去互換が必要なら IE11 を使えという話だが、そういう互換性を唱っていいのは IE9 までだろう。いや、IE9ですら、HTML+Time を捨てた（「鉄道側面画研究（走行手段篇）」参照）ことで、過去互換を語る資格はないと思う。Edge を登場させるのなら、何のために IE の過去互換性をこれほどまでに切り捨てたのか。筋が通らない。
【追記2・半透明窓画像の選択仕様の変更】
上記 IE10 の仕様変更で全プログラムの更新を余儀なくされたわけだが、これを機に半透明窓の仕様に変更を加えた。それまでは「WindowsIE では GIF＋CSS半透明指定、他ブラウザは 24bit-PNG使用」に固定されていたが、IE＋PNG、他ブラウザ＋CSS指定、という組み合わせも可能とした。

選択 Netscape4 MacIE WinIE -6 IE7 - IE9 IE10-, Safari, Firefox 等
0-標準（既存仕様） 無効 PNG CSS (filter) CSS (filter) PNG
1-CSS優先 CSS (opacity)
2-PNG優先 PNG PNG
- 絶滅ブラウザ 過去ブラウザ 現行ブラウザ

* こういう仕様が可能になったのはブラウザの進化と統一化の結果ではあるが、前述の理由で気分はすっきりしないのであった。
* 左上フレーム走行見本は、長らく「標準」（一部シーンは「PNG優先」）設定にしてあったが、2016年 10月を以て、「PNGオンリー」に変更。サーバー容量節約のため、２種類の半透明画像のうち、PNGだけを残してファイル数を半減。……結果的に IE6以前では半透明窓が表示できないという、配布版プログラムにもない割り切った仕様になってしまった。これは「過去互換の重視」という方針にやや反するが、サーバー残量が少なくなってきたので、やむをえない。IE6が終わって（＝IE7の登場＝2006年）から 10年を経て「そろそろいいかな」という判断もある。窓が表示されなくなっただけで、走らなくなったわけではないし。
<< 前頁へ戻る