Coded Chords - AWS

AWSにクレジットカードが登録できない場合(三井住友カード)

2026-07-24T11:55:34+09:00

Table of Contents</summary> </details>

よくある話だと思いますが、AWSでクレジットカードを変更する際にハマったので、その対処法をまとめておきます。

AWSにクレジットカードが登録できない状況</h2>
AWSの管理アカウントで、新しいクレジットカードを支払い方法として登録しようとしたところ、 Your authentication was declined.</q> というエラーが出て登録できませんでした。
最初はカード会社側の問題を疑い、以下を確認しました。

カード自体は問題ない(別のオンラインサービスには問題なく登録できた)</li>
カードの利用明細アプリを見ても、AWSからの少額認証(オーソリ)の記録が一切ない</li> </ul>
AWSサポートに問い合わせたところ、AIでの回答は次のようなものでした。

AWS Japanのアカウントは2025年3月以降、新規クレジットカード登録時に3Dセキュア(3DS)による本人認証が必須になっている。「Your authentication was declined」は、この3DS認証ステップが完了しなかったことを示している。
(英語だったため、要約して意訳しています) </blockquote>
つまり単なるカードの与信エラーではなく、3Dセキュア連携がどこかで途切れていることが原因だという説明でした。
ただし実際には、AWS側が案内するような「銀行の3DS認証ページへのリダイレクト」や「認証用のポップアップ」自体が一度も表示されません。 Chromeの通常ウィンドウ、拡張機能をすべて無効にしたシークレットウィンドウのどちらで試しても結果は同じで、画面遷移なしにいきなり"declined"のメッセージが表示されます。
ブラウザ側の問題は考えにくく、3DS認証のリクエストがそもそもカード発行会社(三井住友カード)まで届いていないか、届く前にどこかで弾かれている可能性が高い、と推定しました。
解決策</h2>
結局のところ、根本原因(AWSとカード会社のどちらの連携不具合か)を完全に特定できません。ここは先人たちの対応方法に倣いました。
「AWSクレジットカード登録できない」などと検索すると、同じような状況に至った記事がたくさんでてきます。そこで上がっている解決策は、解決自体は驚くほどシンプルです。
カード会社に連絡し「3Dセキュアのセキュリティ解除を一時的にしてくれ」と依頼するだけです。
具体的には私が使っている三井住友カードのサポートに電話し、「AWSにこのカードを登録しようとすると3Dセキュアの連携がうまくいかない」とだけ伝えたところ、オペレーターは即座に対応し、次のような処置を提案しくれました。

カードのセキュリティ設定を15分後に解除</li>
24時間後に自動的に元の設定へ戻す</li> </ul>
この対応の直後にAWS側でカード登録を再試行したところ、あっさり成功しました。
つまり実態としては、カード発行会社側のオンライン決済向けセキュリティ機構(3DS絡みの何らかの防御設定)が、AWSからの認証リクエストを何らかの理由で処理できませんでした。カード会社側で一時的にこの認証というゲートを外してもらうだけで解決するという、拍子抜けするほどシンプルな結末でした。
AWS Japanの3DS必須化以降、同様の「認証拒否」報告はコミュニティ上でも複数見かけたので、同じ現象に遭遇している人は少なくないと思います。
仕組みとしては、AWSは入力されたカード番号全体を決済代行システム（アクワイアラ／決済プロバイダ）に送り、そこから国際ブランドのネットワーク（Visa Secure / Mastercard Identity Check等）を経由して三井住友カード（イシュア）へ認証リクエストが飛びます。
この時、三井住友カード側のイシュア認証サーバー（ACS）が受信し、内蔵するリスク判定エンジンが高リスクトランザクションと判断して自動ブロック(silent reject)しているのでしょう。
直接ブロックしているのは三井住友カード側ですが、他のサービスでは発生しないことからAWS側（またはその決済プロバイダ）に問題があるのではないかと考えています。以下のいずれかでしょう。

リスクスコアが高くなりやすいデータを送っている</dt>
AWSが3DSリクエストを送る際、端末情報・ブラウザ情報・加盟店データなどの「リスク判定に必要なコンテキスト情報」を十分にイシュア（三井住友カード）へ渡せていない、または渡しているデータの形式がカード会社の判定基準と噛み合っていない可能性がある。</dd>
判定をフリクションレス（画面なし）で通そうとしすぎる</dt>
本来リスクが疑わしいなら「ワンタイムパスワード画面（チャレンジ認証）を出す」という選択肢をカード会社に取らせるべきだが、AWSのリクエストの作法がチャレンジ認証へ遷移せず、そのままSilent Reject（即時拒否）となる仕様・データ構造という可能性がある。</dd> </dl>
めったに行なわないオペレーションですが、改善してほしいものです。
(余談) カード会社AI音声との格闘</h2>
三井住友カードのサポート窓口は、まず全面的にAI音声応対していました。
問い合わせと最初に本人確認のために生年月日を聞かれます。私の発話が明瞭でないのか、これがなかなか正しく聞き取ってもらえません。「19XX年XX月2日」のように答えても認識されず、「5日」と認識されてします。最終的に西暦・月・日をすべて数字だけの8桁の羅列(19XXXX02)として一気に読み上げたところ、ようやく認識さました。
さらに厄介なのは、今回のような「3Dセキュアの連携不具合」のような込み入った相談内容はAI音声だけでは解決できないという点です。 AIが想定しているFAQの選定フローのための一連のやりとりをして、 FAQになくAIで対応不能と結論付けさせオペレーターに繋ぐフローをうまく起動する必要があります。
これが地味に面倒でした。定型的な用件(残高照会や紛失連絡など)であればAI音声で完結するのだろうが、少しでもイレギュラーな相談だと、まず「これは人に相談すべき内容だ」とAIに判断させるところから上手く落としてあげる必要があります。
結果的に、技術的な不具合そのものよりも、電話サポートのAI(音声認識+フロー分岐)を突破する方に時間がかかった、というのがやるせない気持ちになります。

AWS障害でPayPayが利用不可にフランクフルトの一AZが世界に波及

2026-07-16T00:00:00+00:00

Table of Contents</summary> </details>
2026年7月16日17時40分頃、Amazon Web Services(AWS)のCDNサービス「Amazon CloudFront」で大規模な障害が発生しました。日本の決済サービス「PayPay」をはじめ、ニコニコ生放送、はてなブログ、noteなど多数のサービスに影響が出ています。PayPayではアプリの読み込みや決済処理ができなくなり、公式サイトや障害情報ページ自体にもアクセスできない状態に陥りました。障害発生後、PayPay側は決済手段として「オフライン支払いモード」への切り替えを利用者に案内しています。
障害詳細</h2>
発生時刻は日本時間で2026年7月16日17時40分頃(AWS公式の調査開始は現地時間1:44 AM PDT)です。症状としては、CloudFront経由のアクセスで504 Gateway Timeoutなどの5xxエラーが多発しました。日本国内ではPayPay、ニコニコ生放送、はてなブログ、noteなどが影響を受けたほか、日本、スペイン、ドイツ、オーストラリア、スウェーデン、フランス、米国、英国など世界9か国39都市以上で障害が報告されています。
日本国内で影響を受けた主なサービスは次のとおりです。
サービス</th> 影響内容</th></tr></thead>

PayPay</td> アプリの読み込み・決済処理不可、公式サイト・障害情報ページも接続不可</td></tr>
ニコニコ生放送</td> 接続しにくい状態</td></tr>
はてなブログ</td> 接続しにくい状態</td></tr>
note</td> 接続しにくい状態</td></tr> </tbody></table>
AWSのステータスサイトによると、障害の直接的な引き金はCloudFrontの「VPC Origins」機能でした。VPC Originsは、CloudFrontから顧客のプライベートVPC内にあるバックエンドリソースへ安全に接続するための機能で、これを利用している顧客側でエラーが多発しました。一方、標準的なS3オリジンなど、VPC Originsを使わない構成は影響を受けていません。AWSは応急的な回避策として、VPC Originsを使わない構成に切り替えることでエラーを回避できるとアナウンスしています。
一地域の障害が世界規模に広がった理由</h2>
今回の障害で興味深いのは、技術的な発生源が非常に局所的だった点です。障害の起点は、EU-CENTRAL-1(フランクフルト)リージョンの単一アベイラビリティゾーン「euc1-az2」に限定されていました。
つまり、物理的な不具合はドイツの1つのデータセンター群(AZ)内で起きたものにすぎません。しかし、CloudFrontはグローバルに分散した単一のCDNネットワークとしてVPC Origins接続を提供する仕組みになっているため、フランクフルトの一部で生じた問題が、世界中のエッジロケーション経由で各国のサービスへ波及する結果となりました。
これは、CDNのようにグローバルに一体運用されるインフラでは、1つのリージョンやAZの障害が地理的に無関係な地域にまで影響しうることを示す典型例といえます。東京リージョン自体には障害の原因はなく、あくまでフランクフルト発、世界巻き込み型の障害でした。
障害を事前に防げたか</h2>
クラウドを利用したシステム設計では、どのような機能であっても一時的に利用できなくなる可能性を前提に、二重化やフェイルオーバーの仕組みを組み込むのが一般的な考え方です。
今回の件で言えば、CDNをCloudFrontという単一のサービスに依存し、単一障害点になっていたことが技術的な問題点だったと考えられます。
しかし、CloudFrontは多くの技術者にとって自システムの外側に当たり前に存在するインフラという感覚に近く、これ自体が障害点になり得るという認識を持てていなかったのではないかと思います。
仮にその認識を持てていたとしても、実際に設計へ組み込むにはマルチCDN構成、例えばCloudflareなど別系統のCDNとの併用が必要になります。これはコストとのバランスから、多くの企業にとって現実的な選択肢とは言いにくいのが実情です。
まとめ</h2>
今回のPayPay障害は、PayPay自体のシステム不具合ではなく、利用しているAWS CloudFrontの障害が波及したものです。直接の原因はCloudFrontの「VPC Origins」機能における不具合で、発生源はフランクフルト(EU-CENTRAL-1)の単一AZでしたが、CloudFrontのグローバル構成により世界規模で影響が拡大しました。東京リージョン固有の問題ではなく、VPC Originsを使わないオリジン構成(S3など)は影響を受けていません。
大規模なグローバルCDNに依存するサービスが増える中、一地域の局所的な障害が世界中の決済・コンテンツサービスに連鎖する構造的リスクを改めて浮き彫りにした事例といえます。
このブログも以前はAmazon Amplify + CloudFrontで運用していました</a>が、現在はCloudflareに移行しているため今回の障害の影響は受けませんでした。ただし、CloudFrontとCloudflareはどちらも巨大なグローバルAnycast網であり、同種の相関障害リスク構造を持っています。実際、Cloudflare自体も過去に世界規模の障害を起こしています。今回無傷だったのはたまたまで、CDNの選定自体がこの種のリスクを下げるわけではありません。
References</h2>

ITmedia NEWS.「AWSで障害「CloudFront」世界規模で不調 PayPayに影響、noteやニコニコ生放送もつながりにくく」</li>
ケータイ Watch.「PayPayの障害はAWSが原因、決済は「オフライン支払いモード」を」</li>
BigGo ファイナンス.「PayPayで大規模障害、AWSのCDN不調が波及公式サイトもダウン」</li>
GIGAZINE.「AWSのCDNサービスで大規模障害発生、各種ウェブサイトに接続しにくい状態が発生」</li>
note - zephel01</a>. "Summary of AWS (Mainly CloudFront) Outage (July 16, 2026)"</li>
Sunday Guardian Live.「AWS CloudFront Outage Today: Amazon Web Services Confirms Service Disruption as '5xx Errors' Hit Websites Across Multiple Regions」</li>
The Nightly.「AWS outage update: CloudFront experience global outage, operation issue」</li> </ul> </div>

Amazon S3からCloudflare R2への移行

2026-05-22T00:00:00+00:00

以前「ブログをZolaに移行、AWSの後始末</a>」で、Next.js + Amplify構成のブログをZolaへ移し、Amplifyを含む大半のAWSリソースを削除しました。ただ、そのとき1つだけ削除せずに残したものがあります。有償のWEBフォントを配信するためのS3バケットとCloudFrontです。
本記事では、この最後のAWSリソースをCloudflare R2へ移した記録をまとめます。題材はフォント1つですが、個人ブログのスタティックなリソースをS3とR2のどちらに置くか、という選択の話でもあります。
移行前の構成</h2>
配信していたのは有償のWEBフォントです。このフォントはライセンス上、誰でもwoff2ファイルをダウンロードできる状態にしておくわけにはいきません。一方でWEBフォントである以上、ブラウザからは取得できる必要があります。この相反する要件を、移行前はAWS側で次のように満たしていました 1</a>。

woff2ファイルをS3バケットに保管し、その前段のCloudFrontから配信</li>
CloudFront FunctionでリクエストのRefererヘッダを検査し、ブログのドメイン以外からのアクセスを遮断</li>
S3バケットポリシーにも同じReferer条件を設定し、CloudFrontを経由しないS3への直接アクセスも遮断</li>
フォントがCloudFrontのドメイン(ブログとは別オリジン)から読み込まれるため、S3側のCORS設定でブログのドメインからの要求のみを許可</li> </ul>
ブログのCSSでは、すべての @font-face</code> がこのCloudFrontのURLを参照していました。
Cloudflare R2 への移行</h2> ブログのワークロードは、すでにCloudflareに移っていました。ホスティングはCloudflare Workersの静的アセット配信で動いており、フォントだけをAWSに残しておく理由は薄くなっていました。配信元をS3 + CloudFrontからCloudflare R2に移すと、次のメリットがあります。 AWSとCloudflareに分かれていたインフラの一本化</li> Referer制限のための仕組み(CloudFront Function・バケットポリシーの条件・CORS)の全廃</li> フォントの同一オリジン配信化(別オリジンへの preconnect</code> やCSP調整が不要)</li> R2のストレージ無料枠(10GB)に収まる配信コスト</li> </ul> 特に大きいのは2番目です。R2バケットは、公開設定を有効にしない限り外部から到達できるURLを持たず、フォントへのアクセス手段はWorkerからのR2 Bindingだけになります。S3 + CloudFrontでは、公開バケットへのアクセスをReferer条件で絞り込む必要がありました。R2では公開URLがそもそも存在しないため、アクセス元を判定する仕組み自体が要らなくなります。守るための要素が減ることは、設定ミスの余地が減ることでもあります。 移行後の保護モデル</h2> 新しい構成では、フォントの保護を4つのレイヤーで担保しています。 #</th> レイヤー</th> 設定の実体</th> 防ぐ脅威</th></tr></thead> 1</td> バケット非公開</td> r2.dev 無効・カスタムドメイン未割当・CORS なし</td> バケット URL の直接スクレイプ、検索エンジンの索引</td></tr> 2</td> R2 Binding 経由のみ</td> [[r2_buckets]]</code> 宣言により同一 Cloudflare アカウント内に限定</td> 他アカウントや外部ネットワークからの参照</td></tr> 3</td> Worker が公開面を制限</td> /fonts/<file></code> パスのみを公開し、不正なキーは弾く</td> パストラバーサル、任意キーの READ、バケット列挙</td></tr> 4</td> 長寿命クレデンシャル不在</td> R2 API トークンを発行しない</td> コミットや CI ログ経由のトークン漏洩</td></tr> </tbody></table> 設計の本質は、ライセンス違反が最も起きやすい経路、つまり公開バケットのURLがクローラに拾われて検索結果に載ることを消す点にあります。閲覧者がDevToolsからフォントを保存する行為や、第三者サイトからのホットリンクは別レイヤーの問題で、WEBフォント配信の仕組み上、完全には防げません。必要ならWorkerにReferer許可リストを足すこともできますが、今回は入れていません。私が利用しているフォントのライセンスでは、ライセンシーのドメインから配信することが求められていて、リクエスト元の検査までは要件になっていないためです。ただし、これはフォントごとに異なります。CORSやドメイン制限を技術的保護措置としてEULAで義務づけているフォントもあるので、利用するフォントのライセンスは必ず確認してください。 Worker と R2 の構成</h2> 実装は驚くほど小さく収まりました。まずR2バケットを作成します(ここでは web-fonts</code> という名前にします)。公開設定は無効のままにし、S3と同じキー名でwoff2をアップロードします。あとはWorkerからbindingでつなぐだけです。 wrangler.toml</code> にR2バケットのbindingを宣言します。 name = "blog" main = "src/index.js" compatibility_date = "2026-02-17" [assets] directory = "./public" binding = "ASSETS" [[r2_buckets]] binding = "FONTS" bucket_name = "web-fonts"</code></pre> Worker本体は、/fonts/</code> で始まるリクエストをR2に取り次ぎ、それ以外は静的アセットに渡すだけです。 const FONTS_PREFIX = "/fonts/"; export default { async fetch(req, env) { const url = new URL(req.url); if (url.pathname.startsWith(FONTS_PREFIX)) { const key = decodeURIComponent(url.pathname.slice(FONTS_PREFIX.length)); // Only flat keys in R2 (no subdir, no traversal). Anything else falls // through to static assets — the theme also publishes under /fonts/. if (key && !key.includes("..") && !key.includes("/")) { const obj = await env.FONTS.get(key); if (obj) { const headers = new Headers(); obj.writeHttpMetadata(headers); headers.set("Content-Type", "font/woff2"); headers.set("Cache-Control", "public, max-age=31536000, immutable"); headers.set("ETag", obj.httpEtag); return new Response(obj.body, { headers }); } } } return env.ASSETS.fetch(req); }, };</code></pre> 最後にCSSの参照先を書き換えます。@font-face</code> の src</code> は、これまでCloudFrontの絶対URLを指していましたが、同一オリジンの相対パス /fonts/</code> に変わります。 @font-face { font-family: "WebFont"; src: url("/fonts/WebFont-Regular.woff2") format("woff2"); font-display: swap; font-weight: 400; font-style: normal; }</code></pre> CSS内のすべての @font-face</code> で、CloudFrontの絶対URLを /fonts/</code> で始まる相対パスに置き換えます。デプロイはmainへのpushでGitHub Actionsが wrangler deploy</code> を実行する流れに乗せます。 つまずいた点</h2> デプロイ用のAPIトークンの権限不足でつまずきました。GitHub Actionsが使う CLOUDFLARE_API_TOKEN</code> は旧構成(静的アセット配信のみ)のときに発行したもので、Workers Scriptsの編集権限しかありませんでした。R2 bindingを含むWorkerを wrangler deploy</code> すると、宣言したバケットの存在確認でR2のAPIを呼び出すため、初回のpushは code: 10000 Authentication error</code> で失敗しました。 幸い、Cloudflare Workersのデプロイは原子的です。失敗時は旧Workerが稼働し続けるため、復旧作業中もサイトは旧CloudFront経由でフォントを配信し続け、見た目は保たれていました。 対応として、APIトークンにAccountスコープの Workers R2 Storage: Edit</code> を追加しました。最終的に付与した権限セットは次のとおりです。 スコープ</th> パーミッション</th> 用途</th></tr></thead> Account</td> Workers Scripts: Edit</td> Worker スクリプトのデプロイ</td></tr> Account</td> Workers R2 Storage: Edit</td> R2 binding 宣言時のバケット存在確認</td></tr> Account</td> Account Settings: Read</td> アカウント情報の照会</td></tr> Zone</td> Workers Routes: Edit</td> カスタムルートの設定</td></tr> User</td> Memberships: Read</td> /memberships</code> API の呼び出し</td></tr> User</td> User Details: Read</td> wrangler whoami</code> 相当の照会</td></tr> </tbody></table> Cloudflare公式の「Edit Cloudflare Workers」テンプレートにはR2の権限が含まれていません。新しいbinding(R2 / D1 / KV / Queuesなど)をWorkerに足すときは、デプロイ前にCIトークンの権限を見直すのが安全です。トークンを差し替えたあとは、失敗したジョブだけを再実行しました。 DEPLOY_ID=$(gh run list --branch main \ --workflow="<デプロイ用ワークフロー名>" --limit 1 \ --json databaseId --jq '.[0].databaseId') gh run rerun "$DEPLOY_ID" --failed</code></pre>AWS リソースの撤去</h2> R2配信が本番で安定したことを確認してから、AWS側を停止しました。撤去対象はCloudFrontディストリビューション、CloudFront Function、S3バケットの3つです。ディストリビューションIDは aws cloudfront list-distributions</code>、バケット名は aws s3 ls</code> で確認できます。以降のコマンドでは、それぞれの識別子を変数に入れてあるものとします。 DIST_ID="<対象ディストリビューションのID>" FUNCTION_NAME="<Referer を検査していた CloudFront Function 名>" BUCKET="<フォントを置いていた S3 バケット名>"</code></pre> CloudFrontディストリビューションは、いきなり削除できません。先に Enabled = false</code> で無効化し、設定が全エッジに伝播するのを待ってから削除します。 aws cloudfront get-distribution-config --id "$DIST_ID" \ > /tmp/dist-config.json jq -r '.ETag' /tmp/dist-config.json > /tmp/dist-etag.txt jq '.DistributionConfig | .Enabled = false' /tmp/dist-config.json \ > /tmp/dist-config-disabled.json aws cloudfront update-distribution --id "$DIST_ID" \ --if-match "$(cat /tmp/dist-etag.txt)" \ --distribution-config "file:///tmp/dist-config-disabled.json"</code></pre> update-distribution</code> は Status: InProgress</code> を返します。Status: Deployed</code> に戻るまで伝播を待ちます(実測で約3分)。 until [ "$(aws cloudfront get-distribution --id "$DIST_ID" \ --query 'Distribution.Status' --output text)" = "Deployed" ]; do sleep 30 done</code></pre> Deployed</code> に戻ったら削除します。 ETAG=$(aws cloudfront get-distribution --id "$DIST_ID" \ --query 'ETag' --output text) aws cloudfront delete-distribution --id "$DIST_ID" --if-match "$ETAG"</code></pre> CloudFront Functionの削除では、describe-function</code> で取得した現在のETagを delete-function</code> に渡します。注意点として、FunctionはDEVELOPMENTとLIVEの2つのステージを持ち、両者を別々に更新しているとETagが食い違います。私の環境ではDEVELOPMENT側が新しく、describe-function --stage DEVELOPMENT</code> で取ったETagでなければ PreconditionFailed</code> になりました。 ETAG=$(aws cloudfront describe-function --name "$FUNCTION_NAME" \ --stage DEVELOPMENT --query 'ETag' --output text) aws cloudfront delete-function --name "$FUNCTION_NAME" --if-match "$ETAG"</code></pre> 最後にS3バケットを空にして削除します。 aws s3 rm "s3://$BUCKET" --recursive aws s3api delete-bucket --bucket "$BUCKET"</code></pre> ACM証明書は、CloudFrontのデフォルトドメイン(*.cloudfront.net</code>)のまま運用していて発行していなかったため、削除対象はありませんでした。これでフォント配信に関わるAWSリソースはすべて無くなり、配信はR2経由に一本化されました。 移行して変わったこと</h2> 移行の前後で、AWS側にあったCloudFrontディストリビューション、CloudFront Function、S3バケット、バケットポリシー、CORS設定がすべて消えました。残ったのはR2バケット1つと、ごく短いWorkerスクリプト1つです。 今回移したのはフォント一式というごく小さなリソースで、Cloudflareの無料枠の範囲で十分にまかなえています。コスト面より、管理対象のサービス数が減ったことのほうが効きます。フォント1種類のためにCloudFrontとS3とFunctionの3サービスを横断して設定を追っていた状態から、Cloudflareのダッシュボード内で完結する状態になりました。 今回はフォントが題材でしたが、結論はもっと一般的だと考えています。個人ブログのスタティックなリソースの置き場所としては、Amazon S3 + CloudFrontよりもCloudflare R2のほうが向いています。R2なら公開URLを持たせずにWorkerから読め、S3のように公開バケットを設定で囲い込む手間がいりません。ホスティングがCloudflareにあれば置き場も同じプラットフォームにまとまり、費用も無料枠と転送料無料で個人規模なら気になりません。 S3が劣るという話ではありません。ただ、個人ブログの規模で、すでにCloudflareを使っているなら、スタティックなリソースはR2に置くのが素直な選択だと思います。 より確実な構成にするなら、S3バケットを非公開にしてOAC(Origin Access Control)経由でのみ読ませる方法もありました。ただしWEBフォントはページの一部としてブラウザに読み込まれる以上、閲覧者によるダウンロードまで完全に防ぐことはどのみちできません。完全な防御は不可能だという前提で、ある程度は妥協した構成でした。 ↩</a> </li> </ol> </section> Claude Platform on AWSに見る新時代のハイパースケーラー 2026-05-13T20:00:00+09:00 2026年5月11日、AnthropicとAWSは「Claude Platform on AWS」を一般提供開始しました。Anthropic本家のMessages APIやConsoleの体験そのものを、AWSアカウントから直接利用できる新しい入口で、東京リージョンも初日から対応しています。ただし本稿で読み解きたいのは、機能の追加そのものではなく、この発表が示すAWSの立ち位置の構造的な変化です。Bedrockとの違い、Cloud 2.0レイヤーでの位置づけ、AWS提案の現場への影響という3つの角度から見ていきます。 Table of Contents</summary> </details> Claude Platform on AWSとは何か</h2> 新サービスの概要は次のとおりです。Anthropicが運用するClaude Platformそのものを、AWSアカウントの認証情報と請求経路を介して利用できるようにしたものです。利用者から見えるエンドポイントもSDKの作法も、Anthropic本家のそれとほぼ共通しています。 具体的には、SDKに ANTHROPIC_BASE_URL=https://aws-external-anthropic.<region>.api.aws</code> と anthropic-workspace-id</code> ヘッダーを設定するだけで、Anthropic向けに書いたコードがそのままAWS経路で動きます。認証はAWSのIAM資格情報で行ない、別途Anthropicアカウントを取る必要はありません。利用料はAWS Marketplace経由で計上され、Cost Explorerでモニタリングでき、Enterprise Discount ProgramなどのAWSコミット消化対象にもなります。 使える機能はAnthropic本家とほぼ同等です。Messages APIから最新のエージェント関連機能まで一通り揃い、モデルもClaude Opus 4.7、Sonnet 4.6、Haiku 4.5を同日提供しています。新モデルや新機能がリリース当日(Day-0)から使えるという点こそ、これまでBedrock側の取り込みを待たされてきた構図が崩れた、今回の本質的な変化です。 監査はCloudTrailのManagement Eventsがデフォルトで記録され、推論呼び出しそのものはオプションでData Eventsとして流せます。 Workspaceは、APIキー・権限・課金・月次上限を環境やチーム単位で分離できる、Anthropic Console固有の論理単位です。 </aside> もう一点、Workspaceという新しい概念が入りました。これはプロジェクト・環境・チームを切り分けつつ請求単位も分けられるIAMリソースで、Anthropic Consoleにあるワークスペースの仕組みをAWS IAMの語彙で組み込んだものです。 Bedrockと何が違うのか</h2> AnthropicのモデルならBedrock経由で既に使えるのに、なぜ別の経路を用意したのか。本サービスをBedrockと比較したときのPros/Consは次のとおりです。 Pros</dt> AWSの統制・監査基盤の上で、Anthropic本家とほぼ同等の機能と最新モデルをDay-0で使える。</dd> Cons</dt> データがAWS外で扱われるため別建てのデータ管理が必要になる。加えてClaude専用のため、マルチモデル戦略は取れない。</dd> </dl> 機能面の違いを並べると次のとおりです。 観点</th> Amazon Bedrock</th> Claude Platform on AWS</th></tr></thead> 推論データの処理者・処理境界</td> AWS(AWS境界内)</td> Anthropic(AWS境界外)</td></tr> 新モデル・新機能の追随</td> 数週〜数か月遅れ</td> Day-0で揃う</td></tr> モデルベンダー多様性</td> 多ベンダー(十数社)</td> Claudeのみ</td></tr> AWS IAM / Marketplace / CloudTrail</td> 統合あり</td> 統合あり</td></tr> </tbody></table> 違いは大きく分けて、データの境界と機能の追随速度という2点に集約できます。 Bedrockの構造では、AWSが推論基盤までを自社で運用し、データ処理者としての責任を負います。推論はAWSのセキュリティ境界の内側で行われ、入力データはAnthropicへは共有されません。推論にAWSのデータ統制を要求するエンタープライズ用途に向いた構造です。 一方、Claude Platform on AWSは、認証と請求と監査こそAWSが提供しますが、推論サービス自体はAnthropicが運用する基盤で動きます。データはAWSのセキュリティ境界の外側、Anthropicの管理下で処理されます。この差はコンプライアンス上、本質的です。データレジデンシーやAWS境界内処理を契約で求めている組織には、Bedrockのほうが依然として現実解です。 逆に、Anthropicが最新モデルや新機能をリリースした瞬間からそれを使いたい組織には、Claude Platform on AWSが勝ります。Bedrockでは、Anthropic本家のAPIで先行した機能(extended thinkingやFiles APIなど)が、AWS側のコモディティ化を経て登場するまで数週間から数か月のラグが生じることも珍しくありませんでした。今回のサービスは、その間隙を埋める性格のものです。 選択軸が「データ境界と機能の速さ、どちらを優先するか」に整理されてきたことが分かります。 AIサービスにおけるAWSの役回りの変化</h2> ここからが本稿の本題です。新サービスを技術仕様として眺める以上に、AWSがどんな役回りを引き受けたのかという視点で見るほうが示唆に富みます。 Claude Platform on AWSが構造的に行っているのは、レイヤーの分離です。推論というサービス本体はAnthropicの外部基盤に置きつつ、認証(IAM)、請求(Marketplace)、監査(CloudTrail)、コミット消化といった企業ガバナンスの足回りだけをAWSが提供しています。 この構造は、Cloudflare Workersに ANTHROPIC_API_KEY</code> を環境変数で渡して、Anthropic本家のAPIを叩いているのと本質的に変わりません。違いは、認証がAPIキーではなくIAMで、請求がクレジットカードではなくAWS請求書で、ログがWorkers TraceではなくCloudTrailであることです。エンタープライズの調達と監査の要件を満たすかどうかという、その一点だけが違います。 ここでAWSが押さえている価値は、コンピュートやストレージではありません。請求と身元と監査ログを束ねる「企業の窓口」としての地位です。AWSはこれまで、Cloud 1.0期に積み上げた抽象化レイヤー、つまりEC2やS3やLambdaといったプリミティブで稼いできました。今回はそれと並行して、自社では運用していない外部の推論サービスの請求と統制を引き受けるという、新しい収益面を開いています。 これは戦略的譲歩なのか、新収益モデルなのか。私の見立ては、両面を同時に成立させる賢い設計、というところです。譲歩の側面はあります。AnthropicのモデルをBedrockに統合してきたこれまでの路線とは異なり、推論基盤の主導権をAnthropic側に残したまま窓口だけ引き受ける形だからです。一方でAWSは、Enterprise Discount Programの消化先を増やせますし、新モデル待ちでAWSを離れる顧客を引き留められます。失う主導権の代わりに、エンタープライズの窓口という地位を補強する取引です。 Cloud 0.5/1.0/2.0で見るとどこに位置するか</h2> 以前の記事</a>で、Cloudの時代区分を「Cloud 0.5(仮想化インフラ)」「Cloud 1.0(Cloud Native)」「Cloud 2.0(Agentic Cloud)」の3段で整理しました。Claude Platform on AWSはこの枠組みのどこに位置づけられるでしょうか。 本記事における「Cloud 2.0」の定義: LLMエージェントがCloudのワークロードの主役となる新しいレイヤーを指す、本記事独自の用語として用います。 </aside> Cloud 1.0期のハイパースケーラーは、抽象化レイヤーの提供者でした。物理インフラを覆い隠して、IAMやVPCやマネージドサービスといったプリミティブを通じて開発者に売る役割です。AWSがその役割で群を抜いたことが、Cloud 1.0時代の覇権をもたらしました。 Cloud 2.0期に入ると、ワークロードの主役はLLMエージェントになります。エージェントは、推論基盤、軽量実行環境、永続記憶、版管理ストレージといったプリミティブを使い倒します。ここで重要なのは、これらのプリミティブを必ずしも一社で提供する必要はないという点です。エージェントは複数のサービス境界を越えて動きますし、エンタープライズが推論をAnthropicに、実行環境をCloudflareに、ストレージをAWSにというような組み合わせを選ぶことも当たり前になりつつあります。 そう考えると、前節で論じたAWSの役回り変化は、Cloud 2.0レイヤー全体に起きている地殻変動の一場面として位置づけられます。Cloud 1.0期に培った企業ガバナンス基盤を、自社で運用しない外部の推論サービスにも貸し出す。これが今、Cloud 2.0レイヤーでハイパースケーラーが取りうる役回りのひとつで、Bedrockを併存させているのは内製と外部窓口の両方をAWSが押さえにいくという意思の表れです。 AWS提案の現場で起きる変化</h2> ここから少し業界寄りの話です。AWSのソリューション提案を生業にしてきた人々への影響を見ておきます。 これまでのBedrock案件では、「Anthropic、OpenAI、Meta、Mistralを統一APIで使い分けられる」というマルチモデル統合の価値が前面に出てきました。データレジデンシーやIAM統合と並んで、Bedrockを選ぶ理由のひとつとして語られてきた論点です。 Claude Platform on AWSの登場は、このうち「Anthropicの最新モデルを使いたい」という需要を、Bedrock以外で吸収できることを意味します。Claudeしか使わないユースケースに対しては、「Bedrockでマルチモデルを集約する」という売り文句の説得力が下がります。同じAWSの中に、Anthropic直叩きと変わらない経路が用意されたからです。 提案のロジックも組み替えが要ります。要件ごとの選択は次のように整理できます。 データレジデンシーやAWS境界内処理が契約上の必須要件 → Bedrock</li> Day-0でClaudeの新機能を使いたい、またはWorkspace単位の請求分離が必要 → Claude Platform on AWS</li> 複数モデルベンダーをユースケース別に使い分けたい → Bedrock</li> ClaudeとOpenAIの両方を本家経路で使いたい → BedrockとClaude Platform on AWSの併用</li> </ul> 選択軸が一段細かくなりました。 元AWS ProServeの目で見ると、これは案件の議論を健全にする方向の変化です。Bedrockを「とりあえずの安全牌」として薦める提案には、本来の要件と噛み合わないものが含まれていました。選択肢が増えたことで、データ境界要件か機能の追随速度かを正面から議論できるようになります。 逆に、SI側の付加価値の置き場所は前より難しくなります。「マルチモデル統合のための設計」だけでは差別化が薄まり、業務要件を踏まえてどちらの経路を選ぶか、両者をどう使い分けるかという、より上位の意思決定支援に価値が移っていきます。Cloud 1.0期にインフラ選定で稼いだロジックは、Cloud 2.0期には設計者・選定者の判断力という形に少しずつ姿を変えています。 Anthropicのキャパシティ戦略との符合</h2> 最後に、Anthropic側からこの取引を眺めておきます。 Anthropicは2026年に入ってから、AWSと$100Bを超える複数年コンピュート契約を交わし、5GW級のTrainium容量にコミットすると発表しています。一方でMicrosoft AzureやGoogle Cloudとも並行して提携を結んでおり、推論キャパシティを複数のハイパースケーラーに分散させる戦略を取っています。 TrainiumはAWSが自社開発するAI学習・推論用カスタムチップです。Nvidia GPUへの依存を減らす狙いがあり、Anthropicの大型契約はその外販ボリュームの一翼を担います。 </aside> このキャパシティを最終的に消費するのは、世界中のエンタープライズが回す推論ワークロードです。Anthropic本家APIだけでは、その消費を支えるだけの調達経路を企業に提供しきれません。クレジットカードでの直接契約は、ガバナンスの観点でエンタープライズが選びにくい経路だからです。 Claude Platform on AWSは、Anthropicからすれば「エンタープライズの調達窓口」を一気に拡張する装置です。AWSアカウントを持っている企業の調達担当は、新しいベンダーを通すことなく、既存のMarketplace経由でClaudeを使い始められます。Anthropicは推論基盤の主導権を保ったまま、AWSのエンタープライズ顧客基盤に直結できます。 AWS側から見れば、AnthropicがTrainiumに払うコンピュート料金が、別経路でエンタープライズ向けの推論売上として戻ってきます。Anthropicが請求の上流、AWSが下流という関係です。両者は競合ではなく、調達面で組み合っている構造になっています。 ここまで読むと、Claude Platform on AWSは単発のサービス発表というよりも、Anthropicの分散キャパシティ戦略とAWSの窓口ポジション戦略が噛み合った結果として出てきた仕組みであることが見えてきます。 まとめ</h2> Claude Platform on AWSは、機能カタログの一行というよりも、ハイパースケーラーの役回りが変わりつつあることを示す構造的なサインだと感じています。 Bedrockがそうであるように、AWSは引き続き「自社の推論基盤を売る側」でもあります。同時に、外部ベンダーの推論サービスに対して「請求と身元と監査の窓口」を引き受ける役割も併せ持つようになりました。Cloud 1.0期に培った企業ガバナンスの足回りが、Cloud 2.0期では別のベンダーの実行レイヤーを支える土台として再利用されています。 エンタープライズの調達担当やSIの提案担当にとっては、選択肢が増えた分だけ判断軸を明確にする必要が出てきます。データ境界要件か、機能の追随速度か、ベンダー多様性か。それぞれの要件に対して、Bedrock、Claude Platform on AWS、あるいは両者の併用という選択を素直に評価できるようになりました。 今後、同じ仕組みでOpenAIやGoogleがAWS上に乗ってくる可能性も含めて、ハイパースケーラーの窓口化はゆっくりと進む流れだと見ています。Cloud 2.0期にAWSがどの地位を確保するのか、その答えのひとつがこの発表に入っているのではないでしょうか。 References</h2> AWS Machine Learning Blog</a>.「Introducing Claude Platform on AWS, Anthropic's native platform through your AWS account」</li> AWS</a>.「Claude Platform on AWS」(製品ページ)</li> AWS What's New</a>.「Claude Platform on AWS is now generally available」</li> Anthropic</a>.「Anthropic and Amazon expand collaboration for up to 5GW of Trainium compute」(2026年4月20日)</li> About Amazon</a>.「Amazon and Anthropic expand strategic collaboration」</li> </ul> </div> rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ 2026-04-30T08:30:42+09:00 Table of Contents</summary> </details> ドローンで撮りためた動画素材がNASの容量を圧迫してきたので、編集後はほとんど触らないものをAmazon S3に退避させる仕組みを作りました。手元から外しはするものの、まとめ直しのときに見返す可能性は残しておきたい、いわばコールドアーカイブの個人運用版です。 自宅はHome 5Gで上りが20〜30Mbpsと細いため、転送には rclone</code> を使い、回線が太い場所にいるかどうかでパラメータを切り替えながらアップロードしています。さらに保管側はS3のライフサイクルで自動的にGlacier Deep Archiveに降格させ、月額数百円のレンジで運用できるようにしています。 本記事では、この「転送のチューニング」と「保管の自動化」の二段構えを、AWS側の設定からrcloneのオプション、最後にコスト試算まで通しでまとめます。 なぜAmazon S3を選んだか</h2> 「眠らせておく置き場」に求める要件はおおむね以下のとおりです。 編集後はほとんどアクセスしないが、過去作をまとめ直すときに見返すことはある</li> 手元のストレージやNASから退避させたい、しかし消したくはない</li> 容量が増えても料金がじわじわ膨らまないこと</li> 保管・削除の運用を手動でやらずに済むこと</li> </ul> クラウド側の候補としてはDropboxやBoxのようなサブスクリプション型ストレージも挙がりましたが、構造的な違いから最終的にAmazon S3を選びました。観点ごとの比較は以下のとおりです。 料金構造</dt> サブスク型は容量プラン単位の月額固定で、使っていない分にも払い続ける必要があります。S3は置いた分・使った分だけの従量課金で、「ほとんど触らないが消したくない」数百GBの素材を保管するだけなら割安に収まります。</dd> ストレージクラス</dt> サブスク型は内部的にHotストレージのみで、アクセス頻度の低いファイルでも単価は変わりません。S3はStandard / Standard-IA / Glacier / Glacier Deep Archiveと複数階層があり、Deep Archiveまで落とせばStandardより一桁安い単価で保管できます。</dd> 運用の自動化</dt> サブスク型はファイルの整理・移動・削除を手動で行う前提です。S3はライフサイクルで「3日後にDeep Archiveへ降格、2年後に削除」のようなルールを宣言的に書いておけるため、長期保管の管理コストもほぼかかりません。</dd> </dl> ひとつだけ運用上の注意点があります。S3にアップロード後すぐにNASから消してしまうと、S3が事実上の唯一コピーになります。バックアップの基本である3-2-1ルール（コピー3、媒体2、オフサイト1）の観点では、編集が完全に終わった素材であっても、NAS側を一定期間（例: 半年〜1年）残しておくと安全側に倒せます。私はNASの容量に余裕がある間は最近のフライトを残し、容量を圧迫してきたら古いものから順にNAS側を整理する運用にしています。 rcloneとは</h2> S3へのアップロードツールとしてはrclone</code>を使用しています。 rclone</code>は70以上のクラウドストレージに対応する汎用ファイル転送ツールです。S3・Google Drive・Dropbox・OneDrive・SFTP・WebDAVなどを統一的なコマンドで扱えます。rsyncのクラウド版というのが一番近い説明です。 これまではMacのGUIアプリ Transmit</a> や、コマンドラインの s3cmd</code> を使っていました。日常的なファイル転送ではどちらも十分でしたが、今回のように回線が細く中断も起こり得る環境で大量にアップロードする用途では、rclone</code> のほうが明確に向いていました。観点ごとの違いは以下のとおりです。 転送のチューニング</dt> TransmitはGUIで直感的に扱える一方、並列度やチャンクサイズなどの細かい調整はできません。s3cmd</code> もマルチスレッド転送や帯域制御は限定的です。rclone</code> は並列度・チャンクサイズ・帯域上限・リトライまで細かく指定でき、細い回線でもスループットを引き出せます。</dd> 不安定な回線への耐性</dt> rclone</code> はETagによるチェックサム比較で同一ファイルの再転送をスキップでき、リトライも「ジョブ全体」と「個別HTTPリクエスト」の2階層で設定できます。中断・再開が前提のアーカイブ運用に向いた作りです。</dd> 対応バックエンドの広さ</dt> s3cmd</code> は名前のとおりS3専用です。rclone</code> はS3以外にも多数のクラウドに同じインターフェースで対応するため、将来別のサービスに移行・併用する場合もコマンド体系を変えずに済みます。</dd> </dl> AWS側の設定</h2> 最初にAWS側で必要な準備を済ませておきます。具体的には、転送に使うIAMユーザーの権限と、保管ルールを定義するS3のライフサイクル設定の2点です。 IAMの権限設定</h3> S3バケットへのアクセス権を持つIAMユーザーを作成し、アクセスキーを発行します。ルートアカウントのキーは絶対に使わないでください。最小権限のIAMポリシー例は以下のとおりです（バケット名を video-backup</code> とする場合）。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket", "s3:GetBucketLocation"], "Resource": "arn:aws:s3:::video-backup" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "arn:aws:s3:::video-backup/*" } ] }</code></pre> s3:AbortMultipartUpload</code> はマルチパートアップロード失敗時のクリーンアップに必要です。これがないと中断したアップロードの残骸が課金対象として残り続けてしまいます。 ここまでの内容をAWS CLIで適用する手順は以下のとおりです。 # IAM ユーザーを作成 aws iam create-user --user-name rclone-backup # 上記の iam-policy.json からポリシーを作成 aws iam create-policy \ --policy-name VideoBackupPolicy \ --policy-document file://iam-policy.json # ユーザーにポリシーをアタッチ ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws iam attach-user-policy \ --user-name rclone-backup \ --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/VideoBackupPolicy # アクセスキーを発行（SecretAccessKey は一度しか表示されないので保管すること） aws iam create-access-key --user-name rclone-backup</code></pre> 最後のコマンドで返ってきた AccessKeyId</code> と SecretAccessKey</code> は、後段の rclone config</code> でそのまま使います。 S3ライフサイクルルール</h3> 長期アーカイブ用途では、ストレージクラスを段階的に下げて保管料を抑えたり、中断したマルチパートアップロードの残骸を自動で掃除するルールを入れておくと、安全かつ低コストで運用できます。以下は2つのルールを1ファイルで設定する例です。 ルール1: アップロード後3日経過したオブジェクトをGlacier Deep Archiveに移し、2年（730日）後に削除する</li> ルール2: 7日以上完了していないマルチパートアップロードを中止してパートを削除する</li> </ul> lifecycle.json</code> を用意します。 { "Rules": [ { "ID": "ArchiveAfter3DaysExpireAfter2Years", "Status": "Enabled", "Filter": {}, "Transitions": [ { "Days": 3, "StorageClass": "DEEP_ARCHIVE" } ], "Expiration": { "Days": 730 } }, { "ID": "AbortIncompleteMultipartUploadAfter7Days", "Status": "Enabled", "Filter": {}, "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 } } ] }</code></pre> バケットに適用します。 aws s3api put-bucket-lifecycle-configuration \ --bucket video-backup \ --lifecycle-configuration file://lifecycle.json</code></pre> 現在の設定を確認します。 aws s3api get-bucket-lifecycle-configuration --bucket video-backup</code></pre> 設定にあたっての注意点は以下のとおりです。 Filter: {}</code> はバケット全体が対象という意味。プレフィックスで絞るなら "Filter": {"Prefix": "video/"}</code> のように書く</li> Days</code> はオブジェクトの作成日からの経過日数。ライフサイクルの判定はUTCの00:00に1日1回走るため、設定した翌日にすぐ動くわけではない</li> Glacier Deep Archiveは最安だが、復元に最大48時間（Bulkなら数時間）かかる。「もう見ない可能性が高いがゼロではない」素材向き</li> Deep Archiveは最低保管期間が180日。180日未満で削除や移動をすると残り日数分の料金が発生する。今回は作成3日後に移して2年後（DAに約720日滞在）に削除するため、最低保管期間は十分満たす</li> 128KB未満の小さいオブジェクトはDeep Archiveへの移行対象外（移行してもStandardに留まる）。動画用途なら気にしなくて構わないが、混在バケットでは留意しておく</li> マルチパートアップロード残骸の削除ルールは、IAMポリシーの s3:AbortMultipartUpload</code> とは別に必要。IAMはクライアント側が中止する権限、ライフサイクルはS3側が自動で中止してくれる仕組みなので、両方そろえておくのが望ましい状態</li> </ul> rcloneのインストールと設定</h2> brew install rclone</code></pre> リモートの設定は rclone config</code> を起動して対話的に進めます。新規リモート作成時に入力していく項目を抜粋すると以下のとおりです（></code> の左がプロンプト、右が入力値）。 $ rclone config n) New remote name> s3-aws Storage> s3 provider> AWS env_auth> false access_key_id> AKIA... secret_access_key> ... region> ap-northeast-1 endpoint> （空欄でOK） location_constraint> ap-northeast-1 acl> private storage_class> STANDARD</code></pre> 設定ファイルは ~/.config/rclone/rclone.conf</code> に平文で保存されます。共用マシンでは取り扱いに注意してください。 rcloneの推奨パラメータ</h2> 自宅のHome 5G（上り20〜30Mbps）想定での起動例は以下のとおりです。 rclone copy ./video/ s3-aws:video-backup/ \ --transfers 2 \ --s3-chunk-size 64M \ --s3-upload-concurrency 4 \ --s3-no-check-bucket \ --checksum \ --progress \ --retries 10 \ --low-level-retries 20 \ --log-file=rclone-$(date +%Y%m%d-%H%M%S).log \ --log-level INFO</code></pre> S3では1ファイル内の並列度は --s3-upload-concurrency</code> が直接コントロールするため、--multi-thread-streams</code> は併用しません。両方指定しても効果が二重に効くわけではなく、メモリ使用量だけが増えてしまうので、S3 バックエンドでは --s3-upload-concurrency</code> に一本化 します。回線が太い環境（オフィス・コワーキングスペース等で上り100Mbps以上）では --transfers 4</code> まで増やしても問題ありません。 各オプションの意味と推奨値は以下のとおりです。 オプション</th> 推奨値</th> 説明</th></tr></thead> --transfers</td> 1〜2（細回線）/ 4（太回線）</td> 同時に転送するファイル数。Home 5G のような上り20〜30Mbps の環境では 1〜2 のほうがファイルの完了が早く、リトライ時の損失も小さい</td></tr> --s3-chunk-size</td> 64M</td> マルチパートアップロードの1パートのサイズ。デフォルト 5M を動画用途では 64M〜128M に。メモリ使用量が chunk_size × upload_concurrency × transfers</code> で増える点に注意</td></tr> --s3-upload-concurrency</td> 4</td> 1ファイル内で同時にアップロードするパート数</td></tr> --s3-no-check-bucket</td> 有効</td> バケット存在チェックをスキップ。最小権限 IAM ではデフォルトのままだと起動時のチェックがエラーになることがある</td></tr> --checksum</td> 有効</td> ETag 比較で同一ファイルの再転送をスキップ。サイズと更新時刻だけのデフォルトより確実</td></tr> --retries</td> 10</td> ジョブ全体のリトライ回数</td></tr> --low-level-retries</td> 20</td> 個別 HTTP リクエストのリトライ回数</td></tr> --progress (-P)</td> 有効</td> リアルタイムで進捗を表示</td></tr> --log-file</td> rclone-$(date +%Y%m%d-%H%M%S).log</code></td> ログをファイルに残しておくとエラー追跡や再開判断に役立つ</td></tr> --log-level</td> INFO</code>（デバッグ時 DEBUG</code>）</td> ログレベル</td></tr> --bwlimit</td> 状況に応じて</td> 上限を制限（例: 10M</code>）。--bwlimit "08:00,512k 18:00,off"</code> のように時刻指定で時間帯ごとに切り替えも可能</td></tr> </tbody></table> ライフサイクルでDeep Archiveに降格したオブジェクトに対して、rclone copy</code> で同名ファイルを再アップロードしようとすると、内部で実行されるGET（既存ファイルとのチェックサム比較）がDeep Archiveオブジェクトに対しては失敗します。同じパスに同名ファイルを再投入する用途がある場合は、--immutable</code>（同名ファイルが既に存在したら転送をスキップしてエラーにしない）か --no-traverse</code>（既存ファイルとの比較をしない）を併用するか、そもそも保存先のキー命名でタイムスタンプを含めて衝突を避けます。今回の動画アーカイブのようにファイル名がフライト日時で一意な場合は、特別な対策は不要です。 macで中断させない方法</h2> 長時間の転送中にmacOSがスリープに入ると転送が止まります。caffeinate</code> を使ってシステムスリープを抑止しながら実行します。 caffeinate</code> は macOS に標準で含まれるコマンドです。 </aside> caffeinate -i rclone copy ./video/ s3-aws:video-backup/ \ --transfers 4 \ --s3-chunk-size 64M \ --s3-upload-concurrency 4 \ --s3-no-check-bucket \ --checksum \ --progress \ --retries 10 \ --low-level-retries 20 \ --log-file=rclone-$(date +%Y%m%d-%H%M%S).log \ --log-level INFO</code></pre> 主なオプションは以下のとおりです。 -i</code> システムのアイドルスリープを防止（プロセスが終わるまで有効）</li> -d</code> ディスプレイのスリープも防止（不要なら省略）</li> -s</code> AC電源接続時のみスリープ防止</li> -u -t 3600</code> 指定秒数だけスリープ防止（プロセスを伴わない用途）</li> </ul> caffeinate</code> を前置すると、そのコマンドが終了するまで自動でスリープ抑止が解除されます。バックグラウンドで動かす場合は nohup caffeinate -i rclone copy ... &</code> のようにすれば、ターミナルを閉じても継続します（ログは --log-file</code> に必ず残しておきます）。 蓋を閉じてもスリープさせたくない場合は caffeinate</code> だけでは不十分なことがあるので、事前に以下を実行しておくか、別途 Amphetamine</a> のようなツールを使うのが確実です。 sudo pmset -a disablesleep 1 # 蓋を閉じてもスリープしない（作業後は0に戻す）</code></pre>認証情報の管理を1Password CLIに移す（2026-05-05更新）</h2> ここまでの設定では ~/.config/rclone/rclone.conf</code> にAWSのアクセスキーが平文で残ります。dotfilesで同期したり共用マシンに置く運用では避けたいので、認証情報を 1Password CLI</a> (op</code>) に移し、op run</code> で実行時に環境変数として注入する構成も用意しました。 rclone.conf</code> 側はキーを書かず、env_auth = true</code> にしてAWS標準の認証情報チェーン（環境変数→~/.aws/credentials</code>→IAMロール）から都度取得する動作に変えます。 [s3-aws] type = s3 provider = AWS env_auth = true region = ap-northeast-1 location_constraint = ap-northeast-1 acl = private storage_class = STANDARD</code></pre> 発行済みのキーは1Passwordに保管します。 op item create --category="API Credential" \ --vault=Private \ --title="rclone-backup-aws" \ username="AKIA..." \ credential="..."</code></pre> 参照用のenvテンプレートを ~/.config/rclone/s3-backup.env</code> として配置します。rclone.conf</code> と同じディレクトリで管理でき、値ではなく op://...</code> の参照しか書かれないため、dotfilesに含めて同期しても問題ありません。 AWS_ACCESS_KEY_ID=op://Private/rclone-backup-aws/username AWS_SECRET_ACCESS_KEY=op://Private/rclone-backup-aws/credential</code></pre> 実行時は op run --env-file</code> でラップし、op</code> が1Passwordから値を取り出して環境変数として注入します。先述の起動例は以下のように書き換わります。 op run --env-file="$HOME/.config/rclone/s3-backup.env" -- rclone copy ./video/ s3-aws:video-backup/ \ --transfers 2 \ --s3-chunk-size 64M \ --s3-upload-concurrency 4 \ --s3-no-check-bucket \ --checksum \ --progress \ --retries 10 \ --low-level-retries 20 \ --log-file=rclone-$(date +%Y%m%d-%H%M%S).log \ --log-level INFO</code></pre> caffeinate</code> と組み合わせる場合は、caffeinate</code> を最外殻に置きます。 caffeinate -i op run --env-file="$HOME/.config/rclone/s3-backup.env" -- rclone copy ./video/ s3-aws:video-backup/ \ --transfers 4 \ --s3-chunk-size 64M \ --s3-upload-concurrency 4 \ --s3-no-check-bucket \ --checksum \ --progress \ --retries 10 \ --low-level-retries 20 \ --log-file=rclone-$(date +%Y%m%d-%H%M%S).log \ --log-level INFO</code></pre>まとめ</h2> rcloneのチューニングとS3のライフサイクルを組み合わせて、個人データのコールドアーカイブを構築する構成をまとめました。回線の細さに左右されず転送を完了させ、長期保管のコストはストレージクラスの自動降格で抑える、という二段構えです。 参考として、私の運用パターン（月3フライト × 1回20GB = 月60GB）で運用した場合の年度ごとの料金見積もりは以下のようになります。3日後にGlacier Deep Archiveへ降格、2年で削除するライフサイクルを前提としています。NASにローカルコピーを保持しているため、S3のStandard滞在は最小限に切り詰めています。 左記は保管料のみ。取り出す場合には別途料金が発生します。 </aside>

Coded Chords - AWS

AWSにクレジットカードが登録できない場合(三井住友カード)

AWS障害でPayPayが利用不可に フランクフルトの一AZが世界に波及

Amazon S3からCloudflare R2への移行

Claude Platform on AWSに見る新時代のハイパースケーラー

AWS側の設定</h2> 最初にAWS側で必要な準備を済ませておきます。具体的には、転送に使うIAMユーザーの権限と、保管ルールを定義するS3のライフサイクル設定の2点です。</p>

AWS障害でPayPayが利用不可にフランクフルトの一AZが世界に波及

AWS側の設定</h2>
最初にAWS側で必要な準備を済ませておきます。具体的には、転送に使うIAMユーザーの権限と、保管ルールを定義するS3のライフサイクル設定の2点です。</p>