【基調講演】なぜセキュリティ&ガバナンスなのか？～自然と安全な仕組みの構築について～

トヨクモが主催する「トヨクモ kintone フェス 2025」のリアルイベントで開催された基調講演をご紹介します。

今回は、国立研究開発法人情報通信研究機構（NICT） ナショナルサイバートレーニングセンター長 園田 道夫氏をお招きし、セキュリティとガバナンスについて語っていただきました。

セキュリティの事件例

本日は、「なぜセキュリティ&ガバナンスなのか? 〜自然と安全な仕組みの構築について〜」というテーマでお話ししていきます。

最初に、セキュリティの事件例をご紹介します。

まず、国の研究所の例では、たった1つの冴えないパスワードがあったことにより、クラウドのアカウントがほぼすべて知られてしまい、一部は完全に乗っ取られて大変な事態になりました。

とある病院では、データが暗号化されてしまい、ベンダーに元に戻す可能性を探らせましたが、その際そのベンダーが怪しい動きをしていて、他に頼もうにもコネもなかったために苦戦したという事例があります。

同じくベンダー関連で、自分たちは厳格にやっていた自治体でも、ベンダーがあり得ないほど適当な管理をしていたために、かなり大変なことになりました。

あとは、大変なことになっているのに、CTOがネットで暴れてしまうなども事件にあたるでしょう。

最後に、あまり派手にニュースとしては報道されていませんが、スポーツ関連では、外注の担当エンジニアが不正行為をしていた事件も起きています。

このように、いろいろな事件が起きているわけですが、ポイントとなるのは、これらをどうすれば防げていたのかという点です。

そもそも防げるものなのか

そもそも、こうしたセキュリティの事件は、何らかの仕組みで防ぐことができるものなのでしょうか。

たとえば、冴えないパスワードぐらいであれば、防げるかもしれません。

でも、ベンダーや外注エンジニアをチェックしきれるのでしょうか。彼らが、自社の機密情報を拡散していたとして、それを察知できるのでしょうか。

そういった、信頼できないベンダーや外注エンジニアが入りこまないように、発注段階から怪しくないことを見極められますか？なかなかの難題だと思います。

CTOがネットで暴れるのは、そもそもCTOがガバナンスの統率者みたいな人なので、ガバナンスでも防げないかもしれません。

どんな仕組みで防げるのか

それでは、どのような仕組みならセキュリティの事件を防げるのか考えていきます。

ベンダーについては、レピュテーションと監査になるのでしょうか。

ただ、他の組織なので「噂や評判などを情報としてかき集めて、自分たちが提示したセキュリティのプロセスを守ってくれているのかチェックする」ぐらいになるでしょう。

レピュテーションも、どこまで信用できるのか難しいところです。

最近だと、大企業のベンダーであっても、地方の支社になると信用できるレベルではなかったという事例も聞きます。

そうなると、本当にスタッフ次第になってくるため、人をどうやって見るかといった話に帰結しますが、相手の組織の人をどこまで見れるのかは分かりません。

そこで出てくるのが、SaaS的なクラウドベースにすることで、いろいろと防げるかもしれないという考えです。

自前オンプレ+エンジニア外注やベンダーは、防ぐ観点からすると難しいのではないかという課題感があります。

逆に、クラウドベースにある程度任せる方が、コストパフォーマンスを含めて、現実的な選択肢になってくるはずです。

オンプレ回帰の流れ

クラウドベースの有用性を話しましたが、今、世の中にはオンプレ回帰の流れがあります。

どうやら、使いこなせないから回帰することが多いらしいのです。

この「使いこなせない」を掘り下げてみると、オーバースペック感、つまりオーバーコスト感につながってきます。

そして、そのオーバーコスト感を払拭するためにオンプレに回帰する流れになるわけですが、果たしてメリット・デメリットの比較や検討はできているのでしょうか。

外注するにしても、自前でシステムを作って運用するのは、かなり大変です。

自前システムは穴が作られやすく、セキュリティ的にもあまりに大変だからこそ、SaaSが出てきてよかったとみなさん安心されているはずです。

それでも、使いこなせないから回帰していくとなると、あえてまた苦難の道に入り込むのかという話になります。

脆弱性作成を抑制するために

セキュリティ業界では、多くの脆弱性は自前のものから生まれるという常識があります。

最近の事情として、2024年度のCVE （公認脆弱性データベース）数は、初めて年間4万件を超えており、これで7年連続で記録更新中となりました。

それだけ、うなぎのぼりに増えている状態なのですが、この理由としては、システムそのものの数が増えていることと脆弱性の発見技術の向上が挙げられます。

さらには、生成AIが脆弱性を自動的に探索することも近い未来できるのではないかと言われています。

ただ、現在では、人間の努力以外で効果的な脆弱性作成の抑制手段はないのが実情です。

テンプレートなどをうまく使いながらコードを書くことにより、脆弱性を回避する方法も見出されてきていますが、これだけ増えている事実を考えると、まだまだ足りません。

そうなったときに、ある意味開き直って、ノーコードに寄せた方が安全なのではないかとも考えられます。

このような横並び比較をしたうえで、それでもまだオンプレに戻りたいのか、自前のコードを書きたいのか、しっかりと考えて方針を決めていくべきです。

ノーコードに弱点はあるのか

それでは、ノーコード側に弱点はないのでしょうか。

こちらは、セキュリティの啓蒙・啓発活動をしている世界的な団体「OWASP」が発表した、ローコード／ノーコードの脆弱性TOP10です。

アカウントのなりすましやデータ漏洩などいろいろありますが、逆に言えば、この項目をうまくカバーできているかどうかのチェックリストとしても使えるのかなと思います。

ただ、私が色付けした項目については、ローコード／ノーコードツール側が何とかしてくれる可能性が高そうではないでしょうか。

ノーコードツール側が賢ければ、システムを作る側があまり気にせずとも、ツールに任せられるものになっていると考えられます。

参考までに、ローコード／ノーコードという枠なしでの脆弱性TOP10はこちらです。

2021年の少し古いデータとなりますが、ローコード／ノーコードのTOP10と共通する要素が多く確認できます。

見ていくと、基本設計やポリシーなどの頭に近い部分で人間が配慮すべきポイントが、色がついていない項目になっているかと思います。

これと合わせると、ローコード／ノーコードツールを使う限りは、作る側は基本設計の部分だけに気をつけて悪者と戦っていけばいいのではないかと考えられるのです。

脆弱性に関する状況の変化

脆弱性に関する状況の変化をお話しします。

まず、先ほども触れたように、既存ツールはまだまだ心許ないですが、生成AIを使った脆弱性自動探索が近未来に来るかもしれません。

2025年5月には、ChatGPT4のo3が、ゼロデイ脆弱性を自動的に発見した事例が出てきました。

※ゼロデイ脆弱性…まだ誰にも知られていないソフトやシステムのセキュリティの穴（脆弱性）のこと

ただ、AIによる脆弱性の自動探索をうまくシステム化できた場合、サイバー攻撃の主原因がコードの脆弱性ではなくなる可能性があります。

コードレベルの穴が減ることにより、攻撃がビジネスロジックや設計の穴狙いに移行していくのではないかと考えられるためです。

そうなると、今後は設計段階でのセキュリティ確保や認証の堅牢化などが焦点になっていくでしょう。

コードに振り回されない体制へ

これまでのセキュリティ対応では、コードに振り回されて足元を掬われている感じがありました。

プログラマーに任せていたら知らないうちに脆弱性が作り込まれていて、それらをテストだけであぶり出すのは中々大変な作業ですし、どうしても漏れは発生してしまいます。

後から発覚したらパッチを作る必要が出てきますし、それをお客さんに配布するのも容易ではありません。

なにしろ、サイバー攻撃を企てる人たちは非常に情報に敏感なので、パッチが公開された瞬間に解析して、脆弱性を見つけ、数時間で世界中に攻撃が広がってしまいます。

防御側は、お客様を安全な状態に保つために、パッチ配布や情報公開のタイミングを慎重に調整しなければならず、振り回されることになってしまうのです。

ところが、これをローコード／ノーコードで構築していると、コード部分はツールの中に隠蔽され、品質保証もツール提供側がしてくれるのです。

そうなれば、コードレベルの脆弱性対応に追われる必要が少なくなり、これまでよりも設計や仕組みづくりといった防御側に注力できます。

このように、今後は設計や認証などにリソースを投じて、防御ノウハウを固めていく方がいいかもしれません。

ガバナンスはセキュリティより難しい

セキュリティとガバナンスを比べてみると、より難易度が高いのはガバナンスだと思っています。

ここでのセキュリティは、コードやシステムといったインフラ的な安全性を指しています。対して、ガバナンスとは組織の統制であり、これが難しいのです。

多くのガバナンス上の問題は、権力やパワーの集中が原因となり生まれます。

そこで対策となるのが分散による相互チェックになるのですが、組織を動かす上では、権限やパワーは集中させざるを得ず、なかなか簡単には分散できません。

さらに言うと、外注エンジニアやベンダーなどが原因となった不正は、ガバナンスによって防げるものなのでしょうか。

また、内部犯行の防止についても難しく、先日、10 年間の不正により 2 億円もの損失があったという事件が、偶然同じ時期に 2 つも出てきました。

そのうちのひとつは大企業でしたが、大企業であっても、10 年間に渡って不正に気付けなかったというということですし、はたして気付ける可能性があったのか、どこで気付けたのか疑問が残ります。 

加えて、内部犯行はビジネスインパクトが大きすぎるのです。

今回の事件であれば、2億円の損害になりますが、その予算は税金やお客さんのお金などから来ています。企業としては、それをどこまで補填するべきなのでしょうか。

これらを考えると、いろんなセキュリティ対策にパワーを割いて忙殺されることはやめて、もっと安全な仕組みを目指していくべきだと思います。

自然と安全な仕組みを目指す

各国のセキュリティ対策状況を出しているレポートによると、アメリカやシンガポールなどの海外の会社では、そこまでセキュリティの人材不足が叫ばれていません。

実は、「セキュリティの人材不足が非常に深刻だ」とアンケートに回答している会社が非常に多いのは、日本だけとなっています。

この理由として、アメリカやシンガポールでは、さまざまなシステムの自動化が進んでいることが挙げられます。

システムの自動化には、当然ながらコーディングの自動化も含まれているため、人間の多大な努力が必要なセキュリティの構築には忙殺されずに済んでいるのです。

ここでポイントとなるのが、生成AIの活用です。

セキュリティの人材不足を感じていないと回答している国は、すでにガバナンスやルール設計などの上位レイヤーへの生成AIの活用を期待しています。

それに対して、日本は攻撃検知や脆弱性の発見など、下位レイヤーへの活用の期待があります。これが示すのは、日本はまだまだ自動化できていないということです。

人間が多大な努力をしてセキュリティ対策に取り組むのは、頑張っている感が出て美しいと感じるかもしれません。

しかし、それは本当に企業として適切なコストとパフォーマンスを発揮しているのでしょうか。

日本の企業は、そういったことを真剣に見直す時期に来ていて、むしろ自動化できるところは、どんどん自動化していくべきだと思います。

そうして、ビジネスロジックの堅牢化やガバナンスの強化などのより難易度の高い方に、もっと頭と予算を割いていく方が生産的なのではないでしょうか。

事件にあてはめて対策を考える

それでは、冒頭にお話ししたセキュリティの事件例にあてはめて、対策や構築すべき仕組みを考えていきましょう。

ノーコードでブラックボックスを作らない

たとえば、外注エンジニアの不正については、ノーコードツールを使って安全に自社開発して、そもそも外注しないという選択はいかがでしょうか。

ビジネスロジックに一番詳しい自社の人間が直接システムを作れることになり、相応しいものが作れるはずです。

仮に外注したとしても、ビジネスロジックのようにプログラマ的な専門性を持つ人以外にもわかりやすい見え方・表現であれば、不正を入れ込む難易度は上がります。

つまり、ブラックボックス化しにくい、シンプルな仕組みにしやすいということです。

ブラックボックスがあると、いろいろな不祥事を招きます。

ガバナンスでお話しした内部犯行も、結局は、どのような処理をしているのかがよく分からないというブラックボックスを作ってしまっているために起きています。

そういったことが起きにくい、シンプルな仕組みにすれば、防止にもつながるはずです。

その代わり、システムとしての柔軟性が欠けるため、どこまでやるべきかという問題が出てきます。

ただ、リスクとのトレードオフで考えれば、断然コストパフォーマンスがよく、対策としても堅牢になるのではないかと思います。

仕組みとして強い認証を作る

次に、たった1つの冴えないパスワードによる事件です。

こちらは、仕組みとして強い認証を作り込むことができれば、パスワード自体が貧弱でも問題ありません。

そして、その強い認証はノーコードツールなどがあれば簡単に導入でき、ユーザーのミスにも対応できるようになるはずです。

今時、パスワードオンリーでのセキュリティはあり得ません。

まとめ

最後にまとめです。

今後、「自然に安全で本業への集中度を上げられるような環境作り」を意識しながら、積極的に考えていく必要があると思っています。

そして、その観点でいろんなツールの導入を吟味することをおすすめします。

結局、本業じゃないところに忙殺されると、本業に集中するパワーが減ってしまうことになり、それだと本末転倒です。

自分たちの優秀なスタッフの力を割く先は、セキュリティなどではなく、事業の展開やアイデアなどの前向きな方向に持っていった方がいいでしょう。

ちなみに、最近は生成AIもレベルの高いコードを書けるようになってきていますが、少なくとも現状はノーコードよりも遥かに使いこなすのが面倒です。

ローコード／ノーコードの方が遥かに簡単でありながら、いいものができる状況で、この差が埋まるのにはもう少し時間がかかると思います。

本日は以上です。ありがとうございました。

ご登壇ありがとうございました

多くの企業が直面しているセキュリティとガバナンスの課題に対し、具体的な事例を交えながら、その本質と対策の方向性について非常に分かりやすくお話しいただきました。特に、「自然と安全な仕組み」を目指すという考え方や、セキュリティの穴を塞ぐためにノーコード/ローコードが有効であるというお話は、私たちに新たな視点を与えてくれました。

多くの工数を要するセキュリティ対策から解放され、本業に集中できる環境を構築するためにも、まずはできることから始めてみませんか？

トヨクモ製品は、セキュリティとガバナンスに配慮した設計思想で作られています。30日間の無料お試しで、安全で効率的な仕組みをぜひご体験ください。

30日間のお試しはこちら

https://www.kintoneapp.com/trial

セキュリティに関するFAQ

■製品のセキュリティ対策を教えてください

https://faq.kintoneapp.com/–67d3fcd8ff637bf794f99d7e

セキュリティに配慮をしながらトヨクモ製品をお使いいただいている企業様の事例はこちらからご覧いただけます。

■契約書照会をはじめとする社内の事務手続きを効率化！直感的なインターフェースで現場メンバーが使いやすい業務システムを構築したSBI証券の事例

https://www.kintoneapp.com/case/sbisec

■学内外の申請業務をkintone連携サービスでペーパレス化！年間約1,800時間の業務時間を削減した長崎大学の活用事例

https://www.kintoneapp.com/case/nagasaki-u