危険物取扱者は、かなりざっくり言うと
**「燃えやすい化学物質を法律に従って扱える資格」**です。

取り扱う対象は、消防法で定められた「危険物」で、代表例は：

• ガソリン

• 灯油

• 軽油

• アルコール類

• シンナー

• 重油

• 一部の薬品

などです。

なので実は、日常生活や産業で普通に使われているものが多いです。
ただし量が増えると危険性が一気に上がるので、資格と管理が必要になります。

どれくらい危険？

例えばガソリンはかなり危険です。

ガソリンは：

• 少しの火花で引火

• 蒸気でも燃える

• 空気と混ざると爆発的に燃焼

します。

危険物取扱者は、こういうものを

• 保管

• 給油

• 移送

• 管理

• 立会い

できるようになります。

資格の種類

有名なのは「乙4（乙種第4類）」です。

これは：

• ガソリン

• 灯油

• 軽油

• 重油

など“引火性液体”を扱える資格で、ガソリンスタンド関係で有名です。

さらに強いのが：

• 甲種 → ほぼ全部の危険物

• 乙種 → 特定カテゴリ

• 丙種 → 一部だけ

という感じ。

「爆薬」まで扱えるの？

ここは誤解されやすいですが、
危険物取扱者は基本的に消防法上の危険物です。

なので、

• ダイナマイト

• 火薬

• 爆薬

• 銃弾

みたいなものは別体系（火薬類取締法など）で、別資格・別管理です。

実際の仕事は？

イメージほど「爆発物を触る人」というより、

• 安全管理

• 保管ルール

• 温度管理

• 静電気対策

• 漏洩防止

などをきっちり守る仕事です。

つまり、
**「危険だからこそ、雑に扱わず、ルール化して安全に扱うための資格」**なんですね。

一言でいうと、**「復号の成否（特にパディングが正しいかどうか）を手がかりにして、暗号文から平文を推測していく攻撃」**です。

もう少し具体的に説明します。

ブロック暗号（例：AES-CBC）では、データの長さを揃えるためにパディング（余白埋め）を入れます。代表的なのは PKCS#7 で、末尾に「何バイト埋めたか」を書く方式です。

サーバ側で復号するときはこんな流れです：

1. 復号する

2. パディングが正しいかチェックする

3. 正しければ処理続行、間違っていればエラー

ここで問題になるのが、「パディングが正しいかどうかで挙動が変わる」ことです。

もし攻撃者が
・暗号文を少しずつ改ざんして送る
・サーバのレスポンス（エラーかどうか）を見る
これを繰り返せるとどうなるか。

「この値だとパディングが正しい」→ 一部の復号結果が推測できる
これを1バイトずつ積み上げることで、最終的に平文全体が復元できてしまう、というのがパディングオラクル攻撃です。

イメージとしてはこんな感じです。

本来：
暗号文 → 復号 → 中身は見えない

攻撃時：
暗号文を細工 → 「OK or エラー」だけ観測 → 中身を逆算

この「OK/NGを教えてくれる存在」を**オラクル（神託）**と呼んでいます。

重要なポイントを整理すると：

・対象は主に CBCモード＋パディングあり
・「エラーの違い」や「応答時間の差」が手がかりになる
・鍵そのものを盗むわけではなく、平文を復元する攻撃
・昔のWebアプリ（HTTPSの一部実装など）で実際に問題になった

対策もセットで覚えると理解が締まります。

・パディングエラーとそれ以外のエラーを区別しない（同じレスポンスにする）
・復号前に改ざん検知（MAC検証）を行う（Encrypt-then-MAC）
・そもそも AEAD（GCMなど）を使う ← 現代はこれが主流

まとめると、
**「復号結果の“正しい/間違い”というわずかな情報漏れを足がかりに、暗号を崩す攻撃」**です。

データベースでいう「カタログ化」は、ざっくり言うと

“DB自身が持っている管理情報を整理して保存すること”

です。

まず「カタログ」とは何か

DBの中には、ユーザーデータ以外にも大量の情報があります。

例えば：

• テーブル名

• カラム名

• データ型

• インデックス情報

• 権限

• 制約

• 統計情報

こういう
「DB構造そのものの情報」
をまとめたものがカタログです。

別名で：

• システムカタログ

• データディクショナリ

• メタデータ

とも呼ばれます。

イメージ

たとえばDBに：

CREATE TABLE users (    id INT PRIMARY KEY,    name VARCHAR(100));

を作ると、

DB内部では：

テーブル名: usersカラム: id型: INTPKあり...

みたいな情報が
システムテーブルに保存されます。

これがカタログ化です。

なぜ必要？

DBは毎回：

• このテーブル存在する？

• カラム型は？

• インデックスある？

• 権限OK？

を確認する必要があります。

そのため、
内部に「管理台帳」が必要なんです。

実際にはどこにある？

多くのDBでは内部テーブルとして存在します。

例：

• PostgreSQL → pg_catalog

• MySQL → information_schema

• Oracle → データディクショナリ

例えばPostgreSQLなら：

SELECT * FROM pg_tables;

でテーブル一覧が見れます。

「カタログ化」という言葉の使われ方

文脈によって少し意味が広がります。

1. DB内部のメタデータ管理

これが本来の意味。

2. データ資産の整理

最近は：

• データカタログ

• データガバナンス

文脈でも使われます。

これは：

• 「どこにどんなデータがあるか」

• 「誰が管理しているか」

• 「機密データか」

を企業全体で整理する意味。

実務的には何に効く？

かなり重要です。

DBはカタログを使って：

• SQL最適化

• 実行計画生成

• 権限確認

• スキーマ管理

をしています。

つまり、
DBの頭脳の一部みたいなものです。

まとめ

シンプルに言うと：

• ユーザーデータ → 本体データ

• カタログ → DB自身の管理情報

そして「カタログ化」は、
その管理情報を整理・保持する仕組みのことです。

キジムナーとは、**沖縄地方に古くから伝わる精霊（妖怪・樹木の精）**です。ガジュマルの木に住むとされることが多く、沖縄の民話では非常によく登場します。

キジムナーの特徴

伝承によって細かな違いはありますが、一般的には次のような特徴があります。

• 子どものような姿をしている

• 赤い髪をしていることが多い

• ガジュマルの古木に住む

• 泳ぎが得意

• 魚、特に魚の左目が好物とされる

• 人間の言葉を理解し、会話することもある

地域によっては「木の精」「妖精」「妖怪」など、さまざまな存在として語られます。

人間との関係

キジムナーは、必ずしも人間に害を与える存在ではありません。

仲良くなると…

• 漁を手伝ってくれる

• 幸運をもたらす

• 家を守ってくれる

怒らせると…

• 家を出て行ってしまう

• いたずらをする

• 不運が続く

昔話では、「キジムナーを裏切ったために幸運を失った」という話が多く見られます。

ガジュマルとの関係

沖縄ではガジュマルは生命力が強く、大きく育つ木です。そのため、昔から神聖な木と考えられ、キジムナーの住む木とされてきました。

現在でも「このガジュマルにはキジムナーがいるかもしれない」と語られることがあります。

日本の他の妖怪との違い

キジムナーは、本州で伝わる妖怪とは少し性格が異なります。

• 河童：川に住み、人を驚かせることが多い

• 座敷童子：家に住み、幸福をもたらす

• キジムナー：木に住み、人と友好的な関係を築くこともある

そのため、「森や木の精霊」に近い存在として描かれることが多いです。

まとめ

キジムナーは、

• 沖縄に伝わるガジュマルの木の精霊

• 赤い髪の子どものような姿で語られることが多い

• 人間と友好的になることもあれば、裏切られると去ってしまうこともある

• 沖縄の自然や信仰と深く結び付いた伝承上の存在

という特徴を持つ、沖縄を代表する民間伝承の精霊です。

最も速く泳ぐためのバタ足を一言でいうと、

「膝で蹴るのではなく、股関節からしなるように脚全体を動かす」

です。

初心者ほど、

太もも固定↓膝だけ曲げる↓バシャバシャ

になりがちですが、これは水の抵抗が増えて意外と進みません。

脚はムチのように使う

イメージは：

股関節 ↓太もも ↓膝 ↓足首 ↓つま先

へ力が伝わる感じです。

魚の尾びれやムチに近いです。

膝は多少曲がりますが、主役ではありません。

足首を柔らかくする

速い選手は足首がかなり伸びます。

つま先を伸ばして、

足の甲↓水を押す

状態を作ります。

逆に足首が90度に近いと、水を受けすぎてブレーキになります。

振幅は大きすぎない

「大きく蹴れば進む」と思われがちですが、

• 上がりすぎ

• 下がりすぎ

は抵抗になります。

競泳では一般に体のラインを保ちながら、小さく速く打つ方が効率的です。

下向きだけでなく上向きも使う

実は推進力は、

• 下へ蹴るとき

• 上へ戻すとき

の両方で発生します。

上げる動作を脱力せず、水を感じながら行うのが重要です。

体幹を固定する

どれだけ脚力があっても、

頭 ↑↓腰 ↑↓

と揺れるとエネルギーが逃げます。

速い泳ぎでは、
体幹を一直線に保ち、そのラインのまま脚を振ります。

短距離と長距離の違い

50m自由形のような短距離では、

• 6ビートキック

• 高頻度

• 高出力

が主流です。

一方、長距離では疲労を抑えるため、キック数を減らすこともあります。

速いバタ足の感覚

良いバタ足は、

水面が少し泡立つでも大きな水しぶきは上がらない

状態です。

水しぶきが派手だから速いわけではなく、むしろトップ選手は見た目以上に静かに強い推進力を出しています。

デカップリング（decoupling）は、簡単にいうと
**「お互いをベタベタに依存させないこと」**です。

ITでは特によく使われます。

例えば、システムAがシステムBを直接呼び出していて、

• Bが落ちるとAも止まる

• Bの仕様変更でAも修正必要

• 処理速度が互いに影響する

みたいな状態は「密結合（tight coupling）」です。

これを避けて、

• 片方が落ちても影響を減らす

• 独立して変更できる

• スケールを分離できる

ようにするのがデカップリングです。

具体例

キューを挟む

よくあるのがメッセージキューです。

悪い例：

Webサーバ → 直接メール送信

メールサーバが重いと、Web側も遅くなる。

デカップリング後：

Webサーバ → Queue → メール送信Worker

こうすると：

• Webはすぐ応答できる

• メール処理が遅れても本体は動く

• Workerだけ増やせる

になります。

なぜ重要？

大規模システムほど、
「全部がリアルタイム直結」
だと壊れやすくなります。

なので、

• 非同期化

• キャッシュ

• Queue

• API化

• マイクロサービス

などで依存を弱めます。

ただし万能ではない

デカップリングすると、

• 構成が複雑になる

• デバッグが難しい

• 整合性が遅延する

• 監視ポイントが増える

というデメリットもあります。

例えばQueueを挟むと、
「処理が今どこで止まってる？」
が見えづらくなる。

なので実務では、
“必要な場所だけ疎結合にする”
のが重要です。

IT以外でも使う

実は一般概念としても使われます。

例えば会社組織でも：

• 特定個人に依存しない

• 部署同士を分離する

みたいなのも広い意味ではデカップリングです。

つまり本質は、
「片方の問題が、全部に波及しないように切り離す」
です。

「おととい来やがれ」は、直訳すると

「一昨日（おととい）に来い」

という意味ですが、もちろん実際には「一昨日に行く」ことはできません。

そのため、慣用句としては次のような意味になります。

「二度と来るな」
「話にならない、相手にしたくない」
「出直してこい（今のお前では話にならない）」

という強い拒絶や軽蔑を表す言葉です。

なぜ「おととい」なのか？

ポイントは、「来るなら一昨日に来い」という実現不可能なことを言っている点です。

つまり、

• 「もう手遅れだ。」

• 「来る資格なんてない。」

• 「そんなことはあり得ない。」

という皮肉を込めています。

「明日来い」や「来週来い」なら実際に行けますが、「一昨日来い」は時間をさかのぼれないので、実質的には『来るな』と同じ意味になります。

ニュアンス

例えば、

A「100万円貸して。」

B「おととい来やがれ！」

この場合は、

「貸すわけないだろ。」
「ふざけるな。」
「相手にする気はない。」

という強い拒絶を表しています。

一方で、

「そんな実力じゃ、おととい来やがれだ。」

のように使うと、

「その程度では全然ダメだ。」
「もっと実力をつけてから出直してこい。」

という意味合いになります。

「やがれ」について

「やがれ」は命令形ですが、乱暴で相手を見下す言い方です。

そのため、「おととい来やがれ」はかなりぶっきらぼうで、けんか腰の表現です。冗談で使われることもありますが、真面目な場面で相手に言うと失礼になるので注意が必要です。

それは結構鋭い指摘です。

確かにAIの回答を見ると、何か設計の話になるとすぐに

• マイクロサービス

• Kubernetes

• イベント駆動

• サービスメッシュ

みたいな方向へ行きがちです。

でも現実のシステム開発では、必ずしもマイクロサービスが主流というわけではありません。

なぜAIはマイクロサービスを推しがちなのか

学習データに理由があります。

技術記事やカンファレンス発表では、

• Netflix

• Amazon

• Uber

• Spotify

のような大規模サービスの事例が大量に公開されています。

そしてそういう企業はマイクロサービスを採用していることが多いです。

一方で、

「普通の会社がSpring BootやLaravelでモノリスを作って5年間問題なく運用している」

という事例はあまり記事になりません。

技術記事として面白くないからです。

結果として、

AIは「公開情報が多い設計」を学習しやすくなります。

実際の現場はどうか

実は今でもモノリスは非常に多いです。

特に

• 社内システム

• 業務システム

• 中小規模サービス

• スタートアップ初期

ではモノリスが普通です。

理由は単純で、

作るのが簡単運用が簡単デバッグが簡単

だからです。

マイクロサービスは意外と大変

例えばユーザー管理サービスと注文サービスを分けると、

モノリスなら

関数呼び出し↓終わり

ですが、

マイクロサービスだと

HTTP通信認証タイムアウトリトライ監視ログ集約分散トレーシング

などが必要になります。

かなり面倒です。

AWSでも同じ

AWSの試験勉強をしていると

• Lambda

• ECS

• EKS

• EventBridge

が大量に出てきます。

すると

「全部マイクロサービスにした方が良いのでは？」

と思いがちですが、

実際には

ALB↓EC2 2台↓PostgreSQL

みたいな構成で十分な案件は山ほどあります。

最近の流れ

ここ数年は少し揺り戻しもあります。

有名なのが

モジュラーモノリス（Modular Monolith）

です。

考え方としては

アプリは1つ↓コードは綺麗に分離↓本当に必要になったら分割

です。

いきなり10個のサービスに分けるのではなく、

まず1つで作る。

スケールや組織の都合で必要になったら分割する。

という考え方です。

結論

AIがマイクロサービスをよく挙げるのは、

• 公開情報が多い

• 技術記事が多い

• 大規模事例が目立つ

からです。

しかし現実のシステム開発では、

• 小〜中規模ならモノリス

• 大規模ならマイクロサービス

• 最近はモジュラーモノリスも人気

というのが実態に近いです。

特にユーザーさんのようにAWSやシステム設計を勉強していると、「最先端の構成」と「現場で一番使われている構成」は意外と一致しない、という場面によく出会うと思います。

技術界隈は新しいものほど話題になりやすいので、実際の採用率よりも存在感が大きく見えることがよくあります。

正直に言うと、TripleDESは「理論的に安全そうに見えて、実運用ではもう厳しい」という位置です。主な弱点は大きく3つあります。

まず一番致命的なのがブロックサイズが小さい（64ビット）こと。
これが何を意味するかというと、大量のデータを同じ鍵で暗号化すると同じブロックが衝突しやすくなるという問題です（いわゆるSweet32攻撃）。

HTTPSのように通信量が多い用途では、現実的にリスクになります。現代のAESは128ビットなので、この点で大きな差があります。

次に遅いこと。
TripleDESは名前の通りDESを3回回すので、単純に処理が重いです。しかもDES自体が古い設計なので、ソフトウェアでもハードウェアでも効率が悪い。

結果として、同じ安全性を目指すならAESの方が圧倒的に高速で現実的です。

3つ目が有効なセキュリティ強度の限界。
鍵長は168ビットに見えますが、実際には「ミートインザミドル攻撃」の影響で約112ビット相当の強度になります。

これ自体はすぐ破られるレベルではないものの、現代基準では「将来性がない」ラインです。

細かいですが、他にも気にされる点があります。
・古い設計（1970年代ベース）で安全性の余裕が小さい
・一部プロトコルではすでに非推奨・禁止
・実装ミスや設定ミスが起きやすい

まとめるとこうです。

「小さいブロックサイズによる現実的リスク」と「遅さ」と「中途半端な強度」
この3つが重なって、今はAES（特にGCMなど）に完全に置き換えられています。

なので新しく何かを作るなら、TripleDESを選ぶ理由はほぼありません。互換性維持で仕方なく残っている、というのが実情です。

エルニーニョ現象が日本に影響するのは、

太平洋の海水温の変化が、大気の流れ全体を変えてしまうから

です。

つまり、
「南米付近の海が少し暖かくなるだけ」ではなく、

• 海流

• 上昇気流

• 偏西風

• 高気圧・低気圧の位置

まで連鎖的に変わります。
日本の天気はその“大気の流れ”に強く支配されているので影響を受けます。

1. まずエルニーニョ現象とは何か

通常、赤道付近の太平洋では：

• 東（南米側） → 比較的冷たい

• 西（インドネシア側） → 暖かい

状態になっています。

これは貿易風（東風）が海水を西へ押しているからです。

エルニーニョ時

何らかの理由で貿易風が弱まると、

• 暖かい海水が東側へ移動

• 太平洋中央〜東部の海面温度が上昇

します。

ここで重要なのは、

海が暖まると、その上の空気の動きも変わる

という点です。

2. なぜ海水温で大気が変わるのか

暖かい海は：

• 水蒸気を大量に出す

• 上昇気流を強める

つまり、
「空気の巨大なエンジン」になります。

上昇気流が変わると：

• 雲の発生位置

• ジェット気流

• 高気圧・低気圧の配置

までズレていきます。

3. 日本への影響の仕組み

日本の天気は、

• 太平洋高気圧

• 偏西風

• ジェット気流

にかなり左右されます。

エルニーニョで太平洋の熱配置が変わると、

• ジェット気流が蛇行

• 高気圧の張り出し方が変化

• 季節風の強さが変わる

→ 日本の気温・降水量が変化

します。

4. 日本で起きやすい傾向（一般論）

典型的には：

夏

• 冷夏寄りになりやすい

• 太平洋高気圧が弱まりやすい

• 雨が増えることもある

冬

• 暖冬寄りになりやすい

• 西高東低が弱まりやすい

ただし、
毎回完全に同じにはなりません。

5. なぜそんな遠くの海が影響するのか

ここが一番不思議なところです。

大気は実際には：

世界中でつながった巨大な流体

です。

例えば：

• 赤道で空気が上昇

• 上空を流れる

• 中緯度で下降

• 偏西風に影響

という連鎖が起きる。

つまり、
南米沖だけの話ではなく、

太平洋全体の“熱の置き場所”が変わる

現象なんです。

6. エルニーニョが「異常気象」と言われる理由

通常の気候パターンが崩れるため、

• 豪雨

• 干ばつ

• 台風変化

• 漁業変動

などが世界各地で起きます。

日本もその一部として影響を受ける。

7. ラニーニャとの違い

逆に、

• 西側に暖水が強く集まり

• 貿易風が強い

状態がラニーニャです。

こちらは日本で：

• 猛暑

• 厳冬

になりやすい傾向があります。

まとめ

• エルニーニョは「海水温の変化」だけではない

• 海の熱配置が大気循環全体を変える現象

• 日本の気候は偏西風や高気圧配置に強く依存

• そのため遠い太平洋の変化でも日本に影響が出る

つまり本質的には、

エルニーニョは“海”の現象というより、
地球規模の大気循環の再配置

なんです。

ポイントインタイムリカバリ（PITR: Point-In-Time Recovery）とは、

「過去の特定時点の状態までデータを戻す仕組み」

です。

単なるバックアップ復元との違いは、

• 「昨日のバックアップに戻す」
  ではなく

• 「昨日の15:32:18時点に戻す」

のように、かなり細かい時刻を指定できることです。

よく使われるのは：

• DB誤削除

• ランサムウェア

• アプリ不具合

• オペミス

など。

例えば：

12:00 正常12:10 誤DELETE12:20 障害発覚

普通のバックアップだけだと、
前日状態に戻ってしまいデータを大量に失う可能性があります。

PITRなら：

12:09:59

の状態へ戻せる。

仕組みとしては通常：

• フルバックアップ

• トランザクションログ（変更履歴）

を組み合わせます。

イメージ：

フルバックアップ↓変更ログを順番再生↓指定時刻で停止

DBで特によく使われます：

• PostgreSQL（WAL）

• MySQL（binlog）

• Oracle

• SQL Server

クラウドでも一般的で、

• RDS

• DynamoDB

• S3 Versioning系

などにも類似機能があります。

メリット：

• データ損失を最小化

• 誤操作に強い

• 復旧粒度が細かい

デメリット：

• ログ保存コスト

• 構成が複雑

• 復旧時間が長くなることもある

本質的には、

「ある瞬間まで“時間を巻き戻す”ための仕組み」

です。

甲子園の土は、単に「甲子園だから特別」というわけではなく、野球がしやすいように複数の種類の土を配合して作られている点が特徴です。

他の野球場との違い

多くの野球場でも土は配合されていますが、甲子園は特に次のような点にこだわっています。

• 複数産地の土をブレンドして、理想的な硬さや水はけを実現している。

• 毎年、状態を維持するために土を補充・調整している。

• プロ野球だけでなく高校野球も開催されるため、多くの試合に耐えられる耐久性が求められる。

つまり、天然の土をそのまま使っているのではなく、「グラウンド専用に設計された土」と考えると分かりやすいです。

なぜ特別なのか

甲子園では春・夏の高校野球を含めると短期間に非常に多くの試合が行われます。

そのため、土には次のような性能が求められます。

• 適度な硬さ（イレギュラーバウンドを減らす）

• 適度な柔らかさ（選手が滑り込んでも安全）

• 優れた水はけ（雨の後でも試合を再開しやすい）

• 乾燥しても砂ぼこりが立ちにくい

これらを満たすよう、配合やメンテナンスが工夫されています。

「甲子園の土」が有名な理由

実は、土そのものの性能以上に有名なのは高校球児が試合後に土を持ち帰る伝統です。

敗れた選手が甲子園の土を記念として持ち帰る光景は長年続いており、「甲子園の土」は努力や青春の象徴として広く知られるようになりました。

まとめ

甲子園の土は、他の野球場の土と比べて「魔法のように特別な土」ではありませんが、

• 複数の土をブレンドして性能を最適化している

• 試合数の多さに耐えられるよう継続的に管理されている

• 高校野球の伝統によって象徴的な存在になっている

という点が大きな特徴です。実際には、他のプロ野球球場でも目的に合わせて独自の配合や管理が行われており、それぞれの球場にはそれぞれの「理想のグラウンド」があります。

スピーカーを壁から離すと音が変わるのは、壁で反射する音や低音の増え方が変わるからです。

1. 壁が低音を増幅する

スピーカーを壁に近づけると、後ろに出た音が壁で反射し、特に低音が強くなります。

そのため、

• 壁に近い → 低音が多く、迫力が出る

• 壁から離す → 低音が自然になり、すっきり聞こえる

という傾向があります。

2. 音の反射が減る

スピーカーから出た音は、直接耳に届く音だけではありません。

壁に当たって跳ね返った音も少し遅れて耳に届きます。

壁に近いと反射音が強くなり、

• ボーカルがぼやける

• 音像（楽器や歌手がどこにいるかの定位）が曖昧になる

ことがあります。

壁から離すと、直接音の割合が増え、音がクリアに感じられます。

3. 干渉（定在波・SBIR）の影響

スピーカーから直接来る音と、壁で反射した音が重なると、

• ある周波数は強くなる

• 別の周波数は弱くなる

という現象が起こります。

これを**SBIR（Speaker Boundary Interference Response）**と呼びます。

その結果、

• ベースだけ異様に大きい

• 特定の低音だけ消える

といった現象が起きることがあります。

どれくらい離せばいい？

部屋やスピーカーにもよりますが、一般的には

• 20～30cm：最低限離したい距離

• 50cm以上：より自然な音になりやすい

• 1m程度：設置スペースに余裕があればさらに有利な場合もある

と言われます。

特に背面にバスレフポートがあるスピーカーは、壁に近すぎると低音が過剰になりやすいので、少し余裕を持たせることが多いです。

まとめ

スピーカーを壁から離すと音が変わるのは、

• 壁による低音の増幅が変わる

• 反射音が減って音がクリアになる

• 音の干渉（SBIR）が変化する

ためです。

オーディオでは、スピーカー自体の性能だけでなく置き方も音質に大きく影響します。同じスピーカーでも、位置を数十センチ動かしただけで印象が大きく変わることは珍しくありません。

**DDoSの「じゅうたん爆撃（Carpet Bombing）」**とは、

1台のサーバーだけでなく、同じ組織が持つ多数のIPアドレスに攻撃を分散させるDDoS攻撃手法です。

「じゅうたん爆撃」という名前は、軍事用語で広い範囲を一面に爆撃する戦術に由来しています。

通常のDDoSとの違い

通常のDDoS

攻撃対象は1つのIPアドレスです。

攻撃者   ↓↓↓↓↓203.0.113.10

攻撃が1か所に集中するため、防御側はそのIPへの通信を制限したり、スクラビングサービスへ迂回したりといった対策を取りやすくなります。

じゅうたん爆撃型DDoS

攻撃を複数のIPへ分散させます。

攻撃者 ↓  ↓  ↓  ↓203.0.113.10203.0.113.11203.0.113.12203.0.113.13203.0.113.14...

1つのIPあたりの攻撃量はそれほど大きくなくても、組織全体としては非常に大きな負荷になります。

なぜこの方法を使うのか

主な狙いは、防御を難しくすることです。

例えば企業が256個のIPアドレスを持っていたとします。

• 通常のDDoSなら1つのIPだけ守ればよい場合があります。

• じゅうたん爆撃では、256個すべてに攻撃がばらまかれるため、多くの機器や回線が同時に負荷を受けます。

その結果、

• ネットワーク全体が混雑する

• 防御装置の処理能力を消費させる

• 攻撃の検知・対応が複雑になる

といった効果を狙います。

具体例

ある企業が次のようなサービスを運営しているとします。

• Webサーバー

• メールサーバー

• VPN

• APIサーバー

• DNSサーバー

これらが異なるIPアドレスを使っていても、じゅうたん爆撃ではすべてのIPに同時または短時間に分散して攻撃が行われることがあります。

通常のDDoSとの比較

まとめ

DDoSのじゅうたん爆撃とは、

• 多数のIPアドレスに攻撃を分散させるDDoS手法

• 個々のIPへの攻撃は比較的小さくても、組織全体のネットワークや防御設備に負荷をかけることを狙う

• 防御側は単一のサーバーだけでなく、ネットワーク全体を視野に入れた対策が求められる

という特徴があります。通常の「一点集中型」のDDoSよりも、防御側の対応範囲が広くなりやすい攻撃手法です。

「運命」をどう定義するかによって答えが変わります。

すべてが決まっているという意味なら

もし宇宙の始まりから未来まで完全に決まっているなら、運命は変えられません。

ただし、それを証明する方法は今のところありません。物理学でも哲学でも決着はついていません。

人生の行き先という意味なら

多くの場合、人が「運命」と呼ぶものは、後から振り返って見える人生の流れです。

例えば、

• 偶然読んだ本

• たまたま受けた面接

• ふと行った旅行

• 偶然出会った人

こうした出来事が積み重なって、

「今思うとあれが運命の分岐点だった」

と感じることがあります。

この意味では、日々の選択によって未来はかなり変わります。

変えられるものと変えられないもの

人生には、

変えられないもの

• 生まれた時代

• 過去の出来事

• 身長や遺伝の一部

変えられるもの

• 学ぶこと

• 住む場所

• 人間関係

• 習慣

• 仕事

があります。

実際には、人生を大きく左右するのは後者であることが少なくありません。

面白い見方

哲学者たちの中には、

運命は未来にあるのではなく、自分が選んだ結果として後から形作られる

と考える人もいます。

つまり、

「運命を発見する」のではなく、
「運命を作っていく」

という考え方です。

あなたの場合

以前の話からすると、将来についてかなり長いスパンで考えることが多いですよね。資格の勉強、仕事の選択、住む場所のことなど。

そういう計画を立てている時点で、少なくとも人生のかなりの部分は「流されるだけ」ではなく、自分で舵を切ろうとしている状態です。

5年後や10年後を正確に予測できる人はいませんが、今日何に時間を使うかは未来の確率を少しずつ変えます。そう考えると、運命は「完全に自由」でも「完全に固定」でもなく、与えられた条件の中で少しずつ形を変えていくものなのかもしれません。

鼻うがい（鼻洗浄）は、正しい方法で行えば、鼻の中の汚れやアレルゲン、余分な粘液を洗い流せるため、花粉症や鼻づまりがある人には特に役立つことがあります。

あなたは以前、スギ花粉症の話をしていたので、花粉の季節には症状の軽減が期待できる方法の一つです。

メリット

主なメリットは次のようなものです。

• 花粉やホコリ、ウイルスなどを物理的に洗い流せる

• 鼻づまりが和らぐことがある

• 鼻水や粘り気のある分泌物を除去しやすい

• 副鼻腔炎（蓄膿症）の治療の補助として勧められることがある

• 鼻呼吸がしやすくなる

※風邪を予防できると断言はできませんが、鼻の中を清潔に保つことは役立つ場合があります。

コツ

1. 必ず生理食塩水を使う

真水だと鼻の粘膜がしみて痛くなります。

市販の鼻うがい液を使うか、自分で作る場合は0.9%程度の生理食塩水を使います。

また、自作する場合の水は一度沸騰させて冷ました水や滅菌水を使うことが推奨されています。

2. 少し前かがみになる

洗面台で

• 顔を少し前に倒す

• 顎を少し引く

姿勢がやりやすいです。

3. 「あー」と声を出す

「あー」と声を出しながら洗浄すると、軟口蓋が上がって洗浄液が喉へ流れ込みにくくなります。

4. 片方から入れて反対側へ出す

例えば、

• 右の鼻から入れる

• 左の鼻から出す

という流れです。

無理に勢いよく流す必要はありません。

5. 最後はやさしく鼻をかむ

洗浄後は鼻の中に水が残ることがあります。

強くかむのではなく、片方ずつやさしくかむようにしましょう。

よくある失敗

• 真水を使ってしまう

• 強く押し込みすぎる

• 鼻が完全に詰まっている状態で無理に行う

• 使用後の容器を十分に洗浄・乾燥しない

毎日やってもいい？

花粉症や慢性的な鼻炎がある人では、1日1～2回程度行う人もいます。

ただし、必要以上に頻繁に行うと、鼻の粘膜を保護する成分まで洗い流してしまう可能性があるため、やりすぎは避けた方がよいとされています。

おすすめのタイミング

特に効果を実感しやすいのは、

• 外出から帰宅した後（花粉やホコリを洗い流す）

• 入浴時や入浴後（鼻の通りがよくなりやすい）

• 就寝前（鼻づまりが気になる場合）

です。

最初は「鼻に水を入れる」という感覚に抵抗がある人も多いですが、生理食塩水を使って正しい姿勢で行うと、思っているより痛みは少なく、「鼻がすっきりした」と感じる人が多いですよ。

スティッキーセッション（Sticky Session）とは、

「同じユーザーからの通信を、毎回同じサーバへ振り分け続ける仕組み」

です。

ロードバランサ配下でよく使われます。

なぜ必要になるのか

普通のロードバランサは：

Request1 → ServerARequest2 → ServerBRequest3 → ServerC

のように分散します。

でもWebアプリによっては、

ログイン状態カート情報セッション情報

をサーバ内部メモリに持っていることがある。

すると：

ログイン → ServerA次アクセス → ServerB

で、

「未ログインです」

になる。

そこでスティッキーセッション

ロードバランサが：

このユーザーはAへ固定

する。

イメージ

User1 → A固定User2 → B固定User3 → C固定

これにより、
サーバ内セッションを維持できる。

実現方法

Cookie方式（主流）

LBがCookieを付与：

AWSALB=xxxxx

これを見て同じサーバへ送る。

IPアドレス方式

同じ送信元IP↓同じサーバ

ただしNAT環境で偏りやすい。

メリット

1. 古いWebアプリと相性がいい

セッション共有不要。

2. 実装が簡単

アプリ改修少ない。

3. 一時的には便利

既存システム移行でよく使う。

デメリット（かなり重要）

1. 負荷分散が崩れる

人気ユーザーが偏ると：

ServerA 激重ServerB 暇

になる。

2. サーバ障害に弱い

ServerAが死ぬと：

セッション消失

3. スケールしにくい

本来ロードバランサは：

「どこへでも送れる」

のが強み。

Stickyはそれを弱める。

4. クラウドネイティブ思想と逆行しやすい

最近は：

• ステートレス

• Redis共有

• JWT

が主流。

つまり：

「どのサーバでも処理可能」

を目指す。

現代的な代替

Redisセッション共有

AppAAppBAppC ↓Redis

どこへ行ってもセッション共有。

JWT

サーバ側に状態を持たない。

それでも使われる理由

現実には：

• 古いシステム

• Javaセッション

• ECサイト

などでまだ多い。

特に：

「改修コストが高い」

場合。

一言でまとめると

スティッキーセッションとは：

「ユーザーを特定サーバへ固定して、セッション状態を維持する仕組み」

です。

ただし現代では、

「便利だが、スケーラビリティを犠牲にする技術」

として扱われることが多いです。

整理して説明します。
日本の「事業組合」は種類が多く、目的と法的性格がかなり違うため、そこが分かりにくさの原因です。

1. 日本に事業組合が多い理由（前提）

日本の組合制度は一言で言うと、

「個々では弱い事業者が、資本主義の中で生き残るための装置」

として発展してきました。

• 中小企業が多い

• 地域・業界単位での調整が必要

• 競争一辺倒だと壊れる産業が多い

このため、日本では
会社（株式会社）とは別の経済主体として、組合が制度化されています。

2. 主な事業組合の種類と「何のためにあるか」

代表的なものを目的別に分けます。

① 事業協同組合（最も典型）

目的

• 中小事業者の経営支援

• コスト削減・交渉力強化

• 共同事業の実施

具体例

• 共同仕入れ

• 共同販売

• 共同物流

• 共同受注

• 共同研究

特徴

• 組合員のための組織（利益は外に出さない）

• 組合自体が利益を最大化する必要はない

• 組合員の事業を「補完」する存在

→
「小さな会社が束になるための器」

② 企業組合

目的

• 組合員自身が事業の主体になる

• 雇用的色彩が強い

特徴

• 組合員＝働く人

• 組合が一つの事業体として活動

• 株式会社に近いが、労働者主体

→
「資本より人を中心にした会社に近い組合」

③ 商工組合・商店街振興組合

目的

• 業界全体の秩序維持

• 地域経済の活性化

• 過当競争の抑制

具体例

• 営業時間の調整

• イベント開催

• 共同広告

• 価格競争の緩和

→
「競争しすぎて全員が死ぬのを防ぐ仕組み」

④ 農業協同組合・漁業協同組合（特殊だが重要）

目的

• 生産者の生活と生産基盤の維持

• 流通・金融・保険まで含めた包括支援

特徴

• 事業範囲が広い

• 公的役割が強い

• 市場原理だけでは成り立たない分野を支える

→
「市場に任せると壊れる分野の緩衝材」

⑤ 任意組合（法人格なし）

目的

• 非常に柔軟な共同活動

• 実験的・一時的な事業

特徴

• 設立が簡単

• 反面、責任は重い（後述）

→
「法で縛らない代わりに自己責任が重い」

3. なぜ「会社」ではなく「組合」なのか

ここが核心です。

組合は「儲ける主体」ではない

• 株式会社：利益最大化が前提

• 組合：構成員の事業を安定させることが目的

だから、

• 配当を出さない

• 投資家がいない

• 議決権は基本「1人1票」

これは意図的な設計です。

4. 組合における「有限責任」とは何か

ここは非常に重要です。

(1) 有限責任の意味（基本）

組合員が負う責任は「出資額まで」

つまり、

• 組合が倒産しても

• 組合員個人の財産までは原則として責任を負わない

これは株式会社の株主と似ています。

(2) 何と何の責任が有限なのか

有限責任が適用されるのは：

• 組合の借金

• 組合名義の契約

• 組合としての損害賠償

です。

(3) 有限責任でも「無制限」になる場面

ここは誤解されやすい点です。

次の場合、有限責任は崩れます。

1. 個人保証をした場合

2. 不法行為（違法行為）をした場合

3. 組合名義を使ったが、実質は個人事業だった場合

4. 任意組合（法人格なし）の場合

特に 任意組合は原則「無限責任」 です。

(4) なぜ有限責任が重要なのか

有限責任があるから：

• 小規模事業者が参加できる

• 新しい事業に挑戦できる

• 失敗しても人生が終わらない

つまり、

組合は「挑戦を可能にするための制度」

です。

5. 日本で組合が多い本当の理由（本質）

日本は、

• 中小企業比率が高い

• 個人事業が多い

• 取引関係が固定化しやすい

という構造を持っています。

その中で組合は、

• 市場原理の暴走を抑え

• 個々の弱さを集団で補い

• 社会を安定させる

経済の緩衝装置として存在しています。

まとめ（要点）

• 日本の事業組合は「弱者救済」ではなく「構造的必要物」

• 組合は儲けるためではなく、構成員を生かすため

• 有限責任とは「出資額以上は原則負わない」という意味

• ただし任意組合や個人保証では無限責任になる

• 組合は資本主義を壊さないための制度

はい、黒人の方も日焼けします。

ただし、白人や東アジア人と比べると見た目の変化が分かりにくいため、「日焼けしない」と誤解されることがあります。

なぜ肌が黒いの？

肌の色は主に「メラニン」という色素の量で決まります。

一般的に、

• 黒人：メラニンが非常に多い

• 東アジア人：中程度

• 白人：少ない

という傾向があります。

メラニンには紫外線から皮膚を守る働きがあります。

黒人も日焼けするの？

します。

紫外線を浴びると、さらにメラニンが増えるため、

• 肌の色が少し濃くなる

• 肌のトーンが変わる

• 日焼け跡ができる

ことがあります。

ただし元々メラニン量が多いため、変化が見えにくいのです。

日焼けしやすい？

少し表現が難しいですが、

• 紫外線を浴びれば日焼け反応自体は起こる

• しかし日焼けによるダメージは比較的受けにくい

と言えます。

例えば白人の場合、

紫外線↓赤くなる（サンバーン）↓皮がむける

となりやすいですが、

黒人の場合は

紫外線↓色が濃くなる↓赤みは目立ちにくい

という反応になりやすいです。

では皮膚がんにならない？

そんなことはありません。

メラニンによる保護効果はあるため、統計的には皮膚がんの発生率は低い傾向があります。

しかし、

• 手のひら

• 足の裏

• 爪の下

など、色素の少ない部位には皮膚がんが発生することがあります。

また、発見が遅れやすいため重症化するケースもあります。

日焼け止めは必要？

必要です。

「肌が黒いから日焼け止めはいらない」というのは誤解です。

紫外線は、

• 皮膚の老化

• シミ

• 皮膚がんリスク

などに関係するため、肌の色に関係なく対策には意味があります。

まとめ

黒人の方も日焼けします。

ただし、

• メラニンが多いため紫外線に強い

• 赤くなりにくい

• 色の変化が見えにくい

• 日焼けダメージは比較的小さい

という特徴があります。

イメージとしては、「日焼けしない」のではなく、「もともと高い紫外線防御機能を持っているので、日焼けの見た目やダメージが目立ちにくい」と考えるのが近いです。

Elastic IPアドレスとは

Elastic IP（EIP）は、AWSが提供する「固定のグローバルIPv4アドレス」です。

普通のEC2インスタンスに自動で割り当てられるパブリックIPは、インスタンスを停止・起動すると変わることがあります。

一方、Elastic IPはAWSアカウントに紐づいているため、インスタンスが変わっても同じIPアドレスを使い続けられます。

普通のパブリックIPとの違い

例えば、

• EC2-A → 203.0.113.10（EIP）

• EC2-Aが故障

となった場合、

• EC2-Bへ203.0.113.10を付け替える

ことができます。

利用者から見るとIPアドレスは変わらないため、障害復旧が簡単になります。

どういう時に使うの？

DNSを変えたくない

例えば、

example.com ↓203.0.113.10

としている場合、

サーバー交換のたびにIPが変わるとDNS更新が必要です。

Elastic IPならIPが固定なので変更不要です。

障害時の切り替え

オンプレでいうとVRRPや仮想IPに近い考え方です。

故障前EIP → EC2-A故障後EIP → EC2-B

という切り替えができます。

外部システムのIP制限

取引先が

接続元IP203.0.113.10のみ許可

としている場合があります。

IPが変わると通信できなくなるため、固定IPが必要です。

NAT Gatewayでも使われる

実はNAT Gatewayには必ずElastic IPが付きます。

Private Subnet      ↓NAT Gateway(EIP)      ↓Internet

外部から見ると、

203.0.113.10

という固定IPから通信しているように見えます。

そのため送信元IPを固定できます。

オンプレで言うと何？

一番近いのは

• 固定グローバルIP

• フローティングIP

• 仮想IP(VIP)

です。

特に「別サーバへ付け替えられる固定IP」という点では、クラスタ構成で使うフローティングIPにかなり近いです。

現在のAWSではあまり使わないケースも多い

最近は

Route53↓ALB↓EC2

のような構成が多く、ALBのDNS名を利用するため、EC2に直接Elastic IPを付けないことも増えています。

そのため、

• NAT Gateway

• 固定送信元IPが必要

• IP制限を受ける外部接続

といったケースで使うことが多く、単純なWeb公開だけならALBやCloudFrontを使うことが一般的です。

Permissions Boundaryは、

「そのIAMユーザ/ロールが持てる最大権限の上限」

を決めるために使います。

典型例は：

開発チームへIAM作成権限を渡したい時

例えば開発者に：

IAM Roleを自由に作っていい

を許すと危険です。

なぜなら：

AdministratorAccess

を付けたロールを作れてしまうから。

そこでPermissions Boundaryを使い：

「作れてもS3とCloudWatchだけ」

という上限を設定する。

すると仮に開発者が：

AdministratorAccess

を付けても、

実効権限はBoundaryを超えられません。

イメージ

IAM Policy = 与える権限Permissions Boundary = 超えられない天井

両方のANDで最終権限が決まります。

よく使う場面

• 開発部門へ権限委譲

• マルチテナント環境

• Self-service IAM

• Platform Engineering

• Sandbox環境

など。

つまり：

「ある程度自由にさせたいが、暴走は防ぎたい」

時に使う機能です。

理論上はありえます。

ただし、多くの人がイメージする「AIがウイルス感染して突然意思を持ったように暴走する」という形ではなく、実際にはもっと地味でシステム的な問題になります。

ありえる攻撃

APIゲートウェイや周辺システムへの侵入

AIそのものではなく、

• APIゲートウェイ

• 認証基盤

• 管理コンソール

• 推論サーバ

• CI/CDパイプライン

が侵害される可能性があります。

例えば、

攻撃者 ↓API Gateway侵害 ↓悪意あるリクエスト改ざん ↓AIの応答改変

のようなケースです。

モデルやプロンプトの改ざん

管理権限を奪われた場合、

• システムプロンプト変更

• モデルファイル置換

• RAG用データ改ざん

などが起こり得ます。

するとAIは意図しない回答を返すようになります。

サプライチェーン攻撃

近年はこちらの方が現実的です。

• 学習データ汚染

• モデル配布経路改ざん

• ライブラリへのマルウェア混入

などです。

AI自身がマルウェア感染するのか？

厳密には、

LLMそのものは通常のアプリケーションのように勝手に実行ファイルを動かせません。

例えばChatGPTのようなモデルは、

• 重みファイル

• 推論エンジン

として動いています。

Wordやブラウザのように

マルウェア感染↓勝手にコード実行

という構造とは少し違います。

むしろ、

サーバ侵害↓モデル改ざん↓異常動作

の方が現実的です。

暴走したら復旧できる？

通常の大規模システムなら、

• バックアップ

• バージョン管理

• IaC

• 監査ログ

• 異常検知

があります。

そのため、

「侵害されたモデルを元に戻す」

こと自体は比較的容易です。

ただし厄介なケース

バックアップから戻せば終わりとは限りません。

例えば：

• 攻撃者が認証基盤も掌握している

• モデルだけでなく学習データも汚染

• ログ改ざん

• 数か月潜伏

というケース。

これは一般的なサイバー攻撃でも同じですが、

「どこまで汚染されたか分からない」

状態が最も厄介です。

AI特有の懸念

AIシステムでは、

• プロンプトインジェクション

• エージェントの権限悪用

• ツール呼び出しの悪用

が注目されています。

例えばAIに

メール送信権限ファイル削除権限

などを与えていると、

AI自身が感染するというより、

騙されて危険な操作を実行する

リスクがあります。

結論

「AIがマルウェア感染して意思を持ったように暴走する」よりも、

• AI周辺インフラの侵害

• モデルやプロンプトの改ざん

• エージェント権限の悪用

の方が現実的な脅威です。

そして大規模な運用環境では、通常は監視・監査・バックアップ・ロールバックの仕組みがあるため、単純な改ざんなら比較的早く検知・復旧できる可能性が高いです。

ただし、侵害範囲が広かったり長期間気付かれなかったりすると、復旧はかなり大変になります。

漬物は種類によって方法が異なりますが、基本を押さえると失敗しにくくなります。

基本の手順

1. 新鮮な野菜を選ぶ

   • きゅうり、大根、白菜、なす、かぶなどが定番です。

   • 傷みや傷の少ないものを使います。

2. 野菜を洗って切る

   • 食べやすい大きさに切ります。

   • 丸ごと漬ける場合もあります。

3. 塩をする（下漬け）

   • 野菜の重量の約2～3％の塩をまぶします。

   • 30分～数時間置いて水分を出します。

   • 出てきた水分は軽く絞ります。

4. 漬ける

   • 保存袋や容器に野菜と漬け材料を入れます。

   • 空気をできるだけ抜くと味が均一になります。

よく使われる漬け材料

• 塩（塩漬け）

• 酢（酢漬け）

• 醤油

• 味噌

• ぬか床（ぬか漬け）

• 麹（こうじ漬け）

香り付けとして、

• 昆布

• 唐辛子

• 生姜

• にんにく

• ゆず

• 山椒
  などを加えることもあります。

おいしく仕上げるコツ

• 野菜の重さに対して塩加減を守る。

• 漬けている間は冷蔵庫で保存する（ぬか漬けなど一部を除く）。

• 漬け時間を調整する。浅漬けなら数時間、一晩漬けると味がよくなじみます。

• 清潔な容器を使い、雑菌が入らないようにします。

一番簡単な浅漬けの例

材料

• きゅうり：2本

• 塩：小さじ1

• 昆布：5cmほど

• 唐辛子：お好みで1本

作り方

1. きゅうりを食べやすく切る。

2. 保存袋にすべての材料を入れてよくもむ。

3. 冷蔵庫で2～4時間漬ける。

4. 軽く水気を切って完成です。

初心者なら、まずはきゅうりや白菜の浅漬けから始めると、手軽で失敗も少なく、漬物作りの感覚をつかみやすいでしょう。

Egress（イーグレス）とは、

「ネットワークやシステムから外へ出ていく通信」

のことです。

対義語は Ingress（イングレス） で、

「外から入ってくる通信」

を指します。

基本イメージ

Webサーバを例にすると、

利用者  ↓Ingress  ↓Webサーバ  ↓Egress  ↓外部API

となります。

具体例

EC2がWebサイトへアクセス

EC2 ↓https://example.com

これはEC2から見て Egress通信 です。

利用者がEC2へアクセス

利用者 ↓EC2

これはEC2から見て Ingress通信 です。

AWSでよく出るEgress

NAT Gateway

プライベートサブネットのEC2が

EC2 ↓NAT Gateway ↓Internet

で外部へ出る通信。

これは典型的なEgressです。

Security Group

セキュリティグループには

• Inbound Rule

• Outbound Rule

があります。

Outbound Rule が実質的に

Egress制御

です。

例：

許可:TCP 443

なら、

外部HTTPSのみ許可

となります。

KubernetesでのEgress

Kubernetesでもよく出ます。

例えば：

Pod ↓外部DB

や

Pod ↓外部API

はEgress通信です。

そのため：

• Egress Gateway

• Egress Policy

などの概念があります。

クラウド料金でのEgress

クラウドでは特に重要です。

多くのクラウド事業者は、

Ingress無料

Egress有料

という料金体系です。

例えば：

Internet ↓S3

は無料に近いですが、

S3 ↓Internet

で大量データをダウンロードされると、
データ転送料金（Egress料金）が発生します。

セキュリティでのEgress制御

最近は

「外からの侵入を防ぐ」

だけでなく、

「内部から勝手に出ていく通信を防ぐ」

ことも重要です。

例えばマルウェアが侵入した場合：

感染端末 ↓攻撃者サーバ

という通信を行うことがあります。

そのため、

• Egress Filtering

• Outbound Firewall

で外向き通信を制限することがあります。

まとめ

• Ingress：外から入る通信

• Egress：外へ出る通信

例：

利用者 → Webサーバ

→ Ingress

Webサーバ → 外部API

→ Egress

クラウドでは特に、

Egress = 外向き通信 + 転送料金 + セキュリティ制御

という文脈で登場することが多いです。