AIとCodexで記事を公開するまで｜取材・PR・Vercel QAの実践記録
シーパラ攻略隊の現地レポ2本とGAOCRAFTの公開記録から、AIでの原稿制作、専用作業環境、GitHub PR、Vercel Preview、公開判断を具体的に振り返る。
AIに文章を書かせれば、記事は完成するのでしょうか。
GAOCRAFTでは、そう考えていません。文章が整っていても、写真が違っていたり、公開前の画面が確認できなかったり、ほかの作業のコードまで混ざっていたりすれば、安心して公開できないからです。
2026年10月、GAOCRAFTが運営するシーパラ攻略隊（外部サイト）では、グソグソパニックとドルフィン ファンタジーの現地レポートを制作・公開しました。同じ時期、GAOCRAFT公式サイトではセキュリティ修正を先に済ませ、FIELD NOTESの記事と図版を更新しました。
この記事では、それぞれの実際の変更記録を材料に、AIが手伝う仕事と、人が根拠を確かめて公開を決める仕事の境界を振り返ります。AIへの万能な指示文や、どのサイトでもそのまま使える自動公開の方法を紹介するものではありません。
最初に
今回の素材は、現地で撮影した写真と、そこで確認した内容でした。グソグソパニックの記事では写真7点、ドルフィン ファンタジーの記事でも写真7点を採用しました。2026年10月23日にマージされたシーパラ攻略隊のPR #48・#49から、それぞれの記事の変更範囲を確認できます。
単に「水族館についてAIに書いてもらう」方法ではありません。出発点となる現地資料があり、承認された文章と写真があり、実装後に一致を確かめる工程がありました。
AIは構成案や文章の整理、実装・QAの指示整理を支援できます。しかし、撮影していない写真を撮影済みと書いたり、未確認の混雑や所要時間を体験談として補ったりする役割は与えません。
GAOCRAFT公式サイトで扱うのも、施設のおすすめ情報そのものではありません。取材資料を、根拠の追える公開物へ変えるには何を確認したか。この制作過程がFIELD NOTESのテーマです。
原稿を
記事を公開するときは、原稿だけでなく、画像ファイル、ページのSEO情報、一覧からの導線、サイトマップなども変更する場合があります。複数の作業が並走している環境で、関係のない変更を同じPRに入れると、何を公開するのか判断しにくくなります。
そこで今回の制作では、記事ごとに作業を分け、専用のブランチとworktreeを使う運用を採りました。worktreeは、同じリポジトリの別ブランチを独立した作業ディレクトリで扱う仕組みです。作業を物理的にも分けることで、別の記事や未公開下書きを不用意に混ぜないことを狙いました。
実際のPRで確認できる変更範囲は、グソグソパニックが10ファイル、ドルフィン ファンタジーが11ファイルです。前者には記事ページ、写真7点、サイトマップ、導線設定が含まれ、後者には記事ページ、写真7点、水族館比較ページへのリンクなどが含まれています。
ただし、PRのファイル一覧は変更範囲の証拠であって、ローカル作業ディレクトリの状態そのものを証明するものではありません。 worktreeのパスや内部の作業ログは公開記事には載せず、実装側の引き継ぎ資料で扱います。
図：役割をつないでも、原稿の生成と公開の許可は同じ操作にはならない。今回の制作判断をもとに整理した模式図。
実例1｜写真と
ドルフィン ファンタジーの公開では、原稿と写真7点が承認済みZIPの内容と一致することを、SHA256による照合で確認しました。PR #49の記録には、ローカルのlint・build成功、PC幅1440pxとスマホ幅390pxでの表示確認、記事の内部リンクやSEO設定の確認が残っています。
ここで大切なのは、記事が見た目として自然なことと、採用すると決めた素材が実際に使われていることを分けた点です。AIが写真の説明をうまく書いても、違う画像を参照していたら、見た目だけでは見落とすかもしれません。
同じ記録では、人物が写り込む可能性のある写真について、顔や氏名などの識別情報がないか確認したことも残っています。写真を掲載できるかは、画像の容量や美しさだけでは決まりません。
写真の容量比較とWebPへの変換設定は、別のFIELD NOTES「水族館の写真7枚をWebPに変換したら容量はどれだけ減る？実測と再現手順」で詳しく紹介しています。この記事では圧縮率の説明を重複させず、承認した画像を取り違えないための確認に焦点を当てます。
実例2｜Previewが
公開前の画面確認には、Vercel Previewを使いました。ただし、デプロイの処理が成功しても、保護されたPreviewを実際に閲覧できたことにはなりません。
グソグソパニックの記事では、認証を迂回する共有リンクを作る案がレビューで拒否されたことが、GAOCRAFTの公開後改善記事に記録されています。そこで保護設定を弱めるのではなく、通常の認証セッションで画面を確認しました。
この場面では、「確認できないから安全設定を変える」のではなく、「必要な閲覧権限を持つ環境で確認する」という選択をしました。画面で見るべき項目も、記事本文だけではありません。写真7点、内部リンク、canonical、meta description、構造化データ、インデックス制御を確認対象にしました。
Previewへアクセスできない段階では、画面QAが済んだとは扱わない。確認ができたら、同じ検査を理由なく繰り返さず、次のGateへ進む。公開を止める条件と、再開できる条件を両方決めておくことが重要でした。
実例3｜記事より
GAOCRAFT公式サイト側では、記事の公開に先立ち、Next.jsのセキュリティ修正を別のPR #33として行いました。Next.jsとeslint-config-nextを16.4.1へ更新し、ローカルのlint、型チェック、62件のテスト、production buildが成功したことがPRに記録されています。
このPRにはServer Actionsを対象にした追加の検証もありました。一方、既存依存に関する警告は別の保守課題として切り分けられました。問題があることを無視したのではなく、今回の公開前に対処する部分と、独立して管理する部分を分けたのです。
その次のPR #34で、公開後改善記事の改稿と、新しい画像最適化記事の追加を行いました。PR #34には、デスクトップ向けの新規図版6点とスマホ向けの対応図版6点を含む、18ファイルの変更が記録されています。63件のテストとbuildなどを通したうえで、Previewと本番のSEO状態も公開Gateにしました。
技術的に見れば別々の変更です。しかし編集側から見ても、記事の価値を増やす作業と、安全に公開できる土台を保つ作業を混ぜないという判断でした。
図：PR #33・#34・#48・#49の記録から整理した判断例。すべての作業で同じ問題が起きたという意味ではない。
Previewで
今回の記録で繰り返し出てくるのは、変更したコード、Previewで見た画面、本番に公開された画面が、それぞれ別の確認対象だということです。
シーパラ攻略隊のPR #48・#49では、専用ブランチの差分とローカル検証を経て、SSO保護を維持したVercel PreviewとCIを確認し、マージする条件を設けました。マージ後は公開したURLで写真・表示を確認しました。
GAOCRAFT公式サイトでは、未公開下書きはPreviewでのみ表示でき、検索インデックスを許可しない設定です。また、公開状態の記事であってもVercel Previewではnoindex, nofollowを出し、本番ではcanonicalや記事メタデータを出す実装になっています。これは2026年10月24日時点のソースコードで確認できる動作です。
したがって、PreviewでSEO設定の文字列を見たときも、それが本番でそのまま出るべき値とは限りません。環境ごとの意図を確かめてから「正常」と判定します。
公開できたことをSEOの成功と同一視もしません。検索や閲覧の結果は、公開後に別途観測するものです。この違いは「公開して終わりにしないWebプロダクトの育て方」で実際のGSC・GA4データを使って扱っています。
自分の
今回の制作から、個人開発や小規模チームでも実践しやすいのは、特別なAIの設定よりも、次の担当へ何を証拠として渡すかを決めることだと考えています。
素材の出所：誰が確認した事実か。写真はいつ撮り、掲載の許可と範囲をどう確認したか。
変更の境界：専用ブランチ・作業環境と、触ってよいファイルを明示する。無関係な下書きを保護する。
差分の証拠：原稿と画像が承認した素材に一致するか。PRでどのファイルが変わったか。
画面の証拠：PCとスマホで本文・図版・写真・リンクが読めるか。Previewの認証を迂回していないか。
公開の判断：未解決の問題があるなら、何を確認できるまで止めるか。解決後に誰が公開を許可するか。
公開後の確認：マージ完了だけでなく、ProductionのURL・画像・SEO設定を確認する。
「AIに任せたから速く終わった」と結論づけるには、所要時間の比較が必要です。今回、その効果を定量測定した記録はありません。ここで言えるのは、役割と確認条件を明確にしたことで、記事の制作と本番反映を別々の段階として扱えたことです。
まとめ｜AIが
現地で確かめた内容を原稿にし、Codexで実装し、GitHubで変更をレビューし、Vercelで画面を見る。その一連の作業には、便利なツール以上に「ここまで確認したら進む」「確認できなければ止める」という判断が必要でした。
写真の照合、保護されたPreviewの確認、セキュリティ修正の切り分け、390pxの画面でも読める図版。どれも派手な機能ではありませんが、読者が安心して使える記事に近づけるための作業です。
GAOCRAFTでは、AIを使うこと自体を成果とは考えません。事実を確かめ、意図した内容を届け、公開後も説明できる状態を作ることを成果として積み重ねていきます。
制作記録について：本記事は2026年10月24日時点のGAOCRAFT・シーパラ攻略隊のPR #33・#34・#48・#49と、GAOCRAFTの既存FIELD NOTESをもとに構成しています。PR番号と検証項目は内部の制作記録です。公開URLで確認できる記事内容と、リポジトリ内の作業・QA記録は証拠の種類が異なります。制作工程の一部について個別の所要時間やAIの作業量は測定していません。