2026年8月2日日曜日

マルダセナ論文とホログラフィー

1997年にフアン・マルダセナが提示したAdS/CFT対応は、量子重力研究における「ホログラフィー」を、比喩から具体的な理論関係へと移した提案である。その中心には、反ド・ジッター時空の内部に存在する重力理論と、その境界上に置かれた重力を含まない量子場理論とが、同一の物理情報を異なる記述によって表すという双対性がある。高次元の空間、弦、ブラックホールとして現れる現象が、一つ低い次元では粒子や演算子の相互作用として読み替えられる。

この対応を味わうためには、境界を単なる外縁としてではなく、内部世界の全情報を保持する面として眺める必要がある。奥行きは最初から与えられた絶対的なものではなく、量子状態の関係やエネルギー尺度から立ち現れる可能性がある。遠近をもつ時空が、より平面的な情報の編成から生成されるという反転に、この理論の美しさがある。

マルダセナ論文は厳密な証明ではなく予想として提出されたが、その後、内部の場と境界の演算子を結ぶGKPW辞書が整備され、ブラックホール熱力学、量子情報、物性理論などへ応用が広がった。ホログラフィーとは、宇宙が映像であるという主張ではない。異なる次元、異なる対象、異なる計算法のあいだに、失われることのない情報の対応を見いだす試みなのである。

関連キーワード
#JuanMaldacena　#AdSCFT対応　#ホログラフィー原理　#量子重力　#超弦理論　#反ドジッター時空　#共形場理論　#双対性　#GKPW辞書　#ブラックホール　#創発時空　#量子情報

2026年7月24日金曜日

「不定」を仕様として明記する設計思想 ― 自由度と責任の境界

プログラミング言語や通信規格の仕様書に現れる「不定」「未定義」「未規定」「処理系定義」といった記述は、一見すると設計の曖昧さや未完成さを示すように見える。しかし実際には、それらは仕様設計者が意図的に残した「自由領域」であり、性能、移植性、将来拡張性を両立するための重要な設計技法である。代表例としてC言語規格の未定義動作（Undefined Behavior）が挙げられる。配列外アクセスやNULLポインタ参照などについて、規格は結果を一切保証しない。この決定により、コンパイラは「そのような状況は起こらない」という前提で大胆な最適化を行うことができ、高性能な実装が可能となった。一方で、sizeof(int) のように処理系へ選択を委ねる「処理系定義」や、評価順序のように複数の結果を許容する「未規定」は、異なる目的を持つ概念である。これらはいずれも「何も決めていない」のではなく、「何を保証し、何を保証しないか」を精密に定義している点に本質がある。この考え方は、HTTPやTCP/IPなどのRFC、JavaScript仕様、CPUアーキテクチャ、さらには独自DSLやフレームワーク設計にも広く応用できる。仕様とは、利用者へ約束する境界を定める文書であり、「不定」の明記はその境界を明確化するための積極的な設計判断なのである。自由度を残すことは曖昧さではなく、実装者と利用者の責任範囲を整理する高度な契約設計と位置付けられる。

関連キーワード：仕様設計、Undefined Behavior（未定義動作）、Unspecified Behavior（未規定）、Implementation-defined Behavior（処理系定義）、Indeterminate Value（不定値）、ISO C、ECMAScript、RFC、コンパイラ最適化、評価順序、移植性、実装自由度、契約設計、DSL設計、API仕様

ROCK 5 Model Bは、Rockchip RK3588を中核に

ROCK 5 Model Bは、Rockchip RK3588を中核に、CPU、GPU、NPU、映像入出力、ネットワーク、ストレージ拡張を一枚の基板へ集約したシングルボードコンピュータである。Cortex-A76とCortex-A55を組み合わせた異種コア構成は、高負荷処理と省電力処理を役割分担させ、Mali-G610 GPUと機械学習推論用NPUは、画像処理やエッジAIを小型機器の内部へ持ち込む。

本機の興味深さは、完成されたパソコンでは見えにくい設計上の選択が、利用者の手元に露出している点にある。OSを書き込み、ストレージを選び、冷却機構を取り付け、電源容量を確保するという過程を通じて、計算性能が半導体だけで成立するものではなく、熱、電力、通信、ドライバ、筐体の均衡によって初めて維持されることが理解できる。

また、GPIO、UART、I²C、SPI、Ethernetなどの接続系統は、ROCK 5Bを単なる小型PCではなく、外部世界と信号を交換する組込み計算機として位置付ける。人工知能の推論結果がセンサー入力や機械動作へ接続されるとき、この基板は計算装置から制御装置へと性格を変える。その未完成さは欠点ではなく、内部構造を観察し、構成し、試行錯誤するために残された余白である。ROCK 5Bは、現代の計算機をブラックボックスとして消費せず、その層構造を部品の手触りとともに味わうための実験標本なのである。

関連キーワード：ROCK 5B、RK3588、シングルボードコンピュータ、ARM64、Cortex-A76、Cortex-A55、Mali-G610、NPU、エッジAI、組込みLinux、GPIO、UART、I²C、SPI、NVMe、熱設計、電源設計

Jetson Orin NX開発キットにみるロボットAI基盤の変化

Jetson Orin NX 16GB開発キットは、単なる小型Linuxコンピュータではなく、ロボットに知覚と判断を与えるためのエッジAI基盤として位置づけられる。最大157 TOPSとされる演算性能は、CPUの一般処理速度ではなく、GPUやDLAを用いた低精度ニューラルネットワーク推論能力を示す。その価値は数値そのものより、CUDA、TensorRT、cuDNN、Isaac ROSといったNVIDIAのソフトウェア体系を一体的に利用できる点にある。カメラ映像からの物体認識、姿勢推定、SLAM、音声処理、VLMによる状況理解などを、クラウドへ送らず機体上で実行できることは、通信遅延、プライバシー、自律性の面で重要である。

一方、ROCK 5Bのような汎用SBCと比較すると、消費電力、冷却、価格、環境構築の負担は大きい。したがって、単純な制御、通信、センサー収集には過剰であり、AI処理を必要とする部分だけをJetsonへ分離する構成が合理的である。ロボットの姿勢制御を直接担わせるのではなく、外界を認識し、行動候補を生成する上位計算機として用いることで、本機の特性は生かされる。これはロボットを「動く機械」から、「見て、解釈し、選択する機械」へ変える装置なのである。

関連キーワード： Jetson Orin NX、エッジAI、CUDA、TensorRT、DLA、Isaac ROS、ROS 2、VLM、SLAM、物体認識、姿勢推定、ロボティクス、組込みGPU、異種計算、自律移動

量子エンタングルメントと関連量子技術をサプライチェーン・トレーサビリティへ応用するための分析報告

# 量子エンタングルメントと関連量子技術をサプライチェーン・トレーサビリティへ応用するための分析報告

## エグゼクティブサマリー

量子エンタングルメントをサプライチェーン・トレーサビリティへ応用する発想は、**「モノを量子で追跡する」**というより、**「受け渡し関係と真正性を、計算困難性ではなく物理法則で証明する」**方向に本質があります。現在の実用系プロジェクトは、全履歴をエンタングルメントそのもので表現する段階には至っておらず、主流は **QKD による通信保護**、**QDS による真正性・非否認性**、**量子トークンによる移転・即時検証**、**量子 PUF による現物認証**です。したがって、当面の現実解は、台帳・ERP・イベントログなどの古典系基盤に、量子技術を“追加レイヤー”として組み込む**ハイブリッド構成**です。 citeturn12view0turn14view0turn16view0turn16view3turn16view7

研究面では、QDS は Gottesman–Chuang の理論提案から、量子メモリ不要化、QKD 部品互換、100 km 超の実用プロトコル、8 ユーザー entanglement-based ネットワーク、既設ファイバ上の ORNL 実証へと進展しました。一方で、**エンタングルメント・スワッピングを使って TRACE(A,B) と TRACE(B,C) から TRACE(A,C) を構成するような「関係証明の合成」**は、トレーサビリティ文脈ではまだ成熟した設計パターンではありません。ここが最も大きい研究余地です。 citeturn18view0turn29view0turn19view0turn19view1turn15view3turn14view0turn15view2turn1search0turn23view0

商用・準商用事例では、NEC・Quantinuum・三井物産の量子トークン実証、BT・東芝・EY のロンドン量子セキュア metro network、Orange Business・東芝のパリ商用量子セーフ網、Quantum Base の Q-ID 光学タグ、NTTドコモビジネス・東芝・NEC の東名阪 600 km 広域量子暗号通信実証が重要です。ただし、これらは**供給網全体の履歴証明**というより、**通信秘匿・真正性・現物認証・移転証明の個別機能**を扱っています。したがって、トレーサビリティに最も近い近未来アーキテクチャは、**量子 PUF + 台帳**または**量子トークン + 台帳**であり、エンタングルメント中心モデルは中長期 R&D テーマとして扱うのが妥当です。 citeturn16view0turn16view3turn16view5turn16view7turn17view2

## 技術背景と設計原理

量子トレーサビリティを考えるうえでの基礎は、エンタングルメント、エンタングルメント・スワッピング、QDS、QKD、量子トークン、量子 PUF、no-cloning 定理、そして情報理論的安全性です。エンタングルメントは複数粒子の状態を個別に独立では記述できない相関であり、Ekert の E91 はこの相関を鍵配送へ使う代表例でした。エンタングルメント・スワッピングは、互いに直接相互作用していない粒子間へエンタングルメントを“つなぎ替える”操作で、長距離量子ネットワークや将来の量子リピータの基礎概念です。他方、任意の未知量子状態は完全複製できないという no-cloning 定理が、QKD・量子トークン・量子 PUF の根本的な防偽性を支えます。 citeturn2search0turn1search0turn18view4turn20view0

QKD は、量子チャネルと通常の古典チャネルを併用して秘密鍵を共有し、盗聴があれば誤り率上昇として検知できる方式です。BB84 は準備測定型、E91 はエンタングルメント型の典型であり、ITU-T Y.3800 や ETSI GS QKD 014 は、QKD ネットワークや鍵配送 API の標準化を進めています。ただし、QKD は**認証そのもの**ではなく鍵配送であるため、実運用では認証された古典チャネル、鍵管理系、エンドポイント保護が不可欠です。英国政府の 2026 年報告も、QKD の理論保証はプロトコル・ハードウェア構成に依存し、エンドポイントや KMS の侵害は別問題だと整理しています。 citeturn20view0turn30view1turn21search0turn12view0

QDS は、暗号学的署名のうち **真正性、転送可能性、否認防止**を、計算量仮定ではなく量子物理で支える技術です。Gottesman–Chuang は量子公開鍵的な構想を示し、その後、長期量子メモリ不要化、QKD 部品での実装、認証済み量子チャネル不要化、既設ファイバ上の entanglement-based 実証へと進みました。サプライチェーンに引きつけると、QDS は「誰が、何を、どの条件で引き渡したか」を、転送可能な検証証跡として扱えるため、**chain of custody** の暗号層に最も近い量子技術です。 citeturn18view0turn29view0turn19view0turn19view1turn15view3turn14view0

量子トークンは、量子状態の複製不能性を利用して、**一回性・移転性・即時検証性**を備える証票を設計する系譜です。理論的には Bennett–Brassard の “unforgeable subway tokens” に遡り、近年は tokenized signatures や S-money 系で、量子メモリ不要・古典検証主体・短距離量子生成を組み合わせた現実化が進みました。NEC・Quantinuum・三井物産の 2024 年実証は、商用 QKD 機器と 10 km 光ファイバ上で発行・償還を確認した世界初の試行として重要です。トレーサビリティ文脈では、**所有権移転・受領証跡・高価値貨物の引換証**への親和性が高いと考えられます。 citeturn6search2turn19view2turn19view3turn16view0turn16view1turn16view2

量子 PUF は、製造ばらつきや量子スケールのランダム性を利用して、物理オブジェクトに複製困難な指紋を与える発想です。理論面では QR-PUF や qPUF の安全性定義が研究され、実用面では Quantum Base が Q-ID をスマートフォン読取可能な物理タグとして展開しています。サプライチェーンでは、QKD/QDS/量子トークンが**通信・権利・受け渡し**を保障するのに対し、量子 PUF は**現物と台帳レコードの結合**を担当します。これがないと、どれほど強い暗号証跡を持っていても、“記録は本物でも現物がすり替わっている”問題が残ります。 citeturn18view9turn14view5turn16view7turn31view0turn31view1

下図は、本報告でいう **entanglement-based relation-proof model** を概念的に図示したものです。これは既存の標準や製品名ではなく、**NIST の traceability chain の考え方**と、**entanglement swapping / QDS** を組み合わせて筆者が抽象化した設計概念です。現時点では研究提案段階のモデルとして読むのが適切です。 citeturn23view0turn1search0turn14view0turn15view3

```mermaid

flowchart LR

A[製造者 A] -->|古典イベントログ| B[物流者 B]

B -->|古典イベントログ| C[受領者 C]

QA[(A-B 関係状態)]

QB[(B-C 関係状態)]

QA --> S[Entanglement Swapping / 合成手続]

QB --> S

S --> QC[(A-C 合成関係証明)]

QC --> V[検証者]

V --> L[台帳・監査証跡]

```

技術とトレーサビリティの対応関係を凝縮すると、次のようになります。各要素は単独で万能ではなく、**通信層、証票層、現物層、台帳層**を分担するのが要点です。 citeturn12view0turn16view3turn16view7turn30view1

|---|---|---|---|

## 主要研究論文の整理

以下の表は、トレーサビリティ応用に近い順ではなく、**概念基礎 → QDS 実装 → ネットワーク化 → トークン/PUF → 総説**の流れで整理しています。右端に DOI または arXiv / 公式リンク情報を付しています。要約は原著・公式概要に基づく簡潔な注記です。 citeturn18view0turn19view0turn19view1turn15view3turn14view0turn19view4turn18view9turn14view5

| 年 | 論文 | 著者 | 短い注記 | トレーサビリティへの関連 | DOI / リンク |

|---|---|---|---|---|---|

| 2015 | *Quantum digital signatures with quantum key distribution components* | P. Wallden, V. Dunjko, A. Kent, E. Andersson | QKD と同等の実験要件で動く QDS を提示し、coherent forging 攻撃への証明を与えた。 | QKD 機材再利用により商用網への実装可能性を押し上げた。 | DOI 10.1103/PhysRevA.91.042304 / arXiv:1403.5551 citeturn19view0 |

| 2022 | *Unconditionally secure digital signatures implemented in an 8-user quantum network* | Y. Pelet ほか | trusted node なしの fully connected 8-user entanglement-based ネットワークで USS を実証。 | 多主体サプライチェーンに近いネットワーク条件での署名転送可能性を示した。 | DOI 10.1088/1367-2630/ac8e25 / arXiv:2202.04641 citeturn15view3 |

| 2023 | *Experimental quantum secure network with digital signatures and encryption* | H.-L. Yin ほか | 署名・秘密分散・会議鍵共有・情報理論的通信を統合した “all-in-one quantum secure network” を実証。 | トレーサビリティに必要な複数機能を単一ネットワークで束ねる好例。 | DOI 10.1093/nsr/nwac228 / arXiv:2107.14089 citeturn15view4 |

| 2023 | *Quantum Tokens for Digital Signatures* | S. Ben-David, O. Sattath | tokenized signature を体系化。不可複製の署名トークン、revocability、testability、everlasting security を議論。 | 受け渡しの“一回性”と署名権限の移転を設計する理論基盤。 | DOI 10.22331/q-2023-01-19-901 / arXiv:1609.09047 citeturn19view2turn19view6 |

| 2024 | *Entanglement-based quantum digital signatures over a deployed campus network* | J. C. Chapman, M. Alshowkan, B. Qi, N. A. Peters | 既設 campus fiber で entanglement-based QDS を 25 時間測定。QBER <5% が多く、50 km 超への可能性を示した。 | “既設ファイバ上で関係証明を回す”という観点で最重要の現場実証。 | DOI 10.1364/OE.511503 / arXiv:2310.19457 citeturn14view0turn15view2turn3search8 |

この文献群から読める流れは明瞭です。QDS は **理論提案 → 量子メモリ不要化 → QKD 互換化 → 実用距離化 → 多主体ネットワーク化 → 既設ファイバ実証** と進み、量子トークンは **理論成熟 → 実験実証 → 企業 PoC** へ、量子 PUF は **理論整理 → 物理タグ商用化** へ進んでいます。しかし、**エンタングルメント自体をチェーン全体の traceability object として合成・継承するプロトコル**は、まだ主要文献の中心にはなっていません。 citeturn14view0turn15view3turn19view2turn19view3turn14view5

## 企業プロジェクトと実証の整理

企業・機関プロジェクトは、技術成熟度を見るうえで文献より実務的です。下表では、**何を守っているのか**を、通信・証票・現物・広域基盤に分けて示します。 citeturn16view0turn16view3turn16view5turn16view7turn17view2turn28view0

|---|---|---|---|---|---|---|

企業事例の共通点は、**量子技術を単独で完結させず、既存ネットワーク・KMS・PQC・台帳・スマホ等と結びつけている**点です。逆に言えば、現時点で「エンタングルメントだけでサプライチェーン全履歴を保証する製品」は見当たりません。実用化は、通信保護、証票移転、現物認証というサブ機能ごとに進み、その後に統合される可能性が高いと読むのが妥当です。 citeturn16view3turn16view5turn16view7turn17view2turn12view0

## アーキテクチャ比較

現実的な設計候補は、少なくとも四つに分かれます。評価軸は、台帳統合、必要装置、遅延、スケーリング、どこを物理法則で守れてどこが古典系の信頼前提に残るか、です。以下では、**実用可能性の高い順に**並べています。なお、TRACE composition は既存の標準名称ではなく、本報告の分析用ラベルです。 citeturn14view3turn16view0turn16view7turn23view0turn1search0

|---|---|---|---|---|---|---|---|

| entanglement-based relation-proof model | 受け渡し関係自体を量子関係として扱い、スワッピングで合成可能とみなす。 | entanglement source、Bell 測定、同期、低損失リンク、場合によって量子メモリ。 citeturn1search0turn13search1turn13search4 | 現状は低い。ユーザー数増で entanglement rate が希薄化。 citeturn15view2 | 高い。量子生成、測定、古典通知の往復が必要。 | 関係証明を履歴そのものへ近づけ得る。理論的には非常に魅力的。 | 光子損失、デコヒーレンス、同期ずれ、誤った関係合成。 | 実装成熟度が不足。標準・商用装置・評価法が未整備。 |

比較して最も現実的なのは、**量子 PUF + 台帳**と**QKD/QDS を重ねたハイブリッド通信基盤**です。前者は現物認証に直結し、後者は組織間記録の保護に直結します。これらを結び付ければ、現物と記録の両方を守れます。反対に、entanglement-based relation-proof は概念的には最も新規性がありますが、現状では研究テーマであり、パイロットへ直結させるには無理があります。 citeturn16view7turn31view0turn14view3turn12view0turn15view2

TRACE composition という発想の価値は、NIST が示す古典的な traceability chain が**「前レコードへのリンクの連鎖」**であるのに対し、量子版では**「関係状態の合成」**という別の表現を与えられる点です。古典台帳では履歴は事後記録ですが、量子関係モデルでは受け渡しがその場で新たな検証可能関係を生成しうる、という違いがあります。もっとも、これは現時点では工学的優位がまだ実証されていないため、まずは NIST 型の hash-link 方式に量子署名・量子タグ・量子トークンを重ねる方が合理的です。 citeturn23view0turn1search0turn14view0turn16view0turn16view7

## 実装課題と現実的制約

最大の制約は、依然として**光子損失と距離依存性**です。ORNL の entanglement-based QDS 実証は、25 時間測定で多くの場合 QBER が 5% 未満であり、理論上 50 km 超の可能性を示した一方、現実装では署名率が低いことも明記しています。ロンドンの商用 metro network でも、顧客接続はおおむね 30 km 圏、長距離システムは標準単一モードファイバで典型 120 km とされており、現行商用ファイバ網では距離と鍵生成率・署名率のトレードオフが依然強いことがわかります。 citeturn14view0turn15view2turn14view3

長距離化の本命は量子リピータですが、そこでは**量子メモリ**が主要ボトルネックです。NIST は、古典リピータと異なり未知量子状態は複製できず、量子リピータは量子メモリや特殊な状態に依存すると整理しています。2023 年の *Rev. Mod. Phys.* でも、量子リピータは損失と雑音を克服する中核装置として位置づけられますが、実用化はなお難しいとされます。したがって、サプライチェーンの近中期用途では、**全国規模のエンタングルメント網を待つより、都市圏・拠点間・重要区間に限定した設計**の方が現実的です。 citeturn13search1turn13search4turn13search8

また、QKD/QDS は量子チャネルだけでは完結しません。BB84 原典も量子チャネルと通常の古典チャネルの併用を前提にしており、英国政府報告は、QKD には認証の問題が残るため、実運用では古典チャネル上の認証機構と切り離せないと述べています。さらに同報告は、盗聴検知の利益は主として量子チャネルそのものに限られ、エンドポイント、KMS、古典ネットワークの侵害は別対策が必要だと整理しています。つまり、量子技術は**ゼロトラスト設計を不要にする魔法**ではなく、むしろエンドポイント統制の重要性を高めます。 citeturn20view0turn12view0

標準化は前進していますが、まだ完全ではありません。ITU-T Y.3800 は QKDN の設計・配備・運用・保守を支援する標準的枠組みを与え、ETSI GS QKD 014 は REST ベースの鍵配送 API を定義しています。日本では NICT・NEC・東芝が Y.3800 の骨格形成に大きく関与しており、QKD ネットワーク標準化では国際的に強い立場を持ちます。とはいえ、**QDS、量子トークン、量子 PUF を横断した traceability evidence schema** は未整備で、ここが実装面の空白です。 citeturn30view0turn30view1turn21search0turn24view3

コストについては、公表価格が乏しいため、以下は**公開された助成上限・実証規模・政府調査に基づくオーダー推定**です。英国政府報告は、QKD の光学部品、とりわけ高性能検出器は高価で、アクセス点ごとに物理装置が必要なため、スケールとともに費用が大きく増すと指摘しています。さらに、EuroQCI の 2025 公募は 1 プロジェクトあたり約 500 万ユーロ規模を想定し、EU の IRIS² QKD マイクロサテライト入札は 2,500 万ユーロ規模です。これらを踏まえると、量子トレーサビリティのコスト感は次の程度が妥当です。 citeturn12view0turn22search1turn11search5

| 導入レベル | 公開資料からみたオーダー感 | 根拠の読み方 |

|---|---|---|

| 拠点間 site-to-site PoC | おおむね **10^5〜10^6** ユーロ/ドル級 | 参加組織単位の OPENQKD 参画費用・高価な光学機器・人材統合費を考えると、この帯域が自然。 citeturn25view0turn12view0 |

| 都市圏 multi-site pilot | **10^6〜10^7** ユーロ級 | EuroQCI の公募上限が約 500 万ユーロ/件であり、複数ノード・既設網統合・運用監視込みならこの帯が妥当。 citeturn22search1turn14view3 |

| 広域 backbone / national / space-linked | **10^7** ユーロ超級 | IRIS² の QKD マイクロサテライト入札が 2,500 万ユーロ規模。広域幹線や衛星連携は一段上の投資帯。 citeturn11search0turn11search5 |

さらに、トレーサビリティへ適用する場合は、量子装置の費用だけでなく、**製品識別子体系、監査 API、規制適合、教育、現場オペレーション、保険・責任分界**の費用が上乗せされます。英国政府報告も、QKD は plug-and-play ではなく、新しいスキル・プロセス・商用モデルを必要とするため、費用評価は装置単価だけでは不十分だと指摘しています。 citeturn12view0

## 研究ギャップと具体的研究方向

現状の空白は、**通信保護・証票移転・現物認証が個別最適で進んでおり、トレーサビリティ全体へ統合されていないこと**です。とくに不足しているのは、エンタングルメントによる relation proof を、台帳・ERP・現物タグ・法的証跡へ橋渡しする設計です。以下に、エンタングルメント中心のトレーサビリティを前進させるための、具体的で測定可能な六つの研究課題を示します。成功基準は本報告での提案値であり、既存実証の性能水準や標準化状況を踏まえて設定しています。 citeturn14view0turn15view3turn16view0turn16view7turn30view1turn12view0

|---|---|---|---|---|

| TRACE 合成プロトコルの最小実証 | A-B、B-C の entanglement-based relation を Bell 測定で合成し、A-C の検証可能受け渡し証明を生成する 3 ノード実験。 | relation 合成成功率、QBER、false accept / false reject、合成遅延 | 合成後検証成功率 > 99%、QBER は ORNL 実装と同等の 5% 未満を目標、端末間追加遅延 < 1 s | エンタングルメント・スワッピングを traceability に直接接続する最初の核。 citeturn1search0turn15view2 |

| マルチパーティ供給網での trusted-node 削減 | 5〜8 主体の量子ネットワークで、trusted node なし・少数 trusted node・fully classical relay を比較検証。 | ノード数対性能、攻撃面、運用複雑性、証跡の転送可能性 | 5 主体以上で運用可能、trusted node 削減で security gain を定量化 | 実際の供給網は二者間ではなく多主体であるため。 citeturn15view3turn14view3 |

| 標準化・法的証拠化インタフェース | ETSI 014 鍵配送 API、QKDN 標準、監査証跡、電子文書保存ルールを接続する evidence schema を設計。 | 相互運用性、第三者監査通過率、ログ完全性、実装工数 | 2 ベンダー以上相互接続、外部監査で完全性確認、実装ガイド公開 | 技術が動いても証拠として通らなければ traceability 価値が出ない。 citeturn21search0turn30view1turn23view0 |

研究ギャップを一言でまとめれば、**“量子安全な点対点”は前進しているが、“量子安全な供給網オブジェクト”はまだ未完成**です。今後の突破口は、エンタングルメント・スワッピングそのものより、**QDS、量子トークン、量子 PUF、DLT をどう束ねて評価するか**にあります。つまり、問題は物理だけでなく、プロトコル工学・監査工学・制度設計の複合問題です。 citeturn1search0turn14view0turn16view0turn16view7turn23view0turn12view0

## 開発ロードマップ

現実的なロードマップは、いきなり全国規模の entanglement-based traceability を狙うのではなく、**現物認証 → 受け渡し証票 → 拠点間量子保護 → 関係証明合成**の順に登るべきです。理由は明快で、QKD はすでに標準と実証網を持ち、量子 PUF は現物認証で導入しやすく、量子トークンは高価値イベントへ限定すれば投資対効果を出しやすい一方、エンタングルメント合成型はまだ研究的だからです。 citeturn30view0turn21search0turn16view7turn16view0turn14view0

関係者は、量子通信ベンダー、タグ/ラベル供給者、荷主、物流事業者、金融・保険、監査法人、規制当局、標準化団体、大学/国研です。必要資源は、既設ファイバアクセス、QKD/QDS テストベッド、現場読取端末、監査基盤、PoC 予算、そして運用担当者教育です。日本であれば、NICT・NEC・東芝・通信事業者・荷主側 IT ベンダーが中核候補になります。 citeturn17view2turn30view0turn28view0

以下は、約 4 年を想定した R&D と pilot の提案タイムラインです。前半は量子 PUF / token / QKD の実務統合、後半で entanglement-based relation proof に踏み込みます。これは既存技術成熟度に基づく提案スケジュールです。 citeturn12view0turn14view0turn16view0turn16view7turn17view2

```mermaid

gantt

title 量子トレーサビリティ R&D とパイロットの提案タイムライン

dateFormat YYYY-MM-DD

axisFormat %Y-%m

section 企画と要件定義

ユースケース選定と脅威分析 :a1, 2026-10-01, 120d

証跡要件と法務整理 :a2, 2026-11-01, 150d

標準APIと監査スキーマ設計 :a3, 2027-01-01, 180d

section 近接実装

量子PUFタグと台帳の統合PoC :b1, 2027-01-15, 210d

量子トークン限定PoC :b2, 2027-04-01, 180d

サプライチェーン現場の運用評価 :b3, 2027-08-01, 150d

section 拠点間量子保護

QKD/KMS統合リンク構築 :c1, 2027-04-01, 240d

QDSベース受け渡し証明PoC :c2, 2027-10-01, 210d

既設ファイバ共存試験 :c3, 2027-11-01, 180d

section 関係証明の高度化

TRACE合成の3ノード実験 :d1, 2028-04-01, 210d

多主体ネットワーク拡張 :d2, 2028-10-01, 240d

監査・保険・規制当局レビュー :d3, 2029-01-01, 180d

section パイロット展開

高価値貨物向け限定パイロット :e1, 2029-04-01, 270d

KPI評価と再設計 :e2, 2029-10-01, 150d

商用化判断ゲート :e3, 2030-03-01, 90d

```

パイロット KPI は、**現物一致率、受け渡し否認率、二重償還・二重登録率、監査再現率、イベント当たり追加遅延、PoC 区間あたり運用費、既存システム改修量**を中心に置くべきです。実装判断の閾値としては、量子 PUF 層で現物一致率 99.9% 級、受け渡しイベントの監査再現率 100%、量子セキュリティ由来の追加遅延が業務 SLA 内、そして古典台帳だけでは防げなかった偽造・否認・すり替えを有意に減らせることが必要です。 citeturn16view7turn23view0turn16view0turn14view0turn12view0

総括すると、エンタングルメントをサプライチェーン・トレーサビリティへ応用することは、**原理的には十分に魅力的で、周辺技術も着実に育っている**一方で、**直接的な商用完成形はまだ存在しない**段階です。いま最も有望なのは、量子 PUF、量子トークン、QDS、QKD を**台帳・監査・既設ファイバ網へ段階統合するハイブリッド路線**であり、エンタングルメント・スワッピングによる TRACE 合成は、その次の世代を切り開く研究テーマとして位置づけるのが最も合理的です。 citeturn16view7turn16view0turn14view0turn17view2turn12view0

2026年7月23日木曜日

GLSLは誕生時からvoid main()を唯一の入口として固定し、C言語に近い統一的な実行モデルを採用した

シェーダープログラミングにおける「入口関数が一つ存在する」という設計は、一見するとHLSLやGLSLによって突然導入されたように見える。しかし、その思想は1980年代の映画用レンダリング言語まで遡ることができる。RenderMan Shading Languageでは、surfaceやlightなどのシェーダー自体が一つの実行単位であり、各シェーディング点に対して独立に評価される構造を持っていた。これは現在のフラグメントシェーダーと本質的に同じ「多数のデータに対して同一の処理を適用する」というSIMD的発想である。一方、1990年代末のGPUでは、テクスチャコンバイナやRegister Combinersによって固定回路を組み合わせる方式が主流であり、プログラムというより配線に近いモデルであった。その後、DirectX 8やOpenGL ARB_fragment_programではアセンブリ形式の命令列が導入され、GPUを命令列で制御できるようになったが、この段階ではまだ入口関数という概念は存在せず、ファイル全体が一つのプログラムとして先頭から実行された。転機となったのは2002年前後のCgおよびHLSLであり、GPUプログラムがC言語風の構文を持つ高水準言語へと抽象化されたことで、関数・型・構造体を備えたソフトウェア的な設計が可能となった。HLSLでは入口関数名は任意であり、コンパイル時に指定される。一方、GLSLは誕生時からvoid main()を唯一の入口として固定し、C言語に近い統一的な実行モデルを採用した。したがって、「mainが一つ」という現在のGLSLの様式は、レンダリングアルゴリズムの進化というより、GPUを一般的なプログラミング対象へと昇華する過程で生まれた言語設計上の到達点と位置付けることができる。関連キーワード

RenderMan Shading Language (RSL)
REYES
Texture Combiner
Register Combiners
NVIDIA Cg
HLSL
GLSL
ARB_fragment_program
Pixel Shader
Fragment Shader
GPU Assembly
Shader Model
OpenGL 2.0
DirectX 9
エントリーポイント
main() 関数
SIMD
データ並列処理
高水準シェーディング言語
プログラマブルGPU

NESASMとNessembleはいずれも、6502系CPUを用いるファミコン向けプログラムをROMへ変換するアセンブラである

NESASMとNessembleはいずれも、6502系CPUを用いるファミコン向けプログラムをROMへ変換するアセンブラである。しかし両者の差は、単なる新旧ではなく、開発思想と記述体系の違いにある。NESASMは、.bankによって8KB単位の出力領域を切り替え、.orgでCPUまたはPPU上の配置先を指定する。ギコ猫でもわかるファミコンプログラミングをはじめ、多くの古典的教材はこの構造を前提としており、PRG-ROMとCHR-ROMを物理的なバンクの並びとして意識させる。これに対してNessembleは、.prg、.chr、.segmentなどによって領域の意味を明示し、Rust、WebAssembly、LSP、メディア取込みといった現代的な開発環境へ接続する。6502の命令、PPUレジスタ、VBlank待機など、ファミコンそのものの原理は変わらないが、ローカルラベル、マクロ、インクルード、ROM配置の構文には互換性がない。したがってNESASMのソースをNessembleへ移す作業は、単なる記号置換ではなく、当時の「ROMを区画へ詰める」感覚を、現在の「意味を持つセグメントとして構成する」感覚へ翻訳する行為といえる。古い教材をNESASMで味わうことは当時の制作工程を追体験することであり、Nessembleで再構成することは、その知識をブラウザ上の実験環境へ蘇らせる試みである。

関連キーワード： NESASM、Nessemble、6502、ファミコン、iNES、PRG-ROM、CHR-ROM、バンク、.org、.prg、.chr、PPU、VBlank、アセンブラ方言、WebAssembly、JSNES、レトロゲーム開発、ソース移植

2026年7月22日水曜日

レオナルド・ダ・ヴィンチ『絵画論』における空気遠近法

レオナルド・ダ・ヴィンチ『絵画論』における空気遠近法 ― 視覚科学としての絵画理論

レオナルド・ダ・ヴィンチが遺した『絵画論（Trattato della Pittura）』は、単なる絵画技法書ではなく、人間が世界をどのように知覚するかを探究した視覚科学の記録でもある。なかでも空気遠近法の記述は、遠方の物体が青みを帯び、輪郭が曖昧となり、明暗や色彩の対比が弱まる現象を、観察者と対象物との間に存在する「空気」の働きとして説明した点で画期的であった。これは、建築物や道路の消失点によって空間を構成する線遠近法とは異なり、光、大気、水蒸気、塵などの媒質が視覚へ及ぼす影響を描写へ取り込もうとする試みである。レオナルドは自然観察を繰り返し、山並みや大気の色の変化を実証的に記録し、画家は物体だけでなく、その間に満ちる空気まで描かなければならないと考えた。この発想は17世紀の風景画家クロード・ロラン、さらに19世紀のターナーや印象派へ受け継がれ、光と大気を主題とする風景表現へ発展する。また現代では、大気散乱モデルやボリュームレンダリング、レイマーチングなどコンピュータグラフィックスの理論とも対応関係を見いだすことができ、レオナルドの洞察が五百年以上を経てもなお視覚表現の基盤として生き続けていることを示している。

関連キーワード
レオナルド・ダ・ヴィンチ、絵画論、Trattato della Pittura、空気遠近法、大気遠近法、線遠近法、光学、視覚科学、自然観察、大気散乱、青色散乱、コントラスト、輪郭、風景画、クロード・ロラン、J.M.W.ターナー、印象派、ボリュームレンダリング、レイマーチング、コンピュータグラフィックス

レイトレーシングとレイマーチング

レイトレーシングとレイマーチングは、いずれも視点から放たれたレイ（光線）を用いて画像を生成する技法であるが、その本質的な違いは「交点を解析的に求めるか」「反復的に探索するか」にある。レイトレーシングは、球や三角形など幾何学的に定義された物体との交差を数式として解き、最初の衝突位置を直接決定する。したがって、ポリゴンモデルを中心とする現代CGや映画制作において、高精度な反射・屈折・影の計算に適している。一方、レイマーチングは、空間上の各点で「物体までの距離」を返す距離関数（SDF）や密度場を評価し、その距離だけレイを前進させながら表面や内部構造を探索する。この反復過程は、未知の形状へ近づいていく探索アルゴリズムとして理解でき、複雑な数式曲面やフラクタル、滑らかな形状合成などを容易に表現できる点に特徴がある。

芸術史的な比喩を用いるなら、レイトレーシングはルネサンス以降の遠近法のように、空間構造を幾何学的に確定する手法に近い。それに対し、ボリュームレイマーチングは、光が空気中を伝播する過程を微小区間ごとに積算するため、空気遠近法との対応が見出せる。遠景ほど青みを帯び、輪郭や明暗差が失われる現象は、大気による散乱・吸収をレイに沿って積分する結果として自然に再現される。したがって、レイマーチングは単なる「遅いレイトレーシング」ではなく、空間を距離場や媒質として捉え直す計算思想であり、映画における雲・煙・炎・霧の表現からShaderToyに代表される数式アートまで、現代コンピュータグラフィックスに新たな造形言語をもたらした技法として位置づけられる。

関連キーワード

レイトレーシング（Ray Tracing）
レイマーチング（Ray Marching）
ボリュームレイマーチング
ボリュームレンダリング
符号付き距離関数（SDF）
距離場（Distance Field）
レイ・サーフェス交差判定
ポリゴンレンダリング
BVH（Bounding Volume Hierarchy）
フラクタルレンダリング
レイ積分
光輸送（Light Transport）
散乱（Scattering）
吸収（Absorption）
空気遠近法
線遠近法
解析的交差判定
距離推定法（Distance Estimation）
ShaderToy
プロシージャルモデリング

Physically Based Rendering（PBR）は、映画のためだけに発明されたものではなく、光学や物理学に基づく反射理論をCGへ取り入れる長年の研究成果であり、

コンピュータグラフィックス（CG）の歴史を振り返ると、その発展は単なる計算能力の向上ではなく、「映画で何を表現したいか」という要求と、「数学・物理・情報科学が提供する理論」との相互作用によって形作られてきたことが分かる。例えば、Perlin Noise は、人工的で均質なCG表現に自然界の揺らぎを与えるために考案され、雲や煙、岩肌、木目といった質感表現を可能にした。Boids は、多数の鳥や魚を一体ずつアニメーションする限界を克服するため、局所的な三つの規則から群れ全体の秩序を創発させる分散アルゴリズムとして提案された。一方、Physically Based Rendering（PBR） は、映画のためだけに発明されたものではなく、光学や物理学に基づく反射理論をCGへ取り入れる長年の研究成果であり、映画制作がその実用化を強力に後押しした技術体系である。また、レイマーチングは、距離関数や体積データを数値的に探索する手法として、科学可視化や医療画像とも共通の基盤を持ち、映画では煙・雲・炎など境界の曖昧な現象の描画に活用された。これらはいずれも「映画のためだけ」に生まれたわけではないが、映画産業は従来の技術では実現困難な映像表現を次々と要求することで、新しい理論やアルゴリズムの実験場となり、その成熟を加速させた。CG史とは、数学が映像へ翻訳される歴史であると同時に、映像表現が新たな数学的発想を刺激してきた歴史でもある。この相互作用こそが、現代のリアルタイムレンダリングやゲームエンジン、VFXに至る技術基盤を築いたのである。

2026年7月12日日曜日

WebAssembly 3.0

公式サイト・公式ドキュメント優先で一覧にします。現在の共通仕様は WebAssembly 3.0 です。

WebAssembly共通仕様

WASI・Component Model

WITは、Component Modelのインターフェースやworldを定義するIDLです。

C / C++

Emscripten

EmscriptenはLLVMを利用し、C/C++をブラウザ、Node.js、Wasmランタイム向けにコンパイルする総合ツールチェーンです。

Clang / LLVM

Rust

wasm-bindgenはRustとJavaScript間の高水準な型変換・関数接続を担当します。

Zig

Zigでは主に次のターゲットを使います。


wasm32-freestanding
wasm32-wasi
wasm64-freestanding
wasm64-wasi

現状、WebAssembly専用の独立した公式入門ページは少なめで、言語リファレンスとターゲット指定を参照する形です。

AssemblyScript

AssemblyScriptはTypeScriptそのものではなく、Wasmを直接ターゲットにしたTypeScript風言語です。

Go

ブラウザ向け：


GOOS=js GOARCH=wasm go build

WASI向け：


GOOS=wasip1 GOARCH=wasm go build

Go 1.24では、WASI向け関数exportなどWasm連携機能が追加されています。

TinyGo

Go標準より小さなWasmを作りたい場合はこちらです。

C# / .NET / Blazor

Blazor公式ドキュメント
Blazor WebAssembly概要
Blazor WebAssembly入門
Blazor WebAssemblyのAOTコンパイル
JavaScript相互運用
.NET WebAssembly native dependencies
.NET Runtime GitHub
ASP.NET Core GitHub

Blazor WebAssemblyはブラウザ内で.NETランタイムとC#アプリケーションを実行でき、AOTコンパイルにも対応しています。

Kotlin

Kotlin/Wasmには、ブラウザ向けのwasm-jsとWASI向けのターゲットがあります。

Swift

Swift公式には、ブラウザ向けとWASIランタイム向けのWebAssembly SDK手順があります。

Python

Pyodide

PyodideはCPythonとPythonパッケージ群をWasm化し、ブラウザやNode.jsで実行する仕組みです。

CPython本体

Java

TeaVM

TeaVMはJavaバイトコードを入力にして、JavaScriptまたはWebAssemblyへAOTコンパイルします。KotlinやScalaのクラスファイルも入力可能です。

CheerpJ

実行ランタイム

Wasmtime

WasmEdge

Wasmer

WAMR

組み込み機器やマイコンでは重要です。

wasm3

小型インタプリタです。

wasm3 GitHub

Wazero

Goだけで実装されたWasmランタイムです。

言語	名称	正体	単体／複合
Rust	`rustc`	コンパイラ	単体
Rust	`wasm-bindgen`	JS相互運用ライブラリ＋CLI	複合寄り
Rust	`wasm-pack`	ビルド・パッケージ化CLI	単体
Rust	`web-sys`	Web APIバインディング	単体
Rust	`js-sys`	JS標準APIバインディング	単体
C/C++	Emscripten	コンパイラツールチェーン	複合
C	`emcc`	C向けコンパイラドライバー	構成要素
C++	`em++`	C++向けコンパイラドライバー	構成要素
AssemblyScript	AssemblyScript	言語・ランタイム・ツール群	複合
AssemblyScript	`asc`	コンパイラCLI	単体
Go	`js/wasm`	ブラウザ向けターゲット	名称
Go	`wasip1/wasm`	WASI向けターゲット	名称
Go	`syscall/js`	JS相互運用パッケージ	単体
TinyGo	TinyGo	Go用別コンパイラツールチェーン	複合
TinyGo	`wasm`	ブラウザ向けターゲット	名称
TinyGo	`wasip1` / `wasip2`	WASI向けターゲット	名称
Zig	Zig	言語・コンパイラ・ビルドツール	複合
Zig	`wasm32-freestanding`	ターゲット指定	名称
Kotlin	Kotlin/Wasm	KotlinのWasmバックエンド	構成要素
Kotlin	`wasmJs`	ブラウザ向けGradleターゲット	名称
Kotlin	`wasmWasi`	WASI向けGradleターゲット	名称
Kotlin	Compose Multiplatform	UIフレームワーク	複合
.NET	Blazor WebAssembly	Webアプリフレームワーク	複合
.NET	.NET WebAssembly runtime	.NETランタイム	構成要素
.NET	Interactive WebAssembly	レンダーモード	名称
.NET	WebAssembly AOT	コンパイル方式	名称
Python	Pyodide	Python/Wasmディストリビューション	複合
Python	CPython	Python処理系	複合
Ruby	`ruby.wasm`	CRubyのWasm移植群	複合
Ruby	CRuby	Ruby処理系	複合
Swift	Swift SDKs for WebAssembly	公式Wasm SDK	複合
Swift	Swift for WebAssembly	分野・対応全体の名称	名称
Swift	SwiftWasm	コミュニティプロジェクト	複合
Swift	JavaScriptKit	JS相互運用ライブラリ	単体

M5Stack / ESP32でWebAssemblyを扱う際によく使われるリポジトリ・公式サイト

以下は M5Stack / ESP32でWebAssemblyを扱う際によく使われるリポジトリ・公式サイト のリンク集です。

M5Stack向けサンプル

M5Stack Core2 + wasm3 + AssemblyScript

M5Stack Core2でWebAssemblyを実行する代表的なデモです。

m5stack-core2-wasm3-as (GitHub)

M5Stamp C3 + WAMR

RISC-V版(M5Stamp C3)向けです。

m5stamp-c3wamr (GitHub)

旧版 M5Stack wasm3

初期の実験版です。

m5stack-wasm3-testing (GitHub)

ランタイム

WAMR (WebAssembly Micro Runtime)

Bytecode Alliance系の軽量ランタイム。

wasm3

ESP32で最も普及している軽量インタプリタです。

wasm3 GitHub

M5Stackライブラリ

M5Unified

現在の標準ライブラリです。

M5Unified

M5GFX

高速LCDライブラリ。

M5GFX

旧M5Stackライブラリ

現在は非推奨ですが参考になります。

M5Stack Arduino Library

開発環境

ESP-IDF

ESP32公式SDK

ESP-IDF

Arduino-ESP32

Arduino環境

Arduino-ESP32

PlatformIO

IDEを問わず開発可能です。

PlatformIO

Wasmを生成する言語

解説記事

M5StackでAssemblyScript + wasm3を動かした作者本人の記事です。

マイコンMCUでAssemblyScript + Wasm3を動かす

用途	おすすめ
学習・デモ	wasm3 + AssemblyScript
本格開発	WAMR + ESP-IDF
Arduino中心	WAMR-ESP32
Goで開発	TinyGo
Rustで開発	WAMR + Rust

項目	内容	技術資料
統一API	OpenAI互換APIでOpenAI、Anthropic、Google、Mistralなど多数のモデルを同じインターフェースで利用できる。	API Overview
OAuth (PKCE)	ユーザーがOpenRouterへログインし、あなたのアプリへ認可。認可コードからユーザー専用APIキーを取得できる。第三者アプリ向け認証基盤。	OAuth PKCE Guide
BYOK (Bring Your Own Key)	ユーザー自身のOpenAI・Anthropic・Google・Azure・AWS BedrockなどのAPIキーを登録し、そのキー経由でモデルを利用できる。キーは暗号化保存。	BYOK Documentation
ルーティング	モデルやプロバイダーを自動切替。優先順位やフォールバックも設定可能。	BYOK Documentation
APIキー管理	APIキーごとに名称、用途、クレジット上限を設定。OAuthでも利用可能。	Authentication API
Management API	SaaSがエンドユーザーごとのAPIキーを自動生成・削除・上限変更できる管理API。	Management API Keys FAQ

項目	内容	資料
通常利用	OpenRouterクレジットから従量課金。モデル料金は各プロバイダー価格を基本とし、推論料金への上乗せはない（クレジット購入時に手数料あり）。	Pricing FAQ
BYOK	月100万BYOKリクエストまでは無料。それ以降は、同一モデル・プロバイダー価格の5%をOpenRouterクレジットから徴収。	BYOK Documentation
アプリ別上限	APIキーごとにクレジット上限を設定できる。ユーザー単位・アプリ単位の利用制御が可能。	Authentication API

まず見るべき公式サンプル

1. OAuth PKCE公式ガイド

OpenRouter OAuth PKCE Guide

今回のユースケースに最も直接対応しています。

公式フローは次の3段階です。


1. ユーザーを https://openrouter.ai/auth へ送る
2. コールバックで認可コードを受け取る
3. 認可コードをユーザー管理APIキーへ交換する

OpenRouterでは事前のOAuthクライアント登録やclient_secretを要求せず、PKCEのcode_verifierとcode_challengeを使います。localhostの任意ポートもコールバック先として利用できます。

公式の認可URLは次の形です。


https://openrouter.ai/auth
  ?callback_url=https://example.com/callback
  &code_challenge=...
  &code_challenge_method=S256

認可後、次のエンドポイントでコードをキーへ交換します。


POST https://openrouter.ai/api/v1/auth/keys
Content-Type: application/json

{
  "code": "認可コード",
  "code_verifier": "PKCEの元文字列",
  "code_challenge_method": "S256"
}

レスポンスのkeyが、そのユーザーのOpenRouter APIキーです。

2. Sign In with OpenRouter公式リポジトリ

GitHub: OpenRouterTeam/sign-in-with-openrouter

これがOAuth実装の公式リファレンスです。

含まれるもの：

PKCEコード生成
OpenRouterへのリダイレクト
認可コード交換
APIキー保存
React用ContextとHook
サインインボタン
クロスタブ同期
SSR対策
エラー処理

リポジトリ内の主要箇所は次のとおりです。


src/lib/
  OpenRouter OAuthの本体

src/components/
  Sign In with OpenRouterボタン

src/hooks/
  OpenRouterAuthProvider
  useOpenRouterAuth

src/demo/
  実行可能なデモ

この公式例はバックエンド不要で、取得したキーをlocalStorageに保存します。ただし公式READMEも、ページ内のJavaScriptからキーを読めるため、本番利用ではCSPやXSS対策が必要だと明記しています。

デモ：

3. OpenRouter公式の完成アプリ例

GitHub: OpenRouterTeam/multimedia-explorer

これは単なる断片ではなく、不特定多数のユーザーがOAuthでOpenRouterへ接続する完成アプリです。

主な実装：

OpenRouter OAuth 2.0＋PKCE
ユーザー本人のOpenRouterクレジット利用
テキスト・画像・動画モデルの動的取得
APIルートからのモデル呼び出し
非同期動画ジョブのポーリング
React Hookによる認証状態管理

特に参考になるファイル構成は次です。


lib/openrouter-auth.ts
  OAuth 2.0 PKCE処理

lib/openrouter.ts
  SDKクライアント生成

hooks/use-openrouter-auth.ts
  認証状態管理

app/api/
  ラッパーAPIの実装

ユーザーはOpenRouterアカウントでOAuth接続し、自分のクレジットを使って画像・動画・テキストモデルを利用します。

4. OpenRouter公式Examples

GitHub: OpenRouterTeam/openrouter-examples

OAuth後に取得したユーザーキーを使って、実際にモデルを呼び出す部分はこちらが参考になります。

収録例：

cURL
TypeScript fetch
Vercel AI SDK
Effect AI
Prompt Caching
ストリーミング
モデル固有機能

リポジトリは実行可能なサンプル集として用意されており、TypeScript、cURL、Vercel AI SDKなどに分かれています。

最小のfetch呼び出しは、OAuthで得たキーをBearerトークンに設定します。


const response = await fetch(
  "https://openrouter.ai/api/v1/chat/completions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${userOpenRouterKey}`,
      "Content-Type": "application/json",
      "HTTP-Referer": "https://your-app.example",
      "X-OpenRouter-Title": "Your App"
    },
    body: JSON.stringify({
      model: "openai/gpt-4.1-mini",
      messages: [
        {
          role: "user",
          content: "こんにちは"
        }
      ]
    })
  }
);

if (!response.ok) {
  throw new Error(`OpenRouter error: ${response.status}`);
}

const result = await response.json();
console.log(result.choices[0].message.content);

5. 公式TypeScript SDK

GitHub: OpenRouterTeam/typescript-sdk

TypeScript SDK公式ドキュメント

OAuthで取得したキーをそのままSDKへ設定できます。


import { OpenRouter } from "@openrouter/sdk";

const client = new OpenRouter({
  apiKey: userOpenRouterKey
});

const result = await client.chat.send({
  model: "openai/gpt-4.1-mini",
  messages: [
    {
      role: "user",
      content: "この文章を要約してください"
    }
  ],
  stream: false
});

console.log(result.choices[0].message);

公式OAuthガイドでも、このSDKを使ったキー利用例が掲載されています。

6. Vercel AI SDK公式プロバイダー

GitHub: OpenRouterTeam/ai-sdk-provider

Next.jsやVercel AI SDKを使う場合の公式プロバイダーです。


npm install ai @openrouter/ai-sdk-provider


import { createOpenRouter } from "@openrouter/ai-sdk-provider";
import { generateText } from "ai";

const openrouter = createOpenRouter({
  apiKey: userOpenRouterKey
});

const { text } = await generateText({
  model: openrouter("openai/gpt-4.1-mini"),
  prompt: "BYOKについて説明してください"
});

console.log(text);

公式プロバイダーは、OpenRouterで提供される多数のモデルをVercel AI SDK形式で利用できます。2026年7月時点ではAI SDK v7対応版が公開されています。

GitHub上のサードパーティ実例

7. Streamlit＋OAuth PKCE

GitHub: 0xblocktrain/openrouter-streamlit

Python／Streamlitで、


Connect OpenRouter
↓
OAuth PKCE
↓
ユーザー専用キー取得
↓
チャット実行

を実装した小規模サンプルです。

ユーザー側でAPIキーをコピーする必要がなく、ボタンからOpenRouterへ接続してキーを取得する構成です。

起動方法も単純です。


python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
streamlit run Chatbot.py

8. Streamlitの複数サンプル

GitHub: alexanderatallah/openrouter-streamlit

含まれる例：

チャットボット
ファイルQ&A
LangChain
PromptTemplate
検索連携

古めの部分もありますが、PythonでOpenRouterをラップする構造を確認するには有用です。

9. OAuth対応のStreamlit派生例

GitHub: alonsosilvaallende/chatplotlib-openrouter

Streamlit上でOpenRouter OAuth PKCEを使うスターターです。チャットや可視化アプリへユーザー自身のOpenRouter利用枠を持ち込ませる例として参考になります。

10. IntelliJプラグインでのOAuth例

GitHub: DimazzzZ/openrouter-intellij-plugin

デスクトップIDEプラグインで、

「Connect to OpenRouter」
OAuth／PKCE
手動キー入力
モデル選択

を実装しています。

Webサービスだけでなく、ローカルアプリやIDE拡張でOAuthを使いたい場合の実装例になります。

11. MCP＋OpenRouter OAuth

GitHub: janwilmake/chat-completions-mcp

OpenRouter OAuthで認証し、/chat/completionsをMCPツールとして公開する例です。

今回の「開発したラッパーAPIを、ユーザー自身の課金枠で使わせる」という考え方に近く、


MCPクライアント
↓ OAuth
OpenRouter
↓
ユーザー本人のクレジット

という構造を確認できます。

登録: 投稿 (Atom)

2026年8月2日日曜日

2026年7月24日金曜日

2026年7月23日木曜日

2026年7月22日水曜日

関連キーワード

2026年7月12日日曜日

WebAssembly共通仕様

WASI・Component Model

C / C++

Emscripten

Clang / LLVM

Rust

Zig

AssemblyScript

Go

TinyGo

C# / .NET / Blazor

Kotlin

Swift

Python

Pyodide

CPython本体

Java

TeaVM

CheerpJ

実行ランタイム

Wasmtime

WasmEdge

Wasmer

WAMR

wasm3

Wazero

M5Stack向けサンプル

M5Stack Core2 + wasm3 + AssemblyScript

M5Stamp C3 + WAMR

旧版 M5Stack wasm3

ランタイム

WAMR (WebAssembly Micro Runtime)

wasm3

M5Stackライブラリ

M5Unified

M5GFX

旧M5Stackライブラリ

開発環境

ESP-IDF

Arduino-ESP32

PlatformIO

Wasmを生成する言語

AssemblyScript

TinyGo

Rust

解説記事

おすすめ構成（2026年時点）

料金体系

実装手段

① OAuth認証（推奨される公開アプリ向け）

② APIキー入力

③ BYOK

④ Management API（SaaS向け）

OpenRouterが提供する技術

まず見るべき公式サンプル

1. OAuth PKCE公式ガイド

2. Sign In with OpenRouter公式リポジトリ

3. OpenRouter公式の完成アプリ例

4. OpenRouter公式Examples

5. 公式TypeScript SDK

6. Vercel AI SDK公式プロバイダー

GitHub上のサードパーティ実例

7. Streamlit＋OAuth PKCE

8. Streamlitの複数サンプル

9. OAuth対応のStreamlit派生例

10. IntelliJプラグインでのOAuth例

11. MCP＋OpenRouter OAuth

ラベル

ブログ アーカイブ

ブログアーカイブ