2026年7月~9月の連続温度計測が示す今年の夏——データが語る季節の移ろいと微気象の世界

2026年7月から9月にかけて特定の地点で実施した連続温度計測データをもとに、今年の夏の気候を技術的な視点から振り返ります。7〜8月のピークから9月に入った瞬間の急激な温度低下など、実測ロガーならではの鮮明な波形を提示。気象庁のマクロなデータと身近な微気象データの比較を通して、データ解析が明かす季節の変化と定点観測の魅力をお届けします。

はじめに:昨年の記憶と「今年の夏」の体感

昨年の夏を振り返ると、いつまでも終わらない猛暑や、秋になっても衰えない残暑の厳しさが強く記憶に残っている。連日ニュースで報じられる過酷な暑さに、「今年の夏は一体どうなってしまうのか」と気疲れした方も多いのではないだろうか。

では、それに比べて今年の夏(2026年)はどのような季節だっただろうか。世間一般の印象としては、「去年に比べると、何となく早い時期に夏がスッと終わった気がする」「ある意味で、昔ながらの平均的な夏だったのでは」と感じている人も少なくないはずだ。

こうした季節の体感を、感覚だけでなく「実際のデータ」として捉えてみると、今年の夏の輪郭がより鮮明に浮かび上がってくる。今回は、市販のロガーと自作の熱電対配線による測定システムを用いて、2026年7月から9月にかけて独自に取得した連続温度データをもとに、今年の夏の気候を紐解いていこう。


グラフが描く2026年夏:7月・8月のピークから9月の急降下へ

今回分析するのは、2026年7月1日から10月1日までの約3ヶ月間にわたり、特定の地点で連続計測された4チャンネル(No.1〜No.4)の温度データである。

グラフ全体を俯瞰すると、興味深い傾向といくつかの明確な特徴が見えてくる。

  1. 7月〜8月の推移とピーク
  • 7月に入るとともに温度は右肩上がりに上昇し、7月中下旬から8月中旬にかけて年間を通じた最高水準のプラトー(高止まり)を形成している。
  • 特に水色の線で示されたチャンネル(No.3)は、日中の日射や周囲の熱的影響を強く受けているとみられ、日々の温度変動(振れ幅)が非常に大きく、ピーク時には35℃を超えるような高い数値を示している。
  • 一方、ピンク(No.1)や黄色(No.2)といった比較的安定した環境にあるチャンネルは、日々の大きな乱高下をマイルドに受け止めながら、30℃前後のラインを推移している。
  1. 9月に入ってからの劇的な変化
  • グラフ上の大きな転換点は、9月1日の境界線を過ぎたあたりから訪れている。
  • それまで連日維持されていた30℃超のピークが明らかにトーンダウンし、グラフ全体の波形が下方へとシフトしているのがわかる。
  • 特に9月中旬以降は、最低気温・最高気温ともに一段階低い水準へと移行し、9月下旬から10月初めにかけては、最低気温が22〜23℃前後、最高気温も30℃を下回る日が明確に増加している。

昨年の夏が「いつまでも引きずるような暑さ」だったのに対し、今年のデータは、9月に入ると同時に季節のギアが明確に切り替わり、比較的スムーズに秋へと移行したことを物語っている。


気象庁データとの比較:マクロな視点とミクロな実測値

この実測データを、気象庁が発表している2026年夏の全国的な気象傾向と比較してみると、さらに興味深い事実が見えてくる。

気象庁の発表によると、2026年の夏(6〜8月)の日本の平均気温は平年を大きく上回り、統計開始以来上位に入る記録的な高温となった。西日本を中心に高気圧に覆われる日が多く、各地で「酷暑日」が観測されるなど、マクロな気象統計としては非常に厳しい暑さの夏であったことは間違いない。

しかし、今回の特定の地点における実測ロガーデータに目を向けると、気象庁の「全国的な記録的高温」という大枠のトレンドと合致しつつも、日々の生活空間や特定の設置環境における「実際の熱の抜け方」の早さが浮き彫りになる。

気象庁の広域的なアメダスデータや平均値では均されてしまう「局所的な日射の影響」「夜間の放射冷却による急激な温度低下」、そして「9月に入ってからの空気感の明確な変化」が、自作の熱電対・ロガーシステムによる高頻度サンプリングによってリアルに捉えられている。つまり、マクロな気象情報が示す「今年の暑さの総量」と、ミクロな実測データが示す「肌感覚としての季節のスピード感」の間には、緻密なグラデーションが存在しているのだ。


ロガー情報が教えてくれるもの:微気象データ解析の奥深さ

市販のロガーに熱電対を組み合わせ、自前のシステムで特定の地点の温度を長期間追いかける。こうした地道な観測を行っていると、気象庁の天気予報や一般的な気象データだけでは見えてこない、さまざまな「細部」に気づかされる。

  • どの時間帯に熱がこもりやすいのか
  • 周囲の環境(コンクリート、土、植生など)によって、どのように熱の引き方が違うのか
  • カレンダー上の季節の変わり目と、実際のデータが示す季節の変わり目にどれほどのタイムラグがあるのか

今回の2026年7月〜9月のデータは、私たちに「今年の夏は平均的ですんなり終わった」という感覚を与えてくれたが、それを支えていたのは単なる印象ではなく、微小な環境変化の積み重ねであった。


おわりに:微気象の世界は、まだまだ広がっていく

気象庁のデータは日本全体の気候を俯瞰するには欠かせないものだが、私たちが実際に暮らす空間や、庭先、建物周辺の環境は、場所ごとに全く異なる顔を持っている。

今回のようなロガーを用いた実測とデータ解析の世界は、専門機関だけの特権ではない。少しの工夫と機材があれば、身近な空間の「本当の気候」を誰でも解き明かすことができる。

今年の夏はデータ上でも比較的メリハリのある形で幕を閉じたが、身の回りの微気象を定点観測する試みは、季節の移り変わりをより深く、立体的に味わうための最高の趣味であり、知的探求だと言える。これからもデータというレンズを通して、私たちの身の回りの自然環境を静かに見つめていきたい。


関連記事

2026年秋【重要なお知らせ】還付金のご案内および口座情報確認について」は詐欺メール?国税庁(e-Tax)をかたるフィッシングがスパム判定をすり抜けた理由

「【重要なお知らせ】還付金のご案内および口座情報確認について」という国税庁(e-Tax)を名乗るメールはフィッシング詐欺です。本文とヘッダを公開し、偽物と判断できる根拠、スコア4.1でスパム判定をすり抜けた理由、対策を解説します。

この記事は、スパムアサシンやメーラーでのスパム判定をすり抜けた怪しいメールを取り扱います。その内容の判定や、設定方法の改善策について記載します。

結論から言うと、このメールは国税庁(e-Tax)を装ったフィッシング詐欺です。リンクは開かず、メールは削除してください。

2026年10月11日(日)の夜、筆者のもとに「【重要なお知らせ】還付金のご案内および口座情報確認について」という件名のメールが届きました。差出人は「e-Tax」、アドレスは国税庁の正規ドメインである info@e-tax.nta.go.jp です。ところがヘッダを調べると、国税庁のサーバーから送られたものではないことがはっきり分かります。

同じ日に届いた別文面のe-Tax偽装メールは、前回の記事で取り上げました。今回は文面も送信元IPアドレスも別ですが、送信ソフトの表記(Foxmail)、時刻の表記(+0800)、送信ドメイン認証の失敗など、共通する特徴があります。同じ系統の配信とみられます。

そして今回も、SpamAssassinの判定は「スパムではない」でした。スコアは4.1点(この環境のしきい値は30.0点)で、迷惑メール扱いにならず、そのまま受信箱に届いています。

自分に届いたメールと照合する

お手元のメールが同じものか、次の項目で確認できます。本文の金額などは、配信ごとに異なる可能性があります。

項目内容
件名【重要なお知らせ】還付金のご案内および口座情報確認について
差出人表示"e-Tax" <info@e-tax.nta.go.jp>
受信日時2026年10月11日(日)20:54(日本時間)
本文の金額と期限還付金確定金額:93,500円 / お手続き期限:令和8年10月12日
送信元IPアドレス120.35.201.239
Message-ID<20261011195412267182@e-tax.nta.go.jp>
送信ソフトの表記Foxmail 6, 13, 102, 15 [cn]

背景:情報漏洩が詐欺メールの精度を上げている

昨今、各社から不正アクセスによる個人情報漏洩の報告が相次いでいます。問題は、単にメールアドレスが漏れたということにとどまりません。

メールアドレスとサービスの利用情報が一緒に漏れれば、そのサービスを名乗る詐欺メールの精度は上がります。極端な話、利用しているサービスから届いた「あなたの個人情報が漏れました」というお知らせメール自体が、詐欺である可能性さえあります。

フィッシング対策協議会も、フィッシングメールが届くということはメールアドレスがインターネット上に漏えいしていることを意味し、漏えいした情報は犯罪者の間で売買されて消せない、と注意喚起しています。

今回のメールは宛名のない汎用の文面で、特定サービスの漏洩情報を使った形跡はありません。それでも、国税庁という「自分にも関係があるかもしれない」組織を名乗ることで、受信者を選ばずに信じさせる作りになっています。こうしたメールが届く前提で、判定をすり抜けたときの備えを整えておく必要があります。

届いたメール(受信したままの記録)

以下は受信したメールの件名、本文、ヘッダです。公開にあたり、次の方針で扱っています。

  • 受信者のアドレスと受信サーバーが特定できる部分は「******」に置き換え、受信サーバーが付けた署名などの行は省略しました
  • 送信側の情報(差出人、送信元IPアドレス、Message-IDなど)は、お手元のメールと照合できるよう、そのまま掲載しています
  • 誤字や不自然な表記も、原文のままです

件名

【重要なお知らせ】還付金のご案内および口座情報確認について

本文

【重要なお知らせ】還付金のご案内および口座情報確認について


国税e-Tax
住宅借入金等特別控除の還付金について
令和7年度分の所得税について、還付金が確定いたしました。
下記のとおりご案内いたします。
還付金確定金額:93,500円
お手続き期限:令和8年10月12日
受付日時:2026年10月11日
還付金のお受け取りには、下記よりe-Taxログインのうえお手続きください。

■ご利用確認はこちら

---------------------------------------------------------------
※必ず期限内にご確認いただきますよう重ねてお願い申し上げます。
【ご注意事項】 ·メッセージボックスの内容確認には、マイナンバーカード等の電子証明書による認証が必要です。
還付金の振込には、別途お手続きが必要な場合がございます。詳細は通知書をご参照ください。
e-Taxのご利用可能時間は、e-Taxボームページにてご確認いただけます。 本メールは送信専用です。
ご返信いただいてもご対応いたしかねますのでご了承願います。
 e-Taxホームベージにおける個人情報保護方針
 1. 基本的考え方 国税庁では、e-Taxホームページ(ドメイン「www.e-tax.nta.go.jp」)において提供するサービス(情報提供、各種意見の受付等)の円滑な運営に必要な範囲で情報を収集しています。
収集した情報は利用目的の範囲内で適切に取り扱います。
 2. 収集する情報の範囲 当サイトでは、インターネットドメイン名、IPアドレス、閲覧情報等を自動的に収集します。ー部サービスにおいてクッキーを使用する場合がありますが、個人を特定する情報は取得いたしません。
https://net.kojinbango-card.go.jp/SS_SERVICE_OUT/FA01S001Action.do
(※) マイナンバーカード方式について
マイナンバーカード方式の概要
e-Taxへのログインにあたっては、利用者識別番号(数字16桁)及びパスワードの入力が必要ですが、 マイナンバーカード (※) を事前に登録するだけで、利用者証明用電子証明書の暗証番号(数字4桁)を入力することでe-Taxへログインが可能になります。
(※) 「スマートフォンのマイナンバーカード」 も利用可能です。
https://www.e-tax.nta.go.jp/kojin/mycd_login.htm#anc05
マイナンバーカード方式のメリット
利用者識別番号(数字16桁)及びパスワードの管理が不要です。
マイナンバーカード方式でログインした場合、利用者識別番号は「マイページ」の「基本情報」メニューから、パスワードは「マイページ」の「その他の登録情報」メニューから確認できます。
https://net.kojinbango-card.go.jp/SS_SERVICE_OUT/pages/ssf/FG01S001.jsp
e-Taxを利用するために事前準備として必要であった電子証明書の登録が不要です。
マイナンバーカードの電子証明書(有効期限:5年間)が失効した場合は、市区町村の窓口で電子証明書の更新を行うことで、e-Taxをご利用いただけます。
https://services.digital.go.jp/mynumbercard-android/#%E4%BD%BF%E3%81%88%E3%82%8B%E5%A0%B4%E6%89%80%E3%82%84%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9
「スマートフォンのマイナンバーカード」も利用可能です。
マイナンバーカードを取得されている方は、お持ちのスマートフォンにマイナンバーカード(Android™については「スマホ用電子証明書」のみ対応(※)。)を搭載することができます。
「スマートフォンのマイナンバーカード」を利用すれば、マイナンバーカードをスマートフォンにかざすことなく、申告書の作成・e-Tax送信が可能となります。
また、利用者用電子証明書に設定したパスワード(4桁の数字)を入力する代わりに、生体認証が利用できます。(機種によって異なります。)
詳細や申し込み方法については、デジタル庁HPの「スマートフォンのマイナンバーカード」をご確認ください。
https://www.digital.go.jp/policies/mynumber/smartphone-certification#service
(※)Android™に搭載できる「スマホ用電子証明書」には、マイナンバーカードに記載された氏名、住所、生年月日及び性別並びにマイナンバー(基本4情報等)は搭載されていません。そのため、e-Taxのマイページから初めて「給与所得の源泉徴収票情報の取得希望の手続」を行う場合など、基本4情報等をe-Taxへ提供していただく際には、マイナンバーカードを読み取る必要があります。
----------------------------------------------------------------------------------
国税庁  〒100-8978  東京都千代田区霞が関3-1-1  法人番号7000012050002

国税庁Copyright © NATIONAL TAX AGENCY ALL Rights Reserved.

「■ご利用確認はこちら」の部分には、リンクが設定されているとみられます。リンク先のURLは本稿では掲載しません。【編集メモ:リンク先URLが分かる場合は hxxps://example[.]com のように無効化して追記。確認していない場合は「リンク先は確認していません」と記載】

ヘッダ(公開用に整形)

Return-Path: <info@e-tax.nta.go.jp>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ******.jp
X-Spam-Level: ****
X-Spam-Status: No, score=4.1 required=30.0 tests=HTML_FONT_FACE_BAD,
    HTML_MESSAGE,RDNS_NONE,SPF_FAIL,SPF_HELO_FAIL,URIBL_ABUSE_SURBL,
    URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS,URIBL_PH_SURBL,
    URIBL_ZEN_BLOCKED_OPENDNS autolearn=no autolearn_force=no version=3.4.6
Delivered-To: ******@******.jp
Received: from e-tax.nta.go.jp (unknown [120.35.201.239])
    by ******.jp (Postfix) with ESMTP id ******
    for <******@******.jp>; Sun, 11 Oct 2026 20:54:15 +0900 (JST)
Authentication-Results: ******.jp;
    dkim=none;
    dmarc=fail reason="No valid SPF, No valid DKIM" header.from=e-tax.nta.go.jp (policy=none);
    spf=fail (******.jp: domain of info@e-tax.nta.go.jp does not designate 120.35.201.239 as permitted sender) smtp.mailfrom=info@e-tax.nta.go.jp
Date: Sun, 11 Oct 2026 19:53:58 +0800
From: "e-Tax" <info@e-tax.nta.go.jp>
To: <******@******.jp>
Subject: =?utf-8?B?44CQ6YeN6KaB44Gq44GK55+l44KJ44Gb44CR6YKE5LuY6YeR44Gu44GU5qGI5YaF44GK44KI44Gz5Y+j?=
    =?utf-8?B?5bqn5oOF5aCx56K66KqN44Gr44Gk44GE44Gm?=
Message-ID: <20261011195412267182@e-tax.nta.go.jp>
X-mailer: Foxmail 6, 13, 102, 15 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
    boundary="=====003_Dragon478065417446_====="

偽物と判断できる根拠

1. 国税庁が説明する「本物のe-Taxメール」と違う

国税庁は、e-Taxを装った不審なメールへの注意喚起ページで、本物のe-Taxメールの特徴を説明しています。このメールと並べると、次のとおり食い違います。

国税庁の説明このメール
送信元表記は「e-Tax(国税電子申告・納税システム)」に統一されている表示名は「e-Tax」のみ
定型の文面で、本文にURLは原則記載しない「■ご利用確認はこちら」からe-Taxログインへ誘導している
宛名は、利用者が登録したものが表示される宛名がない
還付金額を表示したメールは送らない「還付金確定金額:93,500円」と表示している
手続や納付を催促するメールは送らない「お手続き期限」を示し、「必ず期限内に」と促している

差出人のアドレス info@e-tax.nta.go.jp は本物と同じです。アドレスだけでは見分けられないので、表示名や本文の作りも合わせて確認する必要があります。国税庁は2026年10月16日(令和8年10月16日)の更新で、還付金額を表示して受取手続きをうながす類似のメールを、不審なメールの最近の事例として追加しています。

2. 本文が不自然

  • 「令和7年度分の所得税」という言い方は通常使いません。所得税は「令和7年分」と呼びます
  • 受付日時は西暦(2026年10月11日)、期限は和暦(令和8年10月12日)で、表記が混在している
  • 期限はメールが届いた翌日の10月12日で、しかもスポーツの日(祝日)。届いたのは日曜の夜で、考える時間を与えない作りになっている
  • 件名は「口座情報確認」だが、本文には口座の話がなく、ログインを促すだけ。リンクの文言は「ご利用確認はこちら」で、還付とも口座とも合っていない
  • 「e-Taxボームページ」「e-Taxホームベージ」(正しくは「ホームページ」)、「ー部サービス」(漢数字の「一」ではなく長音記号)、文頭の中黒「·」など、公式文書をコピーして加工した形跡がある
  • 後半は、マイナンバーカード方式の説明や個人情報保護方針が長々と続く。公式サイトの文章を流用したとみられ、e-tax.nta.go.jp、kojinbango-card.go.jp、digital.go.jp など本物のリンクも混ざっている。本物のリンクや文章が含まれていても、本物の証拠にはなりません

3. ヘッダが「国税庁から来ていない」ことを示している

調べた項目このメールの値分かること
SPFfail(120.35.201.239 は info@e-tax.nta.go.jp の送信元として許可されていない)国税庁ドメインの正規の送信元ではない
DKIMnone電子署名がない
DMARCfail(No valid SPF, No valid DKIM / policy=none)SPFもDKIMも成立していない。ただし送信ドメイン側のポリシーは none
送信元IPアドレス120.35.201.239(受信時は逆引きできず)HELOでは e-tax.nta.go.jp を名乗っているが、実体と一致しない(SPF_HELO_FAIL)
IPアドレスの所属解析結果(下の「参考」)では、このIPを含む 120.32.0.0/13 は AS4134(CHINANET BACKBONE)として経路が広告されている中国の通信事業者のアドレス帯で、国税庁の設備とは考えにくい。動的に割り当てられた回線とみられる(詳しくは下の「参考」)
送信ソフトX-mailer: Foxmail 6, 13, 102, 15 [cn]中国で広く使われるメールソフトの名乗り。官公庁が使うとは考えにくい
送信日時Date: 19:53:58 +0800日本標準時は+0900。日本時間では20:53:58で、受信側の受付時刻(20:54:15)とは矛盾せず、送信側の端末が+0800設定だったことを示唆する
Message-ID<20261011195412267182@e-tax.nta.go.jp>ドメイン部分も国税庁を名乗っている
Return-Pathinfo@e-tax.nta.go.jpSPFの検査対象になる送信者アドレスも、国税庁を名乗っている

4. 同じ件名が、フィッシング対策協議会の注意喚起に載っている

フィッシング対策協議会は2026年9月30日、国税庁をかたってAndroidスマートフォン用の不正アプリのインストールなどへ誘導するフィッシングメールの注意喚起を出しました。メールの件名の例として、今回と同じ「【重要なお知らせ】還付金のご案内および口座情報確認について」が挙げられています。同協議会は、2026年9月30日時点でスマートフォン用のe-Taxアプリは提供されていないとしています。

このメールのリンク先がどう動作するかは、本稿では確認していません。

参考:送信元IPアドレスの解析結果

送信元IPアドレス 120.35.201.239 を、IPアドレスの情報サービスで調べた結果です。位置情報は推定値で、接続元の回線がある場所の目安にすぎません。送信者本人の所在地を示すものではありません。

項目結果
IPアドレス120.35.201.239
ホスト名239.201.35.120.broad.sm.fj.dynamic.163data.com.cn
国China
地域Fujian
市区町村Sanming(推定)
郵便番号365000(推定)
緯度・経度26.2638, 117.639(推定)
タイムゾーンAsia/Shanghai
ISPChinanet
組織Chinanet FJ
AS番号AS4134 CHINANET BACKBONE
CIDR120.32.0.0/13
開始アドレス120.32.0.0
終了アドレス120.39.255.255

読み取れることは、次の3点です。

  • 一般向けの回線から送られたとみられる。 ホスト名の broad と dynamic は、通信事業者が回線の利用者に動的に割り当てるアドレスによく見られる形式です。国税庁のメールサーバーのアドレスではありません。ただし、回線の持ち主が送信者本人とは限らず、踏み台にされた機器の可能性もあります
  • 時刻の表記と方向が一致する。 タイムゾーンが Asia/Shanghai(+0800)なのは、メールの Date: ... +0800 と一致します。送信ソフトの [cn] 表記も同じ方向です。ただし、これらは偽装できるため、所在地を断定する根拠にはなりません
  • 受信時の逆引き結果とは異なる。 受信時のヘッダでは、送信元は unknown(RDNS_NONE)でした。今回の解析ではホスト名が得られています。Postfixは、逆引きで得た名前を正引きしても元のIPアドレスに戻らない場合も unknown と表示するため、動的回線に多い「逆引きだけが設定され、正引きがない」状態だった可能性があります。本稿では正引きまでは確認していません

なぜスパム判定をすり抜けたのか

SpamAssassinが付けた判定は、次のとおりでした。

X-Spam-Status: No, score=4.1 required=30.0 tests=HTML_FONT_FACE_BAD,
    HTML_MESSAGE,RDNS_NONE,SPF_FAIL,SPF_HELO_FAIL,URIBL_ABUSE_SURBL,
    URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS,URIBL_PH_SURBL,
    URIBL_ZEN_BLOCKED_OPENDNS autolearn=no autolearn_force=no version=3.4.6

各検査項目の意味は次のとおりです。

検査項目意味
HTML_MESSAGEHTMLメールである(情報のみ)
HTML_FONT_FACE_BADHTMLのフォント指定が不自然
RDNS_NONE受信時に、送信元IPアドレスの逆引きができなかった
SPF_FAIL送信者アドレスのドメインが、SPFの検査に失敗した
SPF_HELO_FAILHELOで名乗ったドメインも、SPFの検査に失敗した
URIBL_ABUSE_SURBL本文中のURLが、SURBLのabuseリストに該当した
URIBL_PH_SURBL本文中のURLが、SURBLのフィッシングリストに該当した
URIBL_BLOCKED / URIBL_DBL_BLOCKED_OPENDNS / URIBL_ZEN_BLOCKED_OPENDNSブロックリストへの問い合わせ自体が断られ、検査できなかったことを知らせる管理者向けの通知

ここから読み取れることは、次の4点です。

  • 点数が足りない。 合計は4.1点です。SpamAssassinの標準のしきい値5.0点でも通過する点数で、この環境のしきい値は30.0点でした。スコアの積み上げだけで止めるのは難しい状況です
  • フィッシングURLのリストに載っていても、加点は小さい。 URIBL_ABUSE_SURBL と URIBL_PH_SURBL の2つに該当しながら、合計は4.1点にとどまりました
  • ブロックリストの照会3件が、実質機能していない。 BLOCKED を含む3つは「該当した」ではなく「問い合わせを断られた」という意味です。公開DNSリゾルバー経由の問い合わせなどは、ブロックリスト側が受け付けないことがあります。検査できていないので、これらのリストに載っていたかどうかは分かりません
  • DMARCの結果は、スコアに入っていない。 tests= の一覧にDMARC関連の項目はありません。dmarc=fail は Authentication-Results ヘッダにだけ記録されています。しかも送信ドメイン側のポリシーは policy=none で、認証に失敗しても拒否や隔離を求めていません

つまり「認証に失敗している」という最も強い手がかりが、スコアにはほとんど反映されていません。そこで、スコアとは別に、認証の失敗そのものを条件にして振り分ける対策が有効になります。

対策1:送信認証の失敗を条件に振り分ける

「スコア」ではなく「認証の失敗」を条件にする方法です。政府機関のように送信ドメイン認証を整えているはずのドメインを名乗り、かつ認証に失敗しているメールは、ほぼ偽物とみなせます。

筆者が使っているThunderbirdの設定は、前回の記事で紹介したものと同じです。

  1. メニューの「ツール」→「メッセージフィルタ」を開く
  2. 「新規」を選び、条件の項目で「カスタマイズ」から Authentication-Results を追加する
  3. 「次の文字列を含む」で spf=fail と dmarc=fail の両方を条件にする(「すべての条件に一致」)
  4. 動作は「削除」ではなく「ゴミ箱へ移動」または専用フォルダへの移動にする

今回のメールのヘッダにも spf=fail と dmarc=fail の両方が含まれているので、同じ条件で捕捉できます。注意点は2つあります。

  • Authentication-Results は受信サーバーが付けるヘッダです。お使いの環境のメールに付いているか、先に確認してください(ヘッダの見方は前回の記事にまとめています)
  • 認証の失敗は、転送やメーリングリストを経由した正規メールでも起こります。振り分け先のフォルダは、週に1回程度、差出人と件名を確認してください

対策2:サーバー側のスコア設定を見直すときの考え方

  • しきい値を下げる。 今回の4.1点を止めるには、しきい値を4.0点以下にする必要があります。そこまで下げると、正規メールの誤判定が増えます。判定結果を「削除」や「破棄」にしている場合は、誤判定で正規メールが戻せなくなるため、特に慎重に検討してください
  • ブロックリストの照会が拒否されていないか確認する。 ヘッダに BLOCKED を含む項目が出ているなら、その検査は働いていません。自前でサーバーを運用している場合は、SpamAssassinが参照するDNSを、自分で用意したキャッシュDNSサーバーに切り替える方法があります。レンタルサーバーでは利用者が変更できないことが多いので、サーバー事業者への確認や、サービス選びの材料になります
  • 自前のSpamAssassinなら、認証失敗にルールを追加する。 SPF失敗とDMARC失敗が重なったときに大きく加点するルールを足す方法です。設定方法は、要望があれば別記事で取り上げます

対策3:メールのリンクから手続きしない

国税庁によると、e-Taxから送るメールは定型の文面で、本文にURLは原則記載されません。フィッシング対策協議会も、e-Taxから通知が来た場合は登録済みの環境からメッセージボックスを確認するよう呼びかけています。

  • 本文にURLのあるe-Tax通知は、その時点で疑う
  • 還付や期限の連絡が気になったら、メールのリンクではなく、ブックマークしておいた公式サイトから自分でe-Taxにログインして確認する

もしリンクを開いてしまったら

状況別の対処は、前回の記事に詳しくまとめています。要点は次のとおりです。

  • 開いただけで何も入力していない場合: ブラウザを閉じ、念のため履歴とキャッシュを削除する
  • IDやパスワードを入力した場合: 公式サイトから直ちに変更し、同じパスワードを使い回しているサービスもすべて変更する。マイナンバーカードの暗証番号を入力した場合は、カードの一時利用停止も検討する(マイナンバー総合フリーダイヤル 0120-95-0178)。クレジットカード情報を入力した場合は、カード会社にすぐ連絡する
  • アプリをインストールしてしまった場合: 機内モードでネットワークを遮断し、アプリをアンインストールしてウイルス対策アプリでスキャンする。銀行・証券・クレジットカードなどのパスワードも変更する
  • 相談先: 警察の相談窓口 #9110、消費者ホットライン 188、最寄りの税務署

同じようなメールを受け取ったら、フィッシング対策協議会への報告もお願いします。国税庁の不審なメールや電話に関する注意喚起も参考になります。

よくある質問

Q. 「【重要なお知らせ】還付金のご案内および口座情報確認について」というメールは本物ですか?

A. 偽物です。国税庁は、還付金額を表示したメールは送らないと説明しています。ヘッダも、国税庁のサーバーから送られていないことを示しています。

Q. すでにリンクをクリックしてしまいました。

A. 何も入力せず、アプリもインストールしていなければ、大きな被害の可能性は低いです。ただし、上の「もしリンクを開いてしまったら」を確認してください。

Q. 迷惑メールフォルダに入っていないのはなぜですか?

A. SpamAssassinのスコアが4.1点で、しきい値に届かなかったためです。DMARCの失敗はスコアに入っておらず、送信ドメイン側のポリシーも none だったため、受信側でそのまま配信されました。

Q. 本物のe-Taxからのメールかどうか、どう確認すればいいですか?

A. メールのリンクは使わず、ブックマークした公式サイトから自分でe-Taxにログインして、メッセージボックスを確認してください。国税庁によると、本物の通知メールは定型の文面で、本文にURLは原則記載されず、宛名を登録していればその宛名が表示されます。

まとめ

  • 「【重要なお知らせ】還付金のご案内および口座情報確認について」は、国税庁(e-Tax)を装うフィッシングメールです
  • 還付金額の表示、本文のリンク、宛名の欠落、不自然な日本語、ヘッダの認証失敗から、偽物と判断できます
  • SpamAssassinのスコアは4.1点(しきい値30.0点)で、判定をすり抜けました。ブロックリストへの照会も3件が拒否され、DMARCの結果はスコアに入っていませんでした
  • スコアに頼らず、spf=fail と dmarc=fail を条件にしたフィルタが有効です。ただし、振り分け先のフォルダは定期的に確認してください

関連記事・参考情報

関連記事(このサイト)

参考

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意します。コメントでお知らせください。

この記事は2026年10月31日時点の情報です。手口は変化するため、最新の注意喚起は国税庁やフィッシング対策協議会の公式サイトでご確認ください。

過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたしま。コメントとをお願いします。

2026秋 シナリオから動画を、手元のPC(LLM)だけで自動で作るシステムが稼働(自動動画生成)

InIns’s (アイシズ) 開発記 2026年10月25日〜30日の6日間のまとめ

文章のシナリオを渡すと、場面ごとの画像と動画を自動で作り、最後に1本につなぐ。そんなツールを、ローカルのLLMと画像・動画生成モデルだけで作っています。この記事では、6日間でできたこと、測った数字、つまずいた点、そして第一弾の動画から見えた課題を書きます。

第一弾の動画(縦・14場面・28秒)をここに入れます第一弾:MV『システムアラート』の試作。青と白の管理都市に、赤いノイズが侵食していく構成。生成の音はなし。

つくっているもの

役割の違う2台のPCを使います。重い生成は、RTX 3080(VRAM 10GB)の生成用PCが受け持ち、依頼や受け取り、結合は、GPUの弱い操作用PCから行います。操作用PCは、同じ部屋のLAN内でつながっているだけで、外には公開していません。

シナリオ→外部AI(依頼文を貼る)→プロンプト一覧(JSON)→常駐サーバー→ComfyUI→動画を受け取って結合

画像は FLUX.2 klein 4B、動画は Wan2.2 14B(ほかに MiniMax H3 も登録)、文章の相手には Ollama 上の gemma4:26b を使っています。シナリオから場面ごとの一覧を作る部分は、手元のLLMではなく、外部のAI(Grok や Gemini)にチャットで任せる設計にしました。

6日間の経過

日できたこと
10/25〜27方針と決めごとを文書化。ComfyUIのワークフローをAPI形式で4本書き出し、最小のプログラムで動画を1本生成(2秒・640×640・602秒)。
10/28LLMと生成モデルを同時に載せたときのメモリを実測。操作用PCから依頼して生成用PCで動画ができる「段階A」が完成。ライセンスを調べ、画像モデルをFLUX.2 devからklein 4Bへ変更。
10/29文から画像、参照画像から画像、HD動画を追加。前の成果物を画像として再利用する書き方を整備。Chatと生成を1本にまとめたサーバー(inins)を作成。一覧を一括で頼む仕組みを追加。
10/30外部AIが作った28行の一覧が1回で通り、全部生成。動画をつなぐコマンドと、操作用PCの管理画面(inins2)を追加。
システムアラート1回目版

測ってわかったこと

作業時間
Wan2.2 動画2秒(640×640)258秒(モデル読み込み済み)/約600秒(読み込みから)
Wan2.2 動画2秒(縦480×832/横1280×720)595秒/631秒。HDにしても時間はほぼ変わらず
klein 4B 蒸留版 アイキャッチ2枚(1600×896)49秒(初回)、10秒(2回目)
klein base 4B 同じ条件225秒。蒸留版の方が圧倒的に速い
参照画像から画像(昼を夕方に直す)41秒
gemma4:26b の読み込み毎回約2分(GPU 39%/CPU 61%で動作)

動画の生成中はRAMの空きが2〜4GBしかなく、LLMと同時に載せるのは現実的ではありません。そこで「GPUの仕事は1度に1つ」とし、動画を作る前にLLMを外す運用にしました。動画は1本約10分なので、14本なら単純計算で2時間強。長編では待ち時間の設計が重要になります。

つまずいたこと

  • ライセンス。画像モデルFLUX.2 devは非商用ライセンスで、発信用の制作には使えないと判断し、Apache 2.0のklein 4Bへ切り替えました。9Bも非商用でした。MiniMax H3は商用可ですが、使う場合は動画の説明文に明記します(開発中に確認した範囲なので、公開前には一次情報を確かめます)。
  • ワークフローの書き出しミス。画像から動画の入力がフレームの「最後」につながっていた、UNETに別モデルが入っていた、など。中身を読んで直しました。
  • 手順書の細かな誤り。PowerShellにcmdの書き方を示した、別のPCで実行された、など。以後は、貼ればそのまま動く形で示す決まりにしました。
  • 小さなLLMの限界。手元のgemmaにファイルを読み書きさせると、文字化けを正常な結果として受け取り、書き換わっていないのに「完了」と答えました。原因は、道具のエラーの返し方にありました。

第一弾の動画から見えた課題

元のシナリオは3分15秒の曲ですが、できた動画は28秒でした。時間の情報は一覧の形に入っておらず、依頼文の例が「2秒」だったため、外部AIがその値を全行に写したのが主因です。次の版では、作品全体の向き・大きさ・長さ・音の扱いを最初に決めて強制し、場面ごとの時間も一覧に持たせます。

音もありません。Wan2.2は音を作れないためで、音つきならMiniMax H3、または曲を重ねる指定が必要です。登場人物の固定も未対応で、同じ少女が毎回別の顔になります。キャラクターを登録し、一覧から参照する仕組みを作ります。

依頼文を作る、返事を貼って確かめる、誤りがあれば直しの依頼文を作る、という手順は、人の作業が片道2つ(貼る・ドロップ)で済むようにしてあります。

これから

  • 全体の所要時間の見積もりを、確かめの段階で出す
  • 手元の小さなLLMに、依頼の仕分けだけを任せる(15件の試験で最も良かったqwen3:4bが11件正解。決まりと似た例を足して精度を上げる)
  • 作品の設定、場面の時間、キャラクターの固定、音の指定
  • できた動画の自動チェックと、撮りためた実写からの場面抽出(将来)

関連記事

2026年秋LLMはここまで来た。 ローカルLLMに手足をつける?! ClaudeDesktopのようなコード開発支援ツールに仕立ててみる

2026年秋時点で、ローカルLLMはツール呼び出しにより「手足」を持たせやすくなっている。ファイル書き込みとコード実行の簡単な仕組みを組んだところ、Gemma4がランダムCSVの生成とソートをほぼ自律的に完了。OpenCodeやGoose、MCPなどの既存ツールと組み合わせれば、さらに実用的なローカルコーディングエージェントが作れる状況だ。

2026年秋LLMはここまで来た。

ローカルLLMに手足をつける?! Claude Desktopのようなコード開発支援ツールに仕立ててみる。 Visual Studio Code + Clineで試してみて、重くてほぼ使い物にならなかったので半分かきらめていたが、自分で作ってみたほうが軽くできるのでは?ということで試してみた。

2026年秋、ローカルで動くLLMは「ただのチャット」から、かなり実用的な「作業者」に近づいてきた。

特にGoogleのGemma 4シリーズ(例: gemma4:26b、MoEでアクティブパラメータ約4B)は、ツール呼び出し(function calling)を標準でサポートし、長コンテキスト(大きいサイズで256K)、コーディング能力、マルチモーダル対応を備えている。Ollamaやllama.cpp、LM Studio経由で、比較的手軽に動かせるサイズ感だ。

ここに「手足」を付ける——つまり、ファイルの読み書きやPython実行などのツールを与えて、モデル自身にコードを書いて実行させるループを組むと、Claude DesktopやClaude Code、OpenCodeのようなコーディング支援エージェントに近い振る舞いが、ローカルでも再現できる。

実際に簡単な仕組みを組んで試してみたところ、想像以上にすんなり動いた。

簡単な実験:ランダムCSV生成とソート

使用モデルは gemma4:26b。ツールとして「ファイルを書く(write_file)」と「Pythonを実行する(run_python)」を用意しただけの、かなり素朴なエージェントループだ。

AIデータ処理ワークフロー
AIデータ処理ワークフロー

依頼1:ランダムな2列CSVを1万行作る

ユーザーの指示:

2項目の値の、csvファイルを作成するpythonコードを作成し実行してください。
コード名 randm.py、生成するファイル名 rand2026.csv。
10025,44557
10256,55455
…
というような、2元の整数の組のファイルです。
それぞれの数字は 1~99999999 の間の整数でランダム。これを1万行書き出す。

モデルはコードを書き、ファイル名を一度間違えたものの自分で修正し、実行した。結果:

Successfully created rand2026.csv with 10000 rows.

中身を確認したところ、範囲内のランダムな整数ペアが1万行、妥当に生成されていた。

依頼2:1列目でソートして別ファイルに出力

続けて:

rand2026.csv の1項目目の数値で、行ソートするプログラム(sort_gemma4.py)を作成し rgema.csv にソート結果を出力してください。

モデルは csv モジュールを使い、1列目を整数として比較してソートするコードを書き、実行。

Successfully sorted rand2026.csv and saved to rgema.csv

ソート結果も正しい内容になっていた。一連の作業はおよそ10分程度で完了。

モデルが「コードを書いて→実行して→結果を確認して次へ進む」という流れを、ほぼ自律的にこなした。最初はファイル名を少し間違えたが、すぐに直している。これは「手足」がちゃんと機能している証拠だ。

なぜこれが「厳しい」のか

この程度の仕掛けは、ツール呼び出しをサポートしているモデル(Gemma 4、Qwen系、Llama系など)と、Ollamaなどのランタイムがあれば、比較的短時間で組める。

すでにオープンソースのコーディングエージェントは充実している:

  • OpenCode:ターミナル中心、75以上のプロバイダ対応、ローカルモデルも可能。Claude Codeに近い体験をオープンに。
  • Goose(Block発、Apache-2.0):MCPベースの拡張性が高く、完全オフライン運用も可能。
  • Aider:Git統合が強く、軽量で小さなモデルでも動きやすい。
  • Cline や各種MCPサーバー:Claude Desktopにファイルシステムやターミナル、デスクトップ操作を追加する仕組みが成熟している。

Ollamaには ollama launch claude --model gemma4:... のような起動支援もあり、Claude Code自体をローカルモデルで動かす道も広がっている。MCP(Model Context Protocol)経由でファイル操作やコマンド実行を安全に(あるいは許可制で)行える環境が整いつつある。

つまり、「それなりに能力がある人が作ったら、すぐにローカルLLMでも高度なことができる」状態に、すでになっている。コードを書いて実行し、結果を見て次の手を打つ——このループさえ回せれば、CSV生成のような単純作業だけでなく、より複雑なデータ処理やスクリプト作成、反復的な検証もこなせる。

現実的な限界と注意点

もちろん、クラウドの最上位モデル(ClaudeやGPT系の最新)と比べると差はある。

  • ツール呼び出しの安定性や、長いコンテキストでの一貫性はまだモデル依存。
  • 速度はハードウェア次第。GPU/Apple Siliconでそこそこ速くても、複雑な多段思考は時間がかかる。
  • コード実行は強力な分、サンドボックスや許可確認が必須。不用意に広い権限を与えるとリスクがある。
  • 大規模なコードベースの理解や、長期的なプロジェクト管理では、まだクラウド側に分があることが多い。

それでも、「自分のマシンだけで、データを外に出さずに、コストを気にせず作業できる」価値は大きい。特に機密データやオフライン環境では明確な優位性がある。

おわりに

2026年秋のローカルLLMは、単に「動く」だけでなく、「手足を付ければ実用的な作業者になれる」段階に来ている。

今回の実験はごく単純なものだが、それで十分な結果が出たことが重要だ。OpenCodeやGoose、MCP対応のツールを組み合わせ、Gemma 4やQwen系のモデルを載せるだけで、Claude Desktop的な体験のかなりの部分をローカルで再現できる。

これからの競争は、「モデル単体の賢さ」だけでなく、「いかに適切な手足(ツール)と安全な実行環境を組み合わせるか」に移っていくのだろう。ローカルでここまでできるなら、クラウドとの使い分けやハイブリッドな運用も、より現実的になってきた。

参考にした操作の記録は、ランダムCSVもソート結果も妥当な内容で、一連の作業が短時間で完了したことを示している。少し複雑な実装でも、同じ仕組みで試す価値は十分ありそうだ。

しかし、ここまでくると悪用も容易にできそうな状態になっていることがよく分かる。攻めと守りでは、攻めのほうが有利である。わずかでも穴を見つければよいからだ。守る側は穴がないように作り上げる必要があるが、それはなかなか難しい。

破られたことを早期に検知し、被害を抑え、いかに早く復旧するかという世界に変わっていくかもしれない。ただしそれは、一通りしっかり守る仕掛けを用意してからの話だろう。

似たような話は昨今の水害にも通じるかもしれない。少しでも穴があると堤防は崩壊する。いかに避けにくいか、早く復旧するかが重要だが、同じことが起こらないよう、最適なコストで復旧・強化していくことが求められる。


関連記事

PHP2Shell緊急対応の記録(2)事前情報を読む――23時の公開に備えたhsBoxの一夜

PHP2Shell対応の記録・第2話。第1話以降の状況の更新、hsBoxの一夜、各社の「影響なし」「対応中」告知の読み方を、大手レンタルサーバーの例とともに整理します。

筆者:muller|2026年10月23日朝時点の情報です

第1話をお読みいただき、ありがとうございました。

第2話では、次の3点を書きます。第1話以降の状況の更新と補足、hsBoxの一夜、そして各社の「影響なし」「対応中」という告知をどう読むか、です。筆者は、hsBoxの情報公開をお手伝いした立場です。

1. 第1話からの更新と補足

国内の状況(22日昼時点)

  • 停止やメンテナンスを告知した組織は、22日午前の時点で、piyologの集計では211になりました。第1話の54は、21日の22時台までの数字です。
  • 主なサービスは次々に戻っています。pixivは21日23時30分にメンテナンスを終え、コドモンは22日3時22分、BASEは8時に再開しました。以上はzephel01氏のnoteの整理によります。
  • 同じnoteは、この脆弱性で侵害を受けたと公表した国内の組織は、22日12時15分ごろの時点で確認できないとしています。止めたのは「やられたから」ではなく、「やられる前に」止めたから、という整理です。

海外の状況

  • watchTowrは、修正版の公開とほぼ同じころに、実際の悪用の試みを観測したと報告しています。ただし、成功した例は観測していません。CloudflareやPatchstackも、より早い時間帯から試行を観測しています(SecurityWeek)。
  • Amazonは、公開前の10月17日に最初の試行を観測したと、Greenboneがまとめています。ニュージーランドのNCSCも、悪用の報告を把握しているとしています(Greenbone)。
  • Cloudflareは、一般への公開の約9時間前に防御を配備していました(セキュリティ対策Lab)。
  • 米CISAの悪用済み脆弱性カタログ(KEV)には、22日の時点で、2件とも掲載がありません(watchTowr)。

つまり、攻撃の試みは公開前から来ており、悪用を観測したとするベンダーも複数あります。一方で、CISAのKEVには、22日の時点でまだ載っていません。修正版を当てていないサーバーが安全という意味ではありません。

第1話への補足

首相の投稿の時刻。 第1話では「報じられました」と書いた首相の投稿は、21時55分に公式Xへ投稿されたものです。国家サイバー統括室は、その11分前の21時44分に同じ趣旨を投稿していました。どちらも、修正パッチの適用が難しければ、ウェブサイトの一時停止も有効策の一つだと述べています(INTERNET Watch)。

修正版の公開時刻。 第1話では「22時台」と書きましたが、出典によって幅があります。多くの資料や、国内事業者の告知(エックスサーバーなど)は、予告どおりの23時(14:00 UTC)としていますが、AlmaLinuxは12:59 UTC(日本時間21:59)、CERT-EUは13:30 UTC(日本時間22:30)と記しています。php.netとGHSA本体の公開時刻は、筆者はまだ特定できていません。【要確認】

当初の予定。 調整済みの公開日は、もともと22日だったとされています。漏えいを受けて1日前倒しされ、21日の公開になったと、SOCRadarなどが書いています。

2. hsBoxの一夜

事前情報を読む

最初の情報は、事前に追っていた情報から得ました。【ウォッチ対象:普段どの情報源を見ているか】筆者の経験では、重い脆弱性の公表が近づくと、事前に何かしらの気配が漏れてくるもので、見慣れてくると察しがつくようになります。

今回は、もう一つ警戒材料がありました。昨今、AIの関与が疑われる不正アクセスが相次いでいる状況です。INTERNET Watchも、AIが24時間休まず手数を増やしていることを要因とみる声が多いと書いています。今回の脆弱性との関連があったかどうかは、後の検証に委ねます。ただ、警戒すべき事前情報の一つとして頭に置いていたことは、書き残しておきます。なお、攻撃の試みは公開前から始まっていたと報告されています(上の「海外の状況」を参照)。事前情報を追う意味は、そこにもあります。

23時からの動き

  • 23時過ぎ:予告されていた23時の公開を把握していたので、確認を始めました。hsBoxで修正版のパッチを適用できるかの検証にとりかかりました。
  • 23時30分:適用できることを確認しました。ただちに情報発信の作業に移りました。
  • 【時刻】:情報を公開しました。https://x.com/hoscm2025/status/2112923979010965921

検証の開始から適用確認までは、約30分でした。【検証の内容:環境、手順、確認した項目】

なお、修正版の公開は予告より早かったとする資料もあります(上の「第1話への補足」を参照)。hsBoxの動き出しは、予告の23時を基準にしたものでした。公式の予告にも、前倒しもあり得ると書かれていました。

情報を絞って、最速で出す

情報公開で一番重視したのは、速さでした。利用者が一番知りたいのは、自分の環境が対策済みかどうかと、何をすればよいかです。そこで、載せる情報を絞って発信しました。

  • 後から伝えた情報:情報の読み取りかたについて補足情報を追加。

判定の基準については、第1話で書いたとおり、リリースとパッケージ名をセットで示す必要があります。

リリース確認後の情報公開としては早かったほうではないだろうか。引き続きよろしくお願い致します。

3. 「影響なし」「対応中」という告知をどう読むか

今回は、多くの組織が告知を出しました。利用者や取引先は、その告知を読む側に回ったことになります。筆者が気になったのは、内容の差よりも、書き方の差です。特定の組織を評価する意図はなく、公開されている告知から読み取れたことだけを書きます。

「影響なし」には、根拠と時点が必要です

  • 根拠が書かれている例があります。はてなは、はてなブログとはてなCMSがPHPを使っておらず影響を受けないと発表しました(セキュリティ対策Lab)。ニコニコは、一部のサービスについて、影響を受けない技術構成だと説明しています(zephel01氏のnote)。LegalOn Technologiesは、11時15分の更新で、複数のサービスが影響を受けないと説明しました(セキュリティ対策Lab)。
  • 確認の範囲も大事です。自社が書いたコードだけでなく、依存しているソフトウェアや機器、委託先まで見ているかどうかです。たとえばPalo Alto Networksは、自社製品のPAN-OSとPanoramaにも影響があると公表しています(セキュリティ対策Lab)。PHPを使っていないつもりでも、機器の中にPHPが入っている場合があります。また、HTMLだけのサイトでも、同じサーバーにPHPが組み込まれていれば影響を免れない、とINTERNET Watchは指摘しています。
  • 「影響なし」と「被害は確認されていない」は別の話です。前者は構成の話、後者はログなどを調べた結果の話です。両方が書かれていると、受け手は判断しやすくなります。

「対応中」には、見通しと暫定策がほしい

  • KAGOYAは、事業者側ではサイトを止めず、PHP 8.2〜8.5の修正版への更新を調整中としました。その間の暫定策として、利用者にサイトの公開停止やアクセス制限の検討を案内し、被害は確認されていないとしています(22日10時35分時点、zephel01氏のnoteによる)。
  • 一方、ConoHa WINGやお名前.comの告知は「システムの保守作業」とあり、PHPという言葉が出てきません(zephel01氏のnote、セキュリティ対策Lab)。
  • 攻撃者に情報を与えないために、書き方を絞るという考え方もあるでしょう。ただ、利用者が自分のサイトへの影響を判断するには、PHPへの対応かどうか、適用済みかどうかが読み取れるほうが動きやすいと、筆者は感じました。
  • 正直に言えば、告知の時点で適用状況や見通しが読み取れない事業者については、利用者の立場で心配になります。ただし、遅れている=怠慢とは限りません。顧客の環境が多様で、古いPHPには個別の修正が必要だからです。PHP公式は、サポートが終わった系列に通常のリリースを出していません。最小限のバックポートのソースが公開されただけです(Tenable)。そのため、エックスサーバーのように独自の修正を作る事業者や、mixhostのようにCloudLinuxの修正パッケージを使う事業者もあります。この話は第3話で扱います。

見通しを示した例:大手レンタルサーバーの告知

参考までに、レンタルサーバー大手のエックスサーバーの対応を、大まかに紹介します。

同社は、修正版の公開前から緩和措置を入れ、公開の数時間前にサービスサイトと管理画面へのアクセスを止めました。公開後は、公式の修正版や自社で作った修正を、新しいPHPから順に全サーバーへ適用しています。22日の早朝にPHP 8.2〜8.5、昼ごろに7.4〜8.1、午後の早い時間に5.6〜7.3を終えました。5.5以下は、告知の時点では検証中でした。管理画面は22日の朝から、サービスサイトは夜から、順次再開しています。

告知の良い点は、時系列を表で示し、適用が済んだ系列と済んでいない系列を分けて書いていることです。未完の部分を隠さず、利用者に追加の対策をお願いする場合があることも、先に書いています。見通しが読み取れる告知の例です。

利用者の運用管理者にとっては、その間、管理画面にも入れず、何もできない夜でした。ただ、共用サーバーのPHPは、もともと利用者が更新できるものではありません。提供者が全サーバーへ一括で、公式の修正がない古い系列まで手当てしてくれるのは、この形態の強みです。一方で、適用が終わるまでの間に不審な動きがなかったかを、アプリのログや管理者アカウントで確認することは、利用者側に残ります。

「誰が直すのか」は、立場によって変わります。共用サーバーなら提供者、VPSや自前のサーバーなら利用者です。この整理は、第3話で扱います。

受け手が告知を読むときの5つの視点

  1. PHPの脆弱性への対応だと明記されているか
  2. 適用済みか、調整中か、そもそも対象外か
  3. いつ時点の情報か
  4. 暫定策(アクセス制限など)が示されているか
  5. 被害の確認状況と、調べた範囲が書かれているか

深い考察は、状況が落ち着いてからにします。OSSのセキュリティを長く見てきた立場からの論点は、別稿でまとめる予定です。

4. 第2話のまとめ

  • 事前情報を追っていたから、23時過ぎにすぐ検証へ入れた
  • 最速で出すために、情報を絞った
  • 告知は、根拠・時点・範囲・暫定策を見て読む
  • 「誰が直すのか」で、利用者にできることが変わる

次回の第3話では、修正版が手元のサーバーに届くまでの距離を取り上げます。レンタルサーバー各社とLinuxディストリビューションの対応、サポートが終わったPHPの扱いに加えて、実際のサーバーで修正が入ったかを確かめる手順(版数、チェンジログ、再起動の確認)を整理します。

参考情報

2026/10/21 PHP2Shell、眠れなかった夜(第1話)23時の約束――予告から修正版公開までの記録

筆者:muller|2026年10月22日時点の情報です

2026年10月21日の夜、PHPの緊急セキュリティリリースへの対応で、眠れなかったエンジニアは少なくなかったと思います。筆者は、hsBoxの情報公開をお手伝いする立場で、この夜を過ごしました。

あの夜、現場では何が起きていたのか。公式の発表、各社の動き、そして情報の読み方を、数回に分けて整理していきます。第1話では、予告が出てから修正版が公開されるまでの一夜を振り返ります。

1. 予告から公開まで(日本時間)

  • 10月20日(協定世界時):PHPのセキュリティチームが、重大な脆弱性2件(いずれもCVSS v4.0で9.2)を修正する緊急リリースを予告しました。公開は10月21日14:00(協定世界時)、日本時間の23:00です。詳細、影響バージョン、修正版は公開と同時に発表するとされ、詳細が先に公になった場合や悪用の証拠が見つかった場合は、前倒しもあり得るとも書かれていました。
  • 21日未明:Sansecによると、日本時間21日0:20ごろ、PHPのリモートコード実行の脆弱性2件がまもなく開示される、という投稿がHacker Newsに現れ、のちに削除されました。watchTowrは、エンバーゴ下にあった情報が漏えいし、実在すると確認できたと発信し、2件をCVE-2026-109618とCVE-2026-109619だと指摘しました。
  • 21日日中:CERT-EU、オーストラリアのASD/ACSC、IPA、国家サイバー統括室などが、注意喚起や事前準備の呼びかけを出しました。IPAは、PHPを使うシステムの棚卸し、公式情報の注視、公開後すぐに適用できる体制づくりを挙げています。
  • 21日14時ごろ:GMO Flatt Securityが、緩和策として挙げていたsession.upload_progress.enabled=0は、攻撃自体を防げない見込みだと見解を改めました。同日、この脆弱性を悪用できると主張するコードがネット上に出回り始めたとも記しています。
  • 21日15時台から:国内サービスの停止や緊急メンテナンスが始まりました。BASEは15:50から、厚生労働省の介護サービス情報公表システムとエックスサーバーのサービスサイトおよび管理画面は16時から止まっています。夜にかけて広がり、22時台までに告知が確認できた組織は54に達しました。
  • 21日夜:首相が公式Xで、今夜の対応を呼びかけたと報じられました。
  • 22時台〜23時:修正版のPHP 8.5.12、8.4.27、8.3.36、8.2.35が公開されました。【要確認:公式アドバイザリやCVEレコードは、予告の23時より前の22時台に公開されていたとする記録があります。正確な時刻はphp.netとGHSAのタイムスタンプで確認します】

2. 「事実」と「見立て」を分けて読む

昼の時点で、公式が明らかにしていたのは、「2件」「CVSS 9.2」「23時リリース」の3点だけでした。CVE番号、リモートコード実行であること、PHP 5以降に影響しうるという範囲は、研究者や公的機関の見立てに基づくもので、開発元が確認したものではありませんでした。IPAも、影響バージョンは確認できていないと断った上で、CERT-EUの注意喚起を紹介する形をとっていました。

のちに公開された公式アドバイザリでは、CVE-2026-109618はメモリ不足時の処理に起因する破損、CVE-2026-109619は解放済みメモリを指す状態が残る問題と説明されました。影響を受けるのはPHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedで、なかでもmod_phpが最も危険とされています。緩和策については、公式は特定の攻撃経路を減らすだけで、更新が唯一の安全な選択肢だとしています。

つまり、夜のあいだに出回った情報の多くは、あとから「当たっていた部分」と「評価が変わった部分」に分かれました。緩和策の評価が14時に変わったのはその一例です。情報を追うときは、誰が、いつ、何を根拠に言っているのかを、時刻付きで切り分けておく必要がありました。

3. 止まった国内サービスと、その判断

piyologの集計では、22時台までに各社の告知で確認できた停止・メンテナンスの組織は54でした。サービス全体を止めたところ、管理画面や新規受付など一部だけ止めたところ、自社サイトだけ止めたところに分かれます。たとえばエックスサーバーは、サービスサイトと管理画面を止めた一方、利用者のサーバーは稼働を続けると案内しました。Cygamesのように、23時の予定より前倒しで止めたサービスもあります。

なお、この数字には注意書きがつきます。個人のアカウントの告知やBASEの出店者の措置は数えておらず、告知にPHPと明記していない組織も含まれています。

ここで強調しておきたいのは、停止は侵害を意味しないということです。多くは、修正版を当てるまでの予防的な措置でした。

筆者の見立てですが、停止が一気に広がった背景には、14時に緩和策の限界が示されたことと、実証コードの流通が伝えられたことがあったのではないでしょうか。設定変更で粘って23時を待つより、いったん止めて修正を待つほうが、説明のつく判断になっていたはずです。

4. hsBoxの一夜

hsBoxも、昨夜、利用者向けに情報公開を行いました。筆者は、文面の確認、技術面の確認、公開作業などでこの公開をお手伝いしました。

公開した内容は次のとおりです。

確実な適用方法と確認方法を重視してできるだけ即座に適用できる方法を公開する方針で対応するようにコメントしました。パッチ適用検証にて日本時間2026/10/21 23:50ころには適用方法と適用確認方法について確認できたので情報公開しました。

5. 番号だけでは判断できない:Ubuntuの例

hsBox 1.4はUbuntu 26.04 LTSをベースにしています。Ubuntu標準のphp8.5パッケージであれば、「8.5.4-0ubuntu1.5以降なら対策済み」という案内が成り立ちます。

ただし、この一文が成り立つのは、Ubuntu 26.04 LTSのphp8.5に限られます。Ubuntuの公式情報では、修正版は次のようにリリースごとに異なります。

  • 26.10:php8.5の8.5.9-0ubuntu2.1
  • 26.04 LTS:php8.5の8.5.4-0ubuntu1.5
  • 24.04 LTS:php8.3の8.3.6-0ubuntu0.24.04.13
  • 22.04 LTS:php8.1の8.1.2-1ubuntu2.28

Ubuntuは修正を元の版に取り込む(バックポートする)ため、php -vの表示がPHP公式の修正版(8.5.12など)と一致するとは限りません。26.04 LTSの基準を26.10にあてはめると、未修正のパッケージを対策済みと誤判定するおそれもあります。利用者に伝えるときは、「Ubuntuのリリース」「パッケージ名」「版数」をセットで書くのが安全です。

もう一点、パッケージを更新しただけでは対応は終わりません。PHP-FPMやApacheなどを再起動して、はじめて修正版が動きます。

6. 第1話のまとめ

  • 公式発表は最小限で、残りは各社の見立てだった。時刻付きで追い、「いつ・誰が・何を根拠に」を切り分ける
  • 国内の54組織の停止は、予防的な判断が中心で、侵害を意味しない
  • 修正済みかどうかは、番号だけでなく、ディストリビューションとパッケージの条件で確認する

次回の第2話では、昨夜の対応を書き残した人たちの記録を読みます。続く回では、修正版が手元のサーバーに届くまでの距離、そしてAIが見つけた脆弱性という背景を取り上げる予定です。

参考情報

  • The PHP Group「Upcoming Critical PHP Security Release」:https://www.php.net/archive/2026.php
  • piyolog「修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた」:https://piyolog.hatenadiary.jp/entry/2026/10/21/174516
  • GMO Flatt Security Blog「PHPの重大な脆弱性「php2shell」の概要と対応指針」:https://blog.flatt.tech/entry/php2shell
  • IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」:https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
  • CERT-EU「Critical Vulnerabilities in PHP」:https://cert.europa.eu/publications/security-advisories/2026-018/
  • ITmedia NEWS「PHPの「緊急」レベルの脆弱性、開発元が修正バージョン公開」:https://www.itmedia.co.jp/news/article/2610/22/2000002480/
  • Ubuntu Security「CVE-2026-109618」:https://ubuntu.com/security/CVE-2026-109618
  • Ubuntu blog「php2shell vulnerability fixes available」:https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
  • PHP公式アドバイザリ(GitHub):https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w および https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

2026年「還付金確定通知書を格納いたしました」は詐欺メール?国税庁(e-Tax)をかたるフィッシングの見分け方

この記事は、スパムアサシンやメーラーでのスパム判定をすり抜けた怪しいメールを取り扱います。その内容の判定や設定方法の改善策について取り扱います。巧妙化する攻撃に対応について記載します


結論から言うと、このメールは国税庁を装ったフィッシング詐欺です。リンクは開かず、メールは削除してください。

2026年10月11日(日)、筆者のもとに「【重要なお知らせ】還付金確定通知書を格納いたしました」という件名のメールが届きました。差出人は「e-Tax」で、国税庁のドメインから送られたように見えます。

迷惑メール判定は受けておらず、一見すると本物のように見えます。この記事では、同じメールを受け取って「本物かどうか」を調べている方のために、偽物と判断した根拠と、開いてしまった場合の対処法をまとめます。

届いたメールの内容

件名と本文の要点は次のとおりです(リンクは無効化しています)。

  • 件名:【重要なお知らせ】還付金確定通知書を格納いたしました
  • 内容:令和8年分の所得税確定申告の還付金が確定し、通知書をe-Taxのメッセージボックスに格納した。確認期限は令和8年10月1日。
  • 誘導:Android版e-Taxアプリをインストールしていない場合は、ボタンからダウンロードするよう案内。
  • リンク先:hxxps://ojzvvq[.]cn/?ywtxqcrw

同じ文面が届いた方は、以下の見分けポイントと照らし合わせてみてください。

偽物と判断できる7つの理由

1. 存在しない通知である(日付の矛盾)

本文は「令和8年分(令和8年1月1日〜12月31日)の確定申告の還付金が確定した」と述べています。しかし令和8年分は、メールが届いた2026年10月11日時点でまだ年が終わっていません。申告は令和9年(2027年)の2月〜3月ごろに行うもので、還付金が確定しているはずがありません。

さらに、確認期限が「令和8年10月1日」で、メールが送られた時点で10日も過ぎています。期限切れの日付を書いている時点で、おかしな通知です。

2. リンク先が国税庁のサイトではない

ボタンのリンク先は ojzvvq[.]cn というランダムな文字列のドメインで、国税庁のドメイン(nta.go.jp)とは無関係です。末尾の ?ywtxqcrw は、受信者や配信ロットを識別するためのものと考えられます。

.go.jp は日本の政府機関しか取得できないドメインです。リンク先が .go.jp で終わっているかどうかは、見分ける際の基本ポイントです。

3. 本文の内容が矛盾している

  • 「通知はアプリ内のメッセージボックスでのみ確認できる」と説明しながら、外部サイトのボタンへ誘導している
  • 「Android版」のインストールだけを強調している

偽サイトで情報を入力させる、またはAndroid用の不正なアプリ(マルウェア)をインストールさせるのが目的と考えられます。ただし、筆者は偽サイトにアクセスしていないため、実際の動作は確認していません。

4. 本物の文章とリンクを混ぜて信頼させようとしている

後半には、マイナンバーカード方式の説明や個人情報保護方針が長々と書かれています。公式サイトの文章を流用したものと思われ、e-tax.nta.go.jp、digital.go.jp など本物のリンクも混ざっています。国税庁の所在地や法人番号も記載されていますが、これらは公開情報です。本物のリンクや情報が含まれていても、本物の証拠にはなりません。

5. 不自然な日本語がある

  • 「e-Taxボームページ」「ホームベージ」(正しくは「ホームページ」)
  • 「ー部サービス」(漢数字の「一」ではなく長音記号)
  • 文頭の不自然な中黒「·」

公式文書をコピーして加工した形跡とみられます。

6. 「お金」と「期限」で焦らせる

還付金という「得をする話」と、確認期限という「急がせる要素」の組み合わせは、フィッシングの典型的な手口です。冷静に考える時間を与えないための工夫です。

7. メールヘッダが「国税庁からではない」ことを示している

メールの送信元情報(ヘッダ)を調べると、差出人の詐称がはっきり分かりました。

調べた項目結果分かること
送信元の認証(SPF)失敗国税庁ドメインの送信元として許可されていないIPアドレスから送られた
電子署名(DKIM)なし正規のメールに付く署名がない
DMARC失敗送信元の詐称を見抜くための仕組みの判定も不合格
送信元IPアドレス59.59.212[.]137(逆引きできず)国税庁のサーバーとは対応しない。日本のIPアドレス管理機関(JPNIC)の検索では該当データなし
送信ソフトFoxmail(中国語圏向けのメールソフト)国税庁が使うとは考えにくい
送信日時のタイムゾーン+0800(中国標準時)日本の機関なら通常+0900(日本標準時)
URLの検査本文中のURLがフィッシング用のブロックリストに該当すでに危険なURLとして知られている

差出人、Return-Path、Message-IDのすべてが e-tax.nta.go.jp になっており、送信ドメインそのものを詐称していました。

なぜ迷惑メール判定をすり抜けたのか

認証に失敗しているのに配信された理由の1つは、国税庁ドメインのDMARCポリシーです。筆者がDNSで確認したところ、_dmarc.e-tax.nta.go.jp の設定は次のとおり、p=none(認証に失敗しても拒否・隔離を求めない) でした(2026年10月11日時点)。

v=DMARC1; p=none

p=none は「監視のみ」の設定で、認証に失敗したメールも受信側でそのまま配信される可能性があります。そのため、受信側の設定によっては、この種のメールが受信箱に届いてしまいます。迷惑メールフォルダに入っていないことは、安全の証明にはなりません。

対策:送信認証の失敗を条件にしたフィルタを作る

政府機関のように送信認証を整えているはずのドメインを名乗り、かつ認証に失敗しているメールは、ほぼ偽物とみなせます。この条件でメールを自動で振り分けると効果的です。

筆者が使っているThunderbirdでは、次の設定でできます(Authentication-Results は受信サーバーが付けるヘッダです)。

  1. メニューから「ツール」→「メッセージフィルタ」を開く
  2. 「新規」を選び、条件の項目で「カスタマイズ」から Authentication-Results を追加する
  3. 「次の文字列を含む」で spf=fail と dmarc=fail の両方を条件にする(「すべての条件に一致」)
  4. 動作は「削除」ではなく「ゴミ箱へ移動」または専用フォルダへの移動にする

筆者の環境では、この設定により、今回のメールは迷惑メール判定がなくても自動でゴミ箱に入っていました。

ゴミ箱・隔離フォルダは定期的に確認する

送信認証の失敗は、偽メール以外でも起こることがあります。たとえば、メールを別のアドレスへ転送している場合や、一部のメーリングリストを経由した場合です。正規のメールを見逃さないために、振り分けたフォルダは次のように確認しましょう。

  • 週に1回程度、ゴミ箱と隔離フォルダの差出人と件名を確認する
  • 見覚えのある差出人や、自分が関わった手続きのメールが入っていたら、元のフォルダに戻す
  • 判断に迷うメールは、本文内のリンクを開かず、公式サイトや公式アプリから直接確認する
  • 確認して問題がなければ、メールを完全に削除する

メールヘッダの見方

  • Thunderbird:メールを開き、「表示」→「ヘッダ」→「すべて」。またはCtrl+Uでソースを表示
  • Gmail:メール右上の「︙」→「メッセージのソースを表示」
  • Outlook:メールのプロパティから「インターネットヘッダー」を確認

Authentication-Results の行に spf=fail や dmarc=fail があれば要注意です。

もしリンクを開いてしまったら

状況別の対処は次のとおりです。

リンクを開いただけで何も入力していない場合
慌てる必要はありません。ブラウザを閉じ、念のためブラウザの履歴とキャッシュを削除してください。

偽サイトにIDやパスワードを入力した場合

  • 入力したIDとパスワードを、公式サイトから直ちに変更する
  • 同じパスワードを使い回しているサービスもすべて変更する
  • マイナンバーカードの暗証番号を入力した場合は、カードの一時利用停止も検討する(マイナンバー総合フリーダイヤル 0120-95-0178)
  • クレジットカード情報を入力した場合は、カード会社にすぐ連絡する

アプリをインストールしてしまった場合

  • 機内モードにしてネットワークを遮断する
  • 該当アプリをアンインストールし、ウイルス対策アプリでスキャンする
  • 銀行・証券・クレジットカードなどのパスワードを変更する
  • 不審な動作が続く場合は、端末の初期化も検討する

相談先

  • 警察の相談窓口:#9110
  • 消費者ホットライン:188
  • 最寄りの税務署

通報先

  • フィッシング対策協議会
  • 迷惑メール相談センター

今後も見破るための3つのルール

  1. メール内のリンクは開かない。 公式アプリやブックマークから直接アクセスする
  2. 「還付」「期限」「重要」で急かされたら、まず疑う。 本物の税務手続きは、メールのボタンだけで完結しない
  3. 差出人の表示名やドメインは信用しない。 差出人は簡単に詐称できる

よくある質問

Q. 「還付金確定通知書を格納いたしました」というメールは本物ですか?
A. 今回のメールは偽物です。令和8年分の還付金が現時点で確定することはなく、リンク先も国税庁のドメインではありません。

Q. すでにリンクをクリックしてしまいました。
A. 何も入力せず、アプリもインストールしていなければ、大きな被害の可能性は低いです。「もしリンクを開いてしまったら」の対処を確認してください。

Q. 本物のe-Taxからの連絡かどうか、どう確認すればいいですか?
A. メールのリンクではなく、公式サイトやブックマーク、公式アプリから自分でe-Taxにログインして、メッセージボックスを確認してください。

Q. 迷惑メールフォルダに入っていないのはなぜですか?
A. 送信元の詐称を見抜く仕組み(DMARC)が「監視のみ」の設定で、認証に失敗したメールも受信側でそのまま配信されることがあるためです。受信側のフィルタで、送信認証の失敗を条件に振り分けると効果的です。

まとめ

  • 「還付金確定通知書を格納いたしました」は、国税庁を装うフィッシングメールです
  • 日付の矛盾、国税庁ではないリンク先、本文の矛盾、不自然な日本語、ヘッダの認証失敗から、偽物と判断できます
  • 迷惑メール判定をすり抜けることがあるので、「判定されていない=安全」とは考えないでください
  • 送信認証の失敗を条件にしたフィルタが有効です。ただし、振り分け先のフォルダは定期的に確認してください

この記事は2026年10月11日時点の情報です。手口は変化するため、最新の注意喚起は国税庁やフィッシング対策協議会の公式サイトでご確認ください。



過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたしま。コメントとをお願いします。

蛇口の「ぶー」が止まった ── 混合栓のカートリッジ交換(KPS018)は実作業10分

前編で交換部品を特定した、浄水器付き混合栓の異音。注文したKPS018が届いたので、さっそく混合栓のカートリッジ交換をしました。

結論から書くと、「ブーー」という異音も水漏れも止まりました。実作業は10分足らずで、前後の確認を含めても30分ほどでした。

ただし、手順には1か所だけ、ひと手間かかる所がありました。そこで、この記事ではその手順と、外したカートリッジの劣化の様子をまとめます。さらに、次の再発に備えて考えたことも記録しておきます。

交換前の状態:浄水側から「ブーー」と水漏れ

わが家の混合栓は、KVK(旧MYM)のFB764GK8です。8月下旬ころから、ポンプが動くたびに浄水側から「ブーー」と鳴るようになりました。しかも、鳴るたびに蛇口から水が漏れていました。

浄水レバーを手で押さえると、音は止まります。そこで、浄水側の切替カートリッジ(KPS018)が原因と判断しました。詳しい切り分けと部品の調べ方は、前編に書いています。また、2019年の経緯は問題編と解決編にまとめています。

混合栓のカートリッジ交換に用意したもの

混合栓のカートリッジ交換に使ったものは、次のとおりです。

  • KVK KPS018(浄水側の切替カートリッジ)… 楽天市場の販売店で送料込み3,110円
  • モンキーレンチ … カバーとカートリッジを回す
  • プラスドライバー … レバーを留めているネジを外す
  • 小さいマイナスドライバー … レバーのキャップをこじ開ける(写真にはありません)
  • シリコングリース … Oリング・青いパッキン・ネジ部に塗る(手持ちの信越シリコーン G-40M)
混合栓のカートリッジ交換に使ったKPS018と工具
用意したもの。KPS018、モンキーレンチ、プラスドライバー、シリコングリース

なお、KPS018のパッケージ上の名称は「止水カートリッジ」です。わが家の混合栓では、浄水の出し止めを受け持つ部品です。

ちなみに、部品はネコポスで届きました。ところが、袋を開けると先端の青いパッキンが外れていました。どうやら、輸送中に外れたようです。そのため、先端にはめ直してから取り付けました。届いたら、まずパッキンの有無を確かめると安心です。

混合栓のカートリッジ交換の手順

混合栓のカートリッジ交換の流れは、次のとおりです。まず、混合栓の下の止水栓を閉めてから始めます。

  1. 混合栓の下の止水栓を閉める
  2. 浄水レバーのキャップを、小さいマイナスドライバーでこじ開ける
  3. キャップの下のプラスネジを外し、レバーを抜く
  4. リング状のカバーを、モンキーレンチで左に回して外す
  5. カートリッジの六角部分にレンチをかけ、左に回して外す
  6. 新しいKPS018のOリング・青いパッキン・ネジ部に、シリコングリースを塗る
  7. KPS018を右に回して締め、カバー・レバー・キャップを逆の順で戻す
  8. 止水栓を開けて、浄水の出し止めと漏れがないかを確かめる

ひと手間:リング状のカバーを先に外す

つまずきやすいのは、手順4です。レバーを抜いても、すぐにはカートリッジの六角部分にレンチが届きません。手前に、リング状のカバーがあるからです。

そこで、先にこのカバーをモンキーレンチで左に回して外します。すると、奥の六角部分にレンチをかけられます。なお、専用のソケットレンチがあれば、カバーを付けたままでも届くかもしれません。

シリコングリースを塗る理由

新しいKPS018には、Oリング・青いパッキン・ネジ部にシリコングリースを塗りました。グリースを塗ると、Oリングがねじれずに収まりやすくなります。また、ネジ部も滑らかに回せます。ただし、鉱物油系のグリースはゴムを傷めることがあります。したがって、ゴム部品にはシリコングリースを使います。

結局、混合栓のカートリッジ交換にかかった時間は、実作業で10分足らずでした。前後の確認を含めても、30分ほどで終わりました。

結果:異音も水漏れも止まった

交換後は、ポンプが動いても「ブーー」という音は鳴りません。さらに、音と一緒に出ていた水漏れも止まりました。つまり、8月下旬から1か月あまり続いた異音は、混合栓のカートリッジ交換で解消しました。

やはり、前編の見立てどおり、原因は浄水側の切替カートリッジでした。なお、作業があっけなく終わったので、交換前後の動画は撮りそびれました。

外したカートリッジの劣化:先端の青いパッキンが白っぽく

外した古い切替カートリッジ(横から)
外した古いカートリッジ。全体に黒ずんでいた
古いカートリッジの先端にある青いパッキン
先端の青いパッキン。新品は鮮やかな青だが、白っぽく変色していた

見た目で一番変わっていたのは、先端の青いパッキンです。新品は鮮やかな青色です。一方、外したものは白っぽく変色していました。材質はわかりませんが、シリコン系のゴムかもしれません。

次に、黒いOリングを見ました。ひびはなく、触るとある程度の柔らかさも残っています。ただし、どこまで硬くなっていたかはわかりません。

また、同じKPS018を交換した別の方の記録でも、青いパッキンの弾力がなくなっていたと書かれています。したがって、異音と漏れには、このパッキンの劣化が関わっていた可能性が高そうです。

次の混合栓のカートリッジ交換に備えて

最初のカートリッジは約10年、2本目は7年で異音が出ました。つまり、次の混合栓のカートリッジ交換は7〜10年後、2030年代半ばになりそうです。

ところが、そのころにKPS018が手に入るとは限りません。日本バルブ工業会の資料では、補修用部品の供給期間は製造中止後10年とされています。しかも、FB764GK8にはすでに後継機種(KM5061NSC)が出ています。

先端の青いパッキンは単品で手に入らない

そこで、先端の青いパッキンだけを手に入れられないか調べました。しかし、単品では売られていないようです。実際、Yahoo!知恵袋の回答でも、パッキンだけの販売はないだろうとされていました。さらに、市販品での代用も難しいという意見でした。確実なことは、KVKのお客様相談窓口に問い合わせるのがよいでしょう。

古いカートリッジは捨てずに保管する

そのため、外した古いカートリッジは保管しておくことにしました。KPS018が手に入らなくなったときの、最後の手段です。たとえば、青いパッキンを裏返して当たり面を変え、シリコングリースを塗れば延命できるかもしれません。

もっとも、これは試していない案です。また、メーカーが想定した修理方法でもありません。とはいえ、部品が手に入らないときの選択肢としては残しておきたいところです。

ただ、こういう部品は、えてしてなんとなく捨ててしまいがちです。だからこそ、ここに書いて未来の自分への申し送りにしておきます。

今回の修理記録

前編の教訓に従って、今回の修理記録を残しておきます。

項目内容
修理日2026年10月1日
本体KVK(旧MYM)FB764GK8(形状と2019年の発注記録から特定)
症状ポンプが動くと浄水側から「ブーー」と鳴り、蛇口から水が漏れる
交換部品KPS018(浄水側の切替カートリッジ。パッケージ名は止水カートリッジ)
購入先・価格楽天市場の販売店、送料込み3,110円(ネコポスで到着)
工具モンキーレンチ、プラスドライバー、小さいマイナスドライバー
消耗品シリコングリース(Oリング・青いパッキン・ネジ部に塗布)
作業時間実作業10分足らず、確認を含めて約30分
注意点リング状のカバーを先に外さないと、六角部分にレンチが届かない
結果異音・水漏れとも解消
外した部品先端の青いパッキンが白っぽく変色。黒いOリングにひびなし。保管中
過去の交換2019年:浄水側の切替カートリッジ(業者作業)、シングルレバー側 KPS027H-B(自分で交換、原因ではなかった)

まとめ:混合栓のカートリッジ交換はカバー外しがポイント

  • 浄水側の異音と水漏れは、KPS018への交換で止まった
  • リング状のカバーを先に外せば、実作業は10分足らず
  • Oリング・青いパッキン・ネジ部にはシリコングリースを塗って取り付けた
  • 先端の青いパッキンは単品で手に入らない。古いカートリッジは捨てずに保管
  • 修理記録には、部品の型番に加えて、作業のつまずきどころも残す

7年前は、型番を残さなかったせいで遠回りしました。一方、今回は作業のつまずきどころまで書き残せました。次にこの音を聞くのは、7〜10年後かもしれません。そのときの自分が、この記録を見てすぐに直せますように。なお、ほかの修理やトラブル対処の記録は、ノウハウのカテゴリにまとめています。


関連記事

コンクリート劣化の引き金は「急乾燥」だけではなかった ―― AEの集中発生4回を気象データと重ねて検証

AEセンサーが捉えたコンクリートの「悲鳴」の集中発生4回を、気象庁の10分値と重ねて検証しました。雨上がりの急乾燥だけでなく、強風や強い雨で壁が濡れる「急な湿潤」でもAEが集中していました。

90%→40%)との関係を紹介しました。ただ、あのときは気象データとの一致を文章で説明しただけで、データを並べて見せてはいませんでした。取り上げたAEの集中発生も1回だけでした。

その後も記録を続け、ログを整理し直したところ、AEが短時間に集中して発生した場面は合計4回ありました。今回は4回それぞれについて、気温・湿度・雨・風の推移とAEの発生タイミングを1枚のグラフに重ね、コンクリート劣化の引き金を検証します。

結論を先に書くと、引き金は「急乾燥」だけではありませんでした。強風や強い雨で壁が一気に濡れる「急な湿潤」の場面でも、AEは集中して発生していました。現場の定点カメラの画像でも、発生の前後に壁が濡れていた様子を確認できています。

今回使ったデータとグラフの見方

  • AE:壁に取り付けた自作のAEロガー(4チャンネル)の記録です。しきい値を超えた信号を、時刻と振幅で記録しています。
  • 気象:気象庁「過去の気象データ検索」の10分ごとの値(気温・相対湿度・降水量・平均風速・最大瞬間風速・日照時間)を使いました。観測点は現場から少し離れた近隣の地点です。
  • 定点カメラ:壁を10分ごとに撮影している定点カメラ(ATOM Cam 2)の画像で、発生前後の壁の濡れ具合を確認しました。

プライバシーに配慮して、今回のグラフでは日付と観測地点名を伏せ、横軸を「AE集中発生からの経過時間」(発生の60時間前〜12時間後)にしています。グラフは上から、日照・気温・湿度・降水量(10分ごと)・風速・AE検出数の順です。赤い破線がAEの集中発生時刻、一番下の灰色の斜線は記録が止まっていた区間です。AE検出数は、1件と100件を同じグラフに収めるため対数目盛にしています。

ログを整理して分かった2つの注意点

  1. 時刻の「桁あふれ」:ロガー内部の経過時間カウンター(ミリ秒単位)は、約49.7日で一周してゼロに戻ります。そのまま読むと、実際より約50日前の日付に見えてしまいます。時刻合わせの記録と照合して補正したところ、見落としていた集中発生が見つかりました。
  2. メモリ満杯による記録停止:記録用のメモリ(EEPROM)は128件で満杯になります。4回のうち3回は、集中発生の最中に満杯になって記録が止まっていました。グラフの件数は「少なくともこれだけ発生した」という値です。

イベント① 雨上がりの急乾燥(前回のケース)

イベント①のグラフ。雨上がりの晴天で湿度が87%から40%まで下がり気温が上がった後、乾燥のピーク直後にAEが43件集中して発生している
イベント①:雨上がりの急乾燥。乾燥のピークを過ぎた直後にAEが集中

2日前の雨で、湿度は100%近くありました。そこから晴れて、発生までの約10時間で湿度は87%→40%、気温は8.5℃→19.5℃と一気に変わっています。直前24時間の雨はゼロで、風も穏やか(最大瞬間風速6m/s程度)でした。

AEの集中発生(43件・約11分間)は、乾燥が最も進み、日照が切れて湿度が底から戻り始めた直後に起きています。同じ日の朝、乾燥が急に進み始めた時間帯にも小さな集中(4件)がありました。表面だけが乾いて縮み、湿った裏側との差で反ろうとする力が拘束されてひび割れる、という前回の仮説と合う結果です。

定点カメラの画像では、このときの壁はまだしっとりと湿り気を残していました。空気は一気に乾いても、壁はすぐには乾ききっていなかったことになります。なお、AEの出方は11分間で43件と、後で紹介する②〜④(数秒間に69〜108件)に比べるとずっと穏やかでした。

イベント② 大雨から約10時間後

イベント②のグラフ。乾燥した晴天の後に約46ミリの大雨で湿度が100%に達し、雨が上がって約10時間後にAEが69件集中して発生している
イベント②:乾燥→大雨の後、約10時間たってからAEが集中

2日前は湿度40%前後の乾いた晴天でした。その後雨になり、発生当日の未明から朝にかけて約46mmの大雨(1時間に最大13.5mm)が降り、湿度は100%に張り付きました。

AEが集中した(69件・約6秒間)のは、雨が上がってから約10時間後です。そのときは湿度91%・ほぼ無風・雨なしで、気象データの上では発生の瞬間に目立った変化はありません。

ところが定点カメラの画像を見ると、壁は朝から全面が湿った状態で、それが夕方まで続き、暗くなってから濡れた状態に変わったように見えます。AEが集中したのは、ちょうどこの時間帯です。観測点では雨が記録されていないため、局所的なにわか雨だったのか、湿った空気で壁の表面が結露したのかは、まだ分かりません。

イベント③ 暴風雨の始まり

イベント③のグラフ。雨が続いた後、最大瞬間風速が約16メートルから28メートルへ急に強まり始めた瞬間にAEが108件集中して発生している
イベント③:雨の後、風が急に強まり始めた瞬間にAEが集中

2日前の午後は、気温30℃・湿度40%を切る乾燥した日でした。そこから雨になり、発生までの24時間の雨量は35.5mmです。

AEの集中発生(108件・約9秒間)は、最大瞬間風速が約16m/sから30分ほどで28m/sまで一気に強まり始めた、その瞬間でした。28m/sは記録期間中で最も強い風です。センサー付近は雨粒が直接当たる場所ではありませんが、強風のときは霧状になった雨が吹き込んで壁が濡れます。強風で壁が急に濡れた可能性があります。なお、雨を伴わない強風の日(最大瞬間風速16〜17m/s)にはAEの集中は起きていないので、風そのものが原因とは考えにくいです。

現場でも風は相当なものでした。AE発生の10〜20分ほど前に、定点カメラが強風で吹き飛ばされて向きが変わってしまい、このときの壁の様子は写っていませんでした。

イベント④ 梅雨の長雨と強い雨

イベント④のグラフ。湿度ほぼ100%の長雨が2日半続き、10分間に4ミリから6.5ミリの強い雨が繰り返す中でAEが94件集中して発生している
イベント④:長雨の中、強い雨が繰り返す合間にAEが集中

湿度ほぼ100%が2日半続く梅雨の長雨でした。発生までの雨量は24時間で51.5mm、60時間では143.5mmに達しています。

AEの集中発生(94件・約4秒間)の約1時間半前には10分間に4mmの強い雨が2回続き、その直後には最大瞬間風速も9m/s台まで強まっていました。発生の約20分後にも、10分間に6.5mmの強い雨が降っています。

定点カメラの画像では、発生の40分〜2時間ほど前に、壁の全面が湿った状態に変わっていました。強い雨と風が重なった時間帯なので、風で吹き込んだ雨で濡れたと考えられます。壁が濡れてから少し時間をおいて、AEが集中したことになります。

4回を並べて見えた、コンクリート劣化の2つの引き金

タイプイベントAEの出方直前24時間の雨量気象の状況定点カメラで見た壁
急乾燥①43件/約11分0mm晴天で湿度87%→40%。乾燥のピークの直後まだしっとり湿っていた
急な湿潤②69件/約6秒46.0mm大雨の約10時間後(雨なし・湿度91%)暗くなってから濡れた様子
急な湿潤③108件/約9秒35.5mm最大瞬間風速が約16→28m/sへ強まり始めた瞬間直前にカメラが強風で吹き飛ばされ確認できず
急な湿潤④94件/約4秒51.5mm強い雨と風の後、次の強い雨の直前発生の40分〜2時間ほど前に全面が湿った状態に
AE集中発生4回の比較(気象は近隣の観測点の値)

前回の①は「湿った状態から一気に乾く」変化でした。②〜④はその逆で、「壁が一気に濡れる」変化が起きた場面です。②と④は定点カメラでも濡れを確認でき、③も強風で雨が吹き込む状況でした。コンクリート劣化の引き金は、乾燥そのものではなく乾湿の急な変化だと考えたほうが、4回とも説明しやすくなります。

AEの出方にも違いがあります。①は11分かけてゆっくり43件だったのに対し、②〜④は数秒のうちに69〜108件が集中しました。今回の4回を見る限り、「急な湿潤」のほうがAEは短時間に激しく出ています。

ただし、雨量だけでは決まらない

記録が残っている期間に、1日20mm以上の雨が降った日は13日ありました。そのうちAEの集中発生につながったのは3つの雨の期間だけです。1日40mm前後の雨の日や、1時間に13〜14mmの強い雨が降った日でも、AEの集中発生は起きていません。

③では強風、④では短時間の強い雨が重なっていました。雨量だけでは決まらず、強風や短時間の強雨で壁が実際に濡れるかどうかが効いている可能性がある、というのが現時点での見立てです。

なぜ「濡れる」と音が出るのか(仮説)

前回は「表面が乾いて縮もうとするのに、湿った裏側と周囲に拘束されて縮めない。その結果、表面に引っ張る力が集中してひび割れる」と説明しました。今回の結果は、その逆向きの変化でも同じことが起きうることを示唆しています。

  • 表面の吸水膨張:乾いていた表面が急に水を吸うと、表面だけが膨らもうとします。すでにある微細なひびの面どうしが押し合ったり、ずれたりすることで、音(AE)が出る可能性があります。④で壁が濡れてから少し遅れてAEが集中したのも、水を吸って膨らむまでに時間がかかると考えれば説明がつきます。
  • 乾湿の往復による疲労:「乾く→濡れる→乾く」の急な往復が繰り返されると、同じひびが何度も開いたり閉じたりして、少しずつ進行していくと考えられます。
  • 背面の土圧・水圧の増加:大雨の後は、壁の裏側の土に水が溜まり、壁を押す力が増えます。表面が濡れて膨らもうとする力に、この力が重なっている可能性もあります。

いずれもまだ仮説の段階です。

残っている疑問

  • ②〜④のAEは、振幅がほぼ一定で数秒間に集中しています。振幅がばらつきながら11分間続いた①とは性質が違います。壁を伝う水の流れなど、ひび割れ以外の音を拾っている可能性も、まだ完全には否定できません。
  • ②で暗くなってから壁が濡れた原因(局所的な雨か、結露か)は分かっていません。定点カメラは10分ごとの撮影で、夜間は見えにくいという限界もあります。
  • 気象データは近隣の観測点のものなので、現場とは雨の降り方や風向きが違う可能性があります。
  • メモリ満杯などで記録が止まっていた期間があり、夏の大雨の一部は検証できていません。

次にやること

  • 定点カメラの固定強化:③では強風でカメラの向きが変わり、肝心の場面が写っていませんでした。嵐の日でも壁を撮り続けられるように固定し直します。
  • ロガーの改良:満杯で止まらないように記録容量を増やし、時刻の補正を自動化します。可能であれば、波形そのものも保存したいところです。
  • 濡れセンサーの追加:壁の表面が濡れた瞬間とAEの発生を、直接比べられるようにします。

まとめ

  • ログを補正して整理すると、AEの集中発生は4回ありました。
  • 1回は雨上がりの「急乾燥」、3回は強風や強い雨で壁が濡れる「急な湿潤」の場面でした。定点カメラでも、②と④で発生の前後に壁が濡れていたことを確認しました。
  • AEは、「急な湿潤」のほうが数秒のうちに激しく集中していました。
  • 雨量だけでは決まらず、壁が実際に濡れるかどうかが効いている可能性があります。
  • コンクリート劣化の原因は「乾燥」だけでなく、「乾湿の急な変化」として捉え直す必要がありそうです。

次は、濡れセンサーやロガーの改良で「壁が濡れた瞬間」とAEを直接比べられるようにして、続報でお伝えします。

関連記事

出典:気象データは気象庁「過去の気象データ検索」の10分ごとの値をもとに加工して作成しました(観測地点名は非公表)。

蛇口の「ぶー」が7年ぶりに再発 ── 浄水器付き混合栓の異音は切替カートリッジ(KPS018)を疑え

浄水器付き混合栓の異音「ぶー」が7年ぶりに再発。レバーを押さえる切り分けと、AIと図面の照合で交換部品KPS018を特定するまでの調べ方をまとめました。

2019年に苦労して直した、キッチンの混合栓の異音。あの「ぶー」という音が、7年たって再び鳴り始めました。

原因の見当は、すぐにつきました。ところが、前回交換した部品の型番が、どこにも記録されていませんでした。

そこで、この記事では再発の経過をまとめます。加えて、交換部品の型番にたどり着くまでの手順も紹介します。混合栓の異音で困っている方が、同じ手順を試せるように書いています。なお、交換作業と結果は次回の交換編で紹介します。

前回(2019年)の混合栓の異音をおさらい

2019年8月ころ、キッチンの浄水器付き混合栓で異音が出始めました。水を流すたびに「ぶー」と鳴り、止めているときも時々鳴りました。しかも、止めているときに鳴ると、蛇口から水が漏れてきました。

まず、メーカーから提示されたシングルレバー側の止水カートリッジを交換しました。しかし、音はまったく変わりませんでした。

そこで仮説を立てて、音の出どころを切り分けました。その結果、浄水側の切替レバーを押さえると音が止まることがわかりました。つまり、原因は浄水側の切替カートリッジの劣化でした。

経過の詳細は、問題編と解決編に書いています。

2019年撮影。切替(浄水)レバー部を押さえると異音が消える(解決編より)

今回の混合栓の異音:「く、く」から「ブーー」へ

今回は約1か月前、2026年8月下旬ころから症状が出始めました。

  • 最初は、ときどき「く、く」と短く鳴る程度
  • 現在は「ブーー」と長く鳴る
  • 音が鳴るときには、蛇口から水が漏れる

この混合栓は3階のキッチンにあり、約10m下の貯水槽からポンプで揚水しています。最初は、ウォーターハンマーのときに鳴っていました。ウォーターハンマーとは、水の流れが急に止まったときに起きる圧力の変動です。ところが今は、ポンプが動くたびに鳴るようになりました。

部品のシール性能が、少しずつ落ちてきたのだと考えています。そのため、小さな圧力の変化にも弁が耐えられなくなったと見ています。

試しに、前回と同じく浄水レバーを手で押さえてみました。すると、音は止まりました。つまり原因は、前回と同じ浄水側の切替カートリッジです。

困ったこと:交換した部品の型番がわからない

原因の場所がわかっても、型番がわからなければ部品を注文できません。

ところが、2019年の発注記録に残っていたのは「KVK KPS027H-B」だけでした。これはシングルレバー側の止水カートリッジで、原因ではなかった部品です。

一方、実際に異音を直した切替カートリッジは、交換作業を業者に依頼しました。原因の特定まではこちらで行ったものの、発注記録は手元に残りませんでした。さらに、前回の記事にも型番を書いていませんでした。7年後の自分のために、型番を書いておくべきでした。

混合栓の異音で困ったときの調べ方

ここからは、今回たどった手順を5つのステップでまとめます。

1. 混合栓の異音の出どころを切り分ける

  • まず、混合栓の下の止水栓を閉めて、ほかの蛇口を使ってみる
  • その結果、音が出なくなれば、原因はその混合栓の中にある
  • 次に、音が出ている最中に、各レバーを手で押さえてみる
  • そして、押さえて音が止まったレバーの、内部のカートリッジを疑う
  • なお、浄水器付きなら、シングルレバー側と浄水側を分けて確認する

2. 本体の品番を特定する

本体やシンク下の配管まわりに品番シールがあれば、品番はすぐにわかります。ただし、年数がたつと見つからないこともあります。わが家でも、今回は見つけられませんでした。

その場合は、蛇口の写真を撮ってAIに見せると、似た製品の候補を挙げてくれます。今回は、前回記事に書いた商品名をAIに渡しました。商品名は「浄水器内蔵シングルレバー式シャワー付混合栓」です。すると、KVK(旧MYM)の「FB764GK8」が候補に挙がりました。

ただ、AIの答えは時々間違っています。そのため、候補が出たらメーカーの図面や商品写真と見比べてください。細部まで一致しているかを、自分の目で確かめることが大切です。今回はKVKの商品サポートページで、形状を1つずつ照合しました。引き出し式のシャワーヘッドと、上部のシングルレバーは一致しました。さらに、右下の浄水切替レバーの形状も一致しました。

3. 補修部品を特定する

本体の品番がわかったら、次にその品番の補修部品を調べます。メーカーのサポートサイトや、補修部品の解説サイトが参考になります。たとえば「水が止まらない(浄水)」のように、症状ごとに部品が載っています。

FB764GK8の場合、今回関係する部品は次の2つです。

部位部品品番
シングルレバー側止水カートリッジKPS027H-B(2019年に交換)
浄水側切替カートリッジKPS018

4. 手元の記録と突き合わせる

とはいえ、形状の一致だけでは不安が残ります。そこで、2019年の発注記録にあったKPS027H-Bの対象品番を確認しました。すると、その中にFB764GK8が含まれていました。これで、本体の特定に確信が持てました。このように推定と記録を突き合わせる進め方は、コンクリート劣化の原因を確かめた記事でも使いました。

過去の修理記録や取扱説明書が残っていれば、ぜひ照合に使ってください。

5. 注文前に最終確認する

旧MYM製品は、品番が似ていても部品に互換性がない場合があります。実際、販売店のページにもその注意書きがあります。したがって、確信が持てなければメーカーのお客様相談窓口に問い合わせるのが確実です。

KPS018を発注:7年という寿命をどう見るか

以上の手順で、交換部品はKPS018と判断しました。そして、楽天市場の販売店で発注しました。価格は、送料込みで3,110円でした。

ちなみに、最初のカートリッジは設置から約10年で異音が出ました。一方、2019年に交換したカートリッジは7年で異音が出ています。日本バルブ工業会の資料では、水栓の耐用年数は10年程度とされています。また、バルブカートリッジは消耗部品の例に挙げられています。さらに、わが家はポンプで揚水しているため、圧力の変動を受けやすい環境です。したがって、7〜10年での交換は妥当な範囲だと考えています。

次回:交換編

部品が届いたら、KPS018への交換作業と結果を報告します。加えて、外したカートリッジのどこが劣化していたのかも紹介します。また、次の再発に備えて何を記録しておくかもまとめる予定です。

まとめ:混合栓の異音は切り分けと記録が決め手

  • 浄水側のレバーを押さえて音が止まるなら、切替カートリッジを疑う
  • 本体の品番は、品番シール→AI→図面→記録の順で特定する
  • 修理したら、部品の型番・購入先・価格・日付を記録しておく
  • 業者に頼んだときも、交換した部品の型番を聞いておく

7年前の自分がこの記録を残していれば、すぐに部品を注文できていました。この記事が、未来の自分と、混合栓の異音に悩む誰かの役に立てば幸いです。なお、ほかの修理やトラブル対処の記録は、ノウハウのカテゴリにまとめています。