本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences ” を翻訳したものです。 Amazon GuardDuty 拡張脅威検出 は、弱い GuardDuty シグナルの組み合わせが信頼性のしきい値を超えると、それらを相関付けて、重要度が Critical の単一の攻撃シーケンスの検出結果にまとめます。2026 年 5 月 20 日から、攻撃シーケンスに 5 種類の新しいインジケーター ( MALICIOUS_PACKAGE 、 MISCONFIGURATION 、 REACHABILITY 、 SENSITIVE_DATA 、 VULNERABILITY ) が付与されるようになりました。詳細については、「 Document history for Amazon GuardDuty 」および「 Attack sequence finding details 」を参照してください。 これらのインジケーターの情報源は、 Amazon Inspector 、 Amazon Virtual Private Cloud (Amazon VPC) Reachability Analyzer 、 Amazon Macie 、そして AWS Security Hub を通じて提供されるポスチャデータです。これらのサービスを既に別の目的で利用しているお客様もいるでしょう。今回のアップデートにより、拡張脅威検出はこれらのサービスのシグナルを攻撃シーケンスの検出結果に取り込むようになりました。この記事は、前提条件となるサービスを既に利用しているチーム向けの運用ガイドです。新しいインジケーターが検出結果にどのように表示されるか、リリース後のデータから何がわかるか、そしてインシデント対応ワークフローにどう組み込むかについて説明します。これらのインジケーターにより、拡張脅威検出はアカウント内で最も優先すべきシグナルを判断しやすくなります。その結果、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) のランタイムアクティビティをモニタリングするアクティブディフェンス戦略の一環として、ワークロード領域でより信頼度の高い検出結果が得られます。 新しいインジケーターの概要 GuardDuty におけるシグナルとは、GuardDuty が不審なアクティビティを探す際に評価するあらゆるイベントを指します。弱いシグナルとは、それ単体では脅威を明確に示さないシグナルのことで、5 つの新しいインジケーターはこれに該当します。例えば、ホスト上で Common Vulnerabilities and Exposures (CVE) が 1 件検出されたとしても、それは脆弱性が存在することを示すだけで、攻撃者がその脆弱性を悪用していることを示すわけではありません。次の表に示すように、これらの検出結果は、GuardDuty が既に追跡している不審なアクティビティのシグナルと相関付けられることで、初めて価値を発揮します。 インジケーター ソース 示される内容 VULNERABILITY Amazon Inspector Common Vulnerability Scoring System (CVSS) の重要度と Exploit Prediction Scoring System (EPSS) の悪用可能性スコアを含む CVE のリスト。 MALICIOUS_PACKAGE Amazon Inspector Amazon Inspector の MAL-* パッケージインジケーター。Amazon Inspector による脆弱性のスコアリング方法の詳細については、「 Amazon Inspector Security Research 」を参照してください。 REACHABILITY Amazon VPC Reachability Analyzer ホストまたはクラスターがインターネットから到達可能かどうか MISCONFIGURATION AWS Security Hub のコントロール (ポスチャ管理) リソースの設定が、AWS または 業界のベストプラクティス に沿っていないこと。例えば、IMDSv1 が有効なままになっている、管理者ポリシーの権限が過剰である、パブリックにアクセス可能な Amazon Simple Storage Service (Amazon S3) バケットがある、などです。 SENSITIVE_DATA Amazon Macie リソース内で機密データと思われる情報が検出されたこと。 これら 5 つの値は、GuardDuty の AWS マネジメントコンソールで攻撃シーケンスの検出結果を開いたときの [インジケーター] タブと、 GetFindings の JSON ファイルに表示されます。 図 1: 攻撃シーケンスの検出結果の [インジケーター] セクション VULNERABILITY インジケーターには EPSS が含まれるため、ここで EPSS について補足しておきます。「 FIRST EPSS overview 」によると、EPSS スコアは、公開済みの CVE が今後 30 日以内に実際の環境で悪用される確率を 0～1 の範囲で表したものです。EPSS は CVSS を置き換えるものではありません。CVSS が脆弱性本来の重要度を表すのに対し、EPSS は近いうちに悪用される可能性の高さを表すため、インシデント対応ではより役立つ数値となります。 前提条件 インジケーターにデータを反映させるには、次の AWS サービスを有効にしておく必要があります。 Amazon Inspector (Amazon EC2 および Amazon EKS で有効化): VULNERABILITY と MALICIOUS_PACKAGE に対応します。 AWS Security Hub : AWS Foundational Security Best Practices に基づいて MISCONFIGURATION を提供します。 Amazon VPC Reachability Analyzer (本番環境の VPC で有効化): REACHABILITY に対応します。 GuardDuty Runtime Monitoring (Amazon EC2、Amazon ECS、Amazon EKS で有効化): 生成されるすべてのシグナルが、相関付けの起点 (アンカー) になり得ます。 Amazon Macie : SENSITIVE_DATA を提供します。 弱いランタイムシグナルの強化 プロセスの呼び出し、ポッドでの exec、システムコールのパターンなどのランタイムシグナルは、ノイズが多くなることがあります。既知の攻撃ツールのパスに一致しないランタイムシグナルは単体では重要な意味を持たず、リソース状態のコンテキストがなければ、通常は重要度が Critical の攻撃シーケンスとなるしきい値に達しません。 新しいインジケーターは、この欠けていたコンテキストを補います。弱いランタイムシグナルが観測されたホストに、優先度の高いパッチ未適用の CVE、既知の悪意のあるパッケージ、IMDS の設定ミス、インターネットからの到達可能性が併存する場合、拡張脅威検出はそれらをまとめて、高い信頼度で重要度が CRITICAL の単一の攻撃シーケンスに昇格させます。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。このリソース状態のコンテキストを加えることで、弱いシグナルが対応可能なアラートへと変わります。 実際に、ランタイムプロセス領域では新規の攻撃シーケンスの検出結果が大幅に増加し、優先順位付けされたランタイムプロセスの攻撃シーケンスのおよそ 4 件に 1 件を占めるまでになりました。一方、ネットワークベースの侵害の痕跡 (IOC) 領域ではほとんど変化はありませんでした。リリース後 1 週間で、このパターンは多くのお客様のアカウントで確認されています。従来は弱く相互に関連のない複数の検出結果としてばらばらに表示されていた攻撃シーケンスが、重要度が CRITICAL の単一の検出結果として表示されるようになったのです。 例: Amazon EKS で新規に検出された攻撃シーケンス 追加のインジケーターによって拡張脅威検出がどのように改善されたかを説明したところで、これらのインジケーターがどのような価値をもたらすかを具体的な例で見ていきましょう。ここでは、Amazon EKS クラスターで実際に観測されたシナリオを分析します。このアクティビティは 8 日間にわたって発生し、11 件の異なる GuardDuty の検出結果が生成されました。 図 2: 拡張脅威検出がシグナルを相関付ける前の EKS クラスターのアクティビティの概要 図 2 に示すように、GuardDuty が 8 日間にアクティビティ領域で観測したのは、55 件の EKS_AUDIT_LOGS シグナル (ポッドでの exec、ロールの引き受け、 AssumeRoleWithWebIdentity の呼び出し) と、18 件の検出結果レベルのシグナルでした。これらはすべて、198.51.100.69 という単一の外部 IP アドレスから発生していました。この IP アドレスから、同じ EKS クラスターに対して 4 つの異なる AWS Identity and Access Management (IAM) アイデンティティによる認証が行われていました。ワーカーノード上のランタイムアクティビティは、既知の攻撃ツールのパスに一致するプロセスがなく、実行プロファイルのフラグも立たなかったため、ありふれたものに見えました。リリース前の相関ロジックでは、このシーケンスを検出するには EKS_MALICIOUS_PROCESS ルールが発動する必要がありました。このルールの発動には、悪意のある exec パスか、異常で疑わしいツールのプロファイルのいずれかが必要です。今回のアクティビティにはどちらも該当しなかったため、相関付けられた攻撃シーケンスの検出結果は生成されませんでした。 新しい GuardDuty 拡張脅威検出のインジケーターによって、この EKS の例に追加された情報は次のとおりです。 MALICIOUS_PACKAGE (クラスター上): Amazon Inspector の識別子 MAL-2022-4933 が検出されています。 VULNERABILITY (Amazon Inspector の全出力、クラスター上): 合計 42 件の CVE があり、そのうち 33 件が CVSS で CRITICAL と評価されています。 クラスター上: CVE-2022-1471 (SnakeYAML のデシリアライゼーション、EPSS 0.94)、CVE-2024-4577 (PHP-CGI の引数インジェクション、EPSS 0.97)、CVE-2024-34351 (Next.js の SSRF)、CVE-2025-29927 (Next.js の認証バイパス)、CVE-2023-44487 (HTTP/2 Rapid Reset)、CVE-2022-37434 (zlib のヒープオーバーフロー、EPSS 0.92) を含む 12 件の CVE があります。 5 つのワーカーノード全体: 合計 379 件の CVE があり、そのうち 68 件が Amazon Inspector によって CRITICAL と判定されています。 REACHABILITY : クラスターの API エンドポイントがインターネットから到達可能で、5 つのワーカーノードのうち 3 つもインターネットから到達可能です。 MISCONFIGURATION (EC2 IMDS): 5 つのワーカーノードすべてで、引き続き IMDSv1 にアクセスできる状態になっています。 これらの追加インジケーターを考慮すると、この一連のアクティビティは単一の AttackSequence:EKS/CompromisedCluster の検出結果として表示されます。重要度は CRITICAL で、データが反映された 4 つのインジケーターすべてが [インジケーター] タブに表示されます。また、 MITRE ATT&CK® の Initial Access (External Remote Services)、Discovery、Persistence へのマッピングも示されます。 図 3: 攻撃シーケンス内の新しい脆弱性インジケーター この検出結果には、ワーカーノードレベルで 100 件を超える Amazon EC2 の CVE が記載されています。CVSS が CRITICAL のものが 1 件、 HIGH のものも多数ありますが、EPSS スコアが低いため、ほとんどは脆弱性の優先度が LOW です。GuardDuty が優先度の高いものを強調表示するため、100 件を超える検出結果を精査してどれから対処すべきかを判断する必要はなく、最も効果の高い箇所に対応作業を集中できます。 例: 暗号資産マイニングと脆弱なホスト 2 つ目の例では、EC2 インスタンスグループのケースを取り上げます。このケースでは、GuardDuty は暗号資産マイニングを示す有力なネットワークベースの検出結果を既に得ていましたが、新しいインジケーターが修復に役立つ追加のコンテキストを提供したことで、インシデント対応を迅速化できました。 図 4: EC2 インスタンスに対する暗号資産マイニング攻撃 複数の EC2 インスタンスが既知の暗号資産マイニングの宛先と通信しており、この宛先は脅威インテリジェンスによって mining/misc としてフラグ付けされていました。ネットワーク IOC の証拠は、それ単体でも十分に強力なものでした。 新しいインジケーターによって追加された観測内容 : VULNERABILITY により、関与した 3 つのインスタンスのうち 2 つで、EPSS が約 0.9 の CVE-2007-4559 (Python tarfile) が示されました。 結果 : AttackSequence:EC2/CompromisedInstanceGroup の検出結果を基に、「 宛先 IP のブロック 」にとどまらない対応が可能になりました。暗号資産マイニングツールが侵入に悪用したと考えられる脆弱性と、それを修復するパッチが示されるため、アウトバウンド接続を遮断するだけでなく、根本的な侵入経路に対処できます。 GuardDuty は EC2 インスタンスグループで暗号資産マイニングが行われている強力な証拠を得ていたため、この攻撃シーケンス自体は脆弱性のコンテキストがなくても生成されていたはずです。ただし、コンテキストが増えることで、トリアージを迅速に行えます。 リリース後 1 週間のサンプルで観測された侵害の痕跡 次の CVE (EPSS スコアは観測当時の値) は、リリース後の最初の 1 週間に新しい拡張脅威検出のインジケーターが付与されたお客様のアカウントのホストで、各インジケーターの検出結果が生成された時点で観測されたものです。EPSS スコアは特定時点の値であるため、今後の検出結果に表示される CVE の優先度は、ここに示す値ではなく、その時点の EPSS に基づきます。 CVE-2024-4577 – Windows 上の PHP-CGI の引数インジェクション。EPSS 0.97 以上。 CVE-2022-1471 – SnakeYAML のデシリアライゼーション。EPSS 0.94。CVSS は Critical。 CVE-2022-37434 – zlib のヒープバッファオーバーフロー。EPSS 0.92。 CVE-2007-4559 – Python tarfile のパストラバーサル。2026 年時点でも EPSS は 0.9 以上。 CVE-2025-29927 – Next.js の認証バイパス。Node ベースのウェブ層で頻繁に検出。 CVE-2024-34351 – Next.js の SSRF。 CVE-2023-44487 – HTTP/2 Rapid Reset。 ランタイムモニタリングでは、侵害されたホストから回収されたマルウェアやツールのアーティファクトに関連する弱いシグナルが検出されました。 HackTool ファミリーの Linux/frp : Fast Reverse Proxy の亜種で、コマンドアンドコントロールトンネルとして使用されていました。Amazon EKS ワーカーノード上では、多くの場合 kuboard-agent や kuboard-agent-server というバイナリに偽装されていました。また、 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/ 配下で、コンテナスナップショットのパスとの一致も観測されました。frp バイナリはコンテナイメージ内とノード上の両方に存在するため、パッチが適用されていない AMI からノードを再構築するだけでは修復として不十分です。 Burp Collaborator のアウトオブバンドのコールバックホスト名が *[.]oastify[.]com 配下で見つかり、パターン <35-char base32>[.]oastify[.]com に一致していました。これらは同じ EKS シーケンス上で frp と同時に観測されており、共有インフラストラクチャ上で 2 つ目のツールまたは別のアクターが活動していた可能性が高いと考えられます。 Amazon Inspector の悪意のあるパッケージインジケーター MAL-2022-4933 が、Amazon EC2 と Amazon EKS の両方のコンテキストで検出されました。 上記のツール関連のシグナルと相関していたアイデンティティとアクセスのパターンは次のとおりです。 単一の外部送信元 IP から、短期間のうちに Amazon EKS、Amazon ECS、Amazon EC2 の別々の領域にまたがって、人間が使用する複数の異なる IAM アイデンティティによる認証が行われていました。これは、新規に検出されるようになった Amazon EKS プロセス関連のクラスで最も多く見られたアイデンティティのシグネチャです。 これらのインジケーターを活用した攻撃シーケンスへの対応 新しいインジケーターによって、既に発生した攻撃シーケンスに対するインシデント対応のランブックが変わるわけではありません。新しいインジケーターが意味を持つのは新規の検出結果であり、それらの検出結果は、ランタイムモニタリング関連のシグナルが強化された領域に集中しています。新規の検出結果には、次のように対応してください。 シーケンスに緊急に対応してください 。 MALICIOUS_PACKAGE と優先度の高い VULNERABILITY が示されている場合、そのホストは侵害されるリスクにさらされてきただけでなく、現在もさらされています。露出しているリソースを封じ込め、脆弱性を修復してください。また、攻撃者にさらされた可能性があるすべての IAM 認証情報、 インスタンスプロファイル 、 IAM Roles for Service Accounts (IRSA) にバインドされたロール をローテーションしてください。 EPSS で重み付けした優先度に基づいてパッチを適用してください 。CVSS の値だけで判断しないでください。検出結果に含まれる優先度の高い VULNERABILITY リストは、既に EPSS の高い CVE に絞り込まれています。 パブリックなリソースを隔離してください 。 REACHABILITY インジケーターで示されたリソースが対象です。悪用可能な脆弱性があり、インターネットから到達可能なホストは、修復のために隔離する必要があります。 さらに詳しい対応方法については、「 Remediating detected GuardDuty security findings 」の修復手順と、GuardDuty の検出結果とアカウントを AI で分析するセキュリティ分析機能である GuardDuty Investigation を参照してください。 まとめ GuardDuty 拡張脅威検出は、セキュリティチームが特に支援を必要とすることが多いランタイムワークロード領域 (Amazon EC2、Amazon ECS、Amazon EKS) で、信頼度の高い攻撃シーケンスの検出結果をより多く提供できます。これは、GuardDuty のアクティビティシグナルと、他の AWS サービスから得られるリソース状態のコンテキストを組み合わせることで実現しています。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。拡張脅威検出は、こうした弱いシグナルを脆弱性、パッケージリスク、到達可能性、設定ミス、機密データの各インジケーターと相関付けることで、ノイズを、重要度が CRITICAL の対応可能な検出結果に変えます。AWS Security Hub、Amazon Inspector、Amazon VPC Reachability Analyzer、Macie、GuardDuty Runtime Monitoring を既に有効にしている場合、新しいインジケーターは攻撃シーケンスの検出結果に自動的に表示されます。これらのサービスをまだ使用していない場合は、新しい GuardDuty 拡張脅威検出のインジケーターと、各サービス自体が提供する価値を活用するために、ぜひ有効化をご検討ください。 この記事に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせください 。 Aman Khare Aman は Amazon GuardDuty のシニアソフトウェア開発者です。 拡張脅威検出 の開発に携わり、AWS インフラストラクチャで検出された悪意のある攻撃チェーンをお客様が正確に特定できるよう支援しています。以前は Amazon OpenSearch のパフォーマンスとレジリエンシーに関する取り組みを主導し、クラスターマネージャーのメモリ使用量の 10 分の 1 への削減や、1,000 ノード規模のクラスターの実現などを達成しました。仕事以外では、旅行、アドベンチャーアクティビティ、読書、ボードゲームを楽しんでいます。 Kyle Koeller Kyle は Amazon GuardDuty チームのセキュリティエンジニアで、脅威検出を専門としています。クラウドの脅威検出とオフェンシブセキュリティに情熱を注いでおり、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の資格を保有しています。仕事以外では、ジムで過ごしたり、ニューヨーク市を散策したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに 先日、社内で AI Coding Agent Hackathon というイベントを開催いたしました。本記事では、そのイベントの様子を紹介します。 目的 RevComm には「AI活用推進室 (AI Promotion Office)」という組織があります。AI活用推進室における活動の一環として、「AI Coding Agents Optimization Guide」というガイドラインを策定しています。このガイドラインは、AI コーディングエージェントの価値を最大化するために、各チームが段階的に AI コーディングエージェントの活用を進めていけるような指針を定めています。具体的には、まず AGENTS.md の導入などから始め、最終的にはサブエージェントやスキル、MCP などの活用やコスト削減のための方法論などの応用的な活用法を段階的に取り入れていくためのプラクティスを整備しています。 この AI Coding Agents Optimization Guide を実践を通じて組織的に学ぶ場として、ハッカソンを開催しました。 実施したこと 概要 開催時間: 3 時間 使用した AI コーディングエージェント: Claude Code または Codex 題材 今回のハッカソンではタイピングゲームの開発を題材としました。普段、フロントエンド開発に携わっているメンバーも参加しやすいよう、ランタイムとしては Node.js を選定しました。 当日の進行をスムーズにするために、あらかじめテンプレートリポジトリを整備しました。各参加者はこのテンプレートをベースにリポジトリを作成することで、すぐに開発に取り掛かることができます。 メトリクスの収集・可視化 各種メトリクスを収集・可視化することでトークン使用量などのコストを意識して課題に取り組めるようにするために、ダッシュボードを作成しました。このダッシュボードは Claude Code や Codex などのコーディングエージェントを OpenTelemetry を介して Datadog と連携させることによって実現されています。テンプレートリポジトリの Markdown ドキュメントに Datadog と各種コーディングエージェントの連携方法を記載しておき、スムーズにセットアップできるようにしました。 Datadog によるメトリクスの可視化 課題の着手 テンプレートリポジトリには、取り組むべきタスクを詳細に記載した Markdown ドキュメントが含まれています。 タスクの一覧 各タスクには priority が設定されており、それに応じて最終的な採点結果が加算されます。 タスクの例 成果発表 最後に成果発表を実施しました。各自で取り組んだ内容や工夫したことに加えて、普段の開発環境やコーディングエージェントの活用方法についての共有も実施しました。 成果発表の様子 スコアと分析結果の共有 各メンバーのスコアの採点と全体的な分析結果の共有を実施しました。スコアは runn と Playwright を活用して、自動で採点できる仕組みを構築しました。また、ハッカソンに参加いただいた各メンバーが今後、より効果的に AI コーディングエージェントを活用できるようにするため、Datadog で収集したコスト情報とスコアのプロットや、Datadog で収集した情報から判明した良い活用法などについても全体で共有しました。 フィードバック まとめ 成果発表の場を通して、参加者の方々がさまざまな工夫や活用法などを実践されていることがわかりました。 Git worktree や herdr / cmux などを活用してセッションを並列実行することで、タスクをより効率的にこなす。 claude-code-orchestra を活用したマルチエージェントのオーケストレーション /grill-me スキルの活用 自分自身、まだ試したことのないコーディングエージェントの活用法などを知ることもできたため、今後、実践していきたいです。 今回のように、普段の業務と異なる題材で気軽に試せる場を設けることで、組織全体として AI コーディングエージェントの知見を共有する機会になったと感じています。今後もこのような取り組みを通じて、より実践的な AI 活用を進めていきます。

はじめに こんにちは、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 .