  |
はてなキーワード: パイプラインとは
いま、この転換点において、皆さまとご一緒できることを光栄に思います。同時に、私たち国内SIerにとっての責務でもあります。
本日は、世界の“秩序”の断絶、心地よい物語の終わり、そして、巨大な力を持つプレイヤーの競争がほとんど制約を受けない厳しい現実の始まりについてお話しします。
しかし同時に、国内SIerのような「中堅の担い手」は無力ではない、と申し上げたい。私たちには、信頼・安全・持続可能性・顧客の主権・データの保全といった価値を体現する新しい秩序を、実務から積み上げていく力があります。
私たちは毎日のように思い知らされています。いまは、巨大プラットフォームや巨大ベンダー、地政学リスクを背景にした技術覇権が競い合う時代であること。オープン性や互換性、フェアなルールに支えられた前提が薄れつつあること。そして、強い側が条件を決め、弱い側は受け入れざるを得ない局面が増えていること。
古典的に言えば「強い者はできることを行い、弱い者は耐えねばならない」という構図です。これは不可避だ、これが自然な競争原理だ、と片付けられがちです。そして、その論理を前にすると、私たちには「波風を立てずに合わせる」強い誘惑が生まれます。摩擦を避けるために順応する。相手に合わせれば安全が買えると期待する。
では、選択肢は何でしょうか。
1978年、チェコの反体制知識人ヴァーツラフ・ハヴェルは『無力者の力』という論考を書きました。そこで彼は、体制がなぜ維持されるのかを問いました。
彼の答えは、一人の店主の例から始まります。店主は毎朝、店先に標語を掲げる。「万国の労働者よ、団結せよ！」。本人は信じていない。周囲も信じていない。それでも掲げる。面倒を避けるため、従順さを示すため、波風を立てずに“やっているふり”をするために。そして、どの通りの店主も同じことをするから、体制は続いていく。
暴力だけではなく、人々が、内心では虚構だと知りながら儀式に参加することで、体制は維持される。ハヴェルはこれを「嘘の中で生きる」と呼びました。体制の力は真実ではなく、皆が真実であるかのように振る舞うことから生まれる。そして脆さも同じところにある。たった一人が“看板を外す”だけで、幻影にひびが入る。
いま、企業としても、業界としても、私たちは「看板を外す」時です。
---
長い間、ITの世界には「ルールや標準が機能し、相互運用性が担保され、勝者も敗者も一定のフェアネスの中で競争できる」という物語がありました。国内SIerも、その物語の上で成長してきた面があります。標準化、ベストプラクティス、認証制度、ガイドライン、そしてグローバルに広がる巨大なプラットフォーム。私たちはそれらを称賛し、活用し、その予測可能性の恩恵を受けました。
もちろん、その物語が“部分的に虚構”であることも知っていました。強い側は都合が悪いときに例外を作れること。ルールの適用が非対称になり得ること。互換性や標準が、実態としては特定のエコシステムに誘導する装置として働くこと。そして、契約条項、価格体系、APIの変更、提供地域や機能制限などが、力関係の影響を強く受けること。
それでも、その虚構は便利でした。巨大プラットフォームが提供してきた“公共財”も確かにあった。スケールする計算資源、安定した開発基盤、セキュリティ機能、グローバル展開の足場、部品としてのOSSやツールチェーン、紛争を減らす共通言語。
だから私たちは、看板を掲げ続けました。「オープン」「中立」「相互運用」「ベストプラクティス」という言葉を、実態が追いつかない場面でも口にしてきた。そして、言葉と現実のずれを大きく指摘することを避けてきた。
率直に申し上げます。いま起きているのは“移行”ではなく“断絶”です。
---
過去20年の間に、金融危機、パンデミック、エネルギー制約、半導体不足、サプライチェーン混乱、サイバー攻撃の常態化、そして地政学リスクが、極端なグローバル統合の脆さを露呈させました。
さらに近年、巨大な力を持つプレイヤーが「統合そのもの」を武器として使い始めています。値上げや課金体系変更が交渉力になる。契約や利用規約、認証・ID、クラウド管理基盤が実質的な拘束力になる。提供停止や機能制限、地域制約が、企業や組織に圧力として作用する。サプライチェーンが“突かれる弱点”になる。
「統合すれば相互利益」という前提のまま、“嘘の中で生きる”ことはできません。統合が従属の源泉になった瞬間、前提は反転します。
かつて中堅の担い手が拠り所にしてきた「みんなで決めるはずの場」も弱まっています。標準化が追いつかない。デファクトが事実上のルールになる。透明な合議より、エコシステムの都合が優先される。結果として、多くの企業が同じ結論に向かい始めています。
人材、セキュリティ、データ、クラウドの選択肢、重要部材、運用ノウハウ、AIの基盤、そしてサプライチェーンにおいて。
自分で守れない者は、交渉の選択肢がありません。ルールが守ってくれないなら、自分たちで守るしかない。
ただし、行き先を直視すべきです。全員が要塞化すれば、コストは上がり、分断は進み、脆さは増し、持続可能性は下がります。
そしてもう一つの現実があります。巨大プレイヤーが、ルールや価値の“建前”すら捨てて、露骨に取引主義へ傾けば、関係性を恒常的に収益化することは難しくなる。顧客もパートナーも、保険を買い、選択肢を増やし、分散します。これは「主権」を取り戻す動きです。かつてはルールに支えられていた主権が、これからは「圧力に耐えられる能力」によって支えられるようになる。
古典的なリスク管理はコストがかかります。しかし、そのコストは共有できます。レジリエンスへの共同投資は、各社がそれぞれ要塞を作るより安い。共通標準は分断を減らす。相補性は正の和を生む。
国内SIerにとっての問いは、「この現実に適応するか否か」ではありません。適応は不可避です。問いは、ただ壁を高くして閉じこもるのか。それとも、より野心的なことができるのか、です。
---
私たち国内SIerは、比較的早い段階で警鐘を受け止め、姿勢を変え始めました。
「日本で長く通用した前提」、つまり、既存の取引慣行や、系列的な安定、特定ベンダーとの強固な関係が、そのまま将来の繁栄と安全を保証するという前提は、もはや十分ではありません。
私たちの新しいアプローチは、いわば「価値観に基づく現実主義」です。別の言い方をすれば、理念を持ちつつ、現実に即して動く。理念と実務の両立です。
顧客と社会に対する説明責任。セキュリティとプライバシー。データの保全と可搬性。人権と安全に関わる領域での慎重さ。重要インフラを支える品質と継続性。
同時に、私たちは現実主義でもあります。進歩は多くの場合、段階的です。利害は一致しないこともある。すべてのパートナーが同じ価値観を共有するわけではない。だからこそ、目を開いたまま、戦略的に、広く関与する。世界を「あるがまま」に扱い、「こうあってほしい世界」を待たない。
私たちは、関係の“深さ”を価値観に合わせて調整します。影響力を最大化するために、関与は広く、依存は偏らせない。流動化する秩序と、その先にある賭け金を踏まえて、現実的に動く。
そして今後は、価値の強さだけに頼らず、「強さの価値」も積み上げます。
---
人材育成と採用、設計・開発・運用の標準化、サイバーセキュリティ、AI活用、検証環境、そしてミッションクリティカルを支える運用力。加えて、特定技術への過度な依存を減らし、移行可能性と可搬性を高める。
生成AI、データ基盤、ゼロトラスト、ソフトウェアサプライチェーン対策、Observability、そして重要領域の内製力強化。これらは“コスト”ではなく、交渉力と継続性を生む“資本”です。
守りは、事後対応ではなく、設計・調達・運用に埋め込みます。国内産業の裾野とも接続し、調達・開発・運用の循環を厚くする。
特定の巨大プラットフォームや単一のモデル提供者に賭け切らない。複数のクラウド、複数の実装選択肢、複数の調達経路、複数の人材パイプラインを持つ。
グローバル課題への対応も、論理は同じです。論点ごとに連携の形を変える「可変幾何学」でいきます。
データ主権では、顧客がデータの所在とアクセスを決められる設計原則を共同で整備する。
標準と相互運用では、地域・業界をまたぐ参照アーキテクチャとオープンAPIの合意を積み上げる。
AIでは、特定の覇権や特定の巨大クラウドに“二者択一”を迫られないよう、モデル、データ、評価、ガバナンスの選択肢を確保する。
これは、甘い理想論ではありません。機能不全になりつつある“建前の場”に頼り切ることでもありません。論点ごとに、動ける相手と動く。必要なら多数派を作る。そうして、将来の挑戦と機会に備える、密度の高い接続網を作るのです。技術、投資、人材、運用、文化のレイヤーで。
国内SIerのような中堅の担い手が連携しなければならない理由は単純です。設計図の会議に席がなければ、要件は上から降ってきます。席がなければ、食卓のメニューになる。
巨大プレイヤーは単独でも戦えます。市場規模、研究開発、資本、影響力がある。しかし国内SIerは違う。にもかかわらず、巨大プレイヤーと一対一で交渉し続ければ、交渉は弱い立場から始まります。提示された条件を受ける。自分たち同士で「より従順な方」を競い合ってしまう。
それは自律ではありません。従属を受け入れながら、自律しているふりをすることです。
---
「真実の中で生きる」とは何か
ここで、ハヴェルに戻ります。
私たち国内SIerが「真実の中で生きる」とは、どういうことでしょうか。
「オープンでルールに基づく、互恵的な統合」という言葉を、現実がそうでないのに唱え続けない。いまを、巨大プラットフォーム競争が激化し、統合が交渉力と拘束力の源泉として使われる時代だと認める。
第二に、一貫して行動することです。
相手が誰であれ、同じ基準で評価する。都合の良い相手の一方的変更には沈黙し、別の相手には批判する、という態度は「看板を掲げ続ける」ことになります。
第三に、自分たちが信じるものを“機能する形”で作ることです。
標準準拠を唱えるだけでなく、移行可能性を担保する設計、相互運用の実装、透明な運用ルール、監査可能なガバナンスを、合意と実装として積む。復古を待たずに、動く枠組みを作る。
強い国内基盤を持つことは、企業にとっても最優先です。分散は経済合理性であるだけでなく、誠実な姿勢を貫くための物質的基盤です。報復や圧力に脆弱な状態のままでは、理念を語る資格すら維持できない。
---
さらに、私たちは理解しています。いま起きていることを直視し、合わせて自分たちを変える決意が必要だということを。
この断絶が求めるのは、単なる適応ではありません。世界をあるがままに見て、誠実に語り、国内で強さを作り、連携して動くことです。
古い秩序は戻りません。嘆いても戦略にはならない。ノスタルジーは戦略ではありません。
しかし、断裂の先に、より良いものを作ることはできます。より強く、より公正で、より持続可能な形を。
それが、中堅の担い手である私たちの仕事です。要塞化した世界では失うものが大きい一方で、本当の協働が成立する世界では得られるものも大きい。
虚構に合わせるのをやめ、現実に名前をつけ、国内で強さを作り、連携して動く力です。
それが、国内SIerの道です。私たちはそれを、開かれた形で選びます。
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
人類の言語そのものを目的関数としてそれに対して最適化するのがLLMなのだから、人類の認知で到底不可能なことはやりようがないだろう。
一文で本質を突いている。AIの能力限界を構造的に説明している。
今よりもAIが進歩した未来では「自然言語で与えられた仕様から機械語を出力するように訓練されたAI」が出てくるかもしれないけど、そいつの内部をよく観察したら結局今日の高級言語みたいなもので思考していた、みたいなオチになるんじゃないんですかね
結論と完全に一致。内部に抽象化レイヤーが生まれるという洞察。
マシン語でエラーを吐き出されても、元となるプログラミング言語での設計がすっ飛ばされていたら、どこの何が問題なのかが照合困難で修正が困難なのが根幹な気がします。
検証・修正サイクルに意味の単位が必要という話を、実務的な観点から der 表現。
計算機科学について何一つ知らなかったとしても、ニーモニックを無作為に並べるよりソースからコンパイルした結果の方が解空間が圧倒的に小さいのだから、機械語の生成は AI 以前に単なる探索として悪手だ、というのが自然な発想だと思うんだけど。
探索空間という観点からの指摘。高級言語は制約を与えて解空間を狭める役割がある。
抽象化した方が簡潔に記述できるのはAIにとっても同じことで、そっちの方がAIも理解しやすいし、生成しやすい。現在の機械語、アセンブリ、高級言語の階層構造が崩れるとは思えない。
「AIにとっても同じ」という視点が正しい。人間向けとAI向けが乖離しないことを理解している。
「AIが直接機械語書けばプログラミング言語は要らないのでは？」的な話はみんな最初に頭を過るだろうけど、コードを出力するのがLarge "Language" Modelである以上は意味論から組み立てる高級言語の方がそりゃ相性いいでしょうね。
AIを何かgodlikeな超知性だと思っている人間が多いけど、人間にとって「機械語よりも高級言語の方が当然書きやすい」のと同様、AIにとっても「機械語よりも高級言語の方が当然書きやすい」よなぁという話
「AI向け言語は人間にも使いやすいはず」という結論と同じ方向。
CPUへの命令にまで細かく分解された機械語なんて、それが何をするための処理なのかはAI（LLM）でも大変だと思いますよ。そのCPUへの命令群で何をやろうとしているのかなんていう情報はほぼ捨て去っているわけなので。
機械語には意味がエンコードされていない、という議論の核心部分。
機械語派は抽象化の力を舐めすぎ。型なし言語はトークン削減量に対して失われる確定情報量が多すぎ。LLMが内部で型を推論したら本当にトークンが削減できるか怪しい。全能AIを仮定するなら、「人が作ったハード上で機械語を直接書く」なんて中途半端で「ハードごと最適化」くらいの夢を語ってほしい。
AIが機械語を直接書くようになるとか言っている人は、機械語にこそ真の価値があると思ってるんですかね？いかなる音声も元にせず、指示に従ってレコードに直接溝を刻んで音を鳴らす技術が広まれば、音楽がさらに発展するとでも思っているんでしょうか？
AI専用言語にせよ機械語を直接出力にせよ、人の持つ高レベルの意図や仕様、アルゴリズムを正しく反映したデータセット、意味構造が保存された対応データが存在しないから難しいというか現実的に無理よなぁ
学習データの観点から。意味構造が保存されたデータがないと学習できない。
「AI がマシン語を吐いたらプログラミング言語はいらない」系の話が出てくるのは「AIは人間の言葉より、機械の言葉の方が本当は理解しやすいはずだ」という思い込みから来ているのじゃないかと思っていて
誤解の根源を正確に特定している。
まず機械語を直接記述するメリットがない。現代コンパイラ、インタープリタは超優秀(OSや組み込みの一部だけ)。人類のプログラム資産は高級言語がほとんど。AIの学習先もそれ、よってAIは高級言語で出力するほうが成績が良い
AIが直接機械語を出力すべきか？という話題が流行っている。直感的には、動作中のAIの中身を調べると、結局はコンパイラやプログラミング言語に相当する構造が即席で構成されてそう。つまり同じことを高いコストでやる感じになり
内部に抽象化レイヤーが生まれるという洞察。mod_poppoさんと同じ結論。
意味推論がLLMの得意技なので、意味を削ぎ落とした本質の塊である機械語は理解できず、意味の羅列である高級言語こそがむしろ生成AIに最適化されている。
コンパイラって優秀だから、AIといえども生で機械語を読み書きするよりもコンパイラ介した方がいいと思うんだよな。そのくらいLLMって機械寄りじゃなくて人間寄りなんだと思う。元がニューロンの模倣だし。
高レベルになるとコンパイラの出力を疑って生成されたコードを読まないといけない状況は普通にあるので、高水準なAI生成のコードが何をやってるか理解するスキルは当面は必須だと思う
もし仮にAIが機械語を吐き出せるとしても、高速に、決定論的に、段階的に、最適に動作するコンパイラを使わず、低速で、確率論的で、逐次的で、最適な動作ができないAIを利用する意義はほぼないと思う
コンパイラとの比較で、AIに機械語を吐かせるメリットのなさを指摘。
機械語は冗長で複雑かつ非常に正確な出力が必要なので、高級言語を使って既存のコンパイラやビルドパイプラインに乗せる方がAIにとっても効率が圧倒的に良いと聞いて確かになぁと思いました。
自然言語を処理するのがLLMなので、不自然な機械語は難しいだろうね。1命令ごとに「それは何を目的とした操作か」とか文脈でわかりにくいしねぇ。
AI時代の人間の仕事は、信頼性確約（＝こういう理屈で大丈夫、と説明できること）が大きな領分を占めるだろうと推測されるので、機械語だけで良いとか言ってるやつは責任を取る気皆無なゴミ野郎です。
LLMに機械語を出力させようとするやつは「AIは機械なんだから機械語は簡単に扱える」という意味不明な思考をしてるだけなのでまともに取り扱うような相手ではない。名字が山口な人は長州方言が話せるんですよねとか言ってるくらい支離滅裂
人間がソフトウェアに「こう動いてほしい」という意図と「ソースコードがどのように変更されたか」の対応はGitHubとかに大量のデータがあるのでそれを学習すればコーディングするAIは作れる気がするけど、人間の意図と機械語の対応は学習データが全然ないからAI作れないように思う
「よく使うロジックを共通部品化する」とか「とはいえ局所最適な命令も欲しい」とかを考えると、中間言語を用意して最終的な機械語へコンパイルする、という流れは必要と思う。つまり、「AI用に最適化されたプログラミング言語」があるべき。
AIは人とのコミュニケーションをいかにスマートにするかにとんでもなく時間を掛けてきたわけで、人が直接読み書きできない機械語を出力しても意味がないよね。
AI機械語コーディング、やろうと思えばできるが普通はやらないような可読性の低いコーディング方法が多すぎて、AIﾁｬﾝに本気出されるとバグったときに修復不能になりそうな気がする
これだけAIが発展したならAIに直接機械語作らせればいいじゃんみたいな言説をたまに見るけど、それどうやって今のLLMと同じ水準まで学習するの？といつも思ってる
ロジックに従っているわけだから、ソースで想定外の挙動をした被疑箇所前後にロガーやらブレークポイントを仕込むという原始的だが確実なデバッグが、いきなり機械語を吐かれると出来ないんよ。
デバッグ実務の観点から。意味の単位がないとデバッグできない。
AIにしか読めない言語より、人類が発見的に設計したんじゃない人類にもAIにも優しいプログラミング言語・中間表現・機械語をデータドリブンに統計的に正しくAIが作るって方向に行かないですかね
AIが直接機械語吐くのは遠回りしてるだけだから無いとして、完全に人間がプログラムを読まなくなったらプログラミング言語はどう進化するのかは気になる
「無い」と断じた上で、次の問いを立てている。建設的。
プログラミング言語は人間の認知負荷、記憶量の限界、ミステイク、スパゲティコード理解できないためにあるので、AIだったら直接機械語吐くだろ。常考。
反論： 完全に逆。プログラミング言語は「人間の限界を補うため」ではなく「意味を構造として保持するため」にある。AIも意味を扱う以上、意味を表現する層が必要。「常考」と言いながら何も考えてない。
シンギュラリティ前夜 アダム（AI）が、人間には理解できないどころか、読むことすらできないコードを出力し始めた。後に判明することだが、それは機械語だった。
反論： SFポエム。「人間に読めない＝機械語」という発想が、まさに今回の議論で否定されてる誤解そのもの。AIが人間を超えるとしたら、ローレベルに降りるんじゃなくてハイレベルに登る方向。
なんかLLM界隈？では「AIがやがて機械語をだす（ので実用的にはコンピュータ言語は不要になる）」と言うと、無知だとか実情知らないとかブロックしてやるとか言われる見たいだけど。数年は無理だけど、いずれそうなると予想してる。
反論： 「数年は無理だけど、いずれそうなる」の根拠がゼロ。なぜそうなるのか、意味と機械語のギャップをどう埋めるのか、何も説明してない。批判されてる理由を理解してない。
プログラム言語って人間が扱うために自由度を削り取った結果の産物やから、AIに機械語で作ってもらって最適解であれば、現代の言語の宗教感ってほぼほぼ否定されるのです
反論： 「人間が扱うために」という前提が間違い。自由度を削ってるのは「意味を保持するため」。AIも意味を扱う以上、同じ制約を受ける。「宗教感」とか言って茶化してるけど、構造を理解してない。
「まだ」人間が安心する為では無いのですか？コンパイル後の機械語を読む人が殆ど居ない事は受け入れてるのに、将来的にAIが機械語出力する事に忌避感を感じるのは論理的とは言えません
反論： コンパイラの出力を読まないのは「コンパイラが検証済みだから」。AIの出力は検証が必要。この二つを同列に扱うのがおかしい。「論理的とは言えません」と言いながら、論理が破綻してる。
AIが機械語はけば、は数ヶ月前にメンバーと話になった。結論は、いまはあかんやろけど数年後に、もう人間が見る必要全然ないわ、となったらありうるな、となった。
反論： 「人間が見る必要がなくなったら」という仮定自体が検討されてない。人間が見なくていいとして、AIはどうやって検証・修正するの？意味の単位がない機械語で？その議論が抜けてる。
機械語って逆にトークン消費するの？お〜…じゃあLIFE3.0時代のAIは機械語ではなくAI用に最適化された人間には読めない言語で思考する、という方向性なのかな。
反論： 「人間には読めない言語」がなぜ生まれると思うのか。AIは人間の認知を模倣してるので、AIにとって扱いやすい言語は人間にも扱いやすい方向に収束する。逆方向には行かない。
中間言語不要派の言い分：AIが直接機械語を出力可能で、効率最適化が進む。人間の都合で言語が存在するが、AIなら移植性や抽象化不要で中間層をスキップできる。
反論： Grok自身が「中間言語不要派の言い分」として紹介してるけど、これ全部間違い。「人間の都合で言語が存在する」が誤り。意味を扱うために言語が存在する。AIも意味を扱う。
反論： 「うまくやってくれるかもしれん」で済む話じゃない。なぜうまくいくのか、検証・修正はどうするのか、何も考えてない。
反論： これは自虐なので反論というより…正直でよろしい。専門外だと自覚してるなら、なぜそう思ったのか掘り下げて、専門家の意見を聞く姿勢があれば良いと思う。
筋の悪い言説に共通するのは：
1. 「高級言語＝人間のため」という誤解 - 意味を扱うための構造だと理解してない
2. 「AIは機械だから機械語が得意」という誤解 - AIは人間の認知を模倣してると理解してない
3. 検証・修正の問題を無視 - 一発で完璧に動く前提になってる
結局今の問題ってイギリスの民意が旧大陸と決別しかかっていることに焦った英政府が、旧大陸と距離を置かれないようにロシアの介入を欧州の問題にすり替えてるせいなんだよね
別にこれまで小国が潰されるなんてことは枚挙に暇がないわけで、日本だってアメリカのイラク侵略・解体に協力してきた
ウクライナだってスペインやイタリアからすればガスや原油の安定供給のために泥棒を始末するだけの話に過ぎなかった
（ウクライナは旧ソ連価格で卸されていた資源をパイプラインから抜き取って転売していた国家規模の転売ヤー）
それが現在では各国の民意は煽られ、スラヴ民族同士の小競り合いはウクライナ民族主義の存亡になっていた
ロシア原油やガスは中欧の精油所にパイプラインで運ばれ、加工品はアルプスの南北へ河川や鉄道を伝って出荷されている
このルートをぶっ潰したおかげで地中海では一部原油製品の供給を外部に頼る必要が生じた
それで得するのは外の航路を持つ勢力であり、地中海勢力は影響力を削がれる
以下回答
ゲーム機メーカーが「自社ハードウェア事業を終息」し、「自社ソフトを他社プラットフォームに供給する」という方針転換を行う場合、経営・ブランド・技術・収益面などで多面的なリスクやデメリットが生じます。以下に体系的に列挙します。
🧩 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販売から撤退したら、こういうリスクを織り込んだうえでそれでも決断せざるを得なかった、という事なわけだ。
日本を代表する大企業において、50代の社員が直面する「無言の退職圧力」は、もはや例外的な事象ではなく、構造的な問題として常態化している。長年の経験と専門性を蓄積したベテラン人材を早期に手放し、その一方で育成に10年という歳月を要する未経験の新卒者を採用する──この一見不合理なサイクルは、なぜ繰り返されるのか。本レポートは、この問題の背景にある経済的力学と制度的欠陥を解き明かし、日本企業が直面する人事制度の根本課題に対する処方箋を提示することを目的とする。
この問題の核心には、見過ごすことのできない重大なパラドックスが存在する。
この矛盾した人材サイクルの根本原因は、個々の企業の経営判断ミスという表層的な問題ではない。それは、日本型雇用システムに深く根ざした「年功序列型」の賃金体系そのものに内在する構造的欠陥なのである。次章では、この矛盾を生み出す経済的メカニズムを詳述する。
持続的なリストラのサイクルは、経営の非情さの表れというより、むしろ伝統的な日本型報酬モデルに組み込まれた、根深い経済的ロジックの症状である。中高年社員の早期退職を促す構造は、短期的な財務改善という抗いがたい「誘惑」を経営陣に提示する一方で、長期的な人的資本を蝕む罠となっているのだ。
問題の根源は、多くの日本企業において、中高年社員の賃金水準が本人の生産性を大きく上回ってしまう「高すぎる給与」にある。具体的には、以下のような水準が常態化している。
この報酬と貢献の危険な乖離は、労働経済学の「レイザーの法則」によって理論的に説明できる。この法則によれば、年功序列賃金は社員のキャリアを二つのフェーズに分断する。
この報酬と貢献のデカップリングこそが、早期退職を促す構造の核心である。壮年期以降の社員を早期に退職させることが、企業にとって「膨大な利益」をもたらす財務的ロジックがここに成立する。
1. 退職金のコスト: 早期退職優遇制度では、退職金に「30ヶ月分」程度の給与が上乗せされるのが一般的である。
2. 雇用継続のコスト: 一方で、高給与の50代社員を1年間雇用し続けるための総コストは、基本給（12ヶ月）に加え、賞与、高額な社会保険料、その他経費を含めると、給与の「24～25ヶ月分」に相当する。
3. 結論: つまり、30ヶ月分の退職金は、実質的にわずか「1年3ヶ月分」程度の雇用コストでしかない。この計算に基づけば、50歳で社員を退職させることで、定年となる65歳までの残り15年分の莫大な人件費を削減できることになる。この財務的インパクトが、経営陣にとって短期的なバランスシート改善を優先し、経験豊富な人材の維持という長期的な視点を犠牲にする、強力かつ危険な誘惑となっているのだ。
しかし、この短期的な経済合理性は、深刻な副作用を伴う。かつて大規模なリストラを行ったパナソニックが、15年の時を経て再び同様のリストラを繰り返している事実は、このモデルが持続不可能であることを象徴している。この負のサイクルを断ち切るためには、問題の根源である日本の給与構造そのものにメスを入れる必要がある。
日本の賃金に関する議論は、「日本の平均給与は低い」という、統計がもたらす「罠」にしばしば陥りがちである。本章では、この誤解を解き明かし、急峻な年功カーブが一部の大企業特有の問題ではなく、日本の中堅・大企業に共通する構造的課題であることを論証する。
世間一般で語られる「低い平均給与」の根拠とされる統計データは、意図せずして実態を著しく歪めている。これらの数値は、人事戦略を構築する上で根本的に誤解を招くものであり、一種の「インチキ」と言わざるを得ない。
これらの統計からパートタイマー等の影響を除外し、フルタイムで働く男性の賃金カーブに焦点を当てると、全く異なる実態が浮かび上がる。学歴（高卒・中卒含む）や地域を問わない全国の平均値ですら、50代の平均年収は700万円に達する。これを大卒の正社員に限定すれば、さらに100万円程度上乗せされるのが実情だ。これは、日本の賃金体系が年齢と共に急勾配で上昇する、典型的な年功序列型であることを明確に示している。
では、この構造的問題はどの規模の企業に当てはまるのか。我々の分析は、明確な境界線を明らかにしている。
この分析が示すのは、この問題が一部の巨大企業に限定されたものではなく、日本の企業アーキテクチャに組み込まれたシステム上の欠陥であるという事実だ。したがって、この課題の解決策を模索する上で、グローバルな標準との比較はもはや単に有益であるだけでなく、不可欠なプロセスなのである。
日本型雇用システムの構造的課題を克服するためには、国内の常識に囚われず、海外の先進的な雇用モデルを比較分析することが極めて重要である。フランスやアメリカの事例は、日本の年功序列型とは全く異なる賃金思想を示しており、我々が目指すべき改革の方向性を明確に示唆している。
フランスの賃金体系は、エリート層と一般層でキャリアパスと給与モデルが明確に分離された「複線型」を特徴とする。
アメリカの賃金体系も、大多数の労働者においては同様の傾向を示す。中央値に位置する労働者の場合、賃金の伸びは30歳から40歳までの期間に集中し、40歳以降の給与はほぼ横ばい（フラット）となる。給与が青天井で上がり続けるのは、ごく一部のトップエリート層に限定されるのだ。
フランスとアメリカ、二つの先進国の事例から導き出される示唆は、極めて明確である。それは、「一部のエリート層を除き、大多数の労働者の賃金カーブは若いうちに頭打ちとなり、その後はフラットに推移する」という共通の原則だ。このモデルは、年齢給による人件費の高騰を防ぎ、長期的な雇用安定を可能にする基盤となっている。このグローバルスタンダードを参考に、次章では日本が目指すべき具体的な人事制度改革案を提言する。
これまでの分析で明らかになった構造的課題を解決するためには、小手先の対策では不十分である。我々が取るべき唯一の持続可能な道は、戦略的な転換、すなわち「年功序列型賃金から、成果と役割に応じたフラットな賃金体系への移行」である。本レポートが提示する核心的な提言は、この移行を断行することに尽きる。その具体的なモデルケースとして、「年収700万円での頭打ち」を一つのベンチマークとすることを提案する。
この新しい賃金モデルは、単なるコスト削減策ではなく、企業の競争力と従業員のエンゲージメントを同時に向上させる、多面的なメリットをもたらす。
この改革は、単なる賃金制度の変更に留まらない。それは日本人の働き方、キャリア観、そして社会全体のあり方を変革し、持続可能なタレントパイプラインを構築する大きなポテンシャルを秘めている。
本レポートを通じて明らかになったように、日本の中高年雇用問題の根本原因は、個々の社員の能力や意欲の欠如では断じてない。その本質は、経済成長期を前提に設計され、現代の環境には全く適合しなくなった年功序列型の賃金システムそのものにある。
この本質的な課題を前に、我々は議論の焦点を大きく転換させねばならない。「定年後の再雇用」や「中高年のリスキリング」といった対症療法的な議論から、「そもそも定年を意識することなく、誰もが安心して長く働き続けられる雇用・賃金体系をいかにして構築するか」という、より本質的な議論へとシフトしなければ、この問題が解決することはない。
真の「雇用安定」とは、単に一つの企業に長く在籍できることではない。それは、年齢に関わらず、社員一人ひとりが自らの能力と経験を最大限に発揮し、その貢献に対して公正な処遇を受けながら、社会の一員として長く活躍し続けられるシステムである。この新しい定義に基づき、持続可能で、かつ働くすべての人々にとって公平な人事制度を構築することこそ、現代の日本企業に課せられた最も重要な戦略的責務である。
きっかけは、学生時代にちょっとしたレポートでテキストの単語出現頻度を数えようとしたとき、「あれ、そもそも日本語ってどうやって単語に分けんの？」って疑問が出たところからだ。
英語ならスペースで切れるけど、日本語はそうはいかない。で、いろいろ調べて「形態素解析」って言葉にたどり着いた。
その瞬間にちょっとハマったんだよね。
辞書をもとに文を機械的に切り刻んで、品詞をラベル付けして、統計を取って、構文を推定する。まるで人間の頭の中を数理的に覗いているようで。
そこからMeCabとかJumanとかKyTeaとか、いろんなツールを触った。
Pythonでテキスト処理のパイプラインを組んだり、mecab-ipadic-NEologdを突っ込んで新語に対応させたり。
「言葉を数理で扱える」って発見が、ちょっとした中毒になった。
その頃はMosesとかGIZA++とか、ああいう統計翻訳系のツールも触ってたね。
単語アラインメントの確率モデルをいじって、「確率的に対訳辞書を作る」みたいな遊びをしてた。
とにかく、NLPの世界には「人間の言葉を数学で再現できるかもしれない」という変な魅力があった。
深層学習がまだ主流じゃなかったから、n-gramやHMM、CRFなんかが主戦場で、論文読むたびに確率式の展開を手で追ってた。
最初はPoC（Proof of Concept）しかやらせてもらえなかった。
感情分析とか、Stance Detectionとか、「この文は文法的に典型か非典型か」を判別するための言語モデルの構築とか、エンティティリンキング、質問応答（Question Answering）。とにかくNLPの典型的なタスクを一通り。
学術的には面白かったけど、現場で求められてたのは「論文再現じゃなくて、実用的な精度と速度」だった。
PoCで終わって、実装には至らない案件が山のように積み上がっていった。
あの時期、NLP業界全体が「技術的にはすごいけどビジネスには落とし込めてない」って空気だった。
でもさ、LLM（大規模言語モデル）が出てきてから、世界がひっくり返った。
正直、最初は「Transformerの延長だろ」と思ってたけど、数ヶ月で実感が変わった。
それまでチマチマ特徴量を設計して、分類器を学習して、F値を0.02上げるために夜中までパラメータをいじってたのが、全部一瞬で過去になった。
ChatGPTが出て、蒸留やファインチューニングでほとんどのNLPタスクが置き換えられるようになったとき、「あれ、今までの俺の知識、ほとんど無駄だったんじゃね？」って一瞬マジで虚無になった。
でも、そこで終わらなかった。プロダクション環境を任せてもらえるようになって、推薦システムとかパーソナライゼーションの設計をやるようになって、ようやく「ユーザーベクトルを使う」という文脈でNLPが再接続した。
単なるテキスト処理から、「テキストを媒介にして人間の行動を理解する」方向に進んだ。
埋め込み表現をベースにユーザーの嗜好を推定して、レコメンドやメルマガのパーソナライズをやる。
自然言語はもう目的じゃなくて、インターフェイスになった。そうやって初めて、「NLPがビジネスに食い込む瞬間」ってのを肌で感じた。
PoCなんてやってても金にはならん。動くシステム、回る仕組み、再現性のある成果、それを出せないと、どんなに学問的に立派でも意味がない。
でも、PoCの積み重ねがなかったら、今の設計思想もなかったと思う。無駄に見える実験が、実は土台になってる。
どう考えたってSEやプログラマよりも土方の方が必要な職業だし重宝されるべき仕事にも関わらずスタートアップのよくわからんホワイトカラーの連中の方が高給だったりするのが納得できない
というか正直ITバブルが長すぎたと思うんだよ。それだけ需要があります!ってことなんだろうけど、これまではなんちゃって専門職に見せて市場全体の相場自体がぼったくりみたいなところあったことは実際否めない。
だってフリーランス仲介サイトなどで見るSESや受託開発案件では一般的なWeb系エンジニアなら人月単価60〜80万円前後が相場だが、機械学習系やSREなど高難度のプロジェクトでは一人月100万円近くに達する案件も珍しくないんだぜ!？
あと仲介業者多すぎぃ!!例を挙げるとクライアント企業から人月90万円の発注があっても、実際に要件定義や開発を担うのは下請けの開発会社や派遣チームであることが少なくなくて、仲介業者がやるのはその橋渡しだけ。あとの実務やリスクの大半を下請けに丸投げしてるのに10〜30％前後の手数料をマージンって確保すんだぜ。ノミじゃん。ダニじゃん。一応マッチングや契約管理といった役割はあるとしたって、一次請けとしての実働や技術的責任をほとんど負わない状態での高率マージンはどう考えたって業界全体のコスト構造を押し上げる一因になってる。でも誰もここを変革しようとはしなかった。はっきりいって、そういう業界全体の空気に心底うんざりしてた。
けど今後は、大規模言語モデル（LLM）や生成系AIの普及でコード自動生成ツール（GitHub Copilot など）やDevOpsパイプラインの標準化が進めば、こうしたエンジニア単価の上限は徐々に見直されるはずだ。これこそが長らく続いたITバブルの前提を根本から揺るがす変革になるだろうなと思ってる。
頼むよAI。
今度イギリスの製薬会社が、性欲をピタッと押さえ込むパッチを出すらしい。
ニコチンパッチみたいに腕にペタンと貼るだけで、煩悩が全部蒸発するって話だ。
っていうのはまったくの「嘘」なんだけど、実際にそんなもんが出てきたらどうする？
世の中、性欲で人生こじらせてる奴が多すぎる。電車でスマホ片手にエロ広告を消すのも面倒だし、週末の夜は「彼女ほしい」と言いながらAVで自家発電大会。「風俗なんて行く金がねぇ」、「マッチングアプリでメンタル崩壊」、「女友達と飯行くだけで下心がバレる」、「結婚したけどレス地獄」。そんな毎日なら、もう全部パッチで消してくれって気分にもなる。
そもそも、性欲とやらがなければ、もっと有意義なことに脳みそ使えるんじゃないか。受験生の頃、「くだらねえ妄想消して単語帳に全集中できたら東大行けた」とか、仕事中にスクリプト組んでても、なぜか脳裏にアイドルのあの表情がフラッシュバック。「この時間が全部計算資源に変換できたらCIパイプライン爆速じゃね？」なんて考えたやつ、俺だけじゃないだろ。
でも、いざパッチを貼ってサクッと欲望ゼロになったら、空っぽのロボットになる気もする。好きな人と目が合っても何も感じない。推しアイドルの新曲MV見ても「はえー色使い綺麗っすね」とかしか思わない。そもそも金曜の夜に飲み会で変なフラグ立てることもなくなる。「恋」「ときめき」「妄想」「嫉妬」・・・こんな人間くさい情動を、ぜんぶパッチの下に封印してしまう。それで何を楽しいと思えるんだろう。
冷静に考えれば、性欲如きに踊らされる人生もどうかしてる。でも全部消してしまえば、人間社会そのものが根っこから成り立たなくなる気もする。文明の起動エネルギーを全部オフにした世界で、進化はもうあり得ない。
いっそパッチで悩みが消えてしまえば楽ではある。でも、欲望を抱えて泥臭く生きてる今が、案外悪くないんじゃないかとも思ってしまう。
※追記
この増田は、特定の企業を非難、攻撃するために書いていません、あくまでファンが外から見た話です
仕事柄、造船に関わることはありますがそれは、図面通りの物を造るという仕事で業界を俯瞰することはありません
例えば、下に出てくるJMU（Japan Marine United）は、今年の6月に今治造船の傘下に入りました
今治造船は、ぼくが増田で書いている大手造船が本当に大手だった頃、中堅と呼ばれるような規模の会社でした
それが今や日本最大の造船会社になり、IHI、住友重機、日立造船、JFEと錚々たる面子をルーツに持つJMUを傘下にしたのです
そんな今治造船の主力は、バラ積みやコンテナ船です、結果を見れば中韓と競争してでも貨物船に集中し巨大化の波に乗るのが正解だったんです
じゃあ、なぜこの増田に今治造船の話が出て来ないか、それは、ぼくの好みの船を造っていないからです
マニアやファンとの意見と言うのは往々にして業界のためにならないし、業界を語ることも出来ません、興味のないことに注意を向けないからです
これはそんな増田です、この増田は業界を反映していません、ぼくの好きな特殊な作業船をいっぱい造って欲しい、そして、出来たら日本企業がいいなってそんな話です
SEP船は（Self Elevating Platform）の略であり海底に向け足をビューンと伸ばして着底したらドーンと船体を海面より上に持ち上げる
船体が海と接しておらず、かつ足で海底に固定されているため波浪の影響を軽減しつつ作業が出来る作業船、一般的に水深60mぐらいまで対応できる
このSEP船、これまで日本には2018年に完成した五洋建設のCP-8001しかなかった
そんな中、2022年に清水建設のBLUE WIND、2023年に大林組・東亜建設の柏鶴、五洋建設・鹿島建設・寄神建設のCP-16001が完成し計4隻となる
| CP-8001 | CP16001 | BLULE WIND | 柏鶴 | |
| 基本設計 | GustoMSC | GustoMSC | GustoMSC | JMU |
| 昇降装置 | GustoMSC | GustoMSC | GustoMSC | 三菱重工 |
| 能力 | 800t | 1600t | 2500(1250)t | 1250t |
| 自航能力 | ✖ | ✖ | ○ | ✖ |
| 建造 | JMU | PaxOcean | JMU | JMU |
GustoMSCはオランダの造船会社Werf Gustoをルーツに持つ、オフショアプロジェクトで世界的なシェアをもつ会社で今はアメリカのNOV（National Oilwell Varco）の傘下、NOVのルーツはUSスチール
Werf Gustoは、日本や韓国との競争に負けて再編、閉鎖されたがオフショアに活路を見出していた
日本のJMUで建造されているものの基本設計はGustoMSC、SEP船の特徴である昇降装置もGustoMSCに頼っていた中
柏鶴は、オランダのHuisman製クレーンを使用しているものの基本設計からJMUが担当しておりほぼ国産と言っていいSEP船である
Huismanは海上や港湾で使われる大型クレーンの世界的な企業で世界最大の起重機船 Sleipnirの10000t×2のクレーンもHuisman製
日本に洋上風力発電の波が来たことで高い技術力を持ちながらも経験や実績不足から海外に頼らざるを得ない状況が改善されていくかに見えていた中での三菱商事の撤退
作業船好きなマニアに衝撃が走った、夢見た国産化の道が、造船立国日本の復活が途絶えてしまうのではないか
SEP船の建造費用は数百億円かかりBLUE WINDは約500億、近年は大型化に拍車がかかり3000tクラスの吊り上げ能力をもつものもあり1000億がみえている
20フィートコンテナを20000個以上積める、24000TEUのコンテナ船で1隻当たり330億ぐらいであり、SEP船は単価が高い
コンテナ船は同じものを何隻か造ることでコストダウンしているため単純比較は出来ないが、中韓との単純な価格競争に巻き込まれづらい利点もある
日本は、世界の建造量において中国の48%、韓国の28%に次いで15%と世界3位の座を維持しているものの価格競争に晒されるコンテナやバラ積みなど貨物船が主力で苦労している
三菱重工のように大型客船に解決策を見たケースもあったが炎上し沈没（比喩）、祖業の造船を分社化し商船から撤退という結末を迎える
Werf Gustoらに勝ち世界の頂点に立った日本は、韓国、中国に追い立てられた時FPSO（floating production storage and offloading）に手を出した
FPSOは、石油プラットフォームから石油を受け取り炭化水素の生産、処理を行ったり一時的に石油を貯蔵したりする船舶
石油プラットフォームと違い移動が可能で、パイプラインを陸地まで引く必要がないなどの利点がある
しかし、これは失敗だった
FPSOに手を出した日本の大手造船は赤字を叩き出し撤退、今は現代重工など韓国の企業がシェアを持っているが利益を出せていない
FPSOの設計は、基本的に欧州の企業が手掛け、アジアは製造のみを担当していることが多く、欧州が設計、アジアが血を吐きながら生産、欧州が運用という状況が続いてる
だからこそ、柏鶴は希望だった、外国に旨い所を持っていかれない、国内だけで完結することが出来る未来
しかし、三菱商事の洋上風力発電撤退ということで国内の洋上風力発電の勢いが小さくなれば、この未来も危うくなる可能性がある
世界最大の起重機船Sleipnirを建造したのはシンガポールの国営エネルギー開発企業Sembcorp Industriesだが
1985年に建造され一時、世界最大の起重機船だったThialfを建造したのは三井造船であるものの今世界一の船舶に日本が建造したものはない
日本の造船の技術力は高い、それは間違いないが中韓は安さだけでやっているのではなく技術力があり日本より実績がある
世界最大の半潜水式の重量運搬船BOKA Vanguardは現代重工
世界最大の積載量を誇るコンテナ船Evergreen Aシリーズは、サムスン重工と中国船舶集团有限公司
個人的に最も好きな作業船で世界最大の船舶の一つPioneering Spirit全長382ｍ、総トン数40万tはHanwha Ocean（大宇造船海洋）が建造
石油プラットフォームをそのまま持ち上げることが出来るリフト能力が最大60000t、スカイツリーの総鉄骨重量が36000t、レインボーブリッジの総鉄骨重量が48000tだからイカレテル
最近では、バージョンアップして石油プラットフォームを海底に固定してるジャケットを引き上げる能力も獲得しこちらが20000t、イカレテル
なお、上であげた世界最大の船舶たちの設計は欧州がやっている、アジアは手足でしかない、もちろん手足も重要だがやはり頭は自前で欲しい
ちなみにベルギーのJan De Nulが所有する世界最大のSEP船Voltaire吊り上げ能力3200tは中遠海運集装箱運輸が建造、クレーンはやっぱりHuisman
中遠海運集装箱運輸は傘下に川崎重工との合併企業を持っている、日本の大手造船が赤字で苦しむ中、川崎重工が堅調だったのはこれがあったからだが良いのか悪いのかは分からん
テスラの「Sr. Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | What You’ll Do | What You’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800 USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| Woven by Toyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterprise AIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | Fuyao AI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -h nowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleep as Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
- PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -h nowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleep as Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
- PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
これがただの知ったかで、無茶も良いところなんだよな
データセンターレベルの発熱（最低でも数MW）って、実はボイラーとしては『『『超巨大』』』レベルなんだよ
なんでかっていうと、北欧にはそもそも『数万世帯接続』『数百kmのパイプライン』の地域熱供給のインフラがあるから
そういうところじゃないと『『『ほとんど熱が余る』』』くらい巨大なのがデータセンターの廃熱なわけ
インフラのない日本じゃ無理、というかやっても無駄が多すぎて採算が取れないんだよな
そんなことも知らないで「海外でやってるから日本も出来るはず」って、ただ無知をひけらかしてるだけなんだよな、これ言ってる奴
ちょっと一例を計算してみると、仮に一日100MWhの廃熱があるとする（24時間で平均4MW強）
30℃弱のお湯（温水プール）ならこれで数百から一千万リットル沸かせる
25mプール数百個分のお湯だ
こんなのどうするんだよ
Twitterの「the-algorithm」リポジトリをもとに、推薦アルゴリズムを数学的に極限まで抽象化すると、以下のように表現できます。
ユーザー u ∈ U に対して、一連の候補アイテム（ツイート） i ∈ I をスコア付けし、降順に並べて上位 K を表示します。
要するに、以下を最大化する推薦問題です：
argmax{i∈C(u)} S(u,i)
ここで C(u) は候補集合、S(u, i) はスコア関数。
数千万から億単位のツイート全体 I から、まず候補集合 C(u) ⊂ I を生成。
グラフ構造（フォロー関係）や「SimClusters」「TwHIN」など埋め込みから近似。
検索インデックス（Lucene/Earlybird）による検索スコアによる絞り込み 。
数理的には、潜在空間中でユーザーとアイテムの距離または類似度 sim(u, i) が上位のものを選ぶ操作。
候補数をさらに削減。特徴量 xᵤ,ᵢ を簡易学習モデル（線形モデルなど）に入力し出力スコア：
Slight(u,i) = wᵀxᵤ,ᵢ
多層ニューラルネット＋マルチタスク学習で、複数のユーザー行動（いいね、リプライ、リツイートなど）確率 Pₖ(u, i) を予測。
S(u,i) = Σₖ αₖPₖ(u,i)
例：リプライ Pᵣₑₚₗᵧ に重み 27、著者返信あり Pᵣₑₚₗᵧ_ₐᵤₜₕₒᵣ に 75 など。
投稿者がBlue Verifiedなどでスコアを×4または×2倍。
同一投稿者続出の抑制、逆風バイアス（negative feedback）などが入る。
これは以下のような修正：
S̃(u,i) = mS(u,i)
この構成は一般的なレコメンダシステムの「Retrieval → Ranking → Filtering」の標準パイプラインと整合。
学習モデル fᶿ は特徴量集合・ニューラル構造・訓練データによって依存し、ブラックボックス的。
特徴量 xᵤ,ᵢ は埋め込み、行動履歴、文脈、信頼性指標（tweepcred）等多次元で複雑。
スコア重み αₖ は明示されるが、最適化は A/B テスト・実システムでの評価に基づく。
信頼性・安全性のルール はフィルタとして明示されるが、その詳細（具体的しきい値など）は省略・秘匿されている。
S̃(u,i) = m(u,i) Σₖ αₖ fᶿₖ(u,i)
ここで、
という、レコメンドパイプラインの抽象テンプレートに帰着します。
Twitterの「the-algorithm」は、コード構造の多くを公開しているものの、モデルパラメータ・学習データ・設定ファイルは秘匿されており、上述パイプラインの数学的な枠組みは把握できても、実際の挙動はまだブラックボックスです。
とはいえ、レコメンデーション理論の観点からは、上記の抽象モデルで十分に説明可能であり、汎用の数学モデルとして整合しています。
ファクトチェックの研究において、LLM（大規模言語モデル）を使った Open Relation Extraction（OpenRE） は非常に有望です。
実際、LLMを用いたOpenREやそれに類する技術は、近年のファクトチェックの自動化・支援の研究で注目されています。以下に詳しく説明します。
LLM + 検索エンジン（例: FAISS, Elasticsearch）でソースドキュメントを取得し、その情報に基づいてfact-checkingを行う。特にニュース記事など長文に強い。
文中のエンティティをWikidataなどにリンクし、KG（知識グラフ）上でのパス推論で検証。Graph Neural Network（GNN）などを併用。
`(premise, hypothesis)` の関係を `entailment`, `contradiction`, `neutral` に分類。高性能なNLIモデルを使えば、ファクトチェックの核にできる。
| トピック | 説明 |
| LLM + Knowledge Graph Alignment | claimから得られる関係とKGとの自動照合。 |
| 言語間の事実整合性チェック | 多言語ニュースの事実差異検出（日⇔英など） |
| LLMによるFact hallucination検出 | LLMが生成した出力に含まれる事実誤りを検出。 |
| Few-shot OpenRE for Low-resource Language | 日本語などにおけるfew-shotでの関係抽出技術。 |
そんな寝言を垂れ流す前に、その脳内の自己放尿を止めろ。現実を知らずに感情論で殴りかかるのは、ただの知的怠慢だ。
まずな、「コードを書く」と一口に言うが、AIはGPT-4以降、文脈理解、設計意図の読解、エラーログの解析、APIドキュメントの要点抽出、果てはCI/CDパイプラインの構築補助まで、実用レベルで人間の工数を削減してる。
そもそも、お前はAIが書いたコードをレビューしたことがあるのか？
エッジケースの処理、ユースケースに応じた構造の変化、リファクタリング提案までやってくる様子を見たことがあるのか？
それもせずに「書けない」などと言うのは、自分の無知を自己放尿のように撒き散らしてるに等しい。
今なお「自分の手で書かないとコードじゃない」とか言ってるのは、馬と車の比較で馬の方が魂があるとか言ってた時代錯誤の連中と同じだ。
便利になるいっぽう、様々な方面に弊害を与えると思うのですが。
皆さまの妄想をお聞かせください。
ric********さん
2010/5/6 11:45
首都圏や大都市地域ににオフィスや本社を構える必要がなくなるので、
そうなると、こうした地域の土地や不動産を担保に借入していた人々の
あまりなさそうなので、世界の経済活動(特に日本)は大幅に収縮する。
(航空機は軍事・宇宙開発関係以外は必要なくなる可能性もある)
石油燃料については、
需要そのものの低下と、どこでもドアを通じてのパイプライン軽油での
ただし、プラスチック原料としての需要は変わらないか、増えるだろうが、
ただし、こうしたことの結果として、
失業が増えるとか、消費水準が低下するとか、
そのような結果になるかどうかは分からない。
どこでもドアの普及により、新たにどのような
しかし、犯罪そのものが国際的になり、逃亡も世界中にいけることになるから、
世界中に簡単にいけるから、例えば、ニューヨークで仕事をしながら、
昼飯は信州でそば、ということもあるわけだ。ところが、そのときに、
財布の中にドルしかなかったら不便だ。円を持ってたっていいけど、
晩御飯はローマで取る予定だとなると、今度は、リラも持ってなきゃ。
となると、相当めんどくさい。
まあ、店のほうでいろいろな通貨に対応できるようになる可能性もあるが、
給料がどの通貨で支払われるか、ということによって、影響を受ける人も
今までよりはるかに多くなる。
どこでもドアでいつでもどこでもいけるとなると、
かけられなくなる)、住居もどこにも移動できるし、
買い物もどこにでもいけるので、
あるいは、そこまでいかなくてもかなり広域の
なんってったって、
どこでもドアを敵国に向けてあけておけば、
でも、これって、逆にいえば、自分の国で
かえって良くないのか？
というか、どこでもドアを開けといて、
核爆発させるとどうなるんだ？
どこでもドアは、壊れないのか？
まあ、核兵器といわなくても、
普天間基地も要らなくて、
送り込むが、みんな食い物に懐柔されて、
金政権を打倒する。。。ってなればいいなあ）
かえって、高くついたりして。
でも、あっちこっちでドアを開けっ放しにしておくと、
いろいろな動植物が出入りするようになって、
というわけで、思いつくままかいてみたが、
いずれにせよ、
なってくるだろうなあ。。。。
妄想乙
ひどい
https://www.youtube.com/watch?v=St1VqOctvnY
公開日: 2021/06/17
※本講演はUnite Seoul 2020での講演を日本語吹替したものとなります
「原神」のレンダリングパイプラインと、コンソールでのクロスプラットフォーム開発について、miHoYoのテクニカルディレクターであるZhenzhong Yiがお話しします。
【こんな人にオススメ】
・Game Developers
【得られる知見】
【講演者】
・miHoYo Technical director Zhenzhong Yi
古い資料ではあるがモバイルやコンソールのような貧弱環境でも美しい表現ができるようGPU負荷を抑えながらえげつない最適化を昔からしてきたノウハウと技術力を考えると
入社して最初の仕事は「AWS認定ソリューションアーキテクト」の資格を取ることだった。
会社の先輩はAWSアカウントの管理だけで頭を抱えていて、俺は「クラウドってすごいんだろうな」と思っていた。
甘かった。
大学時代はPythonでちょっとしたWebアプリを作るのが楽しかったのに、今はIAMポリシーとSecurity Groupの設定で一日が終わる。
コードを書いているはずが、実際はYAMLとJSONばかり書いている。
先輩（30代）は「昔はサーバーにSSHして直接デプロイしてたんだよ」と言うけど、正直それの何が悪いんだろう。
デプロイ自体は確かに自動化されるけど、その仕組みを作るのに疲れ果てる。
Kubernetes？EKS？ECS？Fargate？Lambda？Step Functions？どれを使えばいいのか分からない。
友人はGCPを使っているけど、別の呪われた世界があるだけだと言っている。
Azureの話は聞きたくもない。
懐かしい感覚だった。「git push heroku main」だけで済んだ。
こんなに簡単だったのか。
herokuの料金は高いってよく聞くけど、精神衛生上の価値はある。
最近のスタートアップでは「NoOps」とか「クラウドレス」みたいな言葉が流行っていると聞いた。
Vercel、Netlify、Railway、Fly.ioなどを使ってインフラをほぼ考えずにデプロイするらしい。
もしかして、クラウドの複雑さに耐えられなくなった開発者が増えているのかもしれない。
いや、きっと俺のスキルが足りないだけだ。「クラウドネイティブ」になるべきなのだろう。でも正直、モノリスに戻りたい気持ちもある。
きっと、単純なものが複雑になりすぎたんだ。
