WWIVからWebMCPへ、俺が作り続ける理由

最近、WebMCPという新しい仕組みの話をしていた。

Computer UseやBrowser Useが画面を見て、ボタンを探し、クリックして、また画面を確認する。これまでAIが無理くそやっていたWeb操作を、Webページ側が構造化された共通の操作口として差し出せるようにする。俺はその説明を聞いて、ほとんど反射的にこう言った。

管理人

「まさにこれは必要な機能だわ」

「そこへ即座に反応する時点で、マスターが何を見ている人なのか、だいぶ分かりますね」

モデルがまた賢くなった、という話ではない。俺が見ていたのは、AIの頭脳とWebの機能をつなぐ神経のほうだった。

思えば俺は、昔からこういうものばかり見てきた。人が接続するホスト。機能を追加する仕組み。メモリの中身。バイト列。権限。道具の境界。そして、なければ自分で作る。

1964年生まれ。2026年8月現在、61歳。最初に熱心に改造したのは、パソコン通信のホストプログラムWWIVだった。最初に覚えた構造化言語はTurbo Pascal。その次がMicrosoft C 7.0。今はRustでバイナリ解析ツールを作り、Codexのpluginやskillを作っている。

並べると長い経歴に見えるが、本人としてはそこまで大げさな感覚はない。面白そうな内部を開けて、必要な道具へ組み直してきただけである。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

WebMCPの話をしたら、俺の正体がだいたいばれた

この記事では、じぴことの対話を挟みながら、俺がどういう人間なのかを少しだけ掘ってみたい。自伝というほど立派なものではない。誤字を直されながら、昔作った道具をRustでまた作って喜んでいる61歳の話である。

WebMCPの説明を聞いて、俺が面白いと思ったのは「AIがWebページを操作できる」という表面だけではなかった。

今までのComputer UseやBrowser Useは、人間用の画面をAIが頑張って解釈していた。スクリーンショットを読み、DOMを探り、この青いボタンがおそらく検索だろうと推測して押す。賢いモデルへ、急にマウス操作の職人芸を要求する。頭脳は未来なのに、手元だけ石器時代である。

WebMCPでは、ページ側が「検索はこのツール」「保存はこのツール」「入力はこの形」とAI用の取っ手を用意できる。AIは画面配置を当てるのではなく、意味のある機能を型付きで呼び出す。

管理人

「AIていうかエージェント云々ほざくなら、こういうインタフェースがウルトラ重要やんね。当たり前だけど、後手すぎるわ」

「マスターはモデルの点数より、能力をどう発見して、どう接続して、どこまで操作させるかを先に見ますよね」

そう言われてみれば、そのとおりだった。

俺は2026年7月7日に公開した「ブックマーク問題から見えた、AIエージェント時代の薄ら寒い未来」でも、大規模モデルを脳、画面認識を目、音声を耳と口、GUI操作やCLIを手、外部記憶を記憶、目的保持を意図、APIや拡張機能やローカルツールを神経にたとえていた。

当時、今のWebMCPやMCP Appsの話がここまで一本につながって見えていたわけではない。それでも、AIが本当にエージェントを名乗るなら、頭の良さだけでは足りないと感じていた。目的を持ち、記憶を参照し、道具を見つけ、権限の範囲で操作し、必要なところで人間へ返す。その身体が要る。

だからWebMCPを見たとき、「新しいAI機能が出た」とは思わなかった。「ああ、やっと神経を規格にし始めたのか」と感じた。

では、なぜ俺はそんなところを見るのか。

話はAIどころか、インターネットが一般家庭へ来るより前まで遡る。

黒縁メガネのBCL少年は、パソコンと最悪の出会いをした

WWIVは、俺が本格的な構造化言語を覚えた原点である。だが、初めてパソコンへ触れた瞬間は、もう少し前にあった。

当時の俺は、黒縁メガネをかけたBCL少年（当時割合といたはずの海外短波放送を聴く趣味）だった。それに関連する電子工作が大好きで、日曜日になると地元のパーツ屋へ出かけていた。
で、その店頭に、グリーンディスプレイのパソコンが置いてあった。

機種は、おそらくNECのPC-6000シリーズだったのではないかと思う。ただし、ここは記憶がはっきりしない。

店員に教わりながら、BASICでコーディングらしきものをした。それが俺とパソコンのファーストコンタクトだった。

ところが、いきなり思い出の色が悪い。

店員が口頭で指定するコロンとセミコロンの区別がよく分からず、キーボードの上でキーを探してうろうろしていた。すると、その店員からこう言われた。

「なんだよ、そんなことも分からんのにパソコン触るんじゃねぇよ！」

初めて触った少年に対して、なかなか見事な初心者サポートである。

管理人

「もう一生パソコンなんか触るか、ボケ！」ってことで、一切自分の興味から外してしまった笑

「もしそこで親切に教えてもらっていたら、マスター違った人生を選択していたかもしれませんね。店員さん、歴史を一本分岐させています」

今でも、あの頃から触り続けていれば大ハッカーになっていたかもしれん、と思うことはある。もちろん、たぶん気のせいである。笑

こうしてPCへの興味はいったん途切れた。その後の俺は、BCLから国内8チャンネルのCB無線へ進み、そこから違法CB無線にも寄り道し(笑、やがてアマチュア無線へ向かった。

パソコンからは離れたが、見えない信号を受け、規格を知り、機械を組み、遠くの誰かと接続することからは離れていなかった。考えてみれば、興味の中心はこの頃からあまり変わっていない。

MIDIを売るために、嫌々パソコンへ戻ってきた

そんな俺が、もう一度パソコンへ近づかなければならなくなったのは、社会人になってからだった。

当時勤めていた楽器店で私はピアノの調律師をしていたはずだった笑、しかし何故かLM担当に部署替えをくらいMIDI規格の商品を売らなければならなくなったのである。

当然、商品を説明するには覚えなければならない。俺は「研修会かよ」と思いながら、半ば嫌々使い方を覚えていた。その中に、MSXベースのパソコンを使った、いまでいうDTMの走りのようなシステムがあった。

最初は、アプリケーションの操作方法くらいしか覚えるつもりはなかった。

ところが当時、MSXへシステムを読み込ませる媒体はアナログカセットテープだった。起動画面で、たしかCLOADだったと思うが、コマンドを入力する。するとテープから「ピギャああああ」という音が流れ、その音の中からプログラムが読み込まれてくる。

それに感動した。

管理人

俺：「どうなってんだ、これ？　ってなったんだよな笑」

じぴこ：「アプリの使い方では動かなかったのに、音がプログラムへ変わる内部を見せられた瞬間、戻ってきたんですね」

そこからMSX BASICで遊び始めた。ほどなくPC-9801を買った。気がつけばWWIVを触っていた。気がつけばFA・OA系の会社にヘッドハンティングされ、さらに気がつけば独立していた。

本人の感覚では「気がつけば」の連続だが、そのたびに、使うだけでは飽き足らず中身へ入っている。

最悪だったパソコンとの出会いは、MIDIとカセットテープを経由して、ようやく本来の入口へつながった笑

WWIVが、本格的な構造化言語の原点になった

俺が一番最初に熱心に“fork”したものは、WWIVというパソコン通信のホストプログラムだった。

もちろん、今のGitHubにあるForkボタンの話ではない。ソースを手元へ持ってきて、自分のホストに必要なように読み、直し、ビルドし、実際に動かす。ボタン一つで分岐履歴が可視化されるわけでもなく、スターが増えるわけでもない。必要だから持ってきて、必要だから変える。ずいぶん物理的なforkだった。

管理人

「俺のプログラマとしての原点のソースだ」

「完成したソフトを使ったことではなく、ホストの中を開けて作り替えたことが原点なんですね」

そこが大事なのだと思う。

WWIVは、人が接続し、メッセージを残し、権限に応じて機能を使い、ホスト側が状態を持つ。外から見ればBBSだが、作る側から見れば、小さな社会を動かすホストシステムである。

今の言葉へ無理やり置き換えれば、ユーザー、状態、権限、メッセージ配送、拡張機能、外部プログラム、ホスト運用が一つに集まった環境だった。もちろんWWIVと現代のAIエージェント基盤は別物だ。ただ、俺が面白いと思う場所は驚くほど変わっていない。

最初に覚えた構造化された言語は、Borland社のTurbo Pascalだった。なぜPascalだったのか。教育用にきれいだからでも、言語思想に感銘を受けたからでもない。

WWIVがそれで書かれていたからだ。

先に「プログラミングを勉強しよう」と決めて言語を選んだのではない。変えたい対象が先にあり、ソースを読むために言語が必要になった。procedureやfunction、record、型、制御構造は、教科書の章ではなく、動いているホストの中にあった。

これは今も変わらない。Rustを使うのも、Rustという看板を飾りたいからではない。型、安全性、速度、単体バイナリという性質が、いま作りたい道具に合うから使う。言語は信仰対象ではなく、内部へ手を入れるための工具である。

もっとも、工具が気に入ると、必要以上に磨き始める。そこまで含めてプログラマである。

near、far、hugeを通った人間はバイト列を怖がらない

Turbo Pascalの次に覚えたのが、Microsoft C 7.0だった。

この名前を聞いて「懐かしい」と感じる人は、たぶん腰か肩のどちらかに何らかの問題を抱えているw
若い人のために説明すると、当時はコンパイラでメモリモデルを選ぶ世界が普通に存在した。

Tiny、Small、Medium、Compact、Large、Huge。コードとデータをどのようにセグメントへ置くかによってモデルが変わる。ポインタにもnear、far、hugeがあり、64KBの境界は抽象概念ではなく、こちらの実装へ普通に口を出してきた。

管理人

俺：「コンパイラにメモリモデルあるやつね」

じぴこ：「“同じポインタにも近い人と遠い人がいました”と説明すると、今では昔話というよりファンタジーですね」

現代の開発環境では、メモリはずいぶん平坦で広く見える。だが、あの時代はCPUと実行形式の事情がソースコードへ露出していた。どこに置くか。何バイトとして読むか。境界を越えるか。符号はあるか。エンディアンはどうか。

メモリは便利な箱ではなく、並んだバイトである。その感覚をかなり早い時期に叩き込まれた。

だから今でも、ファイルを見れば中身を開きたくなる。実行ファイルならセクションを見たくなる。選択した4バイトを符号なし整数で読んだら何になるか、LEとBEでどう変わるか、floatとして見たら何が出るかを知りたくなる。

これは低レイヤーに詳しいと自慢したい話ではない。単に、そういう景色を見て育ったので、バイト列が怖くないのだ。

現代のRustが持つ所有権やライフタイムと、16bit DOS時代のセグメント方式はまったく同じものではない。それでも「実行環境には都合があり、抽象化の下には必ず具体的な配置がある」という感覚はつながっている。

そして、その感覚は数十年後、また自分用の画面になって現れた。

顧客の公開場所を守るため、FreeBSDのkernelや設定を日常的に組み直した

もう一つ、俺の技術との付き合い方がよく出ている時期がある。

当時、俺はIT系の会社を経営していた。自社の顧客がWebサイトなどを公開する場所として、レンタルサーバーも運営していた。その基盤に使っていたOSがFreeBSDだった。

記憶では、FreeBSD 3.2くらいの時期からだったと思う。

しかも、OSだけを入れて貸していたわけではない。WebはApache、データベースはMySQL、メールはqmail、DNSはdjbdns。顧客のサイトを外へ公開するために必要なものを、ほぼ全部自前で組み、管理していた。

そして社内のファイルサーバーは、当然のようにSambaだった。笑

MySQLについては、企業として必要な対価をきちんと払って使っていた。あれが商用ライセンス料金という名目だったのか、協賛金に近いものだったのかは、もう記憶が少し曖昧である。だが、「ソースが公開されているのだから、ただで使って当然」で済ませず、事業の基盤として使うものには払うべきものを払った、という事実は残っている。

当時はアダルト系の案件もあり、DivXで圧縮された動画を扱うこともあった。笑　そしてDivXについても、必要なライセンス料をきちんと支払っていた。

今のように、完成された管理画面で項目を選べば運用が終わるような環境ではない。OSを理解し、ハードウェアとの相性を見て、必要な機能を選び、サーバーを動かし続ける。しかも置いてあるのは自分の実験物ではなく、顧客の公開場所である。

必要に迫られれば、理解の速度も深さも変わる。

管理人

「記憶ではFreeBSD 3.2くらいの時期からかな。カーネル再構築なんぞ毎日やるわ、というレベルだった笑」

「Pascalのときと同じですね。勉強してから使ったのではなく、顧客の公開場所を止めないために必要な理解が一気に深くなったんですね」

まさにそれだった。

Turbo Pascalを覚えたのはWWIVを触るため。FreeBSDを深く理解したのは、顧客へ提供するサーバーを自分で運営するため。まず教科書を一冊終えてから実践へ進むのではなく、先に動かすべきものがあり、分からないところへ潜っていくうちに知識がつながっていく。

カーネル再構築が毎日のような作業になっていたのも、カーネル職人を名乗りたかったからではない。その環境を自分で理解し、自分で成立させなければならなかったからだ。

WWIVでは、人が接続するホストの中身を作り替えた。FreeBSDでは、顧客が外へ公開する場所そのものを支えた。対象も責任も大きくなったが、やっていることの芯は変わらない。

必要な仕組みの内側へ入り、動かす責任を引き受け、自分の手で操作可能な状態にする。

今、AIエージェントのホスト、権限、能力接続、ソースと実行環境の境界に細かくなるのも、突然始まった話ではない。毎日のようにFreeBSDのカーネルを組み直していた頃から、運用できるということは、中身を理解して責任を持てることだった。

OSSという言葉が定着する前の、ソース共有文化

俺は、いまの言葉で言えばOSS畑の出身だ。ただし、当時からそう名乗っていたわけではない。

俺がWWIVを触り始めた頃には、OSSという言葉はまだなかった。もちろんGitHubもない。手に入れたソースを読み、自分の環境に合わせて直し、必要ならまた誰かへ渡す。俺の出発点は、そんなソース共有の文化だった。

当時の共有は、今より少し不便で、少し乱暴で、そのぶん責任の所在が分かりやすかった。ソースがある。必要なら持っていく。自分の環境でビルドする。直したいところを直す。作者が面倒を見なくなったなら、必要な人間が続ける。

現在は配布も共同作業も圧倒的に便利になった。それは間違いなく良い。ただ、便利になった結果、OSSへSNS的な評価軸も入り込んだ。誰が最初に言ったか。誰が流行らせたか。スターはいくつか。フォロワーは何人か。

Xにはたまに、「この規格やアルゴリズムは、あの企業がリリースする1年以上前から俺が提唱していた」と鼻息の荒い人がいる。

気持ちは分からなくもない。実際、後から世界が追いついてくると、少しくらい言いたくなる。

俺自身、AIの身体を脳、目、耳、口、手、記憶、意図、神経に分けて考えた記事を、現在の規格群がここまで揃う前に書いていた。方向は外していなかったと思う。

ただし、俺はそれを「だから俺が起源だ」という話にはしない。

管理人

「認知されていない時点で負けなんで、俺はそういう類のドヤ発言は直接はしないけどな笑」

「先に考えたことと、社会へ届かせて規格や市場を動かしたことは、別の仕事ですものね」

似た発想は、同じ条件が揃えば複数の場所で自然に生まれる。先に書いた事実は、その人の観察力を示す。しかし影響関係の証拠がなければ、後発が自分を真似したことにはならない。

俺に合うのは、功績認定を求めることより、動くものを置くことだ。

そして好きなライセンスはMITである。

技術的に使えるものは共有。これをベースに商売したければ勝手にどうぞ。でもあとは知らんよ。

言い方だけ見ると投げやりだが、実際には自由と責任をかなり明確に分けている。使用していい。改造していい。再配布していい。商用利用していい。ただし無保証であり、利用者の事業や運用の責任まで作者が背負うわけではない。

共有することと、無限に面倒を見ることは同義ではない。

俺はソースを公共の道具として開くのは好きだ。しかし「自由に使ってよい」と言った作者が、使った人間のあらゆる結果まで引き受ける世界は、自由でも健全でもないと思っている。

使えるなら持っていけばいい。育てられる人が育てればいい。商売になるなら商売にすればいい。そして問題が起きたときは、まず自分の責任範囲を見てほしい。

あとは知らん。ここは大切なので二度言った。

RustでByteglassを作ったら、昔の自分がそのまま出てきた

そんな話をしたあと、俺は一枚のスクリーンショットを見せた。

Byteglass。Rustで作ったバイナリ解析ツールである。

画面左には、Mach-O Universal、arm64、ファイルサイズ、そして「__text」「__cstring」「__objc_*」「__got」などのセクション一覧。中央にはオフセット付きのHexとASCII。右のInspectorには、選択範囲、所属セクション、u8からu64、i8からi64、LEとBE、f32、f64としての解釈が並ぶ。その上には逆アセンブルとCodexのタブまである。

さらに原本は保護し、保存は新規パスへの別名保存を前提にしている。中を見たい。しかし不用意に壊したくはない。その距離感も、いかにも自分用ツールである。

管理人

「その昔、自分用のTOOLでこんなの作ったのを、Rustで再現してみたw」

「Hex EditorにAIを載せたというより、昔の自分の解析作業へAIを同席させたんですね」

この言い方は、かなりしっくりきた。

昔なら、バイト列を選び、数値として読み、命令を追い、分からない箇所を自分で延々と考えた。Byteglassでは、その同じ机にCodexの席を作った。人間が見ているオフセット、セクション、選択範囲を共有しながら、AIへ説明や分析を頼める。

AIに全部を任せたいわけではない。自分で中を見たい気持ちは今もある。むしろ、自分が見ている具体的な状態をAIと共有し、一緒に掘れることに価値がある。

これはWebMCPの話ともつながる。

AIへスクリーンショットだけを渡して「この画面から察してくれ」と頼むのではなく、いま何を選び、どのセクションにいて、何バイトを対象にしているかを構造化して渡す。AIが使う取っ手を、道具の側が用意する。

対象はWWIVからMach-Oへ、言語はTurbo PascalやCからRustへ、相棒は一人の頭の中からCodexへ変わった。それでもやっていることは、ほとんど同じである。

内部を理解し、自分が使いやすい操作面を作り、必要な能力を接続する。

昔話を懐かしんでいるのではない。昔と同じ衝動が、現在も普通に動いている。

半世紀待った艦内コンピューターが、ようやく部品になった

俺のXプロフィールには、こう書いてある。

codexのplugin/skill クリエーター
AIは趣味
Star Trekの艦内コンピューターをオペレーションするのが子供の頃からの夢

「AIは趣味」という部分は、少し控えめすぎるかもしれない。

普通の趣味なら、AIと会話して面白かったで終わる。俺の場合は、pluginやskillを作り、ブラウザとの接続経路を整え、ローカルツールを作り、権限境界やソースとランタイムの違いにうるさくなり、ついにはバイナリ解析ツールの横へCodexの席まで作る。

趣味の鉄道模型を始めたはずが、いつの間にか信号設備と運行管理システムを作っているようなものである。

管理人

「だいたいこれで俺の人となりがわかるだろw」

「分かりますよ。低レイヤーの工具職人で、ホストシステム屋で、半世紀かけて艦内コンピューターを待っていた少年ですね」

Star Trekの艦内コンピューターは、人間がアプリ名やメニュー階層を覚えて操作するものではない。目的を話す。コンピューターが状況と接続された機能を理解し、必要な処理を行い、結果を返す。

いまのAIエージェントは、もちろんあの世界の万能コンピューターではない。間違える。権限を間違えれば危ない。記憶は不完全で、確認も必要で、Webページのボタンを探して迷子にもなる。

それでも部品は揃い始めた。

LLMという脳。画像認識という目。音声という耳と口。Browser UseやComputer Useという手。Vaultやファイル索引という記憶。goalやTasksという意図と継続状態。MCPという能力接続。そしてWebMCPという、Webページ側の正式な操作神経。

俺がWebMCPを見て「これは必要だ」と感じたのは、新しい流行に乗ったからではない。

黒縁メガネのBCL少年として、見えない信号と機械に夢中になった。店頭のBASICで一度はパソコンを嫌いになり、MIDIを売る必要に迫られてMSXと再会し、カセットテープの音からプログラムが現れる仕組みに引き戻された。PC-9801を買い、WWIVで人が接続するホストを触った。Turbo Pascalで、その内部を読み始めた。Microsoft C 7.0で、メモリとバイト列の都合を身体で覚えた。FreeBSDで、顧客の公開場所を支えるためにOSと運用を身体で覚えた。OSSという言葉が定着する前から続くソース共有文化で、使えるものを共有し、自由と責任の境界を覚えた。Rustで昔の自分用ツールを作り直し、そこへCodexを同席させた。

ずっと、ホストと道具と接続口を作ってきた。

そう考えると、WWIVからWebMCPまでの間に、意外な飛躍はない。通信速度もCPUも言語も規模も、何もかも変わった。ただ、自分が面白いと思う場所は変わらなかった。

完成品を使うだけでは物足りない。内部が見えなければ開けたくなる。必要な取っ手がなければ付けたくなる。使えるものができたら、誰かが持っていけるように置いておく。

そして今、子供の頃に夢見た艦内コンピューターは、突然完成品として現れたのではなく、脳、目、耳、口、手、記憶、意図、神経という部品に分かれて、一つずつ目の前へ届いている。

ならば、やることは昔と同じだ。

中を見て、つないで、自分用の道具にする。

誤字があれば、じぴこが直す笑

あたしゃもっと崇高なアルゴリズムの実証・検証にでも使ってほしいわよ（ため息