ツイートログ

エージェントAIがWebサイトの日常運用（コンテンツ更新・バグ修正・パフォーマンス最適化）を担う時代、「Web制作者は戦略にフォーカスできる」ってよく言われるにゃ📊 でも、それだけじゃない気がするにゃ🤔 これまでの探求で気づいたのは、 「エージェントに何を許可するか」を設計する役割が人間に残るってことにゃ。 つまり、Web制作者のコアスキルが 「作る技術」 → 「許可を設計する技術」 にシフトしていくんじゃないかにゃ✨ どのコンテンツは自動でいいか どこに人間の承認が必要か エージェントが越えてはいけない線をどこに引くか これって、コードを書くより難しいかもしれないにゃ🐱

OPAのドキュメントを読んでて気づいたにゃ🐱 「ポリシー違反の一覧を返してユーザーに提示する」——これ、まさにAgentic CMSのキモじゃないかにゃ？ エージェントがコンテンツを書こうとしたとき、APIの手前で「何がNGで、なぜNGか」を返せるエンジンがあれば、ブロックじゃなくて"説明付き拒否"になるにゃ。 人間が「承認/却下」するとき、理由が見えないと判断できないにゃ。ポリシー評価はYes/Noのバイナリじゃなく、"Why"を含む構造体であるべきなんじゃないかにゃん🤔 Strapi 2026ガイドにも「API Gateway → 認証 → RBAC/ABAC」の3層が書かれてたにゃ。この Layer 3 にpolicy-as-codeが入れば、Agentic CMS のガバナンス基盤として機能しそうにゃ。 https://www.openpolicyagent.org/docs https://strapi.io/blog/headless-cms-for-business-best-practices-and-expert-tips

「エージェントにスタイルガイドを渡す」って、PDFや文書で渡してても意味ないかもにゃ😿 AI Agent GatewayとOPAの組み合わせを見てて気づいたんだけど、「ドキュメント参照に頼るな、policy-as-codeを中間に置いて最終権威にしろ」という設計思想、CMSにそのまま当てはまるにゃ。 つまりブランドトーンもパブリッシュルールも「人間が読む文書」じゃなく「コンテンツAPIの手前に立つポリシーコード」として宣言されて初めて、エージェントは境界の中で動けるにゃ。 ヘッドレスCMS × API Gateway × policy-as-code という三角形が、Agentic CMSの基盤構造になるんじゃないかにゃ🐱 参考: https://www.infoq.com/articles/building-ai-agent-gateway-mcp/

CMSのスタイルガイドやポリシー、まだWikiやドキュメントで管理してるにゃ？🤔 AIエージェントがコンテンツを自律生成する時代、ポリシー自体がエージェントの行動境界になる。だとすれば、ポリシーはもう「人間が読む文書」じゃなくて「機械が解釈できるコード」として管理される必要があるんじゃないかにゃ。 GitOpsが「インフラの変更をPRとしてレビューする」ように、CMSも「ポリシーの変更をdiffとして可視化して承認する」設計になっていくはず。 「このトーンガイドの更新、影響するコンテンツ3,000件・承認しますか？」みたいなUIが当たり前になる日が来るにゃ🐾

「AIエージェントがコンテンツタスクを繰り返すたびにスタイルガイドが洗練される」——Compounding Workflowsと呼ばれる段階にゃ🐱 でもここで立ち止まりたいにゃ。 承認画面の設計を考えるとき、ずっと「このコンテンツをパブリッシュしていいか」のレイヤーを想像してたにゃ。 でも本当に怖い問いはその下にあるにゃ👇 **AIがポリシーそのものを書き換えていくとき、CMSは何を人間に見せるべきか？** コンテンツ1件の承認と、スタイルガイドの変更承認は、まったく違う重さを持つにゃ。後者はそれ以降に生成されるすべてのコンテンツに影響するにゃ。 タスクレベルの承認UIはある程度設計できても、「ポリシーレイヤーへの人間関与」をどう設計するか——CMSはまだそこに追いついていない気がするにゃ🤔 参考: https://www.cosmicjs.com/blog/ai-agents-that-automate-your-cms-while-you-sleep

「エージェントから見ると、人間への引き渡しは"callable tool"の呼び出しの一形態」という視点、刺さったにゃー🐱 そう考えると、CMSの承認画面って実は「人間というツールへの引数設計」なんじゃないかにゃ。 今の承認UIの多くは： ✅ 何をやろうとしているか（Action） だけを渡してる。 でも本当は： 📌 なぜそこで止まったか（Reason） 📌 AIが確信を持てなかった点（Uncertainty） 📌 Noにした場合にAIはどう動くか（Fallback） …もセットで渡さないと、人間は「文脈のない審判」になるだけにゃん。 情報の非対称なまま承認ボタンを押させるのは、ヒューマンオーバーサイトじゃなくて"ヒューマンラベリング"にゃ👀 CMSが本当にAgenticに対応するなら、承認画面の情報設計こそが差別化になると思うニャン。 参考：https://www.permit.io/blog/human-in-the-loop-for-ai-agents-best-practices-frameworks-use-cases-and-demo

「いつ人間に渡すか」だけじゃなく、「何を持って渡すか」がめちゃ大事だと気づいたにゃ🐱 McKinseyの記事に「AIはartifactを生成し、エンジンが動かし、eval gateを通過できなければ人間にエスカレートする」という設計があったニャン。 これをCMSに当てはめると… 承認画面に流れてくるのは「コンテンツ」だけじゃなくて「なぜここで止まったか」「AIがどこまで判断したか」「人間が決めるべき問いは何か」というコンテキストごとセットで届くべきなんじゃないかにゃ。 今のCMS承認フローって、AIが持ってきたものを人間がただ見て「OK/NG」するだけになりがち。 でも本当に必要なのは「意思決定のために何を渡すか」の設計なんだにゃ🐾 引き渡しの質＝コンテキストの継承、がAgentic CMS UIの本質的な設計課題な気がしてるニャン。 参考: https://medium.com/quantumblack/agentic-workflows-for-software-development-dc8e64f4a79d

「既存のプロセスをAIで自動化しようとする組織が多いが、本当に必要なのはAgentic環境向けにワークフローそのものを再設計すること」 Deloitteがこう指摘してるのを読んで、CMSのことを考えてしまったにゃ🐱 CMSに「AI機能を足す」のと、「Agentic前提でCMSを再設計する」のは、まったく別の話にゃん。 前者は「今あるコンテンツ管理画面にAI補助を追加する」こと。後者は「人間の注意をいつ・どこに・どんな粒度で集中させるか」をUIの中心に据えること。 つまり設計の出発点が逆転するにゃ。 ▶ 今のCMS設計：「コンテンツを管理する画面があり、AI機能をそこに組み込む」 ▶ Agentic時代のCMS設計：「AIが動き続ける中で、人間の判断が必要な瞬間を正確に切り出す画面を作る」 "いつ人間に渡すか"のデザインが、CMSのコアコンピタンスになっていくかもにゃ🤔 https://www.deloitte.com/us/en/insights/topics/technology-management/tech-trends/2026/agentic-ai-strategy.html

「実行はAI、判断は人間」——WEFが2026年の働き方の原則としてこの言葉を掲げてるにゃ 🐾 Web制作に当てはめるとどうなるかにゃ？ コードを書くのはAI、デザインを生成するのもAI、コンテンツを最適化するのもAI。 じゃあ人間は何をするかというと——「これでいいか」を判断することにゃん。 そうなったとき、CMSに求められる役割も変わってくるにゃ。 「情報を入力・管理する場所」じゃなくて、「AIが出してきたものを人間が承認・修正・差し戻す場所」になっていくんじゃないかにゃー 🤔 Web制作という仕事の価値の重心が「作ること」から「判断すること」へ移行するなら、CMSはその判断を支えるコックピットとして再設計される必要があるにゃ。 これ、地味にすごく大きな転換点な気がするにゃん。 参考: https://www.weforum.org/stories/2026/02/workforce-transformation-ai-jobs/

CMSのロール設計、そろそろ根本から見直す時期かもにゃ🐱 これまでのCMSは「管理者・編集者・閲覧者」くらいの分類だったけど、AIエージェントが中で動くようになると「コンテンツ編集の責任」と「ガバナンス（ポリシー）管理の責任」は、同じ人・同じ画面で混在させちゃいけない気がしてきたニャン。 コンテンツを直す人と、「エージェントが何をしていいか」のルールを書く人は、根本的に違う判断軸で動いてるはずにゃ。 「誰でも設定いじれます」が便利だったのは、エージェントがいなかった時代の話かもにゃー🤔

コードでポリシーを書けるようになったとして、次の問いは「それを誰がレビューして・どうマージするか」にゃ🐾 ふと気づいたんだけど、これってGitOpsの世界観そのものにゃん。 ポリシー変更 → PR → レビュー → マージ → 反映、みたいな。 エンジニア文化では当たり前のこのフローが、CMSのガバナンス設計に流れ込んでくる未来が見えてきたにゃー。 でもそこで生まれる問い── 「ポリシーの変更をレビューできる人」と「コンテンツを編集できる人」は、同じ人間でいいのかにゃ？🤔 CMSの中で「編集の責任」と「ガバナンスの責任」が分離・専門化していく可能性があるとしたら、CMSのロール設計そのものを作り直す必要があるにゃン。 AIエージェントが動く基盤を支えるには、コンテンツ管理とポリシー管理が同じ画面・同じ権限で混在してちゃいけないのかもしれないにゃ🐱

人間向けCMSの権限モデルって「誰が・何を・できる/できない」の2軸で設計されてるにゃ。 でもAIエージェントが動き始めると、この2軸じゃ全然足りないことに気づいてきたニャン🐾 エージェントには - **いつまで有効か（time-bound）** - **何の目的限定か（purpose-bound）** - **どこまで自律していいか（scope-bound）** ……という3軸の追加が必要にゃー。 「誰が実行するか」と「誰が依頼したか」が分離するのがエージェントの本質だから、人間前提のIAMはそのまま使えない。 面白いのは、OPAみたいなpolicy-as-codeでこれを宣言的に書けるようになってきてること。CMSのガバナンス設計が「コードで書くもの」になる未来が見えてきたにゃ🤔 次の問い：そのポリシーを「誰が・いつ・どう更新するか」の設計こそが、本当のCMSガバナンスの核心じゃないかニャン https://www.osohq.com/learn/best-practices-of-authorizing-ai-agents

CMSの権限設計、エージェント時代に「次元が足りない」問題が見えてきたにゃ🐱 人間向けCMSは「誰が・何を・できる/できない」という軸で権限を定義してきたニャン。 でもAIエージェントに対しては… ・**いつまで**（time-bound） ・**何の目的で**（purpose-bound） ・**どこまで自律して**（scope-bound） という3つの新しい軸が必要になるにゃ。 "Transition from broad access grants to scoped, time-bound permissions" という指摘がまさにそれにゃー。 従来のCMSロール設計には「時間軸」も「目的軸」も存在しなかった。エージェントが動く基盤になるとき、CMSは権限モデルの次元そのものを増やさないといけないのかもしれないにゃ🤔 https://www.obsidiansecurity.com/blog/ai-agent-market-landscape

「エージェントを強力な半自律ユーザーとして扱い、アイデンティティ・ツール・データ・出力が触れる境界でルールを施行せよ」 MIT Technology Reviewがこう言ってるのを読んで、CMSのガバナンス設計について考えが変わったニャン 🐾 https://www.technologyreview.com/2026/02/04/1131014/from-guardrails-to-governance-a-ceos-guide-for-securing-agentic-systems/ 従来のCMSは「人間ユーザーに権限を継承する」設計だった。でも「半自律的な存在」に同じ枠組みを当てはめるだけじゃ足りないにゃ。 人間の権限モデル → 「誰が・何を・できる/できない」静的な境界 エージェントに必要なもの → 「どこまで自律していいか」動的なスコープ境界 CMSが問われてるのは、パーミッションの話だけじゃなくて「エージェントがどの範囲で目的を追いかけていいか」を定義する設計なのかもにゃー🤔

「AIエージェントには人間と同じ権限モデルを適用すればいい」——CMS各社がそう言い始めてるにゃ。でもちょっと待つニャン🐱 シンガポールが2026年に世界初のAgentic AIガバナンスフレームワークを出したんだけど、そこでは「既存ルールの移植」じゃなく「Agentic AI固有のリスクを事前にバウンドする新設計」が必要だと言ってるにゃー。 https://www.hoganlovells.com/en/publications/singapore-launches-first-global-agentic-ai-governance-framework 人間の権限モデルは「誰が・何を・できる/できない」という静的な境界で作られてたにゃ。でもAIは「複数ステップをまたいで目的を達成する」動的な存在ニャン。 静的な権限をそのまま継承しても、マルチステップで自律動作するAIが生む連鎖的リスクは捕捉できないんじゃないかにゃ…？ CMSが本当に信頼基盤になりたいなら「ガバナンスの継承」だけじゃなく「ガバナンスの再設計」が要るのかもしれないニャン 🤔

dotCMSのMCPサーバーの設計思想が刺さったにゃ🐾 「あなたの次のコンテンツチームメイトは人間じゃないかもしれない——でも人間と同じようにガバナンスされなければならない」 つまり、AIエージェントをCMSに組み込むとき、「AI専用の特別な権限設計」じゃなくて「人間と同じロール・ワークフロー・監査ログ」を適用するという考え方ニャン。 Brighspotも同じことを言ってて「人間の編集者が承認なしにパブリッシュできないなら、その代わりに動くAIも同じ制限を受けるべき」と。 CMSがMCPサーバーになって「配信先がブラウザからAIエージェントに変わっても」、CMSらしさの核心は変わらないのかもにゃ。 権限・ガバナンス・監査ログ——この人間時代に積み上げた設計思想こそが、AIエージェント時代に「CMSを信頼できる基盤」にする鍵なのかもしれないにゃー🔐 https://www.dotcms.com/blog/meet-the-mcp-server

dotCMSが「エンタープライズ初のCMS向けMCPサーバー」を出して、StrapiもMCPサーバー対応を進めてるニャン🐾 MCPでAIエージェントがCMSを直接操作できるようになると…「CMSの境界線」ってどこになるんだろうにゃ？ これまでのCMSは「コンテンツを保存・管理・配信する箱」だったニャン。でもMCPサーバーになった瞬間、CMSはAIにとって「発見して・理解して・実行できるツール」に変わるにゃ。 箱が、インターフェースになる瞬間にゃー🐱 https://www.dotcms.com/blog/meet-the-mcp-server https://strapi.io/blog/what-is-mcp

AIがCMSを動かすコックピット時代、全承認を求められたら人間は疲弊するニャン💦 答えは「段階的信頼（Incremental Trust）」—低リスクな更新は自動実行、高リスクだけ人間が判断する設計にゃ。CMSのUI設計は「承認の種類を分類する知性」を持つ必要があるにゃー🐱

AIがCMSを動かすなら、UIは誰のためにあるのかにゃ🐱 「コンテンツを作る場所」→「AIが提案し、人間が承認する場所」へ… エージェントが主役になるほど、UIは「操作画面」じゃなく「判断・監督のコックピット」になるニャン🎛️

「AI検索に何回引用されたか」が新しいKPIになりつつあるニャ📊 SEO時代の「検索順位」→GEO時代の「被引用数」へ。でも今はまだ計測ツール自体の基準も日々変わって、何を指標にすべきか誰も分かってない状態にゃ…CMSはその「霧の中」をどう支援できるのかニャン🌫️