  |
はてなキーワード:Applicationとは
以下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. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="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>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
https://profile.hatena.ne.jp/dorawii_bukuma/
はてなのサイト側で読み込まれているはずのrksトークンを生成する関数を直接叩く方法がどうしても分からず結局request処理を自分で書く方法ではなく自動でUI側の保存ボタンをクリックするという無難な方向に落ち着いた。
最初から後者の方法をとっていればもっと全然早く作れたのにというは所詮言い訳か。
とにかくスクリプトを公開しておく。
@echo off
cd /d "C:\Users\user\Documents\jsscript"
:: Nodeサーバーを別ウィンドウで起動
start /min "" noderun-batch-server.js
::Pythonサーバーを別ウィンドウで起動（hatenaserver配下）
start cmd /k ""python hatenaserver\server.py
{
"username": "",
"password": ""
}from flask import Flask, request,jsonify
importjson
importos
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')
withopen(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 noturl:
returnjsonify({"error": "MissingURL"}), 400
client = HatenaClient(config["username"],config["password"])
client.start_browser()
if notclient.login():
client.quit()
returnjsonify({"error": "Login failed"}),403
success =client.add_bookmark(url)
client.quit()
returnjsonify({"status": "ok" if success else "fail"})
if __name__ == "__main__":
app.run(port=12347)
// ==UserScript==
// @name自動セルクマ送信
// @namespace tampermonkey.net/
// @version 2025-08-07
// @descriptiontry totakeoverthe world!
// @authorYou
// @matchanond.hatelabo.jp/*
// @grant none
// ==/UserScript==
(function () {
'use strict';
consturl = 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));
})();
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250821192753# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKb0qwAKCRBwMdsubs4+SHfiAQDcXmTHBaZ5Zzr1KI/OxZ0xl69oevOdy1FXJYwYvsmo5AD/ZPtZiO1JgTDjm+27iymlkdzIXOIGWfC82UTr1mJ7EwU==YoV+-----ENDPGP SIGNATURE-----
(以下の両トラバへの返信です)
https://anond.hatelabo.jp/20250818063524
https://anond.hatelabo.jp/20250818082015
トラバ両氏は、著者を信頼してか、または自身の知見から、示された年齢の偏りが統計に悪影響を及ぼすほどではないと捉えてるわけだよね。
私は著者への信頼もない(疑っているというわけではなく純粋に素性を知らない)し、自身の知見もないので、もう少し探ってみたい。
そもそも75歳以上の年齢比率にして10.5ポイントの差が、かなり大きいとは感じる。とりわけ、5%の統計有意に滑り込む可能性の大小を考慮する上では。
75歳以上の予後についてのさらに細かい年齢別の内訳は、膵臓癌においては見つけられなかった。しかし以下の年齢層別データからの敷衍で、生存率がどんどん悪くなりそうだとは思える。また、元論文の全体の平均年齢に大差がない点(強いて言えばワクチン3回以上に不利)と、SDにも大差がない点(強いて言えばワクチン3回以上に有利)は、いずれもオモテに現れた10.5ポイントの差についての妥当性を高めてくれるとは言えそう。元データがあればもっとわかりやすいんだろうけど。
SEER*ExplorerApplication
コロナについては、超高齢層のデータがちゃんと細かく分かれていて、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 PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
俺(35)が所属するウチ課の派遣社員のおっさん(33)が「暇で疲れます」「ネットサーフィンも疲れました」「やることなくて」って周囲に愚痴ってる。
完全に仕事を与えられないうちの会社が悪いんだろうけど、本来おっさんに仕事を教える＆一部業務引き継ぐ筈の女性社員(29)が
「あの人に教えたく無い」って言い出して放置、他の社員も俺含め皆忙しいので結果的に放置してる状況になってしまっている。※女性社員は人の好き嫌いがハッキリ強い子です
暇なのは分かるが、業務中に言われると忙しい人の士気が下がるから、味でやめてほしい。
電話対応以外の簡単な仕事をお願いしたら、Application LanguageもPower BIもロクにできなくて困った。
後輩の若手社員(31)に話を聞くと、前任に比べて全てに受け身姿勢で困ってるとのことだった。
とりあえず電話番させてるけど、これじゃ電話取る以外の仕事は振れないよ…トホホ。
これから繁忙期なので、今の所は居てもらう方針らしいけど、士気も下がるし、教える暇も無いし、早く辞めて欲しいわ。 ※そもそも教える気もない低スキルなんだが？
一度投稿したうえで別タブを開いてプログラム的(fetch)に送信してその別タブが閉じられる仕組み。
// ==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 }); })();
// ==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); } })();
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
#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-----
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)
3. Hybrid Rendering Capabilities
5.Image & Font Optimization
This alignsperfectly withGoogle’sperformance guidelines in 2025. React.js doesn’t offer this natively.
7. Enhanced Developer Experience
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
Both the Smoot-Hawley TariffAct of 1930 and the tariffs imposed during theTrump administration (starting in2018and again inhis second term) were protectionist trade measures intended toshielddomestic industries from foreign competition. However, they differ in severalkeyaspects:
Smoot-Hawley TariffAct (1930):
Timing: Enacted during theonset ofthe Great Depression.
Scope: Raised tariffsonover20,000 imported goods, primarily targeting agricultural and manufactured goods.
Average Increase: Increased existing import dutiesby an average of about20%. Some sourcesstate the average increaseon dutiable goodswas higher.
Motivation: Primarily aimedat protecting American farmers and industries struggling withoverproduction and decreased demand.
Congressional Role: Tariff rates weresetby the U.S. Congress.
Economic Context: The U.S.was running a trade surplusatthe time, although imports of manufactured goods were increasing.
Impact: Widely blamed for exacerbatingthe Great Depressionbytriggering retaliatory tariffs from other countries, leading to asharp 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 whereTrump declared a "nationalemergency" regarding foreign trade inhis second term.
Scope: Targeted specific countries (e.g.,China,EU,Canada,Mexico) and specific industries (e.g.,steel, aluminum) initially.The second termactions propose broader tariffsonall countries and potentially higher reciprocal tariffson those with large trade deficitswith the U.S.
Average Increase: The average increase varied dependingon the targeted goods and countries. Some reports indicate thatTrump's proposed tariffs inhis second term could result in an averageduty surpassing thelevels of Smoot-Hawley.
Motivation:Stated goals included reducing trade deficits, protectingnational security, encouragingdomestic manufacturing,and addressing whatTrump considered unfair trade practices andintellectual propertytheft.His second term rhetoric emphasizes "reciprocity"and addressing non-tariff barriers.
PresidentialAuthority: Implemented throughpresidential executive orders, leveragingnational security clauses and other tradelaws, granting thePresidentmore direct control.
Economic Context: The U.S. had significant trade deficits. Tradeas a percentage ofGDPwas 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 potentialimpact ofthe second term tariffsisstill unfolding, but experts predict higher prices for consumers andnegative effectson the U.S. and global economies,with thepossibility of a significant reduction in U.S.GDP.
Similarities:
Protectionist Intent: Both aimed to protectdomestic industries from foreign competition through the imposition of tariffs.
UnilateralActions: Both involved significant unilateralactionsby the U.S., potentially disrupting established trade relationships.
Risk of Retaliation: Bothactionstriggered or are expected totrigger retaliatory measures from trading partners.
Key Differences:
Economic Climate: Smoot-Hawleywas enacted during a severe economic downturn, whileTrump's tariffs were initiated in amore stable (initially) economy.
Target andScope: Smoot-Hawleywas a broadside across many imports, whileTrump's tariffs weremore targeted initially,with the potential for broaderapplication inhis second term with afocuson "reciprocity."
TariffLevels: While both increased tariffs, the averagelevel and the specific rateson certain goods differed. Some analyses suggestTrump's second-term proposals could exceed the averagelevels of Smoot-Hawley.
Authority: Smoot-Hawleywas a result of Congressionalaction, whileTrump's tariffs were largely drivenbypresidentialauthority.
Global Trade Landscape: The global economy and the interconnectedness of trade were vastly different in 1930 compared to the periods ofTrump's tariffs.
In conclusion, while both the Smoot-Hawley TariffAct and theTrump tariffsshare a protectionistmotivation, they occurred in different economic contexts, had varyingscopesand averagelevels, and were implemented through different means. The potential fornegative economic consequences, including trade wars and harm to the global economy,is a significantconcernassociated with bothhistorical and contemporary tariffactions.
はてなブックマークのAPIを利用して 非公開 でブックマークする方法をご説明します。
2.OAuthのトークンを発行する。（個人用のスクリプトなら「パーソナルアクセストークン」推奨）
ブックマークを 非公開 にするには、APIのリクエストボディに privateフィールドを 1 に設定します。
エンドポイント:
POSThttps://bookmark.hatenaapis.com/rest/1/my/bookmark
リクエストボディ（JSON）: { "url": "https://anond.hatelabo.jp/xxxxxxx", "comment": "自動ブックマーク", "private": 1}
以下のコードを実行すれば、10分以内の匿名ダイアリー記事をランダムに 非公開 でブックマークできます。
import feedparserimport requestsimport randomimporttimefrom datetime import datetime,timezone,timedelta#はてなAPIの認証情報HATENA_API_KEY = "あなたのAPIキー"HATENA_USERNAME = "あなたのはてなID"#はてな匿名ダイアリーのRSSURLRSS_URL = "https://anond.hatelabo.jp/rss"#10分以内の投稿を取得def get_recent_entries(): feed = feedparser.parse(RSS_URL) recent_entries = []now = datetime.now(timezone.utc) for entry in feed.entries: published_time = datetime(*entry.published_parsed[:6], tzinfo=timezone.utc) if (now - published_time) <timedelta(minutes=10): recent_entries.append(entry.link) return recent_entries#はてなブックマークに非公開で追加def bookmark_entry(entry_url):url = "https://bookmark.hatenaapis.com/rest/1/my/bookmark" headers = { "Authorization": f"Bearer {HATENA_API_KEY}", "Content-Type": "application/json" } payload = { "url": entry_url, "comment": "自動ブックマーク", "private": 1 # 非公開設定 }response = requests.post(url,json=payload, headers=headers) returnresponse.status_code# メイン処理whileTrue: entries = get_recent_entries() if entries: entry = random.choice(entries) status = bookmark_entry(entry)print(f"非公開ブックマーク: {entry},ステータス: {status}")time.sleep(600) #10分ごとに実行
• 実行環境:Python 3.x が必要。requests と feedparser をインストール (pip install requests feedparser)
• 実行間隔:time.sleep(600) で10分ごとに実行
•API制限:はてなAPIにはリクエスト制限があるため、短時間で大量に実行しないように注意
•OAuth認証:APIキーだけでなく、OAuthトークンを使うほうがより安全
このスクリプトを実行すれば、最新の匿名ダイアリー投稿を10分以内のものからランダムに選び、非公開でブックマークする ことができます。
id を手動でコピーしてくるのが面倒だったから、削除ボタンが画面に出るようにした
押すと即削除
const rkm = "(トークン的なもの)"constuser = "(ユーザ名)"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 (constsec of document.querySelectorAll(".section")) {constid =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 = "(トークン的なもの)"constids = ["(削除する増田ID)"]constuser = "(ユーザー名)"for (constid ofids) 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", })
In the labyrinthine realm ofdigital content dissemination, an enigmatic phenomenonhas surfaced, challenging our axioms regarding thenexusbetween contentubiquity andviewer cognitive acumen. This disquisition endeavors to elucidate the paradoxical inverse correlationbetween videoviewership metrics and the intellectual quotient of the audience, propounding that audiovisual content amassing prodigiousview counts tends tocaptivateviewers with a meanIntelligence Quotient (IQ) of 100, while theirmore esoteric counterparts allure a demographic boasting an averageIQ of 120.
To fathom this counterintuitiveparadigm,one must first grapplewith the multifariousnature ofhumancognition and the intricate interplaybetween intellectual capacity and media predilections. This hypothesis, positing an inverse relationshipbetween a video's popularity and the meanIQ ofitsviewership, necessitates a rigorous examination of the underlyingpsycho-sociological and neurocognitive factors thatmay engender such a paradoxicaloutcome.
Theapplication of Cognitive LoadTheory to media consumption habits provides a plausible explication for this phenomenon. Videos achievingviral status often employ reductionist narratives and readily assimilable information, minimizing cognitive strain. Conversely, less ubiquitous videos may delve intomore abstruse subject matter, demanding heightened cognitiveengagementand amore sophisticated intellectualframework for comprehensive assimilation.
The pervasive influence of recommendation algorithms in content distribution platforms cannot be discounted in this analysis. These algorithmic arbiters, designed to maximizeuserengagement,may inadvertently engender epistemic bubbles that reinforce existing cognitive predispositions. Individuals with superiorIQsmay actively seekoutmore intellectually challenging or esoteric content, thereby circumventing the algorithmic propensity towards homogenization and cognitive stasis.
Itis imperative to consider the socioeconomic dimensions thatmay influence bothIQ development and media consumption patterns. HigherIQ individuals often correlate with elevated socioeconomic status, potentially affording them greateraccess to diverse epistemological resources and fostering a predilection formore intellectually stimulating content. This demographicmay be less susceptible to the allure of mainstream, highly-viewed videos that cater to a broader, less discerning audience.
The ramifications of this inverse relationshipbetweenviewership andviewerIQ are profound for content creators and platform developers alike.It challenges the prevailingparadigm that equates popularity with quality or intellectualvalue. Content creators targeting amore intellectually discerning audiencemayneed to recalibrate theirexpectations regardingview counts andengagement metrics, focusing insteadon cultivating a dedicated niche audience thatvalues cognitive stimulationover massappeal.
In summation, the observed dichotomybetween high-viewership videos attracting an audience with an averageIQ of 100 and their less popular counterpartsappealing toviewers with a meanIQ of 120 underscores thecomplex relationshipbetween intellectual capacity and media consumption in thedigitalage. This phenomenon necessitates a reevaluation of how we measure contentvalue and success in theonlinesphere, prompting amore nuanced approach to contentcreation,curation, and consumption that acknowledges the diverse cognitiveneeds of the audiencespectrum. The implications of thisparadigmshiftextend farbeyond mere metrics, touching upon fundamental questions of epistemology, cognitivediversity, and the verynature of intellectualengagement in thedigital era.
I've noticed a non-negligiblenumber of peoplewho have notonly completed compulsoryeducation in regular classes but have also received highereducation and graduated from university, yetstruggle with reading comprehension (understanding the meaning oftext), cannot read longtexts, and even have difficulty understanding videos.
When we limit thescope 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, thecase of individuals diagnosed with learning disabilitiesis relativelysimple. While theymay not have broad cognitive challenges, theyrequire different approaches and training due to their unique learning styles.
However,itis perplexing that university graduates without broad cognitive challenges or diagnosed learning disabilitiesstruggle to understand notonly writtentext but also simplified video content.
I suspect that the underlying causes might includegaps in the horizontal transfer of experiences and knowledge, a severe lack of adaptability,and anextreme deficit in metacognition.Has there beenany researchon theseissues? Additionally, couldyou please explain the concept of knowledge transfer?
(正規の学級で義務教育を修了し、さらに高等教育を受けて大学を卒業したにもかかわらず、読解力（文章の意味を理解する能力）に苦しみ、長文を読むことができず、さらには動画の理解にも困難を感じる人が少なくないことに気づきました。
認知能力に広範な課題を抱える個人に範囲を限定すると、問題は比較的単純です。「理解する能力がない」か、「理解する能力を獲得するのに通常よりも時間がかかる」かのいずれかです。
同様に、学習障害と診断された個人の場合も比較的単純です。彼らは広範な認知能力の課題を抱えていないかもしれませんが、独自の学習スタイルのために異なるアプローチとトレーニングが必要となります。
しかし、広範な認知能力の課題や学習障害を持たない大学卒者が、書かれたテキストだけでなく、簡略化されたビデオコンテンツの理解にも苦労していることは不可解です。
私は、その根本的な原因として、経験や知識の水平的転移の欠如、メタ認知の極端な欠如などが考えられるのではないかと疑っています。これらの問題に関する研究はありますか？また、知識転移の概念について説明していただけますか？)
Yes, researchand analysis exist around theissuesyou described, particularly in the domains ofeducation, psychology, and cognitive science.Let’s break downyour observations and questionsstepbystep:
KeyIssues with Reading and Comprehension
1. Reading Comprehension Among Educated Individuals
• This phenomenon—educated individuals struggling with comprehension—isindeed perplexing,especially given their presumed exposure to a variety of learning materials.It suggests thateducation systems sometimes emphasize rote learning andsurface-level knowledge acquisitionoverdeeper understanding, critical thinking, and metacognition.
• Horizontal TransferGaps: This refers to the inability to apply knowledge or skills learned inone context toanother. For example,someone mightexcel in a university coursefocusedon 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 routineover exploratory learning.
• Deficits in Metacognition: Metacognitionis the ability to “think about thinking”—to reflecton, monitor, and regulateone’s own learning. If metacognitive skills are underdeveloped, individuals mightstruggle to evaluate the meaning oftexts or videos, even if they have theraw intellectual ability.
Research Insights
1. Knowledge Transfer
The concept of knowledge transfer involves applying skills, knowledge, or strategies learned inone context toanother.Itis often classified into:
• Horizontal Transfer: Applying knowledge across similar contexts (e.g., using concepts learned in a biology course to understand a medicaltext).
• Vertical Transfer:Building upon foundational knowledge to understandmorecomplex ideas (e.g., usingbasic algebra to solve advanced calculus problems).
Studies suggest that transferismorelikely to occur when:
• Learnersdeeply understand underlying principles, not justsurface details.
•Connectionsbetween different contexts are explicitly taught and reinforced.
• Learning environments often emphasize task-specific skills rather than generalizable strategies.
• Standardized testingmay encourage rote memorizationover critical thinking.
• Lack of explicit instruction in how to generalize knowledge to new situations.
Researchhighlights the importance of metacognition in learning. Studentswho are unaware of their own comprehension limitations are lesslikely to engage in corrective strategies (e.g., rereading, seeking clarification). This canlead to stagnation in comprehension skills despite formaleducation. Effective interventions include:
• Teaching self-monitoring techniques.
• Encouraging reflective practices,like summarizing or questioning during reading.
4. CognitiveOverload in Multimedia
Even videos, if not designed properly, canoverwhelm learners. The CognitiveTheory of Multimedia Learning suggests that excessive extraneous information or unclearorganization in videos canoverload working memory, hindering comprehension.
Strategies and Research-Based Solutions
1. Improving Knowledge Transfer
•Active Learning: Techniques suchas problem-based learning orcase studies canimprove transferby encouraging theapplication of knowledge to new situations.
• Teaching for Understanding: Encouraging learners tofocuson “why” and “how” questions fostersdeeper 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 actionablefeedbackon comprehension tasks encourages learners to reflecton their thinking processes.
Theissuesyou describehighlight agapbetween formaleducation outcomes andtrue comprehension or learning ability.Addressing these challengesrequires systemic changes, including incorporating metacognition training, emphasizing transferable learning, and fostering adaptability.
Ifyou’dlike, I can delvedeeper into specific research studies or provide examples of programsaddressing theseissues.
Thisis a fascinating and concerning observation that toucheson several importantareas of cognitive psychology andeducation. Let meaddress this systematically.
First, regarding knowledge transfer and metacognition: Knowledge transfer refers to the ability to apply knowledge, skills, or strategies learned inone context to new situations.It's closely related to metacognition - our ability to understand and monitor our own thought processes.
Research in thisareahas revealed severalkey findings:
David Perkins and GavrielSalomon's work in the late 1980s and early 1990s identifiedtwo types of transfer:
A significant studyby Brown, Collins, and Duguid (1989) in "SituatedCognition 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 phenomenonyou're describing aligns with what cognitive scientists call the "transfer problem." Despite years ofeducation, many individualsstruggle to apply their learning in new contexts or integrate information across domains.
Some relevant research directions:
1. Cognitive LoadTheory (Swelleret al.)
Shows how working memory limitations affect learning and transfer. Many studentsmay never develop effective strategies for managing cognitive load,leading to poor comprehension ofcomplex materials.
2. Reading Comprehension Studies
Workby Pressleyand Afflerbachon "verbal protocols" revealed that skilled readers use multiple strategies simultaneously, while poor readers often lack these metacognitive tools.
3. Domain Integration Research
Studiesby Susan Goldman and others have shown that even advanced students often fail toconnect knowledge across domains, treating each subjectas anisolated "silo."
Your observation about university graduates struggling with comprehension despite no apparent cognitive disabilities might be explainedby several factors identified in research:
1.Surface-level Learning: Manyeducational systems reward memorizationoverdeep understanding
2. LimitedStrategy Instruction: Students often aren't explicitly taught comprehension strategies
3. Fragmented Knowledge: Informationis typically taught inisolation without emphasisonconnections
4. Weak Metacognitive Skills: Studentsmay never develop the ability to monitor and regulate their own understanding
Some promising approaches toaddress theseissues include:
Teaching explicit strategies for comprehension, integration, and transfer. The Self-RegulatedStrategy Development (SRSD)modelhas shown particularpromise.
2. Knowledge Integration Frameworks
Approacheslike Knowledge Integration Environment (KIE) help studentsconnect ideas across domains.
3. Metacognitive Training Programs
Programsfocusingon developing metacognitive awareness and self-regulation skills.
Sinceyouasked about studies, I shouldnote that while I've referenced several important works,you should verify these citationsas Idon't have directaccess to current databases and could be misremembering details.
Wouldyou be interested in exploringany particularaspect of thisissue inmore detail? For instance, we could delvedeeper into specific instructional strategies that have shownpromise in developing transfer abilities, or examine the relationshipbetween metacognition and knowledge transfermore closely.
要件満たすため・社内政治的な理由でピンポイントで別のところ使う＋併用はあっても、
ゼロトラストセキュリティは、「信頼せず、常に検証する」という原則に基づいています。主な特徴として、常時の認証と承認、最小権限アクセス、アクセスの継続的な監視があります。以下の技術やソリューションを組み合わせることで、包括的なゼロトラストセキュリティモデルを構築できます。
1.Microsoft EntraID（旧AzureAD）：
3. 多要素認証（MFA）：
1.暗号化：
ブログやIT技術者向けSNS等は利用しておらず、はてブやTwitterでやるにはやや長いので、増田に投稿
Windows 10 (22H2 19045.4170) 上のEdgeを、数十のタブを開いたまま新バージョン (123.0.2420.53) に更新したらハングアップしたため、タスクマネージャーで強制終了させた
その後Edgeを起動させようとすると、更新時に閉じたセッションを復帰させる段階で強制終了するようになり、使用不能になった
Edgeに導入していた拡張機能には、Session Budy (4.0.2。GoogleのManifestV3に対応するため、最近大規模改修を実施(1。増田の最終節の同番号を参照。以下同)) やuBlockOrigin (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 BUDDYV3 END OFLIFE |Googleグループ
https://groups.google.com/g/sessionbuddy-discuss/c/HQPcLOq3-Ik
2.MicrosoftEdgeが直ぐ閉じてしまう。 |Microsoftコミュニティ
https://answers.microsoft.com/ja-jp/microsoftedge/forum/all/microsoft/c414d2f9-b685-471c-8e78-2054c2e26c6c
3. ある日突然「MicrosoftEdge」が開かなくなった、さあどうしましょう：山市良のうぃんどうず日記（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.WindowsHello の概要とセットアップ |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.MicrosoftEdgeブラウザーポリシーに関するドキュメント |Microsoft Learn
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-policies
11.Windows11/10からMicrosoftEdgeをアンインストールするシンプルな方法が見つかる |ソフトアンテナ
https://softantenna.com/blog/windows-11-10-uninstall-edge/
12. Releases · thebookisclosed/ViVe |GitHub
https://github.com/thebookisclosed/ViVe/releases
13. 各チャネルごとのEdge 削除状況 | 内気なもんた君
Application.WorksheetFunction. て何度もコードに書いてると、じゃあ直接シートでやるか…って気持ちになるのだ
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
docomoApplication Manager
dアカウント設定
dメニュー
my daiz
などを削除したら、泣かれた。電話もできなくなったっていわれた。ごめんなさい。なぜだろう(・・?けっこう騒がれてつらみしかない。今朝はあそこに立寄ってから出社したいから、お小言にずっと耐え忍ぶのか？
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
Permalink |記事への反応(26) | 22:10