目次と免責事項

▼

2026年2月2日

1544.　変電・き電（饋電）・通信のもろもろ　250万Viewへの道筋　Since2013/12/01

2022年4月に100万PVを達成してから約3年10ヶ月

当ブログは今、250万PVという身に余る節目を迎えました。

100万PV到達まで： 約8年4ヶ月　2022年4月17日
1427.　変電・き電（饋電）・通信のもろもろ　200万Viewへの道筋　Since2013/12/01

250万PV到達まで： わずか11ヶ月　2026年1月30日

　電鉄系の「変電・き電（饋電）・通信」というニッチなテーマを扱いながら、これほど多くの方に、そしてこれほど速いペースで読み継がれるようになるとは想像もしておりませんでした。

こんなマイナーなブログを見て頂き、本当にありがとうございます。

Thank you for visiting this minor blog.
Merci de visiter ce petit blog.
Vielen Dank für Ihren Besuch in diesem kleinen Blog.
Gracias por visitar este blog menor.


　その前の田町事案でのPVを考慮して2026年1月30日の午前6時位に250万PVを迎える予定でした。
　ところが中国のボットがクローラーを開始したため、あっという間に250万PVを越え、そして上野駅停電事故でさらに拍車が掛かりました。現在は2,506,000PVを越えてます。

過去13年間でのPVを多い順から並べますと以下のようになります。

　Topが蕨交流変電所の事故　これは2回発生している。それから各送電線の記事のPV数が多い。

250万PV記念で
　1.スクリプトで最新の50記事に飛べるように目次のページに入れ込みした。
　2.さらに高度な検索ができるようにGoogleの高度検索機能を入れたものを目次に最後に付け加えた。

　記事全体ではやはり電鉄系の事故が発生すると検索件数が増える。

1. アクセスが集中する3つの黄金パターン

上位記事を分類すると、読者が何を求めてこのブログに辿り着くのかが明確に見えてくる。

① 「鉄道事故・停電」時の駆け込み寺（速報・解説）

  • 該当記事: 蕨交流変電所火災（1138）、2026年1月の山手線停電（1539）、黒磯駅加圧事故（542）など。

  • 分析: ニュースで「停電」が報じられた際、一般メディアでは報じられない「なぜ起きたのか？」「技術的にどういう状況か？」を深く知りたい層が流入している。特に2026年1月の記事がすでに上位に食い込んでいる点は、おのずからです。

② 圧倒的な「網羅性」による辞書的利用

  • 該当記事: 全変電所大全 306箇所（965）、架空送電線 経路 一覧（844）。

  • 分析: 「ここを見ればすべて分かる」というまとめ記事は、SNSでのシェアやブックマーク率が高く、長期間にわたって安定したアクセス（ロングテール）を生んでいる。

③ マニアックな「技術深掘り」

  • 該当記事: 狭小トンネルπ架線（595）、動力式検電接地装置（1540）。

  • 分析: 鉄道ファンの中でも、特に「電気・設備」というニッチな層に深く刺さっている。競合が少ないため、特定のキーワードで検索順位1位を独占している可能性が高い。

2. キーワードとターゲットの傾向

  • 「JR東日本 × 首都圏 × 電気設備」が最強の勝ち筋: やはり分母の大きい首都圏、かつJR東日本の設備に関する記事が圧倒的に強い。

  • 「蕨（わらび）」の聖地化: 蕨交流変電所の火災記事が突出してる。このブログにとって「蕨」は、ある種のキラーコンテンツ（象徴的なトピック）になっている。

  • 一般層と専門層の融合: 『シン・ゴジラ』のヤシオリ作戦考察（649）のように、エンタメと技術解説を紐付けた記事は、普段鉄道に興味がない層を呼び込む良い入り口になっている。

　GA4（GoogleAnalytics4）を入れているので今回の田町事案が起こる前から本日までの分析を行なった。

エンゲージメント率が30～40％台は良く記事を読まれていることを示す。
1位のNotセットは引用元が隠蔽されていて不明
2位が大阪　なぜ大阪が多いかは分析している
3位が新宿
4位が横浜
5位が港区
6位が千代田区

田町事案が発生した1月16、17日にスパイク、記事投稿


1月28日投稿の記事はスパイクは発生していないが高止まり（一般ユーザー外が読んでいる）

1月30日に若干のスパイク　これは上野駅停電事故でUpしている。


　検索単語は「検電接地装置」がダントツ、次が動力式検電接地装置で残りは田町変電所関係が多かった。
　2029/01/26時点でブログ等に検電接地装置を載せているのは私のブログしかない。初出は2014年まで遡るのでGoogle検索の上位にある。
　面白いのは、検電接地装置の検索件数が私が1/16にUpした記事に追記する前から増えていること。現場関係者で検電接地装置を検索したJR東日本以外の人々がいたことになる。

夜中にピークがあるがこれはボットが記事をクローラーしていたから

その他判明したこと　GA4とGeminiで分析
　
OSで一番多いのがUNIX　Windowsではない、次はWindowsでこの順位がたまに逆転することがあるがUNIXが多い　Linuxは6番目


250万View以降の対策
GoogleBloggerの突然の終了に備えて移行措置を準備しておくこと　
定期的なエクスポート

　Bloggerの画像は「Blogger メディア マネージャー」という専用の領域に保存・管理されておりGoogleBloggerが終了すると消えてしまう。一応GoogleDriveの一部の機能を使っているらしくGoogle ドライブの容量を直接消費しない。しかしGoogle ドライブ(drive.google.com)の中にファイルとして見えることはない。

　Google アカウント全体のストレージ： 画像が消費する容量は、Google アカウント共通のストレージ（Google ドライブ、Gmail、Google フォトと共有の15GBなど）の一部としてカウントされているので途中でブログの画像がUpできなくなり有償でGoogle ドライブの容量を増やしている。→Google ドライブの容量を直接消費しないと言っている割には画像数が多いので圧迫してる。

読み込ますデータをGoogle Bloggerから落として保存したが以下の点が直ってない

  1. 約1544ある記事を全て見直し、ラベルの付け直しを行なう
  2. 過去記事で内容に不整合がある場合 修正を行なう
  3. リンク切れ箇所を修正 もしくはリンク切れを明示する
これを行なっていると時間が溶けるので中止した。


ローカルLLMの構築

　でLMStudioとAnthingLLMをリンクさせて1544の記事を.md化させてAnthingLLMのワークスペースに投げ込んで実行させてみた。LMStudioのモデルはopenai/gpt-oss-20b:2を使用

　AnthingLLMに1544の記事を読み込ませるまでは成功　336GBのメモリとXeon 40コアがあれば、1544件程度のテキスト処理は一瞬で終わる。

　336 GB (336 GB 使用可能：値上がり前に細々と買い集めていたので8GBと16GB混在　1Rと2R混在速度は24スロット全部埋まっているので1600Mz)　Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz (2.20 GHz) (40コア・80スレッド×2 プロセッサ)で処理中でメモリは65GB使用中　コミット済75/352GB

1544件の記事を適切に分割（チャンク化）して保存すると、おおよそこのくらいの数になるつまり、データ自体はAnythingLLMの中に物理的に取り込まれている。

　最大コンテキストスニペット数: 「4」→ 「20」〜「30」と増やしていっても検索結果が十分応答していない。スニペット数を増やしても記事を列挙できない場合、それがまさにAnythingLLM（内部データベースLanceDB）が大量のインデックスを管理しきれなくなった時の挙動となっている。
AnthingLLMでのチャットの内容　　これでは使い物にならない。

　AnythingLLM は：
1.全記事を embedding
2.質問時に「候補文書」を選別
3.選ばれた一部だけを LLM の context に投入

この 2の段階で、候補が多すぎる（1,544）、類似度が拮抗

結果：関係ない記事を拾う。重要記事が落ちる。回答が薄くなる。等の現象が発露

　今は別のAnthingLLMを使わない方法を探索中　データ（.md）はあるので探して再構築する予定。





at