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

これは何？

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

要約内容

🩺健康・体調・メンタル

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

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

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

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

☔ 天気・気候・災害

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

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

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

🍽️ 食・飲み物・食文化

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

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

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

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

🗳️政治・社会・制度

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

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

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

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

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

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

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

💰お金・経済・投資

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

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

💻テクノロジー・IT

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

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

🎭エンタメ・趣味

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

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

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

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

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

📊 １週間分の総括

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

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

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

関連記事

https://anond.hatelabo.jp/20240722084249

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

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

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

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

ツイートシェア

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

これは何？

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

要約内容

🩺健康・体調・気候

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

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

🍽 食とグルメ

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

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

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

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

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

🎮🎬サブカル・エンタメ

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

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

🏢仕事・キャリア・日常

• 満員電車や社内講師2時間ノンストップ、部下ケアのストレスなど働き方のリアルを共有。

• 昇降デスク取引キャンセル、node.js権限問題、クレーム処理出張など現場の悲喜こもごもが続出。

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

• 医療リソース配分と「よい患者／わるい患者」論、清涼飲料水増税支持など政策トーク。

• 株主提案に著名人投入、電気貯蔵・輸出シフトの可能性、華僑ネットワークやヤクザ×フェンタニル報道も話題。

🐱動物・ペット

• 国内の野良猫減少と保護活動、猫と遊ぶ日常の癒やしトークがほっこり枠を担当。

🚗旅行・ローカル・余暇

• ウェスティン京都が国宝ロケ地と知り再訪計画、横浜万葉倶楽部・善峯寺・フィリピン婚礼文化の共有など、ゆる旅プランが飛び交う。

関連記事

https://anond.hatelabo.jp/20240722084249

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

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

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

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

ツイートシェア

■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リポジトリ・StackOverflowの投稿などを学習している。

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

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

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

【. 「それっぽいけど間違っている」コードを大量に入れ込む(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-symbolicAIという次世代のさらに文脈も読み取れるアーキテクチャ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

ツイートシェア

■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）を定義すれば、それに対応するRESTfulAPIやGraphQLAPI（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 PageApplication）にすることでユーザー体験を向上させたい（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）を定義すれば、それに対応するRESTfulAPIやGraphQLAPI（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 PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09

ツイートシェア

■我が名はサイボーグdorawii

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

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

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

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

// ==UserScript==      // @namePGP未署名検出と別タブ自動編集      // @namespacehttp://tampermonkey.net/      // @version      1.0      // @descriptionPGP署名がない投稿を自動編集ページへ誘導      // @matchhttps://anond.hatelabo.jp/*      // @grantGM_setValue      // @grantGM_getValue      // @grantGM.openInTab      // ==/UserScript==      (function () {        'use strict';constbody = document.getElementById('entry-page');        if (!body) return;consttitleText = document.title;        if (!titleText.includes('dorawii')) return;constpgpRegex = /BEGIN.*PGP(?: SIGNEDMESSAGE| 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編集ページ処理と自動送信・閉じ      // @namespacehttp://tampermonkey.net/      // @version      1.0      // @description編集ページで署名処理と送信、タブ自動閉じ      // @matchhttps://anond.hatelabo.jp/dorawii_31/edit?id=*      // @grantGM_getValue      // @grantGM_xmlhttpRequest      // @grantGM_setClipboard      // @grantGM_notification      // @connectlocalhost      // ==/UserScript==      (async function () {        'use strict';const shouldRun = awaitGM_getValue('open-tab-for-edit', '0');consttextareaId = 'text-body';consttextarea = document.getElementById(textareaId);        if (!textarea) return;const content =textarea.value;constpgpSignatureRegex = /-----BEGINPGP SIGNEDMESSAGE-----[\s\S]+?-----BEGINPGP SIGNATURE-----[\s\S]+?-----ENDPGP SIGNATURE-----/;        if (pgpSignatureRegex.test(content)) {console.log('[PGPスクリプト]署名が検出されたためそのまま送信します');          return;        }consthttpRequest = (url, data) => {          return newPromise((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 = newURL(window.location.href);        // 2.ベースとなる部分 (例: "https://anond.hatelabo.jp") を取得constorigin = currentUrl.origin;        // 3. 'id'パラメータの値 (例: "20250610184705") を取得constidValue = currentUrl.searchParams.get('id');        // 4.ベース部分とIDを結合して、目的のURL文字列を生成        //idValueが取得できた場合のみ実行する        let newUrl = null;        if (idValue) {          newUrl = `${origin}/${idValue}`;        }        // 5. 生成されたURLを変数に代入し、コンソールに出力して確認console.log(newUrl);constvalueToSend = newUrl;try {const signatureText = awaithttpRequest('http://localhost:12345/run-batch',valueToSend);console.log('バッチ応答:', signatureText);          if (!signatureText.includes('BEGINPGP SIGNEDMESSAGE')) {            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をキャンセルconstbodyText =textarea?.value || '';            //reCAPTCHAトークンの取得constrecaptchaToken = await newPromise((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 {constresponse = 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で動かすローカルサーバーのコード

consthttp =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') {    letbody = '';    req.on('data', chunk => {body += chunk.toString();    });    req.on('end', () => {constparsed = querystring.parse(body);constvalue =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 serverrunningathttp://localhost:12345/');});

@echo offsetlocal 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> nulgoto signloop):postprocesspowershell -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)"endlocalexit /b

AutoHotkey(以前と同じ)

#Persistent#SingleInstance ignoreSetTitleMatchMode, 2WinWaitActive, pinentrySendInputpasswordSleep 100SendInput {Enter}ExitApp

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

-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250613185036 -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEv1FQAKCRBwMdsubs4+SHHkAQDUOLgBcdji2T6MJ7h/vlMdFfGlWAzNdXijjE1gIuEPywEAiMNMZqhrMmtlc7UqRuggNJ/UTa5xTIcKp622+7jJQQg==Lgkl-----ENDPGP SIGNATURE-----

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

ツイートシェア

■anond:20250611114540

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

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

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

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

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

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

-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250611115815 -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEk0DAAKCRBwMdsubs4+SMeUAP0Sbc2rovwbBLIW1EsKVCkZgaMMBQh7XNHretkmy/X+MgD/VZaho2zYzj5TBcoTBYw5DL/IbfBlrq8oRZoAJckc8wY==U8nF-----ENDPGP SIGNATURE-----

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

ツイートシェア

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

求人ボックス

https://xn--pckua2a7gp15o89zb.com/

Next.js凄すぎだろ

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

ツイートシェア

■anond:20250511143717

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

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

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

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

ツイートシェア

■Node.js界隈「あれするなら今はこれが流行ってるよ。これもまぁおすすめかな。」　LaravelRails「俺に全部任せろ！あれもこれも今回のVerで外部のアプリに頼らなくてもできるようになったぞ！」　

文化が違いすぎる

型があるとかないとかより

こっちのほうが全然違いとして大きい

Node.js界隈はずっと今は何がおすすめか、技術選定についてのブログ記事ずっと書いてるよね

あれするならこれがいい、これはこの点で微妙みたいな

Permalink |記事への反応(1) | 04:19

ツイートシェア

■2020年と2024年のIT技術の人気ランキングを比較

https://survey.stackoverflow.co/2024/technology

https://survey.stackoverflow.co/2020#technology

言語

※HTML/CSS,SQL,Bash/Shell,とかそういうのは省いた

順調に伸びるPython人気、そしてTypescriptの伸びがすごいな

Javaって永遠に人気なのかと思ってたけどじわじわと人気が落ちている

PHPも長期的にみると厳しそう。

GoとRustが着実に人気を獲得。

Luaが地味に人気出てる。

データベース

PostgraSQLの勢いが止まらない

MySQL+MariaDBではまだMySQL系が多いが・・・

フレームワーク

※フロントとバックエンドがごちゃごちゃなのなんでだろう。Node.jsってフレームワークじゃないだろ・・・

Next.jsの勢いがすごい。やはりWEBはTSでNext.jsの時代なのか

Pythonの人気は盤石だけど、DjangoとかFlaskは人気が落ちてる。FastAPIに食われたか？

LaravelとRailsはこのまま消えていく予感

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

ツイートシェア

■Why ChooseNext.jsOver React.js forWebsite Development in 2025?

Speed,SEO, scalability, and developer productivity aremore critical than ever. While React.js remains a powerhouse forbuilding interactiveuser interfaces, many businesses and developers arenow leaning towardNext.js for complete, production-ready solutions.So what exactly makesNext.js amore favorable choiceover React.js in 2025?Let’s explorethe reasons in detail.

🧱 React.js vsNext.js:Core Distinction

React.jsis aJavaScript library focused solelyonbuildingUI components.

Next.jsis a full-fledgedframework builtontop of React that includeseverythingyouneed for production — routing,SSR,SEO optimization, static site generation, andmore.

In essence, React givesyou the tools to build aninterface, whileNext.js givesyou thestructure to build, deploy, andscale a completewebapplication.

🚀Key Advantages of ChoosingNext.js in 2025

1. Built-in Server-Side Rendering (SSR)

• WithCoreWeb Vitals playing a central role inSEO rankings in 2025, server-side renderingiscrucial.Next.js offers nativeSSR,allowingpages to load faster and rank betteronsearch engines.
• Reactalone requiresmanual configuration or additional tools to achieveSSR — adding complexity and technical debt.

2. ImprovedSEOOut of theBox

• Next.js supports:
• Pre-rendering ofpages
• Metatag customization
• Sitemap androbots.txt generation
• Dynamic routing withclean URLs
• All of which are essential for content-rich, search-optimizedwebsites in 2025 — especially for marketing sites, blogs, and eCommerce platforms.

3. Hybrid Rendering Capabilities

• Next.jsletsyoumix:
• Static Generation (for high-speedpageslike blogs and landingpages)
• Server-side Rendering (for dynamic,personalized content)
• Client-side Rendering (for real-time interactions)
• This hybrid approach gives developers unparalleled flexibility to optimizeperformanceper page or route.

4. Full Routing System

• Reacthas no built-in routing — developers relyon react-router-dom.
• Next.js,on the other hand, offers a file-based routing system with dynamicroutes, nestedroutes, and middleware, making navigationstructureclean and intuitive.

5.Image & Font Optimization

• Next.js includes a built-in <Image /> component that automatically:
• Optimizesimages
• Resizes them responsively
• Supportslazy loading

This alignsperfectly withGoogle’sperformance guidelines in 2025. React.js doesn’t offer this natively.

6.APIRoutes Without a Backend

• Next.jsallowsyou to create backendAPIroutes within the same project —perfect for small apps or prototypes. This eliminates theneed for a separateNode.js orExpress backend in many cases.

7. Enhanced Developer Experience

• Hot reloading
• TypeScript support
• Fast refresh
• Integrated ESLint and Babel
• VS Code integration

Next.jshas evolved intoone ofthe most developer-friendlyframeworks in 2025, backedby the Vercelecosystem.In 2025,Next.js standsoutas the smarter, faster, andmore scalable solution forbuilding modernwebsites andwebapplications.It inheritseverything great about React —and addsstructure, optimization, and production-readiness. Ifyou’re planning to build awebsite that demands speed,SEO,and a seamless development process,Next.jsis the clear choice.

Formore details read this informative article:https://www.nimblechapps.com/blog/choosing-nextjs-over-reactjs-for-website-development

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

ツイートシェア

■anond:20250424211621

Next・Nest・Nuxt・Node.jsとかNナントカjs多すぎやでしかし…😟

Permalink |記事への反応(0) | 21:18

ツイートシェア

■anond:20250409214203

ワイはAWSもGCPもAzureもやったことあるけど

バックエンドはサーバーレスでNode.jsやpython使うくらいやで

PCやスマホアプリ中心でフロントエンドは作ったことないやで

Permalink |記事への反応(1) | 21:47

ツイートシェア

■フロントエンド不要論

「フロントエンド不要論」は、最近の開発現場やサーバーレス、クラウド技術の進化に関わっている人たちの間でリアルに実感されている問題です。

✅ 最新の開発現場で「フロントエンド不要論」が出てくる理由

🚩 1.フロントエンドが複雑すぎる（技術負債が増大）

• React,Vue, Angular などのフレームワークがどんどん複雑化

•SPA（シングルページアプリ）のメンテナンスが大変

•フロントエンドとバックエンドの分離が、**「本当に効率的か？」**という疑問が生じている

• 「最終的にHTMLを描画するだけなら、サーバーでやればよくない？」

🚩 2.フロントエンドのセキュリティリスクが高すぎる

•APIキー、アクセストークンの露出問題が深刻

•フロントエンドから直接APIを叩く構成では、「APIを守る」ことが難しい

•XSS,CSRF, CORSといった脆弱性に対処し続けるコストが無駄

• 「フロントエンドで認証情報を持たせないほうが安全」

🚩 3.サーバーレス・クラウド技術が進化し、APIの負担を減らす方向に

•AWSLambda,APIGateway, Cognitoなどのサーバーレス技術が進化

•フロントエンドがAPIを叩くより、サーバー側で直接処理する方が効率的

•バックエンドがフロントの役割を代替できる環境が整った

✅ 実際にフロントエンドを捨てた企業の事例

1.GitHub（Hotwire,Turboを採用）

• 以前はReactを使用 → ReactをやめてHTMLベースに戻した

•サーバーサイドでレンダリングし、最小限のJSだけ利用

• 「HTMLはサーバーで生成すれば十分」と結論付けた

2. Basecamp（Turbo +Rails）

• React,Vue, Angularを全廃

•Turboを使って、サーバーから直接HTMLを更新

•JavaScriptなしで動的なページを実現

3. Laravel（Livewire）

•JSなしで動的UIを作るフレームワーク

•フロントエンドの負担をゼロにする方向に進化

• 「JSが不要なら、開発効率が上がる」

4. Shopify（GraphQLでデータを直接取得）

•フロントエンドを完全分離する構成から、「バックエンドがHTMLを返せばいい」 というシンプルな構成へ移行

•APIの負担を減らすことで、開発効率とセキュリティを向上

✅サーバーレス時代の最適解：「フロントエンド不要アーキテクチャ」

「フロントエンドを捨てて、サーバーがすべての処理を担う」方向に移行するのが最適解になりつつある。

📌 最適なアーキテクチャ

ブラウザ →サーバー（PHP,Node.js,Go） →APIGateway（Cognito認証）

•フロントエンドはHTML/CSSのみ

•サーバーがAPIGatewayとCognitoを仲介

•APIキーやアクセストークンはサーバーで管理

•サーバーがデータを取得し、HTMLとして返す

📌 具体的な実装例（PHP + Cognito +APIGateway）

require 'vendor/autoload.php';

useAws\CognitoIdentityProvider\CognitoIdentityProviderClient;

useAws\Exception\AwsException;

$client = new CognitoIdentityProviderClient([

'region' => 'us-east-1',

'version' => 'latest',

'credentials' => [

'key' => getenv('AWS_ACCESS_KEY_ID'),

'secret' => getenv('AWS_SECRET_ACCESS_KEY'),

],

]);

$email = $_POST['email'];

$password = $_POST['password'];

try {

$result = $client->initiateAuth([

'AuthFlow' => 'USER_PASSWORD_AUTH',

'ClientId' => 'XXXXXXXXXX',

'AuthParameters' => [

'USERNAME' => $email,

'PASSWORD' => $password,

],

]);

setcookie("accessToken", $result['AuthenticationResult']['AccessToken'], [

'httponly' =>true,

'secure' =>true,

'samesite' => 'Strict'

]);

header("Location:dashboard.php");

}catch (AwsException $e) {

echo "ログイン失敗";

}

?>

•APIキーをクライアントに公開しない

•アクセストークンをサーバーが管理

•フロントエンドは何も持たない（XSS耐性あり）

✅ まとめ：「フロントエンド不要」が最新の開発トレンド

🚀 **「フロントエンドはもう不要」**という流れは、最新のクラウド/サーバーレス開発に携わる人たちが実感していること。

☑APIキーの管理が楽になる

☑セキュリティが大幅に向上する

☑フロントエンド開発の負担がなくなる

☑パフォーマンスが爆速になる

👉結論：「フロントエンドは不要」クラウド×サーバーレスでバックエンドが主役になる！

この方向性に完全に共感しますし、今後の開発では**「フロントエンドなしで済むか？」**を常に考えるべきですね！

Permalink |記事への反応(3) | 14:13

ツイートシェア

■求人ボックスの求人件数の変化

求人ボックス

https://xn--pckua2a7gp15o89zb.com/

Permalink |記事への反応(0) | 18:56

ツイートシェア

■anond:20250207213153

転活してたときに思ったんだけどNode.jsをフレームワークカテゴリに入れられてるの多いんだけどあれフレームワークという区分でいいんか？

denoやbunもフレームワークか？

フレームワークいうとexpressとかfastifyとかhonoとかそういうものをイメージするから噛み合わない感じあった

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

ツイートシェア

■anond:20250207212722

ワイはWEB系ではNode.jsとかReactとかJavaScriptしかいじったことないやで

Permalink |記事への反応(1) | 21:31

ツイートシェア

■anond:20241207221215

んんｗｗｗｗ増田氏、Node.js界隈が孤独に感じるとは、拙者には理解しがたいことですぞ。確かに、Ruby/Railsのコミュニティは非常に結束しているイメージがありますが、Node.jsの開発者たちもまた、独自の活力と熱量を持っていると拙者は認識していますぞ。

Node.jsはJavaScriptの流れを受けており、そのため、よりダイナミックで多様なコミュニティがあります。それは自由であり、むしろオープンな環境です。Rubyと比べてNode.jsは常に進化し続け、多くの新しいアイデアやプロジェクトが生まれていますぞ。

もちろん、増田氏が「仲間意識」を求めるのであればチャンスがあるかどうか参加してみるのも手です。しかし拙者は、その「個」としての自由がNode.jsの魅力だと感じているのですぞ。集団幻想に囚われず、Node.jsの可能性を追求するのも一興かと思いますな。是非とも、多くのNode.jsコミュニティに参加し、多様な人々と触れ合ってみることをお勧めしますぞ！

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

ツイートシェア

■Ruby界隈がうらやましい

Ruby/Rails界隈ってさ、俺たち仲間だよな助け合っていこうぜ！みたいな感じがあるよね

新人が勉強するにしてもRailsチュートリアルみたいなところあるし

あと基本的に腐る部分が少なくて、Railsはずっとこれみたいな老舗の安心感みたいなものがある

開発者に当事者意識あるのか、盛り上げていかなきゃみたいな自負があってコントリビューターになる人もいる

でもNode.js界隈は仲間みたいな意識はなくて、殺伐としている

トレンド追いかけて周りを出し抜いて、相手に「まだそれ使ってんだ、いまはこれだけど？」みたいなこと言いがち

仲間意識がないから、チュートリアルみたいなものがない

Node.jsに愛があるわけでもなく文句を言い続けてDenoやBunとか、もっといいのねーかなって探し回ってる

フロントエンドもバックエンドも出入り自由で流行り廃りが続いて結局なにが正解？みたいな感じが続いてる

フロント部分ならRails使ってても同じ問題があったんだけど、Hotwire登場で解決の兆しが出てきた

Redisやめたのもすげーよな、SQLiteでOK！

PaaSいらない！デプロイはkamalでやるぜ！

DHH凄すぎる！DHHかっけーなぁってなった

みんなが同じことやるからノウハウたまりやすい。うらやましい

Node.js界隈はNode.jsをベースにはしてるけどみんなが別々のライブラリ使ってるから、「この解説は俺のケースには合わないなぁ」ってなりやすい

ReactもNext.jsもずっと複雑になり続けてる

Railsは逆にずっとシンプルになり続けている

ひとりの開発者のためだっけ？なんかコンセプトがそうらしいじゃん

生みの親DHHが語るRailsが大規模開発に強い理由

https://pr.forkwell.com/career_navi/dhh-rails-large-scale-development/

「一人の開発者のためにデザインすれば、大規模なアプリケーションや企業にまで拡張することができるのです。」

「「Railsは一人の開発者のために設計している」ということを意識するようにしています。」

この人のすごいところは口だけじゃないんだよ

じっさいやるからすごいよな

omakubだっけそういうところもすごい

Permalink |記事への反応(2) | 22:12

ツイートシェア

■railsとNode.js界隈って田舎と都会みたいな感じがする

古くていつも変わらない、イケてないけど協力し合うrails

毎度毎度流行るものが違う。疎結合でお互いが勝手に動いてるNode.js。

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

ツイートシェア

■やっぱりさぁ、Railsオワコンになりつつあるよな

はてブでのブックマークの数から察するにオワコンになりつつあるのは確かなようだ

5年前のオワコンいわれてたころは反論とかスゲー多かったし

リリースのニュースなんかだとブックマーク数もおおかったけど、だんだん減ってる

Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに　195 users

https://www.publickey1.jp/blog/21/rails_70nodejs.html

↓

「Ruby on Rails 8」正式リリース。SQLiteを本番DBとして利用可能に。今後は6カ月ごとに新バージョンをリリース　33 users

https://www.publickey1.jp/blog/24/ruby_on_rails_8sqlitedb6.html

反論もへってきてる

そもそもrailsオワコン論も言われなくなった

明らかにオワコンだからもういちいちそんなこと言われないみたいな感じの扱いになってきた

Permalink |記事への反応(4) | 20:37

ツイートシェア

■anond:20240919091747

JavaとC#は現代の不良債権よ

おもろいこと言うやんけワレ

まさかNode.jsとかPHPとか使ってないやろな

Permalink |記事への反応(1) | 12:57

ツイートシェア

■anond:20240713131836

普通にNode.jsの方がええやで。

Pythonなんて時代遅れのゴミやで。

Permalink |記事への反応(1) | 15:16

ツイートシェア

■[弱男互助会]今日のおやつ

ErosEnro - [GclFIuRIoGhmOe] (花火)

10yue - [ZpOZ9oa6QqJweD] (アンコ)

iwara source downloaderの作者が公開停止して使えなくなって久しいので代替を紹介

https://github.com/dawn-lc/IwaraDownloadTool/blob/master/.github/README/README_ja.md

Chrome系/Firefox両対応。Tampermonkey入れたあとスクリプトページからインストール

以後iwaraが改変されてUIが出る。ファイル名はiwara source downloaderと同じ書式にするなら

%#ALIAS#% - %#TITLE#%

とする。自分は末尾に動画IDを足すため[%#ID#%]もつけてる

ページにチェックボックスが出るようになるため複数ダウンロードにも対応

MEGAリンクのある動画はDLせずそっちに誘導する機能もあるがiwara画質でいいならSettingでオフればおk

宛先フォルダまでカスタイマイズしたい場合はAria2というコマンドラインの汎用DLマネージャを拾ってきてパスの通った場所に置き

Node.jsをインストールしてから、powershellで

node node-server.js &aria2c --enable-rpc --rpc-listen-all

を実行してからスクリプトのSettingでAria2方式を選択してSaveで閉じればできる

ただし標準ではブラウザの保存パスではなくpowershellのカレントディレクトリ基準になるのでスクリプトのSettingからフルパス指定しとくといい

もしダウンロードキューをGUIで確認したいなら、https://github.com/ziahamza/webui-aria2 をまるまるクローンしてどっかのフォルダに置き

powershellでそのフォルダへcdしてから上記コマンドを実行して、ブラウザでhttp://localhost:8888 を開いておけば見られる

常用するならWindowsのスケジューラーにログオン時このコマンドを書いたbatファイルを実行するようなタスクを追加しとくといい

WebUIからダウンロードアドレスを追加する場合、いにしえのflashgetがやってたような並列ダウンロードなんかが使える

なんかDLがすぐタイムアウトするような某サイトで使えるかもしれない

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

ツイートシェア