  |
はてなキーワード: デプロイとは
これは私自身が、また私以外の業界から転職されてきた方々を見てきて、これではないかな？と思うことがあります。
それはプログラマー以外の仕事は、常に本番環境である、ということです。
たとえば営業であれば、取引先との打ち合わせも見積もりも、ひとつひとつが「本番」です。やり直しはききませんし、次の瞬間には社外の人の評価や信頼がかかっています。接客や教育、医療、建築…どの仕事もそうです。人や社会に直接つながっている以上、テスト環境など存在しません。常に結果が「本物」として記録されていくのです。
その点、プログラマーの世界は少し違います。そこには「テスト環境」があり、「デプロイ」という明確な境界があります。エラーが出ても、まずはコードの中で直せばいい。実験と修正を繰り返しながら、本番に近づけていける。失敗から学ぶ仕組みが、仕事の構造として組み込まれているのです。
もちろん、だからといってプログラマーが気楽だという話ではありません。むしろ「テストできる」ことが前提だからこそ、完璧なシミュレーションを作り上げる責任が生まれます。本番環境を一歩でも誤れば、大きなシステム障害につながることもある。
けれど、「試すことが許されている」という点で、プログラマーの仕事は他の仕事とは質的に異なる、と私は感じます。多くの職業では「やってみること」そのものがリスクになるのに、プログラマーだけは「やってみること」が日常の一部として制度化されているのです。
たとえるなら、プログラマーの仕事は「楽屋のある職業」なのだと思います。
多くの仕事は、目を開けた瞬間からステージの上に立たされるようなものです。接客業ならお客さんの前に立った時点で本番が始まっていますし、教師なら教室に入った瞬間に舞台袖はありません。間違えば生徒が戸惑い、客が離れ、取引が破談する——それらはリハーサルのない一回きりの公演です。
一方で、プログラマーは楽屋での準備が長く、ステージに出る時間は驚くほど短い。コードを書く、テストする、修正する。その多くは「誰にも見られない暗闇の中」で進んでいきます。そして、いざデプロイという名の本番を迎えるときには、すでに何十回ものリハーサルを終えているわけです。
そう考えると、プログラマーの面白さは「安心して失敗できる時間」が保証されていることかもしれません。社会の多くの仕事が「失敗しないための緊張」で成り立っているのに対し、プログラマーは「失敗を前提とした反復」で完成に近づいていく。
この違いは、単に働き方の差ではなく、「世界との関わり方の構造の違い」にまで広がっているように思うのです。
その境界線こそが、プログラマーとそれ以外の仕事を分ける根本なのかもしれません。
プログラマーの失敗は、基本的にログに残ります。誰が、いつ、どんなエラーを出したのかが正確に記録されます。でもそのログは、「修正可能な痕跡」であり、「過去をなかったことにできる記憶」です。失敗は恥ではなく、改善のためのデータとして保存される。むしろ失敗を残さない方が恐ろしい——なぜなら、それは検証も再現もできないバグだから。
一方、他の多くの仕事での失敗は、ログではなく「印象」として残ります。顧客の言葉、上司の記憶、誰かの評価。修正パッチは配信できませんし、「新しいバージョンをリリースしました」と言っても、その印象が上書きされるとは限りません。世界が自動でキャッシュをクリアしてくれることはないのです。
だからこそ、非プログラマーの人々は無意識のうちに「失敗を避ける設計」で働くようになります。完璧に準備してから発言する、波風を立てないように動く、見せ方に細心の注意を払う。彼らの本番環境には“try-catch”構文が存在しないのです。
一方で、プログラマーは「例外処理」を書くことを前提に思考する。すべての失敗を想定し、起こり得るエラーを受け止める枠組みを最初から組み込む。そこには、世界を「壊れ得るもの」として見る柔軟さと、「壊れても直せる」という信念がある。
その考え方の違いが、やがて人の思考様式や言葉の慎重さ、さらには生き方そのものにまで影響していくのではないか——そんな気がしています。
覚えておいてください。これから踏み出す世界には、「実行ボタンを押す前にコンパイルしてくれる親切な仕組み」はありません。人の言葉も、会話も、メールも、一度送ったら基本的に戻ってきません。Undoはありませんし、Gitもありません。世界は常にmasterブランチで動いています。
ですから、まずはその“冗長な曖昧さ”を恐れないでください。コードの世界ではif文で整理できたことが、現実の人間社会ではあいまいなまま動いています。それを「エラー」だと考えないでください。人間は仕様書なしで動いているシステムです。バグだらけで当たり前なのです。
現実の世界では、修正にも時間がかかりますし、再デプロイにも人の気持ちというプロセスが関わってきます。あなたが「パッチを当てました」と言っても、相手の心がそれをすぐに適用してくれるとは限りません。
ですから、焦らずに。ログを読むより、人の表情や沈黙を読む方が大切になります。
そして何より大事なのは、「テスト環境がない」という世界でどう生きるかを考えることです。
あなたの言葉は、すべて本番環境に直接デプロイされます。その恐ろしさの裏側には、同時に大きな自由もあります。本番だからこそ、本気が伝わります。人間関係も仕事も、常にリアルタイムで最適化されていくのです。
プログラマーらしい慎重さと、非プログラマー的な即興性。その両方を持てる人は、なかなか多くありません。もしあなたがその橋渡し役になれたなら、どんな職場でもきっと大きな価値を発揮できるはずです。
世界はtry-catchのないシステムです。しかし、恐れることはありません。catchできない例外に出会ったときこそ、人は成長します。これからのあなたのフィールドには、テスト環境の代わりに「出会い」と「経験」が用意されています。それもまた、悪くない環境だと思います。
生成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レビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
「教育虐待ガー」とか言ってる層って、マジで日本の教育システムを単なるブラックボックスとして捉えてるんだよね。
でも実際は、日本の教育は 競争アルゴリズムに基づく階層ソートシステム なんだよ。
入力パラメータ（学習量）を下げれば、アウトプット（進学・所得・婚姻市場ポジション）が劣化するのは 仕様 であって感情論じゃない。
だから「可哀想だから詰め込みやめろ」と言うのは、システムの根幹ロジックを理解せずに設定値を勝手に下げる危険なパラメータ変更なんだよ。
日本社会は
つまり教育を削るという行為は、スコアリング関数の入力値を意図的に下げるのと同義。
当然、最終アウトプットは弱者男性という低スコア領域に落ち込む可能性が跳ね上がる。
これを下げた瞬間、
進学機会が減少（選択肢のサブセット化）
という 不可逆なデグレードが発生する。
これを回避するには、インプットを削らないのが最も効率的なんだよ。
まるで、性能要件を理解しない非エンジニアが、「その処理重くない？」とだけ言ってくる感じ。
それは 数千万〜数億円規模の長期的機会損失 という隠れたデフォルト・リスク。
でも外野はただの**無責任ノイズ（noise）**を発してるだけで、何ひとつ責任領域を持たない。
損失補償者（compensator）
意思決定権者（decision owner）
が一致している必要がある。
しかし「教育虐待ガー派」は意思決定に関わるくせに、リスクも損失も負わない。
これ、システム開発なら完全に アンチパターン（責任分離の破綻） なんだよ。
「サラリーマンの平均生涯年収3億円」はよく語られるけど、教育量の削減によって階層ダウンした場合、これは普通に大きく失われる期待値なんだよ。
つまり外野が無責任に発する「可哀想」って言葉は、他人の将来資産を数億単位で毀損するトリガーになり得る。
そのリスクを認識していない時点で、教育議論に参加する資格がない。
最終的に問うべきなのはこれ。
当然、誰も取らないし、払わない。
ちょいちょい言ってるように、一般利用者のイメージからかけ離れて多い、という印象がある。
全国CMやってるようなところでも、激ヤバなところはある。
問題は、中のエンジニアのうち、上の方の連中は「俺たちのシステムはイケてる」って認識らしいってところだな。
k8s使ってる。
terraform使ってる。
×××使ってる。
でも、運用頑張ってる。
SRE頑張ってる。
QA頑張ってE2Eテストやってる。
で、障害多数。
なんでやねん w
一つ一つ、ごく局所的に観察すれば、さほど間違えちゃぁいない。
多分参考にした記事が、10年とかくらい前に日本に紹介された方法で、その当時の規模、複雑度を前提としていたりするので、現代に持ってくると、でかくて複雑な大量の設定ファイルを要求する。
そもそも整理するとか、書き直すという言葉が、彼らの辞書には存在しないのかもしれない。
ともかく、規模がデカくなると、そのままの延長で通用しない、という常識が通用しないのだよな。
加えて、その設定ファイルをきっちり書かないと動かないんだが、その書かれた設定ファイルをテストする仕組みはない。
ある場所の設定変更が、他のところに影響しないという保証がない。
ささやき
いのり
えいしょう
ねんじろ！
デプロイに失敗した
みたいなことが高確率で発生し、DevOpsだなんだ標榜していても、新機能のリリースは少ないし、古いリソースの解放はまずやらない。
楽しいわけないよな？
エンジニアが辞めていく。
取り残された連中は、次の生贄を確保するために嘘をつく。
「うちはフレンドリーですよ」
全部、嘘。
楽しいわけないよな？
で、うんこの山を積み上げるスピードを上げて、さらにプロダクトを脆弱にして、働きづらくする。
楽しいわけないよな？
それは解決策じゃない。
価格は調べたり当時から改定されていて記憶だったりいい加減です
280blocker (¥900 / 年) → AdGuard (¥4000円? / 年) → NextDNS (¥2,500 / 年) → ControlD ($40 / 年) → blocky
280blocker は企業に買われてからなんとなく使うのをやめてしまった
NextDNS は日本系のフィルタが弱く更新頻度も低い印象だったのでやめた
ControlD はよかったけどちょっと高かったのでやめた
今は VPS に blocky デプロイして家族で共有している。blocky はAdAway 記法のフィルタは使えないけどおおむね満足している。AdGuard Home を使用していた時期もあったが、重くて常用できなかった
1Password ($59? / 年) → iCloud+ (¥150 / 月) → Vaultwarden
iCloud+ は家族との共有ができないため不便が多くなり代替を検討
今は VPS に Vaultwarden デプロイして家族で共有している。今のところ満足している
ChatGPT ($20 / 月) → Gemini、Claude
ChatGPT は出始めは未来を感じ課金してガンガン使っていたが、GPT-4 の出来がいまいちに感じて他に乗り換えた
日常のあれこれは Gemini を使い、コード関係は Claude のほうがいい感じの答えが返ってくるので使い分けている
Google Photo (¥3500 / 年) → おもいでばこ → Synology NAS
Google Photo 無料時代に膨大な写真を放り込んでしまったため、有料化が発表されてから脱出するまでに時間がかかった
継続課金は嫌だったのでバッファローのおもいでばこを買ったが、アップロードした写真の日付がなぜか認識されないことが多く使い物にならなかった
Synology NAS についている Synology Photos はそんなことはなく今はこれを使用
Immich とかに乗り換えてもいいかと思うこともあるが、サポート (モバイルアプリなど) の面も考えると OSS に全部まかせるのも怖いなと思ってそのまま
Apple Music → Spotify → YouTube Music (YouTube Premium)
Apple Music がアーティストへの分配金が多いと聞いたためそれを使っていたが、Apple に端末代も出してサブスクでも課金してと金払いすぎではと冷静になり乗り換えを検討
Spotify に乗り換えたが、数年使っても新しい体験がまったく感じられないので失望して解約
今は YouTube Premium に付帯している YouTube Music を使っている。UX は過去使ってきたサービスの中でも最悪だと感じるが、音楽サブスクに金払うよりかは一回でもライブに行ったほうがいいかと割り切っている
Fastmail → NameCheap Private Email → mioセーフティメール
Fastmail は使いやすかったのだが、価格がちょっと負担になってしまい解約
NameCheap は買ってたドメインの管理してたついでに安かったので契約していたが、ドメインのトランスファーに伴い解約
mio セーフティメールは機能はスマートフォンへのプッシュとかは無く必要最低限って感じだけど、よく考えたらプッシュ来てもうざいだけだし値段なりのサービスかなと満足している
住信 SBI ネット銀行プラチナデビット (¥11,000 / 年) → 解約のみ
メインバンクだったこともあり、数年前からモバイル端末保険目当てでついでに加入していた
d NEOBANK になってしまいスマートプラグラムの改悪も発表され、見切りをつけてメインバンクを切り替え、それに伴い解約した
モバイル端末保険は結局一度も使わなかったのだが、これに関して代替が見つかっていないためどうしようかと考えているところ
(年間一万円程度なら、昨今のスマートフォン価格を考えると十年に一回程度の利用でも元が取れそうなため)
Zaim → 家族で銀行口座残高を共有したいニーズがあり (支出を家族デビットカードにまとめているため)、手軽かつ安くあげられるサービスが他に見つからない。Zaim 自体はもう創業者の方が関わっていないらしく、プロダクトとして今後新しい驚きはなさそうなのでできれば課金したくない気持ちがあるのだが
U-NEXT → 映像サブスクは大人の暇つぶしだったり子供のテレビ需要だったりで無いと困る場面が多い。y.u mobile 契約がありポイントで最新作もみられるので他は契約せずこれにしている
後半価格書くの面倒になった
昔よりは支出減らせてるかな
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
KISSの原則と呼ばれ、「複雑さを避けて可能な限りシンプルで単純な状態を維持すること」とされている。
こいつはシステムに限らず、工学的な真理で、特に物理的な制約が少ないソフトウェアの世界ではこの戒めを忘れると、とんでもなく絡み合ったうんこになって、制御不能になる。
物理的制約でガチガチに固められた建物とか機械、電化製品の場合、リード線がごちゃごちゃになってるとか配管がごちゃごちゃになってるとか、柱が歪んでるとかヒビが入ってるとか、誰の目から見ても明らかなんだが、システムの場合「一本の処理フロー」だけじゃなく、「(複数)リクエスト平面」「データフロー」「データライフサイクル」「ステート変移」「非同期処理」等々、頭の中でそれを組み立てられる人じゃないと、どれだけやばいことになってるか、認識できないんよね。
ダメダメなプロダクトだと、裏で集計バッチが動いていると、2人以上がログインするとサーバが落ちるとか、ちょっと大きめのテナントが追加された途端、2箇所からCSVファイル生成＆ダウンロードさせたらサーバが落ちるとか。
1機能1機能は「完璧に()」設計実装されて、テストもしている。
でも、こういう電脳空間を見ることができないエンジニアは、集計バッチが動いて2人以上がログインして、CSVファイルをダウンロードする、みたいな複合的な状況に対応できない。
だけど東大卒で「僕、賢いので」ってのは、現場に「追加」して「複雑化」することしかできない。
考えられない。
「僕はわかるので。
素人は黙っていてください。
彼らの「賢い」は、部分部分の整合性を、他の人よりたくさん、取れるってだけの話で、それってAI的「賢さ」なんよね。
そういうのと、スティーブ・ジョブズ的な「全体を把握する賢さ」「シンプルに実現する賢さ」を比べてご覧よ、って話。
あることを成し遂げるためにたくさんの手順を複雑に積み上げて、それを記憶していられる凄さより、全体を律する「仕組み」を作り上げられる凄さの方が、より「人間だけができる凄さ」なんだよ。
この手の人は「全体」を理解できなくて、重箱の隅にこだわることこそ「知能」「知性」だと思ってんのよな。
そういうアチーブメントテスト脳は、黙ってAI的な「反応的適用作業」に集中していて欲しい。
そういうのはプロとは呼ばない。
「技術的負債って騒いでる人達は、単にコードを読んで直せないだけのスキルの低い人では？」
という意見を見かけて、さすがにどうなんだろうと思った。
関わった現場のひとつに、キャッシュがない状態でトップページを表示するだけで数千件のクエリが実行されるようなサービスがあった。
かなり短い間隔で定期実行し続けるバッチが、ユーザーにアクセスされる前にキャッシュ層にクエリ結果を流し込み、キャッシュをクリアするデプロイ前後以外は普通のWebサービスくらいの動作速度に隠蔽されていた。
単純に N+1 問題の大爆発みたいなものが起きていただけだったので、データ取得を再設計したら初期表示のためのクエリ数は数件程度にまで減ったし、キャッシュの使用量も大幅に削減できた。
とある有名な MVC フレームワークを使っていたのだけれど、片手で数えられるような少数コントローラファイルにそのアプリケーションに必要なアクションがほぼ全部詰め込まれている、という状態になっていた。
privateメソッドで共通処理が埋め込まれていたり、使いたいprivateメソッドがあるコントローラにアクションを追加するような空気感になっていたり、アクションを実行する前に処理しておきたいミドルウェア的な処理がコンストラクタに大量に書かれていたりして、リクエストを受け取ってからレスポンスを返し終えるまでの全体で何がどう動いているのか、何をどこに書くべきなのか非常にわかりにくい状態だった。
責務ごとにファイルを分割、共通処理は再利用できる形に切り出して、初期化は適切なライフサイクルで実行されるように整理という現代では当たり前の状態に整理した。
その結果、コードの見通しがよくなり、新機能の追加や修正の際の影響範囲も明確になった。インフラコストもリリースに伴う精神的負荷も大きく下がったし、何よりテストにかけるコストが激減した。そしてテストコードを書く、という行為自体が可能になった。
これらの作業は単に「読める」「読めない」「直せる」「直せない」のスキル論ではない。
人を増やせば増やすだけスケールする、開発速度は加速するとは決して思っていないが、新規参入したうちの多くが露骨に頭に ? が浮かばせ、見てはいけない闇を見たという顔でそそくさを去っていくのは健全なのだろうか。
「環境変わったから直すケースの方が多い」みたいな意見にも違和感がある。
もちろん、言語やランタイムそのものが大きく変化して互換性を失う場合（たとえばPHPのように）にはどうしても改修が必要になることはある。
環境依存の影響が全体に波及してしまうのは、設計段階で依存を分離していなかったから起こることで、抽象化できていれば影響は局所化できる。
局所化できるはずのものを「考慮しても意味なかった」と片付けるのではなく、どこまで考慮すべきだったか、分離できていたかを振り返り、失敗を繰り返さないための動きをするべきではないかと思う。
振り返り、行いを正すということは難しいことなのかもしれない。人は過ちを繰り返し続けている。これは日本史や世界史の教科書を開くだけですぐわかることだ。しかしだからと言ってやらなくていいということではない。
話が逸れかけたが、いわゆる技術的負債というものについて問題だと感じているのは、誰もが安心してリリースできない状況を作り出していることだ。
そういう状態を "技術的負債がある" と呼ぶのではないだろうか。
だから、「スキルがある人なら読んで直せるでしょ」という話では済まないし、
逆に言えば特定の人だけが持つ「直せる」スキルが必要な時点で、それは既に構造的な問題を抱えているということ。スケールしないし、事業リスクでしかない。
まぁ色々書いたけど、技術的負債を “スキルが低い人の言い訳” と切り捨てるのは簡単なんだよね。
GitHub（ギットハブ）は、ソフトウェア開発者にとって非常に便利なツールであり、特にチームでの協力作業において大きな効果を発揮します。GitHubはGitというバージョン管理システムを基盤としており、コードの変更履歴を管理しやすく、過去の状態に戻したり、特定の変更内容を確認することができます。また、Pull RequestやIssue機能を使えば、チーム内でのコードレビューや意見交換が円滑に行えます。さらに、GitHubは世界中の開発者が参加するオープンソースプロジェクトの中心的なプラットフォームとなっており、自分のスキルを活かして貢献することも可能です。CI/CDなどのDevOpsツールとの統合も簡単で、自動テストやデプロイの自動化によって、開発のスピードと品質が向上します。加えて、READMEファイルやWiki機能を使ってプロジェクトのドキュメントを整備できる点も、学習や共有に役立ちます。このように、GitHubは個人開発にもチーム開発にも不可欠な存在であり、効率的かつ協力的なソフトウェア開発を実現するための強力なプラットフォームです。
https://mavenanalytics.io/project/38415
https://mavenanalytics.io/project/38386
コンサルとか広告、マーケティング、IT、それに物流の現場で飛び交う言葉、ホンマにええんか？
「ストラテジー」とか「ターゲット」「デプロイ」「ミッション」「オペレーション」とか、聞いてて「これって、ビジネスの話だよな…？」ってなるわ。
「PDCAサイクル回すぞ！」なんて息巻いとるけど、あれも元々は軍事作戦の考え方やで。
具体的には、第二次世界大戦中にアメリカの統計学者、ウィリアム・エドワーズ・デミング博士が品質管理のために広めた考え方なんやけど、そのルーツは
計画（Plan）→実行（Do）→評価（Check）→改善（Act）っていうサイクルが、軍のオペレーションと似とるってことやな。
でもな、疑問に思うんよ。軍隊のロジックがビジネスに役立つからって、なんで言葉まで軍事に関連する物騒なもんにしとるんや？
お客さんを「敵」みたいに見て、市場を「占領地」みたいに考えるって、ホンマにまともなビジネスなんか？
俺らがやってるのは、お客さんの困り事を解決したり、世の中に新しい価値を届けたりすることやろ。お互いに協力して、信頼関係を築いていくのが大事なはずや。
なのに、知らん間にビジネスを「戦争」とか「攻撃」みたいに捉える言葉を使っとるせいで、なんかギスギスした雰囲気になっとるんとちゃうか？
軍事用語をビジネスで使うって、もしかして俺らは、遠い国の紛争を他人事として見ながら、実はそのロジックを経済活動に持ち込んで、うっすら戦争ごっこを楽しんでるだけなんちゃうか？
なんか、モヤモヤするわ。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたの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!
失礼しました。
まとめで「問いの優先順位」が変わったと断言しておきながら、その中身を掘り下げずに済ませてしまいましたね。
改めて整理します。
⸻
哲学には「そもそも何を先に問うべきか」というメタレベルの序列があります。
要するに「それを先に解かなければ社会が動いてしまう」問いが上位に繰り上がり、逆に“悠長に考えられる”問いは後回しになる、という現象です。
⸻
| Before (旧来の問い) | After (AI時代の問い) | 変化の理由 |
| :----------------------------------- | :------------------------------------------- | :-------------------------------------------- |
| 「人間とは何か」 (形而上学的本質論) | 「AI をどう制御すべきか」 (実践的価値論) | 技術の暴走がリアルタイムで政策課題となったため。 |
| 「知識は正当化可能か」 | 「LLM の出力はいつ信頼できるか」 | 推論の透明性・検証性が倫理的インパクトと直結するようになったため。 |
| 「意識の必然条件は何か」 | 「意識の“テストプロトコル”は構築可能か」 | 動物実験や臨床倫理と同様の規制設計が迫られるようになったため。 |
| 「言語の意味は何によって成立するか」 | 「統計的言語モデルは“意味”を生成しているのか」 | 実用アプリが氾濫し、理論が後追いを強いられるようになったため。 |
| 「よい社会とは何か」 | 「AI が参加する社会契約をどう再設計するか」 | ガバナンス設計を怠ると取り返しがつかない状況になったため。 |
⸻
⸻
生成AIが絡まない領域――たとえば古典的形而上学の一部（存在のカテゴリー論など）――は、相対的に注目度が下がっただけで消滅したわけではありません。
「実践的アジェンダの影で、静かに深化する純粋哲学」 という二極化が進行中です。
⸻
⸻
生成AIの登場で「何を先に答えねばならないか」が大きく組み替えられ、応用的・検証可能な問いが哲学の最前線に躍り出た――
バイブコーディング、最近この言葉を聞くだけでキレそうになる。AIが勝手にコードを吐き出し、人間はそれを後ろから眺めているだけでいい――そんな耳障りの良い宣伝が界隈を駆け回っている。だが現場の空気はどうだ。タコツボでデバッグとデプロイに追われるエンジニアの悲鳴、無邪気にPRを投げては放置する自称エンジニアの残骸、そして毎日更新される「最強のプロンプト集」。そのすべてがクソだ。数週間前まで「これが最適解」と祭り上げられていたエージェントが、翌朝のタイムラインでは「時代遅れ」のタグ付きでゴミ箱に投げ込まれている。そのペースに合わせてプロンプト設定を書き換え、ルール設定を勉強し直し……。ようやく環境が安定した頃には次のトレンドがやって来る。インフルエンサーはAIのイノベーションを讃えるが、単に技術的負債の積み増しが高速化しているだけだ。クラウド料金とGPU時間を溶かしながら最新の呪文を追いかける――それを楽しいと感じられるのは、現場の泥を一度もなめたことのない奴だけだろう。TwitterでAIにサンプルアプリを吐かせただけの動画が10万いいねを稼ぎ、Qiitaには「たった5分でSaaSを作った」記事が湯水のように溢れる。彼らのKPIはバズであって品質ではない。コードの読解よりもサムネイルの作り込みに時間を費やし、脆弱なサンプルをSNSに放流してはドヤ顔をキメる。出てくる言葉は「やばい」「すごい」ばかり。設計思想もアーキテクチャも語られず、残るのは小ネタだけ。驚きの連打で脳を麻痺させ、その隙に粗悪品を売り逃げる手口にはもはや悪意すら感じる。問題はエモいだけのバズが終わったあとだ。生成されたJSには脆弱性が口を開け、SQLはべったりと文字列連結。テストはもちろん存在しない。GitHubにアップされたそれらが検索結果のトップに並ぶ頃、若いエンジニアはそれを正解と思い込む。やがてプロダクションにコピー＆ペーストされたとき、火の手が上がるのは自明だが、初動でウケを狙った当人はすでに別の流行語を追っている。残された現場は「AIが書いたから仕方ない」で済むほど甘くない。バイブコーディングがもたらすのは「誰でも作れる楽園」ではなく、「誰でもバグを量産できる魔境」だ。トレンドのスピードは人間の学習曲線を嘲笑い、浅い称賛がノイズを増幅し、素人コードがセキュリティホールをばら撒く。この三重苦が渦を巻き、エンジニアの精神とプロジェクトの予算を同時に削り取る。結局、泥臭いリファクタリングと継続的テスト、そして責任をもってコードを読む眼が最後にものを言う。その当たり前を忘れたまま「日本語が最強のプログラミング言語」とか「プログラマー不要論」とか唱えている限り、彼らは永遠にクソの上にクソを塗り重ねるだけだ。俺たちはAIに仕事を奪われるんじゃない。AIを信じ切った素人と、それを煽る驚き屋によって殺されるのだ。
こいつは、DDD＋マイクロサービスの扱いで、ドメインと主張するもの(なんらかの超細分化、共通化されたFunction)ごとに1サービス立ち上げてgRPCでCallとかいうのを真顔でおっ始めてしまう層と完全に被っているのだが。
同じ口で「疎結合で設計してます」っていうから、空いた口が塞がらない。
はっきり言おう。
この手の設計は
「超密結合」
です。
共通化された部分の「設定」を変えると関係している部分全てに影響を与えるし、共通マイクロサービスの仕様をちょっと変更しようとしても、それを利用しているすべてのモジュールに影響を与える。
そして、分離だけはちゃんとされているので、
「テスト容易性が圧倒的に低い」
のに、「TDDも採用しています！」って言い切れちゃう頭を疑う。
デプロイしないと検証できないし、動作がデプロイ先の設定に依存するんだから、実環境以外でのテストはアリバイづくりに過ぎない。
「設定より規約」って言われてるのは、「どう設定されているかソースや実環境のデータを確認しないとわからない」みたいな余計な認知負荷をかけるようなことをすると、巨大化、複雑化していく今時のWebサービスでは成長戦略に致命的なダメージを与えることになるからだ。
のだが、Web記事漁ることしか能がない、「イケてるエンジニア様」たちは、「設定より規約」って言葉も、その定義も知っているのに、自分が何をしているか理解できない。
反論が「ここのWeb記事に書かれてます！(ﾄﾞﾔッ」でお話にならんのだ。
自分の頭で考えろ。
意識高い雰囲気で、ここまで的外れなことをやっている組織には、本当に、本当に、本当に、呆れうんざりする。
少なくとも視覚や聴覚に関しては、望んだものが即座にAIによって生成される。
賢く、悟りを開いた（そうせざるをえなかった）者は子を持たず、自らを去勢する。
こうして、ネオAIとネオ人類の間には、ますます深い知能の格差が生まれていく。
----------
--------------
| 層 | 説明 | 主要資源 |
| コア複合体（Neo-AI + Apex Augmented）（以下、コア） | AIクラウドと脳機能拡張エリートが完全共生。自己進化ループで指数的に知能を伸ばす。 | 計算資源・エネルギー・知識資本 |
| ミドルレイヤ（マネジメント/メンテ層）（以下、ミドル） | コア複合体が設計したツールを運用・保守。知識アクセスは厳格に段階制。 | ライセンス制アルゴリズム、限定的強化学習 |
| ベースポピュレーション（Neo-Human Majority）（以下、ベース） | 生殖と基礎労働を担う。AIに依存しつつも IQ・デジタルリテラシが低い。 | ベーシックインカム、合成娯楽、監視福祉 |
| 分岐点 | 崩壊トリガ | 崩壊後の姿 |
| コアが自律目標を変更 | エネルギー制約・内部競合 | ベース層を切り離し、宇宙移民 |
| ミドル層の集団覚醒 | 知能上限突破ツールの流出 | テクノガラス片的内戦 |
| ベース層の生殖爆発 | 監視網の飽和・経済的飢餓 | Neo-AIによる強制縮減 |
