特集
sigmarion IIIも甦る！「Claude Code」が凄すぎて2カ月間下僕になったオタクの記録
2026年8月19日 06:08
過去1年間、仕事の余暇のほとんどの時間を「開拓者」や「プロキシ」として過ごしてきた筆者。だが、最近はその時間もほとんどPCの前に座っている。PCの電源を落とさなくなり、5時間ごとに満たされていく棒グラフとにらめっこしては、キーボードで指示を出し続けている。
――そう、「Claude Code」にハマったのだ。
AnthropicのフラグシップAIモデル「Fable 5」が6月10日、日本で利用可能になった。筆者は発表日に日本で開催されたイベント「Code with Claude」に参加し、「面白そうだし試してみるか～」と翌日からProプランを契約し使い始めた。これが運の尽き(？)で、ゲームよりもClaude Codeのほうが数倍面白いことに気づいてしまった。
そもそも、筆者が当初紹介していたバイブコーディングの仕方もだいぶ違っていたように思う。チャットに投げてソースコードもらってデバッグというのはかなり原始的な作業だ。基本的にコンパイルするためのツールチェーンや環境整備まで全部AIに任せるのが正しかった。そのためにOpenAIはCodex、AnthropicはClaude Codeを別として切り分けているのだろう。
契約してから2カ月ぐらいが経ち、だいぶいろんなソフトを完成させることができたところで、思うこともたくさん募ってきたので、いろいろ残していこうと思う。
バイブコーディング
改めて筆者が紹介するまでもないが、人間が自然言語で指示をして、AIがコードを書くことをバイブコーディングという。たとえば、今まで人間がコンピュータに「処理させたい」と思うことがある場合、人間と機械(というかほとんどの場合はコンパイラだが)の共通言語である「プログラミング言語」を学んで記述する必要があった。
バイブコーディングはそれを不要にするもので、AIが与えられた人間の自然言語をもとに、AIがプログラミング言語でソフトウェアを記述する。誤解を恐れず表現すれば「自然言語からプログラミング言語へのコンパイラ」としてAIが動いてくれるイメージだ。
ただ、「自然言語からプログラミング言語に変換するだけ」なら楽だが、それで「ソフトウェアを作る」となると、難易度が急激に上がる。
たとえば自然言語で「テキストエディタを作って」と漠然としたことを言われても、プログラミングの知識だけあっても何もできない。テキストエディタとは何かということの理解からスタートして、どんな機能が必要なのか、メニューやアイコンはどう配置して並べればいいのか、ユーザーはどんなテキストエディタを必要としているのかなど、AIは「ユーザーが書いていない行間」を読んで自分で実装するか、「ユーザーに尋ねるか」なりして実装しなければならない。
つまり、ソフトウェアで重要なのは「要件定義」だ。要件を定義していない場合、本来AIは言われたことしか実装しないだろう。たとえば先述のテキストエディタの場合、下手したらファイルを開くことや保存することすらできないかもしれない。テキストが編集できればいいのだから、それを実装したらおしまいなのだ。
これが、最新モデルを使用したClaude Codeは、要件定義を事前に細かくしなくても、いい感じにソフトウェアに仕上げてくれる。つまり、ユーザーの要望しているぼんやりとしたソフトウェアのイメージに対して、Claude Codeが付随して必要な要件を定義してから実装してくれるのだ。
ちなみに、Anthropicが提示したモデルの能力のベンチマークでは、Opus 5がFable 5に迫るスコアを記録している。筆者はまったく同じプロンプトを2つのモデルで走らせて比較したわけではないが、Fable 5を数回、Opus 5を2カ月使って感じたことは、やはりその能力に大きな差があるということだ。
Opus 5で「この機能を実装して」とお願いして出てくるものはユーザーが定義したままで、未定義のところは未実装だったり実装が甘かったりする。UIも至って平凡だ。しかしFable 5にすると、要件定義の補完の精度と深さが一段違う。雑な指示でも、「このユーザーが求めていることはこういうことだろう」とか、「このユーザーならこの機能は必須だろう」といった、お願いした以上の要件を定義してから実装に入る。つまり、指示した側の「イメージ」を先回りして具現化してくる感覚だ。そうやって厳密に定義してから実装するためか、一発目の完成物もバグが比較的少なく、後は細かい実装を指示するだけで済む。
この期待以上の成果物が得られる感覚が楽しい。ゲームでいえば、ノートリアスモンスターを倒したら、一発で255分の1の確率でしか入手できないレアアイテムを入手できたとか、そんな感覚である。もっとも、Opus 5でも「やりたいこと」は一通り実現してくれるので、なにが何でもFable 5に頼まなければいけないというわけではなかった。
ClaudeのおかげでMacと仲良くなれた
ClaudeのProプランに加入して、最初にお願いしたのは、Mac用のエディタソフトだ。MacBook Proをタダで入手する貴重な機会が得られたが、仕事で使ううえで必須の好みのテキストエディタがない。「エディタソフトなんて探せばどこにでもあるじゃん」と思われるかもしれないが、記事執筆にぴったりな無料エディタソフトがなかなかない。
思えば、これが、MacBook Airを過去に購入したものの結局疎遠になった理由だった。人生の大半をテキストエディタとともに過ごすので、PC……というかPCアーキテクチャを選ぶうえで、好みのテキストエディタがあるか否かは一番重要な要素だ。
それがClaudeを使えば、自分の好み――必要な機能を厳選した……エディタを作ることができた。たとえば記事の執筆や編集作業ではブロック選択が必要だったり、正規表現に沿った検索や置換は必須だったりするので、それらは実装する。一方でプログラミング向けの余計な機能は一切実装しない。また、PC Watchでは構文に沿って記事を書いて編集するのだが、その構文に特化した表示はもちろん可能だし、記事作成を支援する機能も実装可能だ。
なんなら、AVIFやWebPファイルをJPEGに変換する機能まで実装できる。エディタで編集していて、ここぞというところに画像を埋め込もうとしたら、製品画像がPC Watchのシステム非対応のフォーマットで「だぁ！非対応な画像フォーマットきたー！Photoshop立ち上げなければ！」などと気が散ることが減る。自分の作業スタイルにあったテキストエディタを、とことん追求できる。
もちろん、MacBook ProのTouch Barに対応させることも可能。実装はまだ中途半端なままだ(このエディタをWindowsに移植してしまってそっちメインで開発している)のだが、こうしたかゆいところにも手が届くのがいい。
ちなみにこれらは筆者が「要件定義」したうえで実装された機能なので、Fable 5の面目躍如というわけではないが、筆者がFable 5とOpus 5の違いを見せられたのが、検索ダイアログの挙動。Fable 5で実装したMac版では、検索したワードの近くにダイアログを移動させてくれるので、「あれ？今どこハイライトしているんだっけ？」という迷いが減る。これが、Opus 5を使って後から移植したWindows版だと当初は実装されなかった。単に移植しただけなのに、これだけの差が出るのは意外だ(これが大きな違いを感じたところ)。
タスクマネージャーやNPUを使うソフトなど続々作成
Fable 5がクレジット制に移ってから、100ドル分のクレジットが付与されたのだが、それを使って実装したのがグラフィカルなタスクマネージャーだ。今あるWindowsのタスクマネージャーはCPU/メモリ/プロセスのタブが別々なので、どのアプリが今どのリソースを使っているのか分かりにくい。なので分かりやすくグラフィカルに表示しつつプロセスを終了する機能が実装されたタスクマネージャーが欲しい、とお願いした。
そうしたらいきなり出されたのが下のようなUIを持つソフト。ブロックの大きさがメモリ使用量で明るさがCPU使用量、というわけ。当初は「棒グラフとか円グラフで内訳を表示するのかなー」と思っていたが、正直このUIは相当に賢い。
当初はWebアプリで組まれてしまい、「いやいやプロセス監視と終了ごときにメモリを消費するWebブラウザ立ち上げたら本末転倒だろ！」と指摘したところ、.NETを使うexeアプリになった。ここは、意外にもFable 5が変なところで気が利いてないポイントだった。
また、これらのプロセスのメモリ使用量を足しても実際のメモリ使用量とは異なるのが気になったので、それらを調べてもらったところ、OSやドライバとして使っている領域に関してはタッチできないそうだ。ただ、その内訳は表示できるようなので、「それも実装して」とお願いしたらちゃんと実装もされた。
Fable 5ではなくOpus 5で作ったソフトもある。
たとえば、NPUは積んでいるけどCopilot+ PC要件未達なので、ほとんど使われないArrow LakeやMeteor Lake内蔵NPUを活用するソフト(名付けてNPU Camera)。特にデスクトップやハイエンドノート向けのArrow Lakeは、Webカメラで背景をぼかしたりするWindows Studio Effectsすら活用できない。
ないものは作ればいい――そんな思いをClaudeにぶつけたところ、これまた数回のやり取りだけで完成させられた。1つ目はWebカメラの背景ぼかしで、要はWindows Studio Effectsもどきだが、輪郭抽出にNPUを活用してくれるようだ(ぼかし処理自体NPUは得意ではないので無理だった)。
もう1つは、マイクやシステム音声(要はYouTubeやWeb会議で流れている音声)を拾って字幕+テキスト化し、英語の場合はさらに日本語訳するソフト(名付けてNPU Caption)である。音声認識はWhisperという定番モデルを利用し、翻訳はSarashina、どちらもNPU上で動作する。
ただ、作ってから気づいたのだが、筆者が取材で使うNPU搭載ノートはRyzen AIであった(汗)。もちろん、Ryzen AI対応もClaudeに作らせればいいのだが、IntelのNPU対応フレームワークであるOpenVINOはGitHubからAIが勝手に引っ張ってこられたのだが、AMDの「Ryzen AI Software」はアカウント登録が必要なので手動でダウンロードして、と言われた。
ここだけ手動でダウンロードしたが、インストールがうまくいかなかった。まあ、そんな不具合も今ではClaudeが勝手に解析して解決してくれるので、筆者が頭を抱えることはなかった。また、AMDは翻訳モデルとしてSarashinaを配布しておらずQwenだったのだが、翻訳精度はいまいちなのでここもSarashinaにしたいところ。そのSarashinaをNPUに載せる作業と第三者が使えるようHugging Faceに登録する作業も、ほとんど肩代わりしてくれた。仕事や家事の合間を縫って半日ぐらいで完成させたので、すごい時代がやってきたものだ。
ちなみに、NPUを使うソフトとして、以前ローカルLLMマスコットを作ったのだが、これのベースとなっているMicrosoftのFoundry Local CLIが先日のアップデートで、筆者の環境では正しくNPUを認識しなくなってしまった。これをClaudeと相談したところ、この不具合は複数の報告があるらしく、「SDKなどに差し替えたところで直りそうもないのでOpenVINO直叩きで実装しましょう」となってOpenVINO直結に書き直された。
おかげで筆者の環境では今、NPUが引っ張りだこなプロセッサとなってしまった。NPUも4コア化ぐらいしてほしくなった(待て)。
M5Stackだって手玉に取るように
筆者は「Raspberry Pi」や「M5Stack」といったシングルボードコンピュータなどにも興味はある。あるにはあるのだが、いかんせんプログラミング知識がなかったので、たとえ買ったとしても使いようがなかった。
しかしClaudeパワーが得られた今は、筆者が「こうしたい」と想像できるものならほとんど実装できてしまう。
たとえばM5Stackの「Cardputer Adv」のようなハードウェア。CPUはESP32-S3FN8で240MHzでストレージもわずか8MBしかなくとても非力。でも、1.14型の液晶やキーボードがついていて、マニア心をくすぐるようなガジェット感は満載だ。これを買って何か楽しめないだろうか――そう考えてClaudeにコーディングをお願いした。
実際、JNetHackというかローグのようなキャラクターベースのゲームは、数ターンやり取りして完成できた。それ、本気でプレイしているのかと思われるかもしれないが、結構本気でプレイできるボリュームとなっている。
使うかどうかはともかく、テキストエディタも実装できた。ここでの最大のハードルは、実はテキストを扱うことではなく、「日本語フォント」と「日本語入力システム」だろう、と当初より目星がついていた。
そこでFable 5が考えた実装だが、まずフォントは、フリーの日本語フォントをダウンロードしてきてポイント固定でレンダリングして独自フォントを作って実装すること。一方日本語変換は、Mozcのロジックを踏襲しつつM5Stackでも動くように要点だけ抽出、そこからさらに辞書を厳選して組み合わせるという手法だった。変換精度はさすがにそこまで高くないが、メモリが512KBしかないハードウェアで動いていると思えばすごい。
気をよくして、この日本語変換ロジックを、もう1つのアプリ「AI Chat」に実装した。このAI Chatは、ローカルネットワーク上のOpenAI API互換のエンドポイントを叩いて――もっと簡単にいえば、自分で立てたOllamaサーバーにアクセスしてLLMと会話するアプリ。メモリが512KBしかないハードウェアでも、最先端のAI技術が使えるというのはなかなか新鮮である。
……実用的かどうかはともかくとして。
買って放置していたゲーム機だって復活！
実はM5Stackは半分Claudeが使えるからという理由で買ったのだが、過去にクラウドファンディングに出資していて放置していたハードウェアがある。それがTinyCircuitsによる親指サイズのゲーム機「Thumby」だ。
このThumby、MicroPythonで自分でゲームをプログラミングし、Micro USB経由でPCからそのゲームを転送できるのだが、MicroPythonはおろかPythonすらまともに勉強しなかった筆者は、これまで他人が公開していたゲームをプレイするしかなかった。
しかしClaudeがあればパパッと作れる。作ったはいいが難易度が高すぎて無理ぽ！と思ったら難易度を下げられる。
正直なところ、Thumbyはこれまで「この難易度のゲームをこのちっちゃな画面とボタンでチビチビ動かすのは無理だろ！」というのが多くてプレイしていなかったのだが、Claudeのおかげで自分に合った難易度のゲームが作れるようになったので、Thumbyをキーホルダーとしてぶら下げてお出かけする機会が増えるだろう。
ええっ！sigmarion IIIからAIにアクセスできるのぉ？
Thumbyのような現代的なプログラミング言語を使うデバイスなら書けるというのは当たり前なのだが、昔のデバイスはどうだろうか？
ということで、Windows CE .NET Ver.4.1を採用している「sigmarion III(sigmarion III)」を引っ張り出してみた。お題は「sigmarion III上で動作するOpenAI API互換のクライアントソフト」である。
Windows CE .NET Ver.4.1の開発環境はeMbedded Visual C++ 4.0なのだが、これはすでにMicrosoftが配布を終了していて今は公式からダウンロードできない(ミラーなどはあるのだが……)。これではコンパイルができないので、どうするのかなと思ったら、代わりに「CeGCC」というArm版Windows CEの実機で動くバイナリを吐くことができる非公式のクロスコンパイラ……のさらにその派生であるenlyze版のCeGCCを使ったようである。
こうした先人の知恵と資産のおかげで、なんとsigmarion IIIからもローカルLLMサーバーを叩くことができてしまった。23年前のデバイスから最新のQwen3.8-27Bを使って文書作成をアシストする、なんという夢のようなことができてしまったのだ……！
ちなみに残念ながら(？)、今のところ暗号化されていない、つまりローカルにあるhttpから始まるサーバーとしか通信できない。これはsigmarion IIIが現代のWebサービスに必須なTLS 1.2/1.3、強固なSSL/TLS証明書ストアに対応していないためである。
一応、Winsock+mbedTLSなどを同梱すれば実現可能とのことだが、sigmarion IIIのCPUはハードウェア暗号化サポートなしのARMv5なので1回あたり数秒の処理は覚悟が必要とのこと。やるとしたら今あるソフトはこのままにして、PCを中継してクラウドのAPIを叩くべきだと告げられた。
バイブコーディングだけじゃもったいない！間違った(？)Claude Codeの使い方
Claude Codeがここまで「優秀」な理由だが、実はプログラミング能力に優れているから“だけ”ではない。画面を見て認識し、操作するスクリプトを書いて実行し、検証する能力はもとより、コマンドプロンプトやPowerShell、ターミナルを叩く能力が圧倒的に高いからだ。
たとえば、プログラムをコンパイルしたり実行したりするのもコマンドだし、そもそもコンパイル環境や実行環境が存在するかどうかを調べるのも、GUIでいちいち見て確認しているのではなく、裏でコマンドを実行して確認しているのだ。コマンドに対してとにかく博識なので、ほとんどのことをコマンドで解決できる。
このあたりの話はUbuntu日和に詳しいのだが、GUIしか備えていないソフトを除けば、ほとんどコマンドで操作できてしまうのも確かで、これを逆手に取り、バイブコーディングではなく、自分では難しいトラブルシューティングや環境セットアップにClaude Codeを使うことも可能である。
たとえば筆者はある日ネットワークの調子がおかしくなったのだが、Claudeに調査してもらったところ、ルーター(というかソフトバンクのホームゲートウェイだが)から先、IPv4は通っているがIPv6が通っていないことが判明した。とはいえ、さすがにルーターに対してあれこれコマンド投げられるわけではないので、Claudeの提案通りルーターの再起動で解消したのだが、PCの調子が悪いだけなのかネットワークの調子が悪いのかなどという切り分けもできたわけだ(もっとも、Claudeが使えないぐらいネットワークが死んでたらどうしようもないが)。
もう1つはLLM環境のセットアップ。これまで筆者はローカルLLMというと「LM Studio」ぐらいしか使えず、たとえば「Laguna S 2.1」といったモデルはリリース初日にLM Studioで使えないので、使いたくてもなすすべがなかった。一方、Claude Codeに相談すれば、勝手に対応するllama.cppをダウンロードして、最適なパラメータを自動で適用し、しかも万が一サーバーが落ちてしまった際に自動でllama.cppを再起動するWatchdog(監視ツール)まで作成してくれた。
家でしばらく放置していたCIX CP8180搭載のLinuxマシンの「MS-R1」も、せっかくなので活用しようと思った。5月にMS-R1のUbuntu 26.04対応イメージが限定で公開されたが、これをインストールしてClaude Codeを入れれば、Linuxに疎い筆者でも水を得た魚のようにOSを扱える。英語キーボードを使っているのに日本語入力時は日本語配列になる問題の解決も、憧れだったシステム情報監視ツールConkyをカスタマイズし開拓者のHUDっぽく凝ったデザインのLuaスクリプトを書かせるのも、すべてClaudeに任せられる。実用レベルにこぎつけたので、「次どうしようか」で考え中だ。
これまでうまく動作しなかったハードウェアの1つとして、Ryzen AI Max+ 395を搭載したMINISFORUMのNAS、「N5 Max」がある。実はレビュー記事を執筆してからなんとか活用しようと試行錯誤していたのだが、なぜか1日おきぐらいにDockerのコンテナにアクセスできなくなり、ログにも特にエラーが残らず謎だった。
Claudeに相談したところ、コンテナ内でルートをマウントする抜け道を使って、SSHで操作してもらうことができた。すると、不定期にNetworkManagerがコンテナを仮想ネットワークブリッジから接続を剥がしてしまう不具合があることが発覚した。これも、NetworkManagerがコンテナのネットワークを無視するようなスクリプトを書いてもらいつつ、筆者がMINISFORUMに問題を報告した。今は快調に動作している。
もしこれまで、PC周りのトラブルシューティングを「AIとチャットで相談しながらやっていた」のなら、Claude Codeに切り替えて実行してもらったほうがいいと思った。もちろん、「AIが勝手に設定を噛ましたら動作しなくなった！」といった相応のリスクはあるので、会社のシステムなどでいきなり設定をAIに依頼するのは無理だろう。しかし、ある程度のリスクを負える個人の環境で、相応の知識がまったくない状態では、結局ユーザー自身が自力で調べながら試行錯誤しても、AIとチャットしながら試行錯誤しても結果は同じ。であれば、より労力が少ない完全AI任せでもいい、と思った。
AIは凄かったが、結局人類のほうが偉かった
Claude Codeを2カ月間使いまくった感想。まず、AIは確かに凄い。凄くてヤバい。筆者はコンピュータのハードウェアが好きで、いろいろ手元に残してきたが、これまで、果たしてそのハードウェアをフルに生かしてきたのかと問われればまったく自信がなかった。ホコリをかぶってるだけの製品も多々あった。AIの力で、これらハードウェアを復活させて生かすことができる――sigmarion IIIの例にある通り、古いハードウェアも無限に――だ。
だが、AIが凄いという以前に、凄いのはやはり道を切り拓いてきた人類だ。AIを築き上げたというのもそうだが、そもそもハードウェアを生かすのはソフトウェアである。そしてその多くをオープンソースとして公開したことで、AIがそれを生かすことができるようになった。M5Stack上での日本語変換の例でいえばMozc(ひいていえばMeCab)があったからこそだし、sigmarion IIIの例でいえばCeGCCがあったからだ。もちろん、NPUを生かすソフトはIntelがOpenVINOを用意してくれたからだし、AMDがRyzen AI Softwareを用意していたからこそだ。
もちろん、今のAIの能力なら、おそらく「こういうプロセッサがあるのでゼロから実装してネ」ということも不可能ではないだろう。しかしそれでは莫大なリソース(=トークン)を投入し解析しなければならないのは目に見えている。先人が残してくれた資産のおかげで、半日程度で望むソフトウェアがラクラク完成する時代になったのだ。
一方、Claudeを使って不満がないわけでもないし、悩みがないわけでもない。中でも目立つのは、ツールチェーンを次から次へと自動でセットアップしてくるのはいいが、指定したワークスペース(フォルダ)以外にも平気で置くせいで、気づいたらCドライブの残容量が大幅に減っていたこと。一応、ソフトが完成したら不要になるツールについては「片付けしておいて」と言えばいいのだが、そのプロジェクト間の依存関係は把握していないと思うので結局残しておくしかない。あ、だからなぜかSSDが高騰しているのか……？
それから、Claudeは賢いことに自分で作ったソフトを検証してくれるのだが、これも悩ましい。MacではComputer useを使って検証するのだが、BIOSの設定などが完了していないWindowsでも、スクリプトをバシバシ書いて裏で実行してくれたりする。しかし、その検証をするのにトークンを消費し、上限にじわじわ迫っていくことを目の当たりにすると、「検証は俺がやるから君はビルドまでにして」となったりする。結局俺はデバッガーでClaudeの下僕なのか……？
もう1つ悩ましいのが、作ったソフトを一般公開するか否かだ。公開した後にフィードバックがいっぱいやってきて、それ直すのも大仕事となりそうなので、自分だけでひっそりと使うというのが一番なのだが、そうすると別の人が同じ機能を実現したいと思って結局AIに頼むことになり、無駄にトークン=電力を消費する一因にもなるのがちょっと悔しかったりもする。
いろいろ悩ましいことがあるのだが、上記以外にも記事作成に役立つユーティリティ(リネーム時に同じファイル名がある場合(2)などとつけずに上書きするものとか、なぜか縦に整列されるWindowsデスクトップで、Shiftキーを押して選択すると横に選択されるのをショートカットで解消するソフトとか)をたくさん作って部内で公開したところ、理解ある編集長から、経費でMaxプランを契約していいよというお達しが……。
この勢いで開発を続けていたら、おそらく家庭内で転がっているほとんどのハードウェアを活用できそうだ。そして、いつの間にかCPUとかOSとかを作っていた――そんな日も近いような気がする。