【Azure】要塞～RDPもSSHも使えないときは～

Microsoft Azureで仮想マシンを管理するには、RDP(Windowsの場合)またはSSH(Linuxの場合)による接続が必要です。

まれに、社内からはRDPもSSHも使えない会社があるようです。そういう会社でクラウドコンピューティングサービス、特にIaaSを勉強するののはほとんど無理だと思うのですが、皆さんどうなさっているのでしょう。

RDPやSSHが使えなくても、HTTPSは通す会社が多いようです。実は、HTTPSが使えれば多くの抜け道があるので何とかなります。RDPやSSHを禁止するのは「セキュリティ上の理由」と説明していただくことが多いのですが、HTTPSを通すのであれば、セキュリティ対策にはそれほど貢献していません。

もっとも、世の中にはアクセス先のIPリストを管理しているところもあるようで、それならセキュリティ上の意味はあります。もっとも、あまり厳しく制限すると今度はインターネットを使う意味がなくなると思いますが。

さて本題です。HTTPSを使ってAzureの仮想マシンにアクセスするのは以下の方法があります。他にも最低2つは思いついたので、皆さんも考えてみてください。

1. ポイント対サイトVPN接続(P2S VPN)
2. クラウドシェル上でのSSHコマンド
3. 要塞ホスト(Bastion Host)

1. ポイント対サイトVPN

仮想ネットワークにVPNゲートウェイを立てて、SSTP接続を行います。SSTPはSSLベースのVPNであり、HTTPSを通すのであれば問題なくつながるはずです。

また、OpenVPNを使うこともできます。OpenVPNはポート番号を自由に設定できるので、HTTPSと同じポートを使ってファイアウォールの制限を回避できる可能性があります。

ポイント対サイトVPNの詳細は、教育コース「Microsoft AzureによるITインフラの拡張」で紹介しているほか、拙著「ひと目でわかるAzure 基本から学ぶサーバー＆ネットワーク構築第3版」でも解説しています。

基本的には管理者を想定しているため、クライアントPCの管理者権限が必要です。

なお、ゲートウェイを作成するには30分ほどかかります。

2. クラウドシェル

Azureの管理ポータルからLinux (Ubuntu) ベースのシェルを起動できます。このシェルからsshコマンドを使ってSSH接続を行います。ただしGUIは使えません。

その場で起動できるので便利ですが、RDPを使って接続することはできません。また、Windowsに接続したい場合は、Windows仮想マシン上でSSHサーバー(デーモン)を起動する必要があります。そのためには初期化時にPowerShellのコマンドを送る必要があり、少々面倒な作業が必要になります。

3. 要塞ホスト

最近正式公開(GA: Generally Available)になった方法で、単に「要塞」と呼ぶようです。英語ではBastion(バスチョン)です。

大ざっぱな手順は以下の通りです。

1. 仮想マシンを作成
2. 仮想マシンを配置した仮想ネットワークに、AzureBastionSubnetという名称のサブネットを作成(現在は、事前に作成しなくてもBastion作成時に追加可能)
3. 要塞(bastion)を、AzureBastionSubnetサブネットを指定して新規作成
   
4. 仮想マシンの[接続]から[要塞]を指定
   要塞ができていない場合は、その場で作成することもできます。
   ここでサブネットの作成もできるようになりました。サブネット名が指定されるのでクリップボードにコピーして貼り付けてください。
   
   要塞の作成には数分かかります。
5. 要塞ができている場合、[接続]からWebブラウザのウィンドウ内でRDPまたはSSH接続が可能になります。
   
   

要塞の料金は、東日本の場合で1時間あたり21.28円プラス帯域使用料です。D2v2仮想マシンより少し安い程度ですね。

ただし「割り当て解除」のような、課金を中断する仕組みはないようです。サブネット名が固定されているなど、どちらかというとVPNゲートウェイに似ています。

おまけ: バスチーユ

ちなみに、bastion(要塞)に対応するフランス語がbastille(バスチーユ)です。

フランス革命勃発の舞台となったバスチーユ牢獄はもともと要塞だったのでそのまま「バスチーユ」と呼ばれるようになったそうです。

【Azure】Azureポータルのハブメニューが消えた?

ひと目でわかるAzure「基本から学ぶサーバー＆ネットワーク構築」第3版が無事出版されました。

ひと目でわかるAzure基本から学ぶサーバー＆ネットワーク構築第3版

前著から100ページ増加していますが、値段は200円アップにとどめています。

左から、初版、改訂新版、第三版です。第3版でだいぶ厚くなっていることが分かります。

クラシックモデルの内容をだいぶ削ったので、ここまで厚くなるとは思いませんでした。そもそも、そんなに加筆したつもりはないのですが。

例によって、校正中に機能が変わったり、画面が変わったりして、多少困ったこともあったんですが、大きな変化はなくてよかったと思います。

が、最近、Azureポータルの操作がちょっと変わりました。

左端のメニュー(ハブメニュー)がなくなりました。

3本ラインのハンバーガーボタン(本来は「引き出し」のアイコンらしい) を押すと出てきます。

従来のハブメニューは、正直ちょっと邪魔だったのでよく縮小してました。前著「改訂新版」でも、ハブメニューを縮小した画面ショットを多用しています。今回はきちんと表示しているのですが、これだったら隠しても良かったですね。

【Azure】Azureサイトリカバリーで可能な操作

「Microsoft Azureによる災害復旧手法」のテキストで、少しわかりにくいところがあったので補足します。

詳細は、マイクロソフトの公式情報「Hyper-V から Azure へのディザスター リカバリー アーキテクチャ」をご覧ください。

いつでも実行可能な操作

以下の作業はいつでも実行可能です。

• 移行の完了…現在の状態を保存し、複製を正常に終了(フェールオーバー中の仮想マシンは残る)
• レプリケーションの無効化…複製をなかったことにする(フェールオーバー中の仮想マシンは残る)

Hyper-V対Azure

Hyper-V対Azureの複製の場合、利用可能な操作は以下の通りです。

●平常時(Hyper-Vで実行)

• 計画されたフェールオーバー
  
• フェールオーバー
  
• テストフェールオーバー

●テストフェールオーバー中(両方で実行)

• テストフェールオーバーのクリーンアップ

●計画されたフェールオーバー(Azureでの実行に切り替え)

• 復旧ポイントの変更
  
• コミット(復旧ポイントの確定)
  

●計画されたフェールオーバー後のコミット後(Azureで実行中)

• 計画されたフェールオーバー(つまりフェールバック)

●フェールバック中

• コミット(フェールバックが確定するが、Azure上の複製に対して構成変更できないなどの制限がある)

●フェールバック中のコミット後

• レプリケーションの反転(複製を含め、すべてが平常時の状態に戻る)

Azure対Azureの場合

オプション演習のAzure対Azureの複製の場合、利用可能な操作は以下の通りです。

●平常時

• フェールオーバー
• テストフェールオーバー

●テストフェールオーバー中

• テストフェールオーバーのクリーンアップ

●フェールオーバー中

• 復旧ポイントの変更
• コミット→復旧ポイントの確定

●フェールオーバーからのコミット後

• 再保護→反転した複製の開始→平常時へ移行

Azure対Azureは、両サイトが対等の関係なので「フェールバック」という概念はないようです。

---

【追記】

フェールバック中、コミットした段階で複製は始まります。ただし、反転するまではフェールオーバーができません。フェールバック後の障害に備えるには、必ず反転する必要があります。

「クラウド市場シェアナンバーワン」に意味はない

「AWSが世界のクラウドサービス市場で首位陥落、マイクロソフトが逆転」というニュースが入ってきて、正直ちょっとあわてました。

AWSがクラウド業界のリーディングカンパニーであることは間違いなく、それを追うのがマイクロソフトという構図は変わっていません。また、市場シェアはAWSのざっと半分がAzureというのが一般的な見解です(調査会社によっては4倍程度まで開きます)。

「AWS vs. マイクロソフト」つまり、SaaSを含む全クラウドの売り上げを集計すると、僅差でマイクロソフトが勝ったということです。逆にいうと、ほとんどSaaSを持たないAWSが、僅差で2位というのはいかにAWSが支持されているかの証拠でもあります。

SaaS (Software as a Service) はクラウドの一種ではありますが、利用者の意識はちょっと違うように思いますし、IT技術者の意識もSaaSは区別して考える場合が多いようです。

AWSは最近までSaaSには手を付けていませんでした。マイクロソフトはIaaSとPaaSをAzureとして提供していますが、SaaSは別ブランドです(たとえばOffice 365)。IBMも、IaaSのSoftLayer、PaaSのBluemixを統合しIBM Cloudとしましたが、SaaSは別ブランドです。

SaaSを特別扱いするのは、それがビジネスと直結しているからです。電子メールやドキュメントツールくらいなら、会社による違いはそれほどありませんが、会計システムだと業界ごとの差は大きく、会社ごとの独自性もあります。

マイクロソフトもAWSも、業務に直結したアプリケーションの提案は、ビジネスパートナーの仕事です。マイクロソフトはDynamics 365というERPクラウドを持っていますが、これはクラウドプロバイダーとしてはかなり珍しい存在です。

ただ、近頃のSaaSはアプリケーションから利用するためのAPIが公開されており、実質的なPaaSとして利用できます。CRM(顧客管理)のSaaSで有名なSalesforceは、Salesforce CRMの動作基盤をPaaSとして利用できます。このように、SaaSとPaaSの区別はあまりなくなってきています。

このように、SaaSは定義的はクラウドですし、実体としてもPaaSに寄ってきたので、名実共にクラウドの一種ではあります。

それでも、現段階でSaaSをIaaSと同列に並べるのはちょっと抵抗を感じます。

そういうことを感じながら、「AWS首位陥落」という表現はちょっと違うなあと思いながら書いた記事がこちらです。

クラウド市場シェアナンバーワンはどこだ？～AWS vs. マイクロソフト～

英語版Windows Serverを日本語化する手順

Azureなどのクラウドが提供する仮想マシンの多くは英語版のOSしか利用できません。AWSの場合は、Community AMIとして日本語化されたものも選べるようですが、Azureにはありません。Azureには、中国語版が最近追加されたので、日本語版も追加される可能性はゼロではありませんが、可能性は低いでしょう。

そこで、以前「英語版Windows Server 2012 R2を日本語化する手順」というエントリを書きました。しかし、手順を紹介しただけで、画面ショットもありませんでした。

Windows Server 2019で操作手順が変わったため、改めて画面ショットも付けて書き直しました。

【図解】英語版Windowsの日本語化～画面ショット付き詳細手順～

今度は会社の公式ブログに載せてもらいました。

Windows Server 2019では[コントロールパネル]ではなく、[設定]を使います。Windows Server 2016では[コントロールパネル]と[設定]のどちらでも可能ですが、[設定]の手順がWindows Server 2016と微妙に違います。一方、コントロールパネルを使った手順はWindows Server 2012と同じなので、ブログではWindows Server 2019とWindows Server 2016以前の2つに分けています。

マイクロソフトMVPアワード受賞できませんでした

2003年4月から、連続して受賞してきた「Microsoft MVPアワード」ですが、今回は受賞できませんでした。

一昨年は書籍が2冊出たのですが、昨年は全くなかったことが要因かもしれません。現在、書籍執筆が2冊進行中なんですが、ちょっと残念です。

【Azure】マネージドディスクとイメージ、仮想マシンの課金

一般にクラウドコンピューティングサービスでは「使った分だけ課金」が基本ですが、何をもって「使ったか」というのはなかなか難しい問題です。

ストレージアカウントの場合(ページBLOB=非マネージドディスクを含む)

Azureのストレージは、Standard ページBLOBを使った仮想ディスクだけが「実際に使った分量に対してGB単価で課金」で、その他のストレージは「割り当てた分量に対して課金」です。

Standard ページBLOB以外のストレージは、いくつかの容量が事前に用意されており、それを選ぶ「カタログ方式」となっています。実際には1GB単位で指定できるのですが、課金はカタログ単位の切り上げになります。たとえば128GBの次は256GBなので、129GBを割り当てると256GBの課金が発生します。

請求は1ヶ月単位のサイクルで行なわれますが、ストレージの使用が1ヶ月に満たない場合は毎日の平均(日割り計算)となります。

Azure Storage を月に数日間のみ使用した場合、料金は日割りされますか?

はい。ストレージ容量は、1 か月にわたり、保存されていたデータ量の 1 日あたりの平均 (GB 単位) を基準に請求されます。たとえば、月の前半は 10 GB のストレージを常に使用し、後半は使用しなかった場合は、ストレージの平均使用量の 5 GB が課金されます。

(ストレージのFQAより)

課金は1日のピークで行なわれるので、図の例で6月15日にゼロにするためには、6月14日中に削除しておく必要があります。

マネージドディスクの場合

ただし、マネージドディスク(管理ディスク)の場合はStandard HDDを含むすべての種類が割り当て単位で課金されます。また、カタログにある容量を超えた場合は課金が切り上げられます。

ストレージアカウントと同様、請求は1ヶ月単位のサイクルで行なわれますが、マネージドディスクの使用が1ヶ月に満たない場合は1時間単位の課金となります。

以下に示す料金が月額になります。管理ディスクを 1 か月未満使用した場合はどのように課金されますか。

料金は月額を使用して、時間単位で計算されます。たとえば、P15 の Premium SSD は ¥4,896.720 になります (リージョンによって料金が異なります)。10 月は、¥4,896.720/(31 日 x 24 時間) = ¥6.582/時間で課金されます。

(マネージドディスクのFQAより)

仮想マシンイメージの課金

マネージドディスクから仮想マシンイメージを作った場合、「スナップショット」と同等の料金がかかります。「無料」と書いてある記事もあるようですが、課金されることはサポートに問い合わせたので間違いありません。

しかし、実際に課金状況を調べてみると、はるかに小さな金額しか請求されていません。「課金サポートではこれ以上のことは分かりかねるので、有償の技術サポートに連絡して欲しい」と言われました。詳細が分かったら報告します。

仮想マシンの課金

Azureの仮想マシンは、分単位課金です。仮想マシンが実行状態になってから課金がスタートして、最初の1分は無条件に1分が課金されます。

その後、1分59秒までは追加の課金がなく、2分になってから次の1分の課金が行なわれます。

AzureのWebサイトには「秒単位課金」という言葉や「時間課金」という言葉が混じっていて混乱していますが、ブログ執筆時点で分単位で課金されることは間違いありません。

「秒単位課金」は「秒単位計測」の意味のようです。1分59秒までが1分、2分ちょうどから次の1分と、正しく認識するには秒単位の計測が必要です。

「時間赤金」は課金明細の記載単位だそうです。確かに、利用明細には「0.92 1時間」のように、1時間単位で記載されています。

ちょっと紛らわしいですね。

なお、後損仁通り、仮想マシンの課金は単なるシャットダウンでは停止せず、「割り当て解除」状態に移行しないと課金が継続します。ハードウェアの割り当てをしている以上は「使っている」とみなすわけですが、これも直感に反します。理屈が分かれば不思議ではないのですが。

【Azure】Azureの仮想マシンにドメインコントローラーを構成する

Microsoft Azureの仮想マシンにドメインコントローラーを構成する場合、以下の注意が必要です。

• データベースはCドライブに置かない
• 仮想ネットワークのDNSサーバーアドレスをドメインコントローラーのものに変更する

AzureのシステムディスクにはRead/Writeキャッシュが設定されていて、不慮の事態によるデータロスがあり得ます。SLAでは稼働率99.9%とか99.95%となっていても、落ちるときは落ちます。

ドメインコントローラー昇格時は、ディレクトリデータベースを配置したディスクドライブのキャッシュを無効にするため、データロスの問題は発生しませんが、パフォーマンス劣化の問題があり、いずれにしてもCドライブににディレクトリデータベースを配置するのは好ましくありません。

と思っていたんですが、Azureキャッシュは無効にできないようです。つまり「データベースはCドライブに置かない」という結論は同じですが、その理由は「予期せぬ停止により、データロスが発生する可能性があるから」ということになります。

このあたりの話は、以下のコースで扱っています。

Microsoft Azureによるサイト間ネットワークの構築 ～ハイブリッドクラウド構成の基礎～

Linuxのお客様も増えてきたので、カリキュラムの変更も考えているのですが、当分の間Windows Serverの話をしています。ただし、最後の1時間くらいです。

AzureとAWSの可用性ゾーン(AZ)

Microsoft Azureの「可用性ゾーン(AZ)」が東日本で利用できるようになっています。西日本はもう少しかかりそうですが、いずれは利用できるようになるそうです。

AzureのAZは、リージョンあたり3つと決まっています。AWSは「2つ以上」だったでしょうか。

Azureのリージョン間は数百Km以上離れているので非常に安全ですが、少々距離が遠すぎます。一方、AZ間の距離は(同一リージョン内の)数十Kmと、かなり短くなっています(AWSと同程度です)。阪神大震災でも40Kmも離れればほとんど影響はありませんでしたから、実用上はAZで十分でしょう。

従来の可用性セット(AS)は、最短でサーバーラックが分離されるだけですから、大規模災害に対しては少々不安が残ります。災害リスクを考えるとAZが必要でしょう。また、日本に関しては、可用性セットで分離できる障害ドメイン(サーバーラック)は2つですから、障害範囲に関しても現時点ではAZの方が有利なようです。

ただし、AZは仮想マシンを作るときにゾーンを明示的に指定する必要があります。それに対してASは「とりあえず同じASにする」という設定で、適当に分散してくれます。何も考えなくてもいいので、ASの方が設定は楽です。

以上のことから、災害対策を想定する場合はAZ、ハードウェア障害を想定する場合はASと使い分けるのがいいようです。なお、Azureでは災害対策にはASR(Azureサイトリカバリ)も利用できます(ASRはリージョン間の複製です)。ASRを使っているならAZを使う必要はないでしょう。

また、「AzureのAZはAWSのAZと同じ」という説明がされていますが(私もしています)、実際には違いもあります。

AWSでは、AZ単位でサブネットを分割する必要があります。これに対して、Azureでは同一サブネット内に異なるAZのサーバーを配置できます。

もっとも、AZが違えばデータ伝送遅延時間が違うので、異なるAZを同じサブネットにするのが適切かどうかは分かりません。AWSと同じように、異なるAZは異なるサブネットにした方が分かりやすいのではないでしょうか。

試しに、複数のAZに複数のサブネットを構成してpingを実行してみました。Windowsのpingは応答時間の分解能が低いのでLinux(Ubuntu)を使っています。

図のように、AZ内では1ミリ秒程度、AZ間では2ミリ秒程度の遅延がありました。サブネットの有無は速度に影響しません。これもAWSと同様のようです。

アプリケーションにとっては1ミリ秒と2ミリ秒の違いが重要な場合もあるので、サブネットを自分で分けた方が分かりやすそうです。

Azure管理用PowerShellモジュール「AzureRM」の削除手順

Microsoft Azureの展開モデルには「クラシックモデル(別名サービスマネージャー)」と、「リソースマネージャー」があります。

PowerShellから管理する場合、クラシックモデルはAzureモジュールを、リソースマネージャーはAzureRmモジュールを使っていました。

Azureモジュールのコマンドレット(PowerShellのコマンド)は「動詞-Azure名詞」の形式で、たとえばGet-AzureVMのようになります。

AzureRmモジュールのコマンドは「動詞-AzureRm名詞」の形式で、たとえばGet-AzureRmVMのようになります。

よく使うリソースマネージャーの方がコマンド名が長くなっているのは、リソースマネージャーがあとから登場したためです。

昨年から提供されているのは、AzureRmモジュールに変わるAzモジュールです。こちらは「Get-AzVM」のようにAzを識別子として使うため、コマンドレットが少し短くなっています。

しかし、これにより2つの問題が発生しました。

• 既存のスクリプトが動かなくなる
• AzモジュールがAzureRmモジュールと共存できない

以下が解決方法です。

【既存のスクリプトが動かなくなる】

コマンドレットの名前が変わると既存のスクリプトが動作しなくなります。そこで、Enable-AzureRmAliasというコマンドレットが用意されました。このコマンドレットを実行することで、AzureRmモジュールのコマンドレットがAzモジュールのコマンドレットの別名として利用できます。

【AzモジュールがAzureRmモジュールと共存できない】

PowerShellのAzureRmモジュールが残っている場合は、Azモジュールのインストール前にAzureRmモジュールをアンインストールしてください。Azureモジュールはそのままで構いません。

詳しい手順は以下を参照してください。

Azure PowerShell モジュールのアンインストール

私の環境では、それでもいくつかのサブモジュールが残ってしまいました。そこで、以下のコマンドを実行しました(全体で1行です)。

Get-Command *az* | where module -Like "azurerm*" | Sort-Object -Unique module | ForEach-Object {Uninstall-Module $_.module}

きちんとデバッグしていないので、利用する場合は十分テストしてからにしてください。

Living Computer Museum(その7) ～ストレージ編～最終回

Living Computer Museumの紹介も第7回。最終回はストレージの紹介です。

最古のストレージが「ホレリスカード」、何しろコンピューターより古くからあります。統計処理に使われたようですね。当時の1ドル札とほぼ同じで、紙幣運搬用の箱に入れて保管したそうです。

ちなみに、1枚80文字です。Living Computer Museumでは実際にパンチしたカードを持って帰ることができました。

ホレリスカード(パンチカード)

コアメモリモジュール。ミニコンピューターでは広く使われたようです。ドーナツ型のフェライトコアに3本の線を通したものを、網戸のようなモジュールにまとめています。

メモリ(磁気)の保持に電源を必要としないため、ノートPCのハイバネート的な使い方もできたそうです。

コアメモリモジュール(32KBくらいでしょうかねえ)

網戸的な部分をアップで撮影。

コアメモリのアップ(網戸みたい)

コアだけの展示もありました。

コアメモリのコア

寄ってみると、ドーナツ状の形が分かります。

コアメモリのコア(拡大)

コンピュータの故障コーナーもあって、クラッシュしたディスクが展示してありました。

クラッシュした磁気ディスク

こちらは旧式のディスク。円盤は数枚あるのに全部で200MBしかありません。おそらく1980年代のものでしょう。

磁気ディスクパック(200MB)

磁気ディスクの原型となった磁気ドラム。今でもアイコンに使われています。

磁気ドラム(今のディスクのアイコンはこれ)

磁気ドラムのアップ。

磁気ドラム

70年代特撮ドラマでおなじみ(?)磁気テープ。ここにあったのはDEC TU78で、私も使いました。「私も使った」というと、学芸員の人が驚いてました(笑)。

DEC TU78磁気テープ

Living Computer Museumの話は以上です。

実際に動くのが面白くて、4時間くらいいたように思います。お土産にCray-1のペーパーモデルを買ってきました。組み立てたらまた紹介したいと思います。

Living Computer Museum(その6) ～PC編～

現在のPCは、日本の電卓ベンダーだった「ビジコン」社が、当時の新進企業インテルにLSIを発注したことからスタートします。

この頃、日本ではシャープとカシオによる電卓開発競争が激化しており、小型化や薄型化とともに機能拡張も盛んに行われていました。

両社に対抗するため、ビジコン社では「簡単に機能を追加・変更できる電卓用IC」を求めていました。これがコンピュータであることを見抜いたインテルのエンジニアは、ビジコン社の社員だった嶋正利氏とともにCPUを設計します。このあたりの経緯は「マイクロコンピュータの誕生――わが青春の4004」に詳しく記載されています(ただし、嶋正利氏の視点であることには注意してください)。

4004は電卓用だったため、4ビット単位で演算を行う「4ビットCPU」でした。4ビットあれば10進1桁を表現できたからです。

後に8ビットCPU「8008」が開発されましたが、ハードウェア的に少々扱いにくかったため、8080を開発します。「40ピンのワンチップLSIでCPUが入手できる」ということで話題になりました。ピン間隔は約2.5mmです。

インテル8080マイクロプロセッサ

当時、半導体は同じ仕様の製品が複数社から提供されるのが普通でした。2社目以降を「セカンドソース」と呼びます。CPUも例外ではなく、セカンドソースとしてNECなどが8080互換CPUを製造していました。

1社独占になるのは16ビットCPUから32ビット化が進んだ頃だと思います。

モトローラMC6800トレーニングキット

インテルに続いて、モトローラもCPU製造を開始します。8080は電卓用途からスタートしたため、汎用のコンピューターとしては機能不足や、アーキテクチャ的に「美しくない」点が感じられました。この問題は、今のXeonになってもいまだに言われます。私、最新の命令セットを知らないので、本当かどうかは判断できないんですが。

後発のモトローラ社は、通信機や半導体製造の大手企業であり、最初からコンピューターとして設計したMC6800を投入します。DEC PDP-11を参考にしたとされるCPUは、小型ながら豊富なアドレッシングモードと、ある程度直交した命令体系を持ち、多くの人に支持されます。

ただし、CPUは小さくてもコンピューターにはソフトウェアが必要です。そこで、エンジニアがソフトウェアを作成し、実際の動作をテストできるような最小構成のキットが発売されました。いわゆる「トレーニングキット」です。

展示してあったのは、モトローラMC6800のトレーニングキットです。

なお、日本ではNECが8080互換CPUを使った「TK-80」を発売し、当時としては爆発的に売れました。買ったのはエンジニアだけではなく、ホビイストも多かったようです。

ALTAIR 8800 (キット)

Altair 8800は、インテル8080を使ったコンピュータキットです。トレーニングキットとは異なり、純粋にホビー用途でした。

Altair 8800にはソフトウェアが全くなかったため、ビル・ゲイツとポール・アレンがAltairの製造元であるMITS社に「BASICインタプリタ」を売り込むことに成功します。マイクロソフトの創業がシアトルではなく、アルバカーキなのはMITS社がアルバカーキにあったためです。

IMSAI 8080 (ALTAIR 8800互換品)

Altairのハードウェアには少々雑なところがあり、製作者は苦労していたようです。製作代行業者もいたと聞きます。

IMSAI 8080はAltair 8800と完全互換のコンピューターで、より洗練したハードウェアを持っていました。

テレタイプ社のテレタイプ

AltairやIMSAIの入出力装置として使用されたのが「テレタイプ」です。テレタイプは、タイプライターから入力した文字を遠隔地で印字する装置で、テレタイプ社の商標です。企業でも、コンピューターのキー入力装置としても広く使われました。

特に人気のあったのがASR-33という機種ですが、機械式タイプライターに似た機構は、打鍵がうるさく一般家庭で使えるようなものではなかったそうです。

コモドールPET 2001の後継と思われる

インテル8080やモトローラMC6800は180ドルくらいだったそうです。1975年当時は1ドル300円程度ですから、5万4000円程度になります。さすがにちょっと高いので、完成品としてのコンピューターはかなり高価になります。ちなみに現在のインテル Core i5の小売価格は2万円くらいです。

そこに登場したのがモステクノロジー社の6502です。これは、モトローラのMC6800開発チームがスピンアウトして作ったCPUで、シンプルながら洗練されたアーキテクチャを持っていました。

6502はわずか25ドル(7500円)で入手できたため、ホビイストたちの興味をひきました。こうして生まれたのがApple IIであり、コモドール社のPET 2001です。

写真はPETの文字はありますが、キーボードがオリジナルPET 2001と違います。改良モデルなのでしょう。PET 2001はApple IIよりもソフトウェア性能やハードウェア機能面で劣っていたようですが、安価なためよく売れました。

任天堂ファミリーコンピュータ(ファミコン)も6502互換CPUを使っています。

TRS-80

タンディラジオシャック(TRS)が発売したTRS-80は、Apple IIやPET 2001と同様、買ってすぐ使える完全なコンピューターで、BASICインタープリタを内蔵していました。また、本体とキーボードが一体で、ディスプレイを外付けするようになっていました。

写真のTRSはフロッピーディスクが付いているので、後期モデルと思われます。初期モデルは、外部記憶装置としてオーディオカセットテープを使っていたはずですし、ディスプレイも分離型でした。

TRS-80は、Apple IIよりも落ち着いたデザインで、ビジネス用途に広く使われたように思います。

クロメンコ(Cromemco)社のPC

クロメンコも、IMSAIと同様、Altair互換機ですが、使っている人はあまり見ませんでしたが、世界的にはかなり売れたはずです。写真のような一体型PCを出しているのは知りませんでした。おそらくTRS-80の少し前だと思います。

IBM PC

満を持してIBM PCが登場です。型番はIBM 5150、名称はthe IBM Personal Computerだそうです。「IBMらしい名前だ」と月刊アスキー誌に出ていたのを覚えています。

先に紹介した「Welcome IBM. Seriously」というアップル社の広告は、このIBM PC登場直前の出来事です。

Compaq Portable

IBMは、サードパーティの参入を容易にするためシステム情報を積極的に公開しました(過去のIBMには絶対なかったことです)。しかし、IBMの予想に反して、本体の互換機が出てしまいます。Compaqもその1つで、本家よりも高速で高機能なPCを発売します。

Compaqポータブルは、世界初の「持ち運べる(ポータブル)PC」です。

IBM PC/AT

互換機に懲りたIBMは、新機種PC/AT以降、PC情報に対してライセンス契約を要求するようになりました。これに対抗して、PC互換機ベンダーは協同で別規格を立ち上げます。

最終的にIBMが実質的に折れることになり「IBMがIBM互換機を作る」などと報道されてしまいました。

さまざまなPDA

各種PDAも展示されていましたが、このあたりは新しすぎるせいか、単に並べてあるだけでした。

Living Computer Museum(その5) ～Apple編～

現在のPCの基礎を築いたApple製品ももちろん数多く展示されています。

これは Blue Box と呼ばれた「製品」で、世界中どこでも無料で電話をかけることができました。電話会社の交換機のバグを利用しています。当時は不正アクセス禁止法的なものがなかったはずなので、違法かどうかは分かりませんが、製作者のスティーブ・ウォズニアック(Appleの共同創業)が違法と言っているそうなので違法なのでしょう(Apple設立につながる電話ハッキングデバイス「ブルーボックス」についてウォズとジョブズ、関係者が語る)。

ちなみに、本来「hacking」はニュートラルな表現で、「工夫してうまいことやる」くらいの意味です。Blue Boxは電話交換機のhackであり、違法なものでした。

Blue Box (無料で電話をかける装置)

このBlue Boxを売りさばいたのがスティーブ・ジョブズで、最後はヤクザとトラブルを起こして殺されかけたそうです。

後にApple Iと呼ばれた製品(完成品ではなかった)

ステーブ・ウォズニアックが作ったApple I。ただし、設計中はまだ名称はなかったようです。Appleという社名はスティーブ・ジョブズが考案したそうです。

Apple Iの電源(パワートランジスタ)

スイッチングレギュレーターは一般的ではなかったため、パワートランジスタを使ったシリーズレギュレーターを使っているようです。

Apple II (スティーブ・ウォズニアック設計の傑作)

完成品として売り出されたApple II。ケースのデザインにはスティーブ・ジョブズの影響が強いとされています。一方、Apple IIの特徴である多数の拡張スロットはスティーブ・ウォズニアックが断固として譲らなかったとか。また、回路図も公開されていました。

この拡張スロットに別のCPUボードを装着することもできたようで、ザイログZ80を搭載しCP/M (当時広く使われた8 bit CPU用OS)を動かした人もいました。

回路図を公開し、仕様を公開した拡張スロットで機能を強化する考え方は、後にIBM PCに引き継がれます。

一方、スティーブ・ジョブズはあくまでもクローズドな環境にこだわり、中を開けることすらできないMacintoshプロジェクトを率います。

Apple III (まだ5インチFD)

Apple IIの後継製品Apple III、ビジネス的にはあまり成功しなかったようです。

Apple Lisa 2 (本来Macとは別プロジェクト)

フルGUIのLisa (写真はLisa 2)。Lisa開発中、スティーブ・ジョブズがPARCでのデモを見て、キャラクタベースからGUIに方針転換されたそうです。

Macintoshのケース内側(開発者のサインが刻印されている)

その後、素行不良でLisaのプロジェクトを追い出されたスティーブ・ジョブズが乗っ取ったのがMacintoshプロジェクト。初代Macintoshの筐体内部には開発のサインが刻印されています。

先に書いたとおり、一般的なツールでは中を開くことすらできないのに、こんな刻印を入れるのは自己満足の塊ですが、開発者としては嬉しかったことだと思います。

Macintosh SE (この辺からMacが実用的になった)

初代Macintoshからしばらくは縦長の一体型でした。3.5インチフロッピーディスクが採用されたのもここからです。なお、初期の3.5インチフロッピーディスクには自動シャッター機能がなかったのですが、Macintoshのために作られたという噂です(参考:記録メディアの歴史)。

マウスボタンを1つにしたのもスティーブ・ジョブズの決断です。PARCの研究では、3ボタンが最も生産性が高いことが分かっていたのに、あえて1ボタンを採用したのは、生産性よりも単純さを優先したからのようです。

なお、PARCではマウスの右ボタンは、ウィンドウのサイズ変更や移動に使っていたので、3ボタンマウスは現在の感覚では2ボタンと同じ操作になります。ウィンドウ端をつかむ部分(ウィンドウハンドル)はありませんでした。

IBMがPCに参入したときに出したAppleの広告

IBMがPC業界に参入する前、ウォールストリートジャーナルに掲載した広告。

Welcome IBM. Seriously

英語の定型句なら

Welcome IBM. Sincerely. (IBMの参加を心から歓迎します)

となるのでしょうが、ちょっと違います。無理に訳すとこんな感じでしょうか。

IBMの参加をマジで歓迎します。

この広告は、コンピュータ界の巨人IBMの参入をAppleは恐れており、単なる空元気だったという説もあれば、Appleは自社に自信があるため、余裕を持ってIBMを「おちょくってる」という説もあります。

その後、ご存じのようにAppleは、Apple IIの思想を受け継いだIBM PCにビジネス的には大敗しますが、Macintoshシリーズは市場シェア以上の存在感を維持し、DTP分野を中心に広く使われるようになります。

もっとも、初期のMacintoshの販売戦略は混乱気味で、DTP市場を獲得したのも偶然の要素もかなりあるようです。

Living Computer Museum(その4) ～ワークステーション編～

まだまだ続きます。

ここの博物館で、もっとも興味をひかれたのがXEROX社のPalo Alto Research Center (PARC) で開発されたALTOの復刻版です。

XEROX社は、このままコンピュータ化が進むとコピー需要が減ると考えてコンピューターの研究をしていました。

PARCはその中心地で、以下のような技術が研究されていました。

• ワークステーション…1人が1台のコンピューターを占有する考え方です。現在では当たり前のことです。
• ビットマップディスプレイ...画面上のドットをメモリに割り当てる仕組み。現在のグラフィック表示の基礎です。
• マウス…最近はタッチデバイスに押されていますが、現在でも広く使われているポインティングデバイスです。
• Ethernet LAN…後にDIX(Xerox、Intel、DEC)規格となりました。その後IEEE 801として標準化されますが、現在でもUNIXのLANはDIX規格をベースにしています。
• レーザープリンター…XEROX社のコピー技術を応用したプリンターで、現在のビジネスプリンターの標準方式です。

残念ながらXEROX社はこうした技術の商用化に失敗し、LAN研究をしていたロバート・メトカーフ氏は3COM社を設立(後にHPが買収)、プリンター用のページ記述言語を製作していたチャールズ・ゲシキ氏とジョン・ワーノック氏はAdobeを設立し、PostScript言語を開発します。

また、ワークステーションのデモを見たスティーブ・ジョブズ氏やビル・ゲイツ氏がウィンドウシステムの開発を決心したのは有名な話です。

ちなみに、PARCでワードプロセッサーの研究をしていたチャールズ・シモニー氏はマイクロソフトで表計算ソフトウェアMultiplanやExcel、ワードプロセッサーWordなどを開発します。

復刻版ALTO(モニター)

復刻版ALTOは、実際に起動するところを見せてもらいました。

復刻版ALTO(電卓アプリ)

復刻版ALTOで動作する電卓アプリ。

ALTOエミュレーター(左)と復刻版ALTO用ディスクパック(右)

ALTOの起動に使われたディスクパックはDEC製でした(写真右)。また、ALTOエミュレーターも動作していました(写真左)。

ALTOエミュレーター(自宅で実行)

ALTOの直系システムStar(これは商用化されており、日本ではJ-Starとして販売されていました)のエミュレーター「DarkStar」はGitHubで公開されています。自宅で実行してみました。エミュレーターとシステムソフトウェアが別々に公開されていることに注意してください。

なお、J-Starはワープロ専用機として販売されており、プログラム環境はなかったと記憶しています。Starについては分かりませんが、エミュレーターとしてスタンフォード大学で開発されたLisp言語「Interlisp」にGUI機能を追加した「Interlisp-D」が動作しました。

Interlispは、MITで開発されたMacLispと並んで人気があり、西のInterlisp、東のMacLispと言われていました。

試作マウス

試作版マウスも展示してありました。最終的に3つボタンマウスが採用されます(日本では「みっつキーマウス」と呼んだ人もいます)。左ボタンは現在と同じ使い方ですが、現在の右ボタンは中央ボタンに割り当てられました。

残った右ボタンはウィンドウの拡大やクローズなどの操作メニューを表示します。当時のウィンドウには、現在のようなウィンドウハンドルがなく、マウスで「つかむ」という操作ができなかったためです。1980年代になってもX Window Systemのuwmでは同様の方式が採用されていました。

最初期のPC用マウス

最初期のPC用マウスは2ボタンでした。ボタンの使い方は前述の通りで、実質的にPARCの3ボタンマウスと同じ使い方をします。

PARCの研究では、2つ以下だと操作性が落ち、4つ以上だと操作に戸惑うことが分かっています。Macintoshでは、スティーブ・ジョブズの一存で1ボタンに決まったとされていますが、おかげで操作性が随分低下しています。

最初期のPC用マウス(裏面)

移動距離は底面の金属ボールの動きで検出しています。後にゴムボールになり、現在は光学式が主流です。

ワークステーションの源流については以上です。

---

その他、初期のコンピューター関連展示物で、前回までに書きそびれたものをついでに紹介します。

PLATOシステムの端末

PLATOシステムの端末です。PATO上で動作する情報共有システムとして「Plato Note」というソフトウェアがありました。これが後の「Lotus Notes」に発展します。

私は、前職でPlato NoteをベースにしたVAX Notesという製品を使っていました。

ENIGMA暗号機

第2次大戦でドイツ軍が使った暗号システム「ENIGMA」。暗号化技術とコンピューターは密接な関係をもって発展します。

十進計算機(手動)

手動式の十進計算機。日本や中国には算盤があったので、この種の計算機はほとんど見ません。