徒然

ルツの概要

人物像

モアブ人女性で、イスラエル人マロンと結婚
夫、義父、義兄の死後、義母ナオミと共にユダへ移住
親戚ボアズと結婚し、ダビデ王の曽祖母となる
マタイによる福音書のイエスの系図に登場する5人の女性の一人

ルツ記について

ペルシャ時代（紀元前550-330年）にヘブライ語で執筆
学者間で歴史小説か歴史物語かの見解が分かれる

物語の流れ

モアブでの出来事

飢饉のため、エリメレク一家がベツレヘムからモアブへ移住
エリメレク死去後、息子マロンとキルヨンがルツとオルパと結婚
約10年後、二人の息子も死去

ユダへの帰還

ナオミが故郷へ戻ることを決意
オルパは実家へ、ルツはナオミに同行
ルツの有名な言葉：「あなたの行かれる所に私も行き、あなたの民は私の民、あなたの神は私の神です」

ボアズとの出会い

ベツレヘムで大麦の収穫期に到着
ルツがボアズの畑で落ち穂拾い
ボアズがルツの忠実さを認め、保護を約束

結婚と子孫

ナオミの助言により、ルツが脱穀場でボアズに保護を求める
ボアズが土地を買い戻し、ルツと結婚
息子オベドが誕生（エッサイの父、ダビデ王の祖父）

宗教的解釈

ユダヤ教の視点

ルツの親切心は、モアブ族の一般的な評価とは対照的
ユダヤ教への改宗者の原型として位置づけられる
ルツ・ラバによれば、ルツはモアブ王エグロンの娘

キリスト教の視点

愛ある親切（ヘセド）の模範
ナオミへの忠誠、落ち穂拾いの選択、結婚への同意などに現れる
ルーテル教会では7月16日に記念

ルツの墓

ヘブロンに伝統的な埋葬地
シャブオット（ルツ記朗読の祭日）に多くの参拝者が訪れる

🕒 脂質は「昼食」で摂るのが最も理想的

脂質を摂るタイミングは、**昼食（12〜14時）**が最も適しているとされています。
これは「時間栄養学」という、食べるタイミングと健康の関係を研究する分野の知見によるものです。

☀️ 昼食に脂質を摂るメリット

1. 午後に必要なエネルギーとして使われる

昼食で摂った脂質は、午後の活動エネルギーとして利用されやすく、
脂肪として蓄積されにくいという特徴があります。

2. BMAL1（ビーマルワン）が最も少ない時間帯

BMAL1は体内時計に関わる遺伝子のひとつで、
脂肪合成を促進し脂肪分解を抑える働きがあります。
日中（特に14〜16時）にBMAL1の量が最小となるため、
脂肪がつきにくい時間帯と言えます。

➡️ 揚げ物など高脂肪食を食べるなら、夜より昼！

🌙 避けたいのは「夜の脂質」

❌ 夕食（特に21時以降）に脂質を摂るデメリット

1. BMAL1が最も活発

BMAL1は22時〜翌2時にピークに達します。
この時間帯に脂質を摂ると、脂肪として蓄積されやすい状態になります。

2. エネルギー消費が低い

夜は活動量が少なく、体が休息モードへ。
摂取したエネルギーが使われず、脂肪蓄積につながります。

3. 睡眠の質を下げる可能性

脂質は消化に時間がかかるため、寝る直前に食べると胃が働き続け、
睡眠の質が落ちることがあります。

🍽️ 食事の時間帯と脂質の摂り方のポイント

食事	理想的な時間帯	脂質の摂り方・ポイント
朝食	起床後1〜2時間以内	脂質は脂肪になりにくいが、量は控えめに。DHA/EPAなど良質な油を利用。主食＋タンパク質を中心に。
昼食	朝食から約5時間後	高脂肪食を食べるなら最適な時間。午後のエネルギーとして有効利用。
夕食	就寝の3時間前まで（遅くとも20時）	脂質と炭水化物は控えめ。消化が良いタンパク質（魚・鶏むね肉）＋食物繊維中心に。

✔️ まとめ

高脂肪食は 昼食に集中
夜は脂質を控えて 軽め・消化の良い食事
BMAL1の働きを意識すると、体脂肪管理がしやすくなる

✅ `.mjs` の意味

Module JavaScript の略
ES Modules（import/export を使うモジュール方式）で書かれた JS ファイルであることを示す

ファイルの拡張子 .mjs は、ECMAScript Modules (ES Modules / ESM) として扱われる JavaScript ファイルであることを明示するための拡張子です。

主に Node.js 環境において、従来の読み込み方式（CommonJS）と区別するために使われます。

主な特徴とポイント

ES Modules (ESM) の強制
- Node.js では通常、.js ファイルは CommonJS（require / module.exports を使う方式）として扱われます。
- .mjs 拡張子を使うと、そのファイルは強制的に ES Modules（import / export を使う方式）として扱われます。

構文の違い

CommonJS (.js のデフォルト):

const fs = require('fs');
module.exports = function() { ... };

ES Modules (.mjs):

import fs from 'fs';
export function myList() { ... };

Strict Mode（厳格モード）がデフォルト
- .mjs ファイル内では、自動的に 'use strict'; が適用された状態になります（変数の宣言漏れがエラーになるなど、安全なコードになります）。

なぜ作られたのか？

JavaScript の標準仕様（ES2015/ES6）でモジュール機能（import/export）が決まりましたが、Node.js にはそれ以前から存在する独自のモジュール機能（CommonJS）がありました。

エノクについての整理

名前と表記

ヘブライ語: חנוך, חֲנוֹךְ
ギリシア語: Ενώχ (エノフ)
アラビア語: إدريس (イドリース)
英語: Enoch (イーノック、イノック)
意味: 「従う者」

系譜

父: ヤレド(イエレド)
子: メトセラ
子孫: ノアの曽祖父にあたる ※カインの息子のエノクとは別人

各文献での記述

創世記

エノクという名前は2回登場:

4章17節: カインの子エノク(別人)
- カインが建てた町の名前の由来
5章21-24節: ヤレドの子エノク(本人)
- 65歳でメトシェラをもうける
- 365年生きた
- 特徴的な記述: 「神とともに歩み、神が彼を取られたので、いなくなった」
- 通常の死の記述がない

エノク書

天使エロヒムによって天に上げられた
天使メタトロンに変容させられた
エチオピア正教では旧約聖書の正典に含まれる

ヨベル書

誕生: 第11ヨベル第5年周第4
母: バラカ(父は天使ラスイエル)
妻: エダニ(父は天使ダネル)
結婚: 第12ヨベル第7年周
子の誕生: 第6年にメトシェラが生まれる

ユダの手紙(新約聖書)

14-15節で『エノク書』から最後の審判に関する預言を引用
初期キリスト教徒も『エノク書』を読んでいた証拠

コーラン(イスラム教)

「マルヤム」の章に預言者イドリースが登場
神によって高い所に上げられたと記述
このイドリースをエノクと同一視することがある

重要なポイント

エノクが後世で重視される理由は、通常の死の記述がなく「神が連れて行った」という特殊な表現がされているため、様々な宗教文献で言及される存在となった。

JWT（JSON Web Token）とは、
ユーザーの認証情報や属性情報などを安全にやり取りするための、コンパクトなトークン形式のことです。
Webアプリ・API・モバイルアプリなどで幅広く使われています。

◆ JWTの基本構造

JWTは「ドット」で区切られた 3つの部分 から構成されます：

xxxxx.yyyyy.zzzzz

Header（ヘッダー）
・署名方式などのメタ情報
・例：{"alg": "HS256", "typ": "JWT"}
Payload（ペイロード）
・ユーザーIDや有効期限などの「クレーム（claims：情報）」
・例：{"sub": "12345", "name": "seiichi", "exp": 1735640000}
Signature（署名）
・偽造されていないことを保証するための署名
・サーバー側が秘密鍵で作成する

◆ JWTがよく使われる理由（メリット）

✔ サーバーレスでセッション管理できる

サーバーでセッション情報を持つ必要がなく、トークン自体に必要な情報が入っているため、
負荷が軽い。

✔ API間の認証に向いている

フロントエンド（ブラウザ）→バックエンドAPI
モバイルアプリ → サーバー
マイクロサービス間など
どこでも使える。

✔ JSON形式で扱いやすい

扱いやすく、構造がシンプル。

◆ JWTの注意点（デメリット）

⚠ 一度発行したら無効化しにくい

セッションのようにサーバー側で即無効化できない。
→ 対策：短い有効期限（exp） を設定し、リフレッシュトークンを使う。

⚠ ペイロードは暗号化されていない

Base64URLエンコードされているだけで、誰でも読める。
機密情報（パスワード・カード番号など）を入れてはいけない。

◆ どんな場面で使われる？

Webログイン（SPA + API）
モバイルアプリの認証
API Gateway や Auth0 などのIDサービス
マイクロサービス間通信

PKCE（Proof Key for Code Exchange：ピクシー）は、
OAuth2 / OIDC の認可コードフローを“より安全にする”ための仕組みです。

特に SPA（React / Vue / Next.js）、モバイルアプリ、デスクトップアプリのように
“クライアントシークレットを安全に隠せない環境” で必須の保護方式です。

✅ PKCE を一言で言うと？

「ログイン後に Authorization Code を盗まれても、攻撃者は交換できないようにする仕組み」

🧠 OAuth2 の弱点を補うために生まれた

通常の「Authorization Code Flow」は
authorization_code を持っていれば 誰でも トークン交換できてしまいます。

→ 攻撃者が URL からコードを盗むと、Access Token を横取りできる危険。

PKCE はこの弱点を補強します。

🔐 PKCE の仕組み（ざっくり）

PKCE では、次の2つを使います：

code_verifier（長いランダム文字列）
code_challenge（code_verifier を SHA-256 変換したもの）

code_verifier  --SHA256→  code_challenge

フローは次のように進みます：

🔍 PKCE フロー図（簡易）

① クライアントが code_verifier（秘密）を生成する

例：

s8sj3hfkDs8sdfk2...

② その SHA256 版を code_challenge として Auth0 に送る

code_challenge = SHA256(code_verifier)

③ ユーザーが Auth0 ログイン

→ ログイン成功後、Auth0 は authorization_code をアプリに返す

RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、
「ユーザー個人に権限を与えるのではなく、“役割（ロール）”に権限をまとめて管理する仕組み」 です。

✅ 一言でいうと

「どのユーザーが何をできるか」を “役割” を介して管理するアクセス制御モデル

🔍 RBAC の基本構造

RBAC は 3つの要素で成り立ちます：

User（ユーザー）
→ 実際にシステムを使う人
Role（ロール）
→ 権限のグループ（例：管理者、一般ユーザー、閲覧者）
Permission（権限）
→ 実行できる操作（例：閲覧、編集、削除）

そして

User → Role → Permission

という 紐づけの“中間にロール”が入るのがポイントです。

🧱 RBAC がない場合（権限を直接付けると…）

例：

ユーザーA → 編集権限
ユーザーB → 閲覧権限
ユーザーC → 編集＋削除
→ ユーザーごとに権限管理が複雑になる
→ 大人数の組織では破綻しやすい

🧱 RBAC の場合（ロールを使う）

例：

■ ロール

admin（閲覧・編集・削除）
editor（閲覧・編集）
viewer（閲覧のみ）

■ ユーザー

ユーザーA → editor
ユーザーB → viewer
ユーザーC → admin

クレジットカードの締め日と支払日について

基本的な仕組み

締め日 利用額が集計され、支払う金額が確定する日。この日までの利用分が次回の支払い対象となります。

支払日（引き落とし日） 締め日で確定した金額が口座から引き落とされる日。土日・祝日の場合は翌営業日に引き落とされます。

一般的なパターン

多くのカード会社では、以下のいずれかを採用しています。

パターン1:毎月15日締め・翌月10日払い

例:12月16日〜1月15日の利用分 → 2月10日に引き落とし

パターン2:毎月末日締め・翌月26日または27日払い

例:1月1日〜1月31日の利用分 → 2月26日または27日に引き落とし

💡 ポイント:締め日直後に高額な買い物をすると、支払いを翌々月に先延ばしできます。

確認が必要な理由

以下の点でカードごとに異なる場合があります:

カードの種類:同じ会社でもグレードやブランドで異なることがある
キャッシング:ショッピングとキャッシングで締め日・支払日が異なる場合がある
選択制:カード会社によっては複数のパターンから選択できる

確認方法

お持ちのカードの規約、ウェブサイト、または利用明細でご確認ください。

Auth0のシステムAPIとは

Auth0には主に2種類のAPIがあり、それぞれ異なる目的で使用されます。

1. Management API

Auth0テナント内の設定や管理操作をプログラム的に実行できるAPIです。Auth0ダッシュボードで行える操作の多くをプログラムから実行できます。

主な機能

ユーザーやアプリケーションの管理、コネクションの設定、アクセス制御などを行うことができます。具体的には:

ユーザーの作成・更新・削除・検索
アプリケーションの設定変更
ログイン画面のカスタマイズ
ロールや権限の管理
接続設定の管理

利用方法

Management APIを使用するには、まずアクセストークンを取得する必要があり、これはAPIを使うための証明書のようなものです。

基本的な流れ:

Machine to Machine（M2M）アプリケーションを作成
アクセストークンを取得
トークンを使ってAPIリクエストを実行

注意点

Management APIには一定時間で実行可能な回数に制限があり、特に継続的に秒間16回を超えるAPI実行が必要な場合はPrivate Cloud契約が必須となります。

2. Authentication API

Management APIはヘッダーにトークンをセットする必要がありますが、Authentication APIはトークン不要です。こちらは主にユーザー認証に関連する操作を行います。

ログイン・ログアウト
パスワードリセット
ユーザー登録

使い分け

管理操作（ユーザー管理、設定変更など）→ Management API
認証操作（ログイン、サインアップなど）→ Authentication API

【公式ブログ】Protecting REST APIs Behind Amazon API Gateway Using Okta https://auth0.com/blog/protecting-rest-apis-behind-aws-api-gateway/

Webアプリにバックエンドの APIサーバーが必要になる主な理由 は、大きく分けて セキュリティ・データ管理・ビジネスロジック・外部サービス連携 の4つです。わかりやすく整理して解説します。

✅ Webアプリにバックエンド API サーバーが必要になる理由

1. セキュリティを守るため（最重要）

フロントエンド（ブラウザ側）はユーザーに公開されるため、秘密情報を置けない し、信頼できない環境 です。

バックエンドはサーバー側で公開されないため：

認証（Auth0 など）
データベース接続情報（DBパスワード）
APIキー（Stripe、SendGridなど）
ビジネスロジック

これら “秘密にすべき処理” を安全に実行できます。

🔒 バックエンドがないと誰でも勝手にDBを改ざんできてしまう
→ だから必須。

2. データベースに直接アクセスさせないため

ブラウザからDBに直接つなぐと：

DBのパスワードが漏れる
SQLを書き換えてデータを破壊される
全データがダウンロードされる

バックエンドAPIは DBとフロントの間のゲートキーパー です。

[ブラウザ] → (安全なリクエスト) → [APIサーバー] → DB

3. ビジネスロジックを隠すため

例：

「在庫が何個以上なら特別割引」
「このユーザーの権限なら編集可能」

これをフロントだけで実装すると、ユーザー側で書き換えられます。

バックエンドで実行することで：

改ざんできない
共通のロジックとして複数サービスから使える

4. 外部サービスとの連携（トークン・秘密鍵を安全に扱う）

Stripe, PayPal, AWS S3 などは 秘密キーを使う 必要があります。