旧ドメイン(nikki-san.fc2.net)のサイトは白紙になりました

もともと9/10に予告していた作業ですが、4日早く今日やってしまいました。

Google Search Consoleの180日間の「アドレス変更」プロセスが9/4にすでに終わっていたというのと、9/10あたりはClaude Codeの週枠が切れてしまって付随作業ができなくなっているかもしれなかったから。

FC2ブログからのHTTP 301転送は手で止めて、それを前提としていた受け側のしくみも全部削除しました。

掲示板等に書かれた旧ドメインの個別エントリ宛のリンクはJavascriptでの転送で救済しますが、トップ含むそれ以外のパスへのアクセスは、白紙ページを返すだけにしています。

Claude Codeに自宅のProxmox VE上での基盤構築作業をしてもらう

独自ドメインのアドレスからメールを送る機能がGmailからなくなってしまうということで、以前Cloudflare Workersを使って自前でメール送信システムを作ってもらっていました。

でもちょっと気にかかっていたのが、SMTPサーバがMailgunという外部サービス依存だというところ。

今メール送信なんて1年に1回あるかないかぐらいやけど、必要なときって航空会社のヘルプデスクへの問い合わせとかけっこうせっぱ詰まってるときだったりするので、安定して使えるようにバックアップ環境もほしいところ。

送信専用だったら自宅サーバにその機能を持たせてもいいんじゃない?ということでやってみました。

AIエージェントにVM構築してもらう

うちのProxmox VE環境をClaude CodeさんからSSHで直接操作してもらえるようなルートを先日構築していたけれど、VMを作るという基盤作業も向こうからやってもらえたりするんかな?

ということで相談してみると、あまり大きな権限を与えなくてもできそうなことがわかりました。

Ansibleでサーバにファイルを配布したり、root権限のいるセットアップスクリプトを実行したりするのはこちらの作業。コマンドをちょこっと打つぐらい。あとはAIエージェント側で勝手に動いてくれて、メール送信環境が完成!VMの入れ物ぐらいはこちらで作らないといけないかと思っていたら、それもやってくれました。

もともとはグローバルIPアドレスが露出している奈良の実家側に実装するつもりだったんですが、プロバイダ側の制約なのか、メールサーバ間通信用の25/TCPのポート宛に出ていけないということがAIエージェントの自主チェックで判明。千葉側の環境でやりましょうということになりました。

それなりにチャットの往復はあったけど、基盤構築も半自動みたいな形でできてしまうんやねー。らくらく。

SMTPサーバを自宅に置く影響

今回SPF・DKIM・DMARCは一応実装しています。一般回線のIPアドレスだからということで受信拒否されるアドレス(観測範囲内ではInfomaniak Mail)もあったんですが、Yahoo.comやGmailには届きました。
(グローバルIPアドレスは共用だと思うので、同じアドレスを共用するところからうちのドメインを騙ったにせメールを出されるとSPF検証だけは通ってしまうけど、これが限界。そんなこと起こらないだろうと割り切ります。)

そしてDuck Addressにはブロックされなかったので、Duck AddressをFromとしたメールを送るのは宛先関係なく問題なくできそうです。
(Duck Addressを通すと、そこから先の転送メールでは、ヘッダから本当の送信元の情報が消されるので。)

Claude Codeに家のネットワークを直接見てもらう

Claude Codeは、本来プログラムのソースコードを作るためのサービスなんですが、

自前のMCP(AIエージェントからほかのシステムを動かすしくみ)を作ることで、自宅サーバ上のブラウザを操作してもらうことができたというのがこの前までの話。

それができるのなら、自宅ネットワークの機器にSSHで入って直接操作してもらうこともできるんじゃない?ということで、ちょっと機能拡張してみました。

いつでも入れるようにはせず、入っても許可した操作だけできるように縛りを一応かけています。

ネットワークの不具合を診断してもらう

千葉の家と奈良の実家の間は常時TailscaleでVPN接続されていて、ふだんはその回線を使って遠隔操作しているのですが、とある特定の通信だけなぜか失敗するという謎の現象に悩まされてきていました。

常設のTailscale回線に頼らず、代わりにTrustTunnelとか使えば回避できるのでなんとかはなっていたんですが、これが微妙にめんどくさい。

そこで今回関連機器の操作権限を与えて、Claude Opus 5さんに調査を依頼してみました。

何をやっているかはリアルタイムで見えるんですが、作業速っ!通信テストとかをさくさくやって、「この部分が原因ではない」「この部分も原因ではない」とどんどん切り分けていきます。

遠隔操作できないChromebook側の操作もいるので、それはこちらの作業で。

本物のネットワークエンジニアとやっていることは同じといえば同じなんですが、プロトコルの癖に引っかかるような絶妙なテスト設計とか、ログのミリ秒単位の突き合わせとか、人なら何日もかけてじっくり取り組むようなことを見る間に片づけていきます。

この問題は以前ChatGPTに解析してもらってもよくわからず迷宮入りしていたんですが、今回Opusさんの協力で半日ぐらいかけてようやく原因に到達。問題解消!

Tailscaleじゃなくて、まさかのpfSenseの特殊挙動のせいやったんか〜(>_<)

千葉豪雨でなぜ行徳島はほぼ無傷だったのか?

今日はもう夏は終わったんじゃないかという気候だったので、ひさびさに江戸川の東岸側まで自転車で回ってみました。

それでやっぱり気になっていたのが、8/13の千葉豪雨のこと。

あのとき市川市にもレベル5大雨特別警報が出ていて、江戸川の東側にはけっこうな被害が出ていたところがあるのに、西側がほぼ無傷だったのはなんでなんやろ?

なんとなく見えてきたことはありました。

立地

市川市のうち江戸川の西側は、ローカルで「行徳島」と呼ばれているエリアの中にあります。東は江戸川、北と西は旧江戸川で周りから隔離されています。

江戸川も旧江戸川もどちらも河口堰的なものより下流側に位置していて、水位はほぼ海面。上流側がいくら増水しても、堤防を水が越えたりはしにくい立地にはなっていそうです。

土地のフラットさ

IMG_20260830_141522

江戸川の東側って、一見フラットに見えているところにも、意外とゆるやかなアップダウンがあったりします。この影響はけっこう大きそう。

たとえば1時間に50mmの雨が降ったとして、排水溝とかもない完全にフラットな地形であれば、全域に50mm水がたまるだけです。

でもアップダウンがあって、水が全体の10%のエリアに集まるようなことがあれば、そのエリアは500mmの水位アップになるわけなので。

IMG_20260830_143101

対して行徳島はまったくといっていいほどアップダウンがない平坦な地形に見えます。どっち方向に行くにしても、自転車はこがないと進まないです。

国土地理院の赤色立体地図で見ても、ディズニーランドのビッグサンダーマウンテン(?)あたりにしか傾斜が見えないです。

排水能力

東側の排水能力がどのぐらいだったかはわからないけれど、西側の情報は一部見つかりました。

IMG_20260830_143351

IMG_20260830_143436

旧江戸川ぞいにはいくつか排水機場があって、たとえばこの本行徳排水機場は本行徳・本塩という地区を担当しているようです。看板にも書いてあるけれど、排水は自然にはほとんどされないそうなので、こういった施設頼み。

そして時間雨量50mmまで排水できる能力があるそうです。

千葉豪雨では、時間雨量50mmを超えたのは8/13の19時までの1時間だけ。

つまり、それ以外の時間帯このエリアに関しては、この排水機場が稼働していれば水はたまらない。そして時間雨量110mmぐらい降った1時間でも、処理オーバー分の60mmしかたまらないし、しかも地形がフラット。そのあとは時間雨量50mmを切っているので、たまっていたとしても減っていくだけ。

厳密ではないにしても、ざっくりこんな感じだったってことかな。なるほどねー。

排水が排水機場頼みということは、このあたりが停電してたらまたちょっとちがったのかも。

ブログをCloudflare PagesからWorkersに乗り換える準備を始める

今のブログ環境はCloudflare Workers & Pagesの"Pages"の方で動かしていますが、それは当時ChatGPTにおすすめされたから。

Are you sure you want to use Pages?

Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare’s primary platform for building applications. Start new projects with Workers.

(DeepL訳:本当にPagesを使いたいですか?Workersは、Pagesのほとんどのユースケースに対応しており、より幅広い機能セットを提供しています。Workersは、Cloudflareがアプリケーション構築のために提供する主要なプラットフォームです。新しいプロジェクトはWorkersで始めましょう。)

でもPagesのあとから出たっぽいWorkersがPagesの機能を飲み込んでいっていて、今さらPagesを選ぶ理由なんてないという雰囲気を感じます。しかもそれはごく最近の話でなく、去年の4月ぐらいからそういう状態だったみたいです。

もしかして、引っ越し先をまちがえた?

それで今さらChatGPTに聞いてみたんですが、

2026年2月に新規でHugoサイトをCloudflare上に構築するなら、PagesではなくWorkers Static Assetsを選ぶべきでした。

と反省していました。

それなら9/10の作業のあとでWorkersに乗り換えてしまおう!ということで、いろいろ準備作業をしていました。

たぶん9/11にWorkers化すると思うんですが、そのあたりでこのブログにつながらなくなったら「あー、なんかミスったんやな」と察してください。うまくいっても見た目は何も変わらないと思うんですが、思った以上に大がかりな作業です。

追記 2026/09/07
予定よりちょっと早く乗り換えました。