  |
はてなキーワード:アーキとは
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A.AWS StorageGateway +AmazonEBS +Object Lock
B.AWS DataSync +Amazon S3 +Object Lock
C.AWS DataSync +Amazon EFS +Object Lock
D.AWS StorageGateway +Amazon S3 +Object Lock
回答C。 AWS StorageGateway は名称てきにオンプレミスと 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-Controlmax-ageを設定してキャッシュ比率を上げる
C.Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransitVPCで接続してSAMでLambdaを配置
E.CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
回答：A 他はなんか怪しい。
問題 5
アプリケーションはEC2 + RDSSQL 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 を有効にすると、削除や上書きを防止できます。
StorageGateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge →認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Controlmax-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると接続管理が爆発的に複雑 になる
TransitGateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirectConnectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
GeminiDeep Researchで本当の話なのか調査させ、はてな匿名ダイアリーへ投稿出来るように要約させた
はてな匿名ダイアリーを指定したら口調が勝手に変わって吹いたｗ
2025年末、「娘のはじめてPCにLinux」という議論がネット上で波紋を呼んだ。これは単なるOSオタクの戯言ではない。 「エリート層は子供にRaspberry Pi（ラズベリーパイ）を与えて"支配側"へ育て、一般家庭や公教育はiPadを与えて"消費側"に留め置く」という、現代の身分制度（デジタル階級社会）への警告だ。
本稿は、英国王立協会やGIGAスクール構想の実態、労働市場データを分析した「公教育の機能不全と家庭内資源動員に関する調査報告書」の要約である。結論から言えば、「中流以下の家庭こそ、なけなしの金を払ってでも子供にLinuxを触らせろ」ということになる。
かつてのデジタルデバイドは「ネットに繋がるか否か」だった。スマホ普及後の現代における格差は、「コンピュータの制御権（Root権限）を持っているか否か」である。
英国王立協会はすでに2012年の段階で「学校のICT教育はオフィスソフトの使い方しか教えていない」と酷評している。 その結果、富裕層の私立校では専門家を雇ってRaspberry PiやAI活用を教え、貧困地域の公立校では管理が楽なiPadを配って終わり、という絶望的な「質の乖離」が起きている。米国でも同様に、富裕層の子供ほど「消費的なスクリーン（TikTokやYouTube）」から離れ、ChromeOSやRaspberry PiやUbuntuなどを導入し創造的なプログラミング教育を受けている。
日本の金のある自治体の公立小中学校で配られたiPadは、MDM（管理ツール）によってガチガチに制限されている。 逆に、ChromeOSはLinuxベースであり開発環境として優秀なのだが、教育委員会は「セキュリティ」と「管理コスト」を理由にその扉（ChromeOSやLinuxでの創造的な授業）を諦めた。 結果、公立校の生徒はiPadで「Web閲覧」と「ドリルアプリ」しかできない。
一方で、開成や筑駒といったエリート校の生徒は、制限のない環境でサーバーを構築し、Unityでゲームを作り、競技プログラミングに没頭している。iPadの 「サンドボックス（砂場）」の中で遊ばされている公立校生と、システムの内側に触れているエリート校生。このスタート地点の差は、10年後に致命的な「年収の差」となって現れる。
「社会に出ればWindowsだろ？」というのは20年前の常識だ。現代の高付加価値インフラ（AWS、Google Cloud、AI開発、IoT）は、ほぼ全てLinuxで動いている。
GUI（マウス操作）はAIにとってコストが高いが、CLI（コマンド操作）はAIへの命令（プロンプト）そのものであるため、相性が抜群に良い。Linuxを学ぶことは、「AI時代におけるコンピュータへの正しい命令作法」を学ぶことと同義だ。
「MOS(Microsoft Office Specialist)」というフィルター機能は低下し、GithubやPixiv、Youtubeなどでのクリエイティブな活動履歴（何を作れるか）がパスポートになる。貧困・中流層がこの壁を越える唯一の武器が「技術力（ポートフォリオ）」だ。
中流以下の公教育が頼りにならない以上、家庭で動くしかない。幸い、Linuxの世界は「金はかからないが、知恵と時間はかかる」。これは資金力のない家庭にとって最大の勝機だ。
30万円のMacBookは不要。企業落ちの中古ビジネスPC（ThinkPad X250/X260等）なら、秋葉原や通販で1.5万〜3万円で買える。Windows11が入らない型落ちこそ、軽量なLinuxには最高の機体だ。Raspberry Pi 4や400の中古も良い選択肢となる。
親が教えられないなら、CoderDojo（無料のプログラミング道場）のようなコミュニティに子供を連れて行けばいい。そこには「技術を楽しんでいる変な大人」がいる。その出会いが重要だ。
「壊れるから触るな」ではなく、「壊してもOSを入れ直せば直るから、好きにいじれ」と言って管理者権限（Sudo）を与えること。YouTubeを見る端末を、YouTubeを作る端末に変えること。
高価なiPadを買い与えて安心するのではなく、1万円の中古PCを与えて「黒い画面」に向かう子供を応援すること。 その小さな投資が、子供を「デジタル小作人」から救う唯一の手段になるかもしれない。
ここ数時間、落合陽一はんがNullNullっちゅう大阪万博のパビリオンの件で、新建築いう建築専門誌をめっちゃ突っついとるんや。
こないだ出た12月号が万博特集でな、見た感じほぼ全パビリオン網羅しとる思うわ。
これが何でインパクトあるかいうたら、新建築はこれまで万博についてほぼ黙っとったからや。
開幕時も、会期中も、閉幕時も、ほぼ一切触れてこんかったから「新建築は万博に反対しとるんか？」いう声も出とったくらいや。
業界で一番権威ある雑誌が、建築の集まりみたいなイベントを完全スルーしとったわけやからな。
それがこの年末になって、ほぼ一冊丸ごと万博特集やから、そらみんなビックリするやろ。
ほんで落合陽一はんや。
落合はんはNullNullのプロデューサーやった。設計したんはNoizっちゅう豊田啓介はんの事務所や。
NullNullは日経アーキテクチュアの表紙にもなっとったし、万博の目玉のひとつやったな。
ところが落合はん曰く、
「新建築にNullNull載っとるの、雑誌出て初めて知ったぞ？ワイに何の話も来とらんやんけ！」
「しかも載っとる図版、ワイが知っとるのと全然ちゃうやないか、編集部どないなっとんねん！」
いうて怒っとるわけや。
「新建築は落合はんに連絡してへんのか？」いう反応になるんは当然や。
けど、現段階で落合はんが新建築をボロクソに攻めとるんは、大丈夫なんやろかとワイは思う。
ワイも設計を仕事にしてるから分かるんやけど、新建築いう雑誌は基本「設計した人」に掲載依頼してくるんや。
掲載するにはオーナーとか利害関係者の許可も要るけど、そのやり取りも設計側がやるんや。
ワイも掲載決まったとき「お施主さんに承諾もろてください」言われてお願いしたことあるしな。
せやから今回も、新建築は設計したNoizに掲載を依頼したと思うわ。プロデューサーである落合はんには直接連絡せんかったやろね。
刊行前の誌面チェックもNoizがやっとるはずやで。
そのとき利害関係者である落合はんには情報が行かんかった。それが誰の問題になるんかは正直微妙なところやな。
あと、落合はんが言う「載ってる図版が間違っとる」いう件やけど、新建築は本来、図面なんか1枚も持っとらん。
せやから「Noizが出した図版と、落合はんが出したかった図版が違う」いう話やろな。
現状、落合はんはまだNoizと連絡取れてへんのかもしれん。明日あたり進展あるんちゃうか。
NullNullに関して言うと、他のシグネイチャーパビリオンと違って、落合はんいう特異な才能を持った人がプロデューサーやったやろ。
せやから、会期中から落合はんと豊田はんで「この建物を『設計した』んは誰か」いう主張が微妙にズレとった感じもあったと思うわ。
河瀨直美はんとか福岡伸一はんは、パビリオンのコンセプトは立てれても、実際の建築設計はできへんやろ。
せやけど落合はんと豊田はんの場合、「どっちがどこまでやったんか」が正直かなり分かりにくかったように思うわ。
逆に言えば、落合はんと豊田はんという2人の「どっちがどこまでやったんか」分からんくらいのコラボやったからNullNullはできたんやと思うけどな。
これは「建築の設計者とは何をした人のことなのか」、「誰が主体的にその建築を語ってええのか」いう、いろんな問題を孕んどると思う。
ある意味、これまでいろんな媒体で、落合はんも「ワイのパビリオンです」いう感じで露出してきた感もあったやろ。
せやから今度は、Noiz的には建築雑誌っちゅうホームで自分らが主導で語りたかったり、新建築的には語らせたかったりしたのかもしれんな。
せやけど、まあ後々のこと考えたら、何事も利害関係者には一言連絡しとくに越したことはないと思うで。
今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時にTypescript は案外うまくいかないことが多い。
UIとかシンプルなものであれば結構うまくいくけど、graphql,prisma みたいなところになると、token数すごくなるし結局完成しない。
この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。
↓↓↓↓↓↓↓
##ソフトウェア工学から見たTypeScriptの3つの根本課題
Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。
1. 不健全な型システム (Unsound Type System)
ソフトウェア工学において、型システムの**「健全性（Soundness）」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。
TypeScriptは、この健全性を意図的に放棄しています。
設計目標の不在:TypeScriptの公式ドキュメントには「健全であること」は設計目標ではないと明記されています。これは、JavaScriptとの互換性や開発者の利便性を優先した、根本的なトレードオフです。
具体的な不健全さ:
配列の扱い:string 型の変数に (string |number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。
any型と型アサーション:any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション（as構文）は、健全性を根本から破壊する「抜け道」です。
関数の引数（Bivariance）:関数の引数の型チェックが、他の多くの言語（反変）とは異なり、より緩いルール（双変）になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。
学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。
2.構造的部分型（Structural Typing）の罠
TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。
意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン（業務領域）の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。
過剰なプロパティの許容:constconfig: { port:number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ（host）がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。
これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。
3. 「漏れのある抽象化（Leaky Abstraction）」としての本質
Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。
TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実（undefined, null, thisの挙動など）を意識し続けなければなりません。
抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。
摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。
##結論
ソフトウェア工学的な観点から見ると、Web上の専門家の議論は我々の対話の結論を強く裏付けています。
TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
