AI時代に個人開発を始めるメリット、というタイトルは広すぎました。今回の改稿では、AIを使うこと自体の話ではなく、個人開発の作業をどう実装ログとして記事にするかに焦点を絞ります。このサイトでは、Codexに実装を手伝わせるだけでなく、変更したファイル、DBマイグレーション、テスト、デプロイ結果を記事の材料にします。
記事にできる材料
src/index.tsに追加した公開条件やルーティングmigrations/に残るDB変更wrangler.tomlの環境変数やCron設定gas/fetch_threads.gsの定期処理- 管理画面で使うカテゴリ、タグ、予約投稿、レビュー状態
tests/logic.test.mjsに追加した確認項目
これらは、記事のために後から作った設定ではなく、サイトを動かすための実装です。読者が同じ構成を作るときに、どこを見ればよいかが分かります。
AIを使うときの役割分担
AIには、要件の整理、文章の言い換え、コードの差分確認、テスト追加を手伝わせます。一方で、事実確認、公開してよい情報かどうか、秘密情報を含まないか、実際にこのリポジトリに存在する話かどうかは人間が見ます。AIが自然な文章を作れても、根拠がなければ有用な記事にはなりません。
AdSense不承認後に変えたこと
不承認理由は有用性の低いコンテンツでした。そこで、広いテーマの記事を、実装ファイルと設定に結び付けて改稿しました。さらに、公開条件へ review_status を入れ、未確認の記事をRSSやsitemapに出さないようにしました。この改善は成功事例ではなく、再申請前の修正記録です。
記事化の流れ
- 変更したファイルを確認する
- 公開条件やDB変更をメモする
- 公式資料で機能名や仕様を確認する
- AIに下書きを整理させる
- 確認できない表現を削る
- 内部リンクと関連記事を入れる
- テストと本番確認の結果を残す
個人開発の記事は、完成品の紹介だけでなく、なぜそう作ったかを書けるのが強みです。AIで下書きを作る場合も、リポジトリの差分と結び付ければ、読者が再現できる実装ログに近づきます。