富永日記帳 ウェブ技術や東急電車、久米田康治作品の話を中心としたブログ tag:blog.w0s.jp,2009:/ 富永冴樹 /image/feed-icon.png 2025-03-25T23:33:51+09:00 『踊る！さんま御殿!!』の歴代ヒット賞受賞者SPに久米田先生が4度目の出演 tag:blog.w0s.jp,2025-03-25:/735 2025-03-25T23:33:51+09:00 2023年10月17日、2024年4月30日、2024年10月29日に続き、「歴代ヒット賞受賞者SP」として久米田先生が4度目のご出演を果たされました。

メディア紹介

§

今回は1回目～2回目のような漫画家仲間などからの感想や、ニュースメディアでの紹介は見当たらず。また2回目と3回目であった新聞 TV 欄での言及もありませんでした。

一方で TVer のサムネイル画像(statics.tver.jp)には全出演者の顔写真が過去の受賞回数とともに表示されています。TVer での配信は期間限定のものであり、配信期間が終わるとサムネイル画像を含めてアーカイブは残らないのでいまのうちに URL ともども保存しておく必要がありますね。

サムネイル画像
TVer の番組ページのスクリーンショットオリジナル画像
  • こういうのは本来国会図書館に記録してほしいところですが、現在の日本では TV 番組そのものデータすら公的機関でアーカイブが行われていない状況なので、配信のサムネイル画像などはなおのこと視聴者が手動で保存しておかないと未来に記録が残らないのが現状です。

放送本編の内容

§

「これって私が間違ってますか?」のテーマで、久米田先生からは完結していない人気作品の評価についてトークがありました。

サムネイル画像
番組で久米田先生が紹介されるシーン（TV 画面のスクリーンショット、下部テロップに「漫画家　久米田康治　ヒット賞3回」）オリジナル画像

ご自身が短めの作品を多く完結させてきたことに触れ、打ち切りの回数を評価してほしいと主張。これに対してさんまからは「なに言うてんのあいつ」と厳しい突っ込みがあり、他の出演者も最初は理解ができていない反応をしていたのですが、久米田先生の手前に座っていた伊集院光は「不人気で打ち切りならそれきりだが、次の連載が続くのは周囲の期待があるから」旨の賛同をされていたのは良いフォローでしたね。

ところでこの話は『かくしごと』第17話（単行本4巻(Amazon)に収録）における未完の漫画に名作など無いや終わらせる事が出来ていない作品は評価に値しないといった名セリフが思い出されます。

サムネイル画像
後藤可久士が未完の漫画に対する持論を述べるシーン（『かくしごと』単行本4巻 p.90）オリジナル画像

続くトークでの連載は始めるときより終わらせる方が難しいの発言はギャグ漫画ながら最終回に定評のある久米田先生だからこそ重みのあるものになっていますし、長い作品ほど広げた風呂敷を畳まないといけないは僚友・藤田和日郎先生の『からくりサーカス』などを念頭に置いたものではないかと感じた次第です。

ところでなえなののトーク中に「顔を差す」を「俺はカオサス」とボケたさんまに対してツボっている久米田先生のお姿がおもしろかったです。喜怒哀楽をほとんど出されない中にあって、顔を埋めるほど笑っておられる姿を見たのは初めてで衝撃を受けました。湯前のトークショーでカメラを向けた藤田先生にピースサインで応えた(YouTube)とき以来の衝撃です。いやあ、いいもの見せていただきました。久米田先生知っていますか、先生の作品を読んでいるときの私はいつもこんな感じなのですよ。

サムネイル画像
口に右手を当てて顔を埋める久米田先生（TV 画面のスクリーンショット）オリジナル画像
]]> リンクの下線表示はカスタマイズすべきか tag:blog.w0s.jp,2025-03-19:/734 2025-03-19T04:05:25+09:00 <a href> によるリンクは UA スタイルシートによって下線が引かれますが、そのデフォルトの見た目がアクセシブルでないという話。

UX Collective の元記事に書かれているように、下線の付いたテキスト内リンクはコンテンツの読みやすさに悪影響を及ぼし、注意散漫になり得ることは確かに考慮すべきでしょう。そのうえで text-underline-offset や text-decoration-thickness、text-decoration-color プロパティを使って下線の圧を弱める手法が両記事で紹介されていますが、これの導入は慎重になるべきです。

というのも本件は下線リンクが存在するサイト（≒すべての Web サイト）で等しく問題になるものであり、制作者スタイルシートでサイト個別に工夫することが正しい解決方法とは思えないからです。元記事ではdyslexia-friendly（識字障害フレンドリー）との表現がされていますが、当事者がユーザースタイルシートを設定すれば済む話ではないでしょうか。もっともユーザースタイルシートの設定には CSS の知識が必要になるわけでして、ブラウザに「リンクの下線の圧を弱める」オプションを導入することを求めるほうが現実的でしょうか。

  • Firefox には「常にリンクに下線を付ける」オプションが存在するので、そんな感じのオプションを増やすことは充分考えられるでしょう。

もう一つの可能性としては text-decoration-skip-ink で前例があるように、後方互換性を犠牲にしてでもブラウザのデフォルトの動作が変更されることも考えられます。もしそうなった場合、制作者スタイルシートで工夫をしていたサイトよりも、むしろなにもしていない（圧倒的大多数の）サイトの方が良い感じになる逆転現象が起こりえます。

いずれにせよ、本件に限らず CSS を書く際はそれが制作者スタイルシートで設定すべきものなのかどうかを考える必要があるでしょう。本ブログではそのような考えのもと、以前からリンクの下線は text-decoration-thickness: from-font のみ設定するようにしており、それ以上のカスタマイズはあえて行っていません。text-underline-offset プロパティにキーワードでなく具体的な数値を設定するのもなんか嫌ですし【謎】

  • 念のため、制作者スタイルシートで下線のカスタマイズをするなと主張するものではありません。仮にブラウザのデフォルトスタイルが変わったり、新しい CSS プロパティが出現したりした場合にすぐに対応できる体制を整えているのであれば実験的にやってみることは否定しません。一方で受託によるサイト制作などで、一度サイトが出来上がったら手を離れるようなケースではサイト独自の工夫をすることには慎重であるべきです。
]]> iPad を買い換えたら軽量省スペースなキーボード選定に難儀 現行機種は Smart Keyboard に対応していないため、Smart Connector 接続タイプを諦めざるを得なかった話 tag:blog.w0s.jp,2025-03-16:/733 2025-03-16T12:05:02+09:00 先日、新型が出たタイミングで iPad を買い換えました。これまで使っていたのは2019年3月に発売された iPad Air (第3世代)(support.apple.com) で、キーボードは Smart Keyboard(web.archive.org) を常時取り付けていました。

薄型軽量で折り畳むと本体の保護にもなる優れもので、6年間持ち歩いたため外側はさすがに多少見栄えが悪くなってきたものの肝心のキーボード機能に損傷はまったくなく耐久性ともども満足していたものでした。Smart Connector 接続なのでマグネットでくっつけるだけで認識し、ペアリング操作や電池の心配をする必要もありません。

ところが現行世代の機種は Smart Keyboard および後継の Smart Keyboard Folio とも対応しておらず、トラックパッド付きの Magic Keyboard 系に統一されていることを知りました。これらは11インチ用でも重量が 600g 近くと、Smart Keyboard の2倍以上となっており、展開したときの奥行きも広さが求められるものとなっています。

テーブルに置いて使う時は良いのでしょうが、私の場合主たる使用箇所は公共交通機関での移動中（通勤電車内における膝の上）であるからして、省スペースと軽量であることは必須の要件なのです。困ったことに他社が販売しているケース付きキーボードもほとんどがトラックパット付きとなっていて、省スペースなものは Logicool が販売している SLIM FOLIO(www.logicool.co.jp) くらいしか見当たりません。これも背面にプラスティック製の板状保護があるためか重量は iPad (A16) 用で 449g と決して軽くはなく、残念ながら私の用途にベストマッチはしていません。

Smart Keyboard のようにトラックパッドなしの小型タイプで、重量も 200g 台の軽量なキーボードは世間に求められていないのでしょうか。まあ確かに通勤電車のロングシートでタブレット機器を操作している人はそれほど多くは見かけないですけど。というか同じ11インチなのだから旧製品との互換性を確保して欲しいですよ Apple さん……。

仕方がないので Smart Connector 接続のケース付きキーボードは諦め、Bluetooth 接続タイプを購入することにしました。Apple 純正だと Magic Keyboard (USB-C)(www.apple.com) があるのですが、同じくらいの大きさ、重量の製品が各社から販売されており、その中でも Anker ウルトラスリム Bluetooth ワイヤレスキーボード(www.ankerjapan.com) のデザインが気に入りました。価格も類似品の中ではおそらく最安値で、税込みわずか2,000円です。

Amazon で買う

唯一の難点は電源スイッチが裏面にあることで、これはエレコムの類似品（TK-FBP102）(www.elecom.co.jp)のように表側にある方が好みなのですが、致命的とまでは言えず許容範囲です。あと裏面は一部分のみ（電池収納まわり）が盛り上がっていて、持ち運びを考えるとこの厚みはデメリットとも言えるのですが、他社の類似品も同形状なので、これが許容できない方は Apple 純正品にするしかないでしょうね。

またいくら小型キーボードとは言えさすがに通勤電車で使うのは難しいと思うので、移動中は閲覧メインの使い方にして、文字入力はカフェなどテーブルのある場所に限定せざるを得なくなってしまいました。例えばイベントの参加レポート記事や映画館で見た新作映画の長文感想を帰宅の移動中に書き上げるといったことは無理になってしまいそうです。

ところでこれまでの Smart Keyboard はキーボード機能のみならずスタンド機能と本体保護を兼ねていたわけでして、それらの代替としてケースの購入にも迫られました。こういう小物はエレコムが強くて、スタンド機能のあるものは iPad(A16) 用(www.elecom.co.jp)で20種類近くも用意されているのですが、実売価格は最安のものでも2,000円台後半なのですね。キーボードよりケースの方が高いとは……。いや Anker のキーボードが安すぎるだけなのかもしれませんが。

]]> `headingoffset` と `headingreset` 属性による見出しレベルの調整 アウトラインアルゴリズム亡き今、HTML Living Standard に見出しレベルを調整する機能が盛り込まれようとしています。 tag:blog.w0s.jp,2025-03-14:/732 2025-03-14T21:09:24+09:00 HTML にグローバル属性として headingoffset と headingreset 属性を追加する議論が進んでいます。これが実現すれば見出し要素だけでなく、その祖先要素でも見出しレベルを調整できることになります。

一方、そうなると現状のように <hn> = 見出しレベル N とは限らなくなり、「見出しレベル N の要素を選択する」ことが困難になるため、CSS 側でも :heading および :heading() 疑似クラスの導入が画策されています。

  • これらの PR は2025年3月14日現在マージされておらず、内容は変更される可能性があります。とくに headingreset の属性名は混乱を引き起こす懸念も出ており、名称が変わるかもしれません。

現行の見出しレベルの問題点

§

現行の HTML では <h1>～<h6> 要素を使って見出しレベルが決定されます。

<body> <h1>見出しレベル 1</h1> <h2>見出しレベル 2</h2> <h3>見出しレベル 3</h3> <h2>見出しレベル 2</h2> </body>

しかしテンプレートエンジンやコンポーネント指向設計を採用したケースでは見出し要素の出力に条件分岐が必要になるなど、実装が複雑になってしまうことがあります。

<body> <h1>見出しレベル 1</h1> <%- include('component/XXX.html', { headingLevelStart: 2 } ) -%> <section> <h2>見出しレベル 2</h2> <%- include('component/XXX.html', { headingLevelStart: 3 } ) -%> </section> </body>
<!-- component/XXX.html --> <section> <!-- 見出しが出現するごとに条件分岐が必要 --> <%_ if (headingLevelStart === 2) { _%> <h2>コンポーネントの最上位見出し</h2> <%_ } else if (headingLevel === 3) { _%> <h3>コンポーネントの最上位見出し</h3> <%_ } _%> <p>...</p> </section>

このような状況に対して、HTML5 の当初の仕様ではアウトラインアルゴリズムによってセクショニングコンテンツと <h1> 要素だけを使ってアウトラインを作ることができるとされていたのですが、ブラウザや支援技術のサポートが行われていなかったため、長い議論の末2022年7月にアウトラインアルゴリズムが削除されることで一応の決着が付いた次第です。

一方で前述のとおり、HTML4 時代のように <h1>～<h6> の要素名によってのみ見出しレベルが決定される現状は不便であり、アウトラインアルゴリズムとは別の手法で解決を図る議論が以前から行われています。

headingoffset と headingreset 属性の提案

§

今回の Pull Request の元になった Issue(GitHub) が立てられた当初の時点（2019年）では見出しレベルの絶対値を指定する headinglevelstart 属性が提案されていました。特徴的なのはネストによる継承をしない方針とされていたことで[1]、これは <ol start> と同じ挙動と言えます。

<body> <h1>見出しレベル 1</h1> <div headinglevelstart="2"> <h1>見出しレベル 2</h1> <h2>見出しレベル 3</h2> <div headinglevelstart="1"> <!-- ネストされていても継承しない --> <h1>見出しレベル 1</h1> <h2>見出しレベル 2</h2> </div> </div> </body>

しかし議論が進む中で絶対値指定でなく相対値指定にすることとなり、属性名も headingoffset へ変更されました。また同時に見出しレベルをリセットする headingreset 属性（真偽属性）も追加されています。

<body> <h1>見出しレベル 1</h1> <h1 headingoffset="1">見出しレベル 2（要素名の 1 + headingoffset 属性値 1 = 2）</h1> <div headingoffset="1"> <h1>見出しレベル 2（要素名の 1 + headingoffset 属性値 1 = 2）</h1> <h2>見出しレベル 3（要素名の 2 + headingoffset 属性値 1 = 3）</h2> <div headinglevelstart="2"> <h1>見出しレベル 4（要素名の 1 + headingoffset 属性値の小計 3 = 4）</h1> <h2>見出しレベル 5（要素名の 2 + headingoffset 属性値の小計 3 = 4）</h2> </div> <div headingreset> <h1>見出しレベル 1</h1> </div> </div> </body>

以下、特殊な例を提示します。

<body> <div headingoffset="10"> <h1>見出しレベル 9（レベルは 9 より大きくはならない）</h1> </div> <div headingoffset="-1"> <h1>見出しレベル 1（headingoffset に指定できるのは正の整数のみ、負の値やその他無効な値が指定された場合は 0 の扱いになる）</h1> </div> <div headingoffset="2"> <h1 aria-level="3">見出しレベル 3（見出し要素の数字や headingoffset 属性値に関わらず aria-level が優先される）</h1> </div> <div headingoffset="2"> <dialog id="modal-dialog"> <h1>見出しレベル 1（showModal() されたダイアログは offset しない）</h1> </dialog> <script> document.querySelector('#modal-dialog').showModal(); </script> </div> </body>

冒頭の注釈にも記したとおり、まだ議論は進行中であり今後内容や属性名が変更される可能性は充分に考えられるのですが、すでに Chromium には実装されており(GitHub)、Chrome canary 136.0.7067.2 で挙動を確認できます。

サムネイル画像
Chrome canary の DevTools で body > div[headingoffset=1] > h2 な見出し要素を選択した様子。アクセシビリティパネルの計算済みプロパティにはレベル: 3と表示されている。オリジナル画像

脚注

]]> Web Storage API で発生しうる例外（`DOMException`）を ESLint で検証する `sessionStorage` や `localStorage` を使う際は必ず `try`...`catch` で囲うべしという話（N回目） tag:blog.w0s.jp,2025-02-27:/731 2025-02-27T20:51:36+09:00 Web Storage API はその使い方やユーザー環境によって例外が発生し得ます。

例えば以下のように 5MB を超えるデータを setItem() しようとすると QuotaExceededError が発生します。

try { const storageKey = 'foo'; sessionStorage.clear(); sessionStorage.setItem(storageKey, 'x'.repeat(5242880 - storageKey.length + 1)); // 5MB を超えるデータをセット } catch (e) { if (e instanceof DOMException) { console.warn(e.name); // `QuotaExceededError`（ただし Cookie がブロックされている場合は `SecurityError`）  } }

ブラウザの設定で Cookie をブロックしている場合はプロパティやメソッドを呼び出さずとも常に SecurityError が発生します。

try { sessionStorage; } catch (e) { if (e instanceof DOMException) { console.warn(e.name); // `SecurityError` } }

これらのことは Web storage API の仕様書(WHATWG)に書かれているのはもちろん、MDN の解説でも触れられているのですが、どういうわけか世の中には sessionStorage や localStorage を try...catch で囲っていない、怖いもの知らずなコードがそれなりに存在するのです。

const foo = sessionStorage.getItem('foo'); doSomething(); // ブラウザの設定で Cookie をブロックしている場合、この関数は実行されない

実際のサイトで散見され始めたのは2018年頃で、当時 Web Storage API を使う際は Cookie 無効環境も考慮しようという記事を書いたのですが、その後は某著名フレームワークの普及もあってレイアウトが崩れる（CSS が部分的にしか適用されない）どころか情報がまったく閲覧できないサイトが増加してしまいました。

そのような流れに対して、いずれ ESLint などに検証ルールが追加されるだろうと静観していたのですが、一向にその気配がありません。似た思想を持つプラグインとして eslint-plugin-try-catch-failsafe(GitHub) があるのですが、これは JSON.parse() と new URL() のみが対象であり、Storage のルールは存在しません。

  • URL は canParse() メソッド(developer.mozilla.org)が実用可能になってきているので、try...catch で囲わなければならないケースは今後減るでしょう。

ということで今さらではあるのですが、さくっとプラグインを作ってみました。

本ブログでも自分用の ESLint 設定ファイル(GitHub)に本日から導入しています。

]]> 【更新】伊豆急行8000系「さくらリレー号」「河津さくら号」の変遷 「河津桜まつり」時期に運転される臨時快速は停車駅や運転区間が毎年のように変わっているため、運転データを分かる範囲でまとめてみました。 tag:blog.w0s.jp,2025-02-20:/604 2025-02-20T14:58:35+09:00 今年も河津桜の時期がやってきました。すなわち、伊豆急行線に8000系の臨時快速列車が走る季節です。

河津桜まつり(www.kawazuzakura.net)が開催される期間を中心に1往復が運転される全車自由席の臨時快速列車は、2017年以降は「河津さくら号」として運転されていましたが、今年は「河津桜号」と微妙に列車名が変わっています。

  • ただし、「JR時刻表」「JTB時刻表」「鉄道ダイヤ情報」といった各種鉄道情報誌には例年どおり「河津さくら号」なので、公式サイトの記述が間違っている可能性もあります。

昨年（2019年）(PDF)(camel3.com)は8000系の「河津さくら号」とは別に、JRの251系を使用した「河津桜号」が伊豆急下田15:35→伊東16:47、その折り返しとして「河津夜桜号」が伊東17:12→伊豆急下田18:12 のダイヤで運転され、それ以前にもJR直通の特急列車で「河津桜号」が運転された年もあったようですが、今年の臨時快速はそれらの列車名を引き継いだことになります。使用車種は発表されていませんが、伊豆高原発着でホーム長の短い今井浜海岸駅にも停車することから、（251系ではなく）例年どおり8000系が使われるものと思われます。

さて、この臨時快速に初めて8000系が充当されたのは2007年で、当時の運転区間は伊東→伊豆急下田と河津→伊豆高原の1往復、途中停車駅は伊豆高原、伊豆熱川、伊豆稲取、今井浜海岸、河津、蓮台寺で、このほかに運転停車もありました。列車名は「快速さくらリレー号」で、列車名自体に「快速」が含まれていたのが特徴でした[1]。

2008年、2009年は運転日とダイヤが若干変わったのみでしたが、2010年からは毎年のように注目すべき変化が起こっています。

  • 2010年: 蓮台寺駅が通過駅に変更（※2009年3月改正で特急「踊り子」全列車の停車取り止め）
  • 2011年: 下り列車が河津止まりに変更
  • 2013年: 運転なし(?)
  • 2014年: 運転時刻が大幅に変更、下り列車が午後の運転となり伊豆高原始発に変更、今井浜海岸駅が通過駅に変更（この年のみ）
  • 2015年: 運転なし(?)
  • 2016年: 今井浜海岸駅がふたたび停車駅に変更
  • 2017年: 列車名が「河津さくら号」に変更、下り列車が午前の運転に戻り（2月19日、26日のみ午後）、ふたたび伊豆急下田行きに変更
  • 2018年: 蓮台寺駅が8年ぶりに停車駅に変更（「踊り子」など特急列車は引き続き通過）、下り列車は日程により午前または午後の運転
  • 2019年: 上り列車が伊豆急下田始発に変更、下り列車は午後の運転（2月21日のみ午前）
  • 2020年: 列車名が「河津桜号」に変更、下り列車は全日午後の運転

より詳細な運転データを下表にまとめます。

2023年2月10日追記2023年の運転情報が発表(PDF)(camel3.com)されたので表に追記しました。

2024年2月7日追記2024年の運転情報が発表(PDF)(camel3.com)されたので表に追記しました。

2025年2月20日追記2025年の運転情報が発表(PDF)(camel3.com)されていたので表に追記しました。

年 河津桜まつり期間 運転日 列車名 旅客扱い区間 途中停車駅（運転停車を除く）
2007年 2月10日〜3月10日 2月10日〜28日 さくらリレー号 伊東→伊豆急下田、河津→伊豆高原 伊豆高原、伊豆熱川、伊豆稲取、今井浜海岸、河津、蓮台寺
2008年 2月9日〜3月10日 2月9〜29日（〜3月10日?） さくらリレー号 〃 〃
2009年 2月7日〜3月10日 2月7日〜3月10日 さくらリレー号 〃 〃
2010年 2月6日〜3月10日 2月6〜28日（3月の実績不明） さくらリレー号 〃 伊豆高原、伊豆熱川、伊豆稲取、今井浜海岸、河津
2011年 2月5日〜3月10日 2月11〜13日、19〜28日 さくらリレー号 伊東→河津、河津→伊豆高原 伊豆高原、伊豆熱川、伊豆稲取、今井浜海岸
2012年 2月5日〜3月10日 2月11〜12日、18〜29日、3月10〜11日 さくらリレー号 〃 〃
2013年 2月5日〜3月10日 運転なし(?)
2014年 2月5日〜3月10日 2月15〜28日（3月の実績不明） さくらリレー号 伊豆高原→河津、河津→伊豆高原 伊豆熱川、伊豆稲取
2015年 2月10日〜3月10日 運転なし(?)
2016年 2月10日〜3月10日 不明 さくらリレー号 伊豆高原→河津、河津(?)→伊豆高原 不明
2017年 2月10日〜3月10日 2月11日〜3月10日 河津さくら号 伊豆高原→伊豆急下田、河津→伊豆高原 伊豆熱川、伊豆稲取、今井浜海岸、河津
2018年 2月10日〜3月10日 2月10日〜3月10日 河津さくら号 〃 伊豆熱川、伊豆稲取、今井浜海岸、河津、蓮台寺
2019年 2月10日〜3月10日 2月16日〜3月3日 河津さくら号 伊豆高原→伊豆急下田、伊豆急下田→伊豆高原 〃
2020年 2月10日〜3月10日 2月15日〜3月6日 河津さくら号（河津桜号?） 〃 〃
2021年 新型コロナのため中止 運転なし
2022年 2月1日〜2月28日 運転なし(?)
2023年 2月1日〜3月5日 2月11日〜2月28日 河津桜号 伊豆高原→伊豆急下田、河津→伊豆高原 伊豆熱川、伊豆稲取、今井浜海岸、河津、蓮台寺
2024年 2月1日〜2月29日 2月10日〜2月29日 河津桜号 伊豆高原→河津、河津→伊豆高原 伊豆熱川、伊豆稲取、今井浜海岸
2025年 2月1日〜3月9日 2月8日〜3月9日 河津桜号 〃 〃
  • 本表作成にあたっては、列車情報は伊豆急行公式サイト(www.izukyu.co.jp)、および「JR時刻表」「JTB時刻表」の各年2〜3月号を参照しました（2020年の運転日のみ「鉄道ダイヤ情報」より）。
  • 参考情報として記載した「河津桜まつり」の開催期間は河津町観光協会のサイト(www.kawazu-onsen.com)に掲載されたデータを情報源としています。ただし、2010年のみは同サイトのアーカイブでは確認できなかったため、旅行会社のブログなど複数の2次情報を元にしました。

2012年の運転のうち、3月10日〜11日は当時のニュースリリースによると下りのみの運転だったようです。この年は開花時期が遅れた影響で本来の「河津桜まつり」に続いて3月11日〜18日に「河津桜“春うらら”まつり」が行われることになったためイレギュラーな形になったのでしょう。上りは回送で運転されたものと思われますが、未確認です。

2013年と2015年は運転がなかったものと思われますが、疑問符を付けています。この臨時快速は伊豆急行のニュースリリースで運転が告知される年もありますが、リリースなしで運転されることもあります。また、まれに「JR時刻表」や「JTB時刻表」への掲載がされないこともあります（一例として2016年の運転はなぜか両時刻表への掲載がありませんでした）。そのため、「運転がなかった」ことを証明するのは困難なのです。

そして、2016年は上記のとおり全国時刻表への掲載がなく、目撃情報を頼りに情報をまとめたため、詳細な運転データが不明な状況です。

その他の年でも、2010年と2014年は2月28日までの運転としていますが、実際は3月以降も運転された可能性があります。例年、3月はJRグループのダイヤ改正が行われるため、「JR時刻表」、「JTB時刻表」の3月号では改正後のダイヤが掲載されることがあり、この場合、2月号に3月上旬（ダイヤ改正前）の運転の掲載がないと「3月上旬の運転がなかった」のか「2月号の時点では3月の運転計画が未定だったに過ぎない」のかの判断ができないためです。

また、一部200系や185系で運転されたケースもあるようですが、このあたりも詳細は把握していません。

脚注

  • 1.

    いつかの段階で「快速さくらリレー号」が「さくらリレー号」に改称されています。「JR時刻表」と「JTB時刻表」の表記を見ると、2007年は両者とも「快速さくらリレー号」ですが、2008年〜2011年は「JR時刻表」では「快速さくらリレー号」、「JTB時刻表」では「さくらリレー号」と異なっており、2012年には両者とも「さくらリレー号」になっています。このため、改称時期は2008年〜2012年のいずれかと思われますが、はっきりしたことは分かっていません。本記事では2007年運転分も含めて「さくらリレー号」で表記しています。 ↩ 戻る

]]> 【更新】`span`属性、`colspan`属性、`rowspan`属性の上限値、下限値 HTML で列や行をまたぐ `span` 属性、 `colspan` 属性、 `rowspan` 属性には上限値、下限値があります。仕様とブラウザ実装をまとめました。 tag:blog.w0s.jp,2025-02-13:/519 2025-02-13T10:34:42+09:00 colgroup 要素、 col 要素で列がまたがる数を指定する span 属性、および表のセルを結合するための colspan 属性、 rowspan 属性には上限値、下限値があります。

HTML仕様

§

まずは仕様を確認してみます。

HTML Living Standard

§

colgroup 要素、 col 要素の span 属性はa valid non-negative integer greater than zero and less than or equal to 1000とされています。「0より大きく1000以下の有効な非負整数」、要するに 1 〜 1000 の整数ですね。

td 要素、 th 要素の colspan 属性は span 属性と同じ一方、 rowspan 属性はa valid non-negative integer less than or equal to 65534と、他とは少し違う定義です。上限値が大きいだけでなく 0 が許容されており、その際は「行グループの残りすべての行にまたがる」とされています。すなわち、

<tbody> <tr> <th rowspan="0">見出しセル</th><td>セル1</td> </tr> <tr> <td>セル2</td> </tr> </tbody> <tbody> <tr> <td>セル3</td> </tr> </tbody>

のような表の場合、見出しセルは2列にまたがる（rowspan="2" を指定したのと同じ）ことが期待されます。これは HTML4 時代から規定されていることなのですが、残念ながら Firefox しか対応していません。

ちなみに HTML4 では同様に colspan="0" も認められており、以前の Firefox は対応していましたが、現在では仕様、実装ともに消え去りました。

HTML 5.2

§

span 属性はlimited to only non-negative numbers greater than zero、 colspan 属性はa valid non-negative integer greater than zeroと書き方が少々異なりますが、意味的にはどちらも「0より大きい有効な非負整数」で、上限値の記述はありません。

rowspan 属性もa valid non-negative integerで、上限値がないこと以外は Living Standard と同様です。

ブラウザの実装

§

いくつかのパターンをテストしてみました。

2017年6月時点

§

ブラウザ <col(group)? span=1001> <td colspan=1001> <td rowspan=0>
Chrome 59 ✘ 1001列を認識 ✘ 1001列を認識 ✘ rowspan="1" と同じ
Safari 10 ✘ 1001列を認識 ✘ 1001列を認識 ✘ rowspan="1" と同じ
Firefox 54 ✔ span="1000" と同じ ✘ colspan="1" と同じ ✔ 仕様どおり
Firefox 55(β) ✔ span="1000" と同じ ✔ colspan="1000" と同じ ✔ 仕様どおり
Edge 40 ✘ span="1" と同じ ✘ colspan="1" と同じ ✘ rowspan="1" と同じ
IE 11 ✘ span="1" と同じ ✘ colspan="1" と同じ ✘ rowspan="1" と同じ

2019年11月12日追記いつの間にか Chrome は rowspan=0 に対応していました（バージョン78で確認）。 Safari 13, Edge 44 は相変わらず未対応です。

2021年3月時点

§

2021年3月18日追記現在の最新状況を下表に記します。 Safari 14 は未だ rowspan="0" 未対応です。

ブラウザ <col(group)? span=1001> <td colspan=1001> <td rowspan=0>
Chrome 89 ✔ span="1000" と同じ ✔ colspan="1000" と同じ ✔ 仕様どおり
Safari 14 ✔ span="1000" と同じ ✔ colspan="1000" と同じ ✘ rowspan="1" と同じ
Firefox 86 ✔ span="1000" と同じ ✔ colspan="1000" と同じ ✔ 仕様どおり

2025年2月13日追記Release Notes for Safari Technology Preview 213(webkit.org)によると、Safari もようやく rowspan=0 に対応するようです。この日が来るまで長かった……。

]]> Report URI サービスの有料化に伴い CSP レポートのエンドポイントを自作 tag:blog.w0s.jp,2025-01-22:/730 2025-01-22T19:51:43+09:00 当サイトでは Content Security Policy (CSP) のレポート収集に Report URI(report-uri.com) のサービスを長年使ってきたのですが、Report URI の作成者のブログ記事 Report URI: Simplifying pricing and changes to free accounts(scotthelme.co.uk) にあるように2025年2月1日をもって無料プランが終了することになりました。

無料プラン終了そのものに対しては記事にあるようにやむを得ないことであり、現行の無料ユーザー向けに格安プランが用意されるといった対応もなされているためその運営判断に不満はないのですが、いかんせん私自身がこの個人サイトの CSP レポートを普段はほとんど活用していないため、月額 9.99 ドルといえども負担は厳しいと思った次第です。そもそもユーザー情報の保管とか一切していない当サイトに CSP を設定しているのはセキュリティ施策というよりは単なる技術的興味からのことであり、これを機に CSP ヘッダーを設定するだけでなくレポート収集のエンドポイントも自作しようと考えた次第です。

ところで CSP のレポートに使われるディレクティブや Reporting API に関係する HTTP ヘッダーはこれまで何回か仕様が大きく変わっており、送信される JSON 形式も変化しています。またブラウザによってどの時点の仕様を実装しているかに差異があったり、ブラウザの設定（アドオン）によってはサイト制作側の意図しないエラーがレポートされたりするなど状況は複雑なため、最新仕様を見るだけではなく実際に送られてくるエラーを見ながらの調整が必要でした。

この記事で書くこと
ブラウザごとの CSP レポートの JSON 形式の違い
ブラウザのアドオンなどによる変わったレポートへの対処
この記事で書かないこと
CSP の基礎的な解説
CSP や Reporting API 仕様の変遷（ざっくりした流れには触れるものの詳細には踏み入らない）
蓄積されたエラーレポートの活用方法
Reporting API（v0）で定められていた Report-To ヘッダー（今となっては考慮する必要がないため）

ソースコード

§

今回作成したエンドポイントのソースコードは report.w0s.jp(GitHub) で公開しており、主要な処理は /node/src/controller/csp.ts(GitHub) に書かれています。

CSP 関連のレスポンスヘッダー

§

CSP レポートを送るためには Content-Security-Policy ないし Content-Security-Policy-Report-Only ヘッダーに専用のディレクティブを指定する必要があります。これはもともと CSP 専用の report-uri ディレクティブ(developer.mozilla.org)であったものが、CSP 以外を含めた様々なレポートに対応した Reporting API を利用するように変更され、今は report-to ディレクティブ(developer.mozilla.org) と Reporting-Endpoints ヘッダー(developer.mozilla.org)を組み合わせる方式となっています。

Chrome と Safari は現行仕様に対応しているのですが、Firefox は最新の 136 Nightly においても古い report-uri ディレクティブしかサポートしていないため、実際は両方を指定する必要があります。

Content-Security-Policy: default-src 'self'; report-uri https://example.com/endpoint; report-to csp Reporting-Endpoints: csp="https://example.com/endpoint"

なお Reporting API に対応したブラウザであっても report-uri ディレクティブのサポートを取り止めたわけではないため、たとえ report-to ディレクティブを書かなくてもレポートの送信自体は行われます。ただし report-uri ディレクティブではレポートが即時配信されるのに対し、Reporting API ではレポートのリストがいったんキューに入れられ、ブラウザが送信タイミングを制御することとされている違いがあります[1]。すなわち、とくに複数のレポートが送信される際におけるパフォーマンス向上のメリットがあるので、多少レスポンスヘッダーが長くなるにせよ最新仕様へ準拠したほうがよいでしょう。

3種類の JSON 形式

§

CSP ヘッダーは前述のとおり新旧2種類に対応した記述を行ったのですが、実際にブラウザが送信する JSON 形式は Firefox, Safari, Chrome でそれぞれ異なるため、エンドポイント側では3種類のフォーマットに対応する必要があります。

Firefox 136（report-uri ディレクティブ）

§

Firefox は report-to ディレクティブに対応していないため、report-uri ディレクティブで指定したエンドポイントに JSON が POST されます。

Content-Type は application/csp-report であり、CSP Level 3 仕様の 5.3. Obtain the deprecated serialization of violation(W3C) で JSON 形式が規定されています。便宜的に TypeScript フォーマットで表現するとこうなります。

{ 'csp-report': { 'document-uri': string; referrer?: string; 'blocked-uri'?: string; 'effective-directive': string; 'violated-directive': string; // `effective-directive` の旧名称（同じ値） 'original-policy': string; disposition?: 'enforce' | 'report'; 'status-code': number; 'script-sample'?: string; 'source-file'?: string; 'line-number'?: number; 'column-number'?: number; }; }

なお、仕様では source-file, line-number, column-number の3つのプロパティのみが省略されうるとあるのですが、実際に Firefox から送信されてくるデータを見ると他のプロパティも存在しないケースがあるため、上記は現実の状況を踏まえたものとしています。

Safari 18.2（report-to ディレクティブ + Reporting-Endpoints ヘッダー）

§

Safari は Reporting API に対応しているのですが、送られる JSON 形式はやや古い仕様のものとなっています。詳しくは追っていないのですが、2018年9月25日版の 5.1. Interface ReportingObserver(W3C) にある Report インターフェースと同様に見えます（実際に Safari がその時期の仕様を元に実装したのかどうかは未確認です）。

同様に TypeScript フォーマットで表現するとこうなります。

{ type: `csp-violation`; url: string; body: { documentURL: string; referrer: string; blockedURL: string; effectiveDirective: string; originalPolicy: string; sourceFile: string; sample: string; disposition: "enforce" | "report"; statusCode: number; lineNumber: number; columnNumber: number; } }

また Reporting API では Content-Type は application/reports+json と定められている(W3C)のですが、Safari は Firefox と同じく application/csp-report で送ってくることに注意する必要があります。

Chrome（report-to ディレクティブ + Reporting-Endpoints ヘッダー）

§

Chrome は Reporting API の最新仕様に準拠しています。

Content-Type は application/reports+json であり、Reporting API 仕様の 2.4. Serialize Reports(W3C) および CSP Level 3 仕様の 5. Reporting(W3C) で規定されているとおりの JSON が送られます。TypeScript フォーマットで表現するとこうなります。

[ { age: number; type: string; url: string; user_agent: string; body: { documentURL: string; referrer?: string; blockedURL?: string; effectiveDirective: string; originalPolicy: string; sourceFile?: string; sample?: string; disposition: 'enforce' | 'report'; statusCode: number; lineNumber?: number; columnNumber?: number; }; } ]

Safari と似ているものの、配列形式となっているのが特徴です。実際には以下のように CSP 以外のレポートも含まれるケースがあるので、必要に応じてフィルタリング処理を掛けましょう。

[ { "age": 0, "type": "csp-violation", "url": "http://example.com/", "user_agent": "Mozilla/5.0 ...", "body": { ... } }, { "age": 999, "type": "another-type", "url": "http://example.com/", "user_agent": "Mozilla/5.0 ...", "body": { ... } } ]

ブラウザのアドオンにより発生するエラーレポート

§

このように Web サイト側では CSP ヘッダーのディレクティブを2種類記述し、エンドポイント側では JSON 形式を3種類受け入れるように対応し、あとは送られてきたデータをデータベース等に保存する処理を作れば最低限の機能としては完成します。

しかしそれだけでは意図しないエラーレポートが大量に蓄積されてしまうため、実際に送られてきたデータを見ながらの調整が必要となります。以下に当サイトにおいて対応したものを記載します。あくまで当サイトで頻出したエラーレポートであり、他のサイトでは状況が異なる可能性はあるので参考程度に……。

  • blockedURL: 'data', effectiveDirective: 'media-src'
    • 当サイトでは画像ファイルなどに "data" URL スキームは使用していない（HTTP/1.1 時代は小さなアイコンに使用していたこともあった）ため、ユーザー環境に起因して発生するエラーと言える
    • Firefox にアドオン NoScript(noscript.net)を入れていると発生することを確認した
    • NoScript が不要になる世界が理想だが、世の中には「Cookie 無効かつスクリプト有効」の設定では閲覧できないサイトがあり、スクリプト設定を無効にすることではじめて閲覧可能になる状況が存在するので、ドメインごとにスクリプト設定を切り換えられるアドオンがないと生きていけない
    • media-src に data: を追加して対応した
  • blockedURL: 'inline', effectiveDirective: 'script-src-elem', sourceFile: 'moz-extension'
    • 当サイトではインライン JavaScript(developer.mozilla.org) は使用していないため、これもユーザー環境に起因して発生するエラーと言える
    • Firefox にアドオン Violentmonkey(violentmonkey.github.io)を入れていると発生することを確認した
    • script-src-elem に 'unsafe-inline' を追加して対応した
    • セキュリティ観点では 'unsafe-inline' の指定は避けるべきとされているが、一方で当サイトのようにそこまでセンシティブでないサイトではユーザースタイルシートやユーザースクリプトの活用を妨げたくはないため、リスクを踏まえたうえで許容する
  • blockedURL: 'trusted-types-policy', effectiveDirective: 'trusted-types', sourceFile: 'chrome-extension', sample: 'dompurify'
    • Chrome のアドオン?
    • sample の値からしてセキュリティ関係のアドオンだろうが詳細は把握していない
    • そこそこ頻繁にレポート発生するので著名なアドオンなのだろうか
    • trusted-types に dompurify を追加して対応した

その他のエラーレポート

§

対応するほどの頻度ではないものの、ちょっと変わったエラーレポートをいくつか紹介します。

  • *-src-elem 未対応環境
    • 当サイトではスタイルシートとスクリプトの設定は script-src-elem, style-src-elem を記述しているが、これらは CSP Level 3 で登場した後発のディレクティブであり、古いブラウザは対応していない
    • フォールバックとして script-src, style-src も指定すれば解消するかもしれないが、ただでさえ長大になりがちなヘッダー値をこれ以上長くしたくない（本当に解消するのか検証もしていない）
  • effectiveDirective: 'fenced-frame-src'
    • <fencedframe> 要素(wicg.github.io)に関連するディレクティブだが、当サイトではその要素は使っていない
    • リクエストに blockedURL や sample が付いていないので詳細はよく分からない
  • effectiveDirective: 'trusted-types', sample: 'default2'
    • なんだその投げやりな名前は

脚注

]]> 駿遠電気の電化当初の車両 —主に玉川電気鉄道からの譲受について— tag:blog.w0s.jp,2025-01-12:/729 2025-01-12T21:27:41+09:00 現在の静岡鉄道静岡清水線は駿遠電気時代の1920(大正9)年に改軌&電化が行われているのですが、当時の資料が断片的にしか残っておらず電化当初の車両はその全容がいまだ判明していません。しかしここ10年ほどで複数の研究記事が発表され、また図書館資料のデジタル化が進んだことで調査の障壁も低くなってきており、徐々に真相に近づいてきている感はあります。

昨年（2024年）、私は玉川電気鉄道（のちの東急玉川線）の開通当初の車両に関する資料調査を行い、その成果を公文書と統計資料でたどる玉川電気鉄道狭軌時代の車両(Amazon)として発表しました。その際に車両譲渡先である駿遠電気と上田温泉電軌（現：上田電鉄）の調査も行ったのですが、あくまで玉川電気鉄道の本であるため取り入れなかった部分もあります。そこで本記事では改めて駿遠電気側の視点で玉電譲渡車の動きを中心にまとめてみることにしました。なおそのような経緯があるため、本記事の内容は拙著の「第6章　改軌に伴う譲渡、改造」と重複する部分が多いのですが、一方で本記事単独でお読みいただけるように構成しております。

Amazon で買う

改軌に伴う車両の譲受

§

駿遠電気の改軌に伴う車両認可の書類そのものは発見されていないのすが、その前段階である工事施行認可申請書（1920(大正9)年3月4日付）(www.digital.archives.go.jp)は国立公文書館に保管されており、改軌半年前の時点で下表の車両が計画されていたことが分かります。

車種 両数 記号番号 自重 定員／積載容積 電動機 備考
電動客車 10両 1～10 6t 40人 37.5㏋×2 玉川電気鉄道より譲受
付随客車 3両 1～3 4t 40人 玉川電気鉄道より譲受
電動貨車（無蓋車） 2両 デカ1～2 5t 4t 37.5㏋×2 台車は玉川電気鉄道より譲受
付随貨車（無蓋車） 10両 ムカ1～10 3.5t 5t

このように旅客車は玉川電気鉄道からの譲受車が予定されていたのですが、これは同時期に玉電が 1,067mm → 1,372mm へ改軌するのに伴い不要となる狭軌車両を譲り受けるつもりであったものとなります。また電動貨車は台車のみ譲受品を使用とあるのですが、玉川電気鉄道では予備の電機品2台分を保有しており、これも改軌で不要になるのでそれを活用するつもりだったものと思われます。具体的には改軌前の1918(大正7)年頃に車両増備のため台車と主電動機、ブレーキ装置をアメリカより輸入したものの[1]、1919(大正8)年に到着した際には改軌が迫っていたためか活用されることなく予備品とされたもの[2]となります。

しかしながら駿遠電気の改軌は1920(大正9)年8月2日に実施されたのに対し、玉川電気鉄道は同年8月21日に暫定単線化ののち、9月3日に改軌が行われています。このため玉川電気鉄道にとっては改軌の1か月以上前に当時の在籍車22両のうち13両もの車両を放出するのは無理があったであろうことは容易に想像が付きます。そこで駿遠電気では美濃電気軌道（のちの名古屋鉄道美濃町線など）からも旅客車両を譲り受けることで、玉川電気鉄道からの譲受タイミングと車両数を調整することになりました。駿遠電気の取締役会で美濃電気軌道からの購入が承認されたのが改軌の2週間前にあたる7月18日とのことですから[3]、ギリギリのスケジュールだったのでしょう。

このような経緯を経て、旅客車は美濃電気軌道と玉川電気鉄道からの譲受、貨車は新造（電動貨車の台車のみ玉川電気鉄道から譲受の可能性）にて改軌&電化を迎えることとなります。

開通式当日の車両数

§

駿遠電気の開通式典を取材した地元紙の取材記事では、開通式に株主用として10, 11, 12号、一般客用に14号が運転されたことが記されています。これは静岡民友新聞（現：静岡新聞）の1920(大正9)年8月4日の3面に掲載された「電車開通と清水驛」の記事で、式典の様子はもちろんのこと在籍車両数、それも貨車の情報まで報告されており、年度ごとの統計データでは分からない「開業初日の車両数」を記録した貴重なものとなっています。

尙ほ同電車は現在電動客車四臺と附随客車二臺及び豫備として電動客車二臺を運轉せるが豫定は五臺を運轉し静岡發朝四時十六分よりとし二十六分毎に發車する筈なるも當分は都合により時間を延ばすやも計られず

(中略)

客車は近々更らに二三臺到着する由にて貨車は無蓋十臺、有蓋五臺電動貨車二臺なりと

静岡民友新聞 1920(大正9)年8月4日　3面「電車開通と清水驛」

このうち改軌の同年に撮影されたとする10号車の写真が『写真で綴る静岡鉄道70年の歩み』（静岡鉄道　1989年）や『懐かしのアルバム　静岡県鉄道写真集』（山本義彦　1993年）(Amazon)に掲載されており、Brill 21E 型と見られる台車、10枚の側面窓、そしてなによりバッファーを装備している特徴からこれは玉川電気鉄道からの譲受車と思われます。一方、近年になって12号車が写り込んだ絵はがきが発見され、台車の形態などからこちらは美濃電気軌道の譲受車と推察されています[4]。（ともに短期間での改番が行われなかった前提）

これらの情報をまとめると、開通式の日にはすでに玉川電気鉄道からの譲受車が一部到着しており、しかしながら所定数は揃っておらず当面の間は運行間隔を調整（減便）する可能性があったことが分かります。そして電動客車の内訳ですが、美濃電気軌道からは D13～D17 の5両を譲り受けたというのが定説であることから[5]、開通式当日の玉電譲受車は10号車の1両と付随車2両の計3両だったのではないかと思われます。

すなわち以下のように考えられます。

車種 譲受元 開通式当日の両数 年度末の両数 駿遠電気での車号（推定）
電動客車 玉川電気鉄道 1両 6両 5～10
電動客車 美濃電気軌道 5両 5両 11～15
付随客車 玉川電気鉄道 2両 3両 不明
  • 美濃電気軌道からの譲受車は開通式までに5両をまとめて用意できた前提で作成した。美濃車が4両以下で玉電車が2両以上であった可能性も否定しきれない。
  • 玉川電気鉄道から譲り受けた車両のうち電動車の両数には諸説あるが、鉄道省鉄道統計資料の大正9年度版「車輛現在表」(dl.ndl.go.jp)には客車総数が14両とあるため、付随車と美濃電気軌道譲受車の両数を差し引いた6両と考える。

上田温泉電軌への譲渡

§

定説では駿遠電気の電動客車のうち2両はほどなく上田温泉電軌（現：上田電鉄）へ譲渡されたとされています。この説の発端はおそらく鉄道ピクトリアル誌に掲載された「私鉄車両めぐり」の記事で、1921(大正10)年6月の路線開通に際して同年中に電動客車9両を玉川電気鉄道より譲受、2両を駿遠電気から譲受、さらに付随客車4両を玉川電気鉄道より譲受したとされています[6]。

その記事における開通当初の電動車一覧表から重要なデータのみを抜粋します。

上田車号 製造時期 譲受時期 譲受元 旧車号
1 1907(明治40)年6月 1921(大正10)年6月 玉川電気鉄道 不明
2 〃 〃 〃 不明
3 1912(明治45)年6月 〃 〃 不明
4 〃 〃 〃 不明
5 1914(大正3)年9月 〃 〃 不明
6 1912(明治45)年6月 〃 〃 不明
7 〃 〃 〃 玉川15
8 1919(大正8)年10月 1921(大正10)年9月 〃 不明
9 1907(明治40)年6月 1921(大正10)年10月 〃 不明
10 〃 1921(大正10)年12月 駿遠電気 不明
11 〃 1921(大正10)年10月 〃 不明

しかしこのデータにはいくつか不自然な点が見られます。

  • 玉川電気鉄道の改軌から半年以上が経っているのにも関わらず、玉電から上田への譲渡は6月に7両、9月と10月に1両ずつと3回に分けて行われたことになっている。
  • 玉電狭軌時代の電動客車は開通当初の1907(明治40)年に10両が用意され、その後1912(明治45)年に2両、1914(大正3)年に3両が増備されているため、上表のように1912(明治45)年製が4両あるのは数が合わない。
  • 同様に1919(大正8)年製の車両は玉電には存在しない。

ところで駿遠電気の旅客車両数の変遷を「鉄道省鉄道統計資料」の「車輛現在表」でみると、大正9年度(dl.ndl.go.jp)は14両、定員計560人だったのが、大正10年度(dl.ndl.go.jp)には13両、定員計570人へと変化しています。その内訳は明記されていないものの、65人乗りボギー車2両が導入された一方で40人乗り四輪車3両が消えたとしか考えられません。また駿遠電気の営業報告書では1922(大正11)年10月時点の四輪電動客車の両数が8両となっていることから[7]、抜けた3両は付随客車ではなく電動客車であったことが分かります。よって駿遠電気から上田温泉電軌へ譲渡された車両は定説の2両ではなく3両と考えます。

これらの考察を元に、以下の仮説を立ててみます。

  • 上田温泉電軌6～7号の製造時期は5号車と同じ1914(大正3)年9月が正しい
  • 上田8号は玉電の予備台車に車体を取り付けて車両として完成させたのち譲渡された
  • 駿遠電気から上田温泉電軌へ譲渡された車両は3両である（上田9～11号）

このように仮定すると、開通と同時に導入された7両は玉川電気鉄道における製造年月順に上田の番号を付与されたことになり、あとは譲渡時期の順に 8, 9……と素直な付番が行われたと考えることができます。10号車の譲渡時期のみ不自然さが残りますが、何かしらのトラブルで遅延が発生したか、単なる書類上の記録ミスがあったか、といったところでしょうか。

一方でこの仮説だと玉川電気鉄道の電動客車15両のうち、駿遠電気に6両、上田温泉電軌に7両（予備台車活用の8号車分を除いた両数）が譲渡されたものの、残る2両分の行方が分からないことになってしまいます。もともと駿遠電気では10両を譲り受ける予定が土壇場で変更になったため、玉川電気鉄道にとっては譲渡先が見つからず廃車となった可能性も充分に考えられますし、あるいは駿遠電気の電動貨車に活用されたとする考察もあります[8]。上田温泉電軌では予備台車に新製車体を組み合わせた可能性がある一方で、既存の完成車の車体を破棄をしたことになるため、そのような回りくどいことをするのかという疑問が残る一方、木造車体の時代なので状態の悪い車体を破棄する事例は存在し、玉川電気鉄道にとっては新製から最長13年しか経っていないとはいえあり得ないことではないとも思います。この点については自分の中でも納得のゆく結論が出ていないので、さらなる考察を見てみたいものです。

脚注

  • 1.

    玉川電気鉄道の「第30期　事業報告書」（1917(大正6)年12月～翌年5月）より ↩ 戻る

  • 2.

    玉川電気鉄道の「第32期　事業報告書」（1918(大正7)年12月～翌年5月）より ↩ 戻る

  • 3.

    RAILFAN 2002年9月号 No.599「駿遠電気の車両の謎」（築地成一郎）p.12 より ↩ 戻る

  • 4.

    鉄道史料 2016年7月号 No.149「駿遠電気の創業期の車両の解明にむけて　訂正」（阿部一紀）pp.57–58 より ↩ 戻る

  • 5.

    『RM LIBRARY 129 名鉄岐阜線の電車—美濃電の終焉—(上)』（清水武　2010年）p.14 より ↩ 戻る

  • 6.

    鉄道ピクトリアル 1964年11月号 No.164「私鉄車両めぐり〔59〕上田丸子電鉄(終)」（小林宇一郎）pp.60–61 より ↩ 戻る

  • 7.

    駿遠電気の「第7回　営業及決算報告書」（1922(大正11)年5月～10月）より ↩ 戻る

  • 8.

    『玉川電気鉄道狭軌時代の車両と駿遠電気初期の車両について』（車歴研究会　2016年、コミケット頒布）p.103 より ↩ 戻る

]]> 荻原俊夫氏の講演「東急の車両設計に携わって」を聞いてきた tag:blog.w0s.jp,2025-01-12:/728 2025-01-12T13:34:01+09:00 世田谷美術館で東急　暮らしと街の文化――100年の時を拓く(www.setagayaartmuseum.or.jp)の企画展が開催されていますが、その一環で昨日1月11日(土)に東急電鉄OBである荻原俊夫氏の講演「東急の車両設計に携わって」(www.setagayaartmuseum.or.jp)があったので聴講してきました。

サムネイル画像
世田谷美術館の建物（講演会とは別の日に撮影）オリジナル画像
サムネイル画像
「東急　暮らしと街の文化」の展示部屋（講演会とは別の日に撮影）オリジナル画像

講演タイトルからしてご自身が担当した車両の話が中心になるかと思いきや、東急電車の歴史をデハ1形から振り返る内容で、著書「東急電鉄 車輌と技術の系譜」(Amazon)をなぞるような性質のものでした。とはいえ直接関わった8000系5次車～2000系についてはその経験から興味深い話を聞くこともできました。

個人的に興味を惹かれたのは1000系の運転台に関する話で、曰く営団地下鉄（当時）の意向次第ではツーハンドルマスコンにすることも覚悟していたと。8500系の新製に際して半蔵門線乗り入れの関係からワンハンドルマスコンを営団に認めさせたことは有名な話ですが、それから10年以上が経ってなお、営団が半蔵門線以外でワンハンドルマスコンを導入していなかったとはいえ東急側がそのような心配をしなければならなかったとは……。

サムネイル画像
1000系1次車の運転台（クハ1001、2008年2月撮影）オリジナル画像

ほかちょっとおもしろかった小ネタをひとつ。8000系から車体長が大型 20m になったことについて東急で初めてという言い方は（本当は）おかしい……と念押しをされたのでチキ3095 のことを意識されているのかと思いきや、第二次世界大戦後に東急小田原線と厚木線に投入されたデハ1800形、クハ1850形（運輸省モハ63形、クハ86形割り当て）が「東京急行電鉄初の 20m 車」であると。まあ確かにそれはそうですね(笑)。著書(Amazon)でも大東急時代の京浜線や小田原線投入車も律儀に東急電車の一員とされていたことを思い出た次第です。

]]>