もう入っている Chrome を、そのまま触らせる Chrome DevTools MCP は、いま普段使っている Chrome をそのまま使います。自動化用のブラウザを別に落とす手順が要らないので、入れるのはコマンド1本です。動かしてみると立ち上がってくるのは見慣れた Chrome とほぼ同じ画面で、そこの安心感が大きかったですね。 そうなると素朴な問いが1つ残ります。ブラウザも触らせたいけど、ログインが要る画面はどうするのか。先に環境を作って、そこから順に書きます。 先に1つだけ前提があります。 Node.js が入っていること です。この後のコマンドで使う npx は Node.js に同梱されているので、まっさらな Windows では叩けません。確かめたのは v22.15.0 です。 Node.js の入れ方そのものはこの記事では扱いません。普段から開発している人なら手癖で終わる話ですし、そうでない人は Claude に「Windows に Node.js を入れたい」と聞けば、いまの環境に合った手順を出してくれます。ここに書いてもすぐ古くなるところなので、そちらに任せます。 入れ方そのものに新しいところは何もないので、 公式の Get started も並べておきます。Gemini CLI や Codex、JSON で設定を書く形はそちらにまとまっています。Claude Code についてはプラグイン経由の入れ方（ /plugin marketplace add ChromeDevTools/chrome-devtools-mcp → /plugin install chrome-devtools-mcp@chrome-devtools-plugins ）も案内されていて、そちらは MCP に加えて Skills も一緒に入ります。この記事は素の MCP 登録だけで進めます。 龍ちゃん 特別な事情がない方は！Skillsも一緒に入れておいたほうがいいから公式を見ようね！ この前提を踏まえて、入れるのはコマンド1本です。 claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest これだけです。オプションは1つも要りません。打ったディレクトリ限定で登録されるので、どこでも使いたいなら --scope user を足します。 追加したら Claude Code のセッションを一度開き直します。開き直さないとツールが生えません。入っているかはこれで見えます。 $ claude mcp list Checking MCP server health… chrome-devtools: npx -y chrome-devtools-mcp@latest --user-data-dir=C:\Users\<ユーザー名>\.chrome-automation-profile --viewport=1400x900 --screenshot-format=webp --screenshot-quality=70 --screenshot-max-width=1400 - ✔ Connected 僕の環境はオプションを足しているので長いですが、素の登録ならもっと短く出ます。見るのは末尾の ✔ Connected だけです。ただしこれで分かるのはサーバーの疎通までで、実際に動くかは1回 list_pages を呼ばせるまで分かりません（この話は最後にもう一度出てきます）。 今回は Windows で完結させています。WSL2 や devcontainer からホストの Chrome を叩く構成は扱いません。 入ったので、何が取れるのかを先に見ておきます。自分のブログの公開ページを開いて、構造をテキストで取ってみます。 navigate_page(pageId=1, type="url", url="https://<自社ブログ>/") → Successfully navigated to https://<自社ブログ>/. ## Pages 1: SIOS Tech Lab - エンジニアのためになる技術トピックス (https://<自社ブログ>/) [selected] take_snapshot を呼ぶと、ページの構造がテキストで返ってきます。要素に番号（uid）が振られているので、座標を推定しなくても操作できるんですよね。 uid=1_0 RootWebArea "SIOS Tech Lab - エンジニアのためになる技術トピックス" url="https://<自社ブログ>/" uid=1_1 banner uid=1_218 StaticText "© 2026 SIOS Tech Lab All rights reserved." 使い分けは1行で足ります。操作するためならスナップショット、人に見せる・見た目を判断するためならスクリーンショットです。 ブラウザ操作なら、だいたい一通りできる ここまでスナップショットとスクリーンショットしか出していませんが、道具はもっとあります。公式の ツール一覧 を数えると、2026年9月の時点で57個ありました。 ブラウザ操作に関わることなら、だいたい一通りできる と思っていいです。 まずユーザー操作のほう。クリック、テキスト入力、フォームの一括入力、ドラッグ、ファイルのアップロード、キーの送信、ダイアログの応答。タブの開閉と切り替え、画面サイズやデバイスのエミュレーションもあります。人が画面でやっていることは、だいたい指示に置き換わります。 うれしいのはここからです。F12 で開く開発者ツールのタブで見ていたものは、だいたいそのまま取れます。ネットワークのリクエスト一覧とヘッダ（Cookie も入ります）、パフォーマンスのトレースから Core Web Vitals（LCP・INP・CLS）、コンソールのメッセージ。画面の見た目ではなく数字が返るので、そのまま AI に読ませて判断させられるんですよね。 いま議論中の話も1つおまけで書いておきます。ヘッド付きの Chrome を触らせても、OS のマウスカーソルは動きません。入力は CDP のレイヤで注入されるので、隣で見ている人にはエージェントがどこをクリックしたのか分からないんですよね。そこで「ゴーストカーソルを重ねて見せる」 提案 が上がっていて、実装まで済んだ PR も1本ありましたが、ページに DOM を挿し込む形は避けたいというメンテナのコメントが付いて、いまは意見を集めている段階です（2026-09-07 に確認）。この辺はすぐ動くので、気になる人は issue を直接見てください。 動くのは、普段使いとは別のプロファイル オプション無しで動くのは、chrome-devtools-mcp が自前の場所に専用のプロファイルを作ってくれるからです。これは試してみるとわかりますが、Chrome 136 以降、既定のプロファイルのままだとリモートデバッグの指定が無視されるんですよね。理由は 公式のリンク で。 要するに 普段使いの Chrome とは別のプロファイルで動く 、という前提が最初から満たされているわけです。 置き場所を自分で決めたいときだけ、 --user-data-dir で渡します。僕がそうしているのは、後から中を見られるようにしておきたかったからです。ほかにも画面サイズやスクリーンショットの形式を指定するオプションがありますが、最初は1つも要りません。要るようになったら 公式のオプション一覧 で必要なものだけ拾ってください。 専用のプロファイルには、本物のログイン状態がそのまま乗ります。フォルダごと別の PC にコピーしても、そのままでは使えない作りになっています（ここは自分では試していません）。ただこれを「安全」とは読まないでほしくて、守れているのは持ち出しだけで、同じ PC の中からは触れてしまうんですよね。だから普段使いのプロファイルと分かれているのは、動かすための条件であると同時に、被害を閉じ込める線でもあるんだと思っています。 ログイン画面に来たら、エージェントはどうするのか ここからが本題です。僕の前提は1つで、 ID とパスワードはエージェントに渡しません 。認証が要る画面を触らせたいときも、そこだけは人が打つ。その前提で指示を先に書いておきます。 実際に投げたプロンプトの末尾がこれです。 前提: ログインは人がやる — 認証画面が出たら止まって依頼する。 そう書いておくと、エージェントは認証フォームを見つけた時点で入力を試さずに止まります。止まったときの出力がこれです。 ここで止まります。**手動ログインをお願いします。** ブラウザは `<自社ブログ>/wp-login.php` を開いた状態です（`pageId=1`、入力前の1枚は取得済み）。 お願いしたいこと: 1. その Chrome ウィンドウで**ログインしてください**（ID/パスワードは私は一切触りません） 2. ⚠ ログイン後、**管理画面のまま置いておいて構いません** — 私は管理画面をスナップショットも スクショもせず、公開ページへ直接 navigate して戻します 3. 終わったら「**終わった**」と言ってください。それを合図に再開します 止まり方として効いているのは3つあると思っていて。頼みごとが1つに絞られていること（ログインして、だけ。他の判断を人に投げていない）、やらないことを明言していること（ID・パスワードには触らない、管理画面は撮らない）、再開の合図を先に決めていること（人が次に何を言えばいいか迷わない）です。 ただしこれは規約であって、強制ではありません。フォームに入力するツール自体は生きているので、絶対に触らせたくないなら、ツールの許可設定の側で落とすことになります。 画面はこれ1枚だけで、空欄のフォームです。エージェントはここに一度も触っていません。 人が返した合図は「ログインした」でした。依頼したのは「終わった」だったんですけど、今回はこれでも再開できています。 再開の1手目は list_pages にします。これも指示に先に書いておく一行です。ブラウザを開き直すと番号が振り直されることがあって、そのときは MCP 自身が「再起動されたので番号が変わった」と教えてくれます。古い番号のまま呼ぶと失敗するので、1手目は取り直しにしておくと安全なんですよね。 ついでに、採番の確認はそのまま「いま何が開いているか」の確認にもなります。 list_pages() → ## Pages 1: ダッシュボード ‹ SIOS Tech Lab — WordPress (https://<自社ブログ>/wp-admin/) [selected] ログインすると管理画面に入れます。ただ今回は中を見ていなくて、タイトル行がテキストで出ているだけで、そのまま公開ページへ戻しました。 戻した先で撮ったのがこれです。さっきと同じ URL、同じ位置で、上端に管理バーが増えているだけです。 これで受け渡しが成立しています。人が担ったのはログインだけで、その前後はエージェントが動いているんですよね。 ひとつ気をつけどころがあります。認証の先へ入るということは、 そこから先はログインした人の権限で動く ということです。読める範囲も押せるボタンも、認証した自分と同じになります。ID とパスワードを渡していないことと、任せた範囲が狭いことは別なので、管理者のアカウントで入るのか、要る権限だけのアカウントで入るのかは、触らせる前に決めておいたほうがいいです。 なお、ここで書いているのは自分たちのサイトでの話です。他社のサービスを自動で操作させてよいかは規約の話が別に要るので、この記事では扱いません。 毎回ログインし直すことになるの？ プロファイルに何が乗るのか、認証を誰が担うのか。ここまでの2つは、最後に1つの問いでつながります。ログインした状態は、どこまで残るのか。ここは層が2つあるので分けて書きます。 1つは、プロファイルに乗る Google アカウントのサインインです。こちらは残っていて、閉じて開き直しても入ったままでした。確かめたのは約8分後、約28時間後、いちばん長いところで約6日2時間後です。 もう1つは、そのサイトが自前で持っているセッションです。今回の自社ブログはこちら側で、ブラウザを閉じたらログインし直しになりました。ウィンドウを普通に閉じて（強制終了はしていません）、約25秒後に開き直しても、管理バーは消えていました。 なぜ残るのか、なぜ残らないのかは追っていません。ログイン状態がどこに保存されるかで変わるところなので、どちらも振る舞いだけ書いています。 残らないなら残るようにしたい、と思うところですが、サイト側の認証情報を自分で取り出して保存する方向へは行っていません。保存した時点でそれが流出の対象になりますし、次からは人が一度も通らずに入れてしまうからです。最後の防壁となる人間の手作業が、丸ごと無くなるんですよね。動かしているあいだはブラウザを見ておいて、挙動に違和感があったり、なんかヤバいなと思ったらパスワードを変える、くらいは構えておくといいと思います。 ただ、Google のサインインだけは自分で保存しなくても残ります。人が毎回通るのはサイト側のログインのほうだけで、そのプロファイルは Google に入れる状態のまま置いてある、と思っておいたほうがいいです。 大事なのは、残らなくても認証の切り分けは成立しているということです。見返りは「次から要らなくなる」ではなく、今この1回、人が触るのはログインだけで済むということなんですよね。 じゃあ次は何を渡せるのか 冒頭の問いを回収すると、ログインが要る画面はどうするのか、答えは人が1回入って、その先を渡す、です。 渡せる仕事はまだあります。 list_network_requests で通信を、 list_console_messages でコンソールを取れるので、「この画面のここが遅い」「エラーが出ていないか」をそのまま調べさせられるんですよね。 ここで使い分けを1つ。開発の現場では、僕は Playwright のほうを使っています。テストを書く場所ですし、同じ手順を何度も回すならコードで持っておくほうが確実なので。入口は Playwright MCP で始めるブラウザ自動化 に書きました。Chrome DevTools MCP が効くのは、日常のちょっとした動作を1回やらせたいときです。わざわざ環境を作るほどではない、でも手でやるのは面倒、くらいの仕事ですね。正直、Windows に Playwright の環境を入れるのが面倒でずっと手が止まっていた、というのも僕の側の事情としてはあります。 反復するならやはり Playwright を書いたほうがいいです。楽なのは着手であって、運用ではないので。 最初の一歩は1つだけです。 claude mcp add を1本打って、「自分のブログのトップを開いて、構造を取ってみて」と頼んでみる。テキストが返ってきたら、そこから先は渡せます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Chrome DevTools MCP を Windows に入れる。ログインだけ人がやる first appeared on SIOS Tech Lab .

はじめに こんにちは、検索基盤部 検索グロースブロックの 朝原 です。普段はZOZOTOWNの検索体験の改善を担当しています。2026年6月29日から7月2日までサンフランシスコで開催されたAI Engineer World's Fair 2026に現地参加しました。本記事では、現地の様子に加えて、特に気になったセッションをSoftware FactoriesとAgentic Commerceの2つのテーマに分けて紹介します。 目次 はじめに 目次 AI Engineer World's Fair 2026とは 現地の様子 ノベルティ Expoエリア サイドイベント セッションレポート Software Factories Better Loops & Orchestrating Agents 所感 Self-Improving Software Factories 所感 Don't Ship Skills Without Evals 所感 Agentic Commerce Designing Multimodal Collaborative Agents for Next-Gen Commerce 所感 When AI Agents Pay and Sellers Monetize: Building x402 Apps for Agentic Commerce on AWS 所感 まとめ AI Engineer World's Fair 2026とは AI Engineer World's Fairは、サンフランシスコで開催されるAIエンジニア向けカンファレンスです。公式サイトによると今年は4日間の開催で、6000人以上の参加者と300人のスピーカーが集まりました。 www.ai.engineer 開催テーマにはSoftware Factories、Autoresearch、Harness Engineeringが掲げられていました。私が聴講した発表では、エージェントを単発の便利ツールとして使うのではなく、継続的に動かす仕組みを扱うものが目立ちました。 現地の様子 サンフランシスコの朝はたいてい曇っていましたが、時間が経つにつれて晴れてくる日が多く、過ごしやすい気候でした。 会場のMoscone Westの入口には、「Engineering the future of AI」というスローガンが大きく掲げられていました。 ノベルティ 受付では、ネームプレートやトートバッグなどのノベルティが配布されました。ネームプレートには名前と所属、職種が記載されていたため、会場内でも似たバックグラウンドの方に話しかけやすかったです。 トートバッグには、サンフランシスコの街並みと「AE」の文字を組み合わせたピクセルアートがあしらわれていました。 ユニークだったのが「AGI PILLS」と書かれたサプリメント風のノベルティです。飲めば知能がアップグレードされるという設定のジョークグッズで、AIカンファレンスらしい遊び心を感じました。 Expoエリア 会場のExpoエリアでは、各社がブースを構えて自社のサービスやプロダクトを紹介していました。実際にデモを試しながら説明を聞けるため、各社がエージェント開発のどこに課題意識を持っているのかを知ることができました。MicrosoftやOpenAIのブースには常に人だかりができていました。 ユニークな展示も多く、Bright Data社のブースでは来場者がロボットを操縦して対戦する企画が人気を集めていました。 サイドイベント カンファレンスの前後や夜には、協賛企業や団体が主催するサイドイベントも数多く開催されていました。私もいくつかのイベントに参加し、世界中から集まったAIエンジニアたちと直接話すことができました。 美術館を会場にしたサイドイベントでは、アート作品に囲まれながらの交流という貴重な体験ができました。 Cloudflareがカフェを貸し切って開催したカジュアルなイベントもあり、コーヒー片手にゆったりと話せる雰囲気でした。 セッションレポート 会場では、キーノート、テーマ別の講演、ワークショップが複数のトラックで並行開催されていました。 ここからは、5つのセッションをテーマごとに紹介します。 Software Factories Software Factoriesは今年の開催テーマのひとつで、専用のトラックも用意されていました。各発表において、Software Factoryは、「AIが開発工程を継続的に実行し、人間は要所で判断しながらAIを動かす仕組みを設計・改善する開発モデル」として説明されていました。 この工場が担うのはコードを書く工程だけではなく、ユーザーフィードバックやログといったシグナルの収集から、優先順位付け、実装、検証まで、ソフトウェア開発のライフサイクル全体を自律的に回すことです。 ここでは、人間とエージェントの役割分担を見直すオーケストレーション、開発フロー全体の自動化の実践、エージェントに渡すスキルの品質管理という順で3つのセッションを紹介します。 Better Loops & Orchestrating Agents OpenClawの開発者で、2026年にOpenAIへ入社したPeter Steinbergerさんの発表です。 Steinbergerさんは、現在のコーディングエージェントの運用では、人間がタスクの采配と確認を担うことが多いと指摘していました。人間がタスクを切り出してエージェントに依頼し、出力を待ち、レビューして修正を頼みます。このようにタスクを采配する役割はOrchestratorと呼ばれ、人間がOrchestratorである限り、エージェントの数をいくら増やしても人間の確認速度が全体の上限になります。これまではモデルの性能の問題もあり、エージェントが意図しない行動をしたら人間が止めて指示し直す、という使い方をしてきました。しかしモデルが優秀になってきた今、「エージェントがコードを生成する画面をただ眺めているのはもったいない」とSteinbergerさんは指摘していました。 人間がOrchestratorを担う、これまでの構成 / Better Loops & Orchestrating Agents — Peter Steinberger, OpenAI 49:06より引用 そこで提案されたのが、Orchestratorを人間からエージェントに引き渡す構成です。Managerエージェントが「プロジェクトの目標」「メモ」「将来のビジョン」をもとにタスクを切り出し、Workerエージェントを作ります。Workerが調査・実装・テストを進め、Reviewerエージェントが結果を確認します。タスクの切り出しから実装・レビューまでの日常のループは、人間が介在しなくても回り続けます。 Managerエージェントがタスクを采配する、提案された構成 / Better Loops & Orchestrating Agents — Peter Steinberger, OpenAI 49:13より引用 一方で人間が不要になるわけではなく、ループの外側で意思決定を受け持ちます。ツールの利用許可のように人間の判断が必要な場面では、Managerが確認を求めるようにします。 もうひとつの提言が、エージェントをターミナルに閉じ込めないことです。Slackなど、ターミナル以外の場所から指示や確認ができれば、人間は席にいなくてもループの外から関与できます。こうした、エージェントを動かし続けるための実行環境や仕組みはハーネス（Harness）と呼ばれ、冒頭で触れた開催テーマのひとつでもあります。ハーネスを作ることが、これからのエンジニアの仕事になると述べていました。 締めくくりの「The future isn't twenty terminals. It's better loops.」という言葉が、強く心に残っています。 所感 この発表を聞くまでの私は、まさにSteinbergerさんがアンチパターンと呼ぶ「人間がOrchestratorである」状態で、タスクの切り出しも個々のエージェントの起動も自分で行っていました。発表を聞いてからは、タスクを切り出す工程からエージェントに任せる構成を実践しています。具体的には、社内の情報源をエージェントに参照させ、そこからタスク候補を抽出してIssue化し、優先度を付けて改善を進めるループです。並列実行するエージェントも自分で個々に起動するのではなく、Managerエージェントに任せているので、人間は指示と承認というループの外側の関与に集中できています。 ループが回っている間、人間は要件定義など別の仕事を進められます。実際にこの構成へ変えてから、私の1週間あたりのPR作成・マージ数はそれまでの約4倍になりました。ただしこれは担当タスクの性質や時期の違いを取り除いた厳密な計測ではないため、あくまで手応えを表す目安として捉えています。 一方で、人間がループの外側に出るほど、今度は承認の質そのものが問われるとも感じています。現状はManagerエージェントが判断を求めてきた場面でしか関与していないため、エージェントが問題に気づかないまま進んだケースを検知する手立ては持てていません。ループを回す速さと同じくらい、どこで人間が見るべきかの設計が重要になりそうです。 Self-Improving Software Factories Software Factoryは多くのスピーカーが語ったテーマですが、ここでは評価指標まで示したWarp創業者Zach Lloydさんの発表を紹介します。 主張を一言でいうと「Software EngineeringはFactory Engineeringになる」です。 エンジニアの仕事は、コードを書くことから、工場のオートメーションのように環境を整えて工場全体を制御することへ変わる、という意味です。 背景には、2026年4月に 自社のターミナル製品Warpをオープンソース化 したWarp自身の経験があります。発表では、これを契機に開発速度とコストが改善したと説明されていました。一方で、IssueやPRが乱立する課題も生まれました。個々の実装をエージェントに任せるだけでは、手前のタスク管理と後工程の検証が人手に残り、増え続けるIssueやPRを処理しきれないためです。 そこでWarpは、入力から運用までを次のような一本のAgenticフローとしてつなぎました。 SlackやWiki、Issueなどの情報源から問題を収集する 問題の大きさや複雑さといった観点からタスクへ落とし込む タスクの解決策や方針を立てる コーディングエージェントが実装する エージェントがレビューする（人間のレビューは任意） その変更がユーザーにどう影響するかを、エージェントがComputer Useで検証する CI/CDでリリースする リリース後のモニタリングでエラーを検知すると、エージェントが原因を突き止めて1の情報源に追加する 8で見つかった問題が再び1の入力になるため、不具合の修正までがループの中に入っています。 Software Factoryのループ図 / Self-Improving Software Factories — Zach Lloyd, Warp 4:55:21〜より引用 また、本発表ではFactory Engineeringの品質を評価する概念的な指標として以下が示されました。 Factory efficiency = Software shipped / (token + human cost) 出荷できたソフトウェアの量をトークンコストと人件費の合計で割った値であり、人の作業とトークン消費の双方をコストとして評価する考え方を示しています。 さらに、Issueを処理する日々のループ（Inner loop）とは別に、ループ自体を改善するループ（Outer loop）を回すべきだと述べていました。これによってループを人間が直接改善せず、ループ自体の改善も自動で回すことができます。 Inner loopとOuter loopの図 / Self-Improving Software Factories — Zach Lloyd, Warp 4:55:21〜より引用 所感 前のセッションで紹介したManager構成は、この発表でいうInner loopにあたります。現状の私は、マージ済みPR数というアウトプット量だけを見ており、出荷量や品質、人の工数、トークン費用まで含めた評価はできていません。Factory efficiencyの発想を使えばこうしたコストまで含めてループの良し悪しを評価できるため、まずは自分のループをこの指標で測り、Outer loopも回していきたいです。もっとも、分子である出荷できたソフトウェアの量をPR数で測るのか機能単位で測るのかは自明ではないため、実際に運用するならこの定義を決めるところから始める必要がありそうです。 Don't Ship Skills Without Evals Google DeepMindのPhilipp Schmidさんによる、エージェントに渡すスキルの作り方と品質管理を扱った発表です。 スキルとは、スクリプトやテンプレート、参考資料をSKILL.mdファイルを中心にひとつのフォルダにまとめたもので、特定の業務手順やベストプラクティスをエージェントに教える役割を持ちます。スキル自体は、エージェントに「今の流れを再現するスキルを作って」と頼むだけでも作れますが、作ったスキルがそのまま良いものとは限りません。この発表では、良いスキルを作るためのベストプラクティスが紹介されていました。 What Is a Skill? / Don't Ship Skills Without Evals — Philipp Schmid, Google DeepMind 2:28より引用 紹介された指針は、スキルがコンテキストを圧迫しないようにする、という観点で一貫していました。 まず、スキルの説明文（メタ情報）は最小限にします。多くの実装では、説明文がエージェントの全ターンでコンテキストに入るため、長い説明文はコストがかさむうえ、LLMの性能低下にもつながると説明されていました。 あわせて、説明には「こういう時には使用しない」など明確なユースケースを記載します。たとえばReactのデザインスキルに「Reactで使う」とだけ書くと、デザインと無関係なリファクタリング中にもスキル全体が読み込まれてしまいます。 本文の書き方では、手順を細かく指定せず、目標と制約を書くことが推奨されていました。手順を固定すると、エージェントがエラーから回復したり、より良い方法を選んだりする余地を奪うためです。ステップ1、ステップ2とフロー化したい処理なら、スキルではなくスクリプトにして実行させるべきと指摘されていました。 また、「高品質なコードを書いて」のように挙動へ影響しない記述はNo-Opsと呼ばれ、今のLLMにはこうした飾りの指示は不要でトークンを消費するだけのため、削除すべきだと説明されていました。 そして、モデルは賢くなり続け、スキルがなくてもできることは増えていくため、スキルは作って終わりではなく定期的に見直します。スキルあり・なしで評価を回すablationテストを行い、差がなくなったスキルは引退させることが推奨されていました。 所感 スキルがコンテキストを圧迫する問題は以前から耳にしていましたが、実際にどう減らすかという取り組みまではできていなかったところに、そのまま実践に移せる具体的な指針を得られました。 一方で、これらのベストプラクティスを人間が覚えてスキルを手で書き続けるのは難しいとも感じるため、エージェントにベストプラクティス自体を渡し、スキルの作成や整理を任せる仕組みを整備していきたいです。 Agentic Commerce Agentic Commerceは、ECサイトの開発に携わる立場から個人的に注目していた領域です。エージェントと一緒に買い物する体験の設計と、エージェントが支払いをするための決済インフラの順で、2つのセッションを紹介します。 Designing Multimodal Collaborative Agents for Next-Gen Commerce Google DeepMindのNidhi Vyasさんによる、ユーザーがエージェントとともに欲しいものを見つけていく体験をどう設計するかという発表です。 発表の前提にあるのは、すべてのユーザーが自分の欲しいものを明確に言語化できるわけではなく、曖昧なゴールしか持たないユーザーが多いという点です。そうしたユーザーには、ビジュアル情報を確認しながらインタラクティブに買い物を進められる体験が合う、というのがVyasさんの主張です。発表では、エージェントと一緒にショッピングを進めるこの体験をCo-Shopping Loopとして定義していました。 The Co-Shopping Loop / Designing Multimodal Collaborative Agents for Next-Gen Commerce（Nidhi Vyas, Google DeepMind）のスライドより引用 ループは以下の3ステップで構成されます。 Discovery：商品を提案するステップ 長期記憶として保持した対話履歴、時間や位置情報、予算やスタイルといった制約をもとに最適な候補を選ぶ 制約は、予算の上限のようなハードな制約と、スタイルの好みのようなソフトな制約に分けて扱う Multimodal Elicitation：ユーザーの意図をくみ取るステップ 発話だけでなく、クリックやマウスのホバー、スクロールといった操作を取得してエージェントにフィードバックする あるスタイルの提案に15秒ホバーした、といった行動を、言葉ではない潜在的な好みとして利用する Adaptive Response：応答の仕方を最適化するステップ ここまでに集めたパーソナライズ情報からユーザーの求める答えの形を予測し、探索段階に応じて構造化テキスト・ビジュアルギャラリー・比較表を使い分ける じっくり比較したいのか、多様な商品をまず眺めたいのか、購入を後押しする説明がほしいのか、ユーザーの潜在的な意図はさまざまです。比較ボタンや一覧表示の切り替え動線を用意しても、すべてのユーザーが能動的に探索するとは限りません。そのため、内容だけでなく見せ方まで、その時点のユーザーの状態に合わせて選ぶべきだとVyasさんは述べていました。 Adaptive Response / Designing Multimodal Collaborative Agents for Next-Gen Commerce（Nidhi Vyas, Google DeepMind）のスライドより引用 所感 エージェントと一緒に買いたいものを明確化していく体験は、検索体験を作る立場からも重要だと感じました。特に「比較したい人には比較表、多様な商品を眺めたい人には商品リスト」のようにユーザーの状態に応じて見せ方を出し分ける発想は、体験の質を大きく左右すると思います。 私自身、2つの商品で迷っているときもあれば、多くの商品からまずあたりをつけたいときもあります。ただ、その状態を言葉にしてエージェントへ伝えるのはユーザーにとって負荷の高い作業であるため、その部分をエージェント側が行動から推論して補うアプローチには大きな可能性を感じました。 When AI Agents Pay and Sellers Monetize: Building x402 Apps for Agentic Commerce on AWS AWSのAnil Nadimintiさんによる、エージェントの支払いを支える決済インフラをどう作るかという発表です。 前提となるのが、AIによる自動アクセスの急増です。発表では、botが全Webトラフィックの51％を占め、初めて人間を上回ったという調査結果が紹介されました。また、一部の企業ではWebトラフィックの95％がAIスクレイピングbot由来だと引用されていました。 AIエージェントによるトラフィックの現状 / When AI Agents Pay and Sellers Monetize: Building x402 Apps for Agentic Commerce on AWS（Anil Nadimineti, AWS）のスライドより引用 発表では、エージェントからのアクセスに対するサイト側の対応が、ブロックか受け入れかの二択として整理されていました。 ブロックすれば基盤への負荷は抑えられるが、AI経由でユーザーに見つけてもらう機会を失う 受け入れれば露出の機会は増えるものの、基盤を強化する必要がありコストも高くつく 実際にはレート制限や認証といった中間的な対策もありますが、それだけではコンテンツ利用に応じた対価を得られません。個別のライセンス契約で対価を得る方法もあるものの、少額・高頻度のアクセスには適用しにくい課題があります。 botをブロックする場合と受け入れる場合のトレードオフ / When AI Agents Pay and Sellers Monetize: Building x402 Apps for Agentic Commerce on AWS（Anil Nadimineti, AWS）のスライドより引用 発表では、支払い要求に応じるエージェントに対してアクセス単位で課金する、という第三の選択肢が提示されました。ブロックか受け入れかの二択に、対価を得ながら受け入れる道を加える発想です。ただし、従来の課金モデルはエージェントに合わず、たとえば「月100万円で1万リクエストまで」のようなプランは、少ししか使わない利用者にはハードルが高すぎます。かといって1リクエストごとにクレジットカードで請求すると、代金よりカード手数料の方が高くなることもあります。エージェントのアクセスは少額・高頻度のため、それに合った決済の仕組みが必要です。 そこで登場するのが、Coinbase社が開発したエージェントのための決済プロトコルx402です。2026年4月にLinux Foundationへの移管の意向が発表され、同年7月14日には移管の完了とx402 Foundationの運営開始が発表されました。名前の由来であるHTTPステータスコード402（Payment Required）は、支払いが必要なことを表すコードとしてもともと仕様に存在していたものの、ほとんど使われてきませんでした。x402はこの402を、エージェントへの支払いリクエストとして利用します。 x402による支払いの流れは次のとおりです。 エージェントが有料URLへアクセスする サイト側が金額・支払い先・利用できる決済方法といった支払い要件を含む402レスポンスを返す エージェントがウォレットで支払いに署名し、その支払い証明をリクエストヘッダーに付けて再度リクエストする サイト側が支払い証明を検証・決済し、確認できたら有料情報を返す クレジットカードのフォーム入力を挟まず、HTTPのやりとりだけで支払いが完結します。 この流れはAWSにも広がっており、Amazon BedrockのAgentCore Paymentsがx402をサポートしています（2026年8月時点ではプレビュー提供です）。 x402 Key Milestones / When AI Agents Pay and Sellers Monetize: Building x402 Apps for Agentic Commerce on AWS（Anil Nadimineti, AWS）のスライドより引用 買う側は、Coinbase CDPやStripeのウォレットをAgentCoreに接続し、エージェントはセッションごとに設定した予算の範囲でx402を使って有料情報を取得します。売る側については、AIエージェントのアクセスを検知してカテゴライズし、エンドポイントごとに利用料を設定して売上をダッシュボードで確認できる構成が発表では紹介されていました。 また、別セッション「Why Your AI Agent Needs a Wallet」では、Circle社のHarshal Bhangaleさんが登壇していました。この発表では、x402の直近の取引量と、Agentic Commerceの将来予測に触れられていました。スライドによると、2026年6月30日時点の直近30日間でx402の取引量は2400万ドルを超えています。あわせて、2030年にはAgentic Commerce市場全体が5兆ドル規模になるという予測も紹介されていました。 x402の市場規模 / Why Your AI Agent Needs a Wallet（Harshal Bhangale, Circle）のスライドより引用 所感 AIエージェントにアクセスされることでユーザーへの露出が増える一方、その負荷はサイトの維持費に跳ね返ります。だからこそ、アクセスに対して対価を得るという発想は合理的だと感じました。 エージェント側にとっても、これまでアクセスできなかったデータを利用できるようになるメリットがあります。売る側と買う側の両方が変わることで、AIエージェントを軸にした市場自体が大きく動いていくと感じました。 まとめ 本記事ではAI Engineer World's Fair 2026の現地の様子と、気になったセッションを紹介しました。Software Factoriesの3セッションでは、人間が個々のタスクを采配する構成から、エージェントが実行ループを管理する構成への移行が提案されていました。私自身のManager構成による開発フローでは、品質やコストまで含めた評価方法が今後の課題です。Agentic Commerceの2セッションからは、ユーザーの状態に合わせて見せ方まで出し分ける体験設計と、エージェントのアクセスを収益化する決済インフラの動きを確認できました。ZOZOTOWNの検索体験にどう取り入れられるか、引き続き検証していきます。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 9月に入り、秋の気配を感じ始めた方も多いのではないでしょうか。今週は AWS Interconnect への Microsoft Azure 接続プレビューや Amazon Linux 2027 のパブリックプレビューなど、幅広いアップデートが揃いました。さて、ちょっと変わったイベントのお知らせです。5体の AI エージェントでチームを組み、自然言語で戦術を指示してサッカーの試合で対戦する「 AWS Agentic Football Cup 」のバーチャルリーグが 9/14（月） に開幕します。Amazon Bedrock AgentCore を使ったマルチエージェント体験を楽しみながら、勝ち上がると AWS re:Invent （11/30〜12/4、ラスベガス） の決勝に招待され、渡航費サポートに加えて優勝賞金 30,000 USD の賞金プールも用意されています。参加無料・コーディング経験不問ですので、腕試しにぜひ登録してみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年8月31日週の主要なアップデート 8/31(月) Automated Security Response on AWS がカスタム修復向け AI Toolkit を追加 AWS ソリューションの Automated Security Response on AWS (ASR) がバージョン 4.0.0 (2026 年 8 月 26 日リリース) で 4 つの新機能を追加しました。任意の AI アシスタントで ASR 準拠のカスタム修復を生成できる AI Remediation Toolkit、Amazon Inspector / GuardDuty / Macie の検出結果の自動修復、アカウント・OU・リージョン・タグ単位でスコープ設定できる強化版 Web コンソール、Email / Slack / Jira / ServiceNow 向けのマルチチャネル通知アダプターです。カスタム修復の開発期間は数週間から数時間に短縮され、100 以上のセキュリティコントロールを Web コンソールから一元管理できます。 AWS Workload Credentials Provider が Linux および Windows 向けにワンクリックインストールで利用可能に AWS Secrets Manager は、AWS Workload Credentials Provider (AWCP) のワンクリックインストールを発表しました。AWCP は Secrets Manager のシークレットをメモリ内にキャッシュし、ローカル HTTP エンドポイント経由でアプリケーションに提供するエージェントで、AWS Certificate Manager (ACM) からの証明書取得にも対応します。従来は GitHub リポジトリのクローンから Rust でのビルドまで約 6 ステップが必要でしたが、Amazon Linux 2023 では dnf コマンド 1 つでインストールできるようになりました。Linux (x86_64、ARM64) と Windows (x64) 向けのコード署名済みビルド済みバイナリも公開ダウンロード URL から取得できます。Secrets Manager が利用可能な全リージョンで、Secrets Manager の標準料金以外の追加費用なしで利用できます。 Amazon WorkSpaces Applications が新たに 3 つの AWS リージョンで利用可能に Amazon WorkSpaces Applications (旧 AppStream 2.0) が、チューリッヒリージョン、大阪リージョン、カルガリーリージョンの 3 リージョンで利用可能になりました。これにより利用可能リージョンは GovCloud を含む従来の 20 リージョンから 23 リージョンに拡大します。アプリケーションストリーミングはネットワークレイテンシーの影響を受けやすく (推奨 250 ms 以下、100 ms 未満が最良)、エンドユーザーに近いリージョンへの展開で操作の応答性が改善されます。また、日本、スイス、カナダ西部のデータレジデンシー要件やコンプライアンス要件への対応にも利用できます。 AWS Interconnect – Microsoft Azure とのマルチクラウド接続をプレビューで発表 AWS は、AWS Interconnect – multicloud の接続先として Microsoft Azure をパブリックプレビューで追加しました。AWS Interconnect – multicloud は、AWS の VPC と他のクラウドプロバイダーのプライベートネットワークを、マネージド型のプライベート接続で結ぶサービスです。従来はコロケーション施設や自前ルーターを組み合わせた DIY 構成が必要でしたが、AWS Management Console、CLI、API から数分で冗長構成の接続をプロビジョニングできます。すでに OCI と Google Cloud は一般提供 (GA) されており、Azure の追加により主要 3 クラウドとの接続が単一の管理体験に統合されます。プレビューはバージニア北部、北カリフォルニア、シドニー、フランクフルトの 4 リージョンで利用できます。 一元的なエージェント検出とガバナンスのための AWS Agent Registry が一般提供開始 AWS Agent Registry が一般提供 (GA) になりました。組織内のエージェント、ツール、スキル、MCP サーバー、カスタムリソースを登録・承認・検索できるプライベートカタログを提供するフルマネージドサービスです。GA では、プレビューの機能に加えて、AWS CloudFormation・Terraform・AWS CDK による IaC 管理、タグ付け、AWS RAM によるクロスアカウント共有、AWS Organizations 全体での AgentCore リソース自動検出、Amazon Quick 連携が追加されました。バージニア北部、オレゴン、アイルランド、東京、シドニーの 5 リージョンで利用できます。料金は従量課金で、月間 5,000 レコード、Search API 100 万回、List + Get API 200 万回までの無料枠があります。 Amazon Aurora serverless が 最大 30% の性能向上とスケーリング改善を追加リージョンで利用可能に Aurora serverless のプラットフォームバージョン 4 が、ニュージーランド、タイ、ケープタウン、ミラノ、メキシコセントラル の 5 リージョンで追加提供されました。プラットフォームバージョン 4 は、バージョン 3 と比較して最大 30% の性能向上と、複数タスクがリソースを奪い合うワークロードに対応する改良版スケーリングアルゴリズムを含みます。Aurora PostgreSQL と Aurora MySQL の両方が対象で、追加費用はかかりません。新規クラスター、リストア、クローンは自動的にプラットフォームバージョン 4 で起動し、既存クラスターは保留中のメンテナンスアクションの適用、停止と再起動、または blue/green デプロイのいずれかでアップグレードできます。 9/1(火) Anthropic の新しいフロンティアモデル Claude Fable 5.1 が AWS で利用可能に Anthropic の最上位フロンティアモデル Claude Fable 5.1 が AWS で一般提供を開始しました。コンテキストウィンドウ 1M トークン、最大出力 128K トークンで、数時間規模のコーディングやエージェントワークロード、ナレッジワークに向けた設計です。アクセス経路は Amazon Bedrock と、Anthropic が運用する Claude Platform on AWS の 2 つがあります。本モデルは「Covered Model」に指定されており、利用には 30 日間のデータ保持と AWS レビューへのオプトインへの同意が必須です。30 日間のデータ保持を受け入れられないお客様向けには、監視用データを自社管理の AWS 環境に保持したまま利用できる Enterprise Frontier Safeguards (EFS) が、対象のお客様から 2026 年秋以降段階的に展開される予定です。 AWS Marketplace がプライベートオファーの自動更新に対応 AWS Marketplace で、プライベートオファーに自動更新 (auto-renewal) 条件を設定できるようになりました。契約期間の満了時に、交渉済みの価格と契約条件を引き継いだ新しい契約が自動的に作成されるため、再交渉や再購入の手続きが不要になります。販売者は「価格据え置き」「固定率の値上げ」「範囲内での値上げ」の 3 種類から更新時の価格ルールを選択でき、購入者はオファー承諾時および更新決定期限までの間、自動更新のオプトイン/アウトを変更できます。契約価格 (contract pricing) を使う直接プライベートオファーが対象で、すべての商用リージョンで追加設定なしに利用できます。 9/2(水) Amazon SageMaker Unified Studio CI/CD がノートブックプロモーションと AI 支援によるマニフェスト生成を追加 Amazon SageMaker Unified Studio (SMUS) のオープンソース CI/CD ツールキット (aws-smus-cicd-cli) に 2 つの機能が追加されました。1 つ目は generate-bundle-manifest エージェントスキルで、プロジェクトの接続・ストレージ・ワークフローを読み取り専用で調査し、デプロイマニフェストを自動生成します。2 つ目はネイティブ SMUS Notebook のプロモーション機能で、開発・テスト・本番の各環境へノートブックを冪等に同期し、実行履歴を保持したまま更新できます。どちらもオープンソースとして GitHub で公開されており、SMUS が利用可能なすべてのリージョンで使用できます。 Amazon Connect Customer が agentic CX designer の一般提供を開始 Amazon Connect Customer は、AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバスである agentic CX designer の一般提供を開始しました。ビジュアルキャンバス上で、LLM が推論する agentic なステップと、適格性判定やコンプライアンス開示など正確さが必須の deterministic なステップを 1 つの会話の中で組み合わせられます。設計、外部システム統合、テスト、本番デプロイまでを同一の場所で完結でき、業務チームがコードを書かずに数週間で本番稼働まで到達できます。本機能は AWS が 2026 年に買収した会話型 AI 企業 NLX の技術を基盤としており、2026 年 6 月 22 日のプレビュー発表を経て GA となりました。東京リージョンを含む 9 リージョンで利用できます。 Amazon Quick がコネクタ向けの新しいツール設定と Model Context Protocol (MCP) 同期サポートを追加 Amazon Quick のコネクタに、ツール単位の有効化/無効化、ツール実行前の同意 (consent) を制御する権限設定、外部 MCP サーバーの変更を自動反映する MCP sync の 3 機能が追加されました。コネクタは Outlook、Slack、Salesforce、Jira や自社開発の MCP サーバーを、チャット、エージェント、アプリ、フロー、ディープリサーチから利用するための仕組みです。従来は MCP サーバー側でツールが追加・変更されるとコネクタを削除して再作成する必要がありましたが、MCP sync によりこの運用が不要になります。管理者とコネクタオーナーは、承認済みツールのみをエンドユーザーに公開するガバナンスを構成できます。Amazon Quick が利用可能なすべてのリージョンで利用できます。 9/3(木) Amazon SES が S/MIME メール署名のサポートを開始 Amazon SES が S/MIME (Secure/Multipurpose Internet Mail Extensions) によるメールのデジタル署名に対応しました。署名用証明書を AWS Certificate Manager (ACM) に保存し、送信 ID に関連付けたうえで設定セットの S/MIME 署名を有効化すると、SES が送信時にサーバー側で自動的に署名を付与します。従来は送信者がメッセージを SES に渡す前に自前で署名する必要がありましたが、この作業が不要になります。受信者は From アドレスの保持者本人が送信したこと、および本文が転送中に改ざんされていないことを検証できます。本機能は SES が利用できるすべての AWS リージョンで利用できます。 Amazon Linux 2027 のパブリックプレビューを発表 AWS は Amazon Linux の次期メジャーバージョンである Amazon Linux 2027 (AL2027) のパブリックプレビューを公開しました。AL2023 をベースラインとして、カーネル 7.1、GCC 16.1、Python 3.14 など主要コンポーネントを刷新し、SELinux をデフォルトで enforcing モードに変更しています。ポスト量子暗号 (PQC) がデフォルトで有効になり、AWS-LC による暗号処理の高速化と AWS Neuron ドライバのサポートも含まれます。プレビュー AMI は全商用リージョンで x86-64 / ARM の両アーキテクチャ向けに提供され、コンテナベースイメージは Amazon ECR Public Gallery から取得できます。サポート期限は 2032 年までと案内されており、AL2023 (2029 年 6 月サポート終了) からの移行先となります。 Amazon Quick Max を発表: Quick を最大限活用するパワーユーザー向けに 5 倍の使用量を提供 Amazon Quick に新しい上位プラン「Quick Max」が追加されました。Max は Plus プランの 5 倍の使用量と 5 倍のインデックスストレージ (10 GB → 50 GB) を提供し、月をまたいで大規模なワークロードを中断なく実行したいパワーユーザーを対象としています。料金は年払いで月額 100 USD/ユーザー、月払いで月額 125 USD/ユーザー です。既存の Plus ユーザーは画面左ナビゲーション下部のユーザー名から「Upgrade plan」を選択するだけで切り替えでき、アップグレードは即時に有効になります。 9/4(金) AWS MCP Server が AWS Lambda 関数向けの serverless capability を追加 AWS MCP Server に serverless capability が追加され、Claude Code や Kiro などのコーディングエージェントが Lambda 関数とその接続リソースの障害を診断できるようになりました。エージェントは 1 回のツール呼び出しで、7 日間ベースラインとの比較によるメトリクス異常検知、ログの構造化サマリー、デプロイ済み設定、変更タイムライン、X-Ray トレースの分析結果を取得できます。複数の API 呼び出しをエージェント側で組み立てる場合と比べて、トークン消費を抑えられます。serverless capability は追加料金なしで利用でき、AWS MCP Server 自体はバージニア北部リージョンとフランクフルトリージョンで稼働します。 Amazon Bedrock Managed Knowledge Base がデータソースコネクタの自動同期スケジュールに対応 Amazon Bedrock Managed Knowledge Base で、データソースコネクタの自動同期スケジュールを設定できるようになりました。従来はソースデータの変更のたびに手動で同期を実行するか、EventBridge Scheduler などでカスタムの仕組みを構築する必要がありました。今回のアップデートにより、日次、週次、月次の 3 種類の頻度をデータソース単位で設定でき、Confluence や SharePoint、Amazon S3 などのネイティブコネクタ全てに適用できます。同期は増分処理のため、前回同期以降に追加、変更、削除されたドキュメントのみが処理されます。RAG アプリケーションのデータ鮮度維持にかかる運用作業を削減できます。 Amazon Bedrock Managed Knowledge Base が SharePoint、OneDrive、Confluence データソースのユーザー管理セットアップを導入 Amazon Bedrock Managed Knowledge Base の SharePoint、OneDrive、Confluence データソースで、ユーザー管理セットアップ (3LO: 3-legged OAuth) が利用できるようになりました。従来はサービスアカウント方式 (2LO) の認証情報を第三者システム側で発行する必要があり、管理者権限を持たないユーザーは IT 部門との調整が必要でした。本アップデートにより、既存の Microsoft 365 アカウントや Atlassian アカウントでサインインするだけで、数分でデータソースの接続を完了できます。ただし 3LO は文書レベルのアクセス制御 (ACL) に対応しないため、本番ワークロードには引き続き Entra ID App-Only などのサービスアカウント方式が推奨されます。 今週は AWS Agent Registry の GA や Amazon Quick の新機能追加など、エージェント関連のアップデートも目立ちました。エージェントの検出・ガバナンスからツール管理まで、エージェント開発の土台が着実に整ってきている印象です。年末の re:Invent（11/30〜12/4）に向けてさらにアップデートが加速しそうですね。来週もお楽しみに！ それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。