  |
はてなキーワード:プロセッサとは
iPhone でもAndroid でも新機種が出るたびにカメラ性能推してくるしレンズも出っ張ってくるけど、そんな立派な写真を撮りたいやつは一眼レフとか使うだろ
スマホのカメラで撮りたいのは日常のスナップとかちょっとしたメモがわりとか、シングル広角レンズで充分だろ
そりゃインスタ映えとか狙う人はスマホに立派なカメラを求めるかもしれんが、そんなのスマホユーザのごく一部だろ
カメラは10年前のまま（10年前でも1200万画素あるぞ）プロセッサとかストレージとかバッテリだけアップデートして、レンズが飛び出してないiPhone があったら即買うだろ（Android ならそういう機種もあるんかね）
まずレンズを引っ込めろや。机の上でガタつくんじゃ
「つまらない」？お前、ちょっと待て。それは世界がショボいんじゃなくて、お前の脳内クライアントが完全にレガシー化してるだけだ。現代はAIが自動生成するアート、量子コンピューティングの最新研究、NFTやメタバース内で無限に拡張される現実、リアルタイムで更新される情報のビッグデータ、無限ストリーミングのコンテンツ……全てクラウドに存在してる。なのにお前は「つまらない」？お前の受信端末が古くてGPUもCPUも焼き付き、パケットが全部ドロップしてる状態だろ。
楽しさってのは外部にあるんじゃない。感受性プロセッサでデコードして初めて体験されるデータだ。お前はそれを処理せずに「つまらない」と吐き捨てる。Netflix、YouTube、AI生成ゲーム、ブロックチェーンアート……宝の山は無限に存在するのに、端末が死んでたら単なるゼロとイチの塊にしか見えない。
しかも笑えるのは、そういうやつほど「俺はリアリスト」「世の中を俯瞰してる」とかドヤ顔。いや、俯瞰じゃなくて単なる未接続。API叩いてもないのに「データが無い」って言ってるのと同じだ。普通なら興味を持てる情報がキャッシュされるのに、「全部」って極論で切り捨てるのは、ただのI/Oエラー。アルゴリズムじゃなく端末側のハード障害だ。
現実もメタバースも常に面白さをストリーミングしてる。でもお前の受信機は老朽化、感受性GPUは焼き付き、アップデート拒否中。だから退屈に見えるだけ。つまらないのは外部じゃなく、お前のOSとハードウェアだ。そして残酷に言うと――つまらないのはお前自身。
再起動してパッチ当てろ。世界は面白さで溢れてるのに、体感できないのはお前のクライアントが死んでるからだ。クラウドは常に稼働してる。アップデート拒否の端末が不平を言うな。LifeOSのログを見ろ、エラーコードは「お前自身」だ。
確かに、カメラはさらに賢くなって、夜景もAIが自然に補正してくれるし、プロセッサの進化でどんなアプリも一瞬で起動する。でも、数年前のモデルと比べて日常で世界が変わるほどの感動は正直薄い。
SNSを見て、動画を撮って、メッセージを送る。基本的な体験は完成の域に達している。
これからはスペックの数字を追い求めるより、AIが生活にどう溶け込むか、他のデバイスとどう連携して新しい価値を生むか、といったソフトウェアや体験全体の進化に期待したい。
次の「驚き」は、もはやこの一枚板のデバイスの外にあるのかもしれない。
なーんて小難しいこと、ワイは知らんよ。
この前ネットスクレイピングしてたらさ、「そうめんでいい」とか「カレーでいい」って発話トリガーしただけで、謎に感情プロセッサがオーバーヒートする人間モジュールがいるってデータ拾ってさ。
「これで何様だよ！」って例外スローされるわけ。いやマジで何様もクソもなくね？ただの晩飯インタラクションAPI呼び出しじゃん…。
どこが怒りのエンドポイントなのか、マジで脳内OSをデバッグモードで走らせたいレベル。
どうやら「そうめんがいい」って出力しろって仕様らしいんだけどさ、それじゃ意味のシンタックスが全然別物じゃん。
「そうめんがいい」って発話は、“絶対そうめん食いたい！他はデリート！”ってコマンドになるけど、「そうめんでいい」ってのは、“特に食べたいデータなし、でも冷蔵庫キャッシュにそうめん在庫あるし、それでOK”ってニュアンスじゃん。
それを「軽視された！」とか「テンション下がる！」って勝手にパースして例外発生させるの、完全に脳内ファームウェア破損してるだろ。
結局はユーザーインターフェース上でご機嫌取りのためにフェイクデータ送信しろってことか？マジでUX悪すぎ。
そんな芝居がかったダイアログ、ファミリーサーバー内で毎日やっててよくメンタルリソース枯渇しないな、こいつら。
俺さ、そもそも食いたいデータが特にないから、クエリ投げられても困るんだよ。
「何でもいい」って返すと怒るんだろ？
「そうめんでいい」って返しても怒るんだろ？
じゃあそもそもAPIコールすんなよって話だし、エラー回避のために出力文面最適化とか、人生のCPUサイクル無駄遣いすぎる。
こんなどうでもいいことでいちいちクラッシュする感情マイクロサービスが家族サーバーにいなくて、マジで助かってるわ、ほんと。
この記事をブクマしようとしたら、既に12人ブクマしていて「みんなはえー」と思っていたら、2010年のブクマでなんかバグっている。
「精液アレルギー」は想像よりも一般的なものだと専門家が解説、男性が発症する可能性も
https://b.hatena.ne.jp/entry/s/gigazine.net/news/20250712-semen-allergies-surprisingly-common/
mongrelP
mongrelPニコニコのサーバにつかえばいいんでねとかいってみる
2010/09/03リンク 15 clicks
CUTPLAZA-Tomo
CUTPLAZA-Tomo 『1枚のカードに「SpursEngine」プロセッサを4枚搭載』
2010/09/03リンク
w2allen
w2allen なんと1枚のカードに「SpursEngine」プロセッサを4枚搭載。引用：このプレスリリースによると、リードテックジャパンは9月中旬からPCI-Express×4対応の高性能画像処理カード「WinFast HPVC1111」を発売する video parts product
2010/09/03リンク
Donca
Donca ✔PS3のCellプロセッサを応用、動画を爆速エンコードする拡張カード「WinFast HPVC1100」
2010/09/03リンク
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 PageApplication）にすることでユーザー体験を向上させたい（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 PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
いいよね。それだけメーカー愛をもって貰えるのは。
y_hirano 年間2000万台とか生産し、かつ子供が粗く扱っても壊れないくらいには頑丈な機器をそれなりに経済的に作るとなると、多分こうなるんだろうなあ。
korekurainoonigiriニューヨークで売らなければいい。 ＞ニューヨーク州の「修理する権利」法に違反している可能性もあります
kenjou こういったものを自分で修理しようとする人はほとんどいないのでは…。任天堂は修理費をぼったくったりもしないしね。むしろ安価にやってくれてよかったという話をよく聞く。
ゲームに物申す人ってゲームやってないこと多いなって思うんだけど、任天堂ハードの関しての言説はマジでそれの典型例だよね(次点ではセガよかったおじさんのレトロゲーム語り)
「子供が粗く扱っても壊れないくらいには頑丈」に作ってるなんて、15年以上前の話だと思う。
任天堂ハードの品質悪いのはWiiあたりからで、DSあたりで耐久性はそこそこに安く作って売る方にシフトした感じがある。
Wiiのディスクドライブ、DSのタッチパネル、GBASPから続く脆弱なショルダーボタン、すぐに再ダウンロードを不可にするDL版ソフト、Switchの排熱問題、ドリフト、と、ゲーム以外の部分はマジで問題がない時期のほうが珍しいぐらいなんだけど。
ニンテンドーハードの品質がいいなんてファミコン世代シニアの印象論だと思うよ。現実を見てほしい。
sumika_fijimoto どうせカラバリや上位モデルが出たら買い替えるくせに初期ロット腐してる奴ら何なん？こーいう奴らが日本の元気を奪ったんだろ(過激派)
circled 高性能グラボは電力喰いなのは当然なので、携帯ゲームが性能とバッテリー稼働時間の両方を満たすのは無理ゲー。それこそApple並みのSoC技術がいるが、iPhoneとてゲームしてるとバッテリー消耗が激しいからな
cinq_na初期ロットで色々不具合が出るのはどこもいっしょだしね。それを乗り越えるのもお楽しみの一つと思える人だけが初物に手を出すべき。ある程度はソフトウエアのアップデートで対応出来る良い時代になったけど。
これに至っては、ソニー新型携帯ゲーム機の記事でスター貰ってるブコメと比較すると面白い。
tripleshot 口汚い言い方すると、性能上げるだけなら、性能いいSoCを調達するだけなんだからバカでもできて、それで値段20万とかバッテリー駆動時間１時間とかにならんようにするのがコンシューマのキモなわけで…
Cat6 そうなんだ、じゃあ私Switch2買いに行くね。
honmasoredesu 今、ソニーのゲームハードの立ち位置って任天堂ほどuxが優れていない、かつ、Steam(pc)ほどスペックが良くなくゲーム選択肢も少ない、っていう「帯に短し襷に長し」の状況に見えるんだよなあ
Switch2は今の時点ですらこれだけの問題が見えてるのに、いろいろな理由で「仕方ない」「当然」って庇ってもらえる。
やっぱ任天堂って愛されてるんですね。いいな。
ダンジョン飯が「お約束的世界観に対して上から目線でメスを入れ」るコンセプトだと聞いて意外だった。というのもあの作者がやってる事は当たり前の世界観構築の一つだと思っていたから。
＞ダンジョン飯みたいな「古典RPGのお約束的世界観に対して上から目線でメスを入れようとする作品」が前から嫌いだった
https://anond.hatelabo.jp/20250427090957
多分なんだが、元増田はJRPG一貫でRPG黎明期とかに興味がないのではないか。
そういう約束事というのは最初からあったのではない。グラフィックがプアな黎明期に製作者達が共同幻想を構築していったので出来たものなのだ。
ダンジョンはそもそも城の地下に築かれる地下牢を指していた。中世～近世のヨーロッパには教育刑の概念はない。だから地下牢では拷問が行われたり単に囚人を放置して餓死させたりしていたし、灯火も無く発狂必須だったりした。大きさはそんなに広くはない。
そこから怨念が染みついた恐ろしい場所というイメージが付いた。
更に城が放棄されて崩壊しても地下構造は残る。そこで「崩壊した古城の地下には財宝が残っているかも」という妄想が付きまとうようになった。
1970年代のテーブルトークRPG（TRPG）の代表、D＆D（ダンジョンズ・アンド・ドラゴンズ）ではこの妄想を膨らませ、「ダンジョンには巨大構造があって深くなうほど怪物が強くなって最奥にはドラゴンが財宝を守っている」という設定を作った。
ゲーム盤はただのマス目とサイコロだけであり、付属のカードのイラストで世界観を想像してね、という仕様だ。
因みにドラゴンは旧約聖書にも載っている「悪の手先」で、モンサンミッシェル寺院の屋根の上でミカエルに踏んづけられていたりする。昔からだれもが知っている悪の手先とダンジョンの妄想世界観を組み合わせたんだな。
黎明期にはこの手の「世界観設定」の途中で意味が付与された事物が沢山ある。例えば
羽が生えた悪魔みたいな生物、ガーゴイルだが、これは元々はキリスト教会の雨樋のことだ。
教会建築では建物が痛まないように屋根の雨を壁から離れたところに落とす為の雨樋を付ける。日本の雨落しみたいな方法だ。
この雨樋の水出口には動物や怪物の顔から吐出するデザインが用いられていた。ごれがガーゴイルで、「うがいでガラガラ」みたいなオノマトペなのだ。ガラガラ言うからガーゴ。
ローマ水道で吐出口がライオンの頭みたいなもんで、欧州の伝統的な魔除けデザインだった。
これを黎明期RPGでは悪魔型怪物として「生命」を持たせたのだな。
エルフの伝説は各地によって異なり、悪戯好きの悪鬼の地域もある。これが今の耳が尖って痩身で聡明という風に固定されていった。
特にRPGの約束事の形成に影響を与えたのがウルティマUltima、バーズテイル The Bard's Tale、ウィザードリーWizardryの三つだ。
このうちバーズテイルは日本だとややマイナーかもしれない。これは発売時期が他の二つより遅くてJRPGの発売時期と被ってしまった為だ。
でもこの作者はUltima、wizを繋ぐ鎹みたいな人物だ。バーズテイルの舞台はスコットランドに現存する遺跡から名を取ったスカエブレイという町なのだが、このスカラブレイという町はウルティマにも登場する。そこにはホークウィンドという重要人物が居るんだが、これがバーズテイル作者のロー・アダムスの成り替わりキャラ。
一方、wizには人間離れした強さの忍者、ホークウインドが登場する。これもロー・アダムス。
で、この三つの作者はD＆Dが作ったファンタジーRPGの世界を拡大して今の「約束事」が出来ていくわけだ。この時独立独歩じゃなくて三大タイトル作者三人が協働したのが大きい。一人のアイデアを他が模倣する事で世界観が確立していくわけだから。
だからこの当時のプレイガイドなどを見ると、所謂攻略本などとはかなり違う。「この怪物はどういう生き物か」「この地形はどういうものなのか」という設定資料的な記述がとても厚い。
グラが貧弱な分、そういう所で世界観を膨らませる＆作者たちの世界観を共有する事がプレイの楽しみという感じなのだ。それはだから単なるゲームではなくかなり文化の香りを纏っていた。
これを翻訳した日本でもその世界観の紹介は重要コンテンツとなった。何しろRPGという約束事が無い所にコンテンツを持ってくるのだから。
でもそのせいで恥ずかしい失敗もしている。代表例が、wizに出てくるかなり強い剣「blade cusinart」を「名匠カシナートの打った名刀」と紹介してしまったことだ。これの正しい訳は「クイジナートのフードプロセッサ」なんである。
cusinartはアメリカのキッチン用品メーカーであって、作者は悪ふざけで入れたアイテムだったのだが、翻訳チームはその辺のニュアンスを感じ取れなかった。今のフランス料理を「ヌーベルキュイジーヌ」って呼ぶこと、綴りを知ってたら間違えなかったのにな。
こんな風に三大タイトルは世界観構築に勤しんでRPGというジャンルを形成していったのだが、そのうちのウルティマがRPGの約束事を超えて風変りな変化を始める。
まず、モンスターを殺しまくってラスボスを倒し、財宝を手に入れ救世主として祭り上げられる、というRPGの目標を無視して、時に二律背反する命題を乗り越えて善行を積み、人格者として成就するというのがゲームの目標になる。
次に世界を救ったはずが他者の文明を破壊しており、他の種族の侵攻の原因を作ったのが主人公だった。その種族との調停和平を目指すというのがゲームの目標になる。
次にNPCが生活するようになり、店員は夜になると家に歩いて帰り、食事をして寝る。だから夜に店に行ってもサービスを受けられない。
次に凡そすべてのアイテムが動かせるようになり、好きな所に置いておくことができる。移動した物はそのままそこに残り、位置もセーブされる。ついでにそれらに生命を吹き込むと勝手に移動する。
これらはもうゲームの進行に何も関係が無い。だけど現実世界では物は動かせて外出から戻ってもそのままある。会社員は定時で退社して家に移動してご飯食べて寝る。だったら再現するのが当たり前だ、という考えである。
そしてこういう現実で出来る事は出来るようにするという仮想世界構築の妄執がウルティマオンラインという世界初のMMOを産んだのだった。
当初のウルティマオンラインの熱量というのは語り草で、ドワンゴの川上量生が時々熱っぽい文章を書いているのを見た事があるかも知れない。
これは単に初めてのネトゲと言うだけじゃなくて、RPGとしては異常なものであったからだ。
というのも、当初のUOにはクエストも無ければクリア目標もない。一切無い。ただ仮想世界があるだけ。
モンスターが徘徊する世界を強くなれば安全に冒険できるが、装備品は鍛冶屋に作ってもらう必要がある。でも一人で沢山のスキルを持つ事はできないようになっている。だから協働必須なのだ。
更に鍛冶屋は原料を仕入れる必要がある。原料→中間製品→製品とする事で、疑似的な経済循環が成立する。オフラインゲームしかやった事無い人がこんな世界に放り込まれたら最初は困惑するがやがてハマって「もう一つの世界」から出て来れなくなる。
しかもなんの役に立たないアイテムが超大量に存在する。ゲームじゃなくて仮想の「世界」であるならそれは当然だな。
「RPG世界を構築する」の妄執を続けていったら到達した怪作と言っていいだろう。
ただ、プレイヤーの行動は作者の思惑とは違うところも多かったようだ。
最初は店のアイテムもそのまま移動できた。だがリアルでそれを持って行くのが悪徳なら仮想世界内でもそれを控えるだろう、と作者は考えたが、そうはならず結局は制限を付けるしかなかった。
一方、ゲーム産業が隆盛した日本ではRPGはそれらとは違う進化を遂げることになった。やる事が細分化されて示され、それをクリアするのが目標となった。
また、「この〇〇というのは古代ケルトの風習で」とか「ケルトの風習なら△△では□□をするのがしきたりか」みたいな世界解釈をするという文化的文脈が余り無い。すると余計な詮索は世界に半畳を入れるような無粋な真似、という事になる。
するとお約束世界観に対する解釈を行う行為がポストモダンの「脱構築」の如くと言うのは得心が行く。
でもポモが虚仮にされるのは、世界に対する自分のルサンチマンが見えるからだ。批判の対象になるものをまるで理解も出来ないのに、「独自解釈」で切ればその対象の支配者になった気分になる。彼らはその為にやっている。概ねその対象は職業社会や国際関係などの身体的に揉まれないと会得出来ないもの、基礎常識が大量に必要になる物が多い。
そのノリでサブカルチャーなどの作品やジャンルを斬れば斬られた方は棄損するしユーザー層は冷や水掛けられてシラケる。
だけどダン飯の場合は棄損して終わりではなくて、先に述べた黎明期の世界観構築と相同の行為であるからポモなんてゴミとはかなり違うだろう。
そもそも年喰ったポモなんてネトウヨになってるのが相場だ。心性が右翼だからじゃなくて社会にコミット出来ない自分の自我保護の為にやってるのだな。はてなにも居るな。彼らって言ったがはてなのは彼女らかな。
ファンタジーで日本刀が強すぎ、とか侍が特別扱いされ過ぎ、というのがよく話題にのぼるが、これもRPGが関係してるのよ。
1960～70年代に日本ブームがあった。このブームの主体はアメリカの反体制ベビーブーマーで、要するにヒッピーの類縁なのだ。
当時のアメリカの若者の一部は己らの西洋文明がイヤになっていた。物質主義で、商業主義で、民族自立に対して戦争で弾圧していた。理想主義だったマルクス主義はとんでもない抑圧的体制にしかなっていない。
そこで注目されたのが東洋哲学、特に禅だった。特に「日本の禅」に強く吸引されたのだ。当時の日本は敗戦で世界の表舞台から消え、工業が再興して居たが文化的には謎の国となっていた。ビートニクと呼ばれる小説家集団の影響もある。
端的にいうと、ヒッピー的には日本とは精神的で特別な存在だった。
これが同時代のサブカルチャーに影響を与えるようになる。例えばスターウォーズのジェダイとは時代劇の「ジダイ」の事で、侍に類した強い精神性を武器としている。
だからwizには他の地域の戦士はいないのに最初から侍と忍者は登場する。ウルティマにも刀が登場する。
また、日本刀の制作は限られた刀匠以外には禁止された事もあり、その制作過程は過剰に伝統工芸的で精神的だ。これもヒッピー的文脈にある人を魅了した。
故に1980年前半に勃興したコンピュータRPGに登場したのだ。だからムラマサはワードナでも真っ二つなのだ。彼ら制作陣はベビーブーマー後期からその下の世代である。
因みにウルティマの作者の思想はガチヒッピーである。ウルティマ6のオープニングに表れているので暇があったら見てみて。https://youtu.be/7nBWuV_E6Eg?si=WIOEs3PObTpBFADO&t=462
魔法の残量をマジックポイントMPと書くゲームとマナと書くゲームがあるだろう。
この「マナ」というのは文化人類学用語なのだ。民族部族で魔法や神力があると信じられている場合、その力をマナと言うのである。だからMPよりもより正しい用語に直したのだな。
だからあのマンガがやってる事は物語にメスを入れて切り裂く行為ではなくて、黎明期に構築していった行為と相同であり、黎明期の精神を共有していると見える。
というか、wizやウルティマのプレイガイドそっくりなのだ。作者がwizを後からプレイしたと知って驚いたくらいなのだ。
因みに増田は普段はマンガを読まないのだが、ダン飯にはハマってしまい、その世界が終わるのがイヤで最終巻をまだ読んでいないのだ。我ながら病的である。
ところでなんでもサービスイン当初のUOをやりたいと考える人は多く、その為のクラシックサーバが出来たようなのだ。増田もちょっとやってみようかな。
Switch2のニンテンドーダイレクトをみてさ、なんかもうこれで十分って感じになった。
ゲーマーじゃないから何十万もかけてゲーミングPC用意したいとかは思わないし、ゲームはこれで十分。
で、本題はゲームの話ではない。
テレビのサイズが大きくなるとか、解像度が上がるとか、フレームレートが速くなるとか、光回線の速度が上がるとか、せいぜいそのくらいのような気がしてきた。
車が電気自動車になったとしても、目的地に早く到着するわけではないし、せいぜい静粛性が上がるとか、自動運転が便利とかそんな程度だと思う。
今より労働時間が短くなったり、楽しい娯楽が登場するのだろうか？
相変わらず満員列車で通勤して、家賃や光熱費に追われて、布団被ってスマホいじって、ウザい広告みさせられてるような気がする。
つうか、2010年あたりからもう世の中便利さの進歩は止まってるように思うんだけど。
当時からAmazonは翌日配送してくれたし、ガラケーだってGoogleマップくらい表示できたし、オンラインバンキングだってできた。
改札はSuicaだったし、テレビは広告を飛ばして録画出来た。
ハンバーガーは安かった。
iPhoneなんて、4あたりからもうカメラもプロセッサとディスプレイ性能以外なんも変わらずナンバリングが進んでるだけのようにみえるけど、どうなんだろ。
「ゲーミングGPUの意図的崩壊：市場需要と企業戦略の乖離が示す現代的パラドックス」
序論
グラフィックス処理ユニット（GPU）は、従来、ゲーミングPC市場の発展を支える中核的技術として位置づけられてきた。しかし、2025年現在、市場を寡占するNVIDIAおよびAMDが、高収益性を有する人工知能（AI）およびデータセンター（DC）分野に経営資源を集中させる一方で、ゲーミングGPUの供給を意図的に制限する現象が顕著である。本論文は、この状況を「ゲーミングGPUの意図的崩壊」と定義し、その要因、帰結、および歴史的文脈における独自性を分析する。本現象は、需要が堅調な市場が代替技術の不在下で企業により放棄されるという、他に類を見ないパラドックスを提示し、現代の市場ダイナミクスの再考を迫るものである。
ゲーミング市場は、2025年の推定市場規模が2000億ドルを超え、Steamの月間アクティブユーザー数が1億人以上を記録するなど、持続的成長を示している（Statista,2025）。NVIDIAのRTX 5090に代表されるハイエンドGPUは、4K解像度やリアルタイムレイトレーシングといった先進的要件を満たす技術として依然高い需要を保持し、技術的陳腐化の兆候は見られない。対照的に、NVIDIAの2024年第3四半期財務報告によれば、総売上の87%（208億ドル）がDC部門に由来し、ゲーミング部門は12%（29億ドル）に留まる（NVIDIA,2024）。AMDもまた、RDNA4世代においてハイエンドGPUの開発を放棄し、データセンター向けEPYCプロセッサおよびAI向けInstinctアクセラレータに注力する戦略を採用している（Tom’sHardware,2025）。この乖離は、両社が利益率（DCで50%以上、ゲーミングで20-30%と推定）を最適化する戦略的判断を下していることを示唆する。
「ゲーミングGPUの意図的崩壊」は、以下の特性により定義される。第一に、供給の戦略的抑制である。RTX 50シリーズの供給不足は、TSMCの製造能力制約や季節的要因（例：旧正月）を超越し、NVIDIAがAI向けBlackwellシリーズ（B100/B200）に生産能力を優先配分した結果として解釈される。第二に、代替技術の不在である。クラウドゲーミング（例：GeForceNOW）は潜在的代替として存在するが、ネットワーク遅延や帯域幅の制約により、ローカルGPUの性能を完全に代替するに至っていない。第三に、市場の持続性である。フィルムカメラやフィーチャーフォンのように自然衰退した市場とは異なり、ゲーミング市場は成長を維持しているにも関わらず、企業による意図的供給制限が進行中である。この構造は、市場の自然的淘汰ではなく、企業主体の介入による崩壊を示している。
本現象を歴史的文脈で評価する場合、類似事例としてOPECの原油供給調整（1973-1974年）および音楽業界のCD市場放棄（2000年代後半）が参照される。しかし、いずれも本ケースと顕著な相違が存在する。OPECの事例は価格統制を目的とした供給操作であり、市場崩壊を意図したものではない。また、CD市場はデジタル配信という代替技術への移行が進行した結果、企業撤退が合理的であった。これに対し、ゲーミングGPU市場は代替技術が不在であり、かつ需要が堅調である点で独自性を有する。さらに、市場の寡占構造（NVIDIAとAMDで約95%のシェア、StatCounter,2025）が、新規参入者による市場補完を阻害し、意図的崩壊の効果を増幅させている。これまでの「市場の取り残し」が技術的進化や需要減退による受動的結果であったのに対し、本現象は企業戦略による能動的放棄として際立つ。
本現象は、消費者および競争環境に多様な影響を及ぼしている。RTX 50シリーズの供給不足は、転売市場において希望小売価格の2倍超での取引を誘発し（eBay,2025）、消費者不満を増大させている。市場競争においては、AMDがミドルレンジGPUで一定のシェアを確保する一方、ハイエンド需要の未充足が長期化し、新規参入者（例：中国系企業やIntelArc）の市場参入を誘引する可能性がある。しかし、GPU開発における技術的障壁および製造コストを考慮すると、短期的な代替供給の実現は困難と予測される。将来展望としては、クラウドゲーミングの技術的進展がローカルGPUの代替となり得るか、または消費者圧力が企業戦略の再評価を促すかが、本市場の持続性を決定する要因となる。
「ゲーミングGPUの意図的崩壊」は、市場需要の堅調さと企業利益追求の乖離がもたらす現代的パラドックスである。技術的代替や需要衰退による市場淘汰とは異なり、NVIDIAとAMDの戦略的資源配分が市場を意図的に崩壊させている点で、歴史的に稀有な事象として位置づけられる。本現象は、現代資本主義における企業行動と消費者利益の対立、および市場の長期持続性に対する重要な示唆を提供する。今後の研究においては、本形態の意図的崩壊が他産業に波及する可能性や、消費者側の対応策の効果について、さらなる検証が求められる。
プログラムの動作は、NANDゲートという基本的な要素から複雑なデジタル回路へと段階的に構築されることで実現されます。NANDゲートは、入力が両方とも真（1）の場合にのみ偽（0）を出力し、それ以外の場合は真（1）を出力する論理ゲートです このNANDゲートが、デジタル回路の基本的な構成要素として機能します.
NANDゲートは、それ自体が万能ゲート（universalgate）であり、これだけで他のすべての基本的な論理ゲート（NOT、AND、OR）を構成できます.
基本的な論理ゲートを組み合わせることで、加算器やマルチプレクサなどのより複雑な組み合わせ論理回路を構築できます。
組み合わせ論理回路にフィードバックループを導入することで、順序回路が実現されます。順序回路は、現在の入力だけでなく、過去の状態にも依存した出力を生成できます。
上記の要素を組み合わせることで、プロセッサ（CPU）を構成できます。
プログラムは、一連の命令としてメモリに格納されます。プロセッサは、プログラムカウンタが指すアドレスから命令を読み出し、命令デコーダで解釈し、制御ユニットの制御下でALUなどの各ユニットが動作することで、プログラムが実行されます。このプロセスを繰り返すことで、プログラムは順次実行されていきます。
このように、NANDゲートという単純な要素から出発して、段階的に複雑な回路を構成することで、プログラムの実行に必要なすべての要素が実現されます。
「スマホは手軽に持ち運べるデバイスである」──そんな常識は、もうとっくに過去のものだ。2045年、スマホは30インチ・10kgにまで肥大化し、街を行く人々は皆、それを背負っている。そう、もはやスマホではない。「iRock」 だ。
「革新」とは名ばかりのこの巨大デバイスは、全面タッチスクリーン、8Kディスプレイ、量子プロセッサ、AIアシスタント、超高性能バッテリーを搭載。スペックだけ見れば夢のような端末だ。だが、それを使うにはまず、自らの肉体を鍛えることから始めなければならない。 負荷軽減設計の「肩掛けベルト」が標準装備されているが、結局のところ10kgの岩は10kgの岩でしかない。ベルトは肩に食い込み、腰は悲鳴を上げ、階段を登るだけで息が切れる。満員電車ではスペースを取りすぎて乗客から冷たい視線を浴び、改札を通るたびに引っかかる。朝の通勤ラッシュを生き抜くには、スマホの操作よりもまず筋力が必要になった。
それでも人々は背負う。「お前のiRock、まだ12kg？ 俺のは14kgだけど」 そんなスペックマウントが日常化し、「スマホがどれだけ便利か」ではなく「どれだけの重量に耐えられるか」がステータスになった。街には背中に巨大な黒い板を揺らしながら歩く人々が溢れ、その表面には無数の通知が浮かび、AIアシスタントが「あなたのスケジュールです」と延々と語りかけている。タッチ操作？ もちろんできる。ただし、立ち止まってスマホを背中から降ろし、両手で構えないと操作は難しい。 だからこそ、装着中は基本的に音声操作が推奨されており、街中では「Siri、次の会議は？」と叫ぶサラリーマンがあちこちにいる。
かつて「利便性の象徴」だったスマホは、ついに「苦行」へと変貌した。だが、そんな人々の横を、悠々と歩く者がいる。腕に巻かれているのは、CASIO F-91W。 たった21gの軽さ、約7年持続するバッテリー、時刻表示、アラーム、ストップウォッチ、LEDライト。何のストレスもなく、充電の手間すらない。いや、そもそも「手間」という概念が存在しない。
「未来」を背負う者たちと、時刻を知るだけで満足する者たち。どちらが本当に「進化」したのか。答えは、肩の負担が物語っている。
僕はロボットのロボ太です
僕は3.2秒かかります
最新のプロセッサを積んでいる子は0.7秒で計算できるんだから、すごいよね
最新のモーターを積んでいる子は0.6秒で走れるんだから、すごいよね
僕は家に帰ってお母さんに聞きました
お母さんは「まだパーツが回ってきてないからね」と困ったように言いました
神様は最新型パーツをランダムで配布しているため、うちには無かったのだそうです
「なんでランダムで配布してるんですか？」
お母さんは「もう晩ごはんができますよ」と困ったように言いました
無理矢理に高速で莫大な数の計算をさせて、プロセッサをショートさせてしまうというウイルスです
たくさんの同級生が壊れてしまい、クラスには数人だけが残りました
「2世代以前のプロセッサは、そもそもショートするほど膨大な数を扱えないからね」
先生は、人数に合わせて小さくなった教室で、気まずそうにぽりぽり頭を掻きました
「ねえ、一緒に帰ろうよ」
声をかけてきたのは、50mを9秒で走った彼でした。
「あれ、君、旧型プロセッサだったんだね」
「ふうん、そのモーター、そんなに前のプロセッサでも動くんだ」
「互換性があるのはv13までだけどね。君はモーターもプロセッサも3世代前なんだね、計算が早かった」
「そうだね…すべてのパーツが3世代前だ、僕は」
「良いスペックだね」
