Talk Lowy(jp)

宇宙に進出するエッジAI：RISC-V革命とソフトウェア定義衛星の時代 2026年現在、人工知能（AI）と宇宙技術の融合は、単なる技術的な模索の段階を超えて、 実際の軌道上での運用および産業的な成熟段階 へと突入しました。最近のGoogleトレンド（Google Trends）でも、AIと宇宙産業の融合に関する検索ボリュームが持続的に上昇しており、単なる宇宙ロケットの打ち上げ競争を超えて、**「軌道コンピューティング（Orbital Computing）」**というソフトウェアとハードウェアアーキテクチャの革新に関心が移っていることが示されています。 過去の人工衛星が、地上から送られた命令を単に中継するか、あるいは生のデータをそのまま転送する「ベントパイプ（Bent-pipe）」の役割にとどまっていたとすれば、現在の衛星は宇宙空間で自ら判断し、データを処理する エッジAIシステム へと生まれ変わりつつあります。 今回の記事では、この宇宙エッジAI革命を牽引する RISC-Vハードウェアアーキテクチャ と、**ソフトウェア定義衛星（Software-Defined Satellites）**のトレンド、そしてグローバルな覇権争いの中で得られる技術的なインサイトについて深く掘り下げていきます。 1. 宇宙データの爆発と地上通信のボトルネック 人工衛星に搭載されるセンサーや高解像度カメラ、合成開口レーダー（SAR）などが飛躍的に進化することで、宇宙で生成されるデータ量は指数関数的に増加しています。しかし、それを地上局に転送するための無線通信帯域幅には、明確な物理的限界が存在します。 帯域幅の制限: 衛星が地上局の上空を通過する時間（パスタイム）は、1日に数回、わずか数分間にすぎません。 遅延（レイテンシ）: 深宇宙探査はもちろん、低軌道（LEO）衛星であっても、光の速度やネットワーク中継による数秒から数分の送信遅延が発生します。 通信コスト: テラバイト級の生データを毎日地上へ転送することは、多大なコストを伴います。 この問題を解決する唯一の突破口は、**「衛星の内部でデータを即座に処理し、価値のある情報（インサイト）だけを地上に送信する」 ことです。すなわち、宇宙の軌道そのものをエッジデータセンターにする 軌道コンピューティング（Orbi...

SkillOpt vs Agent Lightning: AIエージェント最適化、あなたの選択は？ ! SkillOpt vs Agent Lightning 比較 2026年5月、マイクロソフトリサーチ（Microsoft Research）はAIエージェント開発コミュニティに2つの強力なフレームワークを公開しました。 SkillOpt と Agent Lightning です。どちらもAIエージェントの性能を向上させることを目標としていますが、そのアプローチは全く異なります。 --- 🧠 核心的な哲学の違い：何を最適化するか？ SkillOpt : エージェントが読む テキスト指示（スキル文書） を最適化します。 Agent Lightning : エージェントの 行動パターンと意思決定プロセス 自体を最適化します。 --- 📄 SkillOpt: "指示を進化させるフレームワーク" SkillOptは、エージェントが参照する`skills.md`ファイル（自然言語指示）を 訓練可能なパラメータ として扱います。モデルの重み（weight）は一切変更しません。 実測パフォーマンス GPT-5.5基準での精度向上： Direct Chat : +23.5ポイント Codex Agentic Loop : +24.8ポイント Claude Code : +19.1ポイント 🔗 公式リソース GitHub : https://github.com/microsoft/SkillOpt プロジェクトページ : https://microsoft.github.io/SkillOpt/ 論文 (arXiv) : arXiv:2605.23904 SkillOptを選ぶべき場合 クローズドソースモデル（GPT-4o, Claudeなど）を使用している場合 特定ドメインの手順や知識ベースのタスク 人間が結果を審査・承認する必要がある規制環境 インフラ構築を最小限にしたい場合 --- ⚡ Agent Lightning: "エージェントを根本的に訓練するフレームワーク" Agent Lightningは、エージェントの実行プロセスを マルコフ決定過程（MDP） としてモデル化し、強化学習でエージェントの行動を最適...

宇宙衝突を防ぐ人工知能：2026年AI搭載宇宙交通管理（STM）と状況認識（SSA）のトレンド 2026年現在、人類は歴史上かつてないほど混雑した宇宙空間に直面しています。SpaceXのスターリンク（Starlink）やAmazonのプロジェクト・カイパー（Project Kuiper）をはじめとする低軌道（LEO）メガコンステレーション（Mega-Constellations）の急増により、地球軌道を回る人工衛星は数万機に達しており、これに伴って軌道上での衝突リスクも指数関数的に増加しています。 人工衛星同士の衝突や、衛星と宇宙ゴミ（スペースデブリ、Space Debris）の衝突は、単なる機器の損失にとどまらず、連鎖衝突によって地球軌道全体を利用不可能にする**「ケスラーシンドローム（Kessler Syndrome）」**を引き起こしかねない致命的な脅威です。このような宇宙規模の大惨事を防ぐため、2026年の宇宙産業界は人工知能（AI）を実戦配備し、**宇宙状況認識（Space Situational Awareness、SSA） と 宇宙交通管理（Space Traffic Management、STM）**を革新しています。 今回の記事では、2026年現在のGoogleトレンドや世界的な宇宙カンファレンスで注目されている、AI搭載宇宙交通管理の主要トレンド3選を深く掘り下げて解説します。 1. マルチモーダル・データフュージョン による高精度な宇宙状況認識（SSA） 地上および宇宙に配備された望遠鏡、レーダー、無線周波数（RF）センサーなどは、毎日数百万件もの軌道観測データを生成しています。しかし、これらのデータは測定方法によって誤差範囲が異なり、フォーマットもバラバラであるため、手動で統合・分析するには限界がありました。 2026年のAI搭載SSAシステムは、**マルチモーダル・データフュージョン（Multi-Modal Data Fusion）**技術を活用し、異なるソースのデータストリームをリアルタイムで統合・分析します。 多様なデータの結合： 光学画像で把握した衛星の外観や姿勢情報、レーダーで測定した軌道経路、RFセンサーで検出した通信信号を1つに統合します。 ノイズ除去と精度の向上： 悪天候や宇宙天気（太陽風など）によっ...

宇宙へ向かう人工知能：Google トレンドから探るAIと宇宙技術（Space Tech）の融合と未来のインサイト 最近の Google トレンド（Google Trends）を分析してみると、大衆とグローバルIT業界の視線が「人工知能（AI）」と「宇宙技術（Space Tech）」という巨大な二つの軸の交差点に集中していることがわかります。特に2026년 6월 현재、GoogleとSpaceXの間の超大型コンピューティング契約や、6월 12日に予定されているSpaceXのIPO関連の話題は、検索トレンドの核心キーワードとなっています。 この記事では、最近の Google トレンドデータを基に急成長している AIと宇宙技術의 融合の現状 を整理し、開発者やテック分野のビジネスリーダーに役立つ未来のインサイトをお届けします。 1. GoogleとSpaceXの9億2,000万ドル規模のコンピューティング契約：軌道AIの幕開け 最近 Google トレンドで最も高い検索急上昇を記録したニュースは、 GoogleとSpaceXが締結した月額9億2,000万ドル（約1,400億円）規模のクラウドコンピューティング契約 です。この大規模な取引の背景には、地上に構築されたデータセンターだけでは解決できない「宇宙規模のデータ処理」と「超低遅延AIサービス」に対するビジョンがあります。 宇宙と地上のリアルタイム同期 SpaceXのStarlink（スターリンク）衛星ネットワークは地球全域を結ぶ低軌道（LEO）通信インフラを提供し、Google Cloudは大規模な人工知能モデル（Geminiなど）を駆動するためのインフラを提供します。このパートナーシップを通じて、衛星から収集された高解像度の地球観測データや宇宙観測センサーデータなどがGoogle CloudのAIモデルと結合し、リアルタイムで分析されます。 なぜ大規模な宇宙コンピューティングが必要なのでしょうか？（AEO対応） 回答: 衛星が収集する生（Raw）データの量は、毎日ペタバイト（PB）単位に達します。この膨大なデータをすべて地上に転送してから処理しようとすると、莫大な帯域幅のボトルネックが発生します。そのため、GoogleのエッジAI（Edge AI）技術を衛星システムに直接組み込み、宇宙軌道上...

AI時代の真のボトルネックはGPUではなく送電網である 韓国の26万台GPU計画と日本の電力認識の差異を中心に AIインフラ競争を語るとき、私たちは通常、まずGPUの数量に注目する。どの国がNVIDIAのGPUを何枚確保したか、どの企業がBlackwellをどれだけ導入するか、何EFLOPS規模のAIスーパーコンピューターを構築するかがニュースの中心になる。 しかし、最近の状況を見ると、本当のボトルネックはGPU自体ではないかもしれない。GPUを確保しても、それを装着するデータセンター、そのデータセンターに供給する電力、そしてその電力を実際の場所まで送る送電網が準備されていなければ、GPUを稼働させることはできない。 韓国がNVIDIAから26万台以上の規模のGPUインフラを確保することに合意したという発表は、この問題を非常に鮮明に示している。NVIDIAの公式発表によると、韓国政府、サムスン電子、SKグループ、現代自動車グループ、NAVER Cloudなどが合わせて25万台を超えるNVIDIA GPUインフラを構築する予定である。具体的には、政府とクラウド事業者に5万台以上、サムスン電子に5万台以上、SKグループに5万台以上、現代自動車グループに5万台、NAVER Cloudに6万台以上という構成が提示されている。 この数字は、韓国のAI産業にとって非常に大きなチャンスである。しかし同時に、疑問も生じる。 「このGPUを、実際にどこで、どのような電力で、何年以内に稼働させることができるのか？」 26万台のGPUは単なるサーバーの購入ではない 26万台という数字は、単にサーバー室に機器を追加するレベルではない。BlackwellクラスのGPUは1枚あたりの消費電力が非常に大きく、これをラック単位でまとめると、従来のデータセンターとは異なる電力密度を要求される。 NVIDIAの最新GPUラックの電力使用量は、2020年代初頭の数十kW水準から、2025年には100kWを超える水準へと上昇しており、将来的には数百kWクラスのラックも現実的な範囲に入ってきている。韓国電力公社（KEPCO）の関係者もAIデータセンターの電力密度上昇を指摘し、今後は単一のデータセンターが原発1基分（約1GW）の電力を使用する時代が遠くないと言及した。 26万台全体を単純...

AWS RNGとNVIDIA CPO比較分析 – AIデータセンターネットワークの未来はどこに向かっているのか？ 最近AWSが発表した**RNG (Resilient Network Graphs) とNVIDIAが発表した CPO (Co-Packaged Optics)**は、どちらもAI時代の超大型データセンターを支える重要技術として大きな注目を集めています。 興味深いのは、両技術ともに「AIクラスターのネットワーク問題」の解決を目指していながら、実際にはまったく異なるレイヤーの課題に取り組んでいる点です。多くのメディアではRNGとCPOを競合技術のように紹介していますが、エンジニアの視点から見ると、これらは競合関係ではなく相互に補完し合う関係に近いと言えます。 本記事では、ネットワークアーキテクト、DBRE、SRE、インフラエンジニアの視点から、これら2つの革新的な技術を詳しく比較分析します。 AI時代においてネットワークが極めて重要になった理由 従来のウェブサービスやエンタープライズ環境では、CPUやストレージが主なボトルネックになることが一般的でした。しかし、LLM（大規模言語モデル）の学習環境では状況が180度異なります。 GPT、Gemini、Claudeなどのモデルを学習させるには、数千から数万台のGPUを同時に稼働させる必要があります。実際の学習プロセスは以下のように繰り返されます。 GPU演算 ➔ GPU間データ共有 ➔ GPU演算 ➔ GPU間データ共有 モデルの規模が肥大化するにつれ、GPU単体の演算能力よりも、GPU同士を繋ぐ通信能力がシステム全体のパフォーマンスを決定づけるようになります。これは一般に East-Westトラフィック 問題と呼ばれています。AIデータセンターが解決すべき核心的な課題は以下の通りです。 より多くのGPUの相互接続（拡張性） より低いネットワーク遅延（レイテンシ） より高いネットワークスループット（帯域幅） より低い消費電力（省電力化） AWSとNVIDIAは、それぞれ異なるレイヤーからこの課題にアプローチしています。 AWS RNG (Resilient Network Graphs) AWSが選択したアプローチは、トポロジー（接続構造）の革新です。従来のデータセンタ...

SQL Serverにおけるデータベースの互換性レベル（Compatibility Level）の変更は、単なる「バージョン互換性」以上の意味を持っています。実際には、クエリの最適化方式、カーディナリティ推定（Cardinality Estimation）、インテリジェントなクエリ処理（Intelligent Query Processing, IQP）機能の有効化にいたるまで、パフォーマンスに直結する重要なアーキテクチャ上の決定です。 特定のクエリが遅くなった際、互換性レベルを下げることで一時的に復旧させることがあります。しかし、これはデータベース全体として最新エンジンが提供する最適化機能を放棄することになります。本記事では、SQL Serverの互換性レベル100と160の違いをQuery Storeの視点から再考し、最適な移行・運用戦略を解説します。 1. 互換性レベル 100 でも Query Store は動作するのか？ よくある誤解の一つに、**「100のような古い互換性レベルではQuery Storeを使用できない」**というものがあります。結論から言うと、 これは誤りです。 互換性レベルが100（SQL Server 2008相当）に設定されていても、SQL Server 2016以降のバージョンで動作しているデータベースであれば、Query Storeを有効にして以下のコア機能を活用できます。 パフォーマンスデータの収集 : クエリテキスト、実行計画（Execution Plan）、ランタイム統計（平均実行時間、CPU使用量、論理読み取り数など）の収集。 実行計画の比較 : 互換性レベル変更の前後、または特定期間における実行計画の低下（Regression）の検知。 実行計画の強制（Plan Forcing） : 特定の query_id に対して、過去の最適な plan_id を強制適用し、クエリパフォーマンスの安定性を担保。 そのため、古い互換性レベルで動作しているからといって、強力な監視ツールであるQuery Storeを諦める必要はありません。 2. 100 vs 160：インテリジェントなクエリ処理（IQP）の壁 しかし、単なるパフォーマンスの収集を超えて、 自動的な最適化 の領域に進むと、互換性レベルの...