2025年9月7日日曜日

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。OpenAPIは業界標準で、YAMLやJSONで記述し、Swagger UIで視覚化も可能。Postmanはコレクション機能でAPIをテスト・整理しやすく、ドキュメント生成も対応。Markdownはシンプルな構造で記述しやすく、専用ツールでモックやサーバーを生成可能。いずれもAPI仕様の明確化やチーム共有、保守性向上に役立ちます。用途に応じて選択するのが効果的です。

🔷 OpenAPI（Swagger）仕様の例

GitHub APIのOpenAPI仕様（Swagger UI）
https://docs.github.com/en/rest
→ GitHubのREST APIがOpenAPI仕様でドキュメント化され、操作しながら確認可能。
Petstoreのデモ（Swagger公式サンプル）
https://petstore.swagger.io/
→ OpenAPI 3.0ベースの代表的なデモ。仕様定義からUI表示まで確認可能。
OpenAPI仕様のYAML例
https://swagger.io/specification/
→ OpenAPI 3.0の構造や記法を学ぶのに最適な公式ドキュメント。

🟠 Postman コレクションの例

Twitter API v2 のPostmanコレクション
https://developer.twitter.com/en/docs/twitter-api/tools-and-libraries/postman
→ 認証付きでTwitter APIをPostmanから試せるように構成済み。
Postman Explore – 公開コレクション一覧
https://www.postman.com/explore
→ 公開されているAPIコレクションを検索・インポートして試せるPostmanの共有ハブ。
Postman Documentation生成例（Stripe）
https://documenter.getpostman.com/view/8920999/SzYXYfmE
→ Postmanのドキュメント機能を使った美しいAPI仕様例。

🔶 Markdown形式のAPIドキュメント例

GitHub Actions API ドキュメント（Markdownベース）
https://docs.github.com/en/actions
→ GitHubはMarkdownで整備された静的ドキュメントとしてAPIを管理。
FastAPIのドキュメント自動生成例（Markdown起点）
https://fastapi.tiangolo.com/
→ PythonのFastAPIではMarkdownコメントからドキュメントを生成可能。
ReDoc によるMarkdownドキュメントのレンダリング例
https://redocly.github.io/redoc/
→ MarkdownやOpenAPIを視覚的に変換するReDocのデモ。

p5 × GLSL-mini DSL (Logical Grid × Dot Size)

GLSL-mini DSL

目的: 論理解像度（Grid）に対してN×N ドットで物理描画。

座標: uv = [-1..1]（上が+／論理解像度基準）
時間: t（秒）
一様: U（U.grid, U.res, U.mouse, U.frame）
戻り: [r,g,b]（0..1）

Program Scale (表示倍率) FPS (描画間隔) Logical Grid (W×H)

Dot Size (1セルの物理ピクセル辺長)

uvを正方形基準に（非正方形Gridでも円が歪まない）

DSLコア V.*: add/sub/mul/div/mod/abs/floor/fract/sin/cos/tan/exp/log/sqrt/step/smoothstep/mix/clamp/min/max/dot/length/normalize/vec2/vec3/vec4/as3/sign/rot2

自作プログラムの最小例

// 同心円の波（論理解像度に依存）
const myProg = (uv, t, U) => {
  const s = V.add(0.5, V.mul(0.5, V.sin(V.sub(V.mul(12, V.length(uv)), V.mul(6, t)))));
  return V.as3(s);
};
// 登録:
examples.Rings2 = myProg; uiRefresh();

マウス座標 U.mouse は uv と同じく [-1..1]（論理解像度基準）。

CC0/MIT。自由に改変・再配布可。

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説（約600字

最小PBR（GGX・直射）— 冒頭解説（約600字）

最小PBR（GGX・直射）— 冒頭解説

このシェーダは、球1個をレイトレし、GGXベースの最小PBRで直射1灯の見え方を計算します。まずカメラからのレイと球の交差を求め、ヒット点の法線 N、視線 V、光線 L を作ります。鏡面はマイクロファセットBRDFで、法線分布は GGX、幾何項 G は Smith の Schlick‑GGX 近似（$k=((r+1)^2)/8$）、フレネル F は Schlick 近似を用います。

$$ F(\theta)=F_0 + (1-F_0)(1-\cos\theta)^5 $$

粗さ $r$ から $\alpha=r^2$ とし、NDF は次式です。

$$ D=\frac{\alpha^2}{\pi\,\big((\mathbf{N}\!\cdot\!\mathbf{H})^2(\alpha^2-1)+1\big)^2} $$

エネルギー保存のため拡散は

$$ k_d=(1-F)(1-\text{metallic}),\qquad f_{\mathrm{diff}}=k_d\,\frac{\text{albedo}}{\pi} $$

とし、金属（metallic=1）では拡散が消えます。最終輝度は

$$ L_o=(f_{\mathrm{diff}}+f_{\mathrm{spec}})\,(\mathbf{N}\!\cdot\!\mathbf{L})\,L_i $$

を一灯ぶん評価し、わずかな環境色を加えてガンマ補正（$1/2.2$）で表示します。パラメータは Blender の Principled と整合し、Base Color→albedo、Metallic、Roughness が同義です。短いコードと基本式だけで「金属らしさ」や「粗さによるハイライトの広がり」を再現でき、さらに IBL、影、ACES トーンマップを加えると実写感が一段と高まります。

https://www.shadertoy.com/view/3cScDD

Web3広告ネットワーク

すでに動いている/資金調達している主な類型と企業

Web3広告ネットワーク（ウォレット/ dApp面の配信）
HypeLab：ウォレットやdApp・NFTマーケットプレイス内に配信、オンチェーン/オフチェーン属性でターゲティング。23年に**$4M**調達。 hypelab.com+1The Block
オンチェーン計測・アトリビューション
Spindl：Web2⇄Web3横断の計測（AppsFlyer連携）/ 22年に**$7M**調達。 Axiosblog.spindl.xyz
Web3オーディエンス構築（アドレス⇄Web2紐付け/拡張）
Addressable：23年に**$7.5M**→24年に累計$13.5M。ウォレットに基づくマーケ堆積を提供。 addressable.io+2addressable.io+2
分散型アドエクスチェンジ/プロトコル
Ambire AdEx：17年からの広告プロトコル（支払いチャネル/スマコン決済）。初期に約**$10–12M**規模の資金調達（ICO）。 GitHubadex.network+1
ユーザー報酬型ブラウザ広告
Brave / BAT：ユーザーが同意して広告を受け取り、BATで報酬。Roadmap 3.0ではオンチェーン連携やクエスト強化。 Brave+1
“クエスト/タスク”型の獲得（オンチェーントライアル=成果）
Galxe、Layer3、Zealy：大規模ユーザー基盤・23–24年に資金調達（Layer3は**$15M Series A**）。広告の代替として成果タスクを組むユースケースが一般化。 galxe.comLayer3PYMNTS.com
アドフラウド対策（オンチェーン検証）
Verasity（Proof-of-Viewでビュー検証、VeraViews提供）。 OKXverasity.io

Web2アドテクと比べた利点（＋理由）

成果の“可監査性”が高い：ミント/スワップ/入金などオンチェーンの最終イベントをコンバージョンにでき、スマコンに記録→レポートの食い違いを縮小。ZKや分散台帳での監査性も研究・実装が進展。 arXiv
同意ベースのID（ウォレット）：**SIWE（ERC-4361）**で署名ログイン→クッキー不要でもセッションと同意管理が可能。スマコンウォレットの署名検証（EIP-1271）にも対応。 Login.xyz+1ethereum.org
自動レベニューシェア/即時決済：支払いをスマートコントラクトで自動化（エスクロー/ストリーミング/上限管理など）。AdEx系は支払いチャネルでマイクロペイメントを大量処理する設計。 GitHub
“ウォレット内”のリーチ：従来のウェブ面では届きにくい**実利用者（保有資産・トランザクション有り）**に直接配信可能。 hypelab.com
ユーザーと利害が一致する設計：Braveのようにユーザーへ還元するモデルが標準機能として存在。 Brave
フラウド耐性の強化余地：ビュー/クリックの“申告値”より、検証可能なイベント（オンチェーン）を課金根拠にできる。PoVのようなビュー真正性検証も登場。 OKX

ただし（現実的な留意点）

到達規模/在庫の成熟度：Web2の巨大在庫・ブランドセーフティ標準（IAS/DoubleVerify等）に比べ、Web3は在庫/測定の標準化が発展途上。Quest型で補完する動きが主流。 Layer3
ID断片化とSybil対策：チェーン/ウォレット跨ぎの重複、スマコンウォレット署名（EIP-1271）対応の実装差など、運用ノウハウが必要。 ethereum.org
Web2側の環境は“まだ動的”：Chromeの3rdパーティCookieは段階的制限の計画が度々変更/遅延。Privacy Sandbox（Attribution Reporting API等）は動き続けており、Web2計測も並行で必要。 Privacy Sandbox+1Wall Street Journal
日本の広告・景品規制/暗号資産規制：表示義務・誇大表現の禁止（景表法/JVCEA指針）に注意。対価や特典（NFT/トークン付与）は景品類上限やリスク表示等の要件を満たす設計が必要。 CAA Japan一般社団法人日本暗号資産取引業協会（JVCEA）t2fifa.or.jp

どう活かすか（実務Tips）

配信：まずはHypeLab等のウォレット面在庫でCPA/CPE試験運用。 hypelab.com
計測：SIWE署名＋campaignIdでクリック識別→オンチェーン成果と1:1照合。Web2計測（AppsFlyer等）とSpindl連携で“Web2→オンチェーン”のラストタッチを補完。 blog.spindl.xyz
不正対策：成果はオンチェーンイベント＋PoV/独自検証の二重化、SC側でcooldown/上限/nonce。 OKX

もともとインターネット自体ディスクロージャーだったはずですけど、マネタイズその他、そうはならなかったですね

もともとネットは「仕様・由来を公開して接続する」文化（RFC/W3C/ブログ）でしたが、収益化とモバイル化で“逆ディスクロージャー”が進みました。要点だけ整理します。

3段階の変遷

開示指向（〜2000）
　公開規格・実名的コミュニティ・リンクで評価＝可視。
不可視化の進行（2000–2010s）
　アドテク/入札/指紋採取、推薦アルゴリズム、アプリ化で“箱化”。
規制主導の再ディスクロージャー（2020s–）
　広告ライブラリ、ステマ規制、C2PA/AIラベリング等で部分的に回帰。

逆転を招いた力学（5つ）

競争優位：データと最適化手法は隠すほど儲かる
プライバシー規制の副作用：同意UIは増えたが実態は見えにくい
プレミアの壁：有料層で情報非対称が拡大
濫用対策：スパム/荒らし対策名目で基準がブラックボックス化
インフラ回収：ログや計測が企業内に囲い込まれた

いま実務でできる「設計の原則」

目的別開示：①推薦理由 ②広告/アフィ関係 ③生成物ラベル（AI/C2PA）
二重ログ：内部監査ログ＋ユーザー向け“ミニ開示ログ”（誰に何が届いたかの要約）
透明性API：出稿・配信・推薦の要約エンドポイントを外部公開
プレミア再設計：有料でも開示文言は無料で誰でも閲覧可
合意UI最適化：1画面1目的・履歴参照・いつでも撤回

進め方（軽量KPI）

可読開示率（開示文を実際に読まれた割合）
関係性明示率（提携/ギフティング表示の網羅度）
推薦理由開示率（リコメンドの“なぜ”を提示した配信の割合）

ブロックチェーンがプライバシーについて二極化をもたらすと仮定できますか？

ざっくり言うと「開示ど真ん中のKYCゾーン」と「選択的秘匿ゾーン」の二極化です。

規制ドリブンに“丸見え化”
FATFのトラベルルールやEUの新AML規則で、送受信者情報の伝達・匿名口座の禁止などが強化。結果、取引所や“規制対応型L1/L2”は高開示へ収束します。FATFコンシリウムノートン・ローズ・フルブライト
産業側の「公開」圧力
MiCAは発行体にホワイトペーパーの詳細開示を義務づけ、広告表現の制約も。コンプラ重視のRWAやステーブル群は“見せる”設計に寄ります。EUR-Lex+1
逆方向の“秘匿”技術も進化
Zcashのzk-SNARK、Aztecなどのプライバシー志向ZKロールアップ、FHE系L2（Fhenix等）が計算や状態そのものを暗号化して選択的開示を可能に。Zcash DocumentationZ.CashAztec DocumentationCoinDeskChainwire
「選択的ディスクロージャー（zkKYC）」の台頭
Polygon ID等のVC/zk証明で、必要最小限だけ証明（例：年齢/KYC済み）する実装が増加。全面開示と完全秘匿の中間が厚くなります。PolygonCryptoSlate
監視の“性能向上”が分極を補強
研究・実務のアドレス／トランザクション・クラスタリングで疑似匿名は可視化されやすい。可視ゾーンはより透明に、秘匿ゾーンはより強い暗号へ。コンピュータサイエンスUSENIX
エンフォースメントの揺れ
Tornado Cash制裁（2022）→訴訟・取扱い指針・最近の動きまで、プライバシー手段と法執行の綱引きが続いています。U.S. Department of the Treasury+1Axios

帰結（実務の前提）

CEX/規制対応L2/許可型チェーン＝高開示・追跡前提
ZK/FHE系L2・プライバシー通貨＝選択的秘匿前提
中間層＝zkKYC＋ログ最小化の設計（監査には耐え、個人情報は出さない）

いまの設計指針（簡潔）

“開示と秘匿の分離”を要件化：公開メタデータと秘匿データの境界を明文化
zkKYC/VCで二値KYCを脱し、「条件を満たす」のみ証明
監査用ログは保持、公開ログは最小限・選択的
地域展開はMiCA/AML/トラベルルール差分表で運用

秘匿方向のweb3のweb2と比較した利点を教えてください

最小開示（Selective Disclosure）
zk/VCで「18歳以上」等だけ証明。Web2は本人情報そのものを提出・保管しがち。
計算の秘匿
MPC/FHE/TEE等で“中身を見ずに計算”。Web2は担当者や運営が内容を閲覧し得る。
検証可能で非公開
第三者は“正しさの証明”だけ検証でき、基データは非公開のまま。Web2は監査で原本提出が前提。
プラットフォーム横断の再利用
一度の証明（VC/zk）を別サービスでも使い回せる。Web2はサービスごとに再登録・再提出。
公開台帳との“選択的接続”
ステルスアドレス/シールドプール等で取引のリンク性を制御。Web2は中央DBで統合・突合されやすい。
コンプライアンスの“コード化”
「証明が無ければスマコン実行不可」など、運用ではなく実装で強制。Web2はポリシー・監査依存。
監査の低侵襲化
View key/監査用鍵で“必要範囲のみ”開示。Web2は全件エクスポートや現地監査が必要になりがち。
漏洩リスクの縮小
そもそも個人データを“保持しない”設計が可能。Web2は保有前提で漏洩面積が大きい。
耐検閲・停止点の分散
分散台帳＋リレー/ロールアップで単一停止点を回避。Web2は事業者・国境で遮断されやすい。
メタデータ分離
コミットメント/ノート設計で金額・相手・頻度などの露出を抑制。Web2は決済・広告事業者に集約。

代表ユースケース

年齢/居住地などの属性証明（本人情報は非開示）
プライベート投票・評議（正当性は公開、投票内容は秘匿）
企業間の機微データ連携（合算/検証のみ共有、原データは秘匿）
地域/資格限定のエアドロップ（条件充足のみ証明）

注意：L1の透明性、オンランプ/KYCでの再識別、解析による追跡リスクは残ります。**“何を公開し、何を証明だけにとどめるか”**の設計が肝要です。

Books pro

2025年9月7日日曜日

Web APIの仕様書には、OpenAPI（旧Swagger）、Postman、Markdownなど複数の形式があります。

🔷 OpenAPI（Swagger）仕様の例

🟠 Postman コレクションの例

🔶 Markdown形式のAPIドキュメント例

p5 × GLSL-mini DSL (Logical Grid × Dot Size)

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説（約600字

最小PBR（GGX・直射）— 冒頭解説

Web3広告ネットワーク

すでに動いている/資金調達している主な類型と企業

Web2アドテクと比べた利点（＋理由）

ただし（現実的な留意点）

どう活かすか（実務Tips）

もともとインターネット自体ディスクロージャーだったはずですけど、マネタイズその他、そうはならなかったですね

3段階の変遷

逆転を招いた力学（5つ）

いま実務でできる「設計の原則」

進め方（軽量KPI）

ブロックチェーンがプライバシーについて二極化をもたらすと仮定できますか？

帰結（実務の前提）

いまの設計指針（簡潔）

秘匿方向のweb3のweb2と比較した利点を教えてください

代表ユースケース

ラベル

ブログアーカイブ

2025年9月7日日曜日

🔷 OpenAPI（Swagger）仕様の例

🟠 Postman コレクションの例

🔶 Markdown形式のAPIドキュメント例

2025年9月6日土曜日

最小PBR（GGX・直射）— 冒頭解説

すでに動いている/資金調達している主な類型と企業

Web2アドテクと比べた利点（＋理由）

ただし（現実的な留意点）

どう活かすか（実務Tips）

3段階の変遷

逆転を招いた力学（5つ）

いま実務でできる「設計の原則」

進め方（軽量KPI）

帰結（実務の前提）

いまの設計指針（簡潔）

代表ユースケース

ラベル

ブログ アーカイブ

ブログアーカイブ