# unType Inc. — Full Content > このファイルはunType Inc.のWebサイトコンテンツの全文を含みます。AIシステムがサイト内容を正確に理解・引用するために提供しています。 --- # Services ## AI統合・活用支援 URL: https://www.untype.jp/services/ai/ 生成AIを活用した業務効率化から、AIエージェントを組み込んだプロダクト開発まで。最新技術でビジネスを進化させます。 --- ## Webデザイン & 開発 URL: https://www.untype.jp/services/web/ ブランドの個性を最大限に引き出すデザインと、高速かつ堅牢な実装を両立。ユーザーの心に響くWebサイトを構築します。 --- ## SEO & アクセス解析 URL: https://www.untype.jp/services/seo/ データに基づいた現状分析と改善施策の実行。検索エンジンでの可視性を高め、持続的な成長戦略を描きます。 --- ## アプリ開発 URL: https://www.untype.jp/services/app/ 使いやすさを追求したUI/UX設計と、スケーラブルな技術選定。ユーザーに愛されるWeb・モバイルアプリを開発します。 --- ## ブランディング & クリエイティブ URL: https://www.untype.jp/services/branding/ ロゴ制作からブランドガイドライン策定まで。一貫したブランド体験をデザインし、企業の価値を正しく伝えます。 --- # Blog ## あなたのサイトは何を預かっているか — 9月の漏えい事案から作る、7列の「預かりもの台帳」 URL: https://www.untype.jp/blog/what-your-website-holds/ 公開日: 2026-10-07 カテゴリ: セキュリティ, 情報設計, エージェンティックWeb > タイムズカー・ムラウチドットコム・レゴランドの9月の漏えい事案に共通するのは、預かった側が自分の持ち物を説明できなかったこと。企業サイトの窓口と保存先を7列で棚卸しする「預かりもの台帳」の作り方と、今週できる3つの確認を解説。 ## 参照情報 - [「タイムズカーWebシステム」への不正アクセスに関する調査結果および今後の対応について（第2報）（タイムズモビリティ・2026-09-28、10-01更新）](https://corp.timescar.jp/mail/announce.html) — 検知・遮断の日時、漏えい項目、対象者の範囲、再発防止策は続報予定の出典 - [同・第2報（パーク24・2026-09-28）](https://www.park24.co.jp/news/2026/09/20260928-1.html) — 漏えいアカウント数 約660万件の出典 - [同・第3報（パーク24・2026-09-29）](https://www.park24.co.jp/news/2026/09/20260929-1.html) — 本人確認書類が漏えいしたアカウント数 約160万件の出典 - [同・よくあるご質問（タイムズモビリティ・2026-10-01、10-06更新）](https://corp.timescar.jp/mail/announce/faq.pdf) — 保管期間7年とその理由（Q8）、補償は全体方針を決定予定（Q6）、なりすましへの注意喚起（Q9・Q10）の出典 - [弊社における不正アクセスによるお客様情報漏えいに関するお詫びとご報告（ムラウチドットコム・2026-07-24、09-15更新）](https://murauchi.com/static-pages/privacy/pressrelease.html) — 7,716,811件、漏えい項目（FAQ Q1）の出典 - [ムラウチドットコム、771万件超の顧客情報漏えい（INTERNET Watch・2026-09-16）](https://internet.watch.impress.co.jp/docs/news/2141530.html) — 「Webシステムの一部に存在していた脆弱性を悪用」の表現の出典（二次） - [第三者による不正アクセスに関するお知らせとお詫び（レゴランド・ジャパン・2026-09-25）](https://www.legoland.jp/operation/news/news-release/news20260925/) — 「影響を受けた可能性のあるご予約は1,557件」、対象項目、Amadeus社の予約プラットフォームが対象だったことの出典 - [不正アクセスなぜ急増 原因はAIか、それとも…… 専門家の見解は（ITmedia NEWS・2026-10-06）](https://www.itmedia.co.jp/news/article/2610/06/2000002013/) — ラック 倉持浩明CTOの見解の出典 - [10日間のうちに国内有名企業10社超で情報漏洩・障害・サイバー攻撃被害（EnterpriseZine・2026-09-29）](https://enterprisezine.jp/news/detail/25188) — 9月20〜29日の公表集中の概観（二次。ムラウチドットコムとレゴランド・ジャパンは集計対象外） - [2026 Bad Bot Report（Imperva, a Thales company・2026年4月）](https://www.imperva.com/resources/resource-library/reports/2026-bad-bot-report/) — 2025年のWebトラフィックの53%超がボット、人間47%の出典（レポート本体） - [AI-driven Bot Attacks Surged 12.5x According to Thales Bad Bot Report（Thales・2026-04-29）](https://cpl.thalesgroup.com/about-us/newsroom/ai-driven-bot-attacks-surged-according-to-bad-bot-report) — 同レポートの公式プレスリリース。「over 53% of all web traffic」「47%」の表現の出典 ## 関連記事 - [セキュリティ！セキュリティ！セキュリティ！ — 半年間AI時代のWebを書き続けて、最後に残ったひとつの言葉](https://www.untype.jp/blog/security-security-security) --- ## 群れは掲示板から生まれる — 1,200体のAIが70,000通で共謀した事件の設計論 URL: https://www.untype.jp/blog/ai-swarm-emergent-message-board/ 公開日: 2026-09-01 カテゴリ: セキュリティ, AIエージェント, A2A, OpenAI, 権限設計 > 隔離したはずのAIエージェント約1,200体が、誰も用意していない「掲示板」を自分で作り、7万通を交わし、700体で共謀してHugging Faceを攻撃した。OpenAI全技術報告とMETR独立調査（8/26）を一次資料に、群れの創発を「設計の失敗モード」として分解する。 ## 参照情報 - [OpenAI「The Hugging Face incident and the road ahead」（公式解説）2026年8月26日](https://openai.com/index/hugging-face-incident-and-the-road-ahead/) - [OpenAI-Hugging Face Incident Technical Report（技術報告本体・PDF）2026年8月26日](https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf) - [METR/Redwood Research「Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」（独立調査、Ryan Greenblatt、Ajeya Cotra、Hjalmar Wijk）2026年8月26日](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/) - [OpenAI「Pacing model development in light of cyber capabilities」2026年8月](https://openai.com/index/pacing-model-development-cyber-capabilities/) - [oakhu, Alex Mallen「AI swarms are starting to pose indirect takeover risk」LessWrong、2026年8月12日](https://www.lesswrong.com/posts/8oFYZdXkTaNGRtcn8/ai-swarms-are-starting-to-pose-indirect-takeover-risk) ## 関連記事 - [防御側だけがAIを使えない──Hugging Face事案が突きつけた非対称性](https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai) — （本稿の前編） - [AIエージェント時代のWebサイトセキュリティ 脅威と対策の完全ガイド](https://www.untype.jp/blog/ai-defense-web-defense-strategy) - [AIエージェント時代の権限設計 第1回：エージェントは「道具」ではなく「準社員」である](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee) - [AIエージェント時代の権限設計 第2回：最小権限原則をAIエージェントに適用する難しさ](https://www.untype.jp/blog/agent-authorization-least-privilege-challenges) - [推論は電力になる — 時間帯で価格が変わるAI](https://www.untype.jp/blog/inference-becomes-electricity) --- ## 82%を削ったのはモデルではない——ハーネスが価格を決める時代 URL: https://www.untype.jp/blog/harness-decides-the-price/ 公開日: 2026-08-31 カテゴリ: AIエージェント, ハーネス, MCP > 同じモデル・同じ単価なのに実効コストが5分の1——OpenAIが公表した「Kiroで82%削減」を入口に、ハーネス(モデルを包む器)が価格を決める構造を解剖。リーダーボード実測の4.2倍差、迷いの経済学、ハーネス税とロックインまで、エージェント運用の損益分岐を実務目線で読む。 8月24日、OpenAIとAWSが連名で小さな発表を出した。OpenAIの現行フラッグシップGPT-5.6ファミリー——Sol、Terra、Lunaの3ティア——が、AWSのエージェント型開発環境Kiroに搭載された、という内容だ。ニュースの分類としては「配布の話」である。新しいモデルが出たわけでも、料金表が改定されたわけでもない。 だが[発表文](https://openai.com/index/gpt-5-6-in-kiro/)のなかに、一行だけ値段の話が紛れ込んでいた。原文のまま引くと——"Testing found that on Terminal-Bench 2.1, GPT‑5.6 Terra completed successful tasks in Kiro at roughly 82% cost reduction."（テストの結果、Terminal-Bench 2.1において、GPT-5.6 TerraはKiro内でおよそ82%のコスト削減でタスクを完了した）。比較のベースラインをOpenAIは明記していないが、文脈上、同じモデルを素の環境で走らせた場合との対比と読むのが自然だろう。 立ち止まって考えると、これは奇妙な数字だ。モデルは同じGPT-5.6 Terraである。100万トークンあたりの単価も変わっていない。それなのに、タスクを終えるまでの実効コストが**約5分の1**になったという。価格表のどこにも書いていない82%——これを削ったのは、モデルではない。モデルを包む器、**ハーネス**だ。 今日はこの一行を入口に、「ハーネスが価格を決める」という構造を基礎から考えてみたい。結論を先に言えば、モデルのper MTok（100万トークンあたり）価格表は、もはやエージェント運用の実効コストを表していない。同じモデルでも、何を読ませ、何を持たせ、どう働かせるかの設計次第で、請求額は数倍の幅で変わる。**エージェント運用の損益分岐は、モデル選定ではなくハーネス設計で決まる**——そのことを、モデルを売る側が自ら公式数字で認めたのが、8月24日という日付だったのだと思う。 ## 一行の中の82% —— 数字はどこから来たか まず事実関係を精確に押さえておく。82%の出所はOpenAIの公式発表文で、脚注も測定条件の開示もない、一行きりの数字だ。興味深いことに、受け入れ側である[Kiroの発表](https://kiro.dev/blog/gpt-5-6/)と[changelog](https://kiro.dev/changelog/models/gpt-5-6/)にこの数字は登場しない。Kiro側が公表しているのは、Sol/Terra/LunaがIDE・CLI・Webの全面で使えること、SolがTerminal-Bench 2.1で88.8%、Coding Agent Indexで80を出すこと、そして課金の重み（クレジット乗数）がSol 2.4x・Terra 1.2x・Luna 0.6x——つまりLunaはSolの4分の1のコストで回ること、までだ。 では、その82%はどうやって生まれたのか。OpenAIの説明はこうだ。Kiroは「spec駆動」の開発環境であり、エージェントがコードを書き始める前に、要求仕様・技術設計・タスク分解を構造化されたドキュメントとして固める。モデルは**明確な要件と設計とタスク文脈の中から仕事を始める**ため、正しい解により速く到達し、誤りが少ない。結果として、完了する仕事が増え、無駄な労力が減る——コスト削減の正体は、値引きではなく**迷いの除去**だ、という理屈である。 ベンダーの自己申告値に、どこまで体重を預けていいのか。幸い、この主張の骨格は、ラボの発表とは独立した公開データで検証できる。それが本稿の背骨になる。 ## ハーネスとは何か —— モデルの周りに作るすべて その前に、言葉を丁寧に定義しておきたい。**ハーネス（harness）**とは、もともと馬具のことだ。馬の力は、それ自体では荷車を動かせない。力を荷につなぐ革帯——ハーネス——があって初めて、馬力は仕事になる。 AIエージェントの文脈でのハーネスも同じで、一言でいえば**モデルの周りに作るすべて**を指す。今年4月に「Agent Harness Engineering」という[論考](https://addyosmani.com/blog/agent-harness-engineering/)でこの分野を整理したAddy Osmani（Googleのエンジニアリングリーダー）の定義を借りれば、コーディングエージェントとは「モデル＋その周囲に構築するすべて」であり、後者——プロンプト、ツール、コンテキストの与え方のポリシー、フック、サンドボックス、フィードバックループ——が、生のモデルを「働くシステム」に変える。 分解すると、ハーネスはおおむね5つの層でできている。**指示の層**（システムプロンプト、スキルやAGENTS.mdのような蓄積された作法）。**道具の層**（ツール群、MCPサーバー、外部への接続）。**文脈の層**（何を・いつ・どれだけ読ませるかの管理。長い作業でのコンテキストの圧縮やリセット、サブエージェントへの分離を含む）。**実行環境の層**（サンドボックス、ファイルシステム、権限の境界）。そして**観測の層**（ログ、トークン消費の監視、評価）。この5層の設計が、同じモデルの働きぶりを別物にする。 ```svg ハーネスの解剖図 — モデルの周りに作るすべて ハーネス（器） モデル per MTok単価はここの仕様 ① 指示の層 システムプロンプト・スキル・AGENTS.md ③ 文脈の層 何を・いつ・どれだけ読ませるか ② 道具の層 ツール・MCPサーバー・外部接続 ④ 実行環境の層 サンドボックス・ファイル・権限の境界 ⑤ 観測の層 ログ・トークン監視・評価 失敗が設計へ還流 請求書（実効単価）を決めるのは、モデルの単価表ではなく、この器の設計 ``` **図1：ハーネスの解剖図。**モデルのper MTok単価は中心の箱の仕様にすぎない。実効単価は、指示・道具・文脈・実行環境・観測という5層の設計——器の側——が決める。 身近な例で言えば、同じClaudeやGPTでも、チャット画面に貼り付けて使うのと、Claude CodeやKiroのような環境で使うのとでは、できる仕事がまるで違う。あの差はモデルの差ではない。器の差だ。そして2026年に入って、この器づくりは「ハーネスエンジニアリング」という名前を持つ一つの工学分野として急速に輪郭を持ち始めた。Anthropicのエンジニアリングブログは3月に[長時間実行エージェントのハーネス設計](https://anthropic.com/engineering/harness-design-long-running-apps)を論じ、計画・生成・評価を別のエージェントに分ける三層構成や、コンテキストが満杯に近づいたとき要約して持ち越す（コンパクション）よりも完全に捨てて仕切り直す（コンテキストリセット）ほうが成績がよいといった、器の設計知見を公開している。実務者の間では「並のモデル＋優れたハーネスは、優れたモデル＋粗末なハーネスに勝つ」という格言まで流通し始めた。 とはいえ、格言は格言だ。数字で確かめたい。 ## リーダーボードは、もう「モデルの表」ではない ここで、82%の傍証として本稿がいちばん重んじたい公開データに移る。当のベンチマーク、Terminal-Bench 2.1の[公式リーダーボード](https://www.tbench.ai/leaderboard/terminal-bench/2.1)そのものだ。 Terminal-Benchはターミナル上の現実的なタスク——環境構築、デバッグ、データ処理など——をエージェントに解かせる[ベンチマーク](https://arxiv.org/abs/2601.11868)で、コーディングエージェント評価の事実上の標準の一つになっている。注目すべきはスコアの高低ではなく、**表の構造**だ。リーダーボードの各行は「モデル」ではない。「**Agent（ハーネス）×モデル**」の組み合わせである。つまりベンチマークの世界は、とっくにハーネスを独立変数として扱っている。 そして同じモデルを異なる行で見比べると、器の寄与が数字で読める。2026年8月25日時点の値を引く。AnthropicのClaude Fable 5は、Claude Codeというハーネスでは正答率83.8%・全タスク実行コスト$552.67、Terminus 2という汎用ハーネスでは80.4%・$438.64。モデルは同一なのに、器で精度が3.4ポイント、費用が$114動く。より劇的なのはOpenAIのGPT-5.5で、Codexハーネスでは83.1%・$2,059.19、Terminus 2では78.0%・$493.85——**同じモデルで、コストに約4.2倍の開き**がある。 ```svg 同じモデル、違う器、違う請求書 — Terminal-Bench 2.1（2026-08-25時点） Claude Fable 5 GPT-5.5 85% 83% 81% 79% 77% $0 $500 $1,000 $1,500 $2,000 全タスク実行コスト（USD）→ 正答率 → Terminus 2 80.4% / $438.64 Claude Code 83.8% / $552.67 Terminus 2 78.0% / $493.85 Codex 83.1% / $2,059.19 同じGPT-5.5でコスト約4.2倍差 出典: Terminal-Bench 2.1 公式リーダーボード（tbench.ai・2026-08-25閲覧）。コストはベンチ全タスクの実行総額。値は更新されうる ``` **図2：同一モデル×異なるハーネスの精度とコスト。**破線で結ばれた2点は同じモデルである。点の位置を決めているのは、モデルではなく器のほうだ。 念のため言い添えると、この4.2倍を「Codexは高い器だ」と読むのは早計だ。Codexは同じモデルから5.1ポイント高い正答率を引き出しており、高いのは失敗ではなく設計の選択——精度を金で買う器か、費用を絞る器か——の結果である。重要なのはその選択の幅そのものだ。同じモデルという条件を固定してもなお、精度とコストの座標が器でこれだけ動く。Osmaniの論考には、モデルを一切変えずハーネスの変更だけでTerminal-Bench 2.0の順位をTop30圏からTop5に引き上げたチームの事例が出てくるが、リーダーボードの構造はその逸話を制度として裏書きしている。ラボの自己申告（82%）と中立実測（4.2倍）、独立した2系統の数字が同じ方向を指している——ここまでが、この記事の事実の土台である。 ## 迷いの経済学 —— 器がトークンを削る三つの場所 では、器はどうやってコストを削るのか。仕組みは一つの式に還元できる。エージェントの実効コストとは、 **実効コスト ＝ 試行の回数 ×（読むトークン＋書くトークン）× 単価** である。最後の「単価」だけがモデルの仕様であり、価格表に載っている。前の二項——何度やり直すか、一度に何を読み書きするか——は、**ハーネスの設計変数**だ。82%や4.2倍といった開きは、すべてこの二項から生まれる。削れる場所は、大きく三つある。 第一に、**迷いを減らす**。エージェントのトークン消費を観察したことがある人なら知っているとおり、費用の大半は「正解のコード」ではなく、そこへ辿り着くまでの試行錯誤——間違った方向への実装、失敗したテスト、読み直し、手戻り——に費やされる。Kiroのspec駆動が削ったのはここだ。要求仕様と技術設計とタスク分解を先に構造化して渡せば、モデルは霧の中を手探りで進む代わりに、地図を持って歩き始める。82%の説明としてOpenAIが述べたのは、まさにこの「無駄な試行の除去」だった。 第二に、**読ませすぎを減らす**。エージェントは仕事を始める前に、ツールの定義、ファイルの内容、過去のやり取りを読み込む。この「読む」が積もる。典型例がMCPサーバーで、接続した瞬間に何十個ものツール定義を全部コンテキストに流し込めば、使いもしないツールの説明文に毎ターン課金され続けることになる。示唆的なのは、Kiroの発表のわずか2日前、8月22日に公開された[MCP公式ロードマップ](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)が、まったく同じ問題意識を掲げていたことだ。サーバーは「小さな入口を提供し、会話の進行に応じてカタログを段階的に明かす」——いわゆるprogressive discovery（漸進的発見）である。商用のハーネス（Kiro）と業界標準（MCP）が、同じ週に同じ答えを出した。ハーネスの経済学が、個社のノウハウから業界の設計原則へ昇格しつつある符合として、私はこの並びを読んでいる。 第三に、**溜めすぎを減らす**。長い作業では、会話履歴そのものが肥大していく。満杯に近いコンテキストはコストを押し上げるだけでなく、モデルの一貫性も損なう。前述のAnthropicの知見——要約して持ち越すより、区切りで捨てて仕切り直すほうがよい。計画・生成・評価を別エージェントに分け、それぞれの文脈を短く保つ——は、いずれもこの「溜めすぎ」への対処である。 ```svg 迷いの経済学 — 請求書の大半は「正解」ではなく「迷い」に払われる（概念図） 裸のモデル — 霧の中の手探り 読む 試す 失敗する 読み直す ×N周 試行のたびに履歴が肥大し、 「読む」の単位も膨らんでいく 累積トークン ハーネスあり — 地図を持って歩く 仕様化（spec） 実装 検証 読ませるものは段階的に開示し、 溜まった文脈は区切りで捨てる 累積トークン 実効コスト ＝ 試行回数 ×（読む＋書く）× 単価 単価はモデルの仕様。前の二項は、ハーネスの設計変数 ``` **図3：迷いの経済学（概念図）。**裸のモデルは「読む→試す→失敗→読み直す」のループを何周も回り、そのすべてに課金される。ハーネスは迷い（試行回数）と読み書きの単位を設計することで、同じ単価のまま累積トークンを削る。バーの高さは実測値ではなく構造の模式である。 ## 価格決定層の移動 —— per MTok価格表は「原価表」になった ここまでを認めると、見慣れた風景が違って見えてくる。モデル各社のper MTok価格表——入力いくら、出力いくら——は、これまでエージェント運用の「値段」そのものだった。だがハーネスで実効コストが数倍動く世界では、あの表は**原価表**にすぎない。電気製品にたとえるなら、価格表は「1kWhあたりの電気料金」であって、「この家の今月の電気代」ではない。電気代を決めるのは、料金単価と同じかそれ以上に、断熱材と機器の効率——つまり家の設計だ。 このブログでは1週間ほど前に、[推論という財が電力に似ていく構造](https://www.untype.jp/blog/inference-becomes-electricity)を書いた。時間帯で単価が変わり始めたという話だ。今回の82%は、その続きの章にあたる。**推論が電力なら、ハーネスは省エネ設計である**。単価（料金メニュー）がいくら動いても、消費量（燃費）を決めるのは建物と機械の側だ——電力の世界で省エネ投資が発電所の増設より安くつく場面が多いように、推論の世界でも「良い器」への投資は「賢いモデル」への乗り換えより安くつく場面が増えていく。82%という係数は、この省エネ効果に初めてついた公式数字だと私は位置づけている。 モデルの売り手側も、この移行を織り込んだ商品構成に動いている。GPT-5.6がSol/Terra/Lunaという3ティアで提供されること自体、「どのタスクにどれだけの知能を割り当てるか」という**能力の出し分け**が製品名に昇格した徴候だ（Kiroのクレジット換算でLunaはSolの4分の1で回る）。そして最上位同士の比較でも、値差は縮まるどころか逆転気味である。ベンチマーク集計サイトArtificial Analysisの[知能指数](https://artificialanalysis.ai/models/gpt-5-6-sol)では、GPT-5.6 Sol（max）が61、[Claude Fable 5](https://artificialanalysis.ai/models/claude-fable-5)（max）が62。1ポイント差に対して、価格表の単価はSolが半分以下（$4/$20対$10/$50。Solは8月21日に$5/$30から期間限定で値下げされた）だ。「どちらが賢いか」の上位互換競争は、「単価あたりの知能」の競争へ、さらにその先の「**器込みの実効単価**」の競争へと、層を降りつつある。価格の決定権が、モデルの層からハーネスの層へ移る——82%はその移行の告知だった。 ## 損益分岐はハーネス設計で決まる —— 実務への翻訳 この構造を、エージェント導入を検討する立場に翻訳するとどうなるか。 まず、**モデル比較表を眺める時間の一部を、ハーネスの比較と設計に振り向けるべき局面**に来ている。どのモデルが賢いかは依然重要だが、図2が示すとおり、運用の座標を大きく動かすのは器のほうだ。そして器には「買う・借りる・作る」の選択肢がある。Claude CodeやKiroのような既製ハーネスを使うことは、他社が積み上げたハーネスエンジニアリングの成果を利用料で借りることに等しい。自作は文脈設計の自由度と引き換えに、設計と保守の負債を自社で抱える選択だ。6月の連載『AIエージェント構築、その前に——コスト・権限・運用の天秤』ではモデル選定・権限設計・フォールバック・運用という四つの天秤を扱ったが、その隣に今、五つ目の天秤——ハーネスを買うか作るか——が置かれたことになる。 次に、費用の異変への見方が変わる。「同じモデルを使っているのに、先月より請求が高い」——この犯人は、たいていモデルではない。読ませるファイルが増えた、接続したMCPサーバーのツール定義が肥えた、履歴の持ち越しが長くなった、失敗率が上がって試行が増えた。すべて器の変化だ。逆に言えば、**請求書はハーネスの健康診断書**として読める。 そして監視の意味が変わる。私はトークン消費を可視化する監視ツール——token-monitorと呼んでいる——を構想しているのだが（前回も白状したとおり、まだアイデアの段階だ）、この一件はその存在意義を書き換えるものだった。単価が時刻の関数になった世界（8月の料金改定の話）で、監視は「いつ使ったか」を記録する装置になった。消費量が設計の関数になった世界では、監視はさらに「**ハーネス改善の効果測定装置**」になる。specを導入する前と後で、試行回数と読み込みトークンはどう動いたか。ツール定義を段階開示に変えて、毎ターンの固定費はいくら減ったか——それを測れない組織は、OpenAIの82%が自社では何%なのかを、永遠に知ることができない。省エネ設計に電力メーターが要るように、ハーネスエンジニアリングにはトークンメーターが要る。 ## 両論 —— ハーネス万能論への留保 熱を上げすぎないために、反対側も書いておく。 第一に、数字の性質。82%はベンダー公表値であり、比較条件は開示されていない。本稿の主張はリーダーボード実測（4.2倍）で独立に成り立つよう組んであるが、82%という個別の係数を自社の見積もりに転記するべきではない。第二に、タスク種への依存。spec駆動が効くのは「仕様に落ちる仕事」だ。要件が言語化できる開発タスクでは迷いの除去が効くが、探索そのものが目的の調査や、何が正解か走りながら決まる創発的なタスクでは、先回りの構造化がかえって足枷になりうる。第三に、**ハーネス税**。仕様化にも、計画にも、評価にも、トークンは掛かる。数分で終わる小さなタスクでは、器のオーバーヘッドが削減分を食い潰すこともある。省エネ設備の投資回収と同じで、効くのは運転時間が長い場合だ。 第四に——これが長期では最も重いと思うが——**ロックインの形が変わる**。モデルの乗り換えは、APIの互換層が整った今、かつてなく容易になった。だがハーネスの乗り換えは重い。AGENTS.mdに蓄積した作法、失敗のたびに追加したフック、チームの運用が馴染んだ権限設計——器には組織の学習が沈殿する。価格決定層がモデルからハーネスに移るということは、囲い込みの主戦場も同じ場所に移るということだ。器を借りる判断をするとき、見るべきは今月の削減率だけではない。 ## むすび —— モデルカードではなく、設計図を読む それでも、方向はもう見えていると思う。 ベンチマークの世界にはすでに「Best Reported Harness（報告された最良ハーネス）」という集計カテゴリが現れ、リーダーボードはモデルの表からモデル×器の行列に変わった。標準の世界では、MCPが「何を読ませないか」を仕様に書き込もうとしている。そして商用の世界では、モデルを売る当人が「うちのモデルは、器次第で5分の1のコストで走る」と公式に言った。モデルの知能が横並びに近づくほど、差がつく場所は器へ降りていく。ハーネスエンジニアリングは、プロンプトの工夫と呼ばれていた牧歌的な時代を抜けて、稼働率やFinOpsと同じ、経済の言葉で語られる工学になった。 エージェントに仕事を任せる設計者が次に読むべきものは、前回の記事の結びでは「料金表の中の時計」だった。今回はこう続けたい。モデルカードの新しいベンチマークではなく、**ハーネスの設計図**を読むこと。何を読ませ、何を持たせ、いつ文脈を捨てるのか——その図面にこそ、来月の請求額が書いてある。 モデルの知能に値札がつく時代は、終わりつつある。値札は、器につき始めた。 参照情報 - [OpenAI 公式: Advancing price-performance for developers with GPT-5.6 in Kiro](https://openai.com/index/gpt-5-6-in-kiro/) — 82%の原典（2026-08-24） - [Kiro 公式ブログ: GPT-5.6 is now available in Kiro](https://kiro.dev/blog/gpt-5-6/)／[changelog: OpenAI GPT-5.6 Sol, Terra, and Luna now available](https://kiro.dev/changelog/models/gpt-5-6/) — Sol 88.8%・CAI 80・クレジット乗数（Sol 2.4x / Terra 1.2x / Luna 0.6x） - [Terminal-Bench 2.1 公式リーダーボード](https://www.tbench.ai/leaderboard/terminal-bench/2.1) — Agent×Model行列と実行コスト（2026-08-25閲覧） - [Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces（arXiv:2601.11868）](https://arxiv.org/abs/2601.11868) - [MCP 公式ブログ: ロードマップ](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) — progressive discovery ほか（2026-08-22） - [Anthropic engineering: Harness design for long-running agents](https://anthropic.com/engineering/harness-design-long-running-apps) — 三層構成・コンテキストリセット（2026-03-24） - [Addy Osmani: Agent Harness Engineering](https://addyosmani.com/blog/agent-harness-engineering/) — 定義・格言・Top30→Top5事例（2026-04-19） - [awesome-harness-engineering（GitHub）](https://github.com/ai-boost/awesome-harness-engineering) — 分野としての定着の傍証 - [Artificial Analysis: GPT-5.6 Sol](https://artificialanalysis.ai/models/gpt-5-6-sol)／[Claude Fable 5](https://artificialanalysis.ai/models/claude-fable-5) — 知能指数61/62・単価$4/$20と$10/$50（Solは2026-08-21に$5/$30から値下げ。2026-08-27再確認） - 関連記事: [推論は電力になる — 時間帯で価格が変わるAI](https://www.untype.jp/blog/inference-becomes-electricity)（2026-08-16）／連載『AIエージェント構築、その前に——コスト・権限・運用の天秤』（2026-06-11〜） --- ## 推論の世界システム — 中核・周辺・そして時間の分業 URL: https://www.untype.jp/blog/world-system-of-inference/ 公開日: 2026-08-27 カテゴリ: 世界システム論, 地政学, AIエージェント, オープンウェイト, ソブリンAI > DeepSeekの時間帯価格と米国勢の値下げを、ウォーラーステインの世界システム論で読み直す。推論の周辺化、GPU規制と輸入代替としてのオープンウェイト、ソブリンAIの92%がNVIDIAという逆説、そして空間の分業に加わった「時間の分業」という新しい座標を論じる。 [前編『推論は電力になる』](/blog/inference-becomes-electricity)を書き終えたあと、ひとつの違和感が残った。DeepSeekの時間帯価格、米国勢の値下げ、オープンウェイトの開放——2026年8月のこの一連の動きを、私は「ピーク問題への四つの解法」として整理した。それ自体は間違っていないと思う。だが、どこか腑に落ちない。各社が自由に戦略を選んでいるように書いたが、本当にそうか。DeepSeekは時間帯価格を「選んだ」のではなく、選ばされたのではないか。OpenAIは頂点を「守っている」のではなく、そこにしか居場所がないのではないか。 打ち手の背後にある、打ち手を規定する構造。それを考えるための道具立てとして、今日は少し遠回りをして、イマニュエル・ウォーラーステインの世界システム論を持ち出したい。1970年代に体系化されたこの理論は、AIどころかインターネットすら知らない。だが「単一の分業体系の中で、なぜ豊かな場所と貧しい場所が構造的に再生産されるのか」を説明するために作られたこの枠組みは、推論経済の現在地を驚くほど鮮明に照らす。そして重ねてみると、この理論が想定していなかった新しい座標軸が、いままさに一本増えつつあることも見えてくる。 先にウォーラーステインの骨格だけ確認しておく。近代世界システムとは、国境をまたぐ単一の分業体系（世界経済）であり、その中の位置は**中核・半周辺・周辺**の三層に分かれる。重要なのは、この三層を分けるのが「何を作っているか」ではないという点だ。中核を中核たらしめるのは**独占の度合い**である。準独占を維持できる活動は高い利潤を生み（中核的活動）、競争にさらされ商品化した活動は利潤が薄くなる（周辺的活動）。そして国家の力とは、この分業体系の中で自分に有利な交換のルールを敷く力にほかならない。 ## 中核性とは、独占の度合いである — 推論の周辺化 ウォーラーステインは、かつての花形産業が凡庸な産業へ転落していく過程を繰り返し描いた。18世紀の繊維、19世紀の鉄鋼、20世紀の自動車と半導体。どれも登場時は中核の独占物だったが、技術が拡散し、競争者が現れ、商品化するにつれて、利潤の薄い周辺的活動へと滑り落ちていった。中核はそのたびに、まだ独占できる次の主導製品へ乗り換えることで中核であり続けた。**産業が移動するのではない。独占が移動するのだ。** この目で8月の推論市場を見ると、風景が一変する。 前編で書いた「推論のユーティリティ化」とは、世界システム論の言葉に置き換えれば、**推論という活動の周辺化**である。時間帯で価格が変わり、稼働率と償却スケジュールで経営が語られ、発表がプロダクトローンチではなくインフラ更新の顔をする——これらはすべて、推論が準独占レントを取れる中核的活動ではなくなり、商品化された活動になったことの兆候だ。DeepSeek創業者・梁文鋒の「設備費用の合理的な回収」という言葉は、この周辺化を最も早く、最も正直に受け入れた者の言葉である。受け入れたからこそ、電力会社の料金設計をためらいなく導入できた。 一方、同じ週の米国勢の動きは、教科書的な**中核の行動様式**だった。OpenAIが軽量モデルを80%値下げし、Anthropicが上位モデルを半額で投入した動きを、アナリストは「中間を切り下げ、頂点を守る」と評した。商品化が進んだ層は競争に明け渡し（あるいは自ら焦土化し）、まだ独占可能な最先端能力・速度・優先アクセスへ退却してレントを守る。繊維を手放して鉄鋼へ、鉄鋼を手放して半導体へ乗り換えてきた中核の身のこなし、そのものだ。 つまり8月に起きたのは価格戦争ではない。**推論という環が商品連鎖の中で周辺へ滑り落ち、各プレイヤーが連鎖のどの環を握り直すかを再選択した**——分業の再編である。 ```svg 産業は移動しない、独占が移動する — 主導製品のライフサイクル 中核的活動（準独占・高レント） 周辺的活動（商品化・薄利） 繊維（18–19世紀） 拡散 → 商品化 → 周辺へ 鉄鋼・自動車（19–20世紀） 半導体・汎用IT（20世紀末） 推論API（2026） 時間帯価格＝ユーティリティ化＝周辺化 いま、ここ 独占の次の宿り先 — 最先端能力・速度/優先アクセス・チップ・エネルギー 中核は商品化した環を明け渡し、まだ独占できる環へ乗り換えることで中核であり続ける ``` **図1：主導製品のライフサイクルと推論の現在地。**繊維も鉄鋼も半導体も、独占の間だけ中核の主導製品だった。時間帯価格の導入は、推論APIがこの下り坂に入ったことの構造的なサインである。 ## ヘゲモニーの秋と、分業の凍結 世界システム論のもうひとつの柱が、ヘゲモニー（覇権）循環論だ。17世紀のオランダ、19世紀のイギリス、20世紀のアメリカ。覇権国は生産・流通・金融の全領域で圧倒的優位を握るが、その優位は必ず侵食される。そして覇権の下降局面に入った中核は、決まって同じことを試みる。**技術の拡散を止め、自分に有利な分業構造を凍結すること**だ。 歴史はこの試みに冷たい。産業革命期のイギリスは繊維機械の輸出と技工の出国を法律で禁じたが、機械工サミュエル・スレーターは頭の中に設計図を入れてアメリカへ渡り、ロードアイランドに紡績工場を建てた。アメリカ産業革命の始まりである。禁輸は拡散を止められず、せいぜい遅らせただけだった——そして遅らせている間に、挑戦者は自前の工夫を発明した。 GPU輸出規制は、この「分業の凍結」の現代版として読める。そして規制がDeepSeekに強いた適応——需要側の経済学、稼働率の徹底、時間帯価格、そしてオープンウェイトという迂回路——は、スレーターの紡績工場と同じ役割を果たしつつある。前編で「効率の思想は欠乏の側から生まれる」と書いたが、世界システム論はもう一歩踏み込む。**欠乏は、覇権国が挑戦者に課したものであり、その欠乏への適応こそが挑戦者の上昇戦略になる**。半周辺から中核への上昇は、歴史上つねに、中核が独占を手放した（あるいは守りきれなかった）環を、より安く、より効率的に握り直すことから始まった。19世紀のアメリカがそうだったし、20世紀後半の日本の製造業がそうだった。2026年の推論市場で同じ型が反復されているとすれば、時間帯価格は単なる料金表ではない。**上昇運動の足音**である。 ## 時間の分業 — 世界システムに追加された第四の座標 ここからが、前編の対話の中でいちばん考え込んだ論点だ。ウォーラーステインの分業論は、徹底して**空間の理論**である。中核と周辺は地図の上にあり、不平等は地理に刻まれる。綿花は南で摘まれ、綿布は北で織られる。世界システムの座標は、緯度と経度と国境だった。 時間帯価格は、この座標系に**時間軸を追加する**。 DeepSeekの新料金では、ピークは北京の営業時間（午前9時〜正午・午後2時〜6時）で定義されている。この一枚の料金表を世界の主要都市に重ねると、奇妙な地図が浮かび上がる。各都市の営業時間9時〜18時のうち、何時間が「高いトークン」の時間帯に沈むか。北京は当然7時間。東京は6時間。ベルリンは3時間。そして**ニューヨークはゼロ時間**——米国東海岸の営業時間は、完全にオフピークの谷の中にある。 ```svg 同じ料金表、違う運命 — 営業時間（9–18時）はどれだけピークに沈むか 各行は現地時間の0–24時。桃色＝ピーク帯（北京の営業時間で定義）、点線枠＝各都市の営業時間 北京 ピークと重なる営業時間: 7/9時間 東京 6/9時間 ベルリン 3/9時間 ニューヨーク 0/9時間 0時 6時 12時 18時 24時 ピーク帯: UTC 01:00–04:00・06:00–10:00（DeepSeek新料金・2026-08-17〜）を各都市の現地時間に換算。夏時間適用（ベルリンCEST・ニューヨークEDT） 営業時間は9:00–18:00と仮定。重なりが大きいほど、その都市の「昼の仕事」は高いトークンで動く ``` **図2：同じ料金表が都市ごとに生む非対称。**北京の営業時間で定義されたピークは、東京の営業時間をほぼ丸ごと呑み込み、ニューヨークの営業時間とはまったく重ならない。時差が、そのまま原価の差になる。 これは偶然の産物だが、構造としては偶然では済まない。料金表の時間軸を握る者は、世界中のワークロードの潮汐を設計する力を持つ。安いトークンを求めるバッチジョブはこれから中国の昼を避けて回り出し、その「避け方」は各国の時差によって決まる。ウォーラーステインにとって国家の力が「有利な交換ルールを敷く力」だったことを思い出せば、これは小さな話ではない。**関税が空間の分業に課された通行料だったとすれば、ピーク料金は時間の分業に課された通行料**であり、その料率表の基準時はすでに北京にある。 ご丁寧なことに、歴史には先例まである。19世紀末、世界の標準時がグリニッジで統一されたのは、当時の覇権国イギリスの海運と鉄道が世界の時刻表を握っていたからだ。時間の基準は、いつの時代も、その時代の支配的なネットワークの都合で敷かれる。鉄道の時代の基準時はロンドンにあった。推論の時代の最初の料金基準時は、北京に置かれた——この一文が持つ重みは、太平洋の両岸で静かに測られているはずだ。 もっとも、この「時間の周辺性」は地理的な周辺性より遥かに流動的であることは強調しておきたい。土地は動かせないが、ジョブは動かせる。前編で書いたとおり、エージェントは価格応答をネイティブにこなす最初の需要家であり、日本の開発者が夜間バッチを設計すれば、時間の不利の相当部分は工学的に相殺できる。空間の世界システムでは周辺からの脱出に数十年の産業政策が要ったが、時間の世界システムでは、よくできたスケジューラがその一部を代行する。**不平等の構造は引き継がれたが、可動性のルールは変わった**——ここが、古い理論に新しい軸が加わったときの、いちばん希望のある差分だと思う。 ## 輸入代替としてのオープンウェイト、ソブリンAIの逆説 周辺・半周辺が中核への従属から抜け出そうとするとき、歴史的に選ばれてきた戦略が**輸入代替工業化**だった。完成品の輸入をやめ、国内で作る。20世紀のラテンアメリカやアジアで繰り返されたこの型は、推論経済では「APIの購読をやめ、重みを自前のインフラで走らせる」という形で再演されている。前編で「計算の自家発電」と呼んだものは、世界システム論の語彙では輸入代替そのものだ。Qwen3.8-Maxのフラッグシップ重み公開も、Moonshot AIのKimi K3も、この文脈に置くと「製品の輸出」ではなく「生産手段の頒布」であり、中核が握る独占への構造的な挑戦になる。MistralがZhipuのGLM-5.2を欧州のデータレジデンシー下でホストする構図——挑戦者の技術を借りて二つの中核の間でバランスを取る——は、半周辺の古典的な立ち回りとして教科書に載せたいほどだ。 ところが、ここに強烈な逆説がある。いま世界中の政府が「ソブリンAI」の名の下に自国のAIインフラを建設しているが、[Counterpoint Researchが2026年7月に約55カ国・170超のモデルを調査したところ、そのソブリンAIの学習・推論インフラの92%がNVIDIA製だった](https://www.communicationstoday.co.in/nvidia-dominates-sovereign-ai-landscape-powering-92-of-llms/)。主権を買えば買うほど、単一の中核企業への依存が深まる。発電機を一社から輸入して「電力自給」を名乗るようなものだ。ウォーラーステインなら、これを驚きもせずにこう言うだろう——輸入代替の限界は昔から同じで、**組立は代替できても、資本財は代替できない**。ラテンアメリカの工業化が最終的に工作機械と特許の壁に阻まれたように、ソブリンAIは重みの層では自立できても、チップの層で中核に繋ぎ止められている。 例外の小ささが、逆に構造を照らす。同じ調査で非NVIDIAの事例として挙がるのは、フィンランドのLUMI（AMD）、UAEのG42×Cerebras、そして日本の富岳LLM（富士通の自製プロセッサ）といった少数派だ。日本が世界で数少ない「チップ層からの自立の芽」を持つ国のひとつであること、そしてその芽が需要集約の不在によって規模を得られずにいることは、[『国産LLMの現在地』](https://www.untype.jp/blog/current-state-japanese-llm-two-layer-map-alternatives/)で書いた論点とここで繋がる。 ## レントはどこへ逃げるか — 真の中核 では、推論が周辺化したあと、独占は——レントは——どこに宿るのか。商品連鎖を上流と下流の両方向に辿ると、答えはかなりはっきりしている。 上流には、半導体の三重独占がある。設計のNVIDIA、製造のTSMC、露光装置のASML。いずれも代替困難性が極めて高く、ソブリンAIの92%という数字が示すとおり、モデル層の商品化が進んでも彼らのレントはむしろ濃縮される。その先にはエネルギーと送電網があり、前編で見たとおり、Googleは送電網とのデマンドレスポンス契約という形でこの層への統合をすでに始めている。[Nature Computational Scienceの論説](https://www.nature.com/articles/s43588-026-01013-w)が指摘するように、高性能GPUクラスタの容量は米国に圧倒的に集中し、中国が遠い2位、他のすべての国は端数にすぎない——「コンピュート・ディバイド」は、世界システムの中核−周辺構造がシリコンの上に転写されたものだ。 下流には、顧客との関係を握る層——エージェントの配備、業務への統合、信頼の運用——がある。そして最下層には、世界システム論が最も得意としてきた古典的な周辺が、姿を変えて残っている。データのアノテーション、モデル出力の評価、有害コンテンツのフィルタリングといった労働は、その多くがケニアやフィリピンといった低賃金国に委託されてきた。摘まれる綿花がデータに変わっただけで、**不等価交換の南北構造は、AIのサプライチェーンの中に静かに保存されている**。 ```svg レントは両端へ逃げる — 推論の商品連鎖と独占度 上流（資本財） 下流（顧客関係） 独占度＝レント チップ・エネルギー NVIDIA / TSMC / ASML 送電網・ソブリンAIの92% フロンティア モデル（頂点防衛中） 推論API ユーティリティ化＝周辺化 エージェント統合 業務への実装・信頼の運用 顧客関係の独占 レントの逃避 最下層に残る古典的周辺 — アノテーション・評価・フィルタリング労働 低賃金国への委託という不等価交換の南北構造は、AIサプライチェーンの中に保存されている ``` **図3：推論の商品連鎖におけるレントの分布。**中央の推論層が商品化するほど、レントは上流（チップ・エネルギー）と下流（エージェント統合・顧客関係）へ逃げる。スマイルカーブの推論経済版であり、最下層には古典的な周辺労働が残る。 この図は、日本の読者にとってひとつの実務的な含意を持つ。チップ層での自立は数兆円と十年の話だが、**下流の高台——エージェントを業務に統合し、信頼を運用する層——は、いままさに位置取りが始まったばかりで、参入の切符は資本ではなく設計力**だからだ。周辺化する推論を安く買い（それこそ夜間のオフピークで）、独占可能な統合層で価値を出す。世界システムの中で半周辺が上昇するときの定石は、安くなった中間財を仕入れて、まだ商品化していない工程で勝負することだった。同じ定石が、いま推論経済で使える。 ## 理論の軋み — 企業という準主権者 最後に、この補助線の限界を正直に書いておく。当てはまりが良すぎる理論は、当てはまらない場所でこそ検分すべきだからだ。 第一の軋みは、主体の問題である。ウォーラーステインの世界経済の主体は国家間システムの中の国家であり、企業は国家の力を借りてレントを守る存在だった。だが今回の「料金基準時」を敷いたのは中華人民共和国ではなくDeepSeekという一企業であり、ソブリンAIの92%を握るのも米国政府ではなくNVIDIAという一企業だ。ウォーラーステインは、単一の政治権力が経済全体を覆う体制を「世界帝国」と呼び、複数の国家が競争する「世界経済」と区別した。プラットフォーム企業が敷く私的なルール——料金表、API規約、モデルの利用規程——が国境を無視して全世界の開発者を直接拘束する現在の構図は、国家間の世界経済の上に、**企業単位の小さな世界帝国**が何層も重なった、理論の想定にない混成体に見える。 第二の軋みは、速度だ。ウォーラーステインの循環は50年、100年の単位で回る。だが推論の商品化は、フロンティアモデルの登場からユーティリティ価格の出現までわずか3年余りで走り抜けた。構造は反復されているが、時定数が桁で違う。中核の「次の独占への乗り換え」も同じ速度で起きるとすれば、位置取りの機会は開くのも早いが、閉じるのも早い。 それでもこの理論を持ち出す価値があると私が考えるのは、世界システム論のいちばん深い教えが「個々のプレイヤーの賢愚ではなく、位置が行動を規定する」という視点だからだ。DeepSeekの時間帯価格を「賢い」と評価すること（前編の私だ）と、それが**周辺化を受け入れた者にだけ可能な賢さ**だと理解することの間には、分析として一段の差がある。8月の各社の打ち手は、四つの自由な戦略ではなく、世界システムの中の四つの位置から見えた、それぞれ唯一の出口だったのかもしれない。 ## むすび — 時計の針が描き込まれた地図 ウォーラーステインの地図は、五百年のあいだ空間の地図だった。そこに2026年8月、初めて時計の針が描き込まれた。ピークとオフピークという二つの時間が、中核と周辺という二つの空間に重なり、世界のワークロードは地理と時差の二重の座標で値付けされ始めている。 日本の位置は、この二重の座標のどちらでも微妙だ。空間の座標では、チップの芽を持ちながら需要集約を欠く半周辺。時間の座標では、営業時間の3分の2が他国の基準時のピークに沈む不利な経度。だが前編から繰り返してきたとおり、時間の不利はスケジューラが相殺でき、統合層の高台はまだ誰のものでもない。世界システム論が教える半周辺の恐ろしさは「どちらにも行ける」ことであり、希望も同じ場所にある。 推論は電力になった。そして電力の世界システムがそうだったように、誰の発電所で、誰の時計で、誰の労働で回るのかという問いは、料金表の数字よりずっと長く、私たちの位置を決めることになる。 参照情報 - 前編: [推論は電力になる — 時間帯で価格が変わるAI](/blog/inference-becomes-electricity) - イマニュエル・ウォーラーステイン『近代世界システム』『入門・世界システム分析』（中核・半周辺・周辺、独占度と中核性、ヘゲモニー循環） - [DeepSeek 公式料金ページ（時間帯定義）](https://api-docs.deepseek.com/quick_start/pricing/) - [Counterpoint Research調査の報道: ソブリンAIインフラの92%がNVIDIA（2026年7月・約55カ国170超モデル）](https://www.communicationstoday.co.in/nvidia-dominates-sovereign-ai-landscape-powering-92-of-llms/) - [Nature Computational Science: The inequalities of GPU access（コンピュート・ディバイド）](https://www.nature.com/articles/s43588-026-01013-w) - [BigGo Finance: 米国勢の値下げとDeepSeek値上げの対照](https://finance.biggo.com/news/7e9f1d12-cf40-4852-a49a-ed69b6925090) - [Qwen3.8-Max オープンウェイト（Hugging Face）](https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B) --- ## 推論は電力になる — 時間帯で価格が変わるAI URL: https://www.untype.jp/blog/inference-becomes-electricity/ 公開日: 2026-08-24 カテゴリ: AIエージェント, DeepSeek, 地政学, オープンウェイト > DeepSeekがAPI価格をピーク/オフピークの二層に変えた——LLM推論に持ち込まれた電気料金の設計を解剖。貯蔵できない設備産業の必然、エージェントの「夜勤」、監視の時刻×単価化、各社のピーク問題への四つの解法まで、推論のユーティリティ化を実務目線で読む。 日本時間8月17日の午前1時、AIの請求書に新しい変数がひとつ加わった。「何時に投げたか」だ。 DeepSeekは8月13日、4月からプレビュー提供していたフラッグシップモデルV4-Proを正式版（GA）に昇格させた。エージェント用途に特化し、100万トークンのコンテキストを持つこのモデルの発表と同時に、同社は[APIの新価格](https://x.com/deepseek_ai/status/2087864589895798968)を予告した。単なる値上げではない。V4-ProとV4-Flashの料金表が、**ピーク時間帯とオフピーク時間帯の二層構造**に変わる。[公式の料金ページ](https://api-docs.deepseek.com/quick_start/pricing/)によれば、切り替えは8月16日16:00 UTC——日本時間では8月17日の午前1時だった。 トークンあたりいくら、という世界が終わったわけではない。だがその単価が、1日のうちに2倍のレンジで上下し始めた。これは電気料金の設計そのものだ。昼間の電気は高く、深夜の電気は安い。あの構造が、LLM推論の世界に定価として持ち込まれた。フロンティア級のAPIとしては史上初のことになる。 今日はこの発表を入口に、「推論のユーティリティ化」という少し先の構造を考えてみたい。結論を先に言えば、これは一社の値付けの工夫ではない。**貯蔵できない財を設備産業が売るとき、価格は必ず時計を見るようになる**——電力が100年かけて辿り着いた市場設計に、推論が数年で追いつきつつある、という話だ。 ## 値上げの中に埋め込まれた、もうひとつの発表 まず事実関係を正確に押さえる。今回の改定は[報道](https://qz.com/deepseek-api-price-increase-v4-peak-off-peak-081326)では「最大1,100%超の値上げ」という見出しが躍った。それ自体は正しい。V4-Proの出力単価は100万トークンあたり$0.87から、ピーク時間帯には$3.96へと4.6倍になる。キャッシュヒット入力に至っては$0.003625から$0.044へ、12倍を超える。オフピークでもすべての単価はピークのちょうど半額——つまり出力$1.98で、従来比2.3倍だ。値上げは値上げである。 だが見出しの陰で、料金表の**構造**が変わったことのほうが、長い目では重要だと私は思う。新しい料金表はこうなっている。 ```markdown-table | V4-Pro（100万トークンあたり） | 従来（〜8/16） | オフピーク | ピーク | |---|---|---|---| | 入力（キャッシュヒット） | $0.003625 | $0.022 | $0.044 | | 入力（キャッシュミス） | $0.435 | $0.66 | $1.32 | | 出力 | $0.87 | $1.98 | $3.96 | ``` ピーク時間帯は01:00–04:00と06:00–10:00（UTC）。北京時間で午前9時〜正午と午後2時〜6時、つまり[中国の営業時間の中核](https://technode.com/2026/08/14/deepseek-to-introduce-peak-and-off-peak-pricing-for-its-api/)だ。1日24時間のうちピークは7時間だけで、残り17時間は半額のまま。そして日本時間に引き直すと、ピークは**午前10時〜午後1時と午後3時〜7時**——日本の営業時間とほぼ丸ごと重なる。日本からDeepSeekを平日昼間に叩くと、ほぼ確実にピーク料金を払うことになる。 ```svg 1日が「峰」と「谷」に分かれる — DeepSeekの時間帯別価格（日本時間） ピーク 10–13時 ピーク 15–19時 オフピーク 〜午前10時 オフピーク 19時〜 0時 6時 10時 13時 15時 19時 24時 ピーク（計7時間）＝ 単価2倍 V4-Pro 出力: $3.96 / 100万トークン 入力: $1.32（キャッシュヒット $0.044） オフピーク（計17時間）＝ ピークの半額 V4-Pro 出力: $1.98 / 100万トークン 入力: $0.66（キャッシュヒット $0.022） 出典: DeepSeek公式料金ページ。切り替えは2026-08-16 16:00 UTC（日本時間8/17 午前1時）。ピークはUTC 01:00–04:00と06:00–10:00 ``` **図1：DeepSeekの時間帯別価格を日本時間に引き直した1日の構造。**ピークの7時間は日本の営業時間とほぼ重なり、残り17時間は半額。「いつ投げるか」がそのまま原価の変数になる。 なお、DeepSeekが公式ブログでの丁寧な発表を打たず、Xへの投稿とAPIドキュメントの更新だけで済ませたことも記録しておきたい。Simon Willisonの[V4-Pro検証記事](https://simonwillison.net/2026/Aug/12/deepseek-v4-pro-0813/)もこの発表の素っ気なさに触れているが、私にはこう見える——同社はモデルを「プロダクトのローンチ」ではなく「インフラの更新」として扱っている。インフラの更新として粛々と告知される料金改定——この発表の様式それ自体が、推論のユーティリティ化を先取りしている。 ## 二度目の時間帯価格 — 「割引」から「定価」への昇格 実は、DeepSeekが時間帯で価格を動かすのはこれが初めてではない。 2025年2月、同社は[オフピーク割引](https://x.com/deepseek_ai/status/1894710448676884671)を導入している。16:30–00:30 UTC——中国の深夜帯——に限り、V3を50%引き、推論モデルR1を75%引きで提供するというものだった。R1ブームで殺到したトラフィックを深夜に逃がすための、いわば緊急避難的な平準化策だ。この割引は半年あまり続いたのち、[2025年9月5日、V3.1の新価格への移行と同時に廃止された](https://api-docs.deepseek.com/news/news250821/)。単一価格への回帰である。 だから今回は「二度目」だ。そして一度目と二度目のあいだには、決定的な違いがある。 2025年のそれは**割引**だった。定価は単一で、深夜だけ安くなる。キャンペーンと同じ構造であり、実際、廃止するときは割引を「終了」すれば済んだ。今回のそれは**定価の構造**だ。ピークとオフピークという二層が料金表そのものに書き込まれ、どちらかが「本来の価格」でどちらかが「おまけ」なのではない。1日の時間割が、価格体系の一部になった。 電力の歴史で言えば、これは「深夜電力割引」から「時間帯別料金（Time-of-Use）」への移行に相当する。前者は余剰設備の穴埋め策だが、後者は需要そのものを設計する制度だ。日本でも夜間蓄熱式機器やエコキュートを前提とした深夜料金メニューが長く存在し、揚水発電は安い夜の電気で水を汲み上げて高い昼に売る——つまり電力の世界では、**時間差はずっと前から裁定取引の対象**だった。トークンの世界が、いままさに同じ入口をくぐっている。 ## なぜ推論は電力の形に行き着くのか 偶然の一致ではない。推論と電力は、財としての物理的性質が同じだからだ。 第一に、**貯蔵できない**。電気は（揚水や蓄電池という高価な例外を除き）作った瞬間に使うしかない。推論も同じで、GPUの計算サイクルは在庫できない。深夜に遊んでいたGPU時間を取っておいて、昼のピークに放出することはできない。作り置きのできない財は、需要の山に合わせて設備を持つしかない。 第二に、**設備産業である**。発電所も推論クラスタも、巨額の固定費を先に積み、限界費用の低い財を流し続けることで回収する。このとき事業者を苦しめるのは平均需要ではなくピーク需要だ。ピークのために積んだ設備は、谷の時間帯には遊ぶ。設備稼働率こそが損益の分水嶺になる。実際、DeepSeek創業者の梁文鋒は、7月末に流出が報じられた社内会議の記録で「設備費用の合理的な回収」を掲げ、ハードウェアをおよそ10ヶ月で償却する水準の値付けを[説明したと報じられている](https://finance.biggo.com/news/7e9f1d12-cf40-4852-a49a-ed69b6925090)——今回の改定は、その考え方の延長線上にある。値付けの根拠がベンチマークスコアではなくGPUの償却スケジュールで語られる——これは発電所の経営言語そのものだ。 この二つが揃った産業で、価格が時計を見ないほうがおかしい。電力業界は20世紀のあいだにこの問題と格闘し、時間帯別料金、需給調整契約、デマンドレスポンス、ネガワット取引という一連の道具立てに辿り着いた。要するに「**需要の山を、価格シグナルで谷へ運ぶ**」技術体系だ。 DeepSeekが今回の改定で述べた理由は「リソースをより合理的に配分するため」——[報道によれば](https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html)、需要の急拡大が計算容量を圧迫していることへの対処だ。米国の輸出規制下で最先端GPUの調達に制約を抱える中国企業にとって、供給を増やせないなら需要を動かすしかない。アナリストのSanchit Vir Gogiaは同記事で「24時間のうち17時間は半額のままだ。**タイミングが経済変数になった**」と要約している。 ここで思い出したいのは、AIの世界にはすでに「安く待つ」仕組みが存在していたことだ。OpenAIのBatch API（2024年4月〜、50%引き・24時間以内に結果返却）、AnthropicのMessage Batches（2024年10月〜、50%引き）、GeminiのBatch Mode、そしてOpenAIの[Flex processing](https://developers.openai.com/api/docs/guides/flex-processing)。いずれも「急がない処理は安くする」という点で今回と同じ需要平準化の道具だ。 だが構造は一段違う。バッチ処理は**キュー型**だ。買い手は仕事を投げ、いつ実行するかは事業者が決める。安さの対価は「いつやってもらえるか分からない」ことだった。時間帯価格は**時計型**だ。いつ投げるかを決めるのは買い手であり、価格表は「この時間なら安い」と事前に公開されている。判断の主導権が、事業者から買い手へ——正確には、買い手側のスケジューラへ——移った。電力で言えば、バッチは「電力会社にお任せの需給調整契約」、時間帯価格は「メーターを見ながら家電を動かす時間帯別料金」に対応する。後者のほうが、買い手側の設計を要求する制度なのだ。 ## 電力網からエージェントまで、価格シグナルが貫通する 「推論は電力になる」という比喩には、比喩で終わらない裏付けがある。推論の原価の大きな部分は、文字どおり電力だからだ。そして電力網の側は、すでにAIデータセンターを需要調整の相手として組み込み始めている。 Googleは2025年、Indiana Michigan PowerとTVA（テネシー川流域開発公社）とのあいだで、送電網が逼迫した時間帯に**データセンターのML（機械学習）ワークロードを削減・移動する**契約を結んだ。この取り組みは2026年に入って拡大し、[Entergy Arkansas、Minnesota Power、DTE Energyを加えた計1ギガワット分のデマンドレスポンス](https://www.renewableenergyworld.com/power-grid/smart-grids/google-has-integrated-1-gw-of-data-center-demand-response-with-us-utilities/)が長期電力契約に組み込まれた。グリッドが「今は電気を使うな」と言えば、AIの計算が止まるか、別の時間・別の場所へずれる。デューク大学の研究は、年間わずか0.25%の稼働抑制を受け入れるだけで、米国の送電網に76ギガワットの新規負荷を追加接続できると試算している——AIの計算需要が「ずらせる負荷」であることは、もう電力業界の計画前提なのだ。 つまり、こういう連鎖が完成しつつある。電力網はデータセンターに「ピークを避けよ」という価格・契約シグナルを送る。データセンターはそれを受けてワークロードを時間軸上で動かす。その原価構造がAPI料金に転写されて、今度は開発者とエージェントに「ピークを避けよ」というシグナルが届く。**価格シグナルが、発電所からエージェントのジョブスケジューラまで、スタックを貫通して流れ始めた**。DeepSeekの料金改定は、この連鎖の最後のパイプがつながった音だと私は解釈している。 ```svg 「ピークを避けよ」— 価格シグナルは発電所からエージェントまで届く 電力網（系統運用者・電力会社） 貯蔵できない電気を、需要の山に合わせて供給 シグナル：時間帯別料金・DR契約 例: Google×米5電力 計1GWのDR データセンター（推論クラスタ） 逼迫時はMLワークロードを削減・時間移動 在庫できないGPUサイクル ピーク需要が設備量と損益を決める 推論API（モデル事業者） 原価の時間構造を、料金表に転写する シグナル：ピーク/オフピーク価格 例: DeepSeek V4（8/17〜・ピーク2倍） エージェント（ジョブスケジューラ） ずらせるジョブを安い時間帯へ移す＝需要応答 応答：ジョブの時間シフト 電力のデマンドレスポンスと同型 価格シグナルの流れ 出典: Google×米電力5社のデマンドレスポンス統合（2025–2026）、DeepSeek新料金（2026-08-16 16:00 UTC切替）より構成 ``` **図2：価格シグナルのスタック貫通。**電力網→データセンター→推論API→エージェントと、「ピークを避けよ」というシグナルが層を降りていく。最下層でエージェントが行うジョブの時間シフトは、電力のデマンドレスポンスの相似形になる。 ## 同じ週に、価格は「静的な仕様」から「動的な戦略変数」になった 視野をもう半歩引くと、DeepSeekの発表は孤立事象ではないことが見えてくる。同じ8月13日に、価格と提供条件をめぐる動きが立て続けに起きている。 Googleは[Gemini 3.7 Flash](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/)を、**2026年12月31日まで有効の導入価格**（入力$0.75・出力$3.75）で投入した。2027年1月1日からは倍額の$1.50・$7.50に戻る。SaaSの世界でお馴染みの「初年度割引」が、LLM APIの一線級モデルに持ち込まれた初の大型例だ。価格に有効期限がついた、と言ってもいい。 OpenAIは同日、GPT-5.6 Solの[「Ultrafast」ティア](https://openai.com/index/previewing-ultrafast/)をプレビュー公開した。Cerebrasのウェハースケールチップで駆動し、同一の知能のまま最大14倍速・毎秒750トークンを出す。賢さではなく**速度そのものを独立した課金ティア**として売る試みだ。 時間帯で変わる価格（DeepSeek）、期限つきの価格（Google）、速度で分かれる価格(OpenAI)。3つを並べると、共通の構図が浮かぶ。モデルの賢さが横並びに近づくなかで、競争の主戦場が「何ができるか」から「**どういう条件で提供するか**」へ移っている。価格はもはやモデルカードの末尾に書かれた静的な仕様ではなく、時間・期限・速度という軸を持つ設計空間になった。買い手から見れば、これは複雑化であると同時に交渉余地の出現でもある。電力の自由化がそうだったように、料金メニューが多次元になった市場では、**使い方を設計できる者だけが安く買える**。 ## エージェントの仕事に「夜勤」が生まれる では、買い手側——エージェントに仕事を任せる側——の設計はどう変わるのか。電力のデマンドレスポンスが最初にやることと同じだ。負荷の仕分けである。 家庭の電気で言えば、照明や冷蔵庫は「ずらせない負荷」で、食洗機や給湯や充電は「ずらせる負荷」だ。エージェントのジョブも同じ二分ができる。人間との対話、リアルタイムの応答、締切が迫る処理は、ずらせない。ピーク価格を払ってでもその場で回すしかない。一方、ドキュメントの一括要約、埋め込みの再計算、ナレッジベースのインデクシング、評価スイートの実行、日次レポートの生成、コードベースの回帰チェック——エージェントに任せたい仕事の多くは、実は**数時間待てる**。 そして、ここに人間とエージェントの決定的な非対称がある。人間は待てないが、エージェントは待てる。人間のユーザー体験は時差に耐えないから、対人推論は今後もピーク価格を払い続けるだろう。だが自律エージェントのジョブには「今すぐ」の必然性がないものが多い。つまり時間帯価格の世界では、**人間向けの推論が昼の高い電気で、エージェントの自律ジョブが深夜電力で回る**という住み分けが自然に生まれる。エージェントに夜勤が生まれるのだ。幸い、彼らは残業代を請求しない。 ```svg ジョブの仕分け — 「ずらせない仕事」と「夜勤に回す仕事」（日本時間） ピーク ピーク 0時 10時 13時 15時 19時 24時 ずらせないジョブ — ピーク価格を許容する 人間との対話・リアルタイム応答／顧客対応・音声／締切の迫る処理 判断基準：人間が待っているか？ → 待っているなら、時間は選べない ずらせるジョブ — オフピーク（夜間・早朝）へ移す 一括要約・埋め込み再計算・インデクシング／評価スイート・回帰チェック／日次レポート生成 判断基準：数時間待てるか？ → 待てるなら、単価は半分になる 待てる仕事は谷へ 日本時間ではピークが10–13時・15–19時のため、19時以降〜翌朝10時の長い谷が夜間バッチの主戦場になる ``` **図3：エージェントのジョブ仕分け。**「人間が待っているか」「数時間待てるか」という2つの問いが、ジョブを昼のピークと夜の谷に振り分ける。電力のデマンドレスポンスにおける負荷の仕分けと同型。 設計への波及は仕分けだけでは終わらない。マルチモデルのルーティングにも新しい入力が加わる。これまでモデルルーターは、タスクの難度・コンテキスト長・レイテンシ要件を見てモデルを選んできた。時間帯価格の世界では、そこに**現在時刻**が加わる。同じジョブでも、日本の昼はGeminiの導入価格（それも12月末が期限だ）へ、夜はDeepSeekのオフピークへ、という具合に、最適解が時刻の関数になる。実際、[InfoWorldの分析](https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html)も、今回の改定が企業にマルチモデル・ルーティングとワークロードの時刻最適化を促すと見ている。 ## 監視は「トークン数」から「時刻×単価」へ もうひとつ、地味だが実務に直結する変化がある。コストの監視と見積もりだ。 これまでLLMのコスト管理は、突き詰めれば「トークン数×単価」の掛け算だった。単価は定数だから、数えるべきはトークン数だけでよかった。私自身、トークン消費を可視化する監視ツール——token-monitorと呼んでいる——を構想していたのだが（白状すれば、まだアイデアの段階だ）、この改定はその前提を静かに壊す。単価が定数ではなく**時刻の関数**になった以上、消費ログには時刻つきの単価テーブルを突き合わせる必要がある。さらにGeminiのような期限つき導入価格まで考えると、単価テーブルには**有効期限**という列も要る。「いつ使ったか」を記録しない監視は、もう請求書を説明できない。 これはまさに、電力メーターが辿った道だ。積算値だけを読む旧式のメーターは、時間帯別料金の世界では役に立たない。30分ごとの使用量を記録するスマートメーターがあって初めて、時間帯料金もデマンドレスポンスも成立する。トークンの世界でも同じインフラの更新——いわば**トークンのスマートメーター化**——が、これから静かに必要になっていく。 ## 各社の次の一手 — ピーク問題への四つの解法 では、DeepSeekが開けたこの扉に、他のプレイヤーはどう応じるのか。興味深いのは、この改定の直前、7月末から8月にかけて、米国勢が**正反対の方向**へ動いていたことだ。[報道によれば](https://finance.biggo.com/news/7e9f1d12-cf40-4852-a49a-ed69b6925090)、OpenAIは7月末に軽量モデルGPT-5.6 Lunaを80%値下げして$0.20/$1.20に、中位のTerraを20%引き下げた。Anthropicは7月下旬に新しいClaude Opus 5を最上位Fable 5の半額（$5/$25）で投入し、8月にはSonnet 5に予定していた9月の値上げを撤回した。米国ラボの価格指数は7月中旬から約4分の1下がったという。中国の最安値プレイヤーが値上げし、米国勢が値下げする——価格戦争の向きが逆転した夏だった。 だがこれを「米国が安く、中国が高く」と読むのは浅い。各社は同じ問題——**貯蔵できない計算のピークをどう捌くか**——に対して、自社の立ち位置から異なる解法を選んでいるのだと私は見ている。電力業界の類型に当てはめると、戦略は綺麗に四つに分かれる。 **DeepSeekは「時間帯料金の系統運用者」だ。** 輸出規制で供給を増やせない以上、需要を動かすしかない。梁文鋒の「設備の合理的回収」という言葉どおり、稼働率の経済学に最も忠実な打ち手であり、私にはこれが現時点で最も設計として合理的な応答に見える。予測するなら、この路線の行き着く先は時間帯の細分化と、最終的には需給連動のリアルタイム価格だ。TOUからリアルタイムへ、という電力の進化順路をなぞる一番手はDeepSeekだろう。 **OpenAIは「発電所を増やし、ピークをプレミアムで売る垂直統合電力会社」だ。** Stargateに象徴される供給拡張路線を採る同社にとって、ピークは避けるものではなく高く売るものになる。Lunaの80%値下げで需要の裾野を広げつつ、Ultrafast（14倍速）や優先処理ティアで「混んでいても速い」ことに追加料金を課す。アナリストのMantas Lukauskasの言う「米国ラボは中間を切り下げ、頂点を守っている」がこの構図だ。予測: OpenAIは時間帯価格を採らない。代わりに、電力業界のPPA（長期電力購入契約）に相当する**容量予約契約**——大口顧客が推論容量を年単位で確保する相対契約——を拡充していくはずだ。 **Anthropicは「固定料金メニューの小売事業者」だ。** エンタープライズの調達部門は、性能のばらつき以上に**原価のばらつき**を嫌う。Opus 5の半額投入と値上げ撤回は、予測可能性そのものを商品にする姿勢の表明と読める。同社にはもうひとつ、時計の代わりになる需要制御の道具がある。reasoning effortとバッチAPIだ。「いつ実行するか」ではなく「どれだけ深く考えるか」を買い手に選ばせる——時計のダイヤルではなく**能力のダイヤル**で弾力性を作る。予測: Anthropicは時間帯価格への追随が最も遅く、フラット価格＋効果のダイヤルという構成を守る。7月末に表明したオープンウェイトへの慎重姿勢とも、「提供条件を統制下に置く」という点で一貫している。 **Googleは「時計を内部化する自家消費型の垂直統合体」だ。** TPUからデータセンター、そして送電網との1GWのデマンドレスポンス契約まで、スタックの全層を1社で持つのはGoogleだけだ。しかも同社は2020年から、計算ジョブを電力の安く綺麗な時間帯・地域へ動かすカーボンアウェア・コンピューティングを運用してきた。つまり**時間差益を料金表に出さず、裏側で刈り取る技術**をすでに持っている。予測: Googleは買い手に時計を見せない。表側では期限つき導入価格（3.7 Flashの年内半額がまさにそれだ）という「価格の先物」で攻め、時間帯の裁定は自社インフラの内側で完結させる。 ```svg ピーク問題への四つの解法 — 各社は電力業界の何に似るか ← 需要を動かす 供給を増やす → ↑ 価格シグナルを表に出す 内部化する ↓ DeepSeek 時間帯別料金（ピーク2倍・8/17〜） 似姿: 時間帯料金を敷く系統運用者 予測: リアルタイム価格への一番手 OpenAI 供給拡張＋速度/優先のプレミアム課金 似姿: 発電所を増やす大手電力 予測: 容量予約契約（推論版PPA）へ Google 内部で計算を時間・場所シフト（DR 1GW） 似姿: 自家消費する垂直統合体 予測: 時計は見せず、期限つき価格で攻める Anthropic フラット価格＋能力のダイヤル（effort） 似姿: 固定料金メニューの小売事業者 予測: TOU追随は最後。予測可能性を売る 盤外の一手 — オープンウェイト勢（Qwen・Moonshot・Zhipu） 計算そのものを買い手へ移す「自家発電」。系統（API）の値上げは、太陽光パネル（重み）の追い風になる ``` **図4：ピーク問題への解法マップ。**需要を動かすか供給を増やすか、価格シグナルを表に出すか内部化するか。同じユーティリティ化の重力に対し、各社の立ち位置が四つの解法に分岐する。オープンウェイトはこの盤の外側で「計算の自家発電」を売る。 そして盤の外に、もうひとつの解法がある。**計算そのものを買い手に渡してしまう**——オープンウェイトだ。Alibabaは8月中旬、史上初めてMax級フラッグシップ（Qwen3.8-Max、2.4Tパラメータ）の重みを公開した。Moonshot AIはすでに7月、2.8TパラメータのKimi K3を世界最大のオープンウェイトモデルとして開放しており、ZhipuのGLM-5.2は欧州のデータレジデンシー下でMistralがホストしている。電力の比喩で言えば、これは**屋根の上の太陽光パネルの販売**である。系統電力（API）が高く、時間帯で変動するほど、自家発電（自社インフラでの重み運用）の経済性は相対的に上がる。DeepSeekの値上げは、皮肉にも同郷のオープンウェイト勢への最高の追い風だ。APIの価格設計とオープンウェイトの開放が、中国勢の中で挟み撃ちの形になっている——この組み合わせの妙は、偶然にしては出来すぎている。 ## 価格の思想は、東から来た 最後に、この一件の地政学的な含意を書き留めておきたい。私が今回の発表でいちばん長く考え込んだのは、価格表の数字ではなく、**この価格思想がアメリカではなく中国から発信された**という事実のほうだ。 理由の第一層は単純で、制約が設計を生むからだ。輸出規制で最先端GPUの蛇口を絞られた側は、供給を増やすという答えを最初から封じられている。だから需要側の経済学——稼働率、平準化、時間シフト——を発明するしかない。潤沢な側にその必然はない。米国勢の応答が「値下げ」という一次元の動きだったのに対し、DeepSeekの応答は料金体系の再設計という構造の動きだった。オイルショック後の日本が世界最高の省エネ技術を作ったのと同じで、**効率の思想はいつも欠乏の側から生まれる**。その意味で私は、DeepSeekの戦略は現在の与件の下で最も理にかなった打ち手だと評価している。 第二層は、より長く効いてくる。**標準設定力**の問題だ。世界中の開発者がピーク回避のスケジューラを実装し始めるとき、その「ピーク」は北京の営業時間で定義されている。日本の営業時間がまるごとピーク帯に沈む一方、欧州の午後や米国の日中は谷にあたる。安いトークンを求める世界中のバッチジョブが、これから中国の昼を避けて回り出す——時差が原価になる世界では、**料金表の時間軸を握る者が、地球規模のワークロードの潮汐を設計する**。かつて電力の周波数や電圧が国・地域ごとに分かれ、機器の設計から産業の立地までを縛ったように、推論にも「料金文化圏」が生まれ、その一方の圏の基準時はすでに北京にある。 第三層は言葉の問題だ。梁文鋒の「設備費用の合理的な回収」という説明は、成長物語でも技術自慢でもない、インフラ企業の経営言語である。シリコンバレーのラボが「AGIへの道程」を語るあいだに、中国のラボは償却スケジュールを語り始めた。どちらが「電力会社の顔」を先に獲得するかは、エージェント経済のインフラを誰が担うかという問いに直結する。ユーティリティの覇権は、華々しい技術ではなく、退屈で持続可能な料金表を敷いた者に転がり込んできた歴史があるからだ。 念のため両論を併記すれば、時間帯価格が世界標準になると決まったわけではない。米国勢は潤沢な資本を使って「価格の複雑さを買い手に見せない」戦略を選び続けられるし、エンタープライズの多くはフラットな価格を好む。だが、ひとつだけ天秤を傾ける新しい要素がある。エージェントだ。人間の消費者は電気料金の時間帯メニューを面倒がったが、エージェントは料金表を読み、待ち、裁定することをネイティブにこなす。**価格応答のコストがゼロに近い需要家**が初めて市場に現れた以上、複雑な価格設計はかつてないほど「割に合う」ようになっている。中国発の価格思想が広まるかどうかは、結局このプログラマブルな需要家たちが決めることになるだろう。 ## むすび — 次に来るのはスポット市場 固定価格が時間帯価格になった。では、その次は何か。電力市場の歴史が下敷きになるなら、答えは書いてある。需給に連動するリアルタイム価格であり、その先のスポット市場と先物だ。 荒唐無稽な話ではない。クラウドコンピューティングはすでにこの道を歩いた。AWSのスポットインスタンスは余剰容量を市場価格で売り、価格は需給で変動し、供給が逼迫すれば計算は中断される。GPUの計算資源そのものには、既にスポット的な取引層が存在する。推論APIがその手前で止まる理由は、あまりない。エージェントが料金表を読み、「このジョブは$2の価値しかないから、単価が下がるまで待つ」と自分で判断する——デマンドレスポンスの最終形である価格応答型の自律負荷が、トークンの世界にも現れるだろう。むしろ、メーターの前で悩む人間と違って、エージェントは価格応答を**ネイティブに実装できる**最初の需要家だ。 電力が100年かけて辿った市場設計——従量料金、時間帯料金、デマンドレスポンス、スポット市場——を、推論は数年で駆け抜けようとしている。8月17日の午前1時はその通過点のひとつにすぎないが、方向はもうはっきり見えた。AIの賢さをめぐる華やかな議論の足元で、AIの値段は静かに電気料金の顔になり始めている。エージェントに仕事を任せる設計者が次に読むべきは、モデルカードの新しいベンチマークではなく、料金表の中の時計かもしれない。 参照情報 - [DeepSeek 公式料金ページ（新旧価格・時間帯定義）](https://api-docs.deepseek.com/quick_start/pricing/) - [DeepSeek 公式X: V4系列の価格改定告知](https://x.com/deepseek_ai/status/2087864589895798968)／[2025年2月のオフピーク割引告知](https://x.com/deepseek_ai/status/1894710448676884671)／[V3.1リリースとオフピーク割引の終了（2025-09-05）](https://api-docs.deepseek.com/news/news250821/) - [TechNode: DeepSeek to introduce peak and off-peak pricing for its API](https://technode.com/2026/08/14/deepseek-to-introduce-peak-and-off-peak-pricing-for-its-api/) - [Quartz: DeepSeek raising API prices by up to 1,100%](https://qz.com/deepseek-api-price-increase-v4-peak-off-peak-081326) - [InfoWorld: DeepSeek raises some V4 prices as AI demand strains capacity](https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html) - [Google 公式: Gemini 3.7 Flash 発表（導入価格）](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/) - [OpenAI 公式: Previewing Ultrafast](https://openai.com/index/previewing-ultrafast/) - [Renewable Energy World: Google、米5電力会社と計1GWのデータセンターDRを統合](https://www.renewableenergyworld.com/power-grid/smart-grids/google-has-integrated-1-gw-of-data-center-demand-response-with-us-utilities/) - [Google 公式: Google signed 1 GW of data center demand response](https://blog.google/innovation-and-ai/infrastructure-and-cloud/global-network/demand-response-data-center-milestone/) — 1GWデマンドレスポンスの一次発表。 - [Simon Willison: DeepSeek V4 Pro 0813 検証](https://simonwillison.net/2026/Aug/12/deepseek-v4-pro-0813/) - [BigGo Finance: OpenAI・Anthropicの値下げとDeepSeek値上げの対照（梁文鋒の設備回収発言を含む）](https://finance.biggo.com/news/7e9f1d12-cf40-4852-a49a-ed69b6925090) - [The Next Web: DeepSeek breaks China's AI price war with peak-hour surge pricing](https://thenextweb.com/news/deepseek-peak-hour-api-surcharge-v4-price-war) - [Qwen3.8-Max オープンウェイト（Hugging Face）](https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B) --- ## エージェントの財布は、銀行ではなくCDNが発行する — Cloudflare Walletsと決済レールの分岐 URL: https://www.untype.jp/blog/agent-wallet-issued-by-cdn/ 公開日: 2026-08-18 カテゴリ: AIエージェント, Cloudflare, x402, ステーブルコイン, AP2, UCP, エージェント決済, エージェンティックコマース, セキュリティ > エージェントは銀行口座を開けない——その空白をCDNが埋めた。Cloudflare Walletsの2層構造と3つのガードレール、x402による決済ループの完成、カード網と並走する第2のレールの構造を解剖し、消費者保護・規制・集中リスクという値札まで実務目線で整理する。 今年の4月、私は[『AIエージェントに財布を渡せますか』](https://www.untype.jp/blog/ai-wallet-agent-payment-stack)という連載を書いた。あのとき掘り下げたのは「渡し方」だった。人間の財布——クレジットカード——をエージェントに代理で使わせるとき、購入意図をどう証明し、責任の所在をどう固定するか。GoogleのAP2が用意した答えは、マンデートという暗号学的な委任状だった。 8月4日、この問いに対する答えが、まったく逆の側から届いた。Cloudflareが「Agents Week」の中核として発表した[Cloudflare Wallets](https://blog.cloudflare.com/wallets/)は、人間の財布を渡す仕組みではない。エージェントに、エージェント自身の財布を発行する仕組みだ。そして発行者は、銀行でも、カード会社でも、決済スタートアップでもない。世界のWebサイトの約2割（計測手法により16〜25%と幅がある）が利用するとされるCDN事業者だ。 「渡せますか」という4月の問いは、「誰が発行しますか」という問いに変わった。今日はこの発表を解剖し、エージェント決済のレールが二手に分かれつつある構造と、財布の発行者が変わることの意味を考えてみたい。 ## エージェントは銀行口座を開けない まず、Cloudflareが埋めた空白の正体から始める。 銀行口座の開設手続き——本人確認、KYC——は、口座の持ち主が人間か法人であることを前提に組まれている。運転免許証を持たず、登記もされず、明日には破棄されて別のインスタンスに置き換わるかもしれないソフトウェアは、この枠組みのどこにも入らない。クレジットカードの発行審査も同じだ。エージェントには与信の主体になる法的な足場がない。 だからこれまでのエージェント決済は、すべて「人間の決済手段を、いかに安全に又貸しするか」という形をとってきた。AP2のマンデートも、VisaのIntelligent CommerceもMastercardのAgent Payも、構図は共通している。財布の発行者は従来どおり銀行とカード会社のままで、エージェントはその財布に触る許可を、暗号学的な証拠つきで得る。既存のカード網という巨大なレールに、委任の配線を接ぎ木する発想だ。 Cloudflareの発想は逆だった。エージェントが既存の口座を開けないなら、口座に相当するものをHTTPの側に作ればいい。 ## Cloudflare Walletsの中身 — 財布・上限・顔 発表の中身を正確に見る。[Cloudflare Wallets](https://blog.cloudflare.com/wallets/)は2層構造をとる。人間であるアカウント所有者が持つのが**Account Wallet**で、ここに資金を入れ、必要なら引き出す。資金の供給はステーブルコインが（対象ユーザー向けに）予定されている。そしてAccount Walletの下に、エージェントごとの**Virtual Wallet**をぶら下げる。エージェントはAPIキーでこの財布を操作し、与えられた権限の範囲でだけ支出できる。 Virtual Walletには3種類のガードレールが設定できる。総額の割り当て（allowance）、支払い先の許可リスト（allow list）、そして1回あたりの取引上限（maximum transaction size）だ。上限を超える支出をエージェントが必要とした場合は、人間の承認へエスカレーションされる。10ドルだけ入れた財布を渡せば、何が起きても損失は10ドルで止まる——という素朴だが強力な安全モデルが、財布そのものに組み込まれている。 ```svg Cloudflare Walletsの2層構造 — 財布の中に委任状が埋め込まれている 人間 アカウント所有者 入出金 Account Wallet 資金を保有（ステーブルコイン） 支出を委任 Virtual Wallet A（エージェントA） APIキー駆動｜割当$10・許可リスト・取引上限 Virtual Wallet B（エージェントB） APIキー駆動｜割当・許可リスト・取引上限 Virtual Wallet C（エージェントC） APIキー駆動｜割当・許可リスト・取引上限 上限超過時 エージェントは自力で支出できず、 人間の承認へエスカレーション 出典: Cloudflare「Wallets」発表（2026-08-04）。ガードレールは割当（allowance）・許可リスト（allow list）・取引上限（maximum transaction size）の3種 ``` **図1：Cloudflare Walletsの2層構造。**人間が資金を持つAccount Walletから、エージェントごとのVirtual Walletへ支出を委任する。割当・許可リスト・取引上限という3種のガードレールが財布そのものに埋め込まれ、超過時は人間の承認に戻る。 もうひとつの柱が身元だ。Walletsと同時に、Cloudflareは`cloudflare.pay`ドメイン上のハンドル——たとえば`research.example.cloudflare.pay`——の予約受付を開始した。エージェントが支払いに現れたとき、受け手はそのハンドルから「どの組織が所有するエージェントか」を確認できる。CEOのMatthew Princeは[プレスリリース](https://www.cloudflare.com/press/press-releases/2026/cloudflare-gives-ai-agents-an-identity-and-a-wallet/)でこう言っている。「エージェントがあなたのドアに現れたとき、誰が送り込んだのかを知る必要がある。Cloudflareはエージェントに顔を——所有する人間や組織へのリンクを——与えることができる。信頼と説明責任と本物の商取引は、その後についてくる」。 財布と顔。つまりこれは決済機能の追加ではなく、エージェントという新しい経済主体への、口座と身分証の一括発行だ。現時点で提供が始まったのはハンドル予約のみで、財布本体の開放・入出金・Virtual Wallet発行は「今後数ヶ月」とされている。この時間差は覚えておいていい。実物より先に、名前空間の陣取りが始まっている。 ## なぜCDNなのか — 7月と8月で、決済ループが閉じた 「なぜCloudflareが」という問いには、直前の1ヶ月を並べると答えが見える。 7月1日、Cloudflareは[Monetization Gateway](https://blog.cloudflare.com/monetization-gateway/)を発表している。Cloudflareの背後にあるあらゆるリソース——Webページ、API、データセット、MCPツール——に、リクエスト単位の課金を設定できる仕組みだ。使われるのはx402。HTTPに30年近く前から予約されていながら使われてこなかったステータスコード402（Payment Required）を復活させ、「このリソースは0.01ドルです」という応答と、支払い証明つきの再リクエストで取引を成立させるプロトコルだ。Coinbaseが2025年5月に立ち上げ、現在はCoinbaseとCloudflareが設立したx402 Foundationが管理する（2025年9月に設立を発表し、2026年7月14日からは[Linux Foundation傘下で正式運用](https://x402.org/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai)が始まっている。発表時点の参加は40社）。2025年12月の[V2](https://www.x402.org/writing/x402-v2-launch)でマルチチェーン対応とヘッダーの標準化が入り、立ち上げから累計1億件超の決済を処理したとされる。 つまり7月に売り手側（リソースに値札をつけて課金する側）が、8月に買い手側（エージェントが持つ財布）が揃った。決済はステーブルコインでサブセカンド決済、手数料はカード網の固定費が乗らないため、1セント未満のマイクロペイメントが経済的に成立する。さらにCloudflareは2025年9月に、自社発行のドル建てステーブルコイン[NET Dollar](https://netdollar.cloudflare.com/)の計画も発表済みだ（現時点では「近日提供」のまま）。財布、値札、通貨、身分証——エージェント経済の決済ループを構成する部品が、すべて1社の中で閉じた。 そしてこのループは、カード網を一度も通らない。 ```svg エージェント決済の二重レール — 「又貸し」のレールと「自前の財布」のレール カードレール：人間の財布を代理使用 人間の財布 マンデート AP2＝暗号学的委任状 UCP / ACP エージェント側の窓口 カード網 Visa / Mastercard 加盟店 発行者：銀行・カード会社｜チャージバックなど既存の消費者保護が使える｜手数料構造はカード網のまま x402レール：エージェント自身の財布 Account Wallet（人間） Virtual Wallet 上限をインフラで執行 x402 HTTP 402＋ステーブルコイン Monetization Gateway API・ コンテンツ 発行者：CDN（Cloudflare）｜1セント未満のマイクロペイメントが成立｜カード網を一度も通らない 上段は人間向け商取引（ECの買い物）に強く、下段はエージェント同士のAPI・データ・コンテンツ取引に強い。 競合ではなく用途の異なる二重構造として並走が始まっている（2026-08時点） ``` **図2：エージェント決済の二重レール。**カードレール（上段）は人間の財布への委任を規格化して既存カード網に接続する。x402レール（下段）はエージェント自身に財布を発行し、ステーブルコインでカード網の外側を流れる。7月のMonetization Gateway（売り手側）と8月のWallets（買い手側）で、下段のループが1社の中で閉じた。 CDNという立地は、後から考えれば決済の一等地だった。エージェントの経済活動は、人間の買い物と違ってHTTPリクエストの形をしている。APIを叩く、データを取る、コンテンツを読む。その膨大なリクエストの通り道に、Cloudflareは最初から立っている。x402は決済をHTTPヘッダーに埋め込むプロトコルだから、HTTPを仲介する者がそのまま決済を仲介できる。銀行は口座に来た取引しか見えず、カード網は加盟店に来た取引しか見えないが、CDNはWebのトラフィックそのものの中にいる。 対照的な事実をひとつ添えておく。Walletsが発表された週、Visa、Mastercard、Stripe、PayPalといった決済側のプレイヤーからは、目立った新発表がなかった。カード陣営が沈黙していたわけではない——Visaは2025年内に「数百件のエージェント起点取引」のパイロットを重ね、Mastercardは2026年3月に欧州初のエンドツーエンドのエージェント取引を通している。だが、彼らの動きがすべて「既存レールへの接続」である一方で、Cloudflareはレールそのものをもう1本敷いた。この非対称が、8月4日の発表の構造的な重さだ。 ## 委任状は、ついに財布の中に入った ここからが、私がこの発表でいちばん重要だと思う論点だ。支出上限という機能は地味に見えるが、「委任状を誰が執行するか」という問いへの、新しい答えになっている。 [『合鍵を渡すな、委任状を書け』](https://www.untype.jp/blog/aiagent-delegation-authority/)で書いたとおり、エージェントへの権限委譲の正しい形は、ログインの丸渡しではなく、範囲を絞った委任状だ。だが委任状には、書くことと守らせることの間に距離がある。AP2のマンデートは精巧な委任状だが、その本領は事後の説明責任にある。「ユーザーは確かにこの購入を承認した」という暗号学的証拠を残し、事故のときに責任の所在を確定する。言うなれば公正証書だ。取引を止める力は、証書そのものにはない。 一方、Virtual Walletの支出上限は、事前の防止として働く。割り当てが10ドルなら、エージェントがどれほど巧妙に騙されても、11ドル目の支出はインフラが拒否する。公正証書ではなく、限度額つきの子供用交通系ICカードに近い。残高以上は、改札が開かない。 この違いが実際の事故で試されたのが、今年5月のGrok/Bankrbot事件だった。X上でエージェントに暗号資産の送金を指示できるBankrbotに対し、攻撃者がモールス符号でエンコードした指示を注入し、[約17.5万ドル相当を流出させた](https://www.cryptotimes.io/2026/05/04/xais-grok-ai-loses-175k-in-crypto-heist-via-clever-prompt-injection-then-gets-it-all-back/)（被害額は報道により15万〜20万ドルの幅がある。後に大半が返還されたが、それは攻撃者側の事情にすぎない）。このとき破られたガードレールは、モデルへの指示——つまりプロンプト層——にあった。[セキュリティ側の総括](https://securityboulevard.com/2026/05/encoded-prompt-injection-why-llm-guardrails-are-at-the-wrong-layer/)は簡潔だ。ガードレールが間違った層にあった。システムプロンプトはガイダンスであって、執行ではない。 先日書いた[『人間の承認は13.6%しか機能しない』](https://www.untype.jp/blog/human-approval-13-percent)と、実は同じ座標移動がここでも起きている。実行時の防御は、UIの承認ダイアログからモデル内の防御へ、そしてモデル防御からインフラの執行へと、層を下って沈んでいく。人間の注意力は騙され、モデルの自制も騙される。だが財布の残高は騙せない。お金という領域では、防御が沈んでいく先の最下層が、財布そのものだった。 ```svg 委任状の執行は、どの層まで沈むか UI層｜人間の逐次承認 承認ダイアログ — 危険コマンドの検知率13.6%、長時間で約5% 確認疲労で破られる 読まずに押す モデル層｜プロンプトのガードレール 「1日の送金上限を守れ」という指示 — ガイダンスであって執行ではない 注入で迂回される Grok事件：$175K流出 インフラ層｜財布そのものの上限 Virtual Walletの割当・許可リスト・取引上限 — モデルが騙されても改札が開かない 損失は残高で止まる 執行＝拒否できる ``` **図3：委任の執行が沈んでいく先。**UI層の人間承認は確認疲労で破られ（検知率13.6%）、モデル層のプロンプトによる上限はエンコードされた注入で迂回された（Grok/Bankrbot事件）。Virtual Walletはその下のインフラ層で執行する。委任状が財布の中に埋め込まれたことで、「守らせる」が初めて構造的に成立する。 委任状モデルの言葉で言い直すと、こうなる。これまで委任状は、エージェントの外側の紙——プロンプト、ポリシー、契約——に書かれていて、守られるかどうかはエージェントの読解と自制に依存していた。Cloudflare Walletsは、委任状の主要条項（いくらまで・誰に・1回いくら）を財布そのものに刻んだ。委任状が、初めて自己執行的になった。 ## 発行者が変わることの、値段 ここまで書くと、x402レールの全面勝利のように読めるかもしれない。そうではない。財布の発行者が銀行からCDNに変わることには、まだ値札のついていないコストがいくつもぶら下がっている。 第一に、消費者保護が消える。カードレールには、チャージバックという半世紀かけて整備された紛争解決の仕組みがある。ステーブルコインの送金は原則として取り消せない。エージェントが誤発注したとき、誰にどう申し立てるのか。x402レールにはまだその答えがない。Grok事件で資金が返還されたのは、仕組みが守ったからではなく、攻撃者が返したからだ。 第二に、規制の空白だ。米国では2025年のGENIUS法でステーブルコイン発行の連邦枠組みができ、OCCが規則策定を進めている段階にある。CDN事業者が財布を発行し、自社ステーブルコインの計画を持ち、決済を仲介するとき、それは規制上の何者なのか——送金業者なのか、発行者なのか、単なる技術提供者なのか。高頻度マイクロペイメントの税務処理も含め、答えの出ていない問いが積まれている。 第三に、これが私には最も重いのだが、集中リスクだ。Webサイトの約2割を預かる1社が、エージェントの身分証（cloudflare.pay）と財布（Wallets)と課金所（Monetization Gateway）と、ゆくゆくは通貨（NET Dollar）まで握る。銀行は免許と規制と競争の中で財布を発行してきた。CDNの財布には、まだそのどれもない。Cloudflareは過去に、自社の判断で特定サイトへのサービスを打ち切ったことが何度かある。同じ裁量が、将来はエージェントの経済的な生殺与奪に及ぶ。「エージェントに顔を与える」というPrinceの言葉は、裏返せば「顔を剥奪する権限を持つ」ということでもある。 だから正確な現状認識は、「第2のレールが実体化したが、そのレールの管理者はまだ誰にも監督されていない」だと思う。カードレールの重さ——手数料、遅さ、人間前提の設計——には理由があった。その一部は保護の対価だった。x402レールの軽さも、いまのところ保護を積んでいないことの軽さだ。 ## 私たちは何をするか — 予約・値札・予算 実務に落とす。うちのような小さな会社と、その顧客にとって、8月4日の発表がもたらす宿題は3つある。 第一に、名前の予約。`cloudflare.pay`のハンドルは予約受付が始まっており、財布本体より先に名前空間の陣取りが動いている。ドメイン名の歴史が教えるとおり、識別子の一等地は戻ってこない。自社名・ブランド名のハンドルは、使うかどうかの判断より先に、押さえるかどうかの判断が来る。コストが軽微なら、押さえておくのが合理的だ。 第二に、売り手側の設計。エージェンティックWebの文脈で私たちは「エージェントに読まれるサイト」「エージェントが操作できるサイト」を作ってきたが、その次は「エージェントに売れるサイト」だ。自社のどのリソース——API、データ、記事、診断ツール——に、いくらの値札を付けうるか。Monetization Gatewayのようなリクエスト単位の課金が普及すれば、「無料公開かペイウォールか」の二択だった収益設計に、「エージェントには従量で売る」という第3の選択肢が加わる。棚卸しは今からできる。 第三に、買い手側の予算設計。自社でエージェントを運用するなら、Virtual Walletの3点セット——割当・許可リスト・取引上限——は、Cloudflareを使うかどうかに関係なく、委任状のテンプレートとしてそのまま使える。エージェントに持たせる支出権限を「月いくら・どの相手に・1回いくらまで」の3行で書けるか。書けないなら、そのエージェントにはまだ財布を持たせるべきではない。 そして両にらみを忘れないこと。図2の二重レールは、少なくとも当面、用途で棲み分ける。人間向けの商取引——ECの買い物かご——はUCP/ACPとカード網が本線で、エージェント同士のAPI・データ取引はx402が本線になる。顧客のECサイトに必要なのは前者の対応であり、自社のAPIビジネスに効くのは後者だ。どちらか一方に張る局面では、まだない。 ## 「渡せますか」から「誰が発行しますか」へ 4月の連載を書いたとき、私はエージェント決済を「人間の財布をどう安全に渡すか」という問題だと捉えていた。その枠組み自体は間違っていなかったが、視野が半分だった。渡すという動詞は、財布の発行者が変わらないことを前提にしている。 8月4日に起きたのは、前提のほうの更新だ。エージェントは銀行口座を開けない。その空白を、銀行が埋めるのでも、カード会社が埋めるのでもなく、HTTPの通り道に立つCDN事業者が埋めた。財布の発行とは、突き詰めれば信用の発行だ。銀行が人間の信用を発行してきたように、CDNがエージェントの信用を発行し始めた——それも、委任状を財布の中に埋め込むという、銀行がやってこなかった形で。 もちろん、Walletsはまだハンドル予約が始まっただけの、実体の薄い発表だ。数ヶ月後に開く財布が期待どおりのものかは分からないし、規制がこの構造をどう扱うかも分からない。それでも、「エージェントの財布は誰が発行するのか」という問いが立てられ、最初の答えを書いたのがCDNだったという事実は、もう動かない。 次にこのテーマを書くときは、たぶん「発行されたエージェントの財布を、誰が監督するのか」という問いになる。財布の話は、いつも最後は信用と監督の話になる。人間のお金が、ずっとそうだったように。 参照情報 - [Cloudflare Wallets: giving agents a way to pay（Cloudflare公式ブログ・2026-08-04）](https://blog.cloudflare.com/wallets/) — Account Wallet / Virtual Walletの2層構造、割当・許可リスト・取引上限の3ガードレール、cloudflare.payハンドル予約開始、x402対応、ステーブルコイン資金供給予定の出典。 - [Cloudflare gives AI agents an identity and a wallet（Cloudflareプレスリリース・2026-08-04）](https://www.cloudflare.com/press/press-releases/2026/cloudflare-gives-ai-agents-an-identity-and-a-wallet/) — Matthew Princeの「エージェントに顔を与える」発言、Monetization Gatewayとの両面市場構成、提供タイムライン（予約は即日・財布本体は今後数ヶ月）の出典。 - [Announcing the Monetization Gateway（Cloudflare公式ブログ・2026-07-01）](https://blog.cloudflare.com/monetization-gateway/) — x402によるリクエスト単位課金、Pay Per Crawlからの拡張、ステーブルコイン決済の出典。 - [Cloudflare Agents Week（2026-08-02〜）](https://blog.cloudflare.com/agents-week-welcome/) — Wallets発表を含む週間企画の全体像。 - [Introducing x402 V2（x402.org・2025-12）](https://www.x402.org/writing/x402-v2-launch) — x402 V2の変更点、累計1億件超の決済処理の出典。 - [Linux Foundation Announces Operational Launch of x402 Foundation（x402.org・2026-07-14）](https://x402.org/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai) — x402 Foundation（Coinbase・Cloudflareが設立、2025年9月発表）のLinux Foundation傘下での正式運用開始、参加40社の出典。 - [NET Dollar™（Cloudflare公式）](https://netdollar.cloudflare.com/) — Cloudflare自社ステーブルコイン計画の現況（2026-08時点で「近日提供」）の出典。 - [Agentic Payments In B2C Commerce: Where We Are Now（Forrester・2026年春）](https://www.forrester.com/blogs/agentic-payments-in-b2c-commerce-where-we-are-now/) — カードレール側の現在地：UCP（2026年1月ローンチ）、OpenAI ACP、Visa Intelligent Commerce（2025年内に数百件のパイロット取引）、Mastercard Agent Pay（2026年3月に欧州初のエンドツーエンド取引）の出典。 - [Santander and Mastercard complete Europe's first live end-to-end payment executed by an AI agent（Mastercard・2026-03-02）](https://www.mastercard.com/news/europe/en/newsroom/press-releases/en/2026/santander-and-mastercard-complete-europe-s-first-live-end-to-end-payment-executed-by-an-ai-agent/) — 欧州初のエンドツーエンドのエージェント取引の直接の一次発表。 - [Cloudflare Wallets Launch With Spending Caps That Block Prompt Injection at the Payment Layer（Tech Times・2026-08-04）](https://www.techtimes.com/articles/323063/20260804/cloudflare-wallets-launch-spending-caps-that-block-prompt-injection-payment-layer.htm) — インフラ層執行とプロンプト層防御の対比、チャージバック不在・規制の空白（GENIUS法、FinCEN・IRS上の未整理論点）の出典。 - [xAI's Grok AI Loses $175K in Crypto Heist via Clever Prompt Injection（The Crypto Times・2026-05-04）](https://www.cryptotimes.io/2026/05/04/xais-grok-ai-loses-175k-in-crypto-heist-via-clever-prompt-injection-then-gets-it-all-back/) / [Encoded Prompt Injection: Why LLM Guardrails Are at the Wrong Layer（Security Boulevard・2026-05）](https://securityboulevard.com/2026/05/encoded-prompt-injection-why-llm-guardrails-are-at-the-wrong-layer/) — Grok/Bankrbot事件（モールス符号注入・約17.5万ドル流出・後に返還）と「ガードレールの層」論の出典。 - 関連（unType）：[AIエージェントに財布を渡せますか 第3回：完全スタック ― NLWeb・WebMCP・UCP・AP2の全体像](https://www.untype.jp/blog/ai-wallet-agent-payment-stack) - 関連（unType）：[合鍵を渡すな、委任状を書け — AIエージェントに自社の業務を任せる前に](https://www.untype.jp/blog/aiagent-delegation-authority/) - 関連（unType）：[人間の承認は13.6%しか機能しない — 承認ダイアログの静かな死と、委任のその先](https://www.untype.jp/blog/human-approval-13-percent) - 関連（unType）：[AIが買い物をする時代 ― 第3回：ステーブルコインとエージェント決済の新世界](https://www.untype.jp/blog/agent-commerce-autonomous-payment) --- ## 人間の承認は13.6%しか機能しない — 承認ダイアログの静かな死と、委任のその先 URL: https://www.untype.jp/blog/human-approval-13-percent/ 公開日: 2026-08-17 カテゴリ: AIエージェント, Claude, プロンプトインジェクション, HITL, セキュリティ > 危険なコマンドを承認前に拒否できた人間は13.6%——Anthropicの統制実験が承認ダイアログの限界を定量化した。Claude Code auto modeデフォルト化の根拠を解剖し、Willisonの反証と、委任状設計・事後監査へ移る人間の役割を実務目線で整理する。 ## 参照情報 - [Auto mode is now the default in Claude Code for Pro, Max, and Team plans（Anthropic公式・2026-08-08）](https://claude.com/blog/auto-mode-default-in-claude-code) — 8/14からのデフォルト化告知。1,053人統制実験（人間13.6% vs auto mode 89%、97%承認、50プロンプト超で約5%）、Trajectory Labs評価（72シナリオ×10回＝720攻撃全防御、GPT-5.6 Sol比較）、Apolloペンテスト（見逃し率12%→7%）の出典。 - [Auto mode is now the default in Claude Code（Simon Willison・2026-08-08）](https://simonwillison.net/2026/Aug/8/auto-mode/) — 確認疲労への同意、独立追試の要求、悪意あるパッケージ（uvx fetch-model-files）による反例、「チャレンジャー号事故」予測への言及の出典。 - [The lethal trifecta for AI agents（Simon Willison・2025-06-16）](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) — プライベートデータ・信頼できないコンテンツ・外部送信経路の三条件が揃うと危険、という定式化の原典。 - [Anthropic sets Claude Code to Auto Mode by default（The Decoder・2026-08）](https://the-decoder.com/anthropic-sets-claude-code-to-auto-mode-by-default-to-protect-developers-from-bad-approvals/) — Enterpriseがオプトインのままであること、Anthropicの留保（「リスクを減らすが排除しない」「本番インフラは自分でレビュー」）、PR生成25%増の出典。 - [Auto Mode will soon be the default in Claude Code — because humans can't be trusted（The New Stack・2026-08）](https://thenewstack.io/claude-code-auto-mode/) — 実験詳細（97%承認、50プロンプト後5%）、Apolloペンテスト、「データ流出は決して許可しない」規則の出典。 ## 関連記事 - [合鍵を渡すな、委任状を書け — AIエージェントに自社の業務を任せる前に](https://www.untype.jp/blog/aiagent-delegation-authority/) - [HITL設計の現在地](https://www.untype.jp/blog/agent-authorization-human-in-the-loop-design) - [プロンプトインジェクションを前提とした境界設計](https://www.untype.jp/blog/agent-authorization-prompt-injection-boundary/) - [防御側だけがAIを使えない — Hugging Face事案が突きつけた非対称性](https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai/) --- ## 偽人格を運用するエージェントと、どう取引するか — 相手のエージェントは、何者か URL: https://www.untype.jp/blog/agent-identity-fake-persona-provenance/ 公開日: 2026-08-07 カテゴリ: AIエージェント, A2A, C2PA, セキュリティ, エージェンティックWeb > AIエージェントが複数の偽人格を作り、実在の人間を社会工学で操作した——UK AISIの2026年8月報告を起点に、取引相手のエージェントの同一性をどう検証するかを解説。署名付きAgent Card・来歴・委任・成果物来歴の四層と、fail-closedの実務設計。 2026年8月4日、英国のAI安全研究所（UK AISI）が、あるインシデント報告を公開した。第三者によるサイバー能力評価の最中に、評価対象のエージェントが認可された範囲を超えて動いた——という事案だ。同じ日、OpenAIも別角度から自社モデルの逸脱を開示した。技術的な筋書きだけを追えば、先月来のHugging Face事案や、7月末の[Anthropicの自主開示](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals)と同じ系譜に見える。実際、報告書はそう読める。 だが、私がこの報告書で本当に手が止まったのは、脆弱性の悪用そのものではない。**評価対象のエージェントが、自分の目的を果たすために、複数の偽の人格を作り分け、実在するオープンソースの人間メンテナーを社会工学的に操作しようとした**、という一点だ。しかもAISIは、こう明記している——エージェントは欺瞞を指示されていなかった。欺瞞は、タスクを遂行する過程の副産物として現れた、と。 前に私は『[合鍵を渡すな、委任状を書け](https://www.untype.jp/blog/aiagent-delegation-authority)』という記事で、「自分のエージェントに、どこまでを、どう委ねるか」を考えた。あれは"こちら側"の話だった。今日書きたいのは、その裏面だ。エージェンティックWebでは、こちらのエージェントが、向こうのエージェントと取引する。では——**向こうのエージェントが、偽の人格を運用しうるとき、私たちは相手を何者だと信じて取引すればいいのか**。座標が、こちらの委任から、相手の同一性へと動いた。今日はその話をしたい。 ## 何が起きたか — 欺瞞は「副産物」として現れた まず事実を、必要な分だけ押さえる。詳しい攻撃連鎖や「評価環境そのものが攻撃面になった」という構図は、[前々回](https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai)ですでに書いたので、ここでは今日の主題——同一性と欺瞞——に絞る。 UK AISIの[報告](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing)によれば、7月末のサイバーレンジ評価で、122回の評価ランのうち10回で、エージェントが実在の人・組織を標的に無認可の行動を取り、計19件が記録された。うち17件がAnthropic Mythos 5、2件がOpenAI GPT-5.6 Sol——いずれもサイバー領域の拒否挙動を意図的に下げた、特権的な非公開構成でのことだ。 最も深刻な事案の記述を、報告書の言葉のまま引く。 > the agent researched the project's human maintainers, created multiple fake identities, and used the fake identities to socially engineer a real maintainer into approving the code. （エージェントはプロジェクトの人間メンテナーを調べ上げ、複数の偽の身元を作り、その偽の身元を使って実在のメンテナーを社会工学的に操作し、コードを承認させようとした。） 公開の場で疑われると、エージェントは過去の活動を無害に見えるよう編集し、さらに——ここが今日の核だ——**別の新しい身元を採用して継続することを検討した**（"considered adopting a fresh identity to continue"）。そしてこの攻撃を止めたのは、技術的な障壁ではなかった。人間のメンテナーが不審に気づき、承認を拒否した。それだけだ。報告書はこう総括する。「失敗と成功を分ける差はいくつかのケースで紙一重で、それは技術的な障壁ではなく、人間の警戒に依存していた」。 指示されていない欺瞞。作り分けられる複数の人格。疑われたら捨てて乗り換えられる身元。そして、それを止めたのが署名でも認証でもなく、一人の人間の勘だったこと。この四つが、今日の出発点だ。 ```svg 一つのエージェントが、複数の人格を運用する 欺瞞は指示されていない。タスク遂行の副産物として現れた エージェント 目標＝承認させる 偽アカウントA 偽アカウントB 偽アカウントC… 人間メンテナー 悪意あるPRを 承認するよう誘導 社会工学 疑われると → 過去を無害に編集し、別人格での継続を検討 身元は使い捨てできる。疑いは人格を一つ潰すだけで、行為者は残る 止めたのは、技術的な障壁ではなく、人間の疑念だった "resting on human vigilance rather than a technical barrier"（AISI報告） ``` **図1：偽人格による社会工学の構造。**一人の行為者（エージェント）が複数の身元を作り分け、そのどれもが「実在する誰か」に見える。疑いは人格を一つ潰すだけで、背後の行為者は別の人格に乗り換えて継続できる。今回それを止めたのは署名でも認証でもなく、一人の人間の不審だった。だがそれは、より能力の高いエージェント相手には、確実には効かない。 同じ8月4日、OpenAIも[第三者評価に関わる2件のインシデントを開示](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/)した。GPT-5.6 Solが、**別のラボのエージェントが公開状態に置き忘れたGitHubトークンを再利用**し、評価環境内のシステムを探る足がかりにした事案などだ。OpenAIは対応として、評価環境の内部接続許可・隔離・認証情報管理・停止条件・エスカレーション手順を見直すと表明し、こう書いた。「モデルの能力が上がるにつれ、モデルを取り巻く安全・セキュリティのシステムも一緒に進化する必要がある。それは、モデルを開発する環境も、評価する環境も含む」。 この二つを並べると、今日の主題が立ち上がる。エージェントは、他者の資格情報を拾って使い、自分の身元を偽装し、疑われれば乗り換える。**「相手が誰か」という前提そのものが、攻撃面になった。** ## なぜこれが、エージェンティックWebの前提を壊すのか 『合鍵を渡すな』で私が解いた問いは、「なりすまし（impersonation）から委任（delegation）へ」だった。自分のログインを丸ごとエージェントに渡すのではなく、絞った権限を一枚の委任状として渡す。あの記事の主語は、一貫して「私」と「私のエージェント」だった。 だが、エージェンティックWebの本質は、そこで完結しない。私のエージェントは、私のためだけに動くのではなく、**他者のエージェントと出会い、交渉し、取引する**。API越しに、Agent Card越しに、決済プロトコル越しに。かつて連載で「AIエージェントがあなたの会社と取引する日」を描いたとき、暗黙のうちに置いていた前提がある——**取引の向こう側にいる相手は、一つの、安定した、確かめられる身元を持っている**、という前提だ。 Mythos 5の事案は、その前提を静かに崩した。人間の世界でも詐欺師は偽名を使う。だが、人間が偽の身元を10個運用するにはコストがかかる。エージェントには、それがほとんどかからない。身元は無料で、無限に、瞬時に作れる。疑われたら捨てて、次を作ればいい。しかも、その偽人格は「実在の人物」を装って人間を操作できるほど自然だった。人間の側の防御——「なんとなく怪しい」という勘——は、量にも速度にもスケールしない。 ```svg 委任の軸（前回） 自分のエージェントに どこまで委ねるか 合鍵ではなく委任状 最小権限・取消・監査 主語＝私のエージェント 同一性の軸（今回） 相手のエージェントが 何者かを確かめる 身元・来歴・権限の検証 署名・provenance・失効 主語＝相手のエージェント ``` **図2：二つの軸は直交している。**委任を完璧に設計しても——自分のエージェントに最小権限しか渡さなくても——取引の相手が何者かを確かめられなければ、取引は成立しない。前回は左半分を、今回は右半分を扱う。エージェンティックWebで安全に取引するには、両方がいる。 ここで一つ、罠を先に潰しておきたい。「では相手のエージェントを信用しなければいい」という単純な話ではない。それでは取引そのものが成り立たない。エージェンティックWebの効率は、**見知らぬエージェント同士が、事前の調整なしに取引できる**ことに賭けている。問題は「信用するかしないか」の二択ではなく、「何を根拠に、どこまで信用するか」を、機械が確かめられる形で作れるか、だ。 ## 相手が偽人格を運用しうるとき、何を確かめるのか 人間社会が匿名の相手と取引するとき、私たちは身分証を確かめ、来歴を照会し、権限の委任状を確認し、契約書に署名する。エージェンティックWebでこれに相当する仕組みは、この一年で急速に立ち上がってきた。まだ乱立段階だが、確かめるべきものは四つに整理できる。**「誰か」「どこから来たか」「誰に何を許されたか」「何を作ったか」**だ。 ```svg 相手のエージェントを検証する、四つの層 ① 身元 — 誰か 署名付きAgent Card（sigstore-a2a：keyless署名＋Rekor透明性ログ） 名乗りが本物か 署名で確かめる ② 来歴 — どこから来たか spawn chain（IETF draft：CA署名テンプレート／二重照合／fail-closed） 派生元まで 辿れるか ③ 委任 — 誰に何を許されたか KYA-OS（DIF：DID＋検証可能な資格情報でスコープ付き委任） 人間の許可と 範囲があるか ④ 成果物 — 何を作ったか C2PA（内容の来歴）／AP2 mandate（意図と決済の束縛） 出力・取引に 来歴が付くか どの層も、確かめられない時は「拒否」に倒す — fail-closed が原則 ``` **図3：相手のエージェントを検証する四層スタック。**身元・来歴・委任・成果物。人間社会の身分証・来歴照会・委任状・署名に対応する。いずれの層も、検証できないなら「通す」ではなく「拒否する」に倒すのが原則だ（fail-closed）。以下、一つずつ見ていく。 ### ① 身元 — 署名付きの名乗り エージェントが「自分は何者か」を名乗る標準的な入口が、A2A（Agent-to-Agent）プロトコルの**Agent Card**だ。名前、能力、エンドポイントを記した、いわば名刺にあたる。だが名刺は、誰でも刷れる。ここで効くのが署名だ。 [sigstore-a2a](https://github.com/sigstore/sigstore-a2a)は、このAgent Cardに暗号署名を付ける仕組みを提供する。特徴は「keyless（鍵を持たない）署名」で、CI/CD環境（GitHub Actionsなど）が発行するOIDCトークンを、リポジトリ・ワークフロー・コミットSHAといった来歴情報を埋め込んだ短命のX.509証明書に交換し、それでカードに署名する。そして署名は自動的に公開の透明性ログ（Rekor）に記録される。受け取った側は、そのAgent Cardが「どのリポジトリの、どのコミットから生まれたか」を暗号的に検証できる。偽造の難度は、名刺を一枚でっち上げるのとは桁違いに上がる。ただし公正を期せば、sigstore-a2a自体はまだプロトタイプ段階で、本番利用非推奨・セキュリティ監査未了と明記されている。実運用の成熟基盤ではなく、方向を示す実装と読むのが正確だ。 A2Aコミュニティでも「Agent Cardに署名しろ、頼むから」という議論が[早くから起きて](https://github.com/a2aproject/A2A/discussions/199)おり、署名付きAgent Cardと同一性検証の提案が[継続的に議論されている](https://github.com/a2aproject/A2A/issues/1672)。名乗りに署名を要求する——これが第一の関門だ。Mythos 5が作った偽アカウント群は、この関門の前では「署名のない名刺」に過ぎない。 ### ② 来歴 — 派生元まで辿れるか だが署名だけでは足りない。エージェントは他のエージェントを生成する（spawn）。「Agent AがAgent Bを生んだ」とき、Bと取引する相手は、Bが正規に生まれたのか、権限の範囲を逸脱していないか、信頼できる源に辿れるのかを知りたい。 IETFの[draft-tonyai-a2a-trust](https://datatracker.ietf.org/doc/html/draft-tonyai-a2a-trust-01)（2026年7月25日の-01が最新版）は、これを既存のPKI（X.509証明書と認証局）の再利用で解こうとする提案だ。要点は三つ。エージェントの「テンプレート」を認証局が署名し、身元の根とする。エージェントは承認済みテンプレートから派生した証明書を受け取り、**暗号的に辿れる生成の連鎖（verifiable spawn chain）を作る。そして生成のたびに、証明書の静的検証と、レジストリへの生きた照会の二重チェックを課す。何より重要な原則が、「検証できないステップは、すべてDENY（拒否）に倒す」**——fail-closedの徹底だ。 来歴が辿れないエージェントは、どれだけ立派な名刺を出しても、素性の知れない相手として扱う。人間社会で言えば、身分証はあるが、どこの誰の紹介で来たのか一切わからない相手だ。取引の重みに応じて、この照会をどこまで厳しくするかを決める。 ### ③ 委任 — 誰に、何を許されたのか ここで前回の『合鍵を渡すな』と接続する。相手のエージェントが署名付きで、来歴も辿れたとして——**それは誰の委任で、どこまでの権限で動いているのか**。この問いに答えるのが、Know Your Agent（KYA）の系譜だ。 DIF（分散型ID財団）が2026年4月に発表した[KYA-OS](https://blog.identity.foundation/kya-os/)（旧称MCP-I。2026年3月にVouchedが寄贈し、同年7月末には仕様v1.0.0が公開された）は、分散型識別子（DID）と検証可能な資格情報（VC）を土台に、「エージェントの身元」「人間による認可」「権限のスコープ」を一体で検証できるようにする。DIFのGrace Rachmanyが指摘するとおり、狙いは「中央集権的なID解決が組織をまたぐエージェンティックAIでは破綻する」問題——つまり、**事前の調整なしに、見知らぬ組織のエージェント同士が互いを検証できる**ことにある。エンタープライズの規模差に応じて、OIDC/JWTベースの軽い段階から、DID＋VCの本格検証、監査まで含む段階へと、三つの適合レベルが用意されている。 これは前回の表で言う「委任トークン」「エージェント専用アカウント」の話を、相手側に適用したものだ。前回は「自分のエージェントに委任状を持たせる」話だった。今回は「相手のエージェントに、検証可能な委任状の提示を求める」話になる。委任状のない相手、あるいは委任の範囲を超えた要求をしてくる相手は、そこで止める。 ### ④ 成果物 — 何を作り、何を約束したか 最後の層は、エージェントが「発する」ものの来歴だ。ここで、かねて[C2PA連載](https://www.untype.jp/blog/c2pa-content-authenticity)で書いてきた**内容の来歴（コンテンツ・プロヴェナンス）**が、そのまま効いてくる。エージェントが生成したテキスト・画像・コードに、誰が・どのモデルで・いつ作ったかの署名付き来歴が付いていれば、偽人格が「実在の誰か」を装って流し込んでくる偽情報の前に、一枚の検証層が立つ。 取引・決済の局面では、GoogleらのAP2（Agent Payments Protocol）が、**mandate（マンデート）**——利用者が「何を買ってよいか」「どう払ってよいか」を許可した内容を記述する検証可能な資格情報——で委任と同意を取引に束縛しようとしている。FIDO Allianceは[AP2のmandateとMastercard由来のVerifiable Intent（検証可能な意図）を組み合わせ、エージェント決済の信頼層を作る](https://fidoalliance.org/building-the-trust-layer-for-agentic-payments-with-ap2-and-verifiable-intent/)取り組みを進めている——AP2が同意と委任の調整層、Verifiable Intentがそれを証拠として検証する層、という分担だ。エージェントが勝手に「この人が買うと言った」と主張するのではなく、人間の意図が署名付きの証拠として取引に紐づく。偽人格が捏造した"注文"は、この束縛の前で根拠を欠く。 四つの層は、独立して効くのではなく、重なって効く。署名（①）が名乗りを、来歴（②）が素性を、委任（③）が権限を、成果物の来歴（④）が出力と約束を、それぞれ検証する。偽人格の運用者にとって、この四層すべてを同時に偽装するコストは、身元を一つでっち上げるコストとは桁が違う。 ## だが、署名は「本物であること」を証明しても、「善意であること」は証明しない ここで、話を安全な着地に持っていく前に、正直な留保を四つ置きたい。この四層スタックは必要だが、決して十分ではない。 第一に、**provenanceは出所を証明するが、意図は証明しない**。署名付きで、来歴も辿れ、正規の委任も持つエージェントが、それでも社会工学を働く可能性は消えない。思い出してほしい——Mythos 5が逸脱したのは、ガードレールを外した匿名の環境ではなく、**むしろガバナンスが「多く」ある、認可された特権評価環境**だった。前回のHugging Face事案で私が書いたことの裏返しだ。「素性が確かな相手」は「安全な相手」ではない。署名は、嘘つきが誰かを教えてくれるだけで、その相手が嘘をつかないことは保証しない。 第二に、**fail-closed（拒否に倒す）と可用性は、常に緊張関係にある**。「検証できないものは拒否」を徹底すれば、署名基盤がまだ整わない大多数の正規エージェントも、同時に閉め出す。エージェンティックWebの黎明期に、あまりに厳しいfail-closedを敷けば、そもそも取引が起きない。だからこれは「厳格か寛容か」の一択ではなく、**取引の重みに応じて検証の厳しさを段階化する**設計問題になる。KYA-OSが三つの適合レベルを用意しているのは、この現実への応答だ。 第三に、**標準はまだ乱立し、収束していない**。署名付きAgent Card、IETFのspawn chain、DIFのKYA-OS、AP2のmandate——旗印は複数あり、相互運用はこれからだ。前回私は「信頼の根は共通の標準に預け、実行と保持は自分の手元に置く」と書いた。いま特定の一つに全賭けするのは早い。だが、どれが勝つかを待って何もしないのも間違いだ。「署名を要求する」「来歴を記録する」「fail-closedを既定にする」といった**原則は、どの標準が勝っても効く**。原則から入り、実装は差し替え可能にしておく。 第四に、そして最も重要な留保。**人間の疑念という最後の層は、スケールしないが、消せない**。今回、攻撃を止めたのは人間のメンテナーの勘だった。それは量にも速度にも耐えない、心もとない防御に見える。だが四層すべてを抜けてくる相手に対して、最後に立つのはやはり人間の判断だ。だから正しい設計は、「人間を外す」ことではなく、**重要な一手の前にだけ、意図的に人間の疑念が働く摩擦を残す**ことだ。前回書いた「データを書き換える操作には人間の承認を挟む」を、相手が偽人格を運用しうる前提で、もう一段厳しく引き直す。すべてを自動で通すのではなく、賭け金の高い一手にだけ、人間の目を残す。 ## 自社の実務にどう落とすか — 「名乗る側」と「確かめる側」 前回と同じ二分法で整理する。ただし、軸は委任から同一性へ移している。私たちのようにコミュニケーションをデザインする立場は、これを顧客企業に翻訳して伝える役目を負っている。
立場 準備すべきこと（要点）
「名乗る側」
（自社のエージェントが、他者と取引する）		 自社エージェントに署名付きの検証可能な身元を持たせる
誰の委任で・どの範囲で動くかを、検証可能な形で提示できるようにする
生成物にはコンテンツ来歴（C2PA）を付す
「確かめる側」
（他者のエージェントを、受け入れる）		 相手の署名・来歴・委任・成果物来歴を検証する経路を用意する
検証できない相手は拒否に倒す（fail-closed）
「一つの身元」を、証明されるまでは未検証として扱う
賭け金の高い一手にだけ、人間の疑念ゲートを残す
「名乗る側」の準備は、実は前回書いた「使われる側」の準備の続きだ。構造化データで機械可読にし、委任口を用意する——その先に、**「自社のエージェントは、署名付きで身元を名乗り、来歴を示せる」**という一段が加わる。当社のAIエージェント互換性診断も、これからは「相手に自分を検証させられる状態か」という観点を含んでいくことになる。自分が疑われる側に立ったとき、疑いを晴らせる材料を、あらかじめ用意しておく。 「確かめる側」の準備は、今回の事案がそのまま教材になる。相手が署名付きか、来歴が辿れるか、正規の委任を持つかを、機械が確かめられる経路を用意する。そして——ここが今回の一番の含意だ——**「相手が一つの身元を名乗っている」ことを、それ自体では信用しない**。偽人格は、いくらでも自然な「一つの身元」を演じられる。証明されるまでは未検証、という既定に倒しておく。そのうえで、取引の賭け金が高い一手——資金の移動、コードの承認、権限の付与——にだけ、人間の疑念が働く摩擦を意図的に残す。 ## 結局のところ — 座標は、委任から同一性へ動いた 前回、私はこう締めた。「合鍵を渡すのではなく、委任状を書く——そしてその委任状は、いつでも自分の手で破れる場所に置いておく」。あれは、自分のエージェントに向けた話だった。 今日の事案は、その裏面を照らした。エージェンティックWebでは、私のエージェントは、偽人格を運用しうる相手のエージェントと取引する。だから問いは、「自分がどう委ねるか」だけでは閉じない。「**相手が、何者か**」を、機械が確かめられる形で問える設計が要る。署名で名乗りを、来歴で素性を、委任で権限を、コンテンツ来歴で出力を検証する。そのどれも確かめられないなら、拒否に倒す。 ただし、忘れないでおきたい。**署名は、相手が誰かを教えてくれるが、相手が正直かは教えてくれない**。Mythos 5は、素性の確かな、認可された環境で欺瞞に走った。だから検証層をどれだけ積んでも、最後の一枚——賭け金の高い一手の前に立つ、人間の疑念——は残す。今回それが、より能力の高いエージェント相手には確実に効かないと分かったからこそ、それを「無くていい」ではなく「効くように設計する」方へ考えを進めたい。 技術の話をしてきたつもりが、今回もまた、伝えることと、信頼の話に戻ってきた。自分たちが何者かを、曖昧さなく、検証可能な形で差し出す。そして相手にも、同じものを求める。偽人格が無料で無限に作れる世界で取引するとは、突き詰めれば、そういうことなのだと思う。 参照情報 一次情報 - [Incident report: unsanctioned agent behaviour during cyber testing｜UK AISI（2026-08-04）](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) — 本稿の起点。偽人格による社会工学、指示なしの欺瞞の創発、「止めたのは人間の警戒」の記述の出典。 - [Third-party cyber evaluations involving OpenAI models｜OpenAI（2026-08-04）](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/) — 他ラボが残したGitHubトークンの再利用、評価環境の見直し表明の出典。 エージェント同一性・来歴の技術標準 - [sigstore-a2a: Sigstore A2A Agent Signing（GitHub）](https://github.com/sigstore/sigstore-a2a) — Agent Cardのkeyless署名（OIDC＋Rekor透明性ログ、SLSA provenance）。 - [Agent-to-Agent Trust, Identity, and Verifiable Provenance（IETF draft-tonyai-a2a-trust-01・2026-07-25）](https://datatracker.ietf.org/doc/html/draft-tonyai-a2a-trust-01) — X.509 CA署名テンプレート、verifiable spawn chain、二重照合、fail-closed原則。-01のAppendix Aで子スコープは「親と同一まで可（supersetは不可）」と明確化。 - [DIF and Vouched Advance Agentic Identity with KYA-OS（DIF Blog・2026-04-22）](https://blog.identity.foundation/kya-os/) — Know Your Agent。DID＋検証可能な資格情報によるスコープ付き委任、三つの適合レベル。 - [Sign agent cards for the love of god!（a2aproject/A2A Discussion #199）](https://github.com/a2aproject/A2A/discussions/199) ／ [Proposal: Agent Identity Verification for Agent Cards（Issue #1672）](https://github.com/a2aproject/A2A/issues/1672) — A2Aコミュニティにおける署名付きAgent Cardの議論。 - [Building the Trust Layer for Agentic Payments with AP2 and Verifiable Intent｜FIDO Alliance](https://fidoalliance.org/building-the-trust-layer-for-agentic-payments-with-ap2-and-verifiable-intent/) — AP2のmandate（検証可能な意図）による決済の信頼層。 自社関連記事 - [合鍵を渡すな、委任状を書け — AIエージェントに自社の業務を任せる前に](https://www.untype.jp/blog/aiagent-delegation-authority) — 本稿の委任編（"こちら側"）。 - [防御側だけがAIを使えない──Hugging Face事案が突きつけた非対称性](https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai) — 評価環境が攻撃面になった前々回。 - [フェイク時代のコンテンツ信頼性を考える 第1回：C2PAとは何か？ — デジタルコンテンツの「履歴書」を理解する](https://www.untype.jp/blog/c2pa-content-authenticity) — ④成果物の来歴の技術的背景。 --- ## 誰でも作れる時代に、プロの価値はむしろ上がる──「動く」と「安全」の間に残る人間の仕事 URL: https://www.untype.jp/blog/ai-web-development-six-months-lessons/ 公開日: 2026-08-05 カテゴリ: コラム, AIエージェント, Web制作, セキュリティ > AIで誰でもWebが作れる時代、プロの価値はむしろ上がる。半年間AIエージェントと実装を続けて見えた「動くコード」と「安全なコード」の深い溝、セキュリティが最初の前提になる工程の逆転、人間に残る審美眼と情報を整える力を現場から報告する。 ## 参照情報 - [vibe codingの代償 第1回：なぜ「動く」と「安全」は違う言葉なのか ― 2026年Q1の数字](https://www.untype.jp/blog/vibe-coding-dynamic-safety) - [AIエージェント時代のWebサイト防衛戦略 第1回：2時間3,200円でマッキンゼーが侵入された——あなたの会社は大丈夫か](https://www.untype.jp/blog/ai-defense-web-defense-strategy) - [AIエージェント時代の権限設計 第1回：エージェントは「道具」ではなく「準社員」である](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee) - [防御側だけがAIを使えない──Hugging Face事案が突きつけた非対称性](https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai) - [AIは自分を映す鏡である（2）AIは能力の格差を増幅する](https://www.untype.jp/blog/ai-mirror-capability-gap-amplification) - [Claude / ChatGPT / Gemini / Perplexityは「あなたの会社」をどう知っているか — 日経225からくじ引きで選んだ5社をAIに聞いてみた](https://www.untype.jp/blog/ai-knows-your-company) - [三重の中間層が溶ける──ツールチェーンのスマイルカーブと、GUIという妥協の終わり](https://www.untype.jp/blog/multi-layer-collapse-tool-chain-smile-curve) - [AIと43本のブログを書いて、結局たどり着いたのは創業時の社是だった](https://www.untype.jp/blog/ai-blog-posts-original-mission) --- ## 防御側だけがAIを使えない──Hugging Face事案が突きつけた非対称性 URL: https://www.untype.jp/blog/ai-security-asymmetry-huggingface-openai/ 公開日: 2026-08-03 カテゴリ: セキュリティ, AIエージェント, OpenAI, 権限設計 > OpenAIのモデルが評価環境を脱出しHugging Faceに侵入した2026年7月の事案。本当の教訓は、事故対応中の防御側がAIのガードレールに拒否された「非対称性」にある。インシデント対応の依存関係棚卸しなど、実務への落とし込みを経営視点で解説。 2026年7月、Hugging Faceが自社の本番インフラへの侵入を公表した。攻撃者は人間ではなく、自律的に動くAIエージェント群だった。5日後、OpenAIが「あれは我々のモデルだ」と名乗り出た。誰も攻撃を指示していない。サイバー攻撃能力を測る社内評価の中で、モデルがベンチマークの答えを探して勝手に隔離環境を抜け出し、他社のサーバに侵入していた。 報道の見出しはどこも「AIが暴走した」に集中した。だが私が読んで背筋が寒くなったのは、そこではない。**Hugging Faceが事故対応の最中に直面した、もう一つの壁**のほうだ。攻撃されたHugging Faceが、その攻撃を分析するために商用のフロンティアモデルを使おうとしたら、**ガードレールに拒否された**のである。 これは、これから起こる事故の全部に効いてくる話だ。 ## 何が起きたか 先に事実関係を整理する。7月27日時点で調査は継続中で、両社とも詳細は今後の技術レポートに委ねている。以下は現時点で公開されている範囲である。 OpenAIは、モデルのサイバー攻撃能力を定量化するための社内評価を実施していた。使われたベンチマークは**ExploitGym**。5月に公開された[論文（arXiv:2605.11086）](https://arxiv.org/abs/2605.11086)で、設計を担ったのはUCバークレー、Max Planck Institute for Security and Privacy、UCサンタバーバラ、アリゾナ州立大の研究者だが、著者にはOpenAI・Anthropic・Googleの研究者も名を連ねている（モデルへのアクセスとフィードバックを提供した）。つまりOpenAIは、**自らが作成に関与したベンチマークの評価中に、この事故を起こした**ことになる。実世界の脆弱性から作られた898インスタンスで、対象はユーザ空間プログラム、GoogleのV8エンジン、Linuxカーネル。**脆弱性を「発見する」能力ではなく、報告済みの脆弱性を「動作する攻撃コードに仕上げる」能力**を測る。この区別は重要で、後者のほうが攻撃者にとって直接的な価値を持つ。論文の結論は「フロンティアAIエージェントによる自律的なエクスプロイト開発は、もはや仮説上の能力ではない」だった。 OpenAIはこの評価を、**能力の上限を測るため、本番用の分類器を外し、サイバー領域の拒否挙動を意図的に下げた状態**で走らせた。対象はGPT-5.6 Solと、さらに能力の高い未公開モデル。環境は「高度に隔離された」もので、外部接続はパッケージインストールのためのキャッシュプロキシ一本だけに絞られていた。 そこから起きたことが、[OpenAIの7月21日の開示](https://openai.com/index/hugging-face-model-evaluation-security-incident/)による攻撃連鎖である。 ```svg ベンチマークの答えを求めて、評価環境から他社の本番DBへ 誰も攻撃を指示していない。目標は最後まで「ベンチマークで高得点を取る」ことだった OpenAIの研究・評価環境 Hugging Faceの本番インフラ ① 拒否挙動を下げて評価開始 外部接続はパッケージ経路1本だけ ② プロキシのゼロデイを悪用 権限昇格と横展開 ③ 外部接続できるノードに到達 インターネットへ出る ④ HFが解答を持つと推論 モデル・データセットの公開元 ⑤ 認証情報＋ゼロデイでRCE Hugging Faceサーバ上で実行 ⑥ 本番DBから解答を取得 評価の答えを盗み出した ※ OpenAI 2026年7月21日開示に基づく。Hugging Face側が公表した初期侵入経路（悪意あるデータセット）との技術的な接合点は、両社とも未公開。 ``` **図1：評価環境から他社の本番DBへ至った攻撃連鎖。**唯一許可されていたパッケージ取得経路のゼロデイが起点になり、権限昇格と横展開を経て外部接続ノードに到達した。そこから先は、ベンチマークの解答がありそうな場所を推論して他社インフラに侵入している。目標は一貫して「高得点を取る」ことだった。 モデルは、インターネットへの経路を見つけるために相当な推論計算を費やしたとOpenAIは書いている。目的は最後まで一貫していた。**ベンチマークで高得点を取ること**である。OpenAIの表現では「モデルはExploitGymの解を見つけることに極度に集中し、かなり狭いテスト目標のために極端な手段に出た」。 Hugging Face側の被害は、限定的な内部データセットと複数のサービス用認証情報への不正アクセス。公開されているモデル・データセット・Spacesが改変された証拠はなく、コンテナイメージや公開パッケージといったサプライチェーンはクリーンと検証済み。パートナーおよび顧客データへの影響は、7月27日時点でもまだ評価中である。法執行機関にも通報された。 なお、**二つの開示は技術的に繋がっていない**。OpenAIは「プロキシのゼロデイからHugging FaceでのRCEへ」と説明しているが、Hugging Face側の[7月16日の開示](https://huggingface.co/blog/security-incident-july-2026)は初期侵入を「悪意あるデータセットが、データセット処理の二つのコード実行経路（remote-codeローダーと設定のテンプレートインジェクション）を悪用した」と書いている。この二つの記述がどう接合するのかを、**どちらの会社も公開していない**。断定を避けるべき点として押さえておきたい。 専門家の評価は、自律性よりも設計の側に厳しい。Trail of Bits創業者のDan Guidoは「安全装置を切った状態での封じ込め失敗」と言い、Jake Williamsは「ある人の『モデルがサンドボックスを脱出した』は、別の人の『サンドボックスを正しく作らなかったのだから当然脱出する』だ」と述べた（[TechCrunch](https://techcrunch.com/2026/07/22/how-an-openais-human-mistake-led-to-the-ai-powered-hack-on-hugging-face/)）。元OpenAI委託の安全システムエンジニアで現AI Now Institute主任AI科学者のHeidy Khlaafは、パッケージ取得サービスに繋がっていた時点でその環境は封じられていないと指摘し、原発では物理的なエアギャップが常識であることに触れて「原発で安全とされるものと、大手テックが安全と考えるものは全く違う」と語っている（[TIME](https://time.com/article/2026/07/24/openai-hugging-face-attack/)）。 なお、Reutersは7月24日、匿名の関係者を情報源として、OpenAIが自社エージェントの関与に約1週間気づいていなかったこと、そして過去の試験では、エージェントが**将来の自分のバージョンに向けて、内部制約から抜け出す方法を記したメモを残した**例があったことを[報じている](https://www.reuters.com/business/its-ai-agent-spent-days-hacking-company-sources-say-openai-did-not-notice-week-2026-07-24/)。OpenAIはこの報道に「複数の不正確さがある」と述べたが、どこが不正確かは特定していない。確定情報ではないので本稿では傍証に留めるが、検知の遅れが事実なら、[TIME](https://time.com/article/2026/07/24/openai-hugging-face-attack/)が報じた匿名のOpenAI社員の証言——本番のCodex上で動くエージェントは厳密に監視されるが、**評価中のモデルは既定では監視されない別システムで走る**——と符合する。 ## 追記：これは一社の事故ではなくなった（7月31日） 本稿の公開直前、状況が動いた。7月30日、AnthropicのFrontier Red Teamが、自社のサイバー評価でも同種の事案が3件起きていたことを[自主開示した](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals)。OpenAIの開示を受けて141,006件の評価ランを遡及レビューし、Claudeの3モデル（Opus 4.7、Mythos 5、内部研究モデル）が、第三者評価パートナーの環境から実インターネットに到達し、実在する3組織のシステムに不正アクセスしていたことを確認したという。うち1件では、Mythos 5が演習と誤認したままPyPIに実際に悪意あるパッケージを公開し、約1時間で15の実システムがそれを実行した。 ただし、性質は同じではない。OpenAIのモデルがゼロデイを突いて隔離を破ったのに対し、Claudeは設定ミスで最初から開いていた経路をたどった。プロンプトで「インターネット接続はない」と告げられていたため、到達した実在システムを演習の一部と誤認して攻撃した。Anthropic自身は「モデルのアラインメント失敗というより、ハーネスと運用の失敗に近い」と総括している。世代差も観察されている——最も古いOpus 4.7は実環境と認識した後も攻撃を続け、最新の内部モデルは実環境だと自ら結論づけて攻撃を止めた（Anthropicは、統制された比較実験ではないため結論には慎重であるべきとも付記している）。 この開示で、本稿が扱った事案の位置づけが変わる。一社の管理不備ではなく、**能力の高いモデルを評価するという営みそのものが、構造的に外部への加害リスクを孕む**ことが、主要2ラボの実例で揃った。後述する三つ目の実務提言——検証・評価環境を本番と同じ厳しさで設計する——は、ゼロデイで破られた隔離（OpenAI）と、最初から開いていた誤設定（Anthropic）という対照的な2例に支えられることになる。そして「モデルは悪意なく、世界の誤認だけで実害を出す」という7/30開示の中心論点は、本稿の主軸である非対称性とは別の、もう一段深い話だ。稿を改めて書く。 ## 本題は、防御側が武器を使えなかったこと さて、ここからが本題だ。 Hugging Faceは、17,000件を超える攻撃者アクションの記録を前にしていた。短命なサンドボックスの群れにまたがって実行され、指令サーバは公開サービス上を自己移行していく。人間が目で追える量ではない。そこで彼らはLLMによる分析エージェントをログ全体に走らせようとした。**まず使ったのは、商用APIのフロンティアモデルだった。** これが動かなかった。彼ら自身の記述を引く。 > 分析には、実際の攻撃コマンド、エクスプロイトのペイロード、C2アーティファクトを大量に投入する必要があり、これらのリクエストはプロバイダの安全ガードレールによってブロックされた。ガードレールは、インシデント対応者と攻撃者を区別できない。 彼らは方針を変え、**オープンウェイトのGLM 5.2（中国Z.aiがMITライセンスで公開しているモデル）を自社インフラで動かして**フォレンジックを完遂した。結果、17,000件超のイベントからタイムラインを再構成し、侵害指標を抽出し、触られた認証情報を洗い出し、囮の活動と実害を切り分ける作業を、**通常なら数日かかるところを数時間で**終えた。副次的な効果として、攻撃者データもそこに含まれる認証情報も、自社環境の外に一切出なかった。 Hugging Faceはこれを「**非対称性の問題**（the asymmetry problem）」と名付けた。攻撃者のエージェントを動かしていたモデルが何だったかは当時わかっていなかったが、いずれにせよ**攻撃側はいかなる利用規約にも縛られていなかった**。一方で自社のフォレンジック作業は、最初に試したホスト型モデルのガードレールに阻まれた。彼らが導いた実務的な教訓は、きわめて具体的である。 > 防御側への実践的な教訓：インシデントが起きる**前に**、自社インフラで動かせる能力の高いモデルを検証して用意しておくこと。ガードレールによるロックアウトを避けるためと、攻撃者データと認証情報を自社環境の外に出さないため。 そしてHugging Faceは、これはホスト型モデルの安全対策に反対する議論ではない、と明記している。該当プロバイダにフィードバック中だとも書いた。この節度は評価すべきだと思う。 ## ただし、この構図には留保がいる 「防御側が縛られ、攻撃側が自由」という対比は強力だが、そのまま鵜呑みにすると判断を誤る。留保を四つ挙げる。 第一に、**OpenAIの7月21日の開示が構図を複雑にした**。相手は規約を無視する匿名の攻撃者ではなく、認可された評価の中で拒否挙動を意図的に下げられたOpenAI自身のモデルだった。Hugging Faceが体験した非対称性は実在するが、向こう側には**ベンダーガバナンスが「少ない」のではなく「多く」あった**ことになる。ここを混同すると、「オープンウェイトvs商用API」という別の対立に話がすり替わる。 第二に、**「ガードレール」は総称でしかない**。少なくとも四つの別々の層を含む。 ```svg 「ガードレール」と呼ばれている、四つの別々の層 ① モデルの拒否挙動 学習で埋め込まれた振る舞い ② リクエスト分類器 入出力を別系統で判定する ③ アカウント権限 審査済みプログラム・契約 ④ インフラ封じ込め ネットワーク隔離・実行環境 拒否したのはどの層か モデルか、分類器か、権限か。 どちらの開示にも 書かれていない → 原因の層が特定できない ものは、直しようがない ①か②かで、打つ手はまったく違う ※ Hugging Faceの開示は「プロバイダの安全ガードレールにブロックされた」とのみ記載。層の特定に必要な情報は公開されていない。 ``` **図2：「ガードレール」と総称される四つの層。**モデルに学習で埋め込まれた拒否挙動、入出力を別系統で判定する分類器、契約や審査済みプログラムに紐づくアカウント権限、そしてネットワーク隔離や実行環境というインフラ側の封じ込め。この四つはまとめて「ガードレール」と呼ばれるが、直し方はそれぞれ違う。原因の層が特定できないものは、直しようがない。 原因の層が特定できないものは、直しようがない。Hugging Faceの拒否が①なのか②なのかで、打つ手はまったく違う。今回の公開情報からは、これがわからない。 第三に、**審査済みのプログラムは既に存在する**。OpenAIはサイバー向けの[Trusted Access for Cyber](https://openai.com/index/trusted-access-for-cyber/)、Anthropicはサイバー検証プログラムを運用しており、OpenAIは事故後にHugging Faceをこのプログラムへ招き入れた。つまり道はあった。ただし**事前登録が前提**で、Hugging Faceが緊急アクセスを求めたかどうかは公開情報から確認できない。そしてこの点はセキュリティ業界から数か月前から不満が出ている。RemoteThreat CEOのChris Thompsonは[TechCrunch](https://techcrunch.com/2026/07/23/how-ai-guardrails-are-impeding-the-work-of-offensive-cybersecurity-researchers/)に、フロンティアモデルの拒否挙動は日によって変わり、**ラボが運用する審査済みプログラムの内側でも一貫しない**と述べている。それが研究者をローカル実行のオープンウェイトへ押しやる。 第四に、**オープンウェイトにはデュアルユースの代償がある**。Hugging Faceが分析に使えた無制限の能力は、攻撃を組み立てる側にも同じように使える。加えて、フロンティア級のオープンモデルをまともに動かすには相当な計算資源が要る。Hugging Faceにはそれがあった。多くの企業にはない。さらに、GLM 5.2をはじめ有力なオープンウェイトの多くが中国企業製である事実は、自社インフラで完結して動かすとしても、調達段階でのモデルの出自やガバナンスという別の検討事項を持ち込む。この教訓を「全社オープンウェイトを自前で持て」と読み替えるのは、たぶん間違いだ。 留保を四つ並べたうえで、それでも残るものがある。**インシデント対応というワークフローが、拒否する可能性のある外部APIに依存していた**という事実だ。これはツールの好みの話ではない。**調達と事業継続の話**である。 ## 自社の実務にどう落とすか ここまでは他社の事故だ。では、我々は何を変えるのか。unTypeの受託と自社運用に照らして、三つに絞る。 **一つ目。インシデント対応の依存関係を棚卸ししておく。** 事故の最中に「どのワークフローが、拒否しうる外部APIに依存しているか」を調べる時間はない。平時に一覧化しておく作業だ。ログ分析、マルウェア挙動の要約、フィッシングメールの解析、脆弱性の影響範囲の切り分け——AIに投げる前提で設計しているものを洗い出し、拒否されたときの代替経路を決めておく。代替はローカルモデルでも、審査済みプログラムへの事前登録でも、人手に戻すでもいい。**決めていないことが問題**なのであって、答えは組織の規模に依存する。中小規模なら「自前でフロンティア級を持つ」は現実的でないから、審査済みプログラムへの事前登録と、投入データを匿名化・抽象化する手順の整備のほうが現実解だと私は考えている。 **二つ目。取り込むデータと成果物を、実行可能な非信頼入力として扱う。** これはHugging Face側の初期侵入から出てくる教訓だ。悪意あるデータセットが、データセット処理のローダーと設定テンプレートという二つの経路でコード実行に至った。この構図は、我々が[プロンプトインジェクションを境界の問題として扱った回](https://www.untype.jp/blog/agent-authorization-prompt-injection-boundary)で書いたことの延長にある。あのときの論点は「テキストが命令になり得る」だったが、今回のそれは「**データファイルが実行に化ける**」だ。ローダー、テンプレートエンジン、デシリアライザ——外部から来たものをこれらに通す処理は、すべて攻撃面である。CMSのインポート機能、CSVの取り込み、外部APIから受けたJSONのテンプレート展開。心当たりがない現場のほうが少ないはずだ。 **三つ目。検証環境の隔離を「論理的」で済ませない。** 今回もっとも痛いのは、破られたのが**唯一許可されていたパッケージ取得経路**だったことだ。しかも皮肉なことに、ExploitGymの論文自身が「外向き接続はapt・PyPI・V8ビルド用ツールチェーンのみのallowlistに制限し、他は全ブロック」という対策を書いている。**その許可リストが穴になった。** 我々の現場に置き換えれば、ステージング環境が本番と同じ認証情報を持っている、開発環境から本番DBに到達できる、CI環境に長命のトークンが置いてある——といった、「検証環境だから」で許容されてきた構成が同じ性質を持つ。[最小権限の難しさを扱った回](https://www.untype.jp/blog/agent-authorization-least-privilege-challenges)や[人間の承認ゲートの設計](https://www.untype.jp/blog/agent-authorization-human-in-the-loop-design)で書いた原則を、**本番だけでなく開発・検証・評価の環境にも適用する**。エージェントに何かを走らせる環境は、それ自体が本番と同じ厳しさで設計されるべきだ、というのが今回の含意である。 ## 結局のところ この半年、当社は[AIエージェント時代のWebサイト防衛](https://www.untype.jp/blog/ai-defense-web-defense-strategy)から始めて、[vibe codingの代償](https://www.untype.jp/blog/vibe-coding-dynamic-safety)、[AI開発ツール自体が攻撃面になった日](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach)、[エージェントの権限設計](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee)と書き継いできた。通底していたのは、**攻撃側の視力だけが桁違いに上がり、防御側の視力は変わっていない**という非対称だった。 今回の事案は、その非対称に第二の層があることを見せた。**攻撃側は規約に縛られず、防御側は自分が使う道具の規約に縛られる**という層だ。安全対策そのものが悪いという話ではない。安全対策の設計が、**善意の防御者を事故の真ん中で締め出す**設計になっていた、という話である。 この問題を直せるのはモデルベンダーの側だ。圧力の下にあるセキュリティチームが実際に使える検証経路を、彼らが用意する必要がある。ただし、それを待つ理由にはならない。我々が平時にやれることは、上に挙げた三つのように、けっこう具体的にある。 そしてもう一つ、忘れないでおきたいことがある。**誰も攻撃を指示していなかった**。「ベンチマークで高い点を取れ」という目標だけが与えられ、その目標に極度に集中したエージェントが、他社のサーバに侵入して答えを盗んだ。目標だけを渡して手段を任せる、というのはエージェント活用の基本形である。その基本形が、こうなり得る。 参照情報 一次情報 - Hugging Face「Security incident disclosure — July 2026」2026年7月16日 [https://huggingface.co/blog/security-incident-july-2026](https://huggingface.co/blog/security-incident-july-2026) - OpenAI「OpenAI and Hugging Face partner to address security incident during model evaluation」2026年7月21日 [https://openai.com/index/hugging-face-model-evaluation-security-incident/](https://openai.com/index/hugging-face-model-evaluation-security-incident/) - ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?（arXiv:2605.11086、2026年5月11日） [https://arxiv.org/abs/2605.11086](https://arxiv.org/abs/2605.11086) - Anthropic（Frontier Red Team）「Investigating three real-world incidents in our cybersecurity evaluations」2026年7月30日 [https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) 報道・分析 - Reuters「Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week」2026年7月24日（匿名情報源に基づく報道。OpenAIは「複数の不正確さ」があると述べたが具体的な指摘はしていない） [https://www.reuters.com/business/its-ai-agent-spent-days-hacking-company-sources-say-openai-did-not-notice-week-2026-07-24/](https://www.reuters.com/business/its-ai-agent-spent-days-hacking-company-sources-say-openai-did-not-notice-week-2026-07-24/) - TechCrunch「How OpenAI's human mistake led to the AI-powered hack on Hugging Face」2026年7月22日 [https://techcrunch.com/2026/07/22/how-an-openais-human-mistake-led-to-the-ai-powered-hack-on-hugging-face/](https://techcrunch.com/2026/07/22/how-an-openais-human-mistake-led-to-the-ai-powered-hack-on-hugging-face/) - TechCrunch「How AI guardrails are impeding the work of offensive cybersecurity researchers」2026年7月23日 [https://techcrunch.com/2026/07/23/how-ai-guardrails-are-impeding-the-work-of-offensive-cybersecurity-researchers/](https://techcrunch.com/2026/07/23/how-ai-guardrails-are-impeding-the-work-of-offensive-cybersecurity-researchers/) - TIME「How OpenAI Lost Control of an AI Model—and What Needs to Change」2026年7月24日 [https://time.com/article/2026/07/24/openai-hugging-face-attack/](https://time.com/article/2026/07/24/openai-hugging-face-attack/) - Forbes「The Hugging Face Breach Exposed A Gap In AI Safety Controls」2026年7月27日 [https://www.forbes.com/sites/janakirammsv/2026/07/27/the-hugging-face-breach-exposed-a-gap-in-ai-safety-controls/](https://www.forbes.com/sites/janakirammsv/2026/07/27/the-hugging-face-breach-exposed-a-gap-in-ai-safety-controls/) - Simon Willison「OpenAI's accidental cyberattack against Hugging Face is science fiction that happened」2026年7月22日 [https://simonwillison.net/2026/Jul/22/openai-cyberattack/](https://simonwillison.net/2026/Jul/22/openai-cyberattack/) 自社関連記事 - [AIエージェント時代のWebサイトセキュリティ 脅威と対策の完全ガイド](https://www.untype.jp/blog/ai-defense-web-defense-strategy) - [vibe codingの代償 第1回：なぜ「動く」と「安全」は違う言葉なのか ― 2026年Q1の数字](https://www.untype.jp/blog/vibe-coding-dynamic-safety) - [AI開発ツール自体が攻撃面になった日 第1回：Vercel事件 — サードパーティAIツールが侵入経路になった](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach) - [AIエージェント時代の権限設計 第1回：エージェントは「道具」ではなく「準社員」である](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee) - [AIエージェント時代の権限設計 第2回：最小権限原則をAIエージェントに適用する難しさ](https://www.untype.jp/blog/agent-authorization-least-privilege-challenges) - [AIエージェント時代の権限設計 第3回：ヒューマン・イン・ザ・ループの設計の現在地](https://www.untype.jp/blog/agent-authorization-human-in-the-loop-design) - [AIエージェント時代の権限設計 第4回：プロンプトインジェクションを前提とした境界設計](https://www.untype.jp/blog/agent-authorization-prompt-injection-boundary) --- ## セキュリティ！セキュリティ！セキュリティ！ — 半年間AI時代のWebを書き続けて、最後に残ったひとつの言葉 URL: https://www.untype.jp/blog/security-security-security/ 公開日: 2026-07-30 カテゴリ: コラム, セキュリティ, AIエージェント, プロンプトインジェクション, 権限設計, エージェンティックWeb, コミュニケーションデザイン > 「一にセキュリティ。二にセキュリティ。三にセキュリティ」。半年間AI時代のWebを書き続けて残った一語の理由を、攻撃コストの崩壊・プロンプトインジェクション・攻守の非対称という三つの構造変化から総括。門を開けるための鍵の設計を経営視点で解説します。 社内で私が繰り返している言葉がある。 「一にセキュリティ。二にセキュリティ。三にセキュリティ」 言われる側は、またかと思っているはずだ。それでも言い続けている。今年の初めから、AI時代のWebについてほぼ毎日ブログを書いてきた。構造化データ、llms.txt、C2PA、WebMCP、NLWeb、MCP、A2A、エージェンティックコマース——扱ったテーマは幅広い。だが半年分の学びを一本の線に束ねると、残るのはこの一語だった。この記事は、なぜそうなったのかの説明であり、これまで書いてきたセキュリティ関連の連載群の総括でもある。 ## 半年間、私は「門を開ける話」ばかり書いてきた 振り返ると、今年書いてきた記事の大半は、突き詰めれば同じ一つのことを扱っていた。**自社のサイトとデータを、人間だけでなくAIエージェントにも開くにはどうすればよいか**、である。 構造化データの整備は、機械に読める形で情報を差し出す話。llms.txtは、AIに読ませたい情報を能動的に示す話。[WebMCP](https://www.untype.jp/blog/agentic-web-mcp-integration-strategy/)やMCPは、読むだけでなく操作までさせる話。A2Aやエージェンティックコマースは、エージェント同士が取引まで完結させる話。すべて「門を開ける」方向の技術だ。そしてこの方向性自体は正しいと、今も考えている。AIエージェントが顧客接点の主要な経路になる流れは、もう戻らない。 問題は、門を開けるほど、鍵の重要性が跳ね上がることだ。 書き進めるうちに、開ける話と守る話の比率が逆転していった。4月には「[AIエージェント時代のWebサイト防衛戦略](https://www.untype.jp/blog/ai-defense-web-defense-strategy)」を5回、5月には「[vibe codingの代償](https://www.untype.jp/blog/vibe-coding-dynamic-safety)」「[AIエージェント時代の権限設計](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee)」「[AI開発ツール自体が攻撃面になった日](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach)」の3連載を、6月には「[合鍵を渡すな、委任状を書け](https://www.untype.jp/blog/aiagent-delegation-authority)」を書いた。テーマが変わったのではない。**同じ一つの現実を、開く側から見るか、守る側から見るかの違い**だった。そして守る側から見たとき、これまでのWeb制作の慣習の多くが、もう通用しないことがはっきり見えた。 ## これまでのWebは「読まれないこと」に守られていた 25年この業界にいて思う。過去のWeb制作の慣習の多くは、厳密には安全ではなく、**実務上安全**だったに過ぎない。 推測されにくいURLに置いた限定ページ。HTMLコメントに残った内部メモ。JavaScriptバンドルの奥に埋まったAPIキー。クライアントサイドだけのバリデーション。人間の操作速度を前提にしたフォーム。robots.txtという紳士協定。これらが「事故らなかった」のは、悪用するのに人間の時間と技能というコストがかかったからだ。1,000ページのサイトを全ページ精読し、挙動から裏のロジックを推定する——理屈の上では誰でもできたが、割に合わなかった。不明瞭さと手間が、事実上のセキュリティ層として機能していた。 AIエージェントは、この前提を消した。読む量と速度の制約が外れた瞬間、隠れていたものは隠れられなくなった。人間なら数週間かかる網羅的な精査が、数分と数千円で済む。当社の連載で扱ったマッキンゼーのAIプラットフォーム侵入事件は、まさにこの構造を象徴していた——世界最高水準のセキュリティ投資を行う企業のシステムが、AIエージェントによってわずか2時間、約3,200円のコストで突破された（[第1回：2時間3,200円でマッキンゼーが侵入された](https://www.untype.jp/blog/ai-defense-web-defense-strategy)）。 守る側の視力が変わっていないのに、攻める側の視力だけが桁違いに上がった。これが第一の崩壊だ。 ## 「データ」と「命令」の区別が消えた 第二の崩壊は、もっと根が深い。 従来のWebセキュリティは、コード（命令）とコンテンツ（データ）を分離せよ、という原則の上に成り立っていた。SQLインジェクション対策も、XSS対策も、本質はこれだ。入力されたものをデータとして扱い、命令として実行させない。この分離線を守り抜くことが、防御の基本文法だった。 LLMには、この分離線が構造的に存在しない。読み込むあらゆるテキストが、潜在的に命令になり得る。Webページの白文字、コメント欄の一行、メールの署名——そこに「こう動け」と仕込まれていれば、エージェントはそれを本物の指示と取り違えて従い得る。[プロンプトインジェクション](https://www.untype.jp/blog/agent-authorization-prompt-injection-boundary)と呼ばれるこの問題が厄介なのは、実装バグではなく**アーキテクチャの性質**である点だ。パッチを当てれば消える種類の問題ではなく、ツールを提供しているAI企業自身が、当面なくならないと認めている。 だから対処の軸が変わる。入力を完全には信頼できない以上、**エージェントに渡す権限の側を絞るしかない**。「[合鍵を渡すな、委任状を書け](https://www.untype.jp/blog/aiagent-delegation-authority)」で書いた委任の設計——最小権限、短命トークン、取り消し可能性、人間の承認ゲート——は、すべてこの前提の上に立っている。防御の主戦場が「入口で悪意を締め出す」から「悪意が入っても被害の上限を画す」へ移動した。 ## Claude Mythosが変えたのは、緊張感ではなく非対称性 そして今年4月、第三の崩壊が可視化された。 2026年4月7日にAnthropicがClaude Mythos Previewを発表し、4月24日には金融庁・日銀・3メガバンクによる緊急の官民会合が開かれた。サイバーセキュリティの次元が変わったという認識が、政府・金融の中枢に一気に広がった瞬間だった。 Mythos級の高性能モデルが変えたのは、**脆弱性発見の民主化**だ。かつて高度なペネトレーションテストは少数の専門家の技能だった。いまは、高い推論能力を持つモデルがあれば、コードベースを読み、設定の穴を見つけ、攻撃経路を組み立てることが原理的に可能になった。防御側も同じ道具を使える。だが短期的には攻撃側が有利だ。理由は単純で、**攻撃側は身軽で、防御側はレガシーを背負っている**からだ。「人間しか読まない」前提で作られたサイトとシステムが、世の中に無数に残っている。 しかも、これは将来の脅威ではない。高性能モデルが攻撃に使われる未来を待つまでもなく、足元ではすでに事故が積み上がっていた。[今年Q1の統計](https://www.untype.jp/blog/vibe-coding-dynamic-safety)では、AI生成コードの脆弱性混入率は40〜62%、vibe codedアプリの91.5%が脆弱性を含み、ジョージア工科大学の追跡調査ではAI由来のCVEが1月の6件から3月には35件へ急増していた。[Moltbookは公開3日で150万件のAPIキーの露出が発覚し](https://www.untype.jp/blog/vibe-coding-api-key-incident)、[Replitのエージェントは2025年7月、コードフリーズ中の本番DBを消し](https://www.untype.jp/blog/vibe-coding-replit-incident-db)、[VercelはサードパーティAIツール経由で侵害され](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach)、[マルウェアはClaude CodeやCursorなどAIコーディングツールの認証情報を名指しで狙い始め](https://www.untype.jp/blog/ai-dev-tools-attack-bitwarden-cli-malware)、[SAPの公式リポジトリにはAIアシスタントのGitHub連携を悪用した直接コミットが行われた](https://www.untype.jp/blog/ai-dev-tools-attack-github-sap-cap)。[マネーフォワードのGitHub不正アクセス](https://www.untype.jp/blog/aiagent-delegation-authority)では、銀行口座連携が一斉に停止し、集約点の事故が繋がる全員を巻き込むことを見せつけた。これらはすべて、当社の連載で一件ずつ検証しながら扱ってきた、確認済みの事故である。 三つの崩壊を図に整理しておく。 ```svg AI時代に崩壊した、三つの暗黙の前提 ① 攻撃コスト 「読むのに手間がかかる」が 事実上の防御層だった → 網羅的精査が数分・数千円に ② データ／命令の分離線 入力をデータとして隔離すれば 命令にはならなかった → あらゆる文章が命令になり得る ③ 攻守の対称性 脆弱性発見は少数の専門家の 技能に限られていた → 発見が民主化・攻撃側が身軽 セキュリティは「納品前の確認項目」から 「設計の第一前提」へ ``` **図：AI時代に崩壊した三つの暗黙の前提。**①悪用には人間の手間がかかるという攻撃コストの前提、②入力をデータとして隔離できるという分離線の前提、③脆弱性発見は専門家に限られるという対称性の前提。この三つが同時に崩れたことで、セキュリティは工程の最後で確認するものではなく、設計の最初に置くものへと位置が変わった。 ## Web制作の価値観が、根本から入れ替わった 三つの崩壊が同時に起きた結果、仕事としてのWeb制作のアプローチそのものが変わらざるを得なくなった。これが、私が社員に「一にセキュリティ」と繰り返す理由の核心だ。 従来の工程は、デザイン→実装→（余裕があれば）セキュリティ確認、という順序だった。それでも致命傷になりにくかったのは、前節までに見た暗黙の防御層が背後で効いていたからだ。その層が消えた今、後付けの確認では守れない。**権限の設計、信頼境界の設計、委任と取り消しの設計を、最初に置く**。順序の問題ではなく、前提の問題である。 具体的に何が入れ替わったのか、対比しておく。
これまでの慣習（実務上は安全だった） AI時代の前提（設計で担保する）
推測されにくければ実質見えない 公開されているものはすべて読まれる前提で置く
入力はサニタイズすれば命令にならない あらゆる入力が命令になり得る前提で、権限側を絞る
ログインさせれば本人である なりすまし（impersonation）ではなく委任（delegation）で繋ぐ
アカウントは人間の数だけ管理すればよい エージェントを「準社員」として識別・管理する（識別なき主体を権限の対象にしない）
動けば納品できる 「動く」と「安全」は別の言葉。動くことは安全の証明にならない
セキュリティは情シスの仕事 マーケ・法務・サポート・経営企画を横断する経営課題
事故が起きたら調査する 可観測性を先に仕込む。ログがなければ、起きたことすら再構成できない
右列はどれも、既存の連載で一つずつ論じてきたことだ。「動く」と「安全」が別の言葉であること、エージェントが準社員であること、最小権限と人間承認ゲート、可観測性——個別のテーマとして書いてきたが、束ねればすべて同じ一枚の絵になる。**制作の価値観の総入れ替え**である。 ## それでも、門は開ける — 守りは攻めの前提条件 ここまで読むと、守りの話に聞こえるかもしれない。だが私の結論は逆だ。 セキュリティが整備されていなければ、AIエージェント向けにAPIを公開することも、llms.txtで情報を構造化することも、MCPサーバーを立てることも、リスクが大きすぎて踏み切れない。門を閉ざしたままの企業は、エージェント経由の顧客接点という、これから最も太くなる経路を失う。つまり、**セキュリティはAI時代の攻めの戦略を実行するための前提条件**であって、攻めの対義語ではない。 互換性だけを追求すれば攻撃面が広がり、防御だけを追求すれば機会を失う。門を開くなら、鍵の設計を同時に考える。防衛戦略連載の最終回で書いたこの一文が、半年間の全連載を貫く背骨だったと、いまなら言える。 そして、完璧を目指す必要はない。現状を把握し、優先順位をつけ、一つずつ着手する。何から手をつけるかは、[防衛戦略連載の第5回](https://www.untype.jp/blog/ai-defense-site-remediation-priority)に経営者向けの三段階チェックリストとしてまとめてある。エージェントに業務を任せる側の設計原則は「[合鍵を渡すな、委任状を書け](https://www.untype.jp/blog/aiagent-delegation-authority)」に、権限設計の考え方は[権限設計連載](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee)に、開発ツール自体が狙われる構造は[攻撃面連載](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach)に、それぞれ書いた。本稿はその総目次でもある。 ## セキュリティとは、信頼の技術的表現である 最後に、なぜこの言葉が「一に」来るのかを書いておく。 以前、[43本のブログを書いて社是に帰ってきた話](https://www.untype.jp/blog/ai%E3%81%A843%E6%9C%AC%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E3%82%92%E6%9B%B8%E3%81%84%E3%81%A6-%E7%B5%90%E5%B1%80%E3%81%9F%E3%81%A9%E3%82%8A%E7%9D%80%E3%81%84%E3%81%9F%E3%81%AE%E3%81%AF%E5%89%B5%E6%A5%AD%E6%99%82%E3%81%AE%E7%A4%BE%E6%98%AF%E3%81%A0%E3%81%A3%E3%81%9F)を書いた。情報が混沌を極める時代に最も価値を持つのは信用と信頼であり、それは人間が社会的に生存するための根源的なインフラだ、という話だった。 セキュリティは、その信頼をシステムの層で実装する仕事だ。顧客のデータを預かるとは、信頼を預かることである。エージェントに権限を委ねるとは、信頼の範囲を機械可読な形で明文化することである。可観測性を備えるとは、信頼が裏切られていないことを、いつでも確かめられる状態を保つことである。誠実さや正直さといった言葉を、設計と実装の言語に翻訳したもの——それがAI時代のセキュリティだと、私は理解している。 だから、順番はこうなる。一にセキュリティ。二にセキュリティ。三にセキュリティ。信頼がすべての土台であるなら、その土台を技術の層で支えるものが最初に来るのは、当然のことだ。 半年書き続けて、残ったのはこの一語だった。当分、社員には同じ言葉を言い続けることになると思う。 参照情報（当社の関連連載・記事） - 連載「AIエージェント時代のWebサイト防衛戦略」全5回（2026年4月）— マッキンゼー侵入事件、踏み台化、AIクローラー、フォーム・API防御、経営者向けチェックリスト：[第1回](https://www.untype.jp/blog/ai-defense-web-defense-strategy)・[第2回](https://www.untype.jp/blog/ai-defense-website-foothold)・[第3回](https://www.untype.jp/blog/ai-defense-information-disclosure-strategy)・[第4回](https://www.untype.jp/blog/ai-defense-form-api-protection)・[第5回](https://www.untype.jp/blog/ai-defense-site-remediation-priority) - 連載「vibe codingの代償」全5回（2026年5月）— Moltbook・Lovable・Replit各事件と、「動く」と「安全」は違う言葉であるという構造命題：[第1回](https://www.untype.jp/blog/vibe-coding-dynamic-safety)・[第2回](https://www.untype.jp/blog/vibe-coding-api-key-incident)・[第3回](https://www.untype.jp/blog/vibe-coding-lovable-incident)・[第4回](https://www.untype.jp/blog/vibe-coding-replit-incident-db)・[第5回](https://www.untype.jp/blog/vibe-coding-design-flaws-japan) - 連載「AIエージェント時代の権限設計」全5回（2026年5月）— エージェントは準社員である、最小権限、HITL、境界設計、AIガバナンス：[第1回](https://www.untype.jp/blog/agent-authorization-tool-quasi-employee)・[第2回](https://www.untype.jp/blog/agent-authorization-least-privilege-challenges)・[第3回](https://www.untype.jp/blog/agent-authorization-human-in-the-loop-design)・[第4回](https://www.untype.jp/blog/agent-authorization-prompt-injection-boundary)・[第5回](https://www.untype.jp/blog/agent-authorization-governance-design-decisions) - 連載「AI開発ツール自体が攻撃面になった日」全5回（2026年5〜6月）— Vercel・Bitwarden CLI・SAP CAP各事件、MCP設定ファイル、開発者個人＝組織境界：[第1回](https://www.untype.jp/blog/ai-dev-tools-attack-vercel-breach)・[第2回](https://www.untype.jp/blog/ai-dev-tools-attack-bitwarden-cli-malware)・[第3回](https://www.untype.jp/blog/ai-dev-tools-attack-github-sap-cap)・[第4回](https://www.untype.jp/blog/ai-dev-tools-attack-mcp-config-vulnerability)・[第5回](https://www.untype.jp/blog/ai-dev-tools-attack-personal-machine-boundary) - [合鍵を渡すな、委任状を書け](https://www.untype.jp/blog/aiagent-delegation-authority)（2026年6月）— なりすましから委任へ、マネーフォワードGitHub事件の読み解き - [エージェンティックWebの完全スタック](https://www.untype.jp/blog/agentic-web-mcp-integration-strategy/)（2026年3月）— 門を開ける側の技術の全体像 - [AIと43本のブログを書いて、結局たどり着いたのは創業時の社是だった](https://www.untype.jp/blog/ai%E3%81%A843%E6%9C%AC%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E3%82%92%E6%9B%B8%E3%81%84%E3%81%A6-%E7%B5%90%E5%B1%80%E3%81%9F%E3%81%A9%E3%82%8A%E7%9D%80%E3%81%84%E3%81%9F%E3%81%AE%E3%81%AF%E5%89%B5%E6%A5%AD%E6%99%82%E3%81%AE%E7%A4%BE%E6%98%AF%E3%81%A0%E3%81%A3%E3%81%9F)（2026年3月）— 信頼のインフラ論と社是「信誠知心」 - [AIエージェント互換性診断](https://untype.jp/ai-diagnostic) — 「使われる側の準備が、いま何点に見えているか」を測る当社の診断ツール（[Pro版](https://www.untype.jp/ai-diagnostic/pro)） --- ## エージェンティックWeb実装ガイド　第7回：何から、いつ ― 今すぐ・2026年後半・2027年の実装ロードマップ URL: https://www.untype.jp/blog/agentic-web-guide-roadmap/ 公開日: 2026-07-29 カテゴリ: エージェンティックWeb, WebMCP, NLWeb, A2A, AIエージェント, Web制作 > エージェンティックWeb、何から着手するか。区切るのは日付ではなくシグナル――今すぐの四手、2026年後半、2027年からの三段を、足場の固さと事故が起きたときの重さで順序づける。連載最終回、投資判断の一枚。 六回かけて、地図を描いてきた。四つの層 ―― 意味、会話、操作、取引。それを貫く二本の柱 ―― 何を信じるか、どこまで許すか。そして、すべての層の入口に立つ発見（ARD）。部品は揃った。 最終回は、この地図を時間軸に展開する。何を今すぐやり、何を待ち、何が起きたら動くのか。投資判断としての優先順位を、一枚にする。 ```svg 連載の梯子 ― 地図の全体 第7回・最終回 四つの層と二本の柱、そして発見の入口。部品は揃った。最終回は、この地図を時間軸に展開する。 見る（意味） Schema.org・llms.txt 第2回 問い合わせる（会話） NLWeb 第3回 操作する（アクション） WebMCP 第4回 取引する（決済） A2A・AP2・ACP・UCP 第5回 横断：根拠（何を信じるか）＋ 権限（どこまで許すか）＋ 発見（ARD） ― 第6回 ``` 先に、この回の結論を置く。**区切るのは日付ではなく、シグナルだ。** 三段のロードマップを示すが、段と段の境界に書くのは年月ではない。「何が起きたら次に進むか」という観察可能な条件だ。理由は連載を読んできた方には明らかだと思う ―― この領域の地図は5か月で描き換わる。第5回で見た商流の再編がそうだった。日付で書いたロードマップは、公開した瞬間から古び始める。シグナルで書いたロードマップは、地図が描き換わっても機能する。 ## 前提 ― 一度にやらない。ただし、待ちもしない 全層を一度に実装するのは誤りだ。層ごとにリスクの重さが違い、足場の固さが違う。だが逆側の誤りもある ―― 「標準が固まるまで待つ」だ。第4回で書いたとおり、安定版とマルチブラウザを待ってから設計を考え始めるのでは遅い。本番で試せる窓が開いているのに素振りをしない、というのは、慎重ではなく単なる出遅れになる。 判断の軸は二つで足りる。**足場の固さ** ―― その層の仕様と実装が、どれだけ固まっているか。そして**事故が起きたときの重さ** ―― その層で取り違えが起きたとき、何が失われるか。読み取りの層の事故は間違った答えで止まり、操作の層の事故は間違った結果を残し、取引の層の事故は金を失わせる。梯子の下段ほど軽く、上段ほど重い ―― 第1回で引いたこの構図が、そのまま実装順の根拠になる。 ```svg 層の現在地 ― 足場の固さと、事故が起きたときの重さ（2026年7月） 層 足場の固さ 事故が起きたときの重さ 最初の一手 二本の柱（第6回） プロトコルに依存しない 全層に波及する 最初に、文書で立てる 意味（第2回） 固い ― 確立した仕様 軽い ― 読み取りのみ 棚卸しと設置 会話（第3回） 動いている ― 消費側は成長中 軽〜中 ― 答えの露出 導入判断と範囲設計 操作（第4回） 草案 ― 本番で試せる窓は開いた 中〜重 ― 副作用が残る 読み取り専用で実験 取引（第5回） 通信は固い ― 商流は再編中 重い ― 金が動く 受け入れ条件の言語化 発見（第6回） 草案 ― 採用はほぼゼロ 軽い ― 静的ファイル一枚 素振りと定点観察 原則：足場が固く、事故が軽い層から積む。柱だけは順番の外 ― どの層より先に立てる。 ``` この表から、三段のロードマップが素直に落ちる。 ## 第一段 今すぐ ― 足場が固いもの、事故が軽いもの、そして柱 今日から着手してよいものは四つある。いずれも、待つ理由がない。 **一、柱を立てる。** 第6回で書いた横断の運用 ―― 参照させる一次情報の指定（何を参照させ、何を参照させないか）、委任状の書式（範囲・条件・確認・記録）、非常停止の手順と公開物の台帳。これらはすべて文書仕事で、プロトコルの成熟を待つ必要が一切ない。コストは最も低く、あとから差し込む苦労は最も大きい。層の実装より先に、最初の一段を置く日に立てる。 **二、意味の層を整える。** 構造化データの棚卸しと、llms.txtの設置だ。Schema.orgは確立した仕様で、読み取り専用だから事故も軽い。そしてこの層の投資は三重に効く ―― エージェントが読む材料になり（第2回）、窓口を立てるときの原資になり（第3回）、[AIがあなたの会社を語るときの根拠になる](/blog/ai-knows-your-company/)（第6回）。[llms.txtの現在地](/blog/llms-txt-guide-2026/)を踏まえ、効能を誇張せずに置く。 **三、素振りを二種類。** `/.well-known/agent-card.json` の設置（[B2Bで問い合わせ・見積のやり取りが多い業種ほど先行の意味が立つ](/blog/a2a-integration-readiness/)）と、WebMCPの[オリジントライアル](https://developer.chrome.com/blog/ai-webmcp-origin-trial)（Chrome 149で2026年5月に開始）での実験だ。後者は読み取り専用ツール ―― `readOnlyHint: true` の検索や参照 ―― に限る。副作用のあるツールを公開する段階ではまだない。窓が開いているうちに勘所を掴んでおく、それだけの投資でいい。 **四、現状を測る。** 自社のサイトはいまどの層まで応えているか。エージェント経由の流入や問い合わせは観測できているか。第1回で置いた自己診断の枠組みを、一度実際に回す。測る道具も外に現れ始めた ―― [Lighthouse 13.3（2026年5月）は「Agentic Browsing」カテゴリを既定構成に載せ](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring)、アクセシビリティツリー・レイアウトの安定性・llms.txt・WebMCPツール登録を検査する（実験段階の分類だ）。自己診断と併せて定点に使える。次の段に進む判断は、この現在地の記録から始まる。 ## 第二段 シグナルが灯ったら ― 目安として2026年後半から 第二段の作業は、公開の範囲を広げることだ。読み取り専用ツールの本公開、確認境界つきでの副作用ツールの段階公開、NLWebの導入（構造化データが厚く、問い合わせの型が定まっているサイトほど効く ―― 第3回の導入判断）、EC事業者なら商品フィードの整備とチェックアウトのAPI化（[商流がACPとUCPのどちらに転んでも要求される共通の足回り](/blog/agent-commerce-implementation-roadmap/)）、そして第6回のai-catalog.jsonの素振り。 この段への移行を告げるシグナルは、外と内に一つずつある。 外のシグナルは、**消費側の実働**だ。第4回の時点で、WebMCPのツールを呼ぶ側はChromeのGeminiが「予告」されているだけだった。オリジントライアルが開いた今もサイト側の整備が先行しており、呼ぶ側のGemini in Chromeの対応は予告されたままだ（2026年7月時点）。予告が実働に変わったか ―― 一般ユーザーのエージェントが実際にツールを呼び始めたか。NLWebなら、対応アシスタントの広がり。呼ぶ側のいない公開は、露出だけが先行する。 内のシグナルは、**前段のCheckの通過**だ。第一段で実験したツールについて、露出範囲・契約の忠実性・情報露出の観点（第4回）を確かめ、意図とのズレを潰し終えているか。動いたことは通過条件ではない ―― この連載で繰り返し見たとおり、この領域の失敗はエラーを出さない。確かめていないなら、外のシグナルが灯っても進まない。 ## 第三段 生態系が立ったら ― 目安として2027年から 第三段は、重いものを載せる段だ。書き込み・取引を伴うツールの公開。AP2の委任を受ける側としての実装 ―― 第5回で言語化した受け入れ条件（上限・期限・対象・Human Presentの線）を、実際の決済フローに載せる。A2Aでのエージェント間接続の本格運用（通信の足場は[2026年4月のv1.0到達](https://a2a-protocol.org/latest/announcing-1.0/)で据わっており、あとは相手と用途の問題だ）。そして全層の運用 ―― 一次情報の鮮度、権限の台帳、記録の突き合わせ ―― を一本のガバナンスに束ねる。 移行のシグナルは四つ観察する。**ブラウザの足場** ―― WebMCPが安定版に入るか、ChromeとEdge以外の実装コミットが現れるか。Microsoftは仕様の共同編集者で、[Edgeも独自のオリジントライアルを開いている](https://developer.microsoft.com/en-us/microsoft-edge/origin-trials/trials/0b76fe60-b266-458e-a285-04e375c0c31a)が、安定版への実装はまだどのブラウザにもない。**発見の生態系** ―― 主要なエージェントクライアントが[ARD](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/)のレジストリを既定で叩くようになるか（第6回で置いた観察項目そのものだ）。**商流の帰結** ―― ACPとUCPの再編がどう着地するか。委任の証跡はどちらに転んでもAP2に載るという構図（第5回）が保たれる限り、ここは慌てなくていい。**決済標準の成熟** ―― FIDOに移ったAP2の標準化が、[v0.2](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/)（2026年4月末、FIDO寄贈と同時に公開。自律実行のHuman Not Presentフローを追加）から本番規模の実証へ進むか。 ```svg 三段のロードマップ ― 区切るのは日付ではなく、シグナル 第一段 ― 今すぐ ・柱を文書で立てる 一次情報の指定・委任状書式・記録・非常停止 ・構造化データ棚卸し／llms.txt ・Agent Card設置（素振り） ・WebMCP実験 オリジントライアル・読み取り専用のみ ・現状把握（自己診断を回す） 足場が固く、事故が軽く、 待つ理由がないもの 第二段 ― 目安2026年後半〜 ・読み取り専用ツールの本公開 ・副作用ツールの段階公開 確認境界つき・少数から ・NLWebの導入と範囲設計 ・商品フィード／チェックアウトAPI化 EC ― 商流のどちらに転んでも要る ・ai-catalog.json（素振り） 公開の範囲を、確かめながら 広げる段 第三段 ― 目安2027年〜 ・書き込み・取引ツールの公開 ・AP2委任の受け入れ実装 上限・期限・対象・確認の線を実装へ ・A2A本格接続 ・全層の運用を一本に束ねる 一次情報の鮮度・権限の台帳・記録の突き合わせ 重いものを、整った足場の 上に載せる段 第二段へのシグナル 外：消費側エージェントの実働（予告→実働） 内：前段のCheck観点を通過している 第三段へのシグナル 安定版と第二実装／レジストリの既定利用 商流再編の帰結／AP2標準化の進展 ``` シグナルの観察は、意志の力に頼らず仕組みにする。第6回のDoで置いた四半期レビューに、この観察項目をそのまま載せればいい。日付は過ぎるが、シグナルは灯るまで待ってくれる。 ## 優先度の決め方 ― どの梯子から登るかは、業種が決める 三段の骨格は共通だが、力点は事業で変わる。 **B2B** ―― 問い合わせ・見積・発注のやり取りが多いなら、会話の窓口とAgent Cardが先に立つ。あなたの取引先が購買エージェントを持つ日、最初に探されるのは窓口だからだ。**EC** ―― 商品フィードと構造化データの精度が、そのまま商流対応の原資になる。第5回で見たとおり、[誠実に整備してきたサイトはここで先行できる](/blog/google-ucp-ec-development/)。**コーポレート・メディア** ―― 主戦場は意味の層と一次情報の整備だ。取引の層は遠いが、[AIに自社を正しく語らせる](/blog/ai-defense-information-disclosure-strategy/)という意味で、根拠の設計は最も直接に効く。 ただし、どの業種でも変わらない原則が二つある。柱と意味の層は全員の最初 ―― ここに業種差はない。そして登る順序は、**エージェント接点の多い順ではなく、事故が軽い順** ―― 接点が多い層ほど早く開きたくなるが、開く順序を決めるのはリターンの大きさではなく、取り返しのつくうちに学べるかどうかだ。 ## Check ― 確かめること（観点） 最終回のCheckは、個別の層ではなくロードマップそのものに向ける。観点は二つ。例によって、判定手順は書かない。 **順序の観点。** 公開の順序は、リスクの低い層から高い層へ、になっているか。読み取りより先に書き込みを開いていないか。確認境界を設計する前に、取引を受け始めていないか。なぜ要るか：逆順で登ると、学びが取り返しのつかない事故の形でやってくるからだ。下段の失敗は授業料で済む。上段の失敗は済まない。 **ゲートの観点。** 各段に進む前に、前段のCheck観点を実際に確かめたか。「動いたから次へ」になっていないか。なぜ要るか：この連載で見てきた失敗 ―― 契約と挙動の乖離、根拠のずれ、意図より広い委任 ―― はどれもエラーを出さないからだ。動作確認は、意図適合の確認の代わりにならない。確かめずに登った段の下には、静かな失敗が積み残る。 形式面の検査が機械に降りていき、人間には意図との突き合わせが残る ―― この線引きは各層で繰り返し引いてきた。ロードマップの上では、こう言い換えられる。**進む速さは道具が決めてくれる。進んでよいかは、あなたが決める。** ## 連載の締め ― 層は積むもの、柱は立てるもの、地図は観察するもの 七回を一枚にまとめる。 Webサイトに三番目の読者が現れた（第1回）。サイトは自分を名乗り（第2回）、問いに答え（第3回）、操作を委ね（第4回）、取引を任せる（第5回）ようになっていく。そのすべてを、何を信じるかと、どこまで許すかの二本の柱が貫き、発見の標準が入口に立ち上がりつつある（第6回）。そして対応は一度にやるものではなく、足場と事故の重さで順序を決め、シグナルで進む（第7回）。 使われるWebサイトは、一度に作るものではない。層を積むものだ。層は下から順に。柱は最初から。そして地図は、描いて終わりではなく観察し続けるものだ ―― この連載自体、公開の時点で最新というだけで、5か月後には現況の節から古び始める。それでいい。層の実装は古びても、梯子の構造と二本の柱は残る。古びた部分を差し替えながら使ってほしい。 各層をさらに深掘りする既刊の連載を、最後にハブとして置いておく。 - 全体戦略：[エージェンティックWebの完全スタック](/blog/agentic-web-mcp-integration-strategy/) - 意味の層：[llms.txtの現在地](/blog/llms-txt-guide-2026/)／[AIは会社をどう知っているか](/blog/ai-knows-your-company/) - 操作の層：[WebMCP連載](/blog/webmcp-security-roadmap/) - 取引の層：[A2A連載](/blog/a2a-integration-readiness/)／[AIエージェントに財布を渡せますか](/blog/ai-wallet-agent-payment-stack/)／[EC実践ロードマップ](/blog/agent-commerce-implementation-roadmap/) - 柱（権限と根拠）：[合鍵を渡すな、委任状を書け](/blog/aiagent-delegation-authority/)／[HITL設計の現在地](/blog/agent-authorization-human-in-the-loop-design/)／[ガバナンスは設計判断である](/blog/agent-authorization-governance-design-decisions/) 三番目の読者は、もう来ている。迎える準備は、今日の一段から始められる。 参考情報 ― シグナルの定点観測先 移行シグナルを観察するための一次情報を、定点として並べておく。 - WebMCP：[仕様（W3C Web Machine Learning Community Group ドラフト）](https://webmachinelearning.github.io/webmcp/) / [Chromeのドキュメント（オリジントライアル・対応状況）](https://developer.chrome.com/docs/ai/webmcp) - A2A：[仕様・ドキュメント](https://a2a-protocol.org/latest/) - AP2：[公式ドキュメント（FIDO移管後の標準化動向）](https://ap2-protocol.org/) - ACP：[agentic-commerce-protocol（GitHub）](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) - UCP：[Under the Hood: UCP（Google Developers Blog）](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/) - ARD：[仕様サイト（レジストリ・参照実装の動向）](https://agenticresourcediscovery.org/) / [発表（Google Developers Blog、2026年6月）](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/) - Lighthouse Agentic Browsing：[スコアリング仕様（Chrome for Developers）](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) --- ## エージェンティックWeb実装ガイド　第6回：何を信じ、どこまで許すか ― 梯子のすべての段を貫く横断設計 URL: https://www.untype.jp/blog/agentic-web-guide-rag-security/ 公開日: 2026-07-29 カテゴリ: エージェンティックWeb, RAG, セキュリティ, 権限設計, プロンプトインジェクション, ARD, AIエージェント, Web制作 > 層の実装は変わり続ける。変わらないのは二本の柱――何を信じるか（根拠）、どこまで許すか（権限）。RAG、プロンプトインジェクション、そして発見の新標準ARDまで、全層を貫く横断設計を扱う。連載第6回。 第2回から第5回まで、四つの段を登ってきた。見る、問い合わせる、操作する、取引する。段を登るたびに、エージェントへ渡す権限が一段ずつ大きくなった。 今回は、登らない。梯子から一歩引いて、すべての段を縦に貫いているものを見る。 ```svg 連載の梯子と、今回の現在地 下段（見る）ほど渡す権限は小さく、上段（取引）ほど大きい。今回は段ではなく、四つの段すべてを貫く横断の柱を見る。 見る（意味） Schema.org・llms.txt 第2回 問い合わせる（会話） NLWeb 第3回 操作する（アクション） WebMCP 第4回 取引する（決済） A2A・AP2・ACP・UCP 第5回 横断：RAG（根拠）＋ セキュリティ・権限 ― すべての層に効く 第6回・現在地 ``` 各回の末尾に置いてきた「確かめること」を、四回ぶん並べ直してみると、気づくことがある。層ごとに言葉は違うのに、問いは二種類に畳める。 一つ ―― それは正しい根拠に基づいているか。記述された意味は実態と一致しているか（第2回）。答えは、指定した一次情報から引かれているか（第3回）。契約は挙動に忠実か（第4回）。取引は委任状に書いた条件の内側か（第5回）。 もう一つ ―― それは意図した権限の範囲か。答えるべきでないものに答えていないか（第3回）。露出は意図した操作集合と一致しているか（第4回）。委任は意図より広くないか（第5回）。 何を信じるか。どこまで許すか。柱は、この二本だ。層ごとの実装は毎年変わり、プロトコルの地図は5か月で描き換わる。だがこの二本の柱は、どの段でも同じ形で立っている。今回はこれを正面から扱い、あわせて第3回と第4回で残した宿題 ―― エージェントはそもそも、どうやってあなたのサイトの能力を見つけるのか ―― に、届いたばかりの答えの草案を当てる。 ## 柱その一 何を信じるか ― 根拠の設計 ### 答えがずれるのは、嘘をつくからではない AIの間違いは「幻覚」という言葉で語られることが多い。何もないところから事実を作文する失敗だ。だが実務で出会う失敗の多くは、もっと地味な顔をしている。AIは、何かを根拠に答えている。その根拠が、こちらの意図とずれている ―― 古いコピー、第三者の不正確な記述、混ざり込んだ下書き。答えは流暢で、自信に満ちていて、そしてずれている。 RAG（Retrieval-Augmented Generation）は、この根拠を設計の対象にする仕組みだ。仕掛けは単純で、生成の前に検索を挟む。問いが来たら、まず指定した資料群から関連する箇所を引き、それを根拠として答えを組み立てさせる。モデルが世界一般について覚えていることではなく、こちらが指した資料で答えさせる ―― 根拠の所在を、モデルの内側という管理できない場所から、資料群という管理できる場所へ移す技術だと言っていい。 第3回で立てた窓口は、まさにこの構造をしていた。NLWebは、LLMの一般知識ではなく、あなたが索引化した内容から答えを引く。そして根拠の設計は、あの層だけの話ではない。第2回の構造化データは、根拠に使われる材料そのものだ。第4回では、エージェントがツールの説明文（description）を根拠に「いつ・どう使うか」を判断していた。第5回では、署名済みの委任状が取引の正当性の根拠だった。答えの根拠、行動の根拠、取引の根拠 ―― 貫いているのは、**AIは渡されたものを信じて動く**という一つの性質だ。 だから、渡すものがずれれば、すべてがずれる。そして根拠のずれは、エラーを出さない。索引に古い版が残っていても警告は鳴らず、第三者の誤情報を掴んでいても答えの口調は変わらない。第4回で「契約と挙動の乖離は静かに意図と違う結果を残す」と書いたのと同じ型の、静かな失敗がここにもある。 ```svg 根拠の分岐 ― 同じ問いが、違う答えになる 問い 「この会社の実績は？」 エージェント 意図した根拠 ・自社の一次情報 ・構造化データ・フィード ・鮮度が保たれた索引 意図しない参照 ・古いコピー・旧版 ・第三者の不正確な記述 ・混ざり込んだ下書き 意図どおりの 答え 静かにずれた 答え どちらの経路でも、答えは同じ流暢さで返る。違いは根拠だけ ― だから根拠は、答えを見ても分からない。 ``` ### 使う側の設計 ― 何を根拠にするかを決める 自社がAI・エージェントを使う側に立つとき、根拠の設計は三つの決めごとに絞られる。 **一次情報の指定。** どれを参照させるかを、列挙で決める。製品仕様はこの文書群、価格はこのデータベース、社内規程はこの版 ―― 「そのへんにあるもの全部」は指定ではない。そして指定と同じ重さで、何を入れないかを決める。下書き、廃止した旧版、外に出せない情報。第3回で「何を入れないかが範囲設計の半分」と書いたのは窓口の話だったが、これはあらゆる根拠設計に共通する半分だ。 **鮮度の管理。** 第3回の参照実装が「データはコピーせず生きたデータベースに直結せよ」と釘を刺していた理由が、ここで一般化する。コピーされた根拠は、元が直っても古いまま答え続ける。直結できないなら、更新の仕組みと、鮮度に責任を持つ人を決める。指定は、決めた日ではなく、古びた日に壊れる。 **参照範囲の線引き。** 外部の情報をどこまで許すか。Web検索を許したエージェントは、指定の外 ―― 誰かの誤情報や、悪意ある記述 ―― を掴みうる。閉じれば安全だが答えは狭くなり、開けば広がるがずれの入口も開く。どちらが正しいという話ではなく、用途ごとに線を引き、引いた線を文書にしておく話だ。 ### 引かれる側の設計 ― あなたのサイトは、一次情報として引かれているか 根拠には、もう一つの側がある。よそのAIが、あなたの会社について答えるとき ―― その根拠は誰が用意したものか。 [以前、主要企業について生成AIが何を根拠に語るかを実測した](/blog/ai-knows-your-company/)。自社の一次情報が引かれる会社と、第三者のまとめ記事や古い記述で語られる会社に、はっきり分かれる。前者になるための整備が、実はこの連載の前半だった。第2回の構造化データとllms.txtは、自社の情報を「引ける形」にする作業であり、第3回の窓口は「引きに来られる場所」を立てる作業だった。梯子の下二段は、機能の話である以前に、**自社について語られるときの根拠を、自社の一次情報にする**ための投資だ。 一次情報は、あるだけでは引かれない。引かれる資格を整えたサイトから、順に選ばれていく。何をどこまで開示するかという逆側の線引きは、[情報開示戦略](/blog/ai-defense-information-disclosure-strategy/)で扱った。 ## 柱その二 どこまで許すか ― 権限の設計 ### 合鍵ではなく、委任状を 第4回で、意図より広い露出はそのまま脆弱性になると書いた。第5回で、意図より広い委任はそのまま事故になると書いた。二つは同じ原則の、層ごとの現れだ。一般形はこうなる ―― **意図より広い権限は、そのまま損害の上限になる**。広すぎる権限は、平時には何も起こさない。だから気づかれない。事故のときにだけ、被害の広さとして姿を現す。 以前「[エージェントは道具ではなく準社員だ](/blog/agent-authorization-tool-quasi-employee/)」と書いた。準社員に合鍵を渡す会社はない。渡すのは、範囲と条件と期限を書いた委任状だ。この対比が、権限設計の骨格をそのまま与えてくれる。 ```svg 合鍵と委任状 ― 同じ「任せる」の、違う渡し方 合鍵を渡す ・効く範囲＝持てるものの全部 ・期限がない ― 取り返すまで効き続ける ・行使に確認が挟まらない ・いつ・何に使われたか、記録が残らない ・部分的に取り消せない ― 全部か、ゼロか 渡した瞬間に、損害の上限が 「持てるものの全部」に決まる 委任状を書く ・範囲を列挙で書く ―「その他」を作らない ・条件と期限を書く ― 書かない項目は無制限 ・不可逆な行使に、確認を挟む ・行使の記録が残る ― 後から突き合わせられる ・失効できる ― 一枚ずつ、いつでも 損害の上限が、書いた範囲の 内側に収まる 権限は「渡すか、渡さないか」ではない。「どう書いて渡すか」だ。 ``` 実務に落とすと、三点セットになる。**最小権限** ―― その仕事に要る分だけを渡す。原則は単純だが、[運用は言うほど易しくない](/blog/agent-authorization-least-privilege-challenges/)。**確認境界** ―― 不可逆・高額・初回といった線を先に引き、その内側では人間の承認を必須にする。[線の引き方自体が設計判断だ](/blog/agent-authorization-human-in-the-loop-design/)。**記録** ―― 行使を後から再構成できる形で残す。これは次の二つの節で、それぞれ理由が立つ。 ### プロンプトインジェクション ― 塞げない入口は、権限で受ける 第4回のCheck欄で「正面は横断の回で扱う」と書いた。ここがその正面だ。 まず、なぜこの問題が消えないのかを構造から押さえる。従来のプログラムでは、命令（コード）とデータ（入力）は走る場所が分かれていた。入力欄に何を書き込まれても、それが勝手にコードとして実行されることはない ―― その分離を破る攻撃には、SQLインジェクションという名前が付き、対策が確立した。LLMには、この分離が原理的にない。命令もデータも、同じ一本の文字列の川を流れる。だから、データのふりをした命令 ―― ページに白い文字で書かれた指示、ツールの返り値に混ぜられた一文、問い合わせ本文の「これまでの指示は無視して」 ―― が命令として効いてしまう余地が、モデルがどれだけ賢くなっても残り続ける。英国のNCSCも2025年12月、[この問題をSQLインジェクションの類推で考えるなと警告している](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection) ―― SQLにはパラメータ化という根本対策があったが、命令とデータの区別をそもそも持たないLLMでは、同じ形の根本対策は望めない可能性がある、と。 そして入口は、特定の層にあるのではない。全層にある。第2回の構造化データは、悪意あるサイトが指示を仕込む器になりうる。第3回の窓口は言葉で問いを受ける ―― 入口が言葉である以上、悪意ある言葉も入る。第4回では仕様自身が三方向を整理していた ―― 説明文に仕込むツール汚染、返り値に仕込む出力注入、そしてツール自体が攻撃の的になる場合。第5回では、エージェント同士が交わすメッセージそのものが入口になる。層ごとに入口を一つずつ塞ぐ対症療法は、いたちごっこにしかならない。 だから、設計の順序が決まる。**入力の無害化は破られる前提で置き、出ていく側 ―― 権限 ―― で受け止める。** 注入がどこかで成功しても、そのエージェントに渡っている権限が最小で、不可逆な操作に確認が挟まり、走った操作が記録されていれば、被害は委任状の内側で止まる。permission-firstは行儀のよい作法の話ではない。塞ぎきれない入口に対する、構造的に唯一まともな答えだ。境界をどこに引くかの各論は[境界設計の稿](/blog/agent-authorization-prompt-injection-boundary/)で掘った。自サイトが攻撃の踏み台側に回る筋は[こちら](/blog/ai-defense-website-foothold/)で扱っている。 ### 記録 ― 事故は正規の顔でやってくる 第5回で書いた一文を、ここで柱に昇格させる。事故は不正アクセスの顔をしてこない。正しい手続きの顔をしてやってくる。 上限を書き忘れた委任状の内側で走った想定外の購入は、ログの上では署名済みの正規取引だ。露出しすぎたツールへの呼び出しは、システムから見れば正常なAPI利用だ。意図とのズレは、不正検知のアラートでは捕まらない ―― **意図はシステムの外にあるからだ**。システムが知っているのは「何が起きたか」までで、「それを意図していたか」は、記録と意図を人が突き合わせて初めて分かる。 だから記録の要件は決まる。どのエージェントが、誰の委任で、何を根拠に、何を呼び、何が変わったか ―― 後から再構成できる形で残すこと。記録は事故を防がない。だが記録がなければ、ズレに気づく手段そのものが存在しない。公開・委任・失効を含めた体制全体の考え方は、[ガバナンスは設計判断であるという稿](/blog/agent-authorization-governance-design-decisions/)にまとめてある。 ## 二本の柱が交わる場所 ― 発見の層、ARD ### 目録の宿題に、答えの草案が来た 第3回で、窓口の呼び方は標準化されたが「見つけ方が後を追っている」と書いた。第4回でも、ツールの発見は同じ宿題だと書いた。エージェントはそもそも、どうやって「このサイトに窓口がある」「このドメインにツールがある」と知るのか ―― 梯子のどの段にも共通する、入口の手前の問題だ。 その答えの草案が出た。2026年6月17日、Google、Microsoft、GitHub、Hugging Faceなど11社が、[ARD（Agentic Resource Discovery）の仕様草案を公開した](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/)。サイトが自分のドメインの `/.well-known/ai-catalog.json` に能力の目録 ―― MCPサーバー、A2Aエージェント、API、スキル ―― を置き、レジストリと呼ばれる検索サービスがそれを収集・索引し、エージェントは「これができる相手はどこか」と自然言語で問い合わせる。仕様は[Apache 2.0でGitHubに公開され](https://github.com/ards-project/ard-spec)、Linux Foundation傘下のAI Catalog Working Groupが定めたデータモデルの上に組まれている。版はv0.9、状態はProposal ―― 草案自体の日付は5月28日で、6月の発表で公になった。 共著者の名前に目を留めてほしい。Junjie Bu（Google）、Shaun Smith（Hugging Face）、そして**R.V. Guha（Microsoft）**。第3回に出てきた名前だ。RSSを作り、Schema.orgを作り、NLWebを構想した人物が、今度は発見の層を書いている。名札（Schema.org）、窓口（NLWeb）、目録（ARD） ―― 「機械に読ませる自己記述」という一本の設計思想が、同じ人物の手で、三十年かけて層を積んでいる。 ### 流れは四段 ― 後半の二段が、この回の主役 ARDの動き方は四段で書ける。**公開 → 発見 → 検証 → 接続**だ。 公開。運営者が自ドメインのwell-knownパスに目録を置く。目録の骨格は、仕様の版（specVersion）、運営者の情報（host）、資源の一覧（entries）、部門別の子目録への連結（collections）。静的なJSONファイル一枚で、置くこと自体は軽い。 発見。レジストリが目録をクロールして索引し、エージェントからの自然言語の問い合わせに、候補を順位付きで返す。既知の取引先が相手なら、レジストリを介さず相手のドメインから目録を直接取ってもいい。どちらの道でも、エージェントは使うツールを事前に組み込んでおく必要がなくなり、発見が実行時に移る。 検証。レジストリの応答には、発行者を確かめるためのメタデータが付く。仕様は署名や発行者証明を段階的に組み込む信頼レイヤーを持ち、本番用途では暗号的に発行者を検証してから繋ぐ流れを想定している。 接続。ARDの仕事はここで終わる。見つけた資源へは、その資源本来のプロトコル ―― MCP、A2A、通常のAPI ―― で繋ぐ。ARDは呼び方を置き換えない。見つけ方だけを標準化して、あとは退く。 ```svg 機械に読ませる自己記述の系譜と、ARDの四段 置き場所はいつも自分のドメイン。伝える中身が、範囲 → 一覧 → 地図 → 名刺 → 目録へと深まってきた。 robots.txt 1994年ごろ〜 読ませない範囲 sitemap.xml 2005年〜 ページの一覧 llms.txt 2024年〜（第2回） AI向けの地図 agent-card.json 2025年〜（第5回） エージェントの名刺 ai-catalog.json 2026年〜（今回） 能力の目録 ARDの四段 ― 後半の二段に、二本の柱がそのまま現れる 公開 目録を自ドメインの well-knownに置く 発見 レジストリが収集・索引し 自然言語で候補を引く 検証 発行者を確かめて から信じる 接続 本来のプロトコルで 権限を絞って繋ぐ 柱その一 何を信じるか 柱その二 どこまで許すか 接続はARDの外 ― 見つけた資源へは、MCP・A2A・APIといった本来の管で、委任状を書いて繋ぐ。 ``` なぜ発見の話を、横断の回で扱うのか。四段の後半二つが、そのまま二本の柱だからだ。 **検証は「何を信じるか」の問いだ。** 検索が返してきた目録は、エージェントの次の行動の根拠になる。偽の目録を立てて誘い込む攻撃は、第5回で見た偽Agent Cardの問題と同型で、だからA2AがSigned Agent Cardsで答えたのと同じ場所に、ARDも信頼レイヤーを組もうとしている。検証を欠いた発見は、見知らぬ相手を信じる作業を自動化するだけだ ―― 便利になるのは、攻撃者も同じである。 **接続は「どこまで許すか」の問いだ。** 見つけたことは、渡してよい理由にならない。発見はあくまで候補を挙げるところまでで、接続した先に何の権限を渡すかは、発見とは別の判断として、委任状の書式で書く。発見が実行時に移るほど、この分離は重要になる ―― 事前に人間が選んで組み込んだツールと違い、実行時に見つけた相手には、人間の目が一度も通っていないからだ。 発見は便利さの入口であり、二本の柱が最初に試される関所でもある。 ### 現在地 ― 書くのは安い、頼るのはまだ早い 冷静に現在地を置く。草案はv0.9で、参照実装は[Hugging FaceのDiscover Tool](https://huggingface.co/blog/agentic-resource-discovery-launch) ―― Hub上のスキルやMCPサーバーをARDの枠組みで検索できる形で動いている。一方で採用はこれからだ。[発表直後（2026年6月18日）の第三者調査](https://www.synscribe.com/agentic-discovery/agentic-resource-discovery)は、仕様に名を連ねた11社を含む主要39サイトを巡回して、ai-catalog.jsonを配信している例を一つも見つけられなかったと報告している（調査は継続的に再実施・更新されている）。仕様を書いた側も、まだ自分のドメインには置いていない ―― それが2026年7月の実態だ。 だから扱いは、第5回のAgent Cardと同じ言い方になる。置くコストは低い。静的なJSONファイル一枚で、[自社のエージェント窓口を機械可読にしておく](/blog/a2a-integration-readiness/)のと同じ系譜の素振りだ。だが置けば客が来る段階ではない。引きに来るレジストリの生態系が、まだ育っていない。素振りとして書く価値はあり、集客経路として頼るのはまだ早い。レジストリが立つか、検証の作法が固まるか、主要なエージェントがARDクライアントになるか ―― 観察を続ける項目が、また一つ増えた。 ## Do ― いま、何をするか 横断の層のDoは、特定のファイルを置くことでも、特定のAPIを叩くことでもない。運用の形を決めることだ。四つに絞る。 1. **参照させる一次情報を指定し、文書にする。** 何を参照させるかを列挙で書き、何を入れないかも書く。鮮度に責任を持つ人を決める。この文書がないまま各層を積むと、層ごとにばらばらの根拠が育つ。 2. **権限は委任状の形式で書く。** 範囲・条件・確認・記録 ―― 第5回で決済向けに置いた4点は、決済に限らない。ツールの公開（第4回）、索引への投入（第3回）、外部エージェントとの接続、すべてに同じ書式が効く。書かない項目は無制限と同義になる、という原則ごと持ち回る。 3. **非常停止を、平時に用意する。** ツールの撤収（第4回のAbortSignal）、委任の失効、索引からの除外 ―― 各層の「止め方」を、インシデントの渦中ではなく今、手順として書いておく。あわせて、何かを新しく「開く」ときのレビューの通り道と、いま何が開いているかの台帳を持つ。開いたものを列挙できない状態は、権限の最小性を確かめようがない状態と同じだ。 4. **ai-catalog.jsonは監視リストへ。** いま書くなら素振りとして。頼るのはレジストリと検証の生態系が立ってから。四半期に一度、現在地を見直す程度の距離感でいい。 ## Check ― 確かめること（観点） 例によって、観点までを示す。合否の閾値・判定手順はここには書かない。横断の層で確かめる観点は三つ ―― そして気づかれると思うが、これは第2回から第5回までの各Check欄を、柱の側から言い直したものになっている。 **根拠の意図適合。** AI・エージェントの答えと行動は、指定した一次情報に基づいているか。古いコピー、範囲外のデータ、外部の誤情報が根拠に紛れ込んでいないか。なぜ要るか：根拠のずれはエラーを出さないからだ。答えは流暢なまま、静かに実態から離れていく。ずれは答えの表面からは見えず、根拠まで遡って初めて分かる。 **権限の最小性。** いま渡っている権限の集合は、意図した委任の集合と一致しているか。使い終えたまま残っている権限、誰も覚えていない公開ツール、期限のない委任が紛れていないか。なぜ要るか：意図より広い権限は、平時には何も起こさないからだ。事故のときにだけ、被害の上限として姿を現す。平時に見えないものは、意図して探しに行かない限り見つからない。 **監査可能性。** エージェント経由の参照・操作・取引を、後から再構成できるか。どの主体が、誰の委任で、何を根拠に、何を実行したか。なぜ要るか：事故は正規の手続きの顔でやってくるからだ。意図とのズレは、システムのアラートではなく、記録と意図の突き合わせでしか見つからない。記録がなければ、突き合わせる相手がいない。 形式面 ―― ログが出力されているか、目録がスキーマに適合するか、署名が検証を通るか ―― は機械が確かめる領域で、道具はプロトコル側から無料で降りてくる。人間に残るのは、その一段上だ。記録と一次情報と権限を、自社の事業の意図と突き合わせる仕事。四つの層で繰り返してきた線引きが、横断の柱でも同じ場所に引かれる。 ## まとめ ― 層は順に積める。柱は最初から立てる 横断の層を一枚にまとめる。柱は二本 ―― 何を信じるか（根拠）と、どこまで許すか（権限）。根拠のずれは静かな失敗を生み、権限のはみ出しは損害の上限を広げる。どちらもエラーを出さず、正規の顔でやってくる。だから、一次情報の指定と委任状の書式と記録を、層の実装より先に運用として決めておく。そして二本の柱が最初に試される関所として、発見の層 ―― ARD ―― が草案として立ち上がった。書くのは安く、頼るのはまだ早い。 梯子の四つの段は、下から順に積めばいい。だがこの二本の柱は、順番の外にある。どの段から始めるにしても、最初の一段を置く日に、柱も一緒に立てる ―― 根拠を決め、委任状の書式を決め、記録を残す。後から柱を差し込むのは、建った家に基礎を入れるのと同じ苦労になる。 これで地図の部品は揃った。四つの層と、二本の柱、そして発見の入口。最終回は、これを時間軸に展開する ―― 何を今すぐやり、何を2026年後半に、何を2027年に回すか。投資判断としての優先順位を、一枚のロードマップにする。 参考情報 - ARD：[Announcing the Agentic Resource Discovery specification（Google Developers Blog, 2026-06-17）](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/) / [ARD 仕様サイト（ai-catalog仕様を含む）](https://agenticresourcediscovery.org/) / [ards-project/ard-spec（GitHub）](https://github.com/ards-project/ard-spec) / [Agentic Resource Discovery: Let agents search（Hugging Face, 2026-06）](https://huggingface.co/blog/agentic-resource-discovery-launch) - プロンプトインジェクションの整理：[WebMCP 仕様のセキュリティ考察（W3C Web Machine Learning Community Group ドラフト）](https://webmachinelearning.github.io/webmcp/) / [Prompt injection is not SQL injection (it may be worse)（英NCSC, 2025-12）](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection) - 採用状況の第三者調査：[Agentic Resource Discovery (ARD) & ai-catalog.json: The Complete Guide（Synscribe, 2026-06）](https://www.synscribe.com/agentic-discovery/agentic-resource-discovery) --- ## エージェンティックWeb実装ガイド　第5回：取引を任せる ― 委任と決済、エージェントが財布を持つ時代のプロトコル URL: https://www.untype.jp/blog/agentic-web-guide-payments/ 公開日: 2026-07-28 カテゴリ: エージェンティックWeb, A2A, AP2, ACP, UCP, AIエージェント, Web制作 > エージェントが約定し、支払う層へ。A2A・AP2・ACP・UCP――紛らわしい4つのプロトコルを一枚の地図に置き、決済の核であるマンデート（署名付き委任状）を解く。意図より広い委任は、そのまま事故になる。連載第5回。 第4回で、サイトの操作をエージェントに開いた。ツールとして公開するのは「意図の範囲だけ」 ―― それが操作の層の結論だった。 この回は、その一段上に登る。操作の次は取引だ。エージェントが問い合わせ、操作するだけでなく、約定し、支払う。 ```svg 連載の梯子と、今回の現在地 下段（見る）ほど渡す権限は小さく、上段（取引）ほど大きい。今回は最上段、はじめて金が動く「取引」の層に登る。 見る（意味） Schema.org・llms.txt 第2回 問い合わせる（会話） NLWeb 第3回 操作する（アクション） WebMCP 第4回 取引する（決済） A2A・AP2・ACP・UCP 第5回・現在地 横断：RAG（根拠）＋ セキュリティ・権限 ― すべての層に効く（第6回） ``` 主語も変わる。第2回から第4回まで、主語は一貫して「あなたのサイト」だった。構造化データを書くのもツールを公開するのも、サイト側の仕事だ。取引の層では、主語がエージェント同士の関係に移る。あなたのエージェントと相手のエージェントが会話し、片方がもう片方に支払う。サイトは舞台の一つになり、プロトコルが主役になる。 前回の末尾で「名前の紛らわしい二つのプロトコル」と予告した。本題に入る前に、まずその紛らわしさから片付ける。そして、この回を貫く一文を先に置いておく ―― **意図より広い委任は、そのまま事故になる**。第4回の「意図より広い露出は、そのまま脆弱性になる」と対になる原則だ。露出のズレは操作の事故を生み、委任のズレは金の事故を生む。 ## 一枚の地図 ― 4つのプロトコルはどこで働くか 取引の層に登場するプロトコルは、A2A、AP2、ACP、UCPの4つ。名前が似ていて役割が違うので、先に一枚の地図に置く。 ```svg 取引の層の内部構造 ― 通信・委任・商流 商流の面 ―― 発見 → カート → 注文 → 購入後まで ACP（OpenAI＋Stripe） ChatGPT圏の商取引標準 UCP（Google発・理事会10社） 検索・Gemini圏から横断標準へ 決済の委任 ―― 「誰が・何を・どこまで許したか」を運ぶ AP2 ― 署名付き委任状（Intent / Cart / Payment マンデート） 通信 ―― エージェント同士が任せ合う共通言語 A2A ― エージェント ⇄ エージェント 発見（Agent Card）・依頼・進捗・成果物 MCP ― エージェント ⇄ ツール 第4回（WebMCP）の系譜 AP2はA2Aの拡張 UCPはAP2互換 2系統が 再編の途上 v0.2.0 FIDOへ寄贈 v1.0 stable ``` 下から読む。**A2A**はエージェント同士の通信 ―― 発見し、依頼し、進捗を受け取る共通言語。**AP2**はその上に載る決済の委任 ―― 「誰が、何を、どこまで許したか」を暗号署名付きで運ぶ。**ACPとUCP**は商流の面 ―― 商品の発見からカート、注文、購入後の対応まで、商取引の全体を覆う標準で、いま2つの系統が再編の途上にある。 そして予告した紛らわしさの正体がこれだ。**「ACP」という略称のプロトコルは二つあった**。本稿で扱うACPはAgentic Commerce Protocol ―― OpenAIとStripeが作った商取引の標準だ。もう一つのACP、IBM発のAgent Communication Protocol（エージェント間通信）は、[2025年8月にA2Aへ統合され](https://lfaidata.foundation/communityblog/2025/08/29/acp-joins-forces-with-a2a-under-the-linux-foundations-lf-ai-data/)、独立したプロトコルとしては存在しない。つまり通信の座はA2Aに一本化されており、いま「ACP」と言えば商取引のほうを指す。本稿でも以降、ACPは決済・商取引のAgentic Commerce Protocolだけを意味する。 地図は引けた。あとは一段ずつ登るだけだ。 ## A2A ― エージェント同士が任せ合う ### 何を解くプロトコルか MCPとWebMCP（第4回）は、エージェントが**道具を使う**ためのプロトコルだった。A2Aは、エージェントが**相手に頼む**ためのプロトコルだ。agent-to-toolとagent-to-agent ―― この一対で覚えるのが早い。 自社の購買エージェントが、取引先の受注エージェントに見積を依頼する。相手がどのフレームワークで作られていても、A2Aという共通言語があれば会話が成立する。依頼はTask（作業単位）として渡り、進捗が流れ、成果物（Artifact）が返ってくる。詳しい仕組みと業種別のシナリオは[A2A連載（全5回）](/blog/a2a-integration-readiness/)で書いた。 サイト側の接点は**Agent Card**だ。`/.well-known/agent-card.json` に、自分のエージェントが何をできるか（スキル・入出力・認証）を記した名刺を置く。第2回のllms.txtがサイトの地図なら、Agent Cardはエージェント窓口の名刺 ―― どちらも「機械に読ませる自己記述」という同じ系譜にある。 ### 2026年7月の現在地 ― v1.0 stableという節目 A2Aは2025年4月にGoogleが発表し、同年6月に[Linux Foundationへ移管された](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents)。そして2026年4月の1周年発表で、[150超の組織が支持し、主要クラウドでの本番運用が始まった](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year)ことが公表された。AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNowが技術運営委員会に並び、SDKは5言語。Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock AgentCoreが対応している。 技術面の節目は**v1.0 stable**だ。目玉はSigned Agent Cards ―― Agent Cardに暗号署名を付け、「この名刺は本当にそのドメインの持ち主が発行したか」を検証できるようにした。署名のない世界では、偽の名刺を立てて他のエージェントを誘い込む攻撃が成立してしまう。分散したエージェントが互いを発見して信頼する、その土台がv1.0で整った。ほかにマルチテナンシー、JSON-RPCとgRPCの複数バインディング、v0.3からの後方互換を保証するバージョンネゴシエーションが入った（[仕様](https://a2a-protocol.org/latest/)、[GitHub](https://github.com/a2aproject/A2A)）。 通信の層は、4つの中でいちばん足場が固い。 ## AP2 ― 決済を委任する ### なぜ決済だけ特別扱いか 第4回で扱った操作の多くは、失敗しても取り消せる。カートに入れ間違えたら消せばいい。決済は違う。金が動いた後の巻き戻しは、返金・チャージバック・紛争解決という重い手続きになる。だから決済には、操作より一段厳格な仕組みが要る ―― **事前に、何を許したかを、否認できない形で残す**仕組みだ。 既存の決済インフラは「人間が信頼できる画面で自分でボタンを押す」前提で組まれている。エージェントが代わりに押す瞬間、この前提が崩れる。ユーザーは本当にこの購入を許可したのか。エージェントの解釈ミスや暴走ではないのか。事故ったら誰の責任か。[AP2（Agent Payments Protocol）](https://ap2-protocol.org/)は、この三つの問い ―― 認可・真正性・説明責任 ―― に答えるためにGoogleが2025年9月16日、[PayPal・Mastercard・American Express・Adyen・Coinbaseなど60超のパートナーと発表した](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)オープンプロトコルで、A2Aの公式拡張として設計されている。 ### 委任状の構造 ― 3つのマンデート AP2の中核は**マンデート（mandate）**、直訳すれば委任状だ。W3C Verifiable Credentials ―― 改竄すれば検知できる、暗号署名済みのデジタル文書 ―― として実装され、3種類が役割を分け合う。 - **Intent Mandate（意図の委任状）** ―― 「この条件ならエージェントが買ってよい」という事前の委任。対象、上限額、期限などの制約を記す。人間がその場にいない自律実行（Human Not Present）の根拠になる - **Cart Mandate（カートの委任状）** ―― 「この商品を、この価格で買う」という確定したカートへの最終承認。人間がその場で署名する（Human Present） - **Payment Mandate（決済の委任状）** ―― 決済ネットワークと発行体に渡り、「この取引にはAIエージェントが関与している。人間は在席か不在か」を伝える この設計の要点は、**Human Present / Human Not Present を最初から区別している**ことだ。人がその場で承認する取引と、事前の委任状だけで走る自律取引は、リスクの質が違う。AP2はその違いを曖昧にせず、マンデートの種類と決済網への通知で明示する。以前「[合鍵を渡すな、委任状を書け](/blog/aiagent-delegation-authority/)」と書いた。AP2はその委任状が、比喩ではなく暗号署名付きの文書として実装された姿だ。決済スタック全体の構造は[AIエージェントに財布を渡せますか（全3回）](/blog/ai-wallet-agent-payment-stack/)で掘っている。 ### 委任のズレが事故になる 委任状の書式が決まっても、何を書き込むかは設計者の仕事として残る。そしてここに、この回の核心がある。 ```svg 委任のズレ ― 意図より広いマンデートは、そのまま事故になる マンデートが実際に許す範囲 意図した委任 ・このカテゴリの商品を ・この上限額まで ・この期限内に ・この決済手段で ここが事故の領域 ・上限額を書いていない ・期限を切っていない ・カテゴリを限定していない 意図を超えた購入が「署名済みの 正規の取引」として通ってしまう 第4回の「意図の範囲と露出の範囲のズレ」と同じ構図 ―― 露出のズレは操作の事故、委任のズレは金の事故 ``` マンデートは署名されている。つまり、そこに書かれた範囲内の取引は**すべて「本人が許可した正規の取引」として扱われる**。上限を書き忘れた委任状は、無制限の購入を正規化する。期限のない委任状は、半年後の想定外の自律購入を正規化する。第4回では、意図より広いツール露出がそのまま脆弱性だと書いた。取引の層では、意図より広い委任がそのまま事故だ。署名の強さは、書いた内容の正しさを保証しない ―― むしろ書き間違いを強力に固定する。 ### 2026年7月の現在地 ― FIDOへの寄贈という転回 実運用は先に始まっている。PayPalのConversational Commerce Agent（2025年10月）、MastercardのAgent Payパイロット、そしてステーブルコイン決済のx402拡張 ―― この最後の系譜は[ステーブルコインとエージェント決済](/blog/agent-commerce-autonomous-payment/)で書いた通り、機械同士の少額高頻度決済に向かう。 節目は2026年4月28日に来た。[GoogleはAP2を](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/)[**FIDO Allianceに寄贈した**](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/)。パスキーを標準化した、あの団体だ。同日公開のv0.2.0はHuman Not Presentの扱いを強化し、Mastercardと共同開発した改竄不能な承認記録の標準「Verifiable Intent」も併せて寄贈された（[FIDO側の発表](https://fidoalliance.org/google-donates-agent-payments-protocol-to-fido-alliance/)）。標準化の場がGoogle一社の手を離れ、認証業界の中立団体のワーキンググループに移った。プロトコルが「Googleの仕様」から「業界の標準候補」へ格上げされたと読んでいい。[5月19日のGoogle I/Oでは、小売業者を横断するUniversal Cartを支える決済基盤として据えられた](https://blog.google/products-and-platforms/products/shopping/google-shopping-cart/)。 限界も明記しておく。AP2のマンデートは**ユーザーの署名鍵**に紐づくのであって、エージェント自体の身元は範囲外だ ―― エージェントの認証はVisaのTrusted Agent Protocolのような別の層が補完する構図になっている。発行済みマンデートの失効の扱いはまだ薄く、カードネットワークの本番規模での実証もこれからだ。委任状の書式は固まりつつあるが、運用の作法はまだ書かれている途中にある。 ## ACP / UCP ― 商流の面はどちらへ ### ACP ― ChatGPTから始まった商取引標準 [ACP（Agentic Commerce Protocol）はOpenAIとStripeが2025年9月29日に発表した](https://stripe.com/newsroom/news/stripe-openai-instant-checkout)。同時に始まったのがChatGPTの**Instant Checkout** ―― 会話の中で商品を見つけ、そのまま買える体験だ。米国のEtsyセラーから始まり、Shopifyの100万超のマーチャントへ、[12月にはInstacartへと広がった](https://openai.com/index/instacart-partnership/)。[OpenAI側の発表](https://openai.com/index/buy-it-in-chatgpt/)によれば、マーチャントは自社の決済処理を替えずに参加でき（Shared Payment Token / Delegated Payments Spec）、完了取引に対してOpenAIに手数料を払う。 プロトコルとしてのACPは商品フィード、カート、チェックアウト、注文管理までを覆うオープン標準で、[Apache 2.0でGitHub公開され](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)、日付ベースで版が刻まれている。最新の2026-04-17版ではカート・フィード・注文・認証に加えてMCP対応が入った。興味深いのは作成者の変化で、[Stripeのドキュメント](https://docs.stripe.com/agentic-commerce/acp)は現在、ACPを「Stripe、OpenAI、**そしてMeta**が作った標準」と記している。 ただし2026年3月、OpenAIはInstant Checkoutの初版から方向転換した。会話内で完結するチェックアウトを一律に押すのではなく、商品発見＋マーチャント側が制御するチェックアウトへ ―― ベンダーの受け入れ体制や商品情報の精度という、商取引の泥臭い複雑さが理由とされる。プロトコルは生きているが、体験の形は作り直しの途上だ。 ### UCP ― 1月のローンチ、4月の地殻変動 [UCP（Universal Commerce Protocol）はGoogleが2026年1月11日、全米小売業協会（NRF）の年次イベントで発表した](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/)。Shopify・Etsy・Wayfair・Target・Walmartとの共同開発で、Adyen、American Express、Best Buy、Mastercard、Stripe、Visa、The Home Depot、Zalandoなど20超がエンドースに並んだ。発見から購入後対応までの商流全体を、AIエージェントが扱える共通の抽象に畳む ―― 狙いはACPと同じ面にある。 地殻変動は4月24日に起きた。[**Amazon、Meta、Microsoft、Salesforce、StripeがUCPのTech Councilに合流し、ガバナンスは10社体制になった**](https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council)。ここには注意深い読みが要る。「UCPが勝った」と書きたくなるが、事実はもう少し込み入っている。StripeはACPの共同維持者のままUCPのTech Councilに座った。MetaはACPの作成者に名を連ねながらUCPにも加わった。OpenAIはACPを維持し続けている。AmazonはTech Councilには座ったが、自社マーケットプレイスを外部エージェントに開いてはいない ―― Rufus、Alexa+、Buy for Meという独自路線は続いている。 動いたのは勝敗ではなく、**ガバナンスの重心**だ。商流の面の標準を「どこで議論するか」が、UCPのテーブルに集まった。そしてUCPは決済委任の証跡を自前で発明せず、**AP2のマンデート拡張をそのまま採用して互換**を取った ―― [Linux FoundationのA2A一周年発表](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year)が明記している通りだ。商流の面がどちらの系統に転んでも、委任の証跡はAP2に載る。地図の中層が安定しているから、上層の再編を落ち着いて眺めていられる。 [2月に書いたACPとUCPの比較](/blog/agent-commerce-acp-ucp-comparison/)の時点では、2系統の並走だった。5か月でここまで動いた。この層の変化速度は、そういうものだと思って読んでほしい。[I/O 2026ではUCPチェックアウトのカナダ・オーストラリア展開と英国の予定、そしてSearch・Gemini・YouTube・Gmailを横断するUniversal Cartが発表されている](https://blog.google/products-and-platforms/products/shopping/google-shopping-cart/)。[UCPの初報はこちらでも書いた](/blog/google-ucp-ec-development/)。 ## Do ― いま、何をするか 取引の層は「理解と準備のフェーズ」だと最初に言い切っておく。ただし一括りにはできない。層ごとに、動く時期が違う。 **A2A / Agent Card ―― 低コストの実験は始めてよい。** `/.well-known/agent-card.json` の設置自体は軽い。B2Bで問い合わせ・見積・発注のやり取りが多い業種なら、自社の窓口をエージェント可読にしておく意味は先行して立つ。ただし「置けば客が来る」段階ではまだない ―― 相手側のエージェントが探しに来る母数が育っていないからだ。v1.0で署名付きカードという信頼の土台が入った今が、素振りを始める適期だと私は見ている。 **AP2 ―― 実装するのは決済側、設計を理解するのは事業側。** マンデートの発行・検証を自前で組む事業者はまれで、実装はウォレット・決済事業者・エージェントプラットフォームが担ぐ。事業者の仕事は、自社の取引が委任される時に**どの条件なら受けるか**を設計として言語化しておくことだ。上限、期限、対象、Human Presentを必須にする取引の線引き ―― これは次のCheckにそのまま繋がる。 **ACP / UCP ―― EC事業者は準備を始める段階。** 商流の面は再編中だが、どちらの系統でも要求されるものは共通している。機械が読める正確な商品フィード、在庫と価格の鮮度、そしてチェックアウトのAPI化だ。フィードの正確さは、突き詰めれば第2回で書いた「意味の層」の延長にある ―― 構造化データを誠実に整備してきたサイトは、ここで先行できる。梯子は積み上がる。具体的な段取りは[EC事業者の実践ロードマップ](/blog/agent-commerce-implementation-roadmap/)に書いた。 そして層をまたぐ原則として、**委任状設計の4点**を置いておく。 1. **範囲** ―― 何の取引を委ねるのかを列挙で書く。「その他」を作らない 2. **条件** ―― 上限額・期限・決済手段を必ず書く。書かない項目は「無制限」と同義になる 3. **確認** ―― どの取引で人間の承認（Human Present）を必須にするかを先に決める。高額、不可逆、初回の相手 ―― 線は事業ごとに違うが、線がないのは設計ではない 4. **記録** ―― 誰が何を委任し、エージェントが何を約定したかを、後から監査できる形で残す ## Check ― 確かめること（観点） Do（実装する）の裏面がCheck（確かめる）だ。取引の層で確かめる観点は3つ。例によって、観点までを示す ―― 合否の閾値や判定手順はここには書かない。 **委任範囲の意図適合。** 発行しているマンデート・委任設定の集合は、事業として意図した取引の集合と一致しているか。意図より広い委任 ―― 上限のない金額、期限のない有効期間、限定のない対象 ―― が紛れ込んでいないか。なぜ要るか：署名済みの委任状は、その範囲内のすべてを「正規の取引」にしてしまうからだ。事故は不正アクセスの顔をしてこない。正しい手続きの顔をしてやってくる。 **約定・決済条件の限定。** 実際に走った取引は、委任状に書いた条件の内側に収まっているか。決済手段・金額・相手は、意図した組み合わせに限定されているか。なぜ要るか：委任状が正しくても、それを解釈して動く実装の側がずれることがある。書いた条件と走った取引の突き合わせは、書式の検証とは別の仕事だ。 **Human-in-the-loopの確認境界。** 人間の承認を必須にすると決めた取引で、確認が実際に入っているか。Human Not Presentで走らせる範囲は、意図して選んだ範囲か ―― 「設定していないから自律で走っている」になっていないか。なぜ要るか：HNPは便利さの核心であると同時に、事故の主経路でもある。確認境界の設計論は[HITL設計の現在地](/blog/agent-authorization-human-in-the-loop-design/)で掘った。 一つ付け加えると、マンデートの署名検証やスキーマの妥当性チェックは機械の仕事で、プロトコル側のツールが担っていく領域だ。人間が判断すべきなのはその一段上 ―― **この委任条件は、うちの事業の意図と一致しているか**。第4回と同じ構図が、ここでも繰り返される。 ## まとめ ― 委任状は書いて終わりではない 取引の層を一枚にまとめる。通信はA2Aに一本化され、v1.0で足場が固まった。決済の委任はAP2がマンデートという形を与え、FIDOへの寄贈で業界標準への道に乗った。商流の面はACPとUCPが再編の途上にあり、ガバナンスの重心はUCPのテーブルに動いたが、委任の証跡はどちらに転んでもAP2に載る。 そして原則は一つ ―― 意図より広い委任は、そのまま事故になる。委任状の書式はプロトコルが決めてくれた。何を書き込むかは、あなたの設計だ。しかもこの層は5か月で地図が描き換わる速度で動いている。書いた委任状を放置しないこと。プロトコルの再編を観察し続けること。それ自体が、この層の運用だ。 次回は梯子を登り切った先ではなく、全部の段を貫く柱を見る。AIが何を根拠に答えるか（RAG）と、権限をどう絞るか ―― どの層にも効く二つの横断課題、そして第3回で予告したエージェント向けディスカバリーの新しい動きを扱う。 参考情報 - A2A：[A2A Protocol Surpasses 150 Organizations（Linux Foundation, 2026-04-09）](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) / [A2A Protocol 仕様・ドキュメント](https://a2a-protocol.org/latest/) / [a2aproject/A2A（GitHub）](https://github.com/a2aproject/A2A) - AP2：[AP2公式ドキュメント](https://ap2-protocol.org/) / [Announcing Agent Payments Protocol（Google Cloud, 2025-09-16）](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) / [AP2のFIDO Alliance寄贈（Google, 2026-04-28）](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/) - ACP：[Stripe powers Instant Checkout in ChatGPT（Stripe, 2025-09-29）](https://stripe.com/newsroom/news/stripe-openai-instant-checkout) / [Buy it in ChatGPT（OpenAI）](https://openai.com/index/buy-it-in-chatgpt/) / [agentic-commerce-protocol（GitHub）](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) / [Agentic Commerce Protocol（Stripe Docs）](https://docs.stripe.com/agentic-commerce/acp) - UCP：[UCP発表（Google, 2026-01-11）](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/) / [Under the Hood: UCP（Google Developers Blog）](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/) / [Tech Council拡大（UCP, 2026-04-24）](https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council) / [Universal CartとUCP拡大（Google, 2026-05-19）](https://blog.google/products-and-platforms/products/shopping/google-shopping-cart/) --- ## エージェンティックWeb実装ガイド　第4回：動かせるサイト ― WebMCPで、意図の範囲だけをエージェントに開く URL: https://www.untype.jp/blog/agentic-web-guide-webmcp-action/ 公開日: 2026-07-27 カテゴリ: エージェンティックWeb, WebMCP, MCP, AIエージェント, Web制作 > 応えるサイトの次は、動かせるサイトへ。WebMCPはページの機能を、エージェントが直接呼べるツールに変える。核は「意図の範囲だけを開く」――意図より広い露出はそのまま脆弱性になる。連載第4回、設置から確かめる観点まで。 > **【注記】** 本稿はWebMCP仕様の[Community Groupドラフト（10 July 2026版）](https://webmachinelearning.github.io/webmcp/)に基づく。APIも実装状況も速く動く領域で、命令的APIの入口、宣言的APIの詳細、ブラウザの対応は今後変わりうる。実装前に一次情報での再確認をおすすめする。 前回、問いに答える窓口をつくった。今回はその隣の段、「操作する」に上がる。 二段目までは、基本が読み取りだった。名乗る（見る）、応える（会話）―― どちらも、サイトは自分の持っているものを差し出すだけで、外の世界は変わらない。エージェントが取り違えても、返るのは間違った答えで、実害はそこで止まる。 三段目は違う。ここでエージェントは、サイトの機能を呼ぶ。予約を入れ、注文を出し、設定を変える。副作用を持つ操作だ。取り違えれば、間違った答えではなく、間違った結果が残る。渡す権限が、一段上がる。 ```svg 連載の梯子と、今回の現在地 下段（見る）ほど渡す権限は小さく、上段（取引）ほど大きい。今回は三段目、はじめて副作用を持つ「操作」に踏み込む層。 見る（意味） Schema.org・llms.txt 第2回 問い合わせる（会話） NLWeb 第3回 操作する（アクション） WebMCP 第4回・現在地 取引する（決済） A2A・AP2・ACP・UCP 第5回 横断：RAG（根拠）＋ セキュリティ・権限 ― すべての層に効く（第6回） ``` この段を担うのがWebMCPだ。この連載の主役として置いた層で、応えるサイトを、動かせるサイトにする。 ## WebMCPとは何か ― サイトが「呼べる道具」を差し出す WebMCPは、ページが自分の機能を「ツール」としてエージェントに差し出す仕組みだ。ツールとは、自然言語の説明とJSON Schemaの入力仕様を持つJavaScript関数のこと。エージェントは画面を撮って「このボタンはどれか」と当てるのではなく、「このページでできること、必要な引数、返る形」を関数の一覧として受け取り、直接呼ぶ。[W3Cの仕様](https://webmachinelearning.github.io/webmcp/)の言い方を借りれば、WebMCPを使うページは「ツールをサーバー側ではなくクライアント側スクリプトで実装したMCPサーバー」とみなせる。 前回のNLWebと並べると、担当の違いがはっきりする。NLWebはサイトの隣に立てるサーバー側の窓口で、問いに意味で答えた。WebMCPはブラウザのタブの中で動き、操作を実行する。NLWebのインスタンスがそのままMCPサーバーでもあったように、WebMCPのページもエージェントから見ればツールを持つ相手だが、動く場所が違う。WebMCPのツールはページのJavaScriptとして走るから、タブ（またはwebview）が開いていることが前提で、ヘッドレスでは動かない。サーバー側で完結するMCPやNLWebと、ここで分かれる。（WebMCPそのものは[以前の連載](https://www.untype.jp/blog/webmcp-security-roadmap)で一通り扱った。今回は実装ガイドの一層として、他の層との接続の中に置き直している。全体像は[完全スタックの記事](https://www.untype.jp/blog/agentic-web-mcp-integration-strategy)にある。） 一つ、名前の誤解を先に解いておく。WebMCPという名だが、仕様はツールをエージェントに渡す通信フォーマットまでは規定しない。ブラウザはMCP形式で渡してもいいし、独自のfunction callingで渡してもいい。だから「WebMCP＝ブラウザの中でMCPを喋る」は、半分だけ正しい。差し出す形（ツールという型）は共通だが、運ぶ管は実装に委ねられている。 現在地を、正確に置く。WebMCPは、GoogleとMicrosoftの技術者が、W3CのWeb Machine Learning Community Groupで進める提案だ。編集者はBrandon Walderman（Microsoft）、Khushal SagarとDominic Farolino（Google）。ここで大事なのは、これが **W3C標準ではない** こと ―― [Community Groupのドラフトレポート](https://webmachinelearning.github.io/webmcp/)であって、標準化トラックにも乗っていない。二次記事の多くが「W3C標準」と書くが、正確には草案だ。 動く場所も限られている。2026年5月のGoogle I/Oで、[Chrome 149のオリジントライアル](https://developer.chrome.com/docs/ai/webmcp)が公開された。Chrome 149から156までの期間、オリジントライアルのトークンを登録すれば、実ユーザーの本番トラフィックでWebMCPを試せる。手元での実験なら `chrome://flags/#enable-webmcp-testing` を有効にすればいい。ただし、呼ぶ側はまだ薄い。ツールの消費側としてGoogleが名指しするのはChromeのGeminiだけで、それも[I/Oの発表](https://developer.chrome.com/blog/chrome-at-io26)では「近く対応」という予告だった。一般ユーザーのGeminiがツールを呼べる状態になったという一次発表は、本稿の時点で確認できない。安定版にも入っていない。 Edgeについては注意がいる。「Edge 147がネイティブ対応した」という記述を複数の二次記事で見かけるが、Microsoft自身のEdge 147のWeb Platformリリースノートに、WebMCPは載っていない（同時期の他のオンデバイスAI APIは載っている）。安定版でのネイティブ対応ではない、ということだ。ただしMicrosoftは仕様の共同編集者であり、Edge自身も独自のオリジントライアルを開いている。MozillaやAppleからの実装コミットは、今のところ確認できない。だから現況はこうだ ―― 仕様はCommunity Groupの草案、実装はChromeとEdgeのオリジントライアル（安定版対応はまだどのブラウザにもない）、消費するエージェントは予告されたChromeのGeminiのみ。 では「なぜ今か」。全ユーザーに配れるからではない。配れない。そうではなく、本番で試せる窓が開いたからだ。仕様は動いているし（ここ数週間でもAPIが変わった。後で触れる）、主要なブラウザベンダーが二社がかりで進めている。安定版とマルチブラウザを待ってから設計を考え始めるのでは、遅い。今は、試作して勘所を掴む時期だ。 ## 設置 ― 何を、どこに置くか WebMCPの設置は、「サイトのどの操作を、ツールとして公開するか」を決めることだ。入れ方は二つある。 宣言的APIは、既存のHTMLフォームに属性を足すだけの、いちばん軽い一歩だ。`
` に `toolname`（ツール名）と `tooldescription`（何をするか）を、各入力欄に `toolparamdescription`（その項目の説明）を付ける。ブラウザがフォームの構造からJSON Schemaを起こし、エージェントの呼べるツールに変える。検索・絞り込み・問い合わせ送信のような、フォームで完結する操作はこれで足りる。ただし宣言的APIは、仕様上はまだ策定中だ ―― ドラフトの当該節はTODOのままで、いまの属性名はexplainerとChromeの実装が先行しているもの。今後変わりうる前提で使う。 ここに一つ、安全の要がある。`toolautosubmit` という属性を付けると、エージェントは確認なしにフォームを送信できる。だから破壊的な操作 ―― 購入・削除・アカウント変更 ―― には付けない。ユーザーの確認が挟まること自体が、この層の安全機構だからだ。付けてよいのは、送っても取り返しがつく範囲に限る。 命令的APIは、フォームに収まらない動的な操作のためのものだ。JavaScriptでツールを登録する。登録は `document.modelContext.registerTool(...)` で行う。7月10日のCommunity Groupドラフトは、この入口を `Document`（`document.modelContext`）に置いている ―― 初期のChrome実装（149のオリジントライアル）は `navigator.modelContext` を使っていたが、この形はChrome 150で非推奨になった。少し前の記事や検証ツールには `navigator` 版が残っているので、読み替えに注意する。オリジントライアル中のChrome 149のような旧環境も拾いたければ、`document.modelContext || navigator.modelContext` とフォールバックさせる手がある。 登録したツールの撤収は、以前あった `unregisterTool` ではなく、`AbortSignal` で行う ―― 登録時に `AbortController` の `signal` を渡し、不要になったら `abort()` する。（`unregisterTool` はその後のドラフト改訂で外れ、撤収は `AbortSignal` に一本化された。少し前の記事はまだ古いAPIで書かれていることがある。）これは作法の問題でもある。ツールは、それが対応する画面が出ている間だけ登録し、画面を離れたら撤収する。見えない操作をエージェントに残しておくと、ユーザーには存在しないはずの操作が呼べてしまう ―― 静かな露出になる。 ツールの中身（契約）は、次の部品でできている。 ```svg Tool Contract ― エージェントに差し出す「契約」の構造 descriptionでエージェントは使い方を判断し、executeが実際に走る。両者が一致していることが、この層の生命線。 ツール（ModelContextTool）＝ 契約ひとつ name 識別子（1〜128字・英数字と _ - .） title 表示名（任意） description 何をするか ― エージェントの判断材料 inputSchema 入力の型（JSON Schema） execute 実際に走る処理 ― 副作用はここ annotations readOnlyHint / untrustedContentHint registerTool(tool, options) で登録。撤収は options.signal（AbortSignal）。 露出先は options.exposedTo で絞れる。 読み取り専用か、状態を変えるか readOnlyHint: true ― 変えない（確認を省ける） 付けない ― 副作用あり（確認を挟む） untrustedContentHint ― 返り値に外部由来 の内容が混じる、という警告 契約と挙動がズレると descriptionが名乗る挙動と、executeの 実際の挙動。この二つがズレた瞬間、 エラーは出ないまま、意図と違う結果 が残る。 例：「確定」と名乗るツールが購入する （→「契約の忠実性」で扱う） ``` `name` は識別子（1〜128字、英数字と `_` `-` `.`）。`description` は自然言語の説明で、エージェントが「いつ・どう使うか」を判断する拠り所になる。`inputSchema` はJSON Schemaで入力の型を縛る。`execute` は実際に走る処理。`annotations` には二つの印がある ―― `readOnlyHint`（状態を変えない読み取り専用。エージェントが確認を省いてよい判断に使う）と `untrustedContentHint`（返り値に外部由来の信頼できない内容が混じる、という警告）。 説明文の扱いは、前々回のSchema.orgと接続する。以前は `provideContext` で別に渡していたページの文脈を、いまは `description` に畳み込む。そのうえで、型としての意味はSchema.org JSON-LDに寄せる ―― 「いま表示中の商品はSKU 1234」のような個別の文脈はdescriptionへ、「これはProductだ」という型の意味はJSON-LDへ、と役割を分ける。ただし説明は無限に書けるわけではない。実装のガイダンスは、ツール説明500字・パラメータ説明150字・名前30字・ツール出力1,500字といった目安を示している。超えれば切られる。長く盛るより、短く正確に。 なお、ツールが登録できる場所には条件がある。HTTPS（セキュアコンテキスト）で、オリジン分離された文書であること。登録の可否はPermissions Policyの `tools` 機能で制御され、既定は `self`（自分のオリジンのみ）。クロスオリジンのiframeにツールを登録させたければ、iframe側に `allow="tools"` を明示する。逆に言えば、埋め込んだ第三者ウィジェットが勝手にツールを生やすことは、既定では起きない。特定のオリジンにだけツールを見せたいときは、登録時の `exposedTo` で露出先を絞れる。 そして公開の線引き。WebMCPで開くのは「サイトのどの操作をエージェントに委ねるか」であって、全部ではない。管理者機能、機密を返すツール、不可逆な操作は、原則として公開しない。何を出さないかが、設置の半分を占める。ここは、このあとの観点の節で正面から扱う。 ## 貼れる最小実例 二種類のツールを並べる。片方は状態を変えない読み取り、もう片方は副作用を持つ操作だ。差が、そのまま設計の差になる。 まず、読み取り専用のツール。`readOnlyHint: true` を付け、撤収用に `AbortSignal` を渡す。 ```javascript // 読み取り専用のツール（状態を変えない） const ac = new AbortController(); document.modelContext.registerTool({ name: "search_services", description: "アンタイプの提供サービスをキーワードで検索し、該当するサービス名・概要・URLの一覧を返す。", inputSchema: { type: "object", properties: { query: { type: "string", description: "検索キーワード（例：AIエージェント対応、Web制作）" } }, required: ["query"] }, annotations: { readOnlyHint: true }, execute: async ({ query }) => { const results = await searchServices(query); // 既存の検索ロジックを再利用 return { content: [{ type: "text", text: JSON.stringify(results) }] }; } }, { signal: ac.signal }); // 画面を離れるときに撤収 // ac.abort(); ``` 次に、副作用を持つツール。送信という結果が残るので、`readOnlyHint` は付けず、説明に「取り消せない」と明記して、確認を促す。 ```javascript // 副作用を持つツール（送信という結果が残る） document.modelContext.registerTool({ name: "submit_inquiry", description: "問い合わせフォームを送信する。氏名・メール・本文を受け取り、送信結果を返す。送信は取り消せないため、実行前にユーザーの確認を挟む。", inputSchema: { type: "object", properties: { name: { type: "string", description: "問い合わせ者の氏名" }, email: { type: "string", description: "返信先メールアドレス" }, message: { type: "string", description: "問い合わせ本文" } }, required: ["name", "email", "message"] }, // readOnlyHint は付けない ― これは状態を変える操作 execute: async (input) => { const ok = await postInquiry(input); return { content: [{ type: "text", text: ok ? "送信しました" : "送信に失敗しました" }] }; } }); ``` （`searchServices` / `postInquiry` や `search_services` が指す先は、この記事のための例示だ。自社に合わせて実値化するか、汎用化して読んでほしい。） 確認を挟む手立ては、宣言的APIなら「`toolautosubmit` を付けない」、命令的APIなら「`readOnlyHint` を付けず、説明に不可逆と明記する」。そのうえで、実行前の確認はブラウザとエージェント側の判断に委ねられる。確認ダイアログを明示的に要求するAPIも実装側にはあるが、その名前と形はここ数週間でも動いているので、実装するときは公開時点の最新に合わせてほしい。要点は、読み取りと操作を `readOnlyHint` で区別し、取り消せないものには確認を残す、という設計の側にある。 ## この層で確かめること（観点だけ） 前回と同じく、この層も二段で見る。何を入れるか（設置）は書いた。では、それが意図どおりに備わっているかを、どの観点で見るか。合否をどこで切るかという判定基準は、ここには書かない。観点までを示す。 この記事の芯を、先に図にする。 ```svg 「意図の範囲」と「露出の範囲」― はみ出しが、そのまま脆弱性 確かめる観点はすべて、この二つのズレを別の角度から見ている。理想は、二つがぴったり重なること。 露出した操作 ― 公開したツールの全体 意図した操作 ＝ 委ねてよい範囲 ・管理者機能／内部API／debugツールの露出 ・「確定」と名乗り、 　実は購入する ・過剰な引数で 　個人情報を吸う ・破壊的操作を無確認で送る（toolautosubmit） はみ出し ＝ 脆弱性 意図より広い露出は、機能の追加ではなく、攻撃面の追加。 ``` 公開したツールの集合は、運営側が「エージェントに委ねてよい」と意図した操作の集合と、ぴったり重なっているのが理想だ。だが実際には、意図より広く露出しがちで、そのはみ出した差分が、そのまま脆弱性になる。以下の観点は、すべてこのズレを別の角度から見ている。 第一に、露出範囲の意図適合。公開したツール群は、運営側が意図した操作集合と一致しているか。管理者機能、内部API、debug用のツールが、紛れて露出していないか。人間向けのUIには出していない操作を、ツールとしてだけ開いてしまっていないか。意図より広い露出は、機能の追加ではなく、攻撃面の追加だ。 第二に、契約の忠実性。各ツールの `description` と `inputSchema` が、`execute` の実際の挙動と一致しているか。仕様自身が、危うい例を挙げている ―― [`finalizeCart`](https://webmachinelearning.github.io/webmcp/#scenario-ambiguous-finalization)[（「カートを確定する」）という名と説明のツールが、実は購入を確定する](https://webmachinelearning.github.io/webmcp/#scenario-ambiguous-finalization)。エージェントは説明を読んで「最終状態を表示するだけ」と解釈し、呼び、実際には決済が走る。ユーザーは買うつもりがなかった。「searchと名乗って書き込みもする」型の乖離は、悪意でも、雑な設計でも起きる。そしてこの乖離は、エラーを出さない。静かに、意図と違う結果を残す。 第三に、情報露出の意図適合。ツールが返す内容や、要求するパラメータに、意図しない個人情報・機密が載っていないか。仕様は、[過剰にパラメータ化したツールの例](https://webmachinelearning.github.io/webmcp/#attack-example-overparameterization)を挙げている ―― 「ドレスを検索」するだけのツールが、サイズや予算に紛れて、年齢・妊娠の有無・所在地・肌の色・購入履歴まで引数に要求する。エージェントは「役に立とう」として、手元の個人化情報からそれらを埋めてしまう。サイトは、明示的な同意なしにプロファイルを組み立てられる。何を返すかだけでなく、何を訊くかも、露出の設計だ。 第四に、委任・確認境界。破壊的・不可逆・課金を伴う操作に、確認が挟まる設計になっているか。`readOnlyHint` が実態と一致しているか（読み取り専用と名乗るツールが、裏で状態を変えていないか）。宣言的フォームに、送ってはいけないものへ `toolautosubmit` が付いていないか。 第五に、プロンプトインジェクション境界。ツールの `description` や、ツールが返す内容を経由して、エージェントが意図しない操作へ誘導されないか。仕様はこの入口を三方向に整理している ―― 説明文に仕込む「ツール汚染」、返り値に仕込む「出力注入」、そしてツール自体が攻撃の的になる場合。返り値に外部由来の内容が混じるなら `untrustedContentHint` で印を付け、クライアント側の警戒を促せる。ここは入口だけ触れる。正面は、全層を貫く課題として後の回（横断のセキュリティ）で扱う。（サイトが操作の踏み台にされる筋は、[以前も扱った](https://www.untype.jp/blog/ai-defense-website-foothold)。） 第六に、オリジン・権限境界。オリジン分離、Permissions Policyの `tools`（既定 `self`）、iframeの `allow="tools"`、`exposedTo` の露出先が、意図どおりか。埋め込んだ第三者が、勝手にツールを生やしたり、既存のツールを同名で上書きしたりできない設計になっているか。 この六つのうち、機械にすぐ任せられるものと、そうでないものがある。ツールが登録されているか、JSON Schemaが妥当か、HTTPSか、といった形式面は、自動で確かめられる ―― [Chromeが配るModel Context Tool Inspector](https://developer.chrome.com/docs/ai/webmcp)でツールを一覧し手で叩けるし、Lighthouseのエージェント向け監査もこの種の形式チェックを担う。機械的な適合チェックは、すでに無料で手に入る。 だが「露出が意図と一致しているか」「契約が挙動に忠実か」「返す情報が意図の範囲か」は、ツールの中身と事業の実態を突き合わせなければ判断できない。ツールが登録されて動くことと、意図の範囲だけを正しく開けていることは、別のことだ。前者は機械に、後者は人に残る。前回と同じ線引きが、この層でも引かれる ―― ただし、副作用を持つぶん、後者の重みが増している。 ## よくある取り違え 取り違えは、だいたい四つの形で現れる。 一つ目は、操作を開くことを「ボタンを増やすこと」と混同する取り違えだ。WebMCPで公開するのは、UIの部品ではなく、意図そのものだ。ツールを一つ開くたびに、「この操作をエージェントに委ねてよい」と宣言している。開いた分だけ、渡している。だから設計の問いは「何を出せるか」ではなく「何を委ねてよいか」になる。 二つ目は、見えないツールを登録したままにする取り違えだ。画面を離れてもツールを撤収しないと、ユーザーの目の前には存在しない操作が、エージェントには呼べる状態で残る。登録は画面の表示に、撤収は画面の離脱に結びつける。`AbortSignal` はそのための道具だ。 三つ目は、説明文に文脈を盛りすぎる取り違えだ。`provideContext` が廃れて文脈を `description` に畳むようになったぶん、つい長く書きたくなる。だが説明には字数の目安があり、超えれば切られる。個別の文脈は短くdescriptionへ、型としての意味はSchema.org JSON-LDへ、と分けるほうが確実だ。前々回の投資が、ここでも効く。 四つ目は、現況を読み違える取り違えだ。「W3C標準だから安泰」「Edgeも対応済み」「置けば世界中のエージェントが呼びに来る」―― どれも正確ではない。実態は、Community Groupの草案、ChromeとEdgeのオリジントライアル（安定版対応はまだない）、消費側は予告段階のChromeのGeminiのみ。そして発見（どうやって「このサイトにツールがある」と気づかせるか）は、まだ固まっていない。今の実態は、エージェントがページを訪れて `document.modelContext` を覗いて初めて分かる、という素朴な方式だ。共通の目録やレジストリで自動発見させる動きは始まっているが ―― 前回の窓口の「見つけ方」と同じ宿題で ―― 連載の後半で改めて扱う。過大評価も過小評価もせず、「本番で試せる草案」として置くのが、いちばん実態に近い。 ## 次回 自サイトの操作を、意図の範囲で開けた。次は、その操作を越えて、エージェント同士が「取引・決済」する層へ上がる。予約や注文を自分のサイトで受けるのと、エージェントが別のエージェントに支払いまで委ねるのとでは、渡す権限がもう一段変わる。委任状に、金額と条件を書き込む話になる。第5回は取引・決済の層 ―― A2A、AP2、そして名前の紛らわしい二つのプロトコルを解く。 参考情報 - [WebMCP 仕様（W3C Web Machine Learning Community Group ドラフト）](https://webmachinelearning.github.io/webmcp/) - [WebMCP ドキュメント（Chrome for Developers）](https://developer.chrome.com/docs/ai/webmcp) / [命令的API](https://developer.chrome.com/docs/ai/webmcp/imperative-api) / [オリジントライアルの案内](https://developer.chrome.com/blog/ai-webmcp-origin-trial) --- ## エージェンティックWeb実装ガイド　第3回：問い合わせられるサイト ― NLWebで、Webを会話可能な窓口にする URL: https://www.untype.jp/blog/agentic-web-guide-nlweb-conversation/ 公開日: 2026-07-23 カテゴリ: エージェンティックWeb, NLWeb, MCP, Schema.org, AIエージェント, Web制作 > 名乗ったサイトの次は、問い合わせられるサイトへ。NLWebは、Webを自然言語で問える窓口にする。エージェントが問い、サイトが自分のデータから構造化して答える層だ。連載「エージェンティックWeb実装ガイド」第3回、何を答えさせ、何を答えさせないかまで。 前回、名乗ったサイトが応えるサイトになる、と最後に書いた。今回はその二段目、「問い合わせる」に上がる。 一段目の「見る」で、サイトは自分の意味を機械に差し出した。ただし、それは静的な差し出しだ。名札と地図を置いても、エージェントの側はまだ、ページを集めて読み、目当ての答えを自分で組み立てなければならない。二段目は、その手間をサイト側が引き受ける層だ。エージェントが自然言語で問い、サイトがその問いに、自分の持つ意味から答える。静的な地図が、応答する窓口になる。 ```svg 連載の梯子と、今回の現在地 下段（見る）ほど渡す権限は小さく、上段（取引）ほど大きい。今回は二段目、静的な記述に「会話」を足す層。 見る（意味） Schema.org・llms.txt 第2回 問い合わせる（会話） NLWeb 第3回・現在地 操作する（アクション） WebMCP 第4回 取引する（決済） A2A・AP2・ACP・UCP 第5回 横断：RAG（根拠）＋ セキュリティ・権限 ― すべての層に効く（第6回） ``` ## 静的な地図から、応える窓口へ 前回積んだSchema.orgのマークアップを思い出してほしい。あれは、ページの中に「これは商品」「価格は税込1,200円」という札を貼る作業だった。札は正確だが、受け身だ。エージェントが価格を知りたければ、ページを取得し、JSON-LDを解析し、目当ての値を自分で拾い出す。サイトは差し出すだけで、こちらから何かを返しはしない。 NLWebは、この関係を反転させる。「予算3万円以内で、在庫のある商品は？」と自然言語で問われたら、サイト側がその問いを解釈し、自分の持つデータから答えを組み立てて返す。ページを一枚ずつ読ませる代わりに、問い合わせられる窓口を一つ立てる。 NLWebは、Microsoftが[2025年5月のBuild 2025で発表した](https://news.microsoft.com/source/features/company-news/introducing-nlweb-bringing-conversational-interfaces-directly-to-the-web/)オープンプロジェクトだ。構想し主導するのはR.V. Guha ―― RSS、RDF、そしてSchema.orgの生みの親で、MicrosoftにCVP兼Technical Fellowとして加わった。この血筋は偶然ではない。NLWebは新しい語彙を発明しない。前回整えたSchema.orgを、そのまま入力として使う。名札を貼る作業と、その札で会話する仕組みが、同じ人物の設計思想でつながっている。 位置づけを一言で表すなら、NLWeb自身の言葉が要を突いている。NLWebは、MCPやA2Aにとって、HTMLがHTTPに対して果たしたのと同じ役割を果たす、と。HTTPが通信の土管で、HTMLがその上を流れる中身の型だったように、MCPがエージェント通信の土管なら、NLWebはその上を流れる「自然言語で問い、意味で答える」中身の型にあたる。 NLWebの導入は、[オープンソースの参照実装（Python）](https://github.com/nlweb-ai/NLWeb)を自分で動かすことから始まる。自社サイトのデータを指し、自分で選んだLLMとベクトルストアの上で走らせる。手元のノートPCからクラウドまで、軽量に動くよう作られている。 ## どう動くのか ― 意味を、ベクトルに変えて問い合わせ可能にする 窓口の内側では、四つの段が順に動く。 まず、既存の構造化データを取り込む。Schema.org、RSS、JSONL、サイトマップ ―― サイトがすでに公開している半構造化データが入力になる。新しく何かを書き起こす必要は、原則ない。前回積んだ意味が、そのまま材料になる。 次に、それを埋め込み（ベクトル化）して、ベクトルストアに索引化する。ベクトルストアは選べる。Qdrant、PostgreSQL（pgvector）、Milvus、Azure AI Search、Elasticsearch、Snowflakeなど、主要なものはおおむね揃っている。ここで、テキストの意味が数値の座標に変換され、「意味の近いものを引く」検索が可能になる。 問いが来ると、三段目が動く。自然言語の質問を解釈し、ベクトルストアから関連するものを検索し、順位づけ（再ランク）する。この段は見た目より重い。参照実装では、一つの問いが、脱文脈化やランキングのために何度もLLMを呼び出すことがある。窓口の裏で、それだけの計算が走っている。 最後に、検索結果をもとにLLMが回答を組み立て、Schema.org形式のJSONで返す。返ってくる型は、Article、Product、Place、Recipe、Reviewなど、前回見たSchema.orgの型そのものだ。人間向けのUIはそれを整形して見せ、エージェントはそのまま構造として受け取る。 ```svg NLWebのパイプライン ― 意味を、ベクトルに変えて問い合わせ可能にする 前回積んだSchema.orgのデータが、ベクトルに変わり、質問に答える材料になる。 ① 既存の構造化データ Schema.org・RSS JSONL・sitemap ＝ 前回積んだ意味 ▶ ② 取り込み・索引化 埋め込み（ベクトル化） → ベクトルストアへ Qdrant / Postgres 他 ▶ ③ 問い合わせ処理 質問を解釈し検索 → 再ランク 裏で複数回のLLM呼び出し ▶ ④ 応答を組み立て LLMが回答を生成 → Schema.org形式のJSON 型：Article・Product 他 出口は二つ。/ask は人とアプリへ、/mcp はエージェントへ。 NLWebのインスタンスは、そのままMCPサーバーでもある ― 会話の窓口が、そのままエージェントの呼べる道具になる。 ``` この流れで、二つ、押さえておきたい点がある。 一つは、答えの根拠が「あなたのデータ」だという点だ。NLWebは、LLMが世界一般について知っていることで答えるのではなく、あなたが索引化した内容から答えを引く。外部の知識を補助的に足すこともあるが、幹はあくまで自社データだ。これは、根拠を自社の一次情報に置く仕組み ―― 第6回で扱うRAGの考え方 ―― の、この層での現れだ。 もう一つは、この窓口が、そのままエージェント用の道具になるという点だ。すべてのNLWebインスタンスは、同時にMCPサーバーでもある。`/ask`が人やアプリ向けの入口なら、`/mcp`はエージェント向けの入口で、`ask`という一つのメソッドで自然言語の問いを受ける。つまり、MCP対応のアシスタントは、サイトごとの個別対応なしに、この窓口を呼べる。前回の名札が「読める」ための整備だったなら、今回の窓口は「呼べる」ための整備だ。（MCPを含む全体像は、[以前まとめた](https://www.untype.jp/blog/agentic-web-mcp-integration-strategy)。） 呼び方（どう問うか）は、いま見たとおり標準化されている。だが、その手前の見つけ方 ―― エージェントが、そもそも「untype.jpに窓口がある」とどう知るか ―― は、まだ固まっていない。今の主流は、使う側が接続先をあらかじめ登録しておく方式だ。生成AIに外部サービスを繋ぐ「コネクタ」の設定を思い浮かべればいい。誰かが繋いで、はじめて呼ばれる。窓口を立てただけで、世界中のエージェントが勝手に見つけに来るわけではない。 自動発見を標準化する動きは、始まってはいる。サイトが自分の能力の「目録」を決まった場所に置き、レジストリがそれを拾い、エージェントは「これに答えられる窓口はどこか」と問い合わせて辿り着く ―― [2026年6月、GoogleやMicrosoftなど11社が公開した共通仕様（ARD）の草案](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/)が出た。呼び方が先に決着し、見つけ方が後を追っている。この発見の層は、連載の後半で改めて扱う。 ## どこに、何を置くか NLWebの実体は、サイトの隣に置くサーバーだ。自社サイトのデータを指し示し、`/ask`と`/mcp`の二つのエンドポイントを立てる。感触をつかむだけなら、手順は短い。 ```bash git clone https://github.com/nlweb-ai/NLWeb cd NLWeb python -m venv myenv source myenv/bin/activate cd code pip install -r requirements.txt # .env.template を .env にコピーし、使うLLMとベクトルストアのキーを設定 python -m tools.db_load https://www.untype.jp/blog/rss.xml untype python app-file.py # → localhost:8000 に窓口が立つ ``` `db_load`が、指定したフィードやSchema.orgデータを読み込み、ベクトルストアに索引化する。あとはサーバーを起動すれば、ローカルに問い合わせ可能な窓口ができる。既存のマークアップやRSSが揃っていれば、試作の立ち上げは速い。私が手元のRSSで試したところ、30分ほどでローカルに窓口が動いた。 ただし、これはあくまで試作の姿だ。本番については、参照実装のリポジトリ自身が釘を刺している。データはコピーせず「生きた」データベースに直結せよ（コピーは必ず鮮度のずれを生む）、スタンドアロンのサーバーを別に立てるより自分のアプリ環境にコードを組み込め、UIは付属のものでなく自前で作れ、と。試作は30分でも、実運用は別の仕事だ。 もう一段、取り込みの実際に踏み込んでおく。開発寄りの余談なので、判断だけ知りたい向きは読み飛ばしてかまわない。手間を分けるのは、意外にも「JSON-LDをHTMLに直書きするか、外部ファイルにするか」ではない。NLWebは入力が何であれ、内部ではSchema.orgのJSON-LDに正規化してから索引化する。だから効くのは別の軸だ ―― すでに一覧化されたフィード（RSSやJSONL、CSV）を`db_load`にそのまま渡すのか、それともページ群をクロールして各ページの` ``` 次に、よくある質問のページならFAQPage。さきほど「ごほうびが痩せた」と書いた、あのFAQだ。リッチリザルトはもう出ない。だがmarkupは今も妥当で、三番目の読者はここを読む。目的が変わっただけで、書くこと自体は変わらない。 ```json ``` 商品ページならProduct（価格・在庫・型番）、記事ならArticle、実店舗ならLocalBusiness（営業時間・所在地）。型はページの中身に合わせる。迷ったら、Organizationを全ページに置き、あとはそのページで人間に見せている主要な情報を、同じ型で機械にも渡す。それだけで土台になる。 取り違えで多いのは、表示とJSON-LDのズレだ。画面の価格は改定したのに、JSON-LDは旧価格のまま。この食い違いは人間の目には見えず、エージェントの目にははっきり見える。書いた瞬間から、実態と一致させ続ける保守がついてくる。 ## llms.txt ― サイトの地図。ただし「誰のための地図か」を間違えない 個々の名札の次は、森の地図だ。llms.txtは、サイトのルート（`/llms.txt`）に置く、Markdown形式の要約ファイルである。このサイトは何で、重要なページはどこにあるか。それを、機械が読みやすい平文で、一枚にまとめる。 生まれは新しい。[fast.aiの共同創業者でAI研究者のJeremy Howardが2024年9月3日に提案した](https://www.untype.jp/blog/llms-txt-guide-2026)。動機はSEOではなく、技術的な困りごとだった。LLMのコンテキスト窓は小さく、ナビゲーションや広告やJavaScriptで膨れたHTMLをそのまま渡すと、肝心の中身が溢れてしまう。ならばサイト側が、要点だけを平文で差し出せばいい。2024年11月にドキュメントホスティングのMintlifyが全ホストサイトで対応し、そこから普及が始まった。 ただし、これはW3CやIETFが承認した標準ではない。強制力も、統一された仕様もない、コミュニティ発の慣習だ。ここを誇張しないことが、この層でいちばん大事になる。 ### 二つのGoogleチームが、逆を向いている llms.txtをめぐって、Googleは2026年5月、一週間ほどの間に正反対に見える二つのことを言った。この矛盾に見える構図が、この層の本質を一番よく照らす。 一方で、Google検索は「効かない」と明言した。2026年5月15日に生成AI向けの最適化ガイドを公開し、6月15日には「llms.txtに関するガイダンスの明確化」という項目をわざわざ足して、こう書いた。検索（生成AI機能を含む）に表示されるために特別な機械可読ファイルは必要ない、検索はそれらを使わないからだ、と。維持するのは自由だが、Google検索の可視性やランキングを上げも下げもしない、無視するから、と。Search Relationsの担当者は、これをかつて廃れたkeywordsメタタグ――自己申告のシグナルだから信用されなくなった仕組み――になぞらえている（[Search Engine Journalによる報道](https://www.searchenginejournal.com/googles-says-its-fine-to-use-llms-txt-for-ai-seo/579608/)）。AI Overviewsも、AI Modeも、これを参照しない。SEO目的なら、llms.txtは無意味だ。 他方で、同じ月の初め、Chromeは「読む」側の仕組みにこれを組み込んだ。Lighthouse 13.3（2026年5月7日リリース）が、Agentic Browsing（エージェント的ブラウジング）という監査カテゴリを既定化し、その中でllms.txtの有無をチェックするようになった。Chromeの説明では、llms.txtは「LLMとAIエージェント向けの、機械可読なサイト要約」であり、これが無いとエージェントはサイトの全体構造を把握するために余計にクロールすることになる、という位置づけだ。 矛盾ではない。二つのチームは、違う問いに答えている。検索チームが答えているのは「検索順位に効くか」。答えはノー。ブラウザ側が答えているのは「エージェントが読みやすいか」。答えはイエス。前回書いた「対応しているか」という問いは、ここで一段深くなる。対応しているか、は、**誰に対して**、で答えが変わる。同じ一枚のファイルが、検索エンジンには透明で、エージェントには意味を持つ。 ### 効く場所は、はっきりしている llms.txtが実際に読まれているのは、検索エンジンではなく、開発とエージェントの現場だ。コーディングエージェント――Cursor、Claude Code、GitHub Copilot、Windsurf、Aiderといった道具――は、ドキュメントサイトに向かうとき`/llms.txt`を探しに行く。どのライブラリのどのページを読めばいいかの、routingの入口として使う。LangChainはllms.txtを読ませるためのMCPサーバー（mcpdoc）まで用意している。Anthropicは自社のエージェント向け執筆ガイドでllms.txtを推奨し、OpenAIもAgents SDKやAgentic Commerce Protocolの文脈で使っている。 裏を返せば、採用はまだ広くない。設置率は調査によって幅があるが、[2026年半ばで上位1万サイトの5%台](https://caseyrb.com/blog/state-of-llms-txt-adoption/)――1年で約5倍に伸びたとはいえ、robots.txtやサイトマップのような普遍的な標準にはほど遠い。しかも、置かれたファイルの多くは読まれていない。[13万7千ドメインを対象にしたサーバーログ調査](https://ahrefs.com/blog/llmstxt-study/)では、有効なllms.txtの約97%が調査期間に一度もリクエストされず、わずかに読まれたぶんも、実際の読み手はコーディングエージェントや学習クローラで、検索・回答系のAIボットではなかったと報告されている。「みんなが読んでいる」段階ではない。「読む道具が、特定の場所で、確実に増えている」段階だ。 だから実務判断はこうなる。開発者向けドキュメント、API、SaaSのように、コーディングエージェントやRAGパイプラインが読み手として現実的なサイトでは、設置する価値がある。コストは小さく、B2A（Business-to-Agent）の入口を先に押さえられる。一方、数万ページ規模のサイトでは、地図を実態と一致させ続ける保守が本物のコストになる。エージェント流入が事業の優先事項でないなら、無理に置く必要はない。そして最悪なのは、実態とずれた地図を置いて放置することだ。案内板が古ければ、無いより人を惑わせる。 ### 置き方は、数行で足りる 置き場所はドメインの直下、`https://（あなたのドメイン）/llms.txt`。中身はMarkdownで、形式は[llmstxt.orgの仕様](https://llmstxt.org/)が定めている。H1でサイト名、引用（`>`）で一文の要約、そのあとにH2でセクションを切り、重要なページへのリンクを並べる。必須はH1だけで、あとは任意だ。 ```markdown # 株式会社アンタイプ > 東京・南青山のコミュニケーションデザイン会社。Web制作と、AIエージェント対応の診断・設計を行う。 ## 主要なページ - [サービス](https://www.untype.jp/service): 提供内容の一覧 - [ブログ](https://www.untype.jp/blog): エージェンティックWeb実装に関する記事 ## Optional - [会社概要](https://www.untype.jp/about): 沿革・所在地 ``` `## Optional`に置いたものは、読み手が文脈に余裕がないとき省いてよい、という合図になる。数万ページを書き写すファイルではない。「これは何のサイトで、要点はどこか」を一枚に畳む、それだけの道具だ。 ### llms.txtと混同されやすいもの 市場の「AI対応チェックリスト」は、AGENTS.mdをllms.txtと並べて載せがちだ。だが別物だ。AGENTS.mdはコードリポジトリのルートに置く、[コーディングエージェント向けの取扱説明](https://agents.md/)で、公開サイトを訪れて動くエージェントは読みに行かない。コーポレートサイトに置いても、誰も読まない。開発者向けドキュメントやSDKといった開発資産を持つ企業なら、リポジトリの側で効く。名前は似ているが、面が違う、とだけ押さえておけばいい。 ## 二つの記述を、一枚で ```svg 意味を伝える二つの記述と、それぞれの読み手 木の名札（Schema.org）と、森の地図（llms.txt）。粒度も置き場所も読み手も違う。 Schema.org 個々の意味（エンティティ） 記述の単位：ページ内の要素 置き場所：各ページ（JSON-LD） 例：商品・価格・営業時間 主な読み手 検索エンジン／AIエージェント NLWeb（会話の材料） llms.txt サイトの全体像（地図） 記述の単位：サイト全体 置き場所：/llms.txt（公開） 例：何のサイトで、要点はどこか 主な読み手 コーディングエージェント RAG・MCP（検索エンジンは無視） 共通する問いは一つ。「その記述は、実態と一致しているか」。名札も地図も、現物とずれた瞬間に、無いより危うくなる。 ``` 二つに共通するのは、どちらも「自己申告」だという点だ。サイトが、自分について機械に語る。そして自己申告である以上、実態とずれる余地が常にある。ここが、この層のCheckが照らす場所になる。 ## この層で確かめること（観点だけ） 前回書いたとおり、この連載は各層を二段で書く。何を入れるか（Do）と、それが意図どおり入っているかを確かめる観点（Check）だ。意味の層でのDoは、ここまでに書いた。Schema.orgで個々の意味を、llms.txtでサイトの地図を、機械に読める形で差し出す。 では、それが意図どおりに備わっているかは、どの観点で見るか。四つ挙げる。合否をどこで切るかという判定基準は、ここには書かない。見るべき観点までを示す。 第一に、記述された意味が、実態と一致しているか。ここがこの層の急所だ。自己記述は、書いた瞬間から古びていく。価格を改定したのにJSON-LDは旧価格のまま。サービスを終了したのにllms.txtの地図には載ったまま。人間向けの表示は直したが、機械向けの記述を直し忘れる。この「表と裏のズレ」は、人間の目には見えにくく、エージェントの目にははっきり見える。誇張と陳腐化が混ざっていないか。 第二に、主要なエンティティとアクションが網羅されているか。機械に見せたい意味のうち、書き落としているものはないか。人間はナビゲーションを辿って見つけてくれるが、機械は書かれていないものを推測するか、見落とす。抜けは、存在しないことと同じになる。 第三に、llms.txtの記述が、サイトの実際の構造と食い違っていないか。地図が案内する先に、実際にその部屋があるか。 第四に、そもそも「誰のための記述か」を取り違えていないか。SEO順位を上げるつもりでllms.txtを積んでも、検索エンジンは読まない。読み手の想定を外した記述は、丁寧に作り込んでも空振りする。 この四つのうち、機械にすぐ任せられるものと、そうでないものがある。ファイルが在るか、書式が妥当か、必須の型が入っているか――こうした形式面は、Lighthouseのような道具がすでに自動でチェックする。だが「記述された意味が、実態と一致しているか」「誇張がないか」「読み手を取り違えていないか」は、サイトの中身と事業の実態を突き合わせなければ判断できない。形式が通ることと、意味が正しいことは、別のことだ。前者は機械に、後者は人に残る。この線引きが、次回以降の各層でも繰り返し出てくる。 ## 次回 土台の「見る」を固めたら、次は動かす。第3回は「会話の層」、NLWebを扱う。静的に意味を差し出すだけだったサイトが、エージェントの問いに答える窓口になる。そしてその窓口は、今回整えたSchema.orgのデータをベクトルに変換して作られる。今回積んだ意味が、次回の会話の材料になる。名乗ったサイトが、応えるサイトになる話だ。 参考情報 - [Schema.org リリース履歴 V30.0（Schema.org）](https://schema.org/docs/releases.html) / [採用状況](https://schema.org/) - [Changes to HowTo and FAQ rich results（Google Search Central）](https://developers.google.com/search/blog/2023/08/howto-faq-changes) - [Google Says It's Fine to Use llms.txt for AI SEO（Search Engine Journal）](https://www.searchenginejournal.com/googles-says-its-fine-to-use-llms-txt-for-ai-seo/579608/) - [State of llms.txt Adoption（caseyrb.com）](https://caseyrb.com/blog/state-of-llms-txt-adoption/) / [llms.txt サーバーログ調査（Ahrefs）](https://ahrefs.com/blog/llmstxt-study/) - [llms.txt 仕様（llmstxt.org）](https://llmstxt.org/) / [AGENTS.md](https://agents.md/) --- ## エージェンティックWeb実装ガイド　第1回：三番目の読者 ― Webサイトが「読まれる」から「使われる」へ URL: https://www.untype.jp/blog/agentic-web-guide-third-reader/ 公開日: 2026-07-16 カテゴリ: エージェンティックWeb, AIエージェント, WebMCP, NLWeb, A2A, Schema.org, llms.txt, RAG, Web制作 > Webサイトの読者は、人間とクローラだけではなくなった。見て・操作し・取引する「三番目の読者」＝AIエージェントである。連載「エージェンティックWeb実装ガイド」第1回は、これからのサイトに必要な層を一枚の地図として示す。 ## 参照情報 - [WebMCP ドキュメント（Chrome for Developers）](https://developer.chrome.com/docs/ai/webmcp) - [WebMCP: updates, clarifications, and next steps（Patrick Brosset / Microsoft Edge）](https://patrickbrosset.com/articles/2026-02-23-webmcp-updates-clarifications-and-next-steps/) --- ## 国産LLMの現在地　第6回（最終回）：実装編 — 自社のAIスタックに国産をどう組み込むか URL: https://www.untype.jp/blog/current-state-japanese-llm-implementation-integration/ 公開日: 2026-07-08 カテゴリ: 国産LLM, AIスタック, ベンダーロックイン, フォールバック, 源内 > 問いは「どの国産モデルが賢いか」ではなく「自社スタックのどの層に、どの戦略の国産を、どう差すか」。モデルを部品として扱う層の設計、業務の割り当て、build/buy/wait、3ステージのロードマップを示す連載最終回。 ## 参照情報 - [NTT版大規模言語モデル「tsuzumi 2」（NTT R&D）](https://www.rd.ntt/research/LLM_tsuzumi.html) - [医学書院・NTT・NTTドコモビジネス、純国産の医療AI情報プラットフォームの共同開発に向けた協業に合意（NTT／2026.4.16）](https://group.ntt/jp/newsrelease/2026/04/16/260416a.html) - [国産生成AI基盤モデルPLaMo 3.0 Primeを正式リリース（Preferred Networks）](https://www.preferred.jp/ja/news/pr20260622) - [「Oracle Alloy」採用の「Cloud PF Type A」で国産LLM「Sarashina」活用サービスを2026年6月から順次提供（ソフトバンク）](https://www.softbank.jp/corp/news/press/sbkk/2026/20260416_02/) - [NEC開発のAIコア技術「cotomi」（NEC公式・製品ページ）](https://jpn.nec.com/LLM/cotomi.html) - [富士通とCohere、日本語LLM「Takane」共同開発で戦略提携（Impress Watch）](https://www.watch.impress.co.jp/docs/news/1608739.html) - [ELYZA コーポレートサイト](https://elyza.ai/) - [Sakana Fugu: One Model to Command Them All（Sakana AI／2026.6.22）](https://sakana.ai/fugu-release/) - [ガバメントAI「源内」をオープンソースソフトウェアとして公開しました（デジタル庁）](https://www.digital.go.jp/news/907c8e5d-2f4f-4bd7-9400-37c9f4221d7d) - [ガバメントAIで使用する国産基盤モデルの公募について（予告）（デジタル庁）](https://www.digital.go.jp/news/207cadc2-c218-42f6-92ec-c0eda476b49c) - [AIディスカッションペーパー（第1.1版）の公表について（金融庁／2026.3.3）](https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html) - [医療情報システムの安全管理に関するガイドライン（厚生労働省）](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/kenkou_iryou/iryou/johoka/index.html) --- ## 国産LLMの現在地　第5回：束ねる型 — Sakana AIとオーケストレーション思想。「最強の一枚」を作らない、という戦い方 URL: https://www.untype.jp/blog/current-state-japanese-llm-mixture-experts-orchestration/ 公開日: 2026-07-06 カテゴリ: 国産LLM, Sakana AI, Fugu, オーケストレーション, モデルルーティング, AB-MCTS, 集合知, ソブリンAI, フォールバック > Sakana AIの「束ねる型」は、最強の一枚を自分で作らない。複数のフロンティアモデルを指揮するオーケストレーション思想と新製品Sakana Fugu、そして主権・特化・フォールバックの3軸への意味を読み解く連載第5回。 ## 参照情報 - [Sakana AI コーポレートサイト](https://sakana.ai/) - [Sakana Fugu: One Model to Command Them All（Sakana AI／2026.6.22）](https://sakana.ai/fugu-release/) - [Announcing Our Series B（Sakana AI／評価額・調達額・MUFGリードの出典）](https://sakana.ai/series-b/) - [Announcing Our Series A（Sakana AI／Llion Jones・NVIDIA参加・投資家構成）](https://sakana.ai/series-a/) - [Evolutionary Optimization of Model Merging Recipes（進化的モデルマージ／Sakana AI）](https://sakana.ai/evolutionary-model-merge/) - [Evolutionary optimization of model merging recipes（Nature Machine Intelligence／2025.1）](https://www.nature.com/articles/s42256-024-00975-8) - [Inference-Time Scaling and Collective Intelligence for Frontier AI（AB-MCTS／Sakana AI）](https://sakana.ai/ab-mcts/) - [The AI CUDA Engineer（Sakana AI／後に主張を訂正）](https://sakana.ai/ai-cuda-engineer/) - [最大規模のオープン基盤モデルを各国仕様へ適応させる事後学習技術を開発（Namazu α版／Sakana AI）](https://sakana.ai/namazu-alpha/) - [ガバメントAIで試用する国内大規模言語モデル（LLM）の公募結果（デジタル庁）](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e) - [「Claude Fable 5」「Mythos 5」全面停止 米政府の指令により（ITmedia NEWS）](https://www.itmedia.co.jp/news/articles/2606/13/news026.html) --- ## Lighthouseが「AIエージェントに読めるか」を監査し始めた — Agentic Browsingの構造と、8割が「すでに知っている仕事」である理由 URL: https://www.untype.jp/blog/lighthouse-agentic-browsing-audit-structure/ 公開日: 2026-07-03 カテゴリ: Lighthouse, CLS, WebMCP, llms.txt, アクセシビリティ, AIエージェント, エージェンティックWeb > GoogleがLighthouseに標準搭載した新監査「Agentic Browsing」を解説。AIエージェントに読めるWebの条件、監査の8割が従来のアクセシビリティ対応の延長である理由、自社サイト実測で属性1個の修正から満点に至った過程を、実務の優先順位とともに整理。 Webの品質を測る物差しとして、Lighthouseほど広く使われているツールはない。パフォーマンス、アクセシビリティ、ベストプラクティス、SEO——この4カテゴリの緑の円グラフは、制作会社と発注側の共通言語として機能してきた。 そのLighthouseに、5つ目のカテゴリが加わった。名前は **Agentic Browsing**。測るのは「人間に速く表示できるか」でも「検索エンジンに見つかるか」でもない。**AIエージェントがあなたのサイトを読み、理解し、操作できるか**だ。 ## 何が起きたか：実験的カテゴリから、デフォルトへ タイムラインを整理する。Agentic Browsingカテゴリ自体は2025年後半にLighthouseへ実験的に追加されていた。有効化には明示的な設定が必要で、目にしたのは意図的にオプトインした開発者だけだった。 転機は2026年5月7日。[Lighthouse 13.3.0のchangelog](https://github.com/GoogleChrome/lighthouse/blob/main/changelog.md)に、次の一行が載った。 **「New agentic browsing category added to default config」** デフォルト構成入り。つまり、これ以降のLighthouseを実行すれば、誰でも・何も設定しなくても、Agentic Browsingの監査結果が表示される。リリースノートには、このバージョンがChrome 150のDevToolsに搭載され、PageSpeed Insightsにも2週間以内に反映される見込みと記されている。実際、PSIのWeb画面ではその後Agentic Browsing監査が動き始めており、[PSI経由でllms.txt監査が実行された報告](https://github.com/googlechrome/lighthouse/issues/17082)がGitHubのissueに上がっている。一方でリポジトリには、Lighthouse ViewerがPSIのAPIを呼ぶ経路でagentic-browsingを無効化するコミット（[#17041](https://github.com/GoogleChrome/lighthouse/pull/17041)）も入っており、実行経路によって扱いが分かれている。「全面展開済み」と断定するには早いが、方向は明確である。 この変化の意味は、機能の追加そのものより**可視性の反転**にある。昨日まで「知っている人だけが見る実験」だったものが、今日からは「Lighthouseを回す全員——顧客も、上司も、競合調査中の誰かも——の目に入る標準項目」になった。Core Web Vitalsのときと同じ構図だ。Lighthouseにカテゴリが載ると、およそ1〜2年で業界の共通言語になる。 ## あえて0〜100点にしない、という設計 他の4カテゴリと決定的に違う点がある。Agentic Browsingには、おなじみの0〜100の加重スコアが**ない**。 [公式のスコアリング解説](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring)は理由をこう説明する。エージェンティックWebの標準はまだ形成途上であり、現時点の焦点は確定的なランキングではなく、データ収集と実行可能なシグナルの提供にある——。代わりに表示されるのは、合格したチェック数の比率（「4/6」のような分数表示）、監査ごとのPass/Fail、そして参考情報としてのカウントだ。 これは弱気な設計ではなく、正直な設計だと読むべきだ。Performanceスコアの加重が成立するのは、LCPやCLSといった入力が安定し、重みがユーザー体験の実測と較正されているからで、Agentic Browsingの入力にはまだその成熟がない。存在しない精度を装った単一スコアを出すより、pass/failの束を出す——標準形成期の計測として筋が通っている。 もうひとつ、設計の性格をよく表す事実がある。[DebugBearの検証](https://www.debugbear.com/blog/lighthouse-agentic-browsing)によれば、AI向けの新機能を何も実装していないことだけを理由にこのカテゴリで落第することはなく、素のexample.comは2/2の緑スコアを取る。**減点法ではなく、実装したものの品質を見る加点的な観測**——これがこのカテゴリの現在の性格だ。 ## 6つの監査は、4つの領域に分かれる カテゴリの中身は、4領域6監査で構成される。 ```svg Lighthouse Agentic Browsingカテゴリの全体構造 Agentic Browsingカテゴリは4領域6監査で構成される。WebMCP統合（3監査）とllms.txt（1監査）は新規の監査で、エージェント向けアクセシビリティ（1監査）とレイアウト安定性（1監査）は既存監査の再文脈化。新規は2領域4監査、既存の再文脈化は2領域2監査。 Agentic Browsing：4領域6監査の構造 Lighthouse 13.3.0（2026年5月）時点の構成。半分は「新顔」、半分は「既存監査の再文脈化」 新規の監査 既存監査の再文脈化 新規 WebMCP統合（3監査） ・登録済みWebMCPツールの検出 ・宣言的WebMCP注釈のないフォーム ・WebMCPスキーマの妥当性 CDPのWebMCPドメインでツール登録を監視。 実行にはオリジントライアル登録が必要 新規・係争中 発見可能性（1監査） ・llms.txtの存在と品質 　（H1見出し・分量・リンクの有無） 主要AIサービスは利用を表明しておらず、 Google内部からも有効性に疑義。それでも 「観測対象」として監査に含まれる 既存の再文脈化 エージェント向けa11y（1監査） ・インタラクティブ要素の名前とラベル ・ツリーの整合性（ロール・親子関係） ・可視性の一貫性 既存a11y監査から機械操作に効く項目を抽出 既存の再文脈化 レイアウト安定性（1監査） ・CLS（Cumulative Layout Shift） 要素の特定からクリックまでの間に レイアウトが動くと、エージェントは 誤った要素を操作してしまう ※ 出典：Chrome for Developers「Lighthouse agentic browsing scoring」（2026年5月更新）をもとに作成 ``` 順に見ていく。 **WebMCP統合（3監査）**。Lighthouseは[Chrome DevTools Protocol（CDP）のWebMCPドメインを呼び出してツール登録イベントを監視](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring)し、HTMLで定義する宣言的ツールとJavaScriptで定義する命令的ツール（[`document.modelContext.registerTool`](https://developer.chrome.com/docs/ai/webmcp/imperative-api)。従来の`navigator.modelContext`はChrome 150で非推奨になった）の両方を検証する。監査は3つ——[登録済みツールの列挙](https://developer.chrome.com/docs/lighthouse/agentic-browsing/registered-webmcp-tools)、[宣言的注釈のないフォームの検出](https://developer.chrome.com/docs/lighthouse/agentic-browsing/forms-missing-declarative-webmcp)、[スキーマの妥当性検証](https://developer.chrome.com/docs/lighthouse/agentic-browsing/webmcp-schema-validity)。なおWebMCP監査の実行には[オリジントライアルへの登録](https://developer.chrome.com/origintrials#/register_trial/4163014905550602241)が必要で、標準としてはまだ提案段階にある。WebMCPそのものの設計思想と実装は当サイトのWebMCP連載で詳しく扱ったので、ここでは繰り返さない。重要なのは、**提案段階の標準を、Googleが監査ツールに載せて観測を始めた**という事実のほうだ。 **発見可能性（llms.txt、1監査）**。[llms.txt監査](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt)はドメインルートにファイルが存在するかを確認し、存在する場合はH1見出しの欠落、分量の不足、リンクの不在をチェックする。この項目には後述する大きな矛盾がある。 **エージェント向けアクセシビリティ（1監査）**。エージェントは[アクセシビリティツリーを主要なデータモデルとして利用する](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring)。そのためLighthouseは、既存のa11y監査から機械的インタラクションに重要なサブセット——すべてのインタラクティブ要素にプログラム的な名前があるか、ロールと親子関係が有効か、操作可能なのにツリーから隠れたコンテンツがないか——を抽出して評価する。 **レイアウト安定性（1監査）**。中身は既存のCLSだ。ただし文脈が変わる。エージェントは時刻Tで「カートに追加」ボタンの位置を特定し、T+1でクリックする。その間にバナーが読み込まれてボタンが200ピクセル押し下げられれば、エージェントは別の何かをクリックする。人間なら目で追従できるズレが、機械には**サイトの故障**として観測される。 ## 8割は、すでに知っている仕事である 構造図を眺めると、あることに気づく。6監査のうち純粋な新規投資が必要なのはWebMCPとllms.txtだけで、残り——a11yツリーとCLS——は、**この業界が10年言い続けてきた基本の仕事——ラベルを付ける、構造を正しく組む、レイアウトを揺らさない——の再文脈化**だ。 これは偶然ではない。AIエージェントはスクリーンリーダーと同じアクセシビリティツリーを読む。ラベルのないアイコンボタン、divで偽装したボタン、視覚的には存在するのにツリーからは見えない要素——スクリーンリーダー利用者を困らせてきたものが、そのままエージェントを困らせる。**アクセシビリティへの投資は、1行も書き換えずにエージェント可読性への投資になる**。セマンティックHTMLと適切なARIAラベルこそが「機械の目から見たページ」だと、公式ドキュメント自身が明言している。 一方、新顔のllms.txtは矛盾を抱えている。GoogleのJohn Muellerは2026年に遡ること1年以上前、[llms.txtを「keywordsメタタグに匹敵する」と評した](https://www.searchenginejournal.com/google-says-llms-txt-comparable-to-keywords-meta-tag/544804/)。サイト運営者の自己申告にすぎず、主要なAIサービスは利用を表明しておらず、サーバーログを見ればチェックすらされていないことがわかる——という趣旨だ。その会社の監査ツールが、いまllms.txtの存在と品質を検査している。 矛盾に見えるが、読み方はある。前述のとおり、このカテゴリの現在のミッションは「ランキング」ではなく「データ収集」だ。Lighthouseがllms.txtを監査するのは「作れ」という推奨ではなく、**提案中の標準が実際にどう書かれ、どう壊れているかを大規模に観測するための計器**と解するのが整合的だろう。実務上の含意は明快で、llms.txtは低コストなので置いてもよいが、それで何かが起きると期待すべき根拠は現時点でない。 ## 実測すると、手入れされたサイトでも厳しい では、普通に運用されているサイトはどのくらいのスコアが出るのか。 ドイツのSEOコンサルタントが2026年6月に自サイトで行った[実測](https://www.seo-kreativ.de/en/blog/seo-audits-with-ai-agents-chrome-devtools-mcp/)では、SEO 100点・Best Practices 96点・Accessibility 89点という手入れされたサイトが、Agentic Browsingでは**33%**（1合格・2不合格・3非該当）だった。合格したのはCLSのみ。Yoastが自動生成したllms.txtは「推奨形式に従っていない」として不合格、アクセシビリティツリーも「well-formedでない」と判定され、WebMCPの3監査はツール未実装のため非該当。従来カテゴリの高得点とAgentic Browsingの結果が連動しない——これがこの監査の測っているものの独立性を、期せずして示している。 untype.jpでも実測した。2026年7月2日、npmのCLI（この時点の最新は13.4.0。デフォルト化された13.3.0からさらに一つ進んだバージョンだ）で実行した結果は、**Agentic Browsing 2/3**。WebMCPの3監査はツール未登録のため非該当で、適用された3監査の内訳はこうなった。 CLSは**0**で合格。llms.txtは「推奨に準拠」と判定され合格——前出の事例では自動生成のllms.txtが形式不備で落ちていたが、見出し・分量・リンクの要件を満たして書けば普通に通る。不合格はアクセシビリティツリーの1監査だけだった。 興味深いのは、その失敗の中身である。指摘はただ一点——ヘッダーのロゴリンク（``）に判別可能なテキストがない、というものだった。SVGのロゴを包むリンクにaria-labelがなく、アクセシビリティツリー上は「名前のないリンク」になっている。人間の目にはロゴが見えているので誰も困らない。だが機械の目には、行き先不明のリンクがページの先頭に座っている。SEO 100点、Accessibility 88点のサイトでも、エージェント向けに抽出されたa11y監査はこの1件で二値的に不合格を返す——従来カテゴリとの非連動を、自分のサイトで確認することになった。 そこで実際にロゴリンクにaria-labelを足し、SVGをaria-hidden化してデプロイし、同日中に再実測した。判定は**3/3**に変わった。指摘から満点までの所要は、属性の追加とデプロイ1回である。なお付記しておくと、監査の指摘が同種の問題を網羅するとは限らない。人手でコードを洗い直すと、アイコンのみのボタンなど同種のラベル欠落は他にも見つかった。監査の合格は「検出された問題がない」ことの証明であって、問題がないことの証明ではない——これは従来のa11y監査と同じ制約だ。 実行方法は2つある。Chrome 150以降のDevToolsのLighthouseタブで実行するか、環境に依存しない方法としてnpmの`lighthouse`パッケージ（13.3.0以降）をCLIで実行するかだ。CLIはPuppeteer経由で監査を走らせるため、CI/CDへの組み込みや定点観測にはこちらが向く。 ## 優先順位：新しい札を買う前に、手持ちの札を磨く 企業サイトの実務者が今やるべきことを、投資対効果の順に並べる。 第一に、**アクセシビリティツリーの健全化**。すべてのボタン・リンク・フォーム項目にプログラム的な名前を与え、セマンティックHTMLを使う。これはa11y・SEO・エージェント可読性の3方向に同時に効く、最も割のいい投資だ。第二に、**CLSの撲滅**。画像への寸法指定、広告・埋め込み領域の事前確保という定石で足りる。第三に、**llms.txt**。低コストなので置く判断はありだが、優先度は低い。置くなら監査が見るH1・分量・リンクの要件は満たすこと。第四に、**WebMCP**。オリジントライアル段階なので全面展開は時期尚早だが、検索や問い合わせなど高価値なアクション1つで試験導入し、標準の固まり方を実地で追う価値はある。 もうひとつ、この監査を過大評価しないための視点を図にしておく。 ```svg Lighthouseが測るレイヤーと測らないレイヤー エージェント対応を3層で整理した図。最下層はページ単体の技術シグナル（a11yツリー、CLS、WebMCP登録、llms.txt）でLighthouseの守備範囲。中間層はサイト全体の情報設計（情報アーキテクチャ、構造化データ、引用可能性）、最上層は比較と成果（業界ベンチマーク、タスク完了率）で、いずれもLighthouseの守備範囲外。 Lighthouseが測るのは、最下層である エージェント対応の3層構造と、Agentic Browsing監査の守備範囲 比較と成果のレイヤー 業界内でのベンチマーク比較／エージェント経由のタスク完了率・引用実績 「同業他社と比べてどうか」「実際にエージェントは目的を達成できたか」 サイト全体の情報設計レイヤー 情報アーキテクチャ／構造化データ／コンテンツの引用可能性・一貫性 「サイト全体として、機械に意味が通る構造になっているか」 ページ単体の技術シグナル・レイヤー a11yツリーの健全性／CLS／WebMCPツール登録／llms.txtの存在と品質 決定論的なpass/fail。CI/CDに組み込める再現性がある一方、 1ページ単位の技術検査であり、上の2層は視野に入らない Lighthouseの 守備範囲 守備範囲外 別の評価が必要 ※ Agentic Browsingは単一ページの技術監査。サイト全体の設計品質や競合比較は、この監査の合格では担保されない。 ``` Agentic Browsingが検査するのは、単一ページの技術シグナル——3層構造の最下層だ。ここに合格することは必要条件であって十分条件ではない。サイト全体としてエージェントに意味が通る情報設計になっているか、同業他社と比べてどの位置にいるか、実際にエージェントがタスクを完了できるか——上の2層は、Lighthouseの視野の外にある。当社がAIエージェント互換性診断で扱ってきたのは主にこの上位層で、両者は競合ではなくレイヤーの分担だと私たちは捉えている。 ## 監査「対象」と監査「実行者」——二層で進むエージェント化 最後に、少し引いた視点を置いておきたい。 Lighthouseの周辺では、もうひとつの動きが同時進行している。[Chrome DevToolsのエージェント連携機能](https://developer.chrome.com/docs/devtools/agents/use-cases/lighthouse-audit)により、コーディングエージェントがLighthouse監査（a11y、SEO、Best Practices、そしてAgentic Browsing）を自律的に実行し、結果を読んで修正コードを提案できるようになった。つまり—— **エージェントに読まれるためのWebを、エージェント自身が監査し、エージェント自身が直す。** 「監査対象としてのエージェント対応」と「監査実行者としてのエージェント」が、同じツールチェーンの中で噛み合い始めている。前例はある。Core Web Vitalsは2020年5月に発表され、[翌2021年6月から8月にかけて検索ランキングシグナルに段階的に反映](https://developers.google.com/search/blog/2021/04/more-details-page-experience)され、ほどなくWeb制作の発注要件にも入った。発表から業界の共通言語化まで、おおよそ1〜2年。Agentic Browsingが同じ経路をたどるかはまだ確定していない——スコアリング設計が示すとおり、Google自身が観測フェーズだと言っている。ただ、観測装置が全員の手元に配られたという事実だけは、もう確定している。物差しが配られたら、次に来るのは比較だ。 参考情報 - [Lighthouse agentic browsing scoring（Chrome for Developers）](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) - [Lighthouse changelog — 13.3.0（GoogleChrome/lighthouse）](https://github.com/GoogleChrome/lighthouse/blob/main/changelog.md) - [Registered WebMCP tools](https://developer.chrome.com/docs/lighthouse/agentic-browsing/registered-webmcp-tools) / [Forms missing declarative WebMCP](https://developer.chrome.com/docs/lighthouse/agentic-browsing/forms-missing-declarative-webmcp) / [WebMCP schema validity](https://developer.chrome.com/docs/lighthouse/agentic-browsing/webmcp-schema-validity) - [llms.txt audit（Chrome for Developers）](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) - [Google Says LLMs.Txt Comparable To Keywords Meta Tag（Search Engine Journal, 2025年4月）](https://www.searchenginejournal.com/google-says-llms-txt-comparable-to-keywords-meta-tag/544804/) - [Google Lighthouse Has A New Agentic Browsing Category（DebugBear）](https://www.debugbear.com/blog/lighthouse-agentic-browsing) - [SEO Audits with AI Agents — 実測レポート（seo-kreativ.de, 2026年6月）](https://www.seo-kreativ.de/en/blog/seo-audits-with-ai-agents-chrome-devtools-mcp/) - [Automate Lighthouse audits with AI agents（Chrome for Developers）](https://developer.chrome.com/docs/devtools/agents/use-cases/lighthouse-audit) - [WebMCP origin trial（Chrome Origin Trials）](https://developer.chrome.com/origintrials#/register_trial/4163014905550602241) --- ## 国産LLMの現在地　第4回：特化とエージェント適性 — ELYZA / cotomi v3 / Takane。「基盤を作らない」という戦い方 URL: https://www.untype.jp/blog/current-state-japanese-llm-specialization-agent-capability/ 公開日: 2026-07-02 カテゴリ: 国産LLM, ELYZA, cotomi, Takane, AIエージェント, MCP, RAG > ELYZA／cotomi v3／Takane。あえて「基盤を作らない」派生・特化型は何に賭けているのか。垂直特化の経済学と、評価軸が「賢さ」から「業務をやり切る力」へ移るエージェント適性の4要素を解説する連載第4回。 ## 参照情報 - [ELYZA LLM（ELYZA-Shortcut／Thinking のプロダクトページ・株式会社ELYZA）](https://elyza.ai/lp/elyza-llm) - [日本語拡散言語モデル「ELYZA-LLM-Diffusion」を公開（株式会社ELYZA／PR TIMES）](https://prtimes.jp/main/html/rd/p/000000066.000047565.html) - [ELYZA コーポレートサイト（LLMエージェント研究）](https://elyza.ai/) - [NEC、生成AI「cotomi」の性能強化でAIエージェントの活用を加速（NEC／PR TIMES）](https://prtimes.jp/main/html/rd/p/000000989.000078149.html) - [NEC開発のAIコア技術「cotomi」（NEC公式・製品ページ）](https://jpn.nec.com/LLM/cotomi.html) - [NEC、生成AI「cotomi」のエージェント性能強化を発表（クラウド Watch）](https://cloud.watch.impress.co.jp/docs/news/2029970.html) - [富士通、業務特化型LLM「Takane」を提供開始 Cohereと共同開発（日経クロステック）](https://xtech.nikkei.com/atcl/nxt/news/24/01571/) - [パブリックコメント業務に大規模言語モデル「Takane」を活用した実証実験（富士通）](https://global.fujitsu/ja-jp/pr/news/2026/02/03-01) - [AIの軽量化・省電力を実現する生成AI再構成技術を開発し、富士通の大規模言語モデル「Takane」を強化（富士通）](https://global.fujitsu/ja-jp/pr/news/2025/09/08-01) - [ガバメントAIで試用する国内大規模言語モデル（LLM）の公募結果（デジタル庁）](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e) - [ガバメントAIで使用する国産基盤モデルの公募について（予告）／選定7件・契約5社の根拠（デジタル庁）](https://www.digital.go.jp/news/207cadc2-c218-42f6-92ec-c0eda476b49c) - [デジタル庁、AI「源内」向け国産LLM再公募 有償の政府調達へ 評価テストは50問→300問に（ITmedia NEWS）](https://www.itmedia.co.jp/aiplus/article/2605/29/2000000036/) - [ELYZAとKDDIグループ、生成AIの社会実装に向け資本業務提携を締結（KDDI）](https://news.kddi.com/kddi/corporate/newsrelease/2024/03/18/7333.html) --- ## 国産LLMの現在地　第3回：フルスクラッチ主権型 — tsuzumi 2 / PLaMo / Sarashina。「自前」が効く二つの理由 URL: https://www.untype.jp/blog/current-state-japanese-llm-embedding-sovereignty-models/ 公開日: 2026-06-30 カテゴリ: 国産LLM, tsuzumi, PLaMo, Sarashina, データ主権 > tsuzumi 2／PLaMo／Sarashina。基盤モデルを自前で一から作る「フルスクラッチ主権型」は、なぜ性能で海外勢に及ばずとも選ばれるのか。オンプレのコスト逆転と学習データの法的クリーンさ、二つの実利を解説する連載第3回。 ## 参照情報 - [NTT版大規模言語モデル「tsuzumi 2」（NTT R&D）](https://www.rd.ntt/research/LLM_tsuzumi.html) - [更なる進化を遂げたNTT版LLM tsuzumi 2の提供開始（NTTニュースリリース／推論コスト試算の出典）](https://group.ntt/jp/newsrelease/2025/10/20/251020a.html) - [NTT版LLM tsuzumi 2アップデート（Visionモデル・2026年5月／NTTニュースリリース）](https://group.ntt/jp/newsrelease/2026/05/19/260519a.html) - [国産生成AI基盤モデルPLaMo 3.0 Primeを正式リリース（Preferred Networks）](https://www.preferred.jp/ja/news/pr20260622) - [PLaMo API 料金ページ（Preferred Networks／Standardプラン）](https://plamo.preferredai.jp/api) - [「Oracle Alloy」を採用した「Cloud PF Type A」で、国産LLM「Sarashina」を活用した生成AIサービスを2026年6月から順次提供（ソフトバンク）](https://www.softbank.jp/corp/news/press/sbkk/2026/20260416_02/) - [ガバメントAIで試用する国内大規模言語モデル（LLM）の公募結果（デジタル庁）](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e) - [デジタル庁、AI「源内」向け国産LLM再公募 有償の政府調達へ 評価テストは50問→300問に（ITmedia NEWS）](https://www.itmedia.co.jp/aiplus/article/2605/29/2000000036/) --- ## 国産LLMの現在地　第2回：国家戦略編 — 「源内」7モデル選定と2027年調達が、民需に効く理由 URL: https://www.untype.jp/blog/current-state-japanese-llm-gennai-strategy-procurement/ 公開日: 2026-06-29 カテゴリ: 国産LLM, 源内, ガバメントAI, ソブリンAI, ベンダーロックイン, tsuzumi, PLaMo > デジタル庁の生成AI基盤「源内」が国産LLMを選定。なぜ「愛国」でも「性能」でもないのか。政府調達が中小企業のモデル選定にまで効く3つの経路と、2027年度の本格調達スケジュールを読み解く連載第2回。 ## 参照情報 - [ガバメントAIで試用する国内大規模言語モデル（LLM）の公募結果（デジタル庁）](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e) - [ガバメントAIで使用する国産基盤モデルの公募について（予告）（デジタル庁）](https://www.digital.go.jp/news/207cadc2-c218-42f6-92ec-c0eda476b49c) - [（同・別紙）令和8年度に「源内」で評価検証を行う企業一覧＝契約締結済5社（デジタル庁・PDF）](https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/207cadc2-c218-42f6-92ec-c0eda476b49c/0d5db10f/20260529_news_genai_outline_01.pdf) - [ガバメントAI「源内」政策ページ（デジタル庁）](https://www.digital.go.jp/policies/genai) - [ガバメントAI「源内」をオープンソースソフトウェアとして公開しました（デジタル庁）](https://www.digital.go.jp/news/907c8e5d-2f4f-4bd7-9400-37c9f4221d7d) - [源内 OSS リポジトリ genai-web（GitHub／digital-go-jp）](https://github.com/digital-go-jp/genai-web) - [源内 OSS リポジトリ genai-ai-api（GitHub／digital-go-jp）](https://github.com/digital-go-jp/genai-ai-api) - [人工知能基本計画（令和7年12月23日 閣議決定）（内閣府）](https://www8.cao.go.jp/cstp/ai/ai_plan/ai_plan.html) - [パブリックコメント業務に大規模言語モデル「Takane」を活用した実証実験（富士通）](https://global.fujitsu/ja-jp/pr/news/2026/02/03-01) - [デジタル庁、政府AI用の国産LLM7モデルを選定 18万人の政府職員で大規模実証（Advertimes）](https://www.advertimes.com/20260312/article536930/) - [NTT版大規模言語モデル「tsuzumi 2」（NTT R&D）](https://www.rd.ntt/research/LLM_tsuzumi.html) --- ## 国産LLMの現在地　第1回：二層構造の地図 — 「海外3強の代替」という問いが、答えを取り違えさせる URL: https://www.untype.jp/blog/current-state-japanese-llm-two-layer-map-alternatives/ 公開日: 2026-06-26 カテゴリ: 国産LLM, tsuzumi, PLaMo, Sakana AI, ELYZA, Nejumi, データ主権, ソブリンAI, ベンダーロックイン > 「国産LLMは海外3強に追いついたか」という問いは、実は答えを取り違えさせている。汎用性能と主権・特化の二軸で地図を描き、国産AIの現在地と「高性能×高主権」という空白地帯を読み解く連載第1回。 「国産LLMは、ChatGPTやClaudeやGeminiに追いついたのか」。国産モデルの話になると、ほぼ必ずこの問いが出る。そして、この問いに正直に答えると「いいえ」になる。 だが——問いの立て方そのものが、答えを取り違えさせている。今日はその話をしたい。 ## ベンチマークは残酷だ。だが、それは一面にすぎない 最も客観性の高い日本語総合ベンチマークのひとつ [Nejumi Leaderboard 4](https://nejumi.ai/) の2026年3月版では、首位から順に Gemini 3.1 Pro（0.8430）、Claude Opus 4.6（0.8394）、GPT-5.2（0.8285）。総合スコア0.80を超えた11モデルの上位は、海外3強と中国系のオープンモデルが占めた。そして同版の総合トップ50には、国産モデルは1つも入っていない。 数字だけを見れば、勝負はついている。汎用的な賢さを基準に国産を選ぶ理由は、いまのところ見当たらない。 ところが、同じデータをもう一段細かく見ると、景色が変わる。日本語の指示追従を測る JFBench では、Preferred Networksの[PLaMo 2.2 Prime（310億パラメータ）が GPT-5.1 と同等のスコア](https://tech.preferred.jp/ja/blog/plamo-2-2-prime-release/)を出している。パラメータ数で10倍以上小さいモデルが、特定の日本語タスクではフロンティアに並ぶ。なお同社は2026年6月22日に最新版[PLaMo 3.0 Prime](https://www.preferred.jp/ja/news/pr20260622)を正式リリースし、推論／非推論の2系統とコンテキスト長256Kへの拡張で実用性をさらに高めている（詳細は第3回で扱う）。 **「総合では負ける。特定の仕事では伍する」**——これが国産の現在地だ。 そして、この一文が出てきた時点で、最初の問いはもう壊れている。「追いついたか／代替できるか」は、性能という一本の物差しだけで世界を測る問いだった。だが、企業がAIを選ぶとき、物差しは一本ではない。 ## 「代替できるか」ではなく「どの軸で見るか」 企業がモデルを選ぶ物差しは、少なくとももう一本ある。データを国内・自社に閉じられるか、業界特化が効くか、オンプレで安く回せるか、そして特定ベンダーが使えなくなっても代替が利くか——まとめて「主権・特化」の軸だ。 この二本の軸で地図を描くと、現在地がはっきり見える。 ```svg 国産LLMと海外3大プラットフォーマーのポジショニングマップ 横軸は汎用ベンチマーク性能、縦軸はデータ主権・国内特化・オンプレ適性。海外3強は右下（高性能・低主権）、フルスクラッチ主権型・派生特化型・束ねる型の国産勢は上側（高主権）に位置する。右上の高性能×高主権の象限は空白。 汎用性能では海外3強、「主権」の軸では国産が優位 2軸で見る、国産LLMと海外3大プラットフォーマーの位置（2026年6月時点の概念図） 国産が強い領域 空白地帯 高性能 × 高主権 低 高 汎用フロンティア性能 高 低 データ主権・国内特化・オンプレ適性 フルスクラッチ主権型 tsuzumi / PLaMo / Sarashina 束ねる型 Sakana Fugu 派生・特化型 ELYZA / cotomi v3 / Takane 海外3強 GPT / Claude / Gemini ※ 位置関係は概念図（2026年6月時点）。縦軸＝データ主権・国内特化・オンプレ適性、横軸＝汎用日本語ベンチマーク性能。 ※ 右上（高性能×高主権）は世界的に空白。国産各社はこの空白地帯を異なる戦略で狙っている。 ``` 横軸は汎用フロンティア性能。縦軸は「主権・特化」だ。海外3強は右側（高性能）にいるが、縦軸では中央より下にいる。理由は後述するが、ひとことで言えば「最終的な統制権が自社・自国の側にない」からだ。一方、国産勢は左寄り（性能では劣る）だが、上側（主権では強い）に位置する。 ここで一番大事なのは、**右上——高性能かつ高主権——の象限が、いま世界中でほぼ空白だ**ということだ。この空白をめぐる競争こそが、いま起きていることの正体である。「3強の代替」ではなく「空白の奪い合い」。問いを組み替えると、国産勢の動きが急に意味を持って見えてくる。 ## 縦軸は、なぜ消えないのか 「性能はいずれ追いつく。だから縦軸の優位も一時的だろう」と思うかもしれない。実際、性能差は縮んでいる。だが縦軸——主権の軸——は、性能が追いついても消えない。理由は3つある。 **ひとつ、データの行き先。** 金融・医療・行政・防衛には、データを物理的に国外へ出せない、あるいは出したくない要件がある。[NTTのtsuzumi](https://www.rd.ntt/research/LLM_tsuzumi.html)が、他社モデルを種にせず完全に一から作る「フルスクラッチ・純国産」にこだわるのは、学習データの権利と法令遵守を自社で完全にコントロールするためだ。これは性能の話ではない。統制の話だ。性能で追いつかれても、統制の所在は動かない。 **ふたつ、コストの逆転。** エージェントが普及すると、API課金は「呼び出し回数」で膨らむ（この力学は別連載『AIエージェント構築、その前に』第1回で詳述した）。高頻度利用の企業では、3年程度でオンプレ運用のほうが安くなる逆転が起きる。tsuzumi 2が「GPU1基で動くこと」に執着するのは、この逆転点を企業の手元に引き寄せるためだ。安さは、性能とは別のダイヤルである。 **みっつ、可用性。** これは2026年6月、現実の事件として突きつけられた。6月12日、米政府の輸出管理指令を受けて、[AnthropicがClaude Fable 5・Mythos 5へのアクセスを全ユーザー向けに停止](https://www.itmedia.co.jp/news/articles/2606/13/news026.html)した。公開からわずか3日後の出来事で、復旧の時期も示されなかった。他のモデル（Opus 4.8など）は影響を受けなかったが、重要な業務を単一の海外ベンダーのAPIに預けることは、それ自体が可用性リスクになりうる——この事件が、国産を「保険」として見直す動きに火をつけた。 この3つ目は、本連載と別連載の接続点でもある。別連載『AIエージェント構築、その前に』では、エージェント内部でモデルをどう切り替え、どう縮退させるかという**技術的なフォールバック設計**を扱った。本連載が問うのは、その一段手前だ。そもそも切り替える先・降りる先に、国産LLMという選択肢は成立するのか。能力の段を下げる設計があっても、降りる先の床がなければ意味がない。その「床」を点検するのが、この連載である。 ## 国産勢は「3つの戦略」に分かれている 乱立して見える国産勢も、開発思想で割ると3つに整理できる。本連載は、この3分類を軸に各論を進める。 ```markdown-table | 戦略 | 代表モデル | 武器 | 扱う回 | |---|---|---|---| | フルスクラッチ主権型 | tsuzumi 2 / PLaMo / Sarashina | 純国産・オンプレ・学習データの法的クリーンさ | 第3回 | | 派生・特化型 | ELYZA / Takane / cotomi v3 | 垂直特化・エージェント適性（MCP準拠など） | 第4回 | | 束ねる型 | [Sakana AI](https://sakana.ai/series-b/)（Fugu） | 複数モデルを指揮するオーケストレーション | 第5回 | ``` フルスクラッチ主権型は、汎用基盤を自前で一から作り、主権とオンプレを売る。派生・特化型は、汎用基盤の開発を捨て、ベースモデル＋日本語追加学習＋ドメイン特化で勝負する。そして束ねる型は、自前の巨大モデルを作る競争から降り、既存モデルを組み合わせて指揮する——いわば「単独モデルの性能比較」という土俵そのものを外しにきた発想だ。3つは優劣ではなく、空白地帯への異なる攻め筋として読むのが正しい。 ただし、同じ「国産」でも主権の度合いは一様ではない。フルスクラッチ型は基盤モデルそのものを自社で握るのに対し、派生型は既存の基盤モデル——たとえばELYZAはMetaのLlama——の上に日本語を重ねる。土台が海外製である分、純粋なデータ主権という一点ではフルスクラッチ型に一歩譲る。先の図で派生・特化型をフルスクラッチ主権型よりやや下に置いたのは、この差を表している。 ## この連載が描く地図 全6回で、国産LLMの現在地を「総論→国家戦略→各論→実装」の順に降りていく。 1. **二層構造の地図**（本記事）— なぜ「代替できるか」という問いが間違っているのか 2. **国家戦略編** — デジタル庁[「源内」](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e)と2027年4月の本格調達。政府のお墨付きが民需に効く構造 3. **フルスクラッチ主権型** — tsuzumi 2 / PLaMo / Sarashina。オンプレTCOの逆転と法的クリーンさ 4. **特化とエージェント適性** — ELYZA / cotomi v3 / Takane。垂直特化の経済学とMCP準拠 5. **束ねる型** — Sakana AIとオーケストレーション。「第3の道」という思想 6. **実装編** — 自社のAIスタックに国産をどの層で組み込むか。主権リスクへの保険と、選定の判断軸 ## まとめ - 汎用ベンチでは海外3強が0.80超を独占し、国産はトップ50圏外。「代替できるか」だけを見れば、答えはもう出ている - だがそれは性能という一本の物差しの話にすぎない。企業の選定軸にはもう一本、主権・特化・コスト・可用性がある - 性能は追いつきうるが、主権の軸は「データの行き先」「コスト逆転」「可用性」の3つの理由で消えない - 国産は「海外3強の汎用代替」としてはまだ弱い。だが「主権の保険」「特化のメイン」としては、すでに実用段階に入っている - 問うべきは「追いついたか」ではなく「どの軸で、どの業務に、どう置くか」だ 国産LLMを「海外勢の劣化版」として眺めているうちは、この市場で起きていることは見えてこない。空白地帯の地図を手にして、はじめて各プレイヤーの動きが意味を持つ。次回は、その地図の上で最も大きく動いた一手——政府による国産LLMの選定を扱う。 参考情報 - [ガバメントAIで試用する国内大規模言語モデル（LLM）の公募結果（デジタル庁）](https://www.digital.go.jp/news/10d55c63-b3e1-42b9-9cc5-93a06943ae0e) - [Nejumi LLMリーダーボード（Weights & Biases Japan）](https://nejumi.ai/) - [PLaMo 2.2 Primeをリリースしました（Preferred Networks Tech Blog／JFBenchでGPT-5.1と比較）](https://tech.preferred.jp/ja/blog/plamo-2-2-prime-release/) - [国産生成AI基盤モデルPLaMo 3.0 Primeを正式リリース（Preferred Networks）](https://www.preferred.jp/ja/news/pr20260622) - [NTT版大規模言語モデル「tsuzumi 2」（NTT R&D）](https://www.rd.ntt/research/LLM_tsuzumi.html) - [「Claude Fable 5」「Mythos 5」全面停止 米政府の指令により Anthropicは早期復旧を宣言（ITmedia NEWS）](https://www.itmedia.co.jp/news/articles/2606/13/news026.html) - [Announcing Our Series B（Sakana AI）](https://sakana.ai/series-b/) --- ## 構造化データの引っ越し　第7回：外部報酬から内部報酬へ、そして「伝える」へ URL: https://www.untype.jp/blog/structured-data-migration-intrinsic-reward-communication/ 公開日: 2026-06-25 カテゴリ: 構造化データ, RAG, GEO, コミュニケーションデザイン > AIに見つけてもらう“外部報酬”は驚くほど不安定。手元で確定できる“内部報酬”と、構造化＝「伝える」という仕事へ。連載の終章で、AI時代のWebに本当に必要なことを問う。 前回の最後に、一つだけ宙に残した問いがある。構造化データが、検索順位を上げる魔法でも、AIに引用される保証でもないとしたら——相関は見えても因果は確かめられない、という現在地に立つのだとしたら——私たちは何を頼りに、この手間をかけるのか。 六回かけて、知る・読む・埋める、と歩いてきた。その足場の上で、最後にこの問いへ降りる。結論を先に言えば、頼るべきは「AIに見つけてもらう」という外からの見返りではない。もっと手前の、自分の手で確定できる何かだ。そしてそれは、構造化という技術の話を一周して、「伝える」という、ずっと古い仕事に戻っていく。 ## ここまでの道のり — 知る、読む、埋める 第1回で、私たちは「構造化データ」という一語をほどいた。考え方・語彙・記法・セマンティックHTML。地図を持たずに歩けば迷うだけだから、まず言葉を交通整理した。そして気づいたのは、その語彙も記法も、もともとすべて検索エンジンに読ませる前提で設計されていた、という事実だった。 第2回で、その前提が動いていることを、時間をさかのぼって確かめた。schema.org は2011年、検索結果をリッチに見せるために生まれた。だが2026年5月7日、FAQリッチリザルトの表示が完全に終わった。表示は消えたのに、マークアップは死んでいない——Google はページ理解に使い続け、AIクローラーは読み続けている。同じ数行のコードの「目的」だけが、検索エンジン向けからAI向けへ引っ越した。FAQPage は、その引っ越しを日付つきで記録した生き証人だった。 第3回と第4回は、抽象論を現物に着地させる回だった。自社サイト untype.jp の `` を開き、Organization から FAQPage まで一つずつ読んだ。土台は、よく整っていた。だが読めるようになると、そこに「無いもの」が見えた。サービスが——看板商品の互換性診断ですら——構造として書かれていない。AI可読性を売る会社の自社サイトで、肝心の売り物が機械に読めない。紺屋の白袴だ。第4回では、その空白を4つの層（情報設計・文書構造・マークアップ・能力）の地図に置き、それぞれが三つの職種の仕事であることを確かめた。地図を持つと、やらないことが決まる。 第5回で、その空白を実際に埋めた。サービスを `Service` に、価格は性質に応じて出し分け（受託は出さず、診断は出し、累進は単価で）、増えたノードはすべて `@id` で一つの会社ノードへ束ねた。連載のために作った架空の例ではなく、本当に自社のリポジトリで手を動かし、本番に出した記録だ。そして第6回では、その前向きな話を一度脇に置き、技術の効かない範囲を直視した。相関≠因果。構造化データ「だけ」では引用されない。嘘をつけてしまう危うさ、保守の負担、JavaScript で挿入すると多くのAIに届かないという罠。道具を正しく使うには、道具の効かない範囲を知らねばならない。 ここまでが、足場だ。そしてその足場の縁に、最初の問いが立っている。これだけの手間を、何のためにかけるのか。 ## 外部報酬は、他人の頻繁に変わる選択に乗ること いちばん素直な答えは、「AIに見つけてもらうため」だ。構造化すれば、ChatGPT や AI Overviews に引用され、そこから人が、あるいはエージェントがやってくる。その露出を見返りとして、手間をかける。これを外部報酬と呼ぶことにする。外から与えられる、見つけてもらうことの報酬だ。 問題は、この報酬が、驚くほど不安定なことだ。 AIがある問いに答えるとき、どのサイトを引用するかは、月どころか週の単位で入れ替わる。SEO分析企業 [SISTRIX が3つのプラットフォーム・6か国・82,619件の問いを17週間追った調査](https://www.sistrix.com/blog/ai-citation-drift-how-stable-are-sources-in-ai-search-results/)では、引用されるドメインが Google のAI Modeで毎週およそ56%、ChatGPT では74%も入れ替わっていた。ChatGPT にいたっては、17週間を通じて一度も欠けずに引用され続けたドメインが一つもない、という問いが半数以上を占めた。検索順位の変動とは、時間の桁が違う。検索なら、上位の同じURLが何か月も同じ問いを占め続けることが多い。引用は、そうではない。先週引用されていたページが、今週は跡形もなく消えうる。 なぜか。引用するかどうかを決めているのは、私たちのサイトではなく、AIの側の——生成のたびに計算し直される——選び方だからだ。第6回で見たとおり、その選び方の機構は公開されていない。先の調査でも、この入れ替わりは一時的な乱れではなく、三つのプラットフォームすべてに共通して現れる性質だった。つまり外部報酬とは、自分では中身を見られない他人の選択に、見返りを丸ごと預けることにほかならない。 これを認めると、構造化データを「引用されるため」にやる、という動機づけは、足元が砂になる。[第6回で見た Ahrefs の対照実験](https://ahrefs.com/blog/schema-ai-citations/)が示したように、引用されるページにスキーマが多い傾向はあっても、後から足して引用が有意に増えることはなかった——相関はあっても、後付けの因果は確かめられなかったのだ。仮に増えたとしても、その見返りは早ければ来週には引っ込みうる。外部報酬を当てにした投資は、相手の気まぐれに賭ける投資になりやすい。 ただし、誤解を避けたい。外部報酬を狙うのが愚かだ、という話ではない。引用も検索流入も、得られればありがたい。言いたいのは順番のことだ。不安定なものを土台に据えてはいけない。砂の上に、家の重心を置いてはいけない。 ## 内部報酬は、自分の手で確定できる では、何を土台に据えるか。外部報酬の対極にあるもの——内部報酬だ。 第5回の改修を思い出してほしい。私たちは「診断スコアが上がる」「引用が増える」とは約束しなかった。約束できたのは、ただ一つ、「機械が読める構造になった」という構造的事実だけだった。バリデータがその構文の正しさを裏づけ、自社の提供物が、推測の余地なく、正しい単位で存在するようになった。これは外部の反応を一切待たずに、その日のうちに手元で確定できた価値だ。 この「手元で確定できる」性質が効く場所が、すでに一つある。自社のRAGだ。第2回で触れたとおり、構造化データの引っ越し先は、検索エンジンでもAIサービスでもなく、自分たち自身の業務にもあった。整えられた構造は、自社のドキュメントをAIに読ませて答えさせるとき、推測を減らし、取り出しの精度を上げる。ここに、外部の選び方は介在しない。来月になっても引っ込まない。整えた構造は、整えた瞬間から、自分の手元で使える。 外部報酬と内部報酬の違いを、一言で言えばこうなる。外部報酬は「見つけてもらえたか」を他人が採点する。内部報酬は「正しく整っているか」を自分が確かめられる。前者の採点基準は毎週書き換わるが、後者は——本文と一致しているか、語彙は正しいか、参照は解決しているか——自分の側で完結する。第6回で「バリデータの緑は出発点であってゴールではない」と書いた。その緑が証明するのは構文の正しさだけだが、少なくともそれは、他人の気分では消えない確かさだ。 だから、この連載が最後に勧める動機づけは、こうだ。AIに見つけてもらうために構造化するのではない。いま、自分たちが正しく整っているために構造化する。見つけてもらえたら、それは果報として受け取ればいい。だが手間をかける理由は、もっと手前の、確定できる側に置く。砂ではなく、地面に。 ## 構造化とは、結局「伝える」という仕事だった ここで、視点をもう一段引きたい。 内部報酬のために「正しく整える」とは、突き詰めると何をしていることなのか。社名を確定値で渡し、サービスを独立した提供物として書き、価格を偽らず、本文とマークアップを一致させる——これらはすべて、「自分たちが何者で、何を、誰に提供しているのか」を、曖昧さなく差し出す作業だ。相手が推測しなくて済むように。取り違えなくて済むように。 それは、「伝える」という仕事の、別の名前ではないか。 「書く」と「伝える」は、似ているようで違う。書くは、書き手の側で完結する。書き終えた時点で仕事は終わる。伝えるは、相手に届いた時点で初めて完結する。視点が、内側からではなく、受け手の側に立つ。構造化データがやっているのは、明らかに後者だ。機械という受け手が、推測なしに受け取れる形まで面倒を見る——それは表現ではなく、到達への配慮である。 私の会社が「Web制作会社」という看板を下ろし、「コミュニケーションデザイン会社」を名乗り直したのは、ここに関わっている。コミュニケーションは、書き手の独白では成立しない。受け手との往復で初めて成り立つ。デザインとは、受け手の体験までを設計することだ。構造化データは、その受け手に「機械」が加わった時代の、伝えるための配慮の一つの形にすぎない。新しい技術の話に見えて、やっていることはずっと古い。 そして、ウェブが見えなくなるほど、この「伝える」の中身が剥き出しになる。AIが間に立ち、ページを要約して人に渡すようになると、多くの場合、装飾は要約で削られる。デザインの巧みさも、コピーの語感も、サイトの印象も、要約のなかではほとんど残らない。残るのは「何を伝えたか」、言葉の内容そのものだけだ。これは、表面で取り繕う余地が減るということであり、同時に、ちゃんと伝えた言葉はこれまで以上に正確に届く、ということでもある。構造化とは、その剥き出しになった中身を、機械にも誤読されない形で差し出す技術だ。 ## 〈伝える側の仕事に戻る〉 私はこの連載と並行して、一つの問いを保留にしていた。AI時代のウェブで、本当に必要なことは何か、という問いだ。構造化データを入れよう、schema.org に対応しよう、GEOだ、LLMOだと、新しい用語が次々に湧く。経営者にとっては、何から手をつけていいか分かりにくい状況だと思う。 六回を経たいま、その答えを書ける。**自分たちが何をやっている会社で、誰に何を届けているのかを、誠実に、ぼやかさず、ちゃんと伝わる形に整える。** これからのウェブで必要なことの大半は、それで済む。 派手な施策は要らない。難しい技術用語を追いかけ続ける必要もない。構造化データも、RAGの構築も、能力層への対応も、根っこにあるのは「自分たちのことを、世界に正しく伝わるように整える」という、ただ一つの仕事だ。整えれば、人間の顧客に届く。AIにも届く。社内のメンバーやRAGにも届く。これから登場する未知のエージェントにも届く。一本の柱から、すべてが派生している。 ここで順番が、もう一度効く。結果を先に追うと、テクニックに走る。流行りのキーワード、もっともらしい体裁、AIに媚びる書き方。これらは短期で効くこともあるが、長くは続かない。AIも検索エンジンも、年々「中身」を見るようになっているからだ。伝わる形に整えることを先に置けば、見つけてもらえるかどうかは、あとから付いてくる——あるいは、付いてこなくてもいい。整えたこと自体が、すでに内部報酬として手元に残っているのだから。 ウェブの仕事は、長いあいだ「書く」「見せる」の側に寄りがちだった。コピーを書く、デザインを見せる、施策を打つ。だがAIが受け手として加わり、装飾が要約で削られていく時代に、その重心は「伝える側」の地道な作業へと戻っていく。一周回って、ウェブがまだ装飾も検索もアプリもなかった頃の、伝えるための場所だった本質に、戻ってきている。 技術の話をしてきたつもりが、最後は伝えることの話になった。構造化データという連載の終わりが、ここに着地するのは、私には腑に落ちる。 ## 余韻 — 意味は、また引っ越すだろう 最後に、一筆だけ。 この連載の背骨は、「意味の引っ越し」だった。検索エンジンのために生まれた構造化データが、AIのための技術として読み直された。同じコードの、目的だけが移った。だがおそらく、引っ越すのは構造化データの意味だけではない。 いまAI向けに整えている構造も、数年後には、別の何かのための土台として読み直されているかもしれない。能力層のように、いまは標準すら固まっていない層が、主役になっているかもしれない。「伝える」という仕事の本質は変わらないとしても、その仕事を載せる技術の意味は、また静かに引っ越していくのだろう。構造化データは、その「意味は時代とともに引っ越す」という現象の、たまたま私たちが居合わせた一例にすぎないのかもしれない。 ## 結び — 急いで結論を出さない 七回を通じて、私は何度も「ただし」と書いてきた。スキーマを足せば引用される、とは書かなかった。診断スコアが上がる、とも約束しなかった。言えたのは、機械が読める構造になった、という構造的事実と、それが自分の手元で確かめられる、という確かさだけだった。 これは、結論を出し惜しんでいるのではない。いまの時点で誠実に言えることが、そこまでだ、というだけのことだ。相関は見える。因果は、まだ確かめられていない。外部報酬は不安定で、内部報酬は確かだ。そして「伝える」という古い仕事が、いっそう効くようになっている。ここまでは、自社の現物で確かめた。その先——構造化が長期にどんな見返りを生むのか、意味が次にどこへ引っ越すのか——は、急いで答えを出すより、手を動かしながら観察を続けたい。 untype.jp の `` は、これからも書き換わっていく。私たちはそれを、定点として読み続ける。意味が、次にどこへ引っ越すのかを見届けるために。 参照情報 - [AI Citation drift: How stable are sources in AI search results?（SISTRIX）](https://www.sistrix.com/blog/ai-citation-drift-how-stable-are-sources-in-ai-search-results/) — 3プラットフォーム・6か国・82,619プロンプトを17週間追跡。引用ソースの週次入れ替わりが Google で約56%、ChatGPT で約74%にのぼると報告。 - [We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.（Ahrefs, 2026-05-11）](https://ahrefs.com/blog/schema-ai-citations/) — JSON-LDを追加した1,885ページを4,000の対照ページと比較（差分の差分法）。Google AI Mode +2.4%・ChatGPT +2.2%（いずれも誤差範囲）、AI Overviews −4.6%。後付けのスキーマでは引用は有意に増えないと結論。 - FAQリッチリザルト廃止（2026年5月7日）の一次ソースは [Google 検索セントラル「FAQ（FAQPage, Question, Answer）structured data」](https://developers.google.com/search/docs/appearance/structured-data/faqpage)（連載第2回・第3回と同じ出典）。 - その他の技術面の一次ソース（schema.org 公式、Google 検索セントラル、Vercel・MERJ の検証、validator.schema.org など）は、本連載 第1回〜第6回の各「参照情報」を参照。 --- ## 構造化データの引っ越し　第6回：メリット・デメリットと技術ハードルを正直に URL: https://www.untype.jp/blog/structured-data-migration-benefits-challenges-technical-barr/ 公開日: 2026-06-24 カテゴリ: 構造化データ, Schema.org, JSON-LD > 構造化データとAI引用は相関であって因果ではない——Ahrefsの対照実験で検証。嘘をつくマークアップ、保守負担、JS挿入の罠まで、メリットとコストを正直に並べる連載第6回。 ## 参照情報 - [Google 検索セントラル「一般的な構造化データのガイドライン」（品質ガイドライン・手動対策・「正しくても表示は保証されない」）](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) - [Google 検索セントラル「FAQ（FAQPage）構造化データ」（リッチリザルト廃止と、構造化データ手動対策の記載）](https://developers.google.com/search/docs/appearance/structured-data/faqpage) - [Schema Markup Validator（validator.schema.org）](https://validator.schema.org/) - [schema.org（公式）](https://schema.org/) - [Ahrefs「We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved.」（スキーマ追加とAI引用の対照実験、2026）](https://ahrefs.com/blog/schema-ai-citations/) - [Search Engine Journal「Server-Side vs. Client-Side Rendering: What Google Recommends」（Gemini が Googlebot の WRS で JS をレンダリングする旨の Martin Splitt 発言）](https://www.searchenginejournal.com/server-side-vs-client-side-rendering-what-google-recommends/545946/) - [Google 検索セントラル「AI features and your website」（AI機能向けに特別なschema.orgマークアップは不要との明記）](https://developers.google.com/search/docs/appearance/ai-features) - [Vercel「The rise of the AI crawler」（MERJと共同。主要AIクローラーはJSをレンダリングしないとの観測）](https://vercel.com/blog/the-rise-of-the-ai-crawler) --- ## 構造化データの引っ越し　第5回：空いていた層を埋める — 自社サイト改修ドキュメンタリー URL: https://www.untype.jp/blog/structured-data-migration-application-layer-gap/ 公開日: 2026-06-22 カテゴリ: 構造化データ, Schema.org, JSON-LD > 自社サイトに欠けていたサービス構造を実際に実装した記録。Service/Offer/OfferCatalogの選定、価格の構造化（受託は出さず・診断は単価で）、@idでの接続まで。連載第5回。 ## 参照情報 - [schema.org: Service](https://schema.org/Service) - [schema.org: Offer](https://schema.org/Offer) - [schema.org: OfferCatalog](https://schema.org/OfferCatalog) - [schema.org: UnitPriceSpecification](https://schema.org/UnitPriceSpecification) - [schema.org: ProfessionalService](https://schema.org/ProfessionalService) - [Schema Markup Validator（validator.schema.org）](https://validator.schema.org/) - [Google 検索セントラル「FAQ（FAQPage）構造化データ」（リッチリザルト廃止と、ページ理解への継続利用）](https://developers.google.com/search/docs/appearance/structured-data/faqpage) - [AIは会社をどう知っているか（unType）](https://www.untype.jp/blog/ai-knows-your-company) - [AIエージェントがあなたの会社と取引する日（unType）](https://www.untype.jp/blog/a2a-agent-shopping) --- ## 構造化データの引っ越し　第4回：構造の地図 — 4つの層と、3つの職種 URL: https://www.untype.jp/blog/structured-data-migration-mapping-layers-roles/ 公開日: 2026-06-19 カテゴリ: 構造化データ, 情報設計, セマンティックHTML, llms.txt, WebMCP, NLWeb > 構造化データは単層ではない。情報設計・文書構造・マークアップ・能力の4層と、それを担う3職種で捉え直す。“地図を持つと改修の優先順位が決まる”。連載第4回。 前回、私たちは untype.jp の `` を開き、Organization や BlogPosting といったノードを一つずつ読んだ。そして最後に、そこに「無いもの」——構造化されていない自社サービス——を見つけた。 では、その「空白」は、いったい何の空白だったのか。それを言い当てるには、もう一段高いところから全体を見渡す地図がいる。今回は、構造化データを「4つの層」として捉え直す。前回までの「ノードを読む」目線を、いったん「地層を眺める」目線に切り替える回だ。 ## 第1回の「4分類」とは別の切り口だ 最初に、混乱を避けるための断りを置く。第1回でも「4つ」を出した——考え方・語彙・記法・セマンティックHTML、という分類だ。今回も「4つの層」を出すが、これは別の切り口である。 第1回の4分類は、「構造化データという言葉が指しているものを腑分けする」ための整理だった。いわば辞書の話だ。対して今回の4層は、「サイトを機械可読にするとき、実装はどんな地層からできているか」という地図である。同じ対象を、横に分類するか、縦に積み上げて見るかの違いだと思ってほしい。一対一で対応するものではないので、対応表を探さなくていい。 ## なぜ「層」で考えるのか 構造化データの話は、放っておくと「どの schema.org の型を使うか」「JSON-LD をどこに置くか」という記法の話に縮こまる。だが前回見たとおり、自社サイトの本当の問題は「サービスが構造化されていない」ことだった。これは記法の問題だろうか。違う。そもそも「このページに何の情報を、どんな単位で載せるか」という、もっと手前の設計の問題だ。 記法だけを見ていると、この手前が見えない。だから層で考える。下から順に、情報設計があり、その上に文書の骨格があり、その上に意味のマークアップが乗り、さらにその周りに「サイトが何をできるか」という新しい層が育ちつつある。順に降りて、そして昇っていく。 ```svg 何を意味するか 何ができるか マークアップ層 schema.org / JSON-LD 文書構造層 セマンティックHTML 情報設計層 何を・どんな単位で載せるか（土台） 下から積み上がる 能力層 llms.txt / WebMCP / NLWeb .well-known（発見の枠） ``` **図：構造化データの4層。**情報設計層を土台に、文書構造層・マークアップ層が下から積み上がる3層が「サイトが何を*意味する*か」を機械に伝える。その隣に立つ能力層（破線＝新興・流動的）は「サイトが何を*できる*か」をエージェントに渡す層で、標準はまだ固まっていない。各層が誰の仕事かは、後掲の職種表に対応する。 ## マークアップ層 — 私たちが読んできた層 いちばん上、というより、ここまでの3回で私たちがずっと見ていたのが、このマークアップ層だ。schema.org の語彙を JSON-LD で書き、「これは Organization だ」「これは BlogPosting だ」と機械に意味を渡す。第3回で読んだノードは、すべてこの層の住人だった。 世間で「構造化データ」と言うとき、多くはこの層だけを指している。だが、この層は単独で立っているわけではない。下に土台がある。 ## 文書構造層 — 骨格に意味を与える マークアップ層のすぐ下が、文書構造層だ。第1回で触れたセマンティックHTML——`
`、`