はじめに
長年、インフラエンジニアとしてサーバーやネットワーク、データベースの構築に携わってきました。オンプレミスからクラウドまで、一通りの「基盤を作る」仕事はやってきたつもりです。
そんな自分が、ここ半年ほどAIエージェントという技術に触れて、正直かなり驚かされました。指示を出すと、調査をして、設計をして、実際に手を動かしてくれる。それも、こちらの意図をちゃんと汲み取りながら。
この驚きと可能性を、同じようにインフラの現場で長くやってきて、「クラウドやAIの流れに、正直ついていけていない」と感じている方に伝えたい。それがこのブログを始めた理由です。
今回の連載では、その第一歩として、このブログ自体をAIエージェントと一緒に構築した過程を記録していきます。技術解説というよりも、現場感のある「実況記録」として読んでもらえたら嬉しいです。
まず今回の構築では、役割を分担しました。全体の設計・記事の方向性・運用管理は自分(と、この記事を書いているClaude)が担当し、実際のサーバー操作やコーディングは、もう一つのAIエージェントであるCodexに任せています。人間ひとりと、AIエージェント二人という、なんとも不思議なチーム編成です。
サーバー契約、まっさらな状態からのスタート
まず最初に行ったのは、レンタルサーバーの契約です。今回はXserverを選びました。国内の実績、コストパフォーマンスに加えて、決め手になったのがタイミングです。実はXserverは2026年4月、サーバーパネルの主要な操作をAIエージェントや外部プログラムから直接実行できる「XServer API」の提供を始めたばかりでした。ドメイン設定やSSL、WordPressのインストールまで、これまで管理画面でポチポチやっていた作業がAPI経由で操作できる。しかも「AIエージェントからの利用」を明確に想定して作られている。これを見て、今回の構築はAIエージェントとの協働で進めるのに、うってつけの環境だと感じました。
契約直後のサーバーは、本当に何も乗っていない「空っぽ」の状態でした。独自ドメインは未設定、SSL証明書もなく、WordPressもまだインストールされていません。長年インフラを触ってきた身としては、この「まっさら」な状態を見ると、逆に少し胸が高鳴るところがあります。ここから何を積み上げていくか、という楽しみです。
今回は、この後の作業のほとんどを「APIファースト」で進める方針を決めました。管理画面をポチポチ操作するのではなく、可能な限りAPI経由で操作し、変更前に必ず現状を取得し、差分を確認し、明示的に実行を承認してから反映する、という手順です。これは自動化のためだけでなく、「何をやったか」を後から検証できる記録を残すためでもあります。生まれたばかりのXServer APIを、AIエージェントと一緒に実際の構築で使ってみる。その意味でも、今回の企画とはちょうど噛み合ったタイミングでした。
設計書のAPIパスが、実物と違っていた
「APIファーストで進める」と決めた直後、さっそく小さなズレに気づきました。事前にAIエージェントと一緒にまとめていたこの構築の設計書には、各操作のAPIパスがひととおり書かれていたのですが、これを公式のAPI仕様と突き合わせてみると、いくつかの項目で実物と食い違っていたのです。
たとえば、ドメインを追加する操作。設計書では/domainという短いパスになっていましたが、実際の公式仕様では/v1/server/{servername}/domainと、サーバーを一意に特定する情報が経路の中に含まれる形になっていました。WordPressの追加やSSLの設定など、他のいくつかの操作でも同様の差分がありました。
長年インフラをやっていると、「設計書とドキュメント、どちらを正とするか」という場面には何度も出くわします。今回の答えは単純で、設計書ではなく公式のAPI仕様書を正としました。事前にまとまった設計書があるのは心強い反面、それを鵜呑みにせず、実装の直前に必ず公式資料と照合する。この一手間を惜しまなかったことが、後々の余計なエラーを一つ減らしてくれたように思います。
ドメインをどう決めたか
ブログの顔となる独自ドメインは、reboot2ai.com に決めました。「AIとともにもう一度起動する(reboot)」という意味を込めています。仮のドメインで進めて後から変更する案もありましたが、最初から本番用のドメインで進めることにしました。中途半端な仮運用は、後の移行作業がむしろ手間になるという、長年の経験からくる判断です。
ドメインを追加する前に、隠れた関門があった
Cloudflareへネームサーバーを切り替える作業を進める中で、もう一つ知らなかった仕様に出会いました。Xserver側にドメインを追加するには、事前に「このドメインの持ち主です」と示すための確認TXTレコードを、外部から参照できる状態にしておく必要があったのです。
サーバー情報を取得すると専用の確認コードが払い出されていて、それを`_xserver-verify.reboot2ai.com`という名前のTXTレコードとしてCloudflare側のDNSに登録する、という段取りでした。地味な手順ですが、これを飛ばしたままドメイン追加のAPIを呼んでも、うまくいきません。
幸い、この手のドメイン所有権確認は長年ドメイン管理をしてきた身にはお馴染みの作法でした。確認コードは秘密情報として扱い、記録には残さない。この基本を守りながら、TXTレコードの登録、公開 DNSへの伝播確認と、順を追って進めていきました。
落とし穴:Cloudflareに乗せた瞬間、SSLの自動設定が動かなくなった
ここからが、今回一番「らしい」失敗談です。
ドメインの管理には、Cloudflareを使うことにしました。無料プランでも十分な機能があり、DNSの管理やセキュリティ面でのメリットも大きいためです。ドメインのネームサーバーを、Xserver標準のものからCloudflareのものへ切り替え、DNSレコードもAPI経由で準備しました。ここまでは順調でした。
次にサーバー側にドメインを追加し、SSL証明書も同時にAPI経由で設定しようとしました。ところが、このSSL設定だけが失敗するのです。
最初は「一時的な反映待ちかな」と考えて少し時間を置いてみましたが、状況は変わりません。調べていくと、Xserver側のSSL自動設定APIは、ネームサーバーがXserver自身のものである場合にしか使えない、という仕様に行き着きました。Cloudflareにネームサーバーを委任した時点で、この自動化の道が塞がれてしまうのです。
長年API連携の設計をやってきた身としては、「ドメインの権威がどこにあるか」によって使えるAPIが変わるというのは、言われてみれば当然の話です。ただ、これは事前のAPI仕様書だけを読んでいても気づきにくい、実際に手を動かして初めて分かる類の落とし穴でした。
手動対応と教訓
結局、この一点だけは方針を変え、サーバーの管理パネルから手動でSSLを有効化することにしました。「すべてAPIで自動化する」という理想からすると妥協にはなりますが、無理に自動化ルートを探すより、割り切って手動対応にする方が早く、そして安全でした。
この判断で個人的に大事にしたのは、「例外を認める基準をはっきりさせる」ことです。今回は「対応するAPIがそもそも存在しない操作」に限って手動を許可し、それ以外は引き続きAPI経由での操作を徹底する、というルールにしました。ここを曖昧にすると、「面倒だから手動でいいか」がどんどん増えていき、後から何をどう変更したのか追えなくなります。長年の運用経験の中で、そういう現場を何度も見てきました。
手動でSSLを有効化した後、ドメインへのアクセスがきちんとHTTPS化されているのを確認できたときは、地味ながらも、ちょっとした達成感がありました。
次回予告
サーバーとドメインの土台ができたところで、次はいよいよWordPressのインストールです。ところが、ここでもまた一筋縄ではいかない出来事が待っていました。WordPressの管理者権限での認証がなぜか通らず、原因を探っていく過程で、サーバー設定の奥深くに潜んでいた小さな見落としに気づく、という顛末です。
次回、「WordPress導入・SSL・認証編」でお伝えします。
コメント