複雑なテーマの議論のためのツール、CQ2
(cq2.co)- 複雑で長い議論は、対面・チャット・フォーラムのいずれでも、衝動的な応答と構造不足のために流れが崩れやすい
- Discourse はコメントが時系列で積み上がるため、位置のコンテキストを失いやすく、Slack は 1 段階のスレッドしかサポートしていないため、深い議論を収めにくい
- 引用で返信関係をつないでいく方式は、参加者が増えるほど議論の構造を頭の中で追跡する必要が生じ、quote hell につながる
- CQ2 は特定の引用文やコメント全体を基準に、スレッドの中にスレッドを作り、関連する返信と上位のコンテキストを 1 画面で確認できるようにする
- まだ初期段階の無料オープンソースツールであり、モバイル最適化前のため、デスクトップやノートPCで試すのが現実的
複雑な議論が難しくなるポイント
- 職場の戦略議論、AI alignment、技術設計ドキュメント、公共政策のように長い文脈が必要なテーマで問題が目立つ
- 繰り返し現れるボトルネックは 衝動的な応答 と 構造不足 である
- 対面での議論は即時反応を誘発し、議論の構造を維持しにくいため、複雑なテーマを深く扱うには限界がある
- アクティブリスニングが理想的な解決策になり得るとしても、すべてのチームや状況で常に機能するとは言いにくい
- 文章ベースの非同期議論は反応速度を落とせるため、slow mode のような機能があれば、より慎重な応答を促せる
- ただし非同期議論でも構造が不足していれば、長い議論を追いにくいという問題はそのまま残る
Slack と Discourse の構造的限界
- Discourse の議論は 整理されていないコメントストリーム のように続いていく
- 複数人が重なって発言し、話題が混ざる形式は、複雑で長いテーマを深く掘り下げるのに向いていない
- コメントが時系列で並ぶため、議論の中で「どこにあるか」よりも「いつ投稿されたか」のほうが見えやすい
- 特定コメントへの返信を 1 か所で見ることはできるが、その返信にさらに付いた返信を見るには、別のコメントの間をスクロールする必要がある
- Slack は文章ベースの非同期議論のために作られたツールではないが、広く使われている
- 特定のコメントを別パネルのスレッドで議論できる
- スレッド内のコメントをさらに別スレッドにはできないため、議論が 1 段階のスレッド に閉じ込められる
- UI は長い非同期議論よりも、短く素早いコメントのまとまりを送る方向に近く感じられる
- typing indicator は、1 人が考えをまとめている間に他の人の注意をそらす可能性がある
引用が構造の代わりになる quote hell
- チャット・フォーラムツールで共通して現れる問題は quote hell である
- 典型的な流れはシンプル
- Ava があるテーマについてコメントを残す
- Caleb が Ava のコメントの一部を引用して返信する
- Ava が再び Caleb の返信を引用して返答する
- この方式では、1 つのテーマに対する返信が複数のコメントに分散し、ユーザーが引用と返信の関係を自分で追跡しなければならない
- 途中で無関係なコメントまで入り込むと、議論の流れは簡単に途切れる
- 2 人の議論ではそれほど目立たないかもしれないが、5 人以上 が参加する長く複雑な議論では、混乱が急速に大きくなる
CQ2 が提案する議論構造
- CQ2 は複雑な議論のために作られた 無料オープンソースツール で、まだ初期段階にある
- LessWrong の小さな議論を CQ2 上でシミュレーションした結果、より整理され、追いやすかった
- 核心はスレッドの中に再びスレッドを作る構造にある
- 各スレッドが 1 つの話題に留まるのを助ける
- 特定の引用文を中心に新しいスレッドを作り、関連する返信を 1 か所で見られる
- 現在のスレッドのすべての上位スレッドを同じ画面で見られるため、位置のコンテキストを失わない
- CQ2 の tree により、未読コメントのあるスレッド、結論が出たスレッド、特定スレッドへ素早く移動できる
- 解決済みのスレッドと議論全体に 結論 を追加できる
利用フローと予定機能
- 議論を始めるときはタイトルと説明を入力する
- 説明は短くても長くてもよく、議論開始前に文脈・必要情報・考えを提供するために使われる
- その後、参加者にリンクを共有する
- 通常のコメントは最初であり最も左にある main thread に投稿する
- 特定のテキストに返信したい場合は、説明またはコメント内のテキストを選択し、「Reply in new thread」ボタンでその引用文を中心とした新しいスレッドを作る
- コメント全体に返信したい場合は、コメント右上の reply ボタンを使える
- すでに特定の引用文に対するスレッドがある場合、その引用文は強調表示され、クリックしてそのスレッドを開き、議論を続けられる
- コメント全体に対するスレッドがある場合、コメント右上の comments ボタンが強調表示され、クリックするとそのスレッドを開ける
- スレッド移動は trackpad スクロール、または shift キーとマウスホイールで行える
- ナビゲーションバーの tree は特定スレッドへ素早く移動できるようにし、スレッドごとのコメント数・未読コメント数・結論の有無を表示する
- 「Conclude thread」ボタンでスレッドを締めくくることができ、結論が出たスレッドには緑色のバッジと緑色の結論コメントが表示される
- 議論全体はナビゲーションバーの「Conclude discussion」ボタンで締めくくる
- 予定機能には リッチテキスト（rich text）、workspaces、thread custom title、mentions、slow mode、有用な reactions、議論で見落とした部分を見つけるのを助ける AI assistant が含まれる
- CQ2 はまだモバイル利用に最適化されていないため、デスクトップやノートPCで使う必要がある
- Early access は Tally フォーム から受け取れる
1件のコメント
Hacker Newsの意見
複雑な議論のためのツールは、実のところ Usenetニュースリーダーでほぼ解決されていたと思う
スレッド構造が明確に見え、1画面で投稿50件ほどの構造を確認でき、未読のスレッドや投稿が強調表示され、Tabを押すと次の未確認投稿へ移動できた
既読状態も時間基準ではなく投稿／コメント単位で、素早い移動やフィルタリングなどの便利機能もはるかに多かった
その後の議論プラットフォームは、利用効率や深く長続きする議論の能力という面では概して後退したが、最初はWebブラウザの制約のためで、後にはモバイルのタッチインターフェースのためだったと思う
上部引用と下部引用が入り混じり、スレッドは壊れ、投稿が欠落して、人々が何日も互いにすれ違った話をすることがよくあった
Usenetは本当に好きだったし、自分のキャリアの出発点でもあったが、懐かしいとは思わない
投稿、モデレーション、並べ替え、特定の人のフォローといった基本機能以前に、トピック議論の基礎的な体感は、今日におけるUsenetの正当な後継者であるRedditより悪かった
ある時点で、あるスレッドは別スレッドの並行した議論のせいで無意味になることがあり、別スレッドの特定の地点へ簡単に誘導できれば大いに助けになった
しかしそのためにはURLが必要で、メッセージIDはそうした用途には使われていなかった
逸話的には、高校や大学レベルの授業でオンライン討論フォーラムを運営するにはかなり良さそうだ
評判は悪いが、こうした議論には 画像掲示板式のコメント が最も良いと思う
各投稿には固有IDがあり、自分の投稿内に別の投稿へのリンクを入れられる
すると各投稿には、自分を引用したすべての投稿を示すバックリンクが付き、投稿は時系列で表示されながらも、比較的たどりやすいハイパーリンクのネットワークを形成する
長文の議論にはかなり効果的だったが、構造が不必要に制限的なのが惜しい
投稿が単純に接続グラフを形成し、Webサイトがそれを任意の方法で表示できればもっと良い
このプロジェクトの配置はXanaduを強く思い起こさせるが、これほど複雑なインターフェースが必ず必要だとは思わない
むしろ生産的な議論を妨げることもあり得る
文字数制限や返信の深さ制限といった他の媒体の制約が明確さを助ける場合は多く、人と人との情報伝達は根本的に線形なので、結局は短いエッセイを書いて交換する方法が実際の議論の基盤になるからだ
ほとんどのユーザーにとって最大の障壁はコメント間を行き来することであり、相手が何に返信しているのか確認するのに数秒余計にかかるだけで興味が削がれかねない
誤って違う場所をクリックしたり、戻るを押しすぎたりすると、読んでいた位置を失いやすくもなる
複数の会話が同時に進むと、特定の会話について人々が何を言っているのか追いにくい
スレッドの履歴をたどるには、関係のないコメントを除外し、重複した引用を無視するという認知負荷が大きい
新しい方式なら、関心のない投稿は一度だけ見ることになる
整理作業を事実上ひとつの形式に変えてくれる
私の考えでは、今でも 4chan式の線形タイムライン が最も良い
ただし
>参照をたどりやすくする強力なUIサポートが必要だこのアプリやHN、Redditは「スレッドの中のスレッドの中のスレッド」というツリーを採用しているが、同じ親コメントに付いた複数の返信の一部へまとめて応答したいときには非常に悪い
改善するには、この構造のDAG的性質を受け入れ、コメントが応答する親ノードの集合を直接選べるようにすべきだ
さらに重要なのは、その集合を編集可能にすることだ
ほかの人が既に議論された話題について新しいコメントに返信したとき、「ここに私の返信がある」というコメントを新たに付ける必要なく、以前の回答を新しい親に接続できるようにすべきだ
参加の多い議論では、互いにほとんど関係のないサブスレッドが生まれるものなので、その場合 線形構造 はひどく不向きだ
ひとつの返信を非表示にすると、その返信に付いた返信チェーン全体も自動で非表示にできる
LLMがノードにメタデータを追加すれば、さらに興味深くなり得る
たとえばAが陳述Saを提示し、Bがそれに対してSbaで、CがScaで応答するとしよう
新しく加わった人は、SbaはSaの大部分には同意しているが特定の事実に反論しており、ScaはSaのどの内容にも同意していない、といった形で見られる
また、多くの人が同意したノードは重みが大きくなり、反対が多ければ小さくなる、といったことも可能だ
実装と波及効果は事実上無限にある
CQ2 のように「スレッドの中にスレッドを作り、各スレッドが話題から逸れないようにする」方式になるとよいのだが、私の経験では、人々に第1階層のスレッド利用をさせることすら非常に難しく、特に非技術者にはそうだと思う。
複雑な議論は、良くも悪くもたいてい「短く通話して整理しよう」という流れになる。
コミュニケーションアプリに最も期待している機能は、機械学習モデルがそうした「短い通話」を聞いて、要約とアクションアイテムを生成し、スレッドに戻して投稿してくれること。
そうすれば、双方の利点を得られる。
なぜそうなのか気になる。
個人としては非常に賢く体系的な人と仕事をしていても、スレッドが登場した瞬間に、構造化されたコミュニケーションが完全に崩れることが多かった。
興味深いことに、口頭でもたまに同じことが起きる。
職場、電話のテクニカルサポート、アーティストや作家とのフィードバック議論、友人との会話で、特定の下位論点に絞って最後まで扱ってから次へ進む、または全体像に戻る、というやり方を嫌う人がいる。
代わりにあちこち飛び回ったり、直近で関心を持った話題に会話を
chrootするかのように閉じ込めたりする。逸話的には「2種類の人」に近いのだが、共通要因は分からない。
能力不足や悪意の問題ではなく、単にツリーやスタックで考えない人たちなのだと思う。
「AI要約だけ」が目的でも録音は必要で、どこかには文字起こしが残る。
削除の約束を信頼できるかどうかも問題だ。
自己検閲、好みや知識の歪みが思い浮かぶ。
プライバシーへの期待がなく、観察されていると分かっていれば、人は違う行動をする。
雇用上の不利益、社会的孤立、メンタルヘルスへの影響に加え、パノプティコン的な環境は、人々をより衝動的でなく、より順応的に振る舞わせ、創造性とイノベーションに悪影響を与え得る。
実務経験上、ローカル文字起こしも相当な計算資源を割り当てなければ即時にはならないことが多い。
要約が通話終了後しばらく出てこない場合もあり、AIの結果がもっともらしいか／正しいかを確認するには、頭の中でかなり振り返る必要がある。
経営陣は好むだろうが、それ以外の人は徐々に嫌がるようになると思う。
少なくとも私にとって、私的な個人間の会話や通話は、現代のリモートワーク環境における対人的なつながりと社会的な安心感の最後の砦だ。
リンク先の記事に出ている理由から、複雑な話題は「口頭で決めよう」で終わらせるべきではない。
個人的には、今でもモデレーションのある vBulletin/phpBB 風フォーラムが、長期的なオンラインコミュニケーションの最高の形だと思う。
私が見ている複数のフォーラムには、数十年続いているアクティブな議論スレッドもある。
複数のスレッドが絡むとさらに悪化する。
昨年末に Google Chat がこの「スレッドベース」のスペース／チャンネル方式を強制する前は、「トピックベース」のチャンネルを選べた。
すべての議論が独自のスレッドを持ち、ルートレベルはなく、トピックに返信が付くとそのトピックが再び上に上がってきた。
ソフトウェアのイシューごとのトピック、サポートケースごとのトピックといった用途に向いていて、「各トピックはメールのスレッドのようなもの」と説明できたので、非技術者にも理解しやすかった。
各トピックの最初のコメントを要約する習慣もでき、その最初のコメントは常に見えるため、メールのように議論一覧をざっと確認できた。
非技術者には、メールになぞらえられるものが一番よい。
Slack や Discord では、デフォルトの動作は一番下の大きな入力欄と送信ボタンから、チャット全体へ構造のないメッセージを送ることになっている。
返信として別スレッドを作るオプションは、より隠れている。
簡単なUXの再配置と強調で解決できる。
新しいスレッドの作成にはタイトルを必須にする、あるいは入力欄を開くボタンを置く、といった形で少し摩擦を加えることもできる。
これは Google Docs のコメントシステムにかなり似ているように見えるし、各サイドスレッドを1つずつ開くにはクリックが多く必要になるという同じ問題がありそうだ。
複数の返信を一度に「全部読んだ」と感じにくい。
私は Discourse の現在の線形形式の方がよさそうに思う。
新しい返信がすべて下に積み重なり、理想的には文脈のための引用が一部あればよい。
単に文書のようにスクロールして読めばよいので、更新に追いつきやすいからだ。
文書を共同で作業している場合、つまり変更を追跡し、それにコメントする場合でなければ、各コメントを断片的に見て回ることはあまり有用でないことが多い。
複数のコメントを一度に読んでから、全体に対して要約的に返信する方が、全員の時間を節約できる。
長文の議論を追跡不能にするのは、些細なポイントごとに延々と行き来する会話だ。
そういうものは Slack や通話のようなリアルタイムな方法で処理したうえで、メインの会話には「4番目の項目について Joe と Jane と話してみたところ、blah blah を使うのが最善だという合意になった」程度に短く要約する方がよい。
スレッド返信の要約ツリーは Google Docs より改善される可能性がありそうだが、基本的なインタラクションの流れは Google Docs と同じに見える。
ここ数年提案されているウェブページ注釈システムの仕様を見てみると、さらに革新の余地があるかもしれない。
「複雑で深い議論が好き」とのことだが、実際かなり深く複雑に見えるので、深く複雑な議論を生み出せない理由はなさそう
冗談はさておき、気に入っているのは、議論が原文テキストの特定の抜粋を中心に始まる点
つまり、テキストの一部を選択してスレッドを始める
HNで記事の引用から始まっていないトップレベルコメントはいつも懐疑的に見てしまうが、そういう場合、原文を読んでコメントしているのか疑わしいことが多い
ただしこの方式は、テキストブロックではない動画、画像、ゲーム、アプリケーションなどについての会話をどう扱うかは解決していない
そしてこのパターンで最も難しいUX上の問題である重なり合う抜粋も解決していない
重なり合う抜粋を同じスレッドと見るのか新しいスレッドと見るのか、境界をどう定義するのかが問題
集団意思決定の研究を基に作られたカスタムプラットフォームで、グループ討論を支援する部署で働いたことがある
そのプラットフォームのキラー機能の一つは匿名性だった
報復を恐れたり、政治的な駆け引きと見なされたり、群衆に流されているという負担なしにコメントや投票ができるとき、グループ討論では真実が表に出ることがあった
cq2で全コメントに名前が付くのを見ると、気まずいアイデアを持つ人は投稿をためらうかもしれないと思う
なので、c2q式のトラッキングがどの種類の問いに向いているのか気になる
描写されていることは、フレームワークというより文化の問題に近い
人々は疑問を口にしたからといって報復を恐れるべきではなく、幸い最近の顧客企業や以前の職場はそういう環境ではなかった
公開されているプラットフォーム情報や研究があるのか気になる
トローリングのような匿名性による悪い行動をどう管理していたのかも知りたい
私は政治システムの改善を願って、AIを活用した集団意思決定の改善に関する小さな研究プロジェクトを調べているところ
実例が少なすぎるので、こうした直感をもっと得られるとうれしい
DMがよければTwitterで@dchです
視覚資料が大きく欠けている
テキストベースの議論では、読者ごとに頭の中に別々の絵ができてしまう
全員がテキストの説明には同意していたのに、デザイナーが絵を描くと実は認識がそろっていなかったことが明らかになり、全員が反対する、ということはよくある
非同期でよりよく議論する方法という考え方は良いが、私は画像・動画・図表のような視覚資料をフォーラムの中心に置き、多くの人が作るのを難しく感じるという視覚資料の最大の問題を克服する方向を選ぶ
挙げられていた代替案はいずれも、コメントを特定のユーザーに結び付け、コメントを別のコメントへの返信としてつなげている
それよりも会話は議論対象のテーマに焦点を合わせられるし、そのテーマはしばしば概念を説明する視覚資料の集合として最もよく表現される
コメントに返信するのではなく、視覚的に表現された問題の構成要素を中心にコメントを構成できる
そうすれば、特定ユーザーのコメントを増幅したり批判したりする代わりに、複数の人が一つの概念を支持できる
焦点が誰かのコメントではなく問題そのものに置かれるので、防御的な態度も減らせるかもしれない
議論中の概念を表す構造を作ることが、複雑な問題を議論し理解を深めるうえで重要だと思う
私が作っているツール[1]は、人々がそうした構造をより簡単に作り、扱えるようにすることを目指している
ただし、特に問題解決の文脈に焦点を当てており、協働利用に重要な機能はまだ欠けている
ここではコメントが特に関連するが、近いうちに追加予定
中核となるアイデア[2]は前述の内容とつながっているように見えるが、このツールは質問・事実・出典のような補助的な概念と、問題・原因・効果・トレードオフ・解決策のような主要な概念をより区別している
[1] https://ameliorate.app/
[2] https://ameliorate.app/docs/getting-started/core-ideas
ただし、グループに何かを作らせたいなら、テキストだけでも十分なことが多い
そうすれば誰も自分で絵を描く必要がない
逆に言えば、誰も視覚資料を直接制御できない
人々がテキストボックスにコメントを入力すると、そのコメントがサーバーに送られ、サーバーが「アイデアを説明する視覚資料」を継続的に更新するUIを想像している
各クライアントは新しい視覚資料でUIを更新し、すべてのコメントを画像・動画・図表に紐づける方法も提供する
つまり、クライアントUIの中心はスクロールするコメント一覧ではなく、AI生成の視覚資料になる
ユーザーは議論のさまざまな構成要素に掘り下げながら討論を探索できる
AI生成の要約もあり得る
本質的には、AIがサイドチャネルで絵を描くデザイナーと、要約の抽象化を継続的に更新する賢いアシスタントの役割を果たすということ
互いを十分に好ましく思っていて助け合おうとする小規模なグループが直接会い、傲慢なほどシニアな人は外すべき
そうすれば1年分の仕事を1か月で終えられる
互いを好ましく思い、助けたいと思っている小さなグループなら、オフラインでもSlackでも何でも同じように機能する
それを解決する技術的な解はない
真剣に気になるのだが、HN/Old Reddit式の構造の何が問題なのか分からない
私の経験上、有能なモデレーターがいれば、そのシステムは満足のいく議論を生み出す
さらに「複雑な」議論なら、参加者が比較的小さな障壁にもかかわらず参加し続けようとするという前提があるが、この解法ではそれが存在論的な課題のように見える