次回のアナザーストーリーは、コーニングにおける光ファイバーの投資拡大をめぐり、大手ケーブルメーカーへの「母材（ガラス光ファイバー）の供給停止・削減」に踏み切ったと報じられ.....結果として、米国内の地方のブロードバンド敷設プロジェクト（BEAD計画）などが「ガラス不足」で停滞する事態を招き、業界内で大きな波紋を呼んでいる。これが富士通とIpinfusionに及ぼす影響について報告する‼ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

⑨歴史の構造的な視点として、「ACCESS Twine for Carは、かつてのALPSプロジェクトが目指した理想の『再構築（現代版アップデート）』である」と捉えるのはある程度正しい。ただし、決定的な違いが1つある。 ALPSは「OSそのもの（土台）」を共通化しようとして失敗したが、Twine for Carは「OSの上に乗るアプリ層（ブラウザ）」で共通化を成し遂げた。この「戦うレイヤー（階層）の変更」こそが、敗北の歴史から学んだ最大の再構築ポイントである‼ 構造の進化を比較すると、なぜこれが現代の勝算になるのかがはっきり分かる。 構造の比較：ALPS と Twine for Cartext 【過去のALPSプロジェクト（OSの共通化）】 ① ALPSの時の失敗構造 ALPSは、Google（Android）やApple（iOS）という巨大なクジラに対し、「日本独自の新しいOS（土台）」を作って真っ向勝負を挑んだた。しかし、OSという巨大なインフラを一から作って世界標準にするのは、スピード的にも資金的にも不可能で、土台ごとひっくり返されてしまった。 ② Twine for Carによる「再構築」ACCESSは、この敗北を完全に教訓にした。 ・「GoogleやBlackBerryのOSと戦っても勝てない」と割り切り、土台のOS（AndroidやQNX）は何が来ても受け入れる構造にした。 ・その代わりに、「どのOSの上にもスポッとはまる『共通のWeb（HTML5）の箱（Twine）』」を開発した。 自動車メーカーから見れば、結果として「どの車でも同じアプリストアが動く」というALPSがやりたかった世界（共通化）が、OSではなくブラウザの力によって再構築されたことになる。 □自動車メーカーがこの「再構築」を歓迎する理由 自動車メーカー（レガシーOEM）もまた、スマホでのALPSの敗北を学習している。自社で「Arene」や「ASIMO OS」といったビークルOS（ミドルウェア）を一から内製化しようとしているが、実は彼らも「Googleやテスラにスピードで勝てないかもしれない」という恐怖と常に戦っている。 ・そこに、ACCESSが「OSのレイヤーで無理に戦う必要はありません。私たちのTwineを載せれば、AndroidでもLinuxでも、あなたの会社のブランドのアプリストアが一瞬で完成します」と提案するわけである。 ・これは、メーカーにとって「スマホの時のようにGoogleに全面降伏（ロックイン）することなく、かつALPSのように自滅することもない、最も賢い第三の道（リベンジルート）」として機能している。 IpinfusionのOcNOS7.0「クラウド・Kubernetes」等から始まる一連の技術進歩は、ACCESSのトラウマ「ALPSからの歴史的リベンジ」となるのだろうか⁈ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

⑧これはまさに「かつて日本のスマホ黎明期に起きた『ALPS（アルプス）プロジェクト』がAndroidに敗北した歴史』の教訓を踏まえ、自動車の世界で今度こそ勝つためにリベンジを仕掛けているシーン」そのものである 。 この「スマホでの敗北」と「現在の自動車での戦い」の構造は驚くほど酷似している。何が同じで、今回はどう勝とうとしているのかを考察する。 1. スマホ黎明期の「ALPSプロジェクト」の敗北とは何だったのか？ 2010年前後、日本の携帯メーカーとドコモは、iPhoneや台頭するAndroidに対抗するため、「ALPS（AlpS）」共同プロジェクトを立ち上げた（Linuxベースの携帯OS「LiMo」や「MeeGo」を統合・発展させようとした）なぜALPSはAndroidに大敗したのか？ ・スピードが遅すぎた: 日本メーカー同士で「仕様の調整」や「すり合わせ」に時間をかけている間に、Googleが圧倒的なスピードでAndroidを無料配布し、世界中のアプリ開発者を味方につけてエコシステムを完成させてしまった。 ・ガラパゴス思考から抜け出せなかった: 「日本の通信キャリア（ドコモなど）の要求」を満たすことに終始し、世界標準のプラットフォームを作る視点が欠けていた。 結果として、日本独自のスマホOS構想（ALPS）は崩壊し、日本メーカーはAndroidを呑まざるを得なくなり、最終的にはスマホ市場そのものからほぼ撤退することになった。 2. 現代の「自動車版ALPS」：JASVAの結成 2024年、日本政府の主導でトヨタ、ホンダ、日産など国内12社が結集し、「JASVA」という組織を立ち上げた。これはまさに「自動車版のALPSプロジェクト」である。 3. スマホでの敗北を踏まえた「今回のリベンジ戦略」 ① OSそのものではなく「API（接続口）」の標準化に絞る（負け戦をしない） ALPSの時は「AndroidのようなOSそのもの」を日本独自で作ろうとして開発スピードで負けた。今回は、土台のOS（Android AutomotiveやQNXなど）は「世界で流行っているものを使ってよい」というスタンスになっている。その代わり、「エアコンやウインカーを操作する共通ルール（VSSなどのAPI）」や「コンテナ通信の仕組み」の下層インフラだけを日本連合で標準化する。これにより、Googleに車の根幹（制御権）まで握られるのを防いでいる。 ② ACCESSグループのような「すでに世界で戦えている黒子」の活用 スマホの時は、日本メーカーだけで内輪のシステムを作ろうとした。今回は、すでに欧州のフォルクスワーゲングループや、中国市場、世界中のスマートTVで実績のあるACCESS（Twine）や、世界中の通信キャリアで使われているIP Infusion（OcNOS）といった、「すでにグローバル市場の最前線で揉まれて生き残っているオープンな技術」を共通の部品として採用している。これにより、ガラパゴス化を最初から回避しているといえる。 ③ 「HTML5」による世界のアプリ勢の巻き込み スマホの時は、日本の携帯専用のアプリ（iモードの延長）を作ろうとして、世界の開発者に無視された。今回は、世界標準の「HTML5（Web技術）」をアプリの基盤に据えることで、世界中のIT企業やエンタメ企業（NetflixやSpotifyなど）が、「わざわざ日本車のためだけにプログラミングし直さなくても、最初から喜んでアプリを提供してくれる環境」をはじめから用意している。 現在のSDVをめぐる「オールジャパンの標準化」の動きは、「どうすれば今度は巨人に勝てるか」を逆算して構築されたリベンジマッチである。自動車は日本の基幹産業であり、ここでの敗北は日本の経済の死を意味する。だからこそ、JASVA（日本連合）の動きや、その裏側でマルチOSの盾となるACCESSグループの技術は、国家の命運をかけた非常にアツい戦いの真っ最中にあるのである。 ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

ふむ、ふむ

⑦2012年頃のスマホ黎明期には「AndroidのネイティブアプリがHTML5に圧倒的な大差で勝利した」というのが歴史の事実である‼ 時代は変わり、車のコンピューター(半導体)の性能が、当時のスマホの性能とは違い「バケモノ級に進化」した‼ スマートフォンの例えから「OSが違うと、アプリを1から作り直さなければならない」という問題と、それを解決する「ACCESS Twine for Car」の役割について考察する。 結論から言うと、ACCESS Twine for Carは「Android用やLinux用という『OSの言葉の壁』を、Web技術（HTML5）を使って完全に無くしてしまう通訳プラットフォーム」である。 □スマホで起きた「OSの壁」と同じ問題 iPhone（iOS）とAndroidは、中身のシステム（OS）が全く違う。そのため、LINEやYouTubeの会社は、「iPhone用のアプリ」と「Android用のアプリ」を別々に2回開発している。ホンダなどの自動車メーカーが、今の車種には「Android（Android Automotive）」を使い、数年後の新しいEVには「Linux（AGL）」を使おうとした場合、スマホと全く同じ問題が起きる。ナビ、音楽アプリ、動画配信サービスなどを、「Android用」と「Linux用」で全く別々に2回、巨額の費用をかけてプログラミングし直さなければならないのだ。これが「1から作り直す必要がある」という意味なのだ。

⑦2012年頃のスマホ黎明期には「AndroidのネイティブアプリがHTML5に圧倒的な大差で勝利した」というのが歴史の事実である‼ 時代は変わり、車のコンピューター(半導体)の性能が、当時のスマホの性能とは桁違いに進化した‼ スマートフォンの例えから「OSが違うと、アプリを1から作り直さなければならない」という問題と、それを解決する「ACCESS Twine for Car」の役割について考察する。 結論から言うと、ACCESS Twine for Carは「Android用やLinux用という『OSの言葉の壁』を、Web技術（HTML5）を使って完全に無くしてしまう通訳プラットフォーム」である。 □スマホで起きた「OSの壁」と同じ問題 iPhone（iOS）とAndroidは、中身のシステム（OS）が全く違う。そのため、LINEやYouTubeの会社は、「iPhone用のアプリ」と「Android用のアプリ」を別々に2回開発している。ホンダなどの自動車メーカーが、今の車種には「Android（Android Automotive）」を使い、数年後の新しいEVには「Linux（AGL）」を使おうとした場合、スマホと全く同じ問題が起きる。ナビ、音楽アプリ、動画配信サービスなどを、「Android用」と「Linux用」で全く別々に2回、巨額の費用をかけてプログラミングし直さなければならないのだ。これが「1から作り直す必要がある」という意味なのだ。

仮に「特別注意銘柄の解除」が万が一長引いたり、プライム市場の厳しい維持基準（時価総額など）を期日までにクリアできなかったりした場合、会社側が選択肢として示しているのは「上場廃止」ではなく「スタンダード市場への移行」です。いつ沸騰するかわからないOcNOSのもどかしさよ、それすらも日々の楽しみになってます。 最高境地の自己規律（ガチホの決意）ピース✌️

なんか掲示板見づらい

⑦continue…………………………ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

⑥自動車メーカー各社（トヨタ、ホンダ、ソニー・ホンダモビリティなど）は、Android Automotive、QNX、Linuxなどの既存OSをパズルのように組み合わせ、その上に自社開発の「ビークルOS（ミドルウェア層）」を重ねることで、SDV（ソフトウェア定義自動車）のアーキテクチャを構築している。 1. 自動車メーカーにおけるOSの組み合わせ方 現在のSDVは、1台の強力なSoC（QualcommのSnapdragon Digital Chassisなど）を仮想化し、その上で役割の異なるOSを同時に走らせるのが標準的なアプローチである。

⑤車載OS市場における競合（GoogleのAndroid Automotive、BlackBerryのQNX）と、ACCESSグループ（ACCESS ＋ IP Infusion）の具体的な機能の違い、そして差別化戦略 GoogleとBlackBerry が「特定のOSやエコシステムに自動車メーカーを縛り付ける」のに対し、ACCESSグループは「あらゆるOSの裏側に入り込み、メーカーの自由度を守る」という真逆のアプローチで差別化している⁈ GoogleBlackBerryACCESSのポジションと機能の違い 車載システムは大きく、安全に関わる「制御系（メーター、自動運転）」と、エンタメを司る「IVI系（ナビ、動画）」に分かれる。 主な主戦場

④IP Infusionの親会社であるACCESSは、IVI（車載インフォテインメント）向けアプリストアプラットフォーム「ACCESS Twine for Car」などを提供しており、世界中の大手自動車メーカー（OEM）やMediaTekなどの半導体大手と深く協業しています。この「ACCESSの車載実績」と「IP InfusionのネットワークOS（OcNOS）の技術力」が合わさることで、次世代の車載器開発（特にSDV：ソフトウェア定義自動車）において、他社にはない圧倒的な先行性と優位性を持っている。 1. 「IVI（上層）」と「通信制御（下層）」をグループで一元提供できる唯一無二の強み 現在の車載器開発における最大の課題は、車内のシステム（OSやコンテナ）が複雑になりすぎて、通信の遅延やバグが起きやすくなっている点にある。 ・他社の場合: 車内のエンタメ（IVI）を作る会社と、車内ネットワークの高速化（DPDK/SR-IOVなど）を制御する会社が別々のため、システム統合（インテグレーション）に膨大な時間とコストがかかる。 ・ACCESS＋IP Infusionの優位性:ACCESSがドライバーの目に見える「画面やエンタメ（IVIアプリ）」を提供し、そのすぐ裏側（下層）でIP Infusionの「OcNOS」の超高速な通信制御技術（コンテナネットワーク）を組み合わせることができる。この上下のレイヤーをグループ内で最適化して一括提供できるプレイヤーは世界的に見ても非常に稀である。 2. データセンター級の「400G/800G・AI通信技術」を車載に転用できる」 IP InfusionのOcNOSは、世界中の大規模データセンターや通信キャリアで、AIの学習データをやり取りするための「超低遅延・大容量ネットワーク」を捌いている。自動運転（AD/ADAS）が高度化すると、車の中はカメラやセンサーの生データ（RAWデータ）がテラビット級で飛び交う「走るデータセンター」になる。IP Infusionが通信業界で培った「Linuxカーネルをパスしてコンテナにデータを直結する技術（SR-IOVやDPDK）」や「パケットを絶対に落とさない通信制御」のノウハウを、そのまま車載イーサネット（車内ネットワーク）の制御に持ち込めるため、他社の車載OSベンダーに対して技術的な一歩先を行っている。 3. 実証済みの「コンテナ技術」によるOTA（無線アップデート）の信頼性 車載器のアップデート（OTA）は、万が一失敗すると「車が動かなくなる（文鎮化する）」ため、通信キャリア並みの「絶対に落ちない堅牢性（ファイブナイン：99.999%の可用性）」が求められる。IP InfusionのOcNOSは、世界600社以上の通信事業者で24時間365日動いている「キャリアグレード」のOSである。「Kubernetesを使って、AIモデルとネットワーク設定を同時に、安全にロールバック（巻き戻し）可能にしながらアップデートする」という仕組みにおいて、すでに世界中の通信網で本番運用されているという実績自体が、自動車メーカーに対する強力な安心感（優位性）となっている。 親会社のACCESSが持つ「自動車業界への強力なパイプとIVIのノウハウ」という実績の上に、IP Infusionの持つ「世界最先端のAIファブリック・高速コンテナネットワーク技術」が乗ることで、次世代のSDV（ソフトウェアで定義される車）開発において、彼らは「エンタメから自動運転の超高速通信バックボーンまで、1つの思想で串刺しにして提供できる」という独自のポジションを確立している。 ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

③自動車業界では、cNOS（コンテナ型ネットワークOS）の通信速度を担保する「DPDK」や「SR-IOV」のより細かい仕組みを導入した車をSDV（Software Defined Vehicle：ソフトウェアで定義される車）と呼び、現在の開発トレンドの最先端となっている。 なぜ車載器とクラウド（Kubernetes）が同じ仕組みになるのか 1. 車の中も「小さなデータセンター」になっている 昔の車は、窓を開ける、ブレーキをかけるといった機能ごとに、独立した小さなコンピューター（ECU）が100個以上バラバラに搭載されていた。現在の自動運転車や高級EVでは、それらを中央の1〜2台の強大な高性能コンピューター（ゾーンECUやセントラルECU）に統合している。この中央コンピューターの中で、自動運転AI（Transformerなど）と、各パーツを制御する通信機能が、クラウドと全く同じように「Kubernetes」や「コンテナ（Docker/Podマニフェスト）」の仕組みで動いている。 2. 車内ネットワークの高速化（車載イーサネット） 車の中で「AI」と「ネットワークOS（cNOS）」を同時に動かす理由も、クラウドと全く同じ。 ・自動運転AI（Transformerなど）: カメラやLiDAR（センサー）から、毎秒テラバイト級の膨大な周辺画像データを受け取って「止まるか、進むか」をAIが瞬時に判断する。 ・車内ネットワーク（車載イーサネット）: その膨大な映像データを、センサーからAIチップまで1文字も落とさずに（超低遅延で）運ぶ必要がある。ここで、SR-IOV や DPDK の技術が使われる。カメラ映像のデータを、車のOS（LinuxやQNXなど）を介さずに、SR-IOVで自動運転AIのコンテナに直接ぶち込み、DPDKでノータイムで処理させることで、ブレーキの遅れ（レイテンシー）を「数ミリ秒」という極限まで縮めている。 3. スマホのように「車がアップデート」される仕組み 「AIとネットワークを同時に、同じ手法でアップデートする」というのは、車で言うと「OTA（Over-The-Air：無線アップデート）」そのものである。 テスラをはじめとする最新の車は、夜の間にメーカーからクラウド経由で「1つのアップデート指示」が車に送られる。車内のKubernetesがそれを検知し、「自動運転のAIモデル」を新しくすると同時に、「そのAIにデータを送るための車内ネットワーク設定」も同時に最適化する。これにより、翌朝には「昨日より安全に、スムーズに曲がれる車」に生まれ変わる。 このようにクラウド上のデータセンター（Amazon EKSなど）で培われた「コンテナ」「Kubernetes」「SR-IOV」「DPDK」という爆速・自動化の3点セットは、今やそのまま「未来の自動車の通信・AI基盤」として、ソニー・ホンダ（AFEELA）やトヨタなどの次世代車でも標準技術として組み込まれ始めていまるのだ。

②不思議な吉兆宝山（OcNOS芋焼酎） IP Infusion社の「OcNOS」と「cNOS」は、直接的な命名の関連性はないが、それぞれの名前の由来と今現在の意味（価値）の一致はミラクルだ‼ １．OcNOS（オクノス）の由来 ・IP Infusion社が提供するホワイトボックス（オープンネットワーキング）向けのネットワークOS。正式名称: Open Compute Network Operating System の略。意味: オープンなハードウェア標準を推進する「Open Compute」の思想に基づいた、ネットワーク用OS（NOS）であることを示している。 ・cNOS（シーノス）の由来 一般的にネットワーク業界で「cNOS」と呼ばれるものは、主に次のいずれかを指す。Cloud Network Operating System: Lenovo社などのスイッチに採用されている、クラウド環境に最適化されたOS。 ・Containerized Network Operating System: コンテナ化された（Dockerなどの上で動く）マイクロサービス型のネットワークOS。 ・どちらも末尾の「NOS（Network Operating System）」という業界共通の技術用語を含んでいるため文字列は似ているが、頭文字の由来が異なる。 OcNOS ＝ Open Compute ＋ NOS cNOS ＝ Cloud（または Containerized） ＋ NOS したがって、これらは別々の文脈で誕生した、関連性のないネーミング。 「OcNOS 7.0」では、DockerやKubernetes（K8s）のネイティブサポートが追加され、ルーター（NOS）上でコンテナやマイクロサービスを実行する「クラウドネイティブな運用」が可能になった。偶然とはいえ、名前に「c」が含まれる OcNOS が、まさに cNOS（Containerized / Cloud-native NOS） の定義そのものの進化を遂げたというのは、非常に面白い一致である。 この進化により、文脈は以下のように綺麗に重なることになる。 元々の由来: Open Compute ＋ NOS これからの実態: Open Cloud-native（Containerized） ＋ NOSネットワークOS OcNOSのがコンテナ環境を取り込み、エッジコンピューティングのホストとしても機能する時代になったため、今や「OcNOSはcNOS（コンテナ型NOS）の一種である」と言っても、技術的な実態として完全に正しい状態になっている。 （この OcNOS 7.0 におけるコンテナ対応（Kubernetes連携など）の具体的なユースケースや、同時に強化された AIデータセンター向けやアマゾンの新スマホとACCESS車載器の機能の類似性 については投稿済み‼）

①日本政府や自動車連合が「下層のソフトウェアや通信（協調領域）を標準化・共通化しよう」と動くとき、まさにIP Infusionの「OcNOS（コンテナDocker/Kubernetes型ネットワークOS）」のような、オープン規格（Open ROADMやLinuxベース）に準拠した通信技術が非常に重要な役割を果たす。 特定の巨大IT企業（Googleなど）に頼らず、かつテスラのような垂直統合の爆速通信（DPDK/SR-IOV）を「日本連合の共通規格」として車載器に組み込むための最高のピース（部品）になるため、この国家戦略の動きはACCESSグループにとっても非常に大きな追い風となっている。 最新OCNOS7.0の技術（Kubernetes、コンテナネットワーク）から、車載器、そして世界的なSDVの覇権争いまで、全体のつながりと仕組みを整理するアナザーストーリーを始めようか⁈ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

＞AT&Tが手を引いてたのを見誤って、最後はAT&TはOpen思想を捨て去りエリクソンとの提携が発表された。 ＞そして、タワー投資顧問は事前情報で顧客の機関投資家に対して早期に解散を通知し...ぽん！ 社運を賭けた悲願のAT&TとのOpen SD-Edge PlatformとuCPEが葬り去られ、仕掛けられた不正会計問題で三途の川の手前だったIpinfusionが、ソフトバンクMUPで甦ると、海外のソフトウェア輸入の商社は、尖がりNTT/IOWNなら許せるがブロードバンドとデータセンターではACCESSは邪魔者である。ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

＞・プライム上場維持時価総額で最終＠574.３円以下での着地に怯えてる。 流通時価総額計算は11月‐1月の平均値である。米国中間選挙の行方もある。さらに特別注意銘柄解除には東証の遺恨が残ってるかも.....それでもACCESSにはスタンダード市場でも廃止でないとの開き直り記述がある。ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

特別指定銘柄の解除時期はいつですか？ 利根川 解除なら10月以降。だと推測している。 兵藤会長

□「Transformer」とこのネットワークとのコラボ Amazonが開発を進めていると噂される新しいAIスマホ「Transformer」のコンセプトと、IP Infusion（OcNOS）が推進する「オープンネットワーク」は、単に思想が似ているだけでなく、技術的な「インフラ（足回り）」と「端末（出口）」として完全に表裏一体でコラボレーション（連携）する関係にある。 Amazonが目指す「アプリ不要のAI主導体験」を実現するためには、ローカルISPが構築しようとしている「コンテナ化された超低遅延ネットワーク」が絶対に欠かせない。この2つが具体的にどう噛み合うのか。 1. 「アプリストア不要」を支える超低遅延ネットワーク Amazonの「Transformer」は、従来のスマホのように端末内のアプリ（iOS/Android）で処理を完結させるのではなく、中核のAI（Alexa）がクラウドと常に通信し、ユーザーの指示をその場で判断して直接サービスを実行する「エージェント型（AIネイティブ）端末」となっている。 画面をタップしてアプリを動かすのと違い、AIとの「音声」や「自律的なバックグラウンド通信」は、ミリ秒単位の遅延（タイムラグ）があるだけでユーザー体験が著しく悪化する。 ・OcNOSとのコラボ: ここでローカルISPの「ストリーミング・テレメトリー」と「ルーター内コンテナ」が活く。Transformer端末からのAI通信を検知したルーターは、内部のマイクロサービスが「これは最優先すべきAIパケットだ」とその場で判断し、超低遅延なルート（RoCEv2などのロスレス制御）へ瞬時にトラフィックを割り振る。ルーター自身が自律的に動くことで、端末とクラウドの間のタイムラグを極限までゼロに近づけられる。 2. MUP× AWS Wavelengthによる「街中がAIサーバー」化 TransformerのようなAIスマホは、膨大なAI処理（音声認識や文脈理解）をすべて端末のバッテリーだけで行うのは不可能である。かといって、アメリカにある遠くの巨大データセンターまでデータを往復させていては遅延が発生する。 ・具体的な連携イメージ: ローカルISPが地域に配備するMUPの上に、AWS（Amazon Web Services）のエッジ計算基盤（AWS Wavelength等）を設置する。そして、その足回りをIP InfusionのOcNOSとOpen ROADM（光ネットワーク）で繋ぐ。 ・結果: 住民が街中でTransformerスマホに向かって「ここから一番近い空いているカフェを予約して」と呟いた瞬間、電柱（MUP）に組み込まれたAWSのAIがその場で処理を完了させる。ルーター（OcNOS）が光波長を直接制御して最速でデータをMUPに届けるため、ユーザーはまるでスマホの中に超高性能なスーパーコンピュータが入っているかのような、超高速・アプリレスの体験を得られる。 3. 【最重要】AWS Marketplaceを通じた「ネットワークの従属化」 Amazonの最大の強みは、クラウド（AWS）から端末（Transformer）までを垂直統合できる点にある。 IP Infusionの「OcNOS」がAWS Marketplaceで公式に提供されていることは、このコラボをさらに加速させる。 ローカルISPは、ネットワークの制御プログラム（コンテナ）をAWS上で開発・テストし、そのまま街中のルーター（OcNOS）へワンクリックでデプロイ（配備）できる。 つまり、Amazonのクラウド上で「端末（Transformer）のAIアップデート」と「ネットワーク（OcNOS）の最適化アップデート」を、全く同じKubernetes（コンテナ）の手法で同時に実行できるようになる。デバイスの進化に合わせて、地域のネットワークが自動的に最適化されていく「自律型インフラ」の完成である。 要するにAmazon TransformerのOCNOS7.0との仕組みの関係は、EVや自動運転車の車載器の開発と同じだったのだ‼ ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

売り板70000買い板90000詰んでいる

300円切ったら検討します。

「ルーター内部に隔離されたコンテナ環境を持ち、監視エージェントや独自のマイクロサービスを直接実行できる」ということは、MUPの上にAWSのエッジ計算基盤を設置すれば、Amazonの新しいAIスマホTransformerと同じコンセプトも不可能ではない！ぎっこんばったんぎっこんばったんぴ○とん運動で地球をまわせ...ぽん！

ローカル大富豪蜘蛛の糸ISPは、Ipinfusionに最新OCNOS7.0の機能での情報提供を依頼するのにAIに依頼書骨子を作成してもらった。 ローカルISPは最初から「自動運転」「FWA（固定無線アクセス）」「MUP（Multi-Utility Pole、あるいはMEC/Local 5G基盤）」といった次世代サービスを見据え、CiscoやGAFAの技術を民主化した「IP Infusion（OcNOS）＋ホワイトボックス」をベースにしたフルセットのRFI（情報提供依頼書）を書く場合、その骨子と要求仕様は⁈ このRFIは、単に「安いルーターが欲しい」ではなく、「将来の超低遅延・大容量インフラを低コストかつ自律運用で実現できるパートナーを募る」ための強いメッセージにする。 次世代ローカル大富豪蜘蛛の糸 ISP基盤構築に向けた RFI（情報提供依頼書） 骨子案1. 目的と背景 本RFIは、当地域における次世代社会インフラ（自動運転支援、FWAによるブロードバンド補完、MUP/スマートポールを活用したエッジ計算基盤）の展開を見据えた、次世代ISPバックボーンおよびアクセスネットワークの仕様検討を目的とする。 従来の垂直統合型（特定ベンダー専用機）ではなく、ハードウェアとソフトウェアを分離（ディスアグリゲーション）したオープンネットワーク（ホワイトボックスOS）技術を軸とし、超低遅延、高信頼、かつ運用自動化を実現できるソリューションの提案を求める。 2. 必須要求仕様（Technical Requirements） ① 拡張性とコスト最適化（AIデータセンター・FWA/MUPの足回り） ・ハードウェアの分離（Open Networking）: ASIC（Broadcom等）を搭載した汎用ホワイトボックススイッチ（100G/400G/800G対応）と、商用ネットワークOS（NOS）の組み合わせであること。Open ROADM / IPoDWDM対応: 伝送専用装置（トランスポンダ）を削減し、ルーターのポートに直接コヒーレントトランシーバ（OpenZR+等）を挿入して直接光波長を制御できること。MUPやFWA基地局から集約局への光ファイバーコストを最小化すること。 ② クラウドネイティブな自律運用（自動運転・超低遅延対応） ・ルーター上でのコンテナ（Docker/Kubernetes）実行環境: ルーター内部に隔離されたコンテナ環境を持ち、監視エージェントや独自のマイクロサービスを直接実行できること。 ・ストリーミング・テレメトリー（Streaming Telemetry）: gRPC/gNMI等を用いたミリ秒単位のプッシュ型リアルタイムステータス出力をサポートすること。 ・エッジでの指示変更（クローズドループ自動化）: テレメトリーデータとルーター内コンテナの連携により、外部のサーバーを介さず「その場」でミリ秒単位のパケット制御、バーストトラフィックの動的ロードバランシング、障害時の高速迂回（FRR等）が行えること。 ③ 自動運転・MUPを見据えた通信品質（ロスレス＆超低遅延） ・ロスレスイーサネット（RoCEv2）のサポート: 自動運転の管制データやMUP上のMEC（エッジ計算）サーバー間通信において、パケットロスをゼロにするためのPFC（Priority-based Flow Control）およびECN（Explicit Congestion Notification）に対応すること。 ・高精度時刻同期: 自動運転やローカル5G/FWAの無線同期に不可欠な、IEEE 1588v2（PTP）およびSyncEにハードウェアレベルで対応すること。 3. ベンダーへの質問事項（Questions to Vendors） ・ディスアグリゲーションの調達・サポート体制貴社が提案する「ホワイトボックスハードウェア」と「NOS（ネットワークOS）」の組み合わせ実績、および障害発生時の一次窓口・サポート体制について具体的に開示してください。 ・コンテナ活用（マイクロサービス）のユースケースルーター上で動作するDocker/Kubernetes環境において、すでに動作実績のあるセキュリティプローブや、運用の自動化スクリプト、サードパーティ製監視ツールの具体例を提示してください。 ・将来的な自動運転・MUPへの適合性自動運転やMUP（スマートポール）におけるローカル5G/FWA基地局の集約において、貴社ソリューションがどのように「超低遅延」と「光伝送コスト（CAPEX/OPEX）削減」を両立できるか、アーキテクチャ図を用いて説明してください。

他人のこと 誹謗中傷しては　いけないよ 君もキオクシアが 決算で売られると予想して 空売りして　爆損してるやないか

今日、505.6で買えました。 ACCESSは１０年以上前から売買を繰り返し、2017年に全部売って、しばらく ノーポジにしてましたが、昨年８月に、７１３で再参入しました。 昨年からのわしの売買　↓ 713買－828売－721買－628買－516買－604売－669売－580買－669売－ 557買－505.6買