OmniAICreator/Qiita-1.07M huggingface dataset:
Metro BundlerによるHot Module Replacement (HMR) の詳細な仕組み解説 🔥🔄

:::note info | message
Hot Module Replacement (HMR) は、開発中にコードを変更した際に、アプリケーション全体を再起動することなく、変更されたモジュールだけを更新してリアルタイムで変更を反映する機能です。Metro Bundlerは、このHMRを実現するための重要な役割を担っています。
:::

### Hot Module Replacement (HMR) の仕組み：Metro Bundlerが果たす役割 🚀

HMRは、開発体験を劇的に向上させる素晴らしい機能です。特にReact Nativeのような宣言的なUIフレームワークでは、UIの変更をすぐに確認できるため、開発のイテレーション速度が向上します。

Metro BundlerがHMRを実現するために行っている主要なステップは以下の通りです。

1.  **HMRサーバーの起動**:

      * `react-native start` コマンドを実行すると、Metro Bundlerが起動し、同時にHMRサーバーも立ち上がります。このサーバーは、開発者のコード変更を監視し、変更があった場合にクライアント（シミュレーターや実機で動作しているアプリ）に通知する役割を担います。
      * 通常、Metroサーバーは開発用ポート (例: `8081`) でリッスンしています。👂

2.  **ファイル変更の監視**:

      * Metro Bundlerは、プロジェクト内のJavaScriptファイルやその他のアセットの変更を継続的に監視しています。これは、ファイルシステムの監視機能（`watchman` など）を利用して非常に効率的に行われます。
      * 開発者がコードを保存すると、Metroはすぐにその変更を検知します。 vigilant

3.  **差分（Delta）の生成**:

      * 変更を検知すると、Metro Bundlerは変更されたモジュールを特定し、そのモジュールと関連する依存関係のみを再バンドルします。この際、アプリケーション全体を再バンドルするのではなく、**変更された部分の差分（delta）** を効率的に生成します。
      * これがHMRの高速性の鍵です。全体を再バンドルする手間を省くことで、瞬時に更新が可能になります。💨

4.  **HMR更新のプッシュ**:

      * 生成された差分データは、WebSocketを通じてHMRサーバーからクライアントアプリケーションにプッシュされます。クライアントアプリは、Metro Bundlerとの間でWebSocket接続を確立しています。
      * このWebSocket接続は、シミュレーターや実機で実行されているアプリとMetro Bundler間のリアルタイム通信チャネルとして機能します。📡

5.  **クライアント側でのモジュール更新**:

      * クライアントアプリケーションは、プッシュされたHMR更新データを受信します。
      * JavaScriptのランタイム環境（HermesやJavaScriptCore）内で、変更されたモジュールが古いモジュールと「置き換え」られます。これは、モジュールローダーが新しいバージョンのコードをメモリにロードし、古い参照を更新することで行われます。
      * ここで重要なのが、**アプリケーションの状態（state）が保持される** という点です。例えば、フォームに入力中のテキストやスクロール位置などがリセットされずに、UIだけが変更後のコードで再レンダリングされます。これは、Reactの仮想DOMと組み合わせることで非常に効果的に機能します。✨

6.  **UIの再レンダリング**:

      * モジュールが更新された後、React Nativeは変更されたコンポーネントを検知し、仮想DOMの差分計算に基づいてUIを効率的に再レンダリングします。これにより、開発者はコードの変更が即座にUIに反映されるのを確認できます。🎨

:::note alert | message alert
HMRは非常に便利ですが、以下のような場合には完全なリロード（Fast Refreshやアプリの再起動）が必要になることがあります。

  * 新しいネイティブモジュールを追加・削除した場合（`react-native link`/`unlink` に相当する変更など）。
  * コンポーネントの状態管理に問題がある場合や、深い部分の依存関係が複雑な場合。
  * 特定のネイティブモジュールやライブラリがHMRに対応していない場合。
  * ルートコンポーネントや、副作用の大きいモジュールの変更。
    :::
HMRは、開発者が「コードを書く→保存する→すぐに結果を見る」というサイクルを非常に高速にするための、まさに魔法のような機能なんです！ ✨
pandoc + Docker で word ファイルから markdown 形式のファイルを作成しよう！

github などでもおなじみのmarkdown記法便利ですよね
ちゃんと使ってますか？

今回はmd変換が得意なツールの`pandoc`を初めて使用したので覚え書きです

### 使用法
早速ですが使用法です

``` shell
$ docker run --rm -v ${PWD}:/data pandoc/core sample.docx -o sample.md

--rm: 実行後にコンテナを削除
```
***意味***
```
-v ${PWD}:/data: 現在の作業ディレクトリを /data にマウント

pandoc/core: pandoc Dockerイメージ

sample.docx: 変換元の Word ファイル

sample.md: 変換後の Markdown ファイル
```

#### おまけ

xml形式に出力も可能です

```bash
docker run --rm -v ${PWD}:/data pandoc/core sample.docx -t docbook -o sample.xml
Install EPEL repository

日本語フォント追加方法

# Install EPEL repository and necessary dependencies using `dnf`
RUN microdnf install -y dnf && \
    dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm && \
    microdnf install -y google-noto-sans-cjk-fonts && \
    microdnf clean all





# Manually install Japanese fonts if EPEL is unavailable
RUN mkdir -p /usr/share/fonts/noto-cjk && \
    cd /usr/share/fonts/noto-cjk && \
    wget https://noto-website.storage.googleapis.com/pkgs/NotoSansCJKjp-hinted.zip && \
    unzip NotoSansCJKjp-hinted.zip && \
    rm NotoSansCJKjp-hinted.zip && \
    fc-cache -fv
Let's Encrypt certbot certonlyのDNS認証待ちタイムアウト時間は10時間

## 概要
Let's EncryptのcertbotコマンドでcertonlyのDNS認証したときのタイムアウト時間を計った。

## 背景
業務でLet's Encryptのcertbotコマンドで証明書を作成する必要があり、ドキュメントにも記載がなく、ChatGPTに聞いても無限だとの答えで、本当か調査。

## 前提
- バージョン：certbot 4.1.1

## 結果
10時間でタイムアウト。

## コマンド実行結果
以下のようにコマンドを実行し、ターミナルを開けっ放しにして待つことで調査。
![SCR-20250619-hkrj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/341549/13da341c-9cfc-49b8-b852-7613102ba37a.png)
【supabase】RLS設定とエラー解決例（406/403エラー対応）

# 問題
supabaseにデータを登録したところ、エラーが出て登録できない。
Chromeのデベロッパーツールツールで、確認すると以下エラーとなっていた。
- 406 Not Acceptable エラー
- 403 Forbidden エラー

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/31bc3dea-7b7f-4d8b-be92-43d37f4abb3f.png)

# 前提条件
Enable Row Level Security(RLS)を有効にしている。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/fc6f7549-8b9e-448b-a27c-04c0f337929d.png)

## RLSとは(copilotで確認)
SupabaseのRLS（Row Level Security／行レベルセキュリティ）とは、データベースの各行ごとに「誰がアクセスできるか」を制御できるセキュリティ機能。

# 解決方法
テーブルごとに、SQLで「ポリシー（条件）」を設定する。
ポリシー（条件）はPostgreSQL標準の機能で、Supabaseでもそのまま利用できる。

たとえば、「ログインユーザーは自分のuser_idのデータだけ読める」「未ログインユーザーはuser_idがnullのデータだけ読める」など、柔軟なアクセス制御が可能。

- Supabaseプロジェクトのダッシュボードにログイン
- 左メニューから「SQL Editor（SQLエディタ）」を選択
- 「New Query（新しいクエリ）」をクリック

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/04668a43-5e4a-43ed-a253-c64b4eeafeb3.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/d64b3002-0046-476c-ace7-b214922072dd.png)

下記のSQLを貼り付けて「Run（実行）」ボタンを押す。
```.sql
-- 例: 自分のuser_idのレコードだけSELECT/INSERTことができる
-- (ALLなのでUPDATE, DELETEもできる)
CREATE POLICY "Users can manage their own profiles"
ON user_profiles
FOR ALL
USING (auth.uid() = user_id);
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/6f94caf2-c2e6-4ac5-8dea-774a2a117b10.png)

設定後、エラーが消えた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3881019/866c0c3a-f274-46b8-a9aa-752af91e8ed6.png)

# 終わりに
RLSがよくわからなかったのですが、理解できました。
windowsのタスクスケジューラで指定時間を超過してもタスクが実行される話。

## やりたかったこと

朝の9時から20時まで15分おきにバッチを実行する。（これだけです）


## 登録したタスク

![失敗例.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2759942/6358d570-517f-4c02-b779-5a588c456235.png)

トリガーの有効期限で望み通りの設定になっていると思っていました。

## 回避策

![回避策.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2759942/93f076da-65d2-45b2-b723-99f91744e9f1.png)

朝の9時から11時間後(の20時)まで繰り返し実行するようにしました。

## 結論

![タイトルなし.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2759942/b453c33b-7820-4546-a4ed-b7ecf0c88c8f.png)

トリガーの有効期限は日にちのほうに掛かっています。


## 参考

https://qiita.com/maki_s/items/daa9310335023637409a

https://jpwinsup.github.io/blog/2023/02/07/UserInterfaceAndApps/Repeat-task-indefinitely-issues/

https://jpwinsup.github.io/blog/2023/03/10/UserInterfaceAndApps/DoesNotWorkExpiration-DateTaskScheduler/
Postgres コマンド [ 備忘録 ]

## サービスの起動・停止・確認

### PostgreSQLサービスの起動
```bash
# Homebrewでインストールした場合
brew services start postgresql@15
```

### PostgreSQLサービスの停止
```bash
# Homebrewサービスの停止
brew services stop postgresql@15
```

### サービス状態の確認
```bash
# サービス一覧を確認
brew services list | grep postgresql

# 実行中のプロセスを確認
ps aux | grep postgres
```

## データベースへの接続

### デフォルトデータベースに接続
```bash
# ユーザー名を指定して接続
psql -U your_username

# デフォルトユーザーで接続
psql postgres
```

### 特定のデータベースに接続
```bash
# データベース名を指定
psql -d database_name -U username

# ローカルの特定データベースに接続
psql todo_db
```

**出力例:**
```
psql (15.13)
Type "help" for help.

postgres=#
```

## 基本的なpsqlコマンド

### データベース操作
```sql
-- データベース一覧を表示
\l

-- 新しいデータベースを作成
CREATE DATABASE todo_db;

-- データベースに接続
\c todo_db

-- 現在のデータベースを確認
SELECT current_database();
```

**出力例:**
```
postgres=# \l
                                                List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    | ICU Locale | Locale Provider |   Access privileges   
-----------+----------+----------+-------------+-------------+------------+-----------------+-----------------------
 postgres  | oyne2561 | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | 
 template0 | oyne2561 | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | =c/oyne2561          +
           |          |          |             |             |            |                 | oyne2561=CTc/oyne2561
 template1 | oyne2561 | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | =c/oyne2561          +
           |          |          |             |             |            |                 | oyne2561=CTc/oyne2561
 todo_db   | oyne2561 | UTF8     | en_US.UTF-8 | en_US.UTF-8 |            | libc            | 
```

### テーブル操作
```sql
-- テーブル一覧を表示
\dt

-- テーブル構造を確認
\d table_name

-- サンプルテーブルを作成
CREATE TABLE todos (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    completed BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- テーブルにデータを挿入
INSERT INTO todos (title) VALUES ('Clojureを学習する');
INSERT INTO todos (title) VALUES ('PostgreSQLをマスターする');

-- データを確認
SELECT * FROM todos;
```

**出力例:**
```
todo_db=# SELECT * FROM todos;
 id |         title          | completed |         created_at         
----+------------------------+-----------+----------------------------
  1 | Clojureを学習する      | f         | 2025-06-22 10:30:15.123456
  2 | PostgreSQLをマスターする| f         | 2025-06-22 10:30:25.789012
(2 rows)
```

### ユーザー管理
```sql
-- ユーザー一覧を表示
\du

-- 新しいユーザーを作成
CREATE USER app_user WITH PASSWORD 'password123';

-- ユーザーに権限を付与
GRANT ALL PRIVILEGES ON DATABASE todo_db TO app_user;
```

## よく使うpsqlメタコマンド

```bash
\?          # ヘルプを表示
\q          # psqlを終了
\l          # データベース一覧
\dt         # テーブル一覧
\du         # ユーザー一覧
\d table    # テーブル構造を表示
\c dbname   # データベースに接続
\i file.sql # SQLファイルを実行
\o file.txt # 出力をファイルにリダイレクト
\timing     # クエリ実行時間を表示
```
プロンプトエンジニアもそろそろやばいたったひとつの理由、そして私の仕事はなくなった

## プロンプトエンジニアは早期に絶滅する

私はよくAIをやっています。私はとあるツールを使いシステムを2時間程度で作れるようになってきました。

そうなってくるとアイデア勝負になってきます。なので私はよくアイデアをメモしたりしています。

そんな中でプロンプトのひな型を作り、そして作りたいものだけユーザーからインプットとしてもらうという仕組みを考えました。

そこで私は思いました。**プロンプトエンジニアってやばくない？** と思ったんです

## プロンプトエンジニアもそろそろやばいたったひとつの理由

それはプロンプトはテンプレ化できるということです。

1度作ってよかったプロンプトはテンプレ化すればいいだけです。

やろうと思えば **Excelのシートでも作れます。** 必要な部分は可変にしてあとの部分は定型句化すればいいわけです。

## 今の時代にITエンジニアって何をすればいいのかわからなくなる

今はITエンジニアとして虚無状態です。なぜなら私がやるような仕事はすべてAIでできるからです。

私が今やっている仕事は飲み会の幹事くらいです。これは出席者を追っかけないといけないのでAIでは無理な仕事です。

## チャンスがあるとすればAIのサービスの高額化

Open AIなど大した進化もしてないChatGPT PROのサブスクが$200するなどAIサービスの高額化が進んでいる気がします。

AIがコスト的に手が出ないものになった場合、またITエンジニアが日の目を見ることがあるかもしれません。

逆に言うとそれくらいしかAIが廃れる理由はないんです。
gitcloneした直後にファイルを編集してコミットしたら、fatal: not a git repository (or any of the parent directories): .gitが出た

<h2>症状</h2>
新規フォルダを作り、その中にgit上にあるリポジトリをgitcloneした後、ファイルを編集コミットしたところエラーが発生しました

翻訳すると「致命的: Gitリポジトリ(または親ディレクトリのいずれにも該当しません): .git」でした

```terminal:error
git add -a
fatal: not a git repository (or any of the parent directories): .git
```

<h2>解決方法</h2>
cloneしたフォルダ内に移動していないため、エラーになった模様(新規で作ったフォルダの階層でgitコマンドを打っていた

クローンしたフォルダに移動した後コミットしたら解決しました
DDoS攻撃をちゃんと理解したい人のための入門と設計整理メモ

# DDoS攻撃の仕組み・目的・防御を整理してみた話


## 対象読者とこの記事のスタンス

この投稿は、以下のような方を対象にしています：

- Web サービスやインフラの開発・運用をしている方
- DDoS 攻撃に興味はあるが、まだ体系的に理解できていない方
- CDN や WAF を使っているが、攻撃の仕組みまで深く知らない方

---

### ✅ この記事で触れること

- DDoS 攻撃の分類（L3/L4 と L7）
- UDPリフレクション攻撃の仕組みと例
- 攻撃者の目的・心理戦
- CDN や WAF の有無での影響
- DDoS 防御の現実的な設計選択肢

### ❌ この記事で触れないこと

- 各クラウドサービス（AWS/GCP等）での設定手順
- WAF ルールの具体的チューニング方法
- 攻撃ツールの使用や再現


## DDoS攻撃とは？

**DDoS（Distributed Denial of Service）攻撃**は、複数の端末から一斉にサーバーへリクエストを送り、システムをダウンさせる攻撃手法です。

| タイプ | 概要 |
|--------|------|
| DoS | 単一の端末から攻撃 |
| **DDoS** | 複数端末（≒ボットネット）からの分散攻撃 |

:::note info
検知されにくく、効果も高いため、近年は DDoS が主流です。
:::


## 攻撃レイヤー別の狙い

| レイヤー | 狙い | 例 | 防御対象 |
|----------|------|-----|-----------|
| **L3 / L4** | 回線・ネットワーク負荷 | ICMP Flood、UDP Flood | CDN / Edge |
| **L7** | アプリ処理の限界を狙う | 動的APIへの大量アクセス | オリジンサーバー |


## L3/L4攻撃：**“量”で潰す**

大量のトラフィックを送り、CDNやネットワーク機器を物理的にパンクさせる手法です。

### 代表的な手法

- ICMP Flood（ping 連打）
- SYN Flood（握手だけ大量に投げる）
- UDP Amplification（反射攻撃、詳細は後述）

### 攻撃の症状

- DNS 応答はあるのに接続できない
- ブラウザで 522/503 やタイムアウト

### 防御手段

- Anycast（同じIPに複数拠点で応答）
- レート制限
- 大規模分散CDNネットワーク


## L7攻撃：**“論理”で抜く**

キャッシュを回避し、CPUやDBリソースを大量に消費させるタイプ。

### 攻撃例

```http
GET /api/search?q=random
User-Agent: Mozilla/5.0
Cookie: session=...
```
- 動的検索など、キャッシュ対象外を狙う
- User-Agent や Cookie で Bot に見せない工夫をする

### 防御手段

- キャッシュ範囲の工夫（検索結果の一部キャッシュ等）
- WAF の活用
- リクエストの正規化（パラメータ統一）



## UDPリフレクション：反射で浴びせる美学

UDP は “投げっぱなし型” 。これを利用して、攻撃対象を偽装してレスポンスを集中させるのが**リフレクション攻撃**です。

送信者: 攻撃者
送信元IP: 被害者のIPに偽装
→ 被害者に大量のレスポンスが届く

### 使用されやすいプロトコルと増幅係数

| プロトコル | 内容 | 増幅倍率 |
|------------|------|----------|
| DNS | ANYクエリで情報を多く返す | x28〜x54 |
| NTP | `monlist`コマンドで過去アクセス履歴を返す | x500〜x1000 |
| Memcached | UDPでGET → 全データを返す（無認証） | x50000 😱 |

:::note
攻撃者は「少しのリクエスト」で「大量のレスポンス」を生み出し、ターゲットにぶつけるのが狙いです。
:::

### 防御方法

- 無防備な Open Resolver や NTP サーバーをインターネット上から非公開にする
- BCP38 の実施（送信元IPの偽装を防ぐルーター設定）
- UDPトラフィックに対するレート制限やフィルタの適用

---

## CDNがいない構成は「ボーナスタイム」！？

AWS S3直公開や API サーバーをCDN経由なしで運用している構成は、攻撃者にとって格好のターゲットです。

- **CDN がいない = WAF や Anycastなどの防御機構が存在しない**
- **S3 や BaaS 側の DDoS 耐性にも限界がある**（503, レイテンシ増）
- **すべての防御を自前で設計・実装する必要がある**

---

## DDoSは心理戦にも使われる

技術的なリソース消費以外に、**管理者を混乱させるための陽動**としてDDoS攻撃が使われることもあります。

### 攻撃者のシナリオ例

1. DDoS攻撃でトラフィックを急増させる  
2. WAFやFWが遮断を開始  
3. 正規ユーザーにも影響 → 苦情が管理者へ殺到  
4. 現場が混乱 → 「いったんルールを緩めようか…」  
5. **その瞬間に本命の侵入や改ざんが実行される**

🧠 攻撃者は「焦る人間ほどルールを緩める」ことをよく理解しています。


## 攻撃コストはサブスク並みに安い

最近では、DDoS攻撃はダークウェブなどで**簡単に“購入”できます**。

| 攻撃時間 | 費用の目安 |
|----------|------------|
| 数分〜1時間 | $5〜$30 |
| 1日中継続 | $100 |
| 月額契約（無制限） | $500〜$1000 |

### よくある誤解と実情

- ❌「うちは小さいから関係ない」  
- ❌「攻撃されるほど有名じゃない」  
- ✅「目障りだから」「気に食わない」だけでもターゲットになりうる  
- ✅ 攻撃単価が下がっているので、**“採算度外視”の攻撃が増えている**

---

## ✅ まとめ

- DDoSは「ただの大量アクセス」ではなく、**レイヤーごとに戦略がある**
- UDPの反射やL7の論理攻撃、心理戦まで**多様化**している
- CDNやWAFがない構成は**攻撃者から見て好都合**
- 目的は金銭・妨害・陽動・名声など、**“侵入”以外のゴールも多い**
- 防御は「設計」段階からの備えが必要

---

## 🗒️ 書いたきっかけ

AWS WAF のアップデートで「DDoS攻撃の保護ルールが追加された」といった内容の記事を見かけ、  
「WAFってL7レイヤーでしょ？でもDDoSってL3/L4じゃないの？」  
と違和感を覚えて調べていたら、想像以上に面白くて奥深かったので、まとめてみました。

---

ここまで読んでいただき、ありがとうございました！
cdk deploy オプションはどれを採用するのが良いんだろうか

# cdk deploy オプションはたくさんある
仕事で cdk deploy を扱うことになり、最適なオプションを探していました。
他の方のコードを見ると、オプションを使っている人と使ってない人様々で悩みました。
そこで見たオプションをいくつか紹介します。

# 一応結論
| オプション | 説明 |
|:------:|:------:|
| --require-approval never | デプロイ前に変更の承認を求めるかどうか |
| --verbose | 詳細なデバッグログを出力 |
| --concurrency <数値> | 並行して実行するデプロイの数 |

上記の３つは、どのプロジェクトでも採用して良さそうと思いました！

# 他のアプションを紹介
| オプション | 説明 | 検討事項 |
|:------:|:------:|:------:|
| --all | すべてのスタックをデプロイ | △：全てデプロイしないこともある |
| --hotswap | 特定の変更を高速でデプロイ | ×：CloudFormation を介したい |
| --profile | 特定のプロファイルを使用する | △：高度な機能 |
| --context | コンテキスト変数を渡す | △：渡す場合に使用 |
| --no-rollback | スタックのロールバック無効 | △：高度な機能 |
| --rollback | 失敗したデプロイを明示的にロールバックする | △：高度な機能 |
| --output | 標準出力ではなく指定されたファイルに出力 | △：高度な機能 |
| --force | S3バケットにアップロードする際に、既存のファイルを上書き | △：S3使用時検討 |
| --strict | 警告が残っている場合、スタックの構築を停止 | △：高度な機能 |
| --asset-parallelism | アセットを並行して構築および公開する | △：高度な機能 |
| --asset-prebuild | アセットの事前ビルドを制御 | △：高度な機能 |
| --method | デプロイ方法を指定 | △：高度な機能 |

たくさんオプションありますね・・・

# 最後に
cdk deploy --help でオプション一覧を見ると、本当にたくさんあります。
でも皆さんが使用されているのは結構限定されてるかもしれないです。
VPSのリモートデスクトップが黒い画面で落ちる問題

VPSにリモートデスクトップでアクセスしようとすると、黒画面になり、落ちてアクセスできない問題が発生しました。

動作環境
・ConoHa VPS
・Ubuntu 22.04
・xrdp・xfce

## 試したこと


### 1. GUI パッケージを再インストール

```
sudo apt update
sudo apt install --reinstall xrdp xfce4 xfce4-goodies xorgxrdp
```

### 2. セッション設定をリフレッシュ

```
rm -rf ~/.Xauthority ~/.xsession-errors ~/.cache/sessions/*
echo "startxfce4" > ~/.xsession
chmod +x ~/.xsession
```

### 3.  xrdp 設定ファイルを標準に戻す
```
sudo cp /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini.bak
```

### 4. サービス再起動

```
sudo systemctl restart xrdp
sudo systemctl restart xrdp-sesman
```

### 5. VPS を再起動

```
sudo reboot
```

再起動後、少し待って再度ログインにトライし、リモートデスクトップにアクセスできました！

## なぜ「再インストール＋キャッシュクリア」で直ったのか？

1: パッケージ再インストール で xrdp と xorgxrdp の適切な組み合わせに戻した

2:.Xauthority, .xsession-errors, ~/.cache/sessions/ を削除して「真っ新な状態」にした

3: ~/.xsession を startxfce4 だけのシンプルなファイルに置き換えたことで、セッションの起動フローが安定した

「一度壊れた GUI セッションのキャッシュや設定ファイルをクリーンアップし、xrdp／xorgxrdp を正しい組み合わせに戻した」 から、また普通にリモートデスクトップが使えるようになった、ということですね。


もしまた同じ症状が出たときは、この流れを思い出して

1. キャッシュ＆設定ファイルのクリーン
2. パッケージ再インストール
3. セッション設定の再構築

を試してみてください。これだけでほとんどの「黒画面 xrdp 問題」は解決するはずです！
ClineでMCPサーバのアクションをauto-approveする

# ✅ 実現したいこと
ClineｄMCPサーバのアクションを実行させる際に、`Approve`ボタンをクリックしなくて済むようにしたい。（`Auto-approve`させたい）

![スクリーンショット 2025-06-22 13.41.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141934/bbda2809-41c2-4227-9ce9-205e1ffe20fc.png)

# ✅ 設定

## 📝 Auto-approve設定
Auto-approveの設定で、`use MCP servers`をONにする。
![mcp-server-auto-approve-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141934/a733b42c-e4e2-4970-9e27-7ad38d9ad626.png)


## 📝 MCPサーバ設定
MCPサーバの設定で、action(tool)の`Auto-approve`をONにする。

### 方法1
actionを実行させる際に、`Auto-approve`をONにする。
![mcp-server-auto-approve-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141934/4f116366-1251-4954-911c-988c667a5268.png)

### 方法2
MCPサーバ > Toolsで`Auto-approve`をONにする。
![mcp-server-auto-approve-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141934/ca739bf2-5b07-4754-b55b-7a0cf09d8b32.png)

### 方法3

`cline_mcp_settings.json`で`autoApprove`にaction(tool)を指定する。

```json:cline_mcp_settings.json
{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": [
        "/xxx/weather/build/index.js"
      ],
      "autoApprove": [
        "get-forecast"
      ]
    }
  }
}
```

# ✅ 結果
`Approve`ボタンをクリックしなくてもactionが実行されるようになった。
![スクリーンショット 2025-06-22 14.24.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141934/c8f1729b-5e0c-4e2c-9483-78fa90e246fb.png)
5W1Hで整理する指示出し必須情報まとめ

# 5W1Hで整理する指示出し必須情報まとめ

職場で指示が曖昧になりやすい問題を防ぐため、  
5W1Hフレームワークを使って指示出しに必要な情報を整理しました。

---
| 項目        | 質問                   | 指示内容のポイント           | 例                                 |
|-------------|------------------------|------------------------------|------------------------------------|
| W​h​a​t     | 何の作業をする？        | 目的・作業内容・成果物       | A機能の結合テスト実施、バグ再現確認 |
| W​h​y      | なぜそれをする？        | 作業の背景・目的意図         | リリース前の品質保証のため         |
| W​h​e​r​e   | どの環境・対象？        | システム名・環境名・対象範囲 | 検証環境KENV1、画面A〜C            |
| W​h​e​n     | 期限はいつ？            | 納期・優先度                 | 今週金曜12:00まで                  |
| W​h​o      | 誰が担当？関係者は？    | 担当者・レビュー者・相談先   | ○○さんが担当、レビューは□□課長    |
| H​o​w      | どんな手順・資料で？    | 参照資料・進め方・途中確認方法 | 仕様書V2.3、テストケースNo.5〜8、進捗は都度報告 |


---

## 5W1Hフレームワークでの指示出しテンプレート例
```
What（何を）
Aシステムの〇〇機能の結合テストをお願いします

Why（なぜ）
リリース前の事前確認で品質を担保するためです

Where（どこで）
検証環境：KENV1 / 対象画面：画面A〜C

When（いつまでに）
6月28日（金）12:00まで

Who（誰が）
○○さん（あなた）が担当、レビューは□□課長

How（どのように）
仕様書V2.3、既存のテストケースNo.5〜8を参考に進めてください。
初回の進捗は本日午後に一度報告願います。
```



---

## 補足

この5W1H整理表は、  
- 上司が指示出し時に使う  
- 部下が曖昧指示を受けたときに質問するための抜け漏れチェックにも使えます

---
【初心者向け】排他制御の基礎をわかりやすく解説！ 「アトミック」「ミューテックス」「スレッドセーフ」「クリティカルセクション」の違いとは？

## はじめに

プログラミング初心者や組み込み開発を始めたばかりの方にとって、  
「アトミック」「スレッドセーフ」「ミューテックス」などの専門用語は、会話の中で頻繁に登場しながらも、意味がわからず戸惑うことが多いはずです。

筆者も「ソレって結局なんなん？」と思いながら、会話についていけず悔しい思いをした経験があります。

これらの用語は、特に**マルチスレッド**や**リアルタイムOS**環境での**排他制御**において頻繁に使われる重要なキーワードです。

---

この記事では、次の4つのキーワードについて、イメージしやすいようにわかりやすく解説します。

- アトミック（Atomic）  
- ミューテックス（Mutex）  
- スレッドセーフ（Thread-safe）  
- クリティカルセクション（Critical Section）

配属したての新人エンジニアが、**なんとなく話についていける**レベルの理解を目指します。


## アトミック（Atomic）  
**「これ以上分割できない、一連の処理をひとまとめで実行したい」**

アトミック（Atomic）は「atom（原子）」が語源で、  
原子がこれ以上分割できないモノであるように、
**これ以上分割できない処理**という意味です。

**他のスレッドに割り込まれず、一連の処理が中断されずに完了すること**が重要なポイントです。


## ミューテックス（Mutex）  
**「同時アクセスを防ぐためのロック（鍵）」**

「Mutex」は **Mutual Exclusion（相互排他）** の略。  
つまり、**同時に1つのスレッドだけが資源へアクセスできるようにする仕組み**です。

### トイレを例としたイメージ：
```text
鍵をかけて入る → カバーを開ける → 用を足す → 手を洗う → 鍵を外して出る
```

- 「鍵」：ミューテックス  
- 「カバーを開ける → 用を足す → 手を洗う」：アトミックな処理

というように、**ミューテックスはアトミック処理を安全に行うための鍵**と捉えると理解しやすいです。


## スレッドセーフ（Thread-safe）  
**「複数のスレッドから同時に使っても問題ない設計」**

スレッドセーフとは、**同時に複数のスレッドから呼び出されてもデータが壊れないように設計されている処理**のことです。

スレッドセーフな関数の一例：
- 内部でミューテックスを使って排他制御している  
- グローバル変数を一切使わない（副作用がない）

### 注意：
スレッドセーフだからといって「無敵」ではありません。  
**呼び出す目的・文脈によっては意図しない結果になることもある**ため、処理の内容を理解したうえで使いましょう。

### 実務でよくある会話：
- 「その関数、スレッドセーフになってる？」  
- 「グローバル変数を使ってるから、スレッドセーフじゃないですね」


## クリティカルセクション（Critical Section）  
**「この部分は同時に実行されたら困るんだけど…」**

クリティカルセクションとは、  
**排他制御が必要な、同時に実行されたくない処理の範囲**のことです。

## C言語ソースコードを例にここまでの用語をまとめると


```c
int g_counter1 = 0;
int g_counter2 = 0;
int g_counter3 = 0;

void func1() {
    mutex_lock();
    g_counter1 += 1;
    g_counter2 += 1;
    g_counter3 += 1;
    mutex_unlock();
}
```

- `「g_counter1 += 1;」～ 「g_counter3 += 1;」` の加算処理：**アトミックな一連の処理**  
- `「g_counter1 += 1;」～ 「g_counter3 += 1;」` の処理全体 ：**クリティカルセクション**  
- `mutex_lock()`と`mutex_unlock()`：**ミューテックスによる保護**  
- `func1()`：**スレッドセーフな関数**

---

## まとめ：用語の関係性をざっくり整理

| 用語 | 意味 |
|------|------|
| アトミック | 分割できない処理単位 |
| ミューテックス | 同時アクセスを防ぐロック |
| スレッドセーフ | 複数スレッドでも安全に使える設計 |
| クリティカルセクション | 排他制御が必要な処理の範囲 |


## 注意（この記事のスタンス）

本記事では、用語の**ざっくりイメージを掴む**ことを目的としており、  
**割り込み処理**や**ハードウェアレベルの排他制御命令**など、より深い話には踏み込んでいません。

「実務で会話についていける最低ライン」の理解が目標です！


## おわりに

これらの用語は、組み込み開発者ならばチーム開発やコードレビューで日常的に使われる可能性が高いキーワードです。  
「排他制御」といった概念に初めて触れる方が、用語の意味に詰まらずスムーズに学習を進められる助けになれば嬉しいです。
Applications Manager と Site24x7を徹底比較！特徴とメリット、他ソフトとの違いも解説【2025年最新】

こんにちは、やーはりです。
今回は企業のITインフラやアプリケーション監視ツールの中でも特に注目されている「Applications Manager」と「Site24x7」をテーマに、それぞれの特徴、他の監視ソフトとの比較、そして導入メリットまで深掘りします。

---

## 1. はじめに

IT運用の効率化・安定化には、監視ツールの選定が極めて重要です。
クラウド利用やマイクロサービスの普及で複雑化した環境をどう管理するか？
ここで活躍するのが「Applications Manager」と「Site24x7」。

それぞれどんな特徴があるのか、どんな現場に向いているのかを整理し、あなたの環境に合うツール選びをサポートします。

---

## 2. Applications Managerとは？

Applications Managerは、**ZohoグループのIT管理ブランドであるManageEngine**が提供する、企業向けのアプリケーション＆サーバ監視ツールです。

### 主な特徴

* **監視対象が幅広い**

  * サーバ、仮想環境（VMware、Hyper-Vなど）、クラウド（AWS、Azure）、ネットワーク、データベース、Webアプリケーションなど多様なリソースをカバー。
* **深いパフォーマンス分析**

  * 詳細なメトリクス収集で障害原因を即特定可能。
* **カスタマイズ性が高い**

  * アラート設定やダッシュボードの自由度が高く、自社運用に合わせやすい。
* **オンプレミス/クラウド両対応**

  * どちらの環境でも柔軟に展開可能。
* **インテグレーション**

  * SlackやPagerDuty、ServiceNowなど外部ツールとの連携が豊富。

---

## 3. Site24x7とは？

Site24x7も、**ZohoグループのManageEngineブランド**が提供するクラウドネイティブな監視サービスです。

### 主な特徴

* **SaaSモデルで手軽に導入可能**

  * インストール不要、ブラウザで管理可能。
* **統合監視プラットフォーム**

  * サイト監視、サーバ・アプリケーション監視、ネットワーク、クラウドサービス監視を一本化。
* **グローバルな監視拠点**

  * 世界各地の監視ポイントからユーザー体験をリアルタイムチェック。
* **AI/MLを活用したアラート**

  * 異常検知を自動化し、ノイズを削減。
* **豊富なAPI・自動化対応**

  * DevOps環境との連携に強み。

---

## 4. Applications Manager と Site24x7 の比較表

| 項目      | Applications Manager | Site24x7            |
| ------- | -------------------- | ------------------- |
| 提供形態    | オンプレミス / クラウド両対応     | SaaS（クラウドサービス）      |
| 監視対象    | 幅広い（サーバ・アプリ・ネットワーク等） | 幅広いが特にWeb/クラウド監視に強み |
| インストール  | 必要（オンプレ）             | 不要                  |
| カスタマイズ性 | 高い                   | やや限定的               |
| アラート機能  | 詳細設定可能               | AIによる異常検知・ノイズ削減     |
| UI・UX   | 企業向けでやや複雑            | シンプルでモダン            |
| 価格体系    | ユーザー数・監視対象数に依存       | サブスクリプション（月額課金）     |
| 運用難易度   | やや高め                 | 低め                  |
| 外部連携    | 豊富                   | 豊富                  |

---

## 5. 他の監視ツールとの違い

* **NagiosやZabbix**などはオープンソースで柔軟だが、運用工数や設定負荷が大きい。
* **Datadog**はSaaSで強力だが高価な傾向。
* **New Relic**はアプリケーションパフォーマンス監視（APM）に特化。

Applications Managerは、エンタープライズの多様な監視ニーズに対応しつつオンプレミスで細かい制御が欲しいケースに強い。
Site24x7はクラウド環境がメインでスピーディに導入し、運用コストを抑えたい中小〜中堅企業に最適です。

---

## 6. それぞれのメリットまとめ

### Applications Managerのメリット

* 豊富な監視対象で一元管理できる
* 企業のオンプレ環境に最適
* カスタマイズと詳細分析が充実
* 多様な通知チャネルを使える

### Site24x7のメリット

* クラウドネイティブで導入が簡単
* AIで監視精度向上＆運用負荷軽減
* 監視ポイントが世界規模で広い
* DevOpsツール連携が手厚い

---

## 7. まとめ

どちらも優秀な監視ツールですが、選ぶ基準は明確です。

* **オンプレや複雑な環境を徹底管理したい → Applications Manager**
* **クラウド中心で手軽に監視を始めたい → Site24x7**

両者の強みを理解し、自社の運用形態・予算・技術リソースに合った最適解を選ぶことが成功の鍵です。

---

## 8. 参考リンク

* ManageEngine Applications Manager公式: [https://www.manageengine.jp/products/Applications_Manager/](https://www.manageengine.jp/products/Applications_Manager/)
* Site24x7公式: [https://www.site24x7.jp/](https://www.site24x7.jp/)
【MySQL】Performance Schema DB について - メタデータロック監視の完全ガイド

## 概要
Performance Schema は MySQL 5.5 以降で導入されたパフォーマンス監視・診断機能です。

MySQLサーバーが自動的に作成・管理するシステムデータベースで、リアルタイムでサーバーの内部動作を監視できるメタデータロックの確認が可能です。

## メタデータロックの確認方法

メタデータロックテーブルの取得は以下のクエリで実行できます：

```sql
SELECT * FROM performance_schema.metadata_locks;
```

## テーブルの各カラムについて

### 基本情報カラム

#### 1. OBJECT_TYPE
**メタデータロックの対象となるオブジェクトの種類**

| 値 | 説明 |
|---|---|
| `TABLE` | テーブル |
| `SCHEMA` | データベーススキーマ |
| `GLOBAL` | グローバルロック |
| `TABLESPACE` | テーブルスペース |
| `USER LEVEL LOCK` | ユーザー定義ロック |

#### 2. OBJECT_SCHEMA
**ロック対象のオブジェクトが属するデータベース名**

- 値の例: `minne_production`, `information_schema` など
- NULL: グローバルロックの場合

#### 3. OBJECT_NAME
**ロック対象の具体的なオブジェクト名**

- 値の例: `campaigns`, `users`, `campaign_restrictions` など（テーブル名）
- NULL: スキーマレベルのロックの場合

#### 4. COLUMN_NAME
**ロック対象のカラム名（カラムレベルロックの場合）**

- 通常: `NULL`（テーブルレベルロックが一般的）

#### 5. OBJECT_INSTANCE_BEGIN
**オブジェクトのメモリアドレス（内部識別用）**

- 用途: 同一名の異なるオブジェクトインスタンスを区別
- 通常: 数値のメモリアドレス

## ⭐️ 重要な監視項目

### 6. LOCK_TYPE（ロックの種類）
**メタデータロックの種類**

| ロックタイプ | 説明 | 危険度 |
|---|---|---|
| `SHARED_READ` | 読み取り用共有ロック | 低 |
| `SHARED_WRITE` | 書き込み用共有ロック | 中 |
| `SHARED_UPGRADE` | アップグレード用共有ロック | 中 |
| `EXCLUSIVE` | 排他ロック（最も強い） | **高** |
| `INTENTION_EXCLUSIVE` | 排他意図ロック | 高 |

### 7. LOCK_DURATION（ロック保持期間）
**ロックの保持期間**

| 期間 | 説明 | 影響度 |
|---|---|---|
| `STATEMENT` | ステートメント実行中のみ | 低 |
| `TRANSACTION` | トランザクション終了まで | 中〜高 |
| `EXPLICIT` | 明示的に解放されるまで | **非常に高** |

### 8. LOCK_STATUS（ロック状態）
**ロックの現在の状態**

| ステータス | 説明 | 対応の緊急度 |
|---|---|---|
| `GRANTED` | ロック取得済み | 通常 |
| `PENDING` | **ロック待機中** | **🚨 要注意** |
| `VICTIM` | デッドロック検出でキャンセル対象 | **🚨 緊急** |

## その他の診断情報

### 9. SOURCE
**ロックを要求したソースコードの場所**

- 値の例: `sql_parse.cc:6031` など
- 用途: デバッグ・トラブルシューティング

### 10. OWNER_THREAD_ID
**ロックを保持しているスレッドのID**

- 用途: `performance_schema.threads` テーブルと結合してプロセス情報を取得

### 11. OWNER_EVENT_ID
**ロックを取得したイベントのID**

- 用途: パフォーマンススキーマでの詳細な分析

## 実践的な監視クエリ例

### ロック待機の検出
```sql
SELECT 
    OBJECT_SCHEMA,
    OBJECT_NAME,
    LOCK_TYPE,
    LOCK_DURATION,
    LOCK_STATUS,
    OWNER_THREAD_ID
FROM performance_schema.metadata_locks 
WHERE LOCK_STATUS = 'PENDING';
```

### 長時間保持されているロック
```sql
SELECT 
    ml.*,
    t.THREAD_ID,
    t.PROCESSLIST_ID,
    t.PROCESSLIST_USER,
    t.PROCESSLIST_HOST
FROM performance_schema.metadata_locks ml
JOIN performance_schema.threads t ON ml.OWNER_THREAD_ID = t.THREAD_ID
WHERE LOCK_DURATION = 'TRANSACTION'
AND LOCK_STATUS = 'GRANTED';
```

## まとめ

Performance Schema の `metadata_locks` テーブルを活用することで：

- **リアルタイムでのロック状況監視**
- **パフォーマンスボトルネックの早期発見**
- **デッドロック問題の原因特定**
- **データベース運用の最適化**

が可能になります。

特に `LOCK_STATUS = 'PENDING'` の状態を定期的に監視することで、深刻なパフォーマンス問題を未然に防ぐことができます。

大規模なWEBアプリケーションにおけるマイグレーション実行時などは考慮する必要がありますので、頭の片隅に置いておくと良いでしょう。
【1ヶ月合格】データサイエンス発展試験を“独学で突破”した勉強法まとめ（教材1冊＋徹底理解）

## ✅ 概要

- **試験名**：統計検定 データサイエンス発展  
- **勉強期間**：約1ヶ月  
- **使用教材**：『データサイエンス発展 試験対策テキスト』（翔泳社／日本統計学会公式認定）
![9784489024290_1_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/0c2884ba-89ee-42c8-9c37-c22bcef62448.jpeg)

---

## 📘 背景と経緯

- 昨年末に統計検定2級を取得済み。
- 年明けはシステムアーキテクト試験を勉強。
- ゴールデンウィーク中にAI学習を実施し、G検定にも合格。
- その後、約1ヶ月で本試験にも合格。

統計やAIの基礎知識はありましたが、**Pythonは完全未経験**。  
そして、今回の試験でAIの能力を確かめてみたかった。
別に失敗しても俺が資格に受からないだけで誰も損しない。

そんなわけで、
AIが提唱する「**教材以外には頼らず、すべてを理解する**」という方針で挑戦しました。
一種の実験です。

---

## 📚 使用教材と活用法

### 使用した教材

- 『データサイエンス発展 試験対策テキスト』（翔泳社）

### 学習方法

- 本を**何周も繰り返し読み込み**（計8周ほど）
- 巻末の演習問題を繰り返し解く
- **分からない部分はAIに質問**して理解を深める
- 数式や図の説明が難しい時は**写真を撮ってAIに説明させる**

---

## 📷 学習風景の一部
![スクリーンショット 2025-06-22 135931.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/13147d26-758a-4b26-8e40-14765be4fb72.png)
分からない問題、ちょっと理解を確認したいところがあれば問題を作らせたり、

![スクリーンショット 2025-06-22 135953.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/d9aa0f6a-b5a4-47a1-adb5-294dadcae330.png)
写真が曲がっていてもOCR補完できるので、問題なかったり、

![スクリーンショット 2025-06-22 140028.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/b13f6143-3ced-4784-987c-ad3c29928d29.png)
分かりやすくしろと言ってみたり、
![スクリーンショット 2025-06-22 140052.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/9cbccbb3-bcd1-4627-9d28-d2ff686fa298.png)
丸投げしたり、

![スクリーンショット 2025-06-22 140107.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4043133/0697528f-c4fc-490a-b7fa-1194afe89a86.png)
テキストで述べられている例以外の具体例を聞いたりしました。


## 🏁 所感と振り返り

- **この1冊だけで合格は可能**。
- 網羅性は完璧とはいえませんが、合格に必要な知識は十分。
- 丸暗記ではなく、**実践的に使える理解が得られた**ことが収穫。
- 特に自然言語処理の分野は、実際に活用中。
- あと、仮説にしていた「AIは試験勉強に**極めて**強い」事も証明できた。

---

## 📝 まとめ
- 公式テキストを使い倒す覚悟があれば、**これ一冊で合格は十分に可能**。
- OpenAIは最強の勉強補助ツール。これで月3000円は安すぎて狂ってる。
作業環境構築-インストール必要編

# はじめに
申請を通せば色々インストールできる現場があります。その時用です。

# VSCodeの設定
https://qiita.com/aseyan/items/54ac6523e43b688d8c4a

# リンク
https://qiita.com/aseyan/items/98ef612313258b0c8661
Nuxt ScriptsでGA4やGoogleアドセンスを設定する簡単な方法(Nuxt)


## はじめに
こんにちは。Eita Kobayashiと申します。
今回は公式が出しているNuxt Scriptsモジュール(現在β版)で簡単にGoogleアドセンスとGA4を設定する方法をご紹介します。

※ドキュメントを一緒に見ながらやっていくのを推奨
> https://scripts.nuxt.com/

## Nuxt Scriptsとは?

Nuxt Scriptsは、GA4やGoogleアドセンスといった「サードパーティ製スクリプト」の導入と管理を簡単にするNuxtの便利なモジュールです。

主に、サイトのパフォーマンス向上できたり。
また同意管理のような設定の雛形みたいなのが用意されているようです(私はここらへんよくわからん)。

![s7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3801754/f9c907f6-d116-41f1-b0d4-faee689c23ad.png)


> Nuxt Scripts公式サイトから(Google翻訳)

## なぜNuxt Scriptsを使うのか

GoogleアドセンスやGA4のような、いわゆる"よく使う"スクリプトを手軽にかつ確実に導入したい方には、まさにうってつけのモジュールです。

1. 公式モジュール
   - やはり公式というだけあって、Nuxt本体との連携は非常にスムーズです。Nuxtのバージョンアップへの追従や将来的な互換性を考えても、サードパーティ製のモジュールよりも比較的安心して導入できます
2. ドキュメントが充実している
   - 基本的な使い方で迷うことは少ないでしょう

これらの理由以外にも、個人的な体験があります。

以前、Googleアドセンスの件を他のモジュールで試してみたのですが、いかんせん広告を貼るコンポーネントの実装がうまくできなかったです。(一応ドキュメント通りにはやったつもり)

Nuxt Scriptsでやるとすごい簡単に実装できたので、今回はこのモジュールを選定しました。

## インストール

まずはNuxt Scriptsモジュールをインストールしましょう。

```bash
npx nuxi@latest module add scripts
```

## GA4 (Googleアナリティクス) を設定 (グローバル設定)

```ts:nuxt.config.ts
scripts: {
    registry: {
      googleAnalytics: {
        id: 'G-#######', // 各自ここを自分のIDに変えてね
      },
    }
  },
```

たったこれだけです。

これなら「ほかのモジュールでも同じようなことができるじゃないか(怒)」と思う人もいると思うので、次はGoogleアドセンスを簡単に設定しましょう。

## Googleアドセンスを設定 (グローバル設定)

※ads.txtは設定しといてください。今回は特にNuxt Scriptsと関係ないので省略

```ts:nuxt.config.ts
scripts: {
    registry: {
      googleAnalytics: {
        id: 'G-#######', // 各自ここを自分のIDに変えてね
      },
      //googleAdsenseを追加
      googleAdsense: {
        client: "ca-pub-#######", // 各自ここを自分のIDに変えてね 
        autoAds: true, // 自動広告を表示するかしないかを切り替え
      },
    }
  },
```

これでGoogleアドセンスが有効になり、自動表示も有効になりました。

さて、本題はここからです。「広告を貼るコンポーネントの実装」をしましょう。
公式ドキュメントを見ながらやるとそんなに難しくないです。

### 直接広告を埋め込むコンポーネントの実装

記事の途中やサイドバーなど、特定の場所に個別の広告ユニットを配置したい場合も多いですよね。Nuxt Scriptsでは、`ScriptGoogleAdsense`コンポーネントを利用して簡単に実装できます。

以下は、広告ユニットを埋め込む際のサンプルコードです。改造して利用してください。

```vue
<ScriptGoogleAdsense data-ad-client="ca-pub-#### ここに自分のパブリッシャーID" data-ad-slot="ここに個別の広告ユニットのID"
data-ad-format="auto" :data-full-width-responsive="true"
style="display:block;width:100%;height:120px">
    <!-- エラーハンドリング -->
    <template #error>
      <p>おっと!広告の読み込みに失敗しました。</p>
    </template>
</ScriptGoogleAdsense>
```

>https://scripts.nuxt.com/scripts/ads/google-adsense#using-scriptgoogleadsense-component

## まとめ

Nuxt Scriptsは公式モジュールな為、比較的Nuxt本体との連携が非常にスムーズです。
これにより、GA4やGoogleアドセンスといった一般的なサードパーティスクリプトを簡単に導入できます。ドキュメントも整備されているため、導入のハードルは低いでしょう。
曖昧支持対応台詞テンプレ集

# 曖昧指示対応セリフテンプレ集

---

## 目次

* [指示が曖昧なときの初動確認](#1-指示が曖昧なときの初動確認)
* [資料・参考情報を確認する時](#2-資料参考情報を確認する時)
* [進行中に方向性を確認する時](#3-進行中に方向性を確認する時)
* [進捗を報告する時](#4-進捗を報告する時)
* [全体方針を提案する時](#5-全体方針を提案する時)
* [忙しい上司への配慮フレーズ](#6-忙しい上司への配慮フレーズ)

---

## 1. 指示が曖昧なときの初動確認

**上司の指示例：**

> 〇〇やっておいて

**セリフテンプレ：**

> 承知しました。念のため確認させてください。
>
> * 対象範囲は〇〇全体でしょうか？△△機能のみでしょうか？
> * 実施環境は開発環境で大丈夫でしょうか？
> * 成果物はテスト記録のみでよろしいでしょうか？

> 初回作業となりますので、以下の流れで進める想定です。大きくずれていないかご確認いただけますでしょうか？
>
> 1. 仕様確認
> 2. 環境準備
> 3. テスト実施
> 4. 結果報告

---

## 2. 資料・参考情報を確認する時

**上司の指示例：**

> 仕様書に沿ってやって

**セリフテンプレ：**

> 現在、A仕様書を参照していますが、他に参照すべき資料（過去のテストケース、既存のチェックリスト等）はございますでしょうか？

> 以前の類似案件の手順書など、参考になるものがあればご教示頂けますと助かります。

---

## 3. 進行中に方向性を確認する時

**作業を進めていて不安になった時**

**セリフテンプレ：**

> 現時点ではこのような形で進めております（スクリーンショット添付）。方向性は合っていそうでしょうか？

> この段階で一度ご確認頂けますと、後戻りなく進められそうです。

---

## 4. 進捗を報告する時

**セリフテンプレ：**

> 現状の進捗です。
>
> * 環境準備：完了
> * A機能の結合テスト：実施済み（問題なし）
> * B機能の結合テスト：実施中（あと30分程度）

> 現在の進捗状況をまとめます。もし何か確認事項・注意点があればお知らせ下さい。

---

## 5. 全体方針を提案する時

**セリフテンプレ：**

> 今回の作業は以下の進行計画で進める予定です。問題ないかご確認お願いします。
>
> 1. 仕様確認（午前中完了予定）
> 2. テスト環境セットアップ（本日中）
> 3. 結合テスト実施（明日〜明後日）
> 4. 結果レビュー・報告（今週末）

> もし進め方のご要望等あれば、事前に共有頂けますと幸いです。

---

## 6. 忙しい上司への配慮フレーズ

**どの場面でも使いやすい定型文**

> お忙しいところ恐縮ですが、念のため確認させてください。
>
> Yes/No でご回答頂ければ十分です。
>
> ご負担をおかけしないよう、途中で方向性だけ確認させて頂きます。
>
> こちらの進め方で大きく外していないか、ご一言頂けると助かります。

---
Macが熱くなって困る件

Mac が異常に熱くなり、ファンが起動して止まらなくなる現象に悩まされました。
解決したので、経緯と解決策をメモしておきます。

### スペック
まず、私のMac は以下のものです。
* MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports)
* OS: MacOS 12.4
* CPU: 2.4 GHz クアッドコアIntel Core i5
* メモリ: 8 GB 2133 MHz LPDDR3
* GPU: Intel Iris Plus Graphics 655 1536 MB

### 症状
具体的な症状を列挙してみると以下の通りです。

* 使っていると急に熱くなる
* そのうちファンが回り出す
* CPUの温度が90度を超える
* スリープにしてMacを閉じてもファンは止まらない
* 再起動しても収まらない
* シャットダウンして、冷えたことを確認してから起動すれば症状は出ない
* バッテリーで駆動しているときは、あっという間に電池がなくなる
* この症状は2ヶ月ほど前に急に出てきた

ちなみにCPUの温度は以下のコマンドで測ることができます。

`$ sudo powermetrics | grep -e "CPU die temperature"`

### 苦悶の日々
古いハードウェアなので、内部に埃が溜まって排熱機能が低下したのか、とかOSのアップデートをしたら治るのかとか、そろそろ買い替える時期か、とかいろいろ考えました。

焦って買い替えて、新しいMacでも同様の症状がでたら嫌なのでしばらく待って色々調べることにしました。というのも、「Mac 熱暴走」とかで検索してみると、買ったばかりのMacで同様の症状が出ていることが散見されるからです。

### ついに解決〜Chrome犯人説〜
アクティビティモニターでCPUやメモリのリソースを食っているのは何か、いろいろ監視してみたのですが、そのうちだんだんとわかってきたことは、どうもChrome が疑わしいということです。確かに、Macを起動すると、真っ先に立ち上げるのはChrome であり、Chrome を使っていないということは皆無です。

そこで「mac chrome 熱」で検索してみたところ、以下のサイトを見つけました。

https://discussionsjapan.apple.com/thread/255505101?sortBy=rank

ついに解決です！

> Chromeの「設定」→「システム」→「グラフィックアセラレーションが使用可能な場合は…」を無効にしました。

これで解決しました。
ということは、弱いGPUしかついていない私のMacに対して、GPUの能力を前提とした「グラフィックアクセラレーション」を起動して、ハードウェアの能力を超えた要求に応えようと頑張りすぎて熱を持ってしまった、ということでしょうか。

古いMacBookですがあと1〜2年は頑張ってもらいたいです。

同様の症状にお悩みの方がおられたら参考にしてみてください。
Ubuntu で Kubernetes 三昧その５-２(Weave Net CNI)

[Ubuntu で Kubernetes 三昧その５-１(Weave Net CNI)](https://qiita.com/intrajp/items/d8bc58ed689a70b64ca7)の続き

いままで、Control Plane マシンを、マスターと呼んでいましたが、Control Plane(コントロールプレーン)
と呼ぶことにします。
```
@master1~# hostnamectl set-hostname controlplane1
exit
```
コントロールプレーンで、[必要なポート](
https://kubernetes.io/docs/reference/networking/ports-and-protocols/)が開いているか確かめます。
```
@controlplane1:~ sudo ufw status 
状態: 非アクティブ
```
ファイアウォールは稼働されていません。
```
@workernode1:~$ nc localhost 22 -zv -w 2
Connection to localhost (127.0.0.1) 22 port [tcp/ssh] succeeded!
@controlplane1:~$ nc 127.0.0.1 6443 -zv -w 2
Connection to 127.0.0.1 6443 port [tcp/*] succeeded!
@controlplane1:~$ nc 127.0.0.1 2379 -zv -w 2
Connection to 127.0.0.1 2379 port [tcp/*] succeeded!
@controlplane1:~$ nc 127.0.0.1 2380 -zv -w 2
nc: connect to 127.0.0.1 port 2380 (tcp) failed: Connection refused
@controlplane1:~$ nc 127.0.0.1 10250 -zv -w 2
Connection to 127.0.0.1 10250 port [tcp/*] succeeded!
@controlplane1:~$ nc 127.0.0.1 10259 -zv -w 2
Connection to 127.0.0.1 10259 port [tcp/*] succeeded!
@controlplane1:~$ nc 127.0.0.1 10257 -zv -w 2
Connection to 127.0.0.1 10257 port [tcp/*] succeeded!
```
ポート 2380 は使われて折らず、2379 が使われていると思うので、問題ないですね。

ワーカーノードで必要なポートの状態を確認します。
```
@workernode1:~$ nc localhost 10250 -zv -w 2
Connection to localhost (127.0.0.1) 10250 port [tcp/*] succeeded!
@workernode1:~$ nc localhost 10256 -zv -w 2
Connection to localhost (127.0.0.1) 10256 port [tcp/*] succeeded!
@workernode1:~$ nc localhost 30000-32767 -zv -w 2
nc: connect to localhost (127.0.0.1) port 30000 (tcp) failed: Connection refused
(...snip...)
nc: connect to localhost (127.0.0.1) port 32767 (tcp) failed: Connection refused
```
問題ない、と言えます。

[Ubuntu で Kubernetes 三昧その６(clusterrole, serviceaccount, Deployment)](https://qiita.com/intrajp/items/cc9221ec1e4536b7903c)につづく

参考：

https://kubernetes.io/docs/reference/networking/ports-and-protocols/
【CCNA】受験2週間前 ~ 直前に確認したいこと

## これは何の記事なのか

CCNA対策記事です
受験 2 週間前から直前までに確認したいことをまとめました
合格はしましたが，
正直シミュレーションが悲惨だったので後悔したこともまとめました
皆さんは同じ轍を踏まないようにしてくださいね...

## 筆者のスコア

- Automation and Programmability: 70%
- Network Access: 35%
- IP Connectivity: 96%
- IP Services: 90%
- Security Fundamentals: 73%
- Network Fundamentals: 80%

シミュレーションが悲惨でしたが一応合格できました


## 確認したいこと

1. 試験の流れ
1. シミュレーション問題
1. 各プロトコルの優先度
1. その他見直しポイント

## 試験の流れ

### 受験

Cisco の試験は LinuC などと違い，
回答方法が複数あります
事前に知らないと焦るので下記ページで確認しましょう
[Cisco公式チュートリアル](https://learningnetwork.cisco.com/s/certification-exam-tutorials)

また，CCNAは解いた問題を後から確認することができません
前にしか進めません（人生みたいですね）
覚悟して解いていきましょう

### 合否

なんと，すぐにはでない場合があります
その場合は受け取ったレポートに Pending と書いてあります

一旦落ち着きましょう
いつ頃からか，一旦保留にして何か集計の処理をするようになったそうです
（自分は今回初なのでそんなこともつゆ知らず，ドキドキしてました）

合格した場合は，バッチ受け取れるでみたいなメールがきます
不合格の場合は，再受験を促すメールがくるそうです

## シミュレーション問題

正直かなり焦りました
というか 2 問くらいドブに捨ててしまいました
以下の点，気をつけてくださいませ...

### 何のモードから始まっているか確認

特権(`#`)から始まっていることに気付かず，
ひたすら `interface E0/1` を打っては，
そんなコマンドは使えないとエラーを吐かれ続けました

皆さんは `conf t` を打って，
グローバルコンフィギュレーションモードに入ってから，
インタフェースに入りましょうね...

### インタフェースが生きていることを確認

ip アドレスを各インタフェースに割り当てて，
ping で疎通確認する問題でしたが，
そもそもインタフェースが down していたので疎通確認できませんでした
気づくのに 3 分くらいかかってしまいました

皆さんは `no shutdown` しましょうね...

### コマンド確認

やはり対策しておかないと焦ります
チートシートをみるなり，Ping-t で練習しておくのが良いです
というかやっておかないと解けないですほんと

https://qiita.com/yusaku-creative/items/a4bae7f7cf6ae799ae0b

https://mondai.ping-t.com/

## 各プロトコルの優先度

プロトコル多すぎるし，
大きい方が優先の場合と小さい方が優先の場合があり，
かなり困惑します
再度確認しましょう

https://tech.synapse.jp/entry/2022/05/30/113000#STP%E3%81%AE%E5%84%AA%E5%85%88%E5%BA%A6

## その他見直しポイント

こちらがかなり有用です
本番焦らないように見ておきましょう

https://academ-aid.com/qualif/vendor/ccna-qa#index_id0

## 学習方法と試験の感想

実際にどれくらいの学習で受かったのかと，
試験の難易度が体感でどれくらいだったかを共有します
何かの参考になれば嬉しいですね

### 学習方法

### 0 ~ 1 ヶ月

白本の各章を読んでは章末の問題を解くを繰り返し，1 周しました

### 1 ~ 2 ヶ月

Ping-t のピックアップ問題をひたすら解きました

### ~ 2 ヶ月半

白本，Ping-t の模試や，Ping-t のシミュレーションやコマ問を解きました

### 試験の感想

全体的に Ping-t くらいの難易度でした

選択肢から選ぶ問題は Ping-t くらいか少し簡単めでした
シミュレーションは Ping-t のシミュレーションくらいでした
ただ，シミュレーションは難易度がえげつないので，
早めに対策した方がいいです．
問題の途中にシミュレーションが挟まっているので，
ペースを崩される可能性もあります
ロボットアームを多様体最適化を使い最短距離で動かす　記事の予約

多様体最適化の数式は、いくつかの記事で見かけるが、ロボットアームでのPython実装が見当たらない。
簡単な例を示す。
たぶん、6月２７日までには、アップできるかと。
【CORSエラー解消】ReactとFlaskでlocalhostと127.0.0.1が原因でハマった話

# はじめに
ReactとFlaskを使ってWebアプリケーションを開発していた際、CORSエラーに悩まされた。
結論から言うと、Reactアプリのオリジン（実行URL）と、Flaskが返すAccess-Control-Allow-Originヘッダーの値が一致していないことが原因だった。

当初は、Flask側で `localhost` と `127.0.0.1` の両方をCORSで許可しているのだから、どちらでも動くはずだと思っていた。
しかし、実際には `localhost` にするとエラーが出て、`127.0.0.1` にすると正常に動くという状態に陥った。

---

## 起きていた現象

FlaskのCORS設定は以下のようにしており、両方のオリジンを許可していた。

```python
from flask_cors import CORS

CORS(app, origins=[
  "http://localhost:5173",
  "http://127.0.0.1:5173"
], supports_credentials=True)
```

一方、React側では以下のようにaxiosを使ってAPI通信をしていた。

```ts
import axios from 'axios'

const api = axios.create({
  baseURL: 'http://localhost:5000/api',
  withCredentials: true,
  headers: {
    'Content-Type': 'application/json'
  }
})
```

Reactアプリは `http://127.0.0.1:5173` で動いていたため、以下のようなエラーが発生した。

```
Access to XMLHttpRequest at 'http://localhost:5000/api/login' from origin 'http://127.0.0.1:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
```

---

## 原因の本質

CORSエラーが発生するのは、「JavaScriptが実行されているオリジン（= ReactのURL）」と「Flaskが返すAccess-Control-Allow-Originの値」が一致していない場合であることがわかった。

つまり、次のような状態だとCORSエラーになる。

* ReactのURL：`http://127.0.0.1:5173`
* axiosのリクエスト先：`http://localhost:5000`
* FlaskのCORS許可：`localhost:5173` はOKでも、ブラウザが送ってくる `Origin: http://127.0.0.1:5173` に対して許可レスポンスが返らない

---

## 学びの本質

重要なのは、axiosで指定するURL（baseURL）とReactの実行URLが一致しているかどうかではなく、
ブラウザが自動で付与する `Origin` ヘッダーと、Flaskが返す `Access-Control-Allow-Origin` ヘッダーが一致しているかどうかである。

axiosのURLが `localhost` でも、Reactが `127.0.0.1` で動いていれば、`Origin: http://127.0.0.1:5173` が送信される。
このとき、Flaskが `localhost:5173` しか許可していなければ、「違うオリジンからのアクセス」だとみなされてブロックされる。

---

## まとめ

* CORSはブラウザが自動で付加する`Origin`と、サーバーが返す`Access-Control-Allow-Origin`の一致を検証している
* FlaskのCORS設定で複数のオリジンを許可できたとしても、実際のアクセス元と一致する値が正しく返されないと意味がない
* `localhost`と`127.0.0.1`は別オリジン扱いになる
* React、axios、Flaskのホストをすべて `localhost` か `127.0.0.1` に統一するのがベストプラクティス。
KeeperPAMを調べてみた！他社製品と比較して感じたこと

## はじめに

最近Qiitaのスポンサーテーマで見かけた「**KeeperPAM**」というサービスに興味を持ち、  
個人的に調べてみました。

特権アクセス管理（PAM）やパスワード管理サービスは、最近注目度が上がっている分野でもあり、  
自分の学習も兼ねて、他の有名製品と比較してみた結果をまとめておきます。

> ※本記事はあくまで個人の調査・感想ベースです。  
> 導入検討時は、公式サイトや各ベンダーの資料を確認してください。

---

## そもそもPAMとは？

PAM（Privileged Access Management）は、  
「サーバーやクラウド、重要システムへの特権アクセス（root権限など）」を  
**安全かつ適切に制御するための仕組み**です。

最近では以下のような背景から注目が集まっています。

- ゼロトラストセキュリティの浸透
- 増加するリモートアクセスとSaaSの活用
- 情報漏えいや内部不正への対策

---

## 調査対象のPAM製品一覧

個人調査の対象としたのは、以下の4製品です。  
それぞれ、Webサイト・公開ドキュメント・動画などをチェックして得た印象を表にしています。

| 製品名 | 特徴 | 一言での印象 |
|--------|------|----------------|
| **KeeperPAM** | クラウドネイティブ・パスワード管理とPAMの統合 | UIが分かりやすく、導入しやすそう |
| **CyberArk** | エンタープライズ向けの老舗・大企業での導入多数 | 重厚な仕組み、学習コストは高め |
| **BeyondTrust** | 柔軟な構成と豊富な連携機能が魅力 | 拡張性◎ |
| **Delinea** | モダンなクラウドPAM、シンプル構成も可能 | 情報はやや少なめ？ |

---

## KeeperPAMについて調べたこと

### ✅ 良いと感じた点

- **UIがシンプルで直感的**  
  → 管理画面の動画を見ていても迷わず操作できそうな設計。

- **クラウドネイティブな設計**  
  → オンプレ不要で、SaaSとして使える手軽さが魅力。

- **パスワード管理とPAM機能の統合**  
  → Keeper自体は元々パスワードマネージャーなので、特権アクセスとの統合が自然。

- **ブラウザ拡張やモバイル対応も豊富**  
  → 使い勝手の部分も意識されている印象。

### 🤔 気になった点

- **日本語の導入事例や技術情報が少ない**  
  → 比較的最近注目され始めたためか、日本語での情報が限定的。

---

## 他製品との比較で感じたこと

### CyberArkとの違い

- CyberArkは「大規模導入向け」という印象。導入規模・体制が整っている大企業向けかな。
- KeeperPAMは「小〜中規模でも導入しやすそう」なスリムな構成が魅力。

### BeyondTrustとの違い

- BeyondTrustは「柔軟性と高機能」のバランスが良く、設計次第で広く活用できそう。
- 一方KeeperPAMは「分かりやすさと統一感」が強み。機能を理解しやすい印象。

### Delineaとの違い

- Delineaは設計思想がKeeperPAMと近く、クラウドファーストでシンプルな構成を好む方向け。
- ただ、情報量の少なさや使っている人の声が見つけにくかった。

---

## まとめ：PAM分野、想像以上に多種多様

調べていて感じたこと

- 一口にPAMといっても、製品ごとに**思想や対象ユーザー層がかなり異なる**
- KeeperPAMは「クラウドネイティブ」「UI重視」「導入のしやすさ」という点で  
  他の製品と明確に差別化されているように感じた
- パスワード管理とPAMが統合されているのはユニークな価値提案

---

## おわりに

この記事はあくまで、**Qiitaのすぽんさーテーマで気になったサービスを個人的に調べた結果のまとめ**です。

今後、より多くの企業や開発現場で「ゼロトラスト」や「アクセス管理」の重要性が高まっていく中で、この分野の製品を早めに知っておくことは損ではないなと感じました。

「他にこんなサービスもあるよ」などあれば、  
ぜひコメントで教えてください 🙌

---
#35.エラーメッセージの出力順について（Ruby on Rails)

# はじめに
こんにちはnayaaaaです。
Ruby on Railsのエラーメッセージの出力で少しハマったところについて書いていきます。

# ハマったところ
Ruby on Railsを使用したWebページで、ある一意のキーと異なる一意のキーの一方がfalseならエラーメッセージを出力するといった処理を加えたく、Modelにvalidationを追加したのですが、エラーメッセージが出力されませんでした。なんでかなぁと思い、Controller側の設定を確認してみると、すでに先述した処理が書かれており、Modelまで処理が到達していなかったのが原因だったようです。

# RailsのMVCモデルのフロー図

![image-1750506723466.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3904736/b6037456-0865-4aef-b512-d325b2268938.png)

上の画像のようなフローで処理されていると思うのですが、今回で言うとControllerでエラーメッセージを返すように設定されており、Modelでエラーメッセージを出力するように設定してもModelまで処理が到達しなかったというのが原因となります。
※画像がわかりづらいかもしれないですが、自分がイメージしやすいように作成していますのでご了承ください。

Controller側の設定
```
rescue ActiveRecord::RecordNotFound 
        render status: :not_found, json: { error: t('.error_message') }
```
Controller側で例外処理のrescueとしてエラーメッセージを出力する

Model側の設定

```
validate :naya

 def naya
    if !sales || naya_company != sales.naya_company
      errors.add(:sales_id, t(".errors.invalid"))
    
```

①処理が複雑なためvalidateでnayaを指定
②nayaを定義
③salesが存在しない場合やnaya_companyとsales.naya_companyが一致しない場合エラーメッセージを出力

このように先にControllerでエラーメッセージが出力される処理を記述すると、Model側にまで処理が到達しなく、Controllerでエラーメッセージを返してしまうようです。

# まとめ
RailsのMVCモデルの流れでは、Controllerが最初にリクエストを受け取り、Modelのvalidationはその後に実行されます。

今回、validate :nayaをモデルに追加して独自のvalidationを行いましたが、想定通りにエラーメッセージが表示されませんでした。その原因は知り合いに教えてもらったのですが、Controllerで ActiveRecord::RecordNotFoundをrescueしてrenderしていたため、Modelの処理まで到達していなかったことがわかりました。

Modelに到達せずrenderされた場合、その時点でレスポンスが返ってしまうため、以降の処理（validationなど）はスキップされます。

Railsについては大枠では理解していたつもりでも、実際に触ってみると、細かい部分がわかっていなかったことに気づけました。

以上ありがとうございました！！
【AWS SES】DKIM設定（DomainKeys Identified Mail）

## はじめに

こちらはDKIM設定についての健忘録です。


## DKIMとは？

**DKIM（DomainKeys Identified Mail）** は、メールの**なりすましや改ざんを防止**するための技術です。

* メール送信時に「秘密鍵」で署名
* 受信者は「DNS上の公開鍵」で署名を検証

検証に成功すると、**送信者の正当性**が保証され、信頼性が向上します。

### DKIMのメリット

*  スパムやなりすましと誤判定されにくい
*  DMARCと組み合わせてセキュリティ強化
*  ドメインの信頼性を可視化

## DKIM構成の全体像（AWS SES）

| 構成要素           | 説明                            |
| -------------- | ----------------------------- |
| SES            | ドメインの送信者認証と署名付与               |
| DKIM署名         | SESが自動的に `DKIM-Signature` を付与 |
| DNS（Route 53等） | SESが提供する3つのCNAMEレコードを追加       |

## 設定手順（AWSコンソール）

### ① SESに送信ドメインを登録（Identity登録）

1. AWSマネジメントコンソールにログイン
2. **SES（Simple Email Service）** のコンソールを開く
3. ナビケーションペインから **設定 > \[ID]** を押下
4. \[**IDの作成**] を押下
5. 以下の設定を入力：

   * **IDタイプ**: `ドメイン`
   * **ドメイン**: `your-domain.com`（※これは入力例です。ご自身のドメインを指定してください）
   * **DKIM 署名**: 有効化（デフォルトでON）
   
6. \[**IDの作成**] を押下

### ② DKIMトークン（CNAMEレコード）を取得

1. 作成されたドメインを押下
2. 「**DKIM**」セクションを確認
3. `xyz12345._domainkey.your-domain.com` のような **3つのCNAMEレコード** が表示されます。

これらをDNS（Route 53など）に設定する必要があります。

### ③ DNSにCNAMEレコードを追加（Route 53等）

Route 53を使用している場合の設定手順：

1. **Route 53** コンソールを開く
2. 該当のホストゾーン（your-domain.com）を押下
3. \[**レコードを作成**] を押下し、以下の情報を入力

| 項目       | 内容例（実際の値はSES画面からコピー）             |
| -------- | -------------------------------- |
| レコードタイプ  | CNAME                            |
| レコード名    | `xyz12345._domainkey`（ドメイン部分は不要） |
| 値（Value） | `xyz12345.dkim.amazonses.com`    |
| TTL      | デフォルト（300など）                  |

これを**3件分**繰り返します。

### ④ SESでDKIMステータスを確認

1. SESの「Verified identities」に遷移
2. 対象ドメインを押下
3. 「**Verification status**」および「**DKIM status**」が `Success` になっていればOK

   * 反映には数分〜最大72時間かかる場合があります

## 送信後の確認方法

実際にSESで送信したメールを受信し、**メールヘッダー**を確認します。

`DKIM-Signature` のような行があれば、署名が付与されています。

```text
DKIM-Signature: v=1; a=rsa-sha256; d=your-domain.com; ...
```

## ⚠ よくある注意点

| 注意点         | 内容                                              |
| ----------- | ----------------------------------------------- |
| DNS反映の遅延    | CNAMEレコードの反映に**最大72時間**かかることがあります                 |
| 他サービスとの競合   | Google Workspace や SendGrid などと**同一ドメイン**使用時に注意 |
| メールアドレス単位不可 | **ドメイン単位のみ**DKIM署名が可能（`xxx@your-domain.com`は不可） |
| DMARCとの関係   | DKIMが失敗すると**DMARCポリシーでfail扱い**になることがあります          |


## まとめ

* AWSコンソールから簡単にDKIM署名の設定が可能
* DNSにCNAMEを3件追加するだけで署名が有効化
* SPFやDMARCと組み合わせてセキュリティ強化

## 参考リンク

* [AWS公式：DKIMの設定手順](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html)
ローカルLLM × FastAPI × Dify：クラウド不要の日本語チャット環境構築

<h1> 【実証レポート】ローカルLLM × FastAPI × Dify：オフラインの日本語チャット環境構築</H1>


## 1. はじめに（目的）

- API利用コストを抑えたローカル実行環境を構築したい  
- 機密性の高いデータを扱えるよう、ローカル環境で処理を完結させたい  

---

## 2. 構成概要（システム全体）

| 構成要素       | 内容                                       |
|----------------|--------------------------------------------|
| 言語モデル     | オープンソースの日本語対応LLM              |
| APIサーバー    | Python製FastAPIをローカルで構築・常駐化     |
| フロントエンド | Dify（自己ホスト環境／Docker Compose利用） |

---

## 3. 実装と構築方法

### 3.1 モデルとAPIの構築

使用モデル：

```

cyberagent/open-calm-small

````

このモデルをローカルに読み込み、FastAPIでAPIエンドポイントを提供しています。

FastAPI 実装例（抜粋）：

```python
from fastapi import FastAPI, Request
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

app = FastAPI()
tokenizer = AutoTokenizer.from_pretrained("cyberagent/open-calm-small", trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained("cyberagent/open-calm-small", trust_remote_code=True)
model = model.to(torch.device("cuda" if torch.cuda.is_available() else "cpu"))

@app.post("/v1/chat/completions")
async def chat_completion(request: Request):
    data = await request.json()
    user_message = data["messages"][-1]["content"]
    input_ids = tokenizer.encode(user_message, return_tensors="pt").to(model.device)
    output_ids = model.generate(input_ids, max_new_tokens=100, do_sample=True, top_p=0.95, temperature=0.7)
    result = tokenizer.decode(output_ids[0], skip_special_tokens=True)[len(user_message):].strip()
    return {
        "id": "chatcmpl-opencalm",
        "object": "chat.completion",
        "choices": [{"message": {"role": "assistant", "content": result}}],
        "model": "cyberagent/open-calm-small"
    }
````

---

### 3.2 Dify（セルフホスト構成）

* Difyは公式のDocker Compose構成を利用して、自己ホスト型で構築しています。
* Difyからは、**HTTPリクエストノードを用いてFastAPIエンドポイントに接続**し、プロンプトを送信して応答を取得しています。
* OpenAI互換のレスポンス形式で構成しているため、GUI上でスムーズに動作させることができます。

---

## 4. 実行結果と観察

### ✅ 動作確認

* DifyのUIからプロンプトを送信し、ローカルLLMから応答を取得できました。
* 応答形式はOpenAI互換であるため、追加の実装を行うことなく連携できました。

### ✅ 処理性能と品質

* 応答速度は、CPU環境でおおよそ数秒〜十数秒でした。
* 応答の文構造は成立していますが、期待した内容には届いていない場面も確認されました。

今回使用したモデルは小型で扱いやすい反面、応答の一貫性や知識の網羅性には課題が見られました。
今後、上位のLLMモデルやそれに適したハードウェアを利用することで、速度と品質の向上が期待できる可能性があります。

### 実行環境（検証マシン）

| 項目  | 内容                    |
| --- | --------------------- |
| OS  | Windows 10（64bit）     |
| CPU | Intel Core i5（第6世代相当） |
| メモリ | 16GB                  |
| GPU | NVIDIA GTX 1050（2GB）  |

---

## 5. おわりに

本検証により、**ローカル環境のみで構成された日本語LLMチャット基盤を構築できることを確認しました。**
また、DifyのGUIを活用することで、非エンジニアでも対話形式の操作が可能となり、利便性が高まることも分かりました。

応答品質には課題が残るものの、構成としての再現性や導入のしやすさは十分に確認できました。
さらに、利用可能範囲をプライベートネットワーク内にすることで企業内での活用にも応用可能と考えます。