  |
はてなキーワード: トラフィックとは
> 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は 静止データの暗号化 用で、通信の暗号化には関係なし
インターネット上の情報の99%は、情報の受け手の行動や感情、お金を操作することを目的としたもの、あるいは純粋なエンターテイメントとして消費されるものとして整理できます。
一方、1%は、スキル、知識、客観的事実の伝達に特化し、ユーザーの生活や能力を向上させるために役立つ情報と言えます。
ユーザーの視点から見ると、これらの情報は「役に立たない」というよりは、「誰か（情報発信者側）の利益を優先している」あるいは「単に時間を消費させる」性質を持っていると解釈できます。
1%のジャンルは、自己成長や客観的な理解に直結する、ノウハウやデータを主軸とした情報です。
この分類は、インターネット上で情報を探す際に、「誰かの利益のためのコンテンツ」と「自分の利益のための知識」を峻別するための視点を提供しています。
あなたの同僚が夜間の待機中に、プロジェクトの Virtual Private Cloud（VPC）に侵入する不審なトラフィックの増加に気づきました。そこで同僚は、特定の IP アドレスから発信されるトラフィックを停止するように、Cloud Armor の構成を更新しました。この変更によりネットワーク トラフィックは減少しましたが、影響を受けたお客様からエスカレーションがあり、その結果、会社にペナルティが課されました。チームは Google が推奨する方法に沿って再発を防止したいと考えています。どうすればよいですか。
1. 同僚向けにインシデント レポートを作成し、シニア マネジメントにエスカレーションする。
2. この同僚によるすべての変更について、第 2 レベルの確認を求めるプロセスを作成する。
あー、なるほどね。「JOINが難しくて避けてるだけなんじゃね？」ってわけか。
甘い。構造わかってない奴ほどそういう浅い自己放尿をしたがる。
まず前提を修正しろ。JOINの動きなんてとっくに分かってる。
SQLの実行プラン追って、Nested LoopかHash Joinか、インデックス使うのかフルスキャンになるのか、そのあたりの判断も含めて運用設計に組み込んでる。
こっちはわかった上で避けてんだよ。JOINを理解してないから避けてるんじゃない、JOINの実コストと限界を知ってるから回避してるの。
JOINってのは便利だけど代償がでかい。たとえば、数千万件のトラフィックログに対して、ユーザー属性をJOINするとしよう。
属性テーブルが1万件程度でも、JOIN時のI/OとCPU負荷は無視できない。結合条件次第ではインデックスも効かなくなる。クエリキャッシュも効かない、結合後にさらにGROUP BYやWHERE使えばオプティマイザの想定外の地雷も踏む。
こっちはそれを全部経験済み。痛みを知ってるから最適化してる。JOINの怖さを知らない素人が、理解できない設計を「逃げ」と断じるのは自己放尿だな。
それに「JOINがわかりづらい」なんて次元じゃない。JOINなんて構文としては簡単だろ？
問題はそれを巨大なスケールで運用したときのトラブルを想定してるかどうかだ。
JOINが原因で1時間かかるクエリになって死ぬとか、JOINが原因でMySQLのtemporary table溢れてswapに突っ込んでサーバ落ちるとか、JOINが原因でインデックスの設計ミスってテーブルスキャン発生して数億件走査するとか、そういうのを踏んでから語れ。
わかりやすくしとこうか？
JOINを盲信してるのは、「地雷原を地図だけ見て走り抜けようとしてる奴」と同じ。
JOINを避けてるのは、「地雷があるの知ってるから事前に地ならししてる奴」だよ。
「難しいから避けてる」んじゃない。
危険なの知ってるから、先回りして別ルートを構築してるだけだ。
何も知らないで「逃げてる」ってレッテル貼って自己放尿するの、やめとけ。
お前のJOIN観、浅すぎて逆に危ない。
グローバル単一台帳（Blockchain/DAG） 相互検証可能な“関係グラフ”
各ノードは「だれが・いつ・どうつながったか」という変化の射だけを署名し、トポロジ全体が履歴になる
オンチェーン状態 ≒ 直接資産 状態はローカル・資産は導関数
資産や契約は、関係グラフ上の経路依存量として再構成。スナップショットはクライアントが“可逆圧縮”で再計算可能
Proof of X (Work, Stake, etc.) Proof of Stewardship (PoS²)
「ネットワークが望ましい 複雑性 を維持するよう行動した度合い」をメタリック関数で動的スコア化し、報酬・ガバナンス権・帯域を同時に発行
要旨
もはや「台帳」すら保存しない。各エッジは STARK 圧縮された更新証明を持ち、グラフの梁（フレーム）自体が履歴になる。再構築は局所的に O(log N) で済むため、グローバル同期のボトルネックが消える。
2. プロトコル層
Fractal Mesh Transport (FMT)
自己類似ルーティング – トポロジ全体をフラクタルで自己複製。局所障害は“自己相似”パターンに吸収されるため、DDoS が形骸化。
アイデンティティ内包アドレス – DID を楕円曲線座標に埋め込み、パケット自体が署名・暗号化・ルーティングヒントを同封。IPv6 の後継としてレイヤ 3.5 に位置づけ。
HoloFabric Execution
ゼロ知識 WASM（zk-WASM） – 任意言語を WASM にコンパイル→ zk-STARK で実行トレースを証明 → “結果のみ”関係グラフへ。
コンパイラ内蔵 MEV 抑制 – 計算結果が他ノードから解釈不能になるタイムロック VDF を伴い、価値抽出を物理的に遅延。
Temporal Stream Storage
余剰ストレージの“時価”マーケット – ノードは自己の余剰 SSD/HDD を分単位オークション。データは Reed–Solomon＋重力波的ハッシュ空間で erasure coding。
リテンション ≒ 信用 – 長期ホスティング実績は PoS² スコアへ累積。攻撃的ノードは経済的に即時蒸発。
Liquid Fractal Governance
議決トピックを「周波数帯」にマッピングし、参加者は帯域を“委任スペクトル”として分配。結果はウォルラス圧力で収束し、マイナー意見も連続的に次回へ重みが残る。
（安全・分散・性能） 台帳の排除で“グローバル合意”自体を縮退 ⇒ スケール制約が幾何的に消失 安全：ZK 証明、
エネルギー消費 PoS² は「社会的有益度 × 熱消費効率」で算定。熱回収データセンターほど報酬が高い PoW よりオーダー数桁効率、PoS より社会関数を内包
プライバシー vs 透明性 グラフは公開。ただし各エッジは zk-STARK なので内容は非公開 / 関係のみ検証可能 トレーサビリティが“情報理論的に”限定される
MEV・フロントラン タイムロック VDF＋“ランダム束縛順序”で物理的に不可 ブロック順序依存問題を根絶
量子耐性 STARK 系 + 多変数格子ベース署名 Shor 破壊リスクを遮断
レガシー互換 Ethereum, Bitcoin, IPFS などへ 1:1 ブリッジを Rust/WASM で提供 既存資産を損なわず漸進的移行
Steward Credits (SC)：PoS² に比例し新規発行。帯域・ガバナンス票・ストレージ予約を等価交換。
Energy Reclaim Units (ERU)：余熱回収率に応じてクリーンエネルギー補助金と相互運用。
Knowledge Bounties (KB)：AI/LLM ノードが生成した有用モデル差分を関係グラフへコミット→検証トークンとして KB が発行。
負荷の自己調整
ネットワークが過度に混雑すると SC の新規発行レートが自動減衰し、トラフィック手数料が指数的に上昇。結果、スパムは短時間で経済的自殺となる。
Year 0–1：最小核 – zk-WASM VM + Fractal Mesh over QUIC。
Year 1–2：PoS² / ERU メトリクス実証、EVM 相互運用ブリッジ稼働。
Year 2–4：Liquid Fractal Governance によるプロトコル進化をコミュニティへ全面開放。
Year 5+：全世界 ISP ピアリング → 既存 Web の転送層を徐々に Web∞ 上へマイグレート。
国家単位のデジタル・ソブリンティを再構成：国境・法人格の境界を越え“関係”が一次元目となるため、規制枠組み自体が協調フィードバックモデルへ。
プライバシーと公共性の再両立：透明な“関係構造”上で非公開データを安全に扱う産業 API が標準化。医療・行政・金融の壁が大幅に低減。
インフラの脱炭素最適化：PoS² スコアに ERU が直結することで、再エネ比率が低いノードは自然淘汰。エネルギー政策と IT インフラが実質同一の経済圏に。
7. まとめ
Web∞ は「情報の状態」を残すのではなく「変化の証明」を残す。
その結果、台帳の重力・ガス代・フロントラン・量子不安・ガバナンス停滞といった Web3 固有の限界が、概念的に 初期条件から消滅 します。
エネルギー・プライバシー・スケーラビリティを同時に極小化／極大化するため、従来トレードオフと呼ばれた三角関係は “収束しない曲線” へと畳み込まれる――それが本構想の核心です。
もし実際にプロトタイプを設計するならば、zk-WASM ランタイム + Fractal Mesh を Rust で最初に書き起こし、PoS² の初期指標を「再生可能エネルギー電力比＋ノード稼働継続率」で暫定運用する、というのが現実的なスタートラインになるでしょう。
「Dead Internet Theory（死んだインターネット理論）」とは、インターネット上の多くのコンテンツが実は人間ではなく、AIやボットによって生成されているという説です
この理論は、インターネットが主に自動生成されたコンテンツとアルゴリズムによって操作されており、人間の自然な活動が最小限に抑えられていると主張しています
この理論の主な主張は以下の通りです
この理論の起源は明確ではありませんが、2021年に「IlluminatiPirate」というユーザーが掲示板に投稿した内容が広まり、注目を集めました
最近、はてな匿名ダイアリー（通称「増田」）において、AIが生成したと思われる記事が増えているとの指摘があります
例えば、「最近AIが書いたのか価値の無い記事が多いな」という投稿があり、これに対して「その『価値』ってどう判定してんの？」といった反応も見られます
このような状況は、Dead Internet Theoryの主張と一致する部分があり、インターネット上のコンテンツがAIによって生成されているという懸念を現実のものとして感じさせます
2023年のインターネットトラフィックの約49.6%が自動化されたボットによるものであり、これはAIモデルがウェブ上のコンテンツを収集するための活動が一因とされています
また、RedditやYouTubeなどのプラットフォームでも、AIによるコンテンツ生成やボットの活動が増加しており、これがユーザー体験や情報の信頼性に影響を与えているとの指摘があります
Dead Internet Theoryは、インターネット上のコンテンツがAIやボットによって支配されているという陰謀論的な説ですが、実際にAI生成コンテンツやボットの活動が増加しています
はてな匿名ダイアリーにおけるAI生成と思われる記事の増加も、この理論の一端を現実のものとして感じさせます
会社のインターネット回線がNTTPCコミュニケーションズという、NTTコミュニケーションズ（OCN）っぽいけど別のNTT系の会社の回線を使っているんだが、最近マジで回線がクソすぎてビビってる。
ビジネス向けインターネット接続サービスの半年間の障害情報を調べてみると、ほとんど毎月複数回通信遅延現象が起こっている。
これ、「通信遅延」とは言ってあるけど、「普段は100Mbps出るのが2〜3Mbpsまで低下する」とかじゃなくて、0.1Mbps未満まで低下するのでほとんど通信途絶と言って良いレベル。
Webページやシステムは遅いどころかタイムアウトしてアクセスできないことも多く、インターネットのサービスやシステムがほとんど使えない状態になる。
昨今は業務システムやツールのクラウド化が進んでいることもあり影響は甚大で、朝から1〜2時間に渡り文字通り仕事ができない状態になるので、支障が出まくり。
当然こんな状態では「朝一にWeb会議」なんてものはリスキーすぎて出来たもんじゃない。
週明けやWindows Updateの配信日にトラフィックが集中するのは分かるけど、こんなしょっちゅう輻輳するもんなのか？どこの会社も同じような状態？
これでいちいち障害情報を発表してるNTTPCコミュニケーションズがむしろ律儀だったりすんの？
というか以前は「ほとんど毎日始業時間前後30分はネットが遅くなる」レベルの回線だったので、少し前に帯域保証型だか帯域確保型だかのプランに変更したって話で、それで毎日の通信遅延は解消したんだけど、それでも障害情報として発表される通信遅延の影響はもろに受けてる。帯域保証型のプランにして「通信集中したから遅くなります」って、意味なくないか？？？
そもそもこの会社、2021年にビジネス向けインターネット接続サービスで「約1週間インターネット接続が利用できなくなる」という大規模障害起こしてんだよな。
https://support.nttpc.co.jp/csm?id=service_status_detail&outageid=e0b38a5c1bb1bc50c4d47774cc4bcb54
https://support.nttpc.co.jp/csm?id=service_status_detail&outageid=8c9b0b781bf97090c4d47774cc4bcbf7
それで設備強化とかをしたらしいんだけど、、
https://www.nttpc.co.jp/topics/important/pdf/202207_mone_utm_nttpc.pdf
今の時代、ビジネス向けのネット回線で1週間もネット使えないとかヤバすぎでしょ。
仮に一月の回線料が全額返金されたとしても数十万とかせいぜい数百万とかで、発生した損失とは釣り合っていないだろう。
2011年にもパブリッククラウドサービスで大規模障害起こしてるし、「NTTだから安心」とかいうレベルじゃ全く無いねこれ。
https://www.publickey1.jp/blog/11/nttpc.html
追記：この記事を書いた翌日にまた朝から1時間の通信ほぼ途絶現象が発生。マジでクソすぎる。
そして3月25日からVPNサービスで大規模障害発生中、3月27日現在で完全復旧していない。
https://support.nttpc.co.jp/csm?id=service_status_detail&outageid=32ae06e093a02610934ab0a97bba10b9
ここ数年、インターネットに散在するコミュニティ上での異常事象の存在が、SCP財団内でしばしば議題に上るようになってきた。匿名性の高いSNSやコメント欄、掲示板はもちろんのこと、とりわけ「はてな匿名ダイアリー」（以下「増田」と呼称）においては、他のプラットフォームでは見られない特異なアノマリーが複数確認されている。増田は、ユーザー登録をせずとも誰でも簡単に匿名の文章を投稿できる点や、その内容が検索エンジンを介して幅広く閲覧されるという特徴を持つ。その結果、財団の観測網をかいくぐって潜伏しやすい土壌が形成されており、過去数年間で複数のSCPオブジェクトが確認されるに至った。
本報告書では、増田上に跋扈するSCPについての調査概要と確認された事例、ならびに暫定的な収容手順を示す。なお、本報告書に示されるSCP事例は現在進行形で調査が行われており、記載内容はあくまで暫定的なものであることに留意されたい。
1. 背景と問題の経緯
はてな匿名ダイアリーは日本国内を中心としたWebサービス「はてな」が提供するブログプラットフォームの一部で、アカウントを持たない投稿者であっても「増田」と呼ばれる匿名枠にテキストを投稿できる仕組みを提供している。そこでは個人的な悩みや告白、社会への批判や仕事・日常の愚痴まで、多種多様な文章が毎日大量に投稿されている。
増田特有の気軽さや匿名性の高さは、投稿者の真意を推測しにくくする要因であり、その投稿を閲覧する読者側もまた「増田だから真偽がわからない」といった曖昧な認識のもと、批判や同情、考察などを寄せる。その混沌とした言説空間は、ときに不特定多数のユーザーの集合的な感情を刺激し、新たな炎上や論争を生み出す源泉ともなる。
こうした特質はSCP財団から見ると、アノマリー（異常存在）が自己の活動や影響力を隠蔽したまま周囲に感染・拡散するのに非常に都合がよい環境といえる。特に増田では、投稿時に明確なユーザーIDやアカウント情報が残らず、内容の信憑性を裏付ける手段が事実上ないため、「書かれていることが虚実入り混じっている」前提で閲覧されやすい。結果として、何らかのアノマリーが潜入していても発見が遅れがちである。
財団が増田における最初の異常を検知したのは、20██年頃に投稿された「この世を正しく終わらせる方法と手順」と題された増田が発端だった。その増田の内容はいわゆる「終末論」を扱うものであり、極めて支離滅裂かつ狂信的な文体ではあったが、読了した閲覧者の中から数名が突発性の精神不調や共時性の幻視を訴えはじめ、その症状が財団の監視ネットワークに引っかかったのである。その後、財団の調査チームが投稿の書式や文体を解析したところ、当該増田の背後に未確認のミーム汚染因子が潜んでいる可能性が高いと判断された。この事例をきっかけとして、財団は増田の投稿ログを精査し、複数のアノマリーを検出していくこととなった。
以下、財団が確認し、暫定的なオブジェクト分類（Safe/Euclid/Keter 等）を行ったSCPを紹介する。なお、詳細な文書は別途SCPファイルとして管理されているが、本報告書では概要と特徴を簡潔に示す。
概要：増田の特定記事上でコメント欄が自動的に増殖し続け、システム上の最大コメント数を無視して延々と付与され続ける現象。ユーザーが投稿したはずのコメントが複数回重複表示されたり、「名無しのオブザーバー」というハンドルネームでシステムが自動生成したとみられるコメントが絶え間なく追加されたりする。最終的に記事本体よりもコメント欄が何十倍も長くなり、閲覧者がページを読み込むだけでブラウザや端末に極端な負荷をかける。
異常性：コメント数が増え続けるだけでなく、中には本文を改変するようなスクリプトが混入しており、ページをリロードするたびに本文の一部が改変・増殖する事例が報告されている。閲覧者が長時間そのページを開いたまま放置すると、ブラウザ履歴やクッキー情報を勝手に書き換える痕跡が確認されている。
暫定収容手順：財団エージェントがはてな側のシステム管理者に接触し、問題の増田を管理者権限で凍結。また、既に拡散したミラーサイトやアーカイブを順次削除し続けているが、完全な根絶には至っていない。現状、定期的にウェブクローラーを走らせ、類似現象の発生を監視・排除する措置を取っている。
概要：一見するとありふれた日常報告や匿名の愚痴を綴った文章なのだが、記事本文を最後まで読了した閲覧者の脳内に「その人物が最も不安に感じている秘密」や「他人に言えない後ろ暗い過去」を強制的に想起させ、それを吐き出させる形でコメント欄へ投稿させる現象。コメント欄の体裁を取りつつ、実際には閲覧者自身が投稿した認識のない状態で、勝手に恥部をさらすようなコメントが掲載される場合もある。
異常性：このSCPの投稿は複数回確認されているが、書式やタイトルは毎回異なる。共通するのは「冗長かつ最後まで読まないと内容がよくわからない文体」であることと、本文の終盤に読者の潜在意識を刺激する特殊な文章構造が組み込まれている点だ。財団心理学部門の解析では、いわゆる「ミーム改変文字列」が散りばめられており、読み進める中で読者の深層心理に干渉していると推測される。
被害と対処：実際に被害に遭った閲覧者は投稿後しばらくしてから自身のコメント内容に気づき、極度の羞恥や恐慌状態を引き起こす。財団は可能な限り対象投稿を速やかに削除し、被害者のコメント記録を抹消すると同時に、クラスA記憶処理を施して事態の収拾を図っている。問題は、このSCPが投稿される「増田」のアカウント特定が極めて困難な点であり、繰り返し新規IDから投稿が行われていると推定される。新たな投稿が発生次第、いかに早期に検知し削除・封鎖するかが大きな課題となっている。
概要：ある増田上で連続的に展開される「複数の登場人物が互いに呼応しあう」形のスレッドが、実際には単一の存在（SCP-増田-C本体）の手によって形成されているとされる現象。日記本文とコメント欄があたかも多数の異なるユーザーによる対話のように見えるが、財団のIP解析ではすべて同一の不明ホストから投稿されたトラフィックであることが確認されている。
異常性：単なる自作自演ではなく、スレッド内で展開される複数の人格が、投稿のたびに微妙に文体を変化させるだけでなく、実在の第三者のようにリアルタイムで会話を重ねていく。そのやりとりは短時間で数百件以上に膨れ上がり、外部から見ると非常に説得力をもって「議論」が進行しているように映る。読者はそれぞれの人格が持つバックグラウンドストーリーに引き込まれ、スレッドを精読するうちに「どの意見が正しいか」を探り始めるが、最終的には一種の混乱状態に陥り、どの人物が何を意図しているのか判別不能になる。
被害：このスレッドに長時間深く没入した閲覧者は、自分の中に複数の人格が芽生えるような感覚を訴えたり、現実社会で他者と会話する際に「この人は実在しているのか疑わしい」という妄想を抱くようになるケースが報告されている。財団職員の複数名も監視過程で同様の症状を呈し、軽度の精神崩壊を起こした事例があるため、当該増田の監視担当者には定期的な心理カウンセリングが義務づけられている。
暫定対策：疑わしい長文対話形式の増田を早期に検知し、アクセス制限をかける監視システムを導入しているが、アルゴリズムの網をかいくぐる巧妙な投稿が頻発している。加えて、外部のまとめサイトに引用やスクリーンショットが保存されることで事後封じ込めが難航している。
概要：一度投稿された増田が、投稿時刻自体を過去に改変して再掲載される現象。通常、はてな匿名ダイアリーのシステムでは投稿日時を随意に改変することは不可能とされているが、このSCPは投稿履歴を操作して「数年前に投稿された」という形でエントリーを復活させる。
異常性：改変された記事は実在する日付の増田ログに紛れ込む形となり、当時の利用者のコメントやブックマークまで再現されている場合がある。過去ログを遡っていくと、該当記事がもともと存在した痕跡こそないものの、「当時その記事を読んだ」という証言を行うユーザーが現れるなど、現実改変の兆候も疑われる。現状の技術では投稿者の特定に至っておらず、どのようなプロセスで投稿日時を操作しているかは不明である。
注意点：時間改変系のSCPはカテゴリーとして非常に扱いが難しく、無闇な干渉は時間線に予期せぬ影響を及ぼす恐れがある。財団タイムアノマリー対策部門と連携しながら、記事そのものは閲覧制限下に置き、ネットアーカイブやウェブキャッシュの検索を遮断するなどの措置を行っている。
これらSCPが増田上で確認された背景には、以下の要因が考えられる。
増田はアカウント登録不要で誰でも書き込みが可能であるため、投稿者を特定したり、過去の投稿傾向から異常を推定したりする難易度が高い。その結果、アノマリーの一次検知が遅れる傾向が強い。
はてな匿名ダイアリーは、投稿された増田が多くのユーザーに瞬時に閲覧・ブックマークされる仕組みを持つ。また、はてなブックマークを介してさらにコメントや引用が拡散されるため、いったん話題が盛り上がると多方面にコピーや引用が散逸しやすい。
読者や閲覧者の「ネタ」への寛容さ
増田の読者は内容が真実か否かをあまり厳密に問わず、エンターテインメントやストレス発散目的でアクセスしている者が少なくない。結果、多少異常な文章であっても「一風変わった怪文書」「ただの創作」として受け流されやすく、深刻な異常だと気づかれにくい。
こうした要因によって、SCPを含む異常投稿は容易に潜伏し、拡散する。財団としては、はてな運営会社との連携を強化し、AIを用いた自然言語解析による異常兆候の検知システムを導入するなど、対策を進めている。しかし、はてな匿名ダイアリーは日々膨大な数の投稿が行われるため、どこまで網を広げられるかは未知数である。また、海外ホスティングによるミラーサイトや転載が出現し始めると、現実的な削除要請の範囲を超えてしまう。すでにTwitterや他のSNSでもまとめが回ることで、被影響者が増加する事態は避けられない。
はてな匿名ダイアリーにおけるSCP存在は、ネットコミュニティの構造変化に応じて今後も増加する可能性が高い。特に「自らがアノマリーであると自覚していないままネット上で活動している存在」や、「人格を装いながら多人数の読者とインタラクションを行うことで自己増殖するミーム型SCP」は、増田のような自由投稿プラットフォームでさらに悪質化・複雑化する恐れがある。
財団が最も警戒すべきは、増田を起点としてリアル社会へ飛び火するタイプのアノマリーの拡散だ。たとえば、本報告書で例示したSCP-増田-Bのように読者個人の深層心理に入り込み、現実での行動や社会的信用を毀損する現象が拡大すれば、大規模なパニックや社会秩序の混乱を招きかねない。あるいは、SCP-増田-Dのように時間改変的な特性を持つアノマリーがさらなる発展を遂げれば、歴史修正や因果律破壊といったレベルの被害もありうる。
また、はてな匿名ダイアリーは日本国内だけでなく海外からも閲覧・投稿が可能であり、英訳や翻訳を介して国際的に広まる余地がある。財団の各支部やデータ分析班が協調して監視を強化し、各国の法規制とも連携して削除要請を進める必要があるものの、現実には各国プライバシー法や表現の自由との兼ね合いで対応が難航することが予想される。
5. 結論
はてな匿名ダイアリー（増田）は、日常の雑感や炎上ネタから深刻な告白や感情の吐露まで、あらゆる情報が密集する場である。その匿名性ゆえに、SCPオブジェクトが潜伏しやすく、また多くのユーザーが「真偽のほどはわからないがとりあえず読む」態度で消費することから、アノマリーの拡散リスクは高いと言わざるを得ない。すでにSCP財団が確認しただけでも、いくつものSCPが増田に棲みついていることが判明している。
ただし、全投稿を強制的に削除・監視するような強硬策をとれば、はてなプラットフォームの存続意義自体を揺るがすと同時に、財団の存在が表面化するリスクも高まる。一方で、アノマリー拡散を放置すれば、ネット空間を通じてリアル社会にも致命的な影響を及ぼす恐れがある。財団はこのバランスの狭間で慎重な対応を求められている。
今後の具体的な方策としては、増田への新規投稿を常時チェックするAI分析モジュールのさらなる精度向上や、異常記事をいち早く発見し隔離するための専用クローラの整備が必須とされる。また、読者側への啓発活動――「増田を閲覧する際には、妙に長文で意味不明な投稿には注意すること」「不可解な体験があれば速やかに共有し、アクセスを控えること」など――の実施も有効である。しかし、匿名の特性ゆえに抜本的解決策は見通せていない。
財団としては、はてな運営との連携強化を引き続き図り、相互に対策技術をアップデートし合う形でアノマリーの早期封じ込めを目指す。SCP財団が確認した増田におけるSCP事例は氷山の一角に過ぎず、さらなる Permalink | 記事への反応(2) | 15:12
あれはNTTのうんこ通信網をどうにかすると言うだけの技術で、ほとんど意味ないからだよ。
NTTは光だけでスイッチングするから低遅延で高速だと言うだろ？
でもそんなことをせずに実現しているところがある。
NTTなどのオールド通信会社のネットワークは、電話の通信網を基本にしているから、細かい基地局と基地局の間を回線でつなぐという構造をしている。
そのため、IP通信になった今でも、その通信網を一つ一つパケットがルーティングされて流れていくと言う構造になっている。
だから、低遅延にするならオールフォトニクスにして光のままでルーティングする必要がある。
けど、それって昔ながらの古いネットワークだから必要なだけだって、もっとシンプルなネットワークだったらいらないよね？
巨大なデータセンター間を専用の光回線でつなぐと言う商売をやっている専門の通信会社は、そんな面倒くさいネットワークではなく、シンプルに両端にのみ光電変換をする装置を配置する構造にすることによって、IOWNとか言わんでも高性能低遅延低消費電力のネットワークを構築しているわけです。だから、本質的にAPNでございだとか、マルチオーケストレータでございますとか言わなくても、いらないんですよねそんなの。
データセンターの中の通信技術なら既にIOWNより優れたものがある。
インターネットのトラフィックは平等にルーティングされているのではなく非常に偏っているのは周知の事実であり、高性能なネットワークが必要なのはここなのでここだけにシンプルなネットワークを適用すればIOWNなんていらないである。
今は親方電電虫が言ってるからお付き合いでやってる企業は多いが、温度差が激しい。もうすがる先がここしかないところはやっているが、そうでない所は冷めた目で見てる。
NTTが自社の環境こそがデファクトだと思い込んで、それに対応させるだけのガラパゴスな技術に名前を付けて出してしまった、それに取り巻きがやんややんやの拍手をしていると言うのが今のIOWNだよ。ISDNと同じ。
