今週のMetaでのAIに関する議論は、Discourse AIをユーザーにとって分かりやすく、大規模運用において操作しやすくする ことに焦点が当てられました。プロダクト面では、「AIペルソナ」をより広く理解されている「AIエージェント」に改名する動きに強い勢いがあり（AIペルソナからAIエージェントへの改名 ）、翻訳ワークフローへの影響も考慮されています（AIペルソナからAIエージェントへの改名 ）。管理者の操作性にも注目が集まりました。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が到着！ にクロスリンクされました。
「AIペルソナ」から「AIエージェント」への改名（および翻訳への影響への対応） sam は、AIペルソナからAIエージェントへの改名 において、「AIペルソナ」は混乱を招く一方で、「AIエージェント」は広く理解されていると主張しました。これに対し、Falco はAIペルソナからAIエージェントへの改名 で早急な変更を支持しました。Moin は、多数の 翻訳を更新するという実務的な課題を提起し、AIペルソナからAIエージェントへの改名 およびAIペルソナからAIエージェントへの改名 で効率的な翻訳者のワークフローについて質問しました。一方、sam は、この用語が言語を超えて業界標準と一致しているかどうかをAIペルソナからAIエージェントへの改名 で追及しました。
バグ：AIが無効でもAI感情/感情分析レポートが表示される (Contribute > Bug ai-sentiment one1 は、AIが無効の場合はAIレポートを表示しない で、AIが無効になっているにもかかわらず管理者ダッシュボードにAI関連のレポートが表示されているのを発見しました。これに対し、sam はAIが無効の場合はAIレポートを表示しない でこれがバグであることを確認しました。chapoi は、これが「全プラグイン」のレポート表示に関するより広範な問題の一部であることを指摘し、管理者レポートと分析：段階的な変更 （関連：管理者レポートと分析：段階的な変更 ）にフォローアップのフィードバックを振り分けました。
OpenAI/Azureプロバイダーに「サービスティア」が追加（コストとレイテンシーの制御） (#Announcements , ai OpenAIプロバイダーのサービスティア でOpenAIおよびAzureのサービスティア（標準/フレックス/優先）を選択できる機能をリリースしました。また、管理者向けにDiscourse AI - 大規模言語モデル（LLM）設定ページ にあるコア設定画面へのリンクを提示しました。この告知では、特にフレックスティアにおける信頼性のトレードオフについても明確に説明されました（OpenAIプロバイダーのサービスティア ）。
UXバグ：翻訳済みタイトルのタイトル提案スターボタンが誤った位置に表示される (Contribute > UX ai-helper content-localization Moin は、翻訳済みのタイトルを編集する際、タイトルフィールドの外にタイトル提案の:star:ボタンが表示される で、翻訳済みのタイトルを編集する際にAI「クロアチア語のリクエスト ）。
機能案：AIヘルパーが生成した翻訳をコンテンツローカライゼーションに保存できるようにする (Contribute > Feature ai-helper dynaloc Moin は、AIヘルパーによる翻訳の保存をコンテンツローカライゼーションとして扱う で、ヘルパーモーダルから直接「翻訳を保存」するフローを提案しました。これは、AIヘルパーの「説明→脚注を追加」パターンと同様の前例に基づいています（AIヘルパーによる翻訳の保存をコンテンツローカライゼーションとして扱う ）。
Suggested/Relatedタブに関するモバイルUXの回帰（AI提案トピックUI） (Contribute > UX suggested-topics Falco は、モバイルでタブが消えていることに気づき、「Suggested」と「Related」タブの下の下線インジケーター でこれが関連するかどうか尋ねました。awesomerobot はそれが関連していると確認し、「Suggested」と「Related」タブの下の下線インジケーター で修正が差し迫っていることを指摘しました。
テーマコンポーネントの保守：Modernized Foundationとの互換性を保ちつつAI Gistsボタンの対応 (Customization > Theme component ai Lilly は、Discourse Topic Excerpts & AI Gists Button で、従来のFoundationテーマとの互換性を維持しつつ、Modernized Foundationでもフォーマットが機能するようにテーマコンポーネントをリファクタリングしました。これはModernizing the Foundation theme におけるより広範なテーマ作業に関連しています。
パフォーマンス/スケーリング：セマンティックエンベッディング検索によるCPU負荷とバックログの発生 (Support ai-search AI検索の有効化でサーバーが壊れた において、セマンティック検索を有効にした後に検索の中断と持続的なCPUスパイクが発生したとの報告がありました。sam は、外部API呼び出しにより長時間実行されるエンベッディングジョブは想定されるものの、高いCPU使用率は驚くべきもので、データベースやリソースの制約に関連している可能性が高いと説明しました（AI検索の有効化でサーバーが壊れた ）。Falco はAI検索の有効化でサーバーが壊れた でプロバイダーとデータベースの詳細を尋ねました。一方、SubStrider はAI検索の有効化でサーバーが壊れた で仕様とデータセットのサイズ（250万投稿/25万トピック）を共有しました。rburkej もAI検索の有効化でサーバーが壊れた で、セルフホスティングの計画を立てるために詳細な「ハードウェアプロファイル」情報を要求しました。
MCPツールリング：Discourse MCP用のCodex CLIセットアップガイド (users mcp pacharanero は、OpenAI Codex CLIでのDiscourse MCPセットアップ で、OpenAI Codex CLIでDiscourse MCPを使用するための手順付きガイドを公開し、これをDiscourse MCPが到着！ のメイン告知スレッドにリンクしました。
権限の強化：Discourse AIボットグループは「everyone」を許可すべきではない (Contribute > Bug ai-bot Moin は、ai_bot_allowed_groupsに対して「everyone」グループを禁止すべきかどうかをDiscourse AIは「everyone」グループを尊重しない で質問しました。これに対し、sam は、削除すべきであると同意し（クリーンアップ作業が計画されていると注記）、Discourse AIは「everyone」グループを尊重しない でそれを受け入れました。
合計（過去7日間）： 6件の新しいトピックと25件の投稿。最も活発なエンゲージメントは、命名/UXの磨き上げ、およびエンベッディングやOpenAIの使用に関する実用的なスケーリング/コスト制御について行われました。詳細はAIペルソナからAIエージェントへの改名 、OpenAIプロバイダーのサービスティア 、AI検索の有効化でサーバーが壊れた をご覧ください。
お読みいただきありがとうございます。また来週お会いしましょう！
過去1週間（2026-03-09 → 2026-03-16）のMetaでの#aiに関する議論は、製品の洗練、信頼性、そして「実世界」での運用 を中心に集約されていました。
製品面では、DiscourseはAI Persona からAI Agent への名称変更を実装し、用語の標準化に近づきました（Renaming AI Persona → AI Agent ）。インフラストラクチャ面では、ホスト型LLM提供サービスの容量を大幅に拡大し、すべてのティアで制限を引き上げるとともに、モデルの品質とレイテンシー特性を改善しました（Unlock All Discourse AI Features with Our Hosted LLM ）。
一方、運用担当者はAIがコミュニティのリズムにどう適合するか に注力しました。AI Agentの返信を遅延させ（チャットボットのように感じさせず、参加者として振る舞わせるようにする）、というリクエストが、新しいSupportトピック（Adding a configurable delay to AI Agent responses ）として提起されるとともに、長年続いている「Agents」ガイドスレッドでのフォローアップでも議論されました。Discourseスタッフは、遅延返信は#aiそのものではなく、将来の#automationの刷新に属する可能性が高いと示しました（AI bot - Agents ）。
統合に関する会話も顕著な増加を見せました。GoogleのProgrammable Search / Custom Searchの制約と廃止により、Web検索ツールの見直しが迫られており、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超时时间，如何调整？ ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週のAIに関する議論は、特に翻訳ワークフロー や要約機能の配置 に関連する実用的なUXとコスト管理の改善 に集中していました。
翻訳面では、Shauny が、投稿ごとのよりスムーズな「翻訳」操作と、APIコストの重複発生を防ぐために翻訳結果を保存/キャッシュする機能 を提案しました（AIで投稿を翻訳し、翻訳結果を保存する ）。これに対し、Moin は、このアイデアを以前のローカライズに関する議論と結びつけました（AIで投稿を翻訳し、翻訳結果を保存する 、AIヘルパーによる翻訳の保存をコンテンツローカライズとして扱う ）。
要約UI の面では、Ivan_Rapekas が、テーマコンポーネントを作成し、AI要約アクションをトピックヘッダー / サイドバーのタイムラインエリア に追加しました。これにより、要約ボタンの配置に関する長年の要望にも応えています（トピックヘッダーにAI要約を表示 、フィードバック: 要約ボタンをトピックの上部に移動 、モバイルビューでの要約ボタン配置 ）。
いくつかのスレッドでは、AI管理設定における洗練と信頼性 に焦点が当てられました。「Default LLM」エラーラベルの重複表示などの表記の乱れが認識され、修正対象としてキューに入れられました（なぜ「Default LLM」が重複しているのか… 、なぜ「Default LLM」が重複しているのか… ）。また、**LLMコスト設定UI（ドイツ語版）**におけるi18n（国際化）のレイアウト問題も、引き続き refinement されています（ドイツ語でのフィールド整列の問題… 、ドイツ語でのフィールド整列の問題… ）。
その間、コミュニティはエージェントの安全性の境界線 （特に、管理者の監視なしにAIが「ユーザーとして」行動することへの懸念）について再検討し（Discourse公式は公式のopenclawスキルをリリースするのか？ 、discourse統合用のopenclawプラグイン ）、ツール呼び出しのタイムアウトやDiscourse AIを自前のRAG/ナレッジベースに接続することといった統合の制約 にも取り組んでいました（Discourse AIのツール呼び出しタイムアウトはどう解決すべきか？ 、Discourse AIに自前のナレッジベースRAGを導入するには？ ）。また、Discourse MCPがプロトコルを通じてPDF添付ファイル にアクセスできるかどうかという、小さくとも注目に値する質問もありました（Discourse MCPが登場！ ）。
投稿ごとのAI翻訳UX ＋ 翻訳結果の保存によるAPIコストの削減 (Contribute > Feature ai translation Shauny は、「自分の言語で話す日」の摩擦を意図的だと説明しつつ、より扱いやすいモバイルフロー（理想的には投稿ごとの翻訳ボタンと、翻訳結果を1回だけ保存 することで、100人の読者が100回のAPI呼び出しを行わないようにする機能）を求めています（AIで投稿を翻訳し、翻訳結果を保存する 、AIで投稿を翻訳し、翻訳結果を保存する ）。 Moin は、これをAIヘルパーによる翻訳をローカライズコンテンツとして扱うという以前のアイデアと結びつけました（AIで投稿を翻訳し、翻訳結果を保存する 、AIヘルパーによる翻訳の保存をコンテンツローカライズとして扱う ）。 Falco は、これはDiscourseの「トピックごとに切り替え可能な自動翻訳」という設計と部分的に競合すると指摘し、イベント当日のみ自動翻訳を有効にするよう提案しました（AIで投稿を翻訳し、翻訳結果を保存する ）。
Discourseが「OpenClawスキル」や、ユーザーとして振る舞うエージェントを公式に提供するべきか (Contribute > Feature ai sniper756 は、OpenClaw駆動のエージェントを提案しました。これはユーザーに代わってコンテンツを投稿・整理し、ナレッジベースを効率的に構築するものです（Discourse公式は公式のopenclawスキルをリリースするのか？ ）。 awesomerobot は、管理者が関与しない状態でエージェントが実在のユーザーになりすますことについてDiscourseは前向きではない と再確認しました。MetaのBANポリシーの文脈を挙げつつも、管理者支援ツールの余地は残しています（Discourse公式は公式のopenclawスキルをリリースするのか？ 、discourse統合用のopenclawプラグイン ）。
コピー/表記のクリーンアップ: エラー文字列内の「Default LLM」の重複 (Contribute > UX ai Moin は、discourse_ai.ai_bot.agents.default_llm_required（「Default llm Default LLM…」）を確認している際、不自然な重複を発見し、UIでも再現しました（なぜ「Default LLM」が重複しているのか… ）。 awesomerobot は、これが不自然であると確認し、進行中の修正を指摘しました（なぜ「Default LLM」が重複しているのか… ）。
LLMコスト設定画面のドイツ語レイアウト/i18nの洗練 (Contribute > UX ai Moin は、ドイツ語版で見出し間の间距がまだ狭すぎると報告しました（LLMコスト設定におけるドイツ語のフィールド整列の問題 ）。 awesomerobot は、近々修正されるであろうことを返信しました（「Ach!これで直るよ」）（LLMコスト設定におけるドイツ語のフィールド整列の問題 ）。
新テーマコンポーネント: 「トピックヘッダーにAI要約を表示」（デスクトップサイドバー + モバイルタイトルエリア） (#Theme_component , ai ai-summarize Ivan_Rapekas は、Discourse AIの要約ボタンをより目立つUIエリアに配置するテーマコンポーネントをリリースしました。具体的には、デスクトップの右サイドバー/タイムラインコントロールと、モバイルのタイトルエリアです（トピックヘッダーにAI要約を表示 ）。また、これは古い要約ボタン配置に関するフィードバックのアップデートとしてロールアウトされたこと、およびモバイル配置に関する要望にも応えていることを指摘しました（フィードバック: 要約ボタンをトピックの上部に移動 、モバイルビューでの要約ボタン配置 ）。
投票数を正しくキャプチャするため、定期的なAI要約レポートのプロンプトを作成する (#Site_Management , automation ai julia1 は、フィードバック項目に関連する投票数を含めるために、どのようにプロンプトを作成すべきかを尋ねました（Discourse AI - 定期的な要約レポート ）。
サポート: LLMテストは通過するが、デフォルトLLMモデルの設定に失敗する（その後「謎」のように成功する） (Support ai DeltaWater は、ビルトインテストエンドポイントには合格するが、当初はデフォルトモデルとして設定できないモデルに関するスクリーンショットとサーバーログを共有しました。その後、エラーが表示されなくなったため、状態、権限、またはタイミングに関する疑問が提起されました（利用可能なLLMを作成した後でもAIのデフォルトLLMモデルを設定できない 、利用可能なLLMを作成した後でもAIのデフォルトLLMモデルを設定できない 、利用可能なLLMを作成した後でもAIのデフォルトLLMモデルを設定できない ）。
ツール呼び出しのタイムアウト: Discourse AIのread_timeoutは10秒ですが、APIが20〜30秒かかる場合は？ (Support ai Falco は、read_timeoutが10秒であることを明確にし、上位のAPIがそれよりも時間がかかるかどうかを尋ねました（Discourse AIのツール呼び出しタイムアウトはどう解決すべきか？discourseのタイムアウト時間を調整できるか、どう調整するか ）。 shixiaochi は、自前のナレッジベース検索APIが約20〜30秒かかると返信し、タイムアウトを変更できるかどうか、またその方法について尋ねました（Discourse AIのツール呼び出しタイムアウトはどう解決すべきか？discourseのタイムアウト時間を調整できるか、どう調整するか 、Discourse AIのツール呼び出しタイムアウトはどう解決すべきか？discourseのタイムアウト時間を調整できるか、どう調整するか ）。
自前のナレッジベース / RAGをDiscourse AIに統合するには (Support ai shixiaochi は、自前のナレッジベースRAGをDiscourse AIにどのように持ち込むかについて直接質問しました（Discourse AIに自前のナレッジベースRAGを導入するには？ ）。これは、外部検索呼び出しに関するツールタイムアウトの議論と隣接するテーマです（Discourse AIのツール呼び出しタイムアウトはどう解決すべきか？discourseのタイムアウト時間を調整できるか、どう調整するか ）。
MCPの機能に関する質問: MCPは投稿内のPDF添付ファイルにアクセスできるか？ (News and Events > Blog ai mcp anaderi は、MCPが投稿にアップロードされたPDF添付ファイルにアクセス可能かどうかを尋ねました（Discourse MCPが登場！ ）。
お読みいただきありがとうございました。また来週お会いしましょう！
今週の Meta Discourse における AI の活動は、タグやカテゴリなどの小さくも重要な UI 領域において、AI によるローカライゼーションの精度と予測可能性を高めること に焦点が当てられました。Moin は、AI 生成のタグ翻訳は完璧に機能しない というトピックで、コンテキストを欠いた LLM による翻訳の失敗例をいくつか取り上げました。これを受け、nat はプロンプトの改善 や、タグの説明 などの追加的な根拠コンテキストの導入を検討しました (返信 )。一方、Falco は、エージェントに関連ソースを読み込ませる といったツール支援型のアプローチを探求しました (アイデア , フォローアップ )。また、「翻訳を同期して維持する」という関連フィードバックも、カテゴリ名 およびカテゴリの説明 の更新に関する機能リクエストとして提出されました (カテゴリ名 , カテゴリの説明 )。
設定面では、トラブルシューティングのスレッドにおいて、どの種類の PM（プライベートメッセージ）が翻訳されるのか 、そして UI がそれをどのように伝えているのかについて混乱が見られました。私のサイトでの PM の翻訳が機能しない理由のトラブルシューティングを助けてください というトピックで、Moin は現在の制限（グループ PM と 1:1 PM の違い）を明確にしました (詳細 )。また、Falco はより明確な多選択設定を提案し (提案 )、nat は近日登場する「これらのカテゴリを翻訳する」制御が設定 UX を再構築する可能性があることを示唆しました (計画 )。
最後に、漸進的な改善とエコシステムの強化が行われました。セマンティック検索結果と完全一致検索結果に関するメッセージの明確化 (検索の明確化 )、ノイズを減らすための AI パーソナ行動の洗練への関心 (メンションみのリクエスト )、そしてテーマコンポーネントを通じた UI における AI 要約の継続的な採用 (フィードバック ) などです。
お読みいただきありがとうございます。来週またお会いしましょう！
今週（2026-03-30 → 2026-04-06）の meta.discourse.org では、Discourse AI に関する議論が以下の 3 つの主要なテーマに集約されました。
MCP の勢いとエージェント機能 : Discourse AI は、クライアントサイドの MCP サポート の発表により、モデルコンテキストプロトコル（MCP）への取り組みを強化しました。これにより、Discourse AI エージェントが外部の MCP ツールサーバーを呼び出せるようになりました（Bring your own MCP! ）。また、完全な管理者ガイドも公開されました（AI Bot – Bring Your Own MCP Server ）。並行して、サーバーサイドの MCP ツールも進化を続けており、LLM が MCP を介して既存の投稿やウィキコンテンツを更新できるようにする編集ツール が追加されました（Discourse MCP is here! ）。
AI 自動化におけるモデレーションとプライバシーの境界 : 「AI トリアージはプライベートメッセージ（DM）をスキャンできるか 」という実用的なモデレーションの質問は、ハードな制限というよりは UI/設定上の見落としに起因するものであり、自動化 UI におけるより明確な制御機能に関する後続のアイデアを喚起しました（Does AI triage automation scan DMs between regular users? 、solution ）。
ローカリゼーションと埋め込みにおけるモデル固有の特性 : 複数のスレッドで、「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! ）。 companion のハウツーガイドでは、セットアップ、ツールの発見、および JS ベースのカスタムツールとの違いについて説明しています（AI Bot – Bring Your Own MCP Server ）。
MCP の使いやすさ：「リモート/ウェブ MCP」の要望と既存投稿の編集機能追加 (ai mcp News and Events > Blog 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 Contribute > 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 Contribute > 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 Contribute > 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 Contribute > UX paco は、discourse_ai_enabled のユーザー単位版があれば、サイト全体の AI を無効化することなく AI の UI 通知をオプトアウトできるだろうと主張しました（User Interface Preferences: include setting to disable AI nudges ）。別に、翻訳設定の変更は個人メッセージを中心に進化を続けています。nat は移行 PR をリンクし、以前の「公開コンテンツのみ」の設定が新しいカテゴリ＋PM ターゲティング制御にどのようにマッピングされるかを説明しました（AI translation of all PMs ）。
sam は MCP の拡張をリリースし、将来のワークフローベースの自動化を促進しました。
RGJ はモデレーション、翻訳、埋め込みにおいて多くのハンズオンデバッグを行いました。
Denis_Kovalenko は、再現手順とフォローアップを含む 2 つの詳細な運用 AI レポート（モデレーション＋ローカリゼーション）を投稿しました。
nat は翻訳エージェントの品質管理を行い、移行ガイダンスを共有しました。
Falco は MCP 機能を進展させ、実用的なモデル選択を推進しました。
awesomerobot は解決済みの DM スキャン問題を UX 改善提案に変えました。
putty は高品質なローカリゼーションの欠陥を提起し、修正を確認しました。
Lilly はモデル設定/廃止予定に起因する AI ボット故障の診断を支援しました。
Moin はトラブルシューティングを加速させるためにバージョン/コンテキストを提供しました。
pacharanero は、より広いアクセシビリティに焦点を当てた MCP 製品フィードバックを提供しました。
jrgong は MCP に対する実用的なドキュメント/KB ワークフローの必要性を強調しました。
NateDhaliwal はボット問題の基本的なトリアージを行いました。
ice.d は AI ボットエラーのスクリーンショットと設定詳細を提供しました。
paco はユーザー単位 AI 制御に関する UX 議論を継続しました。
お読みいただきありがとうございます。また来週お会いしましょう！
今週の Meta 上の AI 関連の活動（2026-04-06 → 2026-04-13 ）は、実用的な統合の詳細 、特にAI 検出ファイル 、GDPR 対応環境におけるプロバイダー/モデルの選択 、そして翻訳の堅牢性 に焦点が当てられました。
「AI 検出」の分野では、コミュニティが llms.txt を生成するためのコミュニティプラグイン #ai #customization:plugin と、Discourse コアが提供するより新しい（現時点では限定的な）ネイティブな llms.txt ルーティングとの間の現実的な競合を掘り下げました。pacharanero さんは、オーバーライド動作について Ivan_Rapekas さんは 同じスレッド でその不具合を確認しました。さらに、kaktak さんはプラグインの動作を復元するためのアップデートを フォローアップ で約束しました。関連する文脈は、ネイティブサポートに関するコアの議論である Discourse におけるネイティブ llms-txt サポートの有効化 にも転載されました。
並行して、埋め込みや翻訳におけるモデル/プロバイダーの選択 、特に EU/GDPR との強い整合性を必要とするコミュニティにとっての重要性が強調され続けました。Mistral を埋め込みに使用する スレッドでは、Falco さんが動作する設定を共有し、より強力な埋め込みモデルを検討するよう提案しました。また、Mistral を翻訳モデルとして使用した際、翻訳された投稿から画像が消える というスレッドでは、プロバイダーの選択肢や「データ保持ゼロ（zero data retention）」が、コンプライアンスとリスクの観点で何を許容できるかを決定する要素として浮上しました。
最後に、翻訳の品質に関する問題は非常に「実践的」なものになりました。新しいバグ報告で、翻訳後の cooked（レンダリング済み）/マークアップエラー が記述され、Moin さんはそれが Markdown テーブルの書式設定に起因することを突き止めました。ソースとなるテーブルを修正することで、翻訳された出力が正常になったことが 翻訳後の cooked エラー で確認され、cuo_wu さんが 解決策 でこれを裏付けました。
製品利用の側面では、管理者がAI ペルソナ/エージェント の動作制御、特にエージェントが即座に返信するのを防ぐ方法や、それらを「メンションのみ」のパターンに制限する方法の探求を続けました。この議論は、AI ペルソナ/エージェントが投稿への返信ではなく @メンションにのみ応答できるようにする と、AI エージェントの返信に設定可能な遅延を追加する で共有された回避策を結びつけています。
お読みいただきありがとうございました。また来週お会いしましょう！
今週の meta.discourse.org における AI 関連の議論は、翻訳の信頼性とローカライゼーションワークフロー に集中しており、Contribute > Bug Support #ai、 #dynaloc、 content-localization ランダムに言語がスキップされたりバックエンドエラーが発生したりする 「再現が難しい断続的な翻訳の失敗」でした。これを受け、隠し詳細ログの有効化や /logs の検査といったデバッグ提案が出されました（ポルトガル語 (pt) ロケールがスキップされる AI 翻訳 、デバッグの続報 、バックエンドエラーの報告 を参照）。
また、記事が混在している場合（ドイツ語＋英語のタイトルなど）の言語検出と手動オーバーライド に関する実用的なサポートスレッドもあり、外部の設定問題 （期限切れの API キーなど）により翻訳が「壊れている」ように見える理由についても説明されました（ドイツ語として検出されない投稿 および 解決策 を参照）。別に、管理者のみが直面するロケール切り替えエラーは、Chrome 内の期限切れのテーマプレビュークエリパラメータ が原因であることが判明しました（ロケール切り替え時のエラー および 修正方法 を参照）。
「AI プラットフォーム」側では、Discourse MCP 接続性 （Claude コネクタや HTTP での利用可否を含む）への関心が再燃しました（Discourse MCP が登場！ 、および HTTP がサポートされていることの確認 を参照）。最後に、長年続いている AI エージェントのハウツースレッドには、特定のシナリオ向けにカスタムエージェントスキル を追加する方法に関する新しい質問が寄せられました（AI ボット - エージェント を参照）。
トレンドライン: 今週報告された「AI の問題」の多くは、出力の品質に関するものではなく、運用上の堅牢性 （ジョブの動作、リトライ、バックエンドの利用可否、設定の可視性）に関するものでした（例：翻訳のスキップ 、詳細ログ 、リトライ動作に関する質問 ）。
Contribute > Bug Denis_Kovalenko 氏は、多くのロケールを有効にするとポルトガル語が生成されない （その後：任意のロケールがランダムにスキップされる ）現象が発生し、タイトルと本文の翻訳が矛盾していると報告しました（元の報告：ポルトガル語 (pt) ロケールがスキップされる AI 翻訳 、設定の明確化：サポートされているロケールに関する質問 、および「ランダムにスキップされるロケール」の更新：一貫性のない結果 を参照）。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 に切り替えたことで解決しました。その後、タイトルの翻訳が正常に動作するようになりました（解決策 を参照）。
Composer UX の変更：ロケールセレクターが Composer ツールバー内に移動 Moin 氏は、言語ドロップダウンが Composer ツールバー内に移動されたことを明確にし、コアの変更へのリンクを貼りました（変更前後のスクリーンショット + PR 参照 ）。これは翻訳ワークフローと手動入力について議論している際に持ち上がりました（優先度に関する続報の議論 を参照）。
管理者のみが遭遇する「トピックが存在しない / テーマをプレビュー」エラーは、期限切れの preview_theme_id が原因 Denis_Kovalenko 氏は、管理者のみが直面する問題を報告しました。トピック内でインターフェース言語を切り替えると、存在しないテーマのプレビューに関する永続的なエラーが表示されます（報告 ）。 pmusaraj 氏は、Chrome 内の固定された ?preview_theme_id=ID パラメータが原因と診断しました（診断 ）。これを削除することで問題は解決しました（解決確認 を参照）。
翻訳の品質と制限：投稿サイズ/コンテキストウィンドウ、およびモデルの推奨事項 nat 氏は、タイトルは翻訳されるが本文はスキップされる という別のシナリオに言及し、LLM のコンテキストウィンドウ設定を確認するよう提案しました。また、顧客からのフィードバックと初期テストに基づき、「GPT mini」を翻訳に使用することを強く非推奨としました（モデル + サイズ/コンテキストに関するノート を参照）。 Denis_Kovalenko 氏は、非常に大きなコンテキストウィンドウが構成されていることを確認しました（コンテキストウィンドウの詳細 を参照）。
Discourse MCP 接続性：Claude.ai コネクタサポートのリクエスト；HTTP は既にサポート済み News and Events > Blog putty 氏は、Discourse MCP サーバーの HTTP/SSE ストリーミング版がリリースされ、Claude.ai Chat のコネクタとして使用できるかどうかを尋ねました（質問 ）。 Falco 氏は、HTTP サポートは既に存在すると返信し、アナウンススレッドの以前の返信を参照しました（HTTP サポートの返信 を参照）。
AI エージェントの拡張性：AI ボットエージェントへのカスタムスキルのリクエスト 赤丸的小烧酒 氏は（中国語で）、エージェントが異なるシナリオへの返信用にカスタムスキルを追加できるかどうかを尋ね、独自の AI エージェントの動作をカスタマイズする能力を求めています（カスタムスキルのリクエスト を参照）。
Denis_Kovalenko 氏は、今週 2 つのローカライゼーション/AI トラブルシューティングスレッドを牽引しました。
pmusaraj 氏は、診断と設定原因の絞り込みに注力しました。
nat 氏は、機能レベルのデバッグガイダンスとモデルに関する注意点を提供しました。
RGJ 氏は、デバッグの運用化を支援し、具体的な失敗シグナルを浮き彫りにしました。
Moin 氏は、ドキュメントへのポインタを示し、ローカライゼーションワークフローに影響を与える UI 変更を明確にしました。
この返信 で、ai_translation_verbose_logs が隠しサイト設定であることを説明し、関連するガイドへのリンクを貼りました（および参照ドキュメント：隠しサイト設定の使用 ）。ドイツ語として検出されない投稿 で、Composer の言語セレクターがツールバー内に移動されたことを（スクリーンショットと PR 参照付きで）文書化しました。
putty 氏は、翻訳サポートと MCP 議論の両方で大きく貢献しました。
ドイツ語として検出されない投稿 で混在言語の検出/翻訳の問題を提起し、この続報 で翻訳を強制しようとした失敗した試みを共有しました。その後、解決策 で実際の原因が期限切れの API キー/プロバイダーの不一致であることを確認しました。Discourse MCP が登場！ で、Claude.ai コネクタの互換性（HTTP/SSE ストリーミング経由）について質問しました。また、このコメント で、古いロケールセレクターの配置に関する UI への好みも表明しました。
Falco 氏は、使用に関する質問に答え、MCP の機能を明確にしました。
canbekcan 氏は、翻訳ワークフローの問題と最近の変更に関する仮説を探求しました。
ドイツ語として検出されない投稿 で「まず言語を選択し、その後タイトル/コンテンツを追加する」というワークフローを提案し、言語オプションの再作成が必要だったと説明しました。この返信 で「タイトルが欠落している」問題を調査し、当初はテーマに関連する動作を疑いましたが、この投稿 でエラーを再現でき、最近のコード変更を参照しました。このノート で、AI 翻訳を使用していない（学術的な要件による）ことを明確にし、UI の明確化後に参加を終了しました。
赤丸的小烧酒 氏は、AI ボット - エージェント で、カスタムスキルを通じたエージェントの拡張性について質問することで、AI エージェントの製品方向性に関する質問を追加しました。
お読みいただきありがとうございました。また来週お会いしましょう！
今週の meta.discourse.org における AI 関連の議論は、Discourse の AI 機能をより信頼性高く、自動化しやすく、外部の LLM ワークフローとの統合コストを抑える ことに集中していました。信頼性の面では、管理者たちは 翻訳がスキップされるか「停止」しているように見える理由 ——一時的なプロバイダーの障害やレート制限など——について掘り下げ、冗長ログの有効化や監査/ログテーブルの確認といった実用的なデバッグ手順を紹介しました（AI Translation skips Portuguese (pt) locale 、What happens to translations when LLM changes? ）。自動化の面では、AI トリアージと Discourse Automation を使用してトピックに自動タグ付けする 新しいハウツーガイド（Tag topics using AI ）と、エージェントの「例（Examples）」がどのように解釈されるか（そしてそれが誤って過剰なフラグ付けを引き起こす可能性があるか）に関する詳細な解説（AI triage examples not sent properly? ）がありました。最後に、統合と効率性の面では、Cooked コンテンツを Markdown として提供することで、ダウンストリームでの LLM 使用時のトークンコストを削減し、API/MCP 使用と相性が良くなる可能性のある 新しいプラグインが登場しました（Discourse to Markdown Plugin 、Discourse to Markdown Plugin ）。
これらは今週の議論内で直接参照され、周囲のエコシステムを説明するのに役立ちました：Discourse AI plugin 、Discourse Automation 、LLM settings guide 、AI bot personas / Agents 、Discourse MCP is here 、Discourse Chatbot now smarter than ChatGPT 、および参照された AI 検索 500 スレッド（All AI functions are working ok but AI search gives 500 error ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週のMetaにおけるAI関連の議論は、新しいUXと自動化ワークフローの磨き上げ 、およびAI支援による編集や翻訳における正確性の保証の強化 に集中していました。
最大の話題は、新しいドッキング型AIコンポーザーの実際のバグハンティングでした。 Lilly はNew ai docked composer において、編集、引用、モバイルスクロール、ファイルアップロードに関する問題を文書化しました。これに対し keegan は修正を素早く実装し、最終的に機能の改訂中はその機能を制限しました（update ）。並行して、AIヘルパーの校正フローでは、引用テキストの保持について議論が行われました。これは特に機密性の高いまたは正確な引用において重要であり、修正が適用されたことと、追加の設定提案が行われたことが確認されました（Proofread breaks quotes 、examples guidance ）。
運用面では、管理者たちがLLMのレート制限や設定に関する質問により翻訳ジョブが「停止」する件について情報を交換しました（What happens to translations when LLM changes? ）。また、機能導入の面では、Discourse AIのトリアージとDiscourse Automationを組み合わせることでトピックを自動分類する方法を示す新しいハウツーが公開されました（Auto-categorize topics using AI ）。さらに、プラグインの議論では、AI/MCPの消費者により満足してもらうために text/markdown を提供する方法が探られました（Discourse to Markdown Plugin ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週（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
お読みいただきありがとうございます。来週またお会いしましょう！
今週の meta.discourse.org における ai 実用的な信頼性向上 に関連するトピックに集中していました。
ローカライゼーションの面では、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 を変更しても、ページを更新するまでエージェントのラベルが更新されないという軽微な UI バグを見つけました（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 ）、新しい solved Option to hide ‘me too’ replies ）、そして AI プラグインのハイパーリンクが反応しないことを報告した中国語の新しい投稿（社区官方的ai插件中的超链接未能正常跳转，点击后无反应 ）などです。
お読みいただきありがとうございます。また来週お会いしましょう！
今週の meta.discourse.org における AI 関連の活動（2026-05-18 → 2026-05-25）は、主に「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 でも参照）です。
一方、以前の Contribute > Feature モデレーションパイプラインのコメント やその他のカスタムテキストが翻訳されていない点が問題視されています（Use translated posts when emailing users with their user language set 、Use translated posts when emailing users with their user language set 、Use translated posts when emailing users with their user language set でも言及）。
重要な会話を上部に保つための AI チャットのスター登録 （#Announcements , ai AI ボト会話をスター登録 する機能を導入しました。
今週（2026年5月25日～2026年6月1日）の meta.discourse.org における AI 関連の議論は、主に3つのテーマ に集約されました：
AI 統合と自動化 — AI 機能における「イベント駆動」への関心が高まっています。例えば、AI アーティファクトのデータ変更時に外部の自動化処理をトリガーする機能などです。Discourse AI アーティファクトのキー値変更に対する Webhook/イベントサポートの追加（および管理者によるサンドボックス無効化の許可）に関するリクエスト (Add webhook / event support for Discourse AI artifact key-value updates (or allow admins to disable sandboxing) ) には、Discourse の次期自動化機能（「Workflows」）の導入後に再検討するよう促す返信 (reply ) と、スコープ限定されたサーバーサイド Webhook が有用であるという同意 (follow-up ) が寄せられました。
AI UX とコンテンツの忠実度 — 複数のスレッドで、AI 関連の UX がまだ磨きを要する箇所が指摘されました。ドッキングされた AI ボットコンポーザーの「Enter で送信」の動作 (discussion , more )、翻訳出力による Markdown 引用構文の破損 (bug report )、そしてボット/チャットコンテキストにおける完全な Markdown パリティ への継続的な要望 (request continuation ) などです。
ローカライゼーションとマルチモデルサポート — 言語とモデルの柔軟性に関する投稿がいくつかありました。AI プロンプトの中国語へのローカライズに関するリクエスト (request , reply )、ユーザー言語設定に基づいてユーザーにメールを送信する際に翻訳済み投稿を使用する機能における翻訳の進捗（翻訳済み「フラグ理由」が正しく表示されるようになった修正のマージを含む） (Use translated posts when emailing users with their user language set )、Gemini などのより多くの LLM プロバイダーへ感情・感情分析の拡大に関する質問 (question , update ) などです。
お読みいただきありがとうございます。また来週お会いしましょう！
今週、meta.discourse.orgでのAI関連の議論は、主に3つの実用的なテーマ に集中していました。
AI支援による投稿作成とモデレーションUX : 管理者は、AIヘルパーが生成する内容（タイトル、タグ、カテゴリのいずれか）や、制限のあるカテゴリ設定での動作に対して、より細粒度の制御 を求めています。これにより、投稿フォームでのボタンごとの切り替え機能という機能リクエスト（AIタイトルジェネレーターのリクエスト: タイトル/タグ/カテゴリの切り替え ）と、タグ提案がカテゴリのタグ制限を尊重しないというバグ（AIヘルパーがカテゴリで許可されていないタグを提案する ）の両方が浮上しました。
「AI」と「実際にはLLMではない」機能の明確化 : 重要な点として、タグ/カテゴリの提案はLLM駆動ではなく、埋め込み（embedding）に基づくもの であり、これにより「プロンプト」が結果に与える影響の度合いが変わるという指摘が再確認されました（AIタグとカテゴリの提案をカスタマイズする方法 ）。
AI + ローカライゼーション + ツールリングのエッジケース : ローカライズされたAI機能において、言語の誤検出 と翻訳の鮮度に関する混乱 の報告がありました（奇妙な現象: 返信の編集が表示されず、英語で書かれているのにフランス語と表示される ）。さらに、開発者向けの問題として、AIツールテストランナーが、プレーンな http:// の内部エンドポイントに対してSSLネゴシエーションを試みる という事象も報告されました（Der AI Tools Test Runner macht bei http-URLs intern SSL ）。
AIのローカライゼーションで言語を誤検出し、編集内容を古い翻訳の背後に隠す (Contribute > Site feedback ai dynaloc content-localization stephtara さんは、英語で書かれた投稿がフランス語とフラグを立てられ、その後の編集がレンダリングされたビューで「表示されない」と報告しました（報告 ）。 Moin さんは、誤検出は「French」といった単一の単語によって引き起こされる可能性があると説明し、「編集の欠落」はソース投稿ではなく古い翻訳 を表示しているためである可能性が高いと指摘しました（診断 + 回避策 ）。スレッドは、元の投稿者がこの説明を確認し、検出された言語を手動で修正したことで終了しました（確認 ）。また、言語検出の限界に関する覚えやすい言葉も残されています：
「人工知能は知能ではない」（引用 ）。
バグ: AIヘルパーがカテゴリが許可していないタグを提案する (Contribute > Bug ai thgl さんは、AIヘルパーが制限されたタグを推奨し、それらを選択できるにもかかわらず、後で送信をブロックすることを見付けました。一方、手動でのタグ入力では制限が正しく適用されていました（バグ報告 ）。 zogstrip さんは、この問題を迅速に認識し（認識 ）、すでにPRを通じて準備された修正をフォローアップしました（修正状況 ）。報告者は、この対応速度の速さを確認し（感謝 ）、謝意を表しています。
機能リクエスト: AIタグ付け/カテゴリ付けは有効にし、AIタイトル生成は無効にするための切り替え (Contribute > 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を無視しているにもかかわらずTLSを試みていることを示唆しています（詳細 + エラー出力 ）。
お読みいただきありがとうございました。また来週お会いしましょう！
今週（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 を参照）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週（2026-06-15 → 2026-06-22）、meta.discourse.org における AI に関する議論は、エディタ内の AI ヘルパーに対する UX 改善 、AI エージェントのコスト管理とスコーピング 、そしてエンドポイント、SSRF 保護、翻訳の境界ケースなど、セルフホスティング環境における実践的な設定/デバッグの課題 に集中していました。最も注目すべき製品面の更新は、コンポーザーにおける AI 提案 の新しいインラインフロー（コンポーザー内での AI 提案のインライン統合 ）でした。一方、サポートの大部分は、AI 環境を信頼性高くかつ低コストで動作させることに注がれました（例：カテゴリフィルタリングによる AI トークン使用量の削減 でのトークン消費削減のためのカテゴリ限定検索、「このモデルへの接続を試みると、このエラーが返されました」が空白になる でのエンドポイントの正確性とログ確認）。
「本番環境での AI」の側面では、セルフホスティングユーザーは引き続きインフラの現実的な課題に直面しました：内部 LLM ルーティング（LiteLLM/Vertex 風）が 内部 AI エンドポイントの使用方法は？ で SSRF 防御に引っかかり、翻訳ジョブが DiscourseAi::Translation: null byte を含む文字列のため投稿の翻訳に失敗しました で問題のあるコンテンツバイトのために失敗しました。最後に、翻訳バックフィルに関する小さくとも非常に共感できる UX リクエストとして、AI 翻訳設定に日付ピッカーを で、頭の中で計算する必要を避けるための日付ピッカーが提案されました。
総括：エディタ体験において AI 機能が成熟しつつあり（コンポーザー内での AI 提案のインライン統合 ）、管理者はスコープ/コストの制御 （カテゴリフィルタリングによる AI トークン使用量の削減 ）と設定の堅牢化 （「このモデルへの接続を試みると、このエラーが返されました」が空白になる 、内部 AI エンドポイントの使用方法は？ ）にますます注力しています。
コンポーザー内の AI 提案に UX リフレッシュが適用 (#Announcements , ai ai-helper ux chapoi は、カテゴリとタグの AI ヘルパー – 提案 がコンポーザー内でインライン に移動され、特にカテゴリ選択用の新しい*「私に選ばせて」*オプション付きで、より「ワンステップ」のフローを目指したと発表しました（コンポーザー内での AI 提案のインライン統合 ）。 Ed_S は、これは AI が有効/設定されている場合にのみ適用されると明確にし（コンポーザー内での AI 提案のインライン統合 ）、chapoi は AI ヘルパーが有効であることが前提条件であることを確認しました（コンポーザー内での AI 提案のインライン統合 ）。発表記事 、セルフホスティングに関する質問 、確認 。
カテゴリに限定して AI エージェントの検索を行うことでトークン使用量を削減 (Support ai alefattorini は、エージェントが特定のカテゴリの投稿のみを考慮するように制限する方法を尋ね、明示的にトークン使用量の削減 を目的としています（カテゴリフィルタリングによる AI トークン使用量の削減 ）。 Falco は、デフォルトの検索 ツールを使用する場合、エージェント編集 UI ですでにカテゴリによる制限が可能であり、それがヘルプテキストの例としても使用されていることを指摘しました（カテゴリフィルタリングによる AI トークン使用量の削減 ）。質問 、カテゴリ限定検索のガイダンス 。
空白の「このモデルへの接続を試みると…」エラーはエンドポイント設定とログによるデバッグに起因 (Support ai alefattorini はスクリーンショットを共有し、デバッグ方法を尋ねました（「このモデルへの接続を試みると、このエラーが返されました」が空白になる ）。 Falco は、URL が正しい OpenAI エンドポイント（.../v1/chat/completions または .../v1/responses）でなければならないこと、詳細を確認するために /logs ページをチェックすることを提案し、モデル選択のトレードオフ（例：GPT “Nano” vs “Mini”）にも言及しました（「このモデルへの接続を試みると、このエラーが返されました」が空白になる ）。問題報告 、エンドポイント + /logs ガイダンス 。
セルフホスティング + 内部 LLM ゲートウェイ（LiteLLM / Vertex 風）が SSRF 保護に抵触 (Support ai satonotdead は、セルフホスティングされた Discourse から内部エンドポイント（LiteLLM など）を使用しようとしたが、LLM テスト中に 500 エラーが発生し、SSRF 関連の例外 FinalDestination::SSRFDetector::DisallowedIpError が表面化したと説明しました（内部 AI エンドポイントの使用方法は？ ）。 Falco は、同じサーバー上で実行されている場合、DISCOURSE_ALLOWED_INTERNAL_HOSTS 経由で内部ホストを許可するようアドバイスしました（内部 AI エンドポイントの使用方法は？ ）。SSRF エラー + 背景 、環境変数ガイダンス 。
「文字列に null byte が含まれています」による AI 翻訳の失敗 (Support ai LotusJeff は、翻訳の失敗（DiscourseAi::Translation: null byte を含む文字列のため投稿の翻訳に失敗しました）を報告し、投稿とタイトルを手動で確認した後に、コンテンツ内の null byte を特定する方法を尋ねました（DiscourseAi::Translation: null byte を含む文字列のため投稿の翻訳に失敗しました ）。エラー報告 。
機能リクエスト：翻訳バックフィルの最大年齢用の日付ピッカー (#Feature , ai dynaloc content-localization LotusJeff は、**AI 翻訳バックフィルの最大年齢（日）**設定に日付ピッカーを要求しました—特に数十年にわたるアーカイブを持つコミュニティでは、日数の計算が面倒であるため、特に役立ちます（AI 翻訳設定に日付ピッカーを ）。リクエスト 。
お読みいただきありがとうございます。また来週お会いしましょう！
今週の Meta における AI に関する議論は、Discourse AI 機能全体、特に Ask Discourse 、AI 翻訳 / コンテンツローカライゼーション 、および コンポーザー内のインライン AI ヘルパー における品質、透明性、UX の磨き に焦点が当てられました。一部の管理者は Ask Discourse の回答品質の変化に気づき、同サービスが最近ローカルホスト型のオープンウェイトモデル に移行したことを知りました（Ask discourse moins performant 、model change note 、rationale + guidance ）。
ローカライゼーションの面では、複数のスレッドで翻訳の進捗状況が大規模になると混乱を招きやすい ことが指摘されました。これはキャッシュと多段階の処理プロセスによるもので、レポート機能と設定（より明確な進捗表示や日付ピッカー / 固定の切り捨て日付 など）の改善に向けた具体的な要望が寄せられました（AI Translation Progress Graph 、caching + two-step explanation 、date picker request 、topics vs posts pacing ）。関連して、管理者らは言語フォールバック （例：「ユーザーのロケールがサポートされていない場合、英語を表示する」）について質問し、スタッフはサイトデフォルトのロケール動作以外ではまだサポートされていないことを確認しました（Can I force English for unsupported languages 、fallback locales not supported 、current fallback behavior ）。
いくつかの実践的・運用上の問題も浮上しました。内部 LLM エンドポイントと許可されたホスト設定のデバッグ（How to use internal AI endpoints? 、allowed host suggestion ）、無効化された状態が「固まって」しまった AI プラグインの有効化（さらに、無料プランではスパム検知などの重要な機能のためにプラグインは有効化されたままになるという説明付き）（Can’t get the AI plugin enabled 、fix in progress + free-tier note ）、そしてHTML コメントが AI サマリーに含まれてしまう という小さくも示唆に富むエッジケース（最終的に #wontfix としてマークされ、プロンプトによる回避策が提示）（HTML comments are also summarized by AI 、wontfix + workaround ）です。
最後に、編集フローにおける AI アシストボタンのUI 統合品質 への注目が続き、アイコンの重なりや絶対配置されたボタンによるレイアウトの問題が、より広範なインライン AI コンポーザー統合作業と結びついています（Topic edit interface shows overlapping icons 、linked to inline integration thread 、AI title suggest icon placement issue 、inline integration of AI Suggestions ）。
モデル変更後の Ask Discourse の回答品質への懸念 (ai ask-discourse Support gilles が、Ask Discourse が最近「パフォーマンスが低下した」ように感じると報告しました（Ask discourse moins performant ）。nat は、最近ローカルホスト型の DeepSeek v4 flash モデルへの切り替えがあったことを確認し（model change note ）、Falco は、その目的が高速なドキュメントベースのトラブルシューティングであり、開発者支援ではないことを明確にし、代わりに dv のような開発用ハーネスの使用を推奨しました（explanation + dv recommendation 、Using dv (Discourse Vibe) to configure Discourse AI in development ）。
翻訳進捗グラフの精度、キャッシュ、および「進捗とは何を意味するのか？」 (translation ai #Data- &-reporting)LotusJeff は、大規模なサイトにおいて進捗グラフが誤解を招くものだと発見しました（AI Translation Progress Graph ）。Falco は、タイムアウトを避けるためにページがキャッシュされており、翻訳には言語検出 と他のロケールへの翻訳 という2段階のプロセスが含まれており、初期段階の検出進捗はもはや表示されないため、最初の体験が「ひどく」感じられると説明しました（caching + 2-step pipeline ）。LotusJeff は、「対象外 vs 翻訳済み」のより明確なレポートモデルを提案し、Data Explorer SQL プロトタイプの共有を開始しました（reporting proposal 、SQL examples ）、nat は改善が計画されていると述べました（staff follow-up ）。
Discourse AI における内部/セルフホスト型 LLM エンドポイントのデバッグ (ai Support satonotdead は、コンテナ内では機能していた内部エンドポイント URL が、Discourse AI UI テストで失敗するという問題に直面しました（problem report + stack trace ）。Falco は、DISCOURSE_ALLOWED_INTERNAL_HOSTS にホスト名 （IP レンジだけでなく）を含めることを提案しました（allowed host suggestion ）。文脈には以前の Ollama ローカルセットアップも参照されています（Getting Discourse AI to work with Ollama locally ）。
ロケールフォールバックポリシー：サポートされていない言語に対して英語を強制する (translation ai #Feature )Jagster は、フィンランド語中心のサイトのデフォルトロケールを変更せずに、サポートされていないロケールを英語にフォールバックさせることができるか尋ねました（question ）。Falco は、「フォールバックロケール」はリクエストされているものの、まだサポートされていないことを確認しました（no fallback locales yet ）、nat は現在の動作を明確にしました：フォールバックを無効にすると元の言語が表示され、英語フォールバックを使用するにはデフォルトロケールを en に設定する必要があるということです（behavior details ）。
AI サマライゼーションが HTML コメントを含む理由（およびそれが #wontfix である理由） (ai ai-summarize #Feature )ばこん は、読者が見えない HTML コメントが依然としてサマリーに含まれていることに気づきました（report 、example ）。Falco はこれを #wontfix とマークし、特定のインスタンスで問題となる場合は、コメントを無視するようにサマリーエージェントに指示するプロンプトの調整を提案しました（decision + workaround ）。
AI プラグインが無効化されたまま固まる問題 + 無料プランにおける「AI プラグインは無効化できない」に関する説明 (ai Support ondrej は、以前無効化した後、AI を再有効化できませんでした（issue ）。keegan は、「無効化されたまま固まる」状態の修正が必要であることを確認し、無料プラン ではスパム検知などの重要な機能を動かすために AI プラグインが有効化されたままになることを明確にしました。ただし、個々の AI 機能は UI で無効化できます（fix + policy ）。このリクエストでは、既存のセットアップドキュメントも参照されました（documentation excerpt source ）。
AI UI の磨き：重なるアイコンと絶対配置された AI ボタン (ai ux Moin は、トピック情報を編集する際にアイコンが積み重なる/重なる問題を報告しました（overlap report ）、Falco はこれを進行中のインライン AI 統合スレッドにリンクしました（cross-reference 、Inline integration of AI Suggestions (in Composer) ）。関連する UX の問題として、Moin は、AI タイトル提案ボタンがタイトルフィールドが移動する間（特に翻訳されたタイトルの編集時）に固定されたままになること、および提案が英語で表示されることを指摘しました（title icon placement ）；chapoi は後に、position: absolute のボタンが再発する問題の原因となっていると指摘しました（follow-up ）。
トピックが投稿より早く翻訳される理由（および何を調整すべきか） (ai content-localization Support LotusJeff は、トピックデータが数ヶ月前から翻訳されているのに対し、投稿が遅れていることを観察しました（question ）。Falco は、バッチサイズは似ていますが、トピックは特に投稿数の多いトピックにおいて自然に早く完了し、投稿が追いつくように最大年齢やバックフィルレートを調整するよう提案しました（explanation + knobs ）。
機能リクエスト：AI 翻訳設定における日付ピッカー（固定の切り捨て日付） (ai dynaloc content-localization #Feature )mcwumbly は、設定は「{日付}以降のすべての投稿を翻訳する」ではなく「日数バックフィル」である必要があるかもしれないと指摘しました（framing ）。LotusJeff は、ローリングウィンドウは編集された古いコンテンツがスコープから外れてしまう原因となり得ると主張し、「トピックは翻訳されているが投稿はまだ翻訳されていない」というミスマッチがユーザーに目に見える問題であることを強調しました（rolling window concern 、additional rationale ）。
Sentiment ダッシュボードで感情/感情分類がどのように割り当てられるか (ai ai-sentiment Support fzngagan は、感情と感情分類に使用されるモデルを要約し、サイト設定を介したモデルベースの分類とエージェントベースの戦略の違いを説明しました（sentiment classification overview ）、現在のモデルに関する参照ドキュメントスニペット（models reference ）を指し、管理者はデフォルトを編集するのではなく /admin/plugins/discourse-ai/ai-agents で新しいエージェントを作成できることに言及しました（agent approach context ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週、#meta.discourse.org における ai AI コストの管理とバックグラウンド使用の理解 、要約入力周りのセキュリティ期待値の強化 、そして Discourse AI 機能セット全体での UX と統合の改善 が中心となりました。
コスト/運用面では、Discourse は Discourse AI の使用量に対して推定ドルベースのクォータ （トークン制限に加えて）を実装し、プロバイダー全体での予算管理を容易にしました（Discourse AI のコストベースクォータ および companion ガイド Discourse AI における LLM 使用量クォータの設定 を参照）。管理者はまた、埋め込みや要約のバックフィルなどのバックグラウンドジョブにより、AI UI 機能をアクティブに使用していない間にも発生しうる定期的な AI API 呼び出し について情報交換を行いました（Discourse はバックグラウンドで AI API を呼び出すか および Falco の確認 を参照）。
安全性の面では、要約プロンプトに実際に投入されるもの 、特にHTML コメント が含まれることで操作のための「隠れたチャネル」を形成する可能性について、改めて注目が集まりました（HTML コメントも AI によって要約される 、Falco の返信 、および 追々の懸念 を参照）。
その間、複数のスレッドは「現実世界で機能させること」に焦点を当てていました：AI タイトル提案での 500 エラー のトラブルシューティングと監査ログの参照先（Qwen3.7-plus サポートスレッド および ai_api_audit_logs内部 AI エンドポイント / LiteLLM サイドカー の設定（内部 AI エンドポイントの使用方法 および こちら の解決策まとめ）、そして Ollama の OpenAI 互換 API 経由での翻訳のセルフホスティング（DiscourseAI 向けオープンソース LLM のセルフホスティング 、モデル/トークナイザーのガイダンス 、および こちら の翻訳制約に関する議論）。
UX と製品の磨きにも注目が集まりました：AI タイトル提案アイコンの位置 に関する修正が提案されました（AI タイトル提案アイコンがタイトル入力フィールドの上に配置される ）、「インライン」AI 提案がレイテンシー/動作に関する疑問を提起しました（Composer における AI 提案のインライン統合 および レイテンシーに関する質問 ）、そして AI ボット会話用のドッキングされたコンポーザー は、誤ってオフに切り替えられた後、再有効化されました（質問 および 解決 ）。
Discourse AI のコストベースクォータ（推定ドル、トークンだけではない） #Announcements #ai: sam は、プロバイダー全体での予算管理を支援するために、グループごとに推定ドルコスト で AI 使用量を制限する新しい方法を発表しました（発表 ）。この機能は既存のクォータ設定フローと連携しています（Discourse AI における LLM 使用量クォータの設定 ）。
AI 要約に HTML コメントが含まれる（および潜在的なプロンプトインジェクションの懸念） #Feature ai #ai-summarize: Ed_S は、HTML コメントが要約に影響を与える「隠れたチャネル」になるリスクを提起しました（懸念 ）。Falco は、特に小規模/古いモデルの場合にその可能性を認め、システム/ユーザープロンプトの分離を緩和策として指摘しました（返信 ）が、Ed_S はそれがジェイルブレイクに対する真のメカニズムではないと反論しました（追々 ）。
Qwen3.7-plus のセットアップ：タイトル提案ツールが 500 エラーを返す件 + 監査ログを使用したデバッグ方法 Support #ai: bird は、他の AI ツールが動作しているにもかかわらず、AI タイトル生成を使用する際に 500 エラーが発生したと報告しました（報告 ）。Falco は、より詳細な診断のために ai_api_audit_logs を照会するよう推奨し（ヒント ）、その後、最新のエントリを検査する方法と、500 エラーが Qwen ではなく Discourse 側から発生していることを明確にしました（追々 ）。このスレッドでは、Discourse AI が画像生成をサポートするかどうかの質問に対し、画像生成のドキュメントへのポインターも示されました（回答 + リンク 、および Discourse AI における改善された画像生成サポート ）。
内部エンドポイントに対する Discourse AI の実行（LiteLLM サイドカー、内部ホストの許可リスト、MCP のクリーンアップ） Support #ai: evantobin は、localhost の LiteLLM サイドカーに対して DISCOURSE_ALLOWED_INTERNAL_HOSTS を使用して内部接続を機能させる方法について説明し、Vertex AI 認証に関する後続の作業についても言及しました（詳細 ）。satonotdead は、Docker の内部ゲートウェイ IP、ポートマッピング、および壊れた MCP ツールのクリーンアップを使用した完全な解決策を共有しました（解決策 ）。
機能リクエスト / PR: AI ペルソナシステムプロンプトに {username} テンプレートパラメータを追加 #Feature #ai: 42aross は、AI ペルソナが LLM がトピックのテキスト/メタデータから推測するのではなく、サーバー側で現在のユーザーを確実に識別できるように、{username} を許可されたテンプレートパラメータとして追加することを提案しました（リクエスト + 理由 ）。また、CLA プロセスの完了についても言及しました（追々 ）。
AI ボット会話用のドッキングされたコンポーザー：Meta でオフに切り替えられ、その後再有効化 #Announcements ai #ai-bot: putty は、Meta がもはやドッキングされたコンポーザー UI を表示しない理由を尋ねました（質問 ）。keegan は、誤ってオフに切り替えられ、再度オンにしたと返信し、beta への移行について言及しました（ステータス更新 ）。nicolsdennis は、ボット会話の返信長を制限する製品に関する質問で追々しました（質問 ）。
コンポーザー内のインライン AI 提案：一貫性 + レイテンシー/動作に関する質問 #Announcements ai #ai-helper: chapoi は、類似した UI エントリポイント全体で一貫した動作を実現することについて議論し、フィードバックを求めました（投稿 ）。nicolsdennis は、往復レイテンシーと、提案がトピックタイトルのみに基づくかどうかを尋ねました（質問 ）。
UX 修正：AI タイトル提案アイコンの位置 ux #ai: chapoi は、タイトルフィールドの上にタイトル提案アイコンが表示される問題に対する実装修正を投稿し、副作用の確認を求めました（修正 + PR リンク ）。
Gemini API キーの変更：サービスアカウント、移行の懸念 #Integrations how-to #ai: m_terenui は、Google が Gemini API キー周りのセキュリティ変更を報告し、サービスアカウントの必要性や旧キーの移行を必要とする可能性があり、今後 Discourse が管理者にどのような設定を期待しているかを尋ねました（質問 ）。（スレッド参照：Discourse AI 向け Gemini API キーの設定 ）
Ollama を使用した Discourse AI 翻訳のセルフホスティング：プロバイダーの選択、トークナイザー/コンテキストウィンドウ、および「翻訳エンドポイント」がドロップインではない理由 #Self-Hosting #ai: mononym は、Ollama を介した Discourse AI 翻訳を試す方法と、新しい管理者 UI 設定の場所を尋ねました（質問 ）。Falco は、プロバイダーとして OpenAI を選択して Ollama の OpenAI 互換 API を使用するよう提案し（ガイダンス ）、その後、実用的な設定アドバイス（トークナイザーの選択、コンテキストウィンドウ）を提供し、不適合/古いモデルを避けるよう注意しました（詳細 ）。このスレッドでは、Discourse AI 翻訳が単純な LibreTranslate エンドポイントの代替として設計されていない理由と、古い Translator プラグインがそのまま使用できる理由についても言及しました（制約 ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週、meta.discourse.org での AI 関連の議論は、コンテンツのローカライズにおける信頼性と制御 （ai dynaloc AI 駆動機能に対するフィードバックループ についても議論されました。
ローカライズの面では、機能性 と品質 の両方で勢いがついています。管理者はカスタムサイドバーセクションの翻訳 を要望しており（機能リクエスト：カスタムサイドバーのリンクとセクションを翻訳可能にする 、サイドバーのドキュメントリンクを翻訳する からの文脈）、複数の報告でプロンプト/フォーマットの問題 やサイレントな翻訳失敗 が指摘されました。これには、ドイツ語の翻訳に JSON ライクなラッパーが含まれる問題（ドイツ語の翻訳に翻訳要素が含まれる ）や、JSON ストリーミング解析が壊れた際に翻訳がサイレントに切り捨てられ/破損する 問題（JSON ストリーム解析が壊れた場合、エラーを発生させずに翻訳がサイレントに切り捨てられる ）が含まれます。
いくつかのスレッドでは、AI 統合の実用的な使いやすさの向上 について議論されました。解決済みのサポートケースでは、Claude Sonnet 5 が古い Discourse バージョンや構造化出力設定と組み合わされた際にエラーを発生させる理由が説明されています（Discourse AI: Antrophic Sonnet 5 を動作させるには JSON レスポンスを削除する必要があります… ）。ユーザーは独自語彙の翻訳を防止 する方法を尋ねており（AI による独自語彙の翻訳を防止するには？ ）、新しいテーマコンポーネントにより AI ボット会話 UI でのファイルアップロード が改善されました（AI ボット会話ページへのドラッグ＆ドロップアップロードとファイルプレビュー ）。
最後に、評価とフィードバック は繰り返されるニーズとして浮上しました。Ask Discourse ユーザーは AI とやり取りする際に標準的な Discourse のレート制限に遭遇し（Ask Discourse へのフィードバック ）、Discobot Discoveries のハルシネーション（幻覚）により、より良いフィードバックメカニズムへの呼びかけ（および例）が行われました（meta 上の Discobot discoveries 結果へのフィードバック ）。これは、より長期的な AI Search の取り組みと結びついています（Discourse AI に会話型 AI Search が来る ）。
お読みいただきありがとうございます。また来週お会いしましょう！
今週、meta での AI に関する議論は、Discourse AI が実際のコミュニティでどのように動作するか に焦点が当てられ、エッジケースがプライバシー やノイズ の問題に発展する可能性について論じられました。ホスティング済み顧客も、デフォルトのホスティング済みモデルルーターである CDCK/MoM についてより明確な説明を受け、要約やエンベディングなどの異なる AI ワークロードに対して Discourse がなぜ*モデルの混合（mixture-of-models）*アプローチを採用しているかが理解されました（CDCK/MoM とは？ ）。
バグ修正の面では、公開トピックで AI ボットの返信に再試行（Retry）をクリックすると、重複した投稿 が作成されてしまう（その場で再生成されるのではなく）という高頻度で発生する迷惑な問題が報告され、すぐに上流の修正と関連付けられました（AI ボット「再試行」が重複した返信を作成する… 、続報 ）。翻訳関連の問題も目立っていました：1 つの報告では、削除された投稿がキャッシュされた翻訳を介して引き続き表示されることがある ことが示されました（削除された投稿がまだ完全なコンテンツを表示する… ）、もう 1 つのスレッドでは、ストリーミング JSON パースが失敗した際の サイレントな切り捨て に対する修正の進捗が続けられました（翻訳がサイレントに切り捨てられる… ）。
その間、管理者はプロバイダー統合の難題に取り組んでいました：DeepSeek の「応答なし」トラブルシューティング（Discourse 接入 DeepSeek…无响应问题 、接続性の提案 ）、および Gemini エンベディング の 401 エラーは、AI Studio と Vertex/Enterprise エンドポイント間の API の不一致であることが明確になりました（Gemini エンベディングの 401 エラーの修正方法 、解決策 ）。最後に、AI キャプション サブシステムに関する継続的な作業が再浮上し、キャプションの再ビルドを切り替えるためのトグル の計画が含まれていました（AI キャプションボットの簡単な福祉チェック 、閉鎖ノート ）。
お読みいただきありがとうございます。また来週お会いしましょう！
」タイトル提案ボタンがタイトル入力フィールドの外にレンダリングされる問題を報告しました。再現コンテキストは翻訳UIの状態を指しており（例：クロアチア語のリクエスト）。
Discourse llms.txt Generator Plugin