AIコーディングエージェントを使ってOSSを開発し、コミュニティに公開しようとしている方に向けた内容です。技術力があっても、投稿先のルールで弾かれるケースが増えています。その仕組みと対処法を整理しました。
Rustで書かれたラスター画像をSVGに変換するオープンソースエンジン「Open Vectorizer」の開発者が、Hacker NewsとRedditへの投稿で立て続けに壁にぶつかった事例があります。ローカル実行可能で、WebAssembly（ブラウザ上でネイティブに近い速度で動くバイナリ形式）にコンパイルでき、PotraceやVTracerといった既存ツールと張り合えるベンチマーク結果も出していたプロジェクトです。それでも公開の入口で止められました。
何が起きたか
Hacker Newsでは、新規アカウントによる「Show HN」（自作プロダクトを紹介する投稿枠）の投稿が一時的に制限されていました。コミュニティに不慣れなユーザーの流入が多かったための措置です。
r/rustでは投稿が自動削除されました。プロジェクト投稿には「AI生成コンテンツを大きく含まないことの証明」が必須というルールが追加されていたためです。開発にAIの支援を大きく使っていた以上、この証明はできませんでした。
r/opensourceのルールはさらに直接的です。「AI生成コンテンツはすべて低努力とみなし、投稿禁止（ban worthy）」という一文があります。MITライセンスでコントリビューターを募集していたにもかかわらず、投稿の土俵にすら上がれなかったわけです。
なぜ起きるか（原因の分解）
この状況は、単に「運が悪かった」では片付きません。段階的に見ていきます。
1つ目の層は、AIによってソフトウェアの生産コストが劇的に下がったことです。エージェントに依頼すれば、1時間で2万行のコードがGitHubに公開できてしまいます。動作確認も品質検証もされていないまま「作りました」という投稿だけが増えるのは事実です。コミュニティ側がこれに疲弊しているのは理解できます。
2つ目の層は、フィルターの設計ミスです。「AIを使って書かれたか」という問いは、「低品質な使い捨てコードかどうか」という本来知りたい問いの代理変数（プロキシ）として使われています。しかし両者は一致しません。丁寧に設計されたアーキテクチャの上でAIに実装を委任したプロジェクトと、雑なプロンプト1行で生成しただけのプロジェクトを、同じ「AI生成」というラベルで一括りにしてしまう問題です。
3つ目の層は、「AI生成」の定義そのものが揺らいでいることです。IDEの補完機能を使う開発者、GitHub Copilot（AIによるコード補完サービス）で関数単位を補完する開発者、詳細な仕様書からエージェントに実装させる開発者、アーキテクチャ設計・テスト作成・結果評価をすべて自分で行い実装だけをエージェントに委任する開発者。これらはどこまでが「人間が書いた」でどこからが「AI生成」なのか、線引きが年々難しくなっています。人間がキーボードで打った文字数を基準にしても、コードの品質や設計の妥当性は測れません。
自分のプロジェクトが該当するか確認する方法
投稿前に、対象コミュニティのルールを実際に確認する作業が欠かせません。以下は具体的な確認手順です。
- Hacker Newsは
guidelinesページとFAQで、Show HNの投稿条件（アカウント年齢やカルマ数の要件を含む）が変更されていないか確認します - Redditは対象サブレディットの
wiki/rulesページ、またはサイドバーの「community rules」を開き、「AI」「AI-generated」「certify」などのキーワードで検索します - サブレディットのモデレーター告知（stickied post）に、投稿ルール変更の告知が出ていないか直近1〜2週間分を遡って見ます
- GitHubリポジトリのREADMEやCONTRIBUTINGに、AI支援の有無を開示する項目を自分で設けているか確認します
該当するかどうかの判断基準は単純です。開発プロセスのどこかでコーディングエージェント（Claude Code、Cursor、GitHub Copilot Agentなど）に実装の一部でも委任していれば、多くのコミュニティの「AI生成コンテンツ」判定に引っかかる可能性があります。人間が最終レビューをしていても、ルール文言が「significant AI-generated content」のような曖昧な基準の場合は、投稿前にモデレーターへ個別確認するほうが安全です。
対策の手順
ルールに抵触せず、かつ正直にプロジェクトを公開する具体的な進め方です。
手順1: 開発プロセスの開示ドキュメントを先に用意する
READMEに「設計は人間が行い、実装の一部をAIエージェントに委任した」など、関与の度合いを具体的に書きます。「AI使用」を隠すのではなく、どこまで人間が関与したかを明示するほうが、審査側の信頼を得やすくなります。
手順2: ベンチマーク・テストで検証可能性を示す
Open Vectorizerのように、再現可能なベンチマークスイートを用意しておくと、「動くかどうか分からない生成物」との違いを客観的に示せます。テストカバレッジやCI（継続的インテグレーション）のパス状況をバッジで表示するのも有効です。
手順3: 投稿先を分散させる
Hacker News・Reddit以外にも、Lobsters（招待制で質を担保するコミュニティ）、言語別のDiscordサーバー、GitHub Discussionsなど、AI生成物への態度が異なる場が複数あります。1つの窓口で弾かれても、別の場では歓迎される場合があります。
手順4: ルール改定のタイミングを見極める
Hacker Newsの新規ユーザー制限のように、一時的な措置であるケースもあります。数週間〜数ヶ月後にガイドラインページを再確認し、制限が解除されていないか定期的にチェックします。
手順5: コミュニティへの直接コンタクト
Redditのモデレーターにモッドメール（modmail）でプロジェクトの背景と開発プロセスを説明し、例外的な扱いや投稿可否を事前相談する方法もあります。ルール文面だけでは判断が難しいグレーゾーンのプロジェクトほど、事前確認の効果は大きくなります。
確認しておきたいポイント
投稿前に見るべき点を整理します。
- 投稿先のルールページに「AI」「AI-generated」「certify」という語がないか検索する
- 自分の開発プロセスがどの段階でAIに委任しているかをREADMEで具体的に説明できるか確認する
- 再現可能なベンチマークやテストスイートを用意し、動作の正当性を第三者が検証できる状態にする
- 1つのコミュニティで弾かれても、投稿先を複数用意しておく
AIコーディングツールを使った開発自体は、もはや珍しいことではありません。ただし公開先のコミュニティルールは急速に変化しています。投稿前の数分間のルール確認が、せっかくのプロジェクトを無駄にしない一番確実な備えになります。