Cosmic、Sanity、Hygraph AIの実装比較
目次
DEV Communityに出ていた比較記事を読んだ。
Cosmic、Sanity、Hygraphを「AI-powered CMS」という雑な箱で並べず、AIがどの層で動くのかを分けて見る内容だった。
ただし原典はCosmicのCEOが書いていて、Cosmic寄りの比較になる。
Hygraphについては「専用のAI agent productはない」という扱いだが、公式ドキュメントではHygraph AI AgentsがEarly Accessのエンタープライズ機能として説明されている。
そこはそのまま飲み込まず、公式情報で補正して読む。
CMSのAI化は3方向に割れている
この比較で面白いのは、3社が同じ方向に進んでいないところだ。
| 製品 | AIが動く主な層 | 近い使い方 |
|---|---|---|
| Cosmic | CMS、コード、ブラウザ、チャット | AIメンバーがコンテンツ作成からPR作成まで進める |
| Sanity | CMS内の一括編集と、外部エージェント向けのMCP文脈提供 | 既存コンテンツを安全に検索・編集・配信する |
| Hygraph | ワークフロー内の翻訳、要約、SEO、編集補助 | エディター承認を挟みながら定型作業を自動化する |
「CMSにAIが入った」だけでは何も分からない。
AIがコードリポジトリに触るのか、CMSのドキュメントだけを読むのか、編集ワークフローの1ステップとして動くのかで、導入時の確認対象が変わる。
この観点は、以前書いたACF 6.8がWordPressをAIエージェントの操作対象にするともつながる。
ACF 6.8はWordPress Abilities APIとMCP Adapterで「WordPressの機能をAIから発見・実行できる形にする」話だった。
今回の3社比較は、その同じ問題をヘッドレスCMS側がどう実装しているかの話になる。
CosmicはCMSの外まで出る
Cosmicは一番攻めた実装だ。
公式サイトとCLIドキュメントでは、Team Agents、Content Agents、Code Agents、Computer Use Agents、Workflowsが前面に出ている。
Cosmic CLIのドキュメントを見ると、エージェント種別として content、repository、computer_use があり、repository は code や repo のaliasを持つ。
GitHubリポジトリに対してブランチ作成、コード変更、PR作成まで行う設計だ。
これはCMSの編集補助というより、CMSに接続された開発オペレーション基盤に近い。
2026年4月27日のAI Agents Reorgでは、Agents、Workflows、ConversationsがBucket単位ではなくProject単位に移った。
これで「ステージング用Bucketと本番用Bucketをまたいで動くマーケティング担当エージェント」のような運用をしやすくなる。
原典が出た日と同じ日の変更なので、Cosmicの比較軸はかなり動きが速い。
graph TD
A["チャット<br/>Slackなど"] --> B["Team Agent"]
B --> C["Content Agent<br/>CMSコンテンツ"]
B --> D["Code Agent<br/>GitHub PR"]
B --> E["Computer Use Agent<br/>ブラウザ操作"]
C --> F["Workflow"]
D --> F
E --> F強い反面、権限の設計は重くなる。
CMSの権限だけでは足りない。GitHub、チャット、ブラウザセッション、外部API、デプロイ権限まで含めて、どこで人間の承認を挟むかを決める必要がある。
CloudflareがWordPress後継のサーバーレスCMS「EmDash」をベータ公開で書いたように、CMSにMCPやエージェント口を持たせると、CMSは単なる投稿管理画面ではなくなる。
Cosmicはその方向へ一気に振っている。
Sanityは外部エージェントに文脈を渡す
SanityはCosmicと違って、すべてを自社エージェントで握る形ではない。
Agent Contextは、Sanityのコンテンツを外部AIエージェントにMCP経由で読ませるための仕組みだ。
Agent Context MCPはread-onlyで、単一datasetに対してスコープされたアクセスを提供する。
公開されるツールも initial_context、groq_query、schema_explorer の3つに絞られている。
AIエージェントがSanityのschemaを理解し、GROQで問い合わせ、必要ならsemantic searchを使う。
主題は「エージェントが勝手にCMSを書き換える」ことではなく、「本番アプリの検索・支援・推薦エージェントに正しいコンテンツ文脈を渡す」ことにある。
一方でSanity MCP serverは別物だ。
Claude CodeやCursorなどの開発ツールからSanity workspaceを操作するためのMCPサーバーで、query、release管理、schema deploy、document patchなどを扱う。
Sanityは本番ユーザー向けの読み取り文脈と、開発者向けのworkspace操作を分けている。
Content AgentはCMS内の一括編集、監査、翻訳、画像編集などを担う。
大量の既存コンテンツを持つ編集チームにはここが向く。
CosmicのようにコードPRまで出すのではなく、SanityのContent LakeとStudioの中で大規模な編集作業を進める設計だ。
Hygraphは「人間の編集工程」に寄せている
原典ではHygraphが「AI featuresであってAI agentsではない」とされていた。
ただ、現在の公式情報ではその言い方は古い。
Hygraph AI & Automationでは、AI AssistとAI Agentsが分けて説明されている。
AI AssistはStudio内で生成、翻訳、改善を行う編集補助。
AI AgentsはTranslation Agent、Summarization Agent、SEO Agentのように、公開ワークフロー内で自動実行される機能だ。
ドキュメント上も、AI Agentsはエンタープライズ向けEarly Accessとして提供されている。
とはいえ、HygraphのエージェントはCosmicのような「コードを書いてPRを出すエージェント」ではない。
役割はコンテンツモデルとワークフローの内側に閉じている。
権限、監査ログ、編集者の承認、schema integrityを重視する方向だ。
Hygraphの強みはFederationとの組み合わせにある。
複数のコンテンツソースをGraphQL APIで束ねる設計を持っているので、AI機能も「分散したコンテンツを1つの編集ワークフローで扱う」方向に伸びやすい。
グローバル展開や多言語運用をしているチームなら、コード実行より翻訳・要約・SEOの自動化のほうが価値を出しやすい。
比較表で見るより、権限境界で見る
原典の横並び表は便利だが、導入判断では機能数より境界を見るほうがいい。
| 境界 | Cosmic | Sanity | Hygraph |
|---|---|---|---|
| CMSコンテンツの生成・更新 | できる | Content Agentでできる | AI AssistとAgentsでできる |
| 外部エージェントへのMCP文脈提供 | MCP Serverあり | Agent ContextとMCP serverを分離 | 専用MCP製品としては前面に出ていない |
| コードリポジトリ操作 | Code Agentが担当 | 主機能ではない | 主機能ではない |
| ブラウザ操作 | Computer Use Agentあり | 主機能ではない | 主機能ではない |
| 編集者承認・ガバナンス | ワークフロー次第 | Studioと権限制御が中心 | ワークフロー、権限、監査ログが中心 |
コードまで任せたいならCosmicを見る。
外部AIアプリにCMS文脈を安全に食わせたいならSanity Agent Contextを見る。
編集ワークフロー内の翻訳、要約、SEOを自動化したいならHygraphを見る。
同じ「AI CMS」でも、危ない場所が違う。
Cosmicはリポジトリとデプロイ権限、SanityはMCP経由のdatasetアクセス範囲、Hygraphはワークフロー上でAIが変更できるフィールドと承認段階が確認点になる。
原典の結論はそのまま使わない
原典はCosmicの立場が強い。
Cosmicの「AI team member」路線を理解するには良いが、Hygraphの現在の公式説明とはズレがある。
記事内の結論をそのまま採用するより、各社がAIを置いている層を抜き出す読み方が合う。
Markdown + Git + CLIラッパーという別解
3社の比較はSaaS型ヘッドレスCMSの上でAIをどう動かすかの話だが、同じ問題はCMSプラットフォームなしでも起きる。
このブログはAstro + Markdown + Gitで動いていて、ヘッドレスCMSは挟んでいない。
コンテンツはMarkdownファイル、frontmatterスキーマはZod定義、ビルド時バリデーション。
AIが触るのはファイルシステムとGitリポジトリだ。
かなチャット v2では、CLIラッパー経由でClaude Codeにジョブを投げて記事を生成し、完了後にバリデーションゲートを通している。
frontmatterの必須フィールド、セクション構成、画像配置をプログラムでチェックし、エラーがあれば通知が飛ぶ。
Hygraphが「翻訳→SEO→承認」のワークフローで回しているのと、やっていることの種類は同じだ。
差が出るのはスキーマの置き場所と権限の境界で、Hygraphはプラットフォーム内にコンテンツモデルを持つ。
こちらはCLAUDE.md、Zodスキーマ、テンプレートファイルにルールが散らばっていて、AIエージェントがファイルを読んでルールを理解する。
SanityのAgent Contextが「MCPでスキーマとコンテンツを外部エージェントに渡す」のと、CLAUDE.mdで「プレーンテキストにルールを直接書いておく」のは、インターフェースの形が違うだけで狙いは同じだ。
権限も重なる。
Cosmicは「AIにGitHub PRまで出させる」方向で、かなチャットは逆にツール承認ゲートで破壊的操作を止めている。
CMSの権限制御もCLIラッパーのツールゲートも、AIの出力をどこで人間が検査するかの問題だ。
WUPHFのLLM wikiはこの方向をチーム規模に広げていた。
Markdownを正本にしてGit履歴で追跡し、検索インデックスは後から被せて壊れたら再構築する。
ヘッドレスCMSのAI化がプラットフォームのDB・API・ワークフローの上に乗るのに対して、Markdown + Gitベースはファイルシステムとバージョン管理にAIを接続する形で同じ問題を解いている。