# Junify > Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 このサイトの日本語ページは、同じ内容の Markdown でも配信しています。各ページの URL に `.md` を付けるか、 `Accept: text/markdown` を付けてリクエストしてください。 ## ページ - [Junify — アカウントを渡さず、仕事を任せる](https://www.junify.jp/index.md): 日本語トップページ。解決する問題、導入後の状態、仕組み、現場別の入口。 - [BPO・運用代行向けのご案内](https://www.junify.jp/bpo.md): 共有・代理アカウントの課題、仕組み、既存の道具との違い、料金、導入の流れ、FAQ。 - [30 分デモを予約する](https://www.junify.jp/bpo/demo.md): デモで扱う内容と、申し込みに必要な項目。 - [資料をダウンロード](https://www.junify.jp/bpo/download.md): ご説明資料(PDF)の内容と入手方法。 - [医療・ヘルスケア向けのご案内](https://www.junify.jp/healthcare.md): スポット勤務の医師・私物端末・委託先を含む診療システムのアクセス管理。導入後の状態、仕組み、医療の現場で効くこと、FAQ。 - [クラウド運用・特権 ID向けのご案内](https://www.junify.jp/privileged-access.md): 管理コンソール・管理者用 ID のアクセス管理。担当者にパスワードを渡さず、誰が・いつ・どのコンソールに入ったかを一人ひとり記録。IP 制限も管理画面の設定もそのまま。いまの運用、仕組み、導入後の状態、FAQ。 - [SNS・広告・EC 運用代行向けのご案内](https://www.junify.jp/marketing-ops.md): クライアントから預かった SNS 公式・広告・EC モールのアカウントを、担当者にパスワードを渡さずに使ってもらう。いまの運用、仕組み、導入後の状態、自社のアカウントの方への案内、FAQ。 - [人事・採用向けのご案内](https://www.junify.jp/hr.md): 採用媒体と人事系サービスの共有アカウントを、担当者ごとの入口と記録に。導入後の状態、仕組み、人事システム連携、FAQ。 - [社内の共有アカウント向けのご案内](https://www.junify.jp/shared-accounts.md): 部門に残る共有アカウントを、廃止せずに本人単位の入口と記録に。SSO との併用、IdP との違い、FAQ。 - [Junify の仕組み](https://www.junify.jp/product.md): パスワードを渡さずにログインさせる仕組み。3 ステップの使い方、管理者ができること、端末の条件、既存の IdP との共存。 - [作っている人たち](https://www.junify.jp/about.md): 創業ストーリー(楽天の 11 番目の社員として技術部門を率いた元 CTO が 2016 年に設立)、チーム、日本のお客様への対応、信頼の根拠、会社概要。 - [お問い合わせ](https://www.junify.jp/contact.md): お問い合わせフォームの項目と、メールでの連絡先。 ## Junify の使い方 - [招待メールから Junify に参加する](https://www.junify.jp/help/member/join-via-email.md): 届いた招待メールから、スマートフォンの Junify のアプリで登録を済ませ、招待された組織に参加できます。 - [6 桁のコードで Junify に参加する](https://www.junify.jp/help/member/join-via-code.md): 管理者から受け取った 6 桁のコードを使い、スマートフォンの Junify のアプリで登録を済ませて、招待された組織に参加できます。 - [Junify からのメールがスパムフィルターにかかってしまう場合の対処方法](https://www.junify.jp/help/member/allow-junify-email.md): Junify からの重要な認証コードなどのメールが、G-Suite のスパムフィルターによって、スパムのフォルダに振り分けられ、オペレーションがスムーズに進まない場合があります。 - [勤務の開始と終了を記録する](https://www.junify.jp/help/member/clock-in-out.md): スマートフォンの Junify のアプリのホーム画面で、仕事を始めたときと終えたときを勤務の記録に残せます。 - [勤務中の位置情報を共有する](https://www.junify.jp/help/member/share-location.md): スマートフォンの Junify のアプリに位置情報の利用を許可して勤務を始めると、勤務中の居場所を組織に共有できます。 - [PCで Junify にログインをする](https://www.junify.jp/help/member/log-in-on-pc.md): パソコンで Junify にログインするには、初期設定を済ませた Junify アプリと、Chrome ブラウザを用意してください。 - [カードからアプリにログインする](https://www.junify.jp/help/member/card-login.md): Junify の画面で仕事のアプリのカードを押すと、パスワードを自分で入れずに、そのアプリにログインできます。 - [スマートフォンでカードからアプリにログインする](https://www.junify.jp/help/member/open-application-card.md): スマートフォンの Junify のアプリで仕事のアプリのカードをタップすると、パスワードを自分で入れずに、そのアプリにログインできます。 - [組織の情報と設定を確かめる](https://www.junify.jp/help/admin/set-up-organization.md): 組織の名前や連絡先と、組織全体にかかる Junify の設定が、今どうなっているかを確かめられます。 - [メールでメンバーを招待する](https://www.junify.jp/help/admin/invite-member.md): 新しく入った人に招待のメールを送り、スマートフォンの Junify のアプリで登録してもらえるようにします。 - [仕事で使うアプリを Junify に登録する](https://www.junify.jp/help/admin/register-app.md): 仕事で使うアプリを Junify に登録し、メンバーに渡すカードを作れるようにします。 - [アプリのカードを作ってメンバーに渡す](https://www.junify.jp/help/admin/assign-card.md): アプリのカードを作って使う人を選ぶと、その人は Junify の画面に出るカードから、そのアプリにログインできます。 - [自分のグループのメンバーを見る](https://www.junify.jp/help/group-leader/view-supervised-groups.md): 自分がグループリーダーを務めるグループのメンバーを一覧で見て、一人ずつ登録内容を確かめられます。 - [バックアップ用のメールアドレスを登録する](https://www.junify.jp/help/member/register-backup-email.md): スマートフォンの Junify のアプリに個人のメールアドレスを登録し、アカウントを新しいスマートフォンに戻すためのメールを受け取れるようにします。 - [スマートフォンを忘れた／紛失の場合の緊急手段](https://www.junify.jp/help/member/use-backup-login.md): Junify アプリを入れたスマートフォンを一時的に忘れた、Junify アプリをうっかり削除してしまった、スマートフォンを紛失した、という場合に、普段お使いのパソコンから緊急でログインする方法を紹介します。 - [Chrome 拡張機能の削除／再インストール](https://www.junify.jp/help/member/reinstall-extension.md): Junify をパソコンでお使いの場合は Chrome ブラウザにおいて拡張機能を利用します。 - [新しいスマートフォンに自分のアカウントを戻す](https://www.junify.jp/help/member/restore-account.md): 管理者から受け取った 6 桁のコードで、これまでのアカウントを新しいスマートフォンの Junify のアプリに戻せます。 - [Junify アプリの初期化を行う](https://www.junify.jp/help/member/reset-app.md): 一度 Junify アプリを利用していた端末を他人に渡して別の Junify アカウントとして使う場合には、端末に残されている情報を初期化する必要があります。 - [アプリの設定とカード、アカウントを確かめる](https://www.junify.jp/help/admin/manage-application-profile.md): 登録したアプリを開き、ログインの方法などの設定と、そのアプリのカードとアカウントを確かめられます。 - [共有アカウントの ID とパスワードを設定する](https://www.junify.jp/help/admin/set-up-account.md): 共有アカウントに ID とパスワードを保存しておくと、カードを渡した人はそのアプリにログインできます。アプリのパスワードが変わったときも、同じ手順で入れ直せます。 - [メンバーのアカウントのパスワードを会社で管理する](https://www.junify.jp/help/admin/control-passwords.md): メンバーのアカウントの ID とパスワードを、メンバーではなく会社の管理者が入れて管理するようにできます。 - [決めた場所からだけアプリを開けるようにする](https://www.junify.jp/help/admin/set-access-rules.md): アプリを開いてよい場所を決め、その場所にいるメンバーだけが開けるようにします。会社のネットワークからだけ開けるようにもできます。 - [Junify × Google Workspace SAML連携設定マニュアル](https://www.junify.jp/help/admin/set-up-google-workspace-saml.md): 本マニュアルでは、JunifyをIdPとし、Google Workspaceの新しい「SAMLプロファイル」機能を使用してSSO（シングルサインオン）を行うための設定手順を解説します。 - [電話番号でメンバーを招待する](https://www.junify.jp/help/admin/invite-member-by-phone.md): 新しく入った人を電話番号で招待します。画面に出る 6 桁のコードを伝えると、その人はスマートフォンの Junify のアプリで登録できます。 - [メンバーの退職処理をする](https://www.junify.jp/help/admin/offboard-member.md): 組織を離れる人を、Junify のメンバーから外します。 - [メンバーをグループに加える](https://www.junify.jp/help/admin/change-member-groups.md): メンバーを新しいグループに加えて、そのグループに渡しているアプリのカードも使えるようにします。 - [新しいスマートフォンにメンバーのアカウントを戻す](https://www.junify.jp/help/admin/restore-member-account.md): メンバーが新しいスマートフォンの Junify のアプリで、これまでのアカウントを続けて使えるようにします。 - [メンバーの情報を直す](https://www.junify.jp/help/admin/edit-member.md): メンバーの名前や電話番号、社員コードなどの登録内容を直して、保存できます。 - [グループリーダーを決める](https://www.junify.jp/help/admin/assign-group-leader.md): グループをまとめる人を選んで、グループリーダーにできます。 - [期限が切れた招待を送り直す](https://www.junify.jp/help/admin/resend-invitation.md): 招待の期限が切れ、まだ登録を済ませていない人に、招待をもう一度送ります。 - [スマートフォンを忘れたメンバーにログイン用のリンクを送る](https://www.junify.jp/help/admin/send-backup-login.md): スマートフォンを忘れたメンバーの個人用のメールアドレスに、一時的にログインできるリンクを送ります。メンバーは、スマートフォンがなくても勤務を記録できるようになります。 - [メンバーの位置情報を見る](https://www.junify.jp/help/admin/review-member-locations.md): メンバーが勤務中にどこにいて、どう移動したかを、時刻の順に確かめられます。登録した場所ごとに、いまその中にいる人数も分かります。 - [メンバーの勤務の記録を見る](https://www.junify.jp/help/admin/review-work-records.md): メンバーが何時に勤務を始め、何時に終えたかを、カレンダーで日ごとに確かめられます。 - [自分のグループのメンバーの位置情報を見る](https://www.junify.jp/help/group-leader/review-team-locations.md): 自分がリーダーを務めるグループのメンバーが勤務中かどうかと、いまいる場所を確かめられます。メンバーのその日のルートを、1 つの地図で見比べることもできます。 - [自分のグループのメンバーの勤務の状況を見る](https://www.junify.jp/help/group-leader/review-team-work-status.md): 自分がリーダーを務めるグループのメンバーが、いま勤務中かどうかを一覧で確かめられます。メンバーごとの勤務の記録も、月のカレンダーで見られます。 - [勤務時間の修正の申請を承認する](https://www.junify.jp/help/group-leader/approve-edit-request.md): メンバーから届いた勤務時間の修正の申請を、スマートフォンの Junify のアプリで確かめて承認できます。 - [アプリでの作業の録画をオンにする](https://www.junify.jp/help/admin/enable-recording.md): メンバーが Junify のカードからアプリを使ったときの作業を、録画するように設定できます。 - [作業の録画を見返す](https://www.junify.jp/help/admin/review-recording.md): アプリでの作業の録画を開き、誰がいつどのアプリで作業したかと、そのときの画面の動きを確かめられます。 - [誰がいつ何をしたかを記録から調べる](https://www.junify.jp/help/admin/search-events.md): 見たい期間とカテゴリで記録を絞り込み、誰がいつ何をしたかを一覧で確かめられます。 - [メンバーが使っているサービスを確かめる](https://www.junify.jp/help/admin/review-unapproved-apps.md): サービスごとに何人が使い、何回表示されたかを一覧で見て、そのサービスを誰が使ったかを確かめられます。 - [全体告知を書いて公開する](https://www.junify.jp/help/admin/post-announcement.md): 伝えたいことを全体告知として書いて公開し、組織のメンバーに知らせられます。 - [組織アカウント管理者を別の人に替える](https://www.junify.jp/help/admin/change-organization-owner.md): Junify の責任者が替わるときに、組織アカウント管理者を後任のメンバーに替えられます。 - [[初期設定] Zoomクライアントを設定する（パソコン／SAML認証）](https://www.junify.jp/help/member/set-up-sso.md): Junify は様々なアプリケーションと連動をして動きます。 - [Zoomで会議に参加する(パソコン)](https://www.junify.jp/help/member/join-meeting.md): パソコン上で Zoom クライアントを使用して会議を開催します。 - [Zoomで会議を開催する(パソコン)](https://www.junify.jp/help/member/host-meeting.md): パソコン上で Zoom クライアントを使用して会議を開催します。 - [Zoom 会議を予約して開催する （パソコン）](https://www.junify.jp/help/member/schedule-meeting.md): Junify は様々なアプリケーションと連動をして動きます。 - [[初期設定] Zoom アプリで SAML を用いた Junify との接続方法（スマートフォン）](https://www.junify.jp/help/member/set-up-sso-on-phone.md): [初期設定] Zoom アプリで SAML を用いた Junify との接続方法（スマートフォン） - [Zoom app でミーティングに参加する（スマートフォン）](https://www.junify.jp/help/member/join-meeting-on-phone.md): Zoom app を用いて会議に参加します。 - [Zoom app で会議を開催する（スマートフォン）](https://www.junify.jp/help/member/host-meeting-on-phone.md): Zoom app を用いて会議を開催する方法です。 - [Zoom app での会議の事前予約・開催・削除をする方法（スマートフォン）](https://www.junify.jp/help/member/schedule-meeting-on-phone.md): Zoom app を用いて会議を事前に予約し、開催をする方法です。 ## アカウント管理の基礎知識 - [共有アカウントの管理](https://www.junify.jp/guides/shared-accounts.md): 共有アカウントは、1 つの ID とパスワードを複数人で使う状態です。個人に分けられるものは分け、残るものは誰が使ったかを残せる方法で管理します。 - [Google スプレッドシートにパスワードはかけられるか](https://www.junify.jp/guides/shared-accounts/google-sheets-password-protection.md): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](https://www.junify.jp/guides/shared-accounts/password-length-recommendations.md): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](https://www.junify.jp/guides/shared-accounts/personal-password-manager-at-work.md): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 - [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](https://www.junify.jp/guides/shared-accounts/sharing-chatgpt-accounts-at-work.md): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 - [ブラウザーのパスワード保存を業務で使ってよいか](https://www.junify.jp/guides/shared-accounts/browser-saved-passwords-at-work.md): 個人アカウントのパスワードを、会社が管理するブラウザーの設定で、1 人が使う端末に限って保存するなら選択肢になります。共有アカウント、私物端末、個人アカウントへの同期が絡む場合は避けます。管理者の設定で保存を止められます。 - [共有アカウントを複数人で安全に使う方法の比較](https://www.junify.jp/guides/shared-accounts/comparison-of-shared-account-methods.md): 手作業、パスワードマネージャーの共有、ID 管理サービスによる代わりの入力、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [退職者が出るたびにパスワードを変える運用の限界](https://www.junify.jp/guides/shared-accounts/password-change-on-every-departure.md): 一度知られたパスワードは取り消せないため、退職のたびに変える運用には理由があります。限界は、変更後の配り直しと保存先の更新にかかる手間と、誰が知っているかの一覧がないまま起きる抜け漏れです。 - [パスワード管理規程のテンプレートと書き方](https://www.junify.jp/guides/shared-accounts/password-policy-template.md): 規程に入れる項目は、適用範囲、パスワードの条件、保管、共有の禁止と例外、共有アカウント、二段階認証、変更、退職時の手続き、違反時の扱い、見直しの 10 項目です。各条を IPA と個人情報保護委員会の要求に対応づけ、文例を示します。 - [パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方)](https://www.junify.jp/guides/shared-accounts/periodic-password-change.md): NIST SP 800-63B は、サービス側が利用者に定期変更を求めないよう定め、変更を必須にするのは盗まれた証拠があるときとしています。複数人で使う共有アカウントは、知っている人が変わるたびに変更が要ります。 - [共有アカウントの棚卸しの手順と台帳の項目](https://www.junify.jp/guides/shared-accounts/shared-account-inventory.md): 共有アカウントの棚卸しは、サービスごとに誰がパスワードを知っていて誰が使えるかを一覧にする作業です。見つけ方、台帳の項目、分ける・残す・廃止するの判定、更新のきっかけを順に示します。 - [共有アカウントの二段階認証を複数人で使うときの問題と選択肢](https://www.junify.jp/guides/shared-accounts/sharing-two-step-verification.md): 共有アカウントの二段階認証は、コードが 1 人のスマホにしか出ないか、登録用の QR コードを配って全員が出せるかのどちらかになります。方式ごとに起きる問題と、不在と退職に備える選択肢を整理します。 - [パスワードをスプレッドシートで管理する会社が最初に直すこと](https://www.junify.jp/guides/shared-accounts/spreadsheet-password-management.md): 最初に直すのは、そのシートを開ける人の範囲です。次に台帳としての項目を整え、最後にパスワードの値だけを別の保管場所へ移します。一覧としてのスプレッドシートは残せます。 - [Slack・メールでパスワードを送るのをやめる方法](https://www.junify.jp/guides/shared-accounts/stop-sending-passwords-in-chat.md): 送ったパスワードは検索で見つかり、転送や書き出しで広がり、端末と退職者のアカウントに残ります。やめるには、先に別の渡し方を用意し、そのうえで本文に書かないルールを決めます。 - [パスワードマネージャーとは](https://www.junify.jp/guides/shared-accounts/what-is-password-manager.md): パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。 - [共有アカウントとは](https://www.junify.jp/guides/shared-accounts/what-is-shared-account.md): 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。 - [二段階認証(二要素認証)とは](https://www.junify.jp/guides/shared-accounts/what-is-two-step-verification.md): 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。 - [共有アカウントを個人アカウントに分けられないケースの整理](https://www.junify.jp/guides/shared-accounts/when-accounts-cannot-be-split.md): 原則は 1 人 1 アカウントです。それでも、サービスがアカウントを 1 つしか持てない、公式アカウントそのもの、管理者アカウントが 1 つ、外部の人に発行できない、といった場合は共有が残ります。残すものに何を求めるかを整理します。 - [運用代行のクライアントアカウント管理](https://www.junify.jp/guides/agency-accounts.md): 預かり方は権限付与・ID とパスワードの共有・アクセス管理ツールの 3 つ。違いは「誰が使ったかが残るか」と「担当交代時に何をするか」に出ます。 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](https://www.junify.jp/guides/agency-accounts/agency-security-policy-for-clients.md): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](https://www.junify.jp/guides/agency-accounts/qoo10-au-pay-market-store-access.md): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](https://www.junify.jp/guides/agency-accounts/sns-scheduling-tools-client-accounts.md): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 - [運用代行会社がクライアントとの契約に入れておくアカウントの条項](https://www.junify.jp/guides/agency-accounts/account-clauses-for-service-providers.md): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 - [Amazon セラーセントラルのユーザー権限と、運用代行会社への渡し方](https://www.junify.jp/guides/agency-accounts/amazon-seller-central-user-permissions.md): ヘルプはログイン情報を誰とも共有しないよう求めています。大口出品なら、社内の担当者は「従業員の管理」から招待し、運用代行会社はサービスプロバイダーとして承認します。どちらもユーザー権限の画面から外せます。 - [クライアントのアカウントの二段階認証を運用チームで受けるには](https://www.junify.jp/guides/agency-accounts/client-two-step-verification-for-teams.md): 担当者ごとに招待してもらい、各自のアカウントの二段階認証で入る形に切り替えると、コードの受け渡しはなくなります。所有者のログインが残るアカウントは、受け取り先・予備のコード・使った人の記録をクライアントと決めます。 - [カスタマーサポート代行で、クライアントの Zendesk・Freshdesk に入るときのアカウントと権限](https://www.junify.jp/guides/agency-accounts/cs-outsourcing-helpdesk-access.md): オペレーター 1 人ずつ、代行会社が管理するアドレスでエージェントを作ってもらいます。Zendesk・Freshworks の契約は 1 つのログインの共用を認めていません。権限と範囲は受け持つ分に絞り、外れる人はクライアントが停止します。 - [EC 運営代行で、受注データや顧客データの書き出しをどう制限するか](https://www.junify.jp/guides/agency-accounts/ec-order-data-download-control.md): 書き出しの権限は要る担当者にだけ付けます。Shopify は注文と顧客の書き出しを個別に外せます。BASE は書き出しの App をスタッフが使えるか、画面で確かめます。外せない分は、置き場所・削除・記録の決まりで補います。 - [GA4 とタグ マネージャーの権限を代理店・制作会社に渡すとき](https://www.junify.jp/guides/agency-accounts/ga4-gtm-agency-access.md): GA4 はアカウントかプロパティの単位で閲覧者・編集者などの役割を、タグ マネージャーはコンテナ単位で編集・公開などの権限を渡します。管理者は持ち主の会社に残し、契約終了時は両方のユーザー一覧と Google 広告のリンクを確かめます。 - [Google ビジネス プロフィールのオーナーと管理者を、本部・店舗・運用代行会社でどう分けるか](https://www.junify.jp/guides/agency-accounts/google-business-profile-managers.md): 管理者も投稿・クチコミへの返信・営業時間の編集ができ、ユーザーの追加と削除、プロフィールの削除はオーナーだけです。メインのオーナー権限は本人しか譲れないので、本部が持てば、代行会社との契約が終わるときに代行会社の操作を待たずに済みます。 - [運用代行会社の ISMS・P マーク審査で、クライアントから預かったアカウントをどう説明するか](https://www.junify.jp/guides/agency-accounts/isms-pmark-for-agencies.md): 預かったアカウントは、ISMS では適用範囲に含める資産として、P マークでは受託した個人情報がある場所として扱うと読めます。審査では、アカウントの一覧、使える人、使った記録、外した記録、契約の約束を示します。 - [Microsoft 広告を代理店に任せるときの役割の付け方と外し方](https://www.junify.jp/guides/agency-accounts/microsoft-ads-agency-access.md): 担当者を 1 人ずつ招待する形と、クライアントの広告アカウントを代理店のマネージャー アカウントにつなぐ形の 2 つ。運用担当にはキャンペーンか標準を付けます。招待した人は 1 人ずつ削除し、リンクは解除すると代理店の全員が外れます。 - [在宅のオペレーターにクライアントの管理画面を使わせるとき、決めることと確かめること](https://www.junify.jp/guides/agency-accounts/remote-operators-client-admin-access.md): 決めるのは、在宅で扱うアカウント、使う端末、ログインの渡し方、端末に残してよいデータの 4 つです。確かめるのは端末の状態と、誰がいつ入ったかを後で示せるかです。管理画面に直接つなぐ形では、記録は媒体の側にしか残りません。 - [運用代行の作業記録を、クライアントにどう報告するか](https://www.junify.jp/guides/agency-accounts/reporting-work-records-to-clients.md): 媒体の操作履歴から日時・担当者・操作を抜き出して報告に添えます。媒体の履歴で担当者まで分からない共有 ID のアカウントは社内の作業記録で補い、各行がどちらに基づくかを書き分けます。 - [Yahoo!広告(現 LINEヤフー広告)を代理店や複数人で運用するときの権限付与](https://www.junify.jp/guides/agency-accounts/yahoo-ads-agency-access.md): 管理権限を持つ人が担当者のビジネス ID を招待し、管理・登録更新・参照の 3 種類から権限を選びます。代理店の MCC につないで任せる形もあります。どちらの形でもパスワードは渡さず、外すときは権限の削除かリンクの解除です。 - [YouTube チャンネルを社内の複数人や運用代行会社と運用するときの権限](https://www.junify.jp/guides/agency-accounts/youtube-channel-permissions.md): YouTube Studio の「チャンネルの権限」で、担当者のメールアドレスごとに管理者・編集者・閲覧者などの役割を付けて招待すれば、Google アカウントのパスワードを渡さずに任せられます。外すときは同じ画面でアクセス権を削除します。 - [クライアントのセキュリティチェックシートへの、運用代行会社の答え方](https://www.junify.jp/guides/agency-accounts/answering-security-questionnaires.md): 設問は個人情報保護委員会ガイドライン(通則編)別添の安全管理措置の項目に対応しています。現状をそのまま書き、共有 ID は管理方法まで書き、対応予定には期限と担当を添えます。 - [楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](https://www.junify.jp/guides/agency-accounts/ec-mall-store-admin-access.md): 楽天は担当者ごとの楽天 ID を店舗の管理者が承認し、Yahoo! はビジネスマネージャーでツール管理者が従業員のビジネス ID を登録します。どちらも担当者ごとに ID を持つ仕組みです。 - [「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型](https://www.junify.jp/guides/agency-accounts/explaining-account-handling-in-sales.md): 預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。 - [Google 広告の MCC(クライアント センター)で代理店アクセスを整理する](https://www.junify.jp/guides/agency-accounts/google-ads-mcc-agency-access.md): クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。 - [運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](https://www.junify.jp/guides/agency-accounts/handover-checklist.md): 交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。 - [LINE 公式アカウントを複数人・外部と運用するときの権限](https://www.junify.jp/guides/agency-accounts/line-official-account-permissions.md): 管理者が発行する認証用 URL で担当者ごとにメンバーを追加し、管理者か運用担当者の権限を持たせます。外部の運用代行会社も同じ形で追加でき、外すときはメンバーのリストから削除します。 - [Meta(Facebook・Instagram)のビジネスポートフォリオで代理店に権限を付与する仕組みと、できないこと](https://www.junify.jp/guides/agency-accounts/meta-business-portfolio-agency-access.md): クライアントのポートフォリオに担当者を「人」として招くか、代理店のポートフォリオを「パートナー」としてつなぎます。ページ・広告アカウント・Instagram ごとに、許す操作(タスク)を付けます。取り消しは所有者側の操作です。 - [Shopify・BASE などカート側のスタッフ権限と、運用代行会社への渡し方](https://www.junify.jp/guides/agency-accounts/shopify-base-staff-permissions.md): Shopify はスタッフの招待か、パートナー向けのコラボレーターアカウントで渡します。BASE は「スタッフ権限管理 App」でスタッフごとにメニュー単位の権限を付けられます。どちらもオーナーの ID は渡しません。 - [誤投稿・誤設定のあとに原因を追える運用と追えない運用](https://www.junify.jp/guides/agency-accounts/tracing-misposts.md): 報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。 - [運用代行におけるアカウントの預かりとは](https://www.junify.jp/guides/agency-accounts/what-is-delegated-account-access.md): クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。 - [権限付与(アカウントを共有しないアクセス)とは](https://www.junify.jp/guides/agency-accounts/what-is-delegated-permission.md): アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。 - [X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](https://www.junify.jp/guides/agency-accounts/x-tiktok-business-account-access.md): X は広告アカウントの権限(ロール)と、投稿や DM を任せる委任機能(X アカウント権限の付与)を別々に付けます。TikTok はビジネスセンターにメンバーかパートナーとして招きます。どちらもパスワードは渡しません。 - [委託先に自社のアカウントを使わせるときの管理](https://www.junify.jp/guides/outsourcing-access.md): 個人情報保護法が委託元に求めるのは委託先の監督で、アカウントの渡し方までは指定していません。渡し方は 3 つあり、違いは誰が使ったかの記録と、契約終了時の作業に出ます。 - [委託終了・担当交代時のアクセス回収チェックリスト](https://www.junify.jp/guides/outsourcing-access/access-recovery-at-contract-end.md): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](https://www.junify.jp/guides/outsourcing-access/building-a-security-questionnaire.md): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](https://www.junify.jp/guides/outsourcing-access/contract-clauses-for-accounts.md): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 - [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](https://www.junify.jp/guides/outsourcing-access/isms-supplier-relationships.md): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 - [委託先経由の情報漏えいで問われる責任(公開事例から)](https://www.junify.jp/guides/outsourcing-access/liability-in-contractor-breaches.md): 個人情報保護委員会の公表では、委託先で起きた漏えいでも、委託元が 25 条の委託先の監督の不備を指導されています(1 件は自社の安全管理措置の不備で勧告も)。問われたのは、確認の取り決めがない契約、監査や点検の不実施、再委託の未報告です。 - [副業人材・フリーランス・パートに社内アカウントを渡すときの線引き](https://www.junify.jp/guides/outsourcing-access/side-jobs-freelancers-part-timers.md): パート・アルバイト・派遣社員はガイドラインの「従業者」に含まれ、従業者の監督(24 条)の対象です。業務委託のフリーランスは委託先で、委託先の監督(25 条)の側です。副業人材は、自社との契約が雇用か業務委託かで分かれます。 - [再委託先のアクセスをどう把握するか](https://www.junify.jp/guides/outsourcing-access/subcontractor-access-visibility.md): 把握は 3 つの決まりで成り立ちます。再委託の事前報告に、再委託先の人が使う自社のアカウントを含めること。再委託先の人にも一人ずつ発行すること。自社のユーザー一覧と報告された名簿を定期的に突き合わせることです。 - [セキュリティチェックシートとは(委託元の側)](https://www.junify.jp/guides/outsourcing-access/what-is-security-questionnaire.md): 委託元が、委託先の安全管理措置(個人データを守る対策)を書面で確かめる質問票。ガイドラインが委託前に求める確認の手段の一つと読めます。設問は別添の項目に沿って作ります。 - [再委託とは](https://www.junify.jp/guides/outsourcing-access/what-is-subcontracting.md): 委託先が、受けた業務の全部または一部をさらに別の者に任せること。ガイドラインは、委託元が事前に報告を受けるか承認し、再委託先の安全管理措置まで確かめることが望ましいとしています。 - [委託先の監督とは](https://www.junify.jp/guides/outsourcing-access/what-is-supervision-of-contractors.md): 個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守る対策)が行われるよう確かめること(個人情報保護法 25 条)。ガイドラインは選定・契約・取扱状況の把握の 3 点を挙げています。 - [委託先が「共有 ID で作業しています」と答えたときの確認事項](https://www.junify.jp/guides/outsourcing-access/when-contractor-uses-shared-id.md): 確かめるのは 4 点です。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法です。答えられなければ、担当者ごとの発行に切り替える、アクセス管理ツールを挟む、業務範囲を絞る、のどれかを選びます。 - [管理者用アカウント(特権 ID)の管理](https://www.junify.jp/guides/privileged-access.md): 管理者用アカウント(特権 ID)は、サービスの設定や他の人の権限を変えられる強い権限の ID です。個人に分けられる権限は分け、残る共有の管理者アカウントは誰が使ったかを残せる形にします。 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](https://www.junify.jp/guides/privileged-access/aws-root-and-admin-accounts.md): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](https://www.junify.jp/guides/privileged-access/comparison-of-privileged-account-methods.md): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](https://www.junify.jp/guides/privileged-access/google-workspace-microsoft-365-admins.md): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 - [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](https://www.junify.jp/guides/privileged-access/idp-and-remaining-shared-admins.md): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 - [IT 全般統制(J-SOX)で管理者用アカウントについて問われること](https://www.junify.jp/guides/privileged-access/itgc-and-privileged-ids.md): 実施基準は「内外からのアクセス管理」を IT 全般統制の例に挙げ、評価は記録の閲覧や質問で行われます。用意するのは、管理者用アカウントの一覧、権限の付与・変更・削除の記録、利用の記録、定期的な見直しの記録です。 - [ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか](https://www.junify.jp/guides/privileged-access/non-saml-admin-consoles.md): まず公式ヘルプで、担当者ごとの ID を追加できるか、権限を分けられるかを確かめます。追加できるなら個人の ID にし、1 つしか作れないものは共有として貸出の記録、二段階認証の宛先、パスワードを変える場面を決めます。 - [管理者用アカウントの監査で示せるようにしておく記録](https://www.junify.jp/guides/privileged-access/privileged-access-audit-records.md): 公的な資料が求めるのは、誰が・いつ・どのアカウントで・何をしたかがつながる記録と、権限の付与・削除と見直しの記録です。金融庁、内閣官房、IPA の 4 つの文書は、改ざんの防止と定期的な点検も共通して求めています。 - [緊急用アカウント(ブレークグラス)とは](https://www.junify.jp/guides/privileged-access/what-is-break-glass-account.md): 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。 - [特権 ID 管理(PAM)とは](https://www.junify.jp/guides/privileged-access/what-is-pam.md): 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。 - [特権 ID(管理者用アカウント)とは](https://www.junify.jp/guides/privileged-access/what-is-privileged-id.md): 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。 - [医療・ヘルスケアのアカウント管理](https://www.junify.jp/guides/healthcare-access.md): 医療機関のアカウント管理で決めることは、使う人を確かめる方法、権限の付け方と外し方、誰が何をしたかの記録の 3 つです。水準は厚労省のガイドライン第 7.0 版が示しています。 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](https://www.junify.jp/guides/healthcare-access/clinic-saas-responsibility-split.md): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](https://www.junify.jp/guides/healthcare-access/medical-cyber-incident-account-response.md): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](https://www.junify.jp/guides/healthcare-access/online-eligibility-verification-terminal.md): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 - [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](https://www.junify.jp/guides/healthcare-access/staff-departure-account-shutdown.md): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 - [医療法に基づく立入検査で、サイバーセキュリティについて確認されること](https://www.junify.jp/guides/healthcare-access/medical-onsite-inspection-cybersecurity.md): 病院への立入検査は原則年 1 回です。サイバーセキュリティでは、厚労省のチェックリストの全項目に確認日と回答が書かれているかを見て、機器の台帳・連絡体制図・BCP・規程類は現物を確かめます。 - [厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](https://www.junify.jp/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts.md): 区分 2 の 7 項目(権限、不要なアカウント、パスワード 2 項目、二要素認証 2 項目、アクセスの記録)です。台帳を在籍者の一覧と照らし、記録を確かめた跡を残し、事業者が「対象外」とした項目は院内の担当を決めます。 - [医療情報システムの安全管理に関するガイドラインが定めるパスワードの桁数・変更・使い回し](https://www.junify.jp/guides/healthcare-access/password-rules-in-medical-guideline.md): 現行の第 7.0 版では、二要素認証を使うならパスワードは 8 桁以上で英数字を混ぜ、使わないなら 13 桁以上です。定期的な変更はどちらも不要で、システム間で使い回さないことは遵守事項です。 - [薬局・介護事業所のシステム(電子薬歴・介護記録・請求ソフト)のアカウント管理](https://www.junify.jp/guides/healthcare-access/pharmacy-care-facility-accounts.md): 薬局も介護事業者も厚労省の医療情報ガイドラインの対象です。職員ごとの ID、業務に合う権限、辞めた人の ID の停止、使った人の記録が求められます。1 つしか届かない介護の請求用 ID は、知る人と使った記録を事業所で決めます。 - [電子カルテなどからの患者データの持ち出しを防ぎ、記録する方法](https://www.junify.jp/guides/healthcare-access/preventing-patient-data-exfiltration.md): 厚労省のガイドライン第 7.0 版は、持ち出す情報と方法を規程で決め、媒体と院外からのネットワーク経由の両方を想定するよう求めます。見る権限と使えるサービスを仕組みで絞り、持ち出しの承認・媒体の台帳・アクセスの記録を残して見直します。 - [医療情報システムの遠隔保守(リモートメンテナンス)で、保守事業者のアクセスをどう管理するか](https://www.junify.jp/guides/healthcare-access/remote-maintenance-vendor-access.md): 管理の責任は医療機関に残ります。厚労省のガイドライン第 7.0 版は、保守要員に専用のアカウントを使わせ、遠隔保守では必ず記録を集めて作業計画書と照合することを求めます。つながる経路の一覧と契約も要ります。 - [私物端末(BYOD)から診療システムを使うときの安全管理](https://www.junify.jp/guides/healthcare-access/byod-for-clinical-systems.md): 厚労省のガイドラインは私物端末の利用を禁じていませんが、許可の条件・利用範囲・管理方法などを規程に書いて台帳で管理し、院内の端末と同等の対策を手順にすることを求めます。管理されていない端末での利用は許可してはならないとしています。 - [医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](https://www.junify.jp/guides/healthcare-access/medical-audit-log-retention.md): 遵守事項は、ログイン時刻・アクセス時間・操作した医療情報が分かる記録を残して定期的に確かめ、改ざんを防ぎ、時刻を正確に保つことです。年数の定めは厚労省のガイドラインになく、2 省ガイドラインが法定保存年限以上を原則にしています。 - [厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる](https://www.junify.jp/guides/healthcare-access/mhlw-guideline-authentication-and-access-control.md): 求められるのは、利用者ごとの識別・認証、ID とパスワードを本人しか知り得ない状態に保つこと、申請に基づく権限付与、二要素認証、ID の台帳と棚卸しです。遵守事項ごとに、施設で確かめる点を表にします。 - [オンライン診療で入れ替わる医師・スタッフのアカウント管理](https://www.junify.jp/guides/healthcare-access/online-clinic-staff-turnover-accounts.md): 指針は、医療機関に多要素認証を用いるのが望ましいとし、事業者にアクセス権限の管理、退職者アカウントの削除の重点的な監視、アクセスログの保全を求めます。医師が交代する施設は、診療計画の医師名と ID の一覧を合わせます。 - [医事業務・レセプト業務を委託するときのアカウント](https://www.junify.jp/guides/healthcare-access/outsourcing-medical-billing-accounts.md): 企画管理編 7 章の遵守事項は、委託契約の契約書に守秘・非開示を含め、委託先の就業規則等にも同じ対応を求めることです。ID は外部の利用者として、要員ごとにアクセス権限とアクセス状況を管理できる形で用意します。 - [電子カルテ・診療システムの ID を複数人で使うことの問題と現実](https://www.junify.jp/guides/healthcare-access/sharing-ehr-accounts-among-staff.md): 厚労省のガイドラインの遵守事項は、ID とパスワードを本人しか知り得ない状態に保つことです。考え方の節は、全ての職員と関係者に本人の ID 等を用意するとしています。共有 ID はどちらにも載りません。 - [医療機関の二要素認証で求められることと、共有アカウントで起きること](https://www.junify.jp/guides/healthcare-access/two-factor-authentication-with-shared-accounts.md): 医療情報システムを新規に入れるときや入れ替えるとき、二要素認証の採用が遵守事項です。共有アカウントに付けても、コードは 1 人の端末に届き、誰が使ったかは残りません。 - [3 省 2 ガイドラインとは](https://www.junify.jp/guides/healthcare-access/what-is-3-ministries-2-guidelines.md): 3 省 2 ガイドラインとは、厚労省の医療機関等向けガイドラインと、総務省・経産省の事業者向けガイドラインを合わせた通称です。医療情報を扱う側と、そのシステムを提供する側の 2 本で 1 組です。 - [医療情報システムの安全管理に関するガイドラインとは](https://www.junify.jp/guides/healthcare-access/what-is-medical-information-system-security-guideline.md): 厚労省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。現行は第 7.0 版(令和 8 年 6 月)で、経営層・企画管理者・運用担当者ごとの編に分かれ、認証や記録の遵守事項を示します。 - [人事・採用のアカウント管理](https://www.junify.jp/guides/hr-access.md): 採用媒体や人事・給与システムの企業アカウントは、担当者・応援要員・採用代行で共有されがちです。応募者と従業員の情報は安全管理措置の対象で、使える人の限定、使った人の記録、退職時の停止が問われます。 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](https://www.junify.jp/guides/hr-access/indeed-employer-account-with-rpo.md): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](https://www.junify.jp/guides/hr-access/handing-job-board-accounts-to-rpo.md): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](https://www.junify.jp/guides/hr-access/hr-payroll-system-shared-ids.md): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 - [採用媒体のアカウントを複数人で使うときの権限と共有 ID](https://www.junify.jp/guides/hr-access/job-board-account-roles-and-shared-ids.md): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 - [入社・退職時のアカウント管理チェックリスト](https://www.junify.jp/guides/hr-access/onboarding-offboarding-checklist.md): 入社時は本人ごとの ID・必要な範囲の権限・共有アカウントの利用許可・誓約書、退職時は ID の停止・共有パスワードの変更・情報と機器の回収・実行の記録です。期限の一例は、退職の翌日までです。 - [応募者情報の持ち出しを防ぐアクセス管理](https://www.junify.jp/guides/hr-access/preventing-applicant-data-exfiltration.md): 応募者情報は個人情報保護法の安全管理措置と職業安定法 5 条の 5 の対象です。見られる人を採用に関わる人に限り、媒体からの出力・履歴書の保存先・面接官への共有・私物端末の 4 つの経路に制限と記録を置きます。 - [採用の繁忙期に増える人へ、パスワードを渡さずに媒体を使わせる方法](https://www.junify.jp/guides/hr-access/seasonal-hiring-staff-without-sharing-passwords.md): 方法は 4 つです。媒体で本人の ID を追加する、ID 管理サービスに預ける、パスワードマネージャーで共有する、パスワードを見せずに代わりに入力する。このうち 3 つは、教えずに済みます。 - [オンボーディング・オフボーディング(アカウントの観点)とは](https://www.junify.jp/guides/hr-access/what-is-onboarding-offboarding.md): アカウントの観点では、オンボーディングは入社・応援の開始に合わせて本人の ID と権限を発行し、共有アカウントを使える人に加えること。オフボーディングは退職・終了に合わせてそれらを止め、共有のパスワードを変えることです。 - [SaaS のログインを会社が管理する方法の全体像](https://www.junify.jp/guides/access-basics.md): SaaS のログインを会社が管理する方法は、ID 管理サービスによる SSO、パスワードマネージャー、特権 ID 管理、管理されたブラウザー、代わりに入力する仕組みなどに分かれ、アカウントの種類ごとに組み合わせます。 - [監査ログと、監査で示す記録の違い](https://www.junify.jp/guides/access-basics/audit-log-vs-evidence.md): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](https://www.junify.jp/guides/access-basics/browser-extension-access-control-scope.md): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](https://www.junify.jp/guides/access-basics/byod-options-mdm-vdi-browser.md): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 - [SaaS のアカウントを管理するツールの種類と違い](https://www.junify.jp/guides/access-basics/comparison-of-access-management-tool-categories.md): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 - [最小権限の原則を SaaS の共有アカウントに当てはめる](https://www.junify.jp/guides/access-basics/least-privilege-for-shared-saas-accounts.md): 共有アカウントでは権限が ID に付き、使う人全員に同じ権限が渡るため、人ごとには絞れません。まず SaaS 側の権限の種類(閲覧・編集・管理者)で個人に分け、共有が残る部分は、使える人の一覧、期間、記録の 3 つで補います。 - [QR コードでログインする方式と、フィッシングへの強さ](https://www.junify.jp/guides/access-basics/qr-code-login-and-phishing-resistance.md): QR コードでログインする方式は、パソコンの画面の QR をログイン済みのスマホで読み、スマホ側で承認する仕組みです。パスワードを打たない分だけ盗まれにくく、他人が表示させた QR を承認すると入られる弱さがあります。 - [SAML に対応していない SaaS に SSO に近い運用を作る方法](https://www.junify.jp/guides/access-basics/sso-like-operation-for-non-saml-saas.md): SAML などに対応しない SaaS でも、ID 管理サービスの代理入力、パスワードマネージャーの共有、代わりに入力する仕組みで SSO に近い形にできます。違いは担当者がパスワードを知るかと記録の単位です。 - [IdP(ID 管理サービス)とは](https://www.junify.jp/guides/access-basics/what-is-idp.md): IdP(ID 管理サービス)とは、社員の ID を一か所で保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。Okta や Microsoft Entra ID が代表です。 - [最小権限の原則とは](https://www.junify.jp/guides/access-basics/what-is-least-privilege.md): 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。NIST が設計の原則として定義し、IPA も ID の割り当てを必要最小限にするよう勧めています。 - [多要素認証(MFA)とは](https://www.junify.jp/guides/access-basics/what-is-mfa.md): 多要素認証とは、知っているもの(パスワード)、持っているもの(スマホや IC カード)、本人自身(指紋や顔)の 3 種類のうち 2 つ以上でログイン時に本人を確かめる方式です。パスワードが漏れてもすぐには入られないようにします。 - [パスワードレスとは](https://www.junify.jp/guides/access-basics/what-is-passwordless.md): パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。パスキー(FIDO)が代表です。パスワードを見せずに代わりに入力する方式は、パスワードが残るので別の仕組みです。 - [セッション録画(画面操作の記録)とは](https://www.junify.jp/guides/access-basics/what-is-session-recording.md): セッション録画とは、ログインしてから終えるまでの利用を、画面の映像や入力した文字として残す仕組みです。何が残り何が残らないかは製品ごとに違い、本人への明示も要ります。 - [SSO(シングルサインオン)とは](https://www.junify.jp/guides/access-basics/what-is-sso.md): SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。ID 管理サービスと SAML などの規格でつながるサービスにだけ使え、つながらないサービスには別の方法が要ります。 - [ゼロトラストとは](https://www.junify.jp/guides/access-basics/what-is-zero-trust.md): ゼロトラストとは、社内ネットワークにいるからといって信頼せず、利用のたびに利用者と端末を確かめてから最小限のアクセスを許す考え方です。NIST SP 800-207 が定義し、総務省は「決して信頼せず、必ず確認せよ」と言い表しています。 - [法令・ガイドラインとアカウント管理](https://www.junify.jp/guides/compliance.md): 法令や公的な指針がアカウントの管理に求めることは、誰が使ったか分かる・権限は必要最小限・退職や契約終了で止める・委託先を確かめる、の 4 点にまとまります。 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](https://www.junify.jp/guides/compliance/cis-controls-account-access-management.md): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](https://www.junify.jp/guides/compliance/data-breach-report-access-logs.md): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](https://www.junify.jp/guides/compliance/government-unified-standards-accounts.md): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 - [内部監査でアカウントの管理を確かめるときの観点と記録](https://www.junify.jp/guides/compliance/internal-audit-account-checklist.md): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 - [ISMAP の管理基準がクラウドサービス事業者に求めるアカウント管理](https://www.junify.jp/guides/compliance/ismap-account-management.md): ISMAP 管理基準は、事業者のシステムに入る人の ID の登録と削除、管理者権限の制限、定期の見直し、作業の記録を求めます。サービスを使う組織が自分で ID と権限を管理できる機能の提供も求めます。 - [ISO/IEC 27017 がクラウドを使う側と提供する側に求めるアカウント管理](https://www.junify.jp/guides/compliance/iso27017-cloud-account-management.md): ISO/IEC 27017 は推奨の手引です。パスワードの管理では、クラウドを使う会社には事業者の手順が自社の決まりに合うかの確認を、事業者には手順の情報を出すことを勧めています。ID の登録と権限の付与は事業者にだけ手引があります。 - [J-SOX の IT 全般統制の運用評価で、アカウントについて確かめられること](https://www.junify.jp/guides/compliance/jsox-operating-evaluation-accounts.md): 運用評価では、期中に行った利用者の追加・削除・権限の見直しから一部を抜き出し、承認や削除の記録が実際にあるかを確かめます。共有の ID は、本人が使ったことを記録で示せないため、確かめにくくなります。 - [NIST サイバーセキュリティフレームワーク 2.0 の PR.AA を共有アカウントに当てはめる](https://www.junify.jp/guides/compliance/nist-csf-2-identity-management.md): PR.AA は、建物やシステム、データに入れる人を認められた人に限ることを求め、6 項目に分けています。手段は定めませんが、NIST の例は 1 人 1 つの認証情報を挙げており、共有を残すなら使った人の確かめ方と止め方の説明が要ります。 - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」が求めるアクセス管理と ID 管理](https://www.junify.jp/guides/compliance/fsa-cybersecurity-guideline-access.md): 中心は 2.3.1「認証・アクセス管理」です。権限を最小限にして承認した個人に付け、アカウントを作成から終了まで管理して棚卸しし、パスワードを管理し、重要なシステムには外から多要素認証で入り、操作を使った人と結びつけて記録するよう求めます。 - [IPA「組織における内部不正防止ガイドライン」第 5 版のアカウント管理項目](https://www.junify.jp/guides/compliance/ipa-insider-threat-guideline-accounts.md): 第 5 版の 33 項目のうち、アカウントを扱うのは主に 6 つです。共有 ID を使わない、退職した人の ID をただちに消すなど 5 つを「しなければならない」とし、利用の記録を残す 1 つは「望ましい」としています。 - [ISMS の担当者が代わるときのアカウントと権限の引き継ぎ](https://www.junify.jp/guides/compliance/isms-handover-accounts.md): 経営者が後任を任命し直し、管理者権限を後任に付けてから、共有パスワードを変え、前任者の権限を外します。審査では、任命と後任の力量の記録、交代前後の権限の一覧、外した記録を示します。 - [PCI DSS の要件 8 は共有 ID をどう扱うか(EC 事業者と運用代行の場合)](https://www.junify.jp/guides/compliance/pci-dss-requirement-8-shared-ids.md): PCI DSS の要件 8 は共有 ID を例外の場面に限り、PCI SSC はそのねらいを、操作を一人ひとりに結びつけることだと説明します。カード情報を持たない EC 事業者も管理画面の二段階認証などを求められ、運用代行もそれに従います。 - [個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか](https://www.junify.jp/guides/compliance/personal-data-ledger-accounts.md): 台帳は法律の義務ではなく、プライバシーマークは「アクセス権を有する者」を求めますが、細かさは決めていません。台帳には部署と役割を書き、氏名とアカウントは別の一覧に分けると直し漏れが減ります。 - [SOC 2 の論理アクセスの規準(CC6.1〜6.3)を SaaS のアカウント管理に当てはめる](https://www.junify.jp/guides/compliance/soc2-logical-access-for-saas.md): CC6.1 は情報資産へのアクセスを仕組みで制限すること、CC6.2 は承認してから ID を発行し不要になれば消すこと、CC6.3 は役割に応じた最小限の権限を求めます。SaaS では一覧・申請と削除の記録・定期の見直しに当たります。 - [個人情報保護法の安全管理措置をアカウント管理に当てはめる](https://www.junify.jp/guides/compliance/appi-safety-measures-for-accounts.md): 通則編の別添が求める「アクセス制御」と「アクセス者の識別と認証」、24 条の従業者の監督、25 条の委託先の監督を、共有アカウント・退職者・委託先の 3 場面に当てはめ、用意する一覧と記録を表にします。 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版のアカウント管理項目](https://www.junify.jp/guides/compliance/ipa-sme-guideline-accounts.md): 第 4.0 版は、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更・削除、契約終了時のアクセス権の回収を挙げます。本編・付録 3・付録 5 の当てはまる箇所を点検表にします。 - [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](https://www.junify.jp/guides/compliance/iso27001-access-control-for-saas.md): 取り上げる管理策は、5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権の 5 つです。SaaS では、使える人の一覧、ID の作成と削除、パスワード、管理者権限に当たります。 - [経産省サイバーセキュリティ経営ガイドライン(Ver 3.0)の委託先管理](https://www.junify.jp/guides/compliance/meti-cybersecurity-management-guideline-contractors.md): 指示 9 は、委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化を経営者に求めます。アカウントの操作手順は書かれていないため、委託先に渡すアカウントの一覧と契約の条項に置き換えて読みます。 - [総務省テレワークセキュリティガイドライン第 5 版と私物端末](https://www.junify.jp/guides/compliance/mic-telework-guideline-byod.md): 第 5 版は対策を経営者・管理者・勤務者に分けます。管理者には多要素認証、不要なアカウントの削除、ログイン後の記録の取得を、勤務者には認証情報を無断で貸さないことを求め、私物端末はテレワークの方式ごとに可否を決めます。 - [プライバシーマーク(JIS Q 15001)でアカウント管理について求められること](https://www.junify.jp/guides/compliance/privacy-mark-account-management.md): JIPDEC の構築・運用指針は、個人情報の台帳に「アクセス権を有する者」を書いて年 1 回以上確認すること、従業者の監督、委託先の選定基準と契約の 8 事項を求めます。アカウントでは、使える人の一覧・記録・契約の条項に当たります。 - [不正アクセス禁止法と ID・パスワードの共有(識別符号の扱い)](https://www.junify.jp/guides/compliance/unauthorized-computer-access-law-shared-ids.md): 会社が契約するサービスの共有 ID を、会社の承諾を得た担当者が使う行為は、不正アクセス行為から除かれると読めます。退職者の利用、委託先への提供、社外に教える行為は、承諾の範囲と 5 条の「業務その他正当な理由」で分かれます。 - [ISMS(情報セキュリティマネジメントシステム)とは](https://www.junify.jp/guides/compliance/what-is-isms.md): ISMS とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。国際規格 ISO/IEC 27001 に沿って作り、第三者の審査を受けて認証を取ることができます。 - [IT 全般統制(ITGC)とは](https://www.junify.jp/guides/compliance/what-is-itgc.md): IT 全般統制とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」とされるもので、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理が例に挙がります。 - [安全管理措置とは](https://www.junify.jp/guides/compliance/what-is-security-control-measures.md): 安全管理措置とは、個人情報保護法 23 条が事業者に義務づける、個人データの漏えい・滅失・毀損を防ぐ対策です。通則編の別添が、組織的・人的・物理的・技術的の 4 区分と外的環境の把握で内容を示します。 - [SOC 2 とは](https://www.junify.jp/guides/compliance/what-is-soc2.md): SOC 2 とは、クラウドなどのサービスを提供する会社の内部統制を、公認会計士が AICPA の Trust サービス規準に照らして検証し報告する仕組みです。セキュリティなど 5 つの区分で見ます。 - [公表された事故から、アカウント管理の何が問われたか](https://www.junify.jp/guides/incidents.md): 辞めた人のアカウントが生きていた、委託先の担当者がパスワードを知っていた。公表された事故の原因は、この 2 つに行き着きます。どちらも業種や規模を選びません。 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](https://www.junify.jp/guides/incidents/access-between-resignation-notice-and-last-day.md): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](https://www.junify.jp/guides/incidents/agency-google-account-breached.md): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](https://www.junify.jp/guides/incidents/contractor-pc-malware-shared-auth.md): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 - [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](https://www.junify.jp/guides/incidents/contractor-sent-data-outside.md): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 - [委託先の保守担当者が管理者アカウントを共用していた事案から分かる、管理者権限と記録](https://www.junify.jp/guides/incidents/contractor-shared-admin-account.md): コールセンターの仕組みを保守する委託先の元派遣社員が、約 10 年間、管理者用のアカウントで顧客情報を持ち出しました。共用の管理者アカウント、持ち出しを止める設定の不在、記録を点検する運用の不在が原因として公表されています。 - [退職の直前に顧客情報を持ち出された事案から分かる、退職時の業務情報の扱い](https://www.junify.jp/guides/incidents/documents-taken-just-before-resignation.md): 旅行事業の営業担当だった元従業員が、退職直前に宿泊施設の担当者と社内の従業員の個人情報を含む社内資料を持ち出しました。判明は退職の 1 年余り後で、会社は退職・異動時の業務情報の取り扱いを見直すとしています。 - [退職者にサーバーのデータを消された事案から分かる、遮断と復旧の備え](https://www.junify.jp/guides/incidents/former-employee-deleted-data.md): 退職した元社員が退職後に社内ネットワークに不正にアクセスし、サーバーのデータを削除して業務を妨害した容疑で逮捕されました。持ち出しではなく消される型で、遮断と復旧の両方が問われます。 - [退職後に元職員がシステムにログインした事案から分かる、退職日に利用を止める手順](https://www.junify.jp/guides/incidents/former-staff-login-after-leaving.md): 小学校を退職した臨時的任用講師が、退職後に市の学校教育支援システムへ不正にアクセスしたとして逮捕されました。市の公表文は入った経路を書いておらず、問われるのは退職日に利用を止める手順です。 - [退職日の翌日にアカウントが残っていた事案から分かる、退職手続きとアカウント削除のつなぎ方](https://www.junify.jp/guides/incidents/former-staff-took-files-before-and-after-leaving.md): 元職員が在職中と退職日の翌日に、個人情報を含むファイルを USB メモリで持ち出しました。市は原因の一つに、退職翌日もアカウントの削除処理が行われていなかったことを挙げています。 - [再々委託先の作業者が仕入先の個人情報をダウンロードした事案から分かる、多層の委託とアクセス権限](https://www.junify.jp/guides/incidents/fourth-tier-contractor-downloaded-data.md): 委託先・再委託先の先にいる再々委託先の作業者が、仕入先担当者の個人情報約 2.2 万件を私用目的でダウンロードしました。委託の階層が深くなるほど、委託元から作業者が見えにくくなります。誰にどの範囲の権限を与えているかが問われた事案です。 - [公式 SNS が乗っ取られた 9 件の公表文から分かること](https://www.junify.jp/guides/incidents/official-sns-takeovers-from-notices.md): 公表文 9 件のうち、原因を書いたのは 1 件です。多くは「調査中」「再発防止に努める」にとどまります。乗っ取り後に起きたことと、公表文が挙げた対策を表にします。 - [公式 Instagram が運営元を装ったメールで乗っ取られ、削除された事案](https://www.junify.jp/guides/incidents/phishing-took-over-official-sns.md): 公式 Instagram が、運営元を装ったメールへの対応をきっかけに乗っ取られ、管理情報を無効化されたうえ削除されました。公表文で乗っ取りの原因を書いた例です。 - [管理者パスワードの使い回しでランサムウェアの被害が院内に広がった事案](https://www.junify.jp/guides/incidents/reused-admin-password-ransomware.md): 保守用の外部接続機器と院内すべてのパソコンで、同じ推測しやすい ID とパスワードが使われ、全利用者に管理者権限がありました。調査報告書は、原因の多くは国のガイドラインを守っていれば防げたとしています。 - [パスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案](https://www.junify.jp/guides/incidents/reused-password-list-attack.md): 他のサービスから漏れた ID とパスワードの組を試す攻撃で、二段階認証をオフにしていた ID だけが不正ログインされました。国内 12 件、海外を含め 156 件です。 - [退職後に社外の Web サービスへ不正アクセスされた事案から分かる、外部サービスのアカウントの止め方](https://www.junify.jp/guides/incidents/saas-account-alive-after-resignation.md): 元従業員が退職後に、会社が利用する名刺管理システムに不正にアクセスし、名刺情報を漏えいさせました。問われるのは、会社が使うシステムのアカウントを退職時に止める手順です。社外の Web サービスなら、社内の手続きだけでは止まりません。 - [委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案](https://www.junify.jp/guides/incidents/shared-password-with-supplier.md): 給食の委託先の機器から侵入され、病院のサーバーと端末で共通だったパスワードで被害が広がりました。報告書が原因に挙げたのは、共通パスワード、全員への管理者権限、外部接続の役割分担の曖昧さです。 - [共有ツールの ID とパスワードが盗まれて侵入された事案から分かる、ID の発行と管理、多要素認証](https://www.junify.jp/guides/incidents/shared-tool-ids-used-for-intrusion.md): 正規の ID とパスワードが盗まれ、正常なログインに見える形で顧客から預かった情報が窃取されました。影響は 142 の顧客に及び、検証委員会は情報保護の体制と利用組織ごとの管理の不備を指摘しました。 - [無断の再委託先が個人データを持ち出した事案から分かる、再委託と辞めた人が知っているパスワード](https://www.junify.jp/guides/incidents/undisclosed-subcontractor-copied-data.md): 全市民約 46 万人の個人データを入れた USB メモリーを、市に無断の再々委託先の従業員が持ち出して紛失しました。調査報告書は、無断の再委託と、案件を離れた人や転職した人もパスワードを知ったままだった状態を、問題として明記しています。 - [個人情報保護委員会の指導事例に出てくる、推測されやすいパスワードと委託先のアカウント](https://www.junify.jp/guides/incidents/weak-and-default-passwords-in-guidance.md): 令和 6 年度第 1 四半期の指導 110 件の概要には、事業名を使った簡単なパスワード、4 桁の管理者パスワード、初期設定のままの ID が原因とされた事案が並びます。委託先の監督の不備も 8 件ありました。 - [漏えい等とは(個人情報保護法の報告義務)](https://www.junify.jp/guides/incidents/what-is-data-breach.md): 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条は、規則で定める 4 つの事態が起きたとき、個人情報保護委員会への報告と本人への通知を義務づけます。 - [内部不正とは](https://www.junify.jp/guides/incidents/what-is-insider-threat.md): 内部不正とは、役員・従業員・派遣社員などの内部者による、情報の窃取・持ち出し・漏えい・消去・破壊です。IPA のガイドラインは、違法とまでいえない規程違反も含め、退職後に在職中の情報を漏らす行為も内部不正として扱います。 - [不正アクセスとは(不正アクセス禁止法)](https://www.junify.jp/guides/incidents/what-is-unauthorized-access.md): 不正アクセスとは、不正アクセス禁止法 2 条 4 項が定める行為で、中心は、他人の ID とパスワード(識別符号)をネットワーク経由で入力し、制限されている利用ができる状態にすることです。3 条が禁じ、11 条に罰則があります。 - [アカウント管理の用語索引](https://www.junify.jp/glossary.md): アカウント管理に関する用語を、読みの五十音順で探せます。 - [よくある質問](https://www.junify.jp/faq.md): Junify の仕組みや利用条件について、現場ごとのよくある質問にお答えします。 ## 問い合わせ - デモの予約: https://www.junify.jp/bpo/demo - メール: info@junify.com --- # Junify — アカウントを渡さず、仕事を任せる > 社員にも、外部人材にも、委託先にも、アカウントを渡さずに仕事を任せられます。 > > ID とパスワードは管理者が Junify に登録し、担当者は自分のスマホで本人確認をしてクリックするだけ。パスワードを知らないまま仕事を始められ、人が入れ替わっても、事故が起きても、「誰が・いつ・何をしたか」を説明できる会社になります。 必要なのは、担当者のスマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。会社支給でないパソコンでも使えます。 ## いまは、こうなっていませんか これまでは、ID とパスワードを教えるしかありませんでした。いまは、教えなくても任せられます。それでも多くの現場は、まだこうなっています。 - 複数人での共有 — **誰が使ったかが、残らない。** 広告運用、採用媒体、SNS 公式、管理者用アカウント。誰の操作か分からず、全員に聞いて回る。 - 一時的な貸与 — **辞めた人を止めるには、変えて全員に配り直すしかない。** スポット勤務・業務委託・短期の応援。辞めるたびにパスワードを変えて配り直す。変え忘れれば、そのまま入れる。 - 外部アカウントの預かり — **一度教えたパスワードは、取り消せない。** BPO・運用代行・士業。預かったアカウントを、誰がいつ使ったかクライアントに示せない。 ## 仕組み(3 ステップ) はじめに、管理者が ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡しません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。 2. **カードをクリックしてログイン** — 使ってよいアカウントが「カード」として並びます。クリックすると Junify が ID とパスワードを入力。本人は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は一人ひとり(証跡)。必要なアカウントには録画も。本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。日々の操作は「QR を読んで、クリック」だけ。仕組みをくわしく: https://www.junify.jp/product ## 導入後の状態 聞かれた日、事故の日、辞める日、入る日。それぞれ、会社はこう動けます。 - **監査・商談で聞かれた日** — 「アカウント管理はどうしていますか?」に、その場で答えられます。パスワードは渡さず、誰がいつ使ったかは記録が残る。質問票や監査が、壁ではなく信頼の材料になります。 - **事故が起きた日** — 誰が・いつ・どのアカウントを使ったかを、その日のうちに報告できます。録画を付けたアカウントなら、何をしたかまで画面で確認。記録は担当者を疑うためではなく、守るためのものです。 - **退職・交代の日** — パスワードを変えて配り直す必要が、なくなります。その人に渡していたカードを外すだけ。その瞬間から入れません。パスワードは、もともと渡していません。 - **新しい人が入った日** — 初日から、パスワードを教えないまま始めてもらえます。カードを割り当てれば、本人は QR を読むだけ。私物のパソコンでも、パスワードや履歴は端末に残りません。 ## 現場別の入口 あてはまる現場から、お入りください。どれも、実際に Junify が使われている現場です。 | 現場 | 内容 | ページ | | --- | --- | --- | | BPO・運用代行 | クライアントから預かったアカウントを、誰が使ったかまで残る形で扱えます。 | https://www.junify.jp/bpo | | SNS・広告・EC 運用代行 | 預かった SNS 公式・広告・EC モールのアカウントを、担当者にパスワードを渡さずに任せ、誰が使ったかを残せます。 | https://www.junify.jp/marketing-ops | | 医療・ヘルスケア | 患者情報などの機微な情報を扱う業務を、録画付きで、パスワードを渡さずに行える環境に。 | https://www.junify.jp/healthcare | | 人事・採用 | 採用サイト・人事系サービスの共有アカウントを、誰が使ったかが残る形に。 | https://www.junify.jp/hr | | クラウド運用・特権 ID | 管理コンソール・管理者用 ID を共有していても、誰が使ったかを個人で特定し、記録を残せます。 | https://www.junify.jp/privileged-access | | 社内の共有アカウント | 部門に残る共有アカウントを、なくさずに、誰が使ったか分かる形にします。 | https://www.junify.jp/shared-accounts | ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 すでに何らかのツールをお使いの場合、その違いは各ソリューションページとデモでご説明します。 ## 会社 Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。 - 金融機関・上場企業を含む導入実績 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供 - 稼働状況を常時公開(https://status.junify.com) ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分。広告運用の例ですが、操作は同じです): https://www.junify.jp/bpo/try - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify for BPO・運用代行 — 「御社になら、アカウントを預けられる」と言われる会社に > Junify は、クライアントから預かったアカウントを、担当者にパスワードを渡さずに使わせ、誰が・いつ使ったかを担当者ごとに記録するサービスです。「どう管理していますか」という問いに、運用の説明ではなく仕組みで答えられます。 必要なのは、担当者のスマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。 ## いまは、こうなっていませんか これまでは、預かった ID とパスワードを担当者に教えるしかありませんでした。いまは、教えなくても任せられます。それでも多くの会社は、まだこうなっています。 - 共有パスワードを管理表やチャットで配り、誰が知っているか分からない - 人の出入りのたびにパスワードを変え、周知が毎回の仕事になっている - 共有アカウントの作業は記録に残らず、聞き取りで答えるしかない - リモートの担当者が私物のパソコンで作業し、端末に何が残るか見えない いまの運用の代償: 渡したパスワードは、回収できない。共有アカウントでは、誰の操作かを示せない。預かり先が増えるほど、変更と周知が重い。 ## 使い方は 3 ステップ **はじめに(管理者): 管理者が登録して割り当てる** — 管理者が、預かった ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡さず、クライアント側の設定も変えません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。メールアドレスがない人でも使えます。 2. **カードをクリックしてログイン** — 使ってよいアカウントが「カード」として並びます。クリックすると Junify が ID とパスワードを入力。認証アプリ方式の二段階認証コードも。担当者は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は担当者ごと(証跡)。必要なアカウントには録画も。本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの会社はこうなります 商談の日、事故の日、人が辞める日、新しい人が入る日。それぞれ、会社はこう動けます。 - **商談で聞かれた日** — 「パスワードは渡していません。誰がいつ使ったかは記録が残ります」と、その場で答えられます。質問票や監査に、仕組みで答えられます。 - **事故が起きた日** — 誰が・いつ・どのアカウントを使ったかを、その日のうちに報告できます。録画を付けたアカウントなら、何をしたかまで画面で。記録は担当者を守るためのものです。 - **退職・交代の日** — パスワードを変えて配り直す必要が、なくなります。その人の割り当てを外すだけ。その瞬間から入れません。パスワードは、もともと渡していません。 - **新しい人が入った日** — 管理者がカードを割り当てれば、初日から作業できます。本人は QR を読んでクリック。私物のパソコンでも、パスワードや履歴は端末に残りません。 ## 運用はこう変わる | 従来の共有アカウント運用 | Junify 導入後 | | --- | --- | | 管理表のパスワードを確認してログイン | スマホで本人確認 → カードをクリックするだけ | | パスワードを全員が知っている | 担当者は誰も知らない。人の入れ替わりで変える必要がない | | 記録は手入力の報告と聞き取りだけ | 誰が・いつ・どのアカウントを使ったかが自動で残る。録画を付ければ画面も | | 事故のとき、調べられない。説明できない | 誰が・いつ・何をしたかを、その場で示せる | ## 導入シーン すべて実際の導入・利用シーンから。社名非公開の実案件ベースです。詳細はデモでご紹介します。 - **広告運用代行** — クライアントの広告アカウントのパスワード共有をやめ、担当者ごとに使えるアカウントを決めて、誰が使ったかを記録する形に。 - **BPO・業務受託** — クライアントごとの業務システムを Junify に登録。担当が変わっても、管理者が使える人を付け替えるだけ。 - **遠隔医療** — 入れ替わるスポット勤務の医師の診療システム利用を、私物のパソコンのまま、誰が使ったかが医師ごとに残る形に。 - **出版・校正** — 校正の外部スタッフに渡していたアカウントを、期間を区切って使わせる形に。 - **AWS 運用(管理者用 ID)** — 運用を委託した管理者用アカウントを、誰が・いつ使ったかが担当者ごとに残る形に。 - **人事・採用** — 採用サイトや人事系サービスの共有アカウントを、誰が使ったかが担当者ごとに残る形に。 導入のきっかけは大きく 3 つ。事故のあとの説明責任、リモートで働く人の管理、個人情報など機微な情報の扱い。 ## 使う人数の上限までは、何名でも同じ料金。円建ての固定額です 課金の単位は、Junify を使う担当者の人数です。クライアントのアカウント数では課金しません。クレジットカード払い可。 | プラン | 導入後の状態 | 月額(税別) | 上限 | 含まれるもの | | --- | --- | --- | --- | --- | | スターター | まず、パスワードを渡さない会社になる | ¥39,800 | 担当者 15 名まで、同じ料金 | クライアントアカウントの一元管理 / 担当者への割り当て・解除 / パスワードを見せないログイン / 個人単位の利用記録 | | スタンダード(推奨) | 何をしたかまで、画面で答えられる会社になる | ¥128,000 | 担当者 40 名まで、同じ料金 | スターターの全機能 / 画面操作の録画(50GB 込み) / ファイルのアップロードを検知して管理者に通知・ダウンロードの制限(アカウント単位) | | スケール | その体制を、大きな規模でも | ¥248,000 | 担当者 100 名まで、同じ料金 | スタンダードの全機能 / 画面操作の録画 100GB 込み / 担当者数の上限の拡大 / 優先サポート | 上限を超える場合は上位プランまたは個別お見積りをご案内します。録画容量は追加購入できます。請求書払いをご希望の場合はご相談ください。価格は改定されることがあります。 ## ほかの道具を検討したことがある方へ | 道具 | 違い | | --- | --- | | 端末監視ツール | パソコンの操作をすべて記録する製品。私物端末や外部人材には重く、プライバシーの負担も大きい。 | | パスワード管理ツール | 共有パスワードの保管庫。保管は改善しても、担当者に見せたパスワードは回収できない。 | | PAM | サーバーの管理者権限を管理する製品。クライアントが持つ Web サービスの業務には過剰で高価。 | | IDaaS・SSO | 社員向けのログイン基盤。クライアント所有のアカウントや共有アカウントは載せられない。 | | Secure Browser・VDI | 会社が配る専用ブラウザーや仮想デスクトップ。私物のパソコンで働く外部人材に合わない。 | 担当者をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## よくある質問 1. **クライアントのパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 2. **共有アカウントだと、結局誰が使ったか分からないのでは?** — クライアント側の ID とパスワードは共有のままでも、Junify にログインするのは一人ひとりの自分のスマホです。だから、誰が・いつ使ったかを担当者ごとに記録できます。 3. **パスワード管理ツールとの違いは?** — パスワード管理ツールは、担当者にパスワードを見せて使わせる道具です。見せたパスワードは回収できません。Junify は見せずにログインさせ、担当を外せばその場で使えなくします。 4. **クライアントに SSO を用意してもらえばよいのでは?** — 受託側がクライアントのシステム設定を変えられるとは限りません。共有アカウントや SSO 非対応のサービスは、それだけでは覆えません。Junify は ID とパスワードだけのサービスでも使えます。 5. **担当者がすでにパスワードを知っている場合は?** — Junify に登録する際にパスワードを変更し、新しいパスワードを Junify だけが保持する運用を推奨しています。以後は Junify を通してのみログインできます。 6. **二段階認証があるサービスでも使えますか?** — スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 7. **担当者の私物のパソコンでも使えますか?** — 使えます。パソコンに入れるのはブラウザーの Junify 拡張機能だけ(スマホには Junify アプリ)。カードから開いた窓は履歴を残さないモードなので、閉じればパスワードも痕跡も残りません。 8. **録画は、誰が付けて、誰が見られますか?** — 管理者がアカウントごとに決めます。始まる前に担当者本人に表示され、見られるのは本人と管理者だけ。誰が・いつ使ったかの記録は全プラン標準で、画面の録画はスタンダード以上です。 9. **料金は何で決まりますか?** — Junify を使う担当者の人数です。上限の人数までなら何名でも同じ料金で、クライアントのアカウント数では課金しません。円建ての固定額で、3 つのプランをこのページの「料金」に載せています。 ## 会社概要 Junify Corporation — 2016 年設立、米国シリコンバレー(Palo Alto)。 - 金融機関・上場企業を含む導入実績 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供 - 稼働状況を常時公開(status.junify.com) ## 次の一歩 パスワードを渡さずに任せて、「誰が使ったか」を答えられる会社へ。 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try?scenario=bpo - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # 30 分デモを予約する — Junify > 実際の画面をご覧いただきながら、御社の運用に当てはめてご説明します。オンラインで 30 分、事前のご準備は不要です。 URL: https://www.junify.jp/bpo/demo ## デモでご覧いただくこと 1. **実際の操作の流れ** — 担当者が画面上のアカウントを一つ選ぶと、パスワードを知らないままそのサービスにログインでき、誰が・いつ使ったかが記録に残る。この流れを、実際の画面でご覧いただきます。 2. **御社に当てはめた導入イメージ** — クライアント数・体制・任せている業務をうかがい、どのアカウントから始めるとよいかをその場でご提案します。 3. **料金と導入までの流れ** — お見積りの考え方と、利用開始までにやること(最短でどのくらいか)をご説明します。 オンライン開催で移動は不要です。IT に詳しい方の同席は不要です。その場でご契約をお願いすることはありません。 ## お申し込み ページ上のフォームからお申し込みいただくと、1 営業日以内に日程の候補をお送りします。日程は日本時間の平日午前が中心です。 - 必須: 会社名 / お名前 / メールアドレス - 任意: 役職 / Junify を使う方の人数 / ご希望の時間帯(平日 9:00〜10:00、10:00〜11:00、11:00〜12:00 の中から複数可) / ご相談内容 フォームをお使いになれない場合は info@junify.com へ直接ご連絡ください。 --- # 資料をダウンロード — Junify > 仕組み・料金・導入の流れをまとめた、Junify のご説明資料(PDF)です。社内での回覧や、上長へのご説明にそのままお使いいただけます。 URL: https://www.junify.jp/bpo/download ## 資料の内容 - パスワードを渡さずに業務を任せる仕組み - 導入後に変わること(事故対応・監査・人の入れ替わり) - 料金プランと含まれる機能 - 導入の流れと必要なもの ## 入手方法 ページ上のフォームに会社名とメールアドレスをご記入いただくと、その場でダウンロードでき、同じ資料をメールでもお送りします。ご入力いただいた情報は、資料の送付と関連のご案内のためにのみ使用します。 資料に書かれている内容の要点は https://www.junify.jp/bpo.md にも掲載しています。 --- # Junify for 医療・ヘルスケア — 入れ替わる医療従事者にも、委託先にも、患者情報のアカウントは渡さない > 診療システムの ID とパスワードは管理者が Junify に登録し、スタッフは自分のスマホで本人確認をしてクリックするだけ。パスワードを知らないまま私物のパソコンから使え、誰が・いつ使ったかは一人ひとり残ります。 必要なのは、スマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。 ## いまは、こうなっていませんか これまでは、診療システムの ID とパスワードを教えるしかありませんでした。いまは、教えなくても任せられます。それでも多くの医療機関は、まだこうなっています。 - 非常勤・スポット勤務の医師や看護師に、ID とパスワードを口頭やメッセージで伝えている - スタッフの私物のパソコンやスマホに、パスワードや閲覧の履歴が残っている - 勤務のない期間も、そのスタッフは診療システムにいつでも入れる - 委託先で自院のアカウントを誰が使ったか、自院には分からない - 辞めた人が出るたびにパスワードを変え、残る全員に配り直している いまの運用の代償: 一度教えたパスワードは、取り戻せない。共有の ID では、誰が使ったかが残らない。私物の端末に残った痕跡は、自院からは消せない。 ## 使い方は 3 ステップ はじめに、自院の管理者が診療システムの ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードはスタッフに渡しません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。メールアドレスがない人でも使えます。 2. **カードをクリックしてログイン** — 使ってよい診療システムが「カード」として並びます。クリックすると Junify が ID とパスワードを入力。スタッフは見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有 ID でも記録は一人ひとり(証跡)。必要なアカウントには録画も。スタッフ本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。診療システム側の設定はそのまま。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの医療機関はこうなります 新しいスタッフが入る日、勤務のない期間、ビデオ診療中、監査・契約審査の日。それぞれ、現場はこう動けます。 - **新しいスタッフが入る日** — 管理者がカードを割り当てるだけで、初日から診療システムに入れます。本人は QR を読んでクリック。パスワードは知らないままです。 - **勤務のない期間** — 管理者が割り当てを外せば、その瞬間から入れません。次の勤務で戻せます。パスワードは渡していないので、変える必要がありません。 - **ビデオ診療中** — 録画を付けたアカウントなら、何かあったとき誰が何をしたかを画面で確かめられます。軽い方式なので、通話は重くなりません。 - **監査・契約審査の日** — 誰が・いつ・どのシステムに入ったかを、一人ひとり CSV で出せます。委託先のスタッフも同じ仕組みなら、同じ記録で答えられます。 ## 医療の現場で効くこと - **私物の端末のまま** — いまは、私物のパソコンに履歴が残ります。Junify から開いた画面は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。 - **ID・パスワードだけの診療システムにも** — 多くの診療システムには SSO がありません。ID とパスワードでログインする画面があれば、そのまま使えます。認証アプリ方式の二段階認証コードも入力。 - **診断書の発行はできて、持ち出しは止める** — ファイルの保存(ダウンロード)を、アカウントごとに許可・禁止できます。事務は許可、診療スタッフの閲覧は禁止、という使い分けができます。 - **委託先のスタッフにも、同じ手順で** — 委託先のスタッフにも、自院のスタッフと同じ手順で自院のアカウントを使ってもらえます。パスワードは渡らず、記録は一人ひとりです。 ## 実際の導入から - **遠隔医療** — 入れ替わるスポット医師が私物の端末から診療システムを使う現場。パスワードを渡さずに使ってもらい、誰が・いつ使ったかを一人ひとり記録する形にしました。社名非公開の実案件です。 ## よくある質問 1. **患者情報が写る画面を録画するのですか? 誰が見られますか?** — 録画は、何かあったとき誰が何をしたかを画面で確かめるためのものです。管理者が必要なアカウントにだけ設定し、始まる前にスタッフ本人に表示されます。見られるのはスタッフ本人と院内の管理者だけです。 2. **ビデオ診療が重くなりませんか?** — なりません。動画を撮るのではなく、画面が変わった部分だけを記録する軽い方式です。 3. **スタッフの私物パソコンに、何か入れますか? 何か残りますか?** — 入れるのはブラウザーの Junify 拡張機能だけ(スマホには Junify アプリ)。開いた画面は履歴を残さないモードなので、パスワードや閲覧の痕跡は残りません。保存したファイルは残るので、可否はアカウントごとに設定。 4. **うちの診療システムは ID とパスワードでログインする普通のシステムです。使えますか?** — はい。診療システム側の設定変更や連携機能は要りません。二段階認証がスマホの認証アプリにコードが出る方式なら、そのコードも Junify が入力します。SMS やメールのコードは対象外です。 5. **診療システムのパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 6. **医療事務の委託先にも、同じ運用を求められますか?** — 求められます。委託先のスタッフにも、自院のスタッフと同じ手順で自院のアカウントを使ってもらう形です。委託先と委託元が同じ仕組みで運用している導入例があります。 7. **料金は?** — 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。円建ての固定額で、クリニックの規模と対象システムに合わせてデモの際にご案内します。 ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## 会社 Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。 - 金融機関・上場企業を含む導入実績 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供 - 稼働状況を常時公開(https://status.junify.com) ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try?scenario=healthcare - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify for クラウド運用・特権 ID — 管理コンソールのパスワードを、使う人が誰も知らない状態に　IP 制限も、管理画面の設定も、そのまま > ID とパスワードは管理者が Junify に登録し、担当者は自分のスマホで本人確認をしてクリックするだけ。コンソールには Junify が代わりに入力するので、パスワードは知らないまま、共有 ID でも記録は一人ひとり残ります。 必要なのは、担当者のスマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。会社支給でないパソコンでも使えます。 ## いまは、こうなっていませんか 多くの運用チームでは、まだこうなっています。パスワードを教える以外に、方法がなかったからです。 - 管理者用 ID を複数人で共有。ログは共有 ID の名前だけで、誰の操作か分からない。 - パスワードを台帳(Kintone 等)で管理。見た人は全員が知り、取り消せない。 - 退職・異動のたびに、パスワードを変えて全員に周知。変え忘れれば、そのまま入れる。 - 二段階認証の認証アプリは、特定の人のスマホに。その人がいないと、誰も入れない。 - IP 制限はかけているが、許可した IP の中の「誰か」までは分からない。 > - 一度教えたパスワードは、取り戻せない > - 共有の管理者用 ID では、誰の操作かが残らない > - 辞めた人を止めるには、変えて全員に配り直すしかない ## 仕組み(3 ステップ) はじめに、管理者がコンソールの ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡さず、コンソールの設定もそのまま。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。Okta や Entra ID のログインでも入れます。 2. **カードをクリックしてログイン** — 使ってよいコンソールが「カード」として並びます。クリックすると、ブラウザーの Junify 拡張機能が ID とパスワードを入力。本人は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有の管理者用 ID でも記録は一人ひとり(証跡)。必要なコンソールには録画も。本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの運用はこうなります 新しい管理者を任せる日、担当が外れる日、記録を求められる日。それぞれ、運用チームはこう動けます。 - **退職・異動の日** — 管理者が割り当てを外すだけ。その瞬間から入れません。パスワードは本人に渡していないので、変更も周知も要りません。 - **監査の日** — 誰が・いつ・どのコンソールに入ったかを、一人ひとり出せます。本人確認をしてから使うので、共有 ID のままで答えられます。CSV で提出できます。 - **誤操作・事故の日** — 録画を付けたコンソールなら、再生してその日のうちに報告できます。録画のないコンソールでも、誰がいつ入ったかは残っています。 - **新しい管理者を任せる日** — 管理者がカードを割り当てるだけで、初日から始められます。パスワードは教えません。本人は QR を読んでクリックするだけ。 ## 運用の現場で効くこと - **パスワードだけの管理画面にも** — ドメイン・決済・DNS の管理画面には、SAML 非対応のものが残ります。そこでもパスワードを見せずにログインでき、記録は一人ひとりです。 - **二段階認証のコードも Junify が入力** — 認証アプリにコードが表示される方式なら、コードも Junify が入力します。一人のスマホに縛られません。本人のスマホはコンソールの手前に残ります。 - **ログインの後にも、手が届く** — 困るのは、入った後の操作です。カードで開いた画面は Junify が管理する窓の中で動くので、管理者が終了でき、アップロード検知・ダウンロード制御も。 - **端末にパスワードを残さない** — 出先や自宅の端末から入ると、パスワードや履歴が残ります。カードから開いた画面は履歴を残さないモードの窓で動き、閉じればどちらも残りません。 ## IP 制限は、外すことになりませんか IP 制限は、外しません。通信は担当者のブラウザーと管理画面の間で行われ、送信元の IP は変わりません。Junify はログインの瞬間に ID とパスワードを入力するだけです。Junify 側でも IP と位置情報で制限できます。 ## 既存の IdP との共存 Okta や Entra ID はそのまま。Junify は、その外に残るアカウントを引き受けます。 SAML や OIDC でログインできるアプリと、社員一人ひとりの ID は、これまでどおり IdP に。それでも残るもの(SAML に対応していない管理画面と、IdP に載せられない管理者用 ID)を、Junify が同じ水準に引き上げます。 **IdP がこれまでどおり担うこと** — 社員の本人認証と、SAML・OIDC 対応アプリへの SSO。SCIM 対応アプリの入退社連動。端末や場所による条件付きアクセス。 **IdP の外に残り、Junify が引き受けること** - **複数人で使う管理者用 ID・部門の共有アカウント。** Okta の SWA や Entra ID の password-based SSO でも自動入力はでき、「誰がいつ開いたか」は残ります。違いはログインした後。録画・アップロード検知・ダウンロード制御・遠隔終了を設定できます。 - **IdP に載せていない人。** 兼務や短期の担当者、社外のエンジニアなど、IdP にアカウントを作るほどではない人にも、本人のスマホの本人確認で、必要なカードだけを割り当てられます。記録は同じ個人単位です。 - **会社が管理していない端末。** MDM の入っていない端末から入る必要が出ても、Junify が開くブラウザーの窓の中だけを統制し、パスワードや閲覧の痕跡を端末に残しません。 - **同じ SaaS の複数テナント・複数アカウント。** 本番・検証・部門ごとに分かれたアカウントを、それぞれのカードとして整理し、取り違えを防ぎます。 **共存の形** - 本人確認は IdP に任せる — ステップ 1 の本人確認を、IdP からの SAML ログインで行えます。 - ユーザーは IdP と同期 — Entra ID・Active Directory・SCIM から、入退社に追随させます。 - IdP に載せない人は、スマホの Junify アプリで本人確認 — メールアドレスがなくても QR からログインできます。 全員に個人アカウントを発行でき、SAML・OIDC と SCIM で管理しきれるなら、IdP だけで十分です。Junify の出番は、その前提から外れるアカウントが残るときです。 ## 実際の導入から - **AWS 運用(特権 ID)** — コンソールのパスワードを台帳で管理していました。Junify に移し、担当者はカードからログインする形に。誰が・いつ入ったかが、一人ひとり残ります。 ## よくある質問 1. **管理コンソールのパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 2. **二段階認証が必須のコンソールは?** — 認証アプリにコードが表示される方式なら、コードも Junify が入力します。SMS やメールで届くコードは対象外です。カードを開けるのはスマホで本人確認した人だけなので、本人のスマホはコンソールの手前に残ります。 3. **IP 制限を外す必要がありますか?** — ありません。通信は担当者のブラウザーと管理画面の間で行われます。Junify はログインの瞬間に ID とパスワードを入力するだけで、経路の途中には入りません。 4. **担当外の人が、急に入る必要が出たら?** — 管理者がその人にカードを割り当てるだけで、その場で入れます。パスワードを共有し直す必要はありません。必要なのは本人のスマホの Junify アプリとブラウザーの拡張機能だけで、会社支給でない端末でも使えます。 5. **画面の録画は、誰が設定して、誰が見るのですか?** — 管理者が、必要なコンソールにだけ設定します。始まる前に本人へ表示され、見られるのは本人と管理者だけ。画面の変化だけを記録する軽い方式です。誰が・いつ入ったかの記録(証跡)は、録画とは別に CSV で出せます。 6. **Okta などの IdP を使っています。** — IdP はそのままです。Junify への本人確認を IdP のログインに任せ、IdP に載らない管理画面と共有の管理者用 ID を Junify で管理する構成にできます。置き換えではありません。 7. **PAM 製品やパスワードマネージャーとの違いは?** — PAM は踏み台に通信を通します。Junify は経路を変えず、ログインの瞬間に入力するだけ。サーバー・OS の特権管理は対象外です。パスワードマネージャーは本人にパスワードを見せますが、Junify は見せません。 8. **料金は?** — 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。円建ての固定額で、運用チームの規模に合わせてデモの際にご案内します。 ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## 会社 Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。 - 金融機関・上場企業を含む導入実績 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供 - 稼働状況を常時公開(https://status.junify.com) ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try?scenario=privileged-access - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify for SNS・広告・EC 運用代行 — 「御社になら、SNS 公式・広告・EC のアカウントを預けられる」と言われる会社に > クライアントから預かった ID とパスワードは管理者が Junify に登録し、担当者は自分のスマホで本人確認をしてクリックするだけ。担当者にパスワードを教えないまま任せられ、誰が・いつ・どのアカウントを使ったかは担当者ごとに残ります。 体験デモは広告運用の担当者として進みます。必要なのは、スマホの Junify アプリとブラウザーの Junify 拡張機能だけ。 ## いまは、こうなっていませんか これまでは、預かった ID とパスワードを担当者に教えるしかありませんでした。いまは、教えなくても任せられます。それでも多くの運用代行は、まだこうなっています。 - クライアントの SNS・広告のパスワードを、担当チームで共有している - 退職や担当交代のたびに、クライアントにパスワード変更をお願いしている - 誤投稿があっても、共有アカウントの記録に「誰が」は残らない - 一人が複数クライアントの同じ管理画面を扱い、取り違えを防ぐ手立てがない - 在宅の担当者が私物のパソコンから入り、端末に何が残るか分からない - 二段階認証のコードが一人のスマホにしか出ず、その人がいないと入れない いまの運用の代償: 一度教えたパスワードは、取り戻せない。共有のアカウントでは、誰がやったかが残らない。辞めた人を止めるには、クライアントに変更を頼むしかない。 ## 仕組み(3 ステップ) はじめに、御社の管理者が預かった ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡さず、媒体の設定も変えません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。業務委託の担当者も、御社のメールアドレスなしで使えます。 2. **カードをクリックしてログイン** — 使ってよいアカウントがクライアント・媒体ごとの「カード」として並びます。クリックすると Junify が ID とパスワードを入力。担当者は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は担当者ごと(証跡)。必要なアカウントには録画も。本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの会社はこうなります 商談の日、誤投稿の日、担当が代わる日、新しい人が入る日。それぞれ、御社はこう動けます。 - **商談の場で** — 「パスワードは担当者に渡していません。誰がいつ使ったかは記録が残ります」と、その場で答えられます。質問票や監査にも、仕組みで答えられます。 - **誤投稿・誤設定の日** — 誰がやったかを、その日のうちにクライアントへ報告できます。記録は担当者ごと。録画を付けたアカウントなら、何をしたかまで画面で。 - **担当交代・退職の日** — クライアントにパスワード変更を頼む必要が、なくなります。割り当てを外すだけで、その瞬間から入れません。パスワードは、もともと渡していません。 - **新しい人が入った日** — 初日から、パスワードを教えないまま始めてもらえます。担当クライアントのカードだけが並ぶので、別のクライアントに投稿する取り違えも防げます。 ## 運用の現場で効くこと - **私物のパソコンでも** — 私物のパソコンでは、端末に何が残るか分かりません。カードから開いた画面は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。 - **クライアントの二段階認証も** — コードが一人のスマホにしか出ず、その人がいない日は入れません。認証アプリにコードが出る方式なら Junify が入力。SMS・メールは対象外。 - **画面操作の録画** — 誤投稿の原因を調べるには、「誰が」だけでは足りません。予算変更・入稿・投稿の画面操作を、必要なアカウントにだけ管理者が録画できます。 - **顧客リスト・レポートの持ち出し対策** — 顧客リストやレポートを扱うアカウントは、持ち出しが心配です。ダウンロードはアカウントごとに止められ、アップロードは検知して管理者に通知。 ## 自社のアカウントの方へ **自社の SNS 公式や社内ツールの共有アカウントも、同じ仕組みで** ここまでは、運用代行の側で Junify を入れ、クライアントから預かったアカウントを担当者に使わせる形です。アカウントを持つ会社が管理者になって代理店やチームに使わせる形、社内の Google や AI ツールなどの共有アカウントを扱う形もあります。 自社のアカウントの使い方は、社内の共有アカウントのページへ。 https://www.junify.jp/shared-accounts ## 実際の導入から - **広告運用代行** — クライアントの広告アカウントのパスワードを担当者に教えるのをやめ、担当者ごとにカードを渡し、誰が使ったかが残る形に。社員のログインの仕組み(SSO)はそのまま。 ## よくある質問 1. **クライアントのパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 2. **クライアントのアカウントに二段階認証があります。** — スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 3. **SNS や広告以外の管理画面も、同じように使えますか?** — 使えます。ID とパスワードでログインする Web サービスなら、同じようにカードとして登録できます。Google のアカウントや AI ツールなど、社内で共有しているものも対象です。 4. **在宅や業務委託の担当者の、私物のパソコンでも使えますか?** — 使えます。パソコンにはブラウザーの Junify 拡張機能、スマホには Junify アプリを入れます。カードから開いた画面は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。 5. **担当者の画面を録画すると聞くと、監視のようで気になります。** — 録画は、管理者が必要なアカウントにだけ付けます。始まる前に本人へ表示され、見られるのは本人と管理者だけです。画面の変化だけを記録する軽い方式で、何かあったときに誰が何をしたかを画面で確かめるためのものです。 6. **担当者ごとに権限を出せる媒体は、それで足りませんか?** — 出してもらえる媒体では、それを使うのが先です。それでも媒体とクライアントごとに権限を付け外しする作業は残ります。Junify なら一つの場所で管理でき、退職や交代のときは一人分をまとめて外せます。録画も付けられます。 7. **担当者がすでにパスワードを知っている場合は?** — Junify に登録する際にクライアントと相談してパスワードを変更し、新しいパスワードを Junify だけが保持する運用を推奨しています。以後は Junify を通してのみログインできます。 8. **料金は?** — Junify を使う担当者の人数で決まります。上限の人数までなら何名でも同じ料金で、クライアントのアカウント数では課金しません。円建ての固定額で、3 つのプランは BPO・運用代行のページに載せています。 ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## 会社 - Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。 - 金融機関・上場企業を含む導入実績。 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。 - 稼働状況を常時公開: https://status.junify.com ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分。広告運用の担当者として進みます): https://www.junify.jp/bpo/try?scenario=marketing-ops - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify for 人事・採用 — 採用シーズンに増える人にも、媒体のパスワードは渡さない > 採用媒体や人事系サービスの ID とパスワードは管理者が Junify に登録し、担当者は自分のスマホで本人確認をしてクリックするだけ。パスワードを知らないまま媒体の仕事を始められ、誰が・いつ使ったかは一人ひとり残ります。 必要なのは、スマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。 ## いまは、こうなっていませんか これまでは、媒体の ID とパスワードを教えるしかありませんでした。いまは、教えなくても任せられます。それでも多くの人事部は、まだこうなっています。 - 採用媒体の企業アカウントは 1 つ。担当者全員が同じ ID とパスワードで入る。 - 繁忙期に増える人にパスワードを教える。辞めるたびに変えて配り直す。 - 応募者データを誰がダウンロードしたか、媒体の履歴では分からない。 - 労務・給与・勤怠の管理者アカウントも 1 つ。人事と情シスが同じパスワードで入る。 - 二段階認証のコードは、認証アプリを入れた一人のスマホにしか届かない。 - 監査や内部統制で利用記録を求められても、共有アカウントの分は「誰が」を出せない。 いまの運用の代償: 一度教えたパスワードは、取り戻せない。媒体の履歴は、企業アカウントとしか残らない。辞めた人を止めるには、変えて全員に配り直すしかない。 ## 仕組み(3 ステップ) はじめに、管理者が採用媒体や人事系サービスの ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡しません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。メールアドレスがない人でも使えます。 2. **カードをクリックしてログイン** — 使ってよいアカウントが「カード」として並びます。クリックすると Junify が ID とパスワードを入力。認証アプリの二段階認証コードも。担当者は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は一人ひとり(証跡)。必要なアカウントには録画も。担当者本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。媒体側の設定はそのまま。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの人事部はこうなります 人が増える日、辞める日、記録を求められる日。それぞれ、人事部はこう動けます。 - **採用の繁忙期に人が増える日** — 管理者が新しい担当者を登録し、カードを割り当てるだけ。初日から媒体に入れます。担当者は QR を読んでクリック。パスワードは知らないままです。 - **担当者が退職・異動する日** — 管理者が割り当てを外すだけ。その瞬間から入れません。パスワードは渡していないので、変えて配り直す必要がありません。 - **監査・IPO 準備の場で** — 誰が・いつ・どのアカウントを使ったかを、一人ひとり CSV で出せます。本人確認をしてから使うので、共有アカウントでも記録は一人ひとり。 - **応募者情報の持ち出しが疑われた日** — 誰が・いつ使ったかを、その日のうちに確認できます。録画を付けたアカウントなら、画面で何をしたかも確かめられます。 ## 人事の現場で効くこと - **二段階認証のコードを、誰かに聞きに行かなくていい** — スマホの認証アプリにコードが出る方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 - **応募者データの持ち出しに、ログイン後も手が届く** — カードから開いた画面は、Junify が管理するブラウザーの窓の中。ダウンロードはアカウント単位で止められます。アップロードは検知して管理者に通知。 - **会社支給でないパソコンでも、痕跡を残さない** — Junify から開いた画面は、履歴を残さないモードで開きます。閉じれば、パスワードも閲覧の痕跡も端末に残りません。 - **入社・退職のたびに、一覧を手で直さなくていい** — 誰がどのアカウントを使えるかの一覧は、CSV で一括更新できます。社内の ID 基盤や SCIM 対応の人事システムと同期して、自動更新も。 ## 実際の導入から - **人事・採用(社名非公開)** — 採用サイトと人事系サービスの共有アカウントを、担当者が同じパスワードで使っていました。いまは、パスワードを渡さずに使い、誰が・いつ使ったかが一人ひとり残っています。 ## よくある質問 1. **媒体のパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 2. **媒体側が二段階認証を求めます。** — スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 3. **応募者の個人情報が録画に写ります。** — 録画は、管理者が必要と決めたアカウントにだけ付けます。見られるのは操作した担当者本人と管理者だけで、始まる前に担当者の画面にその旨を表示します。 4. **担当者のパソコンやスマホに、何を入れますか?** — スマホに Junify アプリ、ブラウザーに Junify の拡張機能の 2 つです。会社支給でないパソコンでも使え、開いた画面は履歴を残さないモードなので、閉じればパスワードも痕跡も残りません。 5. **すでに SSO を導入しています。** — SSO(社内の ID でまとめてログインする仕組み)はそのまま。SSO に対応していない媒体や人事系サービスの、ID とパスワードのアカウントだけを Junify に登録します。 6. **人事システムと連携できますか?** — 「誰がどのアカウントを使えるか」の一覧を、社内の ID 基盤(Entra ID・AD)や SCIM 対応のシステムと同期し、入社・退職に合わせて自動更新できます。対応していないシステムでは CSV で一括更新。 7. **料金は?** — 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。繁忙期に担当者が増えても、上限までは変わりません。円建ての固定額で、デモの際にご案内します。 ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## 会社 Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。 - 金融機関・上場企業を含む導入実績 - 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供 - 稼働状況を常時公開(https://status.junify.com) ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try?scenario=hr - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify for 社内の共有アカウント — 共有アカウントは、なくならない　なら、パスワードを渡さずに使わせる > 共有アカウントの ID とパスワードは管理者が Junify に登録し、担当者は自分のスマホで本人確認をしてクリックするだけ。パスワードを知らないまま使えて、共有のままでも「誰が・いつ使ったか」は一人ひとり残ります。 Okta や Entra ID をお使いなら、両者の分担は「既存の IdP との共存」にまとめています。 必要なのは、スマホの Junify アプリと、ブラウザーの Junify 拡張機能だけ。 ## いまは、こうなっていませんか これまでは、共有アカウントのパスワードを教えるしかありませんでした。いまは、教えなくても使わせられます。それでも多くの会社は、まだこうなっています。 - SSO に載らない SaaS が部門に残り、ログインは共有のパスワード頼み - SNS 公式・代表アドレス・部門共通 ID のパスワードを、全員が知っている - 退職のたびに共有パスワードを変え、残る全員に配り直している - 共有アカウントは誰が使ったかが残らず、監査で「誰が」を説明できない - 共有アカウントの二段階認証を、一人のスマホの認証アプリに頼っている - メールアドレスのないパート・アルバイトは、共有 ID で使わせている いまの運用の代償: パスワードを知っている人なら、誰でも入れる。共有のままでは、誰が使ったかが残らない。辞めた人を止めるには、変えて全員に配り直すしかない。 ## 仕組み(3 ステップ) はじめに、管理者(情シス)が共有アカウントの ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡しません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。Okta や Entra ID のログインでも入れます。 2. **カードをクリックしてログイン** — 使ってよいアカウントが「カード」として並びます。クリックすると Junify の拡張機能がサービスを開き、ID とパスワードを入力。本人は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は一人ひとり(証跡)。必要なアカウントには録画も。本人に事前表示、見るのは本人と管理者だけ。 担当者の準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。日々の操作は「QR を読んで、クリック」だけ。 ## 導入後、あなたの会社はこうなります 人が増える日、辞める日、記録を求められる日。それぞれ、情シスはこう動けます。 - **退職・異動の日** — 割り当てを外すだけ。その瞬間から入れません。パスワードは本人に渡していないので、変える必要も配り直す必要もありません。 - **監査・IPO 準備の場で** — 誰が・いつ・どのアカウントを使ったかを、一人ひとり出せます。本人確認してから使うので、共有のままでも記録は個人単位。CSV で提出できます。 - **事故の日** — 誰が使ったかは証跡から。録画を付けたアカウントなら、何をしたかまで。その日のうちに報告できます。セッションは、管理者が遠隔で終了できます。 - **パート・アルバイトが増える日** — IdP にアカウントを作らなくても、必要なカードだけを割り当てられます。スマホで本人確認するので、メールアドレスがなくても記録は一人ひとり。 ## 社内の現場で効くこと - **SSO に載らない SaaS・ツールにも** — SAML 非対応のサービスは IdP に載せられません。ID とパスワードでログインするサービスなら Junify に登録でき、サービス側の設定は変えません。 - **二段階認証を、一人のスマホに頼らない** — 二段階認証が一人のスマホ頼みだと、不在の日は入れません。認証アプリにコードが出る方式なら Junify が入力。SMS・メールで届くコードは対象外。 - **社員は IdP で、それ以外の人はスマホで** — IdP にアカウントのない人のログインが残ります。社員は IdP(SAML)で、それ以外はスマホの Junify アプリで。どちらで入っても、記録は一人ひとり。 - **会社が管理していない端末が残る現場でも** — MDM のない端末には、パスワードや閲覧の痕跡が残ります。カードから開く画面は履歴を残さない窓で動き、閉じればパスワードも痕跡も残りません。 ## 既存の IdP との共存 Okta や Entra ID はそのまま。Junify は、その外に残るアカウントを引き受けます。 SAML や OIDC でログインできるアプリと、社員一人ひとりの ID は、これまでどおり IdP に。それでも残るもの(SNS 公式や部門ツールの共有アカウント)を、Junify が同じ水準に引き上げます。 **IdP がこれまでどおり担うこと** — 社員の本人認証と、SAML・OIDC 対応アプリへの SSO。SCIM 対応アプリの入退社連動。端末や場所による条件付きアクセス。 **IdP の外に残り、Junify が引き受けること** - **複数人で使う管理者用 ID・部門の共有アカウント。** Okta の SWA や Entra ID の password-based SSO でも自動入力はでき、「誰がいつ開いたか」は残ります。違いはログインした後。録画・アップロード検知・ダウンロード制御・遠隔終了を設定できます。 - **IdP に載せていない人。** パート・アルバイトなど、IdP にアカウントを作らない人にも、本人のスマホの本人確認で、必要なカードだけを割り当てられます。記録は同じ個人単位です。 - **会社が管理していない端末。** MDM の入っていない端末から入る必要が出ても、Junify が開くブラウザーの窓の中だけを統制し、パスワードや閲覧の痕跡を端末に残しません。 - **同じ SaaS の複数テナント・複数アカウント。** 部門・業務ごとのアカウントを、それぞれのカードとして整理し、取り違えを防ぎます。 **共存の形** - 本人確認は IdP に任せる — ステップ 1 の本人確認を、IdP からの SAML ログインで行えます。 - ユーザーは IdP と同期 — Entra ID・Active Directory・SCIM から、入退社に追随させます。 - IdP に載せない人は、スマホの Junify アプリで本人確認 — メールアドレスがなくても QR からログインできます。 全員に個人アカウントを発行でき、SAML・OIDC と SCIM で管理しきれるなら、IdP だけで十分です。Junify の出番は、その前提から外れるアカウントが残るときです。 ## よくある質問 1. **共有をやめて、個人アカウントにすべきでは?** — できるものは個人アカウントにするのが先です。それでも、SNS 公式や代表アドレスのようにひとつしかないものは残ります。残った共有アカウントを本人確認してから使う形にし、誰が使ったかを残すのが Junify です。 2. **SWA や password-based SSO との違いは?** — どちらも、パスワードを預けて自動入力はできます。違いはログイン後です。Junify は録画・アップロード検知・ダウンロード制御・遠隔終了をアカウントごとに設定でき、IdP に載せていない人にも同じ記録を残せます。 3. **SSO を入れています。意味がありますか?** — SSO はそのまま。SSO に載らない共有アカウントだけを Junify に登録し、Junify へのログインは既存の IdP に任せる構成にできます。SSO を維持したまま共有アカウントだけを移した導入企業があります。 4. **パスワード管理ツールとの違いは?** — パスワード管理ツールは、パスワードを本人に見せて共有する道具です。いちど見せたパスワードは取り戻せません。Junify は見せずに代わりに入力し、担当を外れたら割り当てを外すだけです。 5. **共有アカウントのパスワードを Junify に預けて大丈夫ですか?** — 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 6. **会社支給でないパソコンでも使えますか? 何を入れますか?** — 使えます。必要なのは、自分のスマホの Junify アプリと、ブラウザーの Junify 拡張機能の 2 つ。カードから開いた画面は履歴を残さない窓の中で動くので、閉じればパスワードも閲覧の痕跡も端末に残りません。 7. **料金は?** — 使う人数の上限が決まったプランで、その範囲なら何名で使っても同じ料金です。円建ての固定額。金額はデモの際にご案内します。 関連: 管理コンソール・管理者用 ID の説明は、クラウド運用・特権 ID のページへ https://www.junify.jp/privileged-access ## 核心 本人をスマホで特定し、パスワードは渡さず、記録は軽い仕組みで残り、端末を選ばない。この 4 つを 1 つの仕組みで満たします。 ## 会社 Junify Corporation。2016 年設立、米国 Palo Alto(470 Ramona St, Palo Alto, CA 94301)。金融機関・上場企業を含む導入実績。 米国の公的なセキュリティ基準(NIST CSF)に準拠した体制で、審査の際には BCP・セキュリティ文書をご提供します。稼働状況は https://status.junify.com で常時公開しています。 ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try?scenario=shared-accounts - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロードする: https://www.junify.jp/bpo/download - メール: info@junify.com --- # Junify の仕組み — パスワードを渡さずに、ログインさせる仕組み > 管理者が登録した ID とパスワードを、担当者に見せないままログインに使わせます。担当者は自分のスマホで本人確認をして、使ってよいアカウントをクリックするだけ。必要なのは、スマホの Junify アプリとブラウザーの Junify 拡張機能の 2 つです。 URL: https://www.junify.jp/product ## 使い方は 3 ステップ はじめに、管理者が ID とパスワードを Junify に登録し、誰に使わせるかを決めます(割り当て)。パスワードは担当者に渡しません。 1. **スマホで本人確認** — パソコンの画面に出る QR を、自分のスマホの Junify アプリで読んでログイン。これが本人確認です。メールアドレスがない人でも使えます。 2. **カードをクリックしてログイン** — 使ってよいアカウントが「カード」として並びます。クリックすると Junify が ID とパスワードを入力。本人は見ません。 3. **誰が使ったかが自動で残る** — 本人確認してから使うので、共有アカウントでも記録は一人ひとり(証跡)。必要なアカウントには録画も。本人に事前表示、見るのは本人と管理者だけ。 準備は、スマホのアプリとブラウザーの拡張機能の 2 つ。対象のサービス側の設定は変えません。日々の操作は「QR を読んで、クリック」だけ。 ## 管理者ができること - **割り当てと解除** — 誰にどのアカウントを使わせるかをカード単位で決め、担当が終わればその場で外します。パスワードを変えて配り直す必要はありません。 - **一人ひとりの記録** — 誰が・いつ・どのアカウントを使ったかが本人単位で残り、CSV で出せます。 - **画面の録画** — 必要なアカウントにだけ設定します。動画ではなく画面の差分として保存するので軽く、長く残せます。始まる前に本人に表示され、見られるのは本人と管理者だけ。 - **持ち出しの制御** — ファイルのダウンロードをアカウントごとに許可・禁止。アップロードは検知して管理者に通知します。 - **二段階認証にも** — 認証アプリにコードが出る方式なら、そのコードも Junify が入力します(SMS・メールで届くコードは対象外)。 - **IP 制限・位置情報** — 対象サービス側の IP 制限はそのまま使えます(Junify は経路の途中に入りません)。位置情報によるアクセス制御も設定できます。 - **遠隔でのセッション終了** — 管理者が、開いているセッションをその場で終了できます。 - **人事システム・IdP との連携** — Entra ID・Active Directory・SCIM から入退社に追随させます。本人確認を IdP からの SAML ログインで行うこともできます。 ## 端末について - **会社支給でないパソコンでも** — パソコンに入れるのはブラウザーの拡張機能だけ。カードから開いた窓は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。MDM は要りません。 - **ID とパスワードだけのサービスにも** — SSO がなくても、ログイン画面があればそのまま使えます。 ## 既存の IdP との共存 Okta や Entra ID はそのまま。SAML や OIDC でログインできるアプリと、社員一人ひとりの ID は、これまでどおり IdP に。それでも残るもの(共有アカウント、SSO 非対応の SaaS、IdP に載せない人)を、Junify が同じ水準に引き上げます。 - IdP がこれまでどおり担うこと: 社員の本人認証と、SAML・OIDC 対応アプリへの SSO / SCIM 対応アプリの入退社連動 / 端末や場所による条件付きアクセス - IdP の外に残り、Junify が引き受けること: 複数人で使う管理者用 ID・部門の共有アカウント / IdP に載せていない人 / 会社が管理していない端末 / 同じ SaaS の複数テナント・複数アカウント - 共存の形: 本人確認は IdP に任せる(SAML ログイン)/ ユーザーは IdP と同期(Entra ID・Active Directory・SCIM)/ IdP に載せない人は、スマホの Junify アプリで本人確認 全員に個人アカウントを発行でき、SAML・OIDC と SCIM で管理しきれるなら、IdP だけで十分です。Junify の出番は、その前提から外れるアカウントが残るときです。 ## 会社 Junify Corporation。2016 年設立、米国シリコンバレー(Palo Alto)。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況を常時公開(https://status.junify.com)。作っている人たち: https://www.junify.jp/about ## 次の一歩 - 登録不要で、実際に触ってみる(約 5 分): https://www.junify.jp/bpo/try - 30 分デモを予約する: https://www.junify.jp/bpo/demo - 資料をダウンロード: https://www.junify.jp/bpo/download - メール: info@junify.com --- # 作っている人たち — 大きくなる会社の内側で見てきたことを、製品にした > Junify は、パスワードを渡さずに仕事を任せるための仕組みです。作っているのは、楽天が 11 人から 2 万人になるまで技術部門を率いた元 CTO と、上場企業で技術部門を率いた経験者たち。創業者は日本人で、2016 年から 10 年、日本のお客様に日本語で向き合ってきました。本社は米国にあります。 URL: https://www.junify.jp/about ## 1998 年 — 11 番目の社員 Junify の創業者で CEO の安武弘晃(Hiro)は、1998 年、創業間もない楽天に社員番号 11 番のエンジニアとして入りました。楽天市場を創業期から作り、会社が数十人、数千人、2 万人と大きくなるあいだ、技術の中核にいました。2005 年に執行役員、2007 年からは取締役常務執行役員として、楽天グループの開発部門を統括しました(2016 年 1 月退任)。 ## 1998 〜 2016 年 — 会社が大きくなるとき、何が起きるか 安武の担当はプロダクトだけではありませんでした。社内の IT、セキュリティ、海外拠点の統制。会社が大きくなるたびに規則と道具が増え、その多くは現場に負担を残すだけで、事故を防いではくれない。 パスワードを覚え、共有し、変え、配り直す。どれも真面目に運用されているのに、人の注意力に頼る仕組みは、規模が大きくなるほど守りきれなくなります。何が形だけで、何が本質的な解決なのか。安武はそれを、18 年間、会社の内側から見続けました。 ## 2016 年 — シリコンバレーで、Junify を設立 楽天を退任した 2016 年、安武は米国に移り、Junify を設立しました。本社はカリフォルニア州パロアルト(シリコンバレー)に置きました。 出発点はひとつの考えです。**人をパスワード管理の制御点にしない。** 秘密(パスワード)を配るのではなく、使う権利を配る。 本人はスマホで本人確認をしてクリックするだけ。パスワードは Junify が入力し、誰が・いつ・何を使ったかが一人ひとり残る。いまご覧いただいている Junify は、この考えを 10 年かけて製品にしたものです。仕組み: https://www.junify.jp/product ## 共同創業者 — もう 1 人の創業者も、会社が大きくなる現場にいた 共同創業者で CTO の浜田卓(Takashi)は、米国企業の Indeed に日本人で初めての新卒エンジニアとして入社し、主にバックエンドの開発を担当しました。 2015 年、創業期の Branding Engineer(現 TWOSTONE&Sons)に取締役 CTO として加わりました。社員が数人のころから 70 人規模になるまで開発を率い、在任中に複数のサービスを立ち上げています。同社は浜田の退任後、2020 年に東証マザーズ(現グロース市場)に上場しました。 2016 年に安武と Junify を創業し、それから 10 年、シリコンバレーを拠点に Junify の製品と技術を率いています。 ## チーム — 上場企業の水準を、内側から知っているチーム Junify を作っているのは、CTO 経験者が中心のチームです。上場企業で技術部門を率いた経験者が複数います。 上場企業が求めるセキュリティと内部統制の水準を、求める側と応える側の両方で知っています。Junify は、日本の金融機関・上場企業の審査に応えてきました。 ## 現在 — いまも、上場企業の経営に関わっています 安武は現在も、マネーフォワード、テクマトリックスなど上場企業の社外取締役を務め、2019 年からは日本 CTO 協会の理事として、日本企業の技術経営に関わっています。上場企業の取締役会で審査する側に座る人間が、Junify を作っています。 ## 日本のお客様へ — 米国の会社ですが、日本のお客様に日本語で向き合っています お問い合わせから導入後のサポートまで、日本語で対応します。料金は円建てです。契約審査や、お客様の取引先への説明に使えるセキュリティ文書・BCP・サブプロセッサー一覧をご提供しています。 ## 信頼のかたち - 2016 年の設立から、同じ創業者が 10 年作り続けています - 日本の金融機関・上場企業を含む導入実績 - お預かりする ID・パスワードは暗号化して保管。保管方式とデータの所在は、審査時にセキュリティ文書でご説明します - NIST CSF(米国国立標準技術研究所のセキュリティ枠組み)に沿って体制を整備し、その内容をセキュリティ文書として審査時にご提供 - 稼働状況を常時公開(https://status.junify.com) - 利用規約(https://www.junify.jp/terms)・プライバシーポリシー(https://www.junify.jp/privacy)・サブプロセッサー一覧(https://www.junify.jp/subprocessor_list)を公開。契約条件は利用規約に記載しています ## 沿革 - 2016 年 — 米国カリフォルニア州パロアルトで設立 - 2019 年 5 月 — 株式会社チームスピリットとの提携を発表(https://www.junify.jp/Junify-Press-Release-jp.pdf) ## 創業者 - 安武 弘晃 Hiroaki Yasutake — Co-Founder | CEO。元楽天 CTO(取締役常務執行役員、技術部門統括)。マネーフォワード・テクマトリックス 社外取締役、日本 CTO 協会 理事。(https://www.linkedin.com/in/hiroaki-yasutake-3048291/) - 浜田 卓 Takashi Hamada — Co-Founder | CTO。元 Indeed ソフトウェアエンジニア(日本人初の新卒採用)。元 Branding Engineer(現 TWOSTONE&Sons、東証グロース上場)取締役 CTO。2016 年の創業から Junify の製品と技術を担当。(https://www.linkedin.com/in/takashi-hamada-577b7b32/) ## 会社概要 - 社名: Junify Corporation - 設立: 2016 年 - 本社: 米国カリフォルニア州パロアルト(シリコンバレー)470 Ramona Street, Palo Alto, CA 94301 USA - 代表者: Co-Founder & CEO 安武 弘晃 - 事業内容: パスワードを渡さずに仕事を任せるための SaaS「Junify」の開発・提供 - お問い合わせ: info@junify.com(日本語)、またはお問い合わせフォーム(https://www.junify.jp/contact) ご相談・お見積りはお問い合わせ(https://www.junify.jp/contact)から。実際の画面は 30 分デモ(https://www.junify.jp/bpo/demo)でご覧いただけます。 --- # お問い合わせ — Junify > Junify をご検討頂き、ありがとうございます。フォームに会社名／ご連絡先をご記入頂き「送信」ボタンを押してください。弊社より折返しご連絡をさせて頂きます。 URL: https://www.junify.jp/contact メールでも受け付けています: info@junify.com。実際の画面を見ながら相談したい方は 30 分デモ(https://www.junify.jp/bpo/demo)へ。 ## フォームの項目 - 会社名(必須) - お名前(必須) - メールアドレス(必須。会社でご使用されている E-mail アドレス) - お問い合わせ内容(必須。スパム対策のため、URL をメッセージに含めることはできません) 送信後、「お問い合わせ内容を承りました。折り返し、担当者からご連絡させていただきます。」と表示されます。 --- # 共有アカウントの管理 共有アカウントは、1 つの ID とパスワードを複数人で使う状態です。個人に分けられるものは分け、残るものは誰が使ったかを残せる方法で管理します。 更新日: 2026-09-17 共有アカウントがある限り、退職のたびにパスワードを変えて配り直す手間と、誰が使ったかを説明できない状態の両方が残ります。 ## 共有アカウントとは何か 共有アカウントとは、1 つのサービス上の 1 つのアカウント(ID とパスワードの組)を複数の人が使う状態です。定義と法令上の位置づけは [共有アカウントとは](/guides/shared-accounts/what-is-shared-account) にまとめています。 ## なぜ生まれ、なぜなくならないか 生まれる理由はサービス側の設計にあります。Microsoft Entra ID の公式ドキュメントは、1 組のユーザー名とパスワードを複数人で使う場面を 2 つ挙げています。企業の SNS アカウントのようなアプリケーションと、Microsoft 365 の管理者アカウントのような、強い権限を持つ 1 つだけのアカウントです。人数分のアカウントを作れないサービスでは、共有が唯一の使い方になります。 なくならない理由も同じところにあります。サービス側の仕組みは、利用者側では変えられません。そのため、個人アカウントに分けられるのは、サービス側にその仕組みがあるものに限られます。SNS の公式アカウントや、一度のログインで複数のサービスに入れる仕組み(SSO)に載らない部門ツールの管理者アカウントは、分けたくても分けられないまま残ります。 ## 何が困るか 困りごとは 5 つに分かれます。 - 退職や異動のあとも、辞めた人がログインできる状態が続きます。パスワードを知っている人は、変えて配り直すまで誰でも入れます。 - 誰が操作したかを説明できません。サービス側の記録には、アカウントの名前しか残らないからです。 - 担当者が不在の日にログインできません。確認コードは、登録した 1 台のスマホに表示されるか、登録した電話番号にしか届きません。 - 私物端末にパスワードや履歴が残ります。ブラウザーの保存機能やメモに、共有パスワードがそのまま入るためです。 - 使っていないアカウントに気づけません。誰が使っているかが、台帳にも記録にも残っていないからです。 このうち退職と記録は、法令やガイドラインの要求と直接ぶつかります。個人情報保護委員会のガイドライン(通則編)は、個人データを扱う情報システムの利用者を「識別した結果に基づいて認証する」ことを求めています。誰かを確かめたうえでログインさせる、という意味です。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、共有 ID をやむを得ず使う場合に、利用した人を特定できる仕組みを求めています。どちらも共有そのものを禁じてはいません。しかし、誰が使ったかを特定する手段を用意する責任は、利用者側に残ります。 ## 管理の選択肢 複数人で使う方法は 4 つに分けられます。ID 管理サービス(Okta、Microsoft Entra ID など。社員のアカウントをまとめて管理し、一度のログインで複数のサービスに入れるようにするサービス)を使っているかどうかで、選べる方法が変わります。 | 方法 | できること | 残る限界 | 向く場面 | | --- | --- | --- | --- | | 手作業の台帳と定期変更 | 道具なしで始められ、誰が知っているかを台帳で追える | 全員がパスワードを知り、変更のたびに配り直す | 使う人が数人のとき | | パスワードマネージャーでの共有 | 保管庫を共有し、入力を自動化できる | 自動入力できる人はパスワードを使える | 配布と保管を整えたいとき | | ID 管理サービスが代わりに入力(Okta の SWA、Entra ID の password-based SSO) | パスワードを見せずにログインさせる | 対象は ID 管理サービスにアカウントのある人 | 使う人が全員そこにアカウントを持つとき | | アクセス管理ツール | 担当者に代わってパスワードを入力する | 対象アプリと端末の条件は製品ごとに確認する | ID 管理サービスにアカウントのない人を含むとき | 誰が使ったかの記録は、表の上 2 行と下 2 行で分かれます。手作業とパスワードマネージャーでは、サービス側の記録は共有アカウントの名前のままです。ID 管理サービスとアクセス管理ツールは、その手前で本人単位の記録を残します。パスワードマネージャーには、見られる範囲を絞れる製品もあります。端末の条件も方法ごとに違い、手作業は端末を問わず、パスワードマネージャーは保管庫を開ける端末で使い、ID 管理サービスはそのサービス側の設定で決まります。Entra ID の代わりの入力は、共有アカウントを使う利用者ごとに EMS または Entra ID P1 / P2 の契約プランが前提です。 管理者用アカウント(強い権限を持つ ID)の利用申請・承認と操作の記録を仕組みで行う特権 ID 管理(PAM)は、[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)で扱います。パスワード自体を担当者に配る道具(共有機能つきのパスワードマネージャーなど)は、上のパスワードマネージャーの行に含めます。 Okta の Secure Web Authentication(SWA)は、Okta にログインするだけで、ほかの Web アプリにも入れるようにする Okta の機能です。ID 管理サービスに認証を任せる方式(SAML などの規格でつなぐ方式)に対応していないアプリが対象です。管理者がアプリの ID とパスワードを設定でき、レポートでは誰がいつどのアプリにアクセスしたかを確認できます(公式ヘルプ)。Entra ID の password-based SSO は、Entra ID にパスワードを預けて代わりに入力させる機能です。共有アカウントを使う権限を持つ利用者は、パスワードを見ずに、ログインの手続きの中で使います。管理者はアクセスの付与と取り消しを行い、誰がいつアクセスしたかをサインインの記録(サインインログ)で確認できます(公式ドキュメント)。見られる範囲を絞れるパスワードマネージャーのうち、Bitwarden は、隠したパスワードも自動入力では使えると公式ヘルプに明記しています。詳しくは [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager) で扱います。 ## 何から始めるか 最初にするのは棚卸しです。サービス名、アカウントの ID、パスワードの保管場所、使っている人、管理者、二段階認証の受け取り先、最後に確認した日を一覧にします(最小の 7 項目。全項目は[棚卸しの記事](/guides/shared-accounts/shared-account-inventory)に)。この一覧がないと、次の 2 つの判断ができません。 次に、個人アカウントに分けられるものを分けます。利用者の枠を追加できるサービス、管理者権限を複数人に与えられるサービス、部門の代表アドレスは共有をやめられます。Microsoft 365 の共有メールボックスは、各自が自分のアカウントでアクセスする前提で作られています。公式ドキュメントには、共有メールボックス自体のアカウントではサインインしないようにと書かれています。代表アドレスをこの形にすれば、メールの共有と個人単位の認証を両立できます。 最後に、残るものの扱いを決めます。上の表から、使う人の範囲(ID 管理サービスにアカウントがあるか)、要る記録の細かさ(アカウント単位で足りるか、本人単位が要るか)、端末の条件(会社支給か私物か)で選びます。定期変更を続けるかどうかは、NIST SP 800-63B Revision 4の考え方が判断材料になります。同文書は、サービスを提供する側は利用者に定期的なパスワード変更を求めてはならず、パスワードが盗まれたなどの証拠がある場合は必ず変更させる、としています。共有アカウントで二段階認証を複数人が使うときの問題は [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification) で扱います。 ## このテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 - [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](/guides/shared-accounts/sharing-chatgpt-accounts-at-work): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 - [ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work): 個人アカウントのパスワードを、会社が管理するブラウザーの設定で、1 人が使う端末に限って保存するなら選択肢になります。共有アカウント、私物端末、個人アカウントへの同期が絡む場合は避けます。管理者の設定で保存を止められます。 - [共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods): 手作業、パスワードマネージャーの共有、ID 管理サービスによる代わりの入力、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure): 一度知られたパスワードは取り消せないため、退職のたびに変える運用には理由があります。限界は、変更後の配り直しと保存先の更新にかかる手間と、誰が知っているかの一覧がないまま起きる抜け漏れです。 - [パスワード管理規程のテンプレートと書き方](/guides/shared-accounts/password-policy-template): 規程に入れる項目は、適用範囲、パスワードの条件、保管、共有の禁止と例外、共有アカウント、二段階認証、変更、退職時の手続き、違反時の扱い、見直しの 10 項目です。各条を IPA と個人情報保護委員会の要求に対応づけ、文例を示します。 - [パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方)](/guides/shared-accounts/periodic-password-change): NIST SP 800-63B は、サービス側が利用者に定期変更を求めないよう定め、変更を必須にするのは盗まれた証拠があるときとしています。複数人で使う共有アカウントは、知っている人が変わるたびに変更が要ります。 - [共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory): 共有アカウントの棚卸しは、サービスごとに誰がパスワードを知っていて誰が使えるかを一覧にする作業です。見つけ方、台帳の項目、分ける・残す・廃止するの判定、更新のきっかけを順に示します。 - [共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification): 共有アカウントの二段階認証は、コードが 1 人のスマホにしか出ないか、登録用の QR コードを配って全員が出せるかのどちらかになります。方式ごとに起きる問題と、不在と退職に備える選択肢を整理します。 - [パスワードをスプレッドシートで管理する会社が最初に直すこと](/guides/shared-accounts/spreadsheet-password-management): 最初に直すのは、そのシートを開ける人の範囲です。次に台帳としての項目を整え、最後にパスワードの値だけを別の保管場所へ移します。一覧としてのスプレッドシートは残せます。 - [Slack・メールでパスワードを送るのをやめる方法](/guides/shared-accounts/stop-sending-passwords-in-chat): 送ったパスワードは検索で見つかり、転送や書き出しで広がり、端末と退職者のアカウントに残ります。やめるには、先に別の渡し方を用意し、そのうえで本文に書かないルールを決めます。 - [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager): パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。 - [共有アカウントとは](/guides/shared-accounts/what-is-shared-account): 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。 - [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification): 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。 - [共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split): 原則は 1 人 1 アカウントです。それでも、サービスがアカウントを 1 つしか持てない、公式アカウントそのもの、管理者アカウントが 1 つ、外部の人に発行できない、といった場合は共有が残ります。残すものに何を求めるかを整理します。 ## よくある質問 **共有アカウントは全部なくすべきですか** 個人アカウントに分けられるものは分けるのが先です。それでも 1 つしか作れない管理者アカウントや公式 SNS は残るので、残るものの管理方法を決めます。 **パスワードを定期的に変えれば安全ですか** 変えた後のパスワードを全員に配り直す以上、知っている人の範囲は変わりません。NIST SP 800-63B は定期変更を求めず、盗まれた証拠があるときは必ず変更させるとしています。 **台帳はどんな項目から作ればよいですか** サービス名、アカウントの ID、パスワードの保管場所、使っている人、管理者、二段階認証の受け取り先、最後に確認した日から始めると、次に決めることが見えます。 **Okta や Entra ID があれば共有アカウントは管理できますか** Okta の SWA や Entra ID の password-based SSO に ID とパスワードを預ければ、直接つなげないアプリでも代わりに入力できます。契約プランと対象アプリの条件は公式ヘルプで確認します。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「About shared mailboxes in Microsoft 365」](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [Bitwarden Help Center「Collection permissions」](https://bitwarden.com/help/collection-permissions/) - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify は、分けられずに残った共有アカウントを、担当者がスマホで本人確認をしてから使う形にする仕組みです。管理者が ID とパスワードを登録し、担当者はクリックするだけでログインするため、パスワードは担当者に渡らず、共有のままでも誰が・いつ使ったかは一人ひとり残ります。Okta や Entra ID はそのままで、そこに載らないアカウントだけを登録できます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # Google スプレッドシートにパスワードはかけられるか かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 更新日: 2026-10-13 Google の公式ヘルプは、シートの保護機能でできないことの一つに「パスワードでデータを保護する」を挙げています。見られる人を決めるのは、ファイルの共有設定です。シートや範囲の保護が決めるのは、編集できる人です。 ## パスワードの代わりに使える設定と、その限界 | 設定 | 防げること | 防げないこと | | --- | --- | --- | | 共有相手の指定(一般的なアクセスを「制限付き」に) | 指定していない人が開くこと | 指定した人が中身を読むこと | | ダウンロード・コピー・印刷できる人を絞る | ドライブの機能でファイルを持ち出すこと | ドライブの機能を使わない持ち出し | | シートや範囲の保護 | 指定していない人が編集すること | 見ること、写しを作って印刷・書き出しすること | | シートの非表示 | 画面で目に入りにくくすること | 閲覧者が中身にアクセスすること | 一般的なアクセスを「制限付き」ではなく「リンクを知っている全員」にすると、Google アカウントにログインしなくても開けます。 保護と非表示は、見られる人を減らす設定ではありません。公式ヘルプは保護を「セキュリティ対策ではありません」と位置づけ、守りは別に用意するよう求めています。非表示にしたシートも、閲覧者は中身にアクセスできると書かれています。パスワードの列を隠したり保護したりしても、ファイルを開ける人は値を読めます。 ## 一部だけ見せたくないときは、ファイルを分ける 見られる人を決める共有設定は、ファイルごとにかかります。シートや列ごとに見られる人を変える設定は、公式ヘルプには書かれていません。そのため、表の一部だけを特定の人に見せたくないなら、その部分を別のファイルに移し、そのファイルだけ共有相手を絞ります。 分けたファイルの共有相手を絞る操作は、[パスワードをスプレッドシートで管理する会社が最初に直すこと](/guides/shared-accounts/spreadsheet-password-management)に順番どおりまとめています。そこで扱っていない設定が 2 つあります。 - 対象となる職場や学校の Google アカウントでは、共有相手ごとにアクセスの有効期限を付けられます。期限は今日から 1 年以内で選びます。決まった期間だけ手伝う人に向きます。 - Google Workspace の管理者は、組織の外の人との共有をオフにできます。許可したドメイン(メールアドレスの @ より後ろ)の相手に限ることもできます。設定にはドライブとドキュメントの管理者権限が要ります。 ダウンロード・コピー・印刷を絞る設定にも限りがあります。公式ヘルプは「他のユーザーがファイルの内容をその他の方法で共有することまでは制限できません。」と書いています。 ## Excel のパスワードとの違い Microsoft Excel では、ファイルにパスワードをかけられます。公式ヘルプの手順は、「ファイル」→「情報」→「ブックの保護」→「パスワードで暗号化」です。暗号化は、パスワードがないと中身を読めない形にすることで、パスワードを知らない人はファイルを開けません。 一方で、そのファイルを使う人には、全員に開くためのパスワードを伝えることになります。Microsoft の公式ヘルプも「パスワードが意図しないユーザーの手に渡るリスクは依然としてあります。」と注意しています。パスワードを忘れた場合、Microsoft は回復できません。 ID とパスワードを書いた表を Excel に移しても、値を読める人の範囲は変わりません。表を使う人は、ファイルのパスワードも、中の値も知っているからです。担当者が抜けるたびに、ファイルのパスワードと、その人が見たサービスのパスワードの両方を変えて伝え直すことになります。伝える手段にチャットを使うと、その文面も残ります([Slack・メールでパスワードを送るのをやめる方法](/guides/shared-accounts/stop-sending-passwords-in-chat))。 ## ID とパスワードの表で残ること ここまでの設定で減らせるのは、表を開ける人と、持ち出しの手段です。読んだ人を共有から外しても、覚えた値と手元の控えは消せません。そのため、ID とパスワードの表では、パスワードの値を表に置き続けるかどうかを先に決めます。 値を表から移すときの方式は、大きく分けると、値を見せて共有するか、見せずに代わりに入力するかです。見せて共有する例が[パスワードマネージャー](/guides/shared-accounts/what-is-password-manager)で、共有した相手は値を見るか、自動入力で使えます。見せない方式では、管理者だけがパスワードを持ち、担当者にはパスワードを代わりに入力して使わせます。選び方は[共有アカウントの管理](/guides/shared-accounts)に、表から値を移す順番は先のスプレッドシートの記事にまとめています。 値を出した後も、表は「どのサービスのどのアカウントを誰が使うか」の一覧として残せます。この一覧にはパスワードの値がないため、開いた人がそのままログインに使える情報は載りません。 ## よくある質問 **一部のシートや列だけを隠せますか** 非表示にはできますが、閲覧者は中身を見られます。公式ヘルプによると、閲覧者は非表示のシートにもアクセスできます。見せたくない部分は別のファイルに分け、そのファイルの共有相手を絞ります。 **シートを保護すれば中身を見られませんか** 見られます。保護が止めるのは編集で、見ることではありません。公式ヘルプも、保護はセキュリティ対策ではないと書いています。 **リンクを知っている人だけなら安全ですか** 「リンクを知っている全員」の共有は、Google アカウントにログインしなくても開けます。リンクが転送されれば誰でも開けるため、見られたくない表では相手を指定します。 **Excel にしてパスワードをかければ安全ですか** 知らない人は開けなくなりますが、使う人全員にそのパスワードを伝えるので、共有するパスワードが 1 つ増えます。忘れると Microsoft も回復できません。 **ダウンロードを禁止すれば持ち出せませんか** Google ドライブ上でのダウンロード・コピー・印刷は止まります。公式ヘルプは、ほかの方法で内容を共有することまでは制限できないと書いています。 ## 参考資料 - [Google ドキュメント エディタ ヘルプ「Google ドライブのファイルを共有する」](https://support.google.com/docs/answer/2494822?hl=ja) - [Google ドキュメント エディタ ヘルプ「共有を停止、制限、変更する」](https://support.google.com/docs/answer/2494893?hl=ja) - [Google ドキュメント エディタ ヘルプ「シートを保護する、非表示にする、編集する」](https://support.google.com/docs/answer/1218656?hl=ja) - [Google Workspace 管理者ヘルプ「組織の外部共有を管理する」](https://knowledge.workspace.google.com/admin/drive/manage-external-sharing-for-your-organization?hl=ja) - [Microsoft サポート「Excel ファイルを保護する」](https://support.microsoft.com/ja-jp/office/7359d4ae-7213-4ac2-b058-f75e9311b599) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify に移すときは、表に書いていたパスワードをまず変え、新しい値は管理者だけが登録します。担当者は自分のスマホで本人確認をしてから使い、値を見ることはありません。人が抜けても、使ってよい人の指定(割り当て)からその人を外すだけで、パスワードを変えて表を書き直す作業はなくなります。誰が・いつ使ったかも一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 - [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](/guides/shared-accounts/sharing-chatgpt-accounts-at-work): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 --- # パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い) パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 更新日: 2026-10-13 パスワードの最小文字数は、指針によって 8 文字から 15 文字まで分かれます。値を比べるときは、二段階認証と組み合わせるかどうかと、文字の種類を混ぜる決まりがあるかどうかを合わせて見ます。ここでの二段階認証は、パスワードに加えて 2 つ目の確認を求める方式です。NIST の言う多要素認証にあたり、メールで届くコードは含みません。 ## 指針ごとの文字数と文字の種類の決まり | 資料 | 誰に向けた資料か | 最小の文字数 | 文字の種類 | 書き方の強さ | | --- | --- | --- | --- | --- | | NIST SP 800-63B Revision 4 | ログインを確かめるサービスの側 | パスワードだけなら 15 文字、二段階認証と併用なら 8 文字 | 混ぜる規則を課してはならない | 長さは必須(SHALL)、文字の種類の規則は禁止 | | 総務省 国民のためのサイバーセキュリティサイト | 一般の利用者 | 10 文字以上 | 数字・記号・大文字・小文字が混ざるのが好ましい | 理想として | | IPA 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版 | 中小企業 | 10 文字以上 | 大文字・小文字・数字・記号を含める | 対策の例 | | 厚労省 医療情報システムの安全管理に関するガイドライン 第 7.0 版 | 医療機関 | 二要素認証ありなら 8 桁、なしなら 13 桁 | 英字と数字を混ぜる | 8 桁は「求められる」、13 桁は「とすること」 | NIST と厚労省は、二段階認証を使うかどうかで下限を分けています。方式の違いは[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)にまとめています。 ## NIST SP 800-63B の決まり NIST SP 800-63B は、米国国立標準技術研究所(NIST)が定める、ログインの本人確認のガイドラインです。現行版は 2025 年に出た Revision 4 で、パスワードの決まりは 3.1.1.2 節にあります。この節が求める相手は、パスワードを受け取って確かめる側と、ID を発行して管理する側です(原文では Verifiers and CSPs)。 長さの決まりは 2 段に分かれます。パスワードだけでログインさせるなら、15 文字以上を求めなければなりません(SHALL)。二段階認証の一部として使うなら短くしてもよい(MAY)ものの、8 文字以上は求めなければなりません(SHALL)。上限は、64 文字以上まで受け付けることを勧めています(SHOULD)。 文字の種類を混ぜさせる組み合わせの規則は、課してはならない(SHALL NOT)としています。同じ節が求めることには、ほかに次の 2 つもあります。1 つは、漏えい済みのパスワードやよく使われるパスワードの一覧(ブロックリスト)と照らし合わせることです(SHALL)。もう 1 つは、パスワード管理ツール([パスワードマネージャー](/guides/shared-accounts/what-is-password-manager))と自動入力の利用を認めることです(SHALL)。 前の版(2017 年)では、下限は一律に 8 文字(SHALL)で、組み合わせの規則は課すべきではない(SHOULD NOT)という推奨でした。Revision 4 は、パスワードだけの場合の下限を 15 文字に上げ、組み合わせの規則を禁止に強めました。 ## 日本の公的機関の資料 総務省の「国民のためのサイバーセキュリティサイト」は、一般利用者向けのページで理想の長さを示しています。最低でも 10 文字以上のランダムな英数字の並びで、数字や記号、大文字・小文字が混ざっているのが好ましいとしています。覚えておく必要があるなら、関係のない単語をいくつかつなげ、間に数字を挟む作り方も示しています。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部でパスワードの対策例を挙げています。10 文字以上にすること、大文字・小文字・数字・記号を含めること、名前や電話番号、誕生日、簡単な英単語を使わないことです。 国家サイバー統括室の「インターネットの安全・安心ハンドブック」Ver 5.10 は、第 5 章でパスワードを扱います。ログイン用のパスワードには、英大文字・小文字・数字・記号を使った複雑さと、一定以上の長さが勧められるとしています。企業・従業員向けの講習テキストは、できるだけ長くし、使い回さないよう求めています。 厚労省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、システム運用編 14.1.1 で桁数を示しています。二要素認証を使う場合は 8 桁以上で、英字と数字を混ぜます(大文字・小文字は問いません)。使わない場合は 13 桁以上です。医療機関での当てはめ方は[厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる](/guides/healthcare-access/mhlw-guideline-authentication-and-access-control)にまとめています。 ## 記号を混ぜる決まりは今も要るか IPA とハンドブックは記号を含めることを勧め、総務省は理想として挙げています。厚労省は英字と数字を混ぜるところまでです。一方、NIST が組み合わせの規則を禁じる理由は、同じ文書の付録 A「パスワードの強さ」に書かれています。 付録 A は、長さをパスワードの強さを決める主な要素の一つとしています。文字の種類を混ぜる規則については、利用者の作るパスワードが予想しやすい形にそろうと説明しています。例は、「password」を選ぶ人が、大文字と数字を求められると「Password1」を選びやすいというものです。記号も求められれば「Password1!」になります。また、複雑なパスワードほど覚えにくく、書き留めたり安全でない形で保管したりされやすいとも書いています。 記号を必須にする規則をやめるなら、NIST が同じ節で求める長さと、漏えい済みの一覧との照合を合わせて取り入れます。規程にどう書くかは[パスワード管理規程のテンプレートと書き方](/guides/shared-accounts/password-policy-template)で扱っています。 ## 文字数を決める前に分けて考えること ### 社内システムの設定か、従業員のルールか 社内システムのログインの設定を決めるとき、会社はパスワードを受け取って確かめる側にいます。そのため、NIST の 3.1.1.2 節の決まりは、その設定にそのまま当てはめられると読めます。外部のサービスでは、最小文字数や文字の種類はそのサービスが決めます。会社が決められるのは、従業員がそこで作るパスワードについての社内ルールです。 ### 二段階認証を使えるか NIST と厚労省の下限は二段階認証の有無で変わるため、先に二段階認証を使えるかを確かめます。共有アカウントでは、二段階目のコードが 1 人のスマホにしか出ず、ほかの担当者が使えないことがあります。そのため二段階認証を切って運用しているなら、パスワードだけのログインになり、NIST の基準では 15 文字以上です。 ### 人が覚えて入力するか 総務省は、サービスごとに違う安全なパスワードを覚えるのは大変だとして、パスワード管理ツールの利用を勧めています。共有アカウントでは、使う全員が同じ長い文字列を知り、それぞれが入力します。しかも、長さが守るのは推測に対してであり、すでにパスワードを知っている人に対してではありません。担当者が辞めたあとの扱いは[パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方)](/guides/shared-accounts/periodic-password-change)にまとめています。 ### 決め方の一例 社内システムの設定なら、NIST に合わせます。15 文字以上、二段階認証を使うなら 8 文字以上とし、漏えい済みの一覧との照合を加えます。従業員のルールなら、NIST と IPA のどちらかに合わせ、両方を重ねて課さないようにします。NIST は文字の種類の規則を禁じ、IPA は勧めているので、両方には同時に合わせられないからです。 ## よくある質問 **パスワードは 8 文字で足りますか** NIST SP 800-63B Rev. 4 では、8 文字は二段階認証と組み合わせる場合の下限です。パスワードだけでログインするなら 15 文字以上を求めています。IPA と総務省は 10 文字以上を目安にしています。 **記号を必ず入れる規則はやめられますか** NIST は、文字の種類を混ぜる規則を課してはならないとしています。やめる場合は、NIST が同じ節で求める長さと、漏えい済みのパスワードの一覧との照合を合わせて取り入れます。 **NIST は 8 文字以上と聞きましたが違いますか** 2017 年の版では、利用者が選ぶパスワードは 8 文字以上が必須でした。2025 年の Revision 4 で、パスワードだけでログインする場合の下限が 15 文字になりました。 **長いパスワードを覚えられないときは** 総務省は、関係のない単語をつなぐ作り方と、パスワード管理ツールの利用を勧めています。NIST も、サービス側にパスワード管理ツールの自動入力を認めるよう求めています。 ## 参考資料 - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [NIST Computer Security Resource Center「SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management」](https://csrc.nist.gov/pubs/sp/800/63/b/4/final) - [NIST Special Publication 800-63B(2017 年 6 月、2020 年 3 月更新)「Digital Identity Guidelines: Authentication and Lifecycle Management」](https://pages.nist.gov/800-63-3/sp800-63b.html) - [総務省「国民のためのサイバーセキュリティサイト」推測できる簡単なパスワードを利用しないようにしよう](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/end_user/general/01/) - [総務省「国民のためのサイバーセキュリティサイト」安全なパスワードの設定・管理](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/06/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [国家サイバー統括室「インターネットの安全・安心ハンドブック」Ver 5.10 掲載ページ](https://security-portal.cyber.go.jp/guidance/handbook.html) - [国家サイバー統括室「インターネットの安全・安心ハンドブック」Ver 5.10 第 5 章](https://security-portal.cyber.go.jp/guidance/pdf/handbook/handbook-05.pdf) - [国家サイバー統括室「サイバーセキュリティ普及啓発【企業・従業員層向け】講習テキスト」](https://security-portal.cyber.go.jp/imgs/kigyou_koushu_eturan.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify を使うと、共有アカウントの長いパスワードを全員が覚えて打ち込む作業がなくなります。導入時に長いパスワードへ変えて管理者だけが登録し、ログインのたびに Junify の拡張機能が入力するからです。担当者は値を見ないので、覚えやすさを考えずに長さを決められます。認証アプリにコードが出る方式なら、そのコードも Junify が入力します(SMS・メールで届くコードは対象外)。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 - [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](/guides/shared-accounts/sharing-chatgpt-accounts-at-work): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 --- # 個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 更新日: 2026-10-13 個人で[パスワードマネージャー](/guides/shared-accounts/what-is-password-manager)を使っている社員なら、業務のパスワードも同じ保管庫に入れたくなるでしょう。1 つの合言葉で、私用も業務も自動入力できるからです。ただ、その保管庫が誰のものかで、会社にできることが変わります。 ## 個人向けプランの保管庫は誰のものか 個人向けプランとは、社員が自分で契約するか無料で使っているプランです。1Password なら個人向けとファミリー向けのアカウント、Bitwarden なら Free・Premium・Families が当てはまります。 その保管庫は、契約した社員本人のものです。1Password の公式ヘルプは、私用のパスワードを個人向けかファミリー向けのアカウントに入れるよう案内しています。そのうえで、これらは仕事用のアカウントとは別で、中の項目はどれも勤務先からは使えないと説明しています。 Bitwarden の公式ヘルプも、個人の保管庫(My vault)の項目は利用者個人が持つとしています。会社が契約して作った「組織」(Bitwarden の画面での呼び名)から外しても、本人の手元にすべて残ります。 どちらの製品も、項目が私用か業務用かで扱いを変えてはいません。分かれ目は、どの契約の保管庫に入れたかです。個人向けプランに入れた会社のパスワードは、会社から見えない場所にあることになります。 ## 会社として困ること ### 退職時に回収できない IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、資産管理の項で、退職や任期満了のときに情報・機器・ID・鍵などを回収するよう求めています。回収したことは、チェックリストや記録で見えるようにします。 個人の保管庫に入ったパスワードは、会社が中身を見られません。そのため、回収も、消されたことの確認もできません。どのサービスのパスワードが入っていたかも、本人の申告に頼ることになります。 会社に残る手段は、そのサービスのパスワードを変えることです。その作業の重さは[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)で扱っています。 ### 会社の知らない相手にも共有できる 個人で使う製品にも共有の機能があります。Google パスワード マネージャーは、Google アカウントにパスワードを保存する機能です。公式ヘルプでは、共有できる相手は「ファミリー グループ」のメンバーに限られます。共有したパスワードは相手の Google アカウントに保存され、共有をやめたいときはパスワードを変えるよう案内されています。ブラウザーへの保存そのものは、[ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work)にまとめています。 Bitwarden の Families も、本人と 5 人までの家族や友人で共有するためのプランです。会社のパスワードがこうした経路で家族に渡っても、会社には知る方法がありません。共有の操作が、会社の契約の外で行われるからです。 ### 誰が使ったかの記録が会社に残らない 保管庫の中で誰が項目を見たか、コピーしたかを管理者が確かめる機能は、法人向けプランの一部にあります(1Password は Business、Bitwarden は Teams と Enterprise)。Bitwarden の操作の記録(画面では「イベントログ」)には、項目の閲覧、パスワードの表示とコピー、自動入力が残ります。個人向けプランには会社の管理者がいないので、会社が見られる記録もありません。 ## 法人向けプランで変わること 法人向けプランでは、保管庫を会社の契約の中に作り、誰に共有するかを管理者の側で決めます。 | 比べる点 | 個人向けプラン | 1Password(Teams・Business) | Bitwarden(Teams・Enterprise) | | --- | --- | --- | --- | | 共有の範囲を決める人 | 社員本人 | 保管庫の管理の権限を持つ人(初期設定では管理者を含む) | コレクション(Bitwarden の共有の単位)の管理の権限を持つ人 | | 社員個人の保管庫 | 会社は開けない | アカウントの復旧の権限を持つ人も開ける | 本人のもの。Enterprise の設定で組織のものにできる | | 操作の記録 | 会社には残らない | 使用状況レポート(Business) | イベントログ(Teams・Enterprise) | 1Password では、社員ごとに「Employee vault」という保管庫があります。ほかの社員からは直接見えません。ただし、アカウントの復旧(合言葉を忘れた人が入り直せるようにする機能)の権限を持つ人は、中のすべての項目を開けます。社員のアカウントを削除すると、この保管庫の項目は元に戻せない形で消えます。そのため退職者を外す手順は、削除の前に業務の項目を共有の保管庫へ移すよう求めています。 Bitwarden では、組織に共有した項目は組織のものになり、共有した人が辞めても組織に残ります。一方、個人の保管庫の項目は本人に残ります。 Enterprise には、組織の外に項目を持たせない設定(画面では「Centralize organization ownership」)があります。有効にすると、所有者と管理者以外の社員の個人の保管庫が、組織が持つ「My Items」に置き換わります。辞めた社員の My Items は組織に残り、管理者がほかの社員に使わせることができます。すでに個人の保管庫にある項目は、組織へ移すよう社員に求めることもできます。断った社員は、その場で組織の項目を使えなくなります(組織から削除されるのではなく、一時的に止められる扱いです)。 ## 法人向けプランでも残ること 法人向けプランにしても、辞めた社員が見たパスワードを覚えている状態は残ります。1Password の公式ヘルプにある退職者を外す手順も、その人が使えた保管庫のパスワードを変える工程を含みます。所有者か管理者のグループにいた人なら、管理できる保管庫のパスワードをすべて見たものとして扱うよう書かれています。 法人向けプランで減るのは、どのパスワードがどこにあるか分からない状態です。変える作業はなくなりません。 ## 社内で決めておくこと 総務省の「国民のためのサイバーセキュリティサイト」は、職場での対策としてパスワード管理ツールを勧めています。あわせて、会社ごとに決まりがあることもあるので、情報システム担当者に相談するよう呼びかけています。社員から相談されたときに答えられる決まりが要ります。IPA のガイドラインも、紙・ファイル・パスワード管理アプリなどの保管方法の違いを理解するよう求めています。そのうえで、自社に合った管理ルールを定め、社員に知らせることを求めています。 決めておくのは次の 3 つです。 1. 会社のアカウントのパスワードは、会社が契約した保管庫にだけ入れる。個人向けプランに入れたものは、会社が回収できないからです。 2. 私用のパスワードの置き場所を分ける。法人向けプランの利用者に、家族向けプランを無料で付ける製品もあります(1Password Business、Bitwarden Enterprise)。 3. すでに個人の保管庫にある会社のパスワードは、会社の保管庫へ移してもらい、個人側から消してもらう。消したかどうかは会社から確かめられないので、移したアカウントのパスワードを変えます。 規程に書くときの文例は、[パスワード管理規程のテンプレートと書き方](/guides/shared-accounts/password-policy-template)にあります。 ## よくある質問 **無料のパスワード管理アプリなら業務に使ってよいですか** 会社のアカウントのパスワードは入れないほうがよいでしょう。保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。 **法人向けプランなら退職時にパスワードを変えなくてよいですか** 変える作業は残ります。見た人の記憶は消せないため、1Password の公式ヘルプにある退職者を外す手順も、その人が使えた保管庫のパスワードを変える工程を含んでいます。 **業務用と私用のパスワードを分けるにはどうしますか** 業務用は会社が契約した保管庫、私用は個人のアカウントと決めます。 **社員の個人の保管庫に会社のパスワードがあったら** 会社の保管庫へ移してもらい、個人側から消してもらいます。消したかどうかは会社から確かめられないため、移したアカウントはパスワードを変えます。 ## 参考資料 - [1Password Support「About your Employee vault」](https://support.1password.com/employee-vault/) - [1Password Support「Offboard a team member」](https://support.1password.com/offboarding/) - [1Password Support「Create reports in 1Password Business」](https://support.1password.com/reports/) - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [1Password Support「Get a free 1Password Families membership when you use 1Password Business」](https://support.1password.com/link-family/) - [Bitwarden Help Center「Sponsored Families for Members」](https://bitwarden.com/help/families-for-enterprise/) - [Bitwarden Help Center「Password Manager Plans」](https://bitwarden.com/help/password-manager-plans/) - [Bitwarden Help Center「Permanently Remove Access」](https://bitwarden.com/help/remove-users/) - [Bitwarden Help Center「Organizations FAQs」](https://bitwarden.com/help/org-faqs/) - [Bitwarden Help Center「Enterprise Policies」](https://bitwarden.com/help/policies/) - [Bitwarden Help Center「Temporarily Revoke Access」](https://bitwarden.com/help/revoke-users/) - [Bitwarden Help Center「Event Logs」](https://bitwarden.com/help/event-logs/) - [Google Chrome ヘルプ「Chrome でパスワードを管理する」](https://support.google.com/chrome/answer/95606?hl=ja&co=GENIE.Platform%3DDesktop) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [総務省「国民のためのサイバーセキュリティサイト」安全なパスワードの設定・管理](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/06/) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** 退職のたびに、社員が個人の保管庫に入れたかもしれない共有アカウントのパスワードを洗い出し、変えて、残る全員に配り直す作業が続きます。Junify では導入時にパスワードを変えて管理者が登録し、以後は担当者に見せずに Junify が入力します。新しいパスワードを知らない担当者は個人の保管庫に入れようがなく、担当を外れたら割り当て(そのアカウントを使ってよい人の指定)を外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](/guides/shared-accounts/sharing-chatgpt-accounts-at-work): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 --- # ChatGPT などの生成 AI のアカウントを社内で共有してよいか 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。 更新日: 2026-10-13 ChatGPT の個人向けのアカウントを社内の複数人で使い回すことは、OpenAI の利用規約が禁じています。Claude を提供する Anthropic の個人向けの規約も同じです。複数人で使うなら、法人向けプランで 1 人に 1 つずつアカウントを用意します。 ## 利用規約が定めていること OpenAI の利用規約は、ChatGPT などの個人向けのサービスに適用されます。「登録及びアクセス」の節の「登録」の項は、次のように定めています。 > お客様は、アカウントの認証情報を他人と共有したり、アカウントを他人に利用可能にしたりしてはなりません。また、お客様はご自身のアカウントで発生するすべての活動に責任を負います。 認証情報とは、ログインに使う ID とパスワードのことです。違反すれば、OpenAI はアクセスを止めたりアカウントを削除したりできると、同じ規約の「終了」の項にあります。OpenAI のヘルプも、アカウントは作った本人専用で、ほかの人には各自でアカウントを作るよう案内しています。 会社が契約した個人向けのプランにも、この利用規約が当てはまります。同じ「登録」の項は、団体のためにアカウントを作る人に、その団体に代わって規約に同意する権限を求めているからです。法人向けの契約(OpenAI サービス契約)は、個人向けのサービスには適用されないと冒頭で断っています。 その法人向けの契約も、共有を認めてはいません。3.1 は、ログインの認証情報を「複数のユーザー間で共有しないものとします」と定めています。3.2 は、利用者のアカウントが「当該エンドユーザーによってのみ使用される」とします。 Anthropic の個人向けの規約(Consumer Terms of Service)も、第 2 条で次のように定めています。 > You may not share your Account login information, Anthropic API key, or Account credentials with anyone else. ログイン情報などを他人と共有してはならない、という意味です。同じ条は、アカウントを他人に使わせることも禁じています。 この規約の冒頭には、法人向けの規約は、個人や団体による Claude.ai・Claude Pro の利用を含まないとあります。会社が Claude Pro を買っても、個人向けの規約の対象です。 ## 共有すると起きること ### 誰の会話か分からない 1 つのアカウントを複数人で使うと、会話はすべてそのアカウントのものとして残り、どの会話を誰が入力したかは区別できません。それでも規約は、アカウントで起きたすべての活動の責任を、登録した側に負わせています。不適切な入力があっても、会社が示せるのはどのアカウントからか、までです。 ### 辞めた人が履歴を読める 二段階認証を設定していなければ、パスワードを知っている人は、それが変わるまでログインできます。辞めた人がログインすれば、履歴が消されていない限り、辞めたあとにほかの人が入力した会話も読めます。 止めるには、パスワードを変えて残る全員に配り直し、ほかの端末からもログアウトさせます。ChatGPT では、設定のセキュリティの項目から、すべての端末をまとめてログアウトさせられます。ほかの端末に反映されるまで最大 30 分かかることがあります。この運用の負担は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)にまとめています。 ### 入力した情報の扱い 個人向けの ChatGPT では、入力と出力を OpenAI がサービスの改善などに使うことがあります。学習に使わせない手続きは、利用規約の「使用停止(オプトアウト)」の項にあります。Anthropic の個人向けの規約も、アカウントの設定で止めない限り学習に使うことがある、としています。共有アカウントでは、この設定を変えられる人がログインできる全員に広がります。 ここに個人情報保護法の論点が重なります。個人情報保護委員会の「生成 AI サービスの利用に関する注意喚起等」(令和 5 年 6 月 2 日)は、事業者に 2 つの確認を呼びかけています。 1 つは、個人情報を含む質問や指示(プロンプト)を入れるなら、利用目的の範囲内かどうかです。もう 1 つは、本人の同意なく個人データを入れるなら、提供する事業者が「当該個人データを機械学習に利用しないこと等」です。入れた個人データが回答を出す以外の目的で扱われると、「個人情報保護法の規定に違反することとなる可能性がある」からです。 誰でも学習の設定を変えられる共有アカウントでは、この確認を会社として保ちにくくなります。 ## 法人向けプランで変わること OpenAI の法人向けプランは、ChatGPT Business と ChatGPT Enterprise です。Anthropic では、Claude の Team プランと Enterprise プランです。どれも、誰が使えるかを会社の管理者が決めます。 | 使い方 | 人を外す方法 | 本人以外で会話を見られる人 | 学習への利用 | | --- | --- | --- | --- | | 個人向けのアカウントを共有 | パスワードを変えて配り直し、全端末をログアウトさせる | ログインできる全員 | 止める手続きをしない限り使われうる | | ChatGPT Business | 管理者がメンバーから外し、その時点で入れなくなる | 管理者(閲覧・書き出し・削除) | 初期設定では使わない | | ChatGPT Enterprise | 管理者がメンバーを管理する | 管理者が専用の仕組みで会話の記録を取り出せる | 初期設定では使わない | | Claude の Team・Enterprise | 管理者がメンバーから外し、その時点で入れなくなる | 最上位の管理者(プライマリオーナー)が会話を含むデータを書き出せる | 初期設定では使わない | 表のように管理者が会話を見たり書き出したりできるプランでは、そのことを利用者が知っている必要があります。OpenAI サービス契約の 3.2 も、管理者の操作に必要な同意を利用者から得ておくよう、会社に求めています。 会社のメールアドレスで作った個人向けのアカウントは、会社が法人向けプランを使っていると、会社の組織に移されることがあります。OpenAI の利用規約では「企業のドメイン」、Anthropic の規約では「Business Domains」の項です。移されたアカウントは、入力した内容も含めて管理者が扱えるようになりえます。 ChatGPT と Claude は法人向けプランで人数分のアカウントを作れるので、[共有アカウントを個人アカウントに分けられないケース](/guides/shared-accounts/when-accounts-cannot-be-split)には当たりません。費用を理由に分けない判断も、規約が共有を禁じているので取れません。 ## 共有をやめる順序 1. 共有しているアカウントを書き出します。サービス名、パスワードを知っている人、入力してきた情報の種類を並べ、個人データを入れてきたなら学習の設定も確かめます。 2. 使う人の数だけ法人向けプランのアカウントを用意し、管理者を決めます。個人向けのアカウントが組織に移されうることは、利用者に先に伝えます。 3. 共有していたアカウントのパスワードを変え、ほかの端末からもログアウトさせてから、使うのをやめます。二段階認証を複数人のスマホに設定していたなら、[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)を参考に設定し直します。 ## よくある質問 **ChatGPT のアカウントを社内で共有してよいですか** 個人向けの利用規約は、ログイン情報を他人と共有することと、アカウントを他人に使わせることを禁じています。法人向けの契約も、1 つのアカウントは 1 人だけが使う前提です。 **会社が料金を払っていれば共有できますか** 個人向けのプランなら、個人向けの規約の対象です。Anthropic は、団体による Claude Pro の利用も法人向けの規約には含まれないと明記しています。複数人なら法人向けプランを使います。 **共有アカウントに入力した内容は学習に使われますか** 個人向けでは、止める手続きをしない限り使われることがあり、その設定はログインできる全員が変えられます。ChatGPT と Claude の法人向けプランは、初期設定では使いません。 **辞めた人を共有アカウントから外すには** パスワードを変えて残る全員に配り直し、すべての端末からログアウトさせます。ChatGPT Business や Claude の法人向けプランでは、管理者がメンバーから外した時点で入れなくなります。 **生成 AI に個人情報を入力してもよいですか** 個人情報保護委員会は、利用目的の範囲内かを確かめるよう呼びかけています。本人の同意なく個人データを入れるなら、提供する事業者が機械学習に使わないことなども確かめます。 ## 参考資料 - [OpenAI「利用規約」(2026 年 1 月 1 日発効)](https://openai.com/ja-JP/policies/row-terms-of-use/) - [OpenAI ヘルプセンター「OpenAI アカウント共有ポリシー」](https://help.openai.com/ja-jp/articles/10471989-openai-account-sharing-policy) - [OpenAI「OpenAI サービス契約」(2026 年 1 月 1 日発効)](https://openai.com/ja-JP/policies/services-agreement/) - [OpenAI「OpenAI におけるエンタープライズプライバシー」](https://openai.com/ja-JP/enterprise-privacy/) - [OpenAI「ChatGPT Business」](https://chatgpt.com/ja-JP/business/) - [OpenAI Help Center「Managing members, seat types, and roles in ChatGPT Business」](https://help.openai.com/en/articles/8542216-managing-members-seat-types-and-roles-in-chatgpt-business) - [OpenAI Help Center「How do I log out of all of my devices?」](https://help.openai.com/en/articles/9243857-how-do-i-log-out-of-all-of-my-devices) - [Anthropic「Consumer Terms of Service」(2025 年 10 月 8 日発効)](https://www.anthropic.com/legal/consumer-terms) - [Anthropic ヘルプセンター「Team プランと Enterprise プランでメンバーを管理する」](https://support.claude.com/ja/articles/13133750) - [Anthropic Privacy Center「Export your organization's data」](https://privacy.claude.com/en/articles/13346720-export-your-organization-s-data) - [Anthropic Privacy Center「私のデータはモデルトレーニングに使用されていますか？」](https://privacy.claude.com/ja/articles/7996868-is-my-data-used-for-training) - [Anthropic「プランと料金」](https://claude.com/ja/pricing) - [個人情報保護委員会「生成 AI サービスの利用に関する注意喚起等」(令和 5 年 6 月 2 日)](https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** ChatGPT や Claude は規約が共有を禁じているので、Junify に登録して共有せず、人数分のアカウントに分けます。Junify が受け持つのは、SNS の公式アカウントのように 1 つしかないアカウントです。導入時に変えたパスワードは担当者に渡らず、使うたびに担当者のスマホで本人確認をします。辞めた人の利用は管理者が止めるだけで、誰が・いつ使ったかは人ごとに残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # ブラウザーのパスワード保存を業務で使ってよいか 個人アカウントのパスワードを、会社が管理するブラウザーの設定で、1 人が使う端末に限って保存するなら選択肢になります。共有アカウント、私物端末、個人アカウントへの同期が絡む場合は避けます。管理者の設定で保存を止められます。 更新日: 2026-09-17 Google Chrome や Microsoft Edge は、ログイン画面で入力したパスワードを保存するか尋ね、次回から自動で入力します。この機能の動きと、管理者が配る設定(ポリシー)の内容は、両社の公式ドキュメントで確認できる範囲で書いています。 ## ブラウザーのパスワード保存が何をするか パスワード保存は、保存・同期・自動入力の 3 つの動作からできています。同期とは、ブラウザーにログインしたアカウントを通じて、別の端末でも同じパスワードを使えるようにそろえる仕組みです。 | 動作 | Google Chrome | Microsoft Edge | | --- | --- | --- | | 保存 | Chrome に Google アカウントでログインしていればそのアカウントに、していなければ端末の中に保存する | 管理者が止めない限り、利用者がパスワードを保存し、追加できる | | 同期 | 同期する項目にパスワードが含まれ、同じ Google アカウントでログインした他の端末で使える | 同期できるデータにパスワードが含まれ、サインインしたすべての端末で使える | | 自動入力 | 「自動ログイン」をオンにすると、確認なしでログインする | 保存したサイトを次に開いたとき、自動で入力する | 同期の単位は、ブラウザーにログインしたアカウントです。ブラウザーには、利用者ごとにブックマークや保存したパスワードを分ける「プロファイル」という仕組みがあります。Chrome のヘルプは、パソコンを他の人と共有する場合や、仕事とプライベートでアカウントを使い分けたい場合に、別のプロファイルを作れると案内しています。Edge の会社向けの同期は、会社の Microsoft アカウント(Microsoft Entra ID で管理するアカウント)で使います。対応する契約プラン(Entra ID P1/P2、Microsoft 365 Business など)が前提です。 ## 業務で問題になる 3 つの場面 問題は保存の機能そのものではなく、保存先と同期先が業務の範囲を超える場面にあります。 - 個人アカウントでブラウザーにログインしていると、業務のパスワードが個人の Google アカウント・Microsoft アカウントに保存され、自宅の端末にも同期されます。同期はログインしたアカウントの単位で行われ、業務用か個人用かを区別しないからです。 - 私物端末で使うと、退職後も端末とアカウントにパスワードが残ります。会社が端末とアカウントを管理していないため、削除されたことを確かめられません。 - 共有 PC で使うと、その PC を使う全員に自動入力されます。保存は端末のプロファイル単位で、誰が座っているかは見ないからです。 共有アカウントのパスワードを保存すると、この 3 つのどれかと重なりやすくなります。共有アカウントに固有の問題は、保存した端末とアカウントの数だけ「パスワードを知っている場所」が増えることです。退職時にパスワードを変えて配り直すときの更新先も、同じ数だけ増えます。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)は、「5 分でできる!情報セキュリティ自社診断」の対策例で、パソコンを他の人と共有しないよう求めています。共有せざるを得ない場合は、パソコンのユーザーアカウントを人ごとに別に作るよう求めています。共有 PC で 1 つのユーザーアカウントを全員が使う状態では、ブラウザーの保存はこの要求と両立しません。 ## 使ってよい条件と避けたい条件 使ってよいのは、個人アカウントのパスワードを、会社が管理するプロファイルで、1 人が使う会社端末に保存する場合です。保存先と同期先が会社の管理下にあり、退職時は会社端末の回収とアカウントの停止で止まります。 避けたいのは次の 3 つです。 - 個人の Google アカウント・Microsoft アカウントでログインしたブラウザーに保存する。業務のパスワードが個人アカウントと私物端末に同期されます。 - 共有アカウントのパスワードを保存する。保存した端末の数だけ知っている場所が増え、変更時の更新先になります。 - 共有 PC で保存する。同じプロファイルを使う全員に自動入力されます。 使ってよい場合でも、保存されるのはパスワードそのものです。保存した本人は、いつでもその値を見られます(Chrome のヘルプに、保存したパスワードの表示と削除の手順があります)。会社として[パスワードマネージャー](/guides/shared-accounts/what-is-password-manager)を導入しているなら、ブラウザーの保存はそれと二重になるため、どちらか一方に決めます。 ## 管理者が止められる設定 両ブラウザーとも、管理者が配る設定(ポリシー)で、保存と同期を止められます。公式ドキュメントで確認できた範囲を並べます(Chrome の設定名は日本語版ヘルプの表記)。 | したいこと | Google Chrome(管理者用の画面「管理コンソール」) | Microsoft Edge(管理者が配る設定) | | --- | --- | --- | | パスワードの保存を止める | 「パスワード マネージャーの使用を許可しない」を選ぶ | 「PasswordManagerEnabled」(パスワードの保存を許すかどうかの設定)を無効にする | | 同期を止める | 「ブラウザのログインを無効にする」を選ぶ | 「SyncDisabled」(同期を止める設定)を必須として適用する | 保存を止める設定でできなくなるのは、新しいパスワードの保存です。同期を止めると、Chrome は Chrome へのログインと Google アカウントへの同期ができなくなり、Edge は利用者が同期をオンにできなくなります。Edge には「SyncTypesListDisabled」という設定もあり、同期から外すデータの種類を選べます。 個人アカウントとの混在も設定である程度は防げます。Chrome では、会社が管理する Google アカウントでログインするときに、別のプロファイルを作らせるよう強制できます。Edge の 2 つの設定は、公式ドキュメントの対応機能の欄に「Microsoft アカウントでサインインしたプロファイルには適用されない」とあります。つまり、個人用アカウントのプロファイルには効きません。私物端末や個人アカウントのプロファイルまで止めたいなら、設定だけでは足りません。会社が管理するプロファイルだけを業務に使うルールと組み合わせることになります。 すでに保存されたパスワードが使えるという点は、設定を配った後も残ります。禁止に切り替えるときは、すでに保存されているパスワードを各自に削除させます。共有アカウントなら、パスワードを変えて保存済みの値を使えなくします。 ## よくある質問 **ブラウザーのパスワード保存は禁止すべきですか** 一律の禁止ではなく、個人アカウント・会社が管理するプロファイル・1 人が使う端末の 3 条件で判断します。共有アカウントの保存と、私物端末や個人アカウントへの同期は避けます。 **保存を禁止すれば保存済みのものも消えますか** 消えません。Chrome・Edge とも、保存を許可しない設定にしても保存済みのパスワードは使えます。各自に削除させるか、共有アカウントならパスワードを変えます。 **Edge の管理者の設定は個人のプロファイルにも効きますか** 個人の Microsoft アカウントでサインインしたプロファイルには効かないと公式ドキュメントにあります。会社が管理するプロファイルだけを業務に使うルールと組み合わせます。 **共有 PC でブラウザーに保存しても問題ありませんか** 同じプロファイルを使う全員に自動入力されるため避けます。IPA のガイドラインは、パソコンを共有せざるを得ない場合は、人ごとに別のユーザーアカウントを作るよう求めています。 ## 参考資料 - [Google Chrome ヘルプ「Chrome でパスワードを管理する」](https://support.google.com/chrome/answer/95606?hl=ja) - [Google Chrome ヘルプ「すべてのデバイスで同じブックマーク、パスワード、その他の設定を利用する」](https://support.google.com/chrome/answer/165139?hl=ja) - [Chrome Enterprise and Education ヘルプ「ユーザーまたはブラウザに Chrome のポリシーを設定する」](https://support.google.com/chrome/a/answer/2657289?hl=ja) - [Microsoft Learn「Microsoft Edge Browser Policy Documentation PasswordManagerEnabled」](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/passwordmanagerenabled) - [Microsoft Learn「Microsoft Edge Browser Policy Documentation SyncDisabled」](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/syncdisabled) - [Microsoft Learn「Configure Microsoft Edge enterprise sync」](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-enterprise-sync) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、担当者がパスワードをブラウザーに保存する代わりに、管理者が登録したパスワードを、ブラウザーに入れた Junify の拡張機能が入力します。担当者は自分のスマホで本人確認をしてクリックするだけで、パスワードは担当者にも端末にも残りません。私物端末からでも、誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 共有アカウントを複数人で安全に使う方法の比較 手作業、パスワードマネージャーの共有、ID 管理サービスによる代わりの入力、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 更新日: 2026-09-17 共有アカウントを複数人で使う方法は 4 つに分かれます。違いは「担当者がパスワードを知るか」と「誰が使ったかがどの単位で残るか」の 2 点にまとまります。他社製品の事実は、各社の公式ドキュメントで確認できた範囲だけを書きました。確認できない項目は「—(公式ドキュメントで未確認)」としています。方法の全体像と何から始めるかは[共有アカウントの管理](/guides/shared-accounts)にまとめています。 ## 比較する 4 つの方法 ID 管理サービスとは、Okta や Microsoft Entra ID のように、社員のアカウントをまとめて管理し、一度のログインで複数のサービスに入れるようにするサービスです。次の 4 つのうち、3 番目がこのサービスの受け持つ方法です。比較表では、この順に①〜④と書きます。 1. 手作業(台帳と配り直し) — 台帳で誰が知っているかを管理し、人が変わるたびにパスワードを変えて配り直します。 2. パスワードマネージャーの共有機能 — 共有の保管庫(vault)やコレクションに ID とパスワードを入れ、権限を付けた人に自動入力させます。 3. ID 管理サービスが代わりに入力 — ID 管理サービスに ID とパスワードを預け、そこにログインした人に代わりに入力します。Okta では Secure Web Authentication(SWA)、Microsoft Entra ID では password-based SSO という機能です。 4. アクセス管理ツール — 本人確認した担当者にパスワードを見せずに代わりに入力し、ログイン後の操作まで管理・記録します。Junify を含みます。 ②の事実は 1Password Support と Bitwarden Help Center、③は Okta Help Center と Microsoft Learn、④は Junify の製品ページで確認しました。①は道具を使わないため、確認した資料はありません。 [パスワードマネージャー](/guides/shared-accounts/what-is-password-manager)の定義と共有機能の限界は定義記事に、[二段階認証](/guides/shared-accounts/what-is-two-step-verification)の方式の違いも定義記事にあります。 ## 比較表 比べる点が 7 つあるため、表を 2 つに分けます。④の列は Junify の製品ページの範囲で書いています。どの方法でも、サービス側のログイン記録に残るのは共有アカウントの名前です。表の「誰が使ったかの記録の単位」は、その手前で誰が使ったかを残せるかを示します。 | 比べる点 | ①手作業 | ②パスワードマネージャー | ③ID 管理サービス | ④アクセス管理ツール(Junify) | | --- | --- | --- | --- | --- | | 担当者がパスワードを知るか | 全員が知る | 見る権限があれば見え、隠しても自動入力では使える | 知らない | 知らない | | 誰が使ったかの記録の単位 | 台帳への申告 | 保管庫側に残る閲覧・自動入力の記録 | 誰がいつどのアプリにアクセスしたか | 本人確認した人ごと(CSV で出せる) | | 退職時の操作 | パスワードを変えて残る全員に配り直す | アカウントを停止・削除し、サービス側のパスワードも変える | Okta は利用の許可を外し、Entra ID はアクセスを取り消す | 使える人からその人を外す(配り直しは不要) | | 二段階認証の扱い | 1 人のスマホや電話番号に頼る | 認証アプリの代わりにコードを出せる(Bitwarden は有料プラン) | —(公式ドキュメントで未確認) | 認証アプリのコードは入力できる(SMS・メールは対象外) | | 比べる点 | ①手作業 | ②パスワードマネージャー | ③ID 管理サービス | ④アクセス管理ツール(Junify) | | --- | --- | --- | --- | --- | | ログイン後の管理 | なし | —(公式ドキュメントで未確認) | —(公式ドキュメントで未確認) | 録画、ダウンロードの許可・禁止、アップロードの検知、遠隔でのログイン状態の終了 | | 前提 | なし | 記録機能は 1Password Business、Bitwarden の Teams / Enterprise | 使う人が ID 管理サービスにアカウントを持つこと | 担当者一人ひとりのスマホにアプリ、パソコンのブラウザーに拡張機能 | | 向く規模・状況 | アカウントが数件、使う人が数人 | 配布と保管を整えたいとき | Okta・Entra ID を使っていて、使う人が全員そこにいるとき | 人とアカウントが 1 対 1 でない、ID 管理サービスに載せない人がいる、ログイン後の記録が要る、端末に手を入れにくいとき | 表の中の「ブラウザーの拡張機能」は、ブラウザーに追加する小さなプログラムです。「ブラウザープラグイン」も同じものを指す Okta の呼び方です。③と④を選ぶときは、対象のサービスと端末の条件を、それぞれの公式ドキュメントと製品ごとの資料で確認します。 ## 各点の根拠 ### 担当者がパスワードを知るか Okta の SWA には、管理者が設定した 1 組の ID とパスワードを複数人で共有するサインオン方式があります。画面の表記は「Users share a single username and password set by administrator」です。この設定でパスワードの表示(Password reveal)を有効にしても、見られるのは管理者だけです。利用者は共有設定のパスワードを表示できません。Microsoft Entra ID の password-based SSO では、共有アカウントを使う権限を持つ利用者は実際のパスワードを見ず、Entra ID が代わりにログインします。1Password Teams の閲覧権限は、隠されたパスワードの表示とコピーを含みます。1Password Business は「表示とコピー」を別の権限に分けています。Bitwarden の「パスワードを隠す」権限は、自動入力では使えるためアクセスを完全には防ぎません。公式ヘルプは、共有済みのパスワードとして扱うよう明記しています。 ### 誰が使ったかの記録の単位 サービスの手前で残せる記録の内容は、方法ごとに違います。Okta には、期間内に誰がアプリにサインインしたかを見る Application Usage レポートがあります。いつアクセスしたかは、Okta の操作の記録(システムログ)から Application Access という条件で引けます。Entra ID はサインインの記録を残し、管理者が誰がいつアプリにアクセスしたかを確認できます。1Password Business の使用状況レポートには、項目ごとに最終アクセス日時、操作、操作したメンバーが載ります。Bitwarden の Teams / Enterprise のイベントログ(操作の記録)には、項目の閲覧、パスワードの表示・コピー、自動入力が記録の種類として残ります。 ### 退職時の操作 Okta は、アプリの利用の許可を外すと、利用者のアプリ一覧(My Apps)からそのアプリが消えます。グループ経由で許可していた場合は、グループから外すか、グループごと許可を外します。Entra ID は、管理者がアクセスを付与・取り消しでき、グループの所有者がメンバーの追加・削除を行えます。1Password は、退職者を外す手順を公式ヘルプ(Offboard a team member)で示しています。退職者のアカウントをいったん停止し、その人に共有していたパスワードを変更してから、アカウントを削除する順です。削除すると、保管庫と項目へのアクセスは取り消されます。Bitwarden は、一時的に使えなくする操作(revoke)と完全に削除する操作(remove)を分けています。パスワードマネージャーの場合は、外す前にパスワードを見られた人の記憶までは取り消せません。そのため、サービス側のパスワードを変える作業が残ります。 ### 二段階認証の扱い 1Password は、項目に使い捨てのコード(ワンタイムパスワード)を追加してコードを作れます。共有した保管庫に移せば、ほかのメンバーもその項目を使えます。Bitwarden は、項目の Authenticator Key 欄に秘密鍵を入れると、30 秒ごとの使い捨てコードを作ります。作るには Premium か、有料の組織への所属が要ります。Okta の SWA と Entra ID の password-based SSO が、対象アプリ側の二段階認証コードをどう扱うかは、公式ドキュメントでは明示されていません。Entra ID が書いているのは、共有アカウントを使う利用者に、Entra ID 側で 2 つ以上の方法によるログイン確認(多要素認証)を求められることです。 ### ログイン後の管理と前提 パスワードマネージャーと ID 管理サービスによる代わりの入力について、公式ドキュメントには、ログイン後の操作の管理に関する記述はありません。Entra ID の公式ドキュメントからは、担当者側の前提として 3 つを確認できます。共有アカウントを使う利用者ごとに EMS または Entra ID P1 / P2 の契約プランが要ること。password-based SSO には My Apps のブラウザー拡張機能が必要で、Edge と Chrome で提供されること。対象は、HTML のサインインページを持つアプリであることです。Okta は、ブラウザープラグインが Okta から ID とパスワードを受け取って SWA のアプリに渡します。契約プランの条件は、公式ドキュメントでは明示されていません。 ## この比較で Junify が要らない場合 全員に個人アカウントを発行できるなら、今の ID 管理サービスだけで足ります。ID 管理サービスとの連携(SAML などの規格)で、ログイン、入退社にともなうアカウントの作成・削除、権限まで管理しきれる場合です。使う人が全員 ID 管理サービスにアカウントを持ち、記録が「誰がいつアプリにアクセスしたか」で足りる場合もあります。そのときは、SWA や password-based SSO で共有アカウントを扱えます。アクセス管理ツールを検討するのは、その前提から外れるものが残るときです。つまり、ID 管理サービスに載せない人、一度のログインの仕組みに載らないアプリ、ログイン後の操作まで残したいアカウントがあるときです。 ## よくある質問 **パスワードマネージャーで隠せば担当者は知らないことになりますか** なりません。Bitwarden の公式ヘルプは、隠したパスワードも自動入力で使えるため、共有済みのパスワードとして扱うよう求めています。隠しても、配った相手は使える前提で扱います。 **Okta や Entra ID があれば十分ですか** 使う人が全員 ID 管理サービスにアカウントを持ち、記録が「誰がいつアプリにアクセスしたか」で足りるなら、SWA や password-based SSO で足ります。それ以外の人やログイン後の管理が要るなら別です。 **PAM と共有アカウントの管理は同じですか** PAM は、管理者用アカウントの利用申請・承認と操作の記録を仕組みで行うものです。部門の業務アカウントに当てはめるかは、製品の対象範囲で確認します。 **手作業のままでよいのはどんなときですか** アカウントが数件で使う人も数人、人が変わるたびにパスワードを変えて配り直せるときです。台帳に誰が知っているかを残します。それでも、誰が使ったかは申告に頼ることになります。 ## 参考資料 - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「Reveal the password of an app integration」](https://help.okta.com/oie/en-us/Content/Topics/Apps/Apps_Revealing_the_Password.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [Okta Help Center「Unassign users from applications」](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-unassign-apps.htm) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [1Password Support「Create reports」(usage report)](https://support.1password.com/reports/) - [1Password Support「Use 1Password as an authenticator for sites with two-factor authentication」](https://support.1password.com/one-time-passwords/) - [1Password Support「Offboard a team member」](https://support.1password.com/offboarding/) - [1Password Support「Add and remove team members」](https://support.1password.com/add-remove-team-members/) - [Bitwarden Help Center「Collection permissions」](https://bitwarden.com/help/collection-permissions/) - [Bitwarden Help Center「Event logs」](https://bitwarden.com/help/event-logs/) - [Bitwarden Help Center「Integrated authenticator」(Authenticator keys)](https://bitwarden.com/help/authenticator-keys/) - [Bitwarden Help Center「Managing users」](https://bitwarden.com/help/managing-users/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Junify の仕組み](https://www.junify.jp/product) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、管理者が共有アカウントの ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。パスワードは担当者に渡らず、記録は一人ひとり残り、録画、ダウンロードの許可・禁止、遠隔での終了をアカウントごとに設定できます。ID 管理サービスにいない人も使え、担当を外れたら管理者が使える人からその人を外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 退職者が出るたびにパスワードを変える運用の限界 一度知られたパスワードは取り消せないため、退職のたびに変える運用には理由があります。限界は、変更後の配り直しと保存先の更新にかかる手間と、誰が知っているかの一覧がないまま起きる抜け漏れです。 更新日: 2026-10-13 退職者が出るたびに[共有アカウント](/guides/shared-accounts/what-is-shared-account)のパスワードを変える運用は、共有アカウントを持つ職場では見慣れたものでしょう。 ## なぜ退職のたびに変えるのか 理由はパスワードの性質にあります。パスワードは「知っていること」で本人を確かめる仕組みです。そのため、一度知った人からその知識を取り上げる操作はありません。その人がログインできない状態にするには、パスワードそのものを別の値に変えるしかありません。個人アカウントなら、退職時にそのアカウントを止めれば済みます。共有アカウントは残る人が使い続けるため止められず、パスワードの変更で退職者の知識を使えなくすることになります。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)も、この運用を求めています。第 2 部の「資産管理」は、役職員の退職や派遣社員などの契約満了後に情報が不正に使われるのを防ぐため、退職・任期満了時に情報や機器・ID・鍵などを回収するよう求めています。回収したことは、チェックリストや記録で見えるようにします。「攻撃等の防御」では、従業員の異動や退職などに伴う権限の変更・削除漏れを防ぐルールを定めるよう求めています。付録の「5 分でできる!情報セキュリティ自社診断」の対策例にも、従業員の異動や退職時にはすみやかに設定を変更(削除)する、とあります。共有アカウントでは、この「回収」「削除」に当たる操作がパスワードの変更です。 この変更は、定期変更とは別のものです。NIST SP 800-63B Revision 4(米国の国立標準技術研究所が定めた本人確認の指針。2025 年 7 月)は、サービスを提供する側が利用者に定期的なパスワード変更を求めてはならないとしています。一方で、パスワードなどログインに使うものが盗まれた証拠があるときは、変更を必ず求めるとしています。NIST が挙げる条件は「盗まれた証拠」で、退職者が知ったままの状態を直接は扱っていません。ただ、許可していない人が知っている点は同じなので、この場面の変更は NIST の考え方と矛盾しないと読めます。 ## 変更 1 回にかかる作業 作業は変更そのものより、その後に続きます。順に並べます。 1. サービス側でパスワードを変えます。これが、退職者の知識を使えなくする操作です。 2. 残る利用者全員に新しいパスワードを配ります。変えた瞬間から配り終えるまで、誰もログインできません。 3. 二段階認証のコードの受け取り先を確かめます。退職者のスマホや電話番号に届く設定のままでは、残る人が入れません。 4. パスワードを保存している場所を更新します。ブラウザーの保存、パスワードマネージャー、投稿予約などのために設定した先に、古い値が残るからです。 5. いつ・誰が・なぜ変えたかを記録します。次の変更のときに、配る相手と保存先を同じ範囲で追えるようにするためです。 2 と 4 の手間は、利用者の数と保存先の数に応じて増えます。3 は、退職者のスマホが受け取り先だったときだけ発生します。その場合は、変更の前に受け取り先を移しておかないと、変更後に誰も入れなくなります。二段階認証のコードが 1 台の端末にしか届かない仕組みは [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification) で説明しています。 ## 抜け漏れが起きる構造 抜け漏れは担当者の不注意ではなく、一覧がないことから起きます。サービスごとに「誰がパスワードを知っているか」を記録した台帳がなければ、退職者がどのアカウントのパスワードを知っていたかを、退職の時点で確かめられません。本人に聞いても、数年前に一度教わっただけのアカウントを思い出せないことは珍しくないでしょう。 一覧があっても、対象は退職者だけではありません。異動で担当を外れた人、業務委託や派遣の契約が終わった人、休暇中の代わりに一時的に操作した人も、パスワードを知ったままです。IPA のガイドラインが退職と並べて異動や契約満了を挙げているのはこのためです。変更のきっかけを「退職」に限ると、それ以外の離脱が漏れます。 配り直しの方法も、次の漏れを生みます。新しいパスワードをチャットやメールで送れば、その文面が受け取った人の端末とサービス側の記録に残ります。次の退職者が出たときに、「どこに残っているか」がまた分からなくなります。配り直しのたびに、変更前と同じ数の知っている人と、変更前より多い保存先ができます。 変更までの時間も残ります。退職の申し出から変更までの間、退職者はログインできる状態にあります。変更を月末などにまとめて行う運用なら、その期間は最長で 1 か月に延びます。 ## 運用を減らす 2 つの代わりの方法 変更の回数を減らしても、知っている人が残る限り同じ作業が繰り返されます。退職のたびに変える運用をなくすには「知っている人」を作らないことで、方法は 2 つあります。 1. 個人アカウントに分ける。退職時はその人のアカウントを止めるだけで済み、共有パスワードがなくなります。分けられるのは利用者を追加できるサービスに限られ、公式 SNS など 1 つしか作れないアカウントは残ります。 2. パスワードを知らせない方式に替える。管理者だけがパスワードを持ち、担当者は代理入力(パスワードを代わりに入力する仕組み)でログインし、退職時は使える人から外すだけになります。方式ごとに対象の人と端末の条件があり、パスワードを知っている管理者は残ります。 パスワードマネージャーで共有する方法は、この 2 つの中間です。配布と保管は整いますが、見ることができた人の記憶は取り消せないため、退職時に変える運用は残ります。この点は [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager) で説明しています。個人アカウントに分けられるものを分けたうえで、残る共有アカウントに知らせない方式を選ぶ。この順が、変更の回数をいちばん減らします。知らせない方式の選択肢は [共有アカウントの管理](/guides/shared-accounts) の表にまとめています。 ## それでも変えるときに決めておくこと 代わりの方式に移るまでの間は、変更の運用を続けることになります。抜け漏れを減らすために、次の 3 点を先に決めておきます。 1. 台帳に「誰が知っているか」の列を持つ — 変更のたびに配った相手をここに書き、次の退職時にはこの列を見て対象を決めます。 2. 変更のきっかけを退職以外にも広げる — 異動、契約終了、代わりに操作した期間の終了を、同じ手順の対象にします。 3. 配り方を 1 つに決める — チャット・メールの本文には書きません。配った先の端末や記録に文面が残らず、開ける範囲を後から狭められる方法に統一します。知られたパスワードそのものは取り消せないので、変更の運用は残ります。 ## よくある質問 **退職者が出たら毎回パスワードを変えるべきですか** 共有アカウントのパスワードを知っていた人が辞めるなら、変えるのが原則です。知っている人を作らない方式(個人アカウント・パスワードを代わりに入力する仕組み)に替えれば、この変更自体が要らなくなります。 **パスワードマネージャーを使えば変更は不要になりますか** 見ることができた人の記憶は取り消せないため、共有していた相手が辞めたら変更は残ります。共有から外すだけでは、その人がサービスにログインできる状態は止まりません。 **変更の抜け漏れはどう防ぎますか** サービスごとに「誰が知っているか」を台帳に持ち、退職だけでなく異動や契約終了も変更のきっかけに含めます。配り方は、開ける範囲を後から狭められる方法に統一します。 **変更の間は誰もログインできなくなりますか** 変えてから配り終えるまでの間はログインできません。配る相手と配り方を先に決め、業務の少ない時間帯に変えると、止まる時間を短くできます。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、共有アカウントのパスワードは管理者が登録し、担当者には渡りません。担当者は自分のスマホで本人確認をしてクリックするだけでログインします。退職や異動のときは、管理者が使える人からその人を外すだけで、パスワードを変えて配り直す作業は要りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # パスワード管理規程のテンプレートと書き方 規程に入れる項目は、適用範囲、パスワードの条件、保管、共有の禁止と例外、共有アカウント、二段階認証、変更、退職時の手続き、違反時の扱い、見直しの 10 項目です。各条を IPA と個人情報保護委員会の要求に対応づけ、文例を示します。 更新日: 2026-09-17 パスワード管理規程は、従業員がパスワードをどう作り、どこに置き、誰にも教えず、いつ変え、退職時にどう止めるかを一つの文書で決めるものです。以下の文例は、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版と個人情報保護委員会のガイドライン(通則編)が公開している要求を満たす一般的な文です。法的助言ではありません。就業規則や契約と合っているかは、弁護士や社会保険労務士の確認が要ります。 ## 規程が答える 2 つの要求 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)は、第 2 部「実践編」の「本格的に取り組む」で、規程の作り方を示しています。対応すべきリスクの特定、対策の決定、規程の作成の順で、自社に合った規程を作るという手順です。付録 5 には「情報セキュリティ関連規程(サンプル)」があります。同じ実践編の「攻撃等の防御」には、パスワード管理規程にそのまま入る項目が並びます。ID の発行から削除までの手続、共有 ID の扱い、異動・退職時の権限の見直し、パスワードの設定・管理ルール、多要素認証(2 つ以上の方法でログインを確かめること)の活用です。 個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)も根拠になります。個人情報保護法 23 条の安全管理措置の内容は、「10(別添)講ずべき安全管理措置の内容」に示されています。個人データを扱う会社は、「個人データの取扱いに係る規律」(扱い方のルール)を整えなければなりません。その方法として、取得から廃棄までの段階ごとに取扱規程を作ることが例に挙げられています。技術的安全管理措置(仕組みで行う対策)としてのアクセス制御と、アクセス者の識別・認証は、必ず行う措置です。パスワード管理規程は、この「識別と認証」(誰かを確かめてからログインさせること)を具体化する文書に当たります。通則編の技術的安全管理措置が及ぶのは個人データを扱う情報システムですが、IPA の項目はそれ以外のシステムにも同じように当てはまります。 ## 項目と要求の対応 規程に入れる 10 項目が、2 つの文書のどの要求に対応するかを並べます。 | 規程の項目 | IPA 第 4.0 版の当てはまる項目 | 通則編 10(別添)の当てはまる箇所 | | --- | --- | --- | | 適用範囲 | 法令や契約の要求を社内ルールへ反映し、役職員と社外要員に周知 | 個人データの取扱いに係る規律の整備 | | パスワードの条件 | 複雑さの保持と使い回し防止のルールを定めて周知 | 技術的措置(2)アクセス者の識別と認証(ユーザー ID・パスワード等) | | 保管 | 紙・ファイル・パスワード管理アプリ等の保管方法の違いを理解し、管理ルールを定める | 同上 | | 共有の禁止と例外 | 共有 ID はなるべく使わない | 技術的措置(1)アクセス制御(ユーザー ID のアクセス権で従業者を限定) | | 共有アカウントの管理 | やむを得ず使う場合は利用したユーザーを特定できる仕組みを整備 | 組織的措置(2)規律に従った運用(例示: ログイン実績、アクセスログ等の記録) | | 二段階認証 | 情報の重要度に応じて認証の強度を決め、多要素認証を活用 | 技術的措置(2) | | 変更 | 当てはまる項目なし(第 4.0 版に定期変更の項目はない) | 当てはまる箇所なし | | 退職・異動時の手続き | 異動や退職にともなう権限の変更・削除漏れを防ぐルール。退職時に ID・鍵等を回収 | 組織的措置(3)取扱状況を確認する手段の整備(例示: アクセス権を有する者) | | 違反時の扱い | 禁止行為を明確にし、守秘義務の誓約書を提出させる | 人的措置(秘密保持に関する事項を就業規則等に盛り込む) | | 見直し | 定期的な経営層への報告と対策の見直し | 組織的措置(5)取扱状況の把握と安全管理措置の見直し | 変更の条だけは、どちらの文書にも当てはまる項目がありません。NIST SP 800-63B の 3.1.1.2 節と総務省の資料をもとにします。 ## テンプレート 以下が全文です。会社名、部署名、日数は自社に合わせて置き換えます。「共有アカウント」の定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)に合わせています。各条の下に、どの要求に対応する条かを添えます。 ### 第 1 条 目的と適用範囲 > この規程は、当社の情報システムおよび業務で利用する外部サービスのパスワードの設定、保管、共有、変更、廃止について定める。役員、従業員、派遣社員、および当社のアカウントを利用する業務委託先の要員に適用する。 IPA は、法令や契約の要求を社内ルールに反映し、役職員と社外要員に周知するよう求めています。委託先の要員を適用範囲に入れるなら、契約にも同じ義務を入れます。規程は自社の役職員に向けた文書だからです。 ### 第 2 条 パスワードの条件 > パスワードは、他のサービスと使い回さず、推測できない固有の文字列とする。長さは 15 文字以上とし、二段階認証を併用するサービスでは 8 文字以上とする。初期パスワードは初回ログイン時に変更する。 長さの数値は NIST SP 800-63B Revision 4(2025 年)の 3.1.1.2 節に合わせています。この数値はサービスを提供する側に対する下限であり、社内規程に引くのは同じ考え方を自社に当てはめる判断です。NIST は、文字種を混ぜるなどの組み合わせの規則を課さないよう求めています。一方、IPA のガイドラインは、10 文字以上で大小英字・数字・記号を含めることを対策例に挙げています。どちらに合わせるかは自社で決め、両方を同時に課さないようにします。 ### 第 3 条 保管 > パスワードは、会社が指定したパスワード管理ツールに保管する。紙、表計算ファイル、チャット、メール、ブラウザーの保存機能に記録することを禁止する。 IPA は、紙、ファイル、パスワード管理アプリ等の保管方法の違いを理解し、自社に合った管理ルールを定めるよう求めています。指定ツールを決めていない会社は、この条を書く前に決めます。 ### 第 4 条 共有の禁止 > パスワードは本人のみが知るものとし、他者に教えない。上長、情報システム部門、外部の支援者を名乗る者から求められても開示しない。 総務省の「安全なパスワードの設定・管理」は、同僚等の第三者に教えずに秘密にすること、電子メールでやりとりしないことを求めています。 ### 第 5 条 共有アカウント > 1 つのアカウントを複数人で利用する場合(共有アカウント)は、情報システム部門の承認を得て台帳に登録する。台帳には、サービス名、アカウント名、管理責任者、利用者、パスワードの保管場所、二段階認証コードの受け取り先、最終確認日を記録する。共有アカウントの利用は、利用者を特定できる方法で記録する。 IPA は共有 ID を「やむを得ず使う場合」に、使った人を特定できる仕組みを求めています。通則編は、担当者の情報システムの利用状況(ログイン実績、アクセスログ等の記録)を残すことを手法の例に挙げています。共有アカウントではサービスの記録にアカウント名しか残らないため、利用者を特定する手段(台帳での申告か、本人単位で記録が残る仕組みか)をこの条で決めます。 ### 第 6 条 二段階認証 > 二段階認証を設定できるサービスでは、設定を必須とする。二段階目は認証アプリまたはセキュリティキーを優先し、SMS は他に選べない場合に限る。共有アカウントの二段階目の受け取り先は、台帳に記録した方法に限る。 IPA は、情報の重要度に応じたログイン確認の強さと、多要素認証の活用を求めています。方式ごとの違いは[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)にまとめています。 ### 第 7 条 変更 > パスワードは、漏えいの事実または疑いがあるとき、および共有アカウントの利用者が退職・異動・契約終了で変わったときに、速やかに変更する。それ以外の定期的な変更は求めない。 個人アカウントの定期変更を求めないのは、NIST SP 800-63B の 3.1.1.2 節と、総務省の資料に沿った書き方です。NIST の同節は、サービスを提供する側は定期変更を求めてはならず、盗まれた証拠があれば必ず変更させる、としています。総務省の資料は、流出の事実がなければ変更は不要としています。IPA の第 4.0 版には定期変更の項目がありません。共有アカウントは、パスワードを知っている人が変わるたびに変更が要るため、別に書きます。 ### 第 8 条 退職・異動時の手続き > 退職、異動、契約終了の日までに、本人が利用していた個人アカウントを無効化し、共有アカウントは第 7 条に従って変更する。情報システム部門は、台帳と照合して漏れがないことを確認し、確認の記録を残す。 IPA は、退職・任期満了時に情報や機器・ID・鍵等を回収し、チェックリストや記録で実行状況を見えるようにするよう求めています。 ### 第 9 条 違反時の扱い > この規程に違反した場合は、就業規則の定めに従って扱う。業務委託先の要員については、契約の定めに従う。 通則編は、秘密保持に関する事項を就業規則等に盛り込むことを人的安全管理措置の例に挙げています。IPA は、禁止行為を明確にして違反への抑止力を高めることと、役職員(社外要員を除く)からの守秘義務の誓約書を挙げています。懲戒の内容は就業規則に置き、この規程からは参照だけにします。 ### 第 10 条 見直し > 情報システム部門は、年 1 回、この規程と共有アカウントの台帳を見直し、結果を経営層に報告する。 IPA は定期的な経営層への報告と対策の見直しを、通則編は個人データの取扱状況の把握と安全管理措置の評価・見直しを求めています。 ## 書く前に決めること 決めるのは 3 つです。第 1 に、指定するパスワード管理ツールと、共有アカウントで利用者を特定する手段です。これが決まらないと第 3 条と第 5 条が書けません。第 2 に、長さの基準を NIST と IPA のどちらに合わせるかです。第 3 に、業務委託先の要員を適用範囲に入れるかどうかです。委託先に自社のアカウントを使わせている会社は、入れたうえで契約にも同じ内容を書きます。 ## よくある質問 **パスワードの長さは何文字と書けばよいですか** NIST SP 800-63B Rev. 4 はパスワードだけなら 15 文字以上、二段階認証と併用なら 8 文字以上、IPA は 10 文字以上と文字種の混在です。どちらかに合わせ、両方を重ねて課さないようにします。 **定期変更の条文は入れるべきですか** 個人アカウントには漏えい時の変更だけを書き、定期変更は求めないのが NIST と総務省の考え方です。共有アカウントは、利用者が変わったときに変更する条を別に置きます。 **違反時の罰則は規程に書きますか** 就業規則の定めに従うと書くにとどめ、懲戒の内容は就業規則に置きます。通則編も、秘密保持に関する事項を就業規則等に盛り込むことを例に挙げています。 **共有アカウントの台帳には何を書きますか** サービス名、アカウント名、管理責任者、利用者、パスワードの保管場所、二段階認証コードの受け取り先、最終確認日です。利用者を特定する手段もここで決めます。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [総務省「国民のためのサイバーセキュリティサイト」安全なパスワードの設定・管理](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/06/) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、共有アカウントの ID とパスワードを管理者が登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。第 5 条の利用者の特定は本人単位の記録で満たせ、第 7 条・第 8 条の変更と配り直しは、管理者が使える人からその人を外す操作に置き換わります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方) NIST SP 800-63B は、サービス側が利用者に定期変更を求めないよう定め、変更を必須にするのは盗まれた証拠があるときとしています。複数人で使う共有アカウントは、知っている人が変わるたびに変更が要ります。 更新日: 2026-10-14 パスワードの定期変更を続けるかどうかは、そのパスワードを誰が知っているかで答えが分かれます。NIST SP 800-63B と日本の公的機関の資料が定期変更を不要としているのは、本人だけが使うパスワードについてです。複数人で使う共有アカウントには、その前提がありません。 ## NIST SP 800-63B は何を求めているか NIST SP 800-63B は、米国国立標準技術研究所(NIST)が定める、ログインの本人確認についてのガイドラインです。現行版は Revision 4(2025 年)です。定期変更の扱いは 3.1.1.2 節にあります。この節が求める相手は、パスワードを受け取って確かめる側と、ID を発行して管理する側(原文では Verifiers and CSPs)です。 | 項目 | 3.1.1.2 節の記述 | | --- | --- | | 定期変更 | サービス側は、利用者に定期的なパスワード変更を求めてはならない(SHALL NOT) | | 漏えい時の変更 | パスワードが盗まれたなどの証拠がある場合、サービス側は変更を必ず求める(SHALL) | | 長さ | パスワードだけでログインするなら 15 文字以上、二段階認証と組み合わせるなら 8 文字以上とする(どちらも SHALL) | | 文字種の規則 | 大文字・記号を混ぜるなどの、文字の組み合わせの規則を課してはならない(SHALL NOT) | | 漏えい済みの照合 | すでに漏えいしたパスワードや、よく使われるパスワードの一覧(ブロックリスト)と照らし合わせる(SHALL) | この節が求める相手はサービスを提供する側です。この点は、規程に引くときに確かめておく必要があります。この節は、サービスを提供する側に、利用者へ定期変更を強いる設計をやめるよう求めるものです。社内規程で従業員に定期変更を課している会社がこの節を根拠に規程を改めるのは、同じ考え方を自社に当てはめる判断です。NIST が社内規程を直接扱っているわけではありません。 もう 1 つ、同じ文書の冒頭(1 節)には、利用者の責任が書かれています。利用者は自分のログインの秘密を守り、他人に教えない(credential sharing をしない)責任を負う、という内容です。定期変更を不要とする定めは、この前提の上に置かれていると読めます。 ## 日本の公的機関はどう言っているか 総務省の「国民のためのサイバーセキュリティサイト」にある「安全なパスワードの設定・管理」は、まず経緯を書いています。これまでは定期変更が推奨されていたが、2017 年に NIST から、サービスを提供する側が定期変更を求めるべきではない旨が示された、という経緯です。そのうえで、アカウントが乗っ取られたり、サービスからパスワードが漏れたりしていなければ、変えなくてよいとしています。代わりに求めているのは 3 つです。機器やサービスの間で使い回しのないパスワードを設定すること、流出時にすぐ変更すること、パスワードを同僚などの第三者に教えずに秘密にすることです。 IPA の資料は 2 つ確認しました。「不正ログイン対策特集ページ」は、できるだけ長く、複雑で、使い回さないパスワードと、2 つ以上の方法でログインを確かめること(多要素認証)を勧めています。定期変更についての記述はありません。「情報セキュリティ 10 大脅威 2025」の解説資料「セキュリティ対策の基本と共通対策」(2025 年 2 月、二版 3 月)は、保管・運用の項目に「パスワードの定期的な見直しをする」を挙げています。ただし、変更を指示している場面は不正ログインされたときに限られ、見直しの内容は書かれていません。不正ログインされた場合はすぐに変更し、使い回していれば他のサービスも合わせて変更するとしています。 3 つの資料が、定期変更をどう扱い、どんなときに変更を求めているかを並べます。 | 資料 | 定期変更の扱い | 変更を求める場面 | | --- | --- | --- | | NIST SP 800-63B Rev. 4(3.1.1.2 節) | 求めてはならない | 盗まれた証拠があるとき | | 総務省「安全なパスワードの設定・管理」 | 流出の事実がなければ不要 | 流出したとき | | IPA「セキュリティ対策の基本と共通対策」2025 | 「定期的な見直し」を挙げる(内容の説明なし) | 不正ログインされたとき | ## なぜ定期変更をやめられるのか 定期変更が守っていたのは、パスワードが本人以外に知られたことに気づかないまま使われ続ける期間です。90 日ごとに変えれば、気づかない漏えいがあっても最長 90 日で無効になります。この効果が意味を持つのは、漏えいに気づく手段がほかにないときに限られます。 3 つの資料が共通して置き換え先にしているのは、漏えいの証拠で変える運用です。サービスからの漏えい通知、ログイン通知、漏えいチェックのサイト、ログイン記録の確認で気づける場合があります。それなら、気づいた時点で変えるほうが、定期の期限を待つより早く無効にできます。その間の防御は、使い回さない長いパスワードと二段階認証が受け持ちます。総務省の資料が、定期的に変更するよりも使い回しのないパスワードを求めているのはこの理由です。 ## 共有アカウントでは前提が当てはまらない 定期変更を不要とする根拠は、「パスワードを知っているのは本人だけ」と「本人以外に知られたら証拠が残る」の 2 つでした。[共有アカウント](/guides/shared-accounts/what-is-shared-account)では、どちらも成り立ちません。 第 1 に、知っている人が最初から複数います。NIST の基準は、利用者が秘密を他人に教えないことを前提にしていますが、共有アカウントは教えることを前提にした運用です。第 2 に、知っている人が入れ替わります。担当者が退職・異動しても、その人の記憶からパスワードは消えません。元担当者がログインできる状態は、個人アカウントで言えばパスワードが第三者に知られた状態に当たると読めますが、漏えいの証拠としては残りません。通知が届いても、それが現担当者の操作か元担当者の操作かを区別できず、サービスの記録にもアカウントの名前しか残らないからです。 したがって共有アカウントでは、定期変更をやめる代わりに「証拠があったら変える」に切り替えることができません。変更が要るのは、知っている人の範囲が変わったとき、つまり退職・異動・委託の終了のたびです。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)も、従業員の異動や退職にともなう権限の変更・削除漏れを防ぐルールを定めるよう求めています。共有 ID はなるべく使わず、やむを得ず使う場合は、使った人を特定できる仕組みを整えるともしています。 変えたパスワードを残る全員に配り直す以上、知っている人の範囲は縮まらず、次の退職でまた同じ作業が要ります。定期変更をやめても、この作業は残ります。 ## 定期変更をやめる条件 条件を個人アカウントと共有アカウントに分けて並べます。 | 条件 | 個人アカウント | 共有アカウント | | --- | --- | --- | | 知っているのは本人だけ | 成り立つ | 成り立たない(担当者が知らない状態にすれば成り立つ) | | 漏えいの証拠を得られる | ログイン通知・漏えいチェック・ログイン記録の確認 | 元担当者のログインは検知の手掛かりにならない | | 使い回さない長いパスワード | 15 文字以上(パスワードだけのとき)と漏えい済み一覧との照合 | 同じ | | 二段階認証 | 設定できるなら設定する | 二段階目を 1 人のスマホに頼ると不在時に使えない | | 不要になったアクセスを止められる | アカウントを止める | パスワード変更と配り直し以外に手段がない | 表の右列に「成り立たない」が並ぶ限り、共有アカウントの定期変更をやめる根拠はありません。右列の条件を満たす方法の選択肢は[共有アカウントの管理](/guides/shared-accounts)にまとめています。二段階目を複数人で使うときの問題は[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)で扱います。 ## よくある質問 **社内規程の「90 日ごとに変更」は削ってよいですか** 個人アカウントなら、漏えい時に変更する規定と、使い回さない長いパスワード、二段階認証に置き換えるのが NIST と総務省の考え方に沿います。共有アカウントの条は別に残します。 **NIST の基準は日本の会社にも関係ありますか** 米国の文書で日本の法令ではありませんが、総務省の資料が NIST の考え方を引いて、流出の事実がなければ変更は不要としています。日本でも参照される基準です。 **共有アカウントは何日ごとに変えればよいですか** 日数では決まりません。パスワードを知っている人が変わったとき(退職・異動・委託終了)に変えます。それを避けたいなら、担当者にパスワードを見せない方法に切り替えます。 **漏えいの証拠とは何を指しますか** サービスからの漏えい通知、身に覚えのないログイン通知、漏えいチェックサイトでの一致、ログインの記録に残る不審なアクセスなど、本人以外が使った可能性を示す事実です。 ## 参考資料 - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [総務省「国民のためのサイバーセキュリティサイト」安全なパスワードの設定・管理](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/06/) - [IPA「不正ログイン対策特集ページ」](https://www.ipa.go.jp/security/anshin/measures/account_security.html) - [IPA「セキュリティ対策の基本と共通対策」情報セキュリティ 10 大脅威 2025 版(2025 年 2 月、二版 3 月)](https://www.ipa.go.jp/security/10threats/eid2eo0000005231-att/kihontokyoutsuu_2025.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、共有アカウントのパスワードは管理者が登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。パスワードは担当者に渡らないため、退職や異動のたびに変えて配り直す必要がなく、管理者が使える人からその人を外すだけで止められます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 共有アカウントの棚卸しの手順と台帳の項目 共有アカウントの棚卸しは、サービスごとに誰がパスワードを知っていて誰が使えるかを一覧にする作業です。見つけ方、台帳の項目、分ける・残す・廃止するの判定、更新のきっかけを順に示します。 更新日: 2026-09-17 共有アカウントの棚卸し(何があるか一覧にすること)とは、社内で複数人が使っているアカウントを洗い出し、サービスごとに「誰がパスワードを知っていて、誰が使えるか」を一覧にする作業です。共有アカウントでは、サービス側の記録に操作した人が残りません([共有アカウントとは](/guides/shared-accounts/what-is-shared-account))。そのため、この一覧が使う人を特定する出発点になります。 ## 棚卸しの目的 目的は、3 つの判断の材料をそろえることです。個人アカウントに分けられるか、残すなら誰がどう使うか、廃止できるか。どれも、誰が知っていて誰が使っているかが分からなければ決められません。Microsoft Entra ID の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか分からない、誰がアクセスしたか分からない、アクセスを外すには ID とパスワードを変えて配り直すしかない、などです。棚卸しは、このうち「誰がアクセスできるか」に台帳で答える作業です。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)には、コラム「IT 資産管理について」があります。IT 資産管理を、クラウドサービスも含めて「何の機器やソフトウェアが、どこで、誰によって使われているかの把握」から始まる活動としています。一覧表や管理台帳の作成から始めて、定期的な見直しを習慣にするよう求めています。同じガイドラインは、共有 ID はなるべく使わず、やむを得ず使うなら利用したユーザーを特定できる仕組みを整えるよう求めています。共有アカウントの台帳は、この 2 つの要求への記録です。 ## 共有アカウントの見つけ方 台帳を作る前に、どこに共有アカウントがあるかを探します。管理者の記憶だけでは、部門が自分で契約したサービスが抜けます。 手がかりは 5 つあり、それぞれ見落とすものも決まっています。 1. 請求書・経費精算・法人カードの明細から、有料のサービスと契約者が分かります。個人のカードで立て替えているものと、無料プランは出てきません。 2. ID 管理サービス(Okta、Microsoft Entra ID など)に載っていないログインを探すと、ID 管理サービスとつなげないサービスや、その外で作られた ID が見つかります。部門が直接 ID とパスワードでログインしているものは、この方法では出てきません。 3. 会社アドレス宛のメール(通知・パスワード再設定)からは、代表アドレスや部門アドレスで登録したサービスが分かります。個人のアドレスで登録したものは出てきません。 4. ブラウザーのパスワード保存と、パスワードマネージャーの共有用の保管場所には、実際に使われている ID とパスワードがあります。私物端末のブラウザーに保存されたものは見えません。 5. 部門への聞き取りでは、用途、使っている人、引き継ぎの経緯が分かります。「自分しか使っていない」と思われている共有 ID は、それでも出てきにくいものです。 聞き取りでは、「共有アカウントはありますか」より「担当者が休んだ日は誰がどうログインしますか」と聞くほうが、実際の共有が出てきやすいでしょう。共有を問題と受け取った人も、業務の続け方なら答えやすいからです。 ## 台帳の項目 項目は、判定と退職時の作業に使うものに絞ります。[共有アカウントの管理](/guides/shared-accounts) の「何から始めるか」にある最小の 7 項目を含む、全項目の一覧です。 1. サービス名 — サービス名とログイン画面の URL を書きます。同名のサービスや、同じサービスに会社ごとの環境が複数ある場合の取り違えを防げます。 2. アカウントの ID — ログイン ID(メールアドレスやユーザー名)を書きます。1 つのサービスに複数ある場合を分けられます。 3. 用途 — 何の業務に使うかを書きます。廃止する・まとめる判断の根拠になります。 4. 管理者 — 責任を持つ部門と、設定を変えられる人を書きます。変更・廃止・退職時に誰が動くかが決まります。 5. パスワードを知っている人 — 現に知っている人を書き、過去に知っていた人は別の欄に移します。退職時にパスワードを変える必要があるかの判断材料になります。 6. 使っている人 — 業務でそのアカウントを使うことになっている人を書きます。「パスワードを知っている人」との差が、配り過ぎの度合いを示します。 7. 二段階認証の受け取り先 — 方式と、コードを受け取る端末・番号、バックアップコードの保管場所を書きます。不在時と退職時に何を変えるかが決まります。 8. パスワードの保管場所 — 紙・ファイル・パスワードマネージャーなどの別を書きます。IPA は、保管方法の違いを踏まえた管理ルールを求めています。 9. 最終変更日 — パスワードと二段階認証を最後に変えた日を書きます。退職者が出た後に変えていないアカウントが分かります。 10. 最後に確認した日 — この行の内容を最後に点検した日を書きます。見直しから漏れている行が分かります。 11. 記録の有無 — 誰が使ったかを残す手段があるかを書きます(サービスの利用記録、持ち出し記録、代理入力(パスワードを代わりに入力する仕組み)の記録)。残してよいかの条件になります。 12. 分けられるか — 個人アカウントに分けられるか、分けられない理由を書きます。次の判定の材料になります。 IPA の付録 6「資産管理台帳(サンプル)」は、情報資産と、関連する機器・ソフトウェアを一覧にするためのものです。上の 12 項目は、それとは別に、アカウントを 1 行ずつ管理するためのものです。 ## 判定 台帳が埋まると、アカウントごとに次の 3 つから決められます。 1. 個人アカウントに分ける — サービスが複数のユーザーを持て、費用と手間を受け入れられる場合です。個人アカウントを発行し、共有アカウントは削除するか、パスワードを変えて使えなくします。 2. 共有のまま残す — 分けられない理由があり、使う人を特定する手段を用意できる場合です。使える人を最小にし、記録の手段と退職時の手順を決めます。 3. 廃止する — 用途がない、または最後に使った日が分からない場合です。解約・削除し、台帳に廃止日を残します。 「使う人を特定する手段」は台帳とは別です。台帳は使える人を示すだけで、ある日の操作を誰がしたかは示しません。残すものの管理方法は [共有アカウントの管理](/guides/shared-accounts) で扱います。 ## 更新の頻度ときっかけ 台帳は作った日から古くなります。IPA のガイドラインは、異動や退職に伴う権限の変更・削除漏れを防ぐルールを定め、誰にどの権限を与えているかを管理するよう求めています。退職・任期満了時には、情報や機器・ID・鍵などを回収し、チェックリストや記録で、行ったことを見えるようにすることも求めています。共有アカウントの台帳では、次のきっかけで行います。 - 入社や異動で使う人が増えたら、「使っている人」「パスワードを知っている人」に追加し、二段階認証の受け取り先を確認します。 - 退職や異動で使う人が減ったら、パスワードと二段階認証を変えて最終変更日を更新し、その人を「過去に知っていた人」に移します。 - 契約更新・解約のときは、用途と所有部門を確認し、解約なら廃止日を記録します。 - 定期の見直しでは、全項目を確認して「最後に確認した日」を入れ、最後に使った日が分からないものを廃止候補にします。 定期の周期は、IPA のガイドラインでは特定の期間を定めておらず、「定期的な見直しを習慣化」とだけあります。 ## よくある質問 **棚卸しの範囲はどこまでですか** 複数人がパスワードを知っているアカウントの全部です。無料プラン、個人のカードで立て替えているもの、部門が自分で作ったもの、代表アドレスで登録したものも入れます。 **台帳にパスワードそのものを書きますか** 書きません。保管場所を書きます。台帳を読める人の全員がパスワードを知る状態になり、「知っている人」の欄が意味を失うからです。 **台帳があれば誰が使ったかの記録になりますか** なりません。台帳が示すのは使える人で、実際に使った人ではありません。IPA は共有 ID を利用したユーザーを特定できる仕組みを求めており、利用の記録は別に要ります。 **棚卸しはどのくらいの頻度で行いますか** IPA のガイドラインは特定の周期を定めていません。入退社と契約更新のたびに当てはまる行を更新し、それとは別に全行を見直す日を年 1 回など決めておきます。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」(付録の一覧)](https://www.ipa.go.jp/security/guide/sme/about.html) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify に登録した共有アカウントについては、パスワードを知る人は管理者だけになり、使える人は割り当てで決まります。台帳の「パスワードを知っている人」「使っている人」「記録の有無」の 3 列がその形で埋まり、誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 共有アカウントの二段階認証を複数人で使うときの問題と選択肢 共有アカウントの二段階認証は、コードが 1 人のスマホにしか出ないか、登録用の QR コードを配って全員が出せるかのどちらかになります。方式ごとに起きる問題と、不在と退職に備える選択肢を整理します。 更新日: 2026-10-13 共有アカウントに二段階認証を付けると、ログインには ID とパスワードのほかに、認証アプリや SMS(携帯電話のショートメッセージ)に出るコードが要ります。 ## コードが 1 人のスマホにしか出ない コードは、登録した 1 台のスマホか 1 つの電話番号にしか出ません。そのため、担当者が不在の日はほかの人が入れません(仕組みは [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification) を参照)。認証アプリの同期(別の端末でも同じ内容にそろえる機能)やバックアップは、端末を替えるための機能で、人を替える機能ではありません。Microsoft Authenticator のバックアップでも、公式サポートによると、職場または学校のアカウントはアカウント名だけが保存され、復元した後にサインインし直します。 ## 登録用の QR コードを複数人で読み取ると何が起きるか 不在に備えて取られやすいのが、認証アプリの登録時に表示される QR コードを、複数人のスマホで読み取る方法です。この QR コードには「秘密鍵」が入っています。秘密鍵は、サービスとアプリが同じコードを計算するもとになる、秘密の情報です。同じ QR コードを読み取った端末はすべて同じコードを表示するため、どの端末から入ったかをサービス側は区別できません。Microsoft Entra ID のように、1 人の利用者に複数の認証アプリを登録できるサービスもあります(認証アプリと、コードを表示する専用の小型機器を合わせて 5 つまで)。それでも、その利用者は共有アカウント 1 人として扱われます。登録した端末を誰が持っているかは、サービス側の台帳にはありません。 この運用では 3 つのことが起きます。 - 誰が使ったか分からなくなります。全員が同じコードを出せるからです。 - 秘密鍵がある場所が増えます。秘密鍵は読み取った端末の数だけコピーされ、QR コードを保存した画像にも残ります。 - 退職時に回収を確かめられません。退職者の端末から秘密鍵が消えたことを、管理者は確認できないからです。 NIST SP 800-63B Revision 4(米国の国立標準技術研究所が定めた本人確認の指針。2025 年 7 月)は、利用者が自分のログインの秘密を他人に教えないことを前提にしています。端末を替えるときは、新しい端末を登録して古い端末を使えなくすべきとし、条件を満たす同期の仕組みで秘密鍵を移す方法も認めています。複数の端末でそろえられるログイン手段を扱う付録 B は、利用者どうしで秘密鍵を共有できる作りの製品があることを認めています。そのうえで対策として、同期した秘密鍵が共有されないよう端末の管理で防ぐことと、無断で秘密鍵が使われる危険を利用者に教えることを挙げています。QR コードを配る運用は、この前提の外側にあります。 ## SMS の番号を共有する SMS を二段階目にしている場合、コードは 1 つの電話番号にだけ届きます。番号が私物の携帯なら、退職や機種変更でログインできなくなります。会社の携帯にしても、その端末を持つ人が不在の日に同じ問題が起きます。NIST SP 800-63B Revision 4 は、電話網を使う方式を制限つきの扱いにしています。サービス側には、制限のない別のログイン方式を全利用者に用意することを求め、端末の交換・SIM カードの交換・電話番号の移転などの兆候に気を配ることを勧めています。番号を誰が持ち、その人が不在のときに誰がどう入るかは、SMS の方式では決まりません。先に決めておくことになります。 ## バックアップコードをどう扱うか バックアップコードは、認証アプリや電話が使えないときに代わりに入力する、使い捨てのコードです。Google の場合、公式ヘルプによると、8 桁のコードを 10 個発行できます。1 つ使うとそのコードは使えなくなり、新しい組を発行すると古い組は全部使えなくなります。Google はコードを誰にも渡さないよう求めています。NIST SP 800-63B Revision 4 も、この種のあらかじめ配る秘密(ルックアップシークレット)は 1 回しか使えないと定めています。 共有アカウントでは、バックアップコードが不在の日の手段になります。そのため、保管場所を 1 か所にして誰が見られるかを台帳に書き、使ったら誰がいつ使ったかを記録します。担当者が替わったら、新しい組を発行して古い組を使えなくします。コードを印刷して全員に配ると、秘密鍵を配ったのに近い状態になります。 ## 退職時に何を使えなくするか 退職者の手元に残るものは方式ごとに違います。パスワードを変えるだけでは、秘密鍵とバックアップコードが残ります。 - パスワードは、サービス側で変更します。 - 認証アプリの秘密鍵(スマホの中と、QR コードの画像)は、二段階認証を設定し直し、新しい秘密鍵を残る担当者だけが登録します。 - SMS の受信番号は、会社が管理する番号に変更します。 - バックアップコードは、新しい組を発行して古い組を使えなくします。 - パスキー・セキュリティキー(端末の指紋や顔、または小さな専用の装置でログインする方式)は、登録済みのログイン手段の一覧から退職者の分を削除します。 NIST SP 800-63B Revision 4 は、利用者が資格を失ったときに、そのログイン手段をすみやかに使えなくすることを、サービスを提供する側に求めています。Microsoft Entra ID には、管理者が利用者の認証アプリと、アプリで表示するコードの登録を削除し、登録し直しを求める操作があります。どちらも 1 人ずつ登録することが前提です。共有アカウントでは、サービス側に「退職者」という利用者が存在しないため、上の操作は管理者が自分で行うことになります。 ## 方式ごとの選択肢 不在の日に入れるか、秘密鍵がどこにあるか、退職時に何をするかを、方式ごとに並べます。 | 選択肢 | 不在の日 | 秘密鍵がある場所 | 退職時にすること | | --- | --- | --- | --- | | 認証アプリを 1 台に登録 | 入れない | 1 台 | パスワードを変更。退職者の端末なら二段階認証を設定し直す | | 認証アプリを複数台に登録 | 入れる | 登録した台数分 | 二段階認証を設定し直し、残る全員が再登録する | | SMS を会社の携帯で受ける | 端末を持つ人が要る | 1 台 | 端末を持つ人が替わるなら引き継ぐ | | セキュリティキー・パスキー | 鍵を持つ人が要る | 鍵の本数分 | 退職者の鍵を削除する | | バックアップコードを保管して使う | 保管場所を開けられる人なら入れる | 保管場所 | 新しい組を発行する | どの選択肢でも、サービス側の記録に残るのは共有アカウントの名前だけです。不在の日に入れるようにするほど、秘密鍵がある場所は増えます。したがって、使った人と日時を残す記録(台帳や持ち出し記録)も同時に決めておくことになります。 ## よくある質問 **認証アプリの QR コードを全員で読み取ってもよいですか** 全員が同じコードを出せるようになり、誰が使ったかは分からなくなります。コードのもとになる秘密も端末の数だけ増え、退職時に回収を確かめられません。NIST はこの秘密を他人に教えない前提です。 **担当者が不在でもログインできるようにするには** 保管場所を決めたバックアップコードを使うか、認証アプリを複数台に登録するかです。どちらでも誰が使ったかはサービス側に残らないため、使った人と日時を別に記録します。 **退職者が出たらパスワードを変えれば足りますか** 足りません。認証アプリのコードのもとになる秘密と、バックアップコードは退職者の手元に残ります。二段階認証を設定し直して新しい秘密にし、バックアップコードも発行し直します。 **SMS の番号は会社の携帯にすべきですか** 私物の番号より会社管理の番号のほうが、退職時の引き継ぎはできます。ただしコードはその端末にしか届かないので、端末を持つ人が不在の日の手順は別に決めておきます。 ## 参考資料 - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [NIST SP 800-63B Revision 4 Section 4「Authenticator Event Management」](https://pages.nist.gov/800-63-4/sp800-63b/events/) - [NIST SP 800-63B Revision 4 Appendix B「Syncable Authenticators」](https://pages.nist.gov/800-63-4/sp800-63b/syncable/) - [Google アカウント ヘルプ「Google 認証システムで確認コードを取得する」](https://support.google.com/accounts/answer/1066447) - [Google アカウント ヘルプ「2 段階認証プロセスを有効にする」](https://support.google.com/accounts/answer/185839) - [Google アカウント ヘルプ「バックアップ コードでログインする」](https://support.google.com/accounts/answer/1187538) - [Microsoft サポート「Back up your accounts in Microsoft Authenticator」](https://support.microsoft.com/en-us/account-billing/back-up-and-recover-account-credentials-in-the-authenticator-app-bb939936-7a8d-4e88-bc43-49bc1a700a40) - [Microsoft Learn「Microsoft Authenticator authentication method - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-authenticator-app) - [Microsoft Learn「Manage authentication methods for Microsoft Entra multifactor authentication」](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userdevicesettings) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、認証アプリにコードが出る方式なら、担当者のスマホではなく Junify がコードを入力するため、不在の日のために登録用の QR コードを配る必要がありません。担当者は自分のスマホで本人確認をしてから使うので、共有のままでも誰が・いつ使ったかは一人ひとり残ります。SMS・メールで届くコードは対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # パスワードをスプレッドシートで管理する会社が最初に直すこと 最初に直すのは、そのシートを開ける人の範囲です。次に台帳としての項目を整え、最後にパスワードの値だけを別の保管場所へ移します。一覧としてのスプレッドシートは残せます。 更新日: 2026-09-17 共有アカウントの ID とパスワードをスプレッドシートに並べて管理する形は、台帳とパスワードの保管場所を 1 枚で兼ねている状態です。共有機能の記述は、Google スプレッドシートの公式ヘルプで確認できる範囲です。Microsoft Excel など他の製品でも考え方は同じですが、共有権限の名称と設定は各製品の公式ヘルプで確認が要ります。 ## スプレッドシート管理の何が問題か 表計算ソフトの共有機能は、見られる人にコピー(ダウンロード・印刷)も許す前提で作られています。パスワードを置くと、そのコピーが秘密の控えになります。 問題は 4 つです。 - 想定より多くの人がパスワードを見られます。「リンクを知っている全員」の共有はログインなしで開けるうえ、共有相手の一覧を見直さない限り、退職者や異動者が残るからです。 - シートの外に控えが増えます。はじめの設定では、見るだけの人もファイルをダウンロードでき、ダウンロードした控えはシートの共有設定の外に出ます。 - 誰がパスワードを使ったかは分かりません。変更履歴に残るのは誰がセルを書き換えたかで、誰が値を見てログインしたかではないからです。 - 退職者を共有から外しても、それまでに見たパスワードとダウンロードした控えは取り消せません。外せばシートは開けなくなりますが、見られた値はそのままです。 Google ドライブのヘルプによると、共有相手の権限は閲覧者・閲覧者(コメント可)・編集者に分かれ、はじめの設定ではどの権限でもファイルをダウンロードできます。「リンクを知っている全員」で共有したファイルは、Google アカウントへのログインなしで開けます。変更履歴を見るには編集権限が必要で、履歴に残るのはファイルを更新した人とその内容です。職場や学校のアカウントでは閲覧履歴も確認できます。ただし、閲覧履歴が残っても、その人が値を使ってログインしたかどうかまでは分かりません。 ## 最初に直すこと: 開ける人を絞る 最初にするのは、いまのシートを開ける人を、そのパスワードを使う人だけにすることです。台帳の作り直しや保管場所を移す作業より先にこれをするのには、理由があります。移す作業には時間がかかる一方で、共有設定の変更はその日のうちに終わり、終わった時点で見られる人が減るからです。 Google ドライブの共有設定で、公式ヘルプに書かれている範囲の操作は次の 4 つです。 1. 共有相手を個別に指定し、「リンクを知っている全員」の共有をやめる — ログインした特定の人だけが開ける状態にします。 2. 共有相手の一覧から、使わない人のアクセス権を削除する — 退職者・異動者・念のために加えた人を外します。 3. 「ダウンロード、コピー、印刷できるユーザー」を絞る — 閲覧者・コメント可のユーザーが控えを作れないようにします。 4. 「編集者は権限を変更して共有できます」をオフにする — 編集者が管理者に断りなく共有相手を増やせないようにします。 この 4 つを終えても、すでに配られた控えとダウンロード済みのファイルは残ります。控えを使えなくする方法は最後の段階で扱い、回収を待たずに次の段階へ進みます。 ## 次に直すこと: 台帳の項目を整える 次にするのは、シートを「パスワードの一覧」から「アカウントの台帳」に作り替えることです。パスワードの値を移す先を決めるには、アカウントが何件あり、誰が使っていて、どこに二段階認証のコードが届くかが分かっている必要があるからです。 台帳の列は、[共有アカウントの管理](/guides/shared-accounts) の「何から始めるか」で挙げた項目を使います。サービス名、アカウントの ID、パスワードの保管場所、使っている人、管理者、二段階認証の受け取り先、最後に確認した日です。これは最小の 7 項目で、全項目は[棚卸しの記事](/guides/shared-accounts/shared-account-inventory)にあります。ここでの要点は、「パスワードの保管場所」の列に、パスワードの値ではなく場所を書くことです。移し終えるまでは値の列が残りますが、行ごとに移したかどうかが分かるようになります。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)は、パスワードの保管方法として紙、ファイル、パスワード管理アプリなどを挙げています。その違いを理解し、自社に合った管理ルールを定めて従業員に周知するよう求めています。スプレッドシートは、この「ファイル」に当たります。保管方法として一時的にでも使い続けるなら、上の共有設定と控えの扱いを含めた管理ルールを文書にします。それがガイドラインの求める「ルール」に当たります。 ## 最後に直すこと: パスワードの値を別の場所へ 最後に、パスワードの値をスプレッドシートから出します。移す先の選択肢は 3 つです。[パスワードマネージャー](/guides/shared-accounts/what-is-password-manager)での共有、ID 管理サービス(Okta、Microsoft Entra ID など)の代理入力、パスワードを担当者に知らせないアクセス管理ツールです。代理入力とは、パスワードを担当者に代わって入力する仕組みです。それぞれのできること・残る限界は [共有アカウントの管理](/guides/shared-accounts) の表にまとめています。 移す順は、台帳の「使っている人」が多い行からにします。使う人が多いアカウントほど、シートを見られる人の範囲と重なり、控えも多く出回っているからです。移し終えた行は、シートの値を消し、保管場所の列を「パスワードマネージャーの◯◯保管庫(共有の単位)」のように書き換えます。移した後も、シートを見た人が知っているパスワードは変わっていません。移すと同時にそのアカウントのパスワードを変えると、シート時代に出回った控えを使えなくできます。 全行を移し終えると、スプレッドシートには秘密が残らず、どのアカウントを誰が使い、どこに保管しているかを示す台帳だけが残ります。この台帳は、見られる人の範囲を業務に合わせて決め直せ、棚卸し(何があるか一覧にすること)や退職時の確認にそのまま使えます。 ## よくある質問 **スプレッドシートでの管理はすぐにやめるべきですか** いきなりやめるより、開ける人を絞る、台帳の項目を整える、値を移す、の順で進めるほうが途中で困りません。台帳としてのシートは残せます。 **変更履歴があれば誰が使ったか分かりますか** 分かりません。変更履歴に残るのはセルを書き換えた人で、値を見てログインした人ではありません。ログインの記録はサービス側にアカウント名でしか残りません。 **共有相手から退職者を外せば十分ですか** 外せばシートは開けなくなりますが、それまでに見た値とダウンロードした控えは残ります。その人が知っていたパスワードは、変えるほかありません。 **閲覧制限をかければシートに残せますか** IPA のガイドラインは保管方法の違いを理解して管理ルールを定めるよう求めています。残すなら、共有設定と控えの扱いを含むルールを文書にし、値は別の保管場所へ移す前提で使います。 ## 参考資料 - [Google ドキュメント エディタ ヘルプ「Google ドライブのファイルを共有する」](https://support.google.com/docs/answer/2494822?hl=ja) - [Google ドキュメント エディタ ヘルプ「共有を停止、制限、変更する」](https://support.google.com/docs/answer/2494893?hl=ja) - [Google ドキュメント エディタ ヘルプ「ファイルの変更内容を確認する」](https://support.google.com/docs/answer/190843?hl=ja) - [Google ドキュメント エディタ ヘルプ「Google ドキュメント、スプレッドシート、スライドの閲覧履歴を表示する」](https://support.google.com/docs/answer/7378739?hl=ja) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、シートに書いていたパスワードの値は管理者が Junify に登録し、担当者には見せません。担当者は自分のスマホで本人確認をしてクリックするだけでログインでき、共有のままでも誰が・いつ使ったかが一人ひとり残ります。シートには、どのアカウントを誰が使うかの台帳だけが残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # Slack・メールでパスワードを送るのをやめる方法 送ったパスワードは検索で見つかり、転送や書き出しで広がり、端末と退職者のアカウントに残ります。やめるには、先に別の渡し方を用意し、そのうえで本文に書かないルールを決めます。 更新日: 2026-09-17 新しい担当者に[共有アカウント](/guides/shared-accounts/what-is-shared-account)のパスワードを伝えるとき、Slack のダイレクトメッセージ(DM)やメールで送るのは、いちばん手近な方法です。残る場所の記述は、Slack、Microsoft 365、Gmail の公式ヘルプで確認できる範囲です。 ## 送ったパスワードはどこに残るか チャットやメールの本文に書いたパスワードは、送信した時点で送り手の管理を離れます。残る場所は 4 つです。 ### 検索結果 同じチャンネルや DM の参加者なら、後から「パスワード」で検索して見つけられます。Slack では、保存されたメッセージとファイルを検索できます。有料プランでは、はじめの設定で、ワークスペース(会社ごとの Slack の場所)が続く限りデータを保存します。無料プランでも、直近 90 日のメッセージは閲覧と検索の対象で、1 年を超えたものが削除されます。 有料プランの保存期間の設定には、メッセージの編集と削除を記録する選択肢があり、本人が削除しても削除の記録が残る設定にできます。つまり、送った本人が後から消しても、消えたと確かめられるのは自分の画面だけです。 ### 転送・書き出し 受け取った人の操作や管理者の操作で、送り手の知らない相手に届きます。Gmail は、受信メールを別のアドレスへ自動転送できます。Slack はオーナー・管理者が、パブリックチャンネル(全員が見られるチャンネル)のデータをまとめて書き出せます(エクスポート)。Business+ 以上では、申請して承認されれば、プライベートチャンネルと DM も対象にできます。 ### 端末 受け取った人のパソコンやスマホのアプリに、文面が残ります。端末に何が残るかは公式ヘルプでは明示されていません。ただ、インターネットにつながっていなくても読めるように受信内容を端末に保存するアプリでは、私物のスマホにも文面が残ります。 ### 退職者のアカウント 本人がいなくなってもデータは消えません。Slack はアカウントを解除しても、その人が送ったメッセージとファイルは削除されません。Exchange(Microsoft 365 のメールの仕組み)では、削除したメールも「回復可能なアイテム」に一定期間残ります。保存期間のルール(保持ポリシー)の対象なら、退職者のメールボックスは「非アクティブなメールボックス」として残ります。 ## 代わりの渡し方 代わりの方法は、「後から取り消せるか」「期限や回数を決められるか」「そもそも渡さないか」で 3 段階に分かれます。 | 方法 | できること | 残ること | | --- | --- | --- | | パスワードマネージャーの共有 | 保管庫やコレクション(共有の単位になる入れ物)ごとに共有し、外せば以後は開けない | 見た人の記憶と控えは残る | | 期限・回数つきの共有リンク | 期限と渡す相手を決めて 1 件ずつ渡す | 相手が開いた後の控えは残る | | 渡さない方式 | 管理者だけがパスワードを持ち、担当者は代理入力(パスワードを代わりに入力する仕組み)でログインする | 方式ごとに、対象の人と端末の条件がある | 共有リンクで決められる条件は、製品で違います。1Password は、登録した 1 件(アイテム)を共有リンクで渡し、期限と相手(リンクを知っている全員か、特定の人か)を決められます。Bitwarden Send は、削除日(最長 31 日)、開ける回数の上限、パスワードによる保護を設定でき、Bitwarden を使っていない相手にも送れます。リンク自体をチャットで送るなら、有効期間は短くします。 パスワードマネージャーの共有で何が残るかは [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager)、渡さない方式の選択肢は [共有アカウントの管理](/guides/shared-accounts) にまとめています。共有リンクは「1 回だけ渡す」場面に向きます。繰り返し使う共有アカウントには、パスワードマネージャーの共有か、渡さない方式が向きます。 ## 切り替えの手順 1. 渡し方を先に決める — 「送らない」だけを先に決めると、渡し方に困った担当者はチャットに戻ります。上の表から自社の方法を選び、使える状態にしてから周知します。 2. 過去に送ったパスワードを洗い出す — Slack とメールを「パスワード」「PW」「ログイン情報」で検索し、見つかったアカウントを台帳に載せます。 3. 見つかったアカウントのパスワードを変える — 送った文面を削除しても、受け取った人の端末や、保存期間の設定による記録には残ります。削除ではなく変更で使えなくします。 4. ルールを文書にして周知する — 下の文例のように、禁止と代わりの方法を 1 組で書きます。 5. 例外の窓口と点検の頻度を決める — 緊急時に誰へ連絡するか、2 の検索による点検を何か月ごとに行うかを決めます。 ## 社内ルールの文例 社内ルールの根拠は、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)にあります。同ガイドラインは、保管方法の違いを理解した管理ルールを定め、従業員に周知するよう求めています。次の文例はその要求に対応する条文の一例で、自社の規程の形式に合わせて調整してください。規程としての効力や表現は、社内規程の担当部門や弁護士の確認を受けてください。 > (パスワードの受け渡し) > > 1. 従業員は、業務で使用するアカウントのパスワードを、チャット、電子メール、その他の記録に残る通信の本文に記載して送信しない。 > 2. パスワードの受け渡しが必要な場合は、会社が指定したパスワード管理ツールの共有機能、または有効期限を設定した共有リンクを用いる。 > 3. 前項によらずパスワードを受け渡した場合は、速やかに管理者に報告し、管理者は当該パスワードを変更する。 > 4. 管理者は、年 ◯ 回、社内のチャットおよび電子メールを点検し、本条に反する送信がないことを確認する。 第 1 項が禁止、第 2 項が代わりの方法、第 3 項が漏れたときの扱い、第 4 項が点検です。第 2 項の「会社が指定した」道具を先に用意しておくことが、この規程が守られるかどうかを左右します。第 4 項の点検は、管理者が見られる範囲(パブリックチャンネルなど)に限られます。DM やメールを含めるには、各サービスの権限と従業員への周知が要ります。 ## よくある質問 **ダイレクトメッセージなら送っても構いませんか** ダイレクトメッセージも、Slack の Business+ 以上のプランでは、申請して承認されれば書き出し(エクスポート)の対象にできます。相手の端末と退職後のアカウントに残る点は、チャンネルに書いた場合と同じです。 **送った後に削除すれば消えますか** 受け取った人の端末や転送先には残り、Slack の保存期間の設定によっては削除の記録も残ります。消すのではなく、そのパスワードを変えて使えなくします。 **期限つきの共有リンクなら安全ですか** 開ける期間と回数を絞れるので、本文に書くより残る範囲は狭くなります。開いた後の控えは残るため、繰り返し使う共有アカウントにはパスワードマネージャーの共有か、渡さない方式が向きます。 **社内ルールには何を書きますか** 本文に書かないという禁止と、代わりに使う渡し方、送った場合の報告と変更、定期的な点検の 4 点を 1 組で書きます。禁止だけを書くと、渡し方に困った担当者が元に戻ります。 ## 参考資料 - [Slack ヘルプセンター「Customize data retention in Slack」](https://slack.com/help/articles/203457187-Customize-message-and-file-retention-policies) - [Slack ヘルプセンター「Usage limits for free workspaces」](https://slack.com/help/articles/115002422943-Message-file-and-app-limits-on-the-free-version-of-Slack) - [Slack ヘルプセンター「Deactivate your Slack account」](https://slack.com/help/articles/203953146-Deactivate-a-member-s-account) - [Slack ヘルプセンター「Export your workspace data」](https://slack.com/help/articles/201658943-Export-your-workspace-data) - [Slack ヘルプセンター「Search in Slack」](https://slack.com/help/articles/202528808-Search-in-Slack) - [Microsoft Learn「Exchange のアイテム保持の詳細」](https://learn.microsoft.com/ja-jp/purview/retention-policies-exchange) - [Gmail ヘルプ「Gmail のメールを他のアカウントに自動転送する」](https://support.google.com/mail/answer/10957?hl=ja) - [1Password Support「Securely share 1Password items with anyone」](https://support.1password.com/share-items/) - [Bitwarden Help Center「About Send」](https://bitwarden.com/help/about-send/) - [Bitwarden Help Center「Send Lifespan」](https://bitwarden.com/help/send-lifespan/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、担当者にパスワードを渡す場面がなくなります。管理者が共有アカウントの ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインするため、チャットやメールでパスワードを送る必要がありません。誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # パスワードマネージャーとは パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。 更新日: 2026-10-13 パスワードマネージャーとは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。 ## パスワードマネージャーとは何か ID とパスワードは、保管庫(vault)と呼ばれる、他人が読めない形にした置き場に入れます。利用者は、1 つの合言葉(マスターパスワード)などで保管庫を開きます。すると、ブラウザーの拡張機能(ブラウザーに追加する小さなプログラム)やアプリが、ログイン画面に ID とパスワードを入力します。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、紙、ファイル、パスワード管理アプリ等の保管方法の違いを理解し、自社に合った管理ルールを定めるよう求めています。パスワードマネージャーは、その保管方法の選択肢の 1 つです。 ## 共有機能で何ができるか 業務向けの製品は、保管庫やコレクション(Bitwarden の共有の単位)を複数人で共有できます。1Password の Teams 向け公式ヘルプでは、共有した保管庫の項目をメンバーやグループが見たり編集したりでき、権限は閲覧・編集・管理の 3 段階です。Bitwarden の公式ヘルプでは、コレクションごとに、閲覧、閲覧(パスワードは隠す)、編集、編集(パスワードは隠す)、管理の権限を割り当てられます。共有によって、パスワードをメールやチャットで送る必要はなくなります。 ## 共有した相手はパスワードを知るのか 閲覧権限を与えた相手は、パスワードを見られます。1Password の Teams 向けヘルプでは、閲覧権限に、隠されたパスワードの表示とコピーが含まれます。Bitwarden にはパスワードを隠す権限があります。しかし公式ヘルプは、隠したパスワードも自動入力では使えると明記しています。隠すのはアクセスを制限するだけで防ぐものではないため、共有済みのパスワードとして扱うように、という内容です。 ## 記録はどの単位で残るのか サービスへのログインは、共有アカウントの名前で行われます。パスワードマネージャーが受け持つのは保管庫からログイン画面までです。その先のサービス側の記録には、誰が自動入力を使ったかは残りません。保管庫の中の操作の記録は、法人向けプランの一部にあります(1Password は Business の使用状況レポート、Bitwarden は Teams・Enterprise のイベントログ)。 ## 退職時に何が起きるか 退職者を保管庫やコレクションから外すと、その人は保管庫を開けなくなります。Bitwarden の公式ヘルプは、一時的に使えなくする操作(revoke)と、完全に削除する操作(remove)を分けて用意しています。しかし、外す前にパスワードを見られた人の記憶や控えまでは取り消せません。サービス側のパスワードを変えるまで、その人がログインできる状態は残ります。パスワードマネージャーを使っていても、退職時にサービス側のパスワードを変える運用は残ります(変えた後の配布は保管庫が受け持ちます)。 ## よくある質問 **共有した相手にパスワードは見えますか** 見る権限があれば見えます。パスワードを隠す権限を持つ製品もありますが、隠しても自動入力で使えるため、Bitwarden の公式ヘルプは共有済みのパスワードとして扱うよう求めています。 **退職者を保管庫から外せば安全ですか** 外した後は保管庫を開けなくなりますが、見られた人の記憶や控えまでは取り消せません。サービス側のパスワードを変えるまで、ログインできる状態は残ります。 **パスワードマネージャーで誰が使ったか分かりますか** サービス側の記録は共有アカウントの名前で残り、区別できません。保管庫の中の記録は、法人向けプランの一部にあります(1Password は Business、Bitwarden は Teams・Enterprise)。 ## 参考資料 - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [Bitwarden Help Center「Collection permissions」](https://bitwarden.com/help/collection-permissions/) - [Bitwarden Help Center「Managing users」](https://bitwarden.com/help/managing-users/) - [1Password Support「Create reports in 1Password Business」](https://support.1password.com/reports/) - [Bitwarden Help Center「Event Logs」](https://bitwarden.com/help/event-logs/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify はパスワードを保管して配る道具ではなく、担当者に見せずに代わりに入力する仕組みです。担当者は自分のスマホで本人確認をしてからログインするため、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。担当を外れたら、管理者が使える人からその人を外すだけで、パスワードを変えて配り直す必要はありません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 共有アカウントとは 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。 更新日: 2026-09-17 共有アカウントとは、1 つのサービス上の 1 つのアカウント(ID とパスワードの組)を、複数の人が使う状態を指します。 ## 個人アカウントと何が違うか 違いは、サービス側の記録が人を指すかどうかにあります。個人アカウントでは、ログインしたユーザー名がそのまま操作した人を指します。共有アカウントでは、記録に残るのはアカウントの名前だけです。操作した人は、台帳や聞き取りなど別の手段で確かめるほかありません。 ## なぜ共有アカウントが生まれるのか 理由はサービス側の設計にあります。Microsoft Entra ID の公式ドキュメントは、1 組のユーザー名とパスワードを複数人で使う場面を 2 つ挙げています。1 つは、企業の SNS アカウントのようなアプリケーションです。もう 1 つは、Microsoft 365 の管理者アカウントのように、設定・管理・復旧に使う強い権限を持つ 1 つだけのアカウントです。利用者側でサービスの仕組みは変えられないため、人数分のアカウントを作れないサービスでは共有が唯一の使い方になります。 ## 担当者が辞めるとどうなるのか 辞めた人や担当を外れた人のアクセスを止めるには、パスワードを変えて残る全員に配り直すしかありません。パスワードを知っている人は、変更されるまで誰でもログインできるからです。 ## 法令やガイドラインではどう扱われているか 個人情報保護法 23 条は、個人情報を扱う事業者に、個人データの安全管理のために「必要かつ適切な措置」(漏えいなどを防ぐための対策)を求めています。個人情報保護委員会のガイドライン(通則編、令和 8 年 6 月一部改正)は、その内容を「10(別添)講ずべき安全管理措置の内容」に示しています。そのうち技術的安全管理措置(仕組みで行う対策)として 4 つの措置を挙げており、共有アカウントに関わるのは次の 2 つです。1 つはアクセス制御で、担当者ごとに、扱える個人情報のデータベースなどの範囲を限ります。もう 1 つはアクセス者の識別と認証で、情報システムを使う従業者が正当なアクセス権を持つ者であることを、識別した結果に基づいて認証します。どちらも行わなければならない措置です。 2 つ目の「識別した結果に基づいて認証する」とは、誰かを確かめたうえで、権限のある人だけをログインさせることです。共有アカウントでは、情報システムの側で誰が使ったかを確かめられません。そのため、個人データを扱うシステムで使うなら、誰が使ったかを特定する手段を別に用意する必要があると読めます。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)は、第 2 部「実践編」の「攻撃等の防御」で共有 ID の扱いを書いています。共有 ID はなるべく使わず、やむを得ず使う場合は、共有 ID を使った人を特定できる仕組みを整え、決めたとおりに運用するよう求めています。異動や退職にともなう権限の変更・削除漏れを防ぐルールも挙げています。どちらの文書も共有アカウントそのものを禁じてはいません。求めているのは、使う人を特定できることと、要らなくなったアクセスを外せることの 2 つです。 ## よくある質問 **共有アカウントを使うこと自体は違法ですか** 確認した 2 つの文書に、共有そのものを禁じる記述はありません。個人情報保護委員会のガイドラインは、個人データを扱うシステムで誰が使うかを確かめてからログインさせることを求めており、その手段を用意する責任が残ります。 **代表アドレスも共有アカウントですか** 1 つのメールアカウントのパスワードを全員で使っているなら共有アカウントです。共有メールボックスの機能を使い、各自のアカウントでアクセスする形にすれば共有ではなくなります。 **共有アカウントと個人アカウントの見分け方は** サービスの記録に残るユーザー名が操作した本人を指すなら個人アカウント、アカウントの名前しか残らず操作した人を別に確かめる必要があるなら共有アカウントです。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「About shared mailboxes in Microsoft 365」](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify は、共有アカウントを廃止せずに、担当者がスマホで本人確認をしてから使う形にする仕組みです。サービス側の記録がアカウントの名前のままでも、誰が・いつ使ったかは Junify の側に一人ひとり残るため、誰が使ったかを確かめる手段を台帳や聞き取りの外に用意できます。パスワードは管理者が登録し、担当者には渡りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 二段階認証(二要素認証)とは 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。 更新日: 2026-10-13 二段階認証とは、パスワードに加えて 2 つ目の確認を求めるログイン方式です。 ## 二段階認証とは何か Google のヘルプは、2 段階認証プロセスを、パスワードが盗まれた場合に備える仕組みと説明しています。two-factor authentication(二要素認証)と同じ意味で使っています。厳密な定義は NIST SP 800-63B Revision 4(2025 年 7 月)にあります。知っているもの(パスワード)、持っているもの(スマホやセキュリティキー)、本人の身体(生体)のうち、異なる 2 種類を持っていることを証明する方式を、多要素認証としています。 ## 方式にはどんな違いがあるか 二段階目の方式は 4 つに分かれます。何を使うかと、NIST SP 800-63B Rev. 4 での扱いを並べます。 | 方式 | 何を使うか | NIST SP 800-63B Rev. 4 での扱い | | --- | --- | --- | | 認証アプリ | スマホのアプリが 30 秒ごとに作る使い捨てのコード | 1 つの方法として数える。偽サイトにだまされるとコードを盗まれうる(3.1.4) | | SMS・音声通話 | 登録した電話番号に届くコード | 電話回線で受け取る方式は制限つき(3.1.3.3) | | メール | メールアドレスに届くコード | 二段階目としての利用を認めない(3.1.3.1) | | セキュリティキー・パスキー | 手元の物理キーや端末の中の暗号の鍵 | 偽サイトにだまされても盗まれない仕組みと認める(3.2.5) | 認証アプリのコードは、RFC 6238 という規格で決められた方式(TOTP、時刻をもとに作る使い捨てコード)で作られます。サービスとアプリが同じ秘密の値(秘密鍵)を持ち、今の時刻からそれぞれ同じコードを計算します。コードは通信で届くのではなく、秘密鍵を持つ端末の中で作られます。有効期間は既定で 30 秒です。 ## 共有アカウントで複数人が使うと何が起きるか 二段階目は、本人だけが持つものを前提に設計されています。NIST SP 800-63B も、利用者が自分のログインの秘密を他人に教えないことを前提にしています。共有アカウントで複数人が使うと、この前提が 2 つの形で当てはまらなくなります。 1 つは、コードが 1 か所にしか出ないことです。認証アプリの秘密鍵は登録したスマホにあり、SMS は登録した電話番号に届き、セキュリティキーは 1 人の手元にあります。担当者が不在の日は、ほかの人がログインできません。Google 認証システムのように、Google アカウントにログインして複数の端末で同じコードを出せるようにするアプリもあります。ただし、その対象は自分の Google アカウントでログインした端末です。 もう 1 つは、共有すると誰が使ったか分からなくなることです。秘密鍵の QR コードを全員のスマホで読み取る運用にすると、二段階目が指すのは「秘密鍵を持つ誰か」になり、本人を特定する意味は失われます。管理方法の選択肢は [共有アカウントの管理](/guides/shared-accounts) にまとめています。 ## よくある質問 **二段階認証と二要素認証は同じですか** 日常では同じ意味で使われます。厳密には、二要素認証は知っているもの・持っているもの・本人の身体のうち異なる 2 種類を組み合わせる方式を指し、NIST はこの区別で定義しています。 **共有アカウントの認証アプリを全員のスマホに入れてよいですか** 登録用の QR コードを全員が読み取ればどのスマホでもコードは出ますが、誰が使ったかは分からなくなります。NIST は、利用者がログインの秘密を他人に教えないことを前提にしています。 **SMS で届くコードは使わないほうがよいですか** NIST SP 800-63B は、電話で受け取る方式を制限つきの扱いにし、メールを二段階目に使うことは認めていません。認証アプリのコードは偽サイトで盗まれうる扱い、セキュリティキーは盗まれない扱いです。 ## 参考資料 - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [IETF RFC 6238「TOTP: Time-Based One-Time Password Algorithm」](https://datatracker.ietf.org/doc/html/rfc6238) - [Google アカウント ヘルプ「2 段階認証プロセスを有効にする」](https://support.google.com/accounts/answer/185839) - [Google アカウント ヘルプ「Google 認証システムで確認コードを取得する」](https://support.google.com/accounts/answer/1066447) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify では、担当者が自分のスマホで本人確認をしてから共有アカウントを開くため、二段階認証を共有しても、誰が・いつ使ったかは一人ひとり残ります。認証アプリにコードが出る方式なら、コードは Junify が入力し、担当者のスマホに頼りません。SMS・メールで届くコードは対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 共有アカウントを個人アカウントに分けられないケースの整理 原則は 1 人 1 アカウントです。それでも、サービスがアカウントを 1 つしか持てない、公式アカウントそのもの、管理者アカウントが 1 つ、外部の人に発行できない、といった場合は共有が残ります。残すものに何を求めるかを整理します。 更新日: 2026-09-17 共有アカウントを減らす原則は 1 人 1 アカウントです。ただし、サービス側の作りや契約の形によって、分けたくても分けられないものが残ります。共有アカウントの定義は [共有アカウントとは](/guides/shared-accounts/what-is-shared-account) にあります。 ## 先に分ける IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)は、ID の発行から削除までを管理する手順を定め、ID を渡す相手を必要最小限にするよう求めています。共有 ID はなるべく使わないようにも求めています。個人アカウントに分けると、サービス側の記録がそのまま操作した人を指し、退職時にはその人のアカウントを止めるだけで済みます。したがって、分けられるものを分けるのが先です。この記事の整理は、そのあとに残ったものが対象です。 分けられるのに分けていないアカウントは、分けられないアカウントと区別します。代表アドレスはその典型です。Microsoft 365 の共有メールボックス(複数人で使うための受信箱)は、各自が自分のアカウントで開く前提で作られています。共有メールボックス自体のアカウントでのサインイン(ログイン)は、常に止めておくよう公式ドキュメントに書かれています。Google Workspace にも、グループを「共同トレイ」として使い、メンバーにメールの担当を割り当て、完了にする機能があります。代表アドレスのパスワードを全員で使っているなら、それは分けられないのではなく、分けていないだけです。 ## 分けられない典型 Microsoft Entra ID の公式ドキュメントは、1 組のユーザー名とパスワードを複数人で使う場面を 2 つ挙げています。1 つは、利用者ごとに固有のサインインを求めるアプリ(企業の SNS アカウントなど)です。もう 1 つは、設定・管理・復旧に使う、権限の強い 1 つだけのアカウント(Microsoft 365 の管理者アカウント、Salesforce の最上位の管理者アカウント)です。この 2 つに、契約と体制の事情を加えると、分けられない典型は 5 つに整理できます。 ### サービスがアカウントを 1 つしか持てない 利用者ごとにログインを求める作りでありながら、追加ユーザーや権限を分ける機能がないサービスです。この型に当たる具体的な例は、確認した公式資料にはありません。 ### 公式アカウントや代表の ID そのもの アカウントの名前が対外的な資産になっていて、別のアカウントに分けると意味を失います。Microsoft は、利用者ごとに固有のサインインを求めるアプリの例として、企業の SNS アカウントを挙げています。 ### 管理者アカウントが 1 つ 設定・管理・復旧に使う、権限の強いアカウントが 1 つしかない場合です。公式資料の例は、Microsoft 365 の管理者アカウントと、Salesforce の最上位の管理者アカウントです。 ### 追加ユーザーに費用がかかる 利用者の数で料金が決まり、たまにしか使わない人の分まで契約しないと決めた場合です。公式資料に例はなく、契約上の判断として分けないと決めたものに当たります。 ただし、そのアカウントを共有のまま管理する仕組みにも、人数分の費用がかかる場合があります。Entra ID には、共有アカウントのパスワードを代わりに入力する方式(password-based SSO)があります。共有アカウントを使う利用者ごとに、Entra ID P1 または P2 相当の契約プランが要ります。費用で分けないなら、個人アカウントの追加費用と、共有のまま管理する費用を並べて比べることになります。 ### 外部の人に個人アカウントを発行できない 社内の利用者しか登録できないか、外部の人には発行しない方針がある場合です。Microsoft 365 の共有メールボックスは社外の人に使わせられず、公式ドキュメントは社外の人には別の仕組みを案内しています。 ## 残す共有アカウントに求めること 残す共有アカウントには、共通して 3 つを決めます。パスワードを知っている人の範囲、誰が使ったかを残す記録、退職時の手順です。前の 2 つは、IPA のガイドラインが共有 ID に求める「利用したユーザーを特定可能とするような仕組み」(誰が使ったか分かるようにすること)に当たります。最後の 1 つは、同じガイドラインが求める、退職・任期満了時の ID の回収と、行ったことを記録で見えるようにすることに当たります。ケースごとに、求める中身は変わります。次の表は決め方の一例です。表にある代理入力とは、パスワードを担当者に代わって入力する仕組みを指します。 | ケース | 知っている人の範囲 | 記録 | 退職時の手順 | | --- | --- | --- | --- | | アカウントを 1 つしか持てないサービス | 使う人に限る(代理入力を使えれば管理者だけ) | 使った人と日時を、台帳か代理入力の仕組みで残す | パスワードと二段階認証を変え、バックアップコードを発行し直す | | 公式アカウント | 投稿する人と管理者に限る | 投稿した人と承認した人を残す | 上と同じに加え、つないでいる外部アプリの許可も見直す | | 管理者アカウント | 日常の操作は個人の権限で行い、用途を限る(例: 復旧と初期設定) | 使うたびに、誰が何のために使ったかを残す | 復旧用の ID とパスワードを作り直す | | 費用で分けない | 使う頻度の低い人には、代理入力か、使う都度の貸し出しで対応する | 貸し出しの記録 | 貸し出し先から外し、パスワードを変える | | 外部の人 | 契約上の担当者に限り、契約書に共有の禁止と返却を定める | 委託先に利用の記録を求める | 契約終了時にパスワードと二段階認証を変える | 「知っている人の範囲」を使う人より狭くできるのは、パスワードを知らなくても使える手段があるときだけです。管理者だけがパスワードを持ち、ほかの人は代理入力で使う形にできれば、知る人は 1 人になります。ID 管理サービス(Okta、Microsoft Entra ID など)の代理入力と、アクセス管理ツールの違いは [共有アカウントの管理](/guides/shared-accounts) の表にまとめています。手段がなければ、知っている人と使う人は一致します。退職時にはそのたびにパスワードを変えて、残る全員に配り直すことになります。外部の人の行にある契約書の項目は、契約に含める項目の例です。条項の表現は法務の確認を受けてください。 ## 判断の順序 1. サービスが複数のユーザーを持てるかを公式ヘルプで確かめます。持てるなら分けます。代表アドレスは、共有メールボックスやグループの機能に置き換えます。 2. 分けられない理由が費用なら、個人アカウントの追加費用と、共有のまま管理する費用を並べて比べます。 3. 残すと決めたアカウントは、知っている人の範囲・記録・退職時の手順の 3 つを台帳に書きます。3 つのどれかが書けないアカウントは、まだ残す条件を満たしていません。 ## よくある質問 **SNS の公式アカウントは個人に分けられますか** アカウントそのものは 1 つで分けられません。媒体側に複数人へ権限を与える仕組みがあるかを公式ヘルプで確かめ、なければ共有のまま、知っている人の範囲・記録・退職時の手順を決めます。 **管理者アカウントが 1 つしかないサービスはどうしますか** 日常の操作は個人に与えた権限で行い、1 つだけの管理者アカウントの用途を限ります(例: 復旧と初期設定)。使うたびに誰が何のために使ったかを記録し、退職者が出たら ID とパスワードを作り直します。 **追加ユーザーの費用を理由に共有を残せますか** 分けない判断は成り立ちます。ただし、使う人を特定する手段と退職時の手順を用意する責任は残り、共有アカウントを管理する仕組みにも人数分の費用がかかる場合があります。 **外部の委託先には共有アカウントを渡すほかありませんか** サービスが外部の人を登録できないなら共有が残ります。契約で共有の禁止と返却を定め、知る人を契約上の担当者に限り、契約が終わったらパスワードと二段階認証を変えます。条項の表現は法務の確認を受けます。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「About shared mailboxes in Microsoft 365」](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes) - [Google Workspace ラーニング センター「Use a group as a Collaborative Inbox」](https://support.google.com/a/users/answer/167430) ## Junify の場合 **人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。 **Junify なら** Junify は、分けられずに残る共有アカウントを前提にした仕組みです。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけなので、パスワードを知る人は増えず、共有のままでも誰が・いつ使ったかは一人ひとり残ります。担当を外れたら、管理者が使える人からその人を外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=shared-accounts) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Google スプレッドシートにパスワードはかけられるか](/guides/shared-accounts/google-sheets-password-protection): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。 - [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](/guides/shared-accounts/password-length-recommendations): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。 - [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](/guides/shared-accounts/personal-password-manager-at-work): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。 --- # 運用代行のクライアントアカウント管理 預かり方は権限付与・ID とパスワードの共有・アクセス管理ツールの 3 つ。違いは「誰が使ったかが残るか」と「担当交代時に何をするか」に出ます。 更新日: 2026-10-13 クライアントから SNS 公式・広告・EC モールのアカウントを預かって運用する会社では、預かり方によって 2 つのことが変わります。事故のあとに説明できることと、担当交代時の作業です。媒体(Google 広告や LINE などのサービス)ごとの権限の付け方は媒体別の記事で扱います。 ## クライアントのアカウントを預かるとはどういうことか アカウントを預かるとは、クライアントが所有するアカウントを、運用代行会社の担当者が業務のために操作できる状態にすることです。所有者はクライアントのままで、運用代行会社は任された範囲で操作します。この「委任の範囲」(何をしてよいか)と「アカウントの扱い」(どうやって入るか、誰が ID とパスワードを持つか)は別の問題です。契約で委任の範囲を決めても、アカウントの扱いは決まりません。詳しくは[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。 アカウントの扱いが問題になる理由は、クライアントと運用代行会社の両方にあります。クライアントから見ると、自社の名前で投稿・出稿・受注が起きるアカウントを社外の人に操作させています。運用代行会社から見ると、預かるアカウントの数はクライアント数と媒体数の掛け算になります。一人の担当者が、複数のクライアントの同じ管理画面を扱うことになります。アカウントの取り違えや、担当交代時の回収漏れは、この数と重なりから起きます。 ## 預かり方の 3 つの型 預かり方は、誰が ID とパスワードを持ち、媒体にどのような形で入るかで 3 つに分かれます。 1. 権限付与: クライアントの管理下にアカウントを置いたまま、媒体の仕組みで運用代行会社の担当者を招待する。担当者は自分のユーザーとして入り、クライアントのパスワードは知らない。 2. ID とパスワードの共有: クライアントの ID とパスワードをそのまま受け取り、担当チームで共有して使う。 3. アクセス管理ツール: 運用代行会社が ID とパスワードをツールに登録し、担当者はツールを通してログインする。担当者はパスワードを見ず、ツールが担当者ごとの利用を記録する。パスワード自体を担当者に配る道具(パスワードを保管して配れるアプリなど)は 2 の共有に含める。 | | 権限付与 | ID とパスワードの共有 | アクセス管理ツール | | --- | --- | --- | --- | | できること | 担当者ごとに権限の種類を分ける | 媒体の仕組みに関係なく、どのアカウントでも使える | 権限付与のない媒体でも、担当者にパスワードを見せずに使わせる | | できないこと | 媒体に仕組みがなければ使えない | 誰が操作したかを担当者まで絞れない | 媒体から見た権限は共有 ID のまま | | 記録の単位 | 招待された担当者(媒体が履歴を残す範囲で) | 共有した ID 1 つ | ツールにログインした担当者 | | 担当交代時に起きること | クライアント側か代理店側の管理アカウント(Google 広告の MCC など)で、その人の権限を媒体ごとに削除する | クライアントにパスワード変更を頼み、共有している全員に配り直す | ツール上でその担当者の利用を止める | 表に入りきらない点を型ごとに 1 つずつ添えます。権限付与は、始めるのにクライアント側の設定を変えてもらう必要があります。共有では、担当者ごとにできる操作を分けることもできません。アクセス管理ツールは、導入と登録の手間がかかる代わりに、担当交代のときにパスワードを変えずに済みます。 3 つはどれか一つを選ぶものではなく、組み合わせられます。権限付与ができる媒体はそれを使い、できない媒体を共有 ID かアクセス管理ツールで扱う形が現実的です。権限付与の仕組みについては[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で説明しています。 ## なぜ ID とパスワードの共有が残るのか 権限付与があれば共有は要らないはずですが、実際には共有 ID が残ります。理由は 3 つに分けられ、どれも運用代行会社の側だけではなくせません。 第一に、媒体が権限付与の仕組みを提供していない場合です。ログインの手段が 1 組の ID とパスワードしかない管理画面では、預かり方は共有かアクセス管理ツールに限られます。 第二に、権限付与はあるが、招待されたユーザーにはできない操作がある場合です。所有者のユーザーでしか変えられない設定や、招待された権限では開けない画面があります。その操作のために、所有者の ID を共有する運用が残ります。 第三に、クライアント側の設定を変えられない事情です。権限付与は所有者が招待する仕組みなので、クライアントの担当者に設定の操作を頼まなければ始まりません。クライアントに媒体の管理画面に詳しい人がいない、対応が後回しになる、契約の途中で頼みにくい、といった理由があります。その結果、受け取った ID とパスワードをそのまま使い続けることになります。この運用は珍しくないでしょう。 どの媒体がどの理由に当たるかは変わるので、媒体別の記事で扱います。残った共有 ID について「誰が知っていて、誰がいつ使い、担当交代時にどうするか」が決まっているかが問題です。 ## クライアントに説明を求められる場面 預かり方の違いは、クライアントに説明を求められたときに表に出ます。場面は 3 つあります。 セキュリティチェックシート(委託先の安全対策を確かめる質問票)は、個人情報保護法をもとに求められることがあります。同法 25 条は、個人データの取扱いを委託する事業者に、委託先への「必要かつ適切な監督」(委託先がきちんと扱っているか確かめること)を求めています。個人情報保護委員会のガイドライン(通則編)は、その監督の内容として 3 点を挙げています(3-4-4)。適切な委託先の選定、委託契約の締結、委託先における個人データ取扱状況の把握(委託先がどう扱っているかを知ること)です。チェックシートは、預かる業務に個人データの取扱いが含まれる場合、この把握の一手段として求められると読めます。EC モールの受注情報や広告の顧客リストを扱う委託では、運用代行会社はこの監督の対象になると読めます。そのため、アカウントを誰がどう使っているかの説明を求められます。個人データを扱えば、運用代行会社自身も 23 条の安全管理措置(個人データを守るための対策)を負います。それに加えて、委託元の監督(25 条)に応える立場になります。 25 条が及ぶかどうかは、預かる業務に個人データの取扱いが含まれるかで決まります。投稿の作成と配信だけなら含まれないこともあります。DM への対応、キャンペーンの応募者情報、広告の顧客リストを扱えば含まれます。含まれない業務では、説明を求める根拠は契約と取引の慣習になります。 事故時の報告では、誤投稿や誤設定が起きたときに、誰がいつ操作したかを答えられるかが問われます。共有 ID では媒体の記録が ID 単位です。媒体の記録だけでは担当者まで絞れず、勤務時間や作業の分担と突き合わせることになります。権限付与かアクセス管理ツールなら、記録が担当者単位で残ります。 担当交代では、辞めた人や外れた人がクライアントのアカウントに入れない状態を示す必要があります。作業は上の表のとおりです。共有 ID ではクライアントにパスワード変更を頼むことになり、その依頼自体が「共有していた」ことの説明になります。 ## 何から始めるか 最初の作業は、預かっているアカウントの一覧を作ることです。1 行に 1 アカウントずつ、次の項目を書きます。クライアント名、媒体、アカウント、預かり方(権限付与・共有・ツール)、使っている担当者、二段階認証のコード(ログイン時に届く使い捨てのコード)を誰が受け取っているか、です。この一覧がないと、担当交代時に何を外せばよいかが分かりません。 次に、一覧の中で権限付与に移せるものを選びます。媒体に仕組みがあり、クライアントに招待の操作を頼める関係にあるアカウントから、担当者ごとの招待に切り替えます。切り替えの際に、それまで共有していたパスワードをクライアントに変更してもらうと、共有の状態を終えられます。 最後に、残る共有 ID の扱いを決めます。アカウントごとに 3 つを書き添えます。パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法(アクセス管理ツールを挟むか、作業記録を手で残すか)です。ここまでできると、クライアントから説明を求められたときに、一覧を見せて答えられる状態になります。 ## このテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 - [運用代行会社がクライアントとの契約に入れておくアカウントの条項](/guides/agency-accounts/account-clauses-for-service-providers): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 - [Amazon セラーセントラルのユーザー権限と、運用代行会社への渡し方](/guides/agency-accounts/amazon-seller-central-user-permissions): ヘルプはログイン情報を誰とも共有しないよう求めています。大口出品なら、社内の担当者は「従業員の管理」から招待し、運用代行会社はサービスプロバイダーとして承認します。どちらもユーザー権限の画面から外せます。 - [クライアントのアカウントの二段階認証を運用チームで受けるには](/guides/agency-accounts/client-two-step-verification-for-teams): 担当者ごとに招待してもらい、各自のアカウントの二段階認証で入る形に切り替えると、コードの受け渡しはなくなります。所有者のログインが残るアカウントは、受け取り先・予備のコード・使った人の記録をクライアントと決めます。 - [カスタマーサポート代行で、クライアントの Zendesk・Freshdesk に入るときのアカウントと権限](/guides/agency-accounts/cs-outsourcing-helpdesk-access): オペレーター 1 人ずつ、代行会社が管理するアドレスでエージェントを作ってもらいます。Zendesk・Freshworks の契約は 1 つのログインの共用を認めていません。権限と範囲は受け持つ分に絞り、外れる人はクライアントが停止します。 - [EC 運営代行で、受注データや顧客データの書き出しをどう制限するか](/guides/agency-accounts/ec-order-data-download-control): 書き出しの権限は要る担当者にだけ付けます。Shopify は注文と顧客の書き出しを個別に外せます。BASE は書き出しの App をスタッフが使えるか、画面で確かめます。外せない分は、置き場所・削除・記録の決まりで補います。 - [GA4 とタグ マネージャーの権限を代理店・制作会社に渡すとき](/guides/agency-accounts/ga4-gtm-agency-access): GA4 はアカウントかプロパティの単位で閲覧者・編集者などの役割を、タグ マネージャーはコンテナ単位で編集・公開などの権限を渡します。管理者は持ち主の会社に残し、契約終了時は両方のユーザー一覧と Google 広告のリンクを確かめます。 - [Google ビジネス プロフィールのオーナーと管理者を、本部・店舗・運用代行会社でどう分けるか](/guides/agency-accounts/google-business-profile-managers): 管理者も投稿・クチコミへの返信・営業時間の編集ができ、ユーザーの追加と削除、プロフィールの削除はオーナーだけです。メインのオーナー権限は本人しか譲れないので、本部が持てば、代行会社との契約が終わるときに代行会社の操作を待たずに済みます。 - [運用代行会社の ISMS・P マーク審査で、クライアントから預かったアカウントをどう説明するか](/guides/agency-accounts/isms-pmark-for-agencies): 預かったアカウントは、ISMS では適用範囲に含める資産として、P マークでは受託した個人情報がある場所として扱うと読めます。審査では、アカウントの一覧、使える人、使った記録、外した記録、契約の約束を示します。 - [Microsoft 広告を代理店に任せるときの役割の付け方と外し方](/guides/agency-accounts/microsoft-ads-agency-access): 担当者を 1 人ずつ招待する形と、クライアントの広告アカウントを代理店のマネージャー アカウントにつなぐ形の 2 つ。運用担当にはキャンペーンか標準を付けます。招待した人は 1 人ずつ削除し、リンクは解除すると代理店の全員が外れます。 - [在宅のオペレーターにクライアントの管理画面を使わせるとき、決めることと確かめること](/guides/agency-accounts/remote-operators-client-admin-access): 決めるのは、在宅で扱うアカウント、使う端末、ログインの渡し方、端末に残してよいデータの 4 つです。確かめるのは端末の状態と、誰がいつ入ったかを後で示せるかです。管理画面に直接つなぐ形では、記録は媒体の側にしか残りません。 - [運用代行の作業記録を、クライアントにどう報告するか](/guides/agency-accounts/reporting-work-records-to-clients): 媒体の操作履歴から日時・担当者・操作を抜き出して報告に添えます。媒体の履歴で担当者まで分からない共有 ID のアカウントは社内の作業記録で補い、各行がどちらに基づくかを書き分けます。 - [Yahoo!広告(現 LINEヤフー広告)を代理店や複数人で運用するときの権限付与](/guides/agency-accounts/yahoo-ads-agency-access): 管理権限を持つ人が担当者のビジネス ID を招待し、管理・登録更新・参照の 3 種類から権限を選びます。代理店の MCC につないで任せる形もあります。どちらの形でもパスワードは渡さず、外すときは権限の削除かリンクの解除です。 - [YouTube チャンネルを社内の複数人や運用代行会社と運用するときの権限](/guides/agency-accounts/youtube-channel-permissions): YouTube Studio の「チャンネルの権限」で、担当者のメールアドレスごとに管理者・編集者・閲覧者などの役割を付けて招待すれば、Google アカウントのパスワードを渡さずに任せられます。外すときは同じ画面でアクセス権を削除します。 - [クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/guides/agency-accounts/answering-security-questionnaires): 設問は個人情報保護委員会ガイドライン(通則編)別添の安全管理措置の項目に対応しています。現状をそのまま書き、共有 ID は管理方法まで書き、対応予定には期限と担当を添えます。 - [楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](/guides/agency-accounts/ec-mall-store-admin-access): 楽天は担当者ごとの楽天 ID を店舗の管理者が承認し、Yahoo! はビジネスマネージャーでツール管理者が従業員のビジネス ID を登録します。どちらも担当者ごとに ID を持つ仕組みです。 - [「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型](/guides/agency-accounts/explaining-account-handling-in-sales): 預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。 - [Google 広告の MCC(クライアント センター)で代理店アクセスを整理する](/guides/agency-accounts/google-ads-mcc-agency-access): クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。 - [運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist): 交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。 - [LINE 公式アカウントを複数人・外部と運用するときの権限](/guides/agency-accounts/line-official-account-permissions): 管理者が発行する認証用 URL で担当者ごとにメンバーを追加し、管理者か運用担当者の権限を持たせます。外部の運用代行会社も同じ形で追加でき、外すときはメンバーのリストから削除します。 - [Meta(Facebook・Instagram)のビジネスポートフォリオで代理店に権限を付与する仕組みと、できないこと](/guides/agency-accounts/meta-business-portfolio-agency-access): クライアントのポートフォリオに担当者を「人」として招くか、代理店のポートフォリオを「パートナー」としてつなぎます。ページ・広告アカウント・Instagram ごとに、許す操作(タスク)を付けます。取り消しは所有者側の操作です。 - [Shopify・BASE などカート側のスタッフ権限と、運用代行会社への渡し方](/guides/agency-accounts/shopify-base-staff-permissions): Shopify はスタッフの招待か、パートナー向けのコラボレーターアカウントで渡します。BASE は「スタッフ権限管理 App」でスタッフごとにメニュー単位の権限を付けられます。どちらもオーナーの ID は渡しません。 - [誤投稿・誤設定のあとに原因を追える運用と追えない運用](/guides/agency-accounts/tracing-misposts): 報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。 - [運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access): クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。 - [権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission): アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。 - [X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](/guides/agency-accounts/x-tiktok-business-account-access): X は広告アカウントの権限(ロール)と、投稿や DM を任せる委任機能(X アカウント権限の付与)を別々に付けます。TikTok はビジネスセンターにメンバーかパートナーとして招きます。どちらもパスワードは渡しません。 ## よくある質問 **クライアントのパスワードを担当者に教えずに運用できますか** 媒体に権限付与の仕組みがあれば、担当者を招待する形で教えずに済みます。仕組みがない媒体や、クライアント側の設定を変えられない場合は、共有 ID か、パスワードを担当者に見せないアクセス管理ツールが選択肢になります。 **共有 ID で運用すると何が困りますか** 媒体の記録が ID 単位になり、誰が操作したかを担当者まで絞れません。担当交代のたびにクライアントにパスワード変更を頼み、共有している全員に配り直す作業も残ります。 **担当者が辞めたとき、まず何をしますか** その人が使っていたアカウントを一覧で確認し、権限付与なら権限を削除し、共有 ID ならクライアントに変更を頼み、アクセス管理ツールならその担当者の利用を止めます。一覧がないと漏れが分かりません。 **運用代行会社にも個人情報保護法の義務がありますか** 個人データを扱えば、運用代行会社自身が 23 条の安全管理措置(個人データを守る対策)を負い、加えて委託元の監督(25 条)に応える立場になります。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify は、権限付与ができない媒体や、所有者の ID でしかできない操作で使います。運用代行会社の管理者が預かった ID とパスワードを登録し、担当者はパスワードを見ずにログインします。利用は担当者ごとに記録され、担当交代時は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 更新日: 2026-10-14 運用代行会社がクライアントに示すアカウントの取り決めは、読む人の違う 3 つの文書に分けると書きやすくなります。誰でも読める基本方針、社内で守る規程(社内のルールを書いた文書)、クライアントごとに渡す説明書です。[チェックシートへの回答](/guides/agency-accounts/answering-security-questionnaires)も[契約の条項](/guides/agency-accounts/account-clauses-for-service-providers)も、この 3 つに決まりが書いてあれば、そこから写せます。 ## 3 つの文書に分ける理由 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、情報セキュリティ基本方針を、関係者に取り組みを表明する文書と位置づけています。簡潔に書き、従業員や顧客などに知らせるよう勧めています。IPA の SECURITY ACTION(中小企業が対策を自ら宣言する制度)でも、「二つ星」には基本方針の外部への公開が含まれます。 同じガイドラインの付録 5 は、規程のサンプル(以下、サンプル)です。委託先を評価する基準の候補の一つに、「情報セキュリティに関する方針を公開している」を挙げています。このサンプルで規程を作ったクライアントは、委託先の公開した方針を確かめることがあります。 一方で、アカウントの細かな扱いは公開しないのが無難です。目安は個人情報保護委員会のガイドライン(通則編)3-8-1 です。対象は、会社が自分で開示や訂正に応じる個人データ(保有個人データ)です。その守り方を、データで特定される人(本人)が知れる状態にしておくよう求めています。ただし、知られると守りに支障が出るおそれのあるものは除いてよいとし、例に「アクセス制御の範囲、アクセス者の認証手法等」を挙げています。アクセス制御で担当者と扱う範囲を限っていることは、知らせる内容の例に入っています。 預かったアカウントに、この項がそのままかかるとは限りません。委託された個人データが誰の保有個人データに当たるかは、契約などの実態で決まるからです。それでも、仕組みがあることは示し、誰がどこに入れるかと、入る人をどう確かめるかは伏せる、という線は使えます。細かな決まりは規程に置き、クライアントにはそのクライアントの分だけを説明書で渡します。 | 文書 | 読む人 | アカウントについて書くこと | | --- | --- | --- | | 基本方針 | 誰でも | 預かった情報を守ることと、担当者を限って使わせていること | | 規程 | 従業員と社外の作業者 | 預かったアカウントを誰にどう使わせるかの決まり | | 説明書 | そのクライアントだけ | そのクライアントのアカウントごとの扱い | ## 基本方針に書くこと IPA の基本方針のサンプル(付録 2)は、守る対象を「お客様からお預かりした」情報資産と「当社の」情報資産から選ぶ形です。運用代行会社なら、「お客様からお預かりした」を残すのが実態に合います。 個人情報保護委員会のガイドライン(通則編)の別添は、個人データの扱いについての基本方針を定めることを「重要である」としています。定める項目の例として、「事業者の名称」「関係法令・ガイドライン等の遵守」「安全管理措置に関する事項」「質問及び苦情処理の窓口」などを挙げています。媒体(広告や SNS などのサービス)の名前や担当者の人数は、どちらの基本方針にも書かないのが無難です。 ## 規程のサンプルを、預かったアカウント向けに書き換える サンプルは、色をつけた部分を自社の事情に合わせて直して使う文書です。[アカウントの項目全体](/guides/compliance/ipa-sme-guideline-accounts)は別の記事にまとめています。ただし、どれも自社で ID を出して消せる前提です。預かったアカウントは持ち主がクライアントなので、そのままでは守れない決まりが主に 4 か所あります。 ### 1 人 1 アカウントと共有の禁止(組織的対策 6.2.1) サンプルは、アカウントを利用者 1 名につき 1 つ出し、複数人での共有を禁じています。そのうえで括弧書きで「やむを得ず共有IDが必要な場合は、共有IDを利用したユーザーを特定できるようにする」としています。預かったアカウントには、[権限付与](/guides/agency-accounts/what-is-delegated-permission)の仕組みがない媒体や、所有者の ID でしかできない操作があります。そこで、この括弧書きを本文の決まりにして、条件を書き足します。権限付与がある媒体ではそれを使い、共有で預かるのはそれ以外に限ります。共有の ID は、アカウントごとに使える人を名簿に書き、誰がいつ使ったかを記録します。媒体の規約やヘルプが共有を避けるよう求めていないかを、預かる前に確かめることも加えます。 ### 不要になったアカウントの削除(組織的対策 6.4) サンプルは、アカウントが不要になったら、その翌日までに削除か無効化をするとしています(期限は自社で決める部分です)。預かったアカウントでは、運用代行会社が自分では止められない場合があります。クライアントしか削除できない媒体での権限の削除や、共有の ID のパスワード変更は、クライアントに頼むことになるからです。アクセス管理ツールなら、利用の停止は自社でできます。書き換えでは、自社が行うこと(社内での利用をやめ、クライアントに依頼する)と期限を書きます。クライアントの作業が終わった日も記録します。 ### 退職のときの返還(人的対策 3) サンプルは、退職する従業員に、資料や機器と並べて「アクセス権(ID及び鍵)」も返させ、チェックリストで漏れを確かめるとしています。共有の ID のパスワードはその人が覚えているので、返してもらえません。退職のチェックリストには、その人が使えたクライアントのアカウントを並べます。そのうえで、預かり方ごとに止める作業(権限の削除、パスワード変更の依頼、アクセス管理ツールでの利用停止)を項目にします。担当を外れる異動でも同じ一覧を使います。 ### 従業員以外の作業者(組織的対策 6.6) サンプルは、従業員以外の人にアカウントを出すときは、承認を得たうえで秘密保持契約を結ぶとしています。在宅のフリーランスなどに使わせると、クライアントから見て再委託に当たることがあります。再委託とは、任された仕事をさらに別の人に任せることです。サンプルの委託管理の章(8.5)も、再委託には事前に書面で報告を受け、責任者が承認してから認めるとしています。規程には、秘密保持契約に加えて、クライアントに知らせて承諾を得る手続きを書き足します。 ## クライアントごとに渡す説明書に書くこと 説明書は、規程の決まりと契約の条項を、そのクライアントのアカウント 1 つずつに当てはめた結果を書く文書です。アカウント 1 つごとに、次の 5 つを書きます。 1. 媒体とアカウントの名前、預かり方(権限付与・共有の ID・アクセス管理ツールのどれか)。預かり方で、残る記録と交代時の作業が変わります。 2. 使える人。共有の ID なら、パスワードを知っている人の範囲も書きます。媒体の画面からは、誰が知っているかが分からないからです。 3. 誰がいつ使ったかの残し方(媒体の履歴か、社内の作業記録か)。誤投稿などのときに出せるものがここで決まります。 4. 担当交代と契約終了のときに、自社が行うことと、クライアントに頼むことと、その期限。クライアントの作業が抜けると、辞めた人が入れる状態が残るからです。 5. 不正な利用に気づいたときの連絡先。 各行には、もとにした規程の項目を添えます。あとで確かめるときに、その行がどの決まりに基づくかを、クライアントが自分で追えるようにするためです。 サンプルどおりに規程を作ったクライアントは、委託先を年 1 回以上評価します。契約終了時には、渡した情報とアクセス権(アカウントを使える状態)の回収か破棄を確かめます。確認リストには、ユーザー ID の発行・変更・削除の手続、パスワードの管理のルール、アクセス権の管理のルールを定めているかを問う項目もあります。答えは規程の項目で示し、説明書の 2 と 4 の行は、その規程どおりに運用している例として添えられます。 説明書は、担当者が替わったときと、預かり方を変えたときに、改訂日を入れて直します。ほかのクライアントの行は入れません。 この記事は法的助言ではありません。規程や説明書の文言は、必要に応じて弁護士の確認を受けてください。 ## よくある質問 **基本方針にアカウントの扱いを書くべきですか** 預かった情報を守ることと、担当者を限って使わせていることまでにとどめます。誰がどのアカウントに入れ、入る人をどう確かめているかは、知られると守りが弱くなるおそれがあるので、社内の規程とクライアントごとの説明書に書きます。 **IPA の規程のサンプルはそのまま使えますか** 自社で ID を出して消せる前提の決まりがあり、預かったアカウントには合いません。共有の禁止、不要になったときの削除、退職時の返還、従業員以外の作業者の 4 か所を、クライアントに頼む作業を含めて書き換えます。 **共有の ID は規程で禁止すべきですか** サンプルも、やむを得ない場合は使った人を特定できるようにすることを条件に認めています。権限付与がある媒体はそれを使い、残る共有の ID は使える人の名簿と利用の記録を条件にします。 **クライアントに渡す説明書はいつ直しますか** 担当者が替わったときと、預かり方を変えたときです。クライアントは委託の後も対策を確かめることがあるので、改訂日と、規程のどの項目に基づくかを書き添えておきます。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」付録 2 情報セキュリティ基本方針(サンプル)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_2.docx) - [IPA「中小企業の情報セキュリティ対策ガイドライン」付録 5 情報セキュリティ関連規程(サンプル)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 規程に書いた停止の期限は、共有の ID で預かるアカウントでは自社だけでは守れません。クライアントがパスワードを変えるまで、外れた人も入れるからです。導入時にクライアントと相談してパスワードを変え、Junify だけが持てば、担当者は知らないまま入ります。外れる人は割り当て(使ってよい人の指定)を自社で外した時点で入れなくなり、説明書の担当交代の行も自社の作業と期限で書けます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 - [運用代行会社がクライアントとの契約に入れておくアカウントの条項](/guides/agency-accounts/account-clauses-for-service-providers): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 --- # Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 更新日: 2026-10-14 Qoo10 では、店舗の販売管理画面(QSM)にサブ ID という仕組みがあり、担当者ごとに使える画面を分けられます。ただし Qoo10 のマニュアルは、これを店舗の ID を共有する人のための仕組みとして説明しています。au PAY マーケットでは、担当者を分ける方法を公開資料で確かめられません。管理画面のマニュアルは、ログインしないと読めません。そして、どちらのモールの規約も、ID とパスワードを第三者に使わせることを禁じています。どちらのモールでも、使い始める前にクライアントからモールに確かめてもらいます。楽天市場と Yahoo! ショッピングの仕組みは[楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](/guides/agency-accounts/ec-mall-store-admin-access)にまとめています。 ## 2 つのモールの規約が ID について定めていること 規約は、出店者(クライアント)とモールの間の約束です。運用代行会社の担当者は、出店者から見ると社外の人に当たります。出店者が ID について何を求められているかを、2 つのモールで並べます。 | | Qoo10 | au PAY マーケット | | --- | --- | --- | | ID とパスワードを第三者に使わせること | 禁止(会員規約 18 条 11 号) | 禁止(出店店舗規約 5 条 2 項) | | ID とパスワードで行われた操作 | 会員が行ったものとみなす(会員規約 3 条 2 項) | すべて会員によるものとみなす(5 条 4 項) | | パスワードの変更 | 定期的に変えるなどして秘密を守る責任(会員規約 3 条 1 項) | 定期的に変える義務(5 条 6 項) | | 業務の委託 | 委託を認める定めは見当たらない | 自らの責任で委託できる(21 条 1 項) | Qoo10 の出店者規約は、自らが会員規約の一部を構成すると定めています(1 条)。そのため、出店者にも会員規約の禁止事項が当てはまります。会員規約 18 条 11 号が禁じているのは、ID やパスワードを第三者に「貸与もしくは譲渡し、または第三者と共に使用する行為」です。出店者規約 17 条 4 項は、出店者が ID やパスワードを他人に提供して生じた被害について、Qoo10 は責任を負わないとしています。 au PAY マーケットの出店店舗規約は、21 条 1 項で業務の委託を認めています。委託先の行為には、出店者が自分で行った場合と同じ責任を負います。一方で 5 条 2 項は、ID とパスワードを第三者に利用させることを禁じています。5 条 3 項は、ログインしたままの端末を第三者に使わせることも禁じています。運用代行会社がクライアントの ID とパスワードを受け取って使う形は、5 条 2 項の文面に当たりうる使い方です。21 条 1 項の委託との関係は規約に書かれていないので、使う前にクライアントからモールに確かめてもらいます。 ## Qoo10 の QSM でサブ ID を使う QSM は、Qoo10 の出店者向けの販売管理画面です。担当者を分ける仕組みについて、Qoo10 大学(Qoo10 の出店者向け学習サイト)の用語集は 2 つの語を挙げています。共有ユーザーの権限は、担当者が複数いる場合や外部の業者に委託する場合に、使える画面を限るための権限です。サブ ID は、使える画面を限るときに設定する ID です。 設定の手順は、Qoo10 が公開している QSM のマニュアル(基本情報編)にあります。2018 年ごろの画面を載せた版なので、いまの画面とは表記が違う可能性があります。マニュアルの説明を順に並べると、次のようになります。 1. 「QSMIDを共有する全てのユーザー」を、ユーザー登録のボタンから登録する 2. ユーザーごとにサブ ID を作り、使える画面(メニュー)を選ぶ 3. 共有ユーザーは、サインインのときにサブ ID の確認を受け、許された画面だけを使う 4. 店舗の ID(メイン ID)で入る人は、すべての画面を使える この仕組みそのものを使うか止めるかも、設定画面で切り替えられます。 使う場面の例として、マニュアルは 2 つを挙げています。精算管理の画面を特定の人にだけ見せる場合と、配送管理を配送業者に任せる場合です。サブ ID の一覧には、氏名・電話番号・メモと並んで、最後にログインした日(Last Login Date)の列があります。登録の欄には、追加・修正・削除のボタンがあります。 ## サブ ID で分けても残る共有 マニュアルの説明では、サブ ID は店舗の QSM の ID を共有する人に向けた仕組みです。共有ユーザーもまず店舗の ID で入り、そのうえでサブ ID の確認を受ける形と読めます。そうであれば、担当者ごとに画面を分けても、店舗の ID とパスワードは担当者全員が知っていることになります。サブ ID の確認がどのような手順で行われるかは、マニュアルには書かれていません。 この仕組みは、用語集が外部の業者への委託を例に挙げているとおり、社外の人が使う場面も想定しています。しかし会員規約 18 条 11 号は、ID を第三者と共に使うことを禁じています。サブ ID を使った共有がこの禁止に当たるかどうかを、Qoo10 の公開資料は説明していません。クライアントから Qoo10 に確かめてもらい、その答えを記録に残しておく形が考えられます。 Qoo10 に確かめたうえでサブ ID で共有している場合、担当者が外れるときは、クライアントにその人のサブ ID を削除してもらいます。ただし、店舗の ID とパスワードを知っている人がサブ ID なしで入れるのかどうかは、マニュアルからは分かりません。その人がパスワードを知っていた以上、パスワードを変えない限り、入れない状態だとは言い切れません。そのため、パスワードの変更もクライアントに頼むことになり、残る担当者には新しいパスワードを伝え直す手間が出ます。 ## au PAY マーケットで確かめること au PAY マーケットの店舗管理画面(Wow! manager)は、ログイン画面で ID の欄を「ログインID(メールアドレス)」と表示しています。担当者ごとにログイン ID を作れるか、作れるなら使える画面を分けられるかは、公開されている資料には見当たりません。管理画面のマニュアルと FAQ(店舗運営ガイド)は、ログインしないと開けません。 そのため、確かめる作業はクライアントの側から始めます。クライアントに店舗運営ガイドを見てもらうか、モールに問い合わせてもらい、次の 3 点の答えを得ます。 1. 担当者ごとにログイン ID を作れるか。作れれば、クライアントの ID を第三者に利用させる形をとらずに済むと読めます。 2. 担当者ごとに使える画面を分けられるか。受注情報(購入者の氏名・住所)を見る必要のない担当者から、その画面を外せます。 3. 委託先の担当者がクライアントの ID で入る形を、規約上どう扱うか。21 条 1 項で委託が認められていても、ID の扱いは別の問題です。 出店店舗規約は、出店者に個人情報の管理責任者を置くことも求めています。モールが管理状況の報告を求めたら、すぐに報告しなければなりません(16 条 8 項)。どの担当者がどの ID で入っているかの一覧は、この報告の材料にもなります。 ## 外れる人が出た日に頼むこと どちらのモールでも、担当者を外す操作はクライアントの側で行います。運用代行会社の側では、担当者ごとに 1 行の一覧を持っておきます。列は、クライアント・モール・使っている ID(サブ ID か店舗の ID か)・店舗のパスワードを知っているか、です。この一覧があれば、外れる人が出た日に、サブ ID の削除だけを頼めばよいのか、パスワードの変更まで頼むのかがすぐに分かります。交代の日の手順は[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にまとめています。 ## よくある質問 **Qoo10 で担当者ごとにログインを分けられますか** QSM のサブ ID で、担当者ごとに使える画面を分けられます。ただしマニュアルは、店舗の QSM の ID を共有する人を登録する仕組みとして説明しています。 **Qoo10 の規約は ID の共有をどう扱っていますか** 会員規約 18 条 11 号が、ID やパスワードを第三者に貸すこと・譲ること・第三者と共に使うことを禁じています。出店者規約は会員規約の一部なので、出店者にも当てはまります。 **au PAY マーケットのログイン情報を代行会社に渡してよいですか** 出店店舗規約 5 条 2 項は、ID とパスワードを第三者に利用させることを禁じています。委託先がクライアントの ID で入る形はこれに当たりうるので、使う前にクライアントからモールに確かめます。 **Qoo10 の担当者が外れたら何を頼みますか** サブ ID で共有している店舗なら、その人のサブ ID の削除を頼みます。店舗のパスワードも知っていた人なら、その変更も頼みます。共有の形は、会員規約 18 条 11 号との関係を Qoo10 に確かめてから使います。 ## 参考資料 - [Qoo10(イーベイジャパン)「会員規約」](https://www.qoo10.jp/gmkt.inc/Company/UserAgreement.aspx) - [Qoo10(イーベイジャパン)「出店者規約」](https://www.qoo10.jp/gmkt.inc/Company/UserAgreement_seller.aspx) - [Qoo10大学「QSM(販売管理ツール)用語集」](https://article-university.qoo10.jp/entry/27) - [Qoo10「J*QSM Manual 基本情報」(3-2. 管理者(共有ユーザー)権限の設定方法)](http://doc.image-qoo10.jp/sqm/JP/Manual_information_JP_Ver.1.pdf) - [au PAY マーケット「会員規約(出店店舗向け)」(au PAY マーケット出店店舗規約)](https://wowma.shop/kiyaku.html) - [au PAY マーケット「Wow! manager ログイン」](https://manager.wowma.jp/wmshopclient/authclient/login) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Qoo10 に確かめてサブ ID で店舗の ID を共有している店舗では、担当者が外れるたびに、サブ ID の削除とパスワードの変更をクライアントに頼み、残る全員に伝え直します。Junify では導入時にクライアントと相談してパスワードを変え、Junify だけが持って入力します。外れる人の分は、サブ ID の削除を頼み、割り当て(使ってよい人の指定)を外すだけです。誰がいつ入ったかも残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 - [運用代行会社がクライアントとの契約に入れておくアカウントの条項](/guides/agency-accounts/account-clauses-for-service-providers): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 --- # SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 更新日: 2026-10-14 予約投稿や分析のツールは、複数の SNS の投稿をまとめて予約し、数字を集計するサービスです(SocialDog や Buffer など)。これらは SNS の側で「このツールに操作を許す」という許可を受けて動きます。この許可を誰が出したかで、担当者が外れたときに外すものが変わります。以下、予約投稿ツールと呼びます。 ## 連携は誰の権限で成り立つか 予約投稿ツールに SNS をつなぐ人は、開いた SNS の画面でログインし、連携を許可します(SocialDog のヘルプの手順)。許可を出すのが誰のアカウントかは、媒体とつなぎ方で分かれます。 | 媒体とつなぎ方 | 連携を許可するアカウント | 連携を止める場所 | | --- | --- | --- | | Facebook ページ | ページの全権限を持つ人の個人の Facebook | その人の Facebook の「ビジネス連携」 | | Instagram(Facebook ページ経由) | 同上 | 同上 | | Instagram(Instagram のログイン) | クライアントの Instagram そのもの | 予約投稿ツールの側 | | X | クライアントの X そのもの | X の設定の「アプリとセッション」 | | TikTok | クライアントの TikTok そのもの | 予約投稿ツールの側 | | LINE 公式アカウント | 人ではなく、管理者が発行する連携用の文字列 | 文字列の取り消し・再発行 | Instagram と TikTok の側で連携を外す手順は、取得できた公式資料では確かめられませんでした。 Facebook ページと、ページ経由でつなぐ Instagram では、つなぐ人にページの全権限が要ります。Buffer のヘルプは、ページの管理者で「Full Control」(全権限)を持つことを連携の条件にしています。Facebook ヘルプによれば、全権限を持つ人は管理者と同じ許可を持ち、ほかの人をページから外したり、ページそのものを削除したりできます。許可はつないだ人の Facebook アカウントに結びつき、その人の「ビジネス連携」に並びます。 Instagram を Instagram のログインでつなぐ方法と、X・TikTok では、許可を出すのはクライアントのアカウントそのものです。つなぐ操作にはクライアントの ID とパスワードが要ります。X の開発者向け資料では、連携を続ける許可を受けたツールは、本人が取り消すまでつながります。TikTok の開発者向け資料では、ツールが受け取る更新用の情報は、発行から 365 日有効です。その間、ツールは本人の同意をとり直さずに許可を更新できます。パスワードを知る人が外れても、連携は残ります。 LINE 公式アカウントは、人のログインではなく「チャネルアクセストークン」で動きます。ツールが使ってよいかを確かめるための、連携用の文字列です。連携の入口(Messaging API)を有効にできるのは、LINE 公式アカウントの「管理者」権限を持つ人だけです。この文字列のうち長期のものには、期限がありません。LINE Developers の資料は、この文字列が漏れると、第三者が友だち全員にメッセージを送れると注意しています。 ## つなぐ操作は誰に頼むか Facebook ページ経由の連携は、クライアント側で全権限を持つ人に頼みます。担当者に全権限を渡すと、ページの削除や管理者の付け外しまでできる人が増えるからです。Instagram のログイン・X・TikTok も、クライアントの担当者に自分でログインして許可してもらいます。自社の担当者は、パスワードを知らずに済みます。Instagram の利用規約は、ほかの利用者のユーザー名やパスワードを求めたり受け取ったりすることを禁じています。X の投稿と DM は、委任(他の人に投稿などを任せる機能)を使えば、パスワードを渡さずに任せられます([X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](/guides/agency-accounts/x-tiktok-business-account-access))。 LINE は、連携の入口の有効化と文字列の発行を、クライアント側に行ってもらいます。文字列を発行する画面は LINE Developers(連携の設定を行う開発者向けの管理画面)の「Messaging API設定」です。この画面を開けるのは、チャネルの Admin 権限を持つ人です。 予約投稿ツールの持ち方も決めます。Buffer では、利用者一人ひとりが自分専用の組織(ツール上のチームの単位)を持ち、そこにつないだ SNS は本人しか使えません。1 つの SNS アカウントは、1 つの組織にしかつなげません。担当者が自分の組織につなぐと、会社のチームからはつなげなくなります。SocialDog にも同じ決まりがあります。担当者は会社のチームに招待してもらい、自分のログインで入る形にします。招待は、Buffer では Team プラン、SocialDog では Business 以上のプランの機能です。ツールのログインを複数人で使い回すと、誰が何を予約したかが分からなくなるので避けます。 ## 担当が外れたときに確かめる 3 か所 1 つ目は予約投稿ツールのメンバーです。会社のチームからその人を外します。Buffer では、外した人が作った予約投稿や下書きは消えずに残るので、中身と引き継ぎ先を確かめます。その人がチームのオーナーなら、SocialDog では本人に、オーナーを別の人へ譲ってもらいます。 2 つ目は媒体の側の権限です。Facebook ページのタスクや [LINE 公式アカウントのメンバー](/guides/agency-accounts/line-official-account-permissions)など、その人に付けていた権限を外します。LINE で連携の設定を担当していた人は、LINE Developers にも登録されていることがあります。ここでの権限は LINE 公式アカウントのメンバーとは別で、プロバイダー(チャネルをまとめる単位)とチャネルのそれぞれから外します。 3 つ目は連携そのものです。その人の Facebook の許可でつないでいた連携は、その人のアカウントに結びついています。権限を外す前に、クライアント側の全権限を持つ人につなぎ直してもらいます。権限を外したあと既存の連携がどうなるかは、公式資料に書かれていないためです。Instagram のログイン・X・TikTok で、その人がクライアントのパスワードを知っていたなら、クライアントに変更を頼みます。SocialDog のヘルプによれば、SNS のパスワードを変えると再連携が要る場合があります。変更後は連携が切れていないかを確かめます。LINE で、その人が文字列を見られる立場だったなら、再発行します。長期のものは 1 つの LINE 公式アカウントに 1 つしか持てず、再発行すると前のものは使えなくなります。同じ文字列を使うほかのツールも、新しい文字列に切り替えます。 Buffer では、つなぐ SNS アカウントに「Unavailable」と出たら、別の組織につながっています。ヘルプは、探す先に過去の担当者を挙げています。担当交代の作業全体は[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にまとめています。 ## 契約が終わったとき 契約が終わったら、自社のチームからクライアントの SNS アカウントを削除し、クライアントにも連携を止めてもらいます。予約投稿ツールから SNS アカウントを削除すると、SocialDog では投稿予定と下書きが、Buffer では予約投稿と分析の数字が消えます。クライアントに渡すデータは先に書き出しておきます。 Facebook では、連携を許可した人が、自分の Facebook の「ビジネス連携」から予約投稿ツールを削除します。削除したツールは、ページや広告を管理できなくなります。ただし Facebook ヘルプによれば、それまでに共有された情報はツールの側に残っている場合があります。X では、クライアントが「アプリとセッション」からツールのアクセス権を取り消します。LINE では、クライアントの管理者が文字列を再発行するか取り消します。 ## よくある質問 **予約投稿ツールへの連携は誰が行えばよいですか** クライアント側で権限を持つ人です。Facebook ページ経由の連携にはページの全権限が要り、全権限はページの削除や管理者の付け外しまでできるため、連携のためだけに担当者へ渡すのは避けたいところです。 **担当者をツールから外すと予約投稿は消えますか** Buffer では、外した人が作った予約投稿や下書きはそのまま残ります。消えるのは、ツールから SNS アカウント自体を削除したときで、SocialDog では投稿予定と下書きが削除されます。 **予約投稿ツールのログインを担当者で共有してよいですか** 共有せず、メンバーとして一人ずつ招待します。Buffer のヘルプも招待をいちばん安全な渡し方とし、パスワードを共有する必要はないと説明しています。共有すると誰が予約したかが分からなくなります。 **LINE の連携ツールをやめたら何をしますか** ツールに渡した「チャネルアクセストークン」を取り消すか再発行します。長期のものは期限がなく、1 つしか持てません。再発行すると前のものは使えなくなるので、同じものを使うほかのツールも切り替えます。 ## 参考資料 - [Facebook ヘルプセンター「Facebookでビジネス連携のプライバシーと設定を編集または削除するにはどうすればよいですか。」](https://www.facebook.com/help/405094243235242) - [Facebook ヘルプセンター「Facebookページへのアクセスについて」](https://www.facebook.com/help/289207354498410) - [X Developer Platform「OAuth 2.0 Authorization Code Flow with PKCE」](https://docs.x.com/resources/fundamentals/authentication/oauth-2-0/authorization-code) - [X ヘルプセンター「Xのサードパーティアプリとログインセッションへの権限の付与および取り消し」](https://help.x.com/ja/managing-your-account/connect-or-revoke-access-to-third-party-apps) - [Instagram ヘルプセンター「利用規約」](https://help.instagram.com/581066165581870) - [TikTok for Developers「User Access Token Management」](https://developers.tiktok.com/doc/oauth-user-access-token-management) - [LINEヤフー for Business「LINE公式アカウント(LINE Official Account Manager)Messaging APIマニュアル」](https://www.lycbiz.com/jp/manual/OfficialAccountManager/account-settings_messaging_api/) - [LINE Developers「LINE公式アカウントで複数のツールからMessaging APIを利用する際に確認したいこと」](https://developers.line.biz/ja/tips/2026/07/23/using-multiple-api-tools/) - [LINE Developers「チャネルアクセストークン」](https://developers.line.biz/ja/docs/basics/channel-access-token/) - [LINE Developers「権限を管理する」](https://developers.line.biz/ja/docs/line-developers-console/managing-roles/) - [SocialDog ヘルプ「チームのSNSアカウントを管理する」](https://help.social-dog.net/ja/settings/connect_sns/manage_team_sns_accounts/) - [SocialDog ヘルプ「チームメンバーを管理する」](https://help.social-dog.net/ja/settings/team/manage_team_members/) - [Buffer Help Center「Troubleshooting Facebook connections」](https://support.buffer.com/articles/troubleshooting-facebook-connections-9RFdJRZF2s) - [Buffer Help Center「Connecting your Instagram account to Buffer」](https://support.buffer.com/articles/connecting-your-instagram-account-to-buffer-n9Ad6veXsu) - [Buffer Help Center「Adding users and setting up permissions」](https://support.buffer.com/articles/adding-users-and-setting-up-permissions-ixjiLpe2fd) - [Buffer Help Center「Removing a user from your organization」](https://support.buffer.com/articles/removing-a-user-from-your-organization-m2wOKYJPtf) - [Buffer Help Center「“Unavailable” channels are likely connected to another Buffer organization」](https://support.buffer.com/articles/unavailable-channels-are-likely-connected-to-another-buffer-organization-rzvDUV7uBX) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** X・TikTok で担当者ごとの権限を出してもらえず、ID とパスワードで入るクライアントのアカウントでは、知る人が外れるたび変更を頼む作業が続きます。Junify では導入時にクライアントと相談してパスワードを変え、Junify だけが持ちます。担当者は Junify から開いた画面でパスワードを見ずに入り、誰がいつ入ったかが残ります。割り当て(使ってよい人の指定)を外せば、その人は入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [運用代行会社がクライアントとの契約に入れておくアカウントの条項](/guides/agency-accounts/account-clauses-for-service-providers): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 --- # 運用代行会社がクライアントとの契約に入れておくアカウントの条項 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。 更新日: 2026-10-13 5 つの条項はどれも、運用代行会社が自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書くためのものです。クライアント(任せる側)が入れる条項は[委託契約に入れるアカウント条項の要点](/guides/outsourcing-access/contract-clauses-for-accounts)にまとめています。 ## 任される側が自分の案を持っておく理由 個人データの取扱いを任せるとき、クライアントは個人情報保護法 25 条で委託先を監督する立場になります。任される側については、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版に原則があります。原則 2 は「受託している場合には、委託元の要求に応じる必要があります」としています。 それでも運用代行会社が自分の案を持っておくのは、自社だけでは守れない約束を、相手の案のまま引き受けないためです。[権限付与](/guides/agency-accounts/what-is-delegated-permission)は持ち主が招待する仕組みです。媒体(広告や SNS などのサービス)によっては、代理店側の管理アカウントで担当者を付け外しできます。Google 広告の MCC がその例です。そうした形がない媒体では、担当者を加える操作も外す操作もクライアント側で行います。「交代の当日に入れなくする」と約束しても、クライアントの操作が遅れれば守れません。 契約に書かなくても負う義務もあります。投稿や入稿のように、成果物の完成ではなく作業そのものを任せる形なら、民法 656 条の準委任に当たると読めます。準委任は、契約を結ぶといった法律行為ではない作業を任せる契約で、委任の規定が当てはめられます。そのため 645 条により、任された側はクライアントの請求があればいつでも作業の状況を報告します。終わったあとは、遅れずに経過と結果を報告します。請求は「いつでも」来るので、何を記録するかを決めておかないと、担当者ごとの作業をあとから集め直すことになります。 一方で、引き受ける対策の水準には法律上の目安があります。個人情報保護委員会のガイドライン(通則編)は 3-4-4 の注(※2)で、法律上は「委託先は、法第 23 条が求める水準の安全管理措置を講じれば足りると解される」としています。クライアントの社内規程と同じ対策を求められても、それは法律の求めではなく合意で決まる話です。実施できるかを確かめてから同意します。 ## 5 つの条項と文例 文例の「委託者」はクライアント、「受託者」は運用代行会社です。 ### アカウントの渡し方とクライアント側の協力 > 委託者は、各媒体の権限付与の機能で、受託者の管理アカウントまたは受託者が届け出た担当者に、業務に必要な権限を付与する。権限付与の機能がない媒体に限り、委託者は ID とパスワードを、委託者が定める方法で受託者に通知する。受託者の管理アカウントで行えない担当者の追加または削除は、受託者の依頼を受けて、委託者が◯営業日以内に行う。 前半は、渡し方を先に決めておくための文です。権限付与ができる媒体では、担当者は自分のユーザーで入り、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。媒体によっては、ヘルプでログイン情報を人に教えないよう求めています。YouTube ヘルプは「パスワードやログイン情報を誰とも共有しないでください」と書き、チャンネルの権限で承認したアカウントから入るよう求めています。こうした媒体で ID とパスワードを受け取る約束は避けたいところです。後半の期限は、運用代行会社の側で付け外しできない媒体のためのものです。クライアントの操作待ちで追加や削除が止まっても、その遅れが運用代行会社の落ち度にならないようにします。 ### 使う担当者の範囲と再委託 > 受託者は、委託者のアカウントを使う担当者の名簿を委託者に届け出て、変更があれば◯日以内に更新する。受託者の従業員でない者(業務委託の個人を含む)に使わせるときは、事前に委託者の書面による承諾を得る。 名簿は、クライアントにとっては取扱状況をつかむ材料になり、運用代行会社にとっては誰に使わせてよいかの合意になります。社外のフリーランスに作業を任せるのは、クライアントから見ると再委託(任された仕事をさらに別の人に任せること)です。ガイドライン 3-4-4(3) は、再委託について、委託元が事前に報告を受けるか承認することを望ましいとしています。業務の一部をそのまま任せるなら、民法 644 条の 2 の制限にも当たると読めます。この条は、任された側が別の人に任せられるのを、許しを得たときか、やむを得ない事情があるときに限っています。承諾の手続きを書いておけば、忙しい時期に外部の人を入れる前に何をすればよいかがはっきりします。 ### 記録と報告の範囲 > 受託者は、担当者ごとのアカウントの使用日時と作業内容を記録し、契約終了後◯年間保存する。委託者の求めがあるときは、受託者が保有する記録の範囲で、◯営業日以内に提出する。 「受託者が保有する記録の範囲で」と書くのは、出せる記録が渡し方で変わるからです。権限付与なら、媒体の履歴に担当者ごとの操作が残ります(媒体が履歴を残す範囲で)。共有 ID では媒体の記録は ID 単位なので、誰が操作したかは、運用代行会社が別に付けた作業記録に頼ることになります。クライアントの社員も同じ ID で入っていると、その操作と運用代行会社の操作を記録から分けられません。そうした ID があるなら、クライアント側でも使うかどうかと、使うときは前もって知らせることを、この条項に書き足します。 ### 事故のときの通知と協力 > 受託者は、アカウントの不正な使用、ID・パスワードの流出またはそのおそれを知ったときは、知った時から◯時間以内に委託者に通知し、調査に協力する。委託者は、自ら行ったパスワード、二段階認証、権限の変更を、受託者に速やかに知らせる。 個人データの漏えいなどで、個人情報保護委員会への報告が必要な事態があります。ガイドラインでは、その場合は原則として委託元と委託先の両方が報告の義務を負います。ただし委託先は、委託元に通知すれば報告の義務を免れます(個人情報保護法 26 条 1 項ただし書)。ガイドライン 3-5-3-5 は、この通知の「速やか」の目安を、委託先が知った時から「概ね 3～5 日以内」としています。契約の◯は、夜間や休日に誰が気づき、誰が連絡するかを決めてから、守れる数字を入れます。IPA のガイドラインも「取引先 / 外部情報サービスの管理」の項で、事故のときの通知の義務と連絡先を文書にするよう勧めています。役割と連絡の体制は、相手と合意しておくものとしています。 後半の文は、クライアントがパスワードを変えた結果、担当者が入れなくなったときに、それを乗っ取りと取り違えないためのものです。 ### 終了と担当交代のときの手続き > 契約が終了したとき、または担当者が交代したときは、受託者は対象の担当者の使用を止め(受託者の管理アカウントで行える権限の削除を含む)、保存していた ID・パスワードを消去し、消去した日を委託者に書面で報告する。委託者は、受託者の依頼を受けて、受託者の管理アカウントで行えない権限の削除と、受託者に知らせていたパスワードの変更を◯営業日以内に行う。 この条項では、運用代行会社の作業とクライアントの作業を分けて書きます。代理店側の管理アカウントで付け外しできる媒体なら、権限の削除は運用代行会社が当日に自分で行えます。そうでない媒体の権限の削除と、知らせてもらっていたパスワードの変更は、クライアントの操作です。依頼と期限を書いておかないと、辞めた担当者が入れる状態が残っても、運用代行会社からは止められません。IPA のガイドラインも「取引先 / 外部情報サービスの管理」の項で、アクセス権を回収する側に勧めています。契約終了時の回収は、責任者と期限を決めて行い、記録を残します。 契約の文言は、任せる業務と媒体に合わせて書き直したうえで、弁護士の確認を受けてください。この記事は法的助言ではありません。 ## よくある質問 **クライアントの求める対策が法律より厳しいときは** ガイドラインは、法律上は委託先の対策は個人情報保護法 23 条が求める水準で足りるとしています。それを超える対策は合意で決まるので、実施できるかを確かめてから同意します。 **個人データを扱わない運用でも条項は要りますか** 25 条の監督が及ばない業務でも、作業そのものを任せる契約なら民法の準委任と読め、求めがあれば作業の状況を報告する義務(645 条)があります。何を記録するかを決めておきます。 **フリーランスに作業させるときは何を書きますか** クライアントから見ると再委託に当たり、ガイドラインは事前の報告か承認を望ましいとしています。仕事の一部をそのまま任せるなら民法の制限にも当たると読めます。事前に書面で承諾を得る手続きを書きます。 **個人データの流出に気づいたら、いつまでに知らせますか** 委員会への報告が必要な事態なら、ガイドラインは委託元への通知の目安を知った時から概ね 3〜5 日以内とし、通知すれば委託先の報告は免除されます。それ以外は、契約で守れる期限を決めます。 **契約のひな形に ID とパスワードの通知があったら** 権限付与ができる媒体では、担当者ごとの招待に替えてもらうよう相談します。YouTube のように、ヘルプでログイン情報を誰とも共有しないよう求めている媒体もあります。 ## 参考資料 - [民法(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/129AC0000000089) - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Google 広告ヘルプ「MCC アカウントのユーザーとアクセス権を管理する」](https://support.google.com/google-ads/answer/7459700?hl=ja) - [YouTube ヘルプ「ハッキングされた YouTube チャンネルを復元する」](https://support.google.com/youtube/answer/76187?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 共有 ID のままだと、交代のたびにクライアントへパスワードの変更を頼む作業と、作業記録を求められるたびに、その日誰が入ったかを勤務表と突き合わせる作業が人の手で続きます。導入時にクライアントと相談してパスワードを変え、Junify だけが持つ形にすれば、担当者は知らないまま入れ、誰がいつ使ったかは担当者ごとに残ります。交代の日は割り当て(使ってよい人の指定)を外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Amazon セラーセントラルのユーザー権限と、運用代行会社への渡し方 ヘルプはログイン情報を誰とも共有しないよう求めています。大口出品なら、社内の担当者は「従業員の管理」から招待し、運用代行会社はサービスプロバイダーとして承認します。どちらもユーザー権限の画面から外せます。 更新日: 2026-10-13 Amazon セラーセントラルは、Amazon に出品する事業者が商品・在庫・注文を管理する画面です。ここには、主アカウントのパスワードを渡さずに他の人を入れる仕組みが 2 つあります。社内の人を入れる「従業員の管理」と、社外の事業者を入れる「サービスの管理」です。どちらも[権限付与](/guides/agency-accounts/what-is-delegated-permission)に当たります。運用代行会社がクライアントのセラーセントラルを扱うときは、どちらで入るかによって、担当交代の作業を誰がするかが変わります。 ## 主アカウントと、人を加える 2 つの方法 セラーセントラルのアカウントを登録した人は、ヘルプで「プライマリユーザー」(アカウント管理者)と呼ばれます。この記事では、この人のアカウントを主アカウントと呼びます。登録した直後は、主アカウントだけがすべての画面を使えます。他の人を加える機能(ユーザー権限)は、大口出品に登録している出品者だけが使えます。小口出品では使えません。 ヘルプは、加える相手が組織の中か外かで方法を分けています。 | | 従業員として招待 | サービスプロバイダーとして承認 | | --- | --- | --- | | ヘルプが想定する相手 | 自社の従業員・共同経営者 | 代理店・外部業者など組織の外の事業者 | | 始め方 | 出品者がメールで招待する | 代行会社が Amazon に登録し、出品者が承認する | | 期間 | 削除するまで続く | 365 日。再承認で延ばせる | | 担当者ごとの付け外し | 主アカウントか管理者が行う | 代行会社の管理者が行う | | 外し方 | 「ユーザーを削除」 | 「サービスの管理」から削除。期限切れでも外れる | ## 社内の担当者を従業員として招待する 招待は、設定メニューの「ユーザー権限」から行います。「従業員の管理」の「従業員を招待」で相手の情報を入れて送り、相手は届いたメールの手順に従います。権限は、同じ画面の「編集」から変えられます。 従業員は、権限の管理画面を開けません。ただし、主アカウントか他の管理者が、ユーザー権限のページに「表示と編集」の権限を付けると、その従業員は管理者になります。管理者は、他の従業員とサービスプロバイダーの権限を管理できます。 外すときは、主アカウントか管理者が、「従業員の管理」でその人の横のメニューから「ユーザーを削除」を選びます。 ## 運用代行会社をサービスプロバイダーとして承認する サービスプロバイダーとして入るには、代行会社の側で準備が要ります。Amazon の開発者向け資料によると、代行会社はまず、ソリューションプロバイダーポータルにアカウントを作ります。代行会社や開発会社が Amazon に登録する管理画面で、アカウントは会社で 1 つです。 ロールは、セラーセントラルのどの業務に入れるかを決める権限の種類です。代行会社は、提供するサービスの種類に応じてロールを申請し、Amazon の承認を待ちます。処理には最大 10 営業日かかります。承認前は、出品者の画面でそのロールが灰色になり、付与できません。 出品者は、代行会社から届く承認リンクを開くか、サービスプロバイダーネットワークで「今すぐ承認」を選びます。サービスプロバイダーネットワークは、出品者が代行会社を探せる Amazon の一覧です。表示されたロールを確かめ、必要なら一部を外したり、国・地域で絞ったりしてから承認します。承認すると、代行会社は 365 日間アクセスできます。代行会社がサービスプロバイダーネットワークに登録している場合は、承認のあとに依頼が作られます。代行会社がそれを承諾して、初めて有効になります。 承認のあとは、代行会社の管理者が、担当者ごとに任せるクライアントを選びます。担当者ごとに、表示のみ・表示と編集・管理の段階も付けられます。担当者は、ポータルに登録した自分のメールアドレスでセラーセントラルにログインし、任されたクライアントを選んで作業します。開発者向け資料は、代行会社の管理者が担当者の利用状況を見られるとしています。何がどれだけ残るかは書かれていません。 ## 外すとき 外し方は、誰を外すかで 3 つに分かれます。ポータルの画面名は、英語の開発者向け資料にあるものです。 1. 代行会社の担当者 1 人を、あるクライアントから外す。代行会社の管理者がポータルで「Remove from Client」(クライアントから外す)を選びます。辞めた人は「Remove User」(ユーザーを外す)で、すべてのクライアントから一度に外れます。出品者の操作は要りません。 2. 代行会社そのものを外す。主アカウントか管理者が「サービスの管理」から削除します。削除はすぐに反映され、その代行会社はすべての業務とデータを扱えなくなります。元に戻せず、再開には承認のやり直しが要ります。セラーセントラルの外で結んだ契約は、この操作では解約されません。 3. 期限で外れる。承認から 365 日が過ぎると、アクセスは自動で取り消されます。期限の前に通知が届き、期限内なら再承認で 365 日延ばせます。 代行会社の担当者を従業員として招待していた場合は、1 と 3 は当てはまらず、期限もありません。代行会社の担当者を管理者にしていない限り、代行会社の側では外せません。担当が代わるたびに、主アカウントか管理者が「ユーザーを削除」を行います。 ## 2 段階認証とパスワードの扱い セラーセントラルに入るには、2 段階認証(パスワードのあとに、登録した端末で受け取るコードを入れる確認)が必要です。コードは認証アプリ、SMS、音声通話で受け取ります。 ヘルプは、複数の人が 1 つの出品用アカウントを使うなら、人ごとに別のメールアドレスでログイン情報を作るよう勧めています。そうしないと、安全上の危険が生じ、ログインできない人が出るおそれがあるとしています。 パスワードについて、ユーザー権限のヘルプは「誰とも共有しないようにしてください」と書いています。Amazon サービスビジネスソリューション契約の 16 条は、パスワードを「いかなる第三者」にも開示しないよう定めています。例外は、「本契約に従い」アカウントを使う権限を与えた第三者です。ユーザー権限の仕組みを通さずにパスワードを渡すことがこの例外に当たるかは、ヘルプには書かれていません。出品者は、自分が加えたユーザーの行動にも、パスワードを使って行われた行動にも責任を負います(ユーザー権限のヘルプと 16 条)。 ヘルプは、事業の所有者が変わらず担当者だけが代わる場合は、アカウントにユーザーを加えられると案内しています。出品用アカウントそのものは譲渡できません。 ## 従業員もサービスプロバイダーも使えないとき 小口出品では、ユーザー権限の機能を使えません。ヘルプの仕組みで担当者を加えられるのは、大口出品の出品者だけです。 大口出品でも、サービスプロバイダーの方法は、代行会社のロールが承認されるまで使えません。その間は、出品者が自分で作業する手もあります。ヘルプは、組織の外の相手にはサービスプロバイダーの方法を当てています。外の担当者を従業員として招待することを禁じる文は見当たりません。 どちらの場合も、主アカウントのログイン情報を担当者に渡すことは、ヘルプの「誰とも共有しない」と 16 条に当たりうる使い方です。 ## よくある質問 **セラーセントラルのパスワードを代行会社に教えてよいですか** ヘルプはログイン情報を誰とも共有しないよう求めています。代行会社には、サービスプロバイダーとして承認する形が用意されています。担当者は自分のメールアドレスでログインします。 **小口出品でもユーザーを追加できますか** できません。ユーザー権限の設定と管理ができるのは、大口出品に登録している出品者だけです。 **代行会社の担当者が辞めたら出品者は何をしますか** サービスプロバイダーとして承認していれば、代行会社の管理者が自社の画面でその担当者を外せます。従業員として招待していた場合は、主アカウントか管理者がユーザーを削除します。 **代行会社のアクセスに期限はありますか** 承認から 365 日です。期限が切れると自動で外れます。期限の前なら再承認で延ばせます。切れたあとや削除したあとは、承認を最初からやり直します。 **2 段階認証のコードは担当者ごとに分かれますか** ヘルプは、使う人ごとに別のメールアドレスでログイン情報を作るよう勧めています。その場合は一人ずつ 2 段階認証を設定するので、コードも人ごとに分かれます。 ## 参考資料 - [Amazon セラーセントラル ヘルプ「ユーザー権限の設定と編集」](https://sellercentral.amazon.co.jp/help/hub/reference/external/G901?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「サービスプロバイダーにあなたのアカウントへのアクセスを承認する」](https://sellercentral.amazon.co.jp/help/hub/reference/external/GRUJCZJ74KFU96LB?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「サービスプロバイダーのアカウントアクセスを削除する」](https://sellercentral.amazon.co.jp/help/hub/reference/external/G9GR9Q4U6U5DPMKW?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「サービスプロバイダーのアカウントアクセスを再承認する」](https://sellercentral.amazon.co.jp/help/hub/reference/external/G3782ZCL2U67NSTB?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「アカウント設定に関するよくある質問」](https://sellercentral.amazon.co.jp/help/hub/reference/external/G19781?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「2段階認証」](https://sellercentral.amazon.co.jp/help/hub/reference/external/G202110760?locale=ja-JP) - [Amazon セラーセントラル ヘルプ「Amazon サービスビジネスソリューション契約」(16. パスワード・セキュリティ)](https://sellercentral.amazon.co.jp/help/hub/reference/external/G1791?locale=ja-JP) - [Amazon Selling Partner API 開発者ドキュメント「Service Provider Registration and Role Approval Process Overview」](https://developer-docs.amazon/sp-api/docs/service-provider-registration-and-role-approval-process) - [Amazon Selling Partner API 開発者ドキュメント「Manage Users in Solution Provider Portal」](https://developer-docs.amazon/sp-api/docs/manage-users-in-spp) - [Amazon Selling Partner API 開発者ドキュメント「User Permissions for Service Providers」](https://developer-docs.amazon/sp-api/docs/user-permissions-for-service-providers) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** セラーセントラルには、担当者を 1 人ずつ外す仕組みがあります(従業員の削除と、代行会社の管理者による取り外し)。それを、同じクライアントの広告や SNS、他のモールで人ごとに登録できないアカウントでも行えるようにするのが Junify です。導入時にパスワードを変えて Junify だけが持てば、担当者は見ずにログインし、交代のたびにパスワードの変更を頼む作業は割り当てを外す操作に変わります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # クライアントのアカウントの二段階認証を運用チームで受けるには 担当者ごとに招待してもらい、各自のアカウントの二段階認証で入る形に切り替えると、コードの受け渡しはなくなります。所有者のログインが残るアカウントは、受け取り先・予備のコード・使った人の記録をクライアントと決めます。 更新日: 2026-10-13 二段階認証は、パスワードのあとに、登録したスマホなどに届くコードで本人を確かめる仕組みです。クライアントのアカウントにこれが付いていると、コードは登録した端末や番号にだけ届きます。その先が 1 人のスマホだと、チームのほかの人は入るたびにその人に連絡し、コードを教えてもらいます。受け渡しを減らす方法は 2 つあります。担当者ごとに入れる形に切り替えることと、それでも残るアカウントの受け取り先をクライアントと決めることです。二段階認証の仕組みそのものは[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)で説明しています。 ## 媒体ごとの方式と、担当者ごとに入る仕組み 公式ヘルプにある方式と仕組みは次のとおりです。 | 媒体 | 二段階目の方式 | 担当者ごとに入る仕組み | | --- | --- | --- | | Google 広告 | 電話、認証アプリ、Google からの通知、セキュリティキー、SMS | アクセス権の招待 | | Facebook | セキュリティキー、認証アプリ、SMS | ページへのアクセス許可(ビジネスポートフォリオからも) | | Instagram | 認証アプリ、SMS、WhatsApp | リンクした Facebook ページからのアクセス許可 | | X | SMS(X Premium の加入者のみ)、認証アプリ、セキュリティキー | アカウント権限の付与 | | LINE 公式アカウント | メールを登録したビジネス ID は、メールに届くコード | 権限管理でのメンバー追加 | X の SMS は、Premium の加入者でも国や通信会社によって使えないことがあります。LINE 公式アカウントは、LINE アカウントでログインするときはメールのコードが要らず、LINE アプリで認証番号を入れます。ビジネスポートフォリオからの付け方は[Meta のビジネスポートフォリオで代理店に権限を付与する仕組み](/guides/agency-accounts/meta-business-portfolio-agency-access)にあります。 表の媒体にはどれも担当者が自分のアカウントで入る仕組みがあるので、コードの受け渡しが要るのは所有者のログインを使う場面だけです。 ## 担当者ごとに入る形に切り替える [権限付与](/guides/agency-accounts/what-is-delegated-permission)で担当者を招待してもらうと、コードの受け渡しはなくなります。担当者は自分のアカウントでログインし、二段階認証もその人のアカウントに付くからです。X のヘルプでは、メンバーは管理者かコントリビュータ(投稿などができる役割)として招待を受け、自分のアカウントで承諾して使います。パスワード・電話番号・ログイン認証の設定を管理できるのは所有者だけです。LINE 公式アカウントの権限設定マニュアルでは、メンバーは発行した認証用 URL から 1 人ずつ追加します。Google 広告では、招待されたユーザーはそれぞれの Google アカウントで入ります。MCC(クライアント センター)は、代理店が複数の広告アカウントをまとめて管理するためのアカウントです。Google の開発者向けの資料によると、MCC が所有するアカウントでは、MCC の管理者がそのユーザーに二段階認証を有効にするよう求められます。この所有者としての権限は、[MCC にリンクしただけでは付きません](/guides/agency-accounts/google-ads-mcc-agency-access)。 切り替えには、媒体の規約とヘルプの側からの理由もあります。Meta の利用規約(Facebook に適用)は、利用者の誓約として「自分のパスワードを共有したり、自分のFacebookアカウントに他人をアクセスさせたり」しないことを挙げています。同じ規約は、パスワードを人に求めたり集めたりすることも禁じています。Instagram の利用規約は、ほかの利用者のログイン情報やパスワードを求めたり取得したりしようとすることを禁じています。LINE ビジネス ID に適用される LINEヤフー共通利用規約は、他人にアカウントやパスワードを教えることを禁止事項に挙げています(第 1 章 15 (14))。X のヘルプは、パスワードを所有者か管理者だけが知っている状態を保つよう求めています。 Google 広告には別の事情もあります。開発者向けの資料によると、機密情報にかかわる操作の承認に、パスキー(スマホの指紋や顔の確認などでログインする方式)を求める場合があります。パスキーは端末に結び付いているので、コードのように人に伝えられません。 ## 所有者のログインが残るアカウント それでも、次の場合は所有者のログインが残ります。 - 表にない媒体で、招待の仕組みがない - 所有者にしかできない操作がある(X のログイン認証の設定など) - クライアントに招待の操作を頼めない ただし、Facebook・Instagram・LINE 公式アカウントは前の節の規約に当てはまるので、招待に切り替えるのが前提です。招待を頼めない事情があれば、クライアントと話して解消します。X もヘルプで共有を避けるよう求めているので、所有者のログインを使うのは所有者にしかできない操作に限ります。残ったアカウントでは、コードを受ける場所を次のどれかに決めます。 ### クライアントの担当者の端末で受け、その都度聞く 受け取り先を変えないので、クライアント側の設定はそのままです。その代わり、クライアントの担当者が休みの日や夜間は入れません。コードはチャットや電話で運用代行会社に渡ります。誰が頼み、誰が入力したかは、頼んだ側で書き留めないと残りません。使う回数が少ないアカウントに向く形です。 ### 運用代行会社が管理する端末や番号で受ける 受け取り先を、運用代行会社が会社として管理するスマホ、電話番号、メールアドレスに変えてもらう形です。担当者個人のスマホにしないのは、その人が辞めた日から誰もコードを受けられなくなるからです。所有者はクライアントなので、変えるかどうかはクライアントが決めます。Google 広告のヘルプによると、電話番号などの「再設定用の情報」は、変えてから Google のサービス全体に反映し終えるまで、最長で 7 日ほどかかることがあります。その間は追加の確認を求められることがあります。変更は急ぎの作業の前に済ませ、契約が終わるときに戻す手順も一緒に決めておきます。 ### 認証アプリをチームの複数台に登録する Instagram のヘルプは、1 つのアカウントに複数の端末を登録できることを、認証アプリを勧める理由に挙げています。ただし、その端末を複数人で持つことには触れていません。チームの複数人のスマホに登録すれば受け渡しはなくなりますが、どのスマホも同じコードを出すため誰が使ったかは残らず、人が抜けるたびに設定し直します。この形の問題は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)で扱っています。 どの形を選んでも、予備のコードの扱いを決めておきます。Facebook では二段階認証を設定すると、スマホが使えないときのためのログインコードを 10 個受け取れます。X では SMS で登録したあとに、予備のコードが画面に出ます。どちらも受け取り先の代わりになるので、受け取り先と同じ扱いにします。 ## クライアントと決めておくこと 所有者のログインが残るアカウントは、次の 5 点をクライアントと決めて、預かっているアカウントの一覧に書き込みます。 1. 所有者のログインを使うアカウントと、その理由。招待に切り替えられるアカウントが混ざっていないかを確かめるためです。 2. コードの受け取り先と、その端末や番号の持ち主。持ち主が辞めたり異動したりした日に、誰が受け取り先を変えるかを決めておくためです。 3. 受け取り先を変えるときの頼み方と時期。変更はクライアントの操作で、反映に日数がかかる媒体もあるためです。 4. 予備のコードの保管場所と、見られる人。 5. 誰がいつコードを使ったかの残し方。媒体の記録はアカウント単位で、運用代行会社の側で残さないと担当者まで分からないためです。 担当者が交代するときに受け取り先をどう引き継ぐかは、[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にまとめています。 ## よくある質問 **クライアントのスマホに届くコードを毎回聞いてもよいですか** Facebook・Instagram・LINE は規約が共有を禁じるので招待で入り、X は所有者だけの操作に限ります。ほかで使うのがまれなら、その形もとれます。担当者が休みの日は入れず、誰が頼んだかは自社で記録します。 **クライアントの認証アプリを自社のスマホに登録してよいですか** Facebook・Instagram・LINE は規約が共有を禁じるので招待で入り、X は所有者だけの操作に限ります。ほかはクライアントが決めます。登録した台数だけコードを出せる人が増え、誰が使ったかは残りません。 **コードの受け取り先を自社の番号に変えてもよいですか** Facebook・Instagram・LINE は規約が共有を禁じるので招待で入り、X は所有者だけの操作に限ります。ほかはクライアントが決めます。番号は再設定にも使われるので、契約が終わるときに戻す手順も決めます。 **招待で入れば、二段階認証のコードはどこに届きますか** 担当者は自分のアカウントで入るので、コードは本人のスマホやメールに届きます。担当者が抜けるときは招待した権限を外せば足り、コードの受け取り先を変える作業はありません。 ## 参考資料 - [Google 広告ヘルプ「Google 広告アカウントを保護する: 2 段階認証プロセス」](https://support.google.com/google-ads/answer/12864186?hl=ja) - [Google 広告ヘルプ「Google 広告アカウントへのアクセス権を管理する」](https://support.google.com/google-ads/answer/6372672?hl=ja) - [Google for Developers「Google Ads API セキュリティ要件」](https://developers.google.com/google-ads/api/docs/oauth/security-requirements?hl=ja) - [Facebook ヘルプセンター「Facebookでの二段階認証のしくみ」](https://www.facebook.com/help/148233965247823) - [Facebook ヘルプセンター「Facebookページへのアクセスについて」](https://www.facebook.com/help/289207354498410) - [Meta「Meta利用規約」](https://www.facebook.com/legal/terms) - [Instagram ヘルプセンター「二段階認証でMetaアカウントの安全を確保する」](https://help.instagram.com/566810106808145) - [Instagram ヘルプセンター「利用規約」](https://help.instagram.com/581066165581870) - [X ヘルプセンター「Xの2要素認証(2FA)を使用する方法」](https://help.x.com/ja/managing-your-account/two-factor-authentication) - [X Help Center「How to use two-factor authentication」(英語版)](https://help.x.com/en/managing-your-account/two-factor-authentication) - [X ヘルプセンター「アカウント権限の付与機能の使用方法」](https://help.x.com/ja/managing-your-account/how-to-use-the-delegate-feature) - [LINEヤフー「LINEヤフー共通利用規約」](https://www.lycorp.co.jp/ja/company/terms/) - [LINEヤフー「ビジネスID利用規約」](https://terms2.line.me/business_id_terms?lang=ja) - [LINEヤフー for Business「LINEビジネスIDの2段階認証の有効化(2024/9/3実施)」](https://www.lycbiz.com/jp/news/line-official-account/20240829/) - [LINEヤフー for Business「LINEビジネスIDの2段階認証を必要とする条件変更(2024/9/11実施)」](https://www.lycbiz.com/jp/news/line-official-account/20240909/) - [LINEヤフー for Business「LINE公式アカウント(LINE Official Account Manager)権限設定マニュアル」](https://www.lycbiz.com/jp/manual/OfficialAccountManager/account-settings_permission/) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 担当者がコードを持つ人に毎回チャットで聞き、その人が休みの日は作業が止まります。認証アプリにコードが出る方式なら、Junify がコードを保持して入力するので、受け渡しはなくなります。担当者はスマホで本人確認をして開き、誰が使ったかは一人ずつ残ります。導入時にクライアントと相談してパスワードを変え、Junify だけが持てば、割り当てを外した人は入れません。SMS・メールのコードは対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # カスタマーサポート代行で、クライアントの Zendesk・Freshdesk に入るときのアカウントと権限 オペレーター 1 人ずつ、代行会社が管理するアドレスでエージェントを作ってもらいます。Zendesk・Freshworks の契約は 1 つのログインの共用を認めていません。権限と範囲は受け持つ分に絞り、外れる人はクライアントが停止します。 更新日: 2026-10-13 カスタマーサポート代行でクライアントの問い合わせ管理ツールに入るとき、決めることは 3 つです。誰の名前とアドレスでアカウントを作るか、どこまでの権限と範囲を渡すか、外れる人をどう止めるかです。問い合わせ管理ツールとは、Zendesk や Freshdesk のように、問い合わせを受け付けて担当者が返信する道具です。問い合わせ 1 件ごとの記録を「チケット」と呼びます。 ## オペレーター 1 人に 1 つのエージェント どちらのツールでも、問い合わせに対応する人は 1 人ずつ「エージェント」として登録します。対応する担当者として登録されたユーザーのことです。外部のサポート代行会社が入ることは、契約の文からも想定されていると読めます。Zendesk の顧客契約(Zendesk Customer Agreement)は、1.1 で使える者を定めています。その中に、顧客の「service providers」(業務の委託先)が入っています。その使い方には顧客が責任を負います。Freshworks の利用規約も、利用者の定義に顧客の「contractors」(契約先)を含めています。 一方で、1 つのログインを複数人で使うことは、Zendesk・Freshworks とも契約で認めていません。Zendesk の顧客契約 2.2 は禁止事項の中で、購入したエージェントのログイン 1 つを使えるのは 1 人までとしています。Freshworks の利用規約では、エージェントのログイン情報を複数人で共有したり使ったりしないことに顧客が同意します。Zendesk の公式ヘルプは、ログインを共有すると、変更を加えたエージェントを特定しにくくなるとも説明しています。サポート代行会社は、オペレーターの人数分のエージェントをクライアントに作ってもらうことになります。 ## 誰のメールアドレスで作るか エージェントはメールアドレスで登録します。Freshdesk の公式ヘルプでは、アドレスは必須です。作成するとそのアドレスに有効化のメールが届き、本人がパスワードを決めます。管理者がパスワードを決めておくことはできません。メールが届かなければ、本人がログイン画面の「Forgot Password」から出し直せます。 そのため、アドレスを誰が管理しているかで、辞めた人を止めやすいかが変わります。オペレーターの私用のアドレスで作ると、退職後もそのアドレスでパスワードを決め直せます。この余地は、クライアントが停止するまで残ります。決め方の一例は、サポート代行会社が管理するアドレスを 1 人に 1 つ用意することです。クライアントには、そのアドレスで作ってもらいます。退職の日にアドレスを止めれば、出し直しのメールも本人に届きません。ただし、本人がそのアドレスのメールを読める間は、いつでもパスワードを決め直せます。在職のまま別のクライアントの担当に移る人は、停止されるまで入れる状態が残ります。 ## 権限の種類と、見られるチケットの範囲 どちらのツールでも、エージェントに渡すものは 2 つに分かれます。何ができるか(権限の種類。画面では「ロール」)と、どのチケットが見られるか(範囲)です。公式ヘルプで確かめた違いは次のとおりです(Enterprise・Pro は各社のプランの名前)。 | | Zendesk | Freshdesk | | --- | --- | --- | | 権限の種類 | Enterprise 以外は標準の「エージェント」と「管理者」。Enterprise は独自の権限を作る | 既定は Agent・Supervisor・Administrator・Account Administrator など。独自の権限は Pro・Enterprise で作れる | | 見られるチケットの範囲 | (Enterprise 以外)すべて・所属グループ・所属組織・自分の担当分のいずれか | すべて(All tickets)・所属グループ(Tickets in a group)・自分の担当分(Assigned tickets)のいずれか | | エージェントを追加・停止できる人 | 管理者 | Administrator 以上 | オペレーターに渡すのは、問い合わせに答える権限と、受け持つ問い合わせだけが見える範囲で足ります。管理者の権限まで渡すと、Zendesk ではほかのエージェントの追加や削除までできるようになります。窓口の一部、たとえば一次対応だけを受け持つなら、その分のグループを作ってもらい、範囲をグループに絞る形が考えられます。ただし Zendesk の Enterprise 以外のプランでは、標準の権限に制約があります。公式ヘルプでは、範囲を絞ったエージェントは、問い合わせてきた顧客の登録や編集ができません。レポートを見られるのも、すべてのチケットに入れるエージェントだけです。絞ると何ができなくなるかを、業務の中身と照らして決めます。 顧客の氏名や連絡先が入ったチケットを、一覧で書き出せるかどうかも確かめておきたい点です。Zendesk の Enterprise では、独自の権限ごとに、チケットの一覧の書き出しを許すかどうかを選べます。書き出しの形式は CSV(表計算ソフトで開けるファイル)です。Freshdesk の公式ヘルプは、既定の Agent の権限でも開ける設定を挙げています。定型の返信文などと並ぶ「account exports」(書き出し)です。オペレーターが何を書き出せるかは、権限を付ける前にクライアントの管理者に画面で確かめてもらいます。 ## 外れる人を止める手順 担当交代や退職のとき、エージェントを止める操作はクライアントの管理者が行います。サポート代行会社の役目は、誰をいつ外すかを伝え、止まったことを確かめることです。 Zendesk の公式ヘルプは、次の順を示しています。 1. 未解決のチケットの担当を、ほかのエージェントに付け替える。付け替えないまま削除すると、そのエージェントがいたグループの担当になる。 2. 権限の種類を「エンドユーザー」(問い合わせる側のユーザー)に下げる。対応したチケットの情報を残すためで、下げた後は自分が依頼したチケットしか見られない。 3. 必要に応じてアカウントを「一時停止」する。下げただけでは、ヘルプセンター(問い合わせる側の画面)にはサインインできる。 Freshdesk では、無効化(Deactivate)と削除(Delete)の 2 つから選びます。無効化すると本人はログインできなくなります。解決・終了済みのチケットや記事は本人のものとして残り、対応中のチケットは担当なしに戻ります。削除すると、チケットなどの担当からその人が外れ、本人は連絡先の一覧に残ります。対応の記録をあとでクライアントへの説明に使うなら、無効化のほうが記録を保てます。 ## 複数のクライアントを受け持つときの一覧 1 人のオペレーターが複数のクライアントを受け持つと、エージェントはクライアントの数だけできます。止める操作も、クライアントごとの管理画面で別々に行います。サポート代行会社の側で、オペレーターとクライアントの組み合わせごとに一覧を持っておくと漏れを防げます。項目は、ツール、エージェントのアドレス、権限の種類、見られる範囲、作成を頼んだ日、停止を確かめた日です。退職の日は、この一覧からその人の行を拾ってクライアントごとに依頼します。交代の日の流れ全体は[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にまとめています。 この一覧は、クライアントへの説明にも使えます。チケットには問い合わせた顧客の氏名や連絡先が入ります。そのため、サポート代行はクライアントにとって個人データの取扱いの委託に当たると読めます。個人情報保護法 25 条は、委託する側に「必要かつ適切な監督」(委託先が正しく扱っているか確かめること)を求めています。誰がどのクライアントのツールに入れるかを聞かれたとき、一覧を見せれば答えられます。 ## よくある質問 **オペレーター全員で 1 つのエージェントを使えますか** 使えません。Zendesk の契約は購入したエージェントのログイン 1 つを 1 人までとし、Freshworks の利用規約も複数人での共有を認めていません。人数分を作ってもらいます。 **オペレーターに管理者の権限は要りますか** 問い合わせに答えるだけなら要りません。管理者はほかのエージェントの追加や削除までできます。渡すのは対応に要る権限と、受け持つチケットだけが見える範囲です。 **個人のメールアドレスでエージェントを作っても構いませんか** 避けたいところです。Freshdesk ではパスワードの設定と出し直しのメールがそのアドレスに届きます。代行会社が管理する 1 人 1 つのアドレスなら、退職の日にアドレスを止められます。 **担当を外れた人のエージェントは削除しますか** すぐには削除しません。Zendesk の公式ヘルプは、担当を付け替え、エンドユーザーに下げてから一時停止する順を示しています。Freshdesk では無効化すると、記録を残したままログインできなくなります。 ## 参考資料 - [Zendesk Customer Agreement(Zendesk)](https://www.zendesk.com/company/agreements-and-terms/zendesk-customer-agreement/) - [Zendesk ヘルプ「エージェントは自分でログインする必要がありますか？」](https://support.zendesk.com/hc/ja/articles/4408833795866) - [Zendesk ヘルプ「Zendesk Supportの標準ユーザーロールの概要」](https://support.zendesk.com/hc/ja/articles/4408883763866) - [Zendesk ヘルプ「カスタムロールの作成とエージェントの割り当て」](https://support.zendesk.com/hc/ja/articles/4408882153882) - [Zendesk ヘルプ「エージェントのダウングレードと削除」](https://support.zendesk.com/hc/ja/articles/4408888690842) - [Freshworks Terms of Service(Freshworks)](https://www.freshworks.com/terms/) - [Freshdesk Support "Add support agents"](https://support.freshdesk.com/support/solutions/articles/37591-adding-new-support-agents) - [Freshdesk Support "Manage agent roles"](https://support.freshdesk.com/support/solutions/articles/96909) - [Freshdesk Support "Creating a custom role"](https://support.freshdesk.com/support/solutions/articles/97077-creating-a-custom-role) - [Freshdesk Support "Understanding ticket scope and agent role"](https://support.freshdesk.com/support/solutions/articles/97079) - [Freshdesk Support "Deactivate or Delete Support Agents"](https://support.freshdesk.com/support/solutions/articles/50000008338-deactivating-agents) - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 担当を外れた人も、クライアントに頼んだ停止が済むまでは入れます。Junify では、再発行などのメールを管理者だけが読めるアドレスでエージェントを作ってもらい、導入時にクライアントと相談してパスワードを変え、Junify だけが持ちます。割り当て(使ってよい人の指定)を外した時点で本人は入れなくなり、停止の依頼は後で足ります。後任には本人用のエージェントを作ってもらいます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # EC 運営代行で、受注データや顧客データの書き出しをどう制限するか 書き出しの権限は要る担当者にだけ付けます。Shopify は注文と顧客の書き出しを個別に外せます。BASE は書き出しの App をスタッフが使えるか、画面で確かめます。外せない分は、置き場所・削除・記録の決まりで補います。 更新日: 2026-10-13 EC の管理画面から書き出す受注データには、購入者の氏名・住所・電話番号・メールアドレスが並びます。書き出す形式は CSV(表計算ソフトで開ける形式のファイル)です。Shopify と BASE の公式ヘルプにある項目一覧でも、請求先と配送先の氏名・住所・電話番号が列になっています。画面で 1 件ずつ見るのと違い、書き出しは 1 回の操作で多数の購入者の情報を担当者の手元に移します。EC 運営代行で書き出しを制限するには、書き出せる人を絞る、ファイルの扱いを決める、記録で確かめる、の 3 つを組み合わせます。 楽天 RMS や Yahoo! ショッピングの店舗管理画面は、書き出しだけを外す設定を公開ヘルプで確かめられないため、この記事は Shopify と BASE を扱います。最後の節の決まりは、モールにも当てはまります。担当者を管理画面に入れる方法そのものは、[Shopify・BASE などカート側のスタッフ権限](/guides/agency-accounts/shopify-base-staff-permissions)の記事で扱っています。モールは[楽天 RMS・Yahoo! ショッピングの店舗管理](/guides/agency-accounts/ec-mall-store-admin-access)の記事です。 ## 個人情報保護委員会のガイドラインとの関係 受注データを扱う運営代行会社は、自社も個人情報保護法 23 条の安全管理措置(個人データを守るための対策)を負います。クライアントからは 25 条の監督を受ける立場です。この関係は[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。 個人情報保護委員会のガイドライン(通則編)は、安全管理措置の中身を別添で示しています。書き出しに関係するのは 3 か所です。技術的安全管理措置の(1)は、「担当者及び取り扱う個人情報データベース等の範囲を限定するために、適切なアクセス制御を行わなければならない」としています。使える人と使える情報の範囲を、仕組みで絞るという意味です。組織的安全管理措置の(2)は、記録を残す対象の例に「個人情報データベース等の利用・出力状況」を挙げています。物理的安全管理措置の(3)は、個人データを記録した電子媒体を持ち運ぶときの対策を求めています。「持ち運ぶ」は、管理区域や取扱区域(個人データを扱う場所として決めた区域)の外へ移すことなどと説明されています。書き出した CSV を私物のパソコンや記憶媒体に移す場合は、これに当たると読めます。 委託元(クライアント)の側について、同じガイドラインの 3-4-4 は、委託する業務に必要のない個人データを提供しないことを「当然のこと」としています。発送だけを任せる担当者に全件の書き出しまで許すと、この考え方から外れます。 漏えいが起きたときの重さも、書き出しで変わります。個人データに係る本人の数が 1,000 人を超える漏えいは、個人情報保護委員会への報告の対象です(個人情報保護法の施行規則 7 条 4 号)。取扱いを委託している場合は、原則として委託元と委託先の双方が報告の義務を負います。委託先が委託元に通知すれば、委託先の報告は免除されます。購入者が 1,000 人を超えるショップでは、全件を書き出した CSV 1 本の紛失がこの数を超えます。 ## Shopify で書き出しを外す Shopify では、注文を見る許可と書き出す許可が別になっています。公式ヘルプの「ストアの許可」では、注文管理の中に「閲覧」と並んで「エクスポート」があり、顧客管理にも「エクスポート」があります。発送を担当する人には、注文の閲覧と発送の処理の許可だけを付け、エクスポートを付けない形が取れます。気をつけたいのは、カテゴリーの一番上の項目を選ぶと、中の許可がまとめて選ばれることです。注文管理で一番上を選べばエクスポートも付くので、1 つずつ選びます。下書き注文にもエクスポートの許可があるので、あわせて確かめます。 一方で、許可はストア全体にかかり、特定の注文やお客様だけに絞ることはできません。ヘルプが挙げる例外は 2 つで、アプリや販売先(販売チャネル)ごとの許可と、企業向け販売で取引先の拠点に絞る許可です。 書き出したファイルの届き方は、件数で変わります。50 件までか表示中のページなら、ファイルはその場で端末にダウンロードされます。51 件以上か日付で選んだ場合は、書き出した本人とストアオーナーにメールで届きます。オーナーのアドレスがクライアントのものなら、大量の書き出しにクライアントの側で気づけます。 記録については、ストアのアクティビティログ(管理画面での操作を一覧する画面)の例に書き出しはありません。書き出しが記録されるかは、公式ヘルプに書かれていません。この画面に出せるのは最大 250 件で、一定の日数より前の操作はさかのぼれません。 ## BASE で書き出しを外す BASE のスタッフ権限は、商品・注文・顧客などのメニューと、オーナーが入れた App(追加機能)ごとに付けます。注文データをまとめて書き出すには「注文データダウンロード App」を使います。この App を入れると、注文画面の下にダウンロードのボタンが加わります。 この App は、公式ヘルプの「アクセス権限を設定できるメニュー」の一覧にありません。同じページは、一覧にないメニューや App をスタッフは使えないとしています。一方で App のヘルプは、5,001 件以上を書き出すときのメールを「処理をしたショップオーナーもしくはスタッフ宛」に送るとしています。スタッフが使える場合があるようにも読めます。公式ヘルプからはどちらとも決められないので、スタッフのアカウントで注文画面を開き、ボタンが出るかを確かめます。 「CSV一括発送 App」も書き出しの入口になります。この App で注文を発送済みにする手順は、未発送の注文の CSV をダウンロードするところから始まります。この App を許可すれば、その分の書き出しも許可したことになります。 | | Shopify | BASE | | --- | --- | --- | | 書き出しだけを外す | 注文・顧客それぞれの「エクスポート」を外す | ヘルプからは決められない。スタッフの画面で確かめる | | 大量に書き出したとき | 51 件以上は本人とストアオーナーにメール | 5,001 件以上は、処理した人宛のメールのリンクから | ## 権限で外せない分を補う決まり 管理画面で書き出しを外せないなら、書き出す人とファイルの扱いをクライアントと決めておきます。ガイドラインの 3-4-4 は、委託先がどう扱っているかを委託元が把握できる内容を、委託契約に盛り込むことが望ましいとしています。決めることは次の 4 つです。 1. 書き出してよい担当者と目的。発送や売上の集計など、書き出しが要る作業と人を名前で決めます。決めておかないと、権限を外すべき人が分かりません。 2. ファイルを置く場所。会社が管理するパソコンの決まった場所に限り、私用のメールや私物の端末に移さないと決めます。クライアントにメールで渡す場合は、ファイルにパスワードを付けます。ガイドラインも、中小規模事業者の手法の例にこれを挙げています。 3. 削除の時期。作業が終わったら消し、消したことを記録します。ガイドラインは、削除した記録を残すことを重要としています。 4. 書き出しの記録。管理画面に記録が残らないなら、誰が・いつ・どの範囲を・何のために書き出し、いつ消したかを手で残します。クライアントに聞かれたときに見せるのはこの記録です。ただし、この記録は書き出した本人の申告に頼るので、申告が漏れても管理画面の側からは分かりません。 ## よくある質問 **受注データの書き出しを担当者ごとに禁止できますか** Shopify は注文と顧客の「エクスポート」の許可を外せば、閲覧や発送の処理を残したまま書き出せなくなります。BASE は書き出しの App をスタッフが使えるかがヘルプで決められず、スタッフの画面で確かめます。 **書き出した CSV を自宅のパソコンに置いてもよいですか** ガイドラインは持ち運ぶこと自体を禁じず、持ち運ぶときの対策を求めています。自宅に移すのは「持ち運ぶ」に当たると読めるので、漏えいを防ぐ対策が要ります。置く場所と消す時期をクライアントと決めておきます。 **受注データの CSV をなくしたら報告が要りますか** 本人の数が 1,000 人を超えれば、個人情報保護委員会への報告の対象です。委託を受けている場合は原則として委託元と委託先の双方に義務があり、委託先は委託元に通知すれば報告を免除されます。 **誰が書き出したかは管理画面に残りますか** Shopify・BASE とも、書き出しが記録されるかは公式ヘルプに書かれていません。Shopify では 51 件以上の書き出しがストアオーナーにもメールで届きます。残らない分は作業記録を手で残します。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [Shopify ヘルプセンター「ストアの許可」](https://help.shopify.com/ja/manual/your-account/users/roles/permissions/store-permissions) - [Shopify ヘルプセンター「注文のエクスポート」](https://help.shopify.com/ja/manual/fulfillment/managing-orders/exporting-orders) - [Shopify ヘルプセンター「Shopify管理画面のアクティビティログ」](https://help.shopify.com/ja/manual/shopify-admin/activity-logs) - [BASE ヘルプ「アクセス権限を設定できるメニューには、何がありますか」](https://help.thebase.in/hc/ja/articles/900007657403) - [BASE ヘルプ「【注文データダウンロード App】注文データのダウンロード方法を教えてください」](https://help.thebase.in/hc/ja/articles/900000133723) - [BASE ヘルプ「【CSV一括発送 App】一括で発送処理(ステータス変更)はできますか」](https://help.thebase.in/hc/ja/articles/360000122361) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 管理画面の権限で書き出しだけを外せないと、担当者に「書き出したら申告して消す」と頼み、守られたかを毎回聞くことになります。Junify から開いた管理画面では、パソコンへ落とすダウンロードをアカウントごとに止められ、その頼みと確認が要らなくなります。アップロードは検知して管理者に通知します。担当者がいまパスワードを知っているなら、導入時にクライアントと相談して変え、Junify だけが持ちます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # GA4 とタグ マネージャーの権限を代理店・制作会社に渡すとき GA4 はアカウントかプロパティの単位で閲覧者・編集者などの役割を、タグ マネージャーはコンテナ単位で編集・公開などの権限を渡します。管理者は持ち主の会社に残し、契約終了時は両方のユーザー一覧と Google 広告のリンクを確かめます。 更新日: 2026-10-13 Google アナリティクス 4(GA4)は、サイトやアプリの利用状況を計測するサービスです。Google タグ マネージャーは、サイトに計測などの仕組み(タグ)を置くための管理画面です。どちらも、担当者の Google アカウントを招待する[権限付与](/guides/agency-accounts/what-is-delegated-permission)の仕組みを持っています。ただし 2 つは別のサービスで、権限を付ける単位も役割の名前も違います。 ## 権限を付ける単位と、ユーザーを追加・削除する人 GA4 の権限は、アカウントとプロパティ(計測するサイトやアプリごとの単位)の 2 段階で付けます。タグ マネージャーは、アカウントとコンテナ(サイトごとにタグをまとめる入れ物)の 2 段階です。 | | GA4 | タグ マネージャー | | --- | --- | --- | | 追加できる相手 | Google アカウントに登録されたメールアドレス | Google アカウント | | ユーザーを追加する人 | アカウントかプロパティの管理者 | アカウントの管理者 | | ユーザーを削除する人 | アカウント単位の管理者 | アカウントの管理者 | どちらも、アカウントは持ち主の会社の側に置くものと読めます。アナリティクス ヘルプは、アカウントを 1 つの法人がデータを持つプロパティの集まりと説明し、企業ごとに 1 つを勧めています。タグ マネージャー ヘルプは、アカウントの管理を外部の代理店ではなく組織内の担当者が行うよう勧めています。 ## GA4 で渡す役割 GA4 の役割は 5 つです。 | 役割 | できること(公式ヘルプの説明の要約) | | --- | --- | | 管理者 | すべてを管理する。ユーザーの追加・削除と、役割を付けることもできる | | 編集者 | プロパティの設定をすべて変える。ユーザーの管理はできない | | マーケティング担当者 | オーディエンス(条件で絞った利用者の集まり)、イベント、キーイベント(成果として数える行動)を作る・変える・消す | | アナリスト | 自分が作った分析(データ探索)を、ほかのユーザーと共有する | | 閲覧者 | 設定とデータを見て、レポートに出す項目を変える | 決め方の一例として、レポートを見るだけの制作会社は閲覧者、計測の設定を作り込む代理店は編集者です。広告の成果に使う行動を定める広告運用の担当者には、マーケティング担当者が合います。 役割とは別に、データ制限も付けられます。「費用指標なし」は費用に関する指標を、「収益指標なし」は収益に関する指標を見せない設定です。サイト制作だけを頼む相手に売上の数字を見せたくないときに使えます。 代理店が扱うのが一部のサイトだけなら、アカウントではなくプロパティに追加します。アカウント単位で付けた役割はその下のプロパティすべてに引き継がれます。また公式ヘルプによれば、上の段階で付けた役割より少ない権限をプロパティ側で付け直すことはできません。 Google 広告と GA4 をリンク(つなぐこと)している場合は、広告アカウントの利用者にも GA4 の役割が自動で付きます。この役割では GA4 の画面に入れず、Google 広告の中で GA4 の機能(GA4 のデータからオーディエンスを作るなど)を使えます。GA4 の管理者はリンクの設定画面からこの役割とデータ制限を変えられ、どちらもリンクを解除するまで続きます。 ## タグ マネージャーで渡す権限 タグ マネージャーでは、アカウント単位の権限が「管理」と「ユーザー」の 2 つです。「管理」を持つ人(管理者)は、新しいコンテナを作り、ユーザーの権限を変えられます。コンテナ単位の権限は次のとおりです。 | 権限 | できること(公式ヘルプの説明の要約) | | --- | --- | | 読み取り | タグや設定を見るだけで、変えられない | | 編集 | 作業用の場所(ワークスペース)で変更を作る。版の作成と公開はできない | | 承認 | 変更を作り、版(その時点の設定の控え)を作る。公開はできない | | 公開 | 変更・版の作成・公開のすべてができる | タグ マネージャーでの変更は公開して初めてサイトに反映され、4 つのうち公開できるのは公開の権限だけです。代理店に編集か承認を渡し、公開は持ち主の会社の担当者が行う分け方ができます。公式ヘルプは、有効な管理者を少なくとも 2 人置くことも勧めています。 ## 代理店の中で担当者が代わるとき GA4 でユーザーを削除できるのはアカウント単位の管理者だけで、タグ マネージャーで権限を変えられるのはアカウントの管理者です。代理店がこれを持っていなければ、辞める自社の担当者を外すときも、持ち主の会社に頼むことになります。担当者を代理店の側だけで外せる [Google 広告の MCC](/guides/agency-accounts/google-ads-mcc-agency-access)(代理店が複数の広告アカウントをまとめて扱う管理画面)とは、ここが違います。 ## 契約が終わったときに外すもの 契約終了の作業は、持ち主の会社の管理者が行う操作が中心です。代理店の側では、誰をどの単位で入れたかの一覧を先に渡しておくと、外し漏れを防げます。 1. 代理店のアカウントの中に持ち主の会社のプロパティを作っていた場合は、先にプロパティを持ち主の会社のアカウントへ移します。このままでは、持ち主の会社は削除の操作ができません。移行には両方のアカウントで管理者と編集者の役割が要るので、代理店の協力が要ります。権限は「移行先アカウントの権限で置き換える」を選びます。既存の権限を維持する方を選ぶと、代理店の担当者がプロパティに残ります。 2. GA4 のアカウントとプロパティの両方で、アクセス管理の画面から担当者を削除します。 3. タグ マネージャーのアカウントとコンテナのユーザー管理から、担当者を削除します。 4. Google 広告とのリンクを通じた役割を確かめます。広告アカウント側に担当者が残っていれば、Google 広告の中で GA4 の機能を使える状態も続くと読めます。GA4 は代理店の MCC にもリンクできます。その場合、GA4 から取り込んだデータは MCC の配下の広告アカウントすべてで使えるので、リンクの一覧に代理店の MCC が残っていないかも見ます。 5. 代理店側の人が管理者だった場合は、削除の前に持ち主の会社の管理者がいることを確かめます。タグ マネージャーでは、管理者が 1 人だけでその人の Google アカウントが退職などで削除されると、管理者がいなくなり、アカウントやコンテナは自動で削除されます。読み取りの権限が残っている人は、30 日以内ならゴミ箱から中身を書き出せます。 GA4 の変更履歴には、操作の日時と、操作したユーザーが過去 2 年分残ります(閲覧には編集者の役割が要ります)。ただし、ユーザーの追加や削除そのものが記録されるかは、公式ヘルプには書かれていません。 ## 持ち主の Google アカウントを代理店も使っている場合 招待の仕組みがあっても、持ち主の会社の Google アカウントそのものを代理店の担当者が使い続けている場合があります。1 つの Google アカウントを社内外で使い回す運用は珍しくないでしょう。 この形では、ユーザー一覧にも変更履歴にもその 1 つのアカウントしか出ず、誰が変えたかを担当者まで絞れません。YouTube ヘルプも、Google アカウントの乗っ取りを防ぐ案内で「メールアドレスとパスワードの情報を他のユーザーと共有しないでください」と書いています。招待には次の順で切り替えます。 1. 代理店の担当者それぞれの Google アカウントを、必要な単位に招待します。 2. 担当者が自分のアカウントで入れることを確かめます。 3. 持ち主の Google アカウントのパスワードを変え、代理店には伝えません。変えるまでは、知っている人が入れるからです。 ## よくある質問 **代理店に GA4 の管理者の役割を渡してもよいですか** GA4 の公式ヘルプは、アカウントを 1 つの法人がデータを持つ単位とし、企業ごとに 1 つを勧めています。アカウント単位の管理者は持ち主の会社に残し、代理店には作業に合わせてプロパティの編集者などを渡します。 **制作会社に売上の数字を見せずに GA4 を渡せますか** 役割に加えて「収益指標なし」のデータ制限を付けると、収益に関する指標が表示されなくなります。広告費などを隠す「費用指標なし」もあり、両方を付けることもできます。 **契約が終わったら、GA4 の担当者は誰が削除しますか** 公式ヘルプでは、ユーザーの削除にはアカウント単位の管理者の役割が要ります。持ち主の会社のアカウント管理者が、アクセス管理の画面で担当者を選んで削除します。 **代理店のアカウントで作った GA4 は引き取れますか** 引き取れますが、代理店の協力が要ります。移行元と移行先の両方で管理者と編集者の役割が要るためです。移行では「移行先アカウントの権限で置き換える」を選びます。権限を維持する方を選ぶと、代理店の担当者が残ります。 **タグ マネージャーの公開の権限は誰に渡しますか** 公開すると変更がサイトに反映されます。編集と承認の権限では公開できないので、代理店に編集か承認を渡し、公開は持ち主の会社に残す分け方ができます。 ## 参考資料 - [アナリティクス ヘルプ「アクセス権とデータ制限の管理」](https://support.google.com/analytics/answer/9305587?hl=ja) - [アナリティクス ヘルプ「アナリティクスのユーザーおよびユーザー グループの追加、編集、削除」](https://support.google.com/analytics/answer/9305788?hl=ja) - [アナリティクス ヘルプ「[GA4] Google アナリティクス アカウントの構成」](https://support.google.com/analytics/answer/9679158?hl=ja) - [アナリティクス ヘルプ「[GA4] プロパティを移行する」](https://support.google.com/analytics/answer/9305872?hl=ja) - [アナリティクス ヘルプ「Google 広告を Google アナリティクスに接続する」](https://support.google.com/analytics/answer/9379420?hl=ja) - [アナリティクス ヘルプ「アカウント / プロパティの変更履歴を表示する」](https://support.google.com/analytics/answer/9305465?hl=ja) - [YouTube ヘルプ「ハッキングされた YouTube チャンネルを復元する」](https://support.google.com/youtube/answer/76187?hl=ja) - [タグ マネージャー ヘルプ「ユーザーと権限の管理」](https://support.google.com/tagmanager/answer/6107011?hl=ja) - [タグ マネージャー ヘルプ「公開、バージョン、承認」](https://support.google.com/tagmanager/answer/6107163?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** GA4 を任された担当者が、同じクライアントの SNS や広告には共有の ID で入ることもあります。その ID では、人が抜けるたびにパスワードの変更を頼み、残る人に伝え直します。導入時にパスワードを変えて Junify だけが持てば、担当者はパスワードを知らずに入れ、抜ける人は割り当て(使ってよい人の指定)を外すだけです。GA4 とタグ マネージャーは招待で運用します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Google ビジネス プロフィールのオーナーと管理者を、本部・店舗・運用代行会社でどう分けるか 管理者も投稿・クチコミへの返信・営業時間の編集ができ、ユーザーの追加と削除、プロフィールの削除はオーナーだけです。メインのオーナー権限は本人しか譲れないので、本部が持てば、代行会社との契約が終わるときに代行会社の操作を待たずに済みます。 更新日: 2026-10-13 Google ビジネス プロフィール(Google 検索や Google マップに出る店舗の情報を管理するサービス)では、1 つの店舗のプロフィールに複数のユーザーを追加できます。ユーザーにはオーナーか管理者を付けます。本部・店舗・運用代行会社で運用するときは、誰をどちらにするかで、担当が外れるときの作業が決まります。人ごとに許可を出す仕組みは[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で説明しています。 ## オーナーと管理者でできることの違い 公式ヘルプの権限の表で、オーナーだけに付いている項目は「ユーザーの追加と削除」と「ビジネス プロフィールの削除」の 2 つです。投稿、クチコミへの返信、営業時間や写真の編集などは、管理者でもできます。 オーナーは複数置けますが、そのうち 1 人だけがメインのオーナーです。メインのオーナー権限を譲渡できるのはメインのオーナーだけで、譲渡するまでは自分をプロフィールから外せません。 | 操作 | メインのオーナー | オーナー | 管理者 | | --- | --- | --- | --- | | 投稿・クチコミへの返信・店舗情報の編集 | できる | できる | できる | | ユーザーの追加と削除、役割の変更 | できる | できる | できない | | プロフィールの削除 | できる | できる | できない | | メインのオーナー権限の譲渡 | できる | できない | できない | 追加されたばかりのオーナーと管理者は、7 日ほど一部の操作ができません。プロフィールの削除と削除の取り消し、他のオーナーや管理者の削除、メインのオーナー権限の譲渡です。 招待は、相手のメールアドレスを指定して行います。Google グループ(複数の人をまとめた宛先)は、オーナーにも管理者にも追加できません。 ## 本部・店舗・運用代行会社への割り振り 誰をオーナーにするかの決まりは公式ヘルプにないので、上の決まりから考えた一例を示します。 ### 本部はメインのオーナーと、もう 1 人のオーナー メインのオーナーは、本部の担当者が会社のメールアドレスで作った自分の Google アカウントで持ちます。譲渡にはメインのオーナー本人の操作が要るので、辞めるときの手続きの中で譲渡を済ませてもらえる本部の人が持つ形です(下の「本部のメインのオーナーが異動・退職する」)。メインのオーナーが不在でも人を足したり外したりできるよう、本部にもう 1 人オーナーを置きます。管理者は人を追加も削除もできないためです。 ### 店舗はそのお店のプロフィールの管理者 店長やスタッフは、自分のお店のプロフィールにだけ管理者として追加します。管理者はユーザーを追加できないので、店舗の判断で入れる人が増えることはありません。 ### 運用代行会社は担当者ごとの管理者 運用代行の作業(投稿、クチコミへの返信、分析情報のダウンロード)は、管理者で足ります。担当者ごとに会社のメールアドレスで招待し、1 つのアカウントをチームで使い回さないようにします。その代わり、代行会社の担当者が増えるたびに、本部へ招待を頼むことになります。 代行会社にメインのオーナーを渡すと、契約が終わるときに代行会社の操作が要ります。連絡が取れないときに公式ヘルプにある手続きは「オーナー権限をリクエストする」で、現在のオーナーの返答期限は 3 日です。返答がなければビジネスの確認(Google にオーナーだと確かめてもらう手続き)に進めることがありますが、いつもできるとは限りません。 ## 店舗が多いときのビジネス拠点グループ 店舗が多い場合は、複数のプロフィールをビジネス拠点グループ(旧称「ビジネス アカウント」。複数の店舗をまとめて管理する単位)に入れられます。グループにもオーナーと管理者がいて、権限の範囲は 1 店舗のプロフィールとは違います。 | 操作 | グループのオーナー | グループの管理者 | | --- | --- | --- | | グループのユーザーの追加と削除 | できる | できない | | グループの削除と譲渡 | できる | できない | | グループ内のプロフィールの追加・編集・削除 | できる | できる | | プロフィールを別のグループへ移す | できる | できる | グループのオーナーや管理者は、あとから加えた店舗も含め、グループ内のすべてのプロフィールに入れます。プロフィールを移す先は、移す人がオーナーか管理者になっているグループです。 そのため、運用代行会社の担当者をグループの管理者にすると、担当外の店舗にも入れ、削除や、別のグループへの移し替えもできる状態になります。担当する店舗が決まっている人は、店舗ごとに追加すれば範囲を絞れます。 代行会社には、代理店向けの組織アカウント(複数のクライアントのプロフィールをまとめて扱うもの)もあります。1 店舗のプロフィールは、オーナーが代行会社のグループをグループ ID(グループごとに振られた番号)で招待するか、代行会社から申請します。ビジネス拠点グループは、グループのオーナーが代行会社の組織を組織 ID(10 桁の番号)で招待します。 代行会社のグループに入ったプロフィールには、そのグループのオーナーと管理者が全員入れるので、店舗ごとの管理者より範囲が広くなります。代行会社で担当者が辞めたとき、組織から外せるのは組織のオーナーだけです。 ## 担当が外れるとき ### 店舗や運用代行会社の担当者を外す オーナーが「ビジネス プロフィールの設定」の「ユーザーとアクセス権」で、その人を削除します。その人の返信や投稿はプロフィールに残ります。メインのオーナー以外は、同じ画面の「管理をやめる」で自分から外れることもできます。承諾前の招待は「保留中」から「招待をキャンセル」で取り下げます。 グループで入っている人を外せるのは、グループのオーナーだけです。店舗ごとのオーナーと管理者はグループとは別に設定されるので、店舗ごとの一覧も見ます。 ### 本部のメインのオーナーが異動・退職する 1. 後任を同じプロフィールのオーナーか管理者として追加します。後任は追加から 7 日ほど、元の担当者を含め他の人を外せません。外す作業を後任がするなら、7 日以上前に追加します。 2. メインのオーナーが「ユーザーとアクセス権」で後任を選び、「アクセス」を「メインのオーナー」に変えて保存します。 3. 譲渡のあと元のメインのオーナーがどの役割になるかは公式ヘルプに書かれていないので、一覧で確かめてから外します。 ### 運用代行会社との契約が終わる 本部のオーナーが代行会社の担当者全員を各店舗から外し、グループのオーナーがグループから外します。代行会社がメインのオーナーを持っていた場合は、契約が終わる前に本部への譲渡を頼みます。組織アカウントでつないでいる場合、本部の側から外す手順は公式ヘルプには書かれていないので、代行会社と確かめます。担当交代の作業全体は[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にまとめています。 ## 共有の Google アカウントで入っている場合 店舗用の 1 つの Google アカウントをオーナーにしてパスワードを共有していると、ユーザーの一覧にはそのアカウントしか出ません。1 人だけを外すには、パスワードを変えて残る人に配り直すことになります。YouTube ヘルプも、Google アカウントの乗っ取りを防ぐ案内で「メールアドレスとパスワードの情報を他のユーザーと共有しないでください」と書いています。 この形から移るときは、使っている人をそれぞれ自分のアカウントで管理者に追加します。共有アカウントがメインのオーナーなら、本部の担当者のアカウントへ譲渡してから、共有アカウントを外します。 ## よくある質問 **オーナーと管理者は何が違いますか** 公式ヘルプの表で、オーナーだけに付いている項目は、ユーザーの追加と削除、プロフィールの削除の 2 つです。投稿、クチコミへの返信、営業時間や写真の編集は管理者でもできます。 **運用代行会社にはどちらの権限を渡しますか** 日々の運用は管理者で足ります。担当者ごとにメールアドレスで招待し、Google グループでまとめて招待することはできません。代行会社の組織アカウントのグループを招待する方法もあります。 **メインのオーナーを運用代行会社に任せてもよいですか** メインのオーナー権限を譲渡できるのはメインのオーナーだけです。代行会社が持つと、契約が終わるときに代行会社の操作が要ります。本部が持てば、その操作を待たずに済みます。 **担当者を外すと、その人の返信や投稿は消えますか** 消えません。公式ヘルプでは、削除されたユーザーが書いたクチコミへの返信や投稿などは、プロフィールに残るとされています。 **引き継ぎの直前に後任を追加しても間に合いますか** 後任に元の担当者を外してもらうなら、間に合わないことがあります。追加されたオーナーと管理者は 7 日ほど、他のオーナーや管理者の削除、メインのオーナー権限の譲渡などができません。 ## 参考資料 - [Google ビジネス プロフィール ヘルプ「ビジネス プロフィールのオーナーと管理者を管理する」](https://support.google.com/business/answer/3403100?hl=ja) - [Google ビジネス プロフィール ヘルプ「ビジネス プロフィールのメインのオーナー権限を譲渡する」](https://support.google.com/business/answer/3415281?hl=ja) - [Google ビジネス プロフィール ヘルプ「ビジネス プロフィールのオーナー権限をリクエストする」](https://support.google.com/business/answer/4566671?hl=ja) - [Google ビジネス プロフィール ヘルプ「ビジネス拠点グループのオーナーと管理者を管理する」](https://support.google.com/business/answer/4669093?hl=ja) - [Google ビジネス プロフィール ヘルプ「ビジネス拠点グループを作成、管理する」](https://support.google.com/business/answer/6085339?hl=ja) - [YouTube ヘルプ「ハッキングされた YouTube チャンネルを復元する」](https://support.google.com/youtube/answer/76187?hl=ja) - [Google ビジネス プロフィール ヘルプ「代理店向けの概要」](https://support.google.com/business/answer/9199701?hl=ja) - [Google ビジネス プロフィール ヘルプ「代理店の招待を管理する」](https://support.google.com/business/answer/7655924?hl=ja) - [Google ビジネス プロフィール ヘルプ「代理店による組織の管理について」](https://support.google.com/business/answer/7663063?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 運用代行会社の担当者が辞めた日、Google ビジネス プロフィールは本部のオーナーにその人を外してもらえば済みます。手間が残るのは、同じ人が扱っていたクライアントの SNS や広告のうち、1 つの ID を皆で使うアカウントです。導入時にパスワードを変えて Junify だけが持てば、担当者はパスワードを知らずに使え、辞めた人は割り当て(使ってよい人の指定)を外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 運用代行会社の ISMS・P マーク審査で、クライアントから預かったアカウントをどう説明するか 預かったアカウントは、ISMS では適用範囲に含める資産として、P マークでは受託した個人情報がある場所として扱うと読めます。審査では、アカウントの一覧、使える人、使った記録、外した記録、契約の約束を示します。 更新日: 2026-10-13 運用代行会社は、クライアントから SNS・広告・EC のアカウントを預かって運用しています。ISMS や P マークの審査では、このアカウントも説明を求められる対象に入ると読めます。ISMS では、守る対象の資産として適用範囲(認証の対象とする組織や業務の範囲)に入れることになります。P マークでは、受託した個人情報がある場所として台帳に載ります。いずれも JIPDEC の公開資料からの読み方です。審査で示すのは、アカウントの一覧、使える人、使った記録、外した記録と、契約や規約で約束していることの一覧です。 ## ISMS の適用範囲にどう入れるか JIPDEC の ISMS ユーザーズガイドは、適用範囲の決め方(規格の 4.3)を説明しています。その中で、守るべき重要な情報と、それに関連する資産は、適用範囲に含めなければならないとしています。運用代行会社にとって、預かったアカウントは事業そのものに使う資産です。ガイドが挙げる基準は守るべきかどうかで、持ち主が誰かではないと読めます。ガイドは、適用範囲の外に置く資産があれば、その資産と理由を適用範囲の文書に書くことが望ましい、ともしています。 同じガイドは、法令や規制の要求と契約上の義務も、利害関係者の要求に含まれるとしています。利害関係者とは、取引先や従業員など、組織の取組みに関わる人や組織です。クライアントとの契約にあるアカウントの扱いの約束は、この要求として洗い出す対象です。媒体の利用規約やヘルプがログイン情報を他人と共有しないよう求めている場合も、同じく洗い出す対象になります。その媒体で ID を共有しているなら、求められていることと運用のずれとして、自社で把握しておく必要があります。 預かりアカウントの一覧は、管理の責任者の欄を足せば、資産の一覧の一部に使えます。一覧の項目は[運用代行のクライアントアカウント管理](/guides/agency-accounts)で挙げています。ガイドは、資産の管理の責任者の多くがリスク所有者(その危険への対応を決める責任と権限を持つ人)でもあるとしています。 ## P マークの台帳にどう書くか P マークの審査では、JIPDEC の「構築・運用指針」(JIS Q 15001:2023 準拠 ver1.0)を使います。指針は、対象を「自らの事業の用に供している全ての個人情報」としています。受託した個人情報を除く書き方はしていません。J.1.2 の留意事項は、利害関係者の例に「委託元(及び委託元の顧客)」を挙げています。受託した個人情報も、指針の中で扱う前提になっています。同じ留意事項は、利害関係者の要求事項に、取引先との契約上の義務などを含めてもよいとしています。 預かったアカウントの中には、個人情報が入っているものがあります。SNS の DM、キャンペーンの応募者の情報、広告に使う顧客リスト、EC の受注情報などです。こうした個人情報は、台帳(J.3.1.1)に載せることになると読めます。その場合、保管場所はクライアントのアカウントです。「アクセス権を有する者」を氏名で書くか役割で書くかは、指針に定めがありません。共有 ID で預かったアカウントは ID 名だけでは誰が入れるか分からないので、使う担当者の氏名を、台帳か台帳から参照する一覧に書きます。台帳の項目と確認の頻度は[プライバシーマーク(JIS Q 15001)でアカウント管理について求められること](/guides/compliance/privacy-mark-account-management)で、どこまで書くかは[個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか](/guides/compliance/personal-data-ledger-accounts)で扱っています。 ## 審査で何を見られるか P マークの現地審査について、JIPDEC のページは 4 つの段階を示しています。代表者への聞き取り、運用状況の確認、現場での確認、総括です。運用状況の確認では、個人情報を扱う業務ごとに状況を確かめます。挙がっているのは、個人情報の特定、リスクアセスメント、リスク対策、安全管理措置などです。リスクアセスメントはどこにどんな危険があるかを見積もること、リスク対策はその危険ごとに対応を決めることです。安全管理措置は、個人情報を守るために実際に行う対策です。その際、実際の運用の記録の提示を求めることがあるとしています。更新では、有効期間が終わる 8 か月前から 4 か月前までに申請し、そのあとの審査は新規と同じ流れです。指摘を受けたら、指摘事項文書の日付から 3 か月以内に改善報告書を出します。 ISMS は、ISMS-AC のパンフレットによると、認証の有効期限が 3 年です。その間も年 1 回以上の審査(サーベイランス審査)があり、3 年ごとに更新のための全面的な審査があります。審査の前に一覧を作り直すやり方では、その作業が審査のたびに発生します。日々の運用で一覧と記録を更新していれば、そのまま見せられます。 ## 説明に使う記録と、預かり方による違い 管理策は、規格の附属書 A にある対策の項目です。その名称は、日本規格協会が公開する JIS Q 27002:2024 の目次で確かめられます。管理策の本文は有料なので、何を求めているかは規格を入手して確かめる必要があります。審査で示すものごとに、関わる管理策と項番を並べると次のようになります。対応づけは規格や指針の記述ではなく、名称から読んだこの記事の読み替えです。 | 審査で示すもの | ISMS で関わる管理策(目次の名称) | P マークで関わる項番 | | --- | --- | --- | | アカウントの一覧 | 5.9 情報及びその他の関連資産の目録 | J.3.1.1 個人情報の特定(台帳) | | 使える人 | 5.18 アクセス権 | J.3.1.1 の「アクセス権を有する者」 | | 使った記録 | 8.15 ログ取得 | J.9.2 安全管理措置 | | 外した記録 | 5.18 アクセス権 | J.3.1.1 の台帳の更新 | | 契約と規約の約束 | 5.31 法令，規制及び契約上の要求事項 | J.1.2 利害関係者の要求事項 | | 任せている外部の人 | 5.19 供給者関係における情報セキュリティ | J.9.4 委託先の監督 | 表の最後の行は、運用の一部を在宅のフリーランスなど社外の人に任せる場合です。業務委託の契約で任せているなら、今度は自社が委託する側になります。指針の J.9.4 は、全ての委託先を漏れなく特定し、8 つの事項を盛り込んだ契約を結ぶよう求めています。クライアントの個人データを扱うアカウントを使わせているなら、委託先の一覧にその人を載せることになると読めます。自社の指揮監督の下で働いてもらっている場合は、従業者として J.9.3 の監督の側で扱うと読めます。ISMS では、ユーザーズガイドが JIS Q 27000 の注記を引いています。外部に任せた作業は適用範囲の中に残り、任せた先の組織は外にある、という注記です。 預かり方によって、この表のうち示しにくい行が変わります。ID とパスワードを共有して預かっているアカウントでは、「使える人」と「使った記録」の 2 行が示しにくくなります。一覧からある担当者を外しても、パスワードを変えるまではその人は入れるので、一覧と実際の状態がずれます。媒体の記録は ID 単位なので、担当者ごとの作業記録を別に付けていなければ、誰が使ったかを示せません。共有で預かるアカウントが残るなら、一覧に 2 つを書き添えておきます。パスワードを知っている人の範囲と、人を外したときにパスワードを変えた日です。 権限付与(担当者ごとに招待を受ける形)で預かっているアカウントでは、媒体のユーザー一覧が使える人の一覧になります。使った記録も、媒体が履歴を残す範囲で担当者ごとに残ります。アクセス管理ツールは、パスワードを担当者に見せず、ツールを通してログインさせる仕組みです。この形で預かる場合も、ツール上の使える人の一覧と担当者ごとの利用の記録を、そのまま 2 行の説明に使えます。 ## よくある質問 **自社のものではないアカウントも ISMS の対象ですか** ユーザーズガイドは、守るべき重要な情報と関連する資産は適用範囲に含めるとしています。基準は守るべきかどうかで、持ち主ではないと読めます。外す場合は、その資産と理由を文書に書くことが望ましいとされています。 **P マークの台帳にクライアントの顧客情報も書きますか** 指針は対象を事業に使う全ての個人情報とし、利害関係者に委託元を挙げています。保管場所にはクライアントのアカウントを書きます。共有 ID で使うアカウントは、使う担当者の氏名を台帳か、台帳から参照する一覧に書きます。 **P マークの更新でも現地審査はありますか** あります。JIPDEC の案内では、更新でも申請のあとの審査は新規と同じ流れです。現地審査では、業務ごとに個人情報の特定や安全管理措置などの状況を確かめ、運用の記録を求めることがあります。 **在宅のフリーランスに運用を任せている場合は** 業務委託の契約で、個人データを扱うアカウントを使わせているなら、自社が委託する側になると読めます。指針の J.9.4 は、全ての委託先を特定し、8 つの事項を盛り込んだ契約を結ぶよう求めています。 ## 参考資料 - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [ISMS-AC「ISMS 適合性評価制度」パンフレット(JIP-ISMS120-7.2、2025 年 8 月)](https://isms.jp/doc/JIP-ISMS120-72.pdf) - [日本規格協会「JIS Q 27002:2024 情報セキュリティ，サイバーセキュリティ及びプライバシー保護―情報セキュリティ管理策」プレビュー(目次)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27002_000_000_2024_j_ed10_ch.pdf) - [JIPDEC「プライバシーマークにおける個人情報保護マネジメントシステム構築・運用指針【JIS Q 15001:2023 準拠 ver1.0】」(2023 年 12 月 25 日制定)](https://privacymark.jp/guideline/pm_shishin2023v1.0.pdf) - [JIPDEC プライバシーマーク推進センター「現地審査」](https://privacymark.jp/p-application/new/e-app/on_site_review.html) - [JIPDEC プライバシーマーク推進センター「更新申請方法」](https://privacymark.jp/p-application/update/index.html) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 審査が近づくたびに、クライアントと媒体ごとに誰がパスワードを知っているかを聞き取って一覧を作り直す作業は、Junify では要りません。導入時にクライアントと相談してパスワードを変え、Junify だけが持つようにします。すると割り当て(使ってよい人の指定)の画面がそのまま使える人の一覧になり、誰が・いつ使ったかも担当者ごとに残ります。割り当てを外した人は、その時点から入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Microsoft 広告を代理店に任せるときの役割の付け方と外し方 担当者を 1 人ずつ招待する形と、クライアントの広告アカウントを代理店のマネージャー アカウントにつなぐ形の 2 つ。運用担当にはキャンペーンか標準を付けます。招待した人は 1 人ずつ削除し、リンクは解除すると代理店の全員が外れます。 更新日: 2026-10-13 Microsoft 広告で代理店に運用を任せる形は 2 つあります。1 つは、クライアントが代理店の担当者を 1 人ずつユーザーとして招待し、役割を付ける形です。もう 1 つは、クライアントの広告アカウントを代理店のマネージャー アカウントの下に置く形です。ヘルプはこれをアカウントのリンクと呼びます。どちらでも担当者は自分の Microsoft アカウントで入るので、クライアントのパスワードを受け取る必要はありません。パスワードを渡さずに操作を任せる考え方は、[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)にまとめています。 ## 広告アカウントとマネージャー アカウント Microsoft 広告のアカウントは 2 段です。広告アカウントはキャンペーン・キーワード・予算を持ち、実際に広告を出す単位です。マネージャー アカウントは、広告アカウントを束ねる入れ物です。ユーザーと役割、支払い方法、成果を測るためのタグは、マネージャー アカウントの単位で配下の広告アカウントと共有できます。 ヘルプによれば、登録するとマネージャー アカウントと広告アカウントが 1 組で作られます。つまりクライアントにも代理店にもマネージャー アカウントがあり、代理店だけが作るものではありません。ヘルプの訳によっては管理者アカウントや MCC とも書かれます。代理店などが作る Google 広告の MCC とは、この点が違います。 1 人の担当者が持つ役割は、入れるマネージャー アカウントごとに違ってかまいません。あるクライアントでは閲覧者、別のクライアントではキャンペーン、という持ち方ができます。担当者は、自分が入れる先とその役割を「Manage my user access」の画面で確かめられます。この画面は、画面右上のプロフィール画像から開きます。 ## 4 つの役割と、代理店の担当者に付けるもの 役割はスーパー・標準・キャンペーン・閲覧者の 4 つです。ヘルプの別のページでは、スーパー管理者・標準ユーザー・広告主キャンペーン管理者・閲覧者と書かれています。ヘルプの比較表から、キャンペーンと標準の違いが分かる行を中心に抜き出しました。 | 操作 | スーパー | 標準 | キャンペーン | 閲覧者 | | --- | --- | --- | --- | --- | | キャンペーンの管理 | ○ | ○ | ○ | — | | レポートの実行 | ○ | ○ | ○ | ○ | | 広告掲載オーダーの作成・承認 | ○ | ○ | — | — | | 支払い方法の追加・編集・削除 | ○ | — | — | — | | ユーザーの招待・変更・削除 | ○ | 一部 | — | — | | 代理店からのリンク申請の承認・却下 | ○ | ○ | — | — | | リンクの申請と解除 | ○ | — | — | — | 広告掲載オーダーは、月ごとの請求書払いのアカウントで広告を出し続けるために作る発注です。標準の「一部」とは、標準・キャンペーン・閲覧者の人なら追加も削除もできるという意味です。スーパーの人は編集も削除もできません。 キャンペーンと標準のあいだでは、広告掲載オーダー、ユーザーの管理、リンク申請の承認が分かれます。代理店の担当者が入稿と予算の調整だけを受け持つなら、キャンペーンで足ります。広告掲載オーダーまで代理店が作るなら標準が要ります。標準にすると、ほかの人の招待と、代理店からのリンク申請の承認も一緒に任せることになります。 スーパーは、ヘルプによればマネージャー アカウントの単位でしか付けられません。ほかの役割を広告アカウント 1 つに絞って付けられるかは、公式ヘルプに書かれていません。クライアントのマネージャー アカウントでスーパーを付けた人は、配下のいまある広告アカウントすべてに入れます。これから作る広告アカウントにも自動で入れます。支払い方法の変更やリンクの解除もできるので、クライアントが代理店の担当者にスーパーを付けるのは避けたいところです。 ## ユーザーとして招待する(マルチユーザー アクセス) 招待するのは、クライアント側でユーザーを管理できる人(スーパーか標準)です。「設定」の「ユーザー管理」で担当者のメール アドレスと役割を指定し、招待を送ります。担当者は招待メールのリンクからサインインして承諾します。ヘルプによれば、招待メールを受け取ったら 30 日以内に有効にする必要があります。サインインに使えるのは Microsoft アカウントだけです。 1 つのユーザー名で別々の会社のアカウントに入れる状態を、ヘルプはマルチユーザー アクセスと呼んでいます。受け持つクライアントごとに招待を受けても、担当者のログインは自分の 1 つの ID で済みます。 この形で、1 つのログインを担当者どうしで使い回すことはしません。ヘルプは、ユーザーごとに別のメール アドレスとパスワードを使うよう勧め、共有を勧めない理由を次の 3 つとしています。 - 人が入れ替わると、アカウントの安全を保ちにくい - メール アドレスには、電話番号などの個人の情報や、Outlook などの製品が結びついている - 変更履歴で、誰が変えたかを調べにくくなる 同じページは「パスワードや PIN を同僚に教えてはなりません」とも書いています。Microsoft サービス規約も、ログイン情報は他人に移せず、パスワードは秘密にするよう定めています。 ## 代理店のマネージャー アカウントにつなぐ リンクでは、代理店がクライアントのアカウント番号を入れて申請します。承認するのは、クライアントでスーパーか標準の役割を持つ人です。ヘルプによれば、申請への返答の期限は 30 日で、返答がなければ却下されます。安全のため、申請から 6 時間たつまでは承諾できません。 承認されると、代理店はその広告アカウントの「直接管理者」になります。直接管理者は、キャンペーンの運用から請求の引き継ぎまで扱えます。ヘルプは、請求を引き継ぐ前に、いまの請求先と取り決めを結ぶよう勧めています。1 つの広告アカウントにつなげる直接管理者は 5 つまでです。 直接管理者は、ほかの直接管理者を外したり、新しく足したりできます。一方で、クライアントが招待して役割を付けたユーザーは削除できません。クライアントがリンクを承認するときは、この範囲まで任せることになります。 ヘルプはこの形を「階層」と呼び、代理店側のユーザーのまとまりに管理の権限が渡ると説明しています。解除すると、そのまとまり全員のアクセスが一度に消えます。1 人ずつ付けて 1 人ずつ外す招待とは、この点が違います。リンクで入る担当者は代理店のマネージャー アカウントのユーザーなので、代理店の中のユーザー管理で外せると読めます。 ## 外すとき 招待で入った担当者は、クライアント側でユーザーを管理できる人が「ユーザー管理」でその人を選んで削除します。担当者本人も、「Manage my user access」の「Delete access」で外せます。たとえば担当交代の日に、外れる担当者と一緒にこの画面を開く方法があります。その人が入れるマネージャー アカウントと役割が並ぶので、どのクライアントの分が残っているかをその場で確かめられます。急に辞めて本人が操作できないときは、クライアント側で削除します。 契約が終わったら、リンクを解除します。クライアント側では、スーパーの人が「設定」の「直属の上司」を開き、入っている直接管理者を確かめて解除します。代理店の側からも、止める日を指定して解除できます。日付を指定した解除は取り下げられますが、即時の解除は取り下げられません。 解除の前に、請求先を確かめます。代理店の側で解除する場合、代理店が請求先になっている後払いか月次請求書のアカウントは、最長 3 時間止まります。ヘルプは、止まる時間と新しい請求先を、解除の前にクライアントと相談するよう勧めています。クライアントが解除する場合は、クライアント自身が請求先になるので、支払い方法を用意しておきます。 「変更履歴」では、キャンペーン・広告グループ・広告・キーワードへの変更を過去 6 か月分見られます。「変更者」で人ごとに絞り込めます。ユーザーを人ごとに分けておけば、担当交代の前後で誰の操作かを分けて示せます。 ## よくある質問 **代理店の担当者にスーパーを付けてもよいですか** 避けたいところです。スーパーの人は、配下のいまある広告アカウントにも、これから作る広告アカウントにも入れ、支払い方法の変更もできます。運用担当にはキャンペーンか標準で足ります。 **招待とアカウントのリンクは何が違いますか** 招待はクライアントが担当者 1 人ずつに役割を付け、1 人ずつ外します。リンクは代理店のマネージャー アカウントにつなぐ形で、代理店が直接管理者として請求の引き継ぎまで扱え、解除すると代理店の全員が一度に外れます。 **代理店の担当者が交代したら、クライアントは何をしますか** 招待で入った人なら、スーパーか標準の人がユーザー管理から削除します。リンクで入った人は代理店のユーザーなので、代理店の中で外せると読めます。担当者はクライアントのパスワードを知らないので、変更は要りません。 **1 つのログインを担当者で共有してもよいですか** ヘルプは共有を勧めず、パスワードを同僚に教えないよう求めています。共有すると、変更履歴で誰が変えたかを調べにくくなります。 **契約終了でリンクを外すと広告は止まりますか** 代理店の側で解除し、代理店が請求先の後払いか月次請求書のアカウントなら、最長 3 時間止まります。クライアントの側で解除するときは、保留にならないよう支払い方法を用意しておきます。 ## 参考資料 - [Microsoft 広告 ヘルプ「Microsoft 広告 アカウントへのアクセス権を他のユーザーに付与するには」](https://help.ads.microsoft.com/#apex/ads/ja-jp/52037/0) - [Microsoft Advertising Help "How do I give someone access to my Microsoft Advertising account?"(役割の比較表の英語原文)](https://help.ads.microsoft.com/#apex/ads/en-us/52037/0) - [Microsoft 広告 ヘルプ「Microsoft 広告の階層」](https://help.ads.microsoft.com/#apex/ads/ja-jp/60035/0) - [Microsoft 広告 ヘルプ「既存のアカウントへのリンク」](https://help.ads.microsoft.com/#apex/ads/ja-jp/56854/0) - [Microsoft 広告 ヘルプ「階層またはマルチユーザー アクセスのどちらかを選択する」](https://help.ads.microsoft.com/#apex/ads/ja-jp/60036/0) - [Microsoft 広告 ヘルプ「招待されたユーザーとして Microsoft 広告にアクセスする方法」](https://help.ads.microsoft.com/#apex/ads/ja-jp/52093/0) - [Microsoft 広告 ヘルプ「複数のアカウントにアクセスするためのユーザー名を管理する」](https://help.ads.microsoft.com/#apex/ads/ja-jp/56867/0) - [Microsoft 広告 ヘルプ「キャンペーンにはどのような変更が加えられていますか? またそれを元に戻すことはできますか?」](https://help.ads.microsoft.com/#apex/ads/ja-jp/50840/0) - [Microsoft 広告 ヘルプ「Microsoft 広告アカウントの保護に役立つベスト プラクティス」](https://help.ads.microsoft.com/#apex/ads/ja-jp/52087/0) - [Microsoft「Microsoft サービス規約」(第 4 条 a 項 i)](https://www.microsoft.com/ja-jp/servicesagreement) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 担当者が辞めるたびにクライアントへパスワードの変更を頼む作業は、人ごとに招待できず 1 つの ID で入る管理画面に残ります。Junify が受け持つのは、こうした画面だけです。導入時にクライアントと相談してパスワードを変え、Junify だけが持つので、割り当て(使ってよい人の指定)を外せばその人は入れません。Microsoft 広告のように招待できる媒体は、担当者ごとに招待します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 在宅のオペレーターにクライアントの管理画面を使わせるとき、決めることと確かめること 決めるのは、在宅で扱うアカウント、使う端末、ログインの渡し方、端末に残してよいデータの 4 つです。確かめるのは端末の状態と、誰がいつ入ったかを後で示せるかです。管理画面に直接つなぐ形では、記録は媒体の側にしか残りません。 更新日: 2026-10-13 在宅のオペレーターが、自宅のパソコンからクライアントの SNS・広告・EC の管理画面に入るとします。運用代行会社が始める前に決めることは 4 つです。在宅で扱ってよいアカウント、使う端末、ログインの渡し方、端末に残してよいデータです。始めてから確かめ続けることは 2 つで、端末の状態と、誰がいつ入ったかを後で示せるかです。ログインの渡し方と付ける権限は、運用代行会社だけでは決められず、アカウントの持ち主であるクライアントと決めます。 ## 自宅から管理画面に入る形はどの方式に当たるか 総務省は「中小企業等担当者向けテレワークセキュリティの手引き(チェックリスト)」第 3 版を出しています。テレワークを 8 つの方式に分け、方式ごとにチェックリストを付けた資料です。在宅のオペレーターが管理画面に入る形は、端末からインターネット上のサービスに直接つなぐ「クラウドサービス方式」に当たると読めます。会社支給のパソコンなら方式②、私物のパソコンなら方式⑥です。 手引きは法令ではなく、各項目に効果と実施のしやすさから見た優先度(◎・○)を付けています。もとになった「テレワークセキュリティガイドライン」第 5 版の方式は 7 つです。手引きは端末が会社支給か個人所有かで方式を分けるなど、分け方を変えています。ガイドラインの全体は、[総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod)にまとめています。 方式⑥のチェックリストには、VPN(会社のネットワークに外からつなぐ仕組み)を使う方式にある項目のうち 3 つがありません。そのうち記録に関わるのは、「オフィスネットワークに接続する際のアクセスログを収集する」(7-3)で、アクセスログは接続の記録のことです。在宅のオペレーターは会社のネットワークを通らずに管理画面へ入るので、会社のネットワークの側で入った記録を取る場面がありません。 ## 始める前に決める 4 つのこと ### 在宅で扱ってよいアカウント 手引きは、テレワークで使うシステムと、扱う重要な情報を把握することを挙げています(1-2)。運用代行会社なら、クライアントと媒体ごとに、預かっているアカウントの一覧を作ります。アカウントごとに、個人のデータ(EC の受注情報、広告の顧客リスト、SNS の DM など)を扱うかを書き添えます。招待で入るか、共有の ID で入るかも書きます。 個人のデータを扱うアカウントは、在宅では扱わない、または閲覧だけにする、と線を引く決め方があります。在宅で扱うことをクライアントに伝えておくかどうかも、ここで決めます。 ### 使う端末 手引きは、許可した端末だけをテレワークに使うよう周知し、端末と利用者を把握することを挙げています(1-1)。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版も同じ趣旨です。使ってよい機器の申請と承認の方法を決めて周知するよう勧めています。 私物のパソコンを使わせる場合、問題になるのは家族との共用です。IPA の「テレワークを行う際のセキュリティ上の注意事項」は、テレワークで使うパソコンをできる限り他人と共有しないよう求めています。共有せざるを得ない場合は、業務用のユーザーアカウント(パソコンにログインする利用者の区分。Windows や Mac の「ユーザー」)を別に作るよう書いています。 ブラウザーに管理画面へのログインが残っていると、同じユーザーでそのブラウザーを開いた人は、クライアントのアカウントにそのまま入れます。業務用のユーザーにパスワードをかけて分けておけば、家族は自分のユーザーのブラウザーを使うので、ログインしたままの管理画面には触れません。端末そのものを会社が管理する方法は、[私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser)で比べています。 ### ログインの渡し方 媒体に担当者を招待する仕組み([権限付与](/guides/agency-accounts/what-is-delegated-permission))があれば、オペレーターは自分のユーザーで入り、クライアントのパスワードは自宅のパソコンに入りません。共有の ID で入らせる場合は、パスワードを自宅のパソコンで入力させることになります。私物のパソコンは会社が管理していないので、ブラウザーに保存されたパスワードを会社の側で確かめることも消すこともできません。業務での保存の扱いは[ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work)で整理しています。 手引きは、テレワークで使うシステムに多要素認証を求めるよう設定することを挙げています(9-4)。多要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめることです。管理者の権限は、業務に必要な最小限の人に限るとも書いています(10-1)。共有の ID の多要素認証と、招待で付ける権限の種類は、クライアントが決めます。運用代行会社は、管理者ではない権限で招待するよう頼めます。招待で入るオペレーター自身のユーザーには、運用代行会社の側で多要素認証を求められます。共有の ID の確認コードの受け方は、[クライアントのアカウントの二段階認証を運用チームで受けるには](/guides/agency-accounts/client-two-step-verification-for-teams)で扱っています。 ### 端末に残してよいデータ 広告のレポートや EC の受注一覧は、管理画面からダウンロードできます。手引きは、端末には原則として重要な情報を置かないよう周知することを挙げています(8-4)。必要なときも、パスワードの設定やファイルの暗号化をしたうえで、一時的な保管だけを認める形です。 そこで、ダウンロードしてよいファイル、置き場所、消す時期を決めます。IPA の中小企業向けガイドラインも、私物の端末にダウンロードしてよいファイルの種類を決めて周知するよう勧めています。IPA の注意事項も、自宅で仕事をした後の業務ファイルの受け渡しと消し方を、所属先のルールに従うよう求めています。担当を外れる日に何を消すかまで決めておくと、確かめやすくなります。 ## 始めてから確かめる 2 つのこと ### 端末の状態 方式⑥のチェックリストから、端末と家の回線の項目を抜き出します。 1. ウイルス対策ソフトを入れ、常に検査する設定にする(2-1)。感染したパソコンでは、管理画面に入力した内容が盗まれるおそれがあるためです。 2. サポートが終わった OS やアプリを使わず、最新の更新を入れる(5-1、5-2)。直されない弱点が残るためです。 3. 離れるときは画面をロックする(4-2)。手引きは、自宅では家族など業務と関係ない人が画面をのぞきやすいと書いています。 4. 家の Wi-Fi は「WPA2」か「WPA3」の方式にし、推測されにくいパスワードにする(6-2)。通信の盗み見を防ぐためです。 方式⑥では、これらの多くが「〜するよう周知する」と書かれています。会社が設定するのではなく本人に頼む形なので、始める日に本人と画面で確かめ、その後も時期を決めて確かめ直します。 ### 誰がいつ入ったかを後で示せるか 管理画面に直接つなぐ形では、運用代行会社の手元に、オペレーターが入った記録が残りません。誤投稿や誤った設定のとき、クライアントに示せるのは媒体の履歴だけです。招待で入っていれば履歴は人ごとに残りますが、共有の ID では ID ごとにしか残らず、在宅の誰が操作したかを絞れません。追い方は[誤投稿・誤設定のあとに原因を追える運用と追えない運用](/guides/agency-accounts/tracing-misposts)で扱っています。 チェックリストに 7-3 がなくても、記録が要らないわけではありません。ガイドライン第 5 版は、クラウドサービスにログインした後の記録を取ることを、管理者の基本対策に挙げています(J-5)。そこで、最初に作ったアカウントの一覧を見直し、共有の ID で入るアカウントを在宅で扱わせるかを決め直します。媒体の履歴を運用代行会社の側の誰が見られるかも、クライアントと確かめておきます。 手引きは、事故のときの対応手順と連絡先を決めて周知することも挙げています(7-1)。在宅のオペレーターが異変に気づいたとき誰に連絡し、運用代行会社がいつクライアントに伝えるかも、ここで決めておきます。 ## よくある質問 **在宅のオペレーターに私物のパソコンを使わせてよいですか** 手引きは私物のパソコンを使う方式を禁じておらず、方式ごとにチェックリストを用意しています。家族と共用するなら業務用のユーザーを分け(IPA)、重要な情報は原則として残さないと決めてから使わせます。 **自宅から管理画面に入った記録は会社に残りますか** 管理画面に直接つなぐだけでは、運用代行会社の側には残りません。残るのは媒体の履歴で、招待で入っていれば人ごと、共有の ID なら ID ごとの記録になります。 **クライアントの顧客リストを自宅に保存してよいですか** 手引きは、端末には原則として重要な情報を置かず、必要なときもパスワードや暗号化をしたうえで一時的な保管に限るとしています。保存してよいファイル、保存先、消す時期を先に決めます。 **家族と共用のパソコンでは何をしますか** IPA は、共有せざるを得ないなら業務用のユーザーアカウントを別に作るよう求めています。管理画面の場合、同じユーザーのブラウザーにログインが残っていると、家族が開いても入れます。 ## 参考資料 - [総務省「中小企業等担当者向けテレワークセキュリティの手引き(チェックリスト)」第 3 版(令和 4 年 5 月)](https://www.soumu.go.jp/main_content/000816096.pdf) - [総務省「テレワークセキュリティガイドライン」第 5 版(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) - [総務省「テレワークにおけるセキュリティ確保」](https://www.soumu.go.jp/main_sosiki/cybersecurity/telework/) - [IPA「テレワークを行う際のセキュリティ上の注意事項」](https://www.ipa.go.jp/security/anshin/measures/telework.html) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 在宅のオペレーターに、家のパソコンにパスワードを残していないか、顧客リストをダウンロードしていないかを聞いて回る作業を、Junify を通すアカウントではなくします。導入時にクライアントと相談してパスワードを変え、Junify だけが持ちます。オペレーターはスマホで本人確認をして入り、パスワードを知りません。ダウンロードはアカウントごとに止められ、誰がいつ入ったかは運用代行会社に人ごとに残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 運用代行の作業記録を、クライアントにどう報告するか 媒体の操作履歴から日時・担当者・操作を抜き出して報告に添えます。媒体の履歴で担当者まで分からない共有 ID のアカウントは社内の作業記録で補い、各行がどちらに基づくかを書き分けます。 更新日: 2026-10-13 作業報告で「誰が・いつ・何をしたか」を示す材料は 2 つあります。媒体(Google 広告や LINEヤフー広告などのサービス)が残す操作履歴と、運用代行会社が自分でつける作業記録です。報告では、各行がどちらから取ったものかを書き分けます。媒体の履歴は担当者の申告によらずに残る記録で、作業記録は社内の申告だからです。以下は毎月の定例の報告の話です。事故のあとの報告と、預かり方ごとに記録に残るものの違いは[誤投稿・誤設定のあとに原因を追える運用と追えない運用](/guides/agency-accounts/tracing-misposts)にまとめています。 ## クライアントが作業の記録を求める理由 預かる業務に個人データの取扱いが含まれると、クライアントは個人情報保護法 25 条により、委託先を監督する義務を負います。個人情報保護委員会のガイドライン(通則編)3-4-4 は、監督の中身として 3 つの措置(委託先の選び方、委託契約、委託先での扱いの把握)を挙げています。記録に関係するのは、そのうち 2 つです。1 つは、委託元が扱いの状況を把握できることを委託契約に盛り込むことです(同 (2))。もう 1 つは、定期的な監査などで、契約が守られているかを調べて評価することです(同 (3))。どちらも「望ましい」という書き方なので、報告の頻度や形は契約で決まります。作業報告に記録を添えてほしいという依頼は、この把握の方法の一つと読めます。個人データを扱わない投稿代行では、記録を求める根拠は契約と取引の慣習になります。どちらに当たるかは[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)で整理しています。 運用代行会社の側にも、記録をつける理由があります。ガイドラインの別添 10-3(2) は、取扱いのルールが守られているかを確かめるために、利用状況などを記録することも重要としています。記録の手段の例は、システムの記録の整備や業務日誌の作成です。記録する項目の例示には、担当者の情報システムの利用状況(「ログイン実績、アクセスログ等」。誰がいつ入り、何を見たかの記録)が含まれています。社内で残した記録を、そのまま報告の材料にできます。 ## 媒体の操作履歴で分かること Google 広告・Meta・LINEヤフー広告・Shopify には、誰が何を変えたかを残す画面があります。公式ヘルプで確かめた範囲を並べます。 | 媒体と画面 | 「誰が」の欄に出るもの | さかのぼれる範囲 | ファイルで取り出せるか | | --- | --- | --- | --- | | Google 広告の変更履歴 | 変更したユーザーのメールアドレス | 過去 2 年 | ヘルプに記載なし | | Meta 広告マネージャのアクティビティ履歴 | 変更した人の名前 | ヘルプに記載なし | ヘルプに記載なし | | Meta Business Suite のビジネス履歴 | 操作した人の名前と ID | 期間を選んで書き出す(上限は記載なし) | CSV(全権限が要る) | | LINEヤフー広告(検索広告)の操作履歴 | 操作したビジネス ID | 今日を含め 366 日前まで | できる(管理権限か登録更新権限が要る) | | Shopify のストアのアクティビティログ | 操作した担当者・アプリ・チャネル | 最大 250 件 | できない | 表の「全権限」は、Meta のビジネスポートフォリオ(広告アカウントやページをまとめて管理する画面)のすべてを管理できる権限です。「ビジネス ID」は、LINEヤフーの事業者向けサービスに入るための ID です。Meta のビジネス履歴に残るのは、メンバーの追加や役割の変更、パートナーへのアクセスの付与などです。広告の中身の変更を確かめるときは、広告マネージャのアクティビティ履歴を開きます。 表を報告に使うときに気をつける点は 3 つあります。 - 「誰が」の欄は、ログインした ID の単位です。Google 広告ヘルプは、変更したユーザーを確かめられるのは、他のユーザーが「各自のログイン情報を使用して」入っている場合だと書いています。 - 担当者の操作でない行が混ざります。自動ルールや媒体の仕組みによる変更は、担当者ではない名前で出ます。Google 広告では「Google 広告システム」など、Meta 広告マネージャではルール名、Shopify では「Shopify」です。LINEヤフー広告では、更新者が「LINEヤフー株式会社」、更新ソースが「SYSTEM」と出ます。 - 名前は後から消えることがあります。Meta 広告マネージャでは、広告アカウントから外されたメンバーの変更が「Meta」と表示されます。 ## 共有 ID のアカウントで担当者を示す方法 1 つの ID を担当チームで使っているアカウントでは、媒体の履歴の「誰が」はその ID だけです。担当者の名前は、運用代行会社の側の記録で補います。作業記録には、操作のたびに、日時・アカウント・担当者・操作の内容・誰の依頼かを書きます。 作業記録は本人の申告なので、つけ忘れた操作は残りません。そこで、月に一度、媒体の履歴と作業記録を日時で並べて照らし合わせます。媒体の履歴にあって作業記録にない行は、担当者が記録をつけなかった操作か、同じ ID を使うクライアント側の操作です。その行は担当者とクライアントに確かめ、確かめられなければ「担当者不明」のまま報告します。推定の名前を、確かな記録のように書くのは避けたいところです。 もっとも、照らし合わせは招待に切り替えるまでのつなぎです。招待の仕組みがある媒体では、担当者ごとに招待を受ければ、媒体が履歴を残す範囲で担当者が残ります。しかも、LINEヤフー共通利用規約と Meta の利用規約は、パスワードを他人に教えることを禁じています。照らし合わせに頼るのは、招待の仕組みがない媒体と、切り替えが済むまでのアカウントに限ります。招待の仕組みは[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で説明しています。 ## 報告に載せる項目 {: .checklist} 1. **対象の期間とアカウント** 報告がどの期間の、どのアカウントについてかを最初に書きます。 **なぜ** 操作のなかったアカウントも、操作がなかったと分かるようにするためです。 2. **そのアカウントに入れる人** 期間中に入れた担当者と、追加・外した日を書きます。Meta Business Suite では、全権限を持つメンバーが、メンバーごとの役割と前回のログイン日を書き出せます。 **なぜ** 操作の一覧に出る名前が、許された人の中にいるかを確かめられるようにするためです。 3. **操作の一覧** 日時・担当者・操作の内容(予算の変更、入稿、投稿、設定の変更など)を並べます。 **なぜ** 契約で任された範囲の作業だったかを、クライアントが確かめられるようにするためです。 4. **各行の出どころ** 媒体の履歴から取った行か、社内の作業記録から取った行かを書きます。 **なぜ** 確かめ直すべき行を、クライアントが見分けられるようにするためです。 5. **担当者の操作ではない変更と、照らし合わせで残った行** 自動ルール・媒体の仕組み・クライアント自身による変更と、担当者を確かめられなかった操作を別に書きます。 **なぜ** 担当者の作業に混ぜると、誰の操作かを取り違えて伝えることになるためです。 ## 記録を取り出す時期 媒体の履歴は、時間がたつと取り出せなくなります。さかのぼれる範囲は表のとおり媒体ごとに限りがあり、Shopify のストアのアクティビティログは書き出せません。そこで、報告のたびに媒体の履歴を取り出し(書き出せない画面は写し取り)、作業記録と一緒に社内に保管します。担当者を外す日は、外す前にその人の分を取り出します。Meta 広告マネージャのように、外したあとは名前が残らない媒体があるからです。こうしておけば、半年後に問い合わせを受けても、そのときの記録で答えられます。 ## よくある質問 **共有 ID での操作を、担当者名で報告できますか** 媒体の履歴には共有している ID しか出ないので、担当者名は社内の作業記録から書きます。報告では、その行が媒体の履歴ではなく作業記録に基づくことを書き分けます。 **媒体の操作履歴はどこまでさかのぼれますか** 媒体ごとに違います。公式ヘルプでは、Google 広告は過去 2 年、LINEヤフー広告の検索広告は今日を含め 366 日前まで、Shopify のストアのアクティビティログは 250 件までです。 **担当者を外したあと、履歴の名前はどうなりますか** Meta 広告マネージャでは、広告アカウントから外されたメンバーの変更は「Meta」と表示されます。担当者を外す前に、その人の操作を写し取っておきます。 **作業記録の報告は法律上の義務ですか** 個人データを扱う委託では、クライアントに委託先の監督義務があります。ただしガイドラインは、取扱状況の把握を契約に盛り込むことや定期的な監査を「望ましい」としており、報告の形は契約で決めます。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [Google 広告ヘルプ「変更履歴について」](https://support.google.com/google-ads/answer/19888?hl=ja) - [Meta ビジネスヘルプセンター「Meta広告マネージャで、Metaのテクノロジー上での広告のアクティビティ履歴を表示する方法」](https://www.facebook.com/business/help/289211751238030?locale=ja_JP) - [Meta ビジネスヘルプセンター「Meta Business Suiteでメンバーのアクセス許可とビジネス履歴をダウンロードする」](https://www.facebook.com/business/help/996373447409365?locale=ja_JP) - [LINEヤフー広告 ヘルプ「操作履歴とは【検索広告】」](https://ads-help.yahoo-net.jp/s/article/H000044760?language=ja) - [Shopify ヘルプセンター「Shopify管理画面のアクティビティログ」](https://help.shopify.com/ja/manual/shopify-admin/activity-logs) - [LINEヤフー「LINEヤフー共通利用規約」(第 1 章 15)](https://www.lycorp.co.jp/ja/company/terms/) - [LINEヤフー「ビジネスID利用規約」(ビジネス ID の利用に LINEヤフー共通利用規約が適用される旨)](https://terms2.line.me/business_id_terms?lang=ja) - [Meta「Meta利用規約」(3.1)](https://www.facebook.com/legal/terms) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 報告の前に、共有 ID の履歴の行ごとに誰の操作かを担当者に聞いて回る確認は、Junify で要らなくなります。導入時にクライアントと相談してパスワードを変え、Junify だけが持てば、入れるのは Junify を通した担当者だけです。誰がいつ開いたかが残り、媒体の履歴の日時と並べれば開いていた人が分かります。管理者が録画を付けたアカウントは、何をしたかを AI の要約つきで確かめられます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Yahoo!広告(現 LINEヤフー広告)を代理店や複数人で運用するときの権限付与 管理権限を持つ人が担当者のビジネス ID を招待し、管理・登録更新・参照の 3 種類から権限を選びます。代理店の MCC につないで任せる形もあります。どちらの形でもパスワードは渡さず、外すときは権限の削除かリンクの解除です。 更新日: 2026-10-13 LINEヤフー広告(旧称 Yahoo!広告)では、担当者一人ひとりのビジネス ID をアカウントに招待して権限を付けます。検索広告は 2026 年 4 月 1 日に「LINEヤフー広告 検索広告」へ名称が変わりました。ディスプレイ広告は 2026 年 4 月 1 日に LINE 広告と統合されましたが、検索広告もディスプレイ広告も Yahoo!広告からの移行の作業は要りません。 代理店に任せる形は 2 つで、担当者を 1 人ずつアカウントに招待する形と、代理店の MCC につないで任せる形です。MCC(マイクライアントセンター)は、複数のアカウントを束ねて管理するためのアカウントです。Google 広告の MCC とは別の仕組みです。権限ごとにできる操作は、検索広告のヘルプで確かめた範囲で書いています。権限付与の一般的な仕組みは[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で説明しています。 ## ログインの単位はビジネス ID 広告管理ツール(入稿や予算の設定を行う画面)には、一人ひとりの「ビジネス ID」でログインします。ビジネス ID は LINEヤフーの法人向けサービスに共通の ID です。ログイン方法は[LINE 公式アカウントを複数人・外部と運用するときの権限](/guides/agency-accounts/line-official-account-permissions)にまとめています。 LINEヤフー広告で気をつけるのはメールアドレスです。招待は、相手のビジネス ID に登録したメールアドレスと一致しないと送れません。従業員を加えるときは、本人がビジネス ID を作り、そのアドレスを管理権限を持つ人に伝えて招待を受けます。 1 つのビジネス ID を複数の担当者で使い回すのは避けたいところです。操作履歴(画面上で行った操作の一覧)の「更新者」の欄には、操作したビジネス ID が記録されます。共有していると、誰が予算や広告を変えたかを担当者まで絞れません。 ## 付与できる権限は 3 種類 権限は、広告アカウントや MCC ごとに付けます。種類は管理権限・登録更新権限・参照権限の 3 つです。検索広告の権限ごとの一覧と、MCC の操作一覧から、運用代行で差が出る操作を抜き出すと次のとおりです。 | 操作 | 管理権限 | 登録更新権限 | 参照権限 | | --- | --- | --- | --- | | キャンペーン・広告・キーワードの作成と変更 | ○ | ○ | — | | レポートの作成とダウンロード | ○ | ○ | ○ | | 操作履歴の表示 | ○ | ○ | — | | ユーザーの招待、権限の変更と削除 | ○ | — | — | | 入金とお支払い方法の設定 | ○ | — | — | | アカウントリンクの申請・承諾・解除 | ○ | — | — | 決め方の一例として、入稿と運用を行う担当者は登録更新権限、レポートだけを見る人は参照権限にします。支払いの設定とほかの人の招待は管理権限にしかないので、管理権限は渡す人を絞ります。アカウントの新規作成などは、会社ごとに 1 つある最上位の MCC(ルート MCC)の管理権限でしかできません。 ## 担当者を 1 人ずつ招待する 招待できるのは、そのアカウントの管理権限を持つ人です。代理店の社員など、他企業のビジネス ID も招待できます。管理権限を持つ人が「ツール」の「権限管理(ユーザー)」で「アカウントに招待」を選びます。権限とメールアドレスを入れて招待メールを送り、相手が承諾すると、付けた権限の範囲で操作できるようになります。 招待には次の決まりがあります。 - 1 つのビジネス ID に一度に権限を付けられるのは 1 つのアカウントだけ。同じ権限なら、1 つのアカウントに 20 件までのビジネス ID をまとめて招待できる - 招待メールは送り直せない。届かないときは、招待を取り消してから招待し直す 1 人の担当者が 10 社のアカウントを受け持つなら、招待も 10 回になります。 ## 代理店の MCC につないで任せる もう 1 つの形は、クライアントの広告アカウントを代理店の MCC につなぐ「アカウントリンク」です。 1. 代理店で MCC の管理権限を持つ人が、クライアントの広告アカウント ID を入れてリンクを申請する 2. クライアントで広告アカウントの管理権限を持つ人が、「権限管理(アカウントリンク)」で承諾する 申請は 30 日で消えるので、その間に承諾してもらいます。他社とつなげるのは広告アカウントだけで、他社の MCC はつなげません。1 つの広告アカウントの上に置ける MCC は、1 社につき 1 つ、会社が違えば合わせて 5 つまでです。 申請のときに「リンク目的」を選びます。「アカウント管理」は、MCC を通して管理・編集・参照を行うための目的です。「ライブラリー共有のみ」は、ディスプレイ広告のオーディエンスリスト(広告を出す相手の一覧)を共有するだけの目的です。公式ヘルプによれば、検索広告のアカウントを後者でつなぐと、何も操作できません。運用を任せるなら「アカウント管理」を選びます。 つないだあと、代理店の担当者は MCC に付いた権限でクライアントのアカウントを扱います。ログインのときは、基点となるアカウント(ベースアカウント)を選びます。MCC を選ぶと、その下のすべてのアカウントに MCC と同じ権限が当てはまります。 一方で、その MCC で入る担当者は、受け持ちでないクライアントのアカウントも開けます。代理店でルート MCC の管理権限を持つ人も、ルート MCC を選んでログインすれば、その広告アカウントを管理権限で扱えます。これは「アカウント管理」でつないだ場合です。担当を分けたいときは、クライアントごとに MCC を分けるか、広告アカウントに直接招待する形を選びます。 ## 担当者を外すとき 広告アカウントに直接招待した担当者は、そのアカウントの管理権限を持つ人が外します。「権限管理(ユーザー)」の「招待済みユーザー」でその人を選び、「一括操作」から「権限削除」を選びます。承諾前の招待は「招待中のユーザー」の「招待取り消し」で取り下げます。各担当者は自分のビジネス ID で入っているので、アカウントのパスワードを変える作業はありません。削除はアカウントごとに行います。 MCC に招待した担当者は、代理店で MCC の管理権限を持つ人が MCC から外します。公式ヘルプの削除の手順は MCC を名指ししていませんが、広告アカウントと同じ画面で行う形と読めます。そうであれば、担当交代でクライアントに頼む作業はありません。 契約が終わったときは、アカウントリンクを解除します。解除は MCC 側からも広告アカウント側からもでき、どちらも管理権限が要ります。クライアントは自社の側だけで、代理店の MCC を切り離せます。広告アカウントの管理権限を持つ人は、承諾後でもリンク目的を「ライブラリー共有のみ」に変えられます。検索広告のアカウントなら、リンクを残したまま MCC からの操作を止められます。 直接招待と MCC 経由が混ざると、担当交代のときに外す場所が人によって変わります。担当者ごとに、どのアカウントにどちらの形で入っているかの一覧があれば、外し忘れに気づけます。 ## 権限付与でまかなえないもの クレジットカードの登録には、管理権限に加えてお支払いセンター(支払いを管理する画面)の権限も要ります。代理店が支払いまで受け持つなら管理権限を渡してもらうことになり、その人はほかの人の招待もできるようになります。3 種類の権限の中では、この 2 つを切り分けられません。 もう 1 つは、クライアント側で招待やリンクの承諾が進まない場合です。その間は、受け取った ID とパスワードで直接ログインする運用が残ります。ただし LINEヤフー共通利用規約は、他人にアカウントやパスワードを開示したり提供したりすることを禁止事項に挙げています。担当者のビジネス ID のメールアドレスと付けてほしい権限をクライアントに伝え、招待への切り替えを急ぎます。預かり方の違いは[運用代行のクライアントアカウント管理](/guides/agency-accounts)で比べています。 ## よくある質問 **Yahoo!広告と LINEヤフー広告は別の媒体ですか** 検索広告は名称が変わっただけで、既存のアカウントをそのまま使えます。ディスプレイ広告は LINE 広告と統合されましたが、Yahoo!広告の利用者は移行不要です。 **代理店の担当者をクライアントのアカウントに招待できますか** できます。他企業のビジネス ID も招待できます。招待するのは、そのアカウントの管理権限を持つ人です。 **1 人の担当者を複数のアカウントにまとめて招待できますか** できません。一度に権限を付けられるのは 1 つのアカウントだけです。逆に、同じ権限なら 1 つのアカウントに 20 件までのビジネス ID をまとめて招待できます。 **担当者が辞めたら何をしますか** その人が入っている広告アカウントごとに、管理権限を持つ人が「招待済みユーザー」から権限を削除します。MCC に招待した人は代理店の側で外します。パスワードを変える作業はありません。 **参照権限の人に操作履歴を見せられますか** 見せられません。公式ヘルプでは、操作履歴の表示とダウンロードには管理権限か登録更新権限が要ります。 ## 参考資料 - [LINEヤフー for Business「【重要】広告プラットフォーム統合について」](https://www.lycbiz.com/jp/news/20250925/) - [LINEヤフー for Business「「LINEヤフー広告」プラットフォーム統合リリースについて」](https://www.lycbiz.com/jp/news/20260218/) - [LINEヤフー「LINEヤフー共通利用規約」(第 1 章 4.4、15)](https://www.lycorp.co.jp/ja/company/terms/) - [LINEヤフー「ビジネスID利用規約」(ビジネス ID の利用に LINEヤフー共通利用規約が適用される旨)](https://terms2.line.me/business_id_terms?lang=ja) - [LINEヤフー for Business「【録画配信】10分でまるわかり!LINEヤフー広告 検索広告 入門セミナー」](https://www.lycbiz.com/jp/seminar/ly-ads/searchads/ondemand/beginners10min) - [LINEヤフー広告 ヘルプ「権限管理機能とは」](https://ads-help.yahoo-net.jp/s/article/H000044371?language=ja) - [LINEヤフー広告 ヘルプ「権限管理機能に関するよくある質問」](https://ads-help.yahoo-net.jp/s/article/H000044488?language=ja) - [LINEヤフー広告 ヘルプ「アカウントに招待する」](https://ads-help.yahoo-net.jp/s/article/H000044364?language=ja) - [LINEヤフー広告 ヘルプ「アカウントに招待済みのユーザーの権限を確認、変更または削除する」](https://ads-help.yahoo-net.jp/s/article/H000044509?language=ja) - [LINEヤフー広告 ヘルプ「各権限による表示・設定可能項目について【検索広告】」](https://ads-help.yahoo-net.jp/s/article/H000044592?language=ja) - [LINEヤフー広告 ヘルプ「MCCアカウントと配下の広告アカウントにおける各権限と実施可能な操作一覧」](https://ads-help.yahoo-net.jp/s/article/H000044310?language=ja) - [LINEヤフー広告 ヘルプ「MCCアカウントとは」](https://ads-help.yahoo-net.jp/s/article/H000044414?language=ja) - [LINEヤフー広告 ヘルプ「MCCアカウントと広告アカウントの関連付け(アカウントリンク)について」](https://ads-help.yahoo-net.jp/s/article/H000047563?language=ja) - [LINEヤフー広告 ヘルプ「他企業へアカウントリンクを申請する」](https://ads-help.yahoo-net.jp/s/article/H000044511?language=ja) - [LINEヤフー広告 ヘルプ「他企業からのアカウントリンク申請を承諾・拒否する」](https://ads-help.yahoo-net.jp/s/article/H000044500?language=ja) - [LINEヤフー広告 ヘルプ「アカウントリンクを解除する」](https://ads-help.yahoo-net.jp/s/article/H000044398?language=ja) - [LINEヤフー広告 ヘルプ「ベースアカウントの選択と適用される権限について」](https://ads-help.yahoo-net.jp/s/article/H000047564?language=ja) - [LINEヤフー広告 ヘルプ「操作履歴とは【検索広告】」](https://ads-help.yahoo-net.jp/s/article/H000044760?language=ja) - [LINEヤフー広告 ヘルプ「従業員の新規登録」](https://ads-help.yahoo-net.jp/s/article/H000062048?language=ja) - [LINEヤフー広告 ヘルプ「ビジネスIDを統合する」](https://ads-help.yahoo-net.jp/s/article/H000054842?language=ja) - [LINEヤフー for Business マニュアル「ビジネスIDの作成」](https://www.lycbiz.com/jp/manual/line-ads/account_001/) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** 何社を受け持つ担当者でも、LINEヤフー広告に共有の ID は要りません。招待か MCC へのリンクで入れ、LINEヤフー共通利用規約もパスワードを他人に教えることを禁じています。Junify が引き受けるのは、同じ担当者のほかの媒体で、人ごとに招待できないアカウントです。導入時にパスワードを変えて Junify だけが持てば、交代時は割り当て(使ってよい人の指定)を外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # YouTube チャンネルを社内の複数人や運用代行会社と運用するときの権限 YouTube Studio の「チャンネルの権限」で、担当者のメールアドレスごとに管理者・編集者・閲覧者などの役割を付けて招待すれば、Google アカウントのパスワードを渡さずに任せられます。外すときは同じ画面でアクセス権を削除します。 更新日: 2026-10-13 YouTube のチャンネルは Google アカウントで管理されます。複数の人で運用するには、パスワードを教える方法のほかに、「チャンネルの権限」で担当者を招待する方法があります。チャンネルの権限は、YouTube Studio(チャンネルの管理画面)にある機能です。招待された人は自分の Google アカウントで入り、所有者が選んだ役割の範囲で操作します。この形は[権限付与](/guides/agency-accounts/what-is-delegated-permission)と呼ばれます。 ## パスワードを共有している状態で起きること YouTube ヘルプは、チャンネルの権限を「パスワードなどの機密性の高いログイン情報を共有するより安全」と説明しています。パスワードを知っている人は、チャンネルの削除や権限の付け外しを含め、所有者と同じ操作をすべてできます。 乗っ取りの入口も、知っている人の数だけ増えます。ヘルプは乗っ取りの原因の例として、ウイルスなどの不正なソフトと、サービスを装ったメールでパスワードを入力させる手口を挙げています。共有していれば、知っている全員のパソコンと受信箱がその入口になりえます。代行会社が管理する Google アカウントから乗っ取られた例もあり、経緯は[代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached)にあります。この例の原因は公表されていません。 ## チャンネルの権限の役割 役割は 7 つで、うち 2 つは収益データを見せない制限付きです。次の表は、ヘルプの表から主な操作を抜き出したものです。 | 役割 | 主にできること | できないこと | | --- | --- | --- | | 所有者 | チャンネルの削除を含む、すべての操作 | 所有者の役割を他の人に譲ること | | 管理者 | 権限の管理、動画の作成・公開・削除、ライブ配信の管理 | チャンネルの削除 | | 編集者 | チャンネル情報の編集、動画のアップロードと公開、ライブ配信の管理 | 公開済みの動画とチャンネルの削除、権限の管理 | | 編集者(制限付き) | 編集者と同じ | 編集者の制限に加え、収益データの閲覧 | | 字幕編集者 | 動画の字幕の追加・編集・公開・削除 | 字幕以外の編集とアップロード、収益データの閲覧 | | 閲覧者 | チャンネルの詳細と収益データの閲覧 | 編集、ライブ配信の管理 | | 閲覧者(制限付き) | 閲覧者と同じ | 閲覧者の制限に加え、収益データの閲覧 | 管理者は人を追加でき、公開済みの動画も消せます。そのため、決め方の一例として、管理者は社内の責任者に限り、運用代行会社の担当者には編集者を付ける形が考えられます。収益を見せる必要がなければ、制限付きを選べます。 ## 招待の手順とブランドアカウントの場合 招待は、所有者か管理者が YouTube Studio で行います。左側の「設定」から「権限」を開き、「招待」を選んで、相手のメールアドレスと役割を指定し「完了」を押します。送った招待は 30 日で期限が切れます。 ブランドアカウントは、複数の人がそれぞれ自分の Google アカウントから共同で管理できるアカウントです。チャンネルがブランドアカウントに結びついている場合は、先に「チャンネルの権限に移行」が要ります。移行は、ブランドアカウントのメインの所有者が行います。それまでのユーザーはチャンネルの権限にコピーされますが、役割を手で設定し直し、招待を送る必要があります。 ## 所有者を誰にするか チャンネルの権限の所有者は、その役割を他の人に譲れません。移すには次の手間がかかるので、所有者は運用代行会社ではなく企業側に置いておくと、契約が終わったときに所有権を移す手続きが要りません。 ### 個人の Google アカウントのチャンネル ブランドアカウントに結びついていないチャンネルでは、そのままでは所有者を変えられません。ヘルプは所有権を移す方法を「権限の設定ですべての役割を削除して、ブランド アカウントに変換します」と書いています。変換したあとは、次のブランドアカウントの手順で移すことになると読めます。 ### ブランドアカウントのチャンネル ブランドアカウントには、チャンネルの権限とは別に、ブランドアカウント自体の役割(メインの所有者・所有者・管理者など)があります。メインの所有者はブランドアカウントの側で移すので、チャンネルの権限を使っている場合は、移す前に権限を外す必要があり、全員を招待し直すことになります。 1. YouTube Studio の「権限」の画面で、チャンネルの権限を無効にする 2. 担当者全員を、ブランドアカウントに招待し直す 3. 移す先の人が、ブランドアカウントの所有者になってから 7 日以上たったあとで、自分をメインの所有者に設定する メインの所有者が退職するときも、その人の Google アカウントを削除する前に、この手順で移しておく必要があります。ヘルプは、メインの所有者のアカウントを削除するとチャンネルも削除されるとしているからです。ヘルプは、メインの所有者のほかにもう 1 人以上の所有者を置くことも勧めています。 ## 外すとき・担当が代わるとき 担当者を外すときは、所有者か管理者が同じ「権限」の画面で、その人の役割の下矢印から「アクセス権を削除」を選びます。担当者は自分の Google アカウントで入っていたので、パスワードを変える作業はありません。 担当交代では、後任が招待に応じてから前任者を削除すると、誰も入れない期間ができません。招待は相手が応じる必要があり、30 日で期限が切れるからです。 外し忘れを防ぐには、権限の一覧を定期的に見る必要があります。誰が権限を持っているか(名前とメールアドレス)を見られるのは、管理者と所有者だけなので、この確認は企業側の責任者が持つ形になります。 それまでパスワードを共有していた場合は、チャンネルの権限に切り替えた時点で、所有者の Google アカウントのパスワードを変えます。変えるまでは、知っている人が所有者として入れるからです。あわせて、所有者のアカウントに 2 段階認証(パスワードのほかにもう 1 つの方法でログインを確かめる仕組み)を設定します。ヘルプは、2 つ目の確認にパスキー(スマホなどの画面ロックで確かめる方式)を選ぶことを勧めています。 ## 権限でまかなえないもの 招待された人は、YouTube Music と YouTube Kids アプリを使えず、YouTube API(ほかのツールから YouTube を操作するための仕組み)でもチャンネルを管理できません。そのため、予約投稿や分析の外部ツールをチャンネルにつなぐ操作は、所有者のアカウントが要ると読めます。 この操作のためにパスワードを渡す形は、YouTube ヘルプが避けるよう求めています。乗っ取られたチャンネルの復元の案内で「パスワードやログイン情報を誰とも共有しないでください」と書き、チャンネルへは権限で承認したアカウントから入るよう求めているからです。外部ツールをつなぐ操作は、企業側の所有者が自分で行う分担にします。 記録の面では、招待された人の操作は 2 つに分かれます。動画の公開やチャンネルとしてのコメントはチャンネルの名前で行われ、検索・視聴・購入は担当者自身のアカウントで行われます。どの担当者がチャンネルとして何をしたかを後から確かめる方法は、チャンネルの権限のヘルプには書かれていません。誤投稿のあとに誰の操作かを絞るには、作業の分担と突き合わせることになりえます。 ## よくある質問 **運用代行会社に YouTube のパスワードを渡す必要はありますか** ありません。チャンネルの権限で担当者のメールアドレスを招待すれば、担当者は自分の Google アカウントで入ります。外すときも、パスワードを変える必要はありません。 **運用代行会社の担当者には、どの役割が合いますか** 決め方の一例は編集者です。動画の公開やライブ配信の管理ができ、公開済みの動画とチャンネルの削除、権限の管理はできません。収益を見せないなら編集者(制限付き)を選びます。 **担当者が代わったら何をしますか** 所有者か管理者が「設定」の「権限」で後任を招待し、後任が応じてから前任者のアクセス権を削除します。前任者は自分のアカウントで入っていたので、パスワードを変える作業はありません。 **ブランドアカウントのチャンネルでも使えますか** 使えます。先にメインの所有者がチャンネルの権限へ移行します。ブランドアカウントの既存のユーザーはコピーされますが、役割を設定し直して招待を送る必要があります。 **チャンネルの所有者を別の人に移せますか** チャンネルの権限の所有者の役割は、そのままでは譲れません。手順はブランドアカウントに結びついているかで分かれ、どちらの場合も、権限をいったん外して全員を招待し直す作業が要ります。 ## 参考資料 - [YouTube ヘルプ「チャンネルの権限を管理する」](https://support.google.com/youtube/answer/9481328?hl=ja) - [YouTube Help「Manage your channel permissions」](https://support.google.com/youtube/answer/9481328?hl=en) - [YouTube ヘルプ「ブランド アカウントのユーザー アクセス権からチャンネルの権限に移行する」](https://support.google.com/youtube/answer/9367690?hl=ja) - [YouTube ヘルプ「ブランド アカウントでチャンネルの所有者と管理者を変更する」](https://support.google.com/youtube/answer/4628007?hl=ja) - [YouTube ヘルプ「ブランド アカウントを管理する」](https://support.google.com/youtube/answer/7001996?hl=ja) - [YouTube ヘルプ「ハッキングされた YouTube チャンネルを復元する」](https://support.google.com/youtube/answer/76187?hl=ja) - [YouTube ヘルプ「YouTube チャンネルを保護する」](https://support.google.com/youtube/answer/9701986?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** YouTube ヘルプは、チャンネルには権限で承認したアカウントから入るよう求めているので、権限で運用します。Junify が受け持つのは、同じ担当者が並行して扱う SNS や広告のうち、パスワードを皆で使うアカウントです。導入時にパスワードを変えて Junify だけが持ち、担当者は見ないままログインします。交代のたびに配り直す作業は、割り当て(使ってよい人の指定)を外す操作に変わります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # クライアントのセキュリティチェックシートへの、運用代行会社の答え方 設問は個人情報保護委員会ガイドライン(通則編)別添の安全管理措置の項目に対応しています。現状をそのまま書き、共有 ID は管理方法まで書き、対応予定には期限と担当を添えます。 更新日: 2026-09-17 クライアントから届くセキュリティチェックシートは、設問の並びが会社ごとに違って見えます。それでも、個人情報保護委員会のガイドライン(通則編)別添「講ずべき安全管理措置の内容」の項目に対応づけて読めます。安全管理措置とは、個人データを守るために行う対策のことです。別添の項目は、取扱規律の整備(ルール作り)、組織的・人的・物理的・技術的安全管理措置(体制、従業員、場所や機器、システムの面での対策)、外的環境の把握(海外で扱う場合にその国の制度を知ること)です。対応づけると、預かったアカウントについて何を聞かれているかが分かり、答えに何を書くかが決まります。 ## チェックシートが届く理由 チェックシートに法令上の根拠があるのは、預かる業務に個人データの取扱いが含まれ、クライアントが委託先の監督を負う場合です(法 25 条)。ガイドライン(通則編)3-4-4(1) は、委託先を選ぶときに、委託先の安全管理措置が少なくとも委託元(仕事を出す側)に求められるものと同等であることを確かめるよう求めています。確かめるのは、別添「講ずべき安全管理措置の内容」の各項目が、委託する業務内容に沿って行われることです。これを「あらかじめ確認しなければならない」としています。チェックシートは、この「あらかじめ確認」を書面で行う手段の一つと読めます。 ガイドラインは、従業員 100 人以下の「中小規模事業者」向けに、手法の例示を別に示しています。しかし「委託を受けて個人データを取り扱う者」は、この中小規模事業者から除かれています(10 の※2)。EC の受注情報や広告の顧客リストを扱う委託先には、規模にかかわらず一般の例示が当てはまると読めます。 個人データを扱わない投稿代行に 25 条が当てはまるかは、[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)で扱っています。どちらの場合も答え方は同じです。 ## 設問と安全管理措置の対応 設問の例を、ガイドライン別添 10-2〜10-7 の項目に対応づけます。設問ごとに、どの項目に当たるかと、預かったアカウントについて答えに書くことを挙げます。 1. 「誰がどのシステムに入れるか管理しているか」は、10-6(1) のアクセス制御(誰がどこに入れるかを決めること)と、10-3(3) の取扱状況を確認する手段(アクセス権を有する者)に当たります。答えには、預かっているアカウントの一覧があること、担当者ごとに入れるアカウントが決まっていることを書きます。 2. 「ID を複数人で共有していないか」は、10-6(2) のアクセス者の識別と認証(誰が入ったかを見分け、本人と確かめること)に当たります。答えには共有 ID の有無を書き、あるなら対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰が使ったかを残す方法を続けます。 3. 「退職・異動時にアクセス権を削除しているか」は、10-3(1) の従業者と役割の明確化、10-6(1) のユーザー ID に付与するアクセス権による限定、法 24 条の従業者の監督に当たります。答えには、交代時の手順(招待の取り消し・パスワード変更の依頼・ツール上での利用停止)と、反映を確認する方法を書きます。 4. 「アクセスログ・操作記録(誰がいつ何をしたかの記録)を取得しているか」は、10-3(2) の規律に従った運用(ログイン実績、アクセスログ、業務日誌)に当たります。答えには、預かり方ごとに何が誰単位で残るかを書きます。共有 ID では ID 単位にとどまることも書きます。 5. 「業務に使う端末を管理しているか」は、10-5(2)(3) の機器の盗難・持ち運び時の防止と、10-6(3) のセキュリティ対策ソフトと最新化に当たります。答えには、会社支給か私物か、私物なら何を求めているかを書きます。 6. 「従業者への教育・規程はあるか」は、10-4 の従業者の教育と、10-2 の取扱規律の整備に当たります。答えには、研修の頻度、就業規則等の秘密保持事項、取扱規程の有無を書きます。 7. 「事故発生時の報告体制はあるか」は、10-3(4) の漏えい等事案(情報漏れなどの事故)に対応する体制に当たります。答えには、責任者への報告経路と、クライアントへ連絡するまでの手順を書きます。 8. 「再委託(受けた仕事の一部を別の会社や個人に出すこと)の有無と管理」は、3-4-4(3) の再委託の事前報告・承認に当たります。答えには、フリーランス等に業務を出しているか、その人のアカウントの扱いを書きます。 9. 「個人データを保管する国・サービスを把握しているか」は、10-7 の外的環境の把握(外国で個人データを取り扱う場合、その国の制度を把握したうえで対策を行う)に当たります。答えには、個人データを扱う媒体のうち海外の事業者が運営するものと、その媒体でのデータの保管先を確かめた方法を書きます。 ガイドラインは、例示の全てを行わなければならないわけではなく、適切な手法は例示に限られないとも述べています(10 の冒頭)。この対応づけは「何を聞かれているか」を読むためのものです。例示と同じ手法を採っていないことが、そのまま不備になるわけではありません。 ## 答え方の型 書き方は 3 つの型に収まります。 第一に、現状をそのまま書きます。「はい」「いいえ」の欄しかない設問でも、備考に事実を添えます。「アクセス権の削除」の設問なら、誰が・いつ・何で確かめるかまで書きます。たとえば「担当者の交代時に、権限付与のアカウントはクライアントに招待の取り消しを依頼する。アクセス管理ツールのアカウントは、ツール上でその担当者の利用を止める。反映は翌営業日に一覧で確認している」のように書きます。 第二に、共有 ID があるなら、有無ではなく管理方法を書きます。共有 ID が残る理由は媒体側の制約にあり、[運用代行のクライアントアカウント管理](/guides/agency-accounts)で述べたとおり、運用代行会社の側だけでは解消できません。であれば、対象・範囲・変更手順・記録の方法を書きます。「共有 ID あり。対象は◯媒体の◯アカウント。パスワードを知るのは担当 2 名と管理者。担当交代時はクライアントに変更を依頼。利用は作業記録で管理」の形です。 第三に、「対応予定」と書くのは、現状を別に書いたうえで、期限・担当・完了時の連絡方法を添えられるときに限ります。「権限付与への切り替えを 2026 年 12 月までに、管理部門が担当し、完了時に書面で報告する」の形です。現状と予定を分けて書くのは、次の確認の時点で予定のままでも、選定時の回答が事実と違ったことにならないためです。 ## 正直に書くことの意味 正直に書く理由は、確認が一度で終わらないことにあります。ガイドライン 3-4-4 は、委託契約に、取扱状況を委託元が把握できる内容を盛り込むことが望ましいとしています。また、定期的な監査などで契約内容がどの程度実施されているかを調べ、評価することが望ましいとしています。選定時と把握の方法としては、個人データを取り扱う場所に赴くこと、またはこれに代わる合理的な方法(口頭による確認を含む)を挙げています(※3)。選定時のチェックシートで書いた内容は、その後の監査や訪問、担当者への口頭の確認で突き合わせられます。チェックシートで「共有なし」と答えた会社が、監査の場で共有 ID の存在を説明することになれば、回答が事実と違っていたことを別に説明することになります。チェックシートは、預かっているアカウントの一覧を設問の形に書き写す文書です。一覧が正確なら回答は一覧から作れ、監査で見せるものも同じ一覧になります。 ## よくある質問 **なぜ運用代行会社にチェックシートが届くのですか** ガイドラインが、個人データの取扱いを委託するクライアントに、委託先の安全管理措置(情報を守る対策)が自社と同等かを委託前に確かめるよう求めているためです。 **共有 ID があるときはどう答えますか** 有無ではなく管理方法を書きます。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰が使ったかを残す方法の 4 点です。 **従業員が少ない会社なら、中小規模事業者向けの例示で答えられますか** ガイドラインは中小規模事業者向けの手法を例示していますが、委託を受けて個人データを取り扱う者はその対象から除かれています。委託先の立場では一般の例示で読むことになります。 **「対応予定」と書いてよい条件は** 現状を別に書いたうえで、期限・担当・完了時の連絡方法を添えられるときです。予定を現状のように書くと、後の監査で食い違います。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify を使うと、「ID の共有」の設問に、担当者はパスワードを知らず、誰がいつ使ったかは担当者ごとに記録される、と現状として書けます。退職・交代時の設問には、割り当てを外す手順を答えられます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント 楽天は担当者ごとの楽天 ID を店舗の管理者が承認し、Yahoo! はビジネスマネージャーでツール管理者が従業員のビジネス ID を登録します。どちらも担当者ごとに ID を持つ仕組みです。 更新日: 2026-09-17 楽天市場の RMS(店舗の管理画面)と Yahoo! ショッピングのストアクリエイターPro(同じく店舗の管理画面)は、どちらも管理画面に入る人を担当者ごとに登録する仕組みを持っています。運用代行会社がクライアントの店舗を扱うときは、この仕組みで代行会社の担当者を登録してもらいます。この形が[権限付与](/guides/agency-accounts/what-is-delegated-permission)に当たります。EC モールの管理画面には、受注情報(購入者の氏名・住所)が含まれます。そのため、個人データの取扱いの委託に当たると読め、クライアントから確認を受ける前提になります。委託の考え方は[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。 ## 楽天 RMS の楽天ビジネスログイン(R-Login) RMS へのログインは、楽天ビジネスログイン(R-Login)という仕組みで行います。ヘルプは、使い始めるまでの手順を 5 つの段階に分けています。 1. RMS を使うスタッフ全員が、楽天会員登録で自分の楽天 ID を取る(STEP1) 2. 責任者が利用規約に同意する(STEP2) 3. 管理者が R-Login の登録をする(STEP3) 4. 2 段階認証を登録する(STEP4) 5. 楽天 ID でログインして利用を始める(STEP5) このあとに、管理者が利用者を追加する手順と、利用者を承認して権限を設定する手順が続きます。 ID は 2 層あります。担当者一人ひとりの楽天 ID と、管理者が登録する店舗単位の R-Login ID・パスワードです。ヘルプは R-Login ID とパスワードを「企業・店単位の認証を行うもの」(店舗として本人確認をするためのもの)と説明しています。日々のログインについては「利用者は R-Login ID を使う必要はありません」としています。ログインは、楽天 ID とパスワードに加え、Viber(メッセージアプリ)に届く認証コードを入力する 2 段階認証で行います。信頼できる端末として登録した端末では、コードの入力を 14 日間省けます。 利用者の種別は「管理者」と「スタッフ」の 2 つです。スタッフを承認するときに、権限を 2 つから選びます。ページ編集や受注管理を行う「通常」か、ページ編集のみを行う「ダブルアカウント」(ヘルプの例は外注業者)です。ヘルプの目次と承認・権限設定のページにある表は次のとおりです。 | 種別 | 権限 | ヘルプの例 | 可能な作業例(ヘルプの説明) | | --- | --- | --- | --- | | 責任者 | 通常 | 社長・部長・事業主など | R-Login のユーザ名・パスワード変更、登録スタッフの承認・権限変更、サービス操作全般 | | 管理者(責任者と同一可) | 通常 | 店長 | 責任者の行とまとめて示されている | | スタッフ | 通常 | スタッフ | サービス操作全般 | | スタッフ | ダブルアカウント | 外注業者 | RMS のページ編集(R-Storefront)など | ダブルアカウントの権限は、RMS の中の機能ごとにさらに分かれます。ヘルプが挙げる区分は、R-Storefront + R-Mail、R-Backoffice を除く、R-Datatool を除く、R-Datatool のみ、の 4 つです。 FAQ は、R-Login では「スタッフ」ごとに使える機能を設定でき、設定する権限は管理者にあるとしています。通常権限のスタッフについて、RMS のどの機能を個別に制限できるかの一覧は、取得したヘルプにはありません。 運用代行会社が受け取る形は、FAQ の「編集は別会社に委託したい(ダブルアカウント)」に手順があります。まず、委託先の担当者が自分の楽天 ID を取ります。次に、店舗の管理者が委託先に R-Login ID とパスワードを伝えます(ヘルプはメール等で連絡しないよう求めています)。委託先の担当者自身が利用者登録をし、管理者が承認して権限分類を「ダブルアカウント」に設定します。受注管理まで請け負う場合は、同じ流れで通常権限のスタッフとして承認する形になると読めます。管理者が「利用者追加」から登録用 URL を担当者に送る手順もあります。どちらも登録作業は担当者本人が行います。 担当交代時は、管理者が利用者管理の画面でそのスタッフの状態を「削除」にします。一度削除した情報は元に戻せません。スタッフには承認時に有効期限を設定し、期限を過ぎたスタッフは楽天ビジネスログイン(R-Login)を使えなくなります。期限後も続ける場合は、「一時停止」になっている利用状態を「利用可能」に変更します。 店舗単位の R-Login パスワードは「90 日間おきにパスワード変更が必要」で、過去 4 回と同じパスワードは設定できません(パスワード変更のヘルプ)。STEP3 のページでは「定期的に変更していただく必要があります」と書かれています。変更のあとは「R-Login を使用しているスタッフ全員に、新しいパスワードをお伝えください」と案内されています。つまり、この ID はスタッフの間で共有する前提で作られています。 ## Yahoo! ショッピングのビジネス ID とストアクリエイターPro ストアクリエイターPro へのログインは、Yahoo! ビジネスセンターから行います。ログインには、Yahoo! JAPAN ビジネス ID(会社の従業員ごとに発行される仕事用の ID)と、それにつないだ Yahoo! JAPAN ID が要ります。FAQ によると、ストアクリエイターPro に登録されていないビジネス ID でログインすると「アクセス権限がありません」と表示されます。ビジネス ID の追加は「権限管理設定」メニューから行います。 ビジネス ID は、Yahoo! ビジネスマネージャー(ビジネス ID と権限を管理する画面)で、企業ごとに従業員単位で発行します。ビジネスマネージャーの権限は 3 種類です。 | 種別 | できること(ヘルプの説明) | | --- | --- | | 従業員 | ログインと、利用ツールに許可された権限の範囲での操作 | | ツール管理者 | 管理するツールについて、従業員(ビジネス ID)の追加、ツール利用者の追加・取り消し、ツール権限の設定・取り消し、ツール管理者の設定・取り消し | | 法人管理権限保持者 | 従業員の追加・情報変更、ビジネス ID の削除、法人管理権限の設定・取り消し、決済関連情報と法人情報の変更 | ツール管理者は各ツールに少なくとも 1 人置き、1 人が複数のツールの管理者を兼ねられます。ヘルプは「ツール管理者は、管理するツールの個人情報管理責任者の役割を担います」としています。 従業員の追加は、ツール管理者が行います。ビジネスマネージャーの該当ツールの管理メニューから「従業員新規登録」を開き、氏名とメールアドレスなどを入力し、ツール権限と法人権限を選んで登録します。登録した従業員に、認証用 URL を知らせるメールが届きます。本人がビジネス ID の認証を済ませて使い始めます。 取り消しは 2 段階です。ツール管理者は、該当従業員のツール権限を「ツール権限なし」にして、ツールの利用権限を取り消せます。完了すると、本人とツール管理者全員に確認メールが送られます。退職などで長期間使わなくなった従業員のビジネス ID は、法人管理権限保持者が削除できます。削除したビジネス ID は元に戻せません。企業にビジネス ID が 1 つしかない場合は削除できません。法人管理権限やツール管理権限が付いたビジネス ID は、先にその権限を外さないと削除できません。 ストアクリエイターPro の中で設定できる権限の種類は、公開されているヘルプでは確認できません。 ## 代行会社に渡す形 | | 楽天 RMS | Yahoo! ショッピング | | --- | --- | --- | | 担当者の登録 | 担当者が自分の楽天 ID で利用者登録し、店舗の管理者が承認して権限(通常・ダブルアカウント)を設定 | ツール管理者が従業員(ビジネス ID)として登録し、ストアクリエイターPro のツール権限を付ける | | 担当者側の準備 | 楽天 ID と Viber の 2 段階認証。登録時に店舗の R-Login ID とパスワード | ビジネス ID の認証と Yahoo! JAPAN ID の連携 | | 担当交代時 | 店舗の管理者が状態を「削除」にする。有効期限で止める形もある | ツール権限を「なし」にする。退職なら法人管理権限保持者がビジネス ID を削除 | | クライアント側の作業 | 承認と削除のたびに管理者の操作 | 代行会社の担当者をツール管理者にすれば、従業員の追加と取り消しは代行会社側でできる | Yahoo! で代行会社の担当者をツール管理者にする形は、クライアントへの依頼を減らせます。一方で、その担当者がヘルプの言う個人情報管理責任者の役割を負います。契約で誰がその責任を負うかを決めてから使う形です。 ## 共有 ID が残る場面 楽天では、担当者ごとのログインは楽天 ID で分かれます。しかし店舗単位の R-Login ID・パスワードは、利用者登録の時点で委託先に伝える必要があります。ヘルプ自体が、変更後に全スタッフへ伝えるよう案内する共有の ID です。90 日おきの変更のたびに、誰に伝えたかと、変更後に誰が知っているかを、店舗の管理者と代行会社の間でそろえる作業が発生します。 Yahoo! では、法人管理権限保持者の ID を代行会社に渡している場合、契約終了時に権限を外す作業が残ります。法人管理権限を取り消せないのは 2 つの場合です。サービスに支払い方法(クレジットカード情報)が設定されている場合と、そのビジネス ID に登録した住所が請求書の送付先になっている場合です。自分自身のビジネス ID からも外せません。そのため、先に支払い方法と送付先の設定を変える作業が要ります。 どちらのモールでも、権限付与を始めるにはクライアント側の操作が要ります。楽天では店舗の管理者による利用者の追加と承認、Yahoo! ではツール管理者による従業員の登録です。追加や登録をしてもらえない間は、受け取った ID をそのまま使う形が続きます。残った共有 ID の扱いは[運用代行のクライアントアカウント管理](/guides/agency-accounts)で整理しています。 ## よくある質問 **楽天 RMS の ID を代行会社と共有しても問題ありませんか** ヘルプには、編集を委託する外注業者を「ダブルアカウント」のスタッフとして登録する手順があります。委託先の担当者が自分の楽天 ID で利用者登録し、店舗の管理者が承認する形です。 **Yahoo! ショッピングで代行会社の担当者を追加するには** ツール管理者がビジネスマネージャーで従業員(ビジネス ID)として登録し、ストアクリエイターPro のツール権限を付けます。本人がビジネス ID の認証を済ませて使い始めます。 **担当者が辞めたら Yahoo! では何をしますか** ツール管理者がその人のツール権限を「なし」にします。長期間使わないなら法人管理権限保持者がビジネス ID を削除します。削除した ID は元に戻せません。 **楽天の R-Login パスワードはどのくらいで変わりますか** 店舗単位の R-Login パスワードは 90 日おきの変更が必要で、ヘルプは変更後に R-Login を使うスタッフ全員へ伝えるよう案内しています。日々のログインは各自の楽天 ID で行います。 ## 参考資料 - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ(目次)](https://glogin.rms.rakuten.co.jp/help/) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「STEP1 楽天会員登録をする」](https://glogin.rms.rakuten.co.jp/help/19_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「STEP3 管理者がR-Loginの登録をする」](https://glogin.rms.rakuten.co.jp/help/21_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「STEP5 楽天ビジネスログインでログインして、各サービスの利用を開始する」](https://glogin.rms.rakuten.co.jp/help/23_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「STEP5 管理者が利用者(別の管理者/スタッフ)を追加する」](https://glogin.rms.rakuten.co.jp/help/5_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「STEP7 管理者が利用者の承認する・権限設定する」](https://glogin.rms.rakuten.co.jp/help/6_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「R-Loginパスワードを変更する」](https://glogin.rms.rakuten.co.jp/help/7_01.html) - [楽天市場 楽天ビジネスログイン(R-Login)ヘルプ「よくあるご質問」](https://glogin.rms.rakuten.co.jp/help/12_01.html) - [Yahoo! ショッピング 出店案内「よくある質問」](https://business-ec.yahoo.co.jp/shopping/question/) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「従業員、ツール管理者、法人管理権限保持者の違い」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006538) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「ツール管理者について」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006535) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「ツール利用者の追加(ビジネスIDの新規追加)」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006542) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「ツール利用権限を取り消す」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006548) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「ビジネスIDの削除」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006523) - [Yahoo! JAPAN ヘルプセンター(Yahoo!ビジネスマネージャー)「法人管理権限の追加、交代、取り消し」](https://support.yahoo-net.jp/PccBizmanager/s/article/H000006517) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify は、店舗単位の R-Login のように担当者ごとの登録でまかなえないログインを担います。管理者がクライアントの ID とパスワードを登録し、担当者はパスワードを見ずにログインします。利用は担当者ごとに記録され、担当交代時は割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型 預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。 更新日: 2026-09-17 新規のクライアントとの商談で「御社にアカウントを預けて大丈夫か」と聞かれたときの答えは、自社の運用の説明です。説明は、預かり方ごとに 3 つの問いへ答える形に整えられます。預かり方の定義は[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にまとめています。 ## この質問の裏にある 3 つの問い クライアントがこの質問をするのは、自社の名前で投稿・出稿・受注が起きるアカウントを、社外の人に操作させることになるからです。漠然とした「大丈夫か」を分けると、聞きたいことは 3 つに分かれます。 1. 担当者はパスワードを知るか。知っていれば、退職後も本人の記憶に残り、回収できないためです。 2. 誰が使ったかは残るか。誤投稿や誤設定が起きたときに、原因を人まで追えるかが決まるためです。 3. 担当交代で何が起きるか。辞めた人が入れる状態が残るかどうかと、クライアント側に何を頼まれるかが決まるためです。 預かる業務に個人データの取扱いが含まれる場合、クライアントは委託先の監督を負います(個人情報保護法 25 条。[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access))。個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託前に委託先の安全管理措置(個人データを守るための対策)を確かめることを求めています。確かめる方法としては、個人データを取り扱う場所に赴くこと、またはこれに代わる合理的な方法(口頭による確認を含む)が挙げられています(3-4-4 の※3)。そのため、商談での説明も選定時の確認の一部として扱われうると考えて話すことになります。 ## 預かり方ごとの答えの型 3 つの問いへの答えは、預かり方で決まります。自社の運用がどの型に当たるかをアカウントごとに把握していれば、答えは表から読めます。 | 問い | 権限付与 | ID とパスワードの共有 | アクセス管理ツール | | --- | --- | --- | --- | | 担当者はパスワードを知るか | 知らない。担当者は自分のユーザーで入る | 知っている。共有している全員が知る | 知らない。管理者がツールに登録し、担当者はツール経由で入る | | 誰が使ったかは残るか | 媒体に担当者単位で残る(媒体が履歴を残す範囲で) | 媒体には ID 単位でしか残らない。人は作業記録から推定する | ツールに担当者単位で残る。媒体側は ID 単位のまま | | 担当交代で何が起きるか | クライアント側(または代理店側の管理アカウント)で招待を取り消す。パスワードは変えない | クライアントにパスワード変更を依頼し、残る全員に配り直す | ツール上でその担当者の利用を止める。クライアント側の操作は要らない | 権限付与では「知らない・残る・招待の取り消しを頼む(パスワード変更は不要)」です。アクセス管理ツールでは「知らない・残る・クライアントの操作は要らない」です。共有 ID では「知る・残らない・パスワード変更を頼む」になります。共有 ID が残る理由は媒体側の制約にあります。それでも、運用代行会社が決められる範囲(知っている人の範囲、変更の手順、記録の方法)は決めていることを、この表に添えて話します。 ## 答えの根拠を一覧に置く 商談での答えに根拠を持たせるのは、[運用代行のクライアントアカウント管理](/guides/agency-accounts)で述べた、預かっているアカウントの一覧です。この一覧があれば、アカウントごとに預かり方を決め、担当者と記録の残り方を把握していることを、文書で示せます。 一覧を根拠にするのは、説明が後のチェックシートや監査で突き合わせられるためです([クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/guides/agency-accounts/answering-security-questionnaires))。商談で話した内容、チェックシートに書いた内容、監査で見せる内容が同じ一覧から出ていれば、食い違いは起きません。 見せるのは一覧の項目の構成だけで、ほかのクライアントの行は見せません。他社のアカウントの扱いを見せることは、その他社との秘密保持に反しうるためです。 ## 避けたい答え方 説明の組み立てを保つために、避けたい答え方が 3 つあります。 ### 共有 ID が残っているのに「共有はしていません」と言う 後のチェックシートや監査で共有の事実が出れば、商談での説明と食い違います。代わりに話すのは、共有が残る媒体側の理由と、知っている人の範囲・変更の手順・記録の方法です。 ### 「この媒体は担当者ごとに権限を出せます」と媒体の仕組みを言い切る 説明は公式ヘルプに基づくもので、媒体の仕組みは後から変わります。「公式ヘルプでは」と根拠を添えて話し、媒体側の仕組みと、クライアント側の設定(招待の操作は所有者が行うこと)を分けます。 ### 「事故は起きません」と言う 預かり方が決めるのは、誰が操作したかを追えるかと、辞めた人が入れる状態を残さないかです。誤投稿を防ぐ仕組みは別にあります。代わりに話すのは、起きたときに何を報告でき、交代時に何をするかです。 ## よくある質問 **商談でどこまで自社の運用を話しますか** 預かり方ごとの 3 問(パスワードを知るか・誰が使ったかが残るか・交代時に何が起きるか)への答えまでです。ほかのクライアントの名前や個別のアカウントは出しません。 **共有 ID で運用していることは商談で話しますか** 媒体側の制約で共有が残る場合、その事実と管理方法(知っている人の範囲・変更手順・記録)を話します。後のチェックシートや監査で共有の事実が出れば、説明と食い違います。 **口頭の説明は法令上の確認に当たりますか** 個人データを扱う委託では、ガイドラインは委託先の確認方法に口頭による確認を含めています(3-4-4 の※3)。商談での説明も選定時の確認の一部として扱われうると考えて話します。 **一覧はクライアントに見せるものですか** 見せるのは項目の構成です。ほかのクライアントの行は見せません。アカウントごとに預かり方・担当者・記録の残り方を把握していることを、文書で示せます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify を使っているアカウントについては、3 問に「担当者はパスワードを知りません。誰がいつ使ったかは担当者ごとに残ります。交代時は割り当てを外します」と答えられます。権限付与ができない媒体でも、この答えを変えずに済みます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Google 広告の MCC(クライアント センター)で代理店アクセスを整理する クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。 更新日: 2026-09-17 Google 広告には、代理店が複数のクライアントのアカウントをまとめて扱うための MCC(クライアント センター)アカウントがあります。[権限付与](/guides/agency-accounts/what-is-delegated-permission)の 3 つの要素(権限の種類・招待・取り消し)がこの媒体で揃っていることは定義記事に書きました。この記事では MCC を使うときの実際の作業を扱います。クライアントのアカウントのリンク(MCC につなぐこと)、担当者ごとのユーザー、担当交代時の操作、MCC 側とクライアント側の分担です。書いている事実は、Google 広告ヘルプで確認した範囲です。 ## MCC とクライアントのアカウントのリンク MCC は、Google 広告ヘルプでは「代理店などのお客様が、複数の Google 広告アカウントを簡単に管理するためのツール」と説明されています。既存のアカウントをリンクしても、元の履歴はそのまま残ります。クライアント側のユーザーは従来のログイン情報でアクセスできます。統合請求(複数のアカウントの請求を MCC でまとめて受ける設定)を設定しない限り、請求方法と支払い方法は変わりません。 リンクの操作は両側で 1 回ずつ要ります。MCC の管理者が「サブアカウントの設定」からクライアントの顧客 ID(アカウントごとの番号)を入力し、リンクのリクエストを送ります。クライアント側のアカウントの管理者が「管理者」メニューの「アクセスとセキュリティ」の「管理者」タブで承認または拒否します。 リンクの解除は MCC 側からもクライアント側からもでき、どちらも管理者権限が要ります。解除すると MCC からそのアカウントにアクセスできなくなりますが、履歴は保持されます。MCC が支払い元となる月次請求を設定していた場合は、解除後に広告掲載が停止します。MCC の共有タグ(広告の成果を測るために Web サイトに置く仕組み)を使っている機能にも影響が出ます。サイトを訪れた人に再び広告を出すためのリマーケティング リストや、複数のアカウントにまたがる成果の計測(クロスアカウントのコンバージョン トラッキング)です。契約終了で解除する前に、請求とタグの状態を確認します。 ## 担当者ごとのユーザーと MCC のアクセス権 MCC を使う代理店では、担当者を置ける場所が 2 つあります。MCC 自体のユーザーとして招待する形と、クライアントのアカウントに直接招待する形です。担当者を MCC のユーザーにしておけば、招待も削除も代理店側で完結します。 MCC のユーザーのアクセス権(Google 広告での権限の呼び名)は、クライアント側の Google 広告アカウントのアクセス権とは別に定義されています。クライアント側の 5 段階は定義記事に書きました。違いは「階層の管理」ができるかどうかです。階層の管理とは、クライアント アカウントのリンクと解除、ユーザーの招待とアクセス権の変更といった管理操作を指します。 | アクセス権 | できること(公式ヘルプの説明) | | --- | --- | | 管理者 | アカウントのすべての部分を表示、編集、管理する(階層の管理を含む) | | 標準 | アカウントのすべての部分を表示、編集、管理する(階層の管理を除く) | | 読み取り専用 | MCC アカウントを閲覧する。リンクされたクライアント アカウントの閲覧、レポートの実行、通知メールの受信 | | メール専用 | MCC アカウントの通知メールを受信する | | 請求情報 | お支払い情報を表示、編集する(同じヘルプの詳細表では「お支払いに関するアクセス権限」と表記) | 入稿と運用を行う担当者は標準、レポートだけを見る人は読み取り専用、リンクとユーザーを扱う責任者だけを管理者にすると、業務に要る範囲に収まります。 招待は「管理者」メニューの「アクセスとセキュリティ」から、メールアドレスとアクセス権を指定して送ります。相手が承諾すると招待者に通知が届きます。自分のアクセス権の段階を超えるアクセス権は付与できないので、管理者権限を渡せるのは管理者だけです。 ヘルプの規定ではありませんが、ユーザーは担当者ごとに 1 つにしておきたいところです。複数の担当者が 1 つの Google アカウントを共有して MCC に入ると、Google 広告側の記録がその 1 つのアカウント単位になるからです。誰の操作かを分けられません。 管理者の人数については、Google 広告アカウントのアクセス権のヘルプが、管理者をもう 1 人追加することを勧めています。管理者が 1 人しかいないと、その人が対応できなくなったときにタグにアクセスできなくなる可能性があるためです。MCC 側からクライアント アカウントの管理者を入れ替えられるかは、これとは別の条件で決まります。同じヘルプによれば、MCC がそのアカウントのオーナー(後の節で説明)に設定されている場合は別です。その MCC の管理者権限を持つ人が、アカウント内のユーザーのアクセス権と管理者を編集できます。 ## 担当交代のときに MCC 側でできること 担当者が MCC のユーザーであれば、担当交代の操作は MCC 側だけで済みます。MCC の管理者が「アクセスとセキュリティ」でその人を探し、「アクション」列の「アクセス権を削除」を選びます。まだ承諾されていない招待は同じ列の「取り消し」で無効にできます。クライアントに頼む作業はありません。 担当者をクライアントのアカウントに直接招待していた場合は、削除の操作をそのアカウントの管理者が行います。クライアント側の管理者に頼むか、次の節のオーナー権限を MCC が持っていれば MCC の管理者が行えます。どちらの形で入れたかをアカウントごとに控えておかないと、担当交代時に削除の漏れが出ます。 ## MCC 側とクライアント側のどちらで何ができるか MCC が既存のアカウントにリンクしただけでは、そのクライアント アカウントの「オーナー権限」(MCC がそのアカウントの所有者として扱われる権限)は付与されません。オーナー権限は、クライアント アカウントの管理者権限を持つユーザーだけが MCC に指定でき、所有者として指定できる MCC は 1 つに限られます。所有者に指定された MCC の管理者は、クライアント アカウントに対して次の操作ができます。管理者ユーザーの招待と削除、ユーザーへの管理者権限の付与と取り消し、リンク リクエストの承認と拒否などです。 | 操作 | MCC 側 | クライアント側 | | --- | --- | --- | | リンクのリクエスト | MCC の管理者が送る | — | | リンクの承認・拒否 | 所有者 MCC の管理者なら可 | アカウントの管理者 | | リンクの解除 | MCC の管理者 | アカウントの管理者 | | MCC のユーザーの招待・変更・削除 | MCC の管理者 | — | | クライアント アカウントの直接ユーザーの招待・削除 | 所有者 MCC の管理者のみ | アカウントの管理者 | | オーナー権限の指定・解除 | 所有者 MCC の管理者は無効化(外す)と譲渡(別の MCC に渡す)が可 | アカウントの管理者が指定 | | 請求と支払い方法 | 統合請求を設定した場合に MCC 側 | 設定しなければ従来どおり | リンクの承認とオーナー権限の指定はクライアント側の管理者の操作です。代理店側で先に整えておけるのは、MCC のユーザー構成とアクセス権の割り当てまでです。 ## 権限付与でまかなえないもの リンクの承認はクライアント側の管理者の操作です。それが進まない間は、受け取った ID とパスワードで直接ログインする運用が残ります。その状態で何を決めておくかは[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 もう 1 つの制限は数の上限です。1 つのメールアドレスに結びつけられる Google 広告アカウントは、MCC を含めて最大 20 個です。担当者を各クライアントのアカウントに直接招待していくと、クライアント数が増えたところでこの上限に当たります。MCC のユーザーとして入れておけば、担当者のメールアドレスに結びつくのは MCC だけで済みます。 ## よくある質問 **MCC にリンクすればクライアントのパスワードは不要ですか** 不要です。担当者は自分の Google アカウントで MCC にログインし、リンクされたアカウントを扱います。リンクの承認はクライアント側のアカウントの管理者が行い、パスワードのやり取りは生じません。 **担当者が辞めたとき、クライアントに何か頼みますか** MCC のユーザーとして招待していれば、MCC 側でその人のアクセス権を削除するだけで済みます。クライアントのアカウントに直接招待していた場合は、そのアカウントの管理者に削除を頼みます。 **リンクを解除するとクライアントのデータは消えますか** 消えません。アカウントの履歴は保持され、Google 広告の機能はそのまま使えます。ただし MCC が支払い元の月次請求を設定していた場合、解除後はそのアカウントの広告掲載が停止します。 **MCC の「標準」と「管理者」は何が違いますか** 階層の管理ができるかどうかです。管理者はアカウントのリンク・解除やユーザーの招待・削除を行えます。標準はそれ以外の表示・編集・管理ができます。 **MCC の管理者は 1 人で足りますか** 公式ヘルプは、タグの管理が途切れないよう、管理者をもう 1 人置くことを勧めています。MCC 側からクライアント アカウントの管理者を編集できるのは、その MCC がオーナーに設定されている場合です。 ## 参考資料 - [Google 広告ヘルプ「クライアント センター(MCC)アカウント: Google 広告 MCC アカウントについて」](https://support.google.com/google-ads/answer/6139186?hl=ja) - [Google 広告ヘルプ「アカウントとクライアント センター(MCC)アカウントのリンクについて」](https://support.google.com/google-ads/answer/7456530?hl=ja) - [Google 広告ヘルプ「アカウントを MCC アカウントにリンクする」](https://support.google.com/google-ads/answer/7459601?hl=ja) - [Google 広告ヘルプ「MCC アカウントからアカウントのリンクを解除する」](https://support.google.com/google-ads/answer/7456531?hl=ja) - [Google 広告ヘルプ「クライアント センター(MCC)アカウントからのアカウントのリンク解除について」](https://support.google.com/google-ads/answer/7458428?hl=ja) - [Google 広告ヘルプ「MCC アカウントのユーザー アクセス権について」](https://support.google.com/google-ads/answer/9977851?hl=ja) - [Google 広告ヘルプ「MCC アカウントのユーザーとアクセス権を管理する」](https://support.google.com/google-ads/answer/7459700?hl=ja) - [Google 広告ヘルプ「クライアント アカウントのオーナー権限について」](https://support.google.com/google-ads/answer/7456532?hl=ja) - [Google 広告ヘルプ「Google 広告アカウントのアクセス権の概要」](https://support.google.com/google-ads/answer/9978556?hl=ja) - [Google 広告ヘルプ「Google 広告アカウントへのアクセス権を管理する」](https://support.google.com/google-ads/answer/6372672?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Google 広告のように MCC で担当者を招待できる媒体では、権限付与を使うのが先です。Junify は、権限付与のない媒体や、クライアント側の承認が進まず ID とパスワードを預かるしかないアカウントで使います。管理者が登録し、担当者はパスワードを見ずにログインし、利用は担当者ごとに記録されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 運用担当者の交代・退職時のアカウント引き継ぎチェックリスト 交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。 更新日: 2026-09-17 担当者の交代や退職は、クライアントから預かったアカウントに入れる人が変わる出来事です。何をすればよいかは、預かり方で違います。預かり方は、権限付与・ID とパスワードの共有・アクセス管理ツール(担当者にパスワードを見せずにログインさせる道具)の 3 つです。このうち共有 ID は、クライアントに変更を頼まなければ止められません。預かり方の全体像は[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## 交代前に確かめること 交代前の作業は、退職日や異動日が決まった時点で始めます。本人がいるうちにしかできない確認を先に済ませます。退職後に「どのアカウントを使っていたか」を聞くことはできません。クライアント側の操作を待つ工程は、この段階で依頼を出します。 1. 本人が使っているアカウントを、預かっているアカウントの一覧から抜き出します(自社の操作)。一覧がなければ本人と一緒に作ります。一覧に載っていないアカウントは当日の作業から漏れ、退職後も入れる状態が残ります。 2. アカウントごとの預かり方を確かめます(自社の操作)。当日の作業が型ごとに違うためです。権限付与は招待の取り消し、共有 ID はパスワード変更の依頼、アクセス管理ツールはツール上での利用停止です。 3. 権限付与の招待先が会社のメールアドレスか私用のアドレスかを確かめます(自社の操作)。私用のアドレスで招待されたユーザーは、会社のメールを止めても媒体に入れる状態が残ります。 4. 二段階認証のコードの受け取り先を確かめます(自社の操作。変更の依頼先はクライアント)。コードが本人のスマホや電話番号に届く設定のままだと、本人がいなくなった日に誰も入れなくなります。受け取り先の変更はクライアント側の操作です。 5. 共有 ID のうち本人がパスワードを知っているものを書き出します(自社の操作)。パスワードは記憶から回収できないので、変更を依頼するクライアントと依頼の時期を決めておきます。 6. 後任を決め、権限付与なら後任の招待を、アクセス管理ツールなら後任がツール上で使える設定を先に済ませます(招待はクライアント、ツールは自社の操作)。取り消しと同時に後任が入れないと、投稿や入稿が止まります。 7. クライアントへの連絡の文面と時期を決めます(自社の操作)。招待の取り消しとパスワードの変更はクライアント側の操作で、交代の連絡は挨拶であると同時に依頼でもあるためです。 急な退職で本人に確認できない場合は、一覧が唯一の手がかりになります。一覧もなければ、クライアントごとに媒体のユーザー一覧と共有している ID を洗い直します。確かめた順に、クライアントへ依頼を出します。 ## 交代当日に行うこと 当日の作業は、預かり方ごとに「入れなくする操作」が違います。権限付与と共有 ID ではクライアント側の操作を待ち、アクセス管理ツールでは自社の操作で完結します。 1. 権限付与のアカウントは、本人の招待の取り消しを依頼し、後任の招待が有効なことを確かめます(クライアント、または代理店側の管理アカウントの操作)。招待は本人のユーザーに結びついていて、取り消すまで同じ権限で入れます。 2. 共有 ID は、パスワードの変更を依頼し、新しいパスワードを共有する範囲を決めて配ります(変更はクライアント、配布は自社)。本人が知っているパスワードそのものは、変える以外に無効にできません。 3. アクセス管理ツールでは、ツール上で本人の利用を止めます(自社の操作)。担当者はパスワードを知らないので、ツール上で止めればツール経由では入れません。 4. 二段階認証のコードの受け取り先を、本人のスマホや電話番号から会社の管理する先へ変えます(クライアントの操作)。そのままだと、後任のログインに要るコードが社外の端末にしか届きません。媒体によっては、その番号でパスワードの再設定もできます。 5. 本人が使っていた端末を回収します。または、私物端末のブラウザーに保存されたパスワードとログインしたままの状態を、本人と一緒に消します(自社の操作)。ブラウザーに保存されたパスワードは、変更前のものがそのまま端末に残ります。 6. 媒体にログイン中の端末を切る操作があれば行います(媒体によってクライアントか自社の操作。手順は媒体別の記事で扱います)。回収できなかった端末に残るログイン状態を切るためです。 7. クライアントに交代を伝え、依頼した取り消しと変更の完了を確認します(自社の操作)。クライアント側で後回しになれば、入れる状態が続きます。 ## 交代後に確かめること 交代後の作業は 2 つです。当日の操作が反映されたかの確認と、次の交代に備える一覧の更新です。依頼したことと実施されたことは別なので、依頼の返事だけでは反映を確かめたことになりません。 1. 権限付与のアカウントは、媒体のユーザー一覧に本人の名前がないことを確かめます(自社の操作)。招待の取り消しが実施されたかは、媒体の一覧で分かります。 2. 共有 ID は、クライアントから変更完了の連絡を受け、新しいパスワードでの初回ログインが成功したことを確かめます(完了の連絡はクライアント、ログインは自社)。旧パスワードで入れないことは補助の確認です。記録が ID 単位なので、本人名義の記録の有無では確かめられません。 3. アクセス管理ツールは、利用者一覧に本人がないことを確かめます(自社の操作)。自社の操作なので、操作の記録と一覧の両方で確かめられます。 4. 権限付与とアクセス管理ツールのアカウントについて、交代後しばらく本人名義の記録がないことを見ます(自社の操作)。人単位の記録が残る預かり方に限ってできる確認で、取り消し漏れがあれば本人名義の記録として現れます。 5. 預かっているアカウントの一覧を更新します(自社の操作)。担当者名、パスワードを知っている人、二段階認証の受け取り先、招待先のアドレスを書き換えます。次の交代はこの一覧から始まります。 6. 秘密保持の義務を本人に確認します(自社の操作)。個人情報保護委員会のガイドライン(通則編)10-4 の例示によるもので、秘密保持に関する事項を就業規則等に盛り込むことが、人的安全管理措置(従業員に対する対策)の例として挙げられています。 ## 個人データを扱う委託で交代の手順が持つ意味 預かる業務に個人データの取扱いが含まれる場合、運用代行会社は従業者に対する必要かつ適切な監督(個人情報保護法 24 条)を負います。従業員が個人データをきちんと扱っているか、確かめる義務です。個人情報保護委員会のガイドライン(通則編)は、組織的安全管理措置(体制やルールの面での対策)として、個人データを取り扱う従業者とその役割、取り扱う個人データの範囲を明確にすること(10-3)を例示しています。技術的安全管理措置(システム上の対策)としては、ユーザー ID に付与するアクセス権により従業者を限定すること(10-6)を例示しています。ID ごとに入れる範囲を決めて、扱う人を絞ることです。交代のたびに一覧と権限を更新する手順は、これらの対策を行っていることを示す材料になります。クライアントから取扱状況の確認を求められたときに、示せる根拠になります。 個人データを扱わない投稿代行にこの条文が当てはまるかは、[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)で扱っています。退職者がクライアントのアカウントに入れる状態を残さないという点で、手順は同じです。 ## よくある質問 **退職する担当者がパスワードを知っている共有 ID はどうしますか** 本人の記憶からは回収できないので、クライアントにパスワードの変更を依頼し、新しいパスワードを配る範囲を決めます。反映は、クライアントの完了連絡と新しいパスワードでの初回ログインで確かめます。 **交代の準備はいつから始めますか** 退職日や異動日が決まった時点です。二段階認証のコードの受け取り先や招待の取り消しはクライアント側の操作を待つので、本人がいるうちに一覧を確かめ、依頼を先に出します。 **急な退職で本人に確認できないときは** 預かっているアカウントの一覧が頼りになります。一覧がなければ、クライアントごとに媒体のユーザー一覧と共有している ID を洗い直し、順にクライアントへ依頼します。 **交代の手順は個人情報保護法と関係がありますか** 預かる業務に個人データの取扱いが含まれる場合、運用代行会社は従業者の監督(法 24 条)を負います。ガイドラインは、ID ごとに入れる範囲を決めて扱う人を絞る手法を例示しています。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify では担当者にパスワードを渡していないので、交代の日は管理者がその人の割り当てを外すだけです。導入時にパスワードを変えて Junify だけが持つ運用なら、以後はクライアントのアカウントに入れず、パスワード変更を頼む工程もなくなります。誰がいつ使ったかの記録は担当者ごとに残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # LINE 公式アカウントを複数人・外部と運用するときの権限 管理者が発行する認証用 URL で担当者ごとにメンバーを追加し、管理者か運用担当者の権限を持たせます。外部の運用代行会社も同じ形で追加でき、外すときはメンバーのリストから削除します。 更新日: 2026-09-17 LINE 公式アカウントの管理画面(LINE Official Account Manager)は、1 つのアカウントに複数のメンバーを登録して運用できます。[権限付与](/guides/agency-accounts/what-is-delegated-permission)の一般的な仕組みは定義記事にあります。この記事では、LINE 公式アカウントに特有の点と、外部の運用代行会社を入れて外すときの操作を扱います。特有の点とは、認証用 URL(メンバーを追加するための専用の URL)でメンバーを追加することです。書いている事実は、LINEヤフーの公式マニュアルとヘルプセンターで確認した範囲です。 ## ログインの単位はビジネス ID 管理画面と管理アプリへのログインには「ビジネス ID」(管理画面に入るための ID)を使います。LINE Business ID のヘルプでは、ログイン方法として 3 つが挙げられています。普段使っている LINE アカウントでのログイン、メールアドレスだけで登録できるビジネスアカウントでのログイン、Yahoo! JAPAN ID でのログインです。ビジネスアカウントは LINE アカウントが不要で、業務用のメールアドレスで使えます。 外部の担当者を追加するときは、この選択が先に来ます。担当者が個人の LINE アカウントで登録すると、その人の私用のアカウントがクライアントの公式アカウントの権限を持つ形になります。会社のメールアドレスで作ったビジネスアカウントなら、私用の LINE と切り離せます。運用代行会社の側では、担当者に会社のメールアドレスでビジネスアカウントを作ってもらい、それをクライアントに伝える手順にしておくと揃います。 数の上限も確認しておきます。公式マニュアルによれば、1 人のユーザーが管理できる LINE 公式アカウントは 100 個までです。1 人の担当者が受け持つ公式アカウントが増える運用では、この上限に当たります。 ## 権限の種類 公式マニュアルでは、メンバーに付ける権限は「権限の種類」から選ぶとされています。ただし、権限の種類ごとにできる操作の一覧は、マニュアル上では画像として掲載されており、本文のテキストでは確認できませんでした。この記事では、公式ヘルプの本文で確認できた 2 つの権限と、その差として明記されている操作だけを書きます。 | 権限 | 公式ヘルプで確認できた操作 | | --- | --- | | 管理者 | 管理者の追加、認証済アカウント(LINEヤフーの審査を経たアカウント)の申請 | | 運用担当者 | 管理者の追加と認証済アカウントの申請はできない | ヘルプセンターの「管理者の追加⋅変更」は、管理者を追加するには管理者権限を持つアカウントでログインし、Web 版管理画面から操作する必要があるとしています。運用担当者では操作できません。認証済アカウントの申請も、LINEヤフーの公式コラムで、運用担当者ではできず管理者に依頼するように案内されています。メンバーの追加と、権限の変更・削除については、マニュアルの本文は操作できる権限を限定していません。運用担当者にどの操作が許されるかは、権限を付ける前に管理画面の「権限管理」で実際の表示を確認するほうが確実です。 ## メンバーの追加と認証用 URL メンバーの追加は招待メールではなく、認証用 URL の発行で行います。追加する側が「設定」の「権限管理」で「メンバーの追加」を選び、権限の種類を選んで「URL を発行」します。その URL をメールなどで相手に共有します。相手が URL にアクセスしてログインし「承認」すると、権限管理の画面にその人が表示されます。管理アプリからも「設定」の「権限」で同じ操作ができます。 認証用 URL には 3 つの決まりがあります。 - 発行から 24 時間で使えなくなる - 1 回の発行につき 1 人のユーザーだけ有効で、使い回しができない - 追加されるユーザー側も、LINE ログインのためのメールアドレス設定を済ませておく必要がある 1 つのアカウントに登録できるメンバーは、権限の種類を問わず 100 人までです。 URL は 1 人 1 回です。そのため、運用代行会社を追加するときは、会社宛に 1 つの URL を送るのではなく、担当者の人数分の URL を発行することになります。この手間を省くために、代行会社側で 1 つのビジネスアカウントを作って全員で使う形にすると、管理画面上のメンバーはその 1 つになります。誰が配信したかも、その単位でしか残りません。 ## 外部の運用代行会社を追加する形 クライアントが所有する公式アカウントに運用代行会社を入れる場合、操作の順序は次のようになります。 1. 運用代行会社が担当者の一覧(氏名とビジネスアカウントのメールアドレス)をクライアントに渡す 2. クライアントの管理者が担当者ごとに認証用 URL を発行して送る 3. 各担当者が 24 時間以内に URL を開いて承認する 権限をどちらにするかで、その後の運用が変わります。管理者で入れると、運用代行会社の側で管理者の追加までできます。半面、クライアントの権限管理に手が届く人が社外に増えるので、クライアント側でメンバーのリストを定期的に見る運用が要ります。運用担当者で入れた場合にメンバーの追加と削除をどちらが行えるかは、マニュアルの画像の一覧と管理画面の表示で確認します。 複数の公式アカウントを持つクライアントには、グループの権限で渡す形もあります。グループごと権限を渡すと、そのグループに入っている公式アカウントすべてに権限が及びます。一件ずつ渡す手間は省けますが、担当していないアカウントまで扱えることになります。クライアント数や店舗数の多い運用では、どのアカウントを誰が扱えるかの一覧が必要になります。 ## 担当者を外すとき すでに権限を持っているメンバーは、「権限管理」のメンバーのリストから権限の変更と削除ができます。担当交代や退職では、クライアント側の管理者、または管理者権限で入っている運用代行会社の責任者が、その人を削除します。各担当者は自分のビジネス ID で入っているので、公式アカウント自体のパスワードを変える作業は生じません。 外し忘れを防ぐには、クライアントごとに「誰をどの権限で入れたか」の一覧が要ります。管理画面のメンバーのリストは公式アカウント単位です。1 人の担当者が 10 社の公式アカウントに入っていれば、削除の操作も 10 か所になります。 ## 権限付与でまかなえないもの 公式ヘルプで運用担当者ではできないと明記されている操作、つまり管理者の追加と認証済アカウントの申請は、運用担当者で入っている運用代行会社では行えません。これらが業務に含まれるなら、管理者権限を渡してもらうか、都度クライアントに依頼する形になります。 もう 1 つは、認証用 URL の発行がクライアント側で進まない場合です。その間は受け取った ID とパスワードで直接ログインする運用が残ります。その状態で何を決めておくかは[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## よくある質問 **運用代行会社の担当者に個人の LINE を使ってもらう必要がありますか** ありません。管理画面のログインに使うビジネス ID は、LINE アカウントのほかに、メールアドレスだけで登録するビジネスアカウントでも作れます。会社のメールアドレスで登録すれば個人の LINE と切り離せます。 **管理者と運用担当者は何が違いますか** 公式ヘルプで確認できた範囲では、管理者の追加と認証済アカウントの申請は管理者だけができ、運用担当者ではできません。メンバーの追加を含む権限ごとの操作の一覧は、公式マニュアルでは画像で示されています。 **認証用 URL を複数の担当者で使い回せますか** 使い回せません。認証用 URL は 1 回の発行につき 1 人だけ有効で、発行から 24 時間で使えなくなります。担当者ごとに URL を発行します。 **担当者が辞めたら何をしますか** 管理者が「設定」の「権限管理」でメンバーのリストからその人を削除します。各担当者は自分のビジネス ID で入っているので、アカウントのパスワードを変える作業は生じません。 **1 つの LINE 公式アカウントに何人まで登録できますか** 権限の種類を問わず 100 人までです。逆に、1 人のユーザーが管理できるアカウントも 100 個までです。 ## 参考資料 - [LINEヤフー for Business「LINE公式アカウント(LINE Official Account Manager)権限設定マニュアル」](https://www.lycbiz.com/jp/manual/OfficialAccountManager/account-settings_permission/) - [LINE 公式アカウント ヘルプセンター「管理者の追加⋅変更」](https://help2.line.me/official_account_jp/web/pc?lang=ja&contentId=20011732) - [LINE Business ID ヘルプセンター「ログイン方法の違い」](https://help2.line.me/business_id/web?lang=ja&contentId=20011265) - [LINE 公式アカウント ヘルプセンター(ホーム。アカウントの作成・ログイン・上限)](https://help2.line.me/official_account_jp/web?lang=ja) - [LINEヤフー for Business「LINE公式アカウント(LINE Official Account Manager)グループマニュアル」](https://www.lycbiz.com/jp/manual/OfficialAccountManager/create-group/) - [LINEヤフー for Business「LINE公式アカウント「認証済アカウント」申請の注意点とよくある質問」](https://www.lycbiz.com/jp/column/line-official-account/technique/20190829/) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** LINE 公式アカウントのように担当者ごとにメンバーを追加できる媒体では、権限付与を使うのが先です。Junify は、権限付与のない媒体や、クライアント側の URL 発行が進まず ID とパスワードを預かるしかないアカウントで使います。管理者が登録し、担当者はパスワードを見ずにログインし、利用は担当者ごとに記録されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Meta(Facebook・Instagram)のビジネスポートフォリオで代理店に権限を付与する仕組みと、できないこと クライアントのポートフォリオに担当者を「人」として招くか、代理店のポートフォリオを「パートナー」としてつなぎます。ページ・広告アカウント・Instagram ごとに、許す操作(タスク)を付けます。取り消しは所有者側の操作です。 更新日: 2026-09-17 Meta のビジネスポートフォリオ(参照した開発者向けドキュメントでは Business Manager と表記)は、「アセット」を 1 つの入れ物にまとめる仕組みです。アセットとは、Facebook ページ・広告アカウント・Instagram アカウントなどの資産のことです。誰がどのアセットに何をできるかを、ポートフォリオで決めます。運用代行会社がクライアントのアセットを扱う方法は 2 つあり、どちらも[権限付与](/guides/agency-accounts/what-is-delegated-permission)の形になります。参照した資料は、Meta の開発者向けドキュメントと Facebook ヘルプセンターです。画面上の名称は資料の表記と異なることがあります。 ## 代理店を招く 2 つの方法 第一の方法は、クライアントのポートフォリオに代理店の担当者を「人」として追加する形です。開発者向けドキュメントでは、管理者がメールアドレスと権限の種類(ロール。Admin か Employee)を指定して招待を送ると説明されています。Meta がそのメールアドレスに招待メールを送ります。招待された担当者は、自分の Facebook アカウントでクライアントのポートフォリオに入り、割り当てられたアセットだけを操作します。 第二の方法は、代理店のポートフォリオを「パートナー」(開発者向けドキュメントでは agency)としてつなぎ、アセットを共有する形です。Business Asset Management の概要ページは、agency を次のように説明しています(原文は英語)。「他のビジネスが所有するアセットを管理またはアクセスできる種類のビジネス」です。代理店側から広告アカウントやページへのアクセスを、必要なタスク(許す操作の種類)を指定して申請できます。所有者側が承認するとアクセスが成立します。付与できるのは、そのアセットの所有者(OWNER)であるビジネスに限られます。 2 つの方法の違いは、誰の名簿で担当者を管理するかにあります。「人」として追加する形では、代理店の担当者一人ひとりがクライアントの名簿に載り、担当交代のたびにクライアント側の操作が要ります。パートナーの形では、クライアントは代理店のポートフォリオに対してアセットを共有します。そのため、担当者への割り当ては代理店側の管理者が自分のポートフォリオ内で行う形になると読めます。ただし、取得した資料で確認できるのは、自分のビジネスからユーザーを削除すると「そのビジネスのアセットへのアクセスも外れる」というところまでです。パートナー経由で受け取ったアセットの割り当て手順は書かれていません。 ## 権限の種類とアセットごとのタスク ポートフォリオの権限の種類(ロール)は 2 段階です。Admin は「ビジネス設定のすべてを管理でき、アカウントの変更や削除、人の追加・削除ができる」と説明されています。Employee は「ビジネス設定の情報をすべて見られるが、自分が管理者であるページや広告アカウントを追加する以外の変更はできない」と説明されています。 アセットへの権限は、ロールとは別に、アセットごとに「タスク」の組み合わせで付けます。 | アセット | 付けられるタスク | ドキュメントの説明 | | --- | --- | --- | | Facebook ページ | MANAGE・CREATE_CONTENT・MODERATE・ADVERTISE・ANALYZE | Admin(5 つ全部)・Editor・Moderator・Advertiser・Analyst(ANALYZE のみ) | | 広告アカウント | MANAGE・ADVERTISE・ANALYZE | Admin(キャンペーン・レポート・請求・権限のすべて)・General user(広告の閲覧・編集・作成)・Reporting only(成果の閲覧) | | Instagram アカウント | CONTENT・MESSAGES・COMMUNITY_ACTIVITY・ADVERTISE・ANALYZE | 投稿とストーリーズの作成・管理、DM の送受信、コメント対応、広告、分析にそれぞれ対応 | | カタログ | MANAGE・ADVERTISE | — | 運用代行の担当者に付けるタスクは業務に合わせて絞れます。投稿だけを任せるなら Instagram の CONTENT、広告運用だけなら広告アカウントの ADVERTISE と ANALYZE、レポートの閲覧だけなら ANALYZE、という形です。 ## ページ自体のアクセス許可の 3 種類 Facebook ページには、ポートフォリオのタスクとは別に、ページ自体のアクセス許可があります。ただし Facebook ヘルプセンターは、「ページがビジネスポートフォリオの一部である場合、アクセスレベルが異なります」と注記しています。ポートフォリオに入れたページでは、以下の区分がそのまま当てはまるとは限りません。ヘルプが挙げる区分は 3 つです。 Facebook へのアクセス許可を持つ人は、Facebook の画面でページに切り替えて操作でき、他の管理ツールからも扱えます。範囲は全権限と部分的権限に分かれ、全権限の人は設定の編集とアクセス許可の付け外しもできます。ヘルプは、全権限を与えた相手について「その人は管理者と同じアクセス許可を持つことになります」と注意しています。他の人への許可の付与、管理者を含む人のページからの削除、ページ自体の削除まで行える、という意味です。 タスクへのアクセス許可を持つ人は、Meta Business Suite や広告マネージャなどの管理ツールからページを管理します。「新しいページに切り替えたり、Facebookからページを管理したりすることはできません」と説明されています。運用代行の担当者に渡すのは、通常はこちらの形です。 コミュニティマネージャへのアクセス許可は、ライブ配信中のチャットの管理だけに絞った種類です。コメントの削除や報告、視聴者のチャット利用の 15 分間の停止、視聴の禁止、コメントの固定ができます。ページへの切り替えとページの管理はできません。 ページには、全権限を持つ人が少なくとも 1 人要ります。ヘルプは、全権限を持つ人がいなくなったページは自動的に利用解除され、削除予定になると説明しています。他の人に許可を与えたり外したりできるのも、全権限を持つ人だけです。 ## 招待された側にできないこと 権限付与で入った代理店には、所有者にしかできない操作が残ります。資料で確認できたものを挙げます。 - アセットの再共有: ページを共有された agency は「そのページを別のビジネスに再共有できない」と明記されています。再委託先(運用代行会社がさらに仕事を頼む先)に権限を渡すには、クライアントに直接付与してもらう必要があります。 - ページのアクセス許可の付け外し: 全権限のある Facebook へのアクセス許可を持つ人だけができます。タスクへのアクセス許可で入っている担当者は、同僚を追加できません。 したがって、担当者の追加が発生するたびに、クライアント側で全権限を持つ人の操作が要ります(パートナーの形なら代理店側の管理者の操作で済むと読めます)。この操作をクライアントの管理者の Facebook アカウントを借りて代理店が行う運用にすると、ID の共有に戻ります。共有が残る場面の整理は[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## 担当者・パートナーの削除 「人」として追加した担当者は、ポートフォリオの管理者が削除できます。削除すると「そのビジネスのアセットへのアクセスも外れる」と説明されています。外れるのはそのポートフォリオ経由で与えた権限だけです。同じ人が別の入り方(ページへの直接のアクセス権など)で持つ権限は残ります。 パートナーの解除は、所有者側が広告アカウントやページの agency を削除する操作で行います。Instagram アカウントの担当者の割り当ても、所有者側の操作で個別に外せます。 担当交代の実際の作業では、クライアントごと・アセットごとに「誰が、どの入り方で、どのタスクを持っているか」を一覧にしておかないと、外し漏れが分かりません。 ## よくある質問 **代理店を「人」で招くのとパートナーで招くのはどちらを選びますか** 担当者ごとの付け外しをクライアントに頼まずに済むのはパートナーの形です。ただし、パートナーは受け取ったページを別のビジネスに再共有できません。 **招待された担当者はクライアントのパスワードを知りますか** 知りません。担当者は自分の Facebook アカウントでポートフォリオに入り、許された操作(タスク)の範囲だけを操作します。パスワードを渡す場面は権限付与の外にだけ残ります。 **担当者が辞めたら Meta では何をしますか** ポートフォリオから削除するか、ページや広告アカウントの割り当てを外します。パートナーの形なら代理店側の管理者の操作で済むと読めます。「人」として招いた場合はクライアント側の操作が要ります。 **ページの全権限を代理店に渡しても問題ありませんか** ヘルプは、全権限を与えると相手が管理者と同じ許可を持ち、管理者を外したりページを削除したりできると注意しています。運用に必要なのは通常、タスクへのアクセス許可か部分的権限です。 ## 参考資料 - [Meta for Developers「Business Manager API: Get Started」](https://developers.facebook.com/docs/marketing-api/business-manager/get-started) - [Meta for Developers「Business Asset Management: Overview」](https://developers.facebook.com/docs/marketing-api/business-asset-management/overview) - [Meta for Developers「Business Asset Management: Ad Accounts」](https://developers.facebook.com/docs/marketing-api/business-asset-management/guides/ad-accounts) - [Meta for Developers「Business Asset Management: Pages」](https://developers.facebook.com/docs/marketing-api/business-asset-management/guides/pages) - [Meta for Developers「Business Asset Management: Instagram Accounts」](https://developers.facebook.com/docs/marketing-api/business-asset-management/guides/instagram-accounts) - [Meta for Developers「Business Asset Management: Business-to-Business Functions」](https://developers.facebook.com/docs/marketing-api/business-asset-management/guides/business-to-business) - [Facebook ヘルプセンター「About Facebook Page access」](https://www.facebook.com/help/289207354498410) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify は、Meta の権限付与でまかなえない部分を担います。担当者やページの追加のためにクライアントの管理者アカウントを借りる場面や、権限付与のない媒体では、管理者が ID を Junify に登録し、担当者はパスワードを見ずに使います。利用は担当者ごとに記録されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # Shopify・BASE などカート側のスタッフ権限と、運用代行会社への渡し方 Shopify はスタッフの招待か、パートナー向けのコラボレーターアカウントで渡します。BASE は「スタッフ権限管理 App」でスタッフごとにメニュー単位の権限を付けられます。どちらもオーナーの ID は渡しません。 更新日: 2026-09-17 この記事は、カート型の EC(モールに出店するのではなく、自社のネットショップを作れるサービス)の管理画面をクライアントから預かる場面を扱います。Shopify と BASE には、ストアオーナーの ID を渡さずに担当者を入れる仕組みがあります。[権限付与](/guides/agency-accounts/what-is-delegated-permission)の一般的な仕組みは定義記事にあります。この記事では Shopify と BASE の仕組み、運用代行会社に渡す形、外す操作、権限で足りないものを扱います。モールの店舗管理画面は扱いません。書いている事実は、各社の公式ヘルプで確認した範囲です。 ## Shopify のユーザーの種類とプランごとの上限 Shopify の管理画面に入るユーザーは、ストアオーナー、スタッフ、コラボレーターの 3 種類です。スタッフは「設定」の「ユーザー」からメールアドレスで招待し、「役割」で権限を決めます。役割は職務を表す権限のまとまりです。1 人に複数の役割を割り当てると、それぞれの許可が足し合わされます。招待は 7 日で期限切れになります。コラボレーターは、Shopify パートナー(Shopify のパートナープログラムに登録した事業者)がストアオーナーの承認を得て入るアカウントです。 | 種類 | 入り方 | 権限の決め方 | ユーザー数の上限 | | --- | --- | --- | --- | | ストアオーナー | ストアの所有者 | すべて | 1 人 | | スタッフ | オーナーか管理者役割の人などが招待 | 役割(複数可、足し合わせ) | 契約プランによる | | コラボレーター | パートナーがリクエストし、オーナーが承認 | 承認時に自動で作られた役割。オーナーが編集可 | 上限に数えない | スタッフとして招待できる人数は契約プランで決まります。公式ヘルプの「各料金プランの最大ユーザー数」では、Starter と Basic が 0 人、Grow が 5 人、Advanced が 15 人、Shopify Plus が無制限です。ユーザー機能そのものが Grow 以上でのみ使えます。コラボレーターアカウントと POS(店頭のレジ)専用のスタッフは、この総数に数えられません。 つまり、Basic 以下のプランのストアには、代行会社の担当者をスタッフとして入れる枠がありません。スタッフの枠がない以上、Shopify パートナーとしてコラボレーターで入らなければ、選択肢はオーナーの ID とパスワードを受け取る形に限られます。 ## コラボレーターアカウントで入る流れ コラボレーターの承認は、ストアオーナーが 4 桁のコラボレーターリクエストコードを渡すところから始まります。オーナーは「設定」の「ユーザー」の「セキュリティ」欄でコードを確認してパートナーに伝えます。新しいコードを生成すると古いコードは無効になります。 パートナーがコードを使ってリクエストを送ると、オーナーにメールと管理画面で通知が届きます。オーナーは「設定」の「ユーザー」でリクエストを承認または拒否します。承認時には、リクエストに含まれる権限をもとに自動で作られた役割が割り当てられます。この役割はオーナーが承認前に見直せ、承認後もいつでも変更できます。コラボレーターは、パートナーダッシュボード(パートナー向けの管理画面)または Shopify モバイルアプリからストアにログインします。パートナー側で 2 段階認証(パスワードに加えてもう 1 つの方法でログインを確かめる設定)を有効にしていないとログインできません。コラボレーターが 90 日以内にストアにログインしなかった場合、そのアクセス権は自動的に失われ、オーナーが「ユーザーを再有効化」で戻せます。 ## スタッフとコラボレーターを外すとき スタッフは「設定」の「ユーザー」で、無効化(再有効化できる)、ストアからの削除、端末の許可の取り消しができます。コラボレーターは同じ画面で「コラボレーターアカウントを削除」します。この操作は元に戻せず、再び入るにはパートナー側からリクエストを送り直します。 記録については、「ユーザー管理アクティビティログ」という画面に、ユーザーの作成・編集・削除と役割の変更が日時と実行者つきで残ります。ログイン履歴は、各ユーザーの最新 5 件について、日時、IP アドレス(接続元を示す番号)、ISP(接続に使った通信会社)、場所、ブラウザーと OS を表示します。記録が残る期間は公式ヘルプに明示されていません。 ## BASE の複数人管理 BASE で複数人がそれぞれのアカウントでログインするには「スタッフ権限管理 App」を使います。公式ヘルプはこの App を、ショップオーナーのアカウント情報を共有することなく、招待された複数のスタッフがショップの管理画面にログインできる仕組みと説明しています。BASE U の記事では、スタッフの人数に関わらず無料とされています。 招待はショップオーナーが App の「スタッフの招待」から送ります。スタッフのメールアドレスと、アクセスを許可するメニューを指定します。招待メールの有効期限は 14 日間です。スタッフは招待メールからスタッフアカウントを登録し、以後はスタッフ用のログインページからログインします。 権限はメニューごとに設定します。基本メニューは商品、注文、顧客、データ、デザイン、PAY ID アプリ、過去のお問い合わせの 7 つです。これに加えて、オーナーがインストール済みの対応 App を許可できます。許可されていないメニューはスタッフには操作できず、権限はいつでも変更できます。上限は 1 ショップあたり 100 名です。 外すときは、オーナーが「スタッフ一覧」からそのスタッフを選んで削除します。削除後、そのスタッフはそのショップにログインできなくなりますが、ほかのショップへの参加は維持されます。 | | Shopify(スタッフ) | Shopify(コラボレーター) | BASE(スタッフ権限管理 App) | | --- | --- | --- | --- | | 前提 | Grow 以上のプラン | 代行会社が Shopify パートナー | 無料 App のインストール | | 招待の主体 | オーナーか管理者役割(Plus の組織では組織管理者なども) | パートナーがリクエスト、オーナーが承認 | ショップオーナー | | 権限の単位 | 役割(足し合わせ) | 役割(承認時に作られ、編集可) | メニューと App | | 上限 | 5・15・無制限 | 数えない | 100 名 | | 外し方 | 無効化または削除 | 削除(元に戻せない) | スタッフ一覧から削除 | | 操作の記録 | ユーザー管理の記録、ログイン履歴 5 件 | 同左 | 公式ヘルプで確認できず | ## 権限付与でまかなえないもの Shopify では、スタッフの招待、コラボレーターリクエストコードの共有、リクエストの承認、ユーザーの削除がストアオーナー(または管理者役割)の操作です。クライアント側でこれらの操作が進まなければ、担当者を入れる手段はオーナーの ID を受け取る形しか残りません。Basic 以下のプランで代行会社が Shopify パートナーでない場合も同じです。 BASE では、スタッフに権限を設定できる App はオーナーがインストール済みのものに限られます。BASE のスマートフォンアプリはショップオーナーのみ利用でき、スタッフアカウントでは使えません。これらが代行の範囲に含まれるなら、その部分だけオーナーの ID を使う運用が残ります。残った共有 ID について何を決めておくかは[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## よくある質問 **Shopify の Basic プランでもスタッフを招待できますか** 招待できません。Starter と Basic のユーザー数は 0 人で、ユーザー機能は Grow 以上で使えます。Basic 以下のストアには、Shopify パートナーとしてコラボレーターアカウントで入ります。 **コラボレーターはスタッフ数の上限に含まれますか** 含まれません。コラボレーターアカウントはユーザー総数に数えられません。POS(店頭のレジ)専用のスタッフも同様に数えられません。 **BASE のショップは複数人で管理できますか** できます。無料の「スタッフ権限管理 App」で、オーナーのアカウント情報を共有せずに最大 100 名のスタッフがそれぞれのアカウントでログインでき、権限はメニューごとに設定します。 **運用代行の担当者が辞めたら Shopify で何をしますか** スタッフなら「設定」の「ユーザー」で無効化または削除し、コラボレーターなら「コラボレーターアカウントを削除」します。コラボレーターの削除は元に戻せず、再開にはパートナー側からの再リクエストが要ります。 **誰が操作したかは記録に残りますか** Shopify にはユーザーの作成・編集・役割変更の記録と、最新 5 件のログイン記録があります。BASE の公式ヘルプでは、スタッフごとの操作の記録の機能は確認できませんでした。 ## 参考資料 - [Shopify ヘルプセンター「ユーザー管理」](https://help.shopify.com/ja/manual/your-account/users) - [Shopify ヘルプセンター「役割」](https://help.shopify.com/ja/manual/your-account/users/roles) - [Shopify ヘルプセンター「ユーザーを招待する」](https://help.shopify.com/ja/manual/your-account/users/invite-users) - [Shopify ヘルプセンター「各料金プランの最大ユーザー数」](https://help.shopify.com/ja/manual/your-account/users/users-plan-requirements) - [Shopify ヘルプセンター「管理画面からユーザーを管理する」](https://help.shopify.com/ja/manual/your-account/users/manage-users) - [Shopify ヘルプセンター「コラボレーターアカウント」](https://help.shopify.com/ja/manual/your-account/users/security/collaborator-accounts) - [Shopify ヘルプセンター「ユーザーアクティビティとログイン履歴」](https://help.shopify.com/ja/manual/your-account/users/security/user-management-activity-log) - [Shopify ヘルプセンター「ユーザーの 2 段階認証」](https://help.shopify.com/ja/manual/your-account/users/security/two-step-authentication) - [BASE ヘルプ「複数人にログイン権限を付与できますか」](https://help.thebase.in/hc/ja/articles/115000158282) - [BASE ヘルプ「【スタッフ権限管理 App】スタッフごとに権限を付与して、運営を協働する方法を教えてください」](https://help.thebase.in/hc/ja/articles/900006664706) - [BASE ヘルプ「アクセス権限を設定できるメニューには、何がありますか」](https://help.thebase.in/hc/ja/articles/900007657403) - [BASE ヘルプ「スタッフは、何名まで追加することができますか」](https://help.thebase.in/hc/ja/articles/5496271403161) - [BASE ヘルプ「アクセス権限を変更することはできますか」](https://help.thebase.in/hc/ja/articles/5496222417817) - [BASE ヘルプ「スタッフアカウントを削除したい場合、どうすればいいですか(スタッフ権限管理 App)」](https://help.thebase.in/hc/ja/articles/5525186303897) - [BASE ヘルプ「スタッフ(スタッフアカウント)は、何ができますか」](https://help.thebase.in/hc/ja/articles/5496053406745) - [BASE ヘルプ「ログインは、どこから可能ですか(スタッフ)」](https://help.thebase.in/hc/ja/articles/5550473823129) - [BASE ヘルプ「スタッフは、アプリからBASEを利用できますか」](https://help.thebase.in/hc/ja/articles/5496711751321) - [BASE U(BASE 株式会社)「複数人でのショップ運営に!担当者ごとの権限設定もできる「スタッフ権限管理 App」」](https://baseu.jp/24548) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Shopify のスタッフ招待やコラボレーター、BASE のスタッフ権限管理 App が使えるストアでは、権限付与が先です。Junify は、スタッフを招待できないプランのストア、オーナーの ID でしかできない操作、権限付与のないカートやモールで使います。管理者が登録し、担当者はパスワードを見ずにログインし、利用は担当者ごとに記録されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 誤投稿・誤設定のあとに原因を追える運用と追えない運用 報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。 更新日: 2026-09-17 誤投稿や誤設定が起きたあと、クライアントへの報告で問われるのは、何が起きたかに加えて、誰がいつ操作したかです。これに答えられるかどうかは、預かり方で事前に決まっています。預かり方の全体像は[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## 報告に必要な 3 つの情報 クライアントへの報告に要るのは、誰が・いつ・何を、の 3 つです。「何を」は事故の内容そのもので、投稿の削除や設定の戻しに要ります。「いつ」は影響の範囲を決めます。投稿が公開されていた時間や、誤った予算で配信された期間です。「誰が」は、再発防止策を原因の種類に向けるために要ります。 個人データの漏えい(外部への流出)を伴う事案では、この 3 つはガイドラインが定める手順と重なります。個人情報保護委員会のガイドライン(通則編)3-5-2 は、漏えい等事案(情報漏れなどの事故)が発覚した場合に行うべき 5 つの措置を定めています。そのうち (2) 事実関係の調査及び原因の究明(何が起きたかを調べ、原因を突き止める)、(3) 影響範囲の特定、(4) 再発防止策の検討及び実施が、この 3 つの情報に対応します。漏えいの事例としては、個人データを含むメールを第三者に誤送信した場合が挙げられています。設定ミスで、インターネット上で個人データを閲覧できる状態になっていた場合も同じです(3-5-1-2)。誤投稿・誤設定のように個人データを伴わない事故でも、報告の組み立ては同じです。 ## 共有 ID では担当者まで絞れない理由 共有 ID で担当者を絞れないのは、媒体の記録がログインしたユーザーの単位で残るためです。媒体は「どのユーザーがログインし、何を変更したか」を記録します。しかし、ここでいうユーザーは ID のことで、その ID を使っている人ではありません。3 人が同じ ID で入っていれば、媒体の記録上は操作者は 1 人です。記録からは、3 人のうち誰かとしか言えません。 時刻や接続元(どこから入ったかの情報)が残る媒体もあります。しかし、同じオフィスから同じ時間帯に働く担当者を、これで分けることはできません。在宅勤務で接続元が分かれていても、それは本人を特定する記録ではなく、状況証拠にとどまります。媒体が何をどの期間残すかは媒体ごとに違い、この記事では扱いません。 ## 権限付与とアクセス管理ツールで残るもの 預かり方ごとに、3 つの情報のどこまでが記録として残るかを並べます。 | 預かり方 | 誰が | いつ | 何を | | --- | --- | --- | --- | | 権限付与 | 招待された担当者のユーザー単位で媒体に残る | 媒体のログイン・変更の履歴に残る | 媒体が変更履歴を残す範囲 | | ID とパスワードの共有 | 共有した ID 1 つとしてしか残らない | 時刻は残るが、誰の操作か分からない | 媒体が変更履歴を残す範囲 | | アクセス管理ツール | ツールにログインした担当者単位で、いつどのアカウントを開いたかが残る | ツール側の記録に残る | 媒体が変更履歴を残す範囲 | 権限付与では、記録を残すのは媒体側です。担当者ごとの招待が成立している限り、「誰が」は媒体に残ります。[権限付与(アカウントを共有しないアクセス)とは](/guides/agency-accounts/what-is-delegated-permission)で述べた「担当者ごとに招待を受ける」が守られず、1 つのユーザーを複数人で使っていれば、記録の残り方は共有 ID と変わりません。 アクセス管理ツールでは、媒体の記録は共有 ID のまま(ID 単位)です。しかし、その前段でツールが「誰がいつどのアカウントを開いたか」を担当者単位で残します。媒体側の変更履歴と、ツール側の「そのとき誰が開いていたか」を時刻で突き合わせると、担当者まで絞れます。同じ時刻に同じアカウントを複数人が開いていた場合には、この突き合わせでも 1 人に絞れません。 ## 記録がないときの代わりの方法と限界 共有 ID で人単位の記録がない場合、代わりになるのは、作業記録(投稿カレンダー、入稿依頼のやり取りの記録、承認の履歴)、勤務時間、本人への聞き取りです。誤投稿の時刻に投稿の担当だった人と、その時間に勤務していた人を照らし合わせ、本人に確認します。 この方法には 3 つの限界があります。第一に、結果は推定であり、本人が心当たりを否定すれば確定できません。第二に、同じ時間帯に複数人が同じアカウントで作業していれば、勤務時間では絞れません。第三に、聞き取りは記憶に頼るので、事故から日が経つほど確かさが落ちます。クライアントへ報告するときは、推定であること、確定できない範囲を明記します。推定を確定のように報告し、後で覆ると、事故そのものより報告の信頼が失われます。 ## 再発防止で記録が果たす役割 記録が再発防止に要るのは、原因の種類を分けるためです。誤設定の原因は、担当者の見落としか、確認の手順がなかったことか、その担当者に本来要らない操作の権限があったことかで、対策が違います。見落としなら二重確認、手順の抜けなら承認の追加、権限の広さなら権限の絞り込みです。 誰が操作したかが分からないと、この区別ができません。原因が分からないままの対策は、向ける先を決められず、全員への注意喚起にとどまります。事故を生んだ条件はそのまま残ります。記録は、対策をどの原因に向けるかを決めるために要ります。 事故が起きたあとに記録を増やすことはできません。であれば、預かる時点で、アカウントごとに「誰が」がどこに残るかを、預かっているアカウントの一覧に書いておきます。それが、原因を追える運用の出発点になります。 ## よくある質問 **共有 ID でも媒体の記録を見れば誰が操作したか分かりますか** 分かりません。媒体はログインしたユーザーを見分けて記録するので、同じ ID で入った複数人は記録上 1 人です。時刻や接続元が残っても、同じ場所から同じ時間帯に働く人は絞れません。 **記録がないとき、報告はどう書きますか** 作業記録・勤務時間・本人への聞き取りから推定した結果を、推定であると明記して報告します。確定できない範囲を隠さないほうが、後で覆ったときの信頼の損失が小さくなります。 **権限付与にすれば操作内容まで分かりますか** 誰がいつ入ったかは人単位で残りますが、何をしたかは媒体が変更履歴を残す範囲に限られます。媒体ごとに違うので、預かる前に確認します。 **記録は再発防止にどう関係しますか** 原因が人の誤りか、手順の抜けか、権限の広さかを分けるのに要ります。分けられないと、対策は全員への注意喚起にとどまり、同じ条件が残ります。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify では、共有 ID のままでも担当者はパスワードを見ずにログインし、誰がいつどのアカウントを開いたかが担当者ごとに残ります。誤投稿の報告に要る「誰が・いつ」を、開いていた人が一人なら、勤務時間からの推定ではなく記録で示せます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 運用代行におけるアカウントの預かりとは クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。 更新日: 2026-09-17 運用代行におけるアカウントの預かりとは、クライアントが所有するアカウントを、運用代行会社の担当者が業務のために操作できる状態にすることです。対象は SNS 公式アカウント・広告アカウント・EC モールの店舗管理画面などです。所有者はクライアントのままで、運用代行会社は任された範囲で操作します。 ## アカウントの預かりとは何を指すか 預かりの対象は、クライアントの名前で投稿・出稿・受注が起きるアカウントです。「預かる」は、持ち主が変わるのではなく、操作できる状態を任されている、という意味で使います。 預かりの形は 3 つです。 1. 権限付与: 媒体(Google 広告や LINE などのサービス)の仕組みで、クライアントが担当者を招待する形 2. 共有: クライアントの ID とパスワードを受け取って使う形 3. アクセス管理ツール: 運用代行会社がツールを挟み、担当者にパスワードを見せずにログインさせる形 どの形でも、社外の担当者がクライアントのアカウントを操作する点は同じです。違いは、誰が ID とパスワードを持ち、誰が使ったかがどう残るかにあります。3 つの比較は[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 ## 委任の範囲とアカウントの扱いはなぜ分けて考えるのか 委任の範囲とは、運用代行会社が何をしてよいか(投稿・入稿・予算変更・受注処理など)で、契約で決まります。アカウントの扱いとは、担当者がどうやってそのアカウントに入り、誰がパスワードを持ち、誰が使ったかがどう記録されるかです。こちらは、契約で範囲を決めただけでは決まりません。両者を分けるのは、契約で範囲を狭く決めても、共有 ID で入っている限り、媒体上は所有者と同じ操作ができるからです。誰が操作したかも残りません。 したがって、契約書の範囲の取り決めとは別に、アカウントごとの扱いを決めておく必要があります。預かり方、パスワードを知っている人、記録の方法、担当交代時の手順の 4 つです。 ## 個人データの取扱いを伴うとき何が変わるか 預かる業務に個人データの取扱いが含まれる場合、クライアントは個人情報保護法 25 条により、委託先である運用代行会社を監督する義務を負います。条文の言葉では「必要かつ適切な監督」(委託先がきちんと扱っているか確かめること)です。個人情報保護委員会のガイドライン(通則編)3-4-4 は、この監督の内容として 3 点を挙げています。適切な委託先の選定、委託契約の締結、委託先における個人データ取扱状況の把握(委託先がどう扱っているかを知ること)です。同ガイドラインは、委託契約に、取扱状況を委託元が把握できる内容を盛り込むことが望ましいとしています。また、個人データの取扱いの委託を「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることと説明しています。そのため、運用代行という名称でも、EC モールの受注情報や広告の顧客リストを扱えば、この委託に当たると読めます。 この場合、運用代行会社はクライアントから安全管理措置(個人データを守るための対策)の確認を求められる立場になります。セキュリティチェックシート(委託先の安全対策を確かめる質問票)などがその形です。預かったアカウントを誰がどう使っているかも、確認の対象になります。25 条が及ぶかどうかは、業務に個人データの取扱いが含まれるかで決まります。投稿の作成と配信だけなら含まれないこともあります。DM への対応、キャンペーンの応募者情報、広告の顧客リストを扱えば含まれます。どちらに当たるかは、業務の中身をクライアントと確認して決めます。含まれない業務では、説明を求める根拠は契約と取引の慣習になります。 ## よくある質問 **契約で運用範囲を決めれば、アカウントの扱いも決まりますか** 範囲を決めただけでは決まりません。契約が決めるのは何をしてよいか(委任の範囲)で、どうやって入るか・誰がパスワードを持つか(アカウントの扱い)は別に決める必要があります。 **預かったアカウントの所有者は誰ですか** クライアントのままです。運用代行会社は任された範囲で操作する立場で、担当者を招待する権限付与でも、ID を共有する形でも、所有者は変わりません。 **SNS の投稿代行にも個人情報保護法の委託先監督は関係しますか** 預かる業務に個人データの取扱いが含まれるかで決まります。投稿の作成と配信だけなら含まれないこともありますが、DM 対応や応募者情報、顧客リストを扱えば含まれます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify では、クライアントから預かった ID とパスワードを運用代行会社の管理者が登録し、担当者はパスワードを見ずにログインします。誰がいつどのアカウントを使ったかは担当者ごとに記録され、担当交代時は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 権限付与(アカウントを共有しないアクセス)とは アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。 更新日: 2026-09-17 権限付与とは、アカウントの所有者が、自分の ID とパスワードを渡さずに、他の人にそのアカウントの操作を許可する仕組みです。許可された人は自分のユーザーとして入り、所有者が決めた範囲の操作だけができます。運用代行では、クライアントが所有者、担当者が許可される側です。 ## 権限付与とは何か 権限付与は、「アカウントに入る手段」と「アカウントの所有」を切り離す仕組みです。ID とパスワードを共有する形では、パスワードを知っていることが、そのまま所有者と同じ操作の権利になります。渡した相手が何をしても、媒体(Google 広告や LINE などのサービス)の上では所有者の操作として残ります。権限付与では、所有者が誰をどの範囲で許可するかを媒体上で決めます。許可された人は自分のユーザーで入るので、操作した人が人ごとに残ります(媒体が履歴を残す範囲で)。 ## どのような仕組みで成り立つのか 権限付与の仕組みは、媒体ごとに名称は違っても 3 つの要素でできています。 1. 権限の種類は、許可する操作の範囲を段階で決めるものです(閲覧のみ・編集・管理など)。媒体によっては「ロール」「役割」と呼びます。運用代行では、担当者の業務に必要な範囲だけを依頼します。 2. 招待は、所有者が相手のユーザーを指定して許可を出し、相手が受け入れて成立します。運用代行では、担当者ごとに招待を受け、1 つのユーザーを共有しません。 3. 取り消しは、所有者(または管理権限を持つ人)が許可を外すことです。運用代行では、担当交代時にアカウントごとに取り消しを依頼します。 媒体によっては権限の段階や取り消しの操作者が限られるので、預かる前に確認します。 ## 権限付与でできないことは何か 権限付与は、媒体がその仕組みを提供している範囲でしか使えません。ログイン手段が 1 組の ID とパスワードしかない管理画面では選べません。仕組みがあっても、招待された権限では変えられない設定や開けない画面があると、その操作のために所有者の ID を使う場面が残ります。 権限付与は所有者が招待する仕組みなので、始めるにはクライアント側の操作が要ります。招待の操作が進まないと、受け取った ID とパスワードをそのまま使う形が続きます。できない場合の預かり方は[運用代行のクライアントアカウント管理](/guides/agency-accounts)で整理しています。 ## Google 広告の例 Google 広告ヘルプでは、クライアント センター(MCC)アカウントは、代理店などが複数の Google 広告アカウントをまとめて管理するための仕組みと説明されています。仕組みは 2 つの段階に分かれます。アカウント同士の段階では、クライアントの Google 広告アカウントを代理店の MCC アカウントにリンク(つなぐこと)します。クライアント側のアカウントの管理者権限を持つユーザーは、いつでもこのリンクを解除できます。これがクライアントから見た取り消しです。代理店の中の段階では、担当者が MCC アカウントのユーザーとして招待され、アクセス権(Google 広告での権限の呼び名)を付与されます。 権限の種類に当たるのは、Google 広告アカウント(クライアント側)のアクセス権です。メール専用・お支払いとご請求・読み取り専用・標準・管理者の 5 段階があります。管理者は、アカウントへのアクセスの許可、アクセス権の変更、他のユーザーが送った招待(まだ受け入れられていないもの)の取り消しができます。すでにアクセス権を持つユーザーを外す操作は別です。「アクセス権を管理する」のページに、アクセスとセキュリティの画面で「アクセス権を削除」を選ぶ手順が示されています。MCC 側のユーザーのアクセス権は別に定義されており、[Google 広告の MCC で代理店アクセスを整理する](/guides/agency-accounts/google-ads-mcc-agency-access)で扱います。権限の種類・招待・取り消しの 3 要素がこの媒体では揃っていると読めます。 ## よくある質問 **権限付与と ID の共有は何が違いますか** 権限付与では担当者が自分のユーザーで入り、所有者のパスワードを知りません。共有では所有者の ID とパスワードをそのまま使うので、媒体の記録は ID 単位になり、担当者ごとに分かれません。 **権限付与ができれば共有 ID はなくなりますか** その媒体では不要になります。ただし仕組みのない媒体、招待された権限では変えられない設定、クライアント側の招待操作が進まない場合には、共有 ID が残ります。 **担当者が辞めたら権限付与では何をしますか** 所有者側(または代理店側の管理アカウント)で、その人の招待を媒体ごとに取り消します。パスワードを変える必要はありません。取り消し漏れを防ぐには、預かっているアカウントの一覧が要ります。 ## 参考資料 - [Google 広告ヘルプ「クライアント センター(MCC)アカウント: Google 広告 MCC アカウントについて」](https://support.google.com/google-ads/answer/6139186?hl=ja) - [Google 広告ヘルプ「Google 広告アカウントのアクセス権の概要」](https://support.google.com/google-ads/answer/9978556?hl=ja) - [Google 広告ヘルプ「Google 広告アカウントへのアクセス権を管理する」](https://support.google.com/google-ads/answer/6372672?hl=ja) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify は、権限付与の仕組みがない媒体や、クライアント側の設定を変えられないアカウントで主に使います。運用代行会社の管理者が ID とパスワードを登録し、担当者はパスワードを見ずにログインし、利用は担当者ごとに記録され、担当交代時は割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # X・TikTok の企業アカウントを運用代行するときの権限と共有 ID X は広告アカウントの権限(ロール)と、投稿や DM を任せる委任機能(X アカウント権限の付与)を別々に付けます。TikTok はビジネスセンターにメンバーかパートナーとして招きます。どちらもパスワードは渡しません。 更新日: 2026-09-17 X(旧 Twitter)と TikTok には、広告アカウントにも投稿用のアカウント本体にも[権限付与](/guides/agency-accounts/what-is-delegated-permission)の仕組みがあります。担当者は自分のユーザーで入れます。違いは付与の単位です。X は、広告アカウントの権限(ロール)と、アカウント本体の委任(他の人に投稿などを任せる機能)を別々に付けます。TikTok は、ビジネスセンター(広告アカウントや TikTok アカウントをまとめて管理する画面)に両方を置きます。 ## X 広告アカウントの権限(ロール) X 広告アカウントに入る権限は、広告主(クライアント)が business.x.com の画面で、担当者の @ユーザー名に対して付けます。担当者はクライアントのパスワードを受け取らず、自分の X アカウントで広告アカウントを開きます。権限の種類(ロール)は、画面で付けられるものが 5 つです。開発者向け資料には次のように説明されています。このほかに開発者向けの仕組みでだけ使う種類が 1 つありますが、画面での運用には関係しません。 | ロール | できること(資料の説明) | | --- | --- | | Account administrator | 広告の配信設定(キャンペーン)の変更と統計の閲覧に加え、ユーザーの追加・削除と設定の変更 | | Ad manager | キャンペーンの変更と統計の閲覧。ユーザーの追加・削除と設定の変更は不可 | | Creative manager | 広告の画像や文面(クリエイティブ)の変更と、見た目の確認(プレビュー)。キャンペーンの作成・変更は不可 | | Campaign analyst | キャンペーンと統計の閲覧のみ | | Organic analyst | 広告ではない通常の投稿の分析と、閲覧者(オーディエンス)の傾向の閲覧のみ。キャンペーンは閲覧も不可 | このほか、Account administrator・Ad manager・Creative manager の 3 つに限って、別の権限を付けられます。広告主に代わって、広告としてだけ配信する投稿(Promoted-only)を作る権限です。資料の権限一覧には、通常の投稿やプロフィールの変更を行う権限は含まれていません。運用代行が広告運用に加えて投稿も請け負う場合、投稿は次の委任機能で任せます。 取り消しについて、取得できた資料は開発者向けで、画面上でロールを外す手順は書かれていません。付与が @ユーザー名ごとに行われるので、取り消しも担当者ごとに行える形です。 ## X アカウント本体の委任(X アカウント権限の付与) X アカウント本体には、広告のロールとは別に、他のユーザーにアカウントの操作を任せる委任機能があります。X ヘルプセンターは、「パスワードを共有しなくても、アカウントを共同利用するユーザーの管理や、役割の割り当てまたは削除を安全に行える」と説明しています。役割は 3 つです。 | 役割 | できること(ヘルプの説明) | | --- | --- | | 所有者 | パスワード・電話番号・ログイン認証(二段階認証)の設定の管理、管理者かコントリビュータの招待、ポスト・リポスト・DM(ダイレクトメッセージ)・いいね・予約投稿・リストとコレクションの作成 | | 管理者 | 管理者かコントリビュータの招待、委任されたアカウントとしてのポスト・リポスト・DM・いいね・予約投稿・ポストの削除・リストとコレクションの作成、投稿の分析(ポストアナリティクス)の表示 | | コントリビュータ | 委任されたアカウントとしてのポスト・リポスト・DM・いいね・予約投稿・ポストの削除・リストとコレクションの作成 | 招待は、アカウントの所有者(または管理者)が送ります。X.com の「セキュリティとアカウントアクセス」から「X アカウント権限の付与」を開き、相手のユーザー名と役割を指定します。招待された人が承諾すると、自分の X アカウントのまま委任されたアカウントを使えます。外すときは同じ画面の「あなたがアカウント権限を付与したメンバー」から、役割の変更か「アカウントから削除」を選びます。パスワード・電話番号・ログイン認証の設定を触れるのは所有者だけです。ヘルプは、パスワードを変更しても委任されたユーザーはアカウントに入れるとしています。そのうえで、定期的にパスワードを更新し、所有者と管理者だけが知っている状態を保つよう勧めています。 ## TikTok ビジネスセンターのメンバーとパートナー TikTok ビジネスセンターは、広告アカウント・TikTok アカウント・ショップ・商品カタログなどを 1 か所で管理する画面です。ヘルプは「誰がどのアカウントやアセットにアクセスできるかを確認できる」仕組みと説明しています。アセットとは、広告アカウントやショップなど、ビジネスセンターに置く資産のことです。人を招く形は 2 つあります。 メンバーは、ビジネスセンターに直接入る人です。管理者(Admin)が利用者の一覧画面(Users)からメールアドレスを入れて招待します。1 つのビジネスセンターに登録できるのは最大 4,000 人です。基本の役割は「管理者」(すべての機能)と「標準」(割り当てられたアカウントとアセットだけ)の 2 つです。財務を扱う人にだけ、「財務マネージャー」「財務アナリスト」を付けます。ヘルプによれば、これらは管理者のアクセス権限に追加して付与するもので、財務情報を扱わせるには相手を管理者にしておく必要があります。 パートナーは、別のビジネスセンター(たとえば代理店)です。パートナーの追加とアセットの共有ができるのは管理者だけです。相手のビジネスセンター ID か広告アカウント ID で追加し、共有するアカウント・アセットと権限を招待の時点で決めます。相手が受け入れると、共有されたものが相手のビジネスセンターに表示されます。 アセットごとの権限は、メンバーにもパートナーにも付けます。広告アカウントの場合は 3 段階です。 | 広告アカウントの権限 | できること(ヘルプの説明) | | --- | --- | | 管理者 | アカウント設定の管理を含むすべて | | オペレーター | 広告の作成と編集、配信先(オーディエンス)の管理、資金の管理。設定の変更は不可 | | アナリスト | 広告と成果の閲覧、レポートの閲覧のみ | ## TikTok アカウント本体のリンク 投稿用の TikTok アカウントは、ビジネスセンターに「リンク」(つないで管理下に置くこと)して扱います。既存のアカウントをリンクするには、そのアカウントにログインしている人が TikTok アプリで QR コードを読み取り、ビジネスセンターに許可を与えます。つまり、クライアント側の操作が要ります。 リンクしたアカウントに対してメンバーに付ける権限は 2 段階です。「Deliver ads」は、アカウントの名義と投稿を広告に使う権限です。「Manage account」は、それに加えてコメントへの返信、DM の送信、プロフィールの管理を含む権限と説明されています。メンバーは、付けられた権限の範囲で、Spark Ads(TikTok の投稿を広告として配信する形式)を作れます。作れるのは、自分が入れる広告アカウントからです。アプリからの通常の投稿をビジネスセンター経由で行えるかは、取得したヘルプには書かれていません。 リンクの解除は、両方の側からできます。ビジネスセンター側では、TikTok accounts の「View」から「Unlink account」を選びます。TikTok アプリ側では、プロフィール設定の「Apps and services permissions」から「Remove Access」を選びます。 ## メンバー・パートナーの削除 メンバーの削除は、管理者が利用者の一覧画面(Users)から行います。削除の確認で認証コードの入力が要ります。削除されたメンバーは「このビジネスセンターと、そこで割り当てられたアカウント・アセットにアクセスできなくなる」と説明されています。 パートナーの削除は、管理者が「いつでも」できます。共有した側の管理者が、パートナーの一覧画面(Partners)から相手を選んで削除します。削除されたパートナーは、共有されていたアセットやアカウントを閲覧も管理もできなくなります。 ## 共有 ID が残る場面 X では、広告運用は広告アカウントのロールで、投稿と DM はアカウント本体の委任で任せられます。どちらもクライアントのパスワードは渡しません。残るのは 2 つです。所有者にしかできない操作(パスワード・電話番号・ログイン認証の設定の変更)と、委任の招待をクライアントに頼めない場面です。TikTok では、リンクの操作はアカウント所有者がアプリで行い、リンク後の権限はビジネスセンターで管理できます。そのため、広告と基本的なアカウント管理は権限付与でまかなえます。残るのは、リンクの操作そのものと、ヘルプに書かれていない操作(アプリからの投稿など)をクライアントの ID で代わりに行う場面です。 どちらの媒体でも、権限付与を始めるにはクライアント側の操作が要ります。X ではロールの付与と委任の招待、TikTok ではアプリでの QR コードの読み取りかパートナー招待の受け入れです。招待が送られず、QR コードも読み取ってもらえない間は、受け取った ID とパスワードをそのまま使う形が続きます。残った共有 ID の扱いは[運用代行のクライアントアカウント管理](/guides/agency-accounts)で整理しています。 ## よくある質問 **X 広告の運用を任せるのにパスワードは必要ですか** 必要ありません。広告主が business.x.com で担当者の @ユーザー名に権限(ロール)を付け、担当者は自分の X アカウントで広告アカウントを開きます。 **X の投稿代行も権限付与でできますか** できます。X アカウントの所有者が、担当者を「管理者」か「コントリビュータ」として招く委任機能があり、パスワードを共有せずに投稿・リポスト・DM を任せられます。広告の権限とは別に付けます。 **TikTok ではメンバーとパートナーのどちらで招くべきですか** 代理店の担当者を代理店側で管理するならパートナーです。クライアントは代理店のビジネスセンターに広告アカウントなどを共有し、担当者への割り当ては代理店側の管理者が行います。 **TikTok で担当者が辞めたら何をしますか** 代理店のビジネスセンターの管理者が、利用者の一覧(Users)からその人を削除します。削除すると、そのビジネスセンターで割り当てられていた広告アカウントなどに入れなくなります。 ## 参考資料 - [X Developer Platform「X Ads API: Accessing Ads accounts」](https://docs.x.com/x-ads-api/fundamentals/accessing-ads-accounts) - [X Developer Platform「X Ads API: Campaign Management Reference(Authenticated User Access)」](https://docs.x.com/x-ads-api/campaign-management/reference) - [X ヘルプセンター「アカウント権限の付与機能の使用方法」](https://help.x.com/ja/managing-your-account/how-to-use-the-delegate-feature) - [TikTok Business Center ヘルプ「TikTok Business Center」](https://ads.tiktok.com/help/article/tiktok-business-center?lang=en) - [TikTok Business Center ヘルプ「ビジネスセンターの役割と権限について」](https://ads.tiktok.com/help/article/about-business-center-roles-and-permissions?lang=ja) - [TikTok Business Center ヘルプ「アカウントおよびアセットレベルの権限について」](https://ads.tiktok.com/help/article/about-assets-and-asset-level-permissions?lang=ja) - [TikTok Business Center ヘルプ「How to add members to your TikTok Business Center」](https://ads.us.tiktok.com/help/article/add-users-tiktok-business-center?lang=en) - [TikTok Business Center ヘルプ「Assign Business Center members account and asset permissions」](https://ads.tiktok.com/help/article/how-to-assign-asset-level-permissions?lang=en) - [TikTok Business Center ヘルプ「How to add partners to your Business Center」](https://ads.tiktok.com/help/article/invite-partners-into-tiktok-business-center?lang=en) - [TikTok Business Center ヘルプ「Giving a Partner Access to TikTok Business Center Assets」](https://ads.tiktok.com/help/article/giving-partner-access-tiktok-business-center-assets?lang=en) - [TikTok Business Center ヘルプ「Assign accounts or assets to partners in Business Center」](https://ads.tiktok.com/help/article/how-to-assign-accounts-or-assets-to-partners-in-business-center?lang=en) - [TikTok Business Center ヘルプ「About managing TikTok accounts in Business Center」](https://ads.tiktok.com/help/article/about-managing-tiktok-accounts-in-business-center?lang=en) - [TikTok Business Center ヘルプ「Link an existing TikTok account for account management」](https://ads.tiktok.com/help/article/how-to-integrate-your-business-account-with-business-center?lang=en) - [TikTok Business Center ヘルプ「How to remove members from your Business Center」](https://ads.tiktok.com/help/article/remove-tiktok-business-center-partner?lang=en) - [TikTok Business Center ヘルプ「How to remove a Business Center partner」](https://ads.tiktok.com/help/article/remove-a-tiktok-business-center-partner?lang=en) ## Junify の場合 **人手で続けると** クライアントごとに渡し方を決め、担当替えのたびに権限を付け外しし、どの担当者がどのクライアントのアカウントを使ったかを媒体ごとに追い続けることになります。 **Junify なら** Junify は、権限付与でまかなえない部分を担います。委任の招待やアプリでのリンクをクライアントに頼めない場面や、所有者の ID でしか行えない操作では、管理者が ID とパスワードを登録し、担当者はパスワードを見ずにログインします。利用は担当者ごとに記録されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=marketing-ops) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](/guides/agency-accounts/agency-security-policy-for-clients): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。 - [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](/guides/agency-accounts/qoo10-au-pay-market-store-access): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。 - [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](/guides/agency-accounts/sns-scheduling-tools-client-accounts): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。 --- # 委託先に自社のアカウントを使わせるときの管理 個人情報保護法が委託元に求めるのは委託先の監督で、アカウントの渡し方までは指定していません。渡し方は 3 つあり、違いは誰が使ったかの記録と、契約終了時の作業に出ます。 更新日: 2026-09-18 委託先に自社のシステムや SaaS(インターネット経由で使う業務サービス)のアカウントを使わせると、渡し方によって 2 つのことが変わります。誰が使ったかが記録に残るかと、契約が終わったときに何をするかです。個人情報保護法が委託元に求めるのは委託先の監督で、渡し方そのものは指定していません。 ## 委託先に自社のアカウントを使わせるとはどういうことか 自社が契約している業務システムや SaaS に、委託先の担当者が入って作業できる状態にすることです。受注や問い合わせの処理、経理や採用の事務、SNS 公式や広告の運用を任せる場面で起きます。契約者は自社のままで、委託先は任された範囲で操作します。 契約で決まるのは任せる仕事の範囲で、アカウントをどう渡すかは範囲とは別に決めます(後の節「契約に書くことと運用で決めること」)。委託先の側から見た同じ問題は[運用代行のクライアントアカウント管理](/guides/agency-accounts)で扱っています。派遣社員は、ガイドラインでは自社の従業者(24 条)に含まれ、この記事の委託先には含めません。 ## 法令とガイドラインが委託元に求めること 個人データとは、顧客名簿のように検索できる形で整理された個人情報です。委託する業務にその取扱いが含まれる場合、委託元には個人情報保護法 25 条が当てはまります。条文は「委託を受けた者に対する必要かつ適切な監督を行わなければならない」(委託先がきちんと扱っているか確かめること)です。個人情報保護委員会のガイドライン(通則編)は、この委託を「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることと説明しています。契約の名前が業務委託でも請負でも、個人データを扱わせれば当てはまると読めます。 ガイドラインは、監督の内容として 3 点を挙げています(3-4-4)。適切な委託先の選定、委託契約の締結、委託先における個人データ取扱状況の把握です。3 点はいずれも行わなければならない措置です。そのうち選定時の確認は「あらかじめ確認しなければならない」、契約に盛り込む中身と定期的な評価の方法は「望ましい」とされています。3 点の中身と確認の方法は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 委託先に求める水準は、法 23 条の安全管理措置(個人データを守るために行う対策)と同等です。具体的な項目はガイドラインの別添にあり、アカウントに関わるものは 4 つあります。行わなければならない措置は、アクセス制御(誰がどこに入れるかを限定すること)と、アクセス者の識別と認証(誰が入ったかを見分け、本人と確かめること)の 2 つです。手法の例示は、ログイン実績などの記録と、アクセス権を有する者の明確化の 2 つです。ガイドラインは、別添の例示をすべて行わなければならないわけではなく、適切な手法は例示に限られないとも述べています。指定していないのは渡し方(手法)です。使う人を見分けて本人と確かめる措置自体は行わなければならないとされ、共有 ID ではその見分けをシステムではなく委託先の作業記録で行うことになります。 もう一つ、ガイドラインは「委託する業務内容に対して必要のない個人データを提供しないようにすることは当然」としています。委託先に渡すアカウントの権限を、任せる業務に必要な範囲に絞ることは、この考え方に沿います。 ## 渡し方の 3 つの型 渡し方は、委託先の担当者が自社のシステムにどう入るかで 3 つに分かれます。 1. 担当者ごとに発行する: 委託先の担当者一人ひとりに、自社のシステムの利用者アカウント(ユーザー)を作るか招待する。担当者は自分のユーザーで入る。委託を受ける側の記事では[権限付与](/guides/agency-accounts/what-is-delegated-permission)と呼んでいる形です。 2. 共有アカウントを渡す: 自社の 1 つのアカウントの ID とパスワードを委託先に渡し、委託先の担当者が共同で使う。 3. アクセス管理ツールを挟む: 自社が ID とパスワードをツールに登録し、委託先の担当者はツールを通してログインする。担当者はパスワードを見ず、ツールが担当者ごとの利用を記録する。パスワードを保管して配るだけの道具は 2 に含める。 | | 担当者ごとに発行する | 共有アカウントを渡す | アクセス管理ツールを挟む | | --- | --- | --- | --- | | できること | 担当者ごとに権限の種類を分ける | ユーザーを追加できないシステムでも使える | ユーザーを追加できないシステムでも、パスワードを渡さずに使わせる | | できないこと | ユーザーを追加できないシステムでは使えない | 誰が操作したかを担当者まで絞れない。権限を担当者ごとに分けられない | システムから見た権限は共有アカウントのまま。ツールの導入と登録の手間がかかる | | 記録の単位 | 発行した担当者(システムが記録を残す範囲で) | 共有した 1 つのアカウント | ツールにログインした担当者 | | 契約終了時に起きること | 委託先の担当者のユーザーを一人ずつ停止する | パスワードを変え、残る利用者に配り直す | ツール上で委託先の担当者の利用を止める。パスワードは変えない | 3 つは組み合わせて使えます。ユーザーを追加できるシステムは担当者ごとに発行し、SNS 公式や代表アドレスのように 1 つしかないアカウントを共有かツールで扱う形が現実的です。 ## 契約に書くことと運用で決めること 契約で決まるのは、任せる業務の範囲と、個人データの扱いに関する取り決めです。ガイドライン 3-4-4(2) が契約に盛り込むことが望ましいとするのは、双方が同意した安全管理措置の内容と、委託元が取扱状況を把握できることです。再委託(委託先が受けた業務をさらに別の者に出すこと)の条件も、契約で決めておきたいことです。[再委託とは](/guides/outsourcing-access/what-is-subcontracting)で扱っています。 アカウントの扱いは、契約とは別に運用で決めます。誰に発行するか、共有するか、パスワードを誰が持つか、誰が使ったかをどう残すか、契約終了時に何をするか、の 5 点です。契約に「ID の共有禁止」と書いても、自社が共有アカウントを渡していれば、委託先では共有で使うほかありません。渡し方を決められるのは委託元の側です。 ## 何から始めるか 最初の作業は、委託先が使っている自社のアカウントの一覧を作ることです。1 行に 1 アカウントずつ、委託先、システム、アカウント、渡し方(発行・共有・ツール)、使っている担当者を書きます。二段階認証のコード(ログイン時に届く使い捨てのコード)を誰が受け取っているかも添えます。この一覧がないと、契約終了時に何を止めればよいかが分かりません。 次に、一覧の中から担当者ごとの発行に切り替えられるものを選びます。ユーザーを追加できるシステムから順に、委託先の担当者一人ひとりにユーザーを発行します。切り替えのときに共有していたパスワードを変えると、共有の状態を終えられます。 最後に、残る共有アカウントの扱いを 4 点で決めます。対象のアカウント、パスワードを知っている人の範囲、契約終了時と担当交代時の変更手順、誰がいつ使ったかを残す方法です。記録の方法は、ツールを挟むか、作業記録を委託先に求めるかのどちらかです。ここまでできると、委託先の取扱状況を把握する材料が自社の側に残ります。セキュリティチェックシート(委託先の安全対策を確かめる質問票)を配るときも、この一覧が設問と答えを突き合わせる相手になります。[セキュリティチェックシートとは(委託元の側)](/guides/outsourcing-access/what-is-security-questionnaire)で扱っています。 ## このテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 - [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](/guides/outsourcing-access/isms-supplier-relationships): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 - [委託先経由の情報漏えいで問われる責任(公開事例から)](/guides/outsourcing-access/liability-in-contractor-breaches): 個人情報保護委員会の公表では、委託先で起きた漏えいでも、委託元が 25 条の委託先の監督の不備を指導されています(1 件は自社の安全管理措置の不備で勧告も)。問われたのは、確認の取り決めがない契約、監査や点検の不実施、再委託の未報告です。 - [副業人材・フリーランス・パートに社内アカウントを渡すときの線引き](/guides/outsourcing-access/side-jobs-freelancers-part-timers): パート・アルバイト・派遣社員はガイドラインの「従業者」に含まれ、従業者の監督(24 条)の対象です。業務委託のフリーランスは委託先で、委託先の監督(25 条)の側です。副業人材は、自社との契約が雇用か業務委託かで分かれます。 - [再委託先のアクセスをどう把握するか](/guides/outsourcing-access/subcontractor-access-visibility): 把握は 3 つの決まりで成り立ちます。再委託の事前報告に、再委託先の人が使う自社のアカウントを含めること。再委託先の人にも一人ずつ発行すること。自社のユーザー一覧と報告された名簿を定期的に突き合わせることです。 - [セキュリティチェックシートとは(委託元の側)](/guides/outsourcing-access/what-is-security-questionnaire): 委託元が、委託先の安全管理措置(個人データを守る対策)を書面で確かめる質問票。ガイドラインが委託前に求める確認の手段の一つと読めます。設問は別添の項目に沿って作ります。 - [再委託とは](/guides/outsourcing-access/what-is-subcontracting): 委託先が、受けた業務の全部または一部をさらに別の者に任せること。ガイドラインは、委託元が事前に報告を受けるか承認し、再委託先の安全管理措置まで確かめることが望ましいとしています。 - [委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors): 個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守る対策)が行われるよう確かめること(個人情報保護法 25 条)。ガイドラインは選定・契約・取扱状況の把握の 3 点を挙げています。 - [委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id): 確かめるのは 4 点です。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法です。答えられなければ、担当者ごとの発行に切り替える、アクセス管理ツールを挟む、業務範囲を絞る、のどれかを選びます。 ## よくある質問 **業務委託先に自社のシステムの ID を使わせてよいですか** 個人情報保護法は使わせること自体を禁じていません。委託する業務に個人データの取扱いが含まれれば、委託先の監督(25 条)が委託元に求められます。渡し方によって、誰が使ったかの記録と契約終了時の作業が変わります。 **委託先に 1 つの共有 ID を渡すのは違法ですか** 法令は渡し方を指定していません。ただしガイドラインは、ID ごとの権限で使える人を限定する手法を例示しています。共有 ID では記録が ID 単位になり、委託先の取扱状況を把握しにくくなります。 **契約が終わったとき、まず何をしますか** 委託先が使っていたアカウントの一覧を確認し、発行したユーザーは停止し、共有アカウントはパスワードを変えて残る利用者に配り直し、アクセス管理ツールならその担当者の利用を止めます。 **担当者ごとに発行できないシステムはどうしますか** 共有アカウントを渡すか、アクセス管理ツールを挟むかです。ユーザーを追加できるシステムは担当者ごとに発行し、1 つしかないアカウントを共有かツールで扱う組み合わせが現実的です。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify では、自社の共有アカウントの ID とパスワードを管理者が登録し、委託先の担当者にはパスワードを渡さずに使わせられます。誰が・いつ・どのアカウントを使ったかは担当者ごとに記録されます。契約終了時はその担当者の割り当てを外すだけで、パスワードを変えて配り直す必要はありません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # 委託終了・担当交代時のアクセス回収チェックリスト 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 更新日: 2026-09-18 委託が終わる日にすることは 3 つです。委託先の担当者が自社のシステムに入れる経路をすべて閉じ、閉じたことを確かめます。そして、委託先に残ったものを消してもらいます。作業の順番は 5 段階で、一覧 → 発行したユーザーの停止 → 共有アカウントの変更 → 記録の確認 → 返却・消去の確認です。担当交代のときは、交代する人の分だけを同じ順で行います。委託先の側から見た交代の手順は[運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](/guides/agency-accounts/handover-checklist)にあります。 ## 回収の前に決めておくこと 回収は、契約が終わる日に始めると間に合いません。IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、取引先との契約終了時の対応を挙げています。機密性の高い情報とアクセス権などを回収または破棄することです。責任者と期限を設定し、回収と破棄をチェックシートで運用して、記録を保管することを勧めています。決めておくのは、回収の責任者、期限、委託先の窓口の 3 つです。責任者は自社の誰が行うか、期限は契約終了日の当日か翌営業日までか、窓口は誰に消去の報告を求めるかです。 土台になるのは、委託先が使っている自社アカウントの一覧です。一覧に載っていないアカウントは、当日の作業から漏れます。一覧の作り方は[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)の「何から始めるか」にあります。 ## 委託終了時のチェックリスト {: .checklist} 1. **一覧から、その委託先の行を全部抜き出す** 渡し方(発行・共有・ツール)と、使っている担当者の名前を確かめます。 **なぜ** 渡し方によって、閉じる操作が違うためです。 **確かめ方** 一覧と、システム側のユーザー一覧を並べて、抜けがないか見ます。 2. **担当者ごとに発行したユーザーを停止する** 停止するまで、その人は同じ権限で入れます。 **根拠** IPA の内部不正防止ガイドライン 対策 5 は、不要になった利用者 ID とアクセス権をただちに削除するよう求めています。 **確かめ方** システムのユーザー一覧で、状態が停止になっていることを見ます。 3. **停止と削除を分け、記録の保存期間が終わるまでは削除しない** 利用者 ID を消すと、アクセス記録も消える場合があるためです。 **根拠** 同ガイドライン 対策 5 の本文に付く脚注は、その場合には ID をロックして記録を保全するよう求めています。 **確かめ方** 停止後も、その ID の過去の記録を開けることを確かめます。 4. **共有アカウントを渡していた場合は、パスワードを変えて配り直す** 委託先の担当者が知っているパスワードは記憶から回収できず、変える以外に無効にできないためです。 **確かめ方** 新しいパスワードで自社の担当者がログインでき、古いパスワードでは入れないことを確かめます。 5. **アクセス管理ツールを挟んでいた場合は、ツール上でその担当者の利用を止める** 担当者はパスワードを知らないので、ツール上で止めればツール経由では入れません。 **確かめ方** ツールの利用者一覧に、その委託先の担当者がないことを見ます。 6. **二段階認証のコードの受け取り先を、自社の管理する先へ変える** 二段階認証のコードは、ログイン時に届く使い捨てのコードです。受け取り先が委託先に残ると、自社の担当者がログインできません。 **確かめ方** 受け取り先の設定画面で、自社の連絡先だけになっていることを見ます。 7. **停止後の記録を確かめる** 停止したユーザーと共有アカウントに、終了日以降のログインがないことを見ます。停止や変更が反映されていなければ、記録に現れます。 **根拠** 通則編の別添は、担当者の情報システムの利用状況(ログイン実績など)の記録を手法の例に挙げています。 **確かめ方** 終了日から数日後に、ログイン記録を日付で絞って見ます。 8. **委託先に、ID・パスワードとデータの消去を求め、報告を受ける** ブラウザーに保存されたパスワードやダウンロードしたデータは、自社の操作では消せないためです。消去した日・対象・方法の報告を受けます。 **根拠** 通則編の別添は、委託先が確実に削除・廃棄したことを証明書などで確かめることも重要としています。 **確かめ方** 報告書は契約書と一緒に保管します。 9. **一覧を更新し、その委託先の行を終了として残す** 次の契約や監査で、いつ何を止めたかを示す材料になります。 **確かめ方** 更新日と担当者を一覧に書きます。 2 から 5 までは、渡し方ごとの「入れなくする操作」です。ここが終わらない限り、契約が終わっても委託先の担当者は入れます。7 と 8 は、閉じたことと消したことの確認です。 ## 担当交代のとき 担当交代では、上の手順を交代する人の分だけ行います。発行したユーザーならその人の分を停止します。共有アカウントならパスワードを変えて残る人に配り直し、ツールならその人の利用を止めます。後任の分は、停止と同時に発行や設定を済ませます。同時にしないと、業務が止まるか、旧担当者が残るかのどちらかになります。 委託先の担当者の退職や異動を、委託元が自分で知る方法はありません。IPA の内部不正防止ガイドライン 対策 5 の対策ポイント 3 に付く脚注は、委託先の従業員の異動や退職で起きるアカウントの削除漏れを取り上げています。体制に変更があれば委託元に報告することを、その例に挙げています。届け出の義務は契約で求めておきます。届け出がなければ、定期的な確認のときに、自社のユーザー一覧と委託先の担当者名簿を突き合わせて見つけることになります。 ## 回収の作業が持つ意味 契約終了時の回収と消去の確認は、その契約の最後の取扱状況の把握です。把握が委託先の監督の一部であることは[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 ## よくある質問 **委託先の担当者が退職したことをどう知りますか** 委託先からの届け出が頼りです。IPA のガイドラインは、委託先の従業員の異動や退職による削除漏れを取り上げ、体制の変更を委託元に報告することを例に挙げています。契約で届け出を求めます。 **発行したユーザーは削除と停止のどちらにしますか** まず停止です。IPA のガイドラインは、利用者 ID を消すとアクセス記録も消える場合には、ID をロックして記録を保全するよう求めています。記録の保存期間が過ぎてから削除します。 **共有アカウントのパスワードはなぜ変えるのですか** 委託先の担当者が知っているパスワードは、記憶からは回収できないためです。変える以外に無効にする方法がなく、変えた後は残る利用者に新しいものを配り直します。 **委託先での消去はどう確かめますか** ガイドラインの別添は、削除や廃棄を委託した場合に、委託先が確実に行ったことを証明書などで確かめることも重要としています。消去した日・対象・方法を書面で報告してもらいます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 契約終了の日に、Junify で渡したアカウントについては、委託先の担当者の割り当てを外せばその担当者は入れなくなります。担当者はパスワードを受け取っていないので、共有アカウントでもパスワードを変えて配り直す作業は要りません。終了までに誰が・いつ・どのアカウントを使ったかの記録は、担当者ごとに委託元の側に残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 - [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](/guides/outsourcing-access/isms-supplier-relationships): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 --- # 委託先へのセキュリティチェックシートの作り方(アカウント管理の設問) 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 更新日: 2026-09-18 セキュリティチェックシートのアカウント管理の設問は、自社が渡したアカウントを名指しします。答えは、誰が・いつ・何で確かめているかまで書いてもらう形にします。設問は個人情報保護委員会のガイドライン(通則編)別添「講ずべき安全管理措置の内容」の項目に対応づけます。答えは自社の記録と、現地か口頭の確認で突き合わせます。チェックシートを何のために配るかと、何を聞くかの大枠は[セキュリティチェックシートとは(委託元の側)](/guides/outsourcing-access/what-is-security-questionnaire)にあります。 ## 設問を作る前に決めること 設問を書く前に、その委託先に渡している自社のアカウントの一覧を手元に置きます。委託先、システム、アカウント、渡し方(発行・共有・ツール)、使っている担当者が 1 行ずつ並んだものです。設問の「当社が発行した ID」「当社が貸与している◯◯のアカウント」は、この一覧から名指しします。一覧がないと設問の対象が広がり、答えも一般論になります。 あわせて、答えの欄を 3 つに分けます。現状、確かめ方(誰が・いつ・何で)、対応予定(期限と担当)です。現状と予定を同じ欄に書かせると、後の監査で回答が事実と違ったのか予定が遅れたのかを分けられません。 ## 設問の文例 10 問 設問ごとに、別添のどの項目に当たるかと、答えに求める中身を添えます。ガイドラインは、別添の例示のすべてを行う必要はなく、適切な手法は例示に限られないとしています。設問は「例示どおりか」ではなく「どう行っているか」を聞く形にしています。 1. 当社が発行した ID を使う担当者の氏名・所属・役割を一覧で示してください。組織的安全管理措置 (3) 取扱状況を確認する手段の整備に当たります。答えに求めるのは、自社のユーザー一覧と突き合わせられる名簿です。 2. その一覧を、誰が、いつ(交代のたび・月 1 回など)更新していますか。組織的安全管理措置 (1) 組織体制の整備に当たります。答えに求めるのは、更新の責任者と時期です。 3. 当社のアカウントに、一覧にない人が入れる状態はありませんか。技術的安全管理措置 (1) アクセス制御(担当者と扱う範囲の限定)に当たります。答えに求めるのは、一覧にない人が入れない理由(ユーザーが個人ごと、共有パスワードを知る人が限定)です。 4. 当社が貸与している◯◯のアカウントについて、ID とパスワードを知っている人の氏名を示してください。技術的安全管理措置 (2) アクセス者の識別と認証(使う人を見分け、本人と確かめること)に当たります。答えに求めるのは、対象アカウントごとの、知っている人の名簿です。 5. そのパスワードを最後に変えた時期と、担当者の退職・交代のときに変える手順を示してください。同じく技術的安全管理措置 (2) に当たります。答えに求めるのは、変更の担当者、当社への依頼の経路、配り直す範囲です。 6. 担当者の退職・交代のとき、誰が、いつまでに当社へ届け出ますか。組織的安全管理措置 (1) と技術的安全管理措置 (1) に当たります。答えに求めるのは、届け出の担当者と期限、当社側でユーザーを止めるまでの流れです。 7. 誰がいつ当社のシステムに入ったかの記録を、何に(業務日誌・作業記録など)、どれだけの期間残していますか。組織的安全管理措置 (2) 規律に従った運用(利用状況の記録)に当たります。答えに求めるのは、記録の形と保存期間、当社側のログイン記録と突き合わせられるかどうかです。 8. 当社のアカウントで作業する端末は会社支給ですか。私物なら、パスワードの保存とデータの持ち出しをどう防いでいますか。物理的安全管理措置 (2)(3) と、技術的安全管理措置 (4) 情報システムの使用に伴う漏えい等の防止に当たります。答えに求めるのは、端末の管理者、保存の禁止、持ち出しの防止策です。 9. 受けた業務を他の会社や個人に出していますか。出しているなら、その人は当社のどのアカウントで入りますか。3-4-4(3) 再委託の事前報告・承認に当たります。答えに求めるのは、再委託先の名前、業務、使うアカウントです。 10. 当社のアカウントに関わる不審なログインや ID・パスワードの流出を知ったとき、誰が、いつまでに当社へ報告しますか。組織的安全管理措置 (4) 漏えい等事案に対応する体制の整備に当たります。答えに求めるのは、報告先、期限、経路です。 設問 4 と 5 は、共有アカウントを渡している場合にだけ聞く問いです。担当者ごとに発行しているなら、設問 3 で「ユーザーが個人ごと」と答えられ、4 と 5 は不要になります。設問 9 の再委託については、[再委託とは](/guides/outsourcing-access/what-is-subcontracting)に委託元が確かめることをまとめています。 ## 答えの読み方 答えは、自社の記録で答え合わせできる設問から読みます。設問 1 の名簿は自社が発行したユーザーの一覧と、設問 7 の記録は自社側のログイン記録と突き合わせます。名簿にない名前のユーザーがあれば、委託先の届け出漏れか、一覧の更新漏れです。どちらかを確かめるまで、その設問は未回答として扱います。 備考が空欄の「はい」は、確かめていない「はい」と見分けがつきません。設問ごとに、誰が・いつ・何で確かめているかが書かれているものだけを、現状の答えとして受け取ります。「対応予定」は、期限と担当が添えられているときに限り、現状とは別の欄で受け取ります。共有アカウントがあると答えた場合に確かめる 4 点は、[委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id)にまとめています。 ## 現地確認・口頭確認との組み合わせ 書面の答えは、それだけでは確認になりません。ガイドライン 3-4-4 の ※3 は、委託先の選定と取扱状況の把握の確かめ方を挙げています。個人データを取り扱う場所に赴くか、それに代わる合理的な方法(口頭による確認を含む)で確かめることです。IPA「組織における内部不正防止ガイドライン」第 5 版の対策 17 も、委託先の管理体制を定期的および不定期に確認しなければならないとしています。方法として、管理体制に関する文書の提出を求めることなどを挙げています。 現地か口頭で確かめる設問は、書面では答えを裏づけにくいものに絞ります。設問 4 の共有パスワードがどこに書かれ、誰の目に触れるか。設問 8 の端末に、ブラウザーの保存パスワードやダウンロードしたファイルが残っていないか。設問 7 の記録が、答えに書かれた形で実際にあるか。この 3 つは、担当者に画面や帳票を見せてもらえば、口頭でも確かめられます。 ## 更新の時期 ガイドライン 3-4-4(3) は、取扱状況の把握のために定期的に監査を行うことなどを望ましいとしています。頻度の決め方は[再委託先のアクセスをどう把握するか](/guides/outsourcing-access/subcontractor-access-visibility)にあります。配り直すときは同じ設問を使います。前回の回答との違いを見るためです。担当者の名簿の入れ替わり、共有パスワードの変更日、再委託先の有無が変わっていれば、その設問から確かめます。 定期の更新を待たずに配り直す場面もあります。委託先から担当者の交代や再委託の届け出があったときと、自社のシステムで一覧にないユーザーを見つけたときです。変わった部分の設問だけを配れば足ります。 ## よくある質問 **設問は何問くらいが適当ですか** アカウント管理に限れば 10 問程度です。設問ごとに、誰が・いつ・何で確かめているかを備考に書いてもらう形にすると、問数を増やすより答えの中身で判断できます。 **「はい」ばかりの回答はどう読みますか** 備考が空欄の「はい」は、確かめていない「はい」と区別がつきません。自社が発行したユーザー一覧やログイン記録と突き合わせ、合わない設問から現地か口頭で確かめます。 **現地確認は必ず必要ですか** ガイドラインは、個人データを取り扱う場所に出向くか、それに代わる合理的な方法(口頭による確認を含む)を挙げています。書面と口頭の確認で足りる場合もあり、扱う個人データの量に合わせて決めます。 **更新の頻度は決まっていますか** ガイドラインは定期的な監査などを望ましいとするだけです。頻度の決め方は再委託先の把握の記事にまとめています。配り直すときは同じ設問を使い、前回の回答との違いを見ます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 自社のアカウントを Junify で渡していれば、設問 1(使う担当者の一覧)と設問 7(誰がいつ入ったかの記録)は、委託先の申告を待たずに自社側の記録で答え合わせできます。担当者はパスワードを知らないので、設問 4 の「知っている人」は自社の管理者だけになります。契約終了時はその担当者の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 - [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](/guides/outsourcing-access/isms-supplier-relationships): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 --- # 委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点 ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 更新日: 2026-09-18 委託契約のアカウント条項は、委託先の担当者が自社のシステムに入る範囲を決める文です。入った後に何が残り、終わったら何をするかも、ここで決めます。個人情報保護委員会のガイドライン(通則編)3-4-4(2) は、委託契約に盛り込むことが望ましい内容を 2 つ挙げています。双方が同意した安全管理措置(個人データを守るために行う対策)の内容と、委託先での取扱状況を委託元が合理的に把握できることです。この 2 つをアカウントに当てはめると、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 条項になります。 ## 契約に書く根拠 個人情報保護法 25 条は、個人データの取扱いを委託する事業者に、委託先への必要かつ適切な監督を求めています。監督とは、委託先がきちんと扱っているか確かめることです。ガイドラインはその中身を選定・契約・把握の 3 点に分けています。契約については、前述の 2 つを盛り込むことが望ましいとしています。監督の全体は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 もう一つの根拠は、プライバシーマークの構築・運用指針です。JIPDEC の指針 J.9.4「委託先の監督」は、次の 8 つの事項が盛り込まれた契約を締結することを求めています。 1. 委託者と受託者の責任の明確化 2. 個人データの安全管理に関する事項 3. 再委託に関する事項 4. 個人データの取扱状況に関する委託者への報告の内容と頻度 5. 契約内容が守られていることを委託者が定期的・適宜に確認できる事項 6. 契約内容が守られなかった場合の措置 7. 事件・事故が発生した場合の報告・連絡に関する事項 8. 契約終了後の措置 プライバシーマークを持たない会社にも、契約に何を書くかの一覧として使えます。 IPA「組織における内部不正防止ガイドライン」第 5 版の対策 17「業務委託時の確認」にも、契約に関わる記述が 3 つあります。いずれも「望まれる」とする推奨です。委託先が委託元の調査に協力する義務を負うこと。委託後に監査できるかどうかを契約に先立って確かめること。委託元に深刻な影響が及ぶおそれがある場合には記録が提供されることを、契約上も明確にすることです。 ## 4 つの条項と文例 文例は、特定の会社の契約書を写したものではなく、公開された要求に対応する一般的な文です。条項ごとに、文例と、その条項が対応する要求を示します。 ### 貸与の範囲 > 委託元が発行または貸与するアカウントは、本契約の業務にのみ使用し、委託先があらかじめ届け出た担当者に限って使用する。担当者の追加・変更は、事前に委託元へ書面で届け出る。再委託先に使用させる場合は、委託元の事前の承認を得る。 この条項が対応する要求は、別添の技術的安全管理措置 (1) アクセス制御、3-4-4(3) の再委託の事前報告・承認、指針 J.9.4 の a) と c) です。アクセス制御とは、担当者と扱う範囲を限定することです。 「本契約の業務にのみ」と書くのは、任せる業務に要らない個人データを渡さないためです。アカウントの権限も、任せる業務に必要な範囲に絞ることになります。ガイドラインがこの点をどう述べているかは[委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id)にあります。 ### 共有の禁止 > 委託先は、発行されたアカウントを届け出た担当者以外に使用させず、ID とパスワードを第三者に開示しない。委託元が共有アカウントを貸与する場合、委託先はパスワードを知る者の氏名を委託元に届け出て、その者の退職・交代のときは遅滞なく委託元に変更を求める。 この条項が対応する要求は、別添の技術的安全管理措置 (2) アクセス者の識別と認証と、IPA (7) 利用者の識別と認証です。アクセス者の識別と認証とは、使う人を見分け、本人と確かめることです。 ### 記録の提出 > 委託先は、アカウントの使用者と使用日時が分かる記録を契約期間中および終了後◯年間保存し、委託元の求めに応じて提出する。不審なログインや ID・パスワードの流出を知ったときは、◯時間以内に委託元へ報告し、委託元の調査に協力する。 この条項が対応する要求は、3-4-4(2) の取扱状況の把握、指針 J.9.4 の d)、e)、g)、IPA (17) の記録の提供と調査への協力です。 保存期間や報告の期限の「◯」は、任せる業務で扱う個人データの量に合わせて決めます。事故が起きたときに本人が受ける不利益の大きさも考えます。ガイドラインは、監督の内容をそのリスクに応じて決めるよう求めています。 ### 終了時の返却 > 契約が終了したとき、または担当者が交代したときは、委託先はそのアカウントの使用を直ちに止め、端末に保存した ID・パスワードと業務で取得したデータを消去し、消去した日と方法を書面で委託元に報告する。 この条項が対応する要求は、指針 J.9.4 の h) 契約終了後の措置と、別添の物理的安全管理措置 (4) 削除・廃棄の確認です。削除・廃棄の確認とは、委託先が確実に削除・廃棄したことを証明書などで確かめることです。 ## 条項で決まることと決まらないこと 条項が縛るのは委託先の行為です。誰に使わせるか、パスワードを誰に見せるか、記録を残すか、終わったら消すかです。これに対して、アカウントをどう渡すかは、委託元の側で決める運用です。渡し方は、担当者ごとに発行する・共有アカウントを渡す・アクセス管理ツールを挟む、の 3 つです。3 つの違いは[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)で比べています。 契約と運用の関係で起きやすいのは、共有アカウントを 1 つ渡しながら「共有の禁止」を書くことです。委託先はその 1 つを共有して使うほかなく、条項は守れません。共有アカウントを渡すのであれば、文例の後半のように、知っている人の届け出と交代時の変更を求める形にします。担当者ごとに発行できるシステムであれば、発行に切り替えたうえで前半の禁止を書きます。 条項の実施状況は、契約後に確かめて初めて意味を持ちます。ガイドラインは、定期的な監査などで実施の程度を調べることを望ましいとしています。記録の提出と終了時の報告は、その確認の材料になります。確かめ方は[委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire)にあります。 契約の文言は、任せる業務とシステムに合わせて書き直したうえで、弁護士の確認を受けてください。この記事は法的助言ではありません。 ## よくある質問 **契約に「ID の共有禁止」と書けば足りますか** 自社が 1 つの共有アカウントを渡していれば、委託先は共有で使うほかありません。渡し方は委託元が決め、条項では知っている人の範囲と交代時の変更手順を求める形にします。 **文例はそのまま契約書に使えますか** 文例は公開されたガイドラインの要求に対応づけた一般的なものです。任せる業務とシステムに合わせて書き直し、契約の文言は弁護士の確認を受けてください。 **記録の提出を求める条項は必要ですか** ガイドラインは、取扱状況を委託元が把握できることを契約に盛り込むことが望ましいとしています。IPA のガイドラインも、記録が提供されることを契約上明確にすることが望ましいとしています。 **契約終了後に何を確かめますか** 使用の停止と、端末に残った ID・パスワードとデータの消去です。ガイドラインの別添は、削除や廃棄を委託した場合に、委託先が確実に行ったことを証明書などで確かめることも重要としています。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [JIPDEC プライバシーマーク推進センター「プライバシーマークにおける個人情報保護マネジメントシステム構築・運用指針」(JIS Q 15001:2023 準拠 ver1.0、2023 年 12 月 25 日制定)](https://privacymark.jp/guideline/pm_shishin2023v1.0.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify を使うと、委託先の担当者にパスワードを渡さずに自社のアカウントを使わせられます。担当者がパスワードを受け取らないので、「ID・パスワードを開示しない」の条項では、開示の対象そのものがなくなります。誰が・いつ使ったかの記録は担当者ごとに委託元の手元に残り、提出を待たずに確かめられます。契約終了時はその担当者の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](/guides/outsourcing-access/isms-supplier-relationships): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 --- # ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有 JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。 更新日: 2026-09-18 ISO/IEC 27001:2022(日本語版 JIS Q 27001:2023)の附属書 A には、供給者との関係を扱う管理策があります。番号と名称は、日本規格協会が公開している JIS Q 27002:2024 の目次で確かめられます。5.19 から 5.22 までが供給者関係の管理策で、5.23 がクラウドサービスの利用です。管理策の本文は有料なので、この記事は目次にある名称と、JIPDEC の公開資料の説明までを使います。委託先に自社のアカウントを使わせる場面は、この管理策と、個人情報保護委員会のガイドライン(通則編)の選定・契約・把握を対応づけて読めます。ISMS そのものの定義と認証の仕組みは[ISMS(情報セキュリティマネジメントシステム)とは](/guides/compliance/what-is-isms)にまとめています。 ## 供給者関係の管理策はどこにあるか ISMS-AC の「ISO/IEC 27001:2022 発行のお知らせ」によると、ISO/IEC 27001 は 2022 年 10 月 25 日に改訂されました。旧版で認証を受けていた組織の移行期限は 2025 年 10 月 31 日でした。JIPDEC の解説では、この改訂で附属書 A の管理策は 114 から 93 に整理されました。区分は組織的・人的・物理的・技術的の 4 つです。ユーザーズガイドの表 A-1 は、旧版の「A.15 供給者関係」を含む 14 の区分が、この 4 つに組み替えられたことを示しています。 管理策の番号と名称は、日本規格協会が公開している JIS Q 27002:2024 の目次で確かめられます。ユーザーズガイドによれば、JIS Q 27002 の箇条 5〜8 にある 93 の管理策は、項番も内容も JIS Q 27001 の附属書 A と同じです。目次で供給者とクラウドサービスに関わるのは、組織的管理策の次の 5 つです。 | 番号 | 目次の名称 | | --- | --- | | 5.19 | 供給者関係における情報セキュリティ | | 5.20 | 供給者との合意における情報セキュリティの取扱い | | 5.21 | ICT サプライチェーンにおける情報セキュリティの管理 | | 5.22 | 供給者のサービス提供の監視，レビュー及び変更管理 | | 5.23 | クラウドサービスの利用における情報セキュリティ | 5.21 の ICT サプライチェーンは、情報システムやサービスが供給者からさらにその先の供給者へと連なる取引の流れを指す言葉です。ユーザーズガイドの表 A-2 は、改訂で追加された 11 の新規管理策を列挙しており、5.23 はその一つです。ユーザーズガイドによれば、管理策に付ける属性「運用機能」の値の一つに「供給者関係のセキュリティ」があります。各管理策が何を求めるかの本文は、規格を入手して確かめる必要があります。 ## ユーザーズガイドが供給者について述べていること ユーザーズガイドは、リスク対応の選択肢の一つとして「リスクの共有」を説明しています。アウトソーシングなどで、他の組織とリスクを分け合うことです。共有先の例として、データセンター、インターネットサービスプロバイダー、クラウドサービスプロバイダーなどを挙げています。 そのうえで、リスクを共有する場合には 3 つを明確にすることが重要だとしています。共有したリスク、共有しなかったリスク、共有したことにより新たに発生するリスクです。共有したリスクを明確にするために、セキュリティ対策を契約書などに織り込むことが重要だ、とも述べています。5.19 は、この「共有したことにより新たに発生するリスク」を低減するための管理策と位置づけられています。 利害関係者の話でも供給者が出てきます。規格の 4.2「利害関係者のニーズ及び期待の理解」の解説で、ユーザーズガイドは利害関係者を広い視点で洗い出すよう求めています。例として、取引先の顧客、事業に必要なサービスを提供する供給者、従業員、親会社などを挙げています。 ## 通則編の選定・契約・把握との対応 委託先に自社のアカウントを使わせる場面を、ユーザーズガイドの言葉に当てはめると次のようになります。業務を委託することが「リスクの共有」で、委託先の担当者が自社のシステムに入れる状態が「共有したことにより新たに発生するリスク」です。個人データを扱う委託であれば、この関係には通則編 3-4-4 の委託先の監督も当てはまります。ガイドラインはその中身を、適切な委託先の選定、委託契約の締結、委託先における取扱状況の把握の 3 点に分けています。 5 つの管理策を、名称から読める対象でこの 3 点に対応づけると次のようになります。右の 2 列は規格の記述ではなく、この記事の読み替えです。 | 管理策(目次の名称) | 通則編 3-4-4 の対応 | 自社のアカウントについて決めること | | --- | --- | --- | | 5.19 供給者関係における情報セキュリティ | (1) 適切な委託先の選定。監督の全体にも当たる | 委託先を選ぶときに、アカウントの扱いを確かめる | | 5.20 供給者との合意における情報セキュリティの取扱い | (2) 委託契約の締結 | 貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 条項 | | 5.21 ICT サプライチェーンにおける情報セキュリティの管理 | (3) 再委託の事前報告・承認 | 再委託先の人が使うアカウントを事前報告に含める | | 5.22 供給者のサービス提供の監視，レビュー及び変更管理 | (3) 取扱状況の把握 | ユーザー一覧と名簿の突き合わせ、担当交代時の停止 | | 5.23 クラウドサービスの利用における情報セキュリティ | 直接の対応なし | 自社が契約するクラウドサービス(SaaS)の使い方の話で、委託先の監督とは別 | 契約に織り込む対策の中身は、通則編 3-4-4(2) が 2 つ挙げています。双方が同意した安全管理措置(個人データを守るために行う対策)の内容と、取扱状況を委託元が把握できることです。ISMS でいう「契約書に織り込む」対策と、通則編の契約の内容は、アカウントについては同じところを指しています。文例は[委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts)にあります。担当者ごとに発行するか、共有アカウントを渡すか、アクセス管理ツールを挟むかで、リスクの大きさと記録の残り方が変わります。渡し方ごとの記録の残り方は[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にあります。 ## 委託先が ISMS 認証を持っている場合 委託先が ISMS 認証を持っていても、預けたアカウントの扱いは認証からは分かりません。認証は組織の仕組み全体に対するものです。どの管理策を適用したかは、適用宣言書(どの管理策を使うと決めたかを書いた文書)に現れます。預けたアカウントを誰が使い、誰が使ったかがどう残るかは、契約と確認に現れます。委託先から見れば自社は顧客であり、5.19 の供給者は委託先のさらに先の相手です。自社と委託先の間のアカウントの扱いは、自社が契約と確認で決めることになります。 自社が ISMS 認証を取る側であれば、委託先に自社のアカウントを使わせている状態は、自社の供給者関係の管理策の適用範囲に入ります。説明できる形にしておくのは 3 つです。共有しているアカウントの一覧、パスワードを知っている人の範囲、誰が使ったかの記録の残し方です。契約と適用宣言書の両方で説明できるようにしておきます。 ## よくある質問 **委託先に自社のアカウントを使わせるのは供給者関係ですか** ユーザーズガイドは、アウトソーシングなどでリスクを分け合うことを「リスクの共有」とし、そこで新たに生じるリスクを減らす管理策として 5.19 を挙げています。委託先にアカウントを使わせる場面はここに当たると読めます。 **5.20〜5.22 には何が書かれていますか** 目次の名称は、5.20 供給者との合意における情報セキュリティの取扱い、5.21 ICT サプライチェーンにおける情報セキュリティの管理、5.22 供給者のサービス提供の監視，レビュー及び変更管理です。 **旧版の A.15 供給者関係はどうなりましたか** 2022 年の改訂で管理策は 114 から 93 に整理され、A.15 供給者関係を含む旧版の区分は、組織的・人的・物理的・技術的の 4 つに組み替えられました。5.19 は組織的管理策の一つです。 **ISMS 認証を持つ委託先なら共有 ID の心配は要りませんか** 認証は仕組み全体に対するもので、預けたアカウントを誰がどう使うかまでは示しません。どの管理策を適用したかは適用宣言書で、アカウントの扱いは契約と確認で別に確かめます。 ## 参考資料 - [日本規格協会「JIS Q 27002:2024 情報セキュリティ，サイバーセキュリティ及びプライバシー保護―情報セキュリティ管理策」プレビュー(目次)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27002_000_000_2024_j_ed10_ch.pdf) - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [JIPDEC「ISMS 認証基準(ISO/IEC 27001)の改訂」](https://www.jipdec.or.jp/library/itreport/2022itreport_winter06.html) - [ISMS-AC「ISO/IEC 27001:2022 発行のお知らせ」(2022 年 10 月 25 日、2023 年 2 月 27 日改訂)](https://isms.jp/doc/isoiec27001_2022_rev02.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 供給者との契約に織り込む対策のうち、Junify が仕組みで担うのは 3 点です。委託先の担当者にパスワードを渡さないこと、誰が・いつ・どのアカウントを使ったかを担当者ごとに委託元の記録として残すこと、契約終了時にその担当者の割り当てを外すことです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 委託先経由の情報漏えいで問われる責任(公開事例から) 個人情報保護委員会の公表では、委託先で起きた漏えいでも、委託元が 25 条の委託先の監督の不備を指導されています(1 件は自社の安全管理措置の不備で勧告も)。問われたのは、確認の取り決めがない契約、監査や点検の不実施、再委託の未報告です。 更新日: 2026-09-18 委託先で起きた漏えいで委託元に問われるのは、個人情報保護法 25 条の委託先の監督(委託先がきちんと扱っているか確かめること)です。個人情報保護委員会が公表した 2 件では、委託元が指導を受け、1 件では勧告も受けています。認められたのは、契約に取扱状況を確かめる取り決めがなかったこと、監査や点検をしていなかったこと、再委託を委託元に報告していなかったことです。この記事は公表された指導・勧告の内容に限り、損害賠償などの民事上の責任は扱いません。 ## 法令上の枠組み 個人情報保護法 147 条は、委員会が個人情報取扱事業者に対して必要な指導と助言を行えることを定めています。148 条 1 項は、23〜26 条などの規定に違反した事業者への勧告を定めています。違反を是正するために必要な措置をとるよう求めるものです。同条 2 項は、正当な理由なく勧告に従わず、個人の重大な権利利益の侵害が切迫していると認めるときに、命令できることを定めています。公表された指導・勧告は、この 2 条に基づくものです。 25 条の監督の中身は、ガイドライン(通則編)3-4-4 が選定・契約・把握の 3 点に分けています。全体は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。再委託について、3-4-4 の ※4 は次のように述べています。委託元が委託先を適切に監督していない場合に、再委託先が不適切な取扱いを行えば、元の委託元の法違反と判断され得る、というものです。 ## コールセンター業務を運営する子会社の事案(2024 年 1 月 24 日の勧告と指導) 委員会は 2024 年 1 月 24 日、通信事業者のグループでコールセンター業務を運営する子会社と、その仕組みを保守する委託先に対し、勧告と指導を行いました。勧告は 148 条 1 項、指導は 147 条に基づきます。この子会社は、多数の民間事業者と地方公共団体からコールセンター業務を受託していました。多数の委託元から見れば委託先ですが、コールセンターの仕組みの保守運用を別の会社に任せていたので、その保守の委託先から見れば委託元です。保守の委託先に派遣されていた従業者が、約 928 万人分の個人データを持ち出しました。事案の経緯は[委託先の保守担当者が管理者アカウントを共用していた事案](/guides/incidents/contractor-shared-admin-account)にあります。 委員会の詳細資料は、この子会社について 25 条違反を認めた理由として、次の事実を挙げています。 1. 契約に取り決めがなかったこと。サービス利用契約に、委託先の安全管理措置の実施状況を確認するための取り決めの明記がないまま、実態として個人データの取扱いを委託していた、というものです。通則編では 3-4-4(2) 委託契約の締結に当たります。 2. 再委託を委託元に報告していなかったこと。一部の委託元との契約で、事前に申請して承諾を得た場合に限り第三者に委託できると定めていたにもかかわらず、委託元に報告せずに保守の委託先に個人データを取り扱わせていた、というものです。通則編では 3-4-4(3) 再委託の事前報告・承認に当たります。 3. 取扱状況を把握していなかったこと。定期的な監査や委託の内容の見直しの検討を行っておらず、委託先での取扱状況を適切に把握していなかった、というものです。通則編では 3-4-4(3) 取扱状況の把握に当たります。 勧告の対象は 23 条(自社の組織的安全管理措置の不備)で、25 条の不備は指導の対象でした。勧告の理由は 2 つに分かれます。一つは、2013 年から 2023 年までの長期にわたって持ち出しが繰り返され、人数も多数にのぼったことです。もう一つは、2022 年に委託元の一つから調査依頼があったときに十分な調査ができておらず、その経緯と原因をまだ明らかにできていないことです。 委員会は同じ公表の中で、コールセンター業務を運営または受託している事業者に向けた注意喚起も出しています。個人データを扱う情報システムの保守を外部に任せる場合の内容です。その保守サービス事業者がシステム内の個人データを取り扱うことになっていれば、その事業者は委託先に当たり、監督が必要だとしています。契約の名前が「サービス利用契約」でも、個人データを扱わせれば委託です。 ## 自動車メーカーの事案(2023 年 7 月 12 日の指導) 委員会は 2023 年 7 月 12 日、自動車メーカーに 147 条に基づく指導を行いました。この自動車メーカーは、関連会社に個人データの取扱いを委託していました。委託先のクラウド環境の誤設定により、約 10 年間にわたり約 230 万人分の個人データが外部から閲覧できる状態にありました。 委員会が委託元について指摘したのは、委託先での取扱状況を適切に把握していなかったことです。クラウド環境のアクセス制御(誰がどのデータに入れるかを絞ること)の観点からの監査・点検を行っていませんでした。指導は 23 条と 25 条に基づき、3 点を求めています。従業者への教育、適切なアクセス制御、そして委託先に自社と同等の措置が行われるよう必要かつ適切な監督を行うことです。あわせて、委託先への定期的な監査を含む再発防止策を確実に実施することも求めています。 ## 2 件で共通して問われたこと 2 件に共通するのは、委託元が「取扱状況を把握していなかった」ことを指摘された点です。行為者が委託先の側(派遣社員、担当者)であっても変わりません。 | 問われたこと | コールセンター業務を運営する子会社 | 自動車メーカー | | --- | --- | --- | | 契約の取り決め | 実施状況を確認する取り決めがなかった | 公表資料に記述なし | | 監査・点検による把握 | 定期的な監査と見直しを行っていなかった | アクセス制御の観点からの監査・点検を行っていなかった | | 再委託の報告 | 委託元に報告せずに委託していた | 公表資料に記述なし | | 行政上の対応の種類 | 勧告(23 条)と指導(23 条・25 条) | 指導(23 条・25 条) | ## 委託先の担当者のアカウントとどう関係するか 2 件で問われた「取扱状況の把握」は、委託先の誰が、どのシステムに、どの権限で入り、何をしたかを委託元が知っているかどうかです。コールセンター業務を運営する子会社の事案では、保守運用を担う委託先の 4 人の担当者に管理者アカウントが与えられていました。全委託元のリストを閲覧・ダウンロードできる権限です。詳細資料によれば、このアカウントは個人単位に付与されたものではなく、4 人で共用する状態でした。委員会は、共用のために誰が不適切な操作を行ったかをログから判別できなかったとして、委託先の側の安全管理措置(23 条)の不備に挙げています。誰にどの権限が与えられているかは、委託元が把握する取扱状況の一部と読めます。委託先に自社のアカウントを使わせている委託元は、その一覧と記録を自社の側に持つことが、把握の出発点になります。渡し方によって記録の残り方が変わる点は[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)の「渡し方の 3 つの型」にあります。 ## よくある質問 **委託先が起こした漏えいで委託元も委員会の対応を受けますか** 公表された 2 件では、委託元が 147 条に基づく指導を受け、うち 1 件では 148 条 1 項に基づく勧告も受けています。認められたのは、委託先の監督(25 条)の不備と、自社の安全管理措置(23 条)の不備です。 **再委託先の事故も委託元の責任になりますか** ガイドラインの ※4 は、委託元が委託先を適切に監督していない場合に再委託先が不適切な取扱いを行えば、元の委託元の法違反と判断され得るとしています。再委託を知らなかったことは理由になりにくいと読めます。 **指導と勧告はどう違いますか** 指導は 147 条に基づく助言で、勧告は 148 条 1 項に基づく是正の求めです。勧告に正当な理由なく従わず、個人の重大な権利利益の侵害が切迫していると認められると、148 条 2 項で命令に進みます。 **損害賠償はどうなりますか** この記事は公表された指導・勧告の内容に限っています。損害賠償などの民事上の責任と、契約上の責任は公表資料の範囲外で、扱っていません。個別の判断は弁護士に確認してください。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 委託先の担当者が自社の Web アカウントを使う場面では、Junify がパスワードを渡さず、誰が・いつ・どのアカウントを使ったかを担当者ごとに委託元の記録に残します。取扱状況を把握する材料が、自社の側にできます。契約が終われば、その担当者の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 副業人材・フリーランス・パートに社内アカウントを渡すときの線引き パート・アルバイト・派遣社員はガイドラインの「従業者」に含まれ、従業者の監督(24 条)の対象です。業務委託のフリーランスは委託先で、委託先の監督(25 条)の側です。副業人材は、自社との契約が雇用か業務委託かで分かれます。 更新日: 2026-09-18 社内アカウントを渡す相手が従業者か委託先かは、自社との契約の形で決まります。パート・アルバイト・派遣社員は、個人情報保護委員会のガイドライン(通則編)で「従業者」に含まれます。従業者の監督(個人情報保護法 24 条)の対象です。業務委託契約のフリーランスは委託先で、委託先の監督(25 条)の側です。副業人材は、自社と雇用契約を結ぶなら従業者、業務委託契約なら委託先です。どちらに当たるかで、発行するアカウント、監督の根拠、終了時の手続きが変わります。 ## 従業者か委託先かは契約の形で決まる ガイドライン 3-4-3 は、従業者を次のように説明しています。「個人情報取扱事業者の組織内にあって直接間接に事業者の指揮監督を受けて事業者の業務に従事している者等」です。雇用関係にある従業員(正社員、契約社員、嘱託社員、パート社員、アルバイト社員など)がここに含まれます。取締役や監査役、派遣社員も含まれると明記されています。パートやアルバイトを正社員と分けて扱う理由は、この点に関してはありません。 委託は、3-4-4 の ※1 で「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることとされています。業務委託契約や請負契約で仕事を受けるフリーランスに個人データを扱わせれば、相手が個人でも委託先です。監督の中身は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 副業人材はこの 2 つにまたがります。厚生労働省の「副業・兼業の促進に関するガイドライン」は、労働時間の通算を説明する中で、労働基準法が適用されない例を挙げています。フリーランス、独立、起業、顧問などです。同じ「副業で来ている人」でも、自社と雇用契約を結んでいれば従業者、業務委託契約なら委託先です。本業の勤務先での立場は、自社での位置づけに関係しません。なお同ガイドラインは、請負であるかのような契約でも実態が雇用契約と認められる場合を取り上げています。その場合は、就労の実態に応じて使用者責任が問われるとしています。契約の名前だけで決めるわけにはいきません。 ## 雇用形態ごとの整理 - 正社員・契約社員は従業者です。本人のユーザーを発行し、24 条に基づいて、就業規則などの秘密保持事項と教育で監督します。退職日に本人のユーザーを停止します。 - パート・アルバイトも従業者で、扱いは正社員・契約社員と同じです。共有 ID で使わせると、記録が ID 単位になります。 - 派遣社員も従業者です。派遣先である自社が本人のユーザーを発行し、24 条に基づいて監督します。派遣期間の終了日に停止します。 - 雇用契約で来ている副業人材も従業者です。本人のユーザーを発行し、24 条に基づいて監督します。契約終了日に停止します。 - 業務委託契約の副業人材とフリーランスは委託先です。本人のユーザーを、任せる業務に必要な範囲で発行します。1 つしかないアカウントを渡すなら、知っている人の範囲を決めます。監督の根拠は 25 条で、委託契約に安全管理措置の内容と取扱状況の把握を盛り込みます。契約終了日に停止し、共有アカウントならパスワードを変え、端末に残った ID・パスワードとデータの消去を確かめます。 「本人のユーザー」を発行する点は、どの立場でも同じです。ガイドラインの別添は、行わなければならない技術的安全管理措置を挙げています。アクセス制御(担当者と扱う範囲の限定)と、アクセス者の識別と認証(使う人を見分け、本人と確かめること)です。従業者にも委託先にも当てはまる措置で、立場によって変わるのは監督の根拠と契約の形です。 ## 従業者と委託先で何が違うか 従業者に対する監督は、教育と規程で行います。別添の人的安全管理措置は、従業者に個人データの適正な取扱いを周知徹底し、適切な教育を行うことを求めています。手法の例は、定期的な研修と、秘密保持に関する事項を就業規則などに盛り込むことです。パートやアルバイト、派遣社員にも同じ教育と規程が及びます。 委託先に対する監督は、選定・契約・把握の 3 点です。フリーランスに個人データを扱わせるなら、その人の安全管理措置が自社に求められるものと同等かを委託前に確かめます。契約には安全管理措置の内容と取扱状況の把握を盛り込み、契約後も状況を把握します。相手が 1 人でも、この 3 点は変わりません。 IPA「組織における内部不正防止ガイドライン」第 5 版の対策 7 は、共有 ID と共有のパスワードを使わないよう求めています。利用者ごとの ID を、個別のパスワードで認証する形です。パートやアルバイトに共有 ID で使わせている場合、この対策から外れているのは雇用形態のせいではなく、ID の発行の仕方のせいです。 ## 迷いやすい場面 派遣元の会社に自社のアカウントを渡し、派遣社員がそれで作業する形では、自社の記録は派遣元名義の 1 つのアカウントで残ります。誰が使ったかは、派遣元の名簿に頼ることになります。派遣社員には自社が本人のユーザーを発行します。 フリーランスに、社員と同じ共有 ID を使わせている形は、委託先に共有アカウントを渡している状態です。確かめることは[委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id)にまとめています。契約終了時にはパスワードを変えて残る社員に配り直します。 副業人材が複数の会社で働いている場合、自社のアカウントで扱う個人データを別の勤務先で使わないことを求めます。雇用契約なら就業規則の秘密保持事項で、業務委託契約なら委託契約で求めます。どちらの契約でも、自社のシステムに入る端末を本人の私物にするかどうかは、別に決めることになります。 ## よくある質問 **パートに個人データを扱わせるのに契約書は要りますか** パート社員はガイドラインの「従業者」に含まれ、必要なのは従業者の監督(24 条)で、委託契約は要りません。別添は、秘密保持に関する事項を就業規則などに盛り込むことを手法の例に挙げています。 **副業で来ている人は従業者ですか委託先ですか** 自社との契約で決まります。雇用契約なら従業者で 24 条、業務委託契約なら委託先で 25 条の側です。本業の勤務先での立場は関係ありません。 **派遣社員のアカウントは派遣元と派遣先のどちらが出しますか** ガイドラインは、指揮監督を受けて業務に従事する者として派遣社員を従業者に含めています。派遣先の自社が本人のユーザーを発行し、派遣期間の終了日に止めます。派遣元名義の 1 つのアカウントでは、誰が使ったかが残りません。 **フリーランスに社員と同じ共有 ID を使わせています** 委託先に共有アカウントを渡している状態です。パスワードを知っている人の範囲と交代時の変更手順を委託先と決め、契約終了時にはパスワードを変えて残る社員に配り直します。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [厚生労働省「副業・兼業の促進に関するガイドライン」(平成 30 年 1 月策定、令和 4 年 7 月改定)](https://www.mhlw.go.jp/content/11200000/000962665.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify では、社員・パート・派遣・フリーランスのどの立場の人にも、必要なアカウントだけを本人単位で使わせられます。本人は自分のスマホで本人確認をしてから使い、パスワードは受け取りません。誰が・いつ使ったかは立場に関係なく一人ひとり残り、雇用や契約が終わればその人の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 再委託先のアクセスをどう把握するか 把握は 3 つの決まりで成り立ちます。再委託の事前報告に、再委託先の人が使う自社のアカウントを含めること。再委託先の人にも一人ずつ発行すること。自社のユーザー一覧と報告された名簿を定期的に突き合わせることです。 更新日: 2026-09-18 再委託先の人が自社のシステムに入っているかどうかは、自社の記録を見ただけでは分かりません。記録には委託先の担当者か共有アカウントの名前しか残らないためです。把握は 3 つの決まりで成り立ちます。再委託の定義と、委託元が確かめることの全体は[再委託とは](/guides/outsourcing-access/what-is-subcontracting)にまとめています。 ## 事前報告に含める項目 個人情報保護委員会のガイドライン(通則編)3-4-4(3) は、委託先が再委託を行おうとする場合の委託元の対応を述べています。望ましいとされているのは、委託先から事前に報告を受けるか、承認を行うことです。対象は、再委託する相手方、業務内容、再委託先の個人データの取扱方法です。IPA「組織における内部不正防止ガイドライン」第 5 版の対策 17 も、事前報告を受けて承認することを望ましいとしています。対象は、再委託先の業務内容や重要情報の取り扱い(テレワーク時を含む)など複数です。そのうちの一つが、事故時に再委託先が委託元の調査に協力する義務を負うかどうかです。 この報告に、アカウントの項目を加えます。ガイドラインの「取扱方法」を、自社のシステムに入るという形の取扱いに当てはめたものです。 1. 再委託先の会社名と、作業する人の氏名。自社のユーザー一覧と名前で突き合わせるためです。 2. 再委託する業務の範囲。その業務に要らない権限やデータを渡さないためです。 3. 自社のどのシステムに、どのアカウントで入るか。記録の突き合わせの起点で、ここが空欄だと把握のしようがありません。 4. 発行の形(再委託先の人に発行するか、委託先の担当者のユーザーか、共有アカウントか)。形によって、自社の記録に誰の名前で残るかが変わるためです。 5. 期間。終了日に止める対象を決めるためです。 6. 誰がいつ使ったかを再委託先がどう残すか。自社の記録が共有アカウントの名前で残る場合に、突き合わせる相手になります。 7. 事故時の報告経路と、調査への協力。再委託先で起きたことが、委託先を経由して自社に届く経路を決めるためです。 報告は、再委託が始まる前に受けます。ガイドラインは「事前報告を受け又は承認を行うこと」としています。始まった後の事後報告では、報告までの期間に誰が入っていたかが分かりません。 ## 発行の単位 自社のアカウントが再委託先に渡る経路は 2 つです。委託先の担当者に発行したユーザーを再委託先の人が使う場合と、委託先に渡した共有アカウントが再委託先にも配られる場合です。どちらも自社の記録には委託先の名前で残ります。 ユーザーを追加できるシステムであれば、再委託先の人にも一人ずつ発行し、委託先の担当者のユーザーを使わせないと決めます。発行の申請は委託先を通して受け、承認した名前だけを発行します。これで自社の記録は再委託先の人の名前で残り、終了日にはその人のユーザーだけを止められます。 共有アカウントを渡している場合は、パスワードを知っている人の範囲に再委託先が含まれるかを、委託先への確認事項に加えます。共有パスワードは一度配られると、誰まで知っているかを委託元が確かめる手段が乏しくなります。 ある市の事案では、市に無断の再委託・再々委託が行われ、案件を離れた人や転職した人もパスワードを知ったままでした。詳しくは[無断の再委託先が個人データを持ち出した事案](/guides/incidents/undisclosed-subcontractor-copied-data)にあります。 ## 記録の突き合わせ 突き合わせるのは、自社のシステムのユーザー一覧と、報告された名簿(委託先の担当者と再委託先の人)です。一覧にあって名簿にない名前は、報告漏れか、委託先の内部の交代の届け出漏れです。名簿にあって一覧にない名前は、その人が委託先の担当者のユーザーか共有アカウントで入っている可能性を示します。どちらも、委託先に確かめるまでは未確認として扱います。 ログイン記録も見ます。停止したはずのユーザーに記録があれば停止漏れです。共有アカウントに、報告された作業時間と合わないログインがあれば、名簿にない人が使っている可能性があります。ガイドラインの別添は、担当者の情報システムの利用状況(ログイン実績など)を記録する手法を例に挙げています。この突き合わせは、その記録の使い道の一つです。 頻度について、ガイドラインは定期的な監査などを望ましいとするだけで、決めていません。決め方の一例は、再委託の報告が新しく出たときや変わったときに 1 回と、契約更新の時期に合わせた年 1 回を組み合わせることです。委託の階層が深いほど、委託元がその作業者を直接知る機会は減ります。 空調機器メーカーの事案では、委託先、再委託先、その先の再々委託先の作業者が仕入先情報を持ち出し、委託元が検知しています。詳しくは[再々委託先の作業者が仕入先の個人情報をダウンロードした事案](/guides/incidents/fourth-tier-contractor-downloaded-data)にあります。 ## 委託先を通じた確認と自らの確認 ガイドライン 3-4-4(3) は、委託先を通じて、または必要に応じて自ら、定期的に監査を行うことを挙げています。確かめるのは 2 つです。委託先が再委託先を監督していることと、再委託先が安全管理措置(個人データを守るために行う対策)を行っていることです。IPA の対策 17 は、委託元に深刻な影響が及ぶ可能性が高い場合には、委託元が自ら確認や監査を行うことが望ましいとしています。 自社の記録との突き合わせは、委託先には行えません。委託先が持っているのは自社の名簿だけで、自社のシステムのユーザー一覧とログイン記録は委託元にしかないためです。委託先を通じた監査(再委託先の体制や規程の点検)と、自らの突き合わせは、確かめる対象が違うので、片方で代えることはできません。 ## よくある質問 **再委託の報告には何を書いてもらいますか** ガイドラインが挙げる相手方・業務内容・取扱方法に加えて、再委託先の人が使う自社のアカウント、その人の名前、期間、記録の残し方です。アカウントが書かれていないと、自社の記録と突き合わせられません。 **再委託先の人にも一人ずつ発行すべきですか** ユーザーを追加できるシステムなら、一人ずつ発行します。委託先の担当者のユーザーを再委託先に使わせると、自社の記録は委託先の担当者の名前で残り、再委託先の人の操作が見えません。 **突き合わせはどのくらいの頻度で行いますか** ガイドラインは定期的な監査などを望ましいとするだけで、頻度は決めていません。再委託の報告が変わったときと、契約更新の時期に合わせた年 1 回、を組み合わせる決め方が一つです。 **委託先の監査に任せてよいですか** ガイドラインは、委託先を通じて、または必要に応じて自ら、定期的に監査を行うことを挙げています。自社の記録との突き合わせは自社にしかできないので、委託先の監査とは別に行います。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 再委託先の人が自社の Web アカウントを使う場合も、Junify では委託元の管理者がその人を登録し、必要なアカウントだけを割り当てます。パスワードは渡さないので、委託先から再委託先へ共有パスワードが配られる経路がなくなります。使った記録は再委託先の人ごとに委託元に残り、報告の名簿と突き合わせられます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # セキュリティチェックシートとは(委託元の側) 委託元が、委託先の安全管理措置(個人データを守る対策)を書面で確かめる質問票。ガイドラインが委託前に求める確認の手段の一つと読めます。設問は別添の項目に沿って作ります。 更新日: 2026-09-18 セキュリティチェックシートとは、委託元が委託先に配り、委託先の安全管理措置(個人データを守るために行う対策)を書面で確かめる質問票です。法令上の名前ではなく、実務で使われている呼び名です。ここでは配る側を扱います。答える側の視点は[クライアントのセキュリティチェックシートへの、運用代行会社の答え方](/guides/agency-accounts/answering-security-questionnaires)にあります。 ## 何のために配るのか 根拠は、個人情報保護委員会のガイドライン(通則編)3-4-4(1) にあります。個人データの取扱いを委託する事業者は、委託先を選ぶときに、別添「講ずべき安全管理措置の内容」の各項目が委託する業務に沿って行われることを確かめます。これは「あらかじめ確認しなければならない」とされています。確認の方法としては、個人データを取り扱う場所に出向くか、それに代わる合理的な方法(口頭による確認を含む)が挙げられています(※3)。チェックシートは、この確認を書面で行う手段の一つと読めます。ガイドラインがこの形を求めているわけではありません。 選定時の一度きりではなく、契約後の取扱状況の把握(3-4-4(3))にも使えます。同じ設問を定期的に配れば、選定時の回答との違いから変化を追えます。委託先の監督の全体は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 ## 何を聞くか 設問は、別添の項目に沿って作ると、委託先も対応づけて答えられます。ガイドラインは、例示の全てを行わなければならないわけではなく、適切な手法は例示に限られないとしています。そのため、設問は「例示どおりか」ではなく「どう行っているか」を聞く形にします。アカウントの管理に関わる設問の例を挙げます。括弧は、その設問が当たる別添の項目です。 1. 個人データを扱うシステムに入れる人を、業務に必要な範囲に限定しているか(技術的安全管理措置 (1) アクセス制御) 2. ID とパスワードを複数人で共有していないか。共有しているならどのアカウントか(技術的安全管理措置 (2) アクセス者の識別と認証) 3. アクセス権(そのシステムに入って操作できる権限)を持つ人の一覧があるか(組織的安全管理措置 (3) 取扱状況を確認する手段の整備) 4. 退職・担当交代のとき、その人のアクセス権をいつ誰が外すか(技術的安全管理措置 (1) アクセス制御) 5. 誰がいつシステムに入ったかの記録(ログイン実績など)を残しているか(組織的安全管理措置 (2) 規律に従った運用) 6. 受けた業務を別の会社や個人に出しているか。出しているなら、その人はどのアカウントを使うか(3-4-4(3) 再委託) 委託先に自社のアカウントを使わせている場合は、「当社が発行した ID を、御社の誰が使っているか」のように対象を名指しすると、答えが具体的になります。 ## 答えをどう読むか 「はい」「いいえ」の欄だけでは、選定の判断にも後の把握にも使えません。設問ごとに、誰が・いつ・何で確かめているかを備考に書いてもらう形にします。 共有 ID があると答えた委託先には、4 点(対象のアカウント・パスワードを知っている人の範囲・担当交代時の変更手順・誰がいつ使ったかを残す方法)を備考に書いてもらいます。この 4 点が書けていれば、共有があること自体は管理された状態と読めます。書けていなければ、その委託先では誰が操作したかを絞れない状態と読めます。共有しているアカウントが自社の渡したものなら、解消できるのは自社の側です。渡し方の選び方は[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にあります。 ## よくある質問 **チェックシートは法令で義務づけられていますか** 個人情報保護法もガイドラインも、チェックシートという形は求めていません。求められているのは委託前の確認で、チェックシートはその手段の一つと読めます。 **アカウント管理の設問は何を聞きますか** ガイドライン別添の項目に沿って、入れる人の限定、ID の共有の有無と対象、交代時にアクセス権を外す手順、誰がいつ入ったかの記録、アクセス権を持つ人の一覧、再委託の有無を聞きます。 **「共有 ID あり」と答えた委託先は不合格ですか** 有無ではなく管理方法を見ます。対象のアカウント、パスワードを知る人の範囲、交代時の変更手順、誰が使ったかを残す方法の 4 点です。自社が渡した共有アカウントなら、変えられるのは自社の側です。 **一度配れば済みますか** 選定時の確認に加えて、契約後の取扱状況の把握にも使えます。同じ設問を定期的に配ると、選定時の回答との違いから変化を追えます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify では、委託先の担当者に自社のアカウントのパスワードを渡さずに使わせられます。自社が Junify で渡したアカウントについては、誰が使っているかの設問を、委託先の申告ではなく自社側の記録で答え合わせできます。契約終了時はその担当者の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 再委託とは 委託先が、受けた業務の全部または一部をさらに別の者に任せること。ガイドラインは、委託元が事前に報告を受けるか承認し、再委託先の安全管理措置まで確かめることが望ましいとしています。 更新日: 2026-09-18 再委託とは、委託先が、委託元から受けた業務の全部または一部を、さらに別の会社や個人に任せることです。委託先の社員ではないフリーランスに作業を出す場合も、受けた業務を扱わせるなら再委託に当たります。委託元から見ると、自社のアカウントや個人データが、契約していない相手の手に渡り得る経路になります。 ## 再委託とは何か 個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託をこう説明しています(※1)。「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることです。再委託はその二段目で、委託先が同じことを別の者に対して行う関係です。再委託先がさらに別の者に出す再々委託以降も、再委託と同じ扱いとされています。 ## 委託元は何を確かめるのか ガイドライン 3-4-4(3) は、委託先が再委託を行おうとする場合、委託を行う場合と同様に、次のことが望ましいとしています。 1. 再委託する相手方、再委託する業務内容、再委託先での個人データの取扱方法について、委託先から事前に報告を受けるか、承認を行うこと。 2. 委託先が再委託先に対して委託先の監督を果たしていることを、委託先を通じて、または必要に応じて自ら、定期的に監査を行って確かめること。 3. 再委託先が法 23 条に基づく安全管理措置(個人データを守る対策)を行っていることを、同じ方法で確かめること。 求め方は「望ましい」です。ただし ※4 には次の記述があります。委託元が委託先を監督していない状態で再委託先が不適切な取扱いを行ったときは、元の委託元の法違反と判断され得る、というものです。監督を行っていない事例としても、再委託の条件を指示せず確認も怠った場合と、契約に再委託の把握を盛り込みながら報告を求めなかった場合が挙げられています。再委託を知らなかったことは、委託元の責任を軽くする方向には働かないと読めます。委託先の監督の全体は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 ## 再委託先のアカウントをどう把握するか 自社のアカウントが再委託先に渡る経路は 2 つです。委託先の担当者ごとに発行したアカウントを再委託先の人が使う場合と、委託先に渡した共有アカウントが再委託先にも配られる場合です。どちらも、自社の記録には委託先の担当者か共有アカウントの名前で残り、再委託先の存在は見えません。 把握は、再委託の事前報告に「使うアカウント」を含めることから始めます。再委託先の名前と業務内容に加えて、再委託先の人が自社のどのシステムにどのアカウントで入るかを書いてもらいます。担当者ごとに発行する形なら、再委託先の人にも一人ひとり発行し、委託先の担当者のユーザーを共有させない、と決めておけます。 共有アカウントを渡している場合は、パスワードを知っている人に再委託先が含まれるかを、委託先への確認事項に加えます。定期的な確認では、自社のシステムのユーザー一覧と、報告された担当者の一覧を突き合わせます。報告にない人が入っていれば、再委託・共有・報告漏れのどれかが起きています。渡し方ごとの違いは[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にまとめています。 ## よくある質問 **委託先がフリーランスに作業を出すのも再委託ですか** ガイドラインは委託を「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることとしています。受けた業務で個人データを扱わせれば、相手が個人でも再委託に当たると読めます。 **再委託は禁止すべきですか** ガイドラインは禁止を求めていません。相手方・業務内容・取扱方法について事前に報告を受けるか承認し、再委託先の安全管理措置を確かめることが望ましいとしています。 **再委託先が事故を起こしたら委託元の責任ですか** 委託元が委託先への必要かつ適切な監督を行っていない場合、再委託先の不適切な取扱いは元の委託元の法違反と判断され得る、とガイドラインは述べています。 **再委託先が自社のシステムを使っているか分かりますか** 自社の記録には委託先の担当者か共有アカウントの名前で残るので、そのままでは見えません。再委託の報告に使うアカウントを含め、自社のユーザー一覧と報告された担当者の一覧を突き合わせます。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify では、委託先の担当者が自分のスマホで本人確認をしてから自社のアカウントを使います。パスワードを渡さないので、共有パスワードが再委託先に配られることはなく、利用は割り当てた担当者ごとに記録されます。契約終了時はその担当者の割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 委託先の監督とは 個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守る対策)が行われるよう確かめること(個人情報保護法 25 条)。ガイドラインは選定・契約・取扱状況の把握の 3 点を挙げています。 更新日: 2026-09-18 委託先の監督とは、個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守るために行う対策)が行われるよう確かめることです。個人情報保護法 25 条が委託元に求めています。 ## 委託先の監督とは何を指すか 法 25 条の条文は次のとおりです。「個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。」平たく言えば、個人データの扱いを任せた相手がその情報をきちんと守っているか確かめる責任は、任せた側に残る、ということです。 ここでいう委託は、個人情報保護委員会のガイドライン(通則編)3-4-4 ※1 に説明があります。「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることです。契約の名前が業務委託か請負かではなく、個人データを扱わせるかどうかで決まると読めます。委託先に求める水準は、法 23 条の安全管理措置と同等です。自社が 23 条の水準を超える対策を行っている場合でも、委託先には 23 条の水準で足りると読めます(※2)。 ## 監督として何をするのか ガイドライン 3-4-4 は、委託する個人データの内容や量に応じたリスクに合わせて、3 点を行うよう求めています。3 点はいずれも行わなければならない措置です。ただし、各項目の中身をどの強さで求めているかは分かれます。 ### (1) 適切な委託先の選定 別添の各項目が、委託する業務に沿って行われることを、委託前に確かめます。ガイドラインはこれを「あらかじめ確認しなければならない」としています。 ### (2) 委託契約の締結 双方が同意した安全管理措置の内容と、取扱状況を委託元が把握できることを契約に書きます。ガイドラインはこれを「盛り込むことが望ましい」としています。 ### (3) 委託先における個人データ取扱状況の把握 定期的な監査などで契約内容の実施の程度を調べ、委託の内容の見直しも含めて評価します。ガイドラインはこれを「適切に評価することが望ましい」としています。 確認の方法について、ガイドラインは、個人データを取り扱う場所に出向くか、それに代わる合理的な方法(無理のない別の方法。口頭による確認を含む)を挙げています(※3)。書面の質問票、訪問、担当者への聞き取りは、どれもこの方法の一つと読めます。委託先が再委託を行う場合の確認は[再委託とは](/guides/outsourcing-access/what-is-subcontracting)で扱っています。 ## 監督を行っていないとされる例 ガイドラインは、監督を行っていない事例を 4 つ挙げています。委託先の安全管理措置の状況を契約時にもその後も把握しなかった場合と、必要な措置の内容を指示しなかった場合です。ほかに、再委託の条件を指示せず確認も怠った場合と、契約に再委託の把握を盛り込みながら報告を求めなかった場合があります。いずれも、その結果として個人データが漏えいした場合です。 ## アカウントの扱いとどう関係するか 委託先に自社のアカウントを使わせる場合、委託先での個人データの取扱いはそのアカウントを通して行われます。担当者ごとに発行していれば自社の記録から委託先の誰がいつ入ったかが分かり、共有アカウントでは把握を委託先の作業記録に頼ることになります。渡し方の違いは[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にまとめています。委託を受ける側から見た整理は[運用代行におけるアカウントの預かりとは](/guides/agency-accounts/what-is-delegated-account-access)にあります。 ## よくある質問 **個人データを扱わない委託にも監督は要りますか** 25 条の対象は個人データの取扱いの委託です。含まれない業務には法令上の監督義務はなく、委託先のアカウントの扱いは契約と運用で決めることになります。 **委託契約を結べば監督は済みますか** 契約は 3 点の一つです。3 点はいずれも行わなければならず、契約後も取扱状況の把握が求められます。把握の方法として定期的な監査などが「望ましい」とされています。 **委託先の確認には訪問が必要ですか** ガイドラインは、個人データを取り扱う場所に出向くか、それに代わる合理的な方法(無理のない別の方法。口頭による確認を含む)を挙げています。質問票や聞き取りもその一つと読めます。 **委託先の側にも個人情報保護法の義務がありますか** あります。ガイドラインは、法律上は、委託先は法 23 条が求める水準の安全管理措置を行えば足りる、としています。委託先自身が個人データを守る対策を負う立場です。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** Junify は、委託先の担当者に自社のアカウントのパスワードを渡さずに使わせる仕組みです。誰が・いつ・どのアカウントを使ったかは委託先の担当者ごとに記録され、取扱状況の把握に使えます。契約終了時はその担当者の割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 委託先が「共有 ID で作業しています」と答えたときの確認事項 確かめるのは 4 点です。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法です。答えられなければ、担当者ごとの発行に切り替える、アクセス管理ツールを挟む、業務範囲を絞る、のどれかを選びます。 更新日: 2026-09-18 委託先が「共有 ID で作業しています」と答えたとき、その場で判断するのは共有の有無ではなく、共有が管理された状態かどうかです。確かめるのは 4 点です。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法です。答えられなければ、3 つの選択肢から選びます。担当者ごとの発行に切り替える、アクセス管理ツールを挟む、共有 ID で扱う業務範囲を絞る、です。 ## まず区別すること 共有 ID には 2 種類あります。自社が委託先に渡した共有アカウントと、委託先が自社(委託先)の内部で使っている共有 ID です。どちらかで、委託元にできることが変わります。 自社が渡した共有アカウントであれば、発行に切り替えるか、ツールを挟むかを決められるのは自社です。委託先は渡された 1 つを共有するほかなく、共有をやめる手段を持ちません。自社が渡す形を変えるときの 3 つの型は[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にあります。 委託先の内部の共有 ID であれば、それは委託先の安全管理措置(個人データを守るために行う対策)の問題です。個人情報保護委員会のガイドライン(通則編)の別添は、行わなければならない技術的安全管理措置を挙げています。その一つが、アクセス者の識別と認証(使う人を見分け、本人と確かめること)です。IPA「組織における内部不正防止ガイドライン」第 5 版の対策 7 は、共有 ID と共有のパスワードを使わないよう求めています。利用者ごとの ID を、個別のパスワードで認証する形です。委託元は、自社に求められるものと同等の措置を委託先に求める立場です。この順で確かめたうえで、改善の期限を決めることになります。 ## 4 点の確認手順 4 点は、この順で聞きます。対象が決まらなければ範囲も手順も聞けず、範囲が答えられなければ変更手順は意味を持ちません。 ### 対象のアカウント どのシステムの、どの ID かを聞きます。自社が渡したものか、委託先のものかも確かめます。答えは自社の一覧と照合でき、一覧にないアカウントなら、渡した記録がない状態です。根拠は、別添の組織的安全管理措置 (3) 取扱状況を確認する手段の整備です。 ### パスワードを知っている人の範囲 氏名の一覧を出してもらい、退職した人、案件を離れた人、再委託先の人が含まれていないかを見ます。範囲を答えられなければ、誰でも入れる状態と同じです。根拠は、別添の技術的安全管理措置 (2) アクセス者の識別と認証と、IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版です。このガイドラインは、やむを得ず共有 ID を使う場合には、利用した人を特定できる仕組みを勧めています。 ### 担当交代時の変更手順 最後に変えた日、誰が変えるか、変えた後に誰へ配るかを聞きます。自社の共有アカウントなら、自社への依頼の経路も聞きます。最後の変更日が答えられなければ、辞めた人が知ったままの可能性があります。根拠は、別添の技術的安全管理措置 (1) アクセス制御(担当者の範囲の限定)です。 ### 誰がいつ使ったかを残す方法 業務日誌か作業記録か、誰が書き、どれだけの期間残すかを聞きます。記録がなければ、共有 ID の操作を人まで絞れません。根拠は、別添の組織的安全管理措置 (2) 規律に従った運用(業務日誌などによる検証)です。 判断は、自社側のログイン記録と突き合わせられる形かどうかで行います。共有 ID では、システムの記録は ID 単位でしか残りません。委託先の日誌に書かれた作業時間と、自社側のログイン時刻が合っていれば、人まで絞る材料になります。 答えは、チェックシートの備考か、委託先が使うアカウントの一覧に残します。次回の確認では、前回との違いを見ます。共有パスワードで起きやすい変化は、知っている人の範囲が広がることと、最後の変更日が更新されないことの 2 つです。 ある市の事案では、共有していたパスワードが人事異動や退職があっても固定されたままでした。知っている人がどこまで広がっているか、確認できない状態でした。詳しくは[無断の再委託先が個人データを持ち出した事案](/guides/incidents/undisclosed-subcontractor-copied-data)にあります。 ## 確認できないときの選択肢 どれか一つでも答えられないとき、共有のまま続けるわけにはいきません。選択肢は 3 つで、組み合わせて使えます。 | 選択肢 | 向く場合 | 委託元がすること | 残る限界 | | --- | --- | --- | --- | | 担当者ごとの発行に切り替える | ユーザーを追加できるシステム | 委託先の担当者一人ひとりにユーザーを発行し、切り替え時に共有していたパスワードを変える | ユーザーを追加できないシステムでは使えない | | アクセス管理ツールを挟む | SNS 公式や代表アドレスのように 1 つしかないアカウント | 自社が ID とパスワードをツールに登録し、委託先の担当者はツールを通して入る | システムから見た権限は共有アカウントのまま | | 共有 ID で扱う業務範囲を絞る | 上の 2 つがすぐにできない場合のつなぎ | 個人データを扱う作業を共有 ID から外し、発行したユーザーかツール経由に限る | 共有 ID そのものは残る | ツールを挟む場合、委託先の担当者はパスワードを見ませんが、ツールの導入と登録の手間はかかります。業務範囲を絞る場合は、絞った範囲を委託先が守っているかを確かめる作業が残ります。 業務範囲を絞る選択肢の根拠は、ガイドラインが「委託する業務内容に対して必要のない個人データを提供しないようにすることは当然」としている点です。共有 ID でしか入れないシステムに個人データを置かない。または、共有 ID の権限から個人データの閲覧を外す。どちらも、この考え方に沿います。 委託先の内部の共有 ID については、選択肢は委託先の側にあります。委託元がすることは、改善の内容と期限を決めて契約か覚書に書き、次回の確認で同じ順で聞き直すことです。期限までに改善されなければ、その委託先に個人データを扱わせる範囲を見直します。ガイドライン 3-4-4(3) は、契約で盛り込んだ内容の実施の程度を調べ、委託の内容の見直しも含めて評価することを望ましいとしています。 ## すべて答えられたときの扱い すべて答えられ、自社の記録と合っていれば、共有 ID は管理された状態と読めます。それでも、共有が続く限り、記録は ID 単位で、人まで絞るのは日誌との突き合わせに頼ることになります。ユーザーを追加できるシステムがあれば、答えが揃っている委託先でも、発行への切り替えを次の契約更新で検討します。切り替えは委託元の作業で、委託先に頼まなくても進められます。 ## よくある質問 **共有 ID があると答えた委託先は選べませんか** 管理の中身で判断します。すべて答えられ、自社の記録と合っていれば、管理された共有と読めます。答えられない点があれば、その点を解消する条件を付けて選ぶか、渡し方を変えます。 **共有 ID が自社のものか委託先のものかで何が違いますか** 自社が渡した共有アカウントなら、発行に切り替えるかツールを挟むかを自社で決められます。委託先の内部の共有 ID は委託先の安全管理措置の問題で、改善の期限を決めて次の確認で確かめます。 **「誰がいつ使ったか」は業務日誌で足りますか** ガイドラインの別添は、業務日誌の作成などを通じて取扱いの検証を可能にする手法を例示しています。自社側のログイン記録と日誌の作業時間が合っているかを突き合わせられれば、記録として使えます。 **4 点を確認した後は何をしますか** 答えをチェックシートの備考か一覧に残し、次回の確認で前回との違いを見ます。知っている人の範囲が広がった、最後の変更日が更新されていない、の 2 つが変化として現れやすい点です。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 委託先の誰が自社のどのアカウントを使うかを台帳で持ち、契約が終わるたびに止め、委託先での利用状況を定期的に確かめ続けることになります。 **Junify なら** 委託先が使う共有アカウントが自社のものなら、Junify に登録して、委託先の担当者にパスワードを渡さずに使わせられます。4 点のうち「知っている人の範囲」は自社の管理者だけになり、「誰がいつ使ったか」は担当者ごとに委託元の記録に残ります。交代時はその人の割り当てを外すだけで、パスワードの変更と配り直しは要りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=bpo) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。 - [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](/guides/outsourcing-access/building-a-security-questionnaire): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。 - [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。 --- # 管理者用アカウント(特権 ID)の管理 管理者用アカウント(特権 ID)は、サービスの設定や他の人の権限を変えられる強い権限の ID です。個人に分けられる権限は分け、残る共有の管理者アカウントは誰が使ったかを残せる形にします。 更新日: 2026-09-18 管理者用アカウントの管理で決めることは 3 つです。誰に管理者の権限を持たせるか、共有のまま残る管理者アカウントを誰にどう使わせるか、そして使った記録をどう残すかです。 ## 管理者用アカウントとは何か 管理者用アカウント(特権 ID)とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サービスの設定を変える、他の人のアカウントや権限を変える、契約や支払いを変える、といった操作ができます。サーバーの管理者だけでなく、クラウドや SaaS(インターネット経由で使う業務ソフト)の管理者アカウント、ドメインや決済の管理画面の ID も含みます。定義と範囲は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。 ## なぜ複数人で共有されがちか 共有される理由は、アカウントの作りと使い方の 2 つに分けて考えられます。 作りの理由は、人数分のアカウントを作れないことです。管理者アカウントを 1 つしか作れないサービスがあり、使う人が複数いれば共有になります(例は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)に挙げています)。ID 管理サービスとつなげない管理画面も同じです。ID 管理サービスとは、Okta や Microsoft Entra ID のことです。社員のアカウントをまとめて管理し、一度のログインで複数のサービスに入れるようにします。個人の ID ではログインできないため、管理画面の ID とパスワードを複数人で使うことになります。ドメインや決済の管理画面をつなげられるかは、サービスごとに公式ヘルプで確認します。 使い方の理由の例は当番制です。夜間や休日の対応を交代で受け持つ運用では、その時間の担当者が同じ管理者アカウントで入ります。この運用は珍しくないでしょう。退職時のパスワード変更や、誰が操作したか残らないといった共有アカウント一般の問題は、[共有アカウントの管理](/guides/shared-accounts)で扱っています。管理者用アカウントにもそのまま当てはまります。 ## 何が問われるか 管理者用アカウントで問われるのは、誰が・いつ・何をしたかを出せるかです。金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」は、2.3.1「認証・アクセス管理」に基本的な対応事項を並べています。そこでは、特権アカウント(管理者用アカウント)の利用を厳格に制限し、管理すること(使える人と場面を絞り、使い方を決めておくこと)を求めています。同じ 2.3.1 の別の項目で、アクセスした人を特定できるようにし、処理内容を記録して操作した人と対応づけることも求めています。金融機関向けの文書ですが、管理者用アカウントに何を求めるかの整理として読めます。政府機関向けの「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版)にも、クラウドサービスの利用の基準(要機密情報を扱う場合の基準)があります。管理者権限を利用者に持たせる場合に、アクセス管理と操作の確実な記録を求めています。 上場企業の内部統制報告(J-SOX)では、IT 全般統制(会計の数字を作るシステムを支える土台の管理)に関わります。金融庁の「財務報告に係る内部統制の評価及び監査の基準・実施基準」は、IT 全般統制の例に「内外からのアクセス管理などシステムの安全性の確保」を挙げています。実施基準に特権 ID という語はありません。管理者用アカウントの扱いは、このアクセス管理の中で確かめられると読めます。 ## 管理の選択肢 共有のまま残る管理者アカウントを複数人で使う方法は、4 つに分けられます。 | 方法 | できること | 残る限界 | 向く場面 | | --- | --- | --- | --- | | 台帳と貸出の記録 | 誰がいつ借りたかを台帳に書く | 返した後も、借りた人はパスワードを知っている | 使う人が数人 | | ID 管理サービスが代わりに入力 | パスワードを見せずに使わせ、誰がいつ入ったかをサインインの記録に残す | 対象は ID 管理サービスにアカウントのある人 | 使う人が全員 ID 管理サービスにアカウントを持つ | | 特権 ID 管理(PAM)の製品 | 利用の申請と承認、権限の付与、操作の記録を 1 つの仕組みで行う | サーバー中心か、ブラウザーで使う管理画面も含むかは製品ごとに確認する | 使う前に申請と承認を置く | | パスワードを見せずに使わせる仕組み(アクセス管理ツール) | 担当者に代わってパスワードを入力し、本人確認した人ごとに利用を記録する | 対象アプリと端末の条件は製品ごとに確認する | ID 管理サービスにアカウントのない人も使う | 台帳は道具なしで始められますが、記録は自己申告になります。操作の記録をサービス側で出せるアカウントに向きます。ID 管理サービスが代わりに入力する機能は、Okta では SWA、Microsoft Entra ID では password-based SSO という名前で、預かったパスワードを権限のある人に代わりに入力します。Entra ID は、利用者ごとに EMS または P1/P2 の契約プランが前提です。特権 ID 管理の製品は、サーバーの管理者 ID も同じ仕組みで扱いたいときに向きます。アクセス管理ツールは、本人単位の記録が要るときに向きます。 4 つはどれか 1 つを選ぶものではなく、アカウントごとに組み合わせられます。特権 ID 管理(PAM)の中身は[特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam)にまとめています。パスワードマネージャーで共有する方法は[共有アカウントの管理](/guides/shared-accounts)で扱っています。 ## 既存の ID 管理サービスとの関係 Okta や Microsoft Entra ID を使っている会社でも、上の選択肢は ID 管理サービスを置き換えるものではありません。社員一人ひとりの ID と、ID 管理サービスに認証を任せられるアプリへのログインは、これまでどおり ID 管理サービスが受け持ちます。入退社に合わせたアカウントの作成・削除も同じです。その外に残るのが、1 つしか作れない管理者アカウント、つなげない管理画面、ID 管理サービスにアカウントのない人(短期の担当者や社外の技術者)です。全員に個人アカウントを発行でき、対象のサービスがすべてつながるなら、ID 管理サービスだけで足ります。残るものがあるときに、残る分だけを上の表から選びます。 ## 何から始めるか 管理者用アカウントの一覧を作るところから始めます。サービス名、管理者権限を持つ ID、1 つしか作れないものか、ID 管理サービスとつながるか、いま使っている人、緊急時にだけ使うものかを書き出します。誰に権限を持たせるかと、共有のまま残るものをどう扱うかは、この一覧を見て決めます。 次に、個人に権限を与えられるものは個人に分けます。Google Workspace の公式ヘルプは、特権管理者を少なくとも 2 人置くよう勧めています。1 人がパスワードを忘れても、もう 1 人が再設定できるためです。Microsoft 365 の公式ドキュメントは、グローバル管理者(Microsoft 365 の最上位の管理者)をできるだけ少なくするよう勧めています。作業に必要な最小の権限の種類を与えることも勧めています。同時に、グローバル管理者が締め出されたときにパスワードを戻せる管理者を置くことも勧めています。AWS は、ルートユーザーを日常の作業に使わず、ルートユーザーにしかできない作業に限るよう勧めています。個人の ID に必要な範囲の管理者権限を付けられるサービスでは、この形にすれば共有はなくなります。 最後に、それでも残る共有の管理者アカウントの扱いを決めます。使う人が全員 ID 管理サービスにいるか、本人単位の記録が要るか、サーバーの管理者 ID も同じ仕組みで扱うかで、上の表から選びます。普段は使わない予備のアカウント(緊急用アカウント)は、日常の共有アカウントとは分けて、保管の場所と使ったときの見直しを決めます。考え方は[緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account)にまとめています。 ## このテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 - [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 - [IT 全般統制(J-SOX)で管理者用アカウントについて問われること](/guides/privileged-access/itgc-and-privileged-ids): 実施基準は「内外からのアクセス管理」を IT 全般統制の例に挙げ、評価は記録の閲覧や質問で行われます。用意するのは、管理者用アカウントの一覧、権限の付与・変更・削除の記録、利用の記録、定期的な見直しの記録です。 - [ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか](/guides/privileged-access/non-saml-admin-consoles): まず公式ヘルプで、担当者ごとの ID を追加できるか、権限を分けられるかを確かめます。追加できるなら個人の ID にし、1 つしか作れないものは共有として貸出の記録、二段階認証の宛先、パスワードを変える場面を決めます。 - [管理者用アカウントの監査で示せるようにしておく記録](/guides/privileged-access/privileged-access-audit-records): 公的な資料が求めるのは、誰が・いつ・どのアカウントで・何をしたかがつながる記録と、権限の付与・削除と見直しの記録です。金融庁、内閣官房、IPA の 4 つの文書は、改ざんの防止と定期的な点検も共通して求めています。 - [緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account): 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。 - [特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam): 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。 - [特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id): 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。 ## よくある質問 **管理者アカウントを 1 人だけが持つのは安全ですか** その人がパスワードを忘れたり締め出されたりしたときに、戻せる人がいなくなります。Google Workspace は特権管理者を 2 人以上置くよう勧め、Microsoft 365 も戻せる人を置くよう勧めています。 **特権 ID の監査では何を出すよう求められますか** 金融庁のガイドラインは、特権アカウントの利用の制限と、アクセスした人を特定して操作内容と対応づけた記録を求めています。誰が・いつ・何をしたかを出せる状態が目安です。 **Okta や Entra ID があれば特権 ID の管理は済みますか** 全員に個人の ID を発行でき、対象のサービスがすべて ID 管理サービスとつながるなら足ります。1 つしか作れない管理者アカウントや、つなげない管理画面が残るときは、その分の管理方法を別に決めます。 **PAM の製品は SaaS の管理画面にも使えますか** IPA のガイドラインでは、特権 ID 管理は特権の利用申請・権限付与・操作の記録を管理する技術です。サーバー中心か、ブラウザーで使う管理画面も対象かは、製品ごとに公式ドキュメントで確認します。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」(2023 年 4 月 7 日改訂)](https://www.fsa.go.jp/singi/singi_kigyou/kijun/20230407_naibutousei_kansa.pdf) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「About administrator roles in the Microsoft 365 admin center」](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles) - [AWS Identity and Access Management ユーザーガイド「AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) - [Google Workspace 管理者ヘルプ「Pre-built administrator roles」](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify は、管理コンソールのパスワードを、使う人が誰も知らない状態にする仕組みです。管理者が ID とパスワードを登録して担当者に割り当て、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。誰が・いつ・どのコンソールに入ったかは一人ひとり残り、退職時は管理者が割り当てを外すだけです。Okta や Entra ID はそのままで、IP 制限も外しません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # AWS のルートユーザー・管理者アカウントを複数人で使うときの管理 AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 更新日: 2026-09-18 AWS のルートユーザーは、複数人で日常的に使うものではなく、保管しておいて限られた作業にだけ使うものです。AWS の公式ドキュメントは、日常の作業をルートユーザーで行わないよう強く勧めています。日常の管理者は個人の ID で作り、ルートユーザーは MFA(多要素認証。パスワードに加えて 2 つ目の方法で本人を確かめること)を付けて、使ったら記録が残る形にします。 ## ルートユーザーとは何か AWS アカウントを作ると、最初に 1 つのログイン ID ができます。アカウント内のすべてのサービスと資源に完全にアクセスできるこの ID がルートユーザーで、アカウント作成時のメールアドレスとパスワードでログインします。公式ドキュメントは、ルートユーザーの認証情報を保護し、ルートユーザーにしかできない作業にだけ使うよう求めています。ルートユーザーの MFA は既定で必須になっており、最初のログインから 35 日以内に登録しないとマネジメントコンソールに入れなくなります。管理者用アカウントの中での位置づけは[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。 ## ルートユーザーにしかできない作業 公式ドキュメントが挙げる作業は、アカウントそのものと支払いに関するものが中心です。 - アカウントの管理: ルートユーザーのメールアドレス・パスワード・アクセスキーの変更と、アカウントの解約。どちらも、AWS Organizations に入っていない単独のアカウントの場合です。 - 権限の復旧: 唯一の IAM 管理者が誤って自分の権限を消したときに、ログインして戻すこと。 - 請求: 請求とコスト管理のコンソールへの IAM アクセスの有効化、一部の請求作業、一部の税の請求書の閲覧。 - 特定のサービス: 設定の誤りで誰も操作できなくなった保存領域やキューの修正、一部のサービスの申込みや出品者登録など。 それ以外の作業はルートユーザーで行う必要がない、というのが公式ドキュメントの整理です。日常の設定変更や運用を担当者がルートユーザーで行っている場合は、次の節の形に移せます。 ## 日常の管理者は個人の ID にする 公式ドキュメントは、日常の作業とリソースへのアクセスのために、AWS IAM Identity Center に管理者ユーザーを作るよう勧めています。IAM Identity Center は、社内の利用者を AWS アカウントやアプリケーションにつなぐ AWS の仕組みです。すでに使っている ID 管理サービス(Okta、Microsoft Entra ID など)や Active Directory とも接続できます。接続すると、利用者とグループを同じ内容にそろえられます。IAM Identity Center の中に利用者を直接作ることもできます。複数の AWS アカウントへのアクセスを一か所で管理し、管理者などの職務ごとの権限のまとまり(許可セット)を利用者やグループに与えられます。 IAM のセキュリティのベストプラクティスは、人間の利用者には ID 管理サービスと連携した一時的な認証情報を使わせることを挙げています。MFA を必須にすること、最小限の権限にすること、使われていない利用者や権限を定期的に見直して削除することも並んでいます。IAM ユーザー(パスワードやアクセスキーを長く持ち続ける ID)は、一時的な認証情報を使えない場合に限るとされています。この形にすると、誰がどの権限で入ったかが個人の ID で残ります。 ## 複数人で使わざるを得ないルートユーザーの扱い ルートユーザーは 1 つしか作れないため、担当者が交代しても同じ ID を使うことになります。公式ドキュメントのルートユーザーのベストプラクティスは、次の扱いを挙げています。 - ルートユーザーのパスワード、MFA、アクセスキーは、厳密な業務上の必要がある人以外と共有しない。パスワードの保管場所へのアクセスは記録して監視し、2 人以上の承認を要する形を検討する。 - パスワードを持つ管理者のグループと、MFA を持つ管理者のグループを分け、両方から 1 人ずつそろわないとログインできない形(複数人承認)を可能な限り使う。 - ルートユーザーのメールアドレスは、個人ではなく、会社が管理し複数の人に転送されるグループアドレスにする。担当者の休暇や退職で AWS からの連絡が止まらないようにするためです。 - ルートユーザーのアクセスキー(プログラムから操作するための鍵)は作らない。 - MFA は複数登録する(最大 8 台)。1 台が壊れても別の 1 台で入れる。 - 復旧に使うメールの受信箱と電話番号は、同じ人が両方にアクセスできないよう、別のグループが管理する。 複数の AWS アカウントを AWS Organizations でまとめている場合は、メンバーアカウントのルートユーザーの認証情報を中央で削除できます。削除すると、そのアカウントではルートユーザーでのログインもパスワードの再設定もできなくなります。Organizations で新しく作るアカウントは、既定でルートユーザーの認証情報を持ちません。ルートユーザーにしかできない作業の一部は、管理アカウントから行えます。 ## 使った記録をどう残すか AWS CloudTrail は、コンソールやプログラムからの操作をイベントとして記録し、誰が何をいつ行ったかを確かめられるサービスです。直近 90 日分の管理イベントはイベント履歴として無料で検索・ダウンロードでき、それより長く残すにはトレイル(S3 への保存)を作ります。ルートユーザーのベストプラクティスは、ルートユーザーのログインと利用を監視・通知・報告するよう勧め、通知の仕組みの例を挙げています。 ただし、ルートユーザーは 1 つの ID なので、CloudTrail の記録には「ルートユーザー」としか残りません。公式ドキュメントはパスワードの保管場所へのアクセスの記録と監視を勧めているので、その記録と複数人承認の記録が、誰が使ったかの手がかりになります。 ## よくある質問 **ルートユーザーのメールアドレスは担当者個人のものでよいですか** 公式ドキュメントは、会社が管理し複数人に転送されるグループアドレスを勧めています。担当者の退職や休暇で AWS からの連絡が止まらないようにするためです。他の用途に使わないことも求めています。 **ルートユーザーの MFA は 1 台のスマホでよいですか** 最大 8 台まで登録でき、公式ドキュメントは複数登録を強く勧めています。1 台が壊れたり紛失したりしても、別の MFA で入れるためです。 **管理者は IAM ユーザーで作ってはいけませんか** 公式ドキュメントは IAM Identity Center の利用者と一時的な認証情報を勧めています。IAM ユーザーはパスワードやアクセスキーを長く持つため、一時的な認証情報を使えない場合に限るとしています。 **ルートユーザーが使われたことは分かりますか** CloudTrail にログインと操作が記録され、ルートユーザーのログイン時に通知する設定を組めます。誰が使ったかは記録に残らないため、保管場所へのアクセスの記録で補います。 ## 参考資料 - [AWS Identity and Access Management ユーザーガイド「AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) - [AWS Identity and Access Management ユーザーガイド「Multi-factor authentication for AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html) - [AWS Identity and Access Management ユーザーガイド「Root user best practices for your AWS account」](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html) - [AWS Identity and Access Management ユーザーガイド「Security best practices in IAM」](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) - [AWS IAM Identity Center ユーザーガイド「What is IAM Identity Center?」](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) - [AWS CloudTrail ユーザーガイド「What Is AWS CloudTrail?」](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify は、ルートユーザーのように 1 つしか作れない ID の保管場所になります。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてから使うため、誰が・いつ使ったかが一人ひとり残ります。認証アプリ方式(仮想 MFA デバイス)なら、そのコードも Junify が入力し、パスワードもコードも担当者に渡りません。担当を外れたら割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 - [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 --- # SaaS の管理者用アカウントを管理する方法の比較 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 更新日: 2026-09-18 SaaS(インターネット経由で使う業務ソフト)の管理者用アカウント(特権 ID)を複数人で使う方法は、担当者がパスワードを知るかと、誰が使ったかがどの単位で残るかで選びます。使う前に申請と承認を置きたいかも分かれ目です。台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールを、7 つの点で比べます。他社製品の事実は公式ドキュメントで確認できた範囲だけを書き、特権 ID 管理(PAM)の製品は公的な資料の範囲で書きます(製品名は挙げません)。確認できない項目は「—(未確認)」としています。 ## 比較する 4 つの方法 | 方法 | 何をするか | 確認した資料 | | --- | --- | --- | | ①台帳と貸出の記録 | 誰がパスワードを知っているか、いつ誰が借りたかを台帳に書く | なし(道具を使わない) | | ②ID 管理サービスが代わりに入力 | Okta や Microsoft Entra ID に ID とパスワードを預け、そこにログインした人に代わりに入力する | Okta Help Center、Microsoft Learn | | ③特権 ID 管理(PAM)の製品 | 管理者用アカウントの利用申請と承認、権限の付与、操作の記録を 1 つの仕組みで行う | IPA、金融庁、内閣官房のガイドライン | | ④アクセス管理ツール(Junify を含む) | 本人確認した担当者にパスワードを見せずに代わりに入力し、ログイン後の操作まで管理・記録する | Junify の製品ページ | ②の機能の名前は、Okta では Secure Web Authentication(SWA)、Microsoft Entra ID では password-based SSO です。 パスワードマネージャーの共有機能は、見る権限があれば担当者にパスワードが見える点が部門の共有アカウントと同じです。そのため、[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)で扱っています。特権 ID 管理の定義は[特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam)にあります。 ## 比較表 比べる点が 7 つあるため、表を 2 つに分けます。④の列は Junify の製品ページの範囲で書いています。 | 比べる点 | ①台帳と貸出の記録 | ②ID 管理サービス | ③特権 ID 管理(PAM)の製品 | ④アクセス管理ツール(Junify) | | --- | --- | --- | --- | --- | | 担当者がパスワードを知るか | 借りた人が知り、返した後も知っている | 知らない | —(未確認) | 知らない | | 誰が使ったかの記録の単位 | 台帳への申告 | 誰がいつどのアプリにサインインしたかが、ID 管理サービスの記録に残る | 利用申請と操作の記録を対応づける(IPA の定義) | 本人確認した人ごと。CSV で出せる | | 退職時の操作 | パスワードを変えて残る全員に配り直す | Okta はアプリの利用の許可を外す。Entra ID はグループから外す | 権限の付与を取り消す(内閣官房のガイドライン) | 使える人からその人を外す。変更と配り直しは不要 | | 二段階認証の扱い | 1 人のスマホや電話番号に頼る | —(未確認) | 特権アカウントの管理の例に多要素認証が挙がる(金融庁のガイドライン) | 認証アプリ方式のコードは Junify が入力。SMS・メールは対象外 | | 比べる点 | ①台帳と貸出の記録 | ②ID 管理サービス | ③特権 ID 管理(PAM)の製品 | ④アクセス管理ツール(Junify) | | --- | --- | --- | --- | --- | | ログイン後の管理 | なし | —(未確認) | 操作の記録。デュアルロックやワークフローの例(内閣官房のガイドライン) | 録画、ダウンロードの許可・禁止、アップロードの検知、遠隔でのログイン状態の終了 | | 前提 | なし | 使う人が ID 管理サービスにアカウントを持つ | サーバー中心か、ブラウザーで使う管理画面も対象かは製品ごとに確認する | スマホの Junify アプリとブラウザーの拡張機能。管理画面側の IP 制限と設定はそのまま | | 向く規模・状況 | アカウントが数件、使う人が数人 | 使う人が全員 ID 管理サービスにいて、記録が「誰がいつ入ったか」で足りるとき | 使う前に申請と承認を置きたい。サーバーの管理者 ID も同じ仕組みで扱いたい | 人とアカウントが 1 対 1 でない、ID 管理サービスに載せない人がいる、ログイン後の記録が要るとき | ## 表の根拠 「—(未確認)」とした 3 つの理由を挙げます。③のパスワードの扱いは、公的な資料に、パスワードを本人に見せずに貸し出す方式の記述がないためです。②の二段階認証は、管理画面側のコードの扱いが公式ドキュメントで明示されていないためです。②のログイン後の管理は、公式ドキュメントに記述がないためです。 ③について補うと、内閣官房のガイドラインは、一時的に付けた権限を作業終了後に削除するとしています。デュアルロックとは、複数人の認証がなければ処理を終えられない仕組みです。二段階認証の方式は製品ごとに違います。 ②の事実は Okta Help Center と Microsoft Learn で確認したものです。Okta の共有設定のパスワードを表示できるのは管理者だけで、Entra ID も利用者にはパスワードを見せません。記録と退職時の操作の詳しい内容は[Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins)にあります。Entra ID の公式ドキュメントからは、担当者側の前提として 3 つを確認できます。使う人ごとの EMS または Entra ID P1/P2 の契約プラン、My Apps の拡張機能、HTML のサインインページを持つアプリです。③の記述は、金融庁のガイドライン 2.3.1、内閣官房のガイドライン 7.1.3、IPA の中小企業向けガイドラインの定義によるものです。各文書が求める記録は[管理者用アカウントの監査で示せるようにしておく記録](/guides/privileged-access/privileged-access-audit-records)にまとめています。 ## この比較で Junify が要らない場合 全員に個人の管理者アカウントを発行できるなら、この比較自体が要りません。Google Workspace や Microsoft 365 のように管理者権限を個人の ID に付けられるサービスでは、個人に分ければ足ります。共有のまま残る管理者アカウントも、使う人が全員 ID 管理サービスにアカウントを持つなら、ID 管理サービスの代わりに入力する機能で扱えます。記録が「誰がいつ入ったか」で足りることが条件です。使う前に申請と承認を置くことを決めていて、サーバーの管理者 ID も同じ仕組みで扱いたいなら、特権 ID 管理の製品が対象になります。アクセス管理ツールを検討するのは、これらに当てはまらない条件が残るときです。ID 管理サービスにアカウントのない人が使う、ログイン後の操作まで記録したい、認証アプリのコードを 1 人のスマホから外したい、などです。 ## よくある質問 **特権 ID 管理の製品とアクセス管理ツールは同じものですか** IPA の定義では、特権 ID 管理は利用申請・権限付与・操作の記録を管理する技術です。アクセス管理ツールは本人確認した人にパスワードを見せずに代わりに入力する仕組みで、申請と承認の有無が違います。 **台帳のままでよいのはどんなときですか** 管理者用アカウントが数件で使う人も数人、退職のたびにパスワードを変えて配り直せるときです。誰が使ったかは申告に頼るため、管理者以外が台帳を定期的に確認する運用を添えます。 **ID 管理サービスで足りるのはどんなときですか** 使う人が全員 Okta や Entra ID にアカウントを持ち、記録が誰がいつサインインしたかで足りるときです。Entra ID は使う人ごとの契約プランと拡張機能が前提です。 **パスワードマネージャーはこの比較に入りませんか** 部門の共有アカウントと同じ扱いになるため、共有アカウントの比較記事で扱っています。管理者用アカウントに使う場合も、見る権限があれば担当者にパスワードが見える点は同じです。 ## 参考資料 - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [Okta Help Center「Unassign users from applications」](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-unassign-apps.htm) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) - [Junify の仕組み](https://www.junify.jp/product) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify では、管理者が管理コンソールの ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。パスワードは担当者に渡らず、認証アプリ方式のコードも Junify が入力し、誰が・いつ入ったかは一人ひとり残ります。録画や遠隔での終了はコンソールごとに設定でき、管理画面側の IP 制限はそのままです。担当を外れたら割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 - [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 --- # Google Workspace・Microsoft 365 の特権管理者アカウントの管理 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 更新日: 2026-09-18 Google Workspace と Microsoft 365 の管理者用アカウントは、個人の ID に管理者権限を付ける作りなので、共有せずに管理できます。公式ドキュメントが勧めることは 4 つに整理できます。最上位の管理者を少なくする、役割に応じた権限に分ける、二段階認証を必須にする、緊急用のアカウントを分ける、です。 ## 最上位の管理者を少なくする Google Workspace の最上位は特権管理者(Super Admin)です。管理コンソールのすべての機能を使え、組織のアカウントのあらゆる面を管理できます。公式ヘルプは、特権管理者アカウントを 2 つ以上置き、それぞれ別の個人が管理するよう勧めています。1 人が締め出されたときに戻せる人がいなくなるためです。同時に、特権管理者アカウントを日常の作業に使わないことと、管理者アカウントを複数人で共有しないことを求めています。共有しない理由として、管理者の操作の記録からどの管理者が行ったかを特定するためだと書かれています。 Microsoft 365 の最上位はグローバル管理者で、組織の設定とデータの大半にほぼ無制限にアクセスできます。公式ドキュメントは、グローバル管理者をできるだけ少なくするよう求め、Microsoft Entra ID のベストプラクティスでは 5 人未満を勧めています。5 人以上になると管理画面に警告が出ます。グローバル管理者が締め出されたときに戻せるよう、特権認証管理者を置くことも勧めています。 ## 役割に応じた管理者権限に分ける どちらのサービスにも、あらかじめ用意された管理者の権限の種類(ロール)があり、作業に必要な最小の権限を与えられます。名前は公式ドキュメントの英語表記で示します。 | 作業 | Google Workspace のロール | Microsoft 365 のロール | | --- | --- | --- | | 利用者の作成・削除・パスワードの再設定 | User Management Admin(管理者以外の利用者が対象) | User Administrator | | パスワードの再設定だけ | Help Desk Admin(管理者以外が対象) | Password Administrator、Helpdesk Administrator(管理者以外が対象) | | グループの管理 | Groups Admin | Groups Administrator | | サービスの設定 | Services Admin | Exchange Administrator、SharePoint Administrator、Teams Administrator など | | 端末の管理 | Mobile Admin | Intune の管理者ロール(別の管理センター) | | 契約・支払い | — | Billing Administrator | | 見るだけ | — | Global Reader | Microsoft の公式ドキュメントは、パスワードの再設定を頼みたいだけならグローバル管理者にしない、という例を挙げています。代わりに Password Administrator や Helpdesk Administrator を与えます。Entra ID には、必要なときだけ一定時間、承認つきで権限を有効にする Privileged Identity Management(PIM)もあります。権限が今も必要かを定期的に確認するアクセスレビューもあります。PIM は Entra ID P2 またはガバナンス、アクセスレビューはガバナンスの契約プラン(一部は P2)が要ります。 ## 管理者に二段階認証を必須にする Google の公式ヘルプは、管理者アカウントに二段階認証を必須にするよう求め、セキュリティキー(手元の小さな鍵型の機器)を最も安全な方式としています。方式は、セキュリティキー、Google からの確認、認証アプリのコード、バックアップコード、SMS・音声通話です。管理者は、利用者に対して任意にも必須にもできます。公式ヘルプは、Google が管理者アカウントに二段階認証を強制していることにも触れています。二段階認証そのものの説明は[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)にあります。 Microsoft は、管理者を含むすべての利用者に MFA(多要素認証)を必須にするよう求めています。それに加えて、Azure ポータルや Microsoft Entra 管理センターなどは 2024 年 10 月から、順次 MFA が必須になりました。Microsoft 365 管理センターは 2025 年 2 月からです。除外の設定はできず、緊急用のアカウントも MFA が要ります(パスキーか証明書が推奨)。 ## 緊急用のアカウントを分ける 日常の管理者アカウントとは別に、締め出されたときのためのアカウントを用意します。Microsoft は、2 つ以上の緊急用アカウントを、社内の認証の仕組みに頼らないクラウドだけのアカウントとして作るよう求めています。特定の個人に結びつけず、場所や端末の条件でログインを制限する設定から除外し、少なくとも 90 日ごとに使えることを確かめます。詳しくは[緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account)にまとめています。Google は、別々の個人が管理する複数の特権管理者アカウントを置くことに加えて、予備のセキュリティキーの登録を勧めています。バックアップコードをあらかじめ安全な場所に保存しておくことも勧めています。 ## 使った記録を確かめる Google の公式ヘルプは、管理者の操作の記録(管理ログイベント)を確認するよう勧めています。不審なログインや設定変更のときに管理者へメールで知らせる設定も勧めています。Microsoft のグローバル管理者はディレクトリの操作の記録を見られ、Entra ID にはサインインの記録があります。どちらも管理者が個人の ID なので、記録はその人の名前で残ります。 ## 共有のまま残るのは何か 管理者権限を個人の ID に付けられるこの 2 つのサービスでは、共有が要るのは主に緊急用アカウントです。緊急用アカウントは日常には使わず、使ったら記録を見直します。ほかに共有が残る場合の扱いと、ほかの管理画面も含めた全体の考え方は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)にあります。 ## よくある質問 **特権管理者・グローバル管理者は何人がよいですか** Google は 2 人以上、Microsoft は 5 人未満を勧めています。締め出しに備えて 1 人にしないことと、権限が広いので増やしすぎないことが、両社に共通する目安です。 **管理者は日常の作業用アカウントと分けるべきですか** Google の公式ヘルプは、特権管理者アカウントを日常の作業に使わず、管理作業のときだけログインして終わったらログアウトするよう求めています。日常の作業は別の利用者アカウントで行います。 **二段階認証を管理者だけ必須にできますか** Google は管理者が利用者に対して任意か必須かを設定でき、管理者アカウントには必須を求めています。Microsoft の管理センターは MFA が必須になっており、除外の設定はできません。 **緊急用アカウントは何個必要ですか** Microsoft は 2 つ以上を勧めています。Google は、別々の個人が管理する複数の特権管理者に加えて、予備のセキュリティキーの登録とバックアップコードの保管を勧めています。 ## 参考資料 - [Google Workspace 管理者ヘルプ「Pre-built administrator roles」](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles) - [Google Workspace 管理者ヘルプ「Security best practices for administrator accounts」](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts) - [Google Workspace 管理者ヘルプ「Protect your business with 2-Step Verification」](https://knowledge.workspace.google.com/admin/security/protect-your-business-with-2-step-verification) - [Microsoft Learn「About administrator roles in the Microsoft 365 admin center」](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles) - [Microsoft Learn「Best practices for Microsoft Entra roles」](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices) - [Microsoft Learn「Plan for mandatory Microsoft Entra multifactor authentication (MFA)」](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication) - [Microsoft Learn「Manage emergency access admin accounts - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) - [Microsoft Learn「Microsoft Entra ID Governance licensing fundamentals」](https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** 自社の Google Workspace や Microsoft 365 の管理者は、個人の ID と ID 管理サービスで足ります。Junify が担うのは、それでも共有で残る管理者アカウントです。自社の ID を持たない社外の技術者に使わせる場合や、担当者が交代で使う管理コンソールです。本人確認をした担当者だけが使え、誰が・いつ入ったかが一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 --- # Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。 更新日: 2026-09-18 Okta や Microsoft Entra ID がある会社でも、共有の管理者アカウントがすべてなくなるわけではありません。ID 管理サービスで扱える部分を先に確かめ、残る分をどこが受け持つかを決める役割分担の話です。 ## ID 管理サービスが受け持つこと ID 管理サービスは、社員一人ひとりの ID を持ち、社員はそこに一度ログインすれば、つながっているアプリに入れます。Microsoft Entra ID の公式ドキュメントは、利用者は普段デスクトップやメールに使うのと同じ組織のアカウントで一度サインインする、と説明しています。見えるのは自分に許可されたアプリだけです。管理者は誰がどのアプリを使えるかを決め、グループで付けたり外したりできます。入退社に合わせたアカウントの作成・削除も、対応するアプリではここで行います。 ## 共有の管理者アカウントも扱える SAML(ID 管理サービスとつなぐための規格)に対応していない管理画面でも、ID 管理サービスが預かった ID とパスワードを代わりに入力する機能があります。Okta では Secure Web Authentication(SWA)、Entra ID では password-based SSO という名前です。 | 項目 | Okta の SWA | Entra ID の password-based SSO | | --- | --- | --- | | 共有アカウントの設定 | 1 組の ID とパスワードを管理者が設定し、複数人で共有する方式がある | 管理者がグループにアプリの利用を許可し、そのグループの資格情報として登録する | | 担当者がパスワードを知るか | 知らない | 知らない | | 入力の仕組み | ブラウザーのプラグイン(Okta Browser Plugin)が自動で入力する | My Apps の拡張機能(Edge・Chrome)が入力する | | 誰が使ったかの記録 | Application Usage レポートに、誰がそのアプリにサインインしたかが出る | サインインの記録に残る | | 担当を外すとき | アプリの利用の許可を外す | グループから外す | | 前提 | Okta にアカウントがあること | 使う人ごとに EMS または Entra ID P1/P2 の契約プラン | パスワードの見え方は、どちらも担当者には見せない作りです。Okta では、共有設定のパスワードを表示できるのは管理者だけで、利用者は表示できません。Entra ID の利用者も実際のパスワードは見ず、Entra ID が代わりにログインします。My Apps の拡張機能は、初回起動時にインストールを促されます。 記録と担当を外す操作にも、細かい違いがあります。Okta はシステムログでアクセスの時刻も引けます。Entra ID の記録では、管理者が誰がいつアクセスしたかを確認できます。Okta でアプリの利用の許可を外すと、その人の My Apps から消えます。Entra ID では、グループの所有者が管理者を介さず追加・削除できます。 Entra ID の前提には、契約プランのほかに 2 つあります。HTML のサインインページ(ID とパスワードを入れる通常のログイン画面)を持つアプリであることと、1 人あたり 48 件までであることです。Entra ID は、共有アカウントを使う人に MFA(多要素認証)を求めることや、対応するアプリではパスワードを定期的に自動更新することもできると書いています。この範囲なら、ID 管理サービスだけで共有の管理者アカウントを扱えます。 ## それでも残る場面 残るのは、上の表の前提から外れる場面です。 1. ID 管理サービスにアカウントのない人が使う。兼務や短期の担当者、社外の技術者などです。Entra ID では使う人ごとに契約プランが要り、Okta では Okta のアカウントが要ります。人数分のアカウントと契約を用意するかどうかで決まります。 2. ログインした後の操作まで記録・管理したい。上の表の記録は「誰がいつどのアプリに入ったか」までです。入った後に何を見て何を持ち出したかについて、Okta と Entra ID の公式ドキュメントに記述はありません。監査で操作の記録まで求められる場合は、サービス側の記録か別の仕組みで補います。 3. 管理画面側の二段階認証のコードをどう扱うか。代わりに入力する機能が、管理画面側の認証アプリのコードをどう扱うかは、両社の公式ドキュメントでは明示されていません。Entra ID が書いているのは、Entra ID 側で MFA を求められることです。 なお、代わりに入力する仕組みは、Okta も Entra ID もブラウザーの拡張機能が要ります。 ## 役割分担の決め方 - 社員一人ひとりの ID と、SAML でつながるアプリは、ID 管理サービスが受け持ちます。本人確認と入退社の連動をここで行うためです。 - 使う人が全員 ID 管理サービスにいて、記録が「誰がいつ入ったか」で足りる共有の管理者アカウントは、代わりに入力する機能が受け持ちます。追加の仕組みなしで、パスワードを見せずに使わせられるためです。 - ID 管理サービスにいない人が使う共有の管理者アカウントと、ログイン後の記録が要るものは、別の仕組みが受け持ちます。台帳と貸出の記録、特権 ID 管理の製品、アクセス管理ツールのどれかです。ID 管理サービスの前提から外れるためです。 全員に個人アカウントを発行でき、ID 管理サービスの規格で認証と入退社と権限を管理しきれるなら、ID 管理サービスだけで十分です。残る分の扱いは、[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)の表から選びます。方法ごとの違いは[SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods)にあります。 ## よくある質問 **Okta があれば共有の管理者アカウントの管理は済みますか** 使う人が全員 Okta にアカウントを持ち、記録が誰がいつサインインしたかで足りるなら、SWA の共有設定で済みます。それ以外の人や、ログイン後の記録が要る場合は別の仕組みが要ります。 **Entra ID で共有アカウントを扱う前提は何ですか** 使う人ごとの EMS または Entra ID P1/P2 の契約プラン、Edge か Chrome の My Apps 拡張機能、HTML のサインインページを持つアプリです。1 人 48 件までです。 **代わりに入力する機能で担当者はパスワードを見られますか** Okta の共有設定では管理者だけが表示でき、利用者は表示できません。Entra ID の利用者も実際のパスワードは見ず、Entra ID が代わりにログインします。 **社外の技術者に一時的に管理画面を使わせるには** Entra ID や Okta にその人のアカウントを作れば代わりの入力を使えます。作らないなら、台帳と貸出の記録か、本人確認つきで代わりに入力する別の仕組みを使います。 ## 参考資料 - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [Okta Help Center「Unassign users from applications」](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-unassign-apps.htm) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify が担うのは、ID 管理サービスの外に残る共有の管理者アカウントと、つなげない管理画面です。Junify への本人確認は ID 管理サービスのログインに任せられ、Okta や Entra ID を置き換えません。ID 管理サービスにいない人は自分のスマホの Junify アプリで本人確認をし、記録は同じ形で一人ひとり残ります。ログイン後は録画や遠隔での終了を設定できます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # IT 全般統制(J-SOX)で管理者用アカウントについて問われること 実施基準は「内外からのアクセス管理」を IT 全般統制の例に挙げ、評価は記録の閲覧や質問で行われます。用意するのは、管理者用アカウントの一覧、権限の付与・変更・削除の記録、利用の記録、定期的な見直しの記録です。 更新日: 2026-09-18 上場会社の内部統制報告(J-SOX)で管理者用アカウント(特権 ID)について問われるのは、誰が強い権限を持ち、いつ誰が使ったかです。それを記録で説明できるかが見られます。IT 全般統制の定義と全体像は [IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc)にまとめています。 ## 実施基準はアクセス管理をどこで求めているか 金融庁の実施基準(財務報告に係る内部統制の評価及び監査に関する実施基準)には、IT 全般統制の例が並んでいます。その一つが「内外からのアクセス管理などシステムの安全性の確保」です。全般統制が働かない場合の例には「プログラムに不正な改ざんや不正なアクセスが行われる」ことを挙げています。対応の例の一つが「プログラムの不正な使用、改ざん等を防止するために、システムへのアクセス管理に関して適切な対策を講じる」ことです。監査人の側も、財務報告に関連するシステムやソフトウェアについて「適切なアクセス管理等の方針を定めているか確認する」とされています。 管理者用アカウントが特に見られる理由も、実施基準の記述から読めます。統制活動が自動化されていると、プログラムの不正な改ざんや不正な使用が起きたときに困る、という記述です。「プログラムに精通した者しか対応できず、不正等の適時の発見が困難になる」とあります。そのため、適切なアクセス管理等の措置に留意するよう求めています。プログラムやデータを直接変えられるのが管理者用アカウントです。実施基準に「特権 ID」という語はありませんが、この記述が根拠になります。 ## 評価はどのように行われるか IT 全般統制の運用状況の評価は、業務処理統制の運用状況の評価とあわせて行うとされています。実施基準がその評価の方法として挙げるのは、関連文書の閲覧、担当者への質問、業務の観察、内部統制の実施記録の検証、自己点検の状況の検討です。証拠は原則としてサンプリング(一部を抜き出して確かめること)で入手します。担当者への質問にも答えますが、運用されていたことは記録で示すことになり、記録がなければ示せません。 IT 全般統制の運用状況の評価には、継続利用の扱いがあります。前年度の評価結果が有効で、整備状況に重要な変更がない項目は、その旨を記録すれば前年度の結果を続けて使えます。財務報告の信頼性に特に重要な影響を及ぼす項目は除きます。この場合でも「重要な変更がない」ことを示す記録は要ります。 ## 用意しておく 4 つの資料 実施基準は、アクセス管理について具体的な資料名を挙げていません。[IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc)で挙げた 4 つを、管理者用アカウントに絞って書くと次のようになります。 1. 管理者用アカウントの一覧。どのシステムに、どの管理者用アカウントがあり、誰が持っているかを示します。実施基準の「内外からのアクセス管理」の対象を特定する資料です。 2. 権限の付与・変更・削除の記録。誰が、いつ、誰の承認で権限を得たか、外れたかを示します。「システムへのアクセス管理に関して適切な対策」が運用されている証拠になります。 3. 利用の記録。管理者用アカウントを、いつ誰が使い、何をしたかを示します。「不正な使用」を発見できる状態の証拠になります。 4. 定期的な見直しの記録。権限が今も必要な人だけに付いているかを、いつ誰が確かめたかを示します。運用状況の評価(実施記録の検証)に対応します。 4 つ目の見直しの記録は、実施基準に直接の文言はありません。金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」2.3.1 に近い記述があります。アカウントの定期的な棚卸し(何があるか一覧にすること)と操作履歴のレビュー、システム責任者による定期的なアクセスレビューを、基本的な対応事項に挙げています。金融機関向けの文書ですが、見直しの記録が何を指すかの目安になります。 ## 共有の管理者アカウントで困る点 1 つの管理者用アカウントを複数の担当者が使っていると、4 つの資料のうち 2 つが埋まりません。利用の記録は、システム側にはアカウントの名前しか残らないため、「いつ誰が使ったか」の「誰」が空欄になります。権限の付与・削除の記録も、「パスワードを教えた人」「教えるのをやめた人」の記録になり、退職した人がパスワードを覚えている状態は記録に現れません。共有のまま残る管理者アカウントを、誰が使ったか残せる形にする選択肢は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)の表にまとめています。 ## 対象になる範囲 実施基準は、IT 全般統制を、業務を管理するシステムを支える IT 基盤(ハードウェア、ソフトウェア、ネットワークなど)を単位に作るとしています。評価の対象は財務報告に関わるシステムとその基盤です。会計、販売、購買などのシステムがクラウドサービスで提供されている場合、その管理画面の管理者用アカウントも、そのシステムのアクセス管理に含まれると読めます。実施基準にクラウドや SaaS(インターネット経由で使う業務ソフト)の記述はないため、範囲は監査人と確認します。 ## よくある質問 **実施基準に「特権 ID」という言葉はありますか** ありません。あるのは「内外からのアクセス管理」と、不正な使用の発見が難しくなるためアクセス管理に留意する、という記述です。管理者用アカウントはその中で見られます。 **共有の管理者アカウントは J-SOX で禁止ですか** 禁止する文言はありません。問われるのは、その権限をいつ誰が使ったかを記録で示せるかです。共有のままでは利用の記録の「誰」が埋まりません。 **評価は毎年すべてやり直しますか** 前年度の評価が有効で重要な変更がない項目は、その旨を記録して前年度の結果を継続利用できます。財務報告の信頼性に特に重要な項目は除きます。 **監査の場で口頭で説明すれば足りますか** 実施基準が挙げる方法は文書の閲覧、質問、観察、実施記録の検証です。質問は含まれますが、記録がなければ運用されていたことを示せません。 ## 参考資料 - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」(2023 年 4 月 7 日改訂)](https://www.fsa.go.jp/singi/singi_kigyou/kijun/20230407_naibutousei_kansa.pdf) - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify は、4 つの資料のうち一覧(どのコンソールを誰が使えるか)と利用の記録を担います。担当者が自分のスマホで本人確認をしてから使うため、共有の管理者アカウントでも、誰が・いつ・どのコンソールに入ったかが一人ひとり残り、CSV で出せます。パスワードは担当者に渡りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか まず公式ヘルプで、担当者ごとの ID を追加できるか、権限を分けられるかを確かめます。追加できるなら個人の ID にし、1 つしか作れないものは共有として貸出の記録、二段階認証の宛先、パスワードを変える場面を決めます。 更新日: 2026-09-18 ID 管理サービス(Okta、Microsoft Entra ID など)とつなげない管理画面の ID は、まず公式ヘルプで担当者ごとの ID を作れるかを確かめます。ドメインや DNS(ドメイン名と接続先を結びつける仕組み)、決済の管理画面には、つなげないものが残ります。担当者ごとの ID を作れるなら個人の ID に分けます。1 つしか作れないなら、共有の管理者アカウントとして貸出の記録、二段階認証の宛先、パスワードを変える場面の 3 つを決めます。 ## 公式ヘルプで確かめる 3 つのこと 1. 担当者ごとの ID(メンバー)を追加できるか。「チーム」「メンバー」「ユーザー」の設定のヘルプを見ます。追加できれば、個人の ID に分けられます。 2. 権限の種類を分けられるか。ロール(権限の種類)の一覧を見ます。分けられれば、最上位を少人数にし、作業に応じた権限にできます。 3. 二段階認証を全員に必須にできるか、方式は何か。「セキュリティ」「二段階認証」のヘルプを見ます。認証アプリやセキュリティキーなら担当者のスマホで完結し、メールや SMS なら届く宛先を決める必要があります。 ## 3 つのサービスで確認した結果 公式ヘルプで確認できたものだけを書きます。仕様は変わるため、実際の設定は最新のヘルプで確かめます。 | サービス | 担当者ごとの ID | 権限の種類 | 二段階認証 | | --- | --- | --- | --- | | Cloudflare | メールアドレスで招待して追加できる | Super Administrator、Administrator、Administrator Read Only、Billing、DNS など | 認証アプリ、セキュリティキー、メールの 3 方式 | | Stripe | メールアドレスで招待してチームに追加できる | Super Administrator、Administrator、IAM Administrator、Developer、Analyst、View Only など | 管理者がチームの設定で全員に必須にできる | | お名前.com Navi | 公式ガイドのログインの項目に記述がない | 記述がない | メール認証と SMS 認証の 2 方式 | Cloudflare では、メンバーの追加と取り消しを Super Administrator が行います。Super Administrator は支払いとメンバー管理を含むすべての権限を持ち、Administrator はメンバー管理と支払いを除く全体を受け持ちます。二段階認証は Super Administrator が全メンバーに必須にでき、必須にすると招待を受ける前に設定が要ります。 Stripe では、招待が 10 日で失効し、役割は後から変更できます。IAM Administrator はメンバー管理だけの役割で、アカウント所有者は 1 人です。二段階認証を必須にすると、未設定の人は次回のログイン時に設定を求められ、新しく招待する人は設定しないと参加できません。公式ドキュメントは、招待するときに「その仕事に必要な最も低い権限を与える」よう求めています。メンバーを招待できる役割は、乗っ取られると別の利用者を招き入れられるため、注意するようにも書いています。Stripe は過去 180 日のチームメンバーの操作をセキュリティ履歴として残します。 お名前.com Navi の二段階認証は、ログイン、会員情報の変更、パスワードの変更などで求められます。設定は任意で、設定しないことも選べます。 ## 個人の ID を追加できるサービスでは Cloudflare や Stripe のように担当者ごとの ID を作れるサービスは、Google Workspace や Microsoft 365 と同じ形にできます。最上位の権限(Super Administrator)は少人数に絞り、作業に応じた権限を個人に与えます。二段階認証は全員に必須にし、退職や担当交代のときはメンバーから外します。記録はその人の名前で残ります。1 つの管理者 ID のパスワードを配る形を続ける理由は、この場合はありません。 ## 1 つの ID しか作れないサービスでは お名前.com Navi のように担当者ごとの ID の記述が公式ガイドにないサービスは、1 組の ID とパスワードを複数人で使うことになります。この場合に決めることは 3 つです。 1. パスワードを知る人を絞り、誰が知っているかと、いつ誰が使ったかを台帳に残す。サービス側の記録には ID の名前しか残らないためです。 2. 二段階認証の届く先を決める。メールや SMS で届く方式は、登録した 1 つの宛先にしか届かないため、担当者個人の宛先だとその人が不在のときに誰も入れません。会社が管理する宛先にするか、受け取る人と手順を決めておきます。共有するときの考え方は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にまとめています。 3. 退職や担当交代のときにパスワードを変える。個人の ID のようにその人だけを外すことができないためです。 台帳と、パスワードを見せずに使わせる仕組みの違いは、[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)の表にあります。 ## 確認できなかったこと 3 つのサービスが ID 管理サービスと SAML(ID 管理サービスとつなぐための規格)でつなげられるかどうかは、この記事では確認していません。つなげられる場合は個人の ID をそのまま使えるため、その確認を先に行います。お名前.com Navi については、複数ユーザーの追加と権限の設定の有無を、公式ガイドのログインの項目では確認できませんでした。そのため、この記事では 1 つの ID しか作れないサービスの例として扱っています。 ## よくある質問 **ドメインや決済の管理画面も ID 管理サービスとつなげられますか** サービスごとに違います。この記事で確認した 3 つでは、つなげられるかの公式ヘルプを確認していません。つなげられるなら個人の ID をそのまま使えるので、先に確かめます。 **二段階認証を全員に必須にできますか** Cloudflare は Super Administrator が、Stripe は管理者がチームの設定で全員に必須化できます。お名前.com Navi は任意で、方式はメールと SMS です。 **1 つしか ID を作れない管理画面はどうしますか** パスワードを知る人を絞って台帳に残し、二段階認証の届く先を会社が管理する宛先にし、退職や担当交代のときにパスワードを変えます。 **メンバーを追加できる権限は誰に持たせますか** Stripe の公式ドキュメントは、招待できる役割が乗っ取られると別の利用者を招き入れられると注意しています。最上位の権限と招待の権限は少人数に絞ります。 ## 参考資料 - [Cloudflare Docs「Two-factor authentication」](https://developers.cloudflare.com/fundamentals/user-profiles/2fa/) - [Cloudflare Docs「Roles」(Manage account members)](https://developers.cloudflare.com/fundamentals/manage-members/roles/) - [Cloudflare Docs「Manage account members」](https://developers.cloudflare.com/fundamentals/manage-members/manage/) - [Stripe Docs「Start a team」](https://docs.stripe.com/get-started/account/teams) - [Stripe Docs「User roles」](https://docs.stripe.com/get-started/account/teams/roles) - [Stripe Support「Require two-step authentication for your team」](https://support.stripe.com/questions/require-two-step-authentication-for-your-team) - [お名前.com Navi ガイド「二段階認証設定」](https://www.onamae.com/guide/p/102) - [お名前.com「お名前.com Naviログイン「二段階認証」機能導入のお知らせ」(2020 年 10 月 7 日)](https://www.onamae.com/news/article/10041) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify が担うのは、ID 管理サービスとつなげず、1 組の ID とパスワードで入る管理画面です。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。認証アプリにコードが出る方式の二段階認証なら、そのコードも Junify が入力します。誰が・いつ入ったかは一人ひとり残り、管理画面側の IP 制限や設定はそのままです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # 管理者用アカウントの監査で示せるようにしておく記録 公的な資料が求めるのは、誰が・いつ・どのアカウントで・何をしたかがつながる記録と、権限の付与・削除と見直しの記録です。金融庁、内閣官房、IPA の 4 つの文書は、改ざんの防止と定期的な点検も共通して求めています。 更新日: 2026-09-18 管理者用アカウント(特権 ID)の監査で示すのは、利用の記録と、権限の記録です。利用の記録は「誰が・いつ・どのアカウントで・何をしたか」がつながっているもの、権限の記録は権限を付けた・外した・見直したものを指します。金融庁、内閣官房、IPA の文書は、対象も言葉も違いますが、求める中身はこの範囲に収まります。 ## 4 つの文書が求める記録 | 文書 | 誰が | いつ | どのアカウントで | 何をしたか | 権限の付与・削除・見直し | | --- | --- | --- | --- | --- | --- | | 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」2.3.1 | アクセスした人を特定できる措置(④) | — | 特権アカウントの利用の厳格な制限と管理(①) | 処理内容を記録し、操作した人と対応づける(④)。操作履歴のレビュー(①) | アカウントの作成・使用・終了の管理と定期的な棚卸し(①)。システム責任者による定期的なアクセスレビュー(③) | | 内閣官房「政府機関等の対策基準策定のためのガイドライン」7.1.3・7.1.4 | 事象の主体を示す識別コード | 正確な日付及び時刻(時刻を同期させる) | 識別コードの発行等の管理記録 | 情報システムの操作記録、事象の種類と対象 | 不要なアクセス権限が付いていないか定期的に確認(7.1.3) | | IPA「組織における内部不正防止ガイドライン」第 5 版 (6)(7)(18)(19) | 共有 ID を使わず、管理者ごとの ID で認証する(7) | 作業日時を記した作業報告(6) | 管理者 ID ごとに権限の範囲を決める(6) | 特権の使用を記録(6)。利用者の操作履歴を記録・保存(18)。管理者のアクセス履歴・操作履歴を記録・保存(19) | 作業報告を別の管理者が確認(6)。管理者以外が定期的に確認(19) | | IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版 | 共有 ID をやむを得ず使う場合は使った人を特定できる仕組み | — | 管理者 ID の発行から削除までの手続 | 通信の記録・認証の記録の取得・保管と定期的なレビュー | 異動・退職に伴う権限の変更・削除、権限の付与状況の管理 | 「—」は、その文書にその項目の直接の記述がないことを表します。日時の記述がない文書でも、操作の記録には日時が含まれます。 ## 「誰が」を共有アカウントでどう残すか 金融庁と内閣官房のガイドラインは、使った人を特定できることを求めています。金融庁は「アクセスしたユーザを特定できる措置」、内閣官房は「事象の主体を示す識別コード」の記録です。IPA の内部不正防止ガイドラインは、共有 ID や共有のパスワードを使わないことを求めています。管理者ごとの ID を個別のパスワードで認証しなければならない、としています(対策 7)。共有 ID だと、内部不正のときにアクセスした人を識別できないためです。分けられずに残る共有の管理者アカウントについては、IPA の中小企業向けガイドラインが「共有 ID を利用したユーザーを特定可能とするような仕組み」を勧めています。内部不正防止ガイドラインの対策 19 も、システムから記録を集められない場合の扱いを書いています。管理者の作業内容を文書に記録し、上司または総括責任者が定期的に確認する、という形です。台帳の貸出記録がこれに当たります。仕組みで人を特定する方法は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)の表にあります。 ## 何を記録するか 内閣官房のガイドライン 7.1.4 は、記録する項目の例を 10 挙げています。そのうち管理者用アカウントに関わるのは 7 つです。事象の主体を示す識別コード、識別コードの発行などの管理記録、情報システムの操作記録、事象の種類、事象の対象、正確な日付と時刻、試みられたアクセスに関わる情報です。同じ 7.1.4 は、記録する目的をシステムごとに決めたうえで、対象の機器、項目、保存期間、扱い方を定めるよう求めています。金融庁のガイドラインは、特権アカウントの管理の例として、多要素認証、操作のダブルチェック、アカウントの時間制限を挙げています。ダブルチェックや時間制限を置いた場合、その承認や期限の記録も利用の記録の一部になると考えられます。 ## どれだけ残し、どう守るか 保存期間について、内閣官房のガイドラインの解説は、標的型攻撃の経緯を初期から確認する観点から、1 年間以上の保存が望ましいとしています。金融庁のガイドラインは、記録の取得・監視・保存のための手続を定めるよう求め、手続に含める事項の例に保存期間と保存方法を挙げています。IPA の内部不正防止ガイドラインは、保存期間はリスクとコストのバランスで決めるとしています。改ざんの防止は、4 つの文書すべてに共通します。消去まで挙げているのは内閣官房と IPA の内部不正防止ガイドラインです。金融庁のガイドラインは、同じ手続に含める事項の例にログの改ざん防止を挙げています。内閣官房のガイドラインは、記録への不正な消去・改ざん・アクセスを防ぐ保全方法を定めることを求めています。IPA の内部不正防止ガイドラインは、管理者の記録を改ざんまたは不正な消去ができないよう、暗号化などの対策を取ることを求めています。IPA の中小企業向けガイドラインは、記録の改ざん防止を行ったうえで定期的に見直すことを勧めています。 ## 誰が点検するか 記録は残すだけでなく、定期的に見ることが 4 つとも求めています。点検する人を管理者以外と明記しているのは IPA の内部不正防止ガイドラインです。管理者の記録を定期的に管理者以外が確認しなければならないとし、確認する人の例に上司または総括責任者を挙げています。内部監査の項目にする方法も挙げています。金融庁のガイドラインは操作履歴のレビューと定期的なアクセスレビュー、内閣官房のガイドラインは記録の定期的な点検または分析を求めています。点検した記録そのものが、監査で「見直しの記録」として提出できるものになります。委託先の保守担当者が管理者用のアカウントを共用していた事案では、記録は残っていたものの点検する運用がありませんでした。持ち出しは約 10 年間続いています([管理者アカウントを共用していた事案](/guides/incidents/contractor-shared-admin-account))。 ## よくある質問 **操作の記録はサービスの画面から出せれば足りますか** サービス側の記録には ID の名前と操作が残ります。共有 ID では誰が使ったかが残らないため、台帳か仕組みで人を特定する記録を別に用意して、両方を提出します。 **記録は何年残せばよいですか** 内閣官房のガイドラインの解説は 1 年間以上が望ましいとしています。金融庁は保存の手続に含める事項の例に保存期間を挙げ、IPA の内部不正防止ガイドラインはリスクとコストのバランスで決めるとしています。 **共有 ID の利用記録は台帳でよいですか** IPA の内部不正防止ガイドラインは、システムから記録を集められない場合に作業内容を文書に記録し、上司または総括責任者が定期的に確認するとしています。台帳は、その確認とセットで記録になります。 **誰が記録を点検しますか** IPA の内部不正防止ガイドラインは管理者以外が確認するよう求め、上司または総括責任者、内部監査を例に挙げています。金融庁はシステム責任者による定期的なアクセスレビューを求めています。 ## 参考資料 - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify が担うのは、表の「誰が」「いつ」「どのアカウントで」の部分です。担当者が自分のスマホで本人確認をしてから使うため、共有の管理者アカウントでも記録は一人ひとり残り、CSV で出せます。録画を設定したコンソールでは操作も再生できます。何をしたかの記録は、サービス側の記録と合わせて揃えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # 緊急用アカウント(ブレークグラス)とは 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。 更新日: 2026-09-18 緊急用アカウント(ブレークグラス)とは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。 ## 緊急用アカウントとは何か Microsoft Entra ID の公式ドキュメントは、この予備のアカウントを emergency access account と呼んでいます。「break glass」(非常時にガラスを割って使う、の意味)の場面で使うアカウントとも書いています。グローバル管理者(会社の環境全体を管理できる最上位の権限)を持たせ、普段の管理者アカウントが使えない、どうしても必要なときだけに使います。 ## 何のために置くのか 目的は、管理者が誰も入れない状態を作らないことです。公式ドキュメントは、次のような場面を挙げています。 - 社内の認証の仕組みの障害。社員の ID を社内の仕組みで認証していると、その仕組みが止まったときに誰もログインできません。 - 二段階認証の端末が使えない状態。携帯電話の回線障害などで、管理者全員が確認コードを受け取れなくなります。 - 最後のグローバル管理者の退職。最後の 1 人のアカウントが社内側で削除・無効化され、取り戻せなくなります。 - 災害。携帯電話や通信網が使えなくなります。 そのため、2 つ以上のアカウントを、社内の仕組みから独立したクラウドだけのアカウントとして作るよう勧めています。 ## 普段は使わないとはどういうことか 普段使わないための決まりが、公式ドキュメントに並んでいます。特定の個人に結びつけず、管理チームの複数人が知る安全な場所(耐火金庫など)にログイン情報を保管します。管理者ごとに個人の緊急用アカウントを作る形も選べます。ログイン方法は、普段の管理者アカウントとは別の方法にします。普段の管理者が認証アプリを使っているなら、緊急用にはパスキー(FIDO2。パスワードの代わりに手元の鍵型の機器で本人を確かめる方式)を使う、という例が挙げられています。場所や端末の条件でログインを制限する設定(条件付きアクセス)からは外します。その設定が原因で、緊急時に入れなくなるためです。 ## 使ったら何をするか 使った記録を残し、そのつど見直します。公式ドキュメントは、緊急用アカウントのログインがあるたびに他の管理者へ通知し、サインインと操作の記録を保存するよう求めています。そのうえで、計画した訓練だったのか、本当の緊急だったのか、不正な利用だったのかを見直します。行った操作も記録で確かめ、許された範囲だったかを判断します。 ## 定期的に何を見直すか 使わないまま置いておくと、いざというときに使えないことがあります。公式ドキュメントは、少なくとも 90 日ごとに、ログインして管理作業ができるかを試すよう求めています。合わせて、使ってよい人の一覧と手順書を更新し、担当者の異動や退職があったときにも同じ確認を行います。金庫の番号は定期的に変え、使える人が退職したときにも変えます。緊急用を含む管理者用アカウント全体の管理は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)にまとめています。 ## よくある質問 **緊急用アカウントはいくつ必要ですか** Microsoft Entra ID の公式ドキュメントは、2 つ以上を勧めています。社内の認証の仕組みに頼らないクラウドだけのアカウントにし、普段の管理者アカウントと違うログイン方法を登録します。 **緊急用アカウントにも二段階認証は要りますか** 要ります。公式ドキュメントは、パスキー(FIDO2。手元の鍵型の機器で本人を確かめる方式)か証明書によるログインを勧めています。場所や端末の条件でログインを制限する設定からは外します。 **緊急用アカウントを使ったあとは何をしますか** 記録を保存し、計画した訓練だったのか、本当の緊急だったのか、不正な利用だったのかを見直します。行った操作が許された範囲だったかも記録で確かめます。 **緊急用アカウントを日常の共有アカウントにしてよいですか** 公式ドキュメントは、普段の管理者アカウントが使えない緊急時だけに限るよう求め、使うたびに記録を見直すとしています。 ## 参考資料 - [Microsoft Learn「Manage emergency access admin accounts - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify が担うのは、緊急用ではなく、日常的に複数人で使う管理コンソールのアカウントです。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインするため、パスワードを使う人は誰も知りません。誰が・いつ・どのコンソールに入ったかは一人ひとり残り、担当を外れたら管理者が割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # 特権 ID 管理(PAM)とは 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。 更新日: 2026-09-18 特権 ID 管理(PAM)とは、管理者用アカウント(強い権限を持つ ID)の利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。 ## 特権 ID 管理とは何か IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、「より強固にするための方策」の技術の説明で、特権 ID 管理を次のように書いています。「情報システムの特権(コンピュータを管理するために与えられた最上位の権限)の利用申請や権限付与、操作ログなどを管理する技術」。操作ログとは、誰がどんな操作をしたかの記録です。英語では Privileged Access Management、略して PAM と呼びます。この技術を製品にしたものが PAM 製品と呼ばれます。特権 ID が何を指すかは[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。 ## 何をする仕組みか IPA の説明にある 3 つの働きは次のとおりです。 1. 利用の申請と承認。使う前に、誰が何のために使うかを申請し、別の人が承認します(政府機関向けガイドライン 7.1.3 の解説)。 2. 権限の付与と制限。必要な業務に限って、必要な期間だけ権限を持たせます(金融庁ガイドライン 2.3.1)。 3. 操作の記録。行った操作を記録し、誰の操作かと対応づけます(金融庁ガイドライン 2.3.1)。 政府機関向けガイドライン 7.1.3 の解説は、特に強固な権限管理が要るシステムの例に「デュアルロック機能」や「ワークフロー機能」を挙げています。複数名の認証操作がなければ処理を終えられない仕組みです。金融庁ガイドライン 2.3.1 は、特権アカウントの利用を厳格に制限し、管理することを求めています。例として、多要素認証(2 つ以上の方法で本人を確かめること)、操作のダブルチェック、アカウントの時間制限の設定を挙げています。同じ 2.3.1 の別の項目で、アクセスした人を特定できるようにし、処理内容を記録して操作した人と対応づけることも求めています。 パスワードを本人に見せずに一時的に貸し出す方式については、確認した公的な文書に記述がありません。 ## 公的な文書は何を求めているか 求めているのは、管理者権限を持つ人を絞ることと、使ったことが分かることの 2 つです。IPA のガイドラインは本文で、管理者 ID の発行から削除までの手続を定め、必要最小限の付与にすることを勧めています。共有 ID はなるべく使わず、やむを得ず使う場合は、使った人を特定できる仕組みを整えることも勧めています。政府機関向けの「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版)は、管理者権限を持つ ID の利用を、その権限が要る業務に限るとしています。 ## SaaS の管理者アカウントに当てはめるとどう違うか IPA の説明にある「コンピュータを管理するため」の特権は、サーバーや OS を念頭に置いた言い方ですが、対象をそれに限るとは書いていません。クラウドや SaaS(インターネット経由で使う業務ソフト)の管理者アカウントは、ブラウザーから管理コンソール(設定画面)に入って使います。政府機関向けガイドラインは、その ID のアクセス管理を求めています。全体の管理者権限で管理コンソールにログインすると、利用中の情報システムをすべて削除できるためです。求められることは同じでも、ブラウザーで使う管理画面を製品が対象にしているかは、製品ごとに確認が要ります。 ## よくある質問 **PAM は製品の名前ですか** いいえ。IPA のガイドラインでは、特権の利用申請や権限付与、操作の記録などを管理する技術の総称です。その技術を製品にしたものが PAM 製品と呼ばれます。 **小さな会社でも特権 ID 管理は必要ですか** IPA のガイドラインが本文で勧めているのは、管理者 ID の発行から削除までの手続と、共有 ID を使う人を特定できる仕組みです。特権 ID 管理は、対策を強める技術の一つとして説明されています。 **特権 ID の操作の記録は何を残せばよいですか** 金融庁のガイドラインは、アクセスした人を特定できるようにし、処理内容を記録して、操作した人と対応づけることを求めています。誰が・いつ・何をしたかがつながる形です。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify は、担当者に代わって管理コンソールに ID とパスワードを入力し、使う人がパスワードを知らない状態にする仕組みです。担当者は自分のスマホで本人確認をしてから使うため、誰が・いつ・どのコンソールに入ったかは一人ひとり残ります。通信の経路の途中には入らず、サーバーや OS の管理者 ID は対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # 特権 ID(管理者用アカウント)とは 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。 更新日: 2026-09-18 特権 ID(管理者用アカウント)とは、コンピューターやサービスを管理するために与えられた最上位の権限を持つ ID です。 ## 特権 ID とは何か IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、特権を「コンピュータを管理するために与えられた最上位の権限」と書いています。同じガイドラインの本文では、管理者 ID を「管理者権限を保持する ID」と呼んでいます。「コンピュータを管理するため」はサーバーや OS を念頭に置いた言い方ですが、対象をそれに限るとは書いていません。この記事では、クラウドや SaaS(インターネット経由で使う業務ソフト)の管理者アカウントも含めて、管理者用アカウントを特権 ID と呼びます。 ## どこまでが特権 ID か 代表的なものを 4 つ挙げます。できることは、各サービスの公式ドキュメントの記述によります。 - クラウドのアカウント全体を握る ID の例が、AWS のルートユーザーです。すべてのサービスと資源に完全にアクセスできます。支払いの一部の作業と、単独のアカウントの解約は、ルートユーザーだけができます。 - SaaS の管理者の例が、Google Workspace の特権管理者です。管理コンソールのすべての機能を使え、他の管理者の管理と、削除した利用者の復元もできます。 - 同じく SaaS の管理者の例が、Microsoft 365 のグローバル管理者です。設定と、データの大半にアクセスできます。全員のパスワードの再設定、契約の購入、ドメインの追加と管理もできます。 - サーバー・OS の管理者の例が、Linux の root と Windows の Administrator です。そのコンピューターのすべての操作ができます。 ドメイン登録や決済の専用サービスの管理画面の ID は、出典の定義には例として出てきません。しかし、上に挙げた最上位の管理者と同じ操作(ドメインの管理・支払い)ができる ID なので、この記事では含めます。 ## なぜ特別に扱うのか 理由は、権限が強い分、盗まれたり誤って使われたりしたときの影響が大きいことです。政府機関向けの「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版)の 7.1.3「権限の管理」を見ます。管理者権限にはあらゆる操作が許可される特権が付いている、と説明しています。その ID とパスワードを第三者に取られると、情報の漏えいや改ざんだけでなく、情報システムの破壊も起こりうる、としています。そのため、限られた人だけに管理者権限を付けることが重要だ、というのが同ガイドラインの整理です。サービス側も同じで、AWS はルートユーザーを日常の作業に使わないよう勧めています。Google Workspace は特権管理者を 2 人以上、Microsoft 365 はグローバル管理者をできるだけ少なくするよう勧めています。 ## 共有アカウントとどう違うか 特権 ID は権限の強さで決まり、共有アカウントは使う人の数で決まります。数人で使う管理者アカウントは、特権 ID であり共有アカウントでもあります。Microsoft Entra ID の公式ドキュメントは、複数人で 1 組のユーザー名とパスワードを使う場面の例を挙げています。その一つが、設定・管理・復旧に使う強い権限を持つ 1 つだけのアカウントです。共有アカウント一般の定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)にまとめています。管理の全体像は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)にあります。 ## よくある質問 **特権 ID はサーバーの root だけを指しますか** いいえ。IPA の「コンピュータを管理するために与えられた最上位の権限」はサーバーや OS を念頭に置いた言い方ですが、対象をそれに限るとは書いていません。クラウドや SaaS の管理者アカウントも含めます。 **SaaS の管理者アカウントも特権 ID ですか** 含めます。Google Workspace の特権管理者は管理コンソールのすべての機能を使え、Microsoft 365 のグローバル管理者はドメインの管理や契約の購入、全員のパスワードの再設定ができます。 **管理者の権限は何人が持つべきですか** Google Workspace は特権管理者を 2 人以上置くよう勧め、Microsoft 365 はグローバル管理者をできるだけ少なくするよう勧めています。1 人にしないことと、増やしすぎないことの両方が目安です。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) - [AWS Identity and Access Management ユーザーガイド「AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) - [Google Workspace 管理者ヘルプ「Pre-built administrator roles」](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles) - [Microsoft Learn「About administrator roles in the Microsoft 365 admin center」](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) ## Junify の場合 **人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。 **Junify なら** Junify は、クラウドや SaaS の管理コンソールの管理者用アカウントを、パスワードを使う人が誰も知らない状態で使わせる仕組みです。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。誰が・いつ・どのコンソールに入ったかは一人ひとり残ります。サーバーや OS の管理者 ID は対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=privileged-access) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。 - [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。 - [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。 --- # 医療・ヘルスケアのアカウント管理 医療機関のアカウント管理で決めることは、使う人を確かめる方法、権限の付け方と外し方、誰が何をしたかの記録の 3 つです。水準は厚労省のガイドライン第 7.0 版が示しています。 更新日: 2026-09-18 医療機関のアカウント管理で決めることは 3 つです。使う人が本人かを確かめる方法、権限をどう付けてどう外すか、そして誰が何をしたかをどう残すかです。この 3 つの水準は、厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版が示しています。 ## 求められる水準はどこに書かれているか 医療機関が守る文書は、厚生労働省のガイドライン(第 7.0 版、令和 8 年 6 月)です。中身は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。電子カルテなどのシステムを提供する事業者は、総務省・経済産業省の事業者向けガイドライン(第 2.0 版)を守ります。2 本の関係は[3 省 2 ガイドラインとは](/guides/healthcare-access/what-is-3-ministries-2-guidelines)に書いています。法令の側では、個人情報保護法が[安全管理措置](/guides/compliance/what-is-security-control-measures)を求めます。 読む範囲は施設によって変わります。サーバーの保守を事業者に全て委託できている医療機関等は、概説編と保守委託機関編に対応すれば遵守とみなされます(概説編 3.1.5)。当てはまるかどうかは、事業者がセキュリティ更新の責任を負うことが契約書や約款に書かれているかで決まります。 ## 共有アカウントが残る場面 ガイドラインは、医療情報システムを使う全ての職員と関係者に本人の ID・パスワードなどを用意するよう求めています。それを院内で統一的に管理する必要がある、とも書いています(システム運用編 14.1.1)。それでも 1 つの ID を複数人で使う状態が残るのは、この前提に載らない人や機器があるときです。以下に挙げるのは、その前提から起きうる形を書き出したものです。どの形がどれだけあるかを示す公表資料はありません。 非常勤やスポット勤務の医療従事者がいる場合が 1 つです。企画管理編は、院内の利用者には人事の情報と整合させて ID を付与するよう求めています(13 章)。人事の登録を経ない人に ID を出す手順がない医療機関では、その人が診療システムを使うときに、すでにある ID を借りる形になり得ます。 医事業務やレセプト業務を委託している場合も同じ形が起きます。企画管理編は、外部の利用者についてアクセス権限とアクセス状況を管理するよう求めています(13 章)。事務や運用を外部に委託するときは、委託契約の契約書に守秘・非開示の内容を含め、委託先の就業規則などにも同じ対応を求めることが遵守事項です(7 章)。委託先の要員が交代しても医療機関側の ID 発行が追いつかなければ、1 つの ID を委託先に渡す形になり得ます。 オンライン診療や予約・問診などの外部サービスでは、サービスの側の ID 管理が加わります。厚生労働省の「オンライン診療の適切な実施に関する指針」は、診療システムに影響しうるオンライン診療システムを使うときは、2 本のガイドラインに沿った対策を求めています。医療機関には、多要素認証(2 つ以上の方法で本人を確かめること)を用いるのが望ましいとしています。 私物端末(BYOD)も、規程と台帳の対象になる場面です。ガイドラインは、規程と台帳で管理する前提でこの使い方を想定しています(企画管理編 9 章)。管理されていない端末での BYOD は許可してはならない、ともしています(システム運用編 8.5)。 機器やソフトに接続するために「便宜的に利用する ID」も、企画管理編は利用者の種類として整理し、運用規則を定めるよう求めています(13.1.1)。共有のまま残るなら、決めたうえで残す ID です。共通のパスワードや使い回しが被害を広げた公表事案は、[委託先と共通のパスワードから侵入された事案](/guides/incidents/shared-password-with-supplier)と[管理者パスワードの使い回しから被害が広がった事案](/guides/incidents/reused-admin-password-ransomware)にまとめています。 ## ガイドラインが求める認証・権限・記録の骨子 第 7.0 版のうち、アカウント管理に関わる項目を表にします。「遵守事項」は各章の冒頭の箱に置かれた守るべき決まりです。「考え方」はその後の本文にある説明で、強さが違います。 | 項目 | 求められること | 区分 | 編・章 | | --- | --- | --- | --- | | 利用者の識別・認証 | アクセスする際に利用者を識別・認証し、手順を文書化すること | 遵守事項 | システム運用編 14 | | ID とパスワード | 本人しか知り得ない状態に保ち、運用担当者にも推定できないようにし、システム間で使い回さないこと | 遵守事項 | システム運用編 14 | | 二要素認証 | 令和 9 年 4 月 1 日時点で稼働が想定されるシステムを新しく入れる、または入れ替えるときに、採用するか相当する対応を行うこと(難しい場合は次期更新まで) | 遵守事項 | システム運用編 14 | | 権限の付与 | 部署の申請を踏まえて付与し、申請部署の管理者の確認を得る手順を作ること | 遵守事項 | システム運用編 14 | | 権限の見直し | 付ける権限は必要最小限とし、人事異動などに合わせて更新する | 考え方 | システム運用編 14.2 | | ID の台帳と棚卸し | 台帳で管理し、定期的に棚卸し(何があるか一覧にすること)をして不要なものを削除すること | 遵守事項 | システム運用編 14 | | 退職時の削除 | 職員の退職などに合わせて、利用者の登録からも削除する | 考え方 | 企画管理編 13.1.2 | | 外部の利用者 | アクセス権限とアクセス状況を管理し、管理者権限は最小限の人にだけ付与すること | 遵守事項 | 企画管理編 13 | | アクセスの記録 | ログイン時刻・アクセス時間・操作した医療情報が分かるように記録し、定期的に確認すること(記録機能がなければ業務日誌で操作者と操作内容を残す) | 遵守事項 | システム運用編 17 | | 記録の保護 | 記録へのアクセスを制限し、不当な削除・改ざん・追加を防ぐ対策をすること | 遵守事項 | システム運用編 17 | | 委託時の記録 | 管理を委託している場合は、記録の管理方法と提供を事業者と取り決める | 考え方 | システム運用編 17.1 | 二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです([二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification))。 ## 共有アカウントをどう扱うか 上の表を共有アカウントに当てはめると、決めることは 2 つに絞れます。個人の ID に分けられるものは分けること、分けられずに残るものは誰が使ったかを残す方法を決めることです。選べる形は次の 4 つです。1 つ目と 3 つ目は個人ごとの ID に分ける方向、2 つ目と 4 つ目は共有のまま残す方向です。 | 方法 | できること | 残る限界 | | --- | --- | --- | | 人ごとに ID を発行する | 認証も記録もシステムの機能で足りる。ガイドラインの前提そのもの | 人事の手続きに載らない人、ID 数に上限があるシステムには使えない | | 業務日誌と貸出の台帳 | 道具なしで始められる。記録機能がない場合の代替としてガイドラインも認めている | パスワードは借りた人が知ったまま。記録は自己申告 | | 委託先に ID の発行と管理を任せる | 委託先の要員ごとに ID が分かれ、要員の入れ替わりに合わせて発行と削除ができる | 外部の利用者として権限とアクセス状況を管理するのは医療機関の側で(企画管理編 13 章 ⑤)、報告と台帳の照合を取り決めることになる | | パスワードを見せずに使わせる仕組み | 本人確認した人ごとに利用を記録し、パスワードは渡らない | パスワードはシステム側に残り、対象のシステムと端末の条件は製品ごとに確かめることになる | パスワードを見せずに使わせる仕組みに当たるのは、ID 管理サービスがパスワードを代わりに入力する機能や、アクセス管理ツールです。4 つはどれか 1 つを選ぶものではなく、システムごとに組み合わせられます。共有のまま残す方法を道具の種類で比べたものは[共有アカウントの管理](/guides/shared-accounts)に、管理者用の ID の扱いは[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)にあります。共有アカウントに二要素認証を付けると、コードを受け取る端末も共有になります。この問題は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にまとめています。 ## 何から始めるか 医療情報システムと ID の一覧を作るところから始めます。企画管理編は、管理権限の種類とその ID、利用が認められている人を一覧にし、棚卸しの結果を経営層に報告して承認を得るよう求めています(13 章)。システム名、ID、使っている人、二要素認証に対応しているか、記録の機能があるかを書き出します。 次に、個人に分けられるものは分けます。人事の情報と整合させて ID を付け、退職や勤務終了に合わせて削除する手順を決めます。委託先の要員には、外部の利用者として権限とアクセス状況を管理できる形で ID を用意します。 残る共有 ID は、上の表から記録の方法を決めます。あわせて、二要素認証の期限をシステム更新の計画に入れます。委託先とは、責任の分かれ目(責任分界)と記録の提供を書面で取り決めます。委託先の監督の考え方は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 ## このテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 - [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](/guides/healthcare-access/staff-departure-account-shutdown): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 - [医療法に基づく立入検査で、サイバーセキュリティについて確認されること](/guides/healthcare-access/medical-onsite-inspection-cybersecurity): 病院への立入検査は原則年 1 回です。サイバーセキュリティでは、厚労省のチェックリストの全項目に確認日と回答が書かれているかを見て、機器の台帳・連絡体制図・BCP・規程類は現物を確かめます。 - [厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts): 区分 2 の 7 項目(権限、不要なアカウント、パスワード 2 項目、二要素認証 2 項目、アクセスの記録)です。台帳を在籍者の一覧と照らし、記録を確かめた跡を残し、事業者が「対象外」とした項目は院内の担当を決めます。 - [医療情報システムの安全管理に関するガイドラインが定めるパスワードの桁数・変更・使い回し](/guides/healthcare-access/password-rules-in-medical-guideline): 現行の第 7.0 版では、二要素認証を使うならパスワードは 8 桁以上で英数字を混ぜ、使わないなら 13 桁以上です。定期的な変更はどちらも不要で、システム間で使い回さないことは遵守事項です。 - [薬局・介護事業所のシステム(電子薬歴・介護記録・請求ソフト)のアカウント管理](/guides/healthcare-access/pharmacy-care-facility-accounts): 薬局も介護事業者も厚労省の医療情報ガイドラインの対象です。職員ごとの ID、業務に合う権限、辞めた人の ID の停止、使った人の記録が求められます。1 つしか届かない介護の請求用 ID は、知る人と使った記録を事業所で決めます。 - [電子カルテなどからの患者データの持ち出しを防ぎ、記録する方法](/guides/healthcare-access/preventing-patient-data-exfiltration): 厚労省のガイドライン第 7.0 版は、持ち出す情報と方法を規程で決め、媒体と院外からのネットワーク経由の両方を想定するよう求めます。見る権限と使えるサービスを仕組みで絞り、持ち出しの承認・媒体の台帳・アクセスの記録を残して見直します。 - [医療情報システムの遠隔保守(リモートメンテナンス)で、保守事業者のアクセスをどう管理するか](/guides/healthcare-access/remote-maintenance-vendor-access): 管理の責任は医療機関に残ります。厚労省のガイドライン第 7.0 版は、保守要員に専用のアカウントを使わせ、遠隔保守では必ず記録を集めて作業計画書と照合することを求めます。つながる経路の一覧と契約も要ります。 - [私物端末(BYOD)から診療システムを使うときの安全管理](/guides/healthcare-access/byod-for-clinical-systems): 厚労省のガイドラインは私物端末の利用を禁じていませんが、許可の条件・利用範囲・管理方法などを規程に書いて台帳で管理し、院内の端末と同等の対策を手順にすることを求めます。管理されていない端末での利用は許可してはならないとしています。 - [医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention): 遵守事項は、ログイン時刻・アクセス時間・操作した医療情報が分かる記録を残して定期的に確かめ、改ざんを防ぎ、時刻を正確に保つことです。年数の定めは厚労省のガイドラインになく、2 省ガイドラインが法定保存年限以上を原則にしています。 - [厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる](/guides/healthcare-access/mhlw-guideline-authentication-and-access-control): 求められるのは、利用者ごとの識別・認証、ID とパスワードを本人しか知り得ない状態に保つこと、申請に基づく権限付与、二要素認証、ID の台帳と棚卸しです。遵守事項ごとに、施設で確かめる点を表にします。 - [オンライン診療で入れ替わる医師・スタッフのアカウント管理](/guides/healthcare-access/online-clinic-staff-turnover-accounts): 指針は、医療機関に多要素認証を用いるのが望ましいとし、事業者にアクセス権限の管理、退職者アカウントの削除の重点的な監視、アクセスログの保全を求めます。医師が交代する施設は、診療計画の医師名と ID の一覧を合わせます。 - [医事業務・レセプト業務を委託するときのアカウント](/guides/healthcare-access/outsourcing-medical-billing-accounts): 企画管理編 7 章の遵守事項は、委託契約の契約書に守秘・非開示を含め、委託先の就業規則等にも同じ対応を求めることです。ID は外部の利用者として、要員ごとにアクセス権限とアクセス状況を管理できる形で用意します。 - [電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff): 厚労省のガイドラインの遵守事項は、ID とパスワードを本人しか知り得ない状態に保つことです。考え方の節は、全ての職員と関係者に本人の ID 等を用意するとしています。共有 ID はどちらにも載りません。 - [医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts): 医療情報システムを新規に入れるときや入れ替えるとき、二要素認証の採用が遵守事項です。共有アカウントに付けても、コードは 1 人の端末に届き、誰が使ったかは残りません。 - [3 省 2 ガイドラインとは](/guides/healthcare-access/what-is-3-ministries-2-guidelines): 3 省 2 ガイドラインとは、厚労省の医療機関等向けガイドラインと、総務省・経産省の事業者向けガイドラインを合わせた通称です。医療情報を扱う側と、そのシステムを提供する側の 2 本で 1 組です。 - [医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline): 厚労省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。現行は第 7.0 版(令和 8 年 6 月)で、経営層・企画管理者・運用担当者ごとの編に分かれ、認証や記録の遵守事項を示します。 ## よくある質問 **電子カルテの ID を複数人で使うのは禁止ですか** 共有を禁じる文言はありません。ただし全ての職員と関係者に本人の ID 等を用意するよう求め、ID とパスワードを本人しか知り得ない状態に保つことを遵守事項にしています。 **二要素認証はいつまでに必要ですか** 令和 9 年 4 月 1 日時点で稼働が想定されるシステムを新しく入れる、または入れ替えるときに、採用するか相当する対応を行うことが遵守事項です。難しい場合は令和 9 年度以降の直近の更新までが期限です。 **小さな診療所にも同じ水準が求められますか** 第 7.0 版は、サーバーの保守(セキュリティ更新を含む)を事業者に全て委託している医療機関等は、概説編と保守委託機関編に対応すれば遵守とみなす、としています。当てはまるかは契約書や約款で確かめます。 **医事業務の委託先に ID を渡してよいですか** 企画管理編 13 章は外部の利用者のアクセス権限とアクセス状況を管理するよう求め、7 章は委託契約の契約書に守秘・非開示を含めるよう求めています。渡すならこの形が要ります。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 経営管理編」](https://www.mhlw.go.jp/content/10808000/001716291.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 2.0 版」(令和 7 年 3 月改定)](https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328.pdf) - [厚生労働省「オンライン診療の適切な実施に関する指針」(令和 8 年 4 月改訂)](https://www.mhlw.go.jp/content/001685701.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、診療システムの ID とパスワードを管理者が登録し、スタッフは自分のスマホで本人確認をしてクリックするだけでログインする仕組みです。パスワードは渡らず、誰が・いつ・どのシステムに入ったかは一人ひとり残ります。勤務のない期間は管理者が割り当てを外すだけで入れなくなり、委託先のスタッフにも同じ手順で使ってもらえます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # 予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 更新日: 2026-10-14 予約・問診・オンライン診療などのクラウドサービスでは、サービス側の仕組みと安全対策は事業者が受け持ちます。誰に ID を出していつ止めるかは、医療機関が受け持つのが基本の形です。ただし、実際の分かれ目はサービスと契約ごとに違います。厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、それを事業者と取り決めて文書にし、事業者が出す開示書で確かめるよう求めています。ガイドラインの全体像は[医療・ヘルスケアのアカウント管理](/guides/healthcare-access)にまとめています。 ## 予約や問診のサービスも対象になるか 第 7.0 版の Q&A(概説編 Q7)は、医療情報システムを「医療情報を扱うシステム・端末・ネットワーク全般」と答えています。患者の氏名や症状を入力する予約・問診のサービスも、ここに入ると読めます。同じ Q&A の Q10 は、SNS などの Web サービスで医療情報をやり取りする場合を扱っています。使う前に、本人の確かめ方、使える範囲の制限、責任分界(どこまでが誰の責任かの分かれ目)を確かめるよう答えています。 事業者に任せても、医療機関の責任は消えません。Q&A(企画管理編 Q5)は、クラウド型の電子カルテの事業者から患者の情報が漏れた場合でも、医療機関は医療情報の管理主体として責任を負うと答えています。原因が事業者にあれば、事業者も原因の究明や再発の防止の責任を負います。 ## 分かれ目を決めるのは医療機関と事業者 企画管理編 2 章の遵守事項(守るべき決まり)は、事業者と責任分界を取り決め、安全管理の役割分担も決めるよう求めています(①④)。決めた内容は、契約書や SLA(サービスの水準の取り決め)のように双方を縛る文書にします(2.1.1)。Q&A(企画管理編 Q11)は、誰が何をどのタイミングで行うかを文書にするよう答えています。 オンライン診療のシステムには、厚労省の「オンライン診療の適切な実施に関する指針」もあります。指針は、事業者に責任分界点を医療機関へ明確に説明し、合意した範囲で責任を負うよう求めています。医療機関の側には、その説明を受けて責任分界点を確かめるよう求めています(Ⅴ 2.(5))。医師やスタッフの交代については[オンライン診療で入れ替わる医師・スタッフのアカウント管理](/guides/healthcare-access/online-clinic-staff-turnover-accounts)にまとめています。 アカウントの設定は、利用者の側に残るのが基本です。総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」は、インターネット越しに完成品のサービスを使う形(SaaS)を取り上げています。アプリの動作の設定は事業者、「利用者アカウントや業務データの設定」は利用者の責任、という整理です(Ⅱ.1.2)。 第 7.0 版も、ID の管理は医療機関に求めています。システム運用編 14 章は、ID を台帳で管理し、定期的に棚卸し(何があるか一覧にすること)をして不要なものを削除するよう求めています(遵守事項⑧)。保守委託機関編(セキュリティ更新を含むサーバーの保守を、契約で事業者に全て任せている医療機関向けの編)も同じ考え方です。利用者の ID の台帳と棚卸し、削除の手順は、医療機関が自ら作ることが想定されています(10 章の解説)。ID の管理を事業者に任せるなら、不要なアカウントを確実に削除できる運用を取り決めて文書にします(9 章の解説)。職員が辞めたときの止め方は[医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](/guides/healthcare-access/staff-departure-account-shutdown)にまとめています。 ## 導入の前に開示書で確かめること 事業者の対策は、「製造業者/サービス事業者による医療情報セキュリティ開示書」(MDS/SDS)で確かめます。厚生労働省の標準規格になっている書式で、項目ごとに「はい」「いいえ」「対象外」で答えます。概説編 4.5 は、事業者から MDS/SDS などを受け取って合意し、契約書や SLA で明らかにするよう求めています。Q&A(企画管理編 Q17)は、保守委託機関編の別紙の項目がすべて「はい」か「対象外」かを見るよう答えています。保守委託機関編の対象なら、この確認は遵守項目でもあります(10 ⑨)。ただし「対象外」の項目は、医療機関の責任で対応します(同 Q17)。 別紙の SDS の項目のうち、アカウントと責任の範囲に関わるものと、見る理由は次のとおりです(括弧は別紙の項番)。 1. アクセス管理の機能(ID ごとに使える範囲を決める機能)と、それを職種・担当別に分けられるか(No.17、17.2)。これがないと、職種ごとの権限を設定できません。 2. 二要素認証(パスワードともう 1 つの方法で本人を確かめる仕組み)が使えるか(No.17.1)。保守委託機関編は、端末のアプリのログインに令和 9 年度までの採用を求めています(9 ④)。「はい」が対応予定の意味のこともあるので、いつから使えるかも聞きます。 3. アクセスの記録の機能と、記録を見られる人の制限(No.17.3/17.4、17.3.2)。記録の機能がなければ、業務日誌などで操作した人を残すことになります(システム運用編 17 章)。 4. 非常時のアカウントの管理手順を出せるか、平常に戻った後に使い続けられないよう変えられるか(No.57.1〜57.3)。 5. 管理責任の範囲を文書で示せるか(No.72、73)。 開示書は導入時に一度見れば済むものではありません。Q&A(保守委託機関編 Q7)は、製品やサービスの変更に合わせて確かめ直すよう答えています。厚生労働省のチェックリストも 2-③ で MDS/SDS の提出を求めています。チェックリストには、事業者に答えてもらう用紙(事業者確認用)もあります。院内で使う医療機関確認用との突き合わせ方は[厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts)にあります。 ## 利用規約だけで申し込むサービス 予約や問診のサービスには、個別の契約を結ばず、全員共通の利用規約(約款)で申し込むものもあります。企画管理編 2.1.5 は、約款の契約では中身を個別に調整しにくいため、事業者に分かりやすい情報の提供を求めるよう書いています。例として、MDS/SDS などの判断材料、説明を求めたときの対応、約款上のリスクの表示を挙げています。加えて、医療機関がリスクと役割分担を確かめたうえで使うと示し、合意することも挙げています。MDS/SDS が出てこない場合は、契約書や製品の仕様、問い合わせで別紙の項目を確かめます。Q&A(保守委託機関編 Q5)がそう答えています。 委託などの形をとらずに導入した汎用のシステムやサービスを使うなら、医療機関はシステム運用編の遵守事項にも対応します(保守委託機関編 10 ⑩)。保守委託機関編の対象になるのは、サーバーのセキュリティ更新を事業者が受け持つと契約書や約款に書かれている医療機関です。書かれていなければ対象とは判断できない、と Q&A(保守委託機関編 Q3)は答えています。 ## 取り決めに書いておくこと 使っているサービスが複数あるなら、まずサービスと事業者の一覧を作ります。事業者は互いのサービスを知らないので、医療機関の側で整理する必要があるためです(保守委託機関編 2 章の解説)。そのうえで、サービスごとに次を決めておくのが一例です。 1. スタッフの ID の発行と停止を誰が行い、どの連絡を受けて止めるか(保守委託機関編 9 ②) 2. 契約の後も、ガイドラインを守っていることを示す資料を求められること(企画管理編 2.1.2) 3. アクセスの記録をどう管理し、どの範囲で出してもらえるか(システム運用編 17.1) 4. 情報が漏れたときに、原因の調べと外部への説明をどう分けるか(企画管理編 2.1.3) 受付で 1 つの ID を何人かで使っていると、事業者の記録には ID しか残らず、誰が操作したかを記録から示せません。人ごとに ID を出せるか、その数に上限があるかは、事業者に問い合わせて確かめます。共有が残る理由と選択肢は[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。 ## よくある質問 **予約や問診のサービスもガイドラインの対象ですか** 第 7.0 版の Q&A は、医療情報システムを医療情報を扱うシステム全般と答えています。症状など診療に関わる患者の情報を入れるなら対象と読め、使う前に本人の確かめ方や使える範囲の制限、責任の分かれ目を確かめます。 **クラウドの事業者から情報が漏れたら誰の責任ですか** 第 7.0 版の Q&A は、医療機関も医療情報の管理主体として責任を負うと答えています。原因が事業者にあれば、事業者も原因の究明や再発の防止の責任を負います。 **退職したスタッフの ID は事業者が消してくれますか** 基本は医療機関の仕事です。システム運用編 14 章は、不要な ID を棚卸しで見つけて削除するよう求めています。事業者に任せるなら、確実に削除できる運用を取り決めて文書にします。 **MDS/SDS の「対象外」とはどういう意味ですか** その項目は医療機関の責任で対応する、という意味です。Q&A(企画管理編 Q17)がそう注意しています。厚労省のチェックリストの、事業者に答えてもらう用紙(事業者確認用)でも、「対象外」は医療機関が責任を負う項目です。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 Q&A」](https://www.mhlw.go.jp/content/10808000/001752355.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「オンライン診療の適切な実施に関する指針」(令和 8 年 4 月改訂)](https://www.mhlw.go.jp/content/001685701.pdf) - [総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」(2022 年 10 月)](https://www.soumu.go.jp/main_content/000944468.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 受付の何人かで予約や問診の管理画面の ID を 1 つ使うと、事業者の記録には ID しか残らず、誰が操作したかは院内で聞いて回ります。ブラウザーで開くサービスなら、Junify を通すと誰が・いつ使ったかが一人ずつ残ります。導入時にパスワードを変えて Junify だけが持ち、スタッフは自分のスマホで本人確認してから入ります。辞めた人は割り当て(使ってよいアカウントの指定)を外せば入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 - [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](/guides/healthcare-access/staff-departure-account-shutdown): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 --- # 医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 更新日: 2026-10-14 サイバー攻撃を受けたら、まず保守会社に連絡し、ネットワークを遮断して、記録を守ります。厚生労働省の BCP の手引きは、攻撃者が残した裏口(バックドア)の無効化なども、この初動の被害拡大防止に置いています。ガイドラインは、侵害された可能性のある機器に保存されていた ID とパスワードの無効化を、復旧の際の方策に挙げています。非常時用のアカウントは、正常に戻った後に使えないように変えます。 ## 攻撃を受けたときに決まっていること 厚労省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、システム運用編 18 章の遵守事項(守るべき決まり)で、攻撃を受けたときの対応を 4 つ挙げています。 - 攻撃を受けたサーバーなどを切り離すための、外部ネットワークの一時切断 - コンピュータウイルスなどが入った機器の隔離 - 被害を確かめるための業務システムの停止 - バックアップからの重要なファイルの復元 18 章は、この 4 つを初動と復旧に分けていません。サイバー攻撃を想定した BCP(事業継続計画)の手引きでは、バックアップからの復元は復旧の段階に置かれています(4-3)。 連絡先も決められています。平成 30 年の厚労省の通知は、攻撃の疑いがあれば直ちに保守会社などに連絡するよう、医療機関への注意喚起を自治体に求めました。システムに障害が出て、個人情報の漏えいや医療の提供体制への支障が生じる、またはそのおそれがあると判断したら、厚労省へ連絡します。令和 4 年 11 月の厚労省の事務連絡も、事故が起きたときやそのおそれがあるときは、速やかに厚労省などに連絡するよう挙げています。企画管理編 12 章も、所管官庁(医療機関を受け持つ役所)への連絡を遵守事項にし、手順に厚労省と都道府県警察などへの報告を含めるよう求めています(12.3)。 医療情報が漏えいした場合は、個人情報保護法に基づく漏えい等の報告が要ることがあります(企画管理編 3.1.2)。報告が要る場合と期限は[漏えい等とは(個人情報保護法の報告義務)](/guides/incidents/what-is-data-breach)にまとめています。 ## 記録を守る 企画管理編の表 11-1 は、サイバー攻撃のときに要る対応として、被害状況の把握、被害拡大の防止、原因の究明と並べて「証拠・証跡の保全」を挙げています。BCP の手引きは、アクセスの記録の分析や、情報が書き換えられたり暗号化されたりしていないかを見て、攻撃の範囲と個人情報の漏えいの有無を調べるとしています。自院で証拠を保全できなければ、事業者に頼みます(3-5)。 手引きは、この証拠保全を初動対応に置き、再設定や入れ直し、バックアップからの復元を後の復旧処理に置いています(4-3)。端末を初期化したりシステムを入れ直したりすると、その中の記録が消えることがあります。そうなると、攻撃者が作ったアカウントや悪用された ID を、後から突き止める手がかりがなくなります。厚労省の BCP 確認表は、証拠保全が不十分で被害範囲を特定できなかった例があったと書いています。 アカウントについて守る記録は、誰がいつ入って何をしたかを示すものです。システム運用編 17 章は、ログイン時刻・アクセス時間・操作した医療情報が分かる記録を残し、不当な削除や改ざんを防ぐことを遵守事項にしています。 システムの管理を事業者に任せていると、記録が事業者の側にあることがあります。ガイドラインは、記録の管理方法と提供を事業者と取り決めるよう求めています(システム運用編 17.1)。事故の日に誰に頼めば記録が出てくるかは、この取り決めで決まります。記録の残し方は[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にまとめています。 ## 侵害された可能性のある ID とパスワードを無効にする 手引きは、初動の被害拡大防止(3-3)に、ネットワークの遮断と並べてバックドアの無効化などを挙げています。バックドアは、攻撃者が後で入り直すために残す裏口です。手引きが参照先に示すシステム運用編 18.1 は、復旧の際に侵入の継続と被害の拡大を防ぐ方策として、裏口を残さないことと並べて次の一文を置いています。 > 不正に作成されたり、侵害された可能性のある機器に保存されていた ID・パスワード等を無効化する 攻撃者が作ったアカウントと、乗っ取られた可能性のある機器に保存されていた ID・パスワードの両方を無効にする、と読めます。資料は、全員のパスワードを一斉に変えることを初動の手順には挙げていません。どの機器が侵害されたかは記録から調べます。記録の保全が初動に入るのは、このためでもあります。 無効にする範囲を決めるには、どの機器にどの ID とパスワードが保存されていたか、その ID を誰が知っているかが分かっている必要があります。企画管理編 13 章は、管理者の権限の種類とその ID、使ってよい人を一覧にし、必要に応じて認証に関する情報の変更などを指示することを遵守事項にしています(⑥)。ほかの ID も、定期的に棚卸し(何があるか一覧にすること)をして、不要なものを消すよう求めています(⑦)。これがないと、どこまで変えれば足りるかを事故の日に決められません。 同じ攻撃を繰り返させないための備えも示されています。令和 4 年 11 月の事務連絡は、病院がランサムウェア(データを使えなくして身代金を求めるウイルス)の被害を受けた事案を受けて出されました。その「リスク低減のための措置」は、アカウントについて次の 3 つを挙げています。 - パスワードを複雑なものに変え、使い回さない - 不要なアカウントを削除し、権限を確かめる - 多要素認証(2 つ以上の方法で本人を確かめること)を使う これらは平時の備えですが、復旧でパスワードを変え直すときの目安にもなります。 1 つの ID を複数人で使っている場合は、作業が増えます。その ID のパスワードを変えると、使う人全員に新しいパスワードを伝え直すことになります。伝える手段が紙のメモやメッセージなら、変えたばかりのパスワードがまた紙や端末に残ります。システムの記録には ID しか残らないので、記録だけでは実際に操作した人を絞れません。 ## 非常時用のアカウントは正常に戻った後に変える システム運用編 11 章の遵守事項は、非常時用のアカウントと機能について 3 つを求めています。 - 使う手順を整える - 通常時に不適切に使われないよう管理し、使われたら気づけるようにする - 使われた場合は、正常に戻った後に使い続けられないように変える 11.2 は、正規の権限を持つ人が操作できないときなどに、このアカウントで医療情報を使えるようにする運用を想定しています。考え方は[緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account)にまとめています。 サイバー攻撃で電子カルテが止まると、手引きが例に挙げる紙カルテの運用や、参照用のサーバーや端末を別に用意する運用に切り替えることがあります(3-4)。そのために臨時のアカウントを作って配ったなら、11 章が直接定めるものではありませんが、同じ考えで正常に戻った後に使えないように変えておきたいところです。 ## 平時に用意しておくもの 事故の日にアカウントの作業で迷わないために、次の 4 つを平時に用意します。 1. ID の一覧。管理者用の ID は、権限の種類と使ってよい人を一覧にします(企画管理編 13 章 ⑥)。ほかの ID も定期的に棚卸しをします(⑦)。無効にする範囲を決める元になるからです。 2. 連絡体制図。保守会社などの事業者、厚労省、警察への連絡体制を整え、連絡先を院内に掲示するなど全職員が分かる形にします(手引き 1-2・2-1)。システムが止まると、パソコンの中の連絡先は見られないかもしれないからです。 3. 記録の置き場所と取り出し方。事業者に任せているシステムは、誰に頼めば記録が出るかを取り決めます(システム運用編 17.1)。 4. 非常時用のアカウントの手順と、正常に戻った後に変える手順(システム運用編 11 章)。 ## よくある質問 **攻撃の疑いがあるとき、最初の連絡先はどこですか** 平成 30 年の厚労省の通知は、直ちに保守会社などに連絡するよう求めています。個人情報の漏えいや医療の提供体制への支障、またはそのおそれがあれば厚労省に連絡します。ガイドラインは警察への報告も挙げています。 **すぐに全員のパスワードを変えるべきですか** 資料は、全員のパスワードを一斉に変えることを初動には挙げていません。初動は裏口の無効化などと記録の保全です。侵害された可能性のある機器に保存されていた ID・パスワード等の無効化は、ガイドラインでは復旧の際の方策です。 **アクセスの記録はなぜ初動で守るのですか** 記録は攻撃の範囲と個人情報の漏えいの有無を調べる材料だからです。端末の初期化や入れ直しで消えることがあり、そうなると被害の範囲を特定できなくなります。厚労省は、証拠保全が不十分で範囲を特定できなかった例を挙げています。 **非常時用のアカウントは復旧後どうしますか** システム運用編 11 章は、非常時用のアカウントが使われた場合、正常に戻った後は使い続けられないように変えることを遵守事項にしています。通常時に使われたら気づけるよう管理することも求めています。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「サイバー攻撃を想定した事業継続計画(BCP)策定の確認表」(医療機関用、令和 6 年 6 月)](https://www.mhlw.go.jp/content/10808000/001261299.pdf) - [厚生労働省「サイバー攻撃を想定した事業継続計画(BCP)策定の確認表のための手引き」(医療機関用、令和 6 年 6 月)](https://www.mhlw.go.jp/content/10808000/001261301.pdf) - [厚生労働省「医療情報システム部門等における BCP のひな形」(令和 6 年 6 月)](https://www.mhlw.go.jp/content/10808000/001261302.pdf) - [厚生労働省医政局関係課長連名通知「医療機関等におけるサイバーセキュリティ対策の強化について」(平成 30 年 10 月 29 日 医政総発 1029 第 1 号ほか)](https://www.mhlw.go.jp/content/10808000/001011697.pdf) - [厚生労働省 事務連絡「医療機関等におけるサイバーセキュリティ対策の強化について(注意喚起)」(令和 4 年 11 月 10 日)](https://www.mhlw.go.jp/content/10808000/001024395.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 攻撃のあと共有の ID のパスワードを変えると、使う人全員に新しいパスワードを伝え直し、調べる側は誰がいつ使ったかを勤務表からたどることになります。Junify では導入時にパスワードを変えて Junify だけが持つので、変えた後も管理者が登録し直すだけで、スタッフへの連絡は要りません。誰が・いつ・どのアカウントを使ったかは一人ずつ残ります(ブラウザーで開く診療システムの場合)。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 - [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](/guides/healthcare-access/staff-departure-account-shutdown): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 --- # オンライン資格確認の端末で使うアカウントとパスワードの管理 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 更新日: 2026-10-14 オンライン資格確認の端末(資格確認端末)には、性質の違う ID とパスワードが重なっています。Windows のログイン、電子証明書、オンライン資格確認等システムのアカウントです。システムのアカウントは職員ごとに作れるので、受付で 1 つの ID を使い回す必要はありません。 ## 資格確認端末にある ID とパスワード 資格確認端末は、マイナンバーカードなどで患者の保険の資格を確かめるために置くパソコンです。厚生労働省の「資格確認端末において満たすべき要件」は、推奨する Windows の版と、Microsoft Edge で使う前提を示しています。この端末で管理するものは 3 つあります。 1 つ目は Windows のアカウントです。手順は、医療機関等向け総合ポータルサイト(オンライン資格確認の手続きや資料をまとめた公式サイト)のセットアップ手順書(資格確認端末編)にあります。手順書は、「OqsComApp」という名前のアカウントを Windows に加え、管理者の権限にするよう示しています。パスワードは任意で、[医療情報システムの安全管理に関するガイドライン](/guides/healthcare-access/what-is-medical-information-system-security-guideline)や施設のセキュリティの決まりに従って設定するよう注記があります。 2 つ目は電子証明書(その端末が資格確認端末として準備されたものだと示すためのデータ)です。取り込むときに証明書のパスワードを入れ、「このキーをエクスポート可能にする」にはチェックをしない設定が手順書に書かれています。別のパソコンへ持ち出せない形で入れるということです。 3 つ目がオンライン資格確認等システムのアカウントで、ユーザ ID とパスワードで入ります。このほか端末の外に、総合ポータルサイトのログインがあります。ポータルにログインできる人は、システムの最上位のアカウント(マスタアカウント)のユーザ ID を確かめられます。 ## システムのアカウントの種類 操作マニュアル(管理者編)は、アカウントを 8 種類に分けています。人が使うものと、機器やシステムの連携に使うものがあります。WebAPI は、電子カルテなどがシステムにつなぐための口のことです。 | 種類 | 登録に使うアカウント | 作る単位 | 主な用途 | | --- | --- | --- | --- | | マスタアカウント | 利用申請の際に登録される | — | 管理アカウントの登録 | | マスタアカウントリセット用アカウント | 利用申請の際に登録される | — | マスタアカウントのパスワード初期化 | | 管理アカウント | マスタアカウント | — | ほかのアカウントの登録、設定の変更 | | 一般アカウント | 管理アカウント | 一人ずつ | 資格確認 | | 医療情報閲覧アカウント | 管理アカウント | 有資格者など一人ずつ | 資格確認、薬剤・診療情報などの閲覧 | | WebAPI 用アカウント | 管理アカウント | 資格確認端末ごと | 電子カルテやレセプトコンピューターからの接続 | | 連携アプリ用アカウント | 管理アカウント | 資格確認端末ごと | 連携アプリケーションでの資格確認など | | 顔認証用アカウント | 管理アカウント | 顔認証付きカードリーダーごと | カードリーダーでの資格確認 | 作る単位は手順書によります。手順書は、一般アカウントと医療情報閲覧アカウントを「個人ごとに」作るとしています。受付の全員が 1 つの一般アカウントで入る運用は、この作り方から外れます。ユーザ ID と権限の種類は登録後に変えられず、権限を変えるときは新しく登録し直します。 ## 職員が入るとき、辞めるとき 入るときは、管理アカウントの「アカウント管理(登録)」で、権限の種類、ユーザ ID、氏名、利用開始年月日を入れて作ります。登録すると初期パスワードが表示され、マニュアルはそれを依頼した人に伝えるよう書いています。初期パスワードは、30 日以内にログインしないと使えなくなります。 パスワードを忘れた職員には、管理アカウントで初期化して渡し直します。厚労省のガイドライン第 7.0 版(システム運用編 14 章)は、運用担当者が利用者のパスワードを変えるときの手順を遵守事項にしています。本人確認をし、その方法を台帳に書き、本人以外が知り得ない方法で知らせることです。口頭で伝えるだけでは記録が残りません。 辞めるときは、更新の画面で利用終了年月日を入れるか、無効にするか、削除します。削除したユーザ ID は、同じものを登録し直せません。同じ 14 章は、ID を台帳で管理し、定期的に棚卸し(何があるか一覧にすること)をして不要なものを削除するよう求めています。止め方と、職員の一覧と突き合わせる時期を決めておきます。 ## 管理用の ID を誰が持つか 管理アカウントは、システムの導入時に必ず作られています。分からなくなったときの戻り方は、ポータルの資料が示しています。マスタアカウントでログインすれば、管理アカウントのユーザ ID を確かめてパスワードを初期化できます。マスタアカウントのパスワードは、マスタアカウントリセット用アカウントで初期化します。リセット用のパスワードは、利用申請のときに決めた 4 桁の「秘密の番号」です。 この順番を逆から見ると、マスタアカウントを持つ人は管理アカウントを、管理アカウントを持つ人はすべての職員のアカウントを初期化できます。さらに、ポータルにログインできて秘密の番号を知っている人は、マスタアカウントのパスワードを初期化できます。セットアップ手順書は、マスタアカウントとリセット用アカウントを「大切に保管してください」としています。厚労省は、院内規程の雛形として「安全対策の規程例」を示しています。規程例では院長がシステム管理者を務めます(別の人も指名できます)。システム管理者は、送信機器の設定の変更や更新を行う管理者の権限などの運用について、最終的な責任を負います。決め方の一例は、マスタアカウントと管理アカウントを持つ人と保管場所を決めておき、その人が辞めたらパスワードを初期化して持ち主を替えることです。ポータルのログインと秘密の番号も、誰が知っているかを同じように決めておきます。 ## 端末そのものの扱い 規程例は、端末の扱いについても項目を挙げています。 - 業務に必要なソフト以外が入っていないことを点検する - USB メモリーなどの接続を制限する - のぞき見を防ぐフィルターを付ける - 許可なく部屋の外へ持ち出さない 利用者には、ID とパスワードを本人しか知り得ない状態に保つことを求めています。 1 台を複数の職員で使う場合に、職員ごとに Windows のアカウントを作って切り替える方法も、手順書に載っています。OqsComApp のパスワードは端末の定時の再起動の設定にも入れるので、変えるときは入れ直す場所を導入した業者に確かめます。 ## パスワードの決まりをどれに合わせるか 規程例は、二要素認証を使っていない場合、パスワードを「最長でも 2 か月以内に」変えるとしています。規程例と並んで示されているセキュリティのガイドライン(令和 6 年 1 月一部改正)は、第 7.0 版より前の第 6.0 版を挙げています。第 7.0 版(システム運用編 14.1.1)は、二要素認証があれば 8 桁以上、なければ 13 桁以上とし、どちらの場合も定期的な変更は不要としています。13 桁以上を設定できないシステムでは、設定できる最大の桁数にします。 厚労省の「セキュリティに関するガイドライン」は、オンライン資格確認やオンライン請求のシステムを対象にしています。これらも医療情報を扱うので、医療情報システムの安全管理に関するガイドラインに沿って運用すべきだ、という立場です。最新版を参照するようにも求めています。規程例は雛形なので、パスワードの項目は第 7.0 版に合わせて書き換えると読めます。ただし規程例を写して院内規程を作った施設では、書き換えるまでは 2 か月の条が自院の決まりです。書き換えるときは桁数の条件もあわせて直します。桁数の決め方は[医療情報システムの安全管理に関するガイドラインが定めるパスワードの桁数・変更・使い回し](/guides/healthcare-access/password-rules-in-medical-guideline)にまとめています。 ## よくある質問 **受付の全員で 1 つのアカウントを使ってもかまいませんか** 勧められません。セットアップ手順書は一般アカウントと医療情報閲覧アカウントを個人ごとに作るとし、厚労省の規程例は ID とパスワードを本人しか知り得ない状態に保つよう求めています。人数分は管理アカウントで作れます。 **管理アカウントのパスワードが分かりません** マスタアカウントでログインし、管理アカウントのユーザ ID を確かめてパスワードを初期化します。マスタアカウントのユーザ ID は、医療機関等向け総合ポータルサイトから確かめられます。 **辞めた職員のアカウントはどう止めますか** 管理アカウントで、利用終了年月日を入れる、無効にする、削除する、のいずれかを行います。削除したユーザ ID は同じものを登録し直せないので、止め方を院内で決めておきます。 **パスワードは 2 か月ごとに変える必要がありますか** 規程例は二要素認証がなければ 2 か月以内の変更を挙げますが、第 6.0 版の時期の雛形です。第 7.0 版は 13 桁以上(二要素認証があれば 8 桁以上)なら定期的な変更は不要です。院内規程も桁数とあわせて直します。 ## 参考資料 - [厚生労働省「資格確認端末において満たすべき要件」(令和 8 年 5 月 1 日版)](https://www.mhlw.go.jp/content/10200000/000623527.pdf) - [医療機関等向け総合ポータルサイト「医療機関等向け 資格確認端末のセットアップ」(3.23 版)](https://iryohokenjyoho.hpdx.or.jp/sys_attachment.do?sys_id=6e440b1b93af4350e4b0f0ca2bba1087) - [医療機関等向け総合ポータルサイト「オンライン資格確認等システム 操作マニュアル 管理者編」(2026 年 10 月 第 3.17 版)](https://iryohokenjyoho.hpdx.or.jp/sys_attachment.do?sys_id=7b448b1b93af4350e4b0f0ca2bba1083) - [医療機関等向け総合ポータルサイト「管理アカウントでのオンライン資格確認等システムへのログイン方法」(令和 7 年 1 月)](https://iryohokenjyoho.hpdx.or.jp/sys_attachment.do?sys_id=2f9ae4983bc80bd0c260ee8a04e45acf) - [厚生労働省「オンライン資格確認等、レセプトのオンライン請求及び健康保険組合に対する社会保険手続きに係る電子申請システムに係るセキュリティに関するガイドライン」(令和 2 年 10 月、令和 6 年 1 月一部改正)](https://www.mhlw.go.jp/content/12400000/001189504.pdf) - [厚生労働省「オンライン資格確認等システム及びレセプトのオンライン請求システムに係る安全対策の規程例(別添 4)」](https://www.mhlw.go.jp/content/12400000/001189505.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 資格確認端末とオンライン資格確認等システムは Junify の対象外です。使えるのは、ブラウザーで開く業務サービスの、施設に 1 つの管理用の ID です。そのパスワードを誰が知っているかが担当者の記憶頼みなら、導入時にパスワードを変えて Junify だけが持ち、使ってよい人を割り当て(使ってよいアカウントの指定)で決めます。入る人は自分のスマホで本人確認をし、誰がいつ入ったかが残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](/guides/healthcare-access/staff-departure-account-shutdown): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 --- # 医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。 更新日: 2026-10-14 職員が辞めたときに止めるのは、その人が使えるすべての医療情報システムの ID です。院内の電子カルテだけでなく、院外のクラウドサービスも含みます。複数人で使う ID は消せないので、パスワードを変えます。部署を移ったときは、ID を残して権限を変えます。厚生労働省の[医療情報システムの安全管理に関するガイドライン](/guides/healthcare-access/what-is-medical-information-system-security-guideline)(第 7.0 版)は、退職した職員を利用者の登録から削除するよう求めています。ID を人事の登録と合う形で管理するという考え方です。何日以内に止めるかは書かれていないので、期限と担当は施設で決めます。 ## 止める対象になるアカウント 企画管理編 13 章の遵守事項(守るべき決まり)③は、院内の利用者を、医療機関に所属していることを前提に管理するよう求めています。考え方の節(13.1.2)には、職員が退職する場合は医療情報システムの利用者登録からも削除する、とあります。 医療情報システムは、医療に関する患者の情報(本人が分かる情報を含むもの)を扱う情報システム全般です(概説編 2.2・2.3)。院内で動くシステムに限らず、事業者が提供するサービスも含まれます。予約や問診のサービスも、受診の内容や症状を患者ごとに扱うなら対象になると読めます。退職者 1 人について、確かめる先と止め方は次のとおりです。無効化は、ID を残したまま使えなくすることです。 | アカウントの種類 | 例 | 止め方 | | --- | --- | --- | | 院内のシステムの個人の ID | 電子カルテ、医事会計、部門システム | 利用者の登録から削除か無効化 | | 院外のクラウドサービスの ID | 予約、問診、オンライン診療 | サービスの管理画面で削除か無効化 | | 端末やサーバーへのログイン | 職員の端末、院内のサーバー | 端末やサーバーの利用者から削除か無効化 | | IC カードなどの認証用の機器 | ログインに使うカード | そのカードを使えなくする(失効) | | 複数人で使う ID | 部署で共有する ID | パスワードを変える | 削除と無効化のどちらでもかまいません。厚労省の Q&A は、ID の「不要なものは適宜削除すること」に、不要な ID の無効化も含まれると答えています(システム運用編の Q33)。どちらを選べるかはシステムによって違うので、事業者に確かめます。IC カードについて Q&A は、カードを個人に結びつけ、紛失・貸し借り・失効を管理するよう求めています(同 Q34)。 ## いつ止めるか ガイドラインもチェックリストも、退職から何日以内に止めるかを定めていません。手がかりになるのは、チェックリストのマニュアルにある利用者 ID の台帳の例です。退職予定の職員の行は、説明が「使用者/退職予定」、状態が「使用可（23年３月まで）」となっています。退職の日が決まった時点で、台帳に使える期限を書いておく形です。 期限をどこに置くかは施設が決めます。考え方のもとになるのは、システム運用編 14.2 の、付ける権限は必要最小限にすることが重要だという記述です。決め方の一例は、最終の勤務日の業務が終わった時点です。休暇の消化で最終勤務日と退職日が離れる場合も、この考え方で、その間に診療システムを使う業務があるかを見て決めます。 異動のときは、ID を消さずに権限を変えます。14.2 は、人事異動などで担当業務が変わるのに合わせて、アクセス権限を適宜更新する必要があるとしています。前の部署の権限を残したまま新しい権限を足すと、両方の部署の情報が見える状態が続きます。権限の付け直しは、システム運用編 14 章の遵守事項④にならい、異動先の部署の申請を受けて行い、その部署の管理者に確かめてもらいます。 長く休む職員の ID の扱いは、ガイドラインには書かれていません。マニュアルは、長い間使われていない ID も不正なアクセスに使われるおそれがあるとして、削除や無効化の対象に挙げています。休んでいる間は無効にして、復帰の日に戻すのが決め方の一例です。 ## 誰が何をするか ガイドラインは、経営層・企画管理者・システムの担当者の 3 つの役割ごとに編を分けています(概説編 3.1)。企画管理者は安全管理の実務を、システムの担当者は設定と運用の実務を担う人です。退職と異動の手続きは、この分け方に沿って役目を割り振れます。 出発点は人事の手続きです。退職と異動も、人事の記録から始まります。人事の担当から ID を扱う担当へ、退職日と異動日をいつ、どの手段で伝えるかを決めておきます。 手順づくりを指示するのは企画管理者です。企画管理編 13 章が担当者に作らせる手順のうち、退職と異動にかかわるのは 3 つです。人事の情報と合わせて ID を付ける手順(遵守事項③)、部署の申請を受けて権限を付ける手順(④)、ID の棚卸し(何があるか一覧にすること)の手順(⑦)です。システム運用編 14 章も、ID を台帳で管理し、定期的に棚卸しをして不要なものを削除すること、その手順を作ることを遵守事項にしています(⑧)。止める操作をするのは、システムの担当者か、契約している事業者です。棚卸しの結果は、企画管理者が経営層に報告し、承認を得ます(企画管理編 13 章 遵守事項⑦)。 ただし小さな医療機関では、役割が分かれていないことがあります。保守委託機関編の対象を説明する概説編 3.1.5 は、小規模な医療機関には専任のシステム担当者がおらず、経営層と企画管理者が分かれていないことが多いと想定しています。1 人が役目を兼ねていても、人事の記録と ID の台帳を突き合わせる作業はなくなりません。 ## 事業者が ID を管理しているとき 保守委託機関編は、サーバーの保守を事業者に全て委託している医療機関向けの編です。その 9 章も、退職者や使っていないアカウントの削除か無効化を求めています。9 章の解説も、事業者に任せる場合は削除の運用を文書で取り決めるよう求めています。医療機関と事業者の責任の分け方の全体は、[予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split)にまとめています。 退職の場面で取り決めておくのは、誰が、どの手段で、いつまでに削除を頼むかと、済んだことをどう知らせてもらうかです。チェックリストで事業者が 2-⑤を「対象外」とした場合は、退職者の ID を止める責任は医療機関の側にあります。突き合わせ方は[厚労省のサイバーセキュリティ対策チェックリストの記事](/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts)にあります。 ## 複数人で使う ID とパスワードを知る人 複数人で使う ID は、1 人が辞めても残る人が使い続けるので、削除できません。辞めた人はパスワードを覚えたままです。その人だけを止めるには、パスワードを変え、残る人にだけ新しいパスワードを伝えるほかありません。システム運用編 14 章は、ID とパスワードを本人しか知り得ない状態に保つことを遵守事項にしています。共有の ID は、もともとこの形に合いません。どんな場面で共有の ID が残るかは[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。 止め漏れは、定期的な棚卸しで拾えます。退職のたびに、台帳の行ごとに止めた日と止めた人を書き残しておくと、棚卸しのときにどこまで済んでいるかが分かります。共有の ID の行には、パスワードを変えた日も書いておきます。 ## よくある質問 **退職者の ID は削除しないといけませんか** 無効化でも足ります。厚労省の Q&A は、ID の「不要なものは適宜削除」に、不要な ID の無効化も含まれるとしています。チェックリストの 2-⑤も、削除か無効化をしているかを問う項目です。 **退職から何日以内に止めればよいですか** ガイドラインにもチェックリストにも日数の定めはありません。退職日が決まった時点で台帳に使える期限を書き、最終の勤務日の業務が終わったら止める、というのが決め方の一例です。 **異動した職員の ID はどうしますか** ID は残し、権限を新しい担当業務に合わせて見直します。システム運用編 14.2 は、人事異動などで担当業務が変わるのに合わせて、権限を適宜更新する必要があるとしています。 **事業者が ID を管理している場合はどうしますか** 保守委託機関編は、不要なアカウントを確実に削除できる運用を事業者と取り決め、文書にするよう求めています。誰が、どの手段で、いつまでに頼むかと、済んだ知らせの受け方を決めます。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン Q&A」(令和 8 年 9 月)](https://www.mhlw.go.jp/content/10808000/001752355.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年 6 月)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリストマニュアル ～医療機関・薬局・事業者向け～」(令和 8 年 6 月)](https://www.mhlw.go.jp/content/10808000/001716186.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 退職の連絡を受けると、いまはその人が使うシステムを台帳でたどり、その日のうちに管理画面を開いて止めています。ブラウザーで開くシステムを Junify に登録し、導入時にパスワードを変えて Junify だけが持てば、割り当て(使ってよいアカウントの指定)を外した時点で、登録したシステムには入れません。ID の削除は後日、手順どおりに進められ、共有の ID のパスワードも作り直さずに済みます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療法に基づく立入検査で、サイバーセキュリティについて確認されること 病院への立入検査は原則年 1 回です。サイバーセキュリティでは、厚労省のチェックリストの全項目に確認日と回答が書かれているかを見て、機器の台帳・連絡体制図・BCP・規程類は現物を確かめます。 更新日: 2026-10-13 病院への立入検査は、医療法 25 条 1 項に基づいて都道府県や保健所を置く市などが行います。厚生労働省の立入検査要綱は、すべての病院を原則年 1 回の対象にしています。サイバーセキュリティは令和 5 年度から検査項目に入りました。確かめられるのは、厚生労働省の「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」の記入と、そこに挙がる台帳や連絡体制図などの現物です。 ## 立入検査は誰が、どのくらいの間隔で行うか 医療法 25 条 1 項は、立入検査を行える者を、都道府県知事と、保健所を設置する市・特別区の長と定めています。これらの長は、病院・診療所・助産所などに職員を立ち入らせ、検査させることができます。検査の対象は人員、清潔の状態、構造設備、診療録や帳簿書類などです。立入検査要綱によると、施設を訪れるのは知事や市長・区長が任命した医療監視員です。 検査の間隔は法律には書かれていません。立入検査要綱は厚生労働省医政局が定めたもので、令和 8 年 6 月に一部が改正されました。要綱は医療法に基づくすべての病院を対象とし、「原則年１回実施する」としています。診療所については、令和 8 年度の実施通知が、検査の必要性に応じて対応するよう都道府県などに求めています。令和 5 年 3 月の厚生労働省の検討会資料は、目安を次のように示しています。病院は原則毎年、ベッドのある診療所は概ね 3 年に 1 度、ベッドのない診療所と助産所は随時です。令和 5 年度は、全国 8,138 の病院のうち 7,587 施設(93.2%)に立入検査が行われました。 「医療監査」という言葉で、保険診療の指導・監査を指すこともあります。こちらは、地方厚生(支)局と都道府県が健康保険法 73 条(指導)と 78 条(監査)などに基づいて行います。扱うのは診療の内容と診療報酬の請求です(厚生労働省の指導大綱・監査要綱)。立入検査とは別の制度なので、この記事では扱いません。 ## サイバーセキュリティが検査項目になった経緯 令和 5 年 4 月 1 日に施行された医療法施行規則 14 条 2 項が、病院・診療所・助産所の管理者に次の義務を課しました。 > 医療の提供に著しい支障を及ぼすおそれがないように、サイバーセキュリティを確保するために必要な措置を講じなければならない。 施行時の通知は、この「必要な措置」として、最新の[医療情報システムの安全管理に関するガイドライン](/guides/healthcare-access/what-is-medical-information-system-security-guideline)を参照するよう求めました。あわせて、優先して取り組む事項はチェックリストで示すとしています。立入検査要綱の検査表には「サイバーセキュリティの確保」(2-19)が加わりました。検査の基準は、チェックリストに必要な事項が記入されているかを確かめることです。連絡体制図は、特に提示を求めて有無を確かめることになっています。 ただし、要綱の基準は令和 8 年 6 月の改正後も、ガイドライン第 6.0 版と令和 7 年度版のチェックリストを参照先に挙げたままです。令和 8 年度の実施通知も、参考には同じ版を挙げています。そのうえで、ガイドラインとチェックリストは改定されるので最新版を使うよう、検査する側に求めています。最新の令和 8 年度版チェックリストには、冒頭に「立入検査時、本チェックリストを確認します」と書かれています。 ## 検査の日に確かめられるもの チェックリストのマニュアルは、立入検査で何をどう確かめるかを示しています。チェックリストには、医療機関が書く「医療機関・薬局確認用」と、電子カルテなどの事業者が書く「事業者確認用」があります。医療機関は事業者ごとに事業者確認用を送り、回収しておきます。 | 確かめられるもの | 項目 | 検査での扱い | | --- | --- | --- | | 両方のチェックリストの全項目 | すべて | 確認日と回答の記入を確認 | | サーバー・端末・ネットワーク機器の台帳 | 2-① | 現物を確認 | | インシデント発生時の連絡体制図 | 3-① | 現物を確認 | | サイバー攻撃の想定を含む BCP | 3-③ | 現物を確認 | | 運用管理規程などの規程類 | 4-① | 現物を確認 | | サーバーのアクセスの記録 | 2-⑬ | 直接確認することがある | インシデントは攻撃や障害などの事故のことで、BCP はシステムが止まったときにも診療を続けるための事業継続計画です。現物を確かめる 4 つは、マニュアルが立入検査までに作っておくよう求めています。「いいえ」と答えた項目には、令和 8 年度中の対応の目標日を書きます。点検は少なくとも年に 1 回行うよう求められ、立入検査の前にもう一度チェックリストで確かめることも勧められています。 事業者と運用や保守の契約がなく売買だけのシステムでは、事業者に確かめる 2 つの項目の確認は求められません。遠隔保守を使う機器の有無(2-②)と、事業者からのセキュリティの開示書の提出(2-③)です。その場合、そのシステムの保守の責任は医療機関の側にあります。 ## アカウントに関わる項目 チェックリストのうち、アカウントとログインに関わるのは区分 2 にある次の 7 項目です。 - 2-④ 利用の権限 - 2-⑤ 退職者や使っていないアカウントの削除 - 2-⑦・2-⑧ パスワードの桁数と使い回し - 2-⑪・2-⑫ 二要素認証 - 2-⑬ アクセスの記録 検査の日、これらは主に記入で確かめられ、記録そのものを見られることがあるのは 2-⑬ です。また 4-① は、区分 1〜3 のすべての項目について、具体的な実施方法を規程類に書くよう求めています。そのため、アカウントの発行や削除の手順も、現物を見られる規程類に含まれることになります。 1 つの ID を複数のスタッフで使っていると、1 人が辞めても、ほかの人が使い続けるので ID を消せません(2-⑤)。アクセスの記録にも ID の名前しか残らず、誰が使ったかまでは分かりません(2-⑬)。項目ごとの確かめ方と共有の ID の扱いは、[厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts)にあります。 サーバーの二要素認証(2-⑫)には、検査の場で説明が求められうる点があります。踏み台の端末(サーバーに入る前に必ず経由する専用のパソコン)を使う構成か、それと同等以上の措置があれば、二要素認証を取り入れたものとみなせます。ただし、マニュアルが挙げる 3 つの前提を満たすことが条件です。同等以上かどうかは、立入検査の際に検査職員へ説明できることが想定されています。前提を含む全体は[医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts)にあります。 ## 不適合とされたとき 立入検査要綱は、不適合の事項があれば、開設者(病院を開いた法人や個人)や管理者にその事実を知らせるとしています。そのうえで、改善計画書の提出を求めることも含めて、改善のための指導を行います。 令和 5 年度の病院への立入検査では、「サイバーセキュリティの確保」は適合の割合が最も低い項目でした。検査した 6,188 施設のうち適合は 5,639 施設で、適合率は 91.1% です。 ## よくある質問 **病院の立入検査は何年ごとですか** 厚労省の立入検査要綱は、すべての病院を対象に原則年 1 回としています。厚労省の検討会資料では、有床診療所は概ね 3 年に 1 度、無床診療所と助産所は随時が目安です。 **立入検査と保険診療の指導・監査は同じですか** 別の制度です。立入検査は医療法 25 条に基づき都道府県や保健所設置市などが行います。指導・監査は健康保険法 73 条・78 条などに基づき、地方厚生(支)局と都道府県が診療内容と請求について行います。 **診療所もサイバーセキュリティを確認されますか** 医療法施行規則 14 条 2 項の義務は病院・診療所・助産所の管理者にかかります。チェックリストのマニュアルは、立入検査でこの 3 種類の施設の取組を確かめるとしています。 **立入検査で現物を見せる書類は何ですか** チェックリストのマニュアルでは、機器の台帳、事故が起きたときの連絡体制図、サイバー攻撃の想定を含む BCP、運用管理規程などの規程類です。サーバーのアクセスの記録も直接確かめることがあります。 **チェックリストに「いいえ」があるときは** マニュアルは、「いいえ」の項目に令和 8 年度中の対応の目標日を書くよう求めています。立入検査では、全項目に確認日と回答が記入されているかが確かめられます。 ## 参考資料 - [e-Gov 法令検索「医療法」(昭和 23 年法律第 205 号)第 25 条](https://laws.e-gov.go.jp/law/323AC0000000205) - [e-Gov 法令検索「医療法施行規則」(昭和 23 年厚生省令第 50 号)第 14 条](https://laws.e-gov.go.jp/law/323M40000100050) - [厚生労働省「医療法施行規則の一部を改正する省令について」(令和 5 年 3 月 10 日 産情発 0310 第 2 号)](https://www.mhlw.go.jp/content/10808000/001075881.pdf) - [厚生労働省「医療法に基づく立入検査について」(関係通知と検査結果の掲載ページ)](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iryou/i-anzen/tachiirikensa.html) - [厚生労働省「医療法第 25 条第 1 項の規定に基づく立入検査要綱の一部改正について」(令和 8 年 6 月 12 日 医政発 0612 第 9 号)](https://www.mhlw.go.jp/content/10800000/001711282.pdf) - [厚生労働省「令和 8 年度の医療法第 25 条第 1 項の規定に基づく立入検査の実施について」(令和 8 年 6 月 12 日 医政発 0612 第 10 号)](https://www.mhlw.go.jp/content/10800000/001711283.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリストマニュアル〜医療機関・薬局・事業者向け〜」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716186.pdf) - [厚生労働省 第 16 回 健康・医療・介護情報利活用検討会 医療等情報利活用ワーキンググループ 資料 2-2「医療機関の立入検査の概要」(令和 5 年 3 月 23 日)](https://www.mhlw.go.jp/content/10808000/001076927.pdf) - [厚生労働省「医療法第 25 条に基づく病院に対する立入検査結果(令和 5 年度)」](https://www.mhlw.go.jp/content/10800000/001706226.pdf) - [厚生労働省「指導大綱、監査要綱」(最終改正 令和 8 年 3 月 30 日 保発第 27 号)](https://www.mhlw.go.jp/content/001685596.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 検査の日に、共有の ID を誰が使ったかを問われると、いまはその日の勤務者を一人ずつたどって答えます。Junify を通して入る運用なら、その ID を誰が・いつ使ったかを、システムの記録とは別に一人ずつ CSV で出せます。そのためには導入時にパスワードを変えて Junify だけが持ち、スタッフは入る前に自分のスマホで本人確認をします(ブラウザーで開く診療システムの場合)。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか 区分 2 の 7 項目(権限、不要なアカウント、パスワード 2 項目、二要素認証 2 項目、アクセスの記録)です。台帳を在籍者の一覧と照らし、記録を確かめた跡を残し、事業者が「対象外」とした項目は院内の担当を決めます。 更新日: 2026-10-13 厚生労働省の「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)は 4 つの区分に分かれています。アカウントとログインに関わるのは、区分 2 の 14 項目のうち 7 項目です。どれも「はい・いいえ」で答え、確認した日を書きます。おもに使うのは、利用者 ID の台帳、アクセスの記録、事業者が書いた事業者確認用です。 ## チェックリストの位置づけ チェックリストは、厚労省の[医療情報システムの安全管理に関するガイドライン](/guides/healthcare-access/what-is-medical-information-system-security-guideline)のうち、医療機関等がまず取り組む事項をまとめたものです。令和 8 年度版で医療機関用と薬局用が 1 つになりました。医療機関・薬局が書く「医療機関・薬局確認用」と、システムを提供する事業者が書く「事業者確認用」があり、両方にある項目は同じ番号です。 チェックリストの冒頭には「立入検査時、本チェックリストを確認します」とあり、すべての項目に確認日と回答が書かれているかを見られます。「いいえ」の項目には令和 8 年度中の目標日を書き、年度中にすべてが「はい」になるよう取り組むことが求められています。検査で何を見られるかは[医療法に基づく立入検査で、サイバーセキュリティについて確認されること](/guides/healthcare-access/medical-onsite-inspection-cybersecurity)にあります。 ## アカウントとログインに関わる 7 項目 表の「項目の要点」は、チェックリストの文言を短くしたものです。 | 番号 | 項目の要点 | 確かめるときに見る物 | 事業者確認用の答え | | --- | --- | --- | --- | | 2-④ | 職種・担当業務と情報の種類ごとの権限。管理者権限を持つ人の明確化 | 利用者 ID の台帳の権限の欄 | はい・いいえ・対象外 | | 2-⑤ | 退職者や使っていないアカウントの削除・無効化 | 台帳と在籍者の一覧 | はい・いいえ・対象外 | | 2-⑦ | 英数字を混ぜた 8 桁以上(二要素認証を入れるまでは 13 桁以上) | システムのパスワードの設定 | はい・いいえ | | 2-⑧ | パスワードの使い回しの禁止 | 機器・サービスごとのパスワードの決め方 | はい・いいえ | | 2-⑪ | 端末で業務ソフトにログインするときの二要素認証 | ログインの方法と更新の計画 | はい・いいえ | | 2-⑫ | サーバー(電子カルテなどを動かすコンピューター)の OS へのログインの二要素認証 | 事業者の回答と更新の計画 | はい・いいえ | | 2-⑬ | アクセスの記録の管理 | 記録そのものと、確かめた跡 | はい・いいえ・対象外 | 「対象外」を選べるのは、医療機関の側で行っていることもある項目です。厚労省の検討会資料は不要なアカウントの削除を例に、事業者が答え方に迷い、医療機関が「事業者が守っている」と思い込むおそれがあったと説明しています。 ## 権限と不要なアカウント(2-④・2-⑤) 2-④は、職種や担当業務と情報の種類に応じて、誰がどこまで使えるかを決めているかを問います。注記では、管理者権限(設定の変更やソフトの導入ができる強い権限)を持つ人をはっきりさせることも求めています。マニュアルによると、管理者権限を最低限の人に絞るのは、攻撃を受けたときに被害が院内に広がるのを防ぐためです。 マニュアルは、利用者に付けた ID を台帳で一覧にすることを「望ましい」としています。台帳に書く項目の例は、所属部署、氏名、ユーザ ID、権限です。2-⑤は、2-④で整理した利用者と権限の一覧(台帳があればそれ)をもとに、退職者や長く使われていない ID が残っていないかを確かめ、削除か無効化をする項目です。 確かめ方の一例は、台帳の氏名を人事の在籍者の一覧と突き合わせ、在籍していない人の ID を拾い出すことです。システムで最後にログインした日が分かれば、長く使われていない ID も拾えます。台帳か、システムの利用者一覧を書き出したものがないと、2-④にも 2-⑤にも根拠を示しにくくなります。 ## パスワード(2-⑦・2-⑧) 2-⑦は、パスワードを英数字を混ぜた 8 桁以上にしているかを問います。二要素認証を入れるまでは 13 桁以上です。検討会資料によると、記号を混ぜることと定期的に変えることは、令和 8 年度版で条件から外れました。桁数の考え方は[ガイドラインが定めるパスワードの桁数・変更・使い回し](/guides/healthcare-access/password-rules-in-medical-guideline)の記事にあります。 2-⑧はパスワードの使い回しの禁止です。マニュアルは、事業者が契約先の医療機関すべてに同じパスワードを使い、攻撃を受けた事案があったと書いています。サーバーのパスワードを事業者が管理しているなら、条件を満たしているかを事業者確認用で確かめます。 ## 二要素認証(2-⑪・2-⑫) 二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです([二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification))。2-⑫の OS は、サーバーを動かす基本のソフトです。どちらも、すでに導入しているか、令和 9 年度以降の最初のシステム更新で導入する予定なら「はい」に当たります。 サーバーは、決まった端末を経由しないと入れないようにし、その端末のログインに二要素認証を入れるなどの条件を満たせば、二要素認証を入れたとみなせます。医療機器への二要素認証は、第 7.0 版への改定で見送られ、必須とはされていません。ただしマニュアルは、今後は求められる方向だとして、二要素認証に対応した医療機器を選ぶよう勧めています。 システムごとに次の更新時期と、製品が二要素認証に対応しているかを書き出しておくと、2-⑪・2-⑫に答えやすくなります。みなしの条件の全体と、共有アカウントでの扱いは[医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts)にあります。 ## アクセスの記録(2-⑬) 2-⑬はサーバーに残るアクセスの記録です。マニュアルは、少なくとも利用者のログイン時刻、アクセス時間、操作内容が分かるように記録するよう求めています。その記録は、企画管理者(安全管理の実務を担う担当者)が定期的に確かめます。記録を見られる人を限り、消したり書き換えたりされないようにすることも補足にあります。 記録が残っているだけでは、定期的に確かめていることは示せません。確かめた日と担当者を書き残しておくのが決め方の一例です。何をどこまで残すかは[医療機関のアクセスの記録(監査ログ)](/guides/healthcare-access/medical-audit-log-retention)の記事にあります。 ## 事業者確認用との突き合わせ 医療機関は、システムを提供する事業者ごとに事業者確認用を送り、回収します。事業者が「対象外」に丸を付けた項目は、医療機関の側が責任を負います。たとえば 2-⑤が「対象外」なら、退職者のアカウントを消すのは院内の仕事です。回収した事業者確認用を医療機関・薬局確認用の同じ番号と並べ、「対象外」の項目を院内の誰が行うかを決めます。 運用や保守の契約がなく製品を買っただけのシステムは、事業者確認用が要らない代わりに、セキュリティ更新などの責任を医療機関が負います。 ## 規程に書くこと(4-①) 区分 4 は、区分 1〜3 のすべての項目について、具体的なやり方を運用管理規程などに定めているかを問います。マニュアルが挙げるアカウントの例文は、次のとおりです。 > システム管理者は不正な利用の防止及び発見に向け、情報システムの利用者ごとに適切なアクセス権限を付与したアカウントを登録し、定期的に操作ログを確認する。 例文の「操作ログ」は、誰が何をしたかの記録のことです。立入検査では、規程類も現物を確かめられます。 ## 1 つの ID を複数人で使っているとき チェックリストとマニュアルは、1 つの ID を複数人で使う場合について何も書いていません。ただ、7 項目はどれも、ID が 1 人に結びついていれば答えやすい作りです。1 つの ID には 1 組の権限しか付かないので、2-④の権限は、いちばん広い権限が要る人に合わせることになります。辞めた人が出ても、残る人が使い続けるので、その ID は 2-⑤で消す対象になりません。2-⑬の記録には ID は残っても、誰が使ったかは残りません。 こうした ID は、台帳に「複数人で使用」と書き、誰がパスワードを知っているかと、人が辞めたときにパスワードを変える手順を規程に書いておくのが決め方の一例です。共有の ID がなぜ残るかは[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にあります。 ## よくある質問 **いま使うチェックリストはどの版ですか** 令和 8 年度版(令和 8 年 6 月)です。医療機関用と薬局用が 1 つになりました。厚労省のガイドライン第 7.0 版の掲載ページに、PDF、マニュアル、Excel 版が置かれています。 **二要素認証がまだでも「はい」にできますか** 2-⑪と 2-⑫は、令和 9 年度以降の最初のシステム更新で導入する予定であれば「はい」に当たります。システムごとの更新時期と、製品が対応しているかを一覧にしておくと答えやすくなります。 **利用者 ID の台帳は必ず作るものですか** マニュアルは「望ましい」としており、立入検査で現物を見る書類には挙がっていません。ただ、権限(2-④)と不要なアカウント(2-⑤)を確かめる材料になります。 **事業者が「対象外」と答えた項目はどうなりますか** その項目は医療機関の側が責任を負います。院内で誰が行うかを決め、医療機関・薬局確認用の同じ番号で「はい」にできるようにします。 **共有の ID は台帳にどう書きますか** チェックリストとマニュアルには定めがありません。決め方の一例は、台帳に「複数人で使用」と書き、誰がパスワードを知っているかと、人が辞めたときに変える手順を規程に書いておくことです。 ## 参考資料 - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年 6 月)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリストマニュアル ～医療機関・薬局・事業者向け～」(令和 8 年 6 月)](https://www.mhlw.go.jp/content/10808000/001716186.pdf) - [厚生労働省 医政局 医療情報担当参事官室「令和 8 年度版 医療機関等におけるサイバーセキュリティ対策チェックリストについて(案)」(健康・医療・介護情報利活用検討会 医療等情報利活用ワーキンググループ 第 32 回 資料 6、令和 8 年 5 月 29 日)](https://www.mhlw.go.jp/content/10808000/001705950.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ(チェックリスト・マニュアル・Excel 版の掲載先)](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 2-⑤ の点検で、共有の ID だけは退職者が出ても消せず、そのたびにパスワードを変えて残る人に伝え直すことになります。ブラウザーで開く診療システムなら、導入時にパスワードを変えて Junify だけが持つので、辞めた人はその人の割り当て(使ってよいアカウントの指定)を外すだけで入れなくなります。スタッフは自分のスマホで本人確認をしてから入り、誰が・いつ入ったかが一人ずつ残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療情報システムの安全管理に関するガイドラインが定めるパスワードの桁数・変更・使い回し 現行の第 7.0 版では、二要素認証を使うならパスワードは 8 桁以上で英数字を混ぜ、使わないなら 13 桁以上です。定期的な変更はどちらも不要で、システム間で使い回さないことは遵守事項です。 更新日: 2026-10-13 厚生労働省の「医療情報システムの安全管理に関するガイドライン」は、パスワードの桁数を二要素認証の有無で分けています。二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです([二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification))。使う場合は 8 桁以上、使わない場合は 13 桁以上で、どちらの場合も定期的な変更は不要です。現行版は令和 8 年 6 月の第 7.0 版で、パスワードの決まりは主にシステム運用編 14 章にあります。版と編の構成は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## 二要素認証の有無で変わる桁数 桁数と文字の種類は、14 章のうち 14.1.1 の考え方の節に書かれています。 > 二要素認証を採用していることを前提とした場合、パスワードの桁数は 8 桁（PIN であれば 4 桁）以上が求められる。この際、英数字の混在（大文字小文字は問わない）を求める。ただし、二要素認証を採用していない場合には 13 桁以上とすること。 同じ章の決まりと合わせて、二要素認証の有無で並べると次のとおりです。 | 項目 | 二要素認証を使う場合 | 使わない場合 | | --- | --- | --- | | 桁数 | 8 桁以上(PIN なら 4 桁以上) | 13 桁以上 | | 文字の種類 | 英数字を混ぜる(大文字小文字は問わない) | 同じと読める | | 定期的な変更 | 不要 | 不要 | | システム間の使い回し | しない | しない | | ログインの失敗が続いたとき | 一定時間ログインできなくする | 同じ | PIN は、ガイドラインの定義では「特定のデバイスにおける電子証明書等の使用のための 4-8 桁の暗証番号」です。IC カードのように、特定の機器に入った電子証明書を使うときの暗証番号を指します。診療システムのログイン画面で入れるパスワードは、8 桁か 13 桁の側です。 英数字を混ぜる条件は、8 桁の文に続けて書かれています。13 桁の文は「ただし」で桁数だけを置き換える形なので、13 桁の場合も英数字を混ぜると読めます。記号を混ぜることまでは書かれていません。 13 桁に設定できないシステムについても書かれています。仕様上できない場合は設定できる最大の桁数にし、「直近のシステムの更改、新規導入時に必ず対応すること」です。二要素認証も、新規導入や機器の入れ替えを伴う更改のときに採用する決まりです(これに相当する対応でもよい。遵守事項 ⑤)。次の更新で二要素認証に対応すれば、パスワードは 8 桁以上で足りることになります。期限の詳しい読み方は[医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts)にあります。 ## 遵守事項と考え方の節の分かれ方 14 章は、冒頭に【遵守事項】(守るべき決まり)を置き、その後に考え方の節を続けています。パスワードの決まりは両方に分かれていて、桁数と定期的な変更は考え方の節の側です。 | 決まり | 書かれている場所 | 書き方 | | --- | --- | --- | | 類推されやすい(推測されやすい)パスワードを設定できないよう制限する | 遵守事項 ⑥(1) | 設けること | | 異なるシステムの間で使い回さない | 遵守事項 ⑥(2) | 行わないこと | | パスワードを元に戻せない形で保存する | 遵守事項 ⑥(3) | 管理・運用すること | | システムの担当者にも利用者のパスワードを推定できないようにする | 遵守事項 ⑥(5) | ようにすること | | 一定回数失敗したら一定時間ログインできなくする | 遵守事項 ⑥(6) | 講じること | | 二要素認証ありなら 8 桁以上で英数字を混ぜる | 14.1.1 | 求められる | | 二要素認証なしなら 13 桁以上 | 14.1.1 | とすること | | 定期的な変更 | 14.1.1 | 不要とする | | VPN 装置(院外から院内につなぐ機器)にも二要素認証などを入れる | 14.1.1 | 望ましい | 桁数は遵守事項ではありませんが、文末は「求められる」「とすること」で、「望ましい」とされた VPN 装置の二要素認証より強い書き方です。なお、令和 8 年 9 月に公表された Q&A には、パスワードの桁数や変更を扱う問いはありません。 ## 定期的な変更が要らなくなった経緯と、変えるべきとき 第 7.0 版の策定の通知(令和 8 年 6 月 29 日)は、パスワードの決まりの改定を要点の 1 つに挙げています。使い回しの禁止とアカウントロック(失敗が続いたらログインできなくする仕組み)を書き加え、「定期的な変更」の要件は削除した、という内容です。削除の理由は「セキュリティ面の強化につながらないとされる」と書かれています。第 6.0 版をもとに院内の規程で定期的な変更を決めている施設は、その条を見直す対象になります。定期的な変更をやめる考え方そのものは、[パスワードの定期変更はもう不要か](/guides/shared-accounts/periodic-password-change)に整理しています。 変更が要らなくなったのは、決まった周期で変えることだけです。遵守事項 ⑥(4) は、漏えいのおそれがある場合に、速やかに変更を含む処置を行うよう求めています。パスワードの失念(忘れること)や、漏えいのおそれなどでシステムの担当者がパスワードを変えるときの手順もあります。担当者は本人確認をして、その方法を台帳に書き、新しいパスワードを本人以外が知り得ない方法で伝えます。付箋に書いて渡す、ほかの人に聞こえる場所で伝える、といった方法は、この条件に合わないと読めます。 ## 使い回しの範囲 遵守事項 ⑥(2) が禁じているのは、異なる医療情報システムの間での使い回しです。電子カルテと医事会計、部門システムで同じパスワードを使っていれば、この決まりに反します。14.1.1 は VPN 装置についても、使い回しや単純なパスワードによる被害が多発していると書いています。8 章の遵守事項 ⑤ も、情報機器(端末やサーバなど)のパスワードを出荷時のものから変え、14 章の要件を満たすよう求めています。機器のパスワードも、使い回さないことを含む 14 章の決まりの対象です。保守用の接続機器と院内のパソコンで同じパスワードを使っていた事案は、[管理者パスワードの使い回しでランサムウェアの被害が院内に広がった事案](/guides/incidents/reused-admin-password-ransomware)にまとめています。 ## 保守を事業者に全て任せている医療機関の場合 サーバーの保守(セキュリティ更新を含む)を事業者に全て任せている医療機関等は、読む範囲が違います。概説編と保守委託機関編の遵守事項に対応すれば、ガイドラインを遵守しているとみなされます(概説編 3.1.5)。保守委託機関編には桁数の数字はありません。代わりに、事業者が他院と共通のパスワードを使い回して被害に遭った事案に触れています。事業者が設定するパスワードがこのガイドラインに合うことを、契約書に書いて約束してもらう方法を挙げています(3 章の 2「責任分界」の解説)。 ## 複数人で使う ID に当てはめると 遵守事項 ② は、ID とパスワードを本人しか知り得ない状態に保つことを求めています。桁数や変更の決まりは、この状態の ID を前提に書かれていると読めます。1 つの ID を複数人で使っていると、13 桁にしても、辞めた人や勤務を終えた人がパスワードを知ったままになります。その場合は、人が入れ替わるたびに変えて、残る全員に伝え直すことになります。共有の ID とガイドラインの関係は[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。 ## よくある質問 **パスワードは何桁以上にすればよいですか** 二要素認証を使う場合は 8 桁以上(IC カードなどの暗証番号なら 4 桁以上)で、英数字を混ぜます。大文字と小文字の区別は問いません。二要素認証を使わない場合は 13 桁以上です。 **パスワードの定期的な変更は必要ですか** 第 7.0 版は、二要素認証の有無にかかわらず不要としています。漏えいのおそれがあるときに、速やかに変更を含む処置を行うことは遵守事項です。 **13 桁に設定できないシステムはどうしますか** 設定できる最大の桁数にしたうえで、次のシステムの更改(システムの入れ替え)か新規導入のときに必ず対応する、とされています。 **桁数の決まりは遵守事項ですか** いいえ。遵守事項は、類推されやすい(推測されやすい)パスワードの制限や使い回しの禁止などです。8 桁・13 桁の数字は 14.1.1 の考え方の節にあり、文末は「求められる」「とすること」です。 **令和 8 年の改定で何が変わりましたか** 第 7.0 版(令和 8 年 6 月)で、使い回しの禁止と、失敗が続いたらログインできなくする仕組みが書き加えられ、「定期的な変更」の要件は削除されました。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「『医療情報システムの安全管理に関するガイドライン第 7.0 版』の策定について」(令和 8 年 6 月 29 日)](https://www.mhlw.go.jp/content/10808000/001716656.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン第 7.0 版の概要及び主な改定内容」](https://www.mhlw.go.jp/content/10808000/001102596.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン Q&A」(令和 8 年 9 月)](https://www.mhlw.go.jp/content/10808000/001752355.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 診療システムの ID を複数人で使っていると、人が辞めるたびに長いパスワードを作り直し、残る全員に伝え直すことになります。Junify では、導入時にパスワードを変えて管理者が登録し、スタッフは自分のスマホで本人確認をしてクリックするだけでログインします。辞めた人が出ても、管理者がその人の割り当てを外すだけです。スタッフが 13 桁のパスワードを覚えることもありません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 薬局・介護事業所のシステム(電子薬歴・介護記録・請求ソフト)のアカウント管理 薬局も介護事業者も厚労省の医療情報ガイドラインの対象です。職員ごとの ID、業務に合う権限、辞めた人の ID の停止、使った人の記録が求められます。1 つしか届かない介護の請求用 ID は、知る人と使った記録を事業所で決めます。 更新日: 2026-10-13 薬局と介護事業所のアカウント管理で求められることは、病院や診療所と大きくは変わりません。厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、対象とする「医療機関等」に薬局と介護事業者を含めています(概説編 2.1)。どの資料にも共通して出てくるのは、職員ごとに ID を分け、職種と業務に合わせて権限を付けることです。辞めた人の ID を消すか止めること、誰が使ったかを残すことも共通しています。違いが出るのは、点検に使う資料と、事業所に 1 つしか発行されない ID の扱いです。ガイドラインの全体は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## 薬局と介護事業所に当てはまる文書 | | 薬局 | 介護事業所 | | --- | --- | --- | | 法令の根拠 | 薬機法施行規則 11 条 2 項 1 号 | 個人情報保護法の安全管理措置 | | 医療情報のガイドライン | 対象 | 対象 | | 点検に使う資料 | 医療機関・薬局向けのチェックリスト | 介護事業所向けの手引き | | 点検のしかた | 立入検査で確認される | 手引きのチェックリストで自分で確かめる | 薬局では、薬機法施行規則 11 条 2 項 1 号が、薬局の管理者に、業務に関わる「サイバーセキュリティ」を確保する措置を求めています。この条文は概説編 4.3 も引いています。厚生労働省のサイバーセキュリティ対策チェックリストは、令和 7 年度版まで医療機関用と薬局用に分かれていました。項目が同じなので、令和 8 年度版から 1 本になっています。チェックリストのマニュアルによると、薬機法に基づく立入検査では、薬局がサイバーセキュリティの取組を行っているかを確かめます。令和 8 年度中にすべての項目が「はい」になるよう取り組むことが求められています。 介護事業所には、個人情報保護委員会と厚生労働省の「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」があります。対象は、居宅サービスや介護保険施設などの事業者です。ガイダンスは、技術的安全管理措置(情報システムの側で行う対策)を 6 つ挙げています。そのうちアカウントに関わるのは、アクセス管理(ID やパスワードなどによる認証と、業務に必要な範囲だけを見られる作り)と、アクセスの記録の保存です。認証には二要素認証(パスワードに加えてもう 1 つの方法で本人を確かめる仕組み)が望ましい、と注にあります。医療情報を扱う介護関係事業者がシステムを入れるときは、医療情報のガイドラインによる、ともしています。 令和 8 年 4 月には、厚生労働省の補助事業の検討委員会がまとめた「介護事業所における情報安全管理の手引き」が厚生労働省のサイトに載りました。手引きのチェックリストは、職員から経営者まで事業所で働く全員が使うものです。端末を起動するときに、自分専用の ID とパスワードか生体認証でログインしているかを確かめる項目があります。パスワードを書いたメモや付箋を、人目につく所に置いていないかも確かめます。 ## 職員ごとの ID と権限 薬局では、チェックリストの 2-④ が職種と担当業務に応じた権限と、管理者権限を持つ人をはっきりさせることを求めています。2-⑤ は、退職者や使っていない ID の削除か無効化です。項目ごとの確かめ方は[厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts)にまとめています。 介護事業所では、手引きの解説書が同じことを求めています。職員ごとに固有のユーザー ID を付けて共有アカウントを避け、権限は職務に必要な範囲に絞り、退職者のアカウントは速やかに無効にします。解説書は「複数人で同じID・パスワードを共有することは避けてください」とも書いています。あわせて、離席時にはログアウトするよう職員に指導し、一定時間(例として 30 分)操作がなければ自動でログアウトする設定を挙げています。ログインしたままの端末を別の職員が使えば、記録には前の人の ID が残ります。 電子薬歴や介護記録ソフトで権限をどこまで細かく分けられるかは、製品ごとに違います。薬局では、チェックリストの 2-③ が、事業者から医療情報セキュリティ開示書(MDS/SDS。製品のセキュリティ機能を決まった書式で示した書類)を出してもらうことを求めています。権限をどこまで分けられるかは、この書類と事業者への問い合わせで確かめるのが一例です。 薬局では、電子処方箋の電子署名も職員ごとの ID とかかわります。厚生労働省の資料は、調剤結果への電子署名は薬剤師本人が行う必要があると答えています。リモート署名は、1 日 1 回の本人認証で署名できる方式です。署名する人が端末を移ったときのために、院内で一人ずつを見分ける識別子(職員 ID など)と認証の結果をひも付けておく必要がある、と資料は答えています。この設定はシステム事業者が行います。薬剤師を一人ずつ見分ける ID が院内になければ、このひも付けはできないと読めます。 ## 事業所に 1 つしか発行されない ID 介護保険の請求に使う電子請求受付システムの ID とパスワードは、国民健康保険団体連合会(国保連)から事業所に届きます。届くのは「電子請求登録結果に関するお知らせ」という書類です。国民健康保険中央会の手順書によると、この ID とパスワードは、ほかの国の仕組みを使い始めるときにも要ります。介護情報基盤(介護に関する情報を 1 つに集める国の仕組み)のポータル、ケアプランデータ連携システム、LIFE(科学的介護情報システム)です。 パスワードを忘れたときは、登録した「セキュリティ用メールアドレス」に、30 分だけ使える使い捨てのパスワードが届きます。手順書には、職員ごとに ID を出す手順はありません。そのため、パスワードを知っている人、このメールを受け取れる人、使った人と日時を、事業所が決めて残すことになります。手順書は、請求を代理人に任せていて事業所が ID を把握していない場合も想定しています。事業所が自分の ID を把握していなければ、誰がパスワードを知っているかも分かりません。 薬局が保険請求に使うオンライン請求システムの ID の扱いは[医事業務・レセプト業務を委託するときのアカウント](/guides/healthcare-access/outsourcing-medical-billing-accounts)に書いています。 ## 入職・退職のときに決めること 人の出入りでは、ID を作る、止める、記録で確かめる、の 3 つの手順を決めます。ガイダンスは、監督する従業者に派遣労働者も含めているので、職員ごとに ID を分ける対象には派遣の人も入ると読めます。 1 つの ID を全員で使っていると、辞めた人だけを止められません。ID を消せば残る全員も入れなくなり、パスワードを変えれば全員に伝え直すことになるためです。解説書の事例集には、訪問看護ステーションで全員が同じ ID と単純なパスワードを使い、退職した元職員が自宅から利用者の情報を見ていた例があります。 記録について、薬局のチェックリストは 2-⑬「アクセスログを管理している」を置いています。マニュアルは、少なくともログイン時刻、アクセス時間、操作内容が分かる記録を求めています。共有の ID では、記録に残る利用者が一人の職員に結びつかないので、誰の操作かを記録だけでは確かめられません。医療機関の記録の考え方は[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にまとめています。 ## よくある質問 **薬局も医療情報ガイドラインの対象ですか** はい。第 7.0 版の概説編は、対象とする医療機関等に薬局を含めています。薬機法施行規則 11 条 2 項 1 号も、薬局の管理者にサイバーセキュリティを確保する措置を求めています。 **介護事業所も医療情報ガイドラインを守るのですか** 概説編は介護事業者も対象に含めています。個人情報保護委員会と厚労省のガイダンスは、医療情報を扱う介護関係事業者がシステムを入れるときは、このガイドラインによるとしています。 **介護事業所にもチェックリストはありますか** 厚労省のサイトに載った「介護事業所における情報安全管理の手引き」にあります。端末を起動するとき自分専用の ID とパスワードか生体認証でログインしているか、などを職員と管理者が確かめます。 **介護の請求用 ID は職員ごとに分けられますか** 国保中央会の手順書では、電子請求受付システムの ID とパスワードは国保連から事業所に届きます。職員ごとに発行する手順は書かれていないので、誰が使うかは事業所が決めて残します。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリストマニュアル〜医療機関・薬局・事業者向け〜」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716186.pdf) - [個人情報保護委員会・厚生労働省「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」(令和 8 年 4 月一部改正)](https://www.ppc.go.jp/files/pdf/260401_iryoukaigo_guidance.pdf) - [厚生労働省掲載「介護事業所における情報安全管理の手引き」(令和 8 年 4 月、令和 7 年度老人保健事業推進費等補助金 調査事業)](https://www.mhlw.go.jp/content/12306000/001719620.pdf) - [厚生労働省掲載「介護事業所における情報安全管理の手引き(解説書)」(令和 8 年 3 月)](https://www.mhlw.go.jp/content/12306000/001719621.pdf) - [国民健康保険中央会「介護事業所のみなさまへ セットアップ手順書 電子請求受付システムユーザID・パスワード編」(令和 8 年 1 月版、厚生労働省掲載)](https://www.mhlw.go.jp/content/12301000/tebiki_besshi_03.pdf_safe.pdf) - [厚生労働省「電子処方箋における電子署名について【医療機関・薬局の方々へ】」(令和 8 年 8 月 1.4 版)](https://www.mhlw.go.jp/content/11120000/001242673.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 職員ごとに ID を作れず、事業所で 1 つの ID をブラウザーで使うサービスでは、人が入れ替わるたびに、パスワードを知っている人を決め直して記録します。Junify では導入時にパスワードを変えて Junify だけが持ち、職員はそれぞれのスマホで本人確認を済ませて使います。誰が・いつ使ったかは一人ずつ残り、辞めた職員は割り当て(使ってよいアカウントの指定)を外すと入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 電子カルテなどからの患者データの持ち出しを防ぎ、記録する方法 厚労省のガイドライン第 7.0 版は、持ち出す情報と方法を規程で決め、媒体と院外からのネットワーク経由の両方を想定するよう求めます。見る権限と使えるサービスを仕組みで絞り、持ち出しの承認・媒体の台帳・アクセスの記録を残して見直します。 更新日: 2026-10-13 厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、患者データの持ち出しを一律には禁じていません。持ち出してよい情報と方法を規程で決め、手順を作って管理し、持ち出しの状況を定期的に見直すことを遵守事項(守るべき決まり)にしています。個人情報保護法の面では、個人情報保護委員会と厚生労働省の「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」があります。このガイダンスも、記録機能を持つ媒体の持ち出しの禁止や、アクセス記録の保存を安全管理の例に挙げています。ガイドラインの版と編の構成は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## ガイドラインが「持ち出し」と呼ぶもの 持ち出しは USB メモリーやノートパソコンに限りません。企画管理編 8 章の遵守事項 ⑥ は、院外への持ち出しの手順を定めるときに、次の 3 つの形を想定するよう求めています。 - 医療情報を入れた媒体や情報機器で持ち出す形 - ネットワークを通じて院外へ送る形 - 院外から医療情報の保存場所にネットワークで入り、閲覧したり受信・取り込みをしたりする形 8.2.1 は、持ち出しの方針を、クラウドサービスを使った持ち出しや、テレワークに伴う持ち出しも想定した内容にするよう求めています。 そのため、画面からファイルを保存する操作(ダウンロード)は、3 つ目の形に当たると読めます。自宅や訪問先、私物の端末から、電子カルテやクラウド型のシステムを使う場合です。⑥ が扱うのは院外への持ち出しなので、院内の端末への保存は、それだけでは当たらないと読めます。ただ、院内の端末からも USB メモリーやメールで院外へ出せます。どの操作を持ち出しとして扱うかは、自院で使うシステムごとに決めておきます。 ## 規程と手順で決めること 規程を作るのは企画管理者(安全管理の実務を担う担当者)です。企画管理編 8 章の遵守事項 ⑤ は、リスク評価(何が起きうるか、どれだけ困るかを見積もること)をもとに規程を定めるよう求めています。定めるのは、持ち出しの方針、持ち出す情報、持ち出し方法、管理方法です。持ち出した媒体や機器が盗まれたりなくなったりしたときの対応も、規程に定めます(⑦)。外部からのアクセスについて、許可する人・条件・範囲など、許可を得るための手順を定めること(⑧)も遵守事項です。8.1.1 は、規程を文書にしていない小さな医療機関でも持ち出しは起こりうるとして、リスク分析をして対策を考えておくよう書いています。 手順を作るのはシステム運用担当者(システムの日々の運用を担う担当者)です。システム運用編 7 章 ① は、規程に沿って持ち出しの手順を作って管理し、その状況を定期的に企画管理者に報告するよう求めています。企画管理編 8.2.2 は、持ち出しに使える媒体や機器を限ること、持ち出すときの手続き、持ち帰ったときの確認の手続きを挙げています。システムの保守を行う事業者には、個人情報を含むデータの持ち出しを原則として禁じます(システム運用編 7 章 ②)。やむを得ない場合は、企画管理者の承認を得て認めます。 ## 仕組みで止めること 規程だけでは、手順を飛ばした持ち出しは止まりません。ガイドラインとガイダンスは、仕組みの側で取れる対策も挙げています。 見られる範囲を絞る対策は、システム運用編 14.2 にあります。情報の区分と、利用者や業務の単位ごとに利用権限を決め、付ける権限は必要最小限にするとしています。参照・更新・実行・追加のように細かく権限を分けられるシステムを選ぶと、リスクをさらに下げられるとも書いています。見る権限のない情報は、その人の操作では持ち出せません。 持ち出せる先を絞る対策は、企画管理編 8.2.3 とシステム運用編 7.1 にあります。8.2.3 が対象にするのは、持ち出しに使えるネットワークサービス(クラウドの保存サービスやファイルを送るサービスなど)です。企画管理者が承認したものに限る措置が必要だとしています。7.1 は、許可したサービス以外への接続を遮断することや、許可していないサービスの利用禁止を規則に入れることを例に挙げています。ガイダンスが挙げるのは、記録機能を持つ媒体の持ち込み・持ち出しの禁止や検査です。スマホやパソコンなど、記録機能を持つ機器の接続の制限も挙げています。 持ち出したものを読めなくする対策は、遵守事項にも入っています。システム運用編 7 章 ③ は、盗難や置き忘れに備えて、暗号化やパスワードの設定で内容を容易に読み取られないようにするよう求めています。 ## 持ち出しを記録して見直す 持ち出しにかかわる記録は 3 つあります。1 つ目は、持ち出しそのものの記録です。第 7.0 版の Q&A(企画管理編の Q26)は、持ち出しを認めるときは承認・暗号化・記録を行うよう答えています。Q27 は、持ち出してよいとした判断を、その必要性、対策をしても残るリスク、承認した人、期限とあわせて記録するよう答えています。 2 つ目は、医療情報が入った USB メモリーなどの媒体と情報機器が、いまどこにあるかの台帳です。システム運用編 7 章 ⑦ は、台帳などで管理する手順と、定期的に棚卸し(何があるか一覧にすること)をする手順を作るよう求めています。台帳は媒体と機器を管理するものなので、ネットワークを通じた持ち出しは載りません。 3 つ目はシステムのアクセスの記録です。システム運用編 17 章 ① は、少なくともログイン時刻、アクセス時間、ログイン中に操作した医療情報が分かる記録を求めています。中身は[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にまとめています。この項目に、ファイルの保存や印刷は入っていません。持ち出しとして扱うと決めた操作が記録に残るかを事業者に確かめておくのは、決め方の一例です。 見直しは、企画管理編 8 章 ⑩ が遵守事項にしています。8.2.6 は、持ち出しを最小限にするために定期的に状況を見直し、不自然な持ち出しがあれば理由を確かめるとしています。ガイダンスも、アクセス記録の保存と、不正が疑われる異常な記録がないかの定期的な確認を挙げています。システム運用編 17.1 は、記録を分析して緊急時に知らせる仕組みも求めています。 記録から人を特定できるのは、ID が人ごとに分かれているときです。1 つの ID を複数人で使っていると、記録から分かるのは ID の名前までです([電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff))。 ## 漏えいのおそれが出たとき ガイダンスは、診療録に書かれた病歴を、個人情報保護法の要配慮個人情報(扱いに特に配慮が要る情報)の例に挙げています。診療の過程で医療従事者が知った情報も、同じく例に入っています。要配慮個人情報を含む個人データの[漏えい等](/guides/incidents/what-is-data-breach)が起きたときは、人数にかかわらず報告と通知が要ります。起きたおそれがある段階でも同じです。報告先は個人情報保護委員会、通知先は患者本人です(法 26 条、規則 7 条 1 号)。高度な暗号化などの措置をしたデータは除かれ、患者本人への通知が難しいときは代わりの措置をとります。ガイダンスは例として、患者の診療情報を含む個人データを記録した USB メモリーをなくした場合を挙げています。 報告する項目には、漏えい等が起きた個人データの項目と、その本人の数が含まれます(規則 8 条)。アクセスの記録が使った職員まで分かる形で残っていれば、どの職員がどの患者の情報を開いたかから、範囲を絞れます。企画管理編 8.2.5 は、漏えいしたときの初期対応を規程の中で定めておくよう求めています。例に挙げているのは、紛失が分かったときの連絡先と対応手順です。 ## よくある質問 **患者データの持ち出しは禁止されていますか** 一律には禁じていません。持ち出す情報・方法・管理方法を規程で定め、手順を作って管理し、状況を定期的に見直すことが遵守事項です。保守を行う事業者の持ち出しは原則として禁止です。 **画面からのダウンロードも持ち出しですか** 企画管理編は、院外から医療情報の保存場所にネットワークで入り、閲覧・受信・取り込みをする場合も持ち出しとして想定するよう求めています。自宅や私物の端末で画面からファイルを保存する操作は、これに当たると読めます。 **持ち出しの承認は記録に残しますか** 第 7.0 版の Q&A は、持ち出しを認めるときは承認・暗号化・記録を行い、持ち出してよいとした判断を、必要性・残るリスク・承認者・期限とともに記録するよう答えています。 **患者 1 人分の漏えいでも報告が必要ですか** 病歴などの要配慮個人情報を含む個人データの漏えい等は、おそれの段階でも、人数にかかわらず個人情報保護委員会への報告と患者本人への通知が必要です。高度な暗号化などをしたものは除かれます。 **アクセスの記録だけで持ち出しが分かりますか** ガイドラインが記録に求める項目に、ファイルの保存や印刷は入っていません。持ち出しとして扱う操作が残るかを事業者に確かめ、媒体と機器の台帳と合わせて見直します。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [個人情報保護委員会・厚生労働省「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」(令和 8 年 4 月一部改正)](https://www.ppc.go.jp/files/pdf/260401_iryoukaigo_guidance.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 Q&A」(令和 8 年 9 月)](https://www.mhlw.go.jp/content/10808000/001752355.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 画面からの保存を規程で禁じても、止める手段がなければ、不自然な持ち出しは後から理由を聞いて確かめることになります。ブラウザーで使う診療システムなら、Junify で保存(ダウンロード)をアカウントごとに止められます。導入時にパスワードを変えて Junify だけが持つので、スタッフは Junify を通さないと入れません。アップロードは検知して管理者に知らせ、誰が・いつ使ったかも一人ずつ残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療情報システムの遠隔保守(リモートメンテナンス)で、保守事業者のアクセスをどう管理するか 管理の責任は医療機関に残ります。厚労省のガイドライン第 7.0 版は、保守要員に専用のアカウントを使わせ、遠隔保守では必ず記録を集めて作業計画書と照合することを求めます。つながる経路の一覧と契約も要ります。 更新日: 2026-10-13 保守事業者が外から医療情報システムに入る遠隔保守(リモートメンテナンス)でも、管理の責任は医療機関に残ります。厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版が医療機関に求めることは、4 つに分けられます。つながる経路、保守要員のアカウント、作業の前後の確認、契約です。ガイドラインの全体像は[医療・ヘルスケアのアカウント管理](/guides/healthcare-access)にまとめています。 ## 遠隔保守で医療機関に残る責任 第 7.0 版の Q&A(令和 8 年 9 月)は、施設の外からつなぐ場合について「テレワーク・遠隔保守ともに、医療機関等の管理責任は残ります」と答えています(企画管理編の Q&A の Q8)。管理する対象には、つなぐ端末、利用者、本人の確かめ方、通信の経路、操作の記録、保守の時間帯を挙げています。そのうえで、事業者から報告を受けて監督するよう求めています。 遠隔保守がとくに問われるのは、正規の保守の経路が攻撃にも使えるからです。システム運用編 10.2 は、遠隔保守が攻撃者にとって「正規のルートを装って侵入できる絶好の裏口」になり得ると書いています。保守のための経路と ID を手に入れた攻撃者は、正規の保守と見分けにくい形で入れます。そのためシステム運用編 7 章の遵守事項(守るべき決まり)は、外からのログインを保守作業など必要な場合に限るよう求めています(⑫)。管理されたものだけが使えるよう制御することも同じ項目にあります。委託先の保守用の機器から侵入された公表事案は、[委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案](/guides/incidents/shared-password-with-supplier)にまとめています。 ## つながっている経路を一覧にする 厚生労働省は「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)を出しています。その 2-②は、遠隔保守を使っている機器の有無を事業者に確かめたかを問う項目です。このチェックリストは立入検査で確認されます。マニュアルは、遠隔保守に使う外部接続点(外から院内につながる口)を医療機関が把握しきれていないことを、攻撃が続く大きな要因の一つに挙げています。サーバー・端末・ネットワーク機器の台帳(2-①)をもとに、どの機器に、どの事業者が、どこからつなぐかを聞いて書き足します。 経路は少ないほど管理できます。企画管理編 3.2.2 は、外部接続点が多いこと自体が管理を難しくすると書いています。VPN 装置(外から院内のネットワークにつなぐための機器)の弱点も放置されやすくなります。そこで、新しいシステムに保守用の回線が要るときは、医療機関がまとめた回線を使える事業者を選ぶなどの対策を行うよう書いています。 VPN 装置そのものの確認事項は、厚生労働省医政局医療情報担当参事官室の事務連絡(令和 8 年 3 月 19 日)が 3 つの区分で示しています。 - 保守の契約で、事業者との責任の分かれ目を明確にしているか(後の「契約で決めておくこと」で扱います) - VPN 装置がサポートの終わった製品になっていないか。終わっていれば買い替えなどを検討します - 外からの接続の制限。不要な口や管理画面を外から触れる状態にしない、業務で要るとき以外は接続を切る、ID とパスワードだけに頼らず多要素認証(2 つ以上の方法で本人を確かめること)などを検討する、の 3 つです ## 保守要員のアカウント システム運用編 10 章の遵守事項は、保守要員がサーバーに入るときは専用のアカウントを使わせるよう求めています(③)。個人情報に触れたかどうか、触れた個人情報、作業の内容も記録します。10.1 は、サーバーの OS(サーバーを動かす基本のソフト)などに出荷時から設定されている管理者 ID を使わないよう求めています。保守担当者ごとに ID を設けて、作業した人が分かるようにします。 ID と権限の付け方は、企画管理編 13 章にあります。Q&A(企画管理編)の Q25 は、保守要員の専用アカウントにも、管理者の権限は最小限の人にだけ付けるという 13 章⑤の決まりが当てはまるとしています。Q25 は、要員の離職や担当替えに合わせてすぐアカウントを消すか止められるよう、事業者に報告を義務づけることも求めています。ID の一覧と定期的な棚卸し(何があるか一覧にすること)は同じ章の⑥⑦にあり、保守要員の ID もこの一覧に入れます。 遠隔保守に固有の対策は、システム運用編の表 10-1 にリスクごとに並んでいます。表の中から選んで行う形です。認証とアクセスの管理の行には、次の 4 つが挙がっています。 - OS の[二要素認証](/guides/shared-accounts/what-is-two-step-verification) - 管理者用の ID を厳しく管理すること(「管理者共通アカウントの禁止等」) - つなげる端末や IP アドレス(ネットワーク上の住所)の限定 - 「セッション・タイム・アウト機能」(操作のない接続を一定時間で切る仕組み) ## 作業の前と後に確かめること 作業の前は申請と承認です。システム運用編 10.1 は、保守は原則として事前の申請と承認が必要だとしています。障害時や急ぎの弱点の修正では、事後の承認もあり得るとしています。Q25 は、作業の前に申請を、終わったらすぐ報告を出させるよう求めています。その書類は、医療情報システム安全管理責任者(院内で安全管理の責任を負う人)が承認する形です。 作業の後の確認は遵守事項です。システム運用編 10 章は、遠隔保守でシステムの改造や保守をしたときは、必ず「アクセスログ」(誰がいつ何をしたかの記録)を集めるよう求めています(⑤)。作業の終わりには作業計画書と照合して確かめ、すぐ企画管理者(安全管理の実務を担う担当者)に報告して確認を求めます。システム運用編の Q&A の Q19 は、保守のときに診療録を見たかどうかを、個人別のアカウントと記録で確かめるよう答えています。 同じ遵守事項には、ほかに 2 つあります。事業者がやむを得ずファイルを送るときは、送る側で無害化(ウイルスなどを取り除く処理)されているかを確かめること(⑥)。事業者が診療録を見るときは、医療機関の許可を受けること(⑦)です。記録を何年残すか、委託先とどう取り決めるかは[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にあります。 ## 契約で決めておくこと 先の事務連絡は、医療機関と事業者の思い違いから被害に遭う例が「多発しています」と書いています。医療機関は保守されていると考え、事業者は保守の対象ではないと考えていたため、VPN 装置の管理や設定が行き届かなかった例です。企画管理編 15 章の遵守事項は、必要に応じて保守の管理項目を契約や SLA(サービスの水準の取り決め)で決めることを求めています(⑧)。契約で確かめる点の例は次の 4 つです。 1. VPN 装置などの更新を誰が受け持つか。事務連絡が、更新を含む保守契約かの再確認を求めています。 2. 保守要員の交代をいつ報告するか(Q25)。 3. 遠隔保守の記録を誰が持ち、どう渡すか(システム運用編 17.1)。 4. 攻撃を受けたとき、侵入の経路を調べる記録を出してもらえるか(保守委託機関編 8 章の解説)。 ## 保守を全て委託しているときに事業者に確かめること セキュリティ更新を含むサーバーの保守を事業者に全て委託できている医療機関は、概説編と保守委託機関編に対応すれば遵守とみなされます(概説編 3.1.5)。当てはまるかは契約書や約款で確かめます。保守委託機関編の遵守項目は、「接続サービス」(外からつなぐためのサービス)の安全をどこまで事業者が守るかを確かめるよう求めています(8 ③)。事業者の対策は、事業者が出す医療情報セキュリティ開示書(MDS/SDS)で確かめます。同編の別紙の確認事項には、保守用のアカウントを作業員専用にしているか、遠隔保守のときに記録を集めているか、作業の記録を出せるかが入っています。 ## よくある質問 **保守事業者に共通の管理者 ID を使わせてよいですか** ガイドラインは、保守要員に専用のアカウントを使わせることを遵守事項にしています。出荷時の管理者 ID は使わず、保守担当者ごとに ID を設けて、作業した人が分かるようにすることも求めています。 **遠隔保守の記録は誰が確かめますか** 医療機関の側です。システム運用編 10 章は、遠隔保守では必ず記録を集め、作業の終わりに作業計画書と照合し、すぐ企画管理者に報告して確認を求めることを遵守事項にしています。 **急ぎの保守も事前の承認が要りますか** 保守は原則として事前の申請と承認が必要です。システム運用編 10.1 は障害時や急ぎの弱点の修正では事後の承認もあり得るとし、Q&A は事業者と合意したうえで事後承認にできるとしています。 **保守を全て委託している医療機関は何を確かめますか** 外からつなぐサービスの安全をどこまで事業者が守るかを確かめます。チェックリストは、遠隔保守を使う機器の有無を事業者に確かめることを項目にしています。事業者の対策は開示書(MDS/SDS)で確かめます。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 Q&A」(令和 8 年 9 月)](https://www.mhlw.go.jp/content/10808000/001752355.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716185.pdf) - [厚生労働省「医療機関・薬局におけるサイバーセキュリティ対策チェックリストマニュアル」(令和 8 年度版)](https://www.mhlw.go.jp/content/10808000/001716186.pdf) - [厚生労働省医政局医療情報担当参事官室 事務連絡「VPN 装置等のネットワーク機器におけるサイバーセキュリティ対策の徹底について(周知依頼)」(令和 8 年 3 月 19 日)](https://www.mhlw.go.jp/content/10808000/001679871.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 遠隔保守の記録が事業者の側にあると、確かめるたびに頼んで出してもらい、届くのを待つことになります。Web の管理画面で行う保守なら、導入時にパスワードを変えて Junify だけが持ち、要員は自分のスマホで本人確認してから入ります。誰が・いつ入ったかは自院の管理者がすぐ見られ、画面の操作も記録できます。担当を離れた要員は、割り当てを外せば入れません。VPN やサーバーへのログインは対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 私物端末(BYOD)から診療システムを使うときの安全管理 厚労省のガイドラインは私物端末の利用を禁じていませんが、許可の条件・利用範囲・管理方法などを規程に書いて台帳で管理し、院内の端末と同等の対策を手順にすることを求めます。管理されていない端末での利用は許可してはならないとしています。 更新日: 2026-09-18 私物端末(職員が個人で所有するパソコン、スマホ、タブレット。BYOD)から診療システムを使うことは、厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版が想定している使い方です。ただし、規程と台帳で管理し、院内の端末と同等の対策が取れるよう手順を作ることが条件です。管理されていない端末での利用は「許可してはならない」と書かれています。 ## ガイドラインのどこに書かれているか 規程と台帳のことは、企画管理編 9 章 ⑦ にあります。医療機関等が管理しない情報機器(例として BYOD が挙がっています)について、利用を許諾する条件・利用範囲・管理方法等を規程に含め、許可の状況も含めて台帳で管理することが求められます。これを受け持つのは企画管理者(安全管理の実務を担う担当者)です。 手順と設定のことは、システム運用編にあります。8 章 ⑧⑨ は、規程に基づいて手順と設定を行って企画管理者に報告すること、院内の機器と同等の対策が取れるよう手順を作ることを求めています。8.5 は、許可する場合に選択・採用する対策の例を挙げ、管理されていない端末での BYOD は許可してはならないとしています。導入時にコスト・利便性とリスクを評価することも、同じ節にあります。職員が外部から接続する場合の事前の許可、認証、ネットワーク、端末の条件は 7.2.1 です。こちらを受け持つのはシステム運用担当者です。 すべてのサーバーのセキュリティ更新の責任を事業者に委託している医療機関等は、保守委託機関編の 1 項目に同じ内容がまとまっています。 ## 規程と台帳に書くこと 企画管理編 9 章 ⑦ は、規程に「利用を許諾する条件や、利用範囲、管理方法等に関する内容」を含めるよう求めています。「**等**」が付いているので、この 3 つで足りるという書き方ではありません。9.1 は台帳の項目として、機器がどこにあるか、利用者、使っているソフトやサービスのバージョン、契約プランの状況を挙げています。 | 項目 | 決めること | 根拠 | | --- | --- | --- | | 許可の条件 | 誰の、どの端末を、どの手続きで許可するか | 7.2.1(外部から接続できる職員の事前の許可) | | 利用範囲 | どのシステムの、どの操作までを私物端末で認めるか | 14 章 ④、14.2(権限は必要最小限) | | 管理方法 | 端末に求める設定、確認の頻度、紛失時の連絡先と手順 | 8 章 ⑨(院内の機器と同等の対策) | | 台帳 | 端末、持ち主、許可日、許可の範囲、確認日 | 9 章 ⑦ | | 棚卸し | 台帳を定期的に棚卸しして、許可の状況が実態と合っているか確かめる | 9.1(台帳の棚卸し) | 実態と合わない許可が見つかったときの外し方も、あらかじめ決めておきます。 ## 端末側で取れる対策 システム運用編 8.5 は、BYOD を許可する場合に「下記に掲げるような対策を選択・採用し、十分な安全性を確保する必要がある」としています。並んでいるのは**例**で、3 つあります。 1 つ目は、管理者以外による端末の OS 設定の変更を制御することです。持ち主が基本ソフト(OS)の設定を勝手に変えられないようにします。2 つ目は、他のアプリからの影響を遮断して医療情報の取り扱いを制限し、OS レベルで管理領域を分離することです。端末の中に仕事専用の区画を作り、私用のアプリと分ける形になります。3 つ目は、運用管理規程で OS の設定変更を禁じたうえで、安全性を確認できないアプリがないことを管理者が定期的に確認することです。 同じ節は、悪意のあるソフトなどから外部の不正アクセスが起きることも想定されるとして、「管理されていない端末での BYOD は許可してはならない」としています。何をもって「管理されていない端末」とするかは、原文に定義がありません。この 3 つをどこまで取れるかが目安になります。 7.2.1 は、職員が自宅や訪問先から接続する場合の端末について、考慮すべき点を 3 つ挙げています。端末の安全対策を確かめるには知識と技能が要り、一般の職員に求めるのは難しいこと。外部からのアクセスの状況を点検・監査する負担が大きいこと。医療機関の管理が及ばない私物のパソコンは、想定と違う環境で使われうることです。そのうえで、盗聴・なりすまし防止・アクセス管理を実現した VPN(外部から院内のネットワークに安全につなぐ仕組み)などで安全性を確保するよう求めています。仮想デスクトップ(端末には院内に置いた機器の画面だけを映す仕組み)を使うなどの運用条件の設定も挙げています。 ## アカウント側で決まること 私物端末では、端末の中を医療機関が管理しきれないため、アカウントの側で守る部分が増えます。7.2.1 は、外部からのアクセスの認証は 14.1 の求めに従うとしています。ID とパスワードの秘匿も、二要素認証の期限も、私物端末で変わりません([医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts))。 私物端末で特に問われるのは、パスワードの残り方と、誰が使ったかの記録です。ブラウザーの保存機能やメモに残ったパスワードが、退職や機種変更のあとに消えたかどうかは、端末を医療機関が管理していない以上、確かめられません。ガイドラインはこの点を名指ししていませんが、7.2.1 が挙げる「管理が及ばない私物のパソコンは想定と違う環境で使われうる」という点に当たります。私物端末から使わせるアカウントを人ごとの ID にして、勤務の終了に合わせて止められる形にしておくのは、決め方の一例です。記録の側は、端末に残せないため、システム運用編 17 章が求めるアクセスの記録をシステム側で残す前提になります。共有の ID を私物端末から使うときの記録の扱いは[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にまとめています。 ## 総務省テレワークセキュリティガイドラインとの対応 厚生労働省のガイドラインが挙げる対策は、総務省の「テレワークセキュリティガイドライン 第 5 版」の方式ごとの整理と重なります。7.2.1 の仮想デスクトップは総務省の仮想デスクトップ方式に、8.5 の管理領域の分離はセキュアコンテナ方式(端末内に業務専用の区画を作る方式)に当たると読めます。総務省のガイドラインは、私物端末の可否を方式ごとに決めるよう求めています。管理者には、可能な限り多要素認証を強制すること(管理者 H-2)と、アクセスや操作の記録を取ること(管理者 J-5)を挙げています。方式ごとの整理は[総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod)にあります。 ## 選択肢 | 選択肢 | ガイドラインの位置づけ | 残る限界 | | --- | --- | --- | | 専用端末を貸与する | 7.2.1 が挙げる方法。院内の機器として台帳と手順で管理する | 端末の費用と、配布・回収の手間 | | 仮想デスクトップで院内の画面だけを映す | 7.2.1 が挙げる運用条件。端末に医療情報を残さない | 仕組みの導入と VPN の運用が要る | | 私物端末を許可しない | 管理されていない端末を許可しない、という 8.5 の原則 | 非常勤・スポット勤務の人にも院内の端末が要る | 3 つは、システムや職種ごとに使い分けられます。企画管理編 9.1 は、具体的な条件を担当者と協議して規則に含めるよう求めています。8.5 が求めるコスト・利便性とリスクの評価も、この協議で行います。 ## よくある質問 **私物のスマホやパソコンから電子カルテを見てよいですか** ガイドラインは禁じていません。許可の条件・利用範囲・管理方法などを規程に書き、台帳で管理し、院内の端末と同等の対策が取れる手順を作ることが条件です。 **「管理されていない端末」とは何ですか** 原文に定義はありません。システム運用編 8.5 は、基本ソフトの設定変更の制御、管理領域の分離、規程での禁止と定期確認を対策の例に挙げています。線引きは施設が決めます。 **私物端末を台帳に載せる項目は何ですか** 院内の機器と同じ項目(どこにあるか、利用者、ソフトやサービスのバージョン、契約プランの状況)に、許可の状況を加えます。 **私物端末でも二要素認証は要りますか** 外部からのアクセスの認証は 14.1 の求めに従います。二要素認証の対象と期限は院内の端末と同じで、私物端末だから免除される定めはありません。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify が担うのは、私物端末で問われる 2 つ、パスワードを端末に残さないことと、誰が使ったかの記録です。スタッフは自分のスマホで本人確認をしてからブラウザーの拡張機能で診療システムに入り、パスワードは渡りません。端末の規程・台帳・設定の管理は施設側で行います。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか 遵守事項は、ログイン時刻・アクセス時間・操作した医療情報が分かる記録を残して定期的に確かめ、改ざんを防ぎ、時刻を正確に保つことです。年数の定めは厚労省のガイドラインになく、2 省ガイドラインが法定保存年限以上を原則にしています。 更新日: 2026-09-18 厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、アクセスの記録(アクセスログ。誰がいつ何を使ったかの記録)について、何を残すか、どう守るか、どう確かめるかを遵守事項(守るべき決まり)にしています。**何年残すかは書いていません**。年数は、電子カルテなどを提供する事業者が守る総務省・経済産業省のガイドライン(第 2.0 版)に考え方があり、記録した医療情報の法定保存年限が目安になります。版と編の構成は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## 何を残すか システム運用編 17 章の遵守事項のうち、記録そのものに関わるのは ①②③ です(④ は監査の支援)。 ① は記録と確認です。利用者のアクセスの記録を残して定期的に確認することを求め、少なくとも「利用者のログイン時刻、アクセス時間及びログイン中に操作した医療情報」が特定できるように残すとしています。記録機能がないシステムでは、業務日誌などで操作者と操作内容を記録します。 ② は記録の保護です。記録へのアクセスを制限し、不当な削除・改ざん・追加を防ぐ対策を行います。 ③ は時刻の正確さです。記録の時刻には信頼できる情報を使い、院内で時刻をそろえて標準時刻と定期的に合わせます。 ① の 3 項目は、誰が(利用者)、いつ・どのくらい(ログイン時刻、アクセス時間)、何を(操作した医療情報)に当たります。患者ごとの閲覧まで特定できることが求められていると読めます。記録機能があることが前提で、ない場合の業務日誌は代替です。17.1 も同じ代替策を書いています。 企画管理編 5 章は、記録を 2 種類に分けています。ID の申請のように、利用の前に手続が適切に行われたことを確かめる記録と、システムが自動で残す記録です。前者は不適切な利用を防ぐため、後者は事故や不正を後から見つけるためのものです。同じ章は、記録を過大に集めると運用の負担が大きくなるとして、リスク評価を踏まえて適切な記録を選んで整備するよう求めています(5.2)。 ## 何年残すか 厚生労働省のガイドラインのシステム運用編 17 章と企画管理編 5 章には、アクセスの記録の保存年数の定めがありません。年数の考え方は、事業者向けの 2 省ガイドラインにあります。5.1.5 は、扱う医療情報に法定の保存年限がある場合、その医療情報へのアクセスを記録したログは「原則として法定保存年限以上の保存期間を設けること」としています。脚注は、ログの利用目的(過去の不正の発見)と現状のリスクを考え合わせて、5 年以上の期間を設定することなども考えられる、と書いています。保存年限が「超長期にわたる等」の特殊な場合は、医療機関等と協議して期間を決めます。 法定の保存年限は、診療録が医師法 24 条 2 項で 5 年です。病院日誌、各科診療日誌、処方せん、手術記録、看護記録、検査所見記録、エックス線写真など「診療に関する諸記録」は、医療法施行規則 20 条 10 号で 2 年です。20 条は、医療法 21 条 1 項に基づく病院の記録の定めで、診療所は対象ではありません。 診療録の閲覧・更新を記録したログは、2 省ガイドラインの原則に当てはめると、原則として 5 年以上になります。医療機関が自分で残す業務日誌や、記録機能を持つシステムの保存の設定について、厚生労働省のガイドラインは年数を定めていません。記録した医療情報の保存年限に合わせて、施設が決めることになります。 ## 誰が使ったかを残せない ID をどうするか ① の「利用者」は、ID が人ごとに発行されていれば記録から分かります。1 つの ID を複数人で使っている場合や、機器やソフトの接続のために便宜的に使う ID の場合、記録に残るのは ID の名前で、人までは分かりません。企画管理編 13.1.1 は、こうした ID にも運用規則を定めるよう求めています([電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff))。運用規則には、誰がその ID を使えるのか、使った人と日時をどこに残すのかを含めます。17 章が業務日誌を代替に挙げているのは記録の機能がないシステムなので、これは**代替ではなく**、記録を人まで戻すための取り決めです。 保守業者の作業についても同じ考え方が書かれています。システム運用編 10 章は、保守作業のためにサーバーへ入る保守要員に、専用のアカウントを使わせることを遵守事項にしています。個人情報へのアクセスの有無、アクセスした個人情報、作業内容も記録します(③)。遠隔保守で改造や保守作業が行われる場合は必ずアクセスの記録を集め、作業計画書と照合して、企画管理者(安全管理の実務を担う担当者)に報告します(⑤)。 ## 委託しているときに取り決めること システムの管理を委託している場合、記録はシステムを提供する事業者の側にあります。システム運用編 17.1 は、事業者との間で「ログの管理方法や提供等に関して、明確に取り決めを行うこと」としています。保守委託機関編 8 章は、「接続サービス」について、サービスの内容と責任の分かれ目を明確にするよう求めています。その例に挙げているのが、委託先が持つ記録の提供される内容・提供条件・提供範囲をあらかじめ確認しておくことです。サイバー攻撃を受けたときに、侵入経路と影響範囲を調べられるようにするためです。企画管理編 7 章 ⑧ は、委託先に定期的な報告を求め、その内容を経営層に報告して承認を得ることを遵守事項にしています。 取り決めで決めるのは、次の 4 点です。 - 17 章 ① の 3 項目(ログイン時刻、アクセス時間、操作した医療情報)が、事業者側の記録で特定できるか - 事業者側の保存期間が、2 省ガイドラインの原則(法定保存年限以上)に沿っているか - 医療機関が求めたときに、どの範囲の記録を、どの形式で、何日で受け取れるか - 記録へのアクセス制限と改ざん防止を、事業者側でどう行っているか ## どう確かめるか 経営管理編 4.2 は、対策を予防的措置と発見的措置に分けています。予防的措置は、許可された人以外が患者の医療情報を見られないようにする対策です。発見的措置は、事故が起きても速やかに気づいて被害を小さくする措置です。例として、医療情報へのアクセス状況についてログ監査を実施し、不審なアクセスがないかを確認することを挙げています。対策項目としては、可能な限り予防的措置を行うことが望ましい、としています。発見的措置も適宜組み合わせること、とも書いています。 確認の方法は、全ての記録を目で見ることではありません。システム運用編 17.1 は、個人情報を含む資源について、全てのアクセスの記録を集めて定期的に不正利用がないかを確かめるよう求めています。そのうえで、この確認はシステムでの監視や、運用に基づく適切なしきい値で絞り込んだ後の記録を見ることを想定している、としています。企画管理編 5.3 は、確認の周期が長すぎると不正な利用が続くリスクがあるとしています。一方で対象が多いと負担が大きくなるため、担当者と協議して対象と周期を決めます。 ## よくある質問 **アクセスの記録は何年保存すればよいですか** 厚労省のガイドラインに年数の定めはありません。事業者向けの 2 省ガイドラインは、記録した医療情報の法定保存年限以上を原則とし、診療録なら 5 年以上を設定することなども考えられるとしています。 **業務日誌で記録の代わりになりますか** 記録機能がないシステムに限り、業務日誌などで操作者と操作内容を記録する代替が認められています。記録機能があるシステムでは、その記録を残して定期的に確認します。 **共有 ID の操作は誰がしたか分かりますか** 記録に残るのは ID の名前です。共有 ID や機器の接続用の ID は運用規則を定め、使った人と日時を別に残して補います。 **電子カルテの事業者に記録を出してもらえますか** 記録の管理方法と提供を事業者と取り決めることが求められています。提供される内容、条件、範囲をあらかじめ契約や約款で確かめます。 **記録は全部を目で見る必要がありますか** 全てを目視することは想定されていません。システムの監視や、しきい値で絞り込んだ後の記録を確認し、対象と周期は担当者と協議して決めます。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 経営管理編」](https://www.mhlw.go.jp/content/10808000/001716291.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 2.0 版」(令和 7 年 3 月改定)](https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328.pdf) - [e-Gov 法令検索「医師法」(昭和 23 年法律第 201 号)第 24 条](https://laws.e-gov.go.jp/law/323AC0000000201) - [e-Gov 法令検索「医療法施行規則」(昭和 23 年厚生省令第 50 号)第 20 条](https://laws.e-gov.go.jp/law/323M40000100050) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify が担うのは、記録の「利用者」の部分です。スタッフは自分のスマホで本人確認をしてから診療システムに入るため、共有の ID でも誰が・いつ・どのシステムに入ったかが一人ひとり残り、CSV で出せます。操作した医療情報の記録はシステム側に残り、保存年数は施設が決めます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる 求められるのは、利用者ごとの識別・認証、ID とパスワードを本人しか知り得ない状態に保つこと、申請に基づく権限付与、二要素認証、ID の台帳と棚卸しです。遵守事項ごとに、施設で確かめる点を表にします。 更新日: 2026-09-18 厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、認証とアクセス管理に求めることを 2 か所にまとめています。システム運用編 14 章と企画管理編 13 章です。前者はシステム運用担当者が行う技術的な対応、後者は企画管理者(安全管理の実務を担う担当者)が作る規程と手順です。施設を点検するときは、この 2 つの章を並べて読みます。版の経緯や編の構成は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## 遵守事項の読み方 各章は冒頭に【遵守事項】を置き、その後に考え方を書いています。**遵守事項**は文末が「すること」で、施設が守る決まりです。考え方の節には「望ましい」「求められる」と書かれた項目もあり、こちらは遵守事項ではありません。たとえば VPN 装置(院外から院内につなぐ機器)の二要素認証は「望ましい」で、遵守事項とは強さが違います。 企画管理編の遵守事項には、企画管理者が自分で行うものと、担当者に指示するものがあります。規程の整備、管理権限と ID の一覧化、棚卸しと経営層への報告は、企画管理者自身の役目です。小さな診療所で一人が両方を兼ねていても、下の表はそのまま使えます。規程を決める役目と、システムに設定する役目を分けて読めば足ります。 ## システム運用編 14 章のうちアカウント管理に関わる遵守事項 | 項目 | 遵守事項の要点 | 施設で確かめること | | --- | --- | --- | | 識別・認証 | アクセスの際に利用者を識別・認証し、認証方法の手順を規則やマニュアルで文書化する | システムごとに、誰がどの方法でログインするかを書いた文書があるか | | ID とパスワードの秘匿 | ID とパスワードの組み合わせを使うなら、本人しか知り得ない状態に保つ対策をとる | パスワードを紙やチャットで配っていないか。1 つの ID を複数人で使っていないか | | IC カードなどの代替手段 | IC カードなどを使うなら、破損時に一時的にアクセスするルールを用意する | カードを忘れた日の手順が決まっているか | | 権限付与の手順 | 部署からの申請を踏まえて権限を付与し、申請部署の管理者から確認を得る手順を作る | 申請の記録が残っているか。付与後に部署の管理者が確認しているか | | 二要素認証 | 令和 9 年 4 月 1 日時点で稼働が想定されるシステムの新規導入や、機器の入替などを伴う更改の際に、二要素認証を採用するか、これに相当する対応を行う | 各システムの次の更新時期と、二要素認証に対応した製品かを一覧にしているか | | パスワードの条件 | 類推されやすいパスワードを設定できないよう制限し、システム間で使い回さず、運用担当者にも推定できないようにする | パスワードの最低条件とロックの設定が、システムごとに分かっているか | | 運用担当者による変更 | 失念や漏えいのおそれで担当者がパスワードを変えるときは、本人確認を行い、その方法を台帳に記載する | 変更の台帳があるか。口頭や付箋で新しいパスワードを渡していないか | | ID の台帳と棚卸し | ID を台帳で管理し、定期的に棚卸し(何があるか一覧にすること)をして不要なものを削除する手順を作る | 退職者や契約が終わった委託先の ID が残っていないか | 表に収めきれない条件が 3 つあります。二要素認証は、技術的な理由などで令和 9 年度までの対応が難しい場合、令和 9 年度以降の直近の次期の更新までが期限です。パスワードは、一定回数ログインに失敗したら一定時間ログインできなくします。担当者が変更したパスワードは、本人以外が知り得ない方法で本人に通知します。 考え方の節によると、認証に使う手段は、医療情報システムにアクセスする全ての職員と関係者に用意します。施設の内部で統一的に管理する必要がある、というのが考え方です(14.1.1)。この前提と共有 ID の関係は[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。パスワードの桁数は、二要素認証がある場合は 8 桁以上(PIN なら 4 桁以上)、ない場合は 13 桁以上です。いずれの場合も定期的な変更は不要とされています。 二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです([二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification))。対象と期限、共有アカウントで残る限界は[医療機関の二要素認証で求められることと、共有アカウントで起きること](/guides/healthcare-access/two-factor-authentication-with-shared-accounts)にまとめています。 ## 企画管理編 13 章のうちアカウント管理に関わる遵守事項 | 項目 | 遵守事項の要点 | 施設で確かめること | | --- | --- | --- | | 規程の整備 | リスク評価に基づいて、利用者の認証とアクセス権限に関する規程を整備し、管理する | 認証と権限の決まりが規程として文書になっているか | | 人事情報と合わせた ID 付与 | 内部の利用者が施設に所属することを前提に、人事等の情報と整合性をとって(人事の登録と合う形で)ID を付与する手順を作らせる | 人事の登録を経ない人に ID を出していないか。入職・退職の手続きと ID の発行・削除がつながっているか | | 資格・権限規程に応じた権限 | 医療従事者の資格や院内の権限規程に応じて利用権限を管理し、部署の申請を踏まえて付与して申請部署の管理者の確認を得る | 職種ごとの権限の決まりがあるか | | 外部の利用者 | 施設の外部の利用者の用途・範囲・権限をリスク評価で整理して ID を付与し、アクセス権限とアクセス状況を管理する(管理者権限は最小限の人にだけ) | 委託先や保守業者の ID が誰の名前で、どの範囲まで使えるか分かるか | | 管理権限と ID の一覧化 | 管理権限の種類とその ID、利用が認められている人を一覧にする | 管理者用アカウントの一覧があり、誰が使えるか書いてあるか | | 棚卸しと経営層への報告 | ID の棚卸しを定期的に行って不要なものを削除し、結果を経営層に報告して承認を得る | 棚卸しの結果が理事会や院長に報告されているか | 考え方の節は、利用者の種類を整理するよう求めています。内部の職員、自分の情報を見る患者などの外部関係者のほかに、管理権限を持つ ID も想定します。機器やソフトに接続するために「便宜的に利用する ID」も同じように整理し、目的に応じて運用規則を定めます(13.1.1)。利用者の登録時は対面かこれに準じる方法で本人を確かめ、職員が退職したら利用者登録からも削除します(13.1.2)。登録した ID を使うときの本人確認は、二要素認証やこれに準じた方法によること等を要します。 ## 表をどう使うか 2 つの表の「施設で確かめること」を、システムごとに埋めていきます。電子カルテ、医事会計、画像、部門システム、オンライン診療など、患者の情報を扱うシステムが対象です。埋まらない欄が、規程・手順・設定のどれが足りないかを示します。 埋まらない欄のうち、期限があるのは**二要素認証**です。システムごとの次の更新時期を書き出し、更新の計画に組み込みます。期限のない欄は、ID の台帳から手を付けるのが決め方の一例です。台帳がないと、棚卸しも権限の見直しも外部の利用者の管理も始められないためです。 ## よくある質問 **遵守事項と「望ましい」はどう違いますか** 遵守事項は各章の冒頭に【遵守事項】として置かれ、文末が「すること」の決まりです。考え方の節にある「望ましい」は推奨で、VPN 装置の二要素認証がその例です。 **小さな診療所でも 14 章の決まりは同じですか** 同じです。システム運用編 14.1.1 は、小規模な医療機関等で利用者が限られる場合でも、利用者の識別・認証の措置は同様としています。 **委託先や保守業者の ID はどう扱いますか** 企画管理編は、外部の利用者のアクセス権限とアクセス状況を管理し、用途と範囲を整理して ID を付与するよう求めています。管理者権限は最小限の人にだけ付与します。 **人事情報と ID を合わせるとは何をすることですか** 人事の登録にない人には ID を出さず、入職・退職・異動の手続きと ID の発行・削除・権限変更をつなげることです。企画管理編 13 章の遵守事項と 13.1.2 が求めています。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、診療システムの ID とパスワードを管理者が登録し、スタッフは自分のスマホで本人確認をしてクリックするだけでログインする仕組みです。パスワードはスタッフに渡らず、誰が・いつ・どのシステムに入ったかは一人ひとり残ります。退職や勤務終了のときは、管理者が割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # オンライン診療で入れ替わる医師・スタッフのアカウント管理 指針は、医療機関に多要素認証を用いるのが望ましいとし、事業者にアクセス権限の管理、退職者アカウントの削除の重点的な監視、アクセスログの保全を求めます。医師が交代する施設は、診療計画の医師名と ID の一覧を合わせます。 更新日: 2026-09-18 オンライン診療のアカウント管理で守る文書は、厚生労働省の「オンライン診療の適切な実施に関する指針」(令和 8 年 4 月改訂)です。指針は、医療機関が行う対策と、オンライン診療システムを提供する事業者が行う対策を分けて書いています。医師の ID の発行や削除の手順そのものは指針にはなく、「医療情報システムの安全管理に関するガイドライン」第 7.0 版の側に書かれています。この 2 つを、医師やスタッフが交代する施設の運用に当てはめます。 ## 指針が医療機関に求めること 指針の通信環境の節(Ⅴ 2.(5))は、まず医療機関に、システムを提供する事業者の説明を受けるよう求めています。そのうえで、十分な情報セキュリティ対策がとられていることと、責任分界点(どこまでが誰の責任か)を確かめます。アカウントに関わる項目は次のとおりです。 | 項目 | 指針の記述 | 強さ | | --- | --- | --- | | 多要素認証 | オンライン診療に用いるシステムを使用する際には、多要素認証(2 つ以上の方法で本人を確かめること)を用いるのが望ましい | 望ましい | | 医療情報システムへの影響 | 電子カルテなどの医療情報システムに影響を及ぼす可能性があるオンライン診療システムを使う際は、医療情報安全管理関連ガイドライン(厚労省と総務省・経産省の 2 本)に沿った対策を併せて行う | すること | | 医師の本人確認 | 患者がいつでも医師の本人確認と所属医療機関の確認ができるよう、必要な情報を準備する | すること | | 医師の情報の掲載 | オンライン診療システムを用いる場合は、医師の本人確認ができる情報と医療機関の問い合わせ先をシステム上に掲載する | すること | | 汎用サービスの端末 | ビデオ会議などの汎用サービスを使う場合、端末の立ち上げ時にパスワードや生体認証で操作者を確かめる | すること | | 事業者の対策の確認 | オンライン診療システムが、事業者に求められる対策を満たしていることを確かめる | すること | 医療情報システムには、電子カルテやレセプト作成用のコンピューターだけでなく、遠隔で患者の情報を閲覧・取得するコンピューターや携帯端末も含まれます。自宅から電子カルテを開いてオンライン診療をする形なら、その端末は医療情報システムの一部です。事業者の対策の節には、医療機関の医療情報管理責任者が、これを踏まえて所属する医師が行うべきセキュリティリスク対策を行う、という注記があります。多要素認証の仕組みは[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)にまとめています。 ## 指針が事業者に求めること 事業者の対策のうち、アカウントに関わるのは 3 つです。 1 つ目はアクセス権限の管理です。指針は「システムの運用保守を行う医療機関の職員や事業者、クラウドサービス事業者のアクセス権限を管理すること」を求めています。その方法として、ID・パスワードや生体認証、IC カードなどで多要素認証を行うことが望ましいとしています。あわせて「システム運用監督者は退職者アカウントの削除など管理外になりやすい要素を重点的に監視すること」と書いています。 2 つ目はアクセスログの保全です。「アクセスログの保全措置」を求め、ログの監査・監視を行うことが望ましいとしています。 3 つ目は責任分界点の説明です。「オンライン診療のセキュリティに係る責任分界点について明確に説明し、合意した範囲において責任を負うこと」としています。 「退職者アカウントの削除」は、システムの**運用保守にあたる人**のアカウントについて、事業者に監視を求める文です。診療に使う医師の ID を医療機関がどう削除するかは、指針には書かれていません。そこは厚労省のガイドラインが受け持ちます。企画管理編は、職員が退職したら利用者登録からも削除するよう求めています(13.1.2)。ID を定期的に棚卸し(何があるか一覧にすること)して不要なものを削除することも、遵守事項です(13 章)。オンライン診療システムが医療情報システムに影響を及ぼす場合、指針はこのガイドラインに沿うよう求めています。医師の ID の削除も、この決まりに従うと読めます。 ## 医師が交代する施設の運用 指針は、複数の医師が交代でオンライン診療を行うことを認めています。在宅診療で複数の医師が関与する場合などに、特定の複数医師が交代でオンライン診療を行うときは、診療計画に医師名を記載します。予定にない代診医が診療する場合は、患者の同意と十分な引継ぎが条件です。 医師の出入りが多い施設では、この診療計画の医師名が ID 管理の起点になります。決め方の一例として、診療計画に記載した医師の一覧と、オンライン診療システムと電子カルテに ID がある医師の一覧を、同じ表で管理します。一覧を突き合わせれば、ID があるのに診療計画にない医師、つまり削除の対象が見つかります。 ID の発行と削除は、人事の手続きにつなげます。企画管理編は、内部の利用者について、人事等の情報と整合性をとって(人事の登録と合う形で)ID を付与する手順を求めています(13 章)。利用者の登録時は、対面かこれに準じる方法で本人を確かめます(13.1.2)。遠隔で働く医師の場合、この本人確認をどう行うかを先に決めておく必要があります。決めていないと ID の発行が勤務の開始に間に合わず、既にある ID を借りる運用に戻りやすくなります。共有の問題は[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。 勤務のない期間の扱いも決めます。指針にもガイドラインにも、勤務のない期間に ID を止めることを求める文はありません。ただし、システム運用編 14.2 の考え方は、付与する権限を必要最小限とすることが重要だとしています。人事異動などによる担当業務の変更に合わせて、適宜見直す必要があるとも書いています。月に数回しか勤務しない医師の ID を常に有効にしておく必要があるかは、この考え方に照らして決めます。停止と再開の機能をシステムが持っているかは、事業者に確かめます。 ## よくある質問 **オンライン診療に多要素認証は必須ですか** 指針の書き方は「用いるのが望ましい」で、「すること」とは強さが違います。ただし、電子カルテなどに影響を及ぼすシステムなら、厚労省ガイドラインの二要素認証の遵守事項が併せて当てはまると読めます。 **退職した医師のアカウント削除は誰の責任ですか** 指針が事業者に求めるのは、運用保守にあたる人のアカウントの監視です。診療に使う医師の ID は医療機関が管理し、企画管理編が退職時の利用者登録からの削除と定期的な棚卸しを求めています。 **代診の医師にはどう ID を用意しますか** 指針は、予定にない代診医の診療を、患者の同意と十分な引継ぎを条件に認めています。代診の候補となる医師の ID を本人名義で事前に用意し、勤務のない期間は止めておくのが一例です。 **医師が自宅の端末で診療する場合の注意はありますか** 指針は、遠隔で患者の情報を閲覧する端末も医療情報システムに含めています。汎用サービスを使うなら、端末の立ち上げ時に操作者の認証を行うことを求めています。私物端末は企画管理編 9 章が台帳での管理を求めています。 ## 参考資料 - [厚生労働省「オンライン診療の適切な実施に関する指針」(令和 8 年 4 月改訂)](https://www.mhlw.go.jp/content/001685701.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、オンライン診療で使う診療システムの ID とパスワードを管理者が登録し、医師は自分のスマホで本人確認をしてクリックするだけでログインする仕組みです。パスワードは医師に渡らず、誰が・いつ入ったかは一人ひとり残ります。勤務のない期間は管理者が割り当てを外すだけで入れなくなり、次の勤務で戻せます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医事業務・レセプト業務を委託するときのアカウント 企画管理編 7 章の遵守事項は、委託契約の契約書に守秘・非開示を含め、委託先の就業規則等にも同じ対応を求めることです。ID は外部の利用者として、要員ごとにアクセス権限とアクセス状況を管理できる形で用意します。 更新日: 2026-09-18 医事業務やレセプト業務を委託するとき、委託先の要員は、医療機関が人的管理を行う対象です。厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版では、システムの上の「外部の利用者」にも当たります。契約には守秘・非開示を含め、ID は要員ごとにアクセス権限とアクセス状況を管理できる形で用意します。個人情報保護法 25 条の委託先の監督は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめており、ここではガイドラインの側だけを扱います。 ## 委託先の要員はガイドラインで誰に当たるか まず、**人材派遣**と**業務の委託**では、当てはまる節が違います。企画管理編 7.1 が挙げるのは、医療機関等の職員として人的管理の対象になる人です。医師や看護師のように法令上の守秘義務がある人と、「医事課職員等、業務に携わることで医療情報を取扱い、守秘義務を負う者」がここに入ります。直接雇用の職員だけでなく、派遣で働く人も対象です。人材派遣を受ける形なら、この職員管理の側の話です。 医事業務そのものを会社に委託する形は、契約の側で受けます。7 章の遵守事項(守るべき決まり)は、事務や運用を外部の事業者に委託する場合、委託契約の契約書に守秘・非開示に関する内容を含めるよう求めています(③)。その契約の際に、委託先の就業規則等にも雇用中・退職後の守秘条項と、採用時・定期の教育を含めるよう求めます(④)。なお 7.2 は、医療情報システム等を委託する場合の考え方の節です。委託先の法人だけでなく、実際にその業務にあたる者にも職員と同様の責任や守秘義務を課す必要がある、と書いています。 システムの利用者としては、13 章の遵守事項が「医療機関等の外部の利用者」のアクセス権限とアクセス状況を管理するよう求めています(⑤)。委託先の医事担当者は、この外部の利用者に当たります。 総務省・経済産業省の事業者向けガイドライン(第 2.0 版)は、対象とする事業者を 2.1 で定めています。医療情報システム等の運用・管理・保守などの契約等に基づいて、それを提供する事業者です。売買契約だけで運用・管理・保守の契約がない場合は「契約等」に含まれない、とも書いています。医事業務だけを受託する会社は、この定義に当てはまらないと読めます。2 本の関係は[3 省 2 ガイドラインとは](/guides/healthcare-access/what-is-3-ministries-2-guidelines)に書いたとおりで、医療機関が管理する対象として扱うことになります。 ## 契約と手順で決めること 医事業務の委託に関わる遵守事項を並べます。中心は企画管理編 7 章で、記録の扱いはシステム運用編 17.1 です。 | 求められること | 章・節 | 契約や手順で決めること | | --- | --- | --- | | 事務や運用を外部に委託する場合、委託契約の契約書に守秘・非開示の内容を含める | 7 章 遵守事項 | 守秘の範囲、契約終了後も続くこと、違反時の扱い | | 委託先の就業規則等に、雇用中・退職後の守秘条項と、採用時・定期の教育を含めるよう求める | 7 章 遵守事項 | 委託先の就業規則と教育の実施状況を確かめる方法 | | 委託先が契約どおりに対応していることを定期的に報告させ、結果を経営層に報告して承認を得る | 7 章 遵守事項(外部保存の項目に続けて、委託先事業者一般の形で書かれている) | 報告の頻度と項目(要員の交代、ID の発行と削除) | | 委託契約の終了時に医療情報の返却などを行うことを、あらかじめ契約で取り決める | 7 章 遵守事項(同上) | 終了時の返却・削除と、ID の削除 | | システムの管理を委託している場合、記録の管理方法や提供を事業者と取り決める | システム運用編 17.1 | 誰がいつ使ったかの記録を、どちらが持ち、どう提供するか | 委託先が医療情報を自社の拠点に持ち出して扱う形なら、外部保存の遵守事項も加わると読めます。この場合、事業者向けガイドラインの遵守を契約で定め、定期的に報告を受けることが求められます。保守に必要な情報以外を閲覧させないこと、保存場所が国内法の及ぶ範囲にあることも同じ遵守事項です(7 章)。院内の端末だけで作業する委託なら、外部保存には当たりません。契約条項の文例は[委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts)にあります。 ## ID をどう用意するか 企画管理編 13 章の遵守事項は、外部の利用者について、利用用途とアクセス範囲、アクセス権限をリスク評価に基づいて整理するよう求めています。その内容に応じて ID やアクセス権限を付与し、管理者権限は最小限の対象者にだけ付与します(⑤)。同じ遵守事項は、外部の利用者のアクセス状況を管理することも求めています。誰がどこまで使ったかを ID の単位で追えることが前提なので、ID を要員ごとに用意すれば、この単位が人と一致します。7 章の遵守事項(③④)が求める守秘義務も、要員ごとに確かめられます。 1 つの ID を委託先に渡す形では、要員が交代してもシステムの記録は変わりません。システム運用編 17 章は、ログイン時刻、アクセス時間、操作した医療情報が特定できる記録を残し、定期的に確認することを求めています。誰が操作したかは、委託先の勤務表や業務日誌と突き合わせなければ分からず、その突き合わせができるかは委託先の記録の残し方に左右されます。委託先が既に共有 ID で作業している場合の確かめ方は[委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id)にあります。 要員の交代に合わせた削除は、システム運用編 14 章の ID の台帳と棚卸し(何があるか一覧にすること)の遵守事項で受けます。委託先からの定期報告の項目に要員の交代を入れ、報告のたびに台帳と照合すれば、交代後も残った ID が見つかります。契約終了時に回収するものの一覧は[委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end)にあります。 ## レセプトのオンライン請求システムの利用者 ID 社会保険診療報酬支払基金のオンライン請求システムには、支払基金から届く「ユーザ設定情報」の ID とパスワードでログインします。「オンライン請求ユーザ ID」と「オンライン請求パスワード」という名前です(操作手順書「セットアップにあたって」令和 8 年 3 月版)。初回ログイン時にパスワードを変更し、パスワードは英字と数字が混在する 6 文字以上 16 文字以下、変更期限は 6 か月です。支払基金の Q&A は、ID とパスワードを記載した資料を「届出のあった保険医療機関等のシステム利用者あて」に送るとしています。設定を代行する業者あてには送れません。電子証明書は端末 1 台につき 1 枚です。 1 つの医療機関に複数のユーザ ID を発行できるか、委託先の要員ごとに ID を分けられるかは、取得した手順書と Q&A には書かれていません。委託先にオンライン請求を任せる場合、医療機関に届いた ID を委託先が使う形になり、誰がいつ使ったかは医療機関側で残す必要があります。パスワードは 6 か月ごとに変わるので、委託先の誰がその時点のパスワードを知っているかを、変更のたびに把握しておくことになります。 ## よくある質問 **医事の委託先は 2 省ガイドラインの対象ですか** 2 省ガイドラインは、運用・管理・保守の契約等がある事業者を対象としています。医事業務だけの受託は、この定義に当てはまらないと読めます。厚労省のガイドラインでは医療機関が管理する対象です。 **委託先の要員ごとに ID を発行する根拠は何ですか** 企画管理編 13 章が、外部の利用者のアクセス権限とアクセス状況を管理するよう求めているためです。1 つの ID では、アクセス状況も記録も人に結びつきません。 **院内の端末だけで作業する委託にも外部保存の決まりが要りますか** 外部保存の遵守事項は、医療情報を医療機関の外部に保存する場合のものです。院内の端末だけで作業し、データを持ち出さない委託なら当たりません。持ち出す形なら加わると読めます。 **オンライン請求の ID を委託先に使わせてよいですか** 支払基金の資料には、ID を委託先に使わせる可否も、複数の ID を発行できるかも書かれていません。ID とパスワードの資料は届出済みの医療機関にしか送られないので、使わせるなら医療機関側で誰が使ったかを残します。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [社会保険診療報酬支払基金・都道府県国民健康保険団体連合会「オンライン請求システム操作手順書【セットアップにあたって】ダウンロード版」(令和 8 年 3 月版)](https://www.ssk.or.jp/seikyushiharai/iryokikan/download/download_01.files/online_setup_dl.pdf) - [社会保険診療報酬支払基金「オンライン請求に関するご質問(初期設定)」](https://www.ssk.or.jp/goshitsumon/online/online_10.html) - [社会保険診療報酬支払基金「オンライン請求に関するご質問(電子証明書)」](https://www.ssk.or.jp/goshitsumon/online/online_09.html) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** 委託先のスタッフにも、自院の管理者が Junify に登録した診療システムの ID を、パスワードを渡さずに使ってもらえます。委託先の担当者ごとにスマホで本人確認をしてから使うので、誰が・いつ使ったかは自院の記録に一人ひとり残ります。要員の交代は、管理者が割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 電子カルテ・診療システムの ID を複数人で使うことの問題と現実 厚労省のガイドラインの遵守事項は、ID とパスワードを本人しか知り得ない状態に保つことです。考え方の節は、全ての職員と関係者に本人の ID 等を用意するとしています。共有 ID はどちらにも載りません。 更新日: 2026-09-18 電子カルテや診療システムの 1 つの ID を複数人で使う運用は、厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版の前提から外れます。**遵守事項**は、ID とパスワードを本人しか知り得ない状態に保つことです。考え方の節は、システムにアクセスする全ての職員と関係者に本人の ID などを用意するとしています。それでも共有が残るのは、この 2 つに載らない人や場面があるときです。共有 ID とは何かは[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)にまとめています。 ## ガイドラインは共有をどう扱っているか システム運用編 14 章は、利用者の識別・認証を遵守事項(守るべき決まり)にしています。考え方の節は、認証のために「医療情報システムへアクセスする全ての職員及び関係者に対し」ID・パスワードや IC カードなどの手段を用意するとしています。それを施設の内部で統一的に管理する必要がある、とも書いています(14.1.1)。ID とパスワードは「本人しか知り得ない、又は持ち得ない状態」に保つ必要があり、遵守事項にもそう書かれています。 「共有してはならない」という文言はありません。しかし、複数人が知っているパスワードは「本人しか知り得ない状態」ではありません。ID が人に対応していなければ、「全ての職員及び関係者に」用意したことにもなりません。共有は、禁止されているのではなく、遵守事項と考え方を合わせた前提と両立しない状態です。 企画管理編 13 章は、管理権限を持つ ID のほかに、ソフトや機器に接続するための ID も、利用者に付与される ID として想定しています。これを「便宜的に利用する ID」と呼んでいます(13.1.1)。企画管理者は利用者の種類を整理し、利用目的に応じて ID の運用規則を定めます。機器に結びつく ID のように人に分けられないものは、決めたうえで残す ID として扱われます。 ## 共有 ID が残る場面 共有が残るのは、ID を人ごとに用意する手続きに載らない人がいるとき、または ID はあっても権限や端末の都合で借りるときです。以下に挙げるのは、この 2 つから起きる形を書き出したもので、出典のある分類ではありません。どの形がどれだけあるかを示す公表資料もないので、自分の施設に当てはまるものを選ぶことになります。 ### 非常勤・スポット勤務の医師や看護師 人事の登録手続きを経ないか、手続きが勤務に間に合わないため、既にある ID を借りる形です。企画管理編は人事の情報と合わせて ID を付与するよう求めているので、個人の ID に分けるには、勤務のたびに発行・削除する手順が要ります。 ### 他部署からの応援 本人の ID はあるものの、応援先の業務の権限がないため、その部署の ID を借ります。分けるには、一時的な権限の付与と取り消しの手順が要ります。 ### 夜間・当直の共用端末 最初に入った人がログインしたまま、次の人が続けて操作します。ID は分かれていても記録は最初の人に付くため、操作者が替わるときの決まりと、自動ロックの設定が要ります。 ### 委託の医事担当 要員ごとの ID を用意しないまま、業務用の 1 つの ID を委託先に預ける形です。企画管理編は、外部の利用者のアクセス権限とアクセス状況を管理するよう求めているので、要員の交代に合わせた発行と削除の手順が要ります。 ### 機器やソフトの接続用 ID 検査機器や連携ソフトがシステムに入るための ID で、人が使うものではありません。人に分けられないため、運用規則を決めて残す ID になります。 ## 記録が個人に結びつかないと何が困るか 電子カルテでは、記録の確定に入力者と確定者の識別が求められます。システム運用編 14 章は、診療録などを登録するときに入力者と確定者の氏名などの識別情報を含めるよう求めています。記録の確定は、権限のある利用者に限ります。代行入力があった場合は「誰の代行がいつ誰によって行われたか」を都度記録します。共有 ID では、この識別情報が実際に操作した人と一致しません。カルテの記載が誰のものかを、システムの記録では示せなくなります。 アクセスの記録でも同じことが起きます。システム運用編 17 章は、アクセスの記録を残して定期的に確認することを遵守事項にしています。記録には、少なくとも利用者のログイン時刻、アクセス時間、ログイン中に操作した医療情報が特定できるように残します。確認の目的は、不正利用がないことを確かめることです(17.1)。共有 ID の記録は ID 単位でしか残らないため、疑わしい操作が見つかっても、そのとき誰が操作していたかを記録から絞れません。勤務表や業務日誌と突き合わせる作業が加わります。 パスワードの管理も難しくなります。14 章には、運用担当者がパスワードを変更する場面の決まりがあります。そのなかで、漏えいのおそれがあるときは速やかに変更を含む処置を行うよう求めています(⑥(4))。共有 ID では、知っている人が一人でも施設を離れれば、そのパスワードは本人以外が知る状態です。退職や契約終了のたびに変更して残る全員に配り直すことになり、その限界は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)にまとめています。 ## 場面ごとの選択肢 分けられるものは分け、分けられないものは誰が使ったかを残す方法を決めます。場面ごとの選択肢は次のとおりです。 - 非常勤・スポット勤務では、勤務開始前に本人の ID を発行し、勤務終了で削除または停止する手順を人事の手続きにつなぎます(企画管理編 13 章の人事情報と合わせた ID 付与、13.1.2 の退職時の削除) - 応援では、本人の ID に一時的な権限を付け、期限で外します。申請と管理者の確認は記録に残します(システム運用編 14 章の申請に基づく権限付与) - 共用端末では、操作者が替わるたびにログインし直す決まりと、一定時間で自動ロックする設定を置きます(システム運用編 14 章の識別・認証、17 章の記録) - 接続用 ID は台帳に載せ、使える機器と担当者を限定し、パスワードを知る人を最小限にします(企画管理編 13.1.1 の運用規則、システム運用編 14 章の台帳と棚卸し) 共有のまま残すときの方法の比較は[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。 17 章が業務日誌を代替として挙げているのは、アクセスの記録の機能がないシステムです。機能があるシステムでは記録は残ります。共有 ID のままにするときの記録の扱いは[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にまとめています。委託先の要員の ID は[医事業務・レセプト業務を委託するときのアカウント](/guides/healthcare-access/outsourcing-medical-billing-accounts)で扱います。分けられない共有アカウントの整理の仕方は[共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。 ## よくある質問 **共用端末でログインしたまま交代するのは共有ですか** ID は分かれていても、記録は最初にログインした人に付くので、記録の上では共有と同じ状態です。操作者が替わるたびにログインし直す決まりと、自動ロックの設定で防ぎます。 **共有 ID の記録は業務日誌で補えますか** システム運用編 17 章が業務日誌を代替に挙げているのは、記録の機能がないシステムです。機能があれば記録は残りますが、残るのはアカウント名なので、勤務表との突き合わせが要ります。 **機器の接続用 ID も人ごとに分けるのですか** 分けられません。企画管理編 13.1.1 は便宜的に利用する ID を想定し、運用規則を定めるよう求めています。台帳に載せ、パスワードを知る人と使える機器を限定します。 **共有 ID があると何がいちばん困りますか** カルテの入力者・確定者の識別と、アクセスの記録が実際の操作者と一致しないことです。不正利用の確認や原因の特定を記録だけでは行えず、勤務表との突き合わせが要ります。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、診療システムの共有 ID を管理者が登録し、スタッフは自分のスマホで本人確認をしてからクリックでログインする仕組みです。パスワードはスタッフに渡らず、共有 ID のままでも、誰が・いつ入ったかは一人ひとり Junify の記録に残ります。委託先のスタッフにも同じ手順で使ってもらえます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療機関の二要素認証で求められることと、共有アカウントで起きること 医療情報システムを新規に入れるときや入れ替えるとき、二要素認証の採用が遵守事項です。共有アカウントに付けても、コードは 1 人の端末に届き、誰が使ったかは残りません。 更新日: 2026-09-18 厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版は、二要素認証の採用を遵守事項(守るべき決まり)にしています。二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです。1 つの ID を複数人で使う共有アカウントに二要素認証を付けると、コードの届き先は 1 人の端末になり、誰が使ったかはシステムの記録に残りません。版と編の構成は[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## 遵守事項の文言 システム運用編 14 章の遵守事項 ⑤ は次の文言です。 > 令和９年度(令和 9 年 4 月 1 日時点)時点で稼働していることが想定される医療情報システムを、今後、新規導入又は機器の入替等を伴うシステム更改をするに際しては、二要素認証を採用、又はこれに相当する対応を行うこと。なお技術的な理由等により令和９年度までの対応が困難な場合には、令和９年度以降、直近の次期の医療情報システムの更新までを期限とする。 この文言は 3 つのことを決めています。対象は、令和 9 年 4 月 1 日時点で稼働していることが想定される医療情報システムです。今動いているシステムに今すぐ付け足すことではなく、新規導入か、機器の入れ替えを伴う更改のときに採用します。採用するのは二要素認証そのものでなくてもよく、「これに相当する対応」でも認められます。技術的な理由で間に合わない場合は、令和 9 年度以降、直近の次期の医療情報システムの更新までが期限です。 ⑤ の下には箇条書きが 3 行続きます。1 行目は、クライアント端末(職員が操作するパソコン)とサーバーのいずれにも二要素認証が要ることです。残る 2 行は、どこで行うかを指定しています。クライアント端末では電子カルテなどのアプリのログイン時、サーバーでは基本ソフト(OS)のログイン時です。 表 14-1 の注は、OS やミドルウェア(アプリと OS の間で動く基盤のソフト)での二要素認証も認めています。認証した情報をアプリの資格情報などと結びつけ、適切に権限を付けられる場合です。ただし、OS で 1 要素、アプリで 1 要素という分け方は認めていません。 「これに相当する対応」の例は、**サーバーの側**にあります。14.1.1 は、サーバー OS への接続を、別の区画に置いた踏み台端末(サーバーに入る前に必ず経由する専用のパソコン)からだけに限る構成を 2 通り挙げています。そのいずれか、または同等以上の措置があれば「二要素認証を実装できているものとみなす」としています。この「同等以上の措置」について、脚注は「医療法に基づく立入検査の際に同等性を検査職員に対して説明できること」を例に挙げています。 この 2 通りには、前提が 3 つあります。外部から踏み台端末にログインする人に管理者権限を与えないこと、十分な OS のセキュリティ更新、サーバー群と踏み台端末で共通のパスワードを使わないことです。原文は、これらが満たされない場合は「十分な措置とは見なされない」としています。踏み台端末を置いても、そこで使うパスワードをサーバー群と共通にしていれば、この前提を満たしません。 ## 期限と経過措置 策定の通知(令和 8 年 6 月 29 日)は、改定の要点に二要素認証の緩和措置を挙げています。「令和９年４月１日時点での対応が困難な医療機関等においては、次期システム改修での対応を許容する旨の緩和措置を設定」した、という書き方です。 経過措置は、**何もしなくてよい期間ではありません**。システム運用編 14.1.1 は、令和 9 年度までにシステム更新を行う場合は、二要素認証に対応したアプリやサービスを選ぶことを求めています。経営管理編 5.1.2 は、パスワードに別の要素を組み合わせる二要素認証を「可能な限り迅速に採用すること」を、経営層に向けて書いています。保守委託機関編は、すべてのサーバーのセキュリティ更新の責任を事業者に委託している医療機関等が読む編です。令和 9 年度までの対応が難しい場合は「令和９年度以降のシステム更新時に対応可能な事業者を選定すること」を遵守事項にしています(9 章 ④⑤)。 ## 何を組み合わせれば二要素になるか 二要素認証の「要素」は、知っているもの(パスワード)、持っているもの(スマホ、IC カード)、本人自身(指紋や顔)の 3 種類です。異なる 2 種類を組み合わせたときに二要素になります([二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification))。事業者向けの 2 省ガイドラインも、異なる 2 つ以上の要素を用いる多要素認証を可能な限り早期に採用すべきだとしています(5.1.5)。 14.1.1 の考え方は、パスワードの桁数も示しています。二要素認証を採用している場合は 8 桁以上(PIN なら 4 桁以上)で、英数字の混在(大文字小文字は問わない)を求めます。採用していない場合は 13 桁以上です。認証の強さは認証方法だけで決まるものではなく、ネットワークや端末の管理と合わせて行うものだ、とも書いています。 ## 共有アカウントに二要素認証を付けると何が起きるか 14 章 ② は、ID とパスワードを本人しか知り得ない状態に保つことを遵守事項にしています。共有アカウントは複数人が知っている状態なので、この遵守事項に載っていません。二要素認証を付け足しても、載らないことは変わりません。ガイドラインと共有 ID の関係は[電子カルテ・診療システムの ID を複数人で使うことの問題と現実](/guides/healthcare-access/sharing-ehr-accounts-among-staff)にまとめています。 そのうえで、共有のまま二要素認証を付けると、コードの届き先が 1 人の端末になります。認証アプリや SMS(携帯電話のショートメッセージ)のコードは、登録した 1 台のスマホか 1 つの電話番号にしか出ません。その端末を持つ人が不在の日は、ほかの人がログインできません。不在に備えて登録用の QR コードを全員で読み取る、バックアップコードを配るといった運用にすると、コードのもとになる秘密が端末の数だけ増えます。方式ごとの問題は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)に整理しています。 記録の側でも問題が残ります。誰が使ったかがシステムの記録に残らないためです。二要素認証は「その ID の持ち主が本人か」を確かめる仕組みで、システムの記録には ID の名前が残ります。複数人が同じ ID を使う限り、コードを誰のスマホで受けたかにかかわらず、記録上の操作者は共有 ID です。システム運用編 17 章は、アクセスの記録に「利用者のログイン時刻、アクセス時間及びログイン中に操作した医療情報」を残すことを遵守事項にしています。共有 ID では、この「利用者」を人まで絞れません。誰が使ったかは、システムの記録の外に残すことになります。 ## 選択肢 | 選択肢 | 二要素認証との関係 | 誰が使ったかの記録 | | --- | --- | --- | | 全員に本人の ID を発行し、各自の端末で二要素認証にする | ガイドラインの前提そのもの | システムの記録で足りる | | 共有 ID を残し、コードを受ける端末と保管場所を 1 つに決める | 二要素認証の形は取れる。不在の日の手順を別に決める | システムの記録では ID までしか分からない。操作者の記録は別に用意する | | 機器やソフトの接続用に便宜的に使う ID として整理する | 人がログインしない ID なら、運用規則で扱いを決める | 運用規則に従う | 共有のまま残す ID は、企画管理編 13.1.1 が求める ID の運用規則で扱います。なぜ残すのか、誰が使えるのか、記録をどう残すのかを、そこで決めます。共有アカウントの方法ごとの比較は[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。 ## システム更新の計画に入れること 始めるのは、システムごとの一覧です。システム名、動いている端末とサーバー、二要素認証に対応しているか、対応していないなら次の更新の予定はいつか、を書き出します。共有アカウントが残るなら、その一覧に、コードを受ける端末と、操作者を残す方法を添えます。 ## よくある質問 **認証アプリを全員のスマホに入れれば二要素認証になりますか** 全員が同じコードを出せるようになり、誰が使ったかは分からなくなります。ガイドラインは ID とパスワードを本人しか知り得ない状態に保つことを求めており、共有の前提自体がその外にあります。 **「これに相当する対応」には何が当たりますか** サーバーの基本ソフトについては、踏み台端末に接続を限る構成が 2 通り例示され、同等以上の措置も認められます。いずれも 3 つの前提を満たすことが条件です。クライアント端末の側に例はありません。 **経過措置の間は何もしなくてよいですか** 令和 9 年度までにシステムを更新する場合は、二要素認証に対応したものを選ぶことが求められます。経営管理編は、対応したシステムを原則として令和 9 年度時点で選定するとしています。 **共有アカウントに二要素認証を付ければ記録は残りますか** システムの記録に残るのは共有 ID の名前です。コードを誰のスマホで受けたかは残らないため、誰が使ったかはシステムの記録の外に残すことになります。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 経営管理編」](https://www.mhlw.go.jp/content/10808000/001716291.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [厚生労働省「『医療情報システムの安全管理に関するガイドライン第 7.0 版』の策定について」(令和 8 年 6 月 29 日)](https://www.mhlw.go.jp/content/10808000/001716656.pdf) - [総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 2.0 版」(令和 7 年 3 月改定)](https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify が担うのは、パスワードをスタッフに渡さないことと、誰が・いつ・どのシステムに入ったかを一人ひとり残すことです。スタッフは自分のスマホで本人確認をしてから共有の ID を使います。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 3 省 2 ガイドラインとは 3 省 2 ガイドラインとは、厚労省の医療機関等向けガイドラインと、総務省・経産省の事業者向けガイドラインを合わせた通称です。医療情報を扱う側と、そのシステムを提供する側の 2 本で 1 組です。 更新日: 2026-09-18 3 省 2 ガイドラインとは、医療情報の安全管理について 3 つの省が定めている 2 本のガイドラインを合わせた通称です。1 本目は厚生労働省の「医療情報システムの安全管理に関するガイドライン」(第 7.0 版、令和 8 年 6 月)で、医療機関等が守ります。2 本目は総務省・経済産業省の「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」(第 2.0 版、令和 7 年 3 月改定)です。こちらは、電子カルテなどのシステムやサービスを提供する事業者が守ります。 ## なぜ 3 つの省で 2 本なのか もとは 3 本でした。事業者向けガイドラインの本文によると、総務省はクラウドサービス事業者向けに、経済産業省は情報処理事業者向けに、別々のガイドラインを持っていました。本文は、厚生労働省の 1 本と合わせた 3 本を「いわゆる 3 省 3 ガイドライン」と呼んでいます。 統合の理由として、本文は環境の 3 点の変化を挙げています。事業者が総務省・経済産業省の 2 本を両方参照する負担が大きいことに加え、情報セキュリティに求められることが広がり、多様になりました。ISO/IEC の各規格などとの整合も要るようになっています。この背景から、令和 2 年 8 月に 2 本が 1 本に統合されました。 「3 省 2 ガイドライン」という語は、公的な資料に定義がありません。厚生労働省の第 7.0 版は事業者向けの 1 本を「2 省ガイドライン」と呼び、第 6.0 版の Q&A は 2 本を「3 省のガイドライン」と呼びます。オンライン診療の指針は「医療情報安全管理関連ガイドライン」という総称で 2 本を指しています。 ## 誰がどちらを守るのか 厚生労働省のガイドライン(第 7.0 版)を守るのは「医療機関等」です。病院、一般診療所、歯科診療所、助産所、薬局、訪問看護ステーション、介護事業者などが当たります。そのうち、医療情報システムの導入・運用・利用・保守・廃棄に関わる人が対象です。 総務省・経済産業省のガイドライン(第 2.0 版)を守るのは事業者の側です。医療機関等との契約等に基づいて医療情報システム等を提供する事業者が中心で、直接の契約がなくても、そのシステムに必要な資源や役務を提供する事業者も含みます。患者等の指示で医療機関等から医療情報を受け取る事業者も対象です。 事業者向けの「契約等」には運用・管理・保守の契約が含まれ、売買契約だけの場合は含まれません。第 6.0 版の Q&A は、厚生労働省のガイドラインはサービスを提供する業者ではなく、委託する医療機関等が遵守すべきものだ、と答えています。 医事業務やレセプト業務だけを受託する会社がどちらに当たるかは、事業者向けガイドラインの本文には書かれていません。厚生労働省のガイドラインの側では、企画管理編が外部の利用者のアクセス権限とアクセス状況の管理を求めています(13 章)。事務や運用の委託については、委託契約の契約書に守秘・非開示の内容を含めることを遵守事項にしています(7 章)。扱いは[医療・ヘルスケアのアカウント管理](/guides/healthcare-access)にまとめています。 ## 2 本はどうつながっているか 厚生労働省のガイドラインは、2 本と法令の基準を満たす事業者を選定するよう医療機関に求めています。契約で責任の分かれ目(責任分界)を明確にして合意すること、必要に応じて事業者向けガイドラインの遵守状況を確かめることも求めています(概説編 4.4)。医療情報を外部に保存する委託では、事業者向けガイドラインの遵守を契約で定め、定期的に報告を受けます(企画管理編 7 章)。事業者の対策状況は「サービス仕様適合開示書」(事業者が自社の対策状況を示す書類)などで確かめます。 事業者向けガイドラインの側は、医療機関等が厚生労働省のガイドラインを守れる設計になっていることを事業者が説明する義務がある、としています。多要素認証(2 つ以上の方法で本人を確かめること)を可能な限り早期に採用すべきだ、とも書いています(5.1.5)。アカウント管理について厚生労働省のガイドラインが求めることは、[医療情報システムの安全管理に関するガイドラインとは](/guides/healthcare-access/what-is-medical-information-system-security-guideline)にまとめています。 ## よくある質問 **診療所は事業者向けのガイドラインも読む必要がありますか** 診療所は対象事業者には当たりません(対象は医療情報システム等を提供する事業者です)。ただし厚労省のガイドラインは、基準を満たす事業者を選び、遵守状況を確かめるよう医療機関に求めています。 **電子カルテの事業者は厚労省のガイドラインを守る義務がありますか** 第 6.0 版の Q&A は、厚労省のガイドラインは事業者ではなく委託する医療機関等が遵守するもの、としています。事業者は 2 省のガイドラインに従い、医療機関が厚労省のガイドラインを守れる設計であることを説明します。 **3 省 2 ガイドラインは正式な名前ですか** いいえ、通称です。公的な資料にこの語の定義はありません。厚労省の資料は事業者向けの 1 本を「2 省ガイドライン」、Q&A は 2 本を「3 省のガイドライン」と呼んでいます。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「『医療情報システムの安全管理に関するガイドライン第 7.0 版』の策定について」(令和 8 年 6 月 29 日)](https://www.mhlw.go.jp/content/10808000/001716656.pdf) - [厚生労働省「『医療情報システムの安全管理に関するガイドライン 第 6.0 版』に関する Q&A」(令和 7 年 5 月)](https://www.mhlw.go.jp/content/10808000/001145860.pdf) - [総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 2.0 版」(令和 7 年 3 月改定)](https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328.pdf) - [総務省 報道資料「『医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第 2.0 版(案)』に対する意見募集の結果及び当該ガイドラインの公表」(令和 7 年 3 月 28 日)](https://www.soumu.go.jp/menu_news/s-news/01ryutsu06_02000427.html) - [厚生労働省「オンライン診療の適切な実施に関する指針」(令和 8 年 4 月改訂)](https://www.mhlw.go.jp/content/001685701.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、診療システムの ID とパスワードを管理者が登録し、スタッフは自分のスマホで本人確認をしてクリックするだけでログインする仕組みです。パスワードはスタッフに渡らず、誰が・いつ・どのシステムに入ったかが一人ひとり残ります。委託先のスタッフにも同じ手順で使ってもらえます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 医療情報システムの安全管理に関するガイドラインとは 厚労省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。現行は第 7.0 版(令和 8 年 6 月)で、経営層・企画管理者・運用担当者ごとの編に分かれ、認証や記録の遵守事項を示します。 更新日: 2026-10-14 医療情報システムの安全管理に関するガイドラインとは、厚生労働省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。平成 17 年 3 月の初版から改定を重ね、現行は第 7.0 版(令和 8 年 6 月)です。読む人の役割ごとに編が分かれています。経営管理編以降の各章は、冒頭に遵守事項(守るべき決まり)を置き、その後に考え方を書く形です。 ## 何を対象にしているか 対象は、医療機関等で医療情報システムの導入、運用、利用、保守、廃棄に関わる人です。医療機関等は、病院、一般診療所、歯科診療所、助産所、薬局、訪問看護ステーション、介護事業者などを想定しています(概説編 2.1)。医療情報システムは、患者の個人識別情報を含む情報を扱う情報システム全般で、医療情報を含まない会計・経理システムは含みません。 直接の目的は、個人情報保護法と e-文書法(書類を電子データで保存してよいと定める法律)への対応です。概説編は、医療法施行規則 14 条 2 項が病院・診療所・助産所の管理者にサイバーセキュリティを確保する措置を義務づけていることも挙げています(4.3)。事業者向けガイドラインの本文によると、このガイドラインは保険診療の点数表でも引用され、保険医療機関として守ることが求められます。 ## どんな構成か | 編 | 読む人 | 内容 | | --- | --- | --- | | 概説編 | 全読者 | 目的、対象、各編に共通する前提 | | 経営管理編 | 経営層 | 経営層として遵守・判断する事項と、担当部署に指示・管理する事項 | | 企画管理編 | 企画管理者(安全管理の実務を担う担当者) | 体制、規程、人的管理、ID と権限の規程、点検・監査 | | システム運用編 | システム運用担当者 | 機器、ソフト、ネットワーク、認証・認可、記録などの技術的な対応 | | 保守委託機関編 | 医療機関の管理者・担当者 | サーバーの保守を全て事業者に委託している医療機関等向けの対応 | 保守委託機関編は第 7.0 版で加わりました。サーバーの保守(セキュリティ更新を含む)を事業者に全て委託できている医療機関等は、概説編とこの編に対応すれば遵守しているとみなされます(概説編 3.1.5)。みなされるのは、事業者が更新の責任を負うと契約書や約款に書かれている場合だけです(保守委託機関編 図 1 の注)。 ## 認証と記録について何を求めているか アカウント管理に関わる遵守事項は、システム運用編 14 章と 17 章にあります。項目の一覧は[医療・ヘルスケアのアカウント管理](/guides/healthcare-access)の表にまとめています。14 章は、利用者の識別・認証、ID とパスワードを本人しか知り得ない状態に保つこと、申請に基づく権限付与、ID の台帳と棚卸しを求めています。二要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめる仕組みです。令和 9 年 4 月 1 日の時点で動いているはずのシステムについて、新しく入れるときや機器ごと入れ替えるときに、二要素認証を入れるか、それと同じ程度の対策をとるよう求めています。端末とサーバーの両方が対象になります(表 14-1)。 パスワードの桁数は、遵守事項ではなく 14.1.1 の考え方にあります。二要素認証がある場合は 8 桁以上、ない場合は 13 桁以上で、いずれの場合も定期的な変更は不要です。 17 章は、利用者のログイン時刻、アクセス時間、ログイン中に操作した医療情報が分かる記録を残し、定期的に確認することを遵守事項にしています。記録機能がないシステムでは、業務日誌などで操作者と操作内容を記録します。管理を委託している場合は、記録の管理方法や提供を事業者と取り決めます(17.1)。 章ごとの読み解きは[厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる](/guides/healthcare-access/mhlw-guideline-authentication-and-access-control)にまとめています。記録の残し方と年数は[医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](/guides/healthcare-access/medical-audit-log-retention)にあります。 ## よくある質問 **ガイドラインに法的な強制力はありますか** ガイドライン自体は法令ではありません。直接の目的は個人情報保護法と e-文書法への対応です。概説編は、医療法施行規則 14 条 2 項が病院・診療所・助産所の管理者に義務づけるサイバーセキュリティの措置も挙げています。 **パスワードの定期変更は必要ですか** 第 7.0 版は、いずれの場合も定期的な変更は不要としています。桁数は 14.1.1 の考え方にあり、二要素認証があれば 8 桁以上、なければ 13 桁以上です。システム間で使い回さないことは遵守事項です。 **今使っているシステムにも二要素認証が要りますか** 遵守事項は、令和 9 年 4 月 1 日時点で稼働が想定されるシステムを新しく入れる、または入れ替えるときに、採用するか相当する対応を行うことです。難しい場合は令和 9 年度以降の直近の更新までが期限です。 **アクセスの記録機能がないシステムはどうしますか** システム運用編は、記録機能があることを前提としたうえで、ない場合は業務日誌などで操作者と操作内容を記録すること、としています。管理を委託している場合は、記録の管理方法と提供を事業者と取り決めます。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版(令和 8 年 6 月)」掲載ページ](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [厚生労働省「『医療情報システムの安全管理に関するガイドライン第 7.0 版』の策定について」(令和 8 年 6 月 29 日)](https://www.mhlw.go.jp/content/10808000/001716656.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 概説編」](https://www.mhlw.go.jp/content/10808000/001716290.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 経営管理編」](https://www.mhlw.go.jp/content/10808000/001716291.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 企画管理編」](https://www.mhlw.go.jp/content/10808000/001716292.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 保守委託機関編」](https://www.mhlw.go.jp/content/10808000/001716297.pdf) - [総務省・経済産業省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 第 2.0 版」(令和 7 年 3 月改定)](https://www.meti.go.jp/policy/mono_info_service/healthcare/01gl_20250328.pdf) ## Junify の場合 **人手で続けると** 職種ごとにアカウントを分け、応援や交代のたびに発行と停止を行い、誰がいつどの情報を見たかを、ガイドラインの求める期間だけ残し続けることになります。 **Junify なら** Junify は、診療システムの ID とパスワードを管理者が登録し、スタッフは自分のスマホで本人確認をしてクリックするだけでログインする仕組みです。パスワードはスタッフに渡らず、誰が・いつ・どのシステムに入ったかが一人ひとり残ります。担当を外れたら、管理者が割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=healthcare) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](/guides/healthcare-access/clinic-saas-responsibility-split): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。 - [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](/guides/healthcare-access/medical-cyber-incident-account-response): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。 - [オンライン資格確認の端末で使うアカウントとパスワードの管理](/guides/healthcare-access/online-eligibility-verification-terminal): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。 --- # 人事・採用のアカウント管理 採用媒体や人事・給与システムの企業アカウントは、担当者・応援要員・採用代行で共有されがちです。応募者と従業員の情報は安全管理措置の対象で、使える人の限定、使った人の記録、退職時の停止が問われます。 更新日: 2026-09-18 人事・採用のアカウント管理で決めることは 3 つです。採用媒体や人事・給与システムの企業アカウントを誰に使わせるか、使った人をどう記録するか、入社・退職・応援の終了に合わせて発行と停止をどう行うかです。アカウントの先にあるのが応募者と従業員の個人情報なので、この 3 つは個人情報保護法の安全管理措置(個人データを守るために行う対策)として問われます。 ## 人事・採用で共有アカウントが残る場面 人事・採用部門のアカウントは、採用媒体や人事系サービスのように、部門の外のサービスに置かれています。会社の ID 管理サービス(Okta、Microsoft Entra ID など)とつながっているかは、サービスごとに違います。共有アカウント(1 つの ID とパスワードを複数の人が使う状態。定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account))が残るのは、次の場面です。 1 つは、採用媒体(就活サイト・求人サイト)の企業向け管理画面です。応募者の情報を見てダウンロードする企業アカウントを、担当者を人数分登録できない媒体では全員が同じ ID で使うことになります。人材紹介会社とのやり取りに使う管理画面も同じで、候補者の情報を受け取るアカウントに、窓口の担当者が不在の日は別の人が同じ ID で入ります。 採用代行(応募者対応や日程調整の外部委託)では、媒体の企業アカウントを委託先の担当者に渡す形が残ります。委託先の人数分を発行できない媒体や、委託の期間に発行が間に合わない場合です。 人事・労務・給与・勤怠システムでは、管理者権限を持つアカウントが共有されます。管理者アカウントを 1 つで運用し、複数の部門が同じパスワードで入る形です。 採用の繁忙期の応援要員も、共有が残る場面です。短期の派遣社員やアルバイト、他部署からの応援に媒体の ID を教える形で、数週間のために発行と削除の手続きを踏むより教えるほうが早いためです。 共有アカウントに共通する問題は[共有アカウントの管理](/guides/shared-accounts)にまとめています。辞めた人がパスワードを知ったまま残ること、記録がアカウント名でしか残らないこと、二段階認証のコードが 1 台のスマホにしか出ないことです。媒体ごとの権限の種類や登録できる人数は、公式ヘルプで確かめます。 ## 応募者情報と従業員情報は安全管理措置の対象 個人情報保護法は、特定の個人情報をコンピューターなどで検索できるように整理した集まりを「個人情報データベース等」と呼びます(16 条 1 項)。それを構成する個人情報が「個人データ」です(16 条 3 項)。採用媒体の応募者一覧も人事システムの従業員一覧も、氏名で検索できる集まりなので個人データに当たると読めます。23 条は、個人データの漏えい、滅失、毀損(なくしたり壊したりすること)を防ぐために必要かつ適切な措置を求めています。個人情報保護委員会のガイドライン(通則編)は、この措置に、取得しようとしている個人情報のうち個人データとして扱う予定のものを守る措置も含めています(3-4-2)。応募者が媒体に登録した情報を企業が受け取る前の段階でも、同じ管理が求められると読めます。 別添の項目のうちアカウントに直接関わるのは、アクセス制御、アクセス者の識別と認証、利用状況等の記録、取扱状況を確認する手段の 4 つです。人事・採用では、応募者情報を見られる人を採用に関わる人に限り、共有 ID なら ID の外で使う人を確かめ、誰がいつ見てダウンロードしたかを残すことになります。項目ごとの文言と、共有アカウント・退職者・委託先の 3 場面への当てはめは[個人情報保護法の安全管理措置をアカウント管理に当てはめる](/guides/compliance/appi-safety-measures-for-accounts)にあります。 従業者の範囲も確かめておきます。24 条は従業者の監督(従業者が決まりどおりに扱っているか確かめること)を求め、通則編は「従業者」に、正社員だけでなく契約社員、嘱託社員、パート社員、アルバイト社員、派遣社員も含めています。繁忙期の応援要員が派遣社員やアルバイトでも、同じ監督の対象です。採用代行に媒体のアカウントを渡す場合は、個人データの取扱いの委託に当たれば 25 条の委託先の監督の側になります。要点は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめています。 採用の場面には、職業安定法の定めも重なります。5 条の 5 は、求人者、労働者の募集を行う者、募集受託者(募集を委託された者)などに、求職者等の個人情報を業務の目的の達成に必要な範囲で扱い、適正に管理するために必要な措置を行うよう求めています。厚生労働省の指針(平成 11 年労働省告示第 141 号)の第五の二は、その措置として 4 つを挙げます。目的に応じて正確で最新に保つこと、漏えい・滅失・毀損を防ぐことが 2 つです。残りは、正当な権限を有しない者によるアクセスを防止すること(権限のない人が見られないようにすること)と、保管する必要がなくなった個人情報を破棄または削除することです。求職者等から求められれば、措置の内容を説明しなければならない、ともあります。誰が応募者情報を見られるかを答えられる状態が、ここでも前提になります。 ## 入社・退職時のアカウント管理の要点 人事・採用部門は、入社・異動・退職を最初に知る部門です。IPA の「組織における内部不正防止ガイドライン」(第 5 版)の対策 5 は、利用者 ID とアクセス権の登録・変更・削除の手続きを、人事異動に関連する人事手続きと連携させるよう求めています。異動や退職で不要になった利用者 ID とアクセス権は、ただちに削除するとしています。人事の手続きにアカウントの項目が入っていれば、情報システム部門や各サービスの管理者は、人事から届く入退社の情報を起点に動けます。 入社・応援の開始では、本人ごとの ID を発行し、必要な範囲の権限だけを付けます(内部不正防止ガイドライン 対策 7、通則編 別添)。本人ごとに分けられない共有アカウントは、使ってよい人の一覧に加えます。秘密保持の誓約書も入社時に受け取ります(対策 26、対策 23 の対策ポイント 4)。派遣社員については、派遣元に出した誓約書の写しの提出を派遣の条件にすることを対策 22 が挙げています。 異動では、前の部署で使えたアカウントと権限を見直し、要らないものを外します(対策 5)。 退職・応援の終了では、本人の ID を停止・削除して権限を外します。共有アカウントは使ってよい人の一覧から外し、パスワードを変えます。情報・機器・鍵は回収し、記録で実行状況を見えるようにします(対策 5・24、IPA 中小企業ガイドライン)。 共有アカウントでは、辞めた人がパスワードを知ったままです。本人の ID を止める代わりに、パスワードを変えて残る全員に配り直すことになります。この運用の限界は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)にまとめています。二段階認証のコードの受け取り先が辞める人のスマホなら、その変更も要ります。発行するものと止めるものの一覧は[オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding)にまとめています。 ## 管理の選択肢 方法は、本人ごとに分けるか、共有のまま使う人を管理するかで分かれます。共有のまま使う方法は 4 つあります。 | 方法 | できること | 残る限界 | 向く場面 | | --- | --- | --- | --- | | 本人ごとのアカウントを発行する | 記録が本人単位になる。退職時は本人の ID を止めるだけ | 媒体が人数分の登録と権限の種類に対応している場合に限る | 媒体が対応し、使う人の入れ替わりが少ない | | 共有のまま台帳で管理する | 道具なしで始められる。使ってよい人の一覧と使った人の申告が残る | パスワードは全員が知る。記録は自己申告。退職のたびに変更と配り直し | 使う人が数人で、繁忙期の増減が小さい | | パスワードマネージャーで共有する | 保管庫に入れ、権限のある人に自動入力させる。配り直しが減る | 媒体側の記録は共有名のまま。辞めた人が見たパスワードは変更が要る | 使う人が全員、同じパスワードマネージャーを使える | | ID 管理サービスに預けて代わりに入力させる | ID 管理サービスにログインした人に代わりに入力し、誰がいつ入ったかを記録する | 対象は ID 管理サービスにアカウントのある人。対応の有無と契約プランは公式ドキュメントで確認する | 応援要員や委託先も含めて、全員が ID 管理サービスにいる | | パスワードを見せずに使わせる仕組み(アクセス管理ツール) | 本人確認した担当者に代わりに入力し、誰が使ったかを本人単位で記録する | 対象のサービスと端末の条件は製品ごとに確認する | 短期の応援要員や委託先も使う。本人単位の記録が要る | 共有のまま使う 4 つの方法の比較は[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。方法はアカウントごとに選べます。人事システムは本人ごとに分け、採用媒体は共有のまま記録を残す、という組み合わせも成り立ちます。 ## 何から始めるか 人事・採用部門が使うアカウントの一覧を作るところから始めます。媒体・システム名、アカウント、いま使っている人(社員、派遣社員、アルバイト、委託先の担当者)、応募者や従業員の情報を含むか、二段階認証のコードの受け取り先、退職時に誰が止めるかを書き出します。通則編の別添が例示する「アクセス権を有する者」の明確化に当たります。 次に、本人ごとに分けられるものを分けます。媒体やシステムが担当者の追加と権限の種類に対応しているかを公式ヘルプで確かめ、対応していれば本人ごとの ID にします。人数分を発行できない媒体、管理者アカウントが 1 つしか作れないシステム、委託の期間に発行が間に合わない場合が、共有のまま残る分で、上の表から選びます。 最後に、入社・退職・応援の開始と終了の手続きに、アカウントの項目を入れます。内部不正防止ガイドラインは、利用者 ID や権限の削除を雇用終了直後に速やかに行うとしています(対策 24)。IPA の「中小企業の情報セキュリティ対策ガイドライン」(第 4.0 版)は、退職や任期満了時に情報や機器・ID・鍵を回収し、チェックリストや記録で実行状況を見えるようにすることを勧めています。繁忙期の応援要員は、開始日と終了日を一覧に書いておき、終了日に本人の ID を止めるか、共有アカウントを使える人から外します。 ## このテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 - [採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 - [入社・退職時のアカウント管理チェックリスト](/guides/hr-access/onboarding-offboarding-checklist): 入社時は本人ごとの ID・必要な範囲の権限・共有アカウントの利用許可・誓約書、退職時は ID の停止・共有パスワードの変更・情報と機器の回収・実行の記録です。期限の一例は、退職の翌日までです。 - [応募者情報の持ち出しを防ぐアクセス管理](/guides/hr-access/preventing-applicant-data-exfiltration): 応募者情報は個人情報保護法の安全管理措置と職業安定法 5 条の 5 の対象です。見られる人を採用に関わる人に限り、媒体からの出力・履歴書の保存先・面接官への共有・私物端末の 4 つの経路に制限と記録を置きます。 - [採用の繁忙期に増える人へ、パスワードを渡さずに媒体を使わせる方法](/guides/hr-access/seasonal-hiring-staff-without-sharing-passwords): 方法は 4 つです。媒体で本人の ID を追加する、ID 管理サービスに預ける、パスワードマネージャーで共有する、パスワードを見せずに代わりに入力する。このうち 3 つは、教えずに済みます。 - [オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding): アカウントの観点では、オンボーディングは入社・応援の開始に合わせて本人の ID と権限を発行し、共有アカウントを使える人に加えること。オフボーディングは退職・終了に合わせてそれらを止め、共有のパスワードを変えることです。 ## よくある質問 **採用媒体の企業アカウントを複数人で使うのは違法ですか** 個人情報保護法にも通則編にも、共有を禁じる記述はありません。ただ、識別と認証や利用の記録は ID が人を指さないと満たせないため、使ってよい人の一覧と、使った人を確かめる手段が要ります。 **応募者の情報も個人情報保護法の対象ですか** 氏名で検索できる応募者の一覧は個人データに当たると読めます。通則編は、取得しようとしている個人情報を守る措置も 23 条に含めています。職業安定法 5 条の 5 も、求人者に適正な管理を求めています。 **繁忙期の派遣社員やアルバイトにも同じ管理が要りますか** 要ります。通則編の従業者には派遣社員、パート社員、アルバイト社員が含まれ、24 条の監督の対象です。開始日と終了日を一覧に書き、終了日に ID を止めるか、共有アカウントを使える人から外します。 **採用代行に媒体のアカウントを渡してよいですか** 個人データの取扱いの委託に当たれば、25 条の委託先の監督が要ります。通則編は、適切な委託先の選定、契約の締結、取扱状況の把握の 3 つを挙げています。 **退職者のアカウントはいつまでに止めますか** IPA の内部不正防止ガイドラインは、不要になった利用者 ID とアクセス権をただちに削除するよう求め、雇用終了直後に速やかに行うとしています。共有アカウントは、パスワードの変更が要ります。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [職業安定法(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/322AC0000000141) - [厚生労働省「職業紹介事業者、求人者、労働者の募集を行う者、募集受託者、募集情報等提供事業を行う者、労働者供給事業者、労働者供給を受けようとする者等がその責務等に関して適切に対処するための指針」(平成 11 年労働省告示第 141 号、最終改正 令和 6 年厚生労働省告示第 318 号)](https://www.mhlw.go.jp/content/001003997.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify は、採用媒体や人事系サービスの ID とパスワードを管理者が登録し、担当者にはパスワードを渡さずに使わせる仕組みです。担当者は自分のスマホで本人確認をしてクリックするだけで入り、誰が・いつ・どのアカウントを使ったかは一人ひとり残ります。繁忙期に人が増える日も退職・異動の日も、管理者が割り当てを付け外しするだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理 Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 更新日: 2026-10-14 採用代行(RPO。採用の業務を外部の会社に任せること)や社内の複数人で Indeed の企業アカウントを使うときは、使う人を一人ずつユーザーとして追加します。1 つのログインを何人かで使うことはしません。Indeed の利用規約が、ログイン情報をほかの人と共有することを認めていないためです。追加と削除は管理者の権限を持つ人が「登録ユーザー」のページで行い、権限は任せる仕事に合わせて選びます。採用代行に何を任せ、契約で何を決めるかは[採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo)にまとめています。 ## 1 つのログインを共有しない理由 Indeed の利用規約の全ユーザー向けの部分(セクション D の 7)は、アカウントの認証情報(ログインに使う情報)の扱いを定めています。そこには「これらの情報を他者と共有することはできません」とあります。同じ箇所は、ほかの人にアカウントを使わせた場合、その人の行動も持ち主の行動として扱われる、としています。社員のログインを採用代行の担当者に教えると、規約に反するうえ、規約上は担当者の操作の結果を社員本人が負う形になります。 採用企業向けのヘルプも、1 つのメールアドレスとパスワードを共有せず、一人ひとりをユーザーとして追加するよう勧めています。追加した人には、それぞれのログイン情報が発行されます。 ログインの仕組みの面でも、共有は成り立ちにくくなっています。ヘルプによると、Indeed はパスワードでのログインを順に廃止していて、新しいアカウントはパスワードを使わない方式で作られます。メールアドレスで入る場合、ログイン用のコードはほとんどの場合、登録した電話番号に届きます。1 つのログインを何人かで使うと、その電話を持つ人がいないと、ほかの人は入れません。 ## 所有者と管理者を誰にするか 最初に、アカウントの所有者と管理者が社員になっているかを確かめます。利用規約の採用企業向けの部分(セクション B の 1)によると、会社を代表して作ったアカウントは会社に帰属します。ユーザーの権限の管理を含め、アカウントでの活動すべてに会社が責任を負う、ともあります。採用代行の会社が立ち上げを手伝ったアカウントでは、所有者が社外の人になっていることがあります。所有者は、ダッシュボード右上の企業名を押すと表示されます。表示されないときは Indeed に問い合わせます。所有者を変えたり外したりするには、Indeed への問い合わせが要ります。 ユーザーの追加と削除は、管理者が行います。ただし、ほかにも人を追加できる権限があります。「ユーザーの管理」は自分と同じかそれより低い権限まで付けられ、高度なアクセスは面接官などの採用担当者を追加できます。求人管理者(代理店)は、管理者と同等とするヘルプがあります。これらを採用代行の担当者に付けると、採用代行の会社が自分たちで人を足せます。その結果、社内の誰も知らないユーザーが増えることがあります。決め方の一例は、追加と削除を社員の管理者だけが行い、採用代行の会社には担当者の追加と交代を届け出てもらう形です。 ## 任せる仕事に合わせて役割を選ぶ 権限の付け方は、あらかじめ用意された役割から選ぶ方法と、権限を一つずつ組み合わせる方法(カスタム)の 2 通りです。ヘルプの「ユーザーとアクセス権限の概要」に載っている役割のうち、採用の仕事に関わるものを並べます。 | 役割 | 求人 | 応募者の情報 | 人の追加 | | --- | --- | --- | --- | | 管理者(代理店以外) | すべて管理できる | すべて管理できる | できる | | 高度なアクセス | 投稿、有料掲載、広告キャンペーンの管理 | 確認と連絡 | 面接官など採用担当者を追加できる | | 標準アクセス | 投稿と管理 | 確認と連絡 | 記載なし | | 制限付きアクセス | 記載なし | 特定の求人だけ確認と連絡 | 記載なし | | 求人管理者(代理店) | 求人、広告キャンペーン、請求の管理 | 見ることも扱うこともできない | 管理者と同等とするヘルプあり | 採用代行に応募者への連絡と面接の日程調整だけを、一部の求人について任せるなら、制限付きアクセスが近い役割です。社内の面接官や部門の採用責任者にも、担当する求人だけの制限付きアクセスを使えます。標準アクセスと高度なアクセスでは、求人を限らずに応募者を見られます。求人の投稿や有料掲載も任せつつ見せる応募者を絞るなら、カスタムで「求人」の権限と、応募者の「制限付き」を組み合わせます。高度なアクセスでも有料掲載はできますが、面接官などを追加でき、すべてのレポートを見られるので、任せる範囲より広くならないかを確かめます。 求人管理者(代理店)は日本だけの、代理店向けの役割です。応募者の情報は扱えませんが、請求の管理を含みます。別のヘルプは、応募者の画面を使えないほかは管理者と同等としています。採用代行に付けると人の追加や削除までできると読めるので、付けられるか、付けてよいかを Indeed に確かめます。 費用にも注意が要ります。利用規約(セクション B の 1)では、特定の役割を持つユーザーは Indeed のサービスを購入でき、その料金は会社が支払います。費用のかかる有料掲載は、高度なアクセスのほか、カスタムの「求人」の権限でもできます。「求人」の権限には、有料掲載を含まない選択肢もあります。請求書の支払いと請求先の編集は「請求」の権限です。有料掲載や支払いを任せないなら、これらを付けません。 ## 採用代行の担当者を追加するとき 追加はメールアドレスで行い、相手は Indeed のアカウントを持っている必要があります。持っていない人を追加すると、アカウントを作るよう促すメッセージが出ます。決め方の一例は、採用代行の担当者に所属する会社のメールアドレスで自分の Indeed アカウントを作ってもらい、それを追加する形です。ユーザーの一覧で、どの会社の人かを見分けられます。複数の会社を担当する人は、1 つのログインに複数の会社のアカウントがつながり、ダッシュボード右上のメニューで切り替えて使えます。 Indeed には、社員が会社の ID 管理サービス(Okta、Microsoft Entra ID など)のログインで入れる仕組みがあります。画面での名前は「シングルサインオン(SSO)」です。これを使う会社は、2 点を確かめます。1 つは、入れるメールアドレスのドメイン(@ より後ろの部分)を決める「ドメイン制限」です。有効にしているなら、採用代行の会社のドメインを承認済みに加えないと、その担当者は入れません。もう 1 つは、退職した社員のアクセス権が自動で消える仕組みです。会社のログインを持たない採用代行の担当者には当てはまらないので、その人の分は「登録ユーザー」のページで外すことになります。 ## 外すとき 外す操作は、「登録ユーザー」のページで対象の人を探し、「アクション」の列にある 3 点のアイコンから「削除する」を選ぶだけです。ヘルプによると、権限を変えたときも削除したときも、本人には通知されません。採用代行の会社には、誰を外したかを別に伝えます。 契約が終わるときは、まず所有者が社員になっているかを確かめ、社外の人なら Indeed に問い合わせて社員に移します。そのうえで採用代行の担当者を全員削除し、ユーザーの一覧をもう一度見ます。管理者、求人管理者(代理店)、高度なアクセス、「ユーザーの管理」は、人を追加できる権限です。採用代行の担当者にこれらを付けていた場合は、その人たちが足したユーザーが残っていないかを、この一覧で確かめます。 削除したユーザーが作った求人や、応募者とのやり取りの記録がどう残るかは、公式ヘルプに書かれていません。担当していた求人の引き継ぎ先を決め、必要な記録があれば、削除の前に Indeed に確かめます。Indeed 以外のアカウントも含めた回収の順番は[委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end)にあります。 ## よくある質問 **採用代行に社員の Indeed のログインを教えてよいですか** Indeed の利用規約は、ログイン情報を他者と共有できないと定めています。採用代行の担当者を一人ずつユーザーとして追加し、任せる仕事に合う役割を付けます。 **一部の求人だけを採用代行に任せられますか** 「制限付きアクセス」は、特定の求人について応募者の確認と連絡、面接の設定ができる役割です。求人の投稿も任せる場合、標準アクセスでは全求人の応募者が見えます。カスタムで「求人」の権限と応募者の「制限付き」を組み合わせます。 **採用代行の人がアカウントの所有者になっています** 所有者の変更や削除は、Indeed への問い合わせで行います。利用規約では、会社を代表して作ったアカウントは会社に帰属するので、所有者を社員に移しておきます。 **ユーザーを削除すると本人に通知されますか** 通知されません。ヘルプは、権限を変えたときも削除したときも本人には知らせないとしています。採用代行の会社には、削除したことを別に伝えます。 ## 参考資料 - [Indeed「利用規約」(セクション B「採用企業の利用規約」1、セクション D「全ユーザーの一般利用規約」7)](https://jp.indeed.com/legal) - [Indeed 採用企業ヘルプセンター「ユーザーの追加とアクセスレベルの設定」](https://jp.indeed.com/help/employers/articles/206589143) - [Indeed 採用企業ヘルプセンター「ユーザーとアクセス権限の概要」](https://jp.indeed.com/help/employers/articles/users-and-permissions-overview?hl=ja&co=JP) - [Indeed「ユーザーの追加・管理方法 - アカウント管理 -」(Indeed の使い方 採用担当向け)](https://jp.indeed.com/%E6%B1%82%E4%BA%BA%E5%BA%83%E5%91%8A/c/info/add-users) - [Indeed 採用企業ヘルプセンター「Indeed 採用企業アカウントへのログイン」](https://jp.indeed.com/help/employers/articles/209727223?hl=ja&co=JP) - [Indeed 採用企業ヘルプセンター「よくある質問：Indeed アカウントの作成」](https://jp.indeed.com/help/employers/articles/how-to-create-an-indeed-employer-account?hl=ja&co=JP) - [Indeed 採用企業ヘルプセンター「Indeed アカウント管理者の特定」](https://jp.indeed.com/help/employers/articles/find-indeed-account-admin?hl=ja&co=JP) - [Indeed 採用企業ヘルプセンター「Indeed 採用企業シングルサインオン（SSO）」](https://jp.indeed.com/help/employers/articles/indeed-employer-single-sign-on-sso-overview?hl=ja&co=JP) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Indeed は人ごとのユーザーで運用します。Junify が受け持つのは、採用代行の担当者がほかに使う、1 社に ID が 1 つしかない採用媒体などのアカウントです。導入時にパスワードを変えて Junify だけが持ち、パスワードを担当者に見せずに Junify がログインします。担当が替わるたびにパスワードを変えて配り直す作業はなくなり、担当を外れた人は割り当てを外せば入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 - [採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 --- # 採用代行(RPO)に媒体アカウントを渡すときの整理 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 更新日: 2026-10-14 採用代行(RPO)に媒体のアカウントを使わせるとき、先に決まるのは渡し方ではなく、その媒体が社外の利用を認めているかです。認めていれば、渡し方は 3 つに分かれます。媒体が用意する委託先向けの手続きを使う、委託先の担当者に自社のアカウントの ID を発行する、共有 ID を渡す、です。どの渡し方でも、委託先が応募者の情報を見る以上、個人情報保護法 25 条の委託先の監督が要ります。監督の中身は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にまとめているので、この記事は採用媒体に固有の点だけを扱います。 ## 媒体の規約と仕組みを確かめる ここで取り上げる媒体は、Indeed、doda(doda CONNECT)、Wantedly、Green、engage の 5 つです。このうち公式ヘルプや規約で社外の利用に触れているのは、Wantedly と Indeed です。Wantedly は、「Wantedly で契約を締結している法人以外の第三者」の利用を利用規約で禁止しています。「代行利用に関する覚書」を締結すれば、別の企業が会社アカウントにログインして運用できる、としています。Wantedly Partners 認定企業が運用代行を行う場合は覚書が要りません。覚書は、契約企業と代行利用企業それぞれの会社名・住所・代表者名をお問い合わせフォームで送ると、Wantedly が草案を作り、電子契約で締結します。 Indeed は、利用規約でログイン情報をほかの人と共有することを認めていません。代理店向けの役割「求人管理者(代理店)」もありますが、採用代行に付けてよいかは公式ヘルプに書かれていません。Indeed で採用代行の担当者に使わせる形は[Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo)にあります。 doda、Green、engage の公式ヘルプには、社外の利用についての記述がありません。記述がない媒体では、委託先の担当者を登録してよいかを規約と営業担当に確かめてから発行します。そもそも担当者ごとの ID を発行できない媒体では、渡すなら共有 ID になります。媒体ごとの発行の可否と権限の種類は[採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids)にあります。 ## 3 つの渡し方と 25 条の当てはめ 個人情報保護委員会のガイドライン(通則編)3-4-4 は、個人データの取扱いの委託を「契約の形態・種類を問わず」他の者に個人データの取扱いを行わせることとしています。例に挙げているのは、入力、編集、分析、出力等の処理の委託です。採用代行が応募者の情報を見て、連絡し、選考の結果を入力するなら、この委託に当たると読めます。委託元は、委託先でも 23 条と同等の安全管理措置(個人データを守るために行う対策)が行われるよう監督します。 3-4-4 は、委託する業務内容に対して必要のない個人データを提供しないようにすることは当然だ、としています。媒体のアカウントでは、権限がこの範囲を決めます。日程調整だけを任せるなら応募者情報の閲覧に絞った権限を、スカウトの送信を任せるならその機能を含む権限を付けます。共有 ID で渡す場合は、その ID に付いている権限がそのまま委託先の権限になります。 | 渡し方 | 選定で確かめること | 契約に書くこと | 取扱状況の把握 | | --- | --- | --- | --- | | 媒体の委託先向けの手続き(Wantedly の覚書) | 委託先が媒体の認定企業か。認定企業でなければ覚書を結ぶ | 覚書とは別に、使う担当者の届け出と交代時の連絡 | 会社アカウントのメンバー一覧で、委託先の誰が紐づいているかを見る | | 委託先の担当者に ID を発行する | 委託先の担当者の氏名と人数。退職・交代を届け出る体制 | 届け出た担当者以外に使わせないこと。担当者の追加・変更の事前の届け出 | 媒体のユーザー一覧と、委託先から届いた担当者名簿を突き合わせる | | 共有 ID を渡す | 委託先でパスワードを知る人の範囲を答えられるか | パスワードを知る人の氏名の届け出。退職・交代時の変更の依頼 | 委託先の作業記録と、媒体のログイン時刻を突き合わせる | 契約に書く 4 つの条項の文例は[委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](/guides/outsourcing-access/contract-clauses-for-accounts)にあります。共有 ID を渡すときに委託先へ確かめる 4 点は[委託先が「共有 ID で作業しています」と答えたときの確認事項](/guides/outsourcing-access/when-contractor-uses-shared-id)にあります。 ## 職業安定法との関係 採用の委託には、個人情報保護法とは別に職業安定法が関わります。4 条 5 項は、労働者の募集を「自ら又は他人に委託して」勧誘することと定めています。36 条は、労働者を雇用しようとする者が、被用者以外の者に報酬を与えて労働者の募集に従事させようとするときは、厚生労働大臣の許可を受けなければならない、としています。報酬を与えずに従事させようとするときは、届け出なければならない、としています。採用代行に任せる業務がこの「募集に従事」に当たるかは、任せる業務の中身で決まります。この記事はアカウントの扱いだけを扱うので、当たるかどうかは契約前に厚生労働省か都道府県労働局に確かめてください。 5 条の 5 は、求人者と募集受託者の両方に、求職者等の個人情報を業務の目的の達成に必要な範囲内で扱い、適正に管理するために必要な措置を行うよう求めています。募集受託者とは、39 条が定める、36 条により労働者の募集に従事する者です。委託先が募集受託者に当たる場合、応募者情報の管理は委託元だけの義務ではなく、委託先自身の義務でもあります。契約に書く安全管理措置は、委託先にとっても法律上の求めに沿うものになります。 ## 契約終了と担当交代のとき 契約が終わる日にすることは、渡し方ごとに違います。発行した ID は消し、共有 ID はパスワードを変えて残る人に配り直します。Wantedly は「メンバー管理」でその担当者の紐付きを解除します。覚書の終了の手続きは公式ヘルプに書かれていないので、Wantedly に確かめます。委託先の端末に残った ID とパスワードは自社の操作では消せないため、消去の報告を受けます。順番と確かめ方は[委託終了・担当交代時のアクセス回収チェックリスト](/guides/outsourcing-access/access-recovery-at-contract-end)にあります。 担当交代のときは、その人の分だけを同じ順で行います。委託先の担当者の退職や交代を委託元が自分で知る方法はないので、届け出の義務を契約に入れておきます。届け出がないまま繁忙期を越えると、辞めた人の ID が媒体に残ります。 ## よくある質問 **採用代行に媒体の ID とパスワードを教えてよいですか** 媒体の規約で決まります。Indeed は規約でログイン情報の共有を認めていません。Wantedly は契約した法人以外の利用を禁じ、覚書を結べば別の会社が使えます。応募者情報を扱わせるなら 25 条の監督も要ります。 **委託先の担当者に自社の媒体 ID を発行してもよいですか** 社外の人を登録してよいかは各媒体の規約と契約で確かめます。発行できれば、委託先の誰が登録されているかを媒体のユーザー一覧で確かめられ、終了時はその ID を消すだけです。 **採用代行に職業安定法の許可は要りますか** 36 条は、被用者以外の人に報酬を与えて募集に従事させるなら厚生労働大臣の許可、報酬なしなら届出を求めています。当たるかは任せる業務の中身で決まるので、契約前に確かめます。 **委託先の監督として何を確かめますか** 通則編 3-4-4 の 3 点です。委託先を選ぶときの確認、契約に書くこと、契約後の取扱状況の把握です。アカウントでは、使う担当者の一覧、権限の範囲、記録の残り方を確かめます。 **契約が終わったら何をしますか** 発行した ID を消し、共有 ID ならパスワードを変え、委託先の端末に残った ID とパスワードの消去を確かめます。Wantedly は紐付きを解除します。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [職業安定法(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/322AC0000000141) - [Wantedly ヘルプ「会社アカウントを自社の社員以外が運用することについて」](https://help.wantedly.com/hc/ja/articles/9472775818521) - [Wantedly ヘルプ「代行利用に関する覚書を結びたい」](https://help.wantedly.com/hc/ja/articles/9472713360921) - [Wantedly ヘルプ「メンバーと会社アカウントの紐付きを解除したい」](https://help.wantedly.com/hc/ja/articles/8788920882073) - [Indeed「ユーザーの追加・管理方法 - アカウント管理 -」(Indeed の使い方 採用担当向け)](https://jp.indeed.com/%E6%B1%82%E4%BA%BA%E5%BA%83%E5%91%8A/c/info/add-users) - [Indeed「利用規約」(セクション D「全ユーザーの一般利用規約」7)](https://jp.indeed.com/legal) - [Indeed 採用企業ヘルプセンター「ユーザーとアクセス権限の概要」](https://jp.indeed.com/help/employers/articles/users-and-permissions-overview?hl=ja&co=JP) - [パーソルキャリア「doda CONNECT ご利用マニュアル【人材紹介サービス向け】」(2026 年 4 月版)](https://assist.doda.jp/DodaAssistR/Help/manual/manual_intro_ALL.pdf) - [Green サポート「アカウントの管理者・利用者を増やすことは可能ですか?」](https://support.green-japan.com/hc/ja/articles/47372591632409) - [engage サポートセンター「管理画面を複数名で閲覧したいがどうしたらいいか」](https://support.en-gage.net/hc/ja/articles/7556749613465) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify は、委託先の担当者にパスワードを渡さずに自社のアカウントを使わせる部分を担います。担当者は自分のスマホで本人確認をしてから使うので、誰が・いつ・どのアカウントを使ったかは一人ひとり残ります。契約が終わる日は、その担当者の割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 - [採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 --- # 人事システム・給与システムの共有 ID の問題 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 更新日: 2026-09-18 人事システムや給与システムには、給与・マイナンバー・評価の情報があります。管理者アカウント(強い権限を持つ ID)を複数の人で共有すると、その情報を誰が見て、誰が変えたかを ID から示せなくなります。個人情報保護法の安全管理措置(個人データを守るために行う対策)、番号法(マイナンバー法)の安全管理措置、上場企業の内部統制の 3 つが、それぞれ別の言い方で同じことを問います。 ## 管理者アカウントが共有される場面 人事・給与のシステムで管理者アカウントが共有されるのは、たとえば次の場面です。管理者アカウントが 1 つで、人事と情報システム部門が同じパスワードで入る。給与計算を社会保険労務士や給与計算の委託先に任せていて、委託先の担当者にも同じ ID を渡している。年末調整や入社の繁忙期に、応援の担当者へ管理者の ID を教える。管理者アカウントは全従業員の情報を見られ、権限の設定そのものを変えられる ID なので、共有の影響は一般の担当者アカウントより広くなります。 ## 個人情報保護法で問われること 従業員の情報は、氏名で検索できる集まりなので個人データに当たると読めます。個人情報保護委員会のガイドライン(通則編)の別添が求める措置のうち、管理者アカウントの共有に直接関わるのは次の 4 項目です。 | 別添の項目 | 求められること | 共有の管理者アカウントでは | | --- | --- | --- | | 技術的安全管理措置(1)アクセス制御 | 担当者と扱う個人情報データベース等の範囲を限る。手法の例示は、ユーザー ID に付与するアクセス権で使用できる従業者を限定すること | ID が人を指さないので、権限で人を限れない | | 技術的安全管理措置(2)アクセス者の識別と認証 | 使う従業者が正当なアクセス権を持つ人だと、識別した結果に基づいて確かめる | パスワードを知っている人は誰でも同じ ID になり、識別されない | | 組織的安全管理措置(2)規律に従った運用 | 利用状況の記録が重要。例示にログイン実績、アクセスログ等 | 記録は残るが、操作した人が管理者としか残らない | | 組織的安全管理措置(3)取扱状況を確認する手段 | 例示に「アクセス権を有する者」の明確化 | 一覧に書くべき人が、パスワードを知っている人まで広がる | 24 条の監督の対象になる従業者に派遣社員やパート社員が含まれることは、[オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding)にまとめています。社会保険労務士や給与計算の委託先に ID を渡す場合は、個人データの取扱いの委託に当たれば 25 条の委託先の監督の側になります(要点は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors))。4 項目を共有アカウント・退職者・委託先に当てはめた表は[個人情報保護法の安全管理措置をアカウント管理に当てはめる](/guides/compliance/appi-safety-measures-for-accounts)にあります。 ## 番号法で加わること 給与システムにマイナンバーが入っていれば、番号法の安全管理措置が重なります。番号法 12 条は、個人番号利用事務等実施者に、個人番号の漏えい、滅失、毀損の防止その他の適切な管理のために必要な措置を求めています。個人情報保護委員会の「特定個人情報の適正な取扱いに関するガイドライン(事業者編)」は、これを個人情報保護法に加えて全ての事業者に課される措置と説明しています。検討の手順の中では、個人番号を扱う事務に従事する「事務取扱担当者」を明確にしておかなければならない、としています。 | 事業者編ガイドラインの項目 | 求められること | 共有の管理者アカウントでは | | --- | --- | --- | | 事務取扱担当者の明確化 | 個人番号を扱う事務に従事する人を明確にしておく | 管理者アカウントを知っている人が全員、事務取扱担当者に当たると読める | | 技術的安全管理措置 a アクセス制御 | 手法の例示は、ユーザー ID に付与するアクセス権で、使用できる者を事務取扱担当者に限定すること | 担当者でない人も同じ ID で入れる | | 技術的安全管理措置 b アクセス者の識別と認証 | 事務取扱担当者が正当なアクセス権を持つ人だと、識別した結果に基づいて確かめる | 識別の単位が人ではなくアカウントになる | | 組織的安全管理措置 b 取扱規程等に基づく運用 | 記録の例示に、事務取扱担当者の情報システムの利用状況(ログイン実績、アクセスログ等) | マイナンバーを誰が見たかが、記録から分からない | | 組織的安全管理措置 c 取扱状況を確認する手段 | 記録の例示に「アクセス権を有する者」 | 一覧と実際に入れる人が一致しない | 中小規模事業者(従業員 100 人以下。一定の場合を除く)には別の対応方法が示されていて、機器に備わっているユーザーアカウント制御(利用者ごとにログインを分ける機能)で担当者を限定することが望ましい、とあります。規模が小さくても、人ごとに分けることが前提です。番号法は委託についても、委託先の監督(11 条)と再委託の許諾(10 条)を定めています。 ## 内部統制で問われること 上場企業とその準備をしている会社では、財務報告に関わるシステムの管理が IT 全般統制として評価されます(定義は[IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc))。金融庁の企業会計審議会が定める「財務報告に係る内部統制の評価及び監査に関する実施基準」は、IT に係る全般統制の具体例を挙げています。その 1 つが「内外からのアクセス管理などシステムの安全性の確保」です。給与システムが評価の範囲に入る会社では、管理者権限を誰がいつ使ったかを示すことになります。管理者アカウントを共有していると、設定を変えた人も、給与の数字を直した人も、記録の上では同じ管理者です。 ## 主要な人事・給与サービスの権限の仕組み SmartHR とマネーフォワード クラウド給与について、公式ヘルプで確かめられることを整理します。確かめるのは 4 点です。権限の種類、権限を細かく分ける方法、操作の記録、使えなくする操作です。ここに挙げていないサービスも、公式ヘルプでこの 4 点を確かめます。 ### SmartHR 権限の種類は、システム標準権限(管理者・事務担当者・メンバー・退職者・情報システム担当者)とカスタム権限です。細かく分けるにはカスタム権限を使い、アカウントごとに利用できる機能と扱える従業員情報の範囲を独自に設定します。一部の機能は管理者権限でのみ使えます。操作の記録は監査ログです。従業員情報の作成・変更・削除、マイナンバーの閲覧・編集などの重要な操作を保持し、誰が・何を・いつ・どのように変えたかが分かります。確認は共通設定の監査ログから行います。使えなくする操作については、公式ヘルプがログインを求めるため、公開されている部分には書かれていません。 ### マネーフォワード クラウド給与 既定の権限の種類は 2 つです。給与担当者は「すべての機能を使用し操作を行うことができます」で、従業員は自分の給与・賞与明細を確認できます。細かく分けるには「権限パターンの追加・管理」で、業務に関する権限とシステムに関する権限をまとめた権限パターンを作り、給与担当者ごとに設定します。この機能の利用にはコンタクトセンターへの問い合わせが要ります。操作の記録は、公式ヘルプに記述がありません。使えなくする操作は 2 つで、「メンバーの追加・管理」でメンバーを削除すると即座にログインできなくなり、「ログイン権限失効日」を設定すると、その日以降ログインできません。 ### 共有が残っているのは運用の選択 SmartHR もマネーフォワード クラウド給与も、担当者ごとにアカウントは作れます。これらのサービスで管理者アカウントが共有されているなら、サービスの制約ではなく運用の選択で残っています。担当者を人ごとに登録し、管理者に当たる権限を持つ人を絞り、退職時は本人のアカウントを止める、という形に置き換えられます。マネーフォワード クラウド給与の「ログイン権限失効日」のように、退職日を先に入れておける機能があれば、止め忘れを減らせます。 ## 共有をやめられないときに用意するもの 管理者アカウントが 1 つしか作れないシステムや、委託先に渡す ID は、共有のまま残ります。共有のまま使うときに決めることは[担当者ごとに分けられないアカウントの扱い](/guides/shared-accounts/when-accounts-cannot-be-split)にまとめています。人事・給与のシステムでまず要るのは、使った人の記録です。IPA の中小企業ガイドライン付録 5 の規程サンプルは、管理者権限を持つ共有アカウントへのアクセスについても書いています。アクセスログの取得により使用者を特定できるようにする、という文例です(6.2.2)。方法の選び方は[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。 ## よくある質問 **管理者アカウントを人事と情報システム部門で共有するのは違法ですか** 共有を禁じる条文はありません。ただ、通則編の別添が求める識別と認証と、利用状況の記録は、ID が人を指さないと満たせません。使える人の一覧と使った人の記録を別に持つことになります。 **マイナンバーを扱うシステムは何が違いますか** 番号法 12 条は全ての事業者に安全管理措置を求め、ガイドラインは個人番号を扱う事務取扱担当者を明確にしておくことと、担当者の利用状況の記録を求めています。共有 ID では担当者の一覧と ID が対応しません。 **社労士や給与計算の委託先に管理者 ID を渡してよいですか** 個人情報保護法 25 条と番号法 11 条は委託先の監督を求めます。委託先の担当者ごとにアカウントを作り、権限を委託業務の範囲に限り、契約終了時に止める手順を決めておきます。 **従業員 100 人以下の会社でも同じ管理が要りますか** 番号法のガイドラインは、中小規模事業者(従業員 100 人以下。一定の場合を除く)にも、機器のユーザーアカウント制御で担当者を限定することを望ましいとしています。少なくとも人ごとの ID は要ります。 **サービスに監査ログがあれば共有 ID でも足りますか** 記録に残るのはアカウントの名前です。管理者アカウントを共有していると、記録は管理者としか残らず、誰が操作したかは記録から分かりません。人ごとのアカウントにしてはじめて記録が人を指します。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [行政手続における特定の個人を識別するための番号の利用等に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/425AC0000000027) - [個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン(事業者編)」(令和 7 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/2506_my_number_guideline_jigyosha.pdf) - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について(意見書)」(令和 5 年 4 月 7 日)](https://www.fsa.go.jp/news/r4/sonota/20230407/1.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン 付録 5 情報セキュリティ関連規程(サンプル)」](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx) - [SmartHR ヘルプセンター「アカウント権限とは」](https://support.smarthr.jp/ja/help/articles/360061864733/) - [SmartHR ヘルプセンター「システム標準権限で利用できる機能」](https://support.smarthr.jp/ja/help/articles/360026266513/) - [SmartHR ヘルプセンター「カスタム権限を追加・削除する」](https://support.smarthr.jp/ja/help/articles/360026106594/) - [SmartHR ヘルプセンター「監査ログとは」](https://support.smarthr.jp/ja/help/articles/360026107494/) - [マネーフォワード クラウド給与サポート「マネーフォワード クラウド給与のアクセス権限は、どのようなものがありますか?」](https://biz.moneyforward.com/support/payroll/faq/member/m02.html) - [マネーフォワード クラウド給与サポート「「給与担当者」よりも詳細な権限は設定できますか?」](https://biz.moneyforward.com/support/payroll/faq/user/u03.html) - [マネーフォワード クラウド給与サポート「「権限パターンの追加・管理」の設定方法」](https://biz.moneyforward.com/support/payroll/guide/system-management/pa_office_authority_patterns.html) - [マネーフォワード クラウド給与サポート「給与担当者や従業員がログインできないようにする方法を教えてください。」](https://biz.moneyforward.com/support/payroll/faq/member/m01.html) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify は、人ごとに分けられないシステムの管理者アカウントを、パスワードを渡さずに使わせる部分を担います。担当者はスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残り、CSV で出せます。担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 --- # 採用媒体のアカウントを複数人で使うときの権限と共有 ID 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。 更新日: 2026-10-14 採用媒体の企業アカウントを複数人で使うとき、決めることは 3 つです。担当者ごとの ID を発行できるか、どの権限を付けるか、退職や異動のときにどう外すかです。答えは媒体ごとに違うので、公式ヘルプで確認できた媒体を表にしました。人事・採用のアカウント全体の考え方は[人事・採用のアカウント管理](/guides/hr-access)にまとめています。 ## 媒体ごとの違い | 媒体 | 担当者ごとの ID | 権限の種類 | 退職時に外す操作 | | --- | --- | --- | --- | | Indeed(採用担当者向けの管理画面) | 発行できる。「登録ユーザー」からメールアドレスで追加する | 用意された役割(管理者、高度なアクセス、標準アクセス、制限付きアクセスなど)から選ぶか、権限を一つずつ組み合わせる(カスタム)。制限付きアクセスは特定の求人の応募者だけを扱える | 「登録ユーザー」で、「アクション」の列にある 3 点のアイコンから「削除する」を選ぶ。権限の変更も同じアイコンから行う | | doda(採用支援システム doda CONNECT) | 発行できる。「アカウントを管理」の「ユーザーと権限」から追加する | 管理者(1 名のみ)、管理者代理、通常ユーザー、参照ユーザーの 4 種類 | ユーザー編集画面の「ユーザーの削除」。管理者は削除できない | | Wantedly(会社アカウント) | 発行できる。社員の Wantedly 個人アカウントを、招待リンクか招待メールで会社アカウントに紐づける | 全体の権限は管理者とメンバー。採用サービスの権限は管理者、担当、メンバー、なしの 4 種類 | 「メンバー管理」でそのメンバーを選び、ゴミ箱マークで紐付きを解除する | | ビズリーチ(法人向け) | 担当者ごとの発行の可否と権限は公式 FAQ に記述がなく、アカウント数だけ「上限は設けておりません」とある | 公式 FAQ に記述なし | 公式 FAQ に記述なし | | Green | 発行できない。管理画面の ID とパスワードは各社 1 つで、利用者ごとの発行も管理者権限の追加も受け付けていない | なし。複数人が同時にログインできる | 公式ヘルプに記述なし。ID が 1 つなので、パスワードの変更になる | | engage | 発行できない。複数のアカウントを発行する機能はない。店舗や拠点ごとに、別のメールアドレスで別のアカウントを作ることはできる | なし。1 アカウントにメールアドレスは 1 つ。メーリングリストを設定すれば通知を複数人で受け取れる | 公式ヘルプに記述なし。パスワードの変更になる | 発行できる媒体にも、人数と権限の条件があります。Wantedly は管理画面にアクセスできる人数が契約プランで決まります。公式ヘルプではライトプラン 15 人、スタンダードプラン 30 人、プレミアムプランは無制限で、数えるのは採用の「管理者」と「担当」の合計です。doda の権限は、人材紹介サービス向けのマニュアルに載っているものです。管理者は 1 名だけで、管理者代理から下は人数の制限がありません。Indeed は、追加する相手が Indeed に登録済みのメールアドレスを持っていることが条件です。役割の選び方は[Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo)にあります。 ## 権限をどう選ぶか 権限は、任せる業務に要る範囲に合わせて選びます。応募者の氏名や連絡先を検索できる一覧は、個人情報保護法の個人データに当たると読めます。23 条は、個人データの漏えい、滅失、毀損(なくしたり壊したりすること)を防ぐために必要かつ適切な措置を求めています。使う人と見られる範囲を限ることがその措置に含まれる理由は、[個人情報保護法の安全管理措置をアカウント管理に当てはめる](/guides/compliance/appi-safety-measures-for-accounts)にまとめています。 見せる応募者を絞れる権限は、公式ヘルプで確認できたかぎりでは Wantedly の「担当」と Indeed の「制限付きアクセス」です。Wantedly で担当に設定された人が確認できるのは、「未対応」の候補者と、自分が担当に設定された候補者だけです。Indeed の制限付きアクセスは、特定の求人の応募者だけを扱える役割です。面接官や部門の担当者のように、一部の応募者だけを見ればよい人には、これらの権限を付けます。 doda の権限は、見せる応募者ではなく、使える操作を絞ります。参照ユーザーは、応募者・求人・原稿と、各種設定のうち人材紹介会社管理と設定情報確認を見るだけの権限で、スカウトの送信はできません。doda には、見られる応募者を一部に絞る設定は公式ヘルプにありません。 アカウントの追加と削除ができるのは、Indeed の管理者、doda の管理者と管理者代理、Wantedly の全体の管理者です。doda では申込管理も請求管理も通常ユーザーが使えて、管理者・管理者代理と分かれるのはマスタ管理とユーザー管理だけです。doda のマニュアルは、「他の求人に関する情報を見られたくない」などの事情がなければ管理者代理にしておくとすべてのページが見られて便利だ、と書いています。便利さを取るか、見られる範囲を絞るかは、その担当者が応募者情報を扱う必要があるかで決めます。 応募者情報のダウンロードだけを止める権限は、公式ヘルプで確認できた媒体にはありません。出力してよい人と目的を運用で決め、誰がいつ何件出したかを残すことになります。決め方は[応募者情報の持ち出しを防ぐアクセス管理](/guides/hr-access/preventing-applicant-data-exfiltration)にあります。 ## 担当者ごとに分けられない媒体をどう使うか IPA の「組織における内部不正防止ガイドライン」(第 5 版)の対策 7 は、利用者ごとの ID を個別のパスワード等で認証するよう求めています。Green と engage は ID が 1 つしかないため、この求めを媒体の中では満たせません。共有 ID だと誰が操作したかを識別できない理由は、[オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding)にまとめています。 そこで、媒体の外で 3 つを決めます。使ってよい人の一覧、誰がいつ使ったかを残す方法、辞めた人が出たときのパスワードの変更です。決め方は[担当者ごとに分けられないアカウントの扱い](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。 どちらの媒体にも、入れる場所を絞る設定はあります。engage の公式ヘルプは、管理画面へのアクセスを特定の IP アドレスに限る IP 制限機能の設定手順を示しています。Green の公式ヘルプにも、指定した IP アドレスからだけログインできるログイン IP アドレス制限設定があります。使った人は分かりませんが、社外や自宅から共有 ID で入られることは止められます。 パスワードの変更と配り直しを繰り返したくない場合は、パスワードを見せずに使わせる方法があります。[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)が、手作業の台帳、パスワードマネージャー、ID 管理サービス、アクセス管理ツールの 4 つを比べています。 ## 退職・異動のときに外す操作 外す操作は上の表のとおりですが、媒体ごとに先に済ませておくことがあります。 doda では、管理者の担当者が辞めるときに、退職前に管理者情報を別の人に変えます。管理者は削除できず、管理者情報を変えられるのは管理者だけだからです。削除したユーザーは復元できないので、記録が要るなら削除の前に出しておきます。 Wantedly では、辞める人が投稿したストーリーの投稿者を別のメンバーに変えてから、紐付きを解除します。個人アカウントが削除されると、その人が作成したストーリーも削除されるためです。全体の管理者は最低 1 名要るので、辞めるのが唯一の管理者なら先に引き継ぎます。 Green と engage は ID が 1 つで、止める操作そのものがありません。パスワードを変えて、残る人に配り直すことになります。 どの媒体でも、外したことを確かめる材料は、その媒体のユーザー一覧です。退職の手続きにアカウントの項目を入れ、媒体ごとに誰が外すかを決めておくと、一覧との突き合わせが退職日にできます。手続きの組み立ては[入社・退職時のアカウント管理チェックリスト](/guides/hr-access/onboarding-offboarding-checklist)にまとめています。 ## よくある質問 **担当者ごとに ID を作れない媒体はどう使いますか** 使ってよい人の一覧を持ち、誰がいつ使ったかを残す方法を決め、辞めた人が出たらパスワードを変えます。パスワードを見せずに使わせる仕組みに替える選択肢もあります。 **権限はどれを選べばよいですか** 任せる業務に要る範囲です。見られる応募者を絞れるのは Wantedly の「担当」(候補者ごと)と Indeed の「制限付きアクセス」(求人ごと)です。doda の参照ユーザーは、使える操作を絞る権限です。 **管理者の担当者が退職するときは何をしますか** doda の管理者は 1 名で削除できず、管理者情報は管理者しか変えられません。Wantedly は全体の管理者が最低 1 名要ります。退職前に別の人へ引き継ぎます。 **退職者の ID は削除と無効化のどちらがよいですか** doda は削除すると復元できません。記録の扱いは公式ヘルプに書かれていないので、必要な記録を出してから削除します。Wantedly は紐付きの解除になります。 ## 参考資料 - [Indeed「ユーザーの追加・管理方法 - アカウント管理 -」(Indeed の使い方 採用担当向け)](https://jp.indeed.com/%E6%B1%82%E4%BA%BA%E5%BA%83%E5%91%8A/c/info/add-users) - [Indeed 採用企業ヘルプセンター「ユーザーとアクセス権限の概要」](https://jp.indeed.com/help/employers/articles/users-and-permissions-overview?hl=ja&co=JP) - [Indeed 採用企業ヘルプセンター「ユーザーの追加とアクセスレベルの設定」](https://jp.indeed.com/help/employers/articles/206589143) - [パーソルキャリア「doda CONNECT ご利用マニュアル【人材紹介サービス向け】」(2026 年 4 月版)](https://assist.doda.jp/DodaAssistR/Help/manual/manual_intro_ALL.pdf) - [Wantedly ヘルプ「権限について」](https://help.wantedly.com/hc/ja/articles/8761119733017) - [Wantedly ヘルプ「会社アカウントへのメンバー追加について」](https://help.wantedly.com/hc/ja/articles/8786949564057) - [Wantedly ヘルプ「メンバーと会社アカウントの紐付きを解除したい」](https://help.wantedly.com/hc/ja/articles/8788920882073) - [Green サポート「アカウントを追加したい(社員を招待したい)」](https://support.green-japan.com/hc/ja/articles/47404079870873) - [Green サポート「アカウントの管理者・利用者を増やすことは可能ですか?」](https://support.green-japan.com/hc/ja/articles/47372591632409) - [Green サポート「ログイン IP アドレス制限設定について知りたい(セキュリティ)」](https://support.green-japan.com/hc/ja/articles/47467642693401) - [engage サポートセンター「管理画面を複数名で閲覧したいがどうしたらいいか」](https://support.en-gage.net/hc/ja/articles/7556749613465) - [engage サポートセンター「同一法人で複数のアカウントを作成することはできますか?」](https://support.en-gage.net/hc/ja/articles/4415984143897) - [engage サポートセンター「IP 制限機能を利用したい」](https://support.en-gage.net/hc/ja/articles/47898864234649) - [ビズリーチ「よくあるご質問|法人向けビズリーチ」](https://bizreach.biz/service/bizreach/faq/) - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify は、担当者ごとに ID を発行できない媒体の企業アカウントを、管理者が登録して担当者に割り当てる仕組みです。担当者はパスワードを知らないままクリックでログインし、誰が・いつ使ったかは一人ひとり残ります。退職や異動のときは、管理者が割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 --- # 入社・退職時のアカウント管理チェックリスト 入社時は本人ごとの ID・必要な範囲の権限・共有アカウントの利用許可・誓約書、退職時は ID の停止・共有パスワードの変更・情報と機器の回収・実行の記録です。期限の一例は、退職の翌日までです。 更新日: 2026-09-18 入社・退職時のアカウント管理で行うことは、発行するものと止めるものを一覧にし、実行した日付と担当者を書き添えることです。下の 3 つの一覧は、その項目を人事・採用の現場に置き換え、それぞれの理由と根拠になる資料を添えたものです。用語の定義は[オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding)にあります。 ## チェックリストを誰が持つか 人事部門が起点になります。IPA の「組織における内部不正防止ガイドライン」(第 5 版)の対策 5 は、利用者 ID とアクセス権の登録・変更・削除の手続きを定めることを求めています。手続きに漏れが出ないよう、人事異動に関連する人事手続きと連携した運用にすることも挙げています。入社・異動・退職の日付を最初に知るのが人事だからです。実行するのは各サービスの管理者や情報システム部門なので、人事が起票し、各サービスの管理者が実行日を書き、人事が回収する形にすると、実行の記録が一か所に残ります。 IPA の「中小企業の情報セキュリティ対策ガイドライン」(第 4.0 版)は、退職や任期満了のときに情報や機器・ID・鍵等を回収することを勧めています。加えて、復元できない方法によりデータを消去し、チェックリストや記録で実行状況を見えるようにする、としています。同じガイドラインの付録 5「情報セキュリティ関連規程(サンプル)」には、多くの規程の文例が載っています。そのうち、この手続きに直接関わるのは 2 つです。アクセス権の発行・変更・削除を申請・許可制にして申請書か台帳を保管すること(6.1)と、退職時のチェックリストで返還物を確かめること(人的対策 3)です。 ## 入社・応援の開始時 1. 担当する業務から、使うサービスとアカウントを決めて一覧に書きます。誰がどのアカウントを使えるかの一覧がないと、あとの項目も退職時の停止も照合できません(通則編 別添 組織的安全管理措置(3)の例示「アクセス権を有する者」)。 2. 本人ごとの ID を、決めた承認手順で発行します。承認の記録が、あとで誰が許可して誰に発行したかを示します(内部不正防止ガイドライン 対策 5、付録 5 の 6.3)。 3. 権限は担当業務に要る範囲と期間に限ります。使わない権限が残ると、不正にも操作ミスにも使われる範囲が広がります(対策 5 の必要最小限、必要な時期に限ること)。 4. 本人ごとに分けられないアカウントは、使ってよい人の一覧に加え、使った人が分かる方法を決めます。共有アカウントの記録はアカウント名でしか残らないため、一覧と使った人の記録がないと事故のあとに絞れません(付録 5 の 6.2.1、管理者権限を持つものは 6.2.2)。 5. 共有アカウントの二段階認証のコードの受け取り先を、辞める可能性のある個人のスマホだけにしません。その人のスマホだけだと、退職のとき残る人がコードを受け取れず、二段階の確認を続けられません(付録 5 の 6.2.2 の多要素認証)。 6. 私物のパソコン・スマホ・USB メモリを業務に使ってよいかを決め、許可するなら使う業務の範囲と守る事項をルールにします。私物端末に入った情報は退職時に返却・消去を確かめにくく、調査でも提供を断られることがあります(対策 11 の対策ポイント 1・2。承諾書は望ましいとされています)。 7. 秘密保持の誓約書を入社時に受け取ります。重要情報を保護する義務があることは、一度ではなく適切な機会に何度も意識づけます(対策 26、対策 23 の対策ポイント 4)。 8. 派遣社員・アルバイト・他部署からの応援は、開始日と終了日を一覧に書きます。終了日が一覧にないと、止める日を誰も知らないまま ID が残ります(IPA 中小企業ガイドライン 本編の派遣社員等の契約満了)。 項目 4 の「使った人が分かる方法」は、規程サンプルの言い方では「共有 ID を利用したユーザーを特定できるようにする」ことです(6.2.1)。管理者権限を持つ共有アカウントについては、アクセスログ(誰がいつ入ったかの記録)の取得により使用者を特定できるようにする、とあります(6.2.2)。方法の選び方は[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。項目 5 の受け取り先の決め方は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にあります。 ## 異動時 1. 前の部署で使えたアカウントと権限を一覧で見直し、要らないものを外します。異動のたびに権限が足されるだけだと、一人に権限が集まります(内部不正防止ガイドライン 対策 5。異動で不要になった ID・権限はただちに削除し、人事異動の時期に一斉に見直すとしています)。 2. 共有アカウントを使ってよい人の一覧から外します。一覧に残っている限り、使える人として扱われます(通則編 別添 技術的安全管理措置(1))。 3. 重要な情報を扱う部署への配属と離任のときは、誓約書を受け取ります。入社時の誓約書だけでは、対象の情報が特定されていないことがあります(対策 26 の対策ポイント 3 の昇格、配置転換等、対策 23 の対策ポイント 4)。 ## 退職・応援の終了時 1. 退職日が決まったら、その人が使えるアカウントの一覧を各サービスの管理者に渡します。社外のサービスのアカウントも入れます。退職の情報がアカウントの管理者に届かないことが、削除漏れの入口になるためです。社内の手続きだけでは、社外のサービスは止まりません(内部不正防止ガイドライン 対策 5 の人事手続きとの連携、付録 5 の 6.4)。 2. 退職の申し出から退職日までは、アクセスできる範囲や持ち出しの手段を限ります。雇用終了の間際は情報の持ち出しが起きやすいとされています(対策 24 の対策ポイント 5)。 3. 本人の ID を停止または削除します。期限を決めておかないと、そのうちのまま残ります。規程サンプルの期限は不要になった日の翌日までです(対策 24 の雇用終了直後に速やかに、付録 5 の 6.4)。 4. ID を消すと利用の記録も消えるサービスでは、消さずにロックします。事故のあとに記録が要るためです(対策 5 の脚注)。 5. 管理者用のアカウント(強い権限を持つ ID)を持っていたら、別に確かめて削除・無効化します。一般の ID と別の画面で管理されていて、漏れやすいためです(付録 5 の 6.7)。 6. 共有アカウントは使ってよい人の一覧から外し、パスワードを変えて残る人に配り直します。辞めた人はパスワードを知ったままなので、変えない限り入れます(通則編 別添 技術的安全管理措置(1)(2))。 7. 二段階認証のコードの受け取り先を、残る人に移します。受け取り先が辞めた人のスマホのままだと、残る人がログインできず、辞めた人にコードが届きます(根拠は項目 6 と同じ)。 8. テレワークのために与えた権限(VPN など)も、止める一覧に入れます。対策 24 は、削除を確かめる利用者 ID と権限に、テレワークのために与えたものを含めています(対策 24 の対策ポイント 3)。 9. 情報・書類・パソコン・スマホ・入館証・鍵を回収し、残るデータは復元できない方法で消去します。返却されていないと、退職後の持ち出しや不正侵入に使われます(対策 24 の対策ポイント 2、IPA 中小企業ガイドライン 本編、付録 5 人的対策 3)。 10. 秘密保持の誓約書を、必要に応じて受け取ります。断られても入社時の誓約書があります。対象の情報を退職者が認識していないと、退職後の漏えいを防ぎにくいためです(対策 23)。 11. 各項目の実行日と担当者をチェックリストに書き、保管します。記録がないと、あとで止めたことを示せません(IPA 中小企業ガイドライン 本編の、チェックリストや記録で実行状況を見えるようにすること)。 項目 6 の配り直しは、人数が多いほど抜けが出ます。その限界は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)に書いています。項目 1 が抜けた事案は[退職日の翌日にアカウントが残っていた事案](/guides/incidents/former-staff-took-files-before-and-after-leaving)にあります。 ## 期限をどう決めるか 内部不正防止ガイドラインは、退職で不要になった ID と権限を「ただちに削除」(対策 5)、「雇用終了直後に速やかに」(対策 24)としていて、日数は書いていません。規程サンプルの 6.4 は、不要になった日の翌日までに削除または無効化する、という文例です。人事の手続きに書くなら、この文例にならって退職日の翌日までとするか、自社の締めの日に合わせて日を決め、共有アカウントのパスワード変更も同じ期限に置きます。派遣社員やアルバイトの契約満了も同じ扱いです。IPA の中小企業ガイドラインは、役職員の退職と派遣社員等の契約満了を並べて、回収と消去を勧めています。 ## よくある質問 **退職者の ID はいつまでに止めればよいですか** IPA の内部不正防止ガイドラインは「雇用終了直後に速やかに」とし、日数の定めはありません。IPA 中小企業ガイドライン付録 5 の規程サンプルは、不要になった日の翌日までに削除か無効化としています。 **チェックリストは人事と情報システム部門のどちらが持ちますか** 人事が起票し、各サービスの管理者が実行日を書く形が、人事手続きとの連携を求める内部不正防止ガイドラインに沿います。採用媒体のように人事が管理者のものは、人事が実行も担います。 **入社時にも誓約書が要るのはなぜですか** 内部不正防止ガイドラインの対策 26 は、秘密保持誓約書の提出を適切な機会に要請しなければならない、としています。対策 23 も、入社時や異動時に結んでおくことが重要だ、としています。 **退職予定者の権限は退職日まで残してよいですか** 内部不正防止ガイドラインは、雇用終了の間際に持ち出しが起きやすいとして、一定期間前からアクセス範囲の限定や USB メモリの利用制限などを望ましいとしています。業務に要る範囲は残します。 **共有アカウントのパスワードは退職のたびに変えるのですか** 辞めた人がパスワードを知ったままだと、通則編が求める使う人の限定から外れると読めます。変えて配り直すか、パスワードを本人に渡さない方法に替えるかを、アカウントごとに決めます。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン 付録 5 情報セキュリティ関連規程(サンプル)」](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** チェックリストのうち、ID の発行と停止、使った人の記録の 2 項目を Junify が担います。管理者が本人を登録してアカウントを割り当て、退職時は割り当てを外すだけです。共有パスワードの変更は、パスワードを本人に渡していないので要りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 --- # 応募者情報の持ち出しを防ぐアクセス管理 応募者情報は個人情報保護法の安全管理措置と職業安定法 5 条の 5 の対象です。見られる人を採用に関わる人に限り、媒体からの出力・履歴書の保存先・面接官への共有・私物端末の 4 つの経路に制限と記録を置きます。 更新日: 2026-09-18 応募者情報の持ち出しを防ぐアクセス管理は、応募者情報を見られる人を採用に関わる人に限ることと、情報が動く経路ごとに制限と記録を置くことの 2 つです。経路は 4 つあります。媒体の管理画面からの出力、履歴書のファイルの保存先、面接官への共有、私物の機器です。応募者情報が個人情報保護法の安全管理措置(個人データを守るために行う対策)と職業安定法の対象になる理由は[人事・採用のアカウント管理](/guides/hr-access)にあります。 ## 持ち出しとは何を指すか 個人情報保護委員会のガイドライン(通則編)の別添は、安全管理措置の運用を確かめるための記録の例を挙げています(組織的安全管理措置(2))。個人情報データベース等の利用・出力状況、個人データが記載された書類・媒体等の持ち運びの状況、情報システムの利用状況(ログイン実績、アクセスログ等)です。「持ち運ぶ」は、個人データを管理区域や取扱区域(個人データを扱う場所)の外へ移すことで、事業所内の移動でも紛失・盗難に注意が要る、としています(物理的安全管理措置(3))。応募者情報で言えば、媒体の管理画面から一覧を出力すること、履歴書のファイルを別の場所に保存すること、面接官に渡すことが、いずれも出力か持ち運びに当たります。 職業安定法 5 条の 5 は、求人者や募集受託者(募集を委託された者)に、求職者等の個人情報を適正に管理するために必要な措置を求めています(2 項)。厚生労働省の指針(平成 11 年労働省告示第 141 号)の第五の二(一)は、その措置として 4 つの事項を挙げています。措置を講ずるとともに、求職者等から求められれば内容を説明しなければならない、としています。4 つのうち 2 つが、正当な権限を有しない者による個人情報へのアクセスを防止するための措置と、収集目的に照らして保管する必要がなくなった個人情報を破棄又は削除するための措置です。見られる人を限ることと、選考が終わった情報を消すことは、この 2 つに当たります。 ## 経路ごとの制限と記録 IPA の「組織における内部不正防止ガイドライン」(第 5 版)では、持ち出しに関わる対策が別々の章にあります。物理的管理の章にあるのは、機器や記録媒体の持ち出しの承認と記録(対策 10)と、私物の機器や USB メモリの業務利用と持込の制限(対策 11)です。技術・運用管理の章には、持ち出す機器の暗号化などの保護(対策 15)があります。そして記録の側から支えるのが、原因究明と証拠確保の章にあるアクセス履歴と操作履歴の記録(対策 18)です。採用の実務に当てはめると、経路ごとに次のようになります。 ### 媒体の管理画面からの一覧出力(CSV) 応募者の一覧をまとめてダウンロードし、表計算ソフトで管理する形です。出力できる人を採用担当者に限り、媒体の権限で分けられなければ、出力してよい人と目的を決めます。残す記録は、誰が・いつ・何件出力したかです。共有アカウントでは媒体の記録に人が残らないため、使った人の記録を別に持ちます。根拠は、通則編 別添 組織的(2)の「利用・出力状況」と、内部不正防止ガイドライン 対策 5(一括ダウンロードの通知)です。 ### 履歴書・職務経歴書のファイルの保存先 履歴書や職務経歴書のファイルは、メールの添付、個人のフォルダー、チャットに散らばります。保存先を 1 か所に決めてそこ以外に置かず、選考が終わった応募者の分は期限を決めて消します。残す記録は、保存先の一覧と削除した日付です。通則編 別添 技術的(1)と物理的(4)、指針 第五の二(一)ニが根拠です。 ### 面接官への共有 面接官には、履歴書をメールで送るか、印刷して渡すことになります。見られる期間を面接の前後に限り、送るならファイルにパスワードを付け、印刷物は面接後に回収します。残す記録は、誰に・いつ・どの応募者の情報を渡し、いつ回収したかです。根拠は、内部不正防止ガイドライン 対策 5(権限の期間)と、通則編 別添 技術的(4)、物理的(3)です。 ### 私物のパソコン・スマホ・USB メモリ・個人のクラウド 自宅や移動中に私物のスマホで応募者情報を見る、個人のクラウドに同期する、といった形です。私物端末で扱ってよいかを決め、許可するなら範囲と守る事項を書面で受け取ります。会社貸与でない USB メモリは使いません。残す記録は、許可した人と端末の一覧です。内部不正防止ガイドライン 対策 11 と対策 15 が根拠です。 経路とは別に、退職・異動する採用担当者にも制限が要ります。退職前に応募者の一覧を持ち出す形なので、退職の申し出から退職日までは出力や持ち出しの手段を限り、退職日に ID を止めて共有アカウントのパスワードを変えます(内部不正防止ガイドライン 対策 24)。記録は、退職時のチェックリストと実行日です。 一覧出力には、通知の仕組みが関わります。内部不正防止ガイドラインは、重要情報を一括してダウンロードすると上司等に通知されるようにすることを望ましいとしています(対策 5)。媒体の管理画面にその通知や出力の記録があるかは媒体ごとに違い、公式ヘルプで確かめます。ない媒体では、出力した人が日付と件数を台帳に書く運用になります。共有アカウントで媒体に入っていると、媒体の記録には企業アカウントの名前しか残らないので、使った人の記録は媒体の外で持つことになります。台帳の項目は[共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory)にあります。 退職する担当者については、[退職の直前に顧客情報を持ち出された事案](/guides/incidents/documents-taken-just-before-resignation)に、公表された再発防止策と一緒にまとめています。退職時に止めるものの一覧は[入社・退職時のアカウント管理チェックリスト](/guides/hr-access/onboarding-offboarding-checklist)にあります。 ## 記録は誰のために残すか 内部不正防止ガイドラインの対策 18 は、記録を残す目的を、不正の早期発見と、起きたあとの原因と影響範囲の調査の 2 つとしています。失敗したアクセスだけでなく成功したアクセスの記録も取ること、記録を残している事実を従業員に知らせることが望ましい、としています。知らせることが持ち出しを思いとどまらせるからです。 同じ対策 18 は、内部不正者ではない従業員の無実を証明するために記録を活用し、プライバシー・人権を保護する姿勢を示すことも挙げています。そのために、記録を取る目的を就業規則などで従業員に知らせること(対策 21)が要ります。応募者情報の記録も、この位置づけを担当者に伝えたうえで運用に組み込みます。 ## 応募者から説明を求められたら 指針は、求職者等から求められれば管理の措置の内容を説明しなければならない、としています。経路ごとに置いた制限と残す記録が、そのまま説明の材料になります。誰が応募者情報を見られるか、いつ消すか、持ち出しをどう防いでいるかを、一覧と記録で答えられる状態にしておきます。 ## よくある質問 **応募者の履歴書も個人情報保護法の対象ですか** 氏名で検索できる応募者の一覧は個人データに当たると読めます。通則編は、取得しようとしている個人情報のうち個人データとして扱う予定のものを守る措置も、23 条の措置に含めています。 **媒体からの CSV 出力は禁止すべきですか** 禁止までは求められていません。出力してよい人と目的を決め、誰がいつ何件出したかを残します。一括ダウンロードで上司に通知が届く仕組みを、内部不正防止ガイドラインは望ましいとしています。 **面接官に履歴書をメールで送ってよいですか** 通則編の別添は、移送する個人データについてパスワード等による保護を行うことを手法の例に挙げています。見られる期間を面接の前後に限り、面接後に削除か回収を確かめます。 **私物のスマホで応募者情報を見てよいですか** 内部不正防止ガイドラインは、私物の機器の業務利用を許可するか先に決め、許可するなら業務の範囲と守る事項を定めて承諾書を取ることを挙げています。決めていない状態で見るのは避けたいところです。 **担当者に、記録を取っていると伝えるべきですか** 内部不正防止ガイドラインは、記録を残している事実を従業員に知らせることが望ましいとし、目的を就業規則などで周知するよう求めています。記録は無実を示すためにも使うものです。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [職業安定法(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/322AC0000000141) - [厚生労働省「職業紹介事業者、求人者、労働者の募集を行う者、募集受託者、募集情報等提供事業を行う者、労働者供給事業者、労働者供給を受けようとする者等がその責務等に関して適切に対処するための指針」(平成 11 年労働省告示第 141 号、最終改正 令和 6 年厚生労働省告示第 318 号)](https://www.mhlw.go.jp/content/001003997.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify は、採用媒体の共有アカウントを担当者がスマホで本人確認をしてから使う仕組みなので、誰が・いつ入ったかが一人ひとり残ります。Junify から開いた画面ではダウンロードをアカウント単位で止められ、アップロードは検知して管理者に通知します。担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 --- # 採用の繁忙期に増える人へ、パスワードを渡さずに媒体を使わせる方法 方法は 4 つです。媒体で本人の ID を追加する、ID 管理サービスに預ける、パスワードマネージャーで共有する、パスワードを見せずに代わりに入力する。このうち 3 つは、教えずに済みます。 更新日: 2026-09-18 採用の繁忙期に増える人(他部署からの応援、派遣社員、アルバイト)に媒体を使わせる方法は 4 つあり、3 つはパスワードを教えずに済みます。媒体で本人の ID を追加する方法と、ID 管理サービス(Okta、Microsoft Entra ID など)に預けて代わりに入力させる方法があります。残りは、パスワードマネージャーで共有する方法と、パスワードを見せずに代わりに入力する仕組み(アクセス管理ツール)を使う方法です。パスワードマネージャーだけは、見る権限を外しても自動入力で使えるため、共有したものとして扱います。4 つとも、終了日に止める操作があります。 ## 応援要員も従業者の監督の対象 繁忙期に来る人が派遣社員やアルバイトでも、応募者情報を扱わせる以上は、個人情報保護法 24 条の監督(従業者が決まりどおりに個人データを扱っているか確かめること)の対象です。従業者にどこまで含まれるかは[オンボーディング・オフボーディング(アカウントの観点)とは](/guides/hr-access/what-is-onboarding-offboarding)にまとめています。同じ記事に、IPA の「組織における内部不正防止ガイドライン」(第 5 版)の対策 7 が共有 ID を避けるよう求める理由も書いています。 繁忙期だけの人にパスワードを教える運用は、期間が短くても対策 7 の求めから外れます。短い期間だからこそ、教えた後に止める手段がないことが問題になります。 ## 4 つの方法の比較 | 方法 | 応援要員がパスワードを知るか | 前提 | 終了日の操作 | | --- | --- | --- | --- | | 媒体で本人の ID を追加する | 知らない。自分の ID とパスワードで入る | 媒体が担当者ごとの ID の発行に対応している。人数の上限がある媒体では枠が残っている | 媒体の管理画面でその ID を削除か無効化する | | ID 管理サービスに預けて代わりに入力させる | 知らない。Entra ID の公式ドキュメントでは、利用者は共有アカウントのパスワードを見ずに使う | 応援要員がその ID 管理サービスにアカウントを持つ。Entra ID は共有アカウントを使う利用者ごとに EMS か Entra ID P1 / P2 の契約プランと、My Apps のブラウザー拡張機能が要る | アプリの利用の許可を外す(Entra ID はグループから外す) | | パスワードマネージャーで共有する | 見る権限があれば見える。隠す権限でも自動入力で使える | 応援要員が同じパスワードマネージャーの利用者になる | 利用者を停止し、その人に共有していたパスワードを変えてから削除する | | パスワードを見せずに代わりに入力する仕組み | 知らない。本人確認した人に代わりに入力する | 前提は製品ごとに違うので、公式の資料で確かめる | その人の利用を止める | 媒体で本人の ID を追加する方法は、媒体が対応していれば手間が最も少ない選択です。対応の有無と権限の種類は[採用媒体のアカウントを複数人で使うときの権限と共有 ID](/guides/hr-access/job-board-account-roles-and-shared-ids)にまとめています。繁忙期に気をつけるのは人数の上限です。Wantedly は管理画面にアクセスできる人数が契約プランで決まり、ライトプランは 15 人、スタンダードプランは 30 人、プレミアムプランは無制限です。doda の管理者代理から下と、ビズリーチのアカウント数には上限がありません。上限のある媒体で枠が足りないときに、余った人にパスワードを教える運用が始まります。 ID 管理サービスの方法は、応援要員がすでに社員としてそのサービスにアカウントを持つ場合に向きます。他部署からの応援がこれに当たります。Entra ID の公式ドキュメントは、管理者が誰にアクセス権があり、誰が過去にアクセスしたかを把握でき、付与と取り消しを行えると書いています。派遣社員やアルバイトにそのサービスのアカウントを発行していない会社では、この方法は使えません。 パスワードマネージャーの方法には、知られずに済むわけではないという限界があります。Bitwarden の公式ヘルプは、「パスワードを隠す」権限を付けても自動入力では使えるため、隠したパスワードも共有済みのパスワードとして扱うよう求めています。1Password の公式ヘルプは、退職者を外す手順を 4 段階で示しています。その人のデータの移行、アカウントの一時停止、その人に共有していたパスワードの変更、アカウントの削除です。共有した相手がいれば、終了日には媒体のパスワードの変更が残ります。 [共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)も 4 つを比べています。ただし、そちらが数えているのは共有アカウントの管理のしかたです。手作業の台帳、パスワードマネージャー、ID 管理サービス、アクセス管理ツールの 4 つで、この記事が数えている応援要員への渡し方とは対象が違います。方法は媒体ごとに選べるので、ID を発行できる媒体は本人の ID、発行できない媒体は代わりに入力する方法、という組み合わせも成り立ちます。 ## 繁忙期が終わった後に止める手順 止める作業は、繁忙期が始まる前に一覧を作っておくと終了日にできます。手順は 6 段階です。 1. 応援要員の一覧に、氏名、雇用の形(社員・派遣・アルバイト)、使わせた媒体、渡し方、開始日、終了日を書く。終了日に何を止めるかは、この一覧からしか分からない。 2. 終了日に、媒体で追加した ID を削除か無効化する。止めるまで、その人は同じ権限で入れる。削除すると復元できない媒体(doda)があるので、記録が要るなら先に出しておく。 3. ID 管理サービスで、そのアプリの利用の許可を外す。Entra ID はグループから外せば、その人は共有アカウントで入れなくなる。 4. パスワードマネージャーでは、その人のアカウントを停止し、共有していた媒体のパスワードを変え、アカウントを削除する。変更を省くと、見た人の記憶に残ったパスワードで入れる。 5. パスワードを教えた人がいれば、媒体のパスワードを変えて残る人に配り直す。二段階認証のコードの受け取り先がその人のスマホや電話番号なら、受け取り先も変える。配り直しの手間は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)にまとめています。 6. 終了日から数日後に、媒体のユーザー一覧に応援要員の ID が残っていないこと、ログインの記録が終了日で止まっていることを見る。止め忘れは、ここでしか見つからない。 応援の開始と終了を、入社・退職と同じ手続きで扱う手順は[入社・退職時のアカウント管理チェックリスト](/guides/hr-access/onboarding-offboarding-checklist)にまとめています。 ## よくある質問 **数週間だけの応援に ID を作るのは大げさですか** IPA のガイドラインは、共有 ID を使わず利用者ごとの ID で認証するよう求めています。媒体での追加と削除は管理者の画面操作で済み、上限は Wantedly のように契約プランで決まる媒体だけ確かめます。 **派遣社員やアルバイトにも同じ扱いが要りますか** 要ります。通則編は、24 条の監督の対象になる従業者に、派遣社員、パート社員、アルバイト社員を含めています。開始日と終了日を一覧に書き、終了日に止めます。 **パスワードマネージャーで共有すれば知られずに済みますか** 済みません。Bitwarden の公式ヘルプは、隠したパスワードも自動入力で使えるため共有済みとして扱うよう求め、1Password は退職者に共有したパスワードの変更を手順に入れています。 **ID 管理サービスがあれば応援要員にも使えますか** 応援要員がその ID 管理サービスにアカウントを持ち、利用者ごとの契約プランがあれば使えます。Entra ID は共有アカウントを使う利用者ごとに P1 か P2 の契約プランが要ります。 **繁忙期が終わったら何から止めますか** 応援要員の一覧を終了日順に見て、媒体で追加した ID を消し、ID 管理サービスやパスワードマネージャーの許可を外します。教えたパスワードがあれば変えて配り直します。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [Wantedly ヘルプ「会社アカウントへのメンバー追加について」](https://help.wantedly.com/hc/ja/articles/8786949564057) - [パーソルキャリア「doda CONNECT ご利用マニュアル【人材紹介サービス向け】」(2026 年 4 月版)](https://assist.doda.jp/DodaAssistR/Help/manual/manual_intro_ALL.pdf) - [ビズリーチ「よくあるご質問|法人向けビズリーチ」](https://bizreach.biz/service/bizreach/faq/) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [1Password Support「Offboard a team member」](https://support.1password.com/offboarding/) - [Bitwarden Help Center「Collection permissions」](https://bitwarden.com/help/collection-permissions/) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify では、管理者が媒体の ID とパスワードを登録し、応援要員を登録してカードを割り当てるだけで初日から使えます。応援要員は自分のスマホで本人確認をしてクリックするだけで、パスワードは知りません。メールアドレスがない人でも使え、終了日には割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 --- # オンボーディング・オフボーディング(アカウントの観点)とは アカウントの観点では、オンボーディングは入社・応援の開始に合わせて本人の ID と権限を発行し、共有アカウントを使える人に加えること。オフボーディングは退職・終了に合わせてそれらを止め、共有のパスワードを変えることです。 更新日: 2026-09-18 オンボーディング・オフボーディングとは、一般には入社後の受け入れと、退職時の手続きの全体を指す言葉です。アカウントの観点では、入社・異動・応援の開始に合わせて発行するものと、退職・終了に合わせて止めるものを指します。人事・採用の現場では、採用媒体や人事系サービスの共有アカウントを使う許可も、この発行と停止に含まれます。 ## オンボーディングで何を発行するか IPA の「組織における内部不正防止ガイドライン」(第 5 版)の対策 5 は、利用者 ID とアクセス権の登録・変更・削除の手順を定めて運用するよう求めています。対策 7 は、共有 ID や共有のパスワードを使わず、利用者ごとの ID を個別のパスワード等で認証するよう求めています。対策 7 は、他の利用者に ID とパスワードを貸すことの禁止も挙げています。 発行するのは 4 つです。 - 本人ごとの ID。利用者ごとに ID を発行し、パスワード等で本人を確かめます(対策 7) - 必要な範囲の権限。決めた手順で登録し、担当する業務に要る範囲に限ります(対策 5) - 共有アカウントの利用許可。本人ごとに分けられないアカウントは、使ってよい人の一覧に加えます(通則編 別添 組織的安全管理措置(3)の例示「アクセス権を有する者」) - 秘密保持の誓約書と教育。入社時にも誓約書を受け取り、個人データの扱いを教育します。派遣社員は、派遣元に出した誓約書の写しの提出を派遣の条件にします(対策 26、対策 23 の対策ポイント 4、派遣は対策 22、通則編 別添 人的安全管理措置) 誓約書の提出を適切な機会に要請しなければならない、としているのは対策 26 です。退職時だけでなく入社時や異動時にも受け取る理由は、対策 23 の対策ポイント 4 にあります。退職時には提出を拒まれることがあるためです。IPA の「中小企業の情報セキュリティ対策ガイドライン」(第 4.0 版)も、機密性の高い情報を扱う役職員(社外要員は除く)に守秘義務の誓約書を提出させることを勧めています。書面の保管・更新・回収も、計画的に管理するとしています。 ## オフボーディングで何を止めるか 内部不正防止ガイドラインの対策 5 は、異動や退職で不要になった利用者 ID とアクセス権をただちに削除するよう求めています。対策 24 は、雇用終了時に情報資産(会社の情報や機器)を返却または完全消去させ、与えていた利用者 ID や権限を削除するよう求めています。削除は雇用終了直後に速やかに行い、テレワークのために与えた権限も含める、としています。 止めるのは 4 つです。 - 本人の ID とアクセス権。停止・削除します。ID を消すと利用の記録も消えるシステムでは、ロックして記録を残します(対策 5 とその脚注、対策 24) - 共有アカウントの利用。使ってよい人の一覧から外し、パスワードを変えて残る人に配り直します(通則編 別添 技術的安全管理措置(1)(2)) - 情報・機器・鍵。返却させるか完全に消去し、チェックリストや記録で実行状況を見えるようにします(対策 24、IPA 中小企業ガイドライン) - 秘密保持の誓約書。雇用終了の際に、必要に応じて提出を求めます(対策 23) 共有アカウントの根拠は、通則編の別添が求めるアクセス制御(担当者の範囲を限ること)と、使う従業者の識別と認証です。辞めた人がパスワードを知ったままでは、この限定から外れると読めます。配り直しの手間と抜け漏れは[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)にまとめています。 ## なぜ人事の手続きと結びつけるのか 対策 5 は、利用者 ID とアクセス権の手続きを人事異動に関連する人事手続きと連携させ、人事異動の時期に一斉に見直すことを挙げています。対策 24 は、雇用終了の間際に情報の持ち出しが起きやすいとしています。雇用終了前の一定期間から、PC 等をシステム管理部門等の管理下に置くこと(アクセス範囲の限定、監視の強化など)が望ましい、という書き方です。どちらも、入社・異動・退職の日付を最初に知る人事部門が起点になります。 対象は正社員に限りません。通則編の従業者には契約社員、パート社員、アルバイト社員、派遣社員も含まれるので、繁忙期の応援要員の開始と終了も同じ手続きで扱います。全体像は[人事・採用のアカウント管理](/guides/hr-access)にまとめています。 ## よくある質問 **オンボーディングとアカウントの発行は同じ意味ですか** 一般のオンボーディングは、受け入れの手続きや教育を含む入社後の全体を指します。この記事は、そのうち ID・権限・共有アカウントの利用許可という、アカウントに関わる部分だけを扱います。 **退職者の ID は削除と停止のどちらがよいですか** IPA の内部不正防止ガイドラインは削除を求めつつ、ID を消すと利用の記録も消えるシステムでは、ID をロックして記録を残すとしています。そのシステムで記録がどう残るかを確かめて決めます。 **派遣社員やアルバイトの終了も同じ手続きですか** 同じです。通則編の従業者には派遣社員、パート社員、アルバイト社員が含まれます。IPA の中小企業ガイドラインも、派遣社員等の契約満了時に ID や機器を回収するよう勧めています。 **共有アカウントのオフボーディングは何をしますか** 使ってよい人の一覧からその人を外し、パスワードを変えて残る人に配り直します。ID を止める操作がないため、変更しない限り、辞めた人は知っているパスワードで入れます。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 採用媒体や人事システムのアカウントを担当者ごとに分け、応援要員や採用代行の出入りのたびに発行と停止を行い、応募者の情報に誰が触れたかを残し続けることになります。 **Junify なら** Junify では、オンボーディングは管理者が本人を登録してアカウントを割り当てるだけ、オフボーディングは割り当てを外すだけです。パスワードは本人に渡していないので、退職後に変えて配り直す作業はありません。誰が・いつ・どのアカウントを使ったかは本人ごとに残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try?scenario=hr) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](/guides/hr-access/indeed-employer-account-with-rpo): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。 - [採用代行(RPO)に媒体アカウントを渡すときの整理](/guides/hr-access/handing-job-board-accounts-to-rpo): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。 - [人事システム・給与システムの共有 ID の問題](/guides/hr-access/hr-payroll-system-shared-ids): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。 --- # SaaS のログインを会社が管理する方法の全体像 SaaS のログインを会社が管理する方法は、ID 管理サービスによる SSO、パスワードマネージャー、特権 ID 管理、管理されたブラウザー、代わりに入力する仕組みなどに分かれ、アカウントの種類ごとに組み合わせます。 更新日: 2026-09-18 会社が SaaS(インターネット経由で使う業務ソフト)のログインを管理する方法は一つではなく、アカウントの種類ごとに組み合わせます。 ## 何を管理しようとしているのか 管理の目的は、誰が、どのアカウントで、どの端末からログインし、何をしたかを会社が決めて、あとから確かめられる状態にすることです。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、ユーザー ID と管理者 ID の発行から削除までの手続を定めるよう勧めています。付ける権限を必要最小限にすることも、同じ項目にあります。共有 ID はなるべく使わず、やむを得ず使う場合は、使った人を特定できる仕組みを整えるようにも勧めています。以下の方法は、この勧めのどの部分を受け持つかが違います。 ## なぜ一つの方法では済まないのか SaaS のアカウントには、社員一人に一つずつ発行できるものと、そうでないものがあります。ID 管理サービス(Okta や Microsoft Entra ID など)は、社員の ID を一か所で管理する仕組みです。一人一つの ID にでき、そのサービスがこれとつながるなら、[SSO(シングルサインオン)](/guides/access-basics/what-is-sso)で済みます。Microsoft の公式ドキュメントは、SSO を「一度サインインすれば多くのアプリに入れる」仕組みと説明しています。その方法として SAML(ID 管理サービスとつなぐための規格)などを挙げています。 しかし、この形に収まらないアカウントが残ります。SAML などにつながらないサービス、1 つしか作れない管理者アカウント、SNS や広告のように複数人で使う共有アカウント、ID 管理サービスにアカウントのない短期の担当者や委託先です。Microsoft も Okta も、つながらないサービス向けに、預かったパスワードを代わりに入力する機能を別に用意しています。同じ会社の中に、方法の違うアカウントが並ぶのはこのためです。 ## 方法にはどんなものがあるか | 方法 | 受け持つこと | 受け持たないこと | | --- | --- | --- | | ID 管理サービスと SSO | 社員の ID の台帳と本人確認、SAML などでつながるサービスへのログイン | つながらないサービス | | ID 管理サービスの代理入力(Okta の SWA、Entra ID の password-based SSO) | つながらないサービスのログイン画面への代わりの入力 | ID 管理サービスにアカウントのない人 | | パスワードマネージャー | ID とパスワードの保管、自動入力、複数人での共有 | パスワードを知る人を増やさずに使わせること | | 特権 ID 管理(PAM) | 管理者用アカウントの利用申請と承認、権限の付与、操作の記録 | 日常の業務アカウント | | 管理されたブラウザー(Chrome Enterprise など) | ブラウザーの設定と拡張機能の管理、データ持ち出しの制限、利用のレポート | ログインそのもの | | SaaS 管理ツール | 使っている SaaS とアカウントの一覧、入退社に合わせた発行と削除 | 日々のログインの本人確認と記録 | | パスワードを見せずに代わりに入力する仕組み(アクセス管理ツール) | 本人確認した担当者に代わってのパスワードの入力と、担当者ごとの記録 | サービス側に残るパスワードそのもの | 表に収まらない点を、行ごとに補います。SSO は、ID 管理サービスにアカウントのない人には届きません。代理入力では、サービス側のパスワードはなくならず、使うにはブラウザーの拡張機能が要ります。パスワードマネージャーでは、共有した相手はパスワードを使える状態になり、サービス側の記録は共有アカウントの名前で残ります。特権 ID 管理は、ブラウザーで使う管理画面を対象にするかが製品ごとに違います。管理されたブラウザーは、共有アカウントのパスワードを誰が知っているかまでは扱いません。SaaS 管理ツールは、契約プランと費用の見直しまで受け持ちます。パスワードを見せずに代わりに入力する仕組みは、ログイン画面のあるサービスが対象で、ID 管理サービスにアカウントのない人も対象にできます。使うには、スマホのアプリやブラウザーの拡張機能を入れます。 ID 管理サービスの働きは[IdP(ID 管理サービス)とは](/guides/access-basics/what-is-idp)にまとめています。代理入力の機能を Microsoft と Okta が何と呼び、どのアプリで使えるかは[SAML に対応していない SaaS に SSO に近い運用を作る方法](/guides/access-basics/sso-like-operation-for-non-saml-saas)にあります。パスワードマネージャーの共有機能と限界は[パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager)にまとめています。特権 ID 管理は[特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam)にあります。 管理されたブラウザーについて、Google の公式ヘルプは、Chrome ブラウザーをクラウドの管理画面から管理できると説明しています。設定(ポリシー)は、利用者が Google アカウントにログインしていなくても適用されます。上位の Chrome Enterprise Premium は、機密データの持ち出しを防ぐ制御と、社内ネットワークの外からでも条件つきで SaaS へのアクセスを制御する機能を挙げています。SaaS 管理ツールは、たとえばジョーシスの公式サイト(英語)が、管理外のアプリの検知、契約プランと費用の見直し、アクセス権の付与と回収の自動化を挙げています。 ## 私物端末ではどんな選択肢があるか 私物端末で SaaS を使わせる場合、上の方法に端末側の選択肢が加わります。Microsoft Intune の公式ドキュメントは、端末全体を登録して管理する MDM と、仕事のアプリとその中のデータだけを管理する MAM を分けています。MAM は私物端末で使う典型的な形で、退職時は個人のデータに触れずに会社のデータだけを消せるとしています。仮想デスクトップ(VDI)は、クラウド上で動くデスクトップやアプリを手元の端末に映す方式です。Azure Virtual Desktop の公式ドキュメントによれば、専用アプリかブラウザーから接続します。 総務省の「テレワークセキュリティガイドライン」第 5 版は、テレワークの方式を 7 つに整理しています。VPN、リモートデスクトップ、仮想デスクトップ、セキュアコンテナ、セキュアブラウザ、クラウドサービス、スタンドアロンです。方式ごとに私物端末についての考慮事項が書かれていて、可否は組織が決めます。セキュアブラウザ方式は、専用のブラウザーからオフィスのシステムにアクセスする方法です。製品によってデータが端末から消えるタイミングが違うため、製品の仕様を確かめるよう求めています。ガイドラインの読み方は[総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod)にまとめています。 ## 何から始めるか 使っている SaaS とアカウントの一覧を作るところから始めます。サービスごとに、一人一つの ID にできるか、ID 管理サービスとつながるかを書き出します。共有のまま残るか、使う人が全員 ID 管理サービスにいるか、私物端末から使うかも並べます。この一覧ができると、上の表のどの行がどのアカウントに当てはまるかが決まります。 次に、一人一つの ID にできて ID 管理サービスとつながるものは SSO に寄せ、つながらないものと共有のまま残るものの扱いを別に決めます。共有のまま残るものは、IPA のガイドラインが勧める「使った人を特定できる仕組み」をどう満たすかを選びます。ID 管理サービスの代理入力、貸出の台帳、アクセス管理ツールのどれかです。ID 管理サービスがある会社でそれでも残るアカウントの整理は[Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins)にまとめています。つなげない管理画面の扱いは[ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか](/guides/privileged-access/non-saml-admin-consoles)にあります。 ## このテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 - [SaaS のアカウントを管理するツールの種類と違い](/guides/access-basics/comparison-of-access-management-tool-categories): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 - [最小権限の原則を SaaS の共有アカウントに当てはめる](/guides/access-basics/least-privilege-for-shared-saas-accounts): 共有アカウントでは権限が ID に付き、使う人全員に同じ権限が渡るため、人ごとには絞れません。まず SaaS 側の権限の種類(閲覧・編集・管理者)で個人に分け、共有が残る部分は、使える人の一覧、期間、記録の 3 つで補います。 - [QR コードでログインする方式と、フィッシングへの強さ](/guides/access-basics/qr-code-login-and-phishing-resistance): QR コードでログインする方式は、パソコンの画面の QR をログイン済みのスマホで読み、スマホ側で承認する仕組みです。パスワードを打たない分だけ盗まれにくく、他人が表示させた QR を承認すると入られる弱さがあります。 - [SAML に対応していない SaaS に SSO に近い運用を作る方法](/guides/access-basics/sso-like-operation-for-non-saml-saas): SAML などに対応しない SaaS でも、ID 管理サービスの代理入力、パスワードマネージャーの共有、代わりに入力する仕組みで SSO に近い形にできます。違いは担当者がパスワードを知るかと記録の単位です。 - [IdP(ID 管理サービス)とは](/guides/access-basics/what-is-idp): IdP(ID 管理サービス)とは、社員の ID を一か所で保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。Okta や Microsoft Entra ID が代表です。 - [最小権限の原則とは](/guides/access-basics/what-is-least-privilege): 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。NIST が設計の原則として定義し、IPA も ID の割り当てを必要最小限にするよう勧めています。 - [多要素認証(MFA)とは](/guides/access-basics/what-is-mfa): 多要素認証とは、知っているもの(パスワード)、持っているもの(スマホや IC カード)、本人自身(指紋や顔)の 3 種類のうち 2 つ以上でログイン時に本人を確かめる方式です。パスワードが漏れてもすぐには入られないようにします。 - [パスワードレスとは](/guides/access-basics/what-is-passwordless): パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。パスキー(FIDO)が代表です。パスワードを見せずに代わりに入力する方式は、パスワードが残るので別の仕組みです。 - [セッション録画(画面操作の記録)とは](/guides/access-basics/what-is-session-recording): セッション録画とは、ログインしてから終えるまでの利用を、画面の映像や入力した文字として残す仕組みです。何が残り何が残らないかは製品ごとに違い、本人への明示も要ります。 - [SSO(シングルサインオン)とは](/guides/access-basics/what-is-sso): SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。ID 管理サービスと SAML などの規格でつながるサービスにだけ使え、つながらないサービスには別の方法が要ります。 - [ゼロトラストとは](/guides/access-basics/what-is-zero-trust): ゼロトラストとは、社内ネットワークにいるからといって信頼せず、利用のたびに利用者と端末を確かめてから最小限のアクセスを許す考え方です。NIST SP 800-207 が定義し、総務省は「決して信頼せず、必ず確認せよ」と言い表しています。 ## よくある質問 **SSO を入れればパスワードの管理は要らなくなりますか** ID 管理サービスと SAML などの規格でつながるサービスの分は要らなくなります。つながらないサービスと共有アカウントには、代わりに入力する機能や別の方法が残ります。 **パスワードマネージャーと ID 管理サービスは何が違いますか** パスワードマネージャーは保管と自動入力の道具で、共有した相手はパスワードを使える状態になります。ID 管理サービスは本人確認を引き受け、つながるサービスへのログインを受け持ちます。 **私物端末で SaaS を使わせるにはどうしますか** MDM(端末全体の管理)、アプリだけの管理、仮想デスクトップ、専用のブラウザーがあります。総務省のガイドラインは、VPN・クラウドサービス・スタンドアロンの 3 方式で、リスクを評価して可否を決めるよう求めています。 **小さな会社はどこから始めればよいですか** 使っている SaaS とアカウントの一覧を作り、一人一つの ID にできるもの、共有のまま残るもの、ID 管理サービスにつながるものを分けるところからです。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Microsoft Learn「What is single sign-on in Microsoft Entra ID?」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Chrome Enterprise and Education ヘルプ「Chrome Enterprise Core の概要」](https://support.google.com/chrome/a/answer/9116814?hl=ja) - [Google「Chrome Enterprise Premium」](https://chromeenterprise.google/products/chrome-enterprise-premium/) - [ジョーシス公式サイト(Josys)](https://www.josys.com/) - [Microsoft Learn「What is Microsoft Intune?」](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/what-is-intune) - [Microsoft Learn「What is Azure Virtual Desktop?」](https://learn.microsoft.com/en-us/azure/virtual-desktop/overview) - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は、表の「パスワードを見せずに代わりに入力する仕組み」に当たります。管理者が ID とパスワードを登録して担当者に割り当て、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。ID 管理サービスは置き換えず、SAML につながらないサービスと共有アカウントの分を受け持ちます。私物端末に入れるのはブラウザーの拡張機能だけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # 監査ログと、監査で示す記録の違い 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 更新日: 2026-09-18 監査ログと、監査で示す記録(監査の場では証跡と呼ばれます)は、同じものを指しているように見えて役割が違います。前者はシステムが自動で残す記録、後者はその記録を監査の目的に合わせて選び、守り、点検した結果です。 ## 監査ログとは何か サイバーセキュリティ戦略本部の「政府機関等のサイバーセキュリティ対策のための統一基準」(令和 7 年度版。以下、統一基準)は、情報システムにおけるログを「システムの動作履歴、利用者のアクセス履歴、通信履歴その他運用管理等に必要な情報が記録されたもの」と説明しています。SaaS(インターネット経由で使う業務ソフト)の管理画面にある「監査ログ」や「アクティビティログ」は、この意味のログです。誰がいつログインし、何を変えたかが、出来事ごとに一行ずつ、システムの側で自動的に残ります。 IPA の「組織における内部不正防止ガイドライン」第 5 版は、ログと証跡を分けて定義しています。ログはシステム等で取られる作業ログであり、証跡は監査や監視のためにポリシー(ルール)を決めて収集されるものです。この区別が、二つの言葉の違いの出発点になります。 ## 監査で示す記録とは何か 監査で示す記録は、「あとから説明する」という目的のために集めた記録です。IPA のガイドラインは、証跡について、決めたルールに応じて情報を取得するとしています。ログ以外の日時、利用者、操作端末、操作内容、送受信の内容などです。システムが自動で残したものをそのまま出すのではなく、何を説明したいかを先に決め、それに要る情報を集めて保存したものです。 金融庁の「財務報告に係る内部統制の評価及び監査の基準」は、内部統制の整備及び運用状況は適切に記録及び保存される必要がある、としています。実施基準は、IT に係る全般統制の例に「内外からのアクセス管理などシステムの安全性の確保」を挙げています。経営者は、評価の手続とその結果を記録し保存しなければならないとしています。監査人は、データやシステムの不正使用や改ざんを防ぐためのアクセス管理の方針を定めているかを確認します。IT 全般統制の全体は[IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc)にまとめています。 | 観点 | 監査ログ | 監査で示す記録(証跡) | | --- | --- | --- | | 誰が決めるか | システムの作り手(出る項目は決まっている) | 会社(何を説明したいかから決める) | | いつできるか | 出来事のたびに自動で残る | ログを選び、守り、点検して初めてそろう | | 何が要るか | 出力の設定 | 誰が・いつ・何をしたかのつながり、改ざんの防止、保存期間、管理者以外の点検 | ## 監査で通用する記録の 4 つの条件 公的な文書が求めていることを、この記事では 4 つに整理します。文書ごとの求めの一覧は[管理者用アカウントの監査で示せるようにしておく記録](/guides/privileged-access/privileged-access-audit-records)にあるので、ここでは条件の側から説明します。 一つ目は、誰が・いつ・何をしたかがつながっていることです。内閣官房の「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版。以下、内閣官房のガイドライン)は、ログとして取得する項目の例を 10 挙げています。アカウント管理に関わるのは次の 5 つです。事象の主体(人物又は機器等)を示す識別コード、情報システムの操作記録、事象の種類、事象の対象、正確な日付及び時刻です。時刻については、機器の時刻を基準となる時刻に同期させ(そろえ)、ログに時刻を記録するよう求めています。時計がずれていると、複数のシステムの記録を並べたときに前後関係が崩れるためです。 二つ目は、改ざんされていないと示せることです。統一基準は、改ざんや消失等が起こらないようログが適切に保全されなければならない、としています。内閣官房のガイドラインは、取得したログへの不正な消去、改ざん及びアクセスを防止するよう求めています。そのために、適切なアクセス制御(触れる人を絞ること)を含む保全の方法を定めます。IPA のガイドラインも、管理者の記録は改ざんまたは不正な消去ができないように、暗号化などの対策を実施するとしています。確認のときは、改ざん及び削除の防止と、特定の管理者だけが触れる状態にしておくことが望ましいとしています。管理者が自分の記録を消せる状態では、記録があっても「消していない」ことを示せません。 三つ目は、保存期間を決めて守ることです。統一基準は、ログを取得する目的を決めたうえで、取得する対象の機器、取得する項目、保存期間、扱い方を定めるよう求めています。内閣官房のガイドラインの解説は、標的型攻撃の経緯を初期の段階から確認する観点から、1 年間以上の保存が望ましいとしています。IPA のガイドラインは、保存期間はリスクとコストのバランスで決めるとしています。監査で問われるのは長さそのものより、決めた期間のとおりに残っているかです。 四つ目は、管理者以外が点検していることです。統一基準は、取得したログを定期的に点検又は分析する機能を設け、不正侵入や不正操作の有無を点検するよう求めています。IPA のガイドラインは、システム管理者のアクセス履歴や操作履歴を記録して保存するとしています。その内容は、定期的に管理者以外が確認しなければならないとしています。確認する人の例は、管理者の上司または総括責任者です。記録は残っているだけでは条件を満たさず、点検した記録が加わって初めて監査で示せるものになります。 ## 共有アカウントでは何が欠けるか 一つのアカウントを複数人で使っていると、4 つの条件のうち一つ目が欠けます。システムの監査ログに残るのはアカウントの名前であって、その日にそれを使った人ではないためです。IPA のガイドラインは、システムからログを集められない場合の形を示しています。管理者の作業内容を文書に記録し、上司または総括責任者が定期的に確認します。共有アカウントの利用を台帳に書き、別の人が確認する運用は、この形に当たります。台帳の記入が本人任せなら、改ざんされていないことを示す二つ目の条件も弱くなります。共有アカウントの整理は[共有アカウントの管理](/guides/shared-accounts)にまとめています。 ## 操作の記録と画面の記録はどう違うか 監査ログは、出来事を一行ずつ文字で残す記録です。画面の記録([セッション録画](/guides/access-basics/what-is-session-recording))は、ログインしてから終えるまでに画面に映ったものを残します。文字の記録は検索と集計ができ、一覧で示せますが、画面で何を見て何を打ったかまでは残りません。画面の記録は操作の中身まで再生できますが、全件を見返すことはできず、探すには文字の記録が要ります。どちらを取る場合も、上の 4 つの条件は同じように問われます。IPA のガイドラインは、記録の保存を行っている事実を従業員に通知することが望まれるとしています。これは、どちらの記録にも当てはまります。 ## よくある質問 **証跡と監査ログは同じ意味ですか** 違います。IPA の内部不正防止ガイドラインは、ログをシステム等で取られる作業ログ、証跡を監査や監視のためにルールを決めて収集するものと分けています。監査ログは証跡の材料です。 **監査ログを出せる設定にしておけば監査は通りますか** 出力だけでは足りません。誰が・いつ・何をしたかがつながり、改ざんを防ぎ、決めた期間保存し、管理者以外が点検した記録が求められます。 **記録を点検するのは誰ですか** 管理者本人ではなく、管理者以外の人です。IPA のガイドラインは上司または総括責任者を例に挙げ、政府の統一基準は定期的な点検又は分析を求めています。 **画面の録画があれば監査ログは要りませんか** 要ります。録画は操作の中身を再生できますが、検索や集計には向きません。出来事を文字で残す記録と組み合わせ、どちらにも改ざんの防止と保存期間の決まりを当てます。 **共有アカウントの記録はどう残せばよいですか** システムの記録にはアカウント名しか残りません。IPA のガイドラインは、ログを集められない場合に作業内容を文書に記録し、上司などが定期的に確認する形を示しています。 ## 参考資料 - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について(意見書)」(令和 5 年 4 月 7 日)](https://www.fsa.go.jp/news/r4/sonota/20230407/1.pdf) - [サイバーセキュリティ戦略本部「政府機関等のサイバーセキュリティ対策のための統一基準(令和 7 年度版)」(令和 7 年 6 月 27 日)](https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf) - [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify が担うのは、4 つの条件のうち「誰が」の部分です。担当者は自分のスマホで本人確認をしてから共有アカウントを開くため、誰が・いつ・どのアカウントを使ったかが一人ひとり残り、CSV で出せます。必要なアカウントには画面の録画も設定でき、見られるのは本人と管理者だけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 - [SaaS のアカウントを管理するツールの種類と違い](/guides/access-basics/comparison-of-access-management-tool-categories): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 --- # ブラウザーの拡張機能でできるアクセス管理の範囲 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 更新日: 2026-09-18 ブラウザーの拡張機能でできるアクセス管理には、決まった範囲があります。その拡張機能を入れたブラウザーの中で、許可されたサイトに対して、です。ID 管理サービスの代理入力も、パスワードを見せずに代わりに入力するツールも、この範囲の中で働きます。 ## 拡張機能とは何か Google の Chrome 拡張機能の開発者向けドキュメントは、拡張機能をブラウザーの使い勝手を広げるものと説明しています。広げ方の例は、画面の見た目を変える、ブラウザーの出来事を受け取る、ウェブページの中身を変える、です。ブラウザーの出来事とは、タブを閉じる、ブックマークを消すなどを指します。ウェブサイトと同じ技術(HTML、CSS、JavaScript)で作られます。主な部品は 3 つです。ページの中で動く仕組み、ブラウザーの出来事を受け取って裏で動く部分、ツールバーのボタンです。ページの中で動く仕組みは、ドキュメントでは content scripts と呼びます。 ## 拡張機能ができること できることは 4 つに分けられます。 - ページを読み取る: ページの中で動く仕組みが、表示中のページの内容を読みます。ログイン画面の ID とパスワードの欄を見つけるのがこれに当たります。 - ページに入力する・書き換える: 同じ仕組みが、ページの内容を変えます。ID とパスワードを欄に入れて送る、ダウンロードのボタンを消す、といった動きです。 - 決めたサイトだけで動く: どのサイトで動くかを、拡張機能の設定であらかじめ宣言します。会社が決めたサービスのログイン画面だけで動かせます。 - ブラウザーの出来事に反応する: タブを開いた・閉じた、ダウンロードが始まった、といった出来事を受け取ります。業務用の窓を閉じたら記録を締める、といった動きです。 Chrome のドキュメントによれば、ページの中で動く仕組みは、表示しているページの内容を読み取り、変更できます。読み取った内容を、親の拡張機能に伝えることもできます。どのページで動くかは、設定ファイルに書いた対象のパターンで決まります。拡張機能が使う権限は設定ファイルで宣言し、どのサイトとやり取りできるかを決める権限(ホスト権限)もここに含まれます。警告の出る権限が複数あるときは、利用者が拡張機能を入れるときに一覧で表示されます。ページの中で動く仕組みは、ページや他の拡張機能から触れない隔離された環境で動きます。Okta の公式ヘルプは、自社の拡張機能の安全機能を 2 つ挙げています。入力する認証情報をアプリから読めない場所に一時的に置き、サインインが終わると消すことです。もう一つは、アプリの URL の文字列が Okta の持つものと一致するかを確かめてから入力することです。 ## 拡張機能ができないこと 拡張機能の範囲はブラウザーの中に限られます。ドキュメントが挙げる働きは、いずれもブラウザーの画面とウェブページに対するものです。パソコンに入れた別のアプリ(メールソフト、会計ソフト、遠隔操作のアプリなど)の中で起きることには関われません。拡張機能を入れていないブラウザーや端末にも届きません。同じサービスに、拡張機能のないブラウザーやスマホのアプリからログインすれば、拡張機能の管理は働かないためです。したがって、拡張機能で管理できるのは、担当者がそのブラウザーを通ってサービスを使うときだけです。パスワードを担当者が知っている限り、別の経路から使う余地は残ります。 ## ID 管理サービスの代理入力と拡張機能 ID 管理サービス(Okta や Microsoft Entra ID など、社員の ID を一か所で管理する仕組み)には、代理入力の機能があります。SAML(ID 管理サービスとつなぐための規格)につながらないサービス向けのもので、拡張機能で動いています。仕組みの全体は[SSO(シングルサインオン)とは](/guides/access-basics/what-is-sso)にまとめています。 Microsoft の公式ドキュメントによれば、password-based SSO のアプリにサインインするには拡張機能が要ります。名前は My Apps Secure Sign-in Extension です。利用者は、初めて開くときに拡張機能を入れるよう促されます。拡張機能は Chrome、Microsoft Edge、Internet Explorer 向けに配布されています。スマホでは、Microsoft Edge のモバイル版を使うよう案内しています。Okta の公式ヘルプは、Okta Browser Plugin を、SAML に対応せず利用者の認証情報を求めるアプリで SSO を使うためのものとしています。Okta 対応アプリのサインインページを開くと、認証情報を自動で入れます。どちらも、拡張機能のあるブラウザーから使うことが前提です。 ## 会社が拡張機能を管理するには 会社が入れてよい拡張機能を決め、業務に使う拡張機能を配る仕組みが、ブラウザーの管理機能です。Google の Chrome Enterprise Core の公式ヘルプは、管理コンソールから 100 種類以上の設定を適用できると説明しています。不審な拡張機能をブロックし、ブラウザーの利用のレポートを見ることもできます。設定は、登録した管理対象のブラウザーに、利用者が Google アカウントにログインしていなくても適用されます。拡張機能について、公式ヘルプは 3 つの形を挙げています。管理者がブロックしたもの以外を入れられる形と、許可したものだけを入れられる形を選べること。会社が許可していない権限を求める拡張機能を動かせなくできること。自動でインストールして利用者が外せなくする形があることです。特定のサイトでは拡張機能を動かさない、という設定もあります。 ## Enterprise Browser との違い Enterprise Browser(管理されたブラウザー)は、拡張機能とは違う考え方です。ブラウザーそのものを、会社の管理の単位にします。上位の有料版である Chrome Enterprise Premium は、機密データの持ち出しを防ぐ制御を挙げています。ほかに、利用者・場所・端末の状態に応じた SaaS へのアクセス制御、脅威の検知、拡張機能の管理、レポートです。Microsoft Edge for Business は、Entra ID のアカウントでログインすると有効になります。仕事用と個人用の窓を分け、お気に入り・パスワード・保存データを窓の間で共有しません。会社の管理下にない端末向けには、Intune のアプリ保護の設定と組み合わせる形が案内されています。 | 観点 | 拡張機能 | 管理されたブラウザー | | --- | --- | --- | | 管理の単位 | 入れた拡張機能が動くサイト | ブラウザー全体(すべてのタブとサイト) | | できること | 決めたサイトでの読み取り・入力・動作の変更 | 持ち出しの制限、アクセスの条件、拡張機能の管理、レポート | | 届かない範囲 | ブラウザーの外、拡張機能のないブラウザーと端末 | ブラウザーの外、そのブラウザーを使わない端末 | | 私物端末 | 入れたブラウザーでだけ動く | 登録したブラウザーか、仕事用の窓に分けたブラウザーが対象 | どちらも、ブラウザーの外には届かない点は同じです。違いは、管理の単位を「決めたサイトでの動作」にするか「ブラウザー全体」にするかです。私物端末に入れるものの大きさも変わります。私物端末の選択肢の全体は[SaaS のログインを会社が管理する方法の全体像](/guides/access-basics)にまとめています。 ## よくある質問 **拡張機能を入れればそのサービスの利用を全部管理できますか** できません。拡張機能が働くのは、それを入れたブラウザーからの利用だけです。別のブラウザーやスマホのアプリから同じサービスを使えば、管理の外になります。 **拡張機能はパスワードを読み取れますか** ページの内容を読む権限を持つので、作りによっては読めます。会社は、許可した拡張機能だけを入れられる設定と、求める権限による制限で絞ります。 **Okta や Entra ID の代理入力に拡張機能は要りますか** 要ります。Microsoft は代理入力に My Apps の拡張機能が必要とし、Okta も Okta Browser Plugin で SAML 非対応のアプリに ID とパスワードを入れると説明しています。 **管理されたブラウザーと拡張機能はどちらを選びますか** 管理したいのが決めたサービスの利用なら拡張機能、ブラウザー全体の持ち出しやアクセスの条件なら管理されたブラウザーです。両方を組み合わせることもできます。 ## 参考資料 - [Chrome for Developers「Get started」(Chrome Extensions)](https://developer.chrome.com/docs/extensions/get-started) - [Chrome for Developers「Declare permissions」](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions) - [Chrome for Developers「Content scripts」](https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts) - [Chrome Enterprise and Education ヘルプ「Chrome Enterprise Core」](https://support.google.com/chrome/a/answer/9116814?hl=ja) - [Chrome Enterprise and Education ヘルプ「アプリや拡張機能を許可またはブロックする」](https://support.google.com/chrome/a/answer/6177431?hl=ja) - [Chrome Enterprise and Education ヘルプ「Chrome アプリと拡張機能のポリシーを設定する(Windows)」](https://support.google.com/chrome/a/answer/7532015?hl=ja) - [Microsoft Learn「My Apps portal overview - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/myapps-overview) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Okta Help Center「Security features of the Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/plugin-security.htm) - [Google「Chrome Enterprise Premium」](https://chromeenterprise.google/products/chrome-enterprise-premium/) - [Microsoft Learn「Microsoft Edge for Business」](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-for-business) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify がパソコンに入れるのはブラウザーの拡張機能だけです。担当者は自分のスマホで本人確認をしてカードをクリックし、管理者が登録した ID とパスワードを拡張機能が入力します。カードから開いた窓は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。MDM は要りません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 - [SaaS のアカウントを管理するツールの種類と違い](/guides/access-basics/comparison-of-access-management-tool-categories): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 --- # 私物端末(BYOD)で業務システムを使わせるときの選択肢 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 更新日: 2026-09-18 私物端末(個人所有端末、BYOD)で業務のシステムを使わせるとき、会社が選べる仕組みは 5 つです。対象は、SaaS(インターネット経由で使う業務ソフト)でも社内のシステムでも同じです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを手元に映す仮想デスクトップ(VDI)があります。さらに、会社が管理するブラウザーと、パスワードを見せずに代わりに入力する仕組みがあります。違いは、会社が管理するものが端末か、アプリか、画面か、ブラウザーか、ログインかです。 ## 私物端末で何が問題になるか 会社は私物端末の中身を管理できません。総務省の「テレワークセキュリティガイドライン」第 5 版は、私物端末ではデータを保存でき、対策ソフトの導入を強制できないとしています。そのため十分な管理が取れないと書いています。VPN 方式、クラウドサービス方式、スタンドアロン方式の項では、事故が起きうるリスクを受け入れられるか評価するよう求めています。そのうえで私物端末の利用の可否を決めます。事例の章には、私物端末の業務利用では対策を勤務者任せにせず、組織として行う必要がある、ともあります。 同じガイドラインは、テレワークの方式を 7 つに整理しています。VPN、リモートデスクトップ、仮想デスクトップ、セキュアコンテナ、セキュアブラウザ、クラウドサービス、スタンドアロンです。方式ごとに私物端末についての項があり、求めることが違います。方式ごとの記述と、管理者・勤務者それぞれの対策は[総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod)にまとめています。この記事は、その方式を実現する仕組みの側から、5 つの選択肢を並べます。 ## 5 つの選択肢 | 選択肢 | 会社が管理するもの | 私物端末に入れるもの | 担当が終わったとき | 近い方式(総務省) | 確認した資料 | | --- | --- | --- | --- | --- | --- | | ①MDM(端末の管理) | 端末全体。設定、安全、アプリ | 端末を管理の仕組みに登録する | 端末を初期化できる | 方式ではない。管理者の基本対策に挙がる端末側の対策 | Microsoft Learn、総務省のガイドライン | | ②MAM(アプリの管理) | 仕事のアプリと、その中のデータ | 対応するアプリ(登録は要らない) | 会社のデータだけを消す | セキュアコンテナに考え方が近い | Microsoft Learn | | ③仮想デスクトップ(VDI) | クラウド上のデスクトップとアプリ。データは手元に置かない | 接続用のアプリか、ブラウザー | クラウド側の利用者を外す | 仮想デスクトップ | Microsoft Learn、総務省のガイドライン | | ④会社が管理するブラウザー | ブラウザーの設定、拡張機能、データの持ち出し | 登録したブラウザー、または専用のブラウザーか拡張機能 | ブラウザーの管理から外す | セキュアブラウザ | Google、Island、総務省のガイドライン | | ⑤パスワードを見せずに代わりに入力する仕組み | 誰がどのアカウントを使えるかと、誰が使ったかの記録。サービス側の記録は共有アカウントの名前のまま | パソコンにブラウザーの拡張機能、スマホに本人確認用のアプリ。対象のサービスを別のブラウザーやスマホのアプリから使う場合は範囲外 | 使える人から外す。サービス側のパスワードは残る | 7 方式のどれにも当たらない。方式と組み合わせて使う | Junify の製品ページ | ①と②について、Microsoft Intune の公式ドキュメントは、2 つの管理の形を分けています。MDM は端末を登録し、設定、安全、アプリを含む端末全体を管理する形で、紛失や盗難のときは端末を初期化できます。MAM は仕事のアプリとその中のデータだけを管理し、端末のほかの部分には触れません。私物端末で使う典型的な形とされています。利用者は個人のアプリと内容を自分で管理し、会社は Outlook や Teams など管理するアプリの中のデータを守ります。退職時は、個人の内容に触れずに会社のデータだけを消せます。アプリ保護ポリシー(アプリに配る設定)の公式ドキュメントは、端末を登録しなくても使えるとしています。例に挙げるのは、アプリを開くときの PIN、コピーと貼り付けの制限、個人の保存先への保存の禁止です。ただし対象は、この仕組みに対応したアプリに限られます。利用者には Entra ID のアカウントと Intune の契約プランが要ります。 総務省のガイドラインは、MDM の導入を管理者の基本対策に挙げています。リモートデスクトップ・仮想デスクトップ・セキュアコンテナ・セキュアブラウザの 4 方式では、ルールの策定と、端末に必要な対策が施されていることの確認、端末の管理を求めています。 ③は、クラウド上で動く Windows のデスクトップやアプリを、手元の端末から使う仕組みです。Azure Virtual Desktop の公式ドキュメントがそう説明しています。つなぎ方は、Windows App か Remote Desktop クライアント、または HTML5 のブラウザーです。総務省のガイドラインは、仮想デスクトップ方式で私物端末を使う場合、端末へのデータ保存を制限・禁止するよう求めています。ルールの策定、端末の対策の確認、端末の管理も求めています。 ④について、Google の公式ヘルプは、Chrome Enterprise Core を追加の費用なしで使えるとしています。管理画面から Chrome ブラウザーの設定を配り、利用者が Google アカウントにログインしていなくても適用されます。上位の有料版である Chrome Enterprise Premium では、機密データの持ち出しの制御が加わります。Island の公式ページは、専用のブラウザーと、既存のブラウザーに入れる拡張機能の両方があるとしています。印刷、ダウンロード、画面の撮影、コピーと貼り付けは設定で制御します。ブラウザーの管理機能の詳しい違いは[SaaS のアカウントを管理するツールの種類と違い](/guides/access-basics/comparison-of-access-management-tool-categories)にまとめています。総務省のガイドラインは、セキュアブラウザ方式について、製品によってデータが消えるタイミングが違うとしています。使い方によっては端末にデータが残るおそれがあるため、製品の仕様に十分注意するよう求めています。 ⑤は、端末の中を管理するのではなく、ログインの手前で本人を確かめる仕組みです。パスワードを端末にも担当者にも渡さずに入力します。働くのは拡張機能を入れたブラウザーの中だけで、スマホのアプリから同じサービスを使えば範囲の外です。この類型で公式の資料を確かめられたのは Junify の製品ページだけなので、表の⑤の行はその範囲で書いています。ID 管理サービス(Okta や Microsoft Entra ID など)の代理入力もこの形の一つです。ただし、使う人がそこにアカウントを持つことが前提です。方法の違いは[SAML に対応していない SaaS に SSO に近い運用を作る方法](/guides/access-basics/sso-like-operation-for-non-saml-saas)にまとめています。 ## 何を基準に選ぶか 基準は、会社が何を管理したいかです。端末に業務のデータを置くなら①、置かずにアプリの中だけで完結させるなら②、画面だけを映して手元に何も置かないなら③です。使うものがブラウザーで開く SaaS だけなら④で持ち出しを止められます。共有アカウントや SAML につながらないサービスのログインを、誰が使ったかまで残したいなら⑤です。 組み合わせは前提です。Intune の公式ドキュメントは、守り方の例を挙げています。会社の支給端末は MDM とアプリ保護ポリシーの両方で、私物端末はアプリ保護ポリシーだけで守る形です。総務省のガイドラインも、複数の方式を併用する場合を想定しています。 ## 端末を管理しても残ること ①〜④では、共有アカウントを誰が使ったかが残りません。サービス側の記録には共有アカウントの名前しか残らないためです。共有アカウントの扱いは[共有アカウントの管理](/guides/shared-accounts)にまとめています。私物端末で問われる多要素認証と記録の要求は[総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod)にあります。 ## よくある質問 **私物端末に MDM を入れないと業務に使えませんか** Intune の公式ドキュメントは、MAM を端末の登録なしで使える形としています。総務省のガイドラインは MDM を管理者の基本対策に挙げ、7 方式のうち 4 方式でルールと端末の対策の確認、端末の管理を求めます。 **MAM と MDM は何が違いますか** MDM は端末を登録して端末全体を管理し、紛失時は端末を初期化できます。MAM は仕事のアプリとその中のデータだけを管理し、退職時は個人のデータに触れずに会社のデータだけを消せます。 **仮想デスクトップなら私物端末に何も残りませんか** 画面を映す方式なので、業務のデータは手元に置かない前提です。総務省のガイドラインは、それでも私物端末へのデータ保存を制限・禁止し、ルールと端末の対策の確認、端末の管理を求めています。 **私物端末での共有アカウントの記録はどうなりますか** 端末やブラウザーの管理では、共有アカウントを誰が使ったかは残りません。ログインの手前で本人を確かめて記録する仕組みが別に要ります。 ## 参考資料 - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) - [Microsoft Learn「What is Microsoft Intune?」](https://learn.microsoft.com/en-us/intune/fundamentals/what-is-intune) - [Microsoft Learn「App protection policies overview - Microsoft Intune」](https://learn.microsoft.com/en-us/intune/app-management/protection/overview) - [Microsoft Learn「What is Azure Virtual Desktop?」](https://learn.microsoft.com/en-us/azure/virtual-desktop/overview) - [Chrome Enterprise and Education ヘルプ「Chrome Enterprise Core の概要」](https://support.google.com/chrome/a/answer/9116814?hl=ja) - [Google「Chrome Enterprise Premium」](https://chromeenterprise.google/products/chrome-enterprise-premium/) - [Island「The Enterprise Browser」(Product)](https://www.island.io/product) - [Junify の仕組み](https://www.junify.jp/product) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は 5 つ目の「パスワードを見せずに代わりに入力する仕組み」に当たります。私物のパソコンに入れるのはブラウザーの拡張機能だけで、MDM は要りません。担当者は自分のスマホで本人確認をしてからクリックするだけでログインし、パスワードは端末に渡らず、誰が使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [SaaS のアカウントを管理するツールの種類と違い](/guides/access-basics/comparison-of-access-management-tool-categories): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 --- # SaaS のアカウントを管理するツールの種類と違い ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。 更新日: 2026-09-18 SaaS(インターネット経由で使う業務ソフト)のアカウントを管理するツールを、この記事では 6 つに分けて比べます。名前が似ていても、解く問題が違います。取り上げるのは、ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser(会社が管理する専用のブラウザー)、SaaS 管理ツール、アクセス管理ツールです。[SaaS のログインを会社が管理する方法の全体像](/guides/access-basics)では、ID 管理サービスの働きを SSO と代理入力に分けて 7 行にしています。他社製品の事実は、代表的な製品の公式ドキュメントと公式ページで確認できた範囲だけを書きました。 ## 6 つの種類と確認した製品 | 種類 | 何をするか | 確認した製品と資料 | | --- | --- | --- | | ①ID 管理サービス | 社員の ID を一か所で持ち、本人確認を引き受け、つながるサービスにログインさせる(つながらないサービスには代理入力の機能) | Okta(Okta Help Center)、Microsoft Entra ID(Microsoft Learn) | | ②パスワードマネージャー | ID とパスワードを保管庫に保管し、ログイン画面に自動で入力する(保管庫は複数人で共有できる) | 1Password(1Password Support) | | ③特権 ID 管理(PAM) | 管理者用アカウントの利用の申請と承認、権限の付与、操作の記録を一つの仕組みで行う | SecureCube Access Check(NRI セキュア)、Idira PAM(Palo Alto Networks) | | ④Enterprise Browser | ブラウザーの設定と拡張機能を会社が管理し、データの持ち出しを制限し、利用を記録する | Chrome Enterprise Core / Premium(Google)、Island | | ⑤SaaS 管理ツール | 使っている SaaS とアカウントの一覧を作り、入退社に合わせて発行と削除を行い、契約プランと費用を見直す | ジョーシス(公式サイト) | | ⑥アクセス管理ツール | 本人確認した担当者にパスワードを見せずに代わりに入力し、本人ごとに記録する(Junify を含む) | Junify(製品ページ) | ①の働きは[IdP(ID 管理サービス)とは](/guides/access-basics/what-is-idp)に、②は[パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager)にまとめています。③は[特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam)にあります。 ## 比較表 ⑥の列は Junify の製品ページの範囲で書いています。製品ページに契約プランと費用の記載はないため、この表では扱いません。確認できなかった項目は「未確認」としています。 | 比べる点 | ①ID 管理サービス | ②パスワードマネージャー | ③特権 ID 管理(PAM) | ④Enterprise Browser | ⑤SaaS 管理ツール | ⑥アクセス管理ツール(Junify) | | --- | --- | --- | --- | --- | --- | --- | | 何を解くか | 社員の ID の台帳と本人確認。つながるサービスへの一度のログイン | 保管と配布。覚えなくてよい | 管理者用アカウントの申請・承認・記録 | ブラウザーの設定、拡張機能、持ち出しの制限、利用の記録 | 何を使っているかの一覧、入退社、契約プランと費用 | パスワードを配らずに使わせ、本人ごとに記録する | | 対象になるサービス | SAML などでつながるサービス。つながらないものは代理入力(ログイン画面があるもの) | ログイン画面があるもの全部 | サーバー、ネットワーク機器、クラウドサービス(SecureCube)。SaaS も対象(Idira)。対応するサービスの範囲は未確認 | ブラウザーで開くもの全部。ログインそのものは扱わない | 対応するサービスの ID の一覧と作成・削除 | ログイン画面があるもの(SSO がなくても)。対応を確かめたサービスの一覧は未確認 | | 担当者がパスワードを知るか | SAML ではサービス側のパスワードがない。代理入力では知らないが、サービス側のパスワードは残る | 見る権限があれば見える | SecureCube は利用者に開示せず自動でログイン。Idira は未確認 | Island は利用者ごとにパスワードを保存・呼び出しできる。共有アカウントを誰が知るかの管理は確認したページにない | 扱わない | 知らない。サービス側のパスワードは残る | | 記録の単位 | 誰がいつどのアプリにサインインしたか(個人単位)。代理入力ではサービス側の記録は共有アカウントの名前のまま | 保管庫側の操作(使用状況レポート)。サービス側は共有名 | 申請と操作の記録を対応づける | ブラウザーの利用と設定のレポート | 誰がどの ID を持っているか | 本人確認した人ごと。サービス側の記録は共有アカウントの名前のまま | | 端末の前提 | 代理入力は拡張機能(Entra ID は Edge か Chrome の My Apps 拡張機能、Okta はブラウザープラグイン) | ブラウザーの拡張機能かアプリ | SecureCube はゲートウェイ型で端末に入れるものがない | Chrome は登録したブラウザー。Island は専用ブラウザーか拡張機能 | なし(管理画面で使う) | スマホの Junify アプリとブラウザーの拡張機能。対象のサービスを別のブラウザーやスマホのアプリから使う場合は範囲外 | ## ①〜⑤の根拠 ①について、Microsoft の公式ドキュメントは、Entra ID が本人を確かめて結果をアプリに伝えると説明しています。アプリは自分でユーザー名とパスワードを管理しなくてよくなります。つながらないアプリには password-based SSO があります。Entra ID が ID とパスワードを保管し、アプリに送ります。共有アカウントを使う利用者は、実際のパスワードを見ません。Entra ID はサインインの記録を残すので、管理者は誰がいつアプリにアクセスしたかを確かめられます。Okta の SWA は、SAML などに対応しない外部の Web アプリに SSO の働きを与える技術です。ブラウザープラグインが、サインイン画面に ID とパスワードを自動で入れます。Application Usage レポートで、期間内に誰がアプリにサインインしたかが分かります。 ②について、1Password の公式ヘルプは、共有した保管庫の項目をメンバーが見たり編集したりできるとしています。Teams の閲覧の権限は隠されたパスワードの表示を含みます。使用状況レポートは、メンバーごとに、使った項目と最後にアクセスした日時、行った操作(入力、表示、コピーなど)を示します。レポートの多くは Business の機能です。Teams と Teams Starter Pack では、1Password に料金を直接支払っている場合に、無料の試用で使えるとしています。ブラウザーの拡張機能が、サインインの画面に保存した ID とパスワードを入力します。 ③について、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、特権 ID 管理という技術を挙げています。特権の利用申請や権限付与、操作ログなどを管理するものです。NRI セキュアの公式ページは、SecureCube Access Check の管理対象に、サーバー、ネットワーク機器、クラウドサービスを挙げています。利用者に特権 ID のパスワードを開示せずに自動でログインさせるとしています。申請と承認の形は、事後承認や多段階承認から選べます。特権 ID を使った操作はログとして記録・保管されます。対象の機器や端末にソフトを入れないゲートウェイ型(通信の途中に置く方式)です。Palo Alto Networks の公式ページは、Idira PAM が、サーバーなどの基盤と SaaS の両方を対象にすると書いています。操作の間に入って記録します。 ④について、Google の公式ヘルプは、Chrome Enterprise Core で Chrome ブラウザーを一つの管理画面から管理できるとしています。対応するのは Windows、Mac、Linux、iOS、Android で、追加の費用はかかりません。設定(ポリシー)は、利用者が Google アカウントにログインしていなくても適用されます。レポートには、ブラウザーのバージョン、拡張機能、適用した設定が出ます。Chrome Enterprise Premium は、上位の有料版です。機密データの持ち出しを防ぐ制御と、状況に応じた SaaS へのアクセス制御を挙げています。Island の公式ページは、印刷、ダウンロード、画面の撮影、コピーと貼り付けを設定で制御するとしています。業務の操作も詳しく記録します。専用のブラウザーと、既存のブラウザーに入れる拡張機能の両方があります。同じページは、利用者が自分でパスワードを作り、保存し、呼び出せるとも書いています。保存したパスワードは暗号化されます。共有アカウントのパスワードを誰が知るかを管理する記述は、確認したページにはありません。 ⑤について、ジョーシスの公式サイトが挙げているのは、管理外のアプリの検知、ID の一覧、入退社に合わせたアクセスの自動化です。契約プランと費用の見直し、端末の管理もあります。日々のログインの本人確認や記録は挙げられていません。 ## 組み合わせ方 6 種類は、どれか一つを選ぶものではなく、アカウントの種類ごとに組み合わせます。一人一つの ID にでき、SAML でつながるサービスは①で済みます。何を使っているかが分からなければ、⑤で一覧を作るところからです。ブラウザーからのデータの持ち出しを止めたいなら④、サーバーの管理者 ID まで申請と承認の仕組みに載せたいなら③です。②と⑥は、①でつながらないサービスと共有アカウントを、パスワードを見せてよいか、本人ごとの記録が要るかで選び分けます。 ## この比較で Junify が要らない場合 すべての人に個人の ID を発行できて、そのサービスが ID 管理サービスとつながるなら、①だけで足ります。つながらないサービスと共有アカウントも、使う人が全員 ID 管理サービスにいるなら、①の代理入力で扱えます。記録が「誰がいつアプリに入ったか」で足りる場合です。パスワードを見てよい少人数で使うアカウントは②で配布と保管が整います。アクセス管理ツールを検討するのは、次のどちらかが残るときです。ID 管理サービスにアカウントを作らない人が使うこと、パスワードを知る人を増やしたくないことです。ログイン後の操作を記録したいだけなら、③や④でもできます。違うのは、対象になるサービスの範囲と、導入する形です。 ## よくある質問 **ID 管理サービスがあれば他のツールは要りませんか** 一人一つの ID にでき、SAML などでつながるサービスの分は要りません。つながらないサービスは代理入力の機能で扱え、残るのは ID 管理サービスにいない人、ログイン後の記録、管理者用アカウントの申請と承認です。 **パスワードマネージャーとアクセス管理ツールは何が違いますか** 見る権限のある人にパスワードが見えるかどうかです。1Password Teams の閲覧の権限は隠されたパスワードの表示を含みます。アクセス管理ツールは本人確認した担当者に見せずに入力します。 **Enterprise Browser はログインを管理しますか** 管理するのはブラウザーの設定、拡張機能、データの持ち出し、利用の記録です。Island は利用者ごとのパスワードの保存もできますが、共有アカウントを誰が知るかの管理は確認したページにありません。 **SaaS 管理ツールで誰が使ったか分かりますか** ジョーシスの公式サイトが挙げるのは、管理外のアプリの検知、ID の一覧、入退社に合わせた発行と削除、契約プランと費用の見直し、端末の管理です。日々のログインの記録は挙げられていません。 ## 参考資料 - [Microsoft Learn「What is single sign-on in Microsoft Entra ID?」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [1Password Support「Create reports」](https://support.1password.com/reports/) - [1Password Support「Get to know 1Password in your browser」](https://support.1password.com/getting-started-browser/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NRI セキュアテクノロジーズ「SecureCube Access Check」](https://www.nri-secure.co.jp/service/solution/accesscheck) - [Palo Alto Networks「Idira Privileged Access Management」](https://www.paloaltonetworks.com/idira/human/privileged-access-management) - [Chrome Enterprise and Education ヘルプ「Chrome Enterprise Core の概要」](https://support.google.com/chrome/a/answer/9116814?hl=ja) - [Google「Chrome Enterprise Premium」](https://chromeenterprise.google/products/chrome-enterprise-premium/) - [Island「The Enterprise Browser」(Product)](https://www.island.io/product) - [ジョーシス公式サイト(Josys)](https://www.josys.com/) - [Junify の仕組み](https://www.junify.jp/product) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は表の「アクセス管理ツール」に当たります。管理者が ID とパスワードを登録して担当者に割り当て、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。ID 管理サービスは置き換えず、SAML につながらないサービスと共有アカウント、ID 管理サービスにいない人の分を受け持ちます。パソコンに入れるのはブラウザーの拡張機能だけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # 最小権限の原則を SaaS の共有アカウントに当てはめる 共有アカウントでは権限が ID に付き、使う人全員に同じ権限が渡るため、人ごとには絞れません。まず SaaS 側の権限の種類(閲覧・編集・管理者)で個人に分け、共有が残る部分は、使える人の一覧、期間、記録の 3 つで補います。 更新日: 2026-09-18 [最小権限の原則](/guides/access-basics/what-is-least-privilege)を SaaS(インターネット経由で使う業務ソフト)に当てはめてみます。人ごとに、その仕事に要る権限だけを、要る間だけ渡す形になります。共有アカウントではこの形が成り立ちません。権限が ID に付いていて、一組の ID とパスワードを知る人全員に同じ権限が渡るためです。共有アカウントの定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)にあります。 ## 共有アカウントで最小権限が成り立たない理由 米国 NIST の用語集は、SP 800-53 Revision 5 の定義を載せています。最小権限とは、各主体(entity)にその働きに必要な最小限の資源と権限だけを与えるよう設計する原則です。CNSSI 4009 の定義では、利用者のアクセス権限を、割り当てられた作業に必要な最小限に制限する原則です。どちらも、権限を絞る単位は「主体」や「利用者」です。 SaaS の権限は、利用者ではなく ID に付きます。一人一つの ID なら、ID を絞ることが人を絞ることと同じになります。共有アカウントでは、ID が一つで使う人が複数です。ID の権限を絞っても、その権限は知っている人全員に同じだけ渡ります。閲覧しかしない人にも、管理者の権限が渡ることになります。Microsoft Entra ID の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか、誰がアクセスしたかが分からないこと。外すには変えて配り直すしかないことです。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、ID の発行から削除までを管理する手続を定めるよう勧めています。付ける権限は必要最小限にします。共有 ID はなるべく使わないことも勧めています。やむを得ず使う場合は、共有 ID を利用した人を特定できる仕組みを整え、規定のとおりに運用します。 ## 先に SaaS 側の権限の種類で分ける したがって最初に行うのは、共有をやめて個人の ID に分け、ID ごとに権限の種類を選ぶことです。業務向けの SaaS の多くは、権限の種類を人ごとに割り当てられます。Google アナリティクスの公式ヘルプは、5 つの役割を挙げています。 | 役割 | できること(公式ヘルプの要約) | | --- | --- | | 管理者 | すべての管理。利用者の追加と削除、役割とデータ制限の割り当て | | 編集者 | プロパティ(計測の単位)の設定の管理。利用者の管理はできない | | マーケティング担当者 | オーディエンス、イベント、キーイベントの作成と変更 | | アナリスト | データ探索の作成と共有。非サンプリングのデータ探索の申請 | | 閲覧者 | 設定とデータの閲覧、レポートの表示の変更 | 役割はアカウントとプロパティの単位で人ごとに割り当て、上位で付けた役割は下位に引き継がれます。費用や収益の数字を見せないデータ制限も、役割とは別に付けられます。このように分けられるサービスでは、担当者ごとに「何をする人か」を書き出します。その作業ができる一番低い役割を選び、管理者の役割は少人数に限ります。媒体ごとの権限の分け方は、[Meta のビジネスポートフォリオ](/guides/agency-accounts/meta-business-portfolio-agency-access)、[Google 広告の MCC](/guides/agency-accounts/google-ads-mcc-agency-access)、[Shopify・BASE のスタッフ権限](/guides/agency-accounts/shopify-base-staff-permissions)の記事にまとめています。 分けられないアカウントも残ります。アカウントを一つしか持てないサービス、SNS の公式アカウントそのもの、一つしかない管理者アカウントなどです。どれが当てはまるかの整理は[共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。 ## 共有が残る部分で代わりに絞る 3 つ 共有が残るアカウントでは、権限の種類の代わりに、次の 3 つで絞ります。 ### 使える人の一覧 そのアカウントを使ってよい人を名前で決め、一覧にします。パスワードを知る人は、それより少なくします。権限の種類は絞れなくても、権限を持つ人の数は絞れます。IPA が勧める、必要最小限の割り当てに当たります。 ### 期間 担当の間だけ使えるようにし、担当が終わった日に外します。委託なら契約の終了日です。使わなくなった人に権限が残る状態をなくすためで、IPA が挙げる、異動・退職に伴う削除漏れを防ぎます。 ### 記録 誰がいつ使ったかを、サービス側の記録とは別に残します。サービス側の記録には、共有アカウントの名前しか残らないためです。IPA が勧める、利用した人を特定できる仕組みに当たります。 3 つのうち「使える人の一覧」は、パスワードを知らなくても使える手段があるときに、知る人より広くできます。手段がなければ、使える人とパスワードを知る人は一致します。一人が担当を外れるたびに、パスワードを変えて残る全員に配り直すことになります。この一覧と知る人を切り離す手段は 2 つあります。ID 管理サービス(Okta や Microsoft Entra ID など)の代理入力と、パスワードを見せずに代わりに入力する仕組みです。方法ごとの違いは[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。 ## 見直しの手順 IPA のガイドラインは、異動や退職に伴う権限の変更・削除漏れと、特定の人への権限の集中による不正利用や権限の濫用を、防ぐべき被害として挙げています。そのために、事業所やフロアの入室とシステムのアクセス権限を見直すルールを定め、付与の状況を管理するよう勧めています。運用や利用状況を監視する仕組みを整えることも挙げています。このうちシステムのアクセス権限について SaaS に当てはめると、手順は 4 つです。 1. サービスごとに、個人の ID とその役割、共有アカウントとその使える人の一覧を作る。一覧の作り方は[共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory)にあります。 2. 一人ずつ、その役割や共有アカウントがいまの作業に要るかを見て、要らないものを外す。 3. 記録を見て、一定期間使っていない人を一覧から外す。使っていない権限は、要らない権限の候補です。 4. 入退社と担当交代のたびに当てはまる行を更新し、それとは別に全件を見直す日を決める。IPA のガイドラインは周期を定めていないため、会社が決めます。 管理者用アカウント(強い権限を持つ ID)は、同じ考え方をより厳しく当てはめる対象です。扱いは[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。 ## よくある質問 **共有アカウントでも最小権限は守れますか** 人ごとには絞れません。権限は ID に付き、パスワードを知る人全員に同じ権限が渡るためです。使える人の一覧、期間、記録で、誰がいつ使ったかを絞る形に置き換えます。 **全員に管理者権限を渡すと何が問題ですか** IPA のガイドラインは、特定の人への権限の集中による不正利用や権限の濫用と、異動・退職に伴う権限の変更・削除漏れを、防ぐべき被害として挙げています。 **SaaS の権限の種類はどこで確かめますか** 各サービスの公式ヘルプです。Google アナリティクスは管理者、編集者、マーケティング担当者、アナリスト、閲覧者の 5 つを、アカウントとプロパティの単位で人ごとに割り当てます。 **権限の見直しはどのくらいの頻度で行いますか** IPA のガイドラインは周期を定めず、権限の付与状況を管理し、利用状況を監視する仕組みを勧めています。入退社と担当交代のたびに見直し、別に全件を見る日を決めます。 ## 参考資料 - [NIST Computer Security Resource Center Glossary「least privilege」](https://csrc.nist.gov/glossary/term/least_privilege) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [アナリティクス ヘルプ「[GA4] アクセスとデータ制限の管理」](https://support.google.com/analytics/answer/9305587?hl=ja) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は、共有が残るアカウントの「使える人の一覧」「期間」「記録」を担います。管理者がアカウントごとに使ってよい担当者を割り当て、担当が終わればその場で外します。担当者はパスワードを知らないため、外した後に使える状態は残らず、誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # QR コードでログインする方式と、フィッシングへの強さ QR コードでログインする方式は、パソコンの画面の QR をログイン済みのスマホで読み、スマホ側で承認する仕組みです。パスワードを打たない分だけ盗まれにくく、他人が表示させた QR を承認すると入られる弱さがあります。 更新日: 2026-09-18 QR コードでログインする方式では、パソコンの画面に出た QR コードを、スマホのアプリで読み取ります。そのアプリには、すでに本人がログインしています。スマホ側で承認すると、パソコンがログインします。パスワードを打たないので入力を盗む手口には強く、承認の操作を人が行うので、承認をだまし取る手口には弱さが残ります。 ## QR コードでログインする方式とは何か LINE の公式ヘルプは、パソコン版 LINE のログイン方法を 3 つ挙げています。QR コードの読み取り、生体認証、メールアドレスとパスワードの入力です。QR コードの手順はこうです。パソコン版 LINE を開き、メインの端末(スマホ)の LINE で QR コードリーダーを起動します。パソコンに表示された QR コードを読み取り、スマホの LINE で[ログイン]をタップします。初回のログインで認証番号が表示される場合もあります。パソコンの画面の番号をスマホの LINE に入力して[本人確認]をタップします。Steam(ゲームの配信サービス)の公式サイトも、スマホのアプリの働きを挙げています。QR コードを読み取ってサインインすること、サインインをワンタッチで確認すること、スマホをパスワードの代わりに使うことです。 サービスが違っても、手順は 4 つの段階に分かれます。 1. パソコンが、ログイン画面に QR コードを表示します。 2. ログイン済みのスマホのアプリで、その QR コードを読み取ります。 3. スマホで承認します。サービスによっては、パソコンに照合用の番号が出るので、それをスマホに入力します。 4. パソコンがログインした状態になり、スマホ側ではログイン中の端末の一覧に加わります。 ## なぜスマホで承認すればログインになるのか スマホのアプリは、すでに本人のアカウントでログインしています。パソコンに表示された QR コードは、「このパソコンをログインさせてよいか」という一回限りの問い合わせです。それを本人のスマホが読み取って承認した事実が、本人確認の代わりになります。使っているのは、[多要素認証](/guides/access-basics/what-is-mfa)でいう「持っているもの」(本人のスマホ)です。米国 NIST(国立標準技術研究所)の SP 800-63B は、パソコンとは別の経路(スマホなど)で本人を確かめる方式を扱っています。パソコンとスマホの間で秘密の情報を受け渡す方法の一つに、QR コードを挙げています。 ## 何に強いか パスワードをパソコンで打たないことが、この方式の強さです。偽サイトにパスワードを入力させる手口、キーボードの入力を盗むプログラム、ブラウザーに残ったパスワードの持ち出しがあります。いずれも、パソコン側でパスワードが打たれるか保存されることを前提にしています。QR コードでログインすれば、パソコン側にパスワードは現れません。共用のパソコンや私物のパソコンでも、その端末にパスワードを覚えさせずに済みます。 ## 何に弱いか 弱さは、承認の操作を人が行う点にあります。攻撃者が本物のサービスのログイン画面を開き、QR コードを表示させます。それを偽サイトやメッセージに載せて利用者に読み取らせます。利用者が承認した時点でログインするのは、攻撃者のパソコンです。NIST SP 800-63B は、別の経路で本人を確かめる方式のうち、ある形をもはや受け入れられないとしています。両方の画面に出た秘密を人が見比べ、承認だけを行う形です。利用者が見比べないまま承認する可能性が高まるためです。承認の要求を大量に送りつけ、うるさくなった利用者が一つを承認するのを待つ攻撃(認証疲れ)が観察されていると書いています。 IPA の「情報セキュリティ 10 大脅威 2026 個人編ハンドブック」は、看板やチラシ、郵送物の QR コードを取り上げています。その中に、偽サイトへアクセスさせる有害なものが確認されています。QR コードのリンク先は、読み取る前に目で確かめられません。IPA が扱っているのは、読み取り先が偽サイトである手口です。ログイン用の QR コードを承認させる手口そのものは書かれていません。ただし、読み取る前に中身を目で確かめられないという性質は、ログイン用の QR コードでも同じです。 承認したパソコンは、そのあともログインしたまま残ります。サービスによっては、その端末を一覧で確認して外せます。 LINE の公式ヘルプは、ログインしている端末の確かめ方を説明しています。メインの端末の[設定]>[アカウント]>[ログイン中の端末]で、端末名とログインからの経過時間が分かります。不要な端末は[ログアウト]で外せます。同じ[アカウント]の設定に、サブ端末からの[ログイン許可]をオンまたはオフにする項目もあります。 ## パスキーとどう違うか NIST SP 800-63B は、「フィッシング耐性」を定義しています。利用者の注意深さに頼らずに、偽の相手に秘密や本人確認の結果を渡さない仕組みの性質です。使い捨てのコードのように、人が出力を打ち込む方式には、フィッシング耐性があるとみなしてはならないとしています。QR コードのログインでは、承認するかどうかを人が判断します。この定義は利用者の注意深さに頼らないことを求めているので、QR コードのログインは「フィッシング耐性あり」には入らないと読めます。[パスキー](/guides/access-basics/what-is-passwordless)は、鍵が作ったサイト専用で偽サイトでは働かないため、人の判断に頼りません。サービスがパスキーに対応していれば、偽サイトへの強さではパスキーのほうが上です。 | 観点 | QR コードのログイン | パスキー | パスワード | | --- | --- | --- | --- | | パソコンで打つもの | なし | なし(端末のロック解除だけ) | パスワード | | 偽サイトに対して | 承認を人が判断する | 鍵がサイト専用で働かない | 打てば盗まれる | | 対応するサービス | その方式を用意したサービスだけ | パスキーに対応したサービスだけ | ほぼすべて | ## 会社で使うときに確かめること 確かめる点は、決め方の一例として次の 5 つです。承認の画面に、どの端末からの要求かが表示されるか。初回に番号を見比べる手順があるか。ログイン中の端末を一覧で見て外せるか。自分で表示させていない QR コードは承認しないという決まりを、担当者に伝えているか。ログインの通知が続けて届いたときに、担当者が知らせる先を決めているか。NIST は、承認の通知を送る側に、通知の頻度や回数に妥当な上限を設けることを勧めています。 ## よくある質問 **QR コードでログインすればパスワードは要らなくなりますか** パソコンでは打ちません。ただしスマホ側のアプリにはログインが要り、LINE のようにメールアドレスとパスワードで入る方法が並んで残るサービスもあります。 **他人に QR コードを読ませると何が起きますか** 読み取って承認した人のアカウントで、その QR コードを表示させたパソコンがログインします。自分で表示させていない QR コードは承認しないことが前提です。 **QR コードのログインはフィッシングに強いですか** パスワードを打たないので入力を盗む手口には強い一方、承認の判断を人が行うため、NIST が定義するフィッシング耐性には当たらないと読めます。 **パスキーとどちらを選べばよいですか** サービスが対応していて一人一つのアカウントなら、人の判断に頼らないパスキーのほうが偽サイトに強い方式です。QR コードの方式は、そのサービスが用意している場合に使えます。 ## 参考資料 - [LINE ヘルプセンター「パソコン(PC)でLINEをダウンロード⋅ログイン／ログアウトするには?」](https://help.line.me/line/win/pc?lang=ja&contentId=50001182) - [LINE ヘルプセンター「LINEやLINE関連サービスにログインしている端末を確認するには?」](https://help.line.me/line/ios/pc?lang=ja&contentId=20008468) - [LINE ヘルプセンター「サブ端末(PC/タブレット)からの[ログイン許可]設定を変更するには?」](https://help.line.me/line/ios/pc?lang=ja&contentId=20000112) - [Steam「Steam Apps for Mobile Devices」](https://store.steampowered.com/mobile) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [IPA「情報セキュリティ 10 大脅威 2026 個人編ハンドブック[一般利用者向け]」](https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/setsumei_2026_kojin.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify では、担当者はパソコンの画面に出る QR を自分のスマホの Junify アプリで読んでログインします。この記事で扱った方式と同じ形の本人確認で、メールアドレスがない人でも使えます。管理者が登録した ID とパスワードを担当者に見せずに Junify が入力するので、担当者がサービスのパスワードを打つ場面はありません。本人確認は ID 管理サービスのログインでも行えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # SAML に対応していない SaaS に SSO に近い運用を作る方法 SAML などに対応しない SaaS でも、ID 管理サービスの代理入力、パスワードマネージャーの共有、代わりに入力する仕組みで SSO に近い形にできます。違いは担当者がパスワードを知るかと記録の単位です。 更新日: 2026-09-18 SAML(ID 管理サービスとつなぐための規格)に対応していない SaaS(インターネット経由で使う業務ソフト)があります。こうしたサービスに[SSO(シングルサインオン)](/guides/access-basics/what-is-sso)は使えません。それでも、担当者にパスワードを配らず、一度のログインで入れて、誰が使ったかが残る形は作れます。方法は 4 つあり、担当者がパスワードを知るか、記録がどの単位で残るか、何を前提にするかが違います。 ## 「SSO に近い運用」で目指すこと ID 管理サービス(Okta や Microsoft Entra ID など、社員の ID を一か所で管理する仕組み)が本人を確かめます。その結果をサービスに伝えるのが SSO です。サービス側がその知らせを受け取る作りになっていなければ使えません。password-based SSO(パスワードを代わりに入力する方式)を選ぶ場面を、Microsoft の公式ドキュメントは 2 つ挙げています。アプリが SAML に対応しないときと、ユーザー名とパスワードで認証するときです。 目指す状態は 3 つに分けられます。担当者がサービスごとの ID とパスワードを覚えず、配らないこと。使ってよい人を管理者が決め、担当が終われば外せること。誰がいつ使ったかが残ることです。Microsoft の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか、誰がアクセスしたかが分からないこと。外すには変えて配り直すしかないことです。この 3 つを裏返したものが目指す状態です。 ## 4 つの方法 方法は 4 つです。①Entra ID の password-based SSO と、②Okta の SWA(Secure Web Authentication)は、ID 管理サービスの代理入力です。③パスワードマネージャーの共有と、④パスワードを見せずに代わりに入力する仕組み(アクセス管理ツール)が残りの 2 つです。 ①は、HTML のサインイン画面を持つクラウドのアプリで使えると公式ドキュメントにあります。Entra ID がアプリの ID とパスワードを暗号化して保管し、アプリのログイン画面に送ります。管理者は利用者やグループに ID とパスワードを設定でき、設定しなければ利用者が自分で入力します。共有アカウントの場合は、同じアカウントを使う人のグループを作り、そのグループにパスワードを設定します。利用者は共有パスワードを見ず、使う権限だけを持ちます。対応するアプリでは、Entra ID がパスワードを定期的に自動で更新する設定もあります。 ②について、Okta の公式ヘルプは、SWA を SSO の働きを与える技術としています。対象は、SAML などに対応しない外部の Web アプリです。ID とパスワードの決め方は 5 つあります。利用者が自分で設定する形、管理者が設定する形、管理者が設定した一組を複数の利用者で共有する形などです。管理者が設定する形では、パスワードの表示の機能が使えなくなると公式ヘルプにあります。共有する形では、利用者は共有のパスワードを表示できません。共有の設定のパスワードを見たり変えたりできるのは、上位の管理者(スーパー管理者)とアプリの管理者だけです。ブラウザープラグインは、SWA のアプリのサインイン画面に着くと ID とパスワードを自動で入れると説明されています。 ③について、1Password の公式ヘルプは、保管庫をメンバーやグループと共有できるとしています。共有した人は、項目を見たり編集したりできます。Teams の閲覧の権限は、隠されたパスワードの表示を含みます。Business では「表示とコピー」を別の権限に分けられます。ブラウザーの拡張機能が、サインインの画面で保存した ID とパスワードを入力します。パスワードマネージャーの働きと限界は[パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager)にまとめています。 ④は、本人確認をした担当者に代わってツールがパスワードを入力し、担当者にはパスワードを見せない仕組みです。ID 管理サービスの代理入力と違い、使う人が ID 管理サービスにアカウントを持つことを前提にしない製品があります。対象のサービスと端末の前提は製品ごとに違います。この類型で公式の資料を確かめられたのは Junify の製品ページだけなので、表の④の列はその範囲で書いています。 ## 比較 | 比べる点 | ①Entra ID | ②Okta SWA | ③パスワードマネージャー | ④代わりに入力する仕組み | | --- | --- | --- | --- | --- | | 何が入力するか | Entra ID が保管した ID とパスワードを、My Apps の拡張機能を通じてアプリに送る | Okta が ID とパスワードを入れてサインイン画面に送る。ブラウザープラグインが自動で入力する | 共有した保管庫から、ブラウザーの拡張機能がログイン画面に入力する | 本人確認した担当者に代わってツールが入力する | | 担当者がパスワードを知るか | 知らない | 管理者が設定する形と共有の形では知らない。利用者が設定する形では知っている | 見る権限があれば見える | 知らない | | 記録の単位 | Entra ID のサインインの記録に、誰がいつアプリにアクセスしたかが残る | Application Usage レポートで、期間内に誰がアプリにサインインしたかが分かる | 使用状況レポートに、項目ごとの操作(入力、表示、コピーなど)と操作した人が残る | 本人確認した人ごと | | 使える人 | Entra ID にアカウントのある人 | Okta にアカウントのある人 | 保管庫に招いた人 | ID 管理サービスにアカウントのない人も使える | | 端末の前提 | Edge か Chrome の My Apps 拡張機能 | ブラウザープラグイン | ブラウザーの拡張機能かアプリ | パソコンにブラウザーの拡張機能、スマホに本人確認用のアプリ。対象のサービスを別のブラウザーやスマホのアプリから使う場合は範囲外 | | 契約プラン | 代理入力そのものについては、公式ドキュメントの前提条件に契約プランが挙がっていない。共有アカウントを使う利用者ごとに EMS または Entra ID P1/P2 | 公式ヘルプに明示されていない | レポートの多くは Business。Teams と Teams Starter Pack は、1Password への直接の支払いなら無料試用 | 確認した製品ページに書かれていない | | 担当が終わったとき | グループから外す | アプリの利用の許可を外す(グループ経由ならグループから外す) | 保管庫から外す。見た人の記憶は残る | 使える人から外す | | 確認した資料 | Microsoft Learn | Okta Help Center | 1Password Support | Junify の製品ページ | 誰が使ったかは、ログインの手前の仕組みの記録で残します。Usage & insights のレポートでサインインのデータを見るには、Entra ID P1 または P2 の契約プランが要ります。Okta の SWA に必要な契約プランは、確認した公式ヘルプには書かれていません。 ## どれを選ぶか 使う人が全員 ID 管理サービスにアカウントを持ち、記録が「誰がいつアプリに入ったか」で足りるなら、①か②で済みます。すでに Okta や Entra ID があるなら、追加のツールは要りません。ID 管理サービスがある会社で残る場面は[Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins)にまとめています。 パスワードを見てよい人だけで使うなら、③で配布と保管が整います。ただし、見た人はパスワードを知る状態になるため、担当が終わればサービス側のパスワードを変える作業が残ります。 ID 管理サービスにアカウントを作らない人(委託先、短期の担当者)が使う場合は、④が候補になります。誰がいつ使ったかを本人ごとに残したいのに①②が使えない場合も同じです。方法ごとの詳しい違いは[共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods)にあります。 ## 4 つの方法に共通して残ること どの方法でも、サービス側のパスワードはなくならず、サービス側の記録に残るのは共有アカウントの名前です。パスワードそのものをなくす方式との違いは[パスワードレスとは](/guides/access-basics/what-is-passwordless)にまとめています。サービス側で二段階認証を必須にしている場合、そのコードを誰が受け取るかは別に決めます。Entra ID と Okta の公式ドキュメントは、対象アプリ側の二段階認証のコードの扱いを明示していません。共有アカウントの二段階認証の考え方は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にあります。 ## よくある質問 **SAML に対応しない SaaS でも SSO はできますか** 本人確認の結果を受け取る形の SSO はできません。Microsoft と Okta は、預かった ID とパスワードをログイン画面に代わりに入力する機能を別に用意しており、利用者から見ると一度のログインで入れます。 **Entra ID の代理入力に必要なものは何ですか** サインイン画面が HTML のアプリと、Edge か Chrome の My Apps 拡張機能です。前提条件に契約プランの指定はなく、共有アカウントでは人ごとに EMS か Entra ID P1/P2 が要ります。 **パスワードマネージャーで共有すれば担当者は知りませんか** 見る権限があれば見えます。1Password Teams の閲覧権限は隠されたパスワードの表示を含み、Business では表示とコピーを別の権限にできます。知らせない前提には向きません。 **委託先や短期の担当者にも使えますか** ID 管理サービスの代理入力は、そこにアカウントのある人が対象です。アカウントを作らない人には、パスワードマネージャーの共有か、パスワードを見せずに代わりに入力する仕組みが候補になります。 ## 参考資料 - [Microsoft Learn「What is single sign-on in Microsoft Entra ID?」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [Microsoft Learn「Usage and insights report - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-usage-insights-report) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「Reveal the password of an app integration」](https://help.okta.com/oie/en-us/Content/Topics/Apps/Apps_Revealing_the_Password.htm) - [Okta Help Center「Okta Browser Plugin」](https://help.okta.com/en-us/content/topics/browser-plugin/browser-plugin-main.htm) - [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm) - [Okta Help Center「Unassign users from applications」](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-unassign-apps.htm) - [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/) - [1Password Support「Create reports」](https://support.1password.com/reports/) - [1Password Support「Get to know 1Password in your browser」](https://support.1password.com/getting-started-browser/) - [Junify の仕組み](https://www.junify.jp/product) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は 4 つ目の「パスワードを見せずに代わりに入力する仕組み」に当たります。管理者が ID とパスワードを登録して担当者に割り当て、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。ID 管理サービスにアカウントのない人も使え、誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # IdP(ID 管理サービス)とは IdP(ID 管理サービス)とは、社員の ID を一か所で保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。Okta や Microsoft Entra ID が代表です。 更新日: 2026-09-18 IdP(ID 管理サービス)とは、社員の ID を一か所で作って保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。 ## ID 管理サービスとは何か IdP は Identity Provider の略です。Okta の開発者向けドキュメントは、IdP を、ID の情報を作って保ち、アプリに本人確認の働きを提供するサービスと定義しています。Microsoft の公式ドキュメントは、Microsoft Entra ID を、クラウドで動く ID とアクセスの管理サービスと説明しています。利用者・端末・アプリに対して、本人確認と設定の適用を行うものです。 ## 何を受け持つのか 受け持つ働きは 4 つです。一つ目は ID の台帳で、社員のアカウント、所属グループ、属性(部署や役職などの情報)を一か所に保ちます。人事のアプリや社内のディレクトリ(社員の一覧を持つ仕組み)から取り込めると、Okta の公式ヘルプが説明しています。残る 3 つは、Microsoft の公式ドキュメントにあります。ログイン時に本人を確かめてその結果をアプリに伝えること、サービスごとに使ってよい利用者やグループを設定すること、SAML(ID 管理サービスとつなぐための規格)などで本人確認の結果をサービスに伝えることです。 Okta の公式ヘルプは、利用者台帳(Universal Directory)について説明しています。アプリやディレクトリ、人事のアプリなどから取り込んだ利用者と属性(部署や役職などの情報)を保てる、としています。利用者のプロファイル(利用者ごとの情報)で、アプリと端末へのアクセスとグループの所属を管理します。Microsoft は、Microsoft 365 や Azure の契約者はすでに Microsoft Entra ID を使っていると書いています。ID 管理サービスの本人確認をもとに複数のサービスへ入る働きが[SSO(シングルサインオン)](/guides/access-basics/what-is-sso)です。 ## 受け持たないのは何か ID 管理サービスの本人確認の結果を受け取れるのは、SAML などの規格に対応したサービスだけです。対応しないサービスに対しては、Microsoft も Okta も、預かった ID とパスワードをログイン画面に代わりに入力する機能を別に用意しています。Entra ID の password-based SSO と Okta の SWA です。この機能を使えるのは、ID 管理サービスにアカウントのある人です。短期の担当者や委託先など、ID 管理サービスにアカウントを作らない人には届きません。複数人で使う共有アカウントも、一人ひとりの ID を前提にする SSO の形には収まらず、代わりに入力する機能で扱うことになります。 ## 導入していれば済むのか ID 管理サービスがあれば、社員の ID の台帳、本人確認、つながるサービスへのログインはそこで済みます。残るのは、つながらないサービス、1 つしか作れない管理者アカウント、ID 管理サービスにいない人です。これらの整理は[Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins)にまとめています。 ## よくある質問 **IdP と SSO は同じものですか** 違います。IdP は社員の ID と本人確認を受け持つ仕組みで、SSO はその確認をもとに複数のサービスへログインし直さずに入る働きです。SSO は IdP が提供する機能の一つです。 **Microsoft 365 を使っていれば IdP はありますか** あります。Microsoft の公式ドキュメントは、Microsoft 365 や Azure の契約者は Microsoft Entra ID をすでに使っていると説明しています。 **IdP を入れれば SaaS のアカウント管理は済みますか** SAML などでつながるサービスと、IdP にアカウントのある人の分は済みます。つながらないサービスには代わりに入力する機能、IdP にいない人と共有アカウントには別の決め方が残ります。 ## 参考資料 - [Okta Developer「Identity Providers」](https://developer.okta.com/docs/concepts/identity-providers/) - [Okta Help Center「Users, groups, and profiles」](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-main.htm) - [Microsoft Learn「What is Microsoft Entra?」](https://learn.microsoft.com/en-us/entra/fundamentals/what-is-entra) - [Microsoft Learn「What is single sign-on in Microsoft Entra ID?」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は ID 管理サービスを置き換えません。Junify への本人確認を Okta や Entra ID のログインに任せ、その先にある、SAML につながらないサービスと共有アカウントの分だけを Junify が受け持つ形にできます。ID 管理サービスにアカウントのない人は、自分のスマホの Junify アプリで本人確認をします。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # 最小権限の原則とは 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。NIST が設計の原則として定義し、IPA も ID の割り当てを必要最小限にするよう勧めています。 更新日: 2026-09-18 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。 ## 最小権限の原則とは何か 米国 NIST(国立標準技術研究所)の用語集は、SP 800-53 Revision 5 の定義を載せています。人やプログラムに、その働きを果たすために必要な最小限のシステムの機能やデータと権限だけを与えるように、安全の仕組みを設計する原則です。CNSSI 4009 は、米国の国家安全保障システム委員会の用語集です。その定義では、利用者のアクセス権限を、割り当てられた作業を果たすのに必要な最小限に制限する原則としています。利用者の代わりに動く処理も同じ扱いです。英語では principle of least privilege と呼びます。権限とは、ここでは、読める・書ける・設定を変えられる・他の人の権限を変えられるといった、アカウントにできることの範囲です。 ## 公的な文書は何を求めているか IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、ユーザー ID と管理者 ID の発行から削除までの手続を定め、必要最小限の割り当てにすることを勧めています。共有 ID はなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みを整えることも、同じ項目で勧めています。同じ節の「アクセス権の管理ルールを定める」の項目は、理由として 2 つを挙げています。従業員の異動や退職に伴う権限の変更・削除漏れと、特定の役職員への権限の集中による不正利用や権限の濫用です。NIST SP 800-207(ゼロトラストの文書)は、アクセスを利用のたびに、その作業に必要な最小の権限で許すことを基本原則の一つにしています。 ## SaaS のアカウントに当てはめるとどうなるか SaaS(インターネット経由で使う業務ソフト)の権限を、この記事では 3 つの単位に分けて見ます。 1. 権限の種類で絞ります。全体の管理者ではなく、作業に要る権限の種類だけを与えます。投稿はできるが支払いの設定は変えられない、という形です。 2. 期間で絞ります。担当の間だけ与え、終われば外します。委託の契約が終わった日に外す、という形です。 3. 人で絞ります。共有ではなく一人ひとりの ID にし、誰が使ったかを残します。一つのアカウントを部署全員で使わない、という形です。 共有アカウントでは、この 3 つ目が成り立ちません。一組の ID とパスワードを知る人は全員が同じ権限を持ち、人ごとに絞れないためです。権限の種類を分けられないサービスや、1 つしか作れない管理者アカウントでは、IPA が勧める「使った人を特定できる仕組み」で補います。管理者用アカウントの扱いは[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)に、共有アカウントの方法は[共有アカウントの管理](/guides/shared-accounts)にまとめています。 ## 何から確かめるか サービスごとに、いま誰がどの権限を持っているかを一覧にし、その人の作業に要るかを一人ずつ見ます。要らない権限は外し、担当が終わった人は削除します。IPA のガイドラインが手続として勧めているのは、この発行から削除までの流れを決めて、決めたとおりに運用することです。 ## よくある質問 **最小権限の原則はどこに書かれていますか** 米国 NIST の SP 800-53 などが定義し、NIST の用語集にまとめられています。日本では IPA の中小企業向けガイドラインが、ID の割り当てを必要最小限にするよう勧めています。 **管理者権限を全員に渡すと何が起きますか** IPA のガイドラインは、特定の人への権限の集中による不正利用や権限の濫用と、異動・退職に伴う権限の変更・削除漏れを、防ぐべき被害として挙げています。 **共有アカウントでも最小権限は守れますか** 共有アカウントの権限は使う人全員に同じだけ渡るため、人ごとに絞れません。IPA は共有 ID をなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みを勧めています。 **ゼロトラストと最小権限は関係がありますか** あります。NIST SP 800-207 は、アクセスをその作業に必要な最小の権限で、利用のたびに許すことをゼロトラストの基本原則の一つに挙げています。 ## 参考資料 - [NIST Computer Security Resource Center Glossary「least privilege」](https://csrc.nist.gov/glossary/term/least_privilege) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-207「Zero Trust Architecture」](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify では、管理者がアカウントごとに使ってよい担当者を決め(割り当て)、担当が終わればその場で外します。担当者はパスワードを知らないため、外した後にログインできる状態は残りません。誰が・いつ・どのアカウントを使ったかは一人ひとり残るので、共有アカウントでも権限の見直しに使えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # 多要素認証(MFA)とは 多要素認証とは、知っているもの(パスワード)、持っているもの(スマホや IC カード)、本人自身(指紋や顔)の 3 種類のうち 2 つ以上でログイン時に本人を確かめる方式です。パスワードが漏れてもすぐには入られないようにします。 更新日: 2026-10-13 多要素認証(MFA)とは、種類の異なる 2 つ以上の要素を使って、ログイン時に本人を確かめる方式です。 ## 多要素認証とは何か IPA の不正ログイン対策のページは、多要素認証をこう説明しています。 > 認証の際、複数の要素（記憶情報、所持情報、生体情報のうち2つ以上）を用いた方式は「多要素認証」と呼ばれることもあります。 記憶情報、所持情報、生体情報は、順に、覚えているもの、手元に持っているもの、体の特徴です。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、多要素認証を「サービス利用時に行う利用者認証を、３つの要素（①知っているもの②持っているもの③本人自身に関するもの）のうち、２つ以上の要素を用いて行う技術」としています。 米国 NIST の SP 800-63-4 も、多要素認証を「複数の異なる要素を使うこと」と定義しています。一つの要素だけの認証はたいてい「知っているもの」だ、とも書いています。英語の Multi-Factor Authentication を略して MFA と呼びます。 ## 要素にはどんな種類があるか 要素は 3 つに分かれます。 - 知っているもの(知識情報)は、本人だけが覚えている情報です。パスワード、秘密の質問、PIN(暗証番号)がこれに当たります。 - 持っているもの(所持情報)は、本人だけが手元に持つものです。IC カード、SMS が届く電話、認証アプリ(使い捨てのコードを表示するアプリ)の入ったスマホ、セキュリティキー(USB などで挿す小さな鍵の装置)がこれに当たります。 - 本人自身(生体情報)は、体の特徴です。顔や指紋がこれに当たります。 例は IPA のガイドラインの図と NIST の記述によります。NIST SP 800-63-4 は、同じ要素を複数使っても 1 つの要素の認証のままだとし、利用者が決めた PIN とパスワードは両方「知っているもの」なので 2 要素にならない、と例を挙げています。NIST SP 800-63B(Revision 4、2025 年 7 月)は、生体情報は「持っているもの」と組み合わせた多要素認証の一部としてだけ使うものとしています。二段階認証との呼び分けと、方式ごとの強さは[二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification)にまとめています。 ## なぜ求められるのか パスワードだけの認証は、パスワードが漏れればすぐに他人がログインできます。総務省の「テレワークセキュリティガイドライン」第 5 版は、クラウドサービスの特徴を挙げています。不特定多数がアクセスでき、利用手順も知られているため、ID とパスワードが流出すると不正アクセスを受けやすい、という説明です。そのうえで、ID とパスワードが漏れてもただちに不正アクセスを受けないように、可能な限り多要素認証を使うよう求めています。管理者向けの基本対策には「可能な限り多要素認証を強制する」が挙がっています。IPA のガイドラインも、多要素認証を、対策をより強くする技術の一つとして説明しています。 ## 共有アカウントではどうなるか 2 つ目の要素は、本人だけが持つことを前提にしています。NIST SP 800-63B は、利用者が自分の認証の秘密を他人に渡さない責任を負うとし、各水準の保護は盗難に備えるもので、本人が進んで渡す場合を防ぐものではないと書いています。複数人で一つのアカウントを使い、認証アプリやコードの届く電話を共有すると、2 つ目の要素は「本人」ではなく「共有された誰か」を示すことになり、誰が使ったかを区別できなくなります。その場合の選択肢は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にまとめています。 ## よくある質問 **二段階認証と多要素認証は同じですか** 多要素認証は、種類の異なる要素を 2 つ以上使う方式です。IPA は、認証を多段で行う「多段階認証」と多要素認証を書き分けています。 **パスワードと秘密の質問を組み合わせれば多要素認証ですか** なりません。どちらも「知っているもの」で、同じ種類の要素だからです。NIST は、PIN とパスワードは 2 要素にならないと例を挙げています。 **多要素認証は必ず設定しないといけませんか** 総務省のテレワークセキュリティガイドラインは、管理者の基本対策として「可能な限り多要素認証を強制する」を挙げています。ID とパスワードが漏れてもただちに不正アクセスを受けないようにするためです。 **共有アカウントの多要素認証はどうなりますか** 2 つ目の要素は本人だけが持つものが前提です。NIST は利用者が認証の秘密を他人に渡さないことを前提にしており、複数人で共有すると誰が使ったかを示せなくなります。 ## 参考資料 - [IPA「不正ログイン対策特集ページ」](https://www.ipa.go.jp/security/anshin/measures/account_security.html) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-63-4「Digital Identity Guidelines」](https://pages.nist.gov/800-63-4/sp800-63.html) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify では、担当者が自分のスマホの Junify アプリでパソコンの画面の QR を読み取り、本人確認をしてから共有アカウントを開きます。サービス側の多要素認証が認証アプリにコードを出す方式なら、そのコードも Junify が入力し、誰が使ったかは一人ひとり残ります。SMS やメールで届くコードは対象外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # パスワードレスとは パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。パスキー(FIDO)が代表です。パスワードを見せずに代わりに入力する方式は、パスワードが残るので別の仕組みです。 更新日: 2026-09-18 パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。 ## パスワードレスとは何か FIDO(ファイド)の規格にもとづくパスキーが代表です。パスワードという秘密そのものを持たず、端末の中の鍵で本人を証明します。 これと混同されやすいのが、サービス側のパスワードは残したまま、仕組みが利用者に代わって入力する方式です。ID 管理サービス(Okta や Microsoft Entra ID など、社員の ID を一か所で管理する仕組み)がパスワードを代わりに入力する機能や、パスワードを見せずに代わりに入力するツールがこれに当たります。利用者が入力しない点は似ていますが、パスワードが残るので別の仕組みです。 ## パスキー(FIDO)はどう働くか FIDO Alliance は、FIDO の規格を作る業界団体です。この団体は、パスキーを FIDO の規格にもとづくログインの資格と定義しています。置き場所は、スマホやパソコン、セキュリティキー(USB などで挿す小さな鍵の装置)です。Microsoft の公式ドキュメントによれば、秘密の鍵は利用者の端末に、対になる公開の鍵はログイン先のサイトに置かれます。両方がそろって初めてログインできます。この鍵の組み合わせは作ったサイト専用なので、パスキーは作成したサイトやアプリでしか働きません。利用者は、端末のロック解除と同じ操作(指紋、顔、PIN)で秘密の鍵を使います。偽サイトに誘導されても、そのサイト用の鍵はありません。打ち込む秘密がないので、パスワードのように盗まれません。Google アカウントのヘルプも、パスキーをパスワードに代わるログイン手段とし、フィッシング(偽サイトにだます手口)への保護を強くできると書いています。 パスキーには 2 種類あります。Microsoft のドキュメントによれば、端末に結びついたパスキーは、秘密の鍵が一つの端末から出ません。同期される(別の端末でも同じ鍵を使えるようにそろえる)パスキーは、Apple の iCloud キーチェーンや Google パスワードマネージャーのように、同じ提供元で認証した別の端末でも使えます。 ## 代わりに入力する方式とどう違うか | 観点 | パスキー(FIDO) | 代わりに入力する方式 | | --- | --- | --- | | パスワードはあるか | ない。端末の鍵で証明する | サービス側にある。利用者に見せないだけ | | サービス側の対応 | サービスがパスキーに対応している必要がある | ログイン画面があれば使える | | 偽サイトへの強さ | 鍵が作ったサイト専用なので働かない | 自分で打ち込むことはないが、NIST が言う偽サイトに強い方式には当たらない | | 共有アカウント | 登録した端末の持ち主が前提 | 一組のパスワードを複数人の代わりに入力できる | 代わりに入力する方式では、利用者はパスワードを知らないので、偽サイトに自分で打ち込むことはできません。NIST SP 800-63B が言う「偽サイトに強い方式」は、利用者の注意深さに頼らずに、偽の相手へ秘密や本人確認の結果を渡さない仕組みを指します。サービス側の認証はパスワードのままなので、これには当たりません。仕組みがどのログイン画面に入力するかは、製品の公式ドキュメントで確かめます。 Microsoft と Okta がこの方式を何と呼び、どのアプリで使えるかは[SAML に対応していない SaaS に SSO に近い運用を作る方法](/guides/access-basics/sso-like-operation-for-non-saml-saas)にまとめています。 ## どちらを選ぶか サービスがパスキーに対応していて、一人一つのアカウントで使うなら、パスキーはパスワードを持たない分、漏えいの心配がなくなります。対応していないサービスや、複数人で使うアカウントでは、パスワードは残ります。方法の全体は[SaaS のログインを会社が管理する方法の全体像](/guides/access-basics)にまとめています。 ## よくある質問 **パスキーとは何ですか** FIDO Alliance は、FIDO の規格にもとづくログインの資格で、スマホやパソコン、セキュリティキーに保存できるものと定義しています。端末のロック解除と同じ操作(指紋、顔、PIN)でログインします。 **パスキーはなぜ偽サイトに強いのですか** 鍵の組み合わせが作ったサイト専用で、そのサイトでしか使えないためです。Microsoft の公式ドキュメントは、パスキーは作成したサイトやアプリでしか働かないと説明しています。 **代わりに入力する方式はパスワードレスですか** 利用者は入力しませんが、パスワードはサービス側に残り、いつもどおり確認されます。パスワードをなくす方式とは別の仕組みなので、この記事では分けて扱っています。 **共有アカウントにパスキーは使えますか** パスキーは登録した端末か、同じ提供元でそろえた別の端末にしかありません。複数人で使うアカウントでは、誰の端末に登録するかを決める必要があります。 ## 参考資料 - [FIDO Alliance「Passkeys」](https://fidoalliance.org/passkeys/) - [Microsoft Learn「Passkeys (FIDO2) authentication method in Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2) - [Google アカウント ヘルプ「パスキーでログインする」](https://support.google.com/accounts/answer/13548313?hl=ja) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は、パスワードそのものをなくす方式ではなく、パスワードを担当者に見せずに代わりに入力する方式です。管理者が登録した ID とパスワードを、担当者が自分のスマホで本人確認をしたあとに Junify が入力します。パスキーに対応していない SaaS や共有アカウントでも、担当者はパスワードを知らずに使えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # セッション録画(画面操作の記録)とは セッション録画とは、ログインしてから終えるまでの利用を、画面の映像や入力した文字として残す仕組みです。何が残り何が残らないかは製品ごとに違い、本人への明示も要ります。 更新日: 2026-09-18 セッション録画とは、ログインしてから終えるまでの一続きの利用(セッション)について、画面や操作を記録として残す仕組みです。 ## セッション録画とは何か セッションとは、ログインしてから終えるまでの一続きの利用のことです。その間に画面に映ったものや、利用者が入力したものを、あとから見返せる形で保存するのがセッション録画です。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、特権 ID 管理を、特権の利用申請や権限付与、操作ログ(誰がどんな操作をしたかの記録)などを管理する技術と説明しています。セッション録画は、この操作の記録を、画面や入力の単位で残す方法の一つです。 ## 何が残るのか 残し方は 3 つに分かれます。 - 画面の映像として残す方式です。画面に映ったものを動画で残します。Azure Bastion は、仮想マシン(クラウド上のサーバー)を遠隔で操作する接続の画面を録画します。Teleport(サーバーやアプリへの接続を仲介する製品)は、デスクトップの画面とマウスの動きを記録します。 - 入力した文字と結果を残す方式です。打ち込んだ命令と、その出力を文字で残します。AWS Systems Manager の Session Manager は、セッション中に入力した命令とその出力を記録します。 - 出来事の一覧として残す方式です。何にいつアクセスしたかを、短い記録の列で残します。Teleport は、Web アプリの利用を、アクセスの出来事の流れとして記録します。 ## 何が残らないのか 大事な点は 2 つです。録画は、その仕組みを通った利用しか記録しません。そして、文字で残す方式では、打ち込んだ秘密もそのまま残ります。 製品ごとの限界も公式ドキュメントに書かれています。Azure Bastion の録画は Premium の契約プランでだけ使え、専用クライアントからの接続では使えません。AWS の Session Manager は、通り道になるだけの接続(ポート転送や SSH)を記録できません。Teleport は、デスクトップの録画でキー入力を記録しません。AWS は、パスワードなど秘密の情報が記録に残るため、画面に表示しない命令を使うよう勧めています。 ## 誰が見られるのか 録画の保存先と閲覧の権限は、録画の仕組みとは別に決めます。Azure Bastion では、録画は自社の保存領域(ストレージアカウント)に置かれ、一覧と再生には、その保存領域の読み取りの権限が要ります。閲覧できる人を絞れるかは、製品ごとに公式ドキュメントで確かめます。 ## 本人に知らせる必要はあるか 個人情報保護委員会の Q&A(Q5-7)は、従業者の監督の一環として行うビデオやオンラインでのモニタリング(監視)について、4 つの点に留意するよう求めています。目的をあらかじめ特定し、社内規程などに定めて従業者に明示すること。実施の責任者と権限を定めること。実施のルールをあらかじめ作り、運用する人に徹底すること。ルールどおりに適正に行われているかを確認すること。労働組合などへの事前の通知や、従業者への周知も望ましいとしています。画面の録画を始める前に、この 4 点を社内の決まりとして持っておくことになります。 ## よくある質問 **セッション録画は動画ですか** 方式によります。Azure Bastion は画面の映像を記録し、AWS の Session Manager は入力した命令とその結果を文字で記録します。Teleport はデスクトップの画面とマウスの動きを記録します。 **録画を見られるのは誰ですか** 保存先と閲覧の権限で決まります。Azure Bastion では、録画は自社の保存領域に置かれ、一覧と再生には保存領域の読み取り権限が要ります。 **従業員の画面を記録するとき、何を決めますか** 個人情報保護委員会の Q&A は、目的を社内規程に定めて従業員に明示すること、責任者と権限、実施のルール、ルールどおりに行われているかの確認を挙げています。 ## 参考資料 - [Microsoft Learn「Record Bastion sessions - Azure Bastion」](https://learn.microsoft.com/en-us/azure/bastion/session-recording) - [AWS Systems Manager ユーザーガイド「Enabling and disabling session logging」](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-logging.html) - [Teleport Docs「Session Recording」](https://goteleport.com/docs/reference/architecture/session-recording/) - [個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関する Q&A」Q5-7](https://www.ppc.go.jp/all_faq_index/faq1-q5-7/) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify の録画は、必要なアカウントにだけ設定します。動画ではなく画面の差分として保存するので軽く、長く残せます。録画が始まる前に本人の画面に表示され、見られるのは本人と管理者だけです。担当者はスマホで本人確認をしてから使うため、録画は共有アカウントでも一人ひとりに結びつきます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # SSO(シングルサインオン)とは SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。ID 管理サービスと SAML などの規格でつながるサービスにだけ使え、つながらないサービスには別の方法が要ります。 更新日: 2026-09-18 SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。 ## SSO とは何か Microsoft の公式ドキュメントは、SSO を、ユーザーが一度サインインすれば多くのアプリに入れる仕組みと説明しています。本人確認を引き受けるのは ID 管理サービス(Okta や Microsoft Entra ID など、社員の ID を一か所で管理する仕組み)です。ID 管理サービスが本人を確かめ、その結果をアプリに伝えるため、アプリは自分でユーザー名とパスワードを管理しなくてよくなります。ID 管理サービスの働きは[IdP(ID 管理サービス)とは](/guides/access-basics/what-is-idp)にまとめています。 ## なぜ対応するサービスにだけ使えるのか SSO では、アプリがパスワードを確かめる代わりに、ID 管理サービスからの「この人は本人です」という知らせを受け取ってログインさせます。Microsoft のドキュメントは、この流れを 4 つの段階で説明しています。利用者がアプリを開く、アプリが利用者を ID 管理サービスへ送る、ID 管理サービスが本人を確かめる、アプリが確認の結果を受け取ってアクセスを許す、という順です。この知らせをやり取りする決まりが、SAML(ID 管理サービスとつなぐための規格)や OpenID Connect(同じ目的の新しい規格)です。アプリ側がこの決まりに沿って作られていなければ、知らせを受け取れません。 ## 対応していないサービスはどうなるか 対応していないサービスに対して、ID 管理サービスは別の機能を用意しています。Microsoft の password-based SSO は、ユーザー名とパスワードでサインインするアプリ向けに、Entra ID が ID とパスワードを保管してアプリに送る方式です。ブラウザーで開くログイン画面があるクラウドのアプリで使え、管理者が利用者やグループのために ID とパスワードを設定できます。Okta の SWA(Secure Web Authentication)は、SAML などに対応しない外部の Web アプリに SSO の働きを与える技術です。Okta が利用者ごとに外部アプリにサインインする、と説明されています。どちらも、サービス側のパスワードの確認はそのまま残ります。 | 方式 | サービス側で何が起きるか | 使える条件 | | --- | --- | --- | | SAML などによる SSO | ID 管理サービスからの本人確認の結果を受け取る | サービスが規格に対応している | | 代わりに入力する方式(password-based SSO、SWA) | 預かったパスワードでいつもどおりログインする | サービスにログイン画面がある | | リンクだけ(Microsoft の Linked SSO、Okta の Bookmark) | ログイン画面が開くだけで、SSO は行われない | 移行の途中で、まず一覧に並べたいとき | ## 共有アカウントは SSO で扱えるか SAML などによる SSO は、ID 管理サービスにある一人ひとりの ID が前提です。複数人で一つのアカウントを使う共有アカウントは、この形に収まりません。Okta の公式ヘルプは、SWA の設定の一つに、管理者が設定した一組のユーザー名とパスワードを利用者が共有する形を挙げています。共有アカウントを ID 管理サービスで扱うときは、SSO ではなく、この代わりに入力する方式になります。共有アカウントの管理方法の全体は[共有アカウントの管理](/guides/shared-accounts)にまとめています。 ## よくある質問 **SSO はどのサービスでも使えますか** 使えません。Microsoft と Okta の公式ドキュメントは、SAML などの規格に対応するアプリを対象にしています。対応しないアプリには、パスワードを代わりに入力する別の機能を用意しています。 **SSO を入れるとパスワードはなくなりますか** つながるサービスでは、サービスごとのパスワードを覚える必要がなくなります。ID 管理サービスへのログインは残り、つながらないサービスのパスワードも残ります。 **共有アカウントは SSO で扱えますか** SAML でのログインは一人ひとりの ID が前提です。共有アカウントは、Okta の SWA のように、管理者が設定した一組の ID とパスワードを複数人で使う代理入力の形で扱います。 **パスワードを代わりに入力する方式は SSO ですか** Microsoft は password-based SSO、Okta は SWA と呼び、SSO の選択肢の一つに置いています。ただし本人確認の結果を伝える方式ではなく、サービス側のパスワードの確認はそのまま残ります。 ## 参考資料 - [Microsoft Learn「What is single sign-on in Microsoft Entra ID?」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on) - [Microsoft Learn「Add password-based single sign-on to an application - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications) - [Okta Help Center「Configure Single Sign-On options」](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm) - [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify は SSO の代わりではありません。SSO につながらないサービスと共有アカウントについて、管理者が登録した ID とパスワードを、担当者に見せずに Junify が入力します。担当者は自分のスマホで本人確認をしてクリックするだけで、誰が・いつ使ったかは一人ひとり残ります。本人確認を ID 管理サービスのログインで行うこともできます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # ゼロトラストとは ゼロトラストとは、社内ネットワークにいるからといって信頼せず、利用のたびに利用者と端末を確かめてから最小限のアクセスを許す考え方です。NIST SP 800-207 が定義し、総務省は「決して信頼せず、必ず確認せよ」と言い表しています。 更新日: 2026-09-18 ゼロトラストとは、社内ネットワークの中にいるからといって信頼せず、利用のたびに利用者と端末を確かめてから、必要な最小限のアクセスを許す考え方です。 ## ゼロトラストとは何か 米国 NIST の SP 800-207「Zero Trust Architecture」(2020 年 8 月)は、ゼロトラストを次のように定義しています。侵害されているとみなしたネットワークの中で、要求ごとに正確で最小権限のアクセスの判断を行うときの不確かさを最小にするために設計された、概念と考え方の集まりです。物理的な場所やネットワーク上の場所だけを理由に、資産や利用者のアカウントを暗黙に信頼しないとも書いています。総務省の「テレワークセキュリティガイドライン」第 5 版は、従来の境界型セキュリティの前提を「信ぜよ、されど確認せよ」とすると、ゼロトラストは「決して信頼せず、必ず確認せよ」だと言い表しています。 ## 境界型セキュリティと何が違うか | 観点 | 境界型セキュリティ | ゼロトラスト | | --- | --- | --- | | 前提 | 内側には信頼できるものだけがある | 内側にも脅威があり、内も外も区別なく確かめる | | 守る中心 | ネットワーク | データや機器などの資源 | | 場所の扱い | 社内からのアクセスは信頼する | 社内からでも社外と同じ条件を満たす | 総務省は、クラウドサービスの普及と私物端末の利用が進み、特定の拠点を守る境界型だけでは対応が難しくなったと背景を説明しています。同時に、ゼロトラストは境界型に代わるものではなく、両者を組み合わせて守ることが期待されるとしています。 ## NIST の基本原則は何か SP 800-207 の 2.1 節は、7 つの基本原則を挙げています。 1. すべてのデータとサービスを、守る対象(資源)とみなす。私物端末も、会社の資源にアクセスするなら対象に含めてよい 2. ネットワーク上の場所にかかわらず、すべての通信を守る。社内からのアクセスも社外と同じ条件を満たす 3. アクセスは利用のたびに、その作業に必要な最小の権限で許す。一つの資源への許可は別の資源に自動では及ばない 4. アクセスの可否は、利用者の身元、アプリ、端末の状態などをもとにした動的なルールで決める 5. 会社が持つ端末や関係する端末の安全の状態を監視し、測る 6. 本人確認と許可は動的で、アクセスを許す前に厳密に行う。多要素認証の利用を含む 7. 資産・ネットワーク・通信の状態をできるだけ集め、守り方の改善に使う NIST は、これらは理想の目標であり、すべてを純粋な形で行えるとは限らないと断っています。特定の技術によらない原則で、利用者の確認はパスワード、証明書、使い捨てのコードなど複数の方法があり得るとも書いています。 ## アカウント管理とどう関係するか 原則の 3 と 6 が、SaaS のアカウント管理に直接関わります。利用のたびに本人を確かめ、その作業に要る最小限の権限だけを許し、一つのサービスへのログインが別のサービスへの許可に自動で及ばない形です。共有アカウントで一組の ID とパスワードを複数人が知っている状態では、原則 3 が前提にする「要求している人を確かめる」ことができません。最小権限の考え方は[最小権限の原則とは](/guides/access-basics/what-is-least-privilege)に、多要素認証は[多要素認証(MFA)とは](/guides/access-basics/what-is-mfa)にまとめています。 ## よくある質問 **ゼロトラストは製品の名前ですか** 違います。NIST SP 800-207 は、ゼロトラストを概念と考え方の集まりと定義し、基本原則は特定の技術によらないとしています。総務省も、境界型の防御に代わるものではなく組み合わせるものと説明しています。 **社内ネットワークにいれば安全ではないのですか** ゼロトラストは、社内にいることを信頼の理由にしません。NIST は、社内のネットワークからのアクセスも、社外からと同じ条件を満たすべきだとしています。 **ゼロトラストでアカウント管理は何が変わりますか** 利用のたびに本人と端末を確かめ、その作業に要る最小限の権限だけを許す形になります。NIST は多要素認証の利用と、一つの資源への許可が別の資源に自動で及ばないことを挙げています。 **中小企業にもゼロトラストは関係がありますか** 総務省のガイドラインは、クラウドサービスの普及と私物端末の利用で、拠点を守る境界型だけでは対応が難しくなったと説明しています。テレワークと SaaS を使う会社に当てはまる説明です。 ## 参考資料 - [NIST Special Publication 800-207「Zero Trust Architecture」](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf) - [NIST Computer Security Resource Center「SP 800-207 Zero Trust Architecture」](https://csrc.nist.gov/pubs/sp/800/207/final) - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) ## Junify の場合 **人手で続けると** SSO や多要素認証を入れても、対応していないサービスと共有のまま残るアカウントは手作業に残り、どこまでを仕組みで覆えているかを自分で把握し続けることになります。 **Junify なら** Junify が担うのは、SaaS のログインのうち、ID 管理サービスにつながらないサービスと共有アカウントの部分です。担当者は使う前に自分のスマホで本人確認をし、管理者が決めたアカウントだけを開けます。パスワードは担当者に渡らず、誰が・いつ使ったかは一人ひとり残ります。私物のパソコンに入れるのは、ブラウザーの拡張機能だけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。 - [ブラウザーの拡張機能でできるアクセス管理の範囲](/guides/access-basics/browser-extension-access-control-scope): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。 - [私物端末(BYOD)で業務システムを使わせるときの選択肢](/guides/access-basics/byod-options-mdm-vdi-browser): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。 --- # 法令・ガイドラインとアカウント管理 法令や公的な指針がアカウントの管理に求めることは、誰が使ったか分かる・権限は必要最小限・退職や契約終了で止める・委託先を確かめる、の 4 点にまとまります。 更新日: 2026-09-18 アカウントの管理について、法令と公的なガイドラインが求めることは、文書ごとに言葉は違っても中身は重なっています。誰がそのアカウントを使ったか分かることと、権限を必要最小限にすることです。そして、退職や契約終了のときにアクセスを止めることと、委託先の管理を確かめることです。まず、どの文書が自社に当てはまるかを見分けます。 ## どの文書が自社に当てはまるか 法律は、当てはまる事業者に義務を課します。ガイドラインは法律の解釈を示すか、対策の手引きとして参考にするもので、それ自体に罰則はありません。認証は、取るかどうかを自社で決めます。 | 文書 | 何の文書か | 誰に当てはまるか | アカウント管理について求めること | | --- | --- | --- | --- | | 個人情報保護法 23〜25 条と通則編 | 法律と、個人情報保護委員会の解釈指針 | 個人情報データベース等を事業に使う事業者 | 個人データの安全管理措置、従業者の監督、委託先の監督 | | ISO/IEC 27001(ISMS) | 情報セキュリティの管理の仕組みの国際規格。JIPDEC の制度で第三者が審査する | 認証を取る組織。あらゆる形態・規模の組織に適用できることを意図した規格 | 附属書 A(規格の末尾に付いた管理策の一覧)の 93 の管理策から必要なものを選び、運用する | | プライバシーマーク(JIS Q 15001) | 個人情報保護の仕組みの国内規格と、JIPDEC の付与制度 | 国内に活動拠点を持つ事業者。法人単位で、有効期間は 2 年 | 安全管理措置、従業者の監督、委託先の監督。個人情報の台帳にアクセス権を持つ人を書く | | IPA 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版 | 対策の手引き | 中小企業・小規模事業者。想定読者は経営者と情報管理を統括する人 | ID の発行から削除までの手続、共有 ID を使う人の特定、異動・退職時の権限の変更・削除 | | 総務省 テレワークセキュリティガイドライン 第 5 版 | 対策の指針 | テレワークを行う組織の管理者・経営者・勤務者 | 多要素認証、異動・担当変更に合わせた不要なアカウントの削除、ログイン後の記録の取得 | | 経産省・IPA サイバーセキュリティ経営ガイドライン Ver 3.0 | 経営者向けの指針 | 大企業と中小企業(小規模事業者を除く)の経営者 | 委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化 | | 不正アクセス禁止法 | 法律 | すべての人。アクセス管理者には努力義務 | 他人の ID とパスワードで入る行為の禁止。管理者は識別符号の適正な管理に努める | ## 法律は何を義務づけているか 個人情報保護法 23 条は、個人データの「漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置」を義務づけています。情報が漏れたり消えたりしないための対策のことです。24 条は従業者への、25 条は委託先への「必要かつ適切な監督」(適切に扱っているか確かめること)を求めます。通則編の別添は、技術的な措置として「アクセス制御」と「アクセス者の識別と認証」を、講じなければならない措置に挙げています。内容は[安全管理措置とは](/guides/compliance/what-is-security-control-measures)にまとめています。 不正アクセス禁止法は、事業者ではなく行為を対象にした法律です。3 条は「何人も、不正アクセス行為をしてはならない」と定めます。不正アクセス行為の中心は、他人の識別符号を、管理者や本人の承諾なしに入力してシステムに入る行為です。識別符号とは、その人だけが使うことになっている ID とパスワードなどの符号です。5 条は、他人の識別符号を、その管理者と本人以外に提供する行為を、業務その他正当な理由がある場合を除いて禁じます。8 条は、アクセス管理者(システムを管理する側)に、識別符号の適正な管理などの防御措置に努めるよう求めています。 ## 認証や審査では何を見られるか ISMS は、情報を守るための方針と手順を組織として決め、運用し、見直す仕組みです。認証基準の JIS Q 27001(ISO/IEC 27001)は、本文の必須の要求事項と、附属書 A の 93 の管理策で構成されます。委託先との関係もその管理策に含まれます。詳しくは [ISMS とは](/guides/compliance/what-is-isms)に書きました。 プライバシーマークは、JIS Q 15001 に準拠した審査を経て、法人単位で付与される制度です。JIPDEC の構築・運用指針は、個人情報の台帳に「アクセス権を有する者」を書くことと、従業者を監督することを求めています。委託先については、選ぶ基準を決め、契約に安全管理の事項や報告の頻度を盛り込むことを求めています。 取引先から求められる報告書としては SOC 2 もあります。公認会計士がサービス提供会社の内部統制を検証したもので、アクセス権の付与と削除も見られます。内容は [SOC 2 とは](/guides/compliance/what-is-soc2)に、上場会社の内部統制報告で問われる範囲は [IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc)にまとめています。 ## 公的なガイドラインは何を勧めているか IPA の中小企業向けガイドラインは、ユーザー ID と管理者 ID の発行・変更・削除の手続を定め、ID を必要最小限にするよう勧めています。共有 ID はなるべく使わず、やむを得ず使う場合は、共有 ID を使った人を特定できる仕組みを整えて運用するよう求めています。異動や退職にともなう権限の変更・削除漏れを防ぐルールと、取引先との契約終了時にアクセス権を回収する手順も挙げています。経営者編の原則 2 は、委託先の不備で事故が起きても委託元の管理責任が問われるとして、委託先の対策まで考慮するよう求めます。 総務省のガイドラインは、対策を管理者・経営者・勤務者の立場ごとに分けています。管理者向けには、ログインで可能な限り多要素認証(パスワードに加えてもう 1 つの方法で本人を確かめること)を強制することを挙げます。異動や担当変更を把握して不要なアカウントを削除すること、ログイン後の認証ログや操作ログ(誰がいつ入り、何をしたかの記録)を取ることも求めています。勤務者向けには、パスワードなどの認証情報を無断で貸さないことを求めています。中小企業向けには、専任の担当者がいない組織を想定した別冊の手引きがあります。 経産省と IPA のサイバーセキュリティ経営ガイドラインは、経営者が認識すべき 3 原則と、担当幹部に指示すべき重要 10 項目で構成されます。指示 9 は、ビジネスパートナーやシステム管理の運用委託先を含めて対策状況を把握させること、契約で役割と責任範囲を明確にすることを求めています。経営者向けの指針なので、アカウントの操作手順までは書かれていません。 ## 共通する 4 つの要求 | 要求 | どの文書に出てくるか | 自社で確かめること | | --- | --- | --- | | 誰が使ったか分かる | 通則編(識別と認証、記録)、IPA(共有 ID の利用者の特定)、総務省(ログの取得)、SOC 2 | 共有のアカウントで、操作した人を後から特定できるか | | 権限は必要最小限 | 通則編(アクセス制御)、IPA(ID を必要最小限に)、SOC 2(最小権限) | そのアカウントを使ってよい人の一覧を持っているか。業務に要らない権限を持つ人がいないか | | 退職・契約終了で止める | IPA(異動・退職時の変更・削除、契約終了時の回収)、総務省(不要なアカウントの削除)、SOC 2(アクセスの削除) | 辞めた人や終わった委託先が、まだ入れる状態になっていないか | | 委託先を確かめる | 個人情報保護法 25 条と通則編、プライバシーマーク、経営ガイドライン指示 9、ISMS(5.19 供給者関係) | 委託先の管理を契約と確認の手順で把握しているか | ## 何から始めるか 最初に、社内で使っているアカウントを一覧にします(棚卸し。何があるかを書き出すことです)。1 つの ID とパスワードを複数の人で使っているものは分けて書きます。一覧がなければ止め漏れに気づけないため、順番はこの通りです。共有アカウントの扱いは[共有アカウントの管理](/guides/shared-accounts)に、預かったアカウントの扱いは[運用代行のクライアントアカウント管理](/guides/agency-accounts)にまとめています。 次に、退職・異動・契約終了のときに誰が何を止めるかを手順にします。委託先には、契約に安全管理の事項と報告の頻度を入れ、確認の手順を決めます。認証を取るかどうかは、取引先からの要求と費用を見て判断すればよく、法律の義務はその前から当てはまります。 ## このテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 - [内部監査でアカウントの管理を確かめるときの観点と記録](/guides/compliance/internal-audit-account-checklist): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 - [ISMAP の管理基準がクラウドサービス事業者に求めるアカウント管理](/guides/compliance/ismap-account-management): ISMAP 管理基準は、事業者のシステムに入る人の ID の登録と削除、管理者権限の制限、定期の見直し、作業の記録を求めます。サービスを使う組織が自分で ID と権限を管理できる機能の提供も求めます。 - [ISO/IEC 27017 がクラウドを使う側と提供する側に求めるアカウント管理](/guides/compliance/iso27017-cloud-account-management): ISO/IEC 27017 は推奨の手引です。パスワードの管理では、クラウドを使う会社には事業者の手順が自社の決まりに合うかの確認を、事業者には手順の情報を出すことを勧めています。ID の登録と権限の付与は事業者にだけ手引があります。 - [J-SOX の IT 全般統制の運用評価で、アカウントについて確かめられること](/guides/compliance/jsox-operating-evaluation-accounts): 運用評価では、期中に行った利用者の追加・削除・権限の見直しから一部を抜き出し、承認や削除の記録が実際にあるかを確かめます。共有の ID は、本人が使ったことを記録で示せないため、確かめにくくなります。 - [NIST サイバーセキュリティフレームワーク 2.0 の PR.AA を共有アカウントに当てはめる](/guides/compliance/nist-csf-2-identity-management): PR.AA は、建物やシステム、データに入れる人を認められた人に限ることを求め、6 項目に分けています。手段は定めませんが、NIST の例は 1 人 1 つの認証情報を挙げており、共有を残すなら使った人の確かめ方と止め方の説明が要ります。 - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」が求めるアクセス管理と ID 管理](/guides/compliance/fsa-cybersecurity-guideline-access): 中心は 2.3.1「認証・アクセス管理」です。権限を最小限にして承認した個人に付け、アカウントを作成から終了まで管理して棚卸しし、パスワードを管理し、重要なシステムには外から多要素認証で入り、操作を使った人と結びつけて記録するよう求めます。 - [IPA「組織における内部不正防止ガイドライン」第 5 版のアカウント管理項目](/guides/compliance/ipa-insider-threat-guideline-accounts): 第 5 版の 33 項目のうち、アカウントを扱うのは主に 6 つです。共有 ID を使わない、退職した人の ID をただちに消すなど 5 つを「しなければならない」とし、利用の記録を残す 1 つは「望ましい」としています。 - [ISMS の担当者が代わるときのアカウントと権限の引き継ぎ](/guides/compliance/isms-handover-accounts): 経営者が後任を任命し直し、管理者権限を後任に付けてから、共有パスワードを変え、前任者の権限を外します。審査では、任命と後任の力量の記録、交代前後の権限の一覧、外した記録を示します。 - [PCI DSS の要件 8 は共有 ID をどう扱うか(EC 事業者と運用代行の場合)](/guides/compliance/pci-dss-requirement-8-shared-ids): PCI DSS の要件 8 は共有 ID を例外の場面に限り、PCI SSC はそのねらいを、操作を一人ひとりに結びつけることだと説明します。カード情報を持たない EC 事業者も管理画面の二段階認証などを求められ、運用代行もそれに従います。 - [個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか](/guides/compliance/personal-data-ledger-accounts): 台帳は法律の義務ではなく、プライバシーマークは「アクセス権を有する者」を求めますが、細かさは決めていません。台帳には部署と役割を書き、氏名とアカウントは別の一覧に分けると直し漏れが減ります。 - [SOC 2 の論理アクセスの規準(CC6.1〜6.3)を SaaS のアカウント管理に当てはめる](/guides/compliance/soc2-logical-access-for-saas): CC6.1 は情報資産へのアクセスを仕組みで制限すること、CC6.2 は承認してから ID を発行し不要になれば消すこと、CC6.3 は役割に応じた最小限の権限を求めます。SaaS では一覧・申請と削除の記録・定期の見直しに当たります。 - [個人情報保護法の安全管理措置をアカウント管理に当てはめる](/guides/compliance/appi-safety-measures-for-accounts): 通則編の別添が求める「アクセス制御」と「アクセス者の識別と認証」、24 条の従業者の監督、25 条の委託先の監督を、共有アカウント・退職者・委託先の 3 場面に当てはめ、用意する一覧と記録を表にします。 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版のアカウント管理項目](/guides/compliance/ipa-sme-guideline-accounts): 第 4.0 版は、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更・削除、契約終了時のアクセス権の回収を挙げます。本編・付録 3・付録 5 の当てはまる箇所を点検表にします。 - [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](/guides/compliance/iso27001-access-control-for-saas): 取り上げる管理策は、5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権の 5 つです。SaaS では、使える人の一覧、ID の作成と削除、パスワード、管理者権限に当たります。 - [経産省サイバーセキュリティ経営ガイドライン(Ver 3.0)の委託先管理](/guides/compliance/meti-cybersecurity-management-guideline-contractors): 指示 9 は、委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化を経営者に求めます。アカウントの操作手順は書かれていないため、委託先に渡すアカウントの一覧と契約の条項に置き換えて読みます。 - [総務省テレワークセキュリティガイドライン第 5 版と私物端末](/guides/compliance/mic-telework-guideline-byod): 第 5 版は対策を経営者・管理者・勤務者に分けます。管理者には多要素認証、不要なアカウントの削除、ログイン後の記録の取得を、勤務者には認証情報を無断で貸さないことを求め、私物端末はテレワークの方式ごとに可否を決めます。 - [プライバシーマーク(JIS Q 15001)でアカウント管理について求められること](/guides/compliance/privacy-mark-account-management): JIPDEC の構築・運用指針は、個人情報の台帳に「アクセス権を有する者」を書いて年 1 回以上確認すること、従業者の監督、委託先の選定基準と契約の 8 事項を求めます。アカウントでは、使える人の一覧・記録・契約の条項に当たります。 - [不正アクセス禁止法と ID・パスワードの共有(識別符号の扱い)](/guides/compliance/unauthorized-computer-access-law-shared-ids): 会社が契約するサービスの共有 ID を、会社の承諾を得た担当者が使う行為は、不正アクセス行為から除かれると読めます。退職者の利用、委託先への提供、社外に教える行為は、承諾の範囲と 5 条の「業務その他正当な理由」で分かれます。 - [ISMS(情報セキュリティマネジメントシステム)とは](/guides/compliance/what-is-isms): ISMS とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。国際規格 ISO/IEC 27001 に沿って作り、第三者の審査を受けて認証を取ることができます。 - [IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc): IT 全般統制とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」とされるもので、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理が例に挙がります。 - [安全管理措置とは](/guides/compliance/what-is-security-control-measures): 安全管理措置とは、個人情報保護法 23 条が事業者に義務づける、個人データの漏えい・滅失・毀損を防ぐ対策です。通則編の別添が、組織的・人的・物理的・技術的の 4 区分と外的環境の把握で内容を示します。 - [SOC 2 とは](/guides/compliance/what-is-soc2): SOC 2 とは、クラウドなどのサービスを提供する会社の内部統制を、公認会計士が AICPA の Trust サービス規準に照らして検証し報告する仕組みです。セキュリティなど 5 つの区分で見ます。 ## よくある質問 **共有アカウントを使うと法律違反になりますか** 確認した法令と指針に、共有そのものを禁じる条文はありません。求められているのは、個人データを扱うシステムで誰が使ったかを確かめられることと、要らなくなったアクセスを止められることです。 **中小企業にはどの文書が当てはまりますか** 個人情報データベース等を事業に使っていれば個人情報保護法は規模を問わず当てはまります。総務省の中小企業向け手引きは専任の担当者がいない組織向け、IPA のガイドラインは経営者と情報管理を統括する人向けです。 **認証を取っていない会社は何もしなくてよいですか** ISMS やプライバシーマークは任意の制度ですが、個人情報保護法の安全管理措置と従業者・委託先の監督、不正アクセス禁止法は、認証の有無にかかわらず当てはまります。 **委託先のアカウント管理まで確かめる必要がありますか** 個人データの取扱いを委託するなら、25 条により委託先の監督が義務です。通則編は、委託先の安全管理措置が自社に求められるものと同等であることを、あらかじめ確かめるよう求めています。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [JIPDEC「ISMS 適合性評価制度について」](https://isms.jp/isms/) - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [JIPDEC「プライバシーマーク制度について」](https://privacymark.jp/system/about/index.html) - [JIPDEC「プライバシーマークにおける個人情報保護マネジメントシステム構築・運用指針【JIS Q 15001:2023 準拠 ver1.0】」](https://privacymark.jp/guideline/pm_shishin2023v1.0.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) - [IPA「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第 4 版」](https://www.ipa.go.jp/security/economics/hjuojm00000044dc-att/cms_practice_v4_1.pdf) - [不正アクセス行為の禁止等に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/411AC0000000128) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、4 点のうち、誰が使ったか分かる・必要なアカウントだけを使わせる・退職や担当交代で止める、の 3 つを仕組みで担います。担当者がスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。パスワードは管理者が登録し、担当者には渡しません。退職や担当交代のときは、その人の割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 更新日: 2026-10-14 CIS Controls は、米国の非営利団体 CIS(Center for Internet Security)が公開する、攻撃を防ぐための対策の一覧です。v8.1 は 18 の分野(Control)に分かれ、その下に 153 の具体的な対策(CIS の言う Safeguard。以下、保護策)が並びます。アカウントを扱うのは Control 5「アカウント管理」と Control 6「アクセス制御管理」で、保護策は合わせて 14 です。 保護策の原文は、CIS が公開する CIS Controls Navigator で読めます。v8.1 の翻訳に日本語はないので、この記事の日本語は原文からの訳です。 ## CIS Controls はどんな文書か CIS の FAQ によれば、CIS Controls は、よくある攻撃を防ぐために優先する対策を短くまとめたものです。自社のセキュリティを高めるためなら、誰でも無料で使えます。法令や認証制度の代わりにはなりません。一方で、NIST のサイバーセキュリティフレームワーク、ISO 27000 シリーズ、PCI DSS などとの対応表があります。 v8.1 は v8 を引き継いだ改訂で、NIST のサイバーセキュリティフレームワーク 2.0 との対応づけの見直しや、保護策の説明の補足などが入っています。 ## 実施グループで、どこまで行うかが変わる CIS は保護策を 3 つの実施グループ(Implementation Group、IG)に分けています。組織のリスクと、対策に使える人手やお金に応じて、どこまで行うかを決める目安です。CIS は、どの組織も IG1 から始めるよう勧め、IG1 を「基本的なサイバー衛生」(どの組織も最低限行う対策)と呼んでいます。IG1 の保護策は 56 です。IG1 が想定するのは、多くの場合、IT やセキュリティに詳しい人が少ない中小規模の組織です。IG2 は IG1 に保護策を足したもので、IG3 はすべての保護策を含みます。 Control 5 と 6 の保護策と、それぞれが最初に入る実施グループは次のとおりです。 | 番号 | 要点 | 最初に入る IG | | --- | --- | --- | | 5.1 | すべてのアカウントの一覧を作り、保つ | IG1 | | 5.2 | パスワードを使い回さない | IG1 | | 5.3 | 45 日使われていないアカウントを止める | IG1 | | 5.4 | 管理者の権限を管理者専用のアカウントに限る | IG1 | | 5.5 | プログラムが使うアカウントの一覧を作る | IG2 | | 5.6 | アカウントの管理を 1 か所に集める | IG2 | | 6.1 | 権限を与える手順を決める | IG1 | | 6.2 | 権限を外す手順を決める | IG1 | | 6.3 | 社外から入れるサービスで多要素認証を必須にする | IG1 | | 6.4 | 社外から社内のネットワークに入るときの多要素認証 | IG1 | | 6.5 | 管理者のアカウントで多要素認証を必須にする | IG1 | | 6.6 | ログインと権限を確かめる仕組みの一覧を作る | IG2 | | 6.7 | 権限の管理を 1 か所に集める | IG2 | | 6.8 | 役割ごとの権限を決めて保つ | IG3 | ## Control 5 が求めること Control 5 のねらいは、利用者・管理者・プログラムが使うアカウントに、機器やソフトウェアに入る権限を手順と道具で与え、管理することです。 中心になるのは 5.1 の一覧です。一覧に必ず含めるのは、社員などの利用者、管理者、プログラムが使うアカウント(サービスアカウント)です。書く項目は、少なくとも本人の名前、ユーザー名、使い始めと使い終わりの日付、部署とするよう勧めています。そのうえで、使われているアカウントがすべて認められたものかを、少なくとも四半期に 1 回確かめます。 5.2 は、パスワードを使い回さないことです。望ましい形として、多要素認証を使うアカウントは 8 文字以上、使わないアカウントは 14 文字以上を挙げています。5.3 は、45 日使われていないアカウントを、できる場合は削除するか止めることです。5.4 は、管理者の権限を管理者専用のアカウントに限り、ネットの閲覧やメールなど、ふだんの作業は権限のないアカウントで行うことです。 IG2 では 2 つが加わります。5.5 は、サービスアカウントの一覧に責任を持つ部署・見直した日・目的を書き、四半期ごとに見直すことです。5.6 は、アカウントの管理を [ID 管理サービス](/guides/access-basics/what-is-idp)に集めることです。Okta や Microsoft Entra ID などが、これに当たります。 ## Control 6 が求めること Control 6 のねらいは、アクセスに使う ID と権限を、作る・与える・管理する・取り消すまで、手順と道具で扱うことです。 6.1 と 6.2 は、入社や異動のときに権限を与える手順と、外す手順です。どちらも手順を決めて従うことを求め(6.1 は手順を文書にすることも)、できれば自動にするよう勧めています。6.2 は、退職・権限の取り消し・異動のときに、ただちにアカウントを止めることで外すよう求めます。そのうえで、操作の記録を残すために、削除ではなく停止にする必要がある場合もあると添えています。 6.3〜6.5 は[多要素認証](/guides/access-basics/what-is-mfa)(パスワードに加えて別の方法でも本人を確かめること)です。6.3 は、社外から入れる自社または他社のアプリケーションに、対応していれば多要素認証を必須にすることを求めます。ID 管理サービスや SSO(一度のログインで複数のサービスに入れる仕組み)を通して必須にする形でもよいとしています。6.4 は社外から社内のネットワークに入るときが対象です。6.5 は、対応していれば、管理者のアカウントすべてに多要素認証を求めます。自社で管理するものも、外部の事業者が管理するものも含みます。 IG2 では 2 つが加わります。6.6 はログインと権限を確かめる仕組みの一覧を年に 1 回以上見直すこと、6.7 は権限の管理を ID 管理サービスや SSO に集めることです。IG3 の 6.8 は、役割ごとに必要な権限を決めて文書にし、少なくとも年に 1 回、すべての権限が認められたものかを確かめることです。 ## 業務で使うクラウドサービスに当てはめる 業務で使うクラウドサービスは、社外から入れる他社のアプリケーションなので、6.3 の対象になり、そのアカウントは 5.1 の一覧にも入ると読めます。 ただし、6.3・6.5・6.7 には「対応していれば」という条件が付いています。ID 管理サービスとつながらないサービスは 6.7 の 1 か所に集めた管理から、多要素認証のないサービスは 6.3・6.5 の多要素認証から外れます。そのアカウントは、5.1 の一覧と 6.1・6.2 の手順で把握することになります。 ## 1 つの ID を何人かで使うと合わなくなる保護策 Control 5 と 6 の保護策の文に、[共有アカウント](/guides/shared-accounts/what-is-shared-account)を名指しする文はありません。それでも、次の保護策は、1 つのアカウントを 1 人が使うと考えると無理なく当てはまり、共有の ID では合わなくなります。 - 5.1 は、一覧に本人の名前を書くよう勧めています。共有の ID では 1 行に名前を 1 つに決められず、四半期ごとの確認でも、誰が使っているかを別に調べることになります。 - 共有の ID は、誰か 1 人が 45 日のうちに一度でも使えば、5.3 の止める対象になりません。担当を外れた人がパスワードを覚えていても、この保護策では見つかりません。 - 6.2 は、辞めた人のアカウントを止めることで権限を外します。共有の ID を止めると残る人も使えなくなるので、パスワードを変えて配り直すことになります。6.2 が停止で残そうとする操作の記録も ID ごとに残るので、共有の ID では誰の操作かまでは分かりません。 - 共有の管理者 ID で、6.5 の多要素認証のコードが 1 台の端末にしか届かない設定だと、その持ち主がいない日に管理の作業が止まります。 人ごとに ID を作れるサービスは、人ごとに分けるのが保護策の文にいちばん合う形です。分けられないものは、一覧に使ってよい人を並べ、誰がいつ使ったかを別に残す方法を決めておくと、四半期の確認に答えられます。分けられない場面の整理は[共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。 ## よくある質問 **CIS Controls は日本の会社でも使えますか** 使えます。CIS の FAQ によれば、自社のセキュリティを高めるためなら誰でも無料で使えます。v8.1 の翻訳はフランス語とイタリア語だけですが、1 つ前の v8 には CIS が公開する日本語訳があります。 **中小企業はどの保護策から始めればよいですか** CIS はどの組織も IG1 から始めるよう勧めています。Control 5 と 6 では、5.1〜5.4 と 6.1〜6.5 の 9 つが IG1 に入ります。 **使われていないアカウントは何日で止めますか** 保護策 5.3 は、45 日使われていないアカウントを、できる場合は削除するか止めるよう求めています。 **CIS Controls は共有アカウントを禁じていますか** Control 5 と 6 の保護策の文に、共有アカウントを名指しする文はありません。ただ、一覧に本人の名前を書くよう勧める 5.1 や、辞めた人のアカウントを止める 6.2 は、1 人 1 アカウントが前提と読めます。 **CIS Controls に沿えば法令や認証の代わりになりますか** なりません。CIS の FAQ は、CIS Controls が法令や認証制度の代わりではないとしています。NIST のフレームワークや ISO 27000 シリーズなどとの対応表は用意されています。 ## 参考資料 - [CIS「CIS Controls Navigator v8.1」(Control 5・6 の保護策の原文と実施グループ)](https://www.cisecurity.org/controls/cis-controls-navigator) - [CIS「CIS Critical Security Control 5. Account Management」](https://www.cisecurity.org/controls/account-management) - [CIS「CIS Critical Security Control 6. Access Control Management」](https://www.cisecurity.org/controls/access-control-management) - [CIS「CIS Critical Security Controls Version 8.1」](https://www.cisecurity.org/controls/v8-1) - [CIS「CIS Critical Security Controls Version 8」(日本語を含む翻訳の一覧)](https://www.cisecurity.org/controls/v8) - [CIS「CIS Critical Security Controls」(CIS が非営利団体であることの説明)](https://www.cisecurity.org/controls) - [CIS「CIS Critical Security Controls Implementation Groups」](https://www.cisecurity.org/controls/implementation-groups) - [CIS「CIS Critical Security Controls Implementation Group 1」](https://www.cisecurity.org/controls/implementation-groups/ig1) - [CIS「CIS Critical Security Controls FAQ」](https://www.cisecurity.org/controls/cis-controls-faq) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有の ID は誰かが使い続けるかぎり 5.3 の 45 日の停止に掛からず、抜けた人を締め出すにはパスワードを変えて配り直すしかありません。Junify に載せたアカウントは導入時にパスワードを変えて Junify だけが持つので、抜けた人は割り当てを外した時点で入れなくなり、配り直しも要りません。5.1 の確認には、使ってよい人の一覧と、スマホで本人確認をして入った人の記録を使えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 - [内部監査でアカウントの管理を確かめるときの観点と記録](/guides/compliance/internal-audit-account-checklist): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 --- # 漏えい等の報告で、アクセスの記録(ログ)から示すこと 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 更新日: 2026-10-14 個人情報の漏えい等を個人情報保護委員会に報告するとき、アクセスの記録が裏づけるのは、9 つの報告項目のうち 4 つです。いつから何が起きたかという経過、触れられた個人データの項目、その本人の数、そして原因です。記録で「見られていない」と確かめられなければ、その範囲は漏えいのおそれに当たり得ます。報告が要る 4 つの事態と期限は[漏えい等とは(個人情報保護法の報告義務)](/guides/incidents/what-is-data-breach)にあります。 ## 報告の項目と、記録で示すもの 報告の項目は、個人情報保護法の施行規則 8 条 1 項が定める 9 つです。委員会が公開している報告書の様式と記載例を見ると、記録から埋める欄がどれかが分かります。 | 報告の項目 | 様式で書く欄 | 記録で示すこと | | --- | --- | --- | | 概要 | 発生日、発覚日、発生事案、事実経過など | 最初に不正に入った日時と、その後の動き | | 個人データの項目 | 媒体、種類、氏名や住所などの項目 | 開かれた画面や持ち出されたファイルに含まれていた項目 | | 本人の数 | 人数 | 開かれた範囲に含まれる本人の数 | | 原因 | 原因の種類(不正アクセス、従業員不正など)と詳細 | どのアカウントで、どこから入ったか | 残りの 5 つ(二次被害、本人への対応、公表、再発防止の措置、その他参考となる事項)は、記録よりも事後の対応で決まります。 委員会の記載例のうち不正アクセスの例では、発生日が 2 月 1 日、発覚日が 4 月 1 日です。発覚のきっかけは決済代行会社からの連絡でした。事業者は外部の業者に調査を頼み、侵入の痕跡から 2 月の日付までさかのぼっています。発覚より前の記録が残っていなければ、発生日と経過の欄を記録からは埋められません。 ## 記録がないと「見られていない」と言えない 報告の対象には、漏えい等が発生した事態だけでなく、発生したおそれがある事態も含まれます。個人情報保護委員会のガイドライン(通則編)の 3-5-3-1 は、おそれを「漏えい等が疑われるものの漏えい等が生じた確証がない場合」と説明しています。 この線引きを記録が左右することは、委員会の Q&A(Q6-2)から読み取れます。設定の誤りで個人データが外から見られる状態になった場合を例にとります。閉じるまでに第三者が見ていないことが「アクセスログ等から確認された場合」は、漏えいに当たりません。逆に、アクセスログ等が確認できない場合は「漏えい（又は漏えいのおそれ）に該当し得ます」としています。記録がなければ、見られていないことを示す材料がないからです。当たるかどうかは、その時点で分かっている事実をもとに、事案ごとに判断します(通則編 3-5-3-1)。 本人の数も同じ考え方で数えます。確定できないときの数え方も通則編にあります。おそれがある個人データの本人の数が「最大 1,000 人を超える場合」は、施行規則 7 条 4 号(1,000 人を超える事態)に当たります。入られたアカウントで開ける顧客が何人いるかが、そのまま「最大」の候補になります。どの顧客の画面を開いたかを記録で絞れなければ、開ける顧客全員を数えることになると読めます。 ## 共有の ID では「誰が」が記録に残らない 報告書の原因の欄では、まず事態がどちらの取扱いで起きたか(様式でいう「主体」)を、報告者・委託先・不明から選びます。自社のシステムで起きたなら、入ったのが外部の人でも主体は報告者です。そのうえで、不正アクセスか従業員不正かといった原因の種類と、その詳細を書きます。 誰が入ったかが分からないと決められないのは、この種類のほうです。施行規則 7 条 3 号の「不正の目的をもって行われたおそれがある」行為をした人には、外部の第三者だけでなく従業者も含まれます(通則編 3-5-3-1)。通則編は、従業者の持ち出しがおそれに当たり得る例も挙げています。サーバーや端末に「通常の業務で必要としないアクセスによりデータが窃取された痕跡」が認められた場合です。 あるアクセスが通常の業務に要るものだったかは、誰のアクセスかが分かって初めて判断できます。1 つの ID とパスワードを複数の人で使う[共有アカウント](/guides/shared-accounts/what-is-shared-account)では、記録に残る ID は人ではなくアカウントを指します。パスワードを知っている退職者が入っても、パスワードを盗んだ外部の人が入っても、記録の上では同じ ID に見えます。どこから入ったか(接続元)で見分けられることもありますが、記録だけでは原因の種類を決めにくく、使える人への聞き取りで絞ることになります。 ## 確報までに記録を出せるか 速報は、事態を知った後、速やかに出します(通則編の目安は概ね 3〜5 日以内)。中身は、報告する時点で把握している範囲で足ります。記録が問われるのは、30 日以内(3 号の事態は 60 日以内)に出す確報です。確報では 9 項目のすべてを報告します。合理的な努力を尽くしても分からない項目は、分かりしだい追加で報告します(通則編 3-5-3-4)。聞き取りにかかる日数も、記録を委託先やサービスの提供者から取り寄せる日数も、この期限の中で見込んでおくことになります。 なお、2026 年 7 月 17 日に公布された改正個人情報保護法には、本人への通知の義務を一部緩める見直しが入っています。この改正法の施行は、原則として公布から 2 年以内です。委員会の資料には、報告の側の見直しも方針として挙がっています。体制や手順について第三者の確認を受けることを前提に一定の範囲で速報を免除すること、違法な第三者提供を報告の対象に加えることなどです。こちらは、いつから適用されるかが資料に書かれていません。報告の決まりについて、この記事はいまの施行規則と通則編に沿っています。 ## 平時に確かめておくこと 通則編の別添は、組織的安全管理措置の手法の例として、担当者の情報システムの利用状況(ログイン実績、アクセスログ等)の記録を挙げています。 委員会は 2026 年 10 月 7 日の注意喚起で、安全管理措置の見直し案を先に示しました。確定は 2027 年 4 月の予定です。案では、技術的安全管理措置(システムの側で行う安全対策)の「講じなければならない措置」に、いまの別添にない「不正アクセス等の検知等」が加わる予定です。不正アクセスを早く見つける仕組みを、平時から整えておく措置です。確定するまでは案で、いまの義務ではありません。 案で手法の例として挙がっているのは、認証や操作などの記録を一定の期間保管すること、改ざんや不正な消去から守ること、定期的に分析することです。注意喚起は、手法の例はすべてを行わなくても直ちに法に反するものではない、としています。委員会の「WARNING」も、不正ログインの事例の原因に、記録の保存と監視のルールがなく検知が遅れたことを挙げています。 報告の項目から逆にたどると、平時に確かめておくことは次の 4 つです。 1. 個人データを扱うシステムで、記録に残る ID が一人の人を指しているか。指していなければ、原因の種類も、通常の業務に要らないアクセスかどうかも判断できません。 2. ログインだけでなく、どの画面を開き、何を書き出したかが残るか。ログインの記録だけでは、本人の数と項目を絞れません。 3. 記録を何日分残すか。記載例のように発覚までに 2 か月かかることもあり、それより短い保存期間では、記録から発生日までさかのぼれません。 4. 記録を誰が消せるか。入った本人が記録を消せる状態では、見られていないことを示す材料になりません。 ## よくある質問 **記録がなければ報告しなくてよいですか** いいえ。報告の対象には漏えい等が起きたおそれがある事態も含まれます。委員会の Q&A は、記録で見られていないことを確かめられない場合は、漏えいかそのおそれに当たり得るとしています。 **速報の時点で本人の数が分かりません** 速報は報告する時点で把握している範囲で足ります。確報では 9 項目すべてを報告し、努力しても分からない項目は、分かりしだい追加で報告します。 **共有アカウントの記録で原因を説明できますか** 記録に残る ID は人ではなくアカウントを指すので、従業者か、退職者か、パスワードを盗んだ外部の人かを記録だけでは分けにくくなります。使える人への聞き取りで絞ることになります。 **記録は何日分残せばよいですか** 通則編に日数の定めはなく、委員会の見直し案も「一定の期間」としています。委員会の記載例には、発覚まで 2 か月かかった事案もあります。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報の保護に関する法律施行規則(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/428M60020000003) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [個人情報保護委員会事務局「個人情報保護法等の一部を改正する法律について」(令和 8 年 7 月)](https://www.ppc.go.jp/files/pdf/260717_kaiseihounitsuite.pdf) - [個人情報保護委員会「令和8年 改正個人情報保護法について」](https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/) - [個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関する Q&A」Q6-2](https://www.ppc.go.jp/all_faq_index/faq1-q6-2_) - [個人情報保護委員会「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/) - [個人情報保護委員会「漏えい等報告の記載例 ② 不正アクセス事例」](https://www.ppc.go.jp/files/pdf/kisairei_unauthorized_access_minkan.pdf) - [個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について(注意喚起)」(令和 8 年 10 月 7 日)](https://www.ppc.go.jp/files/pdf/261007_alert_dataleakage.pdf) - [個人情報保護委員会「WARNING~不正アクセスによる個人データ漏えい防止のための注意喚起~」(令和 8 年 10 月 7 日改訂)](https://www.ppc.go.jp/files/pdf/261007_warning.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 確報の原因の欄で不正アクセスか従業員不正かを書き分けるには、共有の ID で入ったのが誰かを突き止める必要があります。Junify を通して入ったアカウントなら、どの担当者がいつ開いたかが名前で残るので、聞き取りを待たずに書き始められます。必要なら画面の操作も残せます。導入時にパスワードを変えて Junify だけが持つため、辞めた人が古いパスワードで入ることもありません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 - [内部監査でアカウントの管理を確かめるときの観点と記録](/guides/compliance/internal-audit-account-checklist): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 --- # 政府の統一基準が求める ID の管理と委託先の対策 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 更新日: 2026-10-14 「政府機関等のサイバーセキュリティ対策のための統一基準」(以下、統一基準)は、国の機関などが守る共通ルールです。ID とパスワードについては、ID を適切に付けて管理し、要らなくなったら速やかに使えなくし、権限を必要最小限にすることを求めています。対策の例を示すガイドラインは、使う人ごとに ID を付けるのを原則とします。複数の人で 1 つの ID を使う「共用識別コード」は、いわゆる[共有アカウント](/guides/shared-accounts/what-is-shared-account)です。ガイドラインはこれを、やむを得ない場合に、使った人を特定できる仕組みを条件に認めています。業務を受ける民間の会社には、機関の情報を扱う業務であれば、情報を守るための対策が契約の条件として求められます。 ## 統一基準群はどんな文書で、誰に当てはまるか 統一基準群は 3 つの文書からなります。サイバーセキュリティ戦略本部が「統一規範」と「統一基準」を決めます。内閣官房国家サイバー統括室は「政府機関等の対策基準策定のためのガイドライン」(以下、ガイドライン)を定めます。現行は令和 7 年度版で、統一基準は令和 8 年 9 月、ガイドラインは令和 8 年 10 月に一部改定されています。 文書ごとに求める強さが違います。統一基準は、各機関が必ず守る「遵守事項」を定めます。ガイドラインは、遵守事項を満たすための「基本対策事項」と解説を載せています。統一基準は、基本対策事項に例示された対策か、それと同等以上の対策を行うことで遵守事項を満たすよう求めています。基本対策事項のうち「以下を例とする」と書かれたものは例で、「全て含む」と書かれたものはすべて行う事項です。 適用対象は「機関等」、つまり国の行政機関、独立行政法人、指定法人です。民間の会社に直接当てはまる文書ではありません。ただし統一基準は 4.1.1 の目的・趣旨で、委託先への要求事項を調達仕様書などに定め、契約の条件にする必要があるとしています。 国の行政機関や独立行政法人などの業務を受ける会社に届くのは、この仕様書と契約に書かれた事項です。統一基準でいう業務委託は、機関の情報を扱わせる場合に限られます。ガイドライン自身も、統一基準群そのものを民間の委託先に守らせるのは、必ずしも適切でない場合があるとしています。 ## ログインと ID について何を求めるか 中心は統一基準の 7.1.1「主体認証機能」です。主体認証とは、ログインする人が本人かを確かめることです。統一基準は ID を「識別コード」、パスワードなどを「主体認証情報」と呼びます。遵守事項は、アクセスする全ての人に ID とパスワードを「適切に付与し、管理するための措置」を求めます。システムを使う必要がなくなった人については、その ID が不正に使われないよう「速やかに」措置をとることを求めています。 ガイドラインの基本対策事項は、これを具体的にしています。例には、ある人に付けた ID を別の人に付けないことがあり、共用識別コードはこの例から除かれています。要らなくなった人については、ID を無効にすることや、無効にした ID を別の人に発行しないことが例に挙がります。解説は、人事異動のあとに不要な ID が残る可能性を指摘し、定期的に確かめて無効にするよう書いています。 ログインの方法について、ガイドラインはパスワード・IC カード・指紋などのうち 2 つ以上を組み合わせる方式の導入を検討するよう求めています。外から直接入れるクラウドサービスの管理者のように強い権限を持つ人には、原則としてこの強い方式を使うとしています。職員の側の決まりもあります。8.1.1 は職員に、自分の ID 以外でシステムを使わないことと、自分のパスワードの管理の徹底を求めています。 権限は 7.1.3 が扱います。必要最小限に設定し、要らない権限が付いていないかを定期的に確かめることが遵守事項です。 ## 共用の ID はどこまで認められるか ガイドラインは共用識別コードを「複数の主体が共用するために付与された識別コード」と定義しています。「情報システム上の制約や利用状況等に応じて」組織で共用する場合もある、という説明です。基本対策事項 7.1.1(2)-6 は、使う人ごとに ID を付けるのを原則とします。責任者の判断でやむを得ず共用するときは、使った人を特定できる仕組みを設け、扱いの手順を決めて、その手順に従うよう求めています。 解説はその理由を書いています。共用の ID は利用の記録だけでは誰が使ったか分からないため、不正な利用に気づきにくく、事故の原因を調べる妨げにもなり得ます。特定の仕組みの例は 3 つです。1 つ目と 2 つ目は、別のログイン方法や、入退室の管理のような物理的な確認を併せて使うことです。3 つ目は、第三者の承認を得てから使い、使ったことが通知される仕組みも設けることです。あわせて、パスワードを知る人を限ることも求めています。 ## 委託先には何を求めるか 統一基準の 4.1.1「業務委託」は、委託先の選定と契約、期間中の履行状況の確認、終了時の検収を遵守事項にしています。検収は、業務の結果を確かめて受け取ることです。委託先には、期間中は対策の履行状況を定期的に報告させます。終了時は、期間を通じて対策を適切に行ったことの報告を含む検収を受けさせます。 ID に関わるのは、ガイドラインの 2 つの基本対策事項です。1 つは 4.1.1(2)-5 です。委託先に確認書などを出させ、その中に「当該委託業務に携わる者の特定」を含めます。変更があれば速やかに出し直させます。もう 1 つは 4.1.1(3)-1 です。8 つの対策をすべてあらかじめ契約に入れ、委託期間を通じて、扱う情報の格付(機密性などに応じた重要さの区分)などに応じて行わせます。8 つのうち ID に関わるのは「情報へアクセスする主体の識別とアクセスの制御」と「ログの取得・監視」です。解説によれば、8 項目は米国の NIST SP800-171(米国政府の情報を政府の外で守るための要求集)を参考にしています。 解説は、扱う情報の格付などに応じて委託先に求めることが考えられる対策を挙げます。その 1 つは、システムの利用者と使う機器を 1 人・1 台ずつ見分けられるようにすることです。管理者用のアカウントに 2 つ以上の方法でのログインを使い、一般のアカウントにも可能な限り使うことも例に入っています。記録については、守るべき情報に触れる全ての利用者の操作の記録を取ることを求めています。記録を監査で示せる形にする条件は、[監査ログと、監査で示す記録の違い](/guides/access-basics/audit-log-vs-evidence)にまとめています。 ## 受託する会社が先に確かめておくこと 受託する会社が ID の決まりに出会う経路は 2 つあります。1 つは、機関のシステムに入る ID をもらう場合です。7.1.1 は「情報システムにアクセスする全ての主体」が対象なので、機関の決まりがそのまま当てはまります。もう 1 つは自社のシステムで機関の情報を扱う場合で、4.1.1(3)-1 として契約に入った事項が当てはまります。どの対策が契約に入るかは案件ごとの仕様書で決まるので、該当箇所を読み、下の表の行に当てはめて確かめます。 | 求めること | 書かれている場所 | 強さ | | --- | --- | --- | | 要らなくなった人の ID を速やかに止める | 統一基準 7.1.1(2)(b) | 遵守事項 | | 権限を必要最小限にし、定期的に確かめる | 統一基準 7.1.3(1) | 遵守事項 | | 使う人ごとに ID を付ける | ガイドライン 7.1.1(2)-6 | 基本対策事項 | | 共用の ID は、使った人を特定する仕組みと手順を条件に | ガイドライン 7.1.1(2)-6 | 基本対策事項 | | 強い権限は原則 2 つ以上の方法でログイン | ガイドライン 7.1.1(1)-2 | 基本対策事項 | | 委託業務に携わる人を確認書で特定 | ガイドライン 4.1.1(2)-5 | 基本対策事項(全て含む) | | 利用者の識別と記録を契約に入れる | ガイドライン 4.1.1(3)-1 | 基本対策事項(全て含む) | 共用の ID を使う業務では、名簿の人だけが使い、外れた人の利用を止めたことを示せると説明しやすくなります。示す場面は、確認書の出し直しと定期報告、終了時の報告です。 ## よくある質問 **民間の会社も統一基準を守る必要がありますか** 直接の対象は国の行政機関・独立行政法人・指定法人です。その業務で機関の情報を扱う会社には、渡された情報を守るための対策が、調達仕様書と契約に書かれた範囲で求められます。 **統一基準は共用の ID を禁じていますか** 禁じてはいません。原則は 1 人に 1 つの ID です。ガイドラインは、責任者の判断でやむを得ず共用する場合に限り、使った人を特定できる仕組みと扱いの手順を設けることを条件にしています。 **2 段階のログインは必須ですか** ガイドラインは、2 つ以上の方法を組み合わせる方式の導入を検討するよう求め、強い権限を持つ人には原則として使うとしています。委託先では管理者用のアカウントでの採用を例に挙げています。 **委託先の担当者の名簿は求められますか** ガイドラインは、委託業務に携わる者の特定を含む確認書を委託先に出させ、変更があれば速やかに出し直させるよう求めています。 ## 参考資料 - [内閣官房国家サイバー統括室「政府機関等のサイバーセキュリティ対策のための統一基準群」(ページ)](https://www.cyber.go.jp/policy/group/general/kijun.html) - [サイバーセキュリティ戦略本部「政府機関等のサイバーセキュリティ対策のための統一基準(令和 7 年度版)」(令和 8 年 9 月 14 日一部改定)](https://www.cyber.go.jp/pdf/policy/general/kijyunr7.pdf) - [内閣官房国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」表紙〜第 2 部](https://www.cyber.go.jp/pdf/policy/general/guider8_6_01.pdf) - [内閣官房国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」第 3 部〜付録](https://www.cyber.go.jp/pdf/policy/general/guider8_6_02.pdf) - [内閣官房国家サイバー統括室「政府機関等のサイバーセキュリティ対策のための統一基準群の概要」](https://www.cyber.go.jp/pdf/policy/general/kijyungun-gaiyor7.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 確認書の担当者を差し替えるたび、自社で共用している ID はパスワードを変えて残る人に知らせ直し、定期報告の前には使用簿と名簿を照らし合わせます。Junify に載せた ID なら、差し替えは割り当ての付け外しで済みます。パスワードは導入時に変えて Junify だけが持つため、外した人はその時点で入れません。担当者はスマホで本人確認をして入り、誰がいつ使ったかの記録を名簿と並べて報告に使えます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [内部監査でアカウントの管理を確かめるときの観点と記録](/guides/compliance/internal-audit-account-checklist): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 --- # 内部監査でアカウントの管理を確かめるときの観点と記録 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。 更新日: 2026-10-14 内部監査でアカウントの管理を確かめるときの確かめ方は、経済産業省の「システム監査基準」が示しています。判断の物差しは「システム管理基準」と「情報セキュリティ管理基準」です。担当者の説明を聞くだけで終えず、サービスから取り出した利用者の一覧を、人事の名簿や承認の記録と突き合わせて確かめます。 ## 監査の物差しになる 3 つの基準 | 基準 | 何を決めているか | アカウントの監査での使い方 | | --- | --- | --- | | システム監査基準(令和 5 年改訂) | 監査の進め方 | 計画の立て方、確かめ方、調書の書き方 | | システム管理基準(令和 5 年改訂) | 監査人が判断に使う尺度 | 責任と権限の決め方、外部サービスの管理 | | 情報セキュリティ管理基準(令和 7 年改正版) | 情報を守るために行う対策の項目(管理策) | ID、パスワード、アクセス権、利用の記録 | システム監査基準は、監査役や内部監査部門が行う監査にも、外部の第三者に頼む監査にも当てはめたり参考にしたりできるとしています。判断の尺度にはシステム管理基準を使うのが望ましく、情報セキュリティの監査では情報セキュリティ管理基準も参照するのが望ましい、という位置づけです。システム管理基準の前文は、情報セキュリティの項目について情報セキュリティ管理基準の平成 28 年改正版などを参照するよう書いています。経済産業省はその後、2025 年 8 月に令和 7 年改正版を、監査の進め方を決めた姉妹編の「情報セキュリティ監査基準」とあわせて公表しました。令和 7 年改正版の管理基準は、JIS Q 27001:2023 と JIS Q 27002:2024 に合わせています。 2 つの管理基準は、どちらも自社に合わせて絞り込んで使うものです。システム管理基準は、項目を漏れなく当てはめる使い方は有効ではないとし、組織に合わせて項目を選び、直して使うのが望ましいとしています。情報セキュリティ管理基準も、組織は管理策を選んで具体的にした自社の体系を作る必要があるとしています。監査人には、監査に使えるところまで具体的にした基準をまとめることが望ましいとしています。内部監査部門は、自社が使っているサービスに合わせて、見る項目を先に決めておくことになります。管理策を SaaS の作業に置き換えた整理は[ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](/guides/compliance/iso27001-access-control-for-saas)にあります。 ## 説明を聞くだけでは確かめたことにならない システム監査基準の基準 8 は、監査の手続を予備調査と本調査に分けています。予備調査では、規程や手順書を読み、関係する部門に話を聞いて、実態をつかみます。本調査では、結論を裏付ける十分で適切な証拠を集めます。基準 8 の解釈指針(基準の読み方を説明した部分)は、聞き取りによる口頭の証拠だけに頼らないよう求めています。書面の証拠を得る、現物と照合する、実際の操作を観察する、といった手続で裏付けます。 アカウントの管理では、この照合が中心になります。たとえば「退職者は当日に止めている」という説明を聞いたら、サービスの管理画面から利用者の一覧を取り出してもらい、人事の退職者の名簿と並べます。どこを重点に見るかは、基準 6 の「リスク・アプローチ」(リスクの大きい所に監査の人と時間を多く充てる考え方)で決めます。基準 6 の解釈指針は、リスクの大きさを起きる可能性と起きたときの影響の組み合わせで評価するとしています。顧客の情報を扱うサービスや管理者用のアカウントは、影響が大きいので先に見る候補になります。 ## アカウントで確かめる観点 括弧内の番号は、情報セキュリティ管理基準(令和 7 年改正版)の項目です(9 は参考として挙がっている例)。財務報告の監査で、何件を抜き出し、1 件ずつ何と照らすかは[J-SOX の IT 全般統制の運用評価で、アカウントについて確かめられること](/guides/compliance/jsox-operating-evaluation-accounts)にあります。 1. 使える人の一覧があるか(5c-5.18.1 h)。どの ID にどの権限があるかを、一か所で記録しているかを見ます。一覧がなければ、承認や退職者との突き合わせができません。 2. 使い始める前に承認があるか(5c-5.18.1 a・c・g)。監査の対象期間に加わった人から何件かを選び、承認の日付が使い始めた日より前か、承認した人と設定した人が別かを確かめます。管理基準は、承認の手続が終わった後にだけアクセス権を有効にするとしています(g)。 3. 退職や異動で止めているか(5c-5.16.1 d、5c-5.18.1 d・i)。人事の退職者・異動者の名簿と利用者の一覧を突き合わせ、止めた日を退職日と比べます。辞めた人の ID が残っていれば、その人がまだ入れるおそれがあります。 4. 共有の ID に理由と承認があるか(5c-5.16.1 b)。管理基準は、複数の人で使う ID を、業務上必要で、承認と文書化をした場合にだけ認めています。ID ごとに、承認の記録と使ってよい人の名簿があるかを見ます。 5. 共有の ID のパスワードを、知っている人が辞めたときに変えたか(5c-5.17.3 d)。パスワードを変えた日を、知っていた人の退職日・異動日と並べます。変えていなければ、辞めた人もそのパスワードで入れるおそれがあります。 6. 管理者用のアカウントが人ごとに分かれているか(8a-8.2.2 c・g・j・k)。管理基準は、この管理策を行うときに考える事項を挙げています。強い権限を持つ ID を複数の人で共有しない、与えた権限を記録する、定期的に見直す、使ったときの記録を取る、などです。 7. 定期的な見直しをしたか(5c-5.18.2)。見直しの記録に、誰がいつ見て、何を外したかが書かれているかを確かめます。異動や昇進のあとの権限が見直しの対象に入っているかも見ます。 8. 利用の記録から人が分かるか(8b-8.15.3・8b-8.15.5)。管理基準は、記録に利用者 ID と日時を含め、本人が自分の記録を消したり止めたりできないようにするよう求めています。共有の ID では記録に ID の名前しか残らないため、貸出簿など別の記録と合わせて誰が使ったかを示せるかを見ます。 9. 委託先の担当者を把握しているか(5d-5.20.1 の参考 g、5d-5.19.4 の参考 m 1))。管理基準は、委託先との取り決めや手順に含める例として、使ってよい委託先の担当者の名簿と、取引を終えるときのアクセス権の回収を挙げています。その名簿と回収の手順が実際にあるかを確かめます。 ## 監査調書に残すもの 基準 9 は、監査調書(監査で何をして、どう判断したかの記録)に一般的に含まれる事項を挙げています。実施者と日時、目的、手続、証拠、確かめた結果、発見した事実とそれへの意見、点検した場合は点検した人と日付です。アカウントの監査では、管理画面から取り出した一覧そのものを、取り出した日時と一緒に証拠として残します。利用者の一覧は日々変わるため、いつの状態を見たかが分からないと、あとから同じ照合をやり直せません。基準 9 も、調書を作る目的に、監査の内容が適切であることと、別の監査人がやり直しても同じ結果が得られることを挙げています。 ## よくある質問 **内部監査ではどの基準を物差しにしますか** システム監査基準は、判断の尺度にシステム管理基準を使うのが望ましいとしています。情報セキュリティの監査では、情報セキュリティ管理基準も参照するのが望ましいとしています。項目は自社に合わせて選びます。 **担当者に聞き取りをすれば確認になりますか** 聞き取りだけでは足りません。システム監査基準は、口頭の証拠だけに頼らないよう求めています。聞き取りは予備調査で実態をつかむのに使い、本調査では書面や現物との照合、操作の観察で裏付けます。 **共有アカウントは監査で何を見られますか** 情報セキュリティ管理基準は、複数の人で使う ID を業務上必要で承認と文書化をした場合にだけ認めています。承認の記録、使ってよい人の名簿、知っている人が辞めたときの変更日を見ます。 **退職者のアカウントはどう確かめますか** 人事の退職者の名簿と、サービスから取り出した利用者の一覧を突き合わせます。辞めた人の ID が残っていないか、止めた日が退職日より遅れていないかを見ます。 ## 参考資料 - [経済産業省「システム監査基準」(令和 5 年 4 月 26 日改訂)](https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kansa-2023r.pdf) - [経済産業省「システム管理基準」(令和 5 年 4 月 26 日改訂)](https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf) - [経済産業省「システム監査制度について」](https://www.meti.go.jp/policy/netsecurity/sys-kansa/) - [経済産業省「情報セキュリティ管理基準(令和 7 年改正版)」](https://www.meti.go.jp/policy/netsecurity/is-kansa/IS_Management_Standard_R7.pdf) - [経済産業省「情報セキュリティ監査制度」](https://www.meti.go.jp/policy/netsecurity/is-kansa/) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有 ID を使う部門は、内部監査のたびに貸出簿を探し、ID ごとに退職日とパスワードの変更日を並べて説明しています。導入時にパスワードを変えて Junify だけが持つと、担当者は使うたびにスマホで本人確認をするので、使った人と日時が ID ごとに残ります。Junify に載せたアカウントでは、割り当て(使ってよい人の指定)を外した人は入れず、突き合わせる相手は割り当ての一覧と利用の記録です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # ISMAP の管理基準がクラウドサービス事業者に求めるアカウント管理 ISMAP 管理基準は、事業者のシステムに入る人の ID の登録と削除、管理者権限の制限、定期の見直し、作業の記録を求めます。サービスを使う組織が自分で ID と権限を管理できる機能の提供も求めます。 更新日: 2026-10-14 ISMAP(政府情報システムのためのセキュリティ評価制度)の管理基準は、クラウドサービス事業者に、アカウントについて 2 つの側から対策を求めています。1 つは、自社の従業員や社外から作業に入る人など、事業者のシステムに入る人のアカウントです。ID の登録と削除、管理者権限の制限、定期の見直し、辞めた人の権限の削除、作業の記録を求めます。もう 1 つは、サービスを使う政府機関など(管理基準では「クラウドサービス利用者」)に渡す機能です。利用者が自分で ID と権限を管理し、管理者のログインを強く確かめられるようにします。 ISMAP は、政府の求める対策を満たすクラウドサービスを前もって評価し、一覧に登録する制度です。国家サイバー統括室・デジタル庁・総務省・経済産業省が運営し、府省庁はこの一覧から選んで調達するのが原則です。事業者は登録された監査機関の監査を受けます。リスクの小さな業務に使う、インターネット経由の業務ソフト(SaaS)向けには ISMAP-LIU という仕組みがあり、同じ管理基準をもとにします。 ## 管理基準のどこまでが公開されているか 管理基準は「ガバナンス基準」「マネジメント基準」「管理策基準」の 3 つでできています。管理策基準は、3 桁の番号の統制目標(達成すべき目標)と、4 桁の番号の詳細管理策(目標を満たすための具体的な事項)に分かれます。統制目標は原則としてすべて実施し、詳細管理策は末尾に B の付いたものを除いて、事業者がサービスに合わせて選びます。末尾の P はクラウドに特有の管理策を表します。当てはめようがない統制目標は、理由を示せば対象から外せます。 ISMAP ポータルは、管理基準を読む条件として、JIS Q 27014 と JIS Q 27017 の購入を挙げています。ポータルに載っている管理基準(令和 6 年 8 月 1 日最終改定)は見本で、すべての詳細管理策は載っていません。全部を含む版は、購入していることを書いて請求した人に配られます。この記事の番号と文言は、見本の版で確かめられる範囲のものです。 現行の管理基準は、平成 28 年度版の「クラウド情報セキュリティ管理基準」を土台にしています。これは JIS Q 27001:2014・JIS Q 27002:2014・JIS Q 27017:2016 に沿った基準です。ISMS の仕組みは [ISMS とは](/guides/compliance/what-is-isms)にあります。令和 7 年 12 月には、JIS Q 27001:2023 などを反映し、管理策の数を減らした改定案が公表されました。改定案では管理策が組織的・人的・物理的・技術的・クラウド固有の 5 つに組み替えられ、番号も付け直されます。詳細管理策も原則として実施する形になります。令和 8 年 9 月のスケジュール案では、改定は令和 9 年 5 月で施行日は未定、新旧の基準をしばらく並行して運用します。 ## 事業者のシステムに入る人のアカウントに求めること 見本の版から、事業者のシステムに入る人のアカウントに関わる統制目標を抜き出すと次のとおりです。右の列は管理基準の文ではなく、この記事の例です。 | 統制目標 | 求めていること | 用意する記録の例 | | --- | --- | --- | | 9.2.1 | 利用者の登録と登録削除の正式な手順 | ID の作成と削除の申請・承認 | | 9.2.2 | アクセス権を与える・無効にする正式な手順 | 権限の付与と取り消しの記録 | | 9.2.3 | 管理者権限を与える人と使い方を絞る | 管理者権限を持つ人の一覧 | | 9.2.4 | パスワードなどを渡すときの正式な手順 | 初回のパスワードの渡し方の決まり | | 9.2.5 | アクセス権を決めた間隔で見直す | 見直しの実施記録 | | 9.2.6 | 退職や契約終了で削除し、異動などで直す | 退職日と削除日を並べた記録 | | 12.4.1 | 利用者の活動などを記録し、定期的に見直す | ログインと操作の記録 | | 12.4.3 | 管理者と運用担当者の作業を記録し、見直す | 作業の記録と、その確認の記録 | 見本の版で見るかぎり、こちらの側で原則として実施する詳細管理策は 9.4.2.2.B です。強い認証と本人の確認が必要な場合には、パスワードの代わりに、暗号を使う方法・IC カード・生体認証などを使うよう求めています。どの場合に必要かは、事業者が決めるアクセス制御の方針によります。 管理基準の別紙 1 は、特に手厚く取り組む 4 つの領域の 1 つ目に「アクセス管理(特権の管理、ID 管理、物理セキュリティ等)」を挙げています。管理者権限の考え方は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にあります。 ## 利用者に提供する機能として求めること 見本の版では、利用者の組織が自分でアカウントを管理するための機能や情報の提供も、原則として実施する詳細管理策(末尾 PB)になっています。 - 9.2.1.6.PB と 9.2.2.8.PB: 利用者が自分で ID を登録・削除し、権限を管理できる機能と仕様を提供する - 9.2.3.11.PB: 利用者の管理者のログインに、リスクに応じた強い認証(例として多要素認証)を提供する - 9.2.4.9.PB: パスワードを割り当てる手順など、利用者側の管理手順についての情報を提供する - 9.4.1.8.PB: サービスや利用者のデータに入れる人を、利用者が制限できる仕組みを提供する - 12.4.1.15.PB: 利用者に、記録(ログ)を取る機能を提供する 多要素認証は、パスワードに加えてもう 1 つの方法で本人を確かめることです([多要素認証とは](/guides/access-basics/what-is-mfa))。 管理基準は参考 1 で、事業者がやらなければ政府機関が統一基準を満たすのに支障が出る事項も、事業者への求めに加えたと説明しています。どの詳細管理策がそれに当たるかは、見本の版には書かれていません。政府機関が守る統一基準の側は[政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts)で扱っています。提供側と利用側の分担は [ISO/IEC 27017 の記事](/guides/compliance/iso27017-cloud-account-management)で扱っています。 ## 監査では記録が抜き取りで確かめられる 監査には、ある時点で仕組みが整っているかを見る整備状況評価と、対象期間を通じて決めたとおりに動いていたかを見る運用状況評価があります。手続によっては整備状況評価だけで終わります。対象期間は最大 1 年で、次の申請の対象期間は前回の末日の翌日から始まります。 ISMAP 標準監査手続では、運用状況評価で申請書・承認記録・台帳のような記録を見ます。そのとき監査人は、対象期間の記録全体(監査の語で母集団)から無作為にサンプルを選び、期間を通じて記録が続いているかを確かめます。サンプル数は手順を行う頻度か記録の件数で決まり、たとえば月次なら 2 件、日次なら 25 件です。退職のたびに行う削除のような手順は、期間中の退職者の一覧がそのまま母集団になると読めます。 ## 言明書の個別管理策に共有のアカウントをどう書くか 事業者は言明書で、実施する詳細管理策ごとに、自社で決めた手順(個別管理策)を書きます。言明書は、どの管理策をどう実施しているかを書いて出す文書です。 見本の版には、1 つの ID を複数の人で使う[共有アカウント](/guides/shared-accounts/what-is-shared-account)を禁じる文は見当たりません。全部を含む版までは、この記事では確かめていません。ただ、9.2.1 の登録と削除は、使う人ごとに行う前提に読めます。12.4.1 と 12.4.3 の記録も、共有の ID では誰の作業かが残りません。人ごとの ID を作れるものは、分けたほうが説明しやすくなります。 運用に使う外部の管理画面を言明の対象範囲に含め、そこで ID を人ごとに分けられない場合もあります。そのときは、9.2.1・9.2.6・12.4.1・12.4.3 の下で選んだ詳細管理策の個別管理策に手順を書くことになるでしょう。どれに書くかは全部を含む版で確かめます。中身は、使ってよい人の名前の一覧、誰が入ったかを残す方法、人が抜けた日にパスワードを変える手順などです。方針で強い認証が要るとした画面なら、9.4.2.2.B があるので、パスワードだけで入る運用は説明しにくくなります。 これが運用状況評価の対象になれば、退職者の一覧から抜き取られた人について、パスワードを変えた記録を見せることになります。誰が選ばれるかは分からないので、記録は全員分そろえておきます。 ## よくある質問 **ISMAP の管理基準は誰でも読めますか** ポータルに見本の版が載っていますが、ポータルは JIS Q 27014 と JIS Q 27017 の購入を閲覧の条件にしています。すべての詳細管理策を含む版は、購入していることを書いて請求した人に配られます。 **詳細管理策はすべて実施が必要ですか** 現行版では、統制目標と、末尾に B が付いた詳細管理策は原則として実施します。ほかは選択制で、選ばないものは理由を書きます。改定案では、詳細管理策も原則として実施する形に変わります。 **共有アカウントは ISMAP で禁止されていますか** 見本の版には、共有を禁じる文は見当たりません。ただ、使う人ごとの登録と削除や作業の記録を説明しにくくなるので、管理の手順を個別管理策に書くことになるでしょう。書いた手順は監査で確かめられます。 **アクセス権の見直しはどのくらいの間隔で行いますか** 統制目標 9.2.5 は「定められた間隔」と書き、間隔の数字は示していません。間隔は事業者が決めます。 ## 参考資料 - [ISMAP ポータル「ISMAP 概要」(国家サイバー統括室・デジタル庁・総務省・経済産業省)](https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010005) - [ISMAP ポータル「ISMAP 管理基準」(公開範囲と配布請求の案内)](https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010028) - [ISMAP 運営委員会「ISMAP 管理基準」(令和 6 年 8 月 1 日最終改定、見本の版)](https://www.ismap.go.jp/sys_attachment.do?sys_id=9a9431de2bf9fa90f0bbfd69fe91bfa7) - [ISMAP 運営委員会「ISMAP 標準監査手続」(令和 7 年 4 月 1 日最終改定)](https://www.ismap.go.jp/sys_attachment.do?sys_id=6e6beb192b03c310434ff14a6e91bfac) - [ISMAP ポータル「ISMAP 管理基準改定案」](https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0012199) - [ISMAP 運営委員会「ISMAP 管理基準」改定案(令和 7 年 12 月 25 日時点)](https://www.ismap.go.jp/sys_attachment.do?sys_id=0d69f78a93df07102e57189dc7373ceb) - [国家サイバー統括室・デジタル庁・総務省・経済産業省「ISMAP 管理基準改定案公表後のスケジュール(案)」(令和 8 年 9 月 17 日)](https://www.ismap.go.jp/sys_attachment.do?sys_id=121b73ce93df07102e57189dc7373c00) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有の管理画面での作業を 12.4.3 に沿って見直すには、画面の履歴と作業簿を突き合わせて、どの操作が誰のものかを確かめることになります。Junify では導入時にパスワードを変えて Junify だけが持ち、担当者は自分のスマホで本人確認をして入ります。誰が・いつ入り画面で何をしたかが、一人ずつ AI の要約つきで残るので、見直しではそれを読みます。抜けた人は割り当てを外せば入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # ISO/IEC 27017 がクラウドを使う側と提供する側に求めるアカウント管理 ISO/IEC 27017 は推奨の手引です。パスワードの管理では、クラウドを使う会社には事業者の手順が自社の決まりに合うかの確認を、事業者には手順の情報を出すことを勧めています。ID の登録と権限の付与は事業者にだけ手引があります。 更新日: 2026-10-14 ISO/IEC 27017 は、クラウドサービスの情報セキュリティ対策の手引です。ISMS の管理策(対策の項目)の手引である ISO/IEC 27002 に、クラウドに特有の手引と管理策を足したものです。サービスを使う会社(規格の語ではクラウドサービスカスタマ。以下、利用企業)と、提供する会社(クラウドサービスプロバイダ。以下、事業者)の両方に向けて書かれています。アカウント管理の手引は、管理策ごとに利用企業と事業者のどちらに向くかが分かれます。パスワードの管理(9.2.4)では、利用企業は事業者の手順が自社の決まりに合うかを確かめます。事業者はその手順の情報を出します。この 2 つが対になっています。 ## 認証の基準ではなく手引である 日本語版の JIS Q 27017:2016 は、ISO/IEC 27017:2015 と内容が一致する規格です。その序文は、この規格の指針は JIS Q 27002 の指針に追加して補うものだと書いています。どの管理策を選ぶかは、リスクアセスメント(どこにどんな危険があるかの見積もり)と、法令や契約などの求めで決まります。ISMS 全体の仕組みは [ISMS とは](/guides/compliance/what-is-isms)にまとめています。 日本では、ISMS-AC(情報マネジメントシステム認定センター)の制度として「ISMS クラウドセキュリティ認証」があります。規格そのものは手引で、認証の審査には JIPDEC が定めた JIP-ISMS517 を使います。ISMS-AC が認めた認証機関が、ISMS 認証に加えて 27017 の管理策が導入・実施されているかを審査します。対象は ISMS 認証を持つか取る組織で、立場は利用企業・事業者・その両方のどれでも構いません。SaaS(インターネット経由で使う業務ソフト)を、他社のクラウド基盤の上で提供する会社もあります。JIPDEC のユーザーズガイド追補は、その会社は両方の立場になると説明しています。 版には注意が要ります。ISMS-AC によると、2026 年 7 月 27 日に ISO/IEC 27017:2026 が発行されました。ISO の規格のページでは、2015 年版は廃止(Withdrawn)と表示されています。認証基準の JIP-ISMS517 は JIPDEC が改訂中で、2026 年秋ごろの発行をめどにしています。認証を持つ組織は改訂版へ移る必要があり、移行期間は改訂版の発行後 3 年の予定です。この記事の番号と名称は、いまの認証が使う 2015 年版のものです。なお、ISMS の規格 ISO/IEC 27001:2022(日本語版は現在 JIS Q 27001:2025)では、管理策が 5〜8 の 4 つの箇条に整理し直され、番号が変わっています。新しい番号でのアカウント管理は [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](/guides/compliance/iso27001-access-control-for-saas)にまとめています。2026 年版の番号と中身は、公開資料では確かめられませんでした。 ## アカウント管理の管理策と、手引の向き先 JIP-ISMS517 の参考 A には、適用宣言書(どの管理策を使い、使わないものはなぜかを書く文書)の記入例があります。その表では、27017 に手引がない欄に「−」と「27017 には追加の実施の手引なし」が書かれています。ここから、アカウント管理の管理策ごとに、27017 の追加の手引が利用企業と事業者のどちらにあるかが読み取れます。 | 管理策(2015 年版の番号と名称) | 利用企業への追加の手引 | 事業者への追加の手引 | | --- | --- | --- | | 9.2.1 利用者登録及び登録削除 | なし | あり | | 9.2.2 利用者アクセスの提供 | なし | あり | | 9.2.3 特権的アクセス権の管理 | あり | あり | | 9.2.4 利用者の秘密認証情報の管理 | あり | あり | | 9.2.5 利用者アクセス権のレビュー | なし | なし | | 9.2.6 アクセス権の削除又は修正 | なし | なし | 「なし」は、27002 の一般の手引だけが当てはまるという意味です。ID の登録と権限の付与で事業者にだけ手引があるのは、利用企業の担当者の ID を作る仕組みを事業者が用意するからだと読めます。ただし手引の中身は規格本文にあり、公開資料では確かめられません。一方で、権限の見直しと、退職や異動での削除には、クラウド特有の手引が足されていません。クラウドのサービスでも、社内のシステムと同じ一般の手引に沿って、自社の決まりで行うことになります。 ## パスワードの渡し方で確かめること 9.2.4 の手引は、ユーザーズガイド追補が様式の例として引用しています。利用企業には、パスワードなどを発行して渡す事業者の管理手順が、自社の求めを満たすかを確かめるよう勧めています。事業者には、発行の手順と本人を確かめる手順を含めて、管理の手順の情報を利用企業に出すよう勧めています。どちらも文末は「望ましい」で、必ず行うことではなく推奨の書き方です。 追補は、利用企業向けの手引の大半が「事業者に確かめる」形だが、確かめること自体は目的ではないと説明しています。確かめた結果どれだけ危険が残るかを評価し、足りなければ自社の対策に加える、という流れです。たとえば、サービスが担当者ごとに ID を作れないとします。1 つの ID を数人で使うしかないなら、誰が入ったかを別の方法で残す対策を自社で足すことになるでしょう。 ## 利用の記録と、管理者の権限 追補は、附属書 A(規格の末尾にあるクラウド向けの追加の管理策)の CLD.12.4.5「クラウドサービスの監視」を挙げています。利用企業は、利用を許した人の使い方を確かめる手順を作ります。そのために、記録の種類・見方・保存期間を事業者に確かめることが望まれる、という説明です。追補は、事業者が利用企業向けに用意する管理画面では、見られる監視の項目が限られることが多いとも書いています。 管理者権限については、追補は利用企業の方針(5.1.1)で扱う事柄として、クラウドを動かす側の管理者が強い権限を持つことを挙げています。事業者の側も、自社の管理者が持つ強い権限に起因する危険への対策を、方針に書き足すよう勧められています。管理者用のアカウントの考え方は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にあります。 ## 役割の分担を文書にする 附属書 A には CLD.6.3.1「クラウドコンピューティング環境における役割及び責任の共有及び分担」があります。追補は関連する 6.1.1 について、役割と責任の受け持ちを事業者・供給者・利用企業の間で決め、合意して文書にするよう勧めています。供給者は、事業者がサービスに使う他社のことです。JIP-ISMS517 は、クラウドの危険の最終的な責任は利用企業が持つとしています。そのうえで事業者は自分の管理範囲に責任を持ち、果たしていることを契約を含む取り決めで利用企業に示す必要がある、と書いています。 認証の審査では、適用範囲を書いた文書にクラウドサービスの名前を入れます。27017 の管理策は原則としてすべて評価し、サービスの種類によって当てはまる管理策がない場合だけ除外できます。アカウントについて用意するものの一例は、事業者なら、パスワードの発行と本人確認の手順、利用記録の種類と保存期間を説明する資料です。利用企業なら、その資料を確かめた記録と、足りない分を自社で補う手順です。 ## よくある質問 **ISO 27017 の認証だけを取れますか** ISMS-AC の ISMS クラウドセキュリティ認証では取れません。ISMS 認証(JIS Q 27001)を持つか取る組織が対象で、ISMS の適用範囲の中にクラウドサービスを含めて審査を受けます。 **クラウドを使うだけの会社も対象ですか** 対象です。規格は使う側と提供する側の両方に手引を書いており、認証もどちらか、または両方の立場で取れます。他社の基盤の上で自社の SaaS を提供する会社は両方の立場になります。 **2026 年版が出て、認証はどうなりますか** ISMS-AC は、認証基準 JIP-ISMS517 を 2026 年秋ごろの発行をめどに改訂中で、認証を持つ組織は改訂版への移行が必要としています。移行期間は改訂版の発行後 3 年の予定です。 **退職者の ID 削除にクラウド特有の決まりはありますか** JIPDEC の記入例では、アクセス権の見直しと削除・修正に 27017 の追加の手引はありません。ISMS の一般の管理策どおりに、自社の決まりで行うことになります。 ## 参考資料 - [ISMS-AC「ISMS クラウドセキュリティ認証」](https://isms.jp/isms-cls.html) - [ISMS-AC「ISO/IEC 27017:2026 発行のお知らせ」(2026 年 7 月 28 日)](https://isms.jp/topics/news/20260728.html) - [JIPDEC「ISO/IEC 27017:2015 に基づく ISMS クラウドセキュリティ認証に関する要求事項」(JIP-ISMS517-1.0、2016 年 8 月)](https://isms.jp/doc/JIP-ISMS517-10.pdf) - [JIPDEC「ISMS ユーザーズガイド追補」(JIP-ISMS111-3.0_S1-1.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-3.0_S1-10.pdf) - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [日本規格協会「JIS Q 27017:2016」プレビュー(序文・目次)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27017_000_000_2016_j_ed10_ch.pdf) - [ISO「ISO/IEC 27017:2026」](https://www.iso.org/standard/27017) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** クラウドの管理画面で人ごとに ID を作れないと、誰が入ったかを担当者に表へ書かせ、人が抜けるたびにパスワードを変えて知らせ直す作業が自社に残ります。Junify では導入時にパスワードを変えて Junify だけが持ち、担当者はスマホで本人確認をして入ります。誰がいつ入り何を操作したかが一人ずつ残り、外れた人は割り当てを外せば入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # J-SOX の IT 全般統制の運用評価で、アカウントについて確かめられること 運用評価では、期中に行った利用者の追加・削除・権限の見直しから一部を抜き出し、承認や削除の記録が実際にあるかを確かめます。共有の ID は、本人が使ったことを記録で示せないため、確かめにくくなります。 更新日: 2026-10-14 上場会社の内部統制報告(J-SOX)では、IT 全般統制の運用状況も評価します。この運用評価は、決めたとおりにアカウントが管理されていたかを、期中の記録で確かめる作業です。アカウントでは、利用者の追加、退職・異動時の削除、定期的な見直し、管理者権限の扱いから一部を抜き出し、1 件ごとに承認の記録や削除の日付を見ます。IT 全般統制そのものは [IT 全般統制(ITGC)とは](/guides/compliance/what-is-itgc)にまとめています。管理者用アカウントに絞った話は [IT 全般統制(J-SOX)で管理者用アカウントについて問われること](/guides/privileged-access/itgc-and-privileged-ids)にあります。 ## 整備の評価と運用の評価の違い 評価は 2 段階に分かれます。整備状況の評価は、ルールと仕組みが作られているかを見ます。退職者のアカウントを人事の連絡を受けて削除する手順が文書になっているか、といったことです。運用状況の評価は、そのルールが期中に実際に守られていたかを見ます。 確かめる方法として、金融庁の実施基準は担当者への質問や実施記録の検証などを挙げています。日本公認会計士協会の財務報告内部統制監査基準報告書第 1 号(以下、内基報 1 号)も、この点に触れています。運用が有効だったと裏付けるには、質問だけでは通常足りないとしています。担当者が「退職者はすぐ消しています」と答えても、記録の閲覧など質問以外の方法で裏付けることになります。人の手で行うアカウントの追加や削除なら、申請・承認・削除の記録がそれに当たります。 ## アカウントで確かめられる内部統制 日本公認会計士協会の監査基準報告書 315 は、付録 6 で IT 全般統制の例を挙げ、アクセス管理のプロセスに 8 つの項目を並べています。この記事では、1 件ずつの記録と照らしやすい次の 5 つを取り上げます。左の列は付録 6 の項目の内容で、右の 2 列は、運用評価で抜き出す元の一覧と照らす記録に置き換えた一例です。 | 付録 6 の項目 | 抜き出す元の一覧 | 1 件ごとに照らす記録 | | --- | --- | --- | | 認証 | 利用者 ID の一覧 | その ID を使う人が 1 人か | | 新しい利用者の追加と権限の変更の承認 | 期中に追加・変更した ID | 承認が追加より前にあるか | | 退職・異動時の権限の削除 | 期中の退職者・異動者 | 削除・変更の日付 | | 管理者権限のアクセス | 管理者権限を持つ ID | 持つことの承認と使った記録 | | 利用者のアクセス権の見直し | 期中に行った見直し | 見直した人・日付・直した結果 | 付録 6 の表は、退職や異動をした利用者のアクセス権が「適時な方法で削除又は修正される」ことを、内部統制の例に挙げています。同じ表は、複雑ではない市販ソフトウェアでは、追加のたびの承認や退職時の削除と、定期的な見直しが互いの代わりになりうる、という例も示しています。 ## サンプルの抜き出し方 ここからは、監査人がサンプル(一覧から一部を抜き出したもの)を選ぶときの決まりです。内基報 1 号は、サンプルは選ぶ人の都合が入らない方法で抜き出さなければならないとしています。一覧全体について結論を出すため、特定の項目だけを狙って選ぶ方法も使いません。件数は、許せる逸脱(決めたとおりに行われなかった例)の割合、予想する逸脱の割合、必要な信頼度、一覧の件数から決めます。 実施基準は監査人の手続の例として、1 日に何件も繰り返し起こる取引なら、信頼度 90% を得るには統制上の要点ごとに 25 件以上が要るとしています。信頼度は、抜き出した結果が一覧全体にも当てはまると言える確からしさです。統制上の要点は、評価の対象として選んだ一つひとつの内部統制を指します。内基報 1 号によると、この 25 件は逸脱がないと見込んだ場合の件数で、逸脱がある程度見込まれるなら、監査人は件数を増やすかを検討します。それ以外は、1 日 1 回、週 1 回、月 1 回、年 1 回などの頻度に応じて件数を決めます。年に数回の見直しと、入社や異動のたびに起こる利用者の追加とでは、抜き出される件数が変わりえます。 抜き出す元の一覧も確かめられます。監査基準報告書 315 実務ガイダンス第 1 号(監査人向けの Q&A で、基準そのものではない。以下、ガイダンス)は、会社がシステムで作った情報を監査人が使うときの手続を説明しています。元のデータを帳簿などと突き合わせて、正確さと漏れのなさを確かめるというものです。退職者の削除を確かめるなら、例えば人事の退職者の一覧に漏れがないことが、照らし合わせの前提になると読めます。 ## 共有の ID で示せなくなること 付録 6 は「認証」を、利用者が自分のログイン情報で入っていること(「別の利用者の資格情報を使用していない」こと)を確かめる内部統制として説明しています。1 つの ID とパスワードを複数の人で使っていると、この前提が当てはまりません。ガイダンスは電子承認の例で、「権限者の ID とパスワードをその課の全員が知っている、紙に書いて貼ってある」状況を挙げています。その場合は、現場の観察などで実態をつかむとしています。記録だけでは、権限者本人が承認したかどうかは分かりません。 共有の ID では、退職時の削除も記録で示せません。共有の ID は辞めた人が出ても消さないので、削除の日付が生まれないためです。辞めた人もパスワードを覚えている限り入れるので、示せるのはパスワードを変えた日だけになります。ガイダンスは管理者用の ID の例で、共有されていると誰が会計データを直したか特定しにくいとしています。対応の例には、貸出しと返却を管理して返却後にパスワードを変えること、操作の記録を後から確かめることを挙げています。 ## 評価の時期と、期末までの確認 内部統制の評価時点は期末日です。実施基準によると、期中に運用評価をして期末日までに重要な変更があった場合は、追加の手続を検討します。変更の内容の把握や、変更後の評価などです。変更されて期末日に残っていない内部統制は、評価しなくてよいとも書いています。例えば期中に会計システムを入れ替えた場合、評価の対象は入れ替え後のシステムでの管理になると読めます。内基報 1 号は、監査人の側でも、評価の後から期末日までの有効性を確かめる手続(「ロールフォワード手続」)が要るかを検討するとしています。 記録の保存について、実施基準は、有価証券報告書の縦覧期間(5 年)と同じ程度の期間保存することが考えられるとしています。後日、第三者が検証できるよう、証拠書類を保存する必要があるとも書いています。画面で見られる利用の記録の保存期間が短いサービスなら、評価に使う分を書き出して残します。 ## 逸脱が見つかったとき 運用評価で、退職者の ID が消えていないサンプルが見つかれば、その内部統制には逸脱があったことになります。内基報 1 号は、統計的な方法で抜き出す場合、逸脱が見つかると必要なサンプルの件数が増えることに留意するとしています。 「開示すべき重要な不備」は、内部統制報告書に書いて公表しなければならない重さの不備です。実施基準は、IT 全般統制の不備が、それだけですぐにこれに当たるわけではないとしています。ただし、業務処理統制(取引を正しく処理するために業務に組み込んだ仕組み)を有効に運用し続けられなくなるおそれがあります。不備がある場合は、代わりになる他の内部統制で目的が果たされているかを検討します。不備が見つかれば、すみやかに改善することも求められています。 ガイダンスは管理者用の ID の不備の例で、使われ方を記録で適時に確かめる仕組みが動いていれば、リスクが下がると判断できる場合があるとしています。監査人がアクセスの記録を確かめ、不正な操作がないことを直接確かめられる場合も挙げています。退職者の ID が残っていた場合も、退職後にその ID が使われていないことを記録で示せるかが、次に問われると読めます。共有の ID では、ほかの人も同じ ID を使い続けるため、記録からは辞めた人が使っていないことを示せません。 ## よくある質問 **退職者の削除は、どの一覧から抜き出されますか** 例えば、期中に退職・異動した人の一覧から抜き出し、削除や権限の変更の日付と照らします。元の一覧に漏れがないことが前提になるため、人事の退職者の一覧も確かめられると読めます。 **サンプルは何件抜き出されますか** 監査人は、一覧の件数、許せる逸脱の割合、必要な信頼度などから決めます。実施基準は、1 日に何件も起こる取引で信頼度 90% を得るには、評価の対象に選んだ内部統制ごとに 25 件以上が要るという例を示しています。 **評価に使う記録は何年残しますか** 実施基準は、有価証券報告書の縦覧期間(5 年)と同じ程度の期間の保存が考えられるとしています。サービスの画面で見られる記録の保存期間が短いなら、評価に使う分を書き出して残します。 **期中に評価したあと、期末まで何をしますか** 評価時点は期末日です。期末日までに重要な変更があれば、変更の内容の把握と変更後の評価などの追加の手続を検討します。監査人も、その間の有効性を確かめる手続が要るかを検討します。 ## 参考資料 - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」(2023 年 4 月 7 日改訂)](https://www.fsa.go.jp/singi/singi_kigyou/kijun/20230407_naibutousei_kansa.pdf) - [日本公認会計士協会 財務報告内部統制監査基準報告書第 1 号「財務報告に係る内部統制の監査」(最終改正 2025 年 2 月 13 日)](https://jicpa.or.jp/specialized_field/files/2-24-nkh_1-2-20250214.pdf) - [日本公認会計士協会 監査基準報告書 315「重要な虚偽表示リスクの識別と評価」(最終改正 2024 年 9 月 26 日)](https://jicpa.or.jp/specialized_field/2-24-315-2-20240926.pdf) - [日本公認会計士協会 監査基準報告書 315 実務ガイダンス第 1 号「ＩＴの利用の理解並びにＩＴの利用から生じるリスクの識別及び対応に関する監査人の手続に係るＱ＆Ａ(実務ガイダンス)」(改正 2022 年 10 月 13 日)](https://jicpa.or.jp/specialized_field/files/2-24-315g_1-2-20240805_1.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有の ID には削除の日付がありません。そのため運用評価で退職者が抜き出されるたびに、辞めた後は入れなかったことを別の資料で説明することになります。Junify では導入時にパスワードを変えて Junify だけが持ち、担当者は自分のスマホで本人確認をして入ります。辞めた人は割り当てを外せば入れなくなり、誰が・いつ使ったかの記録から、退職後に使っていないことを一人ずつ示せます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # NIST サイバーセキュリティフレームワーク 2.0 の PR.AA を共有アカウントに当てはめる PR.AA は、建物やシステム、データに入れる人を認められた人に限ることを求め、6 項目に分けています。手段は定めませんが、NIST の例は 1 人 1 つの認証情報を挙げており、共有を残すなら使った人の確かめ方と止め方の説明が要ります。 更新日: 2026-10-14 NIST サイバーセキュリティフレームワーク(CSF)2.0 の PR.AA は、ID の管理、認証、アクセスの管理を扱う分類です。IPA の訳では「アイデンティティ管理、認証、アクセス制御」と呼びます。会社の建物やシステム、データに入れるのを、認められた人・サービス・機器に限ることを求め、6 つの項目に分けています。CSF は手段を決めない文書なので、共有アカウントを禁じる文はありません。ただ、NIST が別に公表している取り組みの例は、1 人に 1 つの認証情報(パスワードなど、本人を確かめるための情報)を挙げています。共有アカウントを残すなら、誰が使ったかをどう確かめ、担当を外れた人をどう止めるかを、自社の言葉で説明できるようにしておきます。 ## CSF 2.0 はどんな文書か CSF 2.0 の文書番号は NIST CSWP 29 で、2024 年 2 月 26 日に NIST(米国国立標準技術研究所)が公表しました。概要には、規模や分野、対策の進み具合を問わず、どの組織でも使えると書かれています。本文は、組織が自ら選んで使う場合と、政府の方針で求められる場合の両方を想定しています。IPA が日本語訳を公開していますが、訳文には NIST の公式な翻訳ではないと断り書きがあります。 CSF の中心は、目指す状態(成果)の一覧です。統治・識別・防御・検知・対応・復旧の 6 つの機能があり、その下に分類、さらに細かい項目が続きます。PR.AA は「防御」の機能に属する分類の一つです。本文は、成果をどう達成するかは定めないと明記し、手段の説明は NIST のウェブサイトにある補足の資料に任せています。2018 年の CSF 1.1 では、同じ領域は PR.AC という分類で 7 項目ありました。2.0 では PR.AA の 6 項目に組み直され、ほかの分類へ移った項目もあります。 ## PR.AA の 6 つの項目 IPA の訳では、PR.AA は、物理的及び論理的資産(建物や機器、データやシステム)へのアクセスが「認可されたユーザー、サービス、及びハードウェアに限定」されている状態です。そのうえで、不正アクセスのリスクに応じて管理されていることを求めます。6 つの項目を言い換えると次のとおりです。 - PR.AA-01: 認められた人・サービス・機器の ID と認証情報を、組織が管理している。 - PR.AA-02: 本人であることを確かめたうえで、ID を認証情報に結びつけている。確かめ方は、使う場面に応じて決める。 - PR.AA-03: 使う人・サービス・機器が本人か確かめられている。 - PR.AA-04: ログインの結果を別のシステムへ伝える情報が守られ、確かめられている。 - PR.AA-05: 誰に何を許すかを決まりで定め、運用し、見直している。権限は必要最小限にし、一人に任せきりにしない分担(職務の分離)を組み込んでいる。 - PR.AA-06: 建物や部屋への出入りを、リスクに応じて管理し、監視している。 04 は一度のログインで複数のサービスに入れる仕組みの中で使う情報の話で、06 は建物の出入りの話です。共有アカウントの扱いに直接かかわるのは、01・02・03・05 の 4 つと読めます。 ## NIST の取り組みの例は何を挙げているか NIST は、各項目の達成の仕方を示す「Implementation Examples」(取り組みの例)を英語で公開しています。CSF の本文は、これを想定上の例と位置づけています。すべての手段の一覧でも、最低限やるべきことの基準でもないという説明です。例のうち、共有アカウントに関わるものを訳すと次のとおりです(この節と次の節の例の訳は、この記事によるもの)。 - PR.AA-01: 社員や社外の作業者のアクセスの申請を起こし、記録・確認して応じる。必要ならシステムやデータの持ち主の許可を得る。認証情報を発行し、管理し、取り消す。 - PR.AA-02: 原文は「Issue a different credential for each person (i.e., no credential sharing)」です。1 人ごとに別の認証情報を発行し、共有しないという例です。 - PR.AA-03: 多要素認証(2 つ以上の方法でログインを確かめること)を求める。パスワードの強さの下限を決める。 - PR.AA-05: 定期的に、また人が役割を変えたり辞めたりしたときに権限を見直し、要らなくなった権限をすぐに取り消す。権限を必要最小限にする。場所や時間帯など、申請した人と対象の性質を見て許可を決める。 ## 共有アカウントに当てはめたときに問われること [共有アカウント](/guides/shared-accounts/what-is-shared-account)(1 つの ID とパスワードを複数の人で使うもの)は、上の 4 項目のそれぞれで説明が要ります。分けられるものは分けるのが先で、分けられない場合の整理は[共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split)にあります。 ### 認証情報を組織が持っているか(PR.AA-01) パスワードがチャットやメモで人から人へ伝わると、会社は今どこにあるかを把握しにくくなります。例にある「取り消す」も、共有のパスワードでは全員の分を一度に変えることになります。 ### 使った人を ID に結びつけられるか(PR.AA-02) 一つのパスワードを複数の人が使うと、サービスの記録の上では全員が同じ ID として残ります。その時間に誰が使っていたかは、記録からは分かりません。例が「共有しない」を挙げるのは、この結びつきを保つためと読めます。共有を残すなら、使う前に本人を確かめ、誰がいつ使ったかを別に残す方法を決めておくことになります。 ### 本人の確かめ方(PR.AA-03) 小規模事業者向けの手引き(SP 1300)は、多要素認証を使えるすべてのアカウントで、多要素認証を求めることを優先するよう勧めています。共有アカウントも例外ではありません。コードが一人のスマホにしか届かない場合、ほかの人はログインのたびにその人に頼むことになります。方式ごとの問題は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にまとめています。 ### 外れた人をすぐに止められるか(PR.AA-05) 共有アカウントには、辞めた人の分だけを取り消す操作がありません。止めるにはパスワードを変えて、残る全員に配り直すことになります。変えるまでの間は、辞めた人もまだ入れます。パスワードを知っている人は全員が同じ権限で使うため、人ごとに[最小権限](/guides/access-basics/what-is-least-privilege)を当てることもできません。 PR.AA の外の項目も関わります。検知の機能の DE.CM-03 は「人員の活動及び技術の利用が監視されている」状態を挙げています(IPA 訳)。共有アカウントでは、記録から使った人を分けられないので、この状態を示しにくくなります。統治の機能で取引の終了後の扱いを定める GV.SC-10 の例には、要らなくなった取引先のアクセスがすぐに止められたかを確かめる、があります。取引先の人も同じパスワードを知っていると、その分だけを止められません。 ## 組織プロファイルに共有アカウントを書く CSF は、組織プロファイル(自社の今の状態と目指す状態を、項目ごとに書き出したもの)を作る使い方を示しています。今の状態を書いたものを現状プロファイル、目指す状態を書いたものを目標プロファイルと呼びます(IPA 訳)。 共有アカウントについては、分けられずに残るアカウントを一覧にし、項目ごとに今の状態を書くと差が見えます。誰がパスワードを知っているか(01)、使った人をどう確かめているか(02)、二段階認証のコードを誰が受けるか(03)、辞めた人をいつ止めているか(05)です。小規模事業者向けの手引きにある「必要な人にだけアクセス及び権限を限定しているか？不要となった場合に、アクセスを取り除いているか？」(IPA 訳)という問いも、この表で答えられます。 CSF の本文は、現状プロファイルを取引先や見込み客に自社の状態を伝えるためにも使えるとしています。共有アカウントの扱いを書いた表は、取引先からセキュリティについて聞かれたときにも使えます。法令や指針の全体像は[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。 ## よくある質問 **CSF 2.0 は共有アカウントを禁止していますか** 本文に禁じる文はありません。CSF は目指す状態を示し、手段は定めない文書です。ただし NIST が公表している取り組みの例は、1 人ごとに別の認証情報を発行し、共有しない方法を挙げています。 **取り組みの例は守らなければいけませんか** CSF の本文は、例は想定上のもので、すべての手段の一覧でも、最低限やるべきことの基準でもないとしています。自社の状態と目標に合わせて選ぶための参考です。 **共有アカウントを残すと何を説明することになりますか** 誰がパスワードを知っているか、使った人をどう確かめるか、二段階認証のコードを誰が受けるか、外れた人をいつ止めるかの 4 つです。PR.AA-01・02・03・05 に当たります。 **日本語で読める資料はありますか** IPA が CSF 2.0 の本文と、小規模事業者向けの手引きなどを日本語に訳して公開しています。訳文には、NIST の公式な翻訳ではないという断り書きがあります。 ## 参考資料 - [NIST「The NIST Cybersecurity Framework (CSF) 2.0」(NIST CSWP 29、2024 年 2 月 26 日)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf) - [IPA「米国国立標準技術研究所(NIST)サイバーセキュリティフレームワーク(CSF)2.0」(日本語訳、2024 年 11 月)](https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000d400.pdf) - [NIST「Framework for Improving Critical Infrastructure Cybersecurity Version 1.1」(2018 年 4 月 16 日)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf) - [NIST「NIST CSF 2.0 Implementation Examples」(2024 年 2 月 26 日)](https://www.nist.gov/system/files/documents/2024/02/21/CSF%202.0%20Implementation%20Examples.pdf) - [IPA「NIST サイバーセキュリティ フレームワーク 2.0:スモールビジネス クイックスタートガイド」(NIST SP 1300 の日本語訳、2024 年 11 月)](https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000d41r.pdf) - [NIST「Cybersecurity Framework」](https://www.nist.gov/cyberframework) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 現状プロファイルの 01 と 02 を書くとき、共有アカウントではパスワードを知る人と使った人を聞いて調べ、05 で人が外れればパスワードを配り直します。Junify に載せたアカウントは、導入時にパスワードを変えて Junify だけが持つので、01 には担当者に渡していないと書けます。02 には担当者がスマホで本人確認して使った記録を示せます。05 は使ってよい人から外せば入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」が求めるアクセス管理と ID 管理 中心は 2.3.1「認証・アクセス管理」です。権限を最小限にして承認した個人に付け、アカウントを作成から終了まで管理して棚卸しし、パスワードを管理し、重要なシステムには外から多要素認証で入り、操作を使った人と結びつけて記録するよう求めます。 更新日: 2026-10-13 金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」で、ID とアクセスの管理の中心は 2.3.1「認証・アクセス管理」です。2.3.1 は、権限を必要最小限にし、承認した個人にだけ付けるよう求めています。アカウントは作成から終了まで管理し、定期的に棚卸し(何があるか一覧にすること)をします。ID とパスワードを管理し、重要なシステムに外から入るときは多要素認証を使います。使った人を特定し、操作の記録と結びつけることも求めています。ログの管理、監視、取引先の管理の節にも、アクセスに関わる項目があります。 ## どんな文書で、誰に当てはまるか ガイドラインは令和 6 年 10 月 4 日に作られ、同じ日から適用されています。令和 7 年 7 月 4 日に一部改正されました。内閣サイバーセキュリティセンターが国家サイバー統括室に改められたことに合わせた技術的な修正です。対象は、監督指針等(金融庁が業態ごとに定める監督の指針など)にサイバーセキュリティ管理の定めがある「金融機関等」です。銀行、保険会社、金融商品取引業者、暗号資産交換業者などのほか、金融商品取引所も含まれます。ガイドラインは、銀行法などの業法が求める業務の健全で適切な運営に、サイバーセキュリティの確保も含まれるとしています。 各節の項目は、「基本的な対応事項」と「対応が望ましい事項」に分かれています。前者は、金融機関等が一般に行う必要のある基礎的な事項です。後者は、事故が起きたときに地域の経済などへの影響が大きい金融機関等で行うことが望ましい取組みです。大手の金融機関などが参考にすべき進んだ取組みも含みます。ガイドラインは、どちらも一律の対応を求めるものではないとしています。そのうえで、自社のリスクを見積もり、それに見合った対策を取ること(リスクベース・アプローチ)を求めています。 意見募集では、特権 ID(管理者用アカウント)の管理を含む認証・アクセス管理を、システムやツールで行う必要があるかが問われました。金融庁は、必要かどうかは個々の状況によると答えています。 ## 2.3.1「認証・アクセス管理」が求めること 2.3.1 には基本的な対応事項が 8 つあり、対応が望ましい事項はありません。人ごとの ID とアクセスの管理に当たるのは、そのうち①〜⑤の 5 つです。残りの 3 つのうち、⑥は第三者による不正を防ぐ取組み(メールの送信元の確認など)、⑧は重要な部屋への出入りの管理です。⑦は一度のログインで複数のサービスに入れる仕組みなど、システム同士のつなぎ目の安全の話なので除きます。 1. 認証とアクセス権の付与について方針と規程を作り、定期的に見直す(①)。踏まえる観点は 4 つです。[権限を必要最小限](/guides/access-basics/what-is-least-privilege)にし、職務を分けることも考えに入れる(たとえば申請する人と承認する人を分ける)。アカウントの「ライフサイクル(作成、使用、終了)」を管理し、定期的に棚卸しと操作の記録の見直しをして、権限のない人の不正使用を防ぐ。特権アカウント(管理者用アカウント)の利用を厳しく制限する。例は多要素認証、操作のダブルチェック、アカウントの時間制限です。外部委託先によるアクセス権の利用を管理する。 2. アクセス権は、業務上の正当な必要があり、承認され、教育・研修を受け、管理されている個人にだけ付与する(②)。 3. ID とパスワードなどの認証情報を管理する(③)。例は、初期パスワードの変更、パスワードの強さの条件、ID の自動失効、システム責任者による定期的なアクセスの見直しです。 4. アクセスを許す前に、その人の権限が適切かを確かめる。そして、アクセスした人を特定できるようにし、処理内容を記録して、その人の操作と対応させる(④)。 5. システムや情報の重要度に応じて、ログインの確かめ方を決める。重要なシステムに外から入るときは、多要素認証(パスワードに加えてもう 1 つの方法で本人を確かめること)を使う(⑤)。 記録を何年残すかなど、ほかの公的な文書との比較は[管理者用アカウントの監査で示せるようにしておく記録](/guides/privileged-access/privileged-access-audit-records)にまとめています。 ## ほかの節でアクセスに関わる項目 2.1.2 は、経営陣がサイバーセキュリティの規程を整え、少なくとも年に 1 回見直すことを求めています。規程に含める事項の例に、認証・アクセス管理とログ管理があります。2.3.4.2「ログ管理」は、記録を取り、監視し、保存する手続を定めることを求めます。手続に含める事項の例は、記録する内容、記録を見られる人の制限、改ざんの防止、保存期間などです。運用担当者の作業の記録が適切かを、定期的に、または必要に応じて確かめることも求めています。 外からの接続については、2.3.4.4 の⑤があります。テレワークや、システムの提供会社による保守で、外から入れるシステムを絞って適切に管理するよう求めています。その例に、利用者の認証と、通信内容を含む記録の取得・保存・監視を挙げています。2.4.1「監視」は、役職員のいつもと違うアクセスの仕方と、外部の事業者による保守作業などのアクセスを監視の対象に挙げています。 取引先の管理は 2.6「サードパーティリスク管理」(取引先から来る危険の管理)にあります。ここでいう取引先には、外部委託先のほか、クラウドなどのサービスの提供会社も含まれます。2.6 はまず、金融機関等にサービスを提供する取引先は、金融機関等の管理に必要な支援をすべきだとしています。金融当局が業法に基づき、特に必要なときは外部委託先に報告を求め、立入検査をする権限を持つことにも触れています。 そのうえで、取引先を管理する台帳には、管理項目の例として、取引先が自社のシステムに持つアクセスの範囲を挙げています。重要度に応じて契約などに書く項目の例には、監査権限や、取引先の役職員が守るルールがあります。取引を終えるときには、データの廃棄と、自社システムへのアクセスを遮断する手順を整えるよう求めています。 ## 共有のアカウントはどう読めるか ガイドラインにも意見募集への回答にも、共有のアカウントを名指しした記述はありません。ただ、②は権限を「個人に対してのみ」付与するとし、④はアクセスした人を特定して操作と対応させるよう求めています。1 つの ID を複数の人で使うと、システムの記録には ID しか残らず、誰が操作したかを記録からは区別できません。共有を続けるなら、使った人を別の手段(たとえば、誰がいつ使ったかを書く貸出の記録簿)で特定できるようにしておく必要があると読めます。 人が辞めるときの扱いも変わります。担当者が個人の ID を持っていれば、退職の日にその ID を止めればアカウントの終了になります。共有の ID は残る人が使い続けるので止められず、パスワードを変えて配り直さない限り、辞めた人も入れる状態が続きます。共有の ID で①の無権限者による不正使用を防ぐには、人が辞めるたびにこの変更と配り直しを続けることになります。 ## どこから確かめるか ガイドラインの項目を自社の点検に置き換えると、次のようになります。 1. 社内で使っているシステムと外部サービスごとに、アカウントの一覧を作る。誰が使えるか、管理者用か、複数人で使っているかを書く。一覧がなければ棚卸しも見直しもできないためです。 2. それぞれのアクセス権に、誰が承認したかの記録があるかを見る。②が承認された個人にだけ付与するよう求めているためです。 3. 退職、異動、委託の終了のときに、誰がどの ID を止めるかを手順にする。共有の ID は、パスワードを変えて配り直す手順まで書く。①がアカウントの終了の管理を、③が ID の自動失効を挙げているためです。 4. 操作の記録から、操作した人までたどれるかを確かめる。あわせて、誰がいつその記録を見直すかを決める。④と 2.3.4.2 が求めるためです。 5. 取引先の台帳に、取引先が持つアクセスの範囲を書く。取引の終了時にアクセスを止める手順も書く。2.6 が台帳の管理項目の例に挙げ、終了時の手順を求めているためです。 ## よくある質問 **このガイドラインに従う義務はありますか** 金融庁が検査や監督の中で使う文書です。ガイドラインは、業法が求める業務の健全で適切な運営にサイバーセキュリティの確保も含まれるとしています。対応は一律ではなく、自社のリスクに見合った対策が求められます。 **金融機関の委託先や SaaS 事業者にも関係しますか** 対象は金融機関等です。ただし 2.6 節は、取引先が金融機関の管理に必要な支援をすべきだとし、重要度に応じて契約に役職員が守るルールや監査権限などを書く例を挙げています。当局が委託先に報告を求める権限にも触れています。 **共有アカウントは禁止されていますか** 共有を名指しした記述はありません。ただし権限は個人に付与し、使った人を特定して操作の記録と結びつけるよう求めているので、共有するなら使った人を別の手段で特定できる必要があると読めます。 **専用のツールを入れる必要がありますか** 意見募集への回答で金融庁は、特権 ID(管理者用アカウント)の管理を含む認証・アクセス管理について、システムでの管理やツールの導入が必要かどうかは個々の状況による、としています。 ## 参考資料 - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日制定、令和 7 年 7 月 4 日改正)](https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf) - [金融庁「「主要行等向けの総合的な監督指針」等の一部改正(案)及び「金融分野におけるサイバーセキュリティに関するガイドライン」(案)に対するパブリックコメントの結果等について」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/20241004.html) - [金融庁「コメントの概要及びコメントに対する金融庁の考え方」(令和 6 年 10 月 4 日、別紙 1)](https://www.fsa.go.jp/news/r6/sonota/20241004/01.pdf) - [金融庁「「金融分野におけるサイバーセキュリティに関するガイドライン」の一部改正について」(令和 7 年 7 月 4 日)](https://www.fsa.go.jp/news/r7/sonota/20250704/20250704.html) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有の管理画面を誰が使ったかを貸出簿に書き、退職や委託終了のたびにパスワードを変えて配り直す作業は、Junify では要りません。導入時にパスワードを変えて Junify だけが持ち、担当者はスマホで本人確認をして入ります。誰が・いつ使ったかと画面の操作は一人ひとり記録され、割り当てを外せばその人はもう入れません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # IPA「組織における内部不正防止ガイドライン」第 5 版のアカウント管理項目 第 5 版の 33 項目のうち、アカウントを扱うのは主に 6 つです。共有 ID を使わない、退職した人の ID をただちに消すなど 5 つを「しなければならない」とし、利用の記録を残す 1 つは「望ましい」としています。 更新日: 2026-10-13 IPA の「組織における内部不正防止ガイドライン」は、IPA の公開ページで配布されている現行版が第 5 版(2022 年 4 月改訂)です。対策は 10 の観点・33 項目あります。そのうち、アカウントとアクセス権(誰がどこまで使えるかの設定)を主に扱うのは、(5)(6)(7)(18)(19)(24) の 6 項目です。共有 ID を使わない、不要になった ID をただちに消すなど 5 つを「しなければならない」とし、利用の記録を残す 1 つを「望ましい」としています。内部不正の定義と 10 の観点は[内部不正とは](/guides/incidents/what-is-insider-threat)にまとめています。 ## 6 項目と、求める強さ 各項目は、枠で囲んだ「対策の指針」、リスク、対策のポイントで書かれています。項目名は原文のままです。文末の意味は、ガイドラインの用語の節が定めています。「ねばならない」「します」「必要です」は必須と考えられる対策、「望ましい」「望まれます」はより強化したい場合の対策です。 | 項目 | 対策の指針が求めること | 文末 | | --- | --- | --- | | (5) 情報システムにおける利用者のアクセス管理 | ID と権限の登録・変更・削除の手順を定めて運用する。異動・退職で不要になったものはただちに削除する | なければならない | | (6) システム管理者の権限管理 | 管理者が複数なら、ID ごとに権限の範囲を分け、互いに監視できるようにする | なければならない | | (7) 情報システムにおける利用者の識別と認証 | 共有 ID・共有のパスワードを使わず、一人ひとりの ID を個別に認証する | なければならない | | (18) 情報システムにおけるログ・証跡の記録と保存 | アクセスと操作の履歴を記録し、定めた期間、安全に保存する | 望ましい | | (19) システム管理者のログ・証跡の確認 | 管理者の記録を保存し、管理者以外が定期的に確かめる | なければならない | | (24) 雇用終了及び契約終了による情報資産等の返却 | 渡していた情報を返させるか消させ、利用者 ID と権限を削除する | なければならない | (18)(19) の「ログ・証跡」は、アクセスや操作の記録のことです。 ガイドラインは法律ではなく、33 項目すべての実施も前提にしていません。事業への影響が小さく、リスクを受け入れられると判断した対策は、必ずしも行う必要はない、と書いています。一方で、資産管理(4-2)・人的管理(4-6)・コンプライアンス(4-7)のリスクには、何らかの対策が要ることが多いとします。不正のあとの法的な手続きで、非が組織ではなく本人にあると示すためです。6 項目のうち (5)(6)(7) は資産管理に、(24) は人的管理に入っています。 ## 共有 ID の扱い (7) は、共有 ID と共有のパスワードを使わず、一人ひとりの ID を個別のパスワードなどで認証するよう求めます。理由として、共有 ID では不正があったときに重要情報にアクセスした人を見分けられず、そのことが持ち出しやすい環境を作る、と説明しています。ID やパスワードを他の人に貸すことも禁じています。 同じ IPA の[中小企業の情報セキュリティ対策ガイドライン](/guides/compliance/ipa-sme-guideline-accounts)は、共有 ID をなるべく使わないとしています。やむを得ず使う場合は、使った人を特定できる仕組みを整えるよう書いています。(7) には、この条件つきの例外の書き方がありません。 サービスの側で ID を分けられない場合も、判断の基準は前の節の事業への影響の大きさです。ガイドラインが判断の基準に置くのは事業への影響で、ID を分けられるかどうかではありません。また、(7) は個別の ID と認証を求めているので、使った人を記録で見分けられても (7) を満たしたことにはなりません。記録で見分けることは、リスクを受け入れたうえで影響を小さくする手当てです。 ## アクセス権を付けるとき、見直すとき (5) の対策のポイントは、手続きの形まで書いています。 - 登録・変更・削除に、承認の手順と設定が終わったことの報告を置く。重要情報へのアクセス権は、その情報の管理責任者の許しを得る - 権限を付ける人、付ける権限、付ける期間を、それぞれ必要最小限にする - 手続きの漏れを防ぐため、人事異動などの人事の手続きと連携させる - 定期的に見直す。人事異動の時期に一斉に見直すことが望まれ、権限が集まっている人は特に確かめる 委託先の従業員に権限を付ける場合は、契約上の措置が要るとしています。その措置は (17)「業務委託時の確認(第三者が提供するサービス利用時を含む)」の項目にあります。(5) の脚注は例として、委託先で異動や退職があったときに体制の変更を報告させ、アカウントの削除漏れを防ぐことを挙げています。 ## 退職・異動のときの削除 (5) は、異動や退職で不要になった ID とアクセス権を「ただちに削除しなければならない」とします。(24) は、雇用と契約の終了時に ID と権限を削除するよう求めています。元の従業員については、削除されたことの確認も求め、テレワーク用の権限も含めるとしています。削除は雇用終了の直後に速やかに行うことが大切だ、とも書いています。日数で区切った期限は書かれていません。 (5) の脚注は、ID を消すと記録も消えるシステムについて書いています。その場合は ID をロックして入れない状態にし、記録を残すことが必要だとしています。(24) はさらに、雇用終了の間際は持ち出しが起きやすいとし、一定期間前から PC などを管理部門の管理下に置くことが望まれる、と書いています。この時期の事案は[退職の直前に顧客情報を持ち出された事案](/guides/incidents/documents-taken-just-before-resignation)で扱っています。 共有 ID では、退職のたびにパスワードを変えて、残る人に伝え直す手間が生じます。ID は他の人が使い続けるので消せず、辞めた人はパスワードが変わるまで入れるためです。ガイドラインの事例集(付録 I)には、元の従業員が退職後に社内のシステムの機密情報に不正にアクセスした事例があります。原因の一つは、退職後も共有アカウントのパスワードが変えられていなかったことです。関連項目には (5)(7)(23) が挙がっています。 ## 利用の記録と、管理者の記録 (18) の文末は「望ましい」ですが、記録する中身は具体的です。重要情報へのアクセス履歴と利用者の操作履歴に加え、クラウドなどの外部サービスにログインしたときの認証と操作の履歴も挙げています。失敗したアクセスだけでなく成功したアクセスも残すと、後日の確認に役立つとしています。 管理者については強さが変わります。(19) は、管理者の記録を管理者以外が定期的に確かめなければならない、とします。記録を集められないシステムでは、管理者の作業を文書に残し、上司などが確かめる方法を挙げています。 ## 自社の運用に当てはめて確かめる点 1. 業務で使うクラウドサービスごとに、ID の一覧と、使ってよい人の一覧があるか。一覧がなければ、(5) の見直しも (24) の削除の確認も、対象を数えられません。 2. 1 つの ID とパスワードを複数の人で使っているサービスがどれか分かっているか。残すなら、リスクを受け入れる理由を記録します。中小企業向けガイドラインの条件にならって、使った人を見分ける方法を決めておくのが、決め方の一例です。 3. 退職・異動の手続きに、サービスごとの ID の削除と、共有のパスワードの変更、その確認が入っているか。(24) は、辞めた人について削除だけでなく、削除の確認も求めています。 4. クラウドサービスのログインと操作の記録を、誰がどの間隔で確かめるか決まっているか。共有 ID では、サービスの記録に残るのは共有 ID の名前なので、誰が操作したかは記録だけでは分かりません。 5. ID を消すと、そのサービスの記録も消えるかを確かめたか。消えるなら、(5) の脚注のとおり、ロックして記録を残す方法を選びます。 ## よくある質問 **内部不正防止ガイドラインの最新版はどれですか** IPA の公開ページで配布されている日本語版は第 5 版で、2022 年 4 月に改訂されたものです。対策は 10 の観点・33 項目で構成されています。 **共有 ID を使うとガイドラインに反しますか** (7) は共有 ID を使わず、一人ひとりの ID を個別に認証しなければならないとし、例外の書き方はありません。事業への影響が小さく、リスクを受け入れられると判断した場合は、対策を行わなくてもよいとしています。 **退職者の ID はいつまでに消せばよいですか** (5) は不要になった ID を「ただちに」、(24) は雇用終了の直後に速やかに削除するとしています。日数で区切った期限は書かれていません。テレワーク用の権限も含めて、削除を確かめるよう求めています。 **利用の記録(ログ)は必ず取るものですか** 利用者の記録を求める (18) の文末は「望ましい」で、付録のチェックシートでも「推奨」の印が付いています。一方、管理者の記録を管理者以外が定期的に確かめる (19) は「しなければならない」です。 **中小企業向けのガイドラインとどう違いますか** 別の文書です。中小企業向けは、やむを得ず使う共有 ID を、使った人を特定できる仕組みを条件に認めています。内部不正防止ガイドラインの (7) には、この条件つきの例外がありません。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「組織における内部不正防止ガイドライン」(公開ページ)](https://www.ipa.go.jp/security/guide/insider.html) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有 ID を分けられないサービスでは、誰が使ったかが分からず、人が辞めるたびに共有のパスワードを変えて配り直すことになります。Junify では、担当者がスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。導入時にパスワードを変えて担当者には渡さないため、退職や異動ではその人の割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # ISMS の担当者が代わるときのアカウントと権限の引き継ぎ 経営者が後任を任命し直し、管理者権限を後任に付けてから、共有パスワードを変え、前任者の権限を外します。審査では、任命と後任の力量の記録、交代前後の権限の一覧、外した記録を示します。 更新日: 2026-10-13 ISMS の管理責任者や事務局が代わるときの作業は、3 つに分かれます。1 つ目は、経営者が後任に役割を割り当て直し、社内に伝えることです。2 つ目は、後任に管理者権限を付け、前任者が知っている共有パスワードを変えてから、前任者の権限を外すことです。3 つ目は、その経過を記録に残すことです。審査では、規格が文書で残すよう明記している記録と、アカウントの管理の記録をあわせて示します。ISMS の仕組みそのものは [ISMS とは](/guides/compliance/what-is-isms)にまとめています。 ## 担当の交代は規格のどこに関わるか ISMS の規格の日本語版は、ISO/IEC 27001:2022 を訳した JIS Q 27001:2023 です(2025 年に追補 1 が出て、いまは JIS Q 27001:2025)。その 5.3 は、トップマネジメント(組織をいちばん上で指揮する経営者)に、役割ごとの責任と権限を割り当てて社内に伝えるよう求めています。 JIPDEC の ISMS ユーザーズガイドによれば、5.3 の a) と b) は、割り当てる役割として次の 2 つを挙げています。1 つは「ISMS が，この規格の要求事項に適合することを確実にする」ことで、規格どおりに ISMS が動くようにする役です。もう 1 つは「ISMS のパフォーマンスをトップマネジメントに報告する」ことで、ISMS がうまく働いているかを経営者に報告する役です。管理責任者や事務局にこの 2 つを任せている組織では、担当の交代は担当者どうしの引き継ぎでは終わりません。経営者が割り当てをやり直す手続きになります。 6.3(変更の計画策定)は、ISMS を変える必要があると決めたときは計画的に変えるよう求めています。ユーザーズガイドは、組織の内部で起きる変化の例として「情報を取り扱う人員の変更」を挙げています。何を、いつまでに、誰から誰へ移すかを先に決めてから進めれば、この箇条に沿った進め方になります。 7.2(力量)は、役割を担う人に必要な力量(知識や技能)を決め、その証拠を文書で残すよう求めています。後任が受けた教育や、持っている資格の記録がこれにあたります。 ## 前任者が持っているものを書き出す 引き継ぎは、前任者が持っているものの一覧から始めます。事務局の担当者が、ISMS の文書を置く場所や社内のサービスの管理者権限を持ち、共有アカウントのパスワードも知っている運用は珍しくないでしょう。一覧がなければ、外し忘れに気づく手段がありません。 日本規格協会が公開している JIS Q 27002:2024 の目次の名称から読むと、書き出すものは次の管理策(規格の末尾の附属書 A に並ぶ対策の項目)に関わります。管理策ごとの読み替えと、規格の本文が有料であることは [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](/guides/compliance/iso27001-access-control-for-saas)に書きました。 - 社内のサービスや ISMS の文書置き場の管理者権限は、8.2 特権的アクセス権に関わります。 - 個々のサービスを使う権限は、5.18 アクセス権に関わります。 - 前任者が知っているパスワードと、二段階認証の登録先は、5.17 認証情報に関わります。 - 資産の一覧で前任者が管理する人として書かれている箇所は、5.9 情報及びその他の関連資産の目録に関わります。 - 役割と担当者の一覧は、5.2 情報セキュリティの役割及び責任に関わります。 ## 移す順番 順番を誤ると、管理者がいないサービスや、辞めた人が入れるサービスが残ります。次の順で進めます。 1. 経営者が後任を任命し、社内に知らせます。5.3 の割り当てと伝達にあたる手続きで、ここが交代の起点になります。 2. 前任者が持っているものの一覧を作り、前任者に確かめてもらいます。前任者しか知らないアカウントは、本人に聞かないと一覧に出てこないからです。 3. 後任に管理者権限を付けます。前任者の権限を先に外すと、設定を変えられる人がいないサービスが残るからです。 4. 前任者が知っている共有パスワードを変え、二段階認証のコードの送り先を後任に替えます。権限を外しても、パスワードを知っていれば共有アカウントには入れるからです。この作業が人の出入りのたびに重なる問題は、[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)で扱っています。 5. 前任者の管理者権限とアクセス権を外します。IPA の内部不正防止ガイドライン(第 5 版)は、異動や退職で要らなくなった利用者 ID とアクセス権を「ただちに削除しなければならない」としています。同じ項の注では、ID を消すと操作の記録まで消える場合は、ID を使えない状態にして記録を残すよう求めています。 6. 役割と担当者の一覧、資産の一覧、社内外の連絡先を書き換えます。一覧が古いままだと、次の交代のときに同じ書き出しを最初からやり直すことになるからです。 前任者が別の部署へ移るだけの場合も、5 は省けません。上に引いた IPA の項は、削除の対象に退職だけでなく異動も挙げています。規格の管理策では、異動した人の権限は 5.18 アクセス権に関わります。 管理者権限を 1 人に集めない工夫も、交代の機会に検討できます。IPA のガイドラインは、システム管理者を複数任命して互いの作業を確かめられるようにすることが望ましいとしています。管理者が 2 人いれば、どちらかが代わっても管理者がいない期間は生まれません。管理者権限の考え方は[特権 ID とは](/guides/privileged-access/what-is-privileged-id)にあります。 ## 審査で示すもの JIPDEC のユーザーズガイドは、規格が「文書化した情報」を明記している箇所を一覧にしています。交代に関わる記録を、その一覧に入っているかどうかで分けると次のようになります。 | 示すもの | 関わる箇条 | 規格が文書で残すよう明記しているか | | --- | --- | --- | | 後任の任命と、社内に伝えた記録 | 5.3 | 明記なし | | 後任の力量の証拠(教育や資格の記録) | 7.2 | 明記あり | | 交代の計画と、計画どおりに進めた記録 | 6.3、8.1 | 6.3 は明記なし、8.1 は明記あり | | 交代前後の権限の一覧と、外した記録 | 附属書 A の 5.18、8.2 | 管理策の本文で確かめる | | 経営者による見直し(マネジメントレビュー)の結果 | 9.3 | 明記あり | 明記がない項目も、組織が必要と決めた記録は ISMS の文書に含まれます(7.5.1)。任命の記録を残しておけば、5.3 の割り当てと伝達をしたことを、審査員に書面で示せます。 マネジメントレビューは、経営者が ISMS を定期的に見直す場です。そこでは、ISMS に関わる内部の課題の変化を扱います。ユーザーズガイドは、その例として組織の変化を含めています。交代を次のレビューで報告すれば、交代の事実と経営者の判断が、9.3 の記録の中に残ります。 担当者の交代を認証機関に知らせる必要があるかは、認証機関との契約で確かめます。交代が決まった時点で契約と規程を見て、分からなければ認証機関に問い合わせます。JIPDEC の FAQ は、会社名や組織名の単純な変更なら登録内容の変更手続きで認証が引き継がれるとしています。そのうえで、合併や組織の変更で運営の体制や適用範囲(ISMS の対象にした部署や業務)が大きく変わる場合は臨時の審査がありうるので、認証機関に問い合わせるよう書いています。届け出の要否は、認証機関との契約と規程で確かめます。 ## よくある質問 **管理責任者の交代は認証機関に届け出ますか** 知らせる必要があるかは、認証機関との契約と規程で確かめます。組織の変更で運営の体制や適用範囲が大きく変わると臨時の審査もありうるので、交代が決まった時点で問い合わせます。 **前任者が社内に残る場合も権限を外しますか** 外します。IPA の内部不正防止ガイドラインは、異動で要らなくなった ID とアクセス権も、ただちに削除するよう求めています。ID を消すと記録も消えるサービスでは、ID を止めて記録を残します。 **後任について何を記録に残しますか** 規格の 7.2 は、役割に必要な力量(知識や技能)を決め、その証拠を文書で残すよう求めています。後任が受けた ISMS の教育や、関係する資格の記録がこれにあたります。 **共有パスワードも交代のたびに変えますか** 変えます。前任者が知っているパスワードは、権限を外しても使えるからです。二段階認証のコードが前任者のスマホに届く設定なら、送り先も後任に替えます。 ## 参考資料 - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [日本規格協会「JIS Q 27002:2024 情報セキュリティ，サイバーセキュリティ及びプライバシー保護―情報セキュリティ管理策」プレビュー(目次。2024 年 6 月 20 日改正)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27002_000_000_2024_j_ed10_ch.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [JIPDEC「FAQ2:認証取得条件」](https://www.jipdec.or.jp/project/smpo/FAQ2.html) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify に登録した共有アカウントなら、事務局の交代は、前任者を使える人から外して後任を加えるだけで済みます。導入時にパスワードを変えて Junify だけが持つので、後任と関係者にパスワードを配り直すことはありません。誰がいつどのアカウントを使ったかも一人ひとり残ります。前任者がパスワードを登録した本人なら、その分だけは交代時に変えて登録し直します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # PCI DSS の要件 8 は共有 ID をどう扱うか(EC 事業者と運用代行の場合) PCI DSS の要件 8 は共有 ID を例外の場面に限り、PCI SSC はそのねらいを、操作を一人ひとりに結びつけることだと説明します。カード情報を持たない EC 事業者も管理画面の二段階認証などを求められ、運用代行もそれに従います。 更新日: 2026-10-13 PCI DSS は、クレジットカードの情報を守るための国際的な基準です。その要件 8 は、システムを使う人を見分け、本人かを確かめる項目です。基準を作る PCI SSC は FAQ で、[共有 ID](/guides/shared-accounts/what-is-shared-account)(1 つの ID を複数の人で使うもの)は例外の場面に限るとしています。FAQ は、そのねらいを、操作の一つひとつを個人に結びつけることだと説明しています。国内の EC 事業者には、カード情報を持たない場合でも、業界のガイドラインが管理画面の二段階認証などを求めています。 ## PCI DSS は誰に当てはまるか PCI DSS の最新版は 2024 年 6 月に公表された v4.0.1 です。基準書は PCI SSC の文書ライブラリで入手でき、日本語版もあります。PCI SSC の説明では、対象はカード会員のデータを保存・処理・送信する事業者と、その環境の安全に影響しうる事業者です。加盟店、決済を処理する事業者、カード会社、サービスを提供する事業者などが含まれます。ただし、準拠や審査を求められるかどうかは、PCI SSC ではなく、カードのブランドや加盟店と契約するカード会社が決めます。 ## 要件 8 は共有 ID をどう扱うか PCI SSC の FAQ によれば、共有 ID の利用は例外の場面で必要なとき以外は防ぎ、使うなら要件 8.2.2 のすべての項目に沿って管理します。対象は「admin」「root」のような管理者のアカウントに限らず、複数の人で使うログイン情報すべてです。 FAQ はその理由として、誰が何をしたかが ID ごとに残れば、不正や誤った操作の原因を絞り込み、被害を早く食い止められることを挙げています。共有 ID では、システムの記録に残るのは ID だけで、その時間に誰が使っていたかは別に調べるしかありません。 そのうえで FAQ は、管理の作業で共有 ID を限って使うために、道具やパスワードを保管する仕組みを使ってよいとしています。そうした仕組みで、使う人の本人確認をし、一人ひとりの責任と記録を保てるという説明です。使い道の例には、緊急時にだけ使う管理者アカウントが挙がっています。 ## 要件 8 のほかの項目で、共有 ID だと守りにくいもの PCI SSC の FAQ は、要件 8 のほかの項目を次のように説明しています。 | 項目 | FAQ の説明 | | --- | --- | | 使われていないアカウント | 90 日を超えて使われていないもので、削除か無効にすると危険が減る | | 8.3.9 パスワードだけで入る場合 | 少なくとも 90 日ごとに変えるか、アカウントの状態を常に分析して入れるかをその場で決める | | 8.4.2 2 つ以上の方法での確認 | カード会員データを扱う環境に入るすべての利用で求められる | 共有 ID では、この 3 つが守りにくくなります。誰かが使い続けるので、辞めた人が知っている ID でも使われていない扱いになりません。パスワードを変えれば全員へ配り直し、2 つめの確認の手段も全員が受けられるようにしなければなりません。なお FAQ によれば、8.3.9 は 2 つ以上の方法で確かめている利用には当てはまりません。 ## EC 事業者に求められること 国内には、クレジット取引セキュリティ対策協議会の「クレジットカード・セキュリティガイドライン」(6.1 版)があります。割賦販売法が求める措置の、実務の指針とされています。ガイドラインの措置か、それと同等以上の措置を行っていれば、法律の「必要かつ適切な措置」を行っているとみなされます。 EC 加盟店に求められるのは、カード情報を持たない「非保持化」か、持つ場合の PCI DSS 準拠です。非保持化とは「自社で保有する機器・ネットワークにおいて『カード情報』を『保存』『処理』『通過』のいずれも行わないこと」です。PCI DSS に準拠した決済代行会社の決済画面に移す方式などで実現できます。 ただし、ガイドラインは、カード情報を持つかどうかにかかわらず、EC サイトの「脆弱性対策」(弱いところをふさぐ対策)をすべて行うよう求めています。非保持化した店でも、管理者の権限の管理などの不備からカード情報が漏れた事案があるためです。ガイドラインの本文は、管理画面について次の 3 つを挙げています。 1. 管理画面に入れる IP アドレスを限る。限れない場合は、ベーシック認証(ブラウザーが出す ID とパスワードの入力)などを設ける 2. 二段階認証か多要素認証(2 つ以上の方法でログインを確かめる仕組み)を使う 3. ログインに 10 回以下失敗したらアカウントをロックする 附属文書(EC 加盟店向けの対策一覧)の表には、もう 1 つ対策が並びます。管理画面の URL や ID・パスワードを、admin のような推測されやすいものにしないことです。表では、IP アドレスの制限(またはベーシック認証)と、推測されにくい URL・ID・パスワードは、両方入れるのが原則です。システムの都合で無理なときだけ、どちらか 1 つが必須になります。二段階認証か多要素認証はどちらかが必須、ロックは必須です。 ガイドラインは共有 ID には触れていません。ただ、管理画面の ID を何人かで使い、二段階認証のコードが登録した 1 台にしか出ない設定なら、ほかの人はその持ち主に頼むことになります。方式ごとの問題は[共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification)にまとめています。 ## 運用代行やシステム会社に求められること ガイドラインは、委託先の管理について 3 つの場面を書いています。カード情報を扱う業務を外に出すときは、PCI DSS に準拠しているなど必要な対策をとる事業者を選び、契約後も実施の状況を確かめます。EC システムや Web サイトの構築・運用を外に出すときは、加盟店が行う脆弱性対策を理解したうえで作業するよう、委託先に求めます。複数の委託者からカード情報を扱う業務を受ける事業者は、自社のシステムでのカード情報の持ち方を確かめます。そのうえで PCI DSS 準拠などの対策をとります。 決済の仕組みを運営して EC 加盟店に提供する会社には、PCI DSS に準拠し、それを保つことが求められています。ガイドラインが「EC システム提供会社」と呼ぶ事業者です。 店舗の管理画面で受注や商品を扱う運用代行は、2 つめの場面に近い立場です。管理画面の二段階認証やロックは店の側の対策なので、運用代行の担当者もそれに従います。担当者ごとの ID を作る機能があれば、まずそれを使います。モールの例は[楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](/guides/agency-accounts/ec-mall-store-admin-access)で扱っています。 PCI SSC の FAQ には、カード情報を持ち PCI DSS に準拠する店が外部の事業者を使う場合の説明があります。外部の事業者が店の代わりに要件を満たしているなら、その事業者の準拠の状況が店の準拠に影響します。外部の事業者は、どの要件を自社と顧客のどちらが受け持つかを顧客に示すことになっており、その道具に責任の分担表が挙がっています。この考え方は管理画面のアカウントにも使えます。ID を発行する人、二段階認証のコードを受ける人、担当を外す人を表にしておけば、店と運用代行のどちらが聞かれても答えられます。 ## 共有 ID を残すときに決めておくこと 担当者ごとの ID を作れない管理画面で、FAQ の考え方に沿って共有 ID を残す場合の決め方の一例です。 1. 共有 ID が残る管理画面と、分けられない理由を一覧にする。例外として扱うには、どれが例外かが分かっている必要があるためです。 2. 使う前に本人を確かめ、誰がいつ使ったかを残す方法を決める。FAQ が道具でできることとして挙げる、本人確認と一人ひとりの記録に当たります。 3. 担当を外れた人が入れなくなる手順を決める。共有のパスワードを本人が知っていると、変えて配り直すまで入れる状態が続くためです。 4. 二段階認証のコードを誰がどう受けるかを決める。1 人の端末にしか届かないと、その人がいない日は作業が止まるためです。 ## よくある質問 **PCI DSS は共有 ID を禁止していますか** 禁止ではありません。PCI SSC の FAQ は、例外の場面で必要なときに限って使い、要件 8.2.2 のすべての項目に沿って管理するよう求めています。管理者用に限らず、すべての共有 ID が対象です。 **カード情報を持たない EC 事業者にも関係しますか** 国内のガイドラインは、カード情報を持たない店にも管理画面の対策を求めています。入れる場所を限る、推測されにくい ID とパスワードにする、二段階認証か多要素認証を使う、10 回以下の失敗でロックする、などです。 **運用代行会社も PCI DSS に準拠する必要がありますか** カード情報を扱わず管理画面を操作するだけなら、店の対策(二段階認証やロック)に従う立場です。複数の委託者からカード情報を扱う業務を受けるなら、国内のガイドラインは PCI DSS 準拠などを求めています。 **共有 ID でも記録を残せば認められますか** FAQ は、管理の作業では、本人確認と一人ひとりの記録を保てる道具やパスワードを保管する仕組みを使ってよいとしています。ただし、使うのは例外の場面に限り、8.2.2 のすべての項目に沿って管理することが前提です。 ## 参考資料 - [PCI SSC「PCI Data Security Standard (PCI DSS)」](https://www.pcisecuritystandards.org/standards/pci-dss/) - [PCI SSC「Document Library: PCI DSS」(PCI DSS v4.0.1、2024 年 6 月。日本語版あり)](https://www.pcisecuritystandards.org/document_library/?category=pcidss&document=pci_dss) - [PCI SSC ブログ「Just Published: PCI DSS v4.0.1」(2024 年 6 月 11 日)](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1) - [PCI SSC FAQ 1080「Does PCI DSS Requirement 8.2.2 allow users to share authentication credentials?」](https://www.pcisecuritystandards.org/faqs/does-pci-dss-requirement-8-2-2-allow-users-to-share-authentication-credentials/) - [PCI SSC FAQ 1066「What is an "inactive user account" as used in PCI DSS Requirement 8?」](https://www.pcisecuritystandards.org/faqs/1066/) - [PCI SSC FAQ 1590「Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?」](https://www.pcisecuritystandards.org/faqs/1590/) - [PCI SSC FAQ 1591「Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication…」](https://www.pcisecuritystandards.org/faqs/1591/) - [PCI SSC FAQ 1473「What is the role of compliance-accepting entities and assessors…」](https://www.pcisecuritystandards.org/faqs/1473/) - [PCI SSC FAQ 1312「How is an entity's PCI DSS compliance impacted by using third-party service providers (TPSPs)?」](https://www.pcisecuritystandards.org/faqs/1312/) - [PCI SSC FAQ 1576「What evidence is a TPSP expected to provide to customers to demonstrate PCI DSS compliance?」](https://www.pcisecuritystandards.org/faqs/1576/) - [クレジット取引セキュリティ対策協議会「クレジットカード・セキュリティガイドライン【6.1 版】」(2026 年 3 月)](https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines_6.1_published.pdf) - [クレジット取引セキュリティ対策協議会「EC 加盟店におけるセキュリティ対策一覧 1.1 版」(附属文書 20 別紙 a、2026 年 3 月)](https://www.j-credit.or.jp/security/pdf/supporting_document_a.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 管理画面の ID を共有すると、認証コードを持ち主に聞く、使った人を表に書く、担当が抜けたらパスワードを変える、が手作業で続きます。Junify は導入時にパスワードを変えて Junify だけが持ち、担当者はスマホで本人確認をして入るので、誰が・いつ使ったかが残ります。認証アプリにコードが出る方式なら Junify が入力し(SMS・メールは対象外)、担当を外すときは割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか 台帳は法律の義務ではなく、プライバシーマークは「アクセス権を有する者」を求めますが、細かさは決めていません。台帳には部署と役割を書き、氏名とアカウントは別の一覧に分けると直し漏れが減ります。 更新日: 2026-10-13 個人情報の管理台帳に書く「アクセス権を有する者」は、プライバシーマークでは必ず含める項目です。ただ、氏名まで書くか、部署名で足りるかは、指針に定めがありません。個人情報保護法は、台帳そのものを義務づけていません。台帳には部署と役割を書き、人とアカウントの対応は別の一覧に分けて、台帳から参照します。こうすると、担当者が代わるたびに台帳を直さずに済みます。 ## 法律とプライバシーマークで求められること 個人情報保護委員会の Q&A(Q10-10)は、いわゆる「個人情報取扱台帳」を作ることは義務ではない、と答えています。義務になっているのは、個人データの取扱状況を確かめる手段を整えることです。同委員会のガイドライン(通則編)の別添では、[組織的安全管理措置](/guides/compliance/what-is-security-control-measures)(社内の体制やルールで個人データを守る対策)の (3) に当たります。その手法の例示には、あらかじめはっきりさせておく項目が並んでいます。データベースの種類と名称、個人データの項目、責任者・取扱部署、利用目的、「アクセス権を有する者」などです。Q&A は、扱っている個人データをこうしてはっきりさせることを、取扱状況をつかむうえで有効な取組としています。 プライバシーマークの側は、もっと具体的です。JIPDEC の構築・運用指針の J.3.1.1(個人情報の特定)は、台帳を整え、少なくとも 8 つの項目を含めることを求めています。「アクセス権を有する者」はその 1 つで、保管場所や保管方法と並びます。台帳は少なくとも年 1 回と、必要に応じて確認し、最新に保ちます。指針が台帳のほかにアカウントの管理について求めることは、[プライバシーマーク(JIS Q 15001)でアカウント管理について求められること](/guides/compliance/privacy-mark-account-management)にまとめています。 | 比べる点 | 個人情報保護法(通則編・Q&A) | プライバシーマーク(構築・運用指針) | | --- | --- | --- | | 台帳を作ること | 義務ではない。取扱状況を確かめる手段は必要 | 必要 | | 「アクセス権を有する者」 | 手段の例示の 1 つ | 台帳に必ず含める項目 | | 見直し | 取扱状況の把握と安全管理措置の見直しが必要 | 少なくとも年 1 回と、必要に応じて | どちらの文書も、「アクセス権を有する者」を氏名で書くか、部署や役割で書くかまでは決めていません。指針の留意事項は、台帳の整備は取扱いの状況をつかむための手段であって目的ではない、と書いています。細かさは、この目的から決めることになります。 ## 台帳には役割を、氏名とアカウントは別の一覧に 台帳の 1 行は、個人情報の項目ごとに作ります。顧客名簿、応募者の情報、従業員の給与の情報といった単位です。一方でアカウントは、システムやクラウドサービスごとにあります。1 つの名簿が複数のサービスに入っていることも、1 つのサービスに複数の名簿が入っていることもあるでしょう。しかも担当者は、名簿やサービスが変わらなくても入れ替わります。氏名を台帳の各行に直接書くと、1 人の異動で何行も直すことになり、直し漏れが出やすくなります。 決め方の一例として、台帳と一覧を次のように分けます。 | 決める点 | 個人情報の台帳 | アカウントの一覧 | | --- | --- | --- | | 1 行の単位 | 個人情報の項目 | サービスとアカウント | | 使える人の書き方 | 部署と役割。一覧の名前を書いて参照する | 氏名と権限の種類 | | 直すきっかけ | 項目・利用目的・保管場所が変わったとき | 入社・異動・退職、委託の開始と終了 | このように分けても、2 つを合わせれば「この名簿に、いま誰が入れるか」に氏名で答えられます。通則編の組織的安全管理措置(1)の手法の例示にも、関係する項目があります。個人データを扱う従業者とその役割、その従業者が扱う個人データの範囲をはっきりさせることです。役割で台帳を書き、氏名を一覧に置く形は、この例示とも合っています。 アカウントの一覧には、権限の種類も書きます。通則編の技術的安全管理措置(システムの設定や仕組みによる対策)の (1) はアクセス制御です。その手法の例示には、ユーザー ID に付けるアクセス権で、システムを使える従業者を限ることが入っています。同じサービスでも、見るだけの人、データを書き出せる人、ほかの利用者を追加できる管理者がいます。アカウントが悪用されたときに持ち出せる範囲は、この 3 つで違います。一覧の項目は、[共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory)が参考になります(その記事では、アカウントの一覧を台帳と呼んでいます)。 1 つの ID を複数の人で使う[共有アカウント](/guides/shared-accounts/what-is-shared-account)は、書き方が変わります。サービスの利用者一覧には ID の名前しか出ないので、その先にいる人は自社の一覧でしか分かりません。そのため、共有アカウントの行には、使う人の氏名を並べます。年 1 回の確認では、サービスの利用者一覧と自社の一覧を突き合わせます。共有アカウントの行は、その部署に聞いて確かめます。 ## 保管場所にクラウドサービスを書くとき 保管場所の欄にクラウドサービスを書くときは、サービス名に加えて、2 つのことを確かめて書き添えます。 1 つ目は、サービスを提供する事業者が、保存した個人データを取り扱うことになっているかどうかです。Q&A(Q7-53)によると、第三者への提供や委託に当たるかの基準は、保存したデータに個人データが含まれるかではありません。事業者が個人データを取り扱うことになっているかです。取り扱わないことになっている例は、契約でそう定め、適切にアクセス制御をしている場合です。取り扱うことになっていれば、事業者に個人データを渡したことになります。委託として扱うなら、委託先の監督(プライバシーマークでは J.9.4)の対象に入ります。取り扱わない場合も、使う側が自分で安全管理措置を行う必要があります(Q7-54)。 2 つ目は、事業者とサーバーがどの国にあるかです。Q&A(Q10-25)は、外国の事業者のクラウドサービスを使う場合を扱っています。事業者が個人データを取り扱わない場合でも、その国の制度を把握したうえで安全管理措置を行うよう求めています。サーバーが国内にあっても同じです。そのうえで、事業者のある国とサーバーのある国の名称を、本人が知り得る状態に置くことも求めています。台帳に国まで書いておけば、次の公表の内容をそこから作れます。 ## プライバシーポリシーに載せる範囲 台帳やアカウントの一覧そのものを公表する決まりはありません。求められているのは、保有個人データの安全管理のために行った措置を、本人が知り得る状態に置くことです。保有個人データは、自社に開示や削除などを行う権限がある個人データのことです。根拠は個人情報保護法 32 条 1 項 4 号と施行令 10 条 1 号です。知り得る状態とは、本人が知ろうとすれば知ることができる状態で、求められたときに遅れずに答える形も含みます。ただし、知られると安全管理に支障が出るおそれのあるものは除かれます。 通則編 3-8-1 は、載せる内容の例を挙げています。技術的安全管理措置の例は「アクセス制御を実施して、担当者及び取り扱う個人情報データベース等の範囲を限定」です。一方で、支障を及ぼすおそれのある例には「アクセス制御の範囲、アクセス者の認証手法等」を挙げています。アクセス制御をしていることは書き、誰がどのシステムに入れるかや、ログインをどう確かめているかは書かない、という線引きです。通則編は、ガイドラインに沿って措置を行っている、と書くだけでは適切でないともしています。概要をホームページに載せ、残りは問い合わせに答える形でもかまいません。 ## よくある質問 **個人情報の管理台帳は法律で義務ですか** 義務ではありません。個人情報保護委員会の Q&A(Q10-10)がそう答えています。ただし、個人データの取扱状況を確かめる手段を整えることは義務で、扱う個人データを一覧ではっきりさせることは有効な取組とされています。 **台帳に担当者の氏名まで書く必要がありますか** プライバシーマークの指針は細かさを決めていません。台帳には部署と役割を書き、氏名とアカウントは別の一覧に置いて、台帳から参照する方法があります。2 つを合わせれば、誰が入れるかに氏名で答えられます。 **プライバシーポリシーに台帳の中身を載せますか** 台帳を載せる決まりはありません。公表するのは安全管理のために行った措置で、概要を載せ、残りは問い合わせに答える形でもかまいません。アクセス制御の範囲や認証の方法は、載せると支障が出るおそれのある例です。 **保管場所にクラウドサービスはどう書きますか** サービス名に加えて、事業者が保存した個人データを取り扱うことになっているか、事業者とサーバーがどの国にあるかを書き添えます。委託に当たるかと、公表する内容の判断に使います。 ## 参考資料 - [JIPDEC「プライバシーマークにおける個人情報保護マネジメントシステム構築・運用指針【JIS Q 15001:2023 準拠 ver1.0】」(2023 年 12 月 25 日制定)](https://privacymark.jp/guideline/pm_shishin2023v1.0.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」(令和 7 年 7 月 1 日)](https://www.ppc.go.jp/personalinfo/faq/APPI_QA/) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 共有アカウントの行に並べた氏名は、年 1 回の確認のたびに部署へ聞いて確かめ直すことになります。Junify に登録したアカウントは、導入時にパスワードを変えて Junify だけが持ち、管理者がアカウントごとに使う人を決めます(割り当て)。使えるのは割り当てた人だけなので、その画面の氏名を台帳から参照する一覧にでき、聞いて回る必要はありません。誰が・いつ使ったかも一人ずつ残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # SOC 2 の論理アクセスの規準(CC6.1〜6.3)を SaaS のアカウント管理に当てはめる CC6.1 は情報資産へのアクセスを仕組みで制限すること、CC6.2 は承認してから ID を発行し不要になれば消すこと、CC6.3 は役割に応じた最小限の権限を求めます。SaaS では一覧・申請と削除の記録・定期の見直しに当たります。 更新日: 2026-10-13 SOC 2 の検証で使う Trust サービス規準には、「論理的及び物理的アクセス管理」の項目群(CC6)があります。そのうち CC6.1〜6.3 が、システムに入れる人とその権限を扱います。社内で使う SaaS に置き換えると、使える人の一覧、ID の発行と削除の手続、権限の種類と見直しの 3 つです。SOC 2 の仕組みそのものは [SOC 2 とは](/guides/compliance/what-is-soc2)にまとめています。規準と着眼点の文言は、日本公認会計士協会の翻訳(AICPA 2017 年版)によります。 ## 着眼点の扱い 各規準には「着眼点」が付いています。規準を満たしているかを見るときの観点で、規準そのものではありません。翻訳の前書きは、着眼点が組織に合わなければ変えてよいとし、「各着眼点が対処されているかどうかの判定が必要となるわけではない」と書いています。満たすのは規準の文で、着眼点は自社の手続を組み立てるときの手がかりです。 AICPA は、着眼点を改訂した版を「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」の題で公表しています。題のとおり、規準は 2017 年版のままで、改められたのは着眼点と読めます。一方、日本公認会計士協会の翻訳は、2018 年に公表した研究資料と同じ内容で、この改訂を含みません。以下で挙げる着眼点は、改訂前の翻訳によるものです。 ## どの SaaS が対象になるか 翻訳の前書きは CC6.4 を例に、規準が当てはまるのは、SOC 2 の検証の範囲に入るシステムに関わる管理に限られると説明しています。CC6.1〜6.3 も同じように読めます。用語集では、システムは、サービスを提供するために一体で動く設備(サーバーやネットワーク)、ソフトウェア、人、手順、データを指します。そのため、自社のサービスそのものだけでなく、その運用に使う SaaS も範囲に入りえます。クラウドの管理画面、顧客からの問い合わせを扱うツール、提供中のサービスのデータに触れる管理ツールなどです。範囲は、経営者がまとめるシステムの記述書(検証の対象を説明する文書)で示されます。 ## CC6.1 情報資産へのアクセスを仕組みで制限する CC6.1 は、論理的なアクセス(ネットワークや画面を通じてシステムに入ること)の安全対策を導入し、セキュリティ上の出来事から情報資産を守ることを求めます。翻訳では着眼点が 10 あり、SaaS のアカウント管理に当てはめやすいのは次の 4 つです。 - 「情報資産の識別・台帳の作成・管理」: 守る対象を一覧にする - 「論理的なアクセスの制限」: 管理者の権限を含むアクセスを、仕組みと決まりで制限する - 「ユーザーの識別及び承認」: アクセスの前に、人を識別し承認する - 「識別及び認証の管理」: 識別と本人確認の決まりを作り、文書にして管理する SaaS に置き換えると、まず範囲に入る SaaS の一覧を作ります。次に、各 SaaS に誰の ID で入るかを決め、管理者の権限を使える人を限ります。ログインの方法(二段階認証を必ず使うか、Okta や Microsoft Entra ID のような ID 管理サービスを通すか)は、文書にした決まりとして示します。 ## CC6.2 承認を得て ID を発行し、不要になれば消す CC6.2 は、新しい利用者を登録・承認してから、ID やパスワードなどログインに使う情報(翻訳では「システム資格」)を発行することを求めます。アクセスが承認されなくなったら、それを削除します。社員だけでなく、外部の利用者も対象です。着眼点は次の 3 つです。 - 資産のオーナー(その SaaS の責任者)か、承認された管理者の許可を得て ID を作る - もう要らなくなった ID を削除する手順を整える - 付ける必要のない人に ID が付いていないかを、定期的に見直す SaaS では、申請と承認の記録、削除の記録、見直しの記録がこれに当たります。見直しの頻度は規準に書かれていません。用語集は、システムに求められることの例として、次を挙げています。 > セキュリティポリシー・マニュアルに文書化された就業者の論理的アクセスの定期的なレビューとしての許容される最大の間隔 間隔は自社の規程で決め、その間隔どおりに見直したかが問われると読めます。 ## CC6.3 役割に応じて権限を付け、変え、外す CC6.3 は、役割や責任などに基づいて、組織がアクセスを承認し、変え、削除することを求めます。そのとき、最小権限の原則と職務分離(1 人で完結させない役割分担)を考えます。考え方は[最小権限の原則とは](/guides/access-basics/what-is-least-privilege)にあります。着眼点は次の 3 つです。 - 資産のオーナーの承認に基づいて、アクセスを作る・変える手順を整える - もう要らなくなったアクセスを外す手順を整える - 兼務できない職務を分けるために「役割ベースのアクセス管理」(役割ごとに権限の組み合わせを決めて付ける方法)を行う CC6.2 が ID の有無を扱うのに対し、CC6.3 は ID に付ける権限の中身を扱います。SaaS には、閲覧・編集・管理者のような権限の種類を用意しているものがあります。職務ごとにどの種類を付けるかを表にしておけば、異動のときに外す権限と付ける権限がその表から決まります。管理者の権限を持つ人を絞り、権限を付ける人と付けてもらう人を分けることが、職務分離の一つの形です。 ## 共有アカウントは 3 つの規準のどこで説明しにくくなるか 翻訳に「共有アカウント」の語はありません。ただ、1 つの ID を複数の人で使う状態([共有アカウント](/guides/shared-accounts/what-is-shared-account))では、3 つの規準のそれぞれで説明が難しくなります。CC6.1 の着眼点は、入る前に人を識別することを挙げています。共有の ID では、ログインの記録から分かるのは ID だけで、使った人は分かりません。CC6.2 では、1 人を外すにはパスワードを変えて、残る人に配り直すことになります。CC6.3 では、権限が ID に付くので、使う人全員に同じ権限が渡ります。 対応は 2 段になります。SaaS が人ごとの ID と権限の種類を用意しているなら、まず個人の ID に分けます。分けられない管理画面などは、3 つを決めます。使える人の一覧、使うたびに誰が使ったかを残す手段、人が抜けたときにパスワードを変える手順です。そのうえで、規準の文をどう満たすかを説明できるようにします。権限の絞り方は[最小権限の原則を SaaS の共有アカウントに当てはめる](/guides/access-basics/least-privilege-for-shared-saas-accounts)で扱っています。 ## Type 2 の期間中に残しておく記録 Type 2 の報告書(期間を通じて運用を確かめる報告書)には、その期間を対象に監査人が行ったテストとその結果が載ります。手続を文書にするだけでなく、期間中に手続を実際に行ったことを示す記録を残しておくことになります。CC6.1〜6.3 について用意するものを、決め方の一例として挙げます。 1. 範囲に入る SaaS の一覧と、SaaS ごとの ID と権限の一覧。SaaS の一覧は CC6.1 の着眼点にある台帳に当たり、ID と権限の一覧は見直しの元になります。 2. ID の発行と権限の変更について、申請と承認の記録。CC6.2 と CC6.3 は、どちらも着眼点にオーナーの承認を挙げています。 3. 退職・異動の日と、ID や権限を外した日を並べた記録。承認されなくなったときに削除したことを示せます。 4. 規程で決めた間隔での見直しの記録。CC6.2 の定期的な見直しに対応します。 CC6.1〜6.3 の外にも、アカウントに関わる規準があります。CC6.6 の着眼点は、システムの境界の外から入るときに追加の認証を求めることを挙げています。CC7.2 の着眼点は、ID とパスワードなどの「識別及び認証資格の不正使用」で起きる異常を見つける対策を挙げています。共有アカウントでは誰が入ったかが記録に残らないため、正しい利用と不正な利用を記録から区別しにくくなります。 ## よくある質問 **CC6 の着眼点はすべて満たす必要がありますか** 必要ありません。翻訳の前書きは、各着眼点に対処したかの判定は求められないとし、組織に合わせて変えてよいとしています。満たすのは規準の文で、着眼点は手続を組み立てる手がかりです。 **アクセスの見直しは何か月ごとに必要ですか** 規準にも着眼点にも頻度は書かれていません。用語集は、見直しの最大の間隔を自社の規程に書く例を挙げています。決めた間隔どおりに見直し、その記録を残します。 **共有アカウントがあると SOC 2 は受けられませんか** 規準に共有を禁じる文はありません。ただ、使った人の識別と、1 人だけ外す手順の説明が難しくなります。人ごとの ID に分けられる SaaS は分け、残るものは一覧と記録で補います。 **社内で使う SaaS はすべて対象ですか** 対象は検証の範囲に入るシステムに限られます。サービスの運用に使い、顧客のデータや、提供中のサービスの設定に触れる SaaS は範囲に入りえます。範囲はシステムの記述書で示します。 ## 参考資料 - [日本公認会計士協会「セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準」(AICPA 2017 年版の翻訳、2022 年 12 月 28 日)](https://jicpa.or.jp/specialized_field/ITI/files/0-51-0-2a-20221228.pdf) - [日本公認会計士協会「AICPA『セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準』の翻訳の公表について」](https://jicpa.or.jp/specialized_field/ITI/2022/20221228tzq.html) - [AICPA & CIMA「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** 分けられない管理画面を共有のまま Type 2 の対象期間に入ると、誰かが抜けるたびにパスワードを変えて配り直し、誰が使ったかを表に手で書き足す作業が続きます。Junify では導入時にパスワードを変えて Junify だけが持ち、担当者はスマホで本人確認をして入ります。使える人の一覧と、誰が・いつ使ったかの記録は管理者の画面で確かめられ、抜けた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 個人情報保護法の安全管理措置をアカウント管理に当てはめる 通則編の別添が求める「アクセス制御」と「アクセス者の識別と認証」、24 条の従業者の監督、25 条の委託先の監督を、共有アカウント・退職者・委託先の 3 場面に当てはめ、用意する一覧と記録を表にします。 更新日: 2026-09-18 個人情報保護法が求める安全管理措置と従業者・委託先の監督を、アカウントの管理に当てはめると、3 つの場面で同じものが問われます。そのアカウントを使える人の一覧、使った人を特定できる手段と記録、そして要らなくなった人を外す手順です。安全管理措置の全体像は[安全管理措置とは](/guides/compliance/what-is-security-control-measures)にまとめているので、この記事は 3 つの場面に絞ります。 ## 別添のどの項目がアカウントに関わるか 通則編の「10(別添)講ずべき安全管理措置の内容」は、区分ごとに「講じなければならない措置」と「手法の例示」を分けて書いています。措置は省けません。例示については「必ずしも次に掲げる例示の内容の全てを講じなければならないわけではなく」と書かれています。アカウントに関わる項目は次の 4 つです。各項目の内容は上の記事にあり、ここでは区分と強さだけを示します。 | 区分 | 強さ | | --- | --- | | 技術的安全管理措置(1) アクセス制御 | 措置 | | 技術的安全管理措置(2) アクセス者の識別と認証 | 措置 | | 組織的安全管理措置(2) 規律に従った運用(手法の例示に利用状況の記録) | 例示 | | 組織的安全管理措置(3) 取扱状況を確認する手段の整備。「アクセス権を有する者」の明確化 | 措置(一覧は例示) | アクセス制御の手法の例示には「ユーザーID に付与するアクセス権により、個人情報データベース等を取り扱う情報システムを使用できる従業者を限定する」があります。ID ごとの権限で使える人を限る方法です。中小規模事業者(従業員 100 人以下。一定の場合を除く)向けの例示は、機器に付いている利用者ごとにログインを分ける機能で、使う従業者を識別・認証することです。どちらも、ID が人を指すことを前提にした書き方です。 ## 共有アカウントに当てはめる 共有アカウント(1 つの ID とパスワードを複数の人が使う状態。定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account))では、情報システムの記録に残るのはアカウントの名前だけです。通則編に共有を禁じる記述はありません。ただ、上の 4 項目のうち「識別と認証」と「利用状況の記録」は、ID が人を指さないと、そのままでは満たせません。 したがって、共有アカウントで個人データを扱うなら、ID の外で人を特定する手段を用意することになります。用意するものは 3 つです。 | 要求 | 共有アカウントで用意するもの | 説明できること | | --- | --- | --- | | アクセス権を有する者の明確化 | そのアカウントを使ってよい人の一覧(氏名と部署) | 誰が使える状態かを答えられる | | 識別と認証 | 使う人を確かめる手段(端末のログインを人ごとに分ける、使う前に本人を確かめる仕組み) | ID の外で「誰か」を確かめている | | 利用状況の記録 | 誰が・いつ・どのアカウントを使ったかの記録(台帳、システムの記録) | 事故のあとに使った人を絞れる | 一覧がなければ、記録があっても照合できません。順番は一覧が先です。 ## 退職者に当てはめる 24 条は「従業者に対する必要かつ適切な監督」(従業者が規程どおりに扱っているか確かめること)を求めます。通則編の「従業者」には、正社員のほかパート・アルバイト、派遣社員、取締役も含まれます。通則編が挙げる、監督を行っていない事例 1 は、従業者が規程に従って業務を行っていることを確認しなかった結果、個人データが漏えいした場合です。 退職した人は従業者ではなくなります。アクセス制御の例示は、ID の権限で「使用できる従業者を限定する」ことなので、従業者でなくなった人が使える状態は、この限定から外れていると読めます。通則編に、退職から何日以内に止めるかの定めはありません。用意するものは、その人が使えたアカウントの一覧と、止めた日付の記録です。個人アカウントは削除か停止で止まります。共有アカウントは、パスワードを知っている限り入れるので、変更して配り直すことになります。その運用の限界は[退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure)に書きました。派遣社員の契約終了や、パート・アルバイトの退職も同じ扱いです。 ## 委託先に当てはめる 25 条は「委託を受けた者に対する必要かつ適切な監督」を求めます。通則編 3-4-4 は、委託先の安全管理措置が「少なくとも法第 23 条及び本ガイドラインで委託元に求められるものと同等であること」を確認するよう求めます。確認の方法は、別添の各項目が委託業務に沿って実施されることを、あらかじめ確かめることです。監督の 3 点は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にあります。再委託は[再委託とは](/guides/outsourcing-access/what-is-subcontracting)にあります。 委託先に自社のアカウントを使わせる場合、別添の 4 項目を委託先の側でも確かめることになります。 | 別添の項目 | 委託先について確かめること | 契約に書くこと(望ましい) | | --- | --- | --- | | アクセス権を有する者 | 委託先の誰が使うか(氏名)。担当者の交代を報告してもらえるか | 使う担当者の届け出と交代時の報告 | | アクセス制御 | 委託業務に要らない個人データに入れないか | 使わせる範囲 | | 識別と認証・記録 | 委託先で使った人を特定できるか。共有 ID なら委託先の作業記録で分かるか | 取扱状況を委託元が把握できること | | 契約終了 | 終了時にアカウントを止める手順が決まっているか | 終了時の返却と停止 | 通則編は、契約に「委託先における委託された個人データの取扱状況を委託元が合理的に把握することを盛り込むことが望ましい」と書いています。自社のシステムなら、その記録は自社の側に残ります。委託先の側のシステムなら、報告の形で受け取ることになります。 ## 3 つの場面で共通に用意するもの 使える人の一覧、使った人の記録、外す手順と記録の 3 つは、3 つの場面に共通し、他の法令や指針でも同じ形で求められます。全体は[法令・ガイドラインとアカウント管理](/guides/compliance)の「共通する 4 つの要求」の表にまとめています。通則編でこの 3 つに関わる項目は、一覧が別添 組織的(3)、記録が組織的(2)と技術的(2)、外す手順が技術的(1)と 24 条・25 条です。3 つが揃っていれば、誰が使えて誰が使ったかを後から確かめられます。24 条の監督では、それに加えて規程どおりに扱っているかを確認した記録が要ります。 ## よくある質問 **共有アカウントのままで安全管理措置を満たせますか** 通則編は共有を禁じていません。使ってよい人の一覧と、ID の外で使った人を確かめる手段、利用の記録があれば、識別と認証と記録の求めに沿うと読めます。 **退職者のアカウントを止める期限は決まっていますか** 通則編に日数の定めはありません。ID の権限で使える従業者を限定する手法から、従業者でなくなった人を外す必要があると読めます。止めた日付を記録に残します。 **委託先の担当者が交代したらどうしますか** 使える人の一覧を更新し、前の担当者のアカウントを止めます。契約に担当者の届け出と交代時の報告を入れておくと、委託元が取扱状況を把握しやすくなります。 **パートや派遣社員にも同じ管理が要りますか** 要ります。通則編の従業者には、パート社員、アルバイト社員、派遣社員、取締役も含まれます。退職や契約終了でアカウントを止める扱いは正社員と同じです。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、3 つの場面に共通する、使える人の限定と使った人の記録を担います。担当者はスマホで本人確認をしてから共有アカウントを使うので、記録は一人ひとり残ります。パスワードは渡さず、退職や委託終了のときは割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版のアカウント管理項目 第 4.0 版は、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更・削除、契約終了時のアクセス権の回収を挙げます。本編・付録 3・付録 5 の当てはまる箇所を点検表にします。 更新日: 2026-09-18 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月 27 日公開)で、アカウントに関わる項目は 3 か所に分かれています。本編の実践編、付録 3 の自社診断、付録 5 の規程サンプルです。求めていることは、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更と削除、契約終了時のアクセス権の回収です。3 か所を 1 つの点検表にまとめます。 ## ガイドラインの構成 本編は第 1 部「経営者編」と第 2 部「実践編」からなり、付録 1〜8 は IPA のページから別に取得します。付録 3「5 分でできる!情報セキュリティ自社診断」は 25 項目のチェックシートです。「実施している 4 点」「一部実施している 2 点」「実施していない 0 点」「わからない −1 点」で採点します。付録 5「情報セキュリティ関連規程(サンプル)」は、赤字と青字を自社向けに書き換えて規程にするひな形です。経営者編の原則 2 は「委託先の情報セキュリティ対策まで考慮する」で、委託先の不備でも委託元としての管理責任を問われる、と書いています。 ## 本編の実践編で挙がるアカウントの項目 実践編の複数の取組から、アカウントに関わる記述を集めました。中心は「攻撃等の防御」にある「ID アクセス制御」です。 - ID の手続: ユーザー ID と管理者 ID(管理者権限を持つ ID)の発行から削除までを管理する手順を定め、必要最小限にする - 共有 ID: 共有 ID はなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みを整えて運用する - アクセス権の見直し: 異動や退職に伴う権限の変更・削除漏れと、特定の人への権限集中を防ぐルールを定め、付与状況を管理する - パスワード: 複雑さを保ち、使い回しを防ぐルールを定める。紙、ファイル、パスワード管理アプリなど保管方法の違いを理解し、管理ルールを定めて周知する - 認証の強さ: 情報の重要性に応じて本人確認の方法を決め、多要素認証(パスワードに加えてもう 1 つの方法で本人を確かめること)を活用する - 退職時の回収: 退職・任期満了時に情報や機器・ID・鍵を回収し、記録で実行状況を見えるようにする - 契約終了時の回収: 取引先との契約終了時に、機密性の高い情報とアクセス権を回収または破棄する。責任者と期限を決め、チェックシートで運用して記録を保管する ## 付録 3 の自社診断で当たる項目 25 項目のうち、この記事で取り上げるのは 5 つです。解説編の対策例から、関わるものを抜き出します。 | No | 診断内容 | 対策例のうちアカウントに関わるもの | | --- | --- | --- | | 3 | パスワードは破られにくい「長く」「複雑な」パスワードを設定していますか | 10 文字以上で複雑に。同じ ID・パスワードを複数サービスで使い回さない。重要なシステムでは多段階認証・多要素認証・パスキー(パスワードの代わりに端末で本人を確かめる仕組み)などを使う。初期設定パスワードを見直す | | 4 | データの共有設定を必要な人に限定していますか | 従業員の異動や退職時には速やかに設定を変更(削除)する。パソコンを共有せざるを得ない場合は別途ユーザーアカウントを作る | | 21 | 個人所有の情報機器を業務で利用する場合のセキュリティ対策を明確にしていますか | 業務利用を許可制にし、利用時のルールを決める | | 22 | 重要情報の授受を伴う取引先との契約書には、秘密保持条項を規定していますか | 秘密保持や具体的な対策を明記した契約や覚書を交わす。再委託にも同等の秘密保持を要請する | | 23 | 外部サービスは、安全・信頼性を把握して選定していますか | パスワードなどの認証機能について適切に設定・管理する | ## 付録 5 の規程サンプルの当てはまる条項 規程サンプルの「6. アクセス制御及び認証」「8. 委託管理」「人的対策 3. 雇用の終了」に、そのまま使える条文があります。 - 6.1 アクセス制御方針: 業務に応じた必要最低限のアクセス権。発行・変更・削除は申請・許可制で、申請書か台帳を保管。重要なシステムはアクセス権の利用状況を監視する - 6.2.1 認証に関する基本方針: アカウントは利用者 1 名に 1 つ。他者との共有と共有アカウントの発行を禁止。やむを得ず共有 ID が必要な場合は、使ったユーザーを特定できるようにする - 6.2.2 多要素認証: 社外秘以上の情報を扱うクラウドサービスでは常に多要素認証を使う。管理者権限を持つ共有アカウントはアクセスログで使用者を特定できるようにする - 6.4 利用者アカウントの管理: 不要になったアカウントは、不要になった日の翌日までに削除か無効化 - 6.6 従業員以外への発行: 承認を得たうえで秘密保持契約を結ぶ - 6.7 特権アカウント: 保有者を一覧にし、必要最低限の人に限る。管理者の退職や一定期間未使用のときは速やかに削除か無効化 - 6.10 アカウント・パスワードの条件: 1 つの特権アカウント名を 2 名以上で共用しない。パスワードは紙に書いて施錠保管するか、パスワード管理アプリなどで安全に保管し、定期変更は強制しない。漏えいの疑いがあれば速やかに変更 - 人的対策 3. 雇用の終了: 退職時の返還物にアクセス権(ID 及び鍵)を含め、チェックリストで確認 - 8.3 委託契約の締結: 委託業務終了時の情報の返却・廃棄・消去を契約に明記 - 8.7 機密情報共有事項チェックシートの管理: 契約終了時に機密情報とアクセス権が回収または破棄されたことをチェックシートで確認 ## 総務担当がそのまま使える点検表 3 か所を、点検の問いの形に直したものです。「なぜ」は、その項目が抜けたときに起きることです。 | No | 点検の問い | 根拠 | なぜ | | --- | --- | --- | --- | | 1 | 会社で使う SaaS と、それぞれの ID の一覧があるか | 本編 ID の手続、付録 5 の 6.1 | 一覧がないと、退職時に止め忘れる ID に気づけない | | 2 | ID の発行と削除を申請・承認で行い、記録を残しているか | 本編 ID の手続、付録 5 の 6.1 | 誰が承認したか分からないと、不要な ID が残る | | 3 | 共有 ID ごとに、使った人が分かる記録があるか | 本編 共有 ID、付録 5 の 6.2.1 | 記録がないと、事故のあとに使った人を絞れない | | 4 | 重要なシステムで多要素認証を使っているか | 本編 認証の強さ、付録 3 の No.3、付録 5 の 6.2.2 | パスワードが漏れただけで入られる | | 5 | パスワードの保管場所(紙、ファイル、管理アプリ)を決めているか | 本編 パスワード、付録 5 の 6.10 | 各自の判断で保管すると、退職者の手元に残る | | 6 | 異動・退職のたびに権限を見直し、翌日までに止めているか | 本編 アクセス権の見直し、付録 3 の No.4、付録 5 の 6.4 | 止めるまでの間は、辞めた人が入れる | | 7 | 退職時のチェックリストに ID と鍵が入っているか | 本編 退職時の回収、付録 5 の雇用の終了 | 機器は返っても、SaaS の ID は残る | | 8 | 管理者権限を持つ人の一覧があり、退職時に外しているか | 付録 5 の 6.7 | 強い権限の ID が放置される | | 9 | 従業員以外に ID を出すとき、承認と秘密保持契約があるか | 付録 5 の 6.6 | 委託先の担当者の ID が管理の外に置かれる | | 10 | 取引先との契約終了時に、渡したアカウントの回収をチェックシートで確認しているか | 本編 契約終了時の回収、付録 5 の 8.3 と 8.7 | 契約が終わっても入れる状態が続く | | 11 | 私物端末の業務利用を許可制にし、ルールを決めているか | 付録 3 の No.21 | 私物端末に保存されたパスワードを会社が消せない | 点検表の 1・3・6・10 は、使える人の一覧・使った人の記録・外す手順という、他の法令や指針にも共通する 3 点に当たります。共通の 3 点は[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。規程の文言は付録 5 をそのまま使えますが、自社の実態に合わせて条文を変えるときは弁護士の確認を受けてください。 ## よくある質問 **中小企業なら共有 ID を使ってもよいですか** 本編は、共有 ID はなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みを整えて運用するよう求めています。付録 5 の規程サンプルも同じ条件で認めています。 **パスワードは定期的に変えるべきですか** 規程サンプルは「定期的な変更を強制しない」とし、漏えいが判明したか疑いがある場合に速やかに変えるとしています。使い回しをしないことと、安全な保管が前提です。 **退職者のアカウントはいつまでに止めますか** 規程サンプルの 6.4 は、不要になった日の翌日までに削除か無効化としています。本編は退職時に ID を回収し、記録で実行状況を見えるようにするよう求めています。 **付録はどこで手に入りますか** 本編の目次に、付録 1〜8 は IPA のガイドラインのページから取得するとあります。付録 3 は PDF、付録 5 は書き換えて使う文書ファイルです。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」(ガイドラインと付録のページ)](https://www.ipa.go.jp/security/guide/sme/about.html) - [IPA「中小企業の情報セキュリティ対策ガイドライン 付録 3 5 分でできる!情報セキュリティ自社診断」](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_3.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン 付録 5 情報セキュリティ関連規程(サンプル)」](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_5.docx) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、共有 ID を使った人の記録、異動・退職時に止めること、契約終了時の回収の 3 つを担います。共有アカウントは担当者がスマホで本人確認をしてから使うので、使った人の記録は一人ひとり残ります。パスワードは担当者に渡さず、退職や契約終了では割り当てを外すだけで止まります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる 取り上げる管理策は、5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権の 5 つです。SaaS では、使える人の一覧、ID の作成と削除、パスワード、管理者権限に当たります。 更新日: 2026-10-13 ISO/IEC 27001:2022(日本語版は JIS Q 27001:2023)の附属書 A(規格の末尾に付いた管理策の一覧)には、93 の管理策(対策の項目)があります。名称から見て、アカウントの管理に直接関わるのは次の 5 つです。5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権です。SaaS に当てはめると、使える人の一覧、ID の作成から削除までの手続、パスワードの扱い、管理者権限を持つ人の限定になります。ISMS と認証の仕組みは [ISMS とは](/guides/compliance/what-is-isms)にまとめています。 ## 管理策の名称は公開資料のどこで確かめられるか 規格の本文は有料のため、引用しません。管理策の番号と名称は、日本規格協会が公開している JIS Q 27002:2024 の目次で確かめられます。JIS Q 27002 は管理策の手引です。JIPDEC の ISMS ユーザーズガイドによれば、その箇条 5〜8 にある 93 の管理策は、項番も内容も JIS Q 27001 の附属書 A と同じです。違いは、27001 が「しなければならない」と書く要求事項で、27002 が「望ましい」と書く手引であることです。 各管理策に付く属性(管理策を分類する目印)の説明は、[ISMS とは](/guides/compliance/what-is-isms)に譲ります。この記事で使うのは、目次で確かめられる名称までです。各管理策が何を求めるかの本文は、規格を入手して確かめる必要があります。 ## 5 つの管理策を SaaS の作業に置き換える 名称から読める対象を、SaaS の管理でどの作業に当たるかに置き換えると次のようになります。右の 2 列は規格の記述ではなく、この記事の読み替えです。 | 管理策(JIS Q 27002:2024 目次) | 名称から読める対象 | SaaS での作業 | 用意するもの | | --- | --- | --- | --- | | 5.15 アクセス制御 | 誰が何に入れるかの決まり | サービスごとに、使える人と権限の種類を決める | アクセス制御の決まり(文書) | | 5.16 識別情報の管理 | 利用者を区別するための情報(ID)の扱い | ID の作成、変更、削除の手続 | ID の一覧と、作成・削除の申請記録 | | 5.17 認証情報 | 本人を確かめるための情報(パスワードなど)の扱い | パスワードの配り方、保管、変更 | パスワードの扱いの決まり | | 5.18 アクセス権 | 個々の人に与える権限 | 権限の付与、見直し、削除 | 権限の一覧と見直しの記録 | | 8.2 特権的アクセス権 | 管理者権限(他の人の権限や設定を変えられる強い権限) | 管理者権限を持つ人を限り、使ったときの記録を残す | 管理者権限の一覧と利用の記録 | 5.16 と 5.18 は、ID と権限の両方に「作る・変える・消す」の流れがある点で対になります。SaaS では、ID を消さずに権限だけ外す場合と、権限は残したまま ID を止める場合の両方があるため、2 つを分けて一覧を持つと説明しやすくなります。管理者権限の考え方は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にあります。 ## 共有アカウントはどの管理策に関わるか [共有アカウント](/guides/shared-accounts/what-is-shared-account)(1 つの ID を複数の人が使う状態)は、5.16 と 5.17 に関わります。識別情報は利用者を区別するための情報なので、1 つの ID を複数人で使うと、その ID からは使った人を区別できません。認証情報は本人を確かめるための情報なので、複数人が同じパスワードを知る状態は、本人確認の意味を弱めます。目次には 8.5 セキュリティを保った認証と 8.15 ログ取得もあり、使った人を別の手段で確かめて記録を残すことが、この 2 つに関わると読めます。規格本文で共有アカウントをどう扱うかは、この記事で確かめた公開資料には書かれていません。 ## 退職者と委託先はどの管理策に関わるか 目次には、6.5 雇用の終了又は変更後の責任、5.11 資産の返却、5.19 供給者関係における情報セキュリティがあります。ユーザーズガイドは、委託先とリスクを分け合うときの管理策として 5.19 を挙げ、対策を契約書などに織り込むことが重要だと書いています。退職者が使っていた権限を外すことは、5.18 に関わると読めます。6.5 は名称から見て、辞めた後や担当が変わった後も本人に残る責任を扱う管理策です。権限を外すことそのものを指すとは読めません。委託先については 5.19 と、委託先の担当者に与える 5.18 の権限が関わると読めます。 ## 審査や取引先に何を見せられるか ISMS の審査は組織の仕組みに対して行われ、どの管理策を適用したかは適用宣言書(どの管理策を使うと決めたかを書いた文書)に書きます。アカウントについて用意する資料を一例として挙げると、サービスごとの ID と権限の一覧、作成・変更・削除の申請と承認の記録、管理者権限を使った記録の 3 つです。取引先から ISMS 認証を求められた場合も、認証だけでは預けたアカウントを誰が使うかまでは分からないため、同じ 3 つを契約とあわせて示すことになります。使える人の一覧・使った人の記録・外す手順は他の法令や指針とも共通で、[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。 ## よくある質問 **管理策の番号を覚える必要はありますか** 番号は規格の版で変わります。2022 年版で管理策は 114 から 93 に整理されました。覚えるより、ID・パスワード・権限・管理者権限の 4 つに分けて一覧を持つほうが、審査でも説明しやすくなります。 **SaaS 側の設定だけで管理策に対応できますか** 設定は手段の一つです。5.16 や 5.18 は作成から削除までの流れを扱うと読めるため、誰が承認して誰が消すかの決まりと記録が、設定とは別に要ります。 **共有アカウントは ISMS で禁止されていますか** この記事で確かめた公開資料に、共有を禁じる記述はありません。識別情報と認証情報の管理策に関わるため、使う人を別の手段で確かめ、記録を残す形で説明することになります。 **2013 年版の A.9 アクセス制御はどうなりましたか** JIPDEC のユーザーズガイドでは、2013 年版の 14 の箇条は 2022 年版で組織的・人的・物理的・技術的の 4 つに整理されました。アクセスに関わる管理策は 5.15〜5.18 と 8.2 に分かれています。 ## 参考資料 - [日本規格協会「JIS Q 27002:2024 情報セキュリティ，サイバーセキュリティ及びプライバシー保護―情報セキュリティ管理策」プレビュー(目次。2024 年 6 月 20 日改正)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27002_000_000_2024_j_ed10_ch.pdf) - [日本規格協会「JIS Q 27002:2024」](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+27002%3A2024) - [日本規格協会「JIS Q 27001:2023」](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+27001%3A2023) - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [JIPDEC「ISMS 認証基準(ISO/IEC 27001)の改訂」](https://www.jipdec.or.jp/library/itreport/2022itreport_winter06.html) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、5 つのうち認証情報とアクセス権に関わる部分を担います。パスワードは管理者が登録し、担当者には渡しません。担当者はスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 経産省サイバーセキュリティ経営ガイドライン(Ver 3.0)の委託先管理 指示 9 は、委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化を経営者に求めます。アカウントの操作手順は書かれていないため、委託先に渡すアカウントの一覧と契約の条項に置き換えて読みます。 更新日: 2026-09-18 経済産業省と IPA の「サイバーセキュリティ経営ガイドライン Ver 3.0」は、経営者向けの指針です。委託先の管理は、重要 10 項目の指示 9「ビジネスパートナーや委託先等を含めたサプライチェーン全体の状況把握及び対策」にあります。サプライチェーンとは、取引先や委託先のつながり全体のことです。指示 9 は、委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化を求めます。アカウントの操作手順は書かれていません。委託先に渡すアカウントの一覧と契約の条項に置き換えて読むことになります。 この記事は、IPA のプラクティス集と解説ページで確かめられる範囲で書いています。 ## ガイドラインの構成 プラクティス集によれば、Ver 3.0 は 2023 年 3 月に発行され、大企業と中小企業(小規模事業者を除く)の経営者を対象にしています。内容は、経営者が認識すべき「3 原則」と、CISO 等(対策の責任者となる幹部)に指示すべき「重要 10 項目」です。3 原則は IPA の解説ページで次のように示されています。 1. 「経営者は、サイバーセキュリティリスクが自社のリスクマネジメントにおける重要課題であることを認識し、自らのリーダーシップのもとで対策を進めることが必要」 2. 「サイバーセキュリティ確保に関する責務を全うするには、自社のみならず、国内外の拠点、ビジネスパートナーや委託先等、サプライチェーン全体にわたるサイバーセキュリティ対策への目配りが必要」 3. 「平時及び緊急時のいずれにおいても、効果的なサイバーセキュリティ対策を実施するためには、関係者との積極的なコミュニケーションが必要」 委託先は原則 2 に現れ、重要 10 項目では指示 9 が担当します。指示 5(リスクに効果的に対応する仕組みの構築)にも、委託に関わるプラクティス(実践例)があります。委託すべき範囲の明確化と、IT サービスの委託における契約と第三者検証(外部の専門家による点検)です。 ## 指示 9 は何を求めるか プラクティス集に載る指示 9 の指示内容は 2 つです。1 つは、サプライチェーン全体で適切な対策が講じられるよう、「国内外の拠点、ビジネスパートナーやシステム管理の運用委託先等を含めた対策状況の把握を行わせる」ことです。もう 1 つは、「ビジネスパートナー等との契約において、サイバーセキュリティリスクへの対応に関して担うべき役割と責任範囲を明確化する」ことです。あわせて、対策の導入支援や共同実施など、実効性を高める方策を検討させます。 実践に向けた最初の一歩として、プラクティス集は 2 点を挙げています。リスクのある委託先の特定と、その委託先に対する対策状況の把握です。想定される課題には、各部署がそれぞれ委託していて会社として委託先を把握していないこと、確認の観点が分からないこと、規模が多様で一律の対策を求められないことが挙がっています。 ## プラクティス集の事例から読める進め方 プラクティス 9-1 は、製造業の事例です。委託元の部署へのアンケートで委託先とリスクの有無を調べ、リスクのある委託先に対策状況のアンケートを行い、結果を一覧にして経営者に報告し、対応方針を検討しています。プラクティス 9-2 は、100 社以上の委託先を持つメーカーの事例です。直接取引のある委託先を棚卸し(何社あるかを一覧にすること)し、担当者を置けるかと規模で 4 区分に分けています。区分ごとに実施すべき対策を契約で努力義務として求め、年 1 回アンケートで確認しています。2 次以降の再委託先は、1 次の委託先の責任で対策を求めることを原則としています。 プラクティス 5-3 は、IT システムの運用を 1 社に委託していた事業者が、満たすべき条件を自社で決め、第三者検証とあわせて契約書に反映した事例です。委託先任せだった対策を、委託元が条件として示す形に変えています。 ## アカウント管理に置き換えると何を用意するか 指示 9 の要素を、委託先に自社のアカウントを使わせる場面に当てはめます。ガイドラインにアカウントの記述はないため、表の「置き換え」と「用意するもの」は、指示内容から導いたものです。経営ガイドラインは指針で罰則がなく、個人情報保護法 25 条は義務なので、両方に当てはまる会社は法の側の要求を先に満たします。 | 指示 9 の要素 | アカウントでの置き換え | 用意するもの | | --- | --- | --- | | 委託先の特定 | 自社のシステムや SaaS に入れる委託先と担当者 | 委託先ごとに、渡したアカウントと使う担当者の一覧 | | 対策状況の把握 | 委託先で ID をどう扱っているか(担当者ごとか共有か、退職時に止めるか) | 質問票の項目と、年 1 回の確認の記録 | | 契約での役割と責任範囲 | アカウントの発行・返却・記録を誰が担うか | 担当者の届け出、利用記録の提出、契約終了時の停止を書いた条項 | | 再委託 | 再委託先にアカウントが渡っていないか | 再委託時の事前報告の条項 | 契約の文言は弁護士の確認を受けてください。個人情報保護法が委託元に義務づける監督の 3 点は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)に、渡し方の違いは[委託先に自社のアカウントを使わせるときの管理](/guides/outsourcing-access)にまとめています。委託先の担当者の一覧・使った人の記録・契約終了時に止めることは他の法令や指針とも共通で、[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。 ## よくある質問 **経営ガイドラインは中小企業にも当てはまりますか** 対象は大企業と中小企業(小規模事業者を除く)の経営者です。小規模事業者向けには、IPA の「中小企業の情報セキュリティ対策ガイドライン」が別にあります。 **個人情報保護法の委託先の監督と何が違いますか** 経営ガイドラインは経営者向けの指針で罰則がなく、個人情報保護法 25 条は個人データの取扱いを委託する事業者の義務です。求める中身は、把握と契約の点で重なります。 **委託先が使う SaaS のアカウントまで見る必要がありますか** 指示 9 は「システム管理の運用委託先等」を含めた把握を求めています。自社のアカウントを渡している委託先は、把握の対象に入ると読めます。 **経産省の原文はどこで読めますか** 経済産業省のページにあります。この記事は IPA の資料で確かめた範囲で書いています。 ## 参考資料 - [IPA「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第 4 版」](https://www.ipa.go.jp/security/economics/hjuojm00000044dc-att/cms_practice_v4_1.pdf) - [IPA「サイバーセキュリティ経営ガイドライン Ver 3.0 実践のためのプラクティス集」(ページ)](https://www.ipa.go.jp/security/economics/csm-practice.html) - [IPA「解説 3 経営者が認識すべき 3 原則と指示すべき重要 10 項目」](https://www.ipa.go.jp/security/economics/practices_navi/practice103.html) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify では、委託先に渡したアカウントの一覧と、委託先の誰が・いつ使ったかの記録が、管理者の画面に残ります。担当者はスマホで本人確認をしてから使い、パスワードは知りません。契約終了では、その委託先の担当者の割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 総務省テレワークセキュリティガイドライン第 5 版と私物端末 第 5 版は対策を経営者・管理者・勤務者に分けます。管理者には多要素認証、不要なアカウントの削除、ログイン後の記録の取得を、勤務者には認証情報を無断で貸さないことを求め、私物端末はテレワークの方式ごとに可否を決めます。 更新日: 2026-09-18 総務省の「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)は、対策を 3 つの立場に分けて書いています。経営者、システム・セキュリティ管理者、テレワーク勤務者です。アカウントと本人確認に関わる対策は「アカウント・認証管理」の分類にまとまっています。管理者には、多要素認証(パスワードに加えてもう 1 つの方法で本人を確かめること)の強制を求めます。異動や担当変更に合わせた不要なアカウントの削除と、ログイン後の記録の取得も管理者の対策です。勤務者には認証情報を無断で貸さないことを求めます。私物端末(個人所有端末、BYOD)は、テレワークの方式ごとに考慮事項が書かれ、可否は組織が決めます。 ## 第 5 版の構成と読み方 対策は 13 の分類(A〜M)に分かれ、それぞれに「基本対策」と「発展対策」があります。アカウントに関わる分類は 4 つです。D 特権管理(管理者権限の保護)、H アカウント・認証管理、I アクセス制御・認可(必要最小限の人に限ること)、J インシデント対応・ログ管理です。個人事業主は 3 つの立場をすべて兼ねます。 ## 管理者に求められる対策 アカウントと本人確認に関わる管理者の対策を抜き出し、番号と平易な言い換えで並べます。すべて基本対策です。 | 番号 | 対策 | 平たく言うと | | --- | --- | --- | | H-1 | 利用者認証機能について、多要素認証方式の利用やパスワードポリシーの規定など技術的な基準を明確に定める | 本人確認の方法とパスワードの決まりを文書にする | | H-2 | 社内システムやクラウドサービスへのアクセス時に、可能な限り多要素認証を強制する | パスワードだけで入れないようにする | | H-4 | 強力なパスワードポリシーの適用を強制する | 短い・単純なパスワードを設定できないようにする | | H-5 | 初期パスワードが強制的に変更されるか、十分な強度の個別のパスワードが設定されるようにする | 配ったときのパスワードのまま使わせない | | H-7 | 異動や担当変更等を適切に把握し、不要なアカウントの削除やアカウント権限の更新等を実施する | 担当が変わったら要らない ID を消す | | D-1 | 貸与する端末には必要最小限の権限(例: ユーザ権限)を付与する | 端末の管理者権限を普段は使わせない | | D-3 | 製品やクラウドサービスの管理者権限は業務上必要な最小限の人にのみ適用し、アクセス経路も限定する | 管理者権限を持つ人と入る経路を限る | | J-5 | テレワーク関連機器やクラウドサービスの記録(ログインした後の認証ログ、操作ログなど)を取得する | 誰がいつ入り何をしたかの記録を取る | | J-6 | 取得したログの保存容量を確保し、可能な限り 1 年以上保存可能とする | 記録を 1 年以上残す | | B-1 | テレワーク端末を管理する台帳を整備し、利用者や所在を把握する | どの端末を誰が使っているかの一覧を持つ | 解説の章は、異動や担当者変更に際して「権限がなくなるべき者に権限が残ったままにならないよう運用する必要があります」と書いています。パスワードの定期的な変更は原則不要としています。例外は、第三者に知られたおそれがあるときや、共有アカウントなどで利用メンバーに変更があったときなどで、速やかに変更するよう求めています。共有アカウントに触れているのはこの 1 か所です。 ## 勤務者に求められる対策 | 番号 | 対策 | 平たく言うと | | --- | --- | --- | | H-1 | 利用者認証情報(パスワード、IC カード等)を無断貸与や紛失等しないよう、適正に管理する | 自分の ID とパスワードを人に貸さない | | H-2 | 第三者に推測されにくいパスワードを設定する。長く設定できる場合は複数の単語を組み合わせる | 長いパスワードにする | | H-3 | 複数のサービス間で同じパスワードを使い回さない。知られた可能性があれば早急に変更する | 使い回さず、漏れたら変える | | I-3 | 共有フォルダやファイル共有サービスに機密情報を保存する場合、閲覧・編集の権限が誰にあるか確認する | 共有場所の権限を確かめる | | B-1 | テレワーク端末が守るべき情報資産に当たることを認識して管理する | 端末は会社の資産として扱う | 勤務者 H-1 の「無断貸与」は、会社の許可なく自分の認証情報を他の人に使わせることです。会社が決めて共有するアカウントは、管理者側の H-7 と、上の共有アカウントのパスワード変更の記述で扱われています。 ## 私物端末はどう扱われるか ガイドラインは 7 つのテレワーク方式を解説し、方式ごとに「BYOD 利用について」の項を置いています。端末は支給端末と個人所有端末の両方を想定しますが、VPN 方式・クラウドサービス方式・スタンドアロン方式は、メリットが大きい支給端末を想定した評価です。自社が使っている方式の項を読みます。 ### VPN・クラウドサービス・スタンドアロンの 3 方式 VPN(社内ネットワークにつなぐ)、クラウドサービス(インターネット上のサービスに直接つなぐ)、スタンドアロン(社内につながず端末内のデータで作業する)の 3 つでは、端末にデータを保存でき、対策ソフトの導入を強制できないため、十分な管理が取れないとしています。事故が起きうるリスクを受け入れられるかを評価したうえで、利用の可否を決めることになります。 ### リモートデスクトップ・仮想デスクトップの 2 方式 リモートデスクトップ(社内のパソコンを遠隔操作する)と仮想デスクトップ(サーバー上の画面を遠隔操作する)では、端末へのデータ保存を制限・禁止します。そのうえで、利用のルールを決め、端末に必要な対策があることを確認し、端末を管理します。 ### セキュアコンテナ・セキュアブラウザの 2 方式 セキュアコンテナ(端末内に業務専用の区画を作る)とセキュアブラウザ(専用のブラウザーで社内のシステムを使う)でも、利用のルールを決め、端末の対策を確認し、端末を管理します。セキュアブラウザについては、製品の仕様を確かめるよう書いています。 事例の章は、「個人所有端末の業務利用に当たってはセキュリティ対策をテレワーク勤務者任せにせず、組織として適切なセキュリティ対策を実施する必要があります」と書いています。 ## 立場別に見た私物端末とアカウント 私物端末では、会社が端末の中を管理できないため、アカウントの側で守る部分が増えます。ガイドラインの対策を立場別に当てはめると、次のようになります。 経営者は、私物端末を認めるかどうかを、方式ごとのリスクを見て決めます。認めるなら方針を周知します。関わるのは A-1 と、方式ごとの「BYOD 利用について」の項です。 管理者は、私物端末から入るサービスに多要素認証を強制し(H-2)、私物端末の一覧を持ちます(B-1)。担当変更のときには不要なアカウントを消し(H-7)、ログイン後の記録を 1 年以上残します(J-5、J-6)。 勤務者は、認証情報を家族や同僚に貸さず、パスワードを使い回さないようにします(H-1〜H-3)。端末は会社の資産として扱います(B-1)。 誰が使ったかの記録と、担当変更時に不要なアカウントを消すことは、他の法令や指針でも同じ形で求められます。共通の点は[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。私物端末のブラウザーにパスワードを保存する扱いは、ガイドラインにコラムがあります。会社としての判断は[ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work)に整理しています。 ## よくある質問 **私物端末でのテレワークは認められていますか** ガイドラインは禁じていません。方式ごとに、データ保存やソフト導入の強制ができない点を挙げ、リスクを受け入れられるか評価して可否を決めるよう求めています。 **多要素認証は必ず必要ですか** 管理者の基本対策 H-2 は「可能な限り多要素認証を強制する」です。認証情報が漏れてもただちに入られないための対策として、社内システムにも同様に求めています。 **パスワードは定期的に変えるべきですか** 原則不要としています。例外は、第三者に知られたおそれがあるときや、共有アカウントで利用メンバーに変更があったときなどで、速やかに変更します。 **記録はどのくらい残しますか** J-6 は、過去にさかのぼった調査も必要になるため、可能な限り 1 年以上保存できるようにするとしています。対象は認証ログや操作ログなどです。 ## 参考資料 - [総務省「テレワークセキュリティガイドライン 第 5 版」(令和 3 年 5 月)](https://www.soumu.go.jp/main_content/000752925.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、私物端末で問われる、誰が使ったかの記録と、担当変更時に止めることを担います。担当者はスマホで本人確認をしてからブラウザーの拡張機能で使うので、記録は一人ひとり残ります。パスワードは端末に渡らず、担当を外れたら割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # プライバシーマーク(JIS Q 15001)でアカウント管理について求められること JIPDEC の構築・運用指針は、個人情報の台帳に「アクセス権を有する者」を書いて年 1 回以上確認すること、従業者の監督、委託先の選定基準と契約の 8 事項を求めます。アカウントでは、使える人の一覧・記録・契約の条項に当たります。 更新日: 2026-10-13 プライバシーマークの審査で使われる JIPDEC の「構築・運用指針」(JIS Q 15001:2023 準拠 ver1.0)は、アカウントという語を使っていません。求めているのは 3 つです。個人情報の台帳に「アクセス権を有する者」を書いて維持すること、従業者への「必要かつ適切な監督」、委託先の選定基準と契約に入れる 8 つの事項です。アカウントの管理に置き換えると、使える人の一覧、記録、契約の条項の 3 つになります。 ## 指針とはどの文書か 指針は、プライバシーマーク制度基本綱領 7 条 4 項に定める文書で、2023 年 12 月 25 日に制定され、2024 年 10 月 1 日から施行されています。要求事項は J から始まる項番と表で書かれ、表の「項目」が実施すべき内容、「留意事項」が補足です。対象は事業の種類や規模を問わず全ての事業者で、従業者の個人情報も「事業の用に供している個人情報」に含まれます。 ## 台帳の「アクセス権を有する者」には何を書くか J.3.1.1(個人情報の特定)は、個人情報を管理する台帳を整備し、少なくとも次の項目を含めるよう求めています。 - 個人情報の項目 - 利用目的 - 保管場所 - 保管方法 - アクセス権を有する者 - 利用期限 - 保管期限 - 管理する個人情報の件数(概数でも可) 台帳は少なくとも年 1 回、必要に応じて適宜確認し、最新の状態で維持します。留意事項は、台帳の整備は取扱い状況を把握するための手段であって目的ではない、と書いています。個人情報保護法の通則編も、別添の組織的安全管理措置(3)で、取扱状況を確認する手段の例に「アクセス権を有する者」の明確化を挙げています。 「アクセス権を有する者」を SaaS にある個人情報に当てはめると、その保管場所に入れる人の一覧です。個人アカウントなら、サービスの利用者一覧がそのまま答えになります。[共有アカウント](/guides/shared-accounts/what-is-shared-account)(1 つの ID を複数の人が使う状態)では、ID の名前を書いても誰が入れるかが分かりません。指針は、氏名で書くか部署や役割で書くかまでは決めていません。ただ共有 ID は、使う人の氏名を台帳か、台帳から参照する一覧に書いておかないと、誰が入れるかに答えられません。担当者が代わるたびに、年 1 回を待たずに直します。台帳と一覧の分け方は[個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか](/guides/compliance/personal-data-ledger-accounts)にあります。 J.3.1.3(個人情報保護リスクアセスメント。どこにどんな危険があるかの見積もり)の留意事項は、リスクを特定する観点の 1 つに「個人情報に係る情報処理施設及び個人情報に係る情報システム」を挙げています。SaaS のアカウントを誰が持っているかは、この観点で洗い出す対象に入ります。 ## 従業者の監督は何を求めるか J.9.3(従業者の監督)の項目は 1 つで、「個人データを取り扱う従業者に対して必要かつ適切な監督を行うこと」です。従業者には、正社員のほか契約社員、パート、アルバイト、派遣社員、役員(取締役など)が含まれます。監督の中身は参照項番の側にあります。J.9.3 が挙げるのは J.2.4、J.4.2(力量)、J.4.5.4(内部規程)です。J.4.2 は、個人情報保護に影響する業務を行う人に必要な能力を決め、身につけさせ、記録することを求めます。その処置には J.4.3(認識)を満たすことも含まれるため、J.4.3 も関わります。J.4.3 は、少なくとも年 1 回の教育の手順を内部規程にし、違反した際に予想される結果を認識させることを求めます。J.4.5.4 は、規程に含める 15 の事項を挙げています。その g) は「個人情報の適正管理(データ内容の正確性の確保等、安全管理措置、従業者の監督、委託先の監督)に関する規定」です。o) は「内部規程の違反に関する罰則の規定」です。 アカウントに置き換えると、内部規程に ID とパスワードの扱いを書くことになります。自分の ID を他の人に使わせないこと、共有 ID を使うときの記録の付け方などです。それを年 1 回の教育で伝え、違反したときの扱いを決めておきます。監督の記録は、教育の記録と規程そのものです。 ## 委託先には何を求めるか J.9.4(委託先の監督)は 6 つの項目からなります。委託先選定基準を確立して選ぶこと、利用目的の範囲内で契約すること、次の 8 事項を盛り込んだ契約を結ぶことの 3 つが前半です。後半は、全ての委託先を漏れなく特定すること、契約書を個人データの保有期間にわたって保存すること、契約に基づき監督することです。選定基準には、次の 2 つを含めます。委託する業務について自社と同等以上の保護水準にあること。契約に規定する事項に対応できることを、客観的に確認できることです。 | 契約に盛り込む事項 | アカウントに置き換えると | | --- | --- | | a) 委託者及び受託者の責任の明確化 | アカウントを発行する側と使う側の責任 | | b) 個人データの安全管理に関する事項 | 委託先の担当者ごとの ID か、共有 ID なら使った人の記録 | | c) 再委託に関する事項 | 再委託先にアカウントを渡さないか、渡すなら事前の報告 | | d) 取扱状況に関する委託者への報告の内容及び頻度 | 使っている担当者の一覧と交代の報告 | | e) 契約内容が遵守されていることを委託者が定期的に、及び適宜に確認できる事項 | 委託元が利用の記録を確認できること | | f) 契約内容が遵守されなかった場合の措置 | 無断で共有した場合の扱い | | g) 事件・事故が発生した場合の報告・連絡に関する事項 | アカウントの不正利用が疑われたときの連絡 | | h) 契約終了後の措置 | 終了時のアカウントの停止と返却 | 置き換えの列は指針にある言葉ではないので、契約の文言は弁護士の確認を受けてください。個人情報保護法の側から見た監督の 3 点は[委託先の監督とは](/guides/outsourcing-access/what-is-supervision-of-contractors)にあります。 ## 何を用意すれば説明できるか 台帳の「アクセス権を有する者」(J.3.1.1)については、SaaS ごとに入れる人の一覧を用意し、台帳から参照できるようにします。共有 ID は、使う人の氏名をその一覧に書きます。年 1 回以上の確認の記録も残します。 従業者の監督(J.9.3、J.4.2、J.4.3、J.4.5.4)で用意するのは、ID とパスワードの扱いを書いた内部規程と、年 1 回の教育の記録、違反したときの扱いを決めた文書です。 委託先の監督(J.9.4)で用意するのは、選定基準、8 事項を含む契約書、委託先の一覧、担当者の報告と利用の記録です。 3 つとも、審査で見せる文書と、日々の運用で更新する一覧に分かれます。文書は一度作れば済みますが、一覧は担当者の交代のたびに直すものなので、更新のきっかけ(入退社、異動、契約の開始と終了)を決めておくと維持できます。使える人の一覧・使った人の記録・外す手順は他の法令や指針とも共通で、[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。 ## よくある質問 **台帳に共有アカウントはどう書きますか** 指針は細かさを決めていません。ただ ID 名だけでは誰が使うか分からないので、使う人の氏名を、台帳か、台帳から参照するアカウントの一覧に書きます。交代のたびに直し、年 1 回以上は全体を確認します。 **従業者の監督は何を記録すれば足りますか** 指針は監督の方法を細かく定めていません。参照項番の力量・認識・内部規程から、規程と年 1 回の教育の記録、違反時の扱いを決めた文書が根拠になります。 **委託先にアカウントを渡すとき契約に何を書きますか** 指針が求める 8 事項のうち、安全管理、報告の内容と頻度、確認できる事項、契約終了後の措置を、担当者の届け出・利用記録の確認・終了時の停止に置き換えて書きます。 **プライバシーマークがなければ台帳は要りませんか** 指針は付与を受ける事業者の要求事項です。ただし個人情報保護法の通則編も、取扱状況を確認する手段の例に「アクセス権を有する者」の明確化を挙げているため、一覧は法の側でも役に立ちます。 ## 参考資料 - [JIPDEC「プライバシーマークにおける個人情報保護マネジメントシステム構築・運用指針【JIS Q 15001:2023 準拠 ver1.0】」(2023 年 12 月 25 日制定)](https://privacymark.jp/guideline/pm_shishin2023v1.0.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、台帳の「アクセス権を有する者」と、その人が使った記録の 2 つを担います。管理者が共有アカウントを登録して使う人を決める(割り当て)ので、一覧はその画面にあります。担当者はスマホで本人確認をしてから使い、記録は一人ひとり残ります。契約終了や退職では割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 不正アクセス禁止法と ID・パスワードの共有(識別符号の扱い) 会社が契約するサービスの共有 ID を、会社の承諾を得た担当者が使う行為は、不正アクセス行為から除かれると読めます。退職者の利用、委託先への提供、社外に教える行為は、承諾の範囲と 5 条の「業務その他正当な理由」で分かれます。 更新日: 2026-09-18 不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)は、ID とパスワードの共有そのものを禁じる条文を持っていません。会社が契約するサービスの共有 ID を、会社の承諾を得た担当者が使う行為は、2 条 4 項 1 号の括弧書きにより不正アクセス行為から除かれると読めます。分かれ目は、承諾が誰に、いつまで与えられているかと、パスワードを教える行為が 5 条の「業務その他正当な理由による場合」に当たるかです。この記事は条文と警察庁の解説で確かめられる範囲の整理で、法的助言ではありません。個別の事案は弁護士に相談してください。 ## 条文の言葉を先に押さえる 不正アクセス行為の 3 つの型と罰則は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access)にあります。ここでは、共有の場面を読むのに要る 3 つの語だけを押さえます。 | 語 | 条文 | 平たく言うと | | --- | --- | --- | | アクセス管理者 | 2 条 1 項。特定電子計算機の利用について「特定電子計算機の動作を管理する者」 | そのシステムを誰にどこまで使わせるかを決める側 | | 利用権者 | 2 条 2 項。特定利用について「アクセス管理者の許諾を得た者」 | 使ってよいと認められた人や会社 | | 識別符号 | 2 条 2 項。利用権者等ごとに付される符号で、「みだりに第三者に知らせてはならないものとされている符号」(1 号)など | ID とパスワードの組み合わせ | 警察庁の解説は、この 3 つに補足を付けています。法人が運用するシステムのアクセス管理者は、担当のシステム管理者ではなく法人自体です。許諾は、文書でも口頭でも、暗黙の了解でもかまいません。識別符号の中心はパスワードで、ID は「その他の符号」に当たり、ID とパスワードの組み合わせが識別符号になります。 会社が外部の SaaS を契約している場合、アクセス管理者はそのサービスを提供する会社で、利用権者は契約した会社です。会社の担当者は、会社(利用権者)から使ってよいと言われた人になります。 ## 5 つの場面を条文で読む ### 場面 1 会社の共有 ID を担当者に使わせる 2 条 4 項 1 号の括弧書きは、「当該識別符号に係る利用権者の承諾を得てするもの」を不正アクセス行為から除いています。会社が利用権者なら、会社の承諾を得た担当者の入力はこれに当たると読めます。 警察庁の解説は、承諾を得た利用の例として、会社の同僚に自分の代わりにメールが着信していないかの確認を頼む場合を挙げています。承諾は口頭でも成り立ちますが、誰に、どのアカウントを、いつまで認めたかが分からないと、場面 2 や 3 で承諾の範囲を説明できません。使ってよい人の一覧と、認めた日と外した日の記録が、承諾の範囲を示す資料になります。 ### 場面 2 退職者が元の共有 ID で入る 関わる条文は 2 条 4 項 1 号、3 条、11 条です。承諾がいつまでかは条文に書かれていません。退職により承諾の範囲を外れたと見られれば、他人の識別符号の入力として 3 条の禁止に当たり得ますが、個別の事実で判断されます。 会社の側の作業は、条文の当てはめとは別にあります。解説は、8 条の適正な管理の例として「利用権者の異動時における識別符号の確実な追加・削除、長期間利用されていない識別符号の確実な削除」を挙げています。会社が自社のシステムのアクセス管理者なら、退職者の ID を消すことがこれに当たります。外部の SaaS の共有 ID では、会社はアクセス管理者ではなく利用権者ですが、パスワードを変えなければ退職者は入れる状態のままです。退職後の利用が不正アクセス行為に当たるかどうかとは別に、入れる状態を残さないのは会社の側の作業です。元従業員が退職後に入った事案は[退職後に社外の Web サービスへ不正アクセスされた事案](/guides/incidents/saas-account-alive-after-resignation)にあります。 ### 場面 3 委託先の担当者に共有 ID を渡す 関わる条文は 2 条 4 項 1 号と 5 条です。会社が承諾を与えれば、委託先の担当者の入力は場面 1 と同じ扱いになると読めます。会社の承諾を得た提供は、解説で通常「業務その他正当な理由による場合」に当たると解されています。契約に、使う担当者と契約終了時の扱いを書いておくと、その契約が承諾の範囲を示す資料になります。 ### 場面 4 会社のパスワードを社外の人に教える 5 条は、業務その他正当な理由がなければ、アクセス管理者と利用権者以外への提供を禁じます。罰則は 12 条と 13 条にあり、相手の不正アクセスの目的を知っていれば 1 年以下の拘禁刑または 50 万円以下の罰金、知らなければ 30 万円以下の罰金です。 解説は、「業務その他正当な理由」を「社会通念上、正当と認められるような場合」と説明しています。例は、流出した識別符号のリストを情報セキュリティ事業者が契約企業に提供する行為などです。アクセス管理者や利用権者の承諾を得て提供する場合も、通常はこれに当たると解説は書いています。解説は、自らが管理する識別符号を、他社への不正アクセスに使われると知りながら提供する場合を、当たらない例に挙げています。会社のパスワードを、業務の範囲を超えて社外の知人に教える行為は、承諾も業務もなければ 5 条に触れると読めます。 ### 場面 5 会社が自社のシステムを持つ側のとき この場面で関わるのは 8 条です。アクセス管理者は「識別符号又はこれを当該アクセス制御機能により確認するために用いる符号の適正な管理に努める」ものとされています。罰則のない努力義務です。 ## 共有 ID そのものは法律に触れるか 識別符号は、アクセス管理者が利用権者を「他の利用権者等と区別して識別することができるように付される符号」です。1 つの識別符号を複数人が使うと、その符号からは使った人を区別できません。しかし条文に、1 つの識別符号を複数人で使うことを禁じる規定はありません。区別は法律の要求ではなく、8 条の適正な管理と、事故のあとに誰が使ったかを説明するための会社の側の必要です。解説が 8 条の例に挙げる「ログを取得しその定期的な検査を行う」は、共有 ID では使った人を別の手段で残さないと役に立ちません。 ## 会社として用意しておくもの 用意しておくものは 2 つです。 - 共有 ID ごとに、使ってよい人と、認めた日・外した日の一覧。場面 1・2・3 の承諾の範囲を示します - 委託先との契約に書いた、使う担当者と契約終了時の扱い。場面 3 の承諾の範囲を示します 2 つとも、条文が直接求めているものではありません。承諾の範囲を、あとから説明できる形にするための資料です。退職・契約終了時に止める手順と、誰が・いつ使ったかの記録は、他の法令や指針とも共通で、[法令・ガイドラインとアカウント管理](/guides/compliance)にまとめています。 ## よくある質問 **社員に会社の共有 ID を使わせるのは違法ですか** 会社が利用権者として承諾した担当者の入力は、2 条 4 項 1 号の括弧書きで不正アクセス行為から除かれると読めます。誰に認めたかを一覧で残しておきます。 **退職した人が元の ID で入ったら犯罪ですか** 承諾がいつまでかは条文にありません。退職で承諾の範囲を外れたと見られれば 3 条の禁止に当たり得ますが、個別の事実で判断されます。会社側はパスワードを変えるか ID を消します。 **委託先にパスワードを渡すのは 5 条に触れますか** 会社の承諾を得た提供は、解説で通常「業務その他正当な理由」に当たると解されています。契約は承諾の範囲を示す資料になります。不正に使われると知って渡す場合は除かれます。 **会社にも罰則のある義務がありますか** 8 条の適正な管理は罰則のない努力義務です。警察庁の解説は、異動時の識別符号の追加・削除や、使われていない識別符号の削除を例に挙げています。 ## 参考資料 - [不正アクセス行為の禁止等に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/411AC0000000128) - [警察庁「不正アクセス行為の禁止等に関する法律の解説」](https://www.npa.go.jp/bureau/cyber/pdf/1_kaisetsu.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify では、共有アカウントのパスワードは管理者が登録し、担当者には教えません。担当者はスマホで本人確認をしてから使うので、誰に認めたか(割り当て)と誰が使ったかが同じ画面に残ります。退職や委託終了では割り当てを外すだけで、パスワードを変えずに済みます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # ISMS(情報セキュリティマネジメントシステム)とは ISMS とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。国際規格 ISO/IEC 27001 に沿って作り、第三者の審査を受けて認証を取ることができます。 更新日: 2026-10-13 ISMS(情報セキュリティマネジメントシステム)とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。ISMS-AC の説明では、組織が自らのリスクアセスメント(どこにどんな危険があるかの見積もり)で必要な水準を決めます。そして計画を持ち、資源を配分してシステムを運用します。 ## ISMS は何のためにあるのか 目的は、リスクを適切に管理しているという信頼を利害関係者に与えることです。守る対象は情報の 3 つの性質で、機密性(許された人だけが見られること)、完全性(内容が勝手に変わらないこと)、可用性(必要なときに使えること)です。個々の対策ではなく、対策を決めて運用する組織の仕組み全体を指します。 ## ISO/IEC 27001 と認証はどういう関係か ISO/IEC 27001 は、ISMS が満たすべき要求事項を定めた国際規格です。日本語版は JIS Q 27001 で、ISO/IEC 27001:2022 に対応する JIS Q 27001:2023 が 2023 年 9 月 20 日に改正されました。2025 年 5 月 20 日には追補 1(ISO/IEC 27001:2022/Amd 1:2024 に対応)が公示され、JIS Q 27001:2025 になっています。規格は、本文の必須の要求事項と、附属書 A の管理策(事業の特性により除外できる)で構成されます。 認証は、組織の ISMS がこの規格に適合しているかを、第三者の認証機関が審査して登録する仕組みです。日本では ISMS 適合性評価制度がこれにあたります。制度の認定機関(審査をする認証機関を認める立場)は、情報マネジメントシステム認定センター(ISMS-AC)です。規格は、あらゆる形態・規模の組織に適用できることを意図しています。 ## アカウント管理はどこで問われるか 附属書 A には 93 の管理策があり、組織的・人的・物理的・技術的の 4 つに分かれています。2022 年の改訂で、管理策は 114 から 93 に整理されました。旧版の「A.9 アクセス制御」「A.15 供給者関係」などの区分は、この 4 つに組み替えられています。JIPDEC のユーザーズガイドは、委託先とリスクを分け合うときの管理策として「5.19 供給者関係における情報セキュリティ」を挙げています。対策を契約書などに織り込むことが重要だ、とも書いています。管理策の指針である JIS Q 27002 は、各管理策に 5 つの属性を付けています。ユーザーズガイドによれば、属性「運用機能」の値に「識別情報及びアクセスの管理」と「供給者関係のセキュリティ」があります。属性「管理策タイプ」の値は、予防、検知、是正の 3 つです。事故の発生を防ぐもの、発生したときに働くもの、発生した後に働くもの、という分け方です。 アクセス制御や認証情報に関する個々の管理策の文言は、規格本文にあります。規格本文は有料で、この記事で参照した JIPDEC の資料には管理策の一覧までは載っていません。管理策の番号と名称は、日本規格協会が公開している JIS Q 27002:2024 の目次で確かめられます。公開資料で分かるのは、管理策の番号と名称と、アクセス制御や供給者関係が附属書 A の対象に含まれることまでです。自社にどの管理策が求められるかは、規格を入手して確かめる必要があります。 ## 取引先から ISMS 認証を求められたら何を意味するか 認証を求める取引先は、方針と手順を決めて運用し、第三者の審査を受けた組織かどうかを見ています。認証は組織の仕組みに対するもので、預けたアカウントを誰が使い、誰が使ったかがどう残るかまでを保証するものではありません。その部分は、どの管理策を適用したかを書いた適用宣言書と、契約の内容で別に確かめることになります。 ## よくある質問 **ISMS と ISO 27001 は同じものですか** 同じではありません。ISMS は組織が作って運用する仕組みで、ISO/IEC 27001 はその仕組みが満たすべき要求事項を定めた規格です。認証は、仕組みが規格に合っているかを第三者が審査した結果です。 **ISMS 認証は中小企業でも取れますか** 取れます。ISMS-AC は、規格はあらゆる組織に適用できるよう配慮されていると説明しています。ただし審査には費用と準備がかかるため、取引先の要求と照らして判断します。 **取引先が ISMS 認証を持っていれば安心ですか** 認証は、方針と手順を決めて運用し、第三者の審査を受けたことを示します。どの管理策を適用したか、預けたアカウントをどう扱うかは、適用宣言書(どの管理策を使うと決めたかを書いた文書)と契約で確かめます。 ## 参考資料 - [ISMS-AC「ISMS(情報セキュリティマネジメントシステム)とは」](https://isms.jp/isms/) - [ISMS-AC「ISMS 適合性評価制度」パンフレット(JIP-ISMS120-7.2、2025 年 8 月)](https://isms.jp/doc/JIP-ISMS120-72.pdf) - [ISMS-AC「JIS Q 27001:2025(ISO/IEC 27001:2022+Amd 1:2024)発行のお知らせ」(2025 年 5 月 20 日)](https://isms.jp/topics/news/202500520.html) - [JIPDEC「ISMS ユーザーズガイド」(JIP-ISMS111-4.0、2025 年 3 月)](https://www.jipdec.or.jp/archives/publications/JIP-ISMS111-4.0.pdf) - [JIPDEC「ISMS 認証基準(ISO/IEC 27001)の改訂」](https://www.jipdec.or.jp/library/itreport/2022itreport_winter06.html) - [日本規格協会「JIS Q 27001:2023」](https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+27001%3A2023) - [日本規格協会「JIS Q 27002:2024 情報セキュリティ，サイバーセキュリティ及びプライバシー保護―情報セキュリティ管理策」プレビュー(目次。2024 年 6 月 20 日改正)](https://webdesk.jsa.or.jp/preview/pre_jis_q_27002_000_000_2024_j_ed10_ch.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、附属書 A のアクセス制御に関わる 3 点を仕組みで担います。担当者がスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。パスワードは管理者が登録し、担当者には渡しません。担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # IT 全般統制(ITGC)とは IT 全般統制とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」とされるもので、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理が例に挙がります。 更新日: 2026-09-18 IT 全般統制(ITGC)とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」と説明されるものです。通常、複数の業務処理統制に関係する方針と手続を指します。業務処理統制とは、承認された業務がすべて正確に処理・記録されるように、システムに組み込まれた仕組みです。それが正しく働き続けるための土台となる、システムの管理を指す言葉です。 ## 誰に関係するのか 内部統制報告制度は、金融商品取引法により上場会社を対象に、財務報告に係る内部統制を経営者が評価し、監査人が監査する制度です。2023 年 4 月 7 日の改訂版の基準と実施基準は、2024 年 4 月 1 日以後に始まる事業年度から適用されています。実施基準は、この制度の IT の統制は財務報告の信頼性を確保するためのもので、それ以外の目的の IT の統制を直接求めるものではない、と書いています。評価の対象になるのは、財務報告(決算の数字)に関わるシステムとその基盤です。 ## 何が例に挙がっているか 実施基準は、全般統制の例として次の 4 つを挙げています。 - システムの開発、保守に係る管理: 新しいシステムを作る、直すときの手続 - システムの運用・管理: 日々動かすときの手続 - 内外からのアクセス管理などシステムの安全性の確保: 誰がシステムに入れるかの管理 - 外部委託に関する契約の管理: 委託先との契約とその管理 全般統制は、業務システムを支えるハードウェア、ソフトウェア、ネットワークなどの IT 基盤を単位に作ります。 ## アクセス管理はどこで問われるか 実施基準は、プログラムへの不正な改ざんや不正なアクセスで全般統制が有効に働かない場合を挙げています。その場合、業務処理統制を組み込んでいてもその有効性が保証されなくなる、という説明です。そのうえで、プログラムの不正な使用や改ざんを防ぐために、システムへのアクセス管理に関して適切な対策を講じることを挙げています。業務処理統制の側にも、システムの利用に関する認証、操作範囲の限定などアクセスの管理が例として挙がっています。誰がシステムに入れるかは基盤の全般統制で、入った人が何を操作できるかは業務システムの業務処理統制で、と両方の側から見られます。 ## 管理者用のアカウントはなぜ重点になるか 管理者用のアカウント(強い権限を持つ ID。特権 ID とも呼ばれます)は、プログラムやデータを直接変えられます。実施基準は、統制活動が自動化されていると、プログラムの不正な改ざんや不正な使用にプログラムに精通した者しか対応できない、と書いています。その結果、不正の発見が難しくなるため、適切なアクセス管理の措置に留意するよう求めています。意見書と実施基準に「特権 ID」「特権アカウント」という語はありませんが、この記述が、強い権限を誰が持ち、いつ誰が使ったかを説明できる状態を求める根拠になります。管理者用のアカウントを 1 つの ID で複数の担当者が使っている場合、システムの記録には誰が操作したかが残りません。 ## 何を用意しておくか 実施基準の記述をもとに 3 つ、それに定期的な見直しの記録を加えて 4 つに整理すると、次のようになります。 - 誰がどのシステムにどの権限で入れるかの一覧 - 権限を付けたり外したりしたときの承認の記録 - 強い権限を使ったときの記録 - 権限が今も必要な人だけに付いているかを定期的に見直した記録 4 つ目は実施基準に直接の文言がなく、金融庁の金融分野のガイドラインに近い記述があります。記録は、後から取り出せる形で残っている必要があります。 ## よくある質問 **IT 全般統制は上場していない会社にも関係しますか** 内部統制報告制度の対象は上場会社です。ただし、上場会社の子会社は親会社の評価の範囲に入り、上場会社から受託した業務の内部統制も委託元の評価の範囲に入ることがあります。上場準備中の会社は事前に整えます。 **IT 全般統制と IT 業務処理統制はどう違いますか** 業務処理統制は、承認された業務がすべて正確に処理・記録されることを確保する、システムに組み込まれた統制です。全般統制は、その業務処理統制が有効に働く環境を保証する方針と手続です。 **管理者用のアカウントは何を見られますか** 実施基準は、プログラムの不正な使用や改ざんを防ぐためにアクセス管理の対策を講じることを求めています。強い権限を持つ ID を誰が持ち、いつ誰が使ったかを説明できる状態が問われると読めます。 ## 参考資料 - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」(2023 年 4 月 7 日改訂)](https://www.fsa.go.jp/singi/singi_kigyou/kijun/20230407_naibutousei_kansa.pdf) - [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について(意見書)」(令和 5 年 4 月 7 日)](https://www.fsa.go.jp/news/r4/sonota/20230407/1.pdf) - [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、アクセス管理のうち共有アカウントと管理者用アカウントの部分を担います。担当者がスマホで本人確認をしてから使うので、誰が・いつどのアカウントを使ったかが一人ひとり残り、一覧で出せます。パスワードは担当者に渡らず、担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 安全管理措置とは 安全管理措置とは、個人情報保護法 23 条が事業者に義務づける、個人データの漏えい・滅失・毀損を防ぐ対策です。通則編の別添が、組織的・人的・物理的・技術的の 4 区分と外的環境の把握で内容を示します。 更新日: 2026-09-18 安全管理措置とは、個人情報保護法 23 条が個人情報取扱事業者に義務づける対策です。条文は、個人データの「漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置を講じなければならない」と定めています。情報が漏れたり、消えたり、壊れたりしないための対策を行わなければならない、という意味です。具体的な内容は、個人情報保護委員会のガイドライン(通則編)の「10(別添)講ずべき安全管理措置の内容」にあります。 ## 誰に、どこまで求められるのか 対象は、個人情報データベース等(特定の個人情報を検索できるように整理した情報の集まり)を事業に使う事業者です。通則編は、措置の内容は事業の規模や扱う個人データの性質と量などによるリスクに応じて決めればよく、例示のすべてを行う必要はない、と書いています。一方で、別添が「講じなければならない措置」として挙げる項目は、規模を問わず求められます。 ## 別添は何を求めているか | 区分 | 講じなければならない措置 | | --- | --- | | 組織的安全管理措置 | 組織体制の整備、規律に従った運用、取扱状況を確認する手段の整備、漏えい等事案に対応する体制の整備、取扱状況の把握と見直し | | 人的安全管理措置 | 従業者の教育 | | 物理的安全管理措置 | 個人データを扱う区域の管理、機器・電子媒体等の盗難等の防止、持ち運ぶ場合の漏えい等の防止、削除と廃棄 | | 技術的安全管理措置 | アクセス制御、アクセス者の識別と認証、外部からの不正アクセス等の防止、情報システムの使用にともなう漏えい等の防止 | | 外的環境の把握 | 外国で個人データを扱う場合に、その国の制度を把握したうえで措置を講じる | ## アカウント管理に関わる項目はどれか アカウント管理に直接関わるのは、技術的安全管理措置の 4 つの中では 2 つです。「アクセス制御」は、担当者と取り扱う個人情報データベース等の範囲を限定することです。手法の例に、ユーザー ID に付与するアクセス権で、情報システムを使える従業者を限定することが挙がっています。「アクセス者の識別と認証」は、情報システムを使う従業者が「正当なアクセス権を有する者であることを、識別した結果に基づき認証」することです。誰かを確かめてから、その人に権限があるかを見てログインさせる、という意味です。 記録は組織的安全管理措置の側にあります。「規律に従った運用」の手法の例に、担当者の情報システムの利用状況(ログイン実績、アクセスログ等)の記録が挙がっています。取扱いを後から検証できるようにするためです。使える人の一覧は、同じ組織的安全管理措置の「取扱状況を確認する手段の整備」にあります。あらかじめ明確にしておく項目の例に「アクセス権を有する者」が挙がっており、手段を整備すること自体は講じなければならない措置です。共有アカウントでは、情報システムの側で使った人を識別できません。通則編に共有を禁じる記述はありません。ただ、識別と認証と利用状況の記録を満たすには、誰が使ったかを別の手段で特定できるようにしておく必要があると読めます。 ## 中小規模事業者は何をすればよいか 通則編は、従業員 100 人以下の事業者を「中小規模事業者」とし、義務は同じままで、簡単な手法の例を別に示しています。扱う個人情報の本人の数が過去 6 か月のいずれかの日に 5,000 人を超えた事業者と、委託を受けて個人データを扱う事業者は除かれます。中小規模事業者向けの例では、アクセス制御は、個人データを扱える機器と従業者を明確にして不要なアクセスを防ぐことです。識別と認証は、機器に最初から付いている、使う人ごとにログインを分ける機能(ユーザーアカウント制御)で、使う従業者を識別・認証することです。 ## 従業者と委託先にはどう及ぶか 24 条は従業者への「必要かつ適切な監督」を求め、従業者にはパート・アルバイト、派遣社員、役員も含まれます。25 条は委託先の監督を求めます。通則編は、委託先の安全管理措置が委託元に求められるものと同等であることを、別添の各項目に沿ってあらかじめ確認しなければならない、としています。 ## よくある質問 **安全管理措置は何をすれば足りますか** 通則編は、事業の規模や性質、扱う個人データの量や性質によるリスクに応じた内容でよいとし、例示のすべてを行う必要はないと書いています。ただし別添の「講じなければならない措置」自体は省けません。 **従業員 100 人以下なら何が軽くなりますか** 義務は同じですが、通則編は中小規模事業者向けに簡単な手法の例を示しています。扱う本人の数が過去 6 か月のいずれかの日に 5,000 人を超えた事業者と、委託を受けて個人データを扱う事業者は含まれません。 **共有アカウントは安全管理措置に反しますか** 通則編に共有を禁じる記述はありません。ただし、使う従業者が正当なアクセス権を持つ者であることを識別した結果に基づき認証することが求められるため、誰が使ったかを確かめる手段が別に必要です。 **委託先にも安全管理措置を求める必要がありますか** あります。通則編は、委託先の安全管理措置が委託元に求められるものと同等であることを、別添の各項目に沿ってあらかじめ確かめるよう求めています。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、技術的安全管理措置のうち「アクセス者の識別と認証」と「利用状況の記録」に関わる部分を担います。担当者がスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。パスワードは担当者に渡らず、担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # SOC 2 とは SOC 2 とは、クラウドなどのサービスを提供する会社の内部統制を、公認会計士が AICPA の Trust サービス規準に照らして検証し報告する仕組みです。セキュリティなど 5 つの区分で見ます。 更新日: 2026-09-18 SOC 2 とは、クラウドなどのサービスを提供する会社(受託会社)の内部統制を、公認会計士が検証して報告書にまとめる仕組みです。照らし合わせる基準は、AICPA(米国公認会計士協会)の Trust サービス規準です。AICPA は、顧客やビジネスパートナーが、統制の設計・運用・有効性の情報を必要とし、SOC 2 報告書を求めることが多い、と説明しています。 ## 5 つの区分は何を見るか Trust サービス規準は、AICPA の委員会が定めた統制の評価規準で、日本公認会計士協会が翻訳を公開しています。規準は 5 つの区分に分かれ、報告の対象は、5 つのうち 1 つ以上の区分です。 | 区分 | 規準の定義 | | --- | --- | | セキュリティ | 情報とシステムが、未承認のアクセス、未承認の情報の開示、システムのダメージから保護されている | | 可用性 | 情報とシステムが、組織の目的を達成するように操作でき、使用できる | | 処理のインテグリティ | システム処理が、完全、正当、正確、適時で、承認されている | | 機密保持 | 機密とされた情報が保護されている | | プライバシー | 個人に関する情報が、目的に沿って収集、使用、保持、開示、廃棄されている | ## Type 1 と Type 2 は何が違うか Trust サービス規準の説明では、Type 2 の SOC 2 業務は、特定の期間を通じた統制のデザインの適切性と運用の有効性を対象とします。報告書には、監査人が実施した統制のテストとその結果の詳細な記述が含まれます。Type 1 は同じ主題を扱いますが、運用の有効性に関する意見も、テストの結果の記述も含まれません。Type 1 は統制が設計されているかを、Type 2 はその統制が期間を通じて実際に働いていたかを示す、ということです。 ## アクセス管理はどこで見られるか 5 つの区分に共通して使われる共通規準の中に「論理的及び物理的アクセス管理」の項目群(CC6)があります。アカウント管理に関わるのは次の 3 つです。 CC6.1 は、論理的なアクセスセキュリティのソフトウェアと仕組み(システムへの入り口を制限する仕組み)を導入し、情報資産を守ることを求めます。その着眼点(規準を満たしているかを見るときの観点)に、ユーザーの識別と承認があります。CC6.2 は、新しい利用者を登録・承認してからアクセスを許可し、アクセスが承認されなくなったときに資格を削除することを求めます。CC6.3 は、最小権限の原則と職務分離(1 人で完結させない役割分担)を考慮して、役割や責任に基づきアクセスを承認、変更、削除することを求めます。 CC6.2 の着眼点には、アクセス資格の適切性を定期的に見直すことも含まれます。取引先の立場でこの部分を読むと、預けたアカウントを誰が使えるかが管理され、要らなくなった人のアクセスが削除されているかが分かります。Type 2 なら、その手続が期間を通じて働いていたかも分かります。 ## 取引先から求められたらどうするか SOC 2 報告書を求める取引先は、サービスの内部統制を自分で監査する代わりに、公認会計士の報告書で確かめようとしています。報告書がない場合、取引先はセキュリティチェックシート(安全対策を確かめる質問票)などで同じ点を聞いてくることがあります。誰がどのアカウントを使えるかの一覧、付与と削除の手続と記録、使ったときの記録を出せる状態にしておくと、報告書の有無にかかわらず答えやすくなります。検証を受けるかどうかは、取引先の要求と費用を見て判断します。 ## よくある質問 **SOC 2 は認証ですか** 認証ではなく、公認会計士による検証の報告書です。ISMS のように登録証が出る制度ではなく、報告書の中の意見と、統制の記述、Type 2 ならテストの結果を読んで判断します。 **5 つの区分をすべて受ける必要がありますか** 必要ありません。Trust サービス規準は、5 つのうち 1 つ以上の区分を選んで使えるよう作られています。取引先が求める区分を確かめてから範囲を決めます。 **取引先の SOC 2 報告書は何を確かめればよいですか** 報告書の対象となったシステムの範囲と期間、Type 1 か Type 2 か、意見の内容、アクセス権の付与と削除に関する統制とそのテスト結果です。範囲外のサービスは報告書では分かりません。 ## 参考資料 - [AICPA & CIMA「SOC 2 - Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy」](https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy) - [AICPA & CIMA「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) - [日本公認会計士協会「セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準」(AICPA 2017 年版の翻訳、2022 年 12 月 28 日)](https://jicpa.or.jp/specialized_field/ITI/files/0-51-0-2a-20221228.pdf) - [日本公認会計士協会「AICPA『セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシーに関する Trust サービス規準』の翻訳の公表について」](https://jicpa.or.jp/specialized_field/ITI/2022/20221228tzq.html) ## Junify の場合 **人手で続けると** 求められている措置を自社の運用に読み替え、アカウントの一覧・権限・記録を監査で出せる形で保ち、指針が改定されるたびに読み直すことになります。 **Junify なら** Junify は、次の 3 点を仕組みで担います。担当者がスマホで本人確認をしてから使うので、誰が・いつどのアカウントを使ったかが一人ひとり残ります。パスワードは管理者が登録し、担当者には渡しません。担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](/guides/compliance/cis-controls-account-access-management): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。 - [漏えい等の報告で、アクセスの記録(ログ)から示すこと](/guides/compliance/data-breach-report-access-logs): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。 - [政府の統一基準が求める ID の管理と委託先の対策](/guides/compliance/government-unified-standards-accounts): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。 --- # 公表された事故から、アカウント管理の何が問われたか 辞めた人のアカウントが生きていた、委託先の担当者がパスワードを知っていた。公表された事故の原因は、この 2 つに行き着きます。どちらも業種や規模を選びません。 更新日: 2026-09-18 アカウントの扱いに関わる事故は、公表文を読むと 4 つの型に分けられます。退職者や元委託先による不正アクセス、委託先の担当者経由の漏えい、共有パスワードの流出と使い回し、公式 SNS アカウントの乗っ取りです。当事者が公表した原因は事案ごとに違いますが、成り立つ条件は 2 つに絞られます。パスワードを人が知っていることと、辞めた人や担当を外れた人のアカウントが生きていることです。どちらも、業種や規模を選びません。 不正アクセスは、他人の ID とパスワードでシステムに入る行為を中心に、不正アクセス禁止法が定める行為です([不正アクセスとは](/guides/incidents/what-is-unauthorized-access))。内部不正は、役員・従業員・退職者など内部の人による、情報の持ち出しや破壊です([内部不正とは](/guides/incidents/what-is-insider-threat))。漏えい等は、個人データが外に出る・失われる・壊れることをまとめた、個人情報保護法の言葉です([漏えい等とは](/guides/incidents/what-is-data-breach))。 ## 事故の 4 つの型 ### 1 退職者・元委託先による不正アクセス 退職した人や契約が終わった委託先の人が、在職中の ID や知っていたパスワードでシステムに入る型です。ある市は、退職した小学校の臨時的任用講師が[退職後に市のシステムへ不正にアクセス](/guides/incidents/former-staff-login-after-leaving)したとして逮捕された、と公表しています。人材サービス会社では、元従業員が[退職後に社外の名刺管理サービスへ入り](/guides/incidents/saas-account-alive-after-resignation)、名刺情報が漏えいしました。社内の端末やメールを止めても、社外のサービスのアカウントは別に止めなければ残ります。計測機器メーカーの事案は持ち出しではなく、退職者が[サーバーのデータを消した](/guides/incidents/former-employee-deleted-data)ものです。 止め忘れの理由を当事者が書いた例もあります。別の市は、元職員が[退職日の翌日にも庁内の端末から個人情報を持ち出した](/guides/incidents/former-staff-took-files-before-and-after-leaving)ことについて、退職翌日もアカウントの削除処理が行われていなかったことを原因の一つに挙げました。 退職の前も同じ型です。人材サービス会社では[退職の直前に社内資料が持ち出され](/guides/incidents/documents-taken-just-before-resignation)、判明したのは退職の 1 年余り後でした。通信事業者は、[退職を申し出てから退職日までの間に技術情報が持ち出された](/guides/incidents/access-between-resignation-notice-and-last-day)事案で、退職予定者のアクセス権限の停止・制限の強化を再発防止策に挙げています。警察庁は、利用する立場でなくなった人の ID の削除かパスワードの変更を求めています。問われるのは、退職や契約終了の日に、その人が使えた ID をすべて止めているかです。 ### 2 委託先の担当者経由の漏えい 委託先や再委託先の担当者が、委託元の顧客情報を持ち出す型です。委託先が管理するアカウントや端末が破られる事故も、この型に入ります。通信事業者の子会社では、保守を担う委託先の元派遣社員が[共用の管理者アカウント](/guides/incidents/contractor-shared-admin-account)で約 10 年にわたり顧客情報を持ち出し、対象は 69 のクライアントの顧客 928 万件でした。別の通信事業者では、委託先の元派遣社員が[業務用パソコンから個人契約の外部ストレージへ約 596 万件を送り](/guides/incidents/contractor-sent-data-outside)、委託元のネットワーク監視が当日に検知しています。 委託の階層が深くなるほど、委託元から作業者が見えなくなります。ある市の事案では、[市に無断の再々委託先の従業員](/guides/incidents/undisclosed-subcontractor-copied-data)が全市民約 46 万人分のデータを持ち出して紛失しました。調査報告書は、パスワードが口頭で伝わり、案件を離れた人や転職した人も知ったままだったと書いています。空調機器メーカーでは、[4 階層目の作業者](/guides/incidents/fourth-tier-contractor-downloaded-data)が仕入先担当者の個人情報約 2.2 万件をダウンロードしました。 委託先と共有しているのは人だけではありません。情報サービス会社では、[共有ツールの正規の ID とパスワードが盗まれ](/guides/incidents/shared-tool-ids-used-for-intrusion)、正常なログインに見える形で 142 の顧客に影響が出ました。別の情報サービス会社では、[委託先のパソコンの感染](/guides/incidents/contractor-pc-malware-shared-auth)が、共通のログインの仕組みでつながっていた社内システムへの侵入につながり、44 万件が漏えいしました。委託先の誰が自社のどのアカウントを使うかを、委託元が把握しているかが問われます。 ### 3 共有パスワードの流出と使い回し 複数人が知っているパスワードや、ほかのサービスと同じパスワードが、そのまま入口になる型です。法人向けサービスの管理画面では、[ほかのサービスから漏れた ID とパスワードの組を試す攻撃](/guides/incidents/reused-password-list-attack)で、国内 12 件・海外を含め 156 件の ID が乗っ取られました。運営会社は、不正ログインが確認されたのは二段階認証をオフにしていた ID のみだったとしています。 同じパスワードを組織の中で使い回すと、1 か所破られただけで全体に広がります。公立の精神科病院では、保守用の外部接続機器と院内すべてのパソコンで[同じ推測しやすい ID とパスワード](/guides/incidents/reused-admin-password-ransomware)が使われ、最大 4 万人分の個人情報が対象になりました。公立の総合病院では、給食の委託先の機器から侵入され、[サーバーと端末で共通だったパスワード](/guides/incidents/shared-password-with-supplier)で被害が広がり、全体の復旧に 73 日かかっています。 個人情報保護委員会の指導事例にも、[4 桁の管理者パスワードや、事業の名称を使った文字列、初期設定のままの ID](/guides/incidents/weak-and-default-passwords-in-guidance)が原因として並びます。この型で問われるのは、パスワードを誰が知っているか、変えたときに全員へ配り直しているかです。 ### 4 公式 SNS アカウントの乗っ取り 公式アカウントのログイン情報が、担当者や代行会社の側から漏れる型です。カメラ・レンズメーカーは、[運営元を装ったメールに担当者が対応した結果](/guides/incidents/phishing-took-over-official-sns)、公式 Instagram アカウントが削除されたと公表しています。自動車用品の小売会社では、[運営を任せていた代行会社の Google アカウントへの不正アクセス](/guides/incidents/agency-google-account-breached)から、公式 X で無関係な投稿が行われ、YouTube ではチャンネル名の変更や動画の削除が起きました。 原因が公表されることは多くありません。[公式 SNS の乗っ取りを公表した 9 件](/guides/incidents/official-sns-takeovers-from-notices)のうち、原因を書いたのは 1 件です。9 件に共通するのは、アカウントのパスワードを人が知っていることだけです。公式アカウントのパスワードを誰が持ち、誰が投稿できるかが決まっているかが問われます。 ## 公的な数字で見る規模 警察庁などの年次資料「不正アクセス行為の発生状況」(令和 6 年分)によると、令和 6 年に検挙した不正アクセス行為は 533 件でした。そのうち、他人の ID とパスワードを入力して入る型(識別符号窃用型)は 511 件です。手口で最も多いのが「パスワードの設定・管理の甘さにつけ込んで入手」の 174 件です。次が「識別符号を知り得る立場にあった元従業員や知人等による犯行」の 107 件で、前年の 68 件から約 1.57 倍に増えています。 個人情報保護委員会の四半期ごとの公表では、令和 6 年度第 1 四半期の民間事業者への指導・助言は 110 件でした。最も多いのが外部からの不正アクセス等の防止の不備の 44 件で、委託先に対する監督の不備が 8 件、アクセス制御(誰がどこまで使えるかの制限)の不備が 5 件です。指導事案の概要には、管理者用アカウントの一部のパスワードが 4 桁だった事案や、委託先が管理するアカウントのパスワードが事業の名称を使った簡単な文字列だった事案があります。 ## 公表文の読み方 公表文は、原因と再発防止策を当事者が自分で書いたもので、同じ型の管理が自社にもあるかを確かめる材料になります。原因が書かれていない事案に推測を足すと、点検が実際の事故から離れます。 ## 自分の現場を点検する 4 つの問い 1. 先月退職した人と、契約が終わった委託先の担当者が使えた ID を、すべて挙げられるか。その全部が止まっているか。 2. 部門の共有アカウントや公式 SNS アカウントのパスワードを、いま誰が知っているか。辞めた人や担当を外れた人が、その中にいないか。 3. 共有アカウントで操作があったとき、誰が操作したかを、その日のうちに言えるか。 4. 委託先や再委託先の誰が自社のどのアカウントを使っているかを、委託元として一覧で持っているか。 ## このテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 - [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](/guides/incidents/contractor-sent-data-outside): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 - [委託先の保守担当者が管理者アカウントを共用していた事案から分かる、管理者権限と記録](/guides/incidents/contractor-shared-admin-account): コールセンターの仕組みを保守する委託先の元派遣社員が、約 10 年間、管理者用のアカウントで顧客情報を持ち出しました。共用の管理者アカウント、持ち出しを止める設定の不在、記録を点検する運用の不在が原因として公表されています。 - [退職の直前に顧客情報を持ち出された事案から分かる、退職時の業務情報の扱い](/guides/incidents/documents-taken-just-before-resignation): 旅行事業の営業担当だった元従業員が、退職直前に宿泊施設の担当者と社内の従業員の個人情報を含む社内資料を持ち出しました。判明は退職の 1 年余り後で、会社は退職・異動時の業務情報の取り扱いを見直すとしています。 - [退職者にサーバーのデータを消された事案から分かる、遮断と復旧の備え](/guides/incidents/former-employee-deleted-data): 退職した元社員が退職後に社内ネットワークに不正にアクセスし、サーバーのデータを削除して業務を妨害した容疑で逮捕されました。持ち出しではなく消される型で、遮断と復旧の両方が問われます。 - [退職後に元職員がシステムにログインした事案から分かる、退職日に利用を止める手順](/guides/incidents/former-staff-login-after-leaving): 小学校を退職した臨時的任用講師が、退職後に市の学校教育支援システムへ不正にアクセスしたとして逮捕されました。市の公表文は入った経路を書いておらず、問われるのは退職日に利用を止める手順です。 - [退職日の翌日にアカウントが残っていた事案から分かる、退職手続きとアカウント削除のつなぎ方](/guides/incidents/former-staff-took-files-before-and-after-leaving): 元職員が在職中と退職日の翌日に、個人情報を含むファイルを USB メモリで持ち出しました。市は原因の一つに、退職翌日もアカウントの削除処理が行われていなかったことを挙げています。 - [再々委託先の作業者が仕入先の個人情報をダウンロードした事案から分かる、多層の委託とアクセス権限](/guides/incidents/fourth-tier-contractor-downloaded-data): 委託先・再委託先の先にいる再々委託先の作業者が、仕入先担当者の個人情報約 2.2 万件を私用目的でダウンロードしました。委託の階層が深くなるほど、委託元から作業者が見えにくくなります。誰にどの範囲の権限を与えているかが問われた事案です。 - [公式 SNS が乗っ取られた 9 件の公表文から分かること](/guides/incidents/official-sns-takeovers-from-notices): 公表文 9 件のうち、原因を書いたのは 1 件です。多くは「調査中」「再発防止に努める」にとどまります。乗っ取り後に起きたことと、公表文が挙げた対策を表にします。 - [公式 Instagram が運営元を装ったメールで乗っ取られ、削除された事案](/guides/incidents/phishing-took-over-official-sns): 公式 Instagram が、運営元を装ったメールへの対応をきっかけに乗っ取られ、管理情報を無効化されたうえ削除されました。公表文で乗っ取りの原因を書いた例です。 - [管理者パスワードの使い回しでランサムウェアの被害が院内に広がった事案](/guides/incidents/reused-admin-password-ransomware): 保守用の外部接続機器と院内すべてのパソコンで、同じ推測しやすい ID とパスワードが使われ、全利用者に管理者権限がありました。調査報告書は、原因の多くは国のガイドラインを守っていれば防げたとしています。 - [パスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案](/guides/incidents/reused-password-list-attack): 他のサービスから漏れた ID とパスワードの組を試す攻撃で、二段階認証をオフにしていた ID だけが不正ログインされました。国内 12 件、海外を含め 156 件です。 - [退職後に社外の Web サービスへ不正アクセスされた事案から分かる、外部サービスのアカウントの止め方](/guides/incidents/saas-account-alive-after-resignation): 元従業員が退職後に、会社が利用する名刺管理システムに不正にアクセスし、名刺情報を漏えいさせました。問われるのは、会社が使うシステムのアカウントを退職時に止める手順です。社外の Web サービスなら、社内の手続きだけでは止まりません。 - [委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案](/guides/incidents/shared-password-with-supplier): 給食の委託先の機器から侵入され、病院のサーバーと端末で共通だったパスワードで被害が広がりました。報告書が原因に挙げたのは、共通パスワード、全員への管理者権限、外部接続の役割分担の曖昧さです。 - [共有ツールの ID とパスワードが盗まれて侵入された事案から分かる、ID の発行と管理、多要素認証](/guides/incidents/shared-tool-ids-used-for-intrusion): 正規の ID とパスワードが盗まれ、正常なログインに見える形で顧客から預かった情報が窃取されました。影響は 142 の顧客に及び、検証委員会は情報保護の体制と利用組織ごとの管理の不備を指摘しました。 - [無断の再委託先が個人データを持ち出した事案から分かる、再委託と辞めた人が知っているパスワード](/guides/incidents/undisclosed-subcontractor-copied-data): 全市民約 46 万人の個人データを入れた USB メモリーを、市に無断の再々委託先の従業員が持ち出して紛失しました。調査報告書は、無断の再委託と、案件を離れた人や転職した人もパスワードを知ったままだった状態を、問題として明記しています。 - [個人情報保護委員会の指導事例に出てくる、推測されやすいパスワードと委託先のアカウント](/guides/incidents/weak-and-default-passwords-in-guidance): 令和 6 年度第 1 四半期の指導 110 件の概要には、事業名を使った簡単なパスワード、4 桁の管理者パスワード、初期設定のままの ID が原因とされた事案が並びます。委託先の監督の不備も 8 件ありました。 - [漏えい等とは(個人情報保護法の報告義務)](/guides/incidents/what-is-data-breach): 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条は、規則で定める 4 つの事態が起きたとき、個人情報保護委員会への報告と本人への通知を義務づけます。 - [内部不正とは](/guides/incidents/what-is-insider-threat): 内部不正とは、役員・従業員・派遣社員などの内部者による、情報の窃取・持ち出し・漏えい・消去・破壊です。IPA のガイドラインは、違法とまでいえない規程違反も含め、退職後に在職中の情報を漏らす行為も内部不正として扱います。 - [不正アクセスとは(不正アクセス禁止法)](/guides/incidents/what-is-unauthorized-access): 不正アクセスとは、不正アクセス禁止法 2 条 4 項が定める行為で、中心は、他人の ID とパスワード(識別符号)をネットワーク経由で入力し、制限されている利用ができる状態にすることです。3 条が禁じ、11 条に罰則があります。 ## よくある質問 **事故の原因はどこで読めますか** 当事者のお詫び文や調査報告書、個人情報保護委員会の四半期ごとの公表、警察庁の年次資料で読めます。報道だけが伝える原因は、当事者が公表した原因と分けて読みます。 **退職者が元の ID で入るのは不正アクセスですか** 警察庁は、ID・パスワードを知り得る立場にあった元従業員による不正アクセス行為が起きているとして、利用する立場でなくなった人の ID の削除かパスワードの変更を求めています。 **委託先の担当者が起こした漏えいは委託元の責任ですか** 個人情報保護委員会の指導事案では、委託先の取扱状況を把握していなかった委託元に「委託先に対する監督」の不備が認められています。委託先を選び、契約し、把握するところまでが委託元の仕事です。 **点検は何から始めますか** 先月退職した人と契約が終わった委託先の担当者が使えた ID を全部挙げ、止まっているかを確かめるところからです。挙げられない ID があれば、そこが最初の点検先です。 ## 参考資料 - [国家公安委員会・総務大臣・経済産業大臣「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」(令和 7 年 3 月 13 日。令和 6 年分)](https://www.npa.go.jp/bureau/cyber/pdf/R070313_access.pdf) - [国家公安委員会・総務大臣・経済産業大臣「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」(令和 6 年 3 月 14 日。令和 5 年分)](https://www.npa.go.jp/news/release/2024/20240314.pdf) - [個人情報保護委員会「令和 6 年度第 1 四半期における監視・監督権限の行使状況の概要」(令和 6 年 8 月 28 日)](https://www.ppc.go.jp/files/pdf/240828quarter-report_kengenkoushi.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 4 つの型に共通するのは、パスワードを人が知っていることと、辞めた人のアカウントが生きていることです。Junify が預かるアカウントでは、どちらも起きません。パスワードは管理者が登録し、担当者は自分のスマホで本人確認をしてから、見ないまま使います。担当を外れた人は、割り当てを外すだけでその場で入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) --- # 退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 更新日: 2026-09-18 持ち出しが起きたのは退職後ではなく、退職を申し出てから退職するまでの期間でした。ある通信事業者は 2021 年 1 月 12 日、2019 年末に退職した元社員が不正競争防止法違反の容疑で警視庁に逮捕されたと公表しました。在職中の社員による情報の持ち出しは、IPA のガイドラインでは[内部不正](/guides/incidents/what-is-insider-threat)に当たります。この事案では「退職予定者」という期間が問われています。 ## 何が起きたか 公表文によると、元社員は会社と秘密保持契約を結んでいました。それにもかかわらず、退職申告から退職するまでの期間に、会社の営業秘密に当たるネットワーク技術に関わる情報を不正に持ち出していました。会社がそれを把握したのは 2020 年 2 月で、その後に警視庁へ相談し、被害を申告して捜査に協力しました。 元社員は在籍中、ネットワークの構築に関わる業務に就いていました。持ち出された情報は、4G と 5G のネットワーク用の基地局設備と、基地局どうしや基地局と交換機を結ぶ固定通信網に関する技術情報です。 ## 公表された原因と再発防止策 公表文に原因の節はありません。書かれているのは、秘密保持契約を結んでいたにもかかわらず持ち出した、という事実です。どの経路で持ち出したか、退職申告の後に権限がどう扱われていたかは書かれていません。 再発防止策として、会社は 2020 年 3 月以降に次の 4 つを実施したと公表しています。 1. 情報資産管理の再強化。管理ポリシーの厳格化と、棚卸しとアクセス権限(誰がどこまで使えるかの設定)の再度の見直し。 2. 退職予定者に対する、業務用の情報端末によるアクセス権限の停止や利用の制限の強化。 3. 全役員と全社員向けのセキュリティー研修。未受講者は重要情報資産へアクセス不可。 4. 業務用 OA 端末の利用ログ全般を監視するシステムの導入。 2 つ目の項目は、退職の申し出から退職日までの期間を、権限を扱う対象として明示したものです。退職日に止める運用だけでは、この期間は在職中と同じ権限のまま残ります。 ## 同じ型の事故で一般に問われる管理 退職前の持ち出しで問われるのは、退職の申し出を受けてから退職日までの扱いです。IPA の「組織における内部不正防止ガイドライン」第 5 版は、雇用終了時の対策の中で「雇用終了間際に情報の持ち出し等の内部不正が発生しやすい」と書いています。そのため、雇用終了前の一定期間から端末をシステム管理部門などの管理下に置くことが望まれる、としています。例に挙がっているのは、アクセス範囲の限定、USB メモリの利用制限、モニタリング(記録を見張ること)の強化です。ガイドラインの付録の対策一覧も、「退職にともなう情報漏えい」への対策の最初に「退職前の監視強化」を置いています。 秘密保持契約の役割も、この事案から読み取れます。ガイドラインは、雇用終了時に秘密保持契約を結ばない場合の影響を 2 つ挙げています。役職員が重要情報の認識がないまま退職し、知り得た重要情報を公開する可能性が高まること。公開を防ぐための差止請求や、公開に対する損害賠償の請求が認められない可能性が高まることです。つまり IPA は契約の効果を、退職者に対象を認識させることと、事後の差止・損害賠償の根拠になることの 2 つで説明しています。契約だけでは持ち出しは止まらず、権限と記録の管理は別に要ります。 同じ項目は、退職予定者との面談で在職中にアクセスした秘密情報を確かめ、それを秘密保持義務の対象に含めることを対策に挙げています。面談の内容は客観的な形で記録します。退職予定者が何にアクセスしていたかを本人と確かめる場は、持ち出しの抑止と、事後の証明の両方に使えます。 ## 自分の現場を点検する問い - 退職の申し出を受けた日から退職日までの間、その人の権限は何か変わるか。変わらないなら、誰がその判断をしているか。 - 退職予定者が業務で使う情報の範囲を、必要なものだけに絞れる仕組みがあるか。 - 端末からの持ち出し(USB メモリ、個人のメール、クラウドへのアップロード)に気づける記録があるか。誰がそれを見るか。 - 秘密保持の誓約は、入社時と退職時のどちらで取っているか。退職時に拒まれたときの備えはあるか。 - 退職予定者との面談で、在職中にアクセスした情報を確かめ、記録を残しているか。 ## よくある質問 **秘密保持契約を結んでいれば持ち出しは防げますか** この事案では契約を結んでいても持ち出しが起きました。IPA のガイドラインは契約の効果を、退職者に対象を認識させることと、事後の差止・損害賠償の請求の根拠になることの 2 つで説明しています。 **退職の申し出があったら権限を変えてよいですか** IPA のガイドラインは、雇用終了間際に内部不正が起きやすいことから、雇用終了前の一定期間、端末をシステム管理部門の管理下に置くことを望ましいとし、アクセス範囲の限定や USB メモリの利用制限を例に挙げています。 **退職予定者との面談で何を確かめますか** IPA のガイドラインは、退職予定者との面談で在職中にアクセスした秘密情報を確かめ、秘密保持義務の対象に含め、面談の内容を客観的な形で記録することを対策に挙げています。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify では、退職の申し出を受けた時点で、管理者がその人の割り当てを一つずつ外し、残す範囲を絞れます。その後に使ったアカウントは、共有アカウントでも誰がいつ使ったかが一人ひとり記録に残ります。端末の中のファイルの持ち出しは、Junify の範囲の外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 - [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](/guides/incidents/contractor-sent-data-outside): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 --- # 代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 更新日: 2026-09-18 公式 SNS の運営を外部の代行会社に任せている場合、乗っ取られるのは代行会社が持つアカウントです。自動車用品の小売会社の公表文は、代行会社の Google アカウントへの不正アクセスをきっかけに、公式 X と YouTube の両方で第三者の操作が行われたと書いています。 ## 何が起きたか 同社は 2024 年 3 月 1 日に、自社が主催する大会の公式 X と公式 YouTube のアカウントが乗っ取られたと公表しました。公表文によると、運営を任せていた代行会社が使用・管理する Google アカウントが何者かに不正アクセスを受けました。不正アクセスとは、他人の ID とパスワードを入力して、そのアカウントに入る行為です(定義は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access))。 X では、大会や同社とは無関係な投稿とリポストが行われました。2024 年 2 月 25 日以降のリポストなどを含むアカウントの操作は、第三者によるものだとしています。YouTube では、アカウント名、プロフィール写真、チャンネルのバナーが変更され、公式動画の一部が非公開または削除されました。 同社は、警察への相談、個人情報などの漏えいの可能性を含む被害状況の確認、原因の調査、アカウントの凍結と復旧を進めるとしています。あわせて、同社を装った DM(ダイレクトメッセージ)が届いても、リンクを開いたり返信したりしないよう呼びかけました。 ## 公表された原因 公表文の時点で、原因は調査中です。Google アカウントへの不正アクセスがどのように行われたか、また Google アカウントと X のアカウントがどうつながっていたかは書かれていません。 ## 公表された再発防止策 公表文は、外部の専門機関の協力を得て原因究明を進めることと、「今まで以上に厳重な情報セキュリティ体制の構築と強化徹底」を挙げています。アカウントの管理方法の具体策は書かれていません。 ## 同じ型の事故で一般に問われる管理 代行会社が持つ 1 つのアカウントから複数の公式 SNS に影響が及ぶ型で問われるのは、まず、1 つのアカウントに何がつながっているかです。YouTube のチャンネルは Google アカウントで管理されるため、その Google アカウントに入れる人は、チャンネル名や動画を変えられます。YouTube のヘルプは、チャンネルの権限機能で複数の人に 7 種類の権限(所有者、管理者、編集者、閲覧者など)を付けられると説明しています。パスワードなどのログイン情報を共有するより安全だ、ともしています。招待は YouTube Studio の「設定」から「権限」でメールアドレスを入力して行い、外すときは同じ画面で「アクセス権を削除」を選びます。 次に、その Google アカウント自体のログインです。Google のヘルプは、2 段階認証プロセスを、パスワードが盗まれた場合に備えてアカウントを守る機能と説明しています。使える方法は Google からのメッセージ、パスキー、認証アプリ、バックアップコードなどです。代行会社が持つアカウントでは、どの方法を使い、コードを受け取る端末を誰が持つかを、委託元が把握しているかが問われます。 X については、アカウントのパスワードを渡さずに投稿や DM を任せる「権限の付与(委任)」の仕組みがあります。役割ごとにできることと外し方は[X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](/guides/agency-accounts/x-tiktok-business-account-access)で扱っています。 委託元の立場では、個人情報保護法 25 条の委託先の監督が関わります。個人情報保護委員会のガイドライン(通則編)3-4-4 は、個人データの取扱いを委託する場合について書いています。委託元が自分でやるべき対策と同じ水準の対策を、委託先にもさせるよう監督する、としています。委託先の取扱状況を定期的な監査などで把握することが望ましい、ともしています。公式 SNS の DM で顧客の個人情報を受け取る運用であれば、その運営の委託はこの条文の対象に当たると読めます。 ## パスワードを渡さずに代行会社へ任せる形 上に挙げた管理は、いずれも代行会社がパスワードを持つことを前提に、その持ち方を良くするものです。委託元が把握できるのは、代行会社が申告した範囲に限られます。誰が実際にそのパスワードを知っているかは、委託元からは見えません。 別の形として、委託元がパスワードを持ったまま、代行会社の担当者に使わせる方法があります。ログインの入り口を 1 つに決め、ID とパスワードの入力を担当者ではなく仕組みに任せます。担当者は使ってよいアカウントを選んで作業し、パスワードそのものは見ません。この形なら、契約が終わったときに変えるのは使わせる相手の設定だけで、パスワードを変えて配り直す作業は要らなくなります。 ## 自分の現場を点検する問い 1. 代行会社が公式アカウントをどのアカウント(Google、メール、媒体のログイン)で管理しているか、一覧があるか。 2. その 1 つのアカウントが乗っ取られたとき、影響が及ぶ範囲(動画、広告、メール、ほかの SNS)を把握しているか。 3. 2 段階認証と権限付与を使っているか。パスワードを知っている人は代行会社の誰か。 4. 乗っ取りに最初に気づくのは誰で、委託元への連絡経路は決まっているか。 5. 復旧の操作ができる「所有者」は代行会社にあるか、自社にあるか。 ## よくある質問 **代行会社に任せている公式 SNS が乗っ取られたら、誰が公表しますか** この事案では、アカウントの名義である委託元の会社が公表と注意喚起を行いました。公表・顧客対応・復旧のどこまでを代行会社が担うかは、契約で決めておく事柄です。 **Google アカウントの乗っ取りは、どこまで影響しますか** YouTube のチャンネルは Google アカウントで管理されます。同じアカウントでほかのサービスにもログインしていれば、影響はその範囲に及びえます。1 つのアカウントに何がつながっているかの一覧が要ります。 **委託先のアカウント管理は、何を確認すればよいですか** 確認する項目の一例です。公式アカウントを管理するアカウントの一覧、2 段階認証の有無、担当者の範囲、権限付与を使っているか、担当交代時の手順を書面で確かめます。 ## 参考資料 - [YouTube ヘルプ「チャンネルの権限を管理する」](https://support.google.com/youtube/answer/9481328?hl=ja) - [Google アカウント ヘルプ「2 段階認証プロセスでアカウントを保護する」](https://support.google.com/accounts/answer/185839?hl=ja) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、代行会社の担当者からパスワードが漏れる経路は成立しません。委託元の管理者が登録した ID とパスワードは担当者に渡らず、担当者はカードをクリックして使うだけです。契約が終われば、割り当てを外すだけでその場で入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 - [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](/guides/incidents/contractor-sent-data-outside): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 --- # 委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 更新日: 2026-09-18 ある情報サービス会社が 2023 年 11 月に公表した事案は、委託先の従業者のパソコンの感染が入口でした。そこから、関係会社と共通のログインの仕組みを通じて社内システムへ侵入されました。監督官庁への報告書の概要によると、社内システムへの不正アクセスは 2023 年 9 月 14 日に始まっていました。 ## 何が起きたか この会社は 2023 年 11 月 27 日、第三者による[不正アクセス](/guides/incidents/what-is-unauthorized-access)を受けたと公表しました。不正アクセスとは、権限のない人が、他人の ID などを使ってシステムに入ることです。漏えいしたのは、ユーザー・取引先・従業者等の情報です。契機は、ある委託先の従業者のパソコンがマルウェア(悪意のあるプログラム)に感染したことでした。この委託先は、海外の関係会社の委託先であり、公表した会社の委託先でもありました。経営統合前の一方の会社の社内システムは、共通の認証基盤(誰がログインできるかを確かめる仕組み)で管理されていました。海外の関係会社と自社の従業者情報を扱う、両社共通のものです。そこへのネットワーク接続を許可していたため、関係会社のシステムを介して不正アクセスが行われました。公表文はこれを 10 月 9 日とし、報告書の概要は社内システムへの不正アクセスの開始を 9 月 14 日としています。 10 月 17 日に不審なアクセスを検知しました。10 月 27 日に外部からの不正の可能性が高いと判明し、従業者のパスワードをリセットしました。漏えいした情報は 3 種類です。ユーザー情報 302,569 件(うち日本のユーザー 129,894 件)、取引先情報 86,105 件、従業者等の情報 51,353 件です。 ## 公表された原因 公表文が原因として述べているのは、経営統合前の一方の会社の社内システムへのネットワーク接続を許可していたことです。感染したパソコンを入口に、共通の認証基盤で管理されたそのシステムへ到達されました。2024 年 4 月 1 日に公表した監督官庁への報告書の概要には、次の点が記されています。共通化されていた認証基盤は従業者のアカウントに関する 3 つのシステムで、その管理は海外の関係会社が担っていたこと。社内のアカウントを管理するサーバーの管理者権限を持つアカウントを奪取されたことです。監督官庁の指導事項の引用として、委託先の監督が委託先の分析結果や記録に頼っていたことも挙げられています。 ## 公表された再発防止策 公表文は 3 つを挙げています。共通化している認証基盤の環境の分離、ネットワークアクセス管理の強化、委託先の安全管理措置の是正です。報告書の概要には、より具体的な対応があります。関係会社側の環境から自社環境への通信は、必要なもの以外を拒否する設定に変えました。従業者が使うサーバーやシステムに二要素認証(パスワードに加えてもう一つの方法でログインを確かめる仕組み)を適用しました。委託先の管理では 3 点を挙げています。委託先が自社発行のアカウントで自社のネットワークに入る場合は、原則として二要素認証を経た場合にのみ許可すること。委託先には自社が設定したパソコンでのみ委託業務を認めること。個人情報の委託に限らず使える委託先チェックシートを新設することです。 ## 同じ型の事故で一般に問われる管理 この事案では、関係会社であり委託先でもある会社と、従業者の認証基盤とネットワークを共有していました。委託先や関係会社のシステムに自社への広い接続を許していれば、そこで起きた侵入が自社まで届く経路になります。 個人情報保護委員会のガイドライン(通則編)の別添は、技術的安全管理措置として、情報システムを使う従業者の認証を求めています。個人データを扱う情報システムの利用者が、正当なアクセス権を持つ人であることを識別して確かめなければならない、とします。情報システムを外部からの不正アクセスや不正なソフトウェアから守る仕組みの導入と運用も、求めています。3-4-4 は、委託先を選ぶ際に、別添の各項目が委託する業務に沿って実施されることを、あらかじめ確認するよう求めています。委託先のパソコンや仕組みの安全管理措置は、委託元が確認する対象に含まれます。 IPA「組織における内部不正防止ガイドライン」第 5 版の 4-2「資産管理」は、委託先の従業員等への権限の与え方を述べています。重要情報へのアクセス権限を与える場合は、契約上の措置が必要だとしています。契約上の措置の内容は (17)「業務委託時の確認」(対策の事前確認と合意、契約どおりの実施の定期・不定期の確認)にあります。(7)「利用者の識別と認証」(遠隔で保守を行う管理者には複数の方法で確かめる認証を検討する)も当てはまります。 ## 自分の現場を点検する問い - 委託先の担当者は、自社の従業員と同じ ID の仕組み・同じネットワークで自社のシステムに入っているか。別の経路に分けられるか - 委託先の担当者に発行した自社のアカウントに、二要素認証を求めているか - 委託先の担当者が使うパソコンは、誰が用意し、誰が設定を管理しているか - 委託先の側で侵入が起きたとき、自社のどこまで到達できるかを把握しているか - 侵入の有無や範囲を、委託先からの報告に頼らず自社の記録で調べられるか ## よくある質問 **委託先と同じログインの仕組みを使うと何が起きますか** 委託先のパソコンや仕組みが侵入されると、その先にある自社のシステムまで同じ経路で到達され得ます。この事案では、共通の仕組みで管理された社内システムへの接続を許していたことが原因として公表されました。 **二要素認証があれば防げましたか** 監督官庁への報告書の概要は、二要素認証(パスワードに加えてもう一つの方法でログインを確かめる仕組み)が入っていたサーバーやシステムは被害を免れたと述べています。すべてに当てはまるとは書かれていません。 **委託先に自社のアカウントを渡すときに決めることは** この事案の再発防止策は 2 つを挙げています。委託先が自社発行のアカウントで自社ネットワークに入る場合は原則二要素認証を経ること、自社が設定したパソコンでのみ作業を認めることです。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、委託先のパソコンが感染しても、その端末に委託元のアカウントのパスワードはありません。担当者は自分のスマホで本人確認をしてから開き、パスワードを受け取らないからです。委託先の担当者が委託元のアカウントに入る経路は Junify だけになり、担当が終われば割り当てを外します。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](/guides/incidents/contractor-sent-data-outside): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 --- # 委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。 更新日: 2026-09-18 ある通信事業者が 2023 年に公表した事案では、委託先の元派遣社員が業務用のパソコンから顧客情報を外部に持ち出しました。持ち出しを見つけたのは委託先ではなく、委託元である通信事業者のネットワーク監視でした。 ## 何が起きたか この通信事業者は 2023 年 3 月 31 日、個人向けのインターネット接続サービスと映像配信サービスの顧客情報が流出した可能性を公表しました。前日の 3 月 30 日、自社のネットワーク監視が、業務では行うことのない外部への通信を検知しました。通信事業者は直ちにそのパソコンをネットワークから隔離しています。初報の時点で対象は最大約 529 万件とされていました。 7 月 21 日の続報で、経緯が明らかにされました。持ち出したのは、この 2 つのサービスの販売支援業務を受託していた委託先の元派遣社員です。業務に使用していたパソコンから、個人として契約する外部ストレージ(インターネット上の保存場所)へアクセスしていました。そこへ顧客情報を含む業務情報を持ち出していたものです。対象は約 596 万件で、内訳は接続サービス 165 万件、映像配信サービス 431 万件です。流出した項目は、接続サービスでは氏名・住所・電話番号・回線の ID・お客さま番号の一部です。映像配信サービスでは、これにメールアドレスと生年月日が加わります。クレジットカードや口座の情報、パスワードは含まれていません。委託先は、第三者によるアクセスや不正利用は確認されていないとしています。 これは委託先での[内部不正](/guides/incidents/what-is-insider-threat)の事案です。 ## 公表された原因 委託先の公表文に、原因の項目はありません。経緯として、元派遣社員が業務用のパソコンから個人契約の外部ストレージへアクセスして持ち出した、と書いています。動機や、なぜその通信が可能だったかについては、両社の公表文に記述がありません。委託元の公表文にも、委託先の設定や管理の不備を特定した記述はありません。 ## 公表された再発防止策 委託元は、顧客情報を取り扱う全業務について再点検を行いました。同様の環境で業務を行っていたものは是正を完了したとしています。委託先は、全業務のネットワーク環境の緊急点検、セキュリティの強化、従業員への情報セキュリティ研修の充実を挙げています。 ## 同じ型の事故で一般に問われる管理 この事案で目を引くのは、検知が委託先ではなく委託元の側で起きたことです。委託先の担当者が業務用パソコンで何をしているかは、通常、委託元からは見えません。委託元が見られるのは、自社のネットワークや自社のシステムに残る記録だけです。その記録を委託元が持ち、日常的に見る運用があれば、委託先からの報告を待たずに気づける場合があります。 個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託先の監督の一つに「委託先における個人データ取扱状況の把握」を挙げています。委託契約には、委託先での取扱状況を委託元が合理的に把握できることを盛り込むことが望ましい、としています。ガイドラインの別添は、技術的安全管理措置(システムの面での対策)として、情報システムの使用に伴う漏えいを防止する措置を求めています。不正アクセスの防止の手法の例には「ログ等の定期的な分析により、不正アクセス等を検知する」を挙げています。 IPA「組織における内部不正防止ガイドライン」第 5 版の (17)「業務委託時の確認」は、委託先との記録の扱いを述べています。内部不正によって委託元に大きな影響が及ぶ、またはそのおそれが十分にある場合の決まりです。記録が提供されることを事前に確認し、契約上も明確にすることが望ましい、とします。契約書に記録の提供を書いていないと、内部不正が起きた後の調査が難しくなる、という理由です。(18)「情報システムにおけるログ・証跡の記録と保存」(アクセスや操作の履歴、内部から外部への通信の履歴の記録)も同じ型に当てはまります。 ## 自分の現場を点検する問い - 委託先の担当者が自社のシステムやアカウントを使ったとき、その記録は自社の手元に残るか。それとも委託先の報告に頼るか - 業務では起きないはずの通信や操作を、誰が、どの記録で、どれくらいの頻度で見ているか - 委託契約に、事故のときに委託先から記録の提供を受けられることが書いてあるか - 委託先の業務用パソコンから、個人契約のクラウドや外部ストレージへ送れる状態になっていないか - 見つけた後の手順(当該端末の隔離、委託先への連絡、本人への通知)が決まっているか ## よくある質問 **委託先の持ち出しを委託元が見つけることはできますか** この事案では、委託元のネットワーク監視が、業務では起きない外部への通信を当日に検知しました。委託元が自分の記録と監視を持っていれば、委託先からの報告を待たずに気づける場合があります。 **委託先の記録を委託元がもらえるように契約で決めるべきですか** IPA のガイドラインは、内部不正で委託元に大きな影響が及ぶおそれがある場合、記録が提供されることを事前に確認し、契約上も明確にすることが望ましい、とします。契約に書いていないと事後の調査が難しくなります。 **業務用パソコンから個人のクラウドへ送れる状態は問題ですか** この事案の持ち出し経路がそれでした。個人情報保護委員会のガイドラインは、情報システムの使用に伴う漏えいを防ぐ措置を求めています。記録の定期的な分析による検知も、手法の例に挙げています。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify では、委託先の担当者が使う委託元の Web アカウントについて、ファイルのダウンロードをアカウントごとに禁止できます。担当者はパスワードを受け取らず、誰が・いつ・どれを使ったかは委託元の手元に本人単位で残ります。不審な動きを見つけたとき、誰の操作かをその記録からたどれます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 委託先の保守担当者が管理者アカウントを共用していた事案から分かる、管理者権限と記録 コールセンターの仕組みを保守する委託先の元派遣社員が、約 10 年間、管理者用のアカウントで顧客情報を持ち出しました。共用の管理者アカウント、持ち出しを止める設定の不在、記録を点検する運用の不在が原因として公表されています。 更新日: 2026-09-18 通信事業者のグループが 2023 年 10 月に公表した事案では、委託先の元派遣社員が顧客情報を持ち出していました。期間は約 10 年に及びます。持ち出しに使われたのは、委託先の保守担当者が共用していた管理者用のアカウントです。記録は残っていましたが、点検する人が決まっていませんでした。 ## 何が起きたか この通信事業者は 2023 年 10 月 17 日、顧客情報の流出を公表しました。起きたのは子会社と、その委託先です。子会社はコールセンター業務の運営会社で、多数の民間企業と自治体から業務を受託していました。その委託先は、コールセンターの仕組みを提供し保守する会社です。持ち出したのは、委託先で運用保守業務に従事していた元派遣社員でした。子会社が預かっていた顧客情報を持ち出し、第三者に流出させていました。 グループが 2024 年 2 月 29 日に公表した資料によると、持ち出しは 2013 年 7 月頃から 2023 年 2 月頃まで続きました。対象は子会社の 69 のクライアントの顧客 928 万件です。元派遣社員はシステム管理者アカウントを悪用し、業務端末からサーバーに入って顧客情報を取り出していました。2024 年 1 月 24 日、個人情報保護委員会が子会社と委託先に勧告と指導を行いました。2 月 9 日には総務省が親会社に対し、委託先の適切な監督について指導しています。 これは[内部不正](/guides/incidents/what-is-insider-threat)による[漏えい](/guides/incidents/what-is-data-breach)の事案です。 ## 公表された原因 社内調査委員会は、2024 年 2 月 19 日の調査報告書で直接の原因を述べています。委託先の技術的な管理の不備が 5 点です。 1. ダウンロードを制御する措置がない。管理者アカウントで全クライアントの顧客データを取り出せ、事前承認も異常の検知もなかった。 2. 私有 USB メモリーへの書き出しを防ぐ措置がない。保守用の端末から私物の記録媒体に書き出せた。 3. インターネット接続を制限する措置がない。保守用の端末からウェブメールで外部に送れた。 4. 記録(ログ)の監視がない。記録は残っていたが点検する人がなく、アカウントの共用で使用者も特定できなかった。 5. 私有端末によるアクセスを制限する措置がない。私物のパソコンからでも接続できた。 報告書は業務運営の問題も挙げています。元派遣社員は保守の対象に最も詳しく、作業の大半が単独で、直属の上長は別の拠点にいました。 委託元である子会社についても、報告書は原因を述べています。子会社には委託先を管理するための規程がありました。しかし契約条項の一部を除いて守られていませんでした。個人情報の取扱いに関する限り「委託先管理は実態として何もしていないに等しい状況」だった、と報告書は書いています。直接の原因は、担当者に、個人情報の取扱いを委託しているという認識がなかったことです。そのうえで報告書は、規律はあっても委託先を監督する実務の手順がなく、規律が実務に落ちていなかったことを最大の原因としています。 ## 公表された再発防止策 グループは 2024 年 2 月 29 日、再発防止策を 4 つの柱で公表しました。「リスクの視える化」「リスク箇所の最小化」「監視の高度化・点検の徹底」「情報セキュリティ推進体制の強化」です。約 100 億円規模の予算と約 100 名規模の推進組織を充てるとしています。 リスク箇所の最小化では、「アカウント」や「権限」を集中的に管理するとしています。データの抽出・持ち出しやシステムへのアクセスを一括で制御できる環境に、順次統合する計画です。監視の高度化では、各種の記録を監視センターに集めます。特権(強い権限)を持つ利用者や保守者による顧客情報の取り出しと持ち出しの監視を強める、としています。 緊急総点検の結果も公表されています。顧客情報などを保有する 443 のシステムのうち、アカウントの共用で個人を特定できないものが 19% ありました。記録の点検ができていないものは 29% です。会社が許可していない記録媒体や端末を接続できたシステムは 16% です。これには暫定の対処として、設定による接続の禁止と、USB メモリーに代わる手段の導入を挙げています。 ## 同じ型の事故で一般に問われる管理 個人情報保護法 25 条は、個人データの取扱いを委託する事業者に、委託先への「必要かつ適切な監督」を求めています。個人情報保護委員会のガイドライン(通則編)3-4-4 は、監督を行っていない事例を挙げています。委託先の安全管理措置(個人データを守る対策)の状況を契約時にもその後も把握せず、委託先が漏えいした場合です。ガイドラインの別添は、組織的安全管理措置の一つとして、利用状況などの記録を挙げています。規律に従った運用になっているかを確認するためです。 IPA「組織における内部不正防止ガイドライン」第 5 版には、管理者の権限と記録に関係する対策が 3 つあります。(6)「システム管理者の権限管理」は、管理者が複数いる場合の決まりです。管理者の ID ごとに適切な権限の範囲を割り当て、互いに監視できるようにしなければならない、とします。特権を使った操作は記録に残し、特権が要らない操作では特権を使わない、という運用も挙げています。残る 2 つは、(7)「利用者の識別と認証」と (19)「システム管理者のログ・証跡の確認」です。前者は共有 ID や共有のパスワードを使わないこと、後者は管理者の操作の記録を管理者以外が定期的に確認することを求めています。 ## 自分の現場を点検する問い - 委託先の作業者が使う管理者用のアカウントは、一人に一つずつか。共用なら、記録から使用者を特定できるか - 顧客情報を一括で取り出せる権限を、誰が、どの業務のために持っているか。取り出しに承認は要るか - 記録を「誰が」「いつ」「何を見て」点検するかが決まっているか - 委託先に個人データの取扱いを任せているという認識が、契約の担当者にあるか。委託先を確認する手順が動いているか - 特定の作業者に長く依存し、上長がその作業内容を把握できていない持ち場はないか ## よくある質問 **委託先の内部不正は委託元の責任になりますか** 個人情報保護法 25 条は、委託元に委託先への「必要かつ適切な監督」を求めています。ガイドラインは、委託先の安全管理措置の状況を把握せずに漏えいした場合を、監督を行っていない事例に挙げています。 **記録が残っていれば持ち出しは見つかりますか** 記録があるだけでは見つかりません。この事案では記録は残っていましたが、点検する運用と担当者がなく、管理者アカウントが共用で使用者を特定できませんでした。誰が・いつ見るかまで決めて初めて役立ちます。 **管理者アカウントを一人ずつにすれば足りますか** 一人ずつにすると使用者は特定できますが、持ち出しは止まりません。IPA のガイドラインは、管理者の ID ごとに権限の範囲を割り当てて互いに監視し、操作記録を管理者以外が定期的に確認することも求めています。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、この経路は成立しません。共用の管理者アカウントでも、担当者はパスワードを受け取らないからです。自分のスマホで本人確認をしてから開くので、誰が・いつ・どれを使ったかが一人ひとり残ります。同じパスワードを複数人が知っていて使用者を特定できない状態は、そもそも起きません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 退職の直前に顧客情報を持ち出された事案から分かる、退職時の業務情報の扱い 旅行事業の営業担当だった元従業員が、退職直前に宿泊施設の担当者と社内の従業員の個人情報を含む社内資料を持ち出しました。判明は退職の 1 年余り後で、会社は退職・異動時の業務情報の取り扱いを見直すとしています。 更新日: 2026-09-18 退職の 1 年余り後に、元従業員による持ち出しが分かった事案です。ある人材サービス会社は 2025 年 8 月 1 日、2024 年 3 月末に退職した元従業員が、顧客の担当者と自社の従業員の個人情報を含む社内資料を在職中に社外へ持ち出していた、と公表しました。在職中の従業員が退職の直前に情報を持ち出す行為は、IPA のガイドラインが[内部不正](/guides/incidents/what-is-insider-threat)として挙げるものです。会社は、再発防止策に「退職や異動に伴う業務情報の取り扱いプロセス」の見直しを挙げています。 ## 何が起きたか 公表文によると、旅行事業の営業担当だった元従業員は、就業規則などに違反し、退職直前の 2024 年 3 月に社内資料を社外へ持ち出していました。会社がそれを知ったのは 2025 年 4 月に情報提供を受けたときで、2025 年 6 月の社内調査で事実を確かめました。退職から判明まで 1 年余りが経っています。 持ち出された資料に含まれていた情報は次のとおりです。 | 対象 | 内容 | | --- | --- | | 宿泊施設 255 施設の担当者 481 名 | 氏名、メールアドレス、電話番号、勤務先、役職、部署など | | 同じ担当者の一部 | 営業活動を通じて得た追加の個人情報(内容は人によって異なる) | | 対象の施設を担当する会社の従業員 55 名 | 氏名と所属 | 会社は元従業員に持ち出したファイルの削除を求め、削除されたことを確かめました。対象の施設と担当者には個別に連絡し、通常の方法で連絡がつかない方のために窓口を設けています。公表の時点で、ほかの漏えいは確認されていません。退職後の元従業員による社外での営業活動で本情報が使われたという情報提供が 1 件あったことを除き、二次被害とそのおそれも確認されていない、としています。 ## 公表された原因と再発防止策 公表文に原因の節はなく、元従業員の行為を「就業規則などに違反」した持ち出しと述べています。どの経路で持ち出したかは書かれていません。 再発防止策は 3 つです。退職や異動に伴う社内での業務情報の取り扱いプロセスを見直し、業務情報を社内システムに集約して一元的に閲覧・管理できる運用体制を整えること。従業員への情報の取り扱いに関する教育・啓発を継続すること。情報持ち出しのモニタリング(記録を見張ること)の体制を強化することです。 ## 同じ型の事故で一般に問われる管理 退職直前の持ち出しで問われるのは、退職の手続きの中に「業務情報の返却・消去」が入っていたか、そしてそれを確かめる手段があったかです。IPA の「組織における内部不正防止ガイドライン」第 5 版は、雇用終了時に「取り扱いを委託した情報資産の全てを返却又は完全消去させなければならない」と定めています。あわせて、情報システムの利用者 ID と権限を削除しなければならない、としています。挙げている対策は、誓約書や契約書に返却と完全消去の記載を置くこと、情報資産と入館証などの返却を確かめること、ID と権限の削除を確かめることです。業務情報が社内システムの外(個人の端末やファイル)にもあると、退職時に返却・消去を確かめる対象が広がります。社内システムに集約されていれば、確かめる対象はシステム上の権限に置き換わります。 秘密保持契約については、返還・消去すべき情報を自ら一切保有しないことを確認する条項を設けることを対策に挙げています。退職者が返す対象を認識でき、事後の言い逃れを防げるためです。IPA は、自分が関わって作った情報も会社に属し、秘密保持の対象であることを退職者に伝えることが望ましい、としています。営業担当が集めた顧客の連絡先が会社の情報資産であり、退職時に返す対象だと本人が認識する場を、退職の手続きの中に置くことになります。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、資産管理の項で、役職員の退職や派遣社員などの契約満了後の情報の不正利用を防ぐ対策を挙げています。退職・任期満了時に情報や機器・ID・鍵などを回収し、復元できない方法でデータを消去することです。実行の状況は、チェックリストや記録で見えるようにします。回収したことを記録に残す一段があると、1 年後に持ち出しが分かったとき、退職時に何を確かめたかを示せます。 ## 自分の現場を点検する問い - 営業担当が持つ顧客の連絡先は、どこにあるか。社内システムのほかに、個人の端末、メール、スマホ、紙の名簿に散らばっていないか。 - 退職時に返却・消去を確かめる項目に、「顧客の連絡先」が入っているか。確かめた結果は記録に残っているか。 - 退職の申し出から退職日までの期間に、持ち出しに気づける仕組みがあるか。 - 就業規則と誓約書に、退職後の秘密保持と、情報の返却・消去が書かれているか。退職者がその対象を具体的に知る機会があるか。 - 退職から 1 年後に持ち出しが分かったとき、何を持ち出したかを特定できる記録があるか。 ## よくある質問 **退職時の返却は何を対象にすればよいですか** IPA のガイドラインは、雇用終了時に、取り扱いを委託した情報資産のすべてを返却または完全に消去させ、システムの ID と権限を削除するよう求めています。営業担当が持つ顧客の連絡先は、この情報資産に含まれます。 **退職から 1 年後に持ち出しが分かったら何をしますか** この事案では、会社が元従業員に持ち出したファイルの削除を求めて削除を確かめ、対象の施設と担当者に個別に連絡し、連絡がつかない方向けの窓口を設けました。何を持ち出したかを特定できる記録が前提になります。 **誓約書があれば持ち出しは防げますか** 防ぐ仕組みではありません。IPA のガイドラインは、返還・消去すべき情報を自ら一切保有しないことを確認する条項を秘密保持契約に置き、退職者がその対象を認識できるようにすることを対策に挙げています。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify 経由で使うアカウントは、ファイルのダウンロードをアカウントごとに禁止できます。誰がいつどのアカウントを開いたかは本人単位で残るので、後から持ち出せた範囲を絞れます。判明までに時間がかかった事案でも、この記録があれば範囲の特定を早められます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 退職者にサーバーのデータを消された事案から分かる、遮断と復旧の備え 退職した元社員が退職後に社内ネットワークに不正にアクセスし、サーバーのデータを削除して業務を妨害した容疑で逮捕されました。持ち出しではなく消される型で、遮断と復旧の両方が問われます。 更新日: 2026-09-18 ある計測機器メーカーの元社員が、退職後に社内ネットワークなどに不正にアクセスし、サーバーのデータを削除して業務を妨害した容疑で逮捕されました。この会社は 2023 年 1 月 25 日、これを公表しています。情報が外に持ち出される型ではなく、情報が消される型の事案です。 ## 何が起きたか 公表文によると、元社員は退職後の 2022 年 6 月に、社内ネットワークなどに不正にアクセスしました。サーバーに保管されていたデータを削除して会社の業務を妨害した容疑で、逮捕されています。不正アクセスの法律上の定義は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access)にまとめています。逮捕の公表は、削除から約 7 か月後でした。 会社は、把握している限り、顧客と取引先の個人情報を含め、保管データの外部への流出は確認されていないとしています。削除されたデータは、公表の時点で復旧が完了しています。 ## 公表された原因と再発防止策 公表文は、元社員がどの ID で、どこから社内ネットワークに入ったのかを書いていません。退職後も本人の ID が使える状態だったのかも公表されていません。再発防止策は「情報管理体制の一層の強化およびコンプライアンス教育の徹底」で、具体的な内容は書かれていません。 ## 同じ型の事故で一般に問われる管理 IPA の「組織における内部不正防止ガイドライン」第 5 版は、内部不正の対象に「消去・破壊」を含めています(範囲は[内部不正とは](/guides/incidents/what-is-insider-threat))。重要情報や情報システムの窃取・持ち出し・漏えいだけではありません。消される型の事故では、退職者を遮断する管理と、消されたあとに戻す備えの 2 つが問われます。 遮断の側では、同じガイドラインが、異動や退職で不要になった利用者 ID とアクセス権(誰がどこまで使えるかの設定)を「ただちに削除しなければならない」と定めています。社外から社内ネットワークに入るための ID(在宅勤務用の接続など)が業務システムの ID と別に発行されていると、退職時に止める一覧から漏れやすくなります。ガイドラインは雇用終了時の対策として、元役職員の ID と権限が削除されたことを確かめることを求め、そこに「テレワークを行うために元役職員に付与した権限」も含めています。 削除のしかたにも注意点があります。ガイドラインは、利用者 ID を消すとアクセス記録も消えるシステムがあるため、その場合は ID をロックして使えない状態にし、記録を残すよう注記しています。退職者の ID を消したあとに事故が起きると、消す前の記録が要ります。あわせて、重要情報へのアクセス履歴と利用者の操作履歴を記録して保存することが望ましいとしています。記録がないと、原因の特定、行為者の追跡、影響範囲の調査が難しくなるためです。誰がいつ何を消したかが残っていなければ、復旧の範囲も決められません。 戻す備えの側は、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版が扱っています。企業の規模にかかわらず必ず実行すべき「情報セキュリティ 6 か条」の一つが「バックアップを取ろう!」です。挙げている原因は故障・誤操作・ウイルス感染ですが、人が消した場合も、戻す手段は同じバックアップです。 ## 自分の現場を点検する問い - 社外から社内のネットワークに入るための ID は、退職時に止める一覧に入っているか。業務システムの ID とは別に管理していないか。 - サーバーのデータを消せる権限を持つ人は誰か。その人が退職したとき、権限は誰が止めるか。 - 退職者の ID を消すと、その人の過去の操作の記録も消えるシステムがないか。 - サーバーのデータが消されたとき、いつの状態に、どのくらいの時間で戻せるか。バックアップから戻す手順を試したことがあるか。 - 誰がいつ何を消したかが分かる記録があるか。消された日から気づくまでに、どのくらいかかるか。 ## よくある質問 **データを消されただけで情報漏えいになりますか** 会社は、個人情報を含む保管データの外部流出は確認されていないと公表しています。漏えいがなくても、IPA のガイドラインは重要情報や情報システムの消去・破壊を内部不正の対象に含めています。 **退職者の ID を消すと、その人の操作の記録も消えますか** システムによっては消えることがあります。IPA のガイドラインは、ID を消すとアクセス記録が消える場合には、ID をロックして使えない状態にし、記録を残すよう注記しています。 **消されたデータを戻すには何が要りますか** 消される前の状態のバックアップです。IPA の中小企業向けガイドラインは、必ず実行すべき 6 か条の一つにバックアップを挙げています。戻せるかどうかは、戻す手順を試したことがあるかで決まります。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify が担うのは Web サービスへのログインで、社内のネットワークやサーバーそのものは範囲の外です。Junify 経由で使うアカウントには、退職者は入れません。パスワードを知らないため、Junify を通さずにログインできないからです。誰がいつどのアカウントを使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 退職後に元職員がシステムにログインした事案から分かる、退職日に利用を止める手順 小学校を退職した臨時的任用講師が、退職後に市の学校教育支援システムへ不正にアクセスしたとして逮捕されました。市の公表文は入った経路を書いておらず、問われるのは退職日に利用を止める手順です。 更新日: 2026-09-18 退職から約 2 か月後の逮捕でした。ある市は 2024 年 8 月 8 日、市立小学校の元臨時的任用講師が不正アクセス行為の禁止等に関する法律違反の容疑で逮捕されたと公表しました。不正アクセスの法律上の定義は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access)にまとめています。 ## 何が起きたか 市の公表文によると、元講師は 2024 年 6 月 3 日に退職し、退職後に市の学校教育支援システムに不正にアクセスしました。市は「事実関係の把握に努めているところ」とし、児童・保護者・市民への信頼を損なう事態になったことを詫びています。 公表文が書いているのはここまでです。元講師がいつ、どこから、どの ID でシステムに入ったのか、どの情報が見られたのかは書かれていません。 ## 公表された原因と再発防止策 市の公表文は原因を書いていません。退職後も元講師の ID が使える状態だったのか、別の人の ID を使ったのかも、公表文からは分かりません。今後の対応としては「システム運用基準を遵守し、厳重なセキュリティ体制の構築による再発防止などに努めてまいります」とだけ述べています。 ## 同じ型の事故で一般に問われる管理 退職した人がシステムに入れたとき、まず問われるのは、退職日にその人の利用を止める手順があったかどうかです。IPA の「組織における内部不正防止ガイドライン」第 5 版には、利用者のアクセス管理の項(4-2-2 の(5))があります。そこでは、異動や退職で不要になった利用者 ID とアクセス権(誰がどこまで使えるかの設定)を「ただちに削除しなければならない」と定めています。削除されていないと、役職員や元役職員に不正に利用されて重要な情報にアクセスされる恐れがある、と説明しています。管理ができていないと、不正を行った役職員や元役職員の責任を追及できないことや、企業や団体の管理責任を問われることもある、とも書いています。 止める対象は本人の ID だけではありません。同じガイドラインの付録の事例集には、従業員が退職後に企業のシステム内の機密情報に不正アクセスした例があります。主な原因の一つに「退職後に共有アカウントのパスワードが変更されていなかった」ことが挙がっています。1 つの ID を複数人で使う共有アカウントは、退職者の ID を消しても残ります。退職者がそのパスワードを知っていたなら、パスワードを変えない限り、その人はログインできる状態のままです。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、付録 3「5 分でできる!情報セキュリティ自社診断」の解説編で、共有設定を見直す対策例を挙げています。その一つが「従業員の異動や退職時には速やかに設定を変更(削除)する」です。規模の大きくない組織でも、退職時の変更・削除は基本的対策(Part 1)に含まれています。 臨時的任用や非常勤、任期付きの人は、正規の職員と人事の手続きが違うことがあります。退職の情報がシステムの担当者に届く経路が正規職員と別なら、止める手順もそこで途切れやすくなります。ガイドラインは、ID と権限の登録・変更・削除の手続きに漏れがないよう、人事異動に関連する人事手続きと連携した運用にすることを対策の一つに挙げています。 ## 自分の現場を点検する問い - 退職日に止めるアカウントの一覧はあるか。社内のシステムだけでなく、外部の Web サービスも含まれているか。 - 退職の情報は、誰から誰へ、いつ届くか。人事の手続きとシステムの停止が同じ流れの中にあるか。 - 臨時・非常勤・任期付き・派遣の人の退職も、正規の職員と同じ手順の対象になっているか。 - 退職者が知っていた共有アカウントのパスワードを、退職日に洗い出せるか。 - 退職者の ID で退職後にログインがあったとき、それに気づける記録があるか。 ## よくある質問 **退職者が元の職場のシステムに入ると罪になりますか** 不正アクセス禁止法は、他人の ID とパスワードで制限されたシステムに入る行為を禁じており、条文は退職の前後を区別していません。罰則は 3 年以下の拘禁刑か 100 万円以下の罰金です(3 条・11 条)。 **退職者のアカウントはいつ止めればよいですか** IPA の内部不正防止ガイドラインは、退職で不要になった ID と権限を「ただちに削除しなければならない」とし、雇用終了直後に速やかに行うことが肝要だとしています。退職日に止まる手順にしておくのが目安です。 **退職者に入られた組織の側も責任を問われますか** IPA のガイドラインは、ID と権限の管理ができていないと、不正を行った役職員や元役職員の責任を追及できないことや、企業や団体の管理責任を問われることがある、と書いています。 ## 参考資料 - [不正アクセス行為の禁止等に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/411AC0000000128) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 業務で使う Web サービスを Junify 経由にしていれば、退職した人が後からログインすることはできません。退職の日に管理者が割り当てを外せば、その時点でそのアカウントには入れないためです。担当者はパスワードを知らないので、Junify を通さずにログインすることもできません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 退職日の翌日にアカウントが残っていた事案から分かる、退職手続きとアカウント削除のつなぎ方 元職員が在職中と退職日の翌日に、個人情報を含むファイルを USB メモリで持ち出しました。市は原因の一つに、退職翌日もアカウントの削除処理が行われていなかったことを挙げています。 更新日: 2026-09-18 ある市は、教育委員会の元職員が個人情報を含むファイルを持ち出した事案を公表しています。持ち出しは在職中と退職日の翌日の 2 回で、市は原因の一つに、退職翌日にアカウントの削除処理が行われていなかったことを挙げました。退職者による情報の持ち出しは、IPA のガイドラインでは[内部不正](/guides/incidents/what-is-insider-threat)として扱われます。 ## 何が起きたか 市の公表によると、2019 年 4 月 17 日に市民から「選挙に出ている元職員から選挙葉書が送られてきた。個人情報が漏れている可能性があるので調べてほしい」という電話がありました。市が調べたところ、教育委員会の元職員が、個人情報を含むファイルを持ち出した恐れがあると分かりました。持ち出しの日は、在職中の 2018 年 11 月 29 日と、退職日翌日の 2018 年 12 月 22 日です。 | 持ち出しの日 | 立場 | ファイル数 | 個人情報の件数(延べ) | | --- | --- | --- | --- | | 2018 年 11 月 29 日 | 在職中 | 1,019 件 | 31,429 件 | | 2018 年 12 月 22 日 | 退職日の翌日 | 16 件 | 248 件 | 含まれていた情報は、氏名、住所、電話番号、メールアドレス、性別、生年月日、口座情報などです。市の聞き取りに対し、元職員は 11 月 29 日の持ち出しを否定し、12 月 22 日の持ち出しは認めました。市は、11 月 29 日に持ち出されたファイルに含まれる市民 2 名に選挙はがきが届いていた事実から、その日の持ち出しもあったと判断しています。 ## 公表された原因 市は原因を 3 つ挙げています。 1. 元職員が普段使っていた庁内ネットワークの端末には、USB メモリの接続制限があった。しかし公共施設予約システム専用の端末には制限がなく、この端末を経由してファイルを別の USB メモリに移せた。 2. 退職日の翌日に市庁舎へ入れたのは、元職員から「退職日翌日に荷物の整理がしたい」という申し出があり、執務室への入室を許可していたため。 3. 退職日の翌日に庁内ネットワークの端末を使えたのは、アクセスに必要なアカウントの削除処理が行われていなかったため。 市が挙げた 3 つは、建物への入室、端末へのログイン、USB メモリへの複製という、別々の段階に当たります。 ## 公表された再発防止策 市は技術的対策と人的対策に分けて公表しています。技術的対策は 2 つです。接続制限のない端末に管理ツールを入れて利用を制限し、利用履歴を確かめること。USB メモリをセキュリティ機能つきのものに切り替え、利用履歴を確かめる機能を入れることです。人的対策は 3 つです。USB メモリを管理・監督者が直接管理して利用履歴を確かめること。庁内の連絡体制を強化して退職時のアカウント削除を確実に行うこと。職員研修と、自己点検・監査の見直しです。 ## 同じ型の事故で一般に問われる管理 退職日にアカウントが残る事故で問われるのは、退職の情報がシステムの担当者に届く経路です。市の再発防止策は「庁内の連絡体制の強化」を挙げています。削除の操作そのものより、誰が誰に知らせるかが決まっていたかが問われます。IPA の「組織における内部不正防止ガイドライン」第 5 版は、ID と権限の登録・変更・削除の手続きに漏れが出ないための対策を挙げています。「人事異動に関連する人事手続き等と連携した運用」にすることです。同じガイドラインは雇用終了時の対策として、入館証などの権限がすべて返却されたことと、システムから元役職員の ID と権限が削除されたことを確かめるよう求めています。削除は「雇用終了直後に速やかに実施することが肝要」だとしています。この事案では、入館と端末の両方が退職翌日も使えました。建物に入れることと、システムに入れることは別の管理で、どちらも退職日に止める対象です。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、従業員の異動や退職などに伴う権限の変更・削除の漏れを防ぐことを目的に挙げています。そのために、入室とシステムのアクセス権限(誰がどこまで使えるかの設定)を見直すルールを定め、権限の付与状況を管理するよう勧めています。同じ項目は、アクセス権限の運用や利用状況を監視する仕組みを整えることも勧めています。市の再発防止策の「利用履歴のチェック」はこれに当たります。 ## 自分の現場を点検する問い - 退職者が出たとき、その情報はどの部署からシステムの担当者に、いつ届くか。届かないまま退職日を迎える経路はないか。 - 退職日の翌日に、退職者の ID でログインできるかを試したことがあるか。 - 入館証・鍵・端末の返却と、アカウントの停止は、同じ一覧で確認しているか。 - 退職者が後日に荷物を取りに来るとき、入室の前にアカウントを止め、端末を使えない状態にする決まりがあるか。 - 普段の端末に制限があっても、制限のない端末が別に残っていないか。 ## よくある質問 **退職日の翌日までに何を済ませておくべきですか** IPA の内部不正防止ガイドラインは、雇用終了時に情報資産と入館証などの返却を確かめ、システムの ID と権限が削除されたことを確かめるよう求め、削除は雇用終了直後に速やかに行うことが肝要だとしています。 **退職者が荷物を取りに来るときは何に気をつけますか** この事案では、退職翌日の入室を許可し、アカウントも残っていたため、庁内の端末から持ち出しが起きました。入室を許すなら、その前にアカウントを止め、端末を使えない状態にしておくことになります。 **持ち出しには誰がどう気づけますか** この事案は市民からの通報で分かりました。市は、端末と USB メモリの利用履歴を管理者が確かめることを再発防止策に含めています。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 退職の日に管理者が割り当てを外せば、その翌日に Junify 経由のアカウントへ入ることはできません。担当者はパスワードを知らないためです。在職中については、アカウントごとにファイルのダウンロードを禁止でき、誰がいつどのアカウントを開いたかが本人単位で残ります。USB メモリは範囲の外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 再々委託先の作業者が仕入先の個人情報をダウンロードした事案から分かる、多層の委託とアクセス権限 委託先・再委託先の先にいる再々委託先の作業者が、仕入先担当者の個人情報約 2.2 万件を私用目的でダウンロードしました。委託の階層が深くなるほど、委託元から作業者が見えにくくなります。誰にどの範囲の権限を与えているかが問われた事案です。 更新日: 2026-09-18 空調機器メーカーが 2024 年 2 月に公表した事案で情報を持ち出したのは、委託先ではなく再々委託先の作業者でした。委託先の先に再委託先があり、そのさらに先の会社の作業者です。公表文は、アクセス権限の設定を今後の対応の先頭に挙げています。 ## 何が起きたか この空調機器メーカーは 2024 年 2 月 16 日、仕入先担当者の個人情報が不正にダウンロードされた可能性を公表しました。委託の関係は 4 つの階層です。メーカーから委託先である自社グループの情報システム会社、その再委託先である情報サービス会社、そして再々委託先の作業者です。この再々委託先の作業者が、メーカーと国内関係会社の仕入先情報をダウンロードしました。個人情報を含み、委託された利用目的によらないものでした。メーカーはこれを 2023 年 12 月 24 日に検知しました。 対象は、仕入先情報に含まれる氏名・住所・電話番号・振込先情報の約 2.2 万件です。作業者の情報機器をすべて回収して電磁的な記録を調べたところ、第三者への漏洩の痕跡は確認されなかった、としています。二次被害も確認されていません。公表文は、どのような手段で検知したかを書いていません。 これは再々委託先の作業者による[内部不正](/guides/incidents/what-is-insider-threat)の事案です。 ## 公表された原因 公表文は、発生原因として、委託先の作業者が私用目的で不正に情報をダウンロードしたこと、を挙げています。作業者がなぜその情報にアクセスできたか、権限の範囲がどう設定されていたかについての記述はありません。 ## 公表された再発防止策 メーカーは今後の対応として 3 点を挙げています。個人情報への適切な範囲でのアクセス権限の設定、社内ネットワークのセキュリティ対策、そして委託先を選ぶ基準でのセキュリティチェックの強化です。 ## 同じ型の事故で一般に問われる管理 多層の委託について。個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託先が再委託を行おうとする場合の委託元の対応を述べています。再委託する相手方・業務内容・個人データの取扱方法について、委託先から事前に報告を受けるか承認を行うことが望ましい、とします。再委託先が再々委託を行う場合以降も同様です。委託先を通じて、または必要に応じて自ら、定期的に監査を行うことも挙げています。委託先が再委託先を監督していること、再委託先が安全管理措置(個人データを守る対策)を行っていることを確認するためです。IPA「組織における内部不正防止ガイドライン」第 5 版では、(17)「業務委託時の確認」と (14)「重要情報の受渡し保護」が当てはまります。前者は、再委託の契約時に再委託先について事前報告を受け、これを承認することが望まれる、としています。後者は、受渡しの取り決めを委託先だけでなく再委託先にも順守させることが必要だ、としています。 アクセス権限について。ガイドラインの別添は、技術的安全管理措置として、適切なアクセス制御を行わなければならない、とします。担当者と、取り扱う個人情報データベースの範囲を限定するためです。手法の例に、ユーザー ID に与える権限によって、個人情報データベースを取り扱える従業者を限定することを挙げています。IPA の 4-2「資産管理」は、重要情報へのアクセス権限を与える人を必要最小限にする、とします。与える権限も必要最小限にし、権限を与える期間も必要な時期に限ります。委託先の従業員に権限を与える場合は、(17) で示す契約上の措置が必要だとしています。階層が深い委託ほど、委託元がその作業者を直接知る機会は減ります。だからこそ、権限の範囲と期間を絞り、階層ごとに誰が何を使えるかの報告を受ける決まりが要ります。 ## 自分の現場を点検する問い - 自社の情報に触れている作業者が、契約の相手から何段目にいるかを把握しているか。再委託・再々委託の報告を受ける決まりがあるか - 委託先の作業者に与えている権限は、その作業に必要な範囲に絞られているか。ダウンロードまで必要か - 権限を与える期間が決まっているか。作業が終わった作業者の権限をいつ外すか - 委託先を選ぶときのセキュリティの確認に、再委託先の扱いが含まれているか - 業務では起きないダウンロードを、誰が、どの記録で見つけられるか ## よくある質問 **再々委託先の作業者まで委託元が把握する必要がありますか** 個人情報保護委員会のガイドラインは、再委託の相手方・業務内容・取扱方法について事前報告や承認を受けることが望ましいとし、再々委託以降も同様としています。把握の対象は契約の直接の相手にとどまりません。 **委託先の作業者に与える権限はどう決めますか** IPA のガイドラインは、権限を与える人と権限の範囲を必要最小限にし、期間も必要な時期に限ることを求めています。委託先の従業員に権限を与える場合は、契約上の措置も必要としています。 **委託先の作業者の不正なダウンロードは誰が見つけますか** この事案では委託元が検知したと公表していますが、手段は書かれていません。階層が深いほど作業者は見えにくく、権限の範囲を絞ったうえで、誰がどの記録で見るかを決めることになります。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify では、ファイルのダウンロードをアカウントごとに禁止できます。禁止すれば、この経路は成立しません。委託先でも再委託先でも、作業者は割り当てられたアカウントだけをパスワードを見ずに開くので、誰が・いつ・どれを開いたかは階層の先の作業者まで一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 公式 SNS が乗っ取られた 9 件の公表文から分かること 公表文 9 件のうち、原因を書いたのは 1 件です。多くは「調査中」「再発防止に努める」にとどまります。乗っ取り後に起きたことと、公表文が挙げた対策を表にします。 更新日: 2026-09-18 公式 SNS の乗っ取りの公表文は短く、原因はほとんど書かれていません。それでも並べると、乗っ取られたあとに何が起き、どれだけの時間で戻り、何を対策として挙げたかは分かります。 ## 公表文 9 件の一覧 原因が書かれていないものは「未公表」としました。9 件のうち 2 件(宿泊施設の運営会社、飲食店の運営会社)は、公表文に「乗っ取り」とも「不正アクセス」とも書いていません。 | 当事者(アカウント) | 公表 | 何が起きたか | 原因の公表 | 再発防止策として挙げたこと | | --- | --- | --- | --- | --- | | カメラ・レンズメーカー(公式 Instagram) | 2023 年 11 月 | 運営元を装ったメールへの対応後、管理情報が無効化され、アカウントが削除 | 運営元を装ったメールへの対応 | 個人情報の管理・運用方針の検証と実施 | | 新聞社(主催イベントの公式 X) | 2024 年 3 月 | 3 月 1 日に判明、5 日に復旧。二次被害は未確認 | 未公表 | 再発防止を徹底(具体策なし) | | 自動車用品の小売会社(大会の公式 X・YouTube) | 2024 年 3 月 | 代行会社の Google アカウントへの不正アクセス。無関係な投稿、チャンネル名の変更、動画の削除 | 調査中 | 警察への相談、外部機関と原因究明、体制の強化 | | 業務用ソフトの提供会社(公式 X) | 2024 年 4 月 | 利用を中止し、X 社へ復旧を依頼 | 未公表 | 他の SNS アカウントのセキュリティ強化 | | 食品メーカー(公式 X) | 2024 年 9 月 | 不審な URL 付きの DM が送られた可能性 | 未公表 | 再発防止に努める(具体策なし) | | 宿泊施設の運営会社(公式 Instagram) | 2024 年 12 月 | DM の自動返信で不明瞭なメッセージを誤送信 | 「何らかの不具合」とのみ | 不審な挙動の監視を継続 | | 飲食店の運営会社(一部門の Instagram) | 2024 年 12 月 | アカウントが凍結され、なりすましアカウントを確認 | 調査中(乗っ取りとは書いていない) | セキュリティ体制の強化 | | 中古レコード店の運営会社(店舗の公式 X) | 2025 年 2 月 | 乗っ取られ、不審なメッセージが送られた可能性 | 未公表 | 新アカウントへ移行、全アカウントのセキュリティ対策 | | 業界団体(公式 X) | 2025 年 8 月 | 8 月 5 日午前に乗っ取り、6 日夕方に復旧 | 未公表 | セキュリティ対策の強化 | ## 原因はほとんど公表されない ここでいう原因とは、アカウントに入られた手口のことです。手口を書いたのはカメラ・レンズメーカーの 1 件で、運営元を装ったメールへの対応を挙げています。自動車用品の小売会社は、手口までは書いていませんが、代行会社が使用・管理する Google アカウントが不正アクセスを受けたとして、破られたアカウントを特定しています。宿泊施設の運営会社は「何らかの不具合」とだけ書き、飲食店の運営会社は調査中としています。 ## 乗っ取られるとアカウントで何が起きるか 公表文に書かれた出来事は 4 つに分けられます。フォロワーへの不審な DM は、食品メーカー、中古レコード店の運営会社、業界団体の 3 件が注意喚起の対象にしています。カメラ・レンズメーカーは、同社を騙った連絡や URL を開かないよう呼びかけました。無関係な投稿やリポストと、アカウント名や画像の変更・動画の削除は、自動車用品の小売会社の X と YouTube で起きました。アカウント自体の削除は、カメラ・レンズメーカーの Instagram で起きました。 復旧までの時間は、業界団体が翌日、新聞社が 4 日です。業務用ソフトの提供会社は利用を止めて媒体に復旧を依頼し、中古レコード店の運営会社は新アカウントへ移行しました。接点を失う期間は媒体の対応に左右され、当事者だけでは決められません。 ## 再発防止策に書かれていないもの 9 件の公表文が挙げた対策は、表のとおり「セキュリティ強化」「監視の継続」「方針の検証」などです。二段階認証の設定、パスワードの見直し、担当者の限定といった具体的な方法は、どれにも書かれていません。 ## 同じ型の事故で一般に問われる管理 二段階認証(ログイン時にパスワードに加えてコードを求める仕組み)は Instagram も Google もヘルプで手順を用意しており、仕組みは[二段階認証とは](/guides/shared-accounts/what-is-two-step-verification)で扱っています。複数人で運用するなら、コードを受け取る端末とバックアップコードの保管場所を誰が持つかを決めておく必要があります。 担当者の限定は、パスワードを配る人数を減らすことと、担当者ごとに権限を付けることの 2 つです。X の権限の付与(委任)は[X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](/guides/agency-accounts/x-tiktok-business-account-access)で扱っています。 ## 誤投稿のあとに確かめること 誤投稿は、当事者の公表文の例を確認できなかったため、一般論です。問われるのは、誰が、いつ、どの承認を経て投稿したかです。1 つの ID を複数人で使っていると、媒体の記録は ID 単位で、担当者までは絞れません。担当者ごとに権限を付けるか、ログインを担当者ごとに記録する仕組みがあれば、投稿の時刻と突き合わせて絞れます。投稿前の承認は、媒体に承認の機能がなければ運用で決め、誰が承認したかも記録に残します。 ## 自分の現場を点検する問い 1. 公式アカウントごとに、パスワードを知っている人の人数と名前を挙げられるか。 2. 二段階認証を有効にし、コードを受け取る端末とバックアップコードの保管場所が決まっているか。 3. 乗っ取られたとき、フォロワーへの注意喚起を出す担当と文面が決まっているか。 4. 投稿のあとに、誰がいつ投稿したかを記録から示せるか。 5. アカウントが戻らなかった場合に、顧客へ知らせる別の連絡手段があるか。 ## よくある質問 **公式 SNS の乗っ取りは、何日で復旧しますか** 翌日に復旧した例(業界団体)と 4 日後の例(新聞社)があります。一方、削除されたまま復旧時期が未定の例(カメラ・レンズメーカー)や、新アカウントへ移行した例もあります。 **乗っ取られたとき、公表文に共通する対応は何ですか** 利用の中止と媒体への復旧依頼、フォロワーへの注意喚起(不審な DM やリンクを開かない)、名義の会社による公表です。警察への相談を書いた例もあります。 **乗っ取りの原因は、公表しなくてよいのですか** 9 件中 8 件は原因を書いていません。原因が分からなくても、何が起きたか(DM の送信など)は公表されており、顧客への注意喚起が要ることはそこから分かります。 ## 参考資料 - [Instagram ヘルプセンター「二段階認証」](https://www.facebook.com/help/instagram/566810106808145) - [Google アカウント ヘルプ「2 段階認証プロセスでアカウントを保護する」](https://support.google.com/accounts/answer/185839?hl=ja) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 9 件に共通するのは、アカウントのパスワードを人が知っていることです。Junify を使っていれば、その人から漏れる経路は成立しません。担当者はカードをクリックするだけで、ID とパスワードは Junify が入力します。入り口も Junify のカードに固定されます。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 公式 Instagram が運営元を装ったメールで乗っ取られ、削除された事案 公式 Instagram が、運営元を装ったメールへの対応をきっかけに乗っ取られ、管理情報を無効化されたうえ削除されました。公表文で乗っ取りの原因を書いた例です。 更新日: 2026-09-18 カメラ・レンズメーカーの公表文は、公式 Instagram の乗っ取りのきっかけを、運営元を装ったメールへの対応だったと書いています。乗っ取りの結果、アカウントは復旧ではなく削除に至りました。 ## 何が起きたか 同社は 2023 年 11 月 30 日に、公式 Instagram アカウントが 11 月 27 日に第三者に乗っ取られたと公表しました。不正アクセス(他人の ID とパスワードを入力して、そのアカウントに入る行為。定義は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access))の型の 1 つです。 公表文によると、Meta 社(Instagram)からの公式連絡を装ったメールに担当者が対応しました。その結果、アカウントの管理情報が無効化されてアクセスできなくなり、同時にアカウント自体が削除されていました。公表の時点でも削除された状態が続いており、復旧については「抜本的な解決方法を検討しているところ」としています。 影響の範囲として、同社は Instagram の DM(ダイレクトメッセージ)で個人情報を含む連絡をした 53 名に、個別にお詫びと報告を送るとしています。あわせて、同社を騙った連絡や操作を促す URL を受け取った場合は開かずに破棄するよう呼びかけました。 ## 公表された原因 公表文が原因として書いているのは、運営元を装ったメールへの対応です。メールの内容や、担当者がどの情報を入力したかは書かれていません。 ## 公表された再発防止策 再発防止策として書かれているのは「個人情報の管理・運用方針の検証と実施を徹底」することです。アカウントのログインの方法や、担当者の範囲についての具体策は書かれていません。 ## 同じ型の事故で一般に問われる管理 運営元を装ったメールを、Instagram のヘルプは「フィッシング」と呼んでいます。不審なメッセージやリンクで個人情報を求め、アカウントに入ろうとする行為です。ヘルプが挙げる対処のうち、担当者の運用に関わるのは 4 つです。リンクを開かない、返信しない、パスワードなどの情報を渡さない、二段階認証を有効にする、です。Instagram の公式ブログは、アプリの設定にある「Instagram からのメール」が正式な連絡を受け取る唯一の場所だとしています。Instagram が利用者に DM を送ることはない、とも明記しています。メールの真偽は、メールの中ではなく設定の画面で確かめられます。 二段階認証(ログイン時にパスワードに加えてコードを求める仕組み)は、Instagram のヘルプでは、知らない端末からログインがあったときにコードを求める機能と説明されています。使える方法は認証アプリ(推奨)、SMS、WhatsApp で、電話やメールが使えなくなったときのためにバックアップコードがあります。複数人で運用するアカウントでは、コードを受け取る端末と電話番号を誰が持つか、バックアップコードをどこに保管するかを決めておく必要があります。 担当者ごとの権限付与は、Instagram では Meta のビジネスポートフォリオ(Meta の、広告やページをまとめて管理する画面)から行います。仕組みとできないことは[Meta のビジネスポートフォリオで代理店に権限を付与する仕組み](/guides/agency-accounts/meta-business-portfolio-agency-access)で扱っています。 DM の中身については、個人情報保護委員会のガイドライン(通則編)3-5-1-2 が関わります。漏えいの事例に「不正アクセス等により第三者に個人データを含む情報が窃取された場合」を挙げているためです。公式アカウントの DM で顧客の氏名や連絡先を受け取っていれば、乗っ取りはこの事例に当たりえます。誰と何をやり取りしたかを、乗っ取られたあとに媒体の外で確かめられるかが問われます。 ## 担当者がパスワードを知らないログインの形 ここまでの対策は、どれも担当者の注意力に頼っています。偽の画面を見分ける、リンクを開かない、コードを渡さない。見分けられなかったときに何が渡るかは、担当者がパスワードを知っているという前提から決まります。 その前提を外す形があります。ログインの入り口を 1 つに決め、ID とパスワードの入力を担当者ではなく仕組みに任せる形です。担当者は使ってよいアカウントを選ぶだけで、パスワードそのものを見ません。この形なら、偽の画面が本物そっくりに作られていても、担当者には渡せる秘密がありません。アカウントの安全が、メールの真偽を見分けられるかどうかで決まらなくなります。 残るのは、二段階認証のコードの扱いです。SMS やメールで届いたコードを担当者が読んで入力する運用が残っていれば、そのコードは偽の画面に渡りえます。コードをどこで受け取り、誰が入力するかは、パスワードとは別に決めます。 ## 自分の現場を点検する問い 1. 公式アカウントに「運営元からの連絡」が届いたとき、誰が、どの画面で真偽を確かめるか決まっているか。 2. 二段階認証を有効にしているか。コードを受け取る端末と電話番号、バックアップコードを誰が持っているか。 3. パスワードを知っている人は何人か。担当が変わったときに変えているか。 4. DM で顧客の個人情報を受け取っているか。乗っ取られたとき、誰に知らせるべきかを媒体の外で確かめられるか。 5. アカウントが削除された場合に、顧客へ知らせる別の連絡手段があるか。 ## よくある質問 **公式 SNS が乗っ取られたら、個人情報の漏えいになりますか** DM で顧客の個人情報をやり取りしていれば、通則編が漏えいの事例に挙げる「不正アクセス等により第三者に窃取された場合」に当たりえます。この会社は DM で連絡した 53 名に個別に知らせました。 **運営元を装ったメールは、どう見分ければよいですか** Instagram の公式ブログでは、アプリの設定にある「Instagram からのメール」が正式な連絡を受け取る唯一の場所だとしています。メール内のリンクを開かず、設定から確かめます。 **二段階認証を設定していれば乗っ取られませんか** 知らない端末からのログインでは、パスワードに加えてコードを求められます。ただし、コードを受け取る端末や電話番号を誰が持つかの管理と、偽の画面に情報を入力しない運用が要ります。 ## 参考資料 - [Instagram ヘルプセンター「二段階認証」](https://www.facebook.com/help/instagram/566810106808145) - [Instagram ヘルプセンター「Instagram でフィッシングから身を守る」](https://www.facebook.com/help/instagram/670309656726033) - [Instagram 公式ブログ「Instagram の安全とセキュリティを確保する」(2021 年 7 月 13 日)](https://about.instagram.com/ja-jp/blog/announcements/keeping-instagram-safe-and-secure) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、偽のログイン画面でパスワードを盗む経路は成立しません。ログインの入り口は Junify のカードに固定され、クリックすると ID とパスワードは Junify が入力します。担当者はパスワードを見ないので、偽の画面に渡せる秘密を持っていません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 管理者パスワードの使い回しでランサムウェアの被害が院内に広がった事案 保守用の外部接続機器と院内すべてのパソコンで、同じ推測しやすい ID とパスワードが使われ、全利用者に管理者権限がありました。調査報告書は、原因の多くは国のガイドラインを守っていれば防げたとしています。 更新日: 2026-09-18 2024 年 5 月 19 日、公立の精神科病院で、電子カルテを含む病院情報システムが、ランサムウェア(データを暗号化して身代金を要求するウイルス)の攻撃で停止しました。病院の依頼で設けられた外部の専門家による調査委員会の報告書は、翌年の 2 月 13 日に公表されました。報告書は、記録が失われた部分は推測にもとづく、と断っています。 ## 何が起きたか 報告書によると、最初の侵入は 5 月 13 日でした。攻撃者は院内のネットワークを調べ、バックアップを壊し、Windows のユーザー情報を盗み、ウイルス対策ソフトを止めたうえで、19 日に暗号化を始めました。病院は紙のカルテで診療を続け、発生から 90 日で病院情報システムが完全復旧しています。 個人情報は、サーバーの共有フォルダーの文書から、氏名・住所・病名などを含む最大 40,000 人分が[漏えい](/guides/incidents/what-is-data-breach)したと推定されています。病院は 6 月 11 日に公表し、本人に通知しました。電子カルテそのものへの不正なログインは、記録から可能性が「極めて低い」とされています。 ## 公表された原因 報告書が「原因」の章で確認した事実は 4 つです。 1. 保守用の SSL-VPN 装置(外から院内につなぐための機器)の ID とパスワードが、administrator と P@ssw0rd だった。 2. 院内のすべての Windows の管理者の ID とパスワードも、同じ組み合わせが使い回されていた。 3. SSL-VPN 装置の欠陥が 2018 年の設置以降直されていなかった。 4. すべてのサーバーと端末の利用者に管理者権限が与えられていた。 初期侵入の経路は、VPN 装置への辞書攻撃(よく使われる語を順に試す攻撃)、盗まれた ID・パスワードの購入、装置の欠陥のいずれかと推測されています。院内で被害が広がった原因は、管理者の ID・パスワードの使い回しです。攻撃者は同じ ID・パスワードで別のコンピューターに次々と入り、管理者権限でウイルス対策ソフトを止めて暗号化しました。また VPN 装置には接続元の制限がありませんでした。 報告書は、原因の多くは厚生労働省のガイドラインを守っていれば容易に防げた、と書いています。「過去事例との共通点」の節では、管理者パスワードの使い回し、サーバーと端末の利用者への管理者権限の付与、それによるウイルス対策ソフトの停止という点で、過去の 2 つの病院の事案とまったく同じだ、としています。 ## 公表された再発防止策 報告書が掲げた復旧の原則には、最小特権(管理者アカウントの使い回しを禁じ、管理者権限は一時的・限定的に与える)と、ID・パスワードの保護があります。後者は、複雑さや定期変更を求めず、長いパスフレーズ(文のように長いパスワード)を使い、漏えいを定期的に確かめることです。具体策は次のとおりです。 - VPN 接続の ID・パスワードを推測しにくいものにし、よく使われるものを禁止する。16 桁以上のパスフレーズにする。 - 管理者のパスワードは 1 台ごとに別のものにし、Windows の仕組みで自動的に個別化する。 - 一般の利用者は標準ユーザーで運用し、管理者権限が要るアプリは見直す。 - ログインに 5 回連続で失敗したらアカウントを止める。 - VPN 装置と遠隔操作の接続に、接続元の制限をかける。 - サーバー管理の専用端末に多要素認証を入れる。 あわせて、厚労省などのガイドラインにもとづいて、ベンダーとの契約と役割分担を見直すとしています。 ## 同じ型の事故で一般に問われる管理 報告書が「守っていれば防げた」と書いたのは、厚生労働省の「医療情報システムの安全管理に関するガイドライン」です。報告書が引いたのは第 6.0 版で、現行は第 7.0 版です。第 7.0 版のシステム運用編は、関係する遵守事項(守るべき決まり)を 2 つの章に置いています。 「8. 利用機器・サービスに対する安全管理措置」の章は、情報機器のパスワードを出荷時のものから変更することを求めています。「14. 認証・認可に関する安全管理措置」の章の遵守事項は 3 つです。類推されやすいパスワードを使わせないよう、設定できるパスワードに制限を設けること。一定回数ログインに失敗したら、一定時間ログインできなくすること。令和 9 年度時点で稼働するシステムの新規導入・更新では、二要素認証か相当する対応を行うことです。 同じ章の解説は、VPN 装置にも二要素認証(2 つの方法でログインを確かめる仕組み。詳しくは[二段階認証とは](/guides/shared-accounts/what-is-two-step-verification))などを入れることが望ましい、と書いています。パスワードの桁数は、二要素認証がある場合は 8 桁以上、ない場合は 13 桁以上とし、定期的な変更は不要としています。 管理者権限については、IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版に一般の水準があります。ユーザー ID と管理者 ID(管理者権限を持つ ID)の発行から削除までを管理する手続きを定め、どちらの ID も必要最小限の人にだけ与える、という内容です。 ## 自分の現場を点検する問い 1. 外から社内につなぐ機器の ID とパスワードは、設置時のまま、または推測できるものになっていないか。 2. 管理者用のパスワードを、複数のサーバーや端末、サービスで同じにしていないか。 3. 日常の業務に管理者権限が本当に要るか。要らない人にも与えていないか。 4. ログインの失敗が続いたときにアカウントを止める設定があるか。 5. 保守業者が使う接続の経路と ID を把握し、接続元を制限しているか。 ## よくある質問 **P@ssw0rd のようなパスワードはなぜ危ないのですか** 攻撃者は、よく使われるパスワードの一覧を順に試します。報告書は、初期侵入の経路を、外部接続機器への辞書攻撃、盗まれた ID・パスワードの売買、機器の欠陥のいずれかと推測しています。 **医療機関の二要素認証はいつまでに要りますか** 第 7.0 版は、令和 9 年度時点で稼働する医療情報システムを新規導入・更新する際に採用するとし、技術的に困難な場合は令和 9 年度以降の直近の更新までを期限としています。 **管理者権限を外すと診療システムは動きますか** 報告書は、管理者権限が要るアプリは見直しを検討し、使うサーバーと端末を限るよう勧めています。動作の確認はベンダーへの問い合わせが要ります。 ## 参考資料 - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン」関係資料一式](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 侵入の入口になったのは、人が覚えて使い回せるパスワードです。Junify が預かるアカウントでは、これは起きません。パスワードは管理者が登録し、担当者は見ないまま使うので、人づてに広がりません。誰がいつ使ったかは一人ひとり残ります。社内の機器やパソコンの設定は Junify の外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # パスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案 他のサービスから漏れた ID とパスワードの組を試す攻撃で、二段階認証をオフにしていた ID だけが不正ログインされました。国内 12 件、海外を含め 156 件です。 更新日: 2026-09-18 2024 年 7 月、店や会社の公式アカウントを運用する管理画面に入るための ID が、複数の[不正アクセス](/guides/incidents/what-is-unauthorized-access)による不正ログインを受けました。この管理画面を提供する情報サービス会社は、8 月 26 日に事実を公表し、10 月 24 日に件数と対策を続報しています。対象は、店や会社の側が使う管理画面です。一般の利用者のアカウントへの不正な操作はなかった、と公表文は書いています。 ## 何が起きたか 公表文によると、不正ログインは 7 月 10 日から 18 日の間に発生し、19 日に検知されました。手口はパスワードリスト攻撃(他のサービスで実際に使われている ID・パスワードの一覧を使い、ログインを試す攻撃)です。不正ログインが確認されたのは、メールアドレスとパスワードだけで使える方式の ID に限られます。本人の個人アカウントでログインする方式の ID では確認されていません。続報によると、対象となった ID は国内 12 件、海外を含めて 156 件でした。いずれも二段階認証の機能をオフにしていた ID です。 不正ログインされた ID では、その ID で入れる各サービスが使える状態になります。公式アカウントの運用画面と、動画などを投稿する画面です。公表文が、閲覧されたり操作されたりした可能性があるものとして挙げたのは 3 つです。登録した利用者のプロフィール情報と 1 対 1 のやり取りの内容、公式アカウントに登録された住所・電話番号・メールアドレスなどの連絡先情報、不審なメッセージの配信です。 ## 公表された原因 原因として公表されているのは 2 つです。他のサービスから流出したメールアドレスとパスワードの組み合わせが使われたこと、つまりパスワードの使い回しと、二段階認証がオフだったことです。パスワードリスト攻撃は、そのサービス自体から情報が漏れなくても、別のサービスで漏れた組み合わせが同じなら成功します。二段階認証があれば、パスワードが合っていても 2 つ目の確認で止まります。 ## 公表された対応と再発防止策 運営会社は、不正ログインされた ID の管理者に、7 月 19 日・22 日・25 日にパスワード再設定の通知をメールで送りました。7 月 30 日までに、不正ログインされた ID のログインしたままの状態を無効にしています。8 月 26 日に公表し、二段階認証の設定を強く推奨するとともに、他のサービスで使っているパスワードを使い回さないよう呼びかけました。9 月 3 日には、メールアドレスを登録して使う利用者を対象に、二段階認証の有効化を実施しています。 続報は、ログインのたびに登録メールアドレスへログイン通知を送っていることにも触れています。 ## 同じ型の事故で一般に問われる管理 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部 実践編の冒頭「情報セキュリティ 6 か条」の 3 番目に「パスワードを強化しよう」を置いています。理由は、Web サービスから流出した ID・パスワードが悪用されて不正にログインされる被害が増えていることです。そのうえで「長く」「複雑に」「使い回さない」の 3 点を勧めています。対策例には、同じ ID・パスワードを複数のサービス間で使い回さないこと、重要なシステムでは多段階認証・多要素認証・パスキーなどの認証を強くする機能を使うことが並びます。 米国 NIST の SP 800-63B(ログインの本人確認についての基準)第 4 版には、利用者に使い回しを禁じる条文はありません。代わりに、パスワードを受け取って確かめるサービスの側に義務(SHALL)を置いています。過去の漏えいで出回ったパスワードやよく使われるパスワードの一覧と照合し、一致すれば別のものを選ばせる、という義務です。使い回されたパスワードは、別のサービスから漏れた時点でこの一覧に載りえます。2 つの資料は、同じ攻撃を利用者側とサービス側の両面から防ぐ形になっています。 店の公式アカウントの管理画面は、1 つの ID を複数の担当者で使う運用になりがちです。[二段階認証](/guides/shared-accounts/what-is-two-step-verification)は、本人が持つスマホなどを前提にした仕組みです。そのため、複数人で 1 つの ID を使っていると、設定をためらう理由になります。使い回さない長いパスワードと二段階認証は、担当者ごとに ID を分けると設定しやすくなります。分けられる媒体では分けるのが先だと考えられます。分けられない ID にだけ、共有したままの対策が要ります。 ## 自分の現場を点検する問い 1. 会社や店の公式アカウントのログインに、他のサービスと同じパスワードを使っていないか。 2. 二段階認証をオフにしている業務用の ID はどれか。オフにした理由は「複数人で使うから」ではないか。 3. 1 つの ID を複数の担当者で使っている場合、誰がパスワードを知っているかを一覧にできるか。 4. ログイン通知のメールは誰に届き、身に覚えのないログインを見つけたときに誰が動くか。 5. 担当者が辞めたとき、そのアカウントのパスワードを変えているか。 ## よくある質問 **パスワードリスト攻撃とは何ですか** 他のサービスから流出した ID とパスワードの一覧を使ってログインを試す攻撃です。同じ組み合わせを使い回していると成功します。運営会社の公表文はこの攻撃を原因としています。 **二段階認証を設定していれば防げましたか** 公表文は、不正ログインが確認されたのは二段階認証の機能をオフにしていた ID のみだった、としています。オンにしていた ID では確認されていません。 **公式アカウントを複数人で使うとき二段階認証は** 二段階認証は本人のスマホなどを前提にしているので、共有すると誰が使ったかが分からなくなります。担当者ごとに ID を分けられる媒体では、分けるのが先です。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、この経路は成立しません。パスワードは管理者が登録し、担当者は自分のスマホで本人確認をしてから、見ないまま使います。担当者がパスワードを知らないので、ほかのサービスと同じものを使い回すことが起きず、漏れた組み合わせを試す攻撃の前提が消えます。誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 退職後に社外の Web サービスへ不正アクセスされた事案から分かる、外部サービスのアカウントの止め方 元従業員が退職後に、会社が利用する名刺管理システムに不正にアクセスし、名刺情報を漏えいさせました。問われるのは、会社が使うシステムのアカウントを退職時に止める手順です。社外の Web サービスなら、社内の手続きだけでは止まりません。 更新日: 2026-09-18 ある人材サービス会社の元従業員が、個人情報保護法違反などの疑いで警視庁に逮捕されました。この会社は 2023 年 9 月 15 日、これを公表しています。公表文は、入られた先を「当社が利用している名刺管理システム」と書いており、社内のシステムか、外部の事業者が提供するサービスかは書かれていません。 ## 何が起きたか 公表文によると、この会社を退職した元従業員が、会社が利用している名刺管理システムに不正にアクセスし、会社が保有する顧客などの名刺情報を漏えいさせました。不正アクセスの法律上の定義は[不正アクセスとは](/guides/incidents/what-is-unauthorized-access)にまとめています。 会社は、個人情報が漏えいした可能性がある方にお詫びの連絡を済ませ、個人情報保護委員会に報告し、警察に相談して捜査に協力していると述べています。漏えいが起きたときに事業者に生じる報告と本人への通知は、[漏えい等とは](/guides/incidents/what-is-data-breach)にまとめています。 ## 公表された原因と再発防止策 公表文は、元従業員がいつ退職し、いつ、どの ID でシステムに入ったのかを書いていません。再発防止策は「既にセキュリティ対策の強化等を実施しており、引続き再発防止に努めてまいります」の一文です。 ## 同じ型の事故で一般に問われる管理 会社が契約して使う外部の Web サービスの場合、そのサービスは社内のネットワークの外にあります。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、クラウドサービスと社内システムの根本的な違いを説明しています。インターネットを使うため「いつでも、どこからでも、誰でもアクセス可能」であることです。退職者の社内の端末やメールを止めても、サービス側のアカウントが残っていれば、その人は自宅の端末からでもそのサービスに入れます。退職時に止める対象の一覧に外部サービスが入っていないと、社内の手続きを終えても、社外のサービスに、退職者が入れるアカウントが残ります。 止める手順は、サービスごとに違います。利用者を管理画面から削除できるサービスもあれば、1 つの ID を複数人で使っていて、パスワードを変えるしかないサービスもあります。IPA の「組織における内部不正防止ガイドライン」第 5 版は、利用者 ID とアクセス権(誰がどこまで使えるかの設定)の登録・変更・削除について対策を挙げています。「承認手順や設定終了報告等の手続きを定めて運用」することです。設定を終えたら報告する、という一段があると、止め忘れが人事の側から見えるようになります。 名刺情報のように、営業担当が日常的に入力し、退職後も価値のある情報は、退職の日に「誰が入れるか」を確かめる対象になります。同じガイドラインは、ID とアクセス権が適切に付与されているかを定期的に見直し、人事異動の時期に一斉に見直すことを望ましいとしています。契約している外部サービスの一覧と、サービスごとの利用者の一覧がそろっていれば、止め忘れは次の見直しで見つかります。一覧がなければ見直しの機会がなく、止め忘れは外部からの連絡で知ることになりかねません。 ## 自分の現場を点検する問い - 会社が契約している外部の Web サービス(名刺管理、チャット、ファイル共有、会計、採用など)の一覧はあるか。誰が管理者かまで分かるか。 - 退職時の手続きの一覧に、社内システムだけでなく、その外部サービスごとの停止が入っているか。 - 担当者が自分で申し込んで使い始めたサービスや、個人のメールアドレスで登録したサービスが、一覧の外に残っていないか。 - 1 つの ID を複数人で使っているサービスで、退職者がパスワードを知っていたかを確かめられるか。 - 停止を終えたことを、誰が誰に報告するか。報告がないとき、誰が気づくか。 ## よくある質問 **外部の Web サービスも退職時に止める必要がありますか** あります。社内の端末やメールを止めても、サービス側のアカウントが残っていれば、そのサービスにはどこからでも入れます。IPA のガイドラインは、退職で不要になった ID と権限をただちに削除するよう求めています。 **退職者のアカウントを止め忘れたかどうか、後から分かりますか** 契約している外部サービスの一覧と、サービスごとの利用者の一覧があれば照らし合わせられます。IPA のガイドラインは、人事異動の時期などに定期的にアクセス権を見直すことを対策に挙げています。 **退職者が名刺情報を持ち出したら誰の責任ですか** この事案では元従業員が逮捕され、会社は個人情報保護委員会に報告し、対象の方に連絡しました。行為者の責任とは別に、漏えいした側には報告と本人への対応が生じます。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 業務で使う Web サービスを Junify 経由にしていれば、この型の不正アクセスは成立しません。サービス側の ID が残っていても、管理者が割り当てを外せば担当者はそのアカウントに入れません。パスワードは担当者に渡っていないためです。誰がいつどのアカウントを使ったかも、一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案 給食の委託先の機器から侵入され、病院のサーバーと端末で共通だったパスワードで被害が広がりました。報告書が原因に挙げたのは、共通パスワード、全員への管理者権限、外部接続の役割分担の曖昧さです。 更新日: 2026-09-18 2022 年 10 月 31 日、公立の総合病院が、ランサムウェア(データを暗号化して身代金を要求するウイルス)の攻撃を受けました。電子カルテを含む基幹システムが止まり、病院の調査委員会の報告書と概要版は翌年の 3 月 28 日に公表されました。 ## 何が起きたか 侵入の入口は、給食業務を委託していた事業者(給食事業者)のシステムでした。報告書概要は、攻撃の手順を 7 段階で推定しています。 1. 給食事業者の保守用の VPN 機器(外から社内につなぐための機器)の欠陥を使って侵入。公開されていた ID・パスワードで侵入された可能性もある。 2. 給食事業者内の ID・パスワードが弱く、他のシステムの情報やパスワードを盗んで攻撃を広げた。 3. 病院のサーバーの ID・パスワードを盗み、遠隔操作の通信で病院の給食サーバーに侵入。ウイルス対策ソフトを削除。 4. 病院内の他のサーバーの ID・パスワードを盗む。給食サーバーと共通だったため容易だった。 5. 盗んだ ID・パスワードで電子カルテなどの基幹サーバーに侵入。 6. サーバーを経由して端末にもログオンを試みた可能性。 7. 各サーバーでランサムウェアを動かし、身代金を要求。 被害は、電子カルテを含む基幹システムのサーバーの大部分が暗号化されたことです。院内約 2,200 台の端末にも[不正アクセス](/guides/incidents/what-is-unauthorized-access)の痕跡がありました。すべてのサーバーと端末を初期化し、基幹サーバーの再稼働に 43 日、全体の復旧に 73 日を要しています。個人情報の漏えいの可能性は、通信の記録と端末の調査から「極めて低い」とされています。 ## 公表された原因 報告書は、原因を「外部接続(リモートメンテナンス)の管理不備」と「内部のセキュリティが脆弱」の 2 つに分けています。後者について概要は、初期設定が適切なら被害は大規模には広がらなかった可能性がある、と書いています。 | 被害を広げた設定 | 報告書が挙げた再発防止策 | | --- | --- | | 利用者すべてに管理者権限があり、攻撃者にウイルス対策ソフトを削除された | 利用者は管理者権限のない標準ユーザーにする | | Windows のパスワードがサーバー・端末で共通で、1 つ盗まれると他のすべてを乗っ取れた | サーバー・端末ごとに個別のパスワードにする | | ログイン失敗が続いてもアカウントを止める設定がなく、パスワードを数多く試された | 一定回数失敗したらアカウントを止める設定を有効にする | | 電子カルテのサーバーにウイルス対策ソフトがなかった | 電子カルテのサーバーにも入れる | 外部接続については、報告書の表が 3 点を挙げています。VPN 機器などの外部通信機器の保守で、欠陥の管理の役割分担が曖昧だったこと。遠隔保守を許可する基準が曖昧で、保守を行う側の環境の確認が不十分だったこと。許可した後に、その利用状況を確認していなかったことです。組織面では、契約ごとに責任の境界と役割が明確でない領域があった、としています。電子カルテのベンダーは聞き取りに「パスワードが同じであることは(病院にも)認識してもらっていた」と答えましたが、報告書は、その合意を確認した記録はなかったとしています。 ## 同じ給食事業者とつながる他の病院との違い 報告書は、同じ給食事業者と接続していた別の 2 病院と比べています。1 つの病院は給食サーバーに侵入されませんでした。もう 1 つは給食サーバーに侵入されましたが、その先の電子カルテのサーバー群とはパスワードもネットワークの区画も別で、先へは進まれていません。この病院は両方が共通でした。 ## 公表された再発防止策 技術面では、上の表の 4 点に加え、外部接続や遠隔保守を許可する基準を定めるとしています。申請時に相手側の環境を確認し、接続後は通信の記録を確認する運用です。契約面では、契約ごとに受注者と役割分担・責任の境界を文書で確認すること、病院共通の方針にもとづく仕様で調達することを挙げています。復旧時の方針には、ID の共用と共通パスワードの禁止、16 桁以上のパスフレーズ(文のように長いパスワード)の推奨も含まれます。 ## 同じ型の事故で一般に問われる管理 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部 実践編で、パスワードの設定と管理のルールを定めて周知するよう勧めています。内容は 3 つです。複雑さを保つこと、社内のシステムや機器で使い回しを防ぐルールを定めること、保管方法(紙・ファイル・パスワード管理アプリなど)の違いを知って自社のルールを定めることです。 厚生労働省の「医療情報システムの安全管理に関するガイドライン」第 7.0 版(システム運用編)は、「認証・認可に関する安全管理措置」の章に遵守事項(守るべき決まり)を置いています。その 1 つが、異なる医療情報システムでパスワードを使い回さないことです。同じ章は、サーバー群へのログインを踏み台の端末(サーバーに入る前に必ず通す中継用の端末)に限る構成も認めています。その条件の 1 つが、サーバー群と踏み台端末で共通のパスワードを使わないことです。どちらも、1 つのパスワードが盗まれたときに被害が広がる範囲を、分けることで狭める考え方です。 ## 自分の現場を点検する問い 1. サーバー、端末、業務で使う Web サービスのうち、同じパスワードを使っている組み合わせはいくつあるか。 2. 委託先や保守業者が自社のシステムにつなぐ経路を一覧にしているか。その接続を止める権限と手順は誰にあるか。 3. 委託先が使うアカウントのパスワードは誰が知っており、担当者が代わったときに変えているか。 4. ログインの失敗が続いたときにアカウントを止める設定が、サーバーと業務サービスの両方で有効か。 5. 保守や欠陥の修正を誰が担うか、契約書や文書で確認できるか。 ## よくある質問 **委託先の機器から侵入されても委託元の問題になりますか** 報告書は病院側の問題として、契約ごとに保守や欠陥の管理の役割分担が明確でなかったこと、外部接続の許可後に利用状況を確認していなかったことを挙げています。責任の有無は契約と法令の確認が要ります。 **サーバーごとにパスワードを分けると管理が大変ではありませんか** 報告書は復旧方針で、サーバーと端末の管理者パスワードをすべて個別にし、16 桁以上のパスフレーズを推奨しています。厚労省のガイドラインも定期変更は不要としており、分けることを優先します。 **この事案で個人情報は漏えいしましたか** 報告書概要は、通信の記録と端末の調査から、個人情報漏えいの可能性は極めて低いとしています。被害の中心は、電子カルテを含むシステムの停止による診療の制限でした。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン 第 7.0 版 システム運用編」](https://www.mhlw.go.jp/content/10808000/001716295.pdf) - [厚生労働省「医療情報システムの安全管理に関するガイドライン」関係資料一式](https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 取引先と共通のパスワードを使う、という入口は Junify では起きません。委託先の担当者に使わせるアカウントも、パスワードは管理者が登録し、担当者は見ないまま使います。誰がいつ使ったかは担当者ごとに残り、担当が代われば割り当てを外すだけです。サーバーや機器の設定は Junify の外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 共有ツールの ID とパスワードが盗まれて侵入された事案から分かる、ID の発行と管理、多要素認証 正規の ID とパスワードが盗まれ、正常なログインに見える形で顧客から預かった情報が窃取されました。影響は 142 の顧客に及び、検証委員会は情報保護の体制と利用組織ごとの管理の不備を指摘しました。 更新日: 2026-09-18 2021 年 5 月 25 日、ある情報サービス会社が、プロジェクトの情報を関係者で共有するツールへの第三者からの[不正アクセス](/guides/incidents/what-is-unauthorized-access)を公表しました。顧客から預かった情報の一部が盗まれた、という内容です。以後、2022 年 4 月 22 日の第六報まで 6 回にわたって公表しています。 ## 何が起きたか 初報の時点で会社は、さらなる不正アクセスを防ぐためそのツールの運用を停止し、影響範囲と原因を調査中としました。第二報は、第三者が正規の ID とパスワードを使い、正常な認証と通信によって外部から不正アクセスを行ったものだとしています。ツールの何らかの欠陥を悪用した可能性が高い、とも書いています。影響を受けた顧客は 129 とされ、第五報で 142 に改められました。 第四報は、そのツールに数種類の欠陥があったことを確認したものの、悪用された欠陥の特定には至らなかったとしています。そのうえで、第三者がそのいずれかを使うなどして正規の ID とパスワードを盗んだ、と判断しています。 ## 公表された原因 第六報の別紙は、外部の有識者で構成された検証委員会の指摘をまとめています。不正アクセスの原因は 4 点です。 1. 情報保護の体制が不十分だった。 2. 人員・予算の制約などから、そのツールのセキュリティの強化・管理に手が回らなかった。 3. 不正アクセスを直ちに検知する体制が整っていなかった。 4. 利用する会社ごとの環境の管理の多くが、その会社側の管理者に任されていた。 発覚後の対応が遅れた原因は 6 点挙がっています。そのうち ID と記録の管理に関わる 2 点は、個別プロジェクトの問題という前提で対応したことと、属人的な運用と記録の管理が適切でなくツールの構造の把握に時間を要したことです。真因として委員会が挙げたのは次の 4 点です。「当初の想定より幅広い環境と目的でなし崩し的に使われ、その性質や利用状況に沿った扱いがされていなかったこと」「組織が縦割りの傾向にあり、社内システムの管理が全社で一元的に行われていなかったこと」「利便性やコスト削減の意識から、情報管理やセキュリティが優先されない場合があったこと」「インシデント対応で主体的に先手を打つ姿勢が十分でなかったこと」です。 ## 公表された再発防止策 第四報は、そのツールに代わる新しいツールの方針を書いています。多要素認証(2 つ以上の方法でログインを確かめる仕組み)で不正ログインを防ぎ、複数の記録を一元的に集めて不審な動きを監視する、という内容です。第六報は再発防止策を 5 項目にまとめました。項目の名前と、公表文の要点は次のとおりです。 1. セキュリティ対策強化と管理・監督の徹底。セキュリティの枠組みを標準化し、多要素認証の導入や情報管理の厳格化を行う。CISO(情報セキュリティの責任者)直轄の組織が監査・監視・是正を行う。 2. セキュリティインシデント対応の強化。事故対応の体制を強化する。 3. 社内 IT システムの一元管理と各プロジェクト部門の自律的な是正促進。社内のシステムを一元的に管理し、各部門の是正を促す。 4. 全社のセキュリティ意識徹底とリテラシー向上に向けた教育、制度の見直し。教育と制度を見直す。 5. 対外コミュニケーションの改善。顧客や関係当局への情報伝達を改める。 検証委員会の提言 8 項目には、社内 IT システムの一元管理と各システムの位置づけの明確化が含まれます。情報管理やセキュリティを利便性やコスト削減に劣後させない風土づくりも、その 1 つです。 ## 同じ型の事故で一般に問われる管理 複数の会社や案件の関係者が 1 つのツールを使う場面では、ID を誰に発行し、誰が管理し、いつ消すかが問われます。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、第 2 部 実践編で、ユーザー ID と管理者 ID の発行・変更・削除の手続きを定めるよう勧めています。発行から削除までを管理する手順を作り、ID は必要な人にだけ与える、という内容です。共有 ID はなるべく使わず、やむを得ず使う場合は、共有 ID を使った人を特定できる仕組みを整えて運用することも挙げています。アクセス権限の運用や利用状況を監視する仕組みも勧めています。ID の管理を各部門や各案件の管理者に任せる場合でも、全体の手順と監視の仕組みは会社側で持つ、という考え方です。 米国 NIST の SP 800-63B(ログインの本人確認についての基準)第 4 版は、本人が意図してログインの秘密を共有する行為は技術的に検知・防止しにくい、と書いています。1 人 1 ID にしても、ID とパスワードを人から人へ渡す運用が残れば、誰が使ったかは記録に残りません。パスワードの使い回しについての NIST の考え方は、アカウントの乗っ取りの型の記事で扱っています。 ## 自分の現場を点検する問い 1. 取引先や委託先と共有しているツールの ID は、誰が発行し、誰が一覧を持っているか。 2. 案件が終わった後、その案件用の ID を消す手順と期限があるか。 3. 1 つの ID を複数の人で使っているツールで、使った人を特定できる記録があるか。 4. ID とパスワードだけでログインできるツールに、2 つ目の確認を付けられるか。 5. 各部門・各案件の管理者に任せている設定を、会社側が定期的に確かめているか。 ## よくある質問 **正規の ID でログインされる攻撃は防げますか** 公表文は、第三者が盗んだ正規の ID とパスワードで、正常な認証に見える形でアクセスしたとしています。会社が挙げた再発防止策は、多要素認証と、記録を一元的に集めた監視です。 **そのツールはその後どうなりましたか** 初報で運用を停止し、第四報で新しいツールへ移行して利用を終了すると判断したことを公表しています(終了の時期は書かれていません)。新しいツールは多要素認証と記録の一元管理を行います。 **影響を受けた顧客はいくつですか** 第二報で 129、第五報で 142 に改められました。案件数や、盗まれた情報の種類は公表文に書かれていません。 ## 参考資料 - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、この経路は成立しません。ID とパスワードは管理者が登録し、担当者には渡さないからです。担当者の手元にパスワードがなければ、そこから盗んで使うことはできません。認証アプリに出るコードも Junify が入力し、案件が終われば割り当てを外すだけです。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 無断の再委託先が個人データを持ち出した事案から分かる、再委託と辞めた人が知っているパスワード 全市民約 46 万人の個人データを入れた USB メモリーを、市に無断の再々委託先の従業員が持ち出して紛失しました。調査報告書は、無断の再委託と、案件を離れた人や転職した人もパスワードを知ったままだった状態を、問題として明記しています。 更新日: 2026-09-18 ある市で 2022 年 6 月に起きた USB メモリーの紛失は、市の調査委員会の報告書が委託先の内部の運用を細かく記した事案です。報告書が問題として書いているのは、市に無断の再委託・再々委託と、案件を離れた人や転職した人もパスワードを知ったままだった状態です。 ## 何が起きたか 市の調査委員会は、令和 4 年 11 月 28 日に報告書を公表しています。それによると、市は臨時特別給付金の業務を情報サービス会社に委託していました。2022 年 6 月 21 日、その委託先の再々委託先(市に無断)の従業員が、市の施設のサーバーから個人データをコピーしました。USB メモリー 2 本に入れた中身は、全市民約 46 万人分です。そのままコールセンターへ運び、作業後に同行者と飲食して、6 月 22 日未明の帰路でカバンごと紛失しました。USB メモリーは 6 月 24 日に見つかっています。個人情報保護法でいう[漏えい等](/guides/incidents/what-is-data-breach)のうち、紛失の事案です。 ## 公表された原因 報告書は、紛失に至る運用の問題を多数挙げています。そのうち、委託の構造に関するものとパスワードに関するものは次のとおりです。 無断の再委託について。市と委託先の契約は、業務の一部を第三者に委託するときは、あらかじめ市の承認を書面で得るよう定めていました。しかし令和 4 年の業務で、市の承諾のない再委託・再々委託がありました。報告書は、令和 2 年の給付金業務からそうだったとみています。市の施設のサーバールームに入れる入退室カードを申請した人は 19 名でした。うち 10 名は委託先以外の、再委託先・再々委託先の従業員でした。市はその名簿を委託先の従業員と誤認してカードを貸与しました。再委託先・再々委託先の従業員は、上司の指導で、自分が別会社の従業員であることを市に明かしていませんでした。委託先は再委託先・再々委託先にセキュリティ監査を行ったことがありませんでした。市も委託先に監査を行ったことがありませんでした。 パスワードについて。市と委託先の間で共有していたパスワードは、共有する期間や範囲に限定がありませんでした。人事異動や退職があっても固定されたままでした。案件から離れた人や別会社に転職した人も、パスワードを知ったままでした。パスワードは口頭で伝わり、変更もされていなかったため、知っている人がどこまで広がっているか確認できない状態でした。紛失した USB メモリーのパスワードも、以前から市と委託先で使われていた同じものでした。過去に市の業務に関わった再委託先・再々委託先の従業員も知っていました。パソコンでも、紛失した従業員の ID とパスワードが他の従業員と共有されていました。その従業員がパソコンを使えなくなった後も、他の人がログインできていました。ID を見ても実際の使用者を特定できない、と報告書は述べています。一部の端末では、一般の権限のアカウントがなく管理者権限のアカウントだけで業務をする運用も認められました。 USB メモリーの管理簿はありませんでした。誰が・いつ・何の目的で持ち出し、いつ戻し、データを消したかを記録するものもありませんでした。 ## 公表された再発防止策 調査委員会は、調査の途中で、従来のパスワードを直ちに変えることと、共有の範囲を必要最小限にすることを市に指示しました。報告書の提言と消去に関する節から、委託とデータに関わる 3 点を引きます。委託事業者の遵守状況も含めた監査を実施すること。契約の履行に際して、再委託・再々委託など業務の体制が実際に伴っているかの確認を必須とすること。USB メモリーでデータを移した後はその場で消去し、消去したことを市職員が確かめるなど、二重に確認する仕組みを設けることです。 委託先は三大原則を挙げています。顧客の情報には直接触らない、持ち運びできる記録媒体は使わない、情報は限定した場所から持ち出さない、の 3 つです。緊急対策として、情報セキュリティと契約の遵守について週次のモニタリングを徹底する、と定めています。 ## 同じ型の事故で一般に問われる管理 個人情報保護委員会のガイドライン(通則編)3-4-4 は、委託先が再委託を行おうとする場合の委託元の対応を述べています。再委託する相手方・業務内容・個人データの取扱方法について、委託先から事前に報告を受けるか承認を行うことが望ましい、とします。再々委託以降も同じです。委託先を通じて、または必要に応じて自ら、定期的に監査を行うことも挙げています。ガイドラインは、監督を行っていない事例も挙げています。再委託の条件を指示せず取扱状況の確認も怠って再委託先が漏えいした場合と、契約に再委託の把握を盛り込みながら報告を求めなかった場合です。同じ節の脚注は、委託元が委託先を適切に監督していない場合に触れています。そのとき再委託先が不適切な取扱いをすれば、元の委託元の法違反と判断され得る、とあります。 IPA「組織における内部不正防止ガイドライン」第 5 版では、(5)「情報システムにおける利用者のアクセス管理」が当てはまります。異動や退職で不要になった利用者 ID とアクセス権は、ただちに削除しなければならない、とします。その脚注は、委託先の従業員の異動や退職でアカウントの削除漏れが起きないよう、体制に変更があれば委託元に報告することを例に挙げています。(7)「利用者の識別と認証」(共有 ID や共有のパスワードを使わない)も同じ型に当てはまります。共有パスワードでは、辞めた人だけを止める操作がありません。止めるにはパスワード自体を変え、残る人全員に配り直すことになります。 ## 自分の現場を点検する問い - 委託先の現場で働いている人の所属を、委託先の申告以外の方法で確かめたことがあるか - 委託先や再委託先と共有しているパスワードは、誰が知っているかを一覧にできるか。案件を離れた人や転職した人が含まれていないか - 共有パスワードを最後に変えたのはいつか。変えるきっかけ(退職・異動・契約終了)が決まっているか - 委託先のパソコンや端末の ID が個人ごとになっているか。管理者権限だけで日常業務をしていないか - 委託先に対する監査を、委託元として行ったことがあるか。委託先が再委託先に監査をしているか確認したか ## よくある質問 **再委託を知らなかった委託元に責任はありますか** ガイドラインは、委託元が委託先を適切に監督していないとき再委託先が不適切な取扱いをすれば、元の委託元の法違反と判断され得る、としています。知らなかったことは理由になりにくいと読めます。 **辞めた人がパスワードを知ったままだと何が問題ですか** パスワードは知っている人なら誰でも使えるため、辞めた人を止める操作がありません。この事案の報告書は、変更もされず口頭で伝わっていたため、誰まで知っているか確認できなくなっていた、と述べています。 **再委託先の人が現場にいるかを委託元はどう確かめますか** この事案では、委託先が提出した入退室カードの名簿に再委託先の従業員が含まれ、市はそれを委託先の従業員と誤認しました。名簿を信用するだけでなく、所属を裏付ける確認と、定期的な監査が要ります。 ## 参考資料 - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify を使っていれば、パスワードが口頭で伝わっていく経路はありません。担当者は自分のスマホで本人確認をして、パスワードを見ないままアカウントを開くからです。案件を離れた人も転職した人も、割り当てを外せばその場で入れなくなり、パスワードを知ったままになることはありません。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 個人情報保護委員会の指導事例に出てくる、推測されやすいパスワードと委託先のアカウント 令和 6 年度第 1 四半期の指導 110 件の概要には、事業名を使った簡単なパスワード、4 桁の管理者パスワード、初期設定のままの ID が原因とされた事案が並びます。委託先の監督の不備も 8 件ありました。 更新日: 2026-09-18 個人情報保護委員会は、四半期ごとに「監視・監督権限の行使状況の概要」を公表し、指導した事案を社名を伏せて載せます。令和 6 年 8 月 28 日公表の令和 6 年度第 1 四半期分には、パスワードと委託先のアカウントに関わる事案が繰り返し出てきます。同じ型が何度も指導されている資料です。 ## 何が起きたか この四半期の指導・助言は 142 件で、うち民間事業者が 110 件、行政機関等が 32 件です。民間事業者への指導は、[不正アクセス](/guides/incidents/what-is-unauthorized-access)を原因とする[漏えい](/guides/incidents/what-is-data-breach)が中心でした。委員会は原因の傾向を 3 つにまとめています。直し方が出ていた欠陥の放置、推測されやすい ID・パスワード、設定ミスでデータベースが外から見える状態になっていたことです。 指導の内容のうち関係の深いものは次のとおりです(1 事案が複数に当たることがあります)。 | 指導の内容 | 件数 | | --- | --- | | 外部からの不正アクセス等の防止の不備 | 44 | | 委託先に対する監督の不備 | 8 | | アクセス制御の不備 | 5 | | アクセス者の識別と認証の不備 | 3 | ## パスワードが原因とされた事案 概要に載った事案のうち、パスワードの状態が原因と考えられるとされたものを並べます。番号は概要の事案番号です。 - 事案 14: サーバーの管理者権限のアカウントが複数あり、一部のパスワードが 4 桁だった。 - 事案 18: 写真アプリの利用者アカウントにリスト型攻撃(他のサービスから流出した ID・パスワードで試す攻撃)。利用者のパスワードの使い回し。 - 事案 26〜28: 委託先が管理するアカウントのパスワードが、その事業の名称を使った簡単な文字列だった。 - 事案 31・32: 委託先の仮想専用サーバー(1 台のサーバーを分けて借りるサーバー)で、ファイアウォール(外からの通信を選んで止める仕組み)と ID・パスワードが初期設定のまま。総当たり攻撃(文字の組み合わせを片端から試す攻撃)で突破された。 - 事案 38: VPN 機器(外から社内につなぐための機器)とサーバー管理者アカウントのパスワードが推測しやすく、設定後に変更されていなかった。 - 事案 47: 自治体の委託先のメールアカウントのパスワードが、容易に推測できるものだった。 - 事案 55・56: 管理者アカウントの ID とパスワードが同じ 5 文字・6 文字で、容易に推測できた。 - 事案 61: メール管理システムの管理者アカウントの ID・パスワードを長期間変えておらず、強度にも問題があった。 事案 41 は経路が複雑です。業務委託先 2 社のメールサービスが不正アクセスを受け、そこから委託元の委託先用 VPN のパスワードが盗まれました。さらに、委託元が委託先に配っていた社内システム用のアカウントが悪用されました。原因は、VPN と社内システムで多要素認証(2 つ以上の方法でログインを確かめる仕組み)と接続元の制限が不十分だったこととされています。 ## 委託元に対する指導 委託先のアカウントが原因の事案では、委託元も指導を受けています。事案 26〜28 では、適切な委託先の選定、委託契約の締結、委託先での個人データの取扱状況の把握が不十分で、委託先に対する監督に不備があったとされました。事案 31 でも、契約の締結と取扱状況の把握の不十分さが指摘されています。委託先のパスワードが弱かったこと自体は委託先の問題ですが、確かめていなかったことが委託元の問題として扱われています。 ## 同じ型の事故で一般に問われる管理 個人情報保護委員会のガイドライン(通則編)は、個人情報保護法 25 条の委託先の監督について、委託元が行う措置を 3 つ挙げています。適切な委託先の選定、委託契約の締結、委託先における個人データの取扱状況の把握です。選定では、別添の安全管理措置(個人データを守るための対策)が業務に沿って行われることを「あらかじめ確認しなければならない」(委託先が本当にやっているかを、任せる前に確かめる)としています。上の事案で「不十分」とされたのは、この 3 点です。 IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版の対策例のうち、この事案に関わる 3 つを挙げます。初期設定のパスワードを変更すること。パスワードは 10 文字以上でできるだけ長くし、名前・電話番号・誕生日・簡単な英単語を使わず、推測できないようにすること。従業員の異動や退職時には、速やかに設定を変更・削除することです。 米国 NIST の SP 800-63B(ログインの本人確認についての基準)第 4 版は、サービス側にパスワードを一覧と照合するよう求めています。その一覧に、サービスの名前や利用者名とその変形を入れることも、基準は例として挙げています。事業名を使ったパスワードは、この例に当てはまります。詳細は[パスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案](/guides/incidents/reused-password-list-attack)にあります。 ## 自分の現場を点検する問い 1. 委託先に渡したアカウントのパスワードを誰が決め、初期設定のまま使われていないかを確かめたか。 2. 会社名や事業名、サービス名を含むパスワードが、管理者用のアカウントに残っていないか。 3. 委託契約に、アカウントの扱いと取扱状況の報告を入れているか。契約後に確かめる機会があるか。 4. 委託先が使う VPN や社内システムのアカウントに、2 つ目の確認や接続元の制限があるか。 5. 管理者用のアカウントのパスワードを、設定してから一度も変えていないものはないか。 ## よくある質問 **委託先のパスワードが弱くて漏えいしたら委託元の責任ですか** 概要では、委託先のアカウントが原因の事案で、委託元も選定・契約・取扱状況の把握の不十分さから、委託先の監督の不備を指導されています。責任の範囲は契約と法令によります。 **個人情報保護委員会の指導事例はどこで読めますか** 委員会のサイトに、四半期ごとの「監視・監督権限の行使状況の概要」が PDF で載っています。社名は伏せられ、事案の概要と指導事項が表になっています。 **どんなパスワードが推測されやすいとされていますか** 概要にあるのは、4 桁、ID と同じ 5〜6 文字、事業名を使った文字列、初期設定のままのものです。NIST は、サービス名や利用者名を含むものを、照合する一覧に入れる例として挙げています。 ## 参考資料 - [個人情報保護委員会「令和６年度第１四半期における監視・監督権限の行使状況の概要」(令和 6 年 8 月 28 日)](https://www.ppc.go.jp/files/pdf/240828quarter-report_kengenkoushi.pdf) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf) - [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** 委託先が決めた簡単なパスワードや、初期設定のままのパスワードが自社のアカウントに残ることは、Junify では起きません。決めるのは委託元の管理者で、委託先の担当者には渡らず、見ないまま使います。誰がいつ使ったかは担当者ごとに残り、契約が終われば割り当てを外すだけです。サーバーの公開設定は Junify の外です。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 漏えい等とは(個人情報保護法の報告義務) 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条は、規則で定める 4 つの事態が起きたとき、個人情報保護委員会への報告と本人への通知を義務づけます。 更新日: 2026-09-18 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条 1 項は、そのうち「個人の権利利益を害するおそれが大きいもの」として規則で定める事態が生じたとき、個人情報保護委員会への報告を義務づけています。2 項は、本人への通知を義務づけています。細目は個人情報保護委員会のガイドライン(通則編)の 3-5 にあります。 ## 漏えい・滅失・毀損はそれぞれ何を指すか | 語 | 通則編の定義 | 当てはまる事例 | 当てはまらない場合 | | --- | --- | --- | --- | | 漏えい | 個人データが外部に流出すること | 誤送付・誤送信、設定ミスでインターネット上で閲覧できる状態、書類や媒体の盗難、不正アクセスによる窃取 | 第三者に閲覧されないうちにすべて回収した場合 | | 滅失 | 内容が失われること | 帳票の誤廃棄、社内での紛失 | 同じデータが他に保管されている場合 | | 毀損 | 内容が意図しない形で変わること、または内容は保たれているが使えない状態になること | 改ざん、ランサムウェア(データを暗号化して金銭を要求する不正プログラム)による暗号化 | 暗号化されて復元できなくなった場合で、同じデータが他に保管されているとき | ## どの事態を報告しなければならないか 施行規則 7 条が定める対象は 4 つで、いずれも「発生したおそれがある」場合を含みます。 1. 要配慮個人情報(病歴など)を含む個人データの漏えい等。通則編が挙げる例は、診療情報を記録した USB メモリーの紛失です。 2. 不正に利用されると財産的被害が生じるおそれがある個人データの漏えい等。例は、クレジットカード番号や、決済機能のあるサービスのログイン ID とパスワードの組み合わせです。 3. 不正の目的をもって行われたおそれがある行為による漏えい等。例は、不正アクセス、ランサムウェア、従業者が顧客の個人データを不正に持ち出して第三者に提供した場合です。 4. 本人の数が 1,000 人を超える漏えい等。例は、設定ミスで閲覧できる状態になり、本人の数が 1,000 人を超える場合です。 3 番目の行為の主体には、第三者だけでなく従業者も含まれます。行為の相手方には、個人データの取扱いを委託した委託先も含まれます。退職者が残った ID で入った場合や、委託先の担当者が持ち出した場合は、この事態に当たり得ると読めます。 ## いつまでに、何を報告するか 報告は速報と確報の 2 段階です。速報は、知った後、速やかに(目安は概ね 3〜5 日以内)行い、把握している範囲で 9 項目を報告します。9 項目は、概要、個人データの項目、本人の数、原因、二次被害のおそれ、本人への対応、公表の状況、再発防止の措置、参考事項です。確報は、知った日から 30 日以内(不正の目的をもって行われたおそれがある行為による事態は 60 日以内)に、9 項目のすべてを報告します。判明していない項目は、判明次第追加します。 「知った」時点は、法人ではいずれかの部署が知った時点です。取扱いを委託している場合は、原則として委託元と委託先の双方が報告義務を負い、連名で報告できます。委託先が把握している事項を委託元に速やかに通知したときは、委託先の報告義務は免除されます。 ## 本人にはどう知らせるか 本人への通知は、事態の状況に応じて速やかに行います。内容は、概要、個人データの項目、原因、二次被害のおそれ、参考となる事項に限られます。連絡先がないなど通知が難しい場合は、事案の公表や問い合わせ窓口の設置といった代わりの措置が認められます。 ## 発覚したときに何をするか 通則編は、漏えい等やそのおそれが発覚したら、次の 5 つを行わなければならないとしています。 - 責任者への報告と、被害の拡大の防止 - 事実関係の調査と、原因の究明 - 影響範囲の特定 - 再発防止策の検討と実施 - 個人情報保護委員会への報告と、本人への通知 原因の究明と影響範囲の特定は、誰がいつどのデータにアクセスしたかの記録がなければ進みません。個人情報保護委員会の指導事案には、記録が適切に保管されておらず、調査しても原因を特定できなかった事案があります。 ## よくある質問 **報告の対象にならない漏えいは何もしなくて済みますか** 報告義務は 4 つの事態に限られますが、通則編は、漏えい等やそのおそれが発覚したら、内部報告と拡大防止、調査と原因究明、影響範囲の特定、再発防止の措置を行わなければならないとしています。 **委託先で起きた漏えいは委託元も報告しますか** 原則として委託元と委託先の双方が報告義務を負い、連名で報告できます。委託先が委託元に速やかに通知したときは、委託先は報告と本人への通知を免除されます。 **従業員や退職者の持ち出しも報告対象ですか** 不正の目的をもって行われたおそれがある行為の主体には従業者も含まれ、通則編は従業者が顧客の個人データを不正に持ち出して第三者に提供した場合を報告を要する事例に挙げています。 **速報はいつまでに出しますか** 事態を知ってから「速やかに」で、通則編の目安は概ね 3〜5 日以内です。確報は 30 日以内、不正の目的をもって行われたおそれがある行為による事態は 60 日以内です。 ## 参考資料 - [個人情報の保護に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/415AC0000000057) - [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf) - [個人情報保護委員会「令和 6 年度第 1 四半期における監視・監督権限の行使状況の概要」(令和 6 年 8 月 28 日)](https://www.ppc.go.jp/files/pdf/240828quarter-report_kengenkoushi.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify は、報告に要る「原因」と「本人の数」を絞るための記録の部分を担います。担当者はスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。パスワードは担当者に渡らず、担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 内部不正とは 内部不正とは、役員・従業員・派遣社員などの内部者による、情報の窃取・持ち出し・漏えい・消去・破壊です。IPA のガイドラインは、違法とまでいえない規程違反も含め、退職後に在職中の情報を漏らす行為も内部不正として扱います。 更新日: 2026-09-18 内部不正とは、役員・従業員・派遣社員など組織の内部者による、重要情報や情報システムの窃取・持ち出し・漏えい・消去・破壊です。IPA の「組織における内部不正防止ガイドライン」(第 5 版)は、違法行為だけでなく、内部規程違反など違法とまではいえない不正行為も内部不正に含めます。内部者が退職後に、在職中に得ていた情報を漏えいする行為も、内部不正として扱います。 ## 誰が「内部者」に当たるか 内部者は、経営者・役員、従業員(契約社員を含む)、派遣社員などの役職員と、役職員であった者です。そのうち、情報システムや情報にアクセスする権限を持つ人か、物理的にアクセスしうる職務の人(清掃員や警備員などを除く)の、どちらかに当てはまる人が内部者です。退職者は「役職員であった者」として内部者に入ります。 業務委託(準委任・請負)の委託先は、内部者の定義に挙げられていません。ガイドラインは委託先を別に扱い、対策が弱い委託先から重要情報が漏れないよう、委託時の確認とアクセスできる重要情報の制限を求めています。契約終了時には、委託先に与えていた利用者 ID や権限を削除しなければならない、としています。 ## 対策はどんな考え方に立つか ガイドラインは、犯罪学の「状況的犯罪予防」を内部不正防止に応用し、5 つの基本原則を置いています。 1. 犯行を難しくする: 対策を強化して、不正行為をやりにくくする。 2. 捕まるリスクを高める: 管理や監視を強化して、やると見つかる状態にする。 3. 犯行の見返りを減らす: 標的を隠す、取り除く、利益を得にくくする。 4. 犯行の誘因を減らす: 不正を行う気持ちにさせない。 5. 犯罪の弁明をさせない: 行為者が自分の行為を正当化する理由をなくす。 対策の項目は 10 の観点、33 項目です。観点は、基本方針、資産管理、物理的管理、技術・運用管理、原因究明と証拠確保、人的管理、コンプライアンス、職場環境、事後対策、組織の管理です。文末が「ねばならない」「します」「必要です」の対策は必須と考えられるもの、「望ましい」「望まれます」の対策は、より強化したい場合を想定したものです。 ガイドラインが引く IPA の調査では、営業秘密の漏えいがあった企業の漏えい経路で最も多いのが、中途退職者(役員・正規社員)による漏えい(36.3%)です。 ## アカウントの管理に関わる項目はどれか 「情報システムにおける利用者の識別と認証」は、利用者と管理者の識別に共有 ID や共有のパスワード・IC カードを使わないことを、必須の対策として書いています。一人ひとりの ID を、個別のパスワードなどで認証しなければならない、としています。共有 ID では、内部不正が起きたときに重要情報にアクセスした人を識別できず、行為者を特定できないことが心理的に持ち出しやすい環境を作るためです。他の人に ID やパスワードを貸すことも禁じます。 アクセス権(誰がどこまで使えるかの設定)は、対象の人と権限を必要最小限にし、期間も必要な時期に限り、ID と権限の登録・変更・削除を人事手続きと連携させ、定期的に見直します。委託先の従業員に権限を与える場合は契約上の措置が必要で、異動や退職による削除漏れを防ぐため、体制の変更を委託元に報告させる例を挙げています。 「雇用終了及び契約終了による情報資産等の返却」は、元役職員や契約先に与えていた利用者 ID や権限を削除しなければならない、と定めています。削除は雇用終了の直後に速やかに行い、テレワーク用の権限も含めて削除されたことを確認するよう求めています。雇用終了の間際は持ち出しが起きやすいため、一定期間前からパソコンなどを管理部門の管理下に置くことが望ましい、とも書いています。 ## よくある質問 **退職した人の行為も内部不正ですか** ガイドラインは、役職員であった者を内部者に含め、退職後に在職中に得ていた情報を漏えいする行為も内部不正として扱います。 **委託先の担当者は内部者に入りますか** 業務委託(準委任・請負)の委託先は、内部者の定義に挙げられていません。契約社員と派遣社員は含まれます。委託先は、委託時の確認と契約終了時の ID・権限の削除として別に扱われます。 **共有 ID を使うのは対策上どう扱われますか** 利用者と管理者の識別に共有 ID や共有パスワードを使わず、一人ひとりの ID を個別に認証しなければならない、と必須の対策として書かれています。共有 ID では不正をした人を特定できないためです。 **対策は何から始めますか** 経営者が内部不正対策の基本方針を策定し、方向づけを行わなければならない、がガイドラインの最初の項目です。そのうえで重要情報を区別し、アクセス権(誰がどこまで使えるかの設定)を必要最小限にします。 ## 参考資料 - [IPA「組織における内部不正防止ガイドライン」第 5 版(2022 年 4 月)](https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf) - [IPA「組織における内部不正防止ガイドライン」(公開ページ)](https://www.ipa.go.jp/security/guide/insider.html) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify は、ガイドラインの「利用者の識別と認証」と「雇用終了・契約終了時の ID の削除」に関わる部分を担います。担当者はスマホで本人確認をしてから使うので、共有アカウントでも誰が・いつ使ったかが一人ひとり残ります。パスワードは担当者に渡らず、担当を外れた人は割り当てを外すだけで入れなくなります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # 不正アクセスとは(不正アクセス禁止法) 不正アクセスとは、不正アクセス禁止法 2 条 4 項が定める行為で、中心は、他人の ID とパスワード(識別符号)をネットワーク経由で入力し、制限されている利用ができる状態にすることです。3 条が禁じ、11 条に罰則があります。 更新日: 2026-09-18 不正アクセスとは、不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)2 条 4 項が「不正アクセス行為」として定める 3 つの行為です。中心は 1 号で、他人の ID とパスワード(法律では識別符号)をネットワーク経由で入力してコンピューターを動かし、制限されている利用ができる状態にする行為です。3 条は「何人も、不正アクセス行為をしてはならない」と定め、11 条の罰則は 3 年以下の拘禁刑または 100 万円以下の罰金です。 ## 法律は何を「不正アクセス行為」と呼ぶか 条文の言葉を先に示します。アクセス管理者は、コンピューターの動作を管理する人で、自社のシステムなら自社、外部のサービスならその提供者です。利用権者は、アクセス管理者から利用の許諾を得た人です。識別符号は、利用権者を他の人と区別するために付ける符号で、みだりに第三者に知らせてはならないもの(パスワード)、顔や指紋などの体の特徴や声、署名から作るもののいずれかを含みます。 | 2 条 4 項 | 行為 | 平たく言うと | | --- | --- | --- | | 1 号 | 他人の識別符号を入力し、制限されている利用ができる状態にする | 他人の ID とパスワードでログインする | | 2 号 | 制限を免れることができる情報や指令を入力し、同じ状態にする | 仕組みの弱点を突いて入る | | 3 号 | 別のコンピューターが制限しているコンピューターに、同様の情報や指令を入力する | 別の機器を経由して弱点を突く | 警察庁などの年次資料は、1 号の型を「識別符号窃用型」と呼び、令和 6 年に検挙した不正アクセス行為 533 件のうち 511 件がこの型でした。 ## 他人の ID とパスワードで入るとどう扱われるか 1 号の行為は、誰の ID かにかかわらず、3 条の禁止と 11 条の罰則の対象です。条文は、制限されている利用を「し得る状態にさせる行為」を対象にしており、入った後に何かを見たか、持ち出したかを条件にしていないと読めます。法律は、入る行為の前後にある行為も禁じています。 | 条 | 禁じる行為 | 罰則 | | --- | --- | --- | | 4 条 | 不正アクセス行為に使う目的で、他人の識別符号を取得する | 1 年以下の拘禁刑または 50 万円以下の罰金(12 条) | | 5 条 | 業務その他正当な理由がないのに、他人の識別符号をアクセス管理者と利用権者以外に提供する | 相手の目的を知っていた場合は 12 条、知らなかった場合は 30 万円以下の罰金(13 条) | | 6 条 | 不正アクセス行為に使う目的で、不正に取得された他人の識別符号を保管する | 12 条 | | 7 条 | アクセス管理者になりすまして、識別符号の入力を求める情報を公開する、またはメールで送る(フィッシング) | 12 条 | 令和 6 年の検挙事例には、会社員が勤務先の名刺管理サービスの正規利用権者の識別符号を不正に取得してログインし、識別符号取得行為(4 条)と不正アクセス行為(3 条)で検挙されたものがあります。退職者ではなく、勤務先のサービスに他の利用者の ID で入った事例です。 ## 本人の許可があって使う場合はどう読めるか 1 号の括弧書きは、アクセス管理者自身がする入力と、「当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするもの」を除いています。アクセス管理者か、その ID の利用権者の承諾を得て他人の ID とパスワードを入力する行為は、不正アクセス行為から除かれています。警察庁の解説は、正当な利用の例として、会社の同僚に自分の代わりにメールが着信していないかの確認を頼む場合を挙げています。会社が契約する外部サービスの共有 ID を、会社(利用権者)の許可を得た担当者が使う場合も、この承諾に当たると読めます。 一方で、教える側には 5 条があり、業務その他正当な理由による場合を除いて、他人の識別符号をアクセス管理者と利用権者以外に提供することを禁じています。承諾が誰に、いつまで、どの範囲で与えられたかによって、承諾の外に出た利用がどう扱われるかは、条文だけからは一義に読めません。個別の事案は、事実にもとづいて判断されます。 ## 退職者が在職中の ID で入った場合はどう位置づけられるか 警察庁などの年次資料は、「ＩＤ・パスワードを知り得る立場にあった元従業員、委託先業者等の者による不正アクセス行為が発生している」と書いています。そのうえで、利用する立場でなくなった人の ID の削除かパスワードの変更を、アクセス管理者が速やかに行うよう求めています。自治体の公表にも、退職した小学校の臨時的任用講師が退職後に市のシステムへ不正にアクセスしたとして逮捕された、という例があります。 年次資料は、この削除や変更を防御上の留意事項として挙げています。8 条が求める識別符号の適正な管理に努める義務(罰則のない努力義務)と重なる内容です。 ## よくある質問 **パスワードを教えてもらって入るのは不正アクセスですか** 2 条 4 項 1 号は、アクセス管理者またはその ID の利用権者の承諾を得てする入力を不正アクセス行為から除いています。ただし、教える側には、業務その他正当な理由がない提供を禁じる 5 条があります。 **退職者が元の ID で入るのは犯罪になりますか** 警察庁は、ID・パスワードを知り得る立場にあった元従業員による不正アクセス行為が発生しているとして検挙事例を公表しています。個別の事案が当たるかは、事実と捜査・裁判で判断されます。 **ログインしただけで何も見ていなくても違反ですか** 条文は、制限されている利用を「し得る状態にさせる行為」を不正アクセス行為としており、その後に閲覧や持ち出しをしたことを条件にしていないと読めます。 **自社のシステムを持つ会社は何を求められますか** 8 条は、アクセス管理者に、識別符号の適正な管理と、防御の仕組みの有効性の検証、必要なときの対策に努めることを求めています。罰則のない努力義務です。 ## 参考資料 - [不正アクセス行為の禁止等に関する法律(e-Gov 法令検索)](https://laws.e-gov.go.jp/law/411AC0000000128) - [国家公安委員会・総務大臣・経済産業大臣「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」(令和 7 年 3 月 13 日。令和 6 年分)](https://www.npa.go.jp/bureau/cyber/pdf/R070313_access.pdf) - [警察庁「不正アクセス行為の禁止等に関する法律の解説」](https://www.npa.go.jp/bureau/cyber/pdf/1_kaisetsu.pdf) ## Junify の場合 **人手で続けると** 同じ型の事故を避けるなら、退職や契約終了のたびにその人が使えた ID をすべて止め、共有のパスワードを配り直し、記録を点検する人を決めて回し続けることになります。 **Junify なら** Junify は、他人にパスワードを渡さずに仕事を任せる部分と、外れた人を止める部分を担います。担当者はスマホで本人確認をしてから使い、パスワードは Junify が代わりに入力するので、担当者はパスワードを知りません。担当を外れた人は割り当てを外すだけで入れなくなり、誰が・いつ使ったかは一人ひとり残ります。 Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。 - [登録不要の体験デモを見る](https://www.junify.jp/bpo/try) - [30 分デモを予約する](https://www.junify.jp/bpo/demo) ## 同じテーマの記事 - [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](/guides/incidents/access-between-resignation-notice-and-last-day): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。 - [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](/guides/incidents/agency-google-account-breached): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。 - [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](/guides/incidents/contractor-pc-malware-shared-auth): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。 --- # アカウント管理の用語索引 アカウント管理に関する用語を、読みの五十音順で探せます。 ## あ - [ISMS](/guides/compliance/what-is-isms) — ISMS(情報セキュリティマネジメントシステム)とは: ISMS とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。国際規格 ISO/IEC 27001 に沿って作り、第三者の審査を受けて認証を取ることができます。 - [IT 全般統制](/guides/compliance/what-is-itgc) — IT 全般統制(ITGC)とは: IT 全般統制とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」とされるもので、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理が例に挙がります。 - [ID 管理サービス](/guides/access-basics/what-is-idp) — IdP(ID 管理サービス)とは: IdP(ID 管理サービス)とは、社員の ID を一か所で保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。Okta や Microsoft Entra ID が代表です。 - [アカウントの預かり(運用代行)](/guides/agency-accounts/what-is-delegated-account-access) — 運用代行におけるアカウントの預かりとは: クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。 - [安全管理措置](/guides/compliance/what-is-security-control-measures) — 安全管理措置とは: 安全管理措置とは、個人情報保護法 23 条が事業者に義務づける、個人データの漏えい・滅失・毀損を防ぐ対策です。通則編の別添が、組織的・人的・物理的・技術的の 4 区分と外的環境の把握で内容を示します。 - [委託先の監督](/guides/outsourcing-access/what-is-supervision-of-contractors) — 委託先の監督とは: 個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守る対策)が行われるよう確かめること(個人情報保護法 25 条)。ガイドラインは選定・契約・取扱状況の把握の 3 点を挙げています。 - [医療情報システムの安全管理に関するガイドライン](/guides/healthcare-access/what-is-medical-information-system-security-guideline) — 医療情報システムの安全管理に関するガイドラインとは: 厚労省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。現行は第 7.0 版(令和 8 年 6 月)で、経営層・企画管理者・運用担当者ごとの編に分かれ、認証や記録の遵守事項を示します。 - [オンボーディング・オフボーディング(アカウントの観点)](/guides/hr-access/what-is-onboarding-offboarding) — オンボーディング・オフボーディング(アカウントの観点)とは: アカウントの観点では、オンボーディングは入社・応援の開始に合わせて本人の ID と権限を発行し、共有アカウントを使える人に加えること。オフボーディングは退職・終了に合わせてそれらを止め、共有のパスワードを変えることです。 ## か - [共有アカウント](/guides/shared-accounts/what-is-shared-account) — 共有アカウントとは: 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。 - [緊急用アカウント](/guides/privileged-access/what-is-break-glass-account) — 緊急用アカウント(ブレークグラス)とは: 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。 - [権限付与](/guides/agency-accounts/what-is-delegated-permission) — 権限付与(アカウントを共有しないアクセス)とは: アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。 ## さ - [再委託](/guides/outsourcing-access/what-is-subcontracting) — 再委託とは: 委託先が、受けた業務の全部または一部をさらに別の者に任せること。ガイドラインは、委託元が事前に報告を受けるか承認し、再委託先の安全管理措置まで確かめることが望ましいとしています。 - [最小権限の原則](/guides/access-basics/what-is-least-privilege) — 最小権限の原則とは: 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。NIST が設計の原則として定義し、IPA も ID の割り当てを必要最小限にするよう勧めています。 - [3 省 2 ガイドライン](/guides/healthcare-access/what-is-3-ministries-2-guidelines) — 3 省 2 ガイドラインとは: 3 省 2 ガイドラインとは、厚労省の医療機関等向けガイドラインと、総務省・経産省の事業者向けガイドラインを合わせた通称です。医療情報を扱う側と、そのシステムを提供する側の 2 本で 1 組です。 - [シングルサインオン](/guides/access-basics/what-is-sso) — SSO(シングルサインオン)とは: SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。ID 管理サービスと SAML などの規格でつながるサービスにだけ使え、つながらないサービスには別の方法が要ります。 - [セキュリティチェックシート](/guides/outsourcing-access/what-is-security-questionnaire) — セキュリティチェックシートとは(委託元の側): 委託元が、委託先の安全管理措置(個人データを守る対策)を書面で確かめる質問票。ガイドラインが委託前に求める確認の手段の一つと読めます。設問は別添の項目に沿って作ります。 - [セッション録画](/guides/access-basics/what-is-session-recording) — セッション録画(画面操作の記録)とは: セッション録画とは、ログインしてから終えるまでの利用を、画面の映像や入力した文字として残す仕組みです。何が残り何が残らないかは製品ごとに違い、本人への明示も要ります。 - [ゼロトラスト](/guides/access-basics/what-is-zero-trust) — ゼロトラストとは: ゼロトラストとは、社内ネットワークにいるからといって信頼せず、利用のたびに利用者と端末を確かめてから最小限のアクセスを許す考え方です。NIST SP 800-207 が定義し、総務省は「決して信頼せず、必ず確認せよ」と言い表しています。 - [SOC 2](/guides/compliance/what-is-soc2) — SOC 2 とは: SOC 2 とは、クラウドなどのサービスを提供する会社の内部統制を、公認会計士が AICPA の Trust サービス規準に照らして検証し報告する仕組みです。セキュリティなど 5 つの区分で見ます。 ## た - [多要素認証](/guides/access-basics/what-is-mfa) — 多要素認証(MFA)とは: 多要素認証とは、知っているもの(パスワード)、持っているもの(スマホや IC カード)、本人自身(指紋や顔)の 3 種類のうち 2 つ以上でログイン時に本人を確かめる方式です。パスワードが漏れてもすぐには入られないようにします。 - [特権 ID](/guides/privileged-access/what-is-privileged-id) — 特権 ID(管理者用アカウント)とは: 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。 - [特権 ID 管理](/guides/privileged-access/what-is-pam) — 特権 ID 管理(PAM)とは: 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。 ## な - [内部不正](/guides/incidents/what-is-insider-threat) — 内部不正とは: 内部不正とは、役員・従業員・派遣社員などの内部者による、情報の窃取・持ち出し・漏えい・消去・破壊です。IPA のガイドラインは、違法とまでいえない規程違反も含め、退職後に在職中の情報を漏らす行為も内部不正として扱います。 - [二段階認証](/guides/shared-accounts/what-is-two-step-verification) — 二段階認証(二要素認証)とは: 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。 ## は - [パスワードマネージャー](/guides/shared-accounts/what-is-password-manager) — パスワードマネージャーとは: パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。 - [パスワードレス](/guides/access-basics/what-is-passwordless) — パスワードレスとは: パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。パスキー(FIDO)が代表です。パスワードを見せずに代わりに入力する方式は、パスワードが残るので別の仕組みです。 - [不正アクセス](/guides/incidents/what-is-unauthorized-access) — 不正アクセスとは(不正アクセス禁止法): 不正アクセスとは、不正アクセス禁止法 2 条 4 項が定める行為で、中心は、他人の ID とパスワード(識別符号)をネットワーク経由で入力し、制限されている利用ができる状態にすることです。3 条が禁じ、11 条に罰則があります。 ## ら - [漏えい等](/guides/incidents/what-is-data-breach) — 漏えい等とは(個人情報保護法の報告義務): 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条は、規則で定める 4 つの事態が起きたとき、個人情報保護委員会への報告と本人への通知を義務づけます。 --- # よくある質問 Junify の仕組みや利用条件について、現場ごとのよくある質問にお答えします。 ## BPO・運用代行 ### クライアントのパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### 共有アカウントだと、結局誰が使ったか分からないのでは? クライアント側の ID とパスワードは共有のままでも、Junify にログインするのは一人ひとりの自分のスマホです。だから、誰が・いつ使ったかを担当者ごとに記録できます。 ### パスワード管理ツールとの違いは? パスワード管理ツールは、担当者にパスワードを見せて使わせる道具です。見せたパスワードは回収できません。Junify は見せずにログインさせ、担当を外せばその場で使えなくします。 ### クライアントに SSO を用意してもらえばよいのでは? 受託側がクライアントのシステム設定を変えられるとは限りません。共有アカウントや SSO 非対応のサービスは、それだけでは覆えません。Junify は ID とパスワードだけのサービスでも使えます。 ### 担当者がすでにパスワードを知っている場合は? Junify に登録する際にパスワードを変更し、新しいパスワードを Junify だけが保持する運用を推奨しています。以後は Junify を通してのみログインできます。 ### 二段階認証があるサービスでも使えますか? スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 ### 担当者の私物のパソコンでも使えますか? 使えます。パソコンに入れるのはブラウザーの Junify 拡張機能だけ(スマホには Junify アプリ)。カードから開いた窓は履歴を残さないモードなので、閉じればパスワードも痕跡も残りません。 ### 録画は、誰が付けて、誰が見られますか? 管理者がアカウントごとに決めます。始まる前に担当者本人に表示され、見られるのは本人と管理者だけ。誰が・いつ使ったかの記録は全プラン標準で、画面の録画はスタンダード以上です。 ### 料金は何で決まりますか? Junify を使う担当者の人数です。上限の人数までなら何名でも同じ料金で、クライアントのアカウント数では課金しません。円建ての固定額で、3 つのプランをこのページの「料金」に載せています。 ## 広告・SNS・EC 運用 ### クライアントのパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### クライアントのアカウントに二段階認証があります。 スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 ### SNS や広告以外の管理画面も、同じように使えますか? 使えます。ID とパスワードでログインする Web サービスなら、同じようにカードとして登録できます。Google のアカウントや AI ツールなど、社内で共有しているものも対象です。 ### 在宅や業務委託の担当者の、私物のパソコンでも使えますか? 使えます。パソコンにはブラウザーの Junify 拡張機能、スマホには Junify アプリを入れます。カードから開いた画面は履歴を残さないモードで動き、閉じればパスワードも痕跡も残りません。 ### 担当者の画面を録画すると聞くと、監視のようで気になります。 録画は、管理者が必要なアカウントにだけ付けます。始まる前に本人へ表示され、見られるのは本人と管理者だけです。画面の変化だけを記録する軽い方式で、何かあったときに誰が何をしたかを画面で確かめるためのものです。 ### 担当者ごとに権限を出せる媒体は、それで足りませんか? 出してもらえる媒体では、それを使うのが先です。それでも媒体とクライアントごとに権限を付け外しする作業は残ります。Junify なら一つの場所で管理でき、退職や交代のときは一人分をまとめて外せます。録画も付けられます。 ### 担当者がすでにパスワードを知っている場合は? Junify に登録する際にクライアントと相談してパスワードを変更し、新しいパスワードを Junify だけが保持する運用を推奨しています。以後は Junify を通してのみログインできます。 ### 料金は? Junify を使う担当者の人数で決まります。上限の人数までなら何名でも同じ料金で、クライアントのアカウント数では課金しません。円建ての固定額で、3 つのプランは BPO・運用代行のページに載せています。 ## 医療・ヘルスケア ### 患者情報が写る画面を録画するのですか? 誰が見られますか? 録画は、何かあったとき誰が何をしたかを画面で確かめるためのものです。管理者が必要なアカウントにだけ設定し、始まる前にスタッフ本人に表示されます。見られるのはスタッフ本人と院内の管理者だけです。 ### ビデオ診療が重くなりませんか? なりません。動画を撮るのではなく、画面が変わった部分だけを記録する軽い方式です。 ### スタッフの私物パソコンに、何か入れますか? 何か残りますか? 入れるのはブラウザーの Junify 拡張機能だけ(スマホには Junify アプリ)。開いた画面は履歴を残さないモードなので、パスワードや閲覧の痕跡は残りません。保存したファイルは残るので、可否はアカウントごとに設定。 ### うちの診療システムは ID とパスワードでログインする普通のシステムです。使えますか? はい。診療システム側の設定変更や連携機能は要りません。二段階認証がスマホの認証アプリにコードが出る方式なら、そのコードも Junify が入力します。SMS やメールのコードは対象外です。 ### 診療システムのパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### 医療事務の委託先にも、同じ運用を求められますか? 求められます。委託先のスタッフにも、自院のスタッフと同じ手順で自院のアカウントを使ってもらう形です。委託先と委託元が同じ仕組みで運用している導入例があります。 ### 料金は? 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。円建ての固定額で、クリニックの規模と対象システムに合わせてデモの際にご案内します。 ## 人事・採用 ### 媒体のパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### 媒体側が二段階認証を求めます。 スマホの認証アプリにコードが表示される方式なら、そのコードも Junify が入力します。SMS やメールで届くコードは対象外です。 ### 応募者の個人情報が録画に写ります。 録画は、管理者が必要と決めたアカウントにだけ付けます。見られるのは操作した担当者本人と管理者だけで、始まる前に担当者の画面にその旨を表示します。 ### 担当者のパソコンやスマホに、何を入れますか? スマホに Junify アプリ、ブラウザーに Junify の拡張機能の 2 つです。会社支給でないパソコンでも使え、開いた画面は履歴を残さないモードなので、閉じればパスワードも痕跡も残りません。 ### すでに SSO を導入しています。 SSO(社内の ID でまとめてログインする仕組み)はそのまま。SSO に対応していない媒体や人事系サービスの、ID とパスワードのアカウントだけを Junify に登録します。 ### 人事システムと連携できますか? 「誰がどのアカウントを使えるか」の一覧を、社内の ID 基盤(Entra ID・AD)や SCIM 対応のシステムと同期し、入社・退職に合わせて自動更新できます。対応していないシステムでは CSV で一括更新。 ### 料金は? 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。繁忙期に担当者が増えても、上限までは変わりません。円建ての固定額で、デモの際にご案内します。 ## クラウド運用・特権 ID ### 管理コンソールのパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### 二段階認証が必須のコンソールは? 認証アプリにコードが表示される方式なら、コードも Junify が入力します。SMS やメールで届くコードは対象外です。カードを開けるのはスマホで本人確認した人だけなので、本人のスマホはコンソールの手前に残ります。 ### IP 制限を外す必要がありますか? ありません。通信は担当者のブラウザーと管理画面の間で行われます。Junify はログインの瞬間に ID とパスワードを入力するだけで、経路の途中には入りません。 ### 担当外の人が、急に入る必要が出たら? 管理者がその人にカードを割り当てるだけで、その場で入れます。パスワードを共有し直す必要はありません。必要なのは本人のスマホの Junify アプリとブラウザーの拡張機能だけで、会社支給でない端末でも使えます。 ### 画面の録画は、誰が設定して、誰が見るのですか? 管理者が、必要なコンソールにだけ設定します。始まる前に本人へ表示され、見られるのは本人と管理者だけ。画面の変化だけを記録する軽い方式です。誰が・いつ入ったかの記録(証跡)は、録画とは別に CSV で出せます。 ### Okta などの IdP を使っています。 IdP はそのままです。Junify への本人確認を IdP のログインに任せ、IdP に載らない管理画面と共有の管理者用 ID を Junify で管理する構成にできます。置き換えではありません。 ### PAM 製品やパスワードマネージャーとの違いは? PAM は踏み台に通信を通します。Junify は経路を変えず、ログインの瞬間に入力するだけ。サーバー・OS の特権管理は対象外です。パスワードマネージャーは本人にパスワードを見せますが、Junify は見せません。 ### 料金は? 使う人数の上限が決まったプランで、その範囲なら何名で使っても料金は同じです。円建ての固定額で、運用チームの規模に合わせてデモの際にご案内します。 ## 社内の共有アカウント ### 共有をやめて、個人アカウントにすべきでは? できるものは個人アカウントにするのが先です。それでも、SNS 公式や代表アドレスのようにひとつしかないものは残ります。残った共有アカウントを本人確認してから使う形にし、誰が使ったかを残すのが Junify です。 ### SWA や password-based SSO との違いは? どちらも、パスワードを預けて自動入力はできます。違いはログイン後です。Junify は録画・アップロード検知・ダウンロード制御・遠隔終了をアカウントごとに設定でき、IdP に載せていない人にも同じ記録を残せます。 ### SSO を入れています。意味がありますか? SSO はそのまま。SSO に載らない共有アカウントだけを Junify に登録し、Junify へのログインは既存の IdP に任せる構成にできます。SSO を維持したまま共有アカウントだけを移した導入企業があります。 ### パスワード管理ツールとの違いは? パスワード管理ツールは、パスワードを本人に見せて共有する道具です。いちど見せたパスワードは取り戻せません。Junify は見せずに代わりに入力し、担当を外れたら割り当てを外すだけです。 ### 共有アカウントのパスワードを Junify に預けて大丈夫ですか? 2016 年設立。金融機関・上場企業を含む導入実績。米国の公的なセキュリティ基準(NIST CSF)に準拠した体制。審査時は BCP・セキュリティ文書をご提供。稼働状況は status.junify.com で公開。 ### 会社支給でないパソコンでも使えますか? 何を入れますか? 使えます。必要なのは、自分のスマホの Junify アプリと、ブラウザーの Junify 拡張機能の 2 つ。カードから開いた画面は履歴を残さない窓の中で動くので、閉じればパスワードも閲覧の痕跡も端末に残りません。 ### 料金は? 使う人数の上限が決まったプランで、その範囲なら何名で使っても同じ料金です。円建ての固定額。金額はデモの際にご案内します。