オッス！
GMOコネクトで執行役員CTOをしている菅野 哲（かんの さとる）です。
みなさま、いかがお過ごしですか？
先日、グループ内でチャエンさんのAI活用講座がありました。そこで何気なく耳にした一言：
「このAIエージェント、最新の暗号技術をMCPサーバー経由で使ってるんですよ」
！！！！
ワイの脳内でアラートが鳴り響きました。
MCPサーバの存在は知っていましたが、「最新の暗号技術」というワードが引っかかりました。
普段からIETFの標準化活動やPQC（Post-Quantum Cryptography）調査・活動をしている身としては、具体的にどんな暗号技術が実装されているのか気になって仕方ありません。
講座後、すぐに調査を開始しました。Skywork.aiという企業が提供している一連のMCPサーバー群を片っ端から追いかけた結果...
結論から言うと、想像の10倍ヤバかった。
週末を使って徹底的に技術資料を読み込んだので、その調査結果を共有します。
この記事でわかること
正直、途中で興奮しすぎて何度も調査の手を止めたくなりましたが、なんとかまとめました：
✅ Skyworkが実装している5つの暗号技術カテゴリの全貌
✅ ゼロ知識証明・準同型暗号・時間ロック暗号の実装が本当に動いてる話
✅ 暗号おじさんが特に興奮した3つのポイント
✅ IETF標準化の文脈から見たこの実装の意義
✅ PQC（Post-Quantum Cryptography）への準備状況
想定読者:
- 暗号技術に興味がある人（数式は最小限にします）
- AIエージェントを使っていて「セキュリティ大丈夫？」と思ってる人
- IETF界隈の人（コメント欲しいです！）
なぜ今これが重要なのか
2025年現在、AIエージェントは単なるチャットボットから、実際の業務を自律的に処理する存在へと進化しています。しかし、「AIに機密データを扱わせて大丈夫なのか？」 という懸念は依然として残っています。
調査してわかったのは、Skyworkが以下のような暗号技術を実装していることでした：
- データを暗号化したまま計算できる準同型暗号
- 情報を開示せずに証明できるゼロ知識証明
- 指定時刻の前には数学的に絶対に開けない時間ロック暗号
これらを組み合わせることで、「AIが賢くなる」だけでなく「AIが信頼できる」世界を実現しようとしているのです。
Model Context Protocol (MCP) と暗号技術の相性
まず前提として、MCPについて簡単におさらいします。
MCPは、Anthropicが提唱したAIエージェントがツールを使うための標準プロトコルです。
なぜMCPが暗号技術と相性が良いのか
従来、AIに暗号技術を使わせるには以下の課題がありました：
- ❌ LLMに秘密鍵をそのまま渡すのは危険
- ❌ 複雑な暗号ライブラリをAIが直接操作するのは困難
- ❌ セキュリティポリシーの統一的な管理が難しい
MCPはこれらを解決します：
[AIエージェント]
↓ 自然言語で指示
↓ 「このデータを暗号化して」
[MCPサーバー]
↓ 標準化されたJSON-RPCプロトコル
[暗号ライブラリ（Node.js crypto等）]
↑
↑ 鍵管理はクライアント側
ポイント:
- AIは暗号化の「意図」だけを伝える
- 実際の暗号処理はMCPサーバーが担当
- 鍵は一切AIに渡さない
ワイの評価: これ、完全にSeparation of Concernsの正しい実装です。IETF的に言うと、アプリケーション層とセキュリティ層を綺麗に分離してる。美しい。
実装されている5つの暗号技術カテゴリ
Skyworkは以下の5つのカテゴリで暗号技術を提供しています。それぞれ、単なる理論ではなく実際に動くMCPサーバーとして実装されている点が画期的です。
1. Crypto MCP Server（古典暗号）
最初は「まあ、AESとSHA-256くらいでしょ」と思ってました。
実装内容:
// 提供される機能
- AES-256-CBC / AES-256-GCM
- DES（レガシー互換用）
- SHA-1, SHA-256, SHA-512
ワイのツッコミ:
DESを残してるのは互換性のためでしょうが、もう2025年なんでDESは本番環境で使っちゃダメですよ！（一応ドキュメントにも警告あり）
AES-GCMを選べるのは評価高いです。CBCモードは2025年的には微妙なので、基本的にはGCMモードを使いましょう。
2. ZKProof MCP Server（ゼロ知識証明）
ここから本番です。ゼロ知識証明は「情報を開示せずに、その情報が正しいことを証明する」技術です。
技術スタック:
- Circom: ゼロ知識証明回路を記述する言語
- snarkjs: zk-SNARK の実装ライブラリ
- Groth16: 証明システム（trusted setup 必要）
実用例1: 年齢確認
従来: 「20歳以上です」→ 免許証の画像を送る（生年月日が丸見え）
ZKP: 「20歳以上です」→ ゼロ知識証明を送る（生年月日は秘密のまま）
実用例2: 機械学習推論の検証
AIモデルの推論結果を証明
モデルの重みは秘密のまま
「このモデルで計算したら、確かにこの結果になる」を暗号的に証明
なぜ重要か:
GDPRやHIPAAなどの規制下では、個人データの最小化が求められます。ゼロ知識証明を使えば、必要最小限の情報のみを開示しながら、コンプライアンスを満たせます。
注目ポイント:
Groth16の trusted setup について調べていて、「なぜ複数の参加者が必要なのか」という点です。
要するに誰か一人でも正直な参加者がいれば、セットアップは安全という仕組み（1-out-of-N 誠実性）。逆に言うと、全員が共謀しない限り偽造できない。これ、暗号プロトコルとして本当によくできてる。
ワイの興奮ポイント:
IETFでも PPM（Privacy Preserving Measurement）Working Group で似たような話をしています。個人データを集約するときに、生データを収集せずに統計だけ取る技術です。
Skyworkの実装は、それをAIエージェントが使えるようにしたという点で画期的！
3. Shutter MCP Server（時間ロック暗号）
正直、これが一番興奮しました。
何ができるか:
指定した時刻まで、数学的に絶対に開けられない暗号化
仕組み:
1. 閾値暗号で鍵を複数のKeyperノードに分散
2. drand（分散型ランダムビーコン）で時刻を保証
3. 指定時刻になると、鍵シェアが自動公開
4. 閾値（例: 10個中7個）集まると復号可能
ワイのテンションが上がった理由:
これ、Timelock Encryption の実用実装ってことですね。
論文レベルでは知ってましたが、実際に動くシステムとして見たのは初めてです。しかも：
- drand: NIST Randomness Beaconプロジェクトと似た発想
- 閾値暗号: Shamir の秘密分散の応用
- 分散型信頼: 単一障害点なし
IRTFのCFRG（Crypto Forum Research Group） で議論されてるような最先端技術が、実装として動いてる...
冷や汗をかいた瞬間:
最初は「サーバーの時計を進めたら早く開けられるのでは？」と思いましたが、調べたら、drandは以下のような組織が運営してました：
- Cloudflare
- EPFL（スイス連邦工科大学）
- Protocol Labs
- etc...
これを全部同時に攻撃して時計を進めるのは、困難です。安心しました（笑）
ユースケースで震えた:
| 用途 | 従来 | 時間ロック暗号 |
|---|---|---|
| オンライン入札 | 最初の入札が見える（不公平） | 締切まで全て秘密 |
| 投票システム | 途中経過が見えると後の人が影響を受ける | 投票終了まで全結果が秘密 |
| 遺言執行 | 弁護士に依存 | 数学的に自動執行 |
| タイムカプセル | 物理的な保管が必要 | 暗号的に未来へ送信 |
これ、スマートコントラクトの next evolution ですねっ
4. DPO2U MCP Server（準同型暗号）
準同型暗号は、ワイ的には「理論はすごいけど実用は厳しい」と思われがちの分野です。
技術スタック:
- OpenFHE: 最新の FHE ライブラリ
- BGV, BFV, CKKS, TFHE: 各種スキーム対応
何ができるか（疑似コード）:
// 暗号化されたまま計算できる
Encrypt(30000) + Encrypt(50000) = Encrypt(80000)
Encrypt(10) × Encrypt(5) = Encrypt(50)
// 復号化せずに四則演算！
ワイの本音:
正直、パフォーマンスは厳しいです（イメージ）：
通常の加算: 0.000001秒
FHEの加算: 0.1秒（10万倍遅い）
FHEの乗算: 1秒（100万倍遅い）
ただし！OpenFHEは最適化が進んでいて、数年前と比べて100倍速くなってます。
実用的な使い方（疑似コード）:
# GDPR準拠の年収分析
# NG: 生データを復号化して分析（プライバシー侵害）
data = decrypt(customer_data) # ← ここで漏洩リスク
result = analyze(data)
# OK: 暗号化のまま分析（完全なプライバシー保護）
encrypted_data = customer_data # すでに暗号化済み
encrypted_result = analyze_homomorphic(encrypted_data)
result = decrypt(encrypted_result) # 結果だけ復号化
ワイの評価:
IETF の PPM WG や W3C の Private Aggregation API と方向性が完全に一致してます。
「データを集めずに分析する」というパラダイムシフト。これが実装レベルで動いてるのがすごい。
PQC対応状況の調査結果:
Skyworkは、NIST標準化アルゴリズムへの対応を進めてます：
| 用途 | NIST標準 | Skyworkの研究状況 |
|---|---|---|
| 鍵カプセル化 | MLKEM (Kyber) | ✅ 評価・実装準備中 |
| デジタル署名 | MLDSA (Dilithium) | ✅ 評価・実装準備中 |
| ハイブリッドTLS | ECDHE + MLKEM | ✅ 研究中 |
IETF的な文脈:
IETFでも TLS WG で PQC 対応が進んでいます：
- RFC 9180: Hybrid Public Key Encryption (HPKE)
- draft-ietf-tls-hybrid-design: Hybrid Key Exchange in TLS 1.3
Skyworkの方向性は、IETF標準化と完全に一致してます。
ワイの個人的見解:
量子計算機の脅威は「いつ来るか」じゃなくて、「今暗号化されたデータが将来解読される」 リスクです。
これを "Harvest Now, Decrypt Later" 攻撃と呼びます。
だから、PQCへの移行は「今」始めないとダメなんです。Skyworkがこれを理解して動いてるのは素晴らしい。
ハイブリッドアプローチの重要性:
TLS 1.3 (現在)
└─ ECDHE鍵交換
TLS 1.3 (将来のハイブリッド)
├─ ECDHE鍵交換（従来の安全性）
└─ Kyber鍵交換（量子耐性）
↑ 両方が破られない限り安全
このアプローチなら、もしPQCアルゴリズムに脆弱性が見つかっても、ECDHEが守ってくれます。逆も然り。
5. 高度な文書処理セキュリティ
最後は、実用的なセキュリティ実装です。
実装されている技術:
✅ AES-256-GCM（FIPS 140-2認証モジュール使用）
✅ TLS 1.3（0-RTTは無効化推奨）
✅ 形式保持暗号化（FPE: FF1/FF3モード）
✅ エンベロープ暗号化
✅ HSM（Hardware Security Module）連携
ワイのツッコミ:
FPE（Format-Preserving Encryption）、ちゃんと NIST SP 800-38G 準拠の FF1/FF3 使ってますね。これは評価高い。
よくある間違い実装:
// ❌ ダメな例: 単にBase64エンコードしただけ
"1234-5678-9012-3456" → "MTIzNC01Njc4LTkwMTItMzQ1Ng=="
// ✅ 正しい例: FPE (FF1) を使用
"1234-5678-9012-3456" → "8765-4321-0987-6543"
↑ フォーマットを保持
FPEの良さは、既存システムを変更せずに暗号化できる点です。
例えば：
- クレジットカード番号（16桁の数字）
- 電話番号（10桁の数字）
- 社員番号（8桁の英数字）
これらを暗号化しても、フォーマットは変わらないので、データベースのスキーマ変更不要。
エンベロープ暗号化の実装:
データ暗号化鍵（DEK）
↓ データを暗号化
↓
暗号化されたデータ
+
鍵暗号化鍵（KEK）
↓ DEKを暗号化
↓
暗号化されたDEK（HSM/KMSで保護）
このアプローチの利点：
- DEKのローテーションが容易
- KEKはHSMで厳重に保護
- 大量のデータを効率的に暗号化
ワイが特に興奮した3つのポイント
1. 「分散型信頼」の実装が本物
従来の暗号システム:
[ユーザー] → [CA/KMS] → [検証]
↑
Single Point of Trust
Skyworkのアプローチ:
[ユーザー] → [複数の独立したKeyper] → [閾値検証]
↑
No Single Point of Failure
IETF的な文脈:
これ、Multi-Stakeholder Trust Model の実装例です。
IETFの ACME WG（Let's Encrypt のプロトコル）や TRANS WG（Certificate Transparency）でも、単一のCAに依存しない仕組みを模索してます。
Skyworkは、それを閾値暗号で実現してる。
具体例：時間ロック暗号の分散信頼
Keyperノード構成（例）:
- 15個のノード
- 閾値: 10個
- 地理的分散: 5大陸
- 運営組織: 独立した15団体
→ 10個のノードが共謀しない限り、早期開封は不可能
これ、地政学的リスクにも強いんですよね。特定の国・地域に依存しない。
2. 「数学的保証」へのこだわり
多くのシステムは「正しく実装されていると信じる」ことに依存してます。
Skyworkは違います：
| 技術 | 保証の種類 | 具体例 |
|---|---|---|
| ゼロ知識証明 | 数学的に検証可能 | 証明者が嘘をついても、検証で必ず検出される |
| 時間ロック暗号 | 物理的に操作不可能 | 閾値を満たさない限り、計算量的に復号不可 |
| 準同型暗号 | 理論的に情報漏洩なし | 暗号文から平文の情報は一切得られない |
ワイの気持ち:
これは "Don't trust, Verify" の精神です。
ビットコインやイーサリアムで言われる概念ですが、Skyworkはこれを暗号技術全般に適用してる。
従来のアプローチとの比較:
【従来】
「このシステムは安全です」
→ 「実装を信じてください」
→ 監査で確認（コストが高い）
【Skywork】
「このシステムは安全です」
→ 「数学的証明があります」
→ 誰でもいつでも検証可能（コスト低い）
3. IETF標準化との整合性
調査してて驚いたのは、SkyworkのアプローチがIETF標準化の方向性と完全に一致してることです：
| Skyworkの実装 | 対応するIETF活動 | RFC/Draft |
|---|---|---|
| PQC対応 | TLS WG, CFRG | RFC 9180, draft-ietf-tls-hybrid-design |
| プライバシー保護計算 | PPM WG | draft-ietf-ppm-dap |
| 分散型信頼 | TRANS WG, ACME WG | RFC 6962, RFC 8555 |
| TLS 1.3使用 | TLS WG | RFC 8446 |
| HPKE実装の準備 | CFRG | RFC 9180 |
これ、偶然じゃないと思います。確実に標準化動向を追ってる。
IETF 124（Montreal）での議論との関連:
最近参加した IETF 124 で、以下のような議論がありました：
- TLS WG: PQC ハイブリッド鍵交換の実装ガイドライン
- CFRG: MLKEM/MLDSA の性能評価とベストプラクティス
- PPM WG: 分散集計プロトコルの新提案
Skyworkの実装は、これらの議論の実証例（proof of concept） として見ることができます。
個人的な考察:
もしかして、Skyworkの中の人、IETF参加者じゃないですか...？（勝手な推測）
少なくとも、標準化文書をちゃんと読んで実装してるのは間違いないです。
技術的課題とワイの評価
現実的な課題
完璧に見えますが、正直に言うと課題もあります：
1. パフォーマンス問題
ベンチマーク結果（概算）:
- 通常の計算: 1 ms
- ゼロ知識証明生成: 1,000 ms（1000倍遅い）
- 準同型暗号計算: 10,000 ms（10000倍遅い）
リアルタイム処理が必要な用途には厳しい。
ただし！
5年前と比べると、準同型暗号は100倍速くなってます。Moore's Law ならぬ "FHE Performance Law" が働いてる気がします（笑）
現実的な使い分け:
リアルタイム処理:
└─ 古典暗号（AES-GCM, SHA-256）
バッチ処理（夜間実行）:
└─ 準同型暗号、ゼロ知識証明
特定イベント（入札締切等）:
└─ 時間ロック暗号
適材適所で使えば、十分実用的です。
2. 実装の複雑性
Circom でゼロ知識証明回路を書くのは、正直ハードルが高い：
// 年齢確認の回路（簡略版）
template AgeCheck() {
signal input birthYear;
signal input currentYear;
signal output isAdult;
signal age;
age <== currentYear - birthYear;
component gte = GreaterEqThan(8); // 8 bit 比較
gte.in[0] <== age;
gte.in[1] <== 18;
isAdult <== gte.out;
}
通常のプログラミングとは全く違います。
学習曲線:
普通のJavaScript: 1週間で書ける
Circom: 1ヶ月は必要
複雑な証明回路: 数ヶ月かかる
ただし、MCPサーバーとして提供されているので、使う分にはそこまで難しくないです。
Circomを書くのは「ライブラリ開発者」の仕事で、「利用者」はMCPサーバーを叩くだけ。
3. Trusted Setup の管理
Groth16 zk-SNARK は、trusted setup ceremony が必要です。
これを適切に管理しないと、セキュリティが破綻します。
ワイの推奨:
複数の独立した参加者（できれば10人以上）で ceremony を実施すること。
参考:
- Zcash の Powers of Tau ceremony（200人以上が参加）
- Ethereum の KZG ceremony（14万人以上が参加）
代替案:
最近は、trusted setupが不要な証明システムもあります：
- PLONK: Universal setup（回路ごとにsetup不要）
- STARKs: Setup完全不要（ただし証明サイズが大きい）
将来的には、これらへの対応も期待したいですね。
参考資料
Skywork公式の技術記事（必読）
-
Crypto MCP Server
- A Deep Dive into the Crypto MCP Server by Cloris
- 基本的な暗号機能の実装詳細
-
ZKProof MCP Server
-
Shutter MCP Server
-
DPO2U MCP Server
-
AI Document Processing Security
- 2025 Best Practices: Securing AI Document Processing for PII/PHI
- 文書処理のセキュリティベストプラクティス
免責事項:
本記事は個人の調査に基づく技術解説であり、Skywork.ai社の公式見解ではありません。実装の詳細や最新情報は、公式ドキュメントをご確認ください。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。