  |
はてなキーワード: ユビキタスとは
（粘液がダメなら切った爪とか抜けた髪でいいんだけども）
ナメクジは歩く。歩くとその後に粘液がかわいた、道のような跡ができる。
動いたあとの粘液なんて勝手にうまれてくるので本人はゴミのようなものだとおもっている人が多い。
しかしそのゴミからいろいろなことを読み取れる他ナメクジがいる。
他ナメクジからするとキレイな粘液は自分につくれないものなので貴重品である。
寂しそうだとかとにかく迫力があるとか、色合いを読み取れておもしろいのである。
その当時はそんなことをおもっていたかもしれないし思っていなかったかもしれない程度で覚えていない。
結局は見せるために書いたわけでもない（かろうじて空や水滴が見てくれたらよい）し
キレイといわれて騒がれるのがいやなら土の上だけ歩いて粘液を外に出さないこともできる。
とにかく自分が歩いたあとのナメクジ粘液がそういうヒョウカをうけることもあるんだなと思うしかないものだ。
そのうちナメクジ界のごく一部にはヒョウカの高い粘液をみて自分もそういうふうに歩こうとおもうナメクジがでてきた。
ナメクジは喰って寝るだけではないんだといわんばかり、
徒弟制度で代々キレイな粘液をつくりだしては体力を消耗して早死にしていく。
一ナメクジ分のナメクジ生を終わりかけたある年老いたナメクジからみると、
わかいナメクジたちのようにあれは必見だとかあなたも感想を言えばいいのにとかおもうこともない。
あるところに2匹のナメクジがいる。
Ａナメクジは生活の合間におもしろい銀色の粘液をささっと紡ぐが他人に見せたくない。
ＢナメクジはＡナメクジの粘液のきれはしをみつけてダイヤモンドを見つけたように喜んだ。
ＡがＢに話しかけたのをきっかけにすべての粘液をみせてもらうことができるようになった。
そのうちＢナメクジは粘液を出しやすい食べ物を手に入れられる環境に住んでいるので
Ａナメクジに近いとおもえる粘液（といっても長さだけで、色は金色だった）をはじめてひねりだすことができた。
Ａが「公開された粘液のサンプルは見た」とつげるとそれだけでＢは喜んだ。
でもＡナメクジはＢナメクジの粘液についてあまり好意的な評価をしないのである。
Ａは「見たよ。それ以上の評価を求められても困る」といっていた。
根本的にＡは、ＡやＢのつくる粘液には、なにも価値を認めていないのだから当然だ。
だから言葉を補うとしたって、「Ａ自身にはわからないために意味（感情面）は全くよみとれないが、
見た目でいえば○○の部分がかけているから均一に歩けばもっとキレイな粘液になるかもしれない」という技術的な指摘にとどまるのである。
粘液に含まれる感情的な色については「わからない」の一点張りだった。
ＡとＢは一匹のナメクジとしてみると縞のぐあいや好きな葉っぱなど類似性が高いので、
友人としても希有な絆を結ぶことができた。
Ａにとっては（自分で始めた話のくせに）Ｂの相づちがＡとあまりにもかけはなれていて、
Ｂとも絆をきってしまおうかとおもうこともあるようだ。
たぶんＡはＡ自身にも、他の粘液にたいしても、感情が無いわけではない。
粘体の奥にこじれた感情をおさめているのだが、それが自覚される日はもっとずっととおい。
ＢはＡにたいしてなるべく礼儀正しくマウントしないようにしているが、
ＢはＡになるべくみせないようにしているが、実は、家族をひとかかえつくってもうすぐ孫ナメクジもうまれる上に
それでいて趣味の粘液だけで評価を受けようと粘液即売会に打って出た。
Ａはそのことにあまり楽観的になれないでいる。
ＡがＢのきっかけになるようなダイヤモンド的な粘液をつくっていたにもかかわらず、
自身の粘液をまだすぐ隠したり消すことを考えると、
本ナメクジには全くもって、筋の通った、わかりやすい感情なのだろう。
しかしそれは、ほんとうのところ、○○ではなく××であるべきだ、とＢは思う。
どちらにせよ、Ａのナメ生の欠落を仮埋めできるのは年寄り化けナメクジばかりで、
機械的に「まっとう」な反応を示すユビキタスナメクジも生まれてるけれど、Ａにとっては充分な相談相手ではない。
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
実は「シンギュラリティ」とは、ある秘密組織が構築した思想浸透プログラムのコードネームだった。
それぞれの音節には、驚くほど意味深な日本語コードが隠されている。
⸻
**「人類を“技術に都合の良い存在”に変換していく計画の進行フェーズ名」**だったのだ。
それはカモフラージュであり、人類が自ら“超えられやすい形”に最適化されることこそが真の狙い。
⸻
⸻
「シンギュラリティは2045年に来る」と言われているが、その2045という数字こそが罠である。
つまり、「2045年」とは人類が最適化を完了し、“選別”が始まる年を意味する暗号なのだ。
⸻
それがすでに、「シンギュラリティ」の第一段階に“順応してしまった”証拠である。
AmazonのレビューをチャットGPTで書いてもこうならんやろ。なんやこれ
https://www.amazon.co.jp/review/R90RVQQCZVDDA/ref=cm_cr_srp_d_rdp_perm?ie=UTF8&ASIN=B00A47VS5A
龍神と七福神の仙人も良いと思います。ドラゴンボールは、地球の面積比率から計算出来ます。ロトボールは、たまにキャリオーバーする事で盛り上がるようになっていますが、数学の確率・統計も重要です。
ドラゴンクエストを特集していた少年ジャンプのゆうてい、みやおう、きむこうは、ゆうていがいないと、盛り上がりにかけます。ロト7のロトボールを、7つそろえる為には、龍神様も重要です。
桃は、安土桃山時代と桃谷商店街の活気でも重要です。桃て活気を安定させてるのが分かると思います。ドラゴンボールの悪役の桃白白は、良い文字の悪キャラで、黒い服もある天津飯に負けましたが、桃と白のイメージでも、中身の心が重要という事が改めて分かります。
太陽拳は、太陽神とある程度仲良くないとできませんが、キャプテン翼の音速のマッハシュートより上の概念の光のフラッシュシュートは、最高峰のシュートですが、より上の理想の宇宙の力に関係しなくても、この宇宙はつとまります。
天津飯の天は天界の天、天界の閻魔天の閻魔大王、神と界王の考えの上は、次元の神、時間の神です。
七福神の仙人の多い、ロトボールもあうドラゴンボールも良いと思います。セルとセルジュニアのパワーアップは、セルシードの培養とSTAP細胞とiPS細胞と同様です。
セルとセルジュニアは、細胞のセルの進化そのものです、フリーザーの名前に似ているフリーズは、フリーズドライ製法のように、フリーズで、凍らせて凍結する方法ですが、瞬間的に、零下まで冷凍することは重要です。ノーベル賞のビオンテックのメッセンジャーRNAワクチンは、電子顕微鏡で、医療器具で、ゲノム編集して、培養する技術ですが、副反応ないワクチンをより考慮するであれば、抽出方法を検討したほうが良いと思います。
役割のあるメッセンジャーRNAの mRNAが単離した時に、凍結する事で、綺麗に単離させて分離できます。そして、培養も、併用培養する場合、善玉菌のような安全で無害に近い内容が望ましいです。
そして、冷凍技術は、ワクチン保管で重要です。輸送でも重要です。新鮮で美味しい食べ物の為に重要です。スーパーマリオブラザーズも、ニュートン万有引力を考慮するとより良いと思います。スーパーマリオブラザーズの前のマリオブラザーズのフリーズと、アイスクライマーのフリーズも、評価して、副反応のないワクチンと新鮮で美味しい食べ物をまとめて、ITの最高峰のユビキタス化が進んだ戸越銀座のように、高圧ボルトの電位差のある電線は、地下の位置にしたほうが良いと思います。
スーパーサイヤ人は、スーパー野菜人も、褒めているような表現で特に良いと思います。野菜のベジタブルの名前のようなベジータのパワーアップも、野菜を褒めているようで、特に良いと思います。かりん様も、猫を褒めている事からも、動物愛護の考えで、特に良いと思います。
ダブルドラゴン、ドラゴンクエスト、パズル&ドラゴンもドラゴンの名称ですが、
上場企業のタカラバイオも、昔は、ドラゴンの名称です。エンジェルのAngelの名前のようなAngesのアンジェスもワクチン開発で重要です。セルの細胞と細胞培養とワクチンの培養量産につきまして、東京女子医大のセルシードとSTAP細胞とiPS細胞と、アンジェスとタカラバイオのワクチン量産培養も、改めて、まとめて、教科書にしたほうが良いと思います。
七福神の仙人の多い、ロトボールもあうドラゴンボールも良いと思います。セルとセルジュニアのパワーアップは、セルシードの培養とSTAP細胞とiPS細胞の進化と同様です。
00年代・10年代のMMORPGなら、NPC商店のラインナップが日によって価格変動・在庫変動する作品はかなり多く見られた。
ポイント付与のような制度があるものは思い出せないが、無駄に複雑にするだけなので有意義ではないだろう。
またNPCやその属する陣営への好感度などによって、変動とは別に割引(セール)状態になる仕組みも広く見られた。
もちろんプレイヤーキャラの商人系スキルによる割引などもあったが。
そうしたNPC商店から安く仕入れるノウハウを駆使して入荷し、それを露店やオークションシステムへ流して店売りアイテムの転売で稼ぐ、あるいは店売り品を別の地域で店売りして稼ぐというプレイスタイルが可能だったMMORPGもかなりあった。
ただ……MMORPGが廃れた今でも、その3条件を満たすゲームは巷に溢れている。
気づかないだろうか？
モバイルやブラウザゲームの大半に採用されている、ガチャシステムがそれに該当する。
この手のゲームでは、オフラインゲーム同様ゲーム内貨幣とそれを使うNPC商店が存在する。
その一方で、石を使うアイテム商店ないしガチャシステム自体も、本質的にNPC商店と大差ない形で共存している。
石の入手手段が課金のみというゲームは減っており、ゲーム内で攻略を進めることでいわゆる無償石を入手可能だ。
入手手段が有償(課金)と無償(ゲーム攻略の対価)に分かれているだけで、ゲーム内通貨を拡張したものだということが分かるはずだ。
NPC商店がゲーム内のマップ特定地点にあるのに対し、石を使う商店とガチャはUI上からユビキタスにアクセス可能という違いはありがちだが、その程度の差だ。
石商店では日替わりのもの、月替りのものがあるのが一般的だ。ガチャという名の商店ラインナップは2週間前後で入れ替わる。
同一商品について日次の価格変動があるのは比較的マイナーだが、ガチャの場合、商品であるキャラや装備の実用上の「価値」はその時々のゲーム内環境によって変動する。
また、キャンペーンによって割引されたパックアイテムや、ガチャコストの減額あるいは確率上昇というのも、セールの範疇に入るだろう。
石の入手先に関しても、初回購入で増量される権利が年1くらいで再付与されたり、現実社会の決済サービス側のキャンペーンによるセールもある。
ガチャシステムには、引く度にポイントが溜まってアイテムやキャラと引き換えできる制度が組み込まれていることも珍しくない。
ゲームの経済的リアリティを追求する諸システムは、最終的にゲーム内という枠を越えて、境界を曖昧にしていき、現実と結合して、ビジネスモデルも変化させているのだ。
