日本は世界のためのオペレーティングシステムを構築しようとしたが、米国が介入した

Adam Conway 著 2026年8月20日 9:00 AM EDT 私はアダム・コンウェイ、コンピュータサイエンスの学士号を持つアイルランドのテクノロジー愛好家であり、XDAのリードテクニカルエディターです。私の学士論文は、パフォーマンスのようなAndroidアプリやスマートフォンの非機能要素のベンチマークの実現可能性について行われ、2017年以来、何らかの形でテクノロジー業界で働いています。余暇には、Counter-StrikeやVALORANTをプレイしているでしょう。adam@xda-developers.com、Twitterで@AdamConwayIE、InstagramでAdamConwayIE、またはRedditでu/AdamConwayIEまでご連絡ください。 XDAアカウントにサインイン コンピューティングの歴史には、Windowsが勝利しなかったバージョンが存在します。代替がUnixベースだったからでも、Appleが何か違うことを成し遂げたからでもありません。1984年に東京大学で設計されたオペレーティングシステムが、ファイルシステムをハイパーメディア文書モデルに置き換え、カスタムの日本製CPUアーキテクチャで動作し、150万文字をエンコードしようとしたほど野心的だったからです。しかし、1989年に米国の貿易報告書がそれを不公正な貿易障壁として名指ししました。そのプロジェクトこそがTRON（The Real-time Operating system Nucleus）でした。これは政府支援による実際の日本のコンピューティングイニシアチブであり、そのデスクトップ版であるBTRONは、米国の貿易障壁報告書に名を連ね、全国の学校に普及する前に事実上廃止されました。その間、組み込み版であるITRONは、静かに歴史上最も展開されたオペレーティングシステムの一つとなりました。 TRONの歴史は、その後、実際にワイルドな陰謀論を引きつけてきました。例えば、1985年の日本航空123便墜落事故は、TRON開発者を標的にするために意図的に起こされたというものですが、フライトにTRON開発者が搭乗していたという証拠はありません。しかし、この話の最も奇妙な部分は、陰謀論でさえありません。BTRONのハイパーメディアデスクトップは、市場がサポートできるレベルを何十年も先取りしていました。そして、ソフトバンク創業者の孫正義氏が、内部からそれを沈没させるのを助けた可能性があります。 Ken Sakamuraは日本の社会全体のためのOSファミリーを設計しました 彼はシリコンを含め、すべてを欲しました Ken Sakamura氏は、1984年にTRONプロジェクトを開始した当時、東京大学の研究者でした。それは野心的な事業でした。彼は、洗濯機の中のマイクロコントローラーから、デスク上のワークステーション、中央局の通信交換機に至るまで、日本がそのデジタルインフラ全体を構築できるような、垂直統合型コンピューティングアーキテクチャを望んでいました。プロジェクトには5つのサブアーキテクチャがありました：組み込みリアルタイムシステムのためのITRON、パーソナルコンピュータのためのBTRON、メインフレームと通信交換のためのCTRON、システム間調整のためのMTRON、そしてリアルタイムカーネルのハードウェア実装であるSTRONです。プロジェクトは独自のCPUアーキテクチャ、TRON VLSI CPUを設計し、日立がGmicro/200シリーズとして製造しました。日立は実際にそれを製造・販売し、1980年代後半には一部の日本のワークステーションや組み込みシステムを搭載しました。Sakamura氏のチームは、効率的な日本語入力とプログラミング記号のために設計された独自のTRONキーボードレイアウトと、リアルタイムペリフェラルバスであるmicro-BTRONも考案しました。これはIEEE 802.5に基づいており、「電子文具」ペリフェラルを接続するためのMIDIの代替として意図されていましたが、そのバスは商業製品として出荷されることはありませんでした。アイデアは、シリコンからユーザーインターフェースに至るまで、すべてのレイヤーが一緒に設計され、既存のプラットフォームへの互換性の負債がないことでした。 文字エンコーディングシステムであるTRON Codeは、おそらく最も野心的な部分でした。それは31個のプレーン（各48,400文字）のマルチプレーン文字切り替えを0xFEエスケープコードでサポートし、理論上の容量は1,500,400文字でした。1999年までに、B-right/V R2は14個の定義済みプレーンに約130,000文字を搭載し、JISレベル1と2、中国語GB 2312、韓国語KS C 5601、Unicodeの非CJK範囲、そして珍しい歴史的文字のMojikyoコレクションをカバーしていました。ユーザーはTRON文字リソースセンターを通じて新しい文字を無料で登録できました。これを比較のために言うと、1991年のUnicode 1.0は20,902個の統一CJK（中国語・日本語・韓国語）表意文字を定義しましたが、TRONのCJKカバレッジは10年以上Unicodeを上回っていました。その数の大部分はMojikyoから来ていましたが、Unicodeが単一のコードポイントに統合するバリアントグリフを個別にエンコードしていました。1996年のデモリリースには、プレーンを並べて表示する文字コードビューアが含まれており、その野心が最初から見て取れます：日本語基本、日本語補助、中国語GB、韓国語KSC、そして6点点字です。点字は、後から追加されたアクセシビリティアドオンではなく、ファーストクラスのプレーンとして存在しており、Unicodeは1999年のバージョン3.0まで点字パターンを全くエンコードしていませんでした。当時のTRON Codeは、業界が解決するのに何年もかかる問題に対する、誰にでもできる最良の答えでした。プロジェクトは実際の組織、1986年に設立されたTRON協会によって支援されていました。そのメンバーには、日立、三菱、富士通、NEC、松下、東芝…つまり、当時の主要な日本の電機メーカーがほぼすべて含まれていました。これらの国内企業に加えて、外国企業も参加でき、実際にいくつか参加しました。TRONはロイヤリティフリーで、仕様はオープンであり、これは後にITRONが普及することを可能にした意図的な選択でした。日本政府は通商産業省（MITI）を通じて、国家技術戦略としてこのプロジェクトを支援し、ほとんどのオペレーティングシステムプロジェクトが夢見るような機関的支援を与えました。これらのすべてに加えて、BTRONはデスクトップのためにラジカルなものを提案しました。 BTRONのデスクトップは、コンピューティングが実際に行った場所よりも何十年も先を行っていました ファイルとアプリケーションは実装の詳細でした BTRONの核となる考え方は、デスクトップコンピュータ上のユーザーに見えるプリミティブは、ファイルやアプリケーションではなく、タイプされた文書部分であるべきだということでした。言い換えれば、安定した識別子と宣言されたタイプを持つコンテンツのブロックです。パートは他のパートを含むことができ、レポートに図を埋め込むのと同じメカニズムで、ワークスペースにレポートを埋め込むことができます。これは、トップレベルのファイルに対する特別なケースがないことを意味します。このモデルはインターフェース全体で見られ、1B/V3ではコンテナをブラウズすると、各エントリの名前の後に括弧でタイプが表示されているのがわかります。例えば、「中国・韓国料理ガイド（図形）」という文書は、このファイルを画像として説明しています。これに対し、DOSでは拡張子が表示されていました。パートはタイプされたリンクで接続され、壊れやすい文字列パスではなく、システム管理のリンクストアに保存されていました。リンクはリネーム、編集、再編成を生き延び、アプリケーションはファイルの所有者ではなく、パートタイプのハンドラーでした。BTRON3仕様によると、アプリケーションIDの最初の2つのハーフワードはそれが適用されるデータタイプであり、3番目のハーフワードだけが同じタイプの競合するハンドラーを区別します。文書が文章、表、図を含んでいる場合、それらのパートを開くと、システムは各パートの登録済みハンドラーを起動して、親文書のウィンドウ内にその内容を描画します。ハンドラーが存在しない場合、またはハンドラーが描画に失敗した場合、システムはそのコンテンツが表示されるべき領域に斜線を引きます。BTRONはまた、ツリー構造のディレクトリ階層を任意の有向グラフに置き換える、リアルボディ/疑似ボディと呼ばれるファイルシステムモデルを使用しました。ファイルは、システムによってリンクされ、シンボリックリンクやショートカットではなく、重複なしで複数の場所に存在できます。日本語入力の基盤となる辞書は、料理ガイドと同じ方法でアドレス指定されます。ここで、TRONアプリケーションデータバスフォーマットは、共通ヘッダーを持つチャンク化されたセグメント構造を使用して、アプリケーション間で構造化データをやり取りします。そのため、スプレッドシートのセルとテキストの段落を、ユーザーがファイル形式を考える必要なしに、同じ文書に構成できます。アプリケーションは、サポートしないデータタイプをスキップできるため、相互運用性が中核的な側面となります。