開発者であれば、最近のAIの素晴らしさはおおよそご存知でしょう。誇張はここでは避けます。
私が選ぶ武器はCodexです。他にもAIコーディングツールはありますが、どれが何に優れているかを議論することは、私にはあまり興味深い話ではありません。ここで焦点を当てたいのはDevOpsです。
私は小さな会社のCTOであり、いろいろな役割を兼任します。以前は自分をバックエンド開発者と呼んでいましたが、現在は技術関連のことはほとんど何でも担当し、マーケティング、営業、その他の支援的な役割もこなしています。会社には数名しかおらず、何かを成し遂げる必要があるときは私たちの誰かがそれをやらなければなりません。ChatGPTとCodexのおかげで私たちは物事を成し遂げられます。
DevOpsは本当にダメだ。まったくその通りだ。
私が身につける役割のひとつはDevOpsです。DevOpsを行うのは大嫌いです。これらの分野には20年以上触れてきました。正しく行う方法は知っています。2000年代初めに行われたようにISDN回線でzipファイルをアップロードしてTomcatをリモート再起動するといったことから、Puppetでデプロイを自動化したり、AWSのCloudFormationを使ったり、KubernetesやDocker Swarm、Terraformを扱ったりと、あらゆることをやってきました。最近の私のお気に入りはAnsible、Docker、Docker Composeです。これらのことを学び、それを適用するのに、計り知れない時間を投資してきました。
DevOpsが嫌いな理由? 私には宇宙船のワープを外れるような感覚です。スター・トレックの比喩を使えば、大きな機能を出すための壮大な計画がありながら、結局はLinux上の非常に難解な設定を細かく詰めて正しく時刻を合わせ、複雑なネットワーク設定を解決するなどの作業に追われてしまうのです。何週間も行き詰まってしまいます。そのためには「このクソみたいなものをあそこに置いて動かせ」という年寄りの問題を解決する必要があります（不適切な表現ですみません）。この問題をインセプションと呼んでいます。壮大なビジョンから始めます：「私たちのピカピカの新しいバックエンドが準備できているので、展開して世界に発表しよう。」しかし、それがいつのまにか「データベースを公開インターネットに晒さないよう、跳ね橋の設定とプライベートネットワーキングをどう作るかを考えなければならない」という段階にエスカレートします。結果として、気づけばそのプロジェクトに3か月も費やしているのです。
DevOpsはシンプルであるべきだが、そうではない
DevOpsは、本来自動化すべきことを自動化することを目的としています。では、なぜDevOpsはまだ手作業感が強いのでしょうか。その答えは、これらの分野が本当に複雑で、長年にわたり罠だらけのシステムを作ってきたことにあります。データ損失、セキュリティ侵害、ダウンタイムなど、ひどい故障モードを伴う罠が山のように存在します。DevOps担当者が知っておくべきこと、すべきことは多く、ショートカットを取ると災厄を招くことが多いのです。だからこそ、それはしばしばフルタイムの仕事となります。
時々、単純なはずのDevOpsの作業に取り組むことになり、自分が愚か者のように感じます。代わりに、儀式的な下品な作法、魔法のようなコマンドライン呪文、正確に設定ファイルを合わせる必要がある奇妙な問題を解決しようと、何日も頭を悩ませて髪の毛を引き抜くことになります。本当に優れたオペレーションやDevOpsの人たちを何人も知っていますが、正直なところ私がこの作業を自分でやるときには多少のインポスター症候群を感じます。私は危険を冒せるほどの技術を持っていると自負しています。
Codexがその痛みを取り除く
この最新の動きには2週間前に巻き込まれました。我々はGoogleのセットアップを見て、ホスティングに年間約1万ドルを費やしていると結論づけました。動作は素晴らしいのですが、それは多く、Googleに寄付するより自分たちにわずかな昇給を与えたいと考え、Hetznerへの移行計画を開始しました。
しかし、それを実行したのはCodexを使ったからです。顧客の事情により、テレコムクラウド上で動作する別のセットアップもあり、基本的にはOpenStackベースの環境です。私はすでにそれを構築するためのAnsibleスクリプトを多数用意していました。
まず、Codexにそのコードベースをリファクタリング・モダナイズして、私の新しいHetzner環境用の新しいインベントリを設定させました。HetznerでいくつかのVM、プライベートネットワーク、ロードバランサを作成しました。VMのうちの一つはバスティオンとして機能し、パブリックIPを持たない他のVMへSSHでアクセスできるようにします。
小さなステップで、Ansibleスクリプトを修正・アップグレード・モダナイズし、新しいHetzner環境をテストベッドとして使いました。すべての作業をCodexに任せました。Ansibleコードを修正させ、私のノートパソコン上のツールとSSH経由でのプロビジョニングを進めさせました。プロセスの周りにスキルとガードレールを設定しました。
Ansibleスクリプトが失敗したとき、原因をデバッグさせ、修正を実装させました。回避策を調査させることもしました。多くは私が道案内した結果です。私は20年以上の経験に頼っていましたが、コードの1行も触っていません。
これが実際には鍵となります。進むにつれて、それは苦労して物事を理解していくのを目にします。そのときは、直前に行ったことをスキルとして記録するように依頼します。生成されたマークダウンを読み、さらなる改善を提案し、次回はより良くします。あなたとAIのこのフィードバックループは非常に重要です。自分のやり方、すなわち正しい方法で行うのか、AIが思いついた方法でやるのかの差はここにあります。正しい方法を知るのは経験に基づくものです。そしてこれが私たちソフトウェア作りの新たな価値となっています。
3日後に、DNSを切り替え、GoogleのVMを最後まで停止しました。Hetznerアカウント作成から3日で、VMの上限を引き上げてもらう追加日を含めていません。まだ初月だったためです。
Elasticsearchでのローリング再起動
私たちのセットアップの一部としてElasticsearchがあります。未使用の方には、ノードとクラスターの協調によって高可用性を実現するクラスター型の検索エンジンです。アップグレードにはいわゆるローリング再起動が必要です。プラグを抜いて全ノードをアップグレードするわけにはいきません。そうするとクラスターが利用不能になり、分散ブレイン、データ損失、さらにはそれ以上の問題を引き起こします。これは経験豊富なDevOps担当者が責任を持って対処すべき、典型的なケースです。DevOpsには経験が重要なタスクが山ほどあり、誤ったショートカットは静かに障害やデータ損失につながります。
The XXX Elasticsearch cluster upgrade is complete.
All three nodes are now on 9.3.1:
es1 9.3.1
ess2 9.3.1
es3 9.3.1
Final cluster state:
green
3 nodes / 3 data nodes
0 relocating shards
0 initializing shards
0 unassigned shards
Notable preflight/result details:
Latest 9.3.x release verified: 9.3.1
Snapshot health passed before rollout; latest successful snapshot was 2026_03_12_05_33
System feature migration was required and completed before the first node restart
I did the rollout one node at a time in this order:
es3
es2
es1
No code changes were needed in the repo.今朝、Codexに古いデータセンターのクラスタを再プロビジョニングさせるよう依頼しました。前回は9月に手動で行いました。まずノードのクイックインベントリチェックとドライランを実施しました。クラスタが健全な状態（グリーン）で、最新のスナップショットが検証済みであることを確認しました。それから rollout を実行しました。計画を文字通り遵守しました。上のブロックは完了時に私に提供されたレポートです。全体で約20分かかりました。次のステップの許可を求めて戻ってくるたびに許可を与えた、私のスキルの範囲内でです。
この作業を行う前に、Hetzner移行の一部としてこの作業を行うためのスキルを書くことを彼と協議しました。熟練のDevOps担当者が通常行うことをカバーするスキルです：着手前の事前チェック、許可を求める確認ゲート、そして「もしこれが起こったらどうするか」というシナリオの指針。インターネットには多くのアドバイスがあり、私はこの正確な話題について数年前にブログ記事も書きました（例：Docker 1.12 SwarmでのElasticsearch実行）。ブログ記事を定期的に書くのは、「この変なことを2日間かけて理解したので、もう一度その時間を費やさなくて済むように覚えておくべきだ」という意味での、AI以前のスキル作成・記録法でした。
もしご興味があれば、私が使ったスキルファイルはこちらにあります。
次にやることは？
この数週間、私は信じられない量の作業を計画・実行してきました。Cloudflareを通じて2つの新しいウェブサイトを立ち上げました。新しいOSSプロジェクトをいくつか作成しました。2つの実稼働デプロイメントに対して大規模な手直しを行いました。いくつかの大きな新機能もリリースしました。さらに、OpenClawを試したり、新しいAI関連のことにも取り組む時間を得ることができました。何か月分の作業を数週間に圧縮しました。正直に言えば、疲れていますが、同時にエネルギーも沸いています。これって本当に楽しい。
今後の課題として、DevOpsの厄介な作業を近代化するため、世界クラスのAIによる監視・アラート機能を導入したいと考えています。テレメトリ、ログ記録など、必要なものはすでにいくらか揃っていますが、あるものを持っているだけで実際に使えるわけではありません。運用の規律をAIに任せたいのです。稼働時間のチェック、バックアップの検証、リソース使用状況の監視、そしてすべてが所期どおり動作していることの確認。日次レポートを出して、重要な点を要約し、問題をエスカレーションしてほしい。全て手動で設定するために長期の休暇を取りたくはない。とにかくこの作業を完遂したいのです。
これが貴社のチームに必要なものであると感じるなら
最近、Codexを使って他に行ったことのひとつは、AIサービスとコンサルティングのサイトを立ち上げることでした：formationxyz.com。
このピッチはシンプルです。多くの企業がAIの機会を見出していますが、それを実用的なシステム、実用的なワークフロー、そしてチームにとっての実際の活用に落とし込むのに苦労しています。私たちが埋めたいのは、まさにそのギャップです。
FORMATION XYZでは、規模の小さなチームが反復作業を自動化し、実用的なAIシステムを構築し、手動の労力を削減して余力を生み出すエージェント型ワークフローを導入するお手伝いをします。上記のような仕事に興味があり、実用的な方法で社内にAIを適用する支援が必要なら、私たちがお手伝いします。
