将来的に広聴AIを紹介する論文が世の中にあるとよい、という問題意識は妥当である。特に kouchou-ai は、単なる OSS 実装としてだけでなく、日本語圏のブロードリスニング実践、自治体・政党文脈、LLM と可視化を組み合わせた運用知 を持っているため、論文を書く過程そのものが設計判断の棚卸しになる。role-model-papers-polis-birdwatchより
Polis / vTaiwan 系のロールモデルは 制度接続と運用プロセスの記述 を、Birdwatch / Community Notes 系のロールモデルは 評価軸と限界分析 を強く持つ。したがって広聴AIの論文下書きページも、単なる宣伝文ではなく、何を新規知見として主張するか を先に固定する必要がある。role-model-papers-polis-birdwatchより
この wiki で作るべきページ
最初から論文本文を 1 枚で書くより、まず次の 3 層に分けた方が学びが出やすい。
- 論文戦略ページ 本ページ。ターゲット読者、主張、投稿言語、候補 venue、必要データ、未解決論点を整理する
- 論文下書きページ
wiki/analyses/配下に別ページを置き、Abstract / Problem / Method / Case / Evaluation / Limitationsの見出しで本文を育てる - 根拠ページ
個別事例、評価軸、関連研究、図表候補を
sources/やanalyses/に分解して蓄積する
この構成にすると、論文本文がまだ粗くても、周辺の論点整理がそのまま wiki 資産になる。
まず固定したい論文タイプ
広聴AIの初回論文は、欲張って全部入れるより、次のどれを主軸にするかを決めた方がよい。
1. システム紹介＋事例研究
最も書きやすい。日本の自治体・政党・市民参加文脈で、広聴AIがどのような入力、抽出、クラスタリング、可視化、共有を提供したかを書く。Polis 系のロールモデルに近い。role-model-papers-polis-birdwatchより
2. 効果検証
より学術的だが、評価設計が要る。広聴AI利用前後で、理解速度、論点把握、運営工数、参加者間の認識差の可視化などがどう変わるかを測る。Birdwatch 系に近い。role-model-papers-polis-birdwatchより
3. 設計判断の反省知
OSS と実運用を通して得た失敗と tradeoff を整理する。たとえば scatter plot の扱い、静的 HTML 配布、LocalLLM、plugin system、Web UI と CLI の二重性などである。既存 wiki の資産と接続しやすい。open-decisionsより
現時点では、初回は 1 を主軸にし、2 と 3 を副次的に入れる のが最も現実的に見える。理由は、効果検証だけで押すには評価データ設計がまだ重く、設計判断だけで押すには外部読者に伝わる problem setting が弱くなりやすいからである。
日本語で先に書くか、英語で投稿するか
結論から言うと、学びを得るための草稿は日本語で進めつつ、最終的な主要成果物は英語投稿を第一候補にする のがよい。
日本語先行の利点
- 実務者のニュアンス、運用上の痛み、自治体文脈を素早く書ける
- コアメンバー間でレビューしやすい
- まだ主張が固まっていない段階でも進めやすい
- wiki への filing-back と相性がよい
日本語先行の弱み
- そのまま日本国内発表で止まると、Polis 論文や Birdwatch 論文のような 国際的な参照点 になりにくい
- 後から英訳すると、文章は移せても argument structure が英語論文向けに最適化されていないことが多い
- 無償英訳公開は outreach には効くが、査読付き英語論文と同じ discoverability にはならない
英語投稿の利点
- 広聴AIを国際的な議論に接続しやすい
- 日本語圏特有の実践知を、比較可能な case study として提示できる
- 将来の引用、共同研究、OSS 利用者獲得に効きやすい
英語投稿の弱み
- 初期の草稿作成コストが高い
- 日本の現場文脈を英語読者向けに再構成する負荷がある
- 内輪レビューの速度が落ちやすい
推奨方針
推奨は 「日本語草稿ファースト、ただし英語投稿を捨てない構造で書く」 である。
具体的には次の進め方がよい。
- wiki 上では日本語で論点整理と本文下書きを進める
- ただし最初から
Title / 1-paragraph abstract / contribution bullets / figure list / related work listは英語でも併記する - 図表、用語、節構成、主張の単位は英語論文へそのまま持ち込める粒度で固定する
- 日本国内発表をする場合も、それを最終形ではなく 英語投稿前の中間マイルストーン とみなす
この方針なら、日本語で思考速度を保ちつつ、後で「国内向け記事の英訳」に矮小化されるのを防げる。
下書きページに最初から入れるべき見出し
論文下書きページは、少なくとも次の見出しで始めるのがよい。
Abstract
何の問題を、誰に向けて、何で解いたか。ここは早い段階で英語版も併記したい。
Problem Setting
日本の自治体・政党・市民参加で、自由記述が増える一方、人手で読めないという課題をどう置くか。
System / Process
広聴AIの処理系だけでなく、誰がどう使うのか、Web UI と CLI の違い、共有経路、限定公開なども書く。kouchou-aiより
Case Studies
代表事例を 1 つか 2 つ。Polis の UberX 事例のように、本文の背骨になる実例が必要。role-model-papers-polis-birdwatchより
Evaluation
定量でも定性でもよいが、何が改善したと言うのかを置く。Birdwatch 系のように、改善しなかった点も含めて評価軸を立てる。role-model-papers-polis-birdwatchより
Limitations
クラスタリングの限界、散布図依存の問題、運営体制、データ公開制約、評価の弱さなど。
Open Questions
論文化に必要だが未整備のデータ、倫理、比較対象、投稿先。
今すぐ作るとよい次のページ
本ページの次に作る価値が高いのは次の 2 ページである。
kouchou-ai-paper-draft-ja.md日本語の本文下書き。章立てを先に作り、空でもよいので節を置くkouchou-ai-paper-evidence-map.mdどの主張をどの source / code / case / figure で支えるかの対応表
後者があると、感想文ではなく論文に必要な evidence gap が見えやすい。
現時点では 1 本目として kouchou-ai-paper-draft-ja、2 本目として kouchou-ai-paper-evidence-map を作成済みであり、以後は本文と証拠対応表を往復しながら育てる。
Open Questions
- 初回論文の主軸は、システム紹介、事例研究、効果検証、設計判断のどれか
- 日本国内発表を先に行う場合、その venue を最終目標ではなく英語投稿前の試走として扱えるか
- 実例として公表可能な事例データをどこまで確保できるか
- 英語投稿先として HCI / CSCW / civic tech / digital democracy のどこを狙うか
Updates
- 2026-05-19: 初回作成