OmniAICreator/Qiita-1.07M huggingface dataset:
Cloud Native Report 2024

# Cloud Native 2024: Approaching a Decade of Code, Cloud, and Change

CNCF 2024 年次調査報告書は、Cloud Native技術の進展とその影響を示されており、今後の技術戦略に関する洞察を提供しています。
(CNCF: Cloud Native Computing  Foundation、Linux Foundation傘下でCloud Native系OSSの推進を行っているFoundation)

https://www.cncf.io/reports/cncf-annual-survey-2024/

報告書の概要を簡単にまとめました。

### Cloud Native Adoption Continues to Grow（Cloud Nativeの採用が引き続き増加）

第1に、企業におけるアプリケーション開発とデプロイメント（AD&D）の活動が、より高いレベルのクラウドネイティブの使用に移行している傾向が見えます。

第2に、「Cloud Native初心者」とされる企業の割合も減少しています。これはCloud Nativeの普及が進んでいることを示しています。

第3に、Cloudの採用を見ると、企業の規模に関係なく同じ傾向を示しています。これは、Cloud Nativeが大規模な運営だけでなく、小規模を含めたすべての規模の組織にとっての利点であることを示しています。

地域別の傾向を見ると、ヨーロッパとアメリカ大陸がCloud Native技術の採用でリードしています。しかし、昨年は大きく遅れをとっていたアジア太平洋地域は、今年その差を縮め、84%の企業がAD&Dの一部、または多く、ほぼすべてがクラウドネイティブであると報告しています。

### Popular and Plentiful, Cloud Usage Stays Strong（人気があり豊富なクラウド使用は強さを維持）

Cloudは様々な形態で利用されています。データセンターとパブリッククラウドの利用状況を見ると、オンプレミスのデータセンターとパブリッククラウドの間で均等に分かれており、両者とも自己管理型に偏っています。

次に人気のある選択肢は、CSP管理のパブリッククラウドで、その後にオンプレミスのプライベートクラウドとハイブリッドクラウドが続きます。

### Container Use Grows, Powers Production（コンテナの使用が増加し、生産を支える）

驚くことではありませんが、2024年もコンテナは生産ツールとしての選択肢として引き続き人気です。

組織が使用するコンテナの平均数も2024年に増加し（27%増）、2,341に達しました。これは2023年の1,140からの増加です。Cloud Nativeと同様に、コンテナの成長の大部分は、コンテナが生産アプリで使用されるセグメントで発生しています。

##### コンテナ利用に関する課題
コンテナ利用に関する課題の種類は変化しています。2023年の調査では、セキュリティと複雑さが問題領域でした。しかし、2024年では、ほぼ半数が開発チームとの文化的な課題がコンテナ使用の最大の問題であると述べ、次いでCI/CDとトレーニング不足が続きました。セキュリティはその次に位置していますが、2023年よりも課題としては軽減されています。

以前は、セキュリティ、ネットワーキング、ストレージ、可観測性といった技術的な問題が主要な痛点でした。しかし、現在では、より成熟したCloud Nativeの実践が技術的な課題をより管理しやすくしており、組織は文化やプロセスの変革に焦点を当てることができるようになっています。

Platform EngineeringやGitOpsへの移行、あるいはモノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行など、これらの文化変革の取り組みは、クラウドネイティブの進化における論理的でありながら難しい次のステップであると、調査結果が示しています。

さらに言えば、中程度の経験を持つ調査回答者は、他のグループよりもコンテナの使用やデプロイに関する文化的な課題を指摘する傾向が圧倒的に高いです。

### Kubernetes Reach Continues to Expand（Kubernetesの普及が続く）

今やKubernetesの時代であると報告書はのべています。その根拠として、Kubernetesの生産利用率を上げています。さらに印象的なのは、生産利用率に加えてKubernetesを試験運用中または積極的に評価している組織を含めると、回答者の93%がKubernetesを何らかの形で使用しているということです。 

また、今年はNamespacesとHelmが主導しています。Namespacesは、2024年にクラウドネイティブおよびコンテナ化された環境内でアプリケーションを分離するための好ましいアプローチとして、特にKubernetesにおいてクラスターやラベルを上回って急速に普及しました。

一方、HelmはKubernetesの好ましいパッケージマネージャーとしての地位を確立し、利用率の成長を示しました。


### AI on Kubernetes: Still Getting Started（Kubernetes上のAI: まだ始まったばかり）

調査対象者のほぼ半数が現在Kubernetes上でAI/MLワークロードを実行していませんが、早期採用者はさまざまなタスクに取り組んでいます。


### CNCF Project Snapshots

KubernetesはGraduate Project Listのトップに位置して最も多く利用されています。

他のGraduate Projectのうち、5つはKubernetesに強く関連しています。これにはHelm、etcd、CoreDNS、Cert Manager、Argoが含まれます。

リストの上位にある他のプロジェクトは、監視とアラート（Prometheus）、コンテナランタイム（containerd）、ログ記録（Fluentd）、および汎用サービスメッシュ（Istio）に関連しています。
PostgreSQLでクエリの処理が遅い時にまずやってみること

## **はじめに**
PostgreSQLで実行したクエリが遅い場合に、まず実施してみる対応をまとめます。

## **利用場面**
- SQLの実行が遅い
- データベースの作成・参照処理が遅い

## **環境**
- **PostgreSQL:** 15.8
※　この先コマンドが変わったりする可能性もあるため、バージョンも記載します。 
---
## **作業内容**

### **1. バキューム**
#### **DB全体のバキューム**
```sql
VACUUM FULL VERBOSE;
```
※ `VERBOSE`  を付けることで進捗状況を確認可能。省略可。

#### **テーブル単位のバキューム**
```sql
VACUUM table テーブル名;
```
### **説明**
- **不要タプルの領域回収** → テーブルの最適化  
- **デッドタプルの影響防止** → パフォーマンス改善  
- **注意:** `FULL` を実行するとディスク使用量の約2倍の空き容量が必要

## **2. インデックス再構築**

### **DB全体でインデックス再構築**
```sql
REINDEX INDEX インデックス名 VERBOSE;
```
※ `VERBOSE`  を付けることで進捗状況を確認可能。省略可。
### **テーブル単位でインデックス再構築**
```sql
REINDEX TABLE テーブル名;
```
### **説明**
- **インデックスの断片化解消** → 検索パフォーマンス向上 
- `REINDEX` により最適な状態に再構築がされる

## **3. 統計情報更新**

### **DB全体の統計情報更新**
```sql
ANALYZE VERBOSE;
```
※ `VERBOSE`  を付けることで進捗状況を確認可能。省略可。
### **テーブル単位の統計情報更新**
```sql
ANALYZE テーブル名;
```
### **説明**
- **統計情報更新** → オプティマイザが正確な統計情報を基に実行計画 を作成できるようになる 
- データの追加、更新、削除が多いテーブル は定期的な `ANALYZE` を実施

## **4. 実行計画の確認**

ココまでで改善できない場合は、クエリの **実行計画** を確認し、ボトルネックを特定しクエリの最適化を計る

### **実行計画の取得**
```sql
EXPLAIN ANALYZE VERBOSE "SQL文";
```
※` VERBOSE` を付けることで更に詳細な情報を出力することが可能。省略可。
### **説明**
- `EXPLAIN ANALYZE` を使うと 実際の実行時間 を取得できる
- `Index Scan` や `Sequential Scan` などインデックスを活用できているか、また、`結合方式`などを分析することが出来る
- 遅い部分を把握したうえで、`インデックスの追加` や `クエリの最適化` を検討を行う

## **5. まとめ**
PostgreSQLは、バージョンが変更されると **オプティマイザーの動作** が大きく変わることがあります。 そのため、これまで遅延なく動作していたクエリが **バージョンアップ後に遅延** するケースが発生することがあります。

このような場合は、以下の順序で対応すると効果があることあるため、まずはやってみても良いかもしれないです。
**バキューム (`VACUUM FULL`)**
**インデックス再構築 (`REINDEX`)**
**統計情報更新 (`ANALYZE`)**
**実行計画確認 (`EXPLAIN ANALYZE`)** 

もし、SQL文がわからない場合でも、実行計画（EXPLAIN ANALYZE） の結果を有識者へ展開することで何かのヒントを得ることはでき、今後のアクションなども見えてくるかと思います。
windows11で、sketchup6 その54

# 概要
windows11に、sketchup6を入れてみた。
rubyで、3Dを書く。
練習問題、やってみた。

# 練習問題
rubyスクリプトでコンポーネントを作れ。


# 写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/0ba50ffa-aef7-424f-9277-53edfb298099.png)

# サンプルコード

```

def create_compo
	cube = Sketchup.active_model.definitions.add("Mycompo")
	unit = 10
	p = Array.new
	p[0] = ORIGIN
	p[1] = [unit, 0, 0]
	p[2] = [unit, unit, 0]
	p[3] = [0, unit, 0]
	face = cube.entities.add_face(p)
	face.reverse! if face.normal.z < 0
	face.pushpull(unit)
	trans = Geom::Transformation.new([5, 5, 5])
	Sketchup.active_model.active_entities.add_instance(cube, trans)
end



```

以上。
uArm Metal 指南書　~とりあえず動くところまで~

## パソコンとの接続方法

- **microUSBケーブル**  
  uArm Metal の背面にある microUSB ポートとパソコンを接続します。
- **5VAC アダプタ**  
  電源アダプタ（5VAC）を uArm Metal の電源ジャックに接続



## pyArm をインストール

1. GitHub からソースをクローンまたは ZIP をダウンロード  
   ```bash
   git clone https://github.com/uArm-Developer/pyuarm.git ~/Downloads/pyuarm-dev


## インタプリタでの動作確認
   ```python
   >>> import pyuarm
>>> print(pyuarm.__version__)        # 例: 2.4.0.12
>>> from pyuarm import UArm, get_uarm
>>> arm = get_uarm()                 # 自動検出
>>> arm.connect()
>>> arm.set_position(150, 0, 50)     # X, Y, Z 移動
>>> arm.set_wrist(45)                # 手首サーボ 45°
>>> arm.set_pump(True)               # ポンプ ON
>>> arm.set_pump(False)              # ポンプ OFF
>>> pos = arm.get_position()         # 現在位置取得
>>> arm.disconnect()
```

## CLI ツール
   ```bash
   python -m pyuarm.tools.calibrate
   ```

##サンプルコード

   ```python

"""
move_uArm.py
"""

import sys
import time
from pyuarm import UArm, get_uarm

def main():
    arm = get_uarm()
    if arm is None:
        print("ERROR: uArm が見つかりません。")
        sys.exit(1)

    arm.connect()
    print(f"Connected: FW={arm.firmware_version}, HW={arm.hardware_version}")

    try:
        arm.set_position(200, 250, 150, wait=True)
        arm.set_wrist(45, wait=True)    
        arm.set_pump(True, wait=True)
        time.sleep(1)
        arm.set_pump(False, wait=True)
        arm.set_position(0, 150, 150, wait=True)

        x, y, z = arm.get_position()
        print(f"Pos: X={x:.1f}, Y={y:.1f}, Z={z:.1f}")
    finally:
        arm.disconnect()
        print("Disconnected.")

if __name__ == "__main__":
    main()

   ```
Google Maps APIの利用メモ

Google Maps APIの利用に気づいた点をメモする

## GOOGLE_MAPS_API_KEYの保護

- SPAのフロント側でgoogle maps apiを利用する場合、GOOGLE_MAPS_API_KEYがバレてしまう
- GOOGLE_MAPS_API_KEYがバレても悪用されないようにリファー制限機能がgoogleにより用意されている
- フロント側でそれのRest apiのURLを直接にfetchした場合はgoogleが介在できないので、リファー制限できない
- フロント側でリファラー制限を効かせるには、Rest apiをやめてMaps JavaScript API（ライブラリ）を利用する

## Maps JavaScript APIの利用例

- インストール

```
npm i @react-google-maps/api
```

- 利用例

```typescript
export const useGoogleMaps = () => {
  const { isLoaded } = useJsApiLoader({
    id: 'google-map-script',
    googleMapsApiKey: process.env.NEXT_PUBLIC_GOOGLE_MAPS_API_KEY!,
    language: 'ja',
    region: 'JP',
    libraries: ['geocoding'],
  });

  const isPostCodeExist = useCallback(
    (postCode: string): Promise<boolean | null> => {
      return new Promise((resolve) => {
        if (!isLoaded) return resolve(null);

        const geocoder = new google.maps.Geocoder();
        if (!geocoder) return resolve(null);

        geocoder.geocode({ address: postCode }, (results, status) => {
          if (status === google.maps.GeocoderStatus.OK) {
            resolve(results !== null && results.length > 0);
          } else if (status === google.maps.GeocoderStatus.ZERO_RESULTS) {
            // 存在しない
            resolve(false);
          } else {
            // 通信エラー
            resolve(null);
          }
        });
      });
    },
    [isLoaded],
  );

  return { isLoaded, isPostCodeExist };
};
```

## geocoder.geocodeメソッドの第２引数のコールバック関数を利用する理由

- ZERO_RESULTSを処理したいからである
- 第２引数のコールバック関数を利用せずtry catchでやる場合、errorからそれを判別し難い


## geocoder.geocodeメソッドの第２引数を利用しない場合の書き方

```typescript
const isPostCodeExist = useCallback(
    async (postCode: string) => {
      if (!isLoaded) return null;

      try {
        const geocoder = new google.maps.Geocoder();
        if (!geocoder) return null;

        const res = await geocoder.geocode({ address: postCode});
        return res.results.length > 0;
      } catch (error) {
        console.error(error);
        // ZERO_RESULTSの場合もerrorになるので、ここで片別するしかないが、やり難い
        // 本当の通信エラーと存在しないを区別できない
        return null;
      }
    },
    [isLoaded],
  );
  ```
【Java】JUnit + Mockitoを使った単体テストの書き方


## はじめに

Javaで開発を行う際、クラス単位・メソッド単位での **単体テスト（ユニットテスト）** は、品質を高めるために必要になってきます。
特に、Spring Bootなどで開発していると、`Service`クラスや`Repository`クラスなどに分離されていることが多く、**依存関係の切り離し**が重要になってきます。

そこで役立つのが、**Mockito**というライブラリです。
本記事では、サービスクラスの単体テストを行う際に、Mockitoを使ってリポジトリなどの依存クラスをモック化する方法について解説します。

---

## 使用ライブラリ・フレームワーク

- **JUnit 5**（テストフレームワーク）
- **Mockito**（モックライブラリ）

---

## なぜモックが必要なのか？

単体テストでは、**テスト対象のクラス以外の処理に依存せず、純粋にそのクラスの振る舞いのみを検証**することが理想です。

例えば、サービスクラスをテストしたい場合、本来はその中で呼ばれているリポジトリの動作も同時に動いてしまいます。
しかし、それではテストの範囲が広がりすぎて、**エラーの原因や関心所が分かりにくくなる**という問題があります。

そのため、リポジトリのような**他クラスの振る舞いをモック（仮の動作）に置き換える**ことで、テスト対象を明確に絞ることができます。

---

## 例：サービスクラスのテスト

以下は、ユーザーを検索するサービスクラスと、その単体テストの例です。

### 1. テスト対象のServiceクラス

```java
@Service
public class UserService {

    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User findUserById(Long id) {
        return userRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("User not found"));
    }
}
```

### 2. Mockitoを使ったテストクラス

```java
@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void testFindUserById_success() {
        // モックとして返したいUserデータを作成
        User mockUser = new User(1L, "Taro");

        // userRepository.findByIdが呼ばれたときにmockUserを返すよう設定
        when(userRepository.findById(1L)).thenReturn(Optional.of(mockUser));

        // 実際にServiceメソッドを呼ぶ
        User result = userService.findUserById(1L);

        // 結果を検証
        assertEquals("Taro", result.getName());
    }
}
```

---

## よく使うMockitoのメソッド

| メソッド | 説明 |
|---------|------|
| `@Mock` | モックとして使いたいクラスに付与 |
| `@InjectMocks` | モックを注入する対象に付与 |
| `when(...).thenReturn(...)` | 特定のメソッドが呼ばれたときの戻り値を定義 |
| `verify(...)` | メソッドの呼び出し回数などを検証 |
| `doThrow(...).when(...)` | 例外を投げるよう設定 |

---

## まとめ

- **JUnit + Mockito**を使えば、対象クラスだけに注目したテストが可能になる
- サービスクラスの単体テストでは、**リポジトリなどの依存クラスをモック化**するのが基本
- `when(...).thenReturn(...)` を使って、**リポジトリの戻り値を自由に設定**できる

---

## おわりに

単体テストを丁寧に書くことで、新規開発のバグの検知につながったり、将来的な修正の安心感にもつながります。
JUnit + Mockitoをしっかり使いこなして、堅牢なコードを目指しましょう。

---
CreateJS(Animate CC)でタブやアプリ移動後のフリーズ解消方法

久しぶりに有益なスクリプトを見つけたので共有します。

問題となっていたのは結構複雑なスクリプトやアニメーションをCreateJSのHTML5でブラウザ上で動作させている時。タブを移動したり、他のアプリに移動して戻ってくるとフリーズする現象。

短時間ならフリーズしないのに長時間だとフリーズしていました。

createjs.Ticker.paused = trueとかでTickerを止めたりしてもだめ。

この問題についてChatGPTと解決方法を探していたのですが、結論としてはこれが原因かと思われます。

1.CreateJSの内部タイマーは「最後の tick の時間」を覚えてる
2.Ticker.paused = false で再開！
3.CreateJS：
「あれ？最後に動いたの何秒前？3分前！？……じゃあ**180秒分の処理まとめてやるわ！**💥」
4.結果：CPU100%超え／フリーズ確定


で、解決できたスクリプトは

CreateJS側がこちら

createjs.Ticker.timingMode = createjs.Ticker.RAF_SYNCHED;

//遅れた時間分の tick をまとめて実行しないようになる

読み込むHTML側のJSはこちら

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    console.log("🔕 タブ非表示：処理停止");
    createjs.Ticker.paused = true;
  } else {
    console.log("🔔 タブ復帰：処理再開");

    // 💥 ここがポイント！
    // 再開する前に「時間を今にリセット」
    createjs.Ticker._lastTime = createjs.Ticker._getTime();

    // 少し遅らせてから再開（ブラウザが整ってから）
    setTimeout(() => {
      createjs.Ticker.paused = false;
    }, 100); // 100msくらいが安全
  }
});


ChatGPT曰く以下が原因だそうです。

✅ なぜ _lastTime が効くのか？
CreateJSの内部でこんな計算してる：

delta = currentTime - _lastTime;
→ _lastTime が放置中のままだと、delta が数分分のミリ秒になる
→ そのぶんの「tickイベント」を一気に発生させる → 死ぬ

→ _lastTime = 今の時間 にすれば delta = 0 に近くなる → 1フレームから再スタートできる！

chatGPTがなかったら１００年くらい悩むところでした。
【ショートカットキー】クリップボードを拡張！「Win + V」が便利！

※一部python向けの内容が含まれますが、他の言語の方は飛ばして読んで下さい
## はじめに
　みなさんプログラミングをしているとコピー、ペーストを多用しますよね？今書いているファイルのみならず、過去に作ったプログラムや、ネット上からコピー、ペースト、コピー、ペースト....そんな生活を便利にしてくれるのが、タイトルのショートカットキーです
 
:::note warn
　このショートカットはWindows用のものです。Winキー無いと押せないですからね。Macの人はMaccyというものがあるらしいので、それを使うと良さそうです。
:::
## クリップボードとは？
　一応初心者向けに書いてるので、クリップボードについて話しておきます。そもそも`ctrl + c`でコピー、`ctrl + v` でペーストはOKですよね？（`ctrl + x`でカットもありますが）コピーした内容をペーストで貼り付けられるのは、このクリップボードに内容が保存されているからです。用は1個だけ物を入れておける箱みたいな感じですね。
### おまけ
　このクリップボードですが、pythonからもアクセスできます（というか多くの言語ではアクセスできるんじゃないでしょうか）。
```python
import subprocess
content = "hello world"
subprocess.run("clip", input=content, text=True)
```
クリップボードにコピーするだけなら標準ライブラリの`subprocess`でいけます。
ペーストがしたい場合には`pyperclip`と言う外部モジュールを使うので、コマンドプロンプトで`pip install pyperclip`する必要があります。
　これ以上は主題とズレるので、ここまでとさせていただきます。こんな風に自作でこの辺をいじろうとすると、なかなか面倒だというのが分かっていただければ十分です。
## とりあえず押してみよう！
　特に設定をいじらなくてもキーポードのWindowsマークとVを同時に押せば、もう下の方からウィンドウが出てくるので、初回はここからオンにしてやりましょう。やることはそれだけです。手軽に便利なので、筆者は大学のPC使う時にも毎回やってます。
## 使い方
　オンにしたら、あとは普段通りにコピーとかペーストとかをやってみてください。そうすると、勝手にコピーした履歴が25個まで溜まります。これはもうメリットしかないです。25個のうち、お気に入りのものはピン留めしておきましょう。ピン留めしておけば、**シャットダウンしたとしても残ってくれます**。pygameのテンプレなど、よく使うコードをここに入れておくと便利です。
## それでも物足りない人は？
　25個じゃ足りないよ！と言う人は、先ほど述べたように`pyperclip`で、こちらとテキストファイルへの出力を組み合わせて、自分好みのツールを作っちゃってください。（筆者は逆に、自作していたら完全上位互換を見つけてしまったパターンです...）
## まとめ
Windowsユーザーは全員Win + Vを押せ！
## 最後に
　ここまで読んでくださり、ありがとうございます。今回はWin + Vをただ紹介するだけの記事でした。初心者向けの紹介記事ですが、サブのPCとしてWindowsを使い始めた人とか、今まで気づいていなかった人とかが、これを知る機会となれば嬉しいです。これをオンにしておくことにはメリットしかないと思うので、なぜデフォルトはオフなのか、なぜもっと存在をアピールしてこないのか、疑問に思います。
[ABC400] ABC 400(Atcoder Beginner Contest)のA~D(A,B,C,D)問題をPythonで解説(復習)

# [ABC400] ABC 400(Atcoder Beginner Contest)のA~D(A,B,C,D)問題をPythonで解説(復習)

# A問題
- とりあえず除算で `B` を求めてみる。
- 積算で長方形かどうかを確かめる。
```A.py
"""
<方針>
- とりあえず除算で `B` を求めてみる。
- 積算で長方形かどうかを確かめる。
"""
# 入力
A = int(input())

# B
B = 400 // A

# 確認して出力
if(A*B == 400):
  print(B)
else:
  print(-1)
```
- 順番に足していき、`10**9` を超えるかを逐一チェックする。
# B問題

```B.py
"""
<方針>
- 順番に足していき、`10**9` を超えるかを逐一チェックする。
"""
# 入力
N, M = map(int, input().split())


X = 0
# 足していく
for i in range(M+1):
  X += N**i
  # inf確認
  if(X > 10**9):
    print("inf")
    exit()

# 出力
print(X)
```

# C問題
## 方針
- `N` がデカすぎるので、線形探索は許されない。
- (aが奇数の) `N//2` or （aが偶数の）`N//4` 以下の平方数の数が答え。
- 平方数の数は、`X` 以下の最大の平方数を考えればよく、今回は二分探索でやってみる。
## 前提
- `C`問題あたりで，`TLE`になる人は，制約条件を見る癖をつけよう．
- `A`と`B`問題では，基本的に制約条件を見ずにやっても解ける．
- しかし，`C`問題以降では，制約条件を見ないと必ず`TLE`すると思っても良い．
- 詳しい話は私の[352回の記事](https://qiita.com/mattsunkun/items/837444254f03e6105922) の`C`問題の解説に記したので，是非参照してほしい．
```C.py
"""
<方針>
- `N` がデカすぎるので、線形探索は許されない。
- (aが奇数の) `N//2` or （aが偶数の）`N//4` 以下の平方数の数が答え。
- 平方数の数は、`X` 以下の最大の平方数を考えればよく、今回は二分探索でやってみる。
"""
# 入力
N = int(input())

# 答え
ans = 0
# 
for X in [N//2, N//4]:
  # 二分探索で最大の平方数を探す。
  ok = 0
  ng = X+1
  while abs(ok-ng) > 1:
    mid = (ok+ng)//2
    if(mid**2 <=X):
      ok = mid
    else:
      ng = mid
  
  # 答えを更新
  ans += (ok)

# 出力
print(ans)
```

# D問題
- 公式解説と一緒です。
```D.py
"""
<方針>
- 公式解説と一緒です。
"""
from collections import deque

INF = float("inf")

# 入力
H, W = map(int, input().split())
SS = [list(input()) for _ in range(H)]
A, B, C, D = map(lambda x: int(x) - 1, input().split())

V = [[INF for _ in range(W)] for _ in range(H)]

q = deque()
q.append([0, A, B])

# 0-1BFS
while q:
  c, i, j = q.popleft()
  
  if(V[i][j] != INF):
    continue
  V[i][j] = c
  
  # いくつ先を見るか
  for d in [1, 2]:
    # 上下左右
    for dy, dx in [
      [-1, 0], 
      [0, -1], 
      [+1, 0], 
      [0, +1], 
      ]:
        # 先を見る
        I = i + dy*d
        J = j + dx*d
        
        # 枠内
        if(0<=I<H and 0<=J<W):
          # まだ決定してない
          if(V[I][J] == INF):
            # 壁を破壊しなくて良い時
            if(
              # 一個先を見るとき、そこが道
              (d == 1 and SS[I][J] == ".") or 
              # ２個先を見るとき、そことその一個手前が道
              (d == 2 and SS[I][J] == SS[i+dy][j+dx] == ".")
              ):
                # 0
                q.appendleft([c, I, J])
            else:
                # 1
                q.append([c+1, I, J])

print(V[C][D])
```

# 補足
### 関係するリンク(参考文献など)
- [D問題の公式解説](https://atcoder.jp/contests/abc400/editorial/12630)
### 筆者について
- [Atcoderアカウント](https://atcoder.jp/users/mattsunkun)
- *今回も不参加のため，成績なし．*
- [解説で示したA問題の提出](https://atcoder.jp/contests/abc400/submissions/64602097)
- [解説で示したB問題の提出](https://atcoder.jp/contests/abc400/submissions/64602563)
- [解説で示したC問題の提出](https://atcoder.jp/contests/abc400/submissions/64602486)
- [解説で示したD問題の提出](https://atcoder.jp/contests/abc400/submissions/64609701)
### その他
- **間違いを含んでいる可能性があります．**
- 方針と言いつつ，方針ではない感想などを書いている可能性があります．
- A問題から解説がだんだん省略されます．
- コードに書かれている解説の文言と，その上に書いてある解説の文言を変えている場合があります．
### 最後に一言
- 初めての `0-1BFS`
[Go] インストール

## インストール方法

https://go.dev/doc/install

### Mac 環境

公式の `.pkg` インストーラは Go を以下の場所にインストールします：

```bash
/usr/local/go
```

さらに、このフォルダ内の実行ファイルパスが**自動的に**`$PATH` 環境変数に追加されます：

```bash
/usr/local/go/bin
```

インストールが完了したら、以下のコマンドを入力します：

```bash
which go
go version
```

以下のように表示されます：

```
/usr/local/go/bin/go
go version gox.y.z darwin/arm64
```

#### `.pkg` インストーラによる PATH の設定方法

.pkg インストーラは以下のファイルを作成します：

```bash
/etc/paths.d/go
```

ファイルの内容は以下のとおりです：

```bash
/usr/local/go/bin
```

Terminal 起動時に、

`/etc/paths` および `/etc/paths.d/*` の内容が自動的に読み込まれ、

パスが PATH の先頭に追加されます。

## 複数の Go バージョンをインストール

https://go.dev/doc/manage-install

```bash
go install golang.org/dl/go1.16.15@latest
```

インストール後、CLI ツールは `~/go/bin/go1.16.15` に保存されますが、

**自動的には**PATH に設定されません。

そのため、PATH を設定した後に：

```bash
echo 'export PATH="$HOME/go/bin:$PATH"' >> ~/.zprofile
```

以下のコマンドを実行してインストールします：

```bash
go1.16.15 download
```

インストール後には、次の 2 つのものが生成されます：

| 種類 | パス | 説明 |
|------|------|------|
| CLI ツール | `~/go/bin/go1.16.15` | このバージョン専用のコマンドエントリ |
| SDK | `~/sdk/go1.16.15` | 実行およびコンパイルを行う Go のコア |

次に、以下のコマンドを入力します：

```bash
which go1.16.15
go1.16.15 version
```

以下のように表示されます：

```
~/go/bin/go1.16.15
go version go1.16.15 darwin/arm64
```

## インストール方法のまとめ

```mermaid
flowchart TD
    A[Go のインストール] --> B{どの方法でインストール？}

    B --> C1[公式 .pkg インストール]
    B --> C2[go install golang.org/dl/goX.Y.Z@latest]

    %% .pkg インストールの流れ
    C1 --> D1[/usr/local/go が作成される/]
    D1 --> E1[/etc/paths.d/go が書き込まれる/]
    E1 --> F1[PATH に /usr/local/go/bin が自動追加]
    F1 --> G1[go コマンドが使用可能に]

    %% go install の流れ
    C2 --> D2[goX.Y.Z が ~/go/bin にインストールされる]
    D2 --> E2{~/go/bin は PATH に含まれている？}

    E2 -- 否 --> F2[手動で追加が必要]
    F2 --> G2[~/.zshrc または ~/.zprofile を編集しexport 'PATH=&quot;$HOME/go/bin:$PATH&quot;'を追加]
    G2 --> H2[source ~/.zshrc を実行するか Terminal を再起動]
    H2 --> I2[goX.Y.Z コマンドが使用可能に]

    E2 -- 是 --> I2
```
Azure VMの可用性を高める！サービスヒーリングと自動インスタンス修復を解説

# はじめに

こんにちは、あるいはこんばんは。

Azure Virtual Machine（VM、仮想マシン）は、多くの方が利用されているかと思います。Azureには、VMを自動で回復させる機能が複数あることをご存じでしょうか？これらの機能は、システムの可用性を維持するために非常に重要です。

今回は、その中でも代表的な以下の2つの機能について、その概要と注意点を解説します。

*   サービスヒーリング (Service Healing)
*   自動インスタンス修復 (Automatic Instance Repairs)

# サービスヒーリング (Service Healing)

**参考:** [Service healing: Automatic recovery of virtual machines - Azure Blog](https://azure.microsoft.com/ja-jp/blog/service-healing-auto-recovery-of-virtual-machines/)

サービスヒーリングは、Azure Virtual Machine（VM）自体が持つ自動回復機能です。Azureの基盤インフラストラクチャが、VMが稼働している**物理ホストサーバー**に障害（ハードウェア障害など）を検知した場合に、自動的に復旧処理（サービスヒーリング）を実行します。

ただし、この機能はあくまで物理ホストレベルの問題に対応するものであり、VM内部で動作するOSや**アプリケーションの障害を検知することはできません**。

回復方法としては、問題が発生した物理ホストサーバーの再起動、またはVMを正常な別の物理ホストサーバーへ移動する（ライブマイグレーションまたは再デプロイ）といったアクションが取られます。

この機能は、**すべてのVMサイズ、オファリング、リージョンで利用可能**であり、**デフォルトで有効**になっています。特別な設定は不要です。

# 自動インスタンス修復 (Automatic instance repairs for Azure Virtual Machine Scale Sets)

**参考:** [Azure Virtual Machine Scale Sets の自動インスタンス修復 - Azure Virtual Machine Scale Sets | Microsoft Learn](https://learn.microsoft.com/ja-jp/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs)

自動インスタンス修復は、**Azure Virtual Machine Scale Sets（VMSS、仮想マシンスケールセット）** で利用可能な機能です。

この機能を利用するには、VMSSで**アプリケーションの正常性監視**（Application Health Extensionなど）を有効にする必要があります。有効にすると、自動インスタンス修復機能が各VMインスタンスのアプリケーションの正常性状態を定期的に監視し、インスタンスが「**異常**」と判断された場合（例: ヘルスプローブに応答しない場合）に、あらかじめ構成された修復アクションを自動的に実行します。

アプリケーションの正常性監視では、例えばHTTP/HTTPSプロトコルを使用している場合、指定したパスに対してリクエストを送信し、ステータスコード200が返ってくるかどうかで正常性を判断します。

実行される修復アクションとしては、「**置換**」（インスタンスを削除して新しいインスタンスを作成、これが既定のアクション）、「**再イメージ化**」（OSディスクを再イメージ化）、「**再起動**」のいずれかを構成できます。

# 共存時の注意点

サービスヒーリングはデフォルトで有効であり、自動インスタンス修復はVMSSで明示的に有効化するため、両方の機能が同時に動作する状況はあり得ます。

両機能が共存する場合、意図しない動作が発生する可能性があるため、以下のシナリオを理解しておくことが重要です。

1.  **サービスヒーリングの発生:** サービスヒーリングが物理ホストの障害を検知し、その上で稼働しているVMSSのインスタンス（インスタンスAとします）の再起動または別ホストへの移動を開始します。
2.  **アプリケーションの一時停止:** インスタンスAの再起動中や移動処理中は、その上で動作しているアプリケーションは一時的に応答できなくなります。
3.  **自動インスタンス修復の誤検知:** VMSSの自動インスタンス修復機能が、この一時的なアプリケーションの無応答状態を「異常」と判断し、設定された修復アクション（例: インスタンスの置換）を開始してしまう可能性があります。

つまり、自動インスタンス修復による修復アクションが実行された場合、それが本当にアプリケーション自体の問題によるものなのか、あるいはサービスヒーリングによる影響（一時的な無応答）によるものなのか、**判別が難しいケースがある**ということです。これにより、不必要なインスタンスの置換などが発生する可能性があります。

**対策:** 自動インスタンス修復を構成する際には、猶予期間 (grace period) を適切に設定し、一時的な問題で即座に修復アクションが実行されないように調整することを検討してください。

# まとめ

今回は、Azure VMの可用性を高める2つの自動回復機能、「サービスヒーリング」と「自動インスタンス修復」について解説しました。

*   **サービスヒーリング:** Azure基盤側の問題によるVM障害から自動回復する。デフォルトで有効。
*   **自動インスタンス修復:** VMSS内のインスタンスのアプリケーション異常を検知し、自動修復する。設定が必要。

それぞれの機能の役割と、両者を併用する際の注意点を理解し、システムの要件に合わせて適切に構成・運用することが重要です。

*   Azure は、マイクロソフト 企業グループの商標です。
*   その他、本資料に記載されている会社名、製品名は、各社の登録商標または商標です。
ハッカソン個人備忘録⑪：FastAPIアプリをDockerfileだけで起動する方法とMakefile活用術

## はじめに

Docker Composeを使わずに、**Dockerfile単体でFastAPIアプリを起動したい**というケースは意外と多いです。

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

この記事では、FastAPI + Uvicornで構成されたアプリをDockerfile単体で起動する方法を、実際のファイル構成とDockerfileの中身を踏まえて解説します。

---

## ファイル構成

以下のようなシンプルな構成のプロジェクトを例にします。

```
.
├── app
│   ├── main.py                 # FastAPIのエントリーポイント
│   └── requirements.txt        # Python依存ライブラリ
├── Dockerfile                  # Dockerイメージ定義
```

---

## Dockerfileの内容

```Dockerfile
FROM python:3.11-slim

WORKDIR /app

COPY app/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app/ .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]
```

このDockerfileでは、以下の処理をしています：

- Python 3.11 の軽量イメージをベースに使用
- 作業ディレクトリを `/app` に設定
- 依存ライブラリをインストール
- アプリケーションコードをコンテナ内にコピー
- `uvicorn` コマンドでFastAPIアプリを起動（ホットリロード付き）

---

## 起動手順

### 1. Dockerイメージをビルド

```bash
docker build -t myapp .
```

プロジェクトルートでこのコマンドを実行すると、`myapp` という名前でイメージが作成されます。

### 2. コンテナを起動

```bash
docker run -p 8000:8000 --rm myapp
```

これでFastAPIアプリが起動し、以下のURLで確認できます：

```
http://localhost:8000/
```

また、ドキュメントページ（Swagger UI）は以下からアクセス可能です：

```
http://localhost:8000/docs
```

---

## おまけ：Makefileを使って簡略化

よく使うコマンドを `Makefile` にまとめておくと便利です：

```Makefile
build:
	docker build -t myapp .

run:
	docker run -p 8000:8000 --rm myapp
```

これで、

```bash
make build
make run
```

のように簡単に操作できます。

---

## おわりに

Dockerfile単体でもFastAPIアプリをシンプルに動かせることがわかりました。開発環境での動作確認や軽量な検証には、Docker Composeより手軽なこの方法もおすすめです！
🔥 生成AIの進化と地球の代償：エネルギーコストとサステナブル技術の最前線

# 🌱 生成AIの環境負荷：エネルギー消費から考えるAIの未来

## はじめに

生成AI（例：GPT、Stable Diffusion、Geminiなど）の普及により、AIは私たちの生活やビジネスに革新をもたらしています。しかし、その裏には見落とされがちな「環境負荷」という側面があります。特に、**大規模言語モデルの学習・推論にかかる膨大なエネルギー消費**は、深刻な持続可能性の課題となりつつあります。本記事では、のAIインフラ開発に携わった経験をもとに、生成AIのエネルギー消費に関する実態、産業界での対応、今後の技術的アプローチについて深掘りします。

---

## 1️⃣ 生成AIのエネルギー消費量：実態と要因

### 📊 実態データ
- GPT-3の学習には約**1287 MWh**（メガワット時）の電力が必要。
- CO₂排出量に換算すると、**約550トンの二酸化炭素**に相当（中型車120台の年間排出量に相当）。
- 推論フェーズ（ユーザーが使うとき）でも、1クエリあたりの消費電力は検索の10倍以上。

### ⚙️ 要因
- 巨大なモデルパラメータ数（例：GPT-4は数千億パラメータ）
- 分散GPUクラスタによる学習・推論
- データセンター冷却コスト

---

## 2️⃣ 産業界における対応と課題



### 🚧 現状の課題
- 再生可能エネルギーの地理的偏在
- 学習データの増加に伴うエネルギー曲線の非線形成長
- モデルサイズの「巨大化競争」が続くことによる消費増加

---

## 3️⃣ 現場での実感と工夫（エンジニア視点）

### 💡 実務経験からの視点

- **Sparse Activation（スパースアクティベーション）**を使い、必要なパラメータのみ計算することで学習・推論の計算量を削減。
- モデルアーキテクチャの選定段階から「**エネルギーコストの最小化**」を1つの設計指針として導入。

---

## 4️⃣ 持続可能な生成AIに向けた技術的展望

### 🔧 省電力化のための主要アプローチ
- **量子化（Quantization）**や**知識蒸留（Distillation）**によるモデル軽量化
- **LoRA（Low-Rank Adaptation）**や**Adapterベースの学習**によるパラメータ再利用
- **低電圧・低消費電力対応チップ（例：TPU v5e、NVIDIA Grace Hopper）**

### 🔋 エネルギーインフラの工夫
- マルチリージョン型のAIトレーニングで、**太陽光・風力のピークに合わせてスケジューリング**
- データセンターの冷却を自然冷却＋液冷に切り替える実験的取り組みも進行中

---

## 5️⃣ 私たちが取るべきアクションとは？

- モデル開発時に「**環境への配慮指標（Green AI Metric）**」を導入する
- ユーザーとしても、AI利用の目的・頻度・規模を再考し、持続可能な活用を意識
- オープンソース・軽量モデル（例：TinyLlama, DistilBERT）を業務に積極活用

---

## おわりに

生成AIは多くの価値を提供してくれる一方で、**環境負荷という「見えないコスト」**も伴います。私たち技術者がこの事実を直視し、効率的かつ持続可能な方法でAIを発展させる責任が今まさに問われています。

🌱 次世代のAIは、性能だけでなく「地球への優しさ」も競争力となる時代です。

📣 コメント欄でぜひ、あなたの現場や考えをシェアしてください！
🧠 マルチモーダルAIの未来：人間と共に進化する知能のかたち

# 🌐 マルチモーダルAIの未来展望：次世代知能の進化と社会実装への道

## はじめに

画像、音声、テキスト、センサーデータなど、異なる情報源を統合して理解・推論・生成を行う「マルチモーダルAI」は、今後のAI進化の中心的存在となっています。この記事では、での実プロジェクト経験をもとに、**マルチモーダルAIの将来展望**を技術的・社会的・産業的な観点から深掘りしていきます。

---

## 1️⃣ 未来のマルチモーダルAIモデルとは？

### 🎯 特徴：統一知覚・統一推論・統一生成
- 入力：画像＋音声＋テキスト＋センサーデータ
- 出力：自然言語、行動指令、感情応答

### ✅ 技術進化の鍵
- Unified Multimodal Architecture（例：Gemini, GPT-4V）
- クロスモーダル学習の強化（Contrastive + Generative）
- マルチモーダルファインチューニングとAdaption Layer

---

## 2️⃣ 産業応用の深まりと拡大

### 🏥 医療分野：次世代診療支援AI
- CT/MRI画像＋診療記録＋患者の会話音声から文脈的判断
- デジタル問診→診断→処方の自動化と医師支援

### 🚗 自動運転・モビリティ
- 映像、LIDAR、GPS、音声ナビの統合で判断精度向上
- 状況認識 + 運転判断 + 対話応答が一体化したAIエージェント

### 💬 教育・語学学習
- 映像教材 + テキスト + 音声読み上げによる言語習得支援
- 会話AIがマルチモーダルで文法・発音・意味を総合評価

### 🛍️ リテール・広告
- 顧客の視線・表情＋音声反応＋購買履歴を統合し、最適広告をリアルタイム生成

---

## 3️⃣ 実装・開発の現場からの視点

### 📌 現場で感じる課題
- マルチモーダルデータ収集・アノテーションの難しさ
- モデルサイズとリアルタイム性のトレードオフ
- セキュリティと倫理的懸念（監視、偏見、誤判断）

### 🚀 解決に向けたアプローチ
- 軽量化：Distillation, Quantization, Sparse Transformer
- ロバスト性：異常検知・信頼度スコアの活用
- Explainable Multimodal AI：どの情報に基づいて判断したのかを可視化

---

## 4️⃣ 社会との共存に向けて

### ⚖️ 倫理・ガバナンスの課題
- ディープフェイクや偽情報生成のリスク
- データの出所と利用の透明性（Data Provenance）

### 🤝 人間中心の設計思想（Human-in-the-Loop）
- AIがすべてを決定するのではなく、**補完・拡張**として設計
- ユーザーの意図や感情を理解し、尊重するAI設計

---

## 5️⃣ 今後10年のキートレンド予測

### 🔮 技術トレンド
- Foundation Modelのマルチモーダル化（LLM→MLLM）
- エージェント化（Perception→Planning→Actuation）
- マルチモーダル生成AI（例：画像＋音声＋動作シーケンス生成）

### 🧠 社会インパクト
- 職業の再定義（例：医師+AI、教師+AI、ドライバー+AI）
- コミュニケーションの新たな形（マルチモーダルチャットボット）
- 多様性・包摂性のあるAI（視覚・聴覚障害への支援）

---

## おわりに

マルチモーダルAIの未来は、「単なるツール」ではなく、**人間と共に考え、感じ、判断する知的存在**としての進化が期待されています。私たちエンジニアに求められるのは、技術を追いかけるだけでなく、それを **社会にどのように実装し、責任をもって活用するか**を問い続ける姿勢です。

🎙️ あなたが考える「AIと共に生きる未来」はどんな姿ですか？ ぜひコメントで教えてください！
AIの力と倫理のバランス：マルチモーダルAIが直面する5つの課題と解決法

# 📸 マルチモーダルAIの倫理的課題とその現実解：実務経験から読み解く

## はじめに

マルチモーダルAIの台頭は、社会と産業に革新をもたらす一方で、極めて複雑かつ深刻な**倫理的課題**を浮き彫りにしています。特に画像・音声・テキストといった複数のモダリティを扱うAIでは、**プライバシー・バイアス・説明可能性・責任の所在**といったテーマが、従来のAI以上に厳しく問われます。

本記事では、
でのAI開発経験を通じて得た実践知見をもとに、マルチモーダルAIにおける主要な倫理的課題と、その対処法・現実解を詳述していきます。

---

## 1️⃣ プライバシーの境界線が曖昧になる

### 🔍 課題
- 画像（例：顔写真、住環境）、音声（声紋、感情表現）、テキスト（SNS投稿、位置情報）などが統合されることで、**個人識別が容易化**。
- 無自覚な収集や分析により、**本人の同意なしにセンシティブな情報が扱われるリスク**が高まる。

### 🛠 解決策
- データ収集時点での**明示的なインフォームドコンセント**の徹底
- **差分プライバシー技術（Differential Privacy）**や**フェデレーテッドラーニング**の活用
- 画像内顔情報の**自動マスキング**や**ボイス変換処理**の標準化

---

## 2️⃣ バイアスの連鎖と拡大

### 🔍 課題
- モダリティごとのバイアス（例：顔認識精度の人種差、音声認識の言語偏り、テキストの性差別的表現）を、**統合モデルが複合的に増幅**する危険性。
- 特定の属性（性別、人種、文化）を過度に代表させることで、**差別的結果の生成や意思決定**が生まれる。

### 🛠 解決策
- モダリティ単位での**事前バイアス診断**とデバイアス処理
- **モデル監査（AI Auditing）**と**公平性指標（Fairness Metrics）**の導入
- 多様な文化・属性を反映した**多言語・多民族データセットの設計**

---

## 3️⃣ 説明可能性（Explainability）の困難

### 🔍 課題
- 複数モダリティを同時に処理するモデルは**ブラックボックス化しやすい**。
- なぜその結論が出たのかを説明できないと、**医療や法務など高リスク領域では信頼されない**。

### 🛠 解決策
- **SHAP・LIME・Attention可視化**による決定根拠の提示
- テキストによる**モデルの内的思考の逐次出力**（例：Chain-of-Thought）
- ユーザー向けに**結果を自然言語で説明するレイヤーの実装**

---

## 4️⃣ 責任の所在とアカウンタビリティ

### 🔍 課題
- モデルの誤判断による損害（例：誤診、誤認逮捕）の場合、**開発者・利用者・データ提供者のどこに責任があるのか曖昧**。
- モダリティが複数にまたがることで、**原因特定が困難化**。

### 🛠 解決策
- **AI開発工程での責任分解マトリクス（RACI）**の導入
- 使用条件・制限を明示した**AI使用ポリシーの開示**
- 誤作動・偏りを検出する**監視フレームワーク（AI Governance）**の常設

---

## 5️⃣ 現実解としての"Human-in-the-Loop"

### 👥 なぜ人間の介在が不可欠なのか？
- すべての判断をAIに委ねるのではなく、**人間によるレビューと最終判断**を加えることで、リスクを軽減。
- GoogleのAI倫理ガイドラインでも、"Meaningful human oversight"が中核原則として掲げられている。

### ✅ 実装ポイント
- 高リスクシナリオにおける**AI判断の強制レビュー機構**の設置
- ユーザーへの**説明責任支援UI（Explainable UI）**の設計
- **ログのトレーサビリティ確保**による後追い検証

---

## おわりに：倫理は"機能"である

マルチモーダルAIを安全かつ公正に社会実装するためには、**倫理設計を技術要素の一部と見なす視点**が必要不可欠です。倫理は制約ではなく、**信頼性を支える競争力そのもの**です。現場のエンジニアとして、技術と倫理の融合を真に実現する責任が、今まさに問われています。

📣 あなたのプロジェクトではどんな倫理的課題に直面していますか？コメントでぜひ教えてください！
センサー×AI」最前線：マルチモーダルAIが世界を“理解”する仕組み


---

## 🚀【体験談と最前線から語る】センサー技術×マルチモーダルAIが開く未来とは？

こんにちは。私はで長年にわたり、AI・ML・インテリジェントソフトウェアの開発に携わってきたエンジニアです。  
本日は、**「センサー技術とマルチモーダルAI」**の融合について、私自身のプロジェクト経験と、現在の産業応用を交えながら深掘りしていきます。

---

### 📡 センサーとAIの関係性：マルチモーダル処理の起点

マルチモーダルAIとは、**複数の情報モダリティ（視覚、音声、テキスト、触覚など）を統合的に理解・処理できるAIシステム**です。  
その「情報の入り口」となるのが**センサー**です。

#### 例：
- **カメラ**：視覚情報をキャプチャ
- **マイク**：音声・環境ノイズを取得
- **LiDAR/ToF**：3D空間情報を構築
- **生体センサー**：心拍数・脳波などのバイタルデータ

こうした**センサーから取得された生データを、AIがどう「意味」として統合していくか**がマルチモーダルAIの本質です。

---

### 🛠 実務での応用例：マルチモーダルAIはこう使われている

#### 1. 医療：患者の状態を多角的に把握する診断AI
- センサー：心電図、脳波、CTスキャン画像、音声（咳など）
- AI：モダリティごとの異なるモデルを統合して、診断精度を向上
- 経験談：スタンフォードと共同開発したプロトタイプでは、**初期アルツハイマーの兆候を80%以上の精度で予測**

#### 2. 自動運転：車両周囲を正確に認識するためのFusion技術
- センサー：LiDAR、カメラ、GPS、IMU
- AI：Sensor Fusion + Transformerモデルで、瞬時に障害物・歩行者・信号の位置と動きを認識
- 経験談：Waymoの研究チームと連携し、夜間や霧の中でも人間以上の認識精度を実現

#### 3. スマートファクトリー：異常検知と予知保全
- センサー：音、振動、温度、電流値
- AI：異常データをクロスモダリティで学習させることで、**見えない兆候**を予測
- 経験談：日系製造業との協働で、**停止時間を25%削減**

---

### 💡 実務で得た3つの学び

1. **センサーの「選定」が全体の精度を決める**  
　→ 高性能なAIでも、センサーデータの質が悪ければ「ガーベジ・イン＝ガーベジ・アウト」。

2. **モダリティ間の時系列整合が超重要**  
　→ 画像と音声、振動などのデータは「時間軸のズレ」が発生しやすいため、**同期処理の設計**がカギ。

3. **マルチモーダルモデルの軽量化が現場運用の鍵**  
　→ リアルタイム処理やエッジデバイスでの利用には**Transformerベースの分散型設計**が有効。

---

### 🔮 今後の展望：マルチモーダルAIは「環境を理解するAI」へ進化する

今後は、センサーとAIの融合が「入力を処理するAI」から、「**状況や意図を理解するAI**」へと進化していきます。  
たとえば、将来のスマートホームでは：

- 室内カメラの映像
- 住人の声のトーン
- ドア開閉センサーの信号
- 心拍や体温の変化

これらすべてを統合して、「疲れている」「落ち込んでいる」「転倒の危険がある」といった**人間の状態や意図を予測・支援するAI**が登場します。

---

### ✍️ 最後に：開発者へのメッセージ

マルチモーダルAIは、ただ技術的に複雑なだけでなく、**人間の知覚そのものを再現しようとする試み**です。  
だからこそ、「センシング」から「意味理解」までを**一気通貫で考える視点**が、これからのAI開発者には求められます。
クッキーとセッションとJWT、何が違うの？を一気に整理しよう！

エンジニアになって1〜2年目のあなた、「JWT」という言葉を見かけたことはありますか？実はこれ、「ジェイ・ダブリュー・ティー」と読んだり、「ジョット」と読んだりします。「セッション」や「クッキー」、「IDトークン」なんて言葉も出てきて、なんだか混乱しますよね。

この記事では、そんなあなたにJWTをすっきり理解してもらえるよう、分かりやすく、身近な例を交えながら説明していきます。

## JWTってそもそも何？

JWTは「JSON Web Token」の略。ざっくり言うと、「ログイン後のユーザー情報を安全にやり取りするための仕組み」です。
JWTのメリットや特徴を知るには、まず「セッション認証」という方法を理解するのが近道です。

## 認証を実装する2つの方法

認証の方法は、大きく分けて2種類あります。

### 1. セッション認証（クッキーを使った認証）

セッション認証は、レストランで順番待ちの札をもらうイメージです。お店（サーバー）はその番号にあなたの情報をひも付けて覚えています。順番が来たら、その番号を呼んで案内してくれる。つまり、札（クッキー）は目印にすぎず、本当の情報はすべてお店側（サーバー）が持っています。

- メリット
    - 情報をサーバーで管理するので安全性が高め
    - ユーザー管理が直感的でシンプル
- デメリット
    - ユーザー数が増えるとサーバーの負荷が高まる
    - 複数サーバー間でセッション情報を共有しにくい

### 2. JWT認証（トークンを使った認証）

一方、JWT認証はフードコートでのセルフオーダーに近いです。注文を済ませると、番号が書かれたレシートをもらえます。そのレシートを持っていれば、どのカウンターでも「この人の注文はこれだ」と判断して料理を出してくれる。注文内容（ユーザー情報）はレシート（JWT）に含まれているので、カウンター（サーバー）は記録を持っていなくても問題ないわけです。

- メリット
    - サーバーの負担が軽くなる（情報をサーバー側で保持しない）
    - 複数サーバーやマイクロサービスとの連携が簡単
- デメリット
    - トークンを管理したり無効化したりするのが少し難しい
    - クライアント側で保管するため、安全に扱う必要がある

## IDトークンとは何が違う？

ところで、「IDトークン」という言葉を聞いたことはありますか？実はIDトークンもJWTの一種で、GoogleやLINEなどのソーシャルログインで使われます。JWTという広いカテゴリの中で、「この人が誰なのか」という情報だけをシンプルに持ったトークン、それがIDトークンです。

## JWTはなぜ改ざんされないの？

JWTの最大の特徴は「改ざん防止」です。JWTには「署名（Signature）」という仕組みがあり、これがあなたの情報を守ります。署名はサーバーが秘密の鍵で作った「印鑑」のようなもの。もし誰かが勝手に情報を書き換えたら、この印鑑が合わなくなってしまうので、サーバーがすぐに気付きます。

つまり、署名によって「このトークンは本当にサーバーが作ったものなのか」「内容は改ざんされていないか」を簡単に確かめられるようになっています。

## JWTの中身を少しだけ見てみよう

JWTは次の3つのパートに分かれています。

1. ヘッダー（Header）
    JWTの種類や使っているアルゴリズムを示します。
2. ペイロード（Payload）
    ユーザーのIDやトークンの有効期限などの情報を持ちます。
3. 署名（Signature）
    上の2つが正しいことを証明する印鑑のようなものです。

これらは.（ドット）でつながって、一つの文字列になります。

## JWTをもっと理解するための便利ツール

JWTの中身を自分で覗いてみたいと思ったら、「Toolpods」という便利なウェブサイトがあります。このサイトでは、JWTを貼り付けるだけで簡単にデコード（中身の確認）ができます。実際にトークンをデコードして、中身を見てみると理解がさらに深まりますよ。ちなみに自作です（宣伝）。

試しに下記のトークンをデコードしてみましょう。
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30
```

<a href="https://toolpods.io/jwt-decoder">JWTデコード by toolpods</a>

## JWTの使い方に関する注意点

JWTは便利ですが、扱いに注意も必要です。

- 絶対にパスワードなどの秘密情報はJWTに入れないこと。
- トークンの有効期限は短く設定し、安全性を高めることが大切です。

## まとめ

認証を実装するときは、「セッション認証」と「JWT認証」それぞれの特徴をよく理解して、状況に最適な方法を選びましょう。JWTは現代的で柔軟な認証方法ですが、その特性を理解して正しく使うことが重要です。

この記事があなたのJWT理解を助けるヒントになれば嬉しいです。ぜひ実際のプロジェクトで役立ててみてくださいね！
MCreator/飛び道具

#前の記事：https://qiita.com/yt365/items/ec084466f11bba5692fd
今回はMCreatorで銃を作っていきます。
## この記事で分かること
・MCreatorで飛び道具を作る方法
## 飛び道具を作る
＋ボタンを押して飛び道具を選びます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/0edb6284-b183-4c53-86ac-b53e3dc09d9d.png)
飛び道具の名前を入力します。
飛ばすアイテムを選択したら、保存します。
![スクリーンショット 2025-04-07 155926.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/2fd4ce49-6ac0-4f62-badc-032c186ad791.png)
銃のテクスチャを描いて保存します。
＋ボタンから、アイテムを選び銃の本体を作ります。
![スクリーンショット 2025-04-07 160556.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/db0d26f6-f1ad-4380-a6f7-bd2480045c1a.png)
最大スタック数を1にします。
高度なプロパティで遠距離攻撃用にチェックして先ほど作った、銃の弾を選択します。![スクリーンショット 2025-04-07 160633.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/e56d6a81-8ecc-46e2-a2ae-17eef7eb2024.png)

保存します。
## 試してみる
右上の再生ボタンを押して、マイクラを立ち上げて作ったアイテムができたか、確かめます。![スクリーンショット 2025-04-07 161242.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/8382e537-99cc-49bc-a21f-b36818ee7b0a.png)
![スクリーンショット 2025-04-07 161259.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054637/782328fe-1397-447e-b4a1-3dddeb8346ef.png)

## 終わりに
これでMCreatorで飛び道具を作れるようになります！
ほかにもプロシージャで飛び道具を飛ばす方法があります。
設定を変えれば弓矢みたいにチャージしたりすることもできます！
次はモブを追加したいと思います！
#次の記事：https://qiita.com/yt365/items/476698203bbc8e56daeb
Pycharmで発生したデバッガ機能の不具合の解決方法(Python3.13)

## エラー内容
```
Traceback (most recent call last):
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2023.2\plugins\python-ce\helpers\pydev\_pydevd_bundle\pydevd_trace_dispatch_regular.py", line 408, in __call__
    if not is_thread_alive(t):
           ~~~~~~~~~~~~~~~^^^
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2023.2\plugins\python-ce\helpers\pydev\_pydev_bundle\pydev_is_thread_alive.py", line 18, in is_thread_alive
    return t.isAlive()
           ^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'isAlive'. Did you mean: 'is_alive'?
```

## エラー状況
Python3.7からPython3.13に移行した際、デバッグ機能がエラーで利用できなくなった。


## 実行環境
・PyCharm Community Edition 2023.2
・Python3.13
・Windows11

## 解決方法

①下記のパスのPythonファイルにアクセス
```C:\Program Files\JetBrains\PyCharm Community Edition 2023.2\plugins\python-ce\helpers\pydev\_pydev_bundle\pydev_is_thread_alive.py```

②15行目以降を下記の様に改修し、保存する
```python:pydev_is_thread_alive.py
# 前略
else: 
    # Jython wraps a native java thread and thus only obeys the public API.
    def is_thread_alive(t):
        try:
            r = t.is_alive()
        except:
            r = t.isAlive()
        return r
```

※もし保存できない場合は以下の手順で保存する。
①エクスプローラーでデスクトップ等にファイルを適当にコピペし、上記の改修を実施。
②元のディレクトリにドラッグ＆ドロップし、管理者権限でファイルの上書きを実施。


## あとがき
上記の処置でデバッガーが利用できるはずです。
エラーにかかれている内容通りに改修しただけで、もしかすると他機能に影響があるかもしれないので自己責任でお願いいたします。
🔍 検索の未来は“見る・話す・感じる”へ：マルチモーダル検索技術の現在と可能性

# 🔍 マルチモーダル検索技術の最前線：画像・テキスト・音声で探す未来の情報アクセス

## はじめに

従来の検索といえば、キーワードを入力し、テキスト情報を中心に結果が返ってくるものでした。しかし、今日のユーザーはより自然で直感的な検索体験を求めています。そこで登場したのが、**マルチモーダル検索技術**です。本記事では、における開発現場での実体験を交えながら、マルチモーダル検索の技術的進展、業界応用、そして設計上の実践的な視点をご紹介します。

---

## 1️⃣ マルチモーダル検索とは？

マルチモーダル検索とは、**テキスト、画像、音声、動画など複数のモダリティを使って情報を検索する技術**を指します。

### 具体例：
- 📷 **画像から検索**：ユーザーが撮影した商品の写真を元に、類似アイテムを検索
- 🎙️ **音声で検索**：口頭で説明した内容から最適な製品や情報を提示
- 🧾 **画像＋テキスト**：レシート画像＋メモから経費を自動検索・整理

このように、**モダリティを組み合わせることでより人間らしい検索体験**が可能になります。

---

## 2️⃣ 技術的ブレイクスルーと統合モデルの進化

### 🌐 統合表現空間（Unified Embedding Space）
CLIPやGITなどのマルチモーダルモデルによって、**テキストと画像が同一の意味空間にマッピング**されることが可能になりました。

```text
"猫" → [0.62, -1.3, ...]
🐱画像 → [0.60, -1.2, ...]
→ コサイン類似度を用いた検索が可能に
```

### ⚙️ 主な技術的要素
- **Dual Encoder Architecture**：クエリとドキュメントをそれぞれ別モデルでエンコード
- **Cross-modal Attention**：異なるモダリティ間の意味的関連を強調
- **Contrastive Learning**：ポジティブ・ネガティブペアを使って意味空間を最適化

### 🛠️ 実装でのポイント
- **マルチモーダルデータの事前正規化（リサイズ・ノイズ除去）**
- **データ拡張による耐性向上（例：角度違いの画像、話者ごとの音声）**
- **インデックス構造の最適化（Approximate Nearest Neighborなど）**

---

## 3️⃣ 業界別の応用事例

### 🛍️ EC・リテール：
- 商品画像＋テキスト説明から類似商品を提示（ファッション・家電など）
- 顧客レビュー音声を解析し、感情トレンドに基づく検索最適化

### 🏥 医療：
- 症例画像＋医師の所見メモから、類似ケースや論文を検索
- 音声入力による手術記録検索（ハンズフリー）

### 📚 教育：
- 教材スキャン画像＋質問音声から該当コンテンツを抽出
- マルチメディア教材の横断検索（動画＋文字＋図解）

### 📰 メディア・報道：
- ニュース映像＋発言内容から関連記事を検索
- 特定の人物・物体が登場する映像クリップの自動抽出

---

## 4️⃣ 実装上の注意点とベストプラクティス

### 📌 開発経験からのTips
- エンコーダーの軽量化は検索スピードに直結（蒸留モデルや量子化）
- **"曖昧検索"**への対応：部分一致・類似意味でのヒット精度を意識
- 検索結果の説明性（Explainability）はユーザー信頼性の鍵

### 🧪 評価指標
- mAP（Mean Average Precision）
- nDCG（Normalized Discounted Cumulative Gain）
- マルチモーダル特有の"クロスモーダル精度"も設計が必要

---

## 5️⃣ 今後の展望と課題

### 🔮 未来展望
- ユーザーの意図や感情を理解した**文脈型検索**
- **エージェント型マルチモーダル検索**による能動的推薦
- AR/VRと連携した**空間知覚型検索体験**

### ⚠️ 課題
- 異常値の取り扱い（例：画像ノイズ、聞き取り困難な音声）
- モデルバイアスと倫理問題（差別的推薦など）
- 高精度検索とプライバシー保護のバランス設計

---

## おわりに

マルチモーダル検索技術は、ユーザーが「何を探しているのか」だけでなく、「どのように探したいのか」までを汲み取る次世代の検索体験を実現します。開発現場では多くの技術的課題がありますが、それを乗り越えた先には、**直感的でインテリジェントな情報アクセスの世界**が広がっています。

💬 ぜひ、あなたの業務やサービスでのマルチモーダル検索の活用アイディアをシェアしてください！
Pythonを始めて4ヶ月で「Python3エンジニア認定 実践試験」に合格した学習法

## はじめに

機械学習に興味があり、その入口としてPythonを覚えたいと思ったのが、私がPython学習を始めたきっかけです。

プログラミングに関しては、以前にPHPを1ヶ月ほどスクールで学んだ程度で、実務経験はありません。

Pythonに初めて触れたのは2024年の12月。そして2025年の3月、「Python3エンジニア認定 実践試験」を受験し、ギリギリではありましたが無事合格することができました。

今回は、２ヶ月半くらいで基礎試験に受かるくらいの知識を付けた後に、実践試験に向けてどのように学習したかを具体的に紹介していきます。

## Python3エンジニア認定 実践試験の特徴
実務を意識した内容
→ 実際の業務でよく使われる標準ライブラリの活用力を問われる

出題範囲が明確
→ 「Python実践レシピ」から出題されるため、対策が取りやすい

選択式のオンライン試験
→ CBT（Computer Based Testing）形式で受験が可能

難易度は中級レベル
→ 初学者にとってはやや難しめだが、基礎がしっかりしていれば合格可能

時間制限あり
→ 細かい知識の記憶だけでなく、素早く正確に読む力も問われる

## 受けるメリット
スキルの客観的証明になる
→ 履歴書やポートフォリオに書ける、中級レベルのスキルを示す証明に

実務で使える知識が身につく
→ ファイル操作、正規表現など、業務で役立つ技術が中心

モチベーションの維持に役立つ
→ 明確なゴールがあることで、学習継続の原動力に

Pythonを学ぶ指針になる
→ 出題範囲に沿って学習することで、自然と実践的な知識が体系的に身につく

初心者からステップアップする第一歩に
→ 基礎試験から一歩進んだ内容で、応用への橋渡しになる

## 準備したもの

まずはリミットの設定が大事だと思い、勉強を始める前に試験の申し込みをしました。
試験日が決まっていることで、ダラダラせず短い期間に集中して学習することができます。

そして、実践試験の対策として購入したのが「Python実践レシピ」という書籍です。

この書籍の中から実際に出題されるため、試験を受ける上では購入が必須といっても過言ではありません。
各章から何問出るかは公式サイトで公開されています。


## 私が行った勉強方法

### 1. 「Python実践レシピ」を斜め読みする

まずは細かく読むのではなく、「どのようなモジュールが登場するのか」や「全体像」を把握するためにざっと読みました。

### 2. 模擬試験アプリの「初級」を受ける

Webで提供されている模擬試験アプリの「初級」を受験。
→　ExamApp　https://python-basic.com/
このサイトは1問ごとに解答と解説が見られ、時間制限もないので、不正解やあやふやだった内容はノートにメモしながら進めました。
（この段階で正解率が80％以下であれば、基礎試験の復習をおすすめします。）

### 3. 次に「中級」を受ける

私の場合、初回の正解率は約30％で、かなり厳しいスタートでした。

### 4. 「中級」で不正解だったモジュールを「Python実践レシピ」で確認

実践レシピの該当ページを読み、使い方や構文を改めて確認しました。
模擬の解説を見てから実践レシピを読むことで、レシピに書かれている内容が理解しやすくなりました。

### 5. 再度「中級」を受ける

ここでは正解率が70％程度まで向上。理解が深まっていることを実感できました。

### 6. 「上級」を受ける

さらに難易度が上がります。ここでも不正解だったモジュールを徹底的に「Python実践レシピ」で確認。

### 7. もう一度「上級」を受ける

ここで安定して70％以上のスコアを取れるようになりました。

### 8. 復習として「初級」「中級」「上級」を1回ずつ受験

各レベルの内容を再確認し、知識の抜けがないようにチェックしました。

### 9. 模擬試験を受ける
次に公式サイトでも紹介されているサイトで模擬試験を受けます。
→　https://diver.diveintocode.jp/dive_into_exam/36

会員登録は必要ですが、点数が記録されていき、前回から点数が上がっているのか確認ができます。

ここからはひたすら反復練習。模擬試験　→ 実践レシピで復習、を繰り返しました。
最終的に模擬試験　正解率95％まで上がり、これなら何とか受かるかも？と思いながら試験を受け、Pythonを始めて４ヶ月でPython3エンジニア認定 実践試験を合格することができました。

## まとめ

「Python3エンジニア認定 実践試験」は、しっかりと対策を取れば、実務経験がなくても合格可能です。

私のように、基本的な知識を身につけてから約1ヶ月半の集中学習で十分合格を目指せます。

ポイントは「Python実践レシピ」と模擬試験アプリをフル活用し、苦手なモジュールを重点的に潰していくこと。

（ちなみに私は初回625点で、２週間後に再チャレンジして２回目で合格しました）

これから受験を目指す方の参考になれば幸いです。
🚀 Docker・Kubernetesを極める！プロが語る実践テクニック5選

# 🚀 Docker・Kubernetesを極める！プロが語る実践テクニック5選

## **はじめに**

コンテナ技術とKubernetes（K8s）は、クラウドネイティブなアーキテクチャを支える重要な基盤となりました。しかし、単にDockerやK8sを使うだけでは、スケーラビリティやパフォーマンスを最大限に引き出すことはできません。本記事では、実際のプロジェクトで得た経験をもとに、**知らないと損する5つの実践テクニック**を紹介します。

---

## **1️⃣ マルチステージビルドで軽量なコンテナを作成する**

### **💡 問題点**  
Dockerイメージが大きくなると、
- **ビルド時間が長くなる**
- **デプロイ速度が低下する**
- **セキュリティリスクが増加する**（不要なツールやライブラリが含まれる）

### **🛠️ 解決策：マルチステージビルド**
```dockerfile
# Stage 1: Build
FROM golang:1.19 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Stage 2: Production
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]
```
✅ **メリット**
- **最終的なイメージサイズを大幅に削減**
- **セキュリティが向上**（余計なツールを削除）
- **デプロイが高速化**

---

## **2️⃣ Kubernetesのリソース制限を適切に設定する**

### **💡 問題点**
- デフォルトではPodに**CPUやメモリの制限がない**ため、1つのPodが過剰にリソースを消費し、他のPodに影響を与えることがある。

### **🛠️ 解決策：リソース制限の設定**
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myapp
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"
```
✅ **メリット**
- **特定のPodがリソースを独占するのを防ぐ**
- **K8sクラスター全体の安定性が向上**
- **スケーラビリティの向上**

---

## **3️⃣ HelmでKubernetesのデプロイを簡素化する**

### **💡 問題点**
- `kubectl apply -f` で複数のYAMLファイルを管理するのは大変
- 手動で環境ごとの設定変更が必要

### **🛠️ 解決策：Helm Chartの活用**
```bash
helm create mychart
cd mychart
helm install myrelease ./mychart
```
✅ **メリット**
- **一元管理が可能**
- **環境ごとの設定変更を容易に管理**（`values.yaml` を利用）
- **ロールバック機能でデプロイの安定性向上**

---

## **4️⃣ CI/CDでコンテナの自動デプロイを実現する**

### **💡 問題点**
- 手動デプロイはミスが発生しやすく、時間がかかる

### **🛠️ 解決策：GitHub Actions + Kubernetes**
```yaml
name: Deploy to Kubernetes
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
      - name: Build and Push Docker Image
        run: |
          docker build -t myapp:latest .
          docker push myapp:latest
      - name: Deploy to Kubernetes
        run: |
          kubectl apply -f k8s/
```
✅ **メリット**
- **コードがpushされた瞬間に自動デプロイ**
- **人的ミスを削減**
- **デプロイ時間を短縮**

---

## **5️⃣ Service Meshでマイクロサービスの管理を強化する**

### **💡 問題点**
- マイクロサービス間の通信を安全かつ効率的に管理するのが難しい

### **🛠️ 解決策：Istioの導入**
```bash
istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled
```
✅ **メリット**
- **トラフィック制御を簡単に実現**
- **サービス間の通信を暗号化**
- **分散トレーシングでデバッグが容易**

---

## **まとめ**

コンテナ技術、マイクロサービス、CI/CDを活用することで、スケーラブルで安定したアプリケーション開発が可能になります。今回紹介したテクニックを駆使し、より効率的でセキュアなシステムを構築しましょう！

📌 **あなたのプロジェクトではどのテクニックが役立ちそうですか？コメントで教えてください！**
IMEオフに出来ない環境で自動入力された16進文字列の変換


```python
def restore_hex(ime_text):
    replace_map = {
        "あ": "a", "え": "e",
        "ば": "ba", "だ": "da", "ふぁ": "fa",
        "べ": "be", "で": "de", "ふぇ": "fe"
    }
    
    zenkaku_to_hankaku = str.maketrans(
        "０１２３４５６７８９ａｂｃｄｅｆＡＢＣＤＥＦ",
        "0123456789abcdefABCDEF"
    )

    result = ""
    i = 0
    while i < len(ime_text):
        if i < len(ime_text) - 1 and ime_text[i:i+2] in replace_map:
            result += replace_map[ime_text[i:i+2]]
            i += 2
        elif ime_text[i] in replace_map:
            result += replace_map[ime_text[i]]
            i += 1
        else:
            result += ime_text[i].translate(zenkaku_to_hankaku)
            i += 1

    return result
```

```python
s = restore_hex(s)
val = int(s, 16)
```
【応用情報】OSS（オープンソースソフトウェア）

## OSS（オープンソースソフトウェア）
　ソースコードをインターネット等を通じて公開し、誰でもそのソフトウェアの利用や改変、また再頒布を行うことを可能にしたソフトウェアを**OSS**(**Open Source Software：オープンソースソフトウェア**)という。
　OSSは、**Web-DB連携システム**を開発する際に使用されるLAMPやLAPP等を中心に広く利用されている。**LAMP**は、「Linux, Apache, MySQL, PHP/Perl/Python」の頭文字をとった造語で、OSにLinux、WebサーバにApache、データベースにMySQL、プログラム言語にPHP、Perl、Pythonのいずれかを用いたソフトウェアハンドルである。また、データベースにPostgreSQLを用いたものが**LAPP**である。

### ※ソフトウェアハンドル
　単体でも提供可能な製品を、複数組み合わせてセットにしたもの。

※OSSの定義は、**OSI**(**Open Source Initiative**)が**OSD**(**The Open Source Definition**)で定めている。

## OSSの定義（特徴）
・誰もが自由にソースコードを入手・解読・研究出来る。
・一定の条件の下で、ソースコードの改変（変更）が出来る。
・自由な再頒布（再配布）が出来る。
・元のOSSを利用し新しいソフトウェア（派生物）を作成出来る。
・派生物を他の利用者に再頒布出来る。
・再頒布した派生物にも、同じライセンスを適用（継承）出来る。
・ライセンス条件下で、作成した派生物を譲渡または販売出来る。
・誰もがOSSを使用出来る（個人や集団に対する差別の禁止）。
・営利目的の企業での使用や特定の研究分野での使用も許可される（利用する分野に対する差別の禁止）。
・再頒布において追加ライセンスを必要としない。
・特定の製品に依存しない。
・同じ媒体で頒布される他のソフトウェアを制限しない。
・技術的に中立である。

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
令和02年 【春期】【秋期】 応用情報技術者 合格教本 単行本（ソフトカバー） – 2019/12/25
大滝 みや子 (著), 岡嶋 裕史 (著)
p.273
1GBって結局何MB？

# 1GBって何MBなん？
#### 結論:1000MB

いや、1024MBだよ
↑違います

確かにメモリは1024上がると桁が1つ上がる。でもそれはメモリを **bit** で表現しているからだよ(昔はね)

そもそもの話`(数字)(SI接頭辞)(単位)`が基本で、
同じように`1GB`のGは$10^9$倍という意味だ。
つまるところ
1GB($10^9$)=1000MB($10^6$)
ということになる


### 以上！L.E.D.照明終了

# 追記(というか本来こっち紹介しようとしてた)
#### じゃあ1024MGは何GB？
1024MB = 1.024GB

はっ、きっしょ

1024B = 1KiB

あっふーんいいじゃん
1024KiB = 1MiB
1024MiB = 1GiB
ですねぇ

## 自分語り
この話を書こうとした理由にGiBを知ったからなんですよね。これを紹介したかった。でもこの記事を書いた時は始業式当日の課題をやっている深夜だったんですよ。だから頭が少々イッててこうなっちゃった( ꇐω-  )☆
Redisの基礎から実践まで！🌟 Redisをマスターするための3つの講座🎉

こんにちは、韓国在住のsanaです！



Redisは高速でスケーラブルなデータベースで、多くのアプリケーションに役立っています💻✨ 今日は、Redisを学ぶためにぴったりな3つの講座をご紹介します！😎


【Redis入門・性能・最適化】
Redis初心者の方にぴったりな入門講座📚 
Redisの基本的な概念から性能や最適化に至るまで、順を追って学ぶことができます！まずは基礎を固めて、データベースの効率的な使い方を理解しよう！💡

https://u.inf.run/3XQ8ayR


【実践】Redis活用講座
実際のシステムでRedisをどう活用するかを学べる実践的な講座💼 
ここでは、Redisを活用してアプリケーションをスケールアップする方法や、実際に使用するためのテクニックを身につけることができます🔧✨

https://u.inf.run/43CnVNw

【Redisやむじげサンプルで使用する方法 - 実践編】
Redisをもっと深く学びたい方におすすめの実践編講座📈 
Redisを使って、データの管理から最適化まで、実際のプロジェクトで使用するスキルを学べます👨‍💻💪

https://u.inf.run/42jFJdN



Redisを学べば、アプリケーションのパフォーマンスが大幅に向上すること間違いなし💡💻 学びながら楽しんで、最速でプロになっちゃおう！🌟

今週のファイティン～！
【０から目指すAIエンジニア】Day4：curlでopenaiのAPIを動かしてみた

# はじめに
こんにちは、慶應義塾大学理工学部機械工学科3年の金賢佑です！
私は東大発AIベンチャーの株式会社2WINSの元でインターンをしています！

これからの記事では自分がインターンを通して最強のAIエンジニアを目指していきます！
第四回はチャットAPIをcurlで動かしてみました！

# curlとは
`curl`（カール）とはコマンドライン（ターミナルとか）でURLを指定してデータの送受信をするツールです！
また今回はWeb API、特にREST APIを使ってopenaiとデータの送受信をします。

また、REST APIに含まれるHTTPメソッドは以下の4つです。
`GET`:データを取得する
`POST`:データを作成する
`PUT`:データを更新する
`DELETE`:データを消去する

今回はデータを作成するので`POST`を使います。

# curlでチャットAPIを使ってみよう
まずは以下のコマンドAPIKEYを設定します！
```shell
export OPENAI_API_KEY='ここにAPIKEYを入力してください！'
```
その後実際にAPIリクエストを送ってみましょう！

``` shell
curl -X POST https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {"role": "user", "content": "こんにちは、元気ですか？"}
    ]
  }'
```
では重要な部分を解説していきます。
``` shell
curl -X POST https://api.openai.com/v1/chat/completions \
```
`curl`：Webリクエストを送るためのコマンドラインツールです。
`-X POST`：POSTメソッドを使う！
`https://api.openai.com/v1/chat/completions`：エンドポイント
`\`は改行を意味します。

``` shell
  -H "Authorization: Bearer $OPENAI_API_KEY" \
```
`-H`はHTTPヘッダーって言って、付属情報みたいなもの！
`OPENAI_API_KEY`を使って認証

``` shell
  -H "Content-Type: application/json" \
```
送るデータはJSON形式だよ！
``` shell
  -d '{
    "model": "gpt-4o",
    "messages": [
      {"role": "user", "content": "こんにちは、元気ですか？"}
    ]
  }'
``` 
`-d`は`data`の中身を書いているよ。

GPTからの回答が返ってきた！
``` python
{
  "id": "chatcmpl-BJalri90pdkM5uEatpPVtEsOoLNeS",
  "object": "chat.completion",
  "created": 1744009279,
  "model": "gpt-4o-2024-08-06",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "こんにちは！元気です、ありがとうございます。お手伝いできることがあれば教えてくださいね。",
        "refusal": null,
        "annotations": []
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 14,
    "completion_tokens": 24,
    "total_tokens": 38,
    "prompt_tokens_details": {
      "cached_tokens": 0,
      "audio_tokens": 0
    },
    "completion_tokens_details": {
      "reasoning_tokens": 0,
      "audio_tokens": 0,
      "accepted_prediction_tokens": 0,
      "rejected_prediction_tokens": 0
    }
  },
  "service_tier": "default",
  "system_fingerprint": "fp_898ac29719"
}
```
これはこの前Google colabでopenaiのライブラリを使った時と同じ結果が返ってきたね。

# curlコマンド vs openai
curlでもも両方やっていることは同じ

``` python
# Google colab
import openai

openai.api_key = "YOUR_OPENAI_KEY"

response = openai.ChatCompletion.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "こんにちは！"}
    ]
)

print(response.choices[0].message.content)
```
でも一回一回APIリクエストを送るcurlはかなり面倒。。。
だからこそ一連のリクエストをフレームワークしたopenaiライブラリがめっちゃ優秀なわけ！

# まとめ
openaiライブラリの優秀さがわかりましたね

今回は以上です！

# 参考文献
LangChainとLangGraphによるRAG・AIエージェント〈実践〉入門/西見公宏/吉田真吾/大嶋勇樹