本ブログは 2025 年 10 月 17 日に公開された AWS Blog “ Securing Amazon Bedrock API keys: Best practices for implementation and management ” を翻訳したものです。 2026 年 7 月 1 日 : この記事を更新し、Mantle エンドポイントで Amazon Bedrock を使用するためのガイダンスを追加しました。 AWS では、 Amazon Bedrock API を呼び出すための Amazon Bedrock API キー が利用可能です。この記事では、Amazon Bedrock へのこのアクセス方法を効果的に実装、監視、管理するための実践的なセキュリティガイダンスを紹介し、API キーを保護する包括的な戦略の構築を支援します。また、 サービス固有の認証情報 全般についても解説します。これにより、必要に応じて AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) の実装も強化できます。 注 : 以降、この記事では サービス固有の認証情報 と API キー を同じ意味で使用します。 Amazon Bedrock へのアクセスに最適な仕組みの選択 AWS では、可能な限り AWS Security Token Service (AWS STS) が提供する一時的なセキュリティ認証情報を認証方法として優先的に使用することをお勧めします。 ユースケースの都合で一時的な AWS STS 認証情報を使用できない場合は、API キーを使用できます。代表的な例として、HTTP ベアラートークンによる API キー認証を必須とし、 一時的な AWS STS 認証情報による SigV4 署名 を使用するよう設定できないサードパーティ製ソフトウェアやパッケージソフトウェアを使用する場合が挙げられます。 API キーを使用する必要がないと判断した場合は、 サービスコントロールポリシー (SCP) を使用して、API キーの作成と使用を拒否することを検討してください。 ユースケース上 API キーが必要だと判断した場合は、次の 2 種類の API キーのどちらを使用するか検討してください。 短期 API キー : AWS STS 認証情報を使用できない場合は、短期 API キーの使用を検討してください。短期 API キーには有効期限の仕組みが組み込まれており、指定した期間が経過すると自動的に失効します。そのため、漏洩した場合でも認証情報が無期限に使用されることを防げます。 長期 API キー : 長期 API キーは、AWS STS 認証情報も短期の認証情報も使用できない場合にのみ使用してください。例えば、長期間有効な静的 API キーを前提としており、変更できないパッケージソフトウェアや SDK を使用する場合などです。 この記事で紹介するコントロールを実装すれば、API キーに関するセキュリティ上の懸念のほとんどに対処できます。ただし、セキュリティは継続的なプロセスであることを忘れないでください。包括的なセキュリティ戦略の一環として、引き続き AWS のセキュリティに関するベストプラクティスに従い、セキュリティポスチャを定期的に見直してください。 サービス固有の認証情報について サービス固有の認証情報は、特定の AWS サービスへの直接アクセスを提供する専用の認証情報です。他の AWS セキュリティ認証情報 (アクセスキー、シークレットアクセスキー、セッショントークンなど) とは異なり、特定の AWS サービスで使用するように設計されています。 サービス固有の認証情報の主な特徴は次のとおりです。 各認証情報は特定の AWS サービスに関連付けられています AWS Identity and Access Management (IAM) プリンシパルに関連付けられています AWS マネジメントコンソールと AWS コマンドラインインターフェイス (AWS CLI) の両方で管理できます AWS CloudTrail で監視できます サービス固有の認証情報 ID の プレフィックス は ACCA です 組織は SCP を使用して、サービス固有の認証情報の作成と使用を制御できます それでは、サービス固有の認証情報と、それを Amazon Bedrock で使用する方法について詳しく見ていきましょう。 Amazon Bedrock API キー Amazon Bedrock API キー は、Amazon Bedrock への直接アクセスを提供するサービス固有の認証情報です。 アクセス許可 bedrock:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock API アクションを実行できるようになります。同様に、 アクセス許可 bedrock-mantle:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock Powered by AWS Mantle API アクションを実行できるようになります。 キーの種類と特徴 API キーには 2 種類あり、それぞれ次の特徴があります。 短期 API キー 事前署名された SigV4 認証を使用します クライアント側で生成されるため、短期 API キーの作成は CloudTrail に記録されません 認証情報レポートや AWS CLI の呼び出しでは取得できません 有効期間は、API キーを生成した IAM セッションの有効期間と 12 時間のうち、短い方です キーの生成に使用したロールと同じアクセス許可を持ちます パターン: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2} 長期 API キー Amazon Bedrock コンソールから Amazon Bedrock の長期 API キーを作成すると、AWS は BedrockAPIKey-xxx という命名規則の専用 IAM ユーザーを自動的に作成し、マネージドポリシー AmazonBedrockLimitedAccess をアタッチします Amazon Bedrock コンソールから作成された IAM ユーザーでは、コンソールアクセス、コンソールパスワード、アクセスキー、多要素認証 (MFA) のいずれも有効化または設定されていません 一方、IAM コンソールから Amazon Bedrock の長期 API キーを作成する場合は、Amazon Bedrock のサービス固有の認証情報を既存の IAM ユーザーに直接関連付けることができます 各 IAM ユーザーは最大 2 つの長期 API キーを持つことができます 有効期間は 1 日から無期限までの範囲で設定できます 有効期間は、 Amazon Bedrock の API キーを管理するための新しい条件キー の 1 つである iam:ServiceSpecificCredentialAgeDays を使用して制御できます。 SCP の例 を参照してください。 パターン: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2} 長期 API キーが作成されると、次の例のように CloudTrail にイベントが記録されます。AWS CLI を使用して長期 API キーを特定することもできます。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateServiceSpecificCredential", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21", "serviceName": "bedrock.amazonaws.com", "credentialAgeDays": 36500 }, "responseElements": { "serviceSpecificCredential": { "createDate": "Jul 23, 2025, 5:39:08 PM", "expirationDate": "Oct 7, 2125, 5:39:08 PM", "serviceName": "bedrock.amazonaws.com", "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE", "serviceCredentialId": "ACCA123456789EXAMPLE", "userName": "BedrockAPIKey-0g21", "status": "Active" } } } 識別 API キーを扱う際に理解しておくべき重要な点がいくつかあります。短期 API キーはクライアント側で生成されるため、 ListServiceSpecificCredentials などの AWS API で既存の認証情報を一覧表示しても、短期 API キーは含まれません。 長期 API キーは短期 API キーより可視性が高く、複数の方法で管理できます。長期 API キーが関連付けられているプリンシパルは、 Amazon Bedrock コンソール または IAM コンソール で特定できます。また、 AWS CLI コマンドまたは AWS SDK を使用すると、指定したユーザーのサービス固有の認証情報を一覧表示できます。 防御 Amazon Bedrock では、AWS 環境における API キーの使用をより適切に制御、保護するための 4 つの条件キー が導入されました。 条件キー iam:ServiceSpecificCredentialServiceName を使用すると、プリンシパルによるサービス固有の認証情報の作成を許可する AWS サービスを指定できます。 条件キー iam:ServiceSpecificCredentialAgeDays を使用すると、長期 API キーの作成時に最大有効期間を設定して、セキュリティのベストプラクティスを適用できます。 条件キー bedrock:BearerTokenType を使用すると、Amazon Bedrock で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 条件キー bedrock-mantle:BearerTokenType を使用すると、同様に Amazon Bedrock Powered by AWS Mantle で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 これらの条件キーは、短期 API キーと長期 API キーそれぞれのセキュリティ特性の違いを管理するうえで重要な役割を果たします。セキュリティチームはこれらを利用して、AWS Organizations レベルの SCP で組織のポリシーとセキュリティのベストプラクティスを適用できます。詳細については、これらの SCP の適用例を紹介している GitHub リポジトリ を参照してください。 短期 API キーには有効期限が組み込まれているため、潜在的なセキュリティリスクにさらされる期間を抑えられます。ただし、これらのキーは署名に使用したプリンシパルのアクセス許可を継承するため、Amazon Bedrock 以外のアクセス許可も含まれる場合がある点に注意してください。包括的な監視は、 「検知」 セクションで説明する方法で実装できます。 長期 API キーは有効期間を長く設定できるため、長時間実行されるアプリケーションには便利です。ただし、認証情報が悪用されうる期間が長くなる分、それを補うためのコントロールと監視の仕組みに特に注意を払う必要があります。 組織の環境で Amazon Bedrock API キーが不要と判断した場合は、SCP を実装して、サービス固有の認証情報の作成 ( iam:CreateServiceSpecificCredential ) と、Amazon Bedrock でのベアラートークンの使用 ( bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken ) をブロックできます。 注: IAM ポリシーで条件 iam:ServiceSpecificCredentialServiceName を使用せずに iam:CreateServiceSpecificCredential を拒否すると、 AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) など、他のサービスの API キーの作成も拒否されます。 こちらの SCP の例 では、Amazon Bedrock のサービス固有の認証情報の作成と、Amazon Bedrock での API キーの使用を拒否しています。これにより、組織内のビルダーが新しい API キーを作成できなくなり、不正なキー作成のリスクを軽減できます。このアプローチは、認証方法を厳格に管理したい組織や、サービス固有の認証情報を必要とするビジネス上の理由がない組織に有効です。また、 aws:PrincipalArn に指定したプリンシパルを対象とする条件 ArnNotLikeIfExists を SCP に追加すれば、特定のロールを許可リストに登録して、サービス固有の認証情報を作成できるようにすることもできます。 API キー保護の一環として、最小権限の原則に沿ってアクセス許可を定期的に見直し、調整してください。Amazon Bedrock コンソールから長期 API キーを作成すると、AWS はマネージドポリシー AmazonBedrockLimitedAccess がアタッチされた IAM ユーザーを自動的に作成します。このポリシーは、Amazon Bedrock、 AWS Key Management Service (AWS KMS) 、IAM、 Amazon Elastic Compute Cloud (Amazon EC2) 、AWS Marketplace のさまざまなアクションへのアクセスを許可します。長期 API キーと短期 API キーのどちらについても、プリンシパルがユースケースに必要な範囲を超えるアクセス許可を持っていないか評価してください。過剰なアクセス許可が見つかった場合は、ポリシー AmazonBedrockLimitedAccess を、アクセス許可の範囲を絞り込んだカスタムポリシーに 置き換え てください。 検知 API キーには、種類に応じて異なる監視アプローチが必要です。短期 API キーはクライアント側で生成されるため作成を検知できませんが、長期 API キーの作成は CloudTrail イベントで監視できます。 Converse 、 ConverseStream 、 InvokeModel 、 InvokeModelWithResponseStream への推論呼び出しは、管理イベントとして CloudTrail に記録されます。CloudTrail に記録されるこれらのイベントを通じて、短期 API キーと長期 API キーのどちらについても、その 使用 を検知できます。長期 API キーは有効期間が長いため不正使用されやすく、包括的な監視が不可欠です。組織は、次のような厳格な監視コントロールを実装する必要があります。 CreateUser イベントのうち、ユーザー名に BedrockAPIKey- プレフィックスが付いているものを監視します。Amazon Bedrock コンソールからユーザーが作成された場合、イベントは次のようになります。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateUser", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21" }, "responseElements": { "user": { "path": "/", "userName": "BedrockAPIKey-0g21", "userId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:user/BedrockAPIKey-0g21", "createDate": "Jul 23, 2025, 5:39:08 PM" } } } CreateServiceSpecificCredential イベントのうち、 requestParameters.serviceName = bedrock.amazonaws.com を満たすものを追跡します API キーがアクティブに使用されていることを示す次の指標を監視します additionalEventData.callWithBearerToken = true eventSource = bedrock.amazonaws.com { "eventVersion": "1.11", "userIdentity": { "type": "IAMUser", "principalId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::user/BedrockAPIKey-0g21", "accountId": "", "userName": "BedrockAPIKey-0g21" }, "eventTime": "2025-07-23T17:39:37Z", "eventSource": "bedrock.amazonaws.com", "eventName": "Converse", "awsRegion": "us-east-1", "sourceIPAddress": "", "userAgent": "curl/8.11.1", "requestParameters": { "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0" }, "responseElements": null, "additionalEventData": { "callWithBearerToken": true, "inferenceRegion": "us-west-2" } } 監視すべきイベントの一覧については、「 Security Playbook for Responding to Amazon Bedrock Security Events 」を参照してください。 Amazon EventBridge ルール Amazon EventBridge ルールを実装すると、CreateServiceSpecificCredential などの Amazon Bedrock API キーのライフサイクルイベントを検知してアラートを送信できるため、セキュリティ監視を強化できます。 EventBridge ルールを使用した監視は、次の 4 つのコンポーネントで構成されます。 EventBridge ルール : CreateServiceSpecificCredentialRule と BearerTokenUsageRule が、認証情報の作成とベアラートークンの使用を CloudTrail で監視します SNS トピック : BedrockAlertsTopic が、暗号化されたセキュリティアラートを E メールで配信します KMS キー : SNSEncryptionKey が SNS メッセージを暗号化します IAM ロール: サービスの運用に必要なアクセスを提供します 前述の EventBridge ルールは、 eventName (実行されているアクション)、 eventSource (アクションの実行主体または対象となるサービス)、 additionalEventData (レスポンスの詳細を含むブロック) をキーとして、CloudTrail ログ内の特定のパターンを監視します。 次のルールは、CloudTrail イベント CreateServiceSpecificCredential をチェックします。 source: - aws.iam detail-type: - AWS API Call via CloudTrail detail: eventSource: - iam.amazonaws.com eventName: - CreateServiceSpecificCredential API キーを使用して実行されたアクション ( BearerToken = true ) を検索するには、次のルールを使用します。 detail-type: - AWS API Call via CloudTrail detail: additionalEventData: callWithBearerToken: - true EventBridge ルールのデプロイ CloudFormation テンプレート を使用すると、サービス固有の認証情報の作成とその後の使用の両方を自動で監視するよう設定できます。このテンプレートは、前述の CloudTrail イベントが検知されたときに E メール通知を送信するよう EventBridge を設定するため、環境内の API キー操作をリアルタイムで把握できます。詳細については、GitHub リポジトリにあるこのソリューションの 説明 と CloudFormation テンプレート を参照してください。 コンプライアンスのための AWS Config ルール AWS Config ルールを使用して、IAM ユーザーがアクティブなサービス固有の認証情報を持っていないかを監視することで、セキュリティポリシーへの準拠を維持しやすくなります。 AWS Config ルール は、次の手順を実行します。 AWS Config ルールが 24 時間ごとに Lambda 関数をトリガーし、この関数がアカウント内の IAM ユーザーを列挙します 関数は、ユーザーごとにアクティブなサービス固有の認証情報の有無を確認します サービス固有の認証情報を持つユーザーは NON_COMPLIANT としてマークされます アクティブな認証情報を持たないユーザーは COMPLIANT としてマークされます 結果は、レポートと必要に応じた修復のために AWS Config に送信されます AWS Config ルールのデプロイ この AWS Config ルールは、 AWS Config RDK を使用して、CloudShell またはローカルの CLI からデプロイできます。 git clone https://github.com/awslabs/aws-config-rules.git cd aws-config-rules/python-rdklib git fetch && git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS pip install rdk rdklib rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS aws configservice start-config-rules-evaluation --config-rule-names "IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS" 対応と復旧 インシデント対応計画は、いずれも準備フェーズから始まります。準備フェーズの一環として、API キーの所有者と使用状況を明確に記録し、どのアプリケーションやチームがどのキーを使用しているかを文書化してください。また、長期 API キーが必要な場合は、 AWS Secrets Manager などの安全なストレージの使用を検討してください。 API キーに関連するセキュリティインシデントが疑われる場合は、直ちに行動することが重要です。最初のステップは、CloudTrail ログを確認して API キーの作成と使用を承認済みの変更リクエストと照合し、侵害の可能性を検証することです。これにより、不正なキーの作成や使用を特定できます。さらに、これらのログに記録された送信元 IP アドレスとユーザーエージェント文字列を分析すれば、アクセス元が承認済みの場所やアプリケーションなのか、悪意のある可能性がある送信元なのかを判断できます。 インシデント対応のアプローチは、キーの種類によって大きく異なります。短期 API キーの場合、有効期限が最大 12 時間であるため潜在的な被害は限定されますが、有効期限切れを待たずに直ちに対処することが重要です。セキュリティチームは、侵害された短期 API キーを使用しているアプリケーションやシステムを特定し、IAM ロールセッションを 取り消す か、アイデンティティに対して bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken のアクセス許可を拒否する必要があります。 進行中のセキュリティイベントに Amazon Bedrock の長期 API キーが関与している場合、セキュリティチームはコンソールまたは AWS CLI を使用して直ちに対処できます。コンソールでは、IAM コンソールを使用して長期 API キーをすばやく 無効化 または 削除 できます。対応手順を自動化している組織向けには、AWS CLI にキー管理用のコマンドが用意されています。 AWS CLI を使用した対応 API キーに関するイベントに対応するには、次の手順を実行します。 サービス固有の認証情報を特定します。 aws iam list-service-specific-credentials --user-name <user name> --service-name bedrock.amazonaws.com 直ちに封じ込めるには、前の手順で取得した認証情報 ID を使用して認証情報を 無効化 します。 aws iam update-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> --status Inactive イベントを評価した後、関連付けられた API キーを 完全に削除 できます。 aws iam delete-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> 復旧フェーズでは、適切な設定で安全な新しいキーを作成し、アプリケーションの設定を更新するとともに、影響を受けるすべての継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと開発チームに変更を確実に通知することに重点を置いてください。 Amazon Bedrock API キーに関する対策の概要 次の表は、Amazon Bedrock API キーに関連するさまざまな要素を、 NIST CSF 2.0 のコア機能 に対応付けてまとめたものです。 種類 識別 防御 検知 (CloudTrail のイベントを使用) 対応 短期 API キー 短期 API キーはクライアント側で生成されるため、AWS API では一覧表示されません。 作成 : 短期 API キーはクライアント側で生成されるため、作成をブロックすることはできません。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : クライアント側で行われるため、CloudTrail にイベントは記録されません。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの使用を検知して通知するための EventBridge ルールと SNS 。 IAM ロールセッションの 取り消し 、またはアイデンティティに対するアクセス許可の拒否 長期 API キー AWS CLI または SDK を使用した IAM のアクション ListServiceSpecificCredentials 作成 : アクション iam:CreateServiceSpecificCredential を拒否すると、Amazon Bedrock を含むすべてのサービスでサービス固有の認証情報の作成をブロックできます。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : eventName が CreateServiceSpecificCredential の CloudTrail イベント。Amazon Bedrock コンソールを使用した場合は、 CreateUser イベントも対象です。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの作成と使用を検知して通知するための EventBridge ルールと SNS 。 AWS Config ルール コンソールまたは AWS CLI を使用して、長期 API キーをすばやく 無効化 または 削除 します Amazon Bedrock 以外のサービス固有の認証情報 Amazon Bedrock の API キーのほかにも、AWS CodeCommit や Amazon Keyspaces などの AWS サービスが サービス固有の認証情報をサポート しています。 この記事で紹介したセキュリティ対策は、これらのサービスにも適用できます。次の表は、これらのサービス固有の認証情報の一般的なユースケースを示しています。 サービス ユースケース iam:ListServiceSpecificCredentials のレスポンスに含まれるサービス名 推奨される代替手段 AWS CodeCommit の Git 認証情報 AWS CodeCommit リポジトリ内のファイルのアップロード、追加、編集に使用 codecommit.amazonaws.com SSH 認証やフェデレーション認証などの方法があります。詳細については、「 AWS CodeCommit: 他の方法を使用したセットアップ 」を参照してください Apache Cassandra 向けの Amazon Keyspaces 認証情報 Apache Cassandra 互換のアクセスに使用 cassandra.amazonaws.com SigV4 認証プラグインを利用できます。このプラグインは複数のプログラミング言語をサポートしており、IAM ロールやフェデレーティッドアイデンティティによる認証を可能にします。詳細については、「 IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続するための一時的な認証情報を作成する 」を参照してください まとめ 長期 API キーがもたらす影響とその管理方法を理解しておくと、Amazon Bedrock API キーの実装戦略について、十分な情報に基づいた判断を下せます。重要なのは、強固なセキュリティポスチャを維持しながら、セキュリティコントロールをリスク選好度と運用要件に合わせることです。 AWS は、可能な限り AWS STS 認証情報を主要な認証方法として使用することを強く推奨しています。AWS STS 認証情報を使用できない場合は、有効期限の仕組みが組み込まれた短期 API キーを検討してください。長期 API キーは、AWS STS 認証情報も短期の認証情報も選択肢にならない場合にのみ実装してください。API キーを実装する際に組織として重点を置くべき点は、次のとおりです。AWS CLI と CloudTrail ログを使用して API キーを識別すること、SCP などの予防的コントロールで API キーの作成と使用を管理して防御すること、CloudTrail イベント、EventBridge、AWS Config ルールによる包括的な監視で API キーのアクティビティを検知すること、そして明確なインシデント対応手順を整備し、侵害された可能性のある API キーに迅速に対応することです。 ベストプラクティスは、最小権限の原則に基づく適切なアクセスコントロールを維持しながら、これらのコントロールを実装することです。この多層的なアプローチにより、開発ニーズに合わせて API キーを効果的に活用しつつ、強固なセキュリティポスチャを維持できます。 この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 Jennifer Paz Jennifer は 10 年以上の経験を持つ Security Engineer で、現在は AWS Customer Incident Response Team (CIRT) に所属しています。お客様のセキュリティ課題の解決を支援し、セキュリティポスチャを強化するための複雑なソリューションを実装することにやりがいを感じています。仕事以外では、熱心なランナーであり、ピックルボール愛好家、旅行好き、グルメでもあり、常に新しい食の冒険を探し求めています。 Kyle Dickinson かつて Gibson を探索していた私は、今ではクラウドセキュリティの専門家です。AWS の Sr. Security Solution Architect として、かつて探索していたシステムを今は守っています。AWS のお客様を守っていないときは、LEGO 作品を組み立てたり、大けがをせずにロングボードの腕を上げようと奮闘したりしています。家庭生活は、自信たっぷりの小さな犬と、いつも笑わせてくれる元気な 4 歳の娘を中心に回っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

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 .