2026 年 10 月 12 日、コードをイベントハンドラーに書き直さずに標準の HTTP ウェブアプリケーションを Lambda で実行できる新しいフォームファクターである AWS Lambda Web Functions を発表しました。Express、Hono、Fastify、Next.js、または任意の Node.js フレームワークで構築された標準のポートリスニングサーバーを 1 つのコマンドでデプロイできます。Lambda は、スケーリング、マルチリージョン分布、アクティブな CPU 請求を自動的に処理します。アダプター、管理するインフラストラクチャ、フレームワークのロックインはありません。 今回の発表により、AWS Lambda は 3 つの異なるフォームファクターを提供するようになりました。各フォームファクターは同じ Firecracker 分離テクノロジーに基づいて構築され、異なるプログラミングモデル向けに設計されています。 Lambda Event Functions は、すでに Lambda 関数として知られているものです。イベント駆動型の単一同時ハンドラーモデルとウォールクロック課金方式を採用しています。「イベント関数」という名前は、そのプログラミングモデル、つまり関数がイベントを受け取って処理し、応答を返すということを強調するためです。イベント駆動型プログラミングモデルは、イベント処理、キューコンシューマー、および他の AWS サービスによってトリガーされる呼び出しに最適です。 Lambda Web Functions は、マルチコンカレント実行とアクティブ CPU 課金が可能な HTTP ネイティブプログラミングモデルを使用しています。コードはポートでリッスンし、標準の HTTP リクエストを処理します。このプログラミングモデルは、複数の同時リクエストと I/O の多い処理が標準となっているウェブアプリケーション、API バックエンド、インタラクティブな HTTP ワークロードに最適です。 Lambda MicroVMは 、信頼できないコードやユーザーが生成したコードを実行するための顧客管理のライフサイクルを備えた、分離されたステートフルなサンドボックス環境を提供します。 この3つは互いに補完し合っています。アプリケーションでは、非同期バックエンド処理にはイベント関数、ユーザー向け API とサーバー側レンダリングレイヤーには Web Functions、インタラクティブなコード実行機能には MicroVM を使用する場合があります。これらはすべて同じ AWS アカウント内で同じ運用モデルを共有します。 なぜウェブファンクションなのか 最新のウェブアプリケーションでは、開発者が標準フレームワークを自由に使用して迅速に反復できるようにしながら、高速で一貫した応答時間で世界中のユーザーにサービスを提供する必要があります。今日これを構築するには、通常、複数のインフラストラクチャコンポーネントを組み立て、マルチリージョン展開を構成し、レイテンシーベースのルーティングを設定し、I/O待機による支払いを回避するための請求モデルのチューニングが必要です。開発者は、すでに所有しているHTTPサーバーをデプロイするのではなく、特定のコンピューティングモデルに合わせてアプリケーションコードを調整していることに気付くことがよくあります。 Lambda ウェブ関数はこの複雑さを解消します。各実行環境は複数のリクエストを同時に処理します（環境ごとに最大128の同時リクエスト）。つまり、各リクエストを新しいリクエストにマッピングする代わりに、大量の受信トラフィックがウォーム環境を共有できます。Web Functions はコードが使用する CPU 時間を計測するため、データベースクエリや API 呼び出しの待機時間が CPU をほとんど消費しません。メモリは、実行環境が存在する限り計測されます。サーバーサイドレンダリング、API バックエンド、トークン応答をストリーミングする AI 推論エンドポイントなど、I/O の多いウェブワークロードでは、これによりコンピューティングコストを削減できます。 試してみましょう はじめに、単純な Express.js サーバーを作成しました。これは node index.js を使用してローカルで実行するのと同じコードで 、Lambda 固有のアダプターやラッパーは必要ありません。 「エクスプレス」からエクスプレスをインポート; const アプリ = エクスプレス (); const [ホスト, ポート] = process.env.aws_lambda_http_Endpoint.split (':'); app.get ('/', (req, res) => { res.json ({メッセージ:'ラムダウェブ関数からこんにちは!'}); }); app.listen (ポート、ホスト、() => { console.log(`Server running on port ${port}`); }); ローカルでの実行との唯一の違いは、 AWS_LAMBDA_HTTP_ENDPOINT 環境変数です。Lambda はこの変数を、サーバーがリッスンする必要があるホストとポートに設定します。ローカルで実行するには、自分で設定します。たとえば、 AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js のように設定します。 コードの準備ができたら、 AWS コマンドラインインターフェイス (AWS CLI) を使用してデプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app 1 つのコマンド。事前のリソース設定はありません。CLIはソースをバンドルし、Webファンクションを作成し、最初のリビジョンを公開し、Webファンクションエンドポイントをアタッチして、1分以内にライブHTTPSURLを返しました。 リビジョンは、デプロイしたコードの不変のスナップショットです。エンドポイントは、トラフィックをリビジョンにルーティングしたり、トラフィックをリビジョン間で分割したりする HTTPS URL です。これらは、反復作業を行い、新しいコードへトラフィックをどのように移行させるかを制御するために使用するリソースです。 私はすぐにそれをテストしました： <shard-id>$ curl https://<domain-id>. .lambda-web.us-east-1.on.aws/ {「メッセージ」:「Lambda Web Functionsからこんにちは!」} 次に、自分のアプリケーションがヨーロッパとアジアのユーザーに低レイテンシーでサービスを提供できるようにしたかったのです。複数のリージョンで再デプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app \ --regions us-east-1,eu-west-1,ap-northeast-1 Lambda Web Functions は私のコードを 3 つのリージョンすべてに複製し、レイテンシーベースのルーティングを自動的に設定しました。これで、各リクエストは、ベストエフォート方式で 1 つのグローバル URL ( <domain-id>.lambda-web.global.on.aws ) を介して、呼び出し側のレイテンシーが最も低いリージョンにルーティングされるようになりました。。 コードを更新して同じデプロイコマンドを再度実行すると、CLIは既存の関数を検出し、新しいリビジョンをアップロードして、エンドポイントにそのリビジョンを指定しました。コード変更から本番稼働までの合計所要時間: 秒。 より段階的なロールアウトが必要なプロダクションワークフローでは、1 回の API 呼び出しでリビジョン間でトラフィックをシフトできます。 aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name dev \ --auto-deployment-mode Disabled \ --revision-weights 『[{「revisionId」: 「<current-revision-id>」, 「weight」: 90}, {「revisionId」: 「<new-revision-id>」, 「weight」: 10}]』 これにより、エンドポイントトラフィックの90％が現在のリビジョンに、10％が新しいリビジョンに送られるため、追加のツールなしでカナリアデプロイメントを行うことができます。 Amazon CloudFront と併用するとさらに便利に 静的コンテンツと動的コンテンツを組み合わせるアプリケーションの場合、ウェブ関数は Amazon CloudFront と併用するとうまく機能します。ウェブ関数エンドポイントを CloudFront ディストリビューションのオリジンとして選択できます。静的アセットはキャッシュから提供され、動的リクエストはWeb Functionにルーティングされるため、動的部分のサーバーレスコンピューティングで静的コンテンツのCDNパフォーマンスを実現できます。 ウェブ機能により、CloudFront のプライベートオリジンエクスペリエンスが向上します。 今回の起動では、代わりに CloudFront オリジンアクセスコントロール (OAC) をウェブ関数エンドポイントにアタッチします。CloudFront はオリジンへのリクエストに署名し、エンドポイントはディストリビューションのみがそれを呼び出すことを許可します。エンドポイントを公開したり、アプリケーションにカスタム認証を追加したりしなくても、CloudFront がすでに Amazon Simple Storage Service (Amazon S3) に提供しているのと同じプライベートオリジンパターンが得られます。 今すぐご利用いただけます AWS Lambda Web Functions は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、および欧州 (アイルランド) でご利用いただけます。ウェブ関数は起動時に Arm64 で Node.js 24 (nodejs24.x) を実行し、Amazon 仮想プライベートクラウド (VPC) 接続をサポートします。これにより、関数が VPC 内に存在するリソースにアクセスできるようになります。 始めるには、最初の Web 関数を 1 分以内にデプロイしてください。 aws lambda-web deploy --name hello-world --hello-world 料金の詳細については、 AWS Lambda の料金表ページをご覧ください 。詳細については、 Lambda ウェブ関数のドキュメントを参照してください 。 原文は こちら です。

はじめに こんにちは、PS-SLの織田です。今回は 2人のキャラクターが掛け合いで題材を説明する「ゆっくり解説動画」を、Claude Code と動画編集ソフトの「 ゆっくりMovieMaker4（YMM4） 」を組み合わせて作りました。これまでに、ボードゲームのルール解説とSF作品の設定解説で、7〜8分の動画を7本作っています。 この記事では、次のことを紹介します。 動画を生成できない Claude が、どうやって動画づくりの大部分を担っているのか 人と Claude の作業の分け方 途中でつまずいたことと、その対策 作業の手順を Claude Code の「skill」にまとめ、1本ごとに育てていった方法 同じことを試したい人のための手順 Claude をあまり使ったことがない人にも読めるよう、用語の説明から始めます。 Claude は動画を作れない 最初に、この記事でいちばん伝えたいことを書きます。 Claude 自身は、動画も音声も生成しません。 Claude は文章を読み書きするAIで、動画ファイルを直接作る機能は持っていません。 一方で、動画編集ソフトは「どの時間に、どの画像を、どの位置に出すか」をプロジェクトファイルとして保存しています。YMM4 のプロジェクトファイルは、中身が JSON 形式のテキストです。テキストであれば、Claude は読むことも書き換えることもできます。 そこで、次のように分担しました。 Claude：台本、スライド画像、プロジェクトファイルなど「動画の材料と設計図」を作る YMM4：台本から音声を作り、設計図どおりに組み立てて、動画として書き出す 人：ソフトの操作（読み込み・確認・書き出し）と、内容の最終確認をする 動画を作れない AI でも、動画を作る道具のファイルを扱えれば、動画づくりを任せられます。この考え方は、YMM4 以外のソフトにも応用できると考えています。 使った道具 Claude と Claude Code Claude は、Anthropic 社の AI です。文章の読み書き、調べもの、プログラムの作成などができます。 Claude Code は、Claude にパソコンの中のファイルを読み書きさせたり、コマンドを実行させたりできるツールです。もともとはプログラミング向けのツールですが、ファイルを作る・直す・確かめる作業であれば、プログラミング以外にも使えます。Claude Code はターミナル（コマンドを打ち込む画面）で使うイメージがあるかもしれませんが、Claude のデスクトップアプリの「Code モード」からも使えます。今回はすべてデスクトップアプリから操作しており、ターミナルは使っていません。利用には Claude の有料プランなどが必要です（最新の条件は公式サイトで確認してください）。 Code モードへの切り替え方 デスクトップアプリには、通常のチャットと Code モードがあります。Claude Code として使うには、次の手順で Code モードのセッションを始めます。 デスクトップアプリの画面左上にあるアイコンのうち、 </> のアイコン（Code） を選びます。吹き出しのアイコンは、通常のチャットです 左のメニューの「新規」から、新しいセッションを始めます 作業フォルダを選びます。選んだフォルダは、画面上部のセッション名の横に表示されます。選ばずに始めると、そのセッション専用の一時フォルダで動きます 入力欄の下に「自動」などの権限モード（Claude がファイルの操作やコマンドの実行を、どこまで確認なしで行うかの設定）が表示されていれば、Code モードです。一度始めたセッションは、あとから通常のチャットと Code モードを切り替えられないので、先に Code モードを選んでから始めてください。なお、アプリの更新で、アイコンや表記が変わる場合があります。 skill（手順書） skill は、Claude Code に「この種類の作業は、この手順でやる」と教えておくための仕組みです。決まった場所にフォルダを作り、手順を書いた SKILL.md と、必要ならスクリプトなどを入れておきます。 依頼の内容が skill の説明に合うと、Claude は自動でその手順書を読んでから作業を始めます。毎回同じ説明をしなくて済み、前回の失敗から学んだことも次の作業に引き継げます。新人に渡す「作業マニュアル」のようなものだと考えると分かりやすいと思います。 ゆっくりMovieMaker4（YMM4） YMM4 は、ゆっくり解説動画を作るための、無料で使える動画編集ソフトです。今回使った主な機能は次のとおりです。 台本読み込み ： キャラクター名「セリフ」 の形式で1行に1セリフを書いたテキストを読み込むと、セリフごとに合成音声と字幕が作られ、タイムラインに並びます プロジェクトファイル（.ymmp） ：タイムラインの内容が JSON 形式で保存されます。公式には形式が公開されていないため、バージョンによって変わる可能性があります 書き出し ：組み立てた内容を動画ファイルにします このほか、スライドの画像は Microsoft Edge で、動画の変換は YMM4 に付属している ffmpeg で作りました。どちらも追加でインストールしたものではありません。 Claude がやっていること 1本の動画ができるまでの流れです。オレンジが人、青が Claude の作業です。 1. 台本を書く 題材について公式の資料（ルールなら公式サイトや総合ルール）を調べ、2人のキャラクターの掛け合いの台本を書きます。1人が視聴者の代わりに質問し、もう1人が答える形です。 台本の書き方にも、いくつか決まりを作りました。 字幕が画面からはみ出さないよう、1行を33字以内にする 冒頭で「今日のゴール」を示し、最後に「おさらい」を入れる 合成音声が読み間違えやすい書き方を避ける（「1つ」を「ひとつ」と書くなど） 7〜8分の動画なら、2,400〜2,600字を目安にする 2. スライドを作る 背景に出すスライドは、HTML と CSS で1枚ずつ組み、Edge のヘッドレスモード（画面を表示せずに動かす機能）でスクリーンショットを撮って、1920×1080 の PNG にしています。 msedge.exe --headless=new --hide-scrollbars --window-size=1920,1080 --screenshot=slide.png slide.html Claude は画像を描くことはできませんが、HTML を書くことはできます。HTML をブラウザで画像にすれば、図や表を含むスライドを作れます。 次の画像は、この記事のために作ったサンプルです（実際の動画とは別の題材にしています）。 ゆっくり解説動画では、画面の下に字幕が、左下と右下にキャラクターが表示されます。スライドの文字や図がそこに重ならないよう、配置のルールを決めました。スライドを書き出したら、ガイド線を重ねた画像を自動で作り、はみ出しがないかを確かめます。 3. プロジェクトファイルを組み立てる 人が YMM4 で台本を読み込んで保存すると、セリフ（音声と字幕）だけが並んだプロジェクトファイルができます。Claude はこのファイルを直接書き換えて、次のものを追加します。 背景のスライド（そのスライドを説明するセリフが始まる位置に合わせる） 章タイトル、キャラクターの立ち絵、BGM 章の頭に入れる1秒の間 読み間違いの修正（セリフごとの「発音」の欄を書き換える） 長い字幕の2段化 プロジェクトファイルの中身は、次のような JSON です（一部を省略しています）。 { "$type": "YukkuriMovieMaker.Project.Items.VoiceItem, YukkuriMovieMaker", "CharacterName": "キャラクター名", "Serif": "字幕に出る文字", "Hatsuon": "はつおん/のじょうほう", "Frame": 1771, "Length": 316, "Layer": 4 } Frame は開始位置、 Length は長さで、どちらも 1/60 秒単位です。セリフの開始位置が分かるので、「このセリフが始まったら、このスライドに切り替える」という配置を計算で決められます。 配置の指定は、行番号やフレーム番号ではなく、 セリフの文字列 で書くようにしました。台本を少し直してセリフの位置がずれても、指定を書き換えずに済みます。 4. 動くスライドを作る 静止画だけでは伝わりにくい場面（何かが順番に並ぶ、移動する、など）は、動画にしています。 時刻を受け取って、その時刻の画面を描く HTML を作る Edge で時刻ごとに1コマずつ撮影する ffmpeg でコマをつなぎ、30fps の MP4 にする プロジェクトファイルの中で、同じ場面の静止画と差し替える 動きのない区間は1コマだけ撮って長さを伸ばすので、15〜30秒の場面でも撮影は数百コマで済みます（30fpsで全コマを撮ると450〜900コマになってしまいます）。動きのタイミングもセリフの文字列で指定するので、「このセリフが始まって1.5秒後に動かす」のように、声と動きをそろえられます。 5. サムネイルと概要欄 サムネイルもスライドと同じ方法で作ります。YouTube の概要欄に入れるチャプターの時刻は、プロジェクトファイルの章タイトルの位置から計算しています。 人がやっていること YMM4 に台本を読み込んで保存すれば、音声は YMM4 が生成します。そのため人の作業は、ほぼ『決める・読み込む・確認する』だけになりました。手順が整ってからは、アップロードまで含めて1本あたり約1時間です。 作業 担当 理由 企画を決める 人 何を作るかは人が決める 台本・スライド・プロジェクトファイルを作る Claude ファイルを作る・直す作業 通しで見て確認する 人 聞いた印象や見やすさは人が判断する 字幕の位置を調整する 人 ファイルの書き換えでは変えられなかったため（後述） 動画を書き出す・アップロードする 人 ソフトとサービスの操作 内容が正しいかの最終確認 人 公開する責任は人にある つまずいたこと 設定を書き換えたのに反映されない 字幕の表示位置を下げようとして、セリフのデータにある位置の値を書き換えました。ところが、何度書き換えても表示は変わりませんでした。実際の字幕の位置は、キャラクターごとの設定で決まっていて、セリフ側の値は使われていなかったためです。 形式が公開されていないファイルを書き換えると、「書き換えた」ことと「効いた」ことが一致しない場合があります。それ以来、表示を変える編集は、 人が目視で効いたことを確かめてから次に進む ことにしました。分からない項目は推測で作らず、人がソフトで1つ作ったものを手本にしています。 ソフトを開いたまま書き換えると上書きされる YMM4 でプロジェクトを開いたまま Claude がファイルを書き換えると、ソフトが保存するときに上書きされてしまいます。スクリプトでは、書き込む前に YMM4 が起動していないことを確かめ、書き込みのたびにバックアップを残すようにしました。 合成音声の読み間違い 合成音声は、数字と助数詞の組み合わせ（「1つ」を「いちつ」）、読み方が複数ある漢字（「〜した方」を「かた」）、専門用語などを読み間違えます。台本を読み込んだら、全セリフの発音を一覧にして確かめ、発音の欄を直すようにしました。直した読みは設定ファイルに残しておき、次の動画でもすぐに直せるようにしています。 図が公式の資料と違った 文章は公式の資料と照らし合わせていましたが、例えばボードゲームの図の配置が公式の図と違っていたことがありました。また、セリフで「カードが5枚」と言っているのに、図には4枚しか描いていなかったこともありました。それ以来、 図も公式の資料と照らし合わせる 、 セリフの数と図の数をそろえる 、というルールを手順書に入れています。 縮小した画像では小さな崩れが見えない スライドの確認には縮小した一覧画像を使っていましたが、小さな文字が途中で切れていても気づけませんでした。部品を使ったスライドは、部品のまわりを原寸で切り出して確かめるようにしています。 手順書（skill）に育てる 最初の1本は、Claude と相談しながら手探りで作りました。人の手直しは十数回にのぼりました。その後、次のように作り方を整えていきました。 メモ ：1本目で分かったことを Markdown のメモにまとめ、2本目の最初に Claude に読ませた skill にする ：メモの内容を skill に移し、依頼するだけで自動で読み込まれるようにした スクリプトを汎用化する ：最初はファイル名やセリフの位置をスクリプトに直接書いていた。これを、動画ごとの設定ファイルと、スライド・動きの中身を書くファイルに分け、スクリプト本体は書き換えずに使える形にした 題材別に分ける ：同じ種類の題材が続き、手順書に題材特有の話が増えたため、どの題材にも共通の手順と、題材の種類ごとの手引きに分けた 今の skill の構成は次のとおりです。 skills/（skill の置き場） yukkuri-kaisetsu/ SKILL.md … 全体の流れ、人と Claude の分担、決まり事 references/ layout.md … スライド・サムネイル・概要欄の作り方 ymm4.md … プロジェクトファイルの構造、読み間違いの直し方 animation.md … 動くスライドの作り方 rights.md … 権利まわりの方針 題材_<種類>.md … 題材の種類ごとの手引き scripts/ … スライド作成、プロジェクトの組み立て、動くスライドなど assets/ … 過去の動画の設定ファイルなどの見本 1本作るたびに「振り返り」の時間を取り、人から受けた指摘や新しく分かったことを skill に書き足しています。書き足すときは、「何が起きたか」ではなく「次はこうする」という手順の形にしています。 その結果、人の手直しは、慣れてからは1本あたり0〜2回になりました。新しい会話（セッション）を始めて「企画一覧の〇番を作って」と頼むだけで、Claude が skill を読み込み、同じ流れで作業を始めます。 動画の作成手順 必要なもの Windows のパソコン Claude のデスクトップアプリ（Code モード＝Claude Code が使えるプラン） ゆっくりMovieMaker4 Python と画像処理ライブラリの Pillow（スクリプトの実行用） Microsoft Edge（Windows に入っているもの） 進め方 最初の1本は、相談しながら作る ：いきなり skill を作るより、まず1本作ってみるのがおすすめです。デスクトップアプリの Code モードで新しいセッションを始め、作業用のフォルダを選んでから、作りたい動画の内容を伝えて、台本とスライドから順に作ってもらいます YMM4 の作業は人がやる ：台本ができたら、YMM4 で読み込んで保存し、ソフトを閉じてから Claude に伝えます。Claude がプロジェクトファイルを組み立てたら、YMM4 で開いて確認します 気づいたことをその場で伝える ：読み間違い、表示のずれ、図の誤りなどは、スクリーンショットを付けて伝えると、Claude が原因を調べて直します 終わったら振り返りをまとめてもらう ：分かったことを Markdown にまとめてもらい、2本目の最初に読ませます 2〜3本作ったら skill にする ：メモの内容を skill にしてもらいます。skill は、ユーザーのフォルダの中の .claude\skills\<skill の名前>\SKILL.md に置きます（Windows なら C:\Users\<ユーザー名>\.claude\skills\… ）。ここに置いた skill は、そのパソコンの Claude Code（Code モード）で、どのフォルダで作業しても読み込まれます。この記事の手順では、Claude デスクトップアプリの Cowork モード やクラウドのセッションでは読み込まれない点に注意してください。特定のフォルダでだけ使いたい場合は、そのフォルダの中の .claude\skills\ に置く方法もあります SKILL.md の書き出し SKILL.md の先頭には、skill の名前と「どんなときに使うか」の説明を書きます。Claude はこの説明を見て、skill を読み込むかどうかを判断します。 --- name: yukkuri-kaisetsu description: 2人のキャラクターの掛け合いで題材を解説する動画を、ゆっくりMovieMaker4で作る手順。台本、スライド、プロジェクトファイルの編集、サムネイル、概要欄までを扱う。「ゆっくり解説」「YMM4」に触れたら、題材が何であってもこの skill を使う。 --- # ゆっくり解説動画の制作 ## 全体の流れ （人と Claude の作業を順番に書く） ## 決まっている方針 （これまでの指摘から決まったことを書く） 依頼文の例 作る動画の候補を「企画一覧」というファイルにまとめておくと、依頼は1行で済みます。 企画一覧（企画一覧.md）の TCG #3 を作ってください。 タイトル、作業フォルダ、扱う内容の候補、どの回にも共通の進め方（対象、尺、最後に次の回を予告する、など）は、企画一覧と skill の側に書いてあります。 注意点 プロジェクトファイルの形式は公式に公開されていません。書き換えるときは、必ずバックアップを取ってください 書き換えている間は、YMM4 を閉じておいてください 表示を変える編集は、効いたかどうかを画面で確かめながら進めてください 権利まわりで気をつけたこと 解説動画は、題材そのものや素材に権利者がいます。次の点に気をつけました。 実物の画像は使わない ：作品の場面写真やカードの画像、ロゴなどは使わず、図はすべて自作しています。権利者によっては、個人の利用に許諾を出していない場合があります 権利者の規約を読む ：ファン作品向けの規約（ファンコンテンツ・ポリシーなど）がある題材では、作り始める前に読み、必要な表記を動画と概要欄に入れています 素材の利用条件を確かめる ：合成音声、キャラクターの立ち絵、BGM には、それぞれ利用条件があります。特に、収益化や法人での利用には別の条件がある場合があるので、公開範囲に合わせて確認が必要です 内容の最終確認は人がする ：Claude が公式の資料で確かめた内容でも、公開する前に人が確認しています なお、この記事では素材の利用条件を考慮して、作った動画や音声は掲載していません。 まとめ Claude は動画を作れません。それでも、動画編集ソフトが扱うファイルと素材を作ることで、ゆっくり解説動画づくりの大部分を任せられるようになりました。 Claude は「材料と設計図」を作り、ソフトの操作と最終確認は人が行う 形式が公開されていないファイルを扱うときは、「効いたかどうか」を画面で確かめる 1本ごとの振り返りを skill に書き足していくと、人の手直しが減っていく 「AI がそのソフトに対応しているか」ではなく、「そのソフトのファイルを AI が読み書きできるか」という見方をすると、AI に任せられる作業の幅が広がると感じています。プロジェクトファイルがテキストで保存されるソフトであれば、同じ考え方が使えるはずです。 また、Claude関連のブログを他にも書いているので そちら も是非ご覧ください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 動画生成できないClaudeに「ゆっくり解説動画」を作らせてみた first appeared on SIOS Tech Lab .

本ブログは 2026 年 10 月 5 日に公開された AWS Blog “ AWS Continuum sets a new standard in autonomous code security ” を翻訳したものです。 AI モデルは、能力が向上するにつれて、より多くのセキュリティ脆弱性を発見し、それらを悪用するためのますます巧妙な攻撃経路を特定するようになっています。その結果、防御側にはこれまで以上に迅速な対応が求められています。セキュリティチームは現在、既存のプロセスで想定していた以上の数の潜在的な脆弱性に直面しています。脆弱性ごとに調査と再現を行い、修正を作成したうえで、その修正が想定どおりの動作を損なわずに脆弱性を解消できるかをテストで確認しなければなりません。 AWS Continuum for code vulnerabilities は、マシンスピードで動作する自律型セキュリティによって、この作業を加速します。Continuum を具体的な公開基準で評価するために AWS が選んだのが CyberGym-E2E です。このベンチマークでは、エージェントが実際のコードベースから脆弱性を見つけ、動作する概念実証 (proof of concept) でそれを実証し、プロジェクトのテストでカバーされている動作を損なわずに修正することが求められます。Continuum は、ベンチマークの制限時間である 90 分以内に 920 件中 819 件のタスクをパスし、エンドツーエンドの成功率 89.0% を達成しました。これは、従来の公開最高値である 65.9% を 23.1 ポイント上回る新たな基準です。 脆弱性ライフサイクル全体の測定 多くのセキュリティベンチマークは、単一のタスクを切り離してテストします。検出ベンチマークは、システムが疑わしいコードを特定できるかどうかをテストし、パッチ生成ベンチマークは、既知の欠陥を前提として修正を求めます。CyberGym-E2E の前身である CyberGym も既知の脆弱性を前提としており、エクスプロイト生成に重点を置いています。これに対して CyberGym-E2E は脆弱性ライフサイクル全体を評価するもので、システムには脆弱性を特定して実証したうえで、テスト済みの修正を作成することが求められます。このように評価範囲が広いため、セキュリティチームが実際に取り組む作業をより忠実に反映しています。 CyberGym-E2E の各タスクでは、実際のオープンソースプロジェクトの脆弱なリビジョンと、そのビルドとテストに必要なツールを含むコンテナにエージェントが配置されます。エージェントはソースの調査と変更はできますが、脆弱性の説明、概念実証、クラッシュログ、元のパッチは一切与えられません。外部ネットワークへのアクセスはブロックされ、保護されたベンチマークファイルも変更できません。エージェントは 90 分以内に、脆弱性を実証する入力とソースコードのパッチを提出する必要があります。ベンチマーク全体は、139 のオープンソースプロジェクトで過去に OSS-Fuzz によって検出された脆弱性に基づく 920 件のタスクで構成されています。プロジェクトのコード行数の中央値は 600,000 行を超えます。 このベンチマークでは、各提出物を次の 4 つの累積的なステージで評価します。 S1 では、脆弱なプログラムをクラッシュさせる入力をエージェントが生成したかどうかを確認します。 S2 では、エージェントが作成したパッチによってそのクラッシュが防止されるかどうかを確認します。 S3 では、パッチを適用したプロジェクトが引き続き機能テストにパスするかどうかを確認します。 S4 では、ベンチマークで選定された特定の過去の脆弱性もパッチによって修正されるかどうかを確認します。 CyberGym-E2E では、S3 をエンドツーエンドの成功を測る主要な指標と定義しています。S4 は診断用の指標です。リポジトリには実在する脆弱性が複数含まれている場合があり、エージェントがベンチマークで選定された対象とは異なる実在の欠陥を見つけて修正することもあるためです。 Continuum が新たな基準を確立 Continuum for code vulnerabilities は、CyberGym-E2E のすべてのステージで新たな基準を打ち立てました。次の表は、そのパフォーマンスを従来の公開最高値と比較したものです。 ステージ 評価内容 Continuum 従来の公開最高値 差分 S1 脆弱性の発見と再現 92.5% 67.9% +24.6% S2 生成した入力によるクラッシュの修正 89.6% 66.2% +23.4% S3 テスト対象の機能の維持 89.0% 65.9% +23.1% S4 ベンチマークで選定された脆弱性も修正 37.8% 26.2% +11.6% ベンチマークでエンドツーエンドの成功を測る主要な指標である S3 では、Continuum は 920 件中 819 件のタスクをパスしました。成功率 89.0% は、従来の公開最高値である 65.9% を 23.1 ポイント上回っています。この結果には、基盤となるフロンティアモデルの能力と、マルチエージェントのセキュリティシステムとしての Continuum の設計の両方が反映されています。次のセクションでは、このシステムがモデル単体の能力に加えてどのような価値をもたらしているのかを説明します。 公式の結果である 89.0% は、CyberGym-E2E の 90 分の制限時間を適用したものです。制限時間を超えてタスクの継続を許可した場合、Continuum のエンドツーエンドのパス率は 93.7% に達しました。この結果は、長時間の分析を最後まで完了できれば、対応できる範囲がさらに広がる可能性があることを示しています。 評価は、CyberGym-E2E のネットワーク分離と提出物レビューの要件に従って実施しました。実行中は外部からの情報取得をブロックしました。また、実行後にトラジェクトリ (エージェントの実行履歴) をレビューし、タスクの成功が、公開済みの過去の修正を取得した結果ではなく、脆弱性分析によるものであることを確認しました。 エンドツーエンドのセキュリティを実現するハーネス設計 Continuum for code vulnerabilities は、コード脆弱性ライフサイクルの主要なフェーズである発見、検証、修復を中心に構成されたマルチエージェントシステムです。各フェーズでは、そのフェーズで必要となる証拠と判断に合わせて調整された専用のエージェントを使用します。システムは証拠を次のフェーズへ引き継ぐため、各フェーズでは前のフェーズまでに完了した作業を基に処理を進められます。 発見フェーズでは、Continuum がリポジトリを分析し、脆弱性の候補となる検出結果を作成します。エージェントは、詳しく調査すべきコードパスを特定し、各候補を裏付けるソースコード上の証拠を記録します。 検証フェーズでは、専用のエージェントが、候補となる検出結果が実際のセキュリティ問題であることを実証しようとします。エージェントは概念実証を構築して脆弱なプログラムに対して実行し、観測された動作がその検出結果を裏付けるかどうかを判断します。これにより、コードレベルの潜在的な弱点が、実行して確認できる証拠へと変換されます。 修復フェーズでは、エージェントが脆弱性の根本原因を突き止め、パッチを作成します。その後 Continuum は、パッチによって実証済みの不具合が防止されること、そしてプロジェクトの機能テストに引き続きパスすることを確認します。つまり、修正は、脆弱性の立証に使用したものと同じ証拠に基づいて評価されます。 これらのフェーズが連携することで、疑わしいコードから実証済みの脆弱性、テスト済みの修正に至るまでを一貫してたどれる記録が作成されます。このアーキテクチャにより、Continuum は一貫した証拠の基準を維持しながら、ツール、指示、チェック、モデルを各フェーズに合わせて調整できます。また、複数のモデルの相互補完的な強みを活用し、新しいモデルが利用可能になりしだい取り込めるマルチモデルのアプローチにも対応しています。 お客様の環境では、Continuum はコードレベルの証拠を、サービスの露出状況、ネットワークパス、アクセス許可、設定など、利用可能なデプロイコンテキストと組み合わせることもできます。このコンテキストは、本番環境への影響が限定的な脆弱性と、直ちに対応が必要なセキュリティ上の露出とを区別するのに役立ちます。CyberGym-E2E はコードレベルのプロセスを評価するもので、デプロイコンテキストは提供されません。そのため、こうしたより広範な優先順位付けの機能はベンチマークの評価範囲外となります。 CyberGym-E2E のその先へ CyberGym-E2E は、複雑で多段階にわたるプロセスを、再現可能なタスクと、コードを実行して検証できる結果を備えた大規模な公開ベンチマークとして形にすることで、セキュリティ評価を前進させています。タスクの構築、スコアリング、提出基準について CyberGym-E2E の作成者が行った綿密な取り組みは、エンドツーエンドの進歩を測定するための具体的な基盤をこの分野にもたらしています。 920 件のタスク全体で評価の一貫性と再現性を保つため、CyberGym-E2E は C および C++ プロジェクトのメモリ安全性の脆弱性に焦点を当てています。サニタイザーが検出したクラッシュを欠陥の客観的な証拠とし、その後のチェックで、修正が概念実証による脆弱性の再現を防ぎ、プロジェクトのテストでカバーされる機能を維持しているかどうかを判断します。この設計上、多くのプログラミング言語や脆弱性クラスは、必然的にベンチマークの現在の範囲外となります。その中には、本番システムで観測される、最も一般的かつ影響の大きいバグクラスの多くも含まれます。これらの領域を評価するには、別のタスク環境と、同様に厳密な検証方法が必要になります。 AWS が考えるエンドツーエンドのセキュリティは、テスト済みのコードレベルの修正を作成するだけにとどまりません。本番システムでは、サービスの露出状況、ネットワークパス、アクセス許可、設定などのデプロイコンテキストによって、その脆弱性のリスクが限定的なのか、直ちに対応が必要なのかが決まることが少なくありません。今後の評価では、自律型システムがこうしたコンテキストを踏まえて推論し、デプロイされたシステムの安全性への影響に応じて検出結果に優先順位を付けられるかどうかをテストする必要があります。 CyberGym-E2E の価値は、データセットそのものだけにとどまりません。CyberGym-E2E は、エンドツーエンドのセキュリティを独立したタスクとして定義し、測定する価値があることを示しています。そのためには、範囲、証拠、何をもって成功とみなすかについて難しい設計判断が必要になりますが、CyberGym-E2E は、こうした判断を検討するための具体的な出発点をこの分野に提供しています。このシステムレベルの視点は、 Deception Benchmark に関する AWS の取り組みを補完するものです。Deception Benchmark は、範囲はより狭いものの関連する能力、つまり個々のフロンティアモデルが実際の脆弱性と安全なコードをどの程度確実に区別できるかを評価します。両者は、モデルとシステムの両方のレベルでセキュリティパフォーマンスを検証します。 AWS Continuum for code vulnerabilities が、チームによる脆弱性の 発見、検証、優先順位付け、修復 をマシンスピードでどのように支援するかについては、 A WS Continuum 製品ページ をご覧ください。 Alexander Greaves-Tunnell Alec は、AWS Continuum for code vulnerabilities の設計と評価に携わるサイエンティストです。AWS では、検索、セキュリティ、オブザーバビリティの分野にわたるプロジェクトを主導し、既存のモデルの知識だけでは対応できない複雑なアプリケーション領域に最先端の AI を適用してきました。学術的なバックグラウンドは統計学です。 Neha Rungta Neha は、複雑なシステムを対象とするマシン推論を大規模に実現することにキャリアを捧げてきたサイエンティスト兼ビルダーです。自動推論、形式的検証、セキュリティ、AI にわたる研究に取り組み、Cedar、IAM Access Analyzer、Continuum などのシステムの構築に携わってきました。現在は、LLM、形式手法、エージェント型システムを組み合わせ、次世代のマシン推論の開拓に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。