こんにちは、駅メモ！開発チームエンジニアの id:hayayanai です！ 最近、 VoidZero から Vite+ がリリースされました。 Vite+ は Vite 8、Vitest、Oxlint、Oxfmt などを統合した「Web のための統合ツールチェーン」です。 駅メモ！は現在 Vue + Vite 7 + Vitest + ESLint（チーム独自ルール有り）+ Prettier + Stylelint で開発されており、Vite+ のツールはまだ導入していません。 AI で開発が高速化した現代、数十倍速いと謳う Vite+ のツールチェーンは気になります。 ただ、そもそも各ツールがどれくらい Vue 対応しているのか、どう設定すれば良いのかがわからなかったので、テンプレを使って確認することにしました。 Vite+ 経由の vp create vue と従来の pnpm create vue@latest で生成されるプロジェクト設定を比較し、Vue プロジェクト特有の注意点を整理します。 検証環境 プロジェクトの作成 Vite+ 経由 従来の create-vue 生成される設定ファイルの比較 Vite+ プロジェクトの構成 従来の create-vue プロジェクトの構成 共通: eslint.config.ts 共通: Lint 実行順 Linter 比較: Oxlint vs ESLint 検証用コンポーネント Oxlint の結果 ESLint の結果 CSS/Style Lint について 型チェックの違い テスト Formatter 比較: Oxfmt vs Prettier Vue SFC のフォーマット対応 全体比較表 まとめ Linter 型チェック Formatter CSS Lint 検証環境 vp v0.1.16 (Vite+) create-vue v3.22.2 (pnpm create vue@latest) Node.js v24.14.1 pnpm v10.33.0 プロジェクトの作成 Vite+ 経由 vp create vue vue-viteplus ◇ Which package manager would you like to use? pnpm ◇ pnpm@10.33.0 installed ◇ Which agents are you using? Claude Code ◇ Which editor are you using? VSCode ◇ Set up pre-commit hooks to run formatting, linting, and type checking with auto-fixes? Yes Generating project… Running: pnpm dlx create-vue ┌ Vue.js - The Progressive JavaScript Framework │ ◇ Project name (target directory): │ vue-viteplus │ ◇ Use TypeScript? │ Yes │ ◇ Select features to include in your project: │ Vitest (unit testing), Linter (error prevention), Prettier (code formatting) │ ◇ Select experimental features to include in your project: │ Replace Prettier with Oxfmt │ ◇ Skip all example code and start with a blank Vue project? │ No Scaffolding project in /Users/yanai/project/vue-viteplus... │ └ Done. ✔ Merged vue-viteplus/.oxlintrc.json into vue-viteplus/vite.config.ts ✔ Merged vue-viteplus/.oxfmtrc.json into vue-viteplus/vite.config.ts Wrote agent instructions to CLAUDE.md Rewrote imports in 4 files ✔ Merged staged config into vue-viteplus/vite.config.ts ◇ Dependencies installed ◇ Code formatted ◇ Scaffolded vue-viteplus 出力を見ると Running: pnpm dlx create-vue とあり、内部で create-vue を呼んでいることが分かります。create-vue でプロジェクトを生成した後に、Vite+ が以下の変換をかけています。 .oxlintrc.json → vite.config.ts の lint ブロックにマージ .oxfmtrc.json → vite.config.ts の fmt ブロックにマージ vite / vitest の import パスを vite-plus に書き換え pre-commit フック（ vp staged ）の設定を統合 つまり vp create vue は create-vue のラッパーで、生成物を Vite+ 向けに変換しているだけのようです。 従来の create-vue pnpm create vue@latest vue-create-vue ┌ Vue.js - The Progressive JavaScript Framework │ ◇ Use TypeScript? │ Yes │ ◇ Select features to include in your project: │ Vitest (unit testing), Linter (error prevention), Prettier (code formatting) │ ◇ Select experimental features to include in your project: │ none │ ◇ Skip all example code and start with a blank Vue project? │ No Scaffolding project in /Users/yanai/project/vue-create-vue... │ └ Done. こちらは従来通りのシンプルな Scaffold です。create-vue 側でも「Replace Prettier with Oxfmt」の選択肢が出ますが、今回は Oxfmt との比較のため Prettier を選びました。 生成される設定ファイルの比較 以降のコードブロックは主要部分の抜粋です。 Vite+ プロジェクトの構成 package.json { " scripts ": { " dev ": " vp dev ", " build ": " run-p type-check \" build-only {@} \" -- ", " build-only ": " vp build ", " type-check ": " vue-tsc --build ", " test:unit ": " vp test ", " lint ": " run-s lint:* ", " lint:oxlint ": " vp lint . --fix ", " lint:eslint ": " eslint . --fix --cache ", " format ": " vp fmt src/ " } , " devDependencies ": { " eslint ": " ^10.1.0 ", " eslint-plugin-vue ": " ~10.8.0 ", " eslint-plugin-oxlint ": " ~1.57.0 ", " eslint-config-prettier ": " ^10.1.8 ", " vite ": " catalog: ", " vite-plus ": " catalog: ", " vitest ": " catalog: " } } vite.config.ts: import { defineConfig } from "vite-plus" import vue from "@vitejs/plugin-vue" export default defineConfig( { staged : { "*" : "vp check --fix" , } , fmt : { semi : false , singleQuote : true , } , lint : { plugins : [ "eslint" , "typescript" , "unicorn" , "oxc" , "vue" , "vitest" ] , env : { browser : true } , categories : { correctness : "error" } , options : { typeAware : true , typeCheck : true } , } , plugins : [ vue() ] , } ) defineConfig を 'vite-plus' からインポートしていて、Vite の設定に加え lint （Oxlint）、 fmt （Oxfmt）、 staged （pre-commit フック）の設定が1つのファイルにまとまっています。 vite と vitest は、 pnpm-workspace.yaml の catalog: により @voidzero-dev のものに解決されています。 従来の create-vue プロジェクトの構成 package.json { " scripts ": { " dev ": " vite ", " build ": " run-p type-check \" build-only {@} \" -- ", " build-only ": " vite build ", " type-check ": " vue-tsc --build ", " test:unit ": " vitest ", " lint ": " run-s lint:* ", " lint:oxlint ": " oxlint . --fix ", " lint:eslint ": " eslint . --fix --cache ", " format ": " prettier --write --experimental-cli src/ " } , " devDependencies ": { " eslint ": " ^10.1.0 ", " eslint-plugin-vue ": " ~10.8.0 ", " eslint-plugin-oxlint ": " ~1.57.0 ", " eslint-config-prettier ": " ^10.1.8 ", " oxlint ": " ~1.57.0 ", " prettier ": " 3.8.1 ", " vite ": " ^8.0.3 ", " vitest ": " ^4.1.2 " } } .oxlintrc.json: { " plugins ": [ " eslint ", " typescript ", " unicorn ", " oxc ", " vue ", " vitest " ] , " env ": { " browser ": true } , " categories ": { " correctness ": " error " } } .prettierrc.json: { " $schema ": " https://json.schemastore.org/prettierrc ", " semi ": false , " singleQuote ": true , " printWidth ": 100 } 共通: eslint.config.ts 前述の通り vp create vue は内部で create-vue を実行しているため、eslint.config.ts は両プロジェクトで同一です。 import { defineConfigWithVueTs, vueTsConfigs, } from "@vue/eslint-config-typescript" import pluginVue from "eslint-plugin-vue" import pluginVitest from "@vitest/eslint-plugin" import pluginOxlint from "eslint-plugin-oxlint" import skipFormatting from "eslint-config-prettier/flat" export default defineConfigWithVueTs( { name : "app/files-to-lint" , files : [ "**/*.{vue,ts,mts,tsx}" ] } , ...pluginVue.configs[ "flat/essential" ], vueTsConfigs.recommended, { ...pluginVitest.configs.recommended, files : [ "src/**/__tests__/*" ] } , ...pluginOxlint.buildFromOxlintConfigFile( ".oxlintrc.json" ), skipFormatting ) ただし、Vite+ プロジェクトではこの eslint.config.ts に落とし穴があります。 Vite+ の公式ガイド では .oxlintrc.json の使用は推奨されておらず、 vite.config.ts の lint ブロックへ設定を集約する方針です。実際、 vp create vue で .oxlintrc.json は vite.config.ts へマージされた後に削除されています。 しかし eslint.config.ts の buildFromOxlintConfigFile(".oxlintrc.json") はそのまま残っています。存在しないファイルを参照すると eslint-plugin-oxlint: could not find oxlint config file: .oxlintrc.json と警告が出て空配列を返すため、ルール重複の無効化が効きません。 つまり、Oxlint と ESLint で同じ違反が重複報告される状態になります。 回避策は2つあります。 １つ目は vite.config.ts から lint ブロックを直接インポートする方法です。 eslint.config.ts は TypeScript ですから、 vite.config.ts の default export から .lint を取り出して buildFromOxlintConfig に渡せます。 // eslint.config.ts import viteConfig from './vite.config' // 変更前: ファイルが存在しないため機能しない ...pluginOxlint.buildFromOxlintConfigFile( ".oxlintrc.json" ), // 変更後: vite.config.ts の lint ブロックをそのまま渡す ...pluginOxlint.buildFromOxlintConfig(viteConfig.lint), ２つ目は vite.config.ts の lint ブロックを削除し、 .oxlintrc.json に設定を一本化する方法です。 vite-plus の issue によると、現状の実装では .oxlintrc.json 等の専用設定ファイルが優先され、 vite.config.ts はフォールバックとして使われます。 .oxlintrc.json があればそちらが読み込まれます。 { " plugins ": [ " eslint ", " typescript ", " unicorn ", " oxc ", " vue ", " vitest " ] , " env ": { " browser ": true } , " categories ": { " correctness ": " error " } , " options ": { " typeAware ": true , " typeCheck ": true } } eslint.config.ts の修正が不要で済みますが、Vite+ の「 vite.config.ts に集約する」方針とは外れます。 共通: Lint 実行順 2026年4月時点で、create-vue は Oxlint をデフォルトで同梱しています。前述の package.json にある通り、 pnpm lint （ run-s lint:* ）で lint:oxlint → lint:eslint の順に直列実行されます。 create-vue 側では eslint-plugin-oxlint が .oxlintrc.json を読み取り、Oxlint と重複する ESLint ルールを自動で無効化してくれます。 # Vite+ vp run lint # → vp lint . --fix ... Oxlint（vp経由） # → eslint . --fix --cache ... ESLint（直接呼び出し） # create-vue pnpm lint # → oxlint . --fix ... Oxlint（直接呼び出し） # → eslint . --fix --cache ... ESLint（直接呼び出し） vp lint は Oxlint だけを実行する組み込みコマンドで、ESLint は Vite+ に統合されていません。 そのため、テンプレートでは ESLint を eslint コマンドで直接呼ぶ構成になっています。 Vite+ のタスクランナーを活用したい場合は、 vite.config.ts の run.tasks に定義を移行すると良さそうです。 run.tasks で定義したタスクはデフォルトでキャッシュが有効なため、入力ファイルに変更がなければ再実行がスキップされます。 なお、 run.tasks のタスク名は package.json の scripts と重複できないため、移行する場合は package.json 側の lint スクリプトを削除します。 // package.json の lint 関連スクリプトを run.tasks に移行する例 run: { tasks: { lint: { command: 'vp lint . --fix && eslint . --fix --cache' , input: [{ auto : true } , '!.eslintcache' ] , } , } , } , eslint の --cache を使うと .eslintcache が書き出され、 vp run がそれを入力の変更と見なしてタスクキャッシュがヒットしません。 input で '!.eslintcache' を指定し、キャッシュファイルを変更検知の対象外にすることで併用できます。 キャッシュ機能については ESLint ではなくタスクランナー側のもので十分かもしれませんが、 --cache の有無による差異は今回未検証です。 Linter 比較: Oxlint vs ESLint 検証用コンポーネント 検証用に、意図的に Lint 違反を仕込んだ Vue コンポーネントを用意しました。 < script setup lang = "ts" > import { ref } from "vue" // unused expression (correctness) const x = 1 x // prefer-as-const (typescript) let y = "hello" as "hello" const items = ref ([ { id : 1 , name : "Apple" } , { id : 2 , name : "Banana" } , ]) </ script > < template > <!-- v-for without :key --> < li v- for = "item in items" > {{ item.name }} </ li > <!-- v-if and v-for on same element --> < div v- for = "item in items" v-if= "item.id > 0" :key= "item.id" > {{ item.name }} </ div > </ template > < style scoped> .unused-class { color : redd; } </ style > Oxlint の結果 # Vite+ vp lint src/components/LintTest.vue x eslint(no-unused-expressions): Expected expression to be used , - [src/components/LintTest.vue: 6 : 1 ] 5 | const x = 1 6 | x : ^ `---- x typescript-eslint(prefer-as-const): Expected a ` const ` assertion instead of a literal type annotation. , - [src/components/LintTest.vue: 9 : 20 ] 8 | // prefer-as-const (typescript) 9 | let y = 'hello' as 'hello' : ^^^^^^^ ` ---- Found 0 warnings and 2 errors. Finished in 369ms on 1 file with 132 rules using 10 threads. # create-vue pnpm exec oxlint -c .oxlintrc.json src/components/LintTest.vue ...（同一の 2 件） Found 0 warnings and 2 errors. Finished in 24ms on 1 file with 116 rules using 10 threads. Oxlint は <script> 内の違反を検出しましたが、 <template> / <style> の問題はスルーされています。Oxlint は .vue ファイルの <script> ブロックしか Lint しないためです。 oxc の互換性ページ にもある通り、Vue/Svelte/Astro 等のフレームワークでは script ブロックのみが対象です。 vue プラグインを有効にしても、script ブロック内の Vue 関連ルール（ref の使い方など）しか動きません。 SFC テンプレートの Lint 対応は oxc#15761 で追跡されていますが、まだ実装されていません。 また、Oxlint には ESLint の JS プラグインを読み込む JS plugins 機能もありますが、eslint-plugin-vue は動きません。 JS plugins の 制限事項 に「Custom file formats and parsers (e.g. Svelte, Vue, Angular)」は未対応と明記されています。 eslint-plugin-vue はカスタムパーサー（ vue-eslint-parser ）で .vue ファイル全体をパースしてテンプレートの AST をルールに渡す仕組みのため、この制限に該当しています。 ルール数の差（132 vs 116）は、 typeAware: true で型情報を使ったチェック（floating promise の検出等）が追加されるためです。 なお、Vite+ テンプレートの typeCheck: true は Vue プロジェクトでは実質的に使えないようです。 vp lint src/ のようにディレクトリを指定すると .ts ファイルもチェック対象になります。 しかし、 .ts から .vue をインポートしている箇所で tsgo がモジュール解決に失敗し TS2307: Cannot find module エラーが出ます。 上の検証でファイルを直接指定しているのはこの問題を回避するためです。 ESLint の結果 # Vite+（eslint-plugin-oxlint が機能していない） vp exec eslint src/components/LintTest.vue src/components/LintTest.vue 6 : 1 error Expected an assignment or function call and instead saw an expression @typescript-eslint/no-unused-expressions 9 : 5 error 'y' is never reassigned. Use 'const' instead prefer-const 9 : 5 error 'y' is assigned a value but never used @typescript-eslint/no-unused-vars 9 : 20 error Expected a `const` instead of a literal type assertion @typescript-eslint/prefer-as-const 19 : 3 error Elements in iteration expect to have 'v-bind:key' directives vue/require-v-for-key 22 : 30 error The 'items' variable inside 'v-for' directive should be replaced with a computed property that returns filtered array instead. You should not mix 'v-for' with 'v-if' vue/no-use-v-if-with-v-for ✖ 6 problems ( 6 errors, 0 warnings) # create-vue（eslint-plugin-oxlint が正常動作） pnpm exec eslint src/components/LintTest.vue src/components/LintTest.vue 9 : 5 error 'y' is never reassigned. Use 'const' instead prefer-const 9 : 5 error 'y' is assigned a value but never used @typescript-eslint/no-unused-vars 19 : 3 error Elements in iteration expect to have 'v-bind:key' directives vue/require-v-for-key 22 : 30 error The 'items' variable inside 'v-for' directive should be replaced with a computed property that returns filtered array instead. You should not mix 'v-for' with 'v-if' vue/no-use-v-if-with-v-for ✖ 4 problems ( 4 errors, 0 warnings) Vite+ 側は Oxlint で検出されている no-unused-expressions と prefer-as-const も ESLint から報告されて6件。前述の通りルール重複の無効化が効いていません。 create-vue 側は eslint-plugin-oxlint が正常動作し、Oxlint との重複ルールが ESLint 側で無効化されるため4件。 どちらも、 eslint-plugin-vue により <template> 内の Vue 固有の問題も検出されています。 CSS/Style Lint について 検証用コンポーネントの <style> に color: redd; というタイポを仕込みましたが、Oxlint でも ESLint でも引っかかりませんでした。 どちらのテンプレートも CSS の Lint は対象外のようです。 Vue 公式のツーリングガイドの Linting セクション でも案内されているのは eslint-plugin-vue による JavaScript/テンプレートの Lint だけで、CSS/Style の Lint には触れていません。 CSS の Lint が必要なら、これまで同様 Stylelint と Vue プラグインを別途入れることになりそうです。 型チェックの違い pnpm type-check はどちらも vue-tsc --build で同じです。 Vite+ 側は vite.config.ts に typeAware: true （型認識 Lint ルールの有効化）と typeCheck: true （tsgo 経由の型チェック同時実行）の設定があります。 ただし前述の通り tsgo は .vue を読めないため、 .vue の型チェックには引き続き vue-tsc が必要です。 テスト どちらも Vitest です。 Vite+ ではインポートパスが 'vitest' から 'vite-plus/test' に、コマンドが vitest から vp test に変わりますが、設定内容やテストの書き方は同じです。 Formatter 比較: Oxfmt vs Prettier Oxfmt は Prettier との出力互換を謳っており、JavaScript/TypeScript の conformance test を 100% パスしています。 Vue SFC のフォーマット対応 <template> と <style> もフォーマットできるのか気になったため、わざと崩した Vue ファイルで試しました。 <!-- フォーマット前 --> < template >< div class = "foo" >< p v-if= "true" > hello </ p ></ div ></ template > < style scoped>.foo{ color : red ; font-size : 16px ; display : flex ; justify-content : center }</ style > <!-- フォーマット後（Oxfmt / Prettier どちらも同一の結果） --> < template > < div class = "foo" >< p v-if= "true" > hello </ p ></ div > </ template > < style scoped> .foo { color : red ; font-size : 16px ; display : flex ; justify-content : center ; } </ style > Oxfmt でも Prettier でも <template> と <style> をフォーマットでき、出力結果は同一でした。乗り換えて問題なさそうです。 公式ドキュメント によると Prettier の約30倍の速度とのこと。小規模プロジェクトだと体感差はありませんが、大規模プロジェクトでは差が出そうです。 全体比較表 項目 Vite+ ( vp create vue ) create-vue ( pnpm create vue@latest ) Linter Oxlint ( vp lint ) + ESLint Oxlint + ESLint ESLint 設定 同一 （ただし eslint-plugin-oxlint の修正が必要） 同一 Vue template lint ESLint 経由で対応 ESLint 経由で対応 CSS lint なし なし typeCheck tsgo が .vue を読めず実質使えない なし テスト Vitest ( vp test ) Vitest Formatter Oxfmt ( vp fmt ) Prettier (Oxfmtも案内される) ビルド Vite ( vp build ) Vite ( vite build ) 設定の統合 vite.config.ts に集約 個別ファイル ( .oxlintrc.json , .prettierrc.json ) Pre-commit フック .vite-hooks/pre-commit → vp staged なし (要別途設定) まとめ vp create vue と pnpm create vue@latest で生成されるプロジェクトを比較した結果をまとめます。 Linter Oxlint は .vue の <script> ブロックしか Lint できない <template> や <style> は対象外 Vue template の Lint には引き続き ESLint（eslint-plugin-vue）が必要 これは Vite+ でも create-vue でも同じ create-vue は Oxlint をデフォルトで同梱している ESLint 連携の落とし穴 Vite+ テンプレートでは .oxlintrc.json がマージ後に削除されることへの対応が無く、ルール重複の無効化が壊れる vite.config.ts の lint ブロックを import するか、 .oxlintrc.json に一本化することで対処できる Lint 実行 どちらも Oxlint → ESLint の直列実行 型チェック typeCheck: true は Vue プロジェクトでは実質使えない tsgo が .vue をインポートした .ts ファイルで TS2307 エラーを出すため .vue の型チェックには引き続き vue-tsc が必要 Formatter Oxfmt は Prettier と同一の出力 <template> / <style> もフォーマットできる Prettier からの乗り換えで困ることはなさそう CSS Lint どちらのテンプレートも対象外 必要なら Stylelint を別途入れることになる Vite+ を選ぶメリットは Linter/Formatter 単体の差分よりも、 vite.config.ts への設定一元化と vp コマンドによる統合にありそうでした。 Vue 固有の Lint や型チェックについてはまだ ESLint + vue-tsc 頼りなため、Oxlint の Vue テンプレート対応や tsgo の .vue サポートが整えば、設定が楽になりそうです。 今回はテンプレートの設定比較だけでしたが、気になるのはやはり実際のプロジェクトでの速度差です。 次回は Vue ファイルが約2000個存在する駅メモ！のフロントエンドで、Lint/Format/ビルドがどれくらい速くなるか実測してみます。お楽しみに！

2026 年 1 月 26 日週、私たちは ラバ祭り を祝いました。これは、旧正月まで残りわずかであることを告げる中国暦の伝統的な祝日です。ラバ祭りは、中国の多くの人々にとって振り返りと準備にまつわる祝日であり、今年の出来事をまとめ上げ、未来に目を向けます。 2026 年 2 月 9 日週は、春の始まりであり、二十四節気最初の節季である 立春 です。中国の伝統では、春は成長が始まり、新しい節目がやってくる季節として捉えられることがよくあります。「一年の計は春にあり」ということわざもあり、春が自分の方向を定め、新たなスタートを切るときだという考え方を反映しています。 2026 年 1 月 26 日週のリリース 2026 年 2 月 2 日週私が注目したリリースをご紹介します。 Amazon Bedrock がサーバーサイドツールと拡張されたプロンプトキャッシュでエージェントワークフローのサポートを強化 – Amazon Bedrock に、開発者が AI エージェントを構築して運用する方法を改善する 2 つのアップデートが導入されました。 Responses API がサーバーサイドツールの使用をサポート するようになりました。このため、エージェントは AWS のセキュリティ境界内でウェブ検索、コード実行、データベース更新などのアクションを実行できます。 Bedrock には、プロンプトキャッシュのための 1 時間有効期限 (TTL) オプションも追加されました 。この延長は、長時間にわたるマルチターンエージェントワークフローのパフォーマンス向上とコスト削減に役立ちます。Amazon Bedrock では、OpenAI GPT OSS 20B および 120B モデルで サーバーサイドツールを利用でき、1 時間のプロンプトキャッシュ TTL は 一部の Anthropic Claude モデルに一般提供されています。 Amazon SageMaker Unified Studio が AWS PrivateLink を用いたプライベート VPC 接続を追加 – Amazon SageMaker Unified Studio が AWS PrivateLink のサポートを開始しました。このサポートにより、VPC と SageMaker Unified Studio 間のプライベート接続が提供されるため、カスタマーデータをパブリックインターネット経由でルーティングする必要はありません。VPC にオンボードされた SageMaker サービスエンドポイントを使用すると、データトラフィックが AWS ネットワーク内に留まり、IAM ポリシーによって制御されるため、より厳格なセキュリティとコンプライアンス要件をサポートできます。 Amazon S3 がデータ移動を必要としないオブジェクト暗号化の変更をサポート – Amazon S3 では、データを移動または再アップロードしなくても、既存の暗号化されたオブジェクトのサーバー側暗号化タイプを変更できるようになりました。 UpdateObjectEncryption API を使用することで、オブジェクトプロパティとライフサイクル適合性を維持しながら、SSE-S3 から SSE-KMS への切り替え、お客様管理の AWS Key Management Service (AWS KMS) キーのローテーション、または S3 バッチオペレーションによるバケット全体での暗号化の大規模な標準化を行うことができます。 Amazon Keyspaces が予測可能な高スループットワークロードのためのテーブルの事前ウォーミングを導入 – Amazon Keyspaces (Apache Cassandra 向け) がテーブルの事前ウォーミングをサポートするようになりました。これは、ウォームスループットのレベルを事前に設定して、テーブルが大量の読み取りおよび書き込みトラフィックを瞬時に処理できるようにするため、コールドスタートによる遅延が発生しません。事前ウォーミングは、製品のリリースやセールスイベントなど、トラフィックが急激に増加するときのスロットリングの軽減に役立ち、マルチリージョンテーブルを含めたオンデマンドキャパシティモードとプロビジョニングキャパシティーモードの両方で動作します。この機能は、一貫的な低レイテンシーパフォーマンスをサポートしながら、スループットの準備状態をより細かく制御できるようにします。 Amazon DynamoDB MRSC グローバルテーブルが AWS Fault Injection Service と統合 – Amazon DynamoDB マルチリージョン強整合性 (MRSC) グローバルテーブルが AWS Fault Injection Service に統合されました。この統合を利用することで、強力な整合性を備えたマルチリージョンワークロードのためにリージョン障害をシミュレートし、レプリケーション動作をテストして、アプリケーションのレジリエンシーを検証できます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Verified Access を使用したマルチアカウント AWS 環境でのゼロトラストアクセスの構築 – この記事では、一元化された共有サービスアーキテクチャに AWS Verified Access を実装する方法を詳しく説明します。AWS IAM アイデンティティセンターおよび AWS Resource Access Manager (AWS RAM) と統合して、アプリケーション層にゼロトラストアクセスコントロールを適用し、マルチアカウント AWS 環境全体で運用オーバーヘッドを削減する方法を紹介します。 Amazon EventBridge がイベントのペイロードサイズを 1 MB に増加 – Amazon EventBridge が 最大 1 MB のイベントペイロードをサポートするようになりました。これは、以前の 256 KB 上限からの増加となります。この更新は、イベント駆動型アーキテクチャが、ペイロードを分割したり外部ストレージに依存したりすることなく、単一のイベント内でより充実したコンテキスト (複雑な JSON 構造、テレメトリデータ、機械学習出力、生成 AI 出力など) を確保できるようにします。 AWS MCP サーバーがデプロイエージェント SOP を追加 (プレビュー) – AWS がデプロイ SOP (Standard Operating Procedure) を導入しました。この SOP では、AI エージェントが Kiro、Cursor、Claude Code といった MCP 互換の統合開発環境 (IDE) やコマンドラインインターフェイス (CLI) での単一の自然言語プロンプトから AWS にウェブアプリケーションをデプロイできます。エージェントは、AWS Cloud Development Kit (AWS CDK) インフラストラクチャを生成し、AWS CloudFormation スタックをデプロイして、AWS ベストプラクティスに従った継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローを設定します。プレビューでは、React、Vue.js、Angular、Next.js などのフレームワークがサポートされています。 AWS Network Firewall がウェブカテゴリフィルタリングによる生成 AI トラフィック可視性を追加 – AWS Network Firewall が、定義済みのウェブカテゴリを通じて生成 AI アプリケーショントラフィックの可視性を提供するようになりました。ファイアウォールルール内でこれらのカテゴリを直接使用することで、生成 AI ツールやその他ウェブサービスへのアクセスを制御できます。TLS インスペクションと組み合わせると、カテゴリベースのフィルタリングを完全な URL レベルで適用できます。 AWS Lambda が Kafka イベントソースマッピングのオブザーバビリティを強化 – AWS Lambda に、Kafka イベントソースマッピングのための強化されたオブザーバビリティが導入されました。これは、イベントポーリング設定、スケーリング動作、イベント処理状態を監視するための Amazon CloudWatch Logs とメトリクスを提供します。この更新により、Kafka ベースの Lambda ワークロードの可視性が向上し、チームが設定上の問題、許可エラー、および関数の失敗をより効率的に診断できるようになります。この機能は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) イベントソースとセルフマネージド Apache Kafka イベントソースの両方をサポートします。 AWS CloudFormation 2025 年の振り返り – 1 年を振り返るこの記事では、2025 年に行われた CloudFormation 更新が紹介されており、早期検証、より安全なデプロイ、改善された開発者ワークフローに焦点を当てています。改善されたトラブルシューティング、ドリフト認識変更セット、スタックリファクタリング、StackSets 更新、および CloudFormation 言語サーバーや Infrastructure as Code (IaC) MCP サーバーを含めた新しい IDE と AI 支援ツールなどの機能強化が取り上げられています。 今後の AWS イベント カレンダーを確認して、近日開催予定のイベントにサインアップしましょう。 AWS Community Day Romania (2026 年 4 月 23～24 日) – このコミュニティ主導の AWS イベントでは、AWS ヒーロー、ソリューションアーキテクト、および業界エキスパートによる 10 を超えるプロフェッショナルセッションのために、開発者、アーキテクト、起業家、学生が一堂に会します。参加者は、エキスパートによるテクニカルトーク、世界的なカンファレンスで経験を積んだ講演者からのインサイト、参加者だけのネットワーキングブレイクでつながる機会を期待できます。これらはすべて、コラボレーションとコミュニティエンゲージメントをサポートするために設計されたハイクラスな会場で行われます。 このイベント外でもつながりを維持する方法をお探しの場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学び、構築し、つながりましょう。 2026 年 2 月 9 日週の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

クロスイノベーション本部、新卒1年目の大岡叡です。 今回は、1月29日にプレビュー公開されたAWS Deployment SOPsを使ってみたので、その内容を報告します。 AWS Deployment SOPsを使ってみた結果、簡単なプロンプトを一度与えるだけで静的Webサイトをデプロイでき、CodePipelineのCI/CDについても簡単に構築することができました。この検証を通じて、非エンジニアがインフラ構築をして簡単なアプリケーションのデプロイを行う日も遠くないのではないかと思いました。 AWS MCP Serverとは AWS Knowledge Tools AWS API Tools Agent SOP Tools AWS Deployment SOPsとは 検証の前提 検証1：Next.jsアプリケーションのデプロイ 検証内容 実装してくれたCDKのコード Deployment SOPsなしの場合 検証2：CodePipelineのセットアップ 検証内容 実装してくれたCDKのコード まとめ 参考文献 AWS MCP Serverとは AWS Deployment SOPsの説明をするうえで前提となる AWS MCP Server について説明します。AWS MCP Serverは8つのツールを提供しており、 AWS Knowledge Tools 、 AWS API Tools 、 Agent SOP Tools の3つのカテゴリに分類されています。 AWS Knowledge Tools aws___search_documentation ：APIリファレンス・ベストプラクティス・サービスガイドを含む、すべてのAWSドキュメントを横断的に検索して関連情報を見つける。 aws___read_documentation ：AWSドキュメントページを取得し、AIアシスタントが利用しやすいようにMarkdown形式に変換する。 aws___recommend ：AWSドキュメントページに関連するトピックや、他のユーザーがよく一緒に閲覧しているコンテンツに基づいて、おすすめのドキュメントページを取得する。 aws___list_regions ：リージョンID(例：ap-northeast-1)と名称(例：Asia Pacific (Tokyo))のペアの一覧を取得する。 aws___get_regional_availability ：サービス、機能、SDK API、CloudFormationリソースについて、AWSリージョンごとの利用可否情報を確認する。 AWS API Tools aws___call_aws ：AWS APIの呼び出しを実行する。 aws___suggest_aws_commands ：関連するAWS APIの説明と構文ヘルプを取得する。AIモデルの学習データに含まれていない可能性がある、新しくリリースされたAPIにも対応できる。 Agent SOP Tools aws___retrieve_agent_sop ：Agent SOPsの検索または特定のSOPsの詳細情報の取得をする。 💡 Agent SOPsとは Agent SOPsとは、Claude CodeのようなAIアシスタントがAWS関連のタスクを行う際の標準作業手順書（Standard Operating Procedures）のことです。例えば、以下のようなSOPが用意されています。 SOP名 説明 create-secrets-using-best-practices ローテーション機能とKMSを備えたSecrets Managerによるシークレット作成 create-budget アラート機能付きのAWS Budgets作成 setup_cloudwatch_alarm_notifications SNS経由でのCloudWatchアラーム通知セットアップ application-failure-troubleshooting CloudWatchログを分析してアプリケーション障害をデバッグ AWS Deployment SOPsとは AWS Deployment SOPsは、 aws___retrieve_agent_sop のツールが取得するデプロイ用のSOPのことです。 以下の4つのSOPがDeployment SOPsです。 SOP名 説明 deploy-webapp アプリケーションがDeployment SOPsでサポートされているものか確認し、適切なDeployment SOPを選択する。 deploy-frontend-app AWS CDKのコードを生成し、アプリケーションをデプロイした後、デプロイしたWebアプリのURLを提供する。 setup-pipeline AWS CodePipelineを使用してパイプラインを作成し、GitHubに変更がプッシュされると自動的にアプリケーションの検証とデプロイを行う。 document-deployment デプロイに関するドキュメントを生成し、進捗を管理する。 Deployment SOPsがサポートしているアプリケーションタイプは以下のとおりです。 SPA：React, Vue, Angular, SvelteKit SSG：Next.js (static export), Nuxt, Gatsby, Hugo, Jekyll, Docusaurus, Astro, Eleventy Static websites そして、Deployment SOPsは2つのユースケース「AWSへのアプリケーションのデプロイ」と「CodePipelineのセットアップ」をサポートしています。今回はこの2つのユースケースを実際に試してみました。 検証の前提 今回はコーディングエージェントとしてClaude Codeを使用しました。 Skills等のカスタマイズ系のものは使用しないようにしました。 AWS CLI(認証情報設定済み)やGit CLIなどの必要なツールはインストール済みです。 プロジェクトのルートで、以下のような .mcp.json を配置しました。 { " mcpServers ": { " aws-mcp ": { " command ": " uvx ", " args ": [ " mcp-proxy-for-aws@latest ", " https://aws-mcp.us-east-1.api.aws/mcp " ] } } } あらかじめ以下のようなTODOアプリケーションをNext.jsの静的エクスポートで実装しました。これはプロジェクトのルートディレクトリにtodo-appというディレクトリ名で配置しました。 検証1：Next.jsアプリケーションのデプロイ Claude Codeの挙動ベースで検証内容を報告します。結果としては、簡単なプロンプトを一度与えるだけでCloudFront + S3の構成を構築してデプロイを行い、CloudFrontのURLを共有してくれました。 検証内容 最初に「AWS MCPのAWS Deployment SOPsを用いて、todo-appをAWSにデプロイしてください。」というプロンプトをClaude Codeに投げました（ちなみに、この検証で投げたプロンプトはこれだけです）。すると、AWS MCP Serverの aws___retrieve_agent_sop を用いてdeploy-webappのSOPを取得してきて、アプリケーションがDeployment SOPsでサポートされているタイプか分析してくれました。 アプリケーションのファイルの読み込みが完了した後、AWS MCP Serverの aws___retrieve_agent_sop を用いてdeploy-frontend-appのSOPを取得してきてくれました。そして、Next.jsの静的エクスポートはデプロイ可能ということで、デプロイ開始宣言をしてくれました。 続いて、 DEPLOYMENT_PLAN.md を生成してくれました。これ以降はこのプランに従って自律的に実装を進めてくれました。 --- sop_name: deploy-frontend-app, setup-pipeline repo_name: aws-deployment-sops-test app_name: TodoApp app_type: Frontend Application (Next.js Static Export) branch: main created: 2026-02-01 last_updated: 2026-02-01 --- # Deployment Plan: TodoApp Coding Agents should follow this Deployment Plan, and validate previous progress if picking up the Deployment in a new coding session. **IMPORTANT**: Update this plan after EACH step completes. Mark the step `[x]` and update `last_updated` timestamp. ## Phase 1: Gather Context and Configure - [x] Step 0: Inform User of Execution Flow - [x] Step 1: Create Deployment Plan - [] Step 2: Create Deploy Branch - [] Step 3: Detect Build Configuration - [] Step 4: Validate Prerequisites - [] Step 5: Revisit Deployment Plan ## Phase 2: Build CDK Infrastructure - [] Step 6: Initialize CDK Foundation - [] Step 7: Generate CDK Stack - [] Step 8: Create Deployment Script - [] Step 9: Validate CDK Synth ## Phase 3: Deploy and Validate - [] Step 10: Execute CDK Deployment - [] Step 11: Validate CloudFormation Stack ## Phase 4: Update Documentation - [] Step 12: Finalize Deployment Plan - [] Step 13: Update README.md そして、最終的にCloudFrontのURLを提供してくれました。このURLをクリックしたら実際にデプロイされたアプリケーションが正常に動作していることを確認できました。 実装してくれたCDKのコード 実際にClaude Codeが生成してくれたCDKのコードを以下に示します。このコードによって、CloudFront(Distribution, CloudFront Function)、S3(Webサイト用)、S3(CloudFrontアクセスログ用)、S3(S3アクセスログ用)などが作成されます。 import * as cdk from "aws-cdk-lib" ; import * as cloudfront from "aws-cdk-lib/aws-cloudfront" ; import * as s3deploy from "aws-cdk-lib/aws-s3-deployment" ; import { CloudFrontToS3 } from "@aws-solutions-constructs/aws-cloudfront-s3" ; import { Construct } from "constructs" ; export interface FrontendStackProps extends cdk.StackProps { environment : string ; buildOutputPath : string ; } export class FrontendStack extends cdk.Stack { public readonly distributionDomainName : string ; public readonly bucketName : string ; constructor ( scope : Construct , id : string , props : FrontendStackProps ) { super (scope, id, props); const { environment , buildOutputPath } = props; const isProd = environment === "prod" ; const removalPolicy = isProd ? cdk.RemovalPolicy.RETAIN : cdk.RemovalPolicy.DESTROY; // CSP via CloudFront Function - permissive policy for 3rd-party CDNs/APIs const cspFunction = new cloudfront.Function( this , "CspFunction" , { runtime : cloudfront.FunctionRuntime.JS_2_0, code : cloudfront.FunctionCode.fromInline( ` function handler(event) { var response = event.response; response.headers['content-security-policy'] = { value: "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: blob:; style-src 'self' 'unsafe-inline' https:; font-src 'self' https: data:; img-src 'self' https: data: blob:; connect-src 'self' https: wss:; frame-src 'self' https:; media-src 'self' https: blob:; worker-src 'self' https: blob:; object-src 'self' https:; manifest-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'" }; return response; } ` ), comment : "Adds Content-Security-Policy header" , } ); // Extension rewrite function for Next.js static export (trailingSlash: false) // Rewrites /path to /path.html const extensionRewriteFunction = new cloudfront.Function( this , "ExtensionRewriteFunction" , { runtime : cloudfront.FunctionRuntime.JS_2_0, code : cloudfront.FunctionCode.fromInline( ` function handler(event) { var request = event.request; var uri = request.uri; if (!uri.includes('.') && uri !== '/') { request.uri = uri + '.html'; } return request; } ` ), comment : "Rewrites /path to /path.html for Next.js static export" , } ); const cloudfrontToS3 = new CloudFrontToS3( this , "CFToS3" , { bucketProps : { removalPolicy , autoDeleteObjects : !isProd, versioned : false , enforceSSL : true , } , loggingBucketProps : { removalPolicy , autoDeleteObjects : !isProd, lifecycleRules : [{ id : "DeleteOldLogs" , enabled : true , expiration : isProd ? cdk.Duration.days( 3650 ) : cdk.Duration.days( 7 ) }] , enforceSSL : true , } , cloudFrontLoggingBucketProps : { removalPolicy , autoDeleteObjects : !isProd, lifecycleRules : [{ id : "DeleteOldLogs" , enabled : true , expiration : isProd ? cdk.Duration.days( 3650 ) : cdk.Duration.days( 7 ) }] , enforceSSL : true , } , insertHttpSecurityHeaders : false , cloudFrontDistributionProps : { comment : ` ${ id } - ${ environment } ` , defaultRootObject : "index.html" , defaultBehavior : { responseHeadersPolicy : cloudfront.ResponseHeadersPolicy.SECURITY_HEADERS, functionAssociations : [ { function : cspFunction, eventType : cloudfront.FunctionEventType.VIEWER_RESPONSE, } , { function : extensionRewriteFunction, eventType : cloudfront.FunctionEventType.VIEWER_REQUEST, } , ] , } , priceClass : cloudfront.PriceClass.PRICE_CLASS_100, enableIpv6 : true , httpVersion : cloudfront.HttpVersion.HTTP2_AND_3, minimumProtocolVersion : cloudfront.SecurityPolicyProtocol.TLS_V1_2_2021, } , } ); const websiteBucket = cloudfrontToS3.s3Bucket!; const distribution = cloudfrontToS3.cloudFrontWebDistribution; new s3deploy.BucketDeployment( this , "DeployWebsite" , { sources : [ s3deploy.Source.asset(buildOutputPath) ] , destinationBucket : websiteBucket, distribution , distributionPaths : [ "/*" ] , prune : true , memoryLimit : 512 , } ); this .distributionDomainName = distribution.distributionDomainName; this .bucketName = websiteBucket.bucketName; // Outputs new cdk.CfnOutput( this , "WebsiteURL" , { value : `https:// ${ distribution.distributionDomainName } ` , description : "CloudFront distribution URL" , exportName : ` ${ id } -WebsiteURL` , } ); new cdk.CfnOutput( this , "BucketName" , { value : websiteBucket.bucketName, description : "S3 bucket name" , exportName : ` ${ id } -BucketName` , } ); new cdk.CfnOutput( this , "DistributionId" , { value : distribution.distributionId, description : "CloudFront distribution ID" , exportName : ` ${ id } -DistributionId` , } ); new cdk.CfnOutput( this , "DistributionDomainName" , { value : distribution.distributionDomainName, description : "CloudFront domain name" , exportName : ` ${ id } -DistributionDomain` , } ); if (cloudfrontToS3.s3LoggingBucket) { new cdk.CfnOutput( this , "S3LogBucketName" , { value : cloudfrontToS3.s3LoggingBucket.bucketName, description : "Bucket for S3 access logs" , exportName : ` ${ id } -S3LogBucket` , } ); } if (cloudfrontToS3.cloudFrontLoggingBucket) { new cdk.CfnOutput( this , "CloudFrontLogBucketName" , { value : cloudfrontToS3.cloudFrontLoggingBucket.bucketName, description : "Bucket for CloudFront access logs" , exportName : ` ${ id } -CloudFrontLogBucket` , } ); } cdk.Tags.of( this ). add ( "Stack" , "Frontend" ); cdk.Tags.of( this ). add ( "aws-mcp:deploy:sop" , "deploy-frontend-app" ); cdk.Tags.of(cloudfrontToS3). add ( "Stack" , "Frontend" ); cdk.Tags.of(cloudfrontToS3). add ( "aws-mcp:deploy:sop" , "deploy-frontend-app" ); } } 以上より、「AWS MCPのAWS Deployment SOPsを用いて、todo-appをAWSにデプロイしてください。」と一言お願いをすれば、それなりの構成でインフラを構築してくれて、アプリケーションをデプロイできることを確認できました。これなら非エンジニアの方でも簡単かつ安全にアプリケーションをデプロイできるのではないでしょうか。 Deployment SOPsなしの場合 Deployment SOPsを使用せずにClaude Codeに「todo-appをAWSにデプロイしてください。」とお願いしたらどうなるか試してみました。ここでは非エンジニアがデプロイする想定で、条件などを一切与えずにお願いしました。こちらも検証1と同様、Claudeの指示に基本従う方針で進めました。 最初にdeploy方法の選択を迫られました。RecommendedのAWS Amplifyを選択しました。 デプロイを進めてくれて、最終的にAmplifyのURLを表示してくれました。 しかし、このURLにアクセスしたところ、以下のようなWebページでした。 Amplifyへのデプロイ手順はCloudFront + S3構成と比べて複雑ではないものの、単に「デプロイして」と依頼するだけでは、現状のClaude Codeでは自律的にタスクを完遂することが難しいようです。 検証2：CodePipelineのセットアップ Claude Codeの挙動ベースに検証内容を報告します。CodePipelineが構築され、GitHubにプッシュするだけで変更が自動的にデプロイされる仕組みが整いました。 検証内容 最初に「AWS MCPのAWS Deployment SOPsを用いて、CodePipelineをセットアップしてください。」というプロンプトをClaude Codeに投げました。すると、AWS MCP Serverの aws___retrieve_agent_sop を用いてsetup-pipelineのSOPを取得してきて、CodePipelineのセットアップを開始してくれました。 次に以下のような確認をされました。lintエラーの修正だけお願いしておきました。 検証1と同様にDEPLOYMENT_PLAN.mdを更新しながらCDKのコード実装など色々やってくれた後に、以下の認証をお願いされました。これは手順通り対応しました。 その後、パイプラインのデプロイなど色々やってくれてタスクが完了しました。 CodePipelineの動作を確認するために以下のようにh1の中身に変更を加えて、deploy-to-awsブランチにプッシュしたところ、CodePipelineがトリガーされてビルド→デプロイが実行され、Webページに変更内容が反映されました。 実装してくれたCDKのコード 実際にClaude Codeが生成してくれたCDKのコードを以下に示します。CodePipeline、CodeBuildプロジェクト、S3バケット（アーティファクト用）が構築されます。 import * as cdk from "aws-cdk-lib" ; import * as codebuild from "aws-cdk-lib/aws-codebuild" ; import * as codepipeline from "aws-cdk-lib/aws-codepipeline" ; import * as pipelines from "aws-cdk-lib/pipelines" ; import { Construct } from "constructs" ; import { FrontendStack } from "./frontend-stack" ; export interface PipelineStackProps extends cdk.StackProps { codeConnectionArn : string ; repositoryName : string ; branchName : string ; } export class PipelineStack extends cdk.Stack { public readonly pipeline : pipelines.CodePipeline ; constructor ( scope : Construct , id : string , props : PipelineStackProps ) { super (scope, id, props); const source = pipelines.CodePipelineSource. connection ( props.repositoryName, props.branchName, { connectionArn : props.codeConnectionArn, triggerOnPush : true , } ); const synth = new pipelines.ShellStep( "Synth" , { input : source, commands : [ // Install dependencies "(cd todo-app && npm install)" , "(cd infra && npm install)" , // Quality checks "(cd todo-app && npm run lint)" , // Secret scanning "npx -y @secretlint/quick-start '**/*'" , // Build frontend "(cd todo-app && npm run build)" , // CDK synth "cd infra" , "npx tsc" , `npx -y cdk synth --context codeConnectionArn=" ${ props.codeConnectionArn } " --context repositoryName=" ${ props.repositoryName } " --context branchName=" ${ props.branchName } "` , ] , primaryOutputDirectory : "infra/cdk.out" } ); this .pipeline = new pipelines.CodePipeline( this , "Pipeline" , { pipelineName : "TodoAppPipeline" , selfMutation : true , pipelineType : codepipeline.PipelineType.V2, synth , synthCodeBuildDefaults : { buildEnvironment : { computeType : codebuild.ComputeType.MEDIUM, buildImage : codebuild.LinuxBuildImage.STANDARD_7_0 } , partialBuildSpec : codebuild.BuildSpec.fromObject( { version : "0.2" , phases : { install : { "runtime-versions" : { nodejs : "latest" , } , } , } , } ), } , } ); // Deploy stage for production const deployStage = new cdk.Stage( this , "Deploy" , { env : { account : this .account, region : this . region } , } ); new FrontendStack(deployStage, "TodoAppFrontend-prod" , { stackName : "TodoAppFrontend-prod" , environment : "prod" , buildOutputPath : "../todo-app/out" , } ); this .pipeline.addStage(deployStage); // Build pipeline to enable property access this .pipeline.buildPipeline(); cdk.Tags.of( this ). add ( "Stack" , "Pipeline" ); cdk.Tags.of( this ). add ( "aws-mcp:deploy:sop" , "setup-pipeline" ); new cdk.CfnOutput( this , "PipelineName" , { value : "TodoAppPipeline" , description : "CodePipeline Name" , } ); new cdk.CfnOutput( this , "PipelineArn" , { value : this .pipeline.pipeline.pipelineArn, description : "CodePipeline ARN" , } ); } } まとめ AWS Deployment SOPsを用いて、静的エクスポートしたNext.jsアプリケーションをデプロイしたり、CodePipelineのセットアップを行いました。特に問題なくAIがすべての作業を完了してくれたことは驚きでした。近い将来、非エンジニアがインフラ構築をしてアプリデプロイをする日が来るのではないかと期待に胸が膨らみました。 最後までお読みいただきありがとうございました！ 参考文献 https://docs.aws.amazon.com/aws-mcp/latest/userguide/what-is-mcp-server.html https://docs.aws.amazon.com/aws-mcp/latest/userguide/getting-started-aws-mcp-server.html https://docs.aws.amazon.com/aws-mcp/latest/userguide/understanding-mcp-server-tools.html https://docs.aws.amazon.com/aws-mcp/latest/userguide/agent-sops.html https://docs.aws.amazon.com/aws-mcp/latest/userguide/agent-sops-deployment.html https://aws.amazon.com/jp/about-aws/whats-new/2025/01/aws-announces-deployment-agent-sops-in-aws-mcp-server-preview/ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ooka.toru レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）