2026年7月23日木曜日

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に至る技術基盤を築いたのである。

関連キーワード

  • コンピュータグラフィックス（CG）
  • 映画VFX
  • 手続き的生成（Procedural Generation）
  • Perlin Noise
  • 勾配ノイズ
  • Boids
  • 創発（Emergence）
  • 群知能（Swarm Intelligence）
  • Physically Based Rendering（PBR）
  • Cook–Torranceモデル
  • フォン反射モデル
  • レンダリング方程式
  • レイマーチング
  • Sphere Tracing
  • Signed Distance Function（SDF）
  • ボリュームレンダリング
  • モンテカルロ法
  • パストレーシング
  • 光輸送（Light Transport）
  • SIGGRAPH
  • Pixar
  • Industrial Light & Magic（ILM）
  • Ken Perlin
  • Craig Reynolds
  • James Kajiya
  • John C. Hart


投稿者

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 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

小型インタプリタです。

Wazero

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


言語名称正体単体／複合
Rustrustcコンパイラ単体
Rustwasm-bindgenJS相互運用ライブラリ＋CLI複合寄り
Rustwasm-packビルド・パッケージ化CLI単体
Rustweb-sysWeb APIバインディング単体
Rustjs-sysJS標準APIバインディング単体
C/C++Emscriptenコンパイラツールチェーン複合
CemccC向けコンパイラドライバー構成要素
C++em++C++向けコンパイラドライバー構成要素
AssemblyScriptAssemblyScript言語・ランタイム・ツール群複合
AssemblyScriptascコンパイラCLI単体
Gojs/wasmブラウザ向けターゲット名称
Gowasip1/wasmWASI向けターゲット名称
Gosyscall/jsJS相互運用パッケージ単体
TinyGoTinyGoGo用別コンパイラツールチェーン複合
TinyGowasmブラウザ向けターゲット名称
TinyGowasip1 / wasip2WASI向けターゲット名称
ZigZig言語・コンパイラ・ビルドツール複合
Zigwasm32-freestandingターゲット指定名称
KotlinKotlin/WasmKotlinのWasmバックエンド構成要素
KotlinwasmJsブラウザ向けGradleターゲット名称
KotlinwasmWasiWASI向けGradleターゲット名称
KotlinCompose MultiplatformUIフレームワーク複合
.NETBlazor WebAssemblyWebアプリフレームワーク複合
.NET.NET WebAssembly runtime.NETランタイム構成要素
.NETInteractive WebAssemblyレンダーモード名称
.NETWebAssembly AOTコンパイル方式名称
PythonPyodidePython/Wasmディストリビューション複合
PythonCPythonPython処理系複合
Rubyruby.wasmCRubyのWasm移植群複合
RubyCRubyRuby処理系複合
SwiftSwift SDKs for WebAssembly公式Wasm SDK複合
SwiftSwift for WebAssembly分野・対応全体の名称名称
SwiftSwiftWasmコミュニティプロジェクト複合
SwiftJavaScriptKitJS相互運用ライブラリ単体
投稿者

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

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

M5Stack向けサンプル

M5Stack Core2 + wasm3 + AssemblyScript

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

M5Stamp C3 + WAMR

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

旧版 M5Stack wasm3

初期の実験版です。

ランタイム

WAMR (WebAssembly Micro Runtime)

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

wasm3

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

M5Stackライブラリ

M5Unified

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

M5GFX

高速LCDライブラリ。

旧M5Stackライブラリ

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

開発環境

ESP-IDF

ESP32公式SDK

Arduino-ESP32

Arduino環境

PlatformIO

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

Wasmを生成する言語

AssemblyScript

TinyGo

Rust

解説記事

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

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

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


投稿者

OpenRouterに限定して、開発者視点で整理したものです。

項目内容技術資料
統一APIOpenAI互換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 APISaaSがエンドユーザーごとのAPIキーを自動生成・削除・上限変更できる管理API。Management API Keys FAQ

料金体系

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

実装手段

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

ユーザー
    ↓
OpenRouter OAuth
    ↓
認可コード
    ↓
APIキーへ交換
    ↓
あなたのアプリ

利用者はAPIキーをコピーする必要がなく、あなたは取得したユーザー専用APIキーでOpenRouter APIを呼び出します。

② APIキー入力

ユーザー
    ↓
OpenRouter APIキー入力
    ↓
あなたのアプリ

もっとも単純な方式です。キーには利用上限を設定できます。

③ BYOK

OpenAI Key
Anthropic Key
Gemini Key
        ↓
OpenRouter
        ↓
あなたのアプリ

利用者はOpenRouterへ各社APIキーを登録し、OpenRouter経由で統一APIを利用します。キーは暗号化保存されます。

④ Management API（SaaS向け）

あなたのSaaS
        ↓
Management API
        ↓
ユーザーごとのAPIキー生成

エンドユーザーごとにAPIキーを自動発行し、利用上限やリセット周期（日次・週次・月次）をプログラムから管理できます。

OpenRouterが提供する技術

  • OpenAI互換REST API
  • OAuth 2.0 + PKCE
  • BYOK（OpenAI、Anthropic、Google、Azure、AWS Bedrockなど）
  • APIキー管理
  • Management API
  • モデルルーティング
  • フォールバック
  • クレジット管理
  • アプリ別利用上限
  • OpenAI SDK互換
  • Python・TypeScript SDK

OpenRouterは現在、「エンドユーザーが自分のAI利用権を第三者アプリへ委任する」ための仕組みを、OAuth・BYOK・Management APIまで含めて最も体系的に提供しているプラットフォームと言えます。


OpenRouter OAuthで、各ユーザーが自分の残高・課金枠を使う実装について、公式サンプルとGitHub上の実例を分けてまとめます。

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

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対策が必要だと明記しています。

デモ：

Sign In with OpenRouter Live Demo

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)