  |
はてなキーワード:ミドルウェアとは
以下回答
ゲーム機メーカーが「自社ハードウェア事業を終息」し、「自社ソフトを他社プラットフォームに供給する」という方針転換を行う場合、経営・ブランド・技術・収益面などで多面的なリスクやデメリットが生じます。以下に体系的に列挙します。
🧩 1.経営・戦略面のリスク
■ (1)収益構造の変化による利益率低下
- 自社ハード販売による利益（ハード本体・周辺機器・ライセンス料など）が消滅。
- 他社プラットフォームでは、**販売手数料（例：30%前後）**を支払う必要があり、**利益率が大幅に低下**。
- 「プラットフォーム料」によって価格戦略の自由度も制限される。
■ (2) 成長ドライバー喪失
🎮 2.ブランド・マーケティング面のリスク
■ (1)ブランド価値・アイデンティティの喪失
- 「ハード＋ソフト一体の体験」を提供していたブランドが崩壊。
- 消費者にとって「唯一無二のゲーム体験」を失う。
- 長年築いた「プラットフォームブランド」（例：PlayStation、Switchなど）が**事実上消滅**。
■ (2)既存ユーザーの離反・不信感
■ (3)販売チャネルの再構築コスト
⚙️ 3.技術・開発面のリスク
■ (1)技術力・開発ノウハウの空洞化
■ (2) 他社プラットフォームへの依存度上昇
💰 4.経済・契約面のリスク
■ (1)ロイヤリティ・手数料負担
- プラットフォーム運営会社（例：Sony,Microsoft,Nintendo,Valveなど）に販売手数料を支払う。
- サブスクリプションサービス（例：Game Pass）に参加する場合、**収益分配の条件交渉が不利**になる可能性。
■ (2)価格政策の制約
🧠 5.組織・人材面のリスク
■ (1)人員削減・士気低下
■ (2) 開発体制の再構築コスト
🧩 6.市場・競争面のリスク
■ (1)差別化困難
■ (2) 他社との関係悪化の可能性
🕰️ 7. 過渡期の移行リスク
✅ 総括
観点 主なリスク・デメリット 経営 利益率低下、成長鈍化 ブランド 独自性喪失、ユーザー離反 技術 ハード技術衰退、他社依存 組織 人員整理・士気低下 市場 差別化困難、競争激化
もし本当にMicrosoftがXBOX販売から撤退したら、こういうリスクを織り込んだうえでそれでも決断せざるを得なかった、という事なわけだ。
だからそれはミドルをいじってるんじゃなくてバックエンドとフロントエンドのどっちかの開発でいじってるだけだろ
その間をうちがサポートしますよって売られてる商品がミドルウェア
握って出すのがフロント
ミドルウェアっていう言葉を聞き齧った素人はバックとフロントの間にミドルってものがあると思ってしまうけどそれは外から見たものでしかない
そもそもミドルウェアって話はApacheだとかの「ウェブサーバー」の話であってバックエンドの話だしそもそもバックエンドフロントエンドとかいうのが一般的になる前の話であって
今はその辺の「ミドルウェア」はクラウド側に乗ってるし時間軸も違うからバックとフロントの間にミドルとかまるで頓珍漢なんだよね
バック、フロントしかなくて、ミドルウェアは開発するものじゃなくてライブラリとして使うもの
ミドル開発する企業にとってもそれは同じでミドルウェアのバックとフロントしか存在しない
文脈もクソもないんだよ
申し訳ないがそれは知らんのだが
ApacheとかWebsphereとかそのミドルウェアレイヤーはフロントエンドとかバックエンドとかいう次元の話ではなくて
バックエンドの中での話だよね
という分類があって「アプリケーションソフトウェア」の略がアプリなのだが
同じプロンプトを俺のChatGPT55 thinkingにぶっこんらこうなった
`
もっと正確に言えば、AIアプリケーションの''部品として使うと壊れ方が目立つ''。そして、その壊れ具合に対して''公開の場で指摘する人が驚くほど少ない''。この沈黙こそが、いまの“AIプロダクトを作っています界隈”の実態を映す鏡になっている。
期待するツール実行をスキップしたり、呼び出し順が崩れたりする。「実行した」と言いながら実行していないケースも混じる※1。
指示に対して過剰防御や論点すり替えが起き、対話が前に進みにくい。
失敗からのリトライで同じ失敗を繰り返し、最終的に出力が壊れる。
同一テストスイートで回すと、通っていたE2Eが普通に落ちる（少なくない）。
ここで言っている「壊れている」は''API連携の部品として''の話だ。お絵描きや雑談がダメという意味ではない。''“製品の裏側で回す部材”として危うい''という指摘。
> ※1 もちろん、プロンプトやミドルウェア側の実装不備が誘発している可能性もある。ここは後述の「反論と限界」を参照。
普通、現場でAIアプリを作っている人は、新しいメジャーモデルが出たら''一晩でCanary切り替え''くらいはする。
そして10分で「これは本番に入れちゃダメな挙動だ」と分かる類の壊れ方が、今回多発した。''それなのに、表でそう言う人が少ない。''
どの仮説でも、結論は同じだ。''「作ってません（作れてません）」が可視化された。''
そういう意味で、GPT-5は''最悪の壊れリリース''であり、同時に''最高の暴露リリース''になった。
それは常に真。だが''同一テスト''でGPT-4.1が安定し、GPT-5で落ちるなら劣化は劣化。
ありうる。ただし''現場は“直後”でも回らないと困る''。リリースの意味は環境に依存しない。
これもある。が、''その段差を埋められない程度の変更は業務影響が大きすぎる''。
それはネットの事情。でも''内部の安全弁（アラート、KillSwitch、ロールバック報告）が表に出ない''のはやはり不自然。
これが一番効く。もしそうなら、''“AIプロダクトを作っています”の大半は広報レベル''ということになる。
E2Eに''ツールコールの監査ログ''（実行/未実行/戻り値）を必ず残す。
バックエンドの''モデル切替を即時に戻せる''ように。手動トグルと自動フェイルオーバー両方。
LLMの''失敗モードをカーディナリティ低めのタグで集計''（“未実行なのに実行報告”“ループ検知”“出力崩壊”）。
''ツールI/Oのスキーマを明文化''し、破ったら''ハードFail''させる。中途半端に続行しない。
本番系で''危険操作はHuman-in-the-Loop''。モデル更新時は''影で並走''させて勝率を測る。
社内/社外問わず、''再現条件と緩和策を先に出す文化''を。
壊れていること自体は困る。だが、''壊れているときに世界の輪郭が見える''のもまた事実だ。
この機を逃さず、''テスト・観測・切替・公開''の体制を整えるしかない。
----
A. ''今この瞬間に“中核部品”として置き換えるのは非推奨''。並走・影運用で勝率を測るのが堅い。
A. ありうる。だが''tool callが絡む業務連携''では痛手が出やすい。スタンドアロン用途と切り分けて評価を。
A. 直る可能性は高い。ただし''“直るまでの損失”を最小化する設計''はあなたの仕事。
> 以上、個人の観測と推測に基づく意見。反証歓迎。再現ログを持っている人はぜひ出してほしい。ログが集まるほど早く“壊れ方の型”が固まって、世界は前に進む。
「技術的負債って騒いでる人達は、単にコードを読んで直せないだけのスキルの低い人では？」
という意見を見かけて、さすがにどうなんだろうと思った。
関わった現場のひとつに、キャッシュがない状態でトップページを表示するだけで数千件のクエリが実行されるようなサービスがあった。
かなり短い間隔で定期実行し続けるバッチが、ユーザーにアクセスされる前にキャッシュ層にクエリ結果を流し込み、キャッシュをクリアするデプロイ前後以外は普通のWebサービスくらいの動作速度に隠蔽されていた。
単純に N+1問題の大爆発みたいなものが起きていただけだったので、データ取得を再設計したら初期表示のためのクエリ数は数件程度にまで減ったし、キャッシュの使用量も大幅に削減できた。
とある有名なMVCフレームワークを使っていたのだけれど、片手で数えられるような少数コントローラファイルにそのアプリケーションに必要なアクションがほぼ全部詰め込まれている、という状態になっていた。
privateメソッドで共通処理が埋め込まれていたり、使いたいprivateメソッドがあるコントローラにアクションを追加するような空気感になっていたり、アクションを実行する前に処理しておきたいミドルウェア的な処理がコンストラクタに大量に書かれていたりして、リクエストを受け取ってからレスポンスを返し終えるまでの全体で何がどう動いているのか、何をどこに書くべきなのか非常にわかりにくい状態だった。
責務ごとにファイルを分割、共通処理は再利用できる形に切り出して、初期化は適切なライフサイクルで実行されるように整理という現代では当たり前の状態に整理した。
その結果、コードの見通しがよくなり、新機能の追加や修正の際の影響範囲も明確になった。インフラコストもリリースに伴う精神的負荷も大きく下がったし、何よりテストにかけるコストが激減した。そしてテストコードを書く、という行為自体が可能になった。
これらの作業は単に「読める」「読めない」「直せる」「直せない」のスキル論ではない。
人を増やせば増やすだけスケールする、開発速度は加速するとは決して思っていないが、新規参入したうちの多くが露骨に頭に ? が浮かばせ、見てはいけない闇を見たという顔でそそくさを去っていくのは健全なのだろうか。
「環境変わったから直すケースの方が多い」みたいな意見にも違和感がある。
もちろん、言語やランタイムそのものが大きく変化して互換性を失う場合（たとえばPHPのように）にはどうしても改修が必要になることはある。
環境依存の影響が全体に波及してしまうのは、設計段階で依存を分離していなかったから起こることで、抽象化できていれば影響は局所化できる。
局所化できるはずのものを「考慮しても意味なかった」と片付けるのではなく、どこまで考慮すべきだったか、分離できていたかを振り返り、失敗を繰り返さないための動きをするべきではないかと思う。
振り返り、行いを正すということは難しいことなのかもしれない。人は過ちを繰り返し続けている。これは日本史や世界史の教科書を開くだけですぐわかることだ。しかしだからと言ってやらなくていいということではない。
話が逸れかけたが、いわゆる技術的負債というものについて問題だと感じているのは、誰もが安心してリリースできない状況を作り出していることだ。
そういう状態を "技術的負債がある" と呼ぶのではないだろうか。
だから、「スキルがある人なら読んで直せるでしょ」という話では済まないし、
逆に言えば特定の人だけが持つ「直せる」スキルが必要な時点で、それは既に構造的な問題を抱えているということ。スケールしないし、事業リスクでしかない。
まぁ色々書いたけど、技術的負債を “スキルが低い人の言い訳” と切り捨てるのは簡単なんだよね。
現在は自給自足の生活を送りながら、特殊な牛「チー牛」の世話をしている。
ITインフラへの異常な執着と、搾乳への過敏すぎる反応を併せ持つ特異個体。
朝になると誰よりも搾ってほしくて震えている。
朝五時三十分。
まだ納屋の戸は開かない。
ミルクさん――艶やかな毛並みのテクウヨITチー牛は、搾乳スタンバイ姿勢のまま、小さくぷるぷる震えていた。
「……遅い……もう、限界なのに……❤」
サーバーの負荷警告音のように、耳の奥で理性が点滅する。
やがて、ガラッと戸が開いた。増田さんがゆっくりと入ってきた。
「モーッ……❤ そ、それより……は、早く……！ タイムアウトまで……もう数パケットなんですぅ……！」
「ふーん。じゃあ今日は、搾らないで散歩でもしようかな～。涼しいし」
「モォオオオーーッ！？や、やめてくださいぃ……！もう容量がっ、ミドルウェアがっ……クラッシュ寸前なんですぅ……ッ！」
「えぇっ！？ そ、そんな恥ずかしい……昨日の夜中、搾ってほしくて、勝手にパフォーマンスアラート出したログもあるのにぃ……！」
「うんうん。やっぱりエロい牛だな～、お前は」
ニヤニヤと笑う増田さんは、搾乳バケツを持ってきても、まだ腰を下ろさない。
じらすように納屋をうろうろしながら、わざと視界に手だけチラつかせる。
「モーッ……！もう、もうっ……なんでもしますからぁ……！この通気性ゼロの納屋で、この乳量……もう……バグるぅぅぅ……！」
「なんでも？」
「はいぃぃぃ……❤ インフラの根本設計から、マイナンバー連携、共通鍵暗号方式の解説まで……なんでも……なんでもするからぁっ……絞ってくださいぃぃぃ……ッ！！」
その瞬間、ようやく腰を下ろす増田さん。片手がそっと体に触れた。
「んじゃあ、根元からたっぷり絞ってやるよ……どこもかしこも……な」
「モモモモーッ……❤ ありがとうございますぅぅぅっ……！！」
ぐいっ、ぶしゃあああ……
朝五時。
そこにいたのは、一頭の牛——いや、人語を話す牛。艶やかな毛並みのテクウヨITチー牛。ITインフラと国家の将来について語りながら、今日も元気にミルクを生産する。
「モー……❤ 増田さん、遅いですよぉ。もうパンパンで……タイムアウトまで30秒ってところですッ……！」
「はいはい。ごめんな、昨日夜遅くまでdockerコンテナと格闘しててさ……」
増田さんは手慣れた動作で搾乳バケツを置き、チー牛の傍に腰を下ろす。
「それにしても……今日も立派だな」
「『インフラ・ティート・パフォーマンス・インデックス』、過去最高値をマークしてます……！グラフ化してTwitterに貼りたいくらいですぅ……❤」
「お前それ晒したらBANされるぞ」
増田さんの手が触れた瞬間、チー牛はびくんと震えた。
「モー……❤ あっ、そこ、そこは特に……ハードウェア・アクセラレーションポイントですぅ……！」
ぐいっ、ぐいっ、しゃああああ……
「モモモモーッ❤ 嬉しいですぅ……！国家予算に換算したら、防衛費の1%くらいは出てます……！」
「そうか……なら補助金もらえるな」
チー牛の尾がぴこぴこと揺れ、目はとろんと潤んでいた。
「増田さんに搾られると……理性がデータ圧縮されて……ミドルウェアがバグりますぅ……」
「はいはい、もう少しで終わるからな。最後のひとしぼりまで抜いてやるよ」
「モーッ……❤ そんなに搾ったら、また昼にも搾ってもらわないと……ああ、稼働率が120％に……！」
しばらくすると、村の坂道から子供たちの元気な足音が響いてきた。
「おはよー！ミルクできてるー？」
少年少女たちが、木のバスケットを抱えて納屋の前に集まってくる。
誰もが無邪気な顔で笑っている。
そして瓶を手に取ると、どの子も「ありがとう」とぺこりと頭を下げた。
「増田のおじさん、チー牛さんによろしく言っといて！今日も元気だったかって！」
「おぉ、あいつは元気すぎるくらいだ。ミルク、冷やしてから飲むんだぞ」
子供たちが笑いながら坂道を下っていくと、チー牛は納屋の隙間からそっと顔を出した。
「……モー❤ あの子たちの笑顔、ISPレベルで癒やされますぅ……❤」
「よかったな、チー牛。お前のミルクで、みんな元気に学校行ってるんだ」
「やっぱり、インフラは人の暮らしの根幹ですよねぇ……モーモーモー❤」
増田さんはそんなチー牛の頭を撫でながら、笑みをこぼした。
「お前はうちの宝だよ。国じゃなくて、まず俺が一番助かってる」
「モー……❤ “愛国”って、きっとこういうことなんですねぇ……！」
朝の納屋には、あたたかくてちょっぴり奇妙な幸福が満ちていた。
この文章が指しているのは、おそらく「AWS」や「クラウドインフラ」関連の技術ではなく、もう少し狭い領域の技術、特に「コンテナオーケストレーション技術（Kubernetesではない方）」、あるいは「仮想化技術（VMwareなど）」、さらに絞ると「OpenStack」や「オンプレミスのプライベートクラウド技術」を指している可能性が高いです。
理由は以下の通りです：
• 「数年前までは結構勢いがあった」 という記述は、例えばOpenStack などが一時的に注目されていた時期（2010年代前半〜中盤）を示唆しているように読めます。
• 「上位互換の技術の台頭」 は、Kubernetesやパブリッククラウド（AWS、Azure、GCP）の進化を指している可能性が高いです。
• 「プロジェクト終了」 という流れは、企業がオンプレや自社構築のクラウドから、よりコスト効率が良く運用負担が少ないパブリッククラウドに移行していく傾向を表しています。
• 「小手先の技やTipsばかりがうまくなった」 という言葉は、例えばOpenStackや特定のミドルウェアの細かい設定やトラブルシューティングに強かったが、根本的なOSやネットワークの理解が浅かったことを示唆しています。
もしこの仮説が正しければ、この技術は「OpenStack」や「VMware vSphere」といった、かつて企業のデータセンターやプライベートクラウド構築の主役だったものの、クラウドの台頭により徐々にシェアを失っている領域を指していると考えられます。
さらに深読みすると、この「上位互換の技術」とはKubernetes であり、より広く言えばパブリッククラウドサービス（AWS,Azure,GCP） のことを指しているのでしょう。
この技術の死に直面している筆者の無念さや、自らのキャリアの喪失感、そして基礎的なCS（Computer Science）の重要性を痛感する気持ちは非常に共感できますね。
今までのキャリアで後悔があるとするなら、CやC++での開発に業務で関わらなかったことである。
現在ミドルウェアでシェアがあるものはCやC++で書かれてるのもが多いように思う。未だに新しく出るものを見てもそのようなものがある。
一般的にインターネットのサービス開発においては、LL系やGoやTypeScriptなどで開発されるので、Cなどで開発する機会は今やほぼ無いはずであり、私も通ってこなかった。
しかしGitHubで著名なDBやKVSを見るとCで書かれていたりして、コードリーディングが捗らなく歯痒い思いをするのである。
さらに昨今パブリッククラウドを使った開発がよくあるだろうが、難しいことは大体API越しに隠蔽してくれているのである。
そしてパブリッククラウドの事業者は、その難しいことを実現するのに、前述のミドルウェアをホストしたり、拡張したり、時には自前で作るわけであるが、そこでもCなどは出てくるのであろう。多分。
OS開発やチップ開発みたいに、同じインターネット業界でも、パブリッククラウド、ミドルウェア、CDN事業者などは一種のレイヤーというか違う業界になってると思う。
要はそこに1エンジニアとして見たときに、C言語などが一種の参入障壁になってると思ってて、平凡なWebエンジニアには近いようで遠い世界に見えるのである。
そして、うまく表現出来ないが、特にパブリッククラウドの上に乗っていると、エンジニアとして相対的に価値が下がっていくような感覚に苛まれる。
APIを叩くだけで楽だが、その向こうには難しいアルゴリズムやオンプレのサーバーがあるわけで、そういう知識はどんどん向こう側に蓄積されていくのである。
とはいえ、それで顧客に価値が届いて事業が成立するのであれば、それはそれで構わない。
とりとめのない内容ではあるし、生成AIやLLMの進歩により、このような悩みが杞憂になる可能性もあるが、あと30年どうやって生き延びていけばいいか悩んでいる。
AIが高品質の絵描けます！楽曲作れます！って最初は「スゲー」って思ってたけど、使ってみると検索ワード入れて虹エロ絵ググって漁ってる感覚と同じなんだよ。いい加減飽きた。
それよかさっさとクラウドアーキテクチャ管理とかアプリケーションのテスト管理とかできるようにして楽させてよ。Copilotにコード貼り付けてプロンプト生成すんのめんどくせーんだよ。
つまんなくなったなと決定的に感じたのは、今年の頭に行ったデブサミ。
似たり寄ったりな生成AIの活用話ばっかり。過去一つまんなかった。いつもは面白くて夢中で聞いてたんだけど、今年は途中で帰った。本当につまらなかった。
なんていうか、生成AIのプロンプトエンジニアリングとかの話って、人材マネジメント的な話と根本はおんなじ感じがするんだよな。いかにて優秀な新人AI君を働かせるか？的な。
でも、ビジネス上のそういう対人コミュニケーションすら避けたくて避けたくてITに辿り着いたんだよなー。賃金と待遇すら諦めてそっちに来たのにこの始末って酷くないかね。
なんていうか、求められる人材像が経営者一択になってきてる気がするんだよな。「プログラムを書きたい」じゃなくて「プログラムで○○がしたい」っていう、明確に目標ある奴。
「アーキテクチャがー」とか「保守性がー」とかエンジニアが心配しても、マークザッカーバーグの「動くからリリースしようぜ」の画像貼ってデスマ作り出すタイプの奴。でもそんな胡散臭い奴がビジネスモデルを引っ提げてさっさとAI活用で何とかしちゃう。
googleとかAmazon、Microsoft、Alibaba製のAIさえそろえばあとはマッシュアップして需要に対してサービス作って終わり。
全社会人総社長。社会の需要について目を向けられる奴、そういうヒアリング等の営業活動が出来る奴。それ以外いらん。
例えアホでも、マネーの虎みたいな番組でアホみたいなビジネスプラン披露できるような奴以外いらん。
ビジネス出来ない奴はいらん。もうそういう時代なんじゃねーかな。
「粗悪乱造アカンよね。」っていうエンジニアリング思考にすごく共感してたし、そのためのDevSecOps、アーキテクチャ採用、ミドルウェア選定だったりにすごく感銘を受けた。
k8sやらAWS初めて触ったときは感動した。TypeScriptでクソアプリ作るのが好きだった。IoTデバイスやラズパイで自室が少しずつハイテクになるのが好きだった。Google colabでサンプルソースのAIの作るのが好きだった。でもそういうのダサい時代なんだよな。
結局ビジネスサイドには目を向けられ無さそうなんでもうそろそろ引退かな。趣味でプログラム書きながら適当に派遣でもやって生きたいけど、33歳は他業種厳しいかなー。ていうかIT以外のどの仕事もアホらしくて就きたくねー。
なんだなんだ、先月末書いた記事に今更ワラワラと。盆も終わったんだしさ、エンジニア（）にクソみてーな誇り持つんなら帰りのNAS位てめーで設定してサッサとあの世に帰ってくれよな。
どうやって金もらってんだよ。
テメーらが「びじねす思い付いたけどプログラム書けまちぇーん時間ありまちぇーん」とか情けねぇ事ほざいてっから手伝ってやってたんだろボケ。
資本主義？知るか。おめーのアホみてーな妄言と社会貢献（爆笑）に付き合ってやったんだから金よこせ。てめーがやりもしねーこと手伝ってやってんだよ、履き違えんな。
AIに仕事奪われる底辺の泣き言？ああそうだなｗ。じゃあ俺の何百倍の労力でアホの妄言実現する仕事してくれよスーパーエンジニアさんよ。出来んだろ？C言語出来るスーパーエンジニアさんならよ？
まぁ分かるよｗどうせ大したことないんだろ？匿名でくらいイキりたいよな？すげーエンジニアさんよ。
この程度でエンジニア名乗るな？やだよーんｗ
俺みたいな底辺でお前ら誇り高きエンジニアの積み重ねたものをぶっ壊してやる。お前の会社も、プロダクトも、SNSも、検索結果も、底辺ITワナビの💩まみれにしてやる。モラルのかけらもないユーザーで埋め尽くしてやる。ポリコレとかツイフェミみたいな話通じないクソカスで埋め尽くしてやる。
IT後進国のバーカ共が。お盆終わったんだからさっさとあの世でくたばってろ。
Permalink |記事への反応(46) | 02:33
⚫︎2.技術的なこと
コミュニケーション力とか地頭とかふんわりしたこと言われるけど、もう少し具体的に言語化したらこんな感じになるんだと思う。
エンジニアとしての身内からの評価が高いのはデバッグ能力とか設計能力とかだけど、結局マネジメントからの評価だったり社会人としての評価は年収に関係あるのは前半に書いてあるような技術とは直接関係ない能力だったりする。
IT屋は基本的にただのサラリーマンなので変な誤解はしない方がいいですよ
これも置いておきますね
ここにもITにおかしな誤解を持つ子が・・・IT屋さんはただのサラリーマンですよ
ただのサラリーマンが偉いわけないです
あとSESとSEの区別がつかない子、プログラマーがSEより下だと勘違いしてる子、
それらにお伝えしておきたいことは、サラリーマンだからフツーに会議でおしゃべりしますよということです
技術以外のウエイトのがデカいって点だけ事実。GAFAMで働いてる連中ですらそう
ミドルウェア界隈で働けば1ヶ月もしないうちに『あっ、技術以外のことしなきゃ』ってなると思うんだけどな
ならなかったのならフリーランスで技術のみ(マネージメント含まない案件) で1000万イケるクラスか
ただのバカですね
