PQC移行の課題と対策｜RWC2026に学ぶML-KEM／ML-DSAのTLS・PKI設計・運用ポイント

PQCへの移行は、アルゴリズムを置き換えれば終わる話ではない。本記事では、PQC（Post-Quantum Cryptography：耐量子計算機暗号）^[n]技術を実装する実例をもとにした具体的な課題を、RWC2026で共有された内容を基に紹介する。

本記事が、PQCの実運用への到達度の理解とともに、現場で直面する具体的課題および企業として取り得る戦略的対応を整理する一助となれば幸いである。

なお、PQCの現状整理や既知の課題、業界動向については下記資料に体系的に整理されているため、本記事では詳細には立ち入らない。

https://www.nri.com/jp/knowledge/report/2025forum397.html

第1章：ML-KEM（鍵共有）の課題

ML-KEMは、PQCの中でもChromeやCloudflareで試験的に実装されており、意識せずとも実運用環境に浸透しつつある状況にある。RWC2026では、ML-KEMにおいてハイブリッド鍵交換（本章①設計レベルの課題の論点①で詳細）が前提となると述べられており、その設計・実装・運用それぞれの観点で課題が指摘されていた。

それぞれの課題の前に前提知識となるML-KEMを含むハイブリッド鍵交換の動作を下記に示す。

＜図：TLS1.3における鍵交換（KEM）にフォーカスした概念分解図（古典vsハイブリッド）＞

①設計レベルの課題（プロトコル／アーキテクチャ）

論点1：ハイブリッド鍵交換（Hybrid Key Exchange）の必然性

<図：TLS1.3における単一鍵交換とハイブリッド鍵交換の構造比較とその意義＞

ここでいうハイブリッドとは、複数の共有秘密（上記図のZ1,Z2）を組み合わせて単一の鍵（上記K）を生成する鍵交換における共有秘密のハイブリッドを指す。

ML-KEMは実運用での利用実績がまだ浅く、古典（ECDHE等）と比較して長期的な安全性評価が十分とは言えない。このためRWC2026では鍵交換において一方のアルゴリズムに問題が生じた場合でも通信の機密性を維持できるよう、複数の鍵素材を組み合わせるハイブリッド鍵交換が現実的な設計とされている。

例えば、TLS1.3ではECDHEとML‑KEMの組み合わせをハイブリッド鍵交換として実装する実証が進められており、ハンドシェイク内にそれぞれの方式の２種類の共有秘密を生成しておくことで、一方（例えばML‑KEM）が破られても通信全体の機密性が維持されるように設計されている。

こうすることで例えばもし将来ML‑KEMに脆弱性が判明したとしても、通信のセッション鍵はECDHE側の安全性に支えられている。

勘違いされやすいが、ハイブリッド鍵交換とは、2種類の鍵を別々に作って後から安全な方を選ぶことではない。

ECDHEとML-KEMはそれぞれ独立に共有秘密を生成するが、TLS1.3等の設計では、それらはあくまで鍵素材に過ぎず、最終的にはKDF（次の論点2で詳細）によって不可逆にミックスされ、単一の鍵材料が生成される。通信で実際に使われる鍵はこの最終鍵だけであり、「2本立て」で並列に鍵を使うわけではない。

したがって、ここでいうハイブリッド鍵交換は、『状況に応じてアルゴリズムを使い分ける（事後的な選択）』ことではなく、両方式の安全性を一つの鍵に凝縮する（強固にする）ための仕組みである。

実運用観点では、既にIETFにおいて仕様化に向けた検討（Internet-Draft）が進められており^[i]、ChromeやCloudflareで試験的に実装されている。^{[ii][iii][iv]}

論点2：KDFにおける結合方式の安全性と設計配慮：単純結合は危険、理論保証が必要

＜図：ハイブリッド鍵交換により複数の共有秘密をどう混ぜるかという観点が発生＞

KDF（Key Derivation Function）とは、共有秘密などの入力値から安全な鍵を導出する関数であり、所定の鍵長や乱数性を満たすために用いられる。

ハイブリッド鍵交換を前提とすると、ECDHEとML‑KEMはそれぞれ独立に共有秘密を生成するが、KDFへの入力として両者をどのように結合するかが重要な論点となるとRWC2026では言及されていた。（KDF自体は単一の共有秘密の場合でも利用される。）

２つの共有秘密Zを単純に横並びにする素朴な結合は望ましくない。これは、片方の共有秘密が推測・露呈した場合に最終鍵の構造や残りの鍵素材に関する情報が攻撃者に与えられるほか、「少なくとも一方が安全なら最終的な共通鍵も安全」という性質を証明できないためである。

このため、「どのような条件下で、結合後の鍵がどのレベルの安全性（IND‑CCA^[v]等）を維持できるか」を厳密に定義し、証明する研究が進められている。

結合方式の一例として、シンプルなKitchen‑Sink型がある。これは安全性を確保するため、共有秘密だけでなく暗号文などの関連情報も含め、利用可能な要素を幅広くKDFに投入する設計である。この方式は入力情報を増やすことで鍵素材間の結び付き（binding）を強め、安全性を保ちやすい構成となるが、その分KDF処理におけるデータ量および計算負荷が増大し、性能低下の要因となる。

^{また既存研究X‑Wing[vi][vii]}においてはML-KEM（厳密にはFO変換KEM全般）がciphertext second preimage resistance（c2‑PRI）と呼ばれる性質を持つことを前提条件として、DHとML-KEMの組み合わせにおいて、暗号文をKDF入力から除外しても安全性が維持されることが示されている。

さらに近年の研究QSI^[viii]では、c2‑PRIのような性質を満たすKEMを前提とすることで、特定の方式の組み合わせ(DHとML-KEM等)に依存しない形でも安全性が成立することが示されている。

論点3：プロトコル影響：パフォーマンス劣化

TLS1.3のハイブリッド鍵交換に関するIETFの検討では、ハンドシェイクにおいて追加の往復通信（round trip）を発生させないこと（No extra round trips）や低遅延の維持（Low latency）が設計目標として明示されており、通信量と通信回数の双方が性能に影響する要素として考慮されている。^[ix]

①サイズ増加による影響（Low latencyの観点）

＜表：ML‑KEMにおけるパラメータセット別の鍵および暗号文サイズ^[x]＞

＜図：TLS1.3における鍵交換(KEM)にフォーカスした通信量の比較（古典ECDHE vs ML‑KEM‑512）^[xi]＞

まず、データサイズの増加はLow latencyの観点における主要な影響要素の一つである。従来のECDHE（X25519）では鍵共有に伴う通信データは総計でも約64Bと非常に軽量であったのに対し、ML-KEM-512を用いた場合は約1.5KB（約24倍）に達し、大幅な増加となる。

このようなデータ量の増加は、ネットワーク帯域やパケット分割の影響を受けることで、送信時間の増加や通信効率の低下につながる可能性がある。

特にモバイル回線や高遅延環境では、パケット数の増加や輻輳制御の影響も含め、通信遅延の要因となり得る。

②通信回数増加による影響（No extra round tripsの観点）

＜図：専用NamedGroupによるハイブリッド鍵交換の理想フローと移行期の現実＞

ハイブリッド鍵交換では、従来の単一鍵交換とは異なり、複数の鍵交換要素（例えばX25519とML-KEM）を組み合わせて共有秘密を生成する必要がある。

このような構成はTLS1.3の設計時には想定されておらず、複数の鍵交換要素をどのようにClientHelloで送信・交渉するかが新たな課題として生じる。

ハイブリッド鍵交換に関するIETFの検討では、追加の往復通信を発生させないこと（No extra round trips）が設計目標として明示されており、その解決手段として、複数の鍵交換方式を単一の「Named group」として扱う構成が提案されている。（上記図の【1】）^[ix]

ただし、これはハイブリッド鍵交換が前提となる将来を見据えた設計であり、普及のためにはサーバ側の対応とそれに基づくブラウザのデフォルト実装が必要となるため、広範な適用には時間を要する。

そのため、仮にサーバ側でハイブリッド鍵交換用のNamedGroupに対応していたとしても、当面はブラウザ側でX25519による単一鍵交換がデフォルトとして用いられることが想定される。

その結果、鍵交換方式の不一致によりHelloRetryRequestが発生し、再送（RTT増加）が生じ得る状況が継続すると考えられる。（上記図の【2】）

②実装レベルの課題（コード・安全実装）

実装面では、単にアルゴリズムが動くだけではなく、微細な挙動に起因する以下表のような脆弱性を排除する必要がある。

このため、PQCに限った話ではないが、仕様と実装の一致が数理的に保証された「検証済み実装（Verified Implementation）^[xii]」の採用に加え、サイドチャネル対策やメモリ安全といった安全性を考慮した実装が求められる。

その具体例として、ML-KEMの検証済み実装を提供する暗号ライブラリであるmlkem-nativeが、PQCAのPQ Code Packageプロジェクトより公開されている。^[xiii]

mlkem-nativeはCBMC^[xiv]により、仕様に対する機能的正しさの検証に加え、タイミングサイドチャネル（定数時間性）やメモリ安全を考慮した実装が保証されている。（ただし執筆段階ではタイミング以外でのサイドチャネルはスコープ外とREADMEに明言されている。）

＜表：ML-KEM実装でも気にすべき実装における主要な課題＞

③運用レベルの課題（監視観点の増加・動作遅延）

運用面では、RWC2026のPQC関連セッションにおいて、特に可観測性・透明性の確保や、データ量・処理負荷の増加を前提とした運用設計の重要性が示唆されていた。

なお、これらのセッションでは課題や問題意識については言及されていた一方で、具体的な運用レベルの課題対応策については明示的に提示されていなかった。

論点1：PQCの利用有無および意図しない降格（フォールバック）を監視する必要がある

鍵交換方式の監視という観点では、RSAからECDHEへの移行時にも同様の構造は存在した。しかし、両者は同一の古典暗号の枠内での強度差に留まるものであり、利用された鍵交換方式の観測は必ずしも主要な監視対象とはされてこなかった。

これに対しPQCでは、量子計算機を用いた攻撃を前提とした場合には、PQCの利用有無がそのまま保護可否に直結する。このため、実際にPQCが利用されたか否かの観測は重要となる。

さらに、ネゴシエーション過程における不整合や通信経路上の干渉により、意図せず古典方式へフォールバックしている可能性がある。

このようなフォールバックを適切に評価するためには、サーバ側で最終的に選択された鍵交換方式の観測だけでなく、クライアントがどの鍵交換方式を提示していたかといったネゴシエーション過程全体を把握する必要がある。

しかし、従来は鍵交換方式の違いが同一の古典暗号の枠内での強度差に留まっていたため、このような観点での監視手段が整備されておらず、大きな問題としては認識されてこなかった。

これに対しPQCでは、古典方式へのフォールバックがそのまま量子耐性の喪失につながり得るため、こうした監視上の課題が顕在化する。

論点2：検証時のエラーが切り分けしづらい

ハイブリッド鍵交換では、図「TLS1.3における通常鍵交換とML-KEMを含むハイブリッド鍵交換の動作比較」の通り、複数の鍵交換処理（古典およびPQC）が並行して実行されるため、その成否の組み合わせとして複数の内部状態が生じる。

これにより、同一の失敗に見える結果であっても対応する内部状態が異なり、原因の特定や再現が困難となる。

【「TLS1.3における通常鍵交換とML-KEMを含むハイブリッド鍵交換の動作比較」内で想定される失敗例】

• ・Step3（鍵交換）：PQCは成功したが、古典鍵交換が失敗した

• ・Step3（鍵交換）：古典鍵交換は成功したが、PQC処理（復号）が失敗した

• ・Step4〜Step5：双方の鍵交換は成功したが、KDFによる鍵導出処理で不整合が発生した

• ・Step1〜Step3：TLS拡張やパラメータの不整合により鍵交換処理自体が成立しない

このように、TLSのエラーコードは抽象的（handshake_failure等）であり、詳細な失敗理由は標準ログに出力されないため、どの段階で失敗したのかを外形的に判別することは難しい。

論点3：ハンドシェイク肥大化

ハイブリッド鍵交換に起因する通信データ量の増加および交渉過程における追加の往復通信（RTT）の発生により、TLSハンドシェイクのレイテンシが増大する可能性がある（詳細は本稿「①設計レベルの課題：論点3参照」）。

RWCでは言及されていなかったが筆者が思うに鍵交換から毎回始めるフルハンドシェイクの発生頻度自体を抑制する方向の運用が重要になると考えられ、その解決策として、TLS1.3におけるセッション再開（Session Resumption^[xvi]）等の最適化手法の活用が進むと予想される。

これは、一度フルハンドシェイクによりセッションが確立された後は、公開鍵交換や証明書検証といった重い鍵交換処理を繰り返し行わず、チケット情報（PSK）を用いてセッションを再開できる仕組みである。（詳細は本稿では割愛）

第2章：ML-DSA（署名）の課題

RWC2026で最も言及が多かったのがML-DSAである。理由は単純で、ML-KEM（鍵共有）が通信ごとに実行される一時的な鍵交換のみに影響するのに対し、ML-DSA（署名）は「証明書」「TLS認証」「コード署名」「ソフト配布」等極めて影響範囲が広いことにある。

＜表：同bit強度における古典署名とML-DSAのサイズ比較＞

PQC署名は上記表のとおりサイズが極端に大きく、現行設計のまま導入した場合、証明書サイズの増加やTLS通信の遅延といった影響が想定される。

上記表でいう安全性（bit強度）とは、攻撃者が当該暗号を破るために必要な計算量（work factor）をビット数で表したものであり、nビットの安全性は約2のn乗回の計算を要する強度を意味する。ただし、古典暗号は古典コンピュータによる攻撃を前提とした強度であるのに対し、PQCは将来的に量子計算機を用いた攻撃に対しても同等の強度を維持することを目的として設計されている点に本質的な違いがある。

この前提に注意しつつ、同じbit強度で比較するとML-DSAにおいては、bit強度毎に若干の差分はあるものの、公開鍵サイズは古典署名の約20倍、署名サイズは同約40倍となり、将来の量子計算機を用いた攻撃に対して同等の安全性を保つためにはデータ量が大幅に増加する。

①サイズ問題に起因したTLS通信の課題

＜図：TLS1.3における証明書・署名のサイズにフォーカスした増加のイメージ（第2フライト）＞

従来のECDSA P-256からML-DSA-44を現行の証明書基盤およびTLSにそのまま適用した場合、TLSの第2フライトにおけるデータサイズは、従来の約1KBから約14KB超へと大幅に増加する可能性がある。（RWC2026では、データ量が1KB増加するごとに、従来方式と比較して約1.5%の遅延増加が発生するとの指摘もなされている。^[xx]）

この課題への有力な解として検討されているのがMerkle Tree Certificates（MTC）^[xxi]である。従来だと上記の通りTLS通信時、従来のX.509証明書チェーンでは、PQC署名の導入により通信量が大幅に増加するが、Merkle Tree Certificates（MTC）では、証明書チェーン全体を送信する代わりに、以下の情報の送信へと置き換わる。

（MTCの仕組みの詳細は本記事では割愛。詳細は^[xxi]を参照）

• ・MTC証明書（公開鍵およびドメイン名などのメタ情報。従来のようなCA署名は含まれない）

• ・Merkle包含証明（対象証明書がCAの管理するMerkle Treeに含まれていることを示すハッシュ列）

この構造により、通信データは主に軽量なハッシュ列へと置き換えられるため、PQC署名を用いた場合でも通信量を大幅に削減できる。RWC2026では、従来のX.509証明書チェーンで約14KB超となる通信量を約0.7～1KB程度（条件によっては数KB）まで削減可能とされていた。^[xxii]

MTCは現在、IETFのPLANTS Working Groupで標準化作業が進行中であり^[xvi]、Google ChromeとCloudflareが連携し、実ブラウザ（Chrome）および実トラフィックを用いた環境において、MTCの実証実験および性能評価が既に開始されている^{[xxiii][xxiv]}。

従ってこれは将来構想にとどまる研究提案ではなく、PQC署名をWeb PKIに導入するための現実的な移行パスとして、ブラウザベンダ主導で段階的展開が検討されている技術である。

②サイズ問題に起因した鍵管理・運用モデルの課題

＜図：PQC署名サイズ増大による失効モデル(CRL）の課題と短命証明書による解決アプローチ＞

PQC署名の導入により、証明書および署名サイズは大幅に増加する。

この影響は上記図の通り、「1)証明書を発行する通信」および「3)証明書の失効状態を確認する通信」など、PKI運用モデル全体に及ぶ。

この中で本質的な課題となるのは、TLS通信ごとに発生する「3)証明書の失効状態を確認する通信」の中のサーバ証明書の状態確認である。（他方、「1)証明書発行処理」や「3)証明書の失効状態を確認する通信」内の中間CA証明書の状態確認はTLS通信ごとに発生するものではなく、事前に実施される処理であるため、ユーザの接続遅延には直接影響しない。）

この課題に対する有力な解として、RWC2026では、サーバ証明書の失効確認を不要とする短命証明書モデルが紹介されている。

短命証明書モデルでは下記設計を採用することで、サーバ証明書に対するCRL/OCSPの失効確認そのものを不要とする。

• 証明書の有効期間を数日〜数週間とする
• 問題発生時は失効ではなく期限切れで無効化する

これにより、PQCにおいて問題となる「署名付き失効応答の転送」が構造的に削減される。

短命証明書モデルでは、証明書の高頻度更新を前提とするため、証明書ライフサイクル全体を自動化するための要件として、以下の機能が必要となる。

①証明書発行の自動化（代表的な実現手段）

• •ACME（Let's Encrypt型）^[xxv]
  　→Webサーバ等がACMEクライアントを介して自動的にCAへ証明書発行要求を送信し、応答を取得する仕組み
  •CA APIによる発行^[xxvi]
  　→CAベンダが提供するAPIを用いて、証明書の発行・更新をプログラムから制御する仕組み

②配布の自動化（自動デプロイの対象）

• •Webサーバ
  　→取得した証明書を自動的に配置し、設定反映（reload等）までを無停止で実施する
  •Load Balancer
  　→管理API等を通じて証明書を自動登録・切替し、トラフィック断を伴わず反映する
  •CDN
  　→取得した証明書をエッジ（各拠点）に自動配布し、グローバルに即時反映する

③ローテーション管理（実現すべき機能）

• •期限前の自動更新
  　→証明書の有効期限を監視し、期限到来前に自動的に新証明書を取得・更新する
  •無停止での証明書切替
  　→既存セッションに影響を与えずに新証明書へ切替（ホットスワップ）を実現する

このように、本方式は運用負荷（証明書期限切れや設定）を単純に軽減するものではなく、「手動＋失効確認中心」から「自動化＋短命証明書中心」への運用モデルの転換を意味する。

また本方式は、PQC対応だけでなく人的要因による障害を防ぐ観点でも有効なアプローチとなる。

③サイズ問題に起因したしきい値署名の課題

PQC署名のサイズ肥大化は、しきい値署名のような分散型署名方式にも影響を及ぼす。

複数ノード間での通信や計算が前提となるため、署名サイズや処理負荷の増大はそのままシステム全体の複雑性・性能劣化に直結する。

このような課題に対しては、Mithril^[xxvii]というプロジェクト名にて複数ノードでML-DSA署名を生成するプロトコルなどの研究が進められているが、現時点ではノード数や通信ラウンドに制約があり、汎用的な実用には至っていないため、RWC2026では限定的なユースケースにおける検証段階にある技術と位置付けられていた。

終章：企業としてのPQC移行はどう進めるべきか（現実的なアプローチ）

これまで見てきた通り、PQC移行はアルゴリズム単体の問題ではなく、鍵交換・プロトコル・PKI・運用が連鎖して影響する構造的な変化である。

重要なのは、これらの本記事で述べた課題のすべてが企業の努力で解決できるものではないという点である。設計上避けられない制約や、標準化対応に依存する領域も多く、企業としては「何が対応可能で、何が制御できないのか」を前提に移行を進める必要がある。

最後に筆者の目線から、本記事で取り扱った課題と企業としての対応可否という観点で整理して本稿の結びとする。

＜表：PQC移行における課題まとめと企業の対応余地＞

[n]PQC（Post-Quantum Cryptography：耐量子計算機暗号）
将来の量子コンピュータによる既存暗号（RSAやECCなど）の解読リスクに対抗するため、量子計算機でも現実的な時間で解読が困難とされる新たな暗号方式群である。

[i]IETF Datatracker（Hybrid key exchange in TLS1.3）

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

[ii]Chromeの試験的実装内容（TLS1.3でX25519+Kyber768のハイブリッド鍵交換を実装）

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

[iii]Chromeの試験的実装内容（Kyber→ML‑KEMへの移行、X25519 + ML‑KEM‑768 を TLS 1.3 で継続利用）

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html

[iv]Cloudflareの試験的実装内容（X25519+Kyber を用いたTLS 1.3のハイブリッド鍵交換を実トラフィックで展開）

https://blog.cloudflare.com/post-quantum-to-origins/
[v]IND‑CCA（Indistinguishability under Chosen‑Ciphertext Attack）安全性
…攻撃者が以下の3つの条件を与えられても、暗号文を解読できない強固な状態を指す。

1. 通信を盗聴できる。
2. 任意の暗号文をシステムに送り、その復号結果（正誤など）を確認できる。
3. 過去の復号結果をヒントにして、さらに巧妙な暗号文を次々と作成して試行錯誤できる。（適応的攻撃）

[vi]X-Wing:原論文（IACR ePrint）X-Wing: The Hybrid KEM You’ve Been Looking For

https://eprint.iacr.org/2024/039

[vii]X-Wing:general-purpose hybrid post-quantum KEM draft-connolly-cfrg-xwing-kem-10

https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/

[viii]QSI:原論文（IACR ePrint）Starfighters—On the General Applicability of X-Wing

https://eprint.iacr.org/2025/1397

[ix]Hybrid key exchange in TLS1.3draft-ietf-tls-hybrid-design-16

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

[x]FIPS203(ML-KEM Parameter Set)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

[xi]RWC2026の「Post‑Quantum Cryptography and Hybrid Key Exchange」セッションby　 Google Chrome / Secure Web & Networking Teamの共有内容から筆者が要約。

[xii]本記事では実装と仕様の一致が数理的に検証され、機能的に正しく動作することが保証された実装を指す。

[xiii]First stable release of mlkem-native v1 under PQ Code Package Project

https://pqca.org/blog/2025/first-stable-release-of-mlkem-native-v1-under-pq-code-package-project/

[xiv]CBMC（C Bounded Model Checker）
…Cプログラムを論理式として解析し、バッファオーバーフローや整数オーバーフローなどのバグが生じる入力が存在しないことを数理的に検証する形式検証ツール。

[xv]RWC2026の「mlkem-nativeA unified, fast and verified ML-KEM library」セッションの共有内容から筆者が要約。

[xvi]RFC8446Section 2.2（Session Resumption）

https://datatracker.ietf.org/doc/html/rfc8446

[xvii]Cultivating a robust and efficient quantum-safe HTTPS (Googleブログ記事)

https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/ 

[xviii]古典署名（ECDSA）のサイズはFIPS 186-5におけるアルゴリズム仕様および、TLS/X.509における一般的な符号化形式（DER）に基づく実装上の代表値である。

[xix]FIPS204のParameter Set tableより引用。

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf

[xx]RWC2026の「(Dis)patches from the WebPKI（Fina, Static CT, MTC, and PLANTS）」セッションの共有内容から筆者が要約。

[xxi]IETF Datatracker(Merkle Tree Certificates)

https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/

[xxii]IETF Datatracker（PKI,Logs,And Tree Signatures (plants)）

https://datatracker.ietf.org/wg/plants/about/

[xxiii] Cultivating a robust and efficient quantum-safe HTTPS (Googleブログ記事)

https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/

[xxiv]Keeping the Internet fast and secure:introducing Merkle Tree Certificates（Cloudflareブログ記事）

https://blog.cloudflare.com/bootstrap-mtc/

[xxv] 証明書を自動で発行・更新するための標準プロトコル（IETF標準：RFC8555）

https://datatracker.ietf.org/doc/html/rfc8555

[xxvi] CAベンダが提供する独自API

[xxvii] Mithril

https://mithril-th.org/