  |
はてなキーワード: Applicationとは
コードハイライトくらいかと思ったら、増田の削除が簡単になってた
これまではCookieに保存されたトークンが必要で、フォームかCookieから手動で取り出す必要があった
自動でやれなくもないけど、消したいものがある一覧画面だとフォームに存在せず、CookieはHttpOnlyなのでJSから取得できなかった
別ページをfetchして正規表現でHTMLから抜き出すみたいなことやればできなくもないみたいなものだった
つまり事前準備不要な単純なブックマークレットで一覧画面に削除ボタンを追加できる
const user = document.querySelector(".username a").textContent for (const e of document.querySelectorAll(".edit")) { const id = new URL(e.href).searchParams.get("id") const btn = document.createElement("button") btn.textContent = "消" btn.onclick = async () => { await del(user, id) e.closest(".section").remove() } e.after(btn) } const del = async (user, id) => { const url = new URL(`https://anond.hatelabo.jp/${user}/edit`) const params = new URLSearchParams() params.append("mode", "confirm") params.append("id", id) params.append("recaptcha_token", "") params.append("title", "") params.append("body", "") params.append("delete", "削除する") const res = await fetch(url, { method: "POST", headers: { "Content-Type": "application/x-www-form-urlencoded" }, body: params.toString(), }) return res.ok }
これは神アプデ
const rkm = "<formからトークンを取り出してここに入れる>" const user = document.querySelector(".username a").textContent for (const e of document.querySelectorAll(".edit")) { const id = new URL(e.href).searchParams.get("id") const btn = document.createElement("button") btn.textContent = "消" btn.onclick = async () => { await del(user, rkm, id) e.closest(".section").remove() } e.after(btn) } const del = async (user, rkm, id) => { const url = new URL(`https://anond.hatelabo.jp/${user}/edit`) const params = new URLSearchParams() params.append("rkm", rkm) params.append("mode", "confirm") params.append("id", id) params.append("recaptcha_token", "") params.append("title", "") params.append("body", "") params.append("delete", "削除する") const res = await fetch(url, { method: "POST", headers: { "Content-Type": "application/x-www-form-urlencoded" }, body: params.toString(), }) return res.ok }
まーた読んでない増田か
"Post-secondary participation and graduation", p43-44, https://unesdoc.unesco.org/ark:/48223/pf0000397622
Case study – Japan: Gender focused Affirmative Action Policy in Higher Education
Japan’s Diversity, Equity, and Inclusion (DEI) initiatives in HE offer a nuanced case study of affirmative action policies with a predominant focus on gender. These initiatives have largely centred on increasing female representation, particularly in STEM fields, through targeted admissionsand hiring practicessuch as female-only quotas. While inspired by Western DEI models, Japan’s implementation has been selective and narrow, often overlooking other dimensions of disadvantage such as socioeconomic status, rural origin, and even the underrepresentation of men in certain academic tracks.
Overall, the implementation of these initiatives has led toincremental gains in female participation, especially in traditionally male-dominated disciplines (Kunitake, 2025). However, statistical analyses from institutions such as Doshisha University reveal a more complex picture: while women are more likely to pursue higher education, men are increasingly underrepresented, particularly in non-STEM fields, and are more likely to enter the workforce directly after high school. Moreover, students from low-income households and rural areas face significant barriers to accessing higher education due to the high costs of tuition and living expenses, which are not adequately addressed by current DEI policies (Kunitake, 2025).
Kunitake’s (2025) findings highlight a critical issue: Japan’s DEI efforts have disproportionately focused on gender, often overlooking other dimensions of disadvantage such as socioeconomic status, geographic origin, and male underrepresentation in certain academic tracks. The study also references the gender equality paradox, suggesting that in more gender-equal societies like Japan, inherent gender preferences in career choices may become more pronounced, complicating the rationale for gender-targeted interventions (Kunitake, 2025).
The challenges identified include:
- Selective application of diversity principles, with limited attention to intersectionality.
- Potential reverse discrimination and social resistance to gender-exclusive policies.
- Lack of comprehensive evaluation mechanisms to assess the effectiveness and equity of DEI initiatives.
⚠️Beware of fraud⚠️
Inside the application, scammers may approach you with false stories like “You can profit by inventing” or “I want to meet you yesterday,” and try to make you transfer money. These “investment scam” and “romance scums” are popular all over the word.
Even in 9monsters, users like below have been confirm, so please be careful.
⚠️ They suddenly send you messages using Instagramer photos or handsome images of a different person
⚠️ Their Japanese is fluentless, and they talk with sentences like it was translate
⚠️ They will always invite you to move to message apps such as LIME to continue the talk
⚠️ They say things like “You will definitely lose money” or “I need travel fee to come meet you,” and try to make you bank in money
They will try to steal your money by many method, but just keeping the below can protect your important money.
‘🙅♂️Do not send money to someone you have meet🙅♂️’
At 9monsters we regularly issue warnings, however,
if you already transfered, it will be at our responsibility, so we cannot take care about it here.
Please be careful by all mean.
※This information is a periodic warning we post irregularly
※The National Consumer Center also sends information occasionally, so please see here too ↓
Dans l’application, des escrocs vous approchent avec des histoires mensongères comme « On peut gagner avec l’investisement » ou « Je veux te voir pour te rencontrer », et ils vous font virer de l’argent. Les « arnaques d’investissement » et les « arnaques romance » sont à la mode mondialement.
Même dans 9monsters, des utilisateurs comme ci-dessous ont été confirmer, donc faites attention.
⚠️ Ils envoient soudainement un message en utilisant des photos d’instagrameur ou des images d’un beau mec d’une autre personne
⚠️ Leur japonais est trop bien, mais ils vous parlent avec des phrases comme si c’était traduite
⚠️ Ils vous proposent obligatoirement de passer sur des applis de message comme LINEE pour continuer la conversation
⚠️ Ils disent « Tu vas sûrement gagner » ou « Je veux l’argent de voyage pour venir te voir », et ils essayent de vous faire déposer de l’argent
Ils utilisent des méthodes variées pour vous voler l’argent, mais en respectant seulement ci-dessous vous pouvez protéger votre argent important.
« 🙅♂️Ne virez pas d’argent à une personne que vous n’avez jamais déjà rencontré🙅♂️ »
Chez 9monsters, nous diffusons des avertissements régulièrement, mais
si vous avez déjà fait le virement, ce sera de notre faute, donc nous ne pouvons pas faire une réponse ici.
Faites très attention, s’il vous plaît.
※Ces informations sont une alerte de prévention publiée de temps en temps
※Le Centre national de la vie du peuple publie aussi des infos régulièrement, donc regardez aussi ↓
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
以下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を意識。
https://profile.hatena.ne.jp/dorawii_bukuma/
はてなのサイト側で読み込まれているはずのrksトークンを生成する関数を直接叩く方法がどうしても分からず結局request処理を自分で書く方法ではなく自動でUI側の保存ボタンをクリックするという無難な方向に落ち着いた。
最初から後者の方法をとっていればもっと全然早く作れたのにというは所詮言い訳か。
とにかくスクリプトを公開しておく。
@echo off
cd /d "C:\Users\user\Documents\jsscript"
:: Nodeサーバーを別ウィンドウで起動
start /min "" node run-batch-server.js
:: Pythonサーバーを別ウィンドウで起動（hatenaserver配下）
start cmd /k "" python hatenaserver\server.py
{
"username": "",
"password": ""
}
from flask import Flask, request, jsonify
import json
import os
from hatena_client import HatenaClient
from flask_cors import CORS
app = Flask(__name__)
CORS(app)
config_path = os.path.join(os.path.dirname(__file__), 'config.json')
with open(config_path, encoding='utf-8') as f:
config = json.load(f)
@app.route('/bookmark', methods=['POST'])
def handle_bookmark():
data = request.json
url = data.get("url")
if not url:
return jsonify({"error": "Missing URL"}), 400
client = HatenaClient(config["username"], config["password"])
client.start_browser()
if not client.login():
client.quit()
return jsonify({"error": "Login failed"}), 403
success = client.add_bookmark(url)
client.quit()
return jsonify({"status": "ok" if success else "fail"})
if __name__ == "__main__":
app.run(port=12347)
// ==UserScript==
// @name 自動セルクマ送信
// @namespace tampermonkey.net/
// @version 2025-08-07
// @description try to take over the world!
// @author You
// @match anond.hatelabo.jp/*
// @grant none
// ==/UserScript==
(function () {
'use strict';
const url = location.href;
if (!/^https:\/\/anond\.hatelabo\.jp\/\d+$/.test(url)) return;
const editLink = document.querySelector('a.edit');
if (!editLink) {
// 既に編集ページなので処理をスキップ
console.log('編集リンクが存在するため、スクリプトを終了します。');
return;
}
fetch('localhost:12347/bookmark', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ url: url })
}).then(r => console.log("通知成功")).catch(e => console.error("通知失敗", e));
})();
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250821192753# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKb0qwAKCRBwMdsubs4+ SHfiAQDcXmTHBaZ5Zzr1KI/OxZ0xl69oevOdy1FXJYwYvsmo5AD/ZPtZiO1JgTDj m+27iymlkdzIXOIGWfC82UTr1mJ7EwU= =YoV+ -----END PGP SIGNATURE-----
(以下の両トラバへの返信です)
https://anond.hatelabo.jp/20250818063524
https://anond.hatelabo.jp/20250818082015
トラバ両氏は、著者を信頼してか、または自身の知見から、示された年齢の偏りが統計に悪影響を及ぼすほどではないと捉えてるわけだよね。
私は著者への信頼もない(疑っているというわけではなく純粋に素性を知らない)し、自身の知見もないので、もう少し探ってみたい。
そもそも75歳以上の年齢比率にして10.5ポイントの差が、かなり大きいとは感じる。とりわけ、5%の統計有意に滑り込む可能性の大小を考慮する上では。
75歳以上の予後についてのさらに細かい年齢別の内訳は、膵臓癌においては見つけられなかった。しかし以下の年齢層別データからの敷衍で、生存率がどんどん悪くなりそうだとは思える。また、元論文の全体の平均年齢に大差がない点(強いて言えばワクチン3回以上に不利)と、SDにも大差がない点(強いて言えばワクチン3回以上に有利)は、いずれもオモテに現れた10.5ポイントの差についての妥当性を高めてくれるとは言えそう。元データがあればもっとわかりやすいんだろうけど。
SEER*Explorer Application
コロナについては、超高齢層のデータがちゃんと細かく分かれていて、70代・80代・90代以上と、倍々で重症化率や致死率が高くなっているデータはある。(こちらは元々知っていたので、膵臓癌についても同様の傾向だろうと考えていました)
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-----
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
Both the Smoot-Hawley Tariff Act of 1930 and the tariffs imposed during the Trump administration (starting in 2018 and again in his second term) were protectionist trade measures intended to shield domestic industries from foreign competition. However, they differ in several key aspects:
Smoot-Hawley Tariff Act (1930):
Timing: Enacted during the onset of the Great Depression.
Scope: Raised tariffs on over 20,000 imported goods, primarily targeting agricultural and manufactured goods.
Average Increase: Increased existing import duties by an average of about 20%. Some sources state the average increase on dutiable goods was higher.
Motivation: Primarily aimed at protecting American farmers and industries struggling with overproduction and decreased demand.
Congressional Role: Tariff rates were set by the U.S. Congress.
Economic Context: The U.S. was running a trade surplus at the time, although imports of manufactured goods were increasing.
Impact: Widely blamed for exacerbating the Great Depression by triggering retaliatory tariffs from other countries, leading to a sharp decline in global trade and U.S. exports.
Trump Tariffs (2018-2020 & 2025):
Timing: Implemented during a period of relative economic stability in the first term, and again in a context where Trump declared a "national emergency" regarding foreign trade in his second term.
Scope: Targeted specific countries (e.g., China, EU, Canada, Mexico) and specific industries (e.g., steel, aluminum) initially. The second term actions propose broader tariffs on all countries and potentially higher reciprocal tariffs on those with large trade deficits with the U.S.
Average Increase: The average increase varied depending on the targeted goods and countries. Some reports indicate that Trump's proposed tariffs in his second term could result in an average duty surpassing the levels of Smoot-Hawley.
Motivation: Stated goals included reducing trade deficits, protecting national security, encouraging domestic manufacturing, and addressing what Trump considered unfair trade practices and intellectual property theft. His second term rhetoric emphasizes "reciprocity" and addressing non-tariff barriers.
Presidential Authority: Implemented through presidential executive orders, leveraging national security clauses and other trade laws, granting the President more direct control.
Economic Context: The U.S. had significant trade deficits. Trade as a percentage of GDP was also much larger than in 1930.
Impact: Led to retaliatory tariffs from affected countries, impacting U.S. exports and increasing costs for some American businesses and consumers. The broader potential impact of the second term tariffs is still unfolding, but experts predict higher prices for consumers and negative effects on the U.S. and global economies, with the possibility of a significant reduction in U.S. GDP.
Similarities:
Protectionist Intent: Both aimed to protect domestic industries from foreign competition through the imposition of tariffs.
Unilateral Actions: Both involved significant unilateral actions by the U.S., potentially disrupting established trade relationships.
Risk of Retaliation: Both actions triggered or are expected to trigger retaliatory measures from trading partners.
Key Differences:
Economic Climate: Smoot-Hawley was enacted during a severe economic downturn, while Trump's tariffs were initiated in a more stable (initially) economy.
Target and Scope: Smoot-Hawley was a broadside across many imports, while Trump's tariffs were more targeted initially, with the potential for broader application in his second term with a focus on "reciprocity."
Tariff Levels: While both increased tariffs, the average level and the specific rates on certain goods differed. Some analyses suggest Trump's second-term proposals could exceed the average levels of Smoot-Hawley.
Authority: Smoot-Hawley was a result of Congressional action, while Trump's tariffs were largely driven by presidential authority.
Global Trade Landscape: The global economy and the interconnectedness of trade were vastly different in 1930 compared to the periods of Trump's tariffs.
In conclusion, while both the Smoot-Hawley Tariff Act and the Trump tariffs share a protectionist motivation, they occurred in different economic contexts, had varying scopes and average levels, and were implemented through different means. The potential for negative economic consequences, including trade wars and harm to the global economy, is a significant concern associated with both historical and contemporary tariff actions.
id を手動でコピーしてくるのが面倒だったから、削除ボタンが画面に出るようにした
押すと即削除
const rkm = "(トークン的なもの)" const user = "(ユーザ名)" const delmasda = (id) => fetch(`https://anond.hatelabo.jp/${user}/edit`, { "headers": { "content-type": "application/x-www-form-urlencoded", }, "referrer": "https://anond.hatelabo.jp/", "referrerPolicy": "origin", "body": new URLSearchParams({ "rkm": rkm, "mode": "confirm", "id": id, "delete": "削除する" }).toString(), "method": "POST", }) for (const sec of document.querySelectorAll(".section")) { const id = sec.querySelector("a").href.match(/\/(\d{14})/)[1] const delbtn = document.createElement("button") delbtn.textContent = "削除" delbtn.onclick = async () => { await delmasda(id) sec.remove() } sec.querySelector(".edit").after(delbtn) }
増田の削除をひとつひとつ詳細画面開いてするのが面倒だからまとめて消すスクリプトやで
const rkm = "(トークン的なもの)" const ids = ["(削除する増田ID)"] const user = "(ユーザー名)" for (const id of ids) fetch(`https://anond.hatelabo.jp/${user}/edit`, { "headers": { "content-type": "application/x-www-form-urlencoded", }, "referrer": "https://anond.hatelabo.jp/", "referrerPolicy": "origin", "body": new URLSearchParams({ "rkm": rkm, "mode": "confirm", "id": id, "delete": "削除する" }).toString(), "method": "POST", })
MicroSoftASPじゃなくApplication Service ProviderのASP。楽天とかYahooとかFutureShopとか。
In the labyrinthine realm of digital content dissemination, an enigmatic phenomenon has surfaced, challenging our axioms regarding the nexus between content ubiquity and viewer cognitive acumen. This disquisition endeavors to elucidate the paradoxical inverse correlation between video viewership metrics and the intellectual quotient of the audience, propounding that audiovisual content amassing prodigious view counts tends to captivate viewers with a mean Intelligence Quotient (IQ) of 100, while their more esoteric counterparts allure a demographic boasting an average IQ of 120.
To fathom this counterintuitive paradigm, one must first grapple with the multifarious nature of human cognition and the intricate interplay between intellectual capacity and media predilections. This hypothesis, positing an inverse relationship between a video's popularity and the mean IQ of its viewership, necessitates a rigorous examination of the underlying psycho-sociological and neurocognitive factors that may engender such a paradoxical outcome.
The application of Cognitive Load Theory to media consumption habits provides a plausible explication for this phenomenon. Videos achieving viral status often employ reductionist narratives and readily assimilable information, minimizing cognitive strain. Conversely, less ubiquitous videos may delve into more abstruse subject matter, demanding heightened cognitive engagement and a more sophisticated intellectual framework for comprehensive assimilation.
The pervasive influence of recommendation algorithms in content distribution platforms cannot be discounted in this analysis. These algorithmic arbiters, designed to maximize user engagement, may inadvertently engender epistemic bubbles that reinforce existing cognitive predispositions. Individuals with superior IQs may actively seek out more intellectually challenging or esoteric content, thereby circumventing the algorithmic propensity towards homogenization and cognitive stasis.
It is imperative to consider the socioeconomic dimensions that may influence both IQ development and media consumption patterns. Higher IQ individuals often correlate with elevated socioeconomic status, potentially affording them greater access to diverse epistemological resources and fostering a predilection for more intellectually stimulating content. This demographic may be less susceptible to the allure of mainstream, highly-viewed videos that cater to a broader, less discerning audience.
The ramifications of this inverse relationship between viewership and viewer IQ are profound for content creators and platform developers alike. It challenges the prevailing paradigm that equates popularity with quality or intellectual value. Content creators targeting a more intellectually discerning audience may need to recalibrate their expectations regarding view counts and engagement metrics, focusing instead on cultivating a dedicated niche audience that values cognitive stimulation over mass appeal.
In summation, the observed dichotomy between high-viewership videos attracting an audience with an average IQ of 100 and their less popular counterparts appealing to viewers with a mean IQ of 120 underscores the complex relationship between intellectual capacity and media consumption in the digital age. This phenomenon necessitates a reevaluation of how we measure content value and success in the online sphere, prompting a more nuanced approach to content creation, curation, and consumption that acknowledges the diverse cognitive needs of the audience spectrum. The implications of this paradigm shift extend far beyond mere metrics, touching upon fundamental questions of epistemology, cognitive diversity, and the very nature of intellectual engagement in the digital era.
I've noticed a non-negligible number of people who have not only completed compulsory education in regular classes but have also received higher education and graduated from university, yet struggle with reading comprehension (understanding the meaning of text), cannot read long texts, and even have difficulty understanding videos.
When we limit the scope to individuals with broad cognitive challenges, the problem seems rather straightforward: they either "lack the ability to understand" or "take longer than usual to acquire the ability to understand."
Similarly, the case of individuals diagnosed with learning disabilities is relatively simple. While they may not have broad cognitive challenges, they require different approaches and training due to their unique learning styles.
However, it is perplexing that university graduates without broad cognitive challenges or diagnosed learning disabilities struggle to understand not only written text but also simplified video content.
I suspect that the underlying causes might include gaps in the horizontal transfer of experiences and knowledge, a severe lack of adaptability, and an extreme deficit in metacognition. Has there been any research on these issues? Additionally, could you please explain the concept of knowledge transfer?
(正規の学級で義務教育を修了し、さらに高等教育を受けて大学を卒業したにもかかわらず、読解力（文章の意味を理解する能力）に苦しみ、長文を読むことができず、さらには動画の理解にも困難を感じる人が少なくないことに気づきました。
認知能力に広範な課題を抱える個人に範囲を限定すると、問題は比較的単純です。「理解する能力がない」か、「理解する能力を獲得するのに通常よりも時間がかかる」かのいずれかです。
同様に、学習障害と診断された個人の場合も比較的単純です。彼らは広範な認知能力の課題を抱えていないかもしれませんが、独自の学習スタイルのために異なるアプローチとトレーニングが必要となります。
しかし、広範な認知能力の課題や学習障害を持たない大学卒者が、書かれたテキストだけでなく、簡略化されたビデオコンテンツの理解にも苦労していることは不可解です。
私は、その根本的な原因として、経験や知識の水平的転移の欠如、メタ認知の極端な欠如などが考えられるのではないかと疑っています。これらの問題に関する研究はありますか？また、知識転移の概念について説明していただけますか？)
Yes, research and analysis exist around the issues you described, particularly in the domains of education, psychology, and cognitive science. Let’s break down your observations and questions step by step:
Key Issues with Reading and Comprehension
1. Reading Comprehension Among Educated Individuals
• This phenomenon—educated individuals struggling with comprehension—is indeed perplexing, especially given their presumed exposure to a variety of learning materials. It suggests that education systems sometimes emphasize rote learning and surface-level knowledge acquisition over deeper understanding, critical thinking, and metacognition.
• Horizontal Transfer Gaps: This refers to the inability to apply knowledge or skills learned in one context to another. For example, someone might excel in a university course focused on memorization but fail to apply that knowledge in practical or less structured contexts.
• Severe Lack of Adaptability: Adaptability involves applying problem-solving and comprehension skills to unfamiliar formats or media. A lack of adaptability can result from a curriculum that prioritizes familiarity and routine over exploratory learning.
• Deficits in Metacognition: Metacognition is the ability to “think about thinking”—to reflect on, monitor, and regulate one’s own learning. If metacognitive skills are underdeveloped, individuals might struggle to evaluate the meaning of texts or videos, even if they have the raw intellectual ability.
Research Insights
1. Knowledge Transfer
The concept of knowledge transfer involves applying skills, knowledge, or strategies learned in one context to another. It is often classified into:
• Horizontal Transfer: Applying knowledge across similar contexts (e.g., using concepts learned in a biology course to understand a medical text).
• Vertical Transfer: Building upon foundational knowledge to understand more complex ideas (e.g., using basic algebra to solve advanced calculus problems).
Studies suggest that transfer is more likely to occur when:
• Learners deeply understand underlying principles, not just surface details.
• Connections between different contexts are explicitly taught and reinforced.
• Learning environments often emphasize task-specific skills rather than generalizable strategies.
• Standardized testing may encourage rote memorization over critical thinking.
• Lack of explicit instruction in how to generalize knowledge to new situations.
Research highlights the importance of metacognition in learning. Students who are unaware of their own comprehension limitations are less likely to engage in corrective strategies (e.g., rereading, seeking clarification). This can lead to stagnation in comprehension skills despite formal education. Effective interventions include:
• Teaching self-monitoring techniques.
• Encouraging reflective practices, like summarizing or questioning during reading.
4. Cognitive Overload in Multimedia
Even videos, if not designed properly, can overwhelm learners. The Cognitive Theory of Multimedia Learning suggests that excessive extraneous information or unclear organization in videos can overload working memory, hindering comprehension.
Strategies and Research-Based Solutions
1. Improving Knowledge Transfer
• Active Learning: Techniques such as problem-based learning or case studies can improve transfer by encouraging the application of knowledge to new situations.
• Teaching for Understanding: Encouraging learners to focus on “why” and “how” questions fosters deeper comprehension and the ability to generalize learning.
• Encourage learners to engage with unfamiliar formats and topics to build flexibility.
• Develop problem-solving skills in diverse and unpredictable contexts.
3. Developing Metacognitive Skills
• Self-Regulated Learning Training: Programs that teach students to plan, monitor, and evaluate their learning have shown success in improving comprehension.
• Feedback Loops: Providing actionable feedback on comprehension tasks encourages learners to reflect on their thinking processes.
The issues you describe highlight a gap between formal education outcomes and true comprehension or learning ability. Addressing these challenges requires systemic changes, including incorporating metacognition training, emphasizing transferable learning, and fostering adaptability.
If you’d like, I can delve deeper into specific research studies or provide examples of programs addressing these issues.
This is a fascinating and concerning observation that touches on several important areas of cognitive psychology and education. Let me address this systematically.
First, regarding knowledge transfer and metacognition: Knowledge transfer refers to the ability to apply knowledge, skills, or strategies learned in one context to new situations. It's closely related to metacognition - our ability to understand and monitor our own thought processes.
Research in this area has revealed several key findings:
David Perkins and Gavriel Salomon's work in the late 1980s and early 1990s identified two types of transfer:
A significant study by Brown, Collins, and Duguid (1989) in "Situated Cognition and the Culture of Learning" highlighted how knowledge often remains "inert" - students can pass tests but fail to apply knowledge in real-world contexts.
The phenomenon you're describing aligns with what cognitive scientists call the "transfer problem." Despite years of education, many individuals struggle to apply their learning in new contexts or integrate information across domains.
Some relevant research directions:
1. Cognitive Load Theory (Sweller et al.)
Shows how working memory limitations affect learning and transfer. Many students may never develop effective strategies for managing cognitive load, leading to poor comprehension of complex materials.
2. Reading Comprehension Studies
Work by Pressley and Afflerbach on "verbal protocols" revealed that skilled readers use multiple strategies simultaneously, while poor readers often lack these metacognitive tools.
3. Domain Integration Research
Studies by Susan Goldman and others have shown that even advanced students often fail to connect knowledge across domains, treating each subject as an isolated "silo."
Your observation about university graduates struggling with comprehension despite no apparent cognitive disabilities might be explained by several factors identified in research:
1. Surface-level Learning: Many educational systems reward memorization over deep understanding
2. Limited Strategy Instruction: Students often aren't explicitly taught comprehension strategies
3. Fragmented Knowledge: Information is typically taught in isolation without emphasis on connections
4. Weak Metacognitive Skills: Students may never develop the ability to monitor and regulate their own understanding
Some promising approaches to address these issues include:
1. Strategy Instruction Models
Teaching explicit strategies for comprehension, integration, and transfer. The Self-Regulated Strategy Development (SRSD) model has shown particular promise.
2. Knowledge Integration Frameworks
Approaches like Knowledge Integration Environment (KIE) help students connect ideas across domains.
3. Metacognitive Training Programs
Programs focusing on developing metacognitive awareness and self-regulation skills.
Since you asked about studies, I should note that while I've referenced several important works, you should verify these citations as I don't have direct access to current databases and could be misremembering details.
Would you be interested in exploring any particular aspect of this issue in more detail? For instance, we could delve deeper into specific instructional strategies that have shown promise in developing transfer abilities, or examine the relationship between metacognition and knowledge transfer more closely.
要件満たすため・社内政治的な理由でピンポイントで別のところ使う＋併用はあっても、
ゼロトラストセキュリティは、「信頼せず、常に検証する」という原則に基づいています。主な特徴として、常時の認証と承認、最小権限アクセス、アクセスの継続的な監視があります。以下の技術やソリューションを組み合わせることで、包括的なゼロトラストセキュリティモデルを構築できます。
1. Microsoft Entra ID（旧Azure AD）：
3. 多要素認証（MFA）：
1. 暗号化：
ブログやIT技術者向けSNS等は利用しておらず、はてブやTwitterでやるにはやや長いので、増田に投稿
Windows 10 (22H2 19045.4170) 上のEdgeを、数十のタブを開いたまま新バージョン (123.0.2420.53) に更新したらハングアップしたため、タスクマネージャーで強制終了させた
その後Edgeを起動させようとすると、更新時に閉じたセッションを復帰させる段階で強制終了するようになり、使用不能になった
Edgeに導入していた拡張機能には、Session Budy (4.0.2。GoogleのManifest V3に対応するため、最近大規模改修を実施(1。増田の最終節の同番号を参照。以下同)) やuBlock Origin (1.56.0。新規のマイフィルターを多数追加中だった) 等があった
「Edgeが起動しない」と直截な語句で検索していくつかの解説ページにたどり着いた
いくつかの解決策(2・3)を実行したところ、有効ではなかったが次の知見が得られた
数日程度では修復できないだろうと判断し、別のChromiumブラウザを使いつつ、片手間で修復方法を調べることにした
Windowsの設定画面等にあるリンクが有効になるよう、デフォルトのwebブラウザをEdgeから変更した
パスワードは別ツールで管理してたため無くてもそんなに困らなかったが、uBlockの設定とSession Budyで雑に保存してた閲覧履歴は必要だったので、Chrome拡張の復旧作業をした
"Default\Local Extension Settings"以下のフォルダと、念のために"Default\IndexedDB""Default\Local Storage\leveldb"の中身を移植(8)して作業完了
アイテムの履歴データ破損が問題の原因ではと考えてその修復や初期化方法を検索したが、これは徒労に終わった（ただし、このアプローチが完全に無効だとは言い切れない。参考ページ5は、復旧作業完了後に見つけた情報で、今回の問題に活用できずに終わった）
「コントロールパネル→システムとセキュリティ→セキュリティとメンテナンス→信頼性履歴の表示→問題レポートをすべて表示」で確認できた、Edgeの問題の要約やイベント名等で検索したところ、再インストールを勧めるページが数点引っかかった
既に何日も経ちWindowsの再インストールかユーザーアカウントの作り直しをしようかと考えかけていたが、もう少し努力してみることにした
Edgeを (アプリファイルを手動で削除したりするのではなく) なるべく安全にアンインストールすれば、正常に再インストールできるのではと考え、検索結果通り(11・12)に作業してみた
それでも「アプリ」のアンインストールメニューは無効なままで操作できなかったが、他に事例が無いか、"IntegratedServicesRegionPolicySet.json"等の関連語句で再検索した
コマンドラインでアンインストールを試みた事例(13)が見つかり、実行したらEdgeが削除された (ただし、コマンドプロンプトでもポップアップウィンドウでも実行結果の表示がされなかった)
そして参考ページ4のインストーラを実行し、念のために修復とOSの再起動をかけ、Edgeの起動を確認した
Microsoftアカウントにログインしていたため、パスワードは簡単に復旧できた
拡張機能は全て死んでいたが、仮に使っていたChromiumブラウザからコピペしたりエクスポートしたりして終了
利用していた拡張が少なかったので、プロファイルフォルダの内容の移植よりもその方が簡単だった
1. SESSION BUDDY V3 END OF LIFE | Google グループ
https://groups.google.com/g/sessionbuddy-discuss/c/HQPcLOq3-Ik
2. Microsoft Edgeが直ぐ閉じてしまう。 | Microsoft コミュニティ
https://answers.microsoft.com/ja-jp/microsoftedge/forum/all/microsoft/c414d2f9-b685-471c-8e78-2054c2e26c6c
3. ある日突然「Microsoft Edge」が開かなくなった、さあどうしましょう：山市良のうぃんどうず日記（224） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/2202/02/news009.html
https://www.microsoft.com/ja-jp/edge/download?form=MA13FJ
5. Windows10の「タスクバーにピン留めしているアプリ」の、「最近使ったもの」と「固定済み(いつも表示)」の設定ファイルとレジストリはここにある #Windows10 | Qiita
https://qiita.com/RyoIchimura/items/7e33980358f07e57a715
6. msconfig（システム構成）で解除してよいのは？使用場面と起動方法 | ドスパラ通販【公式】
https://www.dospara.co.jp/5info/cts_str_pc_msconfig.html
7. Windows Hello の概要とセットアップ | Microsoft サポート
https://support.microsoft.com/ja-jp/windows/windows-hello-%E3%81%AE%E6%A6%82%E8%A6%81%E3%81%A8%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97-dae28983-8242-bb2a-d3d1-87c9d265a5f0
8. chrome.storageの実体の場所 #Chrome | Qiita
https://qiita.com/k7a/items/cf644471d34d31f398e9
9. 第2回 グループ・ポリシーとは何か：グループ・ポリシーのしくみ（3/5 ページ） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/0602/23/news119_3.html
10. Microsoft Edge ブラウザー ポリシーに関するドキュメント | Microsoft Learn
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-policies
11. Windows 11/10からMicrosoft Edgeをアンインストールするシンプルな方法が見つかる | ソフトアンテナ
https://softantenna.com/blog/windows-11-10-uninstall-edge/
12. Releases · thebookisclosed/ViVe | GitHub
https://github.com/thebookisclosed/ViVe/releases
13. 各チャネルごとの Edge 削除状況 | 内気なもんた君
https://chat.openai.com/share/c80d83ea-752b-4561-a162-7ea0bd116d56
Option Explicit
Dim objExcel, objWorkbook, objWorksheet
Dim strFolderPath, strSourceFile, strTargetFile, strSearchString, strReplaceString
Dim intLastRow, intRow, intColumn
Set objExcel = CreateObject("Excel.Application")
strFolderPath = ".\" ' スクリプトと同じフォルダにあることを仮定
strSourceFile = "変更一覧.xlsx"
strTargetFile = "変更一覧.xlsx"
Set objWorkbook = objExcel.Workbooks.Open(strFolderPath & strSourceFile)
objWorkbook.Sheets("1月").Copy , objWorkbook.Sheets("1月").Index
objWorkbook.Sheets("1月 (2)").Name = "2月"
' セルの値の置換
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 1).Value = Replace(objWorksheet.Cells(1, 1).Value, "1月", "2月")
objWorksheet.Cells(2, 7).Value = Replace(objWorksheet.Cells(2, 7).Value, "2023/2/14", "2023/3/14")
' 最終行の取得
intLastRow = objWorksheet.Cells(objWorksheet.Rows.Count, 1).End(-4162).Row ' xlUp
' 値のクリア
For intRow = 8 To intLastRow
For intColumn = 1 To 6
objWorksheet.Cells(intRow, intColumn).ClearContents
Dim objFSO, objTextFile, strContents, arrLines, arrFields, strNewContents
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile(strFolderPath & "変更一覧.txt", 1)
strContents = objTextFile.ReadAll
objTextFile.Close
arrLines = Split(strContents, vbNewLine)
For Each strContents In arrLines
arrFields = Split(strContents, ",")
For Each strContents In arrFields
If IsNumeric(strContents) Then
strNewContents = strNewContents & "'" & strContents & ","
Else
strNewContents = strNewContents & strContents & ","
End If
strNewContents = Left(strNewContents, Len(strNewContents) - 1) & vbNewLine
' データをシートに貼り付け
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 8).Value = strNewContents
' セルの値の置換
objWorksheet.Cells(123, 1).Value = Replace(objWorksheet.Cells(123, 1).Value, "F", "FH")
objWorkbook.Save
objWorkbook.Close
objExcel.Quit
ごめんね。内部ストレージもいっぱいですってエラーがでるのでなんとかしてほしいといわれて、ストレージにある動画とか画像とか逃がしてるうちに
強制プリインストールされているキャリアアプリ系の謎のエラーメッセージに気づく。これはアレをすれば解決するか(・・?そうおもった。削除したいアプリ一覧とかいうのを 参考にして、ドコモ電話帳
DOCOMO Initialization
docomo Application Manager
dアカウント設定
dメニュー
my daiz
などを削除したら、泣かれた。電話もできなくなったっていわれた。ごめんなさい。なぜだろう(・・?けっこう騒がれてつらみしかない。今朝はあそこに立寄ってから出社したいから、お小言にずっと耐え忍ぶのか？