プロンプト・コモンズ ── 宣伝資材プロンプトを公開し、議論で磨く場── 業界共有のプロンプト・ライブラリ + 双方向議論で進化する仕組みの、コンセプトと実装仕様書

01なぜこれを作るのか

製薬の宣伝資材作成の現場で、過去 18 ヶ月で起きた最大の変化は、「資材ドラフトの初版を AI が書く」 ことが当たり前になったことです。ChatGPT、Claude、Gemini、社内 LLM ── どれを使うかは別として、MR 向け資材、医療従事者向け説明資材、患者向け IP、社内研修資材まで、起案は AI を起点にする企業が大半を占めるようになりました。

ところが、業界横断で見ると、ここに 3 つの非効率が積み上がっています。

• 再発明の重複 ── 各社が、ほぼ同じ目的の同じプロンプトを、独立に試行錯誤して作っている。学習曲線の 最下層を 30 社が並走 している状況です
• "良いプロンプト" の死蔵 ── 一部の熟練者が辿り着いた、コンプライアンスと品質を両立するプロンプトは、組織内のチャットや個人のメモに沈み、退職とともに消えます
• 業界規律の伝播の遅さ ── 薬機法・販提G・製薬協コードの最新解釈が、プロンプトの形で共有されない。だから違反パターンも各社が独立に踏みます

結論を先に置きます。プロンプトは "考え方の骨格" であり、企業秘密ではない。出力 (実際の資材) は各社の責任で審査されるため、プロンプトの公開が直接コンプライアンスを下げることはありません。むしろ、業界全体のコンプライアンス感度を底上げします。本稿の提案は、プロンプトの "オープン化と継続改良" を、業界が共有する公共財として運用する仕組み です。

02何を作るのか ── 全体像

プロンプト・コモンズは、次の 5 つの要素から成る Web プラットフォームです。

これらが組み合わさって、「プロンプトを起点にした、業界横断の継続的議論サイクル」 を構成します。

03なぜ公開できるのか ── オープン化の論理

真っ先に挙がる反論は 「うちのプロンプトは出さない。競合優位の源泉だ」 です。これに 3 段階で答えます。

段階 1 ── 競合優位の所在: 製薬企業の競合優位は、プロンプトそのものよりも、(a) 自社の臨床データ、(b) ターゲット患者さんの理解、(c) MR の現場知見、(d) 出力資材の社内審査体制、にあります。プロンプトは、これらを 表現するための器 に過ぎません。器を共有しても、中身 (各社のデータと知見) は共有されません。

段階 2 ── 公開のメリット: 自社のプロンプトを公開する 1 社は、業界全体からのフィードバックを得られます。コンプライアンスの観点、表現の改善、未認識のリスク。1 社で抱えると 1 人の頭しか働かないが、公開すれば 100 人の頭が働きます。

段階 3 ── 公開のリスク管理: 機密性が懸念される箇所は、プロンプト中で {{PRODUCT_X}} のような変数化で抽象できます。プラットフォーム側もガイドラインで「具体的な未承認情報・治験データ・商業機密の混入禁止」を明示。投稿前の自動スキャンも提供します。

04利用シナリオ

4 つの典型シナリオで、何が起きるかを描きます。

シナリオ A ── ベテラン審査担当が、自身のプロンプトを公開する

「適応外使用を匂わせない MR 向け説明資料の構造を作るプロンプト」を、製薬企業 X 社の Y 氏が公開。Y 氏には、自社で 3 年運用して、薬機法 §66 違反フラグが立たなかった実績がある。投稿時に 運用ログサマリー (匿名化) も添付する。

シナリオ B ── 新人が、業界共有プロンプトを起点に学ぶ

製薬企業 Z 社の新人 W さんは、自社プロンプトを持たない。プロンプト・コモンズで「MR 向け基礎資料」タグで 12 件のプロンプトを比較し、Vote が高い 3 件を読み、議論スレッドを追う。議論スレッドが教科書になる。

シナリオ C ── コンプライアンス担当が、業界規律をフィードバックする

製薬協コードの解釈担当 V 氏が、公開プロンプト P-218 の議論スレッドに 「ここの表現は、製薬協コード §3.1 の最新解釈と矛盾します」 とコメント。投稿者と他の利用者が議論し、改良版 P-218.v2 がフォークされる。業界規律が、文書ではなくプロンプトの差分として伝わる。

シナリオ D ── AI 開発者が、業界ニーズを把握する

LLM プロバイダの開発者 U 氏が、プロンプト・コモンズで「薬機法準拠」「販提G準拠」タグで議論を追う。業界が AI に何を求めているか、どこで詰まっているかが見える。次世代モデルのファインチューン方針が、業界のニーズに直結する。

05主要機能

機能の全体を、利用者ロールごとに整理します。

06アーキテクチャ

使う道具 (技術) を選ぶときは、(a) いま借りているサーバー (VPS = 自分専用に借りた一台のサーバー) をそのまま使える、(b) 小さく始めて後から増やせる、(c) 毎月の運用費が安い、の 3 つを優先しました。

このあと、画面・処理・データ保管の 3 つの層に分けた図と、それぞれで使う道具が出てきます。聞き慣れない名前が並びますが、それぞれ「何のための道具か」を一言で添えてあります。難しければ名前は読み飛ばして、役割だけ拾えば十分です。

全体構成

┌─────────────────────────────────────────────────────────────┐
│  Frontend (Next.js 14 App Router, TypeScript, Tailwind)     │
│  - SSR for SEO + Client interactivity                       │
│  - Markdown editor (CodeMirror 6)                           │
│  - Diff viewer (react-diff-viewer-continued)                │
└──────────────────┬──────────────────────────────────────────┘
                   │ HTTPS / WebSocket
┌──────────────────┴──────────────────────────────────────────┐
│  API (FastAPI + Pydantic, Python 3.12)                      │
│  - REST endpoints                                           │
│  - WebSocket (real-time comments)                           │
│  - Background jobs (Celery + Redis)                         │
└──────────────────┬──────────────────────────────────────────┘
                   │
┌──────────────────┴──────────────────────────────────────────┐
│  Storage Layer                                              │
│  - PostgreSQL 16 (primary data)                             │
│  - Redis 7 (cache, sessions, job queue)                     │
│  - S3-compatible object store (attachments, exports)        │
│  - Meilisearch (full-text search; Phase 2)                  │
└─────────────────────────────────────────────────────────────┘

Compliance Scan Service (separate microservice)
  - Pattern matching (regex + rules)
  - LLM-based review (Phase 3+)
Notification Service
  - Email (SES / Resend)
  - Web Push (VAPID)
Auth: NextAuth + Email OTP / OIDC (pseudonym supported)

図に出てくる耳慣れない名前を、一言ずつ補っておきます。WebSocket は、サーバーとブラウザが回線をつなぎっぱなしにして、新しいコメントが付いた瞬間に画面へ届ける仕組み (普通の通信は「聞かれて初めて答える」が、これは「向こうから話しかけてくる」)。Redis は、よく使うデータを手元に置いて素早く出すための一時置き場 (速い小型の保管庫)。Celery は、時間のかかる処理 (メール送信や自動チェックなど) を裏側でまとめてこなす作業係です。これらは利用者からは見えませんが、表示を速く、待ち時間を短くするための裏方です。

ホスティング

• Frontend: Vercel または同 VPS の Node プロセス + nginx リバースプロキシ
• API + DB: 既存 VPS (Docker Compose) で開始 → 拡大時に分離
• CDN: 既存 Cloudflare 構成を流用
• Auth: NextAuth (セルフホスト)

技術選定の理由

07データモデル (DB スキーマ)

データをどんな「表」に分けてしまうかの設計です。主要な表は 11 個。先ほどの保管庫 (PostgreSQL) の上に置きます。下のコードは、その表を作るための指示書 (SQL という、データベースへの命令の書き方) です。技術者でなければ、コード自体は読まなくて構いません。各行の右側に付けた日本語コメント (利用者の表、プロンプト本体の表、議論の表…) を拾えば、何をどう保管するかの全体像はつかめます。

-- ユーザーと組織 --
CREATE TABLE users (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  pseudonym     TEXT NOT NULL UNIQUE,           -- 公開名 (仮名 OK)
  email_hash    TEXT NOT NULL UNIQUE,           -- メール SHA-256 (login key)
  display_name  TEXT,                              -- 任意の本名
  org_id        UUID REFERENCES orgs(id),       -- 所属組織 (任意開示)
  coi_text      TEXT,                              -- COI 宣言
  reputation    INTEGER NOT NULL DEFAULT 0,
  role          TEXT NOT NULL DEFAULT 'member', -- member / mod / admin
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  status        TEXT NOT NULL DEFAULT 'active'   -- active / suspended / banned
);

CREATE TABLE orgs (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name          TEXT NOT NULL UNIQUE,
  type          TEXT,                              -- pharma / consulting / academic / regulator
  verified      BOOLEAN NOT NULL DEFAULT FALSE,  -- 組織検証済みか
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- プロンプト本体 --
CREATE TABLE prompts (
  id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  slug                TEXT NOT NULL UNIQUE,
  title               TEXT NOT NULL,
  summary             TEXT,                        -- 1-3 行説明
  current_version_id  UUID,                        -- 最新公開バージョン
  owner_user_id       UUID NOT NULL REFERENCES users(id),
  fork_of_prompt_id   UUID REFERENCES prompts(id), -- フォーク元
  license             TEXT NOT NULL DEFAULT 'CC-BY-4.0',
  status              TEXT NOT NULL DEFAULT 'published', -- draft / published / archived / removed
  view_count          INTEGER NOT NULL DEFAULT 0,
  created_at          TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at          TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_prompts_owner ON prompts(owner_user_id);
CREATE INDEX idx_prompts_status ON prompts(status) WHERE status = 'published';

CREATE TABLE prompt_versions (
  id                   UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_id            UUID NOT NULL REFERENCES prompts(id),
  version_label        TEXT NOT NULL,             -- v1, v2.1, etc.
  content_md           TEXT NOT NULL,             -- プロンプト本文 (Markdown)
  changelog            TEXT,                       -- このバージョンの変更点
  parent_version_id    UUID REFERENCES prompt_versions(id),
  author_user_id       UUID NOT NULL REFERENCES users(id),
  sample_output_md     TEXT,                       -- サンプル出力例
  variables_json       JSONB,                      -- {{VAR_NAME}}の定義
  created_at           TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE(prompt_id, version_label)
);
CREATE INDEX idx_versions_prompt ON prompt_versions(prompt_id);

-- 議論 --
CREATE TABLE discussions (
  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_version_id UUID NOT NULL REFERENCES prompt_versions(id),
  title             TEXT NOT NULL,
  opened_by_user_id UUID NOT NULL REFERENCES users(id),
  status            TEXT NOT NULL DEFAULT 'open', -- open / resolved / locked
  category          TEXT,                          -- compliance / improvement / question / report
  comment_count     INTEGER NOT NULL DEFAULT 0,
  created_at        TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at        TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE comments (
  id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  discussion_id     UUID NOT NULL REFERENCES discussions(id),
  parent_comment_id UUID REFERENCES comments(id), -- スレッド階層
  author_user_id    UUID NOT NULL REFERENCES users(id),
  content_md        TEXT NOT NULL,
  status            TEXT NOT NULL DEFAULT 'visible', -- visible / hidden / removed
  created_at        TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  edited_at         TIMESTAMPTZ
);
CREATE INDEX idx_comments_discussion ON comments(discussion_id);

-- 評価 --
CREATE TABLE votes (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  target_type   TEXT NOT NULL,             -- 'prompt' / 'version' / 'comment'
  target_id     UUID NOT NULL,
  user_id       UUID NOT NULL REFERENCES users(id),
  value         SMALLINT NOT NULL CHECK (value IN (-1, 1)),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE(target_type, target_id, user_id)
);

CREATE TABLE reactions (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  target_type   TEXT NOT NULL,
  target_id     UUID NOT NULL,
  user_id       UUID NOT NULL REFERENCES users(id),
  emoji         TEXT NOT NULL,             -- '👍' '⚠️' '💡' etc.
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE(target_type, target_id, user_id, emoji)
);

CREATE TABLE adoptions (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  prompt_id     UUID NOT NULL REFERENCES prompts(id),
  user_id       UUID NOT NULL REFERENCES users(id),
  status        TEXT NOT NULL,             -- 'in_production' / 'piloting' / 'modified' / 'declined'
  notes         TEXT,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- タグ --
CREATE TABLE tags (
  id      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name    TEXT NOT NULL UNIQUE,
  type    TEXT NOT NULL                   -- 'topic' / 'regulation' / 'material_type' / 'language'
);

CREATE TABLE prompt_tags (
  prompt_id  UUID NOT NULL REFERENCES prompts(id),
  tag_id     UUID NOT NULL REFERENCES tags(id),
  PRIMARY KEY(prompt_id, tag_id)
);

-- モデレーション --
CREATE TABLE moderation_flags (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  target_type     TEXT NOT NULL,           -- 'prompt' / 'version' / 'comment'
  target_id       UUID NOT NULL,
  reporter_user_id UUID REFERENCES users(id), -- NULL なら自動スキャン
  reason_code     TEXT NOT NULL,           -- 'pharma_act_66' / 'jpma_code' / 'spam' / 'other'
  reason_text     TEXT,
  status          TEXT NOT NULL DEFAULT 'open', -- open / dismissed / actioned
  resolved_by_user_id UUID REFERENCES users(id),
  resolution_notes TEXT,
  created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  resolved_at     TIMESTAMPTZ
);

-- 監査ログ (全変更を不可逆記録) --
CREATE TABLE audit_log (
  id          BIGSERIAL PRIMARY KEY,
  actor_user_id UUID REFERENCES users(id),
  action      TEXT NOT NULL,             -- 'create' / 'update' / 'delete' / 'moderate'
  target_type TEXT NOT NULL,
  target_id   UUID NOT NULL,
  payload     JSONB,
  ip_hash     TEXT,
  user_agent  TEXT,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_audit_target ON audit_log(target_type, target_id);

主要な不変条件

• 監査ログは追記専用。削除や更新を許さない (PostgreSQL ロールで物理的に保証)
• Reputation は SUM(votes WHERE target == ユーザーのコンテンツ) から再計算可。冗長化はキャッシュ目的
• prompts.current_version_id は published バージョンのみを指す。draft は別途扱う
• 削除されたコンテンツは status='removed' に変える。物理削除しない (議論履歴の継続性のため)

08API 設計

外部のツールやアプリと、このサービスがやり取りするための窓口を「API」と呼びます。ここでは 2 種類を用意します。1 つは REST という、ごく一般的なやり取りの作法 (「この住所に取りに行けばこのデータが返る」を決めたもの)。もう 1 つは前述の WebSocket で、議論の新着コメントをその場で届けるために使います。窓口の一覧表 (どんな住所で何が取れるか) は、自動で仕様書 (OpenAPI 3.1 という共通フォーマット) として書き出されます。

主要エンドポイント (REST)

プロンプト

バージョン

議論

評価

モデレーション

WebSocket (リアルタイム)

# 接続
wss://prompt-commons.example.com/ws

# 購読 (議論ページを開いたとき)
{
  "type": "subscribe",
  "channel": "discussion:<discussion_id>"
}

# サーバから push される events
{ "type": "comment.created", "data": {...} }
{ "type": "comment.edited",  "data": {...} }
{ "type": "reaction.added", "data": {...} }
{ "type": "version.published", "data": {...} }

認証フロー

1. 新規登録: メールアドレス → OTP 送信 → 仮名 (公開名) を選択 → 完了
2. ログイン: メールアドレス → OTP 送信 → セッション Cookie 発行 (HttpOnly, Secure, SameSite=Lax)
3. API 認証: セッション Cookie (Web) または JWT Bearer (外部ツール)
4. 組織検証: 任意。組織ドメインからのメールで自動検証可。

レート制限

09モデレーション運用

プロンプト・コモンズのモデレーション設計は 「自動 → コミュニティ → モデレータ」 の 3 層 で構成します。明白な違反を機械で弾き、解釈の余地があるものをコミュニティで議論可視化し、最終判断をモデレータが担う構造です。

Layer 1 ── 自動スキャン (投稿時 / 公開前)

新規プロンプトまたはコメント投稿時に、以下を自動チェック。

• 規制違反パターン: 薬機法 §66 (誇大広告)、§68 (承認前広告) の典型表現 (regex + 用語辞書)
• 個別商品名のハードコード: 投稿者に変数化を促す
• 未承認情報の混入: 「未承認」「適応外」キーワードの組合せ
• 個人情報・治験データ漏洩: SSN、メールアドレス、CT.gov ID 等の検出
• スパム / 重複: ハッシュ + Jaccard 類似度で類似コンテンツ検知

違反検知時の挙動:

• 確実な違反 (高信頼度): 投稿を block、ユーザーに理由を提示
• 疑わしい (中信頼度): 投稿を warn + draft 保存。ユーザーが修正 or 公開強行を選べる (強行時はモデレータキューへ)
• 軽微 (低信頼度): 公開しつつ、レビュー対象としてマーク

Layer 2 ── コミュニティフラグ

誰でも、任意のコンテンツに対し POST /flags でフラグを立てられる。フラグ理由:

Layer 3 ── モデレータ判断

モデレータは以下を行える:

• 削除 (status='removed'): コンテンツは表示されないが、議論履歴は残る (URL は 410 Gone を返す)
• 編集: 明白な個人情報や違反語の削除のみ。本旨の改変は不可
• 警告: 投稿者に注意通知
• サスペンド: ユーザーアカウントを期間制限
• BAN: 重大かつ繰り返し違反の場合
• 異議申し立て受付: 投稿者がモデレータ判断に異議申し立て可。別モデレータが再審

モデレータ選出

• 初期: 主催者 (当サイト編集部) が 3 名選出
• Phase 2 以降: Reputation 上位 + 業界経験 (製薬企業/規制当局/学術) の三者バランスで 5-7 名
• 任期: 12 ヶ月。再任可
• 利益相反: モデレータは自身が関わるプロンプトのモデレーション判断不可

10ガバナンスとライセンス

ライセンス

プロンプトのデフォルトライセンスは CC BY 4.0 (帰属表示で自由利用可)。投稿者は CC0 (パブリックドメイン) も選択可。商用利用は両方で可能。これは「業界共有財産」というコンセプトと整合します。

運営主体

初期は 当サイト が運営 (このサイトの編集部)。Phase 2 以降、業界横断の運営委員会へ移行を検討:

• 製薬企業から 3 名 (企業規模ミックス)
• 規制当局/関係機関から 1 名 (PMDA 等のオブザーバ的立場)
• 学術から 1 名
• 運営事務局から 2 名

COI ポリシー

• ユーザープロフィールに COI 宣言欄を設置 (任意記入)
• プロンプト投稿時、特定商品の宣伝目的がある場合は明示必須
• モデレータは自身関連コンテンツへの介入禁止

個人情報・データ保護

• 本名は任意。仮名運用が標準
• メールアドレスは内部のみ (SHA-256 ハッシュで照合)
• GDPR / 個人情報保護法準拠
• 削除要求 (GDPR Art. 17): ユーザーは自身のアカウントとコンテンツの削除要求可

11フェーズ別実装計画

段階的に立ち上げ、各段階で実利用フィードバックを取り込む。

12リスクと対応

13成功指標とコスト

成功指標 (Phase 別)

開発・運用コスト見積

初期判断のチェックポイント

Phase 0 終了時点 (1 ヶ月後) に、以下を判定:

• シードコンテンツ 10 件に対し、議論コメントが計 30 件以上ついたか
• 3 社以上から「採用検討」の声があるか
• 規制当局/業界団体から否定的反応がないか

これらが満たされなければ Phase 1 を見送り、コンセプトの再設計か撤退を判断。「作ること」より「作る価値があるかを確かめること」 を Phase 0 のゴールにします。