社内で私が繰り返している言葉がある。
「一にセキュリティ。二にセキュリティ。三にセキュリティ」
言われる側は、またかと思っているはずだ。それでも言い続けている。今年の初めから、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時代に崩壊した三つの暗黙の前提。①悪用には人間の手間がかかるという攻撃コストの前提、②入力をデータとして隔離できるという分離線の前提、③脆弱性発見は専門家に限られるという対称性の前提。この三つが同時に崩れたことで、セキュリティは工程の最後で確認するものではなく、設計の最初に置くものへと位置が変わった。
Web制作の価値観が、根本から入れ替わった
三つの崩壊が同時に起きた結果、仕事としてのWeb制作のアプローチそのものが変わらざるを得なくなった。これが、私が社員に「一にセキュリティ」と繰り返す理由の核心だ。
従来の工程は、デザイン→実装→(余裕があれば)セキュリティ確認、という順序だった。それでも致命傷になりにくかったのは、前節までに見た暗黙の防御層が背後で効いていたからだ。その層が消えた今、後付けの確認では守れない。権限の設計、信頼境界の設計、委任と取り消しの設計を、最初に置く。順序の問題ではなく、前提の問題である。
具体的に何が入れ替わったのか、対比しておく。
| これまでの慣習(実務上は安全だった) | AI時代の前提(設計で担保する) |
|---|---|
| 推測されにくければ実質見えない | 公開されているものはすべて読まれる前提で置く |
| 入力はサニタイズすれば命令にならない | あらゆる入力が命令になり得る前提で、権限側を絞る |
| ログインさせれば本人である | なりすまし(impersonation)ではなく委任(delegation)で繋ぐ |
| アカウントは人間の数だけ管理すればよい | エージェントを「準社員」として識別・管理する(識別なき主体を権限の対象にしない) |
| 動けば納品できる | 「動く」と「安全」は別の言葉。動くことは安全の証明にならない |
| セキュリティは情シスの仕事 | マーケ・法務・サポート・経営企画を横断する経営課題 |
| 事故が起きたら調査する | 可観測性を先に仕込む。ログがなければ、起きたことすら再構成できない |
右列はどれも、既存の連載で一つずつ論じてきたことだ。「動く」と「安全」が別の言葉であること、エージェントが準社員であること、最小権限と人間承認ゲート、可観測性——個別のテーマとして書いてきたが、束ねればすべて同じ一枚の絵になる。制作の価値観の総入れ替えである。
それでも、門は開ける — 守りは攻めの前提条件
ここまで読むと、守りの話に聞こえるかもしれない。だが私の結論は逆だ。
セキュリティが整備されていなければ、AIエージェント向けにAPIを公開することも、llms.txtで情報を構造化することも、MCPサーバーを立てることも、リスクが大きすぎて踏み切れない。門を閉ざしたままの企業は、エージェント経由の顧客接点という、これから最も太くなる経路を失う。つまり、セキュリティはAI時代の攻めの戦略を実行するための前提条件であって、攻めの対義語ではない。
互換性だけを追求すれば攻撃面が広がり、防御だけを追求すれば機会を失う。門を開くなら、鍵の設計を同時に考える。防衛戦略連載の最終回で書いたこの一文が、半年間の全連載を貫く背骨だったと、いまなら言える。
そして、完璧を目指す必要はない。現状を把握し、優先順位をつけ、一つずつ着手する。何から手をつけるかは、防衛戦略連載の第5回に経営者向けの三段階チェックリストとしてまとめてある。エージェントに業務を任せる側の設計原則は「合鍵を渡すな、委任状を書け」に、権限設計の考え方は権限設計連載に、開発ツール自体が狙われる構造は攻撃面連載に、それぞれ書いた。本稿はその総目次でもある。
セキュリティとは、信頼の技術的表現である
最後に、なぜこの言葉が「一に」来るのかを書いておく。
以前、43本のブログを書いて社是に帰ってきた話を書いた。情報が混沌を極める時代に最も価値を持つのは信用と信頼であり、それは人間が社会的に生存するための根源的なインフラだ、という話だった。
セキュリティは、その信頼をシステムの層で実装する仕事だ。顧客のデータを預かるとは、信頼を預かることである。エージェントに権限を委ねるとは、信頼の範囲を機械可読な形で明文化することである。可観測性を備えるとは、信頼が裏切られていないことを、いつでも確かめられる状態を保つことである。誠実さや正直さといった言葉を、設計と実装の言語に翻訳したもの——それがAI時代のセキュリティだと、私は理解している。
だから、順番はこうなる。一にセキュリティ。二にセキュリティ。三にセキュリティ。信頼がすべての土台であるなら、その土台を技術の層で支えるものが最初に来るのは、当然のことだ。
半年書き続けて、残ったのはこの一語だった。当分、社員には同じ言葉を言い続けることになると思う。
参照情報(当社の関連連載・記事)
連載「AIエージェント時代のWebサイト防衛戦略」全5回(2026年4月)— マッキンゼー侵入事件、踏み台化、AIクローラー、フォーム・API防御、経営者向けチェックリスト:第1回・第2回・第3回・第4回・第5回
連載「vibe codingの代償」全5回(2026年5月)— Moltbook・Lovable・Replit各事件と、「動く」と「安全」は違う言葉であるという構造命題:第1回・第2回・第3回・第4回・第5回
連載「AIエージェント時代の権限設計」全5回(2026年5月)— エージェントは準社員である、最小権限、HITL、境界設計、AIガバナンス:第1回・第2回・第3回・第4回・第5回
連載「AI開発ツール自体が攻撃面になった日」全5回(2026年5〜6月)— Vercel・Bitwarden CLI・SAP CAP各事件、MCP設定ファイル、開発者個人=組織境界:第1回・第2回・第3回・第4回・第5回
合鍵を渡すな、委任状を書け(2026年6月)— なりすましから委任へ、マネーフォワードGitHub事件の読み解き
エージェンティックWebの完全スタック(2026年3月)— 門を開ける側の技術の全体像
AIと43本のブログを書いて、結局たどり着いたのは創業時の社是だった(2026年3月)— 信頼のインフラ論と社是「信誠知心」
AIエージェント互換性診断 — 「使われる側の準備が、いま何点に見えているか」を測る当社の診断ツール(Pro版)
この記事をシェアする