ようこそ、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アナウンスおよびリンク追加予定です
WordPress「YOP Poll 7.0.8」でFatal Error発生｜Class "YopPoll\Admin\Deactivation_Feedback" not found の原因と対処法
5年ほど特に問題もなくアップデートを続けつつ利用してきたWordPressだが、突然？ 編集画面に入ろうとするとエラーが発生するようになった。これについて対処していく。 方針は、原因調査、対処、再発防止策絵検討と進める。
発生しているエラーは次です。 一部伏字化しています。
Fatal error: Uncaught Error: Class "YopPoll\Admin\Deactivation_Feedback" not found in /home/XXXX/YYY/public_html/info/wp-content/plugins/yop-poll/includes/class-plugin.php:42 Stack trace: #0 /home/XXXX/YYY/public_html/info/wp-content/plugins/yop-poll/includes/class-plugin.php(20): YopPoll\Plugin->init_hooks() #1 /home/XXXX/YYY/public_html/info/wp-content/plugins/yop-poll/includes/class-plugin.php(14): YopPoll\Plugin->__construct() #2 /homeXXXX/YYY/public_html/info/wp-content/plugins/yop-poll/yop_poll.php(80): YopPoll\Plugin::instance() #3 /home/XXXX/YYY/public_html/info/wp-includes/class-wp-hook.php(341): {closure}('') #4 /homeXXXX/YYY/public_html/info/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters(NULL, Array) #5 /home/XXXX/YYY/public_html/info/wp-includes/plugin.php(522): WP_Hook->do_action(Array) #6 /home/XXXX/YYY/public_html/info/wp-settings.php(622): do_action('plugins_loaded') #7 /home/XXXX/YYY/public_html/info/wp-config.php(94): require_once('/home/XXXX/YYY...') #8 /home/XXXX/YYY/public_html/info/wp-load.php(50): require_once('/home/XXXX/YYY...') #9 /home/XXXX/YYY/public_html/info/wp-admin/admin.php(35): require_once('/home/XXXX/YYY...') #10 /home/XXXX/YYY/public_html/info/wp-admin/about.php(10): require_once('/home/XXXX/YYY...') #11 {main} thrown in /home/XXXX/YYY/public_html/info/wp-content/plugins/yop-poll/includes/class-plugin.php on line 42
この Web サイトに重大なエラーが発生しました。サイト管理者のメール受信箱で手順を確認してください。問題が解決しない場合は、サポートフォーラム をお試しください。
WordPress のトラブルシューティングについてはこちらをご覧ください。
エラー内容を見ると、「Fatal error: Uncaught Error: Class “YopPoll\Admin\Deactivation_Feedback” not found 」とでている。 このプラグイン（plugins/yop-poll）があやしい。 プラグインの自動アップデートに失敗してと推測される。”not found”と言われているので、まずは、このファイルがあるかをチェックする。
SSHでログインして対象のファイルなどを確認する
$ ls -ltra wp-content/plugins/yop-poll/includes/Admin/
合計 148
-rw-r--r-- 1 XXXX XXXX 915 7月 30 01:23 class-admin-page-add-new.php
-rw-r--r-- 1 XXXX XXXX 15219 7月 30 01:23 class-guide.php
-rw-r--r-- 1 XXXX XXXX 5842 7月 30 01:23 class-admin.php
-rw-r--r-- 1 XXXX XXXX 33577 7月 30 01:23 class-admin-page-votes.php
-rw-r--r-- 1 XXXX XXXX 228 7月 30 01:23 class-admin-page-upgrade-to-pro.php
-rw-r--r-- 1 XXXX XXXX 259 7月 30 01:23 class-admin-page-settings.php
-rw-r--r-- 1 XXXX XXXX 1807 7月 30 01:23 class-admin-page-results.php
-rw-r--r-- 1 XXXX XXXX 25307 7月 30 01:23 class-admin-page-polls.php
-rw-r--r-- 1 XXXX XXXX 15001 7月 30 01:23 class-admin-page-logs.php
-rw-r--r-- 1 XXXX XXXX 18534 7月 30 01:23 class-admin-page-bans.php
drwxr-xr-x 2 XXXX XXXX 4096 7月 30 01:23 .
drwxr-xr-x 12 XXXX XXXX 4096 7月 30 01:23 ..
おえ「class-deactivation-feedback.php」はないですね。 これが原因かも
$ find wp-content/plugins/yop-poll -iname "*deactivation*"
$ nl -ba wp-content/plugins/yop-poll/includes/class-plugin.php | sed -n '30,55p'
30 // REST API.
31 add_action( 'rest_api_init', array( $this, 'register_rest_routes' ) );
32 add_filter( 'rest_post_dispatch', array( $this, 'set_rest_nocache_headers' ), 10, 3 );
33
34 // Admin.
35 if ( is_admin() ) {
36 $admin = new Admin\Admin();
37 $admin->init();
38
39 $guide = new Admin\Guide();
40 $guide->init();
41
42 $deactivation_feedback = new Admin\Deactivation_Feedback();
43 $deactivation_feedback->init();
44 }
45
46 // Frontend.
47 $frontend = new Frontend\Frontend();
48 $frontend->init();
49
50 // Assets.
51 $assets = new Assets();
52 $assets->init();
53
54 // Cron-based auto-reset.
55 $auto_reset = new Cron\Cron_Auto_Reset();
$ grep -R “Deactivation_Feedback” wp-content/plugins/yop-poll
wp-content/plugins/yop-poll/includes/class-plugin.php: $deactivation_feedback = new Admin\Deactivation_Feedback();
うーーん これは配布物件の制作ミス？ ですか？ それでは
一時的な対処として、
$deactivation_feedback = new Admin\Deactivation_Feedback();
$deactivation_feedback->init();の2行をコメントアウトしてみる
$ grep “Version:” wp-content/plugins/yop-poll/yop_poll.php
Version: 7.0.8
$ grep “Stable tag” wp-content/plugins/yop-poll/readme.txt
Stable tag: 7.0.8
$ grep -R “spl_autoload|autoload|require_once|include_once” \
wp-content/plugins/yop-poll/includes
wp-content/plugins/yop-poll/includes/Admin/class-admin-page-bans.php: require_once ABSPATH . ‘wp-admin/includes/class-wp-list-table.php’;
wp-content/plugins/yop-poll/includes/Admin/class-admin-page-logs.php: require_once ABSPATH . ‘wp-admin/includes/class-wp-list-table.php’;
wp-content/plugins/yop-poll/includes/Admin/class-admin-page-polls.php: require_once ABSPATH . ‘wp-admin/includes/class-wp-list-table.php’;
wp-content/plugins/yop-poll/includes/Database/class-schema.php: require_once ABSPATH . ‘wp-admin/includes/upgrade.php’;
$ vi wp-content/plugins/yop-poll/includes/class-plugin.php で編集してコメントアウトしてみる
上の２行のコメントアウトで、編集画面（管理者画面）は復旧しました
春版の「人・もの・かね」を踏まえ、半年で起きた最大の変化「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活用の本当の分かれ目なのだと思います。
Unable to find a medium containing a live file system というメッセージが表示されて、Linux の Live USB が起動しないまま止まってしまった経験はないでしょうか。GRUB のメニューを選んだ直後にこの画面で止まると、多くの人はまず「USB メモリが壊れたのか」と考えます。
Unable to find a medium containing a live file system
Attempt interactive netboot from a URL?
yes no (default yes):しかし実際には、USB そのものの故障だけが原因とは限りません。むしろ、一度 USB メモリを抜き差ししただけであっさり正常起動する、というケースも少なくないのです。この Unable to find a medium というメッセージが伝えているのは「結果」であって「原因」ではありません。両者を分けて理解しておくと、同じ症状に出会ったときに落ち着いて対処できるようになります。本記事では、このメッセージが何を意味するのかをまず整理し、その上で考えられる原因と、現実的な対処の順序を解説します。なお本記事は特定の製品に限った話ではなく、Ubuntu 系の Live USB 全般に当てはまる内容として書いています。
「Unable to find a medium containing a live file system」とは、起動処理を担うプログラム（casper）が、Live ファイルシステムを格納したメディアを見つけられなかった、という意味です。
ここでいう medium（メディア）は USB メモリだけを指すわけではありません。DVD ドライブ、ISO イメージをマウントしたデバイス、その他 Live システムを格納しうる媒体をまとめて指しています。つまりこのメッセージは「Live ファイルシステムが入っているはずの媒体を見つけられなかった」という結果だけを述べているのであって、「USB メモリが故障した」と断定しているわけではないのです。
では、その「Live ファイルシステム」とは何でしょうか。Ubuntu 系の Live システムでは、起動後に実際に動く本体は filesystem.squashfs という圧縮されたファイルです。電源投入から起動完了までの流れは、おおまかに BIOS / UEFI から GRUB へ、GRUB から Linux カーネルへ、カーネルから initramfs（初期 RAM ファイルシステム）へと進み、その中で casper が filesystem.squashfs を探し出してマウントする、という順序になっています。この最後の「探し出す」段階でつまずくと、Unable to find a medium のメッセージが表示されます。
逆にいえば、このメッセージが出た時点で分かるのは「最後のマウント段階まで到達したが、目的のファイルにたどり着けなかった」ということだけです。なぜたどり着けなかったのかは、ここからの「原因」の話になります。
同じ Unable to find a medium というメッセージでも、その背後にある原因は複数あります。代表的なものを四つに整理します。
第一に、起動メディアそのものが正しく認識されていないケースです。USB メモリが奥まで挿さりきっていない、USB ポート側の接触が甘い、あるいはタイミングの問題でデバイスの認識に失敗した、といった状況がこれにあたります。この場合、システムから見るとメディアに対応するデバイス自体が存在しないため、casper は探す対象を見つけられません。実際、Ubuntu のバグ報告でも、メディアを一度抜いて挿し直したら起動が続行した、という報告が複数寄せられています。冒頭で触れた「抜き差ししたら直った」という現象は、まさにこのパターンにあたります。
第二に、Live ファイルシステムそのものが欠けている、あるいは壊れているケースです。ISO の書き込みに失敗していた、転送が途中で止まっていた、ファイルが破損していた、といった場合です。メディアは認識されていても、肝心の filesystem.squashfs が読めなければ先には進めません。USB メモリを別のポートに挿し替えても改善しないときは、このパターンを疑うことになります。
第三に、起動パラメータの指定がずれているケースです。カーネルに渡すパラメータが正しくないと、ファイル自体は存在していても casper が探す場所が食い違い、見つけられないことがあります。市販の ISO をそのまま書き込んで使っている場合にはあまり起こりませんが、自分で起動設定を編集した環境では起こり得ます。
第四に、起動の途中までは認識できていたのに、処理の最中に読めなくなるケースです。I/O エラーや USB の再接続（リセット）、電源まわりの不安定さなどによって、途中から通信が途絶えてしまう状況です。これも結果として Unable to find a medium の状態に行き着きます。
このように、接触不良という比較的軽いものから、ISO の破損という作り直しが必要なものまで、原因の幅はかなり広いのが実情です。
原因が幅広いとはいえ、対処の手順は「軽くて起こりやすいもの」から順に試していくのが効率的です。
まず最初に試すべきは、USB メモリの抜き差しです。ポートから一度完全に抜き、数秒置いてからしっかりと挿し直し、もう一度起動を試みます。今回のきっかけになった事例でも、この操作だけで正常に起動しました。USB の接触不良は、完全に死んでいるわけではなく「ある程度は機能するが認識が安定しない」という中途半端な状態で起こることがあり、抜き差しによって接触が回復すると、それまでの症状が嘘のように直ることがあります。このメッセージが出たときは、まず挿し直しを試す価値が十分にあります。
それでも改善しない場合は、別の USB ポートを試します。Ubuntu のバグ報告には、同じ USB メモリでも片側のポートでは起動エラーになり、反対側のポートでは正常に起動した、という事例があります。USB 3.0 と 2.0 が混在しているマシンや、コントローラの異なるポートでは、相性によって挙動が変わることがあるためです。デスクトップなら背面のポート、ノートなら別の口、できれば USB ハブを介さず本体へ直結して試してみてください。
ポートを変えても直らないときは、ISO ファイルの作り直しを検討します。元の ISO を改めて入手し直し、書き込みツールで USB メモリへ書き込み直します。書き込み後に内容を照合する検証機能があれば、あわせて確認しておくと安心です。ここまで来ると、メディア側ではなく書き込まれたデータ側に問題があった可能性が高くなります。
それでも解決しない場合は、BIOS / UEFI の起動順序や、起動メニューに表示されるデバイスの並びなど、より基本的な設定を見直していくことになります。なお Live USB の起動過程で表示されるログは保存が残らないことが多く、後から詳しく追いかけるのは難しいため、現象が出たときの状況をメモしておくと、原因の切り分けに役立ちます。
「Unable to find a medium containing a live file system」は、casper が Live ファイルシステムの入った媒体を利用できなかった、という結果を示すメッセージです。それ自体は USB メモリの故障を意味しません。原因は接触不良から ISO の破損までさまざまなので、抜き差し、ポート変更、ISO の作り直し、設定の見直し、という順に切り分けていくのが現実的です。
特に、抜き差しだけで直るケースは実際に存在します。同じメッセージで止まったら、まずは落ち着いて USB を挿し直すところから始めてみてください。
このエラーに関する具体的な事例や議論は、Ubuntu の公式バグトラッカーにまとまっています。