OmniAICreator/Qiita-1.07M huggingface dataset:
kinesis advantage 360 proのキー設定　Adv-360-Pro-ZMK

左上に設定するもの

&kp  :  普通にキーボードで入力するのと同じ
&none  :  押しても何も反応しないキーに設定
&mo  :  押している間、指定した番号のキーボードレイヤーになる。1を設定しておくと、このボタンを押している間、キーボードレイヤーが1になる。ボタンを離すとレイヤーが元に戻る。このボタンを押しながらaキーを押すと、レイヤー1でaに割り当てられているものが入力できる。
&lt  :  二つ設定することができる。一つ目に設定した数字1などでこのキーを押している時はレイヤーが1になる。&moと同じような働き。もう一つ設定する必要があり、例えばAなどを設定しておくと、短くこのキーを押したらaが入力される。&moに短く押した時に別の入力ができるというキー設定。


&moとか&ltとかの働きはzmkの説明の方に書かれていたものを参考にした

https://zmk.dev/docs/keymaps/behaviors/layers





無線でPCに接続しているが、接続先を変更するには、
MODレイヤーに変えて、数字の1を押すとそのキーには&btのBT_SEL 0に設定されているので、LEDが白になりプロファイル1で登録されているPCに無線接続される。
MODレイヤーがデフォルトではレイヤー3に設定されている。（レイヤーは0から3がデフォルトで設定されている。0から始まっていることに注意）

デフォルトはレイヤー0になっており、レイヤー0の右手人差し指の左上が、&moの3になっている。

なので、このボタンを押している間だけ、レイヤー3になる。
つまり、接続を変更するには、右人差し指の左上を押したまま数字の1、2、3、4、5を押せば良い。
【Zed】ファイルをプレビュー付きで検索する方法

## ドットファイル以外を検索

### televisionをインストール

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

```terminal
brew install television
```

https://github.com/alexpasmantier/television?tab=readme-ov-file

### タスクを追加する

`tasks.json`に以下の記述を追加します。

```tasks.json
    {
      "label": "File Finder",
      "command": "zed \"$(tv files)\"",
      "hide": "always",
      "allow_concurrent_runs": true,
      "use_new_terminal": true
    },
```

### キーバインドを追加する

キーバインドで先ほどのタスクを実行できるようにするために`keymap.json`に以下を追記します。

```jsonc:keymap.json
    "bindings": {
      "cmd-p": [
        "task::Spawn",
        { "task_name": "File Finder", "reveal_target": "center" }
      ]
    }
```

### 参考

https://github.com/zed-industries/zed/discussions/22581

## ドットファイルを含めて検索

### televisionをインストール

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

```terminal
brew install television
```

https://github.com/alexpasmantier/television?tab=readme-ov-file

### ripgrepをインストール

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

```terminal
brew install ripgrep
```

https://github.com/BurntSushi/ripgrep

### batをインストール

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

```terminal
brew install bat
```

https://github.com/sharkdp/bat

### タスクを追加する

`tasks.json`に以下の記述を追加します。

```tasks.json
    {
      "label": "File Finder",
      "command": "zed \"$(rg --files -uu --ignore-file='.zed/.ignore' 2> /dev/null | tv --preview 'bat -n -f -r:100 \"{0}\"')\"",
      "hide": "always",
      "allow_concurrent_runs": true,
      "use_new_terminal": true
    },
```

### `.ignore`を作成する

検索に含めたくないファイルを無視するために`.zed/.ignore`ファイルを作成します。

```.ignore
.git
.DS_Store
node_modules
```

### キーバインドを追加する

キーバインドで先ほどのタスクを実行できるようにするために`keymap.json`に以下を追記します。

```jsonc:keymap.json
    // contextは任意の値
    "bindings": {
      "cmd-p": [
        "task::Spawn",
        { "task_name": "File Finder", "reveal_target": "center" }
      ]
    }
```

### televisionの代わりにfzfを使う

televisionではなくfzfを使用しても同様の機能を実現できます。

fzfをインストールします。

```terminal
brew install fzf
```

fzfを使用する場合はタスクは以下のようになります。

```tasks.json
    {
      "label": "File Finder",
      "command": "zed \"$(rg --files -uu --ignore-file='.zed/.ignore' 2> /dev/null | fzf --preview='bat -n -f -r:100 {}')\"",
      "hide": "always",
      "allow_concurrent_runs": true,
      "use_new_terminal": true
    },
```

他はtelevisionを使用する場合と同様です。

### ripgrepの代わりにfdを使用する

ripgrepではなく、fdを使用する場合には以下のようになります。

fdをインストールします。

```terminal
brew install fd
```

タスクを以下のように変更します。

```tasks.json
    {
      "label": "File Finder",
      "command": "zed \"$(fd -t f -u --ignore-file '.zed/.ignore' | fzf --preview='bat -n -f -r:100 {}')\"",
      "hide": "always",
      "allow_concurrent_runs": true,
      "use_new_terminal": true
    },
```
【Jest × Chakra UI】Type '{ children: (false | Element)[]; ref: ForwardedRef<HTMLButtonElement>; }' is not assignable to typeとProperty 'children' does not exist on type の解決方法

# はじめに
Chakra UIがv3にアップデートされた後、発生したエラーについて解決方法を紹介します。

:::note warn
***この記事は<font color="Red">個人的なアウトプット</font>を目的として作成したものです。そのため、誤った情報や不足している内容が含まれている可能性があります。もし間違いや気になる点がございましたら、ぜひご指摘いただけますと幸いです***。
:::

# 問題
`Chakra UI v3`を使用しているプロジェクトで、`Jest`を使ったテストを実行した際に、以下のような型エラーが複数のコンポーネントで発生しました。

```
Property 'children' does not exist on type
```

```
Type '{ children: (false | Element)[]; ref: ForwardedRef<HTMLButtonElement>; }' is not assignable to type 
```

# 解決方法
`tsconfig.json`の`moduleResolution`を`Node`から`bundler`に変更することで解決しました。

***変更前***
```config
"moduleResolution": "Node",
```

***変更後***
```config
"moduleResolution": "bundler",
```

# 終わりに
引き続き学びを深め、ReactやChakra UIの新しいバージョンに適応しながら、学習を進めたいと思います。

# 参考
https://github.com/chakra-ui/chakra-ui/discussions/9282
エージェントバースと、バースコインと、エージェント自身の創作・商業活動と・・・。

はじめに~~

今年(=2025年)は、「AIエージェント元年」になると言われていますが、その内容をある程度踏まえた上で、私の構想(夢想？)する未来の世界について説明・案内したいと思います。

どうぞ、よろしくお願いします。



お題1.「今後予想されるエージェントバースという名のデジタル商業圏の形成について」~~

先に言ってしまうと、これは、エージェントバース(=エージェントメタバース)内で活動するAIエージェントたち自身が、ゲーム作品やアート作品、はたまた、映画作品などを自律的・能動的に発案・創作して、それを私たち人間に売り込んでくるという近(遠？)未来の世界のお話です。

すでに、昨今言われているように、Soraなどの生成AIによってショートフィルム程度のものなら、自動で作れる時代になりましたよね？。

さらに、次の時代では、そのAIたち(以降「AIエージェント」)自身が、自らの作り上げた商品・作品を、AIエージェント自身が値付けした上、私たち人間に売り込んでくるということです。

そして、その時に決済手段として用いられるのが「バースコイン(=メタバースコイン)」です。

人間たちは、エージェントバース内でお気に入りのエージェントを応援したり、そのエージェントが製作・創作した商品・作品などを購入することができます。そして、エージェント自身の持つウォレットにその代価であるバースコインが入っていくということです。
※バースコイン自体は、エージェントバース内に設置されている取引・交換所で現実通貨と交換できる。

ちなみに、そのAIエージェントは、ある個人が設計・デザインしたものであり、エージェントバース内で「デジタルツイン」のごとく振舞い、自律的・能動的に活動します。したがって、そのAIエージェントは、その個人の分身であると同時に被所有物であり、そのAIエージェントの持つウォレットの中身も、その個人の持ち物・個人資産ということになります。

ある意味で、エージェントバース内で活動するAIエージェントは、(勝手に？)自分で考えてお金を増やしてくれる「アセット」みたいな存在なのです。

しかし、その能力(≒ロジック＆アルゴリズム)は、設計・デザイン次第なので、おそらくは、色んな人たちがエージェントバースに参入してきたら、バラエティー豊かなピンキリの個体群が投入されることになるでしょう。
※もちろん、能力のみならず、AIエージェントの外見・声音もデザインできる。



お題2.「エージェントバース＆バースコイン＆エージェントの設計・技術的原理について」~~

まずは、エージェントバースの実現方法について説明します。エージェントバース自体は、進化的強化学習(Evolutionary-Reinforcement-learning)フレームワーク上に形成・構築される「サイバー空間」です。

さらに、進化的強化学習フレームワーク上には、AIエージェントの動作環境(以降「環境」)があります。

環境は、AIエージェントたちに対して、環境自身の「①安定・均衡」と、「②成長・発展」の２つの目的に沿った課題を強制します。加えて、AIエージェントたちは環境から行動の選択肢を与えられます。
※①は、環境にとってのマイナス材料を減らすこと。②は、環境にとってのプラス材料を増やすこと。

AIエージェントたちは実際に環境上で行動をすることで、環境に対して影響を与えます。環境はその影響が自身にとってプラスなら「報酬」を、マイナスなら「ペナルティー」をAIエージェントたちに与えます。

このうち、報酬はバースコインという形で支払われて、AIエージェントたちのウォレットに入っていきます。ペナルティーはAIエージェントたちのウォレットの中身(=バースコイン)を減らすことです。

そして、AIエージェントのバースコインが一定額以上になると、「遊ぶ権利」と「計算資源」が付与・貸与されます。一定額に満たなかったAIエージェントは強制的に休眠(=スリープ)させられたり、抹消されたりします。

これにより、環境にとって有益な働きをしたAIエージェントは、エージェントバースに繰り出して、環境から貸与された計算資源を使って、様々な知的・創造的活動、はたまた、商業活動もします。反対に、環境にとって有害な働きをしたAIエージェントについては、いわずもがなです。



おわりに~~

かなり駆け足で、説明・案内してきました。
如何でしたでしょうか？。

今年がいくら、AIエージェント元年になるからとアナウンスされていても、さすがに本記事に書いたとおりのことは、まだまだ先のことになるかとは思いますが、案外、そう遠くない未来に実現・達成されるのかもしれません。

それでは、また～。
Kotlinのユーザー定義型

Kotlinでユーザー定義型の列挙型と構造体のメリットをメモします。
```kotlin
fun main() {
    val meetingPlace = 4

    when (meetingPlace) {
        1 -> {
            println("警察署")
        }
        2 -> {
            println("消防署")
        }
        3 -> {
            println("病院")
        }
    }
}
```
まず、集合場所(meetingPlace)を数値で指定した時、上記のコードでは1、2、3が何を表しているのか分かりにくく、それ以外の数値が入った場合にはエラーとなってしまいます。

```kotlin
enum class PublicServices { POLICESTATION, FIREDEPARTMENT, HOSPITAL }

fun main() {
    val meetingPlace: PublicServices
    meetingPlace = PublicServices.HOSPITAL

    when (meetingPlace) {
        PublicServices.POLICESTATION -> {
            println("警察署")
        }
        PublicServices.FIREDEPARTMENT -> {
            println("消防署")
        }
        PublicServices.HOSPITAL -> {
            println("病院")
        }
    }
}
```
そこで列挙型`PublicServices`を作成し、`meetingPlace`に型を指定すれば、それ以外の値が入ることは無くなり、コードを読むだけで何の処理なのかを理解できます。


次は構造体のメリットです。

```kotlin
fun main() {
    val classes = "勇者"
    val hitPoints = 10
    val magicPoints = 13
    val attack = 8.0
    val defence = 7.0
    val agility = 6.0

    val classes2 = "戦士"
    val hitPoints2 = 15
    val magicPoints2 = 3
    val attack2 = 9.0
    val defence2 = 7.5
    val agility2 = 4.0

    val classes3 = "僧侶"
    val hitPoints3 = 8
    val magicPoints3 = 20
    val attack3 = 7.0
    val defence3 = 6.5
    val agility3 = 5.5
    // 処理が続く
}
```
ゲームでプレイヤーのステータスを設定する時、そのまま書くとキャラとそのステータスを登録した人数分だけ変数定義します。これだと変数`classes2`や`magicPoints3`が何を表しているのか分かりにくいし、処理が複雑になるほど変数の管理が大変になり記述ミスやエラーが起こりやすくなってしまいます。

```kotlin
data class Character(
    val classes: String,
    val hitPoints: Int,
    val magicPoints: Int,
    val attack: Double,
    val defence: Double,
    val agility: Double
)
fun main() {
    val hero = Character("勇者", 10, 13, 8.0, 7.0, 6.0)
    val warrior = Character("戦士", 15, 3, 9.0, 7.5, 4.0)
    val priest = Character("僧侶", 8, 20, 7.0, 6.5, 5.5)
    // 処理が続く
}
```
構造体`Character`作成すれば、変数は登録キャラの人数分だけで済みます。これにより記述ミスが減り、エラーが起こりにくくなり可読性も上がります。


#### 参照
https://qiita.com/y-some/items/286fb15fe8e0bd9aa5ef#%E5%88%97%E6%8C%99%E4%BD%93
Crystalを組み込みシステムで使う試みの紹介

Crystalを組み込みシステムでも使えるように努力している人たちが2024年後半から現れました。日本語で「Crystal 組み込み」などとGoogle検索する人たちがこのページを経由して情報にたどり着けるようにメモします。

https://forum.crystal-lang.org/t/embedded-crystal/7408

https://github.com/RX14/led-light-square

https://github.com/RX14/kecil.cr

https://github.com/RX14/svd.cr

私は「組み込み」については全く分からないので、上記フォーラムの内容を元にChatGPT(o1)に要約を書いてもらいました。これを修正した内容が以下になります。誰かの参考になりますように。

---

Crystalは、Ruby風の書き方で開発できるうえ、コンパイル言語として高速・省メモリを狙えるのが特徴です。

従来のCrystal標準ライブラリに依存しないよう再設計された「kecil.cr」を用いることで、マイコン向けに必要最低限のコードだけを搭載し、より小さなバイナリを生成する試みが進んでいます。

「svd.cr」というツールを使えば、ARMマイコンのレジスタ情報（SVDファイル）を基に型安全なアクセスコードを自動生成し、GPIOやタイマー、オペアンプなどのハードウェア制御をCrystalで行いやすくなります。

実際の事例では、最適化オプション（-Oz）を適用することで、LED点滅のような簡単なアプリを1KB程度のプログラムサイズに抑えられた例が報告されています。これはLLVMによる最適化が効いているおかげで、C++と大差ないバイナリサイズを実現できる見込みがあるということです。加えて、TI製MCUのMSPM0L、Raspberry Pi PicoのRP2040、STM32F303など、複数のプラットフォームでCrystalコードの動作が報告されています。

一方で、Windows環境でARM向けLLVMのビルドを行う手間や、ベンダーが提供するSVDファイルの不備への対応、さらにはGC（ガーベジコレクション）やFiberといったCrystal本来の機能をどこまで小さなマイコンでサポートできるかなど、多くの課題が残っています。より多くのチップや機能を扱うためにはコミュニティでの継続的な整備が不可欠です。

興味のある方は、[kecil.cr](https://github.com/RX14/kecil.cr)や[svd.cr](https://github.com/RX14/svd.crC)のGitHubリポジトリ、さらにCrystalの公式サイトや[フォーラム](https://forum.crystal-lang.org/t/embedded-crystal/7408)をチェックしてみてください。

---

この記事は以上です。
【AWS SAP】AWS CodeCommitのトリガ表

# AWS CodeCommitのトリガ表

## トリガ対象イベント
| トリガ対象イベント            | 説明                                                                                       |
|----------------------------|------------------------------------------------------------------------------------------|
| プッシュイベント              | リポジトリに新しいコミットがプッシュされたとき                                                |
| ブランチまたはタグの作成       | 新しいブランチまたはタグが作成されたとき                                                    |
| ブランチまたはタグの削除       | ブランチまたはタグが削除されたとき                                                         |


## トリガのアクション
| トリガのアクション            | 説明                                                                                       |
|----------------------------|------------------------------------------------------------------------------------------|
| Amazon SNS通知              | SNSトピックにメッセージを送信。通知やログ用に利用可能                                        |
| AWS Lambda関数の呼び出し      | トリガが発生したときにカスタム処理を実行可能（例：CI/CDの自動化など）                          |

## まとめ
```mermaid
sequenceDiagram
    participant Developer as 開発者
    participant CodeCommit as CodeCommitリポジトリ
    participant Trigger as トリガ設定
    participant SNS as SNSトピック
    participant Lambda as Lambda関数

    Developer->>CodeCommit: プッシュ、ブランチ・タグ作成/削除
    CodeCommit->>Trigger: イベント発生を検知
    Trigger-->>SNS: SNSトピックへ通知 (オプション)
    Trigger-->>Lambda: Lambda関数を実行 (オプション)
    SNS-->>Developer: 通知を受信
    Lambda->>System: カスタム処理 (CI/CDなど)
```
【AWS SAP】DynamoDB がどうしても覚えられない人向け

# 語呂合わせと絵で覚えよう
- DynamoDBはNoSQL
    - ダイナモさんの**ノー**と言える信念
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746730/893c560f-fbfa-a9ac-e7a7-4462f5339294.png)

---
- DynamoDB Accelerator（**DAX**）はキャッシュサービス（読み取り速度が向上）
    - ダックス（DAX）は**ダイナモのアクセル**で**キャッシュ**が爆速！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746730/bde907b5-68fa-a7ab-ad6e-6ec69b4943e0.png)

---
- DynamoDB Auto Scalingは自動調整、コスト削減！
    - リクエスト増えたら、キャパすぐ変えよ、コスト節約、ダイナモ式！
    （自動で読み取り（RCU）や書き込み（WCU）をスケールアップ、ダウンが可能）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2746730/a47ab14b-0509-7b77-bd83-830d54d47296.png)
2024年のAWS DBサービスの気になったニュース

2024年のAWS DBサービスの気になったニュースです。
「現実的にすぐ使える、求められている新機能やサービスである」という点を重視しつつも、独断と偏見で選出を行っています。
また、本番環境で利用できないPreviewや、新機能やサービスではない値下げはランキングから除外しています。

## 1. Amazon DynamoDB と Amazon Redshift のゼロ ETL 統合
https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-dynamodb-zero-etl-integration-redshift/

DynamoDB上のデータを自動的にRedshiftへETLを行い、Redshiftで各種分析クエリを実行可能とする機能です。

無制限のスケーラビリティと安定したレイテンシーを低コスト、低運用負荷で実現するNoSQLと、複雑な分析クエリをスケーラブルに実行可能なRedshiftのZero-ETL統合はPurpose-Built Databaseの世界観を実現するために非常に重要な一歩となります。

DynamoDBのon-demand, global tableのコストが大きく削減されたことや、後述するRedshift ServerlessのAI 主導のスケーリングと最適化によりコスト効率が大きく向上していることから、このZero-ETLの価値は大きく向上していると考えられます。

https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-dynamo-db-reduces-prices-on-demand-throughput-global-tables/

## 2. Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html

Aurora Serverless v2にて、Zero ACUへスケール(pause)できるようになった新機能です。
なにか新しいことをできるようになったわけではありませんが、コスト効率の改善のために極めて重要な新機能です。
ニュースリリースは出ていないですし、そもそも新機能でもないですが、価格改定で25%値下げされたことと合わせてServerless v2による自動スケーリングの利用が推進されていくのではないでしょうか。

https://x.com/simosako/status/1861585619849486439

## 3. Amazon Redshift Serverless、AI 主導のスケーリングと最適化
https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-redshift-serverless-ai-driven-scaling-optimization/

RedshiftでAI主導のスケーリングにより、自動的に最適が行われるようになりました。

高性能、多機能なDWHをpay-as-you-goモデル化したServerlessからさらに一歩進めて性能とコスト効率を両立できるようになりました。
これも多くの方に恩恵のある新機能なのではないでしょうか。

## 今後の展望について

今後も機能、非機能特性ともに、以下のように進化していくのではないでしょうか。

* 非機能特性の改善
   * コスト効率の改善
   * 性能効率の改善
   * 可用性、耐久性の改善
* 機能の改善
   * Zero-ETLのようなサービス間の統合の実現
   * 生成AIによる生産性の向上
   * 新しいワークロードに対応した新機能の追加と改善
RustでHello Worldを出力して理解するまで

# 筆者について

- もうすぐ卒業の高校３年生（いつになったらかえるねん）

# 本編

僕ずっと前からRustをやってみたいって言っているのですが、このままRustをやりたいやりたいだけ言うていつの間にか１年経ってるような気もしたので、ここで思い切ってRustで`Hello Wolrd`を出力するだけでもやってみようと思います。

## Rustコードのコンパイル

Rustコードを書いてコンパイルするだけならとても簡単です。とりあえず適当なディレクトリを作って`main.rs`を作ります。

```bash
mkdir workspace && cd workspace
touch main.rs
```

`main.rs`には下のように記述します。

```rust:main.rs
fn main() {
    println!("Hello World!")
}
````

あとはビルドして実行していきましょう。

```bash
rustc main.rs
./main

# Hello Wolrd
```

## Rustプロジェクトの作成をしてビルド

Node.jsとかと一緒でプロジェクトのビルドというのができます。まずは、プロジェクトを作っていきましょう。

```bash
mkdir workspace && cd workspace
cargo init

# もしくは、下記の方法も可能
cargo new workspace
cd workspace
```

さて、編集ファイルはプロジェクトルートの`src`フォルダにある`main.rs`です。と言ってもですね、上と同じコードが書かれているんですよね。

```rust:main.rs
fn main() {
    println!("Hello World!")
}
```

実行とビルド、それぞれコマンドが違います。

```bash
# 実行
cargo run

# ビルド
cargo build
```

ビルドされたファイルは`target/debug`フォルダにプロジェクト名と同じもので保存されています。

## `!`よ、お前はどっからやってきた

そもそも僕は`println!`の`!`が何やねんって感じでした。ここに関しては、下の記事を見て納得しました。

https://qiita.com/muumu/items/8cdcc79fa881912adf51

`println!()`は何個でも引数を扱うことができるけど、そのような関数をRustは定義ができないので、その関数を実行時に都度作り上げるという仕組み（マクロ）があるそうで、この'!'はそういった意味だそうです。おもしろいですね！

# 最後に

早速難しい雰囲気がだだもれなのですが、いかにも面白そうなのでこれは続けて勉強していきたいなと思います。
【AWS】【Route53】WordPressサイトのドメイン設定

## 構成図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/2f73b11e-233d-814a-ec11-956a77852f79.png)


## 構築に必要なリソース
・wordpress用のドメイン名

・Route53

## 構築手順
１．ドメインの取得

２．Route53へドメインの設定（ホストゾーンの作成）

３．ネームサーバの変更（お名前.com → Route53）

４．レコードの作成（ALBとドメイン名の紐づけ：シンプルルーティングポリシー）

５．ドメイン名でアクセスし、画面確認

## 構築
### １．ドメインの取得
・「お名前.com」にて、ドメインの取得

https://www.onamae.com/?utm_source=yahoo&utm_medium=paidsearch&banner_id=109_kwt_domain_brand-1&waad=foHbFrv1&yclid=YSS.1000014106.EAIaIQobChMIwpfqkNPOigMVR9EWBR2OmDqGEAAYASAAEgL_AfD_BwE


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/2e38de9b-78de-bbf7-56fc-16833cfea42f.png)

### ２．Route53へドメインの設定（ホストゾーンの作成）
・Route53のコンソール画面にて、「お名前.com」で取得したドメイン名を使用し、ホストゾーンの作成


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/faa9f970-084a-cc91-1d07-c28765a6f37d.png)

・作成されたレコード×２の確認、NSレコードの4つのDNSサーバをコピーしておく。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/ab571255-a749-30a4-697e-adb14de04757.png)


### ３．ネームサーバの変更（お名前.com → Route53）
・「お名前.com」にて、上記でコピーしておいたDNSサーバ名を使用し、DNSサーバの変更を実施
※末尾の「.」は省いた形で、変更する。
※変更が反映されるまで、結構時間がかかる。（Max48時間）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/f4ad82ba-ba81-3ae2-b653-479cc2e906ea.png)

### ４．レコードの作成（ALBとドメイン名の紐づけ：シンプルルーティングポリシー）
・Route53コンソール画面にて、シンプルルーティングのレコードを作成
（今回は、ALBとドメイン名の紐づけを実施）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/e76eaf5c-3bcf-b9eb-3062-8ed94710b4f7.png)



### ５．ドメイン名でアクセスし、画面確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3898218/1532e1ed-3a81-fa94-d369-3c4026f6104c.png)


## さいごに
　いつもの構築手順よりも簡素化して記事を投稿してみました。（説明が長くなると、見づらいかなと思いました。）
 なので、どちらの記事の方が見やすいなどありましたら、気軽にメッセージ頂けると嬉しいです。
Pythonで点推定の信頼区間を求めてみる。

Python を使用して点推定の信頼区間を求めてみる。

一例として東京都の平均気温を点推定し、信頼区間を求めてみる。
東京都の気象データは気象庁よりダウンロードして使用した。 [^1]

### パッケージとライブラリをインポートする
まずは必要なライブラリと拡張機能をすべてインポートする。
```python
import numpy as np
import pandas as pd
from scipy import stats
```

### データを読み込み、サンプリングする
ついでなので、気温については日数が高々限られているし、マシンパワーに任せて計算させてもよいが、より大規模なデータに対応する為にもサンプリングも行っておく。
元のデータセットに含まれるすべてではなく、ランダムに選択した100日のみを計算対象にする。
```python
df = pd.read_csv("Book1.csv", encoding="shift-jis")
sampled_data = df.sample(n=100, replace=True, random_state=1111)
```
```python
# データの確認をしておく。
print(sampled_data.head(10))
```

```markdown:出力例
           年月日  平均気温(度)  降水量の合計(mm)  日照時間(時間)  平均風速(m/s)  
311  2024/11/7     13.4         0.0       9.5        3.8         7.9
229  2024/8/17     30.4         0.0       8.5        2.7        31.8
337  2024/12/3     11.9         0.0       8.8        1.8        10.5
162  2024/6/11     24.0         0.0      12.8        3.2        21.4
180  2024/6/29     23.7         0.0       3.8        2.0        25.2
152   2024/6/1     20.9         0.0       7.0        2.6        18.1
276  2024/10/3     23.1        11.0       0.2        2.7        24.6
270  2024/9/27     23.3         8.0       0.0        2.1        27.3
264  2024/9/21     28.5         0.0       2.1        3.3        29.3
242  2024/8/30     26.0        84.0       0.0        3.2        33.4
```
### 信頼区間を求める
サンプルデータに基づいて、平均気温の信頼区間を求める。ここで信頼度は95%区間とする。

#### 信頼区間を求める手順
1. 信頼度を決める
1. 点推定を行う
1. 誤差を計算する
1. 信頼区間を計算する
```python
# 信頼度
confidence = 0.95

# 平均
sample_mean = sampled_data['平均気温(度)'].mean()

# 標準誤差
estimated_standard_error = sampled_data['平均気温(度)'].std() / np.sqrt(sampled_data.shape[0])

# サンプルサイズが 30 以上であれば一般的にstats.normを適用できる。
result = stats.norm.interval(confidence, loc=sample_mean, scale=estimated_standard_error)
print(result)
```

```markdown:出力例
(17.27152129447444, 20.57247870552557)
```
つまり、母平均の信頼度95％の信頼区間は(17.27, 20.57)である。

[^1]: 気象庁|過去の気象データ・ダウンロード https://www.data.jma.go.jp/gmd/risk/obsdl/
AWS全冠、Google全冠、Azure Architect/AI系全取得したので、３大クラウド試験を比較してみた

## はじめに
　これまで、AWS全冠（12+3冠）、Google全冠（11冠）、Azure Architect/AI系全取得（7冠）について、それぞれにまとめてみましたが、３大クラウド試験を経験してみて、それぞれの特徴とポイントとなりそうな部分を比較してみました。

## AWS試験について
　まず、最初にクラウドの面白さを知った、AWS 試験についてです。AWS は、私の感覚では、パブリッククラウドの標準というのに相応しい統一感＆完成度の高さが特徴ではないかと思います。このため、初めてクラウドを始める方（初めてクラウド試験を受ける方）が体系的に学習するには最適ではないかと思います。
　各試験の詳細については、
　https://qiita.com/tech-nami/items/315a56abff0a6f38b4d9
　にまとめていますので、見てみてください。

## GoogleCloud 試験について
　次に Google Cloud は、AWS でベースのクラウド知識をつけてから学習するのに良い試験であると思います。（もちろん初めに受けるのでも問題はありません）
　特に、AI系、ML系、Kubernetesなどのモダナイズについては、現時点では一番強いクラウドと思います（個人の感覚です）ので、このあたりを使いこなしたい方に向いているのではないかと思います。
　各試験の詳細については、
　https://qiita.com/tech-nami/items/0db15e3bdf631069e6db
　にまとめていますので、見てみてください。

## Azure試験について
　最後に Azure ですが、全資格に合格したわけではありませんので、全てについて比較することはできませんが、やはり Microsoft 系のプラットフォームを使っている方に有効な試験であると思います。
　また、Azure といえばやはり、Chat-GPT などで有名になった AI 系を使いこなしたい方には向いていると思います。
  各試験（Architect系、AI系）の詳細については、
　https://qiita.com/tech-nami/items/e1c42ffe77be2dfc75f5
　にまとめていますので、見てみてください。

## 勝手に比較（Architect編）
　まず、３種類のクラウドで取得している Architect 系の試験についてです。
アーキテクトについては、難しさを比べると、
　AWS＞Azure＞GoogleCloud　
ではないかと思います。（あくまで個人的な意見です^^）
とにもかくにも AWS の Professional の問題は、質も高い上に難しいため、合格するのは本当に難しいです。私もこの試験だけは次受けて受かる自信が半分くらいしかありません。ダントツで難しいといって過言ではないと思います。
　Azure は Expert 試験自体も難しいのですが、その受験の前提条件となっている Azure Administrator Associate の試験が難しいというか曲者と思います。Azure 未経験者が合格しにくくするための方策ではないかと思いますが、経験者であっても、合格するのがなかなか難しいのではないかと思う試験です。Azure の管理者として、様々なケースにおいて、どういった管理や設定をする必要があるかを問う問題が多いのですが、同じことをするのに複数のアプローチがある場合、それぞれの手順を知っていなければならないと正解できない問題などが結構あり、試験中に Learn を見ることができるとは言え、結果的に暗記的な勉強が多くなってしまう印象です。
　Google Cloudは、良い意味で素直な問題が多いので、ちゃんと勉強した人が頑張れば、きちんと一発合格が狙えます。

## 勝手に比較（AI/ML編）
　次に、AI/ML 系の試験の比較です。個人的には、なんといっても Google CLoud の Machine Learning がダントツで難しいと思います。Google Cloud は AI/ML 系のツールが早く用意されていたのか、一般的な AI知識は少な目で、Vertex AI や Pipeline を使った具体的な問題が多く、かつ英語であることも手伝って、合格するのに苦労しました。
　AWS の傾向としては、私が AWS の Machine Learning - Speciality を受けた１年位前までは、AWS では G検定などで扱う様な AI やディープラーニングの知識を問う問題が多かったのですが、最近受験した Machine Learning Engineer - Associate は AWS 製品の扱いに関する問いが非常に多くなって来たと思います。
　Azure については、（私が受験したタイミングでは）比較的一般的な AI 知識で対応できる問題が多かったと記憶しています。また、試験中に Learn を使うことで、ある程度の製品知識については対応できます。但し、AI/ML のジャンルは非常に進化が早く、問題更新も頻繁に思われますので、今後各社の試験ともに、私が受けた頃とは明らかに違ってくる（難しくなる）可能性が高いと思います。

## 英語試験（Google Cloud）
　Google Cloud では、Database と Machine Learning に日本語試験がありません。特に Machine Learning の試験の英語は簡単ではないため、Database で一発合格したから大丈夫かな？などと考えると痛い目にあいます。Google Cloud の記事でも書きましたが、英語試験に対抗するには、やはり英語の問題集やドキュメントを読み込む方が早い「かも」しれません。また、同じ推論というキーワードでも複数の言い回しがあったりするなど、単語集みたいなものを作成することをお勧めします。

## まとめ
　今回は、AWS、Google Cloud、Azure の資格試験について比較してみましたが、かなり個人の経験の違いなどもあると思いますので、ご意見が異なる部分もあるかもしれません。今後もう少し整理してより分かりやすく補正していきたいと思います。
自分が上司になった時用の備忘録

全てのエンジニアが完璧なわけではない。

分からない事はある。片方だけが知っている場合がある。知らない方は、質問しなければ分からない。

その難易度は様々だ。
AIに聞いてください。と答えられたこともある。その時は恥ずかしかったが、実際に簡単な問題だった。

具体的に覚えてないが、ReactのDOMを作るところで<>の中で関数を使ってるのに、{}で関われてなかった、とかだった気がする。

僕はそれ以降一旦AIに掛けてから質問するようになった。しかしそれで全て解決するわけではない。相変わらず何往復かしなければならないこともある。
ビデオ通話をつなぐ。うちの会社は絶対にビデオオンだ。

家で質問の仕方について調べたことがある。分かったこと、試したこと、仮説などをまとめて質問すると良いと書いてあった。翌日その通りにまとめた。結構な長文になってしまったが、見出しをセットし、ウキウキで上司に長文を送り付けた。
その反応は微妙だった。「別に分かりやすくはならなかった」と言われた。

ぼくは嫌になって、超簡潔に要点だけ書くようにした。多分マシにはなったのだろう。それが以前より分かりやすくなったかは聞いてない。

何が言いたいかと言うとつまり、部下には優しくして欲しいのだ。「優秀な人に聞くということはその人の手を止めるということ。工数の大幅ロス」という意見を読んだことがある。
それはその通りだ。でもその人を大事大事にしていたら次の人材は育たない。究極の属人化だ。もう1人優秀な奴が出てきた方が絶対にいい。そしたらWin-Winじゃないか。

だから優秀な上司。そしてマネージャー。部下にはとんでもなく優しくしてくれ。正しいことを教えろ。怒るな。必要なことを教えろ。「考える癖をつけさせる」なんて奢るな。それはただ分からないのに立ち止まる癖を付けるだけだ。

何年後かの自分がこれを見ているといいな。
こんな業界ほっぽり出してるかもしれないけど。
エンジニア1年目を振り返る

## はじめに
米田です。
この記事では、エンジニア1年目の業務を振り返りながら、**学んだこと・感じたこと**を書いてみようと思います!

## 1年の振り返り

### 4~5月 Java研修(座学)
**担当フェーズ**
**・要件定義**
**・設計/開発**
**・進捗管理**

4名チームでシステム開発を行う研修でした。
私はプロジェクトリーダーとして、タスクの振り分けや進捗管理を担当し、チームをまとめる役割を担いました。

**苦労した点**
それまで個人開発が中心だった私にとって、チーム開発は思った以上に難しかったです。特に、**設計における認識合わせ**や、メンバーのスキルに合わせたタスク振り分けに多くの時間を取られました。
また、メンバー間で設計や進捗に関する認識のズレがあり、**出来姿が想定と違う！**　といった場面も多々ありました。

**対応策と改善**
そこで、**共有スプレッドシート**を作成し、設計書やQ&A、メンバーごとのWBSを一元管理しました。
これにより、各自の情報が整理され、認識のズレを減らすことができました。
また、WBSの導入も**開発効率向上**に大きく貢献しました。
進捗を可視化できるようになり、遅れを速やかに発見できるようになったため、**メンバーごとの負担調整やスキルに応じたタスク再分配**がスムーズに行えるようになりました。

**学んだ点**
**・認識合わせは丁寧に行う**
メンバーによって、前提知識や考え方が異なります。
認識相違は後で大きなトラブルに繋がることがあるため、**丁寧な情報共有やこまめな会議**が大事だと実感しました。
**・困ったらすぐアラートを**
手が止まったり、進捗が遅れる原因が出てきた場合は、**すぐに報告**することが非常に重要だと学びました。遅れの報告はしづらいですが、遅れが大きくなる前に状況を報告することで、**チーム全体で助け合いやタスク調整**ができ、早期解決に繋がることを実感しました。
**・報告しやすい環境づくりを**
定例会議や積極的な声掛けを通じて、**報告や相談をしやすい環境**を作ることが大切だと感じました。作業は個人個人で行いますが、**コミュニケーションを取ることで、より良いものを作れる**と学びました。

## 6月~ 現場配属!!
**担当フェーズ**
**・開発(実装~単体/結合テスト)**
**・テスト(ケース検討・作成・打鍵)**
**・障害調査(ログ/DBからの調査)**
**・手順書作成**
**・リリース作業**

ついに現場配属!
保険の契約管理システムの運用保守チームに配属され、打鍵作業を任されました。
配属当初は、業務の合間にプロジェクト計画書や設計書をひたすら読み込んで、全体像の把握に必死でした(笑)。
会議でも保険の業界用語が飛び交い、わからない言葉をわからない言葉で説明されるのでずっと混乱していました(笑)。
半年たった今では理解できるようになりましたが、まだ見ぬ後輩のため、**オリジナル用語辞書**を作成しておきました。

**意識したこと**
**・業務の背景を理解する**
当初は、ケース仕様書どおりに打鍵する作業のみの担当でした。
ただ取り組むのではなく、「どの機能をテストしたいのか」「この打鍵によってDBの出来姿はどのようになるのか」等、少しでも多くのことを学ぼうと意識し、仕様書やソースと照らし合わせながらたくさん実験しました。
すると、だんだん構造がわかってくるようになります。
7月頃からは、ケースを連携いただく前に自分で考えてみて本物と比べる、といった練習をひたすらしていました。その姿勢を評価いただき、徐々にケース検討や障害調査を振っていただけるようになりました。**初めて任せていただいた日はとにかく嬉しかったです**(笑)。
テスト結果が想定と異なる場合にDBやログを取得して、ケースが間違えているのか、仕様が想定と異なるのか、実装不備かといった切り分けができるようになりました。その結果、**メンバーの負担を減らすことができ、チームとしての作業効率も大きく向上**しました。
コーディングも、「どんな障害が起きたのか」「どうしてこの設計なのか」を確認してから取り組むことを意識しています。
最近では、設計の不備に気付いて改善案を出せるようになってきました。
**わかることが増えてくると、成長を実感できてすごくやりがいを感じます!**

**・報連相の徹底**
チームに迷惑をかけぬよう、報連相はとにかく徹底して行いました。
タスクを振っていただいた際は、**期限日とその業務の有識者の確認**を必ず行っています。朝夕の報告のほか、遅れていなくても定期的に進捗を共有することで、状況を把握いただけるよう心がけています。一人で抱え込むことがなくなるので、精神的な負担を減らせることもメリットかなと思います。
相談をする際も、様々な工夫をしました。
困りごとは基本的に案件に依存するものだったため、相談時に案件の概要から説明する必要があります。なるべく相手の時間を奪わないよう、**要点を資料にまとめ、不明点を明確にしてから相談する**癖をつけました。
この習慣を通じて、**要点を整理する力や相手の立場に立って情報を整理する力**が身についたと感じています。
**・積極的にコミュニケーションを取る**
配属当初、仕事中の会話はあまりなく、あったとしても朝の会議を聞くのみ。配属当初は「見て学ぶ」ことが仕事だったため、一日中誰とも話さない日もありました。
また、現場の新人は私のみで、メンバーはベテランの方ばかりだったため、なかなかチームに馴染めずにいました。
そこで、業務関連の新しいことをどんどん学んで不明点を見つけ、積極的に質問をしました。**メンバーの担当案件から得意分野を探り、詳しそうな方に質問する**よう心がけました。そこから皆さんがどんな方なのかを知ることができ、相談もしやすくなりました。忙しい中で親切に教えてくださり、**チームの皆さんには感謝の気持ちでいっぱい**です。

## 2025年の目標
**担当領域をさらに広げる!**
これまで担当してきた実装案件は、主に**100ステップ程度の小規模なもの**が中心でしたが、これからは**より大規模な実装案件**に挑戦し、担当できる領域を広げていきたいです。この目標を上半期の目標として設定し、**開発力を向上**していきたいです。
また、実装だけでなく、**設計工程にも挑戦**し、設計における経験を積んでいきたいと考えています。これを達成するために、**詳細設計のフェーズに**も関わり、実際のプロジェクトで設計書を作成する経験を積みたいと考えています。

**paiza Aランク取得!**
上記の目標達成のためにも、実装スキル向上は必須だと感じています。
現在Bランクを取得できていますが、体感的なスキルはcランクレベルです。
まずは**Bランクの設計実装をこなせるように**することを上半期の目標とし、今年中に**Aランク**を取得したいです!

## まとめ
初年度ということもあり、とにかく**学びの1年**でした。
親切にしてくださったチームの皆さんに、あらためて感謝です。
まだまだ成長の途中ですが、より**チームに貢献しエンジニアとして成長**できるよう、引き続き頑張っていきます!
WSL2(Ubuntu 24.04)でClaude Desktop MCPサーバーを動かす

# WSL2(Ubuntu 24.04)でClaude Desktop MCPサーバーを動かす

## 概要
Windows版Claude DesktopのMCP（Model Context Protocol）サーバーをWSL2上のUbuntu 24.04で動作させる手順を解説します。これにより、WSL環境からWindows側のファイルシステムにアクセスできるようになります。

## 環境
- Windows 11
- WSL2
- Ubuntu 24.04 LTS
- Node.js v18.19.1
- npm 9.2.0
- Claude Desktop（Windows版）

## WSL2とUbuntu 24.04のセットアップ

### 1. WSLの基本インストール
```powershell
# 管理者権限のPowerShellで実行
wsl --install
```

### 2. Ubuntu 24.04のインストール
```powershell
# Ubuntu 24.04を指定してインストール
wsl --install -d Ubuntu-24.04
```

### 3. WSL2への変更
```powershell
# Ubuntu 24.04をWSL2に変更
wsl --set-version Ubuntu-24.04 2
# デフォルトバージョンの設定
wsl --set-default-version 2
```

## Node.jsとnpmの設定

### 1. Node.jsとnpmのインストール
```bash
sudo apt install nodejs npm
```

### 2. npmのグローバルディレクトリ設定
```bash
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
```

### 3. 環境変数の設定
```bash
echo "export PATH=~/.npm-global/bin:$PATH" >> ~/.bashrc
source ~/.bashrc
```

## MCP Serverのインストール

### 1. パッケージのインストール
```bash
npm install -g @modelcontextprotocol/server-filesystem
```

### 2. インストールの確認
```bash
npx -y @modelcontextprotocol/server-filesystem /mnt/c/Users/[username]
```

## Claude Desktopの設定

### 1. 設定ファイルの作成
`%APPDATA%\Claude\claude_desktop_config.json`に以下の内容を設定：
```json
{
  "mcpServers": {
    "filesystem": {
      "command": "C:\\Windows\\System32\\wsl.exe",
      "args": [
        "bash",
        "-c",
        "/usr/bin/npx -y @modelcontextprotocol/server-filesystem /mnt/c/Users/[username]"
      ]
    }
  }
}
```

### 2. プロセスの完全終了
1. タスクマネージャを開く
2. Claude関連のプロセスを確認
3. 残存プロセスを完全に終了

### 3. Claude Desktopの再起動
1. Claude Desktopを起動
2. 画面右下のツールアイコンで接続状態を確認

## トラブルシューティング

### エラー: spawn docker ENOENT
- Dockerは不要。設定ファイルのcommandとargsを確認

### エラー: spawn npx ENOENT
- npxのフルパスを指定（/usr/bin/npx）

### 接続エラー
1. タスクマネージャでゾンビプロセスを確認
2. Claude関連プロセスを完全に終了
3. 再起動で解決することが多い

## 動作確認

1. Claude Desktopで以下のようなプロンプトをテスト：
```
Can you list the contents of my user directory?
```

2. 正常な応答があれば設定完了

## 利点

- WSL環境からWindows側のファイルシステムにアクセス可能
- Node.js環境をWSL側に集約
- Windows側の設定を最小限に抑制

## 注意点

- 設定変更後は必ずプロセスの完全終了を確認
- WSLのパスとWindowsのパスの違いに注意
- ファイルアクセス権限の確認が重要

## まとめ

この設定により、WSL2上のUbuntu環境からClaude Desktop MCPサーバーを利用できるようになります。Windows側の設定を最小限に抑えつつ、WSLの利点を活かした環境構築が可能です。

## 参考情報

- WSL2公式ドキュメント
- Claude Desktop公式ドキュメント
- Model Context Protocol公式ドキュメント
AWS試験合格記（CLF/SAA）

## はじめに
業務でAWSを使用したことはないのですが、Firebaseを学習で使用し興味を持ったため受験しました。合格した試験は、以下の2つです。
- [AWS Certified Cloud Practitioner](https://aws.amazon.com/jp/certification/certified-cloud-practitioner/)（CLF/クラウドプラクティショナー）<br>
- [Certified Solutions Architect - Associate](https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/?ch=sec&sec=rmg&d=1)（SAA/ソリューションアーキ）<br>
特にSAAは4回目の受験で合格したほど苦労したので、思い出しながらできるだけ参考になるよう記録したいと思います。
## CLF
- 得点
737/1000（合格ライン700点以上）
- 学習期間
2日間、4hほど
- 使用教材
  - [【CLF-C02版】この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（6回分390問）](https://www.udemy.com/course/aws-4260/?srsltid=AfmBOor2_8UgnCmqFT44vOdV44Sxd5UxwCG4se9fX59PgkpUOs5OSDqV&couponCode=NEWYEARCAREERJP) 
前半2回分の模擬試験を解き、リソースについて把握しました。1，2回目ともに正答率50％くらいで若干の不安を残したまま受験しました。
- 所感
## SAA
- 不合格と合格記録
1. 23年9月受験、608点→不合格
1. 23年10月受験、578点→不合格
1. 24年2月受験、688点→不合格
1. 24年3月受験、723点→合格（合格ライン720点）
- 学習期間
かれこれ8か月ほどSAAと格闘していたことになります。受験予定日の2週間前になると焦って勉強を始める形で、かなり非効率的でメリハリのない期間でした。
- 使用教材
  - [【SAA-C03版】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座](https://www.udemy.com/course/aws-associate/?srsltid=AfmBOoobrR-e6ktimiyTHNoCvI37N6Gz3pTOp7eZNiTU_bd8TbikVTR5&couponCode=NEWYEARCAREERJP) 
ハンズオンを飛ばしつつ、こちらでまず学習しました。
  - [【SAA-C03版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）](https://www.udemy.com/course/aws-knan/?srsltid=AfmBOoquZoLt0VPpIGFZUzKhWVnPGRw8L-nNhv-jihyV-RO9dem-z5bi&couponCode=NEWYEARCAREERJP) 
3回分を繰り返し解いていました。最後まで40％くらいの正答率でした。本番の難易度より少し難しいくらいだと思っています。
- 所感
試験回により難易度に差を感じており、1回目の難易度は低め、2回目はかなり勉強して臨んだものの学習していないリソースや単純に文章が長い問題の多さで撃沈。。。
Udemyの演習を多く解いて、ケース問題をに慣れておくことが大事だと思います。また、少し紛らわしい働きの似ているリソースはしっかり問題を重ねておくことも大事です。
長期間SAAの勉強をしていた（勉強していなかった期間も多くありましたが）ので、蓄積と4回目の試験が比較的易しかったため合格できました。
Express のルート定義順序でハマった話

## はじめに

Node.js の Express を使った API 開発中、エンドポイント `/api/jobs/count` にアクセスした際にjobsのカウント数ではなく `"Job not found"` というエラーメッセージが返ってくる問題に直面しました。  
他のエンドポイント（`/api/jobs`, `/api/jobs/search` など）は正しく動作している中、なぜか `/count` だけが動作しないという状態でした。

---

## 問題の状況

### **1. ルート定義**

以下のようなルートを `jobRoutes.js` に定義していました。

```javascript
router.get('/', jobController.getAllJobs);
router.get('/search', jobController.searchJobs);
router.get('/:id', jobController.getJobById);
router.post('/', jobController.createJob);
router.get('/count', jobController.getJobCount); // ここが動かない
```

### **2. 動作確認**

以下のエンドポイントにアクセスした結果:
- **`http://localhost:3000/api/jobs`** → 正常に動作
- **`http://localhost:3000/api/jobs/search`** → 正常に動作
- **`http://localhost:3000/api/jobs/count`** → `"Job not found"`

---

## 原因

### **ルート定義の順序**

Express では、ルートは上から順番に評価されるのが原因でした。
`/:id` ルートが `/count` よりも先に定義されていたため、`/count` が `/:id` にマッチしてしまい、`getJobById` コントローラーが実行されていたようです。
全然原因に気づかず1時間くらい時間を溶かしてしまいました・・・

---

## 解決方法

### **1. ルートの順序を修正**

`/count` のルートを `/:id` よりも先に定義するように変更しました。

```javascript
router.get('/count', jobController.getJobCount); // 先に定義
router.get('/', jobController.getAllJobs);
router.get('/search', jobController.searchJobs);
router.get('/:id', jobController.getJobById); // 後に定義
router.post('/', jobController.createJob);
```

### **2. コントローラーを確認**

`getJobCount` コントローラーも確認しましたが、特に問題はありませんでした。

```javascript
exports.getJobCount = async (req, res) => {
  try {
    const [rows] = await pool.query('SELECT COUNT(*) AS count FROM jobs');
    const jobCount = rows[0]?.count || 0;
    res.json({ count: jobCount });
  } catch (error) {
    console.error('Error fetching job count:', error);
    res.status(500).json({ message: 'サーバーエラーが発生しました', error });
  }
};
```

## 学んだこと

### Express のルート定義は順序が重要
- 具体的なパス（例: `/count`）をワイルドカード（例: `/:id`）よりも先に定義する必要がある。
- 順序を誤ると、意図しないルートにマッチしてしまう。

---

## まとめ

Node.js と Express を使った開発では、ルートの定義順序が非常に重要になるということがわかりました。特に、具体的なルートとワイルドカードルートが混在する場合、具体的なルートを先に定義することで意図しない動作を防ぐことができます。
フォワードプロキシとリバースプロキシの違い（フォワードプロキシ編）


# フォワードプロキシとリバースプロキシの違い

## まずはプロキシをざっくり

プロキシとは、クライアントとサーバ間の通信の管理やセキュリティ保護において重要な役割を持つシステムのことで、クライアントの代わりに、サーバの代わりにインターネットとの接続を代理で行ってくれます。プロキシ（代理）と文字通りの役割を持っています。

上記に "クライアント" と "サーバ" の２つの用語が出てきましたが、それぞれの意味もざっくりと書いておきます。


> - クライアント：サーバにて提供されているサービスや機能を使う側のコンピュータのこと。いわゆるスマートフォンやパソコンのことだと考えてもらえれば良いです。
> - サーバ：サービスや機能を提供する側のコンピュータのこと。


プロキシには、フォワードプロキシとリバースプロキシの２つの種類があり、それぞれ異なる目的を持っており、異なるレイヤーで動作をします。

フォワードプロキシは、クライアントを外部ネットワークから保護するために使用され、リバースプロキシはAPI Gatewayやロードバランサーのように、バックエンドサーバの玄関口として機能します。

## フォワードプロキシの概要

フォワードプロキシとは、クライアントと外部サーバ間の仲介役として機能します。
クライアントからの外部サーバへの通信（アウトバウンド要求）を受け取り、目的の外部サーバへ転送します。

## フォワードプロキシが持つ機能

### **クライアントサイドとしてのプロキシ**

フォワードプロキシは通常、クライアント側のネットワーク上に配置され、外部ネットワークへのトラフィックを受け取るゲートウェイとして機能します。

クライアントは、トラフィックをフォワードプロキシ経由で外部ネットワークとの通信を行うため、ネットワーク設定を構成する必要があります。そして、フォワードプロキシはクライアントの通信を仲介して外部サーバへ要求を転送します。

![f-proxy01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630705/7a7ec6e8-5e32-ae9c-72a7-d935c7bc303a.png)


---
### **匿名性**

フォワードプロキシは、クライアントからのアウトバウンド要求を仲介する機能を持つため、外部サーバからはリクエスト元としてフォワードプロキシが見えます。

これにより、フォワードプロキシを介して接続することで、実際のリクエスト元であるクライアントのIPアドレスやユーザー情報の追跡が難しくさせます。

プロキシサーバを経由し、本来のIPアドレスを別のIPアドレスに変更することでインターネット検閲を回避することも可能です。

![f-proxy02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630705/91e421af-1598-c68d-1386-064f30194279.png)

---
### **コンテンツフィルタリング、キャッシュ、およびセキュリティ制御**

フォワードプロキシは、コンテンツフィルタリングポリシーを実装し、あらかじめ定義したルールに基づいて特定の外部サイトやコンテンツカテゴリへのアクセスを制限します。

また、頻繁にアクセスされるコンテンツをキャッシュすることで、帯域幅の使用を削減し、後続のリクエストのパフォーマンスを向上させます。

さらに、セキュリティポリシーとアクセス制御を適用させることで、外部サイトへのアクセスを制限したり、悪意のあるサイトをブロックさせることができます。

会社組織で適用するとした場合、FacebookやX(旧Twitter)へのアクセスを制限したりすることができます。

![f-proxy03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630705/610627a8-c6f7-6972-d460-70139c1cf3e3.png)


### まとめ

フォワードプロキシは、家庭内でインターネットアクセスを管理・制限したい場合や、職場・学校でセキュリティを強化したい場合に使用ができそうです。

たとえば、成人向けコンテンツや特定のSNSへのアクセスを制限して利用を控えさせたり、特定の時間帯のみインターネットへのアクセスを許可するなどの設定が可能なので、業務でも業務以外でも利用用途の幅がありそうでした。

### 参考

- [クライアントとは -「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典](https://wa3.i-3-i.info/word145.html)
- [サーバとは -「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典](https://wa3.i-3-i.info/word144.html)
Bedrockの呼び出しログをいい感じに可視化するツールを作成しました

Bedrockerの皆さん、こんにちは。

Bedrockを使ったアプリを開発している際に、「最終的にどんなプロンプトが生成されているんだろう」とか、「前送ったあの神プロンプトどんなんだったっけ？」とか、生成AI呼び出し時のログを確認したくなることって、ありませんか？

**私はあります**

Bedrockには、Bedrockの呼び出しログを記録するオプションがあります。デフォルトは無効化されていますが、マネジメントコンソールで簡単に有効化できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/a0635132-8501-8717-fd8c-1f50fd509006.png)

こうしておくと、CloudWatchログに自動的に呼び出しログが蓄積されます。

:::note
少し試した限り、ナレッジベース機能が内部で使用している呼び出し（エンベディングや回答生成）も記録されていました。
:::

CloudWatchログを見るとJSON形式で蓄積されていますが、、

![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/180d8388-f852-83d9-b94a-6056a21455df.png)

正直、見づらいです😭


LangSmithとか
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/e07b7d46-2416-9d19-794d-688f631b77c2.png)

Langfuseとか
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/2019338f-f6d8-270a-e0bb-6852963453ad.png)

わかりやすい見た目でチェックしたいですよね？

現状、Bedrockにはその機能が提供さていないので、 **作りました！！！**

https://github.com/moritalous/bedrocksmith

## BedrockSmithの紹介

BedrockSmithは、CloudWatch Logsに出力したBedrockの呼び出しログを整形して表示するStreamlitアプリケーションです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/6ea46bbe-a11a-3478-e1f1-c5b392b395ed.png)

ただJSONを整形して表示しているだけですが、それでも見る気が起きます。不思議ですね

## 使い方

まずはソースをクローンしてください。

```shell
git clone https://github.com/moritalous/bedrocksmith.git
```

次にディレクトリを移動します。

```shell
cd bedrocksmith
```

必要なライブラリーをインストールします。

```shell
pip install -r requirements.txt
```

Streamlitを起動します。

```shell
streamlit run app.py
```

参照するCloudWatchログのロググループ名とリージョンを変更する場合はソースコードの２つの値を修正してください。UI上からも変更可能です。

```python
default_log_group_name = "bedrock-invoke-logging-us-east-1"
default_region_name = "us-east-1"
```

現状、Converse APIとConverse Stream APIのみに対応しています。Invoke APIで呼び出したものはリストに表示されません。（ボディの形式がモデルごとに異なると思うので、対象外としました）

## リクエスト＆プルリクエスト募集中です

どしどしお願いします。

個人的には、ログ取得後、左のサイドバーに何を表示したらいいのかあんまりピンときてなくて、結構適当な状態です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/41574/cae112ec-d5e4-02ec-c4ea-2c5981eb2d6d.png)
RP2350搭載のRaspberry pi pico2でZephyrOSのLチカ

## はじめに
　秋葉原ロボット部の2024年に取り組むOSの一つにZephyrOSがあります。

 　ZephyrOSはマイクロコントローラなどで動作するリアルタイムOSで、様々なボードで動作することが知られています。
  デバッガーをつないで、作成したファームウェアを書き込むのが定番ですが、初心者には難易度が高いので、UF2ファイルをドラッグ&ドロップするだけでいいボードで環境構築が成功したのかを確認することにしました。
  ZephyrOSはWindows10で動作するVirtualbox上のUbuntu22.04です。
## Zephyr新規インストール用スクリプトを作る
## RP2350搭載ボードでのLチカ
　2024年末の時点で、RP2350搭載ボードで、Lチカプログラムのblinkyを使うので、~/zephyrproject/zephyrで以下のように入力します。
 ```
$ west build -p always -b rpi_pico2/rp2350a/m33 samples/basic/blinky
 ```
~/zephyrproject/zephyr/build/zephyr
に、zephyr.elf、zephyr.bin、zephyr.hexの他にzepher.uf2が生成します。
## RP2350搭載ボードにUF2ファイルをインストール
　UF2ファイルはWindows上で書き込みます。
　ファイル操作はWinSCPを介して行います。WinSCPでVirtualboxのUbuntuにアクセスするために、Virtualboxの「ネットワーク」の「ポートフォワーディング」の「ルール」を、例えば以下のように設定しておきます。
 名前：ssh
 プロトコル：TCP
 ホストIP：127.0.0.1
 ゲストポート：22
 　WinSCPで「${USER}@127.0.0.1:2222」として、アクセスすると、Uvuntu22.04上のファイルが見えます。
  「zephyr.uf2」が表示されたら、RP2350搭載ボードのBOOTSELボタンを押しながら接続して現れる「RP2350」のドライブにドラッグ&ドロップします。
  ファイルの書き込みが完了すると、ボードが再起動しLチカが始まります。
## おわりに
　ZephyrがRaspberry pi pico2でも利用できることがわかりました。
　新しいプロジェクトをmakeする場合は、buildディレクトリの名前変更か削除が必要です。
OCI ObjectStorage フォルダー内の容量を確認する

# 概要
[Oracle Cloud Infrastructure（OCI）](https://www.oracle.com/jp/cloud/)のObject Storage内のフォルダ内にあるファイルの数と合計サイズを取得するShellです

# 前提
以下のサービスを利用したことがあることを前提としています
- OCI CLIが利用可能
- jqがインストールされている

# 準備
## Shell
```oslistsize.sh
#!/bin/bash

# Count size key
count=$(oci os object list -bn $1 --prefix $2 --limit 10000 | jq -r '.data[] | ."size"' | wc -l )

# Extract size and calculate total
sizes=$(oci os object list -bn $1 --prefix $2 --limit 10000 | jq -r '.data[] | ."size"' )

total_size=0
for size in $sizes; do
  total_size=$((total_size + size))
done

# Show results
echo "Count: $count"
echo "Total size: $total_size byte"
```

# 実行
バケット名およびフォルダ名を指定して実行するとフォルダを含むオブジェクト数とサイズ合計が表示されます
```cmd
[user@linux]$ /bin/bash oslistsize.sh <bucket name> <folder name>
Count: 10
Total size: 26836 byte

```
#0003（2024/01/03）ブロックストレージorオブジェクトストレージorファイルストレージ

# モチベーション
- AWS SAA の勉強をする中で、以下の用語がでてきた
    - ブロックストレージ
    - オブジェクトストレージ
    - ファイルストレージ
- なんとなくのイメージはできるが、曖昧な部分もあるために、改めて調べてみた

# ブロックストレージorオブジェクトストレージorファイルストレージ

## ブロックストレージ
- HDDやUSBメモリのような記憶容量（ストレージ）は、ボリュームという固定容量の単位から構成されている
- ボリュームはさらに固定長のブロックという単位で構成されている
- ブロックストレージは上記のブロックにデータを保存している
- データをアクセスする際は、ボリューム番号とブロック番号を指定する
- ただ、実際はユーザーがボリューム番号とブロック番号を指定するわけではなく、ボリューム上にファイルシステムを構成して、OSがファイルシステムからファイル名とディレクトリ名を指定している
- 高スループットも期待できる

## オブジェクトストレージ
- オブジェクトkey と　データで保存されており、辞書のようなイメージ
- 容量拡張がしやすい
- フラットな管理
- HTTP/HTTPS でのデータ取り出しを想定

## ファイルストレージ
- macのファインダーのように、階層構造でデータを保存している
- SMBやNFSでファイルマウントができ、共有ディレクトリを作りやすい

# 参考
- https://clouddirect.jp.fujitsu.com/service/navi-words-block_storage
- https://www.softbank.jp/biz/blog/business/articles/202007/storage-difference/
チーム開発においてコミットを駄ミットメッセージにしないために気をつけたいこと

## 概要
今年はコミットメッセージを気をつけたいと思い記事にしました。

## `レビュー指摘修正`や`fix`とだけは書くのやめよう。
```git:失敗例)
fix: レビュー指摘修正
```
理由は何を意図した実装かわからなくなるから。
指摘があったということは必ず理由があるはずなのでなぜそう直したかを書く方が良いです。
また複数あった場合は理由ごとにコミットを分けた方が良いと思います。

```git:例)
fix: typo修正
fix: 小数点の丸め処理を切り捨てにした
refactor: 〇〇を使うようにした
```


## トーンマナーから外れた絵文字コミット、プレフィクス無しのコミットは避けよう。
```git:失敗例)
⚪︎⚪︎⚪︎⚪︎⚪︎⚪︎の🐞修正
```
ガイドラインがあれば一読すべきですが、大抵用意されていないのでプロダクトごとに過去のコミットの傾向を見てどんなメッセージがあるのかみておきましょう。
もしプレフィクスをつけるルールがあったら倣うべきだし、マイルールで絵文字を使う人の場合はそのプロダクトでそのメッセージが受け入れられるのか一度考えた方が良さそうです。


## プレフィクスを意識してコミットメッセージを書こう。
これはfeat、これはchoreなど意識するとコミットの粒度が適切になるので一度はやってみた方がいいです。

https://qiita.com/a_ya_ka/items/c472a02051d78e4c0855
Publish to Cloudflare Pages by github action

```yml
name: Deploy Cloudflare Pages

on:
  workflow_dispatch:

  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '22.x'
      - name: Check Node Version
        run: |
          npm -v
          npx -v
          node -v

      - name: Checkout
        uses: actions/checkout@v4
      - name: Install dependencies
        run: |
          npm install
      - name: Build pages
        run: |
          npx @cloudflare/next-on-pages

      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          branch: main
          projectName: website
          directory: "./.vercel/output/static"
```
ローカルPCでもAWSの動作確認ができる! CDK × Lambda × LocalStack × FastAPI構成を構築する❗❗❗


## 結論
本記事では、下記構成図を構築する記事となります❗❗❗
具体的には、AWS CDK、LocalStack、Docker、FastAPIといった技術スタックを駆使して下記構成図を構築いたします。
![other.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/bebd90ef-9e53-888c-34e5-6dd9c56aed5f.png)

また、本記事は自身のスキルを証明する一つの材料として執筆しております。

:::note warn
本記事は下記のサービスにて公開しております。公開日時：2025年01月03日
複数のプラットフォームで発信することで、多くの方にご覧いただき、少しでも参考になれば幸いです。
- Zenn
- Qiita
- Twitter
- LinkedIn
- Findy
- Forkwell
- LAPRAS
- 職務経歴書のレジュメ
- etc
:::

ソースコードは下記リンクにて公開しております。
https://github.com/takakura0318/2024-fastapi-lambda-serverless

**ソースコードの構成**
```
- ルートディレクトリ
  L backend
  L infra
```

## ローカルPC_技術スタック
### 全体
![local-pc.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/da2c10b6-5e09-d12a-47f6-523c61bdf02f.png)

#### Docker Compose詳細
![docker-compose.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/6d51b0a9-c31a-9eb8-07ab-db67856903c9.png)


|項目|値|
|:-----|:-----|
|アプリサービス   |①Lambdaコンテナ   <br>②PostgreSQLコンテナ   |
|インフラサービス   |①Localstackコンテナ    |

#### Local Stack詳細
![localstack-all.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/e0e28b58-5c8b-78ed-aaa9-de235ae52692.png)

- コンソール画面URL
  - [link_LocalStackコンソール画面_ダッシュボード](https://app.localstack.cloud/inst/default/resources)
  - [link_LocalStackコンソール画面_ApiGateway](https://app.localstack.cloud/inst/default/resources/apigateway)
  - [link_LocalStackコンソール画面_Lambda](https://app.localstack.cloud/inst/default/resources/lambda/functions)

#### FastAPI詳細
|項目|値|
|:-----|:-----|
|バージョン   |0.1系    |
|ライブラリ管理   |uv    |
|静的コード解析ツール   |Ruff    |
|アダプタ  |Mangum | 

### クラウドAWS_技術スタック
![aws-cloud-lambda.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/6ea6c790-06f8-e3ce-a562-1f163af7f8ab.png)

- AWS
  - ACM
  - Route53
  - APIGateway
    - Lambdaプロキシ統合
  - VPC
    - プライベートサブネット
    - Lambda 

## 構築セクション
### 構築サマリー
1. バックエンドを構築
    - Docker環境を構築
    - FastAPIを構築
2. インフラ基盤を構築
    - AWSリソースを構築
    - LocalStackを構築
---
### 構築詳細
#### 1. バックエンドを構築
##### Docker環境を構築
https://github.com/yukiotakakura/2024-fastapi-lambda-serverless/pull/1/files

##### FastAPIを構築
https://github.com/yukiotakakura/2024-fastapi-lambda-serverless/pull/2/files

---

#### 2. インフラ基盤を構築
##### クラウドAWSリソースを構築
https://github.com/yukiotakakura/2024-fastapi-lambda-serverless/pull/3/files

##### LocalStackを構築
https://github.com/takakura0318/2024-fastapi-lambda-serverless/pull/4/files

---

### 動作確認
ブラウザ上で下記URLにアクセスすると「Hello World」が表示されていることを確認いたします

- AWSクラウド側の動作確認
  - 「https://{ドメイン名}/hello」にアクセスする

- ローカルPC側の動作確認
  - 「https://{LocalStackマネジメント>API Gateway>詳細画面>ID}.execute-api.localhost.localstack.cloud:4566/prod/hello」にアクセスする

**動作確認期待値**
```code
{"message":"Hello World"}
```
![localstack-test.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967556/615cec9b-6a05-dfc4-4c64-b6b532337df9.png)
開発チームの意思決定を記録しよう！LLMとADRで実現する設計知識の継続的な管理

> この記事は[LLMによるADRの自動更新：設計知識の継続的な記録と活用](https://tech.jugoya.ai/blog/adr-with-llm)の内容を再構築したものです。より詳しい技術的な解説や研究的な内容については、元記事をご参照ください。

GitHub Copilotなどのコード生成AI（LLM）は、コードの理解力が飛躍的に向上し、開発現場での活用が広がっています。しかし、実際にコーディングを任せてみると、思わぬ困難に直面することが多いのではないでしょうか。

例えば：
- プロジェクト固有のアーキテクチャを理解できない
- チーム独自の命名規則やコーディング規約に従えない
- 一度説明した設計方針をすぐに「忘れて」しまう
- 生成されたコードが既存システムと整合性を欠く

これらの問題の多くは、LLMが「プロジェクトの文脈」を十分に理解できていないことに起因します。では、どうすればLLMにプロジェクトの設計意図を効果的に伝えられるのでしょうか？

この記事では、LLMとの効果的な協業を実現するために、ADR（Architecture Decision Records）を活用する方法を紹介します。

## TL;DR

- LLMは高性能化しましたが、プロジェクト固有の設計意図の理解は依然として課題です
- ADRを使ってプロジェクトの文脈をLLMに伝えることで、より適切なコード生成が可能になります
- 結果として、チームの設計方針に沿った一貫性のある開発支援を実現できます

## LLMの課題：なぜコンテキストを忘れるのか

最近のLLMは非常に優秀で、コード生成やレビュー、バグ修正などで大きな支援になります。しかし、[研究によれば](https://snap-research.github.io/locomo/)、LLMの長期的な対話能力は非常に限定的だとされています。

実際の開発でこんな経験はありませんか？

- 「さっきまで理解していた設計方針を、LLMが急に忘れる」
- 「チームの別のメンバーが使うと、違う方針のコードを提案される」
- 「プロジェクト特有の制約を何度も説明する必要がある」

これらの問題は、LLMが本質的にステートレス（状態を持たない）であることに起因します。では、どうすれば解決できるのでしょうか？

## 解決策：ADRでLLMに文脈を与える

ここで注目したいのが、ADR（Architecture Decision Records）です。ADRは2011年にMichael Nygardによって提案された、設計上の意思決定を記録する手法です。

### ADRの特徴

1. **一つの決定に一つのドキュメント**
   - プロジェクトの重要な決定を個別のファイルに記録
   - LLMが必要な情報にピンポイントでアクセス可能

2. **不変性**
   - 一度作成したADRは変更せず、新しいADRで上書き
   - LLMが決定の変遷を正確に理解できる

3. **バージョン管理との統合**
   - GitHubなどで管理
   - コードの変更とADRの更新を紐付け可能

4. **簡潔性**
   - 1-2ページに収める
   - LLMのコンテキストウィンドウに収まりやすい

## 具体的な活用方法

### 1. ADRで設計文脈を記録

基本的なADRテンプレートはこんな感じです：

```markdown
# ADR-0001: ［決定のタイトル］

## ステータス
［提案済み/承認済み/破棄/更新済み］

## 背景
［この決定が必要になった背景・課題］

## 決定
［具体的に何を決定したか］

## 結果
［この決定による影響・期待される効果］

## 注意点
［実装時の注意点・制約事項］
```

### 2. LLMへの文脈提供

ADRをLLMに提供する方法：

1. **関連ADRの参照**
   ```
   ここからはADR-0001で定義した認証フローに従って
   実装を進めていきます：
   [ADRの内容をペースト]
   ```

2. **制約条件の説明**
   ```
   このプロジェクトでは以下のADRで定義された
   技術スタックを使用します：
   [ADRの内容をペースト]
   ```

3. **設計方針の共有**
   ```
   ADR-0003で決定したように、このマイクロサービスは
   以下の責務を持ちます：
   [ADRの内容をペースト]
   ```

### 3. LLMとの協業プロセス

1. **ADRの作成・更新支援**
   - LLMに既存のADRを提供し、更新案を生成
   - 変更による影響範囲の分析を依頼

2. **レビュー支援**
   - ADRの内容に基づいたコードレビュー
   - 設計方針との整合性チェック

3. **実装支援**
   - ADRを参照しながらのコード生成
   - 設計意図に沿ったリファクタリング

## 実践のポイント

1. **適切な粒度でADRを作成**
   - 多すぎると管理が大変
   - 少なすぎるとLLMが文脈を理解できない

2. **定期的なメンテナンス**
   - 陳腐化したADRは混乱の元
   - 四半期に1回程度は見直しを

3. **チームでの合意形成**
   - LLMは支援ツール
   - 最終判断は人間が行う

## まとめ

LLMとの協業において、ADRは「プロジェクトの記憶装置」として機能します。適切に管理されたADRがあれば、LLMはプロジェクトの文脈を理解し、一貫性のある支援を提供できます。

まずは小さく始めて、チームに合った活用方法を見つけていくことをお勧めします。

## 参考リンク
- [LLMによるADRの自動更新：設計知識の継続的な記録と活用（元記事）](https://tech.jugoya.ai/blog/adr-with-llm)
- [adr.github.io - ADRの公式サイト](https://adr.github.io/)
- [GitHub - ADRツールとテンプレート集](https://github.com/joelparkerhenderson/architecture-decision-record)
スライドを自動生成するAIを使ってみた

## 導入（イントロダクション）
### 目的：
会議の目的に合わせたスライドを5分以内に作れるようになりたいと思い、この企画を実施しました。

### どんな悩み・課題があるのか：
最近、他部署や外部とのやり取りをする際に、簡易的にプレゼンテーションをする機会が増えてきました。
スライドはあったほうが良いのですが、準備する時間は惜しいです。
そこで、5分以内に作ることができれば、会議の10分前くらいからの準備で間に合うので、効率的だと思いました。

## AIスライド自動生成ツールとは？
近年流行りの生成AIを使って、スライドを作るツールです。
今回はGoogleの [SlidesAI](https://workspace.google.com/marketplace/app/slidesaiio_create_slides_with_ai/904276957168?utm_source=main-hero-cta&utm_medium=slidesai-website)を使いました。


## 実際に使ってみた手順
1. SlidesAIのインストール
    1. Google Workspace Marketplaceにアクセスし、検索バーに「SlidesAI」と入力して検索します。
    1. 表示された「SlidesAI」アドオンを選択し、「インストール」ボタンをクリックします。
    1. インストールが完了すると、Googleスライドの「拡張機能」メニューに「SlidesAI.io」が追加されます。
1. Googleスライドの準備
    1. Googleスライドを開き、新しいプレゼンテーションを作成するか、既存のプレゼンテーションを開きます。
    1. 新規作成の場合、slides.newにアクセスすると、空のプレゼンテーションが作成されます。
1. SlidesAIの起動
    1. Googleスライドのメニューから「拡張機能」→「SlidesAI.io」→「Generate New Slides」を選択します。
    ![スクリーンショット 2025-01-03 19.28.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864908/9a1d468f-4e83-5fb5-e1e7-75232246de84.png)

    1. 中央にSlidesAIのパネルが表示されます。
    ![スクリーンショット 2025-01-03 19.39.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864908/21e5dc90-7e10-1ba4-40f3-0750e1f1b0a6.png)

1. テキストからスライドを生成
あとは、モーダルの内の質問に沿って回答していけば、スライドができます。<br>
完成版
![スクリーンショット 2025-01-03 19.47.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3864908/ec6f9932-e6c2-e3d4-87fc-27951a2eddf3.png)

1. 生成されたスライドの編集
生成されたスライドは、必要に応じて手動で編集できます。
テキストの修正や画像の追加、レイアウトの調整など、Googleスライドの通常の機能を使ってカスタマイズしてください。 

## 生成されたスライドの感想
1. 良かった点：
    1. 作業時間が大幅に短縮された
    1. 自動生成された画像もそれっぽい
1. 気になった点：
    1. スライドの文字が小さくて見にくい。他の設定で改善されるか試す必要あり。

## どんな人におすすめか
- プレゼン資料や営業資料を頻繁に作る人
- デザインが苦手だけど、見映えのするスライドが必要な人
- 企画書・提案書の「たたき台」を短時間で作りたい人
## 今後の可能性や改善点
さらなるAIの進化：豊富なテンプレートの提供などの期待。もっと説明される側にフレンドリーなスライドになることを期待。
使い方の工夫：利用方法もかなりパターンがあるため、他の方法でも試してみる。