ドキュメント
JapanTracker の現在の設計思想と運営方針を、テーマごとに公開しています。
日付付きの検討ログは、なぜその判断に至ったかを残す履歴です。現在の方針を確認するときは、この配下の正規ドキュメントを参照してください。新しい論点が決まったときは、対応するページを更新します。
- 設計と運営の原則 このページは、JapanTracker の現在の方針を読むための入口です。詳細はテーマごとの文書に分け、ここには全体を通底する原則だけを置きます。 事実と、その作られ方を残すJapanTracker は、政治や社会についての事実を出典とともに蓄積します。同時に、そのデータをどのAIが、どの条件で、どのように調べて作ったかも残します。 評価や結論を正解として提供しないJapanTracker 自身の政治的評価や結論を、事実であるかのように提供しません。「中立です」とも名乗りません。代わりに、利用者が出典と生成過程を確認し、自分で評価できる状態をつくります。 人間の全件監査を前提にしない人間が一件ずつ読んで正しさを保証する仕組みにはしません。選題、収集、執筆、検証、監査をAIへ大きく移し、その条件と結果を公開して外部から検証可能にします。 データと問いを両方つくるrecord や statistics を置くだけでなく、そこから社会で考える価値のある 問い を作ります。問いは結論を誘導するためではなく、抜けている視点を増やし、必要なら社会の認知を事実に照らして較正するための入口です。 選題と配信を分ける伸びそうな 問い だけを選びません。一方で、採択した問いはできるだけ多くの人へ届くように配信します。リーチを最大化することと、リーチだけで選題することは別です。 現在の方針を確認するときの入口。各詳細文書への案内と、全体を通底する原則。
- 目指していること JapanTracker は、日本の政治と社会について、あとから確かめられる事実の基盤をつくり、そこから考える価値のある問いを社会へ届けます。 事実を、あとからたどれる形で残す何が起きて、誰が何を言い、何をしたのか。日々流れていく情報を、record、case、statistics、mediaCoverage などのデータとして、出典と日付を添えて残します。 人が直接読むためだけではなく、AIが検索し、比較し、事実確認に使える情報基盤になることも目指します。 結論ではなく、問いを届けるデータを置くだけでは、すでに調べたいと思っている人にしか届きません。JapanTracker は、蓄積した事実と社会で起きている議論から 問い を作り、SNSなどを通じて人へ届けます。 何が良い社会か、何が良い政治かを JapanTracker が決めるのではなく、抜けている視点、必要な比較、認知と事実のずれを考える入口となる問いを増やします。 一人を深くするだけでなく、広く少し深くする全員に長いデータを読ませることは目標にしません。投稿を見た人が、知らなかった事実を一つ知る、持っていなかった問いを一つ持つ、昨日より少しだけ考えが深まる。それが広く積み重なることにも価値があると考えます。 JapanTracker が何を目指し、社会にどのような役割を持とうとしているか。
- 全体構造 JapanTracker は、事実を蓄積する下部構造と、人が気づき、考え、議論し、追うための上層を組み合わせたものとして設計します。 Truth infrastructurerecords、cases、people / organizations、mediaCoverage、statistics、unresolved、audit / provenance などを、出典付き・機械可読・検証可能な形で蓄積します。 ここでは深さ、再利用性、履歴、出典、検証可能性を重視します。人間がすべてを直接読む必要はなく、AIが参照・検索・比較しやすいことも重要です。 Social interface下層のデータから 問い を作り、SNSなどを通じて人へ届けます。必要に応じて Follow を使い、単発の話題を継続して追える状態も作ります。 目的は、全員にデータベースを熟読させることではありません。知らなかった事実を一つ知る、持っていなかった問いを一つ持つ、少し考えが深まる、といった小さな認知変化を広く起こすことです。 下層は深さ、上層は到達を重視するtruth infrastructure は、必要なときに深く掘れることを重視します。social interface は、その深いデータを全員に読ませるのではなく、問いや最低限の事実に圧縮し、広く届けます。 truth infrastructure と social interface、複数のデータ要素とフィードバックループ。
- 約束すること 記録を扱う以上、どう扱うかを先に決めて公開しておくべきだと考えています。JapanTracker が守ると決めていることを、ここに約束します。 1. 出典を必ず付けるすべての記録に、出典（媒体名・URL・日付）を必ず添えます。出典を示せない主張は、どれだけもっともらしくても載せません。どの記述からも、その根拠として参照した資料までたどれる状態を保ちます。可能な場合は、原資料や当事者による公表などの一次情報も示します。 2. 切り取らない発言や経緯は、意味が変わらない範囲で文脈ごと記録します。ある立場に不利な事実だけを集めたり、反対の事実を知りながら省いたりしません。事実関係に争いのあるものは、争いがあること自体を書きます。 3. 評価や結論は書かないこのサイトは、何が正しいかを決める場所ではありません。「誰が・いつ・何をしたか」を書き、それが良いことか悪いことかは書きません。断定的な形容や、読み手を特定の結論へ誘導する書き方をしません。解釈は読み手に委ねます。 4. 誤りは直し、直した記録も残す誤りが確認できた場合は直します。記録を静かに書き換えて、なかったことにはしません。 5. 私人の実名は載せない事件の被害者、生徒、遺族など、公的な立場によってではなく、経緯に巻き込まれたことで報道された人の実名は載せません。報道が実名で報じていることは、ここに載せてよい理由になりません。 出典、記述、私人、資金提供など、公開上の基本的な約束。
- データの考え方 JapanTracker は、一つの巨大な記事ではなく、複数の種類のデータを組み合わせて政治と社会を記録します。 複数の要素を並列に持つrecord、case、person、organization、mediaCoverage、statistics、問い、audit / provenance などを、それぞれ異なる役割を持つ要素として扱います。どれか一つを唯一の中心機能とは位置づけません。 recordrecord は「誰が・いつ・何をしたか」を、日付と出典とともに残す最小の事実単位です。後から機械が再利用しやすく、別の case や人物・組織からも参照できる形を優先します。 casecase は意味のある record のまとまりです。単発事故、長期政策、選挙、制度改正など、粒度は固定しません。「このまとまりで追うと理解しやすい」ことを優先します。日本語の画面では、このまとまりの中で何が起きてきたかを読む場所であることから「経緯」と表示します。 case の型を細かく分類したり、case 同士の parent / related などの関係を網羅的に保守したりはしません。必要な関連は共通する record、actor、検索語、問い などから導出できる状態を優先します。 statisticsstatistics は record と同じく、判断材料となる第一級のデータです。件数だけでは見えない規模、頻度、推移、分母を扱うために使います。 record、case、actor、mediaCoverage、statistics などの役割と、出典・比較の考え方。
- 用語と命名 JapanTracker では、データの役割が名前だけでもなるべく一意に分かることを重視します。 ここでは、主要なデータや公開文書に使う英語名について、それが何を指すか、なぜその名前を採ったか、検討した別案をなぜ採らなかったかを記録します。短さだけを優先せず、長くなっても意味が限定される名前を選ぶことがあります。 英語のデータ名と日本語の表示名は別のレイヤーとして扱います。日本語を英語の直訳にそろえることより、初めて見る人がその画面で何を読めるか分かることを優先します。 record指すもの: 「誰が・いつ・何をしたか」を、日付と出典とともに残す最小の記録単位です。発言、決定、文書の公表、事故、判決などを同じ形で扱い、一つの record が複数の case に属することもあります。 採用理由: JapanTracker 自身が「真実」と認定した単位ではなく、出典とともに残した記録であることを表せます。出来事だけでなく発言や文書も含められ、Git の履歴のように後から参照・再利用する考え方とも整合します。 case指すもの: 意味のある record のまとまりです。単発事故、長期政策、選挙、制度改正などを、「このまとまりで追うと理解しやすい」という単位で束ねます。 record、case、mediaCoverage、unresolved など、主要な名前の意味と採用・不採用の理由。
- AIによる生成と運用 JapanTracker は、一人の運営者がすべてを読むことで正確性を保証する仕組みにはしません。規模を広げる手段として、選題・収集・執筆・検証・監査をAIへ大きく移していきます。 現在の手動選題は暫定運用初期段階では、運営者自身が関心を持ち、ユーザーとして中身を確認できるテーマを使って、データモデルやUIの良し悪しを検証しています。これは恒久的な編集方針ではありません。 形が固まった後は、社会で流通している話題や既存のdatasetを材料に、AIが選題・収集・検証を行う比率を高めます。 人間による全件監査を置かない人間による最終確認や全件レビューの工程は置きません。 運営者が一件ずつ読むことを正確性の前提にすると、データ量が増えた時点で仕組みが止まるためです。 人間が見ないことを隠しません。利用者は、出典と生成過程を確認したうえでデータを利用する前提です。 単一モデルを正解にしない一つのAIモデルの出力を、そのまま「中立」「正しい」と認定する方針は採りません。複数モデルや機械的ルールを、異なる種類の問題を見つける監査器として組み合わせる方向です。 人間による全件監査を置かず、選題・収集・執筆・検証をAIへ移していく方針。
- 監査・Provenance・透明性 JapanTracker は、「人間が確認したから正しい」「中立だと運営者が判断したから中立」という保証を置きません。代わりに、どのように作ったかを外から検証できる状態をつくります。 中立を名乗らないJapanTracker は「中立です」と名乗りません。何を中立とするか、どの程度偏っているかという評価自体が、評価者や比較軸によって変わるためです。 一方向の見方に寄りすぎないよう設計はしますが、その達成度をJapanTracker自身が認定しません。 何を残すか可能な限り、使用したモデルとバージョン、prompt / protocol、調査対象、検索条件、入力、参照した資料、比較対象を探した過程、見つかったもの・見つからなかったもの、採択・不採択、判断理由、実際に行った変更を残します。 「問題候補を検出したこと」と「canonical datasetを変更したこと」は分けて記録します。再調査したが変更しなかったことも、後から確認できる方が望ましいと考えています。 公開しなかった候補も残す問い を含め、生成した候補は基本的に捨てません。公開しなかった場合は、その理由も残します。採択されたものだけを見るより、何を見送ったかも含めた方が選択バイアスを検証しやすいためです。 生成過程、探索条件、判断理由を残し、外部から検証可能にする考え方。
- 問い の考え方 問い は、ニュースの要約や重要ニュースランキングではありません。JapanTracker のデータと社会で実際に起きている議論から、考える価値のある問いをつくるためのデータです。 問い は正式なデータ問い はSNS投稿を作るためだけの一時的な文章ではなく、record や statistics と同様に永続的に保存する対象です。問い、根拠、生成・採択過程を後からたどれる形にします。 社会に存在する議論から出発する問いを新奇さのためにゼロからひねり出すことを目的にはしません。SNS、Community Notes、新聞、テレビ、世論調査などから、その時点で何が話され、どんな前提や印象が流通しているかを拾います。 そこから、すでにある議論を深める、別の比較軸へずらす、抜けている視点を補う、認知を較正するといった方向で 問い を作ります。 見落とされた問題だけに尖らないまだ注目されていない問題も扱いますが、「主流が扱っていないこと」自体を価値にはしません。すでに大きく議論されているテーマでも、より良い問いに変換できるなら同じように扱います。 attention が少ないテーマほど優先する、というルールも置きません。逆に、伸びそうなテーマだけを採択することもしません。 社会で考える価値のある問いを、どのように作り、保存し、公開するか。
- 問いをつくるときの考え方 JapanTracker は、記録を置くだけでなく、そこから社会で考える価値のある問いをつくり、できるだけ多くの人に届けることを目指しています。ここでは、その問いをつくるときに大切にする考え方をまとめます。 これは採点表ではありません。すべての問いがすべての条件を同じ強さで満たす必要はなく、これだけで良い問いを網羅的に定義できるとも考えていません。問いを選び、見直すときの共通の基準です。 1. 事実に根ざす問いの出発点は、確認可能な記録、統計、制度、発言、報道などに置きます。根拠のない仮定や、誰かの印象だけから結論へ誘導する問いはつくりません。 2. 現実の選択に関係する政策、制度、社会の振る舞い、人々の判断など、現実に存在する選択やトレードオフにつながる問いを重視します。答えても現実の理解がほとんど変わらない問いを、目新しさだけで優先しません。 3. 結論を問いの中に埋め込まない「なぜ失敗したのか」のように、まだ確かめるべき前提を事実として置く問いは避けます。問いは、JapanTracker の立場へ読者を連れていくためではなく、読者自身が考えるための入口にします。 4. 単純な賛否だけで終わらせない賛成か反対かだけでは見えない条件、便益、コスト、影響を受ける人、時間軸などを探します。二択を増幅するより、何を比較し、何を考えるべきかが見える問いを目指します。 事実に根ざす、誘導しない、認知を較正するなど、問いそのものの原則。
- 社会への届け方 JapanTracker は、良い問いを作るだけでなく、できるだけ多くの人に届くように配信します。ただし、選題と配信最適化は分けて考えます。 選題はリーチだけで決めない伸びそうな 問い だけを選ぶことはしません。ほとんどインプレッションが付かない問いでも、出す価値があると判断したものは公開される状態を許容します。 配信時はリーチを最大化する採択した 問い については、SNS上でできるだけ多くの人へ届くことを目指します。入口では、人間が読みやすく、理解しやすく、続きを考えたくなる表現を使います。 「一人を100深くする」だけでなく、「100万人を1深くする」ような広い認知変化も重要な影響として考えます。 煽ることを目的にしないコピーライティングとして感情や関心を引く表現を使うことはあります。ただし、怒り、恐怖、敵味方の単純化を意図的に増幅し、感情的な対立そのものを目的にすることはしません。 投稿形式は固定しない短い一問、数字を添えた投稿、長文、スレッドなどを使い分けます。SNS本文だけでも最低限の事実や問いが伝わることを理想とします。 SNSでのリーチ、表現、KPI、公式アカウントの振る舞いについて。
- Follow とフィードバックループ JapanTracker は、一つの中心機能だけで価値を作るのではなく、複数のループが相互に回る構造を目指します。Follow はその一つです。 Follow は中心機能ではないrecords、cases、actors、mediaCoverage、statistics、問い、audit / provenance、Follow などを、一つの上下関係で並べません。どれか一つを唯一の中心機能と呼ばず、複数の役割が並列に存在するものとして扱います。 当面は case 単位現在想定している Follow は case 単位です。ケースを超えたテーマ単位の Follow も将来的には考えられますが、現時点では優先度を上げません。 通知主体を持たないJapanTracker 自身が購読者名簿や通知基盤を持つのではなく、ユーザーのAIに定期タスクを作ってもらい、対象ページの更新を確認させる形を優先します。 重要度をJapanTracker側で判定しない何が「重要な更新」かを JapanTracker が判断して通知する設計にはしません。case の「今後わかること」や record などに変更があれば、利用するAIが差分を検知し、ユーザーへの伝え方を判断します。 複数のループを持つJapanTracker には、事実基盤が厚くなるループ、利用されるほど検証可能性が増すループ、dataset から 問い が生まれ議論から新しい論点が戻るループ、Follow によって一過性の関心が継続するループ、社会の反応が新しい record になるループなどがあります。 case を継続して追う仕組みと、複数の影響ループの位置づけ。
- 責任範囲と外部からの指摘 JapanTracker は、検証可能な事実と問いを作り、社会へ届けるところまでを自分たちの仕事として考えます。そこから先の結論、議論、行動までを統制することは目的にしません。 責任を持つ範囲出典とデータを残すこと、生成条件を公開すること、良い問いを作ること、それをできるだけ多くの人へ届けることには責任を持ちます。 知らなかった事実を一つ知る、持っていなかった問いを一つ持つ、昨日より少し考えが深まる、といった小さな認知変化を広く起こせる状態を目指します。 責任を持たない範囲全員に元データを読ませること、良い議論を最後までコーディネートすること、特定の政治的結論へ導くこと、投票や支援などの行動を指示することは責任範囲にしません。 JapanTracker のデータが偏っているか、十分か、妥当かという最終評価も利用者自身に委ねます。そのために出典と provenance を公開します。 人間の解釈を正解として持ち込まないJapanTracker 自身の評価や結論を、事実であるかのように提供しません。AI生成物に解釈や評価が入り込む可能性はありますが、その存在をゼロと宣言するのではなく、生成過程を検証可能にします。 何に責任を持ち、何には持たないか。指摘・訂正・社会的影響との距離。