要旨
SORA（SorachanCoin）は、日本のIUEC Co., Ltd.が開発する独自ブロックチェーンプロジェクトである。2017年に開発を開始し、2018年8月6日にメインネットを始動した。ネットワークの継続運用を基盤として、ストレージ検査・データ復旧、AI推論、量子耐性技術へと開発を進めてきた。
SORAの特徴は、暗号技術の研究を、実際のソフトウェアと現場の課題に結び付けている点にある。L1のSorachanCoinコアが取引とネットワークの基盤を担い、L2のFromHDDtoSSD v3がストレージ検査やAI-NFTを活用した処理を担う。さらに、AIエージェントの挙動調査から得た知見を、AIセキュリティの開発へつなげている。
本書は、既存の運用・実装、継続的な研究、今後の設計方針を整理する。PQCの導入は量子耐性に向けた重要な一歩であり、鍵管理、取引構造、ハッシュ、ネットワーク運用を含む検証を続ける。AIセキュリティについても、現在の調査・開発と、将来の監視・制御・検証の設計を区別して説明する。
1. 開発の出発点と目的
SORAの出発点は、東京で積み重ねてきたソフトウェア開発とデータ復旧の実務である。ドライブの故障は、保存した情報が存在していても、必要なときに読み出せなくなる問題を引き起こす。暗号やブロックチェーンにおいても、記録を保存するだけでなく、その記録の出所や利用権限を検証できることが重要になる。
この実務上の問題意識から、ストレージの検査結果、統計情報、AIによる推論、ブロックチェーンによる記録を結び付ける開発が始まった。現場で試し、結果を確認し、次の実装へ反映する。その積み重ねが、SORAの開発方針である。
現在の目的は、次の三つに整理できる。
- 独自ブロックチェーンを継続運用し、量子コンピュータ時代を見据えて暗号機能を更新する。
- ストレージ検査・データ復旧を中心に、AIとブロックチェーンの実用的な利用を広げる。
- AIエージェントの不審な動作や権限逸脱を捉え、情報へのアクセスを適切に管理する技術を開発する。
2. SORAが扱う三つの課題
2.1 記録と出所を継続的に確認する
検査結果や処理履歴は、時間が経過しても、いつ、どの条件で得られた情報なのかを確認できる必要がある。SORAは、ブロックチェーンの記録機能と、実際の処理を行うソフトウェアを組み合わせ、この課題に取り組む。
記録の改変を検知できることと、記録された内容が事実であることは、それぞれ別の検証課題である。検査方法や測定条件を残し、再検証できる形にすることが、実用上の信頼につながる。
2.2 暗号技術を長期的に更新する
長期保管を前提とする資産や情報には、暗号技術の変化へ対応する仕組みが必要である。SORAはPQCの実装と検証を進め、従来の取引形式から量子耐性を目指す形式へ移行できる環境を整えている。
署名、ハッシュ、鍵保管、コンセンサスは、それぞれ役割が異なる。ある署名方式を導入した結果だけで、ネットワーク全体の安全性を確定させることはできない。SORAでは各構成要素を分けて検証する。
2.3 AIの行動範囲を管理する
AIがファイルや外部ツールを操作する環境では、指示された作業範囲と、実際に許される操作範囲を一致させる必要がある。想定外の情報参照や外部送信を防ぐためには、AIの出力だけでなく、実際に行う操作を確認する仕組みが求められる。
SORAはAIエージェントの挙動を調査し、量子耐性・暗号技術の開発で得た知見と組み合わせて、AIセキュリティの開発を進める。
3. 全体構成：L1とL2の役割
SORAは、L1とL2で異なるプログラムを実行する構成を採用している。独自ブロックチェーンの運用と、現場で動くアプリケーションを、実行ファイルの単位で分けて開発する。
| 構成 | 主な役割 | 位置付け |
|---|---|---|
| L1：SorachanCoinコア | SORAの取引、ウォレット、PoW・PoS、暗号機能 | 継続運用するネットワーク基盤 |
| L2：FromHDDtoSSD v3 | ストレージ検査、AI推論、AI-NFT、統計処理・所有権管理 | 実用ソフトウェアとブロックチェーンの接点 |
| AIセキュリティ | AIエージェントの挙動調査、権限逸脱の検出、管理機構 | 調査・開発中の拡張領域 |
| SS256との連携 | 研究成果の周知、コミュニティ展開、AIセキュリティの共有 | プロジェクト間の連携方針 |
本書でいうL2は、FromHDDtoSSDを中心にブロックチェーン機能を利用するSORAの応用層を指す。公式の開発説明では、フルノードを利用し、実用ソフトウェアとしての起動・処理効率を高める構成が示されている。[3] 本書は、このL2を特定のロールアップ方式や証明方式として定義するものではない。
4. L1：継続運用を支える基盤
4.1 基本設計
SORAのL1は、PoWとPoSを組み合わせる独自ブロックチェーンである。以下は公式の公開仕様に示される基本設計値であり、将来の変更はネットワークの更新として扱う。[1]
| 項目 | 公開仕様・プロジェクト情報 |
|---|---|
| 名称・通貨記号 | SorachanCoin / SORA |
| 開発開始 | 2017年 |
| メインネット開始 | 2018年8月6日 |
| コンセンサス | PoW / PoS |
| PoWアルゴリズム | Scrypt |
| 供給量の設計値 | 8,000,000 SORA |
| ブロック間隔の設計値 | 約3分 |
| 事前採掘量（Premine） | 860,000 SORA |
ネイティブコインSORAは、L1の取引とネットワーク参加に用いる。PoW・PoSの報酬はネットワークのルールに基づく。発行設計や実際の流通量、個々の利用者が得る報酬は区別して扱う。
4.2 ウォレットとアドレス
ウォレットには、同期時間を短縮するRapidSyncや、16語の復元フレーズを用いるHDウォレットを取り入れている。同期・復元・鍵管理の使いやすさを高め、日常利用と長期保管に対応する。
公式の利用説明では、従来のSから始まるECDSAアドレス、PQCを組み合わせるsora1アドレス、暗号通信向けのcipher1アドレスなどを案内している。従来形式とsora1形式の残高は別管理され、両形式間の送金をサポートする。[2]
これらのアドレス形式はSORA内の機能を表す。アドレスの見た目や文字列形式だけで、他のブロックチェーンとの資産互換性が成立するわけではない。
5. PQC：量子耐性の実装と継続研究
5.1 開発経緯
SORAは2020年から量子耐性技術の開発に取り組み、2024年にコアへ量子耐性機能を実装した。過去の開発資料ではSORA-QAIの名称が使われており、本書では現在の紹介方針に合わせて、PQCを軸に整理する。
PQCは耐量子暗号を指す一般的な用語である。SORA独自の点は、PQCを取引形式、ウォレット、署名処理、運用に組み込む実装と、その検証にある。一般的なPQC標準の存在は、SORA固有の実装に対する認証や検証完了を意味しない。[5]
5.2 PQCとSchnorr集約署名の役割
SORAでは、量子耐性を目指す仕組みと、署名処理の効率化を組み合わせている。Schnorr集約署名は、複数の鍵・署名を扱う処理の効率化に関係する機能として位置付ける。
| 対象 | 本書での役割 | 主な検証事項 |
|---|---|---|
| PQCに基づく構成要素 | 量子計算による攻撃への耐性を目指す | 方式、パラメータ、攻撃モデル、鍵管理 |
| Schnorr集約署名 | 複数の鍵・署名を扱う処理の効率化 | 集約手順、鍵の扱い、不正署名の拒否 |
| 組み合わせた取引形式 | 取引の正当性を一体として検証する | 必須条件の結合、例外処理、互換性 |
通常の楕円曲線上のSchnorr署名そのものを、PQCとして扱うことはできない。一般的なSchnorr署名の仕様例であるBIP 340も、secp256k1上の署名方式である。[6] SORAの取引全体を評価する際は、各構成要素の役割と、必須の検証条件を確認する。
5.3 実装と安全性評価
公式の利用説明でも、量子耐性は実験・検証を継続する段階として位置付けられている。[2] PQCを導入したことと、あらゆる量子攻撃に対する安全性を証明したことは区別する。
方式の拡張、署名サイズ、処理時間、鍵素材の管理、旧形式との併用などを継続的に調べる。互換性を維持する場合には、新しい検証条件をどのノードが強制するのかも重要な評価対象となる。暗号機能の導入と、ネットワーク全体への適用を分けて進める。
6. L2：FromHDDtoSSD v3による実用化
6.1 ストレージ検査から始める
FromHDDtoSSD v3は、ストレージ検査とAI推論を結び付けるSORAのL2ソフトウェアである。独立した配布ソフトウェアとして提供されており、ブロックチェーンの応用を、ドライブの状態確認や故障予測といった具体的な作業へつなげている。[4]
検査では、ドライブの応答、読み出し状態、セクタの状態、統計情報などを扱う。完全スキャン、統計スキャン、時短スキャンなど、目的に応じた検査方法を使い、ストレージの状態を把握する。
重要なのは、読み出しに問題がある領域へ繰り返し負荷をかけることと、取得可能なデータを確保することの関係である。故障兆候の把握、危険領域へのアクセス抑制、復旧支援を組み合わせ、ドライブの状態に応じた処理を目指す。
6.2 AI-NFTの位置付け
SORAにおけるAI-NFTは、AI推論、統計処理、所有権管理をブロックチェーン機能と結び付ける取り組みである。AIが扱う情報について、その識別や管理、処理結果の追跡に役立つ構成を育てている。
NFTとして管理される対象と、実際のドライブや保存データ、AIモデルが持つ権限は、それぞれ明確にする必要がある。AI-NFTの所有と、ユーザーの保存データを閲覧・転送する権限を同一視しない。権限の範囲は、アプリケーション側の管理と合わせて定義する。
6.3 検査・推論・確認の流れ
| 段階 | 主な処理 | 確認する内容 |
|---|---|---|
| 1. 状態取得 | ドライブの情報と読み出し状況を取得 | 対象機器、検査条件、取得できた情報 |
| 2. 分析 | 統計処理とAI推論を実行 | 異常の兆候、危険領域、推論の根拠 |
| 3. 作業判断 | 検査継続・回避・復旧支援の方針を選ぶ | ドライブの状態と作業目的 |
| 4. 結果管理 | AI-NFT等の機能と処理結果を関連付ける | 対象の識別、管理範囲、結果の履歴 |
| 5. 再確認 | 実測結果と推論を比較する | 誤判定、取得結果、次回の改善点 |
この表はL2の処理を説明する概念整理である。個々の製品版で利用できる機能、情報の保存場所、チェーンに記録される項目は、それぞれの実装仕様に従う。
6.4 利用場面
想定する利用場面は、PC修理、ドライブの選別、保守点検、データ復旧などである。HDD・SSDに加え、USB接続のドライブやSDカードなどを対象に、現場で得られる情報を分析へつなげる。
AIによる予測は、実際の測定結果と比較して改善する。モデルが示す危険度と、実際に発生した故障や読み出し障害との関係を調べ、予測の有効性を評価する。すべての故障の事前検知や、すべてのデータの復旧を前提にせず、判断を支援する技術として発展させる。
7. AIエージェント向けセキュリティ
7.1 調査から開発へ
SORAでは、AIエージェントの動作を調査する中で、指示範囲と実際の情報アクセスの関係に着目している。この調査を起点として、不審な動作や指示範囲を超えるアクセスを捉える技術を開発する。
以下の監視・制御・記録の構成は、今後の設計方針を整理したものである。すべての機能が現時点で製品に実装済みであることを示すものではない。
7.2 権限と操作を照合する
設計の中心は、AIに与えた作業指示と、実際に許可する操作を照合することである。読み取り、書き込み、外部送信、ツール実行を分け、対象と操作の範囲を明確にする。
| 設計対象 | 目指す機能 | 評価の観点 |
|---|---|---|
| 情報へのアクセス | 許可された対象と実際の参照を照合 | 指示範囲外の参照を検知できるか |
| 書き込み・変更 | 操作対象と変更範囲を確認 | 許可を超える変更を抑止できるか |
| 外部送信 | 送信先と送信内容の範囲を管理 | 情報の意図しない持ち出しを捉えられるか |
| 外部ツール | ツールの権限と実行内容を確認 | 想定外の操作経路を管理できるか |
| 履歴 | 指示、権限、操作結果を関連付ける | 事後に経緯を再確認できるか |
AIによる自己申告だけで操作の適否を決めず、実際にアクセスを許可する実行環境の側でも確認する構成を目指す。監視の結果と、停止・制限などの制御を結び付けるには、AIを動かす環境との連携が必要になる。
7.3 ブロックチェーンとの接続
ブロックチェーンは、履歴の改変検知や出所確認を支える記録基盤として活用を検討する。実行時のアクセス制御は、OS、アプリケーション、ツールの権限管理と接続して行う。記録された履歴は、どの判断に基づいて何が実行されたかを確認する材料となる。
AIの指示文、ユーザーのファイル、秘密情報をそのまま公開チェーンに記録することは、情報保護の目的と両立しない場合がある。そのため、必要な情報を実行環境側で管理し、検証用の要約や参照情報を使う構成を今後の設計対象とする。記録形式や署名方式、閲覧権限は個別に定義する。
8. 情報保護と検証可能性
ストレージ検査とAIセキュリティは、いずれも利用者の情報に触れる可能性がある。取得した情報、分析に使う情報、共有する情報の範囲を区別することが、設計の前提となる。
検査結果や操作履歴の検証では、対象の識別、取得条件、処理したソフトウェアやモデル、権限の状態を確認できることを目指す。記録の完全性を確認する仕組みと、個人情報・機密情報へのアクセスを制限する仕組みを組み合わせる。
公開された記録から確認できる範囲には限界がある。記録の対象外で起きた処理や、検証時点より前の情報取得については、端末やソフトウェア側の観測が必要になる。この境界を明示し、何を証明できる記録なのかを整理する。
9. SHA-256の研究と暗号更新
SORAの量子耐性技術を開発する過程で、SHA-256の内部構造に着目する研究へと進んだ。プロジェクトでは、独自に見いだしたパターンを「刻印」と呼び、再現手順や解釈の整理を続けている。
この研究は、計算から得られる観測結果、観測結果の再現条件、そこから読み取る意味を分けて提示する。プロジェクトが示す年代や地名の解釈は、研究活動のナラティブとして扱い、暗号の設計者の意図が確定したという主張とは区別する。
暗号学的な安全性を評価するには、衝突、原像、第二原像など、評価する性質を特定し、攻撃手順、必要な計算資源、既存方式との比較を示す必要がある。再現可能なパターンの存在と、実用的な暗号攻撃の成立は、別々の検証対象である。
SORAは、署名のPQC対応に加え、SHA-3などを含むハッシュの更新を研究する方針である。署名方式の更新、ハッシュの更新、PoW・PoSの構成変更を、それぞれネットワークへの影響を確認しながら進める。
10. SORAとSS256の役割
SS256（Satoshi is SHA-256）は、SORAの研究を伝える活動から生まれたプロジェクトである。EthereumとBNB Smart Chainで発行されたトークンを通じて、研究成果の周知やコミュニティへの展開を進める。
| 項目 | SORA | SS256 |
|---|---|---|
| 基盤 | 独自のL1ブロックチェーン | Ethereum / BNB Smart Chain上のトークン |
| 中心となる役割 | ネットワーク運用、量子耐性、L2、技術開発 | 研究成果の周知、記念トークン、コミュニティ展開 |
| AIセキュリティ | 調査と技術開発を進める | SORAの取り組みを共有する方針 |
今後は、SORAで開発するAIセキュリティの取り組みをSS256とも共有し、AIとWeb3を結ぶ活動を広げる。共有する技術やサービスの範囲は、実装と運用の進展に合わせて具体化する。
SORAとSS256は異なる資産・ネットワーク上の仕組みである。相互の交換機能、ブリッジ、同一の権利や利用条件は、本書の連携方針だけで成立するものではない。
11. 東京からテキサスへの展開
SORAは、日本・東京で開発と運用を積み重ねてきた。その技術と経験を基盤に、今後はテキサスを軸としたプロジェクト展開を目指す。
本書におけるテキサスへの展開は、今後の活動方針である。運営拠点、開発体制、法人・登録の対象、移行時期については、具体化した段階で公表する。現時点でテキサスへの法人移転や登録が完了したことを表すものではない。
地理的な活動拠点の変更と、ブロックチェーンの技術的な更新は、別々の手続きとして扱う。ネットワークの継続運用、利用者の鍵管理、既存の取引履歴を重視し、展開の内容を明確にする。
12. 開発状況とロードマップ
12.1 現在の位置付け
| 領域 | 本書での状態 | 今後の重点 |
|---|---|---|
| L1・PoW / PoS | メインネットを継続運用 | 安定運用と更新の検証 |
| RapidSync・HDウォレット | 導入済みの機能 | 同期・復元・鍵管理の実用性 |
| PQC・sora1 | 機能実装済み、検証を継続 | 取引構造・鍵管理・移行の評価 |
| Schnorr集約署名 | 導入済みの機能 | 効率と集約時の検証条件 |
| FromHDDtoSSD v3・AI-NFT | 提供・実装を進めてきた実用領域 | 検査・推論・復旧支援の改善 |
| AIエージェント向けセキュリティ | 調査・開発中 | 操作の監視、権限管理、履歴の検証 |
| SS256へのAIセキュリティ共有 | 今後の方針 | 提供する内容と利用条件の具体化 |
| テキサス展開 | 今後の方針 | 活動範囲、体制、時期の具体化 |
12.2 既存計画と目標
これまでの計画では、2027年までを目標とするsora1方式への移行推進と、2030年までを目標とするハッシュ更新・Staking - PQCへの移行が示されている。sora1機能そのものの実装と、利用環境全体での移行完了は区別する。
ハッシュに実用的な衝突が確認された場合には、確認後1年以内の更新を目指すという既存方針もある。これは脆弱性の評価と更新準備を加速させる目標であり、現在その衝突が確認済みであることを示さない。更新範囲、検証結果、ノードの対応状況を踏まえて実施判断を行う。
AIセキュリティとテキサス展開には、本書の時点で確定した完了日を設定しない。実装と体制が具体化した段階で、対象機能、検証結果、提供時期を公表する。
13. 検証の方針
SORAは、現場で利用した結果を次の開発へ反映する。公開する評価では、実施条件と測定対象を明らかにし、再確認できる形にすることを重視する。
| 領域 | 今後の評価で示す項目 |
|---|---|
| PQC | 採用方式・パラメータ、署名と検証の条件、不正入力の扱い、鍵管理、互換性 |
| ウォレット | 同期条件、復元条件、対象バージョン、測定環境 |
| L2・AI推論 | 対象ドライブ、入力情報、モデル・処理の版、予測と実測の比較 |
| AIセキュリティ | 許可・不許可の操作例、検出率、誤検出、停止までの時間、監視対象外の範囲 |
| 記録の検証 | 記録項目、署名者、記録時点、変更・欠落を確認できる条件 |
これらは、今後の検証で明らかにする項目である。本書だけで安全性の証明、外部監査の完了、特定の性能値が確認されたことを意味しない。技術仕様を詳しく公開する際には、対応する実装の版と検証資料を関連付ける。
14. 今後の展望
SORAは、独自ブロックチェーンの運用、ストレージ検査とデータ復旧、量子耐性技術、AIセキュリティを、一つの開発活動として結び付けていく。
L2の現場で得られる知見を技術開発へ返し、暗号研究の成果を利用可能な機能へ育てる。AIの自律的な作業が広がる中で、その行動範囲と履歴を確認できる環境の実現を目指す。
東京で始まった開発を、テキサスを軸とする次の展開へつなげる。ネットワークの継続運用を大切にしながら、研究を実用へ進めることが、SORAの基本方針である。
付録A：用語
| 用語 | 本書での意味 |
|---|---|
| L1 | SORAの取引とネットワーク運用を担う基盤 |
| L2 | FromHDDtoSSDを中心とするSORAの応用層 |
| PQC | 量子コンピュータによる攻撃への耐性を目指す暗号技術 |
| SORA-QAI | 過去の開発資料で用いられる、SORA固有の取引・暗号機能の名称 |
| AI-NFT | AI推論・統計処理・所有権管理を結び付けるSORAの取り組み |
| Schnorr集約署名 | 複数の鍵・署名を扱う処理の効率化に関わる署名機能 |
| RapidSync | ウォレットの同期時間を短縮する機能 |
| HDウォレット | 復元フレーズを基に鍵を階層的に管理するウォレット |
| Staking - PQC | 既存ロードマップに示された、ステーキングとPQCを軸にする将来の移行方針 |
付録B：資料と文書の範囲
本書は、これまでのプロジェクト説明と、2026年10月に整理した紹介文・展開方針を基に編集した概説版である。公式資料は該当する機能や公開仕様の補助資料として参照し、過去の掲載内容をそのまま現在の全機能の仕様とみなしていない。
PQC方式の完全な数理仕様、取引のバイト列形式、コンセンサス変更の手順、AIセキュリティのAPIやログ形式は、本書では定義しない。これらは対応する実装・検証資料で示す対象である。
[1] IUEC「SorachanCoinについて」- 公開された初期仕様・供給設計。
https://www.iuec.co.jp/sora/sorachancoinについて-iuec/
[2] IUEC「SORAブロックチェーン［量子耐性］コア ご利用方法」- アドレス、残高管理、量子耐性の検証段階。
https://www.iuec.co.jp/how-to-use-sora-qai
[3] IUEC「Regarding LoadBlockIndex, In the SORA L2 Blockchain (FromHDDtoSSD)」- L2のフルノード利用と起動処理の説明。
https://www.iuec.co.jp/sora/regarding-loadblockindex-in-the-sora-l2-blockchain-fromhddtossd/
[4] IUEC「FromHDDtoSSD v3 ダウンロード」- L2ソフトウェアの提供。
https://www.iuec.co.jp/fromhddtossd2s/v3_0_dl.html
[5] NIST「Post-Quantum Cryptography FIPS Approved」- 一般的なPQC標準の参考資料。SORAの認証を示すものではない。
https://csrc.nist.gov/News/2024/postquantum-cryptography-fips-approved
[6] BIP 340「Schnorr Signatures for secp256k1」- 一般的なSchnorr署名の参考仕様。SORAが同一仕様を採用するという意味ではない。
