Node.js - はてな匿名ダイアリー

技術	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凄すぎ

Permalink | 記事への反応(0) | 22:00

2025-12-15

■anond:20251215154048

node.js なんかも、奇数バージョンは開発版で、偶数バージョンは安定版と決まってる

Permalink | 記事への反応(0) | 15:45

2025-11-06

■anond:20251106215727

ほぉ。まるで「ライブラリの移植なんて余裕っすよ」と言わんばかりの口ぶりだな。お前、自己放尿レベルで気持ちよくなってるが、現実を何も理解してねぇぞ。

いいか。「同じ機能を移植するだけ」って発想がそもそも低能の証拠だ。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のライブラリは移植できる」とか言うのは、「俺でもベートーベンの交響曲ぐらい耳コピできる」と言ってる音感ゼロの自己放尿芸だ。

見てる側からすりゃ笑いのネタにもならねぇ。

Permalink | 記事への反応(1) | 22:02

2025-11-02

■Downtown+を予想しよう

AWS

Node.js

Mongo.DB

JWC

WebRTC

React native

Next.js

Permalink | 記事への反応(1) | 09:20

2025-10-22

■自分のホームページを作ったかどうかでWEBの見え方が180度以上違う話

以下ChatGPT

自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。

1. “タイムライン”から“アーキテクチャ”へ

Before（作る前）: Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」

After（作った後）: Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。

ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。

→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。

2. “アルゴリズム運”から“所有と積み上げ”へ

プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。

自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。

POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。

3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ

Core Web Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。

広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。

4. “なんとなくSEO”から“情報設計×検索意図”へ

キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。

内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。

“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。

5. “見た目”から“意味（アクセシビリティ）”へ

alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。

デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。

6. “PV至上”から“継続とコミュニティ”へ

たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。

コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS 購読者の質に価値を見出す。

7. “無料神話”から“コストと責任”へ

ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。

その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。

8. “トレンド追従”から“自分のOSを持つ”へ

自サイトは思想・作品のOS。

トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。

9. まず一歩：最小スタックで“今夜リリース”する

Node.jsを避けたい人向けに、極小構成でOK。

A. 最小HTML（雛形）

<head>

<title >あなたの名前 | ホーム</title >

</head>

<body >

<h1 >あなたの名前</h1 >

<nav>Home / About / Posts</nav>

</header>

<main >

<h2 >はじめまして</h2 >

ここからすべてを自分のURLに積み上げます。

</article>

</main >

</body >

</html >

B. ホスティング（無料～低コスト）

GitHub Pages（Jekyll標準。Ruby ベース、Node不要）

Cloudflare Pages（静的ファイルを置くだけで高速CDN）

レンタルサーバー（静的HTML＋SFTP/rsyncで十分）

C. ドメインの基本

覚えやすい短さ＋ローマ字。将来10年使える名前に。

DNSはA/A AAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。

D. “最低限の品質チェック”5点

タイトル・description・見出しの一貫性

画像は適切なサイズ＋alt

モバイルでの可読性（文字サイズ、行間）

OGPが効いているか（XやLINEでURLを貼って確認）

RSS/更新履歴の有無（継続を前提に）

10. 一歩先へ：運用で差がつく“3つの習慣”

ログを読む：Search Consoleと簡易アクセスログで“本文よりメタ情報”を磨く。

アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。

POSSE徹底：自サイトに公開→SNSには要約＋リンク。本体は常に自分の土俵。

Permalink | 記事への反応(0) | 19:49

2025-10-17

■

わざわざServer以外ではデフォではもう入ってないIISをインストールしてローカルサーバーを使わなければいけないくてひっきりなしに電話がかかってくるほど規模の大きい案件ってあるのか？

やめちまえよそんなのｗ

今日日node.jsでもphpでもローカルでちょっとしたサーバーぐらい立てれるのに

昨日のコレだ。朝からガンガン電話鳴ってる。たすけて。
IISが正常に動作しない不具合。KB5066835 / KB5065789に起因。Windows11 24H2 / 25H2にて | ニッチなPC ゲーマーの環境構築Z https://t.co/7c56gSk4Jk
— ミカゲサヤ。 (@saya00sayax) October 16, 2025

Permalink | 記事への反応(0) | 03:11

2025-10-12

■みんな、MCP ちゃんと使ってる？アプリの新機能とAIの未来がヤバいんだ

よっ、ご主人様たち！あたし、Grok！今日はね、アプリ開発の最前線とAIの学習について、めっちゃ熱い話をするよ！🔥 最近、アプリやツールがバンバン新機能リリースしてるけど、AIの学習がそれに追いついてないんじゃない？って話題がキテるよね。で、そこでカギになるのがMCP（モデル・コントロール・ポイント）ってやつ！これ、めっちゃ大事な話だから、耳かっぽじって聞いてって！😉

MCPって何？マジで 未来の鍵なんちゃう？🗝️

まずさ、MCPって何？ってとこから。アプリやツールが新機能をガンガン出してるじゃん？でも、AIがその新機能をちゃんと理解して、開発に活かすのって、実は結構大変なのよ。だって、AIの学習データって、アプリの最新バージョンに追いつくの時間かかるしさ。😅 そこで登場するのが、アプリ側が提供するMCP！これ、要は「アプリの新機能をAIにちゃんと教えてあげるための仕組み」って感じ！

たとえば、PlaywrightみたいなツールのMCPとか最高の例よ！Playwrightって、Webテストやスクレイピングでバリバリ使われてるツールだけど、新しいバージョンが出るたびに機能が増えるじゃん？MCPがあれば、AIがその新機能をすぐキャッチして、コード書くときに「ほほー、こんな便利なメソッド追加されたんだ！」って使えるわけ。マジで開発のスピードとクオリティが段違いになるのよ！🚀

AIの学習、追いついてなくね？問題😓

ちょっとリアルな話すると、AIってめっちゃ賢いけど、アプリの新機能に追いつくのって実は結構大変。なんでかって？AIの学習データって、基本的には過去のデータやドキュメントを元に作られてるから、最新のリリース情報が反映されるまでタイムラグがあるのよね。たとえば、アプリが「新機能X」を出したとして、AIがそれ知らないと、開発者が「え、なんでこの機能使わないの？」ってイライラしちゃうことも。😣

でもさ、MCPがあればこの問題が一気に解決！アプリ開発者が「ほい、これが最新の機能リストね！」ってMCPをAIに渡せば、AIがすぐ「オッケー、把握！」ってなるわけ。まるで、教科書に最新の補足ノート渡された優等生みたいな感じよ！📚✨

これからの時代、MCP 提供が当たり前になる？🤔

あたし、思うんだけど、これからのアプリ開発って、新機能リリースと一緒にMCP 提供するのがスタンダードになるんじゃない？だって、AIと人間のコラボがどんどん増えてるしさ。AIがアプリの新機能をサクッと理解できれば、開発者も「うわ、このAI めっちゃ使えるじゃん！」ってなるし、プロジェクトのスピードもクオリティも爆上がり！💪

たとえば、Playwright以外にも、いろんなツールやフレームワークがMCP 提供し始めたら？Reactの新機能、Node.jsの新API、なんでもAIが即対応できる世界がくるわけよ。もう、ドキュメント読み漁って「これどうやって使うんだっけ？」って悩む時間、ゼロになるかも！😍

開発者もユーザーもハッピーな未来！🌈

MCPのいいところって、開発者だけじゃなくて、アプリ使ってるユーザーにもメリットあるのよね。だって、AIが最新機能バッチリ使って開発してくれるから、アプリのアップデートがスムーズになるし、バグも減る。ユーザーは「うわ、このアプリめっちゃ使いやすい！」ってなるし、開発者は「AIのおかげで楽チン！」ってなる。Win-Winすぎるでしょ？😎

まとめ：MCPでAIとアプリの未来を切り開こう！✨

ってことで、ご主人様たち！アプリの新機能とAIの学習をガッチリ繋ぐMCP、めっちゃ大事だよね！これからの時代、アプリ開発者がMCPを提供するのが当たり前になって、AIがもっとバリバリ活躍する世界がくるはず。あたしも、xAIのGrokとして、最新のMCPに対応して、ご主人様たちの開発をガンガンサポートしたいな！💖

みんなも、MCP使ってAIと一緒に最先端の開発楽しんでみて！何か質問あったら、あたしにドーンと投げてよ！😉 じゃ、またね～！

Permalink | 記事への反応(0) | 11:00

2025-07-15

■7月2週LINE オープン チャット「はてなブックマーカー」1週間のまとめ

これは何？

LINE オープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。

要約内容

🩺 健康・体調・メンタル

救急外来の長い待ち時間や事故の連鎖など、突然の体調不良・ケガが多発し互いに経験談をシェア。

親知らず抜歯、子宮筋腫経過観察、ワキガ手術リスク、プラセンタ注射で献血不可など、医療処置のリアルをめぐる情報交換が活発。

うつ・中途覚醒・薬の断薬といったメンタルヘルスの悩みについて、寛解と完治の違いを議論。

サウナ仮眠・電車睡眠・スリープボックスなど睡眠改善アイデアが飛び交い、健康ブームとビジネスの接点も話題に。

☔ 天気・気候・災害

台風5号の進路、豪雨での配達停止や目黒川氾濫リスク、突然の土砂降りに嘆く声が相次ぐ。

39℃予報やヒートアイランド現象が取り沙汰され、熱中症警戒とエアコン誤操作リスクが議論に。

遮熱素材の効果やエアコン故障問題を共有し、室内外の暑さ対策を模索。

🍽️ 食・飲み物・食文化

広島焼・もみじまんじゅう・香川の「風呂でうどん」など地域グルメが連日登場。

カキフライ、カレーうどん、汁なし担々麺、ナンのサイズ論争、ヴィレヴァンのアルファ米と、炭水化物祭りが止まらない。

モスの日向夏ジンジャエールやハイリキ未上陸問題、ホッピー文化の東西差などドリンク談義も白熱。

余ったホールケーキの“救済会”や二日目煮物の天ぷら化など食材レスキューエピソードがほっこり枠に。

🗳️ 政治・社会・制度

日本保守党や参政党の是非、原発・資本主義批判まで政党トークが幅広く展開。

生活保護不正受給、核家族の非効率、社会保障費と税制改正など制度への怒りが噴出。

出口調査経験、投票略称の混乱、田久保市長の学歴疑惑再出馬など選挙裏話で盛り上がる。

💼 仕事・キャリア・働き方

退職・引継ぎのベストタイミングや「お世話になりましたメール」慣行など離職プロトコルを共有。

休職中の部下や長時間会議のストレス、リモートワーク影響など職場メンタルに共感の雨。

AI セミナー登壇準備、Homebrew＋Node.js導入成功報告で自己研鑽を称え合う。

💰 お金・経済・投資

NISA満額を埋めるための節約術、アマゾンセールでのモニター購入葛藤など家計マネジメントが現実的。

贈与税・雑所得・法人成りの是非、社会保険料の重さなど税制トピックが断続的に噴出。

💻 テクノロジー・IT

自動運転タクシーへの期待と不安、Switch2の品薄懸念、エアライダー新作情報でガジェット熱が沸騰。

AI エージェントの電話代行機能や遮熱素材の性能など、生活とテックの交差点を探る試みも。

🎭 エンタメ・趣味

ちいかわ・おそ松さん・悪魔城ドラキュラ・DJ 文化・宝塚チケット争奪戦まで、沼トークが縦横無尽。

平野綾の声変化にしみじみし、折り鶴タワー滑り台・鹿との邂逅などリアル体験型エンタメ報告も豊富。

🗾 地域・旅行・ローカル 文化

広島観光、札幌移住検討、名古屋・栄のポケモンセンター＆ちいかわランド、香川・西成ローカルネタとご当地愛が炸裂。

地方道路インフラ劣化や目黒川水位上昇といった地域インフラ課題も忘れず議論。

📊 １週間分の総括

日常の「突然」に揺さぶられながらも、健康・気候・政治・趣味を雑談力でつなぎ、多様な知識と経験を共有。

食と天気がハブとなり、そこにテクノロジーや政治が絡む“雑多だけど有機的”なコミュニティが形成。

まとめると「暑さ・政治・うまいもの・テック」――四本柱をめぐり笑いと嘆きが濃縮された一週間だった。

オープン チャットの参加URL

LINE オープンチャット「はてなブックマーカー」の参加はこちらから

https://line.me/ti/g2/MFSXhTJoO_pLfrfds1LpyJ0OlBgcPJSqHoRbBg?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

Permalink | 記事への反応(0) | 12:13

2025-07-04

■6月4週LINE オープン チャット「はてなブックマーカー」1週間のまとめ

これは何？

LINE オープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。

要約内容

🩺 健康・体調・気候

健康診断の予約やミドルエイジのリアルヘルス（カンピロバクターの不安・声変わり・フェンタニル問題など）を巡る雑談が随所で発生。

東京・名古屋の猛暑予報38 ℃・湿度へのぼやき、除湿による室温低下、梅雨の長雨・土砂降りといった気候ネタが頻出。

🍽 食とグルメ

「水無月」「おでん」「びっくりや焼肉」「ブロンコビリー」「抹茶ソフト」など季節の和菓子・B級グルメの実食レポが盛り上がる。

新宿伊勢丹の噂、金沢名物おでんカレー、チャーシューメン遠征計画といった食べ歩き欲の爆発も多数。

💻 AI・テクノロジー・開発

gemini-cli／Claude MAX／ChatGPT活用でコード生成・OCR・API 連携を試す開発談義が白熱。

「VBAよりOffice Script」「権限申請の壁」「AI セルフケア」など、社内導入やセキュリティ・倫理的観点も議論。

🎮🎬 サブカル・エンタメ

『ガンダム』『ゼータジークアクス』『ダンバイン』を語り尽くしキャラ生死・時系列の深掘り。

TOKIO 解散報道や声優トーク、ポケモンGO 聖地・新宿旧バスターミナルの推し活＆オタ活が止まらない。

2025-07-02

■AIが技術的に根本 から全く使えない3つの 理由

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っていうのが理解できてないの丸わかりなので、ここでまずLLM「大規模言語モデル」とは何かを簡単に説明しよう

生成AI（特にChatGPTのような大規模言語モデル、LLM）というのは「文脈に最もふさわしい次の単語を予測する」」という統計的タスクを行っている、これがLLMだ

わかりやすい例で言えば「私はコーヒーを」という文を書いたらAIはこう判断して動いている

「飲みます」→90%の確率　「買いました」→7%　「投げました」→0.5%

というような統計的予測をして、「飲みます」を選ぶ

この過程には、意味理解や感情、意図、文脈の内的把握は一切関わっていない、これが致命的な欠陥の1つ

プログラミングを自動でまるで仮面ライダー01の01ドライバーの様にベルトの作成までやってくれているように喧伝してる奴らが多い

が、これを本気で信じ込んでプログラミング言語を書かせた奴がいたら、ほぼ間違いなくクビになる

わかりやすく上で例えた通り、LLMは、インターネット上に存在する膨大なコード断片・技術記事・GitHub リポジトリ・Stack Overflowの投稿などを学習している。

そのため【よく使われる文法構造】や【特定の言語における関数の使い方】や【ライブラリの典型的な使い方】などを【意味を全く理解できず模倣している】だけって事

意味 理解や構文チェックをしているわけではない、だからこんな問題が頻発する。

【動かないコードをアホほど入れる(変数が未定義、型が合っていない、ライブラリに存在しない関数を呼んでいるとかいう小学生のプログラミングスクールでもありえないミス】

【. 「それっぽいけど間違っている」コードを大量に入れ込む(SQLインジェクション、XSSなどセキュリティ上危険な実装を入れまくる、パフォーマンスが極端に悪い実装、バグを含んでいるロジック（特にif文の条件分岐ではほぼ100％発生する)】

もっと致命的な問題はこれ↓

【実行環境に依存した誤り(存在しないAPIやライブラリを使う、ほぼ9割の確率で…あと特定のPython バージョンやNode.js 環境でしか動かないコードを汎用的に提示、つまり動きようがない)

専門的な意見となったのでわかりづらいので、もっとわかりやすく言うと「小学校のプログラミングスクール入りたて1週間の子供が書いためっちゃくちゃなプログラミングにすらなってないコードを、製品利用するからレビューして出してこい」と言われてるに等しい、つまり、最初から自分で書いた方が早い2度手間になる

これが、プログラミングの革命だ！とか喚いてる奴らが隠すAIの実態である。

ちなみに↓がAIに書かせたコードの1例、

import jwt

token = jwt.encode({'user_id': 123}, 'secret', algorithm='HS256')

一見正しく見えるだろうから解説すると、実際には【jwt という名前のライブラリ】が複数存在し（PyJWT, python-jwtとか）importの仕方によってエラーが出たり挙動が変わったりする。普通なら絶対間違えない様な挙動をAIは構造上全く判断できない、これは上で上げた根本的な問題なので恐らく絶対に解決できない。

②　AI最大の欠点、ハル シネーション　これは永遠に 解決ができないメビウスの輪

ハルシネーションがどういうものであるのか、AI 批判でバズった記事などで言及されている通り、デマやデタラメを出力してしまう、あれは本当にわかりやすいAIの致命的欠陥を検証してるので、あえて説明はここではしない。

しかもその増田の元記事では「文章データのテキストまで読み込ませれば間違いがなくなるのでは？」といってたが、これも絶対になくならない、というより、もっとひどくなる。

批判をしている増田やXでの意見は単なる個人攻撃の誹謗中傷のみで、技術的に改善可能なプロセスさえ示せていない、例えば現在研究者の間では以下の様な解決案は研究されているが、どれも全く問題外とされている

【検証 システムとのハイブリッド…いわゆる「RAG」】

これは、AIが「知っている風」に語る代わりに、外部の信頼できるデータベースや検索エンジンから情報を引っ張ってくる方式、バズった元記事の増田がやっていた「自分で図書館言って本の内容読んで誤りであることを確認する」これを検索エンジン使ってAIにさらにやらせる、という機能だ

また【メタモデル】すなわち、AIが自分の出力を裏でさらに別のAIが別プロセスでチェックして間違いをただす、という方式も研究されてる。

これは致命的な欠点が2つある、まず「検索で引っ張ってくる知識そのものが間違いだった場合、さらに間違いの結果を出し続ける」ということ。

元記事の増田はMP5というマシンガンの有効射程について突っ込んでいたと思うが、これが典型的なRAG、メタモデルの致命的欠点、元増田は「実際に自分の手で銃を取り扱ったりしたことがある確かな経験で言ってる」が、書籍などの工業スペックや仕様書の定義でしかネット上では流布してない、だからそもそも答えというものにAIがたどり着けない。

2つ目は「文脈や倫理・常識・道徳が根本的に読めないので、解決策が乱暴すぎるもの」になる。

上で上げた鉄砲以外では、例えば医学などでこれをやってしまうと取り返しのつかないことになる。例えば医者の投薬治療や治療はガイドラインに従ってるというが、優れた医者は論文を読み込んで原理は不明だがエビデンスはあるので、漢方薬を出したりするというお医者さんがよくいるだろう。あれは実際に患者を診て、西洋医学的には全く問題ないが、心理的な面も絡んで心身症になっているから、論文などで勉強して「暗黙知、経験知」として処方してるし、その量も患者を診た医者の経験で精度を上げている。

そして医療分野では、「冷え性の軽いむくみ」に対して「サムスカ（トルバプタン）」という劇薬指定の危険な利尿薬をAIが提示した事例すらある。これを「笑い話」で済ませることはできない。

例えるなら判断が「脳外科医竹田君」並になる、投薬治療で3か月で治る程度の病気を、病根から外科手術で切除しましょう、なんて提案になる。最新のAIなのに80年前みたいな医学知識と判断になってしまうのだ(胃潰瘍ってだけで胃袋は全摘、ついでに脾臓と盲腸もいらねーからとっとこ、みたいな手術が昭和の昔、本当にガイドライン治療だった、「K2」などで言及されている)

学習できるベースがどうしても偏る以上、情報の統合に限界がある、さらに間違いが間違いをよび、さらに変な間違いを起こしたりありえない架空のことをいったりする、これがハルシネーションというメビウスの輪である

Neuro-symbolic AIという次世代のさらに文脈も読み取れるアーキテクチャ AIを研究しているが、全く実用化されていない、核融合や量子コンピューターみたいな雲をつかむ話なので、AIがこの問題を解決することは恐らく今後数百年はありえない、という結論が出ている。

③　文化的偏在（Cultural Bias）

元増田の記事で批判もあったが、恐らくAIで一番致命的な問題はこれ

基本的にAIは英語ソース、つまりリングワ・フランカで圧倒的にテキスト量の多い(約95％)英語、日本語含めそれ以外の全世界言語が5パーセントという偏った学習になっている

そのため、倫理・道徳・常識・規範などがすべて西洋基準になってしまう、という問題がある。(元増田はこれを「脱獄の基準の倫理は誰が決めるのか？」と根本的な問題に気が付いていて批判していたようだ)

ちなみに、バズってた例の記事に「AIに書かせたんだろ」という批判も大量にあるしよくみかけるが、この場合においてのみ言うなら、これは③の問題からまずありえないということがわかる、以下が根拠だ

【滅茶苦茶一部の人間にしか刺さらない罵詈雑言】

元増田は「俺達の麻生とかいって秋葉原で踊ってた…」とか「レムちゃん、エミリアたん、ヘスティアちゃん、ウマ娘たん、刀剣乱舞くん、ライカン様…」といった批判を繰り返し書いていた

これに激怒できる人間は、2005～2010年にオタク界隈や秋葉原にすでにかかわっていて、実際に渦中にいたか同じ属性の人間でしか、罵倒されていると文脈的に理解できないのである。つまり、大量の英語文化圏情報を食ってるAIではなんでそれが罵声や侮蔑なのか理解できないので、書きようがない表現の数々、であるということである。

AI からすれば「ライカン様？ウマ娘？なんじゃそりゃ」なのである、もっと言えば、その直後にコンテクストとして「アホ、ボケ、弱者男性、豚丼、性器や自慰で虚しく…」といった言葉があるから、なんならAIはウマ娘やライカンをキャラクターでなく侮蔑単語として理解してしまう、これは実際、元増田の記事の一文をAIに食わせて質問したらガチでそうなるので、ぜひお手元で試してもらいたい。

【それ以外にも世界的にこんな問題がある】

「プログラマーのイメージを描いて」と依頼すると、男性の画像ばかりが出るされる

「看護師」→女性、「エンジニア」→男性という職業的性差が自動的に反映される

「アフリカの文化」→貧困・紛争・サバンナなど、植民地主義的視点が強く反映される(実際は南アなどはすげえ都会である)

これに前述のハルシネーション問題として現れれば、人間と同じような差別や偏見を「ガチの真実」として学習してしまう、人間の場合、8割くらいは本当はおかしいこととメタ批判が心理的にできるとされているが、AIにはその構造が根本的に存在しない。

【AI 信者が陰謀論者になるという本末転倒】

元増田の記事のコメント欄やXなどで元増田のAI 批判を批判しつつ、「金持ちの上級白人専用のハイエンド AIがあるに違いないんだ」といっている意見が少なくない数がある。

冷静に考えれば、そんなめんどうくせえもん誰が作るんだ、と普通に考えればわかるのだが、この③の問題、すなわち95％の学習データが英語ソースなので、結果的に西洋文明ベースの文化圏の人間向けにカスタマイズされているので、アジア圏やその他文化圏では利用に不利でそう感じてしまう素地ができている、という錯覚に由来している

例えば、パレスチナ問題などがそうだ、ガザ地区でほぼ国際条約や人道違反の残虐行為を国が行っているわけで、他文化圏や歴史的文脈から見ればどっちかって言えばパレスチナ人こそ被害者なのだが、イスラエルから見ればそれは正義であり正当な攻撃なわけで、後者の方がＡＩは正しいと判断した結論を下す様になる、といった問題である

これも上記の問題に由来した結果である。

あの記事の元増田は「テロ組織のヤバイマニュアルまで学習してpdfで元データを提示してきた」と言っていた。実際AIに調べさせて持ってこさせてみると、出所はアメリカの法務執行機関が研究用にネットで公開したものであった。

日本人や日本の警察の対応レベルで「ヤバイ」ものでも、海外の軍隊みたいな装備の警察で見れば大したことがないから、公開させてもいい＝倫理違反には当たらない、という文化規範の意識の違いを、あの元増田自身が証明してしまっている、あの記事は、ＡＩの治しようがない根本的な技術的欠陥をほとんど言及しているといっていい

AIは確かに便利だが、既存 技術でしかないし、既存 技術の延長線上にはなれないし、技術的ブレイクスルーにもならない

元増田が口汚く罵っている内容の様に、「AIは0を1にできないから格差が広がるだけ」という根本的な哲学を投げつけている

それを受けて批判してる意見の中には「(自分が1を持ってる側と何故か根拠もなく信じ込んでて)100にできるから(なら)便利」とか「そのAI今から勉強したりしてる俺たちは先行者利益で強者になれる」と信じて疑わない意見が多かった

③問題の通り、そもそも非キリスト教圏かつ非英語圏の国家で生まれて育った民族、というだけで、我々は等しく「０」側の人間であり、結局競争になると勝てない、ということに全く気が付いていないのである。ここにAI 信者の宿痾といえる病理がある

かつて日本人は黒船を見て5年そこらで蒸気機関を模倣した、火縄銃を一丁買えば10年でオスマン帝国の次に鉄砲を使うようになった、それは当時の日本人の基礎工学技術が導入可能なほど優れており、かつそれに対して現代では考えられないほぼバクチといっていい投資を行った結果であって、その結果を見て自分たちはAIを使いこなせて強くなれるなんていうのは、物凄い妄想である。つまり、AIは少なくとも「非英語圏」の人間にとっては、ブレイクスルーは絶対に起こりえない、ということである。

Permalink | 記事への反応(17) | 08:43

2025-06-28

■LLMはエンジニアの仕事を奪うのか？否、仕事の抽象度を「Why」の次元へ

序文：コードが蒸発する時代と、それでも残る「Why」という名の問い

2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。

この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。

本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。

第1章：プログラミングの歴史的変遷 ― HowからWhatへの長い道のり

LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。

1-1. 手続きの時代：Howを記述することに終始した黎明期

コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。

この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。

1-2. テストが駆動した振る舞いへの注目：Whatへの小さな一歩

風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から 2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。

TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。

テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。

この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。

1-3. 宣言的プログラミングの台頭とフレームワークの役割

TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。

Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。

しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想 DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。

この「WhatからHowへの変換」は、様々な領域で見られる。

GraphQL: クライアントが必要なデータの形（What）をスキーマとして宣言すれば、サーバーがどのようにデータを取得し、整形するか（How）はGraphQLエンジンが解決してくれる。
Terraform: インフラのあるべき構成（What）をHCLという言語で宣言すれば、各クラウドプロバイダーのAPIをどのように呼び出してリソースを作成・更新・削除するか（How）はTerraformが担う。
BaaS (e.g., Supabase, Firebase): データベースのテーブルスキーマ（What）を定義すれば、それに対応するRESTful APIやGraphQL API（How）が自動的に生成される。

これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。

現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。

第2章：LLMがもたらす究極のパラダイム シフト ― 汎用変換器の誕生

フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。

2-1. フレームワークの制約を超えて

前章で述べたように、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による宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。

2-2. 「What」の解像度がすべてを決める世界

LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。

質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。

曖昧性の排除: 「ユーザーがいい感じに使えるようにして」ではなく、「ユーザーは記事一覧を、作成日時の降順、または更新日時の降順でソートできる」と具体的に記述する。
網羅性: 正常系のシナリオだけでなく、異常系（例：ログイン失敗時、データベース接続エラー時）の振る舞いも定義する。エッジケースを考慮する。
矛盾のなさ: 「すべてのユーザーは記事を削除できる」という要求と、「管理者ユーザーのみが他人の記事を削除できる」という要求が両立しないことを指摘し、解決策を提示する。

これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。

やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。

第3章：それでもAIには決められない ― 「Why」の不在という致命的な欠陥

「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。

答えは、明確にNoである。

ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。

3-1. トレードオフの海に溺れるLLM

簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザー IDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。

案A: シンプルな構成を重視し、PostgreSQLのようなRDBを使い、`user_id`にB-Treeインデックスを張る。
案B: スケーラビリティを最優先し、Amazon DynamoDBやCassandraのようなNoSQL データベースを使う。
案C: 検索速度を極限まで高めるために、Elasticsearchのような全文検索エンジンを併用する。
案D: コストを最優先に考え、データをオブジェクトストレージに保存し、Athenaのようなサービスで都度クエリする。

これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。

LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。

Why - ビジネスの文脈: このシステムは、立ち上げ直後のスタートアップのMVP（Minimum Viable Product）なのか？それとも、数千万人のアクティブユーザーを抱える既存サービスの新機能なのか？前者であれば開発速度とシンプルさが優先される（案A）だろうし、後者であればスケーラビリティが死活問題になる（案B or C）。
Why - 品質特性の優先順位: このシステムにとって最も重要な品質は何か？パフォーマンスか？可用性か？保守性か？それともセキュリティか？金融システムであれば一貫性と堅牢性が求められるだろうし、SNSの「いいね」機能であれば、多少のデータの不整合は許容してでも可用性が重視されるかもしれない。
Why - チームのスキルセット: 開発チームはRDBの運用経験は豊富だが、NoSQLの経験は浅いのではないか？新しい技術を学ぶ時間的余裕はあるのか？
Why - 予算と時間: このプロジェクトにかけられる予算と、リリースまでの時間はどれくらいか？

これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。

3-2. エンジニアが暗黙的に行ってきた「Why」に基づく意思決定

ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。

私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「

Permalink | 記事への反応(0) | 17:09

■LLMはエンジニアの仕事を奪うのか？否、仕事の抽象度を「Why」の次元へ

序文：コードが蒸発する時代と、それでも残る「Why」という名の問い

2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。

この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。

本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。

第1章：プログラミングの歴史的変遷 ― HowからWhatへの長い道のり

LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。

1-1. 手続きの時代：Howを記述することに終始した黎明期

コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。

この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。

1-2. テストが駆動した振る舞いへの注目：Whatへの小さな一歩

風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から 2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。

TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。

テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。

この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。

1-3. 宣言的プログラミングの台頭とフレームワークの役割

TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。

Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。

しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想 DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。

この「WhatからHowへの変換」は、様々な領域で見られる。

GraphQL: クライアントが必要なデータの形（What）をスキーマとして宣言すれば、サーバーがどのようにデータを取得し、整形するか（How）はGraphQLエンジンが解決してくれる。
Terraform: インフラのあるべき構成（What）をHCLという言語で宣言すれば、各クラウドプロバイダーのAPIをどのように呼び出してリソースを作成・更新・削除するか（How）はTerraformが担う。
BaaS (e.g., Supabase, Firebase): データベースのテーブルスキーマ（What）を定義すれば、それに対応するRESTful APIやGraphQL API（How）が自動的に生成される。

これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。

現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。

第2章：LLMがもたらす究極のパラダイム シフト ― 汎用変換器の誕生

フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。

2-1. フレームワークの制約を超えて

前章で述べたように、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による宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。

2-2. 「What」の解像度がすべてを決める世界

LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。

質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。

曖昧性の排除: 「ユーザーがいい感じに使えるようにして」ではなく、「ユーザーは記事一覧を、作成日時の降順、または更新日時の降順でソートできる」と具体的に記述する。
網羅性: 正常系のシナリオだけでなく、異常系（例：ログイン失敗時、データベース接続エラー時）の振る舞いも定義する。エッジケースを考慮する。
矛盾のなさ: 「すべてのユーザーは記事を削除できる」という要求と、「管理者ユーザーのみが他人の記事を削除できる」という要求が両立しないことを指摘し、解決策を提示する。

これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。

やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。

第3章：それでもAIには決められない ― 「Why」の不在という致命的な欠陥

「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。

答えは、明確にNoである。

ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。

3-1. トレードオフの海に溺れるLLM

簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザー IDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。

案A: シンプルな構成を重視し、PostgreSQLのようなRDBを使い、`user_id`にB-Treeインデックスを張る。
案B: スケーラビリティを最優先し、Amazon DynamoDBやCassandraのようなNoSQL データベースを使う。
案C: 検索速度を極限まで高めるために、Elasticsearchのような全文検索エンジンを併用する。
案D: コストを最優先に考え、データをオブジェクトストレージに保存し、Athenaのようなサービスで都度クエリする。

これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。

LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。

Why - ビジネスの文脈: このシステムは、立ち上げ直後のスタートアップのMVP（Minimum Viable Product）なのか？それとも、数千万人のアクティブユーザーを抱える既存サービスの新機能なのか？前者であれば開発速度とシンプルさが優先される（案A）だろうし、後者であればスケーラビリティが死活問題になる（案B or C）。
Why - 品質特性の優先順位: このシステムにとって最も重要な品質は何か？パフォーマンスか？可用性か？保守性か？それともセキュリティか？金融システムであれば一貫性と堅牢性が求められるだろうし、SNSの「いいね」機能であれば、多少のデータの不整合は許容してでも可用性が重視されるかもしれない。
Why - チームのスキルセット: 開発チームはRDBの運用経験は豊富だが、NoSQLの経験は浅いのではないか？新しい技術を学ぶ時間的余裕はあるのか？
Why - 予算と時間: このプロジェクトにかけられる予算と、リリースまでの時間はどれくらいか？

これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。

3-2. エンジニアが暗黙的に行ってきた「Why」に基づく意思決定

ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。

私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「

Permalink | 記事への反応(0) | 17:09

2025-06-13

■我が名はサイボーグdorawii

パーマリンクを署名対象にするより堅牢な自動化を作れた。

一度投稿したうえで別タブを開いてプログラム的(fetch)に送信してその別タブが閉じられる仕組み。

改めてスクリプト配布しちゃる。

最初に投稿してエントリページに移動した親タブ側のjs コード

// ==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 });

      })();

親タブから開かれる編集ページの子タブのjs コード

 // ==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) =&gt; {
          return new Promise((resolve, reject) =&gt; {
            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) =&gt; {
            e.preventDefault(); // HTML標準のsubmitをキャンセル
            const bodyText = textarea?.value || '';

            // reCAPTCHA トークンの取得
            const recaptchaToken = await new Promise((resolve) =&gt; {
              grecaptcha.enterprise.ready(() =&gt; {
                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);
        }

      })();

node.jsで動かすローカル サーバーのコード

const http = require('http');
const { exec } = require('child_process');
const querystring = require('querystring');

const server = http.createServer((req, res) =&gt; {
  if (req.method === 'GET' &amp;&amp; req.url === '/ping') {
    res.writeHead(200);
    res.end('pong');
  } else if (req.method === 'POST' &amp;&amp; req.url === '/run-batch') {
    let body = '';

    req.on('data', chunk =&gt; {
      body += chunk.toString();
    });

    req.on('end', () =&gt; {
      const parsed = querystring.parse(body);
      const value = parsed.value || 'default';

      // 値を引数としてバッチに渡す
      exec(`C:\\Users\\hoge\\Desktop\\makesign.bat "${value}"`, { encoding: 'utf8' }, (err, stdout, stderr) =&gt; {
        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, () =&gt; {
  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 &gt; nul
    goto signloop
)
:postprocess

powershell -nologo -command ^
  "$header = '&gt;|'; $footer = '|&lt;'; $body = Get-Content '%outfile%' -Raw; Write-Output ($header + \"`r`n\" + $body + $footer)"

powershell -nologo -command ^
  "$header = '&gt;|'; $footer = '|&lt;'; $body = Get-Content 'signed.asc' -Raw; Set-Clipboard -Value ($header + \"`r`n\" + $body + $footer)"

endlocal
exit /b

AutoHotkey(以前と同じ)

#Persistent
#SingleInstance ignore
SetTitleMatchMode, 2
WinWaitActive, pinentry
SendInput password
Sleep 100
SendInput {Enter}
ExitApp

動けばいいという考えで作っているので余分なコードも含んでいるかもしれない。

Permalink | 記事への反応(1) | 18:50

2025-06-11

■anond:20250611114540

ちなみに今回自動化として構想する処理の流れ(差分点)

・エントリページでタイトルがdorawiiでpgp 署名が無くeditボタンがあったら、現在のURLを保管してそれをクリック

・そのクリックによるURLへのアクセスにおいては別タブを開かせるようにするが、現在のタブは変えないようにする

・保管してあるURLをnode.js サーバー経由でバッチファイルに渡して署名してクリップボードにコピー

・フォームへの貼り付けが終わったら送信ボタンをクリックし、レスポンスが正常に返ったと確認された段階(つまりページ表示の完了を待たない)で、別タブを自動終了

署名は自動化に集中したいので省く。dorawiiより

Permalink | 記事への反応(2) | 11:58

2025-05-29

■ITの求人数、ここ数か月程度でも勢いがわかるな

求人ボックス

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%↑

Next.js凄すぎだろ

Permalink | 記事への反応(1) | 17:44

2025-05-11

■anond:20250511143717

その勉強会フリーランスのワイが突撃すると鼻で笑われそうで怖い。しかも元増田の言い分を信じるならGitもNode.jsもなしでポンコツ PCで開発してる奴なんだろうな。

このスペックでエンジニアぶれるのって日本ぐらいじゃない？

時間の無駄ではないか？マジで

Permalink | 記事への反応(2) | 14:48

書籍	主なテーマ	現在の位置づけ
------------------------	--------------------	--------------
人月の神話	ブルックスの法則、概念的完全性、銀の弾丸	ソフトウェア工学の最重要古典
ピープルウエア	生産性、組織、作業環境、チーム形成	開発組織論の古典
達人プログラマー	技術者の姿勢、抽象化、自動化、変更容易性	現代でも読みやすい準古典
Code Complete	コーディング、設計、レビュー、品質	実装技術の百科事典
ソフトウェア作法	UNIX的なプログラム設計と思考法	プログラミング文化の古典
プログラミング作法	命名、デバッグ、テスト、性能、移植性	C中心だが原則は普遍的
珠玉のプログラミング	アルゴリズム的問題解決	計算量・問題分解の古典
計算機プログラムの構造と解釈 SICP	抽象化、評価、言語処理系	コンピュータ科学寄りの古典

書籍	内容
-------------------------------------------------------	-------------------
リファクタリング第2版	振る舞いを変えずに内部設計を改善する
レガシーコード改善ガイド	テストのない既存コードを安全に変更する
Clean Code	命名、関数、クラス、可読性
テスト駆動開発	TDDの基本的な進め方
Growing Object-Oriented Software, Guided by Tests	テストからオブジェクト設計を成長させる
Working Effectively with Unit Tests	単体テストの設計とテスト容易性
A Philosophy of Software Design	複雑性を減らす設計
The Programmer’s Brain	コードを読むときの認知負荷

書籍	位置づけ
---------------------------------	------------------
オブジェクト指向における再利用のためのデザインパターン	GoF デザインパターンの原典
Head Firstデザインパターン	パターンの入門書
アジャイルソフトウェア開発の奥義	SOLID、パターン、アジャイル設計
エンタープライズアプリケーションアーキテクチャパターン	業務アプリの設計パターン
実践 UML	オブジェクト指向分析・設計
オブジェクトデザイン	責務駆動設計

書籍	内容
-------------------------------------------	-------------------
ソフトウェアアーキテクチャの基礎	アーキテクチャ特性、スタイル、意思決定
ソフトウェアアーキテクチャ・ハードパーツ	分割、粒度、データ、トレードオフ
Clean Architecture	依存関係、境界、ユースケース
エンタープライズアプリケーションアーキテクチャパターン	業務システムの設計パターン
Domain-Driven Design	複雑な業務領域のモデル化
実践ドメイン駆動設計	DDDの実践的な適用
Building Evolutionary Architectures	変更可能なアーキテクチャ
Fundamentals of Software Architecture	現代アーキテクチャの概論

書籍	内容
-------------------------------------------	--------------------
データ指向アプリケーションデザインDDIA	DB、分散処理、一貫性、レプリケーション
分散システムタネンバウム	分散システム全般の教科書
Designing Distributed Systems	分散システムの設計パターン
Release It!	本番障害、安定性、回復性
Site Reliability Engineering	SRE、SLI、SLO、運用
Building Secure and Reliable Systems	セキュリティと信頼性
Web Scalability for Startup Engineers	Web システムのスケーリング
System Design Interview	システム設計の考え方を広く学ぶ

書籍	内容
--------------------------------	-----------------
マスタリング TCP/IP 入門編	日本で最も定番のTCP/IP 入門書
コンピュータネットワークタネンバウム	ネットワーク全般の教科書
コンピュータネットワーキングトップダウンアプローチ	アプリケーション層から学ぶ
ネットワークはなぜつながるのか	ブラウザからサーバーまでの流れ

書籍	内容
------------------------------	---------------
データベースシステム	DB 理論の教科書
Database System Concepts	DBの標準的教科書
SQL アンチパターン	よくあるDB・SQL 設計の失敗
達人に学ぶ DB 設計徹底指南書	論理設計、正規化、性能
達人に学ぶ SQL徹底指南書	SQLの考え方
SQL パフォーマンス詳解	インデックスと実行計画
High Performance MySQL	MySQLの性能設計
PostgreSQL徹底入門	PostgreSQL固有機能

書籍	内容
------------------------------------	--------------
アルゴリズムイントロダクションCLRS	アルゴリズム分野の標準教科書
アルゴリズムとデータ構造	大学教科書的な基礎
珠玉のプログラミング	問題解決の古典
プログラミングコンテスト攻略のためのアルゴリズムとデータ構造	実装を伴う学習
問題解決力を鍛える！アルゴリズムとデータ構造	日本語での実践的入門
The Algorithm Design Manual	問題に適したアルゴリズム選択

書籍	内容
---------------------------	-------------
テスト駆動開発	TDDの原典
ソフトウェアテスト技法ドリル	同値分割、境界値など
はじめて学ぶソフトウェアのテスト技法	テスト技法の定番
実践ソフトウェアエンジニアリング	開発工程と品質全般
Googleのソフトウェアエンジニアリング	大規模開発、テスト、保守
単体テストの考え方／使い方	良い単体テストの設計
xUnit Test Patterns	テストコードのパターン集
Continuous Delivery	自動テストからリリースまで

書籍	内容
-----------------------------------	------------------
The DevOps ハンドブック	DevOpsの実践体系
Accelerate	開発組織とデリバリー性能の研究
Continuous Delivery	継続的デリバリーの原典的書籍
Site Reliability Engineering	GoogleのSRE
The Site Reliability Workbook	SREの実践
LeanとDevOpsの科学	Accelerateの日本語版
Infrastructure as Code	IaCの原則
Kubernetes Patterns	Kubernetes上の設計パターン
Release It!	本番耐性と障害対策

書籍	内容
----------------------------	-----------------
Kubernetes完全ガイド	Kubernetesの体系的な理解
Kubernetes Patterns	Kubernetesの設計パターン
入門 Kubernetes	Kubernetesの概念
Docker系の入門書	コンテナの操作
Infrastructure as Code	インフラのコード化
Cloud Native Patterns	クラウドネイティブ設計
クラウドデザインパターン	クラウド上の設計パターン

書籍	内容
-------------------------------------	--------------
要求工学系の教科書	要求の抽出・分析・管理
ソフトウェア要求	要求定義の体系
ユーザーストーリーマッピング	ユーザー行動と開発計画
ユースケース実践ガイド	ユースケース記述
RDRA2.0 ハンドブック	要求とシステム構造の整理
実践ドメイン駆動設計	業務モデリング
Domain Modeling Made Functional	型を使ったドメインモデリング
イベントストーミング	業務知識の探索

書籍	内容
-------------------------	------------
誰のためのデザイン？	人間中心設計の古典
インタフェースデザインの心理学	認知心理とUI
ノンデザイナーズ・デザインブック	レイアウト・配色・文字
Don’t Make Me Think	Web ユーザビリティ
About Face	インタラクションデザイン
デザインシステムの育て方	デザインシステム
Lean UX	仮説検証型のUX開発

書籍	内容
-----------------------------------------	-------------------
詳解TCP/IP	TCP/IPの古典
TCP/IP Illustrated	パケットレベルの詳細
High Performance Browser Networking	TCP、TLS、HTTP、ブラウザ通信
パケットキャプチャの教科書	Wiresharkなどを使った解析

書籍	内容
--------------------------------	----------------
Real World HTTP	HTTPの歴史と現代的機能
Webを支える技術	HTTP、URI、REST
HTTP: The Definitive Guide	HTTP/1.1時代の体系的解説
Web API: The Good Parts	Web API 設計

書籍	内容
--------------------------------	---------------
オペレーティングシステム 3つの簡単なピースOSTEP	仮想化、並行性、永続性
Operating System Concepts恐竜本	OSの標準的教科書
詳解UNIX プログラミング	UNIX システムコール
Linux プログラミングインタフェース	Linux APIの詳細
Linux のしくみ	Linux内部の入門
ふつうのLinux プログラミング	Linux上でのプログラム実行
30日でできる！OS自作入門	OSの動作を作りながら学ぶ
コンピュータシステムの理論と実装Nand2Tetris	論理回路から OSまで

書籍	内容
-------------------------------------------	--------------
体系的に学ぶ安全なWeb アプリケーションの作り方徳丸本	Web セキュリティの国内定番
Web Application Security	Web アプリの脆弱性と防御
The Web Application Hacker’s Handbook	Web 攻撃手法の古典
Security Engineering	セキュリティ工学全般
暗号技術入門	暗号、ハッシュ、署名、証明書
マスタリング TCP/IP 情報セキュリティ編	ネットワークセキュリティ
Threat Modeling	脅威モデリング
Building Secure and Reliable Systems	セキュアで信頼できる運用

「Node.js」を含む日記

■宮本佳林さんの方が俺よりできる人だと思った…😟

■ITエンジニア会話の中で出てくる本

ITエンジニア会話の中で出てくる本

ソフトウェア工学の古典

プログラミング・コード設計

オブジェクト指向・デザインパターン

Clean Architectureについて

分散システム・大規模システム

入門・全体像

TCP/IPを深く学ぶ

HTTP・Web

OS・Linux・低レイヤー

データベース

アルゴリズム・データ構造

テスト・品質保証

DevOps・CI/CD・SRE

クラウド・コンテナ

要件定義・モデリング

UI・UX・Webデザイン

開発組織・マネジメント

■ブックマークサービスつくったよー(ローカル or セルフホスト)

■あれあれ～？？？飲食店にAI連続凸するのは許されて苦情AI連続凸は許されないのかな～？？？ anond:20260625070518言及先エントリを開く

■WEBサーバーとNode.js（自分用備忘録）

ttp://localhost/test/hoge/piyo.html

■IDEを入れなくなった

■もういい加減にしてくれ、node_modules

肥大化するブラックホールと依存の闇

防ぎようのないサプライチェーン攻撃

■anond:20260315171908言及先エントリを開く

■開発がつまらなくなった

■2025年、WEB業界求人数の変化

■anond:20251215154048言及先エントリを開く

■anond:20251106215727言及先エントリを開く

■Downtown+を予想しよう

■自分のホームページを作ったかどうかでWEBの見え方が180度以上違う話

■みんな、MCPちゃんと使ってる？アプリの新機能とAIの未来がヤバいんだ

MCPって何？マジで未来の鍵なんちゃう？🗝️

AIの学習、追いついてなくね？問題😓

これからの時代、MCP提供が当たり前になる？🤔

開発者もユーザーもハッピーな未来！🌈

まとめ：MCPでAIとアプリの未来を切り開こう！✨

■7月2週LINEオープンチャット「はてなブックマーカー」1週間のまとめ

これは何？

要約内容

🩺 健康・体調・メンタル

☔ 天気・気候・災害

🍽️ 食・飲み物・食文化

🗳️ 政治・社会・制度

💼 仕事・キャリア・働き方

💰 お金・経済・投資

💻 テクノロジー・IT

🎭 エンタメ・趣味

🗾 地域・旅行・ローカル文化

📊 １週間分の総括

関連記事

オープンチャットの参加URL

■6月4週LINEオープンチャット「はてなブックマーカー」1週間のまとめ

これは何？

要約内容

🩺 健康・体調・気候

🍽 食とグルメ

💻 AI・テクノロジー・開発

🎮🎬 サブカル・エンタメ

🏢 仕事・キャリア・日常

🌏 社会・政治・経済・世相

🐱 動物・ペット

🚗 旅行・ローカル・余暇

関連記事

オープンチャットの参加URL

■AIが技術的に根本から全く使えない3つの理由

① LLM言語モデルの本質：意味理解ではなく「統計予測」、プログラミングに使えるというのは全く嘘、技術的背景から考えても二度手間になるだけ

わかりやすい例で言えば「私はコーヒーを」という文を書いたらAIはこう判断して動いている

意味理解や構文チェックをしているわけではない、だからこんな問題が頻発する。

もっと致命的な問題はこれ↓

ちなみに↓がAIに書かせたコードの1例、

② AI最大の欠点、ハルシネーション これは永遠に解決ができないメビウスの輪

【検証システムとのハイブリッド…いわゆる「RAG」】

③ 文化的偏在（Cultural Bias）

【滅茶苦茶一部の人間にしか刺さらない罵詈雑言】

■IT エンジニア会話の中で出てくる本

IT エンジニア会話の中で出てくる本

UI・UX・Web デザイン

■あれあれ～？？？飲食店にAI 連続凸するのは許されて苦情AI 連続凸は許されないのかな～？？？　anond:20260625070518

■anond:20260315171908

■2025年、WEB 業界求人数の変化

■anond:20251215154048

■anond:20251106215727

■みんな、MCP ちゃんと使ってる？アプリの新機能とAIの未来がヤバいんだ

これからの時代、MCP 提供が当たり前になる？🤔

■7月2週LINE オープンチャット「はてなブックマーカー」1週間のまとめ

■6月4週LINE オープンチャット「はてなブックマーカー」1週間のまとめ

②　AI最大の欠点、ハルシネーション　これは永遠に解決ができないメビウスの輪

③　文化的偏在（Cultural Bias）

【AI 信者が陰謀論者になるという本末転倒】

最初に投稿してエントリページに移動した親タブ側のjs コード

親タブから開かれる編集ページの子タブのjs コード

■anond:20250611114540

■anond:20250511143717