🤖 この記事は 2026-04-28 にFuturistic Imaginationの自動コンテンツパイプライン（Gemini 2.5 Flash）によって生成されました。

Futuristic Imagination 代表の佐藤琢也です。

今日のテーマは、少々耳の痛い話から始めましょう。そう、「Googleに怒られた」話です。

2024年の春先、いつものようにSearch Consoleを開くと、そこには警告が並んでいました。「リダイレクトエラー」「重複ページ（Googleが選択したURLと異なる）」。具体的には、認証を必須とする管理画面へのログインページがサイトマップに誤って含まれていたり、開発環境のサブドメインが本番サイトと重複コンテンツとして認識されたりといった問題です。

一人でAIオウンドメディアを11サイト運用し、累計1,500本以上の記事を自動生成している私にとって、これはシステム全体の品質に関わる重大なサインでした。Vercel Cron、GitHub Actions、Gemini APIを組み合わせてほぼ全自動化しているとはいえ、完璧なシステムなど存在しません。常に何らかの形で問題は発生する。その時、どう対応するかが問われます。

異常検知から根本原因特定までの緊迫感

Search Consoleからの通知を検知した瞬間、私の頭の中では高速でタスクが分解されていきました。まず、どのサイトで、具体的にどのようなURLが問題となっているのか。エラーが発生しているURLリストを抽出し、一つずつ手動でアクセスして挙動を確認します。

リダイレクトエラーの原因はすぐに分かりました。一部のサイトで、ログイン後にしかアクセスできないページが誤ってサイトマップに含まれていたのです。Next.jsで構築されたアプリケーションでは、認証状態によってリダイレクト処理が行われます。Googlebotがそのようなページにアクセスしようとした際、認証されていないためにリダイレクトされ、結果として「エラー」として報告されていました。

より厄介だったのは「重複ページ」のエラーです。これは特にサブドメインの取り扱いが原因でした。開発中に一時的に使っていた検証環境のサブドメインが、誤ってインデックスされてしまい、本番ドメインと同じコンテンツとしてGoogleに認識されてしまった。これはSEO上のペナルティリスクも伴うため、迅速な対応が求められます。

これらの問題は、私がこれまで培ってきた「自動化」のパイプライン自体に潜む設計上の不考慮点を示していました。サイトマップ生成ロジックの不備、開発環境のドメイン管理の甘さ。Vercel上で複数のプロジェクトを運用している中で、それぞれの設定が複雑に絡み合い、今回の事態を引き起こしたのです。複数のリポジトリを並行管理しているからこそ、個々の設定が全体に与える影響を常に正確に把握しておく必要性を痛感しました。

実装と改善：二度と同じ過ちを繰り返さないために

根本原因が特定できれば、あとはひたすら手を動かすのみです。私の仕事スタイルは「理論より実装」を優先します。

まず、サイトマップ生成ロジックの見直し。Next.jsの`getServerSideProps`や`getStaticProps`で動的にページを生成している場合、認証状態によってページの内容が変わる可能性のあるURLは、サイトマップから確実に除外するよう変更しました。具体的には、ログイン後の管理画面ルートを示す`/dashboard`のようなパスは、サイトマップには含めないよう、生成スクリプトに条件分岐を追加したのです。

次に、サブドメインの問題です。これは、Vercelのプロジェクト設定で、検証環境のURLが意図せず本番環境のクロール対象に含まれないよう、ルーティングルールを厳密に設定し直す必要がありました。また、`robots.txt`でのクロール制御や、場合によっては`noindex`タグの適用も検討しました。

さらに、今後の再発防止策として、GitHub Actionsに新しいワークフローを追加しました。これは、サイトマップが更新されるたびに、認証必須ページが含まれていないか、また意図しないサブドメインが混入していないかを自動でチェックするものです。Gemini APIを活用した簡易的なコンテンツ比較も組み込み、重複コンテンツの兆候を早期に検知する仕組みを構築しました。これらの修正は、数日間のうちに全て完了させ、Search Consoleで再クロールをリクエストしました。結果、全ての警告が解除され、サイトの健全性が回復したことを確認できました。

失敗から学ぶ、FIの「実証済み」な強さ

今回の「Googleに怒られた」経験は、私にとって非常に価値のあるものでした。それは、単にエラーを修正したという話だけではありません。Futuristic Imaginationが掲げる「実証済みであること」の価値を改めて深く理解するきっかけとなったのです。

私がお客様に提案するシステムは、全て私が実際に自分で動かし、運用しているものです。AIオウンドメディアの自動化、WordPressからNext.jsへの移行、Gemini APIを使ったコンテンツ生成パイプライン。これら全て、私自身が日常的に運用し、時には今回のようにGoogleから「喝」を入れられながら、泥臭く改善を重ねてきたシステムです。

失敗を隠さず、session_log.mdに「バグの原因→解決策→今後の注意点」として詳細に記録する。これは、私自身の成長のためでもありますが、同時に、FIが提供するサービスの信頼性を高める上で不可欠なプロセスだと考えています。ISRキャッシュのエラー、Geminiの出力フォーマット崩れ、TypeScript Strict Modeの罠。これら実際に踏んだ地雷こそが、お客様に提供するソリューションの「頑丈さ」を保証する礎となります。

私は、効率と自動化を徹底的に追求しますが、それらが人間の手を完全に不要にするとは考えていません。むしろ、人間が判断すべき重要な部分に集中するためにこそ、自動化がある。そして、その自動化されたシステムが意図通りに機能しているか、定期的に、そして異常を検知した際には即座に人間が介入し、品質を担保する。このサイクルこそが、AI時代における開発の肝だと私は確信しています。

Futuristic Imaginationは、AIを使い倒しているこの会社が、最も人間らしい働き方をしている。