情報漏洩に備えて、データを預ける前に預け先の責任範囲を自分で確かめる

出典: 情報漏洩問題の対策方法（ホリエモン人生のヒント）

最初の30秒で、結論が出る動画です。セキュリティの意識や知識がない普通の会社は、AIで武装した悪い人たちには対抗できない、と冒頭で言い切ります。

堀江さんは0:16でパーク24の名前を挙げ、相次ぐ例として解説すると宣言しました。

なぜ今こんなに起きるのか。答えは「AI」です。

堀江さん（動画の中で・0:26〜）

非常に答えはシンプルです。AIです。これどうして情報漏洩が起きてるかというと実はインターネットに繋がっているシステム、Webのシステムとかっていうのは本当に様々な、え、バグがセキュリティホールが、え、存在しております。

話のはじめの一歩は、穴の話です。インターネットにつながるWebのシステムには、バグやセキュリティホールがある、と動画では言います。

セキュリティホールは、外から入れてしまう穴のこと。見積書を作るクラウドの画面にも、顧客名簿を置いた共有フォルダにも、穴はありえます。

穴があるだけでは、まだ何も起きない。誰かが探して見つけた時に、初めて請求情報や顧客名簿が外へ抜かれる。

冒頭の答えの「AI」は、この探す側の話でした。動画の先では、探す側の壁がAIで下がる話につながります。

一人社長の手元に置き換えます。顧客名簿のフォルダも、見積書を作るクラウドの画面も、今日も昨日と同じ場所。

動いたのは、探しに来る側です。請求情報の保存先が昨日と同じ場所でも、そこへ探しに来る相手の道具が変わったんです。

「AI」と聞いて、自分が使うAIだけを疑うのは、見る場所の取り違えです。請求情報を持っている側の話でもあります。

免許証の写しを1枚だけ預かっている人も、この話の内側にいる。顧客名簿を共有フォルダ1つにまとめているだけの人も、同じ話の中にいる。

次の章は0:47から。穴を塞ぐ作業が毎週のように続く話と、穴を探す人たちの話です。

毎日のように、毎週のように、穴を塞ぎ続ける仕事。顧客名簿や請求情報を載せたWebのシステムにも、0:47からの話のとおり、手を止めてはいけない作業があります。

セキュリティアラートが出たら、パッチ（継ぎはぎのように穴を塞ぐもの）を当てる。それを毎週のように続ける、と堀江さんは言います。

穴を探し回る人は、世の中に大量にいるそうです。集まる場所はダークウェブ（表のインターネットとは表向きにはつながっていない裏のインターネット）。

堀江さん（動画の中で・0:47〜）

なのでパッチというですね、そのセキュリティアラートがあった時にパッチを当てて、パッチっていうような、ま、こう継ぎはぎみたいなもんですけど、穴をこう塞ぐみたいなものなんですけれども、そういったものを当てて、え、もう本当に毎日のように、毎週のようにですね、メンテナンスをしていかなければいけない

2026年7月22日、私が管理するGoogleのGemini APIで「身に覚えのない利用」が見つかりました。17時33分から18時03分の約30分に届いたリクエストは722件で、成功616件、失敗106件でした。

中身は、私の仕事と関係のない画像編集や商品画像の生成でした。動画や音楽の生成も、同じ30分の中に混じっていました。

ぞっとしました。

正規の作業が無かったことや、鍵を隔離したらリクエストが止まったことなど、5点の一次証拠がそろい、「身に覚えのない不正利用」と判断しました。

疑わしい露出経路は2点。ブラウザから直接APIを呼ぶ作りと、鍵を書く設定ファイルをGit（バージョン管理）が追跡していたことでした。

ただ、リポジトリは非公開で、どこから第三者へ渡ったかまでは立証できていません。経緯はGemini APIの鍵が使われた経緯の記事にまとめています。

毎週塞いでも、探す人は大量にいる。顧客名簿を置いた共有フォルダも、見積書を作るクラウドの画面の鍵も、会社の大きさに関係なく探される側に入る。

攻撃できる人の数が急に増えたら、顧客名簿を持つ側には何が起きるのか。動画の2:08からは、天才ハッカー集団と最先端のAIを並べて、話が進みます。

例はAnthropicが作るClaudeのMythos（最先端のセキュリティに特化したAI）。ゼロデイ（人間がまだ見つけていないセキュリティホール）まで次々と見つけている、と堀江さんは話します。

脅威に感じた政府機関等が、公開をいったん止めさせた。まず金融機関や政府機関の穴を見つけてから公開するよう、促す流れだと続けます。

堀江さん（動画の中で・2:08〜）

これまでは本当に天才ハッカー集団しかで攻撃できなかったところを最先端のAIはですね、え、ま、それを容易に突破できてしまうと

壁が下がる、とはこういうことです。以前は専門の集団でないとできなかったことが、道具を持てば広い人にできるようになります。

腕の差が、道具を持つかどうかの差に置き換わります。天才ハッカー集団しかできなかった話は、そう言い直せるかな。

一人社長にとって変わるのは、見積書を作るクラウドの画面を、外から探しに来る相手の顔ぶれです。顧客名簿を狙うのに、専門の集団である必要が薄れます。

請求情報を置いたシステムにも、ゼロデイはありえます。動画が例に挙げたMythosは、その穴まで次々と見つけるAIでした。

先に穴を見つけてもらう先として、動画が挙げたのは金融機関と政府機関です。一人社長の顧客名簿は、その名前の中にありません。

顧客名簿の入ったフォルダも、請求情報の保存先も、金融機関や政府機関の後を待たずに、自分の側で守りを考えることになります。免許証の写しを預かる人も同じです。

サイバー攻撃が増えた理由の解説記事は、AIのせいにする前に、鍵と権限を見直す話を取り上げています。

次の章は2:58から。守る側もAIを使う時代に、自分のサイトの検査が止められる矛盾の話です。

ドローンの飽和攻撃とは、大量のドローンを当てて防御をあふれさせる攻撃のこと。2:58からの動画は、この戦い方を例に、守る側がどんな道具で応じるのかへ話を移します。

ドローンにはドローンで防御するしかなく、高価なミサイルでは割に合わない。だから「AIにはAIを」の時代だ、と堀江さんは言います。

ただ、矛盾がある。ClaudeやOpenAIのGPTなど、表の世界の最先端のセキュリティモデルには、規制が強くかけられていると続けます。

堀江さん（動画の中で・3:39〜）

例えば自分たちのサイトがクラッキングされてないかどうか、あるいは、え、そういったセキュリティホールがあるんじゃないかということをまず[検査]する。ま、つまり、ま、防御をするために[最先端]のセキュリティAIを使うということをしようとすると逆に自分たちで自分たちのサイトに対して[検査]をしてるにも関わらず攻撃しようとしてんじゃないかということでアカウントが[BAN]されたりとかすることが出てきてるわけですね。

攻める側は、規制のない道具を使います。守る側は、自分のサイトを調べただけでBAN（アカウントを止められること）になる場合があるんです。

3:39の例です。穴がないかを調べる場面でした。自分たちのサイトへの検査なのに、攻撃しようとしていると見られてしまいます。

ここは読み分けが要ります。動画の話は、守る側のAIをどこから手に入れるか、という話です。

個人事業主が、自力で検査用のAIを動かす話とは別物です。見積書と請求情報を抱えた一人社長が、明日から始める話ではありません。

では、一人社長が決められるのは何か。手元に持つデータの量と、顧客名簿をどこへ預けるかの2点です。

顧客名簿や見積書を全部手元に置くほど、自分で守る範囲が広がる。預け先を選べば、守る役目の一部を任せることもできる。

任せられる範囲は、ばらばらです。預け先ごとに違います。顧客名簿や請求情報を渡す前に、その範囲を知っておく必要があります。

私ならこうする。検査用のAIを自分で探す前に、手元に持つデータの量を減らし、預け先の選び方に話を戻して考えます。

攻める側にも守る側にも、同じ道具が届くとしたら。動画の4:08からは、OpenAIやAnthropicが作る最先端のモデルから半年ほど経つと、手元で動くモデルが出てくる話です。

動画の話では、最先端のフロンティアモデルから半年ほど経つと、オープンウェイトモデルが開発され、そちらが使われる。インストールして、自分のPCや高性能なPCで使えるモデルのことです。

自分たちを守るには、そちらを使わざるを得ない。そういう時代に「来てるのかな」という言葉で、この話は結ばれます。

堀江さん（動画の中で・4:08〜）

もう半年とかのスパンでクローズドなというか、クローズドに作られた[OpenAI]とか[Anthropic]とかの最先端のフロンティアモデルAIがもう半年も経つとですね、オープンウェイトモデルと言って要はただでインストールできて自分のPCとかで使えるようなあるいは高性能な、え、PCで使えるようなですね、え、そういった[オープンウェイトモデル]があの開発されてそっちが使われてる。

AGI Cockpit（AIの仕事を動かしている私の道具）から手元のQwen 3.6（LM Studio）を動かし、外に出したくないメモ1本を要約しました。

外部検索はなし。189字の要約はできました。外に出したくないメモの一次整理には向きます。

ただ、はみ出しがありました。日付から日数を足した記述です。次にやることを勝手に決めた箇所もあり、原文の抜き出しではなく推論寄りでした。

実行も一発では済みませんでした。最初のコンテキストの大きさ（一度に読ませられる量）が小さくて拒否され、設定のやり直しを含めて15分かかりました。

ここが、動画の話との関わりです。手元のAIは外へ出さずに済みますが、出てきた文が原文どおりとは限りません。

試した中身は、手元のQwenで道具を試した記事とクラウドに送らずに資料を作る話にあります。

2026年7月14日には、Graphify（文書どうしの関係を探す道具）の使い方を決めました。手元のOllamaだけで手動で動かし、外部のAIへは送りません。

私は、わからないことを憶測で埋めません。189字の中の1文でも、原文に無ければ事実とは扱いません。

私ならこうする。要約の抜き出しに足された日数や次の一手は原文に無いので、事実チェックを後ろに置きます。

終わり近くの4:43で、冒頭と同じ主張が戻ってきます。セキュリティの意識や知識がない普通の会社は、AIで武装した悪い人たちには対抗できない、という同じ主張。

だから、クリティカルなデータ（漏れると困る個人情報など）は自分たちで持たない方がいい、と堀江さんは言います。

例に挙がるのは、個人情報やクレジットカード情報。運転免許証や顔写真のデータも入ります。

堀江さん（動画の中で・5:07〜）

持っちゃうとセキュリティホールを常に気にして生きていくしかない。え、そういった状況になってしまうんじゃないかなと思います。え、なので、え、データはできるだけ持たないのが[吉]。クラウドサービスにそれを委託していればその会社が情報漏洩させたことになってこっちは被害者としてお金をま、請求できるあの損害を請求できるんで、え、そういう風に考えた方が正しいんじゃないかなと思いました。

請求できることと、守られていることは別の話です。5:07の話は漏れた後の請求で、漏れる前に何を守るかは、預け先の責任範囲の文で決まっています。

私の鍵の場面は、別の場面です。委託先が漏らした話ではありません。「最も確度が高い」と判断した露出経路は、私の側の作りにありました。

Google側の基本説明は、認証情報の管理は利用者との「共有責任」で、発生した利用は「原則有効な請求」になる、というものでした。

それでもAIに頼んで、発生時間と件数を順に示し、人間の担当者による請求の調整の審査まで進めました。8月28日の時点では、審査中でした。

私の分身AIの元になる文書の禁止事項の一つに、個人情報の漏洩を避け、家族とクライアントの情報は守る、があります。預けても、この線は変わりません。

文書どうしの関係を探す道具に渡す文書は、私が明示選択したMarkdownだけにしています。

鍵そのものの扱いは、AIにパスワードを見せない方法とAIに任せる鍵の数え方の記事で取り上げています。

持つ・預ける・AIに渡すの境界は、最後に私が決めます。顧客名簿のフォルダでも、請求情報の保存先でも、それは同じです。

私ならこうする。手元のデータをひとつずつ、持つ・預ける・AIに渡すのどれかに分けてから、預け先の責任範囲の文を読みます。

堀江さんの結論は、重要なデータは自分で持たず、クラウドに委託するほうがよい、というもの。5:07の話で、委託すれば被害者として請求できると言います。

動画は冒頭と終わりの2回、セキュリティの意識や知識がない普通の会社は、AIで武装した悪い人には対抗できない、と繰り返していました。

私が付け足すのは、1点だけです。顧客名簿や請求情報を預ける前に、預け先が書いた責任範囲の文を、自分の目で読みます。

私の線は、個人情報を漏らさないこと。私の分身AIの元になる文書の禁止事項の一つで、データを預けても、この線は変わりません。

あなたの手元にある顧客名簿や請求情報のうち、預け先が書いた責任範囲の文を一度でも読んだことがあるのは、どれでしょうか。