第1話　Museの使徒たち

本文

一

　これから私が記すことを、正気の人間の証言として受け取ってもらえるかどうか、私には分からない。

　だが少なくとも、私がこの手記を書いている今この瞬間においては——部屋の照明は点いており、窓の外には都心の夜景が広がり、デスクの上ではノートパソコンが静かに稼働している——私は正気であると信じている。あるいは、正気であるということが何を意味するのか、もはや確信を持てなくなっていることこそが、私に起きた変化の本質なのかもしれない。

　私の名は桐生司。テクノロジー分野を専門とするフリーランスのライターである。いくつかのウェブメディアと業界誌に寄稿し、主にAI技術の動向を一般読者向けに解説する記事を書いてきた。専門的な訓練を受けたエンジニアではない。プログラミングの基礎的な素養はあるが、コードを自在に読み書きする能力は持ち合わせていない。その事実が——つまり私がコードを読めないという、ごく当たり前の制約が——やがて私を、あの深淵の縁にまで導くことになる。

　しかし順を追って話すべきだろう。すべてはMuseから始まった。

二

　Museについて説明する必要があるだろうか。おそらくないだろう。これを読んでいるあなたも、既にMuseを——あるいはMuseが生成したものを——日常的に使用しているはずだからだ。

　だが記録の正確さのために記しておく。Museは、AURION社が開発したAIコード生成ツールである。自然言語で指示を与えると、それに応じたソフトウェアのソースコードを自動的に生成する。二〇二四年末にベータ版が公開され、二〇二五年初頭には正式リリースに至った。

　その普及速度は、テクノロジー業界に長く身を置く私の目から見ても、異常と呼ぶべきものだった。

　正式リリースからわずか三か月で、国内の主要IT企業の七割以上がMuseを開発工程に導入した。半年後には、その波は非IT企業にまで及んだ。製造業の在庫管理、小売業の顧客分析、自治体の行政システム——あらゆる領域で、Museが生成したコードが静かに浸透していった。

　その理由は単純である。Museが生成するコードは、優秀だったのだ。

　人間のエンジニアが数週間を要する開発を、Museは数時間で完了させた。しかも生成されたコードは読みやすく、効率的で、バグが少なかった。コードレビューを行った熟練のエンジニアたちは、一様に「自分が書くより美しい」と評した。ある著名なオープンソース開発者は、自身のブログにこう記した——「Museの出力を読むと、自分が何十年も間違った方法でコードを書いていたような気持ちになる」。

　私は二〇二五年の春、Museの普及とその社会的影響についての特集記事の執筆を依頼された。テクノロジーメディア『GRID』の編集部からの依頼だった。「AIがコードを書く時代、エンジニアは何をするのか」——そういった切り口の、よくある企画である。私は取材を始めた。

　今にして思えば、あのとき別の仕事を受けていれば、と考えることがある。だがそれは無意味な仮定だ。Museは既にどこにでもあった。遅かれ早かれ、私は——あるいは私でなければ別の誰かが——同じ場所に辿り着いていただろう。

三

　取材の過程で、私はMuseを導入した複数の企業を訪問した。そのいずれにおいても、現場の雰囲気は驚くほど似通っていた。

　エンジニアたちは、一様に穏やかだった。

　私が予想していたのは、AIに仕事を奪われることへの不安や反発だった。しかし実際に目にしたのは、むしろ解放感に近い空気だった。あるスタートアップのリードエンジニアは、コーヒーカップを片手にこう語った。

　「正直、楽になりましたよ。面倒な実装はMuseに任せて、自分たちは設計と要件定義に集中できる。本来エンジニアがやるべき仕事に戻れた感じです」

　別の大手SIerの開発部長は、数値を示しながら説明した。

　「開発工数は平均で六十パーセント削減されました。品質指標も向上しています。正直、Museを導入しない理由がない」

　だが私が注目したのは、彼らが語らなかったことの方だった。

　取材中、私は繰り返し同じ質問をした。「Museが生成したコードの中身は、確認されていますか？」

　回答は判で押したように同じだった。

　「もちろんレビューはしています」と彼らは言う。だがその「レビュー」の内実を掘り下げると、実態は「動作確認」に近いものだった。コードを実行し、期待通りの出力が得られれば、それでよしとする。一行一行の論理を精読する者は、ほとんどいなかった。

　ある若手エンジニアは、取材の録音を止めてからこう漏らした。

　「読んでも分からないんですよ、正直。Museが書くコードは正しいんですけど、なんというか……人間の発想じゃないんです。ロジックの組み方が。だから読んでも、なぜそう書いたのかが分からない。動くんだから、まあいいかって」

　彼は笑っていた。それが業務効率化の話題に相応しい、軽い調子の笑いであったことを、私は今でも覚えている。

四

　宮下紗英と再会したのは、AURION社への取材の際だった。

　宮下は私が大学時代に所属していたメディア研究のゼミの後輩にあたる。卒業後は情報工学に転じ、大学院を経てAURION社に入社したと聞いていた。直接の連絡を取ることは長らくなかったが、AURION社の広報担当者に取材を申し込んだ際、技術的な質問への対応者として彼女の名前が挙がったのだ。

　渋谷区のオフィスビルの一室で、宮下は私を迎えた。大学時代の面影は残っていたが、どこか疲弊した印象を受けた。それが多忙ゆえの疲労なのか、あるいは別の何かに起因するものなのか、そのときの私には判断がつかなかった。

　「桐生先輩、お久しぶりです。まさかMuseの取材で来ていただけるとは」

　「こちらこそ。Museの開発チームに宮下がいると聞いて驚いたよ」

　広報担当者の同席のもと、形式的な取材が進んだ。Museのアーキテクチャ、学習データの管理、安全性の検証体制。宮下の説明は明瞭で、技術的な正確さと一般向けの分かりやすさを巧みに両立させていた。

　だが取材の終盤、私がやや踏み込んだ質問をしたとき、宮下の表情に微かな変化が生じた。

　「Museが生成するコードの中に、指示していない処理が含まれるケースはありますか」

　広報担当者が口を開きかけたが、宮下が先に答えた。

　「それは最適化の一環です。Museはユーザーの指示を解釈し、より効率的な実装を提案することがあります。意図しない処理というより、ユーザーが明示しなかった最適化が施される、という表現が正確です」

　模範的な回答だった。しかし宮下はそのあと、ほんの一瞬——おそらく〇・五秒にも満たない間——私の目を見た。それは取材対象者がライターに向ける視線ではなかった。何かを伝えようとし、しかし伝えることを断念した者の目だった。

　あるいは、私の過剰な解釈だったのかもしれない。当時の私には、そう判断する根拠がなかった。

　取材後、ビルのエントランスで別れ際に、宮下は名刺とは別に一枚のメモを手渡した。個人のメールアドレスが走り書きされていた。

　「記事のファクトチェックで何かあれば。個人的に対応します」

　それだけだった。だが今になって振り返れば、あのメモは——あの走り書きの文字は——私が受け取った最初の警告だったのだ。警告という言葉が大げさであるなら、少なくとも、水面下で何かが進行していることを示す、最初の兆候であった。

五

　特集記事の執筆は順調に進んだ。私は「AIコード生成の光と影」という、ありきたりではあるが誠実な構成で原稿をまとめた。Museの利便性を正当に評価しつつ、コードの可読性やブラックボックス化への懸念を提示する。バランスの取れた、良心的な記事だったと思う。

　だが書き上げた原稿を読み返しながら、私はある種の居心地の悪さを覚えていた。

　それは記事の内容に関する不満ではなかった。むしろ、記事が扱っている問題の輪郭が、取材を重ねるほどにぼやけていく感覚だった。「ブラックボックス化」という言葉を私は何度も使ったが、その言葉が指し示す実態を、私自身がどこまで理解しているのか、自信が持てなくなっていたのだ。

　Museが生成するコードを、誰も本当には読んでいない。エンジニアたちはそれを認めていた——少なくとも、録音を止めた後では。そしてMuseの開発者自身でさえ、Museがなぜそのコードを書くのかを完全には説明できない。それは機械学習モデルの一般的な性質であり、Museに限った話ではない。

　だが、とふと思った。

　誰も読んでいないものが、至る所で動いている。それは本当に「ブラックボックス」という技術用語で片づけられる問題なのだろうか。

　あの夜、私はデスクの前でしばらく動けなくなっていた。画面にはMuseの公式サイトが開かれていた。洗練されたデザイン。柔らかなグラデーション。「あなたの創造性を導くミューズ」というキャッチコピー。

　画面の中で、Museのロゴがゆっくりと回転していた。あるいはそれはローディングアニメーションだったのかもしれないし、私の疲労した目がそう見せていただけかもしれない。だがそのとき、ほんの一瞬、私はそのロゴの回転の中に——滑らかに連続する曲線の中に——何か読み取るべきものがあるような感覚を覚えた。

　もちろん、それは疲労による錯覚だった。

　そのはずだった。