2026年夏版 最新AIはこう使え ― MCPからClaude Coworkへ、実務を「任せる」ための環境が変わった ―

春版の「人・もの・かね」を踏まえ、半年で起きた最大の変化「MCPからCoworkへ」を解説。フォルダ接続へ変わった許可設定とサンドボックスを実体験から。

この半年でAI活用の景色を変えたのが、Anthropicの「Cowork」です。春に「AI活用は“ひと・もの・かね”で読み解ける」という話を書きましたが、その枠組みは変えずに、今回は“AIに実務を任せる土台”がどう変わったかを、夏版としてお届けします。

  • ひと → AI+スキル
  • もの → MCP+操作対象リソース
  • かね → セッション(利用制限)

この枠組みは今も変わっていません。前提として、まず春版をご覧ください。
2026年春版 最新AIはこう使え ―「人・もの・かね」から読み解くAI活用の新常識―

そのうえで、この半年で現場に一番効いてきた変化を、夏版として1つだけ掘り下げます。テーマは「MCPからCoworkへ」。AIに“手足”を与える方法そのものが、変わり始めました。

Coworkとは — Anthropicが提唱する「実務を任せる」仕組み

Claude Cowork(クロード・コワーク)は、Anthropicが提唱する新しいAIの使い方です。2026年1月に研究プレビューとして登場し、4月にmacOS/Windowsで一般提供、7月にはWeb・モバイルへと広がりました。短期間で対象がどんどん広がっています。

ひとことで言うと——CoworkはClaudeに“実務そのもの”を任せる場所です。

春版の言葉でいえば、これは「もの=AIの手足」を、より安全に付け替えられるようにした仕組みです。つまり、Claudeとの対話の中で許可設定を行う仕組みに強化された、ということです。設定ファイルを開いて書く代わりに、「このフォルダを使っていい?」に答えるだけ。(「より安全に」が具体的に何を指すかは、記事の後半であらためて説明します。)

利用者目線で、何が変わったのか — 設定ファイルから「フォルダ接続」へ

体感がいちばん大きいのは、環境構築まわりです。

これまで(MCP直結の時代)
AIにファイルを触らせるには、設定ファイル(claude_desktop_config.json)に filesystem サーバーを書き、ドライブを列挙する作業が必要でした。うまくいかなければ再起動し、バージョンを固定し、記述ミスを疑う。(この設定に何度もハマった記録は別記事に書きました → ステージング版正式公開版(mic.or.jp)

いま(Cowork)
設定ファイルを触りません。「このフォルダを接続していい?」に、あなたが1回OKを出すだけ。承認した瞬間から読み書きできます。再起動もバージョン固定も不要です。

しかも許可の粒度が細かい。フォルダ単位・セッション単位で、必要なぶんだけ。使い終われば、その権限は持ち越しません。

「設定する」から「その場で許可する」へ。環境構築の主役が、設定ファイルから“承認”に移りました。

夏版_MCP-Cowork仕組み図ダウンロード

CoworkはMCPを隠蔽化する仕組みなのか

使ってみての率直な感想です。Coworkは、MCPを隠蔽化する仕組みのように見えます。

より正確には、MCPをなくしたのではなく、その「設定」と「権限付与」を利用者から見えない場所に畳み込んだ、という感じです。

  • ファイル接続:ほぼ隠蔽。もう「MCP」という単語すら意識しません。
  • 外部サービス連携:隠すというより“包む”。MCPは裏で生きていて、コネクタの提案という形で見えにくく・使いやすくなっています。

そして——Coworkの裏側にはMCP相当の仕組みが、利用者に見えない形で確かに存在します。外部サービスは今もMCPコネクタそのもの、ファイルは接続したフォルダをサンドボックスにマウント。利用者はそれを直接見ません。要するにCoworkは、「MCPを知らなくてもAIに手足を付けられる」ための製品化レイヤーなのだと思います。

「より安全に」とは具体的に何か — 最小権限とサンドボックス

後回しにした「安全」の中身です。Coworkの安全は、だいたい次の4つで担保されています。

  • フォルダ単位:許可したフォルダしか触れない
  • セッション単位:許可は持ち越さない。使い終われば消える
  • サンドボックス:コード実行は隔離された環境(仮想環境)の中。ホストPCを直接いじらない
  • ネットワーク:既定では勝手に外に出ない(許可制)

春版の「もの=手足」に対して言えば、手足を出せる範囲を、あらかじめ囲ってあるということです。

ここに大事な連鎖があります。裏でMCP相当の“見えない仕組み”が動くからこそ、その隠蔽に安心感を持たせるために、動作環境を仮想環境(サンドボックス)に閉じ込める——という設計になっている。「見えないものが動く」怖さを、「触れる範囲を囲う」ことで打ち消しているわけです。

サンドボックス(仮想化)のコストという論点

ただ、囲うにはコストがかかります。

サンドボックスを仮想化やクラウドで用意すれば、セッションごとに計算資源のコストが発生します。ここは春版の「かね=配分すべき経営資源」の続きの話です。

一つの発想として——毎回クラウドで仮想環境を立てる代わりに、多少スペックの低いマシンでも“専用の物理サンドボックス機”を1台用意し、そこで動かせば、コストを抑えられるかもしれません。安全のための隔離は「別の箱で動かす」ことが本質なので、その箱が仮想か物理かは、目的次第で選べるはずです。

もちろんトレードオフはあります。クラウドの隔離は毎回まっさらで、維持管理が要らず、同時にいくつも立てられる弾力性がある。物理機はそのクリーンさと手軽さを手放す代わりに、コストを固定費に寄せられる。どちらが得かは使い方次第で、「安全のためのコストをどう持つか」は、これからのAI活用の設計課題になっていくと思います。

使い方の提案 — Cowork時代の許可設定の作法

  1. ファイルは「フォルダ接続」を主経路に。Coworkで作業するなら、旧設定ファイルに頼らず、都度フォルダを接続する運用へ切り替える。いちばん素直で、つまずきが少ない。
  2. 「どちらの層で動く操作か」を意識する。ファイルの読み書きはCowork接続、外部サービスはコネクタ(MCP)。繋がらないときは、まず「どの経路を叩いているか」を疑う。
  3. 最小権限を“不便”ではなく“作法”として使う。毎回の接続はひと手間ですが、これは「任せる相手に、必要なぶんだけ鍵を渡す」ことそのものです。
  4. 旧config方式の人こそ、一度見直す。設定が正しくても、Coworkでは反映されないことがある。両面を知っておくだけで、無駄なトラブルを避けられます。

これは新しい“弊害”でもあります。Coworkでは、こちらが「このフォルダをCoworkで接続して」と指示しないと、MCPの設定自体は正しくできていても、ファイルにアクセスできないことがあります。従来なら“設定さえ合っていれば動く”はずが、Coworkでは“その場の接続指示”という一手間が新たに必要になった——便利さと引き換えの、小さな引っかかりです。

【体験メモ】設定ファイルにはドライブを正しく書いてある。なのにCoworkからは繋がらない。「フォルダを接続」に切り替えたら一発で解決した。原因は、Coworkの標準ファイル操作が“旧設定ファイル”ではなく“フォルダ接続”のほうを見て動くから。

むすび — AIは進化し続ける。人間にも“使いこなす力”が問われる

春版の結論は「AIは設計してから任せる」でした。夏版はその一歩手前をこう言い直します。任せるには、まず“安全に繋ぐ”ところから。

Coworkの「最小権限・セッション単位で、その都度許可する」という作法は、「部下にどこまで任せるか」というあの昔ながらの問いと地続きです。全部の鍵を最初から渡さず、仕事に必要なぶんだけ、その都度渡す。

そして——ここが今回いちばん伝えたいことです。このようにClaudeをはじめとするAIは、これからもどんどん新しい形へ進化していきます。半年で「MCPからCoworkへ」動いたように、また次の形が来る。

だとすれば、問われているのはAIの性能だけではありません。新しいものを理解し、使いこなす力——それが、私たち人間の側にも求められています。AIが進化するスピードに、学び続ける私たちが並走できるか。そこが、これからのAI活用の本当の分かれ目なのだと思います。

関連記事

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.aianthropic.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-IDalibabak_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.comdallasmbs.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.aianthropic.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.comclaudetrial.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 NEWSImpress 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 が組み込まれていく未来のほうが、現実的で筋が良さそうだ。


参考リンク(外部)

spamの配信ツールはDNSキャッシュがずっと残る?

サーバが切り替わったので、古いサーバ宛のメールはほとんど来なくなりましたが、今日もまだ古いサーバに1件メールが来ていたので確認してみました。

”Security Notice. ……”というタイトルのspamメールでした。
送信ツールから、直接古いメースサーバ宛に送信されていました。普通のメールクライアントからの送信なら、送信用メールサーバーを経由するので、2段階以上の送受信となるはずですが、つぎのように、1段階だけでした。
 この部分をチェックするだけでも、何らかのツールを使って送信していることが分かります。

メールのソース
:省略
X-Mozilla-Keys:                                                                                 
Return-Path: <xxx@mic.or.jp>
Received: from tm.82.192.61.119.dc.telemach.net (tm.82.192.61.119.dc.telemach.net [82.192.61.119])
 by mic.or.jp (Postfix) with ESMTP id 7070911002A03
 for <xxxx@mic.or.jp>; Wed,  9 Oct 2019 10:25:50 +0900 (JST)
From: xxxx@mic.or.jp>
To: <xxxx@mic.or.jp>
Subject: 
:省略

  そして、DNSを切り替えて、1週間程度経過しているにも関わらず、古いサーバ宛に送信されています。 どこかにキャッシュされていたDNS情報を取得して古いサーバ宛に送信されたことが考えられます。しかし、今回のケースだと、1週間以上前にもメール送信した実績があり、その時に取得したDNS情報をキャッシュしていて、昨日メール送信する際にその情報を使ってメール送信したと考えるのが妥当でしょう。 メールマガジンの配信など大量メール送信ツールにはDNS情報のようにキャッシュできるものはキャッシュして性能を稼ぐ実装を採用しているものもあります。そのような技術をspam送信に利用しているのでしょう。