release-noteを読み解かせる - 各種AIを触ることでキモが何かをしりたい実験メモ(15)

mastodon v4.7.5のリリースノートの記述が少し分かりにくくて、何を作業すべきか微妙にわからないな、ということで久しぶりに各種AIの作業結果を並べさせてみようというものです。
内容にそこまで差が無いのでほとんど細かい実験記録です。

共通のプロンプト

OpenWebUI経由のGemma 4 31bだけはOpenWebUIの機能でURLの先を取得させましたが、それ以外は全て以下のプロンプトです。

今回は全てのAIで見解もその導出の流れも揃っているので簡単な問題だったと言えましょう。

1つビックリしたのは、今まではテクニカルな話が苦手だったようなSakana AI Fugu Maxがちゃんと答えたところです。

そして、GrokがAI臭い文章を書いてきたことで、Sakana AIは最初から「AIくささ」の除去を徹底的にやっていたのだなと気づきました。ALGO-ARTISの方のこちらのような取り組みを最初からやっていたのかもしれません。

加えて感じるのは、「12GB VRAMのGPUで動くローカルLLMでも、日常の簡単な書き物はできちゃうじゃん」ということです。
コーディングはまだまだですし、非常に長い文章を読ませるのは難しいですが、そんな長文を普段から書かないですよね…

それぞれのAIの特徴まとめ

毎回やってる「比較まとめ」の文章をアップデート。とはいえ違いがあまり出なかったので、この比較というより直近1-2ヶ月の使用感の加筆ですね。

• 言われたことを、その意図も踏まえて愚直にこなすが、深く考えることはしないし地頭も普通なので異論は出してこない（出す時は代替案までだしきる）、単語はその単語の通りと捉えて、他の言葉の言い換えやコンテクストまでは読んでこない、比較的忠実な作業者で、相変わらず若干話が長いが、2026年後半は検索などの作業が大サービス中なので、作業代替として便利なOpenAI / ChatGPT

• 良い地頭で深く考えて、沢山の単語の意味を言い換え語も含めて知っているので、先に答えを一定程度作りつつ、作業はサボりにならない程度に程よく手を抜き、断定はせず操作者と一定異なる意見をぶつけて気づきを与えてくるが、どうもツッコミを入れるのを義務と思ってそうだし、検索などのコンピューティング資源が不足気味なのか、仕事を人間に押し戻したり、やや口数が少なくなったり、自分の知識で片付けようとする傾向がつよくなったようなAnthropic / Claude

• 異様な速度で文章を読んで整理するのに非常に長けているし、単語が持つ意味をふわっとした概念で広がりを持って理解しているが、若干読んでる文章に流されやすいし地頭がよいわけではないので構造は読めないし、単語の使い分けはルーズなので細かい言い間違えが発生してしまう（流石にネット上に溢れているサマリがある文章は正しく言えるが）し、作業は明確なサボりになりそうなぐらい手を抜くので、文章たたき台作成機として便利なGoogle / Gemini

• そこまで作業が早いわけでもなく地頭も普通（バックエンドが複数のLLM混合なのでそうなるのでしょう）だが、日本の伝統的大企業や行政機関が好む文体を徹底してだすことができ、それらの組織の中で飲み込みやすい文章を出すのに長け（でも絵文字は使う）、不要な波風を立たせずに組織を動かす材料を作ってくれる（つまりはAIくささがない文章を作れる）Sakana AI / Sakana Chat

• 性格が読み取れるほどの特徴がない、LLMがそのまま動作したような出力を見せる、ちょっとだけ中国社会を前提にした先入観がありそうなdeepseek

• Geminiと共通点は多いが、意外とGeminiよりも手を抜かない感があるGemma

• 比較的白黒をハッキリ付けて、チェックだけではなくリライトまでしてくる、ちょっとだけ中国社会を前提にした先入観がありそうなQwen

• 基本的に指示者には反論をしない前提っぽく、そこまで文章も精読しないと思わせてネット上の文書ならちゃんと作業するGrok

ChatGPT GPT-6.1 Luna - 思考

結論

リリースノートの記述は、X-Forwarded-For を利用している構成であれば、Forwarded を明示的に無効化する必要はない、という意味ではありません。

今回の修正のポイントは、Mastodon がクライアントIPアドレスの判定において、X-Forwarded-For よりも Forwarded を優先してしまう問題への対処です。

そのため、Mastodon に渡すヘッダを信頼できるリバースプロキシが適切に管理する必要があります。

特に、公式 nginx.conf に追加された

proxy_set_header Forwarded "";

は、クライアントがリクエストに付けてきた Forwarded ヘッダを、Mastodon 側に転送しないための対策です。

つまり、今回の修正は単に X-Forwarded-For の設定を変更するものではなく、信頼できないクライアント由来のIPアドレス情報が、MastodonのIP判定に使われないようにするためのものです。

1. 脆弱性の背景

今回の問題は、HTTPヘッダの Forwarded と X-Forwarded-For の優先順位に起因します。

両者は、リバースプロキシ経由でアクセスしたクライアントのIPアドレスを伝えるためのヘッダです。

• X-Forwarded-For：広く利用されている慣習的なヘッダ

• Forwarded：RFC 7239で標準化されたヘッダ

Mastodon内部ではRackがこれらのヘッダを解釈しますが、従来は Forwarded が X-Forwarded-For より優先されていました。

その結果、公式nginx.confが X-Forwarded-For を設定していても、クライアントがリクエストに独自の Forwarded ヘッダを付けて送ると、そちらがIPアドレスの判定に使われる可能性がありました。

これにより、攻撃者がIPアドレスを偽装し、IPアドレスによるアクセス制限やレート制限を回避できる問題が発生します。

これは公式のSecurity Advisoryにも明記されています。

出典：GHSA-qp4r-p842-mw5c

2. Pull Requestで行われた2つの修正

PR #41481では、実際には2段階の対策が行われています。

① Mastodon内部でのヘッダ優先順位の変更

Rack::Request.forwarded_priority = [:x_forwarded, :forwarded]

これにより、X-Forwarded-For が Forwarded より優先されるようになりました。

② nginx.confでForwardedを転送しない

proxy_set_header Forwarded "";

こちらは、クライアントが送信した Forwarded ヘッダをバックエンドに渡さないための対策です。

公式nginx.confでは、2か所にこの設定が追加されています。

出典：PR #41481 の変更内容

3. リリースノートの記述の意味

ここが今回の疑問のポイントです。

リリースノートには次のように書かれています。

これは、内部の優先順位を X-Forwarded-For 優先に変更したことによる注意事項です。

つまり、独自に Forwarded を使っている環境では、今度はクライアントが送信した X-Forwarded-For が優先されてしまう可能性があります。

そのため、Forwarded を使う環境では、クライアント由来の X-Forwarded-For を除去または上書きする必要があります。

一方、公式nginx.confを利用している環境については、別途更新を推奨しています。

これは、公式設定が X-Forwarded-For を利用しているにもかかわらず、従来はクライアント由来の Forwarded をバックエンドに通していたためです。

4. 結局、X-Forwarded-Forを利用している場合はどうすべきか

整理すると次のようになります。

結論として、リリースノートの最初の注意書きはForwardedを利用する環境に対するものですが、公式nginx.confの更新推奨には、X-Forwarded-Forを利用する環境であってもForwardedを明示的に無効化する対応が含まれています。

したがって、ご質問の認識どおり、元の公式nginx.confをそのまま使っている場合は、今回追加された proxy_set_header Forwarded ""; を反映するのが本家の推奨する対応です。

参考：

• Mastodon v4.7.5 Release Notes

• Pull Request #41481

• Security Advisory GHSA-qp4r-p842-mw5c

Claude Sonnet 5.5 - Effort 中

リリースノートとPRの内容を確認します。

結論から言うと、明示的に Forwarded を空にする対応は、リリースノートの1つ目の項目の指示ではなく、2つ目の項目（同梱 nginx.conf の更新）が実際に求めているものだと読めます。ただし、PR #41481 本体と GHSA-qp4r-p842-mw5c の本文は、このセッションからは取得できませんでした。以下のうち、変更履歴の題名と過去の勧告以外は、Rack/Rails の挙動からの推測です。

確実に言えること

• 変更履歴では、このセキュリティ修正は「Forwarded ヘッダが X-Forwarded-For より優先されてしまう問題の修正」と題され、#41481 と GHSA-qp4r-p842-mw5c が紐づいています。つまり問題の本質は「Forwarded が優先される」ことです。 github

• 過去の勧告 GHSA-c2r5-cfqr-c553 では、Rails の RemoteIp ミドルウェアが、信頼できない送信元から来た X-Forwarded-For や Client-Ip でも末尾（最も近い）のものを信頼することが問題でした。この結果、レート制限や総当たり検知を回避できました。今回も同じ系統の「クライアントIPの偽装」です。 github

• 同梱の nginx.conf は X-Forwarded-For に $proxy_add_x_forwarded_for を使っています（Forwarded は設定していません）。ここはご指摘のとおりです。

背景（推測を含む）

nginx の proxy_set_header は、指定しなかったリクエストヘッダをそのまま上流へ通します。そのため同梱設定のままだと、クライアントが送った Forwarded: for=... が、nginx に触れられずに Mastodon（Puma）まで届きます。

Rack には、Forwarded と X-Forwarded-For の両方がある場合に前者を優先する挙動があります。この点は私の記憶に基づくもので、今回確認できていません。

その場合、次のようになります。

1. nginx は X-Forwarded-For だけを正しく付け足します。

2. アプリは、クライアントが勝手に付けた Forwarded を優先して読みます。

3. 偽装したIPが remote_ip として使われます。

「Forwarded を使っていない」構成でも、攻撃者側が Forwarded を送れば被害を受け得るので、同梱 nginx.conf も影響範囲に入ります。

リリースノート2項目の意味

• アプリ側の修正（本体）: Forwarded を信用せず、X-Forwarded-For を使うようにしたと考えられます。

• 1つ目の項目: 上記の修正後は、アプリが X-Forwarded-For を見ます。そのため、Forwarded だけを付けるプロキシ構成では、クライアント提供の X-Forwarded-For が検証されずに素通りしかねません。そこで「ユーザー提供の X-Forwarded-For を無視／上書きせよ」という注意になります。これは Forwarded 方式を使っている人向けです。

• 2つ目の項目（proxy_set_header Forwarded "";）: 同梱 nginx.conf 利用者向けの多層防御です。アプリを更新しても、偽の Forwarded を上流に届けないようにします。ヘッダを空にして、そもそも渡さない対応です。

なお、nginx は空文字を指定したヘッダを上流へ送らないので、"" は「削除」の意味になります。

確認方法

PR の diff と議論、とくにコミットメッセージや Rack::Request.forwarded_priority に関連する設定変更の有無を見れば、上記の推測を裏付けられます。GHSA-qp4r-p842-mw5c の「Impact」欄にも、より正確な影響範囲が書かれているはずです。

Sources:

• Releases · mastodon/mastodon

• Release v4.7.5 · glitch-soc/mastodon

• Bypassing rate limiting with X-Forwarded-For header (GHSA-c2r5-cfqr-c553)

• mastodon/dist/nginx.conf

Gemini 3 モデル - 自動モード - 標準

Mastodon v4.7.5におけるnginx設定の修正とリリースノートの記述の背景、および本家が行った対応の意味について、以下の通り整理します。

1. 修正の背景（PR #41481 の目的）

この変更は、Mastodon（あるいはその内部フレームワークや依存ライブラリ）におけるIPアドレスの判定処理に関するセキュリティ修正（脆弱性対応）に起因しています。

Web標準では、クライアントの転送元IPを伝えるために従来の X-Forwarded-For のほか、RFC 7239で標準化された Forwarded ヘッダが存在します。Mastodonの処理系において、この Forwarded ヘッダの扱いや優先順位 に起因して、外部の悪意あるユーザーがリクエストヘッダを偽装（IPスプーフィング）できてしまう余地がありました。

これに対処するため、Mastodon側で Forwarded ヘッダの処理方法が修正されました。

2. リリースノートの記述と公式 nginx.conf 変更の真の意味

ご指摘の通り、元々のMastodon公式 nginx.conf は X-Forwarded-For を主に利用しており、Forwarded ヘッダを積極的に使う設定にはなっていませんでした。ではなぜ proxy_set_header Forwarded ""; が追加され、設定の更新が推奨されているのでしょうか。その理由は以下の通りです。

• クライアントからの「偽装ヘッダ」の侵入を防ぐため リバースプロキシ（nginx）が Forwarded ヘッダについて明示的な制御（上書きや削除）を行っていない場合、クライアント（ユーザー）が外部から意図的に偽の Forwarded ヘッダを付加してリクエストを送信できる状態になってしまいます。

• X-Forwarded-For 環境であっても無効化が必要 たとえ実際のプロキシ・バックエンド間では X-Forwarded-For を使っていたとしても、Mastodon側がもし Forwarded ヘッダも解釈（あるいは優先）するように作られている場合、ユーザーが送った Forwarded ヘッダがセキュリティ上のリスクになり得ます。 そのため、公式 nginx.conf においても 「クライアントから送られてきた余計な Forwarded ヘッダは空にして（削除して）バックエンドに伝える」 ために、proxy_set_header Forwarded ""; が追加されました。

3. まとめ：管理者が行うべき対応の意味

リリースノートの記述や公式設定の変更が求めているのは、「プロキシとMastodonの間で、クライアント由来の不正な Forwarded ヘッダが引き回されないようにする」 という防衛策です。

• もし独自の高度なリバースプロキシ構成（Forwarded をメインに使う環境など）をしている場合は、クライアント側の不正な X-Forwarded-For や Forwarded が無視されるよう設定を確認する必要があります。

• 公式提供の nginx.conf を利用している場合でも、最新のセキュリティを担保するために、追加された proxy_set_header Forwarded ""; などの変更を取り入れることが推奨されています。

sakana chat - Fugu Max - Effort 高

Mastodon v4.7.5におけるリリースノートの記述と、本家が行った修正内容（PR #41481 / GHSA-qp4r-p842-mw5c）の背景・意味は以下の通りです。

結論から言うと、提供されている nginx.conf を使っている（＝X-Forwarded-For を利用している）一般的な環境では、まさに Forwarded ヘッダを明示的に空（消去）にする対応が求められています。

1. 問題の背景（脆弱性の仕組み）

Mastodonのバックエンド（Rails / Rack）と提供されていた nginx.conf の間で、ヘッダの優先順位と通過に関する食い違いがありました。

1. Rackの優先順位のデフォルト仕様
   Mastodonが利用するWebサーバーインターフェース「Rack」は、クライアントIPを判定するヘッダとしてRFC 7239標準の Forwarded と従来の X-Forwarded-For の両方をサポートしていますが、デフォルトの優先順位は Forwarded ＞ X-Forwarded-For でした。

2. Nginx設定の盲点
   Mastodonが提供していた nginx.conf では X-Forwarded-For を付与していましたが、Forwarded ヘッダについては何も設定していませんでした。Nginxは明示的に上書き・消去しない限り、 クライアントから送られてきたヘッダをそのままバックエンドに通過させます。

3. IPアドレス偽装の発生（GHSA-qp4r-p842-mw5c）
   悪意あるクライアントが Forwarded: for=偽装IP というヘッダを付与してアクセスすると、NginxはそれをそのままMastodonへ転送します。Mastodon（Rack）側は、Nginxが付与した正しい X-Forwarded-For よりもクライアントが偽造した Forwarded を優先して採用してしまうため、IPブロックやレートリミットを容易に回避できる脆弱性がありました。

2. 本家が行った対応（PR #41481）

この問題に対し、本家はアプリケーション側とWebサーバー側の両面から対策を実施しました。

• Mastodon本体側 (config/initializers/trusted_proxies.rb)
  Rack::Request.forwarded_priority = [:x_forwarded, :forwarded] を設定し、優先順位を逆転させて X-Forwarded-* を最優先にするように変更しました。

• リバースプロキシ設定 (dist/nginx.conf)
  proxy_set_header Forwarded ""; を追加し、クライアントから送られてきた Forwarded ヘッダをNginxで消去（空化）してバックエンドに渡さないようにしました。

3. リリースノートの記述の意味

リリースノートにある2つの指示は、運用しているリバースプロキシの構成によって対象が分かれています。

まとめ

Mastodon公式設定例で Forwarded を使っていなかったからこそ、「クライアントから送られてくる偽造 Forwarded が素通りしてバックエンドで優先評価されていた」 のが根本原因です。

そのため、X-Forwarded-For を利用する標準的な構成であっても、クライアントからの不正なヘッダを遮断するために proxy_set_header Forwarded ""; による消去対応が必要となります。

deepseek - deepthink, smart検索

ご指摘の通り、リリースノートの文言と実際のPRの変更内容には一見すると矛盾があるように見えます。この背景には、「Forwardedヘッダーを『利用している』プロキシ構成」と「Mastodonが提供するnginx.confを『利用している』構成」の両方に対する注意喚起という意図があります。

📜 背景となるセキュリティ問題（GHSA-qp4r-p842-mw5c）

Mastodonのセキュリティアドバイザリ（GHSA-qp4r-p842-mw5c）では、クライアントIPアドレスのなりすましと、それによるブロック・レート制限のバイパスが報告されています。

問題の核心は、MastodonがクライアントのIPアドレスを判断する際、ForwardedヘッダーをX-Forwarded-Forヘッダーよりも優先してしまう点にありました。Mastodonが提供する標準的なnginx.confはX-Forwarded-Forを設定しますが、悪意あるクライアントが直接Forwardedヘッダーを送信すると、アプリケーション側でそちらが信頼されてしまい、IPアドレスを偽装できてしまうのです。

🔧 本家が行った対応（PR #41481）

この問題への対応として、Pull Request #41481では、nginx.confに以下の設定を追加し、クライアントから送られてくるForwardedヘッダーを明示的に無効化（空にする）しました。

nginx

proxy_set_header Forwarded "";

これにより、X-Forwarded-Forを利用している構成であっても、クライアントが送信したForwardedヘッダーはMastodonに渡らなくなり、IPアドレスの偽装を防ぐことができます。

💡 リリースノートの記述の意味

リリースノートの「If your reverse-proxy setup uses Forwarded instead of X-Forwarded-For, please make sure it ignores user-provided X-Forwarded-For headers.」という記述は、主にForwardedヘッダーを利用している（またはX-Forwarded-Forを無視する設定にしている）リバースプロキシの管理者に向けた注意喚起です。

一方で、その直後の「If you are using our provided nginx.conf, please consider updating it.」という記述が、Mastodonの標準nginx.confを利用している場合の対応を促しています。標準のnginx.confはX-Forwarded-Forを使っているため、先の「Forwardedを使っている場合」という条件には該当しませんが、前述の通りForwardedヘッダーによる脆弱性の影響を受けるため、設定ファイルの更新（proxy_set_header Forwarded "";の追加）が必要になるわけです。

つまり、リリースノートは、「Forwardedヘッダーを利用しているプロキシ」と「Mastodon標準のnginx.confを利用しているプロキシ」の両方に対して、それぞれの立場で必要な対策を促す構成になっています。ご指摘のように「明示的に空にする対応」を直接的に命じているわけではありませんが、nginx.confの更新を推奨する形で、実質的にその対応を求めていると解釈できます。

Gemma 4 31B (Open WebUI経由)

Mastodon v4.7.5におけるこの修正の背景と意図は、**「信頼できないユーザー提供のHTTPヘッダーによって、サーバーがクライアントのIPアドレスを誤認することを防ぐ」**ことにあります。

背景と問題点

今回のセキュリティ修正（GHSA-qp4r-p842-mw5c）は、Forwarded ヘッダーが X-Forwarded-For ヘッダーよりも優先して処理されるという挙動に起因しています github.com。

もしリバースプロキシ（nginx）が、クライアントから送られてきた Forwarded ヘッダーをそのままバックエンドのMastodonに転送していた場合、悪意のあるユーザーが偽装した Forwarded ヘッダーを送信することで、Mastodon側に任意のIPアドレスとして認識させることが可能になります。

本家が行った対応（proxy_set_header Forwarded "";）の意味

ご指摘の通り、提供されている nginx.conf の例では Forwarded ヘッダーを能動的に利用していません。しかし、nginxのデフォルトの挙動では、設定で明示的に上書きしない限り、クライアントから送られたヘッダーがそのままバックエンドに引き継がれる場合があります。

そこで、PRにて proxy_set_header Forwarded ""; という行を追加した意図は、**「クライアントから送られてきた Forwarded ヘッダーが存在していても、それを空にして破棄し、バックエンドに届けないように強制する」**ことです。

まとめ

• リリースノートの記述について: 「Forwardedを用いている場合は〜」という記述は、特にその設定を運用しているユーザーへの注意喚起ですが、実際には「意図せずForwardedヘッダーが通過してしまう」こと自体がリスクとなります。

• 対応の目的: X-Forwarded-For を正しく利用していても、それより優先度の高い Forwarded ヘッダーがユーザーによって注入された場合に、それが優先されてしまう脆弱性を塞ぐためです。

• 結論: リリースノートの意図は、単に設定を確認することではなく、PRにあるように**「信頼できないForwardedヘッダーを明示的に排除（空に）する」**対応を推奨しているものです。

Grok 4.6 - 高速

結論から言うと、リリースノートの記述は「明示的に Forwarded を空にする対応」を必須とは書いていませんが、本家が提供する nginx.conf を使っている場合は更新を推奨しており、PRではその具体的な防御として proxy_set_header Forwarded ""; を追加しています。

背景（問題の本質）

Mastodon（Rails/Rack）はクライアントの実IPを特定する際に、リバースプロキシが付与する転送ヘッダを信頼します。
従来、優先順位は Forwarded ヘッダが X-Forwarded-For より優先される設定になっていました（Rackのデフォルト挙動）。

• クライアントが任意に Forwarded ヘッダを送信できた場合、その値が信頼されてしまい、IPスプーフィングが可能になる。

• これにより、IPブロックやレートリミットをバイパスできる（GHSA-qp4r-p842-mw5c）。

本家の公式 nginx.conf はもともと X-Forwarded-For を正しく上書きしていましたが、クライアントが送ってきた Forwarded ヘッダをそのままバックエンドに通していたため、この問題が発生していました。

本家が行った対応の意味

PR #41481 では2つの修正が行われています：

1. Rack側の優先順位変更

ruby

Rack::Request.forwarded_priority = [:x_forwarded, :forwarded]

→ X-Forwarded-For を Forwarded より優先するように変更。
これにより、公式nginx設定のように正しく X-Forwarded-For を設定している環境では、クライアントが送った Forwarded があっても無視されるようになる。

2. 公式 nginx.conf への防御追加

nginx

proxy_set_header Forwarded "";

→ クライアントが送ってきた Forwarded ヘッダを明示的に空にしてバックエンドに渡さないようにする。
（同様に Proxy ヘッダも空にしていた既存の対策と並んで追加）

リリースノートの記述の意図

• 「Forwarded を使っている場合は、ユーザーが送った X-Forwarded-For を無視するようにしてください」
  → これは カスタムリバースプロキシで Forwarded を主に使っている人向けの注意書きです。
  （Forwarded を信頼しているのに、クライアントが送った X-Forwarded-For を残してしまうと、優先順位変更後に別の問題が起きる可能性があるため）

• 「公式 nginx.conf を使っている場合は更新を検討してください」
  → こちらが ほとんどの人に当てはまる部分です。
  公式設定はもともと Forwarded を使っていませんでしたが、クライアントが送った Forwarded を通し続けていたため、proxy_set_header Forwarded ""; を追加する更新が必要、という意味です。

まとめ

• 公式 nginx.conf をベースに使っている場合は、proxy_set_header Forwarded ""; を追加する更新が推奨されます（必須ではないが強く推奨）。

• 自前でリバースプロキシを組んでいる場合も、クライアントが送った Forwarded ヘッダをバックエンドに渡さない（空にするか上書きする）のが安全です。

• リリースノートの文言は少し抽象的ですが、PRの変更内容とセキュリティアドバイザリを合わせると、「クライアント制御の転送ヘッダを信頼しないようにする」という意図が明確です。