実習室で使っている教材：Scratch Jr.
プログラミング実習室で使っていたり、要望があれば使えるようにしている教材のうち、Scratch Jr.について書いてみます。
※「子ども向けプログラミング環境にはどのようなものがあるか」、また「そのプログラミング環境がどのようなものであるか」については、既にネットに情報があふれていますので、あくまで身の周りでどのように使っているかを書いています。
目次
概要
Scratchはテキストブロックによってコーディングを行いますが、Scratch Jr.ではアイコンブロックを使用します。
Scratch Jr.には、条件分岐や変数がありません。
しかし、Scratchと同様に（イベントドリブンで言うところの）メッセージの概念を実装しており、複数のキャラクターを順序よく、あるいは同期して動かすこと、例えば、電子紙芝居で2人のキャラクターが交互に話をするようなプログラムが子どもでも作りやすくなっています。
Scratchキャットも、Scratchと違ってとてもかわいいです（重要）。
関連図書はScratchと違ってあまり出ていませんが、『5才からはじめるすくすくプログラミング』（日経BP社）は、5才児にも読んでもらえるように本文がすべてひらがなで書かれています。*1
状況
実習室は、当初はScratchの一本足打法で始めましたが、想定していなかった小学校1・2年の参加があったため、たまたま通販でセール中だった8インチタブレット*2を調達しました。
7インチ程度の、いわゆる中華タブを持ってきた小学1年生もいました。子どもの指でも7インチでは画面が小さすぎるのと、タブレットが使い込まれていたせいかタッチパネルの感度が落ちていたようで、時々苦戦していました。
最初はコーディングというよりは、ブロックを適当に繋げて遊んでいました。ブロックが繋がるときの感触が心地よいみたいです。
繋げたブロック（＝コード）を実行できることを教えると、ブロックの並べ方によってキャラクターが動きを変えることに気づきました。実行中に、実行部分のブロックがハイライト表示されるためです。
これで、ブロックを繋ぎ変えてからプログラムを実行し始めました。
さらに、ペイントエディタの存在に気づくと、熱心に絵を描きはじめました。そのうち「これ、動かせるのかな……？」と気になり、自分で描いた絵を自分で書いたプログラムで動かすようになりました。
手元のタブレットが1台しかないので、数だけはある中古デスクトップパソコン（Ubuntuインストール済）でScratch Jr.を動かせるようにならないか、いろいろ試してみました。
なにしろ古いデスクトップで、エミュレータではまともに動くことが期待できなかったので、ベアメタルで動作するAndroid-x86やCloudReadyなどの環境を試しました。
しかし、レアな環境のせいかGooglePlayまでたどりつけなかったり、Scratch Jr.の起動までこぎつけたもののタッチ位置がずれていたりなどして、結局は使うことができませんでした。*3
今のところ、小学校2年生以下の児童が初参加をする際には、なるべくタブレットを持参してほしい、とお願いしており、タブレットが足りなくて困るといったことは起きていません。
サンプルコード
「Scratch Jr.では紙芝居しか作れないの？」と思われるかもしれませんが、工夫次第でゲームを作ることもできます。
例えば、サッカーゲームを作ってみましょう。
上のとおりにサッカーボールとサッカーのゴールを配置します。
サッカーボールには、上のとおりスクリプトを組みます。
「タッチされたら、10歩右へ進み、最初の場所に戻る」という内容です。
ゴールには、上のとおりスクリプトを組みます。
「旗が押されたら、ひたすら上下移動を繰り返す」という内容と、「他のキャラクターと当たったら、『ゴール！』といい、少し小さくなる」という内容です。
スクリプトが完成したら、旗アイコンを押して実行します。
動くゴールのタイミングを狙いながら、サッカーボールをタップすると、サッカーボールが飛んでいきます。
最初のうちはゴールが大きいので、外すのが難しいくらいですが……。
ゴールするたびにゴールが小さくなり、だんだん難しくなります。
変数こそありませんが、メッセージを使うなどしてキャラクターやステージを切り替えていけば、それなりのゲーム性を持ったものになるのではないでしょうか。
MSX-BASICでビジュアルプログラミング環境を作ってみた
マウスで命令ブロックをドラッグ＆ドロップすることによりコーディングできるビジュアルプログラミング環境*1を、MSX-BASICで作ってみました。
名付けて、MSX用ビジュアルプログラミング開発環境『MSX T-LEX』*2です。
MSXが、令和のプログラミング教育の最前線で戦えるかもしれない可能性。
いわゆるベーパウェアです。
目次
できること
動画
バージョン2
- 強化ポイント1：256色カラーに対応
- 強化ポイント2：描画精度の向上
- 強化ポイント3：日本語プログラミングとMSX BASICの命令に対応
- 強化ポイント4：条件分岐（IF文）に対応
画面解説
- ブロックエリア ブロック(命令)が格納されています。
- パレット切替 クリックすることで、表示するブロックを、英語系・日本語系・MSX命令系に切り替えることができます。
- コードエリア コーディングを行います。
- ブロックエリアのブロックをドラッグし、コードエリアにドロップすることでコーディングを行います。
- 行間にドロップすると挿入されます。
- ブロック構文（IF,REPEATなど）の間にドロップすると、ブロック構文内に挿入されます。
- 左ドラッグ すでに設置したブロックを移動します。ブロック構文の先頭をドラッグすると、ブロック構文が丸ごと移動します。
- 右クリック ブロックを削除します。ブロック構文の先頭を右クリックすると、ブロック構文が丸ごと削除されます。
- ブロックエリアのブロックをドラッグし、コードエリアにドロップすることでコーディングを行います。
- ヒントエリア ドラッグ中のブロックの機能が表示されます。
- 機能エリア クリックするか、ファンクションキーを押すことで、機能が実行されます。
- EXIT T-LEXを終了します。
- LOAD 保存済みのソースファイルを読み込みます。
- SAVE 編集中のコードエリアの内容を、名前を付けて保存します。
- OVERWRITE 編集中のコードエリアの内容を、現在のファイル名で上書きします。
- RUN 編集中のコードエリアの内容を実行するため、コンパイルを開始します。
とりあえず試してみる
以下のURLをクリックすると、WebMSXで起動します。*3
https://webmsx.org/?MACHINE=MSXTRJ&DISKA_URL=https://github.com/matsun-ri/msx-t-lex/raw/main/disk-image/T-LEX.dsk&MOUSE_MODE=1&BASIC_RUN=lex.bas
.BASファイルをアスキーセーブしているので、本来より読み込みにかなり時間が掛かります。
子ども向けプログラミングワークショップでScratchを選択する理由
何年か前から、ど田舎の図書館で子ども向けプログラミングのワークショップを開催しています。
子どもたちの最初の一歩として、どんな教材を使うか検討した結果、Scratchを選ぶことにしました。
その理由を挙げてみます。
目次
- マウスだけでほとんどの操作が可能（なんならタッチパネルでも）
- 命令語が日本語であること
- 文法エラーの排除
- 子ども向けのテキストが豊富
- 高い知名度
- 実はストイックなプログラミング言語である
- 「Scratchはテキストプログラミングじゃないからいやだ」という反論
- 「Scratchは素晴らしいノーコード環境だ」という誤解
- 結論
マウスだけでほとんどの操作が可能（なんならタッチパネルでも）
Scratchがブロックプログラミングであることに由来する利点ですが、パソコンが初めての子どもでも、マウス操作ならすぐに慣れることができます。
一方、多くのプログラミング開発環境で必須となるキーボードは、習熟している子と不慣れな子の差が激しく、不慣れな子どもを待っている間に習熟している子どもの集中力が途切れてしまいます。
プログラミングのワークショップを検討しはじめた時期に言われていたのは、2013年の調査によると小学生の打鍵平均速度は5.9文字/分しかないということです。これは平均ですから、習熟している子どもはそれなりに速いでしょうし、そうでない子どもはずっと遅いということになります。これでは、写経すら終わる前にイベント時間が終了してしまいます。
また、アルファベット（特に小文字）は小学生には分からない、というのが図書館での経験則です。そもそも、キーボードには大文字しか刻印されていません。
「キーボードやアルファベットなど、興味のある子どもならすぐに覚える」という反論もありましょうが、単発あるいは月1回程度のワークショップでは、覚えるのを待っている暇はありません。逆に言えば、例えば学童保育などで毎日のようにキーボードに触れる機会を持てるのなら、何でもありです。
今回の記事では扱いませんが、IchigoJam BASICは大文字でコーディングしますし、命令が短いので、子ども向けワークショップに向いていると思います。
命令語が日本語であること
Scratchそのものは海外のマサチューセッツ工科大学生まれではありますが、日本語化がほんとうに丁寧になされています。
これもScratchがブロックプログラミングであることに由来する利点ですが、他のブロックプログラミング環境では、必須の命令群が日本語化されていなかったり、フォントが微妙（読めない）だったり、ブロックに対して文字がズレているなどは当たり前のような状況です。*1
また、Scratchで日本語でコードを書き終わってから、表示言語を切り替えるだけで自分が書いたコードが外国語で表示されるのは、子どもたちにとって興味深いでしょう。*2
文法エラーの排除
これもまた、Scratchがブロックプログラミングであることに由来する利点です。
テキストプログラミング言語では、タイプミスによる文法エラーが起こりやすいのですが、Scratchでは命令語はブロックなので、単純なスペルミスが排除できます。
また、条件分岐の「もし」(if)や、ループの「〇回繰り返す」(for)なども、コードブロックの始まりと終わりが視覚的に囲まれますので、コードブロックの閉じ間違いによる文法エラーが排除できます。
これらは、テキストプログラミング環境で言えば、コード補完などの入力支援機能が有効に働いている状態に当たります。
初心者のうちは、ロジックエラーと文法エラーの区別がつきません。排除できるエラーは排除しておくことで、途中で投げ出す可能性を排除することにつながるでしょう。
子ども向けのテキストが豊富
自宅でプログラミングを継続する際にも、関連書籍など情報の入手が容易です。
むしろ、Scratchに関して言えば、本が多すぎて選択に迷いかねない状況ではあります。しかし、選択肢が多いことは、一般的には好ましいことです。
高い知名度
こんなど田舎でプログラミングワークショップに参加するようなアーリーアダプターは、すでにNHKの番組などでScratchの存在を知っていることが期待できます。
実際、開催後には、複数の保護者の方から「もともと、NHKのプログラミングの番組を観てて興味を持っていた」と伺いました。
実はストイックなプログラミング言語である
一般的なテキストプログラミング言語とScratchとの差は、命令語をキーボードで打ち込むか、マウス操作でブロックをドラッグ＆ドロップするか、という手間の違いだけです。
命令を組み合わせてロジックを構築するという部分は共通しているので、他の言語を覚える必要が生じた際にも、有利であることが期待できます。
以上の点から、受講者に希望がある場合は別として、「プログラミングを始めたいけど、何からすればいいか分からない」と言われたら、Scratchを勧めるのは充分に合理的でしょう。
とはいえ、これには反論も存在します。
「Scratchはテキストプログラミングじゃないからいやだ」という反論
「子どもにはScratchよりもテキストプログラミングに触れさせるべきだ」という意見を、時折耳にします。
例えば、次のような意見です。
- 「Scratchに慣れた結果、テキストプログラミングへの移行を面倒がってプログラミングをやめてしまった子どもを何人も見てきた。だから、最初からテキストプログラミングをするべきだ」
- 「Scratchでは、例えばデータベースの操作などの本格的で実用的なシステム構築はできない。だから、最初からテキストプログラミングをするべきだ」
- 「なんか思ってるのと違う。自分が好きなのは、真っ黒な画面にプログラムを苦労して打ち込んで、アスタリスクを左から右に移動させたりするのに成功した、あのワクワク感だ」
そもそも論として、子どもにプログラミングに触れてもらう目的を「子どもにプログラマーになってほしい」という明確だが狭い範囲に置くのか、それとも「子どもに、これからの社会を生きるための基礎知識のひとつをつけてほしい」という曖昧だが広い範囲に置くのか、そこを明確にしないと、捉え方が変わります。
1.の意見は、昔から初心者向けのプログラミング教本を多く出しているある著者が強く主張していました。
この手の話はたまに耳にするのですが、Scratchからの移行でプログラミングをやめてしまう子どもが、なぜ最初からテキストプログラミングだと継続できると思えるのかについて、納得いく解説を聞いたことがありません。
子どもにとっては、自分がやってみたいことと移行先のプログラミング言語でできることが乖離していたとか、移行先にScratch程の魅力を感じなかったからとか、そのような事情があったのでしょう。
その齟齬を埋められない責は、育成する側が負うものです。
2.の意見については、そもそもプログラミング言語には向き不向きがあるので、万能なプログラミング言語などありません*3。本格的にプログラミングを始めると、いくつかの言語を使い分ける必要が出てくるものです。それはScratchなどのビジュアルプログラミングでも、テキストプログラミングでも、変わりません。
3.の意見は、半分冗談で書きましたが、1.や2.だと主張するからよく聞いてみたら、実は3.みたいなことを言っていた、ということもあるようです。だったら最初からそう言ってくれ、って話ですが。
余談ですが、昔は、Scratchのスプライトのような画像を高速に動かすのはとても大変か、もしくはそもそも不可能でした。
今のようなネットなどない中、パソコン付属のマニュアルと月1回しか発行されない専門誌という限られた情報源を手垢まみれにして、やっとBASICを一通り覚えても、画像を思い通りに動かすなんて到底無理だとわかり、当時の子どもは、泣きながら機械語の使い方を覚えたものです。
Scratchであればそれが簡単にできてしまうのですから、やっかむのも無理はありません。*4
そういう人には、今ではSmileBASICみたいに大容量で高速な優れたBASIC開発環境がありますので、ぜひ触れてもらえればと思います。
それに、今の子どものほうが、画像処理まわりなんかは覚えることが多すぎて大変だと思います。昔は大したことはできなかったので、覚えることも少なかったわけですし。
子どもに強制しないのであれば、個人的な好き嫌いの話でしかないので、好きにすればいいのではないでしょうか。そういうのが好きな小学生は、たまにいます。
ただ、30年前のパソコン少年の知識だけでScratchに挑むと、メッセージやマルチスレッドあたりで初っ端からつまづくことになるので、あまりバカにしないほうがいいと思います。*5
「Scratchは素晴らしいノーコード環境だ」という誤解
ちょっと前から、一部のノーコーダーによる「Scratchはノーコードの一種だ」みたいな主張を時々目にします（そう主張している人が、本当にScratchを使い込んでいるのかは疑わしいのですが）。
Scratchで書くのはコードなんですけどね。ほら。*6
話がややこしくなる原因として「ノーコードには明確な定義が存在していない」ということがノーコーダーのコンセンサスとなっている点にあるかと思います。つまり、ノーコーダーが「ノーコードだ」と主張すれば、それは名誉ノーコードになってしまうのです。
Scratchは、自分の判断でブロックをコードエリアにドロップし、コーディングすることでロジックを構築しないと何も作れないわけですが、するとブロックプログラミングでブロックをドロップすることとエディタのコード補完機能でコードを入力することやマウスやタッチパネルなどのポインティングデバイスで仮想キーボードを使い、テキストプログラミング行うことの本質的な違いが問題になってきます。
また、Scratchは小学校低学年でも遊べる優れたUIを持っていますが、見た目よりもストイックで、ロジックの構築（＝コーディング）を手伝ってくれるものではありません。もしScratchがノーコードの仲間だとしたら、「ノーコードでシステムを構築するには、Scratchに匹敵する大変な修練とコーディングが必要だ」と暴露していることになるわけです。もし今のノーコードがその程度のものであるならば、これほど残念なことはありません。*7
Scratch勢はお上品なので、誰もはっきりと書かないのですが、単純な話、子どもたちにコーディングに親しんでもらおうと思ってマサチューセッツ工科大学が何十年もかけて作り上げた結晶であるScratchに対して、「コーディングなんか覚える必要ないぞ」と言わんばかりの名前で呼ばれたら、関係者は大激怒でしょう。思想を無視して、存在意義を否定されているのですから。
以上に挙げた反論にしても、誤解にしても、コーディングを楽しんでいる子ども達の耳に「君たちがやっているのは、本当のコーディングじゃないんだよ」と吹き込むような行為であって、個人的には大人がするような行為ではないと思いますが、人の口には戸が立てられません。
育成側としては、それを目にした子どもたちが混乱しないよう、説明できる術を身につけておくべきでしょう。*8
結論
子どもが興味あるものに触れるのが一番。
今回はScratchについて書きましたが、プログラミングのワークショップでは、Scratch以外にも、様々な教材を手配しています。
詳しくは、また後日に書こうと思います。
*1:MakeCode系のブロックプログラミングや、EV3 Classroomなど。
*2:逆に、外国語で書かれたコードがそのまま日本語で読めてしまう点は、指摘しないと気付いてもらえません。
*3:そんなものがあったのなら、バベルの塔の前の世界のように、言語はただ一つで統一されていたでしょう。
*4:僕もいまだにMSX BASICを触りますし、暇になったら30年前にやってたZ80のアセンブラを再開したいと思っているクチです。
*5:プログラミング経験のある大人ほど、Scratchで「旗が押されたとき」ブロックが複数置ける点につまづきます。
*6:しかも、以前[スクリプト]エリアと呼んでいた場所は、Scratch3.0から[コード]エリアに変わっています。
*7:ノーコードそのものは必要ですし、これからも進化し続けると思っています。また、ノーコードでのシステム構築の際に、Scratchでのコーディング経験は（他のプログラミング言語と全く同様に）役に立つと考えられます。 ここで問題としているのは、一部のノーコーダーによる「Scratch＝ノーコード」という決めつけです。
*8:私見ですが、「Scratchはテキストプログラミングじゃないからいやだ」と「Scratchは素晴らしいノーコードだ」は、昔あった「宇宙の真理がこんなに単純なわけがない。だからきっと相対性理論は間違っている」と「宇宙の真理がこんなに難解なわけがない。だからきっと相対性理論は間違っている」に近いような関係にあるんじゃないかと思っています。
遊星歯車機構とTHSのしくみ
『いずれはカローラにもハイブリッドシステムを載せたい』
と発言したのを聞いて
『安くてよく動くのが取り柄のカローラにハイブリッドシステムなんか積んだら、高くて動きが微妙な車になっちゃうじゃないのか……』
と思ったものですが、今では大抵のトヨタ車にハイブリッド仕様が存在しています。
というわけで、トヨタ車に積んでいるハイブリッドシステム、その名も『THS』について書いてみます。
追記
遊星歯車機構の動作をアニメーションにしてみました。
(1)～(6)のラベルをクリックすると、アニメーションを再生します。
https://scratch.mit.edu/projects/524873959
（注意事項）
- 音が出ます。
- 自分なりに調べた結果をアニメーション化したものです。
- シミュレータではありません。歯車が動く順番や歯車比とか適当です。
- 発電機の電気がバッテリーを経由せずに直接モーターへ行く場合などの、重要な部分を省略しています。
目次
免責事項
自分なりに調べたことを書いていますが、間違っている点があれば資料とともにご指摘いただければ幸いです。
ハイブリッドシステムの種類
一口にハイブリッドカーと言っても、異なる動力をどう組み合わせるかは様々です。
メジャーなハイブリッドシステムの形式には、パラレル方式とシリーズ方式があります。
パラレル方式
エンジンとモーターが直結されており、エンジンの出力不足をモーターで補う方式です。
一般的な車に最小限の変更を加えるだけで実装できるというメリットがあります。
シリーズ方式
エンジンは発電に徹し、それで得た電力でモーターを回す方式です。
遠回りな方法に見えますが、エンジンを最も効率のいい回転数で定速運転させることにより、燃費を抑えることができるというメリットがあります。
例えば、日産ノートe-POWERやJR西日本の豪華寝台列車『瑞風』が採用しています。
ノートe-POWERは登場時に
『電気自動車の、まったく新しいカタチ』
と宣伝されていましたが、実はシリーズハイブリッドは古くから大型艦船や潜水艦に使われている、枯れた（=完成度の高い）システムでもあります。
大型艦船では、 通常ではエンジン→軸→スクリューを一直線に配置しなければならないため、船内のレイアウトに厳しい制限が付きまといます。
モーターと発電機を加え、その間は電線を使うことで船内のレイアウトの自由度が増すこと、古い蒸気タービンだと出力の微調整が利きませんが、電気なら細やかな制御がしやすいことがメリットです。
潜水艦は、潜航中はディーゼルエンジンを使えない（空気がない）ため、電池でモーターを動かします。電池が切れるまでに浮上してディーゼルエンジンを使って充電しないと、動けなくなってしまいます。これはメリット・デメリットの問題ではなく、潜水艦が生まれてから今日に至るまでの宿命です。この軛から逃れることができるのは、稼働に空気を必要としない原子力潜水艦だけです。
スプリット方式
今回取り上げるTHSは、パラレル方式とシリーズ方式の良い所取りであるだけでなく、変速機の代わりまでこなしてしまいます。
名称は『スプリット方式』のほか、『シリーズパラレル方式』とも、モーターの役割が単なる補助ではなく、モーター単独でも走行可能なため『ストロングハイブリッド方式』とも呼ばれます。
THSにおける遊星歯車機構の挙動
普通の車のおさらい
どういうことかを説明するために、まず普通の車のギアについておさらいします。
普通の車のギアには、入出力が2つあり、それぞれエンジン、タイヤに繋がっています。
エンジンが動くと、その回転がタイヤに伝わり、車が前進します。
エンジンブレーキを掛けている状態では、タイヤの回転がエンジンに伝わります。
エンジンを回すのは重いので、それが抵抗になり、エンジンブレーキとなります。
遊星歯車機構のしくみ
プリウスのTHSに使われている遊星歯車機構は、3つの入出力を持っています。
それぞれ、
- タイヤ＋モーター（外側の青色が軸）
- 発電機（内側の紫色が軸）
- エンジン（中間の茶色が軸）
に繋がっています。
この部分をズームしてみましょう。
※面倒くさい方は、次の図までスキップすることをお勧めします。
遊星歯車機構の構造は、太陽系になぞらえられます。
- 太陽の位置にあるサンギア
- サンギアの周りを惑星のように取り囲むピニオンギア*1
- 惑星の軌道に沿って存在するプラネタリーキャリア
- 太陽系外縁部を囲むリングギア
このうち、2.のピニオンギアは、自分自身も回転しますが、プラネタリーキャリアも動かします。
太陽系になぞらえると、
- 惑星の自転→ピニオンギアの回転
- 惑星の公転→ピニオンギアの公転＝プラネタリーキャリアの回転
となります。
参考までに、各ギアを固定した場合、他のギアがどのように回転するかを表にしてみました。
- サンギアを固定すると、プラネタリーキャリアとリングギアは同じ方向に回転する
- プラネタリーキャリアを固定すると、サンギアとリングギアは互いに反対方向に回転する
- リングギアを固定すると、サンギアとプラネタリーキャリアは同じ方向に回転する
モーターのみで走行
難しい御託はこの辺までにして、まずは停止状態の車のアクセルをじわっと踏んでみます。
モーターで走行する状態では、電池の電力で(1)モーターを動かすことで、(2)タイヤを回転させ、車を前進させます。
なお、このとき、(3)ピニオンギアを経由して(4)発電機まで回転が届きますが、この時、発電機には負荷がかかっていない（発電しようとしない）ので、大したロスもなく空転するだけです。
モーター走行中にエンジンを始動
では、アクセルを踏み込んでみましょう。
(1)発電機がセルモーターとなり、(4)エンジンを回すことで、エンジンを始動します。
タイヤとモーターはグレーで描いていますが、暖機運転等の例外を除いて、走行中の多くの場合は、タイヤとモーターも動いています。
モーター＆エンジンで走行
モーターとエンジンの両方で走行する状態です。
発電機をロックすることで、(1)エンジンの動力が(4)モーターの動力と合算されて(5)タイヤに伝わります。
ところで、エンジンとモーターとでは得意分野が異なります。
エンジンは、一定の範囲の回転数で最も性能を発揮できます。言い換えると、それ以外の回転数――おもに発進時の低速域では燃費が悪くなります。
モーターは、回転し始めたその瞬間から最大のトルクを得られます。
そこで、低速域でもあえて(1)エンジンを燃費のいい回転数で動かし、その動力の一部を(3)発電機に分け与えて(5)充電を行います。
こうすることにより、通常の車では燃費が悪くなる速度域でも、電力を溜めることができます。
さらに、発電機で得た電力を(4)そのままモーターに与えて走行の手助けを行う場合もあります。
エンジン→発電機→モーター→タイヤ、という動力の伝達は、感覚的にはとても非効率に思えますが、実はこうすることで変速機を省くことができるのです。
言い換えると、通常の車ではたくさんの歯車の組み合わせで実現している変速を、エンジンと発電機とモーターの絶妙な協調によって、よりシンプルに実現しています。
『プリウスといえばTHS、THSといえば遊星歯車機構』
のように言われることがありますが、このような面倒くさい制御を20世紀のうちに量産車で実現してたのって、今思えば『21世紀に間に合いました』の売り文句は決して伊達じゃなかったんですね。
参考：日経トレンディネット『ハイブリッド車はなぜ燃費がいい？ モーターの役割は何？』
http://trendy.nikkeibp.co.jp/article/special/20090414/1025428/?P=9 ※リンク切れ
回生ブレーキ
では、アクセルを離し、ブレーキを踏みます。
ブレーキを掛ける際は、(1)タイヤの回転が(2)モーターに伝わります。
通常の車でいうエンジンブレーキと同じ状態ですが、スピードがモーターで電力に変換され、電池に蓄えられます。これを回生ブレーキと呼びます。
（この状態だとサンギアが回っているはずなのですが、サンギアにつながっている発電機が発電しているのか、単に空転しているのかがわかりません。どこかで「回生ブレーキにはモーターと発電機の両方を使用している」と読んだ気がしたのですが、ソースを見つけることができませんでした）
普通の車のブレーキは、ディスクブレーキをブレーキパッドで挟むことによる摩擦で作用します。スピードは摩擦熱となって消えてゆきます。
THSでは、フットブレーキを踏んだ際に要求されるブレーキ力を、回生ブレーキとディスクブレーキにうまく配分することで、できるだけ効率的に充電を行います。
このため、プリウスは普通の車よりブレーキパッドの摩耗が少ないとの話もあります。
なお、最近の電車は、回生ブレーキだけでほぼ停止ギリギリまでスピードを落とすことができるそうです。
凄いなと思っていたら、最近のTHSも、回生ブレーキだけでほぼ停止ギリギリまでスピードを落とすことができるそうです。
バック
バックは(1)モーターを逆回転することで行います。
エンジンは進行方向にしか回転しないので、エンジンではバックができません。
例によって発電機が空回りしますが、ロスにはなりません。
ところが、電池が少ない場合や急な登り坂へのバックなどでパワーを必要とする場合に、バック中でもエンジンが掛かる場合があります。
これは、バックするために足りない分の電力を、その場でエンジンを使って発電するからです。
エンジンを回すと前へ進む力が生まれますが、これを発電機とモーターでうまく帳消しにするよう制御しています。
ところで、アイドリングストップは燃費を稼ぐための大原則です。*2
しかし、暖機運転中や、あまりに電池が足りず燃費が悪くなりそうになると、停車中でも(1)エンジンによって(4)発電機を回し、充電を行います。
プリウスPHV(52型・2017年モデル)のEV走行
最後に、現行プリウスPHV（52型）のEVモードについてです。
プリウスの出力は、4代目（50系・いわゆる般若）の場合
- エンジン：98ps(72kW)
- モーター：72ps(53kW)
です。
足し算すると170ps(125kW)になりますが、実際の出力は122ps(90kW)にしかならず、通常のネット値とグロス値の差以上の開きがあります。
エンジンと発電機とモーターを協調させてギアチェンジの代わりを行う仕組み上、エンジンとモーターの両方が最高出力の状態で動力を加算することができないためです。
通常のプリウスであれば、モーターで足りなければエンジンを動せばいいだけですが、プリウスPHVでは事情が変わってきます。
PHVの場合、電池が充分にある限りはEVとしてふるまい、モーターだけでも走行できなければならないため、72ps(53kW)のモーターだけでは少し力不足です。
発電機は出力31ps(23kW)のモーターでもありますが、発電機をモーターとして利用した場合、エンジンが空転するだけで動力がタイヤまで伝わりません。
そこで、プリウスPHV（52型）では、エンジンとプラネタリーギアの間にワンウェイクラッチを追加し、特定方向への回転がエンジンに伝わらないようにしました。
これにより、EVモードでは発電機をモーターとして動力に利用できるようになりました。
旧プリウスPHV（35型）のEVモードでは最高速度が100km/hまででしたが、新プリウスPHVでは2つのモーターの力で、EVモードでも最高速度135km/hで走ることができます。
参考：日経ビジネスオンライン『次期「プリウスPHV」、走行性能が一気に向上』
http://trendy.nikkeibp.co.jp/article/special/20090414/1025428/?P=9
大容量の蓄電池を搭載するEVと比較して、電池容量8.8kWhしかないプリウスPHVでの高速走行は割といい勢いで電池が減ってしまいます。
本来、PHVで長距離の高速走行をしたければ、何も考えずにエンジンを回してハイブリッドカーとして走ればいいだけの話ですし、それが可能なのが、PHVのEVに対するメリットです。
それを、わざわざワンウェイクラッチの追加という仕様変更をしてまでEVモードでの高速走行の実現に拘ったのは、開発陣が『EV走行の楽しさ』をPHVユーザーに体感して欲しかったからではないのでしょうか。
乱暴な言い方をすれば、
『プリウスPHV1台で、ハイブリッドカーとEVの2台分の走行が楽しめます』
と言えるような、EVの走行フィーリングとハイブリッドカーの実用性の両方を兼ね備えるマシンを目標にし、本当に作ってしまったのだと思っています。
*1:ピニオンギアをプラネタリーギアと書いている資料もあります。遊星歯車機構を太陽系に見立てる場合、このギアが惑星に相当するので、プラネタリーギアと呼ぶほうが理解しやすいのですが、遊星歯車機構全体を差す“planetary gear mechanism”とごっちゃになるので、あえてピニオンギアで通すことにします。
*2:2021年現在、アイドリングストップはそこまで燃費や環境負荷に関与しないという話が出てきています。
MSXturboR（新CPU:USO800搭載）
Sorry, this article is written as a joke:)
MSXturboR（エム・エス・エックス・ターボアール）は、パソコンの国際規格であるMSXの一つ。
目次
- 概要
- FS-A1GT
- FS-A1STとFS-A1BT
- FS-A1ST
- FS-A1BT
- バージョンアップアダプタ
- オンラインサービス
- 追記
- 追記(2021年)
概要
1990年に規格が策定されたMSXturboRは、新開発のZ80バイナリ互換高速CPU「R800」と従来のグラフィックチップV9958を劇的に高速化（およそ20倍）させた新VDP「V9909」を組み合わせることにより、既存のMSX用ソフトウェアを1バイトも書き換えることなく高速に動作させることを可能とした。
FS-A1GT
1990年10月には、松下電器産業（現パナソニック）より、最初のMSXturboR規格マシンとなる「FS-A1GT」（以下、A1GTと省略する）が発売された。定価は89,800円(消費税を含まない額)であった。
A1GTの「GT」は「GUI Turbo」の略とされている。メインメモリを512kB搭載したほか、GUIソフトウェア「MSXView」をROMに搭載し、MSXViewの操作に必要なマウスを標準装備とした。
32ビットパソコン市場においてもGUIが珍しい存在だった当時としては、本体を購入するだけでGUIとマウスオペレーション環境が手に入ることは非常に画期的なことであった。
MSXViewは、HAL研究所が1987年にMSX2向けに開発したGUI「HALNOTE」をMSXturboR向けに転用したものであった（従来のHALNOTE用のアプリケーションもMSXViewでも動作させることができた）。
MSXturboRの「従来のMSX用ソフトウェアをコードを書き換えることなく高速に動作可能」という利点を生かし、HALNOTEのMSXViewへのバージョンアップはMSX-DOS2への対応など最小限のカスタマイズで済んだため、MSXturboRの販売価格を抑えたままMSXViewの標準添付を可能とした。
処理速度的に非力なMSX2上ではとても実用に堪えなかったHALNOTEであったが、MSXViewとしてMSXturboR上で動作することによって、ようやく本来の実力が発揮されたといえる。
MSXViewはROMで供給されたため、同じくROMで供給されたワープロソフトや日本語入力システムとともに、軽快な操作環境の実現に寄与した。
当時は、一般的なビジネス用途向け32ビットパソコン（NECのPC-9800シリーズなど）の市場においてもハードディスクドライブがほとんど普及しておらず、ワープロソフトや日本語変換システムがフロッピーディスクで運用されていたため、MSXturboRの操作応答性がビジネス用途パソコンのそれを上回るという逆転現象が発生した。
MSXView用のソフトウェアとして、表計算ソフト『ViewCALC』、ドローソフト『ViewDRAW』などがMSXturboRと同時に発売された。また、MSXturboRに内蔵されたワープロソフトについても、これらのMSXView用ソフトと連携させるための改良が加えられた。
いずれのソフトウェアもGUIによるマウス操作が可能であった。
MSXViewおよびそのアプリケーションに対して、既存のMSXユーザーの目は冷ややかであり（彼らがMSXを所有する目的は、ホビープログラミングか、そうでなければパソコンゲームのプラットフォームとしてであった）、彼らはMSXturboRを単に速度が速くなっただけのMSXとしか捉えなかった（もちろん、ホビープログラマは処理速度の高速化の恩恵に与れたし、それまでのMSXのスペックでは移植が不可能であった他機種向けゲームがMSXturboRに移植される事により、MSXをゲーム機として利用する層もその恩恵を享受することができた）。
しかし、実用ソフトが快適に動作し、しかもマウスによるGUI操作が可能となったMSXturboRは、『速い・安い・うまい』を合言葉に松下とアスキーが行なったキャンペーンにビジネス誌が乗りかかる形となり、一大センセーションを巻き起こした。
MSXのFDDで採用されていたMSX-DOSフォーマットが、もともとビジネス用途パソコンで使われていたMS-DOSフォーマットと互換性があったことに加え、ビジネス用途パソコンのFDDが5インチから3.5インチに移行しはじめていたことも、元々3.5インチFDDを採用していたMSXに味方した（ビジネス用途パソコンでは2HDディスクが使用されていたが、MSXでフォーマットした2DDディスクの読み書きが可能であったため、コンバータソフトなどを用いずとも相互にファイルの交換が可能であった）。
当時、一般的なビジネス用途パソコンと必要なソフトウェア（ワープロソフトなど）一式を揃えようとすると、フロッピー運用であっても一般的なサラリーマンの月収の2倍程度の投資を必要としたため、個人でビジネス用途パソコンを購入することには様々な制約があった。
ところが、MSXturboRで同じ環境を揃えた場合、ビジネス用途パソコン一式の1/3程度の投資で収まったため、MSXturboRは従来のMSXユーザーの大多数を占めたホビーユーザーだけでなく、それまでパソコンの購入をためらっていたビジネスマンや中小・零細企業へ一気に広まった。
このため、それまでMSXを『おもちゃ』などと呼称して見下していたビジネス用途パソコンユーザーが、会社ではビジネス用途にMSXを使い、自宅ではビジネス用途パソコンをホビー用途に使うという逆転現象が発生し、そのようなユーザーが悔し紛れにMSXturboRを『プアマンズMac』と呼ぶことがしばしば見られた。
A1GTはホビーユーザーに限っても10万台程度販売され、縮小傾向にあったMSX市場において久々のヒット作となった。なお、同時期にX68000シリーズの累計販売台数が10万台を突破している。
FS-A1STとFS-A1BT
A1GTの成功に気をよくした松下は、1991年10月に新機種「FS-A1ST」「FS-A1BT」の2機種を同時リリースした。
FS-A1ST
FS-A1STの「ST」は「Standard Turbo」の略とされている。
A1GTからMSXViewを含む添付アプリケーションおよびA1GTでは標準添付であったマウスを省略したものであり、ホビーユーザーをターゲットとした廉価版MSXturboRの位置づけであった（内蔵メモリなどハードウェア上のスペックに差異はない）。定価は74,800円(消費税抜き)であった。
FS-A1BT
FS-A1BTの「BT」は「Business use Turbo」の略とされている。
メインメモリが1MBに増加し、2DDフロッピーディスク対応FDDを2台搭載（A1GT・A1STにも基板上に未使用のFDD接続用パターンが存在し、それを利用してFDDを増設するユーザーもいた）で発売された。MSX史上初のメガバイト単位メモリ搭載機種となったほか、RS-232C端子、MIDI端子、アナログRGB15ピン端子を標準装備した。
RS-232C端子を搭載したことでモデムを接続可能となり、パソコン通信のほか、株式投資、馬券のオンライン購入、オフィスのFAX自動送信ソフトなどに利用された。
アナログRGB15ピン端子にはアップコンバートされたビデオ信号が出力（インタレースモードにおいては424ライン）されており、当時一般的だったPC-9801用モニタを接続することで、クリアな画面表示を実現した。
定価は128,000円であり、MSXとしては久々の10万円を超えた機種となった。なお、当時EPSONから発売されていたPC-9801シリーズ互換機「PC-286C」の定価が168,000円であった。
オンラインサービス
1992年には既存のMSX向けオンラインサービス「THE LINKS」の上位版として、MSXturboR専用のオンラインサービス「Turbo Links」が開始された。
サービスの利用には、モデムの他に専用の通信ソフトが必要とされたが、グラフィカルな画面でオンラインサービスの利用が可能であった。
ユーザーは Turbo Links 上で自分の分身となるキャラクターを操作し、電子掲示板の読み書きやチャットのほか、コナミの協賛によるオンライン対戦ゲームを行なうことができた。
ゲームのソフトウェアは、オセロや将棋などの小規模なものはオンラインで提供されたが、グラフィックなどを含む「重い」ゲームはフロッピーディスクやROMカートリッジで供給された。
特に、Turbo Links 上のクイズゲームでは、1992年の段階でクイズ問題の追加とオンラインによる対人戦を実現しており、現在まで続くオンライン対戦型クイズゲームの嚆矢となった。
クイズ愛好家の間には、視聴者参加型クイズ番組の減少による不満が鬱積していた時期でもあり、このゲームのためだけにA1STとμ・PACKを購入するクイズマニアが少なからずいた。
当時は定額制のネット接続サービスが存在しなかったため、特に地方のユーザーにとっては通信料の負担が大きく、「みかか破産」（NTTに高額な電話代を請求され、支払えなくなること）するユーザーがあらわれて問題となった。
アーケード用クイズゲーム「クイズマジックアカデミーアーケード」シリーズに「アーケード」と付くのは、オリジナル版が Turbo Links 上で運営されていたことの名残りである。
この「MSXturboR」を書こうとした人は途中で寝てしまいました。続きは自分で執筆してください（PJ コンピュータ / Portal:コンピュータ）。
