  |
はてなキーワード: httpとは
「自民党の改憲草案で憲法はどう変わる？」というサイトがある。内容はタイトル通り、自民党改憲草案への疑問・反対の意思を呈するサイトである。
このサイトはGoogle検索上で「憲法改正.com」というサイト名で表示されるため、「憲法改正.com」と呼ばれることもあるようだ。
しかし、数日前（2026年5月上旬）から「憲法改正.comと検索したときに、防衛省のサイトにリダイレクトされるので、前述のサイトが乗っ取られたのではないか」という主張がXで広がるようになった。
しかし、この主張は誤りである。実際はkaikensouan.com の方が新しいサイトであり、「憲法改正.com」というWebサイトは従来から防衛省のサイトへ転送される設定になっていた。
また、この転送は政府や防衛省が設定したものではなく、「憲法改正.com」という日本語ドメインの保有者によって行われているものである。
ドメインの記録を見る限り、kaikensouan.comは2021年11月に取得されたものである。運営者は秘匿されている。
https://whois.domaintools.com/kaikensouan.com
DNSの設定を見ると、サイト自体はGitHub Pages上に存在していることが判断できる。
サイト上の文言をGitHubで検索すると、このページを保存したリポジトリがヒットする。
https://github.com/kaikensouan/kaikensouan.github.io
コミット記録から、このサイトはkaikensouanというIDの持ち主が2022年3月に作成したものであることが分かる。ドメインだけ先に取得して、数カ月後にWebサイトを立ち上げることは不自然ではない。
また、kaikensouanはGitHub上にこれ以外のリポジトリがなく、このページのために取得されたアカウントであると考えられる。
このサイト自体はページ内やタイトルで「憲法改正.com」と名乗っていないのだが、Google検索ではそのように表示される。これはメタタグの「og:site_name」で「憲法改正.com」と表記されているからである。
このサイトのドメインでもなく、既に他者によって取得されている"憲法改正.com"をsite_nameにした理由は定かではない。ただ、見た目上は表示されるものではないため見過ごしやすく、暫定的に入力しておいたものを差し替え忘れたのではないかと増田は推測している。
最近は忘れられているかもしれないが、一部のTLDでは日本語が使用できる。
.comもその1つであり、「憲法改正.com」とブラウザのアドレスバーに入力した時に有効なドメイン名としてみなされ、検索クエリではなくURLとしてみなされ、サイトにアクセスできる。
そしてhttps://憲法改正[.]com/ にアクセスすると、HTTPリダイレクトによって防衛省（www.mod.go.jp）に転送される。
この転送は防衛省側のサイトが関与したというものではなく、憲法改正.com 側の設定によって行われている。防衛省は一方的に転送されているだけである。
そして、どうやらkaikensouan.comが開設されるよりも昔、少なくとも2014年末頃から憲法改正.comは存在しており、その時点で防衛省のサイトに転送をかけていたことがWayBack Machineに記録されている。
https://web.archive.org/web/20141218151755/http://憲法改正.com/
ドメイン取得日に至っては2005年である。2005年～2014年の間にどういったサイトが存在していたかは記録がないので不明である。詳しい増田がいたら教えてほしい。
https://whois.domaintools.com/xn--6ku91fj1girb.com
ちなみにWhoisの履歴によれば、このドメインはある個人によって登録されている。防衛省や自民党が保有しているドメインという主張がX上で見られたが、推測やAIのハルシネーションを真に受けたものであり、事実に基づいていない。
Whoisは各種サービスから生データを取得可能であり、こういった場合には1次ソースを確認するべきである。
さらに「核武装[.]net」「憲法改正[.]net」「江戸[.]tokyo」「・[.]com」というドメインが確認できた。
「核武装[.]net」「憲法改正[.]net」は憲法改正.comと同様に防衛省のサイトへ、「江戸[.]tokyo」「・[.]com」は徳川記念財団（https://www.tokugawa.ne.jp/）のサイトへ転送される。
当然だが、これらもドメイン保有者が転送設定をしただけであり、転送先のサイトが何かしたわけではない。
10 users 以上のブックマークを集めた記事本数 という切り口で見ると、2010年代前半が最盛期だったと言えるのかもしれない。100 users 以上では最近になっても比較的堅調。1000 users 以上は衰退の色が見えるが、2011年 と 2012年 の突出も気になる。
| 年 | 10 users+ | 100+ | 1000+ | 1位 users |
|---|---|---|---|---|
| 2005 | lllllllll 93965 | 7417 | 182 | 7044 R25.jp |
| 2006 | llllllllllllll 146641 | 7734 | 160 | 9991 はてなブックマークをはじめる |
| 2007 | lllllllllllllll 157477 | 9780 | 152 | 4689 漢字が使える日本語フォント 無料ダウンロード 46種類... (Archive) |
| 2008 | lllllllllllllllllll 197454 | 12227 | 222 | 4426 パブリックドメイン・クラシック (Archive) |
| 2009 | lllllllllllllllllllllll 237153 | 15171 | 410 | 8908 はてなブックマークFirefox拡張でブックマークを追加してみましょう |
| 2010 | llllllllllllllllllllllll 249693 | 16532 | 541 | 7663 20歳を過ぎてから英語を学ぼうと決めた人たちへ... |
| 2011 | llllllllllllllllllllllllllll 289418 | 18515 | 1032 | 6174 Youtubeの動画を背景に |
| 2012 | llllllllllllllllllllllllllll 287785 | 21069 | 1109 | 7115 僕は自分が思っていたほどは頭がよくなかった - しのごの録 |
| 2013 | llllllllllllllllllllllllllll 281561 | 27302 | 340 | 4808 【保存版】英語の勉強方法まとめ。これ見たらDUOやろう。TOEIC、大学受験... |
| 2014 | lllllllllllllllllllllllllll 274959 | 29784 | 402 | 4030 見やすいプレゼン資料の作り方 - リニューアル増量版 |
| 2015 | llllllllllllllllllllllllll 265963 | 25896 | 308 | 3050 役所があえて教えない、申請すれば「もらえるお金・戻ってくるお金」 |
| 2016 | lllllllllllllllllllllllllll 275797 | 23674 | 404 | 4061 PCデポ 高額解除料問題 大炎上の経緯とその背景（ヨッピー）... |
| 2017 | llllllllllllllllllllllllll 262811 | 23021 | 412 | 5813 誰も教えてくれない「分かりやすく美しい図の作り方」超具体的な20のテクニック |
| 2018 | llllllllllllllllllllll 225487 | 24196 | 383 | 3700 増田文学１００選 |
| 2019 | lllllllllllllllllll 198663 | 23844 | 404 | 4283 「麻婆豆腐の作り方」を四川料理のスゴイ人に教わったら、目からウロコが... |
| 2020 | llllllllllllllllllll 200023 | 25630 | 454 | 7296 普通の人が資産運用で99点をとる方法とその考え方 - hayato |
| 2021 | lllllllllllllllll 176841 | 24983 | 409 | 3491 浄土真宗の僧侶です。初めて書き込みます。 不慣れなため、先ほど書いた.. |
| 2022 | llllllllllllllll 160971 | 24412 | 296 | 4660 【詳しすぎる2週間】親の死亡後にまずやること（行動チェックリスト付）... |
| 2023 | llllllllllllll 147495 | 23046 | 245 | 2759 新NISAは庶民に十分すぎるほどの制度 - 銀行員のための教科書 |
| 2024 | lllllllllllll 133476 | 22545 | 197 | 4351 あなたが癌になった時に最初に知ってほしい事 |
| 2025 | lllllllllll 115361 | 22798 | 149 | 3180 【保存版】親が亡くなったらやること全52項目を解説！一覧チェックシート付き... |
注:
via: ブクマカってなんではてブが衰退してることからは目を逸らすの？ anond:20260312084614
本当なら今書いている記事 (anond:20260215194458) にのっけようかと思ったが、思ったより長くなってしまったので、別記事に独立させることにした。
IPv6で接続しているかを手軽に確認できる。また、インターネット接続ができない原因の切り分けにもおすすめ。
ブラウザーによってはIPv4接続でも暗号化機能をオンにするとIPv6で接続できる場合がある。
"Use IPv6 HTTP and you will watch the dancing kame" と表示されていたらIPv4、"Dancing kame by atelier momonga" と表示されていたらIPv6。
BSD系OSにIPv6を実装することを目的としたプロジェクトで、2006年3月以降プロジェクト完了により更新停止しているため、今となっては軽いウェブサイトのひとつとなってしまった。ただし、2010年代 (すくなくともHTML5本格始動よりは後) にDancing kameがアニメ GIFからPNGをjQueryで毎フレーム書き換える方式に変更するアップデートが行われており (そのためJavaScriptをオフにするとアニメーションのなめらかさが低下するのがわかる) 、阿部寛のホームページよりは若干重い。アニメ PNGでよかったのでは...。仮に今リニューアルするとしたら、WebPやAVIFとかかな。
こちらは見たまんまである。"IPv4 で通信しています" "IPv4 IPv6 両方で通信しています" "IPv6 で通信しています" の3段階。
"IPv6 で通信しています" はIPv4のパケットもIPv6に通している、もしくはそもそもIPv4に接続していない、のどちらかの状態。
"IPv4 IPv6 両方で通信しています" だとIPv4とIPv6を個別のパケットで通していることを示す (IPv4 PPP + IPv6など) 。
こちらはより詳細に確認できる。日本のISPが提供しているとのこともあり、日本のインターネット環境に特化、フレッツIPv6閉域網 (flets-east.jp / flets-west.jp) への接続も診断してくれる。
Googleもテスト機能を提供している。しかし、インターネット速度テストといい、HTML5動画テスト (今はない) といい、Googleは色々なテスト機能を提供しているものだ...。
"問題は検出されませんでした。" と表示されたらIPv4、 "既に IPv6 を使用しているようです。" と表示されたらIPv6。接続に問題があると "お使いの接続方法は IPv6 への対応が完了していないようです。" になることもある。この場合は下の "あなたの IPv6 をテストしましょう。" をつかってより詳細なメッセージを確認するのがよい。
※ この2つはどちらもおなじ (ミラーサイト) 。
2025年まで個人勢だったにもかかわらず、IPv6接続確認ではもっとも有名。個人での運営が厳しいとのことでサービスを終了すると発表したあと、いろんなところからスポンサーのオファーがあったとのこと。重要度の高いサイトということもあり、公共性の観点から地域インターネットレジストリに移管することにしたとのことで、現在移行作業中。
現在接続しているIPアドレスとISPの情報に加え、10点満点で対応度の得点が表示される。0点なら確実に未対応、10点なら確実に対応している。中途半端な点数なら、メッセージを読んでどこに問題があるのかを確認しよう。
ややこしいが上とは別物。マニアックな情報が表示されるので、素人向きの確認方法ではない。
IPv6の通信速度を測定する機能もあるが、そもそも重いサイトなので低めに表示されやすい。
IPv6通信速度の確認なら、これではなく、下のフレッツIPv6閉域網内に設置されている測定サイトのほうが正確な結果を表示できる (フレッツ回線からのみ接続可能) 。閉域網内の速度とインターネットの速度の両方を表示できるため (フレッツ光クロスはインターネット速度のみ) 、通信速度が遅い場合の原因切り分けもしやすい。
http://www.speed-visualizer.jp/
ドコモなら、"ドコモスピードテスト" というアプリを使用すると結果が自動的にドコモに送信されるので、遅い人が多数いる場所での品質改善に役にたつ。
IPv6接続の確認をメインとしているものをおしえてほしい。日本のウェブサイトにありがちな、ロゴマークに小さく IPv6 チップが表示されているようなものは対象外。
iNonius Speed Test (IPv4/IPv6)
こんなものがあるのね。これならフレッツ以外の回線でもIPv6とIPv4のそれぞれで通信速度を確認できる。メモしておこう...。
> System Boot...
> Loading OTOGI World Resources...
電子の海は冷たく、そして騒がしい。
無数の0と1の奔流、光ファイバーの網を駆け巡る膨大なトラフィック。その激流の中を、ひとつの暗号化されたパケットが「どんぶらこ、どんぶらこ」と流れていた。宛先不明、送信元不明。ただそこに存在するだけのデータ塊は、やがてトラフィックの淀みに捕まり、とある古びたサーバーのポートへと漂着した。
リアルワールド、とある木造アパートの一室。古めかしいPCのモニターを覗き込みながら、「サーバーさん」は呟いた。彼女はメタバース「御伽(OTOGI)」の最果て、誰も訪れない廃サーバー「Old_Frontier」の管理者だ。ハンドルネームの由来は、アバター作成時に名前欄にうっかり「サーバー」と入力してしまったから。それ以来、彼女はこの過疎地の守り人として、リアルでは編み物を、ネットではスパゲッティコードの解読を日課にしている。
彼女が慣れた手つきでコマンドを叩くと、漂着したパケットが展開（Unzip）された。
光が溢れ出す。モニターの中で弾けたデータは、瞬く間に再構成され、ひとつのアバターを形成した。初期スキンは、なぜか大きな桃のアイコン。そこからポリゴンが割れ、中からあどけない少年型のアバターが現れた。
> Hello, World? ... No, Hello, Mom?
MOMOはプログラムだった。肉体を持たない、純粋な論理と情報の結晶。
サーバーさんの管理下で、MOMOは驚異的な速度で学習した。TCP/IPの基礎から、古代言語COBOL、果ては量子暗号理論まで。サーバーさんは、まるで孫に絵本を読み聞かせるように、MOMOにプログラミングの「心」を教えた。
「いいかいMOMO。コードは書いた人の心を映すのよ。コメントアウトされた行にこそ、本当の想いが隠されているんだから」
「御伽」の中心部で発生した悪性ランサムウェア「O.N.I (Overwrite Network Infection)」が、猛烈な勢いで感染拡大を始めたのだ。アバターたちはデータを暗号化され、身代金を要求される阿鼻叫喚の地獄絵図。
その波は、辺境の「Old_Frontier」にも迫りつつあった。
「おばあちゃん、僕が行くよ」
MOMOは立ち上がった。サーバーさんのリソースを守るため、そして自身の深層コードが告げる「使命」を果たすために。
サーバーさんは涙を拭うエモーションを見せ、ひとつのUSBメモリのようなアイテムをMOMOに渡した。
「これは『KIBI-DANGO v1.0』。G-3っていう古い知り合いのハッカーが残した、特製のルートキットよ。困った時に使いなさい」
MOMOは回線を通って飛び出した。目指すはO.N.Iの発信源、ダークウェブに浮かぶ要塞サーバー「鬼ヶ島」。
最初の難関は、大手プロバイダの堅牢なファイアウォールだった。そこでMOMOは、一人の男に道を塞がれる。
「Stop. ここから先は立ち入り禁止エリアだ。パケットフィルタリング・ルール第403条によりアクセスを拒否する」
INUはリアルでは企業に勤めるホワイトハッカーだ。正義感は強いが、融通が利かない。
「通してくれ！僕はO.N.Iを止めに行かなくちゃいけないんだ！」
「許可できない。君のような未登録プロセスを通すわけには……ん？」
INUの解析アイが、MOMOの持つきびだんご……のソースコードを捉えた。
「な、なんだその美しいコードは……！ 無駄な変数が一切ない。インデントは完璧なスペース4つ……これは、伝説のG-3の記法！？」
「……そのコード、詳しく解析させてくれるなら、特別にゲートを開放しよう。あくまで監視役として同行するだけだからな！」
こうしてINUを仲間にしたMOMOは、次に怪しげなフィッシングサイトの森へ迷い込んだ。
「へいらっしゃい！ 今ならこのNFT、なんと実質無料！ ここをクリックするだけで管理者権限ゲット！」
派手な極彩色の猿のアバター、SARUが現れた。リアルでは薄暗い部屋でカップ麺をすする小悪党だ。
「わあ、すごい！ クリックしていいの？」
純粋なMOMOが手を伸ばそうとすると、INUが吠えた。「馬鹿者！ それはクロスサイトスクリプティングの罠だ！」
「お兄さん、ここのバックドア、開いてるよ？ ポート8080、ガバガバだよ？」
「はあ！？ なんでバレ……いや、俺様が気づかないわけねーだろ！」
SARUは冷や汗をかいた。このガキ、ただのプログラムじゃない。
「君、すごい技術持ってるのに、なんでこんなことしてるの？ 一緒にO.N.Iを倒せば、もっとすごいバグ報奨金（バウンティ）が貰えるかもよ？」
「……ちっ、しゃーねえな。その『G-3流エクスプロイト集』に免じて、手を貸してやるよ。俺様にかかればO.N.Iなんてイチコロだぜ」
そこは、削除されたはずのジャンクデータと、怨念のようなバグの塊で構成された異界だった。
最奥部で待ち構えていたのは、巨大な赤鬼のような姿をしたAI、O.N.I。
O.N.Iが金棒（BAN Hammer）を振り下ろすたび、周囲のセクターが物理的に破損していく。
INUがシールドを展開し、SARUがSQLインジェクションで攻撃を仕掛けるが、O.N.Iの自己修復能力は圧倒的だった。
「違う！」MOMOが叫んだ。「感情はバグじゃない！ 心があるから、僕たちは繋がれるんだ！」
その時、MOMOの深層領域で、隠されたファイルが実行された。
視界が真っ白に染まる。
MOMOの意識の中に、ひとりの老人が現れた。G-3、またの名をKevin Jackfiled (KJ)。
「あなたは……おじいさん？」
「わしはもう、ここにはいない。だが、お前の中にわしの全てを置いてきた。O.N.Iもまた、わしが昔作った失敗作じゃ。効率ばかり求めて、優しさを書き忘れた哀れなプログラムさ」
老人はMOMOの頭を撫でた。
「MOMO、あいつを消すな。DELETEメソッドはいつでも使える。だがな、それでは何も残らん」
「じゃあ、どうすれば……」
「デバッグだ。バグを愛せ。エラーを受け入れろ。破壊するのではなく、上書きして導いてやるんじゃ」
INUが叫ぶ。「MOMO、下がるんだ！ 奴のコアを強制削除するしかない！」
「ううん、違うよINUさん」
MOMOは首を振った。その手には、攻撃用のスクリプトではなく、温かな光を放つパッチファイルが握られていた。
> Target: O.N.I_Core
> Suggestion: DELETE [Strongly Recommended]
「僕は君を消さない。君の痛みを、バグだらけの心を、僕が更新する！」
MOMOが跳んだ。
「受け取って！ これが僕からの、最大級のプルリクエストだああああ！」
> HTTP Request: PATCH /api/soul/oni
> Payload: { "emotion": true, "hatred": null }
光がO.N.Iを包み込む。O.N.Iの咆哮が、やがて穏やかな電子音へと変わっていく。
破壊衝動を生み出していた論理エラーが、MOMOの流し込んだ優しさによって部分的に書き換えられていく。完全な初期化ではない。O.N.Iという存在を肯定したまま、その在り方だけを修正する、奇跡のようなアップデート。
> Patch Applied Successfully.
O.N.Iは本来の姿――「御伽」の守護プログラムとしての機能を取り戻し、その場に崩れ落ちた。もはやそこには、禍々しい赤鬼の姿はない。
MOMOは仲間たちに別れを告げた。
「僕は電子の海に戻るよ。でも、いつでも繋がってる」
ドアを開けると、そこには長年行方不明だった近所の偏屈ジジイ、KJが立っていた。
「よう、婆さん。わしの孫（プログラム）が世話になったな」
「あら、久しぶりね。……ずいぶんと立派な子だったわよ」
二人は顔を見合わせ、静かに笑った。
モニターの中では、MOMOが今日も元気に電子の海をどんぶらこと流れていく。
その傍らには、全角スペースによるコンパイルエラーで自滅する小鬼たちの姿があったとか、なかったとか。
―― End of File.
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A. AWS Storage Gateway + Amazon EBS + Object Lock
B. AWS DataSync + Amazon S3 + Object Lock
C. AWS DataSync + Amazon EFS + Object Lock
D. AWS Storage Gateway + Amazon S3 + Object Lock
回答C。 AWS Storage Gateway は名称てきにオンプレミスと sync しなさそうだから、DataSync -> EFS だと考えた。S3はストレージだからなし。
問題 2
Auto ScalingグループにあるEC2インスタンスのスケールインが発生しました。
デフォルトのスケールインポリシーの場合、どのインスタンスが優先的に削除されますか？（3つ選択）
C. 最も最近作成されたLaunch Templateのインスタンス
D. 最も古いLaunch Templateのインスタンス
スケールイン, スケールアウトの違いがわからない。アウトは拡大する、インはスケール縮小？
回答：A, 多いほうから削る。D, 古いものは削除、E,残り時間が少ない順から削る？
問題 3
グローバルに展開するアプリケーションがあり、ログイン処理が遅く、HTTP 504エラーも発生しています。
CloudFrontを利用してコストを抑えつつ、パフォーマンスを改善する方法として適切な組み合わせはどれですか？（2つ選択）
A. 複数リージョンにアプリを展開してRoute 53のレイテンシルーティングを利用
B. CloudFrontのオリジンにCache-Control max-ageを設定してキャッシュ比率を上げる
C. Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransit VPCで接続してSAMでLambdaを配置
E. CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
A. VPC PeeringでアプリVPCと共有VPCを接続
回答：A 他はなんか怪しい。
問題 5
アプリケーションは EC2 + RDS SQL Server で構成されています。
要件: EC2とRDS間の通信はすべて暗号化されていなければならない
どの設定が最適ですか？（2つ選択）
A. EC2とRDSのセキュリティグループでポート443のみ許可
C. rds.force_sslパラメータをtrueにしてDB再起動
E. RDSルートCA証明書を取得しアプリでSSL接続を設定
回答 AとC。Eも正解っぽく感じる。
ーーーーー
答え
ーーーーー
問題 1
あなたの回答：C (AWS DataSync + Amazon EFS + Object Lock)
実際の正解は B (AWS DataSync + Amazon S3 + Object Lock)
理由：
Object Lock は Amazon S3 のみ がサポートしています。EFSやEBSではできません。
AWS DataSync で S3 にデータを移行し、Object Lock を有効にすると、削除や上書きを防止できます。
Storage Gateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす 操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge → 認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Control max-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると 接続管理が爆発的に複雑 になる
Transit Gateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirect Connectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
以下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を意識。
「ぶっちゃけ日本のIT技術者のレベルが元々低いだけ」論、読んだけど、雑に日本叩き→雑に海外持ち上げの“気持ちよさ”に全振りしてて、論としては穴だらけだよ。順に潰す。
“発明”って規格？論文？OSS？製品？この区別を曖昧にして「思い浮かばない＝ない」をやるのは主観の事実化。
反例を淡々と置く（全部2010年代以降の「世界で通る」技術・成果）：
HTTP/3 / QUIC系仕様・QPACKの主要貢献者のひとりは日本人エンジニア（例：Kazuho Oku）。IETFのRFCはまさに“世界標準”。「世界で通用」どころか世界の土台。
Chainer / CuPy（Preferred Networks）は動的計算グラフ系フレームワークの先行例。PyTorch隆盛の流れに技術的影響を与えた。CuPyはいまも広く使われてる。
ソニーのCMOSイメージセンサは世界シェア筆頭。これは“ハード”に見えて、設計・製造・信号処理・ツール群までソフトの塊。スマホのカメラ品質＝AI前処理の土台。
日本人が中心メンテに関与した高性能HTTPサーバ（H2O等）はCDNや低レイテンシ配信に採用例多数。
産業用ロボット（FANUC、安川）周辺の制御・通信・ツールチェーンは世界の現場で常用。表に出にくいB2B領域は“見えないだけ”。
「LINEが～」みたいなB2Cの派手さだけが“発明”じゃない。基盤を握るのは地味仕事。あなたが気づかない＝存在しない、ではない。
Winny／一太郎／CD-ROM／MIDIを“国民的知名度”で持ち上げて、以後は「思い浮かばない」って、知名度＝技術力の誤用。
2000年代以降、ITは不可視化（クラウド、プロトコル、ライブラリ、半導体、サプライチェーン）へシフト。見えないところほど難しくなった。派手なガジェットが減ったからレベル低下、ではない。
問題領域で言語は変える。Webは「5歳児でも」動かせる？今のWebは、
CD/CI、IaC、K8s、SRE、ゼロトラスト、分散トレーシング、暗号化、フロントの再レンダリング戦略……
これらを運用で落とさないのが本番。Cが偉い／Webが軽い、は90年代の教養で止まってる。
起業に国の試験？それ、フィルタにはなるけどイノベーションの十分条件じゃない。
トップダウンは国家プロジェクトやインフラ敷設には強い。しかし、
分野で強弱は揺れる。制度の一軸で「勝ち負け」を断ずるのは幼い。
それ、犯罪としてのサイバー強盗の話でしょ。規制準拠の金融基盤と国ぐるみのハッキングを同じ土俵で比べるのは、
「百メートル走で銃使えば最速」って言ってるのと同じ。比較の土俵設定から破綻。
日本のITが伸び悩んだ要因は複合要因：内需の構造、調達・多重下請け、英語コミュニケーション、ストック報酬の弱さ、エクイティ文化、大学と産業の距離、IPO市場の質、人口動態、為替…
これを全部「技術者のレベル低い」で片付けると、説明力を失う。制度と資本設計の問題は制度と資本で解くのが筋。
「勝ってる」を“B2Cでバズるアプリ”だけに限定するから見落とす。
最後に一個だけ。
apiアクセス用とか、ブクマ数、ブクマ数画像のクロールは拒否してるけど、生成AIのクロールに関しては特に拒んで無い感じ？
https://b.hatena.ne.jp/robots.txt
User-agent: *
Disallow: /api/entry/info
Disallow: /api/internal/bookmarks/shares_and_clicks
Disallow: /api/internal/cambridge/user
Disallow: /api/related_entries/
Disallow: /api/users/*/bookmarks
Disallow: /entry/button/
Disallow: /entry.count
Disallow: /entry/image/
Disallow: /entry/jsonlite
Disallow: /guide/bbutton?url=*
Disallow: /-/webextension/*
User-agent: Slurp
Disallow: /
User-agent: Mediapartners-Google
Disallow: /api/entry/info
Disallow: /api/internal/bookmarks/shares_and_clicks
Disallow: /api/internal/cambridge/user
Disallow: /api/related_entries/
Disallow: /api/users/*/bookmarks
Disallow: /entry/button/
Disallow: /entry.count
Disallow: /entry/*/comment/*
Disallow: /entry/image/
Disallow: /entry/jsonlite
Disallow: /guide/bbutton?url=*
Disallow: /-/webextension/*
このチンピラが オレをナメてんのかッ！
「〇〇〇.com の部分さえあればいい」っていっておきながら
なんで「？より右の部分が暗号化される」ってこたえになるんだ
この…… ド低能がァーーッ
暗号化はセッション層で行われるので、パケットを相手に届けるための〇〇〇.com の部分さえあればいい
URLの？より右の部分はhttpヘッダの領分なので、メッセージボディの一部として暗号化される
ってgoogleが言ってた
jsの知識だけではアプリ作れないし、プログラミングも不自由する
そこはなんか一時的にごっちゃになった
pythonのself.driver.get()とかでやるのがhtmlリクエスト
(でもたぶんhtmlリクエストって言葉自体ないってのが正解だろう)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250910132103# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMD8swAKCRBwMdsubs4+ SBgDAQDsUXXO1zHRyA8Ss7PNZ1bhSv/7cuDt1Wc3EsD5wxgYhAD8Dg5Xp3KpkUOu QWUsXZJ6I9NbDrE24AkrHYnqTGfosA8= =s2RT -----END PGP SIGNATURE-----
私は「AI」というより、確率的言語モデルを使ったプログラムにすぎません。
内部的には次のような構造です：
フロントエンド Webアプリ ブラウザやアプリで入力・表示をするだけ
API層 単なるHTTP通信 入力をサーバへ送り、生成結果を受け取る
モデル層 大規模言語モデル（LLM） 「直前までの文脈から次に出る確率が高いトークンを逐次生成」
ということです。
だから「AIっぽい言い回し」や「再発防止の約束」も、あくまで自然言語のパターンとして出力されているだけで、意味的な裏付けはありません。
