AI時代の個人開発基盤を作るためにTechブログを構築した記録

個人開発で作ったものを、完成した時点で終わらせたくありません。設定、測定結果、判断、失敗、次に試したいことまで残しておけば、次の開発で使える資産になります。

そのために、AIを使った開発の記録も残せるTechブログを構築しました。狙いは「AIが全部作った」という話ではありません。AIを開発工程の一部に置き、Git差分、テスト、人間の判断を通じて、公開できる形へ整える基盤を作ることです。

この記事では、なぜAstro・Markdown・Gitを選んだか、OCIでどう公開したか、そしてAI利用時にどこへHuman Gateを置いたかを説明します。

なぜTechブログを作ったか

個人開発では、実装だけ残しても次の判断に使いにくいことがあります。どの前提で考え、何を変え、どの検証を通ったかが残っていなければ、同じ問題にまた出会ったときに再利用できません。

そこで、一般論だけでなく、実際に動かした環境、設定、検証結果、制約を残す場所としてTechブログを作りました。記事本文はMarkdown、変更履歴はGit、公開対象は静的ビルドの成果物です。開発で得た知識を、あとから読める記事資産へ変換するための基盤でもあります。

設計方針：WordPressではなくAstro、正本はMarkdownとGit

今回の設計方針では、WordPressではなくAstroを選びました。記事をMarkdownで管理し、Gitリポジトリを正本にするためです。

Astroは静的出力に設定しています。公開環境でアプリケーションサーバーやデータベースを動かすのではなく、Mac miniでビルドした静的ファイルを配信します。記事作成、実装、公開を別々に確認しやすくし、公開サーバーの責務を小さく保つためです。

Markdown / Astro source / infra scripts
                 ↓
                Git
                 ↓
     Mac miniで Astro build
                 ↓
       静的な dist 成果物
                 ↓
      Route53 DNS → OCI VM
                 ↓
 nginx HTTPS / Let's Encrypt / certbot renewal
                 ↓
          tech.komnokutsu.com

公開時には、Route53でDNSを設定し、OCI VMを公開しました。OCI Security ListではTCP 80/443を許可し、nginxでHTTPSを配信しています。証明書はLet’s Encryptを使い、certbotの更新も設定しました。これらの本番公開境界は人間が確認して進めたものです。

公開を安全にするために分けたこと

静的サイトにしても、公開の安全性が自動的に得られるわけではありません。そこで「新しいものを出す」ことと「戻せる」ことを分けました。

デプロイスクリプトはdirtyなGit worktreeからの実行を拒否し、依存関係の準備、Astroのcheckとbuild、成果物検証を行います。成果物には deploy-meta.json と SHA256SUMS を加え、サーバー側ではチェックサム、必須ファイル、不要なsymlinkがないことを確認してからreleaseを切り替えます。

releaseは新しいdirectoryへ配置し、current symlinkを原子的に切り替えます。問題が起きた場合は過去releaseへ戻すrollbackコマンドを用意し、切替処理はserver-sideのlockで直列化しています。実際の公開でも、release directoryへのdeploy、current の切替、smoke testを確認しました。

AI時代に重要だったHuman Gate

AIを使うと、調査、実装、文章化を速く進められます。一方で、何を変更し、何を公開し、どの本番操作を行うかは、AI任せにしない境界が必要でした。

AI
 ↓
実装
 ↓
Git差分確認
 ↓
test
 ↓
Human Review
 ↓
Production

これはAIの出力をただ疑うための手順ではありません。変更範囲と責任境界を明確にするための流れです。記事はまず draft: true のMarkdownとして追加し、ローカル確認とHuman Reviewの後に公開対象へ切り替えます。production変更も、人間がDNS、ネットワーク、公開状態を確認したうえで進めます。

AIをどこで使ったか

AIは完成品を一度に出力させるためではなく、工程ごとに役割を分けて使いました。

役割	この構築での使い方
ChatGPT	設計方針の整理、選択肢の検討、記事構成の整理
Codex	リポジトリ調査、実装、テスト、検証
Local LLM	今後の調査・整理用途として検討・実験

AIの提案を採用する前には、Git差分、型・コンテンツ検査、build、成果物検証、ブラウザテストを確認します。人間が公開内容とproduction変更を判断することで、AIの作業速度と公開の責任を分けています。

実装した機能

記事はAstroのcontent collectionで管理し、公開対象のMarkdownからホーム、記事、カテゴリ、タグページを静的に生成します。draft: true の記事は、一覧、RSS、sitemap、production buildのページ生成対象になりません。

SEO・共有向けには、canonical URL、description、Open Graph、Twitter Card、BlogPosting JSON-LD、RSS、sitemap、robots.txt を実装しました。About / ContactとPrivacy Policyも用意しています。個々のSEO実装の詳細は別記事で扱う予定です。

画面の確認にはPlaywrightを使っています。ホーム、記事、About、Privacy、404の表示、内部導線、画像の欠損、desktop/mobileの横幅あふれをsmoke testで確認し、スクリーンショットを人が確認できるように出力します。

公開までの流れ

実際の公開までに行った流れは、次のとおりです。

設計方針を整理し、Astro、Markdown、Gitを中心にした構成を実装する
Markdownを draft: true で追加し、ローカルpreviewで本文、リンク、コードブロックを確認する
Git差分、check、build、成果物検証、ブラウザテストを確認する
Human Review後にGit commitを作成する
Route53のDNS、OCI VM、Security List、nginx HTTPS、Let’s Encrypt、certbot renewalを人間が確認する
deploy scriptでrelease directoryへ成果物を転送し、検証後に current を切り替える
smoke testで配信内容を確認する

公開前のローカル検証では、npm run check、npm run build、npm run verify:dist、npm run test:e2e を実行します。今回の確認ではE2Eは17件成功し、desktop環境ではmobile専用テストが1件スキップされました。

今後

次は、開発作業そのものを記事候補へつなげる仕組みを育てます。

Git履歴と差分から、記事にできる変更候補を整理する
開発ログや検証結果から、事実ベースの下書きを作る
Local LLMを、ローカルで完結させたい調査・整理に使う
実装した仕組みやツールを、公開可能な形に切り出す

候補生成と公開は別です。AIやスクリプトで下書きを作れても、公開する内容は人間が確認し、根拠がないことは書かない。このブログ自体を、その運用を試しながら記録する場所にしていきます。