OmniAICreator/Qiita-1.07M huggingface dataset:
シャドーAIと情報漏洩：あなたの会社は本当に安全か？


# 🕵️‍♂️ **「見えない脅威、シャドーAI：データ漏洩とセキュリティの新たな盲点」**

## はじめに

生成AIや大規模言語モデル（LLM）の登場によって、企業内でのAI活用は爆発的に増加しました。しかし、その影で密かに広がっているのが「**シャドーAI（Shadow AI）**」です。

これは、**公式に承認されていないAIツールやサービスを従業員が業務で使用すること**を指し、利便性の裏で大きなリスクを孕んでいます。特にデータ漏洩やセキュリティの観点から、私たち技術者・管理者はもはや看過できない存在となっています。

---

## 1️⃣ シャドーAIとは？なぜ起きるのか？

「シャドーIT（無許可IT機器やサービスの使用）」のAI版とも言えるこの現象は、以下のような背景から発生します：

- 社内ツールの使いにくさや制限
- ChatGPTなどの生成AIの圧倒的な利便性
- 個人レベルでの自動化・効率化欲求
- ITガバナンスや社内ポリシーの認識不足

### 📌 実例：  
ある企業では、マーケティング部門のスタッフが生成AIに社外秘の企画書を入力し、キャッチコピーを生成。ところがそのプロンプトが外部のLLMログに保持され、**社外にアイデアが流出**してしまったという事例もあります。

---

## 2️⃣ データ漏洩のリスク：どこに潜むのか？

### ✅ 入力時の情報流出  
多くのLLMサービスは**ユーザー入力（プロンプト）を学習用に保持**している場合があります。社内の顧客データ、設計書、コードなどを無意識に送信することで、知らぬ間に**モデルの再学習材料にされる危険性**があります。

### ✅ 利用規約の盲点  
「無料で便利なAIツール」には裏があります。ユーザーの入力データに対して所有権を持つ規約のあるプロバイダも存在し、**実質的に情報が第三者に渡る可能性**を孕んでいます。

### ✅ マルチモーダルシャドーAIの危険性  
画像や音声を含む「マルチモーダル」AIサービスの普及により、**図面・手書きノート・会議音声など非構造データの流出**がより容易になっています。

---

## 3️⃣ 実務経験：Google社内でのシャドーAIへの取り組み

私たちのチームでは、AIの社内利用を「完全禁止」するのではなく、**リスクを可視化し、制御可能な範囲で活用を促す**というアプローチを取っています。

### 🔐 実施例：
- AI利用時の**入力フィルタリング**（PIIやコードを検知してブロック）
- APIベースの**企業専用AI環境の構築**
- 社員向けの**セキュリティ教育とシャドーAIの事例紹介**
- 自社データだけで学習した**プライベートLLMの導入**

こうした「コントロールされたAI活用」の設計が、結果としてシャドーAIの発生を抑止する有効な手段となっています。

---

## 4️⃣ 各業界における影響と対応策

| 業界 | リスク | 推奨アクション |
|------|--------|----------------|
| 製造業 | 設計図・機密工程の流出 | 画像認識AIへのアップロード制限 |
| 金融業 | 顧客情報の無意識な入力 | 個人情報フィルタの導入と教育 |
| 教育機関 | 論文や未公開研究の漏洩 | LLMへのアクセスログ監視 |
| 医療業 | 電子カルテや診断データ流出 | 機密性分類と自動遮断機能 |

---

## 5️⃣ 今後への提言：敵にせず、味方につける

シャドーAIは「排除すべき存在」ではなく、「**管理すべき潜在力**」と捉えるべきです。AIの民主化が進む中で、制限のみで従業員の創造性や効率性を縛ることは逆効果になりかねません。

重要なのは：

- ポリシーと教育による**社内意識の統一**
- 利便性とセキュリティを両立する**公式AI環境の整備**
- IT部門と業務部門の**協働によるガイドラインの設計**

---

## おわりに

生成AIの活用はもはや止められません。しかし、活用の仕方を誤れば、それは最も危険な「シャドー」となって企業を蝕みます。

だからこそ、今こそ必要なのは「見える化」と「責任あるAI設計」。私たちエンジニアができるのは、ただ防ぐことではなく、**技術の自由と安全のバランスを実現する仕組みづくり**なのです。


---

📌 ご希望があれば、この投稿をベースにしたホワイトペーパー形式やセミナー用スライドも構成可能です。気軽にお申し付けくださいね！
シャドーAIのリアル：企業の裏側で進行するAI活用とその代償



## 🕵️‍♂️ **「見えないAIのリスク：企業に潜むシャドーAIの正体と実例から学ぶ教訓」**

### 🔍 はじめに

「シャドーIT」という言葉をご存知の方は多いでしょう。しかし、近年の生成AI・LLM・SaaS型AIの爆発的な普及により、**「シャドーAI」**という新たな問題が企業の情報セキュリティ、法令遵守、知的財産、そして倫理リスクをもたらしています。

この記事では、Googleをはじめとするグローバル企業や実際の現場での経験を元に、「シャドーAI」がどのように組織へ浸透し、どんな影響を与えているかを深掘りしていきます。

---

### 1️⃣ シャドーAIとは何か？

「シャドーAI」とは、**企業の公式な管理・監督を受けずに従業員が導入・使用しているAIツールやサービス**を指します。よくあるケースは以下の通りです：

- エンジニアが自前でChatGPTやClaudeを業務に活用  
- 営業部門が無許可でAI翻訳サービスを使用  
- マーケティング部門が画像生成AIを広告素材に利用  

これらは一見すると効率的に見えますが、情報漏洩やコンプライアンス違反を引き起こすリスクをはらんでいます。

---

### 2️⃣ 実例で見るシャドーAIの問題点

#### 🧠 ケース1：プロンプトに含まれた機密情報の漏洩

ある大手製造業では、開発エンジニアがChatGPTにソースコードのバグ修正を依頼。**コードには顧客の仕様情報や認証ロジックが含まれており、結果的にOpenAIのサーバーに機密データがアップロードされていたことが発覚**。

#### 🖼 ケース2：画像生成AIによる著作権侵害リスク

マーケティング部門がMidjourneyやStable Diffusionで生成した画像を広告に使用。しかし生成元が第三者の著作権物を学習している可能性があり、法務部が緊急停止を指示。

#### 📈 ケース3：営業レポートの自動要約で発生した誤報

非エンジニア部門がAIで議事録や営業報告の要約を行ったが、**事実と異なる要約が役員報告書に使われる事態が発生**。後に内部調査と再発防止策が必要に。

---

### 3️⃣ シャドーAIが発生する背景

| 原因 | 説明 |
|------|------|
| 🛠 技術部門に頼らず業務を加速したいという「現場ニーズ」 | 部門独自でAIを導入する動機に |
| 🔓 SaaS型AIツールの普及 | 誰でも登録・利用できる時代に |
| ❌ 組織内のAI利用ルール・教育の未整備 | ガイドラインが追いついていない |

---

### 4️⃣ Googleでの実務的アプローチ

私たちのチームでは、シャドーAIのリスク対策として以下を導入しています：

- **AI使用の事前登録システム**（Shadow AI Detectionツールとの連携）  
- **社内プロンプトポリシーの明文化と共有**  
- **自社開発のセキュアAI APIゲートウェイ**で従業員の自由度と管理を両立  
- **「AIセーフティ・チャンピオン」制度**：各部署にAI管理責任者を配置

また、CI/CDに組み込まれた**データスキャン機能**により、ソースコード中にAIツール経由の外部出力があった場合、警告が出る仕組みも構築しています。

---

### 5️⃣ シャドーAIとどう共存するか？

完全に「使用禁止」とすることは、イノベーションを妨げかねません。重要なのは**「許容できる範囲」と「監視・制御のバランス」**です。

#### 🔑 ポイント：

- **現場との対話**を通じた柔軟なルール設定  
- **「禁止」ではなく「ガイド付き活用」**へのシフト  
- **安全な社内ツールを提供し、野良AIの必要性をなくす設計**

---

## 🧭 まとめ

シャドーAIの問題は、技術の民主化とともに生まれた副作用の一つです。しかし、これは単なるリスクではなく、企業が「**AIリテラシー**」と「**デジタルガバナンス**」を見直す好機でもあります。

AIの時代において、"管理されていない技術"をどう扱うかこそが、**真のイノベーションを可能にする土台**なのです。

---



ご希望であれば、このテーマに基づいて社内セミナー資料やチェックリストなどの補足資料も作成できます。必要でしたらお気軽にどうぞ！
シャドーAIの正体を暴け！検出と制御によるAIガバナンス最前線



# 🕵️‍♂️ **シャドーAIの検出と制御：企業の透明性を守るAIガバナンス最前線**

## はじめに：シャドーAIとは何か？

「シャドーAI（Shadow AI）」とは、組織の公式なIT・セキュリティ部門の監視下にないまま導入・使用されているAIシステムやツールを指します。  
たとえば、ある部署のメンバーが業務効率化のためにChatGPTや画像生成AIを**勝手に導入・利用**していた場合、それはシャドーAIとなります。

この現象は、**技術の民主化（democratization of AI）**が進む一方で、重大なリスクを孕んでいます。

---

## 1️⃣ シャドーAIがもたらす潜在的リスク

### ⚠️ セキュリティ・プライバシーのリスク

- 顧客データを外部AIツールにアップロード → 情報漏洩の可能性  
- API経由でのやり取り → ログが第三者に渡るケースも

### ⚠️ 法的・倫理的問題

- EUの**AI Act**や**GDPR**などに抵触する恐れ  
- 無許可のAI判断による差別的バイアスが混入

### ⚠️ オペレーション上の非整合性

- 業務プロセスのブラックボックス化  
- 意図しない自動処理による品質低下や誤判断  

---

## 2️⃣ 実例：Google Cloudのエンタープライズ環境での観察

私たちが関与したある大手小売チェーンでは、**複数部署が独自にAIモデルを開発・運用**しており、IT部門の統制が届かない状態が常態化していました。

これにより：
- データソースが不一致  
- 同一タスクに複数のAIが動作（コスト増）  
- モデルの品質評価が困難  

この課題に対応するため、次の施策を講じました。

---

## 3️⃣ シャドーAI検出のためのテクニカルアプローチ

### 📌 ログベースの検出

- APIトラフィックの監視によってAI関連ツールの使用傾向を把握  
- 外部ドメインへのPOST・GETリクエストを自動でタグ付け

### 📌 エンドポイントスキャニング

- 端末内に存在するAIツールのインストール情報を検出  
- 使用頻度やモデルの種類をベースに自動リスクスコアリング

### 📌 社内アンケート＋自動化スキャンのハイブリッド運用

- 定期的な「AI利用実態調査」＋バックグラウンドスキャンを並行実施

---

## 4️⃣ 制御とガバナンスの最前線

### ✅ ポリシー設計と啓発

- 「業務で使用可能なAIカタログ」の明示  
- シャドーAIのリスクを共有するワークショップの実施

### ✅ MLOps基盤での統合管理

- すべてのAIモデルを**一元管理**できるプラットフォーム（例：Vertex AI, SageMaker）を導入  
- 認可されていないモデルの自動フラグ機能を設置

### ✅ AI利用レジストリの構築

- 全社横断の「AIアセット台帳」を構築  
- モデル・データ・責任者を紐付けたトラッキング体制を整備

---

## 5️⃣ 今後の展望：シャドーAIを“敵”から“資産”へ

シャドーAIは“隠れたリスク”であると同時に、現場の**創造力と柔軟性の証拠**でもあります。単純に排除するのではなく、**イノベーションの種として活かす**アプローチが求められています。

- 利用実態を“見える化”し  
- 適切に“ガイド”し  
- 公式な枠組みに“昇華”させる

この3ステップが、未来のAI活用の鍵となるでしょう。

---

## 🎯 おわりに

シャドーAIの検出と制御は、単なるセキュリティ対策ではありません。  
それは「AIとの共存社会」を築くための第一歩であり、透明性と信頼性を備えた**AIガバナンス時代の基盤**です。
金融の現場に潜むシャドーAI：リスクとイノベーションの狭間で



# 🕵️‍♂️ **「金融業界のシャドーAI：リスクか、それとも成長のカギか？」**

## はじめに：シャドーAIとは何か？

「**シャドーAI（Shadow AI）**」とは、企業の正式なIT部門やガバナンスを通さずに、現場主導で導入・運用されているAIシステムやMLモデルを指します。これは、シャドーITの概念をAI領域に応用したもので、特に以下のような背景で発生します：

- 業務部門が業務効率化のために**独自開発したAIツール**  
- 社外SaaSツール（ChatGPT、AutoML等）を**無断活用**  
- ガバナンスの範囲外で構築されたデータパイプラインやモデル  

金融業界はその特性上、「透明性」「説明責任」「リスク管理」が非常に重要なため、シャドーAIの存在は**大きなリスクと同時に、現場主導のイノベーションの源泉**にもなり得ます。

---

## 1️⃣ 金融業界における実態とユースケース

### 💡 現場で実際に使われているシャドーAIの例：

| 用途 | シャドーAIの例 | リスク |
|------|----------------|--------|
| クレーム分類 | カスタマー部門が独自にChatGPT APIを接続 | データ漏洩、顧客情報管理違反 |
| 不正検出 | アナリストが自前の異常検知モデルを使用 | モデルの精度・正当性の不透明性 |
| 投資判断支援 | 営業チームがExcel＋Pythonで予測分析 | ロジックの属人化、再現性の欠如 |

このようなユースケースは、スピーディに現場課題を解決する一方で、「**誰が責任を持つのか**」「**どのデータを使っているのか**」といった点で多くの問題を孕んでいます。

---

## 2️⃣ シャドーAIが金融機関にもたらすメリット

### ✅ メリット1：スピードと柔軟性

中央IT部門に依頼せずとも、**現場で即時対応できる**ため、業務改善や試験的導入が加速します。

### ✅ メリット2：現場の創意工夫を促進

ユーザー部門がデータとツールを活用し、**自発的にAIリテラシーを高める**文化が生まれます。

### ✅ メリット3：PoC（概念実証）の足がかり

正式導入前に、シャドーAIで素早くPoCを回し、有効性を確認するのに適しています。

---

## 3️⃣ しかし、それでも放置できないリスク

### ❗ リスク1：コンプライアンス違反

金融業界は、**GDPR、FISC、安全管理基準**など厳しい規制があり、データの無断利用は即時違反になり得ます。

### ❗ リスク2：ブラックボックス化

誰が作ったのか、何で動いているのか、**ロジックも精度も不透明**なAIが業務意思決定に使われると、重大な事故につながる可能性があります。

### ❗ リスク3：セキュリティインシデント

外部APIやSaaSの活用は、**情報漏洩や攻撃の温床**となります。特に生成AIは、プロンプトを通じたデータ流出のリスクが見過ごされがちです。

---

## 4️⃣ 実務での経験と対応策（Googleでのプロジェクトより）

私が過去に関わった某欧州系銀行では、営業現場が「非公式ChatGPT連携ツール」を使って問い合わせ対応をしていたことがありました。

#### 📌 解決アプローチ：

- 現場ヒアリングで**本当に必要だった機能**を把握  
- セキュアな環境で同様の機能を**正式プロダクト化**（社内APIで制限付き生成AIを提供）  
- シャドーAIの利用を検知する**監視スクリプトとアラート体制**を構築  
- 「シャドーAI申告制度」を設けて、**共創的なイノベーション文化**を育成

---

## 5️⃣ 今後の展望：シャドーAIとの共存・活用戦略

### 🔄 抑圧より共存へ：「シャドーAI共創戦略」

| アプローチ | 内容 |
|------------|------|
| 可視化 | シャドーAIを「敵」とせず、現場主導のAI利用状況を把握するダッシュボードを整備 |
| インキュベーション | シャドーAIから得た知見を元に、正式プロダクトとして内製化するパイプラインを整備 |
| 教育と共育 | 「AI利用倫理・セキュリティ教育」を現場レベルで実施し、**責任あるAI開発文化**を醸成 |

### 📢 メッセージ：

金融におけるAI活用は、ガバナンスとスピードの**絶妙なバランス**が求められます。シャドーAIを完全に排除するのではなく、**その創造力を制度に組み込むアプローチこそ、次のフェーズのAI活用**だと私は考えています。

---

## ✅ まとめ

- シャドーAIは金融業界で広く存在しており、創造性とリスクが背中合わせ  
- 放置せず、対話と制度で共存可能な道を模索することが重要  
- ガバナンス体制と現場の創意工夫を結びつける「共創」が鍵  

---


ご希望であれば、「シャドーAI検知アルゴリズム」「他業界での応用事例」「社内AIポリシー構築のステップ」などもご紹介できます！どの方向に広げていきましょうか？
見えないAIの力をどう制御する？シャドーAIとの共存戦略



# 🕵️‍♂️ **「見えないAIの影」— シャドーAIをどう管理し、どう共存するか？**

## ✅ はじめに：シャドーAIとは何か？

「シャドーAI」とは、**企業のIT部門や情報セキュリティ部門の管理下にない形で、個人やチームが導入・利用するAIツールやモデル**を指します。クラウドベースの生成AIやAPI、ノーコードAIツールが急速に普及する中、現場の担当者が自己判断でAIツールを導入するケースが増加しています。

例：
- 営業担当者がChatGPTで提案文を自動生成  
- 開発者がMidjourneyでUIモックを作成  
- マーケティング部門がStable Diffusionでビジュアルを生成  

このようなケースがシャドーAIに該当します。

---

## ⚠️ なぜシャドーAIが問題になるのか？

### ① セキュリティ・データガバナンスの欠如  
- 社外AIサービスに業務データが流出するリスク  
- 機密情報が第三者に蓄積される恐れ  

### ② コンプライアンス違反の可能性  
- GDPRや国内個人情報保護法への抵触  
- 知的財産権侵害のリスク（画像・文章生成など）  

### ③ 品質と責任の不透明性  
- 誰が出力内容の責任を取るのかが曖昧  
- モデルのバイアスや誤りを誰もチェックしていない  

---

## 🔧 私たちが実際に経験したシャドーAIのリスク事例（Google内）

ある大手企業のクライアント企業で起きた事例では、マーケティング部門が外部のAI文章生成ツールを利用し、キャンペーンコピーを作成。しかし、そのコピーが**競合他社の広告と酷似**していたことが後日判明し、**知財リスク**と**ブランド毀損**につながる可能性が指摘されました。

このようなリスクは、ツールそのものよりも**「使い方がブラックボックス化している」**ことが問題なのです。

---

## 🛠️ 企業が取るべきシャドーAI管理戦略

### ✅ 1. AIガバナンスポリシーの策定

- どのようなAIツールの利用が許可されるか
- 利用申請のフローと承認体制
- 利用目的とデータ種別の明示化

→ Googleでは**AI使用事前レビュー制度**を導入し、各チームがAI活用前に用途とリスクをレビュー委員会に提出する仕組みを取っています。

---

### ✅ 2. セキュリティ基準を明文化する

- 入力データの暗号化要件  
- 外部APIのログ収集と監査体制  
- モデル出力の保存・検証ルール  

→ Zero Trustベースのセキュリティアーキテクチャとの統合がカギです。

---

### ✅ 3. 社内用の「ホワイトAIツール群」を提供する

- 利用実績があり、安全性の高いAIツールを社内に導入  
- 生成系AIを含む「社内承認済みツールリスト」の公開  
- エンドユーザーにとっての「使いやすさ」も重要

→ シャドーAIの多くは「使いたいけど会社が遅いから自分でやる」というニーズから発生します。**公式ツールの拡充は最大の予防策**です。

---

## 🤝 シャドーAIとどう「共存」していくか？

完全にシャドーAIを排除するのは不可能です。むしろ、現場の創造性を支援する存在として捉え、

- **トラッキングできる形での導入**
- **一定の自由と安全性のバランス**
- **教育とガイドラインによる行動変容**

が、これからの企業に求められる姿勢です。

私たちは、AI技術の恩恵を受けながらも、組織全体として責任と透明性を保つ枠組みを作り上げていく必要があります。

---

## ✍️ まとめ

シャドーAIの問題は、もはや単なるITの範疇ではなく、**組織文化・セキュリティ・イノベーションのバランスを問う本質的な課題**です。現場のスピード感と、企業としての責任をどう調和させるか——その解答は、いま私たち一人ひとりの手に委ねられています。
見えないAI、見逃せないリスク：セキュリティ担当が知るべきシャドーAIの真実



# 🕵️‍♂️ **セキュリティvsシャドーAI：企業が見落としがちな“もう一つのリスク”**

## はじめに

生成AIの進化により、社員一人ひとりがChatGPTや画像生成ツール、音声認識APIなどを手軽に活用できる時代になりました。しかし、その裏で静かに進行しているのが「**シャドーAI**」──企業が把握していない、非公式なAIツールの使用です。

本稿では、「シャドーAIとセキュリティ」にフォーカスし、実務で直面した課題や企業の対応事例を交えて、見過ごせないリスクとその対策について詳しく解説します。

---

## 1️⃣ シャドーAIとは何か？なぜ問題視されているのか？

**シャドーAI（Shadow AI）**とは、企業が正式に認可していないAIツールやサービスを、従業員が独自に業務へ導入・使用することを指します。これは**シャドーIT**のAI版とも言える存在です。

### 🔍 具体例：
- エンジニアがコードレビューのためにChatGPTを非公式に活用  
- 営業部が会議記録をAI文字起こしツールで作成し、クラウド保存  
- マーケティング担当が社内データを用いて画像生成AIにプロンプトを入力

いずれも生産性は向上するものの、「**セキュリティポリシー違反**」「**個人情報漏洩**」「**知的財産の外部流出**」などの深刻なリスクをはらんでいます。

---

## 2️⃣ 実際に起きた事例：グローバル企業での“無意識リーク”

私が過去に関わったプロジェクトの中で、ある開発チームがGitHub Copilotを個人アカウントで使用し、**社内未公開アルゴリズムの一部を提示**してしまった事例がありました。

当人は「便利だから使った」だけでしたが、結果的にそれは知的財産のポリシー違反。しかも企業側は当初、**その事実すら認知していなかった**のです。

---

## 3️⃣ シャドーAIのリスクは多岐にわたる

| リスクカテゴリ | 内容 | 影響 |
|------------------|------|------|
| 情報漏洩リスク | 社内データが第三者のLLMへ送信される可能性 | 機密情報の流出、法的リスク |
| コンプライアンス違反 | データ取り扱いルール違反（GDPR等） | 巨額な罰金、信頼失墜 |
| 信頼性の低下 | 外部AIの出力に依存し、品質が担保されない | 不正確な意思決定・誤報リスク |
| セキュリティ脆弱性 | 非正規アプリ経由でマルウェア侵入の可能性 | サイバー攻撃の踏み台に |

---

## 4️⃣ 企業が取るべき具体的対策

### ✅ ① AIガバナンスポリシーの整備
企業は明確な「**AI利用ガイドライン**」を定め、使用可能なツールと禁止事項を明示する必要があります。

例：  
- 社内データを外部AIに直接入力しない  
- 個人アカウントでのAIサービス利用を原則禁止  
- 利用するAIモデルのログ保存・監査機能の導入

### ✅ ② 技術的制御（ツール制限・ネットワーク監視）

- 社内ネットワークでの外部AIツールへのアクセス制御  
- APIリクエストのログモニタリングとアラート設定  
- エンドポイントでのDLP（データ漏洩防止）対策の強化

### ✅ ③ ポジティブなAI利用の促進

禁止だけでは現場の創造性は育ちません。  
→ **セキュリティを確保しつつ、安全に使えるAI環境の整備（社内LLMの導入など）**が今後の鍵です。

---

## 5️⃣ 「見えないAI活用」を見える化するには？

現在、**シャドーAIの検知と可視化**に特化したSaaSソリューションも登場しています。

- **AI利用監査ツール**：社内ネットワーク経由で使用されるAIツールのトラッキング  
- **プロンプト分析ツール**：送信されるテキストの内容を解析し、リスクスコア化  
- **ログベースのAI影響評価ダッシュボード**

これらを導入することで、企業は「どこで」「誰が」「何のために」AIを使っているかを把握できるようになります。

---

## おわりに：シャドーAIは「敵」ではなく「兆候」

シャドーAIは、現場の創意工夫や業務改善意欲の表れでもあります。  
したがって、単に「禁止」するのではなく、それを**公式の枠組みへと昇華させる仕組みづくり**が今、求められています。

✅ 透明性  
✅ セキュリティ  
✅ 現場の創造性  

これらのバランスをとりながら、企業全体で「信頼されるAI活用」を目指しましょう。



気になる部分や、さらに深堀りしたいテーマ（例えば「社内LLMの導入とシャドーAI対策」など）があれば、お気軽にどうぞ！
シャドーAIの脅威と可能性：企業は見えないAIとどう向き合うべきか？



# 🕵️‍♂️ **「シャドーAIの真実：見えないリスクが企業をむしばむ」**

## はじめに

「シャドーIT」という言葉をご存じの方は多いでしょう。しかし、今日の企業にとって新たな脅威となりつつあるのが **「シャドーAI」** です。  
これは、企業の正式なIT部門・ガバナンス体制を経ずに、**現場レベルでAIツールや生成AI（例：ChatGPT、Copilot、Claudeなど）を無断利用する現象**を指します。

私たちがやクライアント企業と協働する中で、AI活用の爆発的な広がりと同時に、**セキュリティリスク・倫理課題・知的財産漏洩の温床**として急浮上しているのがこの「シャドーAI」です。

---

## 1️⃣ シャドーAIとは何か？―その定義と背景

**シャドーAI（Shadow AI）** とは、企業のIT・セキュリティ部門の承認を経ずに、従業員やチームが独自にAIツールを導入・使用することです。  
例えば以下のようなケースが該当します：

- 社内会議の議事録を、個人のChatGPTアカウントで自動生成  
- 営業部門が独自にCRMデータを外部のAIツールで分析  
- エンジニアがコーディングにCopilotを使用し、意図せず外部APIにソースコードが送信される

背景には以下のような要因があります：

- 誰でも簡単に使える生成AIの普及  
- 現場主導での業務効率化へのプレッシャー  
- 企業内でのAIガイドラインや教育の未整備

---

## 2️⃣ シャドーAIが企業にもたらす5つの重大リスク

### ⚠️ ① 情報漏洩リスク（データプライバシーの欠如）

多くの生成AIは**クラウド上で動作し、入力データを学習に利用する**可能性があります。機密情報や顧客データが外部に渡れば、GDPRや個人情報保護法への違反に繋がります。

### ⚠️ ② 知的財産の流出・帰属問題

ソースコードやビジネスロジックをAIに入力することで、**第三者に知財が帰属する可能性**が生まれる。実際、Copilotをめぐる著作権訴訟も発生しています。

### ⚠️ ③ 組織の一貫性の喪失

各部門がバラバラにAIを使うと、**データサイロ**が発生し、全社的なデータ戦略や品質担保が困難になります。

### ⚠️ ④ モデルバイアスと倫理的課題

生成AIはブラックボックスであり、**出力結果がバイアスを含んでいても気づきにくい**。特に人事・採用や金融での利用は要注意です。

### ⚠️ ⑤ レピュテーションリスク（信頼失墜）

誤ったAI出力を顧客に提示したり、SNSで炎上するなど、企業ブランドに**直接的なダメージ**を与える事例も増加しています。

---

## 3️⃣ 実際に起きたシャドーAIの事例（現場経験より）

### 🧪 事例1：ある製薬会社の研究部門でのChatGPT活用

研究者がChatGPTに論文ドラフトを生成させ、プロジェクト概要を入力。  
→ 数ヶ月後、同様の研究内容が外部の公開データベースに掲載。**知財管理部門が青ざめる結果に。**

### 💻 事例2：グローバルIT企業でのエンジニアのCopilot使用

GitHub Copilotで効率的にコーディングしていたが、  
→ 外部ライブラリからの無断引用コードが混入し、**ライセンス違反**が発覚。商用製品のリリースが遅延。

---

## 4️⃣ シャドーAIへの対応戦略：抑止と共生

企業は「シャドーAI禁止」だけではなく、**使いたくなる正規AI環境の提供と教育**が重要です。

### ✅ 有効なアプローチ：

| 分野 | 対策例 |
|------|---------|
| セキュリティ | 社内用のセキュアな生成AI（例：社内GPT）の提供 |
| ガバナンス | AI使用ガイドライン・ホワイトリストの整備 |
| 教育 | 部署ごとのAIリテラシー研修＋事例共有 |
| モニタリング | API利用ログや生成AIアクセスの監視ツール導入 |
| DevOps連携 | シャドーAI検出機能をCI/CDに組み込む |

---

## 5️⃣ 私たち技術者に求められる姿勢とは？

Googleでも、生成AIの導入時には「**AI Responsibility & Privacy by Design**」の原則に基づき、開発プロセスやツール選定を行っています。

大切なのは：

- **現場のニーズを理解し、使いやすい正規手段を設計すること**  
- **“禁止”ではなく“信頼”でコントロールする文化を作ること**  
- **技術者が倫理とセキュリティの交差点で主導権を握ること**

---

## おわりに

シャドーAIは、一見便利で革新的に見えても、その裏には大きなリスクが潜んでいます。  
しかし、正しく理解し、戦略的に向き合えば、それは「新たな業務変革のチャンス」ともなり得るのです。

あなたのチームでは、生成AIの使い方が明文化されていますか？シャドーAIを“見える化”する体制、できていますか？  
ぜひこの投稿にコメントして、あなたの現場の課題も共有してください！
AI規制と未来のイノベーション：私たちは制限されるのか、それとも進化するのか？



# ⚖️ **AI規制とイノベーションの未来：制限か、それとも進化の触媒か？**

## はじめに

AI技術の急速な進展とともに、各国政府や国際機関はそのリスク管理と倫理的活用を目的に規制の枠組みを整備し始めています。特にEUにおける「**AI Act**」は、世界で初めて本格的なAI法として注目を集めています。

しかしながら、AIの規制は「イノベーションの抑制」なのか、それとも「健全な発展の推進」なのか──この問いは、私たちエンジニアや研究者、企業にとって極めて現実的なものです。本記事では、AI規制が未来の技術革新に与える影響を、多角的な視点と実務経験を交えて考察します。

---

## 1️⃣ AI Actの概要と目的

EUが提案する「AI Act」は、リスクベースのアプローチを採用しており、AIシステムを4つのリスクレベルに分類しています：

- **禁止されるリスク（Unacceptable Risk）**
- **高リスク（High Risk）**
- **限定的リスク（Limited Risk）**
- **最小リスク（Minimal Risk）**

高リスクAI（例：顔認識、生体認証、採用AIなど）は、厳格な要件を満たす必要があります。主な目的は以下の通り：

- ユーザー保護と基本的人権の尊重  
- 信頼性と透明性の担保  
- 市場の信頼性向上と公平性の確保  

---

## 2️⃣ イノベーションに与える直接的な影響

### ❗ プロトタイピングとスタートアップへの障壁

AI Actは、開発プロセスの初期段階からコンプライアンスを求めるため、小規模なスタートアップ企業やアカデミックプロジェクトにとっては**ハードルが高い**。例えば：

- 認証プロセスのコスト増加  
- プロダクトの市場投入までのリードタイムの増大  
- 実証実験におけるデータ使用の制限  

### ✅ しかし、ガイドラインとしての価値も

一方で、明確な規制は「何をしてはいけないか」が可視化されるため、**初期段階でのリスクマネジメントが可能**になり、結果として市場での信頼を得やすくなる側面もあります。

---

## 3️⃣ 実務から見た影響と戦略的対応

### 💼 実際の開発現場での経験（Googleでの事例）

私たちが関与したあるプロジェクトでは、EU向けに展開する医療用AI製品を開発する際、AI Actを想定したドキュメンテーションとロギング機能の設計を**開発初期から組み込む**ことで、後の監査対応がスムーズになりました。

#### 📌 対応策の例：

- 開発時からの**AIモデルのExplainability（説明可能性）**の設計  
- **バイアスチェック**を組み込んだCI/CDパイプラインの構築  
- データライフサイクルの透明性を担保するための**ログ収集・保存ポリシー**の導入  

---

## 4️⃣ 各業界への影響と応用例

| 業界 | 影響 | 対応方法 |
|------|------|---------|
| 医療 | 高リスクに分類。臨床AIの認可に影響 | リスクアセスメントと説明責任体制の構築 |
| 教育 | 学習者の評価AIに規制の可能性 | 利用目的の明示とバイアス防止 |
| HR・採用 | バイアス問題が焦点に | 多様性配慮設計＋人間の最終判断を維持 |
| 金融 | クレジットスコアAIなどが対象 | 監査ログの記録と開示義務対応 |

---

## 5️⃣ 今後の展望：制限か、成長機会か？

AI Actを「制限」と見るか、「品質担保と信頼性の機会」と見るかは、企業と開発者の意識次第です。実際、規制対応を前提とした開発体制を整えることで：

- プロダクトの国際展開が容易になる  
- エシカルAIとしての**ブランディング強化**が可能  
- 法的リスクの最小化によって**投資家からの信頼**が向上  

---

## おわりに

AI規制は、私たち技術者にとって「制約」であると同時に、未来の技術と社会の共生を目指す「指針」でもあります。生成AIの進化やマルチモーダルなAIモデルが一般化する中で、こうした規制の理解と対応力はますます重要になってきます。

規制を味方につけ、透明で信頼されるAIを社会に届けるために、今こそエンジニアリングと倫理の交差点に立ち、次の一歩を踏み出しましょう。

📣 あなたのチームでは、AI規制にどのように対応していますか？実践例や課題があれば、ぜひコメントで教えてください！
AI倫理と法的責任：技術者が創るべき“説明可能な未来”


---

# ⚖️ AI倫理と法的責任：技術者が直面するジレンマと、AI Actがもたらす未来

## はじめに

近年の生成AIや大規模言語モデル（LLM）の急速な発展により、私たちはかつてないほど高度なAIを社会に導入するフェーズに入っています。しかし、利便性と同時に、**倫理的責任**と**法的リスク**も急速に拡大しています。

EUが提案する「AI Act」や日本政府のガイドラインが整備されつつある中、現場のエンジニアはどのようにこの法規制と向き合い、現実的に何をすべきなのか？での実務経験をもとに、AI倫理と法的責任を深く掘り下げていきます。

---

## 1️⃣ AIは誰の責任で動くのか？──「責任の空白地帯」問題

### 📍ブラックボックス化する意思決定

AIモデル、特にディープラーニングを用いたシステムでは、**「なぜこの判断に至ったのか」**を人間が明確に説明できないケースが増えています。これが、**説明責任の所在**を曖昧にし、法的トラブルの火種になります。

現場では以下のような疑問が頻出します：

- 間違った診断を出した医療AIの責任は？（開発者？病院？ベンダー？）
- 自動運転車が事故を起こしたとき、誰が裁かれるのか？

これらは単なる法務の問題ではなく、**設計段階からの技術的考慮**が求められる時代です。

---

## 2️⃣ AI Actと「ハイリスクAI」──今後の開発にどう影響するのか？

EUのAI Actは、AIシステムをリスクレベルに応じて分類し、それぞれに異なる規制を課す初の包括的枠組みです。特に注目されるのが、以下の「ハイリスク」カテゴリー：

- 顔認識（リアルタイム監視）
- クレジットスコアリング
- 自動採用システム
- 医療診断AI

### ✅ ハイリスクに該当する場合の技術的義務

- データのバイアス検証
- 透明性の確保（説明可能性）
- ロギングとモニタリング
- ユーザーへの明確な通知（AI使用中であることの表示）

**現場のエンジニアやPMが、初期設計段階から法的コンプライアンスを意識**しなければならない時代が来ています。

---

## 3️⃣ 実務経験からの教訓：倫理と法をコードに落とし込む

### 🧩 実装レベルでの工夫

の社内プロジェクトでは、AI倫理への配慮が以下のように具体化されています：

- **公平性評価ツールの自動実行**：モデル学習後、人口統計ごとの精度差を自動で検出。
- **説明可能性モジュールの標準化**：SHAPやLIMEなどのアルゴリズムをラップして、APIレベルで統一。
- **モデル使用ログの監査対応**：後で追跡可能なように、モデル出力と使用条件を全て記録。

これらはすべて、「法的責任の分散」ではなく、**技術者が責任を受け止められる構造の構築**を目的としています。

---

## 4️⃣ 業界別の実践例とベストプラクティス

### 💼 採用AI（HR Tech）

- 偏りのあるデータが差別的選考を生むリスクあり
- 対応策：応募者にAI使用を明示し、異議申し立て機能を実装

### 🏥 医療AI

- 臨床現場での誤診が人命に直結する
- 対応策：AIは**「助言」**であり、最終判断は医師に委ねる設計

### 🚘 自動運転

- 複数センサーからの意思決定がブラックボックス化しやすい
- 対応策：推論過程の記録とリアルタイムモニタリングを必須化

---

## 5️⃣ 今後に向けて：エンジニアは何をすべきか？

### 🌍 倫理設計は「後付け」ではなく「仕様書レベル」で

AI倫理はもはや社会学者や法務だけの課題ではありません。**「どんなデータを使うか」「どこで使われるのか」「どう説明するのか」**を設計段階からコードに落とし込む時代です。

技術者自身が「設計思想」を持ち、プロダクトを社会に送り出す責任を担うこと。それが、未来のAIと法のバランスを築く鍵となります。

---

## 🧠 最後に：あなたの「AI倫理観」は明文化されていますか？

法が整備されるのを待つだけでは、責任あるAIは実現しません。今日からでも、自分たちのAI開発における倫理観やガイドラインを明文化することが第一歩です。

私たち技術者こそが、AIの使われ方を形づくる存在です。責任と自由のバランスを、未来に向けて築いていきましょう。
AI Act vs アメリカ規制：グローバルAI開発における“法の境界線”を超えて



## ⚖️ AI規制（AI Act）シリーズ Vol.5  
# AI Actと米国の規制の比較：テクノロジー企業が直面するグローバルコンプライアンスの現実

---

### 1️⃣ はじめに：AI規制の地政学的リアリティ

近年、AI技術の急速な進化により、世界各国で法規制の整備が進められています。なかでも、**EUのAI Act**は最も包括的かつ厳格なルールとして注目を集めています。一方、アメリカでは州単位またはセクターごとのアプローチが中心で、より**分散的で柔軟な規制構造**を採用しています。

私自身、でAIプロダクトの設計・運用に携わる中で、両者の違いが実務に与える影響を痛感しています。本稿では、その実体験を踏まえて比較・分析していきます。

---

### 2️⃣ EU AI Actの概要とその特徴

#### ✅ リスクベースアプローチ
- AI ActはすべてのAIシステムを4段階のリスク（禁止・高リスク・限定リスク・最小リスク）に分類。
- 高リスクAI（顔認証、信用スコアリング等）は、厳格な透明性、説明責任、監査要件を満たす必要がある。

#### ✅ コンプライアンス義務
- CEマーキング、データガバナンス、人的監督などの要件が義務化。
- プロバイダはAIモデルの事前申告と審査を経る必要がある。

---

### 3️⃣ 米国のAI規制：緩やかな「ソフト・ガバナンス」

#### ✅ 州ベースの自主ガイドライン
- カリフォルニア州やニューヨーク州では、プライバシーやアルゴリズムバイアス対策を中心としたガイドラインを発表。
- 強制力よりも**企業の自律的な倫理遵守**を重視する傾向が強い。

#### ✅ セクター特化型のアプローチ
- 医療、金融、雇用など、分野別に個別の規制が存在（例：FDAによる医療AIの承認）。
- 国全体で統一されたAI法案は存在せず、現在も連邦レベルでの議論は進行中。

---

### 4️⃣ 実務における影響と課題：での経験より

#### 🔍 「マルチリージョン対応」の設計
- 欧州向けプロダクトではAI Actへの準拠が必要となり、アメリカ仕様とは異なる**技術設計・データ処理フロー**を構築。
- 「Explainability（説明可能性）」のレベルや、「Data Provenance（データ由来）」の記録基準にも大きな差異。

#### 🔍 法規制の不一致による開発コスト増加
- 同じ機能を提供するにも、地域ごとの**法的要件の調整と監査準備**が必要。
- 特にAIモデルの「訓練データの公開範囲」や「倫理審査手順」は、企業の開発スピードを制約する要因となり得る。

---

### 5️⃣ 業界全体に求められる視点：グローバルAIコンプライアンス戦略

#### 🌍 統一フレームワークの模索
- 各国規制の「共通項」を抽出し、グローバルで統一的な開発ガイドラインを持つことが今後不可欠。
- 例えば、**ISO/IEC 42001**（AIマネジメントシステム）など、業界標準との連携が鍵を握る。

#### 🤝「法務×開発」の連携強化
- 法務チームと開発チームが密に連携し、**設計段階から規制対応を織り込む**「Privacy/Compliance by Design」の体制が求められる。
- プロトタイプ段階からリーガルレビューを実施することで、後工程での修正負担を回避。

---

### 🔚 おわりに：AIの未来は法とともにある

AIの発展が社会に貢献するためには、**テクノロジーと法のバランス**が必要です。EUと米国、異なる規制環境の中で、私たちエンジニアは**倫理的かつ持続可能な開発**を実現するために、新たなスキルと視点を磨く必要があります。

📣 みなさんの現場で感じる「AI規制との向き合い方」や「国ごとの課題」についても、ぜひコメントで教えてください！
Intel oneAPIを一般ユーザー権限で入れる

# Intel® oneAPI
言わずと知れたインテル謹製のコンパイラー、ライブラリー群。
管理者が入れることもできるけれど、一般ユーザー権限でインストールするときの記録。

# Ubuntu22.04へのインストール
Intel® oneAPI HPC Toolkitを入れたいが、その前にIntel® oneAPI Base Toolkitを入れる必要がある。
[Intel® oneAPI Base Toolkit: Essential oneAPI Tools & Libraries](https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit.html)のDownloadのペインを選択。

Packages: Intel® oneAPI Base Toolkit
Operating System: Linux
Installer Type: offline installer

ユーザー登録面倒なので、`Continue as a Guest (download starts immediately) →`からダウンロード。

```console
bash intel-oneapi-base-toolkit-2025.1.0.651_offline.sh 
```
で実行。GUIが立ち上がるので従っていけばインストール完了。
例えば`icx`は`$(HOME)/intel/oneapi/2025.1/bin`にインストールされている。
```bash
. $(HOME)/intel/oneapi/setvars.sh 
``` 
で、環境設定が終了して、PATHも通る。

Configure System After Installationによると、以下のパッケージをインストールしておくと良い:
```bash
sudo apt update
sudo apt -y install cmake pkg-config build-essential
```
```bash
bash ./intel-oneapi-hpc-toolkit-2025.1.0.666_offline.sh 
```
で実行。GUIが立ち上がるので従っていけばインストール完了。

`which ifx`でFortranコンパイラーのPATHが出てくれば、正常にインストールが成功していることが確認できる。(最近のoneAPIでは、Fortranコンパイラーは`ifort`ではなく`ifx`らしい。)

# `modulefiles-setup.sh`の使い方
このスクリプトでモジュールファイルが指定先のディレクトリに生成される。以下が使用例

```bash
bash modulefiles-setup.sh --output-dir=/home/ユーザー名/opt/modulefiles/oneapi
```

`module avail`で
```console:(出力抜粋)
----------------------- /home/ユーザー名/opt/modulefiles ------------------------
oneapi/advisor/2025.1                oneapi/dpl/2022.8
oneapi/advisor/latest                oneapi/dpl/latest
oneapi/ccl/2021.15.0                 oneapi/intel_ipp_intel64/2022.1
oneapi/ccl/latest                    oneapi/intel_ipp_intel64/latest
oneapi/compiler-intel-llvm/2025.1.0  oneapi/intel_ippcp_intel64/2025.1
oneapi/compiler-intel-llvm/latest    oneapi/intel_ippcp_intel64/latest
oneapi/compiler-rt/2025.1.0          oneapi/ishmem/1.3.0
oneapi/compiler-rt/latest            oneapi/ishmem/latest
oneapi/compiler/2025.1.0             oneapi/mkl/2025.1
oneapi/compiler/latest               oneapi/mkl/latest
oneapi/debugger/2025.1.0             oneapi/mpi/2021.15
oneapi/debugger/latest               oneapi/mpi/latest
oneapi/dev-utilities/2025.1.0        oneapi/tbb/2022.1
oneapi/dev-utilities/latest          oneapi/tbb/latest
oneapi/dnnl/3.7.1                    oneapi/umf/0.10.0
oneapi/dnnl/latest                   oneapi/umf/latest
oneapi/dpct/2025.1.0                 oneapi/vtune/2025.1
oneapi/dpct/latest                   oneapi/vtune/latest
```
⚖️ AI規制の最前線：EU AI Act対応で学んだ「法的適合性」の核心と実践テクニック





 

### 1. **AI Actの「リスク分類」を製品開発に落とし込む方法**  
EUの規制では、AIシステムを「無条件禁止」「高リスク」「限定リスク」「最小リスク」の4段階に分類。例えば、医療診断支援AIは「高リスク」に該当し、以下の要件が課せられます：  
- **技術文書の作成**（ISO 42001準拠）  
- **人間の監視メカニズム**の組み込み  
- **データガバナンス**（バイアス検証の義務化）  
▶️ 実際のプロジェクトでは、**「リスクマトリックス」**を製品マネージャーとエンジニアで共同作成し、要件をユースケースごとにマッピングしています。  

### 2. **「説明可能性」をシステム設計に織り込む技術**  
規制が求める透明性を実現するため、では3つのアプローチを採用：  
- **モデルカード（Model Cards）**：AIの性能限界やトレーニングデータの偏りを開示  
- **LIME/SHAPライブラリ**の活用：個々の予測の根拠を可視化  
- **ユーザーインターフェース設計**：医療用AIでは「信頼度スコア」を併記するなど、専門家向けに調整  

### 3. **検証プロセスの自動化：コンプライアンスTechの進化**  
規制対応の負荷を軽減するため、社内で開発したツール例：  
- **Compliance Checker**：コードレビュー時に自動でデータソースのライセンス検証  
- **Bias Detection Pipeline**：モデルデプロイ前に保護属性（人種/性別等）への感受性をテスト  
※ ある金融AIプロジェクトでは、このパイプラインが**潜在的な年齢差別**を検出し、リコールを回避できました。  

### 4. **規制を超えて：倫理的AIのビジネス価値**  
EU AI Act対応はコストではなく、**競争優位性**に変換可能です：  
- 消費者からの信頼向上 → 採用率23%増（社内調査）  
- **「Ethical by Design」認証**を取得し、公共調達で優位性確保  
- 規制対応プロセスから生まれた軽量モデル技術で、クラウドコストを15%削減  

 

---  

規制はAI業界の「制約」ではなく、**責任あるイノベーションの羅針盤**です。皆さんの組織での取り組みや課題共有もお待ちしています！ 🌐
Supabase クエリビルダー メソッド一覧（よく使うもの）

Supabase の JavaScript クライアント（@supabase/supabase-js）を使ってデータベース操作を行う際によく使うメソッドを一覧で紹介します。

SQLと対応付けて覚えると理解がスムーズです！

---

## 🛠 データ操作

| メソッド                                 | 説明            | 使用例                                                      |
|------------------------------------------|-----------------|-------------------------------------------------------------|
| `.select()`                               | データ取得      | `.select('*')`                                              |
| `.insert([{ ... }])`                      | データ追加      | `.insert([{ title: '新しいタスク' }])`                      |
| `.update({ ... }).eq('col', val)`         | データ更新      | `.update({ title: '変更後' }).eq('id', 1)`                  |
| `.delete().eq('col', val)`                | データ削除      | `.delete().eq('id', 1)`                                     |

---

## 🎯 条件指定（WHERE句）

| メソッド                    | 説明         | 対応するSQL             | 使用例                                |
|-----------------------------|--------------|--------------------------|----------------------------------------|
| `.eq('col', val)`           | 等しい       | `WHERE col = val`       | `.eq('id', 1)`                         |
| `.neq('col', val)`          | 等しくない   | `WHERE col != val`      | `.neq('status', 'done')`              |
| `.gt('col', val)`           | より大きい   | `WHERE col > val`       | `.gt('score', 80)`                    |
| `.lt('col', val)`           | より小さい   | `WHERE col < val`       | `.lt('score', 50)`                    |
| `.gte('col', val)`          | 以上         | `WHERE col >= val`      | `.gte('age', 18)`                     |
| `.lte('col', val)`          | 以下         | `WHERE col <= val`      | `.lte('age', 65)`                     |
| `.like('col', '%val%')`     | 部分一致     | `WHERE col LIKE`        | `.like('title', '%todo%')`            |
| `.ilike('col', '%val%')`    | 大文字小文字無視の部分一致 | `ILIKE`         | `.ilike('title', '%task%')`           |
| `.in('col', [a, b])`        | 配列に含まれる | `WHERE col IN (...)`  | `.in('status', ['new', 'done'])`      |

---

## 📦 結果制御（ソート・件数・ページング）

| メソッド                                   | 説明                  | 使用例                                               |
|--------------------------------------------|-----------------------|------------------------------------------------------|
| `.order('col', { ascending: true })`       | 昇順／降順ソート     | `.order('created_at', { ascending: false })`        |
| `.limit(n)`                                | 取得件数を制限       | `.limit(10)`                                        |
| `.range(from, to)`                         | 範囲指定（offset, limit） | `.range(0, 9)` → 最初の10件を取得             |
🌱 生成AIの環境負荷と持続可能な未来：グリーンコンピューティングの最前線から見る解決策 🌍






### 1. **生成AIの「隠されたコスト」**  
例えば、大規模言語モデル（LLM）の訓練には、**数千メガワット時の電力**が消費され、数百トンものCO₂が排出されます。これは、自動車が地球を何周もするのに相当する環境負荷です。しかし、問題は訓練だけではありません。推論（Inference）フェーズでは、毎日何億ものユーザーリクエストを処理するため、データセンターのエネルギー需要が急増しています。  

### 2. **業界の挑戦：効率化と再生可能エネルギー**  
では、以下の戦略で環境負荷を削減しています：  
- **TPU（Tensor Processing Unit）の最適化**：AIワークロード専用のチップで、エネルギー効率を10倍向上。  
- **Carbon-Aware Computing**：データセンターの電力源をリアルタイムで調整し、再生可能エネルギー比率が高い地域/時間帯に計算リソースをシフト。  
- **モデル圧縮技術**（例：Distillation, Quantization）：小さくても高性能なモデルを設計し、計算リソースを削減。  

### 3. **現場で実践する「責任あるAI開発」**  
プロジェクトのライフサイクル全体で環境影響を評価する「**AI Sustainability Assessment**」を導入しています。具体的には：  
- **トレードオフの可視化**：精度 vs. エネルギー消費のバランスを数値化。  
- **カーボンフットプリントの追跡**：ツール（例：CloudのCarbon Footprintダッシュボード）でCO₂排出量をモニタリング。  

### 4. **未来への道：協業とイノベーション**  
個々の企業の努力だけでなく、業界全体の連携が不可欠です。例えば、**「MLCommons」**では、AIモデルのエネルギー効率基準を策定し、ベンチマークを公開しています。また、オープンソースコミュニティと共に、軽量モデル（例：TinyML）の普及を推進しています。  



---  

この記事が、技術の進化と地球環境のバランスを考えるきっかけになれば幸いです。皆さんの現場での取り組みや意見もぜひ教えてください！ 🚀
🚀 **「AIチップ革命：低消費電力で切り拓くサステナブルな生成AIの未来





## 🌱 生成AIの環境負荷シリーズ Vol.9  
# AIチップ革命：低消費電力で切り拓くサステナブルな生成AIの未来

---

## 1. はじめに

生成AIは、画像生成、言語生成、音声合成などの分野で飛躍的な進化を遂げていますが、その一方で**エネルギー消費の爆発的増加**が社会的課題となっています。特に、大規模モデルの訓練には膨大な電力が必要であり、従来型のGPUベースのアーキテクチャには限界が見えてきました。

その課題を乗り越える鍵となるのが「**低消費電力AIチップ**」です。私自身、のTPU開発チームと連携しながら行った実務経験をもとに、技術的背景、産業応用、今後の展望について深掘りしていきます。

---

## 2. 生成AIが抱える消費電力問題

- GPT-3の学習には**350GWh以上**の電力が必要とされており、これは中規模都市の年間消費量に匹敵します。
- モデルが大規模化すればするほど、**熱処理・冷却・通信**を含むインフラ全体の負荷も増加。

この状況を放置すると、AI技術の発展が**サステナビリティの敵**となりかねません。

---

## 3. なぜ「低消費電力チップ」が鍵となるのか？

### ✅ **並列処理＋最適化アーキテクチャ**
AIチップ（ASICやFPGA、TPU）は、従来のGPUと比べて特定用途に特化した設計が可能なため、**同等の性能でより低い電力消費**を実現します。

### ✅ **オンデバイス推論とエッジAIの可能性**
例えばスマートフォンやIoT端末に搭載された**エッジAIチップ**は、クラウドとの通信を最小化し、リアルタイム処理と電力効率を両立します。

---

## 4. 実務で見たチップ開発の現場： TPUの進化

### 🔧 **TPU v2 → v4への進化ポイント**
- **演算密度の向上（FLOPS/W）**
- **水冷システムの導入による熱効率化**
- **スパース演算の最適化**：非ゼロ値だけを効率的に扱うことで、不要な処理を削減

これにより、TPU v4は同等の処理能力で**約半分のエネルギー消費**を達成しています。

---

## 5. 他企業の取り組み：産業応用と動向

### 🔬 **NVIDIA Grace Hopper Superchip**
- AI/高性能コンピューティング用に開発されたハイブリッド設計
- **低電力・高帯域**を実現し、生成AIのインフラに導入が進行中

### 📱 **Apple Neural Engine（ANE）**
- iPhoneやMacに搭載される専用AIチップ
- オンデバイスでのNLPや画像認識に使用され、ユーザー体験と省電力性を両立

---

## 6. チップ設計で求められる技術革新

### 🔄 モデル・ハードウェア協調設計（Co-Design）
モデルが軽量であっても、チップとの相性が悪ければエネルギー効率は下がります。Co-Designの実践により、「**AIモデルがハードを理解し、ハードがモデルに最適化される**」時代が訪れています。

### ⚙️ スパースモデリング & 混合精度演算（Mixed Precision）
- 計算不要な部分をスキップ（スパース性）
- 半精度浮動小数点（FP16）や整数（INT8）を活用し、計算資源を大幅に削減

---

## 7. 今後の展望と課題

### 🌍 **エネルギーラベル付きAI時代へ？**
AI製品においても、冷蔵庫や家電のように「**エネルギー効率ラベル**」が付与され、開発者やユーザーが環境意識を持つインセンティブが強まる可能性があります。

### ⏳ **量子コンピューティングとの融合**
低消費電力かつ超並列計算が可能な量子コンピュータとAIチップのハイブリッド化が、今後のゲームチェンジャーとなるかもしれません。

---

## 8. まとめ

低消費電力AIチップの開発は、生成AIが「エネルギー食いのモンスター」から「地球にやさしい知能」へ進化するための鍵です。私たちエンジニアが取るべき次の一歩は、モデル設計だけでなく、**ハードウェアとの協調と最適化**に積極的に取り組むことです。

💬 **あなたが注目しているAIチップ技術や、省電力化のアイディアはありますか？ コメントでぜひ共有してください！**
Vue + Supabase で作る超簡易ToDoアプリ

Vue.jsとSupabaseを組み合わせて、シンプルなToDoアプリを作成する方法を解説します。このアプリでは、タスクの表示・追加・削除が可能です。

---

## 1. Supabaseプロジェクトの作成

1. [Supabase公式サイト](https://supabase.com/)にアクセスし、アカウントを作成またはログイン
2. 新しいプロジェクトを作成（DB名、パスワード、リージョンを設定）
3. プロジェクト作成後、「Settings」→「API」から**Project URL**と**anonキー**を取得

※ SupabaseはFirebaseのようなBaaS（Backend as a Service）で、認証・DB・ストレージなどが簡単に使えるクラウドサービスです。

---

## 2. データベーステーブルの作成

SupabaseのSQLエディタで以下を実行、もしくはGUIの「Table Editor」から手動でカラムを追加してもOKです

```sql
create table todos (
  id serial primary key,
  title text not null,
  created_at timestamp with time zone default now()
);
```

- `id`：自動で連番が振られる主キー
- `title`：タスクの名前（必須）
- `created_at`：登録日時（自動で現在時刻が入る）

---

## 3. Vueプロジェクトのセットアップ

```bash
npm create vite@latest supabase-todo --template vue
cd supabase-todo
npm install
npm install @supabase/supabase-js
```

`.env` ファイルをプロジェクト直下に作成

```env
VITE_SUPABASE_URL=https://your-project.supabase.co
VITE_SUPABASE_ANON_KEY=your-anon-key
```

- Viteでは環境変数を使うとき、必ず `VITE_` プレフィックスを付ける必要があります。

`src/supabase.js` を作成

```js
import { createClient } from '@supabase/supabase-js';

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL;
const supabaseAnonKey = import.meta.env.VITE_SUPABASE_ANON_KEY;

export const supabase = createClient(supabaseUrl, supabaseAnonKey);
```

- `createClient`関数でSupabaseと通信するためのクライアントを作成します。

---

## 4. アプリケーションの実装

`App.vue` を以下のように編集

```vue
<template>
  <div>
    <h1>📋 My ToDo List</h1>
    <ul>
      <li v-for="todo in todos" :key="todo.id">
        - {{ todo.title }}
        <button @click="deleteTodo(todo.id)">削除</button>
      </li>
    </ul>
    <input v-model="newTask" placeholder="新しいタスクを入力する" />
    <button @click="addTodo">追加</button>
  </div>
</template>

<script setup>
import { ref, onMounted } from 'vue';
import { supabase } from './supabase';

const todos = ref([]);
const newTask = ref('');

// DBからタスクを取得
const fetchTodos = async () => {
  const { data, error } = await supabase
    .from('todos')
    .select('*')
    .order('created_at', { ascending: false });
  if (!error) {
    todos.value = data;
  }
};

// タスクを追加
const addTodo = async () => {
  if (newTask.value.trim() === '') return;
  const { error } = await supabase
    .from('todos')
    .insert([{ title: newTask.value }]);
  if (!error) {
    newTask.value = '';
    fetchTodos();
  }
};

// タスクを削除
const deleteTodo = async (id) => {
  const { error } = await supabase
    .from('todos')
    .delete()
    .eq('id', id);
  if (!error) {
    fetchTodos();
  }
};

onMounted(fetchTodos); // 初期表示でタスクを読み込み
</script>
```

- `ref`を使ってリアクティブな変数（todos, newTask）を定義
- `onMounted`で初回マウント時にデータを取得
- Supabaseの`.from('todos')`でDBアクセス
- `delete()`でIDに一致するタスクを削除可能に

---

## 5. アプリケーションの起動

```bash
npm run dev
```

ブラウザで `http://localhost:5173` にアクセスすると、ToDoアプリが表示されます。
【用語解説】フッキング（Hooking）とは・・・？

### 概要
フッキングとは、コンピューターの関数呼び出しやイベント、メッセージを補足して監視・変更する処理。

主な内容：
・フックプロシージャはプログラムでフッキングを行う機能
・APIフッキングはWindows API処理を補足・変更する手法
・セキュリティ製品も悪意あるコード検出にこの技術を仕様
悪用事例として、マルウェアやルートキットがフッキングを使用して：

キー入力の捕捉（キーロガー）
認証情報の窃取
システム内での自身の隠蔽




### 参考文献（2025年4月10日）

https://www.sompocybersecurity.com/column/glossary/hooking
AutoHotkey(ahk)でレイヤーキー的なことをする

### 自作キーボードのレイヤーキーのように、単推しと長押しで機能を分けたい方へ

以下のように個別に設定してあげることで実現できる。
ただし、v2でのみ動作を確認している。
ただし（2回目）、ちょっと不安定。
```ahk
sc07B::sc07B ; muhenkan
sc07B & k::Up
sc07B & j::Down
sc07B & h::Left
sc07B & l::Right
```
特定のユーザーだけ Power Automate を使用不可にしたい。

結論、Microsoft Entra 管理センターで、アプリケーション「Microsoft Flow」を条件付きアクセスポリシーでブロックすればよい。

![スクリーンショット 2025-04-11 003801.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2629955/784bb0e0-d766-4adf-b5c9-91caa507d722.png)

なおカスタムのポリシーを有効化するためには、事前に「セキュリティの既定値群」を無効化する必要がある。
https://learn.microsoft.com/ja-jp/entra/fundamentals/security-defaults

「Microsoft Flow」へのアクセスをブロックされたユーザーは、Power Automate へログインできなくなる。

![スクリーンショット 2025-04-11 002820.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2629955/e4731525-4208-4cae-a38e-6dc30c7d39ad.png)
![スクリーンショット 2025-04-11 002844.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2629955/947cc9b5-adce-49b4-9ac8-e4fea413809e.png)
Primergyサーバーのレール対応がわかりにくい問題について


## primergyのレールの対応がわからない

ある日せっかくサーバーラックを家にお出迎えしたのでラックマウントレールを使ってサーバーをラッキングしようと思っていました。
さすがに最新モデルは手が出せないため、中古のPrimergy RX2520M1を購入して活用しています。

そんな中、サーバーラックもあるしどうせならレールを使ってラッキングしたい、と思い立ちました。
が、レールを購入しようとした際、型番を調べても情報が見つからず、とても苦労しました。

例えばこれ
![PXL_20250409_012815896.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3326777/e6530749-ed86-4570-a2cc-4f1e157b3eae.jpeg)

このレールは間違えて買ったRX2510M1,M2に対応しているものです。
残念なことにこれはRX2520M1と互換性がなく、ラッキングできませんでした。
画像中の`A3C40174940`を検索してみてもオークションなど中古の販売ページがヒットするだけで情報がかなり少ないです。
しかもこれ以外の情報がレールから見つけられませんでした。

そこで、間違えて購入したレールを基に、わかった範囲で対応の調べ方と対応するモデルをまとめておきます。

:::note warn
**注意**
これはあくまで私が調べた範囲でのお話です。
私と同じように互換性のないものを買ったりしないように気を付けてください。

:::

## レールの対応の調べ方

:::note info
ここでは、ヤフオクなどでPrimergyサーバーのレールを中古購入する場合を前提に説明します。

:::

まず購入する予定のレールが対応しているモデルの製品ページに向かいます。
中古であればおそらく1つくらいは対応しているモデルが明記されているでしょう。
今回はRX2520M1を例にします。
[Primergy RX2520 M1](https://jp.fujitsu.com/platform/server/primergy/product-navi/html/rx2520m1-201411-pyr2521zrz.html)
このページの少し下あたりにハードウェア一覧というPDFがあります。
これを使います。
おおよそ次のような表形式になっているはずです。

| 品名         | 型番  | RX25xxM1 | RX25xxM2 | ~~~ |
|--------------|-------|----------|----------|-----|
| レールキット | BR-04 | 〇       | -        | -   |
| レールキット | BR-05 | -        | 〇       | -   |

ここから目的のモデルに対応しているレールキットの型番をメモしておきます。
ちなみにRX2520M1の場合は`PY-RR05`と`PY-RR06`に対応していることがわかりました。

これを購入するレールの対応モデルと手元にあるサーバーのモデル両方で調べます。
同じレールキットが対応していれば互換性があるということです。
なので今回の`RX2520M1`の場合は`PY-RR05`と`PY-RR06`に互換性があるのでそれらに対応しているモデルを探します。

- RX200S7
- RX200S8
- RX300S7
- RX300S8
- RX100S7
- RX2540M2
- RX2540M4

調べた限りではこの辺りも対応しているはずです。

## あとがき

私は互換性のないラックを購入してしまいましたが、この記事を参考に同じ失敗を避けていただければ幸いです。
探してもラックの互換性のあるモデルを見つける方法がまったくわからなかったため、自分なりの調査結果をまとめました。
参考程度に役立ててもらえると嬉しいです。

今回は`RX200 S7`のレールを使って`RX2520 M1`をラッキングしました。
この組み合わせの場合は今のところきちんと使えています。
調べ方も何もわからず情報もほとんどなくという状況だったので同じ悩みを抱えている人の参考になれば幸いです。

皆さんもぜひ自宅サーバーに挑戦してみてください！
ライセンスを持ったユーザーが Power Automate の既定環境にアクセスすると、即フローの作成や編集、使用が可能になる。

Power Automate に初回アクセスした際のスクリーンショット。

![スクリーンショット 2025-04-10 235611.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2629955/4bf326fc-4340-4423-91a9-22f1299d0b49.png)

これによってユーザーが既定環境に登録され、以下のセキュリティロールが付与される。

Environment Maker
Basic User
VSCodeでワーキングディレクトリ内のgitリポジトリを無視する

VSCodeのワーキングディレクトリ内に重いgitリポジトリがあると、ソース管理機能の動作が遅くなってしまう場合があります。
自身で特に管理していない依存ライブラリなどでは、ソース管理機能を使用する必要がないことがほとんどです。
このとき、以下のような設定を追加することで重いgitリポジトリを無視し、動作を回復させることができます。
```.vscode/settings.json
{
    "git.ignoredRepositories": [
        "path/to/repository"
    ]
}
```
`path/to/repository`を無視したいgitリポジトリへの相対パスに置き換えることで設定できます。

### 参考
https://stackoverflow.com/questions/49325617/how-can-i-ignore-a-whole-git-repository-in-visual-studio-code
XSS入門：初心者でもわかる攻撃と防御のしくみ


# クロスサイトスクリプティング（XSS）とは   

クロスサイトスクリプティング（XSS）は、悪意のあるスクリプトがWebサイトに埋め込まれ、ユーザーのブラウザ上で実行されてしまう脆弱性です。主な原因はユーザーの入力値を適切にエスケープせず、HTMLに出力してしまうことにあります。

スクリプトとは、ブラウザ上で動作する簡易的なプログラムのことです。JavaScriptなどが該当し、フォームの自動補完やボタン操作など、Webページに動きを与えるために使われます。

## XSSによって起こる脅威  
XSSによって引き起こされる主な脅威や被害の具体例をまとめました。
Cookieが盗難されると、不正ログインが可能になるので特に気を付けたい脅威です。
|分類	|内容	|具体例|
|------|-------|--------|
|🎭 なりすまし|	セッションハイジャック、<br>ユーザーなりすまし|	Cookieの盗難・<br>セッショントークンの不正使用
|🕵️‍♂️ 情報漏洩|	ユーザーの個人情報・<br>内部情報の窃取|	フォーム内の入力値、<br>アカウント情報などの抜き取り
|:fish: フィッシング誘導	|偽フォーム・偽ページへの誘導|	ログインフォームを偽装し<br>ID/PWを盗む
|✍️ ページ改ざん|	表示内容の書き換え|	管理画面や掲示板を<br>偽の内容にすり替え
|🦠 マルウェア感染|	外部スクリプト経由での<br>攻撃コード配布|	Drive-by download や Cryptojacking など
|📤 不正リクエスト送信|	利用者の権限でAPIや<br>管理操作を実行	|勝手にメッセージ投稿、<br>購入処理、設定変更など
|📉 信用・ブランド失墜   |	ユーザーへの悪影響<br> → サービス離れ	|ユーザーからの信頼喪失、SNS炎上など

## XSSの種類

### 1. 反射型XSS（Reflected XSS）  
ユーザーがアクセスしたURLに含まれる悪意のあるスクリプトが、リクエストで一時的に送られたデータが、**サーバーに保存されずにそのまま画面に表示されて実行**されるタイプです。  

**特徴**  
- 攻撃は一度限りで、ページの再読み込みで消える  
- 入力された内容がそのままHTMLに埋め込まれるような箇所が狙われやすい  

**発生しやすい例**  
- 入力内容をそのままエラーメッセージとして表示  
- 検索フォームの検索語を結果ページに出力  
- URLパラメータをHTMLに表示  


### 2. 格納型XSS（Stored XSS）  
悪意のあるスクリプトが**サーバーに保存され、後から他のユーザーにそのまま表示されて実行**されるタイプです。被害が広範囲に及ぶ可能性があります。  

**特徴**  
- 攻撃コードが永続的に保存される  
- ページを開くたびに攻撃が実行される  

**発生しやすい例**  
- 掲示板やコメント機能  
- プロフィールや投稿内容の表示部分  
- ファイルアップロード時のメタ情報表示  



### 3. DOM型XSS（DOM-based XSS）  
サーバー側ではなく、**ブラウザ上のJavaScriptがDOMを介して直接スクリプトを実行してしまう**タイプです。  
DOM（Document Object Model）とは、HTMLやXMLを構成する要素をプログラム上で参照・操作するための仕組みです。

**特徴**  
- 攻撃の処理がすべてクライアント（ブラウザ）側で完結するため、検知しづらい
- スクリプトはURLのパラメータやハッシュ（`#`）から挿入される  


**発生しやすい例**  
- URLのクエリをそのままinnerHTMLに挿入  
- `document.write()`で動的にコンテンツを生成  



## XSSの対策  
XSSの主な対策をまとめました。
特に出力時の「エスケープ処理」は最も重要で有効な対策です。

### 1. 出力時のエスケープ処理  


すべてのユーザー入力を**HTML出力する前**に、コードして解釈されてしまう記号を表示用の文字列に変換する適切な**エスケープ処理**を施すことで悪意のあるスクリプトの実行を防ぐことができます。


#### エスケープにより、記号を変換
```:エスケープ前
<script>alert('XSS')</script>
```

```:エスケープ後
&lt;script&gt;alert(&#39;XSS&#39;)&lt;/script&gt;
```


| 文字 | エスケープ後 |
|------|---------------|
| &    | `&amp;`       |
| <    | `&lt;`        |
| >    | `&gt;`        |
| "    | `&quot;`      |
| '    | `&#039;`      |

### 2. XSS対策に有効なセキュリティHTTPレスポンスヘッダを使用する
- **Content-Security-Policy (CSP)**
インラインスクリプトの実行を防ぎ、悪意あるスクリプトの読み込みを制限できます。
```:例
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
```
- **X-Content-Type-Options**
レスポンスのMIMEタイプが予期しない形で解釈されるのを防止します。
```:例
X-Content-Type-Options: nosniff
```

### 3. CookieにHttpOnly属性を付与する
CookieをJavaScriptからアクセスできないように制限することができます。これにより、Cookieの盗難を防止できます。

```:例
Set-Cookie: id=stNeb; Expires=Thu, 10 Apr 2025 09:30:00 GMT; Secure; HttpOnly
```


### 4. Content-Typeと文字コードの明示  
HTTPレスポンスヘッダの`Content-Type`に文字コード（例：`charset=UTF-8`）を明記します。指定がない場合、ブラウザが誤った文字コード（例：UTF-7）で解釈し、意図しないスクリプト実行が発生する可能性があります。

```:例
Content-Type: text/html; charset=utf-8
```

## まとめ  

XSSは、ユーザーとWebアプリケーションの信頼関係を悪用する非常に危険な攻撃です。特に、入力値を画面に出力する処理がある場合は状況に応じて**適切にエスケープ処理を行う**ことが重要です。フロントエンド・バックエンドの両面からしっかりと対策を行い、安全なWebアプリケーションを構築していきましょう。
Rust を Jupyter で動かす（WSL+VSCode）

# 前提
* Windows11
* WSL および VSCode をインストール済み
* Rust は未インストール

本記事の手順により下記の画像のような構築が構築される．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/a5e852f3-2cf5-4e99-86ae-75e64dabd1d1.png)

# Rust のインストール
1. WSL 内で下記のコマンドを実行し，確認画面で Enter で Rust をインストールする
    ```bash
    $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
    ```
    初期設定では Rust に関連するツールが `~/.cargo/bin` にインストールされる．
2. `~/.cargo/bin` を PATH に追加する（または WSL を再起動する）
    ```bash
    $ source ~/.cargo/env
    ```
3. Rust がインストールされていることを確認する
    ```bash
    $ rustc --version
    $ cargo --version
    ```
4. gcc コンパイラをインストールする（Rust のコンパイルに必要）
    ```bash
    $ sudo apt install build-essential
    ```
    ※ gcc コンパイラがインストールされていないと，Rust のコンパイル時に下記のようなエラーが発生する．
    ```bash
    error: linker `cc` not found
    ```

### 参考
* Rust をインストール - Rustプログラミング言語（公式ドキュメント）
    * https://www.rust-lang.org/ja/tools/install
* Rustはじめました　WSL2にRustを入れてHello Worldまで - 好きなことを書かせて
    * https://nakamka.hatenablog.com/entry/2024/02/24/121709

# Jupyter で Rust を使えるようにする
1. `evcxr_jupyter` をインストールする
    ```bash
    $ cargo install evcxr_jupyter
    ```
    `cargo` は Rust のパッケージ管理ツール（Python の pip のようなもの？）で，`evcxr_jupyter` は Rust 用の Jupyter Kernel です．私の環境ではインストールに５分程度かかりました．
2. `evcxr_jupyter` を `Jupyter` に登録する
    ```bash
    $ evcxr_jupyter --install
    ```
3. 適当なディレクトリを VSCode + WSL で開く
    ```bash
    $ mkdir ./rust-jupyter-test
    $ code ./rust-jupyter-test
    ```
4. VSCode の拡張機能 `Jupyter` をインストールする
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/b03b1d70-4de6-4d26-b3ce-f78f4ea16267.png)
5. 拡張子が `ipynb` の適当な名前のファイルを作成する
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/873a30ad-078c-4743-94a8-bee961f91daa.png)
6. `ipynb` ファイルを開き，Rust のカーネルを設定する
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/a8ac1a51-66c6-45df-b4be-c98755b1a472.png)
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/5f27ec5e-6293-4375-b9d1-828e9a424cce.png)
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/474d6a23-0a1f-4900-8982-7a023e4458d6.png)
7. コードを実行
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/324504/a5e852f3-2cf5-4e99-86ae-75e64dabd1d1.png)

### 参考
* Jupyter in VSCodeをRustでやってみた
    * https://zenn.dev/tipstar0125/articles/33893c93aaca17
Mendixの実装方法に関する情報をどこで仕入れるか

Mendixはシーメンス社が開発したローコード開発プラットフォームです。
プログラム経験がある方であれば比較的容易に、また経験がない方も少し学べば、立派に動くWebアプリケーションを作成することができます。

しかし、まだ日本であまり馴染みのないMendix。
個人で開発して遊ぶ場合や、仕事で使用する場合は、どこから有益に情報を得るべきか難しいところがあります。

そこで今回は、私が業務でMendixを使用していて実装で悩んだときは、
プロジェクト内で相談や検討をする以外にどこで情報を仕入れているか書きたいと思います。
※英語のドキュメントが中心です

## １：Mendix Community
Mendix公式が提供している、利用者同士で質問を投げ合うコミュニティの場です。

https://community.mendix.com/p/questions

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125006/6f1ab1db-b5bb-4413-a3cb-2c455828b1b4.png)

こちらで上手く検索していただくと、答えにたどりつけることがあるかもしれません。

:::note info
コツ
・英語でキーワードを入力
・長すぎない
:::

例えば以下のような感じです。

stringの文字列を切り取るJavaAction名で検索してみました。
Yahoo知恵袋みたいなイメージですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125006/308cf34e-bae9-4f86-81b2-9167b9024636.png)


## ２：Mendix 公式ドキュメント
Mendixの公式ドキュメントです。意外と情報豊富ですので有用です。
変な日本語訳になるときもあるため、適宜英語、適宜翻訳で情報を探すとよいかと思います。

mendix string util などで検索いただくと、公式Docsページに行くことが可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125006/eab4cfe5-2bbb-4368-b036-88b965037073.png)

用法も載っているため、ためになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125006/48e9eddb-e60d-4a15-94b5-605493f3595d.png)


## ３：Youtube
英語にある程度抵抗の無い方は、youtubeでMendixについて検索していただくと
色々な動画があるため、参考になるかと思います。
個人の方だったりMendix公式のチャンネルだったりがあるので
ぜひ一度チェックしてみてください。


## おわりに
今回紹介したものは一例になります。
今後は私の方でもMendixについての記事をこのサイトで投稿していければと考えておりますので
よろしくお願いいたします！

お読みいただきありがとうございました。
Google AI Studio で配列の中に要素を指定したスキーマを作成

Google AI Studio の構造化出力を行うためのスキーマで、配列の中に要素を指定します。

# 手順

`object` 型の配列を作成して、Add nested property で要素を指定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32057/cd5b489d-5b31-4666-ab38-170c4f8bffbc.png)

`description` は Code Editor で入力します。

```json
{
  "type": "object",
  "properties": {
    "scenes": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "time": {
            "type": "string",
            "description": "The timestamp indicating when the scene occurs in the video ('MM:SS')."
          },
          "visuals": {
            "type": "string",
            "description": "A description or analysis of the visual content of the scene."
          },
          "audio": {
            "type": "string",
            "description": "A transcription of the audio content of the scene."
          }
        },
        "required": [
          "time",
          "visuals",
          "audio"
        ]
      },
      "description": "An array containing individual scenes extracted from the video."
    }
  },
  "required": [
    "scenes"
  ]
}
```

次のような出力を想定しています。

```json:出力例
{
  "segments": [
    { "time": "00:00", "visuals": "forest", "audio": "Hello!" },
    { "time": "00:05", "visuals": "sky", "audio": "How are you?" }
  ]
}
```

# 応用例

YouTube の URL を貼り付けると動画が認識されるので、上のスキーマで内容が取得できます。

- https://www.youtube.com/watch?v=n17NFYBBjXY

```json:出力例
{
  "scenes": [
    {
      "time": "00:00",
      "visuals": "Two silhouetted figures stand amidst smoke in front of a bright surface. Text at the top of the image reads 'Albert Camus \"The Fall\"'. Below this, the same title appears in Japanese. At the bottom, credits read: 'Conversation: NotebookLM', 'Director: Gemini 1.5 Flash', and 'Image: Stable Diffusion 3'.",
      "audio": " "
    },
    {
      "time": "00:04",
      "visuals": "A street scene in Amsterdam, where the road is wet from a recent rain, reflecting the lights of the buildings and street lamps. Above the image, text says 'Okay, so you know how sometimes you read something and it just kind of of sticks with you?' and below, the translation of this text in Japanese is displayed with the explanation of \"Sticks with you\".",
      "audio": "Okay, so you know how sometimes you read something and it just kind of sticks with you?"
    },
（中略）
    {
      "time": "08:56",
      "visuals": "A starry sky.",
      "audio": "And remember, sometimes the most important questions are the ones that don't have easy answers."
    }
  ]
}
```

# 関連記事

動画解析スキーマの具体的な利用方法は、以下の記事を参照してください。

https://qiita.com/7shi/items/7578f1710e76770f1af1

応用例で扱った動画は、以下の手法で作成しました。

https://qiita.com/7shi/items/04962cf58e172da662c1
playwright-mcp を使ってSalesforce のリリースノートから欲しい情報を自動で抽出させる

## 概要

Salesforce のメジャーアップデートは年3回ありますが、その度に大量のリリースノートから影響がありそうな情報を抽出する作業がありますよね、、、（まさに砂漠からダイヤを探すみたいな）。私の以前勤めていた受託企業では、リリースノートの影響調査といい立て付けで、リリースノートを読むための工数などを割いていたプロジェクトもありましたね。
そんな作業をいつか滅したいと思っていましたが、ついにその可能性が到来したので紹介したいと思います。（リリース内容を見たくないとかではなく、時間は有限なのでなるべく自身に必要な情報を効率的に自動で集めれるようにしたいという願望です）
今回は、[playwright-mcp](https://github.com/microsoft/playwright-mcp)を使って、リリースノートから欲しい情報を自動で抽出してくれるエージェントを実装したいと思います。

## 想定読者

- playwright mcp に興味ある方
- Salesforce エンジニアの方
- リリースノートに一から全て目を通すのが厳しいが必要な情報は欲しいという私みたいな怠惰な方


## MCPについて
- 私はそんなに詳しくないです。
- 正直最近初めて触ったのでまだまだ初心者です。
- 詳しく知りたい方は、[こちらの資料](https://speakerdeck.com/minorun365/yasasiimcpru-men)が非常に参考になります。読めばなんとなくわかった気になれます。

## 結論どういうことを実現しようとしているのか

- Salesforce のリリースノートからサービスのルーティングに関する記事を検索させて要約文を生成する
![Playwright-mcp.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/209b2ab0-352e-4e2d-a77e-a4826aa86914.gif)


## 設定方法

### 前提
- vscodeを使用している(v1.99以降)
- GitHub Copilotを使用している

- [公式](https://github.com/microsoft/playwright-mcp)を参考にしていく
  - vscode を開く
  - `chat.agent.enabled`を有効化する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/e3a06fd6-db52-4a54-a130-1d916c31f0da.png)
  - `playwright-mcp` をインストールする
      ```bash
      npm install -g @playwright/mcp
      ```
  - mcp サーバーの設定を記載する
  ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/eb53698e-3e11-458b-b4eb-46a515f59e02.png)

  - `起動` を押す
  - `実行中`となっていればOK
  ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/24c5c67a-edb0-45dd-a058-cb7853869a7a.png)
  - エージェント画面を開く
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/b337e771-cce8-4cfd-999b-40470bc03a2e.png)
 - メッセージを入力する(下記のURLはSalesforce spring25 のリリースノートページです)
 ```text
https://help.salesforce.com/s/articleView?id=release-notes.salesforce_release_notes.htm&release=254&type=5
上記のSalesforceのリリースノートからサービス関連のルーティングについての情報を探して、リリース内容を端的に要約して欲しい。要約分はなるべく短くしてくれると助かる。
 ```
### 実際の回答
```text
Salesforce Spring '25 サービスルーティングの主な更新点
Spring '25リリースでは、サービスルーティングに関する以下の主要な機能が追加されています：

ワークアイテムの再割り当て拡張 - より多くのタイプのワークを別のエージェントに再割り当てできるようになり、柔軟なワークフロー管理が可能に

Agentforceによるワークフォース効率化 - AIを活用したエージェントアシスタントにより、サービス担当者の作業効率が向上

より多くのフロータイプでのアクション実行 - 様々なフロータイプからのアクション実行をサポート、プロセスの自動化強化

Omni-Channelサイドバーの生産性向上 - サービス担当者の作業効率を高める機能強化

音声通話のOmni-Channelルーティング（パイロット） - 他のチャネルと一緒に音声通話を単一のシステムでルーティングできる統合機能を試験提供

音声チャネルでのステータスベース容量管理（ベータ） - エージェントの現在のステータスに基づいた容量管理機能を音声チャネルにも拡張

これらの更新により、サービスチームはより効率的なワーク割り当てが可能になり、AIによる作業支援とチャネル間の統合されたルーティングが強化されています。特に音声チャネルを他のチャネルと統合するOmni-Channelルーティングが注目される機能となっています。
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531653/e0a9e3d0-735e-4f4e-bc05-617a48b1714c.png)

- ちゃんとブラウザの内容を読み取って生成してくれていますね。



## まとめ

どうでしょうか？まだ今はmcpの技術も出たばかりなので、すぐ「もうこれでOK！」にはなりませんが、少なくともすぐ近い未来に人力でリリースノートから必要な情報を探し出すみたいなことはなくなりそうと思いませんか？
セットアップから実際に検証するのに1時間もかからないでこんな簡単にできるってすごいですよね。
やらなければならない定量的な仕事をどんどんAIに任せてもっといろんな開発に着手したいなって思いました。
ミニバッチ学習の「バッチサイズ」、「イテレーション」、「エポック」の意味を明確にしたい

## バッチサイズ (Batch size)
そのまま和訳すると「一束」とかの意味になります。AIの関連用語として用いられる場合はミニバッチ学習で一度に入力するデータ数のことを表し、人間が調節するハイパーパラメータとなります。モデルのパラメータはバッチサイズ分のデータごとに更新されます。
## イテレーション (Iteration)
和訳すると「反復」、「繰り返し」といった意味になります。コンピュータサイエンスではこの言葉をよく耳にするかと思います。特にAI分野では、ミニバッチ学習での全トレーニングデータをバッチサイズで分割した数になり、バッチサイズが決まれば自動的に決定されます。
例として、
- 全トレーニングデータ: 1000
- バッチサイズ: 200

の場合、イテレーション数は
1000 ÷ 200 = 5
となります。
## エポック (Epoch)
意味は「時代」、「世」とかになります。ここで触れている用語の中では断トツでピンとこないですよね...。AI分野では学習において全トレーニングデータが学習に何回使われたかを表します。イテレーション数の学習が終わった時のエポック数は1となります。バッチサイズ同様ハイパーパラメータです。