StoryblokをAIに触らせる？｜公開権限を誰が持つか

「AIエージェントをCMSにつないでも、どうせ下書きを作るだけでしょう」「MCP でつなげば、記事の更新も公開もAIに任せられるんですよね」——企業サイトやオウンドメディアの担当者から、正反対の二つの声が同じ時期に聞こえてきます。どちらも半分だけ当たっています。オーストリア発のヘッドレスCMSである Storyblok は、2026年10月にAIエージェント向けの手引きを公開し、つないだエージェントは、権限しだいで下書きの作成から公開、削除まで実行できることをはっきりさせました。問題は「できるかどうか」ではなく「どこまで渡すか」です。この記事では、Storyblok にエージェントの書き込みを許すときに、渡す権限の段階、人の承認を残す工程、誤りやブランドの逸脱の止め方、マーケと情シスの持ち分を、導入から定着までの順に整理します。

Storyblok は、記事を部品で持つオーストリア発のヘッドレスCMS

Storyblok は、オーストリアで生まれたヘッドレスCMSです。ヘッドレスCMSとは、記事の中身を持つ仕組みと、それをウェブサイトやアプリで見せる仕組みを切り離した型のCMSのことで、中身は API を通じて配られます。Storyblok はその中でも、記事を「部品（ブロック）」の組み合わせとして持ち、編集者は画面上で見た目を確かめながら部品を並べ替えられる点を売りにしてきました。欧米の企業サイトやブランドサイトでの採用が多く、日本語の解説はまだ多くありません。

ヘッドレスCMSと従来型のCMSのどちらを選ぶかという一般論や、他社製品のエージェント機能の考え方は別の記事で扱っているため、ここでは繰り返しません。この記事が扱うのは、すでに Storyblok を使っている、または採用を検討している会社が、そこにAIエージェントの書き込みを許してよいかという一点です。部品で記事を持つ仕組みは、AIにとっても扱いやすい一方で、型そのものを変えられると全ページに影響が出るという性質を持っています。

Storyblok の中身は、記事にあたる「ストーリー」、画像やファイルの「アセット」、部品の型である「コンポーネント」、選択肢の一覧などを持つ「データソース」に分かれています。エージェントに渡す権限を考えるときも、この四つのどれを読ませ、どれを書かせるかで整理すると話が早くなります。

2026年秋の三つの更新：エージェント向けの手引き、MCP サーバー、Strata

一つ目は、2026年10月12日に公式の変更履歴に載ったエージェント向けの手引き（スキル）です。AIのコーディング用エージェントに、Storyblok の作法や操作の名前、データの形を教えるための文書の束で、最初に読み込まれて適切な手引きを選ぶ入口、MCP の操作の手引き、画面側の部品づくり、記事の型の設計、Figma のデザインから部品を起こす手引き、コマンドラインで一括の移行や取り込みを行う手引きがそろっています。無料で、MIT ライセンスの公開ソフトとして、すべての契約で使えると案内されています。

二つ目は、その手引きが前提にしている MCP サーバーです。公式の文書では、提供元が運用する接続先にAIの道具からつなぎ、Storyblok の管理用の API を自然な言葉で操作できるものと説明されています。文書の最終更新は2026年9月29日です。前日の10月11日には、公式ブログが手引きの有無でエージェントの振る舞いを比べた検証記事を出しており、記事の一覧、作成、更新、削除までを実際にエージェントに実行させています。

三つ目は、10月26日の変更履歴に載った Strata です。記事を言葉の一致ではなく意味で探す検索の仕組みで、サイト内検索やチャットボット、社内の検索拡張生成（RAG）の材料に使えるとしています。最上位の契約で、組織ごとに一つの空間（スペース）に限って提供され、索引は1日1回自動で作り直されます。MCP サーバー経由で、Claude などのAIの道具から Strata の検索を呼べるとも書かれています。いずれも直近の公式発表であり、提供終了や新規受付の停止の告知は見当たりません。

誤解：「CMSにつないだエージェントは下書きしか作らない」

冒頭の一つ目の声、つまり「どうせ下書き止まり」という見方は、CMSに付いてくるAIの文章作成機能の印象から来ています。画面の中で「この段落を書き直して」と頼む機能なら、出てくるのは編集者が貼り付けるかどうかを選ぶ文章です。しかし MCP でつないだエージェントは、管理用の API を呼ぶ権限そのものを持って動きます。公式ブログの検証でも、エージェントは記事の作成、更新、公開、削除を実行しています。

その検証では、手引きを読み込んだエージェントが記事を更新したとき、指示の書き方の影響で、公開中の記事を下書きに留めず、そのまま公開し直した例が報告されています。手引きのないエージェントは同じ指示で下書きとして保存しました。筆者は、これを指示の書き方の帰結だと説明し、公開中の記事を変えるときは公開まで行うかどうかを指示に明記するよう勧めています。つまり、同じ道具でも、指示の一言で結果が下書きにも公開にもなるということです。

逆に二つ目の声、「全部任せられる」という見方も危ういものです。公式の MCP サーバーの文書は、すべての呼び出しを言語モデルが仲介するため結果は毎回同じにならないとしたうえで、一回限りの変更や試作に使い、大規模な変更や自動化にはコマンドラインの道具を使うよう勧めています。さらに、自律的に動く自動化の中で MCP サーバーを動かさないこと、削除の確認を隠さないことを明記しています。提供元自身が、任せきりにする使い方を想定していないわけです。

公式ブログの検証の結論も、この見方と合っています。手引きを読み込んだエージェントは、作業ごとにおおむね1割から2割5分ほど速く、変更や削除の前に警告を出す傾向が強かったと報告されています。ただし筆者は、エージェントの出力は確率的なもので、同じ指示でも実行のたびに結果が変わりうると断っています。速さと慎重さは手引きで上がっても、毎回同じ結果になる保証はないという前提で、運用を組み立てる必要があります。

MCP サーバーが分ける三種類の操作

Storyblok の MCP サーバーは、操作を探す、操作の中身を調べる、実行する、の三段で動きます。実行の道具は性質ごとに分かれていて、ここが権限を考える出発点になります。公式の文書の説明を、社内で決めることと並べると次のようになります。

実行の道具	中身（公式の説明）	社内で決めること
読むだけの実行	一覧の取得や中身の読み出し	どの空間を読ませるか。下書きも読ませるか
変える実行	作成と更新（公開もここに入る）	下書きまでか、公開まで許すか
消す実行	削除。利用者の明示の確認が必須	確認する人と、消してよい対象
アセットの登録	画像やファイルの登録と送信	画像の権利の確認を誰がするか

注意したいのは、公開は「消す」ではなく「変える」側に入ることです。削除には確認の画面が必ず出ますが、作成や更新は、標準では確認なしで実行されます。公式ブログも、変更を伴う操作は標準では確認を求めないと書いています。ですから、公開を人に残したいなら、確認の画面に頼るのではなく、権限そのものから公開を外すのが筋です。

もう一つの落とし穴は、記事の更新の操作が、記事の項目を部分的に書き換えるのではなく全体を置き換える仕様であることです。公式ブログは、更新のときは記事の全体を送らないと中身が失われると注意しています。エージェントが一部の項目だけを送れば、残りの項目が空になるおそれがあります。下書きで試すべき理由は、公開の誤りだけでなく、この消え方にもあります。

さらに二つ、公式の文書から読み取れる性質があります。一つは、MCP サーバーが使うのは管理用の API であり、公開中の記事を配る側の API は読めないことです。つまりエージェントが見ているのは、読者に届いている版ではなく、管理画面の中の版です。下書きと公開版が食い違っている記事について、エージェントは公開版を基準に話していないことがあります。もう一つは、画像の登録の仕上げに、利用者の端末で送信の命令を実行する必要があることです。画像を差し替える作業は、結局のところ人の手が一度入る作りになっています。

権限は「接続のとき」と「AIの道具の側」の二か所で絞る

公式の設定手順では、接続の方法としてサインイン（OAuth）を勧めています。AIの道具から接続すると Storyblok のサインイン画面が開き、項目ごとに読み取りと書き込みの権限を選び、つないでよい空間を選ぶ仕組みです。手順書は「AIの道具が本当に必要とする権限と空間だけを渡す」よう書いています。台本で動かすなどサインインできない場合は個人用の鍵（アクセストークン）を使い、その場合も対象の空間と権限を絞った鍵を勧めています。

二か所目は、AIの道具の側です。たとえば Claude の組織向けの契約では、組織の管理者が Storyblok の接続を有効にし、道具ごとに「常に許可」「承認が必要」「禁止」を決められます。標準では読むだけの道具も書き込みや削除の道具も「承認が必要」になっていると、公式の手順書は説明しています。ここで書き込みの道具を「常に許可」に変えた瞬間、確認なしで記事が書き換わる状態になります。

この二か所は、たいてい持ち主が違います。Storyblok の空間の権限はCMSの管理者、AIの道具の組織設定は情シスや全社のAI管理者が持つことが多いはずです。どちらか一方だけが絞っていても、もう一方が緩ければ意味が薄くなります。

• 個人用の鍵を使う場合、公式ブログは「書き込みと公開の両方ができる鍵を一本で渡さない」こと、公開させないエージェントの鍵では公開の許可を外すことを勧めている
• 公式の手順書には、Storyblok 側の利用者の役割（編集者・管理者など）が接続の範囲にどう反映されるかの説明はない。導入前に試験用の空間で、渡した権限で何ができてしまうかを実際に確かめる

定着の段階1：読むだけで、記事の棚卸しに使う

エージェントを入れる最初の段階は、読むだけの権限で、既存の記事を調べさせることです。部品で持つCMSは、どの記事がどの部品を使っているか、どの記事の説明文が空のままか、どの画像に代替テキストがないかといった情報を項目単位で持っています。人が画面を一枚ずつ開いて確かめていた点検を、エージェントに一覧にさせるのは効果が見えやすく、失敗しても何も壊れません。

この段階で、マーケ側は「エージェントに何を聞けば役に立つか」を覚え、情シス側は接続の仕組みと記録の取り方を確かめられます。公式ブログの検証でも、記事の一覧の取得は手引きの有無にかかわらず同じ結果を返しています。読むだけなら、結果の揺れが記事を壊すことはないので、慣れる期間としてちょうどよいのです。

ただし、読むだけでも渡す範囲は決めておきます。公開前の新製品の記事や、社外秘の発表予定が下書きとして入っている空間を読ませれば、その中身はAIの道具の側に流れます。どの空間の、どの状態の記事まで読ませるかは、この段階から決めておくべきことです。

定着の段階2：下書きまで。公開しない指示を毎回書く

読むだけで慣れたら、次は下書きの作成と更新を許します。ここでは権限から公開を外し、エージェントに渡す指示の冒頭にも「保存は下書きとし、公開はしない」と毎回書くようにします。権限で止め、指示でも止める二重の備えです。公式ブログが勧めている「公開まで行うかどうかを指示に明記する」という点を、社内の指示の型に組み込んでおくと、担当が替わっても守られます。

この段階で任せやすいのは、既存記事の説明文の下書き、多言語版の下書き、表記ゆれの修正案、関連記事の候補づけなどです。いずれも、人が下書きを開いて確かめ、自分の手で公開するという工程が残る作業です。逆に、価格や仕様、法令にかかわる記述の書き換えは、下書きであっても根拠を書かせ、担当部門の確認を経てから公開します。AIに事実の正誤を判断させないことが、この段階の約束です。

更新の操作が記事の全体を置き換える仕様であることにも、ここで備えます。エージェントに更新させたあとは、変わった項目だけでなく、変わってはいけない項目が空になっていないかを確かめる手順を入れておきます。最初の数週間は、更新の前後の差分を担当者が見る運用にしておくと安心です。

定着の段階3：部品の型の変更は、開発の手順に乗せる

記事の中身の次に来るのが、部品の型（コンポーネント）やデータソースの変更です。エージェント向けの手引きには、記事の型を設計する手引きや、デザインから部品を起こす手引きが含まれており、型の変更はエージェントに任せやすい作業として想定されています。ただし型の変更は、その型を使う全ページの表示に響きます。部品の項目を一つ消せば、その項目に入っていた中身が全記事で見えなくなることもあります。

そこで型の変更は、会話でその場で行うのではなく、開発の手順に乗せるのが安全です。公式の文書は、一括の変更や継続的な配備には、試し実行ができて同じ結果を再現できるコマンドラインの道具を使うよう勧めています。エージェントに型の変更案を作らせ、それをコードとして記録し、試験用の空間で試し実行し、開発の担当者が確認してから本番に反映する、という流れです。

この段階を担うのは、マーケではなく開発や情シスの側です。エージェント向けの手引きは「開発者がAIのコーディング用エージェントに Storyblok の作業を任せる」ためのものと位置づけられています。マーケの担当者が会話のついでに型を変えられる状態は作らない、という線をここで引いておきます。

公開を人に残す理由：誤りとブランドの逸脱は公開後に広がる

公開を人に残す理由は単純で、公開された記事は検索エンジンやAI検索、社外のサイトに取り込まれ、直しても元に戻らない部分が出るからです。Strata のように記事を意味で探してチャットボットの回答に使う仕組みを入れていれば、誤った記述はサイトの外だけでなく、自社の回答の中にも広がります。エージェントが書いた一文の誤りが、問い合わせ窓口の回答として何度も繰り返される可能性があるわけです。

エージェントの書いた下書きで起きやすい誤りやブランドの逸脱は、次のようなものです。どれも、エージェントの出来の良し悪しより、確かめる工程があるかどうかで防げるかが決まります。

• 料金や仕様の数字を、古い記事や別の製品の記事から持ってきて書き換える
• 社内で使わないと決めた言い回しや、競合を名指しする比較表現を入れる
• 公開中の記事を更新したついでに、指示の解釈で公開まで行ってしまう
• 更新で記事の全体を置き換え、問い合わせ先や注記の項目を空にする
• 削除の確認画面で、記事の中身をよく見ないまま承認してしまう

止め方の基本は、公開の権限を人だけが持つこと、そして公開前に確かめる項目を決めておくことです。確かめる項目は、数字と固有名詞、法令や表示の規制にかかわる記述、ブランドの言葉づかい、消えた項目の有無の四つに絞ると続けやすくなります。

削除はごみ箱に入る。それでも外の世界からは消える

削除については、Storyblok の仕組みが一つの安心材料を用意しています。公式ブログによれば、削除された記事はごみ箱に移り、元に戻せます。また MCP サーバーは削除の前に必ず利用者の確認を求め、公式の文書は、承認する前に記事の番号や画像の番号、部品の名前を確かめるよう書いています。検証でも、エージェントは公開中の記事を消す前に確認を求め、手引きを読み込んだ側は公開中のページが消えることまで指摘しています。

それでも、削除は人に残すべき操作です。ごみ箱から戻せるのはCMSの中の話であって、公開中のページが消えている間に、検索結果やリンク元、広告の遷移先が失われることは戻せません。公式ブログも、エージェントは文脈がなければ記事の重要性を判断できないとして、削除を確認するよう勧めています。

実務では、エージェントには削除の候補を一覧にさせるところまでを任せ、実際の削除は担当者がCMSの画面で行う運用にすると、確認の画面を流し読みで承認してしまう事故を避けられます。確認の画面は止める仕組みではなく、止めるための最後の機会だと考えておくのがよいでしょう。

Strata を入れるなら「何を読ませるか」を先に決める

Strata は検索の仕組みなので、エージェントの書き込みとは別の話に見えます。しかし実際には、どの状態の記事をAIに読ませるかという、同じ種類の判断を求めます。変更履歴によれば、Strata が返す記事の版は、使う鍵が下書き用（プレビュー）か公開用かで決まります。下書き用の鍵で検索を組めば、公開前の記事が検索結果やチャットボットの材料に混ざるおそれがあります。

社外向けのサイト内検索やチャットボットに使うなら公開用の鍵、社内で記事の重複や関連記事を探すための棚卸しに使うなら下書き用の鍵、と目的ごとに分けます。また索引は1日1回自動で作り直されるため、記事を直したり取り下げたりしても、検索結果に反映されるまでに時間差が出ることがあります。急いで取り下げる必要がある記事のために、手動で索引を作り直す手順を担当者が知っておくべきです。

多言語の扱いにも判断が要ります。変更履歴によれば、Strata はどの言語で検索しても、空間の既定の言語で索引された記事から意味の近いものを返します。海外の顧客向けのチャットボットで、翻訳がまだない記事が、既定の言語のまま回答の材料に使われることがあり得るということです。翻訳の確認を経ていない記事を海外向けの回答に混ぜてよいかは、各国の担当と決めておくべき点です。

Strata は最上位の契約に限られ、組織ごとに一つの空間でしか使えません。複数のブランドや国ごとに空間を分けている会社では、どの空間に入れるかが先に議論になるはずです。変更履歴には、データの扱いや利用量の上限、料金の詳細は書かれていないため、契約前に提供元に確かめる項目として残しておきます。

マーケと情シスの持ち分

ここまでの話を、誰が何を持つかで整理すると次のようになります。ポイントは、中身の判断はマーケ、接続と権限は情シス、型の変更は開発と、三つに分けることです。一人の担当者が全部を持つ体制だと、権限を広げる判断と、その権限で起きたことを確かめる役割が同じ人に集まってしまいます。

持ち分	マーケ（サイト・メディア担当）	情シス・開発
接続	使いたい作業を申請する	サインインで渡す空間と権限、AIの道具の組織設定
記事の中身	下書きの確認と公開、確かめる項目の運用	関与しない
部品の型	変えたい理由を伝える	コードとして記録し、試し実行し、反映する
削除	削除してよい記事を決める	削除の操作の記録を保管する
Strata	検索に出してよい記事の範囲	使う鍵の種類、索引の作り直しの手順

持ち分を決めたら、それを短い文書にして、エージェントに渡す指示の型と一緒に置いておきます。権限を広げるときは、マーケの申請と情シスの承認の両方を通すという約束を一つ書いておくだけで、気づかないうちに公開まで渡っている状態を防げます。

外部の制作会社にサイトの運用を委託している場合は、もう一段の注意が要ります。制作会社の担当者が自社のAIの道具から Storyblok につなげば、自社の組織設定の外側から、本番の空間に書き込める経路ができます。委託先にエージェントの利用を認めるかどうか、認めるなら渡す空間と権限、記録の提出を、委託の契約や運用の取り決めに書いておきます。

定着を測る：月に一度の見直しで見るもの

エージェントの運用は、入れた日よりも、慣れてきた三か月後のほうが危うくなります。確認が形だけになり、権限が少しずつ広がっていくからです。月に一度、次の手順で見直す場を持つと、段階を上げるか戻すかを根拠を持って決められます。

見直しで大事なのは、エージェントの出来ではなく、人の確認が機能しているかを見ることです。差し戻しが一件もない月が続いたら、エージェントが優秀になったのか、確認が流されているのかを疑ってみる価値があります。

よくある質問

エージェント向けの手引きを入れれば、誤操作は防げますか

防げるとは言えません。公式ブログの検証では、手引きを読み込んだエージェントは変更や削除の前に警告を出し、作業も速くなりましたが、同じ検証で公開中の記事をそのまま公開し直す例も出ています。手引きはエージェントの作法を整えるものであり、権限の代わりにはなりません。

マーケの担当者が自分の Claude からつないでもよいですか

組織として許可した範囲ならかまいませんが、つなぐ前に情シスに申請し、サインインで選ぶ空間と権限を決めておくべきです。組織向けの契約では、管理者が接続の可否と道具ごとの許可を決められます。個人の契約から本番の空間に書き込める状態は避けます。

下書きだけなら、確認しなくてもよいのでは

下書きでも、更新が記事の全体を置き換える仕様である以上、項目が消えることはあります。また下書きは、Strata を下書き用の鍵で組んでいれば検索結果に混ざる可能性があります。下書きは公開されないから安全、とは限らないと考えておくのが無難です。

まとめ

Storyblok の2026年秋の更新で、AIエージェントがCMSを直接操作する道筋ははっきりしました。MCP でつないだエージェントは下書き係とは限らず、渡した権限の範囲で公開も削除もできます。だからこそ、読むだけ、下書きまで、型の変更、公開の順に段階を踏み、公開と削除は人に残すことが運用の軸になります。権限はサインインのときとAIの道具の側の二か所で絞り、型の変更は開発の手順に乗せ、Strata を入れるなら読ませる記事の状態を先に決めます。中身はマーケ、接続と権限は情シス、型は開発という持ち分を決め、月に一度、人の確認が機能しているかを見直す。AIに公開の判断をさせず、根拠を書かせ、人が確かめる範囲を先に決めておけば、エージェントはサイト運営の手を確実に軽くしてくれます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。