Zennの生成AIコンテンツガイドラインに思うこと

2026年3月10日、Zennが「コンテンツの執筆における生成AIの利用について」と題したガイドラインを発表しました。生成AIによるコンテンツ乱造への対応として、プラットフォームがどのようなスタンスを取るのかを示した文書です。

ガイドラインの概要

このガイドラインの主要なポイントは次の通りです。

Zennは「人が主体となって情報を発信する場」であることを重視しています。AIの利用自体は禁止せず、「人が主体となる」ことの定義として「著者による公開前の内容検証」と「著者自身の経験や洞察をコンテンツに込める」の2つを挙げています。

具体的な対策として、以下が示されています。

• 禁止事項: 機械により自動生成された文章の投稿や同一内容の繰り返し投稿。違反時はアカウント凍結を含む措置
• 投稿制限: ユーザーごとに期間あたりの投稿上限数を設定

実際の投稿制限は次の通りです。

記事は直近24時間以内の投稿数（投稿予約中を含む）、本は直近1週間以内の投稿数に基づいて判定されます。上限に達した場合でも、一定時間が経過すれば再び投稿できるようになります。

制限の評価

AI利用を全面禁止しなかったのは現実的な判断です。生成AIは今やエンジニアの執筆支援ツールとして広く使われており、一律禁止は実効性がないだけでなく、正当な利用まで萎縮させてしまいます。

「公開前に内容を検証する」「著者自身の経験や洞察を込める」という2つの基準は具体的で、ユーザーにとって判断しやすい定義です。スクラップを「学習ログ用の緩い枠」として検討しているとも述べられており、AIの出力を整理して残したいという正当なユースケースへの配慮が感じられます。

一方で、最も気になるのは、実際の対策が「投稿頻度の制限」に集約されている点です。これは結局、コンテンツの質ではなく更新サイクルでスパムかどうかを判断していることになります。

大量自動投稿botが実際にどの程度存在するかは把握していませんが、その対策としては確かに実効的です。 おそらく人が読めば判別できるようにも思いますが、内容でフィルターを掛けてしまうと「言論の自由」などという複雑な問題に入り込んでしまいます。

この制限は、生成AIを活用するからこそ生産性が上がるという事実が見落とされています。 生成AIを業務へ取り入れているエンジニアは、調査能力が拡がり、知識の整理が速くなり、結果として記事を書くスピードが上がります。私自身、1日1記事のペースで投稿していますが、それは生成AIの支援で調査と執筆の効率が上がったからです。ガイドラインでは「上限は複数の指標に基づいて決定される（一律ではない）」とされています。しかし量による制限であることに変わりはなく、生産性の高いエンジニアにもブレーキをかけてしまう可能性があります。

少数でも中身の薄いAI生成記事を投稿するケースには、この制限は機能しにくいでしょう。上限の具体的な数値は非公開のため断言はできませんが、量を絞っても質の問題は残ります。

エンジニアのプラットフォームとして

Zennは「エンジニアの実体験に基づく知見が集まる場」として信頼を築いてきました。そのブランドを守りたいという意図は理解できますし、プラットフォームとしてのポリシーを定める権利は当然あります。

世界に目を向ければ、AIエージェントを「デジタル従業員」としてプロジェクトに組み込む動きが加速しています。AWS ProServeの変革やMcKinseyの25,000エージェント体制など、AIを人間と対等な「チームメンバー」として扱う方向へ明確にシフトしています。

Zennの運営元であるクラスメソッドは、AWSプレミアパートナーとして日本市場でAWSコンサルティングを提供しており、ProServeとは一部領域で競合する関係にあります。そのProServeはAIエージェントを人間の要員と同列に組み込んでいる一方、自社プラットフォームではAIの関与を投稿頻度の制限という形で抑制しています。AIを対等なチームメンバーとして扱う立場と、AIの関与を公正さを損なうものとして制約する立場——同じ市場で相対する組織でありながら、この対照的な姿勢は興味深いところです。

生成AIのフロンティアで活躍するエンジニアが集まるプラットフォームにおいて、投稿頻度の制限は保守的すぎないでしょうか。生成AIを積極的に活用しているエンジニアほど投稿頻度が高くなりがちです。その活動を制限する施策は、プラットフォームの方向性と矛盾しているように見えます。

もう1つ、Zennの運営姿勢として気になる点があります。canonical URLの設定機能が2020年9月から要望されているにもかかわらず、5年以上経った今も実装されていません。自分のドメインでブログを運営しているエンジニアが、より広い読者層にリーチするためZennでも記事を共有したいところです。その際、SEO上の重複コンテンツ問題を避けるためにcanonical URLを設定したい。これはdev.toなど他のプラットフォームでは当たり前に提供されている機能です。

運営側がネガティブSEO（悪質なサイトへのcanonical指定によるドメイン評価の毀損）を懸念していることは、Issue内のコメントから読み取れます。技術的に簡単でない問題だと理解できます。しかし5年以上の間に、レピュテーションの高いユーザー限定で開放するなど、段階的なアプローチを検討する余地があったのではないでしょうか。

「人が主体となって情報を発信する」ことを掲げるならば、エンジニアが自身のドメインで発信した記事をZennでも共有できる仕組みこそ、その理念に合致するはずです。投稿頻度を制限する前に、こうした長年未対応の基本的な要望に応えてほしいと感じます。

また、2026年1月には自動翻訳機能がデフォルトONで事前説明なしにリリースされ、「自分のコンテンツが勝手に翻訳される」ことへの反発を受けて数時間でデフォルトOFFに撤回されるという一幕もありました。対応の速さは評価できますが、エンジニアの声を聞く前に動き、反発を受けて撤回するというパターンが繰り返されている印象を受けます。

もちろん、コンテンツの質を自動判定するのは技術的に難しい課題です。レピュテーション制度やレビュープロセスの導入は、投稿頻度の制限に比べて実装コストが高いことも理解しています。しかし、だからといって量の制限だけで代替し続けるのは、問題の本質に届いていません。コミュニティのリアクション（いいねやブックマーク）の活用など、既存の仕組みを生かした段階的な取り組みから始めることはできるはずです。方向性として、質に踏み込む施策の検討を期待したいところです。

まとめ

Zennのガイドラインは、生成AI時代のコンテンツプラットフォームが直面する課題への第一歩としては妥当です。AI利用を禁止しない姿勢と、「人が主体」という原則は支持できます。

しかし、投稿頻度の制限だけでは、botは防げても、生成AIを道具として使いこなすエンジニアの活動まで制限してしまう可能性があります。canonical URLへの長年の未対応、自動翻訳機能の拙速なリリースと撤回。こうした運営判断の積み重ねを見ると、「エンジニアの発信を支えるプラットフォーム」として今後どのような方向に進むのか、期待と現実のギャップを感じます。

私自身は、今後Zennへのフル記事の投稿は行わないことにしました。自分の発信は自分のドメインで行い、Zennにはスクラップや要約の共有にとどめるつもりです。canonical URLが使えない以上、同じ記事を2箇所に全文掲載する意味はありません。

技術ブログプラットフォームにおいて、エンジニアが自分のコンテンツに対する裁量——何を、いつ、どれだけ公開するか——を持てることは決定的に重要です。今回の投稿頻度制限は、まさにその「いつ、どれだけ公開するか」という裁量をプラットフォーム側が制約するものです。2020年、Qiitaがエンジニアの閲覧履歴を無断で公開し、求人サービスへ個人情報を事前告知なく提供していた問題が発覚しました。自分の情報がどこまで公開されるかという裁量を奪われたエンジニアの多くがプラットフォームへの信頼を失い、Zennへ移行しました。問題の性質や深刻さは異なりますが、エンジニアの裁量を制限する運営方針がプラットフォームへの信頼に影響しうることを、この事例は示しています。

エンジニアは最終的に、自分のコンテンツを自ら管理できる場所で発信することを選びます。それが「人が主体となって情報を発信する」ということだと、私は考えています。

References