関⻄電⼒株式会社 

項⽬ | 内容 

業種 | エネルギー・社会インフラ 

従業員数 | 8,336名(2026年3⽉31⽇現在) 

活⽤サービス | SaaSドック（シャドーIT可視化） 

‍

導⼊前の課題 

「誰が何を使っているか」を確かめる⼿段がなかった 

クラウドサービスの事前審査・申請制度は早くから社内に根付いていた。しかし承認済み台帳と実際の利⽤実態を突き合わせる⼿段がなく、社内監査では「契約はあるが審査を通っていない」サービスが複数発覚していた。 

ネットワーク側の検知では、次のアクションにつながらなかった 

当初検討したCASB製品はIPアドレス単位でしか把握できず、「誰が使っているか」が特定できない。ログを取ることはできても、組織として是正に動くための情報にはならなかった。 

‍

導⼊後の成果 

916件の検知を、対処すべき⼗数件まで絞り込み

SaaSドックで検知した916件を承認済み台帳と突合。「習慣的に使われているか」「業務情報のアップロードを招きやすいか」を軸に分析し、本当に対処すべき⼗数件を特定した。 

推測ではなく、事実でリスクを語れるように 

「シャドークラウドはこの程度」という分析結果を関係役員会議へ報告。⼤きなリスクはなさそうだという事実を持てたことで、正しいリスク管理の⼟台ができた。現場からは、クラウドを使う前に確認の連絡が届くようになった。 

Josysの機能が理解できる資料【5分でわかるJosys】をダウンロードする 

‍

関⻄電⼒株式会社は、国内有数の規模を持つ電⼒会社として、社会インフラである電⼒の安定供給を担っています。原⼦⼒に関する情報から、お客さまの個⼈情報まで、極めて機微な情報を⼤量に預かる同社にとって、情報の「出⼝」の管理は、事業の信頼そのものに直結するテーマです。 

クラウドサービスの事前審査制度は早くから整備していたものの、「申請された内容と、実際の利⽤実態が本当に合っているのか」を確かめる⼿段がありませんでした。今回は、ジョーシスの「SaaSドック」でシャドークラウドの実態把握に取り組んだIT戦略室サイバーセキュリティグループの皆さまに、その取り組みの軌跡を伺いました。

写真左から関⻄電⼒ IT戦略室サイバーセキュリティグループ ⼩林 直⽮ 様、同グループ マネジャー 出原和英 様、同グループ 速⽔ 誠太 様 

‍

「電気は、絶対に⽌められない」。社会インフラが背負う情報セキュリティの重み 

ーー はじめに、御社の事業概要と、社会インフラとしての位置づけについてお聞かせください。 

出原様： 当社は電⼒の発電・販売を担う会社で、国内有数規模の電⼒会社です。電気は、絶対に⽌めてはならないもの。社会的な信頼を背負って働いているという意識が、全社員の前提にあります。 

‍

ーー その責任は、情報セキュリティの領域にはどう表れますか。 

出原様： 電⼒事業の性質上、⾮常に多くのお客さま情報をお預かりしています。だからこそ、その情報を漏らさないという責任は⾮常に重く、万が⼀漏れれば相当に厳しい⽬を向けられることになります。情報漏洩のインパクトは、当社にとって極めて⼤きいと認識しています。社内には、デスクワーク主体の社員もいれば、毎日現場に出ている社員もいる。多様な働き⽅をする組織で、どこか⼀箇所からでも情報が漏れれば、影響は計り知れません。 

‍

ーー 皆さまのご担当領域を教えてください。

出原様： 私たちが所属しているのは、IT戦略室のサイバーセキュリティグループです。名前の通り、社内の情報セキュリティに関する業務を⼀⼿に担当しています。  

‍

ルールはあった。ただ「実態と合っているか」を確かめる⼿段がなかった 

ーー Josys導⼊前、全社で利⽤されるクラウドサービスの申請・管理はどのように運⽤されていましたか。 

出原様： クラウドサービスを利⽤する際は、事前審査を必須としています。取り扱う情報の機密性に応じて、事業者側に求めるセキュリティレベルをランク分けします。たとえば機密性の⾼い情報を扱う場合には、ISMSクラウドセキュリティ認証やFedRAMP認証といった第三者認証の取得を求めます。 

‍

ーー 機密性の区分は、どのように定義されているのでしょうか。 

出原様： ⼤きくは「⾼」と「⾼以外」に分けていて、お客さまに関わる情報や、社会全体に影響が及びうる情報については、「⾼」として扱ってくださいと案内しています。 

‍

ーー 第三者認証を持たない事業者の場合は、どうされるのですか。 

出原様： ⼀律にNGを出すことはしません。第三者認証があれば、その機関によってセキュリティが担保されていると理解できるのですが、ない場合は我々の側から個別に問いを⽴てます。「暗号化していますか」「こういう事象に対応できますか」といった質問をお送りして、回答内容を確認し、当社が求めるセキュリティレベルが担保できているか、確認しています。 

‍

ーー 申請制度の運⽤において、何が課題だったのでしょうか。 

⼩林様： 承認済みのサービス⼀覧は、SharePoint Onlineの台帳で管理していました。ただ、難しさは結局のところ「利⽤実績が分からないため、誰が何を使っているのかの突合せができない」という⼀点に尽きます。

きっかけの⼀つは社内監査でした。当社ではテーマを決めて監査を⾏っていて、クラウド利⽤が対象になりました。監査側は契約情報の台帳と審査済みの台帳を突き合わせていて、「契約はあるけれど、審査済みではないよね」というものがいくつか出てきた。現場にヒアリングをかけると、「使っているが、審査は通していない」というやり取りが実際にあったと聞いています。 

‍

ーー ルールが周知されている中で、なぜそうしたことが起きるのでしょうか。 

⼩林様： 推測になりますが、ルールの整備も周知もしている中で、利⽤者としては「知らなかった」というのがほとんどだと思っています。悪意があるわけではない。だからこそ、実態を把握して、正しく申請に乗せてもらう働きかけが必要でした。 

全社的なリスク対策としては、アップロード制限とコンテンツフィルターを導⼊しています。たとえばアップローダー系のサイトは、ダウンロードはできてもアップロードはできない、という制御をかけている。ある程度の⻭⽌めはできているのですが、それも完璧ではありません。「シャドーITはあるんだろうな」という感覚は、常に持っていました。 

CASBでは届かなかった「⼈」の視点。決め⼿は"⼊れるだけで、ユーザー単位で⾒える"こと 

ーー 過去にネットワーク側からの検知（CASB製品）をご利⽤になった経験について、当時感じられたことをお聞かせください。

出原様： 正直なところ、ログを取って、それで終わってしまいました。製品がダメだったということでは全然なくて、我々の使い⽅が悪かった。ただ結果として、次のアクションには結びつきませんでした。 

⼀番の問題は、プロキシで⾒るとIPアドレスでしか分からないことです。誰が使っているのかがすぐには特定できない。ログイン情報と突き合わせて特定するという話になると、⾮常に⾯倒で、是正アクションにつなげにくかった。 

‍

ーー その経験を踏まえて、ジョーシスを選んだ決め⼿は何でしたか。 

出原様： 2つです。1つは、導⼊が簡単だったこと。もう1つは、⼈（アカウント）で⾒たかったということ。この2点に尽きます。 

拡張機能を⼊れて、ユーザーがログインした状態のまま利⽤状況を⾒る。この⽅式が、我々のやりたいことに対して⼀番早かった。「このIPアドレスは誰なのか」を後から追いかけるのではなく、最初から「誰が、何を使っているか」で⾒える。利⽤が認められていないサー ビスを使っているメンバーに、申請を上げてもらう・利⽤を⾒直してもらうと伝える上で、⼈を軸に管理できることが決め⼿になりました。 

‍

916件の検知。「本当に対処すべき⼗数件」へ 

ーー SaaSドックの実施によって、社内のクラウド利⽤実態はどのように⾒えるようになりましたか。 

⼩林様： 初回のSaaSドックでは、916件のクラウドサービスが検知されました。まず、SharePoint Onlineで管理していた「ちゃんと申請していましたよ」という台帳と突き合わせて、許可済みのステータスを付けていく。その上で、それ以外のサービスを分析対象としました。実際に検知されたユーザーに対してヒアリングをかける、というところまで進めています。 

‍

ーー 916件という数を、どのように絞り込んでいったのでしょうか。 

⼩林様： 通常業務と並⾏しながら、半⽉ほどかけて分析を進めました。単発利⽤や審査不要を除き、⾼頻度で利⽤されているクラウドサービスが141件ありました。この141件を精査し、最終的に対処すべきものは⼗数件にまで絞り込まれました。

‍

ーー 絞り込みの判断軸は、どこに置かれたのでしょうか。 

⼩林様： 実は、ツール側で提⽰されるリスク度合いの⾼い・低いは、結果としてあまり参考にしませんでした。私たちが⾒ていたのは「業務上、どう使われているか」です。 

役に⽴ったのは「3分以上の利⽤」という検知機能でした。3分以上使われているということは、業務として利⽤されている可能性が⾼いということ。そこが分かるのは⾮常に有⽤でした。 

絞り込んだのは、習慣的に利⽤されていて、かつ業務情報のアップロードを招きやすいサービスです。ニュースサイトや検索系、あるいは企業情報を調べるようなサービスは、そもそも情報をアップロードするタイプではないので対象から外しました。当社の定義上、申請しなくてよいものもここでは除いています。 

‍

ーー 個別のサービスは、どのように内容を確認されたのですか。 

⼩林様： 有名なサービスであればすぐに分かりますし、URLベースで検知いただいていたので、実際にURLを覗きに⾏って「こういうサービスか」と確認していきました。141件すべてをそこまで⾒たわけではありませんが、ある程度当たりをつけた後、「これはどうなんだろう」というものは実際に⾒に⾏く。法⼈契約をして使っているのではないか、というものは、聞かないと分からないのでヒアリングの対象にしました。 

‍

ーー 実データを突き合わせてみて、率直にどのような気づきがありましたか。 

出原様： シンプルに、「結構出てくるな」と。致命的な利⽤があったかというと、そこまでのものはなかったという印象です。ただ、細かく⾒ていくと、これだけ出てくるんだな、というのは実感しました。 

⼩林様： もう⼀つ気づいたのは、当社の申請のやり⽅・審査の基準が少し特殊で、「申請を上げなくてもよい」ものがあるということです。その線引きが、実は運⽤の中でかなり難しかった。ここを今後どう整理していくのかは、考えなければいけないところだと思っています。

‍

「⼤きなリスクはない」を、推測ではなく事実として⾔えるようになった 

ーー 可視化された結果に対して、現場部⾨へはどのようなアクションにつなげましたか。 

⼩林様： たとえばAI系のサービスが検知されたケースでは、アンケートをかけました。返ってきたのは「詳しいことを知りたいときにAIに聞いていました」といった内容で、⼤きな問題はないと判断するといった具合に、1件1件リスクの有無を確認していきました。 

出原様： 今回のケースでは大きなセキュリティリスクは確認されなかったため、特別な是正措置は行っていません。ただし、申請が必要なものについては、改めて申請を促す案内を行いました。 

‍

ーー 経営層や上位層への報告に変化はありましたか。 

出原様： 今回の結果は、「シャドークラウドがこれだけ存在していました」という形で関係役員会議に報告しました。現状を把握できたこと、大きなリスクは見当たらないこと、そして今後も継続して監視していく旨を伝えています。 

‍

ーー 申請ベースの管理から、実データに基づく管理へ移行できましたか。 

出原様： 正直に申し上げますと、まだ難しい部分があります。申請ベースの管理そのものは、以前とあまり変わっていません。

というのも、今回は3ヶ月のPoCという位置づけだったため、審査済みステータスによる検知除外機能を積極的に活用していなかったからです。期間が終われば審査済みのステータスも消えてしまうため、ある程度は仕方がないという前提で進めていました。ただ、今年度からは本格的に運用することを決めたので、今後はデータベースとして情報を蓄積していけます。クラウド審査台帳に登録されているものは検知対象から除外するという管理を、今年度から実施する予定です。 

‍

ーー 一度審査を通したサービスは、他部門でもそのまま使えるようになるのでしょうか。 

出原様： そこは難しいところで、基本的には「他のグループで使っているから使ってよい」とはなりません。冒頭で申し上げた通り、取り扱う情報の機密性によって審査基準を変えているため、部門ごとに利用ケースが異なる場合は、個別に審査を受けていただくよう案内しています。 

一方で、IT部門が共通基盤として複数部門に提供しているサービスについては、「このような使い方をしてください」と管理された状態で提供しています。その部分は一括で管理しています。 

‍

現場が変わった。クラウドを使う前に、確認が来るようになった 

ーー マネジメントの立場から見て、チームや現場の動き方に変化はありましたか。 

出原様： 一番大きいのは、見えていなかったものが見えるようになったことです。それ自体に大きな価値があると感じています。クラウド審査のプロセスだけでは把握できなかった部分が、可視化されるようになりました。 

現場とのコミュニケーションでは、副次的な効果がありました。今回、各部⾨に「こういう検知の仕組みを⼊れますよ」と周知しました。それによって、「情報セキュリティ部⾨はクラウド利⽤をここまで厳しく⾒ているのか」ということが、各部⾨に伝わった。 

‍

ーー それが⾏動の変化につながった、と。 

出原様： はい。クラウド利⽤者が、「クラウドは使うだけでも申請が必要なのか」と認識してくれるようになって、事前に聞いてくれるようになりました。組織として、クラウド利⽤に対する考え⽅が少し変わってきたのかなと思っています。

‍

ーー 社内のセキュリティリテラシーについては、どう捉えていらっしゃいますか。 

⼩林様： 正直、すごく幅があります。だから底上げが必要で、全社教育の中で「クラウドを使うときは審査を通してくださいね」と呼びかけています。セキュリティに関する知識の発信も、メールマガジンなどで継続的に⾏われています。最近はAIの利⽤が⼀気に増えてきたので、「AIを使うときはここに気をつけてください」といった切り⼝のほうが、みんなにとっても分かりやすいかもしれません。 

次は「⽌める」ではなく、「バランスをとる」。継続的な管理へ 

ーー 今後、定期的な棚卸しから継続的な管理へ、どのように進めていきたいとお考えですか。 

出原様： アラート機能を使いたいと考えています。クラウド審査台帳と突き合わせて、審査済みのものは検知対象から外した状態を作った上で、まずそうなものが出てきたらすぐ気づける、という形にしたいと考えています。 

‍

ーーセキュリティリスクと利便性のバランスは、どのように考えていらっしゃいますか。

出原様： 会社の成⻑やDXの推進を、阻害したくないんです。牽制を強化しすぎて従業員が委縮してしまっては本末転倒ですし、利便性の確保を妨げることはしたくない。どうしてもトレードオフになる部分はあるので、常にバランスを考えながら進めています。基本は成⻑やDXのためのクラウド利⽤を阻害せず推進するため、クラウド審査によるリスク確認を徹底させたい。リスクの⼤きなもの、リスク確認が済んでいないものだけを⽌めていく、という考え⽅です。 

‍

同じく社会インフラを担う、IT責任者の皆さまへ 

ーー 最後に、同じ課題を抱える読者へメッセージをお願いします。 

出原様： 当社は原子力関連の情報に加え、個人情報も取り扱っております。非常に機微な情報を大量にお預かりしているという認識です。 

そのような状況下で懸念されるのは、「どこから情報が流出しているのか把握できない」という事態です。だからこそ、出口対策は極めて重要になります。今回の取り組みを通じて、その出口がある程度可視化されました。 

導入前は、正直なところ「情報流出につながるようなクラウド利用が見つかるのではないか」という懸念もありました。しかし実際に確認したところ、PoC期間中の範囲内では、直ちに重大と判断すべき利用は確認されませんでした。この「事実に基づいてリスクを正しく評価できる」という点は、非常に大きな成果だと感じています。 

適切なリスク管理を行うための土台が整いました。その意味で、非常に有益な取り組みだったと考えています。今後もこうした取り組みを少しずつ進めていきたいですね。