数学研究者・今村がConfidential Computingに挑む中で見えた、Attestationの奥深さ

公開日：2026.10.14

Ryo Tatsuishi Senior Talent Aquisition

会社全体の組織づくり、採用を担当

Confidential Computing（以下CC）領域に未経験から取り組み、「Confidential VM」の実用化に挑んでいる今村さん。数学博士から研究者のキャリアを経て入社した今村さんに、この領域ならではの魅力を端的に語ってもらいました。

【プロフィール】

今村拓万（Takuma Imamura）：CC Lab リサーチャー

京都大学大学院数理解析専攻博士後期課程を修了後、京都大学数理解析研究所などで研究活動に従事。専門領域は、無限小や無限大のような理想的対象を駆使する「超準解析（ちょうじゅんかいせき）」、代数トポロジー、科学哲学など。2025年、AcompanyにR&Dエンジニアとして参画し、CCの研究開発に従事。現在、CC Lab リサーチャーとして、Confidential VMを中心としたTEEのAttestation（構成証明）基盤の構築、Attestation関連のOSS開発、最先端のTEEハードウェアを活用したベアメタルCC環境の整備、CCにおける安全性の原理的限界を克服する研究を主導。本業の傍ら、プライベートでも数学の研究活動を続けている。

数学博士から研究、Acompanyへ

ーまずは今村さんのバックグラウンドについて教えてください。数学博士取得後、研究者としてのキャリアを歩まれていたと伺いました。具体的にどのようなテーマを研究されていたのでしょうか？

今村： 大学の博士課程では「超準解析（ちょうじゅんかいせき）」という分野を専門にしていました。それと並行して、代数トポロジーや粗幾何学、科学哲学の研究など、かなり幅広い領域に触れていました。

一言で説明するのは難しいのですが、高校の数学で習う「極限」や「微分積分」をイメージしてもらうと分かりやすいかもしれません。高校数学では「無限に近づける」といった、直感的には分かっても少し曖昧な説明で終わることが多いです。大学の数学科に入ると、それを厳密に定義し直します。現代の標準的な定義では、18世紀の解析学では普通に使われていた「無限小」や「無限大」といった直感的な概念は、論理の言葉に置き換えられ、直接的には現れなくなります。

「昔の数学者が直感的に使っていた『無限小』という概念を、現代数学の厳密さの基準で直接扱えるようにできないか」という問題意識から生まれたのが超準解析です。この分野では、無限を普通の数と同じように厳密に取り扱うことができます。私はその枠組みを使って、隣接する代数トポロジーなどの分野へ応用する研究を突き詰めていました。博士を取得した後の1年目も、数理解析研究所というところでポスドクとして同じ研究を継続していました。数学の基礎的な部分を深く突き詰めるキャリアを送っていました。

ー純粋数学の研究者というキャリアから、なぜスタートアップであるAcompanyへの入社を決められたのでしょうか？

今村： 最大の理由は、Acompanyのバリューの中に「Be Cool.」というものがあり、その中で「邪悪な行動や手段をとる人は、どれだけ優秀であっても絶対に採用しない」と明言されていたことです。

世の中にはさまざまな会社がありますが、ここまで明確に「邪悪な人を採らない」とオープンにしている会社は少ないと思います。どれだけロジカルで言っていることが正しくても、相手の心を締め付けるような人がいる環境は良くないですし、エンジニアやリサーチャーの創造性を奪ってしまいます。私も同じような感覚を大事にしていたので、このカルチャーを初めて見たときに強く惹かれました。

とはいえ、実際の業務内容への手応えもありました。カジュアル面談でマニアックな技術の解説をしてもらったのですが、TEE（Trusted Execution Environment：信頼された実行環境）やRemote Attestation（構成証明）の概要を聞いたときに、仕組みや構造がなんとなく頭の中で繋がりました。考え方の抽象レイヤー自体は、公開鍵暗号や電子署名を組み合わせた非常にシンプルなものです。個人的に使っていたクラウドストレージの暗号化プロトコルを調べたことがあったのですが、その時の思考プロセスと地続きだなと感じました。「自分の経験を活かせる部分がありそう」という手触り感を持てたことも、入社を決める大きな後押しになりました。

ー実際に入社してからは、どのようなタスクに取り組んできたのでしょうか？

今村： 入社直後から現在に至るまでの約1年間、CC領域のインフラとソフトウェアスタックの構築にどっぷりと浸かっています。

具体的には、Intelの「SGX」「TDX」やAMDの「SEV-SNP」、AWSの「Nitro Enclaves」（TEEに類似した隔離環境技術）など、主要なTEEテクノロジーのAttestationまわりの検証を幅広く手掛けました。

GitHub - acompany-develop/Humane-RAFW-NE: Remote Attestation Framework for AWS Nitro Enclaves

Remote Attestation Framework for AWS Nitro Enclaves - acompany-develop/Humane-RAFW-NE

GitHub

Nitro Enclavesに関しては、Attestationを最初から最後まで自動で実行してくれるオープンソースソフトウェア（OSS）を自社で開発し、一般に公開するところまでやりました。また、AMD SEV-SNPについても、Remote Attestationを扱うPythonライブラリ「py-snp-utils」を開発しています。

GitHub - acompany-develop/py-snp-utils: Python libraries for parsing SNP reports, fetching VCEK cert chains, and verifying them

Python libraries for parsing SNP reports, fetching VCEK cert chains, and verifying them - acompany-develop/py-snp-utils

GitHub

直近では、Attestationの仕組みの中でより本質的な課題解決のための研究や論文執筆に取り組んでいます。それと並行して、社内の検証用ベアメタルサーバーをセットアップし、AMDのSEV-SNPやIntelのTDXといった最新のハードウェア機能を有効化するインフラ整備も行っています。最新世代のハードウェアを物理レベルから直接触り、実験環境を構築できるのは非常に面白いですが、常に何かしらのバグや仕様の壁にぶつかり続ける日々でもあります。

Confidential VMやAttestationに取り組む中で

ー今村さんが取り組んだ「Confidential VM」について、教えてください。

今村： 一言で言えば、「ホストOSやハイパーバイザーからすらも、メモリの中身を絶対に覗くことができない仮想マシン（VM）」です。

通常のクラウド環境では、仮想マシンを動かしているインフラの管理者や、物理サーバーのホストOSに特権を持つユーザーであれば、理屈のうえではゲストVMのメモリ空間を覗き見ることができてしまいます。Confidential VMは、CPUハードウェアレベルでの暗号化によってこれを不可能にします。つまり、「クラウドベンダーすら信用できない、あるいは情報を一切渡したくない」という極めて高いセキュリティ要件において、安全にパブリッククラウドを利用するために必須となる技術です。

「自社でサーバーを持ってプライベートクラウドを作ればいいのでは？」と思うかもしれません。しかし、インフラを自前で運用するリソースがない企業でもパブリッククラウドの恩恵を受けられるのが強みです。さらに言えば、インフラの内部犯行や、ホストマシンがクラッカー / 攻撃者に不正アクセスされた場合でも、その上で動くConfidential VMの内部までは汚染されません。「組織が鍵を管理する金庫の中に、さらにもう一つユーザーが鍵を管理する金庫を置く」ようなイメージです。たとえ金庫が破られても、その中にある金庫は破れません。医療データや防衛関連など、機密性の高いデータを扱う領域で今まさに強く求められている技術です。

ー Confidential VMを実用化する上で、なぜ「Attestation」というプロセスが重要になるのでしょうか？

今村： クラウドベンダーから「これは安全なConfidential VMです」と提供されても、それが本当にハードウェアレベルで保護されているか、外側から検証できなければ意味がないからです。

もし検証する方法がなければ、結局は「提供しているクラウドベンダーを信用する」という従来通りの話になってしまい、CCを使う意味が失われてしまいます。契約で縛ったとしても、悪意の有無に関わらず実装ミスや「外部からの不正アクセス」によるデータ漏洩は防げません。だからこそ、暗号学的・ハードウェア的なアプローチで客観的に安全性を検証する「Attestation」が必要不可欠です。

TEEのハードウェアやファームウェアには、自身の状態や身分を証明する署名付きの「Attestationレポート」を発行する機能が標準で備わっています。これをエンドユーザーに渡し、検証者が署名とレポートの中身を厳密にチェックするのが基本戦略です。しかし、この「基本戦略」を実際のシステムへ組み込もうとすると、机上の検討だけでは見えてこない無数の落とし穴とバグが出てきます。

ーミッションを遂行する上で、具体的にどのような課題があり、どう解決していったのでしょうか？

今村： いくつかの原理的な問題が知られているのですが、それ以前の実装面において、世の中に出回っているソフトウェアスタックが「まともに動かない」という問題がたくさんありました。結果として、この1年間で出したプルリクエストは100個を超えています。

特に苦戦した思い出深い課題として、Linuxの「IMA（Integrity Measurement Architecture）」というカーネル機能の制御が挙げられます。IMAは、OS内で起動・ロードされるアプリケーションやファイルのハッシュ値を逐時計測し、改ざんがないかをログに記録する機能です。このログの改ざんを防ぐために、vTPM（Virtual Trusted Platform Module）」という暗号処理モジュールのレジスタにハッシュチェーンを記録していくのですが、Confidential VMのAttestationを行うには、このTPMを操作するツール群と連携しなければなりません。

しかし、TPM・CVMのAttestationのツールやライブラリに多くのバグが見つかりました。あるツールを使ってAttestationレポートを発行・検証すると、なぜか成功したり失敗したりする謎の現象が起きました。レポートのバイナリを直接覗いてみると、特定のフィールドのバイト順がシャッフルされて出力されているという、低レイヤーのバグが潜んでいたこともあります。こうしたツール群のソースコードを延々と読み解き、本家へ脆弱性報告や修正のプルリクを爆撃のように送り続けることで、ようやく最初から最後までのフローを完璧に通すことができました。

「手順書が存在しない」世界：低レイヤー開発のリアルな難しさ

ー Attestationの実装において、最も難しいポイントはどこにあるのでしょうか？

今村： 最大の壁は、「公式の手順書が間違っている」、あるいは「そもそも手順自体が存在しない」という点です。

開発の流れは、まず仕様通りにAttestationを実装しようとベンダーのドキュメントを読みます。しかし、その手順通りに動かすだけでは上手くいかないことが普通です。ドキュメントの記述自体が間違っているからです。使っているツールのソースコードを直接読み始めると、ドキュメントに書かれているAPIと実際のコードのAPIが全く異なっている、といった問題が見つかることもあります。

この領域（CC）の低レイヤーを実際に触って開発している人間が世界的に見ても極めて少ないため、リファレンスとなる知見がネット上に転がっていません。さらに、大手ベンダーが提供しているツールであっても、十分なサポートやメンテナンスがされていないケースもあります。関わってくるアクターが多すぎることも難易度を上げています。

CPUベンダー、GPUベンダー、マザーボードの製造元、OSベンダー、そしてその上で動くミドルウェアのベンダー。これら膨大な利害関係者がそれぞれのレイヤーで正しく実装し、協力し合わなければAttestationは完成しません。どこか一つのベンダーが予告なく「破壊的変更」を加えると、サードパーティーのOSS側への情報共有に数ヶ月のラグが発生し、その間に私たちのシステムもドミノ倒し的に動かなくなります。この絡み合った糸を一本ずつ解きほぐしていく作業が必要になります。こうしたTEE関連OSSの開発やコントリビューションの中で直面した課題については、[The Darkside of TEE OSS]でも詳しく紹介しています。

Attestationの2つの基本問題に挑む

ー CC LabではAttestationの基礎的な研究もしていると聞きましたが、その内容について差し支えない範囲で教えてください。

今村： 1つ目は、「開示できないアプリケーションコードの安全性を、どう担保するか」という一般的なSaaSモデルにおける基本問題の解決です。

Attestationレポートには、TEE内で動いているアプリケーションの「ハッシュ値」が含まれます。したがって、Remote Attestationを行うことで、TEE内でどのようなハッシュ値を持つアプリケーションが動作しているかを検証できます。しかし、アプリケーションのハッシュ値が分かったところで、その元となるコードがプロプライエタリ（非公開）であれば、中にバックドア（不正アクセスの抜け穴）が仕掛けられているリスクを排除できません。

Confidential VMも通常のVMと同様、データを外部送信することが可能です。そのため、クライアントから受信した機密データを攻撃者に横流しするような、悪意あるアプリケーションを動作させることも容易にできてしまいます。本当に安全性を検証するなら、ベンダー側がすべてのコードを開示し、ユーザーが悪意あるコードが含まれていないかを監査した上で、コードからビルドしたバイナリのハッシュ値と突き合わせる必要がありますが、ビジネス上コードの全面開示なんて不可能です。

この「コードは開示できないが、ハッシュ値以上の安全性を原理的に証明したい」というジレンマに対し、いくつかのTEEをうまく組み合わせることで、コードを隠したまま解決する「Attestable Audit」を提案しました。具体的にはTEEの中でビルドとコード監査を行うことで、コードを隠したままハッシュ値とコードプロパティの対応関係を暗号論的に証明するという手法です。

この研究成果は、2026年10月31日にギリシャ・アテネで開催される国際ワークショップ「Hardware and Architectural Support for Security and Privacy (HASP 2026)」に採択されました。

2つ目は、「分散型コンピューティングにおける相互Attestationの無限後退」の解決です。

通常の「クライアントがサーバーを検証する」という一方向の構図ではなく、Web3や分散システムのように「CC環境同士がお互いを信頼できるか検証し合う」という状況を考えます。

このとき、双方が「相手のハッシュ値がこれなら許可する」というホワイトリストを持つ必要があります。しかし、お互いのコードの中にお互いのハッシュ値をハードコーディングしようとすると、片方を修正すればもう片方のハッシュ値が変わり……という形で、鶏と卵のような無限後退に陥ってしまいます。この構造的な問題を、一見縁遠いようにも思える数学の古典的な定理を使って解決するアプローチを提案しました。

AcompanyでAttestationに取り組む面白さ

ーバグが多く泥臭い低レイヤー開発の中で、今村さんが感じる「楽しさ」はどこにあるのでしょうか？

今村： 単に特定ベンダーの製品マニュアルに従って動かすだけなら、そこに研究者としての面白みはありません。私が面白いと感じるのは、特定のTEEに依存しない「CC一般に共通する、一段階抽象度の高い問題」に出会え、それを追求できる点です。

技術の中には、10年後には消えているかもしれないものもたくさんあります。実際、かつてコンシューマ向けIntel CPUに搭載されていたクライアントSGXは、第11世代以降のCPUでは廃止され、そのAttestationに用いるEPID RAも2025年に廃止されました（※）。そうした個別の技術仕様を追いかけるだけでなく、CC領域の全体に通底する本質的な課題を切り出し、解決策を提示することには大きな意義を感じます。

※参考：https://community.intel.com/t5/Intel-Software-Guard-Extensions/IAS-End-of-Life-Announcement/td-p/1545831

感覚としては、かつてインターネットの通信が「HTTP」から暗号化された「HTTPS」へ大転換したときの、安全なプロトコル（TLS）を自分たちの手で作り上げている感覚に近いです。CCという次世代のスタンダードを真に安全に使うためのプロトコルがRemote Attestationであり、その理論的な基盤やインフラを自分たちで構築できるところに、この仕事の面白さがあります。誰も開けたがらないニッチで難解な問題だからこそ、やり切る価値がありますし、世界中で誰も解いていない問題を自分の手で解き明かす瞬間の快感は、何物にも代えがたいものがあります。

ー最後に、Acompanyという環境だからこそ得られていると感じる魅力について教えてください。

今村： スタートアップという規模でありながら、CC領域の基礎的な研究開発に投資し、論文を執筆して外部へ発信できる環境を提供している会社は珍しいと思います。大学の研究室、政府系研究機関、ごく一部の企業内研究所を除けば、まず出会えないフィールドです。

最新のTEE機能を持つベアメタルサーバーを直接いじり倒せる環境も、国内ではなかなかないはずです。また、延々と動かないベアメタルサーバーやバグだらけのOSSと向き合うのは精神的に大変な時もあります。そんな時「研究（論文執筆）」の時間があることで、脳の別の領域を使う良い息抜きになっています。

社内には、技術的にも人間的にも純粋にリスペクトできる面白いメンバーが集まっています。「邪悪な人を採用しない」というカルチャーが徹底されているおかげで、理不尽なマイクロマネジメントや、矛盾した指示でメンバーを縛るような人が一人もいません。過度なストレスがなく、お互いの信頼関係が前提にあるため、高い自己判断の裁量を持って業務を進めることができます。低レイヤーの混沌に挑むのは決して楽な道ではありませんが、純粋に技術と向き合い、自らの手で世界のインフラを一段安全に変えていきたいという熱量を持ったエンジニアにとって、Acompanyはエキサイティングで、かつ心理的に守られた最高の遊び場だと思います。