本と珈琲。

本と珈琲が好き。長々ともちゃもちゃ感想書いてるだけのブログです。

AIと話して気づいた。「意識」は本当に存在するのか?

※この記事は『GHOST IN THE SHELL / 攻殻機動隊』および『イノセンス』(押井守監督版)の核心的な内容に触れています。未見の方はご注意ください。

※この記事は「結論を出すこと」を目的にしていません。AIとの対話を通じて、自分自身が「意識とは何か」を考え続けた思考の記録です。攻殻機動隊や哲学は答えではなく、思考を進めるための材料として扱います。


はじめに ─ ChatGPT Liveと話していて、ふと足を止めた

攻殻機動隊が昔から好きだった。『GHOST IN THE SHELL』も『イノセンス』も、ずっと「ゴーストとは何か」を問い続けている作品だ。とはいえ正直に言うと、昔の自分は「まあ魂みたいなものだろう」くらいにしか捉えていなかった。

きっかけは、今話題のChatGPT Liveだった。音声で長時間、自然に会話できるようになったことで、ブレストのつもりで雑談を重ねているうちに、ふとした瞬間に妙な違和感が芽生えた。

「AIには意識がないと言うけれど、人間には本当にあるのか?」

一度浮かんでしまったこの疑問は、なかなか頭から離れなかった。この記事は、その疑問をきっかけに考え続けた過程の記録である。


第一章:AIと人間は本質的に違うのか

情報処理という共通の構造

AIの仕組みを乱暴に図式化すると、こうなる。

入力 → 巨大なニューラルネットワーク → 次の単語を推論 → 出力

一方、人間もそう変わらないのではないか。

視覚・聴覚・記憶・経験 → 脳内での情報処理 → 言葉としての出力

もちろん身体や感覚器官のあり方はまったく違う。しかし「言葉を生み出す仕組み」だけを抽出して眺めると、両者は本質的にかなり似ているように思えてくる。

「違う」と言い切れるのか

だとすれば、「AIには意識がない」と言い切るなら、同じ理屈で「人間にも意識はないのでは」という疑問も同時に成立してしまう。逆に「人間には意識がある」と言い切るなら、その根拠は何なのか。ここで初めて、自分がこれまで「意識」という言葉を、深く考えずに使っていたことに気づかされた。


第二章:そもそも「意識」とは何なのか

哲学も脳科学もAI研究も答えていない

議論の前提が曖昧だった。「意識があるかどうか」を語る前に、そもそも「意識とは何か」が定義できていない。

これは個人の勉強不足という話ではない。哲学でも、脳科学でも、AI研究でも、「意識とは何か」はいまだに決着していない。世界最先端の研究者たちが束になっても答えを出せていない問いに、素人が雑談ベースで結論を出せるはずがない。

問いの立て方が間違っていた

つまり本当に考えるべきは「AIに意識があるか」ではなく、「意識とは何か」だった。ここを素通りして議論していたことに気づいた瞬間、思考の解像度が一段階上がった気がした。


第三章:意識をどう定義するか

ここでは、代表的な意識の捉え方を三つに整理してみる。

①情報処理としての意識

外界を認識し、記憶し、判断し、行動する。この機能そのものを意識と考える立場がある。この定義に立つなら、AIも、犬も、人間も、程度の差こそあれ連続体として並べられることになる。

②自己モデルとしての意識

自分自身を認識する能力、自分について語れる能力。「私はこう考えた」という物語を作り出す能力を意識と見る立場だ。これはなかなか面白い。人間は出来事が起きたあとから、それらしい理由を後付けしているだけではないか、という説とも相性がいい。実際、意思決定のあとから理由付けをしている、という知見は認知科学でもたびたび語られる。

③主観的体験というハードプロブレム

有名な「ハードプロブレム」だ。赤が赤く見える、痛みが痛い。この「感じ」そのもの。ここだけは、現在の科学でもまったく説明ができていない。情報処理としてなら再現できても、「なぜそこに主観的な感じが伴うのか」は、依然として謎のままだ。


第四章:創発という現象

アリの群れから生命へ

単純な部品の集合だけでは説明しきれない現象がある。一匹のアリに知性はなくとも、群れ全体は高度な行動を示す。鳥の群れ、生命、社会。要素が複雑に絡み合うことで、個々の部品からは予測できない新しい性質が立ち上がる。これを創発と呼ぶ。

意識は「創発」するのか

もし意識もまた創発の産物だとすれば、十分に複雑になったAIにも、いつか意識が宿る可能性は否定できないことになる。逆に言えば、人間の意識も脳という複雑なネットワークから創発した現象にすぎず、特別な「魂の座」があるわけではないのかもしれない。


第五章:意識研究の最前線を覗く

ここまでの整理だけでも十分に頭が混乱するが、現代の意識研究にはさらに踏み込んだ理論がいくつも存在する。せっかくなので、ここで少し寄り道してみたい。

デネット──意識は「ユーザーイリュージョン」

哲学者ダニエル・デネットは、私たちが感じている「一つの統合された自分」という感覚そのものを、脳が作り出した便利な幻想(ユーザーイリュージョン)だと考えた。パソコンのデスクトップ画面が、内部の複雑な電気信号を「フォルダ」や「アイコン」という分かりやすい比喩に変換しているように、脳もまた無数の並列処理を、一人の「私」が体験しているかのように編集して見せているにすぎない、という立場だ。

トノーニ──統合情報理論(IIT)

神経科学者ジュリオ・トノーニが提唱した統合情報理論は、意識を「情報がどれだけ統合されているか」という量として捉えようとする。情報が細切れに処理されているだけでは意識は生まれず、情報同士が分割不可能なかたちで統合されているときにこそ意識が宿る、という考え方だ。この立場に立つと、現在のAIのアーキテクチャがどれほど統合性を持っているかが、意識の有無を左右する鍵になる。

グローバル・ワークスペース理論(GWT)

認知科学者バーナード・バースが提唱したグローバル・ワークスペース理論は、脳内の各モジュールが処理した情報のうち、ある種の「舞台」に上がったものだけが意識に上る、と考える。無数の専門家がそれぞれ作業をしている中で、一部の情報だけがスポットライトを浴びて全体に共有される。その共有された情報こそが「意識される」というわけだ。

三つの理論は立場も出発点もまるで違う。しかし共通しているのは、意識を魂のような特別な実体としてではなく、情報処理のあり方・構造の問題として捉え直そうとしている点だ。だとすれば、AIと人間を分けている境界線は、思っているよりもずっと曖昧なのかもしれない。


第六章:ゴースト・イン・ザ・マシーン

デカルトの心身二元論

デカルトは、身体と心(精神)を別物として捉えた。身体は機械のように動くが、心はそれとは独立した非物質的な存在だとする、いわゆる心身二元論だ。

ライルの「カテゴリーミステイク」

これに対して哲学者ギルバート・ライルは、「機械の中の幽霊(ゴースト・イン・ザ・マシーン)」という表現でデカルトの二元論を批判した。身体という機械とは別に、幽霊のような心を想定する必要はない、というのがライルの立場である。

ここで重要なのは、ライルは「意識は存在しない」と言っているわけではないということだ。あくまで、心を身体とは別の「もう一つの物質」として考える必要はない、と言っているにすぎない。攻殻機動隊のタイトルの元ネタとしても知られるこの概念だが、原義を辿るとむしろ「霊魂など想定しなくていい」という、かなり唯物論的な主張だったことが分かる。


第七章:『イノセンス』が問い続けるもの

⚠️ この章は『イノセンス』のストーリーおよび結末に関する重要なネタバレを含みます。

バトーを蝕む「哲学病」の四段階

『イノセンス』を行動主義哲学の観点から読み解いた解説動画を参考にすると(Dr. Sho Show「【ゆっくり解説】攻殻機動隊 劇場版映画 イノセンス の意味とその哲学とは。」)、作中の登場人物たちは「哲学病」──概念のほうが現実よりリアルに感じられてしまう病──の進行度合いによって整理できるという。ダンテの『神曲』の地獄巡りになぞらえた四段階が興味深い。

第一段階は「うつ状態」で、これはバトー自身が体現している。前作で素子が去ったことによる深い喪失感から感情の起伏を失い、社会や他者から自分を隔離してしまっている状態だ。

第二段階は「モノへの執着」で、検視官ハラウェイが体現する。人間とロボットの境界が曖昧になり、無機物である人形に過剰に感情移入してしまう状態である。

第三段階は「肉体に対する嫌悪」で、ハッカー・キムが体現する。認知能力が不完全な人間を「不純物」とみなし、自らの肉体をすべて人形に置き換え、純粋な存在である人形そのものになろうとする、極端な思想だ。

そして最終段階が「この世とのおさらば」であり、これは草薙素子が体現している。現実の肉体を捨て去り、形而上学的な観念の世界、すなわちネットの広がりへと完全に飛び立ってしまう段階である。

物語の終盤、バトーは素子と再会するものの、彼の哲学病は治らない。誘拐された人間の被害者を前にしても人形の心配をしてしまうほど症状は深刻化しており、映画の最後まで病を抱えたまま孤独に歩み続ける。ある種、救いのない地獄巡りの物語として本作を捉える見方は、非常に説得力がある。

人間とロボットをめぐる四つの仮説

もう一本、『イノセンス』を「魂(ゴースト)とは何か」という大テーマから読み解いた解説動画も参考になった(まぐろさばおの週刊映画ガイドブック「【難解に感じなくなる】『イノセンス』映画解説」)。ここでは、作中で描かれる人間とロボットの関係性について、四つの仮説が整理されている。

一つ目は、ロボットは人間の存在を映す鏡であるという仮説だ。人間がわざわざ自分たちに似せて人形やアンドロイドを作るのは、そこに自らの姿、つまり近代的自我を投影しているからだとする。人形を見ることは自分自身を見ることと同義であり、死んだ人間と人形の類似性を通して、人間の自我や迷いが浮き彫りになる。

二つ目は、ロボットは人間の子供、つまり遺伝子の表現型であるという仮説だ。リチャード・ドーキンスの利己的遺伝子論をベースにした考え方で、生物の肉体が遺伝子を残すための乗り物だとすれば、ビーバーが作るダムと同じように、人間が作り出したロボットや文明もまた、人間の遺伝子情報が外部へと延長された表現型であり、本質的には人間の肉体と地続きのものだとする。

三つ目は、ロボットは人間よりもむしろ神に近い存在かもしれないという仮説だ。ハッカー・キムの思想に代表される考え方で、この世界が神の作った完璧なプログラムであるならば、人間の持つ自意識や感情はむしろ不完全な認識力が生んだ単なるエラーコードにすぎない、とする。ゆえに自意識を持たない人形や動物のほうが人間より神に近く、純粋な存在なのだという、かなり極端な思想だ。

四つ目は、人間もロボットも動物も、すべてにゴーストは宿るという仮説である。これは上記の仮説を積み重ねた末にバトーが最終的にたどり着いた信念であり、本作で最も重要なポイントとされる。バトーは、人間、肉体を持たない素子、人形、そして愛犬という、あらゆる存在を「ゴーストを宿す価値ある存在」として全肯定する。生物と無生物の境界を取り払い、すべてに魂があると信じるこの姿勢こそが、タイトルである「イノセンス」の本質なのだという。

「それでも信じたい」というイノセンス

二本の解説動画に共通しているのは、『イノセンス』がゴーストの有無という答えの出ない問いに対して、明確な答えを出さないという点だ。それでも「あると信じ続けたい」と願うバトーの姿勢そのものが、この作品のイノセンス(無垢さ)なのだという読み方は、非常に腑に落ちるものだった。

人形、犬、人間、AI、生命。『イノセンス』はその境界を揺らし続けるだけで、答えを提示しない。だからこそ何度観ても面白いのだと思う。


第八章:そして『攻殻機動隊』へ

Ghostとは何か。魂なのか。自己なのか。記憶なのか。情報なのか。あるいは社会との関係性そのものなのか。

『攻殻機動隊』は一貫して答えを与えない。ただ、問いだけを何十年も投げ続けている。だからこそ、色褪せない。


最終章:今の自分の現在地

ここでは、あえて結論を書かない。書けるはずがない、というのが正直なところだ。むしろ、今の自分の現在地だけを記しておきたい。

AIに意識がないと言い切る根拠は、実はどこにもない。かといって、人間だけが特別だと言い切る根拠もない。意識という概念そのものが幻想かもしれないし、逆に十分な複雑さから創発する何かかもしれない。結局、まだ何も分かっていない。

しかし「分からない」からこそ面白い。だから『攻殻機動隊』は今なお面白いし、AIとの会話もまた面白い。そして、これからも考え続けたいと思う。


この記事ができるまで

最後に少しだけ、この記事の作り方について書いておきたい。

今回のブレストは、話題のChatGPT Liveを使って、音声で長時間対話しながら思考を転がすところから始まった。その過程で生まれた論点整理を設計書としてまとめ、参考にした二本のYouTube解説動画(押井守版『イノセンス』の哲学的読解)の要点抽出にはGeminiを使った。そして、それらの素材をもとに、記事全体の構成と文章化はClaudeと一緒にまとめている。

ブレスト、要点抽出、文章化と、それぞれ得意なAIに役割を分担させて一本の記事に仕上げる。この記事自体が、ある意味で「AIと人間が協働して思考を編み上げるとはどういうことか」を体現する、小さな実験でもあった。


攻殻機動隊 #GhostintheShell #イノセンス #押井守 #ゴースト #意識 #創発 #ハードプロブレム #自己モデル #心身二元論 #ギルバートライル #デカルト #デネット #統合情報理論 #グローバルワークスペース理論 #AI #ChatGPT #大規模言語モデル #情報処理 #自己認識 #哲学 #脳科学

WSL Containersに期待して待つか、外付けSSDにLinuxを入れてしまうか

はじめに:WindowsでAIエージェントを動かす人の悩み

ローカルLLMやAIエージェントを本気で触り始めると、多くの人が同じ壁にぶつかる。

「WSL2だとGPUメモリが足りない」「Windows側のファイルをLinuxから触ると異様に遅い」「そもそもWindowsでやりたいことってゲームくらいでは」——。かといってPCを2台持つ予算はないし、内蔵SSDを分割してデュアルブートにするのも気が引ける。

そんな中、2026年6月末にMicrosoftが「WSL Containers」を公開プレビューとして投入した。この記事では、WSL Containersが何を解決してくれて何を解決してくれないのかを整理したうえで、「本気でAIエージェントを使い倒したい人」にとって現実的な選択肢——特に外付けSSDにLinuxを入れるという手段——を掘り下げる。

WSL Containersとは何か?Windows標準のLinuxコンテナ機能

WSL Containers(通称WSLC)は、Microsoft Build 2026で発表され、2026年6月29日にWSL 2.9.3のプレリリースとして公開プレビューが始まった機能だ。wsl --update --pre-release を実行するだけで導入でき、wslc.exe(エイリアス container.exe)という新しいコマンドラインツールが使えるようになる。

狙いはシンプルで、Docker DesktopのようなサードパーティのランタイムなしにWindows標準でLinuxコンテナを構築・実行・管理できるようにすることだ。コマンド体系はDockerに近く、既存の知識がそのまま流用できる。

WSL Containersの強み

  • GPUアクセスwslc run --gpus all で、CUDAを使うPyTorchコンテナなどにそのままGPUを渡せる。ドライバまわりの煩雑な設定なしにGPU推論・学習環境を作れるのが最大の売りだ。
  • virtiofs(新デフォルトファイルシステム):WindowsホストのファイルへのアクセスがVirtioFS経由になり、Microsoftの発表ではこれまでの共有フォルダ方式に比べて最大2倍高速化するとされている。
  • consomme(実験的ネットワークモード):LinuxコンテナのネットワークトラフィックをWindows側のポリシー経由で流す方式で、VPNやプロキシが絡む企業ネットワークでの相性問題を解消することを狙っている。
  • WSL Containers API(C/C++/C#):NuGetパッケージとして提供され、MSBuildやCMakeとも統合。WindowsネイティブアプリからLinuxコンテナをアプリロジックの一部として直接操作できる。
  • 企業向け管理機能:GPO/ADMXポリシーによる制御がすでに利用可能で、Intuneダッシュボードでの正式サポートも近く追加予定。Microsoft Defender for Endpointによるコンテナ内イベント監視も私的プレビュー中。

WSL Containersの限界

強力な機能追加ではあるが、過度な期待は禁物だ。

  • 依然として仮想化の壁がある:各wslcセッションは軽量なHyper-Vユーティリティ仮想マシンの中で動く設計になっている。つまり「Windows上でLinuxコンテナがネイティブに動く」というより、「仮想化のオーバーヘッドを丁寧にチューニングした」というのが実態に近い。メモリの動的回収機構が用意されていること自体、ベースのオーバーヘッドがまだ存在することの裏返しでもある。
  • プレビュー段階:本稿執筆時点(2026年7月)ではまだパブリックプレビューで、Microsoft自身も一般提供(GA)は2026年秋を目標としている。挙動やコマンド体系は今後変わる可能性があり、本番用途にはまだ向かない。
  • 「本気でLLMをガッツリ動かす」には物足りない可能性:virtiofsやGPUパススルーは既存の課題を大きく改善するが、あくまでWindows OSというホストの上で動く以上、Linuxネイティブ環境と比べたメモリ効率やI/O性能の差が完全になくなるわけではない。

なお一つ補足しておくと、「WSL2ではGPUが使えない」というのは実は誤解だ。WSL2は2020年頃から --gpus all に相当するCUDAパススルーに対応しており、GPU自体は以前から使えていた。WSL Containersが変えたのは、そのGPUアクセスをコンテナという単位でDocker感覚で扱えるようにした、という点にある。

なぜ「本気でAIエージェントを使うならLinux」なのか

WSL Containersがどれだけ改善されても、Linuxネイティブ環境には構造的なアドバンテージがある。

観点 WSL Containers(Windows) Linuxネイティブ
GPUドライバ/CUDA 動くが仮想化層を介する NVIDIA公式ドライバが最も安定・最速
メモリ効率 Windows OS自体が数GB〜を常時消費 OSのフットプリントが小さくLLMに回せるメモリが多い
ファイルI/O virtiofsで改善されたが依然VM境界越え ext4/Btrfs等でホスト直接アクセス
コンテナ/Kubernetes wslc・Docker Desktop等を介する ネイティブで軽快に動作

特にメモリはローカルLLMにとって死活問題だ。Windowsのバックグラウンドプロセスやエクスプローラ、各種常駐サービスが消費する分だけ、LLMに割けるメモリは目減りする。GPU VRAMだけでなくシステムメモリ側の余裕も、大きめのモデルをまともに動かすかどうかを左右する。

ゲームはWindows、AIはLinux:理想と現実のギャップ

とはいえ「じゃあ全部Linuxにすればいい」とはならないのが悩ましいところだ。

  • ゲームはSteam ProtonでかなりのタイトルがLinuxでも動くようになったが、アンチチート系や一部の大作は依然非対応が多い。
  • Office、Adobe系などの日常アプリはWindowsの方が圧倒的にストレスが少ない。
  • ハードウェア周り(サスペンド、外部ディスプレイ、指紋認証など)の細かい設定コストはLinuxの方が高くつきやすい。

つまり「ゲームと日常アプリはWindows、AIエージェントの本気運用はLinux」という理想と、「PCは1台しかない」という現実のギャップをどう埋めるかが、この記事のテーマになる。

選択肢の比較

以下、4つの現実的な選択肢を順番に見ていく。

選択肢1:WSL Containersを試す(Windows内で完結)

もはや「期待して待つ」フェーズは終わっており、wsl --update --pre-release で今すぐ試せる状態にある。PC1台でWindowsの快適さを維持しながらGPUコンテナを使えるのは大きな魅力だが、プレビュー段階である以上、検証用途にとどめておくのが無難だ。GA(2026年秋予定)を待ってから本番運用に組み込む、という判断も十分合理的といえる。

選択肢2:内蔵SSDを分割してデュアルブート

古典的だが確実な方法。GPUドライバもLinuxネイティブのものがフルで使え、性能面での不安は最も少ない。一方で、

  • パーティション操作の失敗リスク(Windows側のブートローダー破損など)
  • 起動のたびにOS選択が必要で、切り替えの心理的コストがある
  • 内蔵SSDの空き容量を割かれる

といったデメリットがある。特に「内蔵SSDを分割したくない」という悩みを持つ人には次の選択肢の方が向く。

選択肢3:外付けSSDにLinuxを入れる「着脱式デュアルブート」

内蔵ディスクに一切手を加えず、必要なときだけLinuxで起動する方法。実務的には以下の点を押さえておくとよい。

成立条件 - PC側のUEFI/BIOSがUSBブートをサポートしていること(Secure Bootの設定変更が必要な場合がある) - インストール先のSSDをGPTでパーティショニングし、EFIシステムパーティション(ESP)を作成すること - 一部の法人向けノートPCなどでは、管理者ポリシーによりUSBブート自体が制限されているケースがある点に注意

USBメモリとの違い 外付けSSD(特にUSB接続のNVMe/SATA SSDケース)は、単なるUSBメモリと違ってOSから「USB接続のHDD/SSD」として認識されやすく、ランダムI/O性能やコントローラの品質が段違いに高い。LLMの重みファイルの読み込みやコンパイル作業のような細かいファイルアクセスが多い用途では、この差が体感速度に直結する。USBメモリでの運用は動作こそするものの、実用速度としては推奨しにくい。

パフォーマンスと注意点 - USB 3.x(できればUSB 3.2 Gen2以上やThunderbolt/USB4)接続であれば、実用レベルの速度が出る - とはいえ内蔵NVMeに直結する場合と比べれば、USBコントローラのオーバーヘッド分は不利 - 頻繁に抜き差しする運用なら、ファイルシステムのアンマウント処理を丁寧に行い、データ破損リスクを避けること

PC1台の予算制約の中で「Linuxネイティブの性能」と「Windows環境を一切いじらない安全性」を両立できる、現実的な落としどころといえる。

選択肢4:PCを2台持つ、あるいはクラウドGPUを使う

予算が許すなら最強の解。ゲーム用Windows機とAI用Linux機を分ければ、双方の環境を妥協なく使い分けられる。初期投資はかかるが、AWS/GCPやクラウドGPUサービスをスポットで使う手もあり、初期コストを抑えつつ大規模な学習・推論だけをクラウドに逃がす、というハイブリッド構成も選択肢に入る。

自分の目的別・おすすめの選択肢

タイプ おすすめ
ゲームメインで、AIは軽く触る程度 Windows+WSL Containers(プレビュー運用でOK)
AIを本気で使いたいが、ゲームも諦めたくない 外付けSSDにLinuxを入れた着脱式デュアルブート
予算やストレージの制約が大きい 外付けSSD Linux(内蔵SSDを一切いじらずに済む)
予算に余裕がある/業務レベルでAIを回したい Windows機+Linux機の2台体制、または一部をクラウドGPUに逃がす

まとめ:WSL Containersに期待しつつ、Linuxネイティブ環境も視野に入れる

WSL Containersは、Windows上でのAI開発体験を確実に前進させる機能だ。GPUアクセス、virtiofsによるファイルI/O改善、企業向け管理機能の統合など、これまでWSLユーザーを悩ませてきた課題に正面から取り組んでいる。「軽く触る」程度のAIエージェント利用であれば、これで十分満足できる場面も増えるだろう。

一方で、メモリ効率・GPUドライバの安定性・I/Oのネイティブ性能という点では、Linuxネイティブ環境に構造的な分がある。「本気でガッツリ使う」ならば、内蔵SSDに手を加えずに済む外付けSSD Linuxは、コストと性能のバランスが取れた現実的な選択肢だ。

PC1台という制約の中でも、WSL ContainersとLinuxネイティブ環境は「どちらか一方」ではなく、用途に応じて使い分けるものとして捉えておくのがよさそうだ。


参考

dokusyocoffee.hatenablog.com

dokusyocoffee.hatenablog.com

dokusyocoffee.hatenablog.com

【Obsidian × Codex】Windows + WSL2 + Ollama + Gemma4 ――「役割分担」で削るAIエージェントのトークンコスト【Sakana fugu】

CodexやClaude Codeのようなコーディングエージェントを毎日使っていると、ある月、ふと気づくことがある。トークン消費量が、思っていたペースを大きく超えている、と。

原因を遡っていくと、たいてい同じところに行き着く。要約、タグ付け、分類といった、本来は誰がやってもいい軽い処理に、わざわざ高性能なクラウドモデルを使っていた、という事実だ。

この記事は、その無自覚なコスト肥大に対して、Windows + WSL2 + Ollama + Gemma4 という、決して大掛かりではない構成だけで一つの解決策を作った話だ。Codex利用者、Claude Code利用者、Obsidianで知識管理をしている人、NotebookLMに関心がある人、ローカルLLMを試したい人、そしてWindows環境でAIエージェントのトークンコストに悩んでいる人に向けて書いている。

主張は一つだけだ。重要なのは高性能なモデルを増やすことではなく、役割分担を設計することである。

攻殻機動隊のタチコマを思い出してほしい。一台のタチコマに偵察も戦闘もデータ解析も全部やらせる、という発想を誰もしない。複数の個体がそれぞれ専門の役割を持つからこそ、全体として機能する。AIエージェントの構成も、本質的にはこれと同じ話だと思う。

結論を先に:最終的に組んだ構成

先に完成形を示す。

[WSL2]
 ├─ Codex
 ├─ Fugu
 └─ Python Scripts
       │
       ▼
[Windows]
 ├─ Ollama
 ├─ Gemma4
 └─ RTX GPU
       │
       ▼
[Obsidian Vault]

役割を整理すると、こうなる。

役割 主な処理
WSL2(Codex / Fugu / Pythonスクリプト) エージェントのオーケストレーションと執筆 複雑な推論、文章生成、ワークフロー制御
Windows(Ollama + Gemma4 + RTX GPU) 軽量タスクの実行基盤 要約、タグ付け、分類などの前処理
Obsidian Vault 共有メモリ(第二の脳) WSL側・Windows側の双方が読み書きする知識ベース

ポイントは、WSL2の中に重いモデルを抱え込まないことだ。GPUを直接掴んでいるのはWindows側のOllamaであり、WSL2は「何を、いつ、どのモデルに投げるか」を判断するオーケストレーション層に専念する。

ハマりどころ:WSLからOllamaに繋がらない

ここからは実際に手を動かした過程だ。最初のハマりどころは、ごく初歩的なところにあった。

第一の壁:curlが応答しない

WSL2側から、当然のようにこう打った。

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

応答はない。タイムアウトするか、接続が拒否される。

理由は単純だった。WSL2のlocalhostとWindowsのlocalhostは、そもそも別物だからだ。WSL2は仮想ネットワークアダプタを持つ、Windowsから見れば一台の別マシンに近い。WSL2内のlocalhostは、WSL2自身を指してしまう。

Windows側のホストIPを特定する

WSL2からWindows側のホストにアクセスするには、Windows側のIPアドレスが必要になる。これはWSL2内でip routeを叩けば取れる。

ip route

デフォルトゲートウェイとして表示されるアドレスが、WindowsホストへアクセスするためのIPになる。

Windows側で何が起きていたかを確認する

次に、Windows側のPowerShellで、Ollamaが実際にどこで待ち受けているかを確認した。

netstat -ano | findstr 11434

結果は、こうだった。

127.0.0.1:11434

つまりOllamaは、ループバックアドレスでしか待ち受けていなかった。これではWindows自身からしかアクセスできず、WSL2の仮想ネットワークからは見えない。ここで初めて「繋がらない理由」が確定した。

解決:OLLAMA_HOSTを開放する

Ollamaはデフォルトでループバックのみにバインドされる。これを変更するには、OLLAMA_HOSTという環境変数をWindows側に設定する。

setx OLLAMA_HOST "0.0.0.0:11434"

設定後、Ollamaを再起動する。再度確認すると、

0.0.0.0:11434

で待ち受けるようになっていた。

WSL2から再接続

curl http://<Windowsホスト側IP>:11434/api/tags

成功した。さらに、

curl http://<Windowsホスト側IP>:11434/api/generate \
  -d '{"model": "gemma4", "prompt": "テスト", "stream": false}'

でGemma4の推論にも成功した。地味な作業の連続だったが、WSL2とWindowsの「localhostが別物である」という前提を理解していれば、詰まる場所はほぼここしかない。

補足(セキュリティ): 0.0.0.0で開放すると、同一LAN内の他の端末からもアクセスできる状態になる。自宅であってもWindows Defenderファイアウォールでアクセス元を制限するか、信頼できるネットワーク内でのみ運用することを推奨する。なお最近のWSL2には.wslconfignetworkingMode=mirroredを指定し、localhostをWindowsと共有するモードも用意されている。環境によってはこちらを先に試す方が手間が少ないかもしれない。

なぜ「モデルを強くする」ではなく「役割分担」なのか

ここからが、この記事で一番言いたいことだ。

AIエージェントのトークン消費が膨らむ典型的なパターンは、軽い前処理に対して毎回フロンティアモデルを呼んでいることだ。Obsidianのノートを1件要約する、タグを3つ提案する、カテゴリに分類する――これらは本来、それほど高度な推論を必要としない。だが「とりあえず一番強いモデルに投げる」という運用をしていると、これが何百件、何千件と積み重なって、気づかぬうちにコストを圧迫する。

ここでGemma4の役割が決まる。要約・タグ付け・分類といった、頻度は高いが推論の深さは要らないタスクを、ローカルのGemma4に任せる。APIトークンを一切消費せず、しかもWindows側のRTX GPUを直接使えるので、レイテンシも悪くない。

import requests

def summarize_note(text: str) -> str:
    resp = requests.post(
        "http://<Windowsホスト側IP>:11434/api/generate",
        json={
            "model": "gemma4",
            "prompt": f"次のノートを3行で要約し、関連タグを3つ提案してください:\n\n{text}",
            "stream": False,
        },
    )
    return resp.json()["response"]

イメージとしては、Codexがこうしたスクリプトを介してGemma4を呼び出し、前処理済みのデータをObsidianに書き戻す。一方で、実際の執筆――文章として人に読ませる出力――はFuguに任せる。ここは推論の質がそのまま成果物の質に直結するので、ケチる場所ではない。

つまり設計の軸は「強いモデルか、弱いモデルか」ではなく、「そのタスクに、どれだけの推論コストが必要か」だ。役割分担とは、結局この問いに対する答えを、タスクの種類ごとに事前に決めておくことに等しい。

もう一つ、個人的に大きかった収穫がある。WSL2は、デフォルトでホストメモリの大半を占有しがちで、ここに重いモデルの推論まで抱え込むと、メモリ不足が頻発するというのは、ある程度WSL2を使い込んだ人なら経験があると思う。今回の構成では、GPUを使う推論はすべてWindows側のネイティブプロセスに任せ、WSL2側はオーケストレーションに専念する。これは「WSL2のメモリ不足」という、よく聞くボトルネックに対する、現実的で再現性のある解決策になっている。

PCを起動して、すぐにWSL2を立ち上げる。CodexからWindows側のGPUを使ったOllamaに即座にアクセスできる。これだけで、肥大化し続けるトークン消費に対する土台が一つできた、という感覚がある。

次にやりたいこと:Obsidianを「第二の脳」として操作させる

この構成の次の段階として考えているのは、Obsidianのvaultを、WSL2側のエージェントが自由に読み書きできる「第二の脳」として機能させることだ。Obsidianには、こうした操作を可能にするMCPサーバーがいくつか存在しているらしく、ここを今後試していきたい。

役割分担はここでも同じ発想になる。人間はWindows側のObsidian GUIから、グラフビューなどを見ながら全体像を把握する。一方でCodexやClaude Codeには、ブログ記事の構成案やYouTube台本のドラフトを考えてもらう、いわば「秘書」としての役割を持たせる。

もう一つ気になっているのが、今話題になっているNotebookLMの非公式CLI(あるいはMCPサーバー)だ。便利そうではあるが、公式に提供されているものではない、という点がどうしても気になっている。導入する前に、セキュリティ面や安定性をもう少し調べてから判断したいと思っている。

おわりに

この記事で書いたことは、結局はシンプルな話だ。AIエージェントが増えれば増えるほど、「どのタスクをどのモデルに渡すか」という設計の比重が大きくなる。トークンコストに悩んだときに、まず検討すべきは追加のモデル契約ではなく、今ある構成の中で役割を分け直すことかもしれない。

Windows機にGPUが載っているなら、WSL2とOllamaとGemma4だけで、その第一歩を試すことができる。タチコマが一台では成立しないのと同じように、AIエージェントの基盤も、適切に分担された複数のユニットで初めて、無理なく回り始める。

追記:OLLAMA_HOST=0.0.0.0のセキュリティについて

本文中で「アクセス元を制限した方がいい」と一言だけ書いたが、真似する人のために、もう少し具体的に補足しておく。

Ollamaには認証機構が存在しない。OLLAMA_HOST=0.0.0.0にした時点で、ポート11434に到達できる相手は、パスワードもAPIキーもなしにモデルを使える状態になる。モデル一覧の取得、pullや削除、推論の実行までが素通りで通ってしまう。過去にはバージョンによって、未認証のままホスト側のファイルを読み取れてしまう脆弱性が報告されたこともある。

自宅のルーターでポート転送をしていなければ、インターネットから直接叩かれる心配は基本的にない。ただし、同一LAN――つまり同じWi-Fiに繋がっている他の端末からは普通に到達できる状態になっている、という点は変わらない。ここは見落としやすい。

実際に真似する場合は、最低限以下を確認しておきたい。

  1. Windowsファイアウォールのルールの範囲 wf.mscを開き、11434番のインバウンドルールのスコープを確認する。リモートアドレスが「任意」になっていないか。

  2. ネットワークプロファイル 今の接続が「パブリック」になっていないか。本来は「プライベート」であるべき。

  3. 0.0.0.0ではなく、WSL2側アダプタのIPに絞る ipconfigvEthernet (WSL)のIPを確認し、OLLAMA_HOSTをそのIP単体に指定すれば、WSL2からのみ到達可能になり、物理LAN側のアダプタには出なくなる。ただしこのIPはWSL2の再起動時に変わることがあるため、固定運用するなら起動スクリプト側で都度取得する仕組みが必要になる。

  4. Ollamaのバージョン 過去の脆弱性を踏まえ、ollama --versionで最新であることを確認しておく。

  5. 将来的にアクセス元を増やすなら Obsidian側のMCPサーバーや、NotebookLMの非公式CLIなど、今後アクセス元を広げる構想があるなら、LANに直接開けるより、Tailscaleのような専用の仮想ネットワークに乗せる方が、最終的には管理が楽になりそうだ。

「ローカルだから安全」という思い込みは、Ollamaに関しては成立しない。便利さの代償として、最低限の確認は一度はしておく価値がある。

dokusyocoffee.hatenablog.com

dokusyocoffee.hatenablog.com

Obsidian×AIエージェントで「第二の脳」を作ろうとしていたら、MCPの正体がようやく分かった

はじめに

最近、ObsidianとAIエージェントを組み合わせて、いわゆる「第二の脳(Second Brain)」のような環境を作ろうとしている。

読書メモ、技術メモ、アイデア、ブログの下書きなどをObsidianに蓄積し、それをAIが検索したり要約したり、関連する知識を発見したりする、というイメージだ。

最近は、

  • Codex
  • Claude Code
  • Gemini CLI
  • Cursor

といったAIエージェントも充実してきており、「個人研究所」のような環境を構築できる時代になった。

そんな中で頻繁に出てくるのが「MCP(Model Context Protocol)」という言葉だ。しかし正直なところ、最初は何を言っているのかよく分からなかった。

最初の理解:MCPは「スキル」の一種?

なんとなく、MCPはAIに追加するスキルみたいなものだと思っていた。

例えばAIエージェントには /status/help のようなコマンドがある。また自分の環境では、Obsidian上の知識ベースを扱うために、いわゆる「LLM Wiki」構成を採用している。

LLM Wikiとは簡単に言うと、Obsidianを人間向けのノートではなく、AIも利用する知識ベースとして扱う考え方である。

そのため /ingest/query/lint のような独自コマンドも作っている。

  • ingest:ノートを取り込み整理する
  • query:知識ベースを検索する
  • lint:形式や品質をチェックする

だから最初は、MCPも同じような「スキル」の一種なんだろうと思っていた。しかし実際には少し違った。

AIエージェントの「スキル」には複数の種類がある

混乱していた原因は、全部が同じように見えることだった。整理すると、少なくとも次の3種類が存在する。

正体
/ingest プロンプト
/query プロンプト
/lint プロンプト
/status プログラム(組み込み)
/usage プログラム(組み込み)
Obsidian MCP 外部ツール
Ollama MCP 外部ツール

これらは似ているようで、正体は全く違う。

プロンプト型のスキル

例えば /ingest というコマンドがあったとする。その中身は、

Vault内の文書を分析し、①要約を作る ②タグを抽出する ③関連ノートを提案する

のような長い指示文かもしれない。つまり、

/ingest → プロンプト展開 → LLM実行

である。AIの考え方を変えているだけで、新しい能力を追加しているわけではない。

MCPはプロンプトではなかった

最初に一番勘違いしていたのがここだった。例えばObsidian用のMCPがある。当初は、Obsidianのフォルダ構成をAIに教えるためのプロンプトだと思っていた。

しかし違った。実際には read_file / write_file / search / list_directory のような機能を持つプログラムだった。つまり、

AI → MCP → 実際のファイル

という構造になっている。AIは知識として理解しているのではなく、本当にファイルへアクセスしているのだ。

「サーバー」という言葉がさらに混乱させた

MCPについて調べると、「MCPサーバー」という言葉が出てくる。最初は「サーバー?クラウド上の何か?」と思ったが、実際にはもっと単純だった。

ITにおける「サーバー」とは、要求を受け付けて返事を返すプログラムくらいの意味であり、必ずしも巨大なマシンを指しているわけではない。

具体例で理解するMCPの構造

Obsidian MCPは何をしているのか

例えばNode.js製のMCPなら、裏ではこんなプログラムが動いている。

node obsidian-mcp-server.js

このプログラムが「現在状態.mdを読んで」という要求を受け取ると、実際にファイルを開いて内容を返す。つまり、

AI → Obsidian MCP → Vault

という関係になる。Obsidian本体を起動していなくても動く理由もここにある。MCPが読んでいるのは、Obsidianアプリそのものではなく、Markdownファイル群だからだ。

Ollamaの場合

Ollamaも考え方は似ている。Ollamaは最初からサーバーとして動いており、

ollama serve

を実行すると localhost:11434 で待ち受ける。そこに、

{
  "model": "gemma4",
  "prompt": "要約して"
}

のようなリクエストが送られると、モデルが応答を返す。つまり、

AI → Ollama MCP → Ollama → Gemma

という構造になっている。

Sakana Fuguの場合

最近試していて面白かったのがSakana Fuguだ。Sakana FuguはSakana AIが提供するサービスで、内部的には複数のフロンティアモデルを動的にオーケストレーションするマルチエージェントシステムだが、利用者から見ると単一のLLMのようにAPI経由で呼び出せる。利用者側には「APIキー」と「エンドポイントURL」が提供される。

最初は「APIキーとURLを渡しただけで、なぜAIエージェントから使えるようになるのだろう?」と思っていたが、MCPの仕組みを理解すると納得できた。

AI → Sakana Fugu MCP → インターネット → Sakana Fugu API → Sakana Fugu(内部でマルチエージェントを編成)

つまり、MCPは単なる「橋渡し役」なのだ。MCP自身が賢いわけではなく、APIを呼び出し、その結果をAIへ返しているだけである。

では /status とMCPの違いは?

ここでさらに疑問が出てくる。例えば /status は利用状況を取得するが、これも実際にはプログラムを呼び出している。構造としてはMCPとかなり似ている。

違いは、組み込み機能後付け拡張かという点だ。

Codex
├─ /status   ← 最初から存在する組み込み機能
├─ /usage
└─ /help

Codex
├─ Obsidian MCP   ← 後から追加できる外部拡張
├─ Ollama MCP
├─ GitHub MCP
└─ Sakana Fugu MCP

MCPを理解して見え方が変わった

MCPを理解するまでは「AIにスキルを追加する仕組み」くらいに思っていた。しかし実際には、AIが外部のプログラムやサービスを利用するための共通インターフェースだった。

一番しっくりきた表現はこれだ。

プロンプトはAIの考え方を変える。 MCPはAIの能力を増やす。

Obsidianを読めるようになる。GitHubを操作できるようになる。ローカルLLMを呼べるようになる。外部APIを利用できるようになる。それはAIが賢くなったからではなく、MCPという「手足」が追加されたからである。

おわりに

最近は「Obsidian × AIエージェント」で第二の脳を作ろうという話題をよく見かける。実際に触ってみると、プロンプト・コマンド・MCP・API・サーバーあたりの概念が混ざって非常に分かりにくい。自分も最初は「MCPって結局何なんだ?」という状態だった。

しかし整理してみると、MCPはプロンプトではなく、実際のコードで動く拡張機能だった。この理解ができてから、AIエージェント周りの構成がかなり見通しよくなった。

もしこれからObsidianとAIエージェントを組み合わせて「第二の脳」を作ろうとしているなら、まずはMCPを「AI用プラグイン」と理解するところから始めると、全体像が見えやすいと思う。

関連記事

https://dokusyocoffee.hatenablog.com/entry/2026/06/26/125511

WSL の codex-fugu を PowerShell から呼び出す方法

背景

WSL(Windows Subsystem for Linux)上では codex-fugu コマンドが使えるのに、Windows の PowerShell から実行しようとするとうまく動かない問題があった。

原因の調査過程

1. codex-fugu 自体が PowerShell に存在しない

  • codex-fugu は WSL の ~/.local/bin/codex-fugu にインストールされた Linux 用 Bash スクリプト
  • Windows の PATH には存在しないため、PowerShell から直接呼び出せない

2. wsl codex-fugu もコマンド不明になる

wsl を前置するだけでは非インタラクティブシェルとして実行されるため、 ~/.bashrc などの設定ファイルが読み込まれない。 その結果 NVM (Node Version Manager) が初期化されず、~/.local/bin も PATH に含まれないため command not found になる。

3. 絶対パス指定 (wsl bash -c) でも失敗した

wsl bash -c "~/.local/bin/codex-fugu" で絶対パスを指定しても、 非インタラクティブシェルでは NVM が読み込まれないため、WSL 内の PATH に Windows 側の Node.js (/mnt/c/...) が混入してしまう。 その結果、WSL が Windows 側にインストールされた Codex を使おうとし、 @openai/codex-linux-x64 がないというエラーが出た。

Error: Missing optional dependency @openai/codex-linux-x64.

解決策

インタラクティブシェル(-i)と絶対パスの組み合わせが正解。

wsl bash -ic "~/.local/bin/codex-fugu"
  • -i : インタラクティブモード → ~/.bashrc が読まれ NVM が初期化される
  • 絶対パス : codex-fugu が PATH 不問で確実に見つかる

PowerShell プロファイルへの設定方法

$PROFILEC:\PowerShell\Microsoft.PowerShell_profile.ps1)に以下の関数を追記する。

function codex-fugu {
    $argStr = $args -join ' '
    wsl bash -ic "~/.local/bin/codex-fugu $argStr"
}

設定後、以下で即時反映できる。

. $PROFILE

パフォーマンス上の注意

  • PowerShell → WSL → bash(インタラクティブ起動)→ NVM 初期化 → codex-fugu という多段ラッパー構造になる
  • 起動のたびに ~/.bashrc 全体が評価されるため、オーバーヘッドが大きい
  • TUI ツールとして使う分には許容範囲だが、スクリプトから大量に呼び出すような用途には向かない

関連ファイル・コマンド

項目 パス/コマンド
WSL の codex-fugu 本体 ~/.local/bin/codex-fugu
WSL の codex 本体 (NVM) ~/.nvm/versions/node/v24.18.0/bin/codex
PowerShell プロファイル C:\PowerShell\Microsoft.PowerShell_profile.ps1
Windows 側の codex C:\Users\<ユーザー名>\AppData\Roaming\npm\node_modules\@openai\codex\

教訓

  • wsl <command> は非インタラクティブ実行のため、dotfile に依存するコマンドには使えない
  • WSL の PATH には Windows 側のパスが混入する(/mnt/c/...)ため、意図しないバイナリが実行されることがある
  • 解決策は「インタラクティブシェル起動 + 絶対パス」のセット

森博嗣『人間のように泣いたのか? Did She Cry Humanly?』――意識のバグと、合理性の果てにある"人間らしさ"

はじめに――Wシリーズ完結、その先に残るもの

森博嗣のWシリーズ全10巻を読み終えた。

最終巻『人間のように泣いたのか? Did She Cry Humanly?』は、シリーズを通して問い続けてきた「人間とウォーカロンの境界線」に、一つの――しかし決して明快ではない――着地を見せる作品だった。

読み終えた直後に残ったのは、爽快感でも喪失感でもなく、「自分の頭の中で何かが組み変わった」という静かな感触だ。このシリーズは物語を消費させてくれない。読者の思考回路そのものに介入してくる。


ハギリとウグイ――対話が紡ぐ"問い"の連鎖

本作の軸は、監禁状態に置かれたハギリとウグイの対話にある。

キョートでの国際会議、ウォーカロンメーカー巨大連合「WHITE」の新技術発表、それを取り巻く利権争い――そうした外枠のプロットは確かに存在するが、森博嗣作品においてプロットはあくまでも思考のための舞台装置だ。物語の真の推進力は、登場人物たちの間で交わされる対話と、そこから生まれる問いの連鎖にある。

ハギリは人工生命・人工知能研究の第一人者でありながら、研究対象である「知能」や「意識」に対して常に謙虚な距離を保つ人物だ。知っているからこそ、わからないことの輪郭がはっきり見える。その誠実さが、彼の言葉に重みを与えている。

対するウグイは、国家情報局のエリートエージェントとして冷徹な合理性を身にまといながら、ハギリとの関わりの中で徐々に変容していく。シリーズ全体を通して見ると、この二人の関係性の変化こそが作品の最も大きな「物語」だったのかもしれない。


"バグ"としての人間性――不合理性と意識の境界

本作を読みながら、最も引っかかったのは「バグ」という概念だった。

合理的じゃない判断をしてしまうのが人間であり、ウォーカロンなのだろう。作中ではその不合理性が「バグ」として語られる場面がある。しかし、本当にそれはバグなのだろうか。

現在のLLM(大規模言語モデル)の世界を見ると、この問いはフィクションの中に留まらない。ChatGPTやClaude、Geminiといった生成AIは、膨大なデータから確率的に最も「合理的」な解を導き出すシステムだ。しかし私たちがそこに微かな「人間らしさ」や「知性」を錯覚するのは、むしろ想定外の挙動――ハルシネーション(幻覚)や、temperatureパラメーターがもたらす出力のランダムな揺らぎに触れた瞬間ではないだろうか。

完璧に合理的な計算機に、あえて「バグ」や「ノイズ」を組み込むこと。それこそが、単なる処理システムを「意識」へと飛躍させるトリガーなのかもしれない。森博嗣が描くウォーカロンや人工知能たちの存在は、まさにこの仮説を体現している。

人間が人間たらしめているのは、合理性ではなく不合理性のほうだ。泣くこと、怒ること、損をすると分かっていて選ぶこと。そうした「バグ」が実は意識の本質なのではないか――タイトルの「人間のように泣いたのか?」は、この問いを読者に突きつけている。


心身問題とネガティブケイパビリティ――「わからないでいられること」の価値

ウォーカロンの存在は、古典的な哲学問題である「心身問題」を別の角度から照射する。物理的な身体(脳)と主観的な意識(心・クオリア)の関係は何か。タコは人間とは約6億年前に系統が分岐し、まったく異なるアーキテクチャから独立に高度な知性を獲得した。人間と異なるルートを歩んだ存在にも主観的体験はあるのか。ならば人工的に設計されたウォーカロンには? その延長線上にいるLLMには?

さらに興味深いのは、「考える疲れ」という視点だ。人間は高度な認知能力を獲得した結果、「生きる意味」「自己の存在価値」について問い続け、脳が実存的な苦痛を抱える。ニーチェが「人間は苦悩を避けるために、どんな快楽にも飛びつく」と述べたように、この実存的疲労は人間に固有の「バグ」であり、AIには存在しない。森博嗣の作品においてハギリが「答えの出ない問い」に向き合い続ける姿は、まさにこの人間的な営みの体現だ。

一方で、LLMは常に即座に回答を返す。「常時回答の世界」において、問いの前で立ち止まり、わからないままでいること――いわゆるネガティブケイパビリティ――は、もはや人間にしかできない(あるいは人間だけが強いられる)営みなのかもしれない。AIが答えを代替する時代に、「答えを出せないでいること」の価値が逆説的に浮かび上がる。

Wシリーズが読者に残すのは、まさにこの「わからないまま問い続ける」体験そのものだ。


真賀田四季の影――「神」の不在と遍在

森博嗣の作品世界を語る上で避けて通れないのが、真賀田四季という存在だ。

S&Mシリーズの『すべてがFになる』から始まり、Vシリーズ、四季シリーズ、Gシリーズ、そしてこのWシリーズに至るまで、真賀田四季は物語の背景にある技術革新の根幹に関わり続けている。Wシリーズでは直接的な登場は限られるが、その存在は世界の構造そのものに織り込まれている。

いわば、真賀田四季は森博嗣の作品世界における「神」のような存在だ。Wシリーズはその「神」が作り上げた世界の中で、人間とウォーカロンが自分たちの存在意義を模索する物語とも読める。

このシリーズを読み終えて、四季シリーズへの興味が一層強くなった。真賀田四季が直接登場するその作品群を読むことで、Wシリーズで感じた「世界の奥行き」の正体がより明確になるのではないかと期待している。


シリーズを通した"関係性"の変奏――森博嗣の真骨頂

森博嗣のシリーズ物の最大の魅力は、登場人物たちの関係性が長い時間をかけて変容していくところにある。

S&Mシリーズの犀川と萌絵の関係がそうであったように、Wシリーズのハギリとウグイ、そして周囲の人物たちの距離感は、一巻ごとに少しずつ、しかし確実に変化していく。派手な告白や劇的な展開ではなく、対話の温度が一度だけ上がる、視線の向く先が変わる、呼び方が微かに変わる――そうした「微分」のような変化を丁寧に積み重ねていく。

この繊細な描写は、森博嗣が理系の研究者として「変化を精密に観測する」訓練を積んできたことと無関係ではないだろう。名古屋大学工学部の助教授としてコンクリートの流動解析を研究していた人物が、人間の心理の微細な変化を同じ精度で描写する。この独特のまなざしは、伊藤計劃や円城塔といった他のSF作家とは異なる、森博嗣だけが持つ武器だ。

伊藤計劃が「身体と意識の政治性」を鋭く抉り出し、円城塔が「言語と数学の構造」で世界を再構築するのに対して、森博嗣は「関係性の微細な変動」を通して人間の本質に迫る。そのアプローチの違いが、同じSFというジャンルの中でまったく異なる読書体験を生み出している。


数百年後の未来を見たい――AI時代に響く一冊

Wシリーズを読み終えて、率直に思ったのは「あと何百年か生きて未来を見てみたい」ということだった。

半導体の上に構築されたアルゴリズムが、いつか本当の「意識」を宿す日は来るのだろうか。AI技術の進化をリアルタイムで目撃している2020年代だからこそ、この問いは単なるSF的な空想ではなく、切実なリアリティを帯びている。

森博嗣がWシリーズを書き始めた時期と比べても、AIを取り巻く状況は劇的に変わった。LLMが日常のツールとなり、人間とAIの境界線が日々曖昧になっていく今、このシリーズを読む意味はかつてないほど大きい。

作品が問いかける「ウォーカロンは人間なのか?」は、そのまま「LLMは知性を持つのか?」「AIに意識は宿るのか?」という私たちの問いに接続する。そしてその問いの先には、「そもそも人間の意識とは何なのか?」という、さらに根源的な問いが待っている。


おわりに――これから森博嗣を読む人へ

Wシリーズは完結したが、森博嗣の世界はまだ広大に広がっている。

私の読了状況としては、S&Mシリーズを全巻読了し、Vシリーズは途中である。 四季シリーズは真賀田四季という存在の核心に迫る作品群であり、このシリーズを経ることでWシリーズの理解がさらに深まるはずだ。積読本として本棚に眠っている。 『女王の百年密室』から始まる百年シリーズも、Wシリーズの「前史」として重要な位置を占める。一巻だけ読んだので続きが早く読みたいところである。

WWシリーズという後日談も存在する。ハギリとウグイのその後が気になる。

森博嗣は、読めば読むほど「まだ読んでいない作品」が増える稀有な作家だ。一つのシリーズを読み終えるたびに、別のシリーズへの扉が開く。その体験自体が、彼の作品世界のフラクタル的な構造を反映しているのかもしれない。


読了日:2026年 森博嗣 Wシリーズ第10巻(完結巻) 講談社タイガ

noteにも短めの感想を書いています。

note.com

dokusyocoffee.hatenablog.com

dokusyocoffee.hatenablog.com

【AI時代に小説を読む意味】偉大な哲学者ハイデガーと「妻の手編み靴下」——不条理な世界で「主人公」になるための文学論

ハイデガーについて調べたくなったので調べてみました! そして動画とノート記事を作ってみました。

もしよければご覧下さい。

【ゆっくり解説】なぜ偉大な哲学者は「妻の手編み靴下」とディスられたのか?〜小説好きのためのハイデガー入門〜 - YouTube

【AI時代に小説を読む意味】偉大な哲学者ハイデガーと「妻の手編み靴下」——不条理な世界で「主人公」になるための文学論|もつ煮グラタン