VCと既存のID管理の使い分け
VCと既存のID管理の使い分けとは、どこまでを既存の仕組みで対応し、どこから証明として持たせるかを決める判断のことです。 両者は置き換えの関係ではなく、担う範囲が違います。 どこまでを既存の仕組みで対応し、どこから証明として持たせるかを決めることが、実務上の判断になります。
別表記:VCとIAMの違い/VCと既存ID管理の使い分け/IAMとVCの棲み分け
それぞれが担っていること
既存のID管理は、自社の統制下にある主体に対して、システム側が権限の一覧を持ち、要求のたびに照合します。誰がどこにアクセスできるかは、システムの側が知っています。
VC(Verifiable Credentials) は、改ざんされたことが分かるデジタルの証明書です。権限の内容を主体に持たせ、受け取った側が発行者の署名を検証して確かめます。権限の情報が、主体に付いて回ります。
既存の仕組みで足りる場面
社内で完結し、対象が固定されていて、自社のシステムが権限を把握できている。この範囲であれば、既存の仕組みで対応できます。
新しい技術を持ち込む必要はありません。むしろ、すでに運用が回っているものを崩さないほうが安全です。
VCが効いてくる場面
「誰の委任に基づくのか」を表現したいとき。 役割を割り当てるだけでは、特定の人から特定の業務を任されているという関係は表せません。
環境や組織をまたぐとき。 AIが別のAIに作業を渡す、外部のサービス上で動くといった構成では、自社の仕組みの外側に権限の情報が出ていきます。
あとから根拠を示す必要があるとき。 誰がいつ何を許可したのかが、署名付きの記録として残ります。管理画面の設定ではなく、検証できる形で提示できます。
発行する人を分けたいとき。 情報システム部門が上限を定め、その枠の中で部門長が個別に委任する、という二段構えを表現できます。承認の流れが、そのまま権限の形になります。
判断の順序
まず、既存の仕組みでどこまで対応できるかを確かめます。そのうえで、足りない部分にVCを当てる。この順序であれば、無駄な作りこみを避けられます。
「VCを導入する」から始めるのではなく、「この業務をAIに任せるには、何をどう証明する必要があるか」から始めるほうが、結果的に早く進みます。
