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>

技術文書用フォーマット AsciiDoc

2026-07-10T05:00:00+09:00

Table of Contents</summary> </details> 
AsciiDocで書かれたドキュメントを修正する必要があったので、 AsciiDoctorを導入しました。
AsciiDocとは</h2>
AsciiDocは、2002年にStuart Rackham氏が開発したマークアップ言語です。もともとはDocBook XMLを人間が書きやすい記法で表現するためのPython製ツールとして誕生しました。プレーンテキストで書いた文書を、HTMLやPDF、EPUBなど複数の形式に変換できる点が特徴です。
2013年にはRuby実装のAsciidoctorが登場し、現在ではこちらが主流の処理系となっています。本記事でも、AsciiDocの処理系としてAsciidoctorを使用します。
2019年からはEclipse Foundation傘下の AsciiDoc Working Groupによって言語仕様の標準化も進められており、処理系間の互換性が高まりつつあります。
ただし、技術文書での採用率では明確にMarkdownが優位です。技術文書作成者の主要フォーマットとしてMarkdownを使う割合が约65%とされ、デファクトスタンダードの地位にあります。学習コストの低さとツールの豊富さ、生成AIで扱う文書形式の標準となっていることが理由です。実際にはAsciiDocは全体の採用率では大きく水を開けられています。
MacへのAsciiDocの導入</h2>
AsciiDocの処理系としてAsciiDoctorを使用します。
ランタイムにRubyを使用するので、Rubyのインストールから行っています。前提として、私の環境では mise</a>で言語のバージョンを管理しています。
# Rubyのインストール mise use -g ruby@latest gem install asciidoctor asciidoctor-pdf asciidoctor-rouge gem install asciidoctor-pdf-cjk asciidoctor-diagram</code></pre>AsciiDocのサンプル</h2> 似たようなマークアップ言語にMarkdownがありますが、以下のような点でAsciiDocが優れているので作る文書の特性で使い分けています。 目次や表紙の生成が可能</li> 細かいテーブルの表現が可能</li> ソースコードにシンタックスハイライトや吹き出しが使える</li> </ul> GitHubやGitLabでもネイティブでAsciiDocのレンダリングに対応しています。始めからHTMLやPDFへの変換を意識して作られている点でも優れています。 次にサンプルを提示します。 Frontmatterを除くと、ソースのままでも読みやすい形式です。特に今回はソースコードの解説だったので、以下の例ではソースコードへの解説を追記する例となっています。 = サンプル :toc: left :toc-title: 目次 :toclevel: 4 :imagesdir: images :figure-caption: 図 :chapter-signifier: :scripts: cjk :pdf-theme: default-with-font-fallbacks :doctype: book :sectnumlevels: 4 :sectnums: :source-highlighter: rouge :rouge-style: gruvbox == Hello World .hello.py [source,python] ---- print("Hello World!") <1> i = 3 if i == 1: <2> print("i = 1") elif i == 2: print("i = 2") elif i == 3: print("i = 3") else: print("i = 4") ---- <1> やっぱりサンプルといえばコレな <2> IF文です！</code></pre>AsciiDocを変換する</h2> 作成したAsciiDocのソースは以下のコマンドでHTMLやPDFに変換します。 # HTMLの生成 asciidoctor --backend html5 sample.adoc -o sample.html # PDFの生成 asciidoctor-pdf sample.adoc -o sample.pdf</code></pre> 以下が生成したサンプルです。 まとめ</h2> AsciiDocは Markdownと似ているので混乱する部分もありますが、 Markdownよりやりたいことをストレートに書けると思います。 サンプルのようにAsciiDocのメタデータにいろいろ記載すると生成するスタイルも変更できるのでいろんな文章に柔軟に対応できると思います。
CloudflareのAI対策見直しとAIエージェント対応度診断 2026-07-08T00:00:00+00:00 Table of Contents</summary> </details> 2026年2月、Cloudflareへ移転した際の記事</a>で、AI学習クローラー対策としてContent Signals Policy、Block AI bots、AI Labyrinthという3層構成を紹介しました。あれから4か月、AIによるアクセスの重要性はさらに増しています。改めてこのブログのCloudflare設定を見直すとともに、Cloudflareが新しく公開したAgent Readinessスキャナーで「AIエージェントへの対応度」を診断してみました。 Managed robots.txtまわりを再確認する</h2> まず、AI Crawl Controlのダッシュボードを一通り確認しました。 Block AI training botsは「Block on all pages」のままで変更していません。このブログのコンテンツはCC BY-NC-ND 4.0(非営利・改変禁止)で公開しているので、商用LLMの学習データとして使われることは元々ライセンスの意図と衝突します。学習目的のクローラーは全ページで拒否するのが一貫した方針です。 Content Signalsでは、Managed robots.txtをオンにしています。 AI Crawl ControlのCrawlers一覧では、クローラーごとの許可/ブロックを個別に確認しました。 カテゴリ</th> 例</th> 設定</th></tr></thead> AI Crawler(学習用)</td> GPTBot、ClaudeBot、Bytespider、Amazonbot、TikTok Spider、Meta-ExternalAgent</td> Block</td></tr> AI Search / AI Assistant</td> Applebot、PerplexityBot、ChatGPT-User</td> Allow</td></tr> Search Engine Crawler</td> Googlebot、BingBot</td> Allow</td></tr> </tbody></table> Crawlers一覧の分類も、学習目的のクローラーを拒否するという方針のとおりでした。あわせてAI Labyrinth(クロールルールを無視するボットに偽コンテンツを読ませるハニーポット機能、Beta)も確認しましたが、2月から変わらずONのままでした。 「混在クローラー」という新しい論点</h2> 今回の見直しで、2月時点にはなかった変化に気づきました。レガシー機能「Block AI bots」の設定画面に、次のような予告が表示されていたのです。 On September 15, mixed-purpose crawlers that are used both for search indexing and for training AI will be included in blocking AI training. </blockquote> ここで言う混在クローラーとは、前段のCrawlers一覧でSearch Engine CrawlerやAI Searchに分類し、学習とは無関係としてAllowにしていたGooglebot、Applebot、BingBotのことです。検索とAI学習を1回のクロールで同時に行うため両者を切り分けられず、学習ブロックを選んでいるサイトでは最も制限の強いルールを適用する、というのが実質的な立場だと考えられます。そのままでは検索エンジン経由の流入もAI検索・AIアシスタント経由の露出も失うため、「Mixed purpose crawlers will continue to be allowed」を選び、混在クローラーは引き続き許可する設定にしました。 レガシー機能は9月15日に廃止され、後継の「Configure AI bot policies」に一本化されます。こちらはボットを3種類に分類し、それぞれ個別にAllow/Blockを選べる形になっていました。 分類</th> 説明</th> 設定</th></tr></thead> Search</td> 検索エンジンのインデックス用ボット</td> Allow(Recommended)</td></tr> Agent</td> ユーザーの質問への回答生成のために参照するボット</td> Allow(Recommended)</td></tr> Training</td> AI学習用にコンテンツをスクレイピングするボット</td> Block(Recommended値はBlock on pages with ads)</td></tr> </tbody></table> Trainingだけ、広告のないこのブログの事情に合わせて推奨値の「Block on pages with ads」から「Block」に変更しました。 AIエージェント対応度を診断してみた</h2> Cloudflareはisitagentready.com</a>という無料の診断ツールを公開しています。 この診断ツールでは、サイトのAIエージェントへの対応度(Agent Readiness)を診断してくれます。 このブログのURLでスキャンしたところ、次のようなものでした。 当サイトのAgent Readiness</figcaption> </figure> 個人ブログサイトでは該当しない項目</h3> 改善項目として、10個の指摘を受けました。ただし、10個のうち6個はいずれも「稼働しているAPIやエージェントサービスがあること」を前提にした指摘でした。 指摘</th> 規格</th> 該当しない理由</th></tr></thead> DNS for AI Discovery (DNS-AID)</td> IETFドラフト、Linux Foundation 2026年発表</td> 他のAIエージェントから発見・接続されるエージェントサービス(チャットボット、MCPサーバー等)を運用していない</td></tr> API Catalog</td> RFC 9727</td> カタログ化すべきAPIが存在しない</td></tr> OAuth/OIDC discovery metadata</td> RFC 8414 等</td> 認証保護されたAPIや会員機能がない</td></tr> OAuth Protected Resource Metadata</td> RFC 9728</td> 同上</td></tr> auth.md</td> WorkOS提唱</td> OAuth Protected Resource Metadataを前提とする、同上の理由</td></tr> MCP Server Card</td> SEP-1649(標準化進行中)</td> MCPサーバーを運用していない</td></tr> </tbody></table> このブログは静的コンテンツを配信するだけのサイトで、APIやエージェント向けサービスは一切運用していません。この種の指摘は、SaaSやEC、API提供事業者向けのチェックリストとしては妥当ですが、個人ブログにはそもそも対象が存在しませんでした。 対応した項目</h3> 「ホームページにLink response header(RFC 8288)がない」という指摘もありました。ツールの提案はrel="api-catalog"</code>やrel="service-doc"</code>でAPIカタログやAPI仕様書を指すというものでしたが、このブログにAPIはないので、この提案どおりに実装しても意味がありません。 代わりに、Linkヘッダーの仕組み自体はこのブログでも使い道があると考え、次の2つを指すヘッダーを追加しました。 / Link: </license/>; rel="license", </atom.xml>; rel="alternate"; type="application/atom+xml"</code></pre> rel="license"</code>はIANA登録済みの正式なrelationで、CC BY-NC-ND 4.0を明記したライセンスページ(/license/</code>)をAIエージェントが機械的に検出できるようにします。学習ボットのブロックと合わせて、コンテンツの利用条件を多層的に伝える形になりました。rel="alternate"</code>はZolaが生成するAtomフィード(/atom.xml</code>)へのリンクで、フィードの発見性を高めます。 対応を見送った項目</h3> 残る3個は、対応自体は可能でも今回は見送りました。 Markdown for Agentsは、Accept: text/markdown</code>のリクエストにHTMLの代わりにMarkdownを返す機能です。CloudflareのAI Crawl Control上では確認できましたが、Proプラン以上限定(2026年7月時点で月$20〜25)のため、Freeプランの現状ではロックされていました。個人ブログの一機能としてはコストに見合わないと判断し、見送りました。 WebMCPは、ブラウザ内蔵のAIエージェントにnavigator.modelContext.provideContext()</code>でサイトの操作(検索など)を直接公開する仕組みです。現状はEarly Preview Program参加者限定の実験段階で、一般のブラウザではまだ有効化されていません。このブログの操作対象もpagefindによる検索程度で薄く、標準化が進んだ段階で再検討することにしました。 Agent Skills discovery indexは、/.well-known/agent-skills/index.json</code>にサイト固有の作業手順(SKILL.md)を公開する仕組みです。コンテンツサイト向けの想定用途は「文章校正」「カテゴリ分類の提案」といった編集アシスタント業務で、これは既に自分のClaude Code環境でローカルに完結しています。v0.2.0のドラフト段階でエコシステムの普及状況も未検証なため、こちらも見送りとしました。 まとめ</h2> Agent Readinessスキャンの10個の指摘を並べてみると、その多くはAPIやSaaS、エージェント向けサービスを運用している事業者を想定したチェックリストだと分かりました。静的な個人ブログにとって本当に意味のある「AI対応」は、実は範囲が絞られます。当サイトでの結論は次のとおりです。 CC BY-NC-NDライセンスの意図に沿って、学習目的のクローラーは技術的にブロックする</li> robots.txtのContent Signalsとライセンスページへのrel="license"</code>で、利用条件を機械可読な形でも表明する</li> 検索エンジンやAI回答エンジンからの参照は妨げず、露出の機会は残す</li> WebMCPやAgent Skillsのようなドラフト段階の規格には、実際に普及するまで様子見の姿勢を崩さない</li> </ul> 2月の記事で組んだ多層防御の骨格は変わっていませんが、Cloudflare側の仕様変更(混在クローラーの扱い)に合わせて設定を追随させ、Agent Readinessという新しい物差しで一度棚卸しをしたことで、このブログのAI対応の現在地を再確認できました。 References</h2> Cloudflare</a>. "Giving users choice with Cloudflare's new Content Signals Policy"</li> Cloudflare</a>. "robots.txt setting"</li> Cloudflare</a>. "Your site, your rules: new AI traffic options for all customers"</li> Cloudflare</a>. "Introducing the Agent Readiness score"</li> Cloudflare</a>. "Pro Plan Overview"</li> IETF</a>. "DNS for AI Discovery"</li> DNS-AID</a>. "AI Agent Discovery via DNS"</li> IETF</a>. "RFC 9727: The api-catalog Well-Known URI and Link Relation Type"</li> IETF</a>. "RFC 8288: Web Linking"</li> WorkOS</a>. "auth.md — Open Protocol for Agent Registration"</li> Model Context Protocol</a>. "MCP Server Card (SEP-1649)"</li> Cloudflare</a>. "Agent Skills Discovery RFC"</li> Agent Skills</a>. "Agent Skills"</li> Chrome Developers</a>. "WebMCP Early Preview Program"</li> </ul> </div> メッセージングアプリの匿名性考察 2026-07-01T10:00:00+09:00 Table of Contents</summary> </details> Threema GmbH（以下、Threema社）の公式ブログに「システムレベルの匿名性についての記事</a>」という記事が投稿されました。 メッセージングアプリの匿名性について論じています。以前、市川の強盗傷害事件をきっかけに暗号化やメタデータで機能比較した記事</a>を書きましたが、匿名性という観点はなかったのでこの記事を参考に解説したいと思います。 メッセージングアプリの匿名性について</h2> Threema社の技術記事では、匿名性を二種類に分けています。 水平的匿名性</dt> 会話の相手に対する匿名性です。ユーザー名だけで連絡先を交換できれば、相手は電話番号や本名を知りません。対等な利用者どうしの間で成り立ちます。</dd> 垂直的匿名性</dt> サービス運営者に対する匿名性です。登録時に電話番号やメールアドレスを渡していなければ、運営は身元を特定する手がかりを持ちません。利用者とサービスという上下の関係で成り立ちます。</dd> </dl> Threema社は、ユーザー名機能で水平的匿名性は広まったものの、プライバシー保護で本当に重要なのは垂直的匿名性であり、これはセキュリティにおけるエンドツーエンド暗号化に相当する基盤だと主張します。あくまで同社の枠組みですが、この二軸はアプリを見比べる土台として使えます。 垂直的匿名性の重要性について</h2> なぜ運営に対する匿名性がそれほど問題になるのでしょうか。 メッセージングアプリでは、登録時に電話番号やメールアドレスを要求するものがあります。 ユーザー名で連絡先を交換できるサービスでも、相手にこうした個人情報を見せずに済むだけで、登録の段階では運営に渡しています。電話番号やメールアドレスは本人確認や他サービスの登録にも使われる、生活に密着した識別子です。運営がこれを保持していれば、別々の文脈で集めた情報を同一人物に結びつける手がかりとして使えてしまいます。 この紐付けは、広告で収益を上げるサービスでは特に意味を持ちます。利用者の行動を束ねてプロフィールを作るほど広告の精度が上がるので、複数の情報源を統合する動機がもともと働きます。電話番号やメールアドレスのような確実な識別子があれば、その統合は格段にやりやすくなります。メッセージの中身が暗号化されていても、誰がいつ誰と連絡したかというメタデータや、それを個人に結びつける識別子までは覆い隠せません。 メッセージングアプリの匿名性の比較</h2> ここまでの軸で、私が知る範囲の主要なアプリを並べてみます。 暗号化の強さと、運営に対する匿名性は別物だという点に注目してください。暗号化の対応範囲やメタデータ収集、法執行機関への開示といった機能面の詳しい比較は前回の記事</a>にまとめたので、ここでは匿名性の軸に絞ります。 アプリ</th> 登録時に必要な個人情報</th> 運営に対する匿名性</th></tr></thead> LINE</td> 電話番号</td> なし</td></tr> WhatsApp</td> 電話番号</td> なし</td></tr> iMessage</td> 電話番号または Apple Account</td> なし</td></tr> Signal</td> 電話番号</td> なし</td></tr> Element / Matrix</td> なし（メールは任意）</td> サーバー次第</td></tr> Threema</td> なし</td> 運営は満たすと主張</td></tr> Session</td> なし</td> 高い</td></tr> SimpleX</td> なし</td> 最も高い部類</td></tr> </tbody></table> 国内利用者の多いLINEは、もう少し細かく見ておきます。LINEのメッセージはLetter Sealingと呼ぶ技術で暗号化されていますが、50人を超えるグループトーク、グループ音声・ビデオ通話、LINEミーティング、アルバム、ノートは対象外で、通信路のTLS暗号化にとどまります。この範囲は運営が技術的に中身へアクセスし得ます。そして匿名性の面では、登録に電話番号が必須なので運営に対する匿名性は持ちません。自治体などが市民の申請にLINEを使うケースが増えていますし、たまに企業でも業務で使用しているケースを見かけます。セキュリティ意識の低さには驚きます。 WhatsAppとiMessageも、垂直的匿名性はありません。メッセージの暗号化に対応していますが、登録にはWhatsAppが電話番号、iMessageが電話番号かApple Accountを必要とします。この時点で運営に対する匿名性は持ちません。特にWhatsAppを運営するMeta社は広告を収入源としているので、個人情報に関連したメタデータを収集してグループ内の他社と共有している可能性があります。中身は守られても、誰といつ繋がったかまでは隠せません。 ただし、Signalのメタ情報の電話番号、登録日、最終接続日のみ。 </aside> 暗号化に強いというイメージのSignalも垂直的匿名性はありません。ユーザー名機能が2024年に加わり、電話番号を教えないまま連絡できるようになりました(水平的匿名性)が、アカウントの作成には今も電話番号が必須です。 Signalを運営するのはSignal Foundationという非営利団体ですが、拠点はカリフォルニア州です。つまり米国の管轄下なので、米国の捜査機関の要求があれば開示義務があります。 ElementはMatrixというオープンなプロトコルの上に作られています。登録に必要なのは、選んだサーバー上のユーザー名とパスワードだけで、電話番号は要りません。メールアドレスはパスワード再設定用に任意で登録でき、サーバーによっては不正利用対策で求められることもあります。利用者はmatrix.orgのような公開サーバーを選んで登録するのが一般的で、自前でサーバーを立てることもできます。運営に対する匿名性は、結局どのサーバーを信頼するかに依存します。 結局、垂直的匿名性を保持しているのは、Threema、Session、SimpleXのみです。 垂直的匿名性の代償</h2> 垂直的匿名性の仕組みと、その代わりに払う利便性のコストを見ておきます。 Threemaは電話番号やメールアドレスを必要とせず、アカウントはランダムに割り当てられたThreema IDだけで機能します。ユーザーはThreema IDを交換しメッセージの送受信を行ないます。伝えるのはThreema IDのみなので、運営や相手に身元を明かさずに通信できます。 Threemaを使用していることすら秘匿する為にGoogle Playなどに依存せずThreemaを入手・購入できる手段も提供しています。 Threema IDはThreema社により管理されており、「IDが誰か」はThreema社に把握されませんが「いつ・どのIDと通信したか」は論理的にはThreema社で把握可能です。ただし、Threema社は広告やトラッキングを行なわないというポリシーを持ち、収益源を買い切り課金に置いています。 SimpleXは、利用者を識別する固定IDを一切持たない設計です。電話番号やユーザー名はもちろん、ランダムなIDすら使いません。仕組みは一方向のメッセージキューで、接続ごとに送信用と受信用の別々のキューを持ち、通常はそれぞれ別のサーバーを経由します。サーバーから見えるのは不透明なキューへの孤立した配送だけで、送信者と受信者を結びつけられません。サーバー同士も通信せず、配送が済んだメッセージは保存しません。 SessionはもともとSignalのフォークとして始まりました。電話番号やメールなどの個人データも不要で、ランダムなSession IDという66文字程度の公開鍵をアカウントのIDとして使います。メッセージは多数の有志ノードからなるオニオン型のネットワークを経由し、どのノードも送信者と受信者の両方を知ることはありません。運営は2024年10月に、暗号化技術への規制圧力を背景としてオーストラリアからスイスへ拠点を移し、現在はスイスのSession Technology Foundationが運営しています。コードはQuarkslabによる独立監査を受けています。SimpleXとの違いは、Sessionが永続的なアカウントのIDを持つ点です。 これらの高い匿名性には、現実的な代償が伴います。 いずれも、相手に直接リンクやQRコード、IDを渡さなければ会話を始められない</li> 従って、電話番号やユーザー名で気軽に相手を見つけることはできず、なんらかの方法で相手と直接これらの情報を交換する必要がある</li> </ul> 一番問題になるのは、相手も同じアプリを入れている必要があるところでしょう。いずれもマイナーなアプリなので、匿名性のために連絡相手の数と手軽さを大きく差し出すことになります。この利便性の低さは、日常使いを考えるうえで無視できないトレードオフです。 メッセージングアプリについて私の選択</h2> ここまで匿名性の強さで並べてきましたが、強ければ強いほどよい、という話ではありません。匿名性がどれだけ効くかは、相手があなたの身元を知っているかどうかで変わります。 私は以下のように考えています。 関係</th> 説明</th></tr></thead> 家族</td> 当然対面しており、インストールするアプリも管理可能。機微なメッセージ交換もあり</td></tr> 友人</td> 対面しているが、アプリの管理は困難。機微なメッセージ交換は限定的</td></tr> 他人</td> 必ずしも対面していない。アプリの管理は不能。機微なメッセージはなし</td></tr> </tbody></table> このように考えると、家族とは水平的匿名性は不要で垂直的匿名性が必要です。前回の記事でも軽く触れましたが、私自身は家族との連絡用にThreemaを選んでいます。 SimpleXやSessionでもよいのですが、かなり以前からThreemaを使用しており、特に問題もないために使用を続けています。 友人も同様です。知り合いなので水平的匿名性は不要ですが、垂直的匿名性は必要です。しかし、現実的には垂直的匿名性を実現するために、先に記述した「代償」のため友人に対応するアプリを導入してもらうことは困難です。そのため諦めて必要な場合は、友人にはメールかSMSでのコンタクトを依頼しています。暗号化、匿名性は放棄すると言うことです。 LINEなどを使っていると「じゃ、LINEで」と言われるので、私はLINEなどのアプリは使わずインストールさえしていません。 ネットで知り合ったような他人については、どちらの匿名性も重要だと思います。しかし、私は、匿名のままネットで知り合った相手とメッセージングアプリを使って通信するようなニーズはないので無視します。 まとめ</h2> LINE・WhatsApp・iMessage・Signalなど主要なメッセージングアプリは、暗号化や水平的匿名性は実装されていますが、垂直的匿名性は担保されていません。LINEなど「なりすまし防止、復旧、法令遵守」などを理由に電話番号への紐付けを強化しています。自治体などでLINEを使用するケースが多いようですが、あれは個人特定を行政として放棄しているとしか思えません。 私にとって必要なのは垂直的匿名性です。メッセージの中身が暗号化されていても、運営に身元や「誰といつ通信したか」を握られては、プライバシーを守ったことになりません。一方、相手に対しても名乗らない水平的匿名性は、私個人にはほとんど必要ありません。 両方の匿名性を保てるのは、Threema・Session・SimpleXの3つです。 米国報道機関ではSignalが使用されているケースが多いようです。 </aside> 両方の匿名性が必要なのは、相手や運営に身元を伏せたまま連絡したい場面だけです。こうしたニーズは犯罪目的での使用を想起するかもしれませんが、内部告発や情報提供など正当な目的のためにも必要です。米国では報道機関が情報提供の窓口としてメッセージングアプリの宛先などを公開しています。日本ではこうした使い方はほとんど根づいておらず、全く遅れています。 大切なのは、自分がどちらの匿名性を必要とするのかを見極めることです。垂直的匿名性はほとんどの人に効きますが、水平的匿名性まで求めるかは人によって大きく変わります。私自身は、身元を隠す必要のない家族との連絡に、垂直的匿名性を保ちつつ扱いやすいThreemaを使っています。 References</h2> Threema</a>. "Anonymity at the System Level: The Ultimate Privacy Protection"</li> Threema</a>. "Statement on ETH Findings"</li> ETH Zurich Applied Cryptography Group</a>. "Three Lessons from Threema"</li> Signal</a>. "Keep your phone number private with Signal usernames"</li> Signal Foundation</a>. "Signal Foundation"</li> SimpleX Chat</a>. "How SimpleX works"</li> Session</a>. "Introducing the Session Technology Foundation"</li> Session</a>. "Session code audit by Quarkslab"</li> WhatsApp Help Center</a>. "About end-to-end encryption"</li> Apple Support</a>. "iMessage security overview"</li> Element</a>. "Creating a Matrix Account"</li> LINE Help Center</a>. "Letter Sealing"</li> LINEヤフー</a>.「LINE暗号化状況レポート（2025年）」</li> </ul> </div> pCloud DriveのmacOS Tahoe問題 2026-06-27T10:00:00+09:00 Table of Contents</summary> </details> macOS Tahoe(macOS 26)に上げてから、pCloud Driveが起動するが機能しない状態となりました。やっかいなのは、アプリ単体では済まず、うっかりpCloud Driveを開こうとするとキーボードが効かなくなるなどMac全体が一時的に不安定になる点です。 pCloudとは</h2> pCloudは、スイスのpCloud AGが提供するクラウドストレージサービスです。買い切りの生涯プランがあること、ファイルを暗号化して預けられること、そしてアカウントを作ると無料枠から使い始められることで知られています。 Macで使う場合、もっとも手軽なのは公式のpCloud Driveアプリです。これはクラウド上のファイルを、ローカルの仮想ドライブ(~/pCloud Drive</code>)としてマウントして見せてくれます。Finderから普通のフォルダのように開けるので、クラウドを意識せずに使えるのが利点です。 一方で、この「仮想ドライブとして見せる」仕組みは、macOSのファイルシステム拡張に依存します。後述するように、ここがOSのアップデートで影響を受けやすい部分でもあります。 macOS Tahoeでの不具合</h2> 私の環境はApple SiliconのMacで、OSはTahoe(macOS 26)です。アップデート後、pCloud Driveが機能せず、開こうとするとOS全体の挙動が一時的に不安定になりました。 同様の現象が一般に報告されているか調べたところ、Tahoe環境での不具合報告が複数見つかりました。代表的なものは次の通りです。 アップデート後に「Enable Disk(仮想ドライブのマウント)」が機能しない</li> メニューバーのアイコンが表示されない</li> ドライブは見えてもマウント・同期ができない</li> ドライブ有効化時に「outdated(古い)」と表示され有効化できない</li> </ul> これらはフォーラムでの報告であり、「同様の事例が存在する」ことの裏付けにはなりますが、原因や解決を断定する根拠にはなりません。pCloud公式が症状ごとの原因を断定して公表しているわけでもありません。そのため、ここから先に書く原因は、あくまで私の推測として読んでください。 pCloud Driveは、クラウドをローカルの仮想ドライブとして見せるために、ファイルシステム拡張(pCloudFS / macFUSE)を使います。この低レベルの拡張がロードに失敗したり、カーネル側で引っかかったりすると、アプリ単体のクラッシュにとどまらず、OS全体の挙動に波及することがあります。私が遭遇した「開こうとすると全体が不安定」という症状は、このパターンと整合します。OSのメジャーアップデート直後は、こうした低レベル拡張の互換性が崩れやすく、不安定になりがちです。 pCloud Driveのアンインストール</h2> macOS向けのpCloud DriveはApple Siliconになってから問題も多く、macOSの変更による影響も受けやすいのでうんざりしていました。 OS全体を巻き込んで不安定になるアプリの回復に時間をかけるより、他の方法に移行しpCloud Driveはアンインストールすることにしました。 アンインストールは次の2ステップが必要です。 ログイン項目からpCloud Driveを外してmacOSを再起動</li> pCloud Driveの削除</li> </ol> まずシステム設定 → 一般 → ログイン項目と機能拡張からpCloud Driveを外し、いったんmacOSを再起動して拡張の常駐を切ります。 次にアプリ本体を削除です。 手動で削除する場合は、pCloud Driveを完全終了(できればアプリ内でログアウト/Unlink)してから、アプリ本体をゴミ箱へ移し、~/Library</code>配下の残骸を削除します。主な残骸は次の場所です。 ~/Library/Application Support/pCloud ~/Library/Application Support/com.pcloud.pcloud.macos ~/Library/Caches/com.pcloud.pcloud.macos ~/Library/Preferences/com.pcloud.pcloud.macos.plist</code></pre> 私が実際に使ったのは、CLIのアンインストーラであるMole(tw93/Mole</code>)です。Homebrewで導入でき、コマンド名はmo</code>になります。 brew install mole</code></pre> mo uninstall</code>は、アプリ本体に加えて、launch agentやPreferences、Cachesといった関連ファイルもまとめて削除してくれます。安全のため、まず--dry-run</code>で削除対象を確認してから本実行しました。対象アプリの正確な名前は--list</code>で確認できます。 mo uninstall --list # mo uninstall が受け付ける正確なアプリ名を一覧表示 mo uninstall --dry-run "pCloud Drive" # 削除対象を事前確認(変更は行わない) mo uninstall # 対話形式の一覧から pCloud Drive を選んで実行</code></pre> 引数なしのmo uninstall</code>は対話形式のセレクタを開くので、一覧からpCloud Driveを選んで実行します。アプリ名を引数で渡せば、対話なしで直接アンインストールできます。削除されたファイルは既定でゴミ箱へ送られるため、必要なら復元できます。 Moleが消すのは、主にユーザーレベルの関連ファイルです。macOSにシステム拡張として登録された部分(pCloudFS / システム拡張)は対象外になることがあります。通常はmacOSを再起動するとクリアされますが、残っていないかは次のコマンドで確認できます。 systemextensionsctl list # pCloud AG の拡張が残っていないか確認</code></pre> Mole自身も、macOS 15以降では一部の拡張系の権限エントリがアプリ削除後も残ること、そしてその種のリセットはグローバルかつリカバリモードを要するため自動では行わないことを、警告として明示しています。ツール任せにせず、最後は再起動とsystemextensionsctl list</code>での確認で締めるのが現実的です。私の環境では、ログイン項目から外して再起動したあとにアンインストールしたこともあり、最終的にpCloud AGの拡張は1つも残りませんでした。 なお、pCloud Driveアプリをアンインストールしても、pCloudアカウント自体は消えません。Web(my.pcloud.com)からファイルにはアクセスできますし、消えるのは有効化済みの同期設定とカスタム設定だけです。 rcloneでの設定方法とメリット</h2> rclone</a>は、各種クラウドストレージをコマンドラインから統一的に扱えるツールです。以前「rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ</a>」でAmazon S3を使った長期保管の構成をまとめましたが、pCloudもバックエンドとして公式にサポートされています。 設定はrclone config</code>の対話で行います。ブラウザ認証を済ませると、設定ファイル~/.config/rclone/rclone.conf</code>が作られ、内容は次のようになります。 [pcloud] type = pcloud hostname = eapi.pcloud.com token = {"access_token":"<rclone config の認証で自動生成されるアクセストークン>","token_type":"bearer","expiry":"0001-01-01T00:00:00Z"}</code></pre> ここでtoken</code>はrclone config</code>のOAuth認証で自動生成されるものです。手で書く必要はありませんし、アクセストークンそのものなので、他人に見せたりリポジトリにコミットしたりしないよう注意してください。この記事でも実際の値はプレースホルダに置き換えています。 私はプライバシーを重視しているので、ヨーロッパリージョン(eapi.pcloud.com</code>)を使っています。 </aside> hostname</code>はリージョンを指します。eapi.pcloud.com</code>はヨーロッパリージョン、api.pcloud.com</code>(デフォルト)は米国リージョンです。アカウントがヨーロッパリージョンの場合は、ここをeapi.pcloud.com</code>に設定しておかないとトークンエラーになることがあります。通常はOAuth認証の過程で適切に設定されますが、うまくいかないときはこの値を疑ってください。 設定できたら、まずは中身が見えるか確認します。 rclone lsd pcloud: # トップ階層のディレクトリ一覧 rclone copy pcloud:My\ Pictures ~/Downloads/pics # 取り出し(ダウンロード) rclone sync ~/work pcloud:work # ローカルからクラウドへ同期(送信)</code></pre> Finderのようにフォルダとしてマウントしたい場合はrclone mount</code>も使えますが、こちらはmacFUSEを必要とします。日常的なファイルの取り出しや同期は、マウントせずとも上記のコマンドだけで完結します。 pCloud Driveからrcloneへ寄せる利点は、大きく2つです。 macOSへの非依存</dt> コマンドベースの転送(copy</code>、sync</code>、lsd</code>、cat</code>)はファイルシステム拡張を使わず、ユーザーランドだけで完結する。今回の不具合の原因だったpCloudFS / macFUSEとは無縁で、OSのメジャーアップデートにも振り回されない。</dd> CLIでの自動化</dt> CLIとなることで、launchd</code>やシェルスクリプトに組み込みが自由になる。バックアップや定期同期などを自動化して回せる。</dd> </dl> pCloudのサービス継続性について</h2> ここで、pCloudというサービス自体の信頼性にも触れておきます。 pCloudの大きなウリは、一度の支払いで使い続けられる買い切り(Lifetime)プランです。ただし、その「Lifetime」が何を指すのかは、規約を読むと印象より限定的です。pCloudの利用規約は、買い切りプランの有効期間を「アカウント所有者の生存期間か99年のいずれか短い方」と定義しています。さらに「pCloudが事業を停止した場合、アカウントは終了し、サービスは提供されない」とも明記されています。買い切りは、永久でも、企業の存続から独立した保証でもありません。 そうなると運営元の規模が気になります。 pCloudを提供するpCloud AGはスイスの非上場企業で社員は数十人規模、外部資本を入れないブートストラップ経営です。非上場企業のため正確な業績は外から分かりません。出回っている年商も10億円程度1</a>です。 pCloudサービスは設立から10年以上続き、ユーザーも2,000万を超えて伸びており、「経営が危ない」という状況ではなさそうです。 しかし、規模の小ささ自体が構造的な継続性リスクになります。買収や方針転換、大手との競争で、サービスの将来を一個人が見通すことはできません。また、規模の小ささが、今回の様な新しいmacOSへの対応の遅れの要因ともなっているかと思います。 だからこそ、買い切りだからと唯一の保管先にはせず、今回のrcloneのような別経路や、ローカル・別クラウドにもコピーを持っておくのが現実的だと考えています。 まとめ</h2> macOS Tahoeとの互換性によるpCloud Drive不具合から、一旦rcloneに移行しました。 とはいえ、pCloud DriveはDropboxのSmart Syncのようにキャッシュだけのローカルに置く方式で便利なので、いつか安定したら戻りたいものです。 振り返ってみると、pCloudの2TBライフタイムを購入したのは2021年です。350ドル（当時のレート1ドル約109円で約38,200円）の一括払いでした。仮に、Dropbox Plusの2TBを使用していたとしたら、年額15,840円（税込）かかります。 2年半足らずで買い切りが追いつき、購入から約5年が経った今では、Dropboxなら累計8万円ほどかかっていた計算です。円で累計コストを並べると、その差がはっきりします。 あまりヘビーに依存せず上手に使っていきたいと思います。 References</h2> pCloud</a>. 「pCloud for macOS リリースノート」</li> pCloud</a>. 「コンピュータからpCloudをアンインストールするとどうなりますか」</li> pCloud</a>. "Terms and Conditions"</li> Apple Support</a>. "Delete apps on your Mac"</li> rclone</a>. "pCloud backend documentation"</li> Mole</a>. "tw93/Mole"</li> </ul> </div> 創業者の自己申告(約16.5億円)と第三者の推計(約6.6億円)で2倍以上の開きがあり、健全性を客観的に確かめる手段がありません。 ↩</a> </li> </ol> </section> GR IV Monochromeから始めるdarktable現像術 2026-06-12T09:46:20+09:00 Table of Contents</summary> </details> RICOH GR IV Monochrome</a> を手に入れました。モノクロ専用機です。買うべき理由や撮影時の設定は別記事にまとめましたが、本稿はその続きにあたります。このカメラを手にしたのを機に、長らく惰性で使ってきたRAW現像アプリを一度見直すことにしました。撮ったあとの工程、つまり選定の記録と、最終的に選んだdarktableをモノクロ前提でどう使っているかのメモです。 RAW現像アプリの選定</h2> これまで使ってきたのは、市川ソフトラボラトリーのSILKYPIXでした。ただ、選んで使い続けてきたというより惰性です。今回そのまま使えなかったのは、GR IV Monochromeに対応していないからです。SILKYPIXは未対応のカメラ・レンズのRAWファイルをそもそも開けません。加えてMac版はWindows版から数年遅れたまま放置されており、現像も遅いと、見直す理由はそろっていました。 候補としていちばん有力だったのはAdobeのLightroom Classicです。操作は直感的で非常に使いやすく、RAWファイルのライブラリ構成を自分で管理でき、Lightroomが勝手に干渉してこないのも気に入っています。ただし、使うには悪名高いAdobeのサブスクリプションが要ります。そこだけがどうしても引っかかりました。 結局、無料でありながら高機能なdarktableを使うことにしました。 darktable</h2> darktableは高機能なのですが、Lightroomのように機能が整理されておらず、最初は取っ付きにくいツールです。モジュールの数も多く、全部を理解しようとすると挫折します。そこで、モノクロ前提で本当に使うモジュールだけを絞り込みました。現像はおおむね次の順序で進めます。 lens correction</code>（必須）— Lensfunデータベースを使い、歪曲と周辺減光を補正する</li> exposure</code>（必須）— 主要被写体の中間調を適正にする(白飛び・黒つぶれは無視)</li> sigmoid</code>（必須）— ダイナミックレンジを表示レンジへ圧縮する(filmic rgb / agxでも可)</li> denoise (profiled)</code>（オプション）— ノイズを抑える</li> rotate and perspective</code>（オプション）— 傾いた水平を出す(必要ならパースも整える)</li> retouch</code>（オプション）— ゴミや不要物を消す</li> tone equalizer</code>（オプション）— 明暗の局所コントラストを足す</li> diffuse or sharpen</code>（オプション）— 仕上げにシャープ化する(旧来のsharpenでも可)</li> crop</code>（オプション）— 最後に構図をトリミングする</li> </ol> この流れの前提になっているのが、darktableが標準で採るscene-referredワークフローです。これは、センサーが捉えた光の量(リニアな値)をできるだけそのまま保ったまま現像を進め、モニタ表示に合わせた明暗の調整は最後にまとめて行う、という考え方です。明るさの情報を途中で切り詰めず、広いダイナミックレンジのまま持ち越して、いちばん最後にトーンマッピング(sigmoid</code> など)で表示レンジへ圧縮します。 この前提があるので、作業は自然と二段構えになります。exposure</code> では主要被写体の中間調だけを合わせ、白飛び・黒つぶれはあえて気にしません。広い階調はあとで sigmoid</code> がまとめて表示レンジに収めてくれるからです。本稿のモジュール選定も、この流れに沿っています。 なお、darktableのモジュールは画面に並んだ順ではなく、内部で決められたパイプライン順に適用されます。上の並びはそのパイプライン順ではなく、darktable公式マニュアルが薦める作業順(最初にlens correction、次に基礎となる露出とトーンマッピング、続いて各種補正、最後に構図の仕上げ)に沿っています。 lens correction</h3> </div> lens correction</code> を有効にすると、Lensfunデータベースを参照して歪曲と周辺減光を自動補正します。GRの単焦点にもわずかな樽型の歪曲と周辺減光があり、これをまず取り除いておきます。 </div> </div> 6月12日時点では、Lensfunの公式データベースにRICOH GR IV Monochromeはまだ登録されていません。ただしGR IV(カラー機)は登録済みで、Monochromeのレンズ(光学系)はGR IVとまったく同じです。違いはセンサー前のカラーフィルターの有無だけなので、補正すべき歪曲・周辺減光のデータは共通して使えます。 問題は、MonochromeがEXIFに記録するカメラ名がGR IVとは別の文字列で、公式データベースのGR IVエントリに自動マッチしないことだけです。そこで、ユーザー領域のLensfunデータベースにMonochrome用のカメラ定義を1つだけ追加し、マウントをGR IVと同じ ricohGRIV</code> にして既存のレンズ補正データを流用します。 darktableは ~/.local/share/lensfun/</code> 配下に置いたXMLを読み込みます。ここは公式データベースの更新では上書きされない領域です。次のファイルを置きます。 <lensdatabase version="1"> <camera> <maker>Ricoh Imaging Company, Ltd.</maker> <maker lang="en">Ricoh</maker> <model>Ricoh GR IV Monochrome</model> <model lang="en">GR IV Monochrome</model> <mount>ricohGRIV</mount> <cropfactor>1.53</cropfactor> </camera> </lensdatabase></code></pre> <model></code> は実機がEXIFに書き込むモデル名と一致させる必要があります。手元の値は exiftool</code> で確認できます。darktableを再起動すると、スクリーンショットのようにcamera欄へ「Ricoh, GR IV Monochrome」が現れ、lens欄にはGR IVの固定レンズ補正がそのまま当たります。 exposure</h3> </div> scene-referredワークフローの起点です。前述のとおり、ここでは主要被写体の中間調が適正になるよう露出だけを決め、白飛びや黒つぶれは気にしません。スライダーを動かして、見せたい部分の明るさを合わせます。 </div> </div> sigmoid</h3> </div> scene-referredな広いダイナミックレンジを、モニタが表示できる範囲へ圧縮するトーンマッピングです。darktableではfilmic rgbやagxと同じ役割を担い、sigmoid</code> はそのなかでも素直に効きます。基本はcontrastで圧縮の強さを、skewでシャドウ側とハイライト側のどちらを持ち上げるかを決めるだけです。モノクロではprimaries(色の扱い)の各パラメータは結果に影響しないので、触る必要はありません。 </div> </div> denoise (profiled)</h3> </div> 高感度で撮った暗所のカットなどで、輝度ノイズのザラつきが気になるなら使います。 センサーごとに測定されたノイズの統計プロファイルを参照してノイズを除去するモジュールです。モノクロは輝度ノイズがそのまま見えるぶん、ザラつきが目立ちやすいので、気になるカットで抑えます。低感度で破綻がなければ飛ばして構いません。 </div> </div> rotate and perspective</h3> </div> 水平が傾いてしまったカットや、建築物の垂直を立て直したいときに使います。GRはノーファインダー撮影が多く、水平も傾きやすいカメラです。 rotationスライダーで角度を調整するか、画像上で水平にしたい線をドラッグして指定すると、その線が水平(または垂直)になるよう自動で回転します。パースの崩れを直したいときは、隠れているlens shiftやshearのコントロールも使えますが、スナップ中心の用途なら水平出しだけで十分です。 </div> </div> retouch</h3> </div> センサーのゴミや、写り込んだ不要物が目立つときに使います。 ヒーリングやクローンで対象を周囲になじませて消すモジュールです。モノクロは小さなゴミも意外と目立つので、気になるときだけ使い、なければ飛ばします。 </div> </div> tone equalizer</h3> </div> 特定の明るさ帯だけを覆い焼き・焼き込みしたいときに使います。たとえばシャドウだけ持ち上げたいが全体は明るくしたくない、といった局所的な明暗調整に向きます。 露出帯(-8EV〜0EV)ごとに明るさを持ち上げ・押し下げでき、全体ではなく狙った帯だけに局所コントラストを足せます。 </div> </div> diffuse or sharpen</h3> </div> 仕上げに解像感を一段上げたいときに使うシャープ化モジュールです。 偏微分方程式ベースで、プリセット(sharpen demosaicingなど)から選ぶと扱いやすくなります。軽く整える程度なら、旧来の sharpen</code> モジュールでも十分です。 </div> </div> crop</h3> </div> 周辺の不要な部分を切り落として構図を整えたいときに使います。 darktableは露出やトーンの調整を画面全体に対して効かせるので、トリミングは仕上げの段階に回します。アスペクト比は自由(freehand)のまま、不要な周辺を切り落として構図を決めます。 </div> </div> References</h2> darktable user manual</a>. darktable公式ユーザーマニュアル</li> darktable user manual</a>.「the pixelpipe and module order」scene-referredワークフローと処理の流れ</li> darktable user manual</a>.「lens correction」モジュール</li> darktable user manual</a>.「rotate and perspective」モジュール</li> darktable user manual</a>.「crop」モジュール</li> darktable user manual</a>.「sigmoid」モジュール</li> Lensfun</a>. レンズ補正データベースのプロジェクトサイト(GitHub リポジトリ</a>)</li> discuss.pixls.us</a>.「darktable 4.8 location of lensfun database for personal use」ユーザー領域へのLensfunデータ追加方法</li> </ul> </div> Macバックアップ戦略・改訂版 2026-06-09T13:37:30+09:00 Table of Contents</summary> </details> 長らくMacのバックアップにはSuperDuperを使い、Bootableなクローンを作ってきました。その方針は、以前Apple Silicon時代のMacバックアップ最新戦略</a>で整理したとおりです。ですが新しいmacOSへの対応がなかなか進まず、Tahoeに至っては一年あまり経った今も正式版すら出ません。そこでSuperDuperを諦め、rsyncでホームディレクトリを鏡像コピーする方式に切り替えました。この記事はその続編であり、乗り換えの理由と設定方法をまとめたものです。 なぜTime Machineが嫌いか</h2> バックアップの話をすると、まずTime Machineを勧められます。ですが私は、ごく初期に使ったきり、その後はすっかり避けるようになりました。 もともとは、Bootableなクローンを作れるサードパーティツールを使っていたからです。 Bootableなクローンが作れれば、ディスクが壊れた際にはクローンからmacOSを起動して復旧できます。 ただし、現在ではBootableなクローンを技術的に作成できなくなりました(後述)。それでも、Time Machineには不信感が根強く、直感が先に拒否します。その裏には技術的な理由が3つあります。 不確実性 Time Machineはバックアップ先を専用のアーカイブ(sparsebundle)として抱え込む。中で何が起きているかは見えず、壊れていても警告は出ない。実際、復元しようとしたらアーカイブが読めず、修復もできず、履歴を全部捨てて最初からやり直すしかなかったという報告は後を絶たない。</li> </ul> </li> 破損に弱い sparsebundleは中身を多数の小さなバンドファイルに分け、その内側に1つのファイルシステムを抱える構造になっている。個々のファイルを直接取り出すことはできず、必ずイメージ全体をマウントして読む。だからバンドや内部の目次(カタログ)が一部でも壊れると、イメージごとマウント不能になり、世代を問わず全データに手が届かなくなる。世代を積み上げる構造だけに、過去のバックアップまでまとめて道連れになりやすい。</li> </ul> </li> ブラックボックス 何がどうコピーされ、どう積み上げられているのか、仕組みそのものがユーザーからは見えない。バックアップ先を開いても何がどう入っているか分からず、「このファイルが今そこにある」とFinderで素朴に確かめることもできない。中で何が行われているか把握できないものに大事なデータを預けるのは、技術者としてどうにも信用しきれない。</li> </ul> </li> </ul> 私が欲しいのはその逆です。バックアップ先を開けば、コピー元とそっくり同じ構造でファイルがそのまま並んでいて、いざというとき個別のファイルをドラッグで取り出せる。履歴はいりません。今この瞬間の鏡像が1つあれば十分です。見えて、触れて、そのまま取り出せること。Time Machineはこの要求に対して、仕組みからして向いていません。 そのため、私は丸ごとBootableなディスククローンを作成できるサードパーティ製のツールを利用してきました。 macOSの変化で、bootableクローンが封じられた</h2> ところが、ここ数年のmacOSの変化で、その前提が崩れました。サードパーティ製ツールによるBootableなクローンが、事実上できなくなったのです。経緯を追うと、じわじわと封じられてきたことが分かります。 Big Surでシステムとデータが分離 起動ディスクが、OSの入った読み取り専用のシステムボリュームと、ユーザーデータのデータボリュームに完全分離された。システム側は改ざん防止のため署名・封印され、サードパーティ製アプリが直接コピーできなくなった。OSを複製する役目はApple自身の仕組み(レプリケーター)に移り、それが動き続けるかどうかもApple次第になった。</li> </ul> </li> Sequoia 15.2が決定打 Appleがそのレプリケーターを壊し、SuperDuperはBootableなバックアップを作れなくなった。データ複製の終盤、PrebootやRecoveryをコピーするあたりで失敗する。これはツール側のバグではなく、Apple側の問題だと開発元が明言している。</li> </ul> </li> Tahoeでは正式対応すら出せず 互換性の壁がさらに増え、SuperDuperは正式版を出せていない。Tahoe対応は暫定ベータ(v3.20系)でしのぐ状態が続いている。一時はベータでの改善に期待もしたが、一年あまり経ってもベータのまま。起動可能クローンへの望みは、もう捨てた。</li> </ul> </li> </ul> 要点を取り違えないことが大事です。壊れたのはBootableなシステム丸ごとクローンであって、ホーム(データ)のコピーが禁じられたわけではありません。Appleが封じたのはシステムボリュームの複製で、ユーザーのデータをコピーすること自体は今も普通にできます。 今日のmacOSでのバックアップ戦略</h2> ここで要件が変わります。 Bootableにできないのなら、システムボリュームまで丸ごとコピーする意味はもうありません。bootableという目的が消えた以上、「全部コピーする」根拠も一緒に消えました。残ったのは、自分のデータだけを守れればいい、という縮退した要求です。 つまり「ホームディレクトリだけでいい」は、最初からそう思っていたわけではありません。bootableを失った結果として、そこまで切り詰めた制約の上に成り立っています。この経緯を踏まえると、要件は次のように整理できます。 バックアップ対象はホームディレクトリのみ。システムは諦める。</li> アプリが~/Library</code>配下などに書く、ユーザーが関知しないデータも要らない。多くは再生成されるので、守る価値がない。</li> 差分でいい。変わっていないファイルは書き換えず、変わったぶんだけ転送する。</li> 世代管理はいらない。常にコピー元と同じ、今この瞬間の鏡像が1つあればいい。</li> </ul> rsyncのメリット</h2> この縮退した要件に、rsyncはきれいに合います。 第一に、差分転送が本職です。rsyncは初期状態で、サイズと更新日時を見て一致するファイルをまるごとスキップします。変わっていないファイルは触らず、変わったぶんだけ送ります。「変更ないファイルは書き換えたくない」という要求が、特別な設定なしにそのまま満たされます。 第二に、コピー先がただのファイルになります。バックアップ先は元と同じフォルダ階層がそのまま並ぶので、Finderで全部見えますし、個別ファイルをドラッグで取り出せます。Time Machineの抽象化とは正反対の、見える鏡像が手に入ります。 第三に、世代を持たない運用ができます。--delete</code>を付ければ、コピー元で消したものはバックアップ先からも消え、常に最新の一枚の鏡像が保たれます。履歴の束は作られません。 第四に、無料で、スクリプトに組めて、スケジュール実行まで自前で完結します。専用アプリのライセンスや、OSの更新に追従できないツールの都合で振り回されることもありません。 </div> 標準のrsyncは使わない Sequoia/Tahoe標準のrsyncはopenrsync</code>という別実装で、出来がよくありません。-a</code>で特殊ファイルに当たると止まる、拡張属性でクラッシュするといった報告があります。標準のものは避け、Homebrewで本家のrsync(3.x系)を入れて使いましょう。 </div> </div> 準備</h2> まずHomebrewで本家rsyncを入れます。TahoeはApple Silicon専用なので、入れると/opt/homebrew/bin/rsync</code>に置かれます。 brew install rsync</code></pre> もう1つ、フルディスクアクセスの設定が要ります。最近のmacOSでは、これが無いとホーム内の保護領域(メールなど)が読めず、警告も出さずに黙って飛ばされます。手で動作確認するときは使っているターミナルを、自動実行するときは後述のスクリプトを、システム設定のプライバシーとセキュリティ → フルディスクアクセスに追加しておきます。これを怠ると「バックアップしたつもりで一部入っていない」が起きます。 コマンドと除外設計</h2> バックアップ本体は、次の一本にまとめます。 #!/bin/bash DEST="/Volumes/Backup" LOG="$HOME/Library/Logs/backup-home.log" if ! /sbin/mount | grep -q "on $DEST "; then echo "$(date) $DEST not mounted, skipped" >"$LOG" exit 0 fi /opt/homebrew/bin/rsync -aE --delete --info=progress2 \ --exclude='/Library/' \ --exclude='.Trash/' \ --exclude=".cache/" \ --exclude='tmp/' \ --exclude='.DS_Store' \ --exclude='/pCloud Drive' \ --exclude='/.pcloud/' \ "$HOME/" "$DEST/home/" >"$LOG" 2>&1 echo "$(date) done" >>"$LOG"</code></pre> 先頭のif ! /sbin/mount ...</code>は、バックアップ先が未マウントのときに内蔵ディスクへ誤って書き込む事故を防ぐガードです。-a</code>は権限・更新日時・シンボリックリンクなどを保ったまま再帰コピーし、-E</code>はmacOSの拡張属性を保持します。--delete</code>でコピー元から消したものをバックアップ先からも消し、常に鏡像に保ちます。--info=progress2</code>は全体の総進捗を一行で表示します。$HOME/</code>の末尾スラッシュは「ホームの中身を」コピーする指定で、これが無いとhome自体が一段深く入れ子になります。 除外設計が実は一番の勘どころになります。詰まりの原因はほぼここに集約されます。 .Trash</code>はゴミ箱、.cache</code>やtmp</code>は再生成される一時データ、.DS_Store</code>はFinderの表示情報。どれもバックアップする価値がない。</li> クラウドや外部接続の仮想ドライブも必ず外す。ローカルに実体がなく、rsyncが舐めるとオンデマンドのダウンロードを次々誘発し、激遅やタイムアウト、最悪はクラウド上の全データの引きずり下ろしを招く。iCloud DriveやDropbox、OneDrive、Google DriveはLibrary/CloudStorage</code>やLibrary/Mobile Documents</code>にあるので、/Library/</code>を外せば一緒に消える。pCloud Drive</code>のようにホーム直下へマウントされるものだけ、個別に除外する。</li> </ul> Library</code>配下をどこまで残すかは判断が要ります。大半はアプリが再生成する状態ファイルなので、丸ごと--exclude='Library/'</code>で外しても困らない人は多いでしょう。ただしローカルにしか実体のないデータ(ローカル保存のメールなど)がある場合は、その特定フォルダだけ残す配慮がいります。 自動化</h2> 週1回の自動実行は、非推奨のcronではなくlaunchdで組みます。さきほどの~/bin/backup-home.sh</code>に実行権を付けます。 chmod +x ~/bin/backup-home.sh</code></pre> 次に~/Library/LaunchAgents/com.user.backup-home.plist</code>を作ります。毎週日曜の午前3時に走る例です(Weekdayの0が日曜)。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.user.backup-home</string> <key>ProgramArguments</key> <array> <string>/Users/ユーザ名/bin/backup-home.sh</string> </array> <key>StartCalendarInterval</key> <dict> <key>Weekday</key><integer>0</integer> <key>Hour</key><integer>3</integer> <key>Minute</key><integer>0</integer> </dict> </dict> </plist></code></pre> 登録します。 launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.user.backup-home.plist</code></pre> launchdの利点は、指定時刻にMacが起動していなくても、次に起動したときに取りこぼしを拾って実行してくれる点です。cronのように「その時刻に寝ていたら丸ごと飛ぶ」ということがありません。複数回ぶんが溜まっても、起動時に走るのは1回にまとめられます。週一の用途なら、これで実用上困りません。 つまずきどころ</h2> 実際に動かすと、たいてい最初の数回はここで引っかかります。 初回はホーム全体のフルコピーなので、容量とドライブ速度によっては数時間かかる。差分で速くなるのは2回目以降。止まっているのか遅いだけなのかは、du -sk /Volumes/Backup/home</code>を時間を空けて2回打ち、数字が増えているかで判別する。</li> 異常に遅い・止まる場合は、まず標準の/usr/bin/rsync</code>(openrsync)を叩いていないかwhich rsync</code>で確認する。そして上のクラウド系の除外が効いているかを見る。GoProなどをMTP接続してマウントしている場合、それもLibrary/CloudStorage</code>に入り込んでタイムアウトの山を作るので、除外で一掃される。</li> Permission Deniedが出ても、rsyncはそのファイルを飛ばして続行する。多くはフルディスクアクセス不足か、root所有の触れないファイルだ。前者は設定で解決し、後者は無視してよいが、拒否されたのが自分の大事なデータでないかだけは確認する。</li> </ul> まとめ</h2> この構成にも、諦めた点はあります。起動可能なクローンではないので、ディスクが飛んだら、まずmacOSを入れ直し、それからホームを書き戻す手間が残ります。アプリの再インストールも要ります。「つなげば即座に元通り」とはいきません。そこは割り切りです。 それでも私は、こちらを選びました。中身が見えて、いざとなれば一ファイルから引き出せて、仕組みを丸ごと自分の手で握れる。バックアップに一番ほしいのは、派手な復旧速度ではなく、この「見えている」という安心でした。OSやアプリの都合に振り回されないかぎり、この鏡像は週末ごとに静かに更新され続けてくれます。それだけで、私には十分です。 三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退 2026-06-08T00:00:00+00:00 三菱UFJ銀行が2026年6月8日付で「当行からの添付ファイル送信方法の変更に関するご案内</a>」を公表しました。日本を代表するメガバンクがまだPPAPやっていたと衝撃を受けました。内容を読んで考えさせられたので記録しておきます。 三菱UFJ銀行のアナウンス</h2> 要点はシンプルです。 同行は、お客さま側のセキュリティを確保するため、パスワード付き添付ファイルのメール送信を原則取り止めると発表しました。 2026年7月18日より順次、添付ファイルを送る際は専用のダウンロードサイトを利用する方式へ変更されます。 理由として挙げられているのは次の2点です。これまでの「メールでパスワード付きZIPファイルを送り、パスワードを別送する方法」、いわゆる PPAP は、ファイルが暗号化されているためメール受信時のマルウェアチェックが困難であること。そして近年、パスワード付きZIPファイルを悪用したサイバー攻撃の事例が確認されていることです。 新方式では、同行の役職員が添付ファイルを送る際、メール本文に専用ダウンロードサイトへアクセスするためのURLを記載します。受け手はそのサイトにアクセスし、別送されるダウンロード専用のパスワードを使ってファイルを取得します。 PPAPの何が問題だったのか</h2> PPAPの是非については、昨年「AWSからSMSにメッセージを送る</a>」という記事で一度整理しました。 そのとき、機密文書をメールで送る手段を秘匿性と本人確認性の観点で並べて評価したのですが、結論は変わっていません。 PPAP、つまり暗号化ファイルとパスワードを同じ経路で送る方法は、1通盗まれればすべて漏洩します。パスワードを別メールにしても、同じメールインフラを流れる以上、傍受や誤送信のリスクは本質的には下がりません。加えて、暗号化されたZIPはメールゲートウェイでウイルススキャンできないため、マルウェアの運び屋になりやすい。三菱UFJ銀行が今回理由として挙げているのは、まさにこの最後の点です。 ですから、PPAPをやめるという判断そのものは正しいと思います。日本でも2020年に政府がPPAPの廃止方針を打ち出して以降の流れに沿っていますし、銀行という立場で旗を振る意味も小さくありません。 新方式は本当に安全になったのか</h2> 問題は、その置き換え先です。 新方式は「メール本文にダウンロードサイトのURLを記載し、パスワードは別送する」というものでした。マルウェアスキャンの観点では確かに前進しています。ファイルが暗号化ZIPとしてメールに乗らなくなるので、受信側のゲートウェイで中身を検査できるようになるからです。 しかし、フィッシング耐性という観点では、むしろ後退しかねません。 ひとつは、銀行が自ら「メール本文のURLをクリックさせる」習慣を送信先に植え付けてしまう点です。銀行はこれまでフィッシング対策として、「当行からのメールにURLは記載しません」「メール内のリンクは開かないでください」と顧客には教育してきたはずです。メールの送信先は顧客ではないと思いますが、今回はその逆を習慣づけることになります。なりすましメールに偽のダウンロードURLが貼られていても、利用者は見分けがつかなくなります。 もうひとつは、「パスワードを別送する」という発想がPPAPのままという点です。日ごろ支援しているコンサルテーション会社やITベンダーはちゃんと技術的に支援できなかったんでしょうか？ URLとパスワードを両方メールで送るのであれば、構造的にはPPAPの暗号化ZIPをWebサイトに置き換えただけです。同じ経路を流れる以上、傍受や誤送信による漏洩リスクは解決していません。マルウェアの問題は片付いても、秘匿性の問題は手つかずなのです。 整理すると、今回の変更は「マルウェアスキャン」という一点ではマシになる一方で、フィッシング耐性では弱点を抱え込む、惜しい設計だと感じます。 本来あるべき姿</h2> 以前の記事</a>でも書きましたが、現実的なのは認証付きのクラウドストレージで共有する方法でした。受け手がログインして初めてファイルにアクセスできる仕組みなら、URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残せます。パスワードを別送する必要すらありません。 メールの送付先は取引業者だと思いますから、銀行が共通の認証を払い出すのは困難です。たとえばBoxやDropboxのようなクラウドストレージであれば、受け手は無料のアカウントを気軽に作れます。銀行側が取引先ごとにアカウントを発行・運用しなくても、受け手がログインして初めてファイルにアクセスできる仕組みを成り立たせられるわけです。 URLが単体で漏れても無効ですし、誰がいつアクセスしたかのログも残ります。 さらに言えば、この方式ならメールにリンクを書く必要すらありません。ファイルを共有すれば、受け手にはクラウドストレージ側から「共有されました」という通知が届きます。受け手は自分が信頼しているサービスにログインしてファイルを取りに行くだけです。冒頭で挙げた、メール内URLをクリックさせる習慣づけという問題が、根本から消えてなくなるのです。 より根本的な解はないのか</h2> もっとも、銀行ともあろうものがファイルの受け渡しを外部のクラウドサービスに丸ごと預けるのも、それはそれで引っかかります。委託先管理やデータの所在、サービスへの従属といった問題が新たに生じるからです。だとすれば、現実的な落としどころは、銀行が認証付きの受け渡しポータルを自前で持つことでしょう。インターネットバンキングという認証基盤と運用ノウハウをすでに備え、取引先の本人確認も日常的に行っている組織です。 Boxがやっていることを内製すればよいだけです。技術力と体力の両面で、銀行はそれができる立場にあります。 では、もっと教科書的な根本解はないのか。あります。受け手の証明書でメールそのものを暗号化・署名するS/MIME、いわゆるPKIです。外部サービスやポータル、パスワードの別送といった仕組みが一切要らず、本人性と秘匿性をエンドツーエンドで担保できる、理屈のうえでは最も美しい解です。 ところがPKIは、米国ですら普及しませんでした。証明書の発行や管理が高コストで手作業が多く、ユーザーごと・端末ごとに鍵を入れて回る運用負荷に耐えられなかったためです。そして決定的なのは、送り手と受け手の双方が対応していないと成り立たないという両側依存です。暗号化して送るには、相手があらかじめ証明書を用意していなければなりません。相手が対応していなければ、文字どおり意味がない。この鶏と卵の構造ゆえに、誰も最初の一歩を踏み出せませんでした。受け手に「アカウントを作ってログインする」という自己完結した操作しか求めないポータル方式に世界が流れたのは、そのためです。 それでもリーダーシップを期待したかった</h2> ここで私が惜しいと思うのは、まさにこの一点です。 PKIが普及しなかった最大の理由が「最初の一歩を誰も踏み出せなかった」ことなら、その一歩を踏み出せる体力と影響力を持つ組織こそ、日本を代表するメガバンクのはずです。 率先してS/MIMEを導入し、添付ファイルをやり取りするような主要な取引先には導入を促す。場合によっては証明書発行の基盤を貸し出したり、運用を支援したりする。そうやって両側依存の壁を、影響力のある側から崩していく。そんなリーダーシップを見せてくれたら、日本全体のメール文化が一段前に進んだかもしれません。 現実的な着地は認証付きポータルでよいと思います。ただ、PPAPをやめるという入口が正しかっただけに、出口がもう一歩踏み込めなかったのは惜しい。日本をリードする銀行のやることだからこそ、ここにこそリーダーシップを期待したかった、というのが私の正直な感想です。 References</h2> 株式会社三菱UFJ銀行</a>. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）</li> Coded Chords</a>. 「AWSからSMSにメッセージを送る」（2025年6月9日）</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> ChatGPT Images 2.0と、ブログのカバー画像パイプライン更新 2026-05-15T20:00:00+09:00 OpenAIは2026年4月21日、新しい画像生成モデルChatGPT Images 2.0を発表しました。API名は gpt-image-2</code> で、開発者向けには5月初旬から開放されています。私のブログではカバー画像の自動生成に旧モデル gpt-image-1</code> を使っていたので、乗り換える価値があるかを調べた上で、今回のリリースに合わせて実際に移行しました。本稿では、新モデルで何が変わったか、料金へのインパクト、そして自分のブログでの乗り換え作業をまとめます。 Table of Contents</summary> </details> ChatGPT Images 2.0で何が変わったか</h2> ChatGPT Images 2.0の特徴は、画像生成に「考えてから描く」という工程が入ったことです。プロンプトを受け取ったあとに構図やレイアウトを推論で組み立て、必要に応じて自己検証を挟んでから描画に進みます。OpenAI自身は「Agentic image generation」と表現しており、テキストから画像へのワンショット変換とは異なる挙動を示します。 実務面で効いてくる改良点を並べると次のようになります。 テキスト描画の精度向上</dt> 看板・図表・タイトルなど、画像内の文字を読める品質で出せるようになりました。印刷物にも耐える水準とされています。</dd> ネイティブ2K解像度</dt> 2048x2048を素のままで生成でき、有料プランでは4Kまでのアップスケールが選べます。前世代の引き伸ばし感は減りました。</dd> 自由なアスペクト比</dt> 3:1から1:3までの範囲で、16の倍数を満たす任意のサイズを指定できます。固定プリセットから連続パラメータへの転換です。</dd> マルチイメージのバッチ生成</dt> n=1〜8</code> でキャラクターやオブジェクトの一貫性を保ったまま、最大8枚を同時生成できます。</dd> </dl> なお「Thinking mode」と呼ばれる、Web検索を生成中に挟んで結果を補強する追加機能はChatGPT本体のPlus・Pro・Business・Enterpriseプランに限定されています。APIから素直に呼び出した場合に同等の挙動が得られるかは現時点で公開情報からは判然としません。日常的なカバー画像生成では恩恵が薄いため、本稿では深掘りしません。 合わせて、旧世代モデルのDALL·E 2およびDALL·E 3は2026年5月12日付で廃止されています。gpt-image-1</code> 自体の廃止は告知されていませんが、明確に前世代の位置づけになりました。 料金面のインパクト</h2> OpenAIの画像APIは、出力トークンに対する従量課金($30.00/100万トークン)を基準に、サイズと品質ごとに代表的な価格が公表されています。私のブログでは1536x1024/高品質を使っていたので、その線で比較します。 解像度 / 品質</th> gpt-image-1</th> gpt-image-2</th> 差分</th></tr></thead> 1024x1024 / high</td> $0.167</td> $0.211</td> +26%</td></tr> 1536x1024 / high(旧設定)</td> $0.25</td> $0.165</td> -34%</td></tr> 1536x1024 / medium</td> $0.063</td> $0.041</td> -35%</td></tr> 1536x1024 / low</td> $0.016</td> $0.005</td> -69%</td></tr> </tbody></table> 興味深いのは、gpt-image-2</code> では1024x1024より1536x1024のほうが安いという逆転が起きている点です。gpt-image-2</code> は連続的なサイズ指定とトークンベースの課金に振り切ったため、画素数と価格の関係が必ずしも単調ではなくなりました。これは料金表というよりトークン課金の写像として読むべきもので、サイズによる単純な大小比較は通用しなくなっています。 絶対額で見ると、記事1本あたり$0.085ほどの削減です。年に50本書いても$4程度なので、コスト最適化自体が主目的にはなりません。ただし「安くなって性能が上がる」方向の更新であり、乗り換えを見送る理由はありません。 output_format=webp</code> のバグ</h2> 実装中に確認したところ、gpt-image-2</code> は output_format=webp</code> を指定しても、実際にはPNGデータを返してきます。レスポンスJSONには "output_format": "webp"</code> が含まれているものの、b64_json</code> をデコードすると先頭が 89 50 4E 47 0D 0A 1A 0A</code> のPNGシグネチャになっています。 同一パラメータを gpt-image-1</code> に渡した場合は正しくWebPが返るため、現時点では gpt-image-2</code> 固有の不具合と判断しています。 そのため、本記事で示すスクリプトではAPIレスポンスをPNGとして受け取り、内部で cwebp -q 80</code> によりWebPへ再エンコードしています。呼び出し側インターフェースは変更せず、最終的には1536x864のWebPファイルを取得できます。 OpenAI側で修正された場合は、output_format=webp</code> をそのまま利用し、内部変換ステップを削除する想定です。 ブログのパイプラインを乗り換える</h2> 私のブログではカバー画像を scripts/generate-cover.sh</code> からOpenAI Image APIを叩いて生成しています。これまでは gpt-image-1</code> から1536x1024のPNGを受け取り、cwebp -q 80</code> でWebPに変換して cover.webp</code> を作っていました。新モデルへの移行で、このパイプラインが得る恩恵は大きく2点あります。 画像精度の底上げ</dt> テキスト描画・構図・解像度がモデルレベルで改善するため、カバー画像の見栄えが直接良くなります。gpt-image-1</code> とのAPI互換性が高く、エンドポイント・認証・レスポンス形式(b64_json</code>)はそのまま使えるため、これだけなら MODEL</code> 変数を gpt-image-2</code> に書き換えれば享受できます。</dd> 画角の自由度</dt> 画角16:9で指定できるようになりました。gpt-image-2</code> のサイズパラメータは「16の倍数」「総画素数65万〜829万」「縦横比3:1〜1:3」を満たす任意の値を受け付けるため、1536x864のような正確な16:9に直接出力できます。旧モデルのプリセット制約から3:2(1536x1024)に妥協していた本ブログでは、記事一覧の見栄えとX(旧Twitter)・はてなブックマークなどのSNSカードプレビューの収まりが、ようやく現代のプラットフォームと噛み合うようになりました。</dd> </dl> リクエスト本体は次のようになりました。 SIZE="1536x864" MODEL="gpt-image-2" RESPONSE=$(curl -s \ https://api.openai.com/v1/images/generations \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -d "$(jq -n \ --arg model "$MODEL" \ --arg prompt "$PROMPT" \ --arg size "$SIZE" \ --arg quality "$QUALITY" \ '{model: $model, prompt: $prompt, n: 1, size: $size, quality: $quality}')")</code></pre> このスクリプトを呼び出している article-cover</code> スキル(Claude Code用のカスタムコマンド)の全体は次のとおりです。記事の特定からフロントマター確認までを4ステップで定義しており、gpt-image-2</code> への移行に際しての変更は不要でした。 --- description: Generate a cover image for an article using OpenAI gpt-image-2 API. Read article content, craft a prompt, generate 1536x864 (16:9) WebP image. --- # Article Cover Image Generation Generate a cover image (cover.webp) for an article using OpenAI gpt-image-2 API. ## Steps ### 1. Identify Target Article Ask the user which article to generate a cover image for. Read the article content to understand the theme and key topics. ### 2. Craft Image Prompt Based on the article content: - Identify the core theme and visual concepts - Craft a gpt-image-2 prompt that captures the article's essence - Show the prompt to the user for approval before generating ### 3. Generate Image Run `./scripts/generate-cover.sh`: ``` ./scripts/generate-cover.sh \ -p "<approved prompt>" \ -o content/blog/YYYY/MM/slug/cover.webp ``` The script defaults to 1536x864 (16:9), high quality, and WebP output. ### 4. Verify Frontmatter Ensure the article frontmatter has: ```toml [extra] local_image = "cover.webp" social_media_card = "ogp.webp" ```</code></pre> 本記事のカバー画像も、この新しいパイプラインで生成しました。 まとめ</h2> ChatGPT Images 2.0は、価格が下がり、解像度とアスペクト比の選択肢が広がった、素直なアップグレードでした。gpt-image-1</code> を呼んでいる既存コードであれば、model</code> を差し替えるだけで動き始めます。 連続的なサイズ指定や推論を伴う構図設計といった点は、定型的なカバー画像生成だけでなく、SNS向け縦長フォーマットや図解付き画像など、これまで複数モデルを使い分けていた領域も gpt-image-2</code> 1本に集約しうるポテンシャルを持ちます。エージェント型ワークフローからの呼び出しでも、複数枚の一貫した出力をシングルリクエストで得られる点が効いてきそうです。 しばらくこのパイプラインを運用してみて、生成品質や絵柄の傾向で気になる点、あるいは output_format=webp</code> まわりの挙動に変化があれば、別途取り上げます。 References</h2> OpenAI</a>.「Introducing ChatGPT Images 2.0」</li> OpenAI API Docs</a>.「GPT Image 1 Model」(価格比較用)</li> OpenAI API Pricing</a>.「OpenAI API Pricing」</li> TechCrunch</a>.「ChatGPT's new Images 2.0 model is surprisingly good at generating text」</li> The New Stack</a>.「With the launch of ChatGPT Images 2.0, OpenAI now 'thinks' before it draws」</li> </ul> </div> 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> 読了『闘うプログラマー』 2026-05-12T07:33:12+09:00 Table of Contents</summary> </details> 1980年代にMS-DOSでデスクトップパソコン市場を制し、WindowsでGUIのオペレーティング・システム(以降、「OS」と記載)も制しつつあったマイクロソフト社は、90年代、高性能コンピューター向けの「本物」のOS開発プロジェクトを立ち上げます。当時のマイクロソフト社の世界戦略を担ったOS「WindowsNT」です。そのプロジェクトに、当時DEC社のミニコン向けOS、VAX/VMSの開発者であった「伝説のプログラマー」David Neil Cutlerが招へいされました。 本書の概要</h2> 本書は、David Cutlerを中心とした開発物語です。 『闘うプログラマー』というタイトルから、David Cutler中心に描かれていると思って購入しました。冒頭は、彼がDEC社で担当していた新OSプロジェクト「Mica」が破棄され、1988年マイクロソフト社に移籍するシーンから描かれています。前半は彼がいかにWindowsNTプロジェクトを立ち上げたかが描かれていますが、中盤からはこのプロジェクトに参加したあらゆるレイヤーの開発者へと順次フォーカスが当てられ、エピソードが盛り込まれていきます。 全く新しいOSを、当時主流だったIntelのCPUだけでなく、まだ完成していないRISCにも対応させなければなりません。さらにDOSとの互換性、Win32系の旧来のWindowsとの互換性も維持する必要があったわけです。想像するだけでデスマーチな開発ですが、本書を読めば実際にデスマーチだったことが分かります。それでも当時は「Cutlerの元で新しいOSの開発が出来る」ことを栄誉だと考えるプログラマーが多くいたわけです。 Cutlerの伝記として読むと中途半端ですが、当時のWindowsNTの過酷な開発エピソードが盛り込まれている点は大変興味深く読めました。本書がWindowsNTの初版がリリースされた1993年に出版されたため、開発者たちのエピソードも生々しく、リアルな状況を伝えています。 「OSの時代」を背景に</h2> WindowsNTの開発が始まった1980年代後半から1990年代に掛けては、まさに「OSの時代」でした。当時は、ハードウェアやネットワークの環境が大きく変化した時代でもあります。 CPUは16ビットから32ビットに進化し、RISCという新しいアーキテクチャーも登場した</li> MacintoshがGUIを一般ユーザーに広めた結果、プリエンプティブなマルチタスクが一般レベルでも要求されるようになった</li> インターネットの普及により、モデムでのパソコン通信ではなく本格的なネットワーク機能が一般ユーザーでも必要となった</li> </ul> PCはMS-DOS上でWindows3.xが動いていましたが、16ビットアーキテクチャーを引きずっていました。IBMは「OS/2」という新しいOSをマイクロソフト社と共にリリースしていましたが、コンシューマーの世界では全く浸透していませんでした。Apple社はClassic Mac OSを何度も刷新しようとしていましたが、ことごとく失敗していました。 そんな中で開発されたWindowsNTは、その後Windows2000、WindowsXPとコンシューマー向けWindowsの核となり、最も成功したOSとなっていきました。 私自身、1995年頃に自宅のPCにWindowsNTを導入していました。とはいえ、当時実際に使っていたツールの大半はWindowsベースですらなく、DOSベースのものが中心だったように記憶しています。それでも「本物のOS」に触れられたこと自体はよいお勉強になりましたし、ファイルシステムのNTFSはFATに比べて信頼性が明らかに高く、家庭利用でもその差を実感できました。 米国でのプログラマーの地位</h2> 個人的に印象的だったのは、米国での「プログラマー」の地位です。WindowsNTの開発に参加していた開発者が、皆スタープログラマーという訳ではありませんでした。それでも多くの開発者はストックオプションで一財産を築き、西海岸に家を建てポルシェを購入してという経済的な成功を手に入れています。日本における「プログラマー」の扱いとは大違いです。 翻って日本では、多くのプログラマーがSIer (システムインテグレーター) を頂点とする多重下請け構造の中で受託開発に従事しています。給与水準は一般のサラリーマンと大きく変わらず、ストックオプションで一財産を築くケースは稀です。「35歳定年説」も語られるほどに、プログラマーを続けること自体、報われにくい構造でした。 この差の背景には、産業構造の違いが大きいのではないでしょうか。米国はマイクロソフト社のように自社プロダクトを開発・販売する事業会社が産業の主役で、その成功は株式を通じて開発者個人にも還元されます。一方、日本では事業会社がIT機能を外注する構造になっており、プロダクトの成功を開発者と分け合う仕組みもありません。経営層に技術者出身者が少ないことも、こうした地位の差を生む一因と感じます。 </a></div>闘うプログラマー新装版</a>posted with ヨメレバ</a></div></div>グレッグ・パスカル・ザカリー/山岡洋一日経BP 2009年07月 </div>楽天ブックス</a></div>Amazon</a></div>Kindle</a></div> </div></div></div></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>

技術文書用フォーマット AsciiDoc

CloudflareのAI対策見直しとAIエージェント対応度診断

メッセージングアプリの匿名性考察

GR IV Monochromeから始めるdarktable現像術

Macバックアップ戦略・改訂版

三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退

References</h2>

株式会社三菱UFJ銀行</a>. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）</li>
Coded Chords</a>. 「AWSからSMSにメッセージを送る」（2025年6月9日）</li> </ul> </div>

Amazon S3からCloudflare R2への移行

ChatGPT Images 2.0と、ブログのカバー画像パイプライン更新

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

読了『闘うプログラマー』

rcloneとS3ライフサイクルで作る個人データのコールドアーカイブ

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

Coded Chords - Tech

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

Coded Chords - Tech

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

技術文書用フォーマット AsciiDoc

MacへのAsciiDocの導入</h2> AsciiDocの処理系としてAsciiDoctorを使用します。</p>

CloudflareのAI対策見直しとAIエージェント対応度診断

メッセージングアプリの匿名性考察

References</h2>

GR IV Monochromeから始めるdarktable現像術

Macバックアップ戦略・改訂版

三菱UFJ銀行のPPAP廃止は、半歩前進で半歩後退

References</h2>

Amazon S3からCloudflare R2への移行

ChatGPT Images 2.0と、ブログのカバー画像パイプライン更新

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

「OSの時代」を背景に</h2> WindowsNTの開発が始まった1980年代後半から1990年代に掛けては、まさに「OSの時代」でした。当時は、ハードウェアやネットワークの環境が大きく変化した時代でもあります。</p>

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

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

References</h2>

株式会社三菱UFJ銀行</a>. 「当行からの添付ファイル送信方法の変更に関するご案内」（2026年6月8日）</li>
Coded Chords</a>. 「AWSからSMSにメッセージを送る」（2025年6月9日）</li> </ul> </div>

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