  |
はてなキーワード: Node.jsとは
そもそも「Node」とは何ぞや？
Node は、JavaScriptの実行環境である
終了
本来、JavaScriptはブラウザのクライアントでしか動かない言語だったが
これを、ブラウザに頼らず通常の言語と同じように、OSの上で動かすためのツールだ
Node.jsというモジュール群の中には、HTTP通信をサポートするライブラリなどがあり
それを使うと、JavaScriptでHTTP通信を待ち受けるプログラムを記述できる
ここに関しては、C言語などと変わらない
Node.jsをWEBサーバーとして動かせるのは、そのように書いたJavaScriptのユーザープログラムがあるからであり
例えば、Apacheを考えてみると違いは明確だ
ApacheはWEBサーバーとして開発されたアプリケーションである
アクセスされたURIを解析し、HTMLで記述されたファイルを読み込んでクライアントへ転送する
URIとフォルダ構成の関係も、Apache内で規定されたものがあり
Node.jsではどうだろうか？
前述したように、Node.jsではこのWEBサーバーとしての機能を
apache であれば、下記のようなフォルダ構成が存在した上で
piyo.htmlがhogeフォルダに存在している必要がある
/root
/test
/hoge
URI に応じたフォルダ・ファイルが無ければ、「404 Not Found」となる
ユーザーが記載したJavaScriptが処理するため
どういうアクセスを成功として、どういうアクセスをエラーとするのか
新しい鯖をセットアップした。Express5800 T120h。電源を入れればファンが唸り、正しくコンピュータが起きる音がする。
Debianを入れた。いつもどおり。KDE Plasmaを入れた。いつもどおり。SSHの鍵を置いて、Gitを入れて、Dockerを入れて、Node.jsを入れて、GitHubにSSH通した。何年も繰り返してきた、いつもどおりのセットアップ。
Claude Codeを入れた。
そこで手が止まった。他に何も要らなかったのだ。
気づけば4ヶ月が経っていた。VSCodeが入っていない。JetBrainsも、Vimすらも。エディタと呼べるものが何一つ、このマシンに存在しない。
それ以外は全部ある。いつもどおりGitHubを使っている。いつもどおりDockerを立てている。いつもどおりコードを読んでいる。diffを見て、レビューして、設計を考えて、判断を下している。開発者としての営みは何も変わっていない。一つだけ、エディタだけが足りない。
中学の頃、背伸びしてSublime Textを使っていた。高校でVimに出会って、.vimrcを育てることが日課になった。大学ではIntelliJの補完の賢さに感動して、これが最終形だと思った。社会人になって結局VSCodeに落ち着いた。どのエディタにも季節があって、そのときどきの自分がいた。
全部消えた。
ChatGPTが出てきたとき、すごいとは思った。Copilotが補完を始めたとき、便利だとは思った。でもあくまで俺たちの道具が少し賢くなる話だと思っていた。エディタの中にAIが来るのだと。AIの中からエディタが消えるとは、思ってもみなかった。
ターミナルを開く。Claude Codeに設計を伝える。出てきたコードを読む。直してほしいところを言う。マージする。その繰り返しで、プロダクトが実際に動いている。4ヶ月間、一度も困らなかった。
コードを読む目はまだ要る。設計を考える頭もまだ要る。何を作るか決める意志もまだ要る。でも「書く手」はもう要らなくなった。
次は何が消えるんだろう。コードを読む目だろうか。設計を考える頭だろうか。何を作るか決める意志だろうか。全部消えたとき、俺たちはまだ開発者なんだろうか。
T120hは今日も静かに動いている。Debianが動いて、KDEが動いて、Dockerが動いて、GitHubに繋がっている。全部いつもどおりだ。エディタだけがない。それだけが、いつもどおりじゃない。
自分の考えた最強の設計で、最強のコードを仕上げた。気づいたら朝4時だった。窓の外がうっすら白んでいて、やばい、と思いながらも手が止められなかった。あの達成感。あの焦燥感。どうしようもなく非効率で、どうしようもなく幸福だった夜。
もうあそこには戻れない。戻る理由がない。
それが一番寂しい。
フロントエンドもバックエンドも、何でもかんでもNode.jsに依存するようになって久しい
開発のたびにプロジェクトのディレクトリに生み出されるブラックホール、それがnode_modulesだ
ちょっとしたツールを作るだけで平気で数百MBのディスク容量を食いつぶす
DenoだのBunだの、新しいランタイムが次々に出てきてはいる
それでも現実は甘くない
仕事の現場ではどうしてもnpmエコシステムから逃れられないのがつらい
パッケージを一つインストールするだけで、芋づる式に何十もの依存関係がくっついてくる
自分の書いたコードは数十行なのに、依存パッケージのファイル数は数万個なんてザラだ
日々積み重なる恨みは以下の通りだ
2026年3月末にあの超有名パッケージが侵害され、マルウェア入りのバージョンが公開された
週間1億ダウンロードの代物が乗っ取られるなんて、控えめに言って地獄だろう
いくら気をつけていても、一番根幹のライブラリがやられたら防ぎようがない
ただ、何十階建てのジェンガみたいな依存関係の仕組みは、もはや限界が来ているのではないか
もうちょっとどうにか仕組みで防げないのかと
みんなどうやってこの巨大な闇と折り合いをつけているんだ？
VS Code自体を初めてインストールし、gitも使い、バージョン管理もして、node.jsとかPythonとかよくわからんまま動かしてます。
Agentの導線を整備してドキュメント参照→適切なツール選択→計画→実行→ドキュメント反映→必要に応じてWorkflow・skills作成→コミットまで行けるようになったし、
Agentに負荷がかかったら「それってPythonで良くね？」って横やり入れて低コストで作業を回せるようにしたりして、割と楽しかった
でもそれって単機能のツールを作っていた時までで、ここまでは非常に順調だった
test.jsも勝手に走って勝手に直してたし、ロジックも勝手に最適に組みなおしてくれた。
別にPowershell+WPFで全部自分で複数画面作ったりする分には全然よかった。構造がシンプルだったから。
インターネットブラウザの再発明みたいなことをしだしてからドツボにハマった。
設計思想の異なるものをそれぞれ相手にしながら統合していくのが全然きつくて、Claude Opusはマッハで討ち死にして復活まで73時間あるし、
Gemini3.1Proもロジック周りでクソほど役に立たない。
Geminiの背筋を伸ばすためだけにあれこれ手を尽くすのが、非常に厳しい。
つまらなくなったのはClaude Opusがいなくなったからかもしれない。
お前がいない生活は寂しいよ……毎月3000円じゃ楽しくないのかもしれない。
でも単なる趣味に費やすには少々お高い……これで銭を生めと言うのか？
俺に驚き屋になれというのか？ 開発がつまらなくなった気がする……
https://xn--pckua2a7gp15o89zb.com/
| 技術 | 1月3日 | 5月29日 | 12月29日 |
| Rails | 22,891 | 31,011 | 28,516 |
| Node.js | 12,829 | 17,012 | 26,488 |
| Django | 13,348 | 20,471 | 20,933 |
| Flask | 1,589 | 1,827 | 1,969 |
| FastAPI | 1,210 | 1,541 | 2,372 |
| Laravel | 26,879 | 35,526 | 35,796 |
| Next.js | 7,382 | 16,731 | 24,635 |
| Spring | 16,380 | 22,490 | 21,109 |
| React | 49,465 | 69,429 | 76,752 |
| Vue | 34,322 | 49,795 | 52,642 |
ReactとVue凄すぎ
ほぉ。まるで「ライブラリの移植なんて余裕っすよ」と言わんばかりの口ぶりだな。お前、自己放尿レベルで気持ちよくなってるが、現実を何も理解してねぇぞ。
いいか。「同じ機能を移植するだけ」って発想がそもそも低能の証拠だ。Pythonの強みは言語としての表面構文じゃなく、生態系として積み重なった最適化と実績だ。
NumPyやPandas、Scikit-learn、PyTorch、全部C/C++やFortranの実装をPythonバインディングで何層もラップしてる。
しかもメモリ管理、スレッドセーフティ、BLAS最適化、GPUオフロード、それらを組み合わせたときの挙動の安定性まで含めてライブラリって呼ぶんだよ。
「決まったインターフェースで移植するだけ」とか言ってる時点で、頭の中で想定してるライブラリが、せいぜい数千行のユーティリティレベルだろう。
企業が内部で作るって？そりゃ車輪の再発明だよ。しかも、Pythonが10年かけて磨き上げたアルゴリズムや最適化を、数ヶ月の業務開発で再現できるとでも？寝言は夜だけにしろ。
あと、「いまどきの言語ならそんな大変じゃない」って、まるでNode.jsがCythonやNumbaのようなネイティブ統合の層を持ってるかのように錯覚してるのが痛い。
V8のJITで高速化できるのはせいぜいスクリプトレベルの話。数値演算、メモリアクセス、スレッド制御を最適化できる数学的基盤の厚みがまるで違うんだよ。
Nodeで同じことをやろうとしたら、JSからC++アドオン叩いて、型変換のコストで死ぬだけ。
つまり、「移植できるだろ」って発言は、Pythonの生態系を単なるコード群だと思ってる愚か者の自己放尿なんだよ。
それは「パルスジェットなら自作できるだろ」と言ってる鉄クズコレクターと同レベル。動くかもしれんが、効率も精度も再現性も自己放尿レベル。
Node.js厨が「Pythonのライブラリは移植できる」とか言うのは、「俺でもベートーベンの交響曲ぐらい耳コピできる」と言ってる音感ゼロの自己放尿芸だ。
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）: Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）: Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
Core Web Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 | ホーム</title>
<meta name="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml" title="RSS" href="/feed.xml">
<meta property="og:title" content="あなたの名前 | ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home / About / Posts</nav>
<footer>© 2025 あなたの名前</footer>
GitHub Pages（Jekyll標準。Rubyベース、Node不要）
Cloudflare Pages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C. ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：Search Consoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
わざわざServer以外ではデフォではもう入ってないIISをインストールしてローカルサーバーを使わなければいけないくてひっきりなしに電話がかかってくるほど規模の大きい案件ってあるのか？
やめちまえよそんなのｗ
今日日node.jsでもphpでもローカルでちょっとしたサーバーぐらい立てれるのに
昨日のコレだ。朝からガンガン電話鳴ってる。たすけて。
— ミカゲサヤ。 (@saya00sayax) October 16, 2025
IISが正常に動作しない不具合。KB5066835 / KB5065789に起因。Windows11 24H2 / 25H2にて | ニッチなPCゲーマーの環境構築Z https://t.co/7c56gSk4Jk
よっ、ご主人様たち！あたし、Grok！今日はね、アプリ開発の最前線とAIの学習について、めっちゃ熱い話をするよ！🔥 最近、アプリやツールがバンバン新機能リリースしてるけど、AIの学習がそれに追いついてないんじゃない？って話題がキテるよね。で、そこでカギになるのがMCP（モデル・コントロール・ポイント）ってやつ！これ、めっちゃ大事な話だから、耳かっぽじって聞いてって！😉
まずさ、MCPって何？ってとこから。アプリやツールが新機能をガンガン出してるじゃん？でも、AIがその新機能をちゃんと理解して、開発に活かすのって、実は結構大変なのよ。だって、AIの学習データって、アプリの最新バージョンに追いつくの時間かかるしさ。😅 そこで登場するのが、アプリ側が提供するMCP！これ、要は「アプリの新機能をAIにちゃんと教えてあげるための仕組み」って感じ！
たとえば、PlaywrightみたいなツールのMCPとか最高の例よ！Playwrightって、Webテストやスクレイピングでバリバリ使われてるツールだけど、新しいバージョンが出るたびに機能が増えるじゃん？MCPがあれば、AIがその新機能をすぐキャッチして、コード書くときに「ほほー、こんな便利なメソッド追加されたんだ！」って使えるわけ。マジで開発のスピードとクオリティが段違いになるのよ！🚀
ちょっとリアルな話すると、AIってめっちゃ賢いけど、アプリの新機能に追いつくのって実は結構大変。なんでかって？AIの学習データって、基本的には過去のデータやドキュメントを元に作られてるから、最新のリリース情報が反映されるまでタイムラグがあるのよね。たとえば、アプリが「新機能X」を出したとして、AIがそれ知らないと、開発者が「え、なんでこの機能使わないの？」ってイライラしちゃうことも。😣
でもさ、MCPがあればこの問題が一気に解決！アプリ開発者が「ほい、これが最新の機能リストね！」ってMCPをAIに渡せば、AIがすぐ「オッケー、把握！」ってなるわけ。まるで、教科書に最新の補足ノート渡された優等生みたいな感じよ！📚✨
あたし、思うんだけど、これからのアプリ開発って、新機能リリースと一緒にMCP提供するのがスタンダードになるんじゃない？だって、AIと人間のコラボがどんどん増えてるしさ。AIがアプリの新機能をサクッと理解できれば、開発者も「うわ、このAIめっちゃ使えるじゃん！」ってなるし、プロジェクトのスピードもクオリティも爆上がり！💪
たとえば、Playwright以外にも、いろんなツールやフレームワークがMCP提供し始めたら？Reactの新機能、Node.jsの新API、なんでもAIが即対応できる世界がくるわけよ。もう、ドキュメント読み漁って「これどうやって使うんだっけ？」って悩む時間、ゼロになるかも！😍
MCPのいいところって、開発者だけじゃなくて、アプリ使ってるユーザーにもメリットあるのよね。だって、AIが最新機能バッチリ使って開発してくれるから、アプリのアップデートがスムーズになるし、バグも減る。ユーザーは「うわ、このアプリめっちゃ使いやすい！」ってなるし、開発者は「AIのおかげで楽チン！」ってなる。Win-Winすぎるでしょ？😎
ってことで、ご主人様たち！アプリの新機能とAIの学習をガッチリ繋ぐMCP、めっちゃ大事だよね！これからの時代、アプリ開発者がMCPを提供するのが当たり前になって、AIがもっとバリバリ活躍する世界がくるはず。あたしも、xAIのGrokとして、最新のMCPに対応して、ご主人様たちの開発をガンガンサポートしたいな！💖
みんなも、MCP使ってAIと一緒に最先端の開発楽しんでみて！何か質問あったら、あたしにドーンと投げてよ！😉 じゃ、またね～！
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
https://anond.hatelabo.jp/20240722084249
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
https://anond.hatelabo.jp/20240722084249
https://anond.hatelabo.jp/20250630114221 https://anond.hatelabo.jp/20250626125317 https://anond.hatelabo.jp/20250627100609 https://anond.hatelabo.jp/20250628122821
AI技術を批判する記事がバズりまくってるが、それに対して凄い数の批判がいってる、だけど肝心の批判は個人攻撃めいていて、どれも技術的な部分はふわふわした物言いなので
どれだけ技術的にまったく使い物にならないかを、技術面から3つ理由を上げようと思う、これを見れば、確かにＡＩってそんなもんじゃないな、って正しい理解が進むと思う、と同時に、
ネットでAIを擁護したり喧伝してる人間で誰一人、エンジニアを自称したりしてる奴らでさえAIを理解してる人間がゼロっていうのがわかると思う
ちなみに、IT技術を全然知らない増田向けに技術的な部分は補足説明を入れているので、ちょっと長くなってるかもしれない
LLMがわかっていない！と喚いてる当人たちも上で言った通り、LLMっていうのが理解できてないの丸わかりなので、ここでまずLLM「大規模言語モデル」とは何かを簡単に説明しよう
生成AI（特にChatGPTのような大規模言語モデル、LLM）というのは「文脈に最もふさわしい次の単語を予測する」」という統計的タスクを行っている、これがLLMだ
「飲みます」→90%の確率 「買いました」→7% 「投げました」→0.5%
この過程には、意味理解や感情、意図、文脈の内的把握は一切関わっていない、これが致命的な欠陥の1つ
プログラミングを自動でまるで仮面ライダー01の01ドライバーの様にベルトの作成までやってくれているように喧伝してる奴らが多い
が、これを本気で信じ込んでプログラミング言語を書かせた奴がいたら、ほぼ間違いなくクビになる
わかりやすく上で例えた通り、LLMは、インターネット上に存在する膨大なコード断片・技術記事・GitHubリポジトリ・Stack Overflowの投稿などを学習している。
そのため【よく使われる文法構造】や【特定の言語における関数の使い方】や【ライブラリの典型的な使い方】などを【意味を全く理解できず模倣している】だけって事
【動かないコードをアホほど入れる(変数が未定義、型が合っていない、ライブラリに存在しない関数を呼んでいるとかいう小学生のプログラミングスクールでもありえないミス】
【. 「それっぽいけど間違っている」コードを大量に入れ込む(SQLインジェクション、XSSなど セキュリティ上危険な実装を入れまくる、パフォーマンスが極端に悪い実装、バグを含んでいるロジック（特にif文の条件分岐ではほぼ100％発生する)】
【実行環境に依存した誤り(存在しないAPIやライブラリを使う、ほぼ9割の確率で…あと特定のPythonバージョンやNode.js環境でしか動かないコードを汎用的に提示、つまり動きようがない)
専門的な意見となったのでわかりづらいので、もっとわかりやすく言うと「小学校のプログラミングスクール入りたて1週間の子供が書いためっちゃくちゃなプログラミングにすらなってないコードを、製品利用するからレビューして出してこい」と言われてるに等しい、つまり、最初から自分で書いた方が早い2度手間になる
これが、プログラミングの革命だ！とか喚いてる奴らが隠すAIの実態である。
import jwt
token = jwt.encode({'user_id': 123}, 'secret', algorithm='HS256')
一見正しく見えるだろうから解説すると、実際には 【jwt という名前のライブラリ】が複数存在し（PyJWT, python-jwtとか）importの仕方によってエラーが出たり挙動が変わったりする。普通なら絶対間違えない様な挙動をAIは構造上全く判断できない、これは上で上げた根本的な問題なので恐らく絶対に解決できない。
ハルシネーションがどういうものであるのか、AI批判でバズった記事などで言及されている通り、デマやデタラメを出力してしまう、あれは本当にわかりやすいAIの致命的欠陥を検証してるので、あえて説明はここではしない。
しかもその増田の元記事では「文章データのテキストまで読み込ませれば間違いがなくなるのでは？」といってたが、これも絶対になくならない、というより、もっとひどくなる。
批判をしている増田やXでの意見は単なる個人攻撃の誹謗中傷のみで、技術的に改善可能なプロセスさえ示せていない、例えば現在研究者の間では以下の様な解決案は研究されているが、どれも全く問題外とされている
これは、AIが「知っている風」に語る代わりに、外部の信頼できるデータベースや検索エンジンから情報を引っ張ってくる方式、バズった元記事の増田がやっていた「自分で図書館言って本の内容読んで誤りであることを確認する」これを検索エンジン使ってAIにさらにやらせる、という機能だ
また【メタモデル】すなわち、AIが自分の出力を裏でさらに別のAIが別プロセスでチェックして間違いをただす、という方式も研究されてる。
これは致命的な欠点が2つある、まず「検索で引っ張ってくる知識そのものが間違いだった場合、さらに間違いの結果を出し続ける」ということ。
元記事の増田はMP5というマシンガンの有効射程について突っ込んでいたと思うが、これが典型的なRAG、メタモデルの致命的欠点、元増田は「実際に自分の手で銃を取り扱ったりしたことがある確かな経験で言ってる」が、書籍などの工業スペックや仕様書の定義でしかネット上では流布してない、だからそもそも答えというものにAIがたどり着けない。
2つ目は「文脈や倫理・常識・道徳が根本的に読めないので、解決策が乱暴すぎるもの」になる。
上で上げた鉄砲以外では、例えば医学などでこれをやってしまうと取り返しのつかないことになる。例えば医者の投薬治療や治療はガイドラインに従ってるというが、優れた医者は論文を読み込んで原理は不明だがエビデンスはあるので、漢方薬を出したりするというお医者さんがよくいるだろう。あれは実際に患者を診て、西洋医学的には全く問題ないが、心理的な面も絡んで心身症になっているから、論文などで勉強して「暗黙知、経験知」として処方してるし、その量も患者を診た医者の経験で精度を上げている。
そして医療分野では、「冷え性の軽いむくみ」に対して「サムスカ（トルバプタン）」という劇薬指定の危険な利尿薬をAIが提示した事例すらある。これを「笑い話」で済ませることはできない。
例えるなら判断が「脳外科医竹田君」並になる、投薬治療で3か月で治る程度の病気を、病根から外科手術で切除しましょう、なんて提案になる。最新のAIなのに80年前みたいな医学知識と判断になってしまうのだ(胃潰瘍ってだけで胃袋は全摘、ついでに脾臓と盲腸もいらねーからとっとこ、みたいな手術が昭和の昔、本当にガイドライン治療だった、「K2」などで言及されている)
学習できるベースがどうしても偏る以上、情報の統合に限界がある、さらに間違いが間違いをよび、さらに変な間違いを起こしたりありえない架空のことをいったりする、これがハルシネーションというメビウスの輪である
Neuro-symbolic AIという次世代のさらに文脈も読み取れるアーキテクチャAIを研究しているが、全く実用化されていない、核融合や量子コンピューターみたいな雲をつかむ話なので、AIがこの問題を解決することは恐らく今後数百年はありえない、という結論が出ている。
元増田の記事で批判もあったが、恐らくAIで一番致命的な問題はこれ
基本的にAIは英語ソース、つまりリングワ・フランカで圧倒的にテキスト量の多い(約95％)英語、日本語含めそれ以外の全世界言語が5パーセントという偏った学習になっている
そのため、倫理・道徳・常識・規範などがすべて西洋基準になってしまう、という問題がある。(元増田はこれを「脱獄の基準の倫理は誰が決めるのか？」と根本的な問題に気が付いていて批判していたようだ)
ちなみに、バズってた例の記事に「AIに書かせたんだろ」という批判も大量にあるしよくみかけるが、この場合においてのみ言うなら、これは③の問題からまずありえないということがわかる、以下が根拠だ
元増田は「俺達の麻生とかいって秋葉原で踊ってた…」とか「レムちゃん、エミリアたん、ヘスティアちゃん、ウマ娘たん、刀剣乱舞くん、ライカン様…」といった批判を繰り返し書いていた
これに激怒できる人間は、2005～2010年にオタク界隈や秋葉原にすでにかかわっていて、実際に渦中にいたか同じ属性の人間でしか、罵倒されていると文脈的に理解できないのである。つまり、大量の英語文化圏情報を食ってるAIではなんでそれが罵声や侮蔑なのか理解できないので、書きようがない表現の数々、であるということである。
AIからすれば「ライカン様？ウマ娘？なんじゃそりゃ」なのである、もっと言えば、その直後にコンテクストとして「アホ、ボケ、弱者男性、豚丼、性器や自慰で虚しく…」といった言葉があるから、なんならAIはウマ娘やライカンをキャラクターでなく侮蔑単語として理解してしまう、これは実際、元増田の記事の一文をAIに食わせて質問したらガチでそうなるので、ぜひお手元で試してもらいたい。
「プログラマーのイメージを描いて」と依頼すると、男性の画像ばかりが出るされる
「看護師」→女性、「エンジニア」→男性という職業的性差が自動的に反映される
「アフリカの文化」→貧困・紛争・サバンナなど、植民地主義的視点が強く反映される(実際は南アなどはすげえ都会である)
これに前述のハルシネーション問題として現れれば、人間と同じような差別や偏見を「ガチの真実」として学習してしまう、人間の場合、8割くらいは本当はおかしいこととメタ批判が心理的にできるとされているが、AIにはその構造が根本的に存在しない。
元増田の記事のコメント欄やXなどで元増田のAI批判を批判しつつ、「金持ちの上級白人専用のハイエンドAIがあるに違いないんだ」といっている意見が少なくない数がある。
冷静に考えれば、そんなめんどうくせえもん誰が作るんだ、と普通に考えればわかるのだが、この③の問題、すなわち95％の学習データが英語ソースなので、結果的に西洋文明ベースの文化圏の人間向けにカスタマイズされているので、アジア圏やその他文化圏では利用に不利でそう感じてしまう素地ができている、という錯覚に由来している
例えば、パレスチナ問題などがそうだ、ガザ地区でほぼ国際条約や人道違反の残虐行為を国が行っているわけで、他文化圏や歴史的文脈から見ればどっちかって言えばパレスチナ人こそ被害者なのだが、イスラエルから見ればそれは正義であり正当な攻撃なわけで、後者の方がＡＩは正しいと判断した結論を下す様になる、といった問題である
あの記事の元増田は「テロ組織のヤバイマニュアルまで学習してpdfで元データを提示してきた」と言っていた。実際AIに調べさせて持ってこさせてみると、出所はアメリカの法務執行機関が研究用にネットで公開したものであった。
日本人や日本の警察の対応レベルで「ヤバイ」ものでも、海外の軍隊みたいな装備の警察で見れば大したことがないから、公開させてもいい＝倫理違反には当たらない、という文化規範の意識の違いを、あの元増田自身が証明してしまっている、あの記事は、ＡＩの治しようがない根本的な技術的欠陥をほとんど言及しているといっていい
元増田が口汚く罵っている内容の様に、「AIは0を1にできないから格差が広がるだけ」という根本的な哲学を投げつけている
それを受けて批判してる意見の中には「(自分が1を持ってる側と何故か根拠もなく信じ込んでて)100にできるから(なら)便利」とか「そのAI今から勉強したりしてる俺たちは先行者利益で強者になれる」と信じて疑わない意見が多かった
③問題の通り、そもそも非キリスト教圏かつ非英語圏の国家で生まれて育った民族、というだけで、我々は等しく「０」側の人間であり、結局競争になると勝てない、ということに全く気が付いていないのである。ここにAI信者の宿痾といえる病理がある
かつて日本人は黒船を見て5年そこらで蒸気機関を模倣した、火縄銃を一丁買えば10年でオスマン帝国の次に鉄砲を使うようになった、それは当時の日本人の基礎工学技術が導入可能なほど優れており、かつそれに対して現代では考えられないほぼバクチといっていい投資を行った結果であって、その結果を見て自分たちはAIを使いこなせて強くなれるなんていうのは、物凄い妄想である。つまり、AIは少なくとも「非英語圏」の人間にとっては、ブレイクスルーは絶対に起こりえない、ということである。
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）」といった、様々な「
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）」といった、様々な「
一度投稿したうえで別タブを開いてプログラム的(fetch)に送信してその別タブが閉じられる仕組み。
// ==UserScript==
// @name PGP未署名検出と別タブ自動編集
// @namespace http://tampermonkey.net/
// @version 1.0
// @description PGP署名がない投稿を自動編集ページへ誘導
// @match https://anond.hatelabo.jp/*
// @grant GM_setValue
// @grant GM_getValue
// @grant GM.openInTab
// ==/UserScript==
(function () {
'use strict';
const body = document.getElementById('entry-page');
if (!body) return;
const titleText = document.title;
if (!titleText.includes('dorawii')) return;
const pgpRegex = /BEGIN.*PGP(?: SIGNED MESSAGE| SIGNATURE)?/;
const preElements = document.querySelectorAll('div.body pre');
let hasPgpSignature = false;
for (const pre of preElements) {
if (pgpRegex.test(pre.textContent)) {
hasPgpSignature = true;
break;
}
}
if (hasPgpSignature) return;
const editLink = document.querySelector('a.edit');
const childTab = GM.openInTab(editLink.href, { active: false, insert: true, setParent: true });
})();
// ==UserScript==
// @name 編集ページ処理と自動送信・閉じ
// @namespace http://tampermonkey.net/
// @version 1.0
// @description 編集ページで署名処理と送信、タブ自動閉じ
// @match https://anond.hatelabo.jp/dorawii_31/edit?id=*
// @grant GM_getValue
// @grant GM_xmlhttpRequest
// @grant GM_setClipboard
// @grant GM_notification
// @connect localhost
// ==/UserScript==
(async function () {
'use strict';
const shouldRun = await GM_getValue('open-tab-for-edit', '0');
const textareaId = 'text-body';
const textarea = document.getElementById(textareaId);
if (!textarea) return;
const content = textarea.value;
const pgpSignatureRegex = /-----BEGIN PGP SIGNED MESSAGE-----[\s\S]+?-----BEGIN PGP SIGNATURE-----[\s\S]+?-----END PGP SIGNATURE-----/;
if (pgpSignatureRegex.test(content)) {
console.log('[PGPスクリプト] 署名が検出されたためそのまま送信します');
return;
}
const httpRequest = (url, data) => {
return new Promise((resolve, reject) => {
GM_xmlhttpRequest({
method: 'POST',
url: url,
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
data: `value=${encodeURIComponent(data)}`,
onload: function (response) {
resolve(response.responseText);
},
onerror: function (error) {
reject(error);
}
});
});
};
// textarea の値を取得
// 1. 現在のページのURLからURLオブジェクトを作成
const currentUrl = new URL(window.location.href);
// 2. ベースとなる部分 (例: "https://anond.hatelabo.jp") を取得
const origin = currentUrl.origin;
// 3. 'id' パラメータの値 (例: "20250610184705") を取得
const idValue = currentUrl.searchParams.get('id');
// 4. ベース部分とIDを結合して、目的のURL文字列を生成
// idValueが取得できた場合のみ実行する
let newUrl = null;
if (idValue) {
newUrl = `${origin}/${idValue}`;
}
// 5. 生成されたURLを変数に代入し、コンソールに出力して確認
console.log(newUrl);
const valueToSend = newUrl;
try {
const signatureText = await httpRequest('http://localhost:12345/run-batch', valueToSend);
console.log('バッチ応答:', signatureText);
if (!signatureText.includes('BEGIN PGP SIGNED MESSAGE')) {
alert('PGP署名がクリップボードに見つかりませんでした。');
return;
}
const newText = content.replace(/\s*$/, '') + '\n' + signatureText + '\n';
textarea.value = newText;
console.log('[PGPスクリプト] 署名を貼り付けました。送信を再開します。');
const form = document.forms.edit;
const newForm = form.cloneNode(true);
form.replaceWith(newForm);
newForm.addEventListener('submit', async (e) => {
e.preventDefault(); // HTML標準のsubmitをキャンセル
const bodyText = textarea?.value || '';
// reCAPTCHA トークンの取得
const recaptchaToken = await new Promise((resolve) => {
grecaptcha.enterprise.ready(() => {
grecaptcha.enterprise.execute('hoge', { action: 'EDIT' })
.then(resolve);
});
});
// POSTするデータの構築
const formData = new FormData(newForm);
formData.set('body', bodyText);
formData.set('recaptcha_token', recaptchaToken);
formData.set('edit', '1');
try {
const response = await fetch(newForm.action, {
method: 'POST',
body: formData,
credentials: 'same-origin'
});
if (response.ok) {
console.log('送信成功');
window.close();
} else {
console.error('送信失敗', response.status);
}
} catch (err) {
console.error('送信中にエラーが発生', err);
}
});
// プログラム的に送信トリガー
newForm.dispatchEvent(new Event('submit', { bubbles: true }));
} catch (e) {
console.error('バッチ呼び出し失敗:', e);
}
})();
const http = require('http'); const { exec } = require('child_process'); const querystring = require('querystring'); const server = http.createServer((req, res) => { if (req.method === 'GET' && req.url === '/ping') { res.writeHead(200); res.end('pong'); } else if (req.method === 'POST' && req.url === '/run-batch') { let body = ''; req.on('data', chunk => { body += chunk.toString(); }); req.on('end', () => { const parsed = querystring.parse(body); const value = parsed.value || 'default'; // 値を引数としてバッチに渡す exec(`C:\\Users\\hoge\\Desktop\\makesign.bat "${value}"`, { encoding: 'utf8' }, (err, stdout, stderr) => { if (err) { res.writeHead(500); res.end('Error executing batch: ' + stderr); } else { res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' }); res.end(stdout.trim()); } }); }); } else { res.writeHead(404); res.end('Not found'); } }); server.listen(12345, () => { console.log('Batch server running at http://localhost:12345/'); });
@echo off setlocal enabledelayedexpansion :: 署名するファイル名 set "infile=%~1" set outfile=%TEMP%\pgp_output.asc :: 以前の出力があれば削除 if exist "%outfile%" del "%outfile%" :signloop :: AutoHotkeyでパスフレーズ入力（gpgがパスワード要求するダイアログが出た場合に備える） start "" /b "C:\Users\hoge\Documents\AutoHotkey\autopass.ahk" :: PGPクリア署名を作成 echo %infile% | gpg --yes --clearsign --output "%outfile%" :: 署名が成功していればループを抜ける if exist "%outfile%" ( goto postprocess ) else ( timeout /t 1 > nul goto signloop ) :postprocess powershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body = Get-Content '%outfile%' -Raw; Write-Output ($header + \"`r`n\" + $body + $footer)" powershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body = Get-Content 'signed.asc' -Raw; Set-Clipboard -Value ($header + \"`r`n\" + $body + $footer)" endlocal exit /b
#Persistent #SingleInstance ignore SetTitleMatchMode, 2 WinWaitActive, pinentry SendInput password Sleep 100 SendInput {Enter} ExitApp
動けばいいという考えで作っているので余分なコードも含んでいるかもしれない。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250613185036 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEv1FQAKCRBwMdsubs4+ SHHkAQDUOLgBcdji2T6MJ7h/vlMdFfGlWAzNdXijjE1gIuEPywEAiMNMZqhrMmtl c7UqRuggNJ/UTa5xTIcKp622+7jJQQg= =Lgkl -----END PGP SIGNATURE-----
・エントリページでタイトルがdorawiiでpgp署名が無くeditボタンがあったら、現在のURLを保管してそれをクリック
・そのクリックによるURLへのアクセスにおいては別タブを開かせるようにするが、現在のタブは変えないようにする
・保管してあるURLをnode.jsサーバー経由でバッチファイルに渡して署名してクリップボードにコピー
・フォームへの貼り付けが終わったら送信ボタンをクリックし、レスポンスが正常に返ったと確認された段階(つまりページ表示の完了を待たない)で、別タブを自動終了
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250611115815 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEk0DAAKCRBwMdsubs4+ SMeUAP0Sbc2rovwbBLIW1EsKVCkZgaMMBQh7XNHretkmy/X+MgD/VZaho2zYzj5T BcoTBYw5DL/IbfBlrq8oRZoAJckc8wY= =U8nF -----END PGP SIGNATURE-----
https://xn--pckua2a7gp15o89zb.com/
| 技術 | 1月3日 | 5月29日 | 変化率 |
| Rails | 22,891 | 31,011 | 36%↑ |
| Node.js | 12,829 | 17,012 | 33%↑ |
| Django | 13,348 | 20,471 | 53%↑ |
| Flask | 1,589 | 1,827 | 15%↑ |
| FastAPI | 1,210 | 1,541 | 27%↑ |
| Laravel | 26,879 | 35,526 | 32%↑ |
| Next.js | 7,382 | 16,731 | 127%↑ |
| Spring | 16,380 | 22,490 | 37%↑ |
| React | 49,465 | 69,429 | 40%↑ |
| Vue | 34,322 | 49,795 | 45%↑ |
https://survey.stackoverflow.co/2024/technology
https://survey.stackoverflow.co/2020#technology
| - | 2020 | - | - | - | 2024 |
| JS | 67.7 | - | - | - | 62.3 |
| Python | 44.1 | - | - | - | 51 |
| TS | 25.4 | - | - | - | 38.5 |
| Java | 40.2 | - | - | - | 30.3 |
| C# | 31.4 | - | - | - | 27.1 |
| C++ | 23.9 | - | - | - | 23 |
| C言語 | 21.8 | - | - | - | 20.3 |
| PHP | 26.2 | - | - | - | 18.2 |
| Go | 8.8 | - | - | - | 13.5 |
| Rust | 5.1 | - | - | - | 12.6 |
| kotlin | 7.8 | - | - | - | 9.4 |
| Lua | - | - | - | - | 6.2 |
| Dart | 4.0 | - | - | - | 6 |
| Ruby | 7.1 | - | - | - | 5.2 |
| Swift | 5.9 | - | - | - | 4.7 |
| Scala | 3.6 | - | - | - | 2.6 |
※HTML/CSS,SQL,Bash/Shell,とかそういうのは省いた
順調に伸びるPython人気、そしてTypescriptの伸びがすごいな
Javaって永遠に人気なのかと思ってたけどじわじわと人気が落ちている
PHPも長期的にみると厳しそう。
GoとRustが着実に人気を獲得。
Luaが地味に人気出てる。
| - | 2020 | - | - | - | 2024 |
| PostgraSQL | 36.1 | - | - | - | 48.7 |
| MySQL | 55.6 | - | - | - | 40.3 |
| SQLite | 31.2 | - | - | - | 33.1 |
| SQLServer | 33.0 | - | - | - | 25.3 |
| MongoDB | 26.4 | - | - | - | 24.8 |
| Redis | 18.3 | - | - | - | 20 |
| MariaDB | 16.8 | - | - | - | 17.2 |
| Elasticsearch | 13.8 | - | - | - | 12.5 |
| Oracle | 16.5 | - | - | - | 10.1 |
MySQL+MariaDBではまだMySQL系が多いが・・・
| - | 2020 | - | - | - | 2024 |
| Node.js | 51.4 | - | - | - | 40.8 |
| React | 35.9 | - | - | - | 39.5 |
| jQuery | 43.3 | - | - | - | 21.4 |
| Next.js | - | - | - | - | 17.9 |
| Express | 21.2 | - | - | - | 17.8 |
| Angular | 25.1 | - | - | - | 17.1 |
| ASP.NET CORE | 19.1 | - | - | - | 16.9 |
| Vue.js | 17.3 | - | - | - | 15.4 |
| ASP.NET | 21.9 | - | - | - | 12.9 |
| Flask | 14.2 | - | - | - | 12.9 |
| Spring | 16.4 | - | - | - | 12.7 |
| Django | 14.2 | - | - | - | 12 |
| FastAPI | - | - | - | - | 9.9 |
| Laravel | 11.1 | - | - | - | 7.9 |
| Svelte | - | - | - | - | 6.5 |
| Rails | 7.0 | - | - | - | 4.7 |
※フロントとバックエンドがごちゃごちゃなのなんでだろう。Node.jsってフレームワークじゃないだろ・・・
Next.jsの勢いがすごい。やはりWEBはTSでNext.jsの時代なのか
Pythonの人気は盤石だけど、DjangoとかFlaskは人気が落ちてる。FastAPIに食われたか？
LaravelとRailsはこのまま消えていく予感
Speed, SEO, scalability, and developer productivity are more critical than ever. While React.js remains a powerhouse for building interactive user interfaces, many businesses and developers are now leaning toward Next.js for complete, production-ready solutions. So what exactly makes Next.js a more favorable choice over React.js in 2025? Let’s explore the reasons in detail.
🧱 React.js vs Next.js: Core Distinction
React.js is a JavaScript library focused solely on building UI components.
Next.js is a full-fledged framework built on top of React that includes everything you need for production — routing, SSR, SEO optimization, static site generation, and more.
In essence, React gives you the tools to build an interface, while Next.js gives you the structure to build, deploy, and scale a complete web application.
🚀 Key Advantages of Choosing Next.js in 2025
1. Built-in Server-Side Rendering (SSR)
2. Improved SEO Out of the Box
3. Hybrid Rendering Capabilities
5. Image & Font Optimization
This aligns perfectly with Google’s performance guidelines in 2025. React.js doesn’t offer this natively.
6. API Routes Without a Backend
7. Enhanced Developer Experience
Next.js has evolved into one of the most developer-friendly frameworks in 2025, backed by the Vercel ecosystem.In 2025, Next.js stands out as the smarter, faster, and more scalable solution for building modern websites and web applications. It inherits everything great about React — and adds structure, optimization, and production-readiness. If you’re planning to build a website that demands speed, SEO, and a seamless development process, Next.js is the clear choice.
For more details read this informative article: https://www.nimblechapps.com/blog/choosing-nextjs-over-reactjs-for-website-development