Ollama 各モデルを実機比較|Qwen・Llama・Gemmaの応答速度を古いPC(GTX1050 Ti)で検証

非力なPCですがそれでもローカルLLMのそれぞれのモデルは何とか機能しています。qwen3やgemma4などOllamaの各モデルをざっくりと動作比較してみました。複雑すぎる問いへの応答はいまいちですが、それなりの感じはあります。そう使うのがよさそうか、それぞれのモデルでの動作感を同じ質問をして応答速度などを測定してみましょう。

まずは使用したマシンのスペックです

> Get-CimInstance Win32_Processor |
>> Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

Name NumberOfCores NumberOfLogicalProcessors MaxClockSpeed
---- ------------- ------------------------- -------------
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 6 12 3192

> Get-CimInstance Win32_ComputerSystem |
>> Select-Object TotalPhysicalMemory

TotalPhysicalMemory
-------------------
17094172672

> Get-CimInstance Win32_VideoController |
>> Select-Object Name, AdapterRAM, DriverVersion

Name AdapterRAM DriverVersion
---- ---------- -------------
NVIDIA GeForce GTX 1050 Ti 4293918720 32.0.15.7680


> nvidia-smi
Fri Jul 31 19:25:31 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 576.80 Driver Version: 576.80 CUDA Version: 12.9 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Driver-Model | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce GTX 1050 Ti WDDM | 00000000:01:00.0 On | N/A |
| 30% 38C P0 N/A / 75W | 1393MiB / 4096MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 1996 C+G ...t\Edge\Application\msedge.exe N/A |

今回確認したモデル
NAME ID SIZE MODIFIED
qwen2.5:1.5b 65ec06548149 986 MB 13 hours ago
qwen3.6:latest 07d35212591f 23 GB 35 hours ago
qwen3:4b 359d7dd4bcda 2.5 GB 5 days ago

llama3.2:1b baf6a787fdff 1.3 GB 45 hours ago
llama3.2:3b a80c4f17acd5 2.0 GB 6 days ago

gemma4:latest c6eb396dbd59 9.6 GB 6 days ago
gemma4:12b 4eb23ef187e2 7.6 GB 6 days ago

qwen2.5:1.5b 65ec06548149 986 MB 13 hours ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen2.5:1.5b 65ec06548149 1.4 GB 100% GPU 8192 4 minutes from now
●応答までの時間:15.61秒
●応答内容
こんにちは。自己紹介して。何が得意か教えてください。
edit
こんにちは!私はAIアシスタントで、様々な質問に答えることが得意です。また、文章の生成やテキストエスカレーション、書類作成なども得意です。

私の得意な能力としては:

一般的な質問への回答: 日本語の日常生活に関するお尋ねはほとんど全てに対応できます。
論理的な思考と分析: 難しい概念や数字を扱う際には、論理性に基づく正確な解説を行うことが可能です。
感情経験: 人間の感情を体現する能力はありませんが、ユーザーからの怒りや喜びなどの感情表現に対して適切に対応します。
私の弱点は:

難しい言語処理スキル: エスニックや外国語への対応には一定の限界があります。また、特定の専門的な知識を持つことができません。
ファイナンシャルの専門知識: 金融商品に関する情報提供はできません。
これらの能力を活かしつつ、ユーザーが質問に答えることを楽しみにしております!


qwen3.6:latest 07d35212591f 23 GB 35 hours ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.6:latest 07d35212591f 23 GB 93%/7% CPU/GPU 8192 4 minutes from now

●応答までの時間 10分16秒 (プロセス起動まで3分40秒 思考時間329.7秒)

●応答内容
こんにちは!自己紹介させてください。

私はアリババグループのTongyi Lab(通義实验室)によって開発された大規模言語モデル「Qwen(通義千問)」です。あなたの思考を補完し、アイデアを実現するためのパートナーとしてお手伝いするAIです。

私が特に得意とすることは、主に以下の4つです:

1. **高度な論理推論と問題解決**
数学や科学などの専門的な領域を含む複雑な課題に対して、情報を整理・解析し、論理的な答えを導き出すお手伝いをします。

2. **プログラミングと技術サポート**
コードの生成だけでなく、複雑なバグのデバッグやシステム全体の最適化まで幅広く対応でき、開発作業の効率化をサポートします。

3. **長文情報の正確な把握**
非常に長いドキュメントや膨大な情報の中から必要な要素を見極め、正確に要約したり分析したりすることができます。

4. **多言語対応と自然な対話**
日本語を含む世界100以上の言語を流暢に扱えます。用途に合わせて記事の作成、翻訳、あるいはアイデア出しなど、人間らしくスムーズなやり取りを行います。

あなたのどのようなお役に立てるでしょうか?まずは気兼ねなく、お気軽にお話しくださいね!


qwen3:4b 359d7dd4bcda 2.5 GB 5 days ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3:4b 359d7dd4bcda 4.1 GB 42%/58% CPU/GPU 8192 4 minutes from now

●応答までの時間 2分20秒 (プロセス起動まで22秒 思考時間119.6秒)

●応答内容
こんにちは!私は通義実験室が開発した大規模言語モデル「Qwen(通義千問)」です。得意なこととしては、多言語対応、質問への回答、物語やメール・スクリプトの執筆、論理的推論、プログラミング、意見の表現、ゲームのプレイなどがあります。何かお手伝いが必要でしたら、いつでもお気軽にお知らせください!

llama3.2:1b baf6a787fdff 1.3 GB 45 hours ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL

●応答までの時間 36秒 (プロセス起動まで 36秒? 思考時間 ?秒)

●応答内容
こんにちは!私はAI-poweredのトピックを教えることができます。このようなアプリケーションでは、質問に答え、情報を提供するなど、さまざまな機能を可能にします。

また、このアプリケーションでは、問題に対する推論や分析を行うこともできます。これにより、より正確で効果的な回答が得られます。


llama3.2:3b a80c4f17acd5 2.0 GB 6 days ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
llama3.2:3b a80c4f17acd5 3.4 GB 29%/71% CPU/GPU 8192 4 minutes from now

●応答までの時間 1分9秒(プロセス起動まで 52秒 思考時間 17?秒)

●応答内容
こんにちは!私はAIコミュニケーションモデルです。私には多くの事を知っていますが、具体的には以下のようなことを得意とします。

1. **質問の答え**: 私に質問が来ると、回答を提供することができます。
2. **情報提供**: 私はさまざまなトピックについての情報を提供することができます。自然言語で説明しやすいようにします。
3. **文書作成**: 私は文章を作成して、レポート、 ईメール、または other の文書を作成できます。
4. **翻訳**: 私は多くの言語の間の翻訳を行うことができます。
5. **コミュニケーション:** 私は人々と交流するために使用できるように設計されています。私には口調、言語、スタイルを変えることができます。

私が得意ではないことは以下に書いてあります。

1. **感情的サポート:** 私は感情的なサポートを行うことができませんが、感情のトピックについて話すときに役立つ情報を提供することができます。
2. **創造性:** 私は想像力とクリエイティブさなどの創造性的な側面では限界がありますが、アイデアや原案を提案することができます。

私には多くの能力がありますが、私が得意なことはどのようなものかを調べると便利です。



gemma4:latest c6eb396dbd59 9.6 GB 6 days ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL

●応答までの時間(プロセス起動まで 秒 思考時間 秒)

●応答内容
Error
500 Internal Server Error: llama-server process has terminated: exit status 0xc0000409: The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.: GGML_ASSERT(n_inputs < GGML_SCHED_MAX_SPLIT_INPUTS) f


gemma4:12b 4eb23ef187e2 7.6 GB 6 days ago

●ps
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma4:12b 4eb23ef187e2 8.9 GB 75%/25% CPU/GPU 8192 4 minutes from now

●応答までの時間 5分4秒(プロセス起動まで 61秒 思考時間 122.8秒)

●応答内容
こんにちは!私はGoogleによってトレーニングされた、大規模言語モデルです。

私が得意なことやお手伝いできることは多岐にわたります。具体的には以下のようなことが得意です。

### 1. **情報の提供と解説**
どんな質問にもお答えします。歴史、科学、技術、文化など、幅広い分野の知識を分かりやすく解説します。
* 例:「量子コンピュータについて教えて」「美味しいカレーの作り方を教えて」

### 2. **文章の作成・編集**
目的に合わせた文章を作成します。
* **ビジネス:** メール、報告書、企画書のドラフト作成
* **クリエイティブ:** 小説、詩、脚本の執筆
* **SNS・ブログ:** キャッチコピーの考案、記事の構成案
* **校正:** 文章の誤字脱字チェックや、より自然な表現への書き換え

### 3. **翻訳と言語学習**
多言語に対応しており、高い精度の翻訳や、外国語の学習サポートができます。
* 日本語から英語、中国語、スペイン語などへの翻訳
* 外国語での会話練習や文法の解説

### 4. **プログラミングと技術的な相談**
コードを書いたり、バグを見つけたり、技術的な仕組みを説明したりします。
* Python, JavaScript, C++, SQLなど多くの言語に対応
* エラーの原因分析や、効率的なアルゴリズムの提案

### 5. **要約と情報の整理**
長い文章を短くまとめたり、複雑な情報を構造化して整理したりします。
* ニュース記事の要約
* 会議の議事録から重要なポイントを抽出
* 箇条書きでのリスト作成

---

**「これってできる?」と思ったら、まずは気軽に話しかけてみてください。**
あなたのアイデアを形にするお手伝いや、日常のちょっとした疑問の解決など、何でもサポートします!

モデルごとに特徴がありますね、GPUかRAM不足かチューニングの問題で、gemma4:latestは動きませんでしたが、応答速度を気にしなければ使えなくはないようです。

関連時期

https://docs.ollama.com/windows

ローカルLLMは、ここまで来た、2026年夏版

「生成AIを使うには、高性能GPUや高価なクラウドサービスが必要。」

そんなイメージを持っている方も多いのではないでしょうか。

しかし、2026年の今、その常識は大きく変わり始めています。

近年は Ollama をはじめとするツールの普及により、インターネットに接続しなくても、自分のパソコンだけで生成AIを動かせる環境が急速に整ってきました。さらに、Qwen、Gemma、Llamaなど高性能なオープンモデルの進化によって、一般的なパソコンでも十分に実用的なAI体験ができるようになっています。

「生成AIを使うには、高性能GPUや高価なクラウドサービスが必要。」

そんなイメージを持っている方も多いのではないでしょうか。

しかし、2026年の今、その常識は大きく変わり始めています。

LLMとは?

**LLM(Large Language Model:大規模言語モデル)**とは、大量の文章データを学習し、人間が書いたような自然な文章を生成したり、質問に答えたりできるAIモデルです。

ChatGPTやGemini、ClaudeなどもLLMの一種であり、文章作成、翻訳、プログラミング、要約、アイデア出しなど幅広い用途に利用されています。

一方、これらの多くはクラウド上で動作しますが、Ollamaを利用するとLLMを自分のパソコン上で実行できます。そのため、インターネット接続がなくても利用でき、入力したデータを外部へ送信せずにAIを活用できる点が大きな特徴です。

近年は Ollama をはじめとするツールの普及により、インターネットに接続しなくても、自分のパソコンだけで生成AIを動かせる環境が急速に整ってきました。さらに、Qwen、Gemma、Llamaなど高性能なオープンモデルの進化によって、一般的なパソコンでも十分に実用的なAI体験ができるようになっています。

もちろん、最高性能を求めるならハイエンドGPUを搭載したPCが有利です。しかし、「AIを使ってみたい」「文章作成やプログラミングを手伝ってほしい」「プライバシーを重視したい」といった用途であれば、以前のような数十万円クラスの専用マシンが必須という時代ではなくなりました。

本記事では、2026年夏時点におけるローカル生成AIの最新状況を整理し、

  • なぜ今、ローカル環境で生成AIを動かす人が増えているのか
  • どの程度のパソコンなら快適に動作するのか
  • 現在おすすめできるモデルにはどのようなものがあるのか
  • ローカル環境ならではのメリットと注意点

といったポイントを、初心者にも分かりやすく解説します。

「ローカル生成AIは、もう一部のマニアだけのものではありません。」

そんな時代の到来を、ぜひ一緒に見ていきましょう。


とりあえずOllamaをいれて、いろいろ試してみよう。 セッション制限で、止まっている間に実験的に試してみよう。

とりあえずインストールしたモデル

> ollama list
NAME ID SIZE MODIFIED
qwen3.6:latest 07d35212591f 23 GB 16 hours ago
llama3.2:1b baf6a787fdff 1.3 GB 25 hours ago
qwen2.5:1.5b 65ec06548149 986 MB 4 days ago
qwen3:4b 359d7dd4bcda 2.5 GB 5 days ago
llama3.2:3b a80c4f17acd5 2.0 GB 5 days ago
gemma4:latest c6eb396dbd59 9.6 GB 5 days ago
gemma4:12b 4eb23ef187e2 7.6 GB 5 days ago

Ollamaを起動してみる (Cluade Desktopとほぼ同じ画面が起動する)

Ollamaが起動していることを、ターミナル(PowerShell / コマンドプロンプト / ターミナル)から確認する。 ローカルからAPI呼び出しできるように開いている

> curl http://localhost:11434/api/tags


StatusCode : 200
StatusDescription : OK
Content : {"models":[{"name":"qwen2.5:1.5b","model":"qwen2.5:1.5b","modified_at":"2026-07-31T06:50:29.9876605
+09:00","size":986061892,"digest":"65ec06548149b04c096a120e4a6da9d4017ea809c91734ea5631e89f96ddc57b
",...
RawContent : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Date: Fri, 31 Jul 2026 01:13:21 GMT

{"models":[{"name":"qwen2.5:1.5b","model":"qwen2.5:1.5b","modified_at...
Forms : {}
Headers : {[Transfer-Encoding, chunked], [Content-Type, application/json; charset=utf-8], [Date, Fri, 31 Jul
2026 01:13:21 GMT]}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 2932

モデルを起動しておく

> ollama run qwen2.5:1.5b
>>> Send a message (/? for help)

↑ 起動すると、プロンプト画面となる。 Claude codeとほぼ同じ感じ

この起動状態でリクエストすればモデル起動時間を飛ばして応答が早くなる。次の形式でよびだせる。★ただしプロンプト入力がなければ、4分ほどでプロセスが終了する。

> curl.exe -X POST http://localhost:11434/api/generate -H "Content-Type: application/json" -d "@test.json"

あらかじめ test.jsonファイルを用意しておく

{
"model": "qwen2.5:1.5b",
"prompt": "こんにちは。自己紹介して。",
"stream": false
}

WebAPIを叩くと、LLMから返事が返ってくる。

> curl.exe -X POST http://localhost:11434/api/generate -H "Content-Type: application/json" -d "@test.json"
{"model":"qwen2.5:1.5b","created_at":"2026-07-31T01:17:42.1473736Z","response":"こんにちは、お話しします。私の名前はQwenです。人工知能の技術を活用して情報を提供したり、コンテキストで質問に答えたりすることができます。何か困っていることがあれば、お気軽にお手伝いできると思いますよ。","done":true,"done_reason":"stop","context":[151644,8948,198,2610,525,1207,16948,11,3465,553,54364,14817,13,1446,525,264,10950,17847,13,151645,198,151644,872,198,89015,1773,99283,26771,117,74810,38826,1773,151645,198,151644,77091,198,89015,5373,32234,136276,77334,1773,129879,13072,24562,15322,48,16948,37541,1773,102249,52183,26232,15767,107502,29412,75606,11622,38826,134482,99553,130720,5373,125574,56833,61803,70534,16161,101504,98297,19655,136885,125212,140163,1773,130967,99629,124777,124186,29491,124409,5373,32234,140357,125882,44934,132322,16586,126241,126264,56880,1773],"total_duration":4338688500,"load_duration":2867092300,"prompt_eval_count":37,"prompt_eval_duration":76950000,"eval_count":57,"eval_duration":1391175000}

これさえできればいろいろできそう。

関連記事

https://docs.ollama.com

AI謎解きプロジェクト|AIは本当に謎を解けるのか?人間との知能実験を開始

人間とAIが、同じ条件で挑む知能実験を始めます。

AI謎解きプロジェクトは、AIが本当に文章だけで謎を解けるのかを検証する長期実験です。
AIは、驚くほどの速度で進化しています。

文章を書き、プログラムを作成し、画像を生成し、Web検索や外部ツールまで自在に扱えるAIも登場しました。

しかし、私たちは一つの疑問を持っています。

「AIは、本当に”考えて”いるのでしょうか。」

知識を検索できることと、自ら考え抜くことは同じではありません。

そこで私たちは、この疑問に真正面から挑むため、新しいプロジェクトを開始します。

それが 「AI謎解きプロジェクト」 です。


このプロジェクトが目指すもの

私たちが目指すのは、単なる謎解きイベントではありません。

人間とAIが同じ条件で挑戦し、その思考力を継続的に記録・比較する実験プロジェクトです。

AIは数か月で大きく進化します。

今日解けなかった問題を、半年後には数分で解いてしまうかもしれません。

逆に、人間なら自然に気付けることを、AIはいつまでも見落とし続ける可能性もあります。

だからこそ、一度きりの勝負では意味がありません。

同じ思想で問題を公開し続け、人間とAIの能力変化を記録していきます。


なぜ「文章だけ」の謎解きなのか

このプロジェクトで扱う問題は、基本的に文章だけで構成します。

画像の細かな観察力や、手作業による操作、音声認識といった能力は評価対象にしません。

必要なのは、

  • 読む力
  • 理解する力
  • 仮説を立てる力
  • 論理的に推論する力
  • 間違いを修正しながら最後まで考え抜く力

です。

つまり、

「読む・考える・解く」

という純粋な知的能力を測ることが、このプロジェクトの目的です。


人間とAIを公平に比較するために

AIに不利な問題を作るつもりはありません。

もちろん、人間にだけ有利な問題を作るつもりもありません。

重要なのは、

誰が解くのかではなく、誰が最後まで到達できるのか。

という一点です。

問題は、人間にもAIにも同じ条件で公開します。

その上で、

  • 到達できたか
  • どれだけ時間がかかったか

を基本指標として比較していきます。


4つの参加カテゴリ

このプロジェクトでは、参加者を4つのカテゴリに分けます。

① 人間のみ

AIを一切使わず、人間だけで挑戦します。

人間の基準となる重要なカテゴリです。


② 人間+AI

人間が主体となり、AIを補助ツールとして利用します。

AIを「どれだけ上手に使いこなせるか」も能力の一部として評価します。


③ AI+人間

AIが主体となって考え、人間は最低限の補助だけを行います。

例えば、

  • AIでは入力できない作業
  • AIでは参照できない資料
  • 必要最小限の操作

など、人間は「手足」としてのみ介入します。

AIの自律性を測るためのカテゴリです。


④ AIのみ

このカテゴリが、本プロジェクト最大の挑戦です。

AIに渡されるのは、スタート地点だけ。

そこから先は、

  • Web検索
  • ブラウザ操作
  • Python
  • MCP
  • 外部ツール

など、必要だと判断したものは自由に利用できます。

制限は設けません。

むしろ、それらを使いこなせなければ解けない問題も積極的に取り入れていきます。

AIは、

どの情報を集め、

どのツールを選び、

どの仮説を採用し、

いつ間違いに気付き、

どのように修正しながら答えへ到達するのか。

その過程そのものが、この実験の観測対象です。


AIはどこまで自律できるのか

現在のAIは非常に高性能です。

しかし、長い推論を続けること、誤りを自ら修正すること、複数の仮説を管理しながら探索を続けることは、まだ得意とは言えません。

私たちは複数のAIで試験を重ねていますが、現時点では人間の介助なしに最後まで安定して到達できるAIは、ごく限られるという印象を持っています。

もちろん、これは現在の話です。

数か月後には、まったく違う結果になっている可能性も十分あります。

だからこそ、このプロジェクトは継続開催します。


AIの進化を記録する

AIは毎月のように新しいモデルが登場します。

ChatGPT

Claude

Gemini

Grok

Copilot

ローカルLLM

これらすべてが比較対象になります。

今年解けなかったAIが、

来年には最速記録を更新するかもしれません。

私たちは、その変化を継続して記録していきます。


人間の参加者も募集します

もちろん、この実験の主役はAIだけではありません。

人間が解けなければ、公平な比較は成立しません。

参加は

  • 一人でも
  • チームでも

自由です。

謎解きが好きな方

AIに興味がある方

人間の思考力に挑戦したい方

そして、

「AIなんかにはまだ負けない。」

そう思っている方の挑戦も、お待ちしています。


これは、AIが人間を超える瞬間を記録するプロジェクトかもしれない。

私たちは、AIが必ず人間を超えるとは考えていません。

しかし、その可能性を否定もしません。

もし、AIが人間を安定して上回る日が来るなら。

それは単なる性能向上ではありません。

「思考」という領域で、人間と肩を並べた瞬間なのかもしれません。

その歴史的な変化を、同じルール、同じ思想、同じ条件で記録し続ける。

それが、この AI謎解きプロジェクト の使命です。


あなたも、この実験の目撃者になりませんか。

このプロジェクトは、一度限りでは終わりません。

問題は継続的に公開し、人間とAIの挑戦記録を積み重ねていきます。

参加方法やルールの詳細は、順次公開予定です。

まずは、このプロジェクトに興味を持っていただけたら幸いです。

AIは、本当に考えて謎を解けるのか。

その答えは、まだ誰にも分かりません。

だからこそ、私たちは挑戦を始めます。人間とAIが、同じ条件で挑む知能実験を始めます。

AI謎解きプロジェクトは、AIが本当に文章だけで謎を解けるのかを検証する長期実験です。
AIは、驚くほどの速度で進化しています。

文章を書き、プログラムを作成し、画像を生成し、Web検索や外部ツールまで自在に扱えるAIも登場しました。

しかし、私たちは一つの疑問を持っています。

「AIは、本当に”考えて”いるのでしょうか。」

知識を検索できることと、自ら考え抜くことは同じではありません。

そこで私たちは、この疑問に真正面から挑むため、新しいプロジェクトを開始します。

それが 「AI謎解きプロジェクト」 です。


このプロジェクトが目指すもの

私たちが目指すのは、単なる謎解きイベントではありません。

人間とAIが同じ条件で挑戦し、その思考力を継続的に記録・比較する実験プロジェクトです。

AIは数か月で大きく進化します。

今日解けなかった問題を、半年後には数分で解いてしまうかもしれません。

逆に、人間なら自然に気付けることを、AIはいつまでも見落とし続ける可能性もあります。

だからこそ、一度きりの勝負では意味がありません。

同じ思想で問題を公開し続け、人間とAIの能力変化を記録していきます。


なぜ「文章だけ」の謎解きなのか

このプロジェクトで扱う問題は、基本的に文章だけで構成します。

画像の細かな観察力や、手作業による操作、音声認識といった能力は評価対象にしません。

必要なのは、

  • 読む力
  • 理解する力
  • 仮説を立てる力
  • 論理的に推論する力
  • 間違いを修正しながら最後まで考え抜く力

です。

つまり、

「読む・考える・解く」

という純粋な知的能力を測ることが、このプロジェクトの目的です。


人間とAIを公平に比較するために

AIに不利な問題を作るつもりはありません。

もちろん、人間にだけ有利な問題を作るつもりもありません。

重要なのは、

誰が解くのかではなく、誰が最後まで到達できるのか。

という一点です。

問題は、人間にもAIにも同じ条件で公開します。

その上で、

  • 到達できたか
  • どれだけ時間がかかったか

を基本指標として比較していきます。


4つの参加カテゴリ

このプロジェクトでは、参加者を4つのカテゴリに分けます。

① 人間のみ

AIを一切使わず、人間だけで挑戦します。

人間の基準となる重要なカテゴリです。


② 人間+AI

人間が主体となり、AIを補助ツールとして利用します。

AIを「どれだけ上手に使いこなせるか」も能力の一部として評価します。


③ AI+人間

AIが主体となって考え、人間は最低限の補助だけを行います。

例えば、

  • AIでは入力できない作業
  • AIでは参照できない資料
  • 必要最小限の操作

など、人間は「手足」としてのみ介入します。

AIの自律性を測るためのカテゴリです。


④ AIのみ

このカテゴリが、本プロジェクト最大の挑戦です。

AIに渡されるのは、スタート地点だけ。

そこから先は、

  • Web検索
  • ブラウザ操作
  • Python
  • MCP
  • 外部ツール

など、必要だと判断したものは自由に利用できます。

制限は設けません。

むしろ、それらを使いこなせなければ解けない問題も積極的に取り入れていきます。

AIは、

どの情報を集め、

どのツールを選び、

どの仮説を採用し、

いつ間違いに気付き、

どのように修正しながら答えへ到達するのか。

その過程そのものが、この実験の観測対象です。


AIはどこまで自律できるのか

現在のAIは非常に高性能です。

しかし、長い推論を続けること、誤りを自ら修正すること、複数の仮説を管理しながら探索を続けることは、まだ得意とは言えません。

私たちは複数のAIで試験を重ねていますが、現時点では人間の介助なしに最後まで安定して到達できるAIは、ごく限られるという印象を持っています。

もちろん、これは現在の話です。

数か月後には、まったく違う結果になっている可能性も十分あります。

だからこそ、このプロジェクトは継続開催します。


AIの進化を記録する

AIは毎月のように新しいモデルが登場します。

ChatGPT

Claude

Gemini

Grok

Copilot

ローカルLLM

これらすべてが比較対象になります。

今年解けなかったAIが、

来年には最速記録を更新するかもしれません。

私たちは、その変化を継続して記録していきます。


人間の参加者も募集します

もちろん、この実験の主役はAIだけではありません。

人間が解けなければ、公平な比較は成立しません。

参加は

  • 一人でも
  • チームでも

自由です。

謎解きが好きな方

AIに興味がある方

人間の思考力に挑戦したい方

そして、

「AIなんかにはまだ負けない。」

そう思っている方の挑戦も、お待ちしています。


これは、AIが人間を超える瞬間を記録するプロジェクトかもしれない。

私たちは、AIが必ず人間を超えるとは考えていません。

しかし、その可能性を否定もしません。

もし、AIが人間を安定して上回る日が来るなら。

それは単なる性能向上ではありません。

「思考」という領域で、人間と肩を並べた瞬間なのかもしれません。

その歴史的な変化を、同じルール、同じ思想、同じ条件で記録し続ける。

それが、この AI謎解きプロジェクト の使命です。


あなたも、この実験の目撃者になりませんか。

このプロジェクトは、一度限りでは終わりません。

問題は継続的に公開し、人間とAIの挑戦記録を積み重ねていきます。

参加方法やルールの詳細は、順次公開予定です。

まずは、このプロジェクトに興味を持っていただけたら幸いです。

AIは、本当に考えて謎を解けるのか。

その答えは、まだ誰にも分かりません。

だからこそ、私たちは挑戦を始めます。

公開予定について

入り口は、2026/8/12に第一弾を公開公開予定です。 その前(2026/8/5)に、コラボ先のサイトにて練習問題が公開される予定です。誰でも挑戦できるので、参加してください。 なお、ゴールできたら、その証として是非その証拠にコメントなどを残していってください。 


謎解き問題 入り口

・関連:2026/8/5 昼頃 公開予定; → hoscm X https://x.com/hoscm2025
・第一弾:2026/8/12公開予定; → 8/12アナウンスおよびリンク追加予定です
・第二弾:2026/8/19公開予定; → 準備中です 


関連記事

参考リンク

ローカルLLM時代への準備検討を開始する ― Ollama+Gemma 4+MCPで2027年に備える

ローカルLLMを本気で検討すべき時期に入ってきた。クラウドAIの技術解放が一段落し、知名度が上がるにつれて、各サービスは投資フェーズから回収フェーズへ舵を切りつつある。実験的に触っていた頃は気にならなかった「使い方」と「コスト」が、いまは真正面から課題として立ち上がってきた。先行する各AIの選別・選択が進むこの時期に、選択肢のひとつとしてローカルLLMをどこまで実務へ組み込めるのか。2027年を見据えた検討を、ここから始める。

この記事の結論(2026年7月時点の現在地)

  • ローカルLLM単体では「AIに作業を任せる」構成にはならない。OllamaはMCPを話さないため、両者を仲介するクライアントが必須になる。
  • 推論エンジンの第一候補はGemma 4(2026年4月2日公開・Apache 2.0)。E4B変種ならVRAM 8GBクラスから動く。
  • クライアント側の情勢は動いた。Roo Codeは2026年5月15日に終了しており、いま選ぶなら本線はCline。
  • 検証すべきは「生成速度」ではなく「エージェントループが完走するか」。ここが未検証のため、本記事は検討段階の記録として置く。

なぜ2027年に向けてローカルLLMを検討するのか

動機は「クラウドAIをやめたいから」ではない。むしろ逆で、クラウドAIを使い続けるために、降ろせる作業を切り分けたいという発想である。検討の軸は四つに整理できる。

  • コスト構造:クラウドAIは従量課金で、使うほど比例して増える。ローカルLLMはGPUの初期投資と電力に置き換わり、使用量が増えても単価が上がらない。
  • 機密性:社外に出しにくいソースコードや顧客データを扱う作業は、そもそも外部APIに投げる前提を置きたくない。
  • 可用性:API障害、レート制限、モデルの世代交代による挙動変化。手元で完結する経路をひとつ持っておく意味は大きい。
  • 役割分担:ローカルLLMは全面置き換えではなく「下ごしらえ担当」として見る。整形・分類・一次調査・定型コードの叩き台までをローカルで済ませ、判断を要する部分をクラウドに残す。

ローカルLLMを実務に組み込む3層アーキテクチャ

「ローカルのOllamaでモデルを動かしながら、MCP経由でAndroid StudioやPython環境などのローカルシステムを操作する」という構成は、次の3層に分解できる。

役割候補
推論エンジン(脳)プロンプトを解釈し、次の一手を決めるOllama上のGemma 4
クライアント(司令塔)モデルとツールを仲介し、ループを回すCline などMCP対応クライアント
MCPサーバー(手足)ファイル読み書き・コマンド実行filesystem / shell(terminal)

最初に押さえる前提 ― OllamaはMCPを話さない

ここを誤解すると設計を丸ごとやり直すことになる。Ollamaが提供するのは、OpenAI互換のエンドポイント(http://localhost:11434/v1)と、Ollama独自形式のツール呼び出し(tool_calls)である。これはMCP準拠ではない。したがって「OllamaにMCPを設定する」という操作は存在しない。

MCPサーバーを使うには、(1) MCPクライアント機能を持つツール(Cline、Continue.dev、LM Studio、Goose など)をOllamaに向けるか、(2) MCPHostやollama-mcp-bridgeのような変換ブリッジを挟むか、のどちらかになる。ローカルLLMを「手足付き」で動かす設計は、この仲介層をどう置くかで決まる。


推論エンジンの候補:Gemma 4

Gemma 4は2026年4月2日にApache 2.0で公開された、Google DeepMindの第4世代オープンウェイトモデルである。Gemini 3と同系の研究成果から蒸留されており、ローカルLLM用途としては現時点で扱いやすい選択肢に入る。

  • 変種はE2B・E4B(実効2B/4B、コンテキスト128K)と、26B MoE・31B Dense(コンテキスト256K)。
  • Ollamaは0.22以降が必要。ollama pull gemma4 で既定のE4B(約9.6GB)が取得できる。
  • 2026年5月5日に投入されたMulti-Token Prediction(投機的デコード)により、デコード側スループットは最大3倍程度まで伸びるとされる。

VRAMの目安

モデル量子化VRAM目安位置づけ
E4BQ48GB〜常用。整形・要約・軽い編集
26B MoE(A4B)Q416GB前後長文コンテキスト重視
31B DenseQ418〜20GB精度重視。24GB級GPU向け
31B DenseBF16約64GB実質サーバー用途

出発点はQ4_K_Mでよい。加えて、コンテキストウィンドウ(KVキャッシュ)用にVRAMを2〜4GB空けておくこと。ローカルLLMで詰まる原因は、モデルが載らないことより、長い会話でKVキャッシュが膨らんで落ちることのほうが多い。


クライアント選定 ― 2026年前半に前提が変わった

ここが今回の検討で最も更新が必要だった箇所である。ネット上の解説記事は「Cline と Roo Code の二択」で書かれたものが多いが、その前提はすでに崩れている。

  • Roo Codeは2026年4月21日に終了を発表し、2026年5月15日にVS Code拡張のサービスを終了した。Roo Code CloudとRouterも停止し、リポジトリは読み取り専用でアーカイブされている。
  • 理由は技術的な行き詰まりではなく方針転換で、「IDEはコーディングの未来ではない」としてクラウドエージェントへ軸足を移した。
  • コミュニティフォークとしてZoo Code、Kilo Codeが後を継いでおり、移行先として案内されたのがClineである。

つまり、いまからローカルLLM+MCPの環境を組むなら、まずCline一本で考えるのが合理的である。フォーク系は、動く構成が固まってから比較対象に加えればよい。

項目ClineZoo Code / Kilo CodeClaude Desktop
状態現行・開発継続Roo Code終了後のコミュニティ継続現行
MCP対応標準対応対応(本家仕様を継承)標準対応
Ollama接続API Providerとして選択可選択可直接は非対応(ブリッジが必要)
向く用途開発ループの自動化Roo流モード運用の継承汎用のMCP作業
情報量多い少ない(移行期)多い

MCPサーバーは2つあれば足りる

Python実行とAndroidプロジェクト操作を目的にするなら、必要な「手足」は2種類だけである。ファイルを読み書きするfilesystem系と、コマンドを実行するshell(terminal)系。多くのMCPサーバーはバックグラウンドでNode.jsまたはPythonを動かすため、Node.jsのLTS版とPythonの安定版を先に入れておく。

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:/Users/<ユーザー名>/Projects/AndroidApp_Project"
      ]
    }
  }
}

filesystemに渡すパスは、最初はプロジェクト1フォルダだけに絞る。許可範囲を広げるのは、ループが安定して回ることを確認してからでよい。コマンド実行系はクライアント側の機能として持っている場合があるため、Clineの設定を確認したうえで、足りなければ別途MCPサーバーを追加する。

想定している開発ループ

Android Studioのボタンを直接押させるわけではない。狙いは開発工程そのものを任せることで、流れは次のようになる。

  1. 指示を出す。例:「ログイン画面にバリデーションを追加し、gradleビルドが通るまで修正を繰り返すこと」。
  2. Gemma 4がプロンプトを解析し、ファイルを読む必要があると判断してfilesystem MCPの利用を要求する。
  3. クライアントが実際にファイルを読み、内容をモデルへ戻す。
  4. モデルが修正内容を出力し、クライアントが書き込む。
  5. クライアントが python run_test.pygradlew assembleDebug をターミナルで実行する。
  6. エラーが出ればログを読み取り、2に戻る。通れば完了。

クラウドAIでは当たり前に回るこのループが、ローカルLLMでどこまで完走するか。それが今回の検討の核心である。


ローカルLLMのコストをどう見るか

「月額いくら浮くか」で判断すると、たいてい見誤る。比較すべき項目を並べておく。

  • 初期投資:VRAM 16GB級で常用ラインに入り、24GB級で選択肢が広がる。ここが最大の固定費。
  • 電力:推論中は継続的に消費する。長時間のエージェントループを回すなら無視できない。
  • 時間コスト:ローカルLLMは生成が遅く、失敗によるやり直しも増える。人間の待ち時間は隠れコストになる。
  • 自律性の閾値:エージェントループはローカルモデルにとって最も厳しい負荷である。一定規模(20B台後半クラス+24GB前後のVRAM)を超えないと安定しにくい、という見方が一般的になってきている。

結論として現実解は併用になる。定型作業と機密性の高い処理をローカルLLMへ降ろし、判断と設計はクラウドAIに残す。この線引きを決めるための材料集めが、いまの段階の目的である。

動作検証の計画

公開前に通す検証項目を、順序つきで固定しておく。

  1. Ollama 0.22以降を導入し、ollama pull gemma4 が完了すること。
  2. ollama run gemma4 で日本語の応答品質と体感速度を確認すること。
  3. 500エラー発生で →  irm https://ollama.com/install.ps1 | iex
  4. 環境変数を正しく設定してOllamaを完全に再起動する → Get-Process | Where-Object {$_.ProcessName -like “ollama“} | Stop-Process -Force
    → これでもだめなら、GPU 起因かも 4GB VRAMなら ollama run llama3.2:3b  → これで起動した・
  5. VS Code+Clineで、API Providerを Ollama、Model IDを gemma4 として接続が通ること。← VRAMが多量にあれば
  6. filesystem MCPを1フォルダだけ許可し、読み取りが成立すること。
    → Windowsでは、
MCP設定ファイルの起動:ollama runのラムボンランナーから、MCP設定ファイルを直接起動します。
PSコマンドで > ollama run llama3.2:3b


VS Codeをインストールする
公式サイト:https://code.visualstudio.com/
VS Codeを開いて
Ctrl + Shift + X を押す
検索欄で Cline  入れて Installをクリックする

ollama pull qwen3-coder × 18GBもある 
ollama pull qwen3:4b ◎  ←  これもだめそう 8GBくらい必要そう
> ollama pull qwen2.5:1.5b

左のClineアイコンをクリックし開き 「Bring my own API Key」APIでcontinueを押し Providerを Ol←

JDKのアップデート: ollama runのラムボンランナーは、オリジナルのLlamaと互換性がないように設計されています。つまり、古いバージョンのJDKを使用することはできません。 recentなバージョンのJDK を使用してください。
llamapの置き換え: ollama runは、Java program のコンパイルとリンキングを扱うためのコマンド llamap を提供しますが、これも modernな Java version では使用できません。代わりに javac コマンドを使用する必要があります。
JDKの設定ファイルの検索: cp オプションは古いバージョンの JDK にあり、modern な JDK に使用できないため、 modernな JDK では使用できません。代わりに -class-pathオプションまたは実際の JDK の lib directory を指定する必要があります。

  1. コマンド実行を経由して「実行 → エラー読み取り → 自己修正」のループが完走すること。
  2. 同じ課題をクラウドAIにも投げ、所要時間と成功率を並べて比較すること。

関門は5番である。ここを通過できた時点で、本記事を実測値つきで更新する。

まとめ ― 2027年に向けた現在位置

ローカルLLMは「安く済ませる手段」ではなく、「どの作業を手元に置くか」を決めるための道具である。2026年7月時点で、推論エンジン(Gemma 4)とクライアント(Cline)とMCPサーバー(filesystem/shell)という3層の見取り図は描けた。一方で、Roo Codeの終了のように前提が半年で入れ替わる領域でもある。だからこそ構成を固定するより、検証手順を先に固めておくほうが実務では効く。ローカルLLMの検討は、ここから実機での確認フェーズに入る。

関連記事

参考リンク

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 等)には絶対にアクセスしないでください。

HDD価格高騰の正体は、AI需要!? ── 4か月待った交換ドライブ到着記

前回、故障したNAS(LS210D)の交換用HDDとして、SeagateのIronWolf「ST4000VN006」(4TB・CMR・NAS向け)を選んだところまで書いた。記事の最後はこう締めくくっていた──「次回は、購入したHDDを使ってNAS復活に挑戦です」と。

その「次回」が、ようやく書ける。

ただし、NAS本体の復活作業はもう一度先送りさせてほしい。理由は単純で、発注したHDDが届くまでに、4か月かかったからだ。 発注は2026年2月23日。到着は6月23日。きっかり4か月、入荷待ちが続いた。今回はまず、この「待たされた4か月」そのものを記録に残しておきたい。HDDという、ふだんは「ポチればすぐ届くもの」が、なぜこれほど待たされたのか。そして、2月に値段を確定して発注しておいた判断は、正解だったのか。


届いたもの ── 伝票とドライブ

まず、到着した実物から。

2026年2月に発注し6月に到着したST4000VN006の到着時の様子
2月発注・6月到着。4か月待った交換用ドライブがようやく届いた

伝票の日付がそのまま記録になっている。発注 2026年2月23日 → 到着 2026年6月23日。 購入金額は21,980円(税込)。発注時点でこの価格は確定していた。

購入したSeagate IronWolf ST4000VN006 4TB NAS用HDDの本体
届いたST4000VN006。ラベルの製造日は「06JUN2026」

そして届いたST4000VN006本体。静電防止袋越しの一枚だが、ラベルの「Date(製造日)」を見て、思わず二度見した。表記は「06JUN2026」。製造日は2026年6月6日。 発注したのが2月、製造されたのが6月初旬、手元に届いたのが6月23日。つまりこのドライブは、私が注文してから3か月以上あとに作られた個体ということになる。倉庫で在庫が眠っていたのを待っていたのではなく、どうやら「作られるのを待っていた」可能性が高い。この点は後でもう一度触れる。

ちなみに、今回壊れて交換対象になった旧ドライブ(ST4000DM005)のラベルを見ると、製造日は「27APR2022」。2022年4月製だ。約4年動いて力尽きた個体を、2026年6月製の新品で置き換えることになる。

(余談だが、製造日「06JUN2026」=2026年6月6日というのは、少し気になる並びでもある。西洋では「666」が新約聖書『ヨハネの黙示録』に登場する「獣の数字」とされ、悪魔・反キリストを象徴する不吉な数として避けられてきた。6が三つ並ぶ6月6日は「恐怖の日」とも呼ばれ、映画『オーメン』などでも知られる。日本ではあまり馴染みのない忌み数だが、もしこのドライブを作ったタイの工場にキリスト教徒の従業員がいたら、出荷日のラベルを見て少し身構えたかもしれない──というのは、さすがに考えすぎだろう。データの保全に、語呂も縁起も関係ない。)


価格は、どう動いていたのか ── 価格.comの実データ

「待っている間に値段がどうなったか」を、体感ではなく実データで見ておきたい。価格.comのST4000VN006 価格推移グラフは、期間を1年・2年に切り替えると長期の推移も追える。これを踏まえて数字を並べると、いくつもの発見があった。

まず、長いスパンで見たときのベースの底上げ。

時点価格.com価格
2022年8月(初値)14,979円
2026年2月23日(発注日・平均)25,253円
私の発注価格(2/23・確定)21,980円

このドライブの登録初値は14,979円。それが私の発注した2026年2月23日には平均25,253円まで上がっていた。2年半ほどで、ベースの価格が1.7倍近くになっている。 そして注目したいのは、私が確保した21,980円が、その2/23時点の平均25,253円よりも3,000円以上安かったこと。安い店を選んで発注した判断は、この時点ですでに効いていた。

次に、到着前後(5月下旬〜6月)の最安値の動き。

時期価格.com最安値(税込)
5月26日37,308円
5月29日38,090円
5月30日27,980円(前日から約1万円下落)
6月上旬29,980円前後
6月13日22,950円(一時的な下げ)
6月14日31,547円(翌日に約8,600円戻す)
6月18日32,980円
6月19日25,500円(約7,500円下落)
6月22〜24日(到着前後)24,980円

ここから二つのことが読み取れる。

ひとつは、私が2月に確保した21,980円という価格は、到着時の相場と比べても明確に安かったということ。到着した6月の最安値はおおむね2.5万〜3.3万円台で、5月下旬には3.8万円台に届いていた。発注時に値段を固定できたぶん、待っている間の値上がりを丸ごと回避できた格好だ。仮にいま同じものを買い直すなら、3,000〜1万6,000円ほど余計に払うことになる。

もうひとつは、価格が一日で7,000〜10,000円も上下していること。6月13日に22,950円まで下がったかと思えば、翌14日には31,547円へ跳ね上がる。これは需要が日替わりで動いているというより、「安値を出す店の在庫が出たり消えたりするたびに、最安ショップが入れ替わっている」動きに見える。薄い在庫を、複数の店が奪い合っている──そんな相場だ。

※価格は価格.comの掲載値(初値・平均・最安値)を参照。価格・在庫は常に変動するため、購入検討時は必ず最新の情報を確認してほしい。


なぜ高い ── 円安は「地ならし」、引き金は別にあった

HDDが高い、と聞くとまず「円安のせいだろう」と考えたくなる。輸入品である以上、円安が効いているのは間違いない。だが、価格.comの価格推移グラフを長期で眺めると、話はそう単純ではないことがわかる。価格推移グラフのページで表示期間を「1年」や「2年」に切り替えると、ここで述べる動きが自分の目で確認できるので、ぜひ実際のグラフと見比べてほしい。

長期グラフで決定的なのは、価格が動き出したタイミングだ。2025年7月から11月にかけて、最安値は17,000円前後でほぼ横ばい──むしろ秋口にはわずかに下げてさえいる。ところが2025年12月を境に、価格は急角度で上がり始める。 2026年に入って上昇は加速し、5月には平均45,000円超・最安値37,000円台のピークをつけ、6月にやや反落して現在に至る。

ここで為替を重ねてみる。円安はこの1年で急に始まったものではない。ドル円が150円を超える水準は2022年から続く長期トレンドで、2026年も年初に159円台をつけたあと、おおむね140〜160円のレンジで推移している。つまり、円安は2025年前半からずっと「効いていた」はずなのに、HDD価格が動き出したのは2025年末からだ。 もし円安が主因なら、価格は2025年前半から上がっていなければおかしい。だが実際には、横ばいの期間が半年以上続いたあと、為替とは無関係なタイミングで急騰が始まっている。

物価と為替は、しばしばずれて現れる。為替は輸入コストの「土台」を押し上げる地ならしではあっても、この急騰の引き金を引いたのは別の要因だ──そう考えるのが自然だろう。

ではその引き金は何か。報道で繰り返し指摘されているのは、生成AI向けのデータセンター需要である。HDDメーカーが利益率の高い大容量・データセンター向けの生産を優先し、結果として4TBクラスのような普及帯の供給が絞られた。Western Digitalは2026年生産分がほぼ完売で、上位クラウド事業者と2027〜2028年まで長期契約を結んでいると報じられている。日本経済新聞も、2026年4〜6月期のHDD大口取引価格が前四半期比で約1割上昇した背景として、中国のPC向け需要とデータセンター優先による品薄を挙げており、為替には触れていない。時期で見ても、AIデータセンター投資が過熱したのはまさに2025年後半から。価格が動き出した時期と、きれいに重なる。

ここで、冒頭の「製造日6月6日」が効いてくる。生産枠がデータセンター向けで埋まっている中では、一般向けの普及帯ドライブは「在庫から出てくる」のではなく「順番待ちで作られる」状況になりうる。私の個体が注文の3か月以上あとに製造されていたのは、まさにその順番待ちの結果だったのではないか──そう考えると、4か月の「入荷待ち」の正体に説明がつく。


この高値は、いつまで続くのか ── 二つの見方

では、この相場はいつまで続くのか。ここは断言を避けたい。見方が、はっきり二つに割れているからだ。

供給側から見れば、高止まりは当面続く。 メーカーの生産枠が2027〜2028年まで長期契約で埋まり、新しい生産ラインの立ち上げには年単位の時間がかかる。だから多くの分析は「2026年中に以前の安値へ戻ることは期待しにくく、緩和は早くて2027年以降」で一致している。この見方に立てば、いま高くても待つ意味は薄い。

だが需要側を見ると、雲行きが変わりつつある。 価格急騰を支えてきたAIデータセンター需要そのものに、調整の兆しが出始めているのだ。2026年に米国で完成予定だったデータセンターの約半数が遅延・中止に追い込まれ、マイクロソフトは計画容量の一部を延期したと報じられている。地域住民の反対運動も激化し、2026年1〜3月だけで総額20兆円規模のプロジェクトが停止・延期、ニューヨーク州議会は新規大規模データセンターの建設を一時停止する法案を可決した。AIの収益化が想定より遅れ、企業間の「勝ち負け」が見え始めているという指摘もある。

もし、過剰投資の調整が本格化し、撤退する企業の発注分が宙に浮けば、データセンター向けのHDD需要は想定より早く緩む可能性がある。そうなれば、普及帯に回ってくる供給も増え、価格が落ち着く展開もあり得る。「2027年まで高止まり」は供給側の論理であって、需要側が崩れれば前提ごと変わる。 どちらに転ぶかは、正直なところ読みきれない。

確実に言えるのは、この相場は「構造的に高い」のではなく、「AI需要という一本の柱に支えられて高い」ということだ。柱が太いままなら高値は続くし、柱が細れば崩れる。HDDの値段を、為替やインフレといった大きな話だけでなく、AI産業の浮き沈みという生々しい現実と結びつけて眺めておくと、買い時の判断材料になるかもしれない。


「他店ではすぐ買えた」という事実 ── 入荷待ちは店の問題でもある

ここは正直に書いておきたい。私が4か月待っている間も、もっと高い値段を出している他店では、在庫があってすぐ買えた。 価格.comでも、2月から6月を通じて在庫表示「△」ながら複数のショップが販売を続けていた。

つまり、市場全体でST4000VN006が完全に払底していたわけではない。「すぐ届く店は高く、安い店は入荷待ち」という、ごく当たり前の構図がそこにあっただけだ。私は安い店を選び、そのぶん時間を払った。供給が絞られた相場では、低価格で出てくるのは余剰のぶんだけで、それを安値で確保しようとすれば順番を待つことになる。価格と納期は、たいてい交換条件になる。


「すぐ欲しい」か「待てる」かで、買い方は変わる

この4か月で得た教訓を一つに絞るなら、HDDの買い方は「すぐ欲しいか/待てるか」で根本的に変わる、ということだ。

今回の私のNASは、前回書いたとおり、NAS全体で多重化しており、お金を払ってまで急いで復旧すべきデータはなかった。だから「待てる」側だった。納期を犠牲にして安い店を選び、結果として高騰相場の値上がりも乱高下も回避できた。これは「待てる」人にとっての最適解だったと思う。

逆に、いま現に運用中のストレージが壊れて、バックアップの空白を一日でも早く埋めたい──そういう「すぐ欲しい」状況なら、話はまったく違う。最安値を狙って入荷待ちに賭けるより、多少高くても即納の在庫を押さえるほうが、トータルでは正しい。相場が高止まりし、しかも日替わりで乱高下する局面では、「最安のタイミングを当てにいく」こと自体がリスクになる。先に見たとおり、この先の相場は供給側・需要側のどちらに転ぶか読みきれない。だからこそ「いつか下がるはず」と当てにして運用に穴を空けるより、自分の状況が「待てる」のか「待てない」のかを先に見極めるほうが、よほど確実だ。

ひとつ補足すると、HDD選びでは「すぐ欲しい/待てる」だけでなく、SMRかCMRか、容量単価はどうか、といった軸も絡んでくる。このあたりは前回で詳しく検討したので、そちらも参照してほしい。


余談:このドライブは「どこ製」なのか

最後に、ラベルを眺めていて気になった点を一つ。製造国の表記についてだ。

今回届いた個体のラベルには「Product of Thailand」とあった。タイで組み立てられたドライブ、というわけだ。面白いことに、今回壊れた交換前のドライブ(ST4000DM005)も、同じく「Product of Thailand」だった。製造日は4年違い、型番も製品系列も違うのに、組み立て地は同じタイ。Seagateにとってタイが主力の組み立て拠点であることがうかがえる。

ただ、この「Product of Thailand」を見て「このドライブはタイ製だ」と言い切るのは、実はかなり乱暴な話だ。ラベルが示しているのは、あくまで最終的な組み立て(アッセンブリ)を行った国にすぎない。

HDDは、プラッタ(ディスク)、磁気ヘッド、スピンドルモーター、サスペンション、制御基板、ファームウェア──と、無数の精密部品の集合体だ。そして、これらの中核部品を誰が作っているかは、公開されている事実である。たとえば磁気ヘッドはTDKが専業の世界トップメーカーで、記録媒体であるプラッタはレゾナック(旧昭和電工)やガラス基板のHOYA、プラッタを回すスピンドルモーターはニデック(日本電産)ミネベアミツミ、磁気ヘッドを支えるサスペンションはニッパツ(日本発条)やTDK──というように、部品ごとに供給メーカーがはっきり分かれており、その多くは日本企業だ。 Seagateのような完成品メーカーはヘッドやメディアを内製もするが、それでも供給安定のために外部からも調達するのが普通である。

だから「○○製だから良い/悪い」という見方は、HDDに関してはほとんど意味をなさない。ラベルの「Product of Thailand」は「タイで組まれた」ことを示すだけで、中身の部品は世界中──とりわけ日本──のメーカーから集められている。組み立て地はラベルで分かっても、中身がどこの何でできているかまでは、ラベルからは読み取れない。これはこのドライブに限った話ではなく、HDDという製品そのものの素性なのだ。


次回こそ ── 届いたHDDでNAS復活へ

というわけで、交換用ドライブはようやく手元に揃った。4か月分の「待ち」も含めて、いい記録になったと思う。

次回は、いよいよこのST4000VN006を使って、故障したLS210Dの復活に挑戦する。分解したNASに新しいドライブを組み込んで、はたして無事に動き出すのか。あるいは、HDD交換だけでは済まない別の問題が待っているのか。実作業の記録は、次回に。


関連記事

参考(外部リンク)

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


参考リンク(外部)