PinterestがAWSクラウドサービスに2031年まで計画40億ドルをコミットする発表は、AWSのAIインフラ需要を読むうえで目立つ材料です。ただし、利用者や導入企業にとって大事なのは、金額そのものよりも、AWS Trainium、AWS Graviton、Amazon EKS、AWS Neuronを使うAI基盤がどの条件で現実的になるかです。
Amazon公式ニュースとPinterest IRは、今回の契約をPinterest史上最大のインフラコミットメントとして説明しています。ReutersやThe Information系の報道でも同日中に話題化しており、需要シグナルとしては強い一方、この記事では事実認定をAmazon、Pinterest、AWSの一次情報に限定します。
Amazon Watch JapanはAmazonおよび関係会社とは非提携です。この記事は製品・サービス理解のための整理であり、AMZNやPINSの売買を勧める投資助言ではありません。
3行まとめ
このテーマをもう少し広げて見るなら、Amazon EC2 M9g/M9gdが一般提供開始：Graviton5とNitro Isolation Engineで移行前に確認すべきこと と AWS FinOps Agentプレビューとは：異常コスト調査をAIエージェント化する前に確認すべきこと も合わせて確認してください。Pinterest発表で出てくるGraviton採用を、次世代Graviton基盤の移行確認ポイントとつなげて読めるため。
PinterestはAWSクラウドサービスへ2031年まで計画40億ドルをコミットしました。即時売上や一括支出とは分けて読みます。
Trainiumはモデル実行、Gravitonは汎用コンピュート、EKSはKubernetesベースの運用基盤として役割が異なります。
対象ワークロード、Neuron対応、Arm移行、EKS運用、測定方法、フォールバック設計を先に確認します。
大口契約の見出しを入口にしつつ、実務では技術ごとの役割と戻し方まで見る必要があります。
- Pinterestは2026年6月4日、AWSクラウドサービスへ2031年まで計画40億ドルをコミットする拡大協業を発表しました。公式発表では、Pinterest史上最大のインフラコミットメントとされています。
- 発表の技術的な焦点は、Trainiumで大規模言語モデルや視覚言語モデルを支え、Gravitonで汎用コンピュートを広げ、EKSでKubernetesベースの基盤近代化を進める点です。
- 自社導入で見るべきなのは、チップ名や契約金額ではなく、対象ワークロード、AWS Neuron対応、Arm移行、EKS運用、計測方法、フォールバック設計です。
PinterestのAWS 40億ドル契約で公式に確認できること
- 2010年から
PinterestとAWSの協業は2010年から続いており、今回の発表は既存基盤の拡大として読むのが自然です。
- 2026年6月4日
PinterestはAWSクラウドサービスへ2031年まで計画40億ドルをコミットする拡大協業を発表しました。
- 目的
AIロードマップ、検索、ショッピング体験、ビジュアル検索ディスカバリー基盤の近代化が発表の中心です。
- 注意点
売上認識、支出タイミング、四半期業績への影響は、公式発表だけでは断定できません。
40億ドルは2031年までのクラウドサービス計画コミットメントとして扱います。
今回の発表でまず押さえるべき事実は、金額、期間、当事者、対象技術、目的です。Amazon公式ニュースは、PinterestがAWSクラウドサービスへ2031年まで計画40億ドルをコミットし、AWS TrainiumとGravitonを使ってAIモデルを大規模に学習・実行すると説明しています。Pinterest IRも同じく、AWSをPreferred Cloud Services Providerと位置づけ、同社史上最大のインフラコミットメントだと発表しています。
ここで注意したいのは、40億ドルをAWSの即時売上やPinterestの一括支出として読まないことです。一次情報の表現は、2031年までのクラウドサービスに対する計画コミットメントです。売上認識、支出タイミング、四半期業績への影響は、今回の公式発表だけでは断定できません。
2010年から続くAWSとの関係が土台
根拠
PinterestとAWSの関係は、今回突然始まったものではありません。公式発表では、両社の協業は2010年から続いており、Pinterestの大規模データレイク最適化にも触れられています。つまり、今回のニュースは「新しいAI用途だけの単発契約」ではなく、既存のクラウド基盤、検索、推薦、データ処理、AIモデル運用をさらに広げる話として読むほうが自然です。
Pinterest側の狙いも、単にインフラを増やすことではありません。Pinterest IRは、AIロードマップの加速、より応答性の高い検索・ショッピング体験、グローバルなビジュアル検索ディスカバリープラットフォームの近代化を目的として挙げています。ユーザー体験としては、画像からアイデアを探す、商品を見つける、好みに合わせた提案を受ける、といった日常的な体験の裏側にある基盤投資です。
金額よりも「何を支える基盤か」を見る
評価基準
市場ニュースでは40億ドルという数字が目立ちます。しかし、Amazon Watch Japanの読者にとって重要なのは、AWSのAIインフラがどの種類のワークロードに使われているのかです。Pinterestの発表では、Trainium、Graviton、EKSがそれぞれ異なるレイヤーに出てきます。
Trainiumは、AIモデルの学習や推論を支えるアクセラレーテッドコンピュートの文脈です。Gravitonは、Armベースの汎用CPUとして、AIの周辺にあるアプリケーション、API、データ処理、マイクロサービスを支えます。EKSは、従来のEC2ベース環境からKubernetesベースのアーキテクチャへ移る近代化の文脈です。これらを一つの「AIチップ採用」としてまとめてしまうと、導入判断を誤ります。
AWSや生成AIクラウドの流れを追う場合は、公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/category/aws-ai-cloud/" rel="noopener">AWS AI Cloudカテゴリ</a>もあわせて見ると、Bedrock、SageMaker、Trainium、AIエージェント基盤の更新をつなげて追いやすくなります。
PinterestのAI基盤でTrainium、Graviton、EKSが担う役割
Pinterest固有の成果として断定できる範囲と、AWS製品の一般説明は分けて読む必要があります。
Pinterestは、視覚検索、パーソナライズ、推薦、ショッピング体験にAIを使ってきた企業です。公式発表では、同社のTaste Graph、従来の埋め込みベース検索からtransformer-based generative modelsへの進化、Pinterest Assistantのようなマルチターンの会話型ディスカバリーにも触れています。
ここで出てくるAIワークロードは一種類ではありません。画像やテキストを扱う視覚言語モデル、ユーザーの好みを捉える推薦モデル、検索結果を返すオンライン推論、モデル更新のための学習、広告やショッピング体験を支える周辺システムが混在します。だからこそ、Trainium、Graviton、EKSをレイヤーごとに分けて読む必要があります。
TrainiumはAIモデル実行の選択肢
根拠
Pinterest IRは、AWS Trainiumを使って、大規模言語モデルや視覚言語モデルをホストし実行する計画を説明しています。AWSのTrainium製品ページでは、Trainiumを学習と推論の両方を対象にしたAIアクセラレータ群として説明しています。
ただし、今回のPinterest発表は、どのTrainium世代をどのモデルに使うかまでは明示していません。AWSの製品ページにはTrainium1、Trainium2、Trainium3の説明がありますが、それをそのままPinterest固有の採用品として断定するのは避けます。記事や社内メモで扱うなら、「AWS Trainiumの一般的な製品説明」と「Pinterestが公式に発表した利用計画」を分けるべきです。
GravitonはAIチップではなく汎用CPU基盤
注意点
Pinterestの発表では、Gravitonがすでに同社の計算基盤のおよそ3分の1を支えているとされています。これは、Gravitonが大規模な実運用基盤に入り込んでいる強いシグナルです。
一方で、GravitonはTrainiumのようなAIアクセラレータではありません。AWSのGraviton製品ページは、GravitonをAmazon EC2上のクラウドワークロード向けに価格性能を高めるプロセッサファミリーとして説明しています。アプリケーションサーバー、マイクロサービス、オープンソースデータベース、HPCなど、幅広い汎用ワークロードが対象です。
AIサービスでは、モデル本体だけがコストや体験を決めるわけではありません。検索API、認証、広告配信、データパイプライン、Feature Store、ログ処理、評価ジョブなど、周辺の汎用コンピュートが巨大になります。PinterestがGravitonを広げる意味は、AIの周辺にあるサービス全体の効率を上げる文脈で見ると理解しやすくなります。
EKSは運用単位を変える
条件
Amazon公式ニュースとPinterest IRは、Pinterestが従来のEC2ベース環境から、Amazon EKS上のKubernetesベースアーキテクチャへ移る近代化を続けると説明しています。ここも「EKS移行が完了した」と読まないほうが安全です。一次情報上は、継続する近代化の取り組みです。
Amazon EKSは、Kubernetesアプリケーションを構築、実行、スケールするためのマネージドサービスです。AWSのEKS製品ページは、生成AIアプリケーションや分散学習、推論デプロイの運用にも触れています。Pinterestのような規模では、モデル、検索、推薦、データ処理、広告、社内開発基盤を、コンテナ単位で管理する意味が大きくなります。
Trainium採用で確認すべきこと
- 1モデルを分ける
LLM、視覚言語モデル、推薦モデル、埋め込みモデル、オンライン推論、バッチ推論を分けて扱います。
- 2Neuron対応を見る
利用フレームワーク、演算、コンパイル、ランタイム、プロファイリングが実運用に耐えるかを確認します。
- 3同じ条件で測る
既存GPU環境と、レイテンシ、スループット、単位コスト、運用工数を同じ表で比較します。
- 4戻し方を決める
性能や互換性に問題が出た場合に、GPUや別構成へ戻すフォールバックを先に用意します。
Trainiumの採用判断は、チップ単体ではなくNeuronを含む開発・運用スタック全体で行います。
Trainiumの導入判断で最初に見るべきなのは、「AWS独自チップだから安くなるか」ではありません。対象モデルがどの種類か、どのフレームワークを使うか、AWS Neuronで動かせるか、測定とデバッグができるかです。
AWS Trainiumの製品ページは、Trainiumを高性能でコスト効率のよいAI at scale向けのアクセラレータとして位置づけています。Neuron SDKは、TrainiumやInferentia向けに、学習・推論、コンパイル、ランタイム、プロファイリング、デバッグなどを支える開発スタックです。導入企業は、チップそのものだけでなく、Neuronまで含めて評価する必要があります。
どのモデルを載せるのかを先に分ける
確認項目
Pinterestのような視覚検索サービスでも、AIモデルは一枚岩ではありません。大規模言語モデル、視覚言語モデル、画像埋め込み、推薦モデル、広告最適化モデル、ランキングモデル、バッチ推論、オンライン推論では、求める性能が違います。
たとえばオンライン推論では、p95やp99のレイテンシ、ピーク時のスループット、再試行、障害時の退避先を見ます。学習では、分散実行、チェックポイント、データ供給、ネットワーク、ジョブ失敗時の再開しやすさが軸になります。バッチ推論では、時間あたり処理量と単位コスト、ジョブキュー、結果検証が中心です。
Pinterestの発表を見て自社でTrainiumを検討する場合、最初に書くべきチェックリストは次のようなものです。
- 対象モデルはLLM、視覚言語モデル、推薦モデル、埋め込みモデルのどれか。
- 推論なのか、学習なのか、ファインチューニングなのか。
- 既存GPU環境と比較する測定条件はそろっているか。
- 精度劣化を許容できる範囲は決まっているか。
- レイテンシ、スループット、単位コスト、運用工数を同じ表で測るか。
Neuron対応は採用判断の中心に置く
評価基準
Trainiumを検討するとき、AWS Neuronを避けて通ることはできません。Neuronは、AWSのAIチップ向けの開発スタックで、PyTorch、JAX、Hugging Face、vLLMなど周辺の対応状況を確認する入口になります。
既存モデルをTrainiumに移す場合、「コードを変えずに動くか」だけでは足りません。コンパイルにかかる時間、プロファイルでボトルネックを追えるか、モデルの一部だけが未対応にならないか、デプロイ後の監視で原因を切り分けられるかを見ます。AI基盤では、動いた瞬間よりも、遅いとき、落ちたとき、精度が下がったときに調べられるかが本番判断を左右します。
公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-22-sagemaker-ai-multiturn-rl-agents/" rel="noopener">Amazon SageMaker AIのマルチターンRL記事</a>でも触れたように、モデルのカスタマイズや評価では、最終回答だけでなくプロセスや環境も評価対象になります。Trainiumの導入でも、モデル単体のベンチマークだけでなく、評価、監視、再現性を含めた基盤として見ます。
世代や性能値をPinterest採用として断定しない
注意点
AWSのTrainium製品ページには、Trainium1、Trainium2、Trainium3の世代別説明が載っています。たとえばTrainium2やTrainium3の性能、UltraServers、NeuronLink、HBM、FP8などの説明は、AIインフラを検討するうえで参考になります。
しかし、Pinterest発表は特定世代、具体的なインスタンス、モデルごとのベンチマークを公開していません。したがって、「PinterestがTrainium3を使っている」「GPUから何割置き換える」「推論コストが何割下がる」といった表現は、一次情報だけでは書けません。公式発表で確認できるのは、PinterestがAWS Trainiumを活用し、LLMや視覚言語モデルをホスト・実行する計画があるという範囲です。
Graviton拡大で確認すべきこと
ネイティブ拡張、古いライブラリ、x86専用バイナリがarm64に対応しているかを確認します。
Dockerイメージをmulti-archでビルドし、テスト環境と本番環境で同じアーキテクチャを再現します。
監視、ログ、セキュリティエージェント、CI/CDがarm64で動くかを確認します。
カナリア移行で影響を限定し、問題が出たときにx86へ戻せる手順を持ちます。
Pinterestの計算基盤のおよそ3分の1という数字は、AI処理の比率ではなく導入段階を示す情報として読みます。
Gravitonを検討するときは、AIモデルではなく、アプリケーションと運用基盤の移行として見るほうが実務に近いです。Pinterestがすでに計算基盤のおよそ3分の1でGravitonを使っているという発表は、GravitonがAI周辺の大規模サービスにも入り込んでいることを示しています。
AWSのGraviton製品ページは、GravitonベースのEC2インスタンスが幅広いワークロードで価格性能を提供し、EC2以外の一部マネージドサービスにも使われていると説明しています。ただし、自社で移行する場合は、ページ上の一般的な価格性能だけを見て決めないほうが安全です。
Arm移行は依存関係の確認から始める
確認項目
GravitonはArmベースです。移行でつまずきやすいのは、CPU性能そのものよりも、アプリケーションの依存関係です。ネイティブ拡張、古いライブラリ、x86専用バイナリ、Dockerイメージ、CI/CD、監視エージェント、セキュリティツールがarm64に対応しているかを確認します。
特に生成AIや検索基盤では、Python、Java、Go、Node.js、Rust、C++の混在が珍しくありません。検索サービスや広告配信の一部だけがarm64に対応していない場合、クラスタ全体の設計が複雑になります。Gravitonを広げる前に、ワークロードごとに次のような項目を確認します。
- コンテナイメージがmulti-archでビルドできるか。
- 依存パッケージにx86専用バイナリが残っていないか。
- テスト環境と本番環境で同じアーキテクチャを再現できるか。
- 監視、ログ、セキュリティエージェントがarm64で動くか。
- x86へ戻すロールバック手順があるか。
約3分の1という数字は比率ではなく導入段階として読む
根拠
PinterestがGravitonをすでに計算基盤のおよそ3分の1で使っているという情報は興味深いものです。ただし、そこから「残りもすべてGravitonへ移る」「AI処理の3分の1がGravitonで動いている」とは言えません。
読むべきなのは、Pinterestのような大規模サービスが、Armベースの汎用CPUを本番の相当な割合で採用しているという導入段階です。これは、Gravitonが単なる検証用ではなく、大規模な実運用の選択肢になっていることを示します。一方で、自社のシステムで同じ比率が適切かどうかは、依存ライブラリ、負荷特性、チームの運用経験、コスト配賦の仕組みによって変わります。
EKSやマネージドサービスとの組み合わせで効く
評価基準
Gravitonの効果は、単体インスタンスのベンチマークだけでは見えません。EKSでノードグループを分け、Armとx86を混在させ、ワークロードごとにスケジューリングする場合、クラスタ全体の設計が重要になります。
たとえば、検索APIはGravitonノードに寄せるが、特定のMLジョブはGPUやTrainium系のノードに寄せる。ログ処理や内部APIはGravitonへ移し、互換性に不安があるコンポーネントはx86に残す。こうした段階移行ができるかどうかは、EKSやコンテナ基盤の成熟度に左右されます。
EKS移行が意味する運用設計
- 1ワークロードを分ける
オンライン推論、バッチ推論、学習ジョブ、検索、広告配信などを性質ごとに分けます。
- 2ノードを設計する
アクセラレータ付きノード、Gravitonノード、x86ノード、汎用ノードの配置を決めます。
- 3スケールを制御する
スケジューリング、オートスケーリング、イメージ配布、ネットワークを運用設計に含めます。
- 4見える状態にする
メトリクス、ログ、コストタグ、障害時の退避先をそろえ、遅さや失敗の原因を追えるようにします。
Kubernetesに移るだけで課題が消えるわけではなく、観測性と責任境界を設計することが重要です。
Pinterestの発表でEKSが出てくる点は、AI基盤を考えるうえで見逃せません。AIモデルの話題ではチップやモデル名に注目が集まりがちですが、本番のAIサービスでは、モデルを動かす土台、デプロイ、監視、スケール、障害対応が同じくらい重くなります。
EKSは、Kubernetesの抽象化を使ってワークロードを管理します。EC2インスタンス単位でサーバーを見ていた運用から、Pod、Node、Cluster、Namespace、Job、Service、Autoscalingといった単位で運用を見る形に変わります。
AI/MLワークロードではスケジューリングと観測性が重要
運用条件
生成AIや視覚検索の基盤では、ワークロードの性質が大きく異なります。オンライン推論は低レイテンシを求められ、バッチ推論は処理量が中心です。学習ジョブは長時間走るため、途中失敗時の再開やチェックポイント管理が欠かせません。検索や広告配信では、モデル以外のサービスも大量に動きます。
EKSでこうしたワークロードを扱う場合、アクセラレータ付きノード、Gravitonノード、x86ノード、通常の汎用ノードをどう分けるかが問題になります。スケジューリング、オートスケーリング、メトリクス、ログ、イメージ配布、ネットワーク、コストタグ、障害時の退避先まで、運用設計として見ます。
公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/" rel="noopener">Bedrock MantleとCloudWatchメトリクスの記事</a>でも、本番AI基盤では「使える」だけでなく「見える」ことが重要だと整理しました。EKS移行でも同じです。モデルやチップの性能が高くても、何が遅いのか、どこで失敗しているのか、単位コストがどこで膨らむのかを追えなければ、本番では扱いにくくなります。
EKS化だけではAI基盤の課題は解決しない
注意点
Kubernetesは強力ですが、万能ではありません。EKSに移っただけで、モデル品質、データパイプライン、セキュリティ、ガバナンス、FinOps、開発者体験が自動的に良くなるわけではありません。
Pinterestのような規模では、標準化されたコンテナ基盤が開発速度や運用信頼性に効く可能性があります。一方、小さなチームでは、Kubernetes運用そのものが負担になる場合もあります。EKSを導入するなら、誰がクラスタを運用するのか、どのメトリクスを見るのか、モデルチームとプラットフォームチームの責任境界をどう分けるのかを先に決めるべきです。
自社導入判断に落とすチェックリスト
公式の性能値は入口として使い、最終判断は自社のモデル、データ、リージョン、運用条件で測ります。
Pinterestのニュースを自社のAWS導入判断に変換するなら、Trainium、Graviton、EKSをまとめて「最新AIインフラ」として扱わないことが出発点です。それぞれの効き方は違います。
Trainiumは、モデルの学習・推論でアクセラレータを使う判断です。Gravitonは、汎用コンピュートをArmへ移す判断です。EKSは、アプリケーションやAIワークロードの運用単位をKubernetesへ寄せる判断です。どれもAWSのAI基盤を支えますが、確認する人、測る指標、失敗時の戻し方が違います。
POC前に見るのは技術名称ではなくワークロード
評価基準
POCの前に、対象ワークロードを分けます。モデル学習、オンライン推論、バッチ推論、検索API、広告配信、データ処理、マイクロサービスでは、採るべき選択肢が違います。
Trainiumを試すなら、対象モデル、Neuron対応、既存GPU環境との比較条件、プロファイリング、フォールバックを決めます。Gravitonを試すなら、arm64対応、依存ライブラリ、multi-archイメージ、カナリア移行、x86への戻し方を決めます。EKSを見直すなら、ノード構成、スケジューリング、観測性、コスト配賦、運用責任を決めます。
POC中は公式の性能値より自社条件で測る
測定項目
AWS製品ページの性能値は、検討の入口として有用です。ただし、最終判断は自社のモデル、データ、リージョン、インスタンス、ネットワーク、監視条件で測る必要があります。
測るべき指標は、p50、p95、p99レイテンシ、スループット、失敗率、コールドスタート、リトライ、単位コスト、デプロイ時間、デバッグにかかる時間です。Trainiumであれば、コンパイルやプロファイルにかかる作業時間も含めます。Gravitonであれば、移行作業と依存関係の修正も含めます。EKSであれば、クラスタ運用と障害時の調査時間も含めます。
本番前はフォールバックと責任境界を決める
注意点
アクセラレータやArm移行は、良い結果が出たときより、悪い結果が出たときの戻し方が問われます。TrainiumからGPUへ戻す、Gravitonからx86へ戻す、EKS上でノード種別を切り替える、特定モデルだけ別基盤に逃がす、といった選択肢を先に用意します。
また、誰が何を見るのかも決めます。モデルチームは精度とレイテンシを見る。プラットフォームチームはクラスタ、ノード、コスト、セキュリティを見る。アプリケーションチームはユーザー体験とAPIのSLOを見る。FinOps担当は単位コストとピーク負荷を見る。責任境界が曖昧なまま本番に進むと、チップやクラウドサービスの良し悪し以前に、運用が詰まります。
この記事の結論として置く判断表
AWSのAI基盤を一つのサービス名だけで判断せず、技術ごとの成功条件と未確定事項を分けて読むことが重要です。
PinterestのAWS 40億ドル契約は、AWSのAI基盤需要を示す大きなシグナルです。特に、Trainium、Graviton、EKSが同じ発表に並んだことは、AIモデル本体、汎用コンピュート、コンテナ運用を一体で見なければならないことを示しています。
一方で、今回の発表だけでは、Pinterestが使うTrainiumの世代、モデル別の性能、コスト削減率、移行完了時期は分かりません。そこを推測で埋めるより、公式に確認できること、まだ断定しないこと、自社で確認することを分けるほうが実務的です。
| 観点 | 今回公式に確認できること | まだ断定しないこと | 自社で確認すること |
|---|---|---|---|
| 契約 | PinterestがAWSクラウドサービスへ2031年まで計画40億ドルをコミット | AWSの即時売上や四半期影響 | 契約ニュースを自社調達判断にどう反映するか |
| Trainium | LLMや視覚言語モデルをホスト・実行する計画 | 世代、インスタンス、Pinterest固有ベンチマーク | Neuron対応、モデル互換性、推論・学習性能、フォールバック |
| Graviton | Pinterestの計算基盤のおよそ3分の1を支えている | 残りの構成、今後の比率、AIモデル本体の実行比率 | arm64対応、依存関係、CI/CD、カナリア移行 |
| EKS | EC2ベース環境からKubernetesベース基盤への近代化を継続 | 移行完了、すべてのワークロードの配置 | ノード設計、観測性、コスト配賦、運用責任 |
今回のニュースから得られる実務上の結論は、AWSのAI基盤を一つのサービス名だけで判断しないことです。Trainiumを試すチーム、Gravitonを広げるチーム、EKS運用を見直すチームでは、成功条件が違います。大口契約の見出しを入口にしつつ、自社ワークロードの測定に戻るのが安全な読み方です。
Amazon Watch Japanでは、Amazon/AWSの公式発表、製品・サービス更新、噂確認、月次まとめの更新を非提携の立場で追っています。AWS AIインフラの発表を続けて追う場合は、<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>から更新通知を受け取れます。
次に読むなら
参照した主な情報源
- Pinterest signs $4 billion AWS deal to scale AI for 600 million users – About Amazon（確認日: 2026年6月5日）
https://www.aboutamazon.com/news/aws/pinterest-aws-4-billion-ai-infrastructure-deal
- Pinterest Works with AWS to Power Next Chapter of AI-Driven Visual Search Discovery – Pinterest IR（確認日: 2026年6月5日）
https://investor.pinterestinc.com/news-and-events/press-releases/press-releases-details/2026/Pinterest-Works-with-AWS-to-Power-Next-Chapter-of-AI-Driven-Visual-Search-Discovery/default.aspx
- AWS Trainium – AWS（確認日: 2026年6月5日）
https://aws.amazon.com/ai/machine-learning/trainium/
- AWS Graviton Processors – AWS（確認日: 2026年6月5日）
https://aws.amazon.com/ec2/graviton/
- AWS Neuron Documentation（確認日: 2026年6月5日）
https://awsdocs-neuron.readthedocs-hosted.com/en/latest/
- Amazon Elastic Kubernetes Service – AWS（確認日: 2026年6月5日）
https://aws.amazon.com/eks/
更新履歴: 2026年6月5日、Amazon公式ニュース、Pinterest IR、AWS Trainium、AWS Graviton、AWS Neuron Documentation、Amazon EKSを確認して初稿を作成しました。ReutersやThe Information系の報道は同日中の需要シグナルとしてのみ扱い、本文の事実認定は一次情報に限定しています。