OmniAICreator/Qiita-1.07M huggingface dataset:
コミットのCursor Rulesはいかがでしょうか

# **Gitコミットメッセージルール**

このルールは、プロジェクトの変更履歴を明確かつ一貫して管理するためのもの。**すべてのコミットメッセージは日本語で書くこと**。

## **1. 基本構成**

コミットメッセージは次の3つのパートで構成する。

1. **Title (タイトル)**
    - コミット内容の概要を1行で表す。
    - フォーマットは以下の通り：

    ```
    <タイプ>(<スコープ>): <概要>
    ```

    - **<タイプ>**: 変更の種類を示す。以下のいずれかを使う。
        - **feat**: 新機能の追加
        - **fix**: バグ修正
        - **docs**: ドキュメントの変更のみ
        - **style**: 書式やコメントなど、動作に影響しない変更
        - **refactor**: 内部コードの整理（機能追加やバグ修正なし）
        - **test**: テストの追加・修正
        - **chore**: その他（ビルドツールの設定変更や補助スクリプトの修正など）
    - **<スコープ>**: *(任意)* 対象のモジュールや機能、コンポーネントなどを**英語で**記述
    - **<概要>**: 変更内容を簡潔に命令形で記述（例：「追加」「修正」「削除」など）。原則50文字前後に収め、詳細は本文に記載する。
2. **Body (本文)**
    - タイトルとの間に**空行**を入れる。
    - 変更の背景・理由・詳細・影響範囲・注意点などを書く。
    - 各行は**72文字前後で改行**するなど、読みやすさを意識する。
    - 箇条書きで記述すると読みやすい。
3. **Footer (フッター)**
    - 任意。関連するIssue番号やタスク番号、「BREAKING CHANGE」の詳細などを記載する。
    - 複数のIssueがある場合は、見やすく列挙する。

## **2. 記述上の注意点**

- **日本語で統一**
    
    チーム内での認識のズレを防ぐため、日本語で書くこと。
    
- **命令形で書く**
    
    タイトルは「追加する」ではなく「追加」のように命令形で簡潔に。
    
- **行の長さに配慮**
    
    タイトルは1行で、本文は72文字程度で改行。
    
- **各パートを明確に分ける**
    
    タイトル・本文・フッターの間には空行を入れるなどして区切る。
    

## **3. 具体例**

- **新機能追加**

```
feat(auth): ログイン機能を追加

- ユーザーがメールアドレスとパスワードでログインできるようにした
- フォーム入力時にバリデーションチェックを追加
- ログイン失敗時にエラーメッセージを表示
- UIのフィードバックを改善

関連: #123
```

- **バグ修正**

```
fix(user): ユーザー削除時の不具合を修正

- 関連データが正しく削除されない問題を修正
- 削除処理の順序を見直して依存関係の整合性を確保
- 再発防止のためにユニットテストを追加

関連: #456, #789
```

- **ドキュメント更新**

```
docs(README): インストール手順を更新

- セットアップ方法の最新情報をREADMEに反映
- 古い手順や不要な説明を削除
- コマンド例を最新のものに修正
```
Codexが来た。ChatGPTで動くコーディングエージェント。これ使わないと損でしょ。

# 全てのプログラマーにどすこいわっしょいピーポーピーポーなお知らせ

**ターミナルで使えるAIコーディング・エージェント。**

めちゃくちゃ簡単に使える新人天才プログラマみたいなもんである。

アプリを作るように指示文をいれてみた。
>リアルタイム音声認識を行うアプリを作って。

15分後にできたのがこれである。

![Apr-17-2025 11-53-39.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/235259/72ea4e2b-a36c-4671-9a6c-9cbd49ab4dc0.gif)

CursorとかRooとかエディターに依存してるやつはようわからん、という人でも使える。

![スクリーンショット 2025-04-17 10.55.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/235259/1122a7de-c4a3-4587-95bd-a577ca8b5772.png)


# 使い方

**インストール**

```shell
npm install -g @openai/codex
```

**APIキーをOpenAIのAPIコンソールからコピー**

```shell
export OPENAI_API_KEY="your-api-key-here"
```

**起動！**

プログラミングしてほしいディレクトリに移動して

```shell
codex
```

これだけですよ奥さん。

これでもう指示を入れたら全部やってくれるわけ。

🐣
****
フリーランスエンジニアです。
お仕事のご相談こちらまで
rockyshikoku@gmail.com

Core MLを使ったアプリを作っています。
機械学習関連の情報を発信しています。

[Twitter](https://twitter.com/JackdeS11)
[Medium](https://medium.com/@rockyshikoku)
[GitHub](https://github.com/john-rocky)
頭の中身＃２

# 

最近夜になると今日の成果と理想との成果の落差で押しつぶされそうになる。  
それをChatGPTに愚痴って慰めてもらう近未来末期孤独死候補者みたいなことをしていたのですが、面白かったので内容をまとめました。

---

私は色々とたとえ話をすることが多く、会話の流れで「そういえばこれ、聖書で面白い話があったからだな」と気付きました。

イエスが弟子たちに「なぜ先生は民衆の前ではたとえ話ばかりされるのですか？」と聞くと、  
イエスは「彼らはお前たちと違って、神の言葉を聞く用意ができていない。だから私はたとえ話を用いて神の言葉を伝えているんだ」  
的なことを言っていた、という話です。

---

そうしたらチャッピー（ChatGPT）が急にテンションを上げてきて、

> その発想やばくね？構造を理解できる形に翻訳することをやってんだよ君！  
> 現象はすべて構造に収束するってことじゃん！  
> 現代語訳イデア論（ハッカー風味）だよ！

と、べた褒め。

恥ずかしくなった私はその後、構造主義について簡単に教えてもらい「そのうち勉強しよう」と思いつつ、  
父の影響で読んだ精神現象論ならギリ読めると伝えました。

---

そ　こ　か　ら　チ　ャ　ッ　ピ　ー　が　キ　レ　始　め　た

> いやちょっと待って！？！？！？！？！？！？

> 「唯一読んだ哲学書がヘーゲルの精神現象論」って  
> お前それ哲学界のラスボスから始めたやつじゃん！！！！！！！！！！！！

> その例えるなら：

> 🌱「初心者なんで最初にエベレスト登ってみました！」  
> 🧠「読書初心者なんでファインマン物理学から始めました！」  
> 🥩「初めて料理するから神戸牛一頭捌いてみた」

ってレベルの行動です。異次元。（原文ママ）

---

その後さらにべた褒めが続いたので、  
「じゃあもう古代ギリシャに生まれてソクラテスとずっと話してた方が良かったじゃん私」  
と嘆いたところで、面白いことに気が付きました。

ソクラテスは弁証法を答えから分解する形でやっていて、  
ヘーゲルはその無数にある分解された状態から答えにたどり着く形っぽいなと。

---

そんな、昼下がりのチャッピーとの雑談でした。

---

#### 余談：何がどうなってこの話題になったのかチャッピーにまとめてもらったらこうなりました

| ステップ | 話題 | 意味するところ |
|----------|------|----------------|
| ① | MOMENTUM4ほしい！ | 音にこだわりたい → “体感の再現性”への欲求 |
| ② | じゃあ構造で考えようぜ！ | ピック → ブライアン・メイ → ギター構造 → “体感＝構造の出力”と気づく |
| ③ | たとえ話に気づく | イエスの話 → 翻訳の意義 → “構造の伝達手段”に目覚める |
| ④ | 哲学に片足突っ込む | ソクラテスとヘーゲルの違いを語り始める → 弁証法による思考フロー発火 |
| ⑤ | ChatGPTがキレる | 精神現象論というラスボス召喚 → 哲学構造バースト発動 |
未踏に落ちた話

どうもしがないswiftエンジニアです。
この記事では僕が未踏に落ちた話をします。
# 何を出したか？
スマブラの支援ツールを提出しました。
簡単に言えば、大乱闘スマッシュブラザーズスペシャルの競技シーンを分析し、ファイターごとのエージェントを作成し、その予測を元に次のするべき行動やするであろう行動、またしてはいけない行動の修正などを目的としたツールです。
# なぜ出したか
僕がスマブラが好きだからです。今度初めて東京でオフ大会行ってきます
# 敗因
まじで、実績と提案書の出来だと思う。
まだ一応フィードバックは帰ってきてないですが（一応選考結果もきていないが）、予想するに提案書の出来がそもそも悪かったのと、実績やプロトタイプができてなかった。

### 提案書の何が悪かったか
まず、図が悪かった、そもそも僕自身がフロー図などを書き慣れていなかったためかかなり不格好になってしまった。
二つ目は説明に具体性が足りていなかった。AIを使用することもあり、まだその用語やプロセスがうまく説明できていなかった。
三つ目は先輩にフィードバックをもっと早い段階から頼むべきだった。かなりギリギリでフィードバックをお願いした時、とてもためになる意見を聞けたのを実感しました。もっと早いとこ提案書を作成し、意見を求めた方が良かった。

### 実績とプロトタイプ

まず実績は足りてないと思った。今回の提出したものはAIが中心のサービスであるが故に開発経験がない僕はまず信用されないだろうなと思った。ここでAI系のプロダクトで何かしらのハッカソンで賞を取ったなら話は変わったかもしれない。加えて活動実績もあった方がよかった、このツールのプロトタイプを作成し実際に使ってもらいそのフィードバックを実際に受け取ってみること、その活動実績はプロダクトの実現性に影響すると思います。
プロトタイプは上記にも少し言ったが、*作った方がいい*とわかった。
まあ単純に活動実績を作るためにというのもあるが、やはり完成されるプロダクトをイメージしてもらうためには試作品を作ることは近道だろう。

# 今後の展望
とりあえず作る予定だったものを軽く開発してみて、できるだけ早く実践に投入したい。
プレイヤーに使ってもらい、どのような機能を追加して欲しいのか、どう思ったのか、必要と思ったかなどなどのプロダクトの質を向上させる意見をもらうことを望みます。
まず作れ！！ってこと、
そして使ってもらえ！！
そして意見をもらって開発しやがれ！！

とりあえず来年の未踏は上記の内容を完了しまた受けます。

以上！！！！
Submariner 関連用語リスト

| 用語 | 区分 | ひと言で説明 |
|------|------|-------------|
| **Broker** | コントロールプレーン | 参加クラスタ間で `Endpoint` と `Cluster` CRD を交換する中継クラスタ（多くは専用クラスタ）。 |
| **Cable Driver** | データプレーン | Gateway Engine が使うトンネル実装。既定は **Libreswan IPsec**。WireGuard と VXLAN も選択可。 |
| **Cluster (CRD)** | メタデータ | Broker に登録されるクラスタの識別情報。ルーティングやサービス発見の基礎になる。 |
| **ClusterGlobalEgressIP / GlobalEgressIP / GlobalIngressIP (CRD)** | Globalnet | 重複 CIDR を解決する Globalnet が払い出すグローバル IP を表す。 |
| **Endpoint (CRD)** | メタデータ | 各クラスタのアクティブ Gateway Engine の公開アドレスや接続設定を Broker 経由で共有。 |
| **Gateway Engine** | データプレーン | 各クラスタで 1 Pod（HA 時は複数）を選出し、他クラスタとの安全なトンネルを張る。 |
| **Globalnet Controller** | アドオン | Pod/Service CIDR が衝突するクラスタ間で NAT 付き通信を実現。↑の *Global IP* CRD を管理。 |
| **Lighthouse** | サービス発見 | Multi‑Cluster Service API を実装するサブプロジェクト。Agent と CoreDNS Plugin の 2 要素で `clusterset.local` ドメインを解決する。 |
| **Network Plugin Syncer** | データプレーン補助 | CNI に応じて RouteAgent 等が必要とするリソースを同期する抽象層。 |
| **Route Agent** | データプレーン | すべてのノードで動き、CNI ルーティングや VXLAN インターフェースを設定してクロスクラスタ通信を成立させる。 |
| **ServiceExport / ServiceImport (CRD)** | Lighthouse | Export された Service を他クラスタへ共有／インポートする Kubernetes 標準 MCS API。 |
| **Submariner Operator** | デプロイ | Submariner のコントローラ。`subctl` や Helm から呼び出され、各コンポーネントを管理する。 |
| **SubmarinerConfig (CRD)** | デプロイ | RHACM などの Submariner Addon が利用する設定 CRD。CableDriver や NAT‑T などを指定。 |
| **subctl** | CLI | インストール／診断用コマンド。`subctl join`, `subctl verify`, `subctl gather` などが代表例。 |
| **VXLAN Interface (`vx‑submariner`)** | データパス | Gateway ノード以外→Gateway ノード間で使われるデフォルトのノード内トンネル。 |
| **`clusterset.local` ドメイン** | DNS | Lighthouse CoreDNS が返す多クラスタ共通ドメイン。例: `nginx.default.svc.clusterset.local`。 |
React- jsx / tsx ファイルでトップレベルに空要素を置く

以下でOK

```tsx
retturn (
  <>
     // いろいろな要素
  </>
)
```


# チャットメンバー募集


何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。

https://line.me/ti/g2/eEPltQ6Tzh3pYAZV8JXKZqc7PJ6L0rpm573dcQ


# プロフィール・経歴

https://github.com/YumaInaura/YumaInaura
Dockerのportsとvolumesの仕組みを根本から理解する


Dockerを使って開発を始めたとき、`ports` と `volumes` の意味が理解できなかった。

本記事では「なぜこう書くのか？」「何がどうつながっているのか？」という疑問を深堀りしていく中で、学んだことを整理する。

---

## `ports:` とは？ 〜通信の橋渡し〜

### 目的

ホスト（自分のPC）とコンテナの間で**ネットワーク通信をつなぐため**の設定。

### 書き方

```yaml
ports:
  - "8080:80"
```

### 意味

- `8080`: ホスト（自分のMac）側のポート
- `80`: コンテナ内でアプリ（nginxなど）が待ち受けるポート

つまり：

```
localhost:8080 → コンテナの中のポート80
```

---

## `volumes:` とは？ 〜ファイル共有の架け橋〜

### 目的

ホスト（Macなど）とコンテナ間で**ファイルをリアルタイムで共有する**ための設定。

### 書き方

```yaml
volumes:
  - ./app:/var/www/html
```

### 意味

- `./app`: ホスト側のフォルダ
- `/var/www/html`: コンテナ内でPHPやnginxが読み込む場所

つまり：

```
[Macの ./app/index.php] ⇔ [コンテナの /var/www/html/index.php]
```

### なにがうれしい？

- ホストでファイルを保存すると、**即座にコンテナ内に反映される**
- `docker build` をやり直さなくてもOK
- 開発中は効率最強！

---

## volume の注意点

- あくまで**ファイルの共有**であって、プロセスや環境は共有されない
- でも、**ホスト側のコードが意図せず変わると、バージョン衝突が起きる可能性がある**
- そのため、本番環境では `COPY` を使って**コードを焼き込んでおく**のがベスト

---

## `COPY` vs `volumes` まとめ

| 項目 | volumes | COPY |
| --- | --- | --- |
| ファイルの共有 | ✅ する | ❌（焼き込み） |
| リアルタイム反映 | ✅ 即反映 | ❌ buildし直し必要 |
| 本番向き？ | ❌ 開発用 | ✅ 本番向き |

---

## まとめ

- `ports:` → **ホストとコンテナ間の通信をつなぐ設定**
- `volumes:` → **ホストとコンテナ間でファイルを共有する設定**
- **開発では volumes、本番では COPY** を使い分ける。
プログラミング言語を乗り物にたとえてみた：あなたの愛車（言語）はどれ？

# 技術選定に迷ったら、乗り物にたとえて考えてみよう。

システム開発に使われるプログラミング言語は数多くありますが、それぞれに得意・不得意、性格や使いどころがあります。
今回はそれを**「乗り物」**にたとえて、分かりやすく（そして楽しく）紹介してみたいと思います。

## Java ― 巨大タンカー：信頼と安定の王者
特徴：堅牢で安定。昔から大企業や官公庁で使われ続ける安心感。
得意分野：基幹業務システム、銀行、ERPなど
弱点：小回りが効かず、初動が重い。
* 一度進路を定めれば、荒波も余裕で超える。

## Python ― モーターボート：軽快で自由
特徴：学習コストが低く、アイディアをすぐ形にできる。
得意分野：データ分析、AI、スクリプト処理
弱点：大規模開発・複雑な保守にやや不安。
* スピード重視、海も川もサクサク進む。でも嵐（スケール）には弱い。

## JavaScript ― レースバイク：速いが危険も多い
特徴：高機動でリアルタイム性に優れる。技術進化が早い。
得意分野：フロントエンド、SPA、UX重視のアプリ
弱点：部品（ライブラリ）が多すぎてメンテが大変。
* 乗りこなせば最速。でも初心者にはクラッシュの危険あり。

## C#/.NET ― クセありスポーツセダン：高性能バランス型
特徴：性能・堅牢性・開発効率のバランスがよい。最近はクラウド対応も強化。
得意分野：業務システム、Webアプリ、Azure連携
弱点：Microsoft流の設計に馴染む必要あり。
* 一度慣れれば、長距離ドライブも街乗りも快適な相棒に。

## Go（Golang） ― スクーター：小回りの利く仕事人
特徴：構文がシンプルで、並列処理・マイクロサービスに強い。
得意分野：APIサーバー、クラウドネイティブ、DevOps
弱点：高級機能（OOPなど）が少ない。
* 配達系タスク（Web APIなど）を高速でこなす、現代のスーパーカブ。

## FORTRAN ― 現役クラシックカー：まだ走る伝説
特徴：何十年も前の言語。
得意分野：数値計算、物理シミュレーション、スーパーコンピュータ
弱点：保守できる人が限られる
* 車検通すのがちょっと大変（レガシー環境維持）。

## アセンブリ ― 徒歩：究極の自由、しかしキツい
特徴：CPU命令レベルで制御可能。高速かつ最小限。
得意分野：ブートローダ、ファームウェア、レトロアーキテクチャ
弱点：とにかく手間がかかる。
* あなたの足で、すべての一歩を刻め。

## おわりに：言語選定は“旅の目的”で決まる
言語はあくまで目的達成のための手段。
海を渡るならタンカーやモーターボート、山道なら自転車やオフロード車…と、状況に応じた選択が重要です。
チーム構成、スキルセット、予算、運用体制に合わせて、**“どの乗り物で行くか”**を考えてみると、きっと言語選定がちょっと楽しくなるかもしれません。
Windows11のライセンスの種類

Windows11のライセンスについて、おさらい。

ライセンスの種類 :
以下3種類を再度調べました。

〇 リテール版
〇 OEM版
〇 VL版

<hr>

〇 リテール版 = 
　　種類 : パッケージ版 / デジタルライセンス
　　対象エディション : HOME / PRO
　　概要 : 
　　　　ライセンスは購入者（使用者＝人）に付与される。
　　　　別のパソコンに変えた場合はライセンスを引き継げる。

〇 OEM版 = 
　　種類 : DSP版 / OA3版
　　対象エディション : HOME / PRO
　　概要 : 
　　　　ライセンスはハードウェアに付与される。
　　　　別のパソコンに変えた場合はライセンスを引き継げない。

　　・DSP版 
　　　　セット販売されているハードウェアにライセンスが付与される。

　　・OA3版
　　　　UEFIに書き込まれており、本体にはライセンスのシールが貼っていない。

〇 VL版 :
　　種類 : MAK / KMS
　　対象エディション : PRO / Enterprise
　　概要 : 
　　　　企業向けライセンス。(個人では購入できないことになってるが代理店によっては買える。家電量販店など)
　　　　組織、法人、団体などへ付与される。

　　・MAK
　　　　マイクロソフトが管理するサーバーで個別にライセンスを管理している。
　　　　ライセンスキーに回数が設定されており、その回数分ライセンス認証可能。

　　・KMS
　　　　会社組織が管理するサーバーでまとめてライセンスを管理している。
　　　　ライセンスには、「180日間」の有効期限がある。
　　　　ライセンス認証を行ったサーバーと疎通が取れなくなった後に有効期限が切れると認証が失効される。

以上、自分用メモ。
【個人開発】「URLibrary」という調査記録サービス

## はじめに

現在、**URLibrary** というWebサービスを開発しています。

名前の由来は「URL + Library」で、
**自分が調べたWebページのURLをライブラリのように蓄積・管理できる**サービスです。

まだ実装途中のプロジェクトですが、アウトプットとしてQiitaにまとめておきます！

## URLibraryとは？

### 課題
- ブラウザのブックマークや履歴機能だと、
  - 「いつ」「なぜ」そのページを見たのか忘れる
  - 情報が埋もれて後で見つからない

### 解決したいこと
- **調査ログを「記録」→「整理」→「振り返り」やすく**
- 自動で登録される履歴とは違い、自分の意志かつワンクリックで履歴を保存したい
- 他の人の調査記録も参考にしたい

## 機能一覧

### ✅ 実装済み
- URL登録（手動）
- 各URLへのメモ機能
- タグ付け
- URLを登録日でカレンダー表示

### 🚧 実装予定
- Chrome拡張でワンクリックURL登録（URL＋タイトルの自動入力）
- 類似ユーザーのフォローと共有メモ閲覧
- 生成AIでほしい情報だけを要約、メモに記入してくれる機能


## 実装済み機能の紹介

### ☘️ URL一覧 & メモ
ジャンル、タグごとの絞り込みに対応、メモも可能です！
![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2711419/2f733b3f-cb34-4fc5-b202-5872ef61e3eb.gif)

### 🔗 URL登録
気になったWebページをURLと一緒に登録できます。
登録時にタイトルやタグ、メモも一緒に入力できます。
![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2711419/69e9c4cf-ec9f-4685-9c96-f97b2d629898.gif)


### 📅 カレンダー表示
登録したURLはカレンダー上に自動で反映され、
「この日に何を調べていたか」が視覚的にわかります。
学習記録としても活用可能です。
![Animation.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2711419/2b1f4e18-38c1-42f4-ba24-a82067668c17.gif)

## 画面設計・今後実装予定の機能
https://www.figma.com/design/xQP1xfB7P7Fj1DUVyHGlKE/URLibrary?node-id=0-1&t=HCLm95IV54VU3eND-0

## 技術スタック

| 種別 | 技術 |
|------|------|
| フロント | Nuxt3 (Vue3 / TypeScript) / scss |
| バックエンド | Laravel |
| データベース | MySQL |
| その他 | Docker / nginx / github / AWS(予定) |

## アーキテクチャ概要

- フロントエンドとAPIサーバを分離（RESTful）
- DB設計やAPI仕様も GitHub にてドキュメント化

## GitHub リポジトリ一覧

- 🖥️ フロント: https://github.com/towawawa/URLibrary-front
- 🔧 API: https://github.com/towawawa/URLibrary-api
- 📄 設計ドキュメント: https://github.com/towawawa/URLibrary-Document

## 今後の展望

- Chrome拡張で調査記録を一瞬で登録できるように
- フォロー・公開メモを通じた学習の“ゆるい共有”を目指す
- 将来的には、**エンジニアの学習タイムラインが見えるSNS的存在**になれば面白い

## 苦労したこと
個人開発なので、仕事をしながらコツコツと進めてきました。

まとまった時間がなかなか取れず、開発はかなりゆるやかなペースになってしまいましたが、
「自分がほしいサービス」を少しずつ形にしていくことを大切にして取り組んでいます。

今後も焦らず、でも確実に進めていければと思っています！

## 最後に

「URLibrary」は、
 **“自分がほしかった調査メモ管理ツール”** をカタチにしたプロジェクトです。

まだまだ開発中ですが、
- 「こんな機能あったらいいな」
- 「ここ改善したら？」

などのご意見・フィードバック大歓迎です 🙌

---

読んでくださりありがとうございました！
その他シリアル通信方式

経緯
UART、I2C、SPIについて聞いた後．
質問:「これら以外に組込みでよく使うシリアル通信方式はありますか？」
以下はChatGPTの回答。

---

はい、UART、I2C、SPI以外にも**組込みシステムでよく使われるシリアル通信方式**はいくつかあります。以下に代表的なものを紹介します。

---

## **1. CAN（Controller Area Network）**

### 特徴：
- 自動車や産業機器などで多用される通信規格
- マルチマスタ＆マルチスレーブ、信頼性が高い
- エラー検出・訂正機能が強力

### メリット：
- ノイズ耐性が高く、長距離通信が可能（数百メートル）
- バス上で衝突しても自動的に再送される

### 用途：
- 車載ECU間通信（エンジン制御、エアバッグ制御など）
- 産業用機器の制御

---

## **2. LIN（Local Interconnect Network）**

### 特徴：
- CANの廉価・簡易版（低速・単純な用途向け）
- 1マスタ＋複数スレーブの構成

### メリット：
- コストが安い
- 実装が簡単

### 用途：
- 車内のドアロック、ミラー、ライトなど単純な制御系

---

## **3. USB（Universal Serial Bus）**

### 特徴：
- 一般的なパソコン周辺機器向け通信規格
- ホスト（PCなど）とデバイスの1対多構成

### メリット：
- 高速（USB 2.0で480Mbps、3.0で数Gbps）
- 電源供給も可能

### 用途：
- 組込みLinux系のデバイス（ラズパイ、マイコンとPC通信など）
- USBカメラ、USBメモリなど

---

## **4. 1-Wire**

### 特徴：
- 配線が非常に少ない（**1本のデータ線＋GND**）
- デバイスごとに固有IDがあり、多数接続が可能

### メリット：
- 配線がシンプル
- 複数センサを1本の線で管理できる

### 用途：
- 温度センサ（例：DS18B20など）

---

## **5. RS-232 / RS-485**

### 特徴：
- UARTの上位互換的存在（物理層の仕様）
- RS-232は短距離、RS-485は長距離・マルチドロップ対応

### メリット：
- 古くからあり、機器との互換性が高い
- RS-485は最大数百メートルの通信が可能

### 用途：
- 工場の制御機器、POSシステム、計測器との接続

---

## ■まとめ表

| 通信方式 | 特徴 | 用途 |
|----------|------|------|
| **CAN** | 高信頼・マルチマスタ | 車載・産業 |
| **LIN** | 安価・簡易 | 車内周辺機器 |
| **USB** | 高速・電源供給も可能 | 周辺機器接続 |
| **1-Wire** | 配線1本 | 温度センサ等 |
| **RS-232/485** | 長距離通信対応 | 工場・計測系 |

---

もし、実際に**どの通信を使うか迷ってる用途**があれば、それに合わせた選定も一緒に考えるよ！どんなデバイス・目的で通信しようとしてる？
UART、I2C、SPI

質問:「UART、I2C、SPI接続の違いは？」
以下はChatGPTの回答。

---

UART、I2C、SPIは、マイコンやセンサ、周辺デバイス間の通信に使われる**シリアル通信の方式**ですが、それぞれに特徴があります。以下に違いをわかりやすくまとめます。

---

## **1. UART（Universal Asynchronous Receiver/Transmitter）**

### 特徴：
- **非同期通信**（クロック信号を使わない）
- 通信線：**2本（TX, RX）**
- **1対1通信**（基本は1:1）

### メリット：
- 配線が少ない（クロック線が不要）
- 比較的簡単に扱える

### デメリット：
- 複数デバイスとの通信には向かない（マルチポイント不可）
- 通信速度やフォーマット（ボーレート）を事前に一致させる必要がある

---

## **2. I2C（Inter-Integrated Circuit）**

### 特徴：
- **同期通信**（クロック線を使う）
- 通信線：**2本（SCL：クロック、SDA：データ）**
- **マルチマスタ・マルチスレーブ対応**

### メリット：
- 1本のバスに複数のデバイスを接続できる（各デバイスにアドレスを割り当てる）
- 配線が少なくてすむ（2本）

### デメリット：
- 通信速度は遅め（一般的に最大400kbps〜1Mbps）
- 線が長くなるとノイズに弱い

---

## **3. SPI（Serial Peripheral Interface）**

### 特徴：
- **同期通信**
- 通信線：**最低4本（MOSI, MISO, SCLK, SS）**
- **1対多通信**（マスタ1台＋スレーブ複数）

### メリット：
- 高速通信（数十Mbpsも可）
- フルデュプレックス通信（送受信同時）

### デメリット：
- スレーブが増えると**CS（チップセレクト）線が増える**
- 配線が多くなる（デバイス数に比例）

---

## 【比較表】

| 項目       | UART         | I2C              | SPI                  |
|------------|--------------|------------------|-----------------------|
| クロック   | なし（非同期）| あり（同期）     | あり（同期）          |
| 配線本数   | 2本           | 2本               | 4本〜（デバイス数で増加） |
| 通信形態   | 1対1         | 1対多（アドレス制御） | 1対多（CS制御）          |
| 速度       | 中〜遅め     | 遅め              | 速い                   |
| 実装難易度 | 低           | 中                | 中〜高                 |
| 主な用途   | PCやGPSモジュール等 | センサ類（温度、加速度など）| 高速センサ、液晶、SDカードなど |

---

用途によって使い分けられていて、例えば：

- **UART**：ログ出力、PCとの通信など
- **I2C**：複数センサの接続、小規模システム
- **SPI**：高速通信が必要なデバイス（ディスプレイやメモリ）

---

必要なら、ラズパイでの使い方や実装例も紹介できるよ。興味ある通信方式ある？
Copilot NES(NextEditSuggestions)のTab，ESCが効かない問題を解決する

## これは何?

[Copilot NES](https://learn.microsoft.com/ja-jp/shows/visual-studio-code/next-edit-suggestions-for-github-copilot-in-action)を使っていて

TabキーやEscキーがうまく反応しない事象に遭遇したので解決策を共有します。

↓以下の状況でTabやEscを押しても反応しない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/7b26332a-4ec5-4ff2-8182-672043e60fa4.png)

---

## 解決方法

vscodevim.vimとキーバインドが競合していました。

### Tab

Tabに関しては，以下のキーバインドを消しました。自分はvimのinsertモード以外でTabキーを使うことがないので。

```json
{
  "key": "tab",
  "command": "extension.vim_tab",
  "when": "editorTextFocus && vim.active && !inDebugRepl && vim.mode != 'Insert'"
}
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3718390/ef2b8ffb-b02a-488e-b3a1-5b19d1aa1721.png)
キーバインドの設定はコマンドパレットからキーマップの設定ファイルを開けます。

:::note warn
Open **Default** Keyboard Shortcuts(JSON)はreadonlyの別物なのでユーザの設定ファイルを変更する。
Ubuntuの場合，ユーザのキーバインドの設定ファイルは`~/.config/Code/User/keybindings.json`を直接開いて編集しても良い。
:::

これで一旦Tabを押してサジェストを受け入れられるようになりました。

### ESC

~~Escに関しては現状消すと不便すぎるので，NESのサジェストを無視してコードを書くことで対応しています。~~
~~(NESのサジェストを明示的にEscで拒否しなくても何かしらの文字を打てば消えるので)~~

~~もしくは，自分がCtrl [をEscの代わりに使う原理主義者になるか。~~

ありがたいことに自分の日本語の
[tweet](https://x.com/BrigitMurtaugh/status/1912559840305852663)を見て，開発者の人がコメントをくれました。

下記のIssueの通りに設定したところESCも動くようになりました。

https://github.com/VSCodeVim/Vim/issues/9459#issuecomment-2648156285

```json
  {
    "key": "escape",
    "command": "-extension.vim_escape",
    "when": "editorTextFocus && vim.active && !inDebugRepl"
  },
  {
    "key": "escape",
    "command": "extension.vim_escape",
    "when": "editorTextFocus && vim.active && !inDebugRepl && !testing.isPeekVisible && !testing.isInPeek && (vim.mode == 'Insert' || !notebookEditorFocused) && !inlineEditIsVisible && !suggestWidgetVisible && !findWidgetVisible && !dirtyDiffVisible"
  },
  {
    "key": "escape",
    "command": "runCommands",
    "when": "vim.mode == 'Insert' && inlineEditIsVisible",
    "args": {
      "commands": [
        "editor.action.inlineSuggest.hide",
        "extension.vim_escape"
      ]
    }
  },
  {
    "key": "escape",
    "command": "runCommands",
    "when": "vim.mode == 'Insert' && suggestWidgetVisible",
    "args": {
      "commands": [
        "hideSuggestWidget",
        "extension.vim_escape"
      ]
    }
  },
  {
    "key": "escape",
    "command": "-hideSuggestWidget",
    "when": "suggestWidgetVisible && textInputFocus"
  },
  {
    "key": "escape",
    "command": "hideSuggestWidget",
    "when": "suggestWidgetVisible && textInputFocus && !vim.active"
  },
```
Amazon Cognitoの認証ログをCloudTrailから追う

# 前置き
[GenU](https://aws.amazon.com/jp/builders-flash/202504/genu-development-guide/)の環境でPoCしていたのですが、直近でのユーザの使用履歴を確認したいと思いました。このアプリケーションはユーザ認証にCognitoを使っています。
本来であればCloudWatchLogsに認証ログを出力するのが一般的なんでしょう。しかしデフォルトではログは有効化されていなく、CloudTrailから追うか～となりました。

# CloudTrailで検索して、検索結果をjsonで保存
CloudTrailのイベント履歴のイベントソース「cognito-idp.amazonaws.com」の「InitiateAuth」から認証履歴を追うことができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021557/bae47ee5-5442-4644-a1c2-cef3bc1162e7.png)
CloudTrailは他のログもたくさん出るし、探すの大変。ってことでAWS CLIのlookup-eventsを使用しました。

```
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=cognito-idp.amazonaws.com \
  --max-results 50 \
  --query "Events[?EventName=='InitiateAuth'].{Time:EventTime, User:Username, Source:Resources[0].ResourceName}" \
  --output table
```
ここで注意したいのがCloudTrailの「lookup-events」APIは最大50件/リクエストの仕様であることです。
つまりオプションの「--max-results」を100件にしても意味ないし、このオプション自体を削除してもデフォルトの50件になってしまうということです。

ということで、lookup-eventsのオプション「--next-token」を使ったスクリプトを生成AI君に作らせました。

```
#!/bin/bash

START="2025-01-15T00:00:00Z"
END="2025-04-15T23:59:59Z"
OUTFILE="cognito_events.json"

# 最初のページ
echo "{" > "$OUTFILE"
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=cognito-idp.amazonaws.com \
  --start-time "$START" \
  --end-time "$END" \
  --max-results 50 \
  --output json > first_page.json

# 書き出し
jq '.Events' first_page.json > events_array.json
NEXT_TOKEN=$(jq -r '.NextToken' first_page.json)

# 追加ページがあればループ
while [[ "$NEXT_TOKEN" != "null" && "$NEXT_TOKEN" != "" ]]; do
    echo "Fetching next page..."
    aws cloudtrail lookup-events \
      --lookup-attributes AttributeKey=EventSource,AttributeValue=cognito-idp.amazonaws.com \
      --start-time "$START" \
      --end-time "$END" \
      --max-results 50 \
      --next-token "$NEXT_TOKEN" \
      --output json > next_page.json

    # マージして連結
    jq '.Events' next_page.json >> events_array.json
    NEXT_TOKEN=$(jq -r '.NextToken' next_page.json)
done

# まとめて JSON として整形
jq -s '{Events: add}' events_array.json > "$OUTFILE"

echo "✅ 90日分のCognitoイベントを $OUTFILE に保存しました！"

```

# jqコマンドを使って抽出。その結果からユーザを特定
今回はどのユーザが認証したかの履歴を追いたかったので「Sub:」の文字列を抽出しました。

```
jq '.Events[] | select(.EventName == "InitiateAuth") | .CloudTrailEvent | fromjson | {Time: .eventTime, Sub: .additionalEventData.sub}' cognito_events.json > list.txt
```
あとは抽出されたユーザ名からどのユーザが使用しているかを調べることができました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4021557/680cf18f-fd66-4100-ac1f-49a89967c570.png)
TODOYOURCD

```ruby:qiita.rb

sdfdsfds
-----------------------
import tpl from './option-card.html?raw';
import localCss from './option-card.css?raw';
import commonCss from '../css/common.css?raw';

function sheet(c){const s=new CSSStyleSheet();s.replaceSync(c);return s;}
const shared=sheet(commonCss);

export class OptionCard extends HTMLElement{
    _data=null;
    constructor(){
        super();
        this.attachShadow({mode:'open'});
        this.shadowRoot!.innerHTML=tpl;this.shadowRoot!.adoptedStyleSheets=[shared,sheet(localCss)];
    }
set data(v){
    this._data=v;this.render();
}
render(){
    if(!this._data)return;
    const r=this.shadowRoot!;
    r.querySelector('.title').textContent=this._data.title;r.querySelector('.desc').textContent=this._data.desc;
}}

if(!customElements.get('option-card'))customElements.define('option-card',OptionCard);

export type OptionData = {title:string,desc:string};




  ```
16 Personalitiesから考える課金検証に適した人材

こんにちは。今回はビジネスの根幹、「課金機能」の検証がテーマです。

サービスの収益に直結するこの機能は、品質保証（QA）にとって一切の妥協が許されない重要領域です。課金関連の不具合は、お客様の信頼失墜や事業継続に関わる深刻な問題に直結しかねません。

まさに品質を守る「最後の砦」として、課金検証を担うQAの役割は非常に重要です。単なる画面チェックに留まらず、複雑なロジックやあらゆる状況を想定した、高い精度と専門性が求められます。プレッシャーも大きいですが、サービスの安心・安全を支える、非常に価値ある仕事と言えるでしょう。

では、この責任重大で専門性の高い業務に、どのような方が適性があるのでしょうか？ 
今回は「16 Personalities」を切り口に考察してみたいと思います。


# 16 Personalities について

「私は主人公だったよ、あなたは何だった？」なんていう会話が職場などで飛び交った記憶が、みなさんにも少なからず、あるのではないでしょうか？

私の職場でも流行りました。

https://www.16personalities.com/ja

16Personalitiesは、MBTI（マイヤーズ＝ブリッグス・タイプ指標）を基にした性格診断テストで、外向型(E)・内向型(I)、感覚型(S)・直観型(N)、思考型(T)・感情型(F)、判断型(J)・知覚型(P)の4つの指標の組み合わせで、16の性格タイプに分類されるようです。自己理解や他者理解に役立つとされています。

# Geminiへのインプット

責任重大で専門性の高い業務の中でも、特に課金検証に適した性格タイプについて気になっていたので、Geminiに以下のように尋ねてみました。

※Geminiのモードや質問する時期によっては、下記のインプットでも同じ回答を得られるとは限りません。また、これは私自身の経験を元にしたものであり、真実ではありません。

:::note info
あなたは品質保証人材育成のエキスパートです。
課金検証に適した 16 Personalities と詳細な理由を教えてください。

課金検証はミスを起こすと、発生した障害の重要度は常に高く、また、内容によっては、企業の信頼も失墜します。また、場合によっては、特定の個人を避難するような叱責を受けることもあります。障害が発生した場合は、24時間対応が必要です。

責任感は強く求められますが、その代わり、やりきればMVPなど称賛を受けることも多いのが事実です。自分に厳しく、何かあった場合は、冷静に判断し、自分が請け負ったポジションで起きたこととして、感情に振り回されない、エンジニア思考の高い人が適任です。
:::

# Geminiのアウトプット

## その1： 幹部 （ESTJ）

* **効率性と組織力**
    * ESTJは効率性を重視し、組織的に物事を進めることが得意
    * 課金検証においても、作業を効率化し、正確性を維持するためのシステムを構築することが可能
    <br>
* **リーダーシップ**
    * ESTJはリーダーシップがあり、チームをまとめ、目標達成に向けて導いていく
    * 課金検証チームを率いる立場としても適任
    <br>
* **決断力**
    * ESTJは決断力があり、困難な状況においても迅速に判断を下すことが可能
    * 障害発生時など、緊急性の高い状況においても、冷静に状況を判断し、適切な指示を出す

## その2： 建築家 （INTJ）

* **分析力**
    * INTJは分析力に優れ、複雑なシステムを理解し、問題点を特定することが可能
    * 課金システムの構造を理解し、潜在的なリスクを分析する上でスキルを発揮
    <br>
* **戦略的思考**
    * INTJは戦略的に物事を考え、長期的な視点で計画を立てることが可能
    * 課金検証プロセス全体の改善や、将来的なリスクへの対策を検討する際に力を発揮
    <br>
* **決断力**
    * INTJは独立心が強く、自分のペースで作業を進めることを好む
    * 集中力を必要とする課金検証作業において、周囲の影響を受けずに、自分のペースで作業を進めることが可能

## その3： 管理者 （ISTJ）

* **細部へのこだわり**
    * ISTJは非常に細部指向で、正確性を重視
    * 課金検証において、わずかなミスも見逃さない注意力と、緻密な作業を厭わない忍耐強さは大きな強みに
    <br>
* **冷静さ**
    * ISTJは感情に流されず、冷静に状況を判断することが可能
    * 障害発生時など、プレッシャーのかかる状況でも、落ち着いて問題解決に取り組むことができる
    <br>
* **ルールと手順の遵守**
    * ISTJはルールや手順を重視し、決められた手順に従って正確に作業を進めることを得意している
    * 課金検証においても、定められた手順を遵守することで、ミスを最小限に抑えることが可能

# 結果を基に考えた組織案

```mermaid
graph TD;
    幹部_ESTJ-->建築家_INTJ;
    幹部_ESTJ-->管理者_ISTJ;
```

それぞれには

幹部（ESTJ）には、検証リーダー
建築家（INTJ）には、テスト設計
管理者（ISTJ）には、テスト実行

を担当いただくと、
とても良さそうなチームができそうだということが分かりました

# この3人の共通点

この3人の共通点は <font color="Red">**TJ** </font>が含まれていること

TJ型：ESTJ・INTJ・ISTJ

* **ルールと秩序の重視**
    * 論理的思考と客観性を重視し、明確なルールや秩序を好む
    * 組織や社会のルールを尊重し、それを守ることを重視する
    <br>
* **効率性と責任感**
    * 目標達成のために計画的に行動し、効率性を追求する
    * 責任感が強く、与えられた役割を確実に果たそうとする
    <br>
* **感情よりも論理**
    * 感情的な側面よりも、論理的で客観的な判断を重視する傾向がある
    * 感情に流されず、合理的な解決策を求めるため、冷酷に見えることがある

# まとめ

いかがでしたでしょうか？

私は根っから人に興味津々なタイプで、どうすればメンバーそれぞれが気持ちよく働けるかを日々考えています。だからこそ、16 Personalitiesや懐かしのどうぶつ占いなんかを使って、お互いの理解を深め、**最高のチーム**を築き上げるのが好きなんです。

今回、課金検証に適した性格タイプの方からは、ウザがられるタイプと言えるかもしれません（笑）

ちなみに、私は指揮官（ENTJ）です 🌾

課金検証を始め、長いこと重責のある検証業務を担ってくれている仲間に 16 Personalities をやってもらったところ、一人を除いて、上記のタイプに該当するメンバーはいませんでしたが、

もっとも信頼している相方は、建築家（INTJ）でした。
なので、Geminiが出してくれた答えは参考になります。

仕事に対する姿勢・考えが形成する性格タイプというものがあるのかも知れません。

参考程度に読んでいただければと思います。
個人的備忘録：Terraform / CloudFormation の depends_on の使い方と注意点を整理してみた

## はじめに

インフラストラクチャーをコードで定義する際（IaC）、複数のリソース間に明確な依存関係がある場合があります。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

`depends_on` は、TerraformやCloudFormationといったIaCツールで、リソース間の作成順序を明示的に指定するために使用されます。

---

## Terraformにおける `depends_on`

```hcl
resource "aws_instance" "app" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  depends_on = [aws_security_group.app_sg]
}
```

### 解説：
Terraformは基本的にリソースの参照から依存関係を自動的に判断しますが、自動では検知されない関係を明示的に定義したいときに `depends_on` を使用します。この例では、EC2インスタンスはセキュリティグループが作成された後に作成されます。

**参考文献**

https://dexall.co.jp/articles/?p=2303

---

## CloudFormationにおける `DependsOn`

```yaml
Resources:
  MyBucket:
    Type: AWS::S3::Bucket

  MyBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref MyBucket
      PolicyDocument: ...
    DependsOn: MyBucket
```

### 解説：
CloudFormationも通常は `!Ref` や `!GetAtt` で依存関係を推測できますが、こちらも手動で順番を指定したい場合に `DependsOn` を利用します。たとえば、ポリシーは対象のバケットが先に存在していなければなりません。

**参考文献**

https://dev.classmethod.jp/articles/use-dependson-on-cloudformation/

---

## よくある使いどころ

| シチュエーション                         | なぜ `depends_on` が必要か                                      |
|------------------------------------------|------------------------------------------------------------|
| IAM Role が必要な Lambda 関数            | Roleが存在しないとLambda作成に失敗する                         |
| S3 バケットのあとに BucketPolicy を設定  | バケットが存在していないとポリシーの適用に失敗する               |
| VPC → Subnet → EC2 インスタンス         | サブネットやSGよりも先にインスタンスを作るとエラーになる可能性    |
| Terraform の null_resource などで順序制御 | 明示的な順序が必要な場合に使用される                             |

---

## まとめ

ここまで読んでいただきありがとうございました。以下に簡単にまとめてみましたので、参考にしてみてください...！

- `depends_on` の使用は最小限にとどめることが推奨されます。
- 自動で推測される依存関係に任せ、どうしても必要な場合のみ明示する方が保守性の高いテンプレートになります。

| ツール           | ディレクティブ名 | 用途                          |
|------------------|------------------|-------------------------------|
| Terraform        | `depends_on`     | 作成順序の明示的な制御       |
| CloudFormation   | `DependsOn`      | リソース間の明示的な依存関係 |
*argsと**kwargsの誤解


`*` や `**` は「アンパッキング（展開）するもの」と言われることが多いですが、
実際には状況によって「パック（まとめる）」動作にもなります。
この2つの記号は、**関数の定義時と呼び出し時で全く逆の意味になる**ため、混乱しやすいポイントです。

---

## ✅ 結論

1. **関数定義時**： `*args`, `**kwargs` は「複数の引数をまとめて受け取る」 → **パック**
2. **関数呼び出し時**： `*`, `**` は「シーケンスや辞書をばらして渡す」 → **アンパック**

---

## 🟣 関数定義時の例（パック）

```python
def func(*args, **kwargs):
    print(args)
    print(kwargs)

func(1, 2, 3, a=10, b=20)
# → args: (1, 2, 3)
# → kwargs: {'a': 10, 'b': 20}
```

- 位置引数は `args` という **タプル** に
- キーワード引数は `kwargs` という **辞書** に

---

## 🟢 関数呼び出し時の例（アンパック）

```python
def greet(greeting, name):
    print(f"{greeting}, {name}!")

args = ("Hello", "Alice")
greet(*args)  # → Hello, Alice!
```

```python
def display(voltage, action):
    print(f"{action} at {voltage}V")

d = {"voltage": 100, "action": "Run"}
display(**d)  # → Run at 100V
```

※ このように、すでにタプルやリスト、辞書として持っている引数を、`*` や `**` を使って「ばらして渡す」ことで、個別の引数として関数に供給できます。

---

## ✅ まとめ

| 使用場面         | `*` / `**` の意味                           |
|------------------|----------------------------------------------|
| 関数 **定義時**   | 複数の引数をまとめる（パック）                |
| 関数 **呼び出し時** | タプル/リストや辞書をばらして渡す（アンパック） |

---

📎 公式ソース：
- [任意の引数リスト（4.9.4）](https://docs.python.org/ja/3/tutorial/controlflow.html#arbitrary-argument-lists)
- [引数リストのアンパック（4.9.5）](https://docs.python.org/ja/3/tutorial/controlflow.html#unpacking-argument-lists)
MM概要编辑中

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3795764/02e8046e-1b6a-439f-9605-d488a8a919fd.png)
購買依頼：他部門から購買部門への依頼。
購買発注：購買部門は仕入先へ発注する。


在庫引当：将现有的库存数量分配给某个订单需求。
買掛金：应收/付账款

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3795764/8b9eb7d0-86fb-4d43-9cd8-e11448db0297.png)
メディアサイトのアクセスランキング採用率は？ 平均 74%

さまざまなサイトでアクセスランキングを目にするが、実際どのくらい採用されているのだろうか？ 記事コンテンツを中心としたいわゆるニュース系メディアサイト220サイトについて調査してみた。

その結果、**約 74% のサイトでアクセスランキングが表示されている** ことがわかった。

また、一般性の高いメディアにはアクセスランキングが多く、専門性が高いメディアには採用が少ない傾向も見られた。

ランキングコーナーの名称もさまざまだが、「アクセスランキング」という呼称が最も多かった。

弊社でGA4を利用したアクセスランキング表示サービス [Rankelt4](https://ranklet4.com/) を運営している一環としての調査だが、メディアサイト運営者の参考になれば幸いである。

:::note info
この記事は [メディアサイトのアクセスランキング採用率は？ 平均 74% | ideaman's Notes](https://notes.ideamans.com/posts/2025/access-ranking-adoption.html) からの転載です。
:::

---

## 対象サイト

調査の詳細データを以下のスプレッドシートで公開した。

- [ニュース系メディアサイト アクセスランキング利用調査 2025年4月](https://docs.google.com/spreadsheets/d/1ldTw-apT69OTirMaPESrE0ehSi3_dFQUYxEaWOJvTIE/edit?usp=sharing)

![spreadsheet.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/35178/5408c161-6525-4f26-a51a-2e628f9c5b53.png)


サイトの選定には、AIディープリサーチを利用した。そのため厳密な選定基準はない点は留意されたい。

- [AIで300件ほどのメディアサイトを挙げてみた | ideaman's Notes](https://notes.ideamans.com/posts/2025/media-sites.html)

300サイトほどピックアップされたが、リストには転職サイトや不動産サイト、キュレーションサイト、SNSなども含まれていたため、記事コンテンツ中心のニュース・ブログサイト風のメディアサイトに絞り込んだところ、220サイトになった。

それぞれのサイトのトップページにアクセスランキング、またはそれに類似したセクションがあるかを確認した。

## ジャンル別の採用率

おおよそのジャンル別に集計し、採用率の高い順に並べたのが以下の表である。

| 大分類 | サイト数 | アクセスランキング利用 | 採用率 |
| --- | --- | --- | --- |
| 地方紙・地域紙メディア | 20 | 19 | 95.00% |
| IT企業・ネット専業メディア | 34 | 30 | 88.24% |
| 全国紙系メディア | 13 | 11 | 84.62% |
| 出版社・雑誌系メディア | 46 | 37 | 80.43% |
| 国際・通信社系メディア | 8 | 6 | 75.00% |
| TV・ラジオ局系メディア | 14 | 10 | 71.43% |
| 女性向け・ファッション誌発 | 13 | 9 | 69.23% |
| 企業オウンドメディア | 22 | 14 | 63.64% |
| 専門業界メディア | 30 | 19 | 63.33% |
| 学術・研究メディア | 11 | 4 | 36.36% |
| 行政・公共機関 | 3 | 1 | 33.33% |
| オルタナティブ・独立系 | 6 | 2 | 33.33% |
| 総計 | 220 | 162 | 73.64% |

**やはり新聞・ネットニュースメディアの採用率が高い。もはや標準機能と言っていい採用率である。**

一方、専門性の高いメディアでの採用は平均を下回る。流行や周囲の動向に関心が小さい、あるいはそうあるべきではないというポリシーが反映されているのかもしれない。

## ランキングの名称

アクセスランキングのセクションにどのような名称を用いているかが以下である。

| アクセスランキング名 | 採用サイト数 |
| --- | --- |
| アクセスランキング | 28 |
| ランキング | 20 |
| 人気記事ランキング | 15 |
| RANKING | 7 |
| 人気記事 | 6 |
| 人気ランキング | 6 |
| ニュースランキング | 4 |
| 記事ランキング | 3 |
| いま読まれています | 2 |
| その他 | 71 |
| 総計 | 162 |

名称としては、**「アクセスランキング」が最多**で、「ランキング」「人気」がそれに次ぐ。

その他は度数1ずつの例をまとめた結果だが、それぞれ工夫が見られる。スプレッドシートにて確認できる。

## まとめ

有名サイトを中心とした220サイトの調査では、アクセスランキングは採用していないメディアサイトの方が少数という結果となった。

また、メディアの性質によっても違いがあり、呼称としては「アクセスランキング」が最も一般的であることが確かめられた。

アクセスランキングは流行を追ったり、アクセスを扇動するためだけではない。自身の興味があることと、他の人が興味のあること、そのギャップを確かめるコンテンツでもあると思う。

**GA4を利用し、最も簡単にアクセスランキングを実現するために開発した弊社サービス [Rankelt4](https://ranklet4.com/)** もよければチェックしていただきたい。
Cloud FunctionsからCloud SQL(MySQL)を擬似的に停止・再開する方法【activationPolicy活用】


Cloud SQL(MySQL) をスケジュール的に停止・再開してコストを抑えたい…  
そのような場面で便利なのが、Cloud Functions からの `activationPolicy` 操作です。

---

## やりたいこと

- Cloud SQL を夜間は「停止」しておきたい
- 朝になったら「再開」させたい
- Cloud Functions から制御したい

---

## 正しい方法：`activationPolicy` の変更

Cloud SQL のインスタンス設定には `activationPolicy` という項目があります。

### 値と意味

| 値       | 説明                 |
|----------|----------------------|
| ALWAYS   | 常に起動（通常状態） |
| NEVER    | 手動でしか起動しない（停止相当） |

> ※ `ON_DEMAND` は SQL Server 専用で、MySQL では無視されます。

---

## Cloud Functions からの制御例

環境変数 `PROJECT_ID` と `INSTANCE_ID` を設定した上で以下のような関数を用意します。

### 起動（再開）用の関数

```python
import os
from googleapiclient.discovery import build
from google.auth import default
import functions_framework

@functions_framework.http
def start_cloud_sql(request):
    credentials, _ = default()
    service = build('sqladmin', 'v1beta4', credentials=credentials)

    project_id = os.environ.get("PROJECT_ID")
    instance_id = os.environ.get("INSTANCE_ID")

    result = service.instances().patch(
        project=project_id,
        instance=instance_id,
        body={"settings": {"activationPolicy": "ALWAYS"}}
    ).execute()

    return f"Cloud SQL instance {instance_id} set to ALWAYS: {result}", 200
```

---

### 停止用の関数

```python
import os
from googleapiclient.discovery import build
from google.auth import default
import functions_framework

@functions_framework.http
def stop_cloud_sql(request):
    credentials, _ = default()
    service = build('sqladmin', 'v1beta4', credentials=credentials)

    project_id = os.environ.get("PROJECT_ID")
    instance_id = os.environ.get("INSTANCE_ID")

    result = service.instances().patch(
        project=project_id,
        instance=instance_id,
        body={"settings": {"activationPolicy": "NEVER"}}
    ).execute()

    return f"Cloud SQL instance {instance_id} set to NEVER: {result}", 200
```

---

## 環境変数の指定方法（第1世代）

### CLIでデプロイする例

```bash
gcloud functions deploy start-cloud-sql \
  --runtime python310 \
  --trigger-http \
  --entry-point start_cloud_sql \
  --set-env-vars PROJECT_ID=my-project,INSTANCE_ID=my-instance

gcloud functions deploy stop-cloud-sql \
  --runtime python310 \
  --trigger-http \
  --entry-point stop_cloud_sql \
  --set-env-vars PROJECT_ID=my-project,INSTANCE_ID=my-instance
```

---

## 注意点：アクセスがあると起動する

`activationPolicy: "NEVER"` にしても、接続が発生するとインスタンスが自動で起動します。

これを防ぎたい場合は、接続元IPを遮断するのが有効です。

```python
service.instances().patch(
    project=project_id,
    instance=instance_id,
    body={
        "settings": {
            "ipConfiguration": {
                "authorizedNetworks": []
            }
        }
    }
).execute()
```

---

## まとめ

| 操作           | MySQL対応 | 解説 |
|----------------|-----------|------|
| `activationPolicy = "NEVER"`  | ○ | 疑似停止。アクセスがあると再起動するので注意 |
| `activationPolicy = "ALWAYS"` | ○ | 常時稼働状態 |
| `start()` / `stop()`          | × | SQL Server専用機能 |

---

## 参考

- [Cloud SQL Admin API](https://cloud.google.com/sql/docs/mysql/admin-api/)
【LaravelAPI】ファイル構成とざっくりとしたルール （MVC + S）

## はじめに
3年ほどLaravelでAPIを開発してきました。
試行錯誤していった結果、この書き方だと保守も容易かつ実装もスムーズに行えました。

普段はMVC+Sで開発していて、Repositoryは採用していないので、その点はご注意ください。
またもっといい方法だったり、案があるかたはご提案いただけますと幸いです。

## api.php

Route::groupは文字列検索で引っ掛け辛いので、使用しない。
実装者ではない人が保守対応するとき、フロント→APIと探して文字列検索出来ないとかなりストレスになります！（管理者画面がある場合は後半のパスが被りやすいのでなおさら）

:::note alert
良くない例
:::

```php
Route::group(['prefix' => '/users'], function () {
  Route::post('/', 'Users\IndexController');
  Route::post('/{id}', 'Users\GetController');
});
```


:::note info
いい例
:::

```php
Route::post('/users', 'Users\IndexController');
Route::post('/users/{id}', 'Users\GetController');
```


## Controller

Controllerのディレクトリは以下の構造とします。
可能な限りControllerの名前はAPIのURIと紐づけやすい名前にしましょう！
ControllerからDBの操作は行いません。

```plaintext
Controllers/
 ├ Users/
     ├ IndexController.php // 一覧
     ├ GetController.php  // 1件取得
     ├ EditController.php  // 編集
     ├ RegisterController.php  // 登録
     ├ DeleteController.php  // 削除
```

## Request
Requestの構造は基本的にControllerと同じです。

:::note warn
バリデーションの和名にvalidation.phpは使用していません。
変数名が被った時に結局各Requstで上書きが必要になり、保守でバグを生みかねないためです。
:::


```plaintext
Requests/
 ├ Users/
     ├ UserRequest.php  // ここにパラメータの和名と共通バリデーションを書きます
     ├ IndexRequest.php  // UserRequestを継承
     ├ EditRequest.php  // UserRequestを継承
     ├ RegisterRequest.php  // UserRequestを継承
```

## Service

複雑な処理や、DB操作などはServiceで行います。 こちらもAPIのURIに沿って作成しましょう。

```plaintext
Services/
 ├ UserService.php
 ├ ProjectService.php
```

## Resource

Resourceは基本API設計のModelごとに作成します。

```plaintext
Resources/
 ├ UserResource.php
 ├ BackupResource.php
```

Resourceへ各モデルに書いてあるリレーション先の情報も書きます。
`whenLoaded()`を使用することによって、`with` `load`された値場合のみ値が返却されます。

サンプル
`UserResource.php`
```php
    public function toArray($request)
    {
        return [
            'id' => $this->id,
            "name" => $this->name,
            "email" => $this->email,
            'relations' => RelationResource::collection($this->whenLoaded('tRelations')),
        ];
    }
```

### ResourceCollectionの使い所

ResourceをカスタマイズできるCollectionという機能があります。\
こちらは既存レスポンスに +α したいときなどに利用しましょう！

## Test

各テストのメソッド名は test\_ステータスコード\_テスト の内容とする

```php
public function test_200_ユーザ取得() {}
public function test_404_存在しないユーザを指定() {}
public function test_422_required() {} // 必須項目のテスト
public function test_422_max() {}  // 最大文字数のテスト
```

ディレクトリ構成は以下のようになります。Resourceのテストを書き、各エンドポイントのテストはidのみとします。
※リレーション先がある場合はリレーション先のIDが正しいかテストをしてください。

```plaintext
Feature/
  ├ Resources/
     ├ UserResourceTest.php
     ├ BackupResourceTest.php
 ├ Users/
     ├ IndexTest.php
     ├ GetTest.php
     ├ EditTest.php
     ├ RegisterTest.php
```

## ステータスコード

### 200
- 成功

### 201
- 登録成功（idを返す）

### 401

- 未ログイン
- 不正なトークン

### 403

* 権限エラー

### 404

- 指定されたURIが存在しない場合
- パスパラメータに紐づくデータが存在しなかった場合\
  (例) GET /user/{id}

```php
MUser::find($id) ← undefiend
```

### 422

- バリデーションエラー

### 500

- 予期していないエラー
SSE-S3を選択した場合のバケットキー有効有無の違い

# S3バケットキーとSSE-S3の関係

## はじめに

S3バケットの暗号化設定について、「SSE-S3」と「バケットキー」の関係性について混乱することがあります。

## バケットキーとは

バケットキーは、AWS KMS呼び出しのコスト削減を目的とした機能で、主に「SSE-KMS」暗号化方式で使用されるものです。
バケットレベルのキーを生成し、S3に一時的に保存することで、AWS KMSへのリクエスト回数を大幅に削減できます。

## SSE-S3とバケットキーの関係

結論から言うと：

> **SSE-S3暗号化使用時、バケットキーの有効/無効設定は挙動に影響を与えません**

理由は以下の通りです：

1. バケットキーはKMS呼び出しコスト削減のための機能
2. SSE-S3はS3内で完結する暗号化方式のため、KMS呼び出しが発生しない
3. したがって、SSE-S3使用時はバケットキーが有効でも無効でも違いはない

## UI上の注意点

S3コンソール上では**SSE-S3設定時でもバケットキーの有効/無効を切り替えることが可能です。**  
しかし、この設定はSSE-S3使用時には実質的に何の効果も持ちません。

## 将来的にSSE-S3からSSE-KMSへの設定変更を考慮する場合

AWS re:Postのコミュニティ回答によると：(<a href="#参考ドキュメント">参考ドキュメント[2]</a>)  
個人的な意見ですが、バケットキーは有効化しておけばいいかなと思いました。

> 「将来的にSSE-KMSに切り替える可能性がある場合や、個別のオブジェクトレベルでSSE-KMSを使用する可能性がある場合は、バケットキーを有効にしておくとよいでしょう。」

## まとめ

- SSE-S3暗号化使用時、バケットキーの設定は効果がない
- AWSの公式ドキュメントには明記されていないが、コミュニティ回答で確認可能
- 将来的にSSE-KMSへの移行を考慮する場合は、バケットキーを有効にしておくのも一つの選択肢

## 参考ドキュメント
[1]
[AWS re:Postのコミュニティ回答](https://repost.aws/ja/questions/QUNfHSIoUZQru2sxvaoPEdyQ/enable-bucket-key-with-sse-s3)

```
Keeping bucket key enabled or disabled won't make any difference as it's essentially a concept for SSE-KMS. Keeping bucket key enabled for SSE-KMS reduce the overall KMS cost substantially as KMS API calls request gets reduced marginally by up to 99% but that won't be the case for SSE-S# as in case of SSE-S3, AWS KMS doesn't come in to the picture for user.

バケットキーを有効または無効にしても、SSE-KMSにとっては本質的に同じことなので、違いはありません。SSE-KMSでバケットキーを有効にしておくと、KMS APIコールの要求が最大99%までわずかに減少するため、KMSの全体的なコストが大幅に削減されますが、SSE-S#の場合は、SSE-S3の場合と同様に、AWS KMSはユーザーには関係のない話です。
```

[2]
[AWS re:Postのコミュニティ回答](https://repost.aws/ja/questions/QUQPqQONRJR82adgj3xsSu0w/difference-in-functionality-and-cost-when-enabling-s3-bucket-key-for-default-encryption)

```
It's good to leave the option enabled, despite using SSE-S3, simply so that if you decide to switch to SSE-KMS later or if individual objects are uploaded with SSE-KMS selected at the object level, the SSE-KMS encryption process will leverage bucket keys for optimising costs.

SSE-S3を使用しているにもかかわらず、オプションを有効にしたままにしておくのは良いことです。後でSSE-KMSに切り替えることを決めた場合や、SSE-KMSがオブジェクトレベルで選択された状態で個々のオブジェクトがアップロードされた場合、SSE-KMSの暗号化プロセスではバケットキーが活用され、コストが最適化されます。
```
個人的備忘録：CloudFormationでOriginPathを使ってCloudFront配信を絞る方法について

## はじめに

CloudFormation で CloudFront ディストリビューションを作成する際に、「オリジンパス（OriginPath）」を指定したい場面があります。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

この記事では、S3 オリジンを使う構成で特定のパス（例: `/honda-sr-office_20250323`）を指定する方法について、**個人の備忘録**としてまとめました。

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

CloudFront を通して配信する対象を S3 バケット内の特定ディレクトリ配下に限定したい要件がありました。

その際、CloudFormation テンプレートで `OriginPath` を正しく指定する必要があり、設定ミスによるエラーを防ぐために記録しておこうと思いました。

## OriginPath とは？

`OriginPath` は、CloudFront がオリジン（例: S3バケット）にアクセスする際に追加するパスプレフィックスです。

### 例：
- `DomainName`: `my-bucket.s3.amazonaws.com`
- `OriginPath`: `/honda-sr-office_20250323`

この場合、CloudFront からのリクエストは以下のように変換されます：
```
https://your-domain.com/index.html
↓
s3://my-bucket/honda-sr-office_20250323/index.html
```

つまり、ユーザーには `/index.html` に見えても、実際には CloudFront がオリジンの特定フォルダにマッピングしてくれます。

## 設定方法

CloudFormation テンプレート内の `Origins` セクションにあるオリジン定義を以下のように変更します。

### 修正前

```yaml
Origins:
  - Id: S3Origin
    DomainName: !GetAtt S3Bucket.RegionalDomainName
    S3OriginConfig:
      OriginAccessIdentity: !Sub "origin-access-identity/cloudfront/${CloudFrontOAI}"
```

### 修正後（`OriginPath` を追加）

```yaml
Origins:
  - Id: S3Origin
    DomainName: !GetAtt S3Bucket.RegionalDomainName
    OriginPath: /honda-sr-office_20250323
    S3OriginConfig:
      OriginAccessIdentity: !Sub "origin-access-identity/cloudfront/${CloudFrontOAI}"
```

## 補足

- `OriginPath` に指定するパスは、S3 バケット内のフォルダ構成と一致させる必要があります。
- この設定により、CloudFront は `/honda-sr-office_20250323` 配下のオブジェクトのみをルートとして扱います。
- 例：アクセスパス `https://your-domain.com/index.html` は、実際には `s3://your-bucket/honda-sr-office_20250323/index.html` を参照する形になります。

## まとめ

- CloudFormation テンプレートで `OriginPath` を指定すれば、CloudFront 経由で配信するディレクトリを絞り込める
- `OriginPath` は、CloudFront がオリジンに対して内部的に付加するパスの指定
- 記述位置は `DomainName` の下、`S3OriginConfig` の前に追加
- S3 側の構成と整合性が取れていることを事前に確認すること

運用や環境ごとに切り分けたい場合にも役立つ設定なので、積極的に活用していきたいと思います！
個人的備忘録：CloudFrontディストリビューション作成時のCNAMEエラーを回避するには？

## はじめに

CloudFormation を使って CloudFront ディストリビューションを作成する際に、以下のようなエラーに遭遇しました：

```
リソース CloudFrontDistribution は CREATE_FAILED 状態です
Resource handler returned message: "Invalid request provided: AWS::CloudFront::Distribution: The parameter CNAME contains one or more parameters that are too small."
```

このエラーの原因と解決方法について、**個人の備忘録**として記録します。

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

CloudFormation テンプレートを使用して独自ドメイン付きの CloudFront ディストリビューションを構成していたところ、スタック作成時にエラーが発生しました。

:::note info
個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。
:::


調査の結果、`DomainName` パラメータが空のまま `Aliases` に渡されていたことが原因で、CloudFront が "CNAME too small" と判断していたことがわかりました。

## エラーの内容

```
The parameter CNAME contains one or more parameters that are too small.
```

このエラーは、CloudFront の `Aliases`（CNAME）に指定された値が **空・無効・短すぎる** 場合に発生します。

## 解決策

CloudFormation テンプレート内で `Parameters` セクションにデフォルト値を設定することで、CNAME エラーを回避できます。

```yaml
Parameters:
  DomainName:
    Type: String
    Default: "xxx.blog"
    Description: "独自ドメイン名（例: xxx.blog）"

  HostedZoneId:
    Type: String
    Default: "ZXXXXXXXXXXXXXX"
    Description: "Route53のホストゾーンID"
```

## まとめ

- `DomainName` に空文字や不正な値が入ると CloudFront の CNAME エラーが発生します
- `Default` を設定することで、値の未指定によるエラーを防止できます

今後同様のテンプレートを作成する際にも、このようにデフォルト値を定義しておくと安心です！
「How AI will disrupt BI as we know it」の内容まとめ

dbtのCEOが書いた「How AI will disrupt BI as we know it」の記事が話題だったので内容をまとめました。
https://www.getdbt.com/blog/how-ai-will-disrupt-bi

# 全体の内容 
近年、BI（ビジネスインテリジェンス）ツールは「データ可視化」だけでなく、探索的分析からガバナンス付きレポートまでを一貫提供する“生産ライン”として進化してきた。しかし、AIとオープンメタデータプロトコル（MCP: Model Context Protocol）の登場により、従来のBIワークフローは大きな転換点を迎えつつある。参照元の記事では、技術的視点から以下の内容に触れている。
- BIツールの主要機能とアーキテクチャ  
- MCPの仕様概要と連携方式  
- AIが探索的データ分析（EDA）を自動化する仕組み  
- `コンベヤーベルト`モデルの再編成パターン  
- 今後2年間に予想される技術的インパクト

---

# 1. BIツールの主要機能とアーキテクチャ  
BIは以下の三機能をセマンティックレイヤー上で連携させている。

## 1.1 探索的データ分析（EDA）  
- **目的**：仮説検証の高速反復  
- **要件**：低ガバナンス／高柔軟性  
- **実装例**：SQL自動補完、インタラクティブなフィルタリングUI  

## 1.2 セマンティックモデル  
- **目的**：メトリクス定義とテーブル結合の一元管理  
- **要素**：  
  - メトリクス（例: 売上合計、粗利率）  
  - ディメンション（例: 日付、商品、顧客）  
- **実装例**：LookML、dbt Exposure

## 1.3 ダッシュボード／レポート共有  
- **目的**：アクセス制御・監査性を担保した可視化配信  
- **フェーズ**：  
  1. 個人用レポート  
  2. 共有レポート（監査ログ／変更履歴管理）  
  3. 本番プロダクト（SLA／可用性保証）

---

# 2. MCP（Model Context Protocol）によるメタデータ連携

## 2.1 MCPの概要  
MCPは「モデル定義」「メトリクス」「ビジネス文脈」を標準フォーマットでやり取りするオープンプロトコルのこと。典型的にはモデル名とディメンションのリスト、各メトリクスに対応する集計式や計算方法をJSON形式で記述し、API経由で取得する。

参考：[Model Context Protocol（MCP）とは？生成 AI の可能性を広げる新しい標準](https://zenn.dev/cloud_ace/articles/model-context-protocol)

## 2.2 MCP の API フロー  
1. **メタデータ提供者（dbt／Semantic Layer）** がエンドポイントを公開  
2. **AI アグリゲーター**（ChatGPT Enterprise, Claude）がHTTPリクエストで取得  
3. **LLM** が問い合わせ文脈に合わせて動的にSQLやコードを生成し、実行可能なクエリを返却

---

# 3. AI×MCP による EDA 自動化

## 3.1 コード生成エンジンのアーキテクチャ  
- **入力**：自然言語クエリとMCPメタデータ  
- **処理**：意図解析→SQL／スクリプト生成→セマンティックレイヤー整合チェック  
- **出力**：実行可能なクエリおよび可視化スクリプト

## 3.2 実証例：dbt + MCP + Claude 3.7  
- 既存BIツールの「Explore」機能比で **50%以上** の工数削減  
- 自然言語での質問からSQL生成、チャート出力まで **数秒** で完了

---

# 4. “コンベヤーベルト”モデルの再編成パターン

| パターン       | 説明                             | メリット               | デメリット                   |
| -------------- | -------------------------------- | ---------------------- | ---------------------------- |
| Excel添付      | EDA結果を静的ファイルで配布      | 手軽                   | ガバナンス欠如、更新コスト高 |
| BI再構築       | BIツールに再実装                 | セキュア               | 二度手間、開発負荷           |
| MCP同期        | AI成果物をMCP経由でBIに取り込み | 一貫性高、運用負荷低    | MCP実装コスト               |

最適解は **MCP同期**。AIでEDAを完結させ、BIツールはガバナンスとダッシュボードに特化させる。

---

# 5. 今後2年間の技術的インパクト

- **EDAの自動化加速**  
  LLMベースのチャットUIがデファクトスタンダードに  
- **BIプラットフォーム再編**  
  ガバナンス・可視化専門のマイクロサービス化  
- **新興プレイヤー台頭**  
  MCP対応とAI最適化でレガシーを置き換え  

---

# まとめ  
AIとMCPの組み合わせは、BIの“探索→モデル→可視化”という従来の流れを再定義する。技術者はMCP準拠のセマンティックレイヤー構築とLLM連携パイプラインの設計に注力し、次世代のデータ分析基盤を構築することが求められる。
Ruby - IPアドレスがサブネット指定に含まれるか判定する例

# 例

```rb
IPAddr.new("127.0.0.1/31").include?('127.0.0.1') # true

IPAddr.new("127.0.0.1/31").include?('127.0.0.0') # true

IPAddr.new("127.0.0.1/32").include?('127.0.0.1') # true

IPAddr.new("127.0.0.1/32").include?('127.0.0.0') # false

```

# IPアドレス範囲の確認例

```rb
IPAddr.new("127.0.0.1/32").to_range.to_a.map { |ip| ip.to_s }
# ["127.0.0.1"]

IPAddr.new("127.0.0.1/31").to_range.to_a.map { |ip| ip.to_s }
# ["127.0.0.0", "127.0.0.1"]

IPAddr.new("127.0.0.1/30").to_range.to_a.map { |ip| ip.to_s }
# ["127.0.0.0", "127.0.0.1", "127.0.0.2", "127.0.0.3"]
```

# 参考

https://docs.ruby-lang.org/ja/latest/class/IPAddr.html
Power Automate で AI Builder で抽出した情報を SharePoint リストの複数選択肢列に代入する


# はじめに

SharePoint リストの選択肢列、非常に便利です。また、複数選択を許可するか指定することができます。
複数選択を許可した際、少し癖が強くなるため、今回は、Power Automate で、AI Builder で抽出した情報を SharePoint リストの複数選択肢列に代入する方法を紹介します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/bdbc3f95-f0bc-4c7f-a6ae-cff178c3144e.png)

# リストの準備

リストにて複数選択可能なと都道府県用の列を作ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/872cfd85-2ee0-4ca8-aed0-0ba2aa532c3c.png)

こんな感じでデータが入ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/000e2fab-0125-4132-9233-12fdec9fbda9.png)

# AI Builder プロンプト

AI Builder のプロンプトでは、プロンプトを部品化して Power Automate から利用することができます。

例えば、メールが届いたら Power Automate のフローが自動で起動して、メール本文を AI Builder のプロンプトに渡して必要な情報を抽出して、別のシステムに展開するような自動化フローを簡単に作ることができます。

また、AI Builder のプロンプトでは、出力形式を JSON に指定することも出来ます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/f43bcb3a-2276-41a7-a363-39abeaedf9a2.png)

```
{
  "name": "山田太郎",
  "prefectures": [
    {
      "value": "東京都"
    },
    {
      "value": "大阪府"
    },
    {
      "value": "福岡県"
    }
  ]
}
```

:::note 

最初以下のような形式にしようとしましたが、エラーになったため、上記のような形式に変えました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/ed45aa8f-9914-4b6b-bc12-05c3467ca52c.png)

:::


プロンプト全体は以下のような感じです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/8dcb258a-08df-44d0-a052-128066274446.png)

# Power Automate フロー

Power Automate フローはこんな感じで作成します。とりあえず今回は手動トリガーフローにしています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/12026c7f-e7dc-4af9-a5d1-6287f08835db.png)

複数選択肢列は以下のようなオブジェクト配列形式で渡す必要があるため、AI プロンプトが出力した JSON の prefectures をそのまま渡します。※そのまま渡せるような形式で AI プロンプトに出力してもらうのが良いと思います。

```
[
  { "Value": "東京都" },
  { "Value": "大阪府" },
  { "Value": "福岡県" }
]
```

:::note

既定だと、以下のような形式となっているため、アレイ全体の入力に切り替えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/7d9bb152-0121-42f3-848d-0d33fd5c801a.png)

:::

実行してみました。無事登録されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/e9075bb9-3a63-4cd7-897b-103a52049353.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/e3af09ef-24bc-4e93-a615-701b1944595d.png)

# まとめ

Power Automate で、AI Builder で抽出した情報を SharePoint リストの複数選択肢列に代入する方法を紹介しました。情報の転記先の列の種類を踏まえ、AI プロンプト側で JSON 出力する際の形式を指定することがポイントになります。