はじめに — このサイトについて

2026-09-21 （更新: 2026-09-24）お知らせ

うまくいかなかった話を書く場所

クラウドインフラと SRE の実務、そして AI 開発ツールを実際の作業に組み込んだ記録を書いています。想定読者は、同じようにインフラの設計・運用をしているエンジニアです。

このサイトの実質的な編集方針は、いまのところ**「想定が外れた記録を書く」**に寄っています。狙ってそうしたわけではなく、書く価値のあるネタを選んでいくと自然にそうなりました。

4本中4本が、何かを間違えた記録になっている。成功事例より、判断を誤った過程の方が書く価値があると考えているからです。

一般的な入門解説を書きません。 「Terraform とは何か」のような記事は、対話型 AI に聞けばその場で答えが返ってきます。わざわざ検索してここに来る理由がない。

書くのは、複数の選択肢から何を選び、何を捨てたかの跡がある内容だけです。そのため全記事に「検討したが採らなかった選択肢」の節を必ず置いています。省略しません。採用した案だけを書くと、読者が自分の状況に当てはめて判断できないからです。

手を動かして確かめていないことを書きません。 伝聞、推測、実測値のない「べき論」は扱いません。記事に載せているコマンド出力は、実際に手元で実行した結果です。

記事は実務経験に基づきますが、所属先の固有情報は一切扱いません。 アカウント構成、顧客名、社内の意思決定の経緯、未公開の設計。これらは書きません。

書くのは一般化した知見だけです。具体的な構成やコマンド出力であっても、特定の組織や案件が推測できる形にはしません。実際、公開前には毎回この作業をしています。

この手間を省いた記事は公開しません。判断に迷ったら書かない方を選びます。サイトの信頼性のためというより、単純に所属先との関係を守るための線引きです。

ここまでに書いた方針は、文章として書くだけでは守れません。忙しいときに最初に崩れる種類の約束だからです。

そこで、機械的に検査できるものはテストに落としました。npm test で落ちます。

このサイトでは執筆を AI 開発ツールに手伝わせています。構成案の提示、話した内容の文章化、リライト。ただし一次体験の捏造と、実測値の推測による補完はさせません。 ネタが無いときは「ネタが無い」と報告させ、それらしい記事をでっち上げさせない。この制約も同じ仕組みの中にあります。

テスト自体に穴が空いていた話は別記事に書きました。ルールをテストにしただけでは足りず、そのテストが実際に落ちることまで確認しないと意味がない、という内容です。

執筆ルールを文章の規約だけにする。 最初はこの状態でした。しかし規約ファイルを読ませたことと、守らせたことは別です。実際に規約をすり抜ける書き方が見つかったので、機械検査に寄せました。

記事本数を優先する。 一定の本数を早く揃える方針も検討しました。しかし一次体験のない記事を混ぜると、検索評価で通らないうえ、読んだ人がこのサイトを二度と見なくなります。本数より、1本あたりに書けることがあるかを優先します。 書けるネタが無い期間は更新が止まります。

成功事例を書く。 「うまくいった構成」を紹介する形式も考えましたが、それは公式ドキュメントと AI が既にやっています。同じ土俵で戦っても勝ち目がありません。