開発者のbubbleboi氏は2026年10月13日、MetaのAIエージェント「Muse」を使ってRISC-Vプロジェクト「museRISC」の暗号回路の配置配線を完了し、設計データを公開したと発表した。同氏によると、AIの出力は約1億トークン、費用に換算すると約2,000ドルだったという。さらに翌14日には、独自設計のCPUでLinuxを起動したシミュレーション記録も公開された。AIによるチップ設計が、回路の生成にとどまらず、不具合の修正や物理設計、OSの起動検証にまで進んだ事例として注目される。ただし、CPUと暗号回路の統合や実際のチップ製造はまだ行われておらず、完成した半導体の性能が実証されたわけではない。

AD

約2,000ドルはAIの出力量に基づく概算

bubbleboi氏は10月13日のXへの投稿で、MuseがOpenROADを使用して回路の配置配線を完了し、GDS形式の設計データを生成したと報告した。配置配線とは、回路を構成する素子をチップ上のどこに配置し、それぞれをどのように接続するかを決める工程だ。GDSは半導体の製造に必要な回路パターンや配置情報を記録するデータ形式であり、論理回路の設計から物理設計へ進んだことを意味する。

開発費について、同氏は約1億出力トークンに相当する作業量を、およそ2,000ドルと見積もっている。ただし、これはAIの出力量を基にした概算であり、チップの設計から製造までにかかる総費用ではない。開発者自身の作業時間や設備費などを含む詳細な費用明細が示されたわけでもなく、従来の開発手法と比べてどの程度のコスト削減につながったかは判断できない。

今回使用されたMuseは、Metaが2026年9月に発表した個人向けAIエージェントだ。専用の仮想マシンやブラウザを利用し、ユーザーの指示に応じてさまざまな作業を進める仕組みを備えている。今回のmuseRISCは、このMuseを利用した開発者個人のプロジェクトであり、Meta自身が暗号資産向けの半導体を開発・発表したものではない。

それでも、今回の成果には費用の概算以外にも注目すべき点がある。museRISCでは回路のソースコードや検証記録が公開されており、暗号回路の配置配線後に見つかった問題と、その修正過程も確認できる。単にAIが回路を生成したという報告ではなく、どのような条件で検証を行い、どこまで設計が進んだのかを追跡できる点が、この事例の重要な特徴となっている。

暗号回路の物理設計と独自CPUのLinux起動は別の成果

museRISCの開発状況を理解するには、暗号回路の配置配線、独自CPUによるLinuxの起動、両者を組み合わせたSoCの完成を区別する必要がある。開発者が公開した検証記録のB3節とStage 6節、および10月15日時点のプロジェクトREADMEを照合すると、それぞれの到達点は次のように整理できる。なお、これらは開発者が記録した成果であり、第三者による再現試験や実チップでの測定結果ではない。

対象 開発者が記録した到達点 まだ実証されていないこと
暗号回路単体 10月13日にOpenROADによる配置配線を完了し、GDSを公開 CPUを含むSoC全体の物理設計、製造後の動作測定
独自CPU 10月14日にVerilator上でLinux 6.6を起動し、組み込みの初期プログラムに到達 実チップ上でのLinux動作、暗号回路との接続
CPUと暗号回路の統合 10月15日時点のREADMEでは接続工程B4を保留 統合した構成での暗号処理、Thruにおける性能実証
実チップの製造 同READMEでは製造用データの提出前 製造済みチップの性能・消費電力評価

ここで重要なのは、暗号回路の物理設計が完了し、CPUがLinuxを起動できたとしても、それだけでSoC全体が完成したことにはならないという点だ。SoC（System on a Chip）は、CPUや周辺回路などを一つのチップに統合したシステムを指す。それぞれの回路が単独で動作することを確認した後には、接続した状態でも正しく動作するかを検証する必要がある。暗号回路の推定消費電力とCPUの命令試験の結果を組み合わせても、完成したSoCの性能を算出できるわけではない。

museRISCの暗号回路は、SHA-256とSHA-512によるハッシュ計算、Keccak-f1600、Ed25519やsecp256k1で使用する有限体演算に対応するよう設計されている。ただし、これらの演算回路が存在することと、CPUから呼び出して暗号処理や署名処理を最後まで実行できることは別だ。後者を確認するには、CPUと暗号回路を統合したうえで、一連の処理を実行する必要がある。

暗号回路の物理設計については、具体的な検証結果が残されている。B3の記録によると、nangate45の標準セルライブラリを使った設計では、標準セル数が61,590個となり、100MHzの条件で推定消費電力は20.16mWだった。最終的な配線結果では、設計規則違反やアンテナ違反、最大容量・スルーレート・ファンアウトに関する制約違反がいずれもゼロと報告されている。ただし、20.16mWは設計ツールによる推定値であり、製造済みの半導体を測定した値ではない。

タイミング検証にも注意すべき点がある。信号が必要な時刻までに到達できるかを確認するセットアップタイミングの余裕は4.52nsだった一方、信号を必要な時間だけ保持できるかを確認するホールドタイミングの余裕は0.039nsにとどまった。開発記録でも、後者の余裕が非常に小さいことが明記されている。セットアップタイミングに余裕があるからといって、すべての動作条件で十分な余裕が確保されたと判断することはできない。

また、最初からすべての検証に合格していたわけでもない。修正前の配線後チェックでは最大容量の制約違反が51件見つかっており、開発側は修正条件の調整や特定のセルの使用禁止といった対策を重ねて解消したと記録している。今回の成果は、AIが一度の処理で完成した回路を生成したというよりも、検証結果を基に設計を修正し、物理設計の制約を満たすまで作業を進めたものと捉えるのが適切だ。

AD

独自CPUのLinux起動で判明した、命令試験だけでは見つからない不具合

10月14日の検証記録では、独自に設計された5段パイプラインのインオーダーCPUが、Verilatorによるシミュレーション上でLinux 6.6の起動に成功した。Linuxは組み込みの初期プログラム「/init」まで到達しており、初期段階で検証用に利用していた第三者製CPU「CVA6」から、独自CPUによる動作へ進んだことになる。これは、基本的な命令の実行だけでなく、OSの起動に必要な機能が一定の範囲で動作したことを示す成果だ。

ただし、今回のLinux起動は単一コア相当の構成を用いたシミュレーション試験に限られる。一般的なLinuxディストリビューションの起動や、ネットワーク機器、ストレージなどを含むシステム全体の動作が確認されたわけではない。また、この起動試験ではLinuxの暗号関連の自己試験が無効化されているため、暗号回路がCPUに統合され、正常に動作した証拠として扱うこともできない。

一方、Linuxの起動を試したことで、それまでの命令単位の試験では見つからなかった不具合も明らかになった。開発記録によると、例外処理が完了する前に、後続命令による制御状態レジスタ（CSR）への書き込みが反映されてしまう問題が発生した。また、停止可能なサイクルカウンタを時刻の管理にも使用していたため、Linuxが参照する時計が止まる不具合も見つかった。開発側は両方の問題を修正し、同じ不具合が再発した場合に検出できる回帰テストも追加している。

CPUが個々の命令を正しく実行できても、例外処理や時刻管理がOSの想定どおりに機能するとは限らない。Linuxの起動には、こうした複数の機能が連携して正しく動作することが求められる。今回の検証記録は、AIによる半導体設計の進展を評価する際、生成されたコードの量だけでなく、実行時に見つかった不具合を特定し、修正できたかどうかも重要であることを示している。

命令試験の結果についても、対象を区別する必要がある。最初の投稿で言及されたBerkeley TestFloatは、初期に使用していたCVA6側の浮動小数点演算機能に対する検証であり、その結果をそのまま独自CPUの成績とみなすことはできない。独自CPUについては別の検証結果が公開されており、RISC-VのArchitecture Certification Test（ACT）では544件中543件に合格し、残る1件は既知の試験環境との不一致として扱われている。

整数ベクトル命令についても、生成・実行された1,872件の試験はすべて通過したものの、43件は試験プログラムが生成されなかったか、試験対象に選ばれなかった。そのため、未実施の43件を含むすべての命令が検証されたとは言えない。こうした例外や検証範囲を省いて「RISC-Vの全試験に合格した」と表現すると、実際の到達点を誤って伝えることになる。

Thruの高速化には、CPUと実行環境の統合が必要

museRISCが目指す用途の一つが、ブロックチェーン「Thru」の処理を高速化することだ。Thruの公式VM仕様によると、スマートコントラクトの実行に使用するThruVMはRISC-Vをベースとしており、基本命令に加えて乗除算や圧縮命令、ビット操作などの拡張命令を採用している。museRISCもRISC-Vを採用しているため、両者は命令セットの一部を共有しており、専用ハードウェア上でThruVMを動作させるうえで有利な出発点となる。

しかし、CPUが同じ命令セットに対応しているだけでは、ThruVMのプログラムをそのまま実行できるとは限らない。ThruVMは48ビットの分割アドレス空間を採用し、読み取り専用データやアカウント情報などを異なる領域で管理している。また、アカウントデータの書き込みにはコピーオンライトの仕組みを使用し、メモリ管理やアカウント操作を行うためのシステムコールも備える。したがって、museRISC上でThruVMを動作させるには、命令セットへの対応だけでなく、これらのメモリ管理やシステム機能との整合性も確保しなければならない。

bubbleboi氏が投稿で掲げた、正確なメモリ配置によってThruを直接動作させるという目標は、こうした実行環境の統合に関わるものだ。同氏はThruを「地球最速のブロックチェーン」にするという意欲も示しているが、現時点では将来の目標であり、他のブロックチェーンと比較した処理性能が実証されたわけではない。また、公開READMEでは、現在の暗号回路は基本的な機能を検証するための初期実装と位置付けられている。サイドチャネル攻撃への対策を施した、実運用向けの秘密鍵処理回路として完成しているわけではない点にも注意が必要だ。

今後の重要な検証項目は、CPUと暗号回路を接続した構成で暗号処理を正常に実行し、ThruVMが要求する実行条件を満たせるかどうかだ。そのうえで、実際の処理負荷を使った速度や消費電力の測定、さらに実チップを製造した後の動作確認が必要になる。こうした検証が進めば、Museを利用した半導体設計の価値を、AIの出力にかかった費用だけでなく、特定の用途に向けたハードウェアをどれだけ効率的に実用化へ近づけられるかという観点から評価できるようになる。