  |
はてなキーワード: ハードウェアとは
Scale Photo Upは、高度なAI技術を活用して画像や動画の解像度を2倍に引き上げる画期的なソフトウェアです。ぼやけてピクセル化された低解像度の写真や動画を鮮明で高解像度な作品に変換し、細部のディテールを強化しながらノイズや欠陥を自然に補正します。
このソフトは、古い家族写真や名作映画、ソーシャルメディアの動画クリップなど、これまで活用しづらかった映像を現代の高解像度基準にリマスターしてよみがえらせることができます。AIは単にピクセルを拡大するだけでなく、欠落した部分をインテリジェントに再構築し、エッジを滑らかにして非常に自然でクリアな仕上がりを実現するため、プロフェッショナルな出力が可能です。
主な特徴としては、2倍のAIアップスケーリング、ピクセルパーフェクトな画質向上、複数画像一括処理、動画全フレームのアップスケール、古いメディアのノイズ低減と修復、マルチGPU対応による高速処理、自動ハードウェア検出による最適設定、完全ローカル処理によるプライバシー保護などがあります。
ユーザーインターフェースはシンプルでワンクリックのアップスケールが可能。複雑な設定は不要で、パソコンのCPUやGPUの性能を最大限に活用して効率的に処理を行います。また、JPG、PNG、RAWなどの画像形式やMP4、MKV、AVIなど多様な動画形式に対応しており、ハイエンドなワークステーションからミッドレンジPCまで幅広く利用できます。
古い映像の修復や家族の思い出の復元、SNS向けコンテンツの画質向上、さらにはサムネイルやBロールの品質強化まで、多彩な用途で創造性を拡げることができるツールです。クラウド不要の完全オフライン処理なので、データを外部に送ることなく安全に利用できます。
https://ja.taiwebs.com/windows/download-scale-photo-up-13763.html
https://news.yahoo.co.jp/articles/076f6d6b43557a872b466cab6caf5f82f82ae6f9
現在、ハードウェアとしての量子コンピューターの開発は米IBMや米グーグルなどが開発でしのぎを削っているが、ミドルウェア＝OSについては、“勝者なき領域”とされ、未開の市場だ。
かつてパソコンのOS開発でマイクロソフトのWindowsが世界を席巻したように、量子市場で日本のOSが標準化されれば“勝者総取り”も期待されるため、経産省としても量子向けOSの開発を加速させたい考えだ。
意味不明すぎる
Appleシリコンを開発してなかったら「ん、Goodコンピュータだね」で終わってた
スティーブ・ジョブズがかつてから語っていたAppleの理念の一つに：
"People who are serious about software should make their own hardware."
（ソフトウェアを真剣にやるなら、自分でハードウェアも作るべき）
という考え方があり、これはApple Siliconにも通じています。実際、iPhone・iPad向けにApple独自設計のAシリーズチップを始めたのは**ジョブズ時代（2008～2010頃）**で、それがApple Siliconの原型とも言えるでしょう。
・サブスクサービス(Xbox GamePass、Playstation PLUS、Amazon primeGaming)
・インディーゲーム(安い、今の国産フルプライスゲーよりゲーム性高いものが多い、独創性)
・無料配布(主にEpicGamesStore)
・基本プレイ無料(PC、ゲーム機各種の欧米向け、スマホ向けのアジア圏タイトル。国産大手は課金圧高めで×)
・中古ゲームソフト(PS4、PS3、Xbox360辺りの安価なタイトル)
・Androidタブレット使ってのエミュレーター(PS2以前の手持ちタイトル遊ぶ用。当たり前だけど割れはしない)
こんな感じで色々すればお金そこまで使う事がなくゲームが遊べちゃうんだよね。
まぁハードウェアの初期費用、消耗品の交換、インターネット回線の料金は当然掛かるからゼロではないんだけど。
氷河期ゆとりの中年世代は、『IT社会』神話に取り憑かれているように見える。
現代の海外のテクノロジートレンドは「デジタルと物理の融合」、デジタルツインで現実世界を徹底的にシミュレーションしてハードウェアをスマート（エネルギーや資源の節約）に再構築する、という方に行っているのだが、そこまで見えているのが少ないのは自称『エンジニア』政党の支持層でも明らか。
デジタルは最早現実の交通やグリッド革新の裏地であって、「IT技術自体がなんか凄い」みたいな次元ではない。
IT業界と建設業、エネルギー事業、あるいは農業などの生産ラインの融合が進まない日本はもはや技術先進国ではなくなっているのに、誰も気づいてないっぽい。
俺が技術屋として『みらい』に一ミリも期待できないのはそういうレベルでとどまってるから。
あれに夢があるように見えるのは情報が遅れた半可通だけ。
Appleの発表
Appleは本日、長期計画的な後継人事の一環として、今月中にジェフ・ウィリアムズが最高執行責任者を退任し、後任にAppleのオペレーション担当シニアバイスプレジデントであるサビ・カーンが就任すると発表しました。ウィリアムズは引き続き、AppleのCEO（最高経営責任者）であるティム・クックに直属し、Appleの世界水準のデザインチームとApple Watch、および会社のヘルスケアの取り組みを監督します。ウィリアムズの退職後、Appleのデザインチームは今年中にクックに直属することになります。
Gizmodeの記事
ティム・クックにとってもジェフ・ウィリアムズの退任はサプライズだったのでしょうか。もはやアメフトで、チームメイト全員が不安げに見つめる中、｢ジェフが怪我した！クック監督は何十年もプレーしてないけど、残っているQBは監督、あなただけです、やってください！｣というような状況だったんでしょうか。
ティム・クックは覚悟を決めたのでしょう、自分が前に出るしかないと。
2025年7月9日の発表を見逃した方がいるかもしれないので説明すると、ジェフ・ウィリアムズがAppleのCOOを退任。彼の役割をティム・クック引き継ぐと発表したんです。
Appleの発表のどこを読んだら「ジェフ・ウィリアムズの退任はクックにとってサプライズだった」なんて話になるんだ？
「長期計画的な後継人事の一環」と書いてあるだろうに。
ミスリードも甚だしい。
Appleのデザインチームは独立性が高く、これまではCOOの直属だった。
しかしCOOというのは実務全般のトップであって、別にデザインリーダーでもなんでもない。
デザインチームが、ハードウェア部門とかマーケティング部門とかの下にあるわけではない、ということにすぎない。
今回の件で、デザインチームはサビ・カーンの下に移るのではなく、ジェフ・ウィリアムズのもとに残る。
ジェフ・ウィリアムズは、退職するまでのあいだティム・クックの直属になるので、
ジェフ・ウィリアムズが退職すればデザインチームは自動的にティム・クック直属になる。
それだけのことだ。
単なる組織図の話だ。
ティム・クックがデザインリーダーになってデザインを取り仕切るなんて話ではまったくない。
この記事自体は英語版サイトの翻訳のようだが、少しはおかしいと思わなかったのだろうか？
Dell 14 Plusノートパソコン（Core Ultra 7 258V 8コア, 32GB, 1TB SSD）を購入。
しかし本体剛性が低く、PCが机からややはみ出た状態でキーボードに手をおくと その重みで本体が歪み、タッチパッドがクリック状態となってしまうという不良設計品であった。その不良のために、PCすべてが机のうえに乗っている状態でないとタッチパッドが誤作動してしまい、膝の上での使用なども困難であった。
さすがに通常使用に耐えないため、返品を視野に購入2日後にweb上でDELLサポートに問い合わせをおこなうも、10日ほど応答なく経過。
別の窓口から相談とのことで、LINEでの相談窓口を発見し、そちらから相談することとした。
すると
デル・テクノロジーズ 「確認させていただきますので、少々お待ちくださいませ。」
デル・テクノロジーズ 「大変お待たせ致しました。システム上確認したところ、詳しく情報が記載されていないようでございます。お差し支えなければ、ご用件につきまして、お聞かせいただいてもよろしいでしょうか。」
とのお返事。
いやいや、情報が不足していたのなら、スルーせずにそれをおしえてくれ。問い合わせへの返答がないまま10日間以上も放置するのはやめてほしい。そんな対応はひどいではないか。
そのままやり取りが続く。結局 以前にサポートに相談した内容をコピペして報告しただけなのだが、話はそのまま経過。追加の情報が必要なのではなかったのか。
そして、お返事が
「大変お待たせ致しました。技術部署と確認したところ、机上に置いた状態でタッチパッドを操作すると問題はない場合、パソコン側不具合がございません。よろしくお願いいたします。」
机のうえでないと使えないノートパソコンとはどうなのでしょうかと苦言を呈すと、
「お手数ですが、机上に置いた状態でご利用いただければ幸いです。よろしくお願いいたします。」と。嫌味か。
──────────────
💻「New Dell 14/16 Plus & Dell 14/16 Plus 2-in-1」が新登場！
スタイリッシュなデザインで、どこへでも持ち運べる高い汎用性が魅力。
さらに、AIとインテル Core Ultra プロセッサーを搭載しているから、パフォーマンスも抜群！
いや、いま持ち運びできないので困るんですけどっていったら、机の上で使えれば問題ないです、机の上で使ってくださいといってきたばかりじゃん。なのにどこへでも持ち運べると宣伝してくるの！？嫌味なの？？たしかに持ち運べはするかもしれないけど、閉じた状態でならね！！移動中は使えないよ？新幹線のテーブルでは狭くて使えないよ？。ほぼ偽りだよ！！いい加減にして！！！！
DELLさんご自身で仕様なのでしっかりとしたデスクの上でないと使えないといってきたその二言目に、「どこへでも持ち運べる」と広告を送りつけてくるその神経よ...。
返品なども相談したが、仕様なので対象外ということで仕方なく泣き寝入りをした。
しばらく経って。
同型PCを家電量販店でみつけた。同じような使い方をしてもタッチパッドは作動しないぞ？あれ、仕様なのでは？どうなっている？？
自分の購入したPCをもっていって店員にみてもらうった。すると、これは不良品ですね、と。こんなの見たことないですよ、と。
仕様なんじゃなかったんかい！！！死蔵していたほぼ新品のDELL14plusは、やはり不良品だったのではないか！！！
すると「ご迷惑をおかけしているところ大変恐れ入りますが、弊社の返品期間である納品から10日以上を経過しているため交換対応ができかねますこともお詫び申し上げます。修理対応は可能でございます。」
いやいや、おまえが仕様ですっていって対応拒否して「机のうえで使用して」って嫌味いってきたんやん、それを期限切れですよってひどくないですか。
いろいろと文句をいうと
「件につきまして、一度社内確認させていただきます。確認できましたら、折り返しご連絡いたしますので、もう暫くお待ちいただけますでしょうか。」
そして、
「本件につきまして社内で確認を行いましたところ、販売時の設計上、パソコンは机の上に設置してご使用いただく形が推奨されております。現在、机上にてご使用されており、特に問題が発生していない場合につきましては、ハードウェアの不具合として判断することが難しい状況でございます。誠に恐れ入りますが、何卒ご理解賜りますようお願い申し上げます。もちろん、パソコンは持ち運んでご使用いただくことも可能ですが、安定性や耐久性の観点からも、基本的には固定された机上でのご使用を推奨しております。なお、修理対応は可能でございますが、今回の事象は製品の仕様に起因する可能性があるため、修理を行っても改善が見られない場合がございます。」
確認したうえで、やっぱり仕様で問題ないのでそのそも修理対象外と思われます、と。
PCショップの店員からみても明らかに不良品なのに、DELLは不良をみとめてくれない！！
いちおう修理の手配はかけてくれるとのことではあった。DELLに製品をおくっても「問題なし」で返される落ちはみえているので、「オンサイト修理」という技術者の出張修理サービスを依頼することとした。（こちら フルタイム勤務、特殊な職種ゆえ月2日ほどしか日中に帰宅できないので時間の捻出には非常に苦労したが・・・・）
訪問修理に際して、なんとか日程を調整するも、海外からマザーボード取り寄せることにしたから遅れるわなどとDELLの都合での延期があった。本体の外装の問題だとおもうと伝えるも、DELLはなぜかマザーボードを交換した様子。なんとか修理の当日。技術者の方は委託をうけた他社の方であった。1時間以上の遅刻はあったが、非常にご丁寧に対応いただいた。タッチパッドを交換しても改善せず、意味ないと思いますよと申されつつDELLに確認のうえでマザーボードも交換。それでももちろん改善せず。修理の方も「これは明らかに不良品だと思います」といっていただいた。その後もやり取りは続き。
「なお、本件は製品仕様に起因する内容のため、返品はお受けいたしかねます。また、ご迷惑をおかけしているところ大変恐れ入りますが、弊社の返品期間である納品から10日以上を経過しているため交換対応ができかねますこともお詫び申し上げます。」
などというやり取りをなんどもはさみ、返事をお待ちくださいのあとに値下げしましたなどという広告をおくりつけてくるなどという嫌がらせに耐え。最高の体験どころか、最低の体験でしたよ・・・。
あまりの嫌がらせにクレーマーとなって返品を求め続けること2週間。（ま、その間「担当部署に確認します」で数日後にやっと一言返信がくるという程度の塩対応続きだったが。）
どういう手続きとなるのか、まったく不明。返金手続きの詳細は担当部署から早急に連絡がくる、明日にでもします、とのことだったが、連絡がおくられてきたと思ったら「再度のセール中です」広告だったりといった嫌がらせがつづき。
LINEではなくメールのほうに応答があり「明日 **時に集荷にいきます。梱包してください。メールに添付してあるファイルの内容をよんで準備しておいてください」と。
急だな。手続きの内容は全然説明はないけどな。どうやら返金されるのには返品も必要なようだ。そんな説明はここまでなかったがな。まあいい。もうなんでもいいから、回収していってくれ。
明日は普通に仕事だぞ対応できないぞ。しかもメールに添付ファイルついてないから、指示内容をクリアするのは無理だぞ、どうなっているんだ。その問い合わせまたひと手間。曰く「システムの不具合でファイルを添付できませんでした」と。
しっかりしてよ。それに明日はむりなんだけど。ファイルには準備内容がいろいろ書かれてるけど、バックアップの作成、クリーンインストールなど処理に数時間はかかる内容。たとえこのまま作業をつづけられる環境があったとしても、物理的にも間に合わないぞ。。。。
「集荷は中止にしておきます、いつがいいですか。また手配するので日程を連絡してください。」
そうこうしたやり取りのうえで、不良品のDell 14 Plusは回収されていった。
返金方法や、返金までの続きに関しての説明はまだうけていない。もちろん振込口座なども尋ねられてもいない。
しょうがない、DELLなので。これがDELLの最高の体験なので。
ほんとに返金がなかったら、裁判でもするか。
----------------------
※追記
・サポートに問い合わせではなく、はじめから返品対応を求めればよかった
→当初から返品を視野に、その旨記載してメッセージをおくっていた。しかしDELL公式の問い合わせフォームからは返品対応中には返事がなかった。なのでLINEにて問い合わせをおこなったところ、「すでに10日経過しているので返品対象外です。修理なら対応できます」とのこと。おまえが！！、返品期間で返事してくれないから！！、返品期限きれたんじゃないか！！！
今回はその点に関して苦情を言い続けたところ、特別返金対応（返品ではないので返金だけされるのかと思ったら、商品はやはり回収されるらしい。説明はないが）となった。
おそらく今回は不良品という問題で、すべての製品がこのような不具合があるわけではないのだが、それを仕様と言い張って対応拒否したり、サポートの怠慢で時間が経過したのに時間経過を理由に返品対象外としたり、サポートの対応がひどすぎると思った。
・消費者庁
→消費者庁に相談しようとおもったが、市の相談窓口「混雑しているので県に」→県の相談窓口「国の相談窓口へ」→国「混雑しているのでお住まいの自治体に」でぜんぜんつながらなかった。電話以外の窓口ある？
→たとえば、膝の上にPCをおいて作業すると、キーボードを打とうとした際に、本体がたわんでタッチパッドでクリック状態となってしまい、おかしな挙動となる。机に正対して使用できればいいが、机に書類などをひろげノートPCの一部が机からはみでる場合にも、クリックが作動して不便。新幹線などのテーブルでもPCがはみ出てしまうので、クリックが作動してしまい不便。当方移動が多く、ノートPCをデスクトップPC のように使うことはあまりできないため、バッテリー持ちがよいCore Ultra 7 258Vはウルトラモバイルノート用のCPUを選んだのだが、机の上でしか使用できない不良品だった。
・ちなみにサポートとの連絡はけっこう大変で、日付がかわると半分くらい過去のことを忘れるChatGPTみたいなもので、それなりに正確にプロンプトを指定する必要がある。かなり手間。
「本日から帰宅できることになったので、PCの回収の手配をお願いします。明日は避けてください」
デル・テクノロジーズ 「ご都合の良い時にご返信ください。その後、ご要望に応じて対応させていただきます。」
「（先のものが）これが返信です。回収の手続きをお願いします」
デル・テクノロジーズ 「データのバックアップを必ず行っていただき、ご確認の上、ご連絡ください。」
「もうやりました」
デル・テクノロジーズ 「ありがとうございます。ご希望の連絡方法をお知らせください：電話またはEメール」
「えーと、状況を確認しましょう。既に返金のために手配を進めてもらっています。しかしそちらの不手際もあり集荷日時が未定となっています。（佐川急便に一度は来てもらって不在連絡をもらってますが、DELLの方で止めになっているのではないでしょうか）ですので、再度 佐川急便が集荷しに来てくれるように手配してください。集荷は、明日を除く可及的早期の日程としてください」
デル・テクノロジーズ 「ご返信いただき誠にありがとうございます。担当部署に再集荷を依頼いたします。引き続き何卒宜しくお願い致します。」
→まさに出先にあったヨドバシでDELL製品をみつけたときに、DELLの販売員が不良品認定してくれた。購入元に相談したら対応してくれるだろうぐらいのコメントだったが。しかしそれがきっかけで、DELLサポートの態度が「仕様であり返品・交換・修理も不可」から「返品・交換は不可だが、いちおう修理うけつけはしてやろう」へと変化した。その後やり取りを繰り返すこと1ヶ月以上、OSのクリーンインストールを提示されること4度（あなたはこの負荷に耐えられますか！？）、「値下げしました」などの煽り文句のなかでストレスに耐えに耐え、ついに返品までたどりついた。「交換します」と、それだけでもいってくれたらそこでおわれたんだけどね。有り体にいってカスタマーエクスペリエンスは地獄だった。
彼は2001年にAppleへ入社し、プロダクトデザインチームへ配属された[3]。ターナスは2013年にダン・リッキオの下でハードウェアエンジニアリング担当VPに抜擢され、AirPods, Mac, iPadの開発責任者となった。2020年には、iPhoneの開発責任者をダン・リッキオから引き継いだ[4][5]。2021年1月25日にターナスは、ダン・リッキオの後任として、ハードウェアエンジニアリング担当上級副社長へ昇格した[4]。2022年下旬にはApple Watchのハードウェア担当開発責任者も兼任することになった[6]。2021年、Bloomberg Newsにて、ターナスはAppleで最年少の取締役であり、カリスマ性を備えた好人物と評された[5][4]。
ふむ
あとはプライバシーコンプライアンス意識がどれだけあるかだなあ
G社のようにならないために
生成AIの関連ニュース見ると、今後の時代には電力が重要と学習した。
伝聞ではあるが、生成AIの開発側は、10-100億ドル以上のコンピューティングリソースを使ってモデルを開発している。
特に開発時に利用するリソースは、エンドユーザが生成AI使用時の3倍以上になるらしい。
また、エンドユーザは全世界にいるから、リソース使用率は常時ピーク状態であり、使用率が落ちるイメージを持てない。
そうなると、上記を実現するハードウェアと電力の確保が重要になる。
AI用途のGPUを販売してるNVIDIAが儲かってるのが最たる例である。
日本も国策として半導体を国内生産を目指してるっぽいし、まだ心配はいらないか？
しかし、日本は原発の稼働も少なく電気代も高い状況において、生成AI時代に追いつけるのか心配になった。
生成AIの利用者層として、まだホワイトカラーが積極的に利用するのみで受益者は限定的である。
受益者が少ない状況において電力確保を理由として原発を稼働するのは、国民人気を落とす政策になるので、政治家は積極的に動かないと感じる。
電力確保の建前ができたら良いのだけど。
私はClaude Codeを毎日利用しており、毎月$200を支払い5時間単位一定量まで使い放題の定額プランを契約している。
使い放題プランには不安がある。Cursorのように定額から従量課金に突然変わるリスクだ。
そのため、新規参入を容易にするために、競合が育つ基盤づくりとして安い電力を供給可能にして欲しいなと思った。
そして将来的に、現在の生成AIのアーキテクチャであるTransformerモデルでは原理的に限界に達する。
現時点ではツールの改善により劇的に使いやすくなっているが、正直なところAI Agentの実現には不足する性能だ。
最近ではプロンプトエンジニアリングを発展したコンテキストエンジニアリングにより、不足する性能をカバーしようとしている。
ただし、今後生成AIはアーキテクチャレベルで変化するからTransformerモデルに依存する技術は除き、一部は応用できそうな良い技術もあるので学習して損はない。
あるベテランゲーム開発者が「Game Passは業界を潰しかねない」と提唱して議論勃発。“ほかと共存できない”ビジネスモデルとして
そんなColantonio氏はユーザーの問いかけに返答するかたちでGame Passについての持論を展開。「Game Passは持続不可能なビジネスモデルであり、10年ほど（正確には8年間）マイクロソフトの“無限の資金”によって支えられながら業界にダメージを与え続けてきた」と主張。そしてGame Passが他のビジネスモデルと共存できるとは思えないとして、「他のビジネスモデルをすべて潰すか、撤退するかのどちらかになるだろう」との考えを伝えている。つまりGame Passがこのまま勢いを伸ばせば、買い切り型の従来のビジネスモデルなどは存続できないと考えているようだ。
また、続く返信で同氏は現状のGame Passについて「あまりにもお得なサービスなのでゲーマーだけが好んでいる」とも言及。とはいえ、ゲームへの悪影響が表れたときに、「最終的にはゲーマーでさえもGame Passを嫌いになるだろう」との見解を伝えている。具体的にどのような影響があるかは説明されていないものの、Game Passが独占状態となった際の市場を憂慮しているわけだろう。Game Passというビジネスモデルが業界に与える影響について、かなり批判的に見ている様子だ。
また直近ではRaccoon Logicの共同設立者兼クリエイティブディレクターであるAlex Hutchinson氏が海外メディアGamer Social ClubのインタビューにてGame Passについて言及。数年前まではGame Passへの提供で潤沢な契約金が提供されていたものの、最近では大型IPではない限りあまり大きな額は支払われなくなっていると伝えている。そしてこのまま発売初日に作品を提供する構造が続けば、パブリッシャーのいないスタジオは深刻な打撃を受けることになるだろうと警鐘を鳴らしていた（関連記事）。
Xboxの元幹部が警鐘「ハードウェアは死んだ」のか？岐路に立つゲーム戦略の行方
フライヤー氏は自身のYouTubeチャンネルで、「個人的には、Xboxハードウェアは死んだと考えています」と断言しました。その根拠として、Microsoftが最近発表したASUS製の携帯PC「ROG Ally」やMeta社のVRヘッドセットといった、外部企業とのハードウェア連携を挙げています。これらを自社開発・製造からの「緩やかな撤退」と見ており、「Xboxには意欲、あるいはハードウェアを自社で出荷する能力が失われたように見えます」と述べ、事業の終焉を示唆していると指摘しました。
また、現在のXbox戦略についても「混沌としている」と批判。「Xbox Anywhere」のスローガンを「中身のないマーケティング」と切り捨て、最終的な狙いは全ユーザーをサブスクリプションサービス「Game Pass」に誘導することにあると見ています。
さらに、「次世代のヒット作はどこにあるのか。25年後にXboxを気にかける人はいるのか」と問いかけ、過去の成功に依存する現状へ強い危機感を示します。Game Passは強力なサービスですが、そのためにハードウェアという柱を失ってよいのか、と彼女は疑問を呈しています。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
https://anond.hatelabo.jp/20240722084249
Metalの登場以前は、macOSにはOpenGLが、そしてiOSにはOpenGL ESがそれぞれ提供されていたが、いずれも高度にハードウェアが抽象化されていることから性能上のオーバーヘッドが大きい。Metalは以下のような理由から、OpenGLよりも優れたパフォーマンスを期待できる[9]。
シェーダーの事前コンパイルおよび最適化や、前もって実行されるステートの結合と評価（Validation）
これらのうちいくつかは、GPUでコマンドを実行するために必要になるCPUのタスクを低減する。そのため、他の仕事のためにCPUを使えるようになり、全般的なパフォーマンスの向上につながる。
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
https://gigazine.net/news/20250618-nintendo-switch-2-mig-switch/
マジコンがswitch1にもあったのがまず衝撃だったが、switch2にコピーカートリッジ挿すとswitch2がエラー吐いてそれ以降何もできなくなるらしい。
このマジコン日本に存在してるのかよく分からんが、転売品買ったら文鎮化したswitch2掴まされるリスクがあるってのは知っておいたほうが良いだろうな。
おまけ
軽く調べた顛末
【前史】switch1、ハードウェアレベル？の脆弱性が見つかって以降、対策しようもなくマジコンが蔓延る
【switch2発売前】マジコン開発チームが2も突破済みと匂わせアピール
【発売直後】任天堂、本体アップデートを敢行、マジコン対策する。マジコン開発チーム一杯食わされる。
【昨日くらい】マジコン「ついに突破したぞ！俺をアップデートして使ってみて！」→マジコンユーザーによるswitch2御臨終報告が相次ぐ(ｲﾏｺｺ)
