CodexとGoogle Antigravityを実務で比較|構成はCodex、デザインはAntigravity
VIEW →
最近は、AIに記事本文を書かせるだけではなく、記事執筆のルール、既存記事の確認、公開前チェック、CMSへの反映、アイキャッチ画像の生成、公開後の改善までを、一つの流れとして組み始めています。
私の環境では、実際にCodexからCMS内の記事を取得し、原稿を調整して下書きへ反映し、リンクや画像、仮のURL、スマートフォンでの表示などを確認するところまで行っています。
また、GA4やSearch Consoleなどの解析データもAIへ渡し、リライトする記事、新しく作る記事、タイトルを見直す記事、内部リンクを調整する記事などの候補を出させています。
AIが提案した内容と根拠を確認しながら、どこから対応するかを決めていく形です。
この記事では、現在こちらで始めている記事執筆・更新・改善の流れについて、実際に行っている内容をもとにまとめます。
AIを使えば、構成案や本文を以前より早く作れるようになりました。
ただし、文章を作ったあとに、既存記事を探し、CMSへ貼り付け、画像を用意し、リンクを確認し、公開後のデータを見ながら改善内容を考えるのであれば、短縮できるのは執筆工程の一部だけです。
現在は、以下のような流れを一つの運用として考えています。
すべてを自動化するというよりも、AIに情報収集や整理、繰り返し作業を任せ、公開や記事の統合、取り下げなど、影響の大きい判断には人が入る形です。
記事を書くたびに、サイトの方針や表記ルールを一から説明するのは効率的ではありません。
そこで、記事執筆時に共通して確認する内容を、AIエージェントが参照できるスキルとして定義しています。
Codexのスキルには、繰り返し行う作業の指示、参照資料、必要に応じたスクリプトなどをまとめられます。詳しい仕組みは、Codexの公式ドキュメントで確認できます。
私の運用では、既存記事の言い回し、見出しの付け方、参照元の優先順位、実体験と未検証情報の分け方などを、記事執筆時のルールとして持たせています。
特に重視しているのが、実際に試したことと、公開情報から確認したことを混同しないことです。
自分で確認できていない内容については、推測で埋めず、不明な場合は不明とします。
AIを使うと文章を自然に補完できてしまうからこそ、どこまでが事実で、どこからが推測なのかを分けるルールが必要だと感じています。
記事執筆のルールとは別に、公開前のチェックフローも定義しています。
記事を書いたあとに「問題がないか確認して」と伝えるだけでは、何を基準に確認するのかが曖昧になります。
そのため、参照元と記事内容が一致しているか、古い料金や仕様を断定していないか、実際に試していない内容を体験談として書いていないかなど、確認する項目をあらかじめ決めています。
そのほか、公開してはいけない情報が含まれていないか、仮のURLや文言が残っていないか、リンクや画像が正しく表示されているかも確認します。
CMSへ反映したあとは、本文だけではなく、スマートフォンでの表示も確認しています。
AIからCMSを操作できるようになるほど、記事を作るルールだけではなく、問題のある状態で公開しないためのルールも重要になります。
AIとCMSを連携するメリットの一つが、新しく作る記事だけではなく、既存記事を含めて判断できることです。
新しい記事を作る前に、既存記事のタイトル、見出し、本文、カテゴリー、内部リンクなどを確認します。
似た内容の記事がすでにある場合は、新しい記事を作るのではなく、既存記事へ追記した方がよい可能性があります。
一方で、扱っているテーマが近くても、解決する課題が異なる場合は、記事を分けた方が分かりやすくなります。
記事間の導線についても、新しい記事から既存記事へリンクするだけではなく、既存記事から新しい記事へリンクした方がよい箇所を確認できます。
内容が重複している記事や、カニバリゼーションが起きている可能性のある記事についても、AIには確定判断ではなく候補として出させます。
そのうえで、それぞれの記事の役割や解析データを確認し、統合するか、内容を分けるか、内部リンクでつなぐかを判断します。
記事を一つずつ作るのではなく、サイト全体の中で、その記事がどのような役割を持つのかまで考えられることが、この運用の大きなメリットです。
CMS側にAIエージェントからコンテンツを取得・更新する手段があれば、原稿を作るだけでなく、記事への反映まで進められます。
私の環境でも、Codexから既存記事を取得し、記事の形式に合わせて原稿を調整したうえで、CMSへ下書きとして反映しています。
これまで試した環境の一つではShopifyを使用しましたが、考え方は特定のCMSに依存するものではありません。
重要なのは、AIが記事データを取得・更新できるCMSや情報基盤であるかどうかです。
記事に合わせたアイキャッチ画像もAIで生成しています。
生成した文章と画像をそれぞれ別の作業として扱うのではなく、一つの記事制作の流れとして進めています。
ただし、現在はAIが作った記事を確認せず、そのまま公開する運用にはしていません。
CMSへ下書きとして反映したあと、内容と表示を確認してから公開しています。
AIエージェント上から公開操作まで扱える場合でも、技術的にできることと、自動で実行してよいことは分けて考える必要があります。
記事を公開したあとは、GA4やSearch Consoleなどの解析データをAIへ渡し、改善候補を出させています。
表示されているもののクリックされていない記事であれば、タイトルや記事内容を見直す候補になります。
一定の検索流入があり、追加できる情報がある記事であれば、リライトの候補になります。
複数の記事で役割が重なっている場合は、内容の調整や統合を検討します。
既存記事では扱っていない検索意図が確認できた場合は、新しい記事の候補として整理します。
現在のサイト方針と合わず、更新する意味も薄い記事については、公開終了やほかの記事への統合も候補に含めます。
ただし、AIが出した提案をそのまま実行するわけではありません。
どのデータを根拠に、なぜその対応を提案しているのかも一緒に出させ、その内容を見ながら優先順位を決めています。
AIに判断そのものを任せるというよりも、人が判断するための材料を整理させる使い方に近いです。
記事改善というと、既存記事へ文章を追加することが中心になりがちです。
ただし、すべての記事をリライトすればよいわけではありません。
新しい記事を作った方がよい場合もあれば、既存記事へ内容をまとめた方がよい場合もあります。
タイトルや導入文を調整するだけでよい記事や、内部リンクを追加することで役割が明確になる記事もあります。
反対に、新しい記事を作らないという判断もあります。
同じ内容の記事を増やし続けるより、既存記事を更新し、サイト内の情報を整理した方が、ユーザーにとっても分かりやすくなります。
AIには、リライト、新規作成、タイトル変更、内部リンクの追加、記事統合、公開終了など、複数の選択肢から候補を出させています。
その提案をもとに、サイト全体として優先度の高いものから対応しています。
このサイトで使用しているmicroCMSについては、今回紹介している一連の連携を、まだ自分の環境では試していません。
2026年8月時点では、microCMS公式のMCP Serverが公開されており、対応するAIツールからmicroCMS内のコンテンツを作成・更新できる仕組みが提供されています。詳しい対応内容は、microCMSの公式ドキュメントで確認できます。
そのため、既存記事の取得、記事の作成や更新、下書きへの反映といった流れは、microCMSでも組める可能性があります。
ただし、ここは公式情報から確認できる範囲であり、私自身が一連の運用を確認した結果ではありません。
実際に試す場合は、まず既存記事の取得と下書き作成から始め、問題がないことを確認しながら、扱う操作を増やしたいと考えています。
今回の運用では、SEOだけでなく、AI検索や生成AIから内容を理解されやすくすることも意識しています。
ただし、AI向けの文章を別に作ったり、不自然に記事を細かく分けたりしているわけではありません。
Googleも、生成AIを利用した検索において、従来のSEOの基本が引き続き重要であり、一般的な情報のまとめではなく、実体験や独自の視点を含む内容が重要だと案内しています。詳しくは、Google検索セントラルの公式情報で確認できます。
そのため、AIで記事数を増やすことよりも、実際に何を試したのか、どこまで確認できたのか、何がまだ不明なのかを具体的に書くことを優先しています。
タイトルや見出し、内部リンクなどは整えますが、SEOやAIOのために実体験を薄めたり、一般的な説明へ置き換えたりしないようにしています。
AIを使うからこそ、誰が、どの環境で、何を行ったのかを残すことが、記事の価値になると考えています。
AI時代の記事運用では、記事本文を生成するだけではなく、執筆ルール、既存記事の確認、公開前チェック、CMSへの反映、アイキャッチ画像の生成、公開後の改善までを一つの流れとして考えられます。
記事執筆とチェックのルールをスキルとして定義しておけば、毎回同じ説明を繰り返さず、一定の基準で作業を進めやすくなります。
既存記事と解析データをあわせて確認することで、リライトだけではなく、新規記事、タイトル変更、内部リンク、記事統合、公開終了など、サイト全体を考えた改善案も出せます。
実際にCodexを使った運用では、既存記事の取得、原稿の調整、CMSへの下書き反映、公開前の確認まで行っています。
Shopifyは、その際に利用した連携可能なCMSの一例です。
今後は、このサイトで使用しているmicroCMSでも、同じような連携を試したいと考えています。
AIで記事を大量に作るのではなく、既存の記事を含めてサイト全体を確認し、必要な記事を作り、更新し、整理する。
そこまでを一つの運用として組むことが、AI時代の記事執筆・更新・改善フローになると感じています。
