OmniAICreator/Qiita-1.07M huggingface dataset:
「続LaTeX2e階梯・縦組編」で紹介されている縦組パッケージをLuaLaTex用に修正する

藤田眞作氏の縦組パッケージは使い勝手が良いのだけれども、LuaLaTeXではそのまま使えないので、これを修正する方法を示す。

1) zw あるいは zh となっているところを、それぞれ、\zw、 \zh と書き換える

2) \kanjiskipとなっているところを、\ltjsetparameter{}で囲む
3) \xkanjiskipとなっているところを、\ltjsetparameter{}で囲む

    たとえば、\xkanjiskip=\kanjiskipとなっている場合には、
    \ltjsetparameter{xkanjiskip=\ltjgetparameter{kanjiskip}}
    とする。

4) \smash{...}となっているところを、\hbox{\smash{...}}とする

以上

補足；

\ltjsetparameter{} とは、LuaTeX-ja（LuaTeXをベースにした日本語組版拡張）のパラメータを設定するためのコマンドである。概要はつぎのとおり。

LuaTeX-ja は、LuaTeXに日本語組版機能を追加した拡張で、従来のpTeX系とは異なる方法で日本語組版を実現している。\ltjsetparameter{} は、LuaTeX-jaの組版パラメータを調整するためのコマンドである。引数にパラメータ名と値を指定して、組版の挙動（字間や禁則処理、縦横の設定など）を変更することができる。

使い方
\ltjsetparameter{kanjiskip=0.3zw}

これは、漢字間の字間（kanjiskip）を「0.3zw」に設定する例である。ほかにも
xkanjiskip（漢字と異種文字間の字間）
prebreakpenalty（行頭禁則のペナルティ）
postbreakpenalty（行末禁則のペナルティ）
autospacing（自動字間調整の有効・無効）
などがある。
    
\kanjiskipと\xkanjiskipについて

日本語組版では、漢字（全角文字）と英数字（半角文字）が混在するため、文字間のスペース（字間）を調整する必要がある。これを「字間調整」と呼ぶ。

\kanjiskip は、漢字と漢字の間に挿入されるスペース（漢字間の字間）を表すパラメータであり、\xkanjiskip は、漢字と英数字・記号などの異種文字との間に挿入されるスペース（異種文字間の字間）を表すパラメータである。そして、

\xkanjiskip=\kanjiskip 

とは、「漢字と異種文字の間の字間（\xkanjiskip）を漢字同士の字間（\kanjiskip）と同じ値に設定する」という意味である。


:::note warn
注意
藤田眞作氏の縦組パッケージは、Copyright xxxx by Shinsaku Fujita. All right reserved.　とのみ記載されており、改編についての一切の記載がない。コードが公開されている以上、これらのコードを私的利用の範囲（個人が家庭内や業務上限られた範囲で使う）で改編することは容認されるはずであるが、これを公開することには著作権上の問題がある。この点に注意する必要がある。

:::
個人的備忘録：LinuxユーザーがDockerにハマる理由を自分なりに整理してみた

## はじめに

日々進化するソフトウェア開発の現場において、開発環境の整備や運用の効率化は重要なテーマとなっています。

:::note warn
**その中で注目を集める技術のひとつがDockerであり、その背景にはLinuxの存在があります。**
:::

本記事では、「**Linuxが好きな人はDockerも好き**」という個人的な印象をもとに、両者の共通点や親和性について考察していきます。

## Linux好きはDocker好き？

エンジニアの世界では、「Linuxが好きな人はDockerも好き」という印象を持つ人が多いかもしれません。実際、私自身もその一人です。

:::note info
**もともとVirtualBoxを使ってローカル開発環境を構築していましたが、1年半前にDockerという技術に出会ってからというもの、ほぼ毎日Dockerに触れています。**
:::

本記事では、その理由を個人的な視点で紐解きながら、なぜLinux好きがDockerにも惹かれるのかを解説していきます。

---

### オープンソース文化という共通点

LinuxもDockerも、オープンソースという自由な文化に根ざした技術です。中身を自由に見られ、自分の手で改善・応用できる点に、強い魅力があります。これは、自分で考え、カスタマイズしていくことが好きな技術者にとって、とても心地よい環境で好きです。

**参考文献**

https://hackernoon.com/lang/ja/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E7%B0%A1%E5%8D%98%E3%81%AA%E6%AD%B4%E5%8F%B2

---

### コマンドラインへの親和性

Linuxを日常的に使っている人は、ターミナル操作に慣れていることが多く、DockerのCLI（コマンドラインインターフェース）にもすぐに適応できます。`docker run`や`docker exec`などの操作も直感的に理解でき、ストレスなく扱えるので好きです

**参考文献**

https://aws.amazon.com/jp/what-is/cli/

---

### システムの仕組みへの関心

Dockerの根幹には、Linuxカーネルの仕組み（名前空間、cgroupsなど）が深く関係しています。プロセスの分離、ネットワーク構成、ファイルシステムのマウントなど、Linuxの基本に関心を持つ人にとって、Dockerは自然に理解が進む技術です。

**参考文献**

https://zenn.dev/akito_ima/articles/c6b87a07193c50

---

### インフラ・DevOpsとの連携

DockerはCI/CDパイプライン、クラウド環境、マイクロサービス設計など、現代的な開発・運用スタイルと非常に相性が良い技術です。Linuxを使い慣れていると、こうした環境にもスムーズに移行でき、Dockerの活用も広がります。

**参考文献**

https://knowledge.sakura.ad.jp/12366/

---

## まとめ

LinuxとDockerの間には、思想・文化・技術的な構造において多くの共通点があります。

:::note info
特にオープンソース文化への親しみ、CLI操作への慣れ、システム内部への関心など、エンジニアとしての志向性が両者の魅力を引き寄せていると思います...!
:::

今後も、これらの技術と向き合いながら、より深く学び続けていきたいと考えています...!
ChatGPTを使用したアプリ開発記【画像投稿機能を実装】


## Firebase Storage 設定
1.	Firebase コンソールにアクセス
2.	プロジェクトを選択
3.	下にスクロールして「Storage」を選択
4.  Blazeプランにアップグレード（ほとんどの人は月額0円）
4.	「はじめる」→ロケーション選択(何でもOK)して有効化
5.	「ルール」タブで一時的に以下のように変更（開発用）:
```jsx
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}
```

## React 側でアップロード処理を追加
```firebase.js
//Firebase Storage（画像や動画などのファイル保存サービス）を使うための関数を読み込んでいます。
import { getStorage} from 'firebase/storage';

//Firebase Storage の機能を有効化し、アプリで使えるように外部へエクスポートしています。
export const storage = getStorage(app); 
```

```App.js
   //アップロード予定の画像ファイル（Fileオブジェクト）を保存するためのステートを定義しています。初期値は null です。
  const [image, setImage] = useState(null);

    //画像投稿
    //Firebase に画像をアップロードしたあとで、その画像の URL をここに代入します。最初は null で初期化。
    let imageUrl = null;
    if (image) {

//Firebase Storage 上に保存する「ファイルの場所」を指定します。
//images/ フォルダに ファイル名_タイムスタンプ 形式で保存するようにして、名前の衝突を防ぎます
      const imageRef = ref(storage, `images/${image.name}_${Date.now()}`);

// 実際に画像ファイルを Firebase Storage にアップロードします。
// uploadBytes() は非同期関数なので await を使います。
      const snapshot = await uploadBytes(imageRef, image);

// アップロードされた画像の「公開URL（ダウンロードURL）」を取得し、それを imageUrl に代入します。 
      imageUrl = await getDownloadURL(snapshot.ref);
    }

    const newPost = {
      text: text,
      time: formattedTime,
      likes: 0,
      user: user?.email,
      
//新しい投稿オブジェクトにこの imageUrl を含めることで、後で <img> タグで表示できるようになります。
      imageUrl,
    };

    setPosts([newPost, ...posts]);
    setText('');
// 投稿後に setText('') でテキストエリアをリセットするのと同じように、setImage(null) でファイルもリセットする
    setImage(null);
  };


  return (     
// ファイル選択用の <input> フィールド。ユーザーが画像を選択すると、setImage() により画像ファイルがステート image に保存されます。
        <input type="file" onChange={(e) => setImage(e.target.files[0])} />

// 投稿一覧で、画像が含まれている投稿だけ <img> を表示します。post.imageUrl があれば画像が表示されます。
            {post.imageUrl && (
              <img src={post.imageUrl} alt="投稿画像" style={{ maxWidth: '100%' }} />
            )}
  );


```
## 操作画面
![画面収録-2025-05-03-9.49.20.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1058366/56e7ac27-d149-4e1b-aa18-eb0aa2972f6a.gif)
dotnet でAPI サーバー開発時の web API と A spire API との違いまとめ

.NET で Web API を作るとき、いつものように `dotnet new webapi` でプロジェクトを作る人が多いと思います。

でも最近、dotnet aspire という新しい選択肢が出てきて、「これって何？」「普通の Web API と何が違うの？」と気になったので調べてみました。

Aspire はマイクロサービスやクラウドを念頭においたもので、そのための機能が用意されているようです。ただ、構成もやることも増えるので、学習コストが高くなります。

従来の Web API プロジェクトと Aspire を使った API 開発を実際に比べてみて、どんなところが違うかをまとめてみました。


# そもそも Aspire とは

dotnet aspire は、.NET 8 から登場した新しいアプリケーションモデルで、マイクロサービスや分散システムを簡単に構築・管理できることを目的としています。
名前の由来は「分散アプリを '目指す（aspire）'」という意味合いです。


# Aspire での API サーバーのプロジェクト作成方法は？

aspire-webapi テンプレートを使って API プロジェクトを作成します。

```powershell:プロジェクト名がMyAspireApiの場合
dotnet new aspire-webapi -n MyAspireApi
```

プロジェクトのディレクトリツリーは次のような感じです。

```:
MyAspireApi/
├── MyAspireApi.sln
├── MyAspireApi.AppHost/         ← 全体構成と依存サービス
├── MyAspireApi.WebApi/          ← 実際のAPIロジック（ASP.NET Core）
└── MyAspireApi.Components/      ← 共有コード（モデル・サービスなど）
```

# Web API と Aspire API との違い

## 概要比較

| 項目 | 通常の Web API | Aspire API  |
| --------- | --------------------------------- | --------------------------------------- |
|コマンド|`dotnet new webapi`|`dotnet new aspire-webapi`|
|  構成 | 単一プロジェクト or 単純な構成 | 複数プロジェクト（AppHost + サービス） |
|  クラウド対応 | 手動で追加（Docker/K8s等） | 初めからクラウドネイティブ前提 |
|  サービス登録 | `builder.Services.AddXxx()` | Aspire の `AppHost` で依存関係を定義 |
|  実行管理 | `dotnet run` 単体 | `dotnet run` で複数サービス一括起動 |
|  Daprなど | 手動導入 | Aspire AppHostから連携しやすい |
|  観測性 | 監視・トレースは手動構築 | OpenTelemetry, Dashboard 付き |
|  主な用途 | 単体API、業務アプリ、社内APIなど | マイクロサービス構成、SaaS、分散システム |

## 開発時の比較

| 比較項目                          | 通常の Web API            | Aspire                                  |
| :---------------------------- | :--------------------- | :-------------------------------------- |
|  **セットアップの簡単さ**             | 非常に簡単：単一プロジェクトで完結      | やや難しい：複数プロジェクトが生成される                    |
|  **構成の理解コスト**               | 低い：APIだけに集中できる         | 中〜高：AppHost, コンポーネント分離の理解が必要            |
| **依存関係の管理**                | DI とサービス登録で完結          | AppHost側で構成し、APIから参照するモデル               |
|  **開発中の確認のしやすさ**            | シンプル：`dotnet run` 一発起動 | Aspireダッシュボードあり、ただし複数起動に注意              |
|  **追加サービスの連携（DB, Redisなど）** | 自分でDockerやパッケージを用意     | Aspire内で `apphost.AddRedis(...)` 等で連携容易 |
|  **制約（自由度）**                | 高い（自由にプロジェクト構成できる）     | やや制限あり（推奨構成に従う必要がある）                    |
|  **学習コスト**                  | 初学者でもすぐに始められる          | .NETの中級者以上向け（AppHostやオーケストレーションの理解が必要）  |
|  **クラウド対応（将来性）**            | Docker/K8s 対応は手動構築     | Aspire内に初めから整備済み、スケール想定向き               |

##  Aspire API 開発の特徴

- AppHost プロジェクトでサービスを束ねて一括管理できる
- 分散トレーシング、ログ収集、メトリクスが初期構成に組み込み済み（OpenTelemetry）
- Redis、PostgreSQL、Zipkinなどを開発時に簡単に使える（dotnet aspire run で起動）
- 複数のAPIやWorkerを統一して起動できる



# まとめ

どちらが優れているというよりも、目的や開発規模に応じて選ぶべき、という感じでしょうか。
まずは従来の構成で始めてみて、サービスの成長に合わせて Aspire を検討という進め方が順当のようです。
【安全確保支援士】デジタル証明書における〜局一覧

# はじめに

デジタル証明書の仕組みを支える各種「〜局」は、それぞれに明確な役割を持っています。本記事では、安全情報確保士試験でも重要となる以下の4つの局について、役割や関係性を整理しながらわかりやすく解説します。



## 1. CA（Certificate Authority：認証局）

**役割：デジタル証明書を発行・管理する中核的な存在**

CAは、公開鍵暗号基盤（PKI）の中で、**デジタル証明書を発行し、その正当性を保証する機関**です。利用者の公開鍵に対して、CAが**電子署名**を付けることで「この鍵はこの人（またはこの組織）のものです」と証明します。

- 公開鍵と所有者情報に電子署名を付けて証明書を発行
- 証明書の更新・失効の管理
- 失効証明書リスト（CRL）の発行も担当

::: note
例えるなら、CAは「デジタルの世界での身分証明書発行機関」です
:::

## 2. RA（Registration Authority：登録局）

**役割：本人確認を行い、CAに証明書発行を指示する**

RAは、直接証明書を発行するわけではありませんが、**利用者の本人確認を行い、証明書の発行をCAに依頼する**役割を担います。

- 利用者の本人確認（身元の確認）
- CAへの証明書発行申請の取り次ぎ
- 登録情報の確認・管理

:::note info
 CAの「窓口担当」のような立ち位置です。
:::


## 3. VA（Validation Authority：証明書有効性検証局）

**役割：証明書が有効かどうかを検証し、回答する**

VAは、利用者からの問い合わせに応じて、**特定のデジタル証明書が現在有効かどうかをチェック**する機関です。証明書の失効状態は重要なセキュリティ情報であり、これをリアルタイムで検証する手段としてOCSP（Online Certificate Status Protocol）などが使われます。

- 証明書の失効状態（有効・無効）を確認
- OCSPやCRLによる応答サービスの提供

::: note
「この証明書、まだ使って大丈夫？」という問いに答えてくれるのがVAです。
:::

## 4. AA（Attribute Authority：属性認証局）

**役割：属性情報に関する証明書（属性証明書）を発行する**

AAは、ユーザーの**属性（所属部署、役職、資格など）を証明する証明書を発行**します。これは身分証明というよりも、「どんな権限を持っているか」を証明するものです。

- 属性情報（例：部長、医師、会員レベル）を証明
- 通常の証明書（身元）とは別に、権限や役割を示す証明書を発行

::: note
「この人は誰？」ではなく、「この人はどんな立場？」を証明します。
:::


## 🔄 各局の役割の違いまとめ

| 略称 | 名称 | 主な役割 |
|------|------|----------|
| CA   | 認証局 | デジタル証明書の発行と署名 |
| RA   | 登録局 | 本人確認・証明書発行申請の窓口 |
| VA   | 証明書有効性検証局 | 証明書の有効性をチェック |
| AA   | 属性認証局 | 属性証明書（役職や権限）の発行 |


## ✅ まとめ

デジタル証明書を取り巻く「〜局」には、それぞれ専門的な役割があり、安全な電子取引を支える要です。安全情報確保士としては、それぞれの局の違いを明確に理解しておくことが重要です。
【公ド読】GitHub Copilot を使用して IDE でコードの提案を取得する

【公式ドキュメントを読もうシリーズ】GitHub Copilot を使用して IDE でコードの提案を取得する

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/using-github-copilot/getting-code-suggestions-in-your-ide-with-github-copilot](https://docs.github.com/ja/copilot/using-github-copilot/getting-code-suggestions-in-your-ide-with-github-copilot)

## 説明

実際の操作方法の説明。

## 所感

ショートカットのコマンド書いてあるので、試してみた。
部分的な提案の受け入れの方法(`Ctrl + c`)でできることを知った。
zsh の Powerlevel10k で、プロンプトにホスト名を追加する

# 契機
複数のホストを何台も ssh で入っていると、どこへログインしているかわからなくなることがある。zsh の Powerlevel10k だと、右側に「ユーザ名@ホスト名」が表示されるが遠いので見難い。
コマンドを入力する左側へ表示させたい。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/c563728d-485f-41b1-93b5-f9d36b619179.png)

# 変更箇所
左側に表示させたいんだけどーー。と思って眺めているとそれっぽいのがあった。
```zsh:.p10k.zsh
  typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
    # =========================[ Line #1 ]=========================
    os_icon                 # os identifier
    dir                     # current directory
    vcs                     # git status
    # =========================[ Line #2 ]=========================
    newline                 # \n
    # prompt_char           # prompt symbol
  )
```

ここにホスト名を追加したらいいじゃぁないですか。host を追加。
```zsh:.p10k.zsh
  typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
    # =========================[ Line #1 ]=========================
    os_icon                 # os identifier
    host                    # hostname 👈 追加
    dir                     # current directory
    vcs                     # git status
    # =========================[ Line #2 ]=========================
    newline                 # \n
    # prompt_char           # prompt symbol
  )
```

`source .zsh` するといい感じ？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/02841a04-bfa1-477d-acd1-14988f836139.png)

色とかアイコンを変更したいなということで `context` の上あたりに設定を追加。
細かい内容は context のところを参照。
```zsh:.p10k.zsh
  ##################################[ host: hostname ]##########################
########
  typeset -g POWERLEVEL9K_HOST_FOREGROUND=123
  typeset -g POWERLEVEL9K_HOST_BACKGROUND=30
  typeset -g POWERLEVEL9K_HOST_TEMPLATE='%m'

  typeset -g POWERLEVEL9K_HOST_VISUAL_IDENTIFIER_EXPANSION='💻'
　### 👇 これの上に追加 ### 👆 追加部分
  ##################################[ context: user@hostname ]##################
################
```

再度 `source .zsh`。うん、良いですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/306041/38953687-15db-4a4f-8bbb-73252dd4776a.png)

完成！
なんか、画像が減色されて色がわかりにくいですねぇ...orz
【中編】Laravel×Docker×EC2 初デプロイで地獄を見た話（構築と詰みポイント編）

前回の準備編を乗り越え、いよいよ本番環境にLaravelをデプロイしていくわけですが、

> これがまた、一筋縄じゃいかない。

今回は、**実際にDockerやLaravelの構成で詰んだポイント**をまとめていきます。

## 🐳 Dockerの罠

### 1. Laravelのログが出ない問題

本番環境でなにも表示されない…と思ったら `storage/logs/laravel.log` が書き込めてないだけ。

```sh
chmod -R 777 storage
chmod -R 777 bootstrap/cache
```

もちろんセキュリティ的には777は微妙だけど、まずは動かすこと優先で。

### 2. LaravelコンテナとDBコンテナの通信ができない

docker-compose.yaml の `networks:` がうまく設定されてなかった。

```yaml
services:
  app:
    networks:
      - laravel-net
  db:
    networks:
      - laravel-net

networks:
  laravel-net:
    driver: bridge
```

→ 共通ネットワークに乗せないと、そもそも通信できない。

### 3. .envのキャッシュが鬼門

ローカルで `php artisan config:cache` しちゃったやつをビルド時にCOPYすると、
**本番の環境変数が反映されない**。

→ `.env`は本番用を別で用意＋キャッシュコマンドは本番で実行すること！

## 🛠 Laravel特有の落とし穴

### 1. APP_URLが違うとCookie破損

ログインできない現象、原因は `APP_URL=http://localhost` のまま本番に突っ込んでたこと。

```dotenv
APP_URL=https://apprentory.click
```

### 2. セッションとCSRFのドメイン一致

HTTPS設定後、CSRFやセッションでコケるようになった。

→ `.env`の `SESSION_DOMAIN` と `SANCTUM_STATEFUL_DOMAINS` をちゃんと設定！

```dotenv
SESSION_DOMAIN=apprentory.click
SANCTUM_STATEFUL_DOMAINS=apprentory.click
```

## 🧠 ハードウェアの壁にも泣かされた

ここまでソフトウェアの話ばかりしてきたけど、実は
**EC2インスタンスのスペック不足**にもめちゃくちゃ悩まされた。

Laravelコンテナがまともに立ち上がらない、MySQLが急に落ちる、CloudWatchに何も出てこない……

> これ、実はメモリ不足が原因でした。

最初は `t2.micro` で始めてたんだけど、
`swap` も設定してない状態で Dockerコンテナ2個はさすがに無理があった。

```sh
# topコマンドで確認すると、常にメモリがギリギリ
```

そこで `t2.small` に変更したところ、
それまでの不安定さが嘘のように解消。

本番環境はケチらず**最低限のリソース確保、大事！**

---

## 😇 今回の学び（中編）

- Dockerネットワーク設計しないと通信できない
- .envはキャッシュしない、分けて管理が鉄則
- APP_URL、セッション周りは本番でちゃんと設定！

→ もう正直めちゃくちゃ疲れたけど、その分LaravelとDockerへの理解は確実に深まった。

次回、いよいよ最終回。**HTTPS化・監視導入・公開までの仕上げ作業**をお届けします！
【公ド読】GitHub Copilot の使用についてのベスト プラクティス

【公式ドキュメントを読もうシリーズ】GitHub Copilot の使用についてのベスト プラクティス

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/using-github-copilot/best-practices-for-using-github-copilot](https://docs.github.com/ja/copilot/using-github-copilot/best-practices-for-using-github-copilot)

## 説明

### Copilot の長所と短所の説明。

下記のことが最適な場合の一部とのこと。
コードの生成しかしたことなかった。
下記を実行できるプロンプト周りも調べよう。

> - テストと繰り返しコードの記述
> - デバッグと構文の修正
> - コードの説明とコメント
> - 正規表現の生成

> - 専門知識やスキルを更新する。 自分自身が責任者であって、Copilot はサービスの強力なツールであることを忘れないでください。

責任はAIではなく、人間にあるので、チェックはしながら使いたいですね。と今のところ思っていますが、ときが経つと考え方も変わるのかもしれないです(2025年5月4日)。

### Copilot コード補完と Copilot Chatの違いの説明。

#### コード補完の最適な目的

> - コード スニペット、変数名、および関数を記述する際の補完
> - 繰り返しコードの生成
> - 自然言語のインライン コメントからのコード生成
> - テスト駆動開発用のテスト生成

テスト駆動開発用のテスト生成をしたことがなかったので、使いたい。便利そう。

#### Copilot Chat の最適な目的

> - コードに関する質問への自然言語での回答
> - コードの大きなセクションを生成し、そのコードを反復処理してニーズを満たす
> - キーワードとスキルを使用して特定のタスクを実行する。 Copilot Chat には、プロンプトの重要なコンテキストを提供し、一般的なタスクをすばやく実行するように設計されたキーワードとスキルが組み込まれています。 さまざまな種類のキーワードとスキルが、さまざまな Copilot Chat プラットフォームで使用できます。 「IDE で GitHub Copilot に質問する」を参照してください。
> - 特定のペルソナとしてタスクを完了する。 たとえば、Copilot Chat に、コードの品質、読みやすさ、効率性について非常に気をつかう C++ のシニア開発者として振舞うように伝え、コードをレビューするように依頼できます。

`特定のペルソナとしてタスクを完了する`とあるが、こういうプロンプトって言葉遊びみたいって正直思ってしまったが、公式で書いているんだし、違いってあるんだろうなあ。どこかで比較したい。

### 適切なプロンプトエンジニアリングの概要の説明。

> - 複雑なタスクを分割する。
> - 要件について具体化する。
> - 入力データ、出力、実装などの例を提供する。
> - 適切なコーディング プラクティスに従う。

抽象的ではなく、具体的なタスクを渡すことで、より価値のある応答をしてくれるんだね。
例を提供するの意識したい。
細かいところは[Copilot Chat のプロンプト エンジニアリング](https://docs.github.com/ja/copilot/using-github-copilot/copilot-chat/prompt-engineering-for-copilot-chat)に書かれているが、追々見ていきます。

### 使用時の注意点。



### 使用時のヒント。

> - Copilot に役立つコンテキストを次のように指定します。
>   - IDE で Copilot を使用している場合は、関連するファイルを開き、無関係なファイルを閉じます。

そうなんだ。影響しちゃうんだね。意識しないと忘れそうだけど、使わないファイルは閉じよう。


## 所感

Tipsだけ読んでても気づかないことが多いので、公式ドキュメント読むの発見多いなと思った。
【公ド読】GitHub Copilot を自分用に設定する

【公式ドキュメントを読もうシリーズ】GitHub Copilot を自分用に設定する

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/setting-up-github-copilot/setting-up-github-copilot-for-yourself](https://docs.github.com/ja/copilot/setting-up-github-copilot/setting-up-github-copilot-for-yourself)

## 説明

自分用の設定周りの記載。

## 所感

Windows Terminalでもできるんだ。
リンク先にショートカットのやり方などあるので、楽しみ。
【公ド読】組織向けの GitHub Copilot の設定

【公式ドキュメントを読もうシリーズ】組織向けの GitHub Copilot の設定

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-organization](https://docs.github.com/ja/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-organization)

## 説明

設定周りの記載。

## 所感

ポリシーやネットワークの設定に関して、書かれている。
プロキシサーバーやファイアウォールの設定もできるんだね。
ABC404回答メモ

# 0.はじめに
　404 Not Foundで有名な404回目のコンテスト。
　全体的に難しい問題が多く、Dは解けずに時間切れ。
　レートは-3の732となりました。
　実力的にここら辺が定位置なのかな・・・。


# 1. A - Not Found
　Aから歯ごたえのある問題。
　英小文字a~zのリストを用意し
　Sの先頭からない文字がないかをチェックしてあったら
　出力して終了としました。

　https://atcoder.jp/contests/abc404/submissions/65424820


# 2.B - Grid Rotation
　考え方は簡単ですが、実装がややこしい問題。
　元の状態ではSとTの差がある個数＝操作数であり
　９０°ずつ図を回転（3回まで）していき
　それぞれの状態で回転回数+差の個数を求め
　最小値＝答えとなることは分かりました。

　あとは図形を回転させる関数cycと
　差をカウントする関数CHKを用意して
　地道にCHKを4回、cycを3回繰り返して
　答えを得ました。

　https://atcoder.jp/contests/abc404/submissions/65439495


# 3.C - Cycle Graph?
　これまたグラフを使ったややこしい（あくまで個人の感想）問題。
　サイクルグラフという概念が初見でしたが
　以下の条件を満たせば、サイクルグラフといえる！とおもう！という前提で実装しました。
　　・すべての頂点が連結されている
　　・すべての頂点において連結されている辺が２つ
　後で解説を見ても考え方はあっていたようでです。

　連結の判断は、よく使っているunion-find関数を使い
　連結されている辺の個数は別途数えました。

　https://atcoder.jp/contests/abc404/submissions/65455938


# 4.D - Goin' to the Zoo
　Nの上限が10ということで、全組み合わせみても大丈夫だなということは気づきました。
　コンテスト中は、勝手に各動物園に必ず2回行くのが
　最も安い方法！と、勝手に決めつけ、あれこれ工夫しましたが
　正当にたどり着けませんでした。
　冷静に考えればそんなこと(各動物園に2回行く)は全くないのですが・・・。

　コンテスト後解説を読んで、行く回数についても全組み合わせに入れることができるのか！
　ということと、productという便利な関数があるのか！という事を知り
　すんなり解けました。
　学びを得ましたが、productについて、ここで使えば行ける！と気づける自信はありません・・・。

　https://atcoder.jp/contests/abc404/submissions/65487230


以上
finallyを使用せずに最後の処理を行う方法

finallyを使用すれば、try/catchどちらの処理を行っていても必ず最後に実行されます。しかし非同期処理中などでfinallyは使用したくないが、同じ処理を行いたい場合もあると思います。そんな時のテクニックをメモ。

方法：1
tryの中で「こんにちは」の条件に当てはまった時、runブロックを使用してreturnします。デメリットはネストが深くなります。
```kotlin
private fun sayGreeting() {
    var message = ""
    run {
        try {
            message = "おはよう！"
            if (true) {
                // 途中で処理を止めて最後の処理を行いたい
                message = "こんにちは🖐️"
                return@run
            }
            message = "こんばんは..."
        } catch (e: Exception) {
            message = ""
        }
    }
    println(message) // こんにちは🖐️
}
```

方法：2
単純に同じ処理を複数書きます。処理が少ない場合はこれでもいかなと。デメリットはif文の数だけ同じ処理が増え冗長になります。下記コードdは「sup」が出力されます。
```kotlin
private fun sayGreeting() {
    var message = ""
    try {
        message = "おはよう！"
        if (false) {
            message = "Hello!"
            println(message)
            return
        }

        if (true) {
            message = "sup"
            println(message) // sup
            return
        }

        if (false) {
            message = "hi!"
            println(message)
            return
        }

        message = "こんばんは..."
    } catch (e: Exception) {
        message = ""
        return
    }
    println(message)
}
```
個人的備忘録：Gitでよく出くわす「dquote>」エラーの対処法をまとめてみました

## はじめに

Gitでコミットメッセージを記述する際に、シェルがコマンドを正しく認識しないトラブルが発生することがあります。

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

本記事では、その原因と対処法について記録します。

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

受講しているITスクールのハッカソンの開発の一環で、Git操作中に `dquote>` が表示されて困ったため、今後同じことで詰まらないよう備忘録としてまとめます。

## 内容

Gitで以下のようにコミットしようとした際：

```bash
 git commit -m "loginのファイルに/api/を追加”
```

メッセージのクオーテーションが全角の「”」だったため、以下のように `dquote>` が表示され、コマンドが完了しなくなってしまいました：

```bash
dquote>
```

これはシェルがクオートの閉じを認識できていないため、まだコマンドが続くと判断している状態です。

### 解決方法

1. `Ctrl + C` を押してコマンド入力を中断
2. 以下のように **半角のダブルクオーテーション**または**シングルクオーテーション**を使用して再実行

```bash
git commit -m "loginのファイルに/api/を追加"
```

または

```bash
git commit -m 'loginのファイルに/api/を追加'
```

## まとめ

* 全角のクオート（”）を使うとコマンドが止まるので注意
* シェル上では必ず **半角のクオーテーション** を使う
* トラブル時は `Ctrl + C` で脱出してからやり直す

ちょっとしたことですが、地味にハマりやすいポイントなので、初心者のうちは意識しておくと安心だと思います...!
個人的備忘録：FastAPI × MySQL のマイグレーション接続エラーを整理してみた

## はじめに

Docker環境で FastAPI + MySQL の開発を行っている際、マイグレーション時にMySQLへの接続エラーが発生したため、その原因と解決方法を備忘録としてまとめます。

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

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

受講しているITスクールのハッカソンの開発の一環で、Docker + Alembic + MySQL を使った開発を行っています。マイグレーションの実行時に `ConnectionRefusedError` が出たため、同じような状況に陥ったときにすぐ解決できるように記事として残します。

## 内容

### 問題点

`.env` ファイルの `DATABASE_URL` が以下のように設定されていた：

```
DATABASE_URL=mysql+pymysql://fastapi_user:fastapi_pass@localhost:3306/fastapi_db
```

この `localhost` はホストOSを指してしまうため、Dockerコンテナ内からはアクセスできません。

### 修正方法

Docker Compose の `db` サービスを利用している場合、ホスト名は `localhost` ではなくサービス名（ここでは `db`）を指定する必要があります。

```
DATABASE_URL=mysql+pymysql://fastapi_user:fastapi_pass@db:3306/fastapi_db
```

### 修正後の流れ

1. `.env` を保存
2. Docker コンテナの再起動

```
docker compose down
docker compose up -d
```

3. マイグレーション実行

```
make makemigration
```

### マイグレーション時の補足エラー

最初、以下のエラーが出ました：

```
FileNotFoundError: No such file or directory: '/app/migrations/versions/xxx_honda.py'
```

これは `migrations/versions/` ディレクトリが存在しなかったためです。

→ ローカルで以下を実行し、ディレクトリを作成：

```
mkdir -p migrations/versions
```

その後再度マイグレーションを行えば正常に `.py` ファイルが生成されます。

## まとめ

Docker上でMySQLに接続する際、`.env` の `localhost` は `db` にする必要がある。また、マイグレーションのディレクトリが存在しないとAlembicはファイル生成に失敗するので、事前に `migrations/versions` を作成しておくことが重要です...！
ABC404振り返り

## はじめに

AtCoder Beginner Contest 404(ABC404)に参加しましたので報告します。

## 今回の概要

- A問題は解いたが、B問題は解けなかった
- C問題以降もダメだったので諦めた
- 成績は1問しか解いていない割に然程悪くない

## A - Not Found

404といえばNot Found。ということで今回唯一のNot Found絡みの問題です。
ゴリ押しで解きましたが、解説でもゴリ押し解法が載っていました。
まあ$O(N^2)$といいつつNの最大値は精々26ですからねえ。

```cpp:A.cpp
#include <bits/stdc++.h>
using namespace std;

int main() {
  string S, T="abcdefghijklmnopqrstuvwxyz";
  cin >> S;
  for (int i = 0; i < (int)T.size(); i++) {
    bool is_found = false;
    for (int j = 0; j < (int)S.size(); j++) {
      if (S[j] == T[i]) is_found = true;
    }
    if (!is_found) {
      cout << T[i] << endl;
      return 0;
    }
  }
  return 0;
}
```

## B - Grid Rotation

B問題は一応、右90度回転する→ドット数を比較するでOKかなと思っていました。
解説を読むと、それほど遠くはなかったようです。

じゃあ何故できなかったかというと、右90度回転の仕方がわからなかったからです。
うーん、資料不足。
実際に回転させるコードを見ると、然程難しくないんですけどね。

## C問題以降

C問題はあーUnion-Findかなあと思って見てました。
解説を見たら、深さ/幅優先検索やUnion-Findなどで解けるとのことでした。
どちらかというと誤回答に注意すべき問題だったようです。

D問題以降は相変わらず問題文も見てません。

## レーティング変動

- パフォーマンス232(147は越えていたので一安心)
- レーティング54→74(+20)

## 今後の課題

基本的に前回から引き続きとなります。

- アルゴ数学本を問題を解きながら読む
- アルゴ式を進める(Python入門は終わりました。次は基礎)
- 高校数学を復習する
- A問題B問題が手早く解けるよう、引き続きAtCoder Daily Trainingに参加する

## その他

A問題の公式解説に『→初心者の方へ』がありました。AtCoderやプログラミングに不慣れな方は読んでおくとよろしいかと存じます。
そう、「こんなんやってられるかー！」と投げる前に。
関西弁で教えてもらおう

# はじめに
プログラミング学習中の[@kat_log](https://twitter.com/kat__log "Twitter")と申します。

ReactのuseStateとuseRefの違いをAIに関西弁で教えてもらうとすんなり入ってきたので共有です😂

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1455073/6289e534-3354-4f4c-8d24-64a67d8eb060.png)

# プロンプト
`UseStateとuseRefの違いは再レンダーするのがステート、しないのがレフですかね？関西弁で教えてくれ！`
（Gemini 2.5 Flash experimentalさんへ）

# 回答
せやせや！その通りやで！

**useState** はな、値がポコっと変わったら、「あ、値変わったんやな！」てReactが気ぃ利かせて**画面もシュッと変え直してくれる（再レンダーしてくれる）** ときに使うもんや。例えば、ボタンを押したら数字が増えて、その増えた数字を画面に出したいとか、そういう場合やな。

ほんで、**useRef** はな、値は覚えときたいねんけど、その値が変わったからって別に**画面までごそごそ変えんでもええねん** 、っていうときに使うもんや。値は持っとくけど、それが変わっても再レンダーはせえへん。

例えば、

- タイマーのIDとか（画面には出さへんけど、タイマーを止めるときにいるやろ？）
- 直前の値とか（今の値と一個前の値を比べたいけど、一個前の値が変わっても画面は変わらんでええやん？）
- 画面上の要素（DOM）を直接触りたいときとか（これも値が変わるって話やないし、画面全体を変え直す必要ないやん？）
こういう、「値は持っときたいけど、その値が理由で画面を再レンダーしたくない」っちゅうときに **useRef** が便利なんや。

せやから、「再レンダーするのがステート、せんのがレフ」っていう理解でバッチリやで！分かりやすい違いやろ？

# 終わり
以上です！😂
個人的備忘録：Git初学者のためのmainブランチトラブル回避術を整理してみた

## はじめに

Git 操作の中でもよく行う「ブランチの切り替え」について、自分用の備忘録としてまとめておきます。

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

受講している IT スクールのハッカソンの開発の一環で、ブランチの管理や切り替えを何度も行う必要がありました。過去に `main` ブランチへの切り替え時に詰まった経験があったため、忘れないようにまとめておきます。

## 内容

### `main` ブランチに切り替える基本のコマンド

```bash
git checkout main
```

### ローカルに `main` ブランチがない場合（リモートから取得して切り替え）

```bash
git fetch origin
git checkout -b main origin/main
```

### `main` ブランチを最新の状態に更新

```bash
git pull origin main
```

### 現在のブランチを確認

```bash
git branch
```

### 作業中の変更がある場合の対処

#### 方法①：変更を一時的に退避（stash）する

```bash
git stash
git pull origin develop  # または main
# 必要なら変更を戻す
git stash pop
```

#### 方法②：変更をコミットしてから `pull`

```bash
git add app/main.py
git commit -m "WIP: ローカル変更を一時コミット"
git pull origin develop  # または main
```

#### 方法③：変更を破棄（注意）

```bash
git checkout -- app/main.py
git pull origin develop  # または main
```

## まとめ

ブランチの切り替えは日常的に行う操作ですが、作業中の変更があるとエラーになることがあります。

変更を残すのか捨てるのかを意識しながら、適切な方法で切り替えるようにしていきたいです...!
【公ド読】GitHub Copilot のプラン

【公式ドキュメントを読もうシリーズ】GitHub Copilot のプラン

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/about-github-copilot/plans-for-github-copilot](https://docs.github.com/ja/copilot/about-github-copilot/plans-for-github-copilot)

## 説明

各プランの比較が書かれている。

## 所感

現時点(2025年5月4日)では、o3はCopilot Pro+、Copilot Enterpriseでのみ使える模様。
Cursorでもo3はリクエストごとの従量課金($0.30 per requestで使えるという記事は見る)([https://apidog.com/jp/blog/openai-o3-o4-mini-api-free-jp/](https://apidog.com/jp/blog/openai-o3-o4-mini-api-free-jp/))で使えるみたい。
現状o3がめっちゃいいという評価を見るので、試してみたい。
【公ド読】GitHub Copilot の機能

【公式ドキュメントを読もうシリーズ】GitHub Copilot の機能

## シリーズ概要
[https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3](https://qiita.com/yasu_programming/items/cec66f9e8d5d571e9ce3)

## URL
[https://docs.github.com/ja/copilot/about-github-copilot/github-copilot-features](https://docs.github.com/ja/copilot/about-github-copilot/github-copilot-features)

## 説明

Copilot コード レビューやってみたいが、現状(2025年5月4日)はFreeプランだとできない。
細かいところは[GitHub Copilot のプラン](https://docs.github.com/ja/copilot/about-github-copilot/plans-for-github-copilot)に記載されている。
一般的なコード変換と同じように、Premiumリクエストを使用してのコードレビューだと思われる。

## 所感

AIによる自動での修正を行うことができるのは、一人レビュワーが増えるみたいで、良さそう。
[走り書き]Selenium + Chrome 136以降で標準プロファイルを読み込めない

# 問題

Chrome ver 136以降をSeleniumから操作しようとするとき、
デフォルトのユーザプロファイルを読み込もうとすると(=いつも使っているサイトのログイン状態等を流用したい)、

```DevTools remote debugging requires a non-default data directory. Specify this using --user-data-dir.```
とエラーが出て、しばらく待った後
```[25112:6836:0504/022112.181:ERROR:google_apis\gcm\engine\registration_request.cc:291] Registration response error message: DEPRECATED_ENDPOINT```
とエラーが出て、session not createdとの例外が投げられ、Chromeが起動できない。

筆者の環境は
```
Win11 + Chrome 136.0.7103.49 (Official Build) （64 ビット） (cohort: Control) 
Selenium 4.32.0
```

# 理由
下記にあるとおり、Chrome ver 136以降では--remote-debugging-port及び--remote-debugging-pipeというSeleniumで使っている機能がデフォルトのデータディレクトリでは封印されたらしく、これが原因と踏んでいます。

https://developer.chrome.com/blog/remote-debugging-port?hl=ja

# 対策
Chrome ver 135以下を使うのは現実的ではないので、やむを得ずSelenium用の別データディレクトリ、プロファイルを作り、そちらからログインするようにしています。

Chrome ver 136以降で常用しているプロファイルを使ってSeleniumを起動する方法があったらご教示ください…ｚ

取り急ぎ。誰か一人でも役に立てば幸いです。
./gradlewとgradleの違い

# はじめに
Android StudioでDokkaを利用しようとした際に、公式通りに`./gradlew dokkaHtml`を利用して生成しようとしていたがうまくいかず、`gradle dokkaHtml`を利用するとうまく生成された。違いはなにかが気になり、調べてみました。

# `./gradlew` と `gradle` の違い

Gradleは、JavaやKotlinなどのプロジェクトで広く使用されているビルドツールです。Gradleを使用する際には、`./gradlew`（Gradle Wrapper）と `gradle`（システムにインストールされたGradle）という2つの方法があります。

## `./gradlew` とは？

`./gradlew` は **Gradle Wrapper** の実行ファイルです。プロジェクトで指定されたGradleバージョンを使用してビルドを実行します。

### 特徴

- プロジェクトに含まれるGradleラッパーを使用
- 指定されたバージョンを自動的にダウンロードして使用
- システムにGradleがインストールされていなくても動作

### ファイル構成

| ファイル名 | 説明 |
|------------|------|
| `gradlew` | Unix系の実行ファイル |
| `gradlew.bat` | Windows用の実行ファイル |
| `gradle/wrapper/gradle-wrapper.properties` | Wrapperの設定ファイル |

## `gradle` とは？

`gradle` は、**システムにインストールされたGradle** を使用してビルドを実行するコマンドです。

### 特徴

- ローカルにインストールされたGradleを使用
- プロジェクトで指定されたバージョンではなく、システムのバージョンを使用
- Gradleを事前にインストールしておく必要がある

## `./gradlew` と `gradle` の違い

| 特徴 | `./gradlew` (Gradle Wrapper) | `gradle` (システムのGradle) |
|------|------------------------------|-----------------------------|
| バージョン管理 | プロジェクトで指定されたバージョン | システムにインストールされたバージョン |
| インストールの必要性 | 不要（自動ダウンロード） | 必要 |
| 環境依存性 | 低い（環境に依存しない） | 高い（環境に依存） |
| CI/CDでの利用 | 推奨される | 非推奨 |
| 初回実行時の動作 | Gradleを自動ダウンロード | 既存のGradleを使用 |

## どちらを使うべきか？

| シーン | 推奨される方法 |
|--------|----------------|
| チーム開発 | `./gradlew` |
| CI/CDパイプライン | `./gradlew` |
| 個人開発（高速ビルド重視） | `gradle` |
| Gradle未インストール環境 | `./gradlew` |
vscodeからリポジトリを作成する方法

#### vscodeからリポジトリを作成する方法はとても簡単です！

1．「ソース管理」から「GitHubに公開」を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/c97d8d46-828a-4cba-96a0-553bf5f7f348.png)

2．リポジトリを「private」か「public」で公開するか選択しましょう。

![スクリーンショット 2025-05-04 015328.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/4807c889-1350-4644-8192-63d04890903e.png)

3．リポジトリに公開するファイルを選択します。
　(問題なければデフォルト通りすべてで良いでしょう)
 
![スクリーンショット 2025-05-04 015352.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/56fda5b4-7f15-4fd2-95c9-1626fc9584cc.png)


4．下記写真のような表示が出ます。

![スクリーンショット 2025-05-04 015415.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/0a444043-b898-4f58-b425-a4441d8524a6.png)


5．正常に発行されたら「GitHub上で開く」を押しましょう。

![スクリーンショット 2025-05-04 015431.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/305292f3-3dac-48d6-939b-01fb0414eac9.png)


これでリポジトリが新しく作成できたことを確認できます！

![スクリーンショット 2025-05-04 015528.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808856/7cd69c73-98f0-4f50-90f1-9e4378d233f3.png)
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️AIによる社会信用スコアのリスク


 
# AIによる社会信用スコアのリスクとは？現場エンジニア視点で深掘り解説

---

### 1. 🧭 はじめに 〜「信用」が数値化される時代の到来〜

最近、**「AIによる社会信用スコア」**というワードを耳にする機会が増えてきました。  
金融ローンの審査、賃貸契約、果ては就職活動まで――  
**AIが個人の「信頼度」を自動スコア化する**仕組みが、一部の国や企業で現実のものとなっています。

一方でこの仕組みには、
- 「透明性の欠如」
- 「バイアスの再生産」
- 「説明責任の曖昧さ」  
など、**現場で開発・運用するエンジニアが無視できない課題**も潜んでいます。

今回は、AI開発者やクラウド運用者の視点で、  
**「社会信用スコア」の仕組みとリスクを、実装例とともに具体的に紐解いて**いきます。

---

### 2. 🧠 社会信用スコアとは？その仕組みと技術的背景

#### 🔍 定義
**社会信用スコア（Social Credit Score）**とは、  
個人または団体の行動履歴や属性データから「信頼性」を数値化する指標です。

#### 🔧 技術的にどう実現される？
一般的には以下のような**MLパイプライン**で構成されます：

```
[データ収集] → [特徴量抽出] → [モデルトレーニング] → [スコア推定]
```

#### 🎯 利用されるデータの一例
| データカテゴリ | 具体例 |
|----------------|--------|
| 経済履歴       | クレジットカード履歴、支払い遅延履歴 |
| 行動履歴       | ソーシャルメディア投稿、位置情報 |
| 人間関係       | SNSのつながり、所属団体             |
| 評判情報       | 顧客レビュー、通報履歴               |

> ⚠️ これらのデータの多くは**個人の同意なく収集される可能性**があり、倫理的懸念の一因となっています。

---

### 3. 💻 簡易スコアリングモデルの実装例（Python + Scikit-learn）

以下は、匿名化されたデモデータを用いた信用スコア推定のサンプルコードです：

```python
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
import pandas as pd

# デモデータの読み込み（仮の特徴量）
data = pd.read_csv('demo_social_credit.csv')
X = data[['payment_delay_days', 'num_social_flags', 'income_level']]
y = data['is_trustworthy']

# 学習用とテスト用に分割
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)

# モデル構築
model = RandomForestClassifier()
model.fit(X_train, y_train)

# 予測と評価
y_pred = model.predict(X_test)
print(classification_report(y_test, y_pred))
```

このモデルは非常にシンプルですが、  
**「信用スコアリングは一見簡単そうに見えて、実は極めて危うい判断を含んでいる」**ことを体感できます。

---

### 4. 🧩 実務での落とし穴と回避策

#### ❗ よくある問題
| 問題例 | 解説 | 回避策 |
|--------|------|--------|
| バイアスの混入 | 過去の差別的判断が学習データに反映 | 特徴量の選定に倫理的レビューを導入 |
| 説明不可能な予測 | ブラックボックスな判断根拠 | SHAP・LIME等の説明性フレームワーク導入 |
| GDPR等の法的リスク | 個人情報取り扱いで訴訟リスク | 記録と同意の管理をクラウドで実装 |

#### 💡 実務Tips
- モデル評価には**公平性指標（fairness metrics）**も導入（例：Disparate Impact）
- 収集データの**「最小限性」**を徹底（データ・ミニマリズム）
- 社内で**AI倫理レビュー体制**を整備（社内委員会など）

---

### 5. 🔭 さらに応用するには？信用スコア×自律エージェントの可能性

信用スコアは、以下の技術と組み合わせることで新たなユースケースを生み出す可能性もあります：

| 技術 | 応用例 |
|------|--------|
| 自律型エージェント (Agentic AI) | 信用スコアに応じて商談や契約の自動制御 |
| ブロックチェーン | スコア履歴のトレーサビリティ保証 |
| Federated Learning | 個人情報を保持したままのスコア学習 |

> ✅ ただし、応用が進むほど**設計時点での倫理配慮**がますます重要になります。

---

### 6. 🧾 まとめ 〜AIは「誰かの評価者」になっていいのか？〜

| 観点 | ポイント |
|------|----------|
| メリット | リスク評価の自動化・信用の可視化 |
| デメリット | プライバシー侵害・バイアス強化・ブラックボックス性 |
| 今後の展望 | 高精度かつ説明可能な信用評価技術への進化、国際的な規制整備 |

社会信用スコアは便利でありながら、極めて慎重に扱うべき技術です。  
**我々エンジニアは、技術の中立性の名のもとに「倫理」を置き去りにしていないか？**  
ぜひ、コードを書く手と同時に、心の中でもこの問いを持ち続けてください。

---

### 🖼️ おまけ：図解でざっくり理解！

1. 社会信用スコアの基本構成  
2. AIスコアの判断例（ツールによる可視化）  
3. バイアスの例：性別・年齢によるスコア差  
4. SHAPによる説明例  
5. 倫理的リスクのマトリクス図  
6. GDPRとの関係図  
7. 自律型エージェントと信用スコアの連携フロー

※ 必要であれば画像を生成します。お申し付けください！
４＊４のスライドパズルをJavaScriptで少しずつ自動解答


# ４＊４のパズルをAIに解いてもらうけど、時間かかるようなら一旦良さそう感じに動かして、改めて考えてもらうようにしてみた。

## 背景
前回作った４＊４の正式名称良く分からないパズルの自動解答機能ですが、ひどい状態の場合、1日待っても帰ってこない。
それじゃあ実用性に欠けるので、最短経路じゃなくても良いから現実的な時間でゴールしよう、という趣旨で機能追加してみた。
ついでに、毎回ひどい、かつ同じ状態に直ぐにセットできるようにボタンも追加してみた。

---

# デモ
v405_async_BDBFS_moveCloserを追加

https://kubo-4ka.github.io/slide-puzzle-size-4/

# ソース

https://github.com/kubo-4ka/slide-puzzle-size-4/

# 前回記事

https://qiita.com/kubo4ka/items/980681d1abcd982de988

https://qiita.com/kubo4ka/items/8e68d9c6c76fef03958e

https://qiita.com/kubo4ka/items/3f38a5fbf8e9755d54d5

---

```mermaid
flowchart TD
    help_click["HELPボタン押下"] --> auto_solve["autoSolve() 実行"]
    auto_solve --> solve_bidir["solvePuzzleBidirectional()"]
    solve_bidir -->|成功| build_path["buildSolutionPath()"]
    build_path --> save_solution["解の保存 solvingSolution[]"]
    save_solution --> replay_step["setInterval,movedTile により1手ずつ再生"]
    solve_bidir -->|上限超過| move_closer["moveCloserState()"]
    move_closer --> step_forward["状態を少し進める"]
    step_forward --> restart_auto["autoSolve() 再実行（setTimeout）"] --> auto_solve

```

| 関数名 | 概要 |
|---|---|
| `helpBtn.addEventListener`| HELPボタン押下時の起点 |
| `autoSolve()` | 探索＋解の再生を行うメイン処理 |
| `solvePuzzleBidirectional()` | 双方向BFS探索ロジック |
| `buildSolutionPath()`| 探索結果からステップを構築 |
| `moveCloserState()`| 探索失敗時にゴールへ近づく |
| `setInterval(),movedTile` | 解を順次再生する繰り返し処理 |

---

## 注意、諦めた点
- スタート側、ゴール側の処理は共通化できそうだけど一旦動いているのでよし
- メモリを数百MB使う。再帰実行してたらブラウザが停止したりクラッシュしたりしたのでsetTimeoutに変更

---


## アルゴリズムの概要

探索とは、ある状態（start）から目的状態（goal）までの**状態遷移のパス（手順）** を見つける処理です。  
このアプリでは：

- **状態**：スライドパズルのタイル配置（1〜15 と null）
- **遷移**：上下左右への合法なタイル移動

---

## 双方向幅優先探索（Bidirectional BFS）とは？

### 通常の幅優先探索（BFS）

- スタートから幅広に探索し、最短経路を見つける
- 計算量：`O(b^d)`（b = 分岐数, d = 深さ）

### 双方向幅優先探索

- スタートとゴールの両側から同時に探索
- 中央で「出会う」ことを目指す
- 計算量：`O(b^{d/2} + b^{d/2})` → 事実上 `O(b^{d/2})`

---

## 実装フロー（探索ループ）

1. `startFrontier` （キュー）に開始状態を入れる
2. `goalFrontier` にゴール状態を入れる
3. `startVisited`, `goalVisited` に訪問状態を記録
4. whileループで両方から1手ずつ進める（幅優先）
5. stateToString() により文字列化し、Map で重複チェック
6. trialNodes を数えて上限になれば moveCloserState() へ
7. 交差したら `buildSolutionPath()` で経路を合成
8. 結果は `solvingSolution[]` に保存され、UIで順に再生される

```
while (startFrontier.length > 0 && goalFrontier.length > 0) {
    // スタート側から1手進める（getNeighbors）
    //  → 新しい状態を startVisited に追加
    //  → その状態が goalVisited に存在すれば交差！

    // 同様にゴール側からも1手進める（getReverseNeighbors）
    //  → 交差チェック
}
```
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️顔認証AIとプライバシーの対立


## 1. はじめに：便利の裏にある「違和感」

「駅の改札を顔パスで通れる！」「出退勤も顔認証でOK！」  
そんな便利な未来がすぐそこにある一方で、次のような声も増えています：

> 「自分の顔、どこでどう使われてるか分からないのが怖い」  
> 「知らないうちに監視されている感覚がある」  

このように、**顔認証AI**はセキュリティ強化や利便性向上に貢献する一方で、**プライバシー侵害や倫理的懸念**という課題も抱えています。

本記事では、実際の開発・運用現場での知見をもとに、**顔認証AIにおけるプライバシーとのバランスの取り方**を、具体的なコード・設計・対策例とともに分かりやすく解説します。

---

## 2. 顔認証AIとは？技術概要と用途の広がり

顔認証AIは主に以下のステップで構成されます：

1. **顔の検出**（Face Detection）
2. **顔の特徴抽出**（Face Embedding / Feature Vector）
3. **特徴ベクトル同士の比較**（Similarity Measure）

代表的なライブラリやAPI：
- OpenCV + Dlib
- FaceNet / ArcFace（埋め込みモデル）
- AWS Rekognition / Azure Face API などクラウドAPI

### 🔍 用途の一例
- 勤怠管理、入退室認証（オフィス、学校）
- 顧客分析（小売・エンタメ）
- セキュリティ（空港、スタジアム）

---

## 3. 実装例：Pythonで簡易顔認証システムを構築してみる

ここでは、**Python + face_recognition** ライブラリを使って、基本的な顔認証の流れを確認します。

### 📦 必要なライブラリ
```bash
pip install face_recognition opencv-python
```

### 🧪 コード例：指定フォルダ内の顔と一致するか確認
```python
import face_recognition
import cv2
import os

# 登録済みユーザーの顔画像を読み込む
known_image = face_recognition.load_image_file("known_users/alice.jpg")
known_encoding = face_recognition.face_encodings(known_image)[0]

# 入力画像を読み込む
input_image = face_recognition.load_image_file("camera_capture.jpg")
input_encodings = face_recognition.face_encodings(input_image)

# 顔が検出されたか確認
if input_encodings:
    result = face_recognition.compare_faces([known_encoding], input_encodings[0])
    print("一致しました！" if result[0] else "一致しません。")
else:
    print("顔が検出されませんでした。")
```

> ✅ **ポイント**：このコードはローカルで完結し、クラウドに画像を送信しない構成です。プライバシーを意識した設計の第一歩になります。

---

## 4. 現場での知見：よくある落とし穴と設計の工夫

### ❌ よくある課題

| 問題 | 説明 |
|------|------|
| **ユーザー同意が不十分** | 利用者が知らない間に顔データが収集・保存されている |
| **保存形式が危険** | 顔画像をそのまま保存し、情報漏洩リスクが高まる |
| **用途外利用** | 顔認証目的で集めた画像をマーケティングに使うなどの転用 |

### ✅ 対策と実装のヒント

| 対策 | 実装例 |
|------|--------|
| **明示的な同意取得** | UIで「顔認証に同意する」チェック必須にする |
| **特徴量のみ保存** | `face_recognition.face_encodings()`のベクトルのみ保存し、画像は即時破棄 |
| **用途制限のログ** | APIアクセスごとに用途ID・利用目的を記録して監査可能に |

---

## 5. 応用：プライバシーに配慮したアーキテクチャ設計

### 🌐 ハイブリッド設計例

```plaintext
[エッジ端末（ラズパイなど）]
 └→ 顔検出と特徴量抽出
     └→ 特徴量のみ暗号化して送信
         └→ [クラウド上の照合サーバー]
```

- 入力画像はローカル処理 → クラウドには送信しない  
- 特徴量はAES暗号化してネット越しに送信  
- サーバーでは本人照合のみを行い、画像は保持しない

> 💡 **実践Tip**：AWS Lambda + S3 + KMS などを使うことで、低コスト・高セキュリティな構成も可能です。

---

## 6. おわりに：技術と倫理は両輪で進む

### ✅ 顔認証AIのメリット
- 非接触・迅速な認証
- セキュリティ強化
- オペレーションの自動化

### ⚠️ 顔認証AIのリスク
- プライバシー侵害
- 同意取得の困難さ
- 差別・バイアスの再生産（顔データの偏り）

---

### 🎯 まとめ

顔認証AIは、便利さと引き換えに非常にセンシティブな情報を扱います。  
だからこそ、エンジニアが**「ただ動けばいい」ではなく、「どう使われるか」を設計する責任**を持つことが求められています。

最後にこの言葉を共有したいと思います：

> **「技術は中立であっても、使い方は常に倫理的な選択だ」**

---

### 📘 参考資料
- [face_recognition公式GitHub](https://github.com/ageitgey/face_recognition)
- [プライバシー影響評価（PIA）とは？](https://www.ppc.go.jp/files/pdf/pia-gl.pdf)
- [AWS Rekognitionとプライバシーに関するベストプラクティス](https://docs.aws.amazon.com/rekognition/latest/dg/data-privacy.html)

---

### 📊 イメージ図の提案（図解として含めると効果的です）
1. 顔認証処理の流れ図（検出 → 特徴抽出 → 照合）
2. 顔ベクトルの比較イメージ
3. ユーザー同意UIのモック
4. ローカル処理とクラウド連携の構成図
5. ベストプラクティス一覧表
6. 顔画像と特徴量の違い（画像例 + ベクトル値）
7. PIA（Privacy Impact Assessment）導入フロー図
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️AI恋愛アプリの倫理的問題



## 🧩 1. はじめに：AIが恋愛を「最適化」していいのか？

最近、AIを搭載した**恋愛マッチングアプリ**が急増しています。プロフィール分析から、チャットの自動生成、さらには「理想の相手」まで推薦するシステム——これは一見、便利で革新的なように思えます。

しかし、ここで疑問が湧きます。

> 🧠「恋愛をAIで最適化する」ことは、果たして倫理的に許されるのでしょうか？

本記事では、AI恋愛アプリに潜む**倫理的リスク**を技術者視点から掘り下げ、**実際のアルゴリズム構造と設計上の注意点**をコード付きで解説していきます。

---

## 🧠 2. AI恋愛アプリの概要と使われている技術

一般的なAI恋愛アプリには以下のような技術が使われています：

| 機能                 | 使用技術                                |
|----------------------|-----------------------------------------|
| プロファイル推薦      | Embedding (Word2Vec, BERT) + 類似度計算     |
| 性格マッチング        | パーソナリティ推定 (Big Five分析 + SVM)     |
| チャット自動生成      | LLM (GPT, Claudeなど) + Prompt Engineering |
| 表示順の最適化        | CTR最適化（Banditアルゴリズム）             |

📝 **図1：AIマッチングシステムのアーキテクチャ**
（図解挿入予定：ユーザーデータ → 特徴抽出 → モデル推論 → 推薦エンジン）

---

## 🔍 3. 実装例：AIマッチングスコア算出の仕組み

ここでは、2人のユーザー間のマッチングスコアを計算する簡易モデルをPythonで実装してみます。

### 🔧 モデル例：ユーザープロファイルのベクトル類似度

```python
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

# ユーザープロファイル（年齢、興味、性格スコアなどを数値化）
user_A = np.array([[0.7, 0.2, 0.9, 0.1]])  # 例: アート好きの内向型
user_B = np.array([[0.6, 0.3, 0.85, 0.15]])  # 例: アートと音楽好きの内向型

# コサイン類似度を使ってマッチングスコアを算出
score = cosine_similarity(user_A, user_B)

print(f"マッチングスコア: {score[0][0]:.2f}")
```

🧪 実際のサービスでは、さらに年齢差、距離、行動ログなどの重み付けを加えた**複合スコアリング**が使われます。

---

## 🚨 4. 技術者が注意すべき倫理的リスクと現場のTips

### ❗ よくある倫理的リスク

| リスク                     | 説明                                                                 |
|----------------------------|----------------------------------------------------------------------|
| バイアスの強化              | 学習データに偏りがあると、特定の人種・性別を優先する推薦結果に       |
| ユーザー依存性の促進        | Dopamine最適化による「中毒性」設計が倫理的問題を生む                   |
| フェイクプロフィールの温床   | LLMで生成された架空の人物像が増加する恐れ                             |
| 無意識なプライバシー侵害     | 性格や感情を過度に推測することで「監視されている」と感じるユーザーも |

### 🛠 実務上のヒント

- **公平性チェック**には [`Fairlearn`](https://fairlearn.org/) や [`Aequitas`](https://github.com/dssg/aequitas) を導入する  
- **Explainable AI (XAI)**を導入して、推薦理由の透明化  
- **人格の過剰推定**はNG → LLMは「補助」として設計  
- **監査ログ**を取り、意思決定の根拠を記録する文化を社内に浸透させる

📝 **図2：公平性チェックの実装例（Fairlearn）**
（コードやスクリーンショット例を挿入）

---

## 🚀 5. 応用展開：「倫理対応済AI推薦API」の構築

実際の現場では、以下のようなマイクロサービス構成を採ることで倫理的ガバナンスを担保できます：

- **Input Filter API**：センシティブなプロファイル情報を正規化・匿名化
- **Recommendation API**：XAIベースの推薦エンジン
- **Bias Auditing Worker**：定期的に結果をバイアスチェック
- **User Feedback Loop**：説明とフィードバック機能

🧱 **図3：倫理対応型AIマッチングシステムの構成図**
（図解：API構成、ログ監査、フィードバック機構を含む）

---

## 🧭 6. まとめ：技術の力 × 倫理のバランスが未来を作る

### ✅ メリット
- ユーザーに合った出会いを創出できる
- コミュニケーションのハードルを下げる

### ❌ 課題・リスク
- 個人の内面を過度に予測する危険性
- バイアス・透明性の欠如が信頼を損なう

---

AIが人の感情や恋愛に関わる領域に進出するほど、**技術者としての倫理観**が問われます。  
設計・実装の段階からリスクを意識し、**「便利さ」の裏にある責任**を忘れないことが求められています。

---

ご希望があれば、図解（構成図、モデル概念図など）やスライド形式でも提供可能です。  
このテーマについて深掘りしたい部分はありますか？
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️大規模AIモデルと環境負荷の倫理問題




## 1. はじめに：AI開発は地球に優しいのか？

ChatGPTやGeminiなど、私たちが日常で使っている**大規模AIモデル（LLM）**。その便利さの裏で、**環境に与える影響**について考えたことはありますか？

実は、GPT-3のトレーニングには推定で **約550トンのCO₂** が排出されたという報告もあり、これは車で地球を数十周するのに相当します。  
本記事では、このようなAIモデルが環境に与える影響と、開発者としてどう向き合えば良いのかを**実例・コード・実践知識**を交えて解説します。

---

## 2. テクノロジー概要：なぜ大規模AIは環境に負荷をかけるのか？

### 🧠 LLM（Large Language Model）の構造

LLMは数百億〜数兆パラメータを持ち、トレーニングには数週間〜数ヶ月に渡るGPU/TPUの稼働が必要です。  
これに伴い、**膨大な電力**と**冷却コスト**がかかります。

### 🔋 消費エネルギーの主な要因

| フェーズ | 内容 | 代表的な負荷 |
|----------|------|---------------|
| 学習     | 数千万〜億単位のテキストを反復処理 | 電力 + GPU稼働時間 |
| 推論     | ユーザーへのレスポンス生成 | リアルタイムGPU利用 |
| デプロイ | クラウド上にLLMを常時稼働 | 常時高負荷なインスタンス |

<div align="center">
  <img src="https://example.com/llm-carbon-footprint-diagram.png" alt="LLM Carbon Footprint" width="70%"/>
  <p>図1：LLM開発のフェーズごとのエネルギー消費</p>
</div>

---

## 3. 実践例：エネルギー効率を意識したLLM推論環境の構築

今回は、**Hugging Face Transformers**を用いて、**Efficientなモデルをローカルまたはオンプレ環境**で稼働させる簡易例を紹介します。

### 🌿 省エネモデルの選定：DistilBERTを使う

```bash
pip install transformers torch
```

```python
from transformers import pipeline

# 軽量モデルを選択
classifier = pipeline("sentiment-analysis", model="distilbert-base-uncased-finetuned-sst-2-english")

result = classifier("This is a very efficient AI model!")
print(result)
```

> ✅ DistilBERTはBERTの約40%軽量化バージョンで、精度を維持しつつ学習・推論の電力を削減できます。

### ⚙️ ONNXによる推論高速化と消費電力削減

ONNXに変換することで、さらに軽量な推論環境が可能です。

```bash
pip install onnxruntime
```

```python
import onnxruntime as ort
import numpy as np

# ONNXモデルでの推論実行
session = ort.InferenceSession("model.onnx")
inputs = {"input_ids": np.array([[101, 2023, 2003, 1037, 2200, 3835, 102]])}
outputs = session.run(None, inputs)
```

---

## 4. 実務Tips：エンジニアができる環境配慮とは？

### ✅ 小さく始める：フルスケールでのトレーニングは避け、まず小規模で試す  
### ✅ モデルの共有：社内で共通モデルを持つことで再学習コストを削減  
### ✅ クラウドのリージョン選択：再生可能エネルギー利用の多い地域を優先（例：北欧リージョン）  
### ✅ モニタリング：GPU使用率・消費電力の可視化で無駄を排除

<div align="center">
  <img src="https://example.com/carbon-aware-cloud.png" alt="Carbon Aware Cloud Strategy" width="70%"/>
  <p>図2：リージョンごとの電力由来比較（例）</p>
</div>

---

## 5. 応用と展望：グリーンAIという選択肢

- **Green AI** という考え方では、**精度至上主義**から脱却し、**効率・持続可能性を重視**します。
- 例：Stanfordの**Energy-Efficient MLベンチマーク**、Metaの**Open Source Tiny Models** など

<div align="center">
  <img src="https://example.com/green-ai-tradeoff.png" alt="Green AI Trade-off" width="65%"/>
  <p>図3：Green AIと従来AIのバランス感覚</p>
</div>

---

## 6. まとめ

| 項目 | 内容 |
|------|------|
| ✅ メリット | 環境配慮、コスト削減、持続可能性 |
| ❌ デメリット | モデル精度・表現力の制限、選択肢の狭さ |
| 💡 今後の展望 | 小型モデルと効率的アルゴリズムの普及、再生可能電力クラウドの活用 |

大規模AIの時代だからこそ、開発者一人ひとりが**倫理と環境意識**を持つことが求められています。  
「できるからやる」ではなく、「**どう作るか**」が試される時代へ——

---

## 🔖 用語解説（初心者向け）

| 用語 | 意味 |
|------|------|
| LLM（大規模言語モデル） | 膨大なパラメータを持つ自然言語処理モデル（例：GPT、PaLM） |
| 推論（Inference） | モデルが入力に対して出力を生成する処理 |
| DistilBERT | BERTを簡略化・高速化した軽量モデル |
| ONNX | 異なるフレームワーク間でモデルを互換させるための中間表現 |
| Green AI | 環境負荷を意識し、効率的にAIを開発・運用するアプローチ |
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️「ブラックボックスAI」と透明性の問題




## 1. 🧩はじめに：なぜ「AIの透明性」が重要なのか？

最近、AIが意思決定プロセスに使われる場面が急増しています。採用判断、ローン審査、医療診断など、社会的なインパクトが大きい分野では特に顕著です。しかし、**その意思決定の根拠が「見えない」「説明できない」問題**、いわゆる「ブラックボックス問題」が深刻化しています。

本記事では、この**ブラックボックスAIの透明性リスク**について、技術的観点と実務的な視点から分かりやすく解説します。さらに、**透明性を向上させる実践的なアプローチ（例：SHAPによる可視化）**をコード付きで紹介し、実務に応用できるヒントも提供します。

---

## 2. 🔍ブラックボックスAIとは？概要と課題

### 💡ブラックボックスAIの定義

ブラックボックスAIとは、**人間にとってその処理過程が理解しにくいAIモデル**を指します。代表的な例は、深層学習（Deep Learning）や複雑な勾配ブースティングモデル（XGBoostなど）です。

- 入力 → モデル → 出力
- しかし、「なぜその出力になったか」は分からない

### 🧱なぜ問題か？

| リスクカテゴリ | 具体例 |
|----------------|--------|
| 倫理的リスク | 偏った学習データにより差別的判断がなされる |
| 法的リスク | 説明責任（Accountability）が問われる状況に対応できない |
| 運用上のリスク | 異常な出力が出た際のトラブルシューティングが困難 |

---

## 3. 🧪SHAPによるAIの説明性向上：実例とコード付き解説

ここでは、回帰タスクにおいて**SHAP（SHapley Additive exPlanations）**を使って、ブラックボックスモデル（XGBoost）の判断根拠を可視化する方法を紹介します。

### 📦必要なライブラリ

```bash
pip install shap xgboost scikit-learn matplotlib
```

### 🧠データセットと学習（California Housing Dataset）

```python
from sklearn.datasets import fetch_california_housing
from xgboost import XGBRegressor
from sklearn.model_selection import train_test_split

X, y = fetch_california_housing(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)

model = XGBRegressor()
model.fit(X_train, y_train)
```

### 📈SHAPを使った解釈

```python
import shap
import matplotlib.pyplot as plt

explainer = shap.Explainer(model)
shap_values = explainer(X_test)

# 要因の大きい順に視覚化
shap.summary_plot(shap_values, X_test, plot_type="bar")
```

🖼️**図解1**：SHAP summary bar plot  
→ どの特徴量が予測にどれだけ影響を与えたかを視覚的に把握できます。

---

## 4. 🛠️現場で役立つTips & よくある落とし穴

### ✅実務での活用Tips

- モデルのレビュー時には、**説明性ツールを使ってフィードバックループを作成**
- SHAPは**インスタンス単位の解釈**が可能 → エッジケースの分析に最適
- ビジネス部門への説明時には**Force plotやwaterfall plot**を活用すると効果的

🖼️**図解2**：SHAP force plot（個別インスタンスの説明）

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

| 落とし穴 | 解説 |
|----------|------|
| SHAP値がすべて真実と思い込む | SHAPも推定であることを意識し、過信しない |
| データの前処理とSHAP対象がズレる | モデルに渡したデータとSHAPの入力を一致させること |
| 計算コストが高くなる | 特にTreeExplainer以外は大規模データでの利用に注意 |

---

## 5. 🚀さらに一歩進んだ活用：監査ログや透明性ダッシュボードの構築

### 📊ダッシュボードでAIの「説明履歴」を管理

実務では、透明性のあるAI運用には**予測履歴＋説明履歴のログ設計**が欠かせません。

- 例：予測時にSHAP値を計算し、PostgreSQLやBigQueryなどに保存
- DashやStreamlitなどで可視化 → 社内透明性の向上

🖼️**図解3**：Streamlitで作るSHAP可視化ダッシュボードの例

---

## 6. 🧭まとめ：ブラックボックスAIへの対応戦略

| 項目 | 内容 |
|------|------|
| ✅メリット | 高精度、複雑なパターンの学習が可能 |
| ❌デメリット | 説明困難、運用リスクが高い |
| 🎯対策 | SHAPやLIMEによる可視化、説明責任を担保する設計 |

AIがますます社会に溶け込む中で、「正確なだけでは足りない」時代が到来しています。AIの透明性を確保することは、単なるオプションではなく、**社会実装の前提条件**です。

---

## 📚参考リンク

- [SHAP公式GitHub](https://github.com/slundberg/shap)
- [xAI（説明可能なAI）に関する欧州AI規制案の概要](https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence)
- [StreamlitでSHAPを可視化する方法](https://docs.streamlit.io)
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️医療分野におけるAI誤診リスク



## 1. はじめに：命を預けるAI、その信頼性は？

近年、医療分野におけるAI活用が急速に進んでいます。画像診断や疾患予測、問診支援など、AIの力で医師の業務効率化が図られる一方で、「AIによる誤診」という重大なリスクも浮上しています。もしAIが悪性腫瘍を見落としたら？誤った診断結果で治療が遅れたら？この記事では、医療AIが抱える誤診リスクの仕組みと、それに対する実践的な対策をエンジニア目線で深掘りしていきます。

---

## 2. 医療AIの基本構造と誤診が起きる仕組み

### 2.1 医療AIの典型的なワークフロー

```mermaid
graph LR
A[医療画像/問診データ] --> B[前処理]
B --> C[モデルによる推論]
C --> D[医師によるレビュー]
D --> E[診断・治療]
```

このように、AIは医療現場の一部として推論を提供しますが、「前処理の精度」や「モデルの訓練データの偏り」が大きく影響を与えます。

### 2.2 誤診の原因
- **バイアスのある学習データ**：特定年齢・人種ばかりのデータで学習している
- **アノテーションの質**：医師によるタグ付けのミスや曖昧さ
- **ノイズの多い入力**：画像がブレていたり、低解像度だったり
- **モデルの過学習**：特定パターンに過度に依存し、汎化性能が低下

---

## 3. 実装例：画像診断AIモデルの簡易プロトタイプ

ここでは、皮膚疾患の分類を行う簡易CNNモデルを例にとって誤診リスクの検証方法を示します。

### 3.1 データセット：ISIC 2018 (皮膚病変の画像データ)

```python
import tensorflow as tf
from tensorflow.keras import layers, models

model = models.Sequential([
    layers.Conv2D(32, (3, 3), activation='relu', input_shape=(128, 128, 3)),
    layers.MaxPooling2D(2, 2),
    layers.Conv2D(64, (3, 3), activation='relu'),
    layers.MaxPooling2D(2, 2),
    layers.Flatten(),
    layers.Dense(64, activation='relu'),
    layers.Dense(3, activation='softmax')  # 良性、悪性、不明
])
model.compile(optimizer='adam', loss='categorical_crossentropy', metrics=['accuracy'])
```

### 3.2 誤診の例：悪性を良性と判定したケース

- 画像に影が入り、特徴が見えづらくなる
- データ拡張不足により、類似パターンにしか反応しない

```python
# モデルの解釈を試みる（Grad-CAM等）
# => 病変とは関係ない背景に注目していることが判明
```

---

## 4. 現場で使えるTipsと落とし穴

### ✅ 現場Tips
- **医師と連携してアノテーション精度を上げる**
- **Grad-CAMやSHAPでAIの判断根拠を確認する**
- **推論後も医師の確認プロセスを絶対に外さない**
- **定期的にデータを再学習・評価し直す**

### ⚠️ よくある落とし穴
- AIが「正しい」と思い込む（ヒューマン・オートメーション・バイアス）
- 少数派クラスの識別率が極端に低くても気づかない
- バージョンアップ時に説明責任を欠く（モデル変更履歴管理の不備）

---

## 5. 応用と今後の展望：連携と規範整備へ

- **フェデレーテッドラーニング**で病院間のデータ共有とプライバシー保護を両立
- **医療AI向けISO/IEC規格**や**ガイドライン**の整備が進行中
- 将来的には、**医療専門AI監査官**のような職種も登場するかも？

---

## 6. おわりに：AIはあくまで「補助」、最後に判断するのは人間

医療AIは可能性に満ちた技術ですが、誤診リスクがゼロになることはありません。そのリスクを最小限に抑えるためには、技術的な工夫と同時に、人間中心の運用と倫理的配慮が不可欠です。エンジニアとして、現場の責任と信頼に応えるシステム設計を心がけたいものです。

---

### 🧠 用語解説
- **Grad-CAM**：画像分類モデルの注目領域を可視化する手法
- **フェデレーテッドラーニング**：分散データを共有せずに学習できる仕組み
- **SHAP**：モデル予測に対する特徴量の寄与を示すライブラリ