ユーザーインターフェース設定：AIの誘導を無効にする設定を含める

貢献 UX
,
1

DiscourseのユーザーインターフェースがAIを売り込もうとしてくるのは、本当にありがたくありません。私は今もこれからも購入するつもりはありません。すべての投稿をAIで要約する提案を無効にする設定はありますか？

2

このサイトではそれが表示されないことに気づきました。AI要約はアドオンであると他の投稿から見て取れます。TC39（JavaScript標準化団体）がこのアドオンを持っていることは構いませんが、私の個人的な好みは彼らのものとは異なり、彼らの価値観を私に押し付けたいという私の願望はゼロです。

3

Metaへようこそ :waving_hand:

どの「促し（nudges）」について話しているのか明確にしていただけますか？現在、公式のDiscourseの#aiプラグインの機能について話しているのか、それとも使用している別のDiscourseフォーラムのカスタム機能なのか分かりかねています。

トピックを要約するためのボタンについては知っていますが、すべての投稿に要約ボタンが表示される機能については認識していません。

Screenshot_20260119_194113_Firefox
Screenshot_20260119_194113_Firefox1572×987 147 KB

「いいね！」 1
4

ええ、それらのことについて話しています。このサイトにも存在するようですね。

5

Stylusのようなブラウザプラグインを使ってCSSを使えば、そのボタンを自分用に非表示にできると思います。私はそれを使ってこのサイトの別のトピックマップの部分を削除しています。

6

私は本業がフロントエンドエンジニアなので、その考えは頭をよぎりました。それをひとまず置いておいて、この機能を無効にする新しい設定を作成するためにDiscourseにPR（プルリクエスト）をコードで作成したいとしたら、そのような質の高いPRは受け入れられるでしょうか？

7

彼らの代わりに答えることはできませんが、一般的に、彼らは不必要な複雑さを避けるために新しいカスタマイズ設定を追加する前に二度以上考える傾向があり、支持を集めた機能リクエストを優先します。

「いいね！」 1
8

それは全くのランダムな要求ではありません。倫理的な観点からAIに反対しているのは私一人ではないことを承知しています。また、コラボレーションと能力に対する腐食的な影響を考えると、この技術に対して深く苦々しい思いを抱いています。AI機能を詰め込もうとしたほとんどすべてのツール（Firefox、VSCode、Notionなど）は、それらすべてをオフにできるという大きな需要にも直面しています。

「いいね！」 1
9

これは非常に重要です。

質の高いプルリクエスト（PR）を歓迎しますが、あらゆる設定は何らかの形でオーバーヘッドを引き起こすため、追加する機能については非常に慎重になるよう努めています。

別の方法として、使用しているフォーラム自体でその問題を提起することも考えられます…もしかしたら、完全にオフにするよう説得できるかもしれません。

いずれにせよ、独自の時間と労力を費やしてそのPRを作成する前に、Feature リクエストを出し、あなたのアイデアが支持を得られるかどうかを確認するのが良いでしょう。

しかし、ここで提案されているようにCSSで簡単に隠せるのであれば、なぜ設定に組み込むことに固執するのか興味があります。それは単にイデオロギー的なものなのでしょうか？

「いいね！」 1
10

管理者は単一のトグルですでに AI を完全にオフにできることに注意してください

ユーザー設定としてのスコープは、主にボタンをオプションで非表示にすることになります… スパム検出などの管理者が使用する AI 機能を個人が完全に無効にすることはできません。

「いいね！」 2
11

ええ、ユーザーインターフェースの簡単な設定では、ボタンの切り替え以上のことはできないだろうと思っていました。しかし、それがまさに私が望んでいることです。そのボタンを二度と使うことはないので、私にとって製品の改善にはならず、表示されない方がいいと思っています。

「いいね！」 1
12

サイト全体の AI 統合を無効にしたかったのですが、それが単一の設定でできることに非常に満足しています。OP が求めている答えは、discourse_ai_enabled のユーザー単位版のようなものかもしれません。そうすれば、AI はサイト全体で完全にオン/オフになるわけではありません。サイトレベルで有効になっている AI 機能であっても、ユーザー単位で抑制できるのです。discourse_ai_enabled のロジックは、サイト全体で true かつユーザー単位でも true となります。

一般的に、不要な複雑さを避けるために新しいカスタマイズ設定を追加することを彼らは考えているのは事実ですが、AI は設定可能な項目数が最も多い機能です。AI が存在するようになったごく短い期間の間に、Discourse において最もカスタマイズ性の高い機能になっているようです。[1]

以下は、手っ取り早い分析です。私はここに来たばかりなので、もし間違いがあれば確認できるように計算過程を示します。

su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt

これが正しい数え方であれば、可能なサイト設定は 1663 件です。そのうち、104 件が ai_ で始まり、3 つの AI 設定はそうではありません（composer_ai_helper_allowed_groups、discourse_ai_enabled、post_ai_helper_allowed_groups）。つまり、私の計算では、AI は圧倒的にカスタム設定の最大のグループを占めています（1663 件中 107 件、つまり全サイト設定の 6.4%）。以下は上位 10 件です。

  • 107 ai
  • 84 discourse
  • 83 chat
  • 71 max
  • 65 enable
  • 48 default
  • 30 dfp
  • 28 oauth2
  • 28 amazon
  • 28 allow

一方、AI 機能のユーザー単位での抑制は、1663 件のうちの 1 件に過ぎません。他方、多くのコードパスがサイト全体でチェックしている場合、ユーザー単位でチェックするのは難しいかもしれません。これは、私が推測する資格がないトレードオフです。

  1. また、比較的明確に定義され、自己完結型の機能であり、比較的新しいため、ai_ という命名規則が一貫しているおかげで、他のコンポーネントよりも設定項目を数えやすいのです。だからこそ、これは「手っ取り早い（quick and dirty）」分析だと言っているのです。 ↩︎