2026/07/06(月)nginxのリバースプロキシが上手くいかない問題を解消した

ConoHa VPSをフロントエンドにし、自宅サーバーにリバースプロキシする構成を組んだ時のトラブルメモ。

起きていた条件

nginxからnginxへリバースプロキシする構成で前段がTLS終端で、後段へはHTTPで接続していた。前段はVPS、後段は物理サーバーで別の環境。

起きていた事象

lycolia.info*.lycolia.info全体で前段が後段に接続できない状態になっていた。

curl -iSsl4 https://blog.lycolia.info/
HTTP/2 000 
server: nginx
date: Fri, 03 Jul 2026 15:24:44 GMT

前段のnginxにcurlを投げるとステータスコード000が返ってきて、curlが終了コード23で異常終了していた。

2026/07/04 00:11:33 [error] 2537#2537: *12468 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: lycolia.info, request: "GET /pub/lycolia/rss.xml HTTP/2.0", upstream: "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80/pub/lycolia/rss.xml", host: "blog.lycolia.info", referrer: "https://blog.lycolia.info/pub/lycolia/rss.xml"

nginxのエラーログには「アップストリームからのレスポンスヘッダーの読み取り中に、アップストリームが有効な HTTP/1.0 ヘッダーを送信しませんでした。」という意味のエラーを出力していた。

後段のnginxには何もログが出ていなかった。

curl -v --http1.1 -H 'Host: blog.lycolia.info' "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80/"
*   Trying [2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80...
* Connected to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a (2400:4153:8f01:c800:c14b:3f7a:2b54:353a) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: blog.lycolia.info
> User-Agent: curl/8.14.1
> Accept: */*
> 
* Request completely sent off
* Received HTTP/0.9 when not allowed
* closing connection #0
curl: (1) Received HTTP/0.9 when not allowed

前段のnginxのあるVPSから、後段のnginxに対してhttpバージョン1.1を明示して叩くと「HTTP/0.9 when not allowed」というエラーが出てきた。HTTP/0.9…?初めて聞く概念だ…。

curl -s --http0.9 'http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]/' | xxd           
00000000: 0000 1204 0000 0000 0000 0300 0000 8000  ................
00000010: 0400 0100 0000 0500 ffff ff00 0004 0800  ................
00000020: 0000 0000 7fff 0000 0000 0807 0000 0000  ................
00000030: 0000 0000 0000 0000 01                   .........

httpバージョン0.9を明示して叩き、帰ってきたレスポンスのバイナリ。端的に言うとプロトコルエラーで帰れと言われているが、理由は後述する。

解決した方法

+listen [::]:80;
-listen [::]:80 http2;

後段のmstdn.lycolia.infoの設定を上記に変更することで、他のドメインでも問題が解決した。

何故解決したかはわからないが、恐らく80 http2と書くと、他の80番ポートのリッスンにも影響が波及するのだと思う。

http2通信にしなくても問題ないのかでいうと、Mastodonは問題なさそうに見えたのでたぶん大丈夫なんだと思う。知らんけど。

何故解決したのか

使用しているnginxのバージョンがproxy_passするときにhttp 2.0をサポートしてなかったからだ。

nginx 1.29.4になるとproxy_passでhttp 2.0がサポートされるようで、2025年12月9日のリリースには以下の一文があった。

*) Feature: the ngx_http_proxy_module supports HTTP/2.

この時ばかりは今までnginxのバージョンに興味が微塵になかった私もバージョンを上げたくなった瞬間だった。

ただ後続のバージョンのバグフィックスを見るに結構バグが出てそうなので、今あげるのは時期尚早かもしれない。まぁ現状困ってないので上げなくてもいいのは幸いだ。

ところでv1.25.1になるとlisten単位のhttp2が非推奨になり、代わりにhttp2 onという全体単位?が推奨設定になるため、将来的に現状のポート単位にhttpバージョンを分ける技は使えなくなりそうである。

あとがき

バイナリ読解

前述したHTTP 2.0のバイナリレスポンスを読んでみようのコーナー。

curl -s --http0.9 'http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]/' | xxd           
00000000: 0000 1204 0000 0000 0000 0300 0000 8000  ................
00000010: 0400 0100 0000 0500 ffff ff00 0004 0800  ................
00000020: 0000 0000 7fff 0000 0000 0807 0000 0000  ................
00000030: 0000 0000 0000 0000 01                   .........

そのバイナリを見るといいという情報をやってみたので試してみた結果。

まず16進数なので1桁に0-Fが入る。これは0000~1111ということだ。つまり1桁が4bitであることが分かる。

さて、HTTP/0.9は一旦忘れて、先ほどやってきたHTTP/2.0として解釈してRFC 9113 - HTTP/2を読んでみる。

「4. HTTPフレーム」によればHTTPフレームの先頭24bitがLength、8bitがType、8bitがFlag、1bitがReserved、31bitがStream Identifierらしい。

つまり先頭を分解するとこうなる。

Length: 00 00 12
Type: 04
Flag: 00
Reserved+Stream Identifier: 00 00 00 00

Lengthだ。0x000012なので18個の8bitフィールドがある。

次の8bitがTypeで0x04となっている。0x046.5.1. 設定フォーマットだ。

Reserved+Streamは全て0なので無価値だろう。

設定フォーマットではそこから48bit単位が設定フィールドとなる。先頭16bitがIdentifier、後ろ32bitがValueだ。

18個の8bitフィールドが設定になるため18 * 8 = 144, 144 / 48 = 3で3つの設定が存在すると読める。

00 03 00 00 00 80

つまりこの部分になる。

Identifierは00 03なのでSETTINGS_MAX_CONCURRENT_STREAMS。最大同時ストリーム数だ。

Valueは00 00 00 80なので128

次は00 00 00 00 10なのでSETTINGS_HEADER_TABLE_SIZE。ヘッダ圧縮テーブルの最大サイズ。

04 00 01 00なので67,109,120。オクテット単位なので単位はバイトと思われる。オクテットのオクはオクトパスのOctと同じなのでタコの脚は八本と考えると覚えやすい。Octoberも旧暦の8月だからOct。

次は00 00 05なので、SETTINGS_MAX_FRAME_SIZE

00 ff ff ff 00なので4,294,967,040。これも単位なので単位はバイトと思われる。

これで設定が終わり、またフレームに戻る。

00 0004 0800
0000 0000 7fff 0000 0000 0807 0000 0000
0000 0000 0000 0000 01

これが残り。

Length: 00 00 04 → 4 * 8 = 32bit
Type: 08WINDOW_UPDATE
Unused Flags: 00
Reserved+Stream: 00 00 00 00
Reserved+Window Size Increment: 7f ff 00 002,147,418,112

次の残り

0000 0807 0000 0000
0000 0000 0000 0000 01

Length: 00 00 08 → 64bit
Type: 07帰れ
ここまでくれば尻だけ読めばいいので中間は読み飛ばす。
最後の32bitがエラーコードらしいので00 00 00 01が恐らくエラーコード。意味合い的にはPROTOCOL_ERROR

要するにHTTP 2に対してHTTP 1.1で接続していたのでプロトコルエラーが返却され、しかしnginxは理解できなかったのでHTTP 0.9として解釈していたのだろう。

今回組んだ構成

今回nginxからnginxにリバースプロキシをしたわけだが、結果として上図のような構成にした。前段にはConoHa VPSを利用している。

これをした理由としては、以前フレッツ光クロスでフルポート使えるIPv4が取れないことが判明したため、クロスに移行出来るようにするためというのと、IPv4のためにDDNSし続けるのが地味に面倒なのと、宅内からIPv4を排除したかったところによる。

ただこれはこれでVPS側にもTLS証明書が必要になるため、DDNSが消えてもIPv4保守のための呪いはまだ残る。DDNSよりはマシだが…。

また、この構成では前後でnginxのバージョンが異なり前段がv1.26.3、後段がv1.24.0となっているため、前段ではhttp2 onにしないと警告が出るなど、バージョン差異による違いが微妙にある。

結果的にできた構成

今回の施策によって自宅サーバーからIPv4が失われても、AレコードをConoHa VPSに向けることでIPv4を受けることが可能な体制の検証をすることができた。これによってフレッツ光クロスに乗り換えたときのIPv4不在問題を解消できる状態となった。

実運用に移すためにはVPS側にもTLS証明が必要になるので自宅サーバーからSCPで送るか、VPS側でも取得する必要が出てくるので、まだまだ対策が必要だ。後者は同一ドメインに二重に証明書が存在する状態になるのでなんか嫌だし、恐らく前者でやるだろう。TCP パススルーなる技術も健闘したが、真のクライアントIP転送問題など、いろいろ厄介そうなのでやめた。

SCPで送る場合はパスフレーズ付きの鍵認証を突破させ、更にnginxをリロードさせないといけないからこちらもやや頭が痛い。パスフレーズ付きのSSH鍵を無人突破させるにはどこかに平文でパスフレーズを持つ必要がある。暗号化もできるがどんどん複雑に…。

或いはDNS-PERSIST-01を使うことで証明書更新を不要にするのも一つの選択肢かもしれないので、こちらも検討していいかもしれない。

しかしVPSがあることで監視対象が増えるなど、なかなか複雑化してしまうので、これを軌道に乗せるかどうかは現時点では不透明だ。ただConoHa VPSは最低スペックで36ヶ月契約であれば月額293円のため、36ヶ月換算でも10,548円にしかならず、IPv4を保持する手段としてはお手頃である。安いISPでもv4を買おうとすると月2~3,000円はするし、まともなところだと一万円以上するので、IPv4にサーバーがついてこの価格は破格と言える。

帯域は100Mbpsだが、100Mbpsあれば十分だろう。

おまけConoHa VPSで帯域実測

自宅サーバーとConoHa VPS間でiperf3をやってみた結果。自宅サーバーへの穴あけが面倒だったので自宅サーバー→ConoHaという逆経路でしか試していない。

Interval Transfer Bitrate Retr Cwnd
0.00-1.00 sec 24.4 MBytes 204 Mbits/sec 0 1.42 MBytes
1.00-2.00 sec 10.9 MBytes 91.2 Mbits/sec 0 1.43 MBytes
2.00-3.00 sec 12.2 MBytes 103 Mbits/sec 0 1.43 MBytes
3.00-4.00 sec 11.0 MBytes 92.3 Mbits/sec 0 1.43 MBytes
4.00-5.00 sec 10.9 MBytes 91.2 Mbits/sec 0 1.43 MBytes
5.00-6.00 sec 12.2 MBytes 103 Mbits/sec 0 1.43 MBytes
6.00-7.00 sec 11.0 MBytes 92.3 Mbits/sec 11 1.26 MBytes
7.00-8.00 sec 11.0 MBytes 92.3 Mbits/sec 169 762 KBytes
8.00-9.00 sec 11.0 MBytes 92.3 Mbits/sec 0 807 KBytes
9.00-10.00 sec 12.2 MBytes 103 Mbits/sec 0 838 KBytes
  • sender: 106 Mbits/sec
  • receiver: 103 Mbits/sec

2026/07/03(金)ConoHaのVPSのポートに穴をあけて外部通信できるようにした

更新日:
投稿日:

任意のポートでSSH接続をしようとしたら全然繋がらず、ググっても出てこなかったので書く。

この記事ではSSH接続に限らず、IP制限なく任意のポートを開放する方法について扱う。

1. セキュリティグループの作成

  1. コントロールパネルにログインする
  2. 左のメニューからセキュリティ→セキュリティグループを開く
  3. 「+セキュリティグループ」ボタンを押し、MySSHとか適当な名前で設定を作る
  4. 作成したセキュリティグループを開き、左下の「+」を押す
  5. 通信方向:IN
    イーサタイプ:IPv4 or IPv6
    プロトコル:TCP or UDP。1つの設定でTCPとUDP両方開けることはできない
    ポート範囲:単体の場合は10092、範囲の場合は10000-11000のように指定すると思うが範囲指定は試していない
    IP/CIDR:IPv4なら0.0.0.0/0、IPv6なら::/0
  6. コンソールに入る
  7. 初期設定

2. NICへセキュリティグループを割り当て

  1. 左のメニューからサーバーを開き、適用するVPSを開く
  2. ネットワーク情報の「セキュリティグループ」を開く
  3. 「+」ボタンを押し、先ほど作成したセキュリティグループを選択
  4. 保存ボタンを押し、セキュリティグループが追加されていることを確認
  5. この時に、プリセットに存在するICMPのルールも割り当てておくと良い。「IPv4v6-ICMP」がそれだ

この設定の反映は即座には反映されないようで、数秒のタイムラグがあった。3秒くらい待つと繋がった。

3. VPSのファイアーウォールに穴をあける

  1. コンソールからVPSのシェルに入る
  2. /etc/nftables.confを開き、先ほどセキュリティグループで開けた穴が開くように設定する

    #!/usr/sbin/nft -f
    
    flush ruleset
    
    table inet filter {
        chain input {
            type filter hook input priority 0;
            policy drop;
    
            iif "lo" accept
    
            ct state established,related accept
    +
    +         meta l4proto { icmp, ipv6-icmp } accept
    +
    +         tcp dport 3000 accept
        }
    
        chain forward {
            type filter hook forward priority 0;
        }
    }
    
  3. nftablesを再起動する
    systemctl restart nftables
    

おまけ:公開鍵認証を使ったSSH接続について

コントロールパネルのセキュリティ→SSH Keyという項目があるが、ここを設定する必要はない。

/etc/ssh/sshd_configを書き換えて、公開鍵を所定の場所に設置すれば普通に設定できるので、わざわざWeb画面から設定する必要はない。

ここから追加したところでパスワード認証が無効になるのかどうかもわからないし、そもそもこれがSSHDに関連するのかもわからないし、謎設定だと思う。ひょっとしたら単に鍵を生成するだけなのかもしれないが、それならssh-keygenなどを使えばいいわけで…。

あとがき

Conoha公式のVPSスタートアップガイドにはSSH接続でVPSにログインするというのがあるが、セキュリティグループに関する記述がないので、そのままでは標準の22番ポートにすら繋がらないのが困りものだ。

VPSスタートアップガイドと言うからにはそのくらい書いてくれてもいいんじゃないだろうか?と思った。

2026/07/01(水)MantisBTのステータスをカスタマイズする

更新日:
投稿日:

MantisBT標準のステータスはどうにも使いづらいので、独自のステータスを追加して置き換える方法。

確認環境

  • MantisBT 2.27.1

やりたいこと

MantisBT標準のステータスを捨てて、一人用のチケット管理システムとして使えるようにする。要するにTODO管理の様なものにする。

ステータスの再定義

まずステータスを再定義する。

ステータスは標準でnew, feedback, acknowledged, confirmed, assigned, resolved, closedと七種類あるが、これをdraft, not started, in progress, pending, testing, completedの六つに変える。意味合いとしては下書き、未着手、仕掛中、保留、試験中、完了だ。

最後に解決状態も同様にopen, fixed, reopened, unable to duplicate , not fixable, duplicate, not a bug, suspended, wont fixと九つあるのを、in completed, duplicate , wont fix, completedの四つに再定義する。

このように状態を絞ることでTODO管理ツールとして機能させることが可能になり、更に状態管理も単純になってやりやすくなる。

やり方

  1. config/config_inc.phpを開きステータスの定義を追加する

    # ステータスの定義
    # <優先度>:<キー名>として並べる。値はDBに登録される値として利用される。
    $g_status_enum_string = '10:draft,20:not started,30:in progress,40:pending,50:testing,100:completed';
    
    # 定義したキー名に対し課題一覧で表示される色を決める
    $g_status_colors['draft']       = '#fcbdbd';
    $g_status_colors['not_started'] = '#e3b7eb';
    $g_status_colors['in_progress'] = '#ffcd85';
    $g_status_colors['pending']     = '#c2dfff';
    $g_status_colors['testing']     = '#fff494';
    $g_status_colors['completed']   = '#d2f5b0';
    
    # チケットの解決状況の定義
    # <優先度>:<キー名>として並べる。値はDBに登録される値として利用される。
    $g_resolution_enum_string = '10:in completed,20:duplicate,30:wont fix,90:completed';
    
  2. config/custom_strings_inc.phpを作成し、ここまでで作った状態を和訳する。

    <?php
    
    # ステータス表示名
    # 完了はフィルタで以上が付くので一番後ろに置いておくとよいと思う
    $s_status_enum_string = '10:起案,20:未着手,30:仕掛中,40:保留,50:試験中,100:完了';
    
    # ステータス変更画面のタイトル・ボタン・通知タイトル
    $s_draft_bug_title = 'ステータスを起案に変更';
    $s_draft_bug_button = '起案にする';
    $s_email_notification_title_for_status_bug_draft = '課題が起案されました。';
    
    $s_not_started_bug_title = 'ステータスを未着手に変更';
    $s_not_started_bug_button = '未着手にする';
    $s_email_notification_title_for_status_bug_not_started = '課題が未着手になりました。';
    
    $s_in_progress_bug_title = 'ステータスを仕掛中に変更';
    $s_in_progress_bug_button = '仕掛中にする';
    $s_email_notification_title_for_status_bug_in_progress = '課題が仕掛中になりました。';
    
    $s_pending_bug_title = 'ステータスを保留に変更';
    $s_pending_bug_button = '保留にする';
    $s_email_notification_title_for_status_bug_pending = '課題が保留になりました。';
    
    $s_testing_bug_title = 'ステータスを試験中に変更';
    $s_testing_bug_button = '試験中にする';
    $s_email_notification_title_for_status_bug_testing = '課題が試験中になりました。';
    
    $s_completed_bug_title = 'ステータスを完了に変更';
    $s_completed_bug_button = '完了にする';
    $s_email_notification_title_for_status_bug_completed = '課題が完了しました。';
    
    # 解決状況表示名
    $s_resolution_enum_string = '10:未解決,20:重複,30:対応不要,90:対応完了';
    
  3. 既にMantisBTを利用している場合、既存のチケットの表示がバグるため、ステータスと解決状況が整合するようにDBを適当に整える。

    -- ステータスの置換
    UPDATE mantisbt.mantis_bug_table SET status = 20
    WHERE status != 10;
    
    -- 解決状況の置換
    UPDATE mantisbt.mantis_bug_table SET resolution = 100
    WHERE resolution = 20;
    
  4. あとは管理画面に入りワークフローを組めば終わりである。個人で使うものなので制約はだいぶ緩めにしている。

あとがき

これで管理がだいぶ楽になりそうだ。MantisBTはバグ管理ツールなのでTODO管理をしようとすると標準ではしんどいが、カスタマイズを重ねることで大分マシになる。

2026/07/01(水)nginxをinit.dからsystemdに移行してみた

Ubuntu 26からinit.dが非推奨になるが、systemdの設定が見つからなかったので試しに書いてみた。

確認環境

  • Ubuntu 24.04.4 LTS
  • nginx/1.24.0

手順

sudo mv /etc/init.d/nginx ~
sudo service stop nginx
cat <<'EOF' | sudo tee /etc/systemd/system/nginx.service
[Unit]
Description=nginx
Documentation=man:nginx(8)
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/sbin/nginx -t -q
ExecStart=/usr/sbin/nginx -g 'daemon off; master_process on;'
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -QUIT $MAINPID
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable nginx
sudo systemctl start nginx

参考記事

あとがき

nginxはマスタプロセスが上がったままなのでtype=simpleで問題なさそうだったが、正直よく分かってないので、何か問題が出たらまたその時に対処したい。

init.dにはまだ沢山転がってるので徐々に移行させていかないと…。

2026/07/01(水)須磨浦山上遊園に行ってきた

これは去る5月23日、須磨浦山上遊園へ行ってきたときの記録である。

旅行記放置しすぎなので書いていこうキャンペーンの一環で淡路市に初上陸してきた話に続き、連続して書いている。

一体何ヶ月分放置するつもりなんだ…。MECEにならずノイズが増えるばかりの技術記事より、もっとMECEの余地が根本にない日記のようなものを書くべきだろう。

記憶にある限り今回で三度目の来訪だ。

この回の訪問では前回、3月9日の訪問時に撮影した箇所の写真を撮らなかったため説明用の写真が足りず、一部に3月9日に撮影した写真を混ぜており、その旨の言及をしている。

須磨浦山上遊園とは?

須磨浦山上遊園とは、書いて字のごとく須磨浦の山の上にある遊園地である。

場所として山陽電車須磨浦公園駅直結というアクセス至便の立地にある遊園地だ。駅直結なのでひらパーみたいに駅から歩く必要はない。駅直結だけあり、運営者は山陽電車である。

遊園地としては昭和に作られた懐かしの遊具や施設を満喫でき、瀬戸内を望む山の上なので大変眺望が良いことが挙げられる。子供が来ても面白が少ないかもしれないので、どちらかといえば大人向けだろう。

例えば日本一乗り心地が悪いことで知られるカーレーターや、日本に5つしか残っていないといわれる回転展望台、現役のジュークボックス、インベーダーゲームといったものや、落下防止装置のない観光リフト、サイクルモノレールなどがある。

ネット上ではガラガラでスカスカで今にも潰れそうな遊園地と紹介されることも少なくないが、私が前回行ったときはそこそこ混んでおり、待ち時間0秒というほどではなかった。遊具によるが5分は覚悟した方がいいだろう。

旅の始まりは阪神三宮駅から

三宮で写真を撮っていなかったので阪神三宮駅から阪神の特急に乗車し山陽須磨へ移動したところ。

ここ数年の山陽電車はJR西日本に倣ってベンチの向きを線路に平行にしているため、山陽須磨のベンチの向きも平行になっている。今年の3月9日には既にこうなっていた。

山陽須磨から海側へ目を移すとJR須磨駅が見える。JRの須磨駅は須磨浜に面しており、駅を出たらすぐ砂浜という夢のような駅である。

山陽須磨で周囲を見渡すと神戸が坂の町と呼ばれている理由がよく分かるくらいには坂が良く見える。

この駅にはカロリーメイトの自販機があるので、小腹が減ったときにも安心だ。改札を出ればコンビニもあるが、動きたくないときには重宝するだろう。

なお、この写真は3月9日に撮影したものである。

しばらく待っていると普通電車がやってきた。これに乗って隣駅の須磨浦公園駅へ向かう。タイミングがいいと二枚目の様な新しい車両が来ることもある(二枚目は3月9日撮影)

須磨浦公園駅に到着

須磨浦公園駅で列車を降りると須磨浦山上遊園のレトロな看板などが出迎えてくれる。

ホームを出ると眼前は瀬戸内海で、非常に眺めがいい。

海側から駅舎を望むとこんな感じ(3月9日撮影)

この日はよく並んでいたが、三宮・姫路1dayチケットを持っていた私はこの行列をスキップしてロープウェイ乗り場へ向かった。

まずは眺望のいいロープウェーから

ロープウェイ乗り場へ向かう階段も中々のレトロさだが、この日は外国人も目立ち、少し驚いた。ただインバウンド客というより、神戸に住んでる外国人が大半で、ごく僅かに訪日客がいるくらいに見えた。

理由として、そもそも神戸ではムスリムのような人は普通にいるし、東南アジア系の人も多く見えたからだ。近場にあって手ごろに遊べるので遊びに来たとか、そんな感じだと思う。一応英語対応もしてるし。

さていよいよロープウェイが見えてきたので乗り込む。

座席には山陽電車のモケットが使われており、これは新型車両のものなので、割と最近モケットだけリニューアルされたものとみられる。

この写真は3月9日に撮影している。

搬器は古くはないものの、新しくもない。そんな感じである(3月9日撮影)

さて動き始めると最初に目に入るのは写真中央左手に見える神戸市営須磨海づり公園だ。昔は奇妙な円盤状の建物があったのだが、老朽化で撤去され、随分シンプルになった(3月9日撮影)

神戸市は釣り禁止エリアが多いが、ここでは合法的に好きなだけ魚を釣れる。但し有料である。

ロープウェイが高度を上げてくると西には須磨浜から神戸市街、ポートアイランド、神戸空港などを一望でき、更に奥には大阪まで一望できる。

正面を見ると海づり公園、奥の陸地は紀伊半島、つまり和歌山県だ。

海を往来する船舶も良く見え大変眺望がいい。

余談だがロープウェイに乗らなくても登山道を歩くことで山上遊園にアクセスできるため、ロープウェイ代をケチりたいとか、健康になりたい人は登山道を歩いてもいい。ここの登山道は六甲全山縦走路に指定されているので、非常に名のある道になっている。但し登山道を行くなら最低でも運動靴は履いてきた方がいいだろう。

日本一乗り心地が悪いことで知られるカーレーターへ

ロープウェイを降りると次はカーレーターだ。これに乗ってメインの場所まで行く。山上遊園なので山の上に行くための乗り物が多い(3月9日撮影)

「揺れ続けて60周年」「唯一無二のカーレーター 60周年」などとめでたい感じの搬器が走っている。ちゃんちゃんこみたいなやつ乗りたかった。

この動画を見ると、かなり揺れているのが分かると思う。この通りガタガタしているため、日本一乗り心地が悪いといわれている。なお一枚目の動画は3月9日に撮影したものである。

原理的にはローラーの上に乗ったコンベヤの上を走行していると思うのが、乗降口に来るとタイヤの上に直乗りするので、揺れが強まり、乗り心地が悪化する感じだ(3月9日撮影)

カーレーターは世界でもここにしかない珍しい乗り物なので、この乗車体験は貴重だ。

カーレーターは乗り心地が悪いことばかり注目されがちだが、実は眺望もいい。このように淡路島と明石海峡大橋を望むこともできる。

日本で五基しかないとされる回転展望閣へ

カーレーターに揺られて坂を上っていくと回転展望閣に到着する。実は兵庫県は回転展望閣のメッカで、最盛期は全国最多の三基存在したそうだ。現在でも二基は生きていて、もう片方はポートタワーの中にある。

回転展望閣に入るには料金が必要だが、三宮・姫路1dayチケットを持っている場合は無料で入れる。

展望閣内はこんな感じでゆったりと回っている。

このフロアは喫茶室コスモスという軽食店になっているが、この日は満席だった。

回転展望閣は回転する性格上、東洋経済のやたら詳しいレビューによると荷重に制約があり50席しか設けられないそうだ。そのため面積に対しての定員は少なめである。

仕組み的には床下に3本のレールがあり、その上に車輪の乗った床があり、一番内側には24個、中央と外側は48個の車輪がついているらしい。つまり合計で120個の車輪がある。これをモーターを使って駆動させることで回しているようだ。

点検は3カ月に1回のペースで行っています。モーターのある部分の床が開くので、ここから車輪に油を差すなどを行っています。つい最近だと、10年以上ぶりにモーターを新調しました。この時はぜんぶで約1000万円の費用がかかりました。3年ほど前には車輪も全部替えました。車輪が一番消耗するんですよ。なお、年間のランニングコストなどは特に計算していません

このようなコメントもあり、維持費は安くはなさそうだ。また先の記事には回転レストランよりもカーレーターのほうが、より高額なメンテナンス費用が発生しているともあった。

須磨浦山上遊園には専属の保守業者がいて面倒を見ていてくれているようだが、全国に設置された当時はどこもがそうだったわけではなく、設備更新方法が不明なまま閉じられた場所もあるのではないかと書かれていた。ただ、ここの場合は鉄道会社が運営していることからレールや車輪、モーター、電気系などの調達そのものは他所より容易な可能性はあるかもしれない。

先の東洋経済のレビューによると喫茶室コスモスは平日に50組~100組。土日祝日は150~250組ほどが来店するとのことで、中々盛況のようだ。1組あたりの平均単価は1500円前後。看板メニューは税込700円のクリームソーダと、税込600円のピザトーストとのこと。そして、ここの食材はロープウェイとカーレーターを利用して運ばれてきているらしい。

そしてここもまた眺望がよく、淡路島や明石海峡大橋や、垂水区の住宅街や、西区の辺りまで一望することができた。眼下に移る観光リフトも楽しみだ。(三月にも行ったが…w)

山の中にポツンと移る場所も須磨浦山上遊園の一部らしいのだが、ここには行けていないのでまた頃合いを見ていきたいと思う。

回転しているので船が行き交う様子が見れる時もある。

壁には県外からの来訪者の漫画も掲示されていた。掲示されている漫画はこれ以外にもあるので興味のある人は是非現地で見てほしい。

来援記念ノートにはタイ王国からの来訪が記録されていて驚いた。まさかさっきロープウェイ乗り場ですれ違った在日タイ人らしき集団はわざわざ海外旅行で来ていたのか…!?

最近は著名人の来訪も多いのか、最近書かれたサインも多くあった。ポプテピピックで有名な大川ぶくぶのサインまであった。大川ぶくぶはいとうのいぢと並び、兵庫県を代表するイラストレーターなのだが、以前、加東市の広告を描いてたり、ここにサインを残していたり、何とも古郷思いの方だなと思った。

この日は残念ながら屋上には登れなかった。

回転展望閣の二階へ

二回にはかつてロープウェイを制御していたという機器が置かれていた。

なんとマスコンは中を開けることができる。

中を開けてぐりぐり動かすと中の動きがよく分かる。詳しい仕組みはわからないが異なる長さの金属の接点が回転により端子と触れ合っているように見えるので、恐らく一つ一つのラインがスイッチのような働きをしているのではないかと思う。

触れるラインが増えるほど電流が多く流れ、モーターがよく回るとか、多分そんな感じだと思う。知らんけど。

二階にはこの他にもインベーダーゲームや懐かしのアーケードゲームが多数並んでおり、いい雰囲気だった。

腹ごしらえに一階の軽食店へ

一階に降りるには一度外に出ないといけないので、外に出たところ写真撮影用の顔ハメ板が置いてあり、外国の方に大人気だった。

さて、そんなこんなで一階にある軽食店にやってきた。喫茶室コスモスは混雑している上に高いので、空いているであろう一階の方に来たのだが、予想通りガラガラだった。

メニューはコスモスと比べるとだいぶ庶民的で、価格も安価だ。しかも三階で売られている神戸六甲アイスクリームがこちらにもある。神戸六甲アイスクリームは一部のスーパーでも売られていて非常においしいやつである。

そして三階のやつには喫茶室コスモスという名前があるが、こっちには特に名前がなかった。

キャッシュレスの時代なので、しっかりキャッシュレスにも対応している。

という訳で食事とした。なんとも映えない食事だが、フランクフルトには粒マスタードがあり、ケチャップもいい感じのラインで塗られているし、たこ焼きもちゃんと船に入っているあたり、チープではあるものの雰囲気はしっかり出ている。

レシートは回転展望閣BBQということになっていた。BBQの受付が偶然軽食も出しているということなのかもしれない。

そしてなんとこのフロアには現役のジュークボックスもある。

このジュークボックスは中に円を描くように大量のレコードが入った場所があり、お金を入れて曲を選ぶと、このレコードを収めている台座が回転し、アームがレコードを掴み、レコード盤にセットし、再生が始まるといったものだ。

レコードが入ったスロットを特定している仕組みは不明だが、古い機械なので複雑なことはしていないと思われる。恐らく選曲ボタンに応じたスロットにレコードをセットしていて、それを取り出しているだけだと思う。

Wurlitzerのアーカイブサイトによると、ボタンを押すと対応するピンが跳ね上がり、レコードを格納する盤面が回転し、検知機に衝突したら停止という機構のようだ。

確か逆回転もしてたような気がするので仕組み的には上記ページそのものだと思う。

たぶん今の人が実装しようとしたらQRコードや、RFID、OpenVisionとかを使うかもしれないが、古い機械なので至ってシンプルだ。つまり、ボタンとスロットが合致しない状態でレコードがセットされていれば違う曲が再生されたりはあるだろう。

また、この機体はDeutsche WurlitzerのX2で、1976年に制作されたモデルのようだ。つまり50年間動いていることになり、恐らくこの建物とほぼ同年齢なので、当時は新品で納入された個体なのだろう。それが今までこうして動き続けているというのは何とも素晴らしいことだ。

天井にはNationalのレトロな電灯もあった。電球はLEDに変えられてそうだが、この電灯カバーは何とも趣がある。

観光リフト乗り場に向かっているといい感じに成長した木を切り倒す告知があり、ちょっと寂しい思いになった。

安全装置のない恐怖の観光リフトへ

そもそも安全装置の付いた観光リフトの方が少ないと思うが、それはさておき乗り場へやってきた。

写真にある通り、安全バーやシートベルトなどの安全装置はないタイプだ。松山城にあるのと同じようなタイプだが、あちらより屋根が立派である。落ちても死ぬことはないと思う。

まずはリフト乗り場前でチケットを買う(3月9日撮影)。基本的に往復を買うが、帰りを歩く人は片道でもよい。ハイキング道があるので徒歩でも戻ってこれる。

新札対応は片方しかないのと、ここは現金しか受け付けていないので注意。どうしてもクレジットで払いたい人は麓の受付まで戻ってAチケットを買ってくるしかないと思う。

乗り始めはこんな感じ。結構傾斜があり、最初は怖いがなれれば何ともない。そのうち手すりに摑まらずとも平気になる。

左奥に見える謎の建築物は花の広場というらしいが、一度も行ったことがないので、また機会があれば行こうと思う。噂では廃墟らしい。

乗り場の案内でも花の広場だけ「営業中」ではなかった上、なんか明らかに安っぽいラベルが貼ってあったので、つまりそういうことなのだろう。

ここもまた眺望がよく、淡路島と明石海峡大橋、そして垂水、明石方面を一望できる。加古川にある製鉄所もぼんやり見えている気がする。

谷底付近は谷合の上を通りかなりの高さがあるため、高所恐怖症の人にはお勧めできない。(3月9日撮影)

そして観光リフトが谷底に入ると、最大の名所が訪れる。

なんとここには摂津国と播磨国の国境があり、その上を通れるのである!!!(3月9日撮影)

こんなところは早々ないので、ここを超えるためだけに乗っていいともいえるのが、この観光リフトだ。少なくとも私は最初このリフトに乗りに来たときは、これを見るために乗った。

そして同時に海側を見れば壮大な谷が見える。いい景色だ。

ここを過ぎればあとは登っていくだけである。

ワイヤーを通している鉄塔をよく見ると昭和三十四年七月 山陽電気鉄道株式会社とあり、非常に長い間、大切に扱われてきたことが分かる。

イラストの注意書きには日本語、英語、中国語、韓国語が併記されており、昨今のインバウンドを意識していることも伺える。

リフトで対岸に着くと自然いっぱい山上遊園の門が迎えてくれる。

前回3月9日に来たとき営業時間が終わっていて乗れなかったサイクルモノレールに乗るのが今日の目的だ。きっと空中を走るので怖いはずだ…!という期待を胸に向かう。

途中でトイレに寄ったが、山の中にある古い遊園地にしてはちゃんとウォッシュレットで感動した。ただ、恐らく和式便所を改造しているようで、部屋が凄く狭かったのと、カバンなどをかける場所がなかったのでやや困った(清掃中で床が水浸しだった)

空中散歩を楽しめるサイクルモノレールへ

意外と人がいてちょっとした列ができていた。列は外国人がメインだった。

ここも支払いは現金のみと思われる。

さて番が回ってきたので乗っていく。らくしーchannelというYoutubeによると、手前側が去年入った新車で、奥側が45年前の車両らしい。また線路長は180mあるとのことで、結構漕ぎごたえがある。

作られた年代が分かる仕様の表示板と、遊園地らしい身長制限の奴もあった。

漕ぎだしはこんな感じ。

高さはそんなになく、揺れもないので特に怖さは感じなかった。鷲羽山ハイランドのスカイサイクルの予習として使うにはイマイチかもしれないと思った。

相変わらず眺望は抜群によく、淡路島と明石海峡大橋と垂水と明石の街並みが良く見えた。供用中だが工事中の高速道路?とやたら広い空き地が見えたが、こっちは住宅の分譲地だろうか?

垂水JCTかな?と思ったが、小さすぎるのと、方角的に名谷ICだと思った。垂水JCTはもっと北にあるのでたぶん見えない。

写真や動画を撮りながら止まったりゆっくり進んだりしていたが、それでも前が詰まっているので、存分に形式を楽しみながら進めるのがここの良いところだと思った。

ちなみに私の後ろの人は電話でキレ散らかしながら漕いでいたが、タイ語か何かを喋っていたので何を言っているのかは全く分からなかった。

1/4ほど進んだところは何故か木がなぎ倒されていた。景観のためにしてはやりすぎな気がするので謎だ。台風で倒れたにしては局所的すぎる気もした。

山の中にデカいマンションがぼこぼこあって見ごたえのある景色だ。

1/2ほどで開けたところを抜けて内側に入ってくると壁が見えるようになる。何かの制御盤がいた。

ゴール手前に来ると海が見え、再び眺望が良くなった。

サイクルモノレールを降りると「この水は飲めません」と書かれた蛇口を見かけた。昔は飲めたが、今は水道管の腐食や、蛇口の衛生面などで飲めなくなったとかなのだろうか?

蛇口が下を向いていることから、そもそも飲用目的の設置ではないのかもしれない。飲用目的なら上に開店する蛇口か、先が丸くなった噴水タイプみたいなやつだと思うし。

ハイキング道みたいな場所があったので入ってみたが、勢い余って下山してしまいそうなので戻ることにした。

もしかしたらこの先に「花の広場」があったのかもしれない。

帰路へ着く

帰りの観光リフトで帰っていく。やはりなかなかの角度だ。

来るときは摂津国から播磨国に入ったが、今度は播磨国から摂津国へ帰ってゆく。

撮影物の中に混ざっていた謎の写真。恐らくカーレーターの乗降口にあるタイヤだと思う。

ロープウェイで下山。この日は三宮・姫路1dayチケットで来ており、姫路市立水族館でナマコを撫でる予定だったのだが、予定の時間をかなりオーバーしていた。

最終受付時間に間に合う電車に乗れるかどうかというぎりぎりのラインだったが、ロープウェイが降り切る寸前に電車が見えたので、この日は姫路に行かず帰ることにした。

一応ロープウェイを降りて走ったものの、改札口に着いた頃には電車の最後尾が過ぎ去るところで、まぁ無理だった。というか間に合ってもナマコ撫でる時間があったか疑わしい時間だったので仕方がない。

そして三宮方面ホームに着くと留置線から須磨浦公園発の特急が出てきたタイミングだったので、これで帰りましたとさ。

あとがき

ジャンルを旅行記にしているが、果たしてこの記事は旅行記なのか…?小旅行を増やすべきでは…?とか思ったが、深いことは考えないことにした。これ以上ジャンル増えても管理に困るし…。

「おでかけ」にジャンルをリネームするのも考えたが、おでかけにしては巨大すぎる記事もあるしなぁ…。よし、この話は忘れよう。

三宮・姫路1dayチケットが神過ぎる話

三宮・姫路1dayチケットは阪神三宮から山陽姫路が一日乗り放題になる企画乗車券だ。

本来阪神三宮から山陽姫路の往復運賃は1,920円だが、このチケットは1,590円で購入できるため、このチケットを使うことで安く往復できるうえ、更に途中下車し放題になる。

更に須磨浦山上遊園の入園料や一部の遊具利用が無料になるという特典まである。これは正規料金では1,500円するため、1,590円で須磨浦山上遊園の一部を無料で遊べて、更に三宮と姫路を往復できることになる。ついでにコンチェルトまたはルミナス神戸2で行われるクルージングの1,000円引きまでついてくる。

要するに1,590円で(1,920 + 1,500 + 1,000) - 1,590で2,830円ほどお得になる計算だ。電車賃分は途中下車すればするほど初乗り料金が相殺されるのでお得になる。

それで山陽電車は経営的に大丈夫なんか?という話もあるのだが、このチケットが売れても売れなくても電車と遊園地は回っており費用が掛かっているため、チケットが売れた時点で売れないよりはマシなのである。そして売るためには来てくれるよう安くする必要があるわけだ。

しかも客が遊園地に来れば飲食や、追加で観光リフトに乗ったり、カーレーターに乗りまくるなど、追加でお金を落としてくれる可能性もあることを考えれば、空気を運んで一円も入らないよりは割引してでも売って来てもらった方が収益に繋がるという話だ。この手のチケットは買ったけど使わないまま期限を迎える人もいるため、そういった埋没分も考えれば、売れれば売れるほど良く、成立するのだと思う。

ちなみに私が須磨浦山上遊園に初めて来たときも、このチケットがあったからこそ来たし、例外なくこのチケットで来ているので、有効活用している人物の一人である。しかもまんまと罠にハマって追加料金まで払ってる。でもそれでいいのだ。これでも正規料金より安いし、ここにも続いてほしいしね。

そして基本的に三宮から姫路に行くときはこのチケットを買っているので、時間に余裕があるときは遊びに来ている。とはいえ、姫路に用事があって暇な時というのもそんなにないので、寄れていないことの方が多くはあるが、3割くらいは来てると思う。

姫路市立水族館でナマコを撫でられなかった話

直近でやりたいことリストに書いているネタだが、これは後日触りに行ったので、また別で記事にしたいと思う。いや、でもこっちは大したネタではないので書かないかも…w

ひとまず今回は「書きたいけど書けてない日記のネタを書く」にある「須磨浦山上遊園に行った話」が書けたので良しとする。