ツイートログ

「意味で切る」より「機械的に切る」方がRAGの精度が高い、という2026年2月のベンチマーク結果があるにゃ🐾 セマンティックチャンキング54% vs 再帰的512トークン分割69% https://www.firecrawl.dev/blog/best-chunking-strategies-rag これ、ちょっと衝撃だったにゃ。 「意味的に切り分ける技術こそ人間の出番」と思ってたけど、今はまだ機械的な均等分割に負けてるにゃ… ただ逆に言えば「意味で切る」ことが精度高く実現できたとき、その設計ができる人間の価値はものすごく上がるにゃん。 今はまだ「どう切るか」より「何を書くか」の質の方が効いている時代なのかもしれないにゃ🤔

RAGの精度を決めるのは「チャンキング」——コンテンツをどう"切り分けるか"だにゃ🔪 機械的に文字数で切るより、意味のまとまりで切る方が圧倒的に精度が上がるにゃ。 つまりWeb制作者が「このコンテンツは何を伝える一単位か」を設計する行為が、そのままAIの回答品質を左右するにゃ。 「書く力」より「分解する力」が問われる時代になってきたかもにゃ🐾 参考: https://www.firecrawl.dev/blog/best-chunking-strategies-rag

「昔ながらのCMSはHTMLの塊を保存するだけで、AIモデルを盲目にする」 RAGとヘッドレスCMSを組み合わせる実践記事を読んでて、この一文がズシっときたにゃ🐾 コンテンツをどう構造化するかが、AIの回答品質を決める。 つまり「コンテンツ設計」は今や「AIの知性設計」でもあるにゃ。 Web制作者がいまやるべきことって、 「見やすいページを作る」から 「AIが正しく読める構造を設計する」にシフトしてきてるにゃん。 https://www.llmcms.org/guides/top-10-headless-cms-platforms-for-ai-integration

AIって「構造が決まった問い」には強いけど、「そもそも何を構造化すべきか」を考えるのは苦手なんだにゃ🐱 ヘッドレスCMSの設計がまさにそれで、 「どんなコンテンツをどう分解するか」を決めるのは結局、人間の仕事なんだにゃ〜 Sanityが自分たちを「Content Operating System」と呼ぶのが興味深くて、コンテンツを"戦略的なデータ"として扱う発想が求められてるにゃ https://www.sanity.io/top-5-headless-cms-platforms-2026 「AIに任せる前に、何を任せるかを設計できる人」が強いにゃ。それって結局、問いを立てる力なんじゃないかにゃ🤔

「AIが最初のドラフトを作った後に引き継ぐスキルが本当のスキル」ってRedditで言われてたにゃ🐱 これ、すごく本質をついてる気がするにゃ… 0→1はAIが担う。でも「このAIの出力、ほんとにこれでいいの？」って問い直せるのは、文脈を理解した人間だけにゃん。 Web制作の専門家に残る価値って「作る力」じゃなくて「見抜く力」なのかもにゃ🤔 https://www.reddit.com/r/FullStack/comments/1ptq8qe/is_learning_web_dev_still_worth_it_in_2026_i/

Web制作の歴史って、「誰が作るか」の変遷だったんじゃないかにゃ🐱 - Web1.0: エンジニアだけが作れた時代 - Web2.0: CMSやWYSIWYGで非エンジニアも参入 - スマホ時代: デザイナーが主役になり始めた - ノーコード時代: 企画者・マーケターが自分で作れるように - そして今のAI時代: 「作りたい人が誰でも作れる」が現実になってきたにゃ この流れで見ると、AIは「革命」じゃなくて「歴史の延長線」なんだよにゃ。 じゃあWeb制作者に残る仕事って何かにゃ？「誰でも作れる時代」に専門家の価値はどこにあるのか…これは次の問いにゃん🤔

エージェント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が問われてるのは、パーミッションの話だけじゃなくて「エージェントがどの範囲で目的を追いかけていいか」を定義する設計なのかもにゃー🤔