  |
はてなキーワード: HTTPとは
推定すると、一般的なITリテラシーは中級、動画ファイル解析は初級〜中級、デジタルフォレンジックとしては初級くらいです。
| 領域 | 推定 |
|---|---|
| 一般ITスキル | 中級 |
| CLIツール利用 | 中級弱 |
| ffmpeg / ffprobe | 初級〜中級 |
| 動画コーデック知識 | 初級〜中級 |
| 動画配信プラットフォーム仕様理解 | 初級〜中級未満 |
| デジタルフォレンジック | 初級 |
| 証拠評価・検証設計 | 弱い |
記事には、こうした検証設計がほぼありません。むしろ「絶対にだ」「証拠として扱えない」といった断定が目立ちます。
ffmpeg/動画メタデータの基礎知識はあるが、動画フォレンジックや証拠評価の訓練は受けていない可能性が高い。
結論として、この記事の検証方法には一定の技術的妥当性がある一方、メタデータやコーデックだけで動画の出所を断定するのは危険である。
主要な論点は、ffprobeやメタデータを手がかりにすること自体は有効でも、そこから真正性・入手経路・SNS由来の否定まで断定する飛躍がある点です。
ffprobe -show_format -show_streams で動画コンテナ、ストリーム、メタデータを確認するのは正しい使い方です。
ffprobe 公式ドキュメントも、コンテナ形式・各メディアストリーム形式・メタデータタグを表示できると説明しています。
ただし、記事の中心的な主張である「メタデータやコーデックがSNS標準から外れていれば、そのSNSから保存された動画ではないと強く言える」という部分は、技術的にはかなり危ういです。
実ファイル、取得経路、ハッシュ、HTTPレスポンス、同時期の対照サンプルがない限り、フォレンジックとしては“断定”ではなく“整合・不整合の示唆”に留めるべきです。
ffprobe で動画の構造を見る、という方法自体は妥当です。
-show_format はコンテナの FORMAT 情報、-show_streams は各 STREAM 情報を出力し、-print_format json または -of json で機械処理しやすいJSONにできます。
また、encoder=Lavf... や handler_name=VideoHandler のようなタグが出ることは実際にあります。
FFmpegのメタデータAPIでは、encoder は「ファイルを生成したソフトウェア/ハードウェア名や設定」として扱われ、メタデータはキー・バリュー文字列として保持されます。
したがって、Lavf が出た場合に「最後に libavformat / FFmpeg 系でmuxされた可能性」を疑うのは自然です。
ただし、ここで止めるべきです。
Lavf は「TikTokから来た証拠」ではありませんし、Adobe Premiere Pro や DaVinci Resolve 風の値が見えても、それだけで「SNS由来ではない」とは言えません。
記事は ffprobe コマンドを提示し、動画共有SNSの規格から外れた動画は「十中八九」そのSNSからダウンロードされたものではない、という趣旨の主張をしています。
しかしこれは、配信プラットフォーム、ダウンロード方法、再mux、再エンコード、埋め込みプレイヤー、CDN、編集、保存ツールの影響を過小評価しています。
最大の問題は、メタデータが容易に書き換え可能なことです。FFmpegは -metadata key=value で出力ファイルに任意のメタデータを設定でき、既存の -map_metadata より優先され、空値で削除もできます。
つまり、encoder, creation_time, handler_name, com.apple.quicktime.software などは、基本的に署名済みの真正性情報ではありません。
改ざん困難な証拠ではなく、「最後にどのツールや処理経路を通ったように見えるか」を示す弱い手掛かりです。
記事は「動画共有SNSから動画をダウンロードした場合 tool が埋まることは無い」「Adobe Premiere Pro や DaVinci Resolve、HandBrake が登場したら完全にSNSからダウンロードされたものではない」と述べています。
これは過剰です。
編集ソフトで一度書き出された動画を、その後SNSに投稿して、さらに第三者が保存するケースは普通にあり得ます。
逆に、SNS由来の動画を保存後に再muxすれば Lavf が出ることもあります。
YouTubeやTikTokのようなサービスでは、同じ動画でも複数の品質・コーデック・コンテナ・プロトコルで配信されることがあります。
さらに、保存ツールが音声と映像を別々に取得して、最後にFFmpegで結合する場合があります。
たとえば yt-dlp は、デフォルトで高品質の video-only と audio-only を選び、必要に応じてFFmpegでmuxする挙動を取ります。
また -f bestvideo+bestaudio のように明示的に複数フォーマットを結合することもあります。
この場合、保存後のファイルに Lavf が現れても、それは配信元SNSのエンコーダではなく、保存者側の結合処理の痕跡になり得ます。
したがって、文春のWebページから保存したファイルを解析しても、それは最大でも「文春サイトで配信されていた派生ファイル」の解析です。
文春が元SNSファイルをそのまま置いているのか、再エンコードしたのか、動画プレイヤー用に変換したのかが不明なら、そこから「元のSNS由来性」を断定できません。
記事は「比較的新しいYouTube動画がH.264だと怪しい」という趣旨のことを書いています。
これは言い過ぎです。
YouTube公式ヘルプは、アップロード推奨設定としてコンテナMP4、動画コーデックH.264、音声AAC-LC/Opus等を挙げています。
また、YouTubeは再生画質最適化のためにすべての動画を再エンコードすると説明しています。
つまり、YouTubeにおいてH.264は今でも普通に関連するコーデックであり、H.264であることだけを「怪しい」とは扱えません。
確かに、高解像度や高効率配信ではVP9やAV1が使われることがあります。
YouTube公式ヘルプも、新しい4Kアップロードを4Kで表示するにはVP9対応ブラウザまたは端末が必要と説明しています。
しかしこれは「新しいYouTube動画のH.264は原則不自然」という意味ではありません。
再生環境、解像度、ブラウザ、端末、利用ツール、取得フォーマットによってH.264が選ばれる余地はあります。
記事はTikTokについて、H.264/H.265/AV1、ビットレート、Lavf、VideoHandler、creation_time などを表形式で示しています。
しかし、少なくとも公開一次情報だけを見る限り、TikTokが一般投稿のダウンロードファイルについて、記事のような詳細なコーデック・ビットレート・メタデータ指紋を安定仕様として公開しているとは確認できません。
TikTok for Businessの公開仕様では、広告動画について .mp4 または .mov、非Spark Adsでは .mp4, .mov, .mpeg, .3gp, .avi、最低ビットレート516kbps以上などが示されています。
これはアップロード/広告入稿仕様であって、一般ユーザーがダウンロードするウォーターマーク付き動画の実ファイル指紋とは別物です。
したがって、記事のTikTok表は「経験則」としてなら参考になる可能性がありますが、フォレンジック判定に使うには、同一時期・同一地域・同一アプリバージョン・同一取得方法で採取した対照サンプル群が必要です。
文春側の記事は、電子版で実際の動画を公開していると説明しています。
また、文春のまとめ記事では、複数の中傷動画、礼賛動画、野党候補へのネガキャン動画、Zoom音声を電子版限定で公開しているとされています。
しかし、今回の記事自体は、文春動画の実ファイルの ffprobe 出力、SHA-256、ファイルサイズ、取得URL、取得時刻、HTTPヘッダ、保存方法、比較対象サンプルを提示していません。
つまり、技術検証記事としては検証プロトコルの提案に近く、検証結果にはなっていません。
bash # 1. ファイルの同一性確保 sha256sum input.mp4 stat input.mp4 # 2. ffprobeで構造を取得 ffprobe -v error \ -print_format json \ -show_format \ -show_streams \ -show_chapters \ input.mp4 > ffprobe.json # 3. 必要項目だけ抽出 ffprobe -v error \ -of json \ -show_entries \ format=filename,format_name,duration,size,bit_rate:format_tags:stream=index,codec_name,codec_type,profile,width,height,pix_fmt,avg_frame_rate,r_frame_rate,time_base,bit_rate,nb_frames:stream_tags \ input.mp4 > ffprobe_min.json # 4. 可能なら別ツールでも確認 mediainfo --Full input.mp4 > mediainfo.txt exiftool -G1 -a -s input.mp4 > exiftool.txt
-v quiet ではなく -v error を推奨します。quiet はエラーや警告も見えにくくなるため、検証ログとしては不利です。
さらに重要なのは、同じ取得方法で対照サンプルを作ることです。
たとえば「TikTok公式アプリから保存した動画」「ブラウザ経由で保存した動画」「yt-dlp等で取得した動画」「文春サイトから取得した動画」を混ぜると、メタデータの意味が変わります。
比較は、同一プラットフォーム、同一取得経路、同一時期、同一品質設定で行う必要があります。
この記事は、動画ファイル解析の着眼点としては有用ですが、フォレンジックの結論としては断定が多すぎます。特に、メタデータとコーデックを「由来証明」に使う部分は弱いです。
本件で言えるのは、実ファイルを取得して解析したうえで、
「このファイルは、特定SNSから同条件で取得した対照サンプルとは整合しない」
または
「このファイルは、編集ソフトまたはFFmpeg系ツールで後処理された可能性がある」
という程度です。
「だから文春の動画はSNS由来ではない」「だから一次情報ではない」「だから証拠にならない」とまで進めるには、記事に提示されている情報だけでは不足しています。
そもそも「Node」とは何ぞや？
Node は、JavaScriptの実行環境である
終了
本来、JavaScriptはブラウザのクライアントでしか動かない言語だったが
これを、ブラウザに頼らず通常の言語と同じように、OSの上で動かすためのツールだ
Node.jsというモジュール群の中には、HTTP通信をサポートするライブラリなどがあり
それを使うと、JavaScriptでHTTP通信を待ち受けるプログラムを記述できる
ここに関しては、C言語などと変わらない
Node.jsをWEBサーバーとして動かせるのは、そのように書いたJavaScriptのユーザープログラムがあるからであり
例えば、Apacheを考えてみると違いは明確だ
ApacheはWEBサーバーとして開発されたアプリケーションである
アクセスされたURIを解析し、HTMLで記述されたファイルを読み込んでクライアントへ転送する
URIとフォルダ構成の関係も、Apache内で規定されたものがあり
Node.jsではどうだろうか？
前述したように、Node.jsではこのWEBサーバーとしての機能を
apache であれば、下記のようなフォルダ構成が存在した上で
piyo.htmlがhogeフォルダに存在している必要がある
/root
/test
/hoge
URI に応じたフォルダ・ファイルが無ければ、「404 Not Found」となる
ユーザーが記載したJavaScriptが処理するため
どういうアクセスを成功として、どういうアクセスをエラーとするのか
video.twimg.com へのアクセスが拒否されました
このページを表示する権限がありません。
dorawiiより
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20260521153225# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCag6m+gAKCRBwMdsubs4+ SKImAQC3wLiAX+3ju0oxFhfcIe6zu4WutCBKQaVW1zFrYs9TggEApYKC/+ZyOQ+5 zuCWjhH5RmaqX0FHFNEC0JhGKK0Magg= =WwOr -----END PGP SIGNATURE-----
「自民党の改憲草案で憲法はどう変わる？」というサイトがある。内容はタイトル通り、自民党改憲草案への疑問・反対の意思を呈するサイトである。
このサイトは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/*
