はてなキーワード: 冗長化とは
中小はどこでも慢性的な人手不足なので、なるのは難しくないと思う
院内の階級が最下層だから、割と本気で人間扱いされないし、雑用は全部おりてくる
危機管理マニュアルには、凶器を持って暴れてる人間がいた場合は事務職員が刺股持って対応することが書かれている
2年に1回ルール変更があり、それに対応できるかどうかで何千万とか下手したら億の金が失われる
ドクターは頭がとてつもなくいいけど、意外とパソコンが苦手な人も多い
院内のシステムやネットワークは本当にギリギリの予算で構築されていて、セキュリティも冗長化も十分でないので、ITに詳しい人は頼りにされることが多い
だがそれは、休日だろうが夜中だろうが電話に出られることが要求されるということでもある
バスの運転手に怒られながら看護部長の電話に対応することも避けられない
これらの諸々が苦にならないか耐えられるなら、簡単になれる割に給料も悪くないのでいいと思う
単体テストというのは、画面を手動で操作してスクリーンショットを撮る仕事だった。エクセルで仕様書を書き、レビューをしていたが、レビューアーはテストケースよりも、枠線の整え方に気を配っていた。
誰かが自動テストを導入しようと言い出した。「再現性がある」「保守性が高まる」「もっと良くなる」と口々に言われていた。
でも、テストコードを開発する工数はどうするのか、開発コードが増えればさらに大変になるのではないかと不安があった。
それでも、これが実現すれば、何かが大きく変わる予感がした。
アプリケーションフレームワークはStrutsだった。フォームをポストする瞬間にカオスが生じ、50行の無駄なコードを書き、100行の読みにくいコードを理解することが技術者の条件だった。
ある人が「レイヤリング」という概念を持ち出し、別の誰かが「DI」と言い出した。アプリケーションアーキテクチャという言葉も登場し、ファウラーという人物の名前も聞こえるようになった。
新しい構造が提案され、それに影響を受けながら、「いつかは美しいアプリケーション構造が生まれるのかもしれない」と夢を抱いていた。
当時、PerlでCGIを作っていたが、PHPやRubyが登場した時は、正直Web"サイト"を作るためのものだと侮っていた。
しかし、次々と洗練されたWebアプリケーションフレームワークが生まれ、StrutsやJavaEEよりもはるかに使いやすくなっていった。
数多くのWebフレームワークの中で、どれを選ぶべきか悩みながら、「いつか完璧なWebフレームワークが現れるかもしれない」と期待していた。
サーバーは冗長化され、ReversProxyを使い、セキュリティのために構成を変更してきた。そしてクラウドが登場し、Dockerなんて本番で使えないと言っていた時代から、
気がつけばどこに存在するのかもわからないクラスターの中で、コンテナアプリが動いている時代になった痛快だ。
かつてLinuxマシン一台を「鯖」と呼んでいた時代から、世界は目まぐるしく変化し続けるとかと思っていた。
誰かがAjaxと言い出し、別の誰かがReactと言い出した。「こんな方法でHTMLを作って良いのだろうか？」と疑問に思いつつも、「Webはアプリケーションだ」という感覚が強まっていた。Webアプリケーションがどう進化していくのか、未来を感じることができた
私たちは、ソフトウェアを開発すること自体に大変さを感じていた。新しい技術やフレームワークが次々と登場し、その都度課題が解決される一方で、新たな課題が生まれる。これほど面白いことはなかった。そしてエンジニアたちには一体感があり、誰もが自分なりの方法で課題を解決し、そのフィードバックループが世界を動かしていた。だからこそ、今は少しつまらない。変化は穏やかになり、「お金を稼ぐ」という目標だけが共通となり、課題は個々の事象に閉じ込められている。しかし、それが悪いことではない。ただ、私たちの時代が変わったのだ。
かつては、私たちの目の前には普遍的な課題があり、それぞれがそれぞれの場所で課題を解決し、そのフィードバックループが世界を動かしていた。
生成AIで例えると、それをどう使うかではなく、エンジニアが一丸となって生成AIをチューニングしていた。世界情勢で例えると、世の中の飢餓を全世界の人がアイディア出して、解決しようとしてたいた。
今でも、普遍的な課題は世界中に転がっているが、それらは高度で、私たちには手が届かないものが増えてしまった。
ITは面白かった。プログラミングが分かるだけで、世界の課題を一緒に解決できる時代だった。それぞれが自分の場所で働くだけで、世界を動かしていた。そんな時代が終わってしまったと感じる。
老害といえば昔話だろ！
サーバーがいっぱい集まってるSNS、いわゆるFediverseの一部。
Mastodonみたいな感じ。というかMastodonとも繋がれる。
（一応書いてみたけどはてなにいる人たちのほうが俺より詳しそう）
MisskeyのUI自体は今っぽくて使いやすい。カスタマイズも色々できる。デッキ表示が好み。アイコンデコはあまり好みではない。
絵文字がたくさんでリアクションが楽しい。仕事のTeamsとかでもBlobcat使いたい。
サーバーごとに雰囲気違って面白い。色々なアカウント作って色々試すと楽しい。
というかアカウントはいくつか作って冗長化したほうがいいなって思った。
運営の小さいサーバーが集まってる感じだから、結構メンテ不足で落ちたりするし連合（他のサーバーとのつながり）の不具合とかも気づきやすい。
電池めっちゃ食うしデータ通信量も多いので外出時はあまり見ない。
一番大きいところ。50万ユーザー以上いるらしい。オンラインはだいたいいつも1万人前後。
とにかく人や他のサーバーとのが多いし運営も法人化して頑張ってるのでハブ的に1つアカウントがあるといいかも。
Misskey.ioにいる人の投稿が流れるタイムライン（LTL）は流れが早すぎて目が回る。
大きすぎておそらく当初Misskeyで想定していた規模じゃないんだろうなって感じの不具合がたまに起きる。
チャンネルがいっぱいあって疎結合な感じで広くゆるく遊べる。疎結合の使い方ちょっと違う気がするけど雰囲気で伝われ。
法人運営のところ。3000ユーザーくらいらしい。オンラインは100人いかないときが多いかな。
一応株式会社が運営しているので課金体系とかもしっかりしてるし動作も安定している。不具合はまだ遭遇していない。
「ポップカルチャーを応援する」と謳っているせいか、LTLは気配が若いかも（当方アラサー）。マスコットキャラクターがかわいい。
「テック系ポッドキャスト”backspace.fm”が運営する汎用サーバー」らしいけどテック感よくわからない。3000ユーザーくらい、オンライン100人くらい。
絵文字賑やかめ、あと自分は遭遇したことないけどLTLの下ネタキツめらしい？
自分がIT職なのでテッキーなところを探して作ったけど正直そこまで顔を出していない。
他にエンジニア系はみすてむずにアカウントを作ったけどこっちもまだ慣れてない。
HTLがない穏やかなサーバー。50~70人くらいはいつもオンラインっぽいけど観測することは基本ない。
ここで一人日記をつけるのが結局一番落ち着く。Fediverse活かせてない？そうね…
リストとかアンテナとか作って情報収集用みたいな使い方をしている。
鯖缶がFediverseﾁｮｯﾄﾃﾞｷﾙの人で、年齢的にも？結構落ち着いていて色々安心感がある。
（ほかは若い鯖缶が多く、若さゆえだな…みたいなスリルにも稀によく遭遇する）
犬の画像や犬の話を眺める用。癒やし。
よそのサーバーの犬画像を持ってきてくれるアカウントもある。癒やし。
とはいえ説明が難しいので、まずは適当なところに作ってみて自分で確かめてみるといいかなと思う。
サーバーの選び方も人それぞれだと思うけど、個人的には「運営が安定している（金銭的、人格的、その他）」」は居心地良く感じることが多いかも。
あとは最初は話題が限定されるところより汎用サーバーのほうが無難かな？
アカウントは複数持ってたほうがいいとは思うけど俺は流石に増やしすぎて使いこなせてない。実はここに書いてないのもある。困った…
今の若い子には例え話が通じないってのは知ってたが、ここまでとはｗ
規模感の話をしてるの、元増田は数字を一切出さずに話してるよね？
まずそれが不誠実なんだが、それに対して数字で規模感を示したに過ぎない
計算したことは無いけど現在のピーク送電の４倍に増えても送電網はやりくりできる
発電が間に合わないけど、
トラックセンターは高圧特高受電するだろうから送電網の負荷なんていくら増えても問題ない
繰り返すが送電網は余裕だけど、足らないのは発電の方
で、だから送電網容量キャパ（元増田のいう「送電インフラ」）の話をするとしたら末端、電柱から自宅に引いてる低圧網の話でしかないんだよ
確かにこっちはギリギリだけど、それでもEV１，２台の充電なんて余裕だよってのが俺の趣旨
大きな仕事をしたいって意気込むくせに、育休取ります、子供が熱出したので会議出れませんと、仕事を放棄し他人に丸投げ。
皆仕事してるなか、Slackに子供との様子をツイッターの如く書き込むやつもいるし、自分が不妊治療で大変だったのに子供を授かり生まれた瞬間に同じような状況のやつを配慮しない幸せアピールするやつ。
社会人なので表面上は仕事を丸投げされても快く引き受けるし、幸せだね〜楽しそうだね〜と返答するけど、心を無にして社畜の如く働く。
こういうこと言うと、社員を冗長化してないのが悪いとか言うやついるけど、よっぽどの大企業でも無理でしょ。
常に既婚者は子供が生まれる・または育てるリスクがあると踏まえて、2倍3倍の人員を確保してくってか？お前は働いたことあるのか？？
運転の楽しさだのそんなのはどーでも良くて、自家用車の最大のメリットは「移動できる簡易拠点」であることなんだよな。
パッと思いつくだけでも、
みたいな利点がある（俺がぜんぶ活用してるかは別として）。
東京（や類する大都会）でも金持ちならタクシーやハイヤー使うかもしれないけど、専用車じゃなきゃ荷物は置いておけないだろうから片手落ち感はある。
それに自家用車持ってる層でも東京の渋滞や信号の多さはいかんともし難いだろ。郊外に出かけるならいいかもしれんが、デイリーユースでちょっと買い物行くのにダラダラ待つのはしんどそうだ。
先日家族で泊まりがけで横浜のアンパンマンミュージアムに行ったんだが、男の子の例に漏れず長男が電車や新幹線が好きで、公共交通機関のアクセス良いと思って新幹線と電車で行ってみたら地獄だった。荷物はクソ重いし子供は疲れてグズグズだし駅の中めちゃくちゃ歩くし……。次に行くときは絶対に車で行こうと思ったね。
東京の親は車持ってない人が多いと思うんだが皮肉じゃなくガチですげーと思う。ちょっとスーパーに買い物行くにも車が無いと思うとベリーハードだろ。よくこなせるよほんとに。
車は維持費がかかるって言うけど、そんなのピンキリだからな。そりゃハイオクでリッター5、6kmしか走らないようなデカい車は相応に維持費はかかるが、軽やコンパクトカーはたいしたことないよ。地方じゃろくに仕送りもらってない大学生だってフリーターだって車持ってるんだから。
駐車場借りたって新幹線の停まる駅近くで5000円/月とかだ。コインパーキングも12時間500円とか。なんなら駐車場1台無料の賃貸もたくさんある。購入費用だって中古のコンパクトカーを4、50万で買えば10年乗れる。
地方だと職場と自宅がどっちも在来線の駅徒歩1分のところに住んでる人だって車で通勤するんだ。その方が圧倒的に楽だからな。冗長化っていうか、最悪電車も使えるってだけだな。車検で代車も無いってときとかね。だから基本的に地方の電車って学生とジジババしか乗ってない。
「車社会」ってワードにどうもネガティブな印象を持たれてる気がするが、当人たちは望んで乗ってるっていうか、一度地方でこの便利さを味わったらもう手放せないよ。だから80のジジイが免許にしがみつくんだろうがな……。はやく自動運転が一般化してくれればいいんだけどな。
なんであんなに炎上するのか僕にはよくわからない…アイマス初めて6年経つけれどもこんなに「やめたい」と思ったような気持ちにさせるのは初めてだ…15万以上の課金してる人から見れば無課金や微課金勢にはアイドルを愛する権利などないといいたいのだろうか？そこまでして、自分の私生活を潰してまで上位を狙う人の気持ちがわからない…ゲームはあくまで娯楽でありのめり込むようなものではないということを小学校や中学校、高校で教わらなかったのだろうか？ゲームサーバーの冗長化や運営に対する補填を求める上位者たち…GCPが通信障害を起こしたのがきっかけで運営を袋叩きをするP（プロデューサー＝ファン）達…「システムは障害が起きる前提でアーキテクトを構築するもの」とつぶやいた人がいるが違うと思う障害が起きる前提で考えてると冗長化しなければならず、ミラーサーバーにアクセスするためにはスイッチングというものが必要である。それを踏まえて考えてみるとGCPが大規模障害を検知したときにはAWS（または各社Webサーバーなど）に流す措置を行う際に、スイッチングにトラフィックが大きくなり（簡単に言えば交通渋滞のようなもの）スイッチング自体に負荷がかかり大規模障害になりかねないというのもわからないのだろうか？？BNSがそこまでして新規にWebサービスと契約はせずそのままにすると思う。ゲームは重要インフラでもないしあくまで娯楽として楽しむものだと個人的には思ってる。「ミリオンPは頭がミリオンだ」と揶揄されることが多いが、今回の一件でさらに表面化したのではないかと思う…
発表資料を作った。
役職持ちもよいらしいので、発表内容である仕事に関わった上司（別係の人）と同僚を補助に指名してチームが出来た。
「ここの表現変えない？」
「この書き方だとこういうふうに誤解されるからさー」
「何と比較して変わったの？書かないとわかないと思うんだけど」
（テーマが従来との比較を前提なので書く必要はないと主張した）
「ここに書いてある業務は本当にやってるの？」
「これ、同じことを言ってるんじゃない？わからない人向けにまとめたら？」
（わからない人がいるならひとつひとつ区切って説明したほうがいいと説明）
とりあえずこのくらいは言われた。
極めつけはこのセリフ。
これが必ず頭につく。
「増田さんがいいならいいんだけどさ。ここ、画像貼るのやめない？そっちに目が行っちゃって資料見てもらえないと思う」
とか言う。
本当にいいと思ってるならこんなこと言わねーだろうオメーーはなんじゃ日本人かうっぜえええええ！！！
と思いながら、ときに反論しつつ、でも絶対折れてくれないから話が長引きに長引いて昼休みを潰された。
ひでえ嘘つきだよ。
最終的には
「あ……それ全部消すとなんか隙間が目立つから、消す前の文章を貼り付けて（以下略）」
（えっお前が消せって言った文章をまた付け足すの！？もしかして折れた！？）
という風に終焉が見えると思いきや、「最初のページさあ」と言われた。
話は長引いて終わった。
ここまでさんざん上司をグチグチ言ってるが、自分は超優秀な社員ではない。
今回の資料の出来に自惚れていたかと言えばそうかもしれないけど、なにがなんでも治さないといけないという気概で添削という名の書き換えを強要されたのは心底苛ついた。
2. 電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
3. 電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
4. 「3.」の実現は中小企業で導入するのは難しいものなのか？
5. 中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
6. 例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
会社で日常的に契約書のPDFや重要な文書を送付しあってるけど、あれ、内容が漏洩することはないの？
あと、会社の情シスから、「迷惑メールが突然来るようになるのは、第三者が設置した中継サーバーでメールアドレスが漏れてしますから。インターネットは不特定多数のサーバーを経由するから、ITを囓ったものなら誰でもそれは分かる」と言われた。確かにインターネット（というかTCP/IP通信）では冗長化されたネットワーク上でパケットが送付されるが、第三者の個人が設置した野良サーバーを、会社から送付されたメールのデータが経由するものなのか・・・？
送信プロトコルとしてSMTPがあり、受信はPOP3、IMAPがあるのは知ってる。
1.について： TCP/IP通信では冗長化されたネットワークをパケットが通るのは分かるが、例えばGmailからOCNのメールに送られるとして、都内在住のマンションに住むある悪意を持った人物が設置したグローバルIPを持つ野良のサーバーを経由して送られる、なんてことがあるのか？ あるとは思ってなかったのだが。。。
2.について： 上と同じ。
3.について： S/MIMEかな？ PGPは会社で使用されているのは見たことがない。
4.について： S/MIME、PGPは、例えば社員400名くらいの小規模な弊社でも導入は容易なのだろうか。Microsoft 365のExchange Serverの設定がいるの？
5.について： 情シスがこれ（メールアドレスは中継サーバーで漏洩するもの）を気にしていた。だから、重要な文書はメールで送ったりするな・・・と。そうなのか？ 初めて知ったのだが。。。メールアドレス漏洩は、リスト型攻撃みたいに文字列(@の左側)を試行して特定ドメインに送付され、届かなければ存在しない、届けばその文字列のアドレスは存在する、みたいなやり方とか、あとダークウェブで入手するものとか、そうだと思ってた。
6.について： 弊社の情シスが言うには、メールの盗聴というのは容易に可能だから、メールでPDFの給与明細を送付するなんてことは絶対にできないらしい（でも、普通にしてる気はするけど・・・）。確かに電子メールはネットワーク上を平文で送付されるかもしれないが、パスワード付きPDFにすればいいし、給与明細をWebサイト閲覧の形にしてTLS通信させればいいじゃん。そういうクラウドサービスあるんだし。そもそも、社内のHUBに悪意ある第三者がLANケーブルつないでパケットキャプチャするとか、実現の難易度高すぎるから、それは想定しなくていいんじゃないの？
ていうのか、疑問。誰か教えて。
追記しました。あとイプシロン8号機はイプシロン6号機の間違いです、ご指摘感謝します。H-Ⅱ 5，8号機が連続で失敗したときのNASDAバッシングの話を書くか悩んだ関係で混同しました。
失敗と表現した人を責めないであげて欲しい。宇宙輸送機の失敗に関する慣習的な定義については色々な人がもう意見を述べているのでそれを読んで貰えれば良いと思うが、それは業界の慣習というか方言なので、村の外から来た人が『機体の異常で予定した打ち上げのタイミングで上げられなかったなら失敗なのでは？』と思うのは仕方がない部分もあると思います(それでも失敗の軽重で言えば、輸送機の失敗としてはかなり軽寄りということは分かるような記事であればうれしいですが)。
最初に共同通信が失敗と報じた際、多くの宇宙ファンが共同通信の表現を叩いていたのをみました。近年ではイプシロン8号機などの宇宙開発の明確な失敗にもあたたかいコメントが寄せられる事が多く、またJAXAやメーカに対して厳しい論調を向ける人への批判もよくみます。批判自体は表現の自由の範疇であり行き過ぎない限りはありがたいのですが、失敗と報じたことのみを以て叩くのは行きすぎだったと思います。もちろんあの事象は中断と報じるのが習慣から言って適当だと思いますが、そういった習慣を記者に押しつけ、あまつさえ工学の素養が無いと馬鹿にする態度は業界に対して閉鎖的な印象をうみ、長い目で見たときにプラスには働かないのではないかと思います。もちろん記者会見でのあの態度は一社会人として許されるものではないですが、宇宙ファンが失敗という表現を叩いたことがあの態度を誘発した部分も無いわけではないと思います。
宇宙業界はまだまだ発展の可能性を秘めた分野であり、JAXAだけではなくメーカや宇宙ベンチャーなど多くの人が宇宙を身近に感じて貰い、より多くの人に関心を持って貰おうと頑張っています。宇宙ファンはもとより、今回の打ち上げが失敗だと思った人たちもこれを機に宇宙開発に興味をもって欲しいと思っています。また次こそはH3の打ち上げが成功するように、昼夜を問わずに働いているロケット屋さん達を応援していただけるとありがたいです。
『成功』と『失敗』は結果でしかなく、問題があったのに成功することもあれば問題がなかったのに失敗することもあります（※）。よって定義として失敗に当たらないとしても今回発生した問題は関係者間で重く受け止められていると思います。また決められたスロットの中で打ち上げればよいという話も『衛星を軌道に投入する』という点だけを見れば嘘ではないのですが、射点の数が少ない日本では一つの打ち上げが延期すると連動して他の打ち上げも遅れ宇宙開発計画全体が遅延することにもなり得ます。また海外顧客の獲得という点でみれば決められた日時に上げられるというのは大きなメリットになります。更にコスト面でも打ち上げが一日延期すると莫大な費用がかかると言われています。また搭載されているALOS-3の前号機であるALOS-2は既に設計寿命を越えており、空白期間を防ぐためにも早くサービスインしたほうが良いのではないかと思います。
とは言え今回のH3は試験機かつ衛星を載せているため安全性がより重視され、L/O前に止められてよかったという結論には変わりがありません。しかし上記のような点を無視して『全く問題がない、最終的に軌道投入できれば良いんだから問題があるというやつはわかっていない』というような言い分が広まることは岡田プロマネが「ロケットの打ち上げ中止自体は非常に大きなこととして受け止めている」と回答したことや事態の収拾にあたっている人達の努力を無にしてしまい、ブコメにもあるように「JAXAは失敗を認めずに意固地になっている」と言った印象をあたえるのでは無いかと思い今回の増田を書きました。
※後者はイメージしづらいかも知れませんが、高信頼な部品を使って冗長化しても偶発的故障の影響を0にすることはできず、最終的には確率の世界になります。またソフトウェアのバグも0であることを保証することはできません。よって万全を尽くしたけれどもどうしようもなく運が悪くて失敗する、ということも理屈の上ではありえます。まあその場合でも信頼性計算のプロセスを疑われることがほとんどとは思いますが。
これは意見が分かれるところだと思います。私も以前は少し調べればわかるようなことを聞く記者に対して、ちゃんと勉強してこいと思っていました。一方で一部の科学系雑誌などを除いて記事を読む人のほとんどは宇宙に興味がない人なわけですから、そういった人たちに情報を伝える役割としてはあえてその分野については素人な記者が質問して記事を書くというのも一定の意味があるのでは無いかと最近は思っています。今回の例をとっても『失敗』と書かないと一般の人に正しく伝わらないと先入観のない記者が考えたのであれば、必ずしも公式発表と同じ表現である必要もないのではないかと思います。ただ公式発表と違う表現をあえて使うならば業界の背景について専門的な記者が補足を入れ、発言者の意図が正しく伝わるような工夫をコミュニケーションの専門家として求めたいという気持ちは少なからずあります。記者の態度については既に述べたので書きません。
実際、会社辞めたのに保険証を持ってきて受診し、医療保険分が請求できず、後でこちらが再請求することはわりとよくある。（本人の自覚の有無はわからない。）
これが無くなることのメリットは医院側にはある。なりすましや不正利用に関してはこちらは直接的なメリットではないが、制度や犯罪防止のためには十分理解する。
立憲の枝野さんが言っていた停電は極端かも知れないが、機器のトラブルは必ずある。
LANケーブルの断線や、ルーターの不具合や資格確認端末の故障などだ。
あとは、光回線の不具合や資格確認のサーバーのトラブルも考えられる。（こちらは医院の責任ではないが、停電ではないから診療はできる）
いままでだったら、保険証の記号番号等を転記すればよかったが、それがなくなると、資格確認で国保なら国保組合、社保ならそれぞれの社保に電話連絡することになる。
電話番号は市町村の国保くらいならわかるけど、それぞれの社保の連絡先はまったく見当がつかない。
ヤフコメなどでは「停電ならそもそも電子カルテ動かないだろ」とか「診療そのものができない」と書き込まれているが、確かに歯科医院では停電だったら休診する。
でも、ネットワークのトラブルは診療はできるし、カルテは見られる。そもそも、歯科医院のほとんどは電子カルテに見えて電子カルテではないレセコンを運用している。
レセプト請求用に電子カルテのようなモノ（レセコン）を運用しているだけで)、カルテは紙だ。
だから、いままでも、パソコンのトラブルはあるけど診療した、なんて日がごくまれにはある。
オンライン資格確認のシステムの冗長化をしている個人の医院はほぼないので、そうなったら、資格の確認できない患者さんは断るしかない。
ブクマについて
https://b.hatena.ne.jp/entry/4715023022544762146/comment/maninthemiddle
maninthemiddle “同じ映画で例えるならば「2001年宇宙の旅」を観てる時とおんなじなのだ。音も場面も数倍賑やかなのに、おんなじぐらい退屈になっちゃった” 2001年宇宙の旅面白いやん…
https://b.hatena.ne.jp/entry/4715023022544762146/comment/marsrepublic
揚げ足取りで申し訳ないけど「2001年と同じ」なら終始興奮しっぱなしの超絶面白い歴史に残る名作、と言うことになってしまうんだが……？
もううんざりだ。2001年宇宙の旅が退屈な作品であることは間違いない。未だに不朽の名作だと持ち上げる回顧老人は回顧老人の自覚を持て。
2001（略）はそもそも冗長な作品だ。意味の変わらない長尺シーンが非常に多い。現代の基準で再構築したら上映時間は半分以下になるだろう。
それでも当時のファンは2001に熱狂した。それは革新的で鮮烈な映像体験を伴っていたからだ。あの映像を見ているだけで興奮したから、無意味な長尺を楽しめたのだ。
しかしフォロワーとなる作品が次々と生まれ、CG技術も進歩し、表現技法はさらに洗練され、SF表現もより先鋭化した。
そして時代を経るにつれ、物語や作品の定型化が作り手と受け手の双方に共有され、作品のテンポはどんどん早くなっていった。起承転結のサイクルは加速し、画面内を意味が埋め尽くす作品が当たり前に享受される世の中になったことで、相対的に過去の作品は冗長化したのだ。
現在の視点から見ると、2001は「映像の陳腐化」「物語の冗長化」のダブルパンチを食らった過去の作品となっているのだ。
そりゃ退屈だよ。
この無意味でつまらない映像は一体いつまで続くのか？という拷問のような作品だよ。
2001公開当時に衝撃をウケたおじいちゃんにとって、その体験は色褪せない黄金の記憶として残っているんだろう。
2001が後世に多大な影響を及ぼした歴史的巨作であったことも間違いない。
だがさらにリッチな映像と物語を過剰摂取して育った世代が2001を「退屈」とバッサリ切り捨てることも同時に間違っていないんだ。
VDI（仮想デスクトップ）代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する本連
載「テレワーク時代のWeb 分離入門」。 第1 回、第2 回でテレワークと Web 分離の方式の特徴を解説しました。
今回のゴール
用途の観点で各方式を分類すると下図のようになりますが、どんな組織にも共通する「おススメの方式」はあ
りません。
（出典：ネットワンシステムズ）
今回は、読者の皆さんが自組織にマッチする方式を選定できる状態をゴールとして、「結局、 どれを選べばいい
のか」という疑問に回答します。
フローチャートで分かる、
VDI 代替ソリューションの分類や、それぞれの仕組み、検討ポイントなどを解説する連載。最
終回は、VDI 代替ソリューションの方式選定における 4 つのポイントを解説して、各方式を比
較します。
（2021 年03 月04 日）
26 →目次に戻る
これまで多くのユーザーと会話してきた経験から、おおよそのケースで次の4 つのポイントに論点が集約されます。
2. データを処理するマシンがローカルマシンで大丈夫かどうか
これらを基に、方式選定に使えるフローチャートを作ってみました。
（出典：ネットワンシステムズ）
「 ブラウジングだけを安全に実行できればよいのか、それともブラウザ以外のアプリも安全に利用させたいのか」
テレワーク用途では、前者でよければセキュアブラウザ方式に、後者でよければそれ以外の方式にふるい分け
できます。Web 分離用途では、前者が仮想ブラウザ方式、後者がそれ以外の方式となります。
27 →目次に戻る
【ポイント 2】データを処理するマシンがローカルマシンで大丈夫かどうか
次に、「 情報漏えい対策をどこまで強固なものにしたいか」という観点での要件です。
プログラムの実行環境が手元のPC となる場合、データも手元のPC に保存されます。つまり、手元のPC を
「 ディスクを暗号化している、生体認証を有効にしている、だから大丈夫」と言い切れるならいいかもしれません
が、「技術の進歩によって将来的に突破されるかもしれない」といった懸念を払拭（ふっしょく）できない場合、仮
想デスクトップ方式やリモートデスクトップ方式のように、遠隔にあるマシン上で作業できる仕組みを導入する必
要があります。
その一方、将来の懸念よりも、例えばコストなど別の部分を重視したい場合は、会社PC 持ち帰り方式（VPN
なお一般的に、リモートデスクトップ方式とVPN 方式はテレワーク用途のみで導入されますが、仮想 デスクトッ
プ方式とアプリラッピング方式は、テレワークと Web 分離、どちらの用途にも利用できます。
【ポイント 3】データを処理するマシンが物理PC で大丈夫かどうか
【 ポイント 2】で「遠隔にあるマシン上で作業させたい」となった場合は、3 番目の検討事項として、業務継続
性を考えるとよいでしょう。
リモートデスクトップ方式の場合、社内の自席にPC が物理的に存在することが前提です。そのため、自席 PC
一方、仮想デスクトップ方式の場合、マシンが仮想化されており、多くの環境において仮想マシンが動作してい
るサーバ群はn ＋1 などの方式で冗長化されています。そのため、非常に強い障害耐性があります。
障害耐性を高めたい場合は、仮想デスクトップ方式がベストです。業務が停止するなどのリスクを運用でカバー
できる場合は、リモートデスクトップ方式を選ぶことになるでしょう。
28 →目次に戻る
【 ポイント 2】で「手元のマシン上で作業させてもOK」となった場合、3 番目の検討事項として、再度情報漏
えい対策について考えます。【 ポイント 2】では、PC ごとデータが盗まれてしまった場合を想定しましたが、ここ
手元のPC でプログラムを実行するということは、つまり「端末の脆弱（ぜいじゃく）性を突いたゼロデイ攻撃
を受けるリスクが存在する」ことです。脆弱性を突いた攻撃を受けると、多くの場合、情報を抜き取られてしまい
ます。
従って、例えば VPN 方式を導入する場合、「EDR（Endpoint Detection and Response）で脆弱性攻撃対
策を実装する」「端末のロックダウン化によってデータを保存させない」「実行できるプログラムを制限する」「屋
外の公衆Wi-Fi を利用できないように制限する」「多要素認証を導入する」などの対策を併せて導入する必要が
あります。
このような徹底した対策を継続して運用できる組織に限っては VPN 方式も有効な選択肢ですが、筆者としては
VPN 方式は安価かつ容易に導入できるので、昨今のテレワーク需要が高まる状況では、多くの組織で上記のよ
うな徹底した対策を取らずに導入してしまったと思います。取 り急ぎの暫定処置としてVPN 方式を導入してしまっ
た場合は、これを機に腰を据えて見直してみてはいかがでしょうか。
• 参考リンク：日本経済新聞「在宅時代の落とし穴 国内38 社がVPN で不正接続被害」
また、国内に限った話ではありませんが、Verizon Communications のレポートによると、やはりVPN トラ
フィックが増加傾向にあるようです。VPN 方式の普及に伴って、悪意ある攻撃者による被害数も増加すると思い
ます。
• 参考リンク：Verizon Communications「Verizon Network Report」
29 →目次に戻る
ここまで、要件をベースとした考え方を記載しました。選定すべき方式が大まかに見えてきたところで、ここか
らはそれぞれの方式を横に並べて、共通の項目に沿って比較します。
この比較によって、方式選定の次のステップとなる製品選定において「見落としがちな落とし穴を見つけて対策
を考える」といった検討を具体的に進めることができると思います。
以降の表の見方を説明しておきます。緑塗りのセルがポジティブな内容、赤塗りのセルがネガティブな内容、黄
塗りのセルはどちらともいえない内容です。また、それぞれの表の下部には、主に赤塗りのセルに関する特記事項
なお単純に、緑塗りセルの多い方式が優れているわけではありません。対象業務の内容やコスト、運用体制、セ
キュリティ、業務継続性など、いろいろな観点からトレードオフで方式を選定することになります。
できる作業
（出典：ネットワンシステムズ）
仮想ブラウザ方式とセキュアブラウザ方式では、例えばファイルサーバの操作といった、ブラウザ以外のアプリ
は使えません。多くの場合、Windows の統合認証など Windows に依存する機能も利用でません。
また、印刷に関しても確認が必要です。製品ごとにサポート内容に差が出るポイントなので、方式選定の次の
30 →目次に戻る
（出典：ネットワンシステムズ）
会社PC 持ち帰り方式（VPN 方式）とリモートデスクトップ方式は、端末のアップデート、故障時の交換など、
端末台数が増えるに従って、それに対応できる人員数を確保する必要があるので、運用コストが増大する傾向に
あります。
その半面、仮想デスクトップ方式は初期コストが高額ですが、メンテナンス対象はマスター OS のみであり、仮
VDI の運用ナレッジが豊富なSIer に依頼することで、作業内容の質を落とさずにコストを圧縮できる効果が期
待されます。
（出典：ネットワンシステムズ）
仮想ブラウザ方式やアプリラッピング方式、セキュアブラウザ方式は、「 Web ページが正常に表示されるかどう
か」などの動作確認を、あらかじめ実環境で実施しておく必要があります。この動作確認は、運用フェーズにおい
また、特に仮想ブラウザ方式は、「 ブラウザタブを開き過ぎるとサーバ基盤の負荷が高騰して Web ページの閲
覧速度が急激に低下する」といったサイジング関連のトラブルが発生しやすくなります。
31 →目次に戻る
（出典：ネットワンシステムズ）
マルウェア対策については、会社 PC 持ち帰り方式（VPN 方式）やリモートデスクトップ方式、仮想デスクトッ
プ方式は、EDR やアンチウイルスソフトの導入などが別途必要です。一方、仮想ブラウザ方式やアプリラッピン
グ方式、セキュアブラウザ方式は、「 利用終了後に環境ごとデータを削除する」「 exe 形式のファイルの実行を禁
重要情報の盗聴については、リモートデスクトップ方式や仮想デスクトップ方式、仮想ブラウザ方式（画面転送
型）は、画面転送型なので、暗号化通信が仮に復号されたとしても、実データが盗聴されることはないという強
みがあります。
最後に、不正アクセスについては、多要素認証システムと組み合わせるなどの対策がどの方式でも必要です。
ログインに関わる操作が増えることで利便性は低下しますが、昨今の状況を鑑みると、多要素認証の導入は必須
といえます。
おわりに
これで 3 回にわたる連載は終了です。いかがだったでしょうか。
セキュリティと利便性はトレードオフの関係にありますが、筆者は「仮想デスクトップ方式」と「仮想ブラウザ
仮想デスクトップ方式と仮想ブラウザ方式は、「 導入によってセキュリティレベルを大きく低下させることはな
い」という点が最大のポイントです。その上で、仮想デスクトップ方式には「従来のクライアント OS と同じよう
に利用できる」という汎用（はんよう）性の高さがあり、これが他の方式より優位な点となっています。一方、仮
想ブラウザ方式は、用途が限定されるものの、ユーザーにとっては利便性が高く、初期コストの観点では仮想デス
蕨変電所の火災でJR線が止まってる問題だが、これは直ぐには復旧できない。恐らく世の人が思っている以上に大きな事故なんである。
何故なら蕨変電所は普通の変電所と違ってハブになる変電所なので東京の1/3の路線に送電できなくなるからなのだ。
その影響は過去の事例から見て不通の解消に１日程度、つまり明日の朝は東京北部のJR線は走らないと考える。
そしてダイヤの大幅な乱れや並行私鉄線の殺人的な混雑は１週間程度続くと思われる。
まず、送電というのは発電所--変電所--変電所--変圧器（電柱の上）--家 となってるのだが、鉄道の場合はちょっと違う。電車が直流で走るからだ（関東以西）。
電力会社の変電所--鉄道会社の直流変電所（ここで交流→直流化する）--架線
国鉄はコストダウンの為に大需要地である東京での電力の自家調達に努めた。因みに見る角度で本数が変わる「千住のお化け煙突」っていうのは千住の国鉄石炭火力発電所の事だったのよ。
それが
・川崎火力発電所（火力/ガスタービン式、燃料はパイプライン供給の天然ガス/鶴見線扇町駅近く）
・信濃川発電所--武蔵境交流発電所（中央線武蔵境駅近くで見える巨大変電所）--沢山の直流発電所--架線
・川崎火力発電所--鶴見交流変電所（湘南新宿ラインで東海道線から分かれて直ぐに見える巨大変電所）--沢山の直流発電所--架線
となっている。そしてもう一つが今回問題の蕨で
・東京電力（パワーグリッド）鳩ケ谷変電所（岩槻街道沿いの超巨大変電所）--JR蕨交流変電所（蕨-西川口間にあるが少し線路からは離れている）--沢山の直流発電所--架線
となっている。
そして各系統間で電力を融通する為の「連系線」というのが、蕨--武蔵境--鶴見と各交流変電所間にあるんである。蕨交流変電所の隣を電車で通ると「JR蕨」って書いた鉄塔が見えるが、あれが蕨--武蔵境の連系線の鉄塔だ。（東電鳩ケ谷-JR蕨間は地下ケーブル）
因みに福一原発事故で外部交流電源途絶といった時の外部電源はこの連系線の事だよ。
ここで重要なのは、電気は各系統のを混ぜて使うって事は出来ない。
何故なら発電所は交流で位相（+と-が入れ替わる周期）が合っていない。それを「混ぜ」ようとすると打ち消しあって電力が減るし、それ以前にショートと同じだから送電線が爆発する。
だから連系線の電気を使う時は交流変電所から直流変電所への系統ごと切り替えるんだな。
こういう訳なので、架線も直流変電所ごとに区切ってある。その区切りが「エアセクション」ってやつ（架線が変電所系統ごとに平行に張ってある）。よく「エアセクションで電車が止まって立往生」になるのはこういう訳で、変電所毎の区切りをゆっくり進んでしまうとパンタグラフで各系統をショートさせた形になるから過熱して溶けたり燃えたり爆発する訳だ。
ここまで読んでもらったら、蕨交流変電所の復旧が2ステージに分かれる事が判るだろう。
過去に新宿直流変電所が爆発してとんでもない混乱が発生したことがある。山手線が中央線と合流する直前にその間に挟まるように白青の変電所が見えるが、あれが新宿直流変電所。事故以前は小さくてぼろっちい建屋だった。
1994年12月11日は冬の嵐で、多摩地区などでは雷が発生して交通網が混乱していた。そんな中、新宿変電所が漏電により出火。消防隊が臨場したが電気火災なので水を掛ける事ができない。そこでJR社員が遮断しようとしたがもう破壊され尽くしていて不可能。
すると上流の武蔵境交流変電所で遮断するしかありませんな。変電所火災は放っておくと変電器などが破裂して中の絶縁油に引火して大火災になっていきます。
ハブになっている武蔵境で遮断したら当然、東京中の路線も駅も停電して大混乱ですわ。因みにJRの場合は新宿にあるJR病院や本社ビルまで停電しちゃうのな。
それでやっと消火したけど新宿変電所は20万Vで溶接機振り回したような状態で建屋も完全破壊。復旧不可能ですわ。
仕方ないので新宿変電所を切り離す工事をして仮復旧。これで武蔵境から他の変電所に送電できるようになった。これに一日掛かってる。でも電力が足りないので相当な間引き運転で、振替先の私鉄地下鉄各線殺人ラッシュに。
次に新宿が受電してた送電線を他の変電所につなげる分散工事をして復旧。これで普通の運転間隔に戻せた。これが1週間。
話の脱線なんだが、新宿変電所を立て直す際にJRは送電の容量アップ、冗長化を進めたのね。それはインフラ企業として正しい事。
でも冗長性は普段は遊びになっちゃう。そして蕨からの送電は東電への電力料金が発生する。鶴見の発電は天然ガス代の支払いが発生する。信濃川はタダだ。連系系フルに活用できるだけのインフラも増強した。但し取水制限がある…。
という訳で「冗長化した設備の有効活用」が動機になってああいう不正をするようになっちゃったって面があるのよね。
新宿発電所の事故はこんだけ大変だったのだが、新宿はスター型結線の末端（少しハブの機能もあった）。
それに引き換え、蕨は大本のハブなのだ。今回の自体の深刻さが判って頂けただろうか？
望みは連系線フル活用できるように冗長構成がされていて信濃川でインチキしていた頃の取水をすれば被害を減縮出来そうってところ。
明日あたりに国に「蕨壊れちゃった…」と言って取水量大幅アップの許可取るのでは？それと川崎火力のタービン全開にしたら運転間隔半分までにはしないで済むかもしれない。
増田の家は東京北部なんだけど、昼過ぎに2度瞬停があって一瞬暗くなり、デスクトップパソコンは落ちなかったが電子制御の扇風機は動作不安定になった。
今考えるとあれが蕨での事故の瞬間と東電鳩ケ谷の遮断の瞬間だったのかなと。
蕨交流変電所の役目知らない人は「何時復旧するの」とイライラするが、知ってたら諦めた方が良いと判るね。
それでも会社に行かねばならない人は線路脇の送電装置類を眺めてその機能を調べて時間を潰したらどうだろう？電車撮ってる鉄オタは白い目で見られるけど、送電系が気になる銅オタは白眼視されないのでおススメです。