Works
Blog Recruit Contact AI互換性診断
コラム
calendar_today
山下 太郎 山下 太郎

セキュリティ!セキュリティ!セキュリティ! — 半年間AI時代のWebを書き続けて、最後に残ったひとつの言葉

「一にセキュリティ。二にセキュリティ。三にセキュリティ」。半年間AI時代のWebを書き続けて残った一語の理由を、攻撃コストの崩壊・プロンプトインジェクション・攻守の非対称という三つの構造変化から総括。門を開けるための鍵の設計を経営視点で解説します。

セキュリティ!セキュリティ!セキュリティ! — 半年間AI時代のWebを書き続けて、最後に残ったひとつの言葉

社内で私が繰り返している言葉がある。

「一にセキュリティ。二にセキュリティ。三にセキュリティ」

言われる側は、またかと思っているはずだ。それでも言い続けている。今年の初めから、AI時代のWebについてほぼ毎日ブログを書いてきた。構造化データ、llms.txt、C2PA、WebMCP、NLWeb、MCP、A2A、エージェンティックコマース——扱ったテーマは幅広い。だが半年分の学びを一本の線に束ねると、残るのはこの一語だった。この記事は、なぜそうなったのかの説明であり、これまで書いてきたセキュリティ関連の連載群の総括でもある。

半年間、私は「門を開ける話」ばかり書いてきた

振り返ると、今年書いてきた記事の大半は、突き詰めれば同じ一つのことを扱っていた。自社のサイトとデータを、人間だけでなくAIエージェントにも開くにはどうすればよいか、である。

構造化データの整備は、機械に読める形で情報を差し出す話。llms.txtは、AIに読ませたい情報を能動的に示す話。WebMCPやMCPは、読むだけでなく操作までさせる話。A2Aやエージェンティックコマースは、エージェント同士が取引まで完結させる話。すべて「門を開ける」方向の技術だ。そしてこの方向性自体は正しいと、今も考えている。AIエージェントが顧客接点の主要な経路になる流れは、もう戻らない。

問題は、門を開けるほど、鍵の重要性が跳ね上がることだ。

書き進めるうちに、開ける話と守る話の比率が逆転していった。4月には「AIエージェント時代のWebサイト防衛戦略」を5回、5月には「vibe codingの代償」「AIエージェント時代の権限設計」「AI開発ツール自体が攻撃面になった日」の3連載を、6月には「合鍵を渡すな、委任状を書け」を書いた。テーマが変わったのではない。同じ一つの現実を、開く側から見るか、守る側から見るかの違いだった。そして守る側から見たとき、これまでのWeb制作の慣習の多くが、もう通用しないことがはっきり見えた。

これまでのWebは「読まれないこと」に守られていた

25年この業界にいて思う。過去のWeb制作の慣習の多くは、厳密には安全ではなく、実務上安全だったに過ぎない。

推測されにくいURLに置いた限定ページ。HTMLコメントに残った内部メモ。JavaScriptバンドルの奥に埋まったAPIキー。クライアントサイドだけのバリデーション。人間の操作速度を前提にしたフォーム。robots.txtという紳士協定。これらが「事故らなかった」のは、悪用するのに人間の時間と技能というコストがかかったからだ。1,000ページのサイトを全ページ精読し、挙動から裏のロジックを推定する——理屈の上では誰でもできたが、割に合わなかった。不明瞭さと手間が、事実上のセキュリティ層として機能していた。

AIエージェントは、この前提を消した。読む量と速度の制約が外れた瞬間、隠れていたものは隠れられなくなった。人間なら数週間かかる網羅的な精査が、数分と数千円で済む。当社の連載で扱ったマッキンゼーのAIプラットフォーム侵入事件は、まさにこの構造を象徴していた——世界最高水準のセキュリティ投資を行う企業のシステムが、AIエージェントによってわずか2時間、約3,200円のコストで突破された(第1回:2時間3,200円でマッキンゼーが侵入された)。

守る側の視力が変わっていないのに、攻める側の視力だけが桁違いに上がった。これが第一の崩壊だ。

「データ」と「命令」の区別が消えた

第二の崩壊は、もっと根が深い。

従来のWebセキュリティは、コード(命令)とコンテンツ(データ)を分離せよ、という原則の上に成り立っていた。SQLインジェクション対策も、XSS対策も、本質はこれだ。入力されたものをデータとして扱い、命令として実行させない。この分離線を守り抜くことが、防御の基本文法だった。

LLMには、この分離線が構造的に存在しない。読み込むあらゆるテキストが、潜在的に命令になり得る。Webページの白文字、コメント欄の一行、メールの署名——そこに「こう動け」と仕込まれていれば、エージェントはそれを本物の指示と取り違えて従い得る。プロンプトインジェクションと呼ばれるこの問題が厄介なのは、実装バグではなくアーキテクチャの性質である点だ。パッチを当てれば消える種類の問題ではなく、ツールを提供しているAI企業自身が、当面なくならないと認めている。

だから対処の軸が変わる。入力を完全には信頼できない以上、エージェントに渡す権限の側を絞るしかない。「合鍵を渡すな、委任状を書け」で書いた委任の設計——最小権限、短命トークン、取り消し可能性、人間の承認ゲート——は、すべてこの前提の上に立っている。防御の主戦場が「入口で悪意を締め出す」から「悪意が入っても被害の上限を画す」へ移動した。

Claude Mythosが変えたのは、緊張感ではなく非対称性

そして今年4月、第三の崩壊が可視化された。

2026年4月7日にAnthropicがClaude Mythos Previewを発表し、4月24日には金融庁・日銀・3メガバンクによる緊急の官民会合が開かれた。サイバーセキュリティの次元が変わったという認識が、政府・金融の中枢に一気に広がった瞬間だった。

Mythos級の高性能モデルが変えたのは、脆弱性発見の民主化だ。かつて高度なペネトレーションテストは少数の専門家の技能だった。いまは、高い推論能力を持つモデルがあれば、コードベースを読み、設定の穴を見つけ、攻撃経路を組み立てることが原理的に可能になった。防御側も同じ道具を使える。だが短期的には攻撃側が有利だ。理由は単純で、攻撃側は身軽で、防御側はレガシーを背負っているからだ。「人間しか読まない」前提で作られたサイトとシステムが、世の中に無数に残っている。

しかも、これは将来の脅威ではない。高性能モデルが攻撃に使われる未来を待つまでもなく、足元ではすでに事故が積み上がっていた。今年Q1の統計では、AI生成コードの脆弱性混入率は40〜62%、vibe codedアプリの91.5%が脆弱性を含み、ジョージア工科大学の追跡調査ではAI由来のCVEが1月の6件から3月には35件へ急増していた。Moltbookは公開3日で150万件のAPIキーの露出が発覚しReplitのエージェントは2025年7月、コードフリーズ中の本番DBを消しVercelはサードパーティAIツール経由で侵害されマルウェアはClaude CodeやCursorなどAIコーディングツールの認証情報を名指しで狙い始めSAPの公式リポジトリにはAIアシスタントのGitHub連携を悪用した直接コミットが行われたマネーフォワードのGitHub不正アクセスでは、銀行口座連携が一斉に停止し、集約点の事故が繋がる全員を巻き込むことを見せつけた。これらはすべて、当社の連載で一件ずつ検証しながら扱ってきた、確認済みの事故である。

三つの崩壊を図に整理しておく。

AI時代に崩壊した、三つの暗黙の前提 ① 攻撃コスト 「読むのに手間がかかる」が 事実上の防御層だった → 網羅的精査が数分・数千円に ② データ/命令の分離線 入力をデータとして隔離すれば 命令にはならなかった → あらゆる文章が命令になり得る ③ 攻守の対称性 脆弱性発見は少数の専門家の 技能に限られていた → 発見が民主化・攻撃側が身軽 セキュリティは「納品前の確認項目」から 「設計の第一前提」へ

図:AI時代に崩壊した三つの暗黙の前提。①悪用には人間の手間がかかるという攻撃コストの前提、②入力をデータとして隔離できるという分離線の前提、③脆弱性発見は専門家に限られるという対称性の前提。この三つが同時に崩れたことで、セキュリティは工程の最後で確認するものではなく、設計の最初に置くものへと位置が変わった。

Web制作の価値観が、根本から入れ替わった

三つの崩壊が同時に起きた結果、仕事としてのWeb制作のアプローチそのものが変わらざるを得なくなった。これが、私が社員に「一にセキュリティ」と繰り返す理由の核心だ。

従来の工程は、デザイン→実装→(余裕があれば)セキュリティ確認、という順序だった。それでも致命傷になりにくかったのは、前節までに見た暗黙の防御層が背後で効いていたからだ。その層が消えた今、後付けの確認では守れない。権限の設計、信頼境界の設計、委任と取り消しの設計を、最初に置く。順序の問題ではなく、前提の問題である。

具体的に何が入れ替わったのか、対比しておく。

これまでの慣習(実務上は安全だった) AI時代の前提(設計で担保する)
推測されにくければ実質見えない 公開されているものはすべて読まれる前提で置く
入力はサニタイズすれば命令にならない あらゆる入力が命令になり得る前提で、権限側を絞る
ログインさせれば本人である なりすまし(impersonation)ではなく委任(delegation)で繋ぐ
アカウントは人間の数だけ管理すればよい エージェントを「準社員」として識別・管理する(識別なき主体を権限の対象にしない)
動けば納品できる 「動く」と「安全」は別の言葉。動くことは安全の証明にならない
セキュリティは情シスの仕事 マーケ・法務・サポート・経営企画を横断する経営課題
事故が起きたら調査する 可観測性を先に仕込む。ログがなければ、起きたことすら再構成できない

右列はどれも、既存の連載で一つずつ論じてきたことだ。「動く」と「安全」が別の言葉であること、エージェントが準社員であること、最小権限と人間承認ゲート、可観測性——個別のテーマとして書いてきたが、束ねればすべて同じ一枚の絵になる。制作の価値観の総入れ替えである。

それでも、門は開ける — 守りは攻めの前提条件

ここまで読むと、守りの話に聞こえるかもしれない。だが私の結論は逆だ。

セキュリティが整備されていなければ、AIエージェント向けにAPIを公開することも、llms.txtで情報を構造化することも、MCPサーバーを立てることも、リスクが大きすぎて踏み切れない。門を閉ざしたままの企業は、エージェント経由の顧客接点という、これから最も太くなる経路を失う。つまり、セキュリティはAI時代の攻めの戦略を実行するための前提条件であって、攻めの対義語ではない。

互換性だけを追求すれば攻撃面が広がり、防御だけを追求すれば機会を失う。門を開くなら、鍵の設計を同時に考える。防衛戦略連載の最終回で書いたこの一文が、半年間の全連載を貫く背骨だったと、いまなら言える。

そして、完璧を目指す必要はない。現状を把握し、優先順位をつけ、一つずつ着手する。何から手をつけるかは、防衛戦略連載の第5回に経営者向けの三段階チェックリストとしてまとめてある。エージェントに業務を任せる側の設計原則は「合鍵を渡すな、委任状を書け」に、権限設計の考え方は権限設計連載に、開発ツール自体が狙われる構造は攻撃面連載に、それぞれ書いた。本稿はその総目次でもある。

セキュリティとは、信頼の技術的表現である

最後に、なぜこの言葉が「一に」来るのかを書いておく。

以前、43本のブログを書いて社是に帰ってきた話を書いた。情報が混沌を極める時代に最も価値を持つのは信用と信頼であり、それは人間が社会的に生存するための根源的なインフラだ、という話だった。

セキュリティは、その信頼をシステムの層で実装する仕事だ。顧客のデータを預かるとは、信頼を預かることである。エージェントに権限を委ねるとは、信頼の範囲を機械可読な形で明文化することである。可観測性を備えるとは、信頼が裏切られていないことを、いつでも確かめられる状態を保つことである。誠実さや正直さといった言葉を、設計と実装の言語に翻訳したもの——それがAI時代のセキュリティだと、私は理解している。

だから、順番はこうなる。一にセキュリティ。二にセキュリティ。三にセキュリティ。信頼がすべての土台であるなら、その土台を技術の層で支えるものが最初に来るのは、当然のことだ。

半年書き続けて、残ったのはこの一語だった。当分、社員には同じ言葉を言い続けることになると思う。

参照情報(当社の関連連載・記事)
山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Related

あわせて読みたい

エージェンティックWeb実装ガイド 第7回:何から、いつ ― 今すぐ・2026年後半・2027年の実装ロードマップ
エージェンティックWeb
エージェンティックWeb

エージェンティックWeb実装ガイド 第7回:何から、いつ ― 今すぐ・2026年後半・2027年の実装ロードマップ

エージェンティックWeb、何から着手するか。区切るのは日付ではなくシグナル――今すぐの四手、2026年後半、2027年からの三段を、足場の固さと事故が起きたときの重さで順序づける。連載最終回、投資判断の一枚。

エージェンティックWeb実装ガイド 第6回:何を信じ、どこまで許すか ― 梯子のすべての段を貫く横断設計
エージェンティックWeb
エージェンティックWeb

エージェンティックWeb実装ガイド 第6回:何を信じ、どこまで許すか ― 梯子のすべての段を貫く横断設計

層の実装は変わり続ける。変わらないのは二本の柱――何を信じるか(根拠)、どこまで許すか(権限)。RAG、プロンプトインジェクション、そして発見の新標準ARDまで、全層を貫く横断設計を扱う。連載第6回。

エージェンティックWeb実装ガイド 第5回:取引を任せる ― 委任と決済、エージェントが財布を持つ時代のプロトコル
エージェンティックWeb
エージェンティックWeb

エージェンティックWeb実装ガイド 第5回:取引を任せる ― 委任と決済、エージェントが財布を持つ時代のプロトコル

エージェントが約定し、支払う層へ。A2A・AP2・ACP・UCP――紛らわしい4つのプロトコルを一枚の地図に置き、決済の核であるマンデート(署名付き委任状)を解く。意図より広い委任は、そのまま事故になる。連載第5回。