NISHIO Hirokazu[日本語][English]

ドキュメントにコメントスレッドが生える形の熟議

Google Docs叩き台のドキュメントをおき、そこにコメントをつけてコメントスレッドができる、というタイプのコミュニケーションの形がある LLM以前からあるが、これも口頭のコミュニケーションと全く違った「技術の進歩によって可能になったコミュニケーション」だ

日本におけるデジタル民主主義の発展経路は

  • 都知事選2024で安野たかひろが人々からGitHubでのIssue/PRを集める
  • 参院選2025で人々と会話したAIがGitHubのPRを作る という順だったのでこの形を通らなかったが、
  • 人々が慣れたUIとしては「テキストを一部を選択してそこにコメントをつける」の方がやりやすかったかもしれない
  • 人々の意見を受け取るチームにとってもその形式の方が楽だったかもしれない

技術的には「ベースのドキュメント」と「それに関するAIチャットログ」から「ドキュメントのスパン + 意見」というフォーマットでの抽出をかけることは可能だと思う

  • それをやった時点でドキュメントに対するレベル1のコメントが大量にある状態になる
  • 素朴なGoogle Docsスタイルは100倍のコメントがあると読めなくなる
    • そこで同一箇所に対するコメントはまとめていく必要がある
    • 「オーバーラップするスパン」に対するコメントをまとめてLLMが一塊にするとよい
      • 似た意見が10件とかならまとめてしまってよい
      • もしすごく量が多かったり、多様な意見が対立していたりするなら、それは取り出してもっとリッチな分析をしたらいい
  • ここまでで、まだレベル1のコメントだけがある、レベル2のコメントはどういう形で発生するか
    • 受け取りチームがコメントを見て、質問を発する、その質問は例えば
      • A: そのまとめコメントに寄与したユーザにメールで「あなたの意見に対して質問が届いています」などと通知され、それに対するコメントをシステムに書き込むことができる
      • B: この質問の情報がAIチャットの側のコンテキストに入り、今後のユーザがオーバーラップするスパンに関して似た発言をした時に質問が発動する
    • もしくは
      • B2: オーバーラップするスパンに対して新しく投稿された意見が既存のまとめコメントとコンフリクトする時に、それを伝えてどう思うかを質問する

関連

Google Docsのモデルで考えると三通りある

  • 直接編集
    • 書き換えて保存する
    • Wikipediaみたいに編集合戦が起きる
  • 変更提案
    • 編集して差分が提案される
    • 承認権限のをある人が承認するとその差分が反映される
    • GitHubのPRもこの仕組み
    • 差分が衝突(コンフリクト)することがある
  • コメント
    • 今回考察した仕組み

(C)NISHIO Hirokazu / Converted from Markdown (ja)
Source: [GitHub] / [Scrapbox]