開発セキュリティの入門は、全体像と登場人物とデータが漏れる3パターンから読む

出典：AIでサボろうチャンネル 【知識ゼロでOK】非エンジニアのための開発セキュリティ超入門【保存版】

AIでサボろうチャンネルは、この動画を、開発の知識がなくても全体像から学べるセキュリティ入門だと位置づけます。始まりは、Webサービスにどんな登場人物がいるのかを並べる、地図づくりです。

登場人物は6つ。ドメインという住所を持ち、リクエストしてきた相手に分け隔てなく情報を見せるゾーンを持つサーバー。それを受け取るブラウザ。ユーザーごとの情報をしまうデータベースと、本人かを確かめる認証。他人が書いた便利なコードのセットであるライブラリ。APIキーという鍵がないと使えない外部サービスのAPI。そして開発者です。

AIでサボろうチャンネルによると、起きたら困るのは、データベースから個人情報が盗まれることと、APIキーが盗まれること。漏れ方は、鍵の閉め忘れ、鍵はかけたのにこじ開けられる、人がだまされて乗っ取られる、の3パターンに分けて話されます。

そのうえで、冒頭にこんな前置きが置かれます。

AIでサボろうチャンネル（0:49）

セキュリティにこれだけ守っていれば大丈夫というラインは存在しないのですが、全体像から要所を掴んで対応できるようになっていきましょう。

入門の動画で、最初にこれを言うんだ！と思いました。安心させる一言から始めるほうが、聞き心地はいいはずです。でも、この一文は脅しでもない。地図から要所をつかもう、という順番の話なんですよね。

AIに委ねて、人は積み減らして生き直す。これが私の軸です。ただ、AIに作ってもらった物ほど、6つの登場人物のどこに何を置いたのかは、作った私から見えにくくなる。中身を自分の手で書いていないからです。

だから、登場人物を6つ数えられるだけで違うんです。鍵はどこにあるのか。どこまでが、頼まれれば見せてしまうゾーンなのか。指を差せる場所ができます。

漏れ方の3パターンは、この地図の上を通る3本の道。次の章からの話も、地図のどこで起きているのかを確かめながら読むと、迷いにくくなります。

AIでサボろうチャンネルは、いちばん強い対策は、公開しないこと、ユーザーごとのデータを持たないことだと話します。守り方を考える前に、守る物そのものを減らす。そんな入口です。

例が具体的なんです。社内の数人向けなら、HTMLを1枚配る。自分だけで使うなら、Tailscaleで自分の端末同士だけの回線をつくる。GoogleスプレッドシートとApps Scriptで、同じ組織の人にだけ見せる。公開するなら静的サイトにして、データベースを持たない。社内だけに見せたいなら、Cloudflare Accessのような既製の認証を使う。URLだけで開ける、更新を共有しやすい、という公開のよさも認めたうえで、順番が示されます。

AIでサボろうチャンネル（10:03）

そもそも公開しなくて済まないか、持たなくていいデータを持っていないか、公開するなら手軽に認証をかけられないか、作り始める前にまずはこの順番で考えてみてください。

ここで取り上げるのは、自分のTailscaleの点検です。2026年10月28日に、自分のMacのTailscaleを点検しました。確かめたのはMac 1台。

その一覧に、「Funnel on」と付いた項目が残っていたんです。Funnelは、tailnetの外に向けて公開するための仕組みの名前です。

10月28日の時点で、そういう設定が入っていました。

で、動画の最初の問いは、公開しなくて済まないか。この問いに答えるには、まず自分がいま何を公開しているのかを知っておく必要があります。公開の設定は、一度入れると画面の外に残っていることがある。

守る線の出発点は、自分の端末で何を公開しているかを数えるところです。動画の問いは、作り始めるときの順番であり、すでに作った物を見直す入口にもなります。

ここからがパターン1、鍵の閉め忘れです。AIでサボろうチャンネルは、publicフォルダに置いた物は、URLを知る人すべてに配信されると話します。鍵をかけたつもりで、扉が開いたままになっている話です。

そこに.env（APIキーやデータベースのパスワードを書く設定ファイル）や.gitを置いたまま公開した例が、実際にあるそうです。ブラウザで動くフロントのコードも全員に配られるので、APIキーを書けば開発者ツールで読めてしまう。データベースでは、注文番号を123から124に書き換えると他人の注文が見える形が紹介されます。SupabaseのRLSやFirebaseのセキュリティルールで、作った本人しか読めない決まりを置き忘れた例として、2026年2月のMoltbookも挙がります。

AIでサボろうチャンネル（12:25）

なのでうちは小さいから狙われないは成り立たず公開した瞬間から毎日ドット円部【.env】ありますかと聞かれ続けると思っていきましょう。

冒頭で触れたとおり、私にも鍵の件があります。2026年7月22日、私が管理するGemini APIで、身に覚えのない利用が見つかりました。約30分の間に、リクエストは合計722件でした。

調べて最も疑わしいと判断した経路は、APIキーを示す設定がGitで追跡される.envに入っていて、クライアント側のアプリがブラウザからAPIを直接呼ぶ構成でした。当時の記事に、私はこう書いています。「いやー、サーバーの内側に置くべき鍵を、玄関先まで持ち出してしまうようなものです。」

ただ、リポジトリ自体は非公開。どの経路で第三者に渡ったのかまでは、立証できていません。原因は、いまも言い切れないんです。

動画が挙げた、.envを置いたまま公開した例と、フロントのコードは全員に配られるという説明。私の件で最も疑わしいと判断した構成は、この2つにそのまま重なります。

AIに作業を委ねても、委ねるのは実行です。鍵の置き場所と公開の範囲という守りの線は、人が引くものです。

動画のこの言葉は、私の722件と並べると、他人事には聞こえません！

パターン2は、こじ開けです。AIでサボろうチャンネルは、SQLインジェクションとXSSを、どちらもユーザーが入力した文字が、データではなく命令として扱われてしまう問題だと説明します。

SQLインジェクションはサーバーの側で、XSSは他のユーザーのブラウザで動く。日本のXSSの有名な例として、アラートループ事件も挙がります。プレースホルダなど今どきのライブラリを通せば起きにくく、危ないのは、入力を自分で文字列に継ぎ足して命令やHTMLを組み立てるコードだそうです。Reactには、危険を承知で直接差し込むための機能があって、名前で念押しされている、とも紹介されます。

対策の原則は、1つにまとめられます。

AIでサボろうチャンネル（19:16）

どちらにも共通する対策の原則は1つでユーザーから送られてきたものは全部疑うです。入力された文字はどれだけ普通に見えてもデータとして扱って命令として解釈させないようにしましょう

私はこういう脆弱性の話を読むとき、まず、どんな条件がそろうと起きるのかを探します。

条件が分かれば、自分のコードや端末がその条件に当てはまるかを見に行けます。

この章で言えば、条件は、入力された文字を自分でつなぎ合わせて命令やHTMLにしているかどうか。送られてきたものは全部疑う、という動画の見方は、AIが書いたコードの入口にもそのまま使えます。

では、入口はどこか？AIに作らせた画面に入力欄がいくつあって、そこに入った文字がどこへ流れていくのか。数えるところからでいい。

コードを全部自分で読めなくても、どこを疑えばいいかの見当がつけば、AIに確かめてもらう時の頼み方が変わります。

4章までは、自分の手で書くコードの話でした。5章でAIでサボろうチャンネルが目を向けるのは、他人が書いたライブラリ。動いているコードの大半はライブラリでできている、というのが動画の前提です。

そのうえで、怖さの芯はこの一文にあると話されます。

AIでサボろうチャンネル（21:09）

脆弱性は見つかった瞬間に世界中に公開されるという点で脆弱性が見つかりましたというニュースは直し方と一緒に壊し方も公開されたと同技【同義】なんですね。

例は3つ挙がります。AIでサボろうチャンネルによると、PHP2Shellはログインなしで普通のリクエストを送るだけでサーバー上の命令を動かせてしまう穴で、2012年のPHP 5.4以降のほぼ全部が対象だったとされます。2025年6月のCitrixBleed 2はサーバーのメモリの中身が漏れて、2段階認証も素通りで成りすませた件。2025年3月のNext.jsは、リクエストに1行足すだけで認可のチェックが飛ばされた件です。

対策は、ちゃんと更新すること。気づく手段の1つとして紹介されるのがGitHubのDependabotで、メールで知らせて、更新のプルリクエストまで作ってくれます。セキュリティの更新は既存の動きを壊さないことが多いので、普段から追いかけていれば無理なく上げられる、とAIでサボろうチャンネルは話します。

自分で書いていないコードの穴を、どうやって知るのか？

私はAIに仕事を渡す時、入口の一次情報は何か、出口で誰が意味と責任を持つか、を先に言える状態にしておきたいんです。ライブラリの話に当てはめると、入口は公式の告知と、自分のコードが今どのバージョンを使っているか。ここは人が見に行く場所として残ります。

あいだの調べ物は、AIに任せていい所。告知の中身が自分の構成に当てはまるのか、どのライブラリが影響を受けるのか。量が多くて根気のいる作業ですよね。

で、最後の出口。更新して動かすのか、いったん止めるのか。ここを決めるのは人です。AIが作ってくれたアプリでも、それを公開しているのは自分なので。

しかも、知らせが出た時点で壊し方も知れ渡っている。後回しにした日数の分だけ、扉が開いたままになるわけです。

3つ目のパターンは、だまされること。AIでサボろうチャンネルは、ここで狙われる先がサービスから開発者本人に移る、と話します。

AIでサボろうチャンネル（24:49）

開発者本人が騙されたら終わりです。そして重要な点としてこのパターンに関してはサービスを公開していようがいまいが関係ありません。狙われるのは開発者のPCとそこに入っているアカウントだからです。

中心はサプライチェーン攻撃です。攻撃者がライブラリを乗っ取り、悪いコードを混ぜた新しいバージョンを配る。開発者が更新した瞬間に、情報を盗むプログラムがPCに入る。AIでサボろうチャンネルによると、2026年にはLiteLLMの作者のアカウントが乗っ取られ、不正な版が2つ公開されたとされます。同じ頃にUPSIDERで開発者のPCが侵害された件は、このLiteLLMの件ではないかと動画では推測されています。

教訓は、鍵を付け替えても再び盗まれた点。侵害された端末はネットから切り離し、最終的には初期化する、と話されます。対策は、新しいバージョンを数日待つ（セキュリティの修正版は速やかに上げる）、入れた瞬間に自動で動くpostinstallを止める、ライブラリをむやみに増やさない、の3つ。採用面接を装って課題のコードを動かさせる手口や、野良のスキルとMCPの話も出てきます。動画では、約3万個のスキルのうち約5%が明らかに悪意がありそうだった、と話されます。

ここで取り上げるのは、2026年10月9日にAIへ頼んだことです。パスワードなどを、AIに直接見せない形にしたい。頼んだ文には「AI は見ることができないようなセキュリティをしやすくしたい。」と書きました。

決めた線は次のとおりです。AIには見せない。人がローカルのブラウザで入れて保存し、AIは使うだけ。キーの管理画面は、ローカル限定のページとして作る。同じ日に、そこまでを決めました。

開発者がだまされたら終わり、という動画の話を聞いて、この線の意味がはっきりしたんですよね。鍵を誰が入れるかは、渡す側、つまり人が引く線。一つのAIに全部の情報と権限を渡さず、領域ごとに境界を引くという私の考え方とも重なります。

もう一つ。2026年9月17日に、GitHubで話題になっていたスキル集を、丸ごとは入れないと判断しました。入れると使えるスキルとフックが倍近くに増えて、すでに持っている安全の仕組みと重なり、ぶつかってしまうからです。

野良スキルに気をつけるという動画の話は、悪意への備えです。私が丸ごとは入れなかった理由は、重なってぶつかることでした。

増やすほど、どこに線があるのか見えにくくなる。ライブラリをむやみに増やさないという動画の対策は、スキルにもそのまま当てはまると感じました。

締めくくりに、AIでサボろうチャンネルは学び先を4つ挙げます。1つ目はIPAの「安全なウェブサイトの作り方」。2つ目は徳丸浩さんの定番の書籍で、改訂版が年末に出る予定らしく、急ぎでなければ待つ手もある、と話されます。

3つ目の紹介は、こうです。

AIでサボろうチャンネル（32:28）

3つ目はオアスプトップ10【OWASP Top 10】です。アプリの脆弱性で特に多い10種類をまとめた国際的なリストで気をつけるべき脆弱性のパターンを知ることができます。

4つ目は、Cloudflareが出しているAI向けのセキュリティ診断のスキルのURLを、Claude CodeやCodexに渡して、その通りに診断を頼む方法。AIでサボろうチャンネルは、そう紹介しています。

4つ並ぶと、全部読まなきゃと身構えるかもしれません。

入口になる資料、つまり公式の資料や定番の教科書やリストは、人が選ぶ。それを読ませて自分のコードと照らし合わせる作業は、AIに任せる。ここまでは積み減らせる部分です。

減らさないのは、診断の結果が返ってきた後。それをどう受け取り、何を直すのかは人に残ります。診断スキルが出した答えを、そのまま信じ切らない。動画自身が、これだけ守れば大丈夫というラインは無いと最初に話していましたよね？

積み減らすのは、読む量と照らし合わせの手間。手元に残すのは、受け取って決める所。この線を持っていれば、4つの学び先は重い宿題ではなく、必要な時に引き出す道具になると思います。

AIでサボろうチャンネルの動画は、Webサービスの登場人物から始まり、公開しない・データを持たない、鍵の閉め忘れ、こじ開け、ライブラリの抜け穴、だまされる、の順に進みます。そして、たくさんの手口の後に置かれたのが、この一言でした。

AIでサボろうチャンネル（30:58）

いろんな手口を紹介してきましたが、教訓を1つにまとめるとするなら、他人が書いたコードを自分のPCで動かす時は気をつけろに集約されます。

7つの章の話が、この1行に集まっていくんですよね。

私は、AIに仕事を任せる時の最低条件を「わからないことは憶測しないで聞く。わかることは2度聞かない」と書きました。

AIに作らせたコードも、動かす前にこの線で見ます。何が入っていて、どこへつながるのか。わからないまま動かさない。

鍵の置き場所と、どこまで公開するか。委ねる範囲が広がるほど、この2つは人が決める線として残ります。

あなたに同じ線を押しつけるつもりはありません。AIに任せる前に、15分だけ使って、AIに作らせた物を1つ選び、鍵を置いた場所と公開している範囲を書き出してみる。入口としては、そこがちょうどいいと思います！