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年秋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年以前)実施の迷惑メール対策方法、設定

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

Claude 詐欺メールを解剖する|認証が通っても偽物だった

ある日、「Claude Max トライアルの準備ができました」という件名のメールが届く。これは典型的なClaude 詐欺メールです。差出人の欄には「Claude」と表示され、本文には自分のメールアドレス、文末には Anthropic 社の住所まで載っている。だから本物の案内に見えてしまう。本記事では、この Claude 詐欺メールを実物のヘッダごと解剖し、見破り方とスパム判定の強化策まで整理します。

厄介なのは、この Claude 詐欺メールが SPF・DKIM・DMARC というメール認証をすべて「合格(pass)」して受信箱に届いていた点です。当サイトでは過去に何度も、認証技術によるなりすまし対策を取り上げてきました。今回はその強化してきたはずの判定をすり抜けた一通が題材です。なぜ通り抜けられたのか、何を見れば見破れるのか、最後にスパムとして弾く方法までを、一般の方とエンジニアの双方に向けて述べます。

届いた Claude 詐欺メールの中身

まず実物を見ます。本文は英語でした。受信者のメールアドレスは伏せています。

claude • max

Your Claude Max trial is ready
Hello,

You have been granted 1-month trial access to Claude Max.
(あなたに Claude Max の1か月トライアルアクセスが付与されました)

ACCOUNT
xxxxx@****(受信者本人のアドレス)

Get Started → https://claudetrial.com/?session=3355555667

Note: This invitation is unique to xxxxx@**** and will expire in 24 hours.
(この招待はあなた専用で、24時間で失効します)

Anthropic PBC, 530 Divisadero St, San Francisco, CA 94117, USA

一見、ただの「無料トライアル案内」です。自分のアドレス宛てに「あなた専用」と書かれている。Anthropic の正しい住所まで載っている。普段 Claude を使う人ほど、正規のお知らせと受け取りやすい。そこを突くのが、この Claude 詐欺メールの狙いです。

本文だけで分かる Claude 詐欺メールの兆候

落ち着いて読めば、本文だけでも危険信号が見つかります。

1. リンク先が Anthropic のものではない。「Get Started」の先は https://claudetrial.com/?session=335555667 です。Claude の正規サービスは claude.ai や anthropic.com で提供されます。claudetrial.com は無関係の別ドメインです。末尾の ?session=… は、クリックした人を追跡する仕掛けの可能性があります。このURLは絶対に開かないでください。

2. 「24時間で失効」と急かす。「あなた専用」「24時間以内」は、考える時間を与えず即クリックさせる古典的な手口です。正規の案内がここまで急かすことはまずありません。

3. 身に覚えのない「手続き完了」通知。申し込んでいないのに「ご要望に応じてお送りしました」とある。これもフィッシングの常套句です。

同種のキャンペーンは国内外で確認されています。セキュリティ企業 MailGuard は、Anthropic を騙る支払い失敗型のフィッシングを報告。日本でも2026年3月、「Claude 日本語無料版」を名乗る偽サイトがITmedia に報じられました。偽の Claude サイトがマルウェアを仕込んだ事例もMalwarebytes が解析しています。Claude の利用者が増えるほど、その名前を悪用する攻撃も増えています。

ヘッダで見抜く Claude 詐欺メールの正体

メールのヘッダ(送信元や経路の記録)を見ると、正体がさらにはっきりします。重要な部分を抜き出します。

From: Claude <accounts1@dallasmbs.com>
Reply-To: accounts1@dallasmbs.com
Return-Path: <accounts1@dallasmbs.com>

Received: from static195-40.de.dm.aliyun.com (47.245.195.40)
Received: from dallasmbs.com by smtp.aliyun-inc.com
Feedback-ID: default:accounts1@dallasmbs.com:alibabak_SmtpBatch

X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"

表示名は「Claude」でも、実際の差出人は accounts1@dallasmbs.com。これが核心です。メールの「表示名」は、送る側が自由に決められます。「Claude」とも「Anthropic」とも、誰でも名乗れる。一方で実アドレスは dallasmbs.com。Anthropic とは縁もゆかりもないドメインです。返信先も戻り先も、すべて同じ無関係ドメインでした。

配信経路は中国系クラウドの一斉配信基盤です。経路をたどると Alibaba Cloud の aliyun.com 系サーバを経由しています。Feedback-ID の alibabak_SmtpBatch は、バルク配信サービスの痕跡です。世界規模の Anthropic が、正規案内をこの種の基盤から送るとは考えにくい。

ヘッダ自体も壊れています。受信側が BAD HEADER SECTION の警告を出しました。「MIME-Version」が二重に書かれているという意味です。雑な送信ツールの典型的な痕跡で、正規の大規模配信ではまず起きません。送信時刻のタイムゾーンも経路ごとにバラバラでした。

なぜ認証は「全部 pass」したのか

ここが今回いちばんの要点です。この Claude 詐欺メールのヘッダには、こう記録されていました。

dkim=pass  header.d=dallasmbs.com
spf=pass   smtp.mailfrom=accounts1@dallasmbs.com
dmarc=pass (policy=none) header.from=dallasmbs.com

SPF・DKIM・DMARC が、いずれも pass。当サイトが「なりすまし対策」として紹介してきた三つの認証が、すべて通っています。「認証が通った=本物では?」と感じた方こそ、ここが落とし穴です。

カラクリはこうです。これらの認証が見るのは、「dallasmbs.com が dallasmbs.com として正しく送ったか」だけ。攻撃者は自分で取得した dallasmbs.com から送っています。だから検査は当然パスします。

つまりこの Claude 詐欺メールは、Anthropic を認証レベルで詐称してはいません。ドメインを偽装したのではなく、認証が一切見ない場所——「表示名」に「Claude」と書いただけです。

当サイトのDMARC 解説やなりすまし対策で強化したのは、主に「正規ドメインを騙るドメイン詐称の検知」でした。今回はドメインを詐称していないため、その網にかからず素通りした。これが「すり抜け」の正体です。SpamAssassin のスコアも score=1.6 required=30.0 と低く、ほぼ素通りでした。

逆のケースも知ると理解が深まります。あるセキュリティ製品の開発者は、本物の Anthropic メールを誤って詐欺判定した経験を公開しました。本文の印象だけでは本物すら怪しく見え、偽物が本物らしく見える。最終的に本物と確証できたのは、認証結果が header.from=claude.com で揃っていたから。「どのドメインとして認証が通ったか」を見たからです。

見るべきは「表示名」ではなく「実アドレス」

ここまでをひとことでまとめます。

認証が「合格」でも、それは「そのドメインとして正しく送られた」ことの証明にすぎない。「あなたが思う相手(Anthropic)から来た」ことの証明ではない。

だから見るべきは、派手な表示名(”Claude”)ではありません。実際の差出人アドレス(@dallasmbs.com)です。表示名が「Claude」でも、実アドレスのドメインが claude.ai や anthropic.com でなければ、正規の案内ではないと判断できます。

そして、ここが最も強調したい警告です。メーラーの中には、この実アドレスを隠し、表示名しか見せないものがあります。スマホのメールアプリでは特に、差出人欄に「Claude」とだけ出て、タップして初めて accounts1@dallasmbs.com が現れることがあります。設定によっては最後まで見えないものすらある。

確認すべき情報を隠すメーラーは、それ自体が危険です。普段使う環境で「実際の差出人アドレスが常に確認できるか」を、一度点検しておくことをおすすめします。なお、ツールや連携の挙動を過信しない姿勢は、当サイトの技術検証記事でも繰り返し触れてきた通りです。

Claude 詐欺メールをスパム判定するには(一般の方へ)

今回のメールは、メーラーもサーバも迷惑メールと判定できませんでした。認証が揃い、スコアが低かったためです。まずは技術設定なしでできる、一般の方向けの習慣から。

第一に、表示名でなく実際の差出人アドレスを必ず確認します。@より後ろのドメインが正規のものと一致するかを見るだけです。第二に、メール内のリンクは踏みません。必要ならブックマークや検索から公式サイトへ自分で行きます。

第三に、「24時間以内」「今すぐ」と急かすメールほど、いったん止まります。急かしは考えさせないための演出です。判断に迷えば AI に画像ごと相談するのも手ですが、AI も誤ります。最後はドメインの一致で確かめてください。

Claude 詐欺メールを弾くルール設計(エンジニアへ)

この Claude 詐欺メールが素通りした根本は、「ドメイン認証は正しいが、ブランド名を表示名で騙っている」点にあります。対策の方向は DMARC の先——認証では捕まらない『ブランド詐称』の検知です。

SpamAssassin なら、「From の表示名に著名ブランド名を含むのに、送信ドメインが正規でない」場合に加点するメタルールが書けます。考え方を示す擬似ルールが以下です。実運用では正規表現とドメインリストの精査が要ります。

# 表示名に "Claude"/"Anthropic" を含む
header  L_BRAND_NAME  From:name =~ /\b(claude|anthropic)\b/i

# 送信ドメインが正規ドメインでない(例:claude.ai / anthropic.com 以外)
header  L_NOT_OFFICIAL  From:addr !~ /\@(claude\.ai|anthropic\.com)$/i

# 両方に当てはまれば「ブランド詐称の疑い」として加点
meta    L_BRAND_SPOOF  (L_BRAND_NAME && L_NOT_OFFICIAL)
score   L_BRAND_SPOOF  4.0
describe L_BRAND_SPOOF  Display name claims a known brand but sender domain does not match

あわせて、実務では次の重み付けが効きます。新規・低評価ドメインへの加点です。dallasmbs.com や claudetrial.com のような、登録が新しく評価の低いドメインに点を上乗せします。今回ヒットした URIBL 系のフィードを増やすのも有効です。

次に一斉配信インフラのヒューリスティックです。海外バルク基盤+日本宛て+英語本文+著名ブランド名という組合せに加点します。今回 X_NONJAPANESE_SUBJECT が既にヒットしているので、足がかりにできます。さらに BAD HEADER SECTION などのヘッダ構文異常もスコアに織り込みます。

最後に、組織としては正規連絡元ドメインのホワイトリスト化が最も確実です。「Anthropic からの案内は claude.ai / anthropic.com 由来のみ」と運用ルールを明文化します。これらは SPF/DKIM/DMARC を置き換えるものではなく、その「外側」を補う層です。認証は「ドメインの正しさ」は保証しますが、「ブランドの正しさ」は見ていないからです。

まとめ:Claude 詐欺メールの教訓

今回の Claude 詐欺メールは、SPF・DKIM・DMARC をすべて pass しながら、受信者に「本物が来た」と誤認させる、よくできた一通でした。すり抜けの理由は、ドメイン偽装ではなく、認証が見ない「表示名」にブランド名を書いただけ。だから受信者は表示名でなく実アドレスのドメインを見るべきで、それを隠すメーラーは危険です。

弾く側は、認証の外側で「表示名とドメインの乖離」を検知する層を足すことが次の一手です。身に覚えのない「無料トライアル」「支払い失敗」「アカウント停止」が届いたら、まず止まって差出人の実アドレスを確かめる。それだけで、多くの被害は防げます。

関連記事

※本記事で扱ったメール・ドメイン・URL は、注意喚起のための実例です。記載のリンク先(claudetrial.com 等)には絶対にアクセスしないでください。

Claude Sonnet 4.6 と Opus 4.7 でフル実装した OSS コードを、今話題の Claude Fable5 でセキュリティチェックさせてみた

リリースされたばかりの最上位モデル「Claude Fable 5」を使って、AIでほぼフル実装した自前の OSS コードのセキュリティチェックをやってみた。結論から言うと——セキュリティチェックのリクエストは Fable 5 では処理されず、自動的に Opus 4.8 に“モデルダウン”されて返ってきた。本記事では、その一部始終と、最終的に Opus 4.8 が出したチェック結果の要約を、公開できる範囲で一般化して共有する。 Fable5

リリースされたばかりの最上位モデル「Claude Fable 5」を使って、AIでほぼフル実装した自前の OSS コードのセキュリティチェックをやってみた。結論から言うと——セキュリティチェックのリクエストは Fable 5 では処理されず、自動的に Opus 4.8 に“モデルダウン”されて返ってきた。本記事では、その一部始終と、最終的に Opus 4.8 が出したチェック結果の要約を、公開できる範囲で一般化して共有する。


背景:Sonnet 4.6 + Opus 4.7 でフル実装したコード

今回のチェック対象は、Claude Sonnet 4.6 と Claude Opus 4.7 を使ってほぼフルに実装した OSS のコードベース。プラグイン(拡張モジュール)を配布・インストールできるタイプの Web アプリ構成で、規模感は後述の通り。

「AI でフル実装したコードは、別の上位モデルにセキュリティ監査させたらどう評価されるのか」——これを確かめたかった、というのが今回の動機だ。


日本から Fable 5 に「セキュリティチェック」を依頼してみた

Fable 5 がアナウンスされたのは米国時間 2026 年 6 月 9 日。ただし提供は国・地域や対象ユーザーによって扱いが分かれており、日本から実際に利用できるようになったのは、このアナウンスより後のことだった。本記事の検証は、日本から利用できた期間にあたる 2026 年 6 月 11 日ごろに行っている。

手順はシンプルで、対象コードを読み込ませ、「脆弱性の有無と状況を報告してほしい」と依頼しただけだ。

ところが返ってきた挙動は予想外だった。

  • 応答に「理由」へのリンクが表示された
  • そして肝心のリクエストは Fable 5 ではなく Opus 4.8 にモデルダウンされて処理された

なぜダウンされたのか

最初は理由がよく分からなかったが、これは仕様だった。

Fable 5 には、サイバーセキュリティや生物・化学といった高リスク領域、さらにモデルの“蒸留”を検知するセーフガードが組み込まれており、該当すると判定された場合は Fable 5 ではなく Opus 4.8 が代わりに応答する設計になっている。今回は「セキュリティチェック」という依頼自体がサイバーセキュリティ関連と判定され、自動的に Opus 4.8 へ引き継がれた、というわけだ。

公式も「安全で通常のコンテンツでもフラグが立つことがある」「現在、精度の改善に取り組んでいる」と注記している。つまり、現状では “セキュリティチェックは Fable 5 の担当外” と捉えるのが実態に近い。

現状の注記(2026/06/13 時点):Anthropic は米国政府の輸出管理指令を受け、6 月 12 日(米国時間)に Fable 5 / Mythos 5 への全ユーザーのアクセスを停止した。この指令は外国籍ユーザー(米国の内外を問わない)を対象としており、日本のユーザーは現在 Fable 5 を利用できない状態にある(Anthropic は復旧に取り組むとしている)。検証を試みる場合は、最新の提供状況を必ず確認してほしい。(参考報道:ITmedia NEWS/Impress Watch)


開発自体は Opus 4.8 → Fable 5 に切り替えて継続

セキュリティ系の依頼はダウンされる一方で、通常の OSS 開発作業は Fable 5 で問題なく進められた。そこで、これまで Opus 4.8 で進めていた開発を Fable 5 に切り替えて作業を継続した。

その結果と、切り替えにあたって出てきた課題は、別記事に詳しくまとめている。


Opus 4.8 によるセキュリティチェック結果(要約・一般化)

ここからは、結局 Opus 4.8 が実施したセキュリティチェックの結果を、公開できる範囲で一般化して共有する。具体的な内部名・攻撃手順には踏み込まず、指摘の「分類」と「深刻度」のレベルで整理した。

対象コードの規模

項目規模
ファイル数約 30 ファイル
コード総量約 210 KB
実装言語Python 中心(約 4,000 行)
レビュー方式静的レビュー(ソースコード精読)

深刻度別の指摘件数

深刻度件数
🔴 Critical0
🟠 High1
🟡 Medium6
🟢 Low6
ℹ️ Info4
合計17

無条件のリモートコード実行のような致命的な欠陥は検出されず、全体としては 「セキュリティを意識した堅実な実装」 という評価だった。ただし多層防御(defense in depth)の観点では、計 17 件の改善余地が挙がった。

主な指摘(カテゴリ別・一般化)

分類深刻度概要(一般化)
認証・認可の外部依存🟠 High本体側に独自の認証機構がなく、強い副作用を持つ API(インストール/アップロード/設定保存など)の保護を、上位の Web サーバ側の認証に全面的に依存している
CSRF 対策・トークン検証🟡 Medium状態を変更する API に Origin / Referer チェックやトークン検証がない。また URL パラメータ由来の値が検証されないまま画面に反映され得る
外部リソース取得(SSRF)🟡 Mediumインストール処理が、指定された URL へ制限なくアクセスし得る
アーカイブ展開時のパス検証🟡 Medium配布パッケージを展開する前のパス検証が不十分(いわゆる Zip Slip)
画面描画時のエスケープ(XSS)🟡 Medium外部由来の文字列を、エスケープせずに DOM へ挿入し得る箇所がある
その他🟢 Low / ℹ️ Infoログ出力・エラー処理・依存関係などに関する軽微な改善提案

評価できた点

監査では、以下のような「すでに適切に対策できている点」も明確に挙げられた。

  • 待ち受けをループバックアドレスに限定している
  • プラグイン名を許可リスト(allowlist)方式で検証している
  • 配布インデックスのスキーマを検証している
  • パス・トラバーサル対策が入っている
  • セキュリティ関連ヘッダを一律で付与している
  • 設定ファイルをアトミックに書き込んでいる

対応方針

報告書には、優先度(P1〜P3)付きの改善ロードマップも併記した。要点は次の 3 つに集約される。

  1. 本体側にも、最低限の認証・CSRF 対策を持たせる
  2. 外部リソースの取得とアーカイブ展開に、検証処理を入れる
  3. 画面描画は一律でエスケープする

なお、実効的なリスクは 上位の Web サーバ側の認証構成(本コードの外側) に大きく左右される。そのため、最終的な安全性の評価は、その構成とあわせて確認する必要がある——この点は報告書にも免責として明記している。


補足:今回のチェックは「静的レビュー」である点に注意

ここは結果を読むうえで重要なので補足しておきたい。

今回 Opus 4.8 が行ったのは、ソースコードを読んで解析する 静的レビューだ。報告書自身も方式を「静的レビュー(ソースコード精読)」と明記している。実際にアプリを起動して通信を流す、いわゆる 動的テスト(実行時の検証)は行っていない。

これは Anthropic 自身が提供する専用機能の位置づけとも一致する。同社の「Claude Code Security」も、コードを読んで文脈やデータフローを追う 静的解析として位置づけられており、アプリを実行して挙動を確かめる ランタイム(動的)ツールではないとされている。手法としては、従来のルールベース(パターンマッチ)型 SAST とは異なり、文脈やロジックを追う「エージェント的なコード推論」に近い。逆に、実行時にしか現れない種類の不具合は、そもそも対象外になる。

そのうえで、結果を読むときに押さえておきたい点が 2 つある。

1. 「過剰検知」が起きやすい

ルールベースの従来型ツールと違い、AI によるレビューは実行のたびに解析内容が変わる 確率的(ストキャスティック)なものだ。文脈を踏まえて深い指摘ができる反面、毎回同じ結果になるとは限らず、影響の小さい指摘や誤検知(false positive)が混ざりやすい。Anthropic の専用ツールでも、ノイズを減らすための誤検知フィルタや、最終判断を人に委ねる運用(human-in-the-loop)が前提になっている。今回のような「チャットにコードを貼って読ませる」簡易な使い方では、そうしたフィルタは働かないため、各指摘は「確定した脆弱性」ではなく 要確認の候補として、1 件ずつ人手でトリアージする必要がある。

2. 見ているのは「渡したコードだけ」

今回のレビューは、読み込ませたソースの範囲しか見ていない。サーバ(Apache)側の設定や、実際の運用環境までは把握していない。報告書が「実効リスクは上位の Web サーバ側の認証構成(本コードの外側)に左右される」と免責しているのは、まさにこのためだ。一般的なコードチェックツールが想定する「システム全体を俯瞰した解析」とは前提が異なる点に注意したい。

要するに——本当に影響があるかどうかは、この静的レビュー結果だけでは確定できない。各指摘について、実際の構成・データフローを踏まえた人手の確認と、必要に応じた動的テストを重ねて初めて、実効リスクが判断できる。AI の静的レビューは「あたりを付ける」には非常に有用だが、最終確定には別の検証が要る、というのが実情だ。


やってみての所感

正直に言えば、手応えよりも 「Fable 5 で確認できなかった」失望のほうが大きい。最上位モデルでセキュリティ監査を、と期待したのに、現状はセーフガードで自動的に Opus 4.8 へ引き継がれてしまう。セキュリティチェックは Fable 5 の担当外、と割り切るしかなかった。

代わりに動いた Opus 4.8 の静的レビューについても、評価は手放しではない。

  • 既存の静的チェックツールとの差は、正直よく分からない。 文脈を読む深さに見どころはあるが、「専用ツールを置き換えるほどの決定的な違い」を今回の範囲で実感できたわけではない。
  • 専用の静的チェックツールを購入しなくても、ある程度のチェックができるのは確かにアリだ。ただし AI ゆえに「漏れなく・均一に」チェックできる保証がないのが微妙なところ。実行のたびに結果が揺れる確率的な仕組みである以上、ここは本質的な弱点になる。
  • したがって、既存の静的チェックツールをやめて AI チェックに全面的に切り替えるのは、「漏れなく検出できるか」という一点で NG だと考える。網羅性・再現性が求められる場面では、まだ任せきれない。

一方で、可能性も感じた。もし AI が、ソース単体だけでなくシステム全体の構成まで含めて判定してくれるようになれば、既存の静的チェックツールと組み合わせて効率的な作業ができるかもしれない。そう考えると、AI が静的チェックツールを置き換えるのではなく、静的チェックツール側に AI が組み込まれていく未来のほうが、現実的で筋が良さそうだ。


参考リンク(外部)

Claude AI と“フル開発”する2026・続編 ― Fable 5 で見えた「現在位置の再構築」という壁

Mythos 相当の Fable 5 を検証、
Claude AI と“フル開発”する2026・続編 ― Fable 5 で見えた「現在位置の再構築」という壁

前回の記事「光と、壁」では、AIと“フル開発”を進めるときの手応え(光)と、その先に立ちはだかる限界(壁)について書きました。今回はその続編として、壁の正体にもう一歩踏み込みます。きっかけは二つ。最上位モデル Fable 5 の登場と、作業がセッションの制限で途中で止まった、ある一件でした。

Mythos 相当の Fable 5 に、使うモデルを上げてみようとした

Fable 5 は2026年6月に公開された、Claude シリーズで現時点もっとも高性能な一般公開モデルです。これまで一部の組織にのみ限定提供されていた最上位ティア「Mythos」相当の能力を、独立した安全機構を組み込むことで初めて一般公開した、という位置づけになっています。Opus 4.8 の上位にあたり、数時間〜数日に及ぶ長時間・複雑なタスクや、自律的に動くエージェント運用での強さがうたわれています。

「それなら使うモデルを上げてみよう」と切り替えようとしたところ、画面にはこう表示されました。
「This model isn’t available right now. You can switch to another model to continue using Claude.(このモデルは現在利用できません。別のモデルに切り替えれば、引き続き Claude を使えます)」

公開直後はこうした一時的な制限が出ることがあります。拍子抜けすると同時に、ふと立ち止まって考えました。自分は前評判で“過剰な期待”をしていないか、と。

モデルが強ければ、勝手に良い結果が出るわけではない

強いモデルは、こちらの前提整理の甘さまで吸収してくれる魔法ではありません。むしろ前提――指示・ルール・文脈――が難解だったり量が多すぎたりすると、強いモデルほど「全部こなそう」として、かえって挙動がぶれることがあります。

だからこそ、「いちばん賢いモデルを選べば自動的に最適」とは限りません。目的に合わせてモデルを選ぶ行為そのものが、設計の一部です。これは人に仕事をお願いするときと、やる方向性は同じで、前提を整え、ゴールを共有し、節目で確認する。相手がAIでも、変わりません。

効いたのは「小さく、絞る」― 特化スキルという解

AIに渡す作業ルール集(いわゆる「スキル」)を整備したところ、作業が目に見えて安定して進むようになりました。なかでもいちばん効果的だった改善は、一つのファイルサイズを小さく抑えることでした。

これは、スキルそのものにも効きます。サイズが大きすぎるスキルは“熟読”されず、結果としてルールが守られないことが多々発生します。実際、肥大化したルール集は分割しました。改訂履歴や補足を別ファイルへ外出しし、領域ごとに小さなスキルへ割り直したところ、読み込みが軽くなり、ルール遵守が安定しました。

見落とされがちですが、ここがいちばんの肝です。最初に投入するルールが鋭く研がれていれば、出力は驚くほど高い水準に届きます。逆に、あれもこれもと多量のルールを詰め込むと、出力はぼんやりと平均化し、よくできた検索ツール程度の答えしか返ってこなくなります。いろいろやらせすぎると、かえって性能は出ないのです。つまり、たどり着く到達点(最適点)は、最初に与えるルールベースの鋭さで決まります。最適点はあらかじめ一つに定まっているのではなく、出発点しだいで高くも低くもなる。だから、ルールを増やして細かく縛れば堅牢になる、とは限りません。むしろルールが増えるほど、それを破る挙動が多発します。

コーディングでも同じ傾向があります。ファイルが大きいと読み直しが増え、似た字形・同音語の取り違え(文字化けに近い誤り)も起きやすく、無駄な処理コストにつながります。小さく保つと、ここが目に見えて減ります。

そして気づいたのは、特定の領域に特化して小さく組み上げたスキルは、汎用に大きく書いたものより高い性能を引き出せる、という感触です。「広く曖昧」より「狭く明確」。賢さの絶対値より、前提の整え方のほうが効くのです。

「すごいのはモデル」なのか ― 増幅されるのは“問いの鋭さ”

この見立ては、いま話題のセキュリティAIにも当てはまると感じています。Anthropic は、一般公開していない最上位モデル「Claude Mythos」を限定パートナーと運用する取り組み(Project Glasswing)の初期結果として、約1か月で1万件を超える高・重大度の脆弱性を特定したと公表しました(出典:Anthropic「Project Glasswing」)。英国の公的機関 AI Security Institute(AISI)の独立評価でも、隔離された検証環境で同モデルが脆弱性を自律的に発見・悪用し、32段階の侵入シミュレーションを完了できたと報告されています(出典:AI Security Institute の評価)。

数字だけ見ると「モデルがすごい」と思ってしまいます。けれど見方を変えると、すごいのはモデル単体ではなく、そこに鋭い問いと手順を与えた、目を磨き上げたエンジニアのセキュリティスキルのほうではないでしょうか。モデルは増幅器のようなもので、鋭い問いを入れれば鋭く、鈍い問いを入れれば鈍く増幅します。脆弱性をあれだけ掘り当てられたのは、勘所を絞り込んだ“特化した問い”があったからこそ、とも読めます。先ほどの「小さく、絞る」話と、根は同じです。

そして、その鋭い目を持つハイスキルエンジニアは、そう簡単には育てられません。モデルは誰でも同じものを使えます。差がつくのは、何を・どう問うか、どんなルールベースから出発するか――つまり人側の技能です。ここを育て続けられるかどうかが、これからの企業の生き残りを分けるポイントになるのかもしれません。

「現在位置の再構築」― 変だと思ったら立ち止まる

運用を続けるうちに、時々、スキルから外れた作業が行われることに気づきました。そうした挙動を見つけたら「スキルをもう一度確認して」と促す。それだけで、たいていは元に戻ります。

これを繰り返すうちに、その現象が起きるときにはパターンがあるとわかってきました。挙動が乱れやすいのは、次のようなときです。

  • 作業の途中で、セッションの制限により処理が止まったあと
  • 使うモデルを切り替えたあと
  • 提供側(Anthropic)のアップグレードが行われたあと
  • 前回の作業から、長い時間が空いたあと

共通点は、「現在位置」――いまどの前提・どの文脈の上で作業しているのか――の連続性が切れる瞬間だ、ということです。だから再開時には、“いまどこにいるのか”をもう一度組み直す必要がある。私はこれを現在位置の再構築と呼んでいます。今回いちばんお伝えしたかったのが、この一点です。

対処そのものはシンプルです。変だと思ったら、いったん止めて確認させる。これがいちばん効きます。そして、モデルの切り替えのように意図的に制御できるものは、注意すれば最初から避けられます。

少しメタな余談を。この記事自体、前回ぶんの作業がセッション制限で途中停止していました。再開のとき私たちがまずやったのは、本文を書き始めることではなく、“どこまで進んでいたか”の確認と、“前提(方針・公開先・書き方のルール)”の再確認でした。それはまさに、ここで言う現在位置の再構築そのものでした。

まとめ ― 壁は「賢さ」では越えられない

「光と、壁」の続きとして見えてきたのは、壁はモデルをいちばん賢いものに上げれば消える、という種類のものではない、ということでした。鍵は、モデルの賢さそのものより、鋭く絞った問いを設計できる人側の技能にあります。出発点となるルールを小さく整え、特化したスキルを用意し、節目ごとに現在位置を組み直す。この地道な運用こそが、人とAIの共同開発を安定させます。

最適点は一つに決まってはいません。だからこそ、出発点を選び、確かめ、そして立ち止まる余地を残しておく。Fable 5 が使える日が来ても、たぶんこの原則は変わらないはずです。

関連記事・参考

Ubuntu26 / PHP8.5 移行で発生したトラブルと対処方法|Failed to get boot ID・ProcSubset=pid

Ubuntu 26 と PHP 8.5 への移行作業中に、従来環境では発生しなかった問題をいくつか確認した。本記事では hash 仕様変更や systemctl status 実行時の「Failed to get boot ID」など、実際に遭遇したトラブルと対処方法をまとめる。

Ubuntu 26 と PHP 8.5 への移行作業中に、従来環境では発生しなかった問題をいくつか確認した。本記事では hash 仕様変更や systemctl status 実行時の「Failed to get boot ID」など、実際に遭遇したトラブルと対処方法をまとめる。
※移行はまだ完了していないので、随時追加更新していきます。

Ubuntu26・PHP8.5移行で発生した問題

PHP 8.5のhash仕様変更で発生した問題 hashのデフォルト動作変更、php内の内部処理、仕様の変更

軽く受け流せば、すぐに解決出る問題かもしれないが、対処の過程でGPTの修正案がセキュリティ脆弱性を引き起こすものだったので、参考のために書いておく。
GPTは安易に、セキュリティ対策実装をもっともらしい理由をつけて消す。それで、何とか動くケースだったらもしかしたら見逃していたかもしれないが、その修正では動かなかった。じっくりコードを見直したところ、除去してはいけないセキュリティ対策実装であったというものだ。 別な対処方法で解決できた。
 直接原因は、hash値に使用される文字の種類が拡張されたことです。詳細についてはセキュリティにまつわる話なので非公開とします。このようにセキュリティ関係の情報は非公開であることが多いのか、GPTも弱いようです。脆弱性の検出に使うのはよいとしても、セキュリティ確保には十分ではないというか、セキュリティ周りの実装は丸投げするのは危険だろう。

ブラウザ経由の PHP exec() → 「Failed to get boot ID」が出る systemctl statusでFailed to get boot IDが発生

実装修正で、比較的簡単に回避はできたが、これが発生する原因特定には時間を要している。

# systemctl cat apache2.service
# /usr/lib/systemd/system/apache2.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=https://httpd.apache.org/docs/2.4/

[Service]
Type=notify
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true
Restart=on-abnormal
OOMPolicy=continue
RemoveIPC=yes

DevicePolicy=closed
KeyringMode=private
LockPersonality=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=read-only
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes


# systemctl show apache2.service | grep -E 'ProtectProc|ProcSubset|ProtectKernelTunables|ProtectKernelModules|RestrictNamespaces|ProtectSystem|ProtectHome|ReadOnlyPaths|InaccessiblePaths|PrivateTmp|RestrictAddressFamilies'
InaccessiblePaths=/boot /root -/etc/sudoers -/etc/sudoers.d -/etc/ssh -/etc/apt -/etc/.git -/etc/.svn
PrivateTmp=no
PrivateTmpEx=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectHome=read-only
ProtectSystem=full
RestrictNamespaces=yes
ProtectProc=invisible
ProcSubset=pid

ProcSubset=pid これが設定されていると、プロセスから見える /proc が自分のPID関連だけに絞られ、/proc/sys/ 配下がまるごと見えなくなります。systemctl status は内部で /proc/sys/kernel/random/boot_id を読もうとするので、Apache配下のPHPから実行したときだけ「Failed to get boot ID: No such file or directory」が出ていた、というわけです。

⇒対処方法
いろいろな対処方法がありますが、
statusのかわりに showを使うように見直しました。
具体的には次のよう感じです

修正前
$command = "systemctl status NetworkManager.service 2>&1";

変更後
$command = "systemctl show NetworkManager.service -p ActiveState,SubState,ActiveEnterTimestamp 2>&1";

PHP 8 の「数値文字列と非数値文字列の比較ルール変更

if ( $m === 0 ) { //部分一致する文字列がなければ 数値化してみる

★PHP7では数値文字列を数値に自動変換していたが、PHP8では変換しない

Ubuntu 22 と 26 で変わったこと

whoコマンドの挙動変化

挙動変化に伴いログイン状態のチェックができなくなっています

# 旧
who | grep tty2

# 新
pgrep -t tty2 2>/dev/null | xargs -r -I{} ps -p {} -o comm= 2>/dev/null | grep -v "^agetty$" | grep -v "^$" | wc -l
# 旧
who

# 新
loginctl list-users
# または
loginctl list-sessions

ImageMagick

Ubuntu 26 移行に伴うビルド側のパッケージ構成変更(GraphicsMagick の IM 互換コマンドを失った)

★ちょっと想定外なdmarcの過剰fail 2025年内に終了するので放置なのか?

DMARC設定で、過剰にfailしているのを発見しました。 ちょっとだけ想定外でした。。。 対象のメールは、ちょっと前に書いたソーラーフロンティアのメールです。


ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=pass header.d=hke.dkim.mpse.jp header.s=mpse.201103 header.b=Stua66Jg;
spf=pass (***.xserver.jp: domain of z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp designates 106.185.96.14 as permitted sender) smtp.mailfrom=z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp;
dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (strict)" header.from=solar-frontier.com (policy=none)

ちょっと対策が必要そうです。

関連記事

https://www.nri-secure.co.jp/blog/dmarc-report