技術で信頼の境界を再定義する。プロダクトCTOが語る、Confidential AI Suiteの挑戦

「AIを活用して生産性を向上させたい」という強い欲求と「機密情報漏洩やAI固有の脆弱性を防ぎたい」という厳格なガバナンス。大企業をはじめとする多くの組織において、この「攻め」と「守り」の葛藤は、AIの社会実装の障壁となっています。このジレンマを解消すべく立ち上げたのが、Acompanyの「秘密を守れる」AI製品群『Confidential AI Suite』です。

今回は、プロダクトCTOである田中さんに、『Confidential AI Suite』誕生の背景や解決すべき課題について聞きました。

【プロフィール】

田中 来樹（Raiki Tanaka）：プロダクトCTO

名古屋大学でコンピュータサイエンスを専攻。学生時代は競技プログラミングや受託開発に取り組み、大学3年時に学生起業し創業者兼CTOとして技術・事業戦略を主導。その後Acompanyに参画し、マルチパーティ計算（MPC）のOSS『QuickMPC』の開発をリード。データクリーンルームの立ち上げから商用化まで、インフラ・SRE・技術リサーチを横断して推進。現在はプロダクトCTOとして、Confidential Computing（以下、CC）をAIワークロードへ適用する『Confidential AI Suite』の技術統括およびプロダクト戦略全般を担っています。

研究・OSS開発から商用化へ——技術を愚直に「社会実装」し続けた歩み

ー 田中さんが学生起業後にAcompanyに参画し、どんなことに取り組んできたか教えてください。

田中：当時Acompany CEOの高橋さんに誘われインターンとして参画し、複数組織がデータを相互に秘匿したまま計算を行う「MPC（マルチパーティ計算）」の研究開発に着手しました。当時は実用的なオープンソースソフトウェア（OSS）が世界的に見ても乏しかったため、まずは『QuickMPC』というOSSの開発をリードすることからスタートしました。

そこから一貫して掲げているテーマが「プライバシー保護技術を研究で終わらせず、社会実装する」ということです。MPCの次はデータクリーンルームの立ち上げから商用化までを担当し、インフラ、SRE、技術リサーチを横断して手掛けました。現在はプロダクトCTOとして、CCをAIワークロードへ適用する『Confidential AI Suite』の技術総括およびプロダクト戦略全般を担っています。

ー どんな経緯で『Confidential AI Suite』開発につながったのか、『Confidential AI Suite』以前の開発について教えてください。

田中：Acompanyが最初に取り組んでいたのは、ブロックチェーンです。当時想定していたパブリックな分散台帳では、機密情報をそのまま載せられません。改ざんしにくい台帳を事業化しようとするなかで、この制約を越える技術として見つけたのがMPCでした。

MPCは、入力を単体では意味を成さない「シェア」に分割し、複数のサーバーが協調して計算する技術です。中央のサーバーへ秘密を預けず、元データを復元しないまま計算結果だけを得られます。当時は世界的にも担い手が少なく、私たちはここに挑戦しました。

この技術が活きる領域として行き着いたのが、データクリーンルームです。複数社がそれぞれ保有するデータを、互いに生データを渡さずに照合・分析する環境で、デジタルマーケティングなどのデータコラボレーションで求められます。

背景には、データを組み合わせれば新たな分析や顧客理解ができる一方、個人データの第三者提供には同意取得や利用目的の制約が伴うという現実があります。生データを安易に渡せば、法令上だけでなく、本人の期待を外した利用によるレピュテーションリスクにもつながります。

私たちは、法務・プライバシーの専門家と検討したデータ取扱いのスキームを、CC上の処理と入出力制御としてプロダクトに実装しました。データを扱う各社が生データを見渡せない状態で処理し、特定の個人を識別できない形にして扱う。こうした仕組みにより、法務・プライバシーの要件を踏まえたデータ連携を設計・実装できるようにしています。

ー その中でどんな課題があり、解決していったのでしょうか？

MPCには、複数のサーバー間で何度も通信しながら計算するため、通常の処理に比べて大幅に時間がかかってしまうという欠点がありました。そのため、大規模なデータ分析やAIワークロードを現実的な時間で動かすことが困難でした。

そこで、データクリーンルームの実行基盤はTEE（Trusted Execution Environment：隔離された実行環境）へと重心を移しました。事業特性上、ステークホルダー間で合意した分析ロジックだけが実行されることが重要です。そのため、TCB（Trusted Computing Base：正しく動くと信頼せざるを得ない構成要素の範囲）を小さく保てるプロセス保護型TEEであるIntel SGXを選定しました。

もっとも、初期世代のIntel SGXには強い技術制約がありました。利用できるメモリは約96MBに限られ、大規模データは小さな単位に分けて処理する必要がありました。加えてOSやカーネル、ハイパーバイザーすらも信頼しないという強い脅威モデルを前提に設計されているため、Linuxアプリケーションをそのまま動かせません。結果として、分析ロジックごとにメモリ制約を踏まえつつ、実用的な速度で処理可能なロジックを考え、フルスクラッチで低レベルな実装をすることになります。これは非常に開発・保守の負荷が大きく、データクリーンルームを広く使える形にするうえでの壁でした。

状況を変えたのは、ハードウェアと周辺ソフトウェアスタックの進化です。利用可能なメモリは最大512GBまで広がり、大規模データを一つの隔離環境で扱いやすくなりました。さらにLibrary OSのGramineにより、既存のLinuxアプリケーションも比較的小さいTCBを維持したまま実行できるようになりました。

さらに、分析ロジックの実装ハードルを下げる仕組みとして、実行基盤をFaaSとして抽象化する仕組みを開発しました。これにより、Pythonで分析ロジックを書いてデプロイ、実行できるようになり、大規模なデータを扱う処理でも、一般のデータエンジニアがロジックを実装し、隔離環境で動かせるようになったのです。

このFaaS型の実行基盤は、Intel社の米国研究開発チームとの共著論文として公開しています。

初期のIntel SGXに向き合った実装上の試行錯誤は、AcompanyのTEEエキスパート・櫻井さんによる記事[なぜSGXに呪われたか]でも紹介しています。

この状況からその後、NVIDIAが2023年にCC対応GPU「H100」を市場に投入したことで、LLMのような大規模AI処理を安全な環境で動かすための条件が整い始めました（※）

Big Tech企業が実例を示し始めた今、すでにCCが実用レベルであることは証明されています。一般の開発者・企業にもこの技術を届けるには、まず具体的な業務ユースケースを示していく必要がありました。そこでSecure Chatを起点に、Confidential AI Suiteへと展開していきました。

※CCのマーケット変化については、[Confidential AIはコンピューターサイエンスの「総合格闘技」 ──Acompanyが描く、R&Dの姿と展望【高橋亮祐×髙橋翼】]を参考に

単発のセキュリティアプリにとどまらない。Confidential AI Suite誕生の背景

ー『Confidential AI Suite』とはどのようなプロダクトなのでしょうか。

田中：企業が機密情報を保護しながら、日常業務でAIを最大限に活用できるようにするための製品群です。

私たちがデータクリーンルームの裏側で磨いてきたのは、任意のスクリプトやアプリケーションを、利用者がCCの難しさを意識せずに機密実行環境へ載せられるマネージドインフラです。データクリーンルームは、そのインフラを活用するユースケースの一つとして位置づけていました。

将来的には、この基盤をプロダクトとしてより幅広い業務に提供していきたいと考えていました。ただ、CCという低レイヤー技術が現場の業務で何を可能にするのかを、分かりやすく示す実例はまだ少なかった。そこで最初のユースケースとして選んだのが『Acompany セキュアチャット』でした。

しかし、企業のAI活用はチャットだけに留まりません。コードの生成・補完、調査、文書作成、AIエージェントによる業務実行へと、AIが使われる場面は広がっています。用途ごとに、求められる体験や、守るべきデータ・権限・実行環境は異なります。だからこそ、チャット、コーディング、業務エージェントなど、それぞれの用途へカバレッジを広げ、安全なAI活用体験を提供するアプリケーション群として『Confidential AI Suite』を構想しました。

※Confidential AI Suiteの製品群と発表内容の詳細は、こちらをご覧ください。

Acompany、安全で秘密を守れるAI製品ブランド「Confidential AI Suite」を発表  | 株式会社Acompany

第一弾製品として、生成AIへの機密データ入力禁止問題を解決する『Acompany セキュアチャット』の提供を開始株式会社Acompany（アカンパニー、愛知県名古屋市西区、代表取締役CEO 高橋亮祐、... 

株式会社Acompany | あらゆるデータとAI活用に、信頼を

ー プロダクトの開発にあたり、どのような顧客課題があったのでしょうか？

田中：特に大企業において、AIで生産性を上げたい「攻め」と、情報漏洩やAI固有の脅威を抑えたい「守り」が衝突しがちです。リスクを恐れるあまり「機密情報の入力禁止」といった厳しい制約を課すと、AIの真価が発揮されません。一方で、ルールだけで縛ろうとすると、社員が個人契約のAIサービスに秘密データを投入してしまう「シャドーAI」が発生し、ガバナンスが形骸化します。

この「攻めと守り」の葛藤は、AIの役割がチャットからエージェントへ広がるほど、飛躍的に難しくなります。AIがメールやドキュメントを読み、SaaSや社内システムを操作し、コードや設定を変更するようになると、便利さの延長で事故の形が変わるからです。

例えば、外部文書に埋め込まれた命令を、エージェントが業務指示だと誤解する。広い権限を持つ共有APIキーによって、依頼者本人には許されない操作まで実行する。AIが提案したパッケージやクラウド設定を、十分に検証しないまま採用する。AIが与えられた情報と権限を組み合わせて操作できる環境では、こうしたことが起こり得ます。

こうしたリスクは、すでに現実のものになっています。国内他社事例として、AIの提案を過信してOSの保護機能を無効化してしまったこと、DBアクセス可能なAIエージェント設定を誤り、本来は管理者承認が必要な情報を広く閲覧可能にしてしまったこと、機密画像を外部の共有サイトへアップロードしたことなどが実際にあったヒヤリハットとして紹介されていました。

ー こうした脅威に対して、Confidential AI Suiteはどのような価値を提供できるのでしょうか？

田中：例えばAIエージェントを業務で動かす場面では、ハーネス（指示やツール呼び出しを制御する実行の枠組み）を含むアプリケーション層と、それを支えるインフラ層に分けて考えて脅威シナリオを考える必要があります。利用者の注意やモデルへの指示だけで対処するのではなく、この二つの層を一体で守れるように設計することが重要です。

アプリケーション層では、ハーネスとして、ガードレール、プロンプトインジェクション検知などの分類器、命令とデータを分離する構造化した指示、ツール実行承認などを組み合わせて、入力を守ります。ただしハーネス自体が攻撃を受ける側でもあるので、ここだけには頼りません。

インフラ層では、依頼者本人の権限の範囲に絞った委任、通信先の制御、認証情報埋め込み、監査などをAgent Gatewayとしてハーネスの外側で強制します。エージェント実行環境では、CC、セッション隔離、認証情報隔離、などを組み合わせ、データと認証情報を守る境界をつくります。

私たちの強みは、AIを安全に業務で活用するために、入力・権限・実行環境までを一体で設計し、実際に使える製品として提供できることです。

その考え方を形にしたのが、Confidential AI Suiteの一つである『Acompany AIスタジオ』です。

AI活用の推進と守りをオールインワンで実現する、エンタープライズ向けAIエージェント基盤「Acompany AIスタジオ」β版提供開始  | 株式会社Acompany

株式会社Acompany（アカンパニー、愛知県名古屋市中区、代表取締役CEO 高橋亮祐、以下Acompany）は、Confidential AI（機密AI）技術を核とするAI製品ブランド「Confid... 

株式会社Acompany | あらゆるデータとAI活用に、信頼を

AIそのものを守る「Security for AI」の仕組みを、エージェントを構築・利用する環境にあらかじめ組み込むことで、利用者が安全対策を都度意識しなくても使える体験を目指しています。

非エンジニアを含む誰でも5分以内にエージェントを構築でき、作成したエージェントはSlackから呼び出すこともできます。また、うまくいった業務手順は、再利用可能な手順定義である「スキル」として組織内で共有できます。

エージェントは業務PCごとの環境ではなく、管理されたリモート実行環境で動きます。PCの設定差による属人化を減らし、管理者が指定したランタイムを組織で統一して使えるようにするためです。継続実行にも対応でき、PCを閉じた後も処理を止めません。

管理者は、監査ログ、通信先のポリシー、利用できるMCP（Model Context Protocol）コネクタをテナント全体で統制できます。利用者が個別にコネクタをインストール・設定しなくても、安全な範囲で必要なツールを使えるようにするためです。

一方で、AIエージェントの脅威は、まだ社会全体で十分に整理・標準化されていません。新しいモデル、ツール、連携方法が出るたびに、何が起こり得るかを洗い出し、脅威モデリングし、対策を設計・運用し続ける必要があります。

私たちは、自社でもAIエージェントを業務で広く利用しています。実際に使うなかで見える脅威や運用上の課題を継続的に観測し、公開される事例・研究も踏まえて脅威モデルを更新しています。机上で一度設計して終わりではなく、変化する実利用に追従し続けることが重要です。

大企業がこれを内製しようとすれば、導入初期から高い安全性とガバナンスを求められる一方で、AI活用そのものも前に進めなければなりません。活用推進、セキュリティ、ガバナンスを横断できる人材は限られ、採用・検証・運用に大きな時間とコストがかかります。

『Confidential AI Suite』が提供する価値は、まさにこうした広大な領域にまたがる複雑なAI基盤開発と運用の重責を、マネージドなプラットフォームとして一括して引き受ける点にあります。

利用企業は、AI活用推進のための機能開発、攻撃手法の最新動向、複雑な鍵管理に煩わされることなく、導入したその日から安全なプライベートモデルやエージェント環境を利用できます。開発者や従業員の体験（UX）を損なうことなく、最高レベルのセキュリティを透過的に標準機能として享受できることが、提供価値になります。

セキュリティを「透過的」にし、人の善意に依存しない構造を作る

ー Confidential AI Suiteを通じて、最終的にどのような世界を実現したいと考えていますか？

田中：「利用者がセキュリティを意識し続けなくても、情報が透過的（Transparent）に守られている世界」です。

今後、AIエージェントが自律的にツールを呼び出し、複数システム間を高速に往来して業務をこなす時代になります。そうした環境下で、人間がすべての操作や脅威（間接プロンプトインジェクションなど）を目視で確認・判断し続けるのは不可能です。人間の注意力や善意に依存した運用は必ず破綻します。

だからこそ、リスクの判断と防御をシステム側で引き受ける必要があります。権限の最小化、接続先ネットワークの制御、高リスク操作の禁止、完全な操作履歴の追跡性をプラットフォーム層で強制する。利用者は本来の付加価値を生む業務に集中し、裏側で強力なセキュリティが効いている状態を作る。そのために、私たちは脅威モデルの変化を継続的に検証・追従する責任を引き受けています。

こうした「信頼できるAI基盤」をつくる考え方は、CEO高橋さんの記事[HTTPSがWebを安全にしたように、信頼できるAIを実現する技術的な基盤を創る挑戦]でも紹介しています。

ー Confidential AI Suiteのバックエンドにおける、技術的な面白さやチャレンジングな課題について教えてください。

田中：大きく二つの難易度の高い技術課題に取り組んでいます。一つ目は「Confidential Serverless Computing」の実現（高速・低コストなエージェント実行基盤）です。

一般的なServerless環境では、軽量なコンテナやMicroVMを高密度に配置し、ミリ秒単位でオンデマンド起動させることでコストとパフォーマンスを両立します。

しかし、現在クラウドサービス上で使えるConfidential VM（AMD SEV-SNPやIntel TDX等）では、ネストされた仮想化やハードウェア仮想化支援機能に制約が存在し、従来のモデルを単純に持ち込むことができません。エージェントごとに重いVMを毎回一から立ち上げていては、待機コストも起動レイテンシも実用に耐えません。そのため、以下のような要素を包括的に再設計しています。

• 共有と隔離の明確な境界定義
• 暗号鍵を安全に解放する仕組み
• セッション終了時におけるメモリ・状態・鍵・一時データの不可逆な即時消去
• CCに対応したGPUとウォームプールのスケジューリング
• ネットワーク層でのテナント・セッション間の厳格な分離

機密性を落とすことなく、あたかもAWS LambdaやGoogle Cloud Run、Cloudflare Workersなどを使っているかのような開発者体験を提供する「Confidential Serverless Computing」と呼ぶべき基盤の独自構築に挑んでいます。

二つ目は、CCを一部の専門家の技術にとどめず、一般の開発者が通常のVMと同じ感覚で扱えるようにするミドルウェアの設計です。

ハードウェアを導入しただけでは、安全なアプリケーションは作れません。実行環境が想定どおりの構成で起動していることを検証し、その証跡を鍵管理側のポリシーが確認した場合にのみ鍵を渡す。さらに、メモリ外へ永続化するデータも暗号化して保護する必要があります。

ログも同様です。ログに機密情報が含まれれば、TEEで保護された領域の外へ平文が出てしまいます。機密情報がログへ流出しないことを、できるだけ機械的に検査・制御する仕組みも必要です。こうした複雑さを、ミドルウェア、プロキシ、API、アプリケーションなど、様々なレイヤーで吸収します。

リモートアテステーションでは、誰かが期待する構成の参照値と、実行環境から届く測定値を照合する必要があります。利用者側で直接検証する場合は、そのための参照値と検証ロジックをクライアント側に実装しなければならず、通常のHTTPSクライアントをそのまま使いにくいことが、導入上の壁になっていました。

この壁を下げるため、Attested TLSのようにTLS通信とアテステーション証跡を結び付け、検証を透過的に扱うための標準化提案が進んでいます。こうした方式に準拠した使いやすいライブラリをつくることも、重要なテーマです。

検証ロジックを、企業内や中立的な第三者が運用するVerifierやプロキシへ委任するアプローチもあります。エンドユーザーは詳細なアテステーションを実装せず、検証済みの通信を利用できるようになります。ただし、そのVerifierやプロキシは新たな信頼境界となるため、運用と監査を含めて設計する必要があります。

もう一つの課題は、メモリだけでなく永続データをどう守るかです。TEEの外へデータを書き出す以上、保存・読み出し時の暗号化と鍵の受け渡しまで設計しなければなりません。既存のDBMSやクラウド、セルフホスト環境で使われているSQL・ORMの延長で、鍵管理と連携しながらデータを暗号化して保存・利用できるようにする。そうしたミドルウェアやドライバを広く普及する形でつくることも、チャレンジの一つです。

Azure SQL Databaseの「Always Encrypted with secure enclaves」は、この方向性を示す一例です。構成に応じてIntel SGXの隔離領域で、暗号化された列に対する計算を処理できます。

CCのハードウェアを単に提供するのではなく、通常のアプリケーション開発に溶け込む安全なスタックとして届ける。そのための未知の課題を、コンピュータサイエンスの幅広い領域にまたがる技術を総動員して一体で解決していくことに、技術的な面白さがあります。（※）

※CCを開発者が扱えるプロダクトへ落とし込む背景は、[Confidential Computingのマーケットを切り拓く ──プロダクト化への挑戦]でも紹介しています。

ー CC（インフラ層）だけでなく、アプリケーション層のセキュリティ（Security for AI）についてはどのようにアプローチしていますか？

田中：CCは、実行中のデータを、ホストOSやハイパーバイザーといった特権ソフトウェアや、インフラの運用者から保護する技術です。リモートアテステーションにより、期待したイメージと構成の実行環境で動いていることも検証できます。

ただし、それだけでは「プロンプトインジェクション」や「AIエージェントの過剰権限による誤動作」のようなアプリケーション層自体への脅威は防げません。インフラ層とアプリ層の多層防御が必要になります。こういった多層にまたがるAIエージェントの脅威を体系化して整理しています。

例えば『Acompany AIスタジオ』では、メールや検索結果など外部から取得したテキストを「命令」ではなく「データ」として扱い、信頼できる業務指示と区別します。これは、外部コンテンツに埋め込まれた指示による間接プロンプトインジェクションへの基本的な対策の一つです。
エージェントを業務システムへ接続する際には、認証情報の扱いも別の攻撃面になります。さらに、隔離実行、依存パッケージの検証、通信先の制御、構造化した監査ログも組み合わせます。これらは複数ある対策の一部であり、単一のガードレールに依存せず、攻撃面ごとに防御を重ねる考え方です。

Security for AIは、まだ標準解が定まっていない領域です。現実に起こり始めているAIエージェントの脅威を捉え、ガードレールや権限制御といったアプリケーション層から、CCを含む機密実行インフラまで、網羅的に対策していく必要があります。

AIエージェントを業務で安全に使うための脅威対策と、その実行基盤をマネージドサービスとして提供するには、AIエージェント固有の脅威、認証・認可、アプリケーションセキュリティ、クラウド基盤、暗号・ハードウェアまで、コンピュータサイエンス全般にまたがる知識と深い専門性が必要です。未解決の課題を顧客価値につなげながら、この全体を設計・実装できることが、私たちにとって最もチャレンジングで面白い点です。

「Be Cool. Be Hacker.」なエンジニアと未知の領域を切り拓きたい

ー 今後、この高度なプロダクトをスケールさせていくにあたり、どのようなエンジニアと一緒に働きたいですか？

田中：弊社のエンジニアが取り組む領域は、低レイヤーの暗号・仮想化技術から、Webエンジニアリング、プロダクトの価値定義、UXデザインまでが一つにつながっています。こういった領域のエキスパートから、幅広く扱えるジェネラルな方など、様々なケイパビリティを持つ方を求めています。具体的には、以下のいずれかの領域に強みを持つエンジニアを求めています。

• AIセキュリティ / Webセキュリティ
• AI実行基盤 / GPU・推論最適化
• 商用Webサービスの立ち上げ、グロース
• データ基盤 / データエンジニアリング
• 暗号・鍵管理（PKI, Attestation）
• 低レイヤー技術（VM, ハイパーバイザー, Kernel ,OS, Rust）

また、未知の課題に対して顧客価値から逆算し、仮説検証を素早く回せる思考力も重視しています。Acompanyでは、行動指針として「Be Cool. Be Hacker.」を掲げています。

前人未到の「AI × CC」という領域で、世界基準のインフラを一緒に創り上げる、そんな思いを持った方と一緒に働きたいです。

株式会社Acompany 採用サイト

株式会社Acompanyの採用サイト。「非連続な未来を創る、圧倒的に」これはAcompanyが掲げるPurposeです。私たちは、常識や現状の延長ではたどり着けない領域を、技術と思想で切り拓きます。想像を超える価値を生み出し、圧倒的に進化する未来を共に創りませんか？

株式会社Acompany 採用サイト