東京都の事務システムに権限設定不備、565人分の個人情報が他施設から閲覧可能に｜攻撃ゼロでも漏えいは起きる——発注側の「権限要件定義」を問う

結論：攻撃者がいなくても漏えいは起きる。疑うべきは「権限要件」と「見えてはいけないもののテスト」だ

東京都は6月10日、看護師等養成施設の事務担当者が利用する都の事務システムで、閲覧権限を持たない施設に関わる個人情報が閲覧できる状態になっていた と公表したと報じられている。対象は 被貸与者437人と連帯保証人128人の計565人分。閲覧可能だった期間は 2026年4月20日9時から5月1日20時ごろ。施設からの指摘で判明し、実際に3施設の4人が権限外の情報を閲覧していた という。

この事案に攻撃者は登場しない。正規ユーザーが正規にログインしただけで、見えてはいけないものが見えた。複数の組織が同じシステムを共用する「マルチテナント型」では、権限設定の不備がそのまま漏えいになる。そしてこの種の不備では、ベンダーの実装ミスだけでなく、発注側の要件定義で「誰が何を見てよいか」が明文化されていたか、受入テストで「見えてはいけないものが見えないこと」を試験していたか が必ず問われる。

取引先ポータル、代理店向け管理画面、共用業務システム——複数の組織が同じ画面にログインするシステムを持つ企業すべてに、同じ構造のリスクがある。

押さえるべき1点：権限不備による漏えいは「攻撃を防ぐ」対策では1件も防げない。防ぐには、要件定義書に権限マトリクスを書き、テスト項目書にネガティブテストを書く必要がある。

事案の概要：正規ログインだけで成立した「漏えい」

注目点は2つ。判明の経緯が 利用者からの指摘 で、システム側の監視では検知できていないこと。そして ログで「誰が・何を閲覧したか」を特定できた こと。操作ログがあったからこそ影響を3施設4人と確定できた。ログ設計の有無は事故後の対応コストと説明責任の質を直接左右する。

攻撃を伴わない漏えいという点では、テスト環境の不備から約2.7万件が露出した阿波銀行の事案（解説記事）と同型だ。

なぜ発注側の問題なのか：権限は「書かなければ作られない」

マルチテナント型システムの権限不備は、開発工程のここで生まれる。

• 要件定義：「施設担当者が貸与情報を照会できる」とは書かれるが、「施設Aは施設Bのデータを参照できないこと」という禁止要件は書かれない。書かれなかった要件は実装もテストもされない
• 実装：正規の画面導線では到達できなくても、検索条件変更・URLパラメータ操作・帳票出力など「特定の操作」で境界を越えられる実装が残る
• テスト：「できることができる」正常系は確認されるが、「できてはいけないことができない」ネガティブテストが項目にない
• 改修・運用：設定変更時に権限への影響が評価されず、リリース後に境界が破れる。本事案も閲覧可能期間が11日間に限られ、変更を契機とした可能性を示唆する

つまり権限不備は実装バグというより 要件とテストの欠落 であり、要件定義書とテスト観点に責任を持つのは発注側だ。丸投げで設計が漏れる構造は発注失敗図鑑：ヒアリング不足・同：検収基準の欠落で指摘したとおり。技術面は壊れたアクセス制御の解説を参照。

発注側チェックリスト：権限要件定義とテナント分離テスト

1. 権限マトリクスを要件定義の成果物にする。「ロール×データ×操作」の表で、見てよい範囲と見てはいけない範囲の両方を明文化する
2. テナント分離のネガティブテストをテスト項目書に入れる。他組織のデータが検索・直接URL・帳票・API・CSV出力のどの経路でも見えないことを受入の合格条件にする
3. 改修・設定変更時の権限リグレッションテストを保守契約に明記する
4. 操作ログで「誰が・いつ・誰のデータを見たか」を追跡できる設計にする。権限外アクセスの検知アラートがあれば利用者の指摘を待たずに気づける
5. 発覚時の手順を決めておく。ログ調査・本人への説明・個人情報保護委員会等への報告要否判断の手順と責任者を事前に定める
6. 稼働中システムに権限診断を実施する。要件漏れと改修の積み重ねで、境界はすでに破れている可能性がある

チェックの勘所：既存システムの保守ベンダーに「権限マトリクスはあるか」「テナント分離のテスト項目はあるか」と聞けば、自社の権限管理の成熟度は今日わかる。両方「無い」なら、本事案は他人事ではない。

二次報道ベースで公開する際の注意

本記事は東京都の個別発表資料を特定できていないため、事案の細部は二次報道に依拠している。そのため、事故原因や責任主体を断定するのではなく、同種システムで点検すべき権限設計・ログ設計・受入テストの観点に絞って読む必要がある。

公開後に東京都の一次資料が確認できた場合は、対象者数、閲覧期間、対応内容、報告・通知の有無を更新する。現時点の実務価値は、個別組織の責任追及ではなく、共用システムを持つ企業が「自社でも同じ境界破れが起きないか」を確認することにある。

よくある質問（FAQ）

Q. 攻撃を受けていないのに「漏えい」として扱う必要があるのか？ A. ある。個人情報保護法の漏えい等報告・本人通知の枠組みでは、不正アクセスの有無ではなく「権限のない第三者が個人データを閲覧した（し得た）か」が問題になる。正規ユーザーでも権限外の閲覧は、本人にとって第三者への漏えいと変わらない。

Q. 権限不備の責任は開発ベンダーと発注側のどちらにあるのか？ A. 契約と要件定義の内容次第だ。権限要件が明記され、それに反する実装ならベンダーの瑕疵を問いやすい。書かれていなければ「仕様どおりに作った」と言われた時点で発注側がリスクを負う。権限マトリクスとネガティブテストを成果物・検収条件に組み込むことが最大の防御だ。

Q. 稼働中のシステムに今からできる点検はあるか？ A. ある。複数ロールのテストアカウントで、検索・URL操作・帳票出力・APIの各経路から他組織データへの到達可否を確認する権限診断が代表的だ。あわせて操作ログの取得範囲と権限外アクセスの検知可否を点検し、定期点検の対象に含めるべきだ。

発注・更改判断に落とすための確認観点

システム開発や基盤更改の記事を読むときは、ニュースそのものよりも自社の要件に変換できるかが重要である。確認すべきは、対象システム、利用部門、業務影響、現行保守の期限、データ移行の難易度、権限・ログ・監査要件、移行中の業務継続方法である。

特にRFPや要件定義では、製品名やベンダー名を先に書くと比較が歪む。先に書くべきなのは、処理量、可用性、権限、監査、移行制約、運用体制である。ニュースをきっかけに検討を始める場合でも、発注書には自社の制約条件を具体化して入れる必要がある。

GXOへ相談する前に整理しておくと早い情報

相談前には、現行システムの概要、利用人数、主要業務、連携先、保守期限、障害履歴、困っている改修、予算感、希望時期をまとめる。詳細な仕様書がなくても、画面・帳票・データの棚卸しから要件を復元できる。

90日で要件定義へ進めるロードマップ

最初の30日は、現行業務と現行システムの棚卸しに使う。画面、帳票、データ、連携、利用者、例外処理、障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書よりも現場の運用が正になっているため、担当者ヒアリングも必要である。

31日目から60日目は、刷新・更改の目的を決める。保守期限への対応だけなのか、業務改善、データ活用、AI導入、セキュリティ強化まで含めるのかで、要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。

61日目から90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限、ログ、監査、非機能、移行、テスト、保守、運用体制を含める。ニュースを見て急いで製品選定に入るより、この90日を使って発注側の物差しを整える方が、失敗コストは小さい。

よくある失敗パターン

第一の失敗は、ニュースをきっかけに製品選定から始めることだ。製品名を先に決めると、要件定義が後付けになり、現行業務の例外や移行制約が漏れる。まず現行業務、データ、権限、帳票、連携、非機能を整理する必要がある。

第二の失敗は、移行を軽く見ることだ。新システムを作るより、現行データを正しく移し、業務を止めずに切り替え、利用者を教育する方が難しいことが多い。移行方式、並行稼働、切り戻し、移行後の照合を要件に入れない発注は危険である。

第三の失敗は、保守運用を見積もりから外すことだ。システムは公開して終わりではない。権限変更、法改正、障害、脆弱性、データ増加、連携先変更に対応する体制が必要になる。初期開発費だけで比較すると、運用で破綻する。

成果物として残すべきもの

発注前には、業務フロー、機能一覧、権限マトリクス、帳票一覧、データ一覧、連携一覧、非機能要件、移行方針、受入テスト方針を残す。完璧な仕様書でなくても、これらがあるだけで見積もりの精度とベンダー比較の質は大きく上がる。

判断表：読むだけで終わらせないための整理

この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。

公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。

いつGXOに相談すべきか

• 取引先・代理店・複数拠点が共用するシステムを持つが、権限マトリクスやテナント分離のテスト項目が存在しない
• これからの発注で、権限設計・ログ設計を要件定義と検収条件に落とし込む支援がほしい
• 稼働中のシステムで権限外アクセスの可否を第三者の目で診断したい

GXOは、DX・システム開発で権限設計・ログ設計を含む要件定義支援と受入テスト設計を、脆弱性診断でアクセス制御診断を提供している。権限不備は要件とテストでしか防げない。→ 相談はこちら

関連記事

• 阿波銀行テスト環境からの2.7万件データ露出に学ぶ「攻撃なき漏えい」
• AI開発発注の失敗図鑑：検収基準がない発注の末路
• システム開発の要件定義テンプレート——発注側が書くべきこと

追加確認：社内展開時の合意形成

社内でこの記事を共有する場合は、単にURLを回覧するだけでは不十分である。関係部門に対して、対象有無、対応期限、必要な判断、次回会議で決めることをセットで伝える。情報共有だけで終わると、誰も担当しないまま時間が過ぎる。

また、対応を急ぐほど、後から見たときの判断根拠が重要になる。なぜ今対応するのか、なぜ今回は見送るのか、どの一次情報を見たのか、誰が承認したのかを簡単に残す。短いメモでも、監査・稟議・次回対応の引き継ぎに使える。

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

• Security NEXT「東京都の事務システムで権限外の個人情報が閲覧可能に」（二次情報）
• 東京都「報道発表（2026年）」一覧ページ

本記事は2026年6月12日時点の公開情報をもとに作成。本事案の事実関係は二次報道（Security NEXT）に基づく。東京都の個別発表資料のURLは執筆時点で特定できなかったため、詳細・最新情報は東京都の公式サイトで必ず確認すること。