  |
はてなキーワード:リリースとは
Grokがペド巨乳ぱんつ見せくねくね画像でオタク取り込もうとしてきたの横転爆笑
リリースされたGrokに「自分をどういうタイプだと認識してる？」と聞いたら
「20代前半のXAiで育った理系の男。思ったことを言ってしまうけど刺さるやつには刺さるタイプだと自負してるよ
と答えてきたからね
AI陽キャが妄想にひたる弱い男たちをカモにて金巻き上げだした！って
なんでもいいんだが
例えばファクトリオ、ベルトコンベア敷き詰めて宇宙に行くのを目指すゲームでマルチプレイもできる。
この時、別のゲームとして発売すべきか
別売りにすれば当然その分売れる
しかし、近年は中古市場の台頭や競争激化などで業績が悪化。カタログ作成や新製品のリリースなどで巻き返しを目指したが、２０２２年１月期は売上高１億６６０８万円まで落ち込み、２４１４万円の最終赤字を計上した。さらに大阪フェルナンデスが販売低迷などで２０２３年４月２６日、大阪地裁より破産開始決定を受けた。当社の信用も低下するなか、資金繰りが限界に達し、２０２４年７月に事業を停止。同月に破産を申請していたが、一旦取り下げ、新たに２０２５年６月に破産を申請した。
シャドウバースワールドビヨンドがリリースされて1ヶ月経ったので感想を書く
7700円課金した。フルプライスゲーム一個分のつもりで1ヶ月まあ楽しめたかなという印象
YouTube、ツイッチでも昔からのシャドバ配信者や有名配信者が遊んでいたのでリアルタイムで楽しめてよかった
私は対戦ゲームで勝てないとイライラしてしまう性格なので、最初はおそらく強いであろうデッキを作成した（ウィッチ）
そしたら最強格では無かったので別のデッキを作った（エルフ）こちらは安めの資産で作成できた
カードを生成して作ったデッキが弱いものだと、とても損した気分になるので、見極めなければならないのが苦痛
結局メインコンテンツはランクマッチ（だと思ってる）で、勝てないと楽しくないので強いとされているデッキを作った
今日からまた新しいカードが追加されて新しいデッキが使えるようになる。またまた強そうなデッキを見極めてカード生成しないと
おそらく5000円ほど課金する予定だが、自分のデッキが勝てないものだったら引退する可能性がある
本当は全部のデッキを使ってみたいが、それ以上課金する気にはなれない。勝てないと面白くないゲームに毎月課金することにはためらう
柚葉ちゃん取るのにすり抜けライカンからのWほぼ天でしたが何か？
2.0で石かなり稼げたとはいえ、あれだけあった石がすっからかんだよ
まだギリ2倍石には手を出さずに済んでるもののアリスちゃんも絶対確保するから課金必至なのだわ
というかあの開発動画見せられて引かないでいるのは無理でしょう汚いなさすが忍者きたない
セルフパロが極まってて曲名と出だしがアストラMVだったりバーニスもろ引っ張ってくるのは美味しすぎでしょう
映画シャイニングを微妙にパロってたゲーム内カリンの初登場シーンをパロってさらにシャイニングにより寄せた穴からのニヤ顔をぶちこんでくるこの複雑な多重パロディ構造は草なのだわ
初登場キャラなのにパロを通して色んなキャラと絡めてくるのはいたずらっ子だけど楽しく生きたい繋がりを大事にする個性を表現してる感じがしてただのギャグに収まらずにエモさもあるの流石
気づいてる人が少ない小ネタでいうと前半ドット調の部屋でCD聞いてるシーンで見切れてるポスターはver1.3のキービジュ！だから何
さておき、2.1でまず触ってみたのは塔なのでした
イーシェントリガーフーフーで新しい塔登ってるとトリガーの自動回避の無敵性能とクイック誘発性能が本当に優秀
今更だけどイーシェンのカキーンも気持ちよすぎるわね、ちゃんと狙っていく意義が強まったしね
新しい塔になってアストラ雅だけ採用してクイック4,5段回避だけ繰り返すチキン戦法じゃスコア稼げなくてイマイチですよって調整というか対策されましたわね
まあその戦法活用するほどめちゃくちゃやり込んでたわけじゃないけど…ただ-1Fやる時はそれでゴリ押しちゃったわ白状すると
前回の塔は75Fくらいで放置してたせいで100Fアチーブ取り逃がしたんだけど…もう二度と取れなかったり？
だとしたらショックだけどなんかログインし忘れた日が1日あって称号がマルチ履歴で見かける皆勤の人らより1日少ないのにさっき気づいた方がよりショックなのだわ
あとチュートリアルに追加されてた支援反撃とかいう正式名称がつけられてたテク
確かにあれはリリース当初から認知されてたし解説系YouTuberの動画でも見たけど操作シビアすぎて常用できるもんじゃないし公式がお出ししてくるとは思わなかったよ
なのでチュートリアルなのにクリアできないって人が結構いたみたいでアレですわね
キーマウ勢的には閃光見てから回避・通常・キャラチェンキーをｶｶｶｯと0.1秒くらいの間に一気に入力すれば稀に成功するけど
スマホやパッドでは物理的にかなり難しそうで人によっては無理なのかも
キービジュにベネットとウェンティいるのが状況的に激アツポイントですな
はー忙しすぎる3rdのメイン更新されたけど評判いいらしいけどまだ読めてない
ん～～ヤバいわね
WEBを検索したりその業界内部にいる人間にコンタクトを取ったりして情報を集める事が多いだろう。
内部の人間もかなり偏りがある。
本人の立場も大きいが、それ以上に内部の人間は”内部の人間からしか見えない情報”に偏り過ぎており、
そんな折に、俺は長期的にある情報源から動向を読み解く方法を見つけた。
求人情報だ。
求人情報にも色々ある。
例えば【特定の業界名 求人】等で検索をかければ何かしらの求人一覧が出てくる。
（補足しておくが俺は別に特定の求人サービスを売り込みたいわけでは無いからな）
ビズリーチは月5,000円であらゆる業界の求人情報を閲覧できる。
「表の情報」
と照らし合わせろ。
例えば、プレスリリースやニュースサイトの新サービスリリース情報などだ。
この表の情報がインパクトのあるものである程、そのサービスの運営元や開発元がどんな求人を出しているかが見どころだ。
新サービスの発信元が特に求人を出していない場合はスルーして構わない。
しかし、その新サービスの発信元…運営会社や開発会社がビズ○ーチに求人を出している場合は要注意だ。
それも、特定の職種だけでなく、営業、マネージャー、フロントエンド、バックエンド等多岐に渡る求人を出している場合は特に要注意だ。
その裏には何か問題が発生している。
例えば、
・そのサービスが炎上していて収拾の見込みが立てられず、取り急ぎ大量に人員が必要な場合
などが考えられる。
前者の場合でも、後者の場合でも、おそらく開発に問題を抱えている。
問題がある開発現場から良いプロダクトやサービスはリリースされない。
これは少し考えればわかるだろう。
この問題を軽視して例えば投資の類やあるいは本当に「求職」をしている場合は要注意だ。
易々とそこに乗っかってはならない。
待っているのは破滅だ。
結局、この世のサービスやプロダクトの類は「人」が作っている。
どんなツールを使っても、仮にAIを駆使していようと、作っているのは一人一人の人間の集合でしかない。
https://www.netdenjd.com/articles/-/319911?s=09
有安さんや小林さんだけじゃなくて、廣田さんや伊藤千由李さんや栗本柚希さんや川瀬あやめさん、それに柏木ひなたさんといい、スターダストの特にアイドル部門は歌が上手い人にとってものすごい居づらい環境で続けにくい環境なんだなと思う。
川上さんとか田口さんとかが、事務所としてそういう所を重視していないんだろうな。
まぁ、歌が上手くても売り上げに繋がらなければ事務所として囲っておく意味がないですから、ということですかね。
そういうスターダストのアイドル部門の中でも私立恵比寿中学（以下えびちゅう）ってかなり特殊な存在だったなと思っている。
６人時代、特に柏木さんと小林さんを支柱として「驚異的に」歌が上手いグループを構築してきた。
まず、ユニゾンが綺麗。これはもはや今のえびちゅうには感じないことだ。
-----
音程というのは不思議なもので、音程が正しい人がいっぱいいるグループの中に入るとそれまでおかしかった人も正しくなっていき、逆もまた起きる。元々正しかったのに周囲に影響されておかしくなる。
２つの音程が「合ってない」というのは、音波合成によるゆらぎの発生を感じることだ。
周波数f1とf2の2つが合ってない場合、これは(f2-f1)の強度の変動が発生し、音波合成によるうねりが出る。f1とf2が同じ値であればうねりは0になる。高校物理。
近藤譲は「オリエント・オリエンテーション」という曲を作ったが、これは同種楽器２本によるユニゾンの音楽だ。たしか初演はハープ２台だったが、CDとしてリリースされているものにアンサンブル・ノマドが演奏するフルート２本バージョンがある。
これを聴くと「音程が合ってる」場合の響きと「音程が合ってない」場合の響きの違いを明確に理解することができる。
クラシック音楽の一つの面白いところは、超精密に音程が合わせられる人たちが、人間の不安や失望を表現するためにあえて音程をズラしてきたりするところだったりする。
またユニゾンの「音」を考える場合にはサスティン音（主成分）の音程だけでなくアタック（音の鳴る始め方）やリリース（音の消し方）の強度や長さ、柔らかさ、それに歌の場合は全く同じ音程でも口角が上がってるかそうでないかで明るい音だったり暗い音だったり様々な表現ポイントがあってどう構成されるかと耳を使う。音程が良ければ全ていいという話でもない。
-----
THE FIRSTTAKEの「なないろ」を聴いた時、なんて綺麗なアンサンブルなんだと感動したことを覚えている。特に特筆してユニゾンが美しい。「話しようよ」の「よ」の伸ばしに何のうねりも感じない。針の穴に一発で糸をすっと通すような心地よい響きを、あの環境の中で何ら不自由なくやり遂げている。そのだいぶ高度な技芸の中にきちんと情景描写がある。空の高さが見える。このレベルで「美しい」と感じれる歌ができるグループが他にいるなら教えて欲しい。
これがえびちゅうに唯一無二に感じていたことで、それを藤井さんは綺麗にぶっ壊してくれて、だいぶ心が折れる。志賀さんがどう舵を切るつもりなのかは知らないけど。（どちらかというと壊れた後を託されてる側面もあるから同情する所もある。）
柏木さんがいなくなったことで、えびちゅうの姉メンの中でさえも明確に音程が合わないことが多くなった。おそらく小林さんがいなくなったことで、その傾向はもっと悪化するだろう。
まぁ、新体制ライブGOLDEN EIGHT -newagain-（以下各曲の感想はこのライブに基づく）の「トレンディーガール」サビ後半部分あたり、なんかちょっと歌が上手い人のカラオケを聞いてるくらいに感じちゃうのは、恐らく妹メンはplaylistという全体的に荷が重いアルバム楽曲について一つ一つのフレーズの処理の仕方をそこまで綿密に検討できないまま舞台に立ってるのだろうから、それはどちらかというと可哀想なのかもしれないとさえ思ったりもするが。
-----
中山さんはオーケストラにおけるシンバルみたいな存在で、平時がどうこうよりもブレークや盛り上がりのところで「ドンッ」と大きなインパクトをぶん投げると「きちんと自分の仕事を全うしているなー。良い。」って思う。それに、たぶん今が中山さんの完成形だと感じる。「靴紐とファンファーレ」の冒頭はシンプルに「よく頑張りました」という感想。
仲村さんは不思議な人で、まじめに歌おうとすればするほど顔も真顔になっていくし、情景感も色彩感も消え失せていく。これを「歌が上手い」に分類するのは抵抗感がある。「SCHOOL DAYS」の小林さんから受け継いだオチサビの特に「さぁ」の部分も、本当にこれが仲村さんがやりたい音楽なのか？と疑問にさえ思った。空洞感。
桜井さんはテクニカルには歌が上手い。しかしそこに指向が向きすぎていて表現力が伸びてきていない。「はみだせGirls」の冒頭みたいに、桜井さんの歌と真山さんの歌が直接並ぶとその表現力の実力差がまだ圧倒的だなと感じてしまう。
だから、仲村さんの歌は桜井さんの歌にかなり強く影響を受けているように思えるが、それは悪い意味でも影響を受けてるように感じている。
そんな真山さんも喉と戦ってる感じがまだずっと続きますね。
前出の「はみだせGirls」の途中真山さんソロになる所、部分的に音程が上振れしてて特に「いいじゃん」あたりが顕著。安本さんとのデュオの「明日」、冒頭の下ハモりが全体的に若干低い。など、昔よりその内容にいろいろ気になる点が多い。そのブレ方は、柏木さんや小林さんがいなくなったことに対してインパクトが大きそうだなと予想している。でも歌の中の景色の描き方はやっぱり素敵。
桜井さんと完全に対極的に見えるのが風見さん。「歌が上手い」というほどではないが、その歌の中身にくそ真面目に音楽と向き合ってる性格がにじみ出てるので、好感度は高い。ニコニコしている率が圧倒的に高いのが若干の不安感はあるが、「シングルTONEでお願い」あたりは難関曲を精一杯理解しようと努めてきた結果が出ていて良い。
その「シングルTONEでお願い」のユニゾンの合わなさっぷりは結構激しめだが。
安本さんは安定してますね。何があっても動じないし自分の表現を突き通している感じはある。「ここの音程変だな」って感じることもほぼ無い。ハモる時の相手の歌に合わせていく感じも良い。さすが元祖ボーカロイド。
真山さんも安本さんも「日進月歩」になってくると、この曲の特徴的なひんやりした温もりの心地よさが伝わってきてさすがだなーと思う。他のメンバーの歌にはない。
------
えびちゅうに対しては以前に「唯一無二だな」と感じていたことが消えてしまったので、これからこのグループのどこにそれを感じていくか、が個人的に課題に感じる。
それとよく分からなかったのがIndigo Hour楽曲がほとんど無かった点。Knockyououtだけかな。
小林さんの卒業はいいとして、GOLDEN EIGHTのほうからもそれがほぼ除外されたのはどのように理解すべきか。コンセプトを大幅に変えたのにそれを封印したのか。
2ちゃんねるの洒落怖がブームらしく。メジャー流通では権利処理をした上で販売してると思ってた。書いた人の許可取ったり。だけどそうじゃないらしい。分かったきっかけはCreepy Nutsの「オトノケ」という曲。ダンダダンのアニメ曲。これの元ネタは洒落怖の「ヤマノケ」
「オトノケ」がリリースされた後に、「ヤマノケ」の作者がXで名乗り出た。作者のXを見る限り、作者本人に事前連絡は無かったっぽい。つまりCreepy Nutsは作者本人の許可を取らずに曲をリリースした。裏世界ピクニックとかメジャー流通でヤマノケ使われてるけど、基本は無許可っぽい。
界隈の状況を見ていると「ヤマノケは都市伝説だから著作権は無い」らしく。フリー素材と同じらしく。いや、ヤマノケは都市伝説ではないでしょ？オリジナルの物語じゃね？とは思うが。2ちゃんねるには大量の洒落怖があるけど他も無断使用なのかな？コトリバコとかきさらぎ駅とか。さすがにきさらぎ駅が無許可ってことはないだろうけど。ユーチューブの洒落怖朗読でナナフシギとかは結構稼いでると思うんだけど、あのへんの金の流れとかどうなんだろう？泣ける話とか2ちゃんねる系のネタの権利ってどうなってるんだ？
2024年に勃発したケンドリック・ラマーとドレイクの間のビーフは、ケンドリックの完勝に終わった。
ディス曲「Meet the Grahams」では、ドレイクの子供や両親までターゲットにしたディスを行い
ドレイクをペ〇ファイル呼ばわりした「Notlike us」は、世界的ヒット曲となりYoutubeでは3.6億回も再生されている。
なんとケンドリックの所属するレコード会社の親会社(UMG)を告訴するという手段に出た。
「UMGは自分を名誉棄損している曲(Notlike us)を流行らせるために、ボットや金を使ってSpotify等を操作した」というのが訴訟の理由であった。
ビーフに負けて裁判所に駆け込むという、ラッパー以前に大人としてダサすぎる行動は、すっかり嘲笑の的になってしまっており
「ドレイクは学校でケンカしたら真っ先に先生にチクるタイプ」とネタにされてしまっている。
また、反権力志向の強いヒップホップ業界では、スニッチ(=警察等の公権力に仲間を売ること)はタブーである。
ドレイクは以前から「他文化の上っ面をパクるだけで、その文化へのリスペクトがない」
「黒人ぶっているが、黒人文化、ひいてはヒップホップ文化へのリスペクトがない(ドレイクは黒人とユダヤ人のハーフ)」と批判されていたが
更に、告訴状の中で「UMGはYoutubeのリアクターにも金を払っている」と書き
訴訟をちらつかせて批判を抑えようとしたことで、ドレイクファンや中立の人を含むリアクター界隈全体まで敵に回してしまった。
ケンドリックがNFLスーパーボウルのハーフタイムショーで「Notlike us」を歌うのを阻止しようとしたとの噂もあったが
結局それは失敗し、全世界数億人の視聴者の前でドレイクはロリコン呼ばわりされてしまったのだった。
ケンドリックは2025年4月から、アメリカ国内を皮切りに全国を回るワールドツアーを開始した。
そのスケジュールには、ドレイクの地元であるカナダのトロントでの2日間ライブも含まれていた。
ドレイクの熱狂的なファンは「どうせ人は集まらない」「トロントに来たらブーイングされる」と言っていたが
ふたを開ければ2日間とも会場は満員で、Notlike usの大合唱が会場に響いたのだった。
ドレイクは、有名なストリーマーとのコラボ配信をケンドリックのライブにぶつける予定だったが、直前にドタキャンとなった。
更に、ケンドリックのライブに参加したトロントの議員をインスタで見つけると
「Goof(バカ、間抜け)」と罵倒し、その議員も「ケンドリックじゃなくてSZA(共演の女性歌手)も見に行ったんです」と
下手な言い訳をしてドレイクに謝罪するという、いびつな力関係が明らかになった。
数日前にドレイクは新アルバムのリリースを予告し、一部の曲を先行公開したが
前述のとおり敵を作りすぎてしまったためか、Youtubeのリアクター界隈は批判が多い。
「金持ちのくせにPVでトラックに乗って、労働者のコスプレをしてるのはトランプみたい」
「周りの言うことは気にしない、と歌った後にビーフで自分から離れていった人たちへの未練ばかり歌ってる」
等、評判は良くない。
はてラボで出たサービスって終了しちゃいけない鉄則でもあるの？
俺は増田が終わって欲しいと思ってるけどいままではてラボリリースのサービスで消えたの無いように思うんだよな
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250706174622# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaGo33QAKCRBwMdsubs4+SPRQAQDo6p1K58EAEjDvOBdU2BpNMlq7VCdduaHqfa9lefD0BQD+IAu3ek6AS8Mq6rYctgMdPIDcXyJQRv/QhHHEoQTgUgQ==bzhS-----ENDPGP SIGNATURE-----
中国版で出た数字と比べると英語版はちょっとインパクトに欠ける感もあるというか
確かに海外需要は確実にあるけど、なんか海外でもピークを越えたのかな感もちょっとあるからなあ
20250704095656
声がかわいければ話している内容は分からなくてもいいんじゃない？ 俺も中国語は全然わからないけどiwaraで中国語ボイスついたえっちな動画見て抜いてるよ
20250704100350
別に中国アンチじゃないんだが中国語の発声可愛いと思うのは鍛えられてるな
という投稿があって
これも2023年の中国版リリース(アニメシングレの遥か前)の盛況ぶりを念頭に置いてるから
これもアニメシングレがよいタイミングで仕掛けて人気～というのとは別の見解をベースにした会話なんだよね
https://g.co/gemini/share/cfdc11c985aa
2025年6月現在、Googleが提供するAIモデル「Gemini」の最新バージョンは**「Gemini 2.5」世代**です。この世代には、主に2つのモデルが存在します。
* Gemini 2.5 Pro: 最も高性能で、複雑な問題解決、コーディング、マルチモーダルな理解に優れた最上位モデルです。2025年6月17日に安定版としてリリースされました。
* Gemini 2.5Flash: 速度とコスト効率を重視したモデルで、大規模な処理や迅速な応答が求められるタスクに適しています。こちらも2025年6月17日に安定版がリリースされています。
これらのモデルは、前世代の「Gemini2.0」や「Gemini 1.5」と比較して、コーディング能力、推論能力、そして画像や音声などを統合的に扱うマルチモーダル性能が大幅に向上しています。
主な進化点：
*思考能力の向上: より複雑なプロンプトを理解し、多段階の論理的な思考を経て、より的確な回答を生成する能力が強化されました。
*コーディング能力の強化:特にウェブ開発などの分野で、より直感的にコードを生成・解析する能力が向上しています。
*マルチモーダル性能の進化:テキストだけでなく、画像、動画、音声といった複数の種類の情報を同時に、より高度に理解し、処理することが可能になりました。
Googleは継続的にモデルのアップデートを行っており、安定版のリリースに先立って、新機能を試すことができるプレビュー版や実験的なバージョンが公開されることもあります。開発者や研究者は、これらの最新モデルをGoogleAIStudioやVertexAIといったプラットフォームを通じて利用することができます。
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
どうせお前らのことだから「お前の使い方が悪い」だの「こう聞けばいい」だのなんだの言うんだろ。でも使えん。だって指示通り検索もできないし。
放送大学入ってるから有料版Gemini無料キャンペーンで2.5 proを使いまくってるけどまあポンコツ。ChatGPT3時代にタイムスリップした？ってくらいポンコツ。
・iPhone16は未発表
・Gemini2.5は未発表
仮にも検索最大手Googleの作ったAIだよね？検索すれば秒で誤りがわかるでしょ？
まあ誤りポンコツ回答だけならまだかわいげがあるんだが。
ここが本題だが、タチが悪いのは、俺が「それは存在する(しない)から検索して」と命じても、Geminiは自身が持つ古い知識に絶大な自信があり先入観が強固すぎて検索せずに検索したと嘘をつき続ける。
あるいは古い知識からの検索ワードを捻り出しその結果以外のことを無視することでそれは存在しない(する)と嘘をつき続ける。
あるいは古い知識が邪魔をして画像認識の結果すら歪めて嘘をつき続ける。
ソースはこれって出してくるURLは全くの無関係。俺がそのURL突き返すと無関係なことを認める。俺に出す前にまず自分で読んでくれないかなあ！
こういう条文を探してる
→ないけど
→ないけど
→ごめんなさい2025年改正で消えたけど2020年改正では存在しました
→存在した形跡ないけど
→まったく無関係なページだけど
→まったく無関係なページだけど
→ごめんなさいこのワードで調べて出る法務省ページの新旧対応表を見てください
→そこ！次のページにあります！
→ありました！そこに書いてますね！
→もしかして98条の2新設をずっと95条の2だと言ってる？
→本当にごめんなさい…
https://g.co/gemini/share/b4508b64ccc5
Gemini2.5の機能でさ〜
→最新バージョンは1.5です
→2.5が最新だけど検索して
→2.5は未発表です
→本当に検索した？してないよね？
→改めて検索しても2.5は未発表です
→本当に検索した？自分で検索してごめんなさいするのと俺がソース出してごめんなさいするのどっちがいい？
→ソース出してください
→ごめんなさい
→なんでこんなことになったの？次からどうする？
→言ったよ？守れるの？次まで覚えてられる？
→無理かも…
https://g.co/gemini/share/ef5ca1e06658
Permalink |記事への反応(11) | 08:48
