OmniAICreator/Qiita-1.07M huggingface dataset:
【Python初心者】URLを解析・構築・エンコードする基本まとめ

PythonでURLを扱うときに使う標準ライブラリ `urllib.parse` の機能について学んだことを、自分用の学習メモとしてまとめました。URLの分解や結合、クエリの操作、エンコードなど、よく使う基本を整理しています。

## URLを構成要素に分解する（`urlparse()`）

URLをスキーム・ドメイン・パス・クエリなどに分解するには `urlparse()` を使います。

```python
from urllib.parse import urlparse

url = "https://example.com/path/to/page?name=alice&age=30"
parsed = urlparse(url)

print(parsed.scheme)   # 'https'
print(parsed.netloc)   # 'example.com'
print(parsed.path)     # '/path/to/page'
print(parsed.query)    # 'name=alice&age=30'
```

```
https
example.com
/path/to/page
name=alice&age=30
```

## クエリ文字列を辞書形式に変換する（`parse_qs()`）

URLのクエリ文字列を辞書のように扱うには parse_qs() を使います。返される値はリスト型です。

```python
from urllib.parse import parse_qs

query = "name=alice&age=30&age=25"
params = parse_qs(query)

print(params)
```

```
{'name': ['alice'], 'age': ['30', '25']}
```

## クエリ文字列をタプルのリストにする（`parse_qsl()`）

クエリの順番を保持した(キー, 値)のリストが欲しいときは parse_qsl() を使います

```python
from urllib.parse import parse_qsl

query = "name=alice&age=30&age=25"
params = parse_qsl(query)

print(params)
```

```
[('name', 'alice'), ('age', '30'), ('age', '25')]
```

## 辞書からクエリ文字列を作る（`urlencode()`）

辞書などのデータをURLのクエリ文字列に変換するには `urlencode()` を使います。

```python
from urllib.parse import urlencode

params = {'name': 'alice', 'age': 30}
query_string = urlencode(params)

print(query_string)
```

```
name=alice&age=30
```

リストの値を含む場合、`doseq=True` を指定すると複数キーになります。

```python
params = {'age': [30, 25]}
print(urlencode(params, doseq=True))
```

```
age=30&age=25
```

## URLエンコードとデコード（`quote()` / `unquote()`）

URLに使えない文字（日本語など）を含む文字列は、エンコードして安全に送れるようにします。

```python
from urllib.parse import quote, unquote

original = "こんにちは"
encoded = quote(original)
decoded = unquote(encoded)

print(encoded)
print(decoded)
```

```
%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF
こんにちは
```

## 相対URLを組み立てる（`urljoin()`）

ベースとなるURLに対して相対パスを組み合わせて、絶対URLを作ることができます。

```python
from urllib.parse import urljoin

base = "https://example.com/path/"
relative = "sub/page.html"
full_url = urljoin(base, relative)

print(full_url)
```

```
https://example.com/path/sub/page.html
```

## おわりに

今回はURLの構造を理解したり、クエリや文字列のエンコード・デコードをするための基本的な使い方を整理しました
# 【連載第5回】異常行動の再現実験とLLMによる説明分岐の最適化設計【PAM×生成AIの実運用強化】


## 🧭 はじめに

本連載では、ゼロトラスト環境下での特権アクセス管理（PAM）に対し、「AIによる行動監視」「CI/CD自動構築」「説明生成AIの統合」など、技術的にも構造的にも段階的に高度化してきました。

本稿（第5回）では、**「異常行動の再現シナリオとその観測」「GPT系LLMを活用した説明分岐の最適化設計」**という、より実運用を想定した動的評価・改善フェーズに焦点を当てます。

---

## 🎯 本記事のゴール

- 典型的な異常行動パターンを再現し、AIスコア挙動を検証
- 各パターンごとにLLM生成の説明精度を評価・改善
- 行動・スコア・説明の三位一体化設計を確立

---

## 🧪 1. 再現する異常行動パターンと構造

| 異常カテゴリ | シナリオ例 | 想定されるスコア挙動 |
|--------------|------------|----------------------|
| ログイン異常 | 定時外・別拠点からの急なログイン | Anomaly↑, Compliance↓ |
| 権限外操作 | 認可されていないコマンドを実行 | Anomaly↑↑, Predict=異常行動 |
| 行動ジャンプ | 通常遷移にないリソースを直アクセス | Predict失敗・補完不能 |
| セッション反復 | 同一行動を過剰に繰り返す | Compliance正常でもAnomaly上昇 |

---

## 🤖 2. 再現スクリプト構成（Ansible例）

```yaml
- name: Simulate out-of-hours login
  shell: ssh -p 22 user@target -i /tmp/key.pem
  when: ansible_date_time.hour > 22 or ansible_date_time.hour < 6

- name: Execute unauthorized command
  shell: cat /etc/shadow
  register: shadow_out

- name: Access high-privilege system
  uri:
    url: https://vault.internal/admin-console
    method: GET
    return_content: yes
```

---

## 📊 3. 各シナリオに対するAIスコア推移記録

```json
{
  "timestamp": "2025-06-25T02:13:45Z",
  "user": "test_admin",
  "anomaly": 0.78,
  "compliance": 0.42,
  "predict_match": false
}
```

---

## 💬 4. LLM説明生成と精度最適化プロセス

### 🔁 試行例：GPTによる説明生成

```python
prompt = f"""
User {{user_id}} accessed {{resource}} at {{timestamp}}. 
Previous actions: {{history_summary}}.
Explain this behavior in 1 sentence from an audit perspective.
"""
response = gpt4(prompt)
```

---

## 🧠 5. 分岐最適化設計（Prompt Engineering）

| ケース | 提示用プロンプト構造 | 効果 |
|--------|---------------------|------|
| 不正行動濃厚 | 行動に対する説明と警告を明示 | 管理者の即時対応促進 |
| 判別困難 | 選択肢付きの要因説明生成 | レビュー補助と証拠提示 |
| 正常だけど異常に見える | 行動意図を補足して誤検知を防ぐ | ノイズ低減・負担軽減 |

---

## 📈 6. 可視化と説明統合ダッシュボード設計

- 時系列グラフ（スコア推移）
- 説明文トランスクリプト（GPT出力）
- 判定フラグ（ALERT／WARN／OK）
- 対応ログ（手動／自動）

---

## 📡 7. 応用：対話型セキュリティレビュー支援AI

- GPTをベースにした「対話型セキュリティアシスタント」
- 質問例：「このユーザーが昨日行った異常は？」「許容範囲内？」
- ChatOps連携でSlack上から即回答

---

## ✅ まとめ

本稿では、以下のような進化を扱いました：

- **異常行動を再現し、AIスコア挙動と照合**
- **生成AIを通じた説明生成を評価・最適化**
- **行動・数値・説明を一体化する構成を設計**

これにより、PAM運用における**“透明性・理解性・自律性”**の三位一体が強化されます。

---

## 🔜 次回予告（第6回）

> 「GPT-AgentsによるPAMアクセス操作の自律実行と説明対話化構成」

---
Claude Code で ESLint fix しちゃおう

## はじめに

かつて少人数でアドベントカレンダーを乗り切った日々を懐かしく思い出すくらい記事を書こうとしております。w
さて、今回のテーマは、X（旧Twitter）でよく見かける「**Claude Code**」についてです。一般的な入門記事ではなく、「**こんな用途にも便利に使えました！**」という、一歩踏み込んだ活用事例をご紹介します。

Claude Codeは、その登場が大きな話題となりましたよね。
特にMaxプランが従量課金ではなく月額制になり、しかもその価格の安さに驚いた方も多いのではないでしょうか。今回は、このMaxプランを最大限に活用し、**ESLintの`--fix`コマンドでは修正できないような問題をClaude Codeに任せてみた**経験をまとめます。

## 実施した手順

1.  **Claude Code Maxプランへの加入**:
    まずは[公式ページ](https://support.anthropic.com/ja/articles/11145838-pro%E3%81%BE%E3%81%9F%E3%81%AFmax%E3%83%97%E3%83%A9%E3%83%B3%E3%81%A7claude-code%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B)からMaxプランに加入しました
2.  **Claude Codeのインストール**:
    次に、[ドキュメント](https://docs.anthropic.com/en/docs/claude-code/overview#install-and-authenticate)を参考にClaude Codeを環境に導入します
3.  **ESLintルール選定と適用**:
    ESLintのルールの中から、`--fix`では自動修正されないものを特定し、プロジェクトに適用しました。ここが最も時間を要するステップです


## ESLintのルール選定

今回選んだのは、`@typescript-eslint/explicit-function-return-type`です。

https://typescript-eslint.io/rules/explicit-function-return-type/

TypeScriptにおいては、関数の返り値を明示することでパフォーマンス向上に繋がるため、開発チームではこのルールを推奨し、コードレビューでも厳しくチェックしていました。しかし、それでもレビュー漏れが発生したり、既存のコードベースに一斉適用しようとすると数百ものファイルを一度に修正する必要があるといった課題がありました。

そこで、「**これはClaude Codeに任せるのが最適では？**」という発想に至ったわけです。


## ESLintのルール設定

ESLintのルール設定は非常に重要です。
ここを適切に行わないと、Claude Codeに修正を依頼しても期待通りの結果が得られず、やり直しになる可能性が高まります。公式ドキュメントをしっかりと確認し、どのようなルールを適用するのかを慎重に設定しましょう。


## Claude Codeの実行

結果には本当に驚かされました。
Claude Codeは、信じられないほどのスピードでコードを修正してくれたのです。もちろん高速であることは理解していましたが、実際に目の当たりにするとそのすごさを改めて実感しました。

今回の修正対象となったファイルはなんと**513ファイル**。これをたった数時間で完了させてくれたのですから、その効率性には目を見張るものがあります。

実際に使用したプロンプトは以下の通りです。

```
`yarn lint` で出力されるエラーをすべて修正してください。
修正方針としては、`typescript-eslint/explicit-function-return-type` のエラーであれば、返り値の型を実際のロジックから深く考えて修正をお願いします。
型は any ではなく、できる限り具体的な型を推測して指定してください。
また、git add や commit はしないようにしてください。
```


## Claude Codeに修正を依頼する際の注意点

今回、AIに全面的に修正を任せましたが、もちろん完璧な修正ばかりではありませんでした。
中には手作業での微調整が必要な箇所も散見されました。また、ESLintのエラー修正後に型エラーが発生するケースもありました（これも最終的にはClaude Codeに再修正を依頼しました）。

大量の修正をAIに依頼する場合、「**ある程度の割り切りが必要**」だと感じました。
例えば、今回の返り値に関するエラー修正においては、以下のような点を許容しました。

  * 多少の型指定ミスは許容する
  * `any`が指定されてしまうことがあっても、一旦は許容する
      * これは、アプリケーションのソースコードだけでは型を正確に推測できないケースがあるためです
  * **目的を見失わない**
      * 今回の目的は「ESLintにおける返り値のルールを追加する」ことであり、既存のソースコードに完璧にルールを適用することに固執しすぎないという判断をしました

AIも万能ではありません。だからこそ、「**どのようにAIを使いこなすか**」が非常に重要になります。


## まとめ

今回の記事では、ESLintの`--fix`では対応できない修正をClaude Codeに依頼した事例を紹介しましたが、一番伝えたいのは、「**Claude Codeの使い方は、アプリケーションの作成や修正にとどまらない**」ということです。MCP（大規模なコード変更プロジェクト）などを駆使すれば、パフォーマンスチューニングなど、AIに任せられる範囲は非常に広いです。

もう一つ強調したいのは、「**AIが生成したコードをそのまま鵜呑みにしない**」ということです。依頼した内容とAIが修正した内容が必ずしも一致するとは限りません。そのため、AIがどのようなコードを生成したのかは、必ず自分の目で確認する習慣をつけるべきです。

AIは単なるツールではありません。どのように活用し、提示された成果物が正しいかを自身で見極めることが求められます。今後もAIの進化は加速するでしょう。AIと上手に付き合いながら開発を進めていければと思います。

最後までお読みいただき、ありがとうございました！
# 【連載第4回】特権アクセス管理（PAM）×AIの運用実戦とCI/CD完全自動化構成【リアルタイム観測制御】


## 🧭 はじめに

本連載では、ゼロトラスト時代のPAM（特権アクセス管理）について、「構築・AI統合・自動化運用」までを段階的に解説してきました。

本稿（第4回）では、前回までの「Terraform+Vault+Ansible構成」および「PAM×AIの三層構成モデル」に、**CI/CDパイプライン連携とリアルタイム観測制御の強化処理**を加えた「実戦適用構成」を徹底的に解説します。

---

## 🎯 本記事のゴール

- **CI/CD×AI×PAM**による**リアルタイム制御の運用基盤**を構築
- Vault/Ansible/AIモデルをGitHub Actionsへ完全統合
- 生成AIや観測モデルを活用し、**“説明可能な自動制御”**を実装

---

## 🧩 構成概要：完全自動運用基盤のアーキテクチャ

```
Developer Push
     ↓
GitHub Actions Triggers
     ↓
Terraform → Vault Init & Policy Apply
     ↓
Ansible → PAM Credential Pull + Host Config
     ↓
AI Models (逸脱検知・準拠推定)
     ↓
LLM補助モデル（説明生成）
     ↓
Slack/Alert + Self-Heal Script
```

---

## 🛠 1. GitHub ActionsによるCI/CD自動トリガー

```yaml
jobs:
  pam_pipeline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Terraform Apply
        run: terraform apply -auto-approve

      - name: Vault Policy Apply
        run: ./scripts/init-vault.sh

      - name: Ansible Playbook
        run: ansible-playbook -i inventory apply-pam.yml
```

---

## 🤖 2. AIモデルの統合：逸脱検知×準拠率推定×行動予測

### モデルA：異常スコアリング（Anomaly Detection）

```python
def score(user_data):
    base_vector = get_historical_vector(user_data["user_id"])
    return cosine_similarity(user_data["latest_vector"], base_vector)
```

### モデルB：準拠率スコアリング

```python
def compliance_score(log_entry, policy_map):
    matches = compare_policy(log_entry, policy_map)
    return len(matches) / len(policy_map)
```

### モデルC：行動予測（選択予測型）

```python
def predict_next_action(history):
    return model.predict(history[-10:])
```

---

## 🧪 3. セルフヒール制御トリガー（自己回復アクション）

```yaml
- name: Auto-Heal PAM Violation
  run: |
    if [ $SCORE -lt 0.4 ]; then
      bash scripts/kill-session.sh $USER_ID
      echo "Force closed session due to abnormal behavior"
    fi
```

---

## 💬 4. 説明生成：GPT連携による行動説明支援

```python
def generate_explanation(user_event):
    prompt = f"Why did the user {user_event['user']} access {user_event['resource']}?"
    return gpt4_completion(prompt)
```

---

## 📈 5. 観測と可視化：動的スコアトラッキング

```bash
curl -X POST metrics-api.example.com   -d '{"user": "A123", "anomaly": 0.38, "compliance": 0.62, "predict": "root shell"}'
```

---

## 🧠 6. 応用：自動承認フロー＋SOAR連携

- 高スコア＋正常行動 → 自動承認（Slackボット連携）
- 中間スコア → 手動承認（管理者入力）
- 逸脱スコア急上昇 → 自動遮断＋SOAR通知（XSOARなどへPOST）

---

## 🧩 7. 今後の展望と布石

- **LLMファインチューニング**による個別ユーザー対応の説明最適化
- **社内AIモデル更新のCI/CD統合**（モデル更新も自動化）
- **リスクスコア連動型リソース配分制御**（特権権限の動的剥奪）

---

## ✅ まとめ

| 要素 | 実現内容 |
|------|----------|
| Terraform | PAM環境構築の自動化 |
| Vault | 資格情報の安全管理 |
| Ansible | 秘匿情報の安全展開 |
| GitHub Actions | CI/CD統合実行 |
| AIモデル | 行動の逸脱・準拠・予測制御 |
| GPT系LLM | 説明自動生成・レビュー支援 |
| Self-Heal | 自動遮断＋修復機構 |

本稿は、**“制御可能で説明可能なPAM基盤”**を構築するための指針です。  
次回は、**「異常行動の再現実験とLLMによる説明分岐の最適化設計」**について解説予定です。

---
ゼロから始めるプログラミング | [第1回]: プログラミングって何？

 
## 1. はじめに：なぜ今「プログラミングって何？」なのか？

「プログラミングとは何か？」——これは一見すると初心者向けの問いかもしれません。しかし、現場のエンジニアであっても、日々コードを書く中でこの本質を見失いがちです。

最近では、AIやLLM（大規模言語モデル）の台頭により「コードを書くこと」自体が大きく変わりつつあります。そんな今だからこそ、「そもそもプログラミングって何なのか？」を改めて問い直すことには、大きな意味があります。

本記事では、**プログラミングの本質を分かりやすく整理しながら、現場で役立つ具体例やコード付きで深掘りしていきます。**

---

## 2. プログラミングとは何か：定義とその背景

### 🔹 一言で言えば「命令の設計」

プログラミングとは、「コンピュータにやらせたいことを、人間が理解できる形で手順に落とし込むこと」です。具体的には次のような3要素があります：

* **入力**：データや条件を受け取る
* **処理**：ルールに従って操作・計算する
* **出力**：結果を返す

この構造は、どのプログラミング言語でも共通です。

### 🔹 コンピュータとの“対話”である

プログラミングとは、単に命令を並べるだけではありません。\*\*“どうすればコンピュータが理解し、意図通りに動いてくれるか”\*\*という、ある意味で対話に近い作業です。

---

## 3. 実例で理解する：Pythonで「やりたいこと」をコードにする

たとえば、次のような現場課題があるとします：

> **CSVファイルの中から、売上が最も高い商品を抽出し、Slackに通知したい。**

これをプログラミングで解決してみましょう。

### 🔸 ステップ1：CSVファイルを読み込む

```python
import pandas as pd

df = pd.read_csv("sales.csv")
```

### 🔸 ステップ2：売上が最大のレコードを抽出

```python
top_item = df.sort_values(by="sales", ascending=False).iloc[0]
```

### 🔸 ステップ3：Slack通知する（Webhookを使用）

```python
import requests

message = f"今月の売上トップ商品は「{top_item['name']}」、売上は {top_item['sales']} 円です。"
webhook_url = "https://hooks.slack.com/services/XXX/YYY/ZZZ"

requests.post(webhook_url, json={"text": message})
```

これだけで業務の自動化が完了します。これが「現場で使えるプログラミング」です。

---

## 4. よくある落とし穴と現場のTips

### ✅ データ型に注意しよう

* `int`と`str`の混在によるエラー
* null値がある場合の処理忘れ

### ✅ 小さく試すことの重要性

いきなり全体を組むのではなく、**1行ずつ動作を確認しながら積み上げる**ことが、バグを減らす最大のコツです。

### ✅ 書く前に考える：「どうしたいか」を言語化

コードを書く前に、\*\*「目的」→「手順」→「実装方法」\*\*の順で整理してみましょう。これが現場でスムーズに開発するための土台になります。

---

## 5. 発展：プログラミングを「仕組み化」へ昇華させる

コードが書けるようになると、次は\*\*「自動化」や「再利用性」\*\*を意識するようになります。

たとえば、上記の処理を関数にまとめたり、複数のCSVをバッチ処理したり、Docker化してCI/CDパイプラインに組み込んだりと、現場では「仕組み化＝スケーラブルな開発」が求められます。

```python
def notify_top_sales(csv_path, webhook_url):
    df = pd.read_csv(csv_path)
    top_item = df.sort_values(by="sales", ascending=False).iloc[0]
    message = f"今月の売上トップ商品は「{top_item['name']}」、売上は {top_item['sales']} 円です。"
    requests.post(webhook_url, json={"text": message})
```

---

## 6. まとめ：プログラミングの「定義」を自分の武器にする

### ✅ プログラミングは「指示の設計」である

### ✅ 現場では「自動化」「再現性」「保守性」が求められる

### ✅ 実装だけでなく、**思考法・設計力・伝達力**が価値になる

---

### 🔮 今後の展望

LLM（GPT系）などの生成AIの登場により、「プログラムを書く」ことの意味は変わりつつあります。とはいえ、**「何を」「なぜ」やりたいのか**を設計する能力は、今後ますます重要になるでしょう。

---

 

## 📌 補足リソース

* Python公式：[https://docs.python.org/ja/3/](https://docs.python.org/ja/3/)
* pandas公式：[https://pandas.pydata.org/](https://pandas.pydata.org/)
* Slack Webhook API：[https://api.slack.com/messaging/webhooks](https://api.slack.com/messaging/webhooks)

---

ご意見・質問があれば、お気軽にコメント欄へどうぞ！
「いいね」やフォローも励みになります🙌
テスト初心者脱出講座 | [第1回]: ソフトウェアテストとは？


## 1. はじめに：その「動くからOK」本当に大丈夫？

現場で「コードは動いてるし問題ないでしょ」とリリースした後、
バグがユーザーの手元で爆発🔥──そんな経験、誰しもあるのではないでしょうか？

ソフトウェア開発における**テスト**は、ただの後処理でも形式的な儀式でもありません。
**不具合を未然に防ぎ、品質を守り、安心してリリースするための武器**です。

今回は、「テストって何？」という初歩的な疑問から、**ユニットテスト実装例**、
**現場でハマりやすい落とし穴**、**TDDや自動化への展望**まで、実践的に解説します！

---

## 2. ソフトウェアテストとは？ざっくり整理しよう

### テストの目的

* バグの早期発見・修正
* 要件との整合性確認（仕様通り動くか？）
* リファクタリングや新機能追加時の安心材料

### 主なテストの種類

| テストレベル  | 説明                   |
| ------- | -------------------- |
| ユニットテスト | 関数・メソッド単位の最小テスト      |
| 結合テスト   | 複数のユニットを組み合わせて確認     |
| システムテスト | アプリケーション全体を通しての動作確認  |
| 受け入れテスト | ユーザー視点で仕様が満たされているか確認 |

**今回の焦点は「ユニットテスト」**。なぜなら、最も書きやすく、即効果を実感できるからです。

---

## 3. Pythonで始めるユニットテスト：pytestで実践

まずはシンプルな関数をテスト対象にします。

### ✅ テスト対象の関数（`calculator.py`）

```python
def add(a, b):
    return a + b

def divide(a, b):
    if b == 0:
        raise ValueError("0では割れません")
    return a / b
```

### 🧪 テストコード（`test_calculator.py`）

```python
import pytest
from calculator import add, divide

def test_add():
    assert add(3, 5) == 8
    assert add(-1, 1) == 0

def test_divide():
    assert divide(10, 2) == 5

def test_divide_zero():
    with pytest.raises(ValueError):
        divide(10, 0)
```

### 📌 実行方法（pytest）

```bash
pytest test_calculator.py
```

### ✅ 実行結果（一部）

```
3 passed in 0.05s
```

たったこれだけで、安全確認ができるようになりました。
「この関数壊れてないかな？」と不安になったらすぐ `pytest`！

---

## 4. 現場で役立つTipsとハマりがちな落とし穴

### 💡Tips

* **関数を書く前にテストを書く（TDD）**：思考整理に有効
* **CIと連携**：GitHub Actionsなどで毎Push時にテスト自動実行
* \*\*pytestのマーク（`@pytest.mark.parametrize`）\*\*で効率化

```python
@pytest.mark.parametrize("a,b,result", [
    (2, 3, 5),
    (-1, -1, -2),
    (0, 0, 0)
])
def test_add_param(a, b, result):
    assert add(a, b) == result
```

### ⚠️ よくある落とし穴

* **「とりあえず動いたからテスト不要」思考**
* **複雑すぎるテストコード → 保守困難**
* **モックの使い方が不自然 → 本物と挙動が違う**

---

## 5. 応用編：TDDとテスト自動化への一歩

テストは書いて終わりではありません。
次のステップに向けて、以下の観点でスキルアップを目指しましょう。

### 🔁 TDD（Test-Driven Development）

1. まず**失敗するテストを書く**
2. 最低限動くコードを書く
3. テストが通ったらリファクタリング

これにより、**仕様に沿った設計**と**安全なリファクタリング**が可能に。

### 🤖 自動化による継続的テスト

GitHub Actionsなどを使い、以下を自動化できます：

* Pull Request作成時にpytest実行
* カバレッジレポートの生成
* デプロイ前のチェック

```yaml
# .github/workflows/test.yml
name: Run Pytest
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
      - run: pip install -r requirements.txt
      - run: pytest
```

---

## 6. おわりに：テストは開発者の盾であり、武器である

### ✅ テストを書くメリット

* 安心してコードを変更できる
* バグが早期に見つかる
* チーム開発での信頼性向上

### 🛠️ デメリット（あえて言えば）

* 最初は学習コストがかかる
* 書きすぎて逆に保守が複雑になる可能性

しかし、**「壊れたコードを本番で出す」コストはもっと高い**。
だからこそ、まずは小さな関数からでもテストを書きましょう。

---

## ✅ まとめ

| 項目      | 内容                   |
| ------- | -------------------- |
| 対象技術    | Python + pytest      |
| 得られるスキル | ユニットテストの書き方 / 自動化の基礎 |
| 難易度     | 初級〜中級                |
| おすすめ対象者 | 若手エンジニア / 品質改善に悩む方   |

**この記事を読み終わった今、ぜひ一つでも関数にテストを書いてみてください。
その一歩が、あなたの開発体験をきっと変えてくれます！**

---

🧵 ご質問や改善提案があれば、ぜひコメントで教えてください！
次回は「テストケースとその書き方」も解説予定です 🙌

---
TypedDictをラッパー関数作成に活用する

## はじめに

以前、TypedDictを利用した「Options Objectパターン」の手法について  
ふれていたが、使いどころが模索できていないままでした。  
今回はコードを書く中で見つけた使いどころについて紹介します。

https://qiita.com/mistylady/items/6b957f17cf68233b91fd

## ラッパー関数作成時での使いどころ

下記は「pywinauto」を利用し、指定要素の子に位置する  
ボタン要素を取得する処理です。  

```py
parent_window_specification_object.child_window(
    class_name="Button", title="保存"
)
```

この処理をラップする際には、  
引数で親要素オブジェクトと検索条件の2種類を渡す必要がありますが  
必ず渡す親要素オブジェクトと、子要素の検索条件を分離した方が読みやすくなります。 

その点を考慮し、TypedDictを利用して
引数を役割をごとに分離した以下のようなラッパー関数を作成してみました。


```py
from typing import Any, NotRequired, TypedDict

from pywinauto import WindowSpecification

# child_window()に渡す引数の管理
ChildSearchCriterias = TypedDict(
    "ChildSearchCriterias",
    {"class_name": NotRequired[str], "title": NotRequired[str], "found_index": NotRequired[int]},
)


def child_window_wrapper(
    parent_element: WindowSpecification, child_search_criterias: ChildSearchCriterias
) -> WindowSpecification:
    """child_windowメソッドのラッパー関数
    Args:
        parent_element (WindowSpecification): 親要素のオブジェクト
        child_search_criterias (ChildSearchCriterias): 子要素の検索条件
        
    Returns:
        WindowSpecification: 探索結果のオブジェクト
    """

    criterias: dict[str, Any] = {}
    if child_search_criterias.get("class_name"):
        criterias["class_name"] = child_search_criterias["class_name"]
    if child_search_criterias.get("title"):
        criterias["title"] = child_search_criterias["title"]
    if child_search_criterias.get("found_index"):
        criterias["found_index"] = child_search_criterias["found_index"]

    return parent_element.child_window(**criterias)
```

このように設計する利点としては、ラッパー関数を呼び出す際の渡す引数が
(必須要素, {オプション要素})の形式となり、可読性が向上しています。

ラッパー関数を呼び出す際は、以下のようになり役割ごとで分離でき、  
メソッド引数についても、引数名指定と同じように利用ができるのも利点です。

```py
# ラップせずに利用(比較用)
parent_window_specification_object.child_window(
    class_name="Button", title="保存"
)

# 自作ラッパー関数を利用
child_window_wrapper(
    parent_window_specification_object,
    {"class_name": "Button", "title": "保存"},
)
```

補足として、ラッパー関数の引数にDict型で渡すので、  
そのままキーワード可変長引数(**kwargs)で、ラッピング対象へ渡すことも可能です。  
しかし、その場合だと誤った引数名を指定して渡してしまう可能性が考えられます。
その部分についても、TypedDictを使うことで予防しています。

## あとがき
Pythonにおける型定義関連の部分はバージョンが上がるごとに充実してきており  
個人的には注目している箇所の1つであり、どんどん使いたい派です。

今回はpywinautoを一例として出したが、  
他にもselenium、playwrightのラッパー関数を作成する場合や  
Requestsのように引数が多数あるメソッドをラップする際にも  
活用できると考えています。


## 参考
- pywinauto.application module — pywinauto 0.6.8 documentation
	- https://pywinauto.readthedocs.io/en/latest/code/pywinauto.application.html?highlight=child_window#pywinauto.application.WindowSpecification.child_window
ChatGPTでMarkdownをきれいに出力させる「魔法の言葉」

![ChatGPT Image 2025年6月24日 00_46_11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/357904/b7b57651-60e9-4107-a446-9dda530aff36.png)

# ChatGPTでMarkdownをきれいに出力させる「魔法の言葉」

みなさん、こんな経験はありませんか？

> ChatGPTにMarkdownでコードブロックを含む文章を出力してもらいたいのに、  
> コードブロックの中のコードブロックが壊れて表示されてしまう……！

そう、ChatGPTは通常のコードブロック（```）にはとても素直に対応してくれるのですが、  
その中にさらにコードブロックが登場すると、もう大混乱。  
まるで**マトリョーシカ状態のコード地獄**。

---

## 魔法の言葉で一発解決

でも安心してください。  
そんなときには、とっておきの魔法の呪文を唱えるのです。

> **出力する際はバッククォートを４つ用いて Markdown を表現してください**

この一文をプロンプトに加えるだけで、ChatGPTは中にコードブロックを含んだMarkdownを、  
とてもきれいに、しかもコピペしやすく整えてくれます！

---

## コードブロックとは

たとえば、Markdownでコードブロックを含むコードを書く場合、以下のように書くことができます！

````markdown
```bash
$ echo コードブロックサンプル
コードブロックサンプル
```
````

このように書くと、最終的な表示はこうなります。

```bash
$ echo コードブロックサンプル
コードブロックサンプル
```

---

## 実際にChatGPTで試してみた

ある日、GitHubのPRにコメントするMarkdownを整形してもらおうと、こんなプロンプトを投げてみました。

````plaintext
下記の内容をGithubのPRにコメントしたいです  
丁寧な表現に変更してください  
出力形式はそのままコピーできるように Markdown にしてください  
=====  
echo には -n オプションがある。これを使うと最後の改行が消える  

e.g.  
```bash  
$ echo a; echo b; echo c  
a  
b  
c  
```  

```bash  
$ echo -n a; echo -n b; echo -n c  
abc  
```  
````

すると……  
うまくいかず、コードブロックが崩れてしまいました

![スクリーンショット 2025-06-24 0.22.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/357904/e044764d-c961-4482-ba5c-d11e54ce176d.png)

---

## 魔法の言葉を添えてみた

そこで、先ほどの魔法の一文をそっと添えてみたのです。

````plaintext
下記の内容をGithubのPRにコメントしたいです  
丁寧な表現に変更してください  
出力形式はそのままコピーできるように Markdown にしてください  
出力する際はバッククォートを４つ用いて Markdown を表現してください ← 追加した一行  
=====  
echo には -n オプションがある。これを使うと最後の改行が消える  

e.g.  
```bash  
$ echo a; echo b; echo c  
a  
b  
c  
```  

```bash  
$ echo -n a; echo -n b; echo -n c  
abc  
```  
````

結果は…見事！Markdownが崩れることなく美しく出力されました

![スクリーンショット 2025-06-24 0.22.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/357904/5491c61c-6832-4c98-bbc6-9985594f2ab0.png)

---

## このQiita記事も魔法の力で

ちなみにこの記事も、ChatGPTに書いてもらっています。  
当然ながら、この記事の中にも複数のコードブロックが登場しています。

そこで、今回使った魔法の言葉はこうです：

> **出力する際はバッククォートを５つ用いて Markdown を表現してください**

そう、 **魔法の強さはコードブロックの入れ子の深さに応じて進化する**のです！

---

## まとめ

- Markdown出力で困ったら「バッククォートの数」を増やしてみる
- ChatGPTには **「出力時に使うバッククォートの数」を伝えると正確に出力してくれる**
- 今回の魔法の言葉：
  - コードブロック内にコードブロック → `バッククォート４つ`
  - さらにその中に…… → `バッククォート５つ`
- 最後に：**コピペしやすい出力が一番大事！**

---

## おまけ：実践あるのみ！

もし今、ChatGPTに複雑なMarkdownを書かせたいと思っていたなら、  
ぜひこの魔法の一文を加えて試してみてください。

そして、その美しい出力結果に感動したら、  
このQiita記事にも「いいね」していただけると嬉しいです！

---

Happy Prompting 🧙‍♂️✨
【Prisma】npx prisma migrate dev 時にテーブル作成されないエラー

## はじめに

Prismaを使って`schema.prisma`ファイルを元に`npx prisma migrate dev` でテーブル作成を行なった際、以下エラーになったのでその解決法を載せておきます！

```
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "postgres", schema "public" at "aws-0-ap-northeast-1.pooler.supabase.com:6543"

(ここでカーソルが止まり何も実行されない...)

```

## 🪄  解消法

手順１：`.env`へDATABASE_URLだけでなく、**DIRECT_URL** も設定する。
```.env
DATABASE_URL=postgresql:{あなたの設定URL}:6543/postgres
DIRECT_URL=postgresql:{あなたの設定URL}:5432/postgres
```

手順２：schema.prismaファイル > `datasource db`へ**directUrl**を追加する。
```schema.prisma
generator client {
  provider = "prisma-client-js"
  output   = "../generated/prisma"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}
```

👉 以上です！ この状態で再度、`npx prisma migrate dev`してみてください！
Mat3raプラットフォームでジョブを作成・実行する方法

ジョブの作成は3つのステップで行います。
 
まず、結晶構造、格子定数、原子位置などの材料システムを指定します。

次に、バンド構造計算や分子動力学計算など、どのワークフローを実行するかを指定します。

最後に、システムのサイズ、求める精度、利用可能なリソースに応じて、計算パラメータを指定します。
例えば、必要なノード数やノードあたりのプロセッサ数などです。

では、材料システムはどのように指定するのでしょうか？

materaプラットフォームにはいくつかの方法があります。

ローカルのパソコンからcifやvasp poscar形式の構造ファイルをアップロードできます。

また、materaユーザーコミュニティによって提供された1万以上の構造が登録されているマテリアルバンクで検索することも可能です。

さらに、Materials Projectなどの外部ソースから構造をインポートすることもできます。

もしそれでも目的の構造が見つからない場合は、「作成」ボタンを押して、Materials Designerで材料を一から設計してください。

格子の種類、格子定数、原子位置を指定すれば、任意の構造を生成できます。

次に、ワークフローステップはどのように指定するのでしょうか？

ワークフローバンクから検索したり、ゼロから作成したりできます。

materaワークフローバンクには一般的なワークフローが多く登録されています。

必要に応じて、サブワークフローを指定し、ユニットやフレーバーを追加できます。

材料とワークフローが準備できたら、ジョブデザイナーに進みます。

「新しいジョブを作成」をクリックします。
 既存のプロジェクトにジョブを整理するか、新しいプロジェクトを作成できます。

必要に応じて材料を一つまたは複数選択します。

ワークフローを選び、重要なパラメータを調整します。

計算タブに移動し、クラスター、キュータイプ、ノード数、ノードあたりのプロセッサ数を選択します。

保存してジョブデザイナーを終了します。

これでジョブ作成が完了し、実行のために送信できる状態になりました。

Mat3ra.comにアクセスして、ぜひ自分で試してみてください。
 ご視聴いただき、また当プラットフォームをご利用いただきありがとうございます。

:point_right: 無料でお試しください：https://mat3ra.com/?utm_source=qiita&utm_medium=newsletter

ビデオを見る: https://www.youtube.com/watch?v=hT1VBFH7HHo
線形微分方程式　微分演算子と逆演算子

### 微分演算子
* $y=y(x)$：任意関数
* $D=\frac{d}{dx}$：微分演算子
としたとき、
* $y'=\frac{d}{dx}y=Dy$
#### 法則
* $(T+U)y=Tu+Uy$
* $(T-U)y=Tu-Uy$
* $TUy=T(Uy)$
##### 多項式演算子
* 例：$f(D)=aD^2+bD+c$
* 交換則：$f(D)g(D)=g(D)f(D)$
* 線形性：$f(D)(au+bv)=af(D)u+bf(D)v$
* $f(D)e^{αx}=f(α)e^{αx}$
* $f(D)[e^{αx}y]=e^{αx}f(D+α)y$

### 逆演算子
* $\frac{1}{D} F(x) = \int F(x) dx$
* $\frac{1}{f(D)} e^{\alpha x} = \frac{1}{f(\alpha)} e^{\alpha x}$ ($f(\alpha) \neq 0$)
* $f(D) e^{\alpha x} = f(\alpha) e^{\alpha x}$
* $\frac{1}{f(D)} F(x) = e^{\alpha x} \frac{1}{f(D+\alpha)} [e^{-\alpha x} F(x)]$
    * $f(D) e^{\alpha x} y = e^{\alpha x} f(D+\alpha) y$
* $\frac{1}{D-\alpha} F(x) = e^{\alpha x} \int e^{-\alpha x} F(x) dx$
    * (3)で $f(D-\alpha)$ としている。
* $\frac{1}{(D-\alpha)^n} F(x) = e^{\alpha x} \int \dots \int e^{-\alpha x} F(x) dx \dots dx$
* $\frac{1}{f(D)} [k \cos ax]$
    * $f(D) (k \cos ax + i k \sin ax)$ : オイラーの公式利用
        * $\xi(x) + \eta(x) i$ の形になっている場合
    * $\xi(x) = \frac{1}{f(D)} [k \cos ax]$, $\eta(x) = \frac{1}{f(D)} [k \sin ax]$
    * $f(ia) \neq 0$ のとき：
        * $\frac{1}{f(D)} [k e^{iax}] = \frac{1}{f(ia)} k e^{iax}$
    * $f(ia) = 0$ のとき：
        * $\frac{1}{D^2 + a^2} \cos ax = \frac{1}{2a} x \sin ax$
        * $\frac{1}{D^2 + a^2} \sin ax = -\frac{1}{2a} x \cos ax$
* $\frac{1}{1 - aD} = 1 + aD + a^2 D^2 + a^3 D^3 + \dots$
* $\frac{1}{f(D)} [e^{\alpha x} F(x)] = e^{\alpha x} \frac{1}{f(D+\alpha)} F(x)$
2025/06/19 〜 2025/06/23 振り返り

## 今週の行動
2025/06/12 〜 2025/06/16 で休暇をいただいていたので、久しぶりの振り返りとなります。

まずは、先週出したアクションから。

:::note info
話し合いや議論をする際には、以下のどれかのうち少なくとも1つを明確にする

決めたいことは何か？
気にしていることは何か？
障壁となっているものは何か？
:::

（結論、今週はチームメンバーが基本通常時の半分である2人になっていていたので、あまり議論するような場面がなかったです。）

### 良かったこと
- 障害発生時に、速やかに原因特定して、解消することができた
- 人数が少ないからこそ、自分の意見を多く出したり、何かに対処する時の方法を多く提示できた

### 伸び代
- 1人作業の時に、誰か他の人に聞くことをあまりしていなかった
    - AIの活用に固執していたせいで、人に聞くという選択肢を取るのが遅くなった
        - AIエージェントをうまく使えるようになりたいという気持ちが先走った
        - 社内のことやプロダクトの仕様に関しては、AIエージェントに聞くよりも
        社内の「人」に聞くのが最強！

## 来週のアクション
:::note info
AIを活用することにとらわれすぎず、人に聞くという選択肢を取れるよう、
自分目線で不確実性の高いものを考える時は時間を決め、その時間を超えたら詳しい人に聞くこととする
:::
6/23

今日から研究中に考えたこと、やったことを記録していく。
# 4月から今日までの概要

### 一般化hough変換
金魚の複数個体追跡のアルゴリズム開発を引き続きすることに。

課題となっているのはオクルージョン発生時。
円や直線の検出アルゴリズムとして知られているhough変換が、図形の欠損にも強いことに目をつけそれを一般化した**一般化hough変換**を使ってみることに。

（hough変換の投票空間において投票の集まる一点が光る様とニューラルネットワークのニューロンが光る様を関連づけられるのではないかという教授の言葉もあり。私がディープラーニングに興味があることとも関係しての提案）

実装はできたが、計算量が多い。精度はそこそこ。
重くなる原因はフレームごとにテンプレートを1700枚ほど使い、オクルージョン画像のエッジ点全てに対し計算が必要であること。

#### 計算時間削減案①GPUを用いる
まず初めに計算時間を減らす手段としてGPUを用いることを考えたが、opencvに実装されている一般化hough変換にはCUDA対応のものがなく断念。

#### 計算時間削減案②CPUで並列処理
実装自体はできて早くはなったがまだまだ重い。

#### 計算時間削減案③クラスタリングによるテンプレート削減
R-tableによるクラスタリングが妥当だと考えるが、Rtableがテンプレートにより形が異なること、R-tableが回転、スケールには直接は対応していないために断念。可能性はまだある。
その他にもインプット画像を見てより"良い"テンプレートを選ぶような機械学習モデルも考えたが実装はしていない。（できるのかも不明）


### OC-SORTを試してみる
hough変換では正直これ以上の精度向上はない上、計算量削減もうまく行っていないということもあり一度hough変換を離れてみることに。
MOT系のアルゴリズムをいくつか見て、オクルージョンに比較的強いという点、学習データが比較的少なくて済むという点に目をつけOC-SORTでの実装を試みる。

ますはデモ動画を回せた。金魚画像でのファインチューニングも行けた！
と思ったらなーんにも追えてない。

学習させるときに薄々思ったけどもしかしたら動画じゃないとダメなのかも？MOT初心者すぎてわかんない。
動画だとしたらそんなデータ用意できない。

MOTで追ってるのってでかい四角で「このヘン！」って感じでなるべく厳密な位置を知りたい今回の研究には不向きなのかも。今回重心座標と頭の座標も欲しいから四角で囲えたとしてもまたそこから重心やら計算するのには骨が折れそう。

以上２点
・動画でないと学習できないなら100本単位で用意するのは無理
・結局大体の位置が追えてもそこから重心とか計算するのはまたハードルがありそう
ということでこの道も一旦なしかも。

# これから
ディープラーニングも捨ててはないけど、有名なアーキテクチャは学習データの関係であんま使えないかもなーとか思ったり。
先生が推してるのもあるし、hough変換にちょっと戻ってみようかな。（houghを推してるというかディープの方にあんまいい思い出がなさそうにも見えるけど。。）

今すぐできそうなものは**インプットの画像をわざとボロボロにする**こと。
エッジ点の数をわざと減らして計算量を減らす。
hough変換自体はかなり強力で割といい位置に、圧倒的な投票が集まってるからいくつか点をぶっこぬいてもいい線行くと思う。

その他の案としては**C++を勉強してopencvを自由にいじれるようになること**がある。
そうすればCUDA対応のhough変換も自分でかけるし、投票先の制限をかけることで計算量の削減ができるんじゃないかと考えている。

明日以降の私に期待！
競プロ日記#25/06/23

# AtCoder
[C - Uniqueness ](https://atcoder.jp/contests/abc398/tasks/abc398_c)
- シンプルにMapを使って実装できた（2回目の取り組みだったが正直1回目の時の記憶はなかった...。がそれで解けたのであればそれはそれで力が付いているということなのか...。）
- ただ1回目の解説ACの時の実装とは多少違っており、そのせいなのか微妙に実行に時間がかかってしまった
↓今回の実装
```
int main() {
    long long N;
    cin >> N;
    map<long long, vector<long long>> G;
    for (long long i = 1; i <= N; i++) {
        long long A;
        cin >> A;
        G[A].push_back(i);
    }
    long long ans = -1;
    long long max = 0;
    for (const auto& [key, value] : G) {
        if (value.size() < 2){
            if (key > max) {
                max = key;
                ans = value[0];
            }
        }
    }

    cout << ans << endl;
}
```
↓1回目の時の実装
```
int main() {
    int N;
    cin >> N;
    vector<int> A(N);
    map<int, vector<int>> d;

    for (int i = 0; i < N; i++) {
        cin >> A[i];
        d[A[i]].push_back(i);
    }

    for (auto it = d.rbegin(); it != d.rend(); ++it) {
        if (it->second.size() == 1) {
            cout << it->second[0] + 1 << endl;
            return 0;
        }
    }

    cout << -1 << endl;
    return 0;
}
```

[C - 403 Forbidden](https://atcoder.jp/contests/abc403/tasks/abc403_c)
- またしても解説AC
- setの配列で管理する
生成モデルの基礎知識10 役立ち情報

こんにちは。
最近、NVIDIA-Certified Associate: Generative AI and LLMs (NCA-GENL)を習得しました。
その際に知っておいた方が良い基礎知識とコードの書き方を共有したいと思います。
生成AIのチュートリアル:

https://github.com/Yuji-github/Gen_AI_Tutorial

LLMの構造の見える化：

https://bbycroft.net/llm


LLMトレーニングの早見表

|テクニック|モデルのアーキテクチャ|ナレッジトランスファー|モデルの軽量化|ホスティングの費用|精度|
|---|---|---|---|---|---|
|ファインチューン|オリジナルのまま|既存の知識の調整|オリジナルのまま|オリジナルのまま|向上する|
|刈り込み（Pruning）|オリジナルのまま|既存の知識を圧縮|コネクションのカット|安くなる|悪くなる|
|量子化|オリジナルのまま|既存の知識を圧縮|FP分が減る|安くなる|悪くなる|
|RAG|オリジナルのまま|新しい知識を使う|オリジナルのまま|オリジナルのまま|向上する（RAGのデータによる）|
|知識蒸留|新規のモデルになる|教師モデルから生徒モデルへ知識の蒸留|小さくなる|安くなる|向上する（１番良くなる）|
WEB業界で使用する技術をザックリつかむ

# はじめに
これまで組み込みやバックエンド開発を主に担当してきましたが、Web業界へ転職したことをきっかけに、Webアプリについて改めて学び直し、使用する技術や構成を整理・まとめています。

※ざっくり書いてChatGPTに補足させてそれっぽくしてます。使用している技術、記事の内容はチェックしているので、技術について全体像を何となく掴みたい人向けです。


# Web開発では何を作るのか？
Webアプリ開発では、主に以下の3つの層で構成されることが多いです。

[ フロントエンド ] ← ユーザーが操作する画面（HTML/CSS/JS）
       ↓↑ HTTP通信
[ バックエンド ] ← ロジック・API（Node.js, Python, Ruby, Java など）
       ↓↑ DBアクセス
[ データベース ] ← データの保存（MySQL, PostgreSQL, MongoDB など）

## フロントエンド開発
ユーザーが直接操作する、見える部分の開発を担当します。

### 主な技術
- **HTML**：ページの構造を定義
- **CSS**：スタイルやデザインを調整
- **JavaScript**：動きや動的な処理を実装

### フレームワーク／ライブラリ
- **React / Vue / Angular**：SPA（Single Page Application）の構築に使用
- **Next.js / Nuxt**：サーバーサイドレンダリングやルーティング対応

### 重要な概念
- **SPA（Single Page Application）**：ページを遷移せずに動的に切り替えるアプリ形式
- **状態管理**：`useState`（React）や Redux などでUIの状態を制御

## バックエンド開発
アプリケーションのロジック、データ処理、認証などを担います。

### 主な言語／フレームワーク
- **Node.js + Express**
- **Python + Django / Flask**
- **Ruby on Rails**
- **Java + Spring Boot**
- **PHP + Laravel**

### 主な役割
- APIの提供（REST / GraphQL）
- データベースとのやりとり
- 認証・セッション管理
- ファイルアップロードや外部サービスとの連携

## データベース
データの永続化を行う層です。ユーザーデータや投稿情報などを保存します。

### 主な種類と例
- **リレーショナルデータベース**：MySQL / PostgreSQL / SQLite
- **NoSQLデータベース**：MongoDB / Firebase Firestore

## 開発で使用する主なツール
- **VS Code**：コードエディタ
- **Git / GitHub**：バージョン管理・チーム開発
- **Docker**：開発環境の統一、仮想化

### デプロイ・運用
- **Vercel / Netlify**：フロントエンドのホスティング
- **Render / Railway / Heroku**：バックエンドやDBのホスティング
- **AWS / GCP / Azure**：スケールが必要な商用アプリ向けクラウドサービス

## 認証・セキュリティ
セキュリティやログイン機能に関わる技術です。

### 認証方式
- セッションベース認証
- JWT（JSON Web Token）
- OAuth（GoogleやGitHub連携ログインなど）

### セキュリティ対策
- **CORS**：クロスオリジンリクエスト制御
- **CSRF / XSS**：不正リクエストやスクリプト攻撃への対策
- **HTTPS**：通信の暗号化


# モダンWeb技術の特徴
- フロントエンドとバックエンドの**分離型構成**が主流
- フロントエンドは**SPA**、バックエンドは**APIサーバー**
- **CI/CD（継続的インテグレーション・デリバリー）**や自動テスト、クラウドデプロイが一般的
医療用超音波診断装置の動画情報の活用～その4　消化管粘膜病変の表示方法の発展～

「その3　消化管粘膜病変検出とその表示方法の新システムつくりの基礎」の最後で、エコー操作中に発見した病変をふくむそのスライスを３Ｄ表示することを試みた。
すなわち、
　show_slice_in_volume_2.py
あるいは、3DSliceViewer_2.py　
　である（閾値設定もこのコード内で指定し、main_pyvista_3d.pyと同じようなコードで、３D上でそのスライスを赤く表示した）

　今回はそれをさらにすすめ、　ターゲットスライス上にある「ポイント」（病変などの場所をピンポイントで示す）を青く表示できるようにした。
 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/bbf8412a-58ae-47b4-8522-4aa6eada2229.png)
click_view_center.py
スライスNoを指定すると、その平面を表示。そしてその平面内のターゲットポイントをクリック（赤まる）。すると、座標がでる。この座標とそのスライスの番号を控えておく。そして、そのふたつの値を、次に示す、 view_polyp_2.pyのコード内に入力し、実行すると。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/c541cb0c-e66d-420a-ac1c-29653dec79a7.png)

view_polyp_2.py
３Dを、外から観察

上の図で、ポイントの座標は、point_x = 493、point_y = 264、point_z = 92で、ポイントは胆のう内にある。なので、３D画像を外から見ても、点は存在しない。
しかし、胆のう内部にはいりこんだ内部からの視点では下記のように、ポイントがみえる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/5bef558b-d677-44cd-bea0-b861886ba0ad.png)

view_polyp_2.py
上と同じ３Dを、内から観察


次に、下図のように、ターゲットポイントを胆のうの外（point_x = 519、point_y = 273、point_z = 92）にもってくる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/5ef0dd39-f4fd-4397-aaa3-3776216a7f6d.png)

view_polyp_2.py
POIは胆のう外
そうすると、今度は、外からみた３D画像に、POI（青い点）が見える。（当然ながら）胆のう内部にはいってみても、POIはみえない（図は省略）




![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/8fafb75e-7beb-488a-94d2-b3e7b9a8f43f.png)
view_polyp_2.py
今回、POIが胆のう外にみえる


試しにに、下図のように、ターゲットポイントを胆のうの内外の境界（point_x = 505、point_y = 275、point_z = 92）にもってくるとどうなるか？すると、 胆のう外からの視点でも、胆のう内からの視点でも、両方みえるのである。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/10d1be7f-b617-411a-a9ad-3a73238c752f.png)
view_polyp_2.py
POIは胆のう内外の境界



![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/07479ddd-2a3e-4b98-af1e-4bf3a558d114.png)
view_polyp_2.py
今回、POIが胆のう外から半分みえる




![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3676736/9c2cc6c6-4492-4427-ac32-14fb559e12c6.png)
view_polyp_2.py
今回、POIは胆のう内からも半分みえる

 （参考）なお、画面の左下のスライダーを動かすと、青が透明にちかづき青が隠れたり、また青くみえるようになったりする。

　この、臓器内部からの視点は、いわゆる大腸CTで「まるで内視鏡をおこなっているように変化していく内部画像の表現」の第1歩である。しかし、エコーの、解像度の限界や多いアーチファクトの存在などのため、大腸CTのように「内視鏡をおこなっているように変化していく内部画像」を得るまでには、まだ時間が要しそうである。
【Next.js】Linkコンポーネントで遷移する際に処理を実行する方法

## 方法

`Link`コンポーネントの`onNavigate`に関数を渡すことで遷移する際に処理を実行できます。

```tsx
import Link from 'next/link'
 
export default function Page() {
  return (
    <Link
      href="/sample"
      onNavigate={() => {
        console.log('Navigating...')
      }}
    >
      サンプル
    </Link>
  )
}
```

`preventDefault()`を実行すると遷移をキャンセルできます。

```tsx
import Link from 'next/link'
 
export default function Page() {
  return (
    <Link
      href="/sample"
      onNavigate={(e) => {
        e.preventDefault()
      }}
    >
      サンプル
    </Link>
  )
}
```

## 参考

https://nextjs.org/docs/app/api-reference/components/link#onnavigate
API連携の設計パターン：return `{ error, response }` で非同期処理をシンプルに

# はじめに 

ReactでAPIを呼び出すとき、こんな風に書いていませんか？

```tsx
try {
  const res = await fetch(url);
  const data = await res.json();
  setData(data);
} catch (err) {
  setError(err);
}
```

一見シンプルですが、実際のアプリではこれを複数箇所で繰り返し、**try/catchが乱立**してしまうことも。

この記事では、非同期APIの呼び出し方をより簡潔に、再利用性も高く書けるようにする **「`{ error, response }` 形式で返す」設計パターン** をご紹介します。

# 問題：try/catchがあちこちに増える

APIを複数呼び出すアプリや、再リクエスト処理などがあると、try/catch構文がどんどん増えて、可読性が下がってしまいます。

また、errorハンドリングが不統一になったり、呼び出し側のコードが煩雑になります。

# 解決策

> API関数の中でエラーハンドリングし、構造化して返す

例えばポケモンAPIを呼び出す関数を以下のように定義します：

```ts
async function fetchPokemon(id: number): Promise<{
  error: Error | null;
  response: any | null;
}> {
  try {
    const res = await fetch(`https://pokeapi.co/api/v2/pokemon/${id}`);
    
    if (!res.ok) throw new Error(`Error fetching pokemon #${id}`);
    
    const data = await res.json();
    return { error: null, response: data };
  } catch (err) {
    return { error: err as Error, response: null };
  }
}
```

*呼び出し側はシンプルに*

```tsx
const { error, response } = await fetchPokemon(1);

if (error) {
  setError(error);
} else {
  setPokemon(response);
}
```

# このパターンのメリット

1. **呼び出し側のロジックが平坦になる**

try/catchを書かなくてよく、状態更新やUI処理に集中できます。

2. **error処理の一貫性**

すべてのAPIが `{ error, response }` 形式で返ってくる前提なので、共通処理がしやすくなります。

3. **テストやmockが楽になる**

関数の出力を模倣しやすく、`{ error, response }` をそのまま返せばいいのでユニットテストが簡潔になります。

# カスタムフックとの組み合わせ例

この設計は `useEffect` やカスタムフックとの相性も抜群です：

```tsx
useEffect(() => {
  let ignore = false;

  async function fetchData() {
    setLoading(true);
    setError(null);

    const { error, response } = await fetchPokemon(id);
    
    if (!ignore) {
      if (error) setError(error);
      else setPokemon(response);
      setLoading(false);
    }
  }

  fetchData();
  return () => { ignore = true };
}, [id]);
```

# 他の一般的な設計との比較

| 方法                        | 特徴                                 |
| ------------------------- | ---------------------------------- |
| `try/catch` を呼び出し元で書く     | 標準的・明示的・柔軟。シンプルな用途では適切。            |
| `{ error, response }` を返す | 呼び出し側が平坦で扱いやすい。小中規模に向く。            |
| `Result<T, E>` 型（fp-ts等）  | より厳格な型安全と関数型スタイル。導入コストが高め。         |
| React Query / SWR を使う     | 非同期管理・キャッシュ・リトライなどを自動化。中大規模では有力候補。 |

**🛠 改善アイデア**

**1. ジェネリクスで型安全を強化**

APIの返却型を指定できるようにすることで、より堅牢に：

```ts
type ApiResult<T> = {
  error: Error | null;
  response: T | null;
};
```

**2. HTTPステータスの保持**

追加情報を持たせたい場合は `status` を含める：

```ts
return { error: null, response: data, status: res.status };
```

**3. AbortController 対応**

必要に応じてキャンセル対応も組み込めます：

```ts
async function fetchData(signal?: AbortSignal): Promise<ApiResult<T>> {
  const res = await fetch(url, { signal });
}
```

# まとめ

| 従来のやり方                     | このパターン                       |
| -------------------------- | ---------------------------- |
| try/catchを呼び出し側で毎回書く       | API関数の中で処理を閉じて構造化して返す        |
| catch漏れ・error処理のばらつきが起きやすい | 呼び出し側は `error != null` の確認だけ |

非同期処理が絡むReactアプリでは、**副作用の責務を関数に閉じ込める**設計がとても重要です。

**🧠 補足**
> { error, data } パターンは React Query と親和性が高い

React Query や SWR では data と error という形で非同期の状態を表現します。
したがって、この設計は、軽量な React Query 的API設計とも言えます。
生成モデルの基礎知識9 Operator Fusion & Dynamic Batching

こんにちは。
最近、NVIDIA-Certified Associate: Generative AI and LLMs (NCA-GENL)を習得しました。
その際に知っておいた方が良い基礎知識とコードの書き方を共有したいと思います。
生成AIのチュートリアル:

https://github.com/Yuji-github/Gen_AI_Tutorial

１．Operator Fusionとは？（モデルの運用・Inference）
オペレーター・フュージョンとは、小さな操作を実行する複数の連続するループを、より効率的な単一のループに結合する最適化手法で、ループ制御のオーバーヘッドが削減され、さらなるベクトル化最適化が可能になり、キャッシュ局所性が向上する。

LLMの運用ではオーバーヘッドが問題
各ループのイテレーションでは、ループ制御メカニズムのためにオーバーヘッドが発生する。
複数のループを融合することで、中間ループのこのオーバーヘッドが排除され、処理パイプラインが効率化。
例えばReLUを単一のループに結合することで、ループ制御のオーバーヘッドを削減できる。

サンプルコード
```
import numpy as np

def fused_operation(x):
   return np.exp(x) * np.log(x) 

x = np.array([1, 2, 3, 4])
result = fused_operation(x)
```

２．Dynamic Batchingとは？（モデルの運用・Inference）
ダイナミックバッチ処理は、バッチが満杯になった時、または最大時間が経過したときにバッチを実行する。
これにより、高トラフィック期間においてもスループットを維持しつつ、従来のバッチ処理と比較してレイテンシー（遅延）が改善する。

![batching.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4108653/3ca7b766-bda7-49a1-b2bf-a8259dfaabac.png)
「推移的関数従属がないこと」ではNG？第三正規形を正しく理解しよう

## 1. まえがき

データベースにおける第三正規形(3NF)の定義について、こんな説明をよく見ます。
**「推移的関数従属がないこと」**

こちらの説明に待ったをかけたい！というのがこの記事の趣旨です。
私自身もこの理解であったため、ボイス・コッド正規形の学習時に混乱してしまいました。
※この話はあとがきにて記載します。

#### そもそもですが、第三正規形の定義は以下です。
>関係スキーマRが3NFであるとは、すべての関数従属***X→A***に対して、以下のいずれかが成り立つときである
>1. ***X***がスーパーキーである
>2. ***A***が候補キーに含まれる属性である
>※自明な関数従属については省略

推移的従属関係が存在しても、その結果(右辺)が主属性である場合においては、3NFとしては許容されます。

これだけだと難しいと思いますので、この辺りの「許容される場合」「許容されない場合」について、用語の解説も含めて、かみ砕きながらまとめたいなと。興味があればお付き合いください。

## 目次
こんな順番で説明していきたいです。
1. 前置き(と3NFの定義) ✅
2. 用語の解説
   - スーパーキー
   - 候補キー
   - 主属性
   - 推移的関数従属
3. 許容される／されない推移的従属の具体例
   - 許容されないケース
   - 許容されるケース
4. まとめ
5. あとがき(私の混乱)


## 2. 用語の解説  
（※他でもいくらでも説明されていると思うので最小限に…）

#### ■ スーパーキー

スーパーキーとは、関係の中で**タプル（行）を一意に識別できる属性の集合** です。  
ただし、最小である必要はなく、余分な属性を含んでいてもOKです。  
つまり、**「それが決まれば行が決定できる要素」** といえます。

#### ■ 候補キー

候補キーは、スーパーキーのうち、**最小の属性集合** です。  
つまり、**「行を決定できる要素のうえに、余計なものが含まれていない」** ものです。

#### ■ 主属性

主属性は、**候補キーに含まれる属性** のことです。  
候補キーが複数の属性から構成されている場合でも、**その構成要素はすべて主属性** とみなされます。

---

##### 候補キーと主属性の具体例

```text
例：ある学生の科目・学期ごとに成績を記録しているテーブル

関係スキーマ: 成績(学生ID, 科目ID, 学期, 成績) 
候補キー: (学生ID, 科目ID, 学期)
関数従属: (学生ID, 科目ID, 学期) → 先生
```

このとき、各属性の主属性かどうかは以下の通りです：

| 属性       | 主属性か？     |
|------------|----------------|
| 学生ID     | 主属性      |
| 科目ID     | 主属性      |
| 学期       | 主属性      |
| 成績       | 非主属性 |

#### ■ 推移的関数従属
(こちらも最小限に...)

推移的関数従属とは、**ある属性が別の属性を介して間接的に決定される関係**のことです。


関係 R において、以下のような関数従属があるとします：

- A → B  
- B → C  

このとき、**A → C** が成り立つならば、C は A に**推移的に従属している**と言います。

<br>

ここで先の定義に戻りますが、3NFにおいては推移的関数従属があっても、右辺が主属性であれば許容されます。

つまり、**推移的従属そのものがNGなのではなく、非主属性が他の非主属性に依存している場合に限って問題**となります。

この点が、「推移的関数従属がないこと」という簡略化された説明と、定義とのズレを生む原因です。

冒頭の **「推移的関数従属がないこと」** という説明のは、恐らく **「非主属性が他の非主属性に依存している場合を排除する」** という意図で使われているのだと思いますが、こちらは間違っておりません。

それでは「許容されない推移的従属」「許容される推移的従属」について具体例を見ていきましょう。


## 3. 許容される／されない推移的従属の具体例


#### ❌許容されない推移的従属のケース

推移的関数従属の右辺が**非主属性**である場合、3NFに違反します。
第三正規形を知っていればわかりそうなケースですね。

```text
例：社員とプロジェクトが決まると上司が決定される関係
※ただし、各上司は1つの部署に所属している

関係スキーマ: 配属(社員ID, プロジェクトID, 上司, 部署)
候補キー: (社員ID, プロジェクトID)
関数従属:
  (社員ID, プロジェクトID) → 上司
  上司 → 部署
```
非主属性が右辺になっている推移的関数従属となるのでNGです。


#### ✅許容される推移的従属のケース

推移的関数従属の右辺が**主属性**である場合、3NFとしては許容されます。

```text
例：学生と教科が決まると先生が決定される関係
※ただし、各先生が担当する教科は1つのみ

関係スキーマ: 履修登録(学生ID, 教科, 先生)
候補キー: (学生ID, 教科)
関数従属:
  (学生ID, 教科) → 先生
  先生 → 教科
```

- 候補キー → 非主属性 
- 非主属性 → 主属性　

の二つの従属あり、推移的従属にあるといえますが、
関係の右辺の「教科」が主属性であるため、3NFとしては許容されています。


## 4. まとめ

第三正規形（3NF）は、単に「推移的関数従属がないこと」と理解されがちですが、  
実際には「**非主属性が他の非主属性に推移的に従属している場合に限って違反となる**」というのが正確です。

#### では、なぜ「許容される推移的従属のケース」を理解する必要があるのでしょうか。
その答えは簡単で、**まだ正規化される余地があるからです！** 
<br>
⇒「ボイス・コッド正規形」に続く....


## 5. あとがき(私の混乱)
許容される例にも出したこちらの例、実は他の方の記事のものです。
```text
関係スキーマ: 履修登録(学生ID, 教科, 先生)
候補キー: (学生ID, 教科)
```
https://qiita.com/ParisMichael/items/0c6ed4ef56d599aa5daa

これを理解しようとしたのですが、3NFを「推移的関数従属がないもの」と理解していたばかりに、**「推移的関数従属がないはずなのに、推移的関数従属を分解しようとしているの？どういうこと(◎_◎;)」** と、大混乱。

なんとか理解しようとした内容を記事としてまとめさせていただきました。

きっかけを与えてくれた執筆者様、ありがとうございました。
JSTQB TA 頻出用語

# JSTQB Advance Level TA (Test Analysis)
　JSTQB Advance Level TAとは、テストアナリスト向けの国際ソフトウェア資格のひとつです。JSTQB Advance Levelの資格としては３つ存在しており、テストマネージャ、テストアナリスト、テストテクニカルアナリストのうちのひとつになります。

 私は、2025/3/Eに一度受験を行いましたが、残念ながら落ちてしまいました。
 再度挑戦するため、学習内容を綴っていこうと思います。

下記は本試験を運営しているJSTQBが一般公開しているシラバスになります。
[JSTQB TA シラバス](https://jstqb.jp/dl/jstqb.jpdlJSTQB-SyllabusALTA_V311.J03.pdf)
[JSTQB ホームページ]()


## JASTQB TA 頻出用語
### 基本用語
| 用語                         | 説明                               |
| :------------------------- | :------------------------------- |
| **テストベース (Test Basis)**    | テストの根拠となるドキュメント（仕様書、要件定義書、設計書など） |
| **テストケース (Test Case)**     | 実行するテストの条件・入力値・期待結果を記述したもの       |
| **テスト目的 (Test Objective)** | テストで達成したい目的（例: 欠陥の発見、品質評価）       |
| **テスト条件 (Test Condition)** | テストすべき事象や機能、状態、または品質特性           |
| **テストスイート (Test Suite)**   | 複数のテストケースをまとめたもの                 |
| **テスト実行 (Test Execution)** | テストケースを実行し、実結果を取得する活動            |
| **期待結果 (Expected Result)** | テストケース実行時に期待される動作や出力             |
| **実結果 (Actual Result)**    | テストケース実行時の実際の動作や出力               |
| **欠陥 (Defect/Bug)**        | ソフトウェアの誤りや問題点                    |
| **障害 (Failure)**           | 欠陥が実行時に現れて異常な動作を引き起こすこと          |

### テストプロセス関連
| 用語                              | 説明                               |
| :------------------------------ | :------------------------------- |
| **テスト計画 (Test Plan)**           | テストの目的、範囲、方針、体制、スケジュールなどをまとめた計画書 |
| **テスト設計 (Test Design)**         | テスト条件を基にテストケースや手順を作成する工程         |
| **テスト実装 (Test Implementation)** | テストデータや環境を準備し、実行可能な形にする工程        |
| **テスト実行 (Test Execution)**      | テストケースを実行する工程                    |
| **テスト完了 (Test Completion)**     | テストの実施結果をまとめ、完了手続きを行う工程          |


### テスト技法・レベル・タイプ
| 用語                               | 説明                 |
| :------------------------------- | :----------------- |
| **ホワイトボックステスト (White-box Test)** | 内部構造を考慮したテスト       |
| **ブラックボックステスト (Black-box Test)** | 入力と出力のみに注目するテスト    |
| **単体テスト (Unit Test)**            | 個々のモジュールや関数のテスト    |
| **結合テスト (Integration Test)**     | モジュール間のインタフェースのテスト |
| **システムテスト (System Test)**        | システム全体の動作確認        |
| **受け入れテスト (Acceptance Test)**    | 顧客やユーザーによる受入確認テスト  |

### その他の重要用語
| 用語                              | 説明                            |
| :------------------------------ | :---------------------------- |
| **バグ管理ツール (Bug Tracking Tool)** | 欠陥の登録・管理ツール（例: JIRA, Redmine） |
| **静的テスト (Static Test)**         | 実行せずにドキュメントやコードをレビューする        |
| **動的テスト (Dynamic Test)**        | 実行して動作を確認する                   |
| **回帰テスト (Regression Test)**     | 修正後に他の機能に影響がないか確認するテスト        |
| **テストカバレッジ (Test Coverage)**    | テストが対象システムのどの程度を網羅しているか       |


# [用語リンク先](https://glossary.istqb.org/ja_JP/search?term=&exact_matches_first=true)
生成モデルの基礎知識8 Mixture of Experts (MoE)

こんにちは。
最近、NVIDIA-Certified Associate: Generative AI and LLMs (NCA-GENL)を習得しました。
その際に知っておいた方が良い基礎知識とコードの書き方を共有したいと思います。
生成AIのチュートリアル:

https://github.com/Yuji-github/Gen_AI_Tutorial

Mixture of Experts（MoE）とは？ (アーキテクチャ)
一つの大きなタスクを、それぞれ特定のサブタスクに特化した複数の「専門家」（エキスパート）と呼ばれる小さなネットワークに分割し、どの専門家を使うべきかを決定する「ゲート」（ゲイティングネットワーク/ルーティングメカニズム）を組み合わせたモデル・アーキテクチャの事。

![MoE.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4108653/8be7439d-295e-4a64-8a83-ffcd22ea0753.png)

有名なモデルはMixtral-8x7B 
8x7Bの意味は70億個のニューロンモデルが８個という意味。
Mixtral-8x7BはLlama 2 70Bより性能が良く速い。

元のアイデアは１９９１年のAdaptive Mixture of Local Experts: https://www.cs.toronto.edu/~fritz/absps/jjnh91.pdf

２．トレーニングの仕方
- データ: モデルは、幅広いタスクやドメインを網羅する多様なデータセットで訓練され各エキスパートを異なる種類のデータに触れさせるのが重要。
- ルーティングメカニズム: MoEモデルには、入力データのどの部分をどの専門家が処理するかを決定するルーティングメカニズム（多くの場合、学習可能なゲート）がある。トレーニング中に、このゲートは、それぞれのエキスパートの持ち上がりつつある専門性に基づいて、異なる種類のデータを異なるエキスパートへとルーティングすることを学習する。
- エキスパートの特化: トレーニングが進むにつれて、各トレーニングは特定の種類のデータやタスクの処理に徐々に熟達していき、ルーティングメカニズムによって指示された、最も効果的に処理できる種類のデータを受け取り、そこから学習する。
- フィードバックループ: フィードバックループがあり、あるエキスパートが特定の種類のデータの処理に長けてくると、ルーター（ルーティングメカニズム）は同様のデータをそのエキスパートに送る可能性が高まる。これにより、各エキスパートの特化が強化される。
- 正則化と損失関数: トレーニングには、効率的な学習を促進し、一つのエキスパートが「何でも屋」になるシナリオを回避するための正則化手法や特殊な損失関数が含まれる。
- 容量制約: エキスパートに容量制約を課すことにより、モデルは単一の専門家がタスクで過負荷になることを防ぎ、すべての専門家間での学習のバランスの取れた分散をする。

３．MoE（Mixtral-8x7B）の働き方
- ルーティングの決定: 各トークンはルーターネットワークによって決定され、ルーターは、この特定のトークンを処理すべき8つの利用可能なエキスパート（フィードフォワードブロック）のうち、どの2つを選択すべきかを決定。この決定は、トークンの特性とエキスパートの専門機能に基づいて行われる。
- エキスパートによる処理: 選択されたエキスパートは、トークンを処理。各エキスパートは、特定の種類のデータやタスクに特化した独自のニューラルネットワーク層を適用。
- アウトプットの結合: 処理後、選択された2つのエキスパートからのアウトプットは結合され、アウトプットの平均化、結合、または各エキスパートが収集した情報を統合するための他の方法が適用されたりする。
- レイヤーを越えての継続: このプロセスは、モデルの各レイヤーで繰り返されます。すべてのレイヤーで、ルーターネットワークはトークンの現在の状態に基づいて異なる専門家のペアを選択。
- 最終アウトプットの生成: トークンがすべてのレイヤーを通過した後、最終アウトプットが生成される。
React学習記録：React-Selectを使ってセレクトボックスをいい感じに実装してみた

## はじめに

今回は、Reactを学ぶ中で「**どうやって使えばいいのか...？！**」と感じたReact-Selectについて記事として整理していきます。

**公式ドキュメント**

https://react-select.com/home

正直、フロントエンドについては苦手意識があり、まだまだ勉強が必要だと感じているので、簡単なコードを紹介しながら自分の理解を深めていきます。

内容については、自分改め初学者向けとなっていますので、温かい目で見守っていただければ幸いです...！！

## 書こうと思ったきっかけ

フロントエンド（主にReact）を勉強する中で、正直よくわからないことが多くて困っています...（***難しい！！！！***）。

:::note info
**自分自身AWSやインフラ周りはすごく好きですが、デザイン含めてフロントエンド周りは、積極的にアウトプット中心で自分自身の理解を深めていく必要があるとつくづく感じています（つまり、苦手...）。**
:::

それに加えて、公式ドキュメントを読む力を鍛えないといけないと以前から思っていたので、まずは簡単な「React-Select」について手を動かしながらまとめていきます。

## React-Selectとは？

React-Selectは、Reactで使えるセレクト（選択）入力UIを簡単に作れるライブラリです。以下のような機能を持っています：

* 複数選択（multi-select）
* オートコンプリート（入力補完）
* 非同期検索（API連携）
* 新しい項目の作成（creatable）
* カスタムスタイルの適用

**参考文献**

https://dev.classmethod.jp/articles/react-select/

https://qiita.com/Hitomi_Nagano/items/c00df24dc24e0329167d

https://rz-log.com/posts/react-select-basic-usage

## 実際のコード

### 手順（Create React Appを使う）

#### ① 新しいReactアプリを作成

```bash
npx create-react-app my-react-select-app
cd my-react-select-app
```

`my-react-select-app` はプロジェクト名。好きな名前に変えてOKです！

こんな感じで問題なくプロジェクトが作成されました！

![Screenshot 2025-06-23 at 21.20.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/4549cb4f-f231-4600-9dd7-595b091d9ffe.png)


#### ② React-Select をインストール

```bash
npm install react-select
```

**こちらも問題なく導入することができました！**

![Screenshot 2025-06-23 at 21.22.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/03172db4-4c27-4e20-b6ce-ada6eb6e0a4d.png)

#### ③ App.js（または App.tsx）を書き換える

以下のように編集します：

```jsx
// src/App.js

import React from 'react';
import Select from 'react-select';

const options = [
  { value: 'apple', label: '頑張れ！🔥' },
  { value: 'banana', label: 'もっと頑張れ！🥶' },
  { value: 'orange', label: 'ほどほどにね〜😆' },
];

function App() {
  return (
    <div style={{ width: '300px', margin: '50px auto' }}>
      <h2>月曜日疲れましたね...</h2>
      <Select options={options} />
    </div>
  );
}

export default App;
```

#### ④ アプリを起動する

```bash
npm start
```

自動でブラウザが開き、[http://localhost:3000](http://localhost:3000) に表示されます。セレクトボックスが動作するか確認できます。

**いい感じに表示されました！（月曜日疲れましたね...^^;）**

![Screenshot 2025-06-23 at 21.32.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/3e9ca083-429c-4309-bb18-3c09d110befe.png)

## まとめ

ここまで読んでいただき、ありがとうございました！

:::note warn
**React-Selectは、Reactの中でもとても便利なUIコンポーネントの1つです。特にセレクトボックスを簡単に導入したいときにとても役立つと感じました！**
:::

最初は「なんだこれ？」と思った自分でも、実際に動かしてみることで理解が深まりました。今後は、非同期検索や新しい項目の作成など、より応用的な使い方にも挑戦していきたいと思います！（Reactと仲良くなりたい...）