Aレコードが新しいサーバーを指した。次はHTTPSだ。https://example-gallery.jp を、鍵のかかったアドレスにする。
Let's Encryptで証明書を取る。コマンドは一行だ。
certbot --nginx -d example-gallery.jp -d www.example-gallery.jp実行した。失敗した。
証明書は、古いサーバーを見ていた
エラーには、（旧サーバーのIP） という見覚えのある数字が並んでいた。引っ越す前の、古いサーバーのIPだ。
証明書を出す側は、本当にこのドメインがこのサーバーのものかを確かめるために、ドメインに対してアクセスしてくる。そのとき返ってきたIPが、まだ古い方だった。Aレコードは変えたはずなのに。
ネームサーバーを四台、一台ずつ直接聞いてみた。01.dnsv.jp は新しいIPだけを返した。正しい。だが 02.dnsv.jp と 03.dnsv.jp は、新しいIPと古いIPの両方を返していた。
DNSの変更は、一台に書けば終わりではない。主たるサーバーから、控えのサーバーへ、設定が転送されて初めて全体が揃う。その転送が、まだ途中だった。私は変更を終えたつもりで、ネットワークの方はまだ書き換えの最中だった。
待つ、という作業
やることは、なかった。待つだけだった。
二十分ほどおいて、もう一度四台に聞いた。今度は全部が、新しいIPだけを返した。転送が終わっていた。
certbot をもう一度走らせると、今度はすんなり通った。証明書が発行され、HTTPは自動でHTTPSに転送されるようになった。期限は九十日、自動更新も仕込まれている。
詰まった原因は、自分のコマンドでも、サーバーの設定でもなかった。ただ、ネットワークが追いつくのを待てばよかった。エンジニアの仕事には、手を止めて待つのが正解、という時間がときどきある。焦って何度コマンドを打っても、転送は早まらない。
人にも、AIにも読めるように
最後に、検索エンジンとAIに向けた仕込みをした。
ページの裏側に、構造化データを置く。これは画家であること、名前は「その画家」と読むこと、活動の拠点、個展の履歴。人間が読む本文とは別に、機械が読むための同じ情報を、決まった形式で書いておく。
"@type": ["Person", "Artist"],
"name": "その画家",
"jobTitle": "画家・アーティスト"最近は、検索する人だけでなく、AIがページを読んで誰かの質問に答える。そのとき、機械が迷わず「この人は画家のその画家だ」と分かる手がかりを、ページ自身が持っていた方がいい。OGP、サイトマップ、作品画像のひとつひとつに付けた説明文。派手さはない。けれど、見つけてもらうための地味な下ごしらえだ。
絵は、見られて初めて作品になる。サイトも、たどり着かれて初めて意味を持つ。
白い壁を建て、絵を掛け、ドメインを移し、鍵をかけ、機械にも読めるようにした。画家のサイトが、世界に向いて開いた。
画家サイト制作記 Vol.1は、ここまで。次のシリーズでまた、別の誰かの仕事を、コードで形にした話を書く。
シンプルシステム株式会社 代表 伊藤勝彦