SaaS、DX、生成 AI——と情報技術の利活用は止まりません。利便性が増す反面、セキュリティやコンプライアンスなど様々なリスクとの向き合い方にも絶えず焦点が当たっています。
今回はその中でも、古典的でありながらも語られづらい「公開」に注目します。この手のインシデントやヒヤリハットとしては「Public のままインターネットに公開してた！」「部門限定なのに全社に公開されてた！」などがあります。
本記事では、これを公開に関するリテラシー（基本的な知識と素養）の欠如と捉えます。可視性リテラシー（Visibility Literacy） と名付けて整理していきます。
※本記事で言及するサービス（Teams や GitHub など）の仕様は、執筆時点のものです。最新の仕様や既定値は変わることがあります。最新につきましては公式情報をご確認ください。
可視性リテラシーとは
デジタルな場に必ず存在する「可視性」に関する基礎知識・基礎素養です。ここで「場」とはデータを置いたり人が集まったりする場所全般を指しています。
場は従来閉鎖的でしたが、クラウドが普及するにつれて、全国に散らばる成員全員やインターネット上と繋がるようになりました。可視性を間違えると、内部で閉じるべきデータを組織全員やインターネット全体に公開してしまう、なんてことが起こり得ます。
このような世界観は、日頃 SaaS を使っている方でも「そんな仕組みになっているのか！？」と驚かれることがあります。私はこのあたりの議論をきちんと言語化し整備していない点に問題意識を抱いており、私なりにやってみようと考えました。
本記事について
教科書的に堅苦しく解説してもわかりづらいので、「原則」という形で並べたいと思います。
原則1: デジタルな場には「可視性」が存在する
可視性(Visibility) とは、その場をどこまで見せるかという設定を指します。
いくつか例を挙げます:
- 例1: Microsoft Teams の「チーム」には以下の可視性があります:
- プライベート: 外（ 組織内全体 を指します）からは見えない。許可された人だけ参加できる
- パブリック: 外からも見える。厳密に言えば「参加すれば見える」「誰でも参加できる」なので「事実上誰にでも見える」
- 例2: GitHub のリポジトリ（個人が持つリポジトリ）には以下の可視性があります:
- プライベート: 自分用。自分以外には見えない
- パブリック: 外（ インターネット全体 を指します）からも見える
- 例3: GitHub のリポジトリ（組織単位に持たせたリポジトリ）には以下の可視性があります:
- プライベート: 組織用。組織内の 全員に見える
- パブリック: 外（ インターネット全体 を指します）からも見える
この可視性設定を間違えると、以下のようなことが起こり得ます:
- Teams チームをパブリックにしてしまうと、たとえ特定部門用のチームであっても組織全体（契約にもよりますがたとえば会社全体）に見えてしまう
- A部門のチームなのに、パブリックになってるせいで別部門の人が参加できてしまう
- 個人リポジトリや組織リポジトリをパブリックにしてしまうと、インターネット全体から見えてしまう
- 万が一機密データを置いていたとすれば、それはインターネット上に公開していることと同義
結論: 可視性の概念は必ず存在すると心得る。「パブリック」のような開放的な設定が高確率で存在することも心得ておく。
原則2: 可視性には「デフォルト設定」がある
デフォルトとは「何もしなかった場合の標準の設定」です。
データを置くためや人が集まるための「場」をつくる際は、可視性の設定項目があります。そこに、たとえばデフォルトでは「パブリック」が指定されていたりします。このままつくってしまうとパブリックになってしまうので、（本当に広く公開したい場合を除けば）プライベートに修正するべきですよね。
あるいは、設定項目が見当たらなかったとしても、設定としては必ず存在します。サービスによりますが、デフォルトでパブリックになっていることもありえます。たとえば GitHub でリポジトリをつくるときは、そもそも元がソーシャルコーディングやオープンソース向けだからか、デフォルトではパブリックになっています。
結論: デフォルトがどの可視性になっているかは必ず確認する。
原則3: 可視性の個々の意味は、サービスによって違う
たとえば Teams における「パブリック」と、GitHub における「パブリック」は別物です。前者は組織内全体ですが、後者はインターネット全体です。
ですので、組織内全体には見せたいが組織の外は（インターネット含めて）見せたくない場合、Teams なら「パブリック」で問題ありません。一方、GitHub でこの塩梅を実現したいなら、組織単位をつくった上でプライベートでつくることになります。プライベートというと組織内であっても関係者にしか見れないと思いがちですが、実際は Teams でいうパブリックと同じようなもので、組織内全員に見える形となっています。
と、このように 可視性の各々の項目（プライベートやパブリックなど。他にもありえます）の意味はサービスによって違います。
結論: 可視性のそれぞれの項目の意味はサービスごとに異なると理解しておく。また、使うサービスごとに、具体的にどんな意味になっているかを理解しておく。
原則4: 可視性の設定は誰かが変えるもの
サービス側のバグでもない限り、可視性が勝手に変わることはありません。可視性は必ずその場をつくった人、あるいはその場に参加していて 可視性を変える権限を持つ人 によってのみ変更できます。
ですので、仮に「勝手に広い範囲に公開されてた！」という場合は、十中八九誰かが可視性を変更しています。あるいは最初からその広い範囲が設定されていたのでしょう。
より具体的に言えば、サービスには 可視性を変更できる権限 なる概念があるはずです。この権限がついている人なら誰でも、いつでも可視性を変更できます。Teams チームの場合は「所有者」の人、GitHub の組織単位の場合は「Owner」の人です。
結論: 可視性の設定は、権限のついた人なら誰でもいつでも変更できる。誰に権限がついているかを確認し、必要なら変更を行う。またメンテナンスも行う。
原則5: 可視性の感覚は触った方が身につく
割と何事も実際に触ってみたり行動してみたりした方が理解しやすいですが、可視性も同様です。
といってもサービス次第では、個人で試したり遊んだりするのも難しいし、もちろん会社の文脈では軽率に試すものでもありません。しかし、可視性についても漏れなく 触ってみた方が身につきます。
本記事の例で言えば、Teams は難しいでしょうが、GitHub であれば私生活で試してみることはできます。自分のアカウントをつくって、リポジトリをつくってみて、可視性を変えてみましょう。その上で、ログインしたアカウントとは別の端末からアクセスしてみて、見えるかどうかを見てみるのです。
GitHub に限らず、場を扱うサービスであれば何でも可視性の設定はあるはずなので、実際に手を動かしてみる機会は意外と確保しやすいです。一番かんたんなのは、X や YouTube その他 SNS 系で、その次がはてなブログなどブログ系・日記系だと思います。どういう設定にしたら、どこまで見えるようになるか、といった世界観がサービスによって全然違います。しかし、大体似たような世界観にはなっていて、次第に肌でわかってくるとも思います。
結論: 何事も経験や手触りというが可視性も同様。個人で何かしらつくって試してみると感覚を掴みやすい。
おわりに
デジタルな「場」を扱うサービスには可視性があります。このあたりの知識や感覚がないと、意図せず広範囲に公開してしまっていた、なんて事故が起きかねません。このあたりの話は整理されてそうで整理されてないと感じたため、本記事にて整理しました。また原則を 5 点挙げる形でシンプルにしました。
参考になりましたら幸いです。