2026自己紹介ページを更新した

NISHIO Hirokazu [Translate]
2026自己紹介ページを更新した
old title: TODO:自己紹介ページを更新する

2026-01-20
自己紹介が最新なのだが、歴史が長いので検索などしたときに http://nhiro.org/ja.html がヒットしてしまう
いわゆるアカデミアの研究者でなくなってから英語圏向けの自己紹介を更新していなかったが、この3年間の活動が世界から興味を持たれるゾーンに入ってきている

2026-01-24
nhiro.orgの更新の仕方を忘れているw
古いScrapboxから発掘した
entrypointという名前のリポジトリがどこかにあるはず
bitbucketだな
いやちがうな
見つからないな
サーバからrsyncで取ってくる

自己紹介とDeep Researchして嘘を取り除いたものをベースにする

https://github.com/nishio/entrypoint を作った
今のバージョンをここに入れて保全する

rsyncでのデプロイをGitHub Actionsで実行する

まずGitHub Pagesでプレビュー
https://nishio.github.io/entrypoint/

2026-02-05
AIに星占いをさせる
>よくある失敗: きれいに整えてしまう→ 半年後に必ず違和感が出る
>今やるべき“正解ムーブ” ①「完成版」を作らない
>②「何者か」より「何を考えているか」
>③ 過去の自分を消さない
>星的アドバイス（超重要）
> 2026年夏以降 → 「名乗れる言葉」が自然に固まる
> 今は → 探索・下書き・公開思考の時期
> だから今の更新は「名刺」ではなく 「作業ログの入口」思ってください。

未踏ジュニアのことを書いてないなとは思った

2026-02-11
ひらめきが降りてきた
自己紹介と歴史は共通の構造を持つ

2026-02-17
全然捗ってない、出力を見るのはした

2026-03-27
ConnectingDotsシステム

2026-07-28
デジタル民主主義サミット2026で登壇者情報の登録でWebサイトを求められて、これのことを思い出した
Opus 5
nhiro.org と www.nishiohirokazu.org の DNS は両方とも 49.212.123.65（さくらのサーバ） を向いていて、そこには 2015年頃の古いページ（bio 141字版・2015年の顔写真・HTTPS なし）が置かれたままです。GitHub 側をいくら更新してもここには反映されません。
このマシンにはさくらサーバへの SSH 設定がなく、私からは旧サーバを更新できませんでした。
注意点：nhiro.org/langbook/（コーディングを支える技術の公式ページ）は旧サーバ上で現役稼働中です。安易に nhiro.org の DNS を GitHub Pages に切り替えるとこれが 404 になります。mem.nhiro.org は Vercel 向きの別レコードなので影響なし。
graspのおかげでどこから聞いても広範囲に情報を発見できる
書き込みした時にどこに書かれるのか不安だなぁ
private非公開の場に書くつもりで指示して公開の場に書かれる事故が起こりそう
今日中にClaude Codeのremote-controlで管理できる体制にしたい
スマホからWebサイトを見て、気になったところを「ここを直して」とメッセージするだけで直る仕組みにする
VPSから全部吸い出してGithubのprivate repo  nhiro-org-vps-backup にいれた
VPSを使い続けるか？GitHub Pagesに移行するか？
→GitHub Pagesにする
DNSを切り替える
GitHub Pagesのカスタムドメイン設定
今回のサーバメンテの知識をどう保管するのが良いか？
Google Analytics
>Universal Analytics の完全終了（確定的な死） — トラッカー ID UA-668701-7 の「UA-」プロパティは Universal Analytics のものですが、Google は 2023年7月1日に UA プロパティのデータ処理を全面停止しました
昔は自分の書いた記事にロシアのキリル語の記事からリンクが貼られてるのをrefererで発見したりして面白かったんだがいつの間にかそういうのがなくなったんだよな
referer が消える条件は「HTTPS → HTTP」 — ブラウザは HTTPS のページから HTTP のサイトへ遷移するとき referer を丸ごと送りません。今のライブ nhiro.org は HTTP のままなので、現状がまさに最悪ケースです（現代の web はほぼ HTTPS なので、ほぼ全流入で referer が空）。GitHub Pages + Enforce HTTPS に移行すると HTTPS → HTTPS になるので、むしろ referer は復活します。
ただし2020年頃から「ドメインまで」に制限 — ブラウザのデフォルトの Referrer-Policy が strict-origin-when-cross-origin になったため、クロスサイト遷移ではオリジンだけが送られ、どの記事からかのパスまでは分かりません。「HN から来た」「X から来た」「どこかの大学のドメインから来た」までは分かる、という粒度です。
とっくに死んでいたのは検索キーワード — 「どんな検索語で来たか」は Google が2011〜2013年頃に "not provided" 化して消えたもので、HTTPS 化の副作用というより Google の方針でした。今は Google Search Console に登録すれば検索クエリ別の表示・クリック数を別経路で見られます（/langbook/ がどんな検索語で読まれ続けているか、はここで分かります）。
ああ、なるほど — 「ロシアの誰かが自分のことを書いてくれた記事を読みに行く」楽しさですね。それは確かに referer のフルパスが届いていた時代の産物で、strict-origin-when-cricross-origin が標準になった今、referer 経由ではほぼ戻りません。「ru のどこかのドメインから来た」止まりで、記事には辿り着けない。
ただ、同じ楽しみを別経路で回収する手段は今のほうがむしろ充実しています：
Google Search Console の「リンク」レポート — これが一番近い代替です。Google のクロールデータから「あなたのサイトにリンクしている外部ページの実URL」が一覧で出ます。つまりロシア語ブログがリンク付きで紹介してくれれば、訪問者が一人も来なくても記事そのものが見つかります。referer と違って「読者が実際にクリックしたか」に依存しないので、発見率はむしろ referer 時代より高い。ドメイン所有権の確認だけ必要なので、DNS 切替のついでに TXT レコード1本で登録できます。
Ahrefs Webmaster Tools（無料枠） — Google より貪欲にクロールする商用バックリンクインデックスで、自サイト検証すれば無料で被リンク一覧が見られます。新規リンク検出の通知も出る。
URL での検索 — X や Bluesky は URL 文字列で検索できるので、nhiro.org で検索すると引用ポストが出ます。Hacker News は Algolia 検索（hn.algolia.com）で URL 検索。Google で "nhiro.org" -site:nhiro.org も素朴に有効です。
Webmention — IndieWeb 文化の現代的な仕組みで、「リンクしたら相手に通知を送る」プロトコル。<link rel="webmention"> を1行置いて webmention.io で受けるだけで、対応ブログから「あなたについて書きました」が能動的に届きます。対応しているのは個人ブログ文化圏（まさに「ロシア語の個人ブログ」的な書き手層と重なる）で、静的サイトに JS なしで足せるので質実剛健路線とも相性がいい。
そうなのか〜、Google Search Console に登録しよう
登録済みだった、使い方を理解していなかっただけw
登録済みですね、しかもドメインプロパティとして。認証作業は不要です。では本題の「ロシア語ブログ発掘」へは：左メニューを一番下までスクロールして「リンク」を開いてください。「外部リンク > 上位のリンク元サイト」がドメイン一覧、「上位のリンクされているページ」がどのコンテンツが言及されているかの一覧で、リンク元サイトをクリックすると個別記事のURLまで掘れます。14年分の蓄積が見えるはずなので、/langbook/ に貼られた読者ブログなどが出てくると思います。
貼ってくれたサマリーからいくつか読み取れることがあります：
インデックス済み 24,163 ページ — この規模は apex の nhiro.org ではなく、ほぼ確実に mem.nhiro.org（Scrapbox ミラー、約2.4万ページ）です。ドメインプロパティはサブドメインを含むので、あなたの検索プレゼンスの本体は実は mem 側にある、ということが分かります
HTTPS 235 / 非HTTPS 7 — Google のサンプル中、HTTP のページはたった7件。旧サーバで配信されている apex サイトは、検索世界ではもうほぼ存在していないに等しい状態です。逆に言えば、DNS を GitHub Pages に切り替えて HTTPS 化しても検索的に失うものはほぼなく、得るだけです
ウェブに関する主な指標が「データなし」 — 実訪問者が少なくて Chrome の実測データ（CrUX）が集まっていないため。異常ではありません
未登録 90,704 ページ — mem のクロール対象が大量にあって Google が取捨選択している状態。急ぎの問題ではないですが、DNS 切替後に apex の新ページ（broadlistening/ 等）を早く載せたいときは、上部の URL 検査バーに URL を入れて「インデックス登録をリクエスト」で個別に押し込めます
GitHub Pagesのenforce HTTPSと証明書の発行の関連で何か間違いがあったらしいが、何が間違いか僕が理解する間もなく修正された
nhiro.org が新サイト + HTTPS で全面復旧
https://nhiro.org/ — 全パス 200（トップ / ja.html / broadlistening/ / langbook/ 等の全アーカイブ）
HTTP → HTTPS 301、証明書発行済み、Enforce HTTPS 有効
nishio.github.io/entrypoint/ → nhiro.org へ 301 — 検索エンジンの評価が分散せず、正規 URL が nhiro.org に一本化されました
経緯：apex の A レコード切替は済んでいたが GitHub 側の cname 設定が空で、nhiro.org が 404 の宙吊り状態だった → docs/CNAME + API 設定で解消。HANDOFF.md にも反映して push 済み
2026-01-24にはVPSに対してrsyncでデプロイする経路を想定していたが、sshでOpus5にログインさせて中身を調査した結果、別にVPSである必要はないのでやめた方がいいよねということに。
(1行解説 by Opus) もう Web サイトを GitHub Pages（無料・HTTPS 自動・push で更新）へ完全移行したので、月額を払って EOL の脆弱な OS を自分で守り続ける VPS を動かす理由がなくなったから。
"ブロードリスニングのページには例の図を載せて"ってプロンプトで日本語版も英語版も適切に引用付きで例の図が載っている
https://nhiro.org/broadlistening/ja.html
https://nhiro.org/broadlistening/
必要な知識が全部LLM Wikiに載ってるので、雑な指示でWebサイトが更新できる