OmniAICreator/Qiita-1.07M huggingface dataset:
ARMアセンブリのモダン設計



> _"単純さを追求することは、強さを追求することである。"_  

今日、あなたが手にしているスマートフォンも、タブレットも、  
ほとんどが**ARMアーキテクチャ**上で動いている。  

ARM。  
それは単なるCPU設計ではない。  
**「省電力」と「高効率」という二律背反に挑んだ、設計思想そのもの**である。

この章では、ARMアセンブリの世界を覗きながら、  
**モダンな命令設計とは何か**を、設計者の視点から探っていく。

---

## ARMとは何か？

ARM（Advanced RISC Machines）は、  
1983年に英国Acorn社によって生まれたCPUアーキテクチャである。

特徴は明確だ：

- RISC（Reduced Instruction Set Computer）設計  
- 消費電力の極小化  
- 高密度な命令発行効率  
- モバイル・組み込み市場を席巻

現代では、スマートフォン、タブレット、IoT機器からサーバー市場まで、  
**至るところでARMコアが息づいている。**

---

## ARMアセンブリの基本命令

ARMは「単純な命令セット」を哲学にしている。

例えば、加算を行うときは：

```assembly
ADD R0, R1, R2
```

意味：

- `R1`と`R2`を加算し、その結果を`R0`に格納する。

ポイントは：

- **3オペランド形式**（ソース2つ＋結果1つ）  
- **明確な動作記述**  
- **結果を別レジスタに格納できる（破壊しない）**

この「破壊しない計算」は、  
後続処理の柔軟性を飛躍的に高める。

---

## 命令の一貫性：シンプルであることの力

ARM命令セットは、設計レベルで**一貫性と予測可能性**が徹底されている。

- ほとんどの命令が**同じフォーマット**  
- 即値（Immediate）も一貫して扱える  
- 条件付き実行（後述）が命令単位で可能

これにより、CPUのパイプライン設計が容易になり、  
結果として**高効率・低消費電力**が実現できる。

単純さこそ、モダン設計における隠れた力なのだ。

---

## 条件付き実行：分岐を減らす設計美学

ARMは、分岐命令（例えば`BEQ`, `BNE`）を使わずとも、  
各命令に「条件コード」を付与できる。

例：

```assembly
ADDEQ R0, R1, R2
```

意味：  
「直前の演算結果がゼロだった場合のみ、R1とR2を加算し、R0に格納せよ」

これにより：

- 分岐によるパイプライン破棄を減少  
- よりスムーズな命令フローを実現

**「無駄なジャンプを避ける」という哲学**が、  
ARM設計思想の根底に流れている。

---

## スタックとレジスタ使用の違い

ARMでは、スタック操作も基本は明示的だ。

例えば、関数コール時には：

```assembly
PUSH {R4, R5, LR}    ; 必要なレジスタを保存
...
POP  {R4, R5, PC}    ; レジスタと復帰アドレスを復元
```

ここで`LR`（Link Register）は戻りアドレス、`PC`（Program Counter）は現在の命令アドレス。  
これにより、関数呼び出しの流れを最小限の命令数で完結できる。

**スタックも、レジスタも、究極的には「電力コスト」と「速度」を天秤にかけた設計**なのだ。

---

## Thumb命令セット：さらに小さく、さらに省電力

ARMは、さらに省メモリ・省電力を追求して、  
**Thumb命令セット**を導入した。

特徴：

- 命令長が16bitに圧縮  
- CPUの内部では通常の32bit命令にデコードされる  
- メモリ帯域とキャッシュ効率が向上

つまり、**コードサイズを半減させつつ、性能を大きく落とさない**という、  
非常にモダンな設計妥協を実現している。

---

## ARM64（AArch64）：時代に合わせた進化

スマートフォンからサーバー領域までを狙ったARMは、  
64bit化（AArch64）を果たした。

- レジスタが32本に拡張（X0〜X30＋SP）  
- メモリアドレッシングの柔軟化  
- より高度なSIMD（NEON）サポート  
- 仮想化支援（Hypervisorモード）

この拡張にも一貫しているのは、  
**「単純さを極力保ったまま、機能を拡張する」**という哲学だ。

---

## ARMアセンブリを書くとは、何を意味するか？

ARMアセンブリを書くとは、  
単に低レベルコーディングを行うのではない。

それは、

- 必要最小限の命令で  
- 無駄な分岐を避け  
- レジスタを最大限に生かし  
- 電力と帯域のコストを意識しながら

**「機械を最も美しく動かすための詩作」**を行うことに他ならない。

---

## 結語：モダン設計とは、単純さと強さの統合である

ARMアーキテクチャとそのアセンブリは、  
現代における**単純さの力**を体現している。

- 無駄を削ぎ落とす  
- 最小限の記述で最大の効果を上げる  
- 自由と秩序をバランスさせる

それは、**設計とは複雑化ではなく、単純化の技術である**という静かな証明である。

> _"モダン設計とは、最小の手数で、最大の宇宙を動かすことである。ARMアセンブリは、そのために設計された静かな芸術である。"_
x86アセンブリ入門：最初の一命令



> _"宇宙は最初の一点から始まった。プログラムもまた、最初の一命令から始まる。"_  

アセンブリの世界に足を踏み入れるとき、  
私たちは初めて、プログラムというものの真の姿を見る。  

そこには、高級言語の甘い抽象も、コンパイラの慈悲深い手助けもない。  
ただ**CPUに対して直接語りかける、小さな小さな命令**だけが存在する。

本稿では、x86アーキテクチャを題材に、  
**「最初の一命令」が持つ意味**を、アセンブリという視点から掘り下げる。

---

## x86とは何か？

x86とは、Intelが1978年に発表した8086プロセッサに端を発する、  
**世界で最も普及した命令セットアーキテクチャ**である。

特徴：

- CISC（Complex Instruction Set Computer）系：多機能な命令を持つ  
- 命令フォーマットが可変長  
- 強力な互換性（8086 → 80286 → 80386 → Pentium → x86-64）

現代のほとんどのPC、サーバ、仮想マシン基盤は、  
このx86系列上に構築されている。

---

## 最初に覚えるべき命令：MOV

アセンブリにおける最初の一歩、それは  
**MOV（ムーブ命令）**である。

```assembly
MOV EAX, 5
```

意味はシンプルだ。

- `5`という即値（Immediate Value）を  
- `EAX`という汎用レジスタにコピーする

**「値をどこかに置く」**――  
これがすべてのプログラム動作の原初的な形である。

---

## なぜMOVが最初なのか？

MOV命令は、単なるデータ転送ではない。  
それは、**存在を作り出す行為**だ。

- まだ何もないレジスタに  
- 明示的な意図を持ったデータを載せる

この瞬間に、**プログラムは無から存在を紡ぎ始める。**

すべての計算、すべての制御、すべての判断は、  
この**「最初の配置」**から始まる。

---

## MOV命令のバリエーション

MOVは非常に多彩な使い方ができる。

- レジスタ同士の転送
  ```assembly
  MOV EAX, EBX
  ```
- メモリからレジスタへの読み込み
  ```assembly
  MOV EAX, [ECX]
  ```
- レジスタからメモリへの書き込み
  ```assembly
  MOV [EDX], EAX
  ```

この柔軟性が、x86アーキテクチャの力強さを支えている。  
**データを「どこから」「どこへ」動かすかを自由に設計できる**のだ。

---

## 実行の流れを追う

1. プログラムカウンタ（EIP）がMOV命令を指す  
2. 命令デコーダがバイナリを解析  
3. レジスタファイルにアクセス  
4. データパスを通じて値が転送される

この一連の流れが、  
**たった1行のMOV命令によって駆動する。**

その背景には、**設計された複雑なマイクロアーキテクチャ**が静かに動いている。

---

## MOVの本質：意図を世界に刻む行為

MOVは単なるデータ移動ではない。  
それは、**設計者が「この値を、ここに存在させる」と宣言する行為**である。

このとき、設計者は二重の責任を負う：

- 値そのものに対する意味付け  
- それを置く場所の選択

プログラムとは、**無数のMOV命令の重ね合わせ**にすぎない。  
そしてその一つ一つが、**意図と構造の小さな彫刻**である。

---

## x86特有のMOVの味わい

x86のMOV命令は、他のアーキテクチャに比べて非常に表現力が豊かだ。

- 即値をメモリに直接書き込める
- レジスタ間、メモリ間、レジスタ→メモリ、メモリ→レジスタすべて自由自在
- サイズ（8bit/16bit/32bit/64bit）も柔軟に扱える

この自由さは、  
**「人間の意図をそのまま命令に反映させる」**という設計思想を映し出している。

---

## 最初の一命令を書くとき、何が始まるか？

`MOV EAX, 5` と書いた瞬間、  
そこには静かな奇跡が起きる。

- CPU内部に、確かに5という数が存在する  
- それは、物理的な電荷配置によって表現される  
- それは、次の演算・分岐・保存へと引き継がれる

たった一行で、**意図が物理現象に変換される**。  
それが、アセンブリの第一歩であり、**設計者が世界を動かす最初の接点**である。

---

## 結語：最初の一命令にすべてが宿る

アセンブリにおいて、  
**最初のMOV命令を書く**とは、  
ただプログラムを始めるのではない。

それは、  
**世界の無に、意味と秩序を刻み始める行為**である。

この一行に、すでにすべての哲学が宿る。

> _"最初の一命令は、単なる動作ではない。それは、設計者がこの世界に「意味」を生み出すための、最初の静かな宣言である。"_
スタックとヒープをアセンブリで見る



> _"記憶のありかたを制御することは、未来を設計することだ。"_  

プログラムは、記憶の上を泳ぐ。  
それは、データを置き、取り出し、再配置しながら動き続ける生命体だ。  
だがその記憶（メモリ）は、無秩序に使われるわけではない。

プログラムのメモリ利用には、大きく二つの領域が存在する。  
**スタック（Stack）**と、**ヒープ（Heap）**である。

この章では、スタックとヒープをアセンブリレベルで眺めながら、  
**記憶空間に対する設計の哲学**を探っていく。

---

## スタックとは何か？

スタックとは、**後入れ先出し（LIFO）**の原則に従うメモリ領域である。  
具体的には：

- 関数呼び出しごとにローカル変数を確保  
- 呼び出し終了時に自動で解放  
- 関数の戻り先アドレスも保存

特徴は明確だ：

- **サイズが小さいが高速**  
- **静的に管理される（順序が厳格）**  
- **生存期間がスコープに依存する**

つまりスタックとは、**設計者があらかじめ計画した「一時的存在たちのための劇場」**である。

---

## ヒープとは何か？

ヒープとは、**動的に確保・解放されるメモリ領域**である。  
その特徴は次の通り：

- **サイズが大きく、柔軟**  
- **確保と解放は設計者次第**  
- **生存期間はプログラムの意図に依存する**

ヒープは、**「秩序なき自由」の空間**であり、  
スタックとは異なり、設計者がその管理責任をすべて負う必要がある。

---

## スタック操作をアセンブリで見る

x86アセンブリにおける基本的なスタック操作はこうだ：

```assembly
PUSH EAX    ; スタックにEAXの値を押し込む
POP  EBX    ; スタックのトップから値を取り出し、EBXに格納
```

内部では次のようなことが起きている：

- `PUSH`は、スタックポインタ（`ESP`）を減少させ、そこにデータを書き込む  
- `POP`は、スタックポインタが指すデータを読み取り、`ESP`を増加させる

この単純な構造により、スタックは**関数の呼び出しと戻り、変数の生死管理**を完璧に制御している。

---

## 関数呼び出しにおけるスタックフレーム

アセンブリレベルで関数を呼び出すと、次のことが行われる：

1. 引数をスタックに積む（右から左へ）  
2. `CALL`命令で関数アドレスへジャンプし、戻りアドレスをスタックに保存  
3. 関数内でローカル変数分スタックを確保  
4. `RET`命令で戻りアドレスへ復帰

例（簡易版）：

```assembly
PUSH 2
PUSH 3
CALL add
ADD ESP, 8  ; 引数の分だけスタックを戻す
```

この一連の流れにより、  
スタックは**一瞬のうちに「世界線」を作り、それを破棄する**劇場となる。

---

## ヒープ操作をアセンブリ視点で見る

ヒープメモリの確保は、通常アセンブリだけで直接行うことは少ない。  
通常は、OSのシステムコールを通して行う。

例えばWindowsでは `HeapAlloc`、Linuxでは `mmap` や `brk` などを使用する。

しかし、その本質は：

- サイズを指定して  
- メモリ空間を確保し  
- ポインタを受け取る

という極めてプリミティブな操作に還元される。

この「動的確保」が、ヒープの自由さと危うさを生み出す。

---

## スタックとヒープ：速度と制御の対比

| 項目 | スタック | ヒープ |
|:----|:---------|:-------|
| 管理主体 | コンパイラ・CPU | プログラマ |
| 確保・解放 | 自動（関数呼び出し/終了） | 明示的に必要 |
| 速度 | 非常に高速（数サイクル） | 比較的遅い（数百サイクル） |
| サイズ制限 | 小さい（数MB〜） | 大きい（数GB以上） |
| 使用用途 | ローカル変数、一時データ | 大きな配列、動的オブジェクト |

この違いは、  
**「設計者はどこまで秩序を制御する覚悟があるか」**  
という問いに直結する。

---

## なぜスタックとヒープを分けるのか？

それは、**「確定しているもの」と「変動するもの」を設計レベルで峻別するため**だ。

- スタック：確定した生存期間を持つ  
- ヒープ：不確定な生存期間を持つ

プログラム設計とは、  
**変化と不変をどこで区切るかを決める行為**であり、  
スタックとヒープの設計は、その最初の境界線なのだ。

---

## 結語：記憶を制御する者が、設計を制する

スタックとヒープは、単なるメモリ空間の違いではない。  
それは、**秩序と混沌、確定と不確定、計画と即興**という、  
プログラム設計における根源的対立を象徴する存在である。

スタックを操るとは、設計の秩序を受け入れること。  
ヒープを操るとは、設計の混沌に責任を持つこと。

> _"記憶を制御するとは、設計に秩序を与えることだ。スタックとヒープは、その秩序の地図である。"_
AIの仕組みはAIに聞こう！

最近はAIの進化が凄まじいですよね...

自分は最近OpenAIのChatGPTに課金したんですが、もう手放せませんｗ

でも皆さん、AIは確かに便利ですが、AIの仕組みって理解していますか？

ちなみに、自分は全く知りませんでした！

なので、今回AIについての理解を深める良い方法を思いついたので、

実践していきたいと思います！

## LLMについて

まず、今回お話していくAIとは、「生成AI」のことを指します。

AIというと、機械学習やディープラーニングなども入ってくるので、

今回は生成AIに限った話にさせてください。

まず、生成AIと切っても切り離せない存在が、LLM（大規模言語モデル）です。

生成AIとは、以下のようなイメージで成り立っています。

生成AI
├─ 🧠 LLM（テキスト生成）
│ └─ ChatGPT、Claude、Gemini など
├─ 🎨 画像生成AI（例：DALL·E、Stable Diffusion）
├─ 🎵 音声生成AI（例：Voicebox、Voicery）
├─ 🎥 動画生成AI（例：Runway、Pika）

つまり、生成AIは色々なものを生成するAIのことで、

LLMは文章だけを生成するAIということです。

LLMの進化

では、LLMの進化について見ていきましょう！

まず初めに、ここでは大きく分けて７つの段階があります。

| 番号 | 技術名                              | 内容                                                                 |
|------|-------------------------------------|----------------------------------------------------------------------|
| 1    | Seq2Seq モデル                      | 翻訳や要約など「入力 → 出力」の基本構造の原点。RNNベースで登場し、自然言語処理に革命を起こした。 |
| 2    | Attention 機構                      | 入力文の中で「重要な単語」に注目できる仕組み。文脈理解や意味保持を向上させた。               |
| 3    | Transformer アーキテクチャ         | RNNを使わず並列処理を可能にし、LLMの高速学習と高精度化を実現した画期的構造。              |
| 4    | Byte Pair Encoding（BPE）などのトークナイゼーション | 単語をサブワード単位で処理することで、未知語に強くなり、語彙数も削減できた。               |
| 5    | Pretraining + Fine-tuning 戦略     | 汎用的な事前学習のあと、特定タスクに合わせて微調整。BERTやGPTで広く採用。                |
| 6    | Self-supervised Learning（自己教師あり学習） | 正解ラベルなしで学習可能。例：次の単語を予測させることで、大量データ学習が可能に。         |
| 7    | Scaled Training（超巨大モデルの学習）     | パラメータ数とデータ量を増やせば性能も向上するという「スケーリング法則」が発見された。       |
| 8    | RLHF（人間のフィードバックによる強化学習） | ChatGPTで採用。人間の好む返答へとチューニングし、対話性能を大幅向上させた。               |


## AIと勉強していく方法について

では、ここからが本題です。

正直、上の表の内容を一つ一つググれば理解を深めることができます。

しかし、実際にAIがどのように考えているのか、自分の興味のある質問で試してみたくはありませんか？

そのプロンプトとしては

**以下の形式に従ってください。各ユーザー入力に対し、Encoder処理とDecoder出力に分けて、｛自分が知りたい技術名｝の形式で応答してください。**

としたあとに、適当な質問をしてみてください。


質問の例：プロゲーマーは幼少期に、共通している事柄はありますか

すると、そのモデルがどのようなことができ、どんなことに注力しているのかを

対話形式で知ることができます。

例えば、Attention機構とはなんだ？気になるなぁ...と思ったとします。

お手持ちのChatGPTなどに上記のプロンプトで聞いてみてください。

（新しいチャットで聞くほうが適切な回答が帰ってきます。）

ちなみに、以下はAttention機構について上記のプロンプトを使用した際の出力内容です。

[Input: プロゲーマーは幼少期に、共通している事柄はありますか]

[Encoder処理]
→ トークン列: [プロゲーマー, は, 幼少期, に, 、, 共通, し, て, いる, 事柄, は, あり, ます, か]
→ 意図抽出：プロゲーマーの幼少期における環境・習慣・特性などの共通点を尋ねている
→ 文構造：主語＋時期指定＋抽象的属性の有無を問う形式の疑問文

[Attention重み可視化]
→ 「幼少期」: 0.26
→ 「共通」: 0.23
→ 「事柄」: 0.20
→ 「プロゲーマー」: 0.17
→ その他: 0.14以下

※ 特に「幼少期」「共通」「事柄」に注意が集中 → 時期的特徴と属性に焦点

[Decoder出力]
→ 多くのプロゲーマーには、幼少期からゲームに触れる環境があったという共通点があります。
→ さらに、「集中力の高さ」「勝ち負けへのこだわり」「親の理解」なども共通して見られる傾向があります。
→ 回答：はい、複数の共通した特徴が見られます。

[Decoder Ready] 

実際、Attention機構は各トークンごとに分けられた単語について、重み付けを行い、

より人間的な返答を自然言語で行えるようになりました。



## まとめ

AIの仕組みはAIに聞こう！

ということで、紹介したプロンプトを参考に、AIについての知識を深めていただければと思います！

もし何か問題がございましたら、ご指摘等いただけると幸いです。
メモリアドレスとポインタの哲学



> _"位置を知るとは、存在を知ることだ。そして存在を知るとは、設計を知ることだ。"_  

すべてのデータは、どこかにある。  
CPU、メモリ、ストレージ――コンピュータのあらゆる構成要素は、  
**「ここにある」「あそこにある」**という物理的位置情報に基づいて動いている。

そして、その位置を扱う概念こそが、  
**メモリアドレス（Memory Address）**であり、  
その位置を操作するための技法こそが、**ポインタ（Pointer）**である。

この章では、**メモリ空間を制御するという設計行為の本質**を、  
アセンブリの視点から哲学的に掘り下げる。

---

## メモリアドレスとは何か？

メモリアドレスとは、  
**「コンピュータ内部におけるデータの物理的または論理的な位置」**を示す数字である。

- アドレスは通常、**整数（数値）**で表現される  
- 1バイトごとにアドレスが付与される（バイトアドレッシング）  
- プログラムは、データの「中身」ではなく「位置」を操作する

つまり、プログラムとは本質的に、  
**「どの場所を、どの順番で、どう読むか」**を記述する構造である。

---

## なぜ「位置」を直接操作する必要があるのか？

高級言語では、位置を意識せずにプログラムを書くことができる。  
だが低レベルな世界では、それは許されない。

- レジスタに何をロードするかはアドレスで指定する  
- スタックフレームはアドレスオフセットで設計する  
- メモリマップドI/Oではアドレス空間がハードウェアそのものになる

**位置を知らずに設計することは、設計を放棄することに等しい。**

アセンブリを書くとは、すなわち、  
**空間そのものを設計対象とする**という覚悟を意味する。

---

## ポインタとは何か？

ポインタとは、  
**「データそのものではなく、データの場所を指し示す情報」**である。

例（C言語）：

```c
int a = 42;
int* p = &a;
```

ここで `p` は、`a` というデータそのものではない。  
**`a` が「どこにあるか」という情報**だけを持つ。

このシンプルな仕組みが、  
- 間接参照  
- 動的メモリ管理  
- データ構造（リスト、ツリー、グラフ）  
- ハードウェアアクセス

といった高度な設計を可能にしている。

---

## アセンブリにおけるアドレスとポインタ

アセンブリでは、すべてが「場所」を意識した命令になる。

例（x86）：

```assembly
MOV EAX, [EBX]  ; EBXが指すアドレスにあるデータをEAXにロード
```

ここで `[EBX]` という表記は、**「EBXという値をアドレスと解釈せよ」**という意味だ。  
つまり、**「データを指すデータ」**という、  
ポインタ的思考がこの時点で求められる。

---

## ポインタ操作とは「二重の意味操作」である

ポインタは、直接的なデータ操作ではない。  
それは、**「データを間接的に操作する」という構文的飛躍**を意味する。

- 通常の代入：データをデータに移す  
- ポインタ操作：場所を通じてデータを移す

この違いは哲学的だ。  
**我々はもはや「もの」ではなく、「ものの場所」にアクセスすることで世界を制御している。**

この間接性が、現代のコンピュータ構造を成立させている。

---

## メモリ空間設計とは「秩序なき空間に秩序を与える」行為である

コンピュータのメモリは、  
- 数十万  
- 数百万  
- 数十億  

ものアドレス空間を持つ。  
それは本来、無秩序な数列に過ぎない。

そこに秩序を与えるのが、設計者の役目だ：

- スタック領域  
- ヒープ領域  
- データセグメント  
- コードセグメント

これらの区分けは、すべて**空間に意味を与えるための設計行為**である。

---

## アドレス計算：設計者の静かな数学

アセンブリを書く際には、しばしばアドレス計算を行う。

例（スタック操作）：

```assembly
PUSH EAX    ; スタックポインタを減少させ、EAXの内容を書き込む
```

これは、単なる命令列ではない。  
それは、**「ここから-4バイト下の位置にデータを書き込む」という幾何学的操作**である。

- ポインタ＋オフセット  
- インデックススケーリング  
- ベース＋インデックス＋ディスプレースメント

これらすべては、**空間に対する構文的数学**である。

---

## ポインタの危うさ：破壊は一瞬で訪れる

ポインタ操作を誤れば：

- 無効なアドレス参照（セグメンテーションフォルト）  
- バッファオーバーフロー（攻撃対象になる）  
- ダングリングポインタ（解放済みメモリ参照）  

が発生する。

つまり、**位置に対する責任を設計者が負わなければ、プログラムは必ず破綻する。**

これは単なる技術的問題ではない。  
**設計に対する倫理的態度の問題**なのだ。

---

## 結語：メモリアドレスとポインタは、設計者の意図を空間に刻む構文である

アセンブリにおいて、  
メモリアドレスとポインタを制御するとは、  
**「存在そのもの」ではなく「存在する場所」を設計する行為**である。

それは、意味と空間の交差点であり、  
設計者が最も純粋に責任を負う領域である。

> _"ポインタとは、存在を超えて存在の場所を操る術である。アドレスとは、秩序なき空間に刻まれた意図の座標である。"_
レジスタとは：演算のための小さな宇宙



> _"最も小さな箱の中に、世界のすべてを保持せよ。"_  

CPUとは演算器である。  
だが演算とは、単なる計算ではない。  
それは、**一瞬一瞬、情報をどこに置き、どこから取り出し、どのように流すかを制御する芸術**である。

その中心に位置するのが、**レジスタ（Register）**だ。  
それは、**機械の中にある、最も速く、最も小さな宇宙**である。

この章では、レジスタという存在が、  
なぜCPUの設計において神経系を成し、  
なぜアセンブリプログラミングにおいて設計者の「息遣い」そのものとなるのかを見ていく。

---

## レジスタとは何か？

レジスタとは、  
**CPU内部に存在する超高速な記憶領域**であり、  
**演算処理に必要なデータやアドレスを一時的に保持する装置**である。

特徴は以下の通り：

- メモリより圧倒的に高速（数サイクル以内にアクセス可能）  
- サイズは非常に小さい（数ビット〜数十ビット）  
- 直接命令からアクセスされる（MOV, ADDなど）  
- 命令実行のために必須

つまりレジスタは、  
**「CPUが思考し、行動するための作業台」**そのものだ。

---

## なぜレジスタが必要なのか？

もしCPUが、すべてのデータをメインメモリから直接読み書きしていたら：

- 命令1つごとに数百サイクルかかる  
- プログラムは事実上停止する  
- キャッシュも意味を持たない

レジスタはこのボトルネックを解消する。  
それは、**「今この瞬間だけ必要なものを最短経路で保持する」**ための、  
**極限まで小型化・高速化された記憶装置**である。

---

## レジスタの分類：静かに棲み分ける小宇宙たち

一般的なCPUには、次の種類のレジスタが存在する。

### 汎用レジスタ（General Purpose Register）

- 任意のデータを保持  
- 演算・アドレス計算・一時保存に使用
- 例：`EAX`, `EBX`, `RCX`, `RDX`（x86）

### 特殊レジスタ（Special Purpose Register）

- プログラムカウンタ（PC / IP）：現在実行中の命令アドレス  
- スタックポインタ（SP / ESP）：スタックトップ位置  
- フラグレジスタ（FLAGS / EFLAGS）：演算結果フラグ（ゼロ、キャリー、オーバーフロー）

### セグメントレジスタ

- （主にx86系）メモリセグメントを選択するためのレジスタ（例：`CS`, `DS`）

### 制御レジスタ（Control Register）

- 仮想メモリ、ページング、特権モード制御などシステム動作を司るレジスタ

---

## レジスタ設計はCPUアーキテクチャの「詩」である

- x86は8本の32bit汎用レジスタから出発し  
- x86-64で64bit化＋新レジスタ（R8〜R15）を導入  
- ARMは32本（R0〜R31）のシンプルな構成  
- RISC-Vはゼロレジスタ（常に0を返す）を設け、演算効率を向上

この設計の違いは単なる数字ではない。  
**「何を重視し、何を切り捨てたか」**という、  
**設計者たちの静かな声**なのだ。

---

## アセンブリプログラミングにおけるレジスタ操作とは

アセンブリでは、レジスタ操作がすべての基本になる。

例（x86）：

```assembly
MOV EAX, 5    ; EAXに5を格納
MOV EBX, 10   ; EBXに10を格納
ADD EAX, EBX  ; EAXにEBXを加算
```

この3行だけで、  
**データ保存 → データ間演算 → 結果格納**  
という**プログラムの基本単位**が実現されている。

---

## レジスタ制御は「小さなリソースで無限を組み立てる」技術

レジスタは少ない。  
どのCPUも数本〜数十本しか持たない。

この制約のなかで：

- 計算をやりくりし  
- データを一時保存し  
- 必要に応じてメモリと入れ替えしながら  
- 最終的な結果を導き出す

これはまさに、  
**「小さな宇宙に巨大な計算世界を折りたたむ」**  
設計行為である。

---

## レジスタアロケーション：静かな戦略の戦い

コンパイラ設計や最適化の世界では、  
「どのデータをどのレジスタに割り当てるか」  
という問題が深刻に存在する。

- 使われないレジスタを無駄にしない  
- スピル（レジスタ不足時にメモリ退避）を最小限にする  
- パイプラインハザード（データ依存）を防ぐ

この最適化戦略は、まさに**無言の知性の戦場**であり、  
**レジスタとは単なる場所ではなく、設計者の思考の跡**なのだ。

---

## 結語：レジスタとは、機械と設計者が唯一共有する小さな宇宙である

レジスタは単なる記憶装置ではない。  
それは、設計者が機械に与えた**最小限の思考領域**であり、  
機械が設計者に残した**最大限の自由空間**である。

そこに載せられるものはわずかだ。  
だが、そこに込めることができるものは、**世界すらも凌駕する。**

> _"レジスタとは、すべてを計算するために与えられた、最も小さな宇宙である。設計者は、その宇宙に全存在を折りたたむ。"_
CPUアーキテクチャと命令セットの基礎



> _"設計とは、無数の選択を制約することで、秩序を生み出す行為だ。CPUもまた、設計された秩序である。"_  

すべてのプログラムは、最終的にはCPU上で動く。  
そして、CPUは**単なる鉄とシリコンの塊ではない**。  
それは、人間の設計哲学と物理世界への挑戦が結晶化した、**動く思想**である。

この章では、CPUアーキテクチャと命令セット（Instruction Set Architecture, ISA）という、  
**最もハードでありながら最も思想的な層**について掘り下げる。

---

## CPUアーキテクチャとは何か？

CPUアーキテクチャとは、  
**「コンピュータの中核部がどのように命令を解釈し、実行するかを定めた設計仕様」**である。

要素は多岐にわたるが、中心的な構成は次の通り：

- **レジスタ設計**：データを一時的に保持する高速記憶領域  
- **命令セット**：CPUが理解できる基本動作の集合  
- **メモリモデル**：どのようにアドレス空間を扱うか  
- **パイプライン設計**：命令実行をいかに並列化するか  
- **割り込み処理**：外部からのイベントをどう受け止めるか

つまり、CPUアーキテクチャとは、**「このハードウェアはこう動く」という設計書そのもの**である。

---

## 命令セットとは何か？

命令セット（Instruction Set）は、  
**「CPUが直接理解し、実行可能な最小単位の命令体系」**である。

例えばx86命令セットでは：

- `MOV`：データ転送  
- `ADD`：加算  
- `SUB`：減算  
- `JMP`：無条件ジャンプ  
- `CMP`：比較

などが用意されている。  
それぞれは、ビット列にマッピングされ、最終的に電気信号となってCPU内で解釈される。

**命令セット＝CPUにとっての母語**である。

---

## 命令セットが異なれば、世界の見え方も異なる

同じ「加算」を行うにしても、命令セットによって指示の仕方は異なる。

- x86（CISCアーキテクチャ）  
  ```assembly
  ADD EAX, EBX
  ```
- ARM（RISCアーキテクチャ）  
  ```assembly
  ADD R0, R1, R2
  ```

x86は「加算元と加算先を指定する」のに対し、  
ARMは「2つのオペランドを加算し、結果を第3のレジスタに保存する」設計。

この違いは、**アーキテクチャが「世界をどう分解し、再構成しようとしているか」**の違いに直結している。

---

## CISCとRISC：二つの設計思想

### CISC（Complex Instruction Set Computer）
- 複雑な命令を少ない行数で表現できる  
- ハードウェアが多くの機能を肩代わりする  
- 命令セットが大規模・多様化しやすい（例：x86）

### RISC（Reduced Instruction Set Computer）
- 命令をできるだけ単純・均一にする  
- すべての命令がほぼ同じ実行時間を持つ  
- コンパイラによる最適化が前提（例：ARM, RISC-V）

この分岐は、単なる性能比較ではない。  
それは、「**機械にどこまで仕事をさせ、どこからは設計者が責任を持つか**」という設計倫理の違いである。

---

## レジスタ設計：動的世界のための静的拠点

CPU内部のレジスタは、  
**プログラムの実行中に使われる最も高速な記憶装置**である。

種類も豊富だ：

- 汎用レジスタ（General Purpose）  
- 特殊レジスタ（Stack Pointer, Program Counterなど）  
- フラグレジスタ（条件分岐用ビット）  

アセンブリ言語でレジスタを操作することは、  
**CPUの内部状態を直に触る**ということであり、  
それは設計者にとって**「世界の心臓に直接触れる」**体験に他ならない。

---

## メモリモデル：線形か、セグメントか

CPUがメモリにアクセスする方法もアーキテクチャに依存する。

- **セグメント方式（例：8086）**  
  → メモリ空間を「セグメント」と呼ばれる単位に区切る  
- **フラット方式（例：x86-64, ARM）**  
  → メモリは単一の線形空間として扱う

この設計は、  
「**物理空間の有限性をどう知覚させるか**」  
「**アドレッシングのコストと安全性をどう分配するか**」  
という、極めて哲学的な選択である。

---

## CPU設計における「選択」とは何か？

CPUアーキテクチャの設計は、無数の選択の積み重ねだ。

- 命令の種類  
- レジスタの数  
- メモリアクセスモデル  
- 割り込み機構の有無  
- マルチコア対応設計

これらすべてが、**「どこまでをハードに固定し、どこからを設計者に委ねるか」**という問いへの回答である。

CPUは、単なる演算装置ではない。  
**選択と制約の結晶**であり、**設計者への問いかけ**なのだ。

---

## 結語：CPUアーキテクチャとは、設計された物理法則である

私たちがアセンブリを書くとき、  
それは単なる命令列ではない。  
それは、**ある設計思想に沿った世界の中で、動きを記述する行為**である。

- どのレジスタを使うか  
- どの命令を選ぶか  
- どのメモリにアクセスするか

すべては、そのCPUが持つ**設計された物理法則**の中で決まる。  

> _"アーキテクチャとは、ただの仕様ではない。それは、動作する宇宙の律法であり、設計者に課せられた静かな宿命である。"_
アセンブラの役割：翻訳者か、詩人か



> _"言葉を渡す者には二つの道がある。忠実に伝えるか、解釈して昇華するか。"_  

プログラムは、機械が動くために存在する。  
だが、機械は人間の言葉を理解できない。そこには必ず、**橋渡しをする存在**が必要だ。  

アセンブラ（Assembler）。  
それは単なるツールではない。  
**人間が書いた意図を、機械が動かせる形式へと変換する、最もミニマルな翻訳者であり、時に詩人である。**

この章では、アセンブラとは何か、その役割の深層に迫る。

---

## アセンブラとは何か？：記号と命令の間の通訳

アセンブラとは、**アセンブリ言語で書かれたソースコードを、機械語（バイナリ）に翻訳するプログラム**である。

基本的な流れはこうだ：

1. ソースコード（アセンブリ）を読み取る  
2. 各命令を対応する機械語ビット列に変換する  
3. ラベルやジャンプ先を解決する  
4. 実行可能なバイナリを出力する

例えば：

```assembly
MOV AX, BX
```

を読んだアセンブラは、内部で「この命令は`100010`というパターンだな」と認識し、  
対応するバイナリを出力する。

つまり、アセンブラは**意味を破壊せず、ただ形式を変える存在**である。

---

## アセンブラは「翻訳者」である

人間が書いた `MOV AX, BX` には、「BXの値をAXにコピーせよ」という意図が込められている。  
アセンブラはこれを：

- 忠実に  
- 冷徹に  
- 無感情に

機械語へと変換する。  
この態度は、**優れた翻訳者が原文を損なわないこと**に似ている。

---

## だが時にアセンブラは「詩人」である

一方で、現実のアセンブラは単なる変換以上のことを行う場合がある：

- マクロ展開（短縮記法を展開する）  
- 条件アセンブル（コードを環境に応じて切り替える）  
- 最適化（命令順序の最小化）

これらは、「原文に忠実に」という原則を超え、  
**設計者の意図を解釈し、最適な形で機械語に編み直す**行為である。

つまり、アセンブラは**翻訳者と詩人のあいだ**を行き来する存在なのだ。

---

## 第一世代アセンブラと現代アセンブラの違い

かつてのアセンブラ（例：NASM, MASM）は、ほぼ忠実な翻訳に徹していた。  
- 1行1命令  
- 機械語への単純マッピング  

しかし現代のアセンブラ（例：LLVM assembler, GNU as）は、より豊かな機能を持つ：

- 高度なマクロシステム  
- 条件コンパイル機能  
- リンカとの高度な連携  
- デバッグシンボル生成  

つまり、**ただの翻訳ではなく、意味の保持と拡張を同時に目指す存在**へと進化している。

---

## アセンブラに求められる「二つの誠実さ」

アセンブラには、矛盾する二つの要求が突きつけられる。

1. **機械に忠実であれ**  
2. **設計者の意図に忠実であれ**

前者は正確さ、後者は解釈力を要求する。  
これらを両立するために、アセンブラは：

- 最小限の情報損失で変換を行い  
- 必要に応じて人間の設計意図を補助し  
- しかし機械語の仕様には絶対服従する

という、**極めて哲学的なバランス感覚**を求められる。

---

## アセンブラを書くとは、「意図と形式の乖離」を埋めること

アセンブラを書くという行為は、単なるパーサー作成ではない。  
それは、「**人間の意図と機械の仕様という、異なる論理体系をすり合わせる試み**」である。

- 人間は意味を重視する  
- 機械は形式を重視する

このギャップを、どこまで正確に、かつ美しく橋渡しできるか。  
それがアセンブラ設計の核であり、設計者としての誇りである。

---

## アセンブラとコンパイラの違いとは？

一見似ているが、アセンブラとコンパイラは本質的に異なる。

| 項目 | アセンブラ | コンパイラ |
|:----|:------------|:-----------|
| 入力 | アセンブリ言語 | 高級言語（C, Rustなど） |
| 出力 | 機械語 | 機械語 or アセンブリ |
| 変換 | ほぼ1対1対応 | 構文解析・意味解析・最適化を含む |
| 役割 | 形式の翻訳 | 意図の解釈と最適化 |

つまり、**アセンブラは形式の忠実な通訳者**であり、  
**コンパイラは意味の解釈者であり設計者の代弁者**なのだ。

---

## 結語：アセンブラとは、意味を壊さないための詩的装置である

アセンブラは、ただ機械語を吐くだけの存在ではない。  
それは、「**設計者の意図を、形式という過酷な世界に耐えうる形で送り届ける**」ための、静かな翻訳者であり、時に詩人である。

- 正確であること  
- 意図に寄り添うこと  
- 機械に従うこと  
- だが人間のために設計すること

この矛盾を、無言のまま解き続ける。  
それがアセンブラという存在の本質である。

> _"アセンブラは翻訳者であり、同時に詩人である。形式に沈み込むことなく、意味を紡ぐ静かな技術者である。"_
【ServiceNow】クライアントスクリプトをJavaScript Executorで確認する方法

# 🧠 JavaScript Executorとは？

ServiceNowの**Client Scripts/UI Policies etc**を利用できる、**一時的なコード実行環境**のことです。
クライアント側のコードをすばやく作成およびデバッグするのに役立ちます。

- バックグラウンドスクリプトは実行できないため注意:warning:
- 基本的には**adminロール**を持つユーザーのみが使用可能

## 🛠 使用方法

### ステップ1：「Alt + Ctrl + Shift + j」を押下する
Javascript Executorを開きます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941772/7992a996-8106-4d42-a429-22e0842fb63a.png)



### ステップ2：コードを記述して実行  
以下のように、スクリプトを入力して「Run my code」をクリックします。
今回の場合、User IDが取得できていることが確認できる。

```javascript
alert(g_form.getValue("user_name"));
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941772/962f621a-10a5-4975-8dcf-3f71f8b83dcd.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941772/c8696096-6ad5-4d0f-bda0-178b09aee657.png)


## 参考
https://www.servicenow.com/community/developer-blog/using-the-javascript-executor-to-test-client-scripts/ba-p/2271158#:~:text=Example%20of%20opening%20the%20Javascript%20executor%20on%20your,text%3A%20...%204%204.%20Click%20%22Run%20my%20code%22
【AWS】初学者：Amazon EC2（Elastic Compute Cloud）について

# Amazon EC2（Elastic Compute Cloud）について
本日はmazon EC2について学習しました。
ハンズオン学習は行っていないので操作については理解できてませんが概要に
ついて学習したことをアウトプットします。

## 🌐 Amazon EC2とは？
Amazon EC2（Elastic Compute Cloud）は、オンプレミス環境の物理サーバーと同等の性能を持つ仮想サーバーを、AWSクラウド上で簡単に作成・管理できるサービスです。

## ✅ 特徴まとめ
・スケーラビリティ：インスタンス数を必要に応じてスケールアップ／ダウン可能

・柔軟な構成：CPU、メモリ、ストレージなどを用途に応じて選択

・コスト最適化：従量課金で、オンプレミスのような初期投資不要

・多様なOS：Linux、Windows、macOSなどに対応

・セキュリティ管理：IAM、セキュリティグループで厳格にアクセス制御可能

・即時起動：数分でインスタンス起動可能

・AMI対応：マシン設定をイメージ化し再利用可能

## 💰 購入方式と料金体系
| 方式            | 特徴                                |
| ------------- | --------------------------------- |
| オンデマンド        | 従量課金、長期契約不要、柔軟な運用（料金は高め）          |
| リザーブド         | 1年/3年契約で割引適用、長期利用向け、分割払いや一括払いに対応  |
| スポット          | AWSの余剰リソースを格安で利用、割引率最大90%、停止リスクあり |
| Savings Plans | EC2以外にも対応、使用量に応じた柔軟な割引プラン         |

## 🧱 インスタンスタイプの分類
| タイプ   | 特徴                | 用途例          |
| ----- | ----------------- | ------------ |
| Tシリーズ | バースト性能ありの汎用型、低コスト | 軽量なWebアプリなど  |
| Mシリーズ | バランス型             | 一般的な業務アプリなど  |
| Cシリーズ | 高性能CPU向け          | 計算処理、バッチ処理など |
| Rシリーズ | メモリ最適化            | DBサーバーなど     |
| Gシリーズ | GPU搭載             | 機械学習、画像処理など  |

## 🌍 コストに影響する3要素
### 1️⃣ リージョン（地域）
・東京リージョンは割高、米国東部（バージニア北部）は安価

・リージョンによって利用できるサービスにも差がある

### 2️⃣ データ転送
・リージョン外へのデータ送信は有料

・同一リージョン内の通信（例: VPC内）は無料

・CloudFrontでコスト最適化可能

### 3️⃣ ストレージ（EBS）
・SSD (gp3, io2) / HDD (st1, sc1) など選択肢あり

・容量、スナップショット数によって料金増加

・gp3の方がgp2より安価で柔軟

## 🚀 EC2インスタンス作成の流れ
1.AWSマネジメントコンソールにログイン

2.EC2サービスへ移動

3.「インスタンスの起動」を選択

4.AMI（OSイメージ）を選択（例: Ubuntu）

5.インスタンスタイプを選択（初心者は t2.micro 推奨）

6.ネットワークやIAMロールを構成

7.ストレージ容量を指定（例: 8GB）

8.タグ追加（任意）

9.セキュリティグループ設定（SSH, HTTPなど）

10.キーペア作成＆ダウンロード → 起動！

## 🧠 vCPU（仮想CPU）とは？
・物理コアを仮想的に分割したリソース

・多くのインスタンスタイプは1コア=2vCPUとして提供

・ワークロードに応じて選定が必要

### vCPU数の例
| タイプ         | vCPU数 |
| ----------- | ----- |
| t3.micro    | 2     |
| m5.large    | 2     |
| c6i.xlarge  | 4     |
| r5.2xlarge  | 8     |
| c6a.4xlarge | 16    |

## 🎯 vCPU活用のポイント
・軽量な処理 → t3やm5

・計算処理やAI用途 → c6系やGシリーズ

・不要なリソース制限：vCPU数を抑えてコスト調整

・バースト性能（CPUクレジット）：t系インスタンスは一時的な高負荷に強い

## 📌 最適化Tips
・Auto Scalingでリソースを自動スケーリング

・DockerなどでvCPUを分割運用し、効率化

・使わないEBSやスナップショットは定期削除

## 📝 まとめ
EC2はAWSの基盤となるサービスであり、構成の柔軟性やコスト最適化手段が豊富です。
用途や予算に応じてインスタンスタイプや料金プランを選ぶことが、効率的なクラウド運用の第一歩だと感じました。
ROA(Route Origin Authorization)メモ

オンプレミスで所有しているIPアドレス（≒自社保有のIPv4/IPv6ブロック）をAWSに持ち込む（BYOIP: Bring Your Own IP）場合、**Route Origin Authorization（ROA）の登録は必須**です。これは、**AWSがそのIPアドレスをインターネットに広報（BGPアナウンス）するために、正当性を証明するため**です。



## 🛠 ROA登録～AWS BYOIP の流れ

### 1. IPアドレスを自社で保有していることを確認

* RIR（地域インターネットレジストリ）からの正式割り当てが必要
* 例：APNIC/JPNIC から `203.0.113.0/24` を割当済み

### 2. ROA を作成

* RPKIマネージャー（APNIC、ARINなどのRIRポータル）で
* 「このIPプレフィックスは **AS16509** がアナウンス可能」と指定
* 例：`203.0.113.0/24` → `AS16509`

### 3. ROAの公開・有効化

* RPKIで署名・公開（通常は即時か数時間以内に反映）

### 4. AWSコンソールでBYOIP申請

* VPC > IPアドレス > Bring Your Own IP
* 対象CIDRブロック、ROA登録済みであることを確認

### 5. AWSによるバリデーション

* ROAの有無、WHOIS情報、IP割当証明書などを元に確認
* 通常1～2営業日で完了（追加書類を求められる場合も）

### 6. アドバタイズと使用開始

* Global Accelerator、ELB、EC2 ENI、NAT Gatewayなどで使用可能

---

## 🔐 ポイント

* ROAに指定するAS番号を間違えると AWS によるバリデーションが**失敗**します
* AWSが広報するAS番号（通常は AS16509）を必ず指定
* ROAが **Invalid** や **Not Found** 状態だと、AWS側でアドバタイズ不可

---
【Rails】🔰初学者：Railsでよく出るエラーとその対処法まとめ

# 【Rails】🔰初学者：Railsでよく出るエラーとその対処法まとめ

Railsを触っていると必ず出会う「エラー」。
最初は怖いですが、ちゃんと読む習慣をつけるようにし、少しだけ自力で解決できるようになってきました。
ホントに「少しだけ」ではありますが・・・:sweat_smile:

今回は、僕自身がRailsを学んでいる中でよく出会ったエラーとその意味、そして対処法を整理してみました。

## ✅ 主なエラーとその意味


| エラー名                                       | 内容                                    | 例                                              |
| ------------------------------------------ | ------------------------------------- | ---------------------------------------------- |
| **SyntaxError**                            | Rubyの文法ミス                             | `unexpected keyword_end`（endの数ミス）              |
| **NameError**                              | 定義してない変数やメソッドを使った                     | `undefined local variable or method 'post'`    |
| **NoMethodError**                          | 存在しないメソッドを呼び出した                       | `undefined method 'title' for nil:NilClass`    |
| **RoutingError**                           | 存在しないルートにアクセスした                       | `No route matches [GET] "/posts/123"`          |
| **ActiveRecord::RecordNotFound**           | 指定IDのレコードが見つからない                      | `Couldn't find Post with 'id'=999`             |
| **ActionController::ParameterMissing**     | パラメータが送られてない                          | `param is missing or the value is empty: post` |
| **ActiveModel::ForbiddenAttributesError**  | Strong Parametersで許可されていない属性を保存しようとした | `Unpermitted parameter: :title`                |
| **Missing Template**                       | 該当するviewファイルがない                       | `Missing template posts/show`                  |

## ✅ エラーが出たらまずやること！
### 1. エラーメッセージ全文をちゃんと読む
エラーの種類（例：NoMethodError）

どこのファイルで、何行目で出たか

for nil:NilClass のような詳細

### 2. スタックトレース（バックトレース）を見る
上：呼び出し元

下：実際のエラー箇所
```ruby
app/controllers/posts_controller.rb:10:in `show'
```
## 🔍 よくあるエラーと対処法（具体例）
### 🔸SyntaxError
```ruby
SyntaxError: unexpected keyword_end, expecting end-of-input
```
✅ 対策：
end の数や順序をチェック

エディタの構文チェック機能に頼る

### 🔸NameError
```ruby
NameError: undefined local variable or method `post`
```
✅ 対策：
変数やメソッドが定義済みか

スペルミス or @ のつけ忘れに注意

### 🔸NoMethodError
```ruby
NoMethodError: undefined method `title' for nil:NilClass
```
✅ 対策：
nil に対してメソッドを呼び出していないか

.findで失敗したらnilになるか例外になるので rescue が有効

### 🔸RoutingError
```ruby
No route matches [GET] "/posts/123/edit"
```
✅ 対策：
rails routes で定義確認

HTTPメソッドやパスを見直す

### 🔸ActiveRecord::RecordNotFound
```ruby
ActiveRecord::RecordNotFound: Couldn't find Post with 'id'=999
```
✅ 対策：
.find(params[:id]) が見つからないと例外

rescue でフォールバック処理

### 🔸ActionController::ParameterMissing
```ruby
param is missing or the value is empty: post
```
✅ 対策：
フォームのname属性や構造をチェック

params.inspectで中身を確認

### 🔸ForbiddenAttributesError
✅ 対策：
Strong Parameters を正しく書く！
```ruby
def post_params
  params.require(:post).permit(:title, :body)
end
```
### 🔸Missing Template
```ruby
Missing template posts/show
```
✅ 対策：
該当する .html.erb があるか

render の記述ミスに注意

## 📝 まとめ
エラーは嫌な存在に思えますが、
実は「コードを正しく書くための先生」みたいなもの。
特にエラーが解消されてきれいに実行できた時は脳汁がでます。

まずは落ち着いてエラーを読むことから始めてるように心がけていきます。
NLB異常検知

AWSの**Network Load Balancer (NLB)** において、バックエンドの異常を検知し、自動的にアクションを実行する仕組みは、以下のような構成で実現可能です。

---

## 🔍 バックエンド異常の検知

### NLB のヘルスチェック

NLBはターゲット（EC2やIPアドレス）に対して**TCP/TLS/HTTPヘルスチェック**を行い、異常なターゲットを自動でルーティング対象から外します。

ただし、**NLB自体にCloudWatchアラームや自動通知機能はありません。**

---

## ⚙ 自動アクションの実装（構成例）

異常検知 → 通知・自動処理までを自動化するには、以下のAWSサービスの連携が必要です。

### 構成イメージ：

1. **CloudWatch Logs / Metrics**

   * ヘルスチェックの失敗数（`UnHealthyHostCount`）を監視

2. **CloudWatch Alarm**

   * 上記メトリクスにしきい値を設定（例：UnHealthyHostCount >= 1）

3. **SNS or EventBridge**

   * CloudWatchアラームの状態遷移で通知を送る or イベントをトリガー

4. **Lambda（自動アクション）**

   * 例：対象インスタンスの再起動、Auto Scalingグループのインスタンス置き換え、Slack通知など

---

## 🛠 自動アクションのユースケース例

| ケース             | トリガー                          | アクション                 |
| --------------- | ----------------------------- | --------------------- |
| EC2が不健康         | `UnHealthyHostCount` 増加       | LambdaでEC2再起動         |
| IPベースのターゲットが不健康 | `UnHealthyHostCount` 増加       | Lambdaでバックエンドシステム通知   |
| 特定AZで全ターゲット異常   | AZ別 UnHealthyHostCount モニタリング | Route 53 のトラフィックルール変更 |

---

## 🧩 補足：ターゲットがIPの場合

IPベースのターゲットはEC2ではないため、EC2ステータスのCloudWatchメトリクスは使えません。ヘルスチェックと連携した異常検知は**NLBのヘルスチェックメトリクス**を利用する必要があります。

---

## まとめ

| 必要な要素                    | 説明                        |
| ------------------------ | ------------------------- |
| CloudWatch               | NLBのUnHealthyHostCountを監視 |
| CloudWatch Alarm         | 異常検知のトリガー                 |
| Lambda or SSM Automation | 自動アクションを実行                |
| SNS / EventBridge        | 通知やフロー制御に活用               |

---
「break 文と continue 文を英文で説明してください」（ChatGPT への試問）

こんにちは。
英文を読み、腹落ちして自分が理解できるようになることは重要だと思い、試しに下記の質問に対して ChatGPT へ英作文をお願いしました。

この回答を読んで考えますと、英文だからこそ明瞭な説明だと思いました。もしもこれの和訳から理解しようとしても、語義に基づいていることが理解から欠落するだろうと思われます（したがって本当の理解と言えるのか怪しいかもしれません）。

#### ChatGPT への質問
break 文と continue 文の機能を英文で説明してください。その際に各々の機能が語義に基づいていることが明瞭となるよう留意してください。

#### ChatGPT の回答

了解しました！

> In loop control, the break and continue statements serve distinct purposes. The break statement immediately terminates the entire loop, causing the control flow to break out of the loop and proceed with the statement that follows it. In contrast, the continue statement skips the rest of the current iteration and causes the loop to continue with the next iteration, as long as the loop condition still holds. While break ends the loop entirely, continue allows it to proceed by bypassing only part of its current execution.
【Laravel11】SELECT EXISTSの発行にえらい苦労したしなんなら解決していない

このSQLを発行したい。

```sql
SELECT hoge.id, EXISTS(SELECT id FROM fuga WHERE fuga.hoge_id = hoge.id AND fuga.status = 1) AS fuga_exists FROM hoge;
```

このSQLの書き方、どこを探しても何故か全く出てきません。

# [クエリビルダ](https://readouble.com/laravel/11.x/ja/queries.html)

`exists`・`doesntExist`メソッドはSQLを組み立てるのではなく実行してboolを返してきやがるので今回の用途には役立ちません。
これを書いた時点でSQL全体が`SELECT EXISTS`で囲われてしまいます。

`whereExists`メソッドは名前のとおり`WHERE EXISTS`文を発行するので`SELECT EXISTS`ではありません。


# [リレーション](https://readouble.com/laravel/11.x/ja/eloquent-relationships.html)

こちらの下のほうにひっそりと`withExists`なるメソッドが書かれていました。

しかし例が`->withExists('comments')`としか書かれておらず、追加のWHERE句を渡したいときにどうすればいいかとかがさっぱりわかりません。
これは[英語版ドキュメント](https://laravel.com/docs/11.x/eloquent-relationships)の時点からそうです。


# 答え

```php
$hoge->withExists(['fuga AS fuga_exists' => function ($query) {
    return $query->where('status', '=', 1);
}]);
```

こんな使い方ドキュメントのどこにも乗ってねえんだけど。

最終的に[プルリク](https://github.com/laravel/framework/pull/37302)にようやくそれっぽい記述を見つけて、ようやくどうにかすることができました。


# おまけ

というか本題。
このSQLを発行したい。

```sql
SELECT hoge.id, NOT EXISTS(SELECT id FROM fuga WHERE fuga.hoge_id = hoge.id AND fuga.status = 1) AS fuga_not_exists FROM hoge;
```

こちらの作り方はいまだにわかりません。

JOINにすればいいじゃんとかそういう問題ではないんだよ、このSQLを作りたいんだよ。


# ソースコードリーディング

せっかくなのでソースコードを読んでみよう。

## [QueriesRelationships::withExists()](https://github.com/laravel/framework/blob/v11.44.0/src/Illuminate/Database/Eloquent/Concerns/QueriesRelationships.php#L946)

`withAggregate($relation, '*', 'exists')`を呼んでるだけですね。

## [QueriesRelationships::withAggregate()](https://github.com/laravel/framework/blob/v11.44.0/src/Illuminate/Database/Eloquent/Concerns/QueriesRelationships.php#L776)


やべえ…まったく意味がわからない。

parseWithRelationsで引数を分割して、第二引数が`as`ならなんかやってるっぽい。

つまり`withExists('XXX AS fuga_exists')`とか送ればエイリアスを書けそうだ。


下のほう見たら`if ($function === 'exists')`とか書かれていた。

中を見るとSQLを直接発行していた。
`sprintf('exists(%s) as %s', $query->toSql(), $this->getQuery()->grammar->wrap($alias))`

つまり、NOTを入れる余地がない。



# 感想

ソースコードリーディングむり。
C言語のNULLの正体は0なのか？

## 初めに
C言語で頻繁に使われるNULL。
「何もない」を意味しますが、実際には何らかの値であるはずです。
よく「NULLの正体は0」だと言われますが、本当にそうなのでしょうか？
実際にコードを書いて確認してみました。
## 実験用プログラム
```demo.c
#include <stdio.h>
#include <stddef.h>

int main() {

    if (NULL == 0) {
        printf("NULL is equal to 0\n");
    } else {
        printf("NULL is not equal to 0\n");
    }

    printf("NULL (as integer): %d\n", NULL);
    printf("0 (as integer): %d\n", 0);

    return 0;
}
```

## 実行結果
NULL == 0 が真であり、整数として表示しても 0。
つまり、この環境では`NULL`は`0`と同じだと確認できました。
```
C:\Users\nanasi\test3>gcc demo.c

C:\Users\nanasi\test3>a
NULL is equal to 0
NULL (as integer): 0
0 (as integer): 0
```

## 定義位置
定義されている場所を調べましたがNULLに関するものは以下の1行だけで見つけられませんでした。
```C:\mingw64\include\c++\14.2.0\cstdlib
#define NULL __null
```

## 環境
Windows10 (10.0.19045.5737)
gcc version 14.2.0
Unity WebGLのローカルサーバーを起動する方法（Windows版）（Unity6対応）

UnityのWebGLの開発で、ビルドを実行しようとすると、以下のことが不便でした。
- 「Build And Run」からだと、毎回ビルドするし、ポート番号も変わってしまう
- ``python -m http.server 8000``や``npx http-server``だと、Gzipに対応していないので、ビルド設定をいじらないといけない。インストールする必要もある

「何とかならないものか」と手段を調べてみると、Unityエディタのフォルダの中にある「SimpleWebServer.exe」を直接起動する方法が見つかりました。  
以下、そのコマンドです。  
（``buildFolder``が、開きたいビルドしたWebGLアプリのフォルダとしています）  
（バージョンは適宜置き換えてください）  
（デフォルトでインストールした場合のフォルダです）

- Unity 6000.0.48f1 の場合

```
"C:\Program Files\Unity\Hub\Editor\6000.0.48f1\Editor\Data\MonoBleedingEdge\bin\mono.exe" "C:\Program Files\Unity\Hub\Editor\6000.0.48f1\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\SimpleWebServer.exe" buildFolder http://localhost:8000/
```

- Unity 2022.3.60f1 の場合

```
"C:\Program Files\Unity\Hub\Editor\2022.3.60f1\Editor\Data\MonoBleedingEdge\bin\mono.exe" "C:\Program Files\Unity\Hub\Editor\2022.3.60f1\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\SimpleWebServer.exe" buildFolder 8000
```

- Unity 2021.3.45f1 の場合

```
"C:\Program Files\Unity\Hub\Editor\2021.3.45f1\Editor\Data\PlaybackEngines\WebGLSupport\BuildTools\SimpleWebServer.exe" buildFolder 8000
```

上記のコマンドを「コマンドプロンプト」などから実行すると起動できます。  
毎回入力するのが面倒であれば、batファイルなどにするといいでしょう。

---

最初は2021では起動したものの、2022・6ではエラーで起動せず。  
どうしたらいいかと調べたら、monoで起動していたみたいだったので、それを試してみたら2022でも起動しました。  
また、6ではポート番号からURLに変更になったようで、そちらを変更してみたら上手くいきました。

困っている人の参考になれば幸いです。  
以上。
#0131（2025/05/12）狩野モデルとは

# 狩野モデルとは：エンジニアのための顧客満足設計入門

## はじめに

プロダクト開発において、どの機能を優先的に実装すべきか悩んだ経験はありませんか？狩野モデル（Kano Model）は、顧客満足の観点から機能の優先順位を明確にするための有効なフレームワークです。この記事では、狩野モデルの基本とエンジニアが実務で活用するための方法について解説します。

---

## 狩野モデルとは

狩野モデルは、1980年代に東京理科大学の狩野紀昭教授が提唱した理論です。このモデルは、プロダクトやサービスにおける各機能が、顧客満足にどのような影響を与えるかを5つのカテゴリに分類して理解します。

### 5つの品質カテゴリ

| カテゴリ  | 説明                                   | 顧客満足への影響            |
| ----- | ------------------------------------ | ------------------- |
| 基本品質  | あって当然の機能。欠けると不満になるが、満たしても感動はない。      | 無いと不満、大きな満足にはつながらない |
| 一元的品質 | あればあるほど満足度が上がり、なければ不満が増す性能やコストなどの要素。 | あれば満足、なければ不満        |
| 魅力品質  | 想定していなかったが、あると非常に嬉しい機能。              | 無くてもOK、あれば大満足       |
| 無関心品質 | あってもなくても顧客にとってどうでもいい機能。              | 満足にも不満にもつながらない      |
| 逆品質   | あればかえって不満を生む機能。顧客の価値観や期待と合致しない。      | あれば不満を招く            |

このように分類することで、機能実装の判断基準が明確になり、限られたリソースをより効果的に活用できます。

---

## エンジニアが実務で活用する方法

### 1. 機能候補の洗い出し

開発チームやプロダクトオーナーと連携し、ユーザーのニーズや要望、アイデアをもとに機能候補をリストアップします。

### 2. 顧客アンケートの設計と実施

各機能に対して、以下の2つの質問をユーザーに行います：

* 肯定的質問：「この機能があったらどう思いますか？」
* 否定的質問：「この機能がなかったらどう思いますか？」

それぞれに対して以下の5段階で回答してもらいます：

* とても嬉しい
* まあ嬉しい
* どちらでもない
* あまり嬉しくない
* 嫌だ

このペアの回答から機能のカテゴリを分類できます。

### 3. 集計と分析

アンケート結果をもとに、各機能がどのカテゴリに属するかを分類します。分析結果を表やグラフ（Kano plot）で可視化することで、チーム内の意思決定がしやすくなります。

### 4. 優先順位の決定と実装計画

* 基本品質：必ず実装。ないと顧客が離れる要因に。
* 一元的品質：競合と差をつけるための強化対象。
* 魅力品質：リソースに余裕があれば検討。差別化要素。
* 無関心・逆品質：基本的に実装しない方向で。

### 5. 定期的な再評価

市場や顧客の期待は時間とともに変化します。定期的に狩野モデルを再評価することで、常にユーザー中心の開発が可能になります。

---

## おわりに

狩野モデルは「顧客満足」という視点から、エンジニアがより戦略的に機能設計・優先順位づけを行うための強力なツールです。プロダクト開発の現場で、「ユーザーの本当の期待」に応えるために、ぜひチームで取り入れてみてください。
FastAPI × ALB 環境での HTTPS→HTTP リダイレクトによる CORS ヘッダー消失問題の原因と解決


## はじめに
AWS の Application Load Balancer（ALB）で HTTPS 終端を行い、バックエンド（FastAPI／Uvicorn）へは HTTP でリクエストを流す構成において、CORS エラーが発生する事例がありました。  
原因は **HTTPS→HTTP へリダイレクトされる際に必要な `Access-Control-*` ヘッダーが欠落すること** にありました。この記事では、その原因と解決手順をまとめます。

## 問題の再現例

1. ブラウザがプリフライト（OPTIONS）リクエストを発行  
   ```bash
   OPTIONS https://request.example.com
   Origin: https://client.example.com
   ```

2. ALB（HTTPS→HTTP 終端） → Uvicorn（HTTP:80）へ転送

3. FastAPI がリダイレクトを返却  
   ```http
   HTTP/1.1 307 Temporary Redirect
   Location: http://request.example.com/
   ```

4. ブラウザが HTTP 側へ再プリフライト  

5. ALB の HTTP→HTTPS リダイレクトルール（301）で HTTPS に戻る

6. **一度も CORS ヘッダーが付与されず** ブラウザが以下を出力して失敗
   ```
   No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
   ```  

## 原因の詳細

- **ALB が HTTPS 終端** → バックエンドへは HTTP で転送  
  この際、起動時の設定を行なっておらず、`X-Forwarded-Proto: https` が付与されていない
- **Uvicorn** はデフォルトで「127.0.0.1 からのプロキシのみ信頼」  
  → ALB からの `X-Forwarded-Proto` を無視 → `request.url.scheme` が `http` のまま  
- ブラウザは一度 HTTP エンドポイントへ飛び、CORS ミドルウェアを経由しないまま再リダイレクト  
- 結果的に **CORS ヘッダーが一切付与されず** リクエストがブロック

## 解決方法

### 1. Uvicorn 起動時にプロキシを全許可する

Dockerfile や起動スクリプトで、以下オプションを追加します。

```bash
uvicorn app.main:app --reload --proxy-headers --forwarded-allow-ips="*"
```

- `--proxy-headers`：X-Forwarded ヘッダーを処理  
- `--forwarded-allow-ips="*"`：任意のプロキシ IP を信頼

### 2. コード上で ProxyHeadersMiddleware を追加

CLI オプションが使えない場合は、`main.py` に以下を挿入します。

```python
from starlette.middleware.proxy_headers import ProxyHeadersMiddleware

app = FastAPI()
app.add_middleware(ProxyHeadersMiddleware, trusted_hosts="*")
```

## まとめ

1. **真の原因**：HTTPS→HTTP リダイレクト時に CORS ヘッダーが付かずブロック  
2. **対策**：Uvicorn に `--proxy-headers` と `--forwarded-allow-ips="*"` を追加する

以上の手順で、ALB 経由の CORS エラーは解消できます。ぜひお試しください！
いろんなアルゴリズム"00.00.00.13"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.13

# ReferenceID

# n桁のm進数を全て列挙
* m色の玉が入った箱がn個あり、それぞれの箱から玉を一つずつ取り出すときの順列を全て列挙

```python:
def enumeration(il, ol, N):
	ol2 = []
	if not ol:
		ol2 = [[i] for i in il]
	else:
		for i in il:
			for j in ol:
				ol2.append([i]+j)
	if len(ol2[0]) == N:
		return ol2
	return enumeration(il, ol2, N)
```

# 使用方法
```python:
enum = enumeration(['a','b','c'], [], 2)
print(enum)
"""
[['a', 'a'],
 ['a', 'b'],
 ['a', 'c'],
 ['b', 'a'],
 ['b', 'b'],
 ['b', 'c'],
 ['c', 'a'],
 ['c', 'b'],
 ['c', 'c']]
"""
```
[Cursor] AIが色々な変更を混ぜてくる!!!

## どんな機能なのか
- AIの変更をグループ化して分かりやすくしてくれる!
- グループごとにAccept/Rejectできる!!


### 具体的に
画像の例では、AIの行った変更が2つにグループ化されています。

- Modifying user data retrieval to handle cases where no user is found
- Updating user ID reference to dynamically use retrieved user's ID

1つ目のグループは私の望んだとおりの変更なので、反映させても良いです。
しかし、**2つ目のグループは望まない変更**です。
このとき、**1つ目のグループだけ変更を反映させたい**ですね!
それをできるのがこの機能!!!

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3803067/3e4e727c-9e52-4d1d-9ce1-ddca0e6a03c5.png)


## どんな嬉しいことがあるのか
- AIが要らない変更を加えることを防げる
- 1つのコミットに関係のない変更が混ざるのを防げる (※)

:::note info
※ Gitでプロジェクトを管理している際、1つのコミットに対し1つの変更を含めるようにすべきとされています。つまり、1つのコミットに2つ以上の関係のない変更を含ませてはいけません。(コミットメッセージと実際の変更にずれがないようにすべき、と言ったほうが伝わるかも)　AIが行った変更をグループ化させることで関係のない変更が含まれていることに気づきやすく、コミットに関係のない変更が含まれてしまうのを防ぐことができます。
:::

## どこから有効にするのか

:::note warn
この情報は古いです。
この機能を有効にする方法が変わったようです。
ですので、この節の情報は参考までにご覧ください。
:::

1. カーソルの設定を開く
    -  Ctrl + Shift + P をしてから、`cursor settings`と入力<br>_OR_
    -  右上の歯車マーク<br>_OR_
    - Ctrl + Shift + J
1. Features を開く
1. 下にスクロールして、`Auto Group Changes`を探す


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3803067/fbe6db25-1be7-4f9f-be59-e80b6d604d94.png)
[8086実機実験]BIOSのリセットベクタにjmpしたら無限再起動する？

## やりたいこと
CPUは電源投入後、メモリ上のFFFF0h(リセットベクタ)から実行を開始し、BIOSの処理を経て、最終的にメモリ 7C00h に読み込まれたブートローダーを実行します。
今回は「ブートローダーから強制的にFFFF0hにジャンプすると、CPUが無限に再起動を繰り返すのではないか？」という仮説の下、実験を行いました。

※UEFIは異なる仕組みで起動しますので、本記事の対象外です。

## 実験用プログラム
```
[org 0x7C00]
bits 16

start:
    jmp 0xF000:0xFFF0

times 510-($-$$) db 0
dw 0xAA55
```
## 実験結果
以下の方法を用いて8086実機上から実行させています。
https://qiita.com/earthen94/items/10c012ae14545e9f4284

分かり辛いですが、再起動を繰り返しています。
![ezgif-3b7c880b7c9d3b.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/76a7fe74-3f72-422b-8074-e7a252f50f23.gif)
Terraform Associate (003) 受験記録

:::note info
この記事の内容は2025年5月9日時点のものです。
:::
# はじめに

2025年5月9日に、[Terraform Associate (003)](https://developer.hashicorp.com/certifications/infrastructure-automation) を受験し合格しました。
今後受験される方のお役に立てば幸いです。
なお、試験の概要や一般的な注意事項等は、公式サイトおよび既存の公開情報を参考にされてください。

# 試験準備（学習編）

※筆者はTerraform初学者です。

・Udemyで提供されているTerraformの講義ビデオを視聴しました。
[HashiCorp Certified: Terraform Associate 2025](https://www.udemy.com/course/terraform-beginner-to-advanced/?srsltid=AfmBOoqa8lA_NHKa1X99hEmujVy8s_q028-337hi9q1pbfd6Xuhxq0iW)

・5日間に渡り研修を受ける機会があり、講義&デモ環境を使用した実践を通して、Terraformの基本的な内容について学習しました。

・その後試験を受けるにあたり、Udemyで提供されている練習問題に取り組みました。
[HashiCorp Certified: Terraform Associate Practice Exam 2025](https://www.udemy.com/course/terraform-associate-practice-exam/?kw=HashiCorp+Certified%3A+Terraform+Associate+Practice+Exam+2025&src=sac&couponCode=V2JPLETSLEARN)


# 試験準備（手続き編）
・受験にあたりIDの提示を求められるのですが、私はこのIDにマイナンバーカードを使用しました。
<font color="Red">試験予約時の氏名の表記は、マイナンバーカードの表記と同じ日本語で登録をしました。</font>
インターネットに公開されている受験者のブログ等を見る限り、試験の氏名登録にはローマ字を使用し、パスポートをIDとして用いて受験をされた方が多いようですが、私はパスポートの更新・受け取りまでに2週間以上かかってしまう状況でしたので、このような形で受験をしました。
当日は試験官から特に何かこの点についてコメントがあることはありませんでしたが、不安な方は、実績の情報が多いパスポートを使用される方が無難かもしれません。

・試験の予約にあたりGitHubのアカウントが必要です。予約の画面遷移の中で「GitHubからのログインが必要です」の旨を伝える画面が表示されます。

・英語が母国語ではない場合は試験時間を30分間延長できるオプションがあり、私は予約時こちらのオプションを申請しました。

・試験は試験開始時刻の24時間前までならキャンセル可能なようです。

・試験中は、カメラで自身および受験している環境を投影している必要があります。私はWebカメラを所有していたので、そのカメラをノートPCに接続して使用しました。

・環境チェックは試験日より前でも事前に実施できるので、ブラウザや映像・音声など、要件を満たしていることを確認しました。
※環境チェックのボタンを押すと自動で検証して各チェック項目の結果を返してくれます。


# 試験当日
### 試験開始前
・ブラウザにはChromを使用しました。

・25分前くらいにサイトにアクセスし、念の為環境チェックを再度行い問題ないことを確認しました。15分前にならないと試験開始のための画面に進むことができないようです。
※環境チェックなどが行える画面→試験開始のための画面（ここで初めて試験官と繋がる）→試験画面という画面遷移でした。

・試験開始のための画面に進む前の画面でもチャットボタンが存在しており（まだ試験官とは繋がっていません）、そこからメッセージを送ることができました。そこでのやり取りは1通目送信後に自動終了してしまうのですが、10分程度でメールに連絡が届きました。
当日試験開始のための画面に進むまでに困った時は、そのチャットをトリガーに、メールでやり取りができるようです。

・試験開始のための画面に進むと少し待機した後に試験官とのやり取りが始まります。
部屋の撮影（机上と机の下含む）、IDの投影に始まり、机の上のものをどかすように、また携帯を離れた場所に置くよう指示がありました。

・一通りの確認が完了すると、試験に進むことができます。

### 試験中
・カメラに顔が映っていなかったので、顔と体はカメラに収めるようにとチャットで指示がありました。

・チャットは新着コメントがあると、チャット画面が自動で画面右に大きく表示されるので、コメントが届いていないか都度気にする必要はありませんでした。

### 試験後
・合否はアンケート回答後その場で分かりました。

・結果のレポートは翌日メールで届きました。

# 感想
Terraformの基本的な内容について体系立った学習ができて良かったと思います。
これから受験を検討されている方の参考になれば幸いです。
生成AI活用して簡単な(Switchbotの温度を表示する)Webサイトを作った感想

# 作ったもの

自宅のSwitchbotの温湿度計のデータを見れるウェブサイトを作りました。
制作時間は実質6時間くらいです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789636/a3ec2882-7d99-4601-b51b-99543e93e4d0.png)

https://diuxamlfu3f0g.cloudfront.net/202505_switchbot/index.html

# 作った過程、簡単な構成

## 背景

SwitchbotのAPIというのがあり簡単に使えるということを知り、
また、**生成AIを使って自動でコーディングしてWeb系のアプリを作る**というのが流行っているそうなので、マネしてみたく、使ってみました。

## 簡単な構成

AWSのサーバレスな構成です。データの流れに注目した図です。（ちゃんとした書き方をあまり知らない）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3789636/6af054cd-a1fd-48c5-8b56-a3e2575f49e3.png)

1. Switchbot API→SQS
Lambda/PythonでSwitchbotのAPIを叩き、SQSに配信します。
S3に一気に配信してもいいのですが、構成を悩んでいたので、暫定的にSQSに貯めていました。
SQSはよく分からずFIFOキューにしました。
1. SQS→S3
Lambda/PythonでSQSの内容をCSVに整形します。
CSVは日ごとにファイルができます。例：`2025-05-11.csv`
1. S3→CloudFront
静的Webサイトを構成して、JavaScript（ECharts）でグラフを描画しています。

# 生成AIを使った感想

## 構成の検討・相談では良い感じに使えた(ChatGPT)

「Swtichbotの温度データを良い感じに可視化したい」というお題だと、構成が無限に考えらると思います。
例えば、データ蓄積はS3/RDB/Kinesis Firehose？など色々あります。そこを「なるべく安くて簡単な構成」と相談するとS3が良いと説得してくれました。サンプル構成付きで。
また、可視化部分も、静的Webサイト(Chart.js/EChars）、EC2+Metabase、Grafana Cloud、Google Locker Studioなど色々あります。私が「そこまで機能はリッチでなくてよく、安いほうがよく、すでにあるCloudFrontを活用したい」と聞いたら、静的Webサイトをオススメしてくれました。

## 高速にプロトタイピングできる(Claude3.7sonnet)。ただし、要件出し・レビュー・修正は人間も必要

Claude3.7 sonnetはすごいです。人間が手で書いたら数時間かかるようなコードを5分くらいで書いてくれます。雑に依頼して、「こんな感じでどうでしょう？」とすぐに提案してくれます。

ただ、**①要件をちゃんと説明・入力すること、②所望の動作になっているかチェックすること、③必要な部分を修正すること**、の3つは、まだまだ人間側の工夫も必要かなと思いました。

### 要件を入力

要件については、ちゃんと人間が意思を持って言語化する必要があると思いました。
もちろん「なんでもいい」のであれば適当でいいのですが、適当に入力すると「コレジャナイ」ものが出てくることもあります。

私は、以下のようなプロンプトで入力しました。

```
- 要求
  - Apache EChartsを使って、気温データを可視化したいです。
  - 静的Webサイトで動くようなスクリプトにしてください
  - エラーは逐一consoleに表示してください。

- データは以下のような形式で、サーバ上の同じディレクトリに2025-05-08.csvなど日付ごと保存されています。
  - curretTimeがタイムスタンプで、temperatureが温度です。
  - fetch()で読み込んできてください
  - 複数日付（可能であればディレクトリの中身すべて）のデータを読み込んできて描画したいです。
  - モックデータでのデモ表示などは不要です

- 機能
  - 期間を「生データ、1日、7日、30日」などで選択できるようにしてください
  - 表示事項を「気温、湿度、バッテリー」で選択できるようにしてください
```

### チェック・レビュー

細かいチェックは不要ですが、色々とポチポチ、動作確認をしておかしい点を見つけるのは人間の役割です。
特に、LLM側は本来「それっぽいものを返答する」というロジックで動いており、細かい実行環境は知らないので、「実際に想定動作しない」ことが**まあまあ**あります。この点は人間も「知識と経験」のようなものがあった方が、解決が早くなりそうだと思いました。

### 修正

Claude3.7 sonnetのクセですが、「Aの動作をBするようにして。Cの動作をDするようにして」などと修正依頼すると、それ以外の部分も改修してきて、プログラムの構成・Webサイトの見た目を全く変えて出力してくることがあります。
「要らないところも勝手に直してきたな・・」と思い、「Eは不要です。書き直して」などと依頼しても、以前の姿に戻らないこともあります。

この点は新規でチャットを作り、修正したいプログラムを丸々入力して、「修正箇所のみ教えてください」というようにアドバイスを求めると、必要な書き換え箇所を出力してくれるイメージでした。
このように、若干「依頼の仕方」を工夫して所望のモノを引き出す必要があります・・・

## 細かい不満はあるが、スピードアップは間違いない

修正などに手間取るという不満を述べましたが、自分でイチからコードを書くのに比べれば、圧倒的に早いです。
今後もどんどん活用・浸透していくんだろうな・・・と感じました。
【保存版】Pythonの便利な組み込み関数10選と活用例

## はじめに

Pythonには多くの便利な「組み込み関数」が標準で用意されています。これらを活用することで、コードの可読性や生産性が大きく向上します。本記事では、初心者から中級者まで役立つ「おすすめ組み込み関数10選」とその活用例を紹介します。

---

## 1. `len()`
リストや文字列などの要素数を取得します。
```python
lst = [1, 2, 3]
print(len(lst))  # 3
```

## 2. `enumerate()`
ループ時にインデックスと要素を同時に取得できます。
```python
for i, v in enumerate(['a', 'b', 'c']):
    print(i, v)
```

## 3. `zip()`
複数のリストを同時にループできます。
```python
names = ['Alice', 'Bob']
ages = [24, 19]
for name, age in zip(names, ages):
    print(name, age)
```

## 4. `map()`
関数をリストの各要素に適用します。
```python
nums = [1, 2, 3]
squared = list(map(lambda x: x**2, nums))
print(squared)
```

## 5. `filter()`
条件を満たす要素だけを抽出します。
```python
nums = [1, 2, 3, 4]
even = list(filter(lambda x: x % 2 == 0, nums))
print(even)
```

## 6. `sorted()`
リストなどをソートします。
```python
nums = [3, 1, 2]
print(sorted(nums))
```

## 7. `any()` / `all()`
条件を満たす要素が「1つでもある」「すべて満たす」か判定します。
```python
nums = [1, 2, 3]
print(any(x > 2 for x in nums))  # True
print(all(x > 0 for x in nums))  # True
```

## 8. `range()`
指定した範囲の連番を生成します。
```python
for i in range(5):
    print(i)
```

## 9. `sum()`
合計値を計算します。
```python
nums = [1, 2, 3]
print(sum(nums))
```

## 10. `set()`
重複を除去した集合を作成します。
```python
nums = [1, 2, 2, 3]
print(set(nums))
```

---

## おわりに

組み込み関数を使いこなすことで、Pythonのコードはよりシンプルかつ強力になります。ぜひ日々の開発で活用してみてください！
WebフレームワークのAstroを理解する

## きっかけ
私的な趣味でWebサイトを開発したい欲求があり、下記要件を満たせるフレームワークを調査していたところ、Astroが候補に挙がりました。

- パフォーマンス重視であること
- 基本的にはブログ（静的サイト）を生成、デプロイできること
- サーバーレス（低コスト）で運用できること
- 一部ぺージにはインタラクティブなパーツ（Webコンポーネント）を実装できること

ひとまず使ってみるのも手ではありますが「道具の使い方を理解してから使う」ことをモットーにしているのでドキュメントを読んで咀嚼したメモを残しておきます。


## Astroとは？
公式ページでまず述べられているのは「The web framework for content-driven websites」との事です。ブログ、Eコマースやなどのコンテンツ駆動（ユーザーへ見せる物）のサイトを構築することを念頭にしたWEBフレームワークらしい。つまりはWebアプリケーション（SNSとか）を考慮していないとも解釈できるが詳しく見ていくとしよう。

## 特徴
[公式ドキュメントの導入記事](https://docs.astro.build/ja/concepts/why-astro/)に述べられているので詳しく見ていく。


### HTMLとJavaScriptの分離

まず目を引いたのは下記の記述ですね。

> Zero JS, by default: Less client-side JavaScript to slow your site down.

[スクリプトの処理](https://docs.astro.build/ja/guides/client-side-scripts/#%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%AE%E5%87%A6%E7%90%86) を読んでみると、Astroでコンポーネントを定義する際に参照したスクリプトファイルや`<script>`タグの内容がAstroによって切り離されて、`type=module`として組み込まれる仕様だそうです。

スクリプトタグをBodyの最後へ記述してHTMLの読み込みを止めないところから一歩踏み込んで、明確にHTMLのロードを待たせてからスクリプトを展開させることにより、レンダリング時間を最小限にさせていることがわかりますね。時にはスクリプトタグを直接出力したいケースについても考えられていて、`is:inline`ディレクティブを記述するとAstroがビルドする時の分離処理から除外されてそのまま出力されるそうだ。

この機能の良い所は、コンポーネントに記述されたスクリプトやスタイルが、フレームワークによってバンドル化されることで、**同一のコンポーネントを複数回レンダリングする時** に分離したスタイルやスクリプトのバンドルが共有されるので無駄が生じない設計になっている所だと思う。

### アイランドアーキテクチャ

続いてはAstroの目玉機能？の[アイランドアーキテクチャ](https://docs.astro.build/ja/concepts/islands/)についてです。

記事を読んでみた個人的な感想は「アトミックデザイン（コンポーネントベース）と親和性が高い？」と感じた事です。Next.js等はWEBぺージ全体をJavaScriptでレンダリングさせるのに対して、Astroは部分的にサーバーサイドで静的なHTMLをレンダリングさせるか、ReactやVueを用いてインタラクティブに表現させるか選択することができる。


個人的な解釈は、**島（コンポーネント）ごとに自治権（レンダリング方法の決定権）を持っている**イメージ？

このアイランドアーキテクチャを知った時は、Astroでパフォーマンスを突き詰めたWEBを構築しようとすると、アトミックデザインに寄っていくと感じました。必然的にコンポーネントが細かくなって地方自治が捗るからね。

### コンテンツコレクション

[コンテンツコレクション](https://docs.astro.build/ja/guides/content-collections/)はAstroが「コンテンツ駆動」であることを実現する機能の1つだと感じました。特徴について以下に述べます。

### コンテンツの型を定義できる
提供するコンテンツに種類（ブログ、ドキュメント、ポエム）があるとして、記事の種類ごとにどんな情報が格納されるかフォーマットを定義することできる。TypeScriptの型として定義されるそうなので、追加した記事にフォーマット違反が有った場合はビルド時にエラーが発生して、違反の内容はコレクションの定義に基づいてメッセージが出力されるとの事で修正も容易になるはずだ。

### 記事自体はmarkdown(md)やmdx(markdown in JSX)で管理できる
先述の記事の型を管理できる関係で、markdown(md)ファイルには型のプロパティを埋めるだけで記事が書けるようになるみたい。[microCMS](https://microcms.io/)でコンテンツのスキーマとデータをmicroCMSで管理させて、Webサイトのビルドする時はAstroにデータを食わせる構図だと面白いかも？

### ぺージのテンプレートを作れる
記事の内容をコレクションに突っ込んだら、コレクションの内容から記事ページを生成させることができる。[公式ドキュメント](https://docs.astro.build/ja/guides/content-collections/#%E9%9D%99%E7%9A%84%E5%87%BA%E5%8A%9B%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88)では指定したコレクション全てを同一のテンプレートで出力させるサンプルもある。大は小も兼ねることから、特定の記事だけスペシャルなテンプレに振り分けて出力させることも可能になるかな？


## 最後に
今回は自分の作ろうとするWebサイトでAstroが要件を満たせていそうかの観点でドキュメントを部分的にチェックしました。全体の30％も見られていないと思いますが、基本的な設計思想や実装されている機能が自分の理想に近いと感じられました。React(Next).jsと比べると、アプリケーションとして構築するには機能が弱いというか、コンセプト外な感じなので、Webサイトの要件・仕様を明確にして適切に技術選定するべきだと感じました。次はAstroを実際に使ってみた記事を書きたいな。