雑談 – OSAKANA TAROのメモ帳

2026年6月24日2026年7月3日

SPAM対応メモ 2026/06/24

メールサーバに新しいメールが入ってこない、というので調査したら、特定ユーザのメールパスワードがばれていてSPAM送信に使われていたという時のメモ

(1) 落ちてるデーモンはいなかった

systemctl --failed

を実行した際に止まっているものはいなかった

(2) メールのキューに異常

postfixのメールキューの状態を確認

# postqueue -p

数万通のメールが滞留していた

差出人はほぼ1ユーザで、宛先は方々にわたる

(3) メール配送停止

ひとまず、postfixのメール配送処理を止める

# postfix abort

(4) ログ確認

/var/log/messagesと/var/log/maillog に対してそのユーザ名でgrepをかけて確認

roudcubeのログにて、roundcube内から多数のメールアドレスを指定してメール送信していることを確認

(5) アクセス者IPアドレス確認

ログから該当する操作のIPアドレスを確認し、そのアドレスがどこなのかを確認

今回は3IPアドレスからきており、どれも海外

(6) あからさまにSPAMを削除

今回特定の時間帯の送信は全部SPAMっぽかったので以下のコマンドで該当ユーザのメールをpostsuper -d queueIDで削除

# for queid in `postqueue -p|grep "Jun 24 04"  |grep ユーザ名|awk '{ print $1 }' | sed s/\*//ig`; do postsuper -d $queid; done

あと、MAILER-DAEMON関連の返送処理も削除

# for queid in `postqueue -p|grep MAILER|awk '{ print $1 }' | sed s/\*//ig`; do postsuper -d $queid; done

(7) とりあえず再開

2026年5月7日2026年7月3日

wordpressサーバの/var/lib/mysqlにbinlogファイルが大量にたまっていた

知り合いのとこのwordpressサーバが稼働していなかったので調査したところディスクフルが発生していた

状況を確認すると、 /var/lib/mysqlが15GBと大変な状態になっていた

binlogがたまりまくっていた

というか、4/23以降、一日1GB以上出力されたりしてるのなんでだ？？

[root@xxxxxxxxxxx mysql]# ls -ltr /var/lib/mysql/binlog*
-rw-r-----. 1 mysql mysql 1076027128 Apr 11 12:15 /var/lib/mysql/binlog.000401
-rw-r-----. 1 mysql mysql  895282121 Apr 23 06:48 /var/lib/mysql/binlog.000402
-rw-r-----. 1 mysql mysql 1076428654 Apr 23 19:12 /var/lib/mysql/binlog.000403
-rw-r-----. 1 mysql mysql  596357576 Apr 24 03:25 /var/lib/mysql/binlog.000404
-rw-r-----. 1 mysql mysql 1074553571 Apr 24 22:57 /var/lib/mysql/binlog.000405
-rw-r-----. 1 mysql mysql 1075609896 Apr 26 11:28 /var/lib/mysql/binlog.000406
-rw-r-----. 1 mysql mysql 1075981972 Apr 27 18:37 /var/lib/mysql/binlog.000407
-rw-r-----. 1 mysql mysql 1075913505 Apr 28 00:47 /var/lib/mysql/binlog.000408
-rw-r-----. 1 mysql mysql 1075838660 Apr 28 05:05 /var/lib/mysql/binlog.000409
-rw-r-----. 1 mysql mysql 1075205513 Apr 28 08:48 /var/lib/mysql/binlog.000410
-rw-r-----. 1 mysql mysql    5651277 Apr 29 23:47 /var/lib/mysql/binlog.000411
-rw-r-----. 1 mysql mysql    2052256 Apr 29 23:56 /var/lib/mysql/binlog.000412
-rw-r-----. 1 mysql mysql     101787 Apr 30 00:01 /var/lib/mysql/binlog.000413
-rw-r-----. 1 mysql mysql    3171581 Apr 30 03:19 /var/lib/mysql/binlog.000414
-rw-r-----. 1 mysql mysql 1074621728 May  3 02:47 /var/lib/mysql/binlog.000415
-rw-r-----. 1 mysql mysql 1074747087 May  5 18:27 /var/lib/mysql/binlog.000416
-rw-r-----. 1 mysql mysql 1074122275 May  6 01:02 /var/lib/mysql/binlog.000417
-rw-r-----. 1 mysql mysql 1076183303 May  6 16:09 /var/lib/mysql/binlog.000418
-rw-r-----. 1 mysql mysql 1074003040 May  7 01:08 /var/lib/mysql/binlog.000419
-rw-r-----. 1 mysql mysql        320 May  7 01:08 /var/lib/mysql/binlog.index
-rw-r-----. 1 mysql mysql  286409863 May  7 16:07 /var/lib/mysql/binlog.000420
[root@xxxxxxxxxxx mysql]#

とりあえず、binlog関連の設定を「show variables like ‘binlog%’;」を実行して確認してみる

[root@xxxxxxxxxxx mysql]# mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 50827
Server version: 8.0.45 Source distribution

Copyright (c) 2000, 2026, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show variables like 'binlog%';
+------------------------------------------------+--------------+
| Variable_name                                  | Value        |
+------------------------------------------------+--------------+
| binlog_cache_size                              | 32768        |
| binlog_checksum                                | CRC32        |
| binlog_direct_non_transactional_updates        | OFF          |
| binlog_encryption                              | OFF          |
| binlog_error_action                            | ABORT_SERVER |
| binlog_expire_logs_auto_purge                  | ON           |
| binlog_expire_logs_seconds                     | 2592000      |
| binlog_format                                  | ROW          |
| binlog_group_commit_sync_delay                 | 0            |
| binlog_group_commit_sync_no_delay_count        | 0            |
| binlog_gtid_simple_recovery                    | ON           |
| binlog_max_flush_queue_time                    | 0            |
| binlog_order_commits                           | ON           |
| binlog_rotate_encryption_master_key_at_startup | OFF          |
| binlog_row_event_max_size                      | 8192         |
| binlog_row_image                               | FULL         |
| binlog_row_metadata                            | MINIMAL      |
| binlog_row_value_options                       |              |
| binlog_rows_query_log_events                   | OFF          |
| binlog_stmt_cache_size                         | 32768        |
| binlog_transaction_compression                 | OFF          |
| binlog_transaction_compression_level_zstd      | 3            |
| binlog_transaction_dependency_history_size     | 25000        |
| binlog_transaction_dependency_tracking         | COMMIT_ORDER |
+------------------------------------------------+--------------+
24 rows in set (0.00 sec)

mysql>

17.1.6.4 バイナリロギングのオプションと変数を参照するとbinlog_expire_logs_secondsが関連する設定で、これが”binlog_expire_logs_seconds=2592000″ なので 720時間(30日)の保存となっている

「show binary logs;」を実行して、mysql内部で認識されているbinlog一覧を確認。まあ、/var/lib/mysql以下にあるファイルと一致してますね

mysql> show binary logs;
+---------------+------------+-----------+
| Log_name      | File_size  | Encrypted |
+---------------+------------+-----------+
| binlog.000401 | 1076027128 | No        |
| binlog.000402 |  895282121 | No        |
| binlog.000403 | 1076428654 | No        |
| binlog.000404 |  596357576 | No        |
| binlog.000405 | 1074553571 | No        |
| binlog.000406 | 1075609896 | No        |
| binlog.000407 | 1075981972 | No        |
| binlog.000408 | 1075913505 | No        |
| binlog.000409 | 1075838660 | No        |
| binlog.000410 | 1075205513 | No        |
| binlog.000411 |    5651277 | No        |
| binlog.000412 |    2052256 | No        |
| binlog.000413 |     101787 | No        |
| binlog.000414 |    3171581 | No        |
| binlog.000415 | 1074621728 | No        |
| binlog.000416 | 1074747087 | No        |
| binlog.000417 | 1074122275 | No        |
| binlog.000418 | 1076183303 | No        |
| binlog.000419 | 1074003040 | No        |
| binlog.000420 |  319677238 | No        |
+---------------+------------+-----------+
20 rows in set (0.02 sec)

mysql>

まず最初として、「set PERSIST binlog_expire_logs_seconds=604800;」を実行してbinlog_expire_logs_secondsを7日間に短縮する

mysql> set PERSIST binlog_expire_logs_seconds=604800;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'binlog%';
+------------------------------------------------+--------------+
| Variable_name                                  | Value        |
+------------------------------------------------+--------------+
| binlog_cache_size                              | 32768        |
| binlog_checksum                                | CRC32        |
| binlog_direct_non_transactional_updates        | OFF          |
| binlog_encryption                              | OFF          |
| binlog_error_action                            | ABORT_SERVER |
| binlog_expire_logs_auto_purge                  | ON           |
| binlog_expire_logs_seconds                     | 604800       |
| binlog_format                                  | ROW          |
| binlog_group_commit_sync_delay                 | 0            |
| binlog_group_commit_sync_no_delay_count        | 0            |
| binlog_gtid_simple_recovery                    | ON           |
| binlog_max_flush_queue_time                    | 0            |
| binlog_order_commits                           | ON           |
| binlog_rotate_encryption_master_key_at_startup | OFF          |
| binlog_row_event_max_size                      | 8192         |
| binlog_row_image                               | FULL         |
| binlog_row_metadata                            | MINIMAL      |
| binlog_row_value_options                       |              |
| binlog_rows_query_log_events                   | OFF          |
| binlog_stmt_cache_size                         | 32768        |
| binlog_transaction_compression                 | OFF          |
| binlog_transaction_compression_level_zstd      | 3            |
| binlog_transaction_dependency_history_size     | 25000        |
| binlog_transaction_dependency_tracking         | COMMIT_ORDER |
+------------------------------------------------+--------------+
24 rows in set (0.00 sec)

mysql>

ただ、設定を変更しただけでは反映されないようで、10分程度待機しただけでは show binary logs;の結果に変化はなかった

mysql> show binary logs;
+---------------+------------+-----------+
| Log_name      | File_size  | Encrypted |
+---------------+------------+-----------+
| binlog.000401 | 1076027128 | No        |
| binlog.000402 |  895282121 | No        |
| binlog.000403 | 1076428654 | No        |
| binlog.000404 |  596357576 | No        |
| binlog.000405 | 1074553571 | No        |
| binlog.000406 | 1075609896 | No        |
| binlog.000407 | 1075981972 | No        |
| binlog.000408 | 1075913505 | No        |
| binlog.000409 | 1075838660 | No        |
| binlog.000410 | 1075205513 | No        |
| binlog.000411 |    5651277 | No        |
| binlog.000412 |    2052256 | No        |
| binlog.000413 |     101787 | No        |
| binlog.000414 |    3171581 | No        |
| binlog.000415 | 1074621728 | No        |
| binlog.000416 | 1074747087 | No        |
| binlog.000417 | 1074122275 | No        |
| binlog.000418 | 1076183303 | No        |
| binlog.000419 | 1074003040 | No        |
| binlog.000420 |  358509579 | No        |
+---------------+------------+-----------+
20 rows in set (0.00 sec)

mysql>

13.4.1.1 PURGE BINARY LOGS ステートメントにあるように手動で「PURGE BINARY LOGS BEFORE ‘2026-05-01 00:00:00’;」と実行すれば2026/05/01以前のbinlogが削除されるのだと思うんだけど・・・ということで実行

mysql> PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00';
Query OK, 0 rows affected (0.02 sec)

mysql> show binary logs;
+---------------+------------+-----------+
| Log_name      | File_size  | Encrypted |
+---------------+------------+-----------+
| binlog.000415 | 1074621728 | No        |
| binlog.000416 | 1074747087 | No        |
| binlog.000417 | 1074122275 | No        |
| binlog.000418 | 1076183303 | No        |
| binlog.000419 | 1074003040 | No        |
| binlog.000420 |  377894939 | No        |
+---------------+------------+-----------+
6 rows in set (0.00 sec)

mysql>

ファイルは・・・削除されていますね

[root@xxxxxxxxxxx mysql]# ls -ltr /var/lib/mysql/binlog*
-rw-r-----. 1 mysql mysql 1074621728 May  3 02:47 /var/lib/mysql/binlog.000415
-rw-r-----. 1 mysql mysql 1074747087 May  5 18:27 /var/lib/mysql/binlog.000416
-rw-r-----. 1 mysql mysql 1074122275 May  6 01:02 /var/lib/mysql/binlog.000417
-rw-r-----. 1 mysql mysql 1076183303 May  6 16:09 /var/lib/mysql/binlog.000418
-rw-r-----. 1 mysql mysql 1074003040 May  7 01:08 /var/lib/mysql/binlog.000419
-rw-r-----. 1 mysql mysql         96 May  7 16:25 /var/lib/mysql/binlog.index
-rw-r-----. 1 mysql mysql  383435241 May  7 16:25 /var/lib/mysql/binlog.000420
[root@xxxxxxxxxxx mysql]#

とりあえずしのいだので、次はなぜ4/23以降でbinlogが肥大化したのか調査ですね・・・

2026/05/11追記

原因がはっきりしないのだが、wordpressのプラグインで更新されていなかったものがあったので、アップデートを5/8に実施したところ、ファイルの増加量が減っていた

[root@xxxxxxxxxxx ~]# ls -ltr /var/lib/mysql/bin*
-rw-r-----. 1 mysql mysql 1074747087 May  5 18:27 /var/lib/mysql/binlog.000416
-rw-r-----. 1 mysql mysql 1074122275 May  6 01:02 /var/lib/mysql/binlog.000417
-rw-r-----. 1 mysql mysql 1076183303 May  6 16:09 /var/lib/mysql/binlog.000418
-rw-r-----. 1 mysql mysql 1074003040 May  7 01:08 /var/lib/mysql/binlog.000419
-rw-r-----. 1 mysql mysql 1074323672 May  8 03:18 /var/lib/mysql/binlog.000420
-rw-r-----. 1 mysql mysql 1073965591 May  8 16:47 /var/lib/mysql/binlog.000421
-rw-r-----. 1 mysql mysql 1074897443 May 10 12:39 /var/lib/mysql/binlog.000422
-rw-r-----. 1 mysql mysql        128 May 10 12:39 /var/lib/mysql/binlog.index
-rw-r-----. 1 mysql mysql  576882057 May 11 14:17 /var/lib/mysql/binlog.000423
[root@xxxxxxxxxxx ~]#

さらに翌日確認して、間違いなく増加率が激減していることを確認した

[root@xxxxxxxxxxx ~]# ls -ltr /var/lib/mysql/bin*
-rw-r-----. 1 mysql mysql 1074747087 May  5 18:27 /var/lib/mysql/binlog.000416
-rw-r-----. 1 mysql mysql 1074122275 May  6 01:02 /var/lib/mysql/binlog.000417
-rw-r-----. 1 mysql mysql 1076183303 May  6 16:09 /var/lib/mysql/binlog.000418
-rw-r-----. 1 mysql mysql 1074003040 May  7 01:08 /var/lib/mysql/binlog.000419
-rw-r-----. 1 mysql mysql 1074323672 May  8 03:18 /var/lib/mysql/binlog.000420
-rw-r-----. 1 mysql mysql 1073965591 May  8 16:47 /var/lib/mysql/binlog.000421
-rw-r-----. 1 mysql mysql 1074897443 May 10 12:39 /var/lib/mysql/binlog.000422
-rw-r-----. 1 mysql mysql        128 May 10 12:39 /var/lib/mysql/binlog.index
-rw-r-----. 1 mysql mysql  867993952 May 12 11:46 /var/lib/mysql/binlog.000423
[root@xxxxxxxxxxx ~]#

2026/05/21追記

落ち着いたかと思ったら、またかーーー

-rw-r-----. 1 mysql mysql         56 Nov 16  2021  auto.cnf
-rw-r-----. 1 mysql mysql  880718553 May 14 03:39  binlog.000424
-rw-r-----. 1 mysql mysql 1074983980 May 15 22:05  binlog.000425
-rw-r-----. 1 mysql mysql 1074458947 May 16 01:00  binlog.000426
-rw-r-----. 1 mysql mysql 1076353655 May 16 04:11  binlog.000427
-rw-r-----. 1 mysql mysql 1075894927 May 16 11:45  binlog.000428
-rw-r-----. 1 mysql mysql 1076430757 May 16 20:30  binlog.000429
-rw-r-----. 1 mysql mysql 1074418130 May 17 01:11  binlog.000430
-rw-r-----. 1 mysql mysql 1075734983 May 17 17:52  binlog.000431
-rw-r-----. 1 mysql mysql 1074210923 May 18 13:17  binlog.000432
-rw-r-----. 1 mysql mysql 1074818836 May 18 19:42  binlog.000433
-rw-r-----. 1 mysql mysql 1075645558 May 19 00:18  binlog.000434
-rw-r-----. 1 mysql mysql 1074848030 May 19 10:46  binlog.000435
-rw-r-----. 1 mysql mysql 1075579091 May 19 15:20  binlog.000436
-rw-r-----. 1 mysql mysql 1076234338 May 19 20:25  binlog.000437
-rw-r-----. 1 mysql mysql  618166201 May 20 03:45  binlog.000438
-rw-r-----. 1 mysql mysql 1075233776 May 20 15:03  binlog.000439
-rw-r-----. 1 mysql mysql 1076237754 May 20 18:18  binlog.000440
-rw-r-----. 1 mysql mysql 1074276162 May 20 21:19  binlog.000441
-rw-r-----. 1 mysql mysql  227580182 May 21 11:19  binlog.000442
-rw-r-----. 1 mysql mysql        304 May 20 21:19  binlog.index

もう set PERSIST binlog_expire_logs_seconds=1; を設定してしまおう・・・・(0が無限扱いだといやなので数値入れとくか的な)

mysql> set PERSIST binlog_expire_logs_seconds=1;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'binlog%';
+------------------------------------------------+--------------+
| Variable_name                                  | Value        |
+------------------------------------------------+--------------+
| binlog_cache_size                              | 32768        |
| binlog_checksum                                | CRC32        |
| binlog_direct_non_transactional_updates        | OFF          |
| binlog_encryption                              | OFF          |
| binlog_error_action                            | ABORT_SERVER |
| binlog_expire_logs_auto_purge                  | ON           |
| binlog_expire_logs_seconds                     | 1            |
| binlog_format                                  | ROW          |
| binlog_group_commit_sync_delay                 | 0            |
| binlog_group_commit_sync_no_delay_count        | 0            |
| binlog_gtid_simple_recovery                    | ON           |
| binlog_max_flush_queue_time                    | 0            |
| binlog_order_commits                           | ON           |
| binlog_rotate_encryption_master_key_at_startup | OFF          |
| binlog_row_event_max_size                      | 8192         |
| binlog_row_image                               | FULL         |
| binlog_row_metadata                            | MINIMAL      |
| binlog_row_value_options                       |              |
| binlog_rows_query_log_events                   | OFF          |
| binlog_stmt_cache_size                         | 32768        |
| binlog_transaction_compression                 | OFF          |
| binlog_transaction_compression_level_zstd      | 3            |
| binlog_transaction_dependency_history_size     | 25000        |
| binlog_transaction_dependency_tracking         | COMMIT_ORDER |
+------------------------------------------------+--------------+
24 rows in set (0.00 sec)

mysql> perge binary logs before '2026-05-20 00:00:00';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'perge binary logs before '2026-05-20 00:00:00'' at line 1
mysql> purge binary logs before '2026-05-20 00:00:00';
Query OK, 0 rows affected (0.12 sec)

mysql> show binary logs;
+---------------+------------+-----------+
| Log_name      | File_size  | Encrypted |
+---------------+------------+-----------+
| binlog.000438 |  618166201 | No        |
| binlog.000439 | 1075233776 | No        |
| binlog.000440 | 1076237754 | No        |
| binlog.000441 | 1074276162 | No        |
| binlog.000442 |  234276939 | No        |
+---------------+------------+-----------+
5 rows in set (0.00 sec)

mysql> purge binary logs before '2026-05-21 00:00:00';
Query OK, 0 rows affected, 1 warning (0.05 sec)

mysql> show binary logs;
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000442 | 234276939 | No        |
+---------------+-----------+-----------+
1 row in set (0.00 sec)

mysql>

2025年7月19日2025年12月1日

Switch2のTV出力に対応したHAGiBiS SWC10を買った

Switch2の入手に成功

で・・・実家に帰った時に簡単にTV出力ができるように持ち運びやすいアダプターが欲しいな、と思っていたところに 8769さんから HAGiBiS SWC10 がSwitch2対応だよ、というお話が・・・

8796.jp管理日誌「HAGiBiS SWC10は安価なNintendo Switch 2対応互換ドックという話」

とりあえずaliexpressで発注 https://ja.aliexpress.com/item/1005008165019787.html

2025/07/12発注で7/19到着

まさかHAGiBiS自社ロゴ入りの梱包袋で届くとは驚きです

中身はアダプター本体と説明書

とりあえず届いた状態でSwitch2で動作確認

特に問題なくTVに表示されました

念のため、SWC10のfirmwareをアップデートしてみます

「Switch2 投屏固件 | TV Mode Firmware」

1105342383542763520.zipというファイル名で、中には CS5563_65_69_V20.00.34.00_803400 というディレクトリが・・・

8769さんの時はV20.00.32だったようなのでこっそりアップデートしているようです

2025/12/01時点では Switch2系统更新21.0.0后投屏问题（最新解决方案汇总）から Hagibis 8K60Hz 20251113.zip をダウンロードして使用します。

パソコンとの接続は電源用ということになっているType-Cで行います

パソコン側ではUSB Type-C Digital AV Adapter (USB\VID_343C&PID_0000\000000000000)として認識されました

firmwareアープデータの ASL自动升级工具1.40.exe を実行していると、デバイスを認識すると有無も言わさずアップデートが開始されます

アップデートが終わると下記のような緑となります

なお、アップデートする必要がない場合は下記のように黄色になりました

アップデートしたあとでSwitch2につないでみましたが、特になにか変わったという実感はありませんでした

とりあえずこれで持ち運びもしやすくて安心です

2025年2月11日

Amazon Fire TVでSteam Linkは普通にインストールできる

Amazon Fire TVでSteam Link使ってパソコン上のSteamゲームを遊べないのかな？とぐぐってみると、開発者モードを有効にしてAPKファイルをインストールする、なんて話が出てくる

が・・・試しにAmazonアプリストアで検索してみると、普通にSteam Linkが出てくる

どうやら、2024年10月9日に登録されたらしい

というわけで、記述が古い開発者モードを有効にして、なんて書いてある記事に騙されないようにしましょう

2023年3月6日2023年3月6日

伊勢神宮内宮神域にある鏡岩に行ってみた

昭和の終わりごろ親の転勤のつごうで伊勢市に住んでいた時期がある。

小学校か中学校の遠足で、伊勢神宮内宮から高麗広方面にいく途中にある鏡岩というところまで歩いて行く、というものがあった。

いまはどうなってるんだろう？と思って検索してみると、道は整備されておらず荒れているらしい。

実際のところどうなんだろ？と思って、2023年3月5日に行ってみました。

レンタサイクルを借りて内宮宇治橋前から団体バス駐車場を横切って

高麗広への道に突入。

ちなみに、この道。CBCテレビでやっている「道との遭遇」という番組で紹介されたりしています→「険道・三重県伊勢市～度会郡南伊勢町に伊勢神宮から直結の狭すぎる道が！ジャニーズJr.「7 MEN 侍」佐々木くんが険道走る。先行映像公開！」

すぐに内宮御手洗場の対岸を通るのですが、木々に遮られて写真としてはうまく撮れず・・・

また、途中にある建設会社の資材置き場の横にある道なんですが

謎の石の飛び橋ルートが見えたりしていました

対岸は広くなっていましたが、いまは何も残っていませんでした

川を渡って広場までいくのを動画で撮ったモノがこちら

謎の川越えルート pic.twitter.com/oagKQkCE0x
— OSAKANA TARO (@osakanataro2) March 4, 2023

帰ってきてから調べて見ると「宮川水系五十鈴川流域の砂防～伊勢神宮宮域内の砂防～」という三重県の資料で平成3年～6年にかけて施行した「景観に配慮した護岸工」と紹介されていました。

この写真が撮られた時期はまだ田んぼかなにかやってたようですね

進んでいくと、いきなりいままでの細い道が災害復旧で丈夫な感じになってたり・・・

こちらは整備されなくなって石に埋もれつつある旧道

さらにすすんでいくと右側に水飲み場という標識があります。

ただ、水としては冷たいという感じではありませんでした。

さらに進むとこんな感じで開けた場所に出ます。なにか栽培とかしているようです。

あとで分かるのですが、ここで見える対岸の川原が鏡岩のあたりだったのですが、残念ながらここから川を渡るルートが存在していません。

じゃあ、どこからなら対岸に渡れるのかと言えば、もっと上流にしばらく進んだところにあるこの分岐を下に行きます

降りて橋を渡り・・

橋を渡ってすぐ左側の道を入って、下流側/内宮に向けて歩いて行きます。

途中、倒木があったり

なかなかやばい感じの木橋があったり

というか、これ、もうすぐ折れる予感がします・・・

鏡岩アドベンチャー橋 pic.twitter.com/KN40pIcccy
— OSAKANA TARO (@osakanataro2) March 4, 2023

まあ、折れても下は水がなく、高低差もなんとかなる程度なので渡れますけどね

橋を越えて少しいくと左側にカーブした感じで石垣がある開けた場所がありますが、そこを超えてさらに下流側へ進んでいきます。

しばらく進むと川からちょっと高度があがり、左側に岩が見える出っ張りがあります。

この出っ張りの少し先の下流側に目的地の鏡岩があります。

鏡岩には２つの見るポイントがあります。１つ目

↑の写真の左側にはお社があります。

なんか、明治になるまではこのお隣にもう１つお社があったらしいです。

で、鏡岩と呼ばれるところは↓の右側部分です

上からだとわかりにくいですが、階段があるのでそこを降りて行くことができます

下から見るとこんな感じです。

鏡岩の全体像としてはこんな感じです。

昭和終わりの時点で、どこが鏡？？？という感想を持っていましたが、そこから３０年以上が経過した現時点では、さらにうーん、という感じになっていますね。

かつてはこのあたりがもっと鏡っぽく見えたのかもしれません・・・

下流側の川から鏡岩のある方向を見てみますとこんな感じです。

この写真のどこに鏡岩があるのかというと↓の赤丸の部分です

鏡岩付近を動画で pic.twitter.com/0u7DHBNag8
— OSAKANA TARO (@osakanataro2) March 4, 2023

まあ、見てのとおりに清流感はすごいです。

鏡岩の川側は、ごつごつしていて木もはえてるので見栄えはよくありません。

で・・・ここから下流側を見ると・・・

対岸にひらけたところが見えますね。上から撮った写真に見えたブルーシートっぽい物体も↓にあります。

ここに橋があれば簡単に鏡岩に行けるのに、といった感じの場所でした。

下流側に少し進んだら対岸の道が近いところに…
短絡ルート作れば再び鏡岩遠足ができるのでは？ pic.twitter.com/grTZyEpn7m
— OSAKANA TARO (@osakanataro2) March 4, 2023

もしかして、災害で山崩れとかがあってこんなにひらけた感じになったのかと思い、伊勢市の「土砂災害ハザードマップ（伊勢市宇治今在家町高麗広地区）」を確認してみましたが、この付近については特に崖崩れの恐れについては触れられていませんでした。

そんなわけで、今回の鏡岩探索は、距離としては片道 6kmぐらいで、今回は自転車移動だったので片道約１時間での旅という感じでした。

現在はまだ木橋が使える状態ですが、恐らくもうすぐ寿命がなくなりそうなのと、夏は草が生えて大変になりそう、というのもあって、なかなか訪問にはツライ場所じゃないかと思います。

10:58 宇治橋前出発
11:05 謎の飛び石橋発見
11:12 出発
11:21 水飲み場
11:24 ひらけたところ(鏡岩対岸。仙人下橋)
11:28 分岐
11:30 自転車を置いて徒歩移動開始
11:32 木橋
11:34 カーブの石垣
11:38 鏡岩到着
12:16 撤収
12:23 カーブの石垣
12:24 木橋
12:28 自転車回収
12:35 ひらけたところ(鏡岩対岸。仙人下橋)
12:40 水飲み場
12:53 宇治橋前

ということで、鏡岩手前から神路山方面を望んだ写真でこの記事を締めさせていただきます。