Claude Codeのセキュリティ対策｜企業導入前に知るべきリスクと設定

Claude Codeを本番環境の開発ワークフローに組み込む企業が増えています。ターミナル上でコードの生成・編集・実行を自律的に行うこのツールは、開発効率を劇的に向上させる一方で、従来のコーディング支援ツールとは次元の異なるセキュリティリスクを内包しています。

筆者は金融系データベース管理者としてのキャリアを経て、現在IT企業を経営していますが、金融業界で叩き込まれた「最小権限の原則」と「証跡の確保」という考え方は、AIエージェントの導入においても変わらず重要だと実感しています。むしろ、AIが自律的にコマンドを実行するという性質上、従来以上に慎重な権限設計が求められます。

本記事では、Claude Codeのセキュリティモデルの全体像から、パーミッション設定、APIキー管理、クラウドプロバイダ経由での利用方法、そして企業導入時に確認すべき項目までを体系的に解説します。Claude Codeの基本的な機能や使い方についてはClaude Codeとは？完全ガイドをご覧ください。

Claude Codeのセキュリティモデル

Claude Codeのセキュリティを理解するうえで、最も重要な前提があります。それは、Claude Codeがユーザーのターミナルアカウントと同じ権限で動作するという点です。

これは一見当たり前のことのように聞こえるかもしれませんが、その意味するところは深刻です。ターミナルで sudo が使えるユーザーであれば、Claude Codeも原理的にはシステム全体を操作できます。~/.ssh ディレクトリにアクセスできるなら、SSH秘密鍵を読み取ることも技術的には可能です。つまり、Claude Codeに対するセキュリティ対策とは、ターミナル操作そのもののセキュリティを見直すことと同義なのです。

多層防御のアーキテクチャ

Anthropicはこのリスクに対して、多層防御（Defense in Depth）のアプローチを採用しています。単一の仕組みに依存するのではなく、複数の防御レイヤーを重ねることで、いずれかが突破されても被害を最小限に抑える設計です。

具体的には、以下の層が存在します。

パーミッションシステム -- ツール実行前にユーザーの明示的な承認を要求する
分類器モデル -- 自動実行モード時に、別のAIモデルがリスク判定を行う
サンドボックス -- OS レベルでファイルシステムとネットワークアクセスを制限する
Hooks -- パーミッションチェックの前段階で、カスタムルールによる制御を実行する

この多層構造は、金融システムにおけるセキュリティ設計と同じ思想です。認証・認可・監査・隔離のそれぞれが独立して機能し、どれか一つが破られても全体が崩壊しない。筆者がこのモデルを評価するのは、まさにこの設計思想に共感するからです。

サンドボックスによるOS レベルの隔離

Claude Codeのサンドボックス機能は、コンテナ技術とは異なるOS レベルのプロセス隔離を提供します。具体的には以下のような制限が適用されます。

ファイルシステムアクセスの制限 -- プロジェクトディレクトリと明示的に許可されたパス以外への読み書きをブロック
ネットワークアクセスの制限 -- 許可されたドメインやポート以外への外部通信を遮断
PID名前空間の隔離 -- Claude Codeのプロセスが他のプロセスを参照・操作できないよう分離

最近のアップデートでは、PID名前空間の隔離が強化され、資格情報のスクラビング（意図しない認証情報の漏洩防止）やPowerShell実行時の権限硬化も導入されました。これらはいずれも、Claude Codeが意図しない操作を実行した場合の被害範囲を限定するための仕組みです。

サンドボックスの設定は ~/.claude/settings.json で管理します。

{
  "permissions": {
    "sandbox": {
      "enabled": true,
      "allowedPaths": [
        "/Users/username/projects",
        "/tmp"
      ],
      "networkPolicy": {
        "allowedDomains": [
          "api.github.com",
          "registry.npmjs.org"
        ]
      }
    }
  }
}

筆者の運用では、プロジェクトごとにサンドボックスの許可パスを最小限に絞っています。「動かないから広げる」のではなく、「必要になったら都度追加する」という方針が重要です。

データプライバシーとSOC 2 Type II準拠

企業導入において避けて通れないのが、「Claude Codeに渡したコードはどう扱われるのか」という問題です。

Anthropicは明確に、Claude Codeを通じて処理されたコードはモデルの学習には使用しないと表明しています。これはAnthropicのデータ処理ポリシーに基づくもので、API経由で送信されたデータは応答生成のためにのみ使用され、学習データセットには含まれません。

また、AnthropicはSOC 2 Type IIの認証を取得しています。SOC 2 Type IIは、セキュリティ・可用性・処理の完全性・機密性・プライバシーの各基準について、一定期間にわたる運用の有効性を第三者機関が監査するものです。金融機関や大企業がサービス導入を検討する際に、この認証の有無は重要な判断材料となります。

パーミッション設定とアクセス制御

Claude Codeの実行制御の中核を担うのがパーミッションシステムです。5つのモードが用意されており、それぞれセキュリティと利便性のトレードオフが異なります。

パーミッションモードの詳細

default（デフォルト）

すべてのツール実行において、事前にユーザーの承認を求めます。ファイルの編集、コマンドの実行、外部APIへのアクセスなど、あらゆる操作の前にプロンプトが表示されます。

Claude wants to edit: src/components/Header.tsx
Allow? (y/n/always)

最も安全なモードですが、承認のたびに作業が中断されるため、生産性への影響は無視できません。ただし、導入初期やセキュリティ要件が厳格な環境では、このモードから始めることを強く推奨します。

plan（プランモード）

Claude Codeがまず実行計画を提示し、ユーザーが計画全体を確認してから承認します。個々の操作ではなく、一連の作業単位で承認を行うため、defaultモードよりも効率的です。

Plan: 
1. Read src/utils/auth.ts
2. Add input validation to login function
3. Update tests in src/utils/auth.test.ts

Approve this plan? (y/n)

筆者のチームでは、通常の開発作業ではこのplanモードを標準としています。何を行うかを事前に確認できるため、意図しない変更を防ぎつつ、承認の手間を最小限に抑えられます。

auto（自動モード）

Claude Codeが自律的にツールを実行しますが、実行前に別の分類器モデル（classifier model）がリスク判定を行います。この分類器は以下のような操作を検出してブロックします。

スコープの逸脱 -- 現在の作業コンテキストから外れた操作（例：フロントエンドの修正中にデータベースのマイグレーションを実行しようとする）
未知のインフラへの操作 -- 設定されていないサーバーやサービスへのアクセス
悪意のあるコンテンツ -- プロンプトインジェクションの可能性がある入力の実行

autoモードは生産性が高い反面、分類器の判定が100%正確であるという保証はありません。分類器自体がAIモデルであるため、巧妙に設計されたプロンプトインジェクションを見逃す可能性は理論的には存在します。筆者は本番環境に影響を与えない開発タスク（テストコードの作成、リファクタリングなど）に限定して使用しています。

acceptEdits（編集自動承認モード）

ファイルの編集操作は自動的に承認されますが、シェルコマンドの実行やその他の操作には引き続き承認が必要です。コードの修正作業に集中したい場合に有用ですが、意図しないファイル変更が発生するリスクがあります。

bypassPermissions（全承認バイパス）

すべてのパーミッションチェックを無効化し、Claude Codeが完全に自律的に動作します。このモードは極めて危険であり、本番環境での使用は絶対に推奨しません。テスト目的の隔離された環境でのみ検討すべきです。

{
  "permissions": {
    "mode": "bypassPermissions"
  }
}

上記の設定を本番のプロジェクトに適用してしまうケースを散見しますが、これは自宅の玄関を常時開放しているのと同じです。便利さの裏にあるリスクを正しく理解してください。

パーミッションモードの選択指針

環境	推奨モード	理由
本番環境に接続可能な端末	default	誤操作による本番影響を完全に防止
通常の開発作業	plan	計画確認による安全性と生産性のバランス
テストコード作成・リファクタリング	auto	低リスク作業での生産性最大化
隔離されたCI/CD環境	acceptEdits	自動化パイプラインでの効率性確保
絶対に使うべきでない	bypassPermissions	セキュリティリスクが許容範囲を超える

Hooksによるセキュリティ強制

Claude CodeのHooks機能は、セキュリティの文脈では特に重要な役割を果たします。Hooksはパーミッションチェックの前段階で実行されるため、bypassPermissionsモードであっても強制的にルールを適用できるという特徴があります。

例えば、本番データベースへの接続を一切禁止するHookを設定する場合は、以下のように記述します。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "bash -c 'if echo \"$TOOL_INPUT\" | grep -qE \"(production|prod-db|本番)\"; then echo \"DENIED: 本番環境への操作は禁止されています\" >&2; exit 1; fi'"
      }
    ]
  }
}

PreToolUse Hookはツール実行の前に発火し、終了コード1を返すことで実行を拒否します。この仕組みの優れた点は、パーミッションモードの設定に関係なく適用されることです。つまり、誰かが誤ってbypassPermissionsに設定してしまった場合でも、Hookによるガードレールは機能し続けます。

筆者は以下のようなHookを標準的に設定しています。

本番環境のホスト名やデータベース名を含むコマンドの拒否
rm -rf や DROP TABLE など破壊的操作の検出と拒否
機密ファイル（.env、credentials.json、秘密鍵ファイル）の読み取り制限
外部への curl や wget による意図しないデータ送信の検出

Hooksの詳細な設定方法や活用例については、Claude Code Hooks完全ガイドで詳しく解説しています。

APIキー・認証情報の安全な管理

Claude Codeの利用にはAPIキーが必要ですが、このキーの管理方法を誤ると、深刻なセキュリティインシデントにつながります。

APIキーの基本的な取り扱い

最も重要な原則は、APIキーを絶対にコードにハードコードしないことです。これはAPIキー管理の基本中の基本ですが、いまだに多くのプロジェクトで守られていません。GitHubの公開リポジトリにAPIキーがコミットされ、数分以内にスキャンボットに検出されて不正利用される事例は後を絶ちません。

Claude Codeでは、環境変数 ANTHROPIC_API_KEY を通じてキーを設定します。

export ANTHROPIC_API_KEY="sk-ant-xxxxxxxxxxxxx"

ただし、シェルの履歴に残る .bashrc や .zshrc への直接記述は避けるべきです。代わりに、~/.claude/settings.json の env セクションを使用するか、シークレット管理ツールを経由します。

{
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-xxxxxxxxxxxxx"
  }
}

この settings.json ファイル自体のパーミッションも適切に設定する必要があります。

chmod 600 ~/.claude/settings.json

Anthropic Consoleでの利用上限管理

APIキーの漏洩時の被害を軽減するために、Anthropic Consoleで利用上限を設定することを強く推奨します。以下の制御が可能です。

日次上限（Daily Limit） -- 1日あたりの最大利用額
月次上限（Monthly Limit） -- 月あたりの最大利用額
キー単位の上限 -- APIキーごとに個別の上限を設定

Anthropic Console > API Keys > [キー名] > Spend Limits
  Daily Limit: $50
  Monthly Limit: $500

筆者の運用では、開発者個人用のキーには日次$20、月次$200の上限を設定しています。CI/CD用のキーは用途に応じて別途上限を設定し、万が一の漏洩時にも被害額を限定できるようにしています。

APIキーのローテーション

APIキーは定期的にローテーション（更新）すべきです。以下のタイミングでの更新を推奨します。

定期更新 -- 90日ごと（四半期ごと）
メンバー離脱時 -- チームメンバーが退職・異動した場合は即座に更新
漏洩の疑い -- キーが外部に流出した可能性がある場合は即座に無効化・再発行
権限変更時 -- キーに紐づく権限を変更する場合

ローテーションの手順は以下の通りです。

Anthropic Consoleで新しいキーを発行
環境変数・設定ファイルを新しいキーに更新
正常に動作することを確認
古いキーを無効化
キー更新の記録を残す

この手順で重要なのは、古いキーの無効化を新しいキーの動作確認後に行うことです。同時に切り替えるとダウンタイムが発生するリスクがあります。

チーム運用でのキー管理戦略

チームでClaude Codeを利用する場合、キー管理の戦略は以下の2つに大別されます。

個別キー方式

各開発者がそれぞれのAPIキーを持つ方式です。利用状況の追跡が容易で、特定のキーが漏洩した場合の影響範囲が限定される利点があります。一方で、キーの発行・管理・ローテーションの運用負荷が人数に比例して増加します。

共有キー＋プロキシ方式

組織で管理するプロキシサーバーを経由してAPIにアクセスする方式です。個々の開発者はAPIキーを直接保持せず、プロキシの認証情報のみを管理します。キー管理が一元化される反面、プロキシサーバー自体のセキュリティが新たな懸念点となります。

筆者は個別キー方式を採用しています。管理の手間はかかりますが、金融系の経験から「共有アカウント・共有鍵は監査時に問題になる」という教訓があるためです。誰がいつ何を実行したかを追跡可能にするには、個別のキーが不可欠です。

Amazon Bedrock経由での利用

企業のセキュリティポリシーが「社外にデータを出さない」ことを要求する場合、Amazon Bedrock経由でClaude Codeを利用する選択肢があります。

Bedrock利用のセキュリティ上のメリット

Amazon Bedrock経由の利用には、以下のセキュリティ上のメリットがあります。

データが自社のAWSアカウント内に留まる

Anthropicの公開APIを使用する場合、リクエストデータはAnthropicのインフラを経由します。一方、Bedrock経由であれば、データは自社のVPC内で処理され、AWSアカウントの外に出ることはありません。金融機関や医療機関など、データの所在地に厳格な要件がある業種では、この点が決定的な差別化要因となります。

IAMによるきめ細かいアクセス制御

AWS IAMと統合されるため、既存のAWS権限管理の仕組みをそのまま活用できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/Department": "Engineering"
        }
      }
    }
  ]
}

上記の例では、Department タグが Engineering のユーザーのみがClaude モデルを呼び出せるよう制限しています。部門ごと、プロジェクトごと、さらにはモデルのバージョンごとにアクセスを制御できます。

CloudTrailによる監査ログ

すべてのAPI呼び出しがAWS CloudTrailに記録されます。いつ、誰が、どのモデルを、どのリージョンから呼び出したかが自動的に証跡として残ります。

{
  "eventSource": "bedrock.amazonaws.com",
  "eventName": "InvokeModel",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:user/developer-a"
  },
  "requestParameters": {
    "modelId": "anthropic.claude-sonnet-4-20250514"
  }
}

金融機関出身の筆者にとって、この監査ログの自動取得は極めて重要です。「誰が何をしたか」を後から追跡できない環境は、そもそも企業利用に適さないと考えています。

BedrockでClaude Codeを利用する設定

Claude CodeをBedrock経由で利用するには、以下の環境変数を設定します。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

ただし、アクセスキーの直接設定よりも、IAMロールやインスタンスプロファイルの利用を推奨します。EC2インスタンスやECSタスクから利用する場合は、IAMロールを関連付けることでキーの管理自体が不要になります。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
# IAMロールが関連付けられている場合、キーの設定は不要

VPC内での閉域利用

さらにセキュリティを強化する場合、VPCエンドポイントを使用してBedrock APIへのアクセスをVPC内に閉じることができます。

# VPCエンドポイントの作成（AWS CLI）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxxxx \
  --security-group-ids sg-xxxxx

この構成により、インターネットを経由せずにBedrock APIを利用でき、データがVPCの外に出ることを物理的に防止できます。

Vertex AI経由での利用

Google Cloud Platform（GCP）を主に利用している企業には、Vertex AI経由でClaude Codeを利用する選択肢があります。Vertex AIの詳しい概要についてはVertex AIとは？を参照してください。

Vertex AIのセキュリティ特性

Workload Identity Federation

Vertex AI経由の利用で特筆すべきは、Workload Identity Federationのサポートです。これにより、サービスアカウントキーを発行・管理することなく、外部のIDプロバイダ（AWS、Azure AD、OIDC準拠のプロバイダなど）の認証情報を使ってGCPリソースにアクセスできます。

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_EMAIL:generateAccessToken",
  "token_url": "https://sts.googleapis.com/v1/token"
}

サービスアカウントキーは長期間有効な認証情報であり、漏洩時のリスクが高いものです。Workload Identity Federationを使用すれば、短命のトークンで認証を行うため、キー漏洩のリスクを根本的に排除できます。

サービスアカウントによる権限管理

GCPのIAMを活用して、Vertex AIへのアクセスを制御します。

# サービスアカウントの作成
gcloud iam service-accounts create claude-code-sa \
  --display-name="Claude Code Service Account"

# Vertex AIユーザーロールの付与
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:claude-code-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

VPC Service Controls

GCPのVPC Service Controlsを使用すると、Vertex AIへのアクセスをVPCの境界内に制限できます。これはAWSのVPCエンドポイントに相当する機能で、データの外部流出を防止するためのネットワークレベルの制御です。

# サービス境界の作成
gcloud access-context-manager perimeters create claude-code-perimeter \
  --title="Claude Code Perimeter" \
  --resources="projects/PROJECT_NUMBER" \
  --restricted-services="aiplatform.googleapis.com" \
  --policy=POLICY_ID

Vertex AIでClaude Codeを利用する設定

Vertex AI経由でClaude Codeを利用する場合の環境変数は以下の通りです。

export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=us-east5
export ANTHROPIC_VERTEX_PROJECT_ID=your-project-id

認証はGoogle Cloudの標準的な認証フローに従います。ローカル開発環境では gcloud auth application-default login で認証し、本番環境ではサービスアカウントまたはWorkload Identity Federationを使用します。

Microsoft Foundry経由の利用

なお、サードパーティプロバイダとしてMicrosoft Foundryもサポートされています。Azure環境を中心に運用している企業にとっては、既存のAzure ADやRBACの仕組みと統合できる点がメリットとなります。

各クラウドプロバイダの選択は、自社の既存インフラとセキュリティポリシーに合わせて判断してください。いずれの経由方法を選んでも、データが自社の管理下に留まり、既存の権限管理・監査ログの仕組みを活用できるという本質的なメリットは共通です。

企業導入時のセキュリティチェックリスト

ここまで解説してきた個々のセキュリティ機能を、実際の導入プロセスに落とし込みます。以下のチェックリストは、筆者が自社およびクライアント企業でClaude Codeの導入を支援する際に使用しているものをベースにしています。

1. パーミッションモードの選定

導入時に最初に決定すべきは、パーミッションモードです。

組織のセキュリティポリシーに基づいてパーミッションモードを決定した
本番環境に接続可能な端末ではdefaultモードを設定した
bypassPermissionsモードの使用を組織として禁止した
パーミッションモードの設定変更には承認フローを設けた

筆者の推奨は、全員planモードから開始し、プロジェクトの性質に応じてautoモードへの移行を検討するアプローチです。最初からautoモードを許可すると、セキュリティ意識が十分に醸成される前に事故が発生するリスクがあります。

2. サンドボックスの評価と設定

サンドボックスの有効化を確認した
許可するファイルパスを最小限に設定した
ネットワークアクセスの許可リストを定義した
サンドボックス設定の変更管理プロセスを策定した

3. APIキーの運用ポリシー

APIキーの発行・管理・廃棄のプロセスを文書化した
キーごとの利用上限（日次・月次）を設定した
キーのローテーション間隔を決定した（推奨：90日）
メンバー離脱時のキー無効化手順を策定した
キーの保管方法を決定した（環境変数 or シークレット管理ツール）

4. VPCデプロイメントの評価

データの所在地に関する要件を確認した
Anthropic直接API / Bedrock / Vertex AIのいずれを使用するか決定した
VPC内での閉域利用の要否を判断した
クラウドプロバイダのIAMポリシーを設計した
監査ログの取得・保管方法を決定した

5. Hookによるガードレールの設定

本番環境への操作を制限するHookを設定した
破壊的コマンドを検出・拒否するHookを設定した
機密ファイルへのアクセスを制限するHookを設定した
Hookの設定をバージョン管理に含めた

6. 監査ログの要件定義

取得すべきログの範囲を定義した
ログの保管期間を決定した
ログの監視・アラートの仕組みを検討した
定期的なログレビューのプロセスを策定した

7. チームオンボーディングのセキュリティ教育

Claude Codeのセキュリティリスクに関する教育資料を作成した
パーミッションモードの意味と選択基準を説明した
APIキーの取り扱い規則を周知した
インシデント発生時の報告・対応フローを策定した
定期的なセキュリティ研修の実施計画を立てた

エンタープライズ向け機能の活用

大規模な組織での導入には、Claude Codeのエンタープライズ向け機能が有効です。料金プランの詳細についてはClaude Code料金プラン完全比較をご確認ください。

SSO（シングルサインオン）

Okta、Azure AD、SAML 2.0準拠のIDプロバイダとの統合が可能です。既存のID管理基盤をそのまま活用でき、個別のアカウント管理が不要になります。

SCIMプロビジョニング

SCIM（System for Cross-domain Identity Management）に対応しており、ユーザーのプロビジョニング（作成・更新・削除）を自動化できます。人事システムやIDプロバイダと連携すれば、メンバーの入退社に伴うアカウント管理が自動化されます。

監査ログ

管理者向けの監査ログ機能により、組織内のClaude Code利用状況を可視化できます。誰がいつどのような操作を行ったかを追跡可能です。

カスタムデータ保持期間

組織のデータ保持ポリシーに合わせて、会話データの保持期間をカスタマイズできます。規制要件に応じた設定が可能です。

IPアドレス制限（IP Allowlisting）

許可されたIPアドレスからのみアクセスを許可する設定が可能です。オフィスネットワークやVPNからのアクセスに限定することで、不正アクセスのリスクを低減します。

ロールベースアクセス制御

組織内のユーザーに対して、役割に応じたアクセス権限を設定できます。管理者、開発者、閲覧者など、役割に応じた権限の使い分けが可能です。

BYOK（Bring Your Own Key）

2026年前半にBYOK（自社管理の暗号鍵によるデータ暗号化）の提供が予定されています。これにより、Anthropicに保存されるデータの暗号化に自社のKMS（Key Management Service）を使用できるようになります。金融機関や政府機関など、暗号鍵の自社管理が必須の組織にとって待望の機能です。

まとめ

Claude Codeのセキュリティ対策は、単一の設定で完結するものではありません。パーミッションモードの適切な選択、サンドボックスによるOS レベルの隔離、APIキーの厳格な管理、Hookによるガードレールの設定、そしてクラウドプロバイダのセキュリティ機能の活用。これらの多層防御を組み合わせることで、初めて企業利用に耐えうるセキュリティレベルが実現します。

筆者が金融系の現場で学んだことの一つに、「セキュリティは最も弱い箇所の強度で決まる」という原則があります。パーミッションを厳格に設定しても、APIキーがハードコードされていれば意味がありません。VPC内に閉じた環境を構築しても、監査ログを取得していなければインシデント発生時に原因を追跡できません。

Claude Codeは開発生産性を大幅に向上させる強力なツールです。しかし、その強力さゆえに、セキュリティへの配慮なしに導入すると、取り返しのつかないリスクを抱えることになります。本記事で解説したチェックリストを活用し、自社の環境に合わせたセキュリティ設計を行ったうえで、Claude Codeの恩恵を最大限に享受してください。

導入に際してセキュリティ設計のご相談が必要な場合は、お気軽にお問い合わせください。