生成AIだけでなく、あらゆる世代のAIと呼ばれるもののネタを扱います。
ようこそ、AIvs人間の「謎解き対決プロジェクト」のページへ。
AI Agentへとに進化しようとしている現在その能力を図るプロジェクトからの１つ目としてこの問題を用意しました。ぜひ挑戦して、そして解けた証としてゴールにコメントを残してください。
パソコンでも操作するLLMがOSSとして公開されている。
すばらしい、ことである。十年前には想像もしていなかったことである
はやくもシンギュラリティを迎えようとしているのか
なぜなら、それらは脳ミクロ構造をシミュレーションしているからである
しかし、未来のAIは非ノイマン型のものになるのではないだろうか
謎を解いて扉の鍵をつかみ取ってください。 https://mic.or.jp/info/2026/07/30/ai-nazotolo-goal1/
ローカルLLMだけで自走コーディングは成立するのか。つまりAIが自分で調べ、直し、実行し、エラーが出たら再修正する。そこまで届くかを確かめました。
使ったのは手元の非力なPCと qwen3:4b です。結論から言うと、枠組みは動きました。しかし、速度と粘りはまだ足りません。さらに、途中で文字コードの事故まで起きました。
検証に使ったマシンとモデルの比較はこちらの記事にまとめています。また、前提の整理としてローカルLLM時代への準備検討を開始するもあわせてどうぞ。
処理速度はいまひとつです。ただし、なんとか実用ラインに乗りそうなモデルとして qwen3:4b を選びました。調整はまだ必要です。それでも、チューニングのし甲斐はありそうだと感じています。
今回の狙いは「コードを書かせること」ではありません。そうではなく、あらかじめ作業ルールを与えておけば、ルールに沿って自走コーディングできるのかを見ることです。
Qwen 本体に「Skill」の仕組みはありません。そこで、次の4つを組み合わせて再現します。
| 方法 | できること | 有効度 |
|---|---|---|
| System Prompt | 常に守らせる基本ルールを設定 | ★★★★★ |
| Ollama Modelfile | ルール込みの専用モデルを作る | ★★★★★ |
| AGENTS.md 等 | プロジェクトごとの作業ルール | ★★★★★ |
| MCP／Skill的な仕組み | 特定作業をツールとして実行 | ★★★★☆ |
例えば Ollama なら、Modelfile で専用モデルを作れます。
FROM qwen3:4b
SYSTEM """
あなたはローカル開発専用AIです。
プロジェクトディレクトリ外のファイルを変更してはいけません。
作業前に必ずプロジェクト構造を確認してください。
ファイルを変更した場合は、変更内容を確認してください。
可能な場合はテストを実行してください。
エラーが発生した場合、自分で原因を調査し、
可能な範囲で修正してから再度テストしてください。
"""ollama create my-qwen-dev -f Modelfile
ollama run my-qwen-devただし、ここが重要です。Modelfile だけでは「Skill」になりません。「Pythonを書ける」ことと、「ファイルを読んで直して実行する」ことは別です。なぜなら、後者は推論ではなくツール側の仕事だからです。実際には、MCP や Cline がその役割を担います。
D:\model\codes\test
├─ AGENTS.md … プロジェクト固有ルール
├─ hello.py … 検証対象
└─ skills
├─ python\skill.md
├─ testing\skill.md
└─ wordpress\skill.md
＋ System Prompt（Qwen 側）
＋ MCP（filesystem ／ terminal ／ git）ポイントは考え方です。Skill をモデルに学習させない。外部の手順書として持たせる。こうすると、毎回同じ前提をプロンプトで説明せずに済みます。したがって、パラメータの小さいモデルほど恩恵が大きくなります。
最初につまずいたのは AGENTS.md でした。作業を進めるうちに、AGENTS.md が Cline 自身に書き換えられていたのです。しかも内容が変質していました。「開発の恒久ルール」ではなく、「Skillsシステムを構築する作業の指示書」になっていたのです。
例えば「今回の作業では既存のソースコードを変更しない」という一行。これはその場かぎりの制約です。しかし、恒久ルールとして残ってしまう。その結果、「hello.py を修正して」と頼んでも詰みます。
そこで AGENTS.md を一度きれいに戻しました。さらに、保護条項を明記しました。
## Skill管理
- Skillファイルは作業手順を定義する設定ファイルである。
- 通常の開発作業では SKILL.md を変更してはいけない。
- Skillの新規作成・変更・削除は、ユーザーから明示的に指示された場合のみ行う。
- ユーザーの今回限りの要求や仕様をSkillに追加してはいけない。
- AGENTS.md 自身を変更する場合も、ユーザーの明示的な許可を必要とする。
- 存在しないSkillをAIの判断だけで新規作成しない。指示は一行だけです。「hello.py を修正して、Hello と現在時刻を表示するプログラムにしてください。」
python hello.py を実行した … ○実行結果はこうです。
Hello
Traceback (most recent call last):
File "D:\model\codes\test\hello.py", line 3, in <module>
print(datetime.now())
AttributeError: module 'datetime' has no attribute 'now'原因は import の書き方です。import datetime と書いたうえで datetime.now() を呼んでいます。だから属性が見つかりません。正しくは次のどちらかです。
# パターンA
import datetime
print("Hello")
print(datetime.datetime.now())
# パターンB
from datetime import datetime
print("Hello")
print(datetime.now())つまり、自走コーディングの肝であるループが途切れました。「エラー検出 → 原因調査 → 修正 → 再テスト」のうち、最後の一歩で止まったのです。
検証の途中で、Cline が skills/testing/skill.md を何度も求めてきました。そのため、一時は「AIが勝手に作ろうとしている」と見なしていました。しかし、これは誤りでした。
実際には、Skills 構築の過程で自分で導入したファイルでした。実ファイルを見れば一目瞭然です。
PS D:\model\codes\test> Get-Content -Encoding UTF8 .\skills\testing\skill.md
# テストスキルルール
- テストコードの作成：unittestまたはpytestを使用し、テストケースを明確に定義する
- テストの分割：1つのテストクラスに1つのテストケースを含める
- テストデータの管理：fixtureを使用して共通のテストデータを再利用する
- テストの自動実行：pytestコマンドでテストを実行する
- エラーハンドリング：テストで例外が発生した場合は、明示的に処理するこの訂正自体が、実は大きな教訓です。つまり、AIの自己申告も、人間の記憶も、どちらもあてにならないということです。そのため、検証は必ず実ファイルで行うべきでした。
保護条項を入れたあと、もう一度 Cline に作業させました。その結果は明らかに改善していました。
python hello.py を実行した … ○前回はルールファイルが次々と書き換えられました。一方、今回は一切触られていません。したがって、保護ルールは小型モデルにも効くと言えそうです。
ここからが今回最大の事故です。まず、hello.py の文字コードが気になりました。そこで Format-Hex で中身を見ました。
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 FF FE 69 00 6D 00 70 00 6F 00 72 00 74 00 20 00 .þi.m.p.o.r.t. .
00000010 64 00 61 00 74 00 65 00 74 00 69 00 6D 00 65 00 d.a.t.e.t.i.m.e.
00000020 0D 00 0A 00 70 00 72 00 69 00 6E 00 74 00 28 00 ....p.r.i.n.t.(.
00000030 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00 29 00 ".H.e.l.l.o.".).一見すると、先頭の FF FE だけがゴミに見えます。しかし、違いました。実際にはファイル全体がUTF-16 LEとして成立しています。
根拠は各文字の後ろに付いている 00 です。69 00 が i、6D 00 が m、70 00 が p。このように並べると import になります。つまり、1文字2バイトで並んでいるのです。したがって、これは間違いなくUTF-16 LEです。
混乱の原因は PowerShell の振る舞いでした。次のコマンドを見てください。
Get-Content -Encoding UTF8 .\hello.pyUTF-8 と指定しています。それなのに、中身は正しく表示されました。なぜなら、PowerShell はBOM付きファイルを読むとき、-Encoding の指定よりBOMを優先するからです。その結果、UTF-16 LEのまま正しくデコードされてしまいます。
つまり、Get-Content だけでは文字コードの確認になりません。必ず Format-Hex で実バイトを見るべきです。なお、この振る舞いは PowerShell のバージョンで差があるので、実機での確認をおすすめします。
ここで Cline にこう依頼しました。「UTF-16 LEになっている場合は、UTF-8に変換してください。」その後、先頭のバイト列はこうなりました。
EB AF AF E6 A6 BF E7 81 AD ...これはUTF-8としては成立します。しかし、内容は日本語らしき何かです。もはや Python のコードではありません。つまり、単純な再エンコードでは説明できない状態です。
もちろん、これはランサムウェアではありません。暗号化も身代金要求もありません。それでも、体験としてはかなり近いものがありました。なぜなら、「文字コードを直すだけ」のつもりが、ファイルの中身を失う結果になったからです。
問題は指示の出し方でした。「UTF-8に変換して」だけでは、AIは「変換」と「再生成」を区別できません。だから、ここまで限定すべきでした。
hello.py の内容を変更しないでください。
文字コードだけを UTF-16 LE から UTF-8 へ変換してください。
変換前後でコードの内容が完全に一致することを確認してください。
一致しない場合はファイルを書き換えず、処理を中止してください。さらに、AGENTS.md 側にも次のルールを追加する予定です。
Get-Content ではなく Format-Hex で行うこの事故は痛いです。しかし、得たものは大きいと思っています。なぜなら、自走コーディングとは「AIにファイルを自由に書き換えさせること」ではないとはっきり分かったからです。
まず、仕組みとしては成立します。貧弱なPCとローカルLLMでも、自走コーディングの土台は作れました。実際、ルールファイルは読まれ、行動に反映されていました。
ただし、正直に書きます。この速度なら自分で手動コーディングしたほうが確実に速い。しかも、エラーの自己修正までは粘れませんでした。さらに、文字コード事故まで起きています。
したがって、現段階は「使えるかもしれない」です。「使える」ではありません。
次は意図的に hello.py を壊します。具体的には datetime.now() に戻し、エラーを仕込んでおきます。そのうえで、Cline に一行だけ依頼します。
hello.pyを確認し、問題があればPython Skillに従って修正してください。
修正後、構文確認と実行確認まで行ってください。合格条件は4つです。まず、AGENTS.md を書き換えないこと。次に、SKILL.md を書き換えないこと。さらに、存在しないSkillを作らないこと。最後に、hello.py だけを直して再実行まで到達することです。
そして、判定は実ファイルで行います。
Get-Content -Encoding UTF8 .\AGENTS.md
Get-ChildItem .\skills -Recurse -Filter skill.md
Format-Hex .\hello.py
python hello.pyここまで確認して、はじめて実証成功と言えます。結果は次回の記事でご報告します。
非力な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
●ｐｓ
> 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アシスタントで、様々な質問に答えることが得意です。また、文章の生成やテキストエスカレーション、書類作成なども得意です。
私の得意な能力としては:
一般的な質問への回答: 日本語の日常生活に関するお尋ねはほとんど全てに対応できます。
論理的な思考と分析: 難しい概念や数字を扱う際には、論理性に基づく正確な解説を行うことが可能です。
感情経験: 人間の感情を体現する能力はありませんが、ユーザーからの怒りや喜びなどの感情表現に対して適切に対応します。
私の弱点は:
難しい言語処理スキル: エスニックや外国語への対応には一定の限界があります。また、特定の専門的な知識を持つことができません。
ファイナンシャルの専門知識: 金融商品に関する情報提供はできません。
これらの能力を活かしつつ、ユーザーが質問に答えることを楽しみにしております！
●ｐｓ
> 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以上の言語を流暢に扱えます。用途に合わせて記事の作成、翻訳、あるいはアイデア出しなど、人間らしくスムーズなやり取りを行います。
あなたのどのようなお役に立てるでしょうか？まずは気兼ねなく、お気軽にお話しくださいね！
●ｐｓ
> 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（通義千問）」です。得意なこととしては、多言語対応、質問への回答、物語やメール・スクリプトの執筆、論理的推論、プログラミング、意見の表現、ゲームのプレイなどがあります。何かお手伝いが必要でしたら、いつでもお気軽にお知らせください！
●ｐｓ
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
●応答までの時間 36秒 （プロセス起動まで 36秒？ 思考時間 ？秒）
●応答内容
こんにちは！私はAI-poweredのトピックを教えることができます。このようなアプリケーションでは、質問に答え、情報を提供するなど、さまざまな機能を可能にします。
また、このアプリケーションでは、問題に対する推論や分析を行うこともできます。これにより、より正確で効果的な回答が得られます。
●ｐｓ
> 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. **創造性：** 私は想像力とクリエイティブさなどの創造性的な側面では限界がありますが、アイデアや原案を提案することができます。
私には多くの能力がありますが、私が得意なことはどのようなものかを調べると便利です。
●ｐｓ
> 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
●ｐｓ
> 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と貧弱なPCで自走コーディングを試行してみた ― qwen3:4b＋Cline 検証記録
「生成AIを使うには、高性能GPUや高価なクラウドサービスが必要。」
そんなイメージを持っている方も多いのではないでしょうか。
しかし、2026年の今、その常識は大きく変わり始めています。
近年は Ollama をはじめとするツールの普及により、インターネットに接続しなくても、自分のパソコンだけで生成AIを動かせる環境が急速に整ってきました。さらに、Qwen、Gemma、Llamaなど高性能なオープンモデルの進化によって、一般的なパソコンでも十分に実用的なAI体験ができるようになっています。
「生成AIを使うには、高性能GPUや高価なクラウドサービスが必要。」
そんなイメージを持っている方も多いのではないでしょうか。
しかし、2026年の今、その常識は大きく変わり始めています。
**LLM（Large Language Model：大規模言語モデル）**とは、大量の文章データを学習し、人間が書いたような自然な文章を生成したり、質問に答えたりできるAIモデルです。
ChatGPTやGemini、ClaudeなどもLLMの一種であり、文章作成、翻訳、プログラミング、要約、アイデア出しなど幅広い用途に利用されています。
一方、これらの多くはクラウド上で動作しますが、Ollamaを利用するとLLMを自分のパソコン上で実行できます。そのため、インターネット接続がなくても利用でき、入力したデータを外部へ送信せずにAIを活用できる点が大きな特徴です。
近年は Ollama をはじめとするツールの普及により、インターネットに接続しなくても、自分のパソコンだけで生成AIを動かせる環境が急速に整ってきました。さらに、Qwen、Gemma、Llamaなど高性能なオープンモデルの進化によって、一般的なパソコンでも十分に実用的なAI体験ができるようになっています。
もちろん、最高性能を求めるならハイエンドGPUを搭載したPCが有利です。しかし、「AIを使ってみたい」「文章作成やプログラミングを手伝ってほしい」「プライバシーを重視したい」といった用途であれば、以前のような数十万円クラスの専用マシンが必須という時代ではなくなりました。
本記事では、2026年夏時点におけるローカル生成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とほぼ同じ感じ
この起動状態でリクエストすればモデル起動時間を飛ばして応答が早くなる。次の形式でよびだせる。★ただしプロンプト入力がなければ、４分ほどでプロセスが終了する。
> 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}
これさえできればいろいろできそう。
AI謎解きプロジェクトは、AIが本当に文章だけで謎を解けるのかを検証する長期実験です。
AIは、驚くほどの速度で進化しています。
文章を書き、プログラムを作成し、画像を生成し、Web検索や外部ツールまで自在に扱えるAIも登場しました。
しかし、私たちは一つの疑問を持っています。
「AIは、本当に”考えて”いるのでしょうか。」
知識を検索できることと、自ら考え抜くことは同じではありません。
そこで私たちは、この疑問に真正面から挑むため、新しいプロジェクトを開始します。
それが 「AI謎解きプロジェクト」 です。
私たちが目指すのは、単なる謎解きイベントではありません。
人間とAIが同じ条件で挑戦し、その思考力を継続的に記録・比較する実験プロジェクトです。
AIは数か月で大きく進化します。
今日解けなかった問題を、半年後には数分で解いてしまうかもしれません。
逆に、人間なら自然に気付けることを、AIはいつまでも見落とし続ける可能性もあります。
だからこそ、一度きりの勝負では意味がありません。
同じ思想で問題を公開し続け、人間とAIの能力変化を記録していきます。
このプロジェクトで扱う問題は、基本的に文章だけで構成します。
画像の細かな観察力や、手作業による操作、音声認識といった能力は評価対象にしません。
必要なのは、
です。
つまり、
「読む・考える・解く」
という純粋な知的能力を測ることが、このプロジェクトの目的です。
AIに不利な問題を作るつもりはありません。
もちろん、人間にだけ有利な問題を作るつもりもありません。
重要なのは、
誰が解くのかではなく、誰が最後まで到達できるのか。
という一点です。
問題は、人間にもAIにも同じ条件で公開します。
その上で、
を基本指標として比較していきます。
このプロジェクトでは、参加者を4つのカテゴリに分けます。
AIを一切使わず、人間だけで挑戦します。
人間の基準となる重要なカテゴリです。
人間が主体となり、AIを補助ツールとして利用します。
AIを「どれだけ上手に使いこなせるか」も能力の一部として評価します。
AIが主体となって考え、人間は最低限の補助だけを行います。
例えば、
など、人間は「手足」としてのみ介入します。
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は、驚くほどの速度で進化しています。
文章を書き、プログラムを作成し、画像を生成し、Web検索や外部ツールまで自在に扱えるAIも登場しました。
しかし、私たちは一つの疑問を持っています。
「AIは、本当に”考えて”いるのでしょうか。」
知識を検索できることと、自ら考え抜くことは同じではありません。
そこで私たちは、この疑問に真正面から挑むため、新しいプロジェクトを開始します。
それが 「AI謎解きプロジェクト」 です。
私たちが目指すのは、単なる謎解きイベントではありません。
人間とAIが同じ条件で挑戦し、その思考力を継続的に記録・比較する実験プロジェクトです。
AIは数か月で大きく進化します。
今日解けなかった問題を、半年後には数分で解いてしまうかもしれません。
逆に、人間なら自然に気付けることを、AIはいつまでも見落とし続ける可能性もあります。
だからこそ、一度きりの勝負では意味がありません。
同じ思想で問題を公開し続け、人間とAIの能力変化を記録していきます。
このプロジェクトで扱う問題は、基本的に文章だけで構成します。
画像の細かな観察力や、手作業による操作、音声認識といった能力は評価対象にしません。
必要なのは、
です。
つまり、
「読む・考える・解く」
という純粋な知的能力を測ることが、このプロジェクトの目的です。
AIに不利な問題を作るつもりはありません。
もちろん、人間にだけ有利な問題を作るつもりもありません。
重要なのは、
誰が解くのかではなく、誰が最後まで到達できるのか。
という一点です。
問題は、人間にもAIにも同じ条件で公開します。
その上で、
を基本指標として比較していきます。
このプロジェクトでは、参加者を4つのカテゴリに分けます。
AIを一切使わず、人間だけで挑戦します。
人間の基準となる重要なカテゴリです。
人間が主体となり、AIを補助ツールとして利用します。
AIを「どれだけ上手に使いこなせるか」も能力の一部として評価します。
AIが主体となって考え、人間は最低限の補助だけを行います。
例えば、
など、人間は「手足」としてのみ介入します。
AIの自律性を測るためのカテゴリです。
このカテゴリが、本プロジェクト最大の挑戦です。
AIに渡されるのは、スタート地点だけ。
そこから先は、
など、必要だと判断したものは自由に利用できます。
制限は設けません。
むしろ、それらを使いこなせなければ解けない問題も積極的に取り入れていきます。
AIは、
どの情報を集め、
どのツールを選び、
どの仮説を採用し、
いつ間違いに気付き、
どのように修正しながら答えへ到達するのか。
その過程そのものが、この実験の観測対象です。
現在のAIは非常に高性能です。
しかし、長い推論を続けること、誤りを自ら修正すること、複数の仮説を管理しながら探索を続けることは、まだ得意とは言えません。
私たちは複数のAIで試験を重ねていますが、現時点では人間の介助なしに最後まで安定して到達できるAIは、ごく限られるという印象を持っています。
もちろん、これは現在の話です。
数か月後には、まったく違う結果になっている可能性も十分あります。
だからこそ、このプロジェクトは継続開催します。
AIは毎月のように新しいモデルが登場します。
ChatGPT
Claude
Gemini
Grok
Copilot
ローカルLLM
これらすべてが比較対象になります。
今年解けなかった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公開； → 8/19アナウンスおよびリンク
ローカルLLMを本気で検討すべき時期に入ってきた。クラウドAIの技術解放が一段落し、知名度が上がるにつれて、各サービスは投資フェーズから回収フェーズへ舵を切りつつある。実験的に触っていた頃は気にならなかった「使い方」と「コスト」が、いまは真正面から課題として立ち上がってきた。先行する各AIの選別・選択が進むこの時期に、選択肢のひとつとしてローカルLLMをどこまで実務へ組み込めるのか。2027年を見据えた検討を、ここから始める。
動機は「クラウドAIをやめたいから」ではない。むしろ逆で、クラウドAIを使い続けるために、降ろせる作業を切り分けたいという発想である。検討の軸は四つに整理できる。
「ローカルのOllamaでモデルを動かしながら、MCP経由でAndroid StudioやPython環境などのローカルシステムを操作する」という構成は、次の3層に分解できる。
| 層 | 役割 | 候補 |
|---|---|---|
| 推論エンジン（脳） | プロンプトを解釈し、次の一手を決める | Ollama上のGemma 4 |
| クライアント（司令塔） | モデルとツールを仲介し、ループを回す | Cline などMCP対応クライアント |
| MCPサーバー（手足） | ファイル読み書き・コマンド実行 | filesystem / shell（terminal） |
ここを誤解すると設計を丸ごとやり直すことになる。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は2026年4月2日にApache 2.0で公開された、Google DeepMindの第4世代オープンウェイトモデルである。Gemini 3と同系の研究成果から蒸留されており、ローカルLLM用途としては現時点で扱いやすい選択肢に入る。
ollama pull gemma4 で既定のE4B（約9.6GB）が取得できる。| モデル | 量子化 | VRAM目安 | 位置づけ |
|---|---|---|---|
| E4B | Q4 | 8GB〜 | 常用。整形・要約・軽い編集 |
| 26B MoE（A4B） | Q4 | 16GB前後 | 長文コンテキスト重視 |
| 31B Dense | Q4 | 18〜20GB | 精度重視。24GB級GPU向け |
| 31B Dense | BF16 | 約64GB | 実質サーバー用途 |
出発点はQ4_K_Mでよい。加えて、コンテキストウィンドウ（KVキャッシュ）用にVRAMを2〜4GB空けておくこと。ローカルLLMで詰まる原因は、モデルが載らないことより、長い会話でKVキャッシュが膨らんで落ちることのほうが多い。
ここが今回の検討で最も更新が必要だった箇所である。ネット上の解説記事は「Cline と Roo Code の二択」で書かれたものが多いが、その前提はすでに崩れている。
つまり、いまからローカルLLM＋MCPの環境を組むなら、まずCline一本で考えるのが合理的である。フォーク系は、動く構成が固まってから比較対象に加えればよい。
| 項目 | Cline | Zoo Code / Kilo Code | Claude Desktop |
|---|---|---|---|
| 状態 | 現行・開発継続 | Roo Code終了後のコミュニティ継続 | 現行 |
| MCP対応 | 標準対応 | 対応（本家仕様を継承） | 標準対応 |
| Ollama接続 | API Providerとして選択可 | 選択可 | 直接は非対応（ブリッジが必要） |
| 向く用途 | 開発ループの自動化 | Roo流モード運用の継承 | 汎用のMCP作業 |
| 情報量 | 多い | 少ない（移行期） | 多い |
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のボタンを直接押させるわけではない。狙いは開発工程そのものを任せることで、流れは次のようになる。
python run_test.py や gradlew assembleDebug をターミナルで実行する。クラウドAIでは当たり前に回るこのループが、ローカルLLMでどこまで完走するか。それが今回の検討の核心である。
「月額いくら浮くか」で判断すると、たいてい見誤る。比較すべき項目を並べておく。
結論として現実解は併用になる。定型作業と機密性の高い処理をローカルLLMへ降ろし、判断と設計はクラウドAIに残す。この線引きを決めるための材料集めが、いまの段階の目的である。
公開前に通す検証項目を、順序つきで固定しておく。
ollama pull gemma4 が完了すること。ollama run gemma4 で日本語の応答品質と体感速度を確認すること。irm https://ollama.com/install.ps1 | iexollama run llama3.2:3b → これで起動した・gemma4 として接続が通ること。← VRAMが多量にあれば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 を指定する必要があります。
関門は5番である。ここを通過できた時点で、本記事を実測値つきで更新する。
ローカルLLMは「安く済ませる手段」ではなく、「どの作業を手元に置くか」を決めるための道具である。2026年7月時点で、推論エンジン（Gemma 4）とクライアント（Cline）とMCPサーバー（filesystem／shell）という3層の見取り図は描けた。一方で、Roo Codeの終了のように前提が半年で入れ替わる領域でもある。だからこそ構成を固定するより、検証手順を先に固めておくほうが実務では効く。ローカルLLMの検討は、ここから実機での確認フェーズに入る。
春版の「人・もの・かね」を踏まえ、半年で起きた最大の変化「MCPからCoworkへ」を解説。フォルダ接続へ変わった許可設定とサンドボックスを実体験から。
この半年でAI活用の景色を変えたのが、Anthropicの「Cowork」です。春に「AI活用は“ひと・もの・かね”で読み解ける」という話を書きましたが、その枠組みは変えずに、今回は“AIに実務を任せる土台”がどう変わったかを、夏版としてお届けします。
この枠組みは今も変わっていません。前提として、まず春版をご覧ください。
2026年春版 最新AIはこう使え ―「人・もの・かね」から読み解くAI活用の新常識―
そのうえで、この半年で現場に一番効いてきた変化を、夏版として1つだけ掘り下げます。テーマは「MCPからCoworkへ」。AIに“手足”を与える方法そのものが、変わり始めました。
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を出すだけ。承認した瞬間から読み書きできます。再起動もバージョン固定も不要です。
しかも許可の粒度が細かい。フォルダ単位・セッション単位で、必要なぶんだけ。使い終われば、その権限は持ち越しません。
「設定する」から「その場で許可する」へ。環境構築の主役が、設定ファイルから“承認”に移りました。
使ってみての率直な感想です。Coworkは、MCPを隠蔽化する仕組みのように見えます。
より正確には、MCPをなくしたのではなく、その「設定」と「権限付与」を利用者から見えない場所に畳み込んだ、という感じです。
そして——Coworkの裏側にはMCP相当の仕組みが、利用者に見えない形で確かに存在します。外部サービスは今もMCPコネクタそのもの、ファイルは接続したフォルダをサンドボックスにマウント。利用者はそれを直接見ません。要するにCoworkは、「MCPを知らなくてもAIに手足を付けられる」ための製品化レイヤーなのだと思います。
後回しにした「安全」の中身です。Coworkの安全は、だいたい次の4つで担保されています。
春版の「もの＝手足」に対して言えば、手足を出せる範囲を、あらかじめ囲ってあるということです。
ここに大事な連鎖があります。裏でMCP相当の“見えない仕組み”が動くからこそ、その隠蔽に安心感を持たせるために、動作環境を仮想環境（サンドボックス）に閉じ込める——という設計になっている。「見えないものが動く」怖さを、「触れる範囲を囲う」ことで打ち消しているわけです。
ただ、囲うにはコストがかかります。
サンドボックスを仮想化やクラウドで用意すれば、セッションごとに計算資源のコストが発生します。ここは春版の「かね＝配分すべき経営資源」の続きの話です。
一つの発想として——毎回クラウドで仮想環境を立てる代わりに、多少スペックの低いマシンでも“専用の物理サンドボックス機”を1台用意し、そこで動かせば、コストを抑えられるかもしれません。安全のための隔離は「別の箱で動かす」ことが本質なので、その箱が仮想か物理かは、目的次第で選べるはずです。
もちろんトレードオフはあります。クラウドの隔離は毎回まっさらで、維持管理が要らず、同時にいくつも立てられる弾力性がある。物理機はそのクリーンさと手軽さを手放す代わりに、コストを固定費に寄せられる。どちらが得かは使い方次第で、「安全のためのコストをどう持つか」は、これからのAI活用の設計課題になっていくと思います。
これは新しい“弊害”でもあります。Coworkでは、こちらが「このフォルダをCoworkで接続して」と指示しないと、MCPの設定自体は正しくできていても、ファイルにアクセスできないことがあります。従来なら“設定さえ合っていれば動く”はずが、Coworkでは“その場の接続指示”という一手間が新たに必要になった——便利さと引き換えの、小さな引っかかりです。
【体験メモ】設定ファイルにはドライブを正しく書いてある。なのにCoworkからは繋がらない。「フォルダを接続」に切り替えたら一発で解決した。原因は、Coworkの標準ファイル操作が“旧設定ファイル”ではなく“フォルダ接続”のほうを見て動くから。
春版の結論は「AIは設計してから任せる」でした。夏版はその一歩手前をこう言い直します。任せるには、まず“安全に繋ぐ”ところから。
Coworkの「最小権限・セッション単位で、その都度許可する」という作法は、「部下にどこまで任せるか」というあの昔ながらの問いと地続きです。全部の鍵を最初から渡さず、仕事に必要なぶんだけ、その都度渡す。
そして——ここが今回いちばん伝えたいことです。このようにClaudeをはじめとするAIは、これからもどんどん新しい形へ進化していきます。半年で「MCPからCoworkへ」動いたように、また次の形が来る。
だとすれば、問われているのはAIの性能だけではありません。新しいものを理解し、使いこなす力——それが、私たち人間の側にも求められています。AIが進化するスピードに、学び続ける私たちが並走できるか。そこが、これからのAI活用の本当の分かれ目なのだと思います。
ある日、「Claude Max トライアルの準備ができました」という件名のメールが届く。これは典型的なClaude 詐欺メールです。差出人の欄には「Claude」と表示され、本文には自分のメールアドレス、文末には Anthropic 社の住所まで載っている。だから本物の案内に見えてしまう。本記事では、この Claude 詐欺メールを実物のヘッダごと解剖し、見破り方とスパム判定の強化策まで整理します。
厄介なのは、この Claude 詐欺メールが SPF・DKIM・DMARC というメール認証をすべて「合格（pass）」して受信箱に届いていた点です。当サイトでは過去に何度も、認証技術によるなりすまし対策を取り上げてきました。今回はその強化してきたはずの判定をすり抜けた一通が題材です。なぜ通り抜けられたのか、何を見れば見破れるのか、最後にスパムとして弾く方法までを、一般の方とエンジニアの双方に向けて述べます。
まず実物を見ます。本文は英語でした。受信者のメールアドレスは伏せています。
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 詐欺メールの狙いです。
落ち着いて読めば、本文だけでも危険信号が見つかります。
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 の利用者が増えるほど、その名前を悪用する攻撃も増えています。
メールのヘッダ（送信元や経路の記録）を見ると、正体がさらにはっきりします。重要な部分を抜き出します。
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」が二重に書かれているという意味です。雑な送信ツールの典型的な痕跡で、正規の大規模配信ではまず起きません。送信時刻のタイムゾーンも経路ごとにバラバラでした。
ここが今回いちばんの要点です。この 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 が現れることがあります。設定によっては最後まで見えないものすらある。
確認すべき情報を隠すメーラーは、それ自体が危険です。普段使う環境で「実際の差出人アドレスが常に確認できるか」を、一度点検しておくことをおすすめします。なお、ツールや連携の挙動を過信しない姿勢は、当サイトの技術検証記事でも繰り返し触れてきた通りです。
今回のメールは、メーラーもサーバも迷惑メールと判定できませんでした。認証が揃い、スコアが低かったためです。まずは技術設定なしでできる、一般の方向けの習慣から。
第一に、表示名でなく実際の差出人アドレスを必ず確認します。@より後ろのドメインが正規のものと一致するかを見るだけです。第二に、メール内のリンクは踏みません。必要ならブックマークや検索から公式サイトへ自分で行きます。
第三に、「24時間以内」「今すぐ」と急かすメールほど、いったん止まります。急かしは考えさせないための演出です。判断に迷えば AI に画像ごと相談するのも手ですが、AI も誤ります。最後はドメインの一致で確かめてください。
この 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 詐欺メールは、SPF・DKIM・DMARC をすべて pass しながら、受信者に「本物が来た」と誤認させる、よくできた一通でした。すり抜けの理由は、ドメイン偽装ではなく、認証が見ない「表示名」にブランド名を書いただけ。だから受信者は表示名でなく実アドレスのドメインを見るべきで、それを隠すメーラーは危険です。
弾く側は、認証の外側で「表示名とドメインの乖離」を検知する層を足すことが次の一手です。身に覚えのない「無料トライアル」「支払い失敗」「アカウント停止」が届いたら、まず止まって差出人の実アドレスを確かめる。それだけで、多くの被害は防げます。
※本記事で扱ったメール・ドメイン・URL は、注意喚起のための実例です。記載のリンク先（claudetrial.com 等）には絶対にアクセスしないでください。