Coded Chords - Cloud

https://codedchords.dev • This is a web feed, also known as an Atom feed. Subscribe by copying the URL from the address bar into your newsreader. Visit About Feeds to learn more and get started. It's free. Visit website Recent posts Updated on $DATE date Cloud Coded Chords - Cloud A personal blog Zola2026-05-13T20:00:00+09:00https://codedchords.dev/tags/cloud/atom.xml Claude Platform on AWSに見る新時代のハイパースケーラー 2026-05-13T20:00:00+09:00 2026-05-13T20:00:00+09:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/05/claude-platform-aws/  <img src="https://codedchords.dev/blog/2026/05/claude-platform-aws/cover.webp?h=8abf7062e68c7aef84c7" alt="Cover" width="1536" height="1024" loading="lazy" /> <p>2026年5月11日、AnthropicとAWSは「Claude Platform on AWS」を一般提供開始しました。Anthropic本家のMessages APIやConsoleの体験そのものを、AWSアカウントから直接利用できる新しい入口で、東京リージョンも初日から対応しています。ただし本稿で読み解きたいのは、機能の追加そのものではなく、この発表が示すAWSの立ち位置の構造的な変化です。Bedrockとの違い、Cloud 2.0レイヤーでの位置づけ、AWS提案の現場への影響という3つの角度から見ていきます。</p> <span id="continue-reading"></span><details> <summary>Table of Contents</summary>  </details> <h2 id="Claude_Platform_on_AWSとは何か">Claude Platform on AWSとは何か</h2> <p>新サービスの概要は次のとおりです。Anthropicが運用するClaude Platformそのものを、AWSアカウントの認証情報と請求経路を介して利用できるようにしたものです。利用者から見えるエンドポイントもSDKの作法も、Anthropic本家のそれとほぼ共通しています。</p> <p>具体的には、SDKに <code>ANTHROPIC_BASE_URL=https://aws-external-anthropic.<region>.api.aws</code> と <code>anthropic-workspace-id</code> ヘッダーを設定するだけで、Anthropic向けに書いたコードがそのままAWS経路で動きます。認証はAWSのIAM資格情報で行ない、別途Anthropicアカウントを取る必要はありません。利用料はAWS Marketplace経由で計上され、Cost Explorerでモニタリングでき、Enterprise Discount ProgramなどのAWSコミット消化対象にもなります。</p> <p>使える機能はAnthropic本家とほぼ同等です。Messages APIから最新のエージェント関連機能まで一通り揃い、モデルもClaude Opus 4.7、Sonnet 4.6、Haiku 4.5を同日提供しています。新モデルや新機能がリリース当日(Day-0)から使えるという点こそ、これまでBedrock側の取り込みを待たされてきた構図が崩れた、今回の本質的な変化です。</p> <p>監査はCloudTrailのManagement Eventsがデフォルトで記録され、推論呼び出しそのものはオプションでData Eventsとして流せます。</p>  <aside data-position="right"> <p>Workspaceは、APIキー・権限・課金・月次上限を環境やチーム単位で分離できる、Anthropic Console固有の論理単位です。</p> </aside>  <p>もう一点、Workspaceという新しい概念が入りました。これはプロジェクト・環境・チームを切り分けつつ請求単位も分けられるIAMリソースで、Anthropic Consoleにあるワークスペースの仕組みをAWS IAMの語彙で組み込んだものです。</p> <h2 id="Bedrockと何が違うのか">Bedrockと何が違うのか</h2> <p>AnthropicのモデルならBedrock経由で既に使えるのに、なぜ別の経路を用意したのか。本サービスをBedrockと比較したときのPros/Consは次のとおりです。</p> <dl> <dt>Pros</dt> <dd>AWSの統制・監査基盤の上で、Anthropic本家とほぼ同等の機能と最新モデルをDay-0で使える。</dd> <dt>Cons</dt> <dd>データがAWS外で扱われるため別建てのデータ管理が必要になる。加えてClaude専用のため、マルチモデル戦略は取れない。</dd> </dl> <p>機能面の違いを並べると次のとおりです。</p> <table><thead><tr><th style="text-align: left">観点</th><th style="text-align: left">Amazon Bedrock</th><th style="text-align: left">Claude Platform on AWS</th></tr></thead><tbody> <tr><td style="text-align: left">推論データの処理者・処理境界</td><td style="text-align: left">AWS(AWS境界内)</td><td style="text-align: left">Anthropic(AWS境界外)</td></tr> <tr><td style="text-align: left">新モデル・新機能の追随</td><td style="text-align: left">数週〜数か月遅れ</td><td style="text-align: left">Day-0で揃う</td></tr> <tr><td style="text-align: left">モデルベンダー多様性</td><td style="text-align: left">多ベンダー(十数社)</td><td style="text-align: left">Claudeのみ</td></tr> <tr><td style="text-align: left">AWS IAM / Marketplace / CloudTrail</td><td style="text-align: left">統合あり</td><td style="text-align: left">統合あり</td></tr> </tbody></table> <p>違いは大きく分けて、データの境界と機能の追随速度という2点に集約できます。</p> <p>Bedrockの構造では、AWSが推論基盤までを自社で運用し、データ処理者としての責任を負います。推論はAWSのセキュリティ境界の内側で行われ、入力データはAnthropicへは共有されません。推論にAWSのデータ統制を要求するエンタープライズ用途に向いた構造です。</p> <p>一方、Claude Platform on AWSは、認証と請求と監査こそAWSが提供しますが、推論サービス自体はAnthropicが運用する基盤で動きます。データはAWSのセキュリティ境界の外側、Anthropicの管理下で処理されます。この差はコンプライアンス上、本質的です。データレジデンシーやAWS境界内処理を契約で求めている組織には、Bedrockのほうが依然として現実解です。</p> <p>逆に、Anthropicが最新モデルや新機能をリリースした瞬間からそれを使いたい組織には、Claude Platform on AWSが勝ります。Bedrockでは、Anthropic本家のAPIで先行した機能(extended thinkingやFiles APIなど)が、AWS側のコモディティ化を経て登場するまで数週間から数か月のラグが生じることも珍しくありませんでした。今回のサービスは、その間隙を埋める性格のものです。</p> <p>選択軸が「データ境界と機能の速さ、どちらを優先するか」に整理されてきたことが分かります。</p> <h2 id="AIサービスにおけるAWSの役回りの変化">AIサービスにおけるAWSの役回りの変化</h2> <p>ここからが本稿の本題です。新サービスを技術仕様として眺める以上に、AWSがどんな役回りを引き受けたのかという視点で見るほうが示唆に富みます。</p> <p>Claude Platform on AWSが構造的に行っているのは、レイヤーの分離です。推論というサービス本体はAnthropicの外部基盤に置きつつ、認証(IAM)、請求(Marketplace)、監査(CloudTrail)、コミット消化といった企業ガバナンスの足回りだけをAWSが提供しています。</p> <p>この構造は、Cloudflare Workersに <code>ANTHROPIC_API_KEY</code> を環境変数で渡して、Anthropic本家のAPIを叩いているのと本質的に変わりません。違いは、認証がAPIキーではなくIAMで、請求がクレジットカードではなくAWS請求書で、ログがWorkers TraceではなくCloudTrailであることです。エンタープライズの調達と監査の要件を満たすかどうかという、その一点だけが違います。</p> <p>ここでAWSが押さえている価値は、コンピュートやストレージではありません。請求と身元と監査ログを束ねる「企業の窓口」としての地位です。AWSはこれまで、Cloud 1.0期に積み上げた抽象化レイヤー、つまりEC2やS3やLambdaといったプリミティブで稼いできました。今回はそれと並行して、自社では運用していない外部の推論サービスの請求と統制を引き受けるという、新しい収益面を開いています。</p> <p>これは戦略的譲歩なのか、新収益モデルなのか。私の見立ては、両面を同時に成立させる賢い設計、というところです。譲歩の側面はあります。AnthropicのモデルをBedrockに統合してきたこれまでの路線とは異なり、推論基盤の主導権をAnthropic側に残したまま窓口だけ引き受ける形だからです。一方でAWSは、Enterprise Discount Programの消化先を増やせますし、新モデル待ちでAWSを離れる顧客を引き留められます。失う主導権の代わりに、エンタープライズの窓口という地位を補強する取引です。</p> <h2 id="Cloud_0.5/1.0/2.0で見るとどこに位置するか">Cloud 0.5/1.0/2.0で見るとどこに位置するか</h2> <p><a href="https://codedchords.dev/blog/2026/04/cloud2-0/">以前の記事</a>で、Cloudの時代区分を「Cloud 0.5(仮想化インフラ)」「Cloud 1.0(Cloud Native)」「Cloud 2.0(Agentic Cloud)」の3段で整理しました。Claude Platform on AWSはこの枠組みのどこに位置づけられるでしょうか。</p>  <aside data-position="right"> <p>本記事における「Cloud 2.0」の定義: LLMエージェントがCloudのワークロードの主役となる新しいレイヤーを指す、本記事独自の用語として用います。</p> </aside>  <p>Cloud 1.0期のハイパースケーラーは、抽象化レイヤーの提供者でした。物理インフラを覆い隠して、IAMやVPCやマネージドサービスといったプリミティブを通じて開発者に売る役割です。AWSがその役割で群を抜いたことが、Cloud 1.0時代の覇権をもたらしました。</p> <p>Cloud 2.0期に入ると、ワークロードの主役はLLMエージェントになります。エージェントは、推論基盤、軽量実行環境、永続記憶、版管理ストレージといったプリミティブを使い倒します。ここで重要なのは、これらのプリミティブを必ずしも一社で提供する必要はないという点です。エージェントは複数のサービス境界を越えて動きますし、エンタープライズが推論をAnthropicに、実行環境をCloudflareに、ストレージをAWSにというような組み合わせを選ぶことも当たり前になりつつあります。</p> <p>そう考えると、前節で論じたAWSの役回り変化は、Cloud 2.0レイヤー全体に起きている地殻変動の一場面として位置づけられます。Cloud 1.0期に培った企業ガバナンス基盤を、自社で運用しない外部の推論サービスにも貸し出す。これが今、Cloud 2.0レイヤーでハイパースケーラーが取りうる役回りのひとつで、Bedrockを併存させているのは内製と外部窓口の両方をAWSが押さえにいくという意思の表れです。</p> <h2 id="AWS提案の現場で起きる変化">AWS提案の現場で起きる変化</h2> <p>ここから少し業界寄りの話です。AWSのソリューション提案を生業にしてきた人々への影響を見ておきます。</p> <p>これまでのBedrock案件では、「Anthropic、OpenAI、Meta、Mistralを統一APIで使い分けられる」というマルチモデル統合の価値が前面に出てきました。データレジデンシーやIAM統合と並んで、Bedrockを選ぶ理由のひとつとして語られてきた論点です。</p> <p>Claude Platform on AWSの登場は、このうち「Anthropicの最新モデルを使いたい」という需要を、Bedrock以外で吸収できることを意味します。Claudeしか使わないユースケースに対しては、「Bedrockでマルチモデルを集約する」という売り文句の説得力が下がります。同じAWSの中に、Anthropic直叩きと変わらない経路が用意されたからです。</p> <p>提案のロジックも組み替えが要ります。要件ごとの選択は次のように整理できます。</p> <ul> <li>データレジデンシーやAWS境界内処理が契約上の必須要件 → Bedrock</li> <li>Day-0でClaudeの新機能を使いたい、またはWorkspace単位の請求分離が必要 → Claude Platform on AWS</li> <li>複数モデルベンダーをユースケース別に使い分けたい → Bedrock</li> <li>ClaudeとOpenAIの両方を本家経路で使いたい → BedrockとClaude Platform on AWSの併用</li> </ul> <p>選択軸が一段細かくなりました。</p> <p>元AWS ProServeの目で見ると、これは案件の議論を健全にする方向の変化です。Bedrockを「とりあえずの安全牌」として薦める提案には、本来の要件と噛み合わないものが含まれていました。選択肢が増えたことで、データ境界要件か機能の追随速度かを正面から議論できるようになります。</p> <p>逆に、SI側の付加価値の置き場所は前より難しくなります。「マルチモデル統合のための設計」だけでは差別化が薄まり、業務要件を踏まえてどちらの経路を選ぶか、両者をどう使い分けるかという、より上位の意思決定支援に価値が移っていきます。Cloud 1.0期にインフラ選定で稼いだロジックは、Cloud 2.0期には設計者・選定者の判断力という形に少しずつ姿を変えています。</p> <h2 id="Anthropicのキャパシティ戦略との符合">Anthropicのキャパシティ戦略との符合</h2> <p>最後に、Anthropic側からこの取引を眺めておきます。</p> <p>Anthropicは2026年に入ってから、AWSと$100Bを超える複数年コンピュート契約を交わし、5GW級のTrainium容量にコミットすると発表しています。一方でMicrosoft AzureやGoogle Cloudとも並行して提携を結んでおり、推論キャパシティを複数のハイパースケーラーに分散させる戦略を取っています。</p>  <aside data-position="right"> <p>TrainiumはAWSが自社開発するAI学習・推論用カスタムチップです。Nvidia GPUへの依存を減らす狙いがあり、Anthropicの大型契約はその外販ボリュームの一翼を担います。</p> </aside>  <p>このキャパシティを最終的に消費するのは、世界中のエンタープライズが回す推論ワークロードです。Anthropic本家APIだけでは、その消費を支えるだけの調達経路を企業に提供しきれません。クレジットカードでの直接契約は、ガバナンスの観点でエンタープライズが選びにくい経路だからです。</p> <p>Claude Platform on AWSは、Anthropicからすれば「エンタープライズの調達窓口」を一気に拡張する装置です。AWSアカウントを持っている企業の調達担当は、新しいベンダーを通すことなく、既存のMarketplace経由でClaudeを使い始められます。Anthropicは推論基盤の主導権を保ったまま、AWSのエンタープライズ顧客基盤に直結できます。</p> <p>AWS側から見れば、AnthropicがTrainiumに払うコンピュート料金が、別経路でエンタープライズ向けの推論売上として戻ってきます。Anthropicが請求の上流、AWSが下流という関係です。両者は競合ではなく、調達面で組み合っている構造になっています。</p> <p>ここまで読むと、Claude Platform on AWSは単発のサービス発表というよりも、Anthropicの分散キャパシティ戦略とAWSの窓口ポジション戦略が噛み合った結果として出てきた仕組みであることが見えてきます。</p> <h2 id="まとめ">まとめ</h2> <p>Claude Platform on AWSは、機能カタログの一行というよりも、ハイパースケーラーの役回りが変わりつつあることを示す構造的なサインだと感じています。</p> <p>Bedrockがそうであるように、AWSは引き続き「自社の推論基盤を売る側」でもあります。同時に、外部ベンダーの推論サービスに対して「請求と身元と監査の窓口」を引き受ける役割も併せ持つようになりました。Cloud 1.0期に培った企業ガバナンスの足回りが、Cloud 2.0期では別のベンダーの実行レイヤーを支える土台として再利用されています。</p> <p>エンタープライズの調達担当やSIの提案担当にとっては、選択肢が増えた分だけ判断軸を明確にする必要が出てきます。データ境界要件か、機能の追随速度か、ベンダー多様性か。それぞれの要件に対して、Bedrock、Claude Platform on AWS、あるいは両者の併用という選択を素直に評価できるようになりました。</p> <p>今後、同じ仕組みでOpenAIやGoogleがAWS上に乗ってくる可能性も含めて、ハイパースケーラーの窓口化はゆっくりと進む流れだと見ています。Cloud 2.0期にAWSがどの地位を確保するのか、その答えのひとつがこの発表に入っているのではないでしょうか。</p> <h2 id="References">References</h2> <div class="references"> <ul> <li><a rel="external" href="https://aws.amazon.com/blogs/machine-learning/introducing-claude-platform-on-aws-anthropics-native-platform-through-your-aws-account/">AWS Machine Learning Blog</a>.「Introducing Claude Platform on AWS, Anthropic's native platform through your AWS account」</li> <li><a rel="external" href="https://aws.amazon.com/claude-platform/">AWS</a>.「Claude Platform on AWS」(製品ページ)</li> <li><a rel="external" href="https://aws.amazon.com/about-aws/whats-new/2026/05/claude-platform-aws/">AWS What's New</a>.「Claude Platform on AWS is now generally available」</li> <li><a rel="external" href="https://www.anthropic.com/news/anthropic-amazon-compute">Anthropic</a>.「Anthropic and Amazon expand collaboration for up to 5GW of Trainium compute」(2026年4月20日)</li> <li><a rel="external" href="https://www.aboutamazon.com/news/company-news/amazon-invests-additional-5-billion-anthropic-ai">About Amazon</a>.「Amazon and Anthropic expand strategic collaboration」</li> </ul> </div>

2026年5月11日にGAされたClaude Platform on AWSは、AnthropicのネイティブAPIをAWSアカウントから直接呼べる新サービスです。この発表が示すAWSの立ち位置の構造的な変化を、Bedrockとの違い、Cloud 2.0レイヤー、AWS提案現場の3つの角度から読み解きます。

rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ 2026-04-30T08:30:42+09:00 2026-05-05T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/04/rclone/  <img src="https://codedchords.dev/blog/2026/04/rclone/cover.webp?h=549d1cce4801beb622f1" alt="Cover" width="1536" height="1024" loading="lazy" /> <details> <summary>Table of Contents</summary>  </details> <p>ドローンで撮りためた動画素材がNASの容量を圧迫してきたので、編集後はほとんど触らないものをAmazon S3に退避させる仕組みを作りました。手元から外しはするものの、まとめ直しのときに見返す可能性は残しておきたい、いわばコールドアーカイブの個人運用版です。</p> <p>自宅はHome 5Gで上りが20〜30Mbpsと細いため、転送には <code>rclone</code> を使い、回線が太い場所にいるかどうかでパラメータを切り替えながらアップロードしています。さらに保管側はS3のライフサイクルで自動的にGlacier Deep Archiveに降格させ、月額数百円のレンジで運用できるようにしています。</p> <p>本記事では、この「転送のチューニング」と「保管の自動化」の二段構えを、AWS側の設定からrcloneのオプション、最後にコスト試算まで通しでまとめます。</p> <h2 id="なぜAmazon_S3を選んだか">なぜAmazon S3を選んだか</h2> <p>「眠らせておく置き場」に求める要件はおおむね以下のとおりです。</p> <ul> <li>編集後はほとんどアクセスしないが、過去作をまとめ直すときに見返すことはある</li> <li>手元のストレージやNASから退避させたい、しかし消したくはない</li> <li>容量が増えても料金がじわじわ膨らまないこと</li> <li>保管・削除の運用を手動でやらずに済むこと</li> </ul> <p>クラウド側の候補としてはDropboxやBoxのようなサブスクリプション型ストレージも挙がりましたが、構造的な違いから最終的にAmazon S3を選びました。観点ごとの比較は以下のとおりです。</p> <dl> <dt>料金構造</dt> <dd>サブスク型は容量プラン単位の月額固定で、使っていない分にも払い続ける必要があります。S3は置いた分・使った分だけの従量課金で、「ほとんど触らないが消したくない」数百GBの素材を保管するだけなら割安に収まります。</dd> <dt>ストレージクラス</dt> <dd>サブスク型は内部的にHotストレージのみで、アクセス頻度の低いファイルでも単価は変わりません。S3はStandard / Standard-IA / Glacier / Glacier Deep Archiveと複数階層があり、Deep Archiveまで落とせばStandardより一桁安い単価で保管できます。</dd> <dt>運用の自動化</dt> <dd>サブスク型はファイルの整理・移動・削除を手動で行う前提です。S3はライフサイクルで「3日後にDeep Archiveへ降格、2年後に削除」のようなルールを宣言的に書いておけるため、長期保管の管理コストもほぼかかりません。</dd> </dl> <p>ひとつだけ運用上の注意点があります。S3にアップロード後すぐにNASから消してしまうと、S3が事実上の唯一コピーになります。バックアップの基本である3-2-1ルール（コピー3、媒体2、オフサイト1）の観点では、編集が完全に終わった素材であっても、NAS側を一定期間（例: 半年〜1年）残しておくと安全側に倒せます。私はNASの容量に余裕がある間は最近のフライトを残し、容量を圧迫してきたら古いものから順にNAS側を整理する運用にしています。</p> <h2 id="rcloneとは">rcloneとは</h2> <p>S3へのアップロードツールとしては<code>rclone</code>を使用しています。</p> <p><code>rclone</code>は70以上のクラウドストレージに対応する汎用ファイル転送ツールです。S3・Google Drive・Dropbox・OneDrive・SFTP・WebDAVなどを統一的なコマンドで扱えます。rsyncのクラウド版というのが一番近い説明です。</p> <p>これまではMacのGUIアプリ <a rel="external" href="https://panic.com/transmit/">Transmit</a> や、コマンドラインの <code>s3cmd</code> を使っていました。日常的なファイル転送ではどちらも十分でしたが、今回のように回線が細く中断も起こり得る環境で大量にアップロードする用途では、<code>rclone</code> のほうが明確に向いていました。観点ごとの違いは以下のとおりです。</p> <dl> <dt>転送のチューニング</dt> <dd>TransmitはGUIで直感的に扱える一方、並列度やチャンクサイズなどの細かい調整はできません。<code>s3cmd</code> もマルチスレッド転送や帯域制御は限定的です。<code>rclone</code> は並列度・チャンクサイズ・帯域上限・リトライまで細かく指定でき、細い回線でもスループットを引き出せます。</dd> <dt>不安定な回線への耐性</dt> <dd><code>rclone</code> はETagによるチェックサム比較で同一ファイルの再転送をスキップでき、リトライも「ジョブ全体」と「個別HTTPリクエスト」の2階層で設定できます。中断・再開が前提のアーカイブ運用に向いた作りです。</dd> <dt>対応バックエンドの広さ</dt> <dd><code>s3cmd</code> は名前のとおりS3専用です。<code>rclone</code> はS3以外にも多数のクラウドに同じインターフェースで対応するため、将来別のサービスに移行・併用する場合もコマンド体系を変えずに済みます。</dd> </dl> <h2 id="AWS側の設定">AWS側の設定</h2> <p>最初にAWS側で必要な準備を済ませておきます。具体的には、転送に使うIAMユーザーの権限と、保管ルールを定義するS3のライフサイクル設定の2点です。</p> <h3 id="IAMの権限設定">IAMの権限設定</h3> <p>S3バケットへのアクセス権を持つIAMユーザーを作成し、アクセスキーを発行します。ルートアカウントのキーは絶対に使わないでください。最小権限のIAMポリシー例は以下のとおりです（バケット名を <code>video-backup</code> とする場合）。</p> <pre class="giallo z-code"><code data-lang="json" data-name="iam-policy.json"><span class="giallo-l"><span class="z-punctuation">{</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Version</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "2012-10-17"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Statement</span><span class="z-punctuation">": [</span></span> <span class="giallo-l"><span class="z-punctuation"> {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Effect</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "Allow"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Action</span><span class="z-punctuation">": [</span><span class="z-punctuation z-definition z-string z-string">"s3:ListBucket"</span><span class="z-punctuation">,</span><span class="z-punctuation z-definition z-string z-string"> "s3:GetBucketLocation"</span><span class="z-punctuation">],</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Resource</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "arn:aws:s3:::video-backup"</span></span> <span class="giallo-l"><span class="z-punctuation"> },</span></span> <span class="giallo-l"><span class="z-punctuation"> {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Effect</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "Allow"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Action</span><span class="z-punctuation">": [</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string z-string"> "s3:PutObject"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string z-string"> "s3:GetObject"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string z-string"> "s3:DeleteObject"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string z-string"> "s3:AbortMultipartUpload"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation z-definition z-string z-string"> "s3:ListMultipartUploadParts"</span></span> <span class="giallo-l"><span class="z-punctuation"> ],</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Resource</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "arn:aws:s3:::video-backup/*"</span></span> <span class="giallo-l"><span class="z-punctuation"> }</span></span> <span class="giallo-l"><span class="z-punctuation"> ]</span></span> <span class="giallo-l"><span class="z-punctuation">}</span></span></code></pre> <p><code>s3:AbortMultipartUpload</code> はマルチパートアップロード失敗時のクリーンアップに必要です。これがないと中断したアップロードの残骸が課金対象として残り続けてしまいます。</p> <p>ここまでの内容をAWS CLIで適用する手順は以下のとおりです。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># IAM ユーザーを作成</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> iam create-user --user-name rclone-backup</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># 上記の iam-policy.json からポリシーを作成</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> iam create-policy</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --policy-name VideoBackupPolicy</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --policy-document file://iam-policy.json</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># ユーザーにポリシーをアタッチ</span></span> <span class="giallo-l"><span class="z-source">ACCOUNT_ID</span><span class="z-keyword z-operator">=</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">aws</span><span class="z-string"> sts get-caller-identity --query Account --output text</span><span class="z-punctuation">)</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> iam attach-user-policy</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --user-name rclone-backup</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --policy-arn arn:aws:iam::</span><span class="z-punctuation z-definition z-variable z-source">${ACCOUNT_ID}</span><span class="z-string">:policy/VideoBackupPolicy</span></span> <span class="giallo-l"></span> <span class="giallo-l"><span class="z-punctuation z-definition z-comment z-comment"># アクセスキーを発行（SecretAccessKey は一度しか表示されないので保管すること）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> iam create-access-key --user-name rclone-backup</span></span></code></pre> <p>最後のコマンドで返ってきた <code>AccessKeyId</code> と <code>SecretAccessKey</code> は、後段の <code>rclone config</code> でそのまま使います。</p> <h3 id="S3ライフサイクルルール">S3ライフサイクルルール</h3> <p>長期アーカイブ用途では、ストレージクラスを段階的に下げて保管料を抑えたり、中断したマルチパートアップロードの残骸を自動で掃除するルールを入れておくと、安全かつ低コストで運用できます。以下は2つのルールを1ファイルで設定する例です。</p> <ul> <li>ルール1: アップロード後3日経過したオブジェクトをGlacier Deep Archiveに移し、2年（730日）後に削除する</li> <li>ルール2: 7日以上完了していないマルチパートアップロードを中止してパートを削除する</li> </ul> <p><code>lifecycle.json</code> を用意します。</p> <pre class="giallo z-code"><code data-lang="json" data-name="lifecycle.json"><span class="giallo-l"><span class="z-punctuation">{</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Rules</span><span class="z-punctuation">": [</span></span> <span class="giallo-l"><span class="z-punctuation"> {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">ID</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "ArchiveAfter3DaysExpireAfter2Years"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Status</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "Enabled"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Filter</span><span class="z-punctuation">": {},</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Transitions</span><span class="z-punctuation">": [</span></span> <span class="giallo-l"><span class="z-punctuation"> {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Days</span><span class="z-punctuation">":</span><span class="z-constant z-numeric"> 3</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">StorageClass</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "DEEP_ARCHIVE"</span></span> <span class="giallo-l"><span class="z-punctuation"> }</span></span> <span class="giallo-l"><span class="z-punctuation"> ],</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Expiration</span><span class="z-punctuation">": {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Days</span><span class="z-punctuation">":</span><span class="z-constant z-numeric"> 730</span></span> <span class="giallo-l"><span class="z-punctuation"> }</span></span> <span class="giallo-l"><span class="z-punctuation"> },</span></span> <span class="giallo-l"><span class="z-punctuation"> {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">ID</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "AbortIncompleteMultipartUploadAfter7Days"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Status</span><span class="z-punctuation">":</span><span class="z-punctuation z-definition z-string z-string"> "Enabled"</span><span class="z-punctuation">,</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">Filter</span><span class="z-punctuation">": {},</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">AbortIncompleteMultipartUpload</span><span class="z-punctuation">": {</span></span> <span class="giallo-l"><span class="z-punctuation"> "</span><span class="z-support z-type z-property-name z-json">DaysAfterInitiation</span><span class="z-punctuation">":</span><span class="z-constant z-numeric"> 7</span></span> <span class="giallo-l"><span class="z-punctuation"> }</span></span> <span class="giallo-l"><span class="z-punctuation"> }</span></span> <span class="giallo-l"><span class="z-punctuation"> ]</span></span> <span class="giallo-l"><span class="z-punctuation">}</span></span></code></pre> <p>バケットに適用します。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> s3api put-bucket-lifecycle-configuration</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --bucket video-backup</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --lifecycle-configuration file://lifecycle.json</span></span></code></pre> <p>現在の設定を確認します。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">aws</span><span class="z-string"> s3api get-bucket-lifecycle-configuration --bucket video-backup</span></span></code></pre> <p>設定にあたっての注意点は以下のとおりです。</p> <ul> <li><code>Filter: {}</code> はバケット全体が対象という意味。プレフィックスで絞るなら <code>"Filter": {"Prefix": "video/"}</code> のように書く</li> <li><code>Days</code> はオブジェクトの作成日からの経過日数。ライフサイクルの判定はUTCの00:00に1日1回走るため、設定した翌日にすぐ動くわけではない</li> <li>Glacier Deep Archiveは最安だが、復元に最大48時間（Bulkなら数時間）かかる。「もう見ない可能性が高いがゼロではない」素材向き</li> <li>Deep Archiveは最低保管期間が180日。180日未満で削除や移動をすると残り日数分の料金が発生する。今回は作成3日後に移して2年後（DAに約720日滞在）に削除するため、最低保管期間は十分満たす</li> <li>128KB未満の小さいオブジェクトはDeep Archiveへの移行対象外（移行してもStandardに留まる）。動画用途なら気にしなくて構わないが、混在バケットでは留意しておく</li> <li>マルチパートアップロード残骸の削除ルールは、IAMポリシーの <code>s3:AbortMultipartUpload</code> とは別に必要。IAMはクライアント側が中止する権限、ライフサイクルはS3側が自動で中止してくれる仕組みなので、両方そろえておくのが望ましい状態</li> </ul> <h2 id="rcloneのインストールと設定">rcloneのインストールと設定</h2> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">brew</span><span class="z-string"> install rclone</span></span></code></pre> <p>リモートの設定は <code>rclone config</code> を起動して対話的に進めます。新規リモート作成時に入力していく項目を抜粋すると以下のとおりです（<code>></code> の左がプロンプト、右が入力値）。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">$</span><span class="z-string"> rclone config</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">n</span><span class="z-source">) New remote</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">name</span><span class="z-source">></span><span class="z-string"> s3-aws</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">Storage</span><span class="z-source">></span><span class="z-string"> s3</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">provider</span><span class="z-source">></span><span class="z-string"> AWS</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">env_auth</span><span class="z-source">></span><span class="z-constant z-language z-false"> false</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">access_key_id</span><span class="z-source">></span><span class="z-string"> AKIA...</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">secret_access_key</span><span class="z-source">></span><span class="z-string"> ...</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">region</span><span class="z-source">></span><span class="z-string"> ap-northeast-1</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">endpoint</span><span class="z-source">></span><span class="z-string"> （空欄でOK）</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">location_constraint</span><span class="z-source">></span><span class="z-string"> ap-northeast-1</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">acl</span><span class="z-source">></span><span class="z-string"> private</span></span> <span class="giallo-l"><span class="z-entity z-name z-function">storage_class</span><span class="z-source">></span><span class="z-string"> STANDARD</span></span></code></pre> <p>設定ファイルは <code>~/.config/rclone/rclone.conf</code> に<strong>平文</strong>で保存されます。共用マシンでは取り扱いに注意してください。</p> <h2 id="rcloneの推奨パラメータ">rcloneの推奨パラメータ</h2> <p>自宅のHome 5G（上り20〜30Mbps）想定での起動例は以下のとおりです。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">rclone</span><span class="z-string"> copy ./video/ s3-aws:video-backup/</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --transfers</span><span class="z-constant z-numeric"> 2</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-chunk-size 64M</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-upload-concurrency</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-no-check-bucket</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --checksum</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --progress</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --retries</span><span class="z-constant z-numeric"> 10</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --low-level-retries</span><span class="z-constant z-numeric"> 20</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-file=rclone-</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d-%H%M%S</span><span class="z-punctuation">)</span><span class="z-string">.log</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-level INFO</span></span></code></pre> <p>S3では1ファイル内の並列度は <code>--s3-upload-concurrency</code> が直接コントロールするため、<code>--multi-thread-streams</code> は併用しません。両方指定しても効果が二重に効くわけではなく、メモリ使用量だけが増えてしまうので、<strong>S3 バックエンドでは <code>--s3-upload-concurrency</code> に一本化</strong> します。回線が太い環境（オフィス・コワーキングスペース等で上り100Mbps以上）では <code>--transfers 4</code> まで増やしても問題ありません。</p> <p>各オプションの意味と推奨値は以下のとおりです。</p> <table><thead><tr><th>オプション</th><th>推奨値</th><th>説明</th></tr></thead><tbody> <tr><td>--transfers</td><td>1〜2（細回線）/ 4（太回線）</td><td>同時に転送するファイル数。Home 5G のような上り20〜30Mbps の環境では 1〜2 のほうがファイルの完了が早く、リトライ時の損失も小さい</td></tr> <tr><td>--s3-chunk-size</td><td>64M</td><td>マルチパートアップロードの1パートのサイズ。デフォルト 5M を動画用途では 64M〜128M に。メモリ使用量が <code>chunk_size × upload_concurrency × transfers</code> で増える点に注意</td></tr> <tr><td>--s3-upload-concurrency</td><td>4</td><td>1ファイル内で同時にアップロードするパート数</td></tr> <tr><td>--s3-no-check-bucket</td><td>有効</td><td>バケット存在チェックをスキップ。最小権限 IAM ではデフォルトのままだと起動時のチェックがエラーになることがある</td></tr> <tr><td>--checksum</td><td>有効</td><td>ETag 比較で同一ファイルの再転送をスキップ。サイズと更新時刻だけのデフォルトより確実</td></tr> <tr><td>--retries</td><td>10</td><td>ジョブ全体のリトライ回数</td></tr> <tr><td>--low-level-retries</td><td>20</td><td>個別 HTTP リクエストのリトライ回数</td></tr> <tr><td>--progress (-P)</td><td>有効</td><td>リアルタイムで進捗を表示</td></tr> <tr><td>--log-file</td><td><code>rclone-$(date +%Y%m%d-%H%M%S).log</code></td><td>ログをファイルに残しておくとエラー追跡や再開判断に役立つ</td></tr> <tr><td>--log-level</td><td><code>INFO</code>（デバッグ時 <code>DEBUG</code>）</td><td>ログレベル</td></tr> <tr><td>--bwlimit</td><td>状況に応じて</td><td>上限を制限（例: <code>10M</code>）。<code>--bwlimit "08:00,512k 18:00,off"</code> のように時刻指定で時間帯ごとに切り替えも可能</td></tr> </tbody></table> <p>ライフサイクルでDeep Archiveに降格したオブジェクトに対して、<code>rclone copy</code> で同名ファイルを再アップロードしようとすると、内部で実行されるGET（既存ファイルとのチェックサム比較）がDeep Archiveオブジェクトに対しては失敗します。同じパスに同名ファイルを再投入する用途がある場合は、<code>--immutable</code>（同名ファイルが既に存在したら転送をスキップしてエラーにしない）か <code>--no-traverse</code>（既存ファイルとの比較をしない）を併用するか、そもそも保存先のキー命名でタイムスタンプを含めて衝突を避けます。今回の動画アーカイブのようにファイル名がフライト日時で一意な場合は、特別な対策は不要です。</p> <h2 id="macで中断させない方法">macで中断させない方法</h2> <p>長時間の転送中にmacOSがスリープに入ると転送が止まります。<code>caffeinate</code> を使ってシステムスリープを抑止しながら実行します。</p>  <aside data-position="right"> <p><code>caffeinate</code> は macOS に標準で含まれるコマンドです。</p> </aside>  <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">caffeinate</span><span class="z-string"> -i rclone copy ./video/ s3-aws:video-backup/</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --transfers</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-chunk-size 64M</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-upload-concurrency</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-no-check-bucket</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --checksum</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --progress</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --retries</span><span class="z-constant z-numeric"> 10</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --low-level-retries</span><span class="z-constant z-numeric"> 20</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-file=rclone-</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d-%H%M%S</span><span class="z-punctuation">)</span><span class="z-string">.log</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-level INFO</span></span></code></pre> <p>主なオプションは以下のとおりです。</p> <ul> <li><code>-i</code> システムのアイドルスリープを防止（プロセスが終わるまで有効）</li> <li><code>-d</code> ディスプレイのスリープも防止（不要なら省略）</li> <li><code>-s</code> AC電源接続時のみスリープ防止</li> <li><code>-u -t 3600</code> 指定秒数だけスリープ防止（プロセスを伴わない用途）</li> </ul> <p><code>caffeinate</code> を前置すると、そのコマンドが終了するまで自動でスリープ抑止が解除されます。バックグラウンドで動かす場合は <code>nohup caffeinate -i rclone copy ... &</code> のようにすれば、ターミナルを閉じても継続します（ログは <code>--log-file</code> に必ず残しておきます）。</p> <p>蓋を閉じてもスリープさせたくない場合は <code>caffeinate</code> だけでは不十分なことがあるので、事前に以下を実行しておくか、別途 <a rel="external" href="https://apps.apple.com/app/amphetamine/id937984704">Amphetamine</a> のようなツールを使うのが確実です。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">sudo</span><span class="z-string"> pmset -a disablesleep</span><span class="z-constant z-numeric"> 1</span><span class="z-punctuation z-definition z-comment z-comment"> # 蓋を閉じてもスリープしない（作業後は0に戻す）</span></span></code></pre><h2 id="認証情報の管理を1Password_CLIに移す（2026-05-05更新）">認証情報の管理を1Password CLIに移す（2026-05-05更新）</h2> <p>ここまでの設定では <code>~/.config/rclone/rclone.conf</code> にAWSのアクセスキーが平文で残ります。dotfilesで同期したり共用マシンに置く運用では避けたいので、認証情報を <a rel="external" href="https://developer.1password.com/docs/cli/">1Password CLI</a> (<code>op</code>) に移し、<code>op run</code> で実行時に環境変数として注入する構成も用意しました。</p> <p><code>rclone.conf</code> 側はキーを書かず、<code>env_auth = true</code> にしてAWS標準の認証情報チェーン（環境変数→<code>~/.aws/credentials</code>→IAMロール）から都度取得する動作に変えます。</p> <pre class="giallo z-code"><code data-lang="ini" data-name="~/.config/rclone/rclone.conf"><span class="giallo-l"><span class="z-punctuation">[</span><span class="z-entity z-name z-section z-group-title z-ini">s3-aws</span><span class="z-punctuation">]</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">type</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> s3</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">provider</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> AWS</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">env_auth</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> true</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">region</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> ap-northeast-1</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">location_constraint</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> ap-northeast-1</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">acl</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> private</span></span> <span class="giallo-l"><span class="z-keyword z-other z-definition z-ini">storage_class</span><span class="z-punctuation z-separator z-key-value"> =</span><span class="z-source"> STANDARD</span></span></code></pre> <p>発行済みのキーは1Passwordに保管します。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">op</span><span class="z-string z-punctuation z-definition z-string"> item create --category="API Credential"</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --vault=Private</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string z-punctuation z-definition z-string"> --title="rclone-backup-aws"</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string z-punctuation z-definition z-string"> username="AKIA..."</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string z-punctuation z-definition z-string"> credential="..."</span></span></code></pre> <p>参照用のenvテンプレートを <code>~/.config/rclone/s3-backup.env</code> として配置します。<code>rclone.conf</code> と同じディレクトリで管理でき、値ではなく <code>op://...</code> の参照しか書かれないため、dotfilesに含めて同期しても問題ありません。</p> <pre class="giallo z-code"><code data-lang="shellscript" data-name="~/.config/rclone/s3-backup.env"><span class="giallo-l"><span class="z-source">AWS_ACCESS_KEY_ID</span><span class="z-keyword z-operator">=</span><span class="z-string">op://Private/rclone-backup-aws/username</span></span> <span class="giallo-l"><span class="z-source">AWS_SECRET_ACCESS_KEY</span><span class="z-keyword z-operator">=</span><span class="z-string">op://Private/rclone-backup-aws/credential</span></span></code></pre> <p>実行時は <code>op run --env-file</code> でラップし、<code>op</code> が1Passwordから値を取り出して環境変数として注入します。先述の起動例は以下のように書き換わります。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">op</span><span class="z-string z-punctuation z-definition z-string"> run --env-file="</span><span class="z-variable z-other z-normal z-shell">$HOME</span><span class="z-string z-punctuation z-definition z-string">/.config/rclone/s3-backup.env" -- rclone copy ./video/ s3-aws:video-backup/</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --transfers</span><span class="z-constant z-numeric"> 2</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-chunk-size 64M</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-upload-concurrency</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-no-check-bucket</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --checksum</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --progress</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --retries</span><span class="z-constant z-numeric"> 10</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --low-level-retries</span><span class="z-constant z-numeric"> 20</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-file=rclone-</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d-%H%M%S</span><span class="z-punctuation">)</span><span class="z-string">.log</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-level INFO</span></span></code></pre> <p><code>caffeinate</code> と組み合わせる場合は、<code>caffeinate</code> を最外殻に置きます。</p> <pre class="giallo z-code"><code data-lang="shellscript"><span class="giallo-l"><span class="z-entity z-name z-function">caffeinate</span><span class="z-string z-punctuation z-definition z-string"> -i op run --env-file="</span><span class="z-variable z-other z-normal z-shell">$HOME</span><span class="z-string z-punctuation z-definition z-string">/.config/rclone/s3-backup.env" -- rclone copy ./video/ s3-aws:video-backup/</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --transfers</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-chunk-size 64M</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-upload-concurrency</span><span class="z-constant z-numeric"> 4</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --s3-no-check-bucket</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --checksum</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --progress</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --retries</span><span class="z-constant z-numeric"> 10</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --low-level-retries</span><span class="z-constant z-numeric"> 20</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-file=rclone-</span><span class="z-punctuation">$(</span><span class="z-entity z-name z-function">date</span><span class="z-string"> +%Y%m%d-%H%M%S</span><span class="z-punctuation">)</span><span class="z-string">.log</span><span class="z-constant z-character z-escape"> \</span></span> <span class="giallo-l"><span class="z-string"> --log-level INFO</span></span></code></pre><h2 id="まとめ">まとめ</h2> <p>rcloneのチューニングとS3のライフサイクルを組み合わせて、個人データのコールドアーカイブを構築する構成をまとめました。回線の細さに左右されず転送を完了させ、長期保管のコストはストレージクラスの自動降格で抑える、という二段構えです。</p> <p>参考として、私の運用パターン（月3フライト × 1回20GB = 月60GB）で運用した場合の年度ごとの料金見積もりは以下のようになります。3日後にGlacier Deep Archiveへ降格、2年で削除するライフサイクルを前提としています。NASにローカルコピーを保持しているため、S3のStandard滞在は最小限に切り詰めています。</p>  <aside data-position="right"> <p>左記は保管料のみ。取り出す場合には別途料金が発生します。</p> </aside> <noscript> <strong>⚠️ JavaScript is required to render the diagram.</strong> </noscript> <pre class="mermaid invertible-image"> xychart-beta title "年度ごとのS3保管料金（千円）" x-axis ["1年目", "2年目", "3年目", "4年目", "5年目"] y-axis "料金（千円）" 0 --> 7 bar [1.6, 4.2, 5.5, 5.5, 5.5] </pre>  <p>1〜2年目はDeep Archive側に毎年720GBずつ積み上がるため線形に増加し、3年目以降は毎月のアップロード分と削除分が釣り合って定常状態に入り、年額 ¥5,500程度・累積保管量約1.5TBで頭打ちになります。月額換算すると ¥460程度で、Standard滞在を3日に切り詰めることで、料金のほぼ全てがDeep Archiveの単価で支配される構成です。料金は1ドル=¥150換算、AWSの公開価格（ap-northeast-1、執筆時点）に基づく概算なので、実費は為替・価格改定・取り出し料金で変動します。</p> <p>この設計の枠組みは、データ特性に合わせて他の用途にも応用できます。私は同じS3アカウントでLogic Proの楽曲プロジェクト（月4曲、1曲500MB）も管理しており、こちらは「再編集の可能性が長く残る」という性質に合わせて、Standard滞在を1年・削除を10年に設定しています。</p> <table><thead><tr><th>用途</th><th>月次</th><th>Std→DA</th><th>削除</th><th>定常年額</th><th>定常容量</th></tr></thead><tbody> <tr><td>ドローン動画</td><td>60 GB</td><td>3日</td><td>2年</td><td>¥5,500</td><td>1.5 TB</td></tr> <tr><td>楽曲プロジェクト</td><td>2 GB</td><td>1年</td><td>10年</td><td>¥1,900</td><td>240 GB</td></tr> </tbody></table> <p>両方合算しても月額 ¥620程度、合計約1.7TBです。データの性格に応じてライフサイクルを分ければ、同じ仕組みで複数の用途を最適化できます。</p>

ドローンの動画素材やLogic Proの楽曲データなど、編集後はほとんど触らないが消したくないデータの「眠らせ場所」を、Amazon S3とrcloneで構築した記録です。細回線でも止まらない転送のチューニングから、Glacier Deep Archiveを使った長期保管のコスト設計まで、二段構えでまとめました。

Cloudflare Agents Week 2026が告げるCloud 2.0時代: エンタープライズの主戦場が移る 2026-04-27T07:00:13+09:00 2026-04-27T07:00:13+09:00 Toshiyuki Yoshida https://codedchords.dev/blog/2026/04/cloud2-0/  <img src="https://codedchords.dev/blog/2026/04/cloud2-0/cover.webp?h=aa99350328ab1f917f77" alt="Cover" width="1536" height="1024" loading="lazy" /> <p>Cloudflareは2026年4月13日〜17日に「Agents Week 2026」を開催して、10個以上の新機能を一気に発表しました。新機能の多くが、LLMエージェント(Claude Codeのような「目的を与えられたら、自律的に考え道具を使いタスクを完遂するLLMを使った仕組み」)に関連したものです。</p> <p>Cloudflareがエージェント向けプラットフォームのロードマップを一気に開示しきった印象的な5日間でした。</p> <details> <summary>Table of Contents</summary>  </details> <h2 id="Cloud_2.0の時代">Cloud 2.0の時代</h2> <p>今回の発表をまとめて眺めると、Cloudの変遷は次のように整理できます。「Cloud x.0」という言い回しが使い古されているのは承知の上で、それでも今回の地殻変動を端的に表すのに「Cloud 2.0」はちょうど良い言葉だと感じています。</p>  <aside data-position="right"> <p>本記事における「Cloud 2.0」の定義: LLMエージェントがCloudのワークロードの主役となる新しいレイヤーを指す、本記事独自の用語として用います。過去に同じ表記が別の意味で使われてきた経緯がありますが、本記事の主張とは無関係です。</p> </aside>  <table><thead><tr><th style="text-align: left">世代</th><th style="text-align: left">呼称</th><th style="text-align: left">本質的な役割</th><th style="text-align: left">操作主体 (Who)</th><th style="text-align: left">主な関心事・技術</th></tr></thead><tbody> <tr><td style="text-align: left"><strong>Cloud 0.5</strong></td><td style="text-align: left"><strong>仮想化インフラ</strong></td><td style="text-align: left"><strong>「場所」の移動</strong></td><td style="text-align: left">インフラ担当者 (手動)</td><td style="text-align: left">リフト＆シフト、VM、データセンターの仮想化</td></tr> <tr><td style="text-align: left"><strong>Cloud 1.0</strong></td><td style="text-align: left"><strong>Cloud Native</strong></td><td style="text-align: left"><strong>「構造」の最適化</strong></td><td style="text-align: left">開発者 (コード/API)</td><td style="text-align: left">マネージドサービス、K8s、サーバレス、IaC</td></tr> <tr><td style="text-align: left"><strong>Cloud 2.0</strong></td><td style="text-align: left"><strong>Agentic Cloud</strong></td><td style="text-align: left"><strong>「意思」の自律化</strong></td><td style="text-align: left"><strong>AIエージェント</strong></td><td style="text-align: left">自律的な推論、長期記憶、Tool Use、動的リソース制御</td></tr> </tbody></table> <p>3つの世代を「場所→構造→意思」の流れで並べると、世代が進むごとに操作主体が一段上のレイヤーへ移っていくことが見えてきます。Cloud 0.5でインフラ担当者がVMを操作し、Cloud 1.0で開発者がAPIやIaC越しにマネージドサービスを操作してきたところに、Cloud 2.0ではLLMエージェント自身がインフラを叩く側に立ちます。今のエンタープライズが向き合っているのは、「LLMエージェントをいかに効率よく稼働させるか」を中心に据えた新しいITインフラストラクチャーの設計です。</p> <p>ひとつ前提を強調しておきます。Cloud 2.0はCloud 1.0を置き換えるものではありません。銀行の勘定系、ECのバックエンド、SaaSの基盤といった既存のワークロードは、引き続きCloud 1.0のプリミティブの上で動き続けます。Cloud 2.0はその上に積み上がる新しいレイヤーとして立ち上がり、エージェントが必要に応じて下のCloud 1.0のアプリを呼び出すこともある、という関係です。</p> <h2 id="LLMエージェントとは">LLMエージェントとは</h2> <p><strong>LLMエージェントとは、目的を与えられたら自分で考え道具を使いタスクを完遂するLLMを用いた仕組み</strong>です。聞かれたことに答えるだけのチャットボットと違い、ゴールに向かって自分で手を動かしていきます。具体的にはAnthropicのClaude CodeやClaude Coworkのようなサービスです。</p> <p>より正確に整理すると、エージェントは主に以下の4つの要素で構成されるシステムと定義されることが多いです。</p> <dl> <dt>脳 (Brain / Planning)</dt> <dd>LLM本体です。与えられた大きな目標を、実行可能な小さなステップ(サブタスク)に分解します。過去の失敗から学び、計画を修正する能力もここに含まれます。</dd> <dt>記憶 (Memory)</dt> <dd>会話の文脈や現在の作業手順を保持する短期記憶と、外部データベース(RAGなど)を活用して膨大な情報を必要に応じて取り出す長期記憶の二段構えです。</dd> <dt>道具の使用 (Tool Use / Action)</dt> <dd>エージェントの大きな特徴です。LLMはテキストを生成するだけでなく、Web検索で最新情報を取得し、コード実行で計算やデータ分析を行ない、API連携でメール送信・カレンダー予約・ファイル操作といった外部ツールを呼び出します。</dd> <dt>認識と判断 (Perception & Reflection)</dt> <dd>実行した結果が正しかったか、目標に近づいているかを自己評価し、次の行動を決定します。</dd> </dl> <p>この4要素は、計画→実行→評価のループを回しながら、共通の記憶を参照・更新する形で連動します。</p> <p>ChatGPTをはじめとするLLMが登場したとき、企業はいかにこれを業務システム(アプリケーション)に取り込むかを検討しました。RAGによる社内ナレッジ検索、お問い合わせの自動応答、議事録の要約など、LLMをアプリケーションの中の一機能として組み込む方向です。</p> <p>しかしその方向での検討は正しい解ではありませんでした。LLMがアプリケーションを含めたさまざまな道具を使い、人間に成り代わって判断しながら業務を行なう。そういう世界が見えてきたのです。LLMを部品として埋め込む構図から、LLMが部品を使う側に立つ構図への反転です。</p> <p>この転換の背景には、Anthropicが2024年11月に公開したMCP (Model Context Protocol) で得られた「LLMを外と繋げば爆発的に生産性が上がる」という体験があります。Claude Codeはこの延長線上で、もっとカジュアルにLLMに外の道具を使わせればMCPより更に効果的であるということを実証してみせました。</p> <p>つまり、既存の業務システムは無くなりません。LLMエージェントから利用される対象になります。アプリケーションは引き続きそこに存在しますが、操作する主体が人間からエージェントに移る、という関係です。前節の表で操作主体をAIエージェントに置いたのは、まさにこの転換を指しています。</p> <p>使われ方の面でも構造が変わります。Cloud 1.0までのアプリケーションは「1つのアプリが多数のユーザを捌く」one-to-manyの前提で設計されてきました。コードは共通で、水平スケールでスループットを上げ、コストはユーザ数に対してサブリニアに伸びる構造です。エージェントはこれを反転させ、1ユーザ(あるいは1タスク)に対して専用の実行環境を割り当てるone-to-oneのモデルになります。</p> <table><thead><tr><th style="text-align: left">軸</th><th style="text-align: left">Cloud 1.0 アプリ</th><th style="text-align: left">LLMエージェント</th></tr></thead><tbody> <tr><td style="text-align: left">実行モデル</td><td style="text-align: left">one-to-many</td><td style="text-align: left">one-to-one</td></tr> <tr><td style="text-align: left">実行環境</td><td style="text-align: left">ユーザ間で共有</td><td style="text-align: left">ユーザごとに専用</td></tr> <tr><td style="text-align: left">コスト構造</td><td style="text-align: left">サブリニア</td><td style="text-align: left">ほぼリニア</td></tr> </tbody></table> <p>この「1ユーザに専用環境」という前提が、次節で見るインフラ要件の起点になります。</p> <h2 id="Cloud_2.0で必要なインフラ機能">Cloud 2.0で必要なインフラ機能</h2> <p>前節で整理したLLMエージェントの4要素と、ユーザ1人に1つの実行環境を割り当てるone-to-oneのモデル。この2つを起点にすると、Cloud 2.0レイヤーが要求するインフラ機能は素直に導けます。</p> <p>エージェントが実行時に取る活動を一段ずつ分解していくと、それぞれに対応するインフラ機能が見えてきます。</p> <table><thead><tr><th style="text-align: left">エージェントの活動</th><th style="text-align: left">求められるインフラ機能</th></tr></thead><tbody> <tr><td style="text-align: left">LLMの推論を回し続ける(脳・認識)</td><td style="text-align: left">複数モデルを切り替えられる統合推論レイヤー</td></tr> <tr><td style="text-align: left">AIが書いたコードを安全に走らせる(道具)</td><td style="text-align: left">ミリ秒で立ち上がる軽量実行環境</td></tr> <tr><td style="text-align: left">長尺タスクやコーディング作業を進める(道具)</td><td style="text-align: left">永続的なフル機能Linux環境</td></tr> <tr><td style="text-align: left">社内DBや業務APIに到達する(道具)</td><td style="text-align: left">エージェント単位のプライベートネットワーク</td></tr> <tr><td style="text-align: left">Webアプリを操作する(道具)</td><td style="text-align: left">マネージドなブラウザ自動化</td></tr> <tr><td style="text-align: left">大量のコードを生成・分岐・統合する(道具)</td><td style="text-align: left">Git互換の版管理ストレージ</td></tr> <tr><td style="text-align: left">状態と過去のやり取りを保持する(記憶)</td><td style="text-align: left">コンテキスト外で保持できる永続記憶レイヤー</td></tr> </tbody></table> <p>ここで効いてくるのがone-to-oneのモデルです。1ユーザに1つの専用実行環境を割り当てるため、表に並べた各機能は「同時に大量に立ち上げ、短時間で捨てる」パターンに耐える必要があります。Cloudflareがブログ「<a rel="external" href="https://blog.cloudflare.com/welcome-to-agents-week/">Welcome to Agents Week</a>」で示した試算が分かりやすい例です。米国だけで1億人を超えるナレッジワーカーがそれぞれ数個のエージェントを15%の同時実行率で動かすと、同時セッション数は約2400万、CPU 1基あたり25〜50ユーザを想定すると米国分だけで50万〜100万CPU相当の容量が必要になる、という見積もりです。one-to-many前提の最適化のままでは、この規模には到底届きません。</p> <p>つまりCloud 2.0レイヤーで必要なのは、上の表に並べたプリミティブを、one-to-oneでも破綻しないコスト構造で提供できるインフラです。次節では、このレイヤーで誰がどう動いているかを見ていきます。</p> <h2 id="Cloud_2.0で変わる力関係">Cloud 2.0で変わる力関係</h2> <p>CloudflareはAgents Week 2026の発表で、前節で挙げたCloud 2.0要件のすべてに対応するサービスを揃えました。</p> <table><thead><tr><th style="text-align: left">要件(前節の表)</th><th style="text-align: left">Cloudflareサービス</th><th style="text-align: left">Agents Weekでの発表</th><th style="text-align: left">説明</th></tr></thead><tbody> <tr><td style="text-align: left">統合推論レイヤー</td><td style="text-align: left">AI Gateway</td><td style="text-align: left">○</td><td style="text-align: left">拡張(14社・70モデル、Workers AIバインディング追加)</td></tr> <tr><td style="text-align: left">軽量実行環境</td><td style="text-align: left">Dynamic Workers</td><td style="text-align: left">○</td><td style="text-align: left">今回発表の目玉。2026年3月24日に有料ユーザーへopen beta開放</td></tr> <tr><td style="text-align: left">永続Linux環境</td><td style="text-align: left">Sandboxes</td><td style="text-align: left">○</td><td style="text-align: left">GA昇格(active CPU pricing、Outbound Workers等を追加)</td></tr> <tr><td style="text-align: left">エージェント単位プライベートネットワーク</td><td style="text-align: left">Cloudflare Mesh</td><td style="text-align: left">○</td><td style="text-align: left">新規発表</td></tr> <tr><td style="text-align: left">ブラウザ自動化</td><td style="text-align: left">Browser Run</td><td style="text-align: left">○</td><td style="text-align: left">旧Browser Renderingを改名。Live View等を追加</td></tr> <tr><td style="text-align: left">版管理ストレージ</td><td style="text-align: left">Artifacts</td><td style="text-align: left">○</td><td style="text-align: left">新規ローンチ</td></tr> <tr><td style="text-align: left">永続記憶レイヤー</td><td style="text-align: left">Agent Memory</td><td style="text-align: left">○</td><td style="text-align: left">プライベートベータ発表</td></tr> </tbody></table> <p>7要件すべてが新規発表・GA昇格・拡張のいずれかに該当します。Agents Week 2026は、Cloudflareがこのレイヤーへの準備を一気に完了させたイベントとして位置づけられます。</p> <p>次に、Cloud 1.0を制覇した3強(AWS、Google Cloud、Microsoft Azure)にCloudflareを加えて、同じ7要件のものさしで判定します。判定の3条件は次のとおりです。</p> <ol> <li>GA: 一般提供されており、誰でも利用できる(プライベートベータや「未公開」は除外)</li> <li>エージェント特化: 汎用クラウドサービスの流用ではなく、エージェント向けに設計されている</li> <li>統合プラットフォーム配下: 各社の「エージェントクラウド」ブランドや統合プラットフォームの一部として提供されている</li> </ol> <p>3条件すべてを満たせば○、preview/beta段階なら△、該当サービスなし・汎用流用・受付終了なら×、と判定します。</p> <table><thead><tr><th style="text-align: left">要件</th><th style="text-align: center">Cloudflare</th><th style="text-align: center">Google Cloud</th><th style="text-align: center">Microsoft Azure</th><th style="text-align: center">AWS</th></tr></thead><tbody> <tr><td style="text-align: left">統合推論レイヤー</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td style="text-align: center">○</td></tr> <tr><td style="text-align: left">軽量実行環境</td><td style="text-align: center">△</td><td style="text-align: center">○</td><td style="text-align: center">△</td><td style="text-align: center">△</td></tr> <tr><td style="text-align: left">永続Linux環境</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td style="text-align: center">△</td><td style="text-align: center">△</td></tr> <tr><td style="text-align: left">エージェント単位プライベートネットワーク</td><td style="text-align: center">△</td><td style="text-align: center">△</td><td style="text-align: center">△</td><td style="text-align: center">×</td></tr> <tr><td style="text-align: left">ブラウザ自動化</td><td style="text-align: center">○</td><td style="text-align: center">○</td><td style="text-align: center">×</td><td style="text-align: center">○</td></tr> <tr><td style="text-align: left">版管理ストレージ</td><td style="text-align: center">△</td><td style="text-align: center">×</td><td style="text-align: center">×</td><td style="text-align: center">×</td></tr> <tr><td style="text-align: left">永続記憶レイヤー</td><td style="text-align: center">△</td><td style="text-align: center">○</td><td style="text-align: center">△</td><td style="text-align: center">○</td></tr> </tbody></table> <p>判定の根拠とした各社のエージェント特化プラットフォーム/主要サービスは次のとおりです。</p> <table><thead><tr><th style="text-align: left">要件</th><th style="text-align: left">Cloudflare</th><th style="text-align: left">Google Cloud</th><th style="text-align: left">Microsoft Azure</th><th style="text-align: left">AWS</th></tr></thead><tbody> <tr><td style="text-align: left">統合推論レイヤー</td><td style="text-align: left">AI Gateway</td><td style="text-align: left">Vertex AI Model Garden</td><td style="text-align: left">Azure AI Foundry Models</td><td style="text-align: left">Amazon Bedrock</td></tr> <tr><td style="text-align: left">軽量実行環境</td><td style="text-align: left">Dynamic Workers</td><td style="text-align: left">Cloud Run / Vertex AI Agent Engine</td><td style="text-align: left">Azure Container Apps</td><td style="text-align: left">Bedrock AgentCore Runtime</td></tr> <tr><td style="text-align: left">永続Linux環境</td><td style="text-align: left">Sandboxes</td><td style="text-align: left">Vertex AI Code Interpreter</td><td style="text-align: left">Azure Container Apps</td><td style="text-align: left">Bedrock AgentCore Code Interpreter</td></tr> <tr><td style="text-align: left">エージェント単位プライベートネットワーク</td><td style="text-align: left">Cloudflare Mesh</td><td style="text-align: left">VPC + Vertex AI Agent Engine</td><td style="text-align: left">Azure Private Link + AI Search</td><td style="text-align: left">(PrivateLink等の汎用流用)</td></tr> <tr><td style="text-align: left">ブラウザ自動化</td><td style="text-align: left">Browser Run</td><td style="text-align: left">Vertex AI Browser Tool</td><td style="text-align: left">(エージェント特化サービス未確認)</td><td style="text-align: left">Bedrock AgentCore Browser</td></tr> <tr><td style="text-align: left">版管理ストレージ</td><td style="text-align: left">Artifacts</td><td style="text-align: left">(該当サービス未確認)</td><td style="text-align: left">(該当サービス未確認)</td><td style="text-align: left">(該当サービス未確認)</td></tr> <tr><td style="text-align: left">永続記憶レイヤー</td><td style="text-align: left">Agent Memory</td><td style="text-align: left">Vertex AI Agent Engine Memory Bank</td><td style="text-align: left">Azure AI Foundry Memory</td><td style="text-align: left">Bedrock AgentCore Memory</td></tr> </tbody></table> <p>7要件のものさしで眺めると、Google Cloudはエージェント特化のサービスを最も成熟させています。CloudflareはAgents Week 2026で全領域を埋め、×は出していません。Microsoft Azureはエージェント特化の統合プラットフォームとしてはpreview段階のサービスが多い印象です。AWSはBedrock AgentCoreファミリー(Runtime / Memory / Code Interpreter / Browser / Gateway / Identity / Policy / Evaluations / Observability)でレイヤー横断のサービスを揃えています。特に2026年4月にAgentCore BrowserがOS-levelアクションを追加したことで、ブラウザ自動化は他社と並ぶ水準に到達しています。一方で、エージェント単位のプライベートネットワークとGit互換の版管理ストレージという2領域では、AgentCoreファミリーに対応するプリミティブが現時点で確認できません。</p> <p>Cloudflareがone-to-one前提の課金モデル(Dynamic Workersのper-load課金、Sandboxesのactive CPU pricing)とisolateベースのms起動を統合的に提供しているのに対し、AWSはAgentCore側で個別プリミティブを揃える方向で追いついている段階です。Cloud 1.0期に確立した汎用プリミティブ(EC2、Lambda、VPC、IAM)はone-to-many前提で設計されていたため、one-to-oneのワークロードに対しては個別最適の積み上げで対応している、と位置づけられます。</p> <p>Cloud 1.0時代、CDNとセキュリティのベンダーとして3強の外側に置かれていたCloudflareが、Cloud 2.0レイヤーでは3強と肩を並べる側へ上がってきました。Cloud 1.0はAWSが制覇したレイヤーでしたが、Cloud 2.0ではプレイヤーの力関係がリセットされるステージです。</p> <h2 id="主戦場は業務リエンジニアリングへ">主戦場は業務リエンジニアリングへ</h2> <p>エンタープライズはCloud 1.0の世界を捨てる必要はありません。基幹システムやSaaSバックエンドはAWS中心の運用を続ければよく、その領域でのインフラ・アーキテクチャの設計力はこれからも継続して必要です。</p> <p>ただしCloud 2.0レイヤーは別の判断軸で組む必要があります。Cloud 1.0期に確立したベンダー選定の前提がそのままでは通じないからです。前節で見たとおり、Cloud 2.0ではGCPが先行、Cloudflareが追いつき、AzureとAWSは個別サービスを揃えつつも統合プラットフォームとしては道半ばです。「Cloud 1.0と同じベンダーで揃える」という発想を出発点にすると、コスト構造とプリミティブの噛み合わせで不利な選択を踏みやすくなります。</p> <p>そしてCloud 2.0レイヤーで主戦場になるのは、インフラ・アーキテクチャではありません。プラットフォーム側がプリミティブを統合提供している以上、何をどう組み合わせるかが大きな差別化要因にはなりません。</p> <p>ここで主戦場となるのは、業務プロセスをエージェント向けに再設計し、エージェントのスキルとして実装できる人材です。Cloud 1.0時代に「AWS特化のインフラ設計者」が握っていた価値の中心は、Cloud 2.0では「業務とエージェントの間を設計できる人」に移ります。</p> <p>エンタープライズが今着手すべきは、エージェントが代替・補強できる業務プロセスの棚卸しと、それをエージェントに落とし込むケイパビリティの社内構築です。Cloud 2.0プラットフォームの選定は、その準備の一部であって目的ではありません。</p> <hr /> <h2 id="References">References</h2> <div class="references"> <ul> <li><a rel="external" href="https://blog.cloudflare.com/welcome-to-agents-week/">Cloudflare</a>.「Welcome to Agents Week」(米国ナレッジワーカー試算の出典)</li> <li><a rel="external" href="https://blog.cloudflare.com/agents-week-in-review/">Cloudflare</a>.「Building the agentic cloud — Agents Week in Review」(発表総まとめ)</li> <li><a rel="external" href="https://developers.cloudflare.com/changelog/post/2026-03-24-dynamic-workers-open-beta/">Cloudflare Developers</a>.「Dynamic Workers open beta」(2026年3月24日open beta開放)</li> <li><a rel="external" href="https://blog.cloudflare.com/sandbox-ga/">Cloudflare</a>.「Agents have their own computers with Sandboxes GA」</li> <li><a rel="external" href="https://blog.cloudflare.com/browser-run-for-ai-agents/">Cloudflare</a>.「Browser Run for AI Agents」</li> <li><a rel="external" href="https://blog.cloudflare.com/introducing-agent-memory/">Cloudflare</a>.「Introducing Agent Memory」</li> <li><a rel="external" href="https://www.cloudflare.com/press/press-releases/2026/cloudflare-launches-mesh-to-secure-the-ai-agent-lifecycle/">Cloudflare Press</a>.「Cloudflare Launches Mesh」</li> <li><a rel="external" href="https://www.anthropic.com/news/model-context-protocol">Anthropic</a>.「Model Context Protocol」(2024年11月公開)</li> <li><a rel="external" href="https://aws.amazon.com/bedrock/agentcore/">AWS</a>.「Amazon Bedrock AgentCore」(Runtime / Memory / Code Interpreter / Browser / Gateway / Identity / Policy / Evaluations / Observability)</li> <li><a rel="external" href="https://aws.amazon.com/about-aws/whats-new/2026/04/agentcore-browser-os-actions/">AWS</a>.「AgentCore Browser adds OS-level interactions」(2026年4月8日)</li> </ul> </div>

Cloudflareが2026年4月に開催した「Agents Week 2026」では、Cloud 2.0時代の到来が見えてきました。Cloud 1.0で築いた優位がCloud 2.0レイヤーには引き継がれない構造と、エンタープライズが向き合う変化を考えます。

AWS CodeCommit新規受付凍結の影響について 2024-08-13T00:00:00+00:00 2024-08-13T00:00:00+00:00 Toshiyuki Yoshida https://codedchords.dev/blog/2024/08/codecommit-impact/ <blockquote> Amazon's recent decision to stop accepting new users for several cloud services caught some customers, partners and even a few employees by surprise. (Amazon が展開中の複数のクラウドサービスについて新規ユーザー登録受付を中止したことで、顧客や協力企業の間で混乱が広がっている。) <footer> <cite> Business Insider -{" "} <a href="https://www.businessinsider.com/aws-deprioritized-cloud-services-surprising-customers-salespeople-2024-8"> Amazon decision to deprioritize 7 cloud services caught customers and even some salespeople by surprise </a> </cite> </footer> </blockquote> <p>以下の記事は、最近の報道などを見た個人的な意見です。既に中の人ではないので、この件に関しては報道以上の情報は持ち合わせていません。</p> <h2 id="サービス凍結の状況">サービス凍結の状況</h2> <p>同記事によると、次のように説明されている模様です。</p> <blockquote> <p>As the public outcry grew, AWS's chief evangelist Jeff Barr wrote a short X post on Tuesday to explain that the company decided to "discontinue new access to a small number of services," but it would continue running them in a secure environment.</p> <p>関係者から懸念の声が高まったことを受け、AWSのバイスプレジデント兼チーフエバンジェリストを務めるジェフ・バー氏は7月30日のX（旧Twitter）投稿を通じて詳細な事実を説明するとともに、今後の対応を明らかにした。</p> </blockquote> <p>これまで使ってきたユーザーはそのまま使用でき、新規ユーザーはGitHubなど別のソリューションを選択すればよいのですぐに何か問題となる訳でありません。</p> <h2 id="新規受付凍結の影響">新規受付凍結の影響</h2> <p>この変更により直近大きな影響はなさそうですが、顧客としては不安でしょう。</p> <p>既存ユーザーに対してはサポートを継続すると言われていますが、ほとんどの顧客は遠からずこれらのサービスが終了すると考えているでしょう。つまり、顧客は将来のサービス終了に備えた対応を迫られています。</p> <p><a rel="external" href="https://aws.amazon.com/jp/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/">AWSのブログ</a>でリポジトリーの移行方法が紹介されていますが、CodeCommitやCloud9などのツールは開発プロセスの中に組み込まれて使用しているので、最低でも次のような対応が必要です。</p> <ul> <li>リポジトリーの移行</li> <li>ユーザーの移行</li> <li>CI/CDの組み直し</li> <li>開発プロセスの対応変更</li> <li>社内の移管手続きの変更</li> <li>開発者や運用者の再教育</li> </ul> <p>ちょっとした組織横断のプロジェクトになりそうです。</p> <h2 id="何が悪かったのか？">何が悪かったのか？</h2> <p>第一の問題は、AWSがCodeCommitやCloud9のサービスの重要性をAWSが図り損ねたことでしょう。</p> <p>想像するに、CodeCommitやCloud9はそれほど利用者が多くなかったのでしょう。ユーザーの利用度が低い、サービス提供側から見ると金を生まないサービスを統廃合していくのは当たり前の話です。</p> <p>これが本番環境のRuntimeだけに関わる問題であれば、ここまでの問題にならなかったかもしれません。ところが、CodeCommitやCloud9などは企業ITの組織やプロセスに深く関わるので、サービスの移行だけでなく人やプロセスの移行も必要です。少数かもしれませんが、AWSを信じてCodeCommitやCloud9を利用していた企業は多大な移行コストが必要となります。</p> <p>その認識がAWSには足りてなかったのではないかと思います。アプリ開発の側の人だったので偏見かもしれませんが、どうもインフラ屋さんというのはこういう部分のセンスが足りていないのではないかと思うことがよくあります。</p> <p>結果として、Business Insiderが報じるよう、AWS自身も以下のようは羽目になってしまっています。</p> <blockquote> <p>The company is trying to keep supporting clients while signaling that these offerings are no longer a strategic priority.</p> <p>同社は、これらのサービスがもはや戦略的優先事項ではないことを示しながら、顧客のサポートを続けようとしている。</p> </blockquote> <p>2点目は、これらの決定に至るAWS社内での連携の問題でしょう。</p> <p>AWS CLIの<a rel="external" href="https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst">CHANGE LOG</a>を見ると、7月26日にCommitされた2.17.18のコメントに以下のように記述されています。これを受けて一部の顧客が気付いて徐々に騒ぎが大きくなっていったようです。</p> <pre class="giallo z-code"><code data-lang="plain"><span class="giallo-l"><span>api-change:`codecommit`: CreateRepository API now throws OperationNotAllowedException when the account has been restricted from creating a repository.</span></span></code></pre> <p>実際には6月6日から新規顧客への制限を加えていたという話もあります。当然これらの決定は更に数ヶ月前には行われていたことでしょう。一方でBusiness Insiderが報じるようにAWS内部でも十分に周知されないまま決定されたようです。</p> <blockquote> <p>It turns out that even some of Amazon's own salespeople were not aware of the change until after it was made public late last week.</p> <p>なお、アマゾンの営業部門の中には事前に何も聞かされておらず、同社が先週末に受付中止を公表した時点で初めてその事実を知った従業員が複数いることも分かった。</p> </blockquote> <p>アグレッシブな機能の改善は美点でもあり機能やサービスをどんどん追加している時はよかったかもしれませんが、ある程度利用が定着した段階に入っているこれからはこれまでのようなカジュアルな変更は難しいのかもしれません。</p>

Business Insider などを読んでいるとAWSのCodeCommitやCloud9の新規受付凍結は、米国でもかなり問題になっている模様。