Japan criticism: 6月 2026

2026年6月28日日曜日

量子コンピュータの仕様書群

量子コンピュータの仕様書群を読み解くとき、重要なのは計算機性能や実装技術ではなく、「計算とは何か」という概念そのものの変化を味わうことである。従来の計算機仕様が決定論的な状態遷移を前提としていたのに対し、量子計算の仕様は重ね合わせ状態、干渉、観測、デコヒーレンスといった量子力学的概念を計算資源として扱う。そのため仕様書は命令セットやAPIの説明書であると同時に、物理法則の記述書としての性格を持つ。

代表例であるOpenQASM、Q#、QIRなどの仕様では、HゲートやCNOTゲート、測定命令といった操作が中心に据えられている。そこではプログラムは値を加工する手続きではなく、量子状態空間を変形する過程として記述される。特に測定命令は、観測によって重ね合わせ状態を単一の結果へ収束させるため、プログラムの意味そのものが観測行為と不可分であることを示している。

また、量子仕様の多くは回路図、線形代数、プログラミング言語仕様が一体化している点でも興味深い。古典計算機のアセンブリ言語が電子回路から抽象化された存在であったのに対し、量子言語は再び物理現象へ接近し、数式・回路・コードが同じ対象を異なる視点から表現する構造を持つ。この特徴は、計算機科学と物理学が再統合されつつある現在地を示している。量子コンピュータの仕様書とは、単なる技術文書ではなく、「観測によって世界が確定する」という量子論的世界観を計算機設計へ持ち込んだ思想書として読むことができる。

関連キーワード：
量子コンピュータ、OpenQASM、Q#、QIR、量子ゲート、量子回路、重ね合わせ、量子もつれ、量子測定、デコヒーレンス、ユニタリ変換、量子アルゴリズム、量子誤り訂正、表面符号、量子情報理論

見込み無い種子のオントロジー

1804年、人類は初めて世界人口10億人に到達した。そこからわずか123年後の1927年には20億人、1960年には30億人、1987年には50億人へ達する。現在では80億人を超えている。この急増を知る現代人には当然に見えるが、18世紀以前の人々にとって人口とは、国家を左右する最も重要な相場の一つだった。

17世紀から18世紀にかけての絶対主義国家は、人間を個人としてではなく、人口、穀物、税収、兵員という数値の集まりとして見ていた。王たちが日々気にしていたのは「穀物相場」である。凶作で穀物価格が上がれば、飢饉、暴動、徴税不能が連鎖する。国家の安定は穀物価格に直結していた。フランス革命前夜の穀物価格高騰も、その危険性を示している。

この時代に登場したケネーは、金銀を集める重商主義を批判し、「土地相場」こそが社会の本体だと考えた。『経済表』は貨幣の流れを描いた図として知られるが、その本質は土地、収穫、余剰、税収の循環を可視化した制約地図だった。社会を支えているのは市場の熱狂ではなく、土地が毎年どれだけの余剰を生み出せるかという現実である。

18世紀末になると、マルサスが「人口相場」を発見する。世界人口はまだ10億人に達していなかったが、彼は人口増加の勢いそのものを問題視した。人口は増え続けるが、食糧生産には限界がある。人口増加が続けば、いずれ飢餓が訪れるという見方だった。

しかし19世紀の産業革命は、この相場を一時的に崩壊させた。蒸気機関、鉄道、化学肥料、機械化農業が土地制約を押し広げる。1804年から1927年までの間に人口は倍増したが、大規模な世界的飢餓は予測ほどには起きなかった。人類は土地相場と人口相場を乗り越えたように見えた。

ところが第二次世界大戦後、再び巨大な相場が現れる。医療と公衆衛生によって死亡率が急落し、1950年の25億人は1960年に30億人、1974年に40億人、1987年には50億人へ増加する。人口増加率は1963年頃に年2.3％前後という歴史的ピークに達した。ここで世界を支配したのが「人口爆発相場」である。

ポール・エーリッヒの『人口爆弾』は、人口増加による大規模飢餓を予測し、世界的な影響を与えた。人々は人口統計を見ながら、文明崩壊の未来を想像したのである。

だが歴史のクライマックスは別の場所にあった。飢餓研究の中から、人類は新しい相場を発見する。1943年のベンガル飢饉では、推計80万人から380万人が死亡した。しかし後の研究は、飢餓が単なる食糧総量不足では説明できないことを示した。食糧が存在していても、戦争、価格高騰、物流断絶、所得喪失によって人々は食べられなくなる。

ここで初めて「飢餓の発見」が起こる。人類は長い間、食糧相場だけを見ていた。しかし本当に社会を動かしていたのは、アクセス相場、物流相場、価格相場、制度相場、戦争相場だったのである。

📏ラプラス変換と逆ラプラス変換の仕様

ラプラス変換は微分方程式を解くためのツールであるため、科学や工学の分野で多くの応用がある。

関数 LaplaceTransform(f, s)
    入力: f - 時間領域の関数
          s - ラプラス変換で使用する複素数変数
    出力: F(s) - ラプラス変換の結果

    定義: F(s) = ∫(0, ∞) e^(-st) f(t) dt

    初期化: 結果を格納する変数 result を 0 に設定
    定義: 積分のステップ幅 delta_t（小さい値、例えば 0.01 など）
    定義: 積分の上限 approx_upper_limit（理論上は ∞ だが、実際には大きな値、例えば 100 または 1000 など）

    // 数値積分 (台形則やシンプソン則などを使用することも可能)
    for t から 0 まで approx_upper_limit まで delta_t ずつ増加させる:
        // 現在の t での関数の値を計算
        current_value = e^(-s*t) * f(t)
        
        // 積分の合計に加算
        result = result + current_value * delta_t

    return result

線形微分方程式を代数方程式に、畳み込みを乗算に変換する

ラプラス変換は，数学者であり天文学者であったラプラス侯爵 Pierre-Simon, marquis de Laplace にちなんで命名され，彼は確率論に関する研究において同様の変換を用いた.
ラプラスは Essai philosophique sur les probabilités (1814) で生成関数の使用について広範囲に執筆し，ラプラス変換の積分形式は結果として自然に発展している．
ラプラスの生成関数の使用は、現在z変換として知られているものに似ており、彼はNiels Henrik Abelによって議論された連続変数のケースにはほとんど注意を払っていませんでした。この理論は、Mathias Lerch, Oliver Heaviside, and Thomas Bromwichによって19世紀から20世紀初頭にさらに開発されました。
現在、この変換が（主に工学分野で）広く使われているのは、第二次世界大戦中とその直後のことで、それ以前のHeavisideの操作的微積分を置き換えるものであった。ラプラス変換の利点はGustav Doetschによって強調されており、ラプラス変換という名前はこの人物に由来しているようである。

ラプラス変換は工学や物理学でよく使われます。

ラプラス変換は工学や物理学でよく使われます。線形時不変システムの出力は、その単位インパルス応答と入力信号の畳み込みによって計算できます。この計算をラプラス空間で行うと、畳み込みは乗算になり、後者は代数的な形式であるため解きやすくなる。

ラプラス変換は、多くの関数に対して反転可能である。

システムの入力または出力の簡単な数学的または関数的記述がある場合、ラプラス変換は、しばしばシステムの動作を分析するプロセスや、一連の仕様に基づく新しいシステムを合成するプロセスを簡略化する代替の関数的記述を提供する。
ラプラス変換は微分方程式の解法にも使用でき、機械工学や電気工学で広く使用されている。ラプラス変換は、線形微分方程式を代数方程式に変換し、代数学の正式な規則によって解くことができる。元の微分方程式は、逆ラプラス変換を適用することによって解くことができる。イギリスの電気技術者Oliver Heavisideは、ラプラス変換を用いないものの、同様の方式を最初に提案し、その結果生まれた演算微積分をHeaviside calculus（ヘービサイド微積分）と呼んでいる。

ラプラス変換とその逆変換の広範で一般的な適用性は、天文学のアプリケーションによって説明される。このアプリケーションでは、時間領域とスペクトル（周波数領域）を関連づけるのではなく、点以上として分解するには遠すぎる高周波熱放射の天体源の物質の空間分布に関する情報を、そのフラックス密度スペクトルから得ることができる。
球形で温度が一定であるなどの天体の性質を仮定して、天体のスペクトルに対して逆ラプラス変換を行うことに基づく計算を行うと、天体の中の物質の分布（中心からの距離の関数としての密度）についてスペクトルと一致する唯一の可能なモデルが得られる[36]。天体の構造に関する独立した情報が得られる場合、逆ラプラス変換法は良く一致することが分かっている。

https://en.wikipedia.org/wiki/Laplace_transform#/media/File:Laplace_animation_of_Cubic_Polynomial.gif　しゅるしゅるしゅるしゅる

ラプラス変換は、複素関数論と微分方程式の分野で広く用いられる数学的な変換です。この変換は、時間領域の関数を複素周波数領域の関数に変換します。このプロセスは、微分方程式の解析や信号処理など、さまざまな応用において重要です。

「代数的」という言葉がラプラス変換に関連して使われる場合、それは次の点を指します：

代数的操作の単純化:
ラプラス変換は、微分方程式の解法を単純化するために使われます。時間領域での微分演算が、周波数領域でのより簡単な代数的演算（加算、乗算など）に変換されます。
代数的手法:
ラプラス変換は、複雑な微分方程式を解くために代数的手法を利用することを可能にします。これにより、解析がより直接的かつ計算が容易になります。

この文脈での「代数的」とは、ラプラス変換が複雑な微分演算をより取り扱いやすい代数的形式に変換する能力を指しています。これは、代数的データ構造が型の合成や組み合わせに関する数学的な原則に基づいていることとは異なる用途です。

これは数値解析では無いですか？

数値解析とは異なります。数値解析は、コンピュータを使用して数値的に近似解を求める手法ですが、代数的解法は方程式の解を具体的な数式で厳密に求める方法です。

代数的解法では、方程式を根号や多項式などの明確な形で解き、解を正確に表現します。これに対し、数値解析では、反復計算や近似式を使って解の近似値を計算します。例えば、ニュートン法や二分法などが数値解析の典型的な手法です。

簡単に言うと、代数的解法は「解の式」を直接提供し、数値解析は「解の近似値」を計算によって求めるのが一般的です。したがって、方程式が代数的に解けるというのは、根号や有限の演算を用いて解を具体的に導出できるということを意味します。

ラプラス変換は五次方程式でも代数的に解けますか？

ラプラス変換は、五次方程式のような多項式方程式を解くために直接使用される方法ではありません。ラプラス変換は主に微分方程式や積分方程式を解く際に用いられる数学的な技術です。これにより、時間領域の方程式をより扱いやすいs領域（ラプラス領域）に変換し、代数的な方法で解を求めることができます。しかし、これは元の微分方程式が線形であり、初期条件が与えられた場合に限ります。
五次方程式などの多項式方程式の解法については、ラプラス変換ではなく他の手法が必要です。五次方程式は、一般にガロア理論により、代数的な解（有理数と根号を使った閉じた形の解）を持たないことが証明されています。そのため、五次方程式の解は代数的手法ではなく、数値解法（ニュートン法やその他の数値的アプローチ）を用いて求める必要があります。
ラプラス変換を五次方程式の解法に適用しようとすると、その方程式が特定の微分方程式から導出される場合に限り有効なアプローチになる可能性はありますが、多項式そのものを直接解く手段としては使用されません。

2026年6月27日土曜日

Bracmatは、1990年代以降にBart Jongejanによって開発された記号処理言語

Bracmatは、1990年代以降にBart Jongejanによって開発された記号処理言語であり、構文解析、パターンマッチング、木構造変換、論理探索を単一の実行モデルへ統合しようとした試みとして位置付けられる。その設計思想は、COMIT、SNOBOL、Icon、Prolog、Lispといった記号処理系の系譜に連なりながらも、コンパイラや仮想機械を中心とする現代的言語処理系とは異なる発展を遂げた。Bracmatにおいてプログラムは主として木構造として表現され、評価とは命令列の逐次実行ではなく、パターン照合と項書換えの連続として理解される。特に「:」演算子による構造分解は、代入、構文解析、照合、束縛を同時に実現し、プログラムとデータの境界を曖昧にする。

実装面では、BracmatはC言語による小規模なインタプリタとして構築されており、ソースコードは内部木構造へ変換された後、再帰的なパターンマッチャとバックトラック機構によって評価される。このためBracmatは、一般的なプログラミング言語というよりも、項書換えシステム、エキスパートシステム、自然言語解析器、あるいは知識表現基盤として理解する方が適切である。実際に自然言語処理、XML変換、ルールベース推論などへの応用例が存在する。

Bracmatを味わうとは、プログラムを「計算手順」ではなく「意味構造の変形過程」として眺めることである。それはAI以前の記号処理研究が追求した、知識と規則を直接実行可能な形で記述するという思想を現代に伝える貴重な実験系なのである。

関連キーワード：
Bracmat、Bart Jongejan、記号処理、パターンマッチング、項書換え系、バックトラック、SNOBOL、Icon、Prolog、Lisp、抽象構文木、知識表現、自然言語処理、ルールエンジン、木構造変換、記号AI、論理プログラミング、DSL、再帰下降、構文解析

2026年6月26日金曜日

ODBCおよびJDBCに至るデータベース接続技術の系譜

概要

ODBCおよびJDBCに至るデータベース接続技術の系譜は、単なるAPI設計の歴史ではなく、異種システム統合という計算機科学上の長期的課題への回答として理解できる。その源流は、IBMのIMSやDB2、CICSにおけるセッション管理やトランザクション制御にあり、データベースを状態を持つ資源として扱う思想が形成された。さらにUNIX文化は、FILEやソケットに代表されるハンドルベースの抽象化を発展させ、実体を隠蔽しながら統一的な操作体系を提供した。1980年代にはネットワーク化の進展に伴い、RPCやクライアント／サーバモデルが普及し、遠隔資源を局所的なAPIとして扱う設計思想が一般化する。

このような背景のもと、SQL Access Group（SAG）は異なるデータベース製品間の相互運用性確保を目的としてCLI（Call Level Interface）を整備した。CLIはConnection、Statement、Cursor、Prepare、Fetchといった概念を定式化し、データベース操作を状態遷移を伴う抽象オブジェクトとして扱う枠組みを提供した。MicrosoftはこれをWindows環境へ移植し、Driver ManagerやDSNを導入したODBCとして発展させた。さらにSun MicrosystemsはJava環境向けにJDBCを設計し、CLIおよびODBCの概念を完全なオブジェクト指向APIとして再構成した。

この流れを味わう視点から見ると、ODBCやJDBCは単なる接続技術ではなく、メインフレーム時代の資源管理思想、UNIXの抽象化文化、分散システム理論、そしてオブジェクト指向設計が交差する地点に位置している。そこには「異なるものを統一的に扱う」という計算機科学の普遍的な願望が刻み込まれており、現代のORMやクラウドデータアクセス基盤にも連続する設計思想を読み取ることができる。

2026年6月25日木曜日

「SWF仕様とAVM2――公開された仮想機械と失われた実行環境」

Flashをめぐる仕様公開の歴史は、単なる企業技術の開示ではなく、閉じた実行環境がいかにして半ば公共的な読解対象へ変化したかを示す事例である。SWF仕様、ActionScript、AVM2、ABCバイトコード、Tamarinといった関連キーワードは、Flash Playerという巨大な体験装置を分解するための入口となる。SWF File Format Specificationは、図形、タイムライン、音声、動画、スクリプトを格納するファイル構造を記述し、AVM2 OverviewはActionScript 3.0を実行する仮想機械のモデルを示した。さらにTamarinによってVM実装の一部がオープンソース化されたことで、Flashは完全なブラックボックスではなくなった。しかし、レンダリングの微妙な互換性、ブラウザ連携、セキュリティサンドボックス、動画再生、商用プラグインとしての統合挙動までは、仕様書だけで完全に復元できるものではなかった。したがってFlashを味わうとは、公開仕様の存在を確認するだけでなく、仕様、実装、互換性、企業支配、そして後年のRuffleのような再実装が交差する地点を読むことである。Flashは、仕様が公開されてもなお、実行環境全体の文化的記憶は仕様書の外側に残ることを教えている。

CAFISは、NTTデータが運用する日本の代表的なキャッシュレス決済基盤

CAFISは、NTTデータが運用する日本の代表的なキャッシュレス決済基盤であり、1984年にカード決済ネットワークとして開始された。現在はクレジットカード、電子マネー、QRコード決済、インバウンド決済、BankPay、ことら等にも接続し、加盟店、決済事業者、カード会社、金融機関を結ぶ幹線網として機能している。

CAFISを「味わう」視点で重要なのは、これが単なるAPIや通信仕様ではなく、決済要求、承認、売上、取消、精算、端末、加盟店契約、障害対応、セキュリティを含む制度的インタフェースである点にある。PayPay等の表層がアプリ、QRコード、SDKとして現れるのに対し、CAFISはその背後で異なる事業者間の責任境界を接続する。すなわちCAFISとは、公開仕様として読むよりも、日本の決済制度が実装された不可視の仕様群として読むべき対象である。

関連キーワード：CAFIS、NTTデータ、キャッシュレス決済、クレジットカード、電子マネー、QRコード決済、BankPay、ことら、PSP、決済代行、加盟店、カード会社、金融機関、アクワイアラ、イシュア、POS連動、INFOX、承認電文、売上処理、取消処理、精算、PCI DSS、24時間365日運用、制度的インタフェース、決済の地層。

B-CAS方式における放送アクセス制御の仕様史的考察

概要
B-CAS方式は、日本のデジタル放送において、放送波、受信機、ICカード、契約管理、著作権保護を接続するために導入されたアクセス制御方式である。公開仕様の中心にはARIB STD-B25があり、限定受信方式、スクランブル、受信機仕様、コンテンツ保護方式などが規定される。本稿では、B-CASカードを単なるテレビ付属品ではなく、家庭用受信機に挿入された制度インターフェースとして捉える。映像や音声は放送波で配信されるが、視聴可否、契約状態、復号、コピー制御は、受信機とカードの協調によって処理される。すなわちB-CASは、テレビ視聴という日常的行為を、暗号技術、標準化、著作権保護、契約管理の交点に再配置した。さらに4K/8K放送以降は、ARIB STD-B61やACASにより、物理カードから受信機内蔵型CASへと移行する。この変化は、放送制度がカードとして外部化される段階から、機器内部に統合される段階への移行として読むことができる。

キーワード
B-CAS、ARIB STD-B25、限定受信方式、デジタル放送、ICカード、スクランブル、著作権保護、コピー制御、ACAS、制度インターフェース

Haar特徴に基づくカスケード分類器

本稿は、Haar特徴に基づくカスケード分類器を、単なる顔検出アルゴリズムではなく、画像を矩形領域の和と差分へ還元する実行可能な仕様として読む試みである。Haarの名は、1910年の直交関数系に由来するが、OpenCVにおけるHaar Cascadeは、連続関数の理論そのものではなく、白矩形と黒矩形の画素和差分を特徴量とし、それを多数の正例・負例画像から学習した分類器としてXMLに保存する実装形式である。Viola and Jonesの2001年論文は、Integral Image、AdaBoost、Cascade構造を結合し、膨大な候補窓の評価を高速化した。この構成により、画像は意味として理解される前に、矩形特徴、しきい値、弱分類器、段階的棄却という手続きへ分解される。OpenCVのCascadeClassifier APIは、この学習済みXMLを読み込み、detectMultiScaleによって顔や目の候補矩形を返す。ここに見えるのは、AI以前の機械学習が、視覚をいかに集約演算と条件分岐の体系へ翻訳したかという、仕様化された視覚認識の姿である。

CORSの味わい

本稿は、CORSを単独の通信仕様ではなく、ブラウザがコードの出自を管理してきた歴史の一段階として読む。出発点は1990年代半ば、Netscape期に成立したSame-Origin Policyである。これは、あるWebページのスクリプトが別Originの文書や資源を勝手に読めないようにする境界だった。しかしWebは画像、CSS、scriptタグなどを通じて最初から越境的であり、2000年代にはJSONPのような非公式な回避策が広がった。CORSは、この越境をHTTPヘッダで明示的に許可する制度として標準化される。すなわち、無秩序な抜け道を、Originにもとづく許可の手続きへ変換したのである。さらに現在、この考え方はLocal Gatewayにも応用できる。CDNやローカルHTTPサーバのように検証可能なOriginを持つコードだけに、認証、署名、評価器実行、ローカルファイル読込などの能力を渡す。一方、file://、data:、sandbox iframeのようなnull Originは拒否する。ここにCORSの味わいがある。CORSは単に外部APIを読む技術ではなく、出自なきコードをローカル能力から遠ざける、ブラウザ的な身分制度なのである。関連キーワード：Same-Origin Policy、Netscape Navigator、Origin、Cross-Origin Resource Sharing、CORS、JSONP、script tag、HTTP Header、Access-Control-Allow-Origin、Preflight Request、Null Origin、Opaque Origin、file://、data: URL、sandbox iframe、CDN、Local Gateway、Local Auth Server、Local Capability、Origin-Bound Capability、No-Origin No-Eval、Code Provenance、Distribution Authority、Browser-Mediated Trust、Capability-Based Security、Subresource Integrity、Signed Manifest、Build Hash、Pairing Code、Session Token

SDLとhtml5.hの関係

WebAssembly環境におけるSDLは、単なる移植用ライブラリではなく、ブラウザを一つの実行プラットフォームとして扱うための抽象化装置である。SDLはWindow、Renderer、Event、AudioといったC APIを通じて、画面・音・入力という外界をアプリケーションに提示する。一方、Emscriptenのhtml5.hは、Canvas、KeyboardEvent、MouseEvent、requestAnimationFrameなどのHTML5機能をC/C++から扱うための低レベル接続面である。Emscripten版SDLは、このhtml5.hおよび生成JavaScript glue codeの上に構築され、SDL_CreateWindowをHTMLCanvasElementへ、SDL_PollEventをブラウザイベント由来のSDL_Eventへ、SDL_RenderPresentをCanvas/WebGL描画へ写像する。本稿は、SDLを上位の安定した抽象インタフェース、html5.hを下位のブラウザ接続口として読み、その間にあるEmscripten backendとJS glueの役割を検討する。そこに見えるのは、WebAssemblyが計算だけを運び、画面・音・入力は翻訳層によって初めてブラウザに接続されるという、移植技術の制度的構造である。

キーワード：WebAssembly、SDL、Emscripten、html5.h、JavaScript glue code、Canvas、WebGL、KeyboardEvent、SDL_Event、SDL_Renderer、HTMLCanvasElement、Browser API、移植層、低レベルバインディング

2026年6月24日水曜日

FITS ― 宇宙観測を未来へ運ぶ保存形式の思想

FITS（Flexible Image Transport System）は、1970年代後半に天文学コミュニティによって策定された観測データ交換・保存形式であり、今日に至るまで天文学の事実上の標準として利用されている。一般的な画像フォーマットが表示を目的とするのに対し、FITSは観測結果そのものを保存するための科学データ形式である。ファイルには天体画像だけでなく、観測日時、望遠鏡、検出器、波長、天球座標などの科学的文脈がASCIIテキストのヘッダとして格納される。この設計により、数十年後の研究者であっても観測条件を再現しながらデータを解析できる。

FITSを味わう際に興味深いのは、その構造が磁気テープ時代の計算機文化を色濃く残している点である。80文字固定長のヘッダカード、2880バイト境界への整列、ビッグエンディアン表現などには、異機種間で科学データを共有しようとした当時の技術的制約と理想が刻み込まれている。これは単なるファイル形式ではなく、国や組織を超えて観測成果を保存し続けるための社会的契約でもあった。

FITSの世界では「Once FITS, Always FITS」という言葉が知られている。すなわち、一度記録されたFITSデータは将来の計算機でも読み出せるべきであるという原則である。この思想は長期保存を重視するアーカイブ文化そのものであり、UNIXのtarやPostScript、あるいはRFC文書群に通じる精神を持つ。現代ではCFITSIOやAstropyを通じてPythonやAI解析環境とも接続されているが、その根底には「観測の記憶を未来へ伝える」という設計思想が変わらず流れている。FITSは宇宙を撮影するための形式ではなく、宇宙観測という知的営為そのものを保存するための仕様なのである。

関連キーワード

FITS、Flexible Image Transport System、天文学、観測データ、科学データ形式、ASCIIヘッダ、メタデータ、CFITSIO、Astropy、SAOImage DS9、IRAF、WCS（World Coordinate System）、磁気テープ、長期保存、データアーカイブ、NASA、Virtual Observatory、科学的再現性、Once FITS Always FITS、宇宙観測インフラ

YouTube 解説キャプション URL入力版

サンプルURL入りです。YouTubeの通常URL、短縮URL、埋め込みURL、Shorts URL、動画IDだけでも読み込めます。Enterキーでも読み込みます。

再生すると、ここに解説キャプションが表示されます。

video id: loading... / current time: 0.00s

字幕はYouTube動画の下に表示します。動画の上には重ねないので、プレーヤー操作を邪魔しません。

上のJSONを編集して「字幕JSONを反映」すると、表示タイミングを変更できます。start / end は秒数です。小数秒も使えます。