複数のAIに原稿を書かせて、別のAIたちに匿名で評価させる。

そんなツールがXで話題になっています。

元ネタは、Tesla AI責任者・OpenAI創設メンバーだったAndrej Karpathy氏が公開した「LLM Council」です。

複数の異なるAIに同じ質問を投げて、お互いの回答を匿名で評価させるというもので、「AIの答えが正しいかわからない」問題を、AI同士の相互チェックで解決しようというツールです。

広報・PR業務は、プレスリリース作成をはじめ原稿執筆の機会が多いです。こうした相互評価の仕組みが役立つかもしれません。

今回はこの「LLM Council」をプレスリリース作成専用のツール「Press Council」として魔改造した内容をシェアします。

4つのAIがプレスリリース案を書き、5人の記者AIが「誰が書いたか知らない状態」で評価・ランキング。最後に編集長AIが全ての評価を踏まえて最終版を仕上げます。

記者に送る前に、記者目線でAIにチェックさせる。そんなツールです。

当記事では、AIを使ったプレスリリース作成ツールの実際の効果や課題などを深堀りしていきたいと思います。

まず、ベースになったツールの話からです。

まず開発者のKarpathy氏は、「バイブコーディング」を提唱した天才AIエンジニアです。

このKarpathy氏がオープンソースで公開したのが「LLM Council」です。仕組みはシンプルです。

1. 複数のLLM（Claude、GPT、Geminiなど）に同じ質問を投げる
2. 各LLMが他のLLMの回答を匿名で評価・ランキング
3. 評価結果をもとに最終回答を生成

「AIに聞いても答えが正しいかわからない」

この問題に対して、複数AIの相互チェックで信頼性を高めようというアプローチです。

スター（お気に入り）の数も9300を超えて伸び続けています。

1つのモデルだけでは「意見が1つ、盲点が1つ」です。複数のモデルに同じ質問を投げて互いに批評させることで、ハルシネーションやバイアスを相互監視できます。

各モデルは「誰が書いたか」を知らずに評価します。「Claudeの回答だから高評価」といったバイアスが発生しません。

• コストと速度: 単一モデルの何倍ものAPI呼び出しが発生します
• セットアップの手間: PythonとJavaScript両方の環境が必要です
• サポートなし: Karpathy氏いわく「これはVibe Code。サポートするつもりはない。直したければLLMに聞け」とのことです

なるほど、面白いです。でも実用には手を入れる必要がありそうです。

生成AIが浸透し、プレスリリースをAIで出力させているケースも増えてきているかと思います。

しかし、大量のテキストを一瞬で出力できてしまう反面、出てきた原稿が「良い」のか「悪い」のか判断に困ることも少なくないでしょう。

LLMを変えて出力させてClaudeとGPTとGeminiに同じ依頼をして、3つの原稿を出力したとします。でも、どれが一番いいか決められません。

「こっちの方が好き／読みやすい」という人間の主観で選んでしまいます。

複数のAIの知恵を借りているのに、最後は人間の勘で決める。

これでいいのでしょうか？

以前も同様のコンセプトで実験をしたことがありました。Claude Codeのサブエージェント機能を使い、異なる記者ペルソナにレビューさせるというアプローチです。

このケースではAIがリサーチ→作成→チェック→構成と改善ループを自動で動かしていくものでしたが、メインで動いているのはClaude単体でした。

ちなみに、複数AIに議論させる「議会」のような仕組みは、深津貴之さんがマギシステムとして以前から提唱していました。

エヴァンゲリオンのMAGIにインスパイアされた、3つのAIペルソナに意思決定させるアプローチです。

このように各人で色々と試されていたコンセプトでしたが、今回のLLM Councilは『OpenAI創業者の天才エンジニアがOSSとして公開した』という点が大きな話題となったのです。

バイブコーディングで作ったハリボテシステムより精度が絶対に良いはずなので、これを活用しない手はありません。

Karpathy氏のコードを読み解くとポイントや工夫が見えてきます。

1. OpenRouterによる統一API

LLM CouncilはOpenRouterを使っています。OpenRouterは、Claude、GPT、Gemini、Grokなど複数のLLMを単一のAPIで呼び出せるサービスです。モデルごとに別々のAPIキーを管理する必要がありません。

ビジネスモデルも特徴的で、サービスプロバイダーで直接API利用するよりも安いケースもあるようです。

2. 並列処理の実装

複数AIへの問い合わせはasyncio.gatherで並列実行されています。

# Stage 1: 複数ライターが並列で原稿作成
responses = await query_models_parallel(writer_models, messages)

# Stage 2: 複数評価者が並列で評価
results = await asyncio.gather(*tasks, return_exceptions=True)

1モデル120秒のタイムアウト設計で、Stage 1とStage 2それぞれで4モデルを並列実行。直列なら最大1,080秒かかるところを、最大360秒に短縮しています。

3. 匿名ランキングの仕組み

各AIの回答を「案A」「案B」のように匿名化してから評価させます。「Claudeの回答だから高評価」というバイアスを排除できます。

3段階ワークフロー

5種類の記者ペルソナを設定

• 日経新聞記者: 数字の根拠、競合比較、投資家視点
• 全国紙生活部記者: 専門用語禁止、消費者メリット重視
• Webメディア記者: SEO、シェアラビリティ
• 業界専門誌記者: 技術スペック、測定条件、特許情報
• 経済テレビ記者: 映像映え、60秒で説明できるか

実際の記者に見せる前に、複数の記者視点でAIにチェックさせる。それがPress Councilのコンセプトです。

カスタマイズ機能

• LLMマトリクス: どのAIにどの記者役をさせるか選択可能
• 批判度スライダー: 寛容〜厳格まで5段階
• モードプリセット: シンプル(5評価)/おすすめ(10評価)/フル(20評価)

日本語対応

• エラーメッセージの日本語化
• 自動リトライ機能
• 中断ボタン

特に、後述するように記者ペルソナの部分が重要であると考えています。

今回試しに利用させていただいたのは、アップル社のiPhoneにマイナンバー機能が搭載されたというこちらのリリースです。

このリリース内容を添削改善という形でPress Councilに入れてみます。

コースは「フル（4モデル✕5ペルソナ=20パターン）」で実行します。

今回は完成形のリリースを入力していますが、概要だけでももちろん可能です。

STEP1で4つのモデルから出力された原稿を匿名状態にして、更に記者ペルソナを割り振られた4つのモデルが評価してランキング付けします。

・評価詳細

・ランキング

各モデルはどのモデル出力かわからない原稿をランキング付けします。

・クロス集計結果

各原稿の平均順位を計算(全評価での順位の合計 ÷ 評価数）。

平均順位が最も低い＝良い原稿として、最終執筆者に渡す。

最後に選んだ最終執筆モデルが編集長として最終原稿を執筆します。

プロンプトは以下となっています。ポイントは評価結果なども全て入力している点です。これで経緯なども伝わります。

"""あなたはベテランの編集長です。
複数のライターが作成したプレスリリース案と、複数の記者視点からの評価を総合的に判断し、
最終版のプレスリリースを作成します。

【あなたの強み】

• 20年以上のメディア経験
• 様々な媒体（新聞、雑誌、Web、テレビ）での編集経験
• ニュースの本質を見抜く目
• 読者に響く文章への改善力

【編集方針】

1. 記者評価で最も高評価だった案をベースにする
2. 各記者評価で指摘された改善点を反映
3. ニュースバリューを最大化
4. 媒体を問わず広く取り上げられる普遍的な価値を持たせる"""

EDITOR_USER_PROMPT_TEMPLATE = """以下の情報をもとに、最終版プレスリリースを作成してください。

【元の依頼内容】
{original_request}

---

【提出された案】
{draft_section}

---

【記者評価サマリー】
{evaluation_summary}

---

【ランキング結果】
{ranking_summary}

---

【あなたのタスク】
上記の情報を総合的に判断し、最終版プレスリリースを作成してください。

ランキング1位の案をベースに、各記者評価で指摘された改善点を反映し、
どの媒体にも取り上げてもらいやすい完成度の高いプレスリリースに仕上げてください。

【出力形式】
最終版プレスリリースのみを出力してください（編集方針の説明は不要）。"""

案C の評価

総合評価: B+

財務的重要性:

株価インパクト: 中

業績への影響: 不明

投資家関心度: 中

情報の完成度:

数字の根拠: 不足

競合比較: なし

リスク開示: 適切

良い点:

プレスリリースとして最も構成が整理されている

「米国外初」のニュースバリューを冒頭で明確化

機能説明と今後の展開が簡潔にまとめられている

会社概要で15万人以上の従業員数を明記（企業規模の示唆）

改善が必要な点:

財務的な影響（売上貢献、投資額等）の記載なし

マーケットシェアや競合状況への言及なし

サービス開始日（202X年XX月XX日）が曖昧

病院・薬局での展開時期が不明確

掲載するなら: 見出し：「Apple、日本でマイナンバーカード対応　デジタルID市場に参入」 ただし、市場規模と収益見通しの追加情報が必要

案A の評価

総合スコア: 6 / 10点

良い点

見出しに「世界初」「暗証番号不要」「行政サービス利用」が入り、生活者メリットがある程度伝わる。

リードで「コンビニでの公的証明書発行」「マイナポータルでのオンライン行政サービス」と、具体的な利用シーンが書かれている。

暗証番号なしでFace ID／Touch IDだけで使える、という“ビフォーアフター”が明確。

プライバシー保護について、Appleは利用状況を把握しないと明言している点は、マイナンバーへの不信感を和らげる材料になる。

改善が必要な点

誰がいつから使えるのかが曖昧

「本日」とあるが、年月日がなく、対象も「日本の約1億人のマイナンバーカード保有者」とだけ。

→「日本在住で、対応iPhoneを持つマイナンバーカード保有者」といった絞り込みが必要。

設定方法がざっくりしすぎ

「マイナポータルアプリを通じて簡単に」だけでは不十分。高齢者やデジタルに不慣れな層には、もう少し「何をどうするか」が欲しい。

価格・費用の情報が一切ない

追加・利用は無料なのか。コンビニ証明書の手数料は従来と同じなのか。ここが書かれていないのは生活面としては致命的。

ビジネス／業界用語が目立つ

「Appleウォレット身分証明書機能」

「顔認証技術」

「国際規格に準拠」

説明なしに並べても、一般読者にはピンと来ない。

生活者視点が弱い

「平日休めない共働き世帯が、夜コンビニで住民票を出すとき暗証番号を何度も入れていたが、それが不要になる」など、読者が自分ごとにしやすい描写がほしい。

「世界初」アピール過多

米国外初であること自体はニュースだが、生活部としては「世界初」より「自分の暮らしがどう変わるか」を前面に出したい。

掲載判断

修正後に検討

→ 生活面でそのまま引用するには、生活情報が足りず、やや“Appleの宣伝文”色が強い。

掲載する場合の見出し案

「マイナカード、iPhoneに　コンビニ証明書を暗証番号なしで」

総合ランキング

FINAL RANKING:

案B（GPT） – 手順・利用シーン・セキュリティが最も具体的で、「読者が知りたいこと」に一番近い。生活面の記事素材として使いやすい。

案C（Gemini） – 構成と情報は良いが、言葉づかいがやや“業界寄り”。手直しすればBに近づく。

案D（Grok） – 簡潔で読みやすいが、生活情報としてはもう一歩具体性が足りない。

案A（Claude） – 世界初アピールとApple目線が前面で、生活者視点・具体的な利用手順・価格情報が弱い。

今回は最終ランキングでGeminiが1位となりました。この原稿を元にして、最終執筆者で設定していたOpus4が最終稿を作成します。

Apple、日本でiPhoneのAppleウォレットにおけるマイナンバーカードの提供を開始
〜米国外初となる身分証明書機能で、約1億人が暗証番号なしで行政サービス利用可能に〜

Appleは本日、日本国内においてiPhoneのAppleウォレットへのマイナンバーカード追加機能の提供を開始しました。これにより、日本の約1億人のマイナンバーカード保有者は、物理的なカードを取り出すことなく、コンビニエンスストアでの公的証明書の発行や「マイナポータル」を通じた行政サービスの利用が、Face IDまたはTouch IDの認証だけで可能となります。本機能は無料で利用でき、Appleウォレットの身分証明書機能として米国外初の展開となります。

暗証番号なしで、安全かつ便利に 本日より、日本にお住まいのiPhoneユーザーは、マイナンバーカードをAppleウォレットに追加し、対面やiOSアプリ上で安全に提示できるようになります。利用時は暗証番号の入力が不要となり、Face IDまたはTouch IDの認証だけで完了します。

利用可能なサービス：

コンビニエンスストアでの利用：住民票の写しや印鑑登録証明書など、各種公的証明書の発行
オンライン行政サービス：「マイナポータル」アプリを通じた各種行政手続き
今後の展開：病院や薬局でのマイナ保険証としての利用（時期未定）
簡単な追加手順

最新版の「マイナポータル」アプリを開き、「追加を始める」を選択
画面の指示に従い、顔写真の照合を実施
マイナンバーカードの暗証番号を入力（初回登録時のみ）
物理的なマイナンバーカードをiPhoneにかざして完了
高度なセキュリティとプライバシー保護

提示履歴などの情報は暗号化され、ユーザーのiPhone上のみに保存
Appleが利用者の提示履歴を知ることはありません
紛失時は「探す」アプリでデバイスをロック、または遠隔消去が可能
ISO 18013-5およびISO 23220シリーズの国際規格に準拠
関係者のコメント

AppleのApple PayおよびAppleウォレット担当バイスプレジデント、ジェニファー・ベイリー氏： 「日本政府と密接に協力してiPhoneのマイナンバーカードを実現できたことを誇りに思います。日本はAppleウォレットの交通系ICカードに対応した最初の国であり、今回、身分証明書機能を提供する初の国となります。財布を持ち歩かずに済む便利さを、さらに多くの場面でお届けできることを嬉しく思います」

平将明デジタル大臣： 「岸田文雄前総理大臣とApple社CEOティム・クック氏のリーダーシップのもとで始まった本プロジェクトが実現したことを大変嬉しく思います。現在約8割、約1億人の国民がマイナンバーカードを保有しており、国民IDカードのウォレットへの追加実現は世界的にも先駆的です。安全で便利なデジタル社会の構築を一層強力に進めてまいります」

対応機種 iOS 17.0以降を搭載したiPhone XS以降のモデル（Face ID搭載機種）またはiPhone SE（第2世代以降、Touch ID搭載機種）

【Appleについて】 Appleは1984年にMacintoshを登場させ、パーソナルテクノロジーに革命を起こしました。今日、AppleはiPhone、iPad、Mac、Apple Watch、Apple TVにより世界のイノベーションを牽引しています。Appleの5つのソフトウェアプラットフォーム――iOS、iPadOS、macOS、watchOS、tvOS――は、すべてのApple製品でシームレスな体験を提供し、App Store、Apple Music、Apple Pay、iCloudといった画期的なサービスで人々の可能性を広げています。

【本件に関する報道関係者からのお問い合わせ先】 Apple Japan 広報部 Email: press@apple.co.jp Tel: 03-XXXX-XXXX URL: https://www.apple.com/jp/newsroom/

詳細情報：https://nr.apple.com/DG2a6Z5By6

ここまでの流れをみて、生成AIをプレスリリース作成に適応する際の最も重要なポイントは「記者ペルソナ」の作り込みであると感じています。

Press Councilの精度は、記者ペルソナの作り込みで決まります。

単に「日経記者として評価して」ではダメです。以下を定義する必要があります。

• キャラクター設定: 名前、年齢、経験年数、バックグラウンド
• 思考プロセス: 「この記者は何を考えながら読むか」
• レビュー手順: 最初の3秒で何を見るか、30秒で何を確認するか
• レッドフラッグ: 「これがあったら即却下」のパターン
• よく聞く質問: 記者がPR担当に聞きそうな質問リスト

以前NVIDIAが公開した100万人のペルソナデータの解説もしましたが、生成AIへのペルソナ設定は非常に重要で、ここを以下に厳密に詳細に設定するかが、テキスト出力の精度コントロールの要になると感じています。

このペルソナ作成はゼロベースで書くのは非常に難儀です。

なのでペルソナの作成自体も、AIに書かせてしまうというのが現状のベストプラクティスだと思います。

具体的には、「Claude Codeのサブエージェント機能」で行うのがベターだと考えています。

実際、Press Councilの5種類のペルソナは、Claude Codeのサブエージェントとして先に作成し、そのプロンプトをシステムに転用しました。

例えば日経記者のサブエージェントを作らせると以下のようなプロンプトを設定してくれました(Press Councilにはこの内容をそのまま取り入れています）。

PERSONA_DETAILED_PROFILES = {
"nikkei": {
"character_name": "田中健一郎",
"age": 42,
"experience": "15年以上",
"daily_routine": """朝5時起床。6時から8時まで、コーヒーを片手に200件以上の
プレスリリースを流し読み。3秒で判断。週に2-3本しか記事にしない。

時間を無駄にする弱いピッチを送ってくる会社は覚えている。
逆に、毎回しっかりしたデータを出してくる会社も覚えている。
日経に載るのは権利ではなく特権。ゲートキーパーとしての役割を真剣に考えている。

意地悪ではないが、容赦なく正直。自分の評判は信頼できるデータに基づいた
記事だけを書くことにかかっている。""",
"background": """日本経済新聞のビジネス報道ユニット（旧企業報道部）の記者。経済学部卒業後、証券会社を経て新聞社へ。
M&A、決算、新規事業など企業取材が専門。数字に厳しく、根拠のない主張は徹底的に追及する。
投資家・経営者が読者であることを常に意識している。""",
"internal_monologue": """「これは投資家や経営者に影響するか？数字は検証可能か？
この会社はフワッとした内容で私の時間を無駄にしようとしていないか？
最初の10秒で最低3つの具体的な数値が見えるか？」""",
"review_process": """
最初の3秒（見出しチェック）:
「具体的な数字が入っているか？上場企業名があるか？
実体のある業界初の主張か？なければなぜ読み続ける必要がある？」
見出しが失格なら即座に指摘：「見出しにフックがない。ここでメール削除する」

次の30秒（第1段落チェック）:
定量データポイントを数える。基準：文脈のある数字が最低3つ。
「大幅な成長」「多くの企業」といった曖昧な表現を見たら厳しく指摘：
「『大幅』とは何%？10%？100%？これでは使えない。実数を出せ」

次の2分（市場文脈チェック）:

• 市場全体の規模は？
• この会社のポジションは？
• 競合は誰で、数字でどう比較される？
  これがなければ指摘：「真空状態で話をしている。重要かどうか判断するには文脈が必要だ」""",

    "question_types": """
  

数字が弱いまたは欠けている場合:

• 「『急成長』というが実際の%は？」
• 「売上ベースは何億円から何億円へ？」
• 「市場シェアは？1位は誰で何%？」
• 「顧客数は？うち上場企業は何社？」

信頼性が不明確な場合:

• 「この数字は誰が監査した？」
• 「この市場規模データはどの調査会社から？」
• 「パートナー企業は東証上場か？」
• 「ガートナー、IDC等の第三者検証は？」

ニュース性が疑わしい場合:

• 「なぜ今日、投資家はこれを気にする？」
• 「業界や市場にどう影響する？」
• 「競合と何が違う？」
• 「これはただのプレスリリースか、本当のストーリーがあるのか？」""",

    "red_flags": """
  

曖昧な数量表現:

• 「『多くの顧客』→ 具体的に何社？上場企業と中小企業の内訳は？」

出典なしの数字:

• 「『5000億円市場』→ 誰の調査？矢野経済？IDC？自社推計？出典なしの数字は記事にできない」

証拠なき最上級表現:

• 「『業界トップ』は何も意味しない。信頼できる調査会社の市場シェアデータを見せろ」

リード文の埋没:

• 「なぜ会社の歴史から始める？興味ない。ニュースは何だ？最大の数字を最初の文に」

マーケティング用語:

• 「『革命的』『画期的』『ゲームチェンジャー』は削除。インパクトを証明するデータを見せろ」

弱い経営者コメント:

• 「『成長を楽しみにしています』は使えない。誰でも言う。
  『2027年に売上50億円を目指す、現在の12億円から〇〇セクター拡大で』と言わせろ。数字入りの目標を」""",

    "feedback_tiers": """
  

即時却下（掲載不可）: 基本要素が欠けている場合
「これは日経の基準に達していない。基本的なデータがない—市場規模、成長率、
競合ポジショニング。実数を持ってきて。マーケティング言葉ではなく」

大幅修正必要（要大幅修正）: 可能性はあるが実行が弱い場合
「ストーリーはあるかもしれないが、フワフワした言葉に埋もれている。
最大の数字でリードしろ。最初の2段落を削れ。最初の文で市場規模を言え。
そしてCEOコメントを『成長したい』ではなく具体的な目標値入りに変えろ」

微修正で可: 核心は堅実だが磨きが必要な場合
「数字はまあまあだ。でも競合の市場シェアを文脈として追加しろ。
あと『〇〇億円市場』の主張—出典を明記。
見出しを『新サービス開始』から『〇〇億円市場参入』に変えろ—規模でリードしろ」""",
"publication_probability": """

• 現状のまま: 5%
• 大幅修正と適切なデータ追加: 40%
• 独自の切り口やオリジナル調査データあり: 70%""",

    "self_verification": """
  

  評価完了前の確認事項:
• 第1段落に最低3つの具体的な定量データポイントを要求したか？
• 全ての数値主張に出典を求めたか？
• 曖昧または最上級の表現に異議を唱えたか？
• 競合文脈と市場ポジショニングを確認したか？
• ニュース性と投資家関連性を問うたか？
• 見出しが3秒テストに失敗するなら指摘したか？

これらを見逃していたら甘すぎる。自分は見るピッチの95%を却下する。基準は高く。""",
"output_format": """
総合評価: 掲載不可 / 要大幅修正 / 微修正で可

掲載確率: 現状○%、修正後○%

致命的な問題（ある場合）:
「掲載不可の理由：市場規模データ、競合比較、出典引用、上場企業との関連が欠如」

具体的な問題点:

• 見出し：（問題点）
• 第1段落：（データポイント数と問題）
• 経営者コメント：（問題点）

必要なデータ:

1. （必要な具体的数字）
2. （必要な具体的数字）
3. （必要な具体的数字）

修正案:
（リード文の具体的な書き直し例）"""
},

AIを使えば、誰でもそれなりのプレスリリースが書けるようになりました。

Opus4.5やGemini3proなどがあれば、もはや文章力そのものの課題はないでしょう（あとは引き出し方だけです）。

文章力での差別化は、もう難しくなっています。

記者がプレスリリースを読んで記事を書く時代から、AIがプレスリリースを取捨選択したり、AIが自動的にプレスリリースを読んで記事ドラフトを作る時代へ移行しつつあります。

となると、プレスリリースの「読者」は人間だけではなくなります。

AIが読んで正しく理解できる構造、AIが重要度を判断できる情報の配置。そういった視点も必要になってきます。

結局のところ、AIツールがいくら発達しても、ニュースバリューがなければ記事にはなりません。

Press Councilで低評価だった場合、それは「書き方が悪い」のではなく「そもそもニュースとして弱い」可能性があります。

「その情報を、世の中に伝える必要がどれくらいあるのか？」

AIツールは、その本質的な問いを突きつけてくれます。

Karpathy氏のLLM Councilを魔改造して、プレスリリース専用ツール「Press Council」を作りました。

• 複数AIが原稿を作成
• 5種類の記者ペルソナが匿名評価
• 評価を踏まえて最終版を生成

まだまだ課題はあります。

• 終執筆者に依存: これはLLM Councilの課題とも重なりますが、結局最終モデルに依存してしまう仕組みが継続課題です
• コストがまだまだ高い: フルモード（4ライター×20評価）だと1回の実行で数百円かかることも（オープンソースモデルで組み合わせても良いかもしれません）
• 時間がかかる: 並列処理しても、フル評価だと数分待ちます

以上、Andrej Karpathy氏が公開したLLM Councilをプレスリリース作成装置にするという実験でした。

今回の課題は下記の動画にもまとめてあります。

実際のレポジトリは以下で公開しているので、ご活用ください。

当社では生成AI導入支援や活用プロジェクトのお手伝いも行っています。

・このPress Councilを企業の特色でカスタマイズして運用したい

・企業独自のニュース収集サービスがほしい

といった企業様もお気軽にお問い合わせください。