なぜ、HimitsuBakoは安心して使えるのでしょうか。
その理由は、「大切な情報を、そもそも見せない」という発想にあります。
この連載「HimitsuBakoのヒミツ」では、その安全性を支える工夫を、数回に分けて紹介していきます。
第1回は、その中心にある技術「ゼロ知識証明（ZKP）」についてです。
「見せること」が前提だった社会の終焉？
私たちは、どこまで「見せること」を前提に生きているのでしょうか。
パスワード、個人情報、写真、やり取りの履歴。
それらは「安全に守られている」と感じながら使われています。
けれど本当にそうなのでしょうか…？
HimitsuBakoが問い直すのは、
単なるセキュリティ技術ではなく、その前提そのものです。
今回は、その背景にある考え方と技術に注目しました。
私たちは「実は、見えている」世界で安心している
HimitsuBakoを自社開発した企業のCEOである鄧氏は、
いま一般的に使われているサービスの構造について、このように説明します。
「これまでの多くのサービスは、「フロントエンド（ユーザーが操作する画面）・バックエンド（処理を担う仕組み）・データベース（データを保存する場所）という構成で作られています。」
このような構造は、一見すると合理的で、洗練された仕組みです。
「データの種類によって保存先は異なりますが、テキストのような軽い情報はデータベースに、
大量の画像や動画などはクラウドストレージ（インターネット上の保管場所）に保存される――」
こうした設計は、いまや誰にとってもイメージしやすいほど、身近で標準的なものとなっています。
しかし、その合理性の裏には、見過ごされがちな問題があることを指摘しています。
「そのままサーバーに保管すると、運用者でも内容を見ることができてしまう構造になります。
パスワード情報なども同様で、そのままの生データのままでは誰でも見られてしまうリスクがある仕組みです。」
もちろん、通信の暗号化やデータ保護の技術は進化してきました。 ですが多くの場合、「サーバーに届いた後の情報」は、完全に見えなくなるわけではありません。
つまり、私たちは、普段、「見られていない」と感じながらサービスを使っていますが、 実際には“見える状態に置かれている情報”の上で成り立っている。
「見ようと思えば見える場所」に情報を置いたまま、
それを見ないことに信頼を置いているのです。
さらに、こう続けます。
「多くのサービスは似た仕組みで動いているので、情報が漏れてしまう可能性を常に抱えています。じゃあ、これを防ごうとすると結構難しいんですね。」
この構造がある限り、設定ミスや内部不正、運用の不備、あるいは外部からの攻撃によって、
情報が意図しない形でアクセスされるリスクにさらされているというわけです。
ここで問われるのは、技術の問題だけではありません。
「見えることを前提とする設計」そのものです。
発想を変える：「見せる」から「証明する」へ
では、この問題にどう向き合うのか。
HimitsuBakoが選んだのは、ここで発想を大きく変えるアプローチでした。
情報を渡す、つまり「見せる」のではなく、
「それを知っている」という事実だけを確認する。
これは単なる効率化ではなく、
「確認とは何か」という問いの再定義でもあります。
この考え方を支えるのが、ゼロ知識証明です。
ゼロ知識証明は「信頼の置き方」を変える
ゼロ知識証明とは、
秘密の中身を明かさずに、「それを知っている」という事実だけを証明する技術
です。
少し不思議に聞こえるかもしれませんが、考え方は意外とシンプルです。
ここで重要なのは、「隠す」ことではありません。
そもそも「渡さない」ことです。
これまでの仕組みは、こうでした。
- 情報を渡す
- その正しさを確認する
一方、ゼロ知識証明では、
- 情報は渡さない
- それでも正しさは確認できる
という状態が成立します。
これは、「安全性の向上」というよりも、
信頼の置き方そのものの転換と言ったほうが近いかもしれません。
「言わずに証明する」ってどういうこと？
少しイメージしてみましょう。
たとえば「合言葉」を思い浮かべてみてください。
これまでの方法では、合言葉そのものを口に出して「言うこと」で伝えて確認していました。
つまり、一度は相手に渡す必要があったわけです。
一方、ゼロ知識証明では、その必要はありません。
「言わずに」、知っていることだけを証明するのです。
ドアの向こうにいる人に対して、
合言葉は直接言わない。
その代わりに、「知っている人だけが答えられるはずの問い」に答える
といったやり取りに近い仕組みです。
相手は合言葉そのものを知ることはありません。
それでも、「確かに知っている」ということは分かる。
「知っている人だけが通れる手順」を通過することで、正しさを示します。
ここでは、
- 相手に中身を明かさない
- それでも関係は成立する
という、少し異なる信頼のカタチが生まれます。
見せないのに証明できる
――この一見不思議な性質こそが、ゼロ知識証明の特徴です。
サーバーは「中身を知らないまま」機能する
HimitsuBakoでは、このゼロ知識証明の考え方を実装レベルまで落とし込んでいます。
「見せない」技術によって、サーバー側ですらユーザーの重要な情報の中身を知らないまま、処理が行われる仕組みを実現しています。
たとえばパスワード。
これまでは「正しいかどうか」を確認するために、
どこかでその内容に触れる必要がありました。
しかしこの仕組みでは、
- パスワードそのものは見せない
- それでも「正しいこと」だけを検証する
という状態になります。
つまり、
- 情報の中身は渡さない（＝ゼロ知識）
- サーバーは検証だけを行う
という役割に変わるのです。
これによって、サーバーは秘密情報を保持せずに済み、これまでの方法では防ぎきれなかった 情報が洩れることのリスクを大幅に減らすことができているということです。ただ、ここで起きているのは、単なるリスク低減ではありません。「知っている」大事なところをサーバーから切り離すという構造の変化です。
鍵をめぐる問題は「責任の所在」の問題でもある
これまでのセキュリティでは、「暗号化」も重要な手段でした。
しかしそこには別の課題があります。
それが、鍵を誰が持つのかという鍵管理の難しさと、そのバランスをめぐる問題です。
つまり、サーバー側では元のデータを見ることができず、本当のユーザーはどこかできちんと元の状態に復号化したデータを見る必要がありますが、そのための鍵をどこに置くのかによってリスクが変わるということが長く課題となってきたのです。
サーバー側が持てば管理のリスク（内部から漏洩）
ユーザー側が持てば喪失のリスク（端末が壊れたり紛失した場合のリカバリーが難しく、その方法も考慮する必要がある）
どちらを選んでも、一長一短があるというわけです。
これは単なる技術的問題ではなく、
責任をどこに置くかという問題でもあります。
HimitsuBakoでは、
- ユーザー側で安全にデータを扱い
- サーバーは中身に触れない
という設計で、この課題のバランスを取り直します。
ここでもやはり、
「誰が何を知っているのか」が再設計されています。
その結果、HimitsuBakoの
「見られない安心」と「使いやすさ」の両立の実現が可能になっています。
新しい安心のかたち――「見せない」という思想
ゼロ知識証明は、
「どう守るか」ではなく 「そもそも渡すのか」という問いから始まる技術です。
HimitsuBakoはこの考え方を取り入れることで、
これまでの情報漏洩のリスクが常に存在していた「中身に触れることを前提」とした設計を
「中身に触れることなく成立させる仕組み」へと換え、安心できるデータ管理を目指しています。
その結果、
- 情報を見せないまま
- 正しいことだけを検証できる
という環境を実現しています。
この「見せる」ことをやめる、という選択こそが、
これからのデジタル社会における、新しい安心を支えるかたちなのかもしれません。
この発想は、セキュリティの話にとどまりません。
これからのデジタル社会において、
私たちは何を誰に見せ、何を見せないのか。
その境界線を引き直す試みでもあります。