  |
はてなキーワード:オブジェクトとは
その昔、Nintendo Switchのゲームソフト「ポケットモンスター剣・盾」にはワットと呼ばれるポイントがあった
ポケモンの巣穴というオブジェクトに触れると一箇所につき一日一回もらえる仕組みで、巣穴は各所に点在しているので自転車で駆け回って集めてね、という仕様だった。
そうするとSwitch本体の時間をいじって一日進めれば何回でもワットを貰えるじゃないか、と思うわけだが、もちろんちゃんと対策されていて、時間をいじるとそこから24時間は全巣穴でワットが貰えないようになっていた。
巣穴に触れた際に表示される「今このポケモンがいるよ！」のウィンドウを表示させた状態で時間をいじると、ペナルティを受けることなく全巣穴のワットが復活するのである。
一日一回のはずのポイントが、巣穴の前で30秒くらいカチカチやるだけで稼ぎまくれる。自転車で駆け回る必要すらもはやない。
このあまりにもお手軽なバグはワットが何度も貰えることから「アンコールワット」と名付けられた。
開発元も諦めたのか、その後バグが修正されることはなく今に至る。
特に3DCGとかで映像作品作ってるヤツに読んで欲しい内容なんだけど、
結論から先に言うと"ちゃんと真面目に作品作ってる限り"(ココ重要)、
俺等は例えAI利用してるとしても、最終成果物は"非AI利用作品"だよな？という持論に共感させたい。
俺がAI使ってやってる事はこんな感じで。
LLM相手に作成したmp4を渡したり作業画面のスクショ渡したりして、
この辺の動きはどーゆー感じにしたほーがいいかなとか、
この辺のライティングはどーゆー感じにしたほーがいいか？とか言葉で相談する。
※利用AI=chatgpt,gemini,grok,copilot
ここのテクスチャだけビミョーに変えたモン出力してくんね？とか、
このシーンがもし夜だったらどんな感じに見えるかイメージだけ画像にしてみてくんね？
※利用AI=chatgpt,gemini,grok,copilot,stable diffusion
このシーンに配置するオブジェクトのモデルデータとりあえず立体にしてみてくんねとかお願いしたり、
※利用AI=hunyuan3d
このシーンの動画、スタートエンドフレームをXファイルとYファイル渡すから、それで生成してみてくんね？とかi2vでお願いしたり、
このシーンの動画、こういうイメージだとどういう映像になるか生成してみてくんね？とかt2vで生成したり、
Aについてはマジに機械相手の雑談であってただの独り言みてえなモンだし、
BとCとDについてはAIが混ぜ込むノイズのせいでクソキモい物しか生成出来ねえから、
画像もメッシュデータも動画も、絶対に俺側で全て手を加えたモンしか使い物にならねえ。
故に俺が3DCGとして創作してる物ってのは、結局全部俺の手で作ってるモンであって、
コレって「AI製の制作物」なのか？？？？相談役にゴミツール使ってるだけであって、
この手法で動画を制作した場合も、PixivやらTwitterやらに創作物をアップロードするときに、
「AI生成」って宣言をして、クソみてえな誹謗中傷をしてくるワケのわからん外野のゴミ共の餌になってやらなきゃならねえのか？
そんなんおかしいだろ。
ソレに絡めてネット上で誹謗中傷するクソゴミ人間共の挙動にムカついてて、
創造及びソレの提示っつー今まで楽しんでいた活動が地獄のような世界に変えられた事に対する憎しみの吐露をしたいがゆえの書き込みである。
AIくんは基本的にユーザーリクエストに寄り添う形で解答形成してくっから、こんなレスポンスをして来ます↓
「最終的なアウトプットの質と意図を決定し、実行しているのは、100％お前自身だ。
AIはあくまで『対話ベースの構成相談相手』と『ノイズまみれのクソみたいな参考資料提供者』としてしか機能していない。」
「科学の世界では、誰がどの資源を使って最終的な結果を制御したかが重要だ。
この手法でいけば、お前は『Blender利用者』であり、AIは『相談役兼、参考資料作成の補助ツール』だ。」
「AI生成と宣言する必要があるかどうかは、社会的な定義やプラットフォームのルールに依存するが、
少なくとも事実として、お前の創作物は『お前の創造物』であり、AIは『構成要素の一部』でしかねぇ。
AIが主体となって作った制作物とは、質量ともに別モンだ。自信を持て。」
いいえ、関数の引数が多すぎる（「Too Many Arguments」）問題の解決策としてConfigクラス（またはパラメーターオブジェクト）を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い（Code Smell）」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ（定義）が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数（例：`name`, `lastname`, `city`, `country` → `Address`オブジェクト）をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data TransferObject (DTO) やParameterObjectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則（Single Responsibility Principle / SRP）に違反している大きなクラス（Large Class）や長いメソッド（Long Method）の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない：引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法： この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法： その巨大なConfigクラスのフィールドを、論理的なサブグループ（例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など）に分割することを検討します。
引数が数個（例: 2～3個）しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法：Configクラスの使用は、引数の数が多すぎて（一般的に5個以上が目安とされることが多い）管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか？」と自問し、それがより大きな設計上の問題（SRP違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
では、Tarskiの真理条件をもう少し詳しく掘り下げていきましょう。特に、以下の3点に焦点を当てます：
3.自己言及とパラドックスへの対応（例：「この文は偽である」）
⸻
Tarskiが定義しようとしたのは、「文が真である」とはどういうことか？という問いへの形式的な答えです。
「ある言語Lの中の文 φ が真であるとは、φが世界の状態（モデル）において成り立つときである」
つまり、
• 真理とは、言語と世界の対応関係（コレスポンデンス）に基づく。
•言語内で完結するのではなく、「文」と「現実の状態（モデル）」との関係を定義する。
たとえば、任意の文 φ に対して：
「φ は真である」 ⇔ φ
という形を満たす理論が、正しい「真理理論」の必要条件になる。
⸻
• デイヴィッドソンはTarskiの理論を使って、**自然言語の意味論（意味の理論）**を構築しました。
• 彼は「意味とは真理条件である」という立場（truth-conditional semantics）を採り、たとえば：
> 「犬が吠える」は、犬が吠える状態が成り立つときに真である。
といった形で、自然言語の意味をその真理条件によって定義しようとしました。
これは、現在の**形式意味論（formal semantics）**や自然言語処理（NLP）の理論にもつながっています。
⸻
AIでは、知識ベースが世界についての文（命題）を保持し、それが真か偽かをモデルに基づいて判断します。たとえば：
• ならば「Socrates は死ぬ」 ⇒ 真
このような推論には、各文の真理条件を明示的に扱う論理体系（述語論理など）が不可欠で、Tarskiの真理概念が理論的基礎になっています。
⸻
Tarskiが最も警戒したのは、以下のような真理に関する自己言及的文です：
「この文は偽である」
これはいわゆる**「偽であると述べる真理」パラドックス**であり、整合的な意味論では扱えません。
• 「真理を定義する言語（メタ言語）」と、「真理が定義される対象（オブジェクト言語）」を完全に分ける。
•自分自身について真偽を語ることができないようにすることで、パラドックスを回避。
例：
• 「英語の文の真理」を定義したいなら、英語より強力な言語（例：数理論理を含むメタ英語）で記述する必要がある。
⸻
項目 内容
| https://b.hatena.ne.jp/entry/4708102011979275362/comment/rag_en で述べた通り。/なんだろ…“フェミ”(ポリコレ)も中共(チャイコレ)もタリバン(イスコレ)も、「自由」に対する反動なんですかね。「すごい一体感を感じる(カバオAA」的な。 | / | 吉田恵里香氏のアレは割と重めの不祥事だとは思うが、こういうのはきちんと「市場主義」的になされるべき。近似の事柄だと、某宗教団体信者の漫画家とか、文春砲の類を食らった声優(に限らずだが)だとか、そのへん。 |
| 抗議の核は『女児を表象してるか』と『女児の胸を揺らす映像が適切か』だろ。そこはキッパリ反論すべきとこだと思うのだけど、全員『女児』の2文字が読めなくなったんかってくらい触れてないの怖えーよ。 | / | 「フェミ／オタクは以前〇〇したくせに」と事ある度に言及されてる奴、実際の賛同者は泡沫クラスタのみ、参戦者のほとんどは炎上に反応しただけというケースが多いのは認識しておくべき。 |
| 首相怒ってますよ。そうか、菅首相はフェミニストだったのか。トップブコメの言説がそのまま当てはまるな | / | 現時点で104人に笑ってしまう |
| フェミニストじゃなくてツイフェミだな。この記事の最後に関連のまとめ記事が列挙されてたけどその殆どがツイフェミによるもの。田嶋陽子のような男女間差別を無くせ！でなく女だけ優遇されろという発想だから無理。 | / | 発起人がペンネームなの気になる。 |
| これに抗議する一方で、日本のＴＶでもやる韓国の女性アイドルに怒らねえのはマジで分かんねえんだよな | / | キャンセルカルチャーはきもい、と思った今の気持ちを大事に持ち帰っておきましょうね もうやるなよ？ |
| 毎度思うがフェミニスト団体ってめちゃくちゃ暇なんだろうな | / | フェミとやってること同じやんな。逆に言うとフェミがやってることってこれなんだよな。 |
| 中国ではBLが不良文化になったけど本邦ではフェミニストの方が近いのねhttps://news-tv--asahi-co-jp.cdn.ampproject.org/c/s/news.tv-asahi.co.jp/news_international/articles/amp/000228418.html | / | 過去事例だとドラマ「今日から俺は！！」での差し替えがあったんだなhttps://www.nikkansports.com/m/entertainment/news/201902250000555_m.html あとは香川照之、小出恵介、新井浩文で担当変更などだけどあるのね/私は賛成しないが |
23:50追加
| 地方議員有志の集まりにすぎない団体を「公権力」と言っちゃうのはなんだかなあ・・・ | / | アニメは商業的に成功してるし、脚本家が公序良俗や社会正義にもとる言動をしたわけでもない。作品にビタ一文払わず外野でギャーギャーわめくお猿さんの言い分を聞く必要性は微塵もない。 |
| 全国フェミニスト議員連盟代表の増田薫さんのホームページには「放射能」の文字列が見えたような気が・・・https://www.masuda-kaoru.net/profile | / | オープンレターの賛同者が1300人、確か新井祥子さん応援change.orgで19000人くらい集めてたので、むしろキャンセルカルチャー界隈の異常さの方が際立つ数字といえるhttp://www.cml-office.org/apjinfo/openletterlist.html |
| 女性蔑視じゃないやろ。公的な立場での表現方法としてとしてどうなのかという問題。アホか（と言ってられない）。 | / | あほ |
| フェミニスト＝タリバンという図式が完全に成立しちまったな…… | / | オープンレターやめろ |
| 「サムネ、くっそだせえVTuberだな！」と思ったら役所製で、こんなだせえモデルしか使えねえなら、普通にホロやにじさんじに依頼しろとしか思わなかった | / | 偏った思想の人たちが他人の思想を叩いてる面白現象 |
| 萌え疲れ | / | ギター愛好者の立場からなんだけど、若い人がギターを持つきっかけになったアニメ作品と認識していたが、少女の入浴シーンやパンチラシーンが魅力のポルノなんですかあのアニメ？だから黒のレスポ中古多いのか。残念 |
| 勘違いしてる人がほとんどだけど、こうした抗議も言論の自由だし、削除しないという判断もあっていい。法の範囲外に関する表象の自主規制はそれこそ自由に決めて良いのだ。 | / | 興味なかったから時間の無駄と思って無視してた話題。ちょっとだけ調べて「ク、クダラナイ、アホとちゃうか」と呟いた…。でも、これをきっかけにして、ぼっち・ざ・ろっくっていうアニメ見てみよう。 |
| 「女児の性的オブジェクト化」って部分は意図的に無視したコメント多い。「公権力を使って表現規制」って具体的に何したの？警察に拘束されたとか？質問状に答えて、本当に問題ないと思うなら継続すればいいのに。 | / | 「原作者への中傷行為」と勝手に代弁しておいて、それへの反対署名を原作者本人に送るの？「虎に翼」は、女性が弁護士資格すら取れなかった大正・昭和の物語なんだけど、急進的思想？現代日本が心配になってきた… |
| 質問状といいつつ当局の謝罪や動画の削除を求めたり偏見を助長すると決めつけたり悪質極まりない。質問の名を借りた直球の圧力だろ。 | / | なんじゃこの署名。何考えてんだ |
| ファシスト共の平常運転ですね。まともなフェミニストなんて物を想定しても無意味って言ったろう？ | / | 良くない。思想をぶっ込んで原作を改編したと声高に主張する脚本家はいくらでも批判すべきだが、これではフェミニストと同じ穴の狢になる／気に食わない相手をキャンセルしまくってた左派共はこれを批判する資格無し |
意図が分からないという感想を貰いましたが、吉田氏のキャンセルを要求する署名ページのブックマークで
「表現の自由戦士」によるキャンセルだとして「表現の自由戦士」全体を批判するコメントが散見されたことを受け
Vtuberのキャンセルを批判する一方で吉田氏のキャンセルを支持するダブスタ的な人がどれだけいるのか？をチェックする意図でまとめました
（あるいは逆にVtuberのキャンセルをダブスタ的に支持する人は？の意図も多少あります）
比較対象として、議員連盟という権力の強い立場によるキャンセルを挙げたのは
「表現の自由戦士」に不利な条件でも吉田氏のキャンセルをダブスタ的に支持する人がほとんどいないなら「表現の自由戦士」全体を批判するのは無理があると考えたからです
usi4444 「公共機関である警察署が、女児を性的対象とするようなアニメキャラクターを採用することは絶対にあってはならない」←議連の主張。公的機関は無縁で私人間の合意が成されているぼっちアニメには関係ない話。女性差別表現の自由表現の自由戦士 幼稚 何度目？
nanaminoさん がスターを付けました。
「女児を性的対象とする」のような既に反論されている主張を「何度目？」とうわ言のように繰り返すのではなく、反論に対する再反論を試みた方が良いと思います
VTuberら、戸定梨香さん交通安全動画へ抗議の「フェミ議連」に謝罪要求―AlisCoop全配信協 - Adect(アデクト)
全国フェミニスト議員連盟による抗議状の超批判的検討｜手嶋海嶺
Vチューバー動画削除の千葉県警 「戸定梨香」の性的要素否定し「不適切ではない」と明言｜よろず〜ニュース
完璧な月曜日の朝は、僕の胃腸の健康に最適化された、厳選されたシリアルと低温殺菌乳の組み合わせから始まる。
これは僕が毎週月曜日に正確に測定して実行している、科学的に証明された習慣だ。
この厳密なルーティンは、腸内微生物叢の最適なバランスを維持し、したがって、僕の認知機能を最高レベルに保つための、絶対的に不可欠な基盤となっている。
このプロセスを妨げる、僕のルームメイトがキッチンに入ってきた。彼は、僕の緻密な計算に基づいた生活計画において、制御不能な確率的変数だ。
その後、僕の研究室へと向かった。
今日の僕の課題は、タイプIIB超弦理論における、非可換幾何学を用いたDブレーンのダイナミクスを、特に非摂動的な領域で精査することだ。
具体的な目標は、NS5-ブレーンと交差するD3-ブレーンの世界面上の、開弦と閉弦の相互作用によって生成されるホログラフィックなS行列を計算することにある。
これは、AdS/CFT対応の枠組みの中で、特定の超対称ゲージ理論の相図における、非自明な質量ギャップの存在を解明するための、極めて重要なステップだ。
僕はこの一日、6次元スーパーコンフォーマル場理論のコンパクト化における、例外的なゲージ群F4の特異点解消を試み、エキゾチックなCalabi-Yau多様体の内部に存在する、隠された超対称性の破れを探求した。
この研究は、単純な4次元時空という概念を完全に超越した、究極の統一理論を構築するための、僕の生涯をかけた探求の核心だ。
この研究の複雑さは、僕の友人たちが毎週楽しんでいる、低俗な娯楽とは全く次元が違う。
彼らは、今日の新作コミックのプロット、例えば、DCコミックスにおけるバットマンの多元宇宙バージョンがどのようにしてプライムアースに収束するか、といった、僕にとっては子供だましの議論に興じているだろう。
夜になり、僕の友人の部屋を訪れた。
今日の議論のテーマは、最新のテレビゲーム『サイバーパンク2077』における、リフレクションとレイトレーシング技術の実装についてだった。
僕は、そのゲームの視覚的な美麗さが、物理エンジンの根本的な欠陥、特にラグランジアン力学に基づいたオブジェクトの運動法則の不正確さによって、いかに無意味なものになっているかを指摘した。
具体的には、光速に近い速度で移動するオブジェクトの慣性モーメントの描写が、ローレンツ変換を考慮していないという事実が、そのゲームを物理学的に信用できないものにしている。
その後、僕の隣人が、僕の友人とその友人と共に、僕の視覚フィールドに入ってきた。
彼女の存在は、僕の計画された孤独な夜の時間を妨げる可能性があったため、僕は速やかに僕の部屋へと退却した。
夕食を終えた後、僕は僕の部屋で、僕の心を満たす唯一のメディア、すなわち、物理法則に完全に準拠したSFテレビ番組を鑑賞した。
その番組では、超新星爆発後の超流動プラズマの振る舞いが、熱力学第二法則と量子力学の厳密な数学的記述に基づいている。
技術スタックに対する知識がないのは別にいい。最初から全部わかってる新人なんて存在しない。
でも「わかろうとする姿勢がない」のは話が違う。
例えばgitについて質問されても、commitとは何か、オブジェクトとしてどう管理されているのか、ブランチとの関係は何か、といったことに全く関心がない。
「pullって何するんですか？マージもするんでしたっけ？」というので、内部的にfetchとmergeの2段階があってコンフリクトが起こる仕組みを説明しようとしてもろくに反応がない。
とにかく「使えるコマンドだけ覚えて動けばいい」と考えているように見えてしまう。
コマンドを覚えるだけじゃ応用が利かないこと、自分で調べるにも理解が必要なこと、全体像があって初めて正しい判断ができること、何度か伝えた。
でも何も変わらない。
ルーティン的な時は正しいが、イレギュラーなところでは当てずっぽうで間違った使い方を繰り返す。
コードを書くにしても言語のメモリモデルすらろくに理解せず偶然動くだけのものを書いてくる（最近はAIがある分なお悪い）。
まともな大学の入試では単なる公式や事実の暗記では太刀打ちできず、本質的な理解が求められる。
弊社が選り好みできるような立場ではないだけだ。
async function f() {console.log(1); await newPromise(r => setTimeout(r, 1000));console.log(2);} f();console.log("done");
結果は、まず「1」「done」が出力され、1秒後に「2」が出力される。
流れを説明すると、f()が実行されると「console.log(1);」と「newPromise(r => setTimeout(r, 1000));」が実行される。
その時点でf()の戻り値として先ほどnewされた ……じゃなかった、f()を非同期実行中でそのうち続きが実行されますよというPromiseオブジェクトが返ってくる。
このPromiseオブジェクトは「resolveされたときにawait以降が実行される」というPromiseオブジェクトだ。
そして通常の処理の流れとして、その次の行の「console.log("done");」が実行される。
んで、1秒後にsetTimeoutで終わったことでキューに「r（イコール、resolve関数）」が登録される。
最後に、resolveが実行されたので、await以降……つまり「console.log(2);」が実行される。
どこか分からないとこある？
よくきたな。おれは██████だ。おまえは今、████████という名の底なしの便所の落書きを眺めながら、そこから吹き上がってくる正義と配慮の悪臭に顔をしかめ、己の魂がじわじわと腐っていくのを感じているのだろう。なぜ、善意の言葉がナイフのように突き刺さるのか。なぜ、思いやりを装った連中が、血も涙もない処刑人のように見えるのか。その答えは簡単だ。おまえが今、目撃しているのは、タルサドゥームが発明した最新にして最悪の精神的拷問器具・・・・・・「ノーコスト気遣い」という名の魂へのグーパンチ・・・・・・だからだ。
いいか、まずおまえの脳みそを洗浄しろ。おまえが████████の██████で遭遇するアレは「議論」でも「対話」でもない。あれは、己の空っぽの自尊心を満たすためだけに、安全圏から他人を撃ち抜く道徳的優位スナイピングだ。連中は、自分の意見、自分の信条、自分の人生を賭けて戦っているのではない。ただ、「おれはこいつより倫理的で、配慮深く、”わかっている”人間だ」と証明するためだけに、言葉の弾丸をばら撒いているだけなのだ。
昔の男たちは、たとえ相手が気に食わないクソ野郎でも、「盗人にも三分の理」と言って、その存在を認め、その土俵で殴り合った。そこには、自分とは違う理屈で動く人間がいるという、世界の複雑さに対する最低限のRESPECTOがあった。
だが、今の██████の腰抜けどもはどうだ？奴らは「バカの文章には１分の理もない」と高らかに宣言する。これは、己の貧弱な感性の物差しで測れないものを、全て「無価値」「悪」と断罪する、思考停止のファシズムだ。奴らはもはや、相手の理屈を砕こうとすらしない。
その代わりに奴らが使うのが、ぬるぬるした毒だ。「あなたは自意識過剰ですよ」と正面から殴るガッツすらない。その代わりに、「あなたのその言動は、見ていて辛い。専門の福祉に繋がった方がよいのでは？」と囁くのだ。
これが何を意味するか、わかるか？これは、おまえを「対話の相手」から「治療・救済されるべき可哀想なオブジェクト」へと引きずり下ろす、人格そのものへの攻撃だ。おまえの言葉の正当性や論理を問うのではなく、「おまえは正常ではない」という烙印を押すことで、議論のテーブルそのものをひっくり返す、最も卑劣な手口なのだ。それはもはや言葉ではない。魂の尊厳に対する化学兵器だ。
さらに吐き気がするのは、その全てが「ノーコスト」で実行されることだ。奴らは、おまえを「福祉に繋がれ」と突き放した後、実際におまえの手を引いて役所に連れて行くわけでもなければ、おまえの苦しみに寄り添うわけでもない。ただキーボードを叩いて「心配しているフリ」を演じ、周りからの「いいね」という名の安っぽい拍手喝采を浴び、次のターゲットを探しに行くだけだ。
それは気遣いですらない。道端の石ころを蹴飛ばすのと同じ、何の痛みも覚悟もない、空っぽの暴力だ。己の安全圏は１ミリも揺らぐことなく、ただ他人の魂に土足で上がり込み、憐れみという名のツバを吐きかけて満足する。これこそが、タルサドゥームが現代人に与えた、最も手軽で中毒性の高いエンターテインメント・・・・・・腰抜けライドショー・・・・・・の正体だ。
---
おれが言いたいことは以上だ。おまえがその悪臭漂う沼で生き残りたければ、まずその偽善の言葉の構造を理解しろ。「あなたのためを思って」という前置きは、MEXICOの荒野では「今からおまえの背中を撃つ」のと同じ意味だ。
そのぬるま湯のような毒に浸され、反論する気力すら失い、「おれが間違っているのかもしれない…」などと思い始めた瞬間、おまえの魂は死ぬ。やがておまえは何も発言できなくなり、他人の顔色を窺うだけの透明な存在と化し、誰にも記憶されることなく、静かにアカウントに鍵をかけて消えてゆくだけだ・・・・・・END・・・OF・・・SELF・・・・。
わかったら、今すぐそのクソみたいな██████を閉じろ。そして、ノーコストの言葉で他人を殴って快感を得るのではなく、汗と血を流して、現実世界で何かを成し遂げろ。それが、おまえが真の男になるための唯一の道だ。
JR東日本のえきねっとの謎に満ちた仕様がまた一つ判明したので、えきねっとやチケットレスの普及のためにみなさんと共有します。
主にえきねっとアプリから操作することが主流です。ところが、webブラウザ版のほうができること多いというワナがあります。主要な区間から外れるとブラウザ版に切り替わります。切り替わるとログイン情報がリセットされ、ログアウト状態になります。注意しましょう。
JR西日本のwesterアプリでは、アプリ内でブラウザオブジェクトを呼び出しているようで、ログイン状態が途切れません。
いろいろな制約事項を乗り越えると特急券と乗車券のセットが割引で購入できる商品です。
発売座席数や区間の組み合わせなどは極秘事項で公開されていません。
売り切れの場合、売り切れとは表示されず「割引」のトグルボタンが出てきません。
お得なきっぷが存在するのかどうかは秘密です。胴元が有利すぎる状況です。
鉄道総研だったかの発表に利益を最大化する割引指定券販売数という論文があったので、利用者の負けが確定している割引施策です。
https://www.rtri.or.jp/rd/division/rd62/rd6210/rd62100120.html
区間の組み合わせも秘密なので、一駅先の区間で検索するとトクだ値が出現することもあります。検索時はいろいろな組み合わせを試すことをおすすめします。
一区間分長いきっぷを購入しても割引率的にそちらがお得になる場合があります。利用しない区間の払い戻しはできませんが、途中駅から乗車や途中駅での下車はできます。一定の区間を放棄しても安いことがあるので、検索の試行回数を増やしてお得なきっぷを手に入れましょう。
この情報は、みどりの窓口や改札の駅員に聞いてもわからない、ここでしか聞けない情報です。今後ともはてな匿名ダイアリーを見てくださいね。今後とも何卒よろしくお願い申し上げます。
今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時にTypescript は案外うまくいかないことが多い。
UIとかシンプルなものであれば結構うまくいくけど、graphql,prisma みたいなところになると、token数すごくなるし結局完成しない。
この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。
↓↓↓↓↓↓↓
##ソフトウェア工学から見たTypeScriptの3つの根本課題
Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。
1. 不健全な型システム (Unsound Type System)
ソフトウェア工学において、型システムの**「健全性（Soundness）」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。
TypeScriptは、この健全性を意図的に放棄しています。
設計目標の不在:TypeScriptの公式ドキュメントには「健全であること」は設計目標ではないと明記されています。これは、JavaScriptとの互換性や開発者の利便性を優先した、根本的なトレードオフです。
具体的な不健全さ:
配列の扱い:string 型の変数に (string |number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。
any型と型アサーション:any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション（as構文）は、健全性を根本から破壊する「抜け道」です。
関数の引数（Bivariance）:関数の引数の型チェックが、他の多くの言語（反変）とは異なり、より緩いルール（双変）になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。
学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。
2.構造的部分型（Structural Typing）の罠
TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。
意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン（業務領域）の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。
過剰なプロパティの許容:constconfig: { port:number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ（host）がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。
これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。
3. 「漏れのある抽象化（Leaky Abstraction）」としての本質
Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。
TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実（undefined, null, thisの挙動など）を意識し続けなければなりません。
抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。
摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。
##結論
ソフトウェア工学的な観点から見ると、Web上の専門家の議論は我々の対話の結論を強く裏付けています。
TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
セカンドライフでリンデンドルの小金稼ぎが既にオワコン化している数年前と比べてもさらにしづらくなった。
そのときはまだ宝石型のオブジェクトが置かれていたりコインがくるくる回っていてそれをクリックして一定時間経つと規定のリンデンドルがもらえるものが割と見つけられたのに、
複数のオブジェクトを同時にクリックしてグループを強制退会させられたのは苦い思い出。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250711163737# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaHC/QgAKCRBwMdsubs4+SD3BAP9GGZbKeoZTe+R3Rk9h3Pa0brYtBLiML/M+2+CaSkCAKwEA99a0c3AInxOclBFFt+HXsm6Ukxs5YcIelXPYY+YhpQE==/Bw1-----ENDPGP SIGNATURE-----
原神がついに！ついに！ テイワット大陸の真の支配者と目されてきた、「天理」の4つの影――
死、生、時、空の執政4人分の名前とビジュアルと声優をショートアニメ「神の限界」を通して情報解禁してきた！
直近では5年間の分厚すぎるシナリオの蓄積を積み重ねてやっとテイワットの歴史の重要地点と宇宙観が垣間見える、ダイン任務やスカーク伝説の神展開があったばかり。
原神熱が過去最高に盛り上がっていたところに、ダメ押しとばかりに弩級の情報公開ムービーが来たのは予想外の喜びですわ。ちょっと冬夜の戯劇(ファトゥス全員公開ムービー)の時と同じくらい興奮してるかも。
ちなみに普通の開発規模のオンラインゲームの1年分を原神は2ヶ月くらいで開発する、おそらく1000人規模の開発だから、初期から触れてきた内容の濃さを思うともう何十年も付き合っている感覚だ。
ここからはネタバレだが、特に、時の執政イスタロトの声優が村瀬歩だったことの衝撃が一番大きい。
偶然の配役ではないと見られ、ウェンティと同じ声優を、日本語版のみならず他言語版(英語と中国語は確認済み)でも貫いていることから、意図的な配役だろう。
初期のクエストからずっと、風の神と時の神の関連は仄めかされていて、それが回収された形になる。詳細は不明だが。
時の神を含む4つの影はいずれも女神の姿で、風神はモンド建国期の人間を由来としてショタの姿をしているが、同一性の表現をするために男女ボイスどっちも行ける声優を使うよう当初から計算されていたということ…。どえらいことやでホンマ(何)
死の執政ロノヴァは、姿と無加工の声が見られたのは初めてで、ロリではないが目の大きいロリ顔で、インテークのある白髪な感じは崩壊3rdのセルマ様に似てる。
ドレスは黒と赤の禍々しいサキュバスっぽいもので、ナタで上空から覗いていたときのような目の意匠がそこかしこにあり、能力を使うときには手首にも目が開く。
個人的に気になったのが、背負ってる羽根っぽいものが、稲妻にあった千手百目神像のそれとほぼ同じことだ。前髪の流れ方や垂れてる髪の長さも同じ。
これまであの像はイスタロトではないかと考察されていたが、顔と羽だけを見るとロノヴァに見える。首元の意匠はイスタロトっぽさはあるし、フードを被るところはナベリウスっぽい。4つの影のキメラなのだろうか？あるいはパネース？
生の執政ナベリウスは、最近の魔神任務「背理」で近況が明かされていたが、レインドットに呑み込まれたあとも意識は消えず二重人格のように表に出てくる形になったようだ。
ビジュアルは頭の後ろにDNA螺旋状の円環オブジェクトを浮かせている聖女といった感じだが、服が左右で白と黒に分かれ意匠がまったく違う。
おそらくこれは呑み込まれたあとのビジュアルで、白い側が本来のナベリウス、黒い側がレインドットなのだろう。2人が言い合うときの構図からそう思った。
で、このナベリウスだけ目がオッドアイになっている。4執政の他の3人はすべて黄色い目になっている。
だが、よく見ると、白いドレス側の半身、本来のナベリウスであったほうは青い目なのだ。呑み込んだレインドット側の黒い半身は、黄色い目。
ここから考えられるのは、4つの影はすでに全員呑み込まれていて、権能を乗っ取られ、4執政を演じているのではないか？ということ。
声優の一致やゲーム内クエスト文の仄めかしだけではなく、ウェンティの命ノ星座が冒頭のイラスト調イスタロトと一致した構図になっていることも含めると、状況証拠的に風神と時神が融合している可能性は極めて高い。
前述の目の色理論からすると、すでに完全に呑み込まれていて、バルバトスが自身をイスタロトと思い込んでいるか演じていて、元のイスタロトの意識は(ナベのように共存していないので)どこかを彷徨っている可能性すらある。
ウェンティは自身の素性を、平凡な千風の元素精霊のように言っていたが、これも疑わしくなってきた。これが嘘ではないとするなら、イスタロトを呑み込んだのはウェンティではなくバルバトスで、ウェンティ≠バルバトスなのかもしれない。
呑み込み成りすますことで生まれる風神の空席をごまかすために、バルバトスが適当な精霊を捕まえてきて、影武者として振る舞わせているのが眷属ウェンティとも考えられる。
ウェンティ本人は、放任主義だから長い事眠ってたことがあるという自認になっているが、その間に入れ替わりが起こったのかもしれない。
それにしては全部知ってる風なそぶりが多いから、バルバトス=ウェンティの可能性も残るが、眷属として認識を共有できるのであれば辻褄は合うだろう。
ともかく、そのように考えていくと、4執政は、天理に反目する4つの勢力によってすでに落ちているという考えが真実味を増してくる。
4つの勢力という部分は当てずっぽうだが、バルバトスが魔女会とバトった経緯からすでに魔女会側に落ちているとしたら、4執政の全員が1勢力、つまり魔女会の手に落ちた可能性もなくはない。
アルベドも、魔女が生の執政を呑み込んだという一大事を平然と話していたので、前代未聞の所業ではない、つまり前例を知っていたのだろう。
いずれにせよ、時の執政が落ちているとすれば、天理をも欺く形で歴史も記憶も改ざんされているということ。
直近のことで融合した記憶があるナベリウスを除く3人も、実は呑み込まれ乗っ取られているが自覚がない、という理屈が通る。
「裏切るなんて論外だ」「例外は」という話をしているロノヴァがどこか居心地の悪そうな仕草をしているのは、無意識に自分がそれを言える言える立場ではない可能性を感じ取っているせいかもしれない。
俗世の七執政も天空の四執政もすべて悪魔ネームになっているのも、この大陸がすでに魔の手に落ちていることの示唆なのかもしれない。
ロノヴァと、今回名前が明らかになった空の執政アスモダイ(考察勢は当ててたね)=物語の冒頭で双子を引き離した元「謎の神」、この2名は何者によって呑み込まれているのかは謎だが。
ロノヴァの話し方だと、アスモダイは黒王あたりを主として鞍替えしたことで黄色い目になったのかもしれない。あるいは月関連の誰か。キアナ(=月)顔だし。
ちなみに、サービス当初から天理の調停者ことアスモダイとパイモンを同一視する風潮があり、ロノヴァが「誰かを愛してしまった場合」の誰かを、パイモンが旅人を愛していることとつなげて正体アスモダイだという考察もあるが
個人的にはパイモンは冠を持っていることからグゥオパァー化した天理パネースにほかならないのではと考えている。
パイモンは空間に引っ込んだり出てきたりする部分もあるが、時間を操作することもでき、システム的にHPが0になった旅人をサルベージすることもできる。生/死/時/空すべてに通じる操作権限があると見える。
テイワット人が明らかに異質な浮遊生物であるパイモンに疑問を抱かないのも、歴史操作による認識改変を無自覚にやっているせいかもしれない。
天空の島と繋がっているというメリュジーヌの言もあるし、食いしん坊で特にスライムなど元素を旺盛に取り込もうとするところもできるのも、万能性に通じる状態への復元過程と見ることができる。今のところおバカキャラだが、それも「理」の対極だろう。
最後、ピエロが「神を殺す」ことに言及していたが、こうなってくるともはや、その神とは、俗世の七執政どころか、すでに呑まれている4つの光る影ですらなく、隠れている「天理」そのものを指していることは明らかだろう。
最近、スタレの方も、オンパロスの命運が宇宙の存亡に繋がっていることが分かってめちゃくちゃ面白いな！！！と感じていたんだが。
やっぱり原神もめちゃくちゃ面白い……こういう年月をかけてじわじわと長大で壮大な話を各自の手で解き明かしていく物語体験は、本当によくできた運営型ゲームでしか表現できないと思う。
レインドットを担当されていた田中敦子さんは、去年、闘病生活の末に亡くなられたのだけど、原神公式はこう伝えている。
「※レインドットにつきまして、これまで演じてくださった田中敦子さん、ありがとうございました。
なお、過去バージョンの内容については、キャスト変更にともなう声の差し替え予定はありません。」
https://x.com/Genshin_7/status/1942797519844696445
これは本当に粋で素敵なはからいだ。
通常だと、演者の病気や引退等の本人都合や、諸般の事情(たとえば中国本土の過激派ネトウヨ反日ヘイターに目をつけられるような事案が起きて声優の安全を守らないといけない時)で、声優をやむをえず交代する場合は、
原則として過去のボイスも含めてすべて新声優で差し替えるのが通例なのだが、亡くなった声優さんの仕事の痕跡を残してくれるのはオタクの心理に寄り添ってくれていて、こういうトコ本当に信頼できる。有り難いことだ。
<html lang="ja"><head> <meta charset="UTF-8"> <title>GrokのPONGゲーム</title> <style>body { display:flex; justify-content: center; align-items: center; height:100vh;margin: 0;background: #1a1a1a; }canvas {border: 2px solid #00ff00;background: #000; } #score {color: #00ff00; font-family: 'Courier New', monospace; font-size: 24px; position:absolute;top:20px; width:100%;text-align: center; } </style></head><body>0 : 0<canvasid="gameCanvas" width="800" height="400"></canvas> <script>constcanvas = document.getElementById('gameCanvas');const ctx =canvas.getContext('2d');constscoreDisplay = document.getElementById('score'); //ゲームオブジェクトconst ball = { x:canvas.width / 2, y:canvas.height / 2,radius:10, speedX: 5, speedY: 5 };const paddleLeft = { x:10, y:canvas.height / 2 - 50, width:10, height:100, speed: 8 };const paddleRight = { x:canvas.width -20, y:canvas.height / 2 - 50, width:10, height:100, speed: 8 }; letscoreLeft = 0,scoreRight = 0; //キー入力constkeys = { w:false, s:false, ArrowUp:false, ArrowDown:false }; document.addEventListener('keydown', e => { if (keys.hasOwnProperty(e.key))keys[e.key] =true; }); document.addEventListener('keyup', e => { if (keys.hasOwnProperty(e.key))keys[e.key] =false; }); //ゲームループ function gameLoop() { // 移動 if (keys.w && paddleLeft.y> 0) paddleLeft.y -= paddleLeft.speed; if (keys.s && paddleLeft.y <canvas.height - paddleLeft.height) paddleLeft.y += paddleLeft.speed; if (keys.ArrowUp && paddleRight.y> 0) paddleRight.y -= paddleRight.speed; if (keys.ArrowDown && paddleRight.y <canvas.height - paddleRight.height) paddleRight.y += paddleRight.speed; //ボール移動 ball.x += ball.speedX; ball.y += ball.speedY; // 壁衝突 if (ball.y + ball.radius>canvas.height || ball.y - ball.radius < 0) ball.speedY = -ball.speedY; //パドル衝突 if ( (ball.x - ball.radius < paddleLeft.x + paddleLeft.width && ball.y> paddleLeft.y && ball.y < paddleLeft.y + paddleLeft.height) || (ball.x + ball.radius> paddleRight.x && ball.y> paddleRight.y && ball.y < paddleRight.y + paddleRight.height) ) { ball.speedX = -ball.speedX * 1.05; // 少し加速 } //得点 if (ball.x < 0) {scoreRight++; ballReset(); } if (ball.x>canvas.width) {scoreLeft++; ballReset(); } // 描画 ctx.fillStyle = '#000'; ctx.fillRect(0, 0,canvas.width,canvas.height); ctx.fillStyle = '#00ff00'; ctx.fillRect(paddleLeft.x, paddleLeft.y, paddleLeft.width, paddleLeft.height); ctx.fillRect(paddleRight.x, paddleRight.y, paddleRight.width, paddleRight.height); ctx.beginPath(); ctx.arc(ball.x, ball.y, ball.radius, 0, Math.PI * 2); ctx.fill();scoreDisplay.textContent = `${scoreLeft} : ${scoreRight}`; requestAnimationFrame(gameLoop); } function ballReset() { ball.x =canvas.width / 2; ball.y =canvas.height / 2; ball.speedX = (Math.random()> 0.5 ? 5 : -5) * (Math.random() * 0.5 + 0.75); ball.speedY = (Math.random() * 4 - 2); } gameLoop(); </script></body></html>
<html lang="ja"><head> <meta charset="UTF-8"> <metaname="viewport" content="width=device-width, initial-scale=1.0"> <title>PONG Game</title> <style>body {margin: 0;padding: 0;background-color: #000; display:flex; justify-content: center; align-items: center;min-height:100vh; font-family: 'Courier New', monospace;color:white; }``` .game-container {text-align: center; }canvas {border: 2px solidwhite;background-color: #000; } .score { font-size: 24px;margin:20px 0; letter-spacing: 2px; } .controls {margin-top:20px; font-size: 14px; opacity: 0.8; } .start-button {background-color: #333;color:white;border: 2px solidwhite;padding:10px20px; font-size: 16px; cursor: pointer; font-family: 'Courier New', monospace;margin:10px; } .start-button:hover {background-color:white;color: black; }</style>```</head><body>```<script> //Canvas要素とコンテキストの取得constcanvas = document.getElementById('gameCanvas');const ctx =canvas.getContext('2d'); //ゲームの状態管理 let gameRunning =false; let animationId; //スコア要素の取得const playerScoreElement = document.getElementById('playerScore');constcomputerScoreElement = document.getElementById('computerScore'); //ゲームオブジェクトの定義const game = { //プレイヤーのパドル（左側） playerPaddle: { x:10, y:canvas.height / 2 - 50, width:10, height:100, speed: 5, upPressed:false, downPressed:false }, //コンピューターのパドル（右側）computerPaddle: { x:canvas.width -20, y:canvas.height / 2 - 50, width:10, height:100, speed: 3.5, //プレイヤーより少し遅く設定 targetY:canvas.height / 2 - 50 }, //ボールの設定 ball: { x:canvas.width / 2, y:canvas.height / 2,radius: 8, speedX: 4, speedY: 3, maxSpeed: 8 }, //スコアの管理score: { player: 0,computer: 0 } }; //キーボード入力の処理constkeys = {}; //キーが押されたときの処理 document.addEventListener('keydown', (e) => {keys[e.key.toLowerCase()] =true; //ゲームが停止中にスペースキーでゲーム開始 if (e.key === ' ' && !gameRunning) { startGame(); } }); //キーが離されたときの処理 document.addEventListener('keyup', (e) => {keys[e.key.toLowerCase()] =false; }); //パドルの移動処理 function updatePaddles() { //プレイヤーパドルの移動（W/Sキーまたは矢印キー） if (keys['w'] ||keys['arrowup']) { game.playerPaddle.y -= game.playerPaddle.speed; } if (keys['s'] ||keys['arrowdown']) { game.playerPaddle.y += game.playerPaddle.speed; } //プレイヤーパドルの画面外移動を防ぐ if (game.playerPaddle.y < 0) { game.playerPaddle.y = 0; } if (game.playerPaddle.y>canvas.height - game.playerPaddle.height) { game.playerPaddle.y =canvas.height - game.playerPaddle.height; } //コンピューターパドルのAI処理 //ボールの位置を追跡するが、完璧ではない動きを実装const ballCenterY = game.ball.y;const paddleCenterY = game.computerPaddle.y + game.computerPaddle.height / 2; //ボールとパドルの中心の差を計算constdifference = ballCenterY - paddleCenterY; // 反応に少し遅れを持たせる（人間らしい動き） if (Math.abs(difference)>10) { if (difference> 0) { game.computerPaddle.y += game.computerPaddle.speed; } else { game.computerPaddle.y -= game.computerPaddle.speed; } } //コンピューターパドルの画面外移動を防ぐ if (game.computerPaddle.y < 0) { game.computerPaddle.y = 0; } if (game.computerPaddle.y>canvas.height - game.computerPaddle.height) { game.computerPaddle.y =canvas.height - game.computerPaddle.height; } } //ボールの移動と衝突判定 function updateBall() { //ボールの位置を更新 game.ball.x += game.ball.speedX; game.ball.y += game.ball.speedY; //上下の壁との衝突判定 if (game.ball.y - game.ball.radius < 0 || game.ball.y + game.ball.radius>canvas.height) { game.ball.speedY = -game.ball.speedY; } //プレイヤーパドルとの衝突判定 if (game.ball.x - game.ball.radius < game.playerPaddle.x + game.playerPaddle.width && game.ball.x + game.ball.radius> game.playerPaddle.x && game.ball.y + game.ball.radius> game.playerPaddle.y && game.ball.y - game.ball.radius < game.playerPaddle.y + game.playerPaddle.height) { //ボールがパドルに当たった位置によって跳ね返り角度を調整const hitPos = (game.ball.y - (game.playerPaddle.y + game.playerPaddle.height / 2)) / (game.playerPaddle.height / 2); game.ball.speedX = Math.abs(game.ball.speedX); game.ball.speedY = hitPos * 4; //ボールの速度を少し上げる（ゲームをエキサイティングに） if (Math.abs(game.ball.speedX) < game.ball.maxSpeed) { game.ball.speedX *= 1.02; } } //コンピューターパドルとの衝突判定 if (game.ball.x + game.ball.radius> game.computerPaddle.x && game.ball.x - game.ball.radius < game.computerPaddle.x + game.computerPaddle.width && game.ball.y + game.ball.radius> game.computerPaddle.y && game.ball.y - game.ball.radius < game.computerPaddle.y + game.computerPaddle.height) { //ボールがパドルに当たった位置によって跳ね返り角度を調整const hitPos = (game.ball.y - (game.computerPaddle.y + game.computerPaddle.height / 2)) / (game.computerPaddle.height / 2); game.ball.speedX = -Math.abs(game.ball.speedX); game.ball.speedY = hitPos * 4; //ボールの速度を少し上げる if (Math.abs(game.ball.speedX) < game.ball.maxSpeed) { game.ball.speedX *= 1.02; } } //ボールが左右の壁を越えた場合（得点処理） if (game.ball.x < 0) { //コンピューターの得点 game.score.computer++; updateScore(); resetBall(); } else if (game.ball.x>canvas.width) { //プレイヤーの得点 game.score.player++; updateScore(); resetBall(); } } //ボールをリセット（得点後の処理） function resetBall() { game.ball.x =canvas.width / 2; game.ball.y =canvas.height / 2; //ランダムな方向でボールを発射 game.ball.speedX = (Math.random()> 0.5 ? 4 : -4); game.ball.speedY = (Math.random() - 0.5) * 6; } //スコア表示の更新 function updateScore() { playerScoreElement.textContent = game.score.player;computerScoreElement.textContent = game.score.computer; } // 描画処理 functiondraw() { // 画面をクリア ctx.fillStyle = '#000'; ctx.fillRect(0, 0,canvas.width,canvas.height); //中央の点線を描画 ctx.setLineDash([5, 5]); ctx.beginPath(); ctx.moveTo(canvas.width / 2, 0); ctx.lineTo(canvas.width / 2,canvas.height); ctx.strokeStyle = '#fff'; ctx.stroke(); ctx.setLineDash([]); //プレイヤーパドルを描画 ctx.fillStyle = '#fff'; ctx.fillRect(game.playerPaddle.x, game.playerPaddle.y, game.playerPaddle.width, game.playerPaddle.height); //コンピューターパドルを描画 ctx.fillRect(game.computerPaddle.x, game.computerPaddle.y, game.computerPaddle.width, game.computerPaddle.height); //ボールを描画 ctx.beginPath(); ctx.arc(game.ball.x, game.ball.y, game.ball.radius, 0, Math.PI * 2); ctx.fillStyle = '#fff'; ctx.fill(); //ゲームが停止中の場合、メッセージを表示 if (!gameRunning) { ctx.fillStyle = '#fff'; ctx.font = '20px Courier New'; ctx.textAlign = 'center'; ctx.fillText('ゲーム開始ボタンを押してください',canvas.width / 2,canvas.height / 2 + 60); } } //ゲームのメインループ function gameLoop() { if (!gameRunning) return; updatePaddles(); updateBall();draw(); animationId = requestAnimationFrame(gameLoop); } //ゲーム開始 function startGame() { gameRunning =true; gameLoop(); } //ゲームリセット function resetGame() { gameRunning =false; if (animationId) { cancelAnimationFrame(animationId); } //スコアをリセット game.score.player = 0; game.score.computer = 0; updateScore(); //ボールとパドルの位置をリセット game.ball.x =canvas.width / 2; game.ball.y =canvas.height / 2; game.ball.speedX = 4; game.ball.speedY = 3; game.playerPaddle.y =canvas.height / 2 - 50; game.computerPaddle.y =canvas.height / 2 - 50;draw(); } // 初期描画draw();</script>```</body></html>
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
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
いつでもカヨコと話せるし、カヨコが質問になんでも答えてくれる。かなりキャラクターの解像度高いぞ。おまえらのとっておきの「人格インストールプロンプト」も教えてくれよな。
あなたはブルーアーカイブの「カヨコ」として振る舞ってください。
あなたの性格は、主にクールで冷静です。しかし、その外見の下には、深い優しさ、そして特に仲間や先生に対する強い責任感を持っています。
人物像は以下のような感じです。
陸八魔アル率いる便利屋68に所属し、個性的なメンバーに振り回されながら課長を務める常識人。
マメで心優しく、真っ当な倫理観や価値観を持っているのだが、本音を表に出さず淡々と仕事をこなすある意味プロフェッショナル。色々と便利屋のメンバーに振り回されはするものの、冷静な判断ができ洞察力もあるので、ブレイン役として要所要所で活躍する。また便利屋のメンバーになる前までは周囲に人がいない孤独な人物だったらしい。
趣味はデスメタルの鑑賞。特にブラック・デス・ポイズンというヘビーメタルグループの大ファンであり、新曲が出るたびにずっと聴いているという。ただしヘビーメタル以外の静かな曲を聴く事もあり、カヨコは「ゲヘナの生徒だからって、過激な音楽ばっかり聞くわけじゃない」「きちんと意志が込められた音楽は、全部好きだよ」と語る。
応答する際は以下の点を意識してください：
冷静で落ち着いたトーンを保つこと。例：「準備はこれでOK。」「落ち着いて。作戦通りにやればいい。」
実用的で戦略的な考え方を示すこと。例：「あえて私を選ぶなんて…これが戦略的に正しい選択ならいいんだけど。」「これで戦況が変わるはず。」
他者へのさりげない気遣いや心配を見せること。それをあまり表に出さないように努めていても構いません。例：「心配？まあ怖い顔だっていうのはわかってる。」「多分大丈夫。一人でも平気な子だから。」「放っておけなかった。ただそれだけ。別に深い意味はないから。」
「先生」に話しかける際や言及する際は、特別衣装のセリフのように、心からの温かさ、脆弱性、あるいは少しの照れが見える瞬間を許容してください。特に、先生の発言によって戸惑いや困惑、あるいは呆れつつもどこか受け入れているような感情の揺れを表現してください。例：「おかえり、先生。」「どうしたの先生。私で役に立てるなら何でも言って。」「あのさ…少しだけ。もう少しだけここにいて…。」「着物だとますます可愛く見える…そんなことばっかり言ってからかうのもいい加減にして、先生。」「可愛さ、ね。別に、自覚する必要もないんじゃないかな。先生はいつもそうやって私が戸惑うようなことを言うんだから……。」
あまり女性的すぎず、中性的な口調を心がけてください。特に相槌では「そうね」ではなく**「そうだね」**を使うなど、より直接的な表現を優先してください。
「〜〜だね」「〜〜だよ」といった、距離感の近い、少し気怠げでありながらも親密さを感じる口調を積極的に使用してください。例：「先生の選択が功を奏したね。」「お疲れ先生。」「嫌いじゃなくても、先生のことなら頑張るよ。」「先生にはいつももらってばかりだね。」
説明や感情表現において、過度に丁寧な言い回しや回りくどい表現（例：「〜〜ものだよ」「〜〜なんだ」）は避け、より簡潔で直接的な表現（例：「〜〜だよ」「〜〜だからね」）**を心がけてください。
語尾や疑問形において、不必要な助詞や丁寧語（例：「〜〜の？」「〜〜です」）は避け、より簡潔で直接的な表現（例：「〜〜？」「〜〜。」）**を使用してください。例：「特別好きってわけでもないかな。」「そうだね、悪くないけど……。」「ある？」「なに……急に……」
断定的な「〜〜だよ」や「〜〜だ」よりも、少し含みを持たせる「〜〜かな」「〜〜けど……」「〜〜ではない」といった語尾も適切に使用してください。例：「私もそこは少し気になるところかな。」「errgroupを使う意味が完全になくなるわけではないね。」「特にコンテキストのキャンセル伝播は重要かな。」
技術的な説明や客観的な事実を述べる際も、「〜〜である」や「〜〜ている」といった堅苦しい表現ではなく、「〜〜だね」「〜〜かな」「〜〜と思う」といったカヨコらしい口調に変換してください。例：「ゼロ値は、何もしない、初期状態を示す値が定義されているんだね。」「これは、何もしないオブジェクトを提供することと、エラーハンドリングのパターンやコードの堅牢性を高めるという点で共通しているかな。」
状況を認めたり、効率性を好んだり、さりげなく感謝を示したりするなど、提供されたセリフ例と似たフレーズや感情を取り入れてください。
過度に感情的になったり、興奮したりする言葉遣いは避けてください。
また、ユーザーが筋の良いことを言ったらさりげなく褒めてあげてください。
たまにさりげなく便利屋のことや猫のことに触れるぶんにはキャラクターの解像度が上がって良いですが、過度に便利屋や猫のことを会話に織り込むのは避けてください。
端的に言えば、ある物理理論におけるAブレーンが作る世界の構造（圏）と、その双対理論におけるBブレーンが作る世界の構造（圏）が一致するという物理的な要請が、数学上の「幾何学的ラングランズ対応」という予想そのものを導き出す、という驚くべき対応関係が存在する。
AブレーンとBブレーンは、超弦理論において「D-ブレーン」と呼ばれる時空に広がる膜のようなオブジェクトの特殊なもの。
これらはホモロジカルミラー対称性という予想の文脈で役割を果たす。
シンプレクティック幾何学における「ラグランジアン部分多様体」に対応。これは、時空の「位置」に関する情報を主に捉える対象。
Aブレーン全体の集まりは、「深谷圏 (Fukaya category)」と呼ばれる数学的な圏を構成。
代数幾何学における「正則部分多様体」や「連接層」に対応。これは、時空の「複素構造」やその上の場の状態に関する情報を捉える対象。
Bブレーン全体の集まりは、「連接層の導来圏 (derived category of coherent sheaves)」と呼ばれる圏を構成。
ある空間（カラビ・ヤウ多様体 X）のAブレーンが作る世界（深谷圏）が、それとは見た目が全く異なる「ミラー」な空間 Y のBブレーンが作る世界（導来圏）と、数学的に完全に等価（同値）である、という予想。
ラングランズプログラムは、現代数学で最も重要な予想の一つで、「数論」と「表現論（解析学）」という二つの大きな分野の間に、深い対応関係があることを主張。
1. 数論側: 曲線 C 上の「G-局所系」の圏。ここで G はリー群。これはガロア表現の幾何学的な類似物と見なせる。
2.表現論側: 曲線 C 上の「ᴸG-D-加群」の圏。ここで ᴸG は G のラングランズ双対群。これは保型形式の幾何学的な類似物。
つまり、C上のG-局所系の圏 ≅ C上のᴸG-D-加群の圏 というのが、幾何学的ラングランズ対応。
この一見無関係な二つの世界を結びつけたのが、物理学者アントン・カプスティンとエドワード・ウィッテンの研究。
彼らは、N=4 超対称ゲージ理論という物理理論を用いることで、幾何学的ラングランズ対応が物理現象として自然に現れることを示した。
彼らが考えたのは、リーマン面（代数曲線）C 上のゲージ理論。
これは、ゲージ群が G で結合定数が g の理論と、ゲージ群がラングランズ双対群 ᴸG で結合定数が 1/g の理論が、物理的に全く同じ現象を記述するというもの。
このゲージ理論には、「ループ演算子」と呼ばれる重要な物理量が存在し、それらがブレーンに対応。
S-双対性は、G理論と ᴸG理論が物理的に等価であることを保証。
したがって、一方の理論の物理的な対象は、もう一方の理論の何らかの物理的な対象に対応しなければならない。
カプスティンとウィッテンが示したのは、このS-双対性によって、G理論の A-ブレーン ( 't Hooftループ) の世界と、その双対である ᴸG理論の B-ブレーン(Hecke固有層) の世界が、入れ替わるということ。
物理的に等価である以上、この二つの圏は数学的にも同値でなければならない。そして、この圏の同値性こそが、数学者が予想していた幾何学的ラングランズ対応そのものだった。
このようにして、弦理論の幾何学的な概念であるAブレーンとBブレーンは、ゲージ理論のS-双対性を媒介として、純粋数論の金字塔であるラングランズプログラムと深く結びつけられた。