OmniAICreator/Qiita-1.07M huggingface dataset:
AWS完全初心者がAWS-CLFに合格した話

## はじめに
こんにちは。Tsukasaです!
今回はAWS完全初心者である自分がAWS認定試験のファーストステップであるAWS Cloud Practitioner試験(以下AWS-CLF)に挑戦して合格したことについて記事を書いていけたらと思います。
合格してからだいぶ時間が経ちましたが、自分のやってきたことのアウトプットとこれからCLF合格を目指す方のために少しでも参考になったらと思います。
よろしくお願いいたします！

## AWS-CLFとは
AWS-CLFはAWS認定試験12種類のうちの1つになります。
12種類の中でも最も難易度が低い初心者向けの資格となっています。
AWSの公式サイトにもAWS-CLFについて以下のような記載があります。
『AWS Certified Cloud Practitioner は、AWS クラウド、サービス、用語の基本的かつ高度な理解を検証します。 これは、IT やクラウドの経験がまったくない個人でクラウドのキャリアに切り替えるか、基礎的なクラウドリテラシーを求めている基幹業務の従業員にとって、AWS 認定ジャーニーの良い出発点となります。』

https://aws.amazon.com/jp/certification/certified-cloud-practitioner/

詳しくはサイトをご覧いただけたらと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2478024/b0e07087-cab9-4749-aacf-344ece52c818.png)


## 合格に要した時間
結論から言うと合格に要した時間は2ヶ月半となります。
2024年10月中旬頃から勉強を開始し、12月末に合格しました。
客観的に見ても時間がかかりすぎたかなと思います。
これはあくまでも私のやり方なので、もっと効率的で良い勉強方法があるかもしれません。
以下に勉強方法を紹介しますが、参考程度に考えていただけたらと思います。

## 勉強方法
AWS-CLFを受験される方はAWSに関して初心者の方が多いと思います。
そもそもAWSとは？Cloudとは？といったところからスタートとなると思います。
その場合AWSのサービス名どころかCloudに関する知識や用語についても全く知らないところから始まると思います。
私はまずそのような用語やAWSやCloudについて学習するために参考書を読んで知識をインプットするところから始めました。
私は業務でもAWSを全く触ったことがなく、何の知識もなかったため、AWSは何ぞや？というところからのスタートとなりました。
そのためAWSの基本の参考書とCLFに特化した２冊を用いてインプットを始めました。

https://www.amazon.co.jp/dp/4815625387?tag=nokonokonoko0-22&linkCode=ogi&th=1&psc=1

https://www.amazon.co.jp/dp/B08147GCLS?ref=cm_sw_r_ffobk_cp_ud_dp_86K7CQ59C9E7GW2TNPK7&ref_=cm_sw_r_ffobk_cp_ud_dp_86K7CQ59C9E7GW2TNPK7&social_share=cm_sw_r_ffobk_cp_ud_dp_86K7CQ59C9E7GW2TNPK7&bestFormat=true

このインプットには1ヶ月かかりました。
とは言え、1度参考書を読んだだけで理解できるはずがありません。
あまり深くは考えすぎず、全体を何となく読むくらいに留めました。

その後更にインプットをするためにUdemyで以下の動画を視聴しました。
全てをそのまま見ると時間がかかるので1.5倍速で視聴しました。
ハンズオンもあり、知識を定着させるにはこのような動画視聴も良いかもしれません。
またUdemyは定期的にセールがあるので、セール時に動画を買うのが良いと思います。

https://www.udemy.com/course/ok-aws-e/?couponCode=ST8MT220425G2

動画視聴の後は同じくUdemyの練習問題集を購入し、こちらをひたすら解き続けました。
65問の問題集が全部で6セットありましたが、こちらを6,7回程解いたかと思います。(記憶が曖昧ですが、、)

https://www.udemy.com/course/aws-4260/?couponCode=ST8MT220425G2

## 実際に試験を受けてみて
実際に試験を受けてみた感想としては練習問題よりも難しかったなというのが正直な感想です。
正直あまり手応えはなく、受かったか落ち方かなり際どいなと感じました。
CLFは試験終了と同時にパソコンに合否だけが表示されます。
手応えがなかっただけに合格の表示が出た時は驚きましたし、同時に嬉しかったです。
私は午前９時に受けましたので、点数などの詳細の連絡はその日の夜に届きました。
以下が私の得点になります。

![スクリーンショット 2025-04-23 20.20.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2478024/78a16059-9aa1-41c1-953a-432e14c7c593.png)
CLFは700点合格となりますが、私のスコアは723点とかなりギリギリな結果となりました。
それでも合格は合格なので、胸を張ろうと思います！笑

## 終わりに
いかがでしたでしょうか？
正直時間はかかりましたし、他にもっと良い勉強方法はあったかと思います。
ですが、結果は一発合格だったので、このやり方は間違っていなかったと思います。
この方法はあくまでも一例なので、ご自身に合った勉強方法を選択されれば良いと思います。
他にも勉強方法をアップされている方はたくさんいらっしゃるので、是非比較してみてください！
この記事がこれからCLFを受ける方にとって少しでも参考になることを祈っています。
【基本情報技術者試験 対策②】情報セキュリティの脅威※参考リンク付き

 **💻基本情報技術者試験 テクノロジ系 技術要素・情報セキュリティ🔓**

本日は情報セキュリティの脅威に関する要点をまとめます。
学習の参考になったサイト等もリンクで添付していますので、是非ご覧ください✨
※リンクは2025年4月時点の情報です。ページが削除・変更されている場合もありますのでご了承ください。

 ## 「情報セキュリティ」とは？
> JISと呼ばれる国の規格では、次のように定められています。
  **「情報の機密性、完全性、及び可用性を維持すること」** 
 
→「真正性」「責任追跡性」「否認防止性」「信頼性」の4つの特性も
　情報セキュリティの要素に含まれる。

 #### それぞれの特性の意味
 - 機密性…情報が守られている特性
 - 完全性…情報を正確に保ち、改ざん・破壊されない特性
 - 可用性…必要な時に情報へアクセスできる特性
 - 真正性…なりすましがないことを示す特性
 - 責任追跡性…誰がいつ何をしたのか、後から追跡できる特性
 - 否認防止性…何かが起きたとき、原因となる人が否定できない証拠を残しておく特性
 - 信頼性…システムの故障や不具合が発生しにくく、正しく動作することを示す特性

---
 
 ## 「脅威」とは？
> 情報セキュリティを脅かすリスク要因のこと
  **「人的脅威」「技術的脅威」「物理的脅威」** の3つが主な分類となる

 **⑴人的脅威** ※人によって引き起こされる脅威
　・ソーシャルエンジニアリング
　・不正のトライアングル

---
 
 **⑵技術的脅威** ※技術的な手段によって引き起こされる脅威 
 
 #### ■攻撃の準備

- **ポートスキャン**  
  [ポートスキャンとは？特徴と種類、対策方法をわかりやすく解説](https://www.shadan-kun.com/waf_websecurity/portscanning/)

- **セキュリティホール**  
  [セキュリティホールへの攻撃とは？攻撃例と対策を簡単に解説](https://office110.jp/security/knowledge/cyber-attack/security-hole-measures)

 #### ■パスワードを割り出す攻撃

- **ブルートフォース攻撃**  
  [ブルートフォース攻撃（ブルートフォースアタック）とは？](https://www.ines-solutions.com/industry/a318)

- **辞書攻撃**  
  [辞書攻撃とは？手口やリスク・対策を解説！NGパスワードの事例も](https://www.lanscope.jp/blogs/cloud_security_pfs_blog/20231027_15937/)

- **パスワードリスト攻撃**  
  [パスワードリスト攻撃とは？わかりやすく対策や原因・被害事例を解説](https://www.lanscope.jp/blogs/cyber_attack_pfs_blog/20230905_33240/)

 #### ■マルウェアによる攻撃
- **マルウェア
（ボット・スパイウェア・ランサムウェア・キーロガー・バックドア・コンピュータウイルス）**  
  [マルウェア攻撃 - Rapid7](https://www.rapid7.com/ja/fundamentals/malware-attacks/)

 #### ■WEBサイトに仕掛けられる攻撃

- **フィッシング**  
  [フィッシング攻撃とは？その手口も解説 - Cloudflare](https://www.cloudflare.com/ja-jp/learning/access-management/phishing-attack/)

- **ドライブバイダウンロード**  
  [ドライブバイダウンロード攻撃とは？攻撃の仕組みや回避方法を解説](https://www.kaspersky.co.jp/resource-center/definitions/drive-by-download)

- **SEOポイズニング**  
  [SEOポイズニングとは？- クラウドストライク | CrowdStrike](https://www.crowdstrike.com/ja-jp/cybersecurity-101/social-engineering/seo-poisoning/)

- **DNSキャッシュポイズニング**  
  [インターネット10分講座：DNSキャッシュポイズニング - JPNIC](https://www.nic.ad.jp/ja/newsletter/No40/0800.html)

- **SQLインジェクション**  
  [SQLインジェクションとは？仕組み・被害事例・対策をわかりやすく解説](https://www.shadan-kun.com/waf_websecurity/sql_injection/)

- **クロスサイトスクリプティング（XSS）**  
  [クロスサイトスクリプティング（XSS）とは？わかりやすく解説](https://www.shadan-kun.com/waf_websecurity/xss/)

 #### ■その他の攻撃
- **スパム**  
  [スパムとは？意味・危険性・見分け方から対策までわかりやすく解説](https://business.ntt-east.co.jp/content/cloudsolution/column-367.html)

- **DoS攻撃**  
  [DoS攻撃・DDoS攻撃とは？意味と対策方法をわかりやすく解説](https://www.shadan-kun.com/waf_websecurity/dos_ddos_attack/)

- **ディレクトリトラバーサル攻撃**  
  [ディレクトリトラバーサルとは？対策や例をわかりやすく解説](https://www.lanscope.jp/blogs/cyber_attack_pfs_blog/20231128_16893/)

---

 **⑶物理的脅威** ※ネットワークなどを使わない直接的な手段によって引き起こされる脅威
- 水害、落雷、地震、大気汚染、爆発、火災、侵入、盗難など

---

 ### 参考文献
[いちばんやさしい 基本情報技術者 絶対合格の教科書＋出る順問題集（SBクリエイティブ公式サイト）](https://www.sbcr.jp/product/4815624262/)

[だれでもわかる＆受かる！　情報セキュリティマネジメントやさしいテキスト+頻出問題集[科目A・科目B]（SBクリエイティブ公式サイト）](https://www.sbcr.jp/product/4815616151/)
※上記リンクは2025年4月時点の情報です。ページが削除・変更されている場合もありますのでご了承ください。
Notesについてまとめてみた

# 概要
社内コミュニケーションツールであるNotesについてざっくりとまとめてみました。

# 目次
- [Notesとは](#notesとは)
- [歴史](#歴史)
- [Dominoとは](#dominoとは)
- [ベンダーの移り変わり](#ベンダーの移り変わり)
- [サポート終了問題](#サポート終了問題)
- [他の社内コミュニケーションシステムに移行する際の課題](#他の社内コミュニケーションシステムに移行する際の課題)
- [Notesの使用方法](#notesの使用方法)

# Notesとは
Notesは、[HCLテクノロジーズ](https://ja.wikipedia.org/wiki/HCL%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%82%BA)が開発、運用している[グループウェア](https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%A9%E3%83%9C%E3%83%AC%E3%83%BC%E3%83%86%E3%82%A3%E3%83%96%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2) (情報共有ツール) です。
文書の共有や電子メール、カレンダーやスケジュール管理、掲示板などの機能をもっています。
グループウェアの先駆けとなったツールでもあります。

# 歴史
1989年に、[ロータス・デベロップメント](https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%BC%E3%82%BF%E3%82%B9_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2))という会社により「Lotus Notes」という名前でリリースされました。
1995年にはIBMがロータス・デベロップメントを35億ドルで買収し、NotesはIBMのソフトウェア部門の一部の製品となりました。
1996年にはNotesのデータベースをブラウザからアクセスできるようにする「Domino」がリリースされ、Notesで使用されているサーバーを総称してDominoと呼ぶようになりました。
2013年には名称が「Lotus Notes」から「IBM Notes」に変更されました。
その後2019年にIBMからHCLテクノロジーズに売却され、「HCL Notes」という名称になりました。

:::note
ちなみに2000年前後は、企業内コミュニケーションのシステムを簡単に作れる基盤としてNotesは有名だったらしいです。
ただその後徐々にsharepointのように同じような機能があり、かつWebベースで見た目がきれいなグループウェアが大頭してきて、シェアが少しずつ他のグループウェアに移り変わっていったらしいです。
:::

# Dominoとは
Notes用のサーバーソフトウェアです。
Notesがクライアント側のソフトウェアで、Dominoがサーバー側のソフトウェアというイメージです。
ユーザーはNotesを使用してDominoサーバーにアクセスして、データの共有やアプリを利用できます。

# ベンダーの移り変わり
[歴史](#歴史)にも記載した通り、Notesという製品は3種類のベンダーを移り変わりしています。

1989年～1995年：ロータス・デベロップメント
1995年～2019年：IBM
2019年～現在：HCLテクノロジーズ

また、IBMがHCLに売却する少し前にリリースされた「Notes/Domino V9.0」と「Notes/Domino V10.0」は、2024年6月1日にサポートが終了しています。
V11以降はHCLに売却されてからリリースされたため、現在も継続的にサポートが行われています。

参考：[「IBM版」Notes/Dominoのサポート終了巡り混乱、企業は主体的に情報収集を](https://xtech.nikkei.com/atcl/nxt/column/18/00989/051500150/)

# サポート終了問題
2022年にHCLがV9とV10のサポートが終了する旨を発表すると、その後Notes自体のサポートが終了する、というフェイクニュースが出回ったそうです。
あくまでIBM時代の過去のバージョンが終了するだけで、HCLに売却されてからの直近のバージョンはサポートは継続されており、今後もしばらくサポートは続いていくと思われます。

参考： [脱Notesのフェイクニュースにご注意を！](https://note.com/dominolab/n/n5d7e8b74386f)

# 他の社内コミュニケーションシステムに移行する際の課題
例えばですがNotesから他のグループウェアのシステムに移行するとなっても、現在Dominoサーバーにある大量の過去データの移行が必要だったり、Domino Designerを使用してカスタムアプリケーションを作成していると、新しいシステムに移行するのはかなり複雑になります。また、そのためには移行プロジェクトを進めるためのNotesの専門知識を持つ人材も確保しておく必要があります。

# Notesの使用方法
HCLの[こちら](https://help.hcl-software.com/notes/welcome/index.html)のページにドキュメントが置かれています。

# 終わりに
社内のコミュニケーションシステムはNotesやsharepoint、Google Workspaceなど様々ありますが、導入する際はそれぞれの特徴を吟味して導入を進められたらいいですね。
Flutterのビルドでプラグインエラー

flutterのビルドで下記エラーが発生した。

>Execution failed for task ':flutter_plugin_android_lifecycle:compileReleaseJavaWithJavac'.

対処方法は下記。
# settings.gradleファイルの変更
　ファイルのpluginsセクションに次の行を追加または更新する
~~~
 id "com.android.application" version "8.3.2" apply false
~~~
# gradle-wrapper.propertiesファイルの変更
　次の内容でファイルを更新する。
~~~
 distributionUrl=https\://services.gradle.org/distributions/gradle-8.4-all.zip
~~~

上記ファイルを更新したあと、プロジェクトをクリーンして再ビルドする。

参考にした記事は下記。
https://github.com/flutter/flutter/issues/156307#issuecomment-2396404883
(25卒)新入社員がデータベースを開発してみた【個人開発】

https://github.com/GitHub30/AwesomeKV

## はじめに
サーバー管理ゼロ、世界中どこからでもミリ秒台の読み出しが可能なグローバル分散型キー・バリュー・ストア API「AwesomeKV」を個人開発しました。本記事では、その特徴、使い方、アーキテクチャ、今後のロードマップなどをご紹介します。


## 背景とコンセプト
- **サーバーレス**: インフラ管理不要で、コードだけ書いてデプロイ。  
- **Key–Value ストア**: 簡単な CRUD（生成・取得・更新・削除）操作を HTTP で完結。  
- **グローバル分散**: Cloudflare Workers KV 上に構築し、Edge キャッシュによる低レイテンシを実現。  

多くのプロジェクトで、ちょっとした設定やフラグを保存したいだけのためにフルマネージド DB を立てるのはオーバースペック。そこで、最低限の機能に絞った軽量 KV ストアを自分で作ってみました。

---

## 主な特徴
- **シンプル RESTful API**  
  - `GET /<key>` … 値を取得（存在しない場合は 404）  
  - `PUT`/`POST /<key>` … 値を保存（初回は 201、上書きは 200）  
  - `DELETE /<key>` … キーを削除（200）  
- **CORS 完全対応**  
  - 標準的な `Access-Control-Allow-*` ヘッダーを全て設定  
- **MIME タイプ自動判別**  
  - `.json` や `.png` など拡張子から IANA 登録済みのメディアタイプを自動設定  
- **グローバル低レイテンシ**  
  - Edge キャッシュを使ったリクエストはミリ秒単位  
- **サーバー管理ゼロ**  
  - Cloudflare Workers ＋ KV ネームスペースでフルマネージド  

---

## API 仕様・使い方

### JavaScript からの利用例

```js
// キーに値を登録（作成/上書き）
await fetch('https://awesomekv.dev/mynamespace/mykey', {
  method: 'PUT',
  body: 'Hello, AwesomeKV!'
});

// キーの値を取得
const res = await fetch('https://awesomekv.dev/mynamespace/mykey');
if (res.ok) {
  console.log(await res.text());  // → "Hello, AwesomeKV!"
} else {
  console.error('Key not found:', res.status);
}

// キーを削除
await fetch('https://awesomekv.dev/mynamespace/mykey', { method: 'DELETE' });
```

### Python からの利用例

```py
import requests

# 値を登録
r = requests.put('https://awesomekv.dev/mynamespace/mykey', 'Hello from Python')
print(r.status_code)  # 201

# 値を取得
r = requests.get('https://awesomekv.dev/mynamespace/mykey')
if r.status_code == 200:
    print(r.text)      # → Hello from Python
else:
    print('Not found', r.status_code)

# キーを削除
r = requests.delete('https://awesomekv.dev/mynamespace/mykey')
print(r.status_code)  # 200
```

---

## アーキテクチャ
1. **Cloudflare Worker**  
   - `worker.js` にて HTTP メソッドとパスを判定し、`env.KV.get/put/delete` を呼び出し  
   - CORS ヘッダー、MIME タイプを付与してレスポンスを返却  
2. **Workers KV**  
   - グローバル分散ストレージ  
   - 読み出しはエッジキャッシュ、書き込みはオリジン  
3. **デプロイ**  
   - [Wrangler](https://developers.cloudflare.com/workers/cli-wrangler/) を使って数秒で公開  

---

## パフォーマンスと制限
- **レイテンシ**: キャッシュヒットで 5ms 以下  
- **KV 制限**  
  - 値サイズ上限 25 MiB  
  - キー長最大 512 バイト  
  - 無料枠: 読み込み 100k/日、書き込み 1k/日（有料プランで増量可）  

---

## ユースケース
- エッジでの **設定／機能フラグ** の保存  
- CDN 経由の **静的アセット**（画像、JSON）配信  
- ユーザーごとの **セッション情報**・**プレファレンス** のキャッシュ  

---

## ロードマップ
1. マルチキー操作（Bulk GET/DELETE）  
2. 自動 TTL（有効期限）機能  
3. API 認証（API キー／JWT）  
4. Web UI ダッシュボード  
5. メトリクス・分析連携（Workers Analytics）  

---

## まとめ
「AwesomeKV」は、Cloudflare Workers KV を最大限に活かした、超シンプルかつスケーラブルな HTTP KV ストアです。  
インフラ管理を一切せずに、グローバル分散と低レイテンシを手軽に導入できるため、小規模プロジェクトからエンタープライズまで幅広く活用いただけます。  
ぜひお試しください！  

- GitHub: https://github.com/GitHub30/AwesomeKV  
- サービス: https://awesomekv.dev
C言語　何故main に戻らない？スタック上の戻り先を改変する実験 main→func1→func2

## func1戻り先のアドレスを知る

### 使用したサイト
https://godbolt.org/

### C言語ソース
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/4debc8db-e1e6-4c03-bf17-8dad8f2f4da2.png)

### アセンブリソース
左側に各命令のアドレスが表示されている
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/c0a93ea6-4336-4de8-ac0d-0ddc46fc6551.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/c4d55709-2544-4c73-bbd3-b944b7ff7efc.png)

### func1のスタックフレーム
|低アドレス  |  |
|---|---|
|・・・  |  |
|1  |mov    QWORD PTR [rbp-0x10],0x1  |
|2  |mov    QWORD PTR [rbp-0x8],0x2  |
|旧rbpの値  |push   rbpによって代入された  |
|401166  |call func1()の次の命令のアドレス  |
|・・・  |  |
|高アドレス  |  |

※上のスタック図は8バイト刻み

### スタックにfunc1の戻り先アドレスが積まれていることを確認
スタック図をみるとa[1]の16バイト先に戻り先アドレスが入っている。
この仮説を基にa[3]の値をprintfで出力してみる。
```c
void func1(){
    long a[2];
    a[0]=1;
    a[1]=2;
    printf("%lx",a[3]);
}
```
```実行結果.bash
401176
```
このアドレスは「 mov    eax,0x0」命令のアドレスと一致する。
つまりfunc1関数からは「 call   401126 <func1()>」の次のアドレスに返るということである。

## func1の戻りアドレスを別のアドレスに変更

### compiler Explorer
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/5868740b-711a-464e-bc82-f4f82b92a0b5.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/7dda6ece-dc17-47e4-9451-4c9a0a6b59ed.png)
```実行結果.bash
ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 139
Program terminated with signal: SIGSEGV
```
compiler Explorer上では安全ではないと判断されたのかエラーを吐いた。
(参考にした本では同じようなコードでも動いていたが。。。)

### ローカルgccで確認
```test.c
#include<stdio.h>

void func2();

void func1(){
    long a[2];
    a[0]=1;
    a[1]=2;
	a[4] = (long)func2;
}

void func2(){
    printf("func2");
}

int main(){
    func1();
    printf("main");
    return 0;
}
```
```コンパイルコマンド
gcc -fno-stack-protector -no-pie -O0 test.c -o test
```
```実行結果.bash
func2
```
自分の仮説ではa[3]が戻りアドレスだと思っていたが、a[4]だったようだ。
スタックフレームがどうなっているのか分からない。
詳しい方がおられましたらご教示下さると幸いです。

## 参考文献
①阿布編程　（２０２３）　『CPU眼里的C/C++』　清華大学出版社.
WindowsでCursorにMCPを設定する

# WSLで慣れてるとハマる？CursorのMCP設定でつまづいた話

普段、Windowsで開発していると、ついWSL上で作業するのが当たり前になってしまいますよね。僕もその一人で、今回もWSL上でMCPサーバを立ち上げて「動いた動いた」と安心していました。

ところが、CursorエディタでMCPの設定をしたところ、なぜかエラーが発生。MCPサーバ自体はWSLで普通に動いてるのに、Cursor側からうまく接続できなかったんです。

いろいろ試してみた結果、**MCPサーバをWindows側で立ち上げ直したら、すんなり動作**。どうやら、CursorがMCPを起動・接続する際には、ホスト側の環境（つまりWindows側）に依存する部分があるようです。

WSLでの作業に慣れている人ほど気づきにくいポイントかもしれません。同じようなことでハマった人の参考になれば幸いです！

### 前提
* MCPサーバは[Model Context Protocol](https://github.com/modelcontextprotocol/servers)のサーバソースを使う
* サーバはnpxを使う
* ローカルでPostgreSQLが立ち上がっている
* Cursorバージョンは0.49

## 導入手順
### MCPサーバ設定
Windows側のコマンドプロンプトで、
```
git clone git@github.com:modelcontextprotocol/servers.git
npm install
npm run build
```
ちなみに、ここではビルドまでしておくだけでよく（サーバを立ち上げっぱなしにするのではなく）Cursorが都度立ち上げて使う仕組みらしい

### Cursor設定
Cursor上でCursor Settings→MCPから設定しても良いし、プロジェクトフォルダ配下に.cursor/mcp.jsonを作成しても良い
```json
{
    "mcpServers": {
        "postgres": {
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-postgres",
                "postgresql://localhost:5432/postgres"
            ]
        }
    }
}
```

### 動作確認
青ランプになればOK
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201287/3cdd825e-1704-4496-9488-9d07899a149c.png)

エラーの場合はOutput→Cursor MCPにログが出る
Agentプロンプトでテーブルのことについて聞けば、自動的にMCPを使って、PostgreSQLに対して実際にクエリを発行してテーブルの中身を見たり、列の構成を確認してソースコード開発に反映したりしてくれる

## Tavily
Linuxでは一時的にインライン環境変数を指定してMCPを起動しますが、Windowsでは以下のようにして動きました
```json
{
    "mcpServers": {
        "TAV2": {
            "command": "cmd",
            "args": [
                "/C",
                "set TAVILY_API_KEY=tvly-xxxxxxxxxxxxxxx && npx -y tavily-mcp@0.1.3"
            ],
            "type": "stdio"
        }
    }
}
```
[js]名無しのn フェッチ入門講座

こんにちは。名無しのnです。
今日は名無しのnのフェッチ入門講座を開いていきます（一部ai)
フェッチAPIを使用すると、JavaScriptで簡単にネットワーク通信が可能です。例えば、ウェブからデータを取得したり、サーバーに情報を送信したりするのに役立ちます。フェッチAPIはPromiseベースで動作し、非同期処理を簡単に実現できます。
この講座では、フェッチAPIの基本的な使い方から応用的なテクニックまでを紹介します。実際の例を使って理解を深めていきましょう。
コード
以下は、基本的なフェッチAPIの使い方の例です。
## 基本的なフェッチの使い方
```f-g.js
// URLからデータを取得する基本的な例
fetch('uri')
  .then(response => {
    if (!response.ok) {
      throw new Error('ネットワークエラー: ' + response.status);
    }
    return response.json(); // レスポンスをJSONとして取得
  })
  .then(data => {
    console.log(data); // 取得したデータを表示
  })
  .catch(error => {
    console.error('エラーが発生しました:', error);
  });
  ```
POSTリクエストの例
  ``` f-p.js
// サーバーにデータを送信するPOSTリクエスト
fetch('', {
  method: 'POST', // リクエストの種類
  headers: {
    'Content-Type': 'application/json' // JSONデータを送信する
  },
  body: JSON.stringify({ // 送信するデータ
    title: 'フェッチAPI入門',
    body: 'この記事はフェッチAPIの使い方を学ぶための例です。',
    userId: 1
  })
})
  .then(response => {
    if (!response.ok) {
      throw new Error('ネットワークエラー: ' + response.status);
    }
    return response.json(); // レスポンスをJSONとして取得
  })
  .then(data => {
    console.log('作成されたデータ:', data);
  })
  .catch(error => {
    console.error('エラーが発生しました:', error);
  });

  
 ```
 ## 注意CORS
 フェッチAPIを使用する際に注意が必要な点として、CORS（Cross-Origin Resource Sharing）制限があります。CORSは、ブラウザが異なるドメイン間でのリクエストを制限する仕組みです。この制限により、アクセスしようとするリソースがCORSを許可していない場合、フェッチAPIを使用してデータを取得できないことがあります。

たとえば、次のようなエラーが表示されることがあります：
``` Console
Access to fetch at 'https://example.com/api' from origin 'https://yourdomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
```
この問題を解決するには、以下のような方法を検討できます：

サーバー側でCORSを許可する設定を追加する。

プロキシサーバーを利用して、CORS制限を回避する。

必要に応じてmode: 'no-cors'オプションを使用する（ただし制限された操作しかできません）。

CORSの制限について理解し、適切な対応を行うことで、安全かつ効率的にフェッチAPIを活用することができます！
これについては,べつのきじで詳しく説明します！
## まとめ
まーフェッチはデータを送信＆getするものです。
ご意見や質問があればコメント欄で教えてください！
また次回！
【Docker】DockerFileをAmazonLinux2からAmazonLinux2023に更新したら、コンテナ内から出力されるログが文字化けしたため、原因追求と対策を行った

## はじめに
現場にて、運用上バッチをデプロイする時に使われていたDockerFile(が記入されている.sh)がありました。
そのDockerFileを更新する際、なかなか解消できない問題が発生したため、知識共有として記事に残そうと思います。

## 背景
2025年でAmazonLinux2(以下AL2)がサポート終了するため、DockerFileもAmazonLinux2023(以下AL2023)に変更する対応を行った。

## 変更したらどうなったか？
デプロイしたバッチからはログを出力していたが、AL2の時は正常だったログが、AL2023に更新すると文字化けが発生していた。

## どんな処理だったか？
```diff_docker:旧処理(一部省略).sh
cat << _EOF ${_DIR_}/DockerFile
- FROM amazonlinux:2
+ FROM amazonlinux:latest
ADD ${NAME}.tar.gz /opt/
ENV_NAME=en_US.UTF-8
WORKDIR /opt/${NAME}
RUN yum install -y java-11-amazon-corretto
_EOF
```

:::note info
amazonlinux:latestと記入すれば最新のDockerイメージを取得するようになります。
記載時点ではAL2023が最新です。
:::

## 原因は？
AL2とAL2023のデフォルトでインストールされているパッケージに差があった。

## どんな差があったか？
・AL2ではglibc-langpack-enが**デフォルトでインストールされている**ため、en_US.UTF-8に対応していた。
・AL2023はglibc-langpack-enが**デフォルトでインストールされていない**ため、en_US.UTF-8に対応していなかった。

:::note info
Q:glibc-langpack-enとは？
A:Linux環境で英語を使えるようにするためのロケールパッケージです。
:::

## どう対応したか？
1. ロケール設定の追加を行った
2. ロケールパッケージ(glibc-langpack-en)のインストールを行った

上記2点を対応したことにより、無事文字化けが解消された。
```diff_docker:新処理(一部省略).sh
cat << _EOF ${_DIR_}/DockerFile
FROM amazonlinux:latest
ADD ${NAME}.tar.gz /opt/
ENV_NAME=en_US.UTF-8
+ ENV_LANGUAGE=en.US:en
+ ENV_LC_ALL=en.US.UTF-8
WORKDIR /opt/${NAME}
RUN yum install -y java-11-amazon-corretto ¥
+ && yum install -y glibc-langpack-en
_EOF
```

:::note info

Q:ロケール設定とは？
A:システムのデフォルト言語や文字コード、タイムゾーンなどを管理する、言うなればシステムの地域設定のことを示しています。

:::

## 終わりに
まさかインストールパッケージがALバージョンで異なるとは思いませんでした。
EC2上でロケール関連の設定、パッケージインストールはとりあえず実施しておくというケースは多いかと思います。
ただDockerFile側は盲点でした。
この記事が誰かの役に立てば幸いです！
Adaが教えてくれたこと：設計と信頼の再定義



> _"信頼とは、意図と構造が一致しているという一点に宿る。"_  

全30本に渡って見てきたAda／SPARKの思想と実装。  
最後に改めて問いたい。  
**「私たちは、何をもってコードを信頼していたのか？」**

Adaは、設計とは何かを定義し直す。  
それは、コードの速さでも、柔軟さでも、見た目でもなく、  
**「その構造が、どこまで未来を約束できるか」という一点に集約される。**

---

## 信頼とは、バグが起きなかった実績ではない

多くの現場では、こう語られる：

- バグが出なかったから安全  
- テストが通っているから安心  
- たくさんのユーザーが使っているから信頼できる

しかしAdaは、もっと冷徹にこう問いかける：

> _「それは“偶然動いた”だけではないのか？」_

---

## 信頼性の新定義：予測、制約、検証、証明

Ada／SPARKが示した信頼性の条件は、こうである：

- **予測可能であること**（非決定性の排除）  
- **設計意図が構文で表現されていること**（契約）  
- **機械的に検証できること**（静的解析）  
- **証明可能であること**（数学的保証）

これらが揃って初めて、「これは信頼できる設計だ」と言える。

---

## 開発者に問われるのは、「何を選ぶか」ではなく、「何を許さないか」

Adaを使うことは、あらゆる選択肢を狭めることであり、  
それは裏を返せば、**曖昧さと不安定さを“許さない姿勢”の表明**である。

この構造を選んだ時、私たちは「自由」を捨てたのではない。  
**“守るべき信頼”のために、必要のない自由を放棄したのだ。**

---

## 曖昧を語らず、正しさを語るコードへ

Adaのコードは、どれだけ書いても饒舌にならない。  
**ただそこに在り、構造で語る。**  
それは設計者の思想の断面であり、責任の形式知であり、未来への構造的遺言だ。

---

## 結語：構文に宿る信頼、それがAdaという思想

この30本を通じて見えてきたのは、  
Adaという言語が単なるツールではなく、  
**設計者の“信頼されたいという意思”を受け止める器**であったという事実である。

私たちは、自由に書くこともできる。  
しかしその先に「正しく設計された構造」がないなら、信頼は生まれない。

Adaは言う。

> _"書けるコードより、信じられる構造を残せ。"_
静寂の中の正しさ：テストが要らなくなる日



> _"沈黙はエラーがないことではない。証明された構造が、声を上げる必要を失ったのだ。"_  

テスト駆動開発、テスト自動化、CI/CD——  
私たちは数十年にわたり、「壊れていないことを確認する」ための儀式を続けてきた。

だが、SPARK Adaはそこに**まったく別の道を提示する**。  
**「テストしなくても正しさが保証される構造」**という、静かで強固な開発パラダイムだ。

---

## テストとは「信じるしかない」行為である

テストとは本質的にサンプリングである。  
ある入力に対して期待される出力が出ることを確認するが、**それ以外は保証されない**。

SPARKはその発想を根底から覆す。  
**すべての入力に対して、すべての仕様が守られることを証明する**。

---

## 正しさが証明できる関数の例

```ada
function Max (A, B : Integer) return Integer
  with
    Post => Max'Result = (if A >= B then A else B);
```

このPost条件は、「Maxは必ず2値のうち大きい方を返す」という**意味論的仕様**である。  
GNATproveがこれを通過するということは、**Maxは“設計通り”であることが数学的に確定している**という意味になる。

---

## テストは減り、設計が増える

テストが不要になるというのは、「確認しないでいい」ということではない。  
それはむしろ、**仕様と制約を構文として記述し、すべてを設計段階で検証する**という意味である。

テストを書かないのではない。  
**テストの代わりに仕様を書く。**  
それがSPARKのスタイルだ。

---

## テストから検証へ：静的保証の開発体験

- テスト：動かしてみる  
- レビュー：人が読む  
- デバッグ：バグを探す  

→ SPARK：**仕様を書く → 検証ツールが証明する → バグが存在できない**

この静かな開発体験は、**“壊れないことを証明する構造を設計する”という新しい美学**である。

---

## 結語：沈黙は、正しさが語られる世界

動かしてみなくてもよい。  
試してみなくてもよい。  
テストを書かなくてもよい。

それは怠惰ではなく、**証明によって沈黙を成立させた構造が、語る必要を失ったから**である。

> _"コードが沈黙しているのは、語るべき矛盾が存在しないからだ。"_
機械に設計を語らせる：形式手法時代の人間とコードの関係



> _"コードが設計者の意図を語れるなら、対話すべきは人間ではなく構造である。"_  

かつて、コードは人間が読めるものではなかった。  
その後、プログラミング言語は読み書きの対象となり、**「わかりやすさ」や「表現力」が求められるようになった**。

しかしSPARK Adaが示すのは、その次のフェーズだ。  
**コードが自ら設計意図を“証明し、保証し、主張する”世界**である。

本稿では、形式手法時代における「人間とコードの新たな関係性」について掘り下げる。

---

## 設計意図をコードに埋め込むという転換

```ada
function Transfer (From, To : in out Account; Amount : Positive)
  with
    Pre  => From.Balance >= Amount,
    Post => From.Balance = From'Old.Balance - Amount and
            To.Balance   = To'Old.Balance + Amount;
```

これは単なる“関数”ではない。**設計文書であり、制約の宣言であり、証明可能な設計仕様**である。

つまり、**コードが仕様を語り、検証者に説明責任を果たす**存在となっている。

---

## 会話の相手が人間ではなくツールになる世界

SPARKでは、設計レビューの対象が**人間の目視チェック**ではなく、  
**静的検証ツール（GNATprove）との対話**となる。

- 仕様通りか？  
- 契約は破られていないか？  
- 未定義な振る舞いがないか？  

これらを人間が推測する必要はなく、**機械が証明し、コードが語る**。

---

## ドキュメントが不要になる構造的誠実さ

SPARKにおいて、仕様書はコードに吸収される。  
Pre/Post、型制約、不変条件など、**設計情報が構文そのものに宿る**ためだ。

結果として、文書とコードが乖離することがなくなる。  
**“設計者が何を意図したか”がコード自身に語らせることができる。**

---

## 人間の責任が「書くこと」から「意図を設計すること」へ

従来の開発では「正しく書く」ことが主な責任だった。  
SPARKでは、「**何が正しいのかを定義すること**」が責任となる。

これは、**プログラマの役割が実装者から“制約を設計する存在”へ変化する**ことを意味している。

---

## 結語：設計とは、人が語るのではなく、構造が語るものへ

機械は嘘をつかない。だが、**曖昧な構造は真実を語らない**。  
SPARKは、コードを「沈黙する命令列」から、**設計意図を語る構造体**へと進化させる。

人間の仕事は、仕様を紙に書くことではない。  
**それをコードに語らせるための設計構文を選ぶこと**なのだ。

> _"人が語る設計には限界がある。構造が語る設計こそが、次の開発の礎である。"_
安全な状態遷移を制御する：有限オートマトンとAdaの親和性



> _"混乱は状態管理の失敗から始まる。秩序は明示された遷移に宿る。"_  

あらゆるリアルタイム制御、UIロジック、プロトコル実装において、  
**状態遷移の正しさはシステムの安定性を左右する。**

Adaは、その設計哲学の中に「状態を型で管理し、遷移を明示せよ」という強い意志を持っている。  
これは、**有限オートマトン（Finite State Machine）と驚くほど相性が良い構造**である。

---

## 状態を“変数”でなく“型”で定義する

```ada
type Mode is (Idle, Starting, Running, Stopping, Error);
Current_Mode : Mode := Idle;
```

このように、状態は自由な文字列や数値ではなく、**型として限定された集合**として定義される。  
これにより、「ありえない状態」は**コンパイル時点で排除**される。

---

## 遷移は明示的に記述する。制御不能な分岐を残さない

```ada
case Current_Mode is
   when Idle =>
      if Start_Requested then
         Current_Mode := Starting;
      end if;

   when Starting =>
      if Init_Complete then
         Current_Mode := Running;
      end if;

   when others =>
      Current_Mode := Error;
end case;
```

このように、すべての遷移を明示的に書くことで、**無定義の分岐が生まれない**構造がつくられる。  
**case文は静的解析でもっとも効果的な状態制御手段**であり、Adaの構文と極めて相性が良い。

---

## 状態と責任を分離するモジュール設計

状態遷移は、以下のような構造で分離・管理されるべきである：

- `type State`：全状態を明示的に定義  
- `procedure Transition`：状態間の遷移ロジック  
- `function Is_Valid_Transition`：状態の検査関数  
- `package Controller`：これらをまとめる構造単位

Adaの `package` 構文により、これらを**責務ごとに整理された構造体として再利用可能に設計**できる。

---

## 状態爆発を防ぐ：静的に予測可能な分岐数

状態が型で管理されていることにより、状態数と遷移数は**コード上に明確に現れる**。  
これは、状態遷移表の検証や可視化にも大きく寄与し、  
**テストではなく、設計段階で正しさを検証可能にする**。

---

## 結語：状態を設計せずに制御はできない

Adaは、状態管理を**構造化し、明示し、検証可能にする**言語である。  
有限オートマトンと親和性が高い理由は、**状態が“設計の単位”として尊重されているから**だ。

> _"正しい状態にいること。それは、正しい遷移を設計できたという唯一の証明である。"_
エラー処理ではなく失敗設計：例外の哲学的再考



> _"例外とは、逃げではない。設計に取り込めなかった現実との向き合い方だ。"_  

一般的なプログラミングにおける例外処理は、**「何か起きたら考える」ための後始末**として機能する。  
だがAdaにおける例外処理は、それとはまったく異なる位置づけを持っている。

**エラーは“処理”されるべきではない。構造の中で“発生し得ない”ように設計されるべきである。**  
その上で、現実の“設計が及ばない不確実性”にだけ、例外が許される。

---

## Adaの基本設計思想：「あり得ないことは書かせない」

Adaでは、設計段階で「発生しうる異常」を構文的に排除することが第一原則である。  
たとえば、ゼロ割は以下のように**契約（Pre）で除外**される。

```ada
function Divide (A, B : Integer) return Integer
  with Pre => B /= 0;
```

この設計において、例外は**設計漏れの代償**ではなく、**現実との折り合い**である。

---

## 例外とは“設計に入れられなかった現象”への礼節

例えば、外部ファイルが存在しない、通信が遮断される、センサが沈黙する——  
これらは**プログラム内部で完結できない不確定性**である。

Adaはこれらに対し、明示的な例外ハンドリングを要求する。

```ada
begin
   Open_File (Config);
exception
   when Name_Error =>
      Put_Line("設定ファイルが存在しません。");
end;
```

この例外処理は「想定外の事態」ではなく、**“設計内で許容した”唯一の逸脱**である。

---

## SPARKとの断絶：例外なき世界の哲学

SPARKでは、例外は**禁止されている**。  
これは、設計者が**あらゆる不確実性を排除した“閉じた世界”を構築すること**を強制されるということ。

例外がないというのは、「ミスが起きない」ことではない。  
**ミスが起きる余地そのものを構造から削ぎ落とす設計**を意味する。

---

## エラー処理から失敗設計へ

現代の多くのプログラムは、try-catchにすべてを託してしまう。  
しかし、それは「動くように見えるだけの不安定な構造」でしかない。

Adaはそこに対して、明確な設計上の態度を示す。  
**設計で避けられる失敗は、絶対に構文で潰せ。**  
それでも起き得ることに対してのみ、静かに例外を許せ。

---

## 結語：例外は、設計が見落とした現実の境界線である

Adaは、例外を「処理」ではなく「構造の外」に位置づける。  
それは、**設計者の“想定と責任の限界”を明示する枠組み**なのだ。

> _"例外は設計者の責任ではない。だが、例外の存在を許す設計は、誠実でなければならない。"_
正しさをデザインする：Adaにおける美的設計原則



> _"美しい設計とは、正しさが見えること。"_  

プログラミングにおける「美しさ」とは何だろうか？  
簡潔さ、柔軟さ、パフォーマンス、スタイル——どれも間違ってはいない。  
しかしAdaは、それらとは違う基準で語る。**正しさを、構造としてデザインする美学**である。

この言語が持つ設計原則は、単なる機能の提供ではなく、**設計行為そのものを美術化する哲学**だ。

---

## 明示性：見えない設計は設計ではない

Adaは「書かなくても済む」ことを良しとしない。  
すべてを**明示的に書く**ことを通して、**意図の完全な可視化**を実現する。

- `type` を定義せよ  
- `range` を指定せよ  
- `Pre/Post` で契約を明示せよ

これは単なる構文的厳格さではない。**意図が読み取れるコードこそが、美しい**という思想の表れである。

---

## 対称性と整合性：コードは建築である

Adaの設計は、どの階層を見ても同じ構造美が宿っている：

- `package` と `package body` の物理的分離  
- `spec`（仕様）と `impl`（実装）の明快な対応  
- 宣言→契約→実装という線形的な設計フロー

**建築物がその構造で意味を語るように、Adaのコードも構文で正しさを訴える。**

---

## 意図と責任を持たせる：命名と型の詩学

Adaに無名関数や型推論はない。  
その代わり、すべての構成要素に**意味ある名前と文脈が与えられる**。

```ada
type Altitude_Meters is range 0 .. 20000;
```

ここには、「整数型」では表現できない**物理的制約と意味論の注入**がある。  
このような記述が、**設計者の誠実さと構造的想像力を伝える**。

---

## 変更耐性：未来を意識した静的美

良い設計とは、**変更されたときに壊れない設計**である。  
Adaではこれが、以下のような要素で実現されている：

- 明示されたインターフェース（`package spec`）  
- 型レベルで制限されたデータ表現  
- “ありえない使い方”を排除する構文チェック

これらは、**可読性を越えた、未来への配慮**としての美しさだ。

---

## 結語：設計とは思想の彫刻である

Adaは、開発を“作業”ではなく、“表現”に変える。  
書かれたコードは単なる命令ではなく、**構造的な哲学の形跡**として残る。

美しさとは、曖昧さの排除であり、意図の明示であり、変更に耐える構造である。  
それを設計の根幹に据えた言語が、Adaなのだ。

> _"構文が語る設計、それは思考の建築物である。"_
Ada 2022の革新：今なぜこの言語に注目すべきか



> _"進化とは、理想を手放さずに現代性を取り入れることだ。"_  

Adaは「古い」「堅い」「保守的」な言語だと語られることが多い。  
しかし、その最新仕様である **Ada 2022** は、  
この言語が持つ堅牢性を保ちながらも、**現代的なニーズに静かに応えてきた**。

本稿では、Ada 2022がもたらした革新と、  
なぜ今改めてこの言語が“選ばれるに値するか”を考察する。

---

## 静的保証 × 現代的表現：パラダイムの交差点

Ada 2022 は、従来の「正しさ至上主義」を崩すことなく、以下のような新要素を導入した：

- **合同演算子の導入**（`xor`, `and then`, `or else` などの簡潔な表現）  
- **式関数の導入**（関数を簡潔に表現しつつも明示的に設計意図を含められる）  
- **より強化された合成性**（宣言の簡略化とパッケージ構造の洗練）

これは単なる“糖衣構文”ではない。  
**「設計を破らずに記述性を向上させる」文法的哲学の体現**である。

---

## 表現の自由と意図の明示を両立する

```ada
function Square (X : Integer) return Integer is (X * X);
```

このような「式ベース関数」の導入により、可読性が向上。  
同時に、型や副作用の定義が依然として明確であり、**静的解析との相性を壊さない**。

これは、**速さと安全性の間にある溝を埋める設計的折衷**でもある。

---

## 並行性のさらなる強化とリアルタイム制御

- 非同期タスクに対する制御構文の強化  
- 優先順位継承やタスク識別の改善  
- `delay until` の解像度向上とイベント駆動との親和性

これにより、**ミッションクリティカルかつタイミングに厳しい環境**でも、より高精度な制御が可能になった。

---

## Adaが進化するという静かな驚き

他の言語が“流行”とともに短い周期で変化していくなか、  
Adaの進化は**破壊的変更を一切伴わずに行われる**。

Ada 2022は、40年近い設計哲学を裏切ることなく、  
**その思想をより「選ばれやすい形」に鍛え上げた**のである。

---

## 結語：今、最も過小評価されている近代言語

Ada 2022は、決して過去にしがみついた言語ではない。  
むしろ、**未来の開発に耐えうる“構文としての思想”を洗練させた存在**である。

- 明示的であること  
- 正しさを前提に設計されていること  
- 変化を受け入れながらも、核の哲学を崩さないこと

今、静かにAdaを選ぶ理由は、かつてよりもずっと多い。

> _"変わらない理念に、変わる技術が追いついた。それがAda 2022である。"_
デバッグ不要の世界：予測可能性が支える開発体験



> _"バグを直すのではなく、バグが生まれない構造を選べ。"_  

デバッグとは、誤りを“後から”発見する営みである。  
だがその構造自体が、**本質的に非効率で不確実なもの**であるとしたらどうだろう？

Ada、そしてSPARKが提供するのは、**「デバッグ不要の構造」そのもの**である。  
予測可能で証明可能な設計のもと、バグを未然に排除する開発体験を語る。

---

## なぜデバッグが必要になるのか？

- 実装が設計意図とズレている  
- 型が曖昧で想定外のデータが入る  
- 境界条件が設計されていない  
- 並行処理の順序が予測できない

これらすべては、**構文上・構造上で制御できない言語仕様**から来ている。

---

## SPARKが描く「バグが生まれない設計」

```ada
procedure Update_Score (Current : in out Integer)
  with
    Pre  => Current < 100,
    Post => Current = Current'Old + 1;
```

この構造において、100以上の値が入っていた場合、  
**GNATproveが“バグになる可能性”をコードを書いた時点で検出する**。

デバッグではなく、**証明によってエラーを封じる開発体験**が実現する。

---

## テストの限界と「信頼性のスケーリング」

テストは「観測された範囲」しか保証しない。  
だが、現実のシステムは**観測しきれない分岐と状態**を常に抱えている。

SPARKは、それら全てに対して、**数学的に仕様を証明できる領域を提供**する。  
これによって、「たまたま通ったテスト」は**「常に正しい仕様」へと昇華される**。

---

## デバッグが不要になることの本当の意味

それは「ラクができる」ということではない。  
**最初に設計と仕様を構文に刻むことで、後戻りを不要にする**ということである。

設計コストは上がる。だがその分、**修正・障害対応・事故調査といった“開発の闇”をゼロに近づける**。

---

## 結語：デバッグは文化、証明は構造

デバッグとは、開発文化の一部であり、「仕方のないもの」とされてきた。  
しかしSPARKは、その前提を構造ごと否定する。

「バグが生まれない」ではなく、**「バグが生まれ得ない」**。  
その設計哲学が開発体験を根本から変える。

> _"直す前に、起こさせない。それが設計であり、証明の力だ。"_
Adaの教育的価値：大学教育と安全性の導入



> _"初学者にこそ、正しさの重みを体験させよ。"_  

プログラミング教育の初期段階では、しばしば「簡単な言語」や「即時反映型の動的言語」が選ばれる。  
だが、それは本当に学習者にとって“正しい入口”なのだろうか？

**Adaは、初学者にこそ必要な“設計と誠実さの重み”を体験させる言語**である。  
それは、エラーを許容せず、設計意図を強制し、型の意味を考えさせる構造そのものが教育だからだ。

---

## 曖昧さを許さない構文＝設計の構造を学ぶ第一歩

```ada
procedure Greet (Name : String) is
begin
   Put_Line ("Hello, " & Name);
end Greet;
```

Adaでは、あらゆる要素が**明示されなければならない**。  
暗黙的な型推論もなく、`begin` と `end` で範囲を明示しなければならない。

これは「面倒」なのではなく、**構造の感覚を養う教育的意図**に満ちている。

---

## 型システムによる誤解の早期排除

```ada
subtype Age is Integer range 0 .. 120;
```

このように「意味を持った型」を作ることで、  
**型とは“値の制限”であり、“文脈の表明”であること**を教えることができる。

初学者は、整数と年齢の違いを明示的に学ぶことになる。  
これは**抽象化と意味づけを学ぶ極めて有効な手段**である。

---

## “動くこと”より、“壊れないこと”の美学を知る

多くの教育では、「まず動かしてみよう」という姿勢が推奨される。  
それは悪くないが、Adaは**「まず設計を考えよ。動く前に壊れない構造を作れ」**と語る。

これは、**未来のシステム設計者に必要な精神的骨格**を育てる。

---

## SPARKとの接続：形式手法の導入点としての価値

形式手法は難解と思われがちだが、  
SPARKはその**入口を“構文”にしてしまうことで、学習の敷居を下げる**。

学生は自然とPre/Post、Invariantといった概念を知る。  
それは将来の安全系設計者、証明技術者の基礎となる。

---

## 結語：早期に正しさの「構造」を刷り込む

初学者にとってのAdaは、自由な表現手段ではなく、  
**「制限された構造の中で、正しく設計する力」を養う道具**である。

この訓練が、設計・品質・再利用・再検証に強い人材を生む。

> _"正しさを教えるなら、構文にそれを語らせよ。Adaはその教育装置である。"_
SPARKで証明される“ゼロバグ設計”



> _"理想は夢ではない。構造がそれを保証するならば。"_  

バグは避けられない。  
そう信じてきた開発文化のなかで、「ゼロバグ」を掲げることは理想主義に見える。  
だがSPARKは、それを**理論と構造によって実現可能な目標**へと変える。

“ゼロバグ”とは、**全入力に対して、すべての挙動が保証された状態**であり、  
SPARKはそのための言語設計と検証基盤を提供する。

---

## バグの起源はどこか

ほとんどのバグは、「あり得ないと思っていた条件が起きた」ときに現れる。  
つまり、**設計者の想定の漏れ＝仕様と実装の乖離**に他ならない。

SPARKは、この乖離を**構文の段階で潰す**。

---

## コードが「証明対象」になる世界

```ada
function Subtract (A, B : Integer) return Integer
  with
    Pre  => A >= B,
    Post => Subtract'Result = A - B;
```

この関数は、「BがAを超えない」ことを前提とし、  
その結果が正しいことを**数学的に証明可能**とする。

GNATproveは、このコードを**テストではなく証明の対象として扱う**。  
それにより、「例外が起きない」ではなく「仕様を破らない」ことを保証する。

---

## テスト駆動ではなく、証明駆動の設計へ

テストは「反証」でしかない。  
すべてのバグをテストで検出することは不可能だ。  
一方でSPARKでは、「こうなるべき」という設計仕様を記述し、それが**破られないことを証明**する。

これはテストとは別の次元——**ロジックの厳密性という世界の構築**である。

---

## ゼロバグを可能にする設計制約

SPARKでは以下が強制される：

- 副作用のない純粋関数設計  
- すべての変数・ループに対する不変条件の記述  
- 全パスの終了保証（例外回避）

このような制約の中で書かれたコードは、**“書ける範囲”自体が安全であることを意味する**。

---

## 結語：理想ではなく、前提としてのゼロバグ

「バグはあって当然」ではなく、  
**「証明されていない設計はリリースできない」**という価値観。

SPARKが描くのは、**ソフトウェアが自己証明できる世界**であり、  
そこにはゼロバグが「目指すもの」ではなく「最低条件」として存在する。

> _"正しく書ける範囲でしか書かせない——それがSPARKという設計の哲学だ。"_
なぜAdaは流行らないのか：言語と文化の逆説



> _"価値があることと、選ばれることは、決してイコールではない。"_  

Adaは正しい。論理的で、予測可能で、安全で、構造的で、強固だ。  
だが現実には、多くの現場で「選ばれない」。

**なぜ、これほどまでに“設計された言語”が、流行らないのか？**  
その理由は、単なる文法の難解さではなく、**文化と構造に潜む“選択のパラドックス”**にある。

---

## 市場が求めるのは「速く作れる」ことである

- Ada：厳密な型指定、Pre/Postの明示、モジュール分離、静的解析の導入  
- 他言語：動的型、インタプリタ実行、柔軟な拡張

この対比において、Adaは「初速の遅さ」を常に抱える。  
結果として、**PoCやスタートアップ的開発と相性が悪い**。

**「早く動かせること」＞「正しく動くこと」**という価値観が、普及の壁を作っている。

---

## 学習コストと開発文化のミスマッチ

Adaの学習には明確な構文理解と形式的思考が要求される。  
これは、近年の「とりあえず動かす文化」と**根本的に噛み合わない**。

- JavaScript：直感と柔軟性  
- Python：自然言語的な記述  
- Ada：型、構文、契約、意図、証明

この隔たりは、**流行る言語に求められる“軽さ”とは真逆**である。

---

## コンパイラが厳しすぎる問題

Adaのコンパイラは、**“誤解”を一切許容しない**。  
些細な曖昧さや不明瞭な構文は、容赦なく拒否される。

これは教育・入門・試行錯誤フェーズにおいて、**開発者の“意欲の折れ”につながる**。

逆に、**ミスに寛容な言語ほど、ユーザーは受け入れやすい。**

---

## 成功事例が「派手でない」現実

Adaは航空・鉄道・医療といった分野で確かに使われている。  
だが、**これらは“技術的にカッコいい”とは語られにくい**。

- Web開発のような爆速・表現的な楽しさ  
- AI/MLのような注目領域でのインパクト

これらが少ないことも、言語としての「物語性」を欠く要因となっている。

---

## 結語：流行とは、合理性の上に立たない

Adaは、**正しすぎた**。  
現代が求めたのは、「最適な設計」ではなく、「速さ・柔軟さ・軽さ」だった。

だがそれでもなお、Adaが存在し続けていること。  
そして、安全が最優先される領域では今も最適解であること。

その事実こそが、この言語の**静かな正しさ**を証明している。

> _"時代に選ばれなかったことは、間違っていたことの証明にはならない。"_
コンパイル時の契約違反：検証と失敗の美学



> _"失敗を美しくする。それが設計の責任だ。"_  

バグを「実行時に捕まえればよい」と考える設計では、**誤りはいつか現実となる。**  
Adaは、その発想を根底から否定する。**失敗は“動く前に”露呈させるべきだ。**

そして、SPARK Adaが体現するのは、**失敗を構文として設計に織り込む美学**である。

---

## 失敗を「予測」ではなく「前提」として扱う

たとえば、次のコードを見てみよう。

```ada
function Safe_Square (X : Integer) return Integer
  with
    Pre  => X <= 46340;
```

これは、「46340を超えるとオーバーフローする可能性がある」ことを、**事前に宣言している**。  
これに違反するコードは、**GNATproveがコンパイル時に契約違反として拒否する**。

---

## コンパイルとは検証の第一関門である

従来の言語では、コンパイラは構文と型しか見ない。  
Ada／SPARKでは、**意図・制約・関係性までもがコンパイル時に検証対象**となる。

つまり、**正しくない設計は、書いた時点で“止められる”世界**がそこにある。

---

## “失敗する”ことを恐れない——設計における覚悟

SPARKにおける契約は、「満たされているかもしれない」ではなく、  
**「満たされていることを証明できなければならない」**という世界観。

この厳しさが、設計者に**「意図を記述する責任」**を負わせる。

---

## 実行前の拒絶＝設計の透明性を守る構造

```ada
function Divide (A, B : Integer) return Integer
  with Pre => B /= 0;
```

このような関数が存在する場合、`Divide(X, 0)` は**そもそも成立しないコード**となる。

これは、エラーハンドリングではなく、**設計ルールの静的強制**であり、  
「後で直す」のではなく、**「最初に間違えられないようにする」**という思想である。

---

## 結語：失敗が“設計の余白”でなくなった世界

Ada／SPARKが示すのは、「ミスをしてはいけない」世界ではない。  
むしろ、「ミスが起きる余地を、構文の段階で潰す」という**設計による救済**の哲学である。

**失敗は隠さずに晒し、止められるべきである。**  
それを“設計としての構文”で実現する——その強さが、Adaの美学だ。

> _"止まるコードは、未来の破綻を防ぐ設計者の意思である。"_
実用Ada：組込み現場での導入事例と設計パターン



> _"理論は強い。しかし、現場で生き残るのは“実装できる設計”だ。"_  

Adaは形式手法に支えられた理論的に堅牢な言語として知られている。  
だが、**その思想は現実の産業領域でも確実に活かされている**。

本記事では、実際の組込み分野におけるAdaの導入例と、そこで機能している設計パターンを解説する。

---

## 航空：Fly-by-Wireシステムへの採用

航空機の自動制御系（Fly-by-Wire）では、**リアルタイム性と高信頼性**が絶対条件となる。  
Adaは以下の点で採用されている：

- 時間制御（`delay until`）による精密なスケジューリング  
- `task`／`protected object` による予測可能な並行処理  
- `Pre/Post`条件による契約設計

**エアバスの制御コードにはAdaが使用されている**ことが象徴的だ。

---

## 鉄道：信号・制御システムの中枢

日本を含む欧州の鉄道インフラにおいても、Adaは信号装置・連動装置に活用されている。

- システム状態を正確に表現する列挙型  
- セーフティクリティカルな範囲型（`range`）  
- `package`によるモジュール単位の分離と再検証

**乗客の命を預かるロジック**が、Adaによって設計されているという事実は、設計者にとって重い意味を持つ。

---

## 医療機器：意図が仕様となる世界

医療機器に求められるのは「意図しない動作をしない」こと。  
SPARK Adaを利用することで、開発企業は**ソースコードに証明可能な仕様**を埋め込むことが可能となっている。

- ゼロ割などの致命的例外を構文レベルで排除  
- 設計文書を必要とせず、コードそのものを提出可能なエビデンスに

**FDA（米国食品医薬品局）でもAda/SPARKベースの開発は承認対象となっている**。

---

## 実践的設計パターン

- **契約付き抽象化**：Pre/Post + Genericでの抽象API化  
- **状態機械モデル**：明示的enumとcase文によるFSM実装  
- **安全な再初期化**：`Reset`手続きに状態無矛盾性の保証を付与  
- **分離された構成単位**：`package`と`body`で変更耐性を高める

これらは**“コンパイル時検証が通る構造”であると同時に、“設計者の意図を守る構造”**でもある。

---

## 結語：理論を現場に持ち込む方法は、Adaが証明してきた

Adaは“ニッチな理想主義”ではない。  
**その思想は、数十年にわたって現場で生き残ってきた**。

高信頼性を求める現場で必要なのは、「早く書ける」ことではなく、  
**「後から壊れないこと」「再検証できること」**である。

> _"現場で戦える理論。それがAdaという選択だ。"_
SPARKと証明責任：証明義務とエビデンスの思想



> _"設計の信頼性は、主張ではなく証明によってのみ獲得される。"_  

ソフトウェアにおける「正しさ」は、しばしば開発者の感覚や慣例に依存している。  
しかし、航空宇宙・防衛・医療のような領域では、**「なんとなく動く」ことは許されない**。

SPARKはこの世界において、**“正しい”を証明できる設計**を言語構造として提供する。  
ここでは、SPARKが実現する「証明責任」とは何か、その背後にある思想を解き明かす。

---

## 証明責任：動くコードではなく、正しさを保証するコード

SPARKでは、関数や手続きに対して「この仕様を満たす」ことを**宣言的に明記**する。

```ada
function Compute_Average (X, Y : Integer) return Integer
  with
    Pre  => X >= 0 and Y >= 0,
    Post => Compute_Average'Result >= X and Compute_Average'Result <= Y;
```

このような記述は、単なるコメントや意図ではない。  
**証明責任（proof obligation）**として、GNATproveによって数学的に検証される。

---

## 人間の責任から、機械の証明義務へ

従来、設計者は「これは正しいはずです」と主張する側だった。  
SPARKの世界では、その主張が**「証明されなければ受け入れられない」構造**になっている。

- 設計者は仕様を明記する  
- コンパイラが構文を確認する  
- GNATproveが**その通りかを論理的に証明する**

ここにおいて、**主張と根拠が一体化する**。

---

## エビデンスベースの開発：証明はドキュメントを超える

SPARKでは、コードがそのまま**検証可能な証拠（エビデンス）**となる。  
別紙の文書やテスト結果ではなく、**構文そのものが設計意図を語る**。

この「自己証明可能なコード」は、認証・審査・監査の現場で強力な信頼を生む。

---

## GNATproveによる義務の生成と検証

設計された仕様に対して、GNATproveは以下のような**証明義務（Proof Obligations）**を自動生成する：

- 事前条件が満たされるか  
- 事後条件が常に真であるか  
- 範囲外アクセスやオーバーフローが発生しないか

これにより、**設計の論理的不備がコンパイル段階で発見される**。

---

## 結語：「主張」ではなく「証明」の上に設計を築く

設計の信頼性とは、個人の技能でも、テストの網羅率でもない。  
それは、**「正しいと主張する構造」と「それを証明する機構」が一体となったときに初めて成立する。**

SPARKは、**ソフトウェアを数学的証明の対象とする唯一の舞台**である。

> _"正しさを証明できないコードは、偶然動いているにすぎない。"_
ハッカソン個人備忘録㉝：ESLint Flat Config を使った Next.js + TypeScript プロジェクトの設定ファイル解説

## はじめに

以下のコードは、Next.js + TypeScript プロジェクトで使用される ESLint の設定ファイルです。特に、ESLint の新しい構成方法である "Flat Config" を使用している点が特徴です。

```js
import { dirname } from "path";
import { fileURLToPath } from "url";
import { FlatCompat } from "@eslint/eslintrc";

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const compat = new FlatCompat({
  baseDirectory: __dirname,
});

const eslintConfig = [
  ...compat.extends("next/core-web-vitals", "next/typescript"),
];

export default eslintConfig;
```

---

## 各部分の説明

### 1. `path` と `url` モジュールのインポート
```js
import { dirname } from "path";
import { fileURLToPath } from "url";
```
Node.js の標準モジュールです。`import.meta.url` をファイルパスに変換するために `fileURLToPath` を、そしてそのファイルのディレクトリパスを得るために `dirname` を使います。

### 2. ファイルパスとディレクトリの取得
```js
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
```
ESM 環境下でも CommonJS のように `__filename` や `__dirname` を再現するための記述です。

### 3. `FlatCompat` の初期化
```js
const compat = new FlatCompat({
  baseDirectory: __dirname,
});
```
ESLint v8 以降で正式導入された Flat Config 形式を、旧 `.eslintrc` スタイルと互換させるためのクラスです。

### 4. ルールセットの適用
```js
const eslintConfig = [
  ...compat.extends("next/core-web-vitals", "next/typescript"),
];
```
Next.js で推奨される ESLint 設定を取り込んでいます：
- `next/core-web-vitals`: パフォーマンスやアクセシビリティに関する推奨ルール
- `next/typescript`: TypeScript を使用する場合の補助ルール

### 5. 設定のエクスポート
```js
export default eslintConfig;
```
Flat Config 形式では、ESLint 設定は `export default` でエクスポートされます。

---

## 補足：Flat Config とは？
Flat Config は ESLint v8.21 以降で導入された新しい設定形式で、従来の `.eslintrc.js` に代わる形で登場しました。

**参考文献**

https://zenn.dev/makotot/articles/0d9184f3dde858

以下のような特徴があります：
- ファイル名は `eslint.config.js` が推奨される
- JavaScript モジュールとして柔軟に設定を記述可能
- モジュールのインポートや変数の利用が可能

---

## まとめ
この設定ファイルは、Next.js + TypeScript プロジェクトで ESLint を効果的に利用するために、最新の Flat Config を活用したものです。

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

既存のルールセットを取り込みつつ、柔軟な構成ができるため、今後のプロジェクトではこの形式が主流なるのではと考えております...!
Adaの初学者が躓くポイントと哲学的処方箋



> _"難しさは、語彙が多いことではない。語彙の一つひとつに“意味”が込められていることだ。"_  

Adaは習得が難しい言語だと言われる。  
たしかにその記述は冗長で、構文は厳密、自由度も低く感じられる。

だがそれは、「習得しづらい言語」なのではなく、**「設計に誠実であれ」という言語」**である。

本記事では、Adaの初学者が特につまずきやすい点を取り上げ、  
その背景にある哲学的意図と向き合うことで、**難しさを“美しさ”に変える処方箋**を提示する。

---

## 躓き①：型定義の堅牢さと制限の多さ

```ada
subtype Voltage is Integer range 0 .. 100;
```

「なんでいちいち範囲まで指定するのか？」  
その疑問はもっともだ。だが、それこそが**誤りを事前に排除する設計意図**なのだ。

Adaでは、「どんな値でも入りうる」ことは**悪**であり、  
「入り得る値を制限し、それ以外を拒否する」ことが**構文的美徳**とされる。

---

## 躓き②：制約の多い関数定義と契約条件

```ada
function Divide (X, Y : Integer) return Integer
  with Pre => Y /= 0;
```

他言語なら「ゼロ割はif文で処理すればいい」と考える。  
しかしAdaでは、**「そういう呼び出しを構文で許さない」設計**を選ぶ。

このPre条件は、**意図を明文化し、設計を“嘘のつけない言語”にする試み**である。

---

## 躓き③：無名の構造体・ラムダ・暗黙的型推論がない

JavaScriptやPythonのような「速く書ける言語」に慣れた人にとって、  
Adaの文法は窮屈に感じられるだろう。

だがAdaは、**あらゆる構成要素に“名前”を要求する。**  
その理由は明快で、**名前のないものは、設計上存在しないのと同じだから**である。

---

## 躓き④：警告ではなくコンパイルエラー

Adaは設計ミスを「警告」ではなく「拒否」する。  
それは不親切ではなく、**設計者を“未来の事故”から守る優しさ**である。

「動くかどうか」ではなく、**「正しく動く保証があるか」**を重視するのが、Adaの信念だ。

---

## 結語：不便さの中にある誠実さ

Adaは、習得すれば便利になる言語ではない。  
**そもそも“便利さ”を追求していない**。

その代わりに得られるのは、  
「設計意図がコードに宿り」「未来の誤りが予防される」「誰が読んでも一貫性のある構造」だ。

> _"Adaの難しさは、誤魔化しが通用しないという一点に_
形式仕様と実装の統合：SPARKによる“証明可能なプログラミング”



> _"実装と仕様が同じファイルに宿るとき、ソフトウェアは語り始める。"_  

従来のソフトウェア開発では、「仕様書」と「ソースコード」は別物だった。  
仕様は人間が読み、コードは機械が処理するものとして、両者はしばしば乖離してきた。

SPARK Ada はそれを統合する。  
**仕様が構文となり、実装と共に同じファイルに記述される**この設計思想は、  
開発におけるドキュメントと保証の構造を根底から変える。

---

## コードに宿る形式仕様：Pre/Postの再定義

SPARKでは、関数や手続きに **契約（Pre/Post）** を付与することで、  
仕様を明示的に文法化できる。

```ada
procedure Transfer (From, To : in out Account; Amount : Positive)
  with
    Pre  => From.Balance >= Amount,
    Post => From.Balance = From'Old.Balance - Amount and
            To.Balance   = To'Old.Balance + Amount;
```

これにより、設計意図・制約・責務がすべて**1つの構文ブロック**にまとまり、  
**実装が仕様から逸脱する余地がなくなる。**

---

## 一貫性と自動検証：仕様は嘘をつかない

- 仕様が記述されていないコードは、設計意図が読み取れない  
- コメントは信頼できない  
- テストは限定的な証拠にすぎない

SPARKの形式仕様は、これらを乗り越える。  
**仕様＝形式的条件**として定義され、それが自動検証ツールで**証明対象**になる。

---

## 設計変更と“正しさの継承”

仕様がコードに含まれていることで、変更時の検証も可能になる。

```ada
function Abs (X : Integer) return Integer
  with
    Post => Abs'Result >= 0;
```

このようなPost条件を持つ関数を改修しても、  
GNATproveがその正しさを**証明し直す**。  
これにより、「変更＝不安定化」という常識を**構造的に排除**できる。

---

## 実装と仕様の分離は、もはや古い

かつては、仕様を別紙で書くことが「丁寧な開発」だった。  
だが、仕様と実装の同期は崩れやすく、  
「いつのまにかコードが仕様と乖離する」ことは珍しくない。

SPARKは、その乖離を**構文的に禁止する世界**を提案する。

---

## 結語：コードが語る仕様、仕様が動かすコード

ソフトウェアが巨大化し、人の記憶や理解を超える今、  
正しさは**設計者の脳内にあるべきではない。**

コードそのものが語る世界へ。  
SPARKは、**「正しいソフトウェアは、書かれた時点で証明されるべきだ」**という思想を体現する。

> _"仕様がコードに寄り添うとき、バグは設計段階で死ぬ。"_
Genericと再利用：一般性と特化の調和



> _"再利用とは、曖昧を許さずに一般化することだ。"_  

多くの言語において、**再利用性と安全性はトレードオフ**とされる。  
「汎用的な構造」を作れば、「型の曖昧さ」が避けられなくなる——そんなジレンマを、Adaは断ち切る。

Adaにおける **generic** は、単なるテンプレートではない。  
**厳密な契約と型指定による、安全性の上に成り立つ再利用構造**である。

---

## 汎用性の中に、型の秩序を

Adaでは、型・値・サブプログラムを「パラメータ」として汎用化できる。  
しかし、そこには明確な制約が付く。

```ada
generic
   type Element_Type is private;
   with function "<" (Left, Right : Element_Type) return Boolean is <>;
package Generic_Sort is
   procedure Sort (A : in out Array_Type);
end Generic_Sort;
```

この構文は、「比較可能なElement_Type」という**前提を明示して再利用可能にする**。  
自由ではあるが、無秩序ではない。

---

## 型制約付きの汎用パッケージ設計

```ada
generic
   type Item is range <>;
   Default : Item;
package Counter is
   function Next(X : Item) return Item;
end Counter;
```

これは、任意の範囲型に対して適用可能な汎用カウンターであり、  
**整数型に限定した上で、汎用的に機能を提供する**例である。

---

## ジェネリクスで崩れることのない堅牢性

他の言語では、「型を渡すことでコンパイルエラーが見えなくなる」ことがある。  
Adaでは、型制約によって**「何ができて、何ができないか」を構文上保証**するため、  
**曖昧な挙動や破壊的依存関係が生じにくい。**

---

## 一般化＝抽象化ではない。文脈の制約と共にあれ

Adaのgenericは「どんな場合にも使えるもの」ではない。  
**「この文脈で使えるように設計されたもの」**として定義される。

それゆえに、再利用は制限される代わりに、**明快で予測可能**であり、  
「汎用性という名の破壊」を避ける。

---

## 結語：再利用とは、秩序の複製である

再利用できるコードとは、**意味と制約が明確に記述されているもの**である。  
汎用性と安全性は本来矛盾しない——その設計的証明が、Adaのgenericである。

> _"再利用とは、正しさの定型化である。"_
並行性の安全を保証する：Protected Objectの思想



> _"並列化は武器だ。だが制御されなければ、ただの事故になる。"_  

現代のソフトウェアは、複数の処理が同時に動くことを前提に設計されている。  
だが「同時に動く」ことは、必ずしも「協調して動く」ことを意味しない。

Adaは、単なる並行性を超えた、**協調的・安全な並行構造**を提供する。  
その鍵を握るのが、**Protected Object** である。

---

## 複数からアクセスされる「状態」を守るには

共有変数へのアクセスは、レースコンディションやデッドロックの原因となる。  
Adaはこの問題に、**同期制御と排他制御を構文レベルで提供**する。

```ada
protected type Buffer is
   procedure Insert(Item : in Integer);
   function Get return Integer;
private
   Data : Integer := 0;
end Buffer;
```

この構造により、`Data` への操作は **同期的かつ排他的** に実行される。

---

## Protected Objectの思想：同期の意味論を構文にする

Protected Object（保護オブジェクト）は、以下を同時に満たす：

- **状態の一貫性を保証**
- **ロック不要で排他制御を提供**
- **宣言的に同期構造を定義**

これは、C++やJavaに見られる明示的なロックやmutex制御とは全く異なるアプローチだ。

---

## 安全な並行設計は、明示された意図から始まる

```ada
protected body Buffer is
   procedure Insert(Item : in Integer) is
   begin
      Data := Item;
   end Insert;

   function Get return Integer is
   begin
      return Data;
   end Get;
end Buffer;
```

どの処理がどの順序でどのように排他制御されるかを、**構文上明示する**ことで、  
意図しない並行バグを「設計段階で消す」ことができる。

---

## スケーラビリティと堅牢性の両立

Protected Objectは、単に「安全」であるだけでなく、**リアルタイム制御との親和性が高い**。  
タイミング制御・優先度継承・デッドライン制御といった要素を自然に取り込める。

---

## 結語：協調する並行性を設計する

並行性は、プログラムの複雑さを加速させる力を持つ。  
だがAdaはそれを、**構文と抽象によって“設計可能な秩序”に変える**。

Protected Objectとは、**安全な協調のための構造的誠実さ**である。

> _"協調なき並行は暴走であり、設計なき共有は破滅である。"_
静的解析とAda：コンパイラを超えた保証への歩み



> _"最も信頼できるバグは、実行される前に死ぬバグである。"_  

バグの多くは、**「書いた本人でさえ、気づいていない意図のズレ」**から生まれる。  
これをテストで拾おうとする発想は、常に後手である。

Adaはその設計思想の中で、「静的解析」＝**コンパイル時点での検証による保証**を前提としている。  
とくにSPARK Adaでは、**GNATprove**というツールを用いて、コードを**数学的に証明可能な構造物**へと昇華させる。

---

## 静的解析の本質：実行前に設計を証明する

静的解析は、以下の問いに答える：

- このコードは、**定義された契約に違反していないか？**
- この関数は、**呼び出されたとき常に正しい状態にあるか？**
- この変数は、**未初期化状態で使われていないか？**

これらを**実行せずに検証する**。

---

## GNATprove：証明ツールではなく設計の鏡

SPARKの静的解析ツールである `GNATprove` は、以下の情報を用いてコードを解析する：

- Pre/Post条件
- 型制約と範囲情報
- アクセス可能なメモリ情報（Global/Depends）
- Loop不変式（loop invariant）

```ada
procedure Increment (X : in out Integer)
  with
    Pre  => X < Integer'Last,
    Post => X = X'Old + 1;
```

この定義により、GNATproveは「Xが上限を超えることはない」と**数学的に保証する**。

---

## コンパイルの先にある「保証」の設計

コンパイルが通ること＝安全、ではない。  
Adaの世界では、**「構文が正しいこと」と「意図が正しいこと」は分けて考える。**

静的解析は、**構文上の正当性を超えて、設計意図が保証されているかどうか**をチェックする。

---

## 設計段階で証明される世界

SPARKでは、コードが完成した瞬間にその正しさを機械的に証明できる。  
これは「自動検査」ではなく、**設計と仕様が数学的に整合していることの保証**である。

---

## 結語：保証なき実行は、希望にすぎない

テストでは足りない。レビューも限界がある。  
真に信頼されるソフトウェアは、**論理的に破綻のない構造でのみ成立する**。

静的解析とは、**開発者の主観を越えた“第三の目”**であり、Adaはそのための言語である。

> _"検証されない設計は、設計ではなく賭けである。"_
Adaのモジュール設計：パッケージと可視性の哲学



> _"見せないことが、信頼を生む。"_

ソフトウェアの本質は、機能ではなく**構造**である。  
構造を制御するということは、**「何が、どこから、どう見えるか」を設計すること**に他ならない。

Adaにおけるモジュール設計は、**パッケージ（package）という単位によって厳密に制御される**。

---

## パッケージ＝「見せること」と「隠すこと」の境界線

Adaのパッケージは、インターフェースと実装が**物理的に分離**されている。

```ada
-- インターフェース定義
package Motor_Control is
   procedure Start;
   procedure Stop;
end Motor_Control;

-- 実装定義
package body Motor_Control is
   procedure Start is
   begin
      -- 実装詳細
   end Start;

   procedure Stop is
   begin
      -- 実装詳細
   end Stop;
end Motor_Control;
```

この分離によって、**公開されたインターフェース以外に依存することを構文的に禁止**できる。

---

## 「実装の不可視化」が守る3つのもの

1. **変更耐性**  
   実装を差し替えても、外部には影響しない。

2. **意図の明確化**  
   設計者が「これだけを使ってほしい」という意思を構文で表明できる。

3. **セキュリティと堅牢性**  
   内部の構造に不用意に踏み込まれることを防ぐ。

---

## private型：完全なカプセル化を実現する型制御

```ada
type Engine_State is private;

private
   type Engine_State is (Idle, Running, Error);
```

外部からは `Engine_State` の構造が見えず、値の操作も制限される。  
これはC++の`private`よりも厳密な意味での**構文的カプセル化**である。

---

## 可視性制御によって、設計者の意図が守られる

Adaでは、すべてのシンボルに対して**明示的な「公開／非公開」の指定**が必要になる。  
これにより、**無意識の依存関係**を排除し、設計の自律性が保たれる。

---

## 結語：構造の秩序が、ソフトウェアを永続させる

良い設計とは、美しい実装ではなく、**壊れにくい構造**である。  
Adaのパッケージシステムは、見えるものを制限することで、未来の破綻を防ぐ。

> _"コードは記述するものではなく、公開と非公開を設計するものである。"_
Adaとリアルタイム性：確定性という信頼



> _"信頼は速度ではなく、確定性から生まれる。"_  

リアルタイムシステムの本質とは、「速さ」ではなく「約束されたタイミング」である。  
Adaは、この**“いつ動くか”を設計できる言語**であり、リアルタイム制御の信頼を設計に組み込む。

CやC++がリアルタイムを「努力と規律」で実現しようとする一方で、  
Adaは構文と言語仕様の中に、**確定性を構造として持っている**。

---

## 時間は変数ではない：RT設計の前提

リアルタイム制御において、プログラムは単に「動く」だけでは足りない。  
**「いつ、どのくらいで、何をするか」が予測可能でなければならない。**

Adaはこの設計思想に従い、リアルタイム対応として以下を提供している：

- 高精度なタイマー制御 (`delay until`)
- 優先度ベースのスケジューリング (`pragma Priority`)
- 並行処理タスクの明示的定義 (`task`)

---

## 例：タイミング制御の構文的保証

```ada
task body Heartbeat is
begin
   loop
      Send_Pulse;
      delay until Clock + 0.001; -- 毎ミリ秒ごとに制御
   end loop;
end Heartbeat;
```

この `delay until` は、単なる「待機」ではない。  
**システム時刻との明示的な関係性**を定義し、実行タイミングを確定させる。

---

## 優先度制御とデッドライン遵守

Adaは、リアルタイムOSとの連携を前提とした設計が可能。  
`pragma` を通じて、タスクの優先順位を明示的に定義できる。

```ada
pragma Priority (System.Default_Priority'Last); -- 最優先に設定
```

これにより、**スケジューラとの対話が言語構文に昇華される**。

---

## 組込み制御への親和性

航空・宇宙・鉄道・防衛。  
Adaがこれほどまでにリアルタイム領域で採用されてきた理由は、**「設計を裏切らない言語構造」**にある。

ハードウェア依存の挙動を排し、予測可能なソフトウェアの骨格を作る。

---

## 結語：予測できるコードだけが、制御を担える

信頼性とは、スピードではない。  
それは、**「次に何が起きるかを設計者自身が説明できる」こと**であり、Adaはその要求に真正面から応える。

> _"リアルタイム設計とは、未来の一秒を制御することである。"_
宣言の美学：明示される意図の構造化



> _"意図を隠したコードは、美しくない。"_  

多くのプログラミング言語は、表現力や記述の短さを「洗練」として評価する。  
だが、Adaは異なる。

**短さではなく、明示性を**。  
**柔軟さではなく、構造性を**。  
そう語るかのように、Adaはすべてにおいて「宣言せよ」と命じる。

---

## 宣言とは何か：コードに思想を刻むこと

Adaの構文は「省略」を嫌う。  
すべてを明示的に定義することは、単なる冗長さではなく、**構造的な誠実さ**である。

```ada
type Temperature is range -273 .. 1000;
subtype Room_Temp is Temperature range 15 .. 30;
```

この例には、**意味の分化**が明確に刻まれている。  
設計意図を隠すことなく、型の階層構造として表現している。

---

## 無名を嫌う構文規律

Adaでは、手続き・関数・型・定数・例外のいずれにおいても「名前」を明示することが強制される。  
これは、設計上の**すべての構成要素に意図と責任を持たせる**ためである。

```ada
procedure Initialize_Engine;
function Calculate_Torque return Float;
```

こうした命名と構造の明示は、コードを**設計書と等価な存在**に近づける。

---

## 可読性と可検証性は同じ構造から生まれる

曖昧な構文は、誤解とバグの温床となる。  
Adaの構文は、「読むこと」と「検証すること」を同一線上に置いている。

- 構文は明示される
- 型は文脈ごとに限定される
- 意図は名前と契約に埋め込まれる

この結果として、**機械にも人にも正しさが伝わる**。

---

## 宣言はコストではない、未来への投資である

初期実装においては、たしかに記述が多く感じられるかもしれない。  
だが、その**すべてが後工程のコスト削減へと還元される**。

- 他者が読むコスト
- 修正のリスク
- 設計変更時の影響範囲

これらを事前に封じ込める宣言の力は、決して小さくない。

---

## 結語：明示された意図こそが、設計の美学

Adaは黙らない。  
すべてを語れと命じてくる。  
それは、設計における**誠実さの強制**であり、**読み手への最大の敬意**でもある。

> _"宣言とは、設計を隠さない勇気である。"_
Adaにおける例外処理：制御ではなく設計の補強として



> _"例外は、設計の逃げではなく、設計の覚悟である。"_  

例外処理は往々にして「雑に扱われがちな最後の手段」としてコードに埋め込まれる。  
だがAdaにおいて、例外は**設計の一部であり、最後の砦ではなく「想定された補強」**である。

Adaの例外機構は、他の言語と同様に存在するが、その**位置付けと使用思想**は決定的に異なる。

---

## Adaの例外は「補助線」である

Adaはコンパイル時検証を徹底する言語だが、それでも**想定外の外部要因**が存在する世界においては、例外が必要になる。

```ada
begin
   Parse_Config_File;
exception
   when Constraint_Error =>
      Put_Line("Invalid configuration format.");
   when others =>
      Put_Line("Unknown failure occurred.");
end;
```

このように、例外処理は**制御の中心ではなく、構造の末端**に置かれる。

---

## 他の言語に見られる「例外依存構造」との決別

多くの言語では、**try-catchで囲む前提で設計が進む**。  
これは、「正しさは保証できないが、失敗時に対応すればいい」という**後手の思想**である。

Adaは逆である。  
**まず正しく書け。正しさの外側だけを例外として扱え。**

---

## 設計の補強としての例外使用

例外とは本来、「設計に取り込めなかった外界とのインタフェース」への備えである。

- I/Oエラー
- 不正なハードウェア状態
- OSとの不整合

こうした**本質的に制御不能な要素**に対してのみ、例外を使う。

---

## SPARKとの分離：例外を許さない領域の設計

SPARK Adaでは、例外を**言語機能として無効化**している。  
それは「完全に制御可能な領域のみを設計せよ」という思想から来ている。

つまり、SPARKでは**例外の発生し得る構造自体を排除する**ことで、検証可能性を保つ。

---

## 結語：例外は「無責任」ではなく「責任の補完」である

例外処理とは、バグの隠蔽ではない。  
それは、**設計意図に入り込めなかった現実との「誠実な向き合い」**である。

Adaは例外を「制御フローの分岐」ではなく、**設計の余白を守る囲い**として扱う。

> _"例外は、設計者が制御できなかった世界への、最後の礼節である。"_