会社情報
採用情報
お問い合わせ
Article

社用スマホの管理とトラブル対応マニュアル

高田晃太郎
社用スマホの管理とトラブル対応マニュアル

モバイル関連のインシデントは、従業員1,000人規模の企業で年間数件から数十件に達することが一般に報告されています。企業のモバイル端末でも紛失・盗難が一定割合で発生することは各種調査で広く示されており³。交通機関の遺失物統計では携帯電話が例年上位を占め¹²、ヒューマンエラーやフィッシングに起因する事案も少なくありません。公開されたレポートやベンダー資料を俯瞰すると、単一端末の紛失でもアカウント不正利用や認証情報の流出が連鎖した場合に対応コストが増大し得る現実が見えてきます⁴。にもかかわらず、社用スマホ（モバイルデバイス）の運用が「配布」「回収」「再配布」という事務手順にとどまり、ゼロトラストの文脈での整合やインシデント初動の自動化（条件付きアクセスやセッション取り消し等）が後回しになる状況は珍しくありません。

本稿では、CTO視点で、社用スマホ運用を経営と現場の橋渡しとして再設計する道筋を提示します。モバイルデバイス管理（MDM: Mobile Device Management）とID基盤（SSO/ディレクトリ）の統合、COPE/BYODの方針決定、遠隔ワイプ（選択的/完全）の実装、そしてSLO・KPIによる継続運用までを、具体的なコマンドやAPI例とともに解説します。IT部門だけでなく現場管理者にも役立つ、実務に直結する内容を意図しています。

社用スマホ管理の現実と前提条件を揃える（MDM・ゼロトラストの基礎）

最初に確認したいのは、社用スマホの分類と責任分界です。会社支給で業務専用のCOBO（Corporate-Owned, Business-Only）、個人利用を許容するCOPE（Corporate-Owned, Personally Enabled）、個人端末を業務利用するBYOD（Bring Your Own Device）は、同じ「スマホ」でもデータ保護レベルとプライバシーの扱いが異なります。COBOでは端末全体の管理権限が企業側にあり、初期化（完全ワイプ）や所在追跡の選択肢が広がります。COPEは業務と私用の境界をポリシーで制御し、選択的ワイプ（業務データのみ消去）が前提です。BYODは端末本体ではなく業務アプリとデータに管理境界を置く設計で、アプリ保護ポリシーやコンテナ化が主軸になります⁵。

ゼロトラスト（境界ではなく継続的検証を重視）の観点では、デバイスはアイデンティティと並ぶ信頼根拠です。端末の整合性、暗号化、スクリーンロック、OSバージョン、脱獄・root化の有無などを評価し、コンプライアンスを満たしたものだけに業務データへのアクセスを許可するのが基本線です⁵。IDフェデレーション（SSO）はSaaSと統合し、条件付きアクセス（状況に応じた許可/拒否）で「準拠端末かつ強固な多要素認証（MFA）」を満たさない要求を弾きます。MDMはデバイス状態の観測と設定適用、ID基盤はアクセスポリシー評価という役割分担を明確にすると、設計の衝突が減り、運用判断も単純化します。

もうひとつの前提はサプライチェーンです。Apple Business ManagerやAndroid Zero-touch/Device Ownerによる自動デバイス登録は、出荷段階から端末を企業テナントにひも付け、初回起動時に自動で管理下に置きます。箱を開けた瞬間から企業構成が適用されるため、野良初期設定やローカルアカウント逸脱を防ぎ、紛失時の遠隔ロックやワイプ成功率を高めます。回線側ではeSIMの一元管理が有効で、紛失や退職対応での回線停止と端末制御を同時に進められます。

基本ポリシーを言語化し仕様に落とす

運用事故の多くは、方針が文章で定義されていないことに起因します。採用する管理モデル（COBO/COPE/BYOD）、OSアップデートの最短適用期限、紛失時の初動SLO、誰が「選択的ワイプ」を実行できるのか、回線停止とアカウント停止の優先順位などを、ポリシーとランブック（手順書）に落とし込みます。合意した文書があれば、夜間や休日のオンコール時でも迷いが減ります。プライバシーの扱いも明記し、BYODやCOPEではGPSや通話履歴など私的情報を収集しないことを約束しておくと、従業員体験を損なわず準拠率を上げられます⁵。ここでSLO（Service Level Objective: 目標水準）やKPI（Key Performance Indicator: 重要指標）の定義を先に置くと、後段の自動化やダッシュボード設計がぶれません。

実装ガイド：MDMとIDの統合で現場を回す

実装では、MDMの機能を最小構成から積み上げます。暗号化と画面ロックは必須で、iOSはデータ保護クラス（FileVaultはmacOSの機能）、Androidは端末暗号化と強度の高いスクリーンロック（PIN/パスワード/生体認証の組み合わせ）を前提にします⁵。証明書はSCEP/PKCS（証明書配布プロトコル）で端末やアプリに配布し、Wi‑FiやVPN、証明書ベースのEAP-TLS認証へ接続させます。ID基盤側では条件付きアクセスでコンプライアンス要求を定義し、非準拠端末にはメールやストレージへのアクセスを遮断します。以下に、運用でそのまま使えるコマンドやAPIの例を示します。

# PowerShell: Intune 端末の選択的ワイプ（アプリと企業データのみ）
Import-Module Microsoft.Graph.Intune
Import-Module Microsoft.Graph.Authentication

try {
  Connect-MgGraph -Scopes "Device.ReadWrite.All,Directory.AccessAsUser.All" | Out-Null
  $deviceId = "<AzureADDeviceId>"  # Azure AD の deviceId
  # 管理対象モバイルの wipe (keepEnrollmentData: $true で選択的)
  $uri = "https://graph.microsoft.com/beta/deviceManagement/managedDevices/$deviceId/wipe"
  $body = @{ keepEnrollmentData = $true; keepUserData = $false; useProtectedWipe = $true } | ConvertTo-Json
  Invoke-MgGraphRequest -Method POST -Uri $uri -Body $body -ContentType 'application/json'
  Write-Host "Selective wipe requested for $deviceId"
} catch {
  Write-Error ("Wipe failed: {0}" -f $_.Exception.Message)
}

Google Workspace 管理下のAndroid端末に対しては、Admin SDKのMobiledevices APIでアクションを実行します。選択的ワイプにより業務アカウントのデータだけを削除し、個人領域は保持できます。

# curl: Google Admin SDK で Android 端末を選択的ワイプ
ACCESS_TOKEN="<OAuth2Token>"
CUSTOMER_ID="my_customer"
RESOURCE_ID="<resourceId>"   # 事前に一覧APIで取得

curl -s -X POST \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"action":"account_wipe"}' \
  "https://admin.googleapis.com/admin/directory/v1/customer/$CUSTOMER_ID/devices/mobile/$RESOURCE_ID/action" \
  | jq .

条件付きアクセスの自動化も効果的です。Microsoft GraphのPoliciesエンドポイントを使えば、準拠端末以外からのメールとストレージへのアクセスを即時に遮断できます。緊急時フラグを持たせ、解除までの期間限定ポリシーとして作る運用も現実的です。

# PowerShell: 準拠端末以外を一時的にブロックする条件付きアクセス
Import-Module Microsoft.Graph.Beta.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$policy = {
  "displayName": "Emergency - Block Noncompliant Mobile",
  "state": "enabled",
  "conditions": {
    "clientAppTypes": ["mobileAppsAndDesktopClients"],
    "platforms": {"includePlatforms": ["iOS","android"]},
    "devices": {"deviceFilter": {"mode": "exclude","rule": "device.isCompliant -eq true"}}
  },
  "grantControls": {"operator": "OR","builtInControls": ["block"]}
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies" -Body $policy -ContentType 'application/json'

Android EnterpriseのWork ProfileやDevice Ownerでは、ポリシーをJSONで定義して配信できます。デバッグ無効化、スクリーンロック要件、クリップボード制限などの基礎を固めると、データ漏えい経路を減らせます。

{
  "passwordRequirements": {
    "passwordMinimumLength": 8,
    "passwordQuality": "ALPHANUMERIC"
  },
  "debuggingFeaturesAllowed": false,
  "screenCaptureDisabled": true,
  "keyguardDisabledFeatures": ["DISABLE_FINGERPRINT","DISABLE_SMART_LOCK"],
  "usbFileTransferDisabled": true
}

端末の在庫と準拠状況を日次で取得し、ダッシュボードに流すと遅延やドリフト（設定のズレ）が可視化されます。以下はIntune管理デバイスのページング取得例です。

# PowerShell: Intune 管理端末のインベントリ収集
Import-Module Microsoft.Graph.DeviceManagement
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$uri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$top=100"
$devices = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $devices += $resp.value
  $uri = $resp.'@odata.nextLink'
}
$devices | Select-Object id, deviceName, operatingSystem, complianceState | Export-Csv devices.csv -NoTypeInformation

配布と回収の動線を自動化する

Apple Business Managerやゼロタッチ登録を使った自動配布に、配送業者の到着通知とセットアップガイドのメールを紐付けると、ITを介さず初期化から業務開始までを現場で完結できます。退職時は、IDの無効化と選択的ワイプ、eSIM停止、資産台帳更新を一連のワークフローとして自動実行すると、ヒューマンエラーとリードタイムを削減できます。SaaSのアカウント無効化は端末ワイプより即時にデータ保護の効果が出るため、優先順位として先にトリガーする設計が安全です。

トラブル対応ランブック：初動から復旧まで（インシデント対応）

よくあるケースは、紛失・盗難、故障・物理破損、SIMや回線のトラブル、マルウェアや不審アプリ、そしてMFAロックアウト（多要素認証でログインできない状態）です。共通する原則は、被害の拡大を止め、事実を確定させ、業務を継続する順序で思考すること。初動では、本人確認を行い、位置情報の追跡が許容されるモデルか方針と照合し、即座にID側でセッション取り消しを実行します。続けて選択的ワイプまたは完全ワイプを実施し、eSIMや回線の停止で外部との通信も遮断します。BYODやCOPEでは選択的ワイプが原則で、COBOのときのみ完全初期化を許容する、といった分岐を文書で固定しておくと判断がぶれません⁵。

メール、ストレージ、社内アプリのトークンを無効化するには、ID基盤のセッション取り消しを自動化します。以下はAzure ADのサインイン無効化とセッション取り消しの例です。

# PowerShell: ユーザーのセッション取り消しとサインイン無効化
Import-Module Microsoft.Graph.Users
Connect-MgGraph -Scopes "User.ReadWrite.All"

$userId = "<user-upn-or-id>"
Invoke-MgInvalidateUserRefreshToken -UserId $userId
Update-MgUser -UserId $userId -AccountEnabled:$false

インシデントからの学習には検知の可視化が欠かせません。モバイル由来の不審サインインや異常な端末特性の急増を、ログ分析で拾い上げます。Microsoft 365 DefenderやSentinelを使うなら、Kusto Query Language（KQL）でモバイル特性に注目します。

// KQL: モバイルプラットフォームからの高リスクサインイン
SigninLogs
| where DeviceDetail.operatingSystem has_any ("iOS","Android")
| where RiskLevelAggregated in ("high","medium")
| summarize count() by UserPrincipalName, bin(TimeGenerated, 1h)
| order by count_ desc

物理破損や故障では、端末交換までの業務継続をどう担保するかが鍵です。短期貸与端末をあらかじめ在庫として持ち、ゼロタッチで直ちに業務プロファイルを適用できる体制を用意しておくと、店舗や現場のダウンタイムを数時間以内に抑えられます。MFAロックアウトのような本人起因の障害は、セルフサービス復旧を整えることで一次対応を大幅に減らせます。回復コードの配布、プッシュ通知以外の二要素手段、ヘルプデスク営業時間外の回復フローを事前に用意しておくと、夜間のオンコール負荷が下がります。

選択的ワイプと完全ワイプの線引き

選択的ワイプは業務データとアプリのみを消去し、個人領域は残す手段です。COPEやBYODでは基本的にこちらを使い、従業員体験と法的配慮を両立させます。完全ワイプはCOBOや重大インシデントのときだけに限定し、発動条件と承認プロセスを文書化します。監査に備え、誰がいつどの端末に何を実行したかの証跡はMDMとチケッティングの両方に残すと、情報セキュリティ委員会や労務のレビューにも耐えます⁵。

運用の継続改善：SLO、KPI、コスト最適化

運用は回して計測することで強くなります。SLOは、紛失報告からセッション取り消し完了までを15分以内、選択的ワイプのリクエスト発行までを30分以内、端末交換が必要な場合の業務再開までを同営業日内、といった具合に時間で定義します。KPIはコンプライアンス準拠率、OSアップデートの遅延分布、ワイプ成功率、セルフサービス復旧率、インシデント当たりの平均対応時間などが有効です。これらをダッシュボードで可視化し、四半期ごとに閾値を見直すと、現実的な目標と現場の改善が同じ方向を向きます。

費用対効果の面では、eSIM集中管理による回線停止の迅速化、グローバルローミングの上限制御、端末更新サイクルの最適化が効きます。MDMとIDの自動化により、配布から稼働までのリードタイム短縮には大きな改善余地があり、ヘルプデスクの一次対応件数もセルフサービスの整備により目に見えて減少します。現場の負担は削りつつ、監査対応では証跡の完全性を高められるため、セキュリティと生産性のトレードオフを小さくできます。

最後に、運用のボトルネックは人ではなく手順にあることが多い、と肝に銘じたいところです。ワイプ権限の集中や承認フローの多段化が初動の遅延を招くなら、条件付きアクセスによる自動ブロックとセッション取り消しを優先し、端末のハードワイプは後工程に送る再設計が有効です。ポリシーの即時性で守りを固め、端末交換や再配布はユーザー体験を損なわないよう非同期に進める。この二層構造こそが、変化の速い現場に適応できるスマホ運用のコアとなります。

まとめ：実装と運用を往復して強くする

社用スマホの管理は、技術的にも組織的にも積み重ねのゲームです。MDMとIDの統合で守りの基盤を作り、COPEやBYODの方針を文書化し、選択的ワイプと完全ワイプの線引きを明確にする。紛失・盗難・故障・MFAロックなど現実的なトラブルには、セッション取り消しと条件付きアクセスの自動化で被害拡大を止め、交換や再配布はユーザー体験を損なわないよう段取りする。SLOとKPIで結果を測り、四半期ごとに改善を重ねれば、対応は短く、業務は止まりにくくなります。

次に取り組むと良いのは、緊急時の条件付きアクセス自動適用、日次のコンプライアンス可視化、そしてセルフサービス復旧の拡充です。あなたの組織では、最初に短縮したい時間はどこでしょうか。初動の15分なのか、交換端末の到着までの半日なのか。答えを決め、計測し、また改善していきましょう。

参考文献

  1. 警視庁 拾得物等取扱状況（携帯電話等の遺失・拾得に関する統計） https://www.keishicho.metro.tokyo.lg.jp/about_mpd/jokyo_tokei/kakushu/kaikei.html
  2. nippon.com「『携帯電話なくした』1日600台」 https://www.nippon.com/ja/japan-data/h01962/
  3. Security NEXT「企業におけるモバイル端末の紛失・盗難発生に関する調査」 https://www.security-next.com/032446
  4. ASCII.jp「年次調査『情報漏えいのコストに関するレポート』サマリ（IBM Security）」 https://ascii.jp/elem/000/004/024/4024761/
  5. 東京都「東京サイバーセキュリティ強靭化推進事業 ハンドブック 2024（MDM・BYODの考え方と対策）」 https://shanaitaisei.metro.tokyo.lg.jp/Tokyo_CyberSecurity_HandBook_2024_Text/17/page-17-3.html