セキュリティ

AWS CloudHSMとは？KMSとの違い・東京の料金とクラスター構築手順をCLIで解説

AWS CloudHSMとは？KMSとの違い・東京の料金とクラスター構築手順をCLIで解説

AWS CloudHSMは、自分のVPCの中にシングルテナントのハードウェアセキュリティモジュール（HSM）を置き、暗号鍵をその中だけで生成・使用するAWSのサービスです。鍵を扱うAPIはPKCS#11、Java Cryptography Extensions（JCE）、Microsoft CNGといった業界標準のもので、AWS KMSのように「AWSのAPIで鍵を呼ぶ」形とは設計が異なります。

この記事では、KMSとの責任分界とカスタムキーストアの制約、東京リージョンの時間単価から出す月額、クラスターの作成から初期化・有効化までのCLI手順、CloudHSM CLIで鍵ペアを作ってRSA-PSS署名を検証するところまでを扱います。最後に、CloudHSMを採用すべき条件とKMSで足りる場面を言い切ります。

まとめ：CloudHSMを選ぶ条件と東京で月2,600ドル超になる費用構造

先に結論を置きます。CloudHSMは「より安全なKMS」ではなく、鍵の運用責任を自分で引き受ける代わりに標準APIと専有HSMを手に入れるサービスです。

  • 選ぶ理由は要件で決まる：PKCS#11やJCEでの鍵操作が仕様で指定されている、PCI PINのような決済系の監査がある、AWS側の運用者からも鍵を切り離したい。このいずれかが無ければKMSで足ります。
  • 費用は台数×時間で積み上がる：東京リージョンは1台1.81ドル毎時（2026年9月時点）。冗長化の最低ラインである2台を常時動かすと、730時間換算で月2,642ドル前後になります。
  • 作成時の選択は戻せない：HSMタイプは実質hsm2m.medium一択で、FIPSモードかnon-FIPSモードかはクラスター作成後に変えられません。
  • KMSと組み合わせる道もある：カスタムキーストアならKMSのAPIのまま鍵素材をCloudHSMに置けますが、対称鍵専用です。
  • hsm1.mediumは2026年3月31日でサポート終了：既存環境はhsm2m.mediumとClient SDK 5への移行状況を最初に確認します。

AWS CloudHSMの仕組み｜専有HSMクラスターとFIPS 140-3レベル3の範囲

CloudHSMを理解するうえで押さえる単位は「クラスター」と「HSM」の2つです。この2つの関係と、作成時に決める設定を先に整理します。

シングルテナントHSMとクラスター同期｜VPC内に置く鍵の保管場所

HSMは鍵を保管・演算する専用機器で、CloudHSMではその1台を1つのAWSアカウントが占有します。複数のHSMを束ねたものがクラスターで、CloudHSMはクラスター内のHSM同士でユーザー・鍵・ポリシーを同期し、1つの論理単位として扱います。HSM間の負荷分散を受け持つのはクライアントSDKです。

HSMの実体は利用者のVPC内のプライベートサブネットにENIとして現れます。クラスター作成時にセキュリティグループが自動で作られ、同じセキュリティグループに属するEC2からの接続だけを受け付ける構成です。バックアップはHSMの中で暗号化されてからリージョン内のサービス管理のS3バケットに保存され、AWS側も復号できない設計だと公式のGetting started以下のドキュメントで説明されています。

KMS側の管理境界はAWS KMSとは？仕組み・料金とキーポリシー設計で扱っています。

hsm2m.mediumとFIPSモード｜作成後に変えられない2つの選択

HSMタイプにはhsm1.mediumとhsm2m.mediumがありますが、非推奨化の告知によればhsm1.mediumは2025年4月から新規作成ができず、2026年3月31日にサポートを終えました。2026年1月からは既存クラスターのhsm2m.mediumへの自動移行も始まっています。新規構築で選ぶのはhsm2m.mediumです。

もう一つの選択がクラスターモードです。クラスターモードの説明では、FIPSモードはFIPS承認済みの鍵とアルゴリズムだけを使え、non-FIPSモードは承認外のものも含めて全機能を使えると整理されています。モードは作成後に変更できず、バックアップもFIPS同士・non-FIPS同士でしか復元できません。

項目 FIPSモード non-FIPSモード
使えるHSMタイプ hsm1.medium／hsm2m.medium hsm2m.mediumのみ
鍵とアルゴリズム FIPS承認済みのみ 承認外も含む全機能
バックアップの復元先 FIPSモードのみ non-FIPSモードのみ

認証の水準はコンプライアンス検証のページに記載があり、hsm2m.mediumはFIPS 140-3レベル3（NISTの証明書#4703）です。監査でFIPS準拠を示す必要がある案件はFIPSモード、PKCS#1 v1.5の暗号化などFIPSモードで止められた処理を残す必要がある案件だけnon-FIPSモード、という分け方になります。

クラスター上限と鍵数の上限｜hsm2m.mediumで16,666鍵までの制約

設計前に確認しておきたいのが上限値です。クォータのページでは、リージョンあたりのクラスター数は既定4、HSM数は既定6で、いずれも引き上げを申請できます。1クラスターに入れられるHSMは28台で、こちらは変更できません。

hsm2m.mediumの鍵の上限は1クラスター合計16,666本で、うち非対称鍵は3,333本までです。テナントごとに鍵ペアを発行するSaaSではこの3,333本が先に効くため、テナント数の見込みと照らしてください。

KMSとCloudHSMの違い｜鍵の管理責任とAPIと料金の3軸で比較

違いは暗号の強さではなく、誰が運用し、どのAPIで呼ぶかにあります。

KMS・CloudHSM・カスタムキーストアの責任分界と対応APIの比較

実務での選択肢はKMS単体、CloudHSM単体、KMSのカスタムキーストア（鍵素材をCloudHSMに置くKMS）の3つです。特徴を並べると次のようになります。

比較軸 KMS CloudHSM カスタムキーストア
HSMの運用 AWS 利用者 利用者
鍵を呼ぶAPI KMS API PKCS#11／JCE／CNG KMS API
S3・EBS等との統合 あり なし あり
鍵の種類 対称・非対称・HMAC 対称・非対称 対称のみ
主な費用 鍵とリクエスト課金 HSM台数×時間 両方が発生

表の2行目と3行目が分かれ目です。CloudHSMはAWSサービスと統合されないため、S3の暗号化などはKMS経由になります。一方で、Javaのアプリケーションが標準のJCEで署名する、OracleのTDEがPKCS#11で鍵を取りに行くといった「既存の標準APIをそのまま使いたい」用途はCloudHSMの領分です。データベースの接続文字列やAPIキーのような機密値の保管は、どちらでもなくAWS Secrets Managerの担当になります。

カスタムキーストアの制約｜対称鍵のみ・自動ローテーション不可の範囲

カスタムキーストアは両方の良い所取りに見えますが、制約が多い仕組みです。KMSのCloudHSMキーストアの解説によれば、作れるKMSキーは対称のAES-256鍵だけで、非対称キー、HMACキー、鍵素材のインポート、自動ローテーション、マルチリージョンキーはいずれも使えません。カスタムキーストアの数もアカウント・リージョンあたり10個までです。

キーストアを切断すると、そのKMSキーを使う暗号処理はすべて失敗します。「KMS統合を保ったまま鍵素材の所在を自社管理下に置く」という要件がはっきりしているときだけ選ぶ構成です。

CloudHSMの料金｜東京リージョン1.81ドル毎時から月額を見積もる計算

CloudHSMの課金は単純で、公式の料金ページにある通り、HSMを起動してから削除するまでの時間に対して1台ごとに時間単位で発生し、前払い費用はありません。単純な分、台数を見誤ると費用がそのまま倍になります。

Price List APIで東京の単価を取得するPythonスクリプトの実行例

料金ページの表はJavaScriptで描画されるため、見積りの根拠を残すなら認証不要のPrice List APIから取るのが確実です。次のスクリプトはPython標準ライブラリだけで、東京リージョン（ap-northeast-1）のCloudHSM単価と730時間換算の月額を表示します。

import json
import urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
index = json.load(urllib.request.urlopen(BASE + "/offers/v1.0/aws/CloudHSM/current/region_index.json"))
url = index["regions"]["ap-northeast-1"]["currentVersionUrl"]
offer = json.load(urllib.request.urlopen(BASE + url))
print("publicationDate:", offer["publicationDate"])

for sku, product in offer["products"].items():
    usage = product["attributes"].get("usagetype", "")
    if "CloudHSMv2Usage" not in usage:
        continue
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            hourly = float(dim["pricePerUnit"]["USD"])
            print(usage, hourly, "USD/h", round(hourly * 730, 1), "USD/month(730h)")

2026年10月5日に実行した時点の出力は次の通りで、価格データの公開日は2026年9月11日でした。同じオファーの米国東部（バージニア北部）は1.60ドル毎時なので、東京は約13%高い水準です。

publicationDate: 2026-09-11T12:46:25Z
APN1-CloudHSMv2Usage-hsm2m.m 1.81 USD/h 1321.3 USD/month(730h)
APN1-CloudHSMv2Usage 1.81 USD/h 1321.3 USD/month(730h)

冗長構成2台で月2,642ドル｜検証環境で課金を止めるHSM削除の手順

本番は2台以上が前提です。1台構成ではその1台の障害や保守で鍵操作が止まり、カスタムキーストアは2台未満だとKMSキーを新規作成できません。

構成（東京） 時間単価の合計 730時間換算の月額
検証用1台 1.81ドル 1,321.3ドル
本番2台（2AZ） 3.62ドル 2,642.6ドル
本番3台（3AZ） 5.43ドル 3,963.9ドル

検証環境では、使わない間にHSMをdelete-hsmで削除し、検証が終わればクラスターごと消します。1台残すだけで月1,300ドルを超えるため、検証用クラスターの放置は請求書で初めて気付く失敗の典型です。

# クラスター内のHSMを確認する
aws cloudhsmv2 describe-clusters --filters clusterIds="$CLUSTER_ID" \
  --query 'Clusters[0].Hsms[].[HsmId,AvailabilityZone,EniIp,State]' --output table

# 使わないHSMを削除して時間課金を止める
aws cloudhsmv2 delete-hsm --cluster-id "$CLUSTER_ID" --hsm-id "$HSM_ID"

CloudHSMクラスターを構築する手順｜作成から初期化・有効化までCLIで実行

ここから手を動かします。以下はプライベートサブネットとクライアント用EC2が用意済みの前提で、クラスター固有の作業だけを追います。

create-clusterでFIPSモードのクラスターと最初のHSMを作る

クラスター作成の手順では、HSMタイプ、バックアップの保持期間、サブネットIDを指定します。hsm1.medium以外では--modeが必須で、サブネットはアベイラビリティーゾーンごとに1つだけ渡します。バックアップの保持期間は既定90日で、7〜379日の範囲で変更が可能です。

# FIPSモードのクラスターを作成（サブネットはAZごとに1つ）
aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium \
  --mode FIPS \
  --backup-retention-policy Type=DAYS,Value=90 \
  --subnet-ids subnet-0aaa1111 subnet-0bbb2222

# 返ってきたClusterIdで最初のHSMを作る
CLUSTER_ID=cluster-xxxxxxxxxxx
aws cloudhsmv2 create-hsm --cluster-id "$CLUSTER_ID" \
  --availability-zone ap-northeast-1a

作成時にサービスリンクロールAWSServiceRoleForCloudHSMが作られるため、ロールを作れない権限では失敗します。最初の1回は管理者権限で実行してください。

CSRへの署名とinitialize-cluster｜トラストアンカー証明書の作り方

初期化はクラスターの所有者を証明書で確立する工程で、初期化の手順に沿ってHSMのCSRを自分のルートCAで署名して戻します。

# 1. クラスターのCSRを取り出す
aws cloudhsmv2 describe-clusters --filters clusterIds="$CLUSTER_ID" \
  --output text --query 'Clusters[].Certificates.ClusterCsr' \
  > "${CLUSTER_ID}_ClusterCsr.csr"

# 2. ルートCAの秘密鍵と自己署名証明書（10年）を作る
openssl genrsa -aes256 -out customerRootCA.key 3072
openssl req -new -x509 -days 3652 -key customerRootCA.key -out customerRootCA.crt

# 3. CSRに署名してHSM証明書を作る
openssl x509 -req -days 3652 -in "${CLUSTER_ID}_ClusterCsr.csr" \
  -CA customerRootCA.crt -CAkey customerRootCA.key -CAcreateserial \
  -out "${CLUSTER_ID}_CustomerHsmCertificate.crt"

# 4. 署名済み証明書とトラストアンカーで初期化する
aws cloudhsmv2 initialize-cluster --cluster-id "$CLUSTER_ID" \
  --signed-cert "file://${CLUSTER_ID}_CustomerHsmCertificate.crt" \
  --trust-anchor file://customerRootCA.crt

公式の例は2048ビットですが、対応表に3072・4096ビットも載っているため3072ビットにしました。2048ビットに期限が付いている事情はRSA暗号とは？仕組みと鍵長・パディングの選び方で整理しています。本番のルートCA鍵は、オフラインのHSMなど信頼できる環境で生成するよう公式も求めています。

CloudHSM CLIのインストールとcluster activateで管理者を有効化

初期化が終わったら、クライアントのEC2にCloudHSM CLIを入れます。インストール手順はOSごとにパッケージが分かれており、Amazon Linux 2023のx86_64なら次の通りです。

wget https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Amzn2023/cloudhsm-cli-latest.amzn2023.x86_64.rpm
sudo yum install ./cloudhsm-cli-latest.amzn2023.x86_64.rpm

# 初期化で作ったトラストアンカーを既定の場所に置き、HSMのIPを登録する
sudo cp customerRootCA.crt /opt/cloudhsm/etc/customerRootCA.crt
sudo /opt/cloudhsm/bin/configure-cli -a 10.0.1.25

# 対話モードで起動し、最初の管理者パスワードを設定する
/opt/cloudhsm/bin/cloudhsm-cli interactive
aws-cloudhsm > cluster activate

有効化の手順によれば、有効化前のadminはunactivated-adminという一時的なロールで、cluster activateでパスワードを決めるとadminに変わります。このパスワードは記録して安全な場所に保管するよう公式も勧めています。

CloudHSM CLIで鍵ペアを生成しRSA-PSS署名と検証を試す手順

クラスターが有効になれば鍵を扱えます。管理者は利用者アカウントを作るだけで、鍵の生成と使用はcrypto-user（CU）の権限です。この役割の分離がCloudHSMの運用の基本になります。

crypto-userを作りRSA鍵ペアを3072ビットで生成する手順

管理者でログインしてCUを作り、CUでログインし直してから鍵ペアを生成します。RSA鍵ペア生成のコマンドではモジュラス長の最小値が2048、公開指数は65537以上の奇数と決められています。

aws-cloudhsm > login --username admin --role admin
aws-cloudhsm > user create --username app_signer --role crypto-user
aws-cloudhsm > logout
aws-cloudhsm > login --username app_signer --role crypto-user

aws-cloudhsm > key generate-asymmetric-pair rsa \
  --public-exponent 65537 \
  --modulus-size-bits 3072 \
  --public-label invoice-sign-pub \
  --private-label invoice-sign-key \
  --public-attributes verify=true \
  --private-attributes sign=true

属性を付けずに生成するとsignもverifyもfalseのままで、署名コマンドが通りません。用途の属性は生成時に明示してください。5回続けてログインに失敗するとアカウントがロックされる点も、CUのパスワードを配布する前に共有しておくべき仕様です。

crypto signでのRSA-PSS署名とcrypto verifyでの検証

署名はcrypto sign rsa-pkcs-pssで行います。鍵はラベルなどの属性で指定し、MGFのハッシュは署名のハッシュ関数と揃える必要があります。

aws-cloudhsm > crypto sign rsa-pkcs-pss \
  --key-filter attr.label=invoice-sign-key \
  --hash-function sha256 \
  --mgf mgf1-sha256 \
  --salt-length 32 \
  --data-path invoice-2026-10.pdf

aws-cloudhsm > crypto verify rsa-pkcs-pss \
  --key-filter attr.label=invoice-sign-pub \
  --hash-function sha256 \
  --mgf mgf1-sha256 \
  --salt-length 32 \
  --data-path invoice-2026-10.pdf \
  --signature-path invoice-2026-10.sig

署名の出力JSONのsignature（Base64）をファイルに保存して検証に渡し、Signature verified successfullyが返れば成功です。ソルト長はハッシュ長と同じ32バイトにしておくと、OpenSSLのrsa_pss_saltlen:digestで外部の検証側と揃えやすくなります。

専用のkmsuserを作りKMSカスタムキーストアへ接続する手順

同じクラスターをKMSのカスタムキーストアとして使う場合は、キーストア作成の手順に沿って専用のCUkmsuserを作ります。パスワードは7〜32文字の英数字で、2FAを付けるとKMSがログインできなくなるため付けません。

# CloudHSM CLI（管理者でログインした状態）
aws-cloudhsm > user create --username kmsuser --role crypto-user

# AWS CLI：キーストアを作成し、接続してから対称KMSキーを作る
aws kms create-custom-key-store \
  --custom-key-store-name example-cloudhsm-store \
  --cloud-hsm-cluster-id "$CLUSTER_ID" \
  --key-store-password "$KMSUSER_PASSWORD" \
  --trust-anchor-certificate file://customerRootCA.crt

aws kms connect-custom-key-store --custom-key-store-id "$CKS_ID"
aws kms describe-custom-key-stores --custom-key-store-id "$CKS_ID" \
  --query 'CustomKeyStores[0].ConnectionState'

aws kms create-key --origin AWS_CLOUDHSM --custom-key-store-id "$CKS_ID"

KMSキーの作成は、接続状態がCONNECTEDになったのを確かめてから実行します。接続時にKMSはkmsuserのパスワードを自分で回転させるので、このアカウントを他の用途に流用しないでください。

CloudHSM導入で詰まりやすい箇所｜hsm1移行・SDK 3廃止・mTLSの落とし穴

公式ドキュメントの注意書きに散らばっている制約を、詰まる順に並べます。

hsm1.mediumのサポート終了とClient SDK 5への移行の確認

既存環境で最初に確認するのはHSMタイプとSDKの版です。hsm2m.mediumへの移行では、アプリケーション側がClient SDK 5に上がっていないと接続が途切れると告知されています。Client SDK 3のコマンドラインツールであるcloudhsm_mgmt_util（CMU）とkey_mgmt_util（KMU）は2025年1月1日でサポートを終えており、2025年以前の解説記事にある手順はそのままでは使えません。

FIPSモードのクラスターでは、2024年1月1日からTriple DESでの暗号化と、PKCS#1 v1.5パディングによるRSAの鍵ラップ・暗号化・復号が使えなくなっています。古いアプリケーションがCKM_RSA_PKCSやRSA/ECB/PKCS1Paddingで鍵を包んでいる場合、移行先のクラスターで同じ処理が失敗します。OAEPへの切り替えを移行計画に入れてください。

カスタムキーストアとmTLSの非互換・2FA付きkmsuserの作り直し

hsm2m.mediumはクライアントとHSMの間の相互TLS（mTLS）に対応し、公式も設定を推奨しています。ところがKMSのカスタムキーストアは、mTLSを有効にしたクラスターに接続できません。アプリからの直接利用とKMS経由の利用を1つのクラスターで兼ねる設計では、構築前にクラスターを分けるかmTLSを見送るかを決めてください。

kmsuserに2FAを付けてしまった場合は取り消せず、ユーザーを削除して作り直すしかありません。キーストアに紐づけた後でプライベートサブネットを消すと、接続がSUBNET_NOT_FOUNDで失敗する点も見落とされがちです。この種の構成判断を含めてAWSの鍵管理基盤を設計から任せたい場合は、AWS・Google Cloud・Azureのインフラ構築の範囲で相談を受けています。

CloudHSMを採用する条件とKMSで足りる場面の判断基準

最後に判断を言い切ります。CloudHSMは要件が先にあるときに選ぶサービスで、「念のため強い方を」という理由で選ぶと、月数千ドルの固定費と運用負荷だけが残ります。

CloudHSMを選ぶ条件｜PKCS#11の要件・PCI PIN・鍵の単独管理

次のどれかに当てはまるなら、CloudHSMを選ぶ理由があります。第一に、アプリケーションやミドルウェアがPKCS#11・JCE・CNGで鍵を扱う仕様になっている場合です。オンプレミスのHSMで動いていた署名基盤やOracle TDEの移行がこれに当たります。第二に、決済系でPCI PINやPCI-3DSへの準拠が求められる場合で、CloudHSMのHSMはhsm1.medium・hsm2m.mediumとも両方に準拠しています。

第三に、鍵の管理者をAWSから切り離すことが契約や規制で求められる場合です。HSMのユーザーと鍵は利用者だけが管理し、バックアップもAWSは復号できません。TLS証明書を発行する自社CAの署名鍵はこの条件に入りやすく、証明書の運用はTLSとは？SSLとの違い・仕組みとバージョン選定とあわせて設計します。

CloudHSMを見送る場面｜S3やEBSの暗号化だけならKMSで足りる理由

反対に、S3・EBS・RDSの保存データを暗号化したいだけなら、CloudHSMは過剰です。これらはKMSと統合済みで、暗号の強さでCloudHSMが上回るわけでもありません。非対称鍵での署名も、まずKMSの非対称キーで足りるかを確かめてください。カスタムキーストアは対称鍵専用なので、「KMS統合のまま非対称鍵をCloudHSMに置く」構成は組めません。

マルチクラウドで鍵管理を揃えたい場合は、Azure側の専有HSMの扱いをAzure Key Vaultとは：Managed HSMの違いで確認してから方式を決めると、IaCの分割を後から作り直さずに済みます。

よくある質問

AWS CloudHSMの検討と構築でよく挙がる質問をまとめました。

CloudHSMとKMSの違いは何ですか？

違いは、HSMを誰が運用するかと、鍵をどのAPIで呼ぶかという点です。KMSはAWSが運用するHSMをKMS APIで使うサービスで、S3やEBSなど多くのAWSサービスと統合されています。CloudHSMは利用者専有のHSMを自分のVPCに置き、PKCS#11・JCE・CNGといった業界標準APIで操作します。ユーザーとHSM台数の管理は利用者の責任で、AWSサービスとの直接統合はありません。両者をつなぐのがKMSのカスタムキーストアです。

CloudHSMの料金は月いくらかかりますか？

東京リージョンは1台あたり1.81ドル毎時で、2026年9月11日公開の価格データで確認した値です。730時間換算で1台1,321.3ドル、冗長化した2台構成なら2,642.6ドルになります。課金はHSMを起動してから削除するまでの時間単位で、前払いはありません。検証環境ではHSMを残したまま放置しないことが費用管理の要点で、使わない時間帯はdelete-hsmで台数を減らします。

CloudHSMの無料枠や無料トライアルはありますか？

現行のCloudHSM（hsm2m.medium）の料金に無料枠はありません。Price List APIに残るトライアル用の項目は旧世代向けで、現行HSMの時間単価とは別のものです。手順を試すだけでも1台分の時間課金が発生するため、検証は作業時間を決めて行い、終わったらHSMとクラスターを削除してください。鍵管理を安く試したいだけならKMSで始めるほうが現実的でしょう。

CloudHSMのHSMは最低何台必要ですか？

動かすだけなら1台で足りますが、本番は異なるアベイラビリティーゾーンに2台以上が前提です。1台構成ではそのHSMの障害や保守の間に鍵操作が止まります。KMSのカスタムキーストアとして使う場合も、異なるAZにアクティブなHSMが2台以上ないとKMSキーを作れません。上限は1クラスター28台です。

hsm1.mediumのクラスターはどうなりますか？

hsm1.mediumは2026年3月31日にサポートを終え、2026年1月からhsm2m.mediumへの自動移行が始まっています。移行方法はCloudHSM管理の移行へのオプトインと、バックアップから新クラスターを作るブルーグリーン切り替えの2つです。どちらでもアプリケーション側をClient SDK 5へ更新しておかないと、移行後に接続できなくなります。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.09.25　コラム 社会保険加入条件は50人以下の場合どうなる：2027年10月からの段階撤廃と週20時間の判定をシステムで行う要件
  2. 2026.04.20　テックブログ Chrome（Gemini）のSkillsとは？使い方・作成手順・利用条件と表示されない時の対処
  3. 2026.09.25　コラム 最低賃金引き上げ【令和8年度】47都道府県の改定額・発効日と企業の対応手順
  4. 2026.06.16　コラム 内部通報制度の改正ポイント｜2026年12月1日施行の公益通報者保護法と改正指針への対応
  5. 2024.06.11　コラム 個人情報漏えい件数の推移をグラフで解説｜最新データと過去最多（約1.9万件）

RELATED POSTS 関連記事

一覧へ戻る

目次