  |
はてなキーワード: データセンターとは
https://arxiv.org/pdf/2304.10466.pdf
試行錯誤によって方針を学習する深層強化学習アルゴリズムは、環境と積極的に相互作用することによって収集された限られた量のデータから学習しなければならない。多くの先行研究が、データ効率の良いRLを実現するためには適切な正則化技術が重要であることを示していますが、データ効率の良いRLにおけるボトルネックの一般的な理解は不明なままでした。その結果、すべての領域でうまく機能する普遍的な技術を考案することは困難であった。
本論文では、非定常性、過剰な行動分布シフト、オーバーフィッティングなどのいくつかの潜在的な仮説を検討することにより、サンプル効率的な深層RLの主要なボトルネックを理解することを試みている。
強化学習ってよく知らない
我々は、状態ベースのDeepMind control suite（DMC）タスクについて、制御された体系的な方法で徹底的な実証分析を行い、遷移の検証セットにおける高い時間差（TD）誤差が、深いRLアルゴリズムの性能に深刻な影響を与える主犯であり、良い性能をもたらす先行手法は、実際、検証TD誤差を低く制御することを示した。この観察から、ディープRLを効率化するための強固な原理が得られる。すなわち、教師あり学習の正則化技術を利用することで、検証TD誤差をヒルクライムできる。
誤差を減らすのがDeepLearningだけど、それが時間差なのか。
我々は、検証TD誤差をターゲットとするシンプルなオンラインモデル選択法が、状態ベースのDMCとGymタスクにおいて効果的であることを示す。
1 はじめに
強化学習（RL）法は、大容量の深層ニューラルネット関数近似器と組み合わせた場合、ロボット操作などのドメインで有望視されている（Andrychowicz et al、
2020）、チップ配置（Mirhoseini et al.、2020）、ゲーム（Silver et al.、2016）、データセンターの冷却（Lazic et al.、2018）。アクティブなオンラインデータ収集の単位ごとに費用が発生するため（例．
実際のロボットを動かす、シミュレーションによるチップ評価など）、限られた経験量でも効率的に学習できる、サンプル効率の良い深層RLアルゴリズムを開発することが重要である。このような効率的なRLアルゴリズムの考案が、近年の重要な研究課題となっています（Janner et al、
2019; Chen et al., 2021; Hiraoka et al., 2021)。
原理的には、オフポリシーRL法（例えば、SAC (Haarnoja et al., 2018), TD3 (Fujimoto et al., 2018), Rainbow (Hessel et al., 2018)）は、データ収集のステップごとに多くの勾配ステップのポリシーと値関数を改善することを可能にするため、良いサンプル効率が得られるはずです。しかし、このメリットは実際には実現できないようで、1回の学習ステップを多く取りすぎることでを収集した各遷移は、多くの環境において実際にパフォーマンスを害する。過大評価（Thrun & Schwartz, 1993; Fujimoto et al., 2018）といったいくつかの仮説、非定常性（Lyle ら、2022）、またはオーバーフィッティング（Nikishinら、2022）が根本的な原因として提案されている。
これらの仮説に基づき、より多くの勾配ステップを持つオフポリシーRLを可能にする方法として、モデルベースのデータ増強（Jannerら、2019）、アンサンブルの使用（Chenら、2021）、ネットワークの正則化（Hiraokaら、2021）、再生バッファを維持しながらRLエージェントをゼロから定期的にリセット（Nikishinら、2022）などのいくつかの緩和戦略が提案されている。これらのアプローチはそれぞれサンプル効率を大幅に向上させるが、これらの修正の有効性は（これから示すように）タスクに大きく依存する可能性があり、根本的な問題やこれらの手法の挙動を理解することはまだ未解決である。
ICLR 2023で会議論文として発表 本論文では、より多くの勾配ステップを取ることが深層RLアルゴリズムの性能悪化につながる理由、ヒューリスティック戦略が役立つ場合がある理由、そしてこの課題をより原理的かつ直接的な方法で軽減する方法を理解しようとするものである。
最近提案されたタンデム学習パラダイム(Ostrovski et al., 2021)を用いた実証分析を通じて、TD学習アルゴリズムは、学習の初期段階において、すぐに高い検証時間差(TD)誤差(すなわち、保留した検証セットにおけるQ-ネットワークとブートストラップターゲットの間の誤差)を得る傾向にあり、悪い最終解をもたらすことを明らかにする。
このホワイト ペーパーでは、深い RL アルゴリズムで勾配ステップを増やすとパフォーマンスが低下する理由、場合によってはヒューリスティック戦略が役立つ理由、およびこの課題をより原則的かつ直接的な方法で軽減する方法を理解しようとします。 最近提案されたタンデム学習パラダイム (Ostrovski et al., 2021) を使用した実証分析を通じて、トレーニングの初期段階で、TD 学習アルゴリズムが高い検証時間差を迅速に取得する傾向があることを示します。
(TD) エラー (つまり、保留された検証セットでの Q ネットワークとブートストラップ ターゲットとの間のエラー) が発生し、最終的なソリューションが悪化します。 さらに、データ効率の高い RL 設定のために考案された多くの既存の方法が、検証 TD エラーを低く制御する限り有効であることを示します。
この洞察は、深い RL を効率的にするための堅牢な原則を提供します。データ効率を向上させるために、検証 TD エラーを山登りすることによって、特定の問題に最も適した正則化を選択するだけです。
この原則は、オンラインRLトレーニングの過程で特定のタスクに最適な正則化戦略を自動的に発見しようとする単純なオンラインモデル選択方法の形で実現され、これを検証TDエラーを使用した自動モデル選択(AVTD)と呼びます。
AVTD は、各エージェントが異なる正則化を適用する共有リプレイ バッファーで、いくつかのオフポリシー RL エージェントをトレーニングします。 次に、AVTD は、環境内で動作するための検証 TD エラーが最小のエージェントを動的に選択します。
この単純な戦略だけでも、多くの場合、さまざまな Gym および DeepMind コントロール スイート (DMC) タスクで個々の正則化スキームと同様のパフォーマンスを発揮するか、それを上回ることがわかります。 重要なのは、パフォーマンスがドメイン間で大幅に異なる可能性がある以前の正則化方法とは異なり、私たちのアプローチはすべてのドメインで堅牢に動作することに注意してください。
要約すると、私たちの最初の貢献は、サンプル効率の高いディープ RL のボトルネックの実証分析です。 これらの課題の背後にあるいくつかの潜在的な説明を厳密に評価し、トレーニングの初期段階で高い検証 TD エラーを取得することが、データ効率の高いディープ RL のパフォーマンスを阻害する最大の原因の 1 つであることを観察します。 私たちの 2 番目の貢献は、単純なアクティブ モデル選択法 (AVTD) です。これは、検証 TD エラーの山登りによって正則化スキームを自動的に選択しようとします。 多くの場合、私たちの方法は、さまざまな Gym および DMC タスクで、最適な個々の正則化スキームに匹敵するか、それを上回ります。
30年以内に「首都直下地震」が発生する確率は70％なんだそうだが、
自分が生きているうちに起きると考えると、東京に住んでいていいのかな、とぼんやり思う。
都の計画はどうなっているのか、たまにみるんだけど、自分が知りたいことがほとんど書いていない。
帰宅困難者の対応とか、災害対応のノウハウ的なことはどうでもよくない？
多分、そんなレベルじゃないと思う。
それよりも、木造密集地地域が倒壊＋火災で壊滅する可能性があるわけでしょ。300万世帯くらい。
その死傷者の推計も書いてある。だけど、生き残った人の生活再建が十分に書かれていない。
生き残った人は住処を失ったわけで、これまで経験したことのないような大量の難民が発生するわけですよ。
東日本大震災の経験からみても、災害直後は罹災証明などの業務で行政はパンク状態。被災地の対応で手いっぱい。
また当面の避難所。仮設住宅なんていうけど、どこにそんな場所あんのよ。区の公園などが候補地リストに載っているのをみるけど、トイレどうするの？上下水道電気、廃棄物、ただでさえ周囲のインフラがメタメタなのに、いろいろ考えるとせいぜい1週間、そう長くは我慢できないでしょう。そのキャパも問題だろうけど、それよりも1年～3年スパンでの生活再建どうするのかが問題。
300万世帯の人が一斉に。そして半壊した自宅も気になるから、なるべく東京近郊で。まず無理でしょ。当たったら宝くじレベル。避難所生活に耐えかねて、遠くの町でビジホかネカフェ難民化、そして最悪ホームレス。あるいは半壊住宅に無理やり住み続け、そういう人が多ければ多いほどマクロな復興を妨害することに。
そんななか、首都直下に関しては、千葉県は意外とキープレイヤーなのかもしれないと思うことがある。
まず下総台地の地盤が固い。柏や印西市に次々と大規模なデータセンター開発が進められているのは、洪水地震災害リスクが相対的に低いからだ。
そして、市街化調整区域が山ほどあって、幹線道路も細く農地の割合も多い、という、限界ニュータウンなど最近も話題になった。
その意味では都市生活の利便性の観点からはめっちゃ不便である。現状では資産価値ゼロかマイナスでむしろお荷物。ただ、ひとたび首都圏に危機が発生すれば話は別だ。焼け跡に囲まれた墨田区の公園でストーブに当たっているよりはるかに価値がある場所になる。
都市計画・土地利用を見直せば災害復興のために活用できるポテンシャルは高いということだ。
ただ、半世紀前の成田空港建設で合意形成に失敗した経験から考えて、災害が起きてから、復興のポテンシャルのある地域を選ぶのでは間に合わず、事前に復興のシナリオについて周辺市町村と調整を進めたほうがいいと思う。
NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく
そもそもIOWNって何？っていう話については恐らくNTTの社員でも誰一人答えられないので割愛したいが
発端は電気によるネットワークルーティングに限界が来ていることから始まっている
このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ
IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること（All-Photonics Network: APN）が構想の発端である
電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる
1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった！」となるだろう
IOWNは100Gbpsを提供してくれる
ちなみに今でも企業向けに100Gbpsの専用線サービスは存在している
なのでIOWNは何も大容量サービスではないのだ
ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので
まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない
また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう
ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い
低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだが
低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである
さて、IOWN1.0の提供価格は月額198万円とのことである
現在提供されている100Gbpsの専用線サービスも198万円である
これも資料を見るとIOWN1.0では1.0倍とのことなので妥当な価格である
IOWN2.0では13倍（倍とは？）とのことなので価格も大幅に下がってくれるだろう
逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある
ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが
遅延に関してはIOWN1.0で1/200を目指している
これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる
さて、低遅延になって誰が嬉しいのかはさておき、現状では東京ー大阪間で15msぐらいである（往復）
これが1/200になると75μsとなるのだが、東京ー大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない
なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる
実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが
15msが8msになったのを「1/200」と言われるのはモヤッとする
そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている
つまりは大容量であることを活用して非圧縮で送信すればコーデック部分の処理遅延を減らせるとの主張である
コーデックの遅延は製品にもよるが200〜800msぐらいある
また、超低遅延のコーデックなら10msを実現できるらしい（使ったことはないが）
伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう
ただしそれは従来の100Gbpsネットワークでも実現できる
特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワークを研究する際によく使われた方便で
4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ
それが今の時代では、8K非圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである
ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう
問題なのはこの非圧縮リアルタイム映像伝送はほとんど使われていないということである
コーデックが進化することでコーデックにかかっている遅延は無視できるようになり
特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ
なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワークの試験で用いられているのが現状である
まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない
それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか
遠隔での演奏を実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる
この2mに価値があるのだろうか
また、人間の脳のクロック間隔は30msであるという研究結果がある
15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である
問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ
光の速度の限界なので当たり前ではあるのだが
限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ
普通の演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える
確かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている
そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが
そもそもe-Sportsのゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか
同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い
逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが
ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが
10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない
もちろんゲームによってはこの数msで価値が生まれる場合もあると思うが、あまり数は多くないように思える
結局のところ、IOWNは大容量かつ低消費電力、つまりは低価格のサービスとして進んで行くだろう
End-To-EndでIOWNが必要か、と言われると明確に答えはNOで
10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークはそもそも必要ない
一方でデータセンタ間のインフラネットワークとしては非常に価値が高い
データのレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ
特に災害が多い日本では地理位置分散をさせることは非常に重要で
そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる
こうしたインフラとしての重要性は明確に求められているのにもかかわらず
「IOWN」と標榜してまるで次世代のネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。
考えすぎかもしれないけれど…。主に環境問題からやり玉にあげられるリニアモーターカー（以下、リニアと略す）だけど、国防の観点から議論があってもいいように思うんだよね。
元アルファベット（Google）会長でオバマ政権時に米国防イノベーション委員会(DIB)の議長も務めたエリック・シュミット氏が指摘するように、AIは第二の核兵器となり戦争を根本から変えてしまうと言われている。そしてあまり話題になることはないが、AIは電気を大量に消費する。2030年までに世界の消費電力の最大20％がデータセンター関連が占めるようになるという予測もある。
AIは有事の時にだけ稼働させればよいという性格のものではない。311の時のヤシマ作戦は使えない。EVも普及していく流れにある。EVは国際的なトレンドであるため、抑制は難しい。一方、リニアは日本だけの事情であるため、比較的フリーハンドで考えることができるはず。少しでも節電できるものは節電してインフラ設計していくのがポスト核抑止力としてのAI時代の制度設計なんじゃないだろうか。
かつて（1989年）、リニアの消費電力量について、元国鉄技師の某氏が「1 人あたりでは新幹線の 40 倍」と主張し、鉄道総研の理事長が「東海道新幹線の3倍」と反論したことがあったそうだが、3倍のコストの意味が、論争当時（平時）と今（準有事？）とでは違ってきたと思うんだよね。
リニアは、東海道域に地震や噴火があった際の代替手段の位置づけもある。であれば、現行の東海道新幹線と同等の輸送量／時での消費電力量を第三者（できれば国防関連機関）がきちんと算出し、その差分をスピードアップのコストとして考え（私は新幹線大好き中央新幹線新設でいいじゃん派なので）、その電力の使い道がリニアでよいのかコンピューティングを優先すべきなのか、国防の観点からも安心させてもらいたいと思う。それに、リニアってネット環境大丈夫なんだろうか。
レイドレースは、世界中のff14プレイヤーが一緒に遊べるお祭り。
MMORPGとはいえ、ワールドもデータセンターも別れていて、別データセンターの人と交流する機会はほぼないので、もちろんプレイヤーも知らない。
けど、レイドレースになれば、世界中の猛者が参加し、攻略スピードを競い合う。
world 1stになったところで、得られるものなんて名誉しかなく、公式からは世界一おめでとうのtweetがされるのみである。
レイドレース自体はプレイヤー間で自然発生的な感じで始まった非公式のお祭りだけど、公式も称賛だけだが一枚噛んでくれる。
ゲーム内にNFT的なもの、、それこそ某アニメなどにありそうな、世界で唯一のユニークスキルだとか、唯一のアイテムとか、そんなものはない。
あるのは吉田P/Dからのコングラッチュレーションだけである。
とはいえ、日常的に配信しているプレイヤーであれば、実利はある。
もともと配信に向かないと言われているff14だからそんな大したことはないだろうけど、14内での唯一のeスポーツ的なものと言えばこの非公式レイドレースである。
名前を売るにも絶好の機会ではある。
ff14自体外部ツールは利用禁止である。利用規則にも明言されている。もちろん、ソフトの改変やリバースエンジニアリングなども禁止である。
じゃあどこまでが禁止か？ということに関しては、吉田P/Dはずっと言及を避けてきている。
まぁ光の戦士であれば常識だとは思うが、詳細は過去の吉田P/Dの発言などでも見てほしいものだけど、
あたりであろうか。
多分感想は人それぞれだと思う。性善説で任せてもらっていると思う人もいれば、バレないようにやれよお前らと言われていると感じる人もいるでしょう。
今回の騒動の中でも、act（ダメージログの自動集計）はいいけどズームハック（クライアント改ざん）はダメって言ってる人もいるわけで（個人的にはどっちも難易度に直接関わるものなので両方ダメに決まってるだろと思うわけですが）。
で、この騒動の中で吉田P/Dがずっとぼかしていた部分を明言したわけですよ。
「今回、外部ツール不正使用が調査によって明らかになった場合、少なくとも僕は、当該チームをワールドファーストチームとは認めません。」
一歩踏み込んで来ましたね。僕はね、これはちょっとなぁと思っちゃったわけです。全方位に配慮する吉田P/Dにしては珍しいなと思った次第です。
まず、今回ツール発覚はチーム内部・関係者によるハッキングの結果の告発になります。前々回のネバーランドは自らツール使っていることを晒していましたが、今回はハッキングされた上で情報がバラされています。
もし、サーバー側で外部ツールの利用が確認できているのであれば、前回覇者にもペナルティが来るはずですが、それはなかった（と思う）。
ということを考えたら、ズームハックしてもログ上ではバレず、ペナルティはない。
まぁ、今回は大炎上したし、チームからも自首したようなので、そちらがメインなのかもしれませんが。
細かい経緯はわからないけど。まぁハッカー（正確にはクラッカーですけども）が得をするということは、今後レイドレースを行うチーム、ユーザーは常にハッキングに怯えることになるのもセットで考えなくちゃいけないのではなかろうか。
ツールを使っていなければいいというわけじゃなくて、ツールを使っているだろうお前！！って疑ってくるやつがクラッキングを繰り返す可能性があるということです。
なぜなら、吉田P/Dの発言は、クラッカーに正義棍棒をもたせることになったなと思うのですよ。
大炎上している、燃やしている側に正義棍棒を持たせるっていうのも、なんだか吉田P/Dとしてはなんとなく珍しいなと思った次第であります。
吉田P/Dがかのように明言されている以上、今後レイドレースは、外部ツールを使っていないことを証明しながらのクリアをしなくてはいけなくなるのですけども、
まぁいわゆる悪魔の証明との戦いなのよね。
なんだかドーピングと戦ってきたロードレース業界みたいだなと思った次第。
戦ってきたというとなんか違うな。ドーピングスキャンダルまみれだったという方が近い。
最高峰のレースであるツール・ド・フランス、99年から95年まで優勝者無しなんだから。
ランスアームストロングが7連覇したときだけど、ドーピング発覚で優勝剥奪になったけど、
何位までの選手がドーピングしているのか、今更全部調べきることできないからもう空白っていうことで！みたいな。
大きなレースとか大会の優勝者が、何年その座につけるのか、そっちの方が気になっちゃうのがロードレースだから。
ロードレースのドーピングは2つに大別されて、トレーニング中と大会中の２つ。
トレーニング中は回復力を高めることができ、質の高いトレーニングを通常より多くこなすことができるためのもの。
大会中もやはり回復力を高めることができるもので、心拍数190くらいで死にそうな状態で山を登っているときのもう一踏みを手助けしてくれるもの。
俺自身はドーパーなんて優勝者として認めないけど、とは言えドーピングすることで、他の誰よりもつらい状況に長時間いることができるようになるものかつ、
ロードレース界でいえば、当時上位者は全員ドーパーだったこともあり、結局のところイコールコンディションなので、まぁそれはそれでええんちゃうっていう気持ちもある。
ロードレースはドーピングスキャンダルにより、長い長い低迷期を迎えることになった。
今それなりに人気が戻ってきているのは、チームスカイがゼロトレランスをうたいながら、クリス・フルームという偉大な選手を育て上げたからだろう。
その流れを見てきたあとで、ff14の不正ツールスキャンダルを見れば、
それらを使ったところで俺にはクリアできないし、劇的に簡単になるわけでもない。
レース一位を競うには有利にはなると思うけど、使ったところで自キャラがコエチカモリモリのワンパンマンになれるわけじゃない。
一段と窮屈になるのが嫌だなーっていうね。
まぁ、個人的にはズームハックはもちろん、actもダメだし、discordも外部ツールだし、ヌシ釣り用の各情報サイトも外部ツールだし、YouTubeの攻略情報も外部ツールだと思っているので、グレーのままが良かったんだけどねぇ。
公式フォーラムに書く場所なかったからついでにここに書いておくけど、
もし本当にレイドレースを公式にしてレギュレーションも決めるのであれば、ぜひ一度ロードレース界の話を聞いてみるのがいいと思う。
個人的にはこれまで通り非公式且つコングラあり、ツール発覚時には通常より重めのペナルティ（一発垢バン）とかでいいんじゃないかなーと思っちゃうけど。
最後に、これだけの最高のコンテンツを、長時間に渡って開発してくれて、見ているだけでもドラマチックで感動的なバトルで胸が熱くなるもんで、
それが最終的にユーザー同士のいがみ合いの場として終わらせてしまったことに関して、
何よりも吉田P/Dはじめ開発スタッフの皆様に本当に申し訳なく思う。
吉Pごめんよ（土下座エモート
1段階じゃなくて100段階くらい進化した姿ならこんな感じだと思う
スマートウオッチよりも小さく高性能なウェアラブルデバイスがさらに普及する
さらに高性能なワイヤレス充電が普及し公共の建物や駅、大型商業施設、バスやタクシーなどの乗り物内、幹線道路や高速道路上などは内部空間が丸ごと充電エリアになり、そこにいるだけでデバイスは自動的に充電されるようになってバッテリー切れはおろか充電の概念すらも消滅する
それはあらゆる建物や乗り物の入り口や内部、店舗のレジのみならず、そのデバイスそのものが他人のデバイスを検知し送信する機能を持つ
センサーが検知したデバイスの情報はデータセンターにリアルタイム送信され続けるようになる
人は蓄積されたデータをどのように利用するかをレストランのメニューのように選べるようになる
たとえば民間の健康診断サービスと連携した場合、デバイスが直接検知した当人の健康状態のみならず、過去一年間に入った飲食店、頼んだメニュー、一日あたりの徒歩の移動距離、各所の便器に設置された尿や便の成分などが集計され、今後起きる可能性の高い病気や不足している運動量、生活圏内にある当人の経済状況に適した飲食店などが提示される
結構多くのWEBサーバのアクセス制限で.co.jp .ne.jp .jpがdeny設定されていたって話である。
https://b.hatena.ne.jp/entry/s/twitter.com/kanose/status/1601270223386324992
個人のネット利用で大きな転換点は2005年くらいで、例えばブログのはしりのはてなダイアリーサービス開始は2003年でアルファブロガー選考開始は2004年、youtubeサービスインが2005年だが、これらの特徴は「アカウントをとって企業のWEBサービスを利用する」という、今では当たり前の方法だ。
だがこの以前にはそういう方式のものは少なく、ISPや借りたレンタルサーバに自分でコンテンツをアップロードして構築するというのが主流だった。
これは内部的にはLINUXサーバ制限アカウントを貰ってユーザーディレクトリの/WWWにファイルを置くという事やね。
だから最初のうちは個人サイトのURLは「ｈttp://www.yourisp.co.jp/~aybabtu」って感じだった。~はUNIXのユーザーホームディレクトリを示すのね。やがてバーチャルドメインに対応するサーバ会社が増えてｈttp://www.aybabtu.rentarusabaa.comみたいな今では当たり前のURLになったんだが、最初はバーチャルドメイン設定は有料だった。
MS Officeには「パブリッシュ」ボタンがあってそれを押すと編集してるファイル群の構造のまま指定したサーバにFTPでファイル送るみたいな機能もあった。（だがこれはShift-JISでUpするというクソ仕様で後に読めなくなるのだった）
httpの頭のHTはハイパーテキストで、参照箇所にはリンクが設定できて参照元にジャンプ（これも死語だ）できる電子文書なわけで、まさに公開はパブシュッシュ＝出版なわけだ。今もサブスクリプション＝新聞雑誌の定期購読というのはこの建付けが残ってるからだ。
ISPやWEBレンサバにはユーザー権限の多寡で違いがあって、ユーザに実行権限も付与してperlなどのインタープリタを構築しておくと、テキストであってもファイル先頭にインタープリタへのパスを書いておくとそれが実行され、標準出力をhttpで返す。これがCGIで、ISP供与で多いHTMLファイルの公開だけの権限制限されたサーバに不満な層は「CGI実行可」のレンサバ屋に移っていった。
但しプログラムであるから、いい加減に書いてループ参照とか起こすとサーバのCPUやメモリを喰いつくしてサーバダウンを惹き起こす。だからISP供与のでは実行権限を与えなかったわけだ。逆に言えばISPが必ずホームページ公開スぺースを供与するのに個人向けレンサバが成り立ったのは何故？と言えばCGIの実行が出来たからだ。
故にWindowsしか使わない人には難しい上級者向けだったのだが、これを優しいチュートリアルで簡単設定出来るようにしてユーザーを増やして会社を大きくしたのがpaperboy＆co.の家入一真氏なわけだ。はてな創業者の近藤淳也氏と並ぶ個性的なアントレプレナーと謂われた。その後堀江などと共にインターネッ党を作って都知事選に出て箸にも棒にもな結果になったのは黒歴史なので触れないで上げてください。特に堀江は野菜でいじられるよりも傷つくので偉そうに政治の話してる時に「インターネッ党」とボソっというのは残酷な事なので止めてあげて欲しい。お願いします。
また、CGIでの使用言語はperlが圧倒的で、perlで書いた掲示板スクリプトを配布するサイト、趣味プログラマが星の数ほどいた。
こういう訳で初期のWEBで動的ページ＝perlであってJcode.pmを開発した小飼弾氏は魔術師扱いされて崇拝されており、ブログブームが来ると圧倒的な人気を誇った。
今では多言語が普通に扱えるのが当たり前だが、マルチバイト文字の扱いというのは難しく、文字コードがそれぞれ違うのがそれに輪をかけていた。例えば今でも日本語Windows上でフランス語や中国語のファイル名は作れないだろう。また、最初期からかなりの期間、Twitterでは日本語の検索が出来なかった。youtubeでも日本語で投稿できなかった期間は長い。
子飼氏はperlで日本語を使用できるようにするライブラリをUNICODE対応にしてWEBで普遍的に日本語が使えるようにしたものだ。
ただ、HTLMと実行文を混ぜ書きできるPHPがver.4になるとデータベース連携が強化されていてデフォルトでSQL文発行関数が実装されており、perlCGIは廃れていってしまう。
またISPより高い自由度を求めて自宅にサーバを立ててそれを公開するという者も現れた。
はてなはサーバをデータセンターに置いてはいたものの、筐体は町工場に設計図を持ち込んでステンレスの1U筐体を自前で作っていたし、Pixivはギガバイトのシステムボードを使って自作した多数のサーバをエレクター上に置いてむき出し運用してしていたので、自宅サーバ組の延長にあったのだな、実は。
こういう中で画像を公開する、動画を公開するというのはなかなか大変だった。
仲間内で見るという分にはファイルを置けばいいだけだが、問題になったのが「2ch晒し」であった。これは悪意を持って2chにURLを貼るのだけじゃなくて、単にURLを書くというのも含まれた。
というのも2chにURLが書かれるとアクセスが集中して大抵はサーバダウンしてしまう。すると他の契約者のサイトもページも見れなくなってしまう。
例えばヒーロー戦記主題歌みたいな社歌でbuzzった日本ブレイク工業のサイトは重すぎて何週間も閲覧出来なくなった。社歌の動画ファイルを置いていたためだ。
こういうサーバダウンは契約者の責任ではないがホスティング会社も許してはくれない。契約解除、つまり出ていけか、法人契約への変更かを迫られる。転送量制限なしと言っていても実際に転送過多になると干すティングになるわけだ。
だから2chは悪意の塊の他にサーバーダウンとサーバからの追い出しを惹き起こすので蛇蝎のように嫌われていた。2ch晒し→その時点でサイトを閉じてしまう人も多く居た。
するとこれを逆手に取ってアップローダ（あぷろだ）を自作サーバで運用してアフィリエイトで収入を上げる者が現れてくる。
ただこれは著作権違反のファイルが上げられて訴えられる事もあるからそのリスク低減のためと転送量制限の為にファイル容量に制限が設けられていた。
すると大きなファイルを共有したい連中はこれでは満足できない。
そこで目を付けたのが海外でアップローダを運用しているサーバだ。運用動機は日本のアップローダと変わらない。だがファイルの大きさの制限が緩かった。
そこでそういう海外のアップローダが違法性が高いファイルの共有に使われるようになった。やってたのは2chのダウンロード板と半角板がメインだ。
だがこれは運営には迷惑な話で、日本人は英語の広告なんてクリックしない。しかも商品の販路が無いので日本からのアクセスに報酬は支払われない。つまり金を落とさず転送量だけ上がるのだ。しかも海外では転送量従量課金は多かった。
更に問題なのがロリ画像がアップロードされることだ。2次元ロリでも規制があるのに実写ロリは完全アウトだ。実写ロリが発覚した場合、サーバ管理者は必ず逮捕される。マグショットが新聞に掲載されTVで晒され、釈放後も幼児が被害者の性犯罪者なのでGPSロガ装着が義務付けられ住所は共有される。二度と部屋を借りる事は出来ずに一生トレーラーハウスかキャンピングカーを買って橋の下で生活となる。
こんな実写ロリ画像や動画をアップロードする奴が居たのである。
そこで管理者としては日本からのアクセスが増えたのを確認した時点で遮断するしかない。一生を棒に振る可能性を回避するためだ。
圧倒的によく使われるWEBサーバのapacheでは.htaccessというシステムファイルに記述してアクセス制限を掛ける事が出来る。ここで国別IPアドレス指定するのはちょっと難しいのでdeny from co.jp deny from ne.jpという風に書くとドメインがco.jp、ne.jpからのアクセスを全部弾くことができる。
この時にディレクトリ指定を「/」にするとそのサーバの全てが弾かれて403エラーが出てしまう。しかもバーチャルドメインも同じなので思わぬところで403エラーが出る事もある。
そういう訳であちこちの海外サーバで日本からのアクセスが拒否されていた。全て2chダウンロード板と半角板のやつらのせいである。
自分はアメリカの田舎の新聞社のトップページで403を食らったことがあるから嫌われ方は相当なものだと思う。「やるべき.htaccessの基本設定」みたいなのに書かれて共有されたのかも知れない。
因みにダウンロード板と半角板は2ch名物の厨房板だったのに、今見たら無くなってるのな。諸行無常だ。
2005年にサービスインしたYoutubeだが、翌年にGoogleに買収されたもので最初は元paypal社員らが作ったベンチャーだった。
だが最初は著作権違反コンテンツばかりであって、自作ビデオというのは少なかった。
特に酷かったのがまた日本人で、最初は10分制限がなかったのをいいことにアニメの全話丸上げみたいなのが大量にされており、当事者のアニオタ達も「ここまでやったら閉鎖されるだろ！」と諫めるほどだった。
そんな中で2006年6月にYoutubeが数日間の大メンテナンスに突入し、画面には「All your video are belong to us」というブロークン英語が書かれていて騒ぎになった事があった。
これの元ネタは「All your base are belong to us」で、古いセガのゲームの英語版で出てきたセリフだ。深刻な場面で突然めちゃくちゃな英語をいう。このおかしさでFLASHが作られたりとミーム化していたものだ。
しかも日本産ゲームは結構あちこちでバカ英語を作ってて、engrishとかjanglishとか言われてネタにされていた。日本で言えばアヤシイ中国製品の日本語を愛でるような感じだ。
そこでYoutubeがあんなメッセージを出したので、日本のネット民は身に覚えがありすぎて「アニオタのせいだろ！また排除されるだろ」と責任のなすり合いと相なったのだった。
因みにその後も日本人の利用が制限とかは無かったので誤解だったのだが、海外アップローダ見つけては403の焼き畑とかロリ画像問題とかがあって、その後のアニメフル全話という流れだったので過剰反応をしたのであった。
