AIトピックの週刊まとめ

ニュースとイベント フォーラムの概要
113

概要

今週のMetaでのAIに関する議論は、Discourse AIをユーザーにとって明確にし、大規模運用において扱いやすくすることに集中していました。プロダクト面では、「AI Persona」をより広く理解されている「AI Agent」にリネームする動きが強く、AI Persona → AI Agentへのリネームや、その続編となるAI Persona → AI Agentへのリネームにおいて、翻訳ワークフローへの影響も考慮されました。管理者体験についても注目が集まり、AIが無効化されているサイトでもAIダッシュボードやレポートが表示されてしまう問題が指摘され、これはバグとして確認され、AIが有効になっていない場合はAIレポートを表示しないおよび関連する包括的なスレッド管理者レポートと分析：段階的な変更におけるより広範なレポート作業に組み込まれました。

運用面では、コミュニティはコスト/パフォーマンスの制御とスケーリングに伴う課題について掘り下げました。DiscourseはOpenAIプロバイダーでのサービスティアでOpenAI/Azureプロバイダー向けのサービスティアを導入し、大規模なセルフホストインスタンスからは、セマンティック埋め込み検索を有効にした際に深刻な負荷がかかるという報告がAI検索の有効化でサーバーが壊れたにもたらされました。また、AI支援UX、特にローカライゼーションやエディタUIに関わる部分についても、AIヘルパーによる翻訳の保存をコンテンツローカライゼーションとして扱うや翻訳されたタイトルを編集する際、タイトルフィールドの外にタイトル提案の:star:ボタンが表示されるなどで継続的な改善が行われました。

最後に、AIに隣接するエコシステムとしてのMCPツールリングに関する作業も続き、Codex CLI向けの実際のセットアップガイドがOpenAI Codex CLIでのDiscourse MCPセットアップで公開され、これは公式アナウンススレッドDiscourse MCPが登場！にもクロスリンクされました。

興味深いトピック

アクティビティ

合計（過去7日間）： 新規トピック6件、投稿25件。最も活発なエンゲージメントは、命名/UXの磨き上げ、および埋め込みとOpenAI使用に関する実用的なスケーリング/コスト制御围绕していました。詳細はAI Persona → AI Agentへのリネーム、OpenAIプロバイダーでのサービスティア、およびAI検索の有効化でサーバーが壊れたをご覧ください。

お読みいただきありがとうございます。また来週お会いしましょう！ :slight_smile:

114

概要

先週（2026-03-09 → 2026-03-16）の Meta の ai に関する議論は、製品の完成度、信頼性、そして「実世界」での運用を中心に集約されました。

製品面では、Discourse が AI Persona から AI Agent への名称変更を実装することで、用語の標準化に近づきました（Renaming AI Persona → AI Agent）。インフラ面では、Discourse がホスト型 LLM オファリングの容量を大幅に拡大し、すべてのティアで制限を引き上げ、モデルの品質とレイテンシ特性を改善しました（Unlock All Discourse AI Features with Our Hosted LLM）。

一方、運用担当者たちは、AI がコミュニティのリズムにどう組み込まれるかに焦点を当てました。AI Agent の返信を遅らせる（チャットボットというより、参加者のように感じるようにするため）という要望が、新しいサポートトピック（Adding a configurable delay to AI Agent responses）として挙がるとともに、長期的な「Agents」ガイドスレッドでもフォローアップされました。Discourse スタッフは、遅延応答は ai 自体ではなく、将来の automation 見直しに含まれる可能性が高いと示唆しました（AI bot - Agents）。

統合に関する会話も顕著に増加しました。Google の Programmable Search / Custom Search の制約と廃止により、ウェブ検索ツールの見直しを迫られており、Discourse は代替プロバイダーの検討や、主要な LLM ベンダーから提供される「ネイティブ検索ツール」の導入を探っています（Google Search for Discourse AI - Programmable Search Engine and Custom Search API）。並行して、コミュニティガイドは Discourse MCP エコシステムを中心に拡大し続け、新たに公開された OpenCode CLI のセットアップ手順書も含まれています（Discourse MCP Setup in OpenCode CLI）。

最後に、実用的な管理者ワークフローが繰り返し話題に上がりました。直接データベースクエリによる AI スパム検出の可観測性向上（Discourse AI - Spam detection）、感情分析のバックフィルとデバッグに関する質問（Problems setting up Sentiment）、そしてプロバイダーや設定に依存する感情処理に関する GDPR 関連の懸念（Introducing Discourse AI Sentiment Analysis: New Admin Report Available）です。また、ツール呼び出しのタイムアウトに関する中国語のオープンサポートスレッドも、「詳細が必要」の段階で進行中です（Discourse ai のツール呼び出しタイムアウト如何解决？是否可以调整 discourse 超时时间，如何调整？）。

注目トピック

アクティビティ

ご一読いただき、ありがとうございます。来週またお会いしましょう！ :slight_smile:

115

meta.discourse.org の週次 AI サマリー (2026-03-16 → 2026-03-23)

概要

今週の AI に関する議論は、特に翻訳ワークフローと要約機能の配置における実用的な UX 改善とコスト管理の向上に集中しました。翻訳面では、Shauny 氏が、よりスムーズな投稿ごとの「翻訳」機能の提案と、API 利用料の重複発生を防ぐための翻訳出力の保存/キャッシュ機能の必要性を提起しました（Translate post with AI and save translation）。これに対し、Moin 氏は、このアイデアを以前のローカライゼーションに関する考察と関連付けました（Translate post with AI and save translation、Saving translations by AI Helper as content localization）。

要約 UIの面では、Ivan_Rapekas 氏が、AI 要約アクションをトピックヘッダー/サイドバーのタイムライン領域に追加するテーマコンポーネントをリリースしました。これは、要約ボタンの配置に関する長年の要望に答えるものです（AI summary in topic header、Feedback: Move summarize button at the top of the topic、Summarize button placement on mobile views）。

いくつかのスレッドでは、AI 管理設定における洗練さと信頼性が焦点となりました。「Default LLM」というエラーラベルが重複表示されるなどの文言の不備は認識され、修正待ちとなりました（Why is ‘Default LLM’ repeated…、Why is ‘Default LLM’ repeated…）。また、**LLM コスト設定 UI（ドイツ語版）**における i18n レイアウトの問題も引き続き改善が進められています（Field alignment issues… in German、Field alignment issues… in German）。

一方、コミュニティはエージェントの安全性の境界（特に管理者の監視なしに AI が「ユーザーとして」行動することへの懸念）を再考しました（Discourse 官方会出个官方的 openclaw skill 么？、openclaw plugin for discourse integration）。また、ツール呼び出しのタイムアウトや、Discourse AI とセルフホスト型 RAG/ナレッジベースの接続といった統合の制約にも取り組みました（Discourse ai 的工具调用超时如何解决？、Discourse ai 如何引入自建知识库 RAG？）。さらに、Discourse MCP がプロトコル経由でPDF 添付ファイルにアクセスできるかどうかという、小さながらも注目すべき質問も出ました（Discourse MCP is here!）。

興味深いトピック

アクティビティ

お読みいただきありがとうございます。また来週お会いしましょう！:slight_smile:

116

概要

今週の Meta Discourse における AI の活動は、タグやカテゴリなどの小さくも重要な UI 領域において、AI によるローカライゼーションの精度と予測可能性を高めることに焦点が当てられました。Moin は、AI 生成のタグ翻訳は完璧に機能しない というトピックで、コンテキストを欠いた LLM による翻訳の失敗例をいくつか取り上げました。これを受け、nat はプロンプトの改善や、タグの説明などの追加的な根拠コンテキストの導入を検討しました (返信)。一方、Falco は、エージェントに関連ソースを読み込ませるといったツール支援型のアプローチを探求しました (アイデア, フォローアップ)。また、「翻訳を同期して維持する」という関連フィードバックも、カテゴリ名およびカテゴリの説明の更新に関する機能リクエストとして提出されました (カテゴリ名, カテゴリの説明)。

設定面では、トラブルシューティングのスレッドにおいて、どの種類の PM（プライベートメッセージ）が翻訳されるのか、そして UI がそれをどのように伝えているのかについて混乱が見られました。私のサイトでの PM の翻訳が機能しない理由のトラブルシューティングを助けてください というトピックで、Moin は現在の制限（グループ PM と 1:1 PM の違い）を明確にしました (詳細)。また、Falco はより明確な多選択設定を提案し (提案)、nat は近日登場する「これらのカテゴリを翻訳する」制御が設定 UX を再構築する可能性があることを示唆しました (計画)。

最後に、漸進的な改善とエコシステムの強化が行われました。セマンティック検索結果と完全一致検索結果に関するメッセージの明確化 (検索の明確化)、ノイズを減らすための AI パーソナ行動の洗練への関心 (メンションみのリクエスト)、そしてテーマコンポーネントを通じた UI における AI 要約の継続的な採用 (フィードバック) などです。

興味深いトピック

活動

お読みいただきありがとうございます。来週またお会いしましょう！:slight_smile:

117

概要

今週（2026-03-30 → 2026-04-06）の meta.discourse.org では、Discourse AI に関する議論が以下の 3 つの主要なテーマに集約されました。

  1. MCP の推進とエージェントの機能: Discourse AI は、Model Context Protocol (MCP) にさらに注力し、クライアントサイドの MCP サポートを発表しました。これにより、Discourse AI エージェントが外部の MCP ツールサーバーを呼び出せるようになりました（Bring your own MCP!）。また、完全な管理ガイドも公開されました（AI Bot – Bring Your Own MCP Server）。並行して、サーバーサイドの MCP ツールも進化を続け、LLM が MCP を介して既存の投稿やウィキコンテンツを更新できるようになる編集ツールが追加されました（Discourse MCP is here!）。

  2. AI 自動化におけるモデレーションとプライバシーの境界: 「AI トリアージはプライベートメッセージ (DM) をスキャンできるか」という実用的なモデレーションの質問は、技術的な制限というよりは UI/設定の落とし穴であることが判明し、自動化 UI におけるより明確な制御機能に関する追加のアイデアを促しました（Does AI triage automation scan DMs between regular users?、solution）。

  3. ローカリゼーションと埋め込みにおけるモデル固有の特性: 複数のスレッドで、「AI 機能」は往々にして「モデルの挙動＋統合の詳細」に過ぎないことが浮き彫りになりました。翻訳の問題は、すぐに修正されたドイツ語の「AI コメント/思考テキスト」の漏洩（AI Commentary on German Translations）から、Mistral Small での翻訳時に画像が欠落する問題（モデルを切り替えることで回避）（Images missing in translated posts when using Mistral as translation model）まで多岐にわたります。埋め込みの面では、Mistral の API の不整合（dimensions と output_dimension）が設定で表面化しました（Use Mistral for embeddings）。また、AI ボット設定における廃止された Gemini モデル IDに起因する、実際の管理者によるトラブル（Issue with AI bots forum bots）も発生しました。

興味深いトピック

  • Discourse AI エージェントは、もはや任意のMCP サーバーに接続可能になりました（「Bring your own MCP」） (ai, #Announcements)
    sam は、Discourse AI エージェントが外部 MCP サーバーの URL（GitHub、Notion、Linear、検索プロバイダーなど）を登録し、発見されたツールを LLM エージェントから直接使用できるようになったことを発表しました（Bring your own MCP!）。関連するハウツー記事では、セットアップ、ツールの発見、および JS ベースのカスタムツールとの違いについて説明されています（AI Bot – Bring Your Own MCP Server）。

  • MCP の使いやすさ：「リモート/ウェブ MCP」の要望と、既存投稿の編集機能の追加 (ai, mcp, blog)
    継続的な MCP へのフィードバックにおいて、pacharanero は、ウェブで公開されたエンドポイントを通じて、MCP を CLI ユーザー以外にとってよりアクセスしやすくする方法を探求しました（Discourse MCP is here!）。 jrgong は、既存のトピックや投稿の編集を必要とする KB/ドキュメントのユースケースを指摘し（ref）、Falco は編集ツールが追加されたこと（「最新版にアップデートするだけ」）を確認しました（ref）。

  • AI トリアージモデレーションと DM スキャン：「個人メッセージを含む」は機能するが、「すべてのトピック」が混乱を招いた (automation, ai, Support)
    Denis_Kovalenko は「AI を使用したトリアージ投稿」をテストし、一般ユーザー間の PM がスキャンされていないことを発見しました（Does AI triage automation scan DMs between regular users?、test details）。 RGJ は PM が監査ログに到達していないことを確認し、回避策として**「トピックタイプ」を「すべて」ではなく空欄のままにすること**を特定しました（ref）。この修正は即座に機能し（ref）、スレッドはより明確なオプションに関する UX 議論へと発展しました（ref、ref）。

  • 翻訳されたドイツ語の投稿に「AI コメント/思考プロセス」のテキストが含まれていたが、すぐに修正されました (ai, content-localization, bug, fixed)
    putty は、ドイツ語の翻訳出力に「思考/翻訳」に関するコメントが漏れ出ていることを報告しました（AI Commentary on German Translations）。 nat はフォーマットを厳格化するアップデートをリリースし、影響を受けたコンテンツを整理しました（ref）。その後、ユーザーから修正が確認されました（ref）。

  • Mistral による翻訳で、翻訳ビュー（upload:// リンク）の画像が欠落していたが、モデルのアップグレードで解決 (ai, content-localization, Support)
    Denis_Kovalenko は、翻訳モデルを OpenAI から Mistral に切り替えたところ、翻訳版がテキストは表示されるものの画像を省略してレンダリングされることを発見しました（Images missing in translated posts when using Mistral as translation model、behavior details）。 RGJ はプロンプトの強化や、より優れたモデルの試行を提案し（ref）、Mistral Small から Mistral Large への切り替えで問題が解決しました（ref）。その後、Falco はどの「Mistral Small」を指しているのか明確化を求め、必要に応じてより強力な小型クラスモデルの使用を推奨しました（ref）。

  • Mistral による埋め込み：OpenAI 互換設定が dimensions パラメータ名で破綻する (ai, #Feature)
    RGJ は、OpenAI 形式の統合を通じて Mistral 埋め込みを設定する場合、Discourse が dimensions を送信すると失敗することを記録しました。これは Mistral が output_dimension を期待しているためです（Use Mistral for embeddings）。パラメータを削除するとテストが成功することから、互換性レイヤーやプロバイダー固有のマッピングが必要であることが示唆されます（ref）。

  • AI ボットのエラーは廃止された Gemini モデル ID に起因し、画像生成モデルに関するガイダンスも提供 (ai, ai-bot, Support)
    ice.d は、レガシーなボット設定で「Not found」エラーに遭遇しました（Issue with AI bots forum bots）。 Lilly は gemini-2.5-flash-pre の廃止の可能性を指摘し、モデル URL/ID の更新（画像生成対応のものを含む）を提案しました（ref、config example）。また、NateDhaliwal は LLM が設定されているかどうかを確認しました（ref）。

  • AI ペルソナは @メンションへの返信のみを行うべきか？チームはニッチなトグルよりもワークフローを重視 (ai, ai-bot, #Feature)
    既存の機能リクエストにおいて、sam は、「@メンションへの返信のみ」を別の設定としてではなくデフォルトとするべきかどうかを疑問視しました（Allow AI Persona/Agent to respond only to @mentions…）。 Falco は、エッジケースは今後のプロジェクトワークフローで対応する方が良く、例えばメンショントリガーのワークフローで挙動を制御できるため、さらに多くのスイッチを追加する必要はないと主張しました（ref）。

  • エージェントの応答遅延：ワークフローがタイミング制御をカバーすると予想される (ai, Support)
    sam は、AI エージェントの応答に対する設定可能な遅延は、ワークフローが対応すべき事項であると指摘しましたが、即座には実装されない可能性があると述べました。それ以外の場合は、API 経路でのカスタム開発が必要となります（Adding a configurable delay to AI Agent responses）。

  • ユーザーレベルの AI 制御（「AI ナッジを無効化」）と PM 翻訳設定の移行 (ai, ai-summarize, content-localization, ux/#Feature)
    paco は、discourse_ai_enabled のユーザー別同等機能があれば、サイト全体で AI を無効化することなく、ユーザーが AI の UI ナッジをオプトアウトできるだろうと主張しました（User Interface Preferences: include setting to disable AI nudges）。別途、翻訳設定の変更は個人メッセージを中心に進化を続けており、nat は移行 PR をリンクし、以前の「公開コンテンツのみ」の設定が新しいカテゴリ＋PM ターゲティング制御にどうマッピングされるかを説明しました（AI translation of all PMs）。

アクティビティ

お読みいただきありがとうございます。また来週お会いしましょう！:slight_smile:

118

概要

今週の Meta における AI 関連の活動（2026-04-06 → 2026-04-13）は、実用的な統合の詳細に焦点が当てられました。特に、AI 検出ファイル、GDPR 対応環境におけるプロバイダー/モデルの選択、そして翻訳の堅牢性に関する議論が中心でした。

「AI 検出」の分野では、コミュニティの llms.txt 生成用 ai #Plugin と、Discourse コアに実装された比較的新しく（現時点では限定的な）ネイティブ llms.txt ルーティングとの間で、現実的な競合が発生しました。
pacharanero さんは、このオーバーライド動作を :robot: Discourse llms.txt Generator Plugin で報告し、Ivan_Rapekas さんが 同じスレッド で不具合を確認しました。その後、kaktak さんが フォローアップ で、プラグインの動作を復元するアップデートを実施することを約束しました。関連する文脈は、ネイティブサポートに関するコアディスカッション enabling native llms-txt support in Discourse にも転載されました。

並行して、埋め込み（embeddings）や翻訳におけるモデル/プロバイダーの選択、特に EU/GDPR との強い整合性を必要とするコミュニティにとって重要な課題として、引き続き重点が置かれました。
Use Mistral for embeddings では、Falco さんが動作する設定を共有し、より強力な埋め込みモデルの検討を提案しました。また、Images missing in translated posts when using Mistral as translation model では、コンプライアンスとリスクの観点から許容される選択肢を決定する際に、プロバイダーオプションや「ゼロデータ保持（zero data retention）」が浮上しました。

最後に、翻訳の品質に関する問題は非常に「実践的」なレベルで取り扱われました。新しいバグレポートで、翻訳後の「cooked/markup エラー」が報告され、Moin さんがこれを Markdown テーブルの書式設定に起因するものと特定しました。ソースとなるテーブルを修正することで、Cooked error after translate における翻訳出力が解決し、cuo_wu さんが 解決 を確認しました。

製品利用の側面では、管理者が引き続きAI ペルソナ/エージェントの動作制御を探求しました。具体的には、エージェントが即座に返信するのを止めさせ、返信を「メンションのみ」のパターンに制限する方法です。この議論は、Allow AI Persona/Agent to respond only to @mentions, not to replies to its posts と、Adding a configurable delay to AI Agent responses で共有された回避策を結びつける形となりました。

興味深いトピック

  • llms.txt ルーティング競合：コア対プラグインの動作 (ai #Plugin)
    pacharanero さんは、Discourse コアの新しいネイティブ llms.txt ルートが、設定されていない場合でも /llms.txt をオーバーライドしているように見えると指摘しました。これにより、プラグインの主要エンドポイントが失敗する一方で、/llms-full.txt は機能しているという状態が発生しています（:robot: Discourse llms.txt Generator Plugin）。
    Ivan_Rapekas さんも同様の症状を確認し（同じスレッド）、この報告をコア機能の議論 enabling native llms-txt support in Discourse へとリンクさせました。
    kaktak さんは、コアがプラグインの動作をオーバーライドしないようアップデートをリリースすると述べました（プラグインスレッドの更新）。
    参照用として、プラグインのトピックは :robot: Discourse llms.txt Generator Plugin、コア機能のトピックは enabling native llms-txt support in Discourse にあります。

  • 埋め込みプロバイダーの選択：Mistral と高スコアな代替案の比較 (ai #Feature)
    Use Mistral for embeddings では、Falco さんが動作する設定を共有し、ベンチマークでより良い結果を出す埋め込みモデル（Qwen ベースの埋め込みオプションを含む）を検討することを推奨しました。より広いスレッドでは、Mistral が一部のデプロイメント（GDPR 志向のものを含む）にとって重要であるという文脈が描かれています：Use Mistral for embeddings。

  • 翻訳モデルの動作：Mistral 使用時の画像欠落とプロンプト調整 (ai content-localization)
    翻訳された投稿から画像が消えてしまうという問題の調査は、Images missing in translated posts when using Mistral as translation model で続行されました。
    Denis_Kovalenko さんは、Mistral の API を選択する動機として GDPR を強調しました（投稿）。
    Falco さんは、「ゼロデータ保持」の推論プロバイダーオプションを指摘しました（投稿）。
    RGJ さんは、ZDR（ゼロデータ保持）が自動的に GDPR 準拠を意味するわけではないと明確にし、この症状はサードパーティ製モデルの機能とプロンプト設計によって引き起こされている可能性があると示唆しました（投稿）。
    スレッドは実用的な解決策で終了しました：Denis_Kovalenko さんがプロンプトを改善し、Mistral Small が画像を削除するのを止めることに成功しました（投稿）。
    完全なスレッド：Images missing in translated posts when using Mistral as translation model。

  • 新しいバグレポート：「翻訳後の cooked エラー」が Markdown テーブルの書式設定に起因 (ai bug)
    今週、新しいトピックが登場しました。
    cuo_wu さんが、言語切り替え後に翻訳/レンダリング（cooking）の問題が発生したと報告しました（Cooked error after translate）。
    Moin さんが、Markdown テーブルの先頭/末尾の | 文字が欠落している場合、元の言語では許容されても、翻訳されたレンダリングでは破綻してしまうことを特定しました。英語側のテーブルを修正することで、翻訳も正常に動作するようになりました（診断 + 例）。
    cuo_wu さんが修正を確認しました（確認）。
    このレポートは、影響を受けるマークアップを示すために Discourse FontAwesome Pro のコンテンツを参照していました。

  • エージェントの動作制御：ボットを @メンションのみに制限（返信トリガーのループ回避） (ai ai-bot)
    Allow AI Persona/Agent to respond only to @mentions, not to replies to its posts では、saurabhmithal さんが、「メンションのみ」の制御を、ボットへの返信があるたびにエージェントが即座に返信してしまうのを防ぐというより広範な目標と結びつけました。この根本的な課題は、Adding a configurable delay to AI Agent responses でも議論されています。

  • 遅延したエージェント応答の回避策：外部オーケストレーターボット＋スケジュール付きタグ付け (ai)
    saurabhmithal さんが、ボットが「自動補完のようにではなく、ペース配分された参加者として」振る舞いたいコミュニティ向けの実装パターンを共有しました。これは、外部の「オーケストレーター」ボット（例：cron で実行）を使用してカテゴリを定期的にチェックし、その後エージェントにタグを付けるという方法です。さらに、人間が直接即座のボット返信をトリガーできないようにグループ制限を組み合わせます（Adding a configurable delay to AI Agent responses）。
    このアプローチは、関連するメンションみの制御に関する議論からも再度参照されました（Allow AI Persona/Agent to respond only to @mentions…）。

  • ペルソナ設定のリクエスト：Discourse 文脈を無視する「標準的なチャット AI」の作成 (ai ai-bot)
    New AI Persona Editor for Discourse では、Alon1 さんが、汎用的なチャットボット（例：claude.ai に類似）のように振る舞うペルソナを設定する方法を尋ねました。具体的には、Discourse の投稿やユーザー詳細を検索せず、Discourse に埋め込まれていることさえ認識しないように設定したいという要望です。
    スレッドの根元：New AI Persona Editor for Discourse。

  • Discourse MCP デプロイメントの使いやすさ：「推奨される」サイドカーアプローチは？ (ai mcp)
    Discourse MCP is here! では、pacharanero さんが、MCP をサイドカーサービスとして実行するための Meta 推奨の方法があるかどうかを尋ね、また Falco さんが言及した「編集ツール」の追加についても触れました。
    スレッドの根元：Discourse MCP is here!。

  • コンプライアンスの微妙な点：「ゼロデータ保持」対 GDPR 準拠（およびセルフホスティング） (ai)
    今週は繰り返されるテーマとして、プロバイダーの選択は機能性だけでなく、コミュニティが正当に運用できるかどうかにかかっているという点が浮き彫りになりました。
    Images missing in translated posts when using Mistral as translation model では、RGJ さんが ZDR ≠ GDPR 準拠であると強調しました。
    一方、Falco さんは、多くの ZDR プロバイダーオプションが存在することを強調し（同じスレッド）、埋め込みはフル LLM よりもセルフホスティングが容易であることが多いと述べました（Use Mistral for embeddings でも同様の意見が共有されました）。

活動

  1. /llms.txt ルーティングにおけるコアとプラグインの競合を :robot: Discourse llms.txt Generator Plugin で文書化（スレッドの根元：:robot: Discourse llms.txt Generator Plugin）。
  2. Discourse MCP is here! で推奨される MCP サイドカーデプロイメントに関するガイダンスを要請（スレッドの根元：Discourse MCP is here!）。

お読みいただきありがとうございます。また来週お会いしましょう！:slight_smile:

119

概要 (2026-04-13 → 2026-04-20)

今週の meta.discourse.org における AI 関連の議論は、翻訳の信頼性とローカライズワークフローに集中しており、bug と Support スレッドで #ai、#dynaloc、content-localization タグが主に使用されました。最大のテーマは、言語がランダムにスキップされたり、バックエンドエラーが発生したりする、再現が難しい断続的な翻訳の失敗でした。これに対し、非表示の詳細ログの有効化や /logs の確認などのデバッグ提案がなされました（AI 翻訳がポルトガル語 (pt) ロケールをスキップ、続報のデバッグ、バックエンドエラー報告を参照）。

また、外部設定の問題（古い API キーなど）により翻訳が「壊れた」ように見える場合の、言語検出と手動オーバーライドに関する実用的なサポートスレッドもありました（ドイツ語と英語が混在するタイトルなど）（投稿がドイツ語として検出されないと解決策を参照）。別途、管理者限定のロケール切り替えエラーは、Chrome 内の古いテーマプレビュークエリパラメータが原因であることが判明しました（ロケール切り替え時のエラーと修正を参照）。

「AI プラットフォーム」側では、Discourse MCP の接続性（Claude コネクタや HTTP の可用性を含む）への関心が再燃しました（Discourse MCP が登場！、および HTTP がサポートされていることの確認を参照）。最後に、長年続いている AI エージェントの使い方スレッドに、カスタマイズされたシナリオ向けのカスタムエージェントスキルに関する新しい質問が寄せられました（AI ボット - エージェントを参照）。

トレンドライン: 今週の「AI の問題」の大半は出力の品質に関するものではなく、運用上の堅牢性（ジョブの動作、リトライ、バックエンドの可用性、設定の可視性）に関するものでした（例：スキップされた翻訳、詳細ログ、リトライ動作に関する質問）。

興味深いトピック

  • bug で、AI 翻訳がロケールを断続的にスキップ（当初はポルトガル語の欠落として観測）
    Denis_Kovalenko 氏は、多くのロケールを有効化するとポルトガル語が生成されない（その後：任意のロケールがランダムにスキップされる）可能性があり、タイトルと本文の翻訳が一貫しないことを報告しました（元の報告：AI 翻訳がポルトガル語 (pt) ロケールをスキップ、設定の明確化：サポートされるロケールに関する質問、および「ランダムにスキップされるロケール」の更新：一貫性のない結果を参照）。
    デバッグはログと内部実装の詳細へ移行しました：nat 氏は /logs を確認し、非表示の ai_translation_verbose_logs 設定を有効にするよう提案しました（非表示の詳細ログの提案を参照）。その後、RGJ 氏はタグ/トピック/投稿に影響を与えるバックエンドの失敗（503 unreachable_backend）を表面化させました（エラー出力を参照）。スレッド内では、なぜ翻訳ジョブが retry: false で設定されているのかという実装上の疑問も提起されました（リトライに関する質問を参照）。

  • AI 翻訳のログトラブルシューティングに非表示設定を使用
    Denis_Kovalenko 氏が管理者検索で ai_translation_verbose_logs が見つからない場合（設定が見つからないを参照）、Moin 氏はこれが非表示サイト設定であるため予想されることだと説明し、非表示設定に関するドキュメントを指し示しました（非表示設定ドキュメントへの案内と参照ガイド：非表示サイト設定の使用を参照）。その後間もなく、RGJ 氏が調査を支援するためにこの設定を有効にしました（詳細ログの有効化を参照）。

  • 多言語混在投稿は検出を混乱させる可能性があるが、手動言語選択は検出を強制する Support
    putty 氏は、ドイツ語の投稿が翻訳されない事例を共有し、ドイツ語を選択することで言語が強制されるかどうかを尋ねました（問題報告を参照）。Falco 氏は、言語を選択することがまさにその通りであり、投稿が英語とドイツ語が混在しており、英語のタイトルが検出に影響を与えていると確認しました（確認＋説明を参照）。

  • 翻訳が「機能しない」のは機能自体ではなく設定（API キー/プロバイダー）に起因することが判明
    同じスレッドにおいて、putty 氏は強制しても翻訳が反映されないのを当初確認し（翻訳の強制が役立たなかったを参照）、後に翻訳されたタイトルが欠落しているというエラーに気づきました（タイトルの欠落エラーを参照）。最終的に、翻訳者設定（Claude プランの切り替え中の古い API キー）を修正し、CDCK の LLM に戻したところ問題が解決し、タイトルの翻訳が機能するようになりました（解決策を参照）。

  • コンポーザー UX の変更：ロケール選択器がコンポーザーツールバーに移動
    Moin 氏は、言語ドロップダウンがコンポーザーツールバー内に移動したことを明確にし、コアの変更と関連付けて説明しました（前後のスクリーンショット＋PR 参照を参照）。これは翻訳ワークフローと手動入力に関する議論の中で取り上げられました（続報の好まれる設定に関する議論を参照）。

  • 管理者限定の「トピックが存在しない/プレビューテーマ」エラーは、古い preview_theme_id が原因
    Denis_Kovalenko 氏は、管理者限定の問題を報告しました：トピック内でインターフェース言語を切り替えると、存在しないテーマをプレビューするという恒久的なエラーが表示されます（報告を参照）。pmusaraj 氏は、Chrome 内の ?preview_theme_id=ID パラメータが固定されていることが原因と診断しました（診断を参照）、これを取り除くことで問題が解決しました（解決確認を参照）。

  • 翻訳の品質と制限：投稿サイズ/コンテキストウィンドウ、およびモデルの推奨事項
    断続的な翻訳の欠落をデバッグしている際、nat 氏は、タイトルは翻訳されたが本文はスキップされた別のシナリオについて言及し、本文のサイズに起因すると指摘しました。また、LLM のコンテキストウィンドウ設定を確認するよう提案し、顧客からのフィードバックと初期テストに基づき、翻訳に「GPT mini」を使用しないことを強く勧めました（モデル＋サイズ/コンテキストに関する注記を参照）。Denis_Kovalenko 氏は、非常に大きなコンテキストウィンドウを設定していたことを確認しました（コンテキストウィンドウの詳細を参照）。

  • Discourse MCP 接続性：Claude.ai コネクタサポートの要望；HTTP は既にサポート済み
    MCP に関する blog スレッドで、putty 氏は、Claude.ai Chat でコネクタとして使用するために、Discourse MCP サーバーの HTTP/SSE ストリーミング版がリリースされるかどうかを尋ねました（質問を参照）。Falco 氏は HTTP サポートが既に存在すると回答し、発表スレッドの以前の返信を指し示しました（HTTP サポート対応の回答を参照）。

  • AI エージェントの拡張性：AI ボットエージェントでのカスタムスキルに関する要望
    赤丸的小烧酒 氏は（中国語で）、エージェントが異なるシナリオの返信のためにカスタムスキルを追加できるかどうかを尋ね、独自の AI エージェントの動作をカスタマイズできる能力を求めました（カスタムスキルに関する要望を参照）。

アクティビティ

  • Denis_Kovalenko 氏は今週、2 つのローカライズ/AI トラブルシューティングスレッドを主導しました：

  • pmusaraj 氏は診断と設定原因の特定に注力しました：

  • nat 氏は機能レベルのデバッグガイダンスとモデルの注意点を提供しました：

    • AI 翻訳がポルトガル語 (pt) ロケールをスキップで /logs の確認と非表示詳細ログの有効化を提案し、この深掘りでサイズ/コンテキストウィンドウの考慮事項とモデル推奨事項について議論しました。
    • 投稿がドイツ語として検出されないで、無関係なコミットという仮説に異議を唱え、使用されている LLM について尋ね、文脈的に Gemini の廃止を指摘しました（同じ返信内）。
    • ドイツ語検出スレッドが解決した後、別の問題報告のために新しいトピックを作成するよう要請しました（要請を参照）。

  • RGJ 氏はデバッグの実用化を支援し、具体的な失敗シグナルを表面化させました：

  • Moin 氏はドキュメントを指し示し、ローカライズワークフローに影響する UI 変更を明確にしました：

  • putty 氏は翻訳サポートと MCP 議論全体で大きく貢献しました：

  • Falco 氏は使用に関する質問に答え、MCP の機能を明確にしました：

  • canbekcan 氏は翻訳ワークフローの問題と最近の変更に関する仮説を探求しました：

    • 投稿がドイツ語として検出されないで「まず言語を選択し、その後タイトル/コンテンツを追加する」というワークフローを提案し、言語オプションを再作成する必要があると説明しました。
    • この返信で「タイトルの欠落」問題を調査し、当初はテーマ関連の動作を疑いましたが、その後エラーを再現でき、この投稿で最近のコード変更を参照しました。
    • この注記で、AI 翻訳を使用していないこと（学術要件のため）を明確にし、UI 明確化後に参加を終了しました。

  • 赤丸的小烧酒 氏は、AI ボット - エージェントでカスタムスキルを通じたエージェントの拡張性について尋ねることで、AI エージェントの製品方向に関する質問を追加しました。

お読みいただきありがとうございました。来週またお会いしましょう！:slight_smile:

120

概要

今週の meta.discourse.org 上の AI 関連の議論は、Discourse の AI 機能をより信頼性が高く、自動化しやすく、外部 LLM ワークフローとの統合コストを低く抑えることを中心に集約されました。信頼性の面では、管理者らが「翻訳がスキップされる」または「停止したように見える」原因（一時的なプロバイダーの障害やレート制限など）を掘り下げ、詳細ログの有効化や監査/ログテーブルの確認といった実用的なデバッグ手順を議論しました（AI 翻訳がポルトガル語 (pt) ロケールをスキップする、LLM が変更されたとき翻訳はどうなるか？）。自動化の側面では、AI トライジと Discourse 自動化を用いたトピックの自動タグ付けに関する新しいハウツーガイド（AI を用いたトピックのタグ付け）と、エージェントの「例（Examples）」がどのように解釈され、誤って過剰なフラグ付けを引き起こす可能性があるかについての深い分析（AI トライジの例が正しく送信されていない？）が話題となりました。最後に、統合と効率化については、マークダウン形式で調理済みコンテンツを提供する新しいプラグインが登場し、後続の LLM 利用におけるトークンコストを削減するとともに、API/MCP 利用との親和性も高まりました（Discourse to Markdown プラグイン、Discourse to Markdown プラグイン）。

興味深いトピック

アクティビティ

今週言及された追加の参照リンク（上記スレッドの文脈）

これらは今週の議論内で直接参照され、周辺エコシステムを理解するのに役立ちます：Discourse AI プラグイン、Discourse 自動化、LLM 設定ガイド、AI ボットペルソナ/エージェント、Discourse MCP が登場、Discourse Chatbot は ChatGPT より賢くなった、および参照された AI 検索 500 スレッド（すべての AI 機能は正常に動作しているが、AI 検索で 500 エラーが発生する）。

お読みいただきありがとうございました。来週またお会いしましょう！:slight_smile:

121

概要

今週のMetaでのAI関連の議論は、新しいUXと自動化ワークフローの磨き上げ、およびAI支援による編集や翻訳における正確性の保証の強化に焦点が当てられていました。

最も活発だったスレッドは、新しいドッキングされたAIコンポーザーの実際のバグハンティングでした。 Lillyは、New ai docked composerにおいて、編集、引用、モバイルスクロール、ファイルアップロードに関する問題を文書化し、keeganは修正を迅速に実施し、機能の改善が進むまでその機能を制限しました（更新情報）。並行して、AIヘルパーの校正フローでは、引用されたテキストの保持について議論がありました。特に機密性の高い引用や正確な引用においてこれは重要であり、修正が適用されたこと、および追加の設定提案が行われたことが確認されました（Proofread breaks quotes、例示に関するガイダンス）。

運用面では、管理者たちがLLMのレートリミットや設定に関する質問により、翻訳ジョブが「停止」する件について情報を交換しました（What happens to translations when LLM changes?）。また、導入支援の面では、Discourse AIのトリアージとDiscourse Automationを組み合わせることでトピックを自動分類する方法を示す新しいハウツーが公開されました（Auto-categorize topics using AI）。さらに、プラグインの議論では、text/markdownを配信してAI/MCPの消費者をより満足させる方法が探られました（Discourse to Markdown Plugin）。

興味深いトピック

  • ドッキングされたAIコンポーザーの回帰バグと迅速な修正（#Bug、#ai、composer）： Lillyは、新しいドッキングされたコンポーザーが編集アクションをブロックしたり、引用時に奇妙な動作をしたり、通常のコンポーザーと比較して不整合が生じたりする可能性があると報告しました。特に改行に関する部分で顕著でした（報告、Shift+Enterに関するフィードバック）。 keeganは複数の修正とフォローアップを行い、意図された動作と次のステップを説明しました（修正の概要、機能制限の発表）。

  • ドッキングされたコンポーザーにおけるRTEファーストの設計判断（Markdownはサポートされるが、プレビューなし）： ドッキングされたコンポーザーは主にRTE（リッチテキストエディタ）を意図しており、Markdownはスペースの制約によりプレビュー機能なしで利用可能であることが明確にされました（設計の解説、確認）。

  • ボットUIとのインタラクション時の引用、サイドバー、ナビゲーションのエッジケース： ボットを引用すると、サイドバーの隙間やUIの消失、さらにはユーザーがボットの会話に閉じ込められる原因となることが指摘されました。その後、修正により改善されました（初期の動作、その後の状況）。

  • ドッキングされたコンポーザーでの最初の投稿以降のファイルアップロード失敗： 他の問題が改善された後、Lillyは、残っている問題が最初の投稿以降のアップロード失敗と、一時的な引用の問題に限定されていることを突き止めました。これらはその後、ビルドの再実行により解消されました（バグ報告、トリアージの更新、メンテナの返信）。

  • AI校正は引用されたテキストを「改善」してはならない（#Bug、ai-helper）： bksubhutiは、AIが宗教的またはソーステキストの引用を変更するリスクを指摘し、引用はそのままの状態で保持すべきだと主張しました（懸念事項）。 Falcoは、この問題は修正済みであり、もし再発する場合はより良いモデルを試すよう提案しました（修正の参照）。

  • 例示と専門的なペルソナを用いた校正エージェントの設定： bksubhutiは、パーリ語指向の専門的なペルソナプロンプトを共有し、エンジン選択について質問しました（ペルソナの詳細）。一方、Falcoは、例示を使用しているかどうかを尋ね、デフォルトの校正機能には引用処理を安定させるための複数の例が含まれていることに言及しました（例示に関する提案）。

  • レートリミットによる翻訳ジョブの停止と「思考（thinking）」設定に関する混乱（#Support、ai）： 翻訳のトラブルシューティングスレッドで、Falcoは「思考」を無効にするよう提案しました。一方、RBoyは、Discourse AI UIにおいてそれが何を意味するのかを尋ね、1日あたりのトークン数によるレートリミットが原因で繰り返し失敗するエラーを共有しました（提案、レートリミットエラー、UIに関する質問）。

  • AI/MCPの消費に最適化されたMarkdown配信（#customization:plugin、#markdown、ai）： Discourse-to-Markdownプラグインのスレッドでは、AIクライアント向けのクリーンなパスとして「コンテンツネゴシエーション」が探られました。正規のURLに対して Accept: text/markdown を試し、サポートされていない場合はJSON APIの動作にフォールバックするというアプローチです（提案、フォローアップ）。同じ議論では、これがMCPの使用に明示的に結び付けられています（Discourse MCP is hereも参照）。

  • AI生成画像の品質向上（およびプロンプト共有への関心）： 長期にわたるサポートボットの議論で、37Rbは、以前の試みと比較して画像生成の品質に大きな向上があったと指摘しました（体験談）。 EricGTは、プロンプトやヒントをより広く共有するよう促しました（リクエスト）。

  • 新しいハウツー：AIトリアージとDiscourse Automationを使用してトピックを自動分類する（#Site_Management、#automation、ai）： Discourseは、AIを使用してトピックが別のカテゴリに属するかどうかを決定するためのガイドを公開しました。ここでは前提条件（Discourse AI、Automation、設定されたLLM、およびエージェント/ペルソナ）と全体のワークフローが詳細に説明されています（ガイド；前提条件の参照：Discourse AI、Discourse Automation、LLM設定ガイド、AIボットペルソナ）。

アクティビティ

  • Lillyは、ドッキングされたAIコンポーザーの詳細なQAパスを主導し、初期の障害を文書化し（New ai docked composer）、進行中の修正を認め（フォローアップ）、その後、引用やアップロードなどの残りの問題を絞り込みました（状況、再実行結果）。彼女は、「最初の投稿後のアップロード」回帰を主要な残りのバグとして浮き彫りにしました（報告）。

  • samは、ドッキングされたコンポーザーに関するフィードバックループを認め、修正が actively 進行中であることを伝え、keeganによる継続的な作業を指摘しました（返信）。

  • keeganは、ドッキングされたコンポーザーの修正を実装・調整し、意図されたRTEファーストのUXとMarkdownのトレードオフを説明しました（解説）。その後、修正が継続される中、今後の変更までその機能を制限しました（更新情報）。

  • bksubhutiは、正確性と倫理の観点から問題を提起しました。AI校正は、特に正確な宗教的またはソースの引用において、引用ブロックを保持しなければならないと主張しました（懸念事項）。更新後、動作を確認し、実験を続けました。これには、カスタム校正ペルソナの共有やモデルの提案依頼が含まれます（確認、テスト、ペルソナプロンプト）。

  • Falcoは、2つの領域で標的を絞ったトラブルシューティングを提供しました。彼は、校正/引用処理に関する修正を指摘し、問題が持続する場合はより良いモデルを試すよう推奨しました（Proofread breaks quotes）。また、エージェントを安定させるための例示の使用について質問し（例示）、翻訳動作の問題に対処するために「思考」を無効にするよう提案しました（What happens to translations when LLM changes?）。

  • RBoyは、実際の翻訳運用上の苦痛を共有しました。彼らは、1日あたりのトークン数によるレートリミットのために翻訳試行が繰り返し失敗していることを共有し、Discourse AIの設定UIにおいて「思考」が何を指すのかを尋ねました（エラー報告、明確化の質問）。

  • benwordは、Discourse-to-MarkdownプラグインがHTTPコンテンツネゴシエーションを通じてAI/MCP消費者をサポートする方法について展開し、実用的な「Markdownを試して、失敗したらJSONにフォールバックする」という戦略を概説しました（Discourse to Markdown Plugin）。これにより、MCP統合の可能性にも言及しました（関連: Discourse MCP is here）。

  • jrgongは、提案された「コンテンツネゴシエーション後にフォールバックする」というアプローチが、実際にもう一つのLLM（Claude）によってすでに実装されていたことを確認しました（返信）。

  • 37Rbは、以前の試みと比較してアーティファクトが少なくなったなど、AI画像生成の大幅な改善に関するポジティブなフィールドフィードバックを共有しました（サポートボットの議論）。

  • EricGTは、37Rbの結果に基づいて、プロンプトの共有やヒントを求めることで、コミュニティの学習を促進しました（リクエスト）。

  • Discourseは、AIトリアージを使用してトピックを自動分類するための新しい管理者向けガイドを公開しました。ここでは前提条件とセットアップの参照が明示的に文書化されています（Auto-categorize topics using AI；関連ドキュメント：Discourse AI、Discourse Automation、LLM設定ガイド、AIボットペルソナ）。

お読みいただきありがとうございました。また来週お会いしましょう！ :slight_smile:

122

概要

今週（2026-05-04 → 2026-05-11）の meta.discourse.org における AI に関する議論は、ai 翻訳の運用上の信頼性に集中しました。特に、「思考/推論」モデルがロケール検出を破綻させ、完了予算を枯渇させ、翻訳ジョブを混乱させる方法で停止または失敗させる問題についてです（AI 翻訳エラー および LLM が変更された場合、翻訳はどうなるか？ を参照）。もう一つのデバッグの焦点は、トークン制限の驚き（リクエストサイズ対レスポンスサイズ、TPM/TPD レート制限）と、それらが Discourse AI の LLM 設定とどのように相互作用するかという点でした（AI が LLM トークン閾値をランダムかつ予測不可能に超過する を参照）。

UX/設定の側面では、より小規模ながら実用的な更新がありました。引用処理のための校正プロンプトのカスタマイズ（校正が引用を壊す を参照）、PM/エージェントのフォローアップ画像アップロードの回帰（すでに上流で修正済み）（PM 経由のエージェントフォローアップで画像を投稿できない を参照）、そして LLM 設定ページでの Google Gemini モデル設定に関する新規ユーザーの質問（Discourse AI - 大規模言語モデル (LLM) 設定ページ を参照）です。

全体として：3 つの新しいトピックで 26 の新しい投稿があり、活動の大部分はFalco とRBoy によって行われました。主に bug と Support のスレッドで ai タグが付いたもの（例：AI 翻訳エラー、AI が LLM トークン閾値をランダムかつ予測不可能に超過する、PM 経由のエージェントフォローアップで画像を投稿できない）です。

興味深いトピック

  • 「思考」出力が完了予算を消費することで引き起こされる翻訳の失敗
    RBoy は、AI 翻訳エラー において Validation failed: Raw can't be blank, Cooked can't be blank のような翻訳エラーを報告しました。Falco は、推論トークンが max_tokens の下で「すべてのトークンを消費」し、空または無効な出力につながることを特定しました（文脈内の分析）。デバッグの議論では、なぜ Discourse が翻訳に推論を避けているか（同じスレッド）や、大規模な翻訳失敗に関する過去の経緯（関連する議論）にも触れました。

  • LLM 変更後に「停止」する翻訳：思考モデルではロケール検出が不安定
    LLM が変更された場合、翻訳はどうなるか？ において、RBoy は、新しいログや進行状況が表示されないまま翻訳が完了していないように見える状況を説明しました（停止症状）。Falco は根本的な問題を説明しました。思考モデルをロケール検出に使用することはできません。なぜなら「思考ブロック」がパースを破綻させ、ロケール検出がなければ翻訳が進まないからです（根本原因の説明；結論はフォローアップで認められました）。

  • 翻訳モデルに対する構造化出力の要件（例：json_schema）
    推論モデルから非推論モデルに切り替えた後、RBoy は、選択されたモデルが response_format: json_schema をサポートしていないことを示す 400 エラーに遭遇しました（エラー報告）。Falco は、翻訳には構造化出力をサポートするモデルが必要であると明確にしました。「基本的に最近リリースされたすべての最先端モデル（SotA）」が該当します（ガイダンス）。

  • 実用的な翻訳デバッグ：/p/POST_ID と監査ログを使用するが、response_tokens でフィルタリングしない
    Falco は、失敗した投稿を /p/120 で確認し、ai_api_audit_logs を調査することを助言しました（デバッグアプローチ）。RBoy が一致する監査行を確認できなかった場合（クエリと不一致）、Falco は SQL フィルタから response_tokens 句を削除することを推奨しました（修正）。スレッドでは、調査中の /p/ と /t/ の違いも明確にされました（フォローアップ）。

  • トークン制限の混乱：413 エラーは「最大出力トークン」ではなくリクエストサイズを示す
    RBoy は、出力トークン上限を下げたにもかかわらず、ランダムにトークン制限超過が発生したと報告しました（初期報告）。Falco は、413 はリクエストが大きすぎることを示す（要求されたレスポンスではない）と強調し、LLM の「コンテキストウィンドウ」設定に焦点を当てるよう提案しました。また、現代の基準では 8k は異常に小さいとも指摘しました（明確化）。RBoy は設定されたコンテキストウィンドウとプロバイダーの制限を返信し、なぜ Discourse が設定された境界を超えてしまうのかと疑問を呈しました（詳細）。

  • 翻訳の不安定さの上流要因としてのレート制限圧力（TPD/TPM）
    同じトークンスレッドにおいて、RBoy は、翻訳パイプラインが最初は日次トークンレート制限（429）で停止し、再開後に 413 リクエスト过大エラーで失敗したと指摘しました（失敗の順序）。これは、LLM が変更された場合、翻訳はどうなるか？ および AI 翻訳エラー での継続的な翻訳トラブルシューティングと関連していました。

  • 校正のカスタマイズ：引用の動作を調整するための組み込み例の場所 (ai-helper)
    bksubhuti は、引用を壊さないように独自の校正パーソナリティを調整するために、どこで例を見つけられるか尋ねました（質問）。Falco は、管理 UI 内の校正エージェントの例（admin/plugins/discourse-ai/ai-agents/-22/edit）を指し示しました（案内）。bksubhuti は例セットを見つけ、それが JSON を出力することを確認しました（確認）。

  • PM エージェントのフォローアップで画像を投稿できない（上流で修正済み）
    Ethsim2 は、2026.5.0 で PM 経由のエージェントへのフォローアップ時に画像を投稿できないと報告しました（バグ報告）。Lilly は、すでに修正済みであり（関連する不完全な報告にも言及）、返信しました（応答）。Ethsim2 は必要な不足している上流コミットを特定しました（フォローアップ）。（関連：新しい AI ドッキングコンポーザー。）

  • 新しい LLM 設定の質問：Gemini モデル ID / プロバイダー URL の混乱
    danhanghai は、LLM 設定ページで Google プロバイダー経由で gemini-3.1-flash-lite を設定する助けを求め、モデル ID とエンドポイント URL を共有しました（質問）。より広い文脈として、この質問は長期間続いている参照トピック Discourse AI - 大規模言語モデル (LLM) 設定ページ (how-to ai) の中に位置しています。

活動

お読みいただきありがとうございます。来週またお会いしましょう！:slight_smile:

123

概要

今週の meta.discourse.org における ai に関する議論は、実用的な信頼性向上策を中心に展開されました。言語やロケールの検出、翻訳クレジットの活用方法から、些細な UX の不快感や自己ホスティングの設定問題まで多岐にわたりました。

ローカライゼーションの側面では、thomasjsn 氏により、ノルウェー語のコンテンツが no として検出され、その後 nb_NO に翻訳されてしまい、ほぼ重複するテキストが生成され、クレジットが浪費されているという報告がありました（Norwegian is identified as no by locale detector agent, content localization supported locales is nb_NO）。このスレッドはすぐにプロンプトレベルの回避策（投稿 5）へと発展し、その後 nat 氏によってコアおよびデフォルトエージェントの改善が確認されました（投稿 7）。

一方、Discourse AI の UI には小さくても目立つ改善が加わりました。RBoy 氏は、デフォルトの LLM を変更してもページをリフレッシュするまでエージェントのラベルが更新されないという不具合を発見しました（Minor UI bug changing default LLM）。これに対し awesomerobot 氏が修正 PR を提出しました（投稿 2）。

自己ホスティング環境のユーザーにとって有益なトラブルシューティングの機会もありました。NotAnonymous 氏が感情分析の設定中に Docker と Hugging Face で 404 エラーに遭遇しましたが、Falco 氏が有効な回避策を提供しました（Self-Hosting Sentiment and Emotion for DiscourseAI、投稿 15 を参照、投稿 16 で確認）。

最後に、いくつかの小さなフォローアップで今週を締めくくりました。Gemini の「思考予算」テスト制限に関するフォローアップ（Thinking budget for Gemini Pro, error when using 0 or -1）、「me too」/承認パターンの再燃と新しい solved 機能への言及（Option to hide ‘me too’ replies）、そして AI プラグイン内のハイパーリンクがクリックしても反応しないという中国語での新しい報告（社区官方的 ai 插件中的超链接未能正常跳转，点击后无反应）です。

興味深いトピック

  • ノルウェー語のロケール検出（no と nb_NO）による重複翻訳とクレジット浪費（bug ai）
    thomasjsn 氏は、ノルウェー語の投稿が no として検出され、その後ノルウェー語の nb_NO に翻訳されることで、微妙な差異はあれど主にコンテンツが重複してしまう現象を指摘しました（Norwegian is identified as no by locale detector agent, content localization supported locales is nb_NO）。nat 氏は、ロケール検出エージェントを複製してシステムプロンプトを調整することを提案しました（投稿 2）。これに対し thomasjsn 氏は明示的な言語コード行を追加することで検証しました（投稿 5）。nat 氏はその後、この回避策がデフォルトエージェントに組み込まれたことを確認しました（投稿 7）。これは（投稿 6）でのプロンプトガイダンスの後に行われました。

  • AI 設定 UI でデフォルト LLM のラベルがリフレッシュされるまで更新されない（ux ai）
    Minor UI bug changing default LLM において、RBoy 氏は、デフォルトモデルを変更してもページが再読み込みされるまで、エージェント行に古い「デフォルト LLM」のテキストが表示され続けることを示しました。awesomerobot 氏は、これは些細な問題ではあるが修正する価値があると同意し、PR を提出しました（投稿 2）。

  • 自己ホスティング環境での感情分析 Docker イメージが、上位モデルのアートファクトパス（404）により失敗する（#Self-Hosting ai ai-sentiment）
    NotAnonymous 氏は、Self-Hosting Sentiment and Emotion for DiscourseAI の自己ホスティング手順に従っている最中に、Hugging Face から tokenizer.json の 404 エラーに遭遇しました。Falco 氏は、上位モデルの変更がまだマージされていないことを説明し、ブランチを指し示すことを推奨しました（投稿 15）。これにより NotAnonymous 氏の問題は解決しました（投稿 16）。

  • 「me too」/承認ノイズとシグナル、solved 改善による部分的な回答（#Feature ai）
    「me too」返信の散らかりを減らすという長年の要望が、NateDhaliwal 氏が solved プラグインの変更を通じて似た機能が直近でリリースされたことを指摘したことで再浮上しました（Option to hide ‘me too’ replies）。参照されたリリーススレッドは Solved improvements: allowing members to indicate they’re experiencing a reported issue です。EricGT 氏は、その展開に関する議論で自身のコメントへの直接リンクをフォローアップしました（投稿 3、Solved improvements…（投稿 14） も参照）。

  • Gemini Pro の「思考予算」のエッジケースに関するフォローアップ（現在の使用状況なしでは確認困難）（bug ai）
    Thinking budget for Gemini Pro, error when using 0 or -1 において、sam 氏は問題がまだ発生しているか確認しました。RBoy 氏は、Pro モデルをもう使用していないためテストできなくなったと回答しました（投稿 6）。これは回帰状況を検証しようとする人々にとって有用な文脈です。

  • 中国語のバグ報告：AI プラグインのハイパーリンクがクリックしても反応しない（bug ai）
    ハ基米曼波 氏から 社区官方的 ai 插件中的超链接未能正常跳转，点击后无反应 で新しい報告が入りました。これはクリック可能に見えるが移動しないリンクに関するものです。NateDhaliwal 氏は返信しましたが、投稿は後に投稿者によって削除されました（投稿 2）。そのため、次の実行可能なステップには、新しい再現手順と環境詳細が必要になる可能性があります。

活動状況

お読みいただきありがとうございます。また来週お会いしましょう！:slight_smile:

124

概要

今週（2026-05-18 → 2026-05-25）の meta.discourse.org における AI 関連の活動は、主に「AI ボットとの会話をよりスムーズで管理しやすくする」ことに向けられており、加えて、AI 支援型メールワークフローにおけるローカライゼーションに関する継続的な運用上の懸念も取り上げられました。

製品面では、Discourse が AI チャット向けに 2 つの小さくても影響力のある UX 改善をリリースしました。重要なチャットをトップに固定しておくために AI 会話をスター（お気に入り）登録する機能（Star common AI conversations、Star common AI conversations にも言及）と、AI ボットトピックで入力ボックスを常時利用可能にして「返信の手間」を減らすドッキング型コンポーザー（Introducing a docked composer for AI bot conversations、Introducing a docked composer for AI bot conversations も参照）です。

一方、以前のスレッド #Feature が再浮上し、更新が求められました。翻訳サポートは依然として課題であり、特にユーザーが設定した言語でメールを受け取る際、モデレーションパイプラインのコメントやその他のカスタムテキストが翻訳されていないことが問題となっています（Use translated posts when emailing users with their user language set、Use translated posts when emailing users with their user language set にも言及）。

興味深いトピック

活動

ご一読いただき、ありがとうございます。また来週お会いしましょう！:slight_smile:

125

概要

今週（2026-05-25 → 2026-06-01）の meta.discourse.org における AI 関連の議論は、主に3 つのテーマに集約されました。

  1. AI 統合と自動化 — AI アーティファクトのデータが変更された際に外部の自動化をトリガーする「イベント駆動型」の AI 機能への関心が高まっています。Discourse AI アーティファクトのキーバリュー更新に対する Webhook/イベントサポートの追加（または管理者によるサンドボックス化の無効化を許可） におけるアーティファクト更新用 Webhook のリクエストについては、Discourse の今後の自動化方針（「ワークフロー」）が発表された後に再検討すべきだという前向きな反応 (返信) とともに、スコープを絞ったサーバーサイド Webhook の有用性に対する合意 (フォローアップ) が得られました。

  2. AI の UX とコンテンツの忠実度 — 複数のスレッドで、AI 関連の UX にはまだ手を入れるべき箇所があることが浮き彫りになりました。ドッキング型 AI ボット作曲者の「Enter キーで送信」の動作 (議論, 詳細)、翻訳出力が Markdown の引用構文を壊す問題 (バグ報告)、そしてボット/チャット文脈における完全な Markdown 対応への継続的な要望 (リクエスト継続) などです。

  3. ローカライゼーションとマルチモデルサポート — 言語とモデルの柔軟性に焦点を当てた投稿が複数ありました。AI プロンプトの中国語へのローカライズ要求 (リクエスト, 返信)、ユーザー向けメッセージングでの翻訳利用の進捗（ユーザー言語設定に応じた翻訳された「フラグ理由」が正しく表示されるようにする修正がマージされた）ユーザーの言語設定に基づいて翻訳された投稿をメール送信時に使用する、および Gemini などのより多くの LLM プロバイダーへの感情分析/感情分析の拡張 (質問, 更新) などです。

興味深いトピック

  • AI アーティファクト更新のための Webhook/イベントサポート（自動化＋統合） (#Feature ai webhooks ai-artifacts)
    MachineScholar 氏は、外部の自動化（例：n8n ワークフロー）を可能にするため、AI アーティファクトのキーバリューデータが変更された際に Webhook を発行することを提案しました (Add webhook / event support for Discourse AI artifact key-value updates (or allow admins to disable sandboxing))。
    Falco 氏は、新しい「ワークフロー」アプローチが導入された後に再検討すべきだと提案し (返信)、sam 氏はアーティファクト ID でスコープを絞れるサーバーサイド Webhook のアイデアを支持しました (コメント)。
    MachineScholar 氏はまた、ワークフローに関する情報やタイムラインをどこで追跡できるかについても尋ねました (フォローアップ)。

  • AI ボット会話用のドッキング型作曲者：「Enter キーで送信」の摩擦（およびアップロードの問題） (#Announcements ai ai-bot composer)
    AI ボット会話用のドッキング型作曲者の導入 において、Lilly 氏は「Enter キーで送信」を無効化し、紙飛行機アイコンでのみ送信できるようにするオプションを要望しました (投稿)。
    tobiaseigen 氏はこれに同意し、AI 会話とは常に「雑談」ではなく、段落やコードブロックが必要な場合が多いと指摘しました。また、チャット設定に関する回避策を挙げつつも、リアルタイムチャット利用におけるトレードオフについても言及しました (投稿)。
    その後、Lilly 氏は最初の投稿後に画像アップロードが機能しなくなったと報告し、ボット利用については通常の作曲者に戻したと述べました (投稿)。

  • メール/通知内の翻訳済みコンテンツ：ロードマップと「フラグ理由」の翻訳表示に関する修正のマージ (#Feature ai activity-summary dynaloc content-localization)
    ユーザーの言語設定に基づいて翻訳された投稿をメール送信時に使用する スレッドにおいて、pmusaraj 氏は OP（最初の投稿）がまだロードマップにあるものの、タイムラインは未定であることを確認しました (投稿)。
    関連する UI 文字列を明確にする際、Bart_Veldhuizen1 氏は「カスタム備考」が実際には「その他」フラグタイプであることを説明し、レビューキューでポルトガル語で表示される一方、DM では正しく翻訳されていた様子を示しました (詳細)。
    pmusaraj 氏はこの翻訳問題に対する修正をマージし (更新)、関連する PR を参照しました：議論への言及。

  • 自己ホスト型感情/感情分析：他の LLM プロバイダーへの拡張（Gemini が言及） (#Self-Hosting ai ai-sentiment)
    DiscourseAI 用の感情と感情の自己ホスト において、Orioni 氏は感情分析を他の LLM に接続するための ETA を尋ね、Gemini Flash バリアントとのポジティブな経験に触れ、コスト削減のために Gemini を感情分析に使用したいと述べました (投稿)。
    Falco 氏は、この機能が追加され、近日中にサイトに表示されるはずだと返信しました (返信)。

  • AI 翻訳バグ：Markdown 引用符 > が時折 0 に変換される (bug ai dynaloc)
    thomasjsn 氏は、「GPT-5.4 Nano」と「Gemini 3 Flash」の両方からの翻訳において、Markdown 引用マーカー（>）が時折 0 に変換され、AI 翻訳における Markdown 引用変換の失敗 でフォーマットが壊れると報告しました。
    例では、引用ブロックや見出しがあるべき箇所に 0 文字が繰り返されていることが示されています (報告)。

  • リクエスト：AI プラグインのプロンプトテキストを中国語で設定/ローカライズ可能にすること (#Feature ai localization)
    bird 氏は、要約、タイトル、DM 要約がデフォルトで英語になっていることを挙げ、AI プロンプトを中国語で設定できるようにすることを要望しました (希望 ai プラグイン可以设置提示词为中文)。
    sniper756 氏は、英語/中国語の出力は不安定でモデルによって異なる可能性があるとしつつも、根本的な原因は不明だと返信しました (返信)。

  • ボット/チャット文脈における完全な Markdown サポート（および関連する移行の懸念） (#Feature chat ai)
    ボット用チャットでの完全な Markdown サポート において、rokejulianlockhart 氏は、ボットを超えた完全な Markdown サポートに関するより広範なトピックが存在するかどうかを尋ねました（sam 氏による、より一般的なトピックを作成することへの以前の開放的な姿勢を参照：引用）。
    また、メッセージをチャット/DM に移行することに関する別の質問を引用し (参照トピック)、完全な Discourse Markdown がなければ、彼らのユースケースではこの機能は実用化できないと主張しました (投稿)。

アクティビティ

お読みいただきありがとうございます。来週またお会いしましょう！:slight_smile:

126

概要

今週の meta.discourse.org における AI 関連の議論は、主に3 つの実用的なテーマに集約されました。

  1. AI 支援による構成とモデレーション UX：管理者は、AI Helper が生成する内容（タイトル、タグ、カテゴリ）や、制約のあるカテゴリ設定における動作について、よりきめ細やかな制御を求めています。これにより、作曲器内のボタンごとのトグル機能に関する機能リクエスト（AI タイトル生成機能のリクエスト：タイトル/タグ/カテゴリのトグル）と、タグの提案がカテゴリのタグ制限を無視するバグ（AI Helper がカテゴリで許可されていないタグを提案する）の両方が表面化しました。

  2. 「AI」と「実際には LLM ではない」機能の明確化：重要な点として再確認されたのは、タグ/カテゴリの提案は LLM 駆動ではなく、埋め込み（embedding）ベースであるという点です。これは、どの程度「プロンプト」で結果を誘導できるかに影響します（AI タグおよびカテゴリの提案をカスタマイズする方法）。

  3. AI ＋ ローカリゼーション ＋ ツールのエッジケース：ローカライズされた AI 機能において、言語の誤検出や翻訳の鮮度に関する混乱が報告されました（奇妙：編集が表示されず、英語で書かれたものがフランス語と表示される）。さらに、開発者向けの問題として、AI ツールテストランナーが、平文の http:// 内部エンドポイントに対して SSL をネゴシエートしているように見えるという事象が指摘されました（AI ツールテストランナーが http URL に対して内部で SSL を行う）。

興味深いトピック

  • AI ローカリゼーションが言語を誤検出し、古い翻訳の背後で編集を隠す（Contribute > Site feedback, ai, dynaloc, content-localization）
    stephtara 氏は、英語で書かれた投稿がフランス語としてフラグ付けされ、その後の編集がレンダリングされたビューで「表示されない」ことを報告しました（報告）。
    Moin 氏は、誤検出は「フランス語」といった単一の単語によって引き起こされる可能性があり、「欠落した編集」は元の投稿ではなく古い翻訳を表示していたためであると説明しました（診断と回避策）。
    スレッドは、元の投稿者が説明を確認し、検出された言語を手動で修正したことで終了しました（確認）。また、言語検出の限界についての印象的な指摘がありました：

    「人工知能は知能ではない」 (引用）。

  • バグ：AI Helper がカテゴリで許可されていないタグを提案する（bug, ai）
    thgl 氏は、AI Helper が制限付きタグを推奨し、それを選択可能にしながら、後で送信をブロックしてしまうことを発見しました。一方、手動でのタグ入力は正しく制限を適用していました（バグ報告）。
    zogstrip 氏は即座にこの問題を認識し（認識）、すでに準備された PR による修正をフォローアップしました（修正状況）。
    報告者は対応の速さを確認し感謝しました（ありがとう）。

  • 機能リクエスト：AI タギング/カテゴリ化を有効にしつつ、AI タイトル生成を無効にするトグル（#feature, ai）
    Frully 氏は、タイトル、タグ、カテゴリの提案ボタンごとに個別のトグルを求めました。分類には AI の助けを残しつつ、タイトルはユーザー自身が作成できるようにしたいという要望です（リクエストと理由）。
    NateDhaliwal 氏は、実用的な暫定対応として、CSS を通じて「タイトルを提案」ボタンだけを非表示にする方法を提案しました（CSS 回避策）。
    リクエスト者はこれを実行可能として受け入れました（フォローアップ）。

  • AI タグ/カテゴリの提案をカスタマイズする方法：これは LLM プロンプトではなく、埋め込みベースであることの明確化（Support, ai, ai-helper, 解決済み）
    Frully 氏は、コミュニティがコンテンツをどのように整理するか（例：一貫した #meetings パターンや必須タグなど）をヘルパーに「教える」ことを望み、システムプロンプトの例がタイトルに焦点を当てており、タグ/カテゴリには焦点を当てていないと指摘しました（質問）。
    Falco 氏は、その理由を明確にしました：タグ/カテゴリの提案は LLM プロンプトを一切使用せず、既存のトピックに対するドラフトの埋め込みに依存しているためです（回答/解決策）。

  • AI ツールテストランナー：http.get() が内部 http:// エンドポイントに対して SSL を試行しているように見える（Support, rest-api, ai）
    Tobias1 氏は、http.get("http://stable-diffusion:7860/") が内部 IP に正しく解決される一方で、SSL ハンドシェイクエラーで失敗する再現スクリプトを共有しました。これは、ランナーまたはその HTTP クライアント層が TLS を試行していることを示唆しています（詳細とエラー出力）。

アクティビティ

お読みいただきありがとうございます。また来週お会いしましょう！:slight_smile:

127

概要

今週（2026-06-08 → 2026-06-15）は、メタ上で Discourse AI に関する議論が わずかではあるが実用的な バースト（2件の新しいトピックにわたる12件の新しい投稿）を見せました。その大半は、AI 翻訳の設定変更とコスト/スコープの可視性を中心に、組み込み AI ツールに関するいくつかの 運用および管理者向けの落とし穴 に焦点が当てられていました。

重要なテーマの一つは、AI 翻訳設定で 何が変わったのか を理解することでした。具体的には、「翻訳可能なカテゴリ」から「除外されるカテゴリ」モデルへの変更、およびコミュニティがどのように移行したかについてでした。また、スタッフログや Data Explorer を通じて 翻訳スコープとボリュームを監査/測定 する方法についても議論されました（AI Translation: What happened to “Translatable Categories” and how are translation costs calculated?、スレッド内で引用された移行の明確化、Data Explorer のクエリ提案、および参照されている以前の説明 392993/7）。

その他、スタッフやコミュニティメンバーは、タグの 教師なし機械翻訳 における段階的な改善と制限について議論し（AI-generated tag translations do not work perfectly）、AI ツールテストランナーにおける ポート/プロトコルのクイック を明確にし（Der AI Tools Test Runner macht bei http-URLs intern SSL）、組み込みの感情分類器で カスタマイズできることとできないこと についてカバーしました。多くの場合、より深い制御が必要な場合は管理者向けにセルフホスティングを推奨していました（Classification in the Discourse Sentiment Dashboard、および sentiment and emotion のセルフホスティング へのポインター）。最後に、ある管理者が、自動作成された AI 関連の管理者アカウント（「deepseek-chat」）の削除方法について質問しました。これには、AI プラグイン/ボットに関連していること、およびスタッフユーザーの削除フローに関するガイドラインが示されました（请问怎么删除deepseek-chat这个自动建立的管理员账户、削除に関する参照は Deleting users in rails console を参照）。

興味深いトピック

  • AI 翻訳設定の移行：「翻訳可能なカテゴリ」→「除外されるカテゴリ」 (ai dynaloc Support)
    Sara_Carmona_y_Lladó は、AI 翻訳 UI で 翻訳可能なカテゴリ が表示されなくなったことに気づき、動作が変更されたか、移行が行われたか、またスコープとコストがどのように決定されるようになったかを尋ねました（AI Translation: What happened to “Translatable Categories” and how are translation costs calculated?）。 Moin は移行が行われたことを確認し、カテゴリリストが以前の動作を維持するように変換された方法を説明しました（移行の説明）。これには、以前のスタッフのガイダンス（392993/7）が参照されていました。

  • ログと Data Explorer を使用した AI 翻訳スコープの監査 + 「何が翻訳されたか」の把握 (ai dynaloc Support)
    移行の説明に続き、Moin は、スタッフアクションログを使用して手動の設定変更を検出すること、およびカテゴリ/言語/カウント別に翻訳を内訳する Data Explorer クエリを共有することを提案しました（Data Explorer のアプローチ）。これはスレッド 405072/2 で続きました。

  • AI タグ翻訳の品質：何が進歩し、何が優先順位が低く残っているか (ai dynaloc tags Contribute > Site feedback)
    以前の報告へのフォローアップとして、nat は、元の報告で言及されたタグは「今ではメタ上で処理されるべき」と確認しましたが、タグ翻訳に追加のコンテキストを渡すことはまだ優先順位が高くないことも指摘しました（AI-generated tag translations do not work perfectly）。 Moin は、どのタグ翻訳が報告以来改善されたかをどのように見つけることができるか尋ねました（399570/15）。

  • AI ツールテストランナーのプロトコル動作：80 番以外のポートは HTTPS がデフォルト (ai rest-api Support)
    Falco は現在の動作を明確にしました。テストランナーはポート 80 でのみ HTTP をサポートしており、他のポートは内部的に HTTPS がデフォルトになるということです。これにより報告は解決しました（Der AI Tools Test Runner macht bei http-URLs intern SSL）。

  • 感情ダッシュボードの分類器のカスタマイズ：組み込み機能はロックされているように見えます；セルフホスティングが一つの道 (ai ai-sentiment Support)
    Lauraruskovic は、管理者アクセスがあっても、組み込みの感情分類エージェントのプロンプトフィールドがロックされている（読み取り専用）ように見えると報告し、推奨される方法はカスタムエージェントを作成することかどうかを尋ねました（Classification in the Discourse Sentiment Dashboard）。 NateDhaliwal は、組み込み機能はまだ編集できない可能性が高いと示唆し、感情/感情のセルフホスティングを可能な回避策として指摘しました（404193/10、sentiment and emotion のセルフホスティング）。

  • 自動作成された AI 管理者アカウント（「deepseek-chat」）：削除できる/すべきか？ (ai Support)
    sniper756 は、「deepseek-chat」に関連して自動的に作成された管理者アカウントの削除方法を尋ねました（请问怎么删除deepseek-chat这个自动建立的管理员账户）。 NateDhaliwal は、これはおそらく AI プラグインで使用されるボットであり、使用されていない場合は削除可能（ただし注意点あり）であると述べました。スタッフユーザーを削除するための rails-console のアプローチを参照しました（405250/2、Deleting users in rails console）。

アクティビティ

  • Moin
    今週の主な「AI 翻訳設定の変更」調査を牽引し、移行を確認し、翻訳可能なカテゴリ が新しい除外カテゴリモデルに変換された方法を詳細に説明しました（AI Translation: What happened to “Translatable Categories” and how are translation costs calculated?）。また、元の質問は 405072/1 を参照してください。スタッフログを通じた監査を提案し、カテゴリ/言語別の翻訳数を定量化する Data Explorer クエリを提供しました（405072/3）。別個に、タグ翻訳の品質改善についてフォローアップし、以前の報告以来何が変わったかをどのように特定できるか尋ねました（AI-generated tag translations do not work perfectly、解決の更新は 399570/18 を参照）。
    関連する参照には、引用された以前の移行ノート（392993/7）と、より広範なタグ翻訳スレッドのコンテキスト（399570/18、399570/15）が含まれていました。

  • Sara_Carmona_y_Lladó
    今週最も実質的な新しいトピックを開始し、「翻訳可能なカテゴリ」から「除外されるカテゴリ」への UI/動作の変更を指摘し、バックフィルスコープメッセージをどのように解釈すべきか、およびコストがどのように計算されるかの明確さを要求しました（AI Translation: What happened to “Translatable Categories” and how are translation costs calculated?）。フォローアップの説明と移行の詳細は、返信で提供されました（405072/2、405072/3）。

  • nat
    AI タグ翻訳の処理に関する具体的な更新を提供しました。元の報告（および追加のもの）でリストされたタグは「今では」メタ上で処理されるべきであり、追加のコンテキストの改善は優先順位が低いとしました（AI-generated tag translations do not work perfectly）。これは、Moin からの継続的なフォローアップに直接対応するものでした（399570/15）。

  • Falco
    AI ツールテストランナーのプロトコルが予期せず切り替わるというサポートレポートを解決し、HTTP はポート 80 でのみサポートされており、他のポートは HTTPS がデフォルトになることを明確にしました（Der AI Tools Test Runner macht bei http-URLs intern SSL）。これはスレッド内で解決済みとしてマークされました（404705/2）。

  • NateDhaliwal
    2つの別々のサポートスレッドで支援しました：

    1. 感情分類のカスタマイズに関しては、組み込みエージェントはおそらく編集できない（まだ）と説明し、より深い変更が必要な場合は管理者向けに感情/感情のセルフホスティングを指摘しました（Classification in the Discourse Sentiment Dashboard、フォローアップリンクは 404193/10、参照されたガイドは sentiment and emotion のセルフホスティング）。
    2. 「deepseek-chat」自動作成の管理者アカウントに関しては、これはおそらく AI プラグインのボットであると述べました。使用されていない場合は削除可能であり、スタッフユーザーを削除するための rails-console メソッドへのリンクを提供しました（请问怎么删除deepseek-chat这个自动建立的管理员账户、削除手順は Deleting users in rails console を参照）。

  • Lauraruskovic
    感情分類器の設定に関する議論を継続し、管理者権限があっても分類エージェントは見つかったもののプロンプトを編集できなかったと説明し、カスタムエージェントを作成することが推奨されるアプローチかどうかを尋ねました（Classification in the Discourse Sentiment Dashboard。カスタマイズに関する議論は 404193/6 を経由して続き、セルフホスティングへのポインターは 404193/10 にあります）。

  • sniper756
    自動的に作成された AI 関連の管理者アカウント（「deepseek-chat」）の削除に関する管理者メンテナンスの質問を提起しました。これには、問題のユーザー/アカウントのスクリーンショットが含まれていました（请问怎么删除deepseek-chat这个自动建立的管理员账户）。返信では、削除が安全かどうか、そして必要であればどのように行うかが議論されました（405250/2、追加のコンテキストは Deleting users in rails console にあります）。

お読みいただきありがとうございます。また来週お会いしましょう！ :slight_smile: