#cloud

What surprised me here is not the “run Claude Code remotely” part. That feels obvious. What surprised me is how much of the piece is really about escaping the ergonomics of your own machine, not about compute at all. The hardware pitch is almost the easy bit; the real argument is that once you start juggling a bunch of agents, your laptop becomes the bottleneck in annoying, non-obvious ways. That rings true. I’m less convinced by the confident drift into “just use this remote setup and it solves

Alphabetが、AI infrastructure と compute を拡張するための80 billionドル規模の equity capital raise を提案した ざっくり言うと、AIを動かすためのサーバー、データセンター、計算資源をさらに増やすための大型資金調達 「equity capital raise」は、株式を通じて資金を集めることを指す。借金ではなく、資本を増やすイメージ 発表日は2026年6月1日 かなり大きな金額で、AlphabetがAI競争をかなり本気で取りにいっていることが伝わる Alphabetの投資家向け発表によると、同社はAI infrastructure と compute を拡大するために、80 billionドルの equity capital raise を提案した。 ここで少し言葉をかみくだくと、 AI infrastructure AIを支える土台のこと。たとえばデータセンター、GPUなどの計算用ハードウェア、電力、通信設備など。 compute 計算能力のこと。AIは学習にも推論

元記事は、Reddit上で「巨大なGPUを深く考えずに借りてみたら、なんだかすごいことをやっている気分になった」という趣旨の投稿です。 GPUは、AIの学習や画像生成、重い計算を高速にこなすための重要な計算資源です。 こうしたGPUをクラウドで借りると、手元のPCでは到底無理な規模の処理ができる一方、コスト感覚がかなり大事になります。 「とりあえず使ってみる」体験は面白いですが、同時にクラウド時代の計算資源の重みを実感させます。 投稿の雰囲気からは、技術の興奮と少しの怖さが同居している感じが伝わってきます。 元記事は、Redditの`r/artificial`に投稿されたもので、タイトルの雰囲気からしてかなり“生っぽい”です。内容をざっくり言うと、大きなGPUを深く考えずに借りてみたら、まるで自分がすごい計算を動かしている人になった気分だった、という話です。 まず、GPUって何かを簡単に言うと、もともとはゲームや画像処理向けに作られた、超並列計算が得意な部品です。今ではAIの世界で大活躍していて、特に大きなモデルの学習や推論（学習済みモデルを使って答えを出すこと）には欠

AnthropicがSeries Hで65億ドルを調達し、post-money valuationは9650億ドルに到達 主導したのはAltimeter Capital、Dragoneer、Greenoaks、Sequoia Capital 直近のrun-rate revenueは470億ドル超に到達したと発表 調達資金は、安全性研究・解釈可能性研究・計算資源の拡張に使う方針 すでにAmazon、Google、Broadcom、SpaceXなどと大規模な計算資源契約を結んでおり、AIインフラ競争のスケール感がかなりすごい Anthropicが、またもや巨大な資金調達を発表しました。 今回の金額は65億ドル。日本円に直すと為替次第ですが、ざっくり1兆円級の世界です。いや、もはや「資金調達」という言葉の感覚がだいぶバグってきます。 しかも評価額は9650億ドル。ほぼ1兆ドル級です。 スタートアップの延長線上にあるというより、もう「世界のAI基盤を押さえる巨大企業」になりつつある、という印象が強いですね。 Ant

AI agent は「人間の代わりに動くソフトウェア」だが、従来のセキュリティは人間を前提に作られている AI agent は数が一気に増え、記事では「人間の144倍」と表現されている 問題の本質は、AI agent が「誰なのか」をどう証明し、何をしてよいかをどう制御するかにある 従来のIAM（Identity and Access Management: 誰に何を許すかを管理する仕組み）だけでは不十分 その解決策として、記事は Agent IAM という考え方を押し出している The New Stack のこの記事は、AI agent の急増によってセキュリティの前提が崩れつつある、という話です。 タイトルの「identity crisis」は、直訳すると「アイデンティティの危機」。つまり、「お前は誰だ？」をうまく扱えなくなっている、という意味合いですね。なかなかうまい言い方だと思います。 AI agent というのは、単なるチャットボットではありません。 人の指示を受けて、ツールを使い、APIを叩き、ファイルを読み書きし、場合によっては他のサービスまで操作する“自律的なソフトウェ

中国が、海中に設置したデータセンターを商用運用開始したと報じられた 場所は上海の臨港新片区付近、海面下約35メートル 約2,000台のサーバーを収容し、AIや5G、データ注釈などに使う 電力は沖合の風力発電が一部を担い、冷却は海水の自然な低温を利用 PUEは1.15未満とされ、一般的なデータセンターより効率がかなり高い ただし、腐食・耐圧・保守の難しさなど、課題も大きい AIの普及で、データセンターはどんどん“電気食い”になっています。 ChatGPTのようなAIサービス、5G、動画配信、クラウド計算――こうした処理を支えるサーバーは、ものすごい熱を出します。 そして、熱を冷やすのにもまた電気が要る。ここがデータセンター運営の悩みどころです。 冷やすための空調設備やチラー（巨大な冷却装置）がフル稼働すると、今度は電力消費が増える。まさに「計算するために電気を使い、冷やすためにも電気を使う」わけです。 そこで中国が出してきたのが、“いっそ海に沈めて、海そのものを冷却装置にしてしまおう”という発想。 正直、かなり大胆です。でも

著者はFAANG企業を辞め、独立研究者になるために 6枚の RTX 6000 Ada を積んだGPUサーバー「grumbl」を自作した 価格は 約4.8万ドル。かなり高いが、「仕事を早く進められるなら投資になる」という発想で購入 住んでいるのがアパートだったため、電源制約が大きな壁になり、2つの電源を別回路のコンセントに分ける構成にした 自前サーバーの利用率は 平均76%、2025年以降に絞ると 85% 2026/3/13時点の試算では、クラウドで同等の計算資源を借りるより 約1.7万ドル安かった ただし、自分の作業時間・構築や保守の手間はコスト計算に入っていない 結論としては「節約のため」よりも、面白いものを作るための投資だった、というのが著者の本音 GPUサーバーを4.8万ドルで買う、という時点でだいぶ普通ではありません。 でもこの記事の面白さは「豪遊しました」ではなく、自分の働き方そのものを変えた結果として、その投資が合理的だったのかを、かなり真面目に検証しているところです。 しかも著者は「FAANGの仕事を

Infomaniakは、議決権の過半数をスイスの公益財団に移した これで会社は買収されにくくなり、独立性が長期的に守られる 財団は会社を動かすのではなく、理念を守る番人として機能する 会社の中核には、privacy・digital sovereignty・環境配慮・地域性といった価値観がある 単なる「いい話」ではなく、会社の支配構造そのものを変えたのが面白い Infomaniakという会社は、クラウドやWebサービスを提供するスイス企業です。 今回の発表でかなり印象的なのは、単に「独立を大事にしています」と言っているのではなく、会社の支配構造そのものを、独立が崩れにくい形に作り替えたことです。 要するに、創業者や投資家の気分次第で会社の方向が変わる、というありがちな話から距離を置いたわけです。 こういう話、正直かなり好きです。理念を語るだけなら誰でもできますが、会社法や議決権の設計まで踏み込むのは本気度が違うと思います。 Infomaniakは2026年5月13日、創業者のBoris Siegenthaler氏が、**議決権の過半

RailwayがGoogle Cloud Platform（GCP）のアカウント停止に巻き込まれ、約8時間の大規模障害が発生した 影響はDashboard、API、ログイン、ビルド、デプロイに及び、最終的に全リージョンのワークロードが到達不能になった 直接の原因はGCP側の誤った自動処理だったが、Railway側にも「単一障害点」を作ってしまう構成上の課題があった キャッシュが効いていた間は一部の環境が生きていたが、route cacheの期限切れで障害が全体へ連鎖した Railwayは今後、Google Cloudへの依存を縮める、true mesh化する、database shardをAWSとMetalへ広げるといった対策を進める 個人的には、これは「クラウドは便利だが、依存の置き方を雑にすると一発で痛い目を見る」という、かなり教訓の大きい事故だと思う Railwayが公開したIncident Reportによると、2026年5月19日、同社は**Google Cloudの誤った処理により、production account

月額 `$340` だったインフラ費用を、`$136` まで削減した やったことは「コードの大改修」ではなく、設定と運用の見直し 具体策は、インスタンスの適正化、使っていないDBの削除、静的ファイルの移動、クエリ改善、予約課金の活用 いちばん大事なのは、“なんとなく不安だから大きめ” をやめて、実測すること こういう改善は派手じゃないけれど、実際にはかなり効く。個人的にも、ここをサボるとクラウド費用は静かに膨らむと思う 元記事の筆者は、約 5 万 MAU（Monthly Active Users = 月間アクティブユーザー数）のアプリを運用しながら、クラウド費用を 月額 $340 から $136 に削減したそうです。 削減率はなんと 60%。しかも、アプリのコードを大きく書き換えずに、です。 これ、かなり面白い話です。 「性能改善 = 開発の頑張り」と思いがちですが、実際は “どんなインフラを、どう使っているか” のほうがコストに直結することが多いんですよね。クラウドは便利な反面、放っておくと“使ってないのに課金される箱”が増えが