ウェブ今昔物語 第2話 ガラケー時代の奇妙な冒険編

iモード時代のモバイルサイト制作を思い出す

スマホが登場するずっと前、日本では折りたたみ式のガラケーがモバイル端末の主役だった。

中でもDoCoMoが展開していたiモードは、“インターネットに接続できる携帯”として大ヒット。 それに続けとばかりに、auはEZweb、SoftBank（当時はJ-PHONEやボーダフォン）はYahoo!ケータイというサービスを展開していた。

問題は、この各キャリアが微妙に異なるHTML仕様を採用していたことだ。 iモードは独自のiHTML、EZwebはHDML（のちにXHTML）など、“モバイル用HTML”が統一されていなかった。

そのため、制作者は「各キャリアごとに別ファイルを用意する」ことが前提。 「モバイルサイトを作る」というのは、**“3種類の別サイトを同時に管理する”**ようなものだった。

また、スマホのようにレスポンシブ対応はできないので、PCサイトとは完全に切り分ける必要があった。 つまり、1つのプロジェクトにPC版＋モバイル3種＝4サイト分の工数が発生する時代だったわけだ。

今では考えられないが、それが当たり前だった。

画面幅120px、容量10KB、制限だらけの設計

ガラケーサイト制作でまず立ちはだかるのが、画面と容量の圧倒的な制限だった。

当時の標準的な表示領域は、幅120px・高さ130px程度。今のスマホと比べると、まるで名刺サイズのような感覚だ。

この狭い画面に合わせて、文字サイズや改行位置を細かく調整し、少しでも「見やすく・伝わりやすく」見せる工夫が求められた。

さらに、ファイルサイズの制限も手ごわい。1ページあたりのHTML全体が10KB以下でなければならず、
画像についても1点20KB以下・GIFかJPEGのみ対応という条件が付きまとった。

「どの情報を削るか」「どの画像を残すか」「どこまで装飾を諦めるか」──そんな取捨選択が、常に制作の裏側にあった。

CSSも使えなくはなかったが、多くの機種ではスタイルシートが非対応か動作が不安定だったため、
基本的にはタグ直書きとテーブルレイアウトで整えるのが現場の常識だった。

制限されるからこそ工夫が生まれる──とはいえ、あれはなかなかの試練だった。

そしてもうひとつの試練が、キャリアごとにバラバラだった「独自タグ」だ。

ガラケー時代に存在した『独自タグ』とは？

各キャリアの携帯サイトは、見た目こそ似ていても、中身のHTMLはまるで別物だった。
原因は、DoCoMo・au・SoftBankのそれぞれが、独自にHTMLタグや属性を拡張・定義していたことにある。

これにより、あるキャリアでは動いたタグが、他のキャリアでは無視されたり、場合によってはレイアウトが崩れたりもした。
しかもこれらのタグは、PCブラウザでは表示も動作も確認できないため、実機でのテストが不可欠だった。

通常はまずPCサイトを構築し、そこから各キャリア用のモバイルページを3つ派生させるのが定石だった。
つまり、ひとつのWebコンテンツに対して、最大で4種類のHTMLを用意・管理する必要があったというわけだ。

キャリア	主な独自タグ・仕様	備考
DoCoMo（iモード）	<i:emoji>、<i-mode:input>	iHTML（独自HTML）仕様。タグ名も特殊
au（EZweb）	<input format="M">など	HDMLやXHTMLに属性追加。独自の入力制御
SoftBank（旧Vodafone）	<emoji>、<accesskey> など	他キャリアとの互換性なし、絵文字も独自形式

3キャリアすべての実機で確認するなんて、正直ムリ！

当時はキャリアが提供していた簡易チェックサービスとか、サードパーティ製のテストツールもあったにはあったけど、
「まあ、だいたい合ってるだろう」くらいの気持ちで使っていた記憶がある。

それでも本番でレイアウトが崩れて、朝から胃がキリキリ痛むなんてことも日常茶飯事。
今だったら泣いてる･･･。

これは僕の予測だが、、、ガラケーでホームページ見る人は恐らく皆無！
無駄な努力だったのかもしれないorz

キャリア依存の絵文字地獄とShift_JISの呪い

ガラケー時代の“地雷”といえば、やはり絵文字と文字コードの問題は外せない。まず絵文字についてだが、今のようにUnicodeで統一されている時代とは違い、当時は各キャリアがバラバラの絵文字セットと内部コードを持っていた。同じハートの絵文字を表示させたいだけでも、DoCoMo、au、SoftBankそれぞれでまったく違うコードを書く必要があり、まるで別の言語を扱っているような感覚だった。

さらにやっかいなのは、他キャリアの絵文字を受け取ったときの挙動で、たいていは白四角（□）になったり、記号化けになったりしてまともに表示されない。そのため、絵文字変換ライブラリを導入したり、最初から絵文字を諦めたりと、泣く泣く調整していた人も多いはずだ。

そしてもうひとつの大きな壁が文字コード。ガラケーサイトではShift_JISが基本で、metaタグで明示しなければ文字化けはほぼ確定だった。一方で、PCサイトやCMSはUTF-8への移行が進んでおり、両対応しようとするとトラブルが続出。UTF-8で作ったページがガラケーで文字化けするという悲劇は、今でも鮮明に覚えている。

私自身、古いCGIメールフォーム（mpmail）でShift_JISのメールをUTF-8に変換する処理に手を焼き、「???」だらけのメール本文を見て頭を抱えた経験がある。最終的にはエンコードを無理やり変換して整えたが、正直あれは呪いのようだった。

絵文字と文字コード──どちらも見た目では気づきにくく、気づいた頃には崩れている。そんな地味で厄介な罠が、ガラケー時代には潜んでいた。

まとめ：小さな画面に詰め込んだあの頃の情熱

スマートフォンがまだ影も形もなかった頃、日本ではガラケーがモバイルの主役だった。iモードを筆頭に、キャリアごとに違う仕様や表示ルール、文字コードに振り回されながら、制作者たちは120pxの小さな画面と10KBの容量に夢を詰め込んでいた。独自タグ、Shift_JIS、絵文字化け、キャリア別の3分岐ソース──今では考えられないような制限と不自由さの中、それでも「少しでも使いやすく、見やすく」と知恵を絞って作り上げていた。思い出すだけで胃が痛くなるような場面も多かったけれど、あの混沌こそが、確かにモバイルウェブの原点だったのだと思う。