OmniAICreator/Qiita-1.07M huggingface dataset:
Strategyパターン

## 1. Strategy パターンとは？

- **定義**: アルゴリズムのファミリーを定義し、それぞれをカプセル化して交換可能にするデザインパターン
- **目的**: 実行時にアルゴリズムを動的に変更可能にする
- **カテゴリ**: 振る舞いパターン（Behavioral Pattern）

## 2. どんな時に使う？

- 同じタスクを異なる方法で実行する必要がある場合
- アルゴリズムの変更をクライアントから独立させたい場合
- 条件分岐を減らし、コードを柔軟にしたい場合

## 3. 構造

- **Context**: 戦略を利用するクラス。Strategyの参照を持つ
- **Strategy**: アルゴリズムのインターフェース
- **ConcreteStrategy**: 具体的なアルゴリズムの実装

## 4. サンプルコード（Java）

支払い方法を切り替える例。

```java
// Strategyインターフェース
interface PaymentStrategy {
    void pay(int amount);
}

// ConcreteStrategy
class CreditCardPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with Credit Card");
    }
}

class PayPalPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " with PayPal");
    }
}

// Context
class ShoppingCart {
    private PaymentStrategy paymentStrategy;
    
    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.paymentStrategy = strategy;
    }
    
    public void checkout(int amount) {
        paymentStrategy.pay(amount);
    }
}

// クライアントコード
public class Main {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();
        cart.setPaymentStrategy(new CreditCardPayment());
        cart.checkout(100); // Paid 100 with Credit Card
        cart.setPaymentStrategy(new PayPalPayment());
        cart.checkout(200); // Paid 200 with PayPal
    }
}
```

## 5. メリット

- アルゴリズムを交換可能、コードの再利用性向上
- 条件分岐を削減し、単一責任の原則を遵守
- 新しいアルゴリズムの追加が容易

## 6. デメリット

- クラス数が増える
- クライアントが具体的な戦略を知る必要がある場合も

## 7. 実際の使用例

- ソートアルゴリズム（クイックソート、マージソートなど）の切り替え
- 支払い処理（クレジットカード、PayPal、暗号通貨など）
- ゲームのAI戦略（攻撃的、防御的など）

## 8. まとめ

- Strategyパターンは、アルゴリズムを動的に切り替えたい場合に有効
- 柔軟性と拡張性を提供し、条件分岐を最小限に抑える
- 適切な場面で使用すれば、コードの保守性が向上！
プロダクション環境へのデプロイを成功させる実践編（パート2）

\
前回はデプロイ前の準備について解説しましたが、今回は実際に本番（プロダクション）環境へデプロイする際の実践的なポイントや注意点を紹介します。

---

### 🔄 1. デプロイ前に必ずバックアップを取る

本番環境へのデプロイ前には、必ずすべてのデータとコードをバックアップしてください。予期せぬエラーや不具合が発生した場合でも、バックアップがあればすぐにロールバックが可能です。バックアップ中にユーザーがデータを追加しないよう、一時的に「メンテナンスモード」や「リードオンリーモード」に切り替えることも重要です。もしダウンタイムを避けたい場合は、ゼロダウンタイムデプロイ手法も検討してください。

---

### 🕵️‍♂️ 2. 本番環境の構成をしっかり把握する

開発環境と本番環境では、OSやミドルウェア、ライブラリのバージョンが異なる場合があります。特にLinuxやBSDなどサーバー環境で動かす場合は、環境依存のトラブルが発生しやすいので、事前に本番環境の構成をしっかり確認しましょう。仮想サーバーやコンテナを使っている場合も、ホスティング環境やバージョンの互換性に注意が必要です。

---

### 🤖 3. 自動デプロイツールを活用する

手動でのデプロイはミスや漏れが発生しやすいため、できるだけ自動デプロイツール（例：Jenkins、GitLab CI/CD、GitHub Actionsなど）を活用してください。自動デプロイツールを使うことで、デプロイプロセスが標準化され、再現性も高まります。また、デプロイ時のエラーもログとして残るので、トラブルシューティングも容易です。

---

### 👥 4. デプロイ時はチーム全員で待機する

重大なデプロイや初回デプロイの際は、チーム全員が待機し、必要に応じて即座に対応できる体制を整えておきましょう。デプロイ後に予期せぬエラーが発生した場合でも、迅速にロールバックや修正ができます。チーム内でデプロイ担当者を明確にしておくことも重要です。

---

### 🛡️ 5. デプロイ後の動作確認を徹底する

デプロイが完了したら、必ず本番環境でアプリケーションが正常に動作しているか確認してください。ログやモニタリングツールを活用し、ユーザーへの影響がないかチェックしましょう。また、主要な機能やAPIが正しく動作しているか、自動テストや手動テストで検証することも重要です。

---

### 🔄 6. ロールバック手順を用意しておく

万が一デプロイ後に重大なバグや障害が発生した場合に備え、ロールバック手順を事前に準備しておきましょう。ロールバック手順をドキュメント化し、チームメンバーがすぐに実行できるようにしておくことで、トラブル時のダウンタイムを最小限に抑えられます。

---

### 📝 7. デプロイに関するドキュメントを更新する

デプロイ後は、デプロイ内容や変更点、注意事項などをドキュメントに記録してください。次回以降のデプロイやトラブルシューティングの際に役立ちます。また、チームメンバーがデプロイ履歴を確認できるように、Wikiや共有ドキュメントを活用しましょう。

---

### 🚨 8. デプロイ失敗時の対応フローを明確にする

デプロイ失敗時の対応フローを事前に決めておき、チーム全員で共有してください。誰がどのタイミングでどのようなアクションを取るか明確にすることで、トラブル時の混乱を防げます。また、根本原因分析（RCA）を行い、再発防止策を講じることも重要です。

---

## 🏁 まとめ

本番環境へのデプロイは、準備だけでなく実践的な運用も非常に重要です。バックアップ、自動デプロイ、動作確認、ロールバック、ドキュメント管理など、一連の流れを徹底し、トラブルに備えることで、安定したシステム運用を実現できます。
npx tailwindcss initでエラーが出る理由

はじめに
---
ChatGPTに相談しながらtailwindCSSをReactに導入しようとしたところ、
`npx tailwindcss init -p`コマンドでエラーが発生していました。
すこし苦労したので記事にします。

問題
---
下記コマンドを実行するとエラーが、、、

```
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

> 'tailwind' は、内部コマンドまたは外部コマンド、
> 操作可能なプログラムまたはバッチ ファイルとして認識されていません。
```

原因
---
TailwindCSSのバージョンが4系になったことで、
インストール方法が変わったようです。

:::note
2025/05/24 現在最新版のtailwindcssはv4.1です。
<p><a href="https://tailwindcss.com/" target="_blank" rel="noopener" style="display:inline-block;background-color:#38bdf8;color:#fff;padding:6px 12px;border-radius:4px;text-decoration:none;font-weight:bold;">Tailwind CSS 公式サイト</a></p>
:::

解決方法
---

下記のように`tailwindcss@3.4.13`と3系のバージョン指定をすることで
従来通りとされる方法でインストールができました。
```
$ npm install -D tailwindcss@3.4.13 autoprefixer postcss
$ npx tailwindcss init -p

> Created Tailwind CSS config file: tailwind.config.js
> Created PostCSS config file: postcss.config.js
```

おわりに
---
これでtailwindcssを試すことができます！

:::note
@Sicut_study さんの記事のおかげで解決することができました。
深く感謝申し上げます。
[npx tailwindcss initでnpm error could not determine executable to runエラーが出る](https://qiita.com/Sicut_study/items/6b0fb7388e265bdb11da)
:::

今後も学んだこと・つまずいたことを共有していきます。
どなたかの目に留まり助けとなれば幸いです。
プロダクション環境へのデプロイをスムーズに進めるための準備（パート1）

**「防ぐより備えよ」**  
プロダクション環境へのデプロイ前の入念な準備は、システムの安定稼働を保証するうえで非常に重要です。Mike Tysonの名言「誰もが計画を持っているが、顔面を殴られるまではね」を思い出しますが、だからといって準備が無駄なわけではありません。困難な状況に陥ったとき、準備をしていることで有利に進められます。

---

### 1️⃣ 常にクリーンなコードを意識する

クリーンなコードは、あらゆる状況で推奨されるべきものです。プロダクションへのデプロイをより安全に行うために、コードが整理され、分かりやすい状態であることが大切です。これは、他者がコードを引き継いだ場合や、あなた自身が修正する場合にも役立ちます。特にプロダクション環境では、時間が非常に貴重です。1分の遅れが大きな問題を引き起こすこともあります。私は、チームメンバーのコードをデプロイし、プロダクションでエラーに遭遇した経験が何度もあります。その際、本人に電話をしても対応できないことがあり、自分でコードを見て即座に修正しなければならないことも。そんな時、コードが分かりにくいと修正に時間がかかり、クライアントからの問い合わせも増えてしまいます。

---

### 2️⃣ 防御的プログラミング（Defensive Programming）を実践する

私は「The Pragmatic Programmer（実践プログラマー）」という本で紹介されている防御的プログラミングの考え方が非常に好きです。この手法を身につけることで、予期せぬエラーや環境の変化にも柔軟に対応できます。インドのエンジニアのコードは冗長で複雑なことが多いですが、エラー処理がしっかりしており、安定して動作している印象があります。

---

### 3️⃣ 可能な限りユニットテストを活用する

コードに問題が発生するまで、誰もコードを見てくれないものです。エラー処理能力を自ら身につけ、コードを書く段階からテストを実施することが重要です。ユニットテストを活用することで、一部のバグ修正時にシステム全体を再テストする必要がなくなり、バグの連鎖（デグレード）を防げます。さらに、ユニットテストは思考力や予測力のトレーニングにもなります。テストカバレッジが高いほどバグは減り、プロダクションへのデプロイも安心して行えます。

---

### 4️⃣ ログ記録の習慣をつける

ログ記録は、開発中からプロダクション環境まで非常に役立ちます。プロダクション環境でデバッグモードを有効にするのは絶対に避けてください。例外やシステムの動作情報をログに記録しておくことで、問題発生時の調査が非常に楽になります。また、ログがあることで、問題が自分のコードではなく他の箇所にあることを証明する根拠にもなります（ただし、ログ記録自体がエラーを引き起こすこともあります。私はLaravelとDockerでログファイルへの書き込みができず、システムが落ちた経験があります）。

---

### 5️⃣ 可能ならCI（継続的インテグレーション）を導入する

CIを導入することで、コードレビューや自動テストなど、普段は面倒でやりがちな作業を自動化できます。CIの活用により開発スピードが向上し、より良いコードを書く時間も増えます。

---

### 6️⃣ デプロイ用チェックリストを作成する

デプロイ用のチェックリストを作成することは非常に重要です。デプロイ前・中・後の各ステップをリスト化しておくことで、重要な手順を忘れることがなくなります。また、各ステップにかかる時間も把握できます。私が参加したプロジェクトでは、クライアントからチェックリストの作成を求められることが多く、デプロイの進捗を共有することで信頼を得られました。クライアントが要求していなくても、自発的にチェックリストを提供することで、DevOpsとしての専門性をアピールできます。

---

### 7️⃣ プロダクション環境の前にDev/Test/Staging環境を準備する

プロジェクトの要件やリソースによりますが、重要なプロジェクトやDevOpsが十分に活用できる場合は、開発・テスト・ステージング環境を分けて運用することをおすすめします。ステージングサーバーでコードが正常に動作することを確認してから、プロダクション環境へデプロイしてください。

---

### 8️⃣ デプロイ用のワークフローとパイプラインを作成する

基本的にワークフローやパイプラインはチェックリストと似ていますが、より技術的な側面が強いです。パイプラインでは、各ステップが完了しないと次のステップに進めないようになっています。たとえば、自動テストが失敗した場合は、テストサーバーへのデプロイができません。パイプラインはステップ・バイ・ステップの流れであり、チェックリストは並列や順不同で実施できるリストであることを理解しておきましょう。
git bisectでバグ混入コミットを特定する

多くのコミットを重ねた後で、想定外の箇所で不具合に気づいたとき、「いつから壊れたのか」を突き止めるのは地味に面倒。密結合気味な構造のシステムだと、どのファイルに原因があるのか検討もつかないこともあると思います。

こういうときに役立つのが `git bisect`。問題のコミットを、最小限の試行回数で効率よく特定できます。

## git bisect を使わない場合

問題のコミットを探るとして、1件ずつ戻して調べていたらキリがありません。効率よく進めるには、次のような手順で原因を探るかと思います。

```
1. 最新のコミットで不具合を確認
2. 確実と思われる古いコミットで動作確認 → 問題なし
3. 少し遡った新しいコミットに移動 → 問題あり
4. さらに範囲を狭めた古いコミットで動作確認 → 問題なし
5. さらに範囲を狭めた新しいコミットに移動 → 問題あり
6. さらに範囲を狭めた古いコミットで動作確認 → 問題なし
7. さらに範囲を狭めた新しいコミットに移動 → 問題あり
8. 上記の繰り返し・・・いつか問題のコミットにたどり着く
```

新しい側・古い側の両方から範囲を狭めてバグコミットを包囲していく。難しくはないですがshaのコピペなどの手作業が地味に面倒。`git bisect` を使うと簡単です。

## git bisect を使ってみる

```bash
git bisect start
git bisect bad            # 現在はバグ状態であることを示す
git bisect good abc1234   # バグがないとわかっている古いコミットを指定
```

まず、上記のように入力して開始します（※1行で一発指定することもできます。後述）。

すると自動的に中間のコミットにコードを戻してくれるので、アプリの動作を確認。確認できたら、次のように入力します。

```bash
git bisect good   # 問題なしの場合
git bisect bad    # 問題ありの場合
```

goodとbadを繰り返しながらコミット履歴を「中間 → 中間 → 中間・・・」とたどっていくと、最終的には分岐しきれない一点に到達します。すると次のようなメッセージが表示されます。

```
<commit-hash> is the first bad commit
```

これは「このコミットで問題が発生した」とGitが判断したことを意味します。つまり、**バグが混入したコミットを特定できた**ということ。

簡単。意外と早く特定ポイントに到達できます。

### HEADやブランチ名を指定してstartすることもできる

SHAを調べるのが面倒な場合は、次のようにポインタやブランチ名などでも指定できます。

```bash
git bisect start HEAD origin/main
```

上記は以下と同じ意味です。

```bash
git bisect start
git bisect bad HEAD
git bisect good origin/main
```

## 探索の終了と復帰

特定できたら、以下で元の状態に戻します。

```
git bisect reset
```

これで完了。元のブランチや作業ツリーには影響せず、安全に bisect モードを抜けられます。

## 実際どれくらいの手間ですむ？

コミット数100件 → 最大7回、1000件 → 最大10回、10000件でも最大14回。かなりコミット数が多くても大差ないので、ブランチを切ったところから大雑把にバグ探しを始めるとよいでしょう。

手作業でコミットログを見ながら「ここが怪しいはず」と目星をつけて探ると早そうですが、bisectに任せて黙々と手を動かすほうが意外とラクです。

## 応用編

`git bisect` には、以下のような応用的な使い方もあります。

* `git bisect skip`
  * 確認不要なコミットをスキップさせる。たとえばphp構文エラーで確認しようがない場合など
    * たまたまバグ発生コミットだったりすることもあるので要注意
* `git bisect log` / `git bisect replay`
  * 探索履歴を記録・再現できる。チーム内での共有に便利
* `git bisect run <cmd>`
  * テストスクリプトなどを指定して、自動的に探索させる
  * スクリプトの終了ステータスに応じて、`good`/`bad` を自動で判定
  * つまりバグ特定を**完全に自動化**できる
    * CI/CDに自動テストとセットで組み込めば、何かあった時のバグ探しまで自動でやってくれる

## 参考リンク

* [Git公式ドキュメント：git bisect](https://git-scm.com/docs/git-bisect)

## まとめ

`git bisect` はシンプルで強力なデバッグ支援ツール。「いつから壊れた？」と思ったら、まずは `git bisect` を思い出してください。
【用語解説】SOCKS(Socket Secure)プロキシについて

:::note info
普通のHTTPプロキシとは何が違うのか...。
:::

# 概要
・SOCKSプロキシとは、クライアントとサーバー間のネットワークパケットをプロキシサーバー経由で中継するプロトコル。

・最新のSOCKS5では、TCPストリームプロキシに加え、UDPパケットの転送もサポートする。ユーザー名/パスワードやGSSAPIなどの認証方式をオプションで利用出来る。

・多くの実装がIANA登録のTCPポート1080番で待機。

# SOCKSとHTTPプロキシの主な違い
### 対応プロトコルレベル
SOCKSプロキシはOSI参照モデルのセッション蒼（L5）で動作。
tcp/ipレベルの**任意のプロトコル**を透過的に中継。

一方、HTTPプロキシはアプリケーション層（L7）でHTTPプロトコルを解釈し、HTTPリクエスト/レスポンスのみを扱う。

### 転送可能なトラフィック
SOCKSプロキシはプロトコルに依存せず、TCPとUDP両方の任意ストリームを中継可能。
一方、HTTPプロキシは主にHTTPまたはHTTPSトラフィックの中継に特化し、他のプロトコルを直接扱うことはない。

### 認証方式
SOCKS5ではユーザー名／パスワード認証やGSSAPIなど複数の認証方式をサポートし、認証が不要な設定も可能。
HTTPプロキシはHTTPのProxy-AuthenticateおよびProxy-Authorizationヘッダーを用いて、Basic認証やDigest認証などでアクセス制御を行う。

### 性能と用途
SOCKSプロキシはトラフィックを解析せず単純に転送するため、高速に動作し、P2Pファイル共有やオンラインゲーム、SSHトンネルなど多様な用途に適している。
HTTPプロキシはキャッシュ機能やコンテンツフィルタリング機能を持つものが多く、主にWeb閲覧のパフォーマンス向上やフィルタリングに利用される。

## 参考文献（2025年5月24日）

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Proxy-Authenticate

https://www.remote.it/resources/understanding-socks-proxies
AWS × Terraform構成をステップ別に自動化してみた【構成図あり】

# AWS × Terraform構成をステップ別に自動化してみた【構成図あり】

AWSでの学習・構築経験を元に、Terraformを使って以下のような構成を段階的に構築してみました。



## 📌 使用サービス（ステップ別）

### ✅ #1 VPC＋Public Subnet
- TerraformでCIDR設計＆基本タグ構成を作成
- `aws_vpc` / `aws_subnet` の基本リソース管理

### ✅ #2 Nginx on EC2（Public Subnet）
- EC2を構築し、Nginxの初期ページを確認
- SGとIGWの設定をTerraformで自動化

### ✅ #3 WordPress on EC2＋RDS
- Private SubnetでRDS構築し、パブリック側のEC2から接続
- `aws_db_instance` などを使った接続構成

### ✅ #4 ALB＋NAT構成
- ALBからのアクセス受付＋EC2→NAT経由で外部通信
- NAT Gatewayとルートテーブルの設定もIaC化

### ✅ #5 ECS＋ECR＋Nginx
- ECRにDockerイメージをpushし、Fargateにてデプロイ
- ALBとターゲットグループの連携も含む

### ✅ #6 VPC Endpoint＋S3構成
- ECSからS3への通信に対してVPC Endpointを経由
- よりセキュアで費用を抑えた構成を意識

## 💡 工夫した点

- モジュール分割と `depends_on` を駆使した構成
- `lifecycle` で不要な削除・変更を防止
- S3＋DynamoDBによるtfstate管理

## 📂 GitHubリンク

→　https://github.com/Kkasuga904/terraform-aws-portfolio

## 🛠 構成図

![ChatGPT Image May 24, 2025, 04_41_20 PM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3582037/88963bcf-6682-4f7e-a78f-74d3b68c5769.png)


## 💼 ココナラで構築代行受付中

ポートフォリオで使った構成やカスタマイズ対応も含め、構築代行も受け付けています。

https://coconala.com/services/3709841


## 📦 Terraformテンプレを販売しています！

本記事の構成をベースに、再利用可能な構成テンプレートをBoothで販売しています👇

👉 [Terraform × AWS構成テンプレ（Booth）](https://awsssteraform.booth.pm/items/6994781)

- 初学者向けでも使いやすい設計
- モジュール分離済み、保守性・可搬性を意識
- 初月は購入者特典で「コードレビュー」付き

※ぜひ導入・改善のベースにご活用ください！
Claude 4（クロード4）オープン！OpusとSonnetの違いと新機能を徹底解説

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4068926/eceb7a67-8a8a-4594-a6da-e93ee40ce96c.png)

Anthropicは、次世代AIアシスタント「Claude 4」シリーズをリリースしました。今回は、その中核となる「Claude Opus 4」と「Claude Sonnet 4」の特徴と、開発者にとってのメリットを解説します。

## 🚀 Claude 4の新機能

Claude Opus 4とSonnet 4は、コーディング、推論、開発者体験の分野で新たな基準を確立します。

- **Opus 4**  
  Anthropic史上最強のAIモデルで、複数のソフトウェア工学ベンチマークでトップクラスの性能を発揮します。特に長時間のタスクやエージェントワークフローに強みがあります。
- **Sonnet 4**  
  Sonnet 3.7から大幅に進化し、より高速で正確な回答、そしてユーザーの指示への高い対応力が特徴です。

## 🧠 拡張思考・並列ツール・メモリ

両モデルは「拡張思考（extended thinking）」に対応。Claudeは推論とツール利用（例：Web検索、ファイルアクセス、API呼び出し）を交互に行い、複雑なタスクを解決できます。

- **ツールの利用**  
  検索、ファイルアクセス、APIなど多様なツールを推論中に活用
- **メモリ機能**  
  ファイル間で重要な情報を保持し、擬似的な「記憶」を実現
- **並列ツール実行**  
  複数のツールを同時に利用し、より高速かつ高度なエージェント動作が可能

これにより、Claudeは長時間にわたる知識蓄積や繰り返し作業の回避、マルチアワー級のワークフローにおける文脈維持が可能です。

## 💻 Claude Codeの一般提供開始

Claude Codeが正式リリースされ、開発者向けの強力なIDE連携が実現。

- **🔧 IDE連携**  
  VS CodeやJetBrainsプラグインで、Claudeの編集内容をリアルタイムでコード内に表示
- **🧰 Claude Code SDK**  
  Claudeのアーキテクチャを活用した独自エージェントの構築が可能
- **🚀 GitHub Betaアプリ**  
  CI/CDフローやPRレビューでClaude Codeを実行可能。  
  コマンド: `/install-github-app` でGitHubワークフローと連携

## 📊 ベンチマーク性能

Claude Opus 4は主要コーディング指標で他モデルを圧倒。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4068926/c67e92b2-1bdf-406e-8791-81fa10588084.png)


| モデル              | SWE-bench | Terminal-bench |
|---------------------|-----------|----------------|
| Claude Opus 4       | 72.5%     | 43.2%          |
| Claude Sonnet 4     | 72.7%     | 39.4%          |

Claude 4はコード生成、デバッグ、リファクタリングなど、複雑なタスクでも高い精度を維持。特にSWE-benchでは、実世界のGitHubイシューを解決する能力が高く評価されています（Opus 4は72.5%、Sonnet 4は72.7%）。

Opus 4は大規模なリファクタリングや長時間のエージェント実行に最適。Sonnet 4は高速な応答と高い精度が求められるタスクで優れています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4068926/efc01222-81ce-48c1-b9e3-f65b9cd51f07.png)


## 🧩 導入事例

- **GitHub**：Copilotの新エージェント機能をClaudeで強化
- **Cursor**：大規模コードベースの理解力で業界最高峰
- **Replit**：複数ファイルの正確な変更を実現
- **Rakuten**：7時間に及ぶオープンソースリファクタリングをClaude単体で完遂
- **Manus, Augment, Sourcegraph**：コード編集、ナビゲーション、成功率向上

## 🧬 Opus 4 vs Sonnet 4

| 特徴           | Claude Opus 4                | Claude Sonnet 4              |
|----------------|-----------------------------|------------------------------|
| 性能           | 🚀 最強（フロンティアエージェント） | 🧠 実用性重視のバランス型       |
| コスト         | 💲 $15/$75（100万トークン）     | 💲 $3/$15（100万トークン）      |
| 用途           | 長時間・複雑なワークフロー    | 高速タスク・汎用サポート     |
| 利用可能層     | Pro/Team/Enterprise         | 無料＋Pro                    |

## 🗂️ 新API機能

- **コード実行ツール**
- **MCPコネクタ**
- **Files API**
- **プロンプトキャッシュ（1時間）**

独自のツールチェーンや永続的メモリを活用した強力なAIエージェント構築が可能に。

## 📌 導入方法

Claude 4は、完全な文脈維持、長時間の深い思考、スタックへの直接統合が特徴です。

- **Anthropic.com**
- **Claude Code SDK**
- **GitHub Beta**
- **Amazon Bedrock & Google Vertex AI**

## 🙋 FAQ

- **Opus 4とSonnet 4の違いは？**  
  Opus 4は推論・長時間タスクに最適。Sonnet 4は高速・コスト効率重視。
- **Claude 4はGPT-4より優れている？**  
  SWE-benchなどコーディング指標でGPT-4を上回り、長期メモリやエージェント連続性も優位。
- **VS CodeでClaude Codeは使える？**  
  はい。拡張機能をインストールすれば、コード編集が直接反映されます。
- **無料で使える？**  
  Sonnet 4は無料プランでも利用可能。

Claude 4を活用し、開発ワークフローをさらに進化させましょう。
Railsマイグレーションにおける外部キー制約エラーの解決がしたい

はじめまして！最近Railsでモデル設計を見直す機会があり、外部キー制約に関するマイグレーションエラーに遭遇しました。😅

## 🔍 エラーの詳細分析
```bash
PG::UndefinedTable: ERROR:  relation "customers" does not exist
```
`customer`モデルの作り直しをしたいと考えた時に、すでに存在する`projects`とのリレーションがあるため、
エラーは、`projects`テーブルの作成時に参照先の`customers`テーブルが存在しないことを示しています。これは単なる実行順序の問題に見えます。

## 💡 問題の本質的理解
### 1. マイグレーションの実行メカニズム
Railsのマイグレーションは、ファイル名のタイムスタンプに基づいて順次実行されます。この仕組みは通常は問題ありませんが、以下のようなケースで課題が生じます：
- 既存のアプリケーションにリファクタリングを加える場合
- 複数の開発者が並行してマイグレーションを作成する場合
- 循環参照が存在する複雑なスキーマ設計の場合

### 2. 外部キー制約の役割と課題
外部キー制約は、データ整合性を保証する重要な機能です。しかし、開発プロセスにおいては以下のジレンマが存在します：
```ruby
# 理想的な世界 ✨
create_table :projects do |t|
  t.references :customer, foreign_key: true  # データ整合性を保証
end
# 現実の世界 😱
# → customersテーブルがまだ存在しない可能性
```

## 🛠️ 解決アプローチの比較検討
### アプローチ1: 条件付き外部キー制約
```ruby
class CreateProjects < ActiveRecord::Migration[7.0]
  def change
    create_table :projects do |t|
      t.string :name
      t.references :customer, foreign_key: false
      t.timestamps
    end
    
    # 条件付きで外部キー制約を追加
    if ActiveRecord::Base.connection.table_exists?(:customers)
      add_foreign_key :projects, :customers
    else
      # 後続のマイグレーションで追加することを想定
      Rails.logger.warn "Customers table not found. Foreign key will be added later."
    end
  end
end
```
**メリット** ✅：
- 単一のマイグレーションファイルで完結
- 実行時の状況に応じた対応

**デメリット** ❌：
- マイグレーションの冪等性が損なわれる可能性
- 正直ちょっと気持ち悪い 😬

### アプローチ2: 段階的マイグレーション
```ruby
# Phase 1: スキーマ定義 (20250409101045_create_projects.rb)
class CreateProjects < ActiveRecord::Migration[7.0]
  def change
    create_table :projects do |t|
      t.string :name
      t.bigint :customer_id, index: true
      t.timestamps
    end
  end
end
# Phase 2: 制約追加 (20250409120000_add_foreign_keys.rb)
class AddForeignKeys < ActiveRecord::Migration[7.0]
  def change
    add_foreign_key :projects, :customers, validate: false
    
    # 既存データの整合性チェック
    validate_foreign_key :projects, :customers
  end
end
```
**メリット** ✅：
- 各マイグレーションの責務が明確
- ロールバックが容易

**デメリット** ❌：
- マイグレーションファイルが増加
- 依存関係の管理がめんどい 😩

## 🎯 最終的な対応
### 1. 環境別の戦略
最終的には下記で対応しましたが、環境別にマイグレーションを分けるのは正直きもいです 🤔
```ruby
class CreateProjects < ActiveRecord::Migration[7.0]
  def change
    create_table :projects do |t|
      t.string :name
      t.bigint :customer_id
      t.timestamps
    end
    
    add_index :projects, :customer_id
    
    # 本番環境では慎重に、開発環境では柔軟に
    if Rails.env.production?
      add_foreign_key :projects, :customers, validate: false
      validate_foreign_key :projects, :customers
    else
      add_foreign_key :projects, :customers if table_exists?(:customers)
    end
  end
  
  private
  
  def table_exists?(table_name)
    ActiveRecord::Base.connection.table_exists?(table_name)
  end
end
```

## 🤔 考察：設計について
この問題は、スキーマは時間とともに進化する前提で設計すべきだなと考えさせられます。
開発初期は柔軟性を重視し、成熟度に応じて制約を強化していくように設計すべきだなと思いました。

*この記事が皆様の開発体験の向上に貢献できれば幸いです。ご意見・ご質問はコメント欄にてお待ちしております。* 💬
Djangoで共通化された入力フォーム（form_row）を作って再利用する方法

## はじめに
DjangoでWebアプリを開発する際、複数画面で入力項目をたくさん作ることはありませんか？
せっかくなら、項目名が違うだけで同じ構造なら使い回したいなと思うことはありませんか？
そこで今回は、マイページ編集やユーザー登録画面など、複数の画面で同じ見た目・構造を使い回す方法を紹介します！
この記事を読んでいただければフォームの入力項目を実装するにあたって手間やミスが少なくなるはずです！

## 実現したいこと
- **フォーム入力欄の見た目・振る舞いを共通化**し、どの画面でも統一感を持たせる
- 例: マイページ編集、ユーザー登録、パスワード変更画面などでスタイルを統一させる

## 実装コード（基本編）
### 共通部分のテンプレート（例: `partials/form_row.html`）
`partials/form_row.html`というファイルを作成して、下記のように実装すれば基本形は完成です！

```partials/form_row.html
{% load widget_tweaks %}
<div class="mb-3">
  <label for="id_{{ field.name }}" class="form-label">{{ label }}</label>
  {{ field|add_class:"form-control" }}
</div>
```

### 画面に反映させた例（例: `registration/login.html`）
下記のように`{% include "partials/form_row.html" with field=form.username label="ユーザー名" %}`
と入れてあげると、テンプレ化した入力フォームを使用できます！
内容としては、``{% include "(テンプレ化したフォームがあるところ)" with field=(入力項目名のカラム) label="(入力項目名)" %}``

```registration/login.html
<form method="post">
    {% csrf_token %}
    {% include "partials/form_row.html" with field=form.username label="ユーザー名" %}
    {% include "partials/form_row.html" with field=form.password label="パスワード" %}
    <!-- 中略 -->
</form>
```

### 反映させた画像
下記のように入力フォームを反映できました！
![入力項目テンプレ１.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4084215/cef97b42-525e-45ad-aac8-22a79117c91d.png)



## 実装コード（応用編）
ここでは、画面によって編集の可否を変える方法を紹介します！

### 共通部分のテンプレート（例: `partials/form_row.html`）
`{{ field|add_class:"form-control" }}`の末尾に`|attr:"disabled:true"`を追加すると編集ができないようにできます！
また、下記のように場合分けすることで、編集可否を使い分けできます！
ここでは、`readonly`がTrueのときに編集不可になるようにしています！

```partials/form_row.html
{% load widget_tweaks %}
<div class="mb-3">
  <label for="id_{{ field.name }}" class="form-label">{{ label }}</label>
  {% if readonly %}
    {{ field|add_class:"form-control"|attr:"disabled:true" }}
  {% else %}
    {{ field|add_class:"form-control" }}
  {% endif %}
</div>
```

### 編集可能状態の例（例: `registration/mypage_update.html`）
```registration/mypage_update.html
<form method="post">
    {% csrf_token %}
    {% include "partials/form_row.html" with field=form.username label="ユーザー名" %}
    {% include "partials/form_row.html" with field=form.email label="メールアドレス" %}
    <!-- 中略 -->
</form>
```

### 反映させた画像（編集可の場合）
下記のように入力フォームを反映できました！
![入力項目テンプレ編集可.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4084215/26176d31-a0de-4982-9eca-6a0370b04242.png)


### 編集不可状態の例（例: `registration/mypage.html`）
末尾に`readonly=True`を追加することで、フォームを編集不可にできます！
```registration/mypage.html
{% include "partials/form_row.html" with field=form.username label="ユーザー名" readonly=True %}
{% include "partials/form_row.html" with field=form.email label="メールアドレス" readonly=True %}
```

### 反映させた画像（編集不可の場合）
下記のようにフォームの項目が編集不可になりました！
![入力項目テンプレ編集不可.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4084215/92151b9d-28f3-4e2b-9e70-d987f76b135c.png)

## 終わりに
共通化テンプレートを作ることで、フォームの見た目や振る舞いを共通化できました。
これにより、修正コストの低減・保守性の向上・ユーザー体験の向上につながります！

## 備考
Djangoバージョン：4.x系想定
テンプレートエンジン：Django標準
Bootstrap 5 使用（UI整備済み）
【ざっくり用語解説】UPX（Ultimate Packer for eXecutables）について

## 概要
UPX(Ultimate Packer for eXecutables)は、実行形式のファイルやライブラリを圧縮し、サイズを大幅に削減するOSSのツール。

## サポート形式
・PE：(Portable Executable)：Windowsの.exe/.dllなど
・ELF：(linux/Unix系のバイナリ)
・Mach-O：macOSの実行ファイル
などなど

## 特徴
### 圧縮率
・一般的に50%～70%のサイズ削減が可能。Zip/Gzipよりも高い圧縮率を実現。

### 高速展開
・解答は、10MB/s以上と高速である。古いハードウェアでもリアルタイムに実行可能。

### 自己完結型実行
・圧縮後のバイナリには展開用のスタブが組み込まれ、追加ライブラリ不要で動作する。

### 拡張性
・OSSかつプラグイン機構により、独自のフォーマットの追加も可能。

## 簡単な動作原理
### スタブと圧縮
1. 元のバイナリをブロック単位で圧縮
2. 圧縮済みデータと展開用スタブを連結
3. 起動時にスタブが展開し、メモリ上で実行

## メモリとランタイム
・圧縮前と比べたメモリ使用量の増加は最小限に抑えられている。完全にオーバーヘッドがないわけではない。

## 参考文献（参照日2025年5月24日）

https://en.wikipedia.org/wiki/UPX

https://medium.com/%40shellseekerscyber/explainer-packed-malware-16f09cc75035

https://stackoverflow.com/questions/353634/are-there-any-downsides-to-using-upx-to-compress-a-windows-executable
Supabaseへの直接アクセス・API Route経由をちゃんと理解しておきたい

「ユーザーがWebアプリにログイン → Googleアカウント情報をSupabaseのデータベースに保存する」という処理は、クライアントからSupabaseへ直接アクセスする一例。

---

### 直接アクセスの流れ

1. ユーザーがブラウザでGoogleログインする

2. ログイン成功後、ブラウザ（クライアント）側のJavaScriptから`supabase.from('users').insert(...)`を実行

3. Supabaseのデータベースに直接データが保存される

→ つまり、ブラウザからSupabaseに直接アクセスする方法。

---

### API Route経由の流れ

1. ユーザーがブラウザでGoogleログインする

2. ログイン成功後、ブラウザ（クライアント）側のJavaScriptから`fetch('/api/users', { method: 'POST', ... })`を実行

3. Next.jsのAPI Route（サーバー側）でSupabaseにデータを保存

→ つまり、ブラウザ→Next.jsのAPI Route→Supabaseという流れ。

---

### どちらが良い？

- 直接アクセス: 簡単、コードが少ない（クライアントから直接アクセスする場合、SupabaseのAPIキーは環境変数にしてもブラウザに露出するため、完全には隠せない）

- API Route経由: セキュリティが良い（APIキーはサーバー側で隠せる）

---

### 結論

「ユーザーがWebアプリにログイン→Googleアカウント情報をSupabaseのデータベースに入れる」は、直接アクセスの一例。

ただし、セキュリティを重視するなら、API Route経由の方がおすすめかも。
Windows11でスクリプトが実行できないときの対処方法

WindowsのTerminalでPowerShellを使っていて、ダウンロードしてきたスクリプトを実行しようとしたところ以下のようなエラーになり、実行できませんでした。

```
PS C:\Users\toshi\uroarm> .\venv\Scripts\activate
.\venv\Scripts\activate : このシステムではスクリプトの実行が無効になっているため、ファイル C:\Users\toshi\uroarm\venv\S
cripts\Activate.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://go.microsoft.com/f
wlink/?LinkID=135170) を参照してください。
発生場所 行:1 文字:1
+ .\venv\Scripts\activate
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : セキュリティ エラー: (: ) []、PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess
PS C:\Users\toshi\uroarm>
```

いろいろと検索した結果、以下のような流れで解消できました。

Terminalを管理者モードで起動します。

起動の仕方は、スタートメニューを右クリックして「ターミナル（管理者）」をクリックして起動します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28184/777834d7-0781-4e16-92c8-54c2b1bb87d9.png)

タブに、「管理者：Windows PowerShell」と表示されたターミナルが起動します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28184/d14828b3-2b97-40b0-90e3-a2b141cd5e47.png)

これで管理者権限のあるPowerShellが起動しましたので、PowerShellの実行ポリシーを確認します。

```
Get-ExecutionPolicy
```

**Restricted** と表示されたらスクリプトの実行が制限されています。

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5

ポリシーを緩めるので、このPowerShellが実行されている間だけにしておきます。

```
Set-ExecutionPolicy RemoteSigned -Scope Process
```

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7.5

以上で、スクリプトが実行できるようになりました！
🌟 Vol.9.0〜9.11 総まとめ：Struts2 バリデーション編（実務レベルの入力チェック設計／実装／UX／Ajax連携）

本シリーズ「Vol.9.xxx」では、**Struts2における入力バリデーションの全体像**を実務目線で解説してきました。  
validate()・XML定義・国際化・UI改善・Ajax活用まで、**網羅的かつ現場で役立つ構成**でお届けしています。

---

## 📚 全13回の構成一覧（Vol.9.0〜9.11）

| Vol | タイトル | 内容の概要 |
|-----|----------|------------|
| [📘 Vol.9.0](https://qiita.com/juehara-crypto/items/263e0eb599be73681b0f) | Struts2 入力バリデーションと型変換の世界へ | シリーズ全体の導入＋基本的なバリデーションの役割を整理 |
| [📘 Vol.9.1](https://qiita.com/juehara-crypto/items/a67976acd60430fa0da6) | validate() メソッドの基本 | Struts2の王道：addFieldError + input遷移によるチェック |
| [📘 Vol.9.2](https://qiita.com/juehara-crypto/items/44fd5012bfbc809d352a) | validate() 実装編 | fielderrorタグと組み合わせた基本的な実装パターン |
| [📘 Vol.9.3](https://qiita.com/juehara-crypto/items/fd6881d2c54de07b3ae4) | XMLバリデーション定義編 | Login-validation.xmlの書き方とinput遷移との連動解説 |
| [📘 Vol.9.4](https://qiita.com/juehara-crypto/items/c82203f583b2712be395) | 条件付きチェック編 | if文＋validate()を活用した柔軟なチェックロジック |
| [📘 Vol.9.5](https://qiita.com/juehara-crypto/items/c44fae5980a5c9b40312) | fielderror表示の改善編 | UI・UX向上のための表示制御テクニック |
| [📘 Vol.9.6](https://qiita.com/juehara-crypto/items/de18b174f1740f9b3646) | i18n対応編 | メッセージリソースでの多言語バリデーション対応 |
| [📘 Vol.9.7](https://qiita.com/juehara-crypto/items/793e85ad47b981d6fbae) | 入力値の保持・再表示編 | エラー後の入力維持や初期化のベストプラクティス |
| [📘 Vol.9.8](https://qiita.com/juehara-crypto/items/b11017ca621d94599f72) | 独自バリデータ編 | FieldValidatorを拡張して共通化／再利用設計 |
| [📘 Vol.9.9](https://qiita.com/juehara-crypto/items/6df87d22d07818df5166) | 単体テスト編 | validate()やinput遷移のテストを網羅的に確認する手法 |
| [📘 Vol.9.10](https://qiita.com/juehara-crypto/items/6c042593898aa598cba4) | エラー表示のUIデザイン編 | 視認性・操作性を向上させるUIの実装テク |
| [📘 Vol.9.11](https://qiita.com/juehara-crypto/items/7d33c9cd812b37153c12) | Ajax×バリデーション連携編 | クライアント×サーバー連携でUX＆保守性を両立するハイブリッド構成 |

---

## 🧭 こんな方におすすめ

- Struts2で**業務アプリの入力フォームを開発している方**
- **input遷移とvalidate()の正しい使い方**を知りたい方
- **UI/UXの改善や多言語対応、Ajaxによるリアルタイムチェック**まで踏み込みたい方
- バリデーション処理の**再利用・拡張・テストの実践法**を押さえたい方

---

## 🛠 実装サンプルのリポジトリ

GitHub にてシリーズ実装例を公開中（順次拡充中）

🔗 [Portfolio_Bulletinboard - GitHub](https://github.com/juehara-crypto/Portfolio_Bulletinboard)

---

## 📝 編集後記

本シリーズは、Struts2バリデーションの全体像を、**現場で「使える」観点から徹底的に分解・整理**してきました。  
今後、以下のシリーズ展開も予定しています：

- ✅ Vol.10シリーズ：**Struts2のセキュリティ（CSRF／XSS／認可）**
- ✅ Vol.11シリーズ：**例外処理／ログ出力／運用保守対応**
- ✅ Vol.12シリーズ：**DB連携・トランザクション・DAO層設計**

実務で「Struts2ってどう使いこなせばいいの？」という悩みに寄り添う構成を、今後も続けていきます！

---

## 🙌 最後までご覧いただきありがとうございました！

このVol.9シリーズが皆さまの開発現場で役立つことを願っています。  
**「いいね」「ストック」「フォロー」**励みになりますので、ぜひよろしくお願いします🙇‍♂️
ブラウザのセキュリティ対策の整理メモ

## はじめに
CORS・CSP・Same-Origin Policyについて、理解が深まったため整理する。

---

## 大前提の話

ブラウザは、HTMLの`<form>`タグやJavaScriptの`fetch()`などを使えば、別のサイトへ自由にリクエストを送ることができる。

```html
<form action="https://victim.com/api/update" method="POST">
  <input type="hidden" name="data" value="attack">
  <input type="submit" value="送信">
</form>
```

このように、攻撃者のサイトからでも、他のサイトに対してPOSTリクエストを送ること自体は可能。

---

## fetch() によるリクエストではレスポンスの制限がかかる（Same-Origin Policy）

JavaScriptの`fetch()`を使って他のオリジンにリクエストを送ると、レスポンス自体は返ってくるが、ブラウザはそれをJavaScriptから読めないように制限する。

これは Same-Origin Policy（同一生成元ポリシー） によるもので、オリジン（プロトコル、ドメイン、ポート）が異なるとレスポンスの中身を読み取れないというセキュリティルール。

---

## CORS（Cross-Origin Resource Sharing）で読み取りを許可できる

サーバ側がレスポンスヘッダーに以下のように記述すると、特定のオリジンからのレスポンス読み取りを許可できる。

```http
Access-Control-Allow-Origin: https://frontend.example.com
```

この場合、`https://frontend.example.com` 上のJavaScriptからの`fetch()`でのみ、レスポンスの中身を扱えるようになる。

---

## CSP（Content-Security-Policy）はページが使えるリソースを制限する

`CSP`は、そのWebページでどこから何を読み込めるかを制御するレスポンスヘッダー。

例えば、以下のようなヘッダーを返すと、

```http
Content-Security-Policy: script-src 'self';
```

この場合、そのページは自分自身のドメイン（self）からのスクリプトだけ読み込みを許可し、他ドメインのスクリプトはブロックする。

同様に、`style-src`, `img-src`, `connect-src` などでCSSや画像、AJAX通信先を制限できる。

---

## CORSもCSPも「レスポンス後に効くセキュリティ」

CORSやCSPは、いずれもブラウザがレスポンスを受け取った後に適用されるセキュリティ機能。
つまり、「リクエストを送ること」自体を防ぐわけではない。
リクエスト内容の検証をするには、サーバーサイドでの検証が必要。

---

## CSRFトークンによる検証
セッションベースでCSRFトークンを発行・検証する仕組みが有効
* フォームの作成時にトークンをセッションに保存
* フォーム内に hidden input で埋め込む
* サーバー側でトークンの一致を検証

こうすることで、「正しいフォームを通じて送信されたリクエスト」であることを保証できる。

## まとめ
ブラウザには、CORSやCSP、Same-Origin Policyといったデフォルトのセキュリティ機構が備わっており、クロスオリジンの通信や不正なスクリプトの実行などに対して制限がかかる。

ただし、これらはあくまで「レスポンスをどう扱うか」に関する対策であり、「リクエストが正当なものかどうか」を検証する仕組みではない。

そのため、フォーム送信やAPI呼び出しにおけるリクエスト内容の検証するには、サーバーサイドでのセキュリティ対策が必須となる。
UnityAIでゲームを作ってみる - Day1 -

# UnityAIでゲームを作ってみる - Day1 -

## 最近話題（？）の[Unity AI](https://unity.com/ja/products/ai)で期間を決めて、ホラーゲームを作ってみようと思いました。 

## なんで？
個人のゲーム開発でAIを使わない手はありません。
もちろん異論はあると思いますが、わたしは体感生産性250%くらいになりました。

マルチタスクなどできない人間だったのに、今ではVSCodeでCopilotが動いている間にUnityを動かして、アイディアに詰まったらブラウザのGeminiに相談しながらYouTubeで動画を観られるような状況です。

## まだ無料期間らしい
今のところ、紆余曲折を経てUnityが最適解だと思っているので、検証するのは最早義務です。
ましてや正式リリースまでは無料とあればなおさら。

## とはいえ…
とはいえ、心血注いでいるプロジェクトで採用するのは不安があります。
なので、悪く言えば「完成しなくてもいい」ようなプロジェクトでどの程度のものかお手並み拝見といきます。

とりあえず7日分程度の工数を見積もって、その間にどれだけのものができるのか、それを記録していこうと思います
パケット交換通信について

パケット交換通信について

今回は、自分が書籍で学んだパケット通信をアウトプットしたいと思います。

パケット交換通信とは、パケット呼ばれる単位で細分化されたデータを使い通信をすること。

元々は、回線交換通信が用いられており、これは通信先のコンピュータ間と回線を設定し、回線を接続（コネクションを確立）させ、通信を行う手段。しかし、これでは、その回線を占有していることになり、複数のコンピュータが繋がれたネットワークだと回線待ちが生じてしまう。

そこでデータを細分化して、占有が起こらなくすることを目的にしたのがパケット通信。

パケッドにはヘッダと呼ばれる、領域があり、そこに送信元のアドレスと送信先のアドレスを書いておく。

アドレスというのは、IPアドレス（階層型）とMACアドレス（NICにより唯一性）がある。

パケットの交換にはルータを介して行われ、ルーターはバッファと呼ばれる記憶空間にパケットを記憶し、待ち行列を作る。ルータがパケットのヘッダ情報を元に、データを送る。ちなみにバッファはキュー（FIFO）。
Next.js で作った静的サイトをmainブランチを汚さずに GitHub Pages に公開したい

毎度ハマるのでメモになります。

# やること/ゴール

- Next.js で静的サイトを吐く
- 出力されたファイルは `main` ブランチには置かない
- GitHub Pages が 静的サイトジェネレータ Jekyll を使おうとするが静的サイトを吐くのは next.js なので使わない
- 今回は [llm-cost-estimator](https://kaibadash.github.io/llm-cost-estimator/) を例として扱います
    - `llm-cost-estimator` は任意のリポジトリ名に変更してお試しください

# GitHub の Pages 設定

![pages](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21799/d45c6d26-ed4f-4289-8c86-40506c292178.png)

このようにしました。

# Next.js で静的サイトを吐く

何がともあれ next.js と GitHub pages の環境を作ります。

```bash
npx create-next-app llm-cost-estimator --typescript
npm install gh-pages --save-dev
```

config を設定します。`output: 'export'` で静的サイトを吐くようにします。
今回は `docs` ディレクトリに吐くようにしています。

```next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  /* config options here */
  ...(process.env.NODE_ENV === 'development'
    ? {}
    : {
        output: 'export',
        basePath: '/llm-cost-estimator',
        assetPrefix: '/llm-cost-estimator',
        distDir: 'docs',
      }
  ), // 略
```

ビルドしてサイト生成を確認しておきましょう。差分が大量になるので docs 配下は GitHub 管理下にしないようにします。

```bash
$ npm run build
$ ls docs/
_next       404.html    favicon.ico file.svg    globe.svg   index.html  index.txt   next.svg    vercel.svg  window.svg
$ echo "docs/*" >> .gitignore
```

# Jekyll を無効にしてデプロイする

あとはこれらを GitHub Pages に置くだけなのですが、標準だと Jekyll がビルドしようとしてエラーになるため、 jekyll を無効にします。

```bash
$ touch .nojekyll
```

root に .nojekyll を置きます。

```package.json
{
  "name": "llm-cost-estimator",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "deploy": "next build && touch docs/.nojekyll && gh-pages -d docs -b gh-pages"
  },
```

:memo: `touch docs/.nojekyll` はいらないかも…

デプロイのコマンドを追加します。
`gh-pages -d docs -b gh-pages` は docs の内容を `gh-pages` ブランチにまるっと上書きするぞ！というコマンドです。
デプロイします。

```bash
$ npm run deploy

# 略
Route (app)                                 Size  First Load JS
┌ ○ /                                    3.46 kB         105 kB
└ ○ /_not-found                            977 B         102 kB
+ First Load JS shared by all             101 kB
  ├ chunks/4bd1b696-52a6696c08e3276c.js  53.2 kB
  ├ chunks/684-836db4fb37c5abfa.js         46 kB
  └ other shared chunks (total)          1.99 kB


○  (Static)  prerendered as static content

Published
```

このようになれば GitHub へのリクエストは成功です。
`Published` というとサイトが出来上がったと思いがちですが、このあと GitHub Actions でデプロイが実行されます。

![deploy](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21799/62f61239-fbfd-4479-8014-0de07dc5daf9.png)

GitHub の Actions を見てみましょう。
Jekyll が実行されていないことを確認。

# サイトの表示を確認しましょう！

https://kaibadash.github.io/llm-cost-estimator/

問題なければ push して作業は終わり。お疲れ様でした。
皆さん、私はhtmlとcssだけを使って、このWeb UIを作りました。

皆さん、私はhtmlとcssだけを使って、このWeb UIを作りました

![Screenshot_20250522_172803.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4096274/accd2800-6359-4ca1-9269-26af10cfaecd.png)

純粋なhtmlとcssの小さなコードです。もしコードが必要な人がいたら教えてください。読んでくれてありがとう。
もし十分な愛があれば、私はさらに多くの愛を生み出すだろう。

https://github.com/asianprogrammer/Fashion
「米の値段と随意契約の関係を教えて下さい。」をAI先生に聞きました。  

・最近の話題です。難しいです。

# (本日の)ChatGPT先生へ
#### 質問リスト
```
# 質問リスト
1. 米の値段と随意契約の関係を教えて下さい。  
2. 実際の例を教えて下さい。  
3. 会計法の何条と関係がありますか。  
4. 随意契約理由書のひな形（フォーマット）を教えて下さい。  
5. 以上の事を、前農水大臣、新農水大臣はご存知でしたか？ご存知ですか？  
6. 学校給食法第10条第2項は何ですか。  
7. 学校給食法第10条第2項に基づく政府の実際の対応や備蓄米放出の実例を教えて下さい。  
8. 私の質問をMarkdown形式でリスト化して出力して。Markdown形式でリストからアスタリスクは削除して。1行目に、# 質問リスト の文字を出力して。最後の質問も追加して下さい。追番を追加して下さい。Markdown形式で。  
9. Markdown形式で。最後までお願いします。
```

#### (以下回答抜粋)
>米の値段と随意契約の関係については、特に政府の米の買い上げや調達制度と関連して説明されることが多いです。以下、ポイントを整理します。
...
>ご希望があれば、実際の例（農水省や地方自治体の契約）も紹介できます。
>🏫 事例1：豊中市の学校給食用米の随意契約...
>🏢 事例2：高槻市の臨時支援米の随意契約...
>🔬 事例3：茨城県の研究用米の随意契約
>まとめ
>ご希望があれば、他の地域や具体的な契約内容についてもご紹介できます。
>現在、日本政府は米の価格高騰に対応するため、備蓄米の放出方法を「競争入札」から「随意契約」に変更する方針を打ち出しています。この政策転換は、米価の安定化と消費者への迅速な供給を目的としています。
...

以下省略


# Gemini先生へ

# copilot先生へ

# いつもの? sympyの実行環境と 参考のおすすめです。
[(テンプレート)](https://qiita.com/mrrclb48z/items/00dd08b0317069be9342)

https://qiita.com/mrrclb48z/items/b6351b48e47bcf6265c0

# いつもと違うおすすめです。
某有名企業のセキュリティエンジニアから学ぶSNSのリスクヘッジ術

# 事の出来事

5/22、とあるXユーザーが投稿したポストについてエンジニア界隈で物議を醸した。

内容は、
**勤務先、顔出し、本名**を公開している某有名企業所属のセキュリティエンジニアが、
Xで卑猥なポストしたり、裏垢女子に説教していることだった。

とあるユーザーは、当該Xユーザーをとりあげて「当該Xユーザと同じチームにいるなら退職するわww」と発言して、共感したユーザーが多数で結果的に80万インプ以上ついた。（当該ポストは削除済み）


# 肝心のポスト内容について

さて、おまたせいたしました。
当該Xユーザの肝心のポストはこちらです。

![1A2AE1D6-6DAF-4D0D-AD31-9BB0CC3CD072 2.JPEG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3943636/a84cca45-53c4-4db5-b93f-0ba99dc0283d.jpeg)
![52AE1690-89A4-4AFC-9A0B-188C92644E07.JPEG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3943636/f1044401-03f1-471e-8be7-5419aaeeafe4.jpeg)





変態すぎてドン引きした人多数いるだろう。

驚くことに、
<font color="red">上記ポストを勤務先・顔出し・本名公開のアカウント</font>で投稿しているということ。

いい歳して有名企業のセキュリティエンジニアでありながら、
情報リテラシーが皆無という矛盾があります。

Qiitaにいるエンジニアのほうが、当該Xユーザーより優秀です。

# 上記の出来事から学ぶSNSのリスクヘッジ術

私からSNS（特にX）で注意すべき点は、

- 勤務先を公開するなら、会社の看板背負う覚悟を持つこと
- 勤務先を公開するなら、会社の宣伝ポストしかしないこと
- 勤務先を公開するなら、会社にポストのチェックしてもらうこと
- 勤務先を公開する場合、炎上したら自分だけではなく、勤務先に迷惑かかる自覚を持つこと
- プロフに「個人の見解です」という中途半端な予防線を張らないこと
- 上記を守れない場合は、勤務先を公開しないこと

です。



ここから、上記出来事より実践すべきSNSの運用について紹介します。

- ちょっと攻めた発言したいなら、匿名垢（アイコンはAIがおすすめ）がおすすめ
- 本名顔出しするなら、不特定多数に見られているつもりでポストすること
（スクショ撮って晒すXユーザーもいるので）

です。

上記を参考にSNSの発信に気をつけながら、運用してください。
.NETってなに？ C#との違いを理解する

# はじめに
C#を学んでいくに当たって、.NETとは？と疑問に感じたので自分なりに調べたものをまとめました。

# 結論
`C#`と`.NET`は別物です。
`C#`はプログラミング言語で`.NET`は実行環境です。
公式では「アプリケーションプラットフォーム」という言い方をしています。
アプリケーションプラットフォームとはプログラミング言語とライブラリがセットになったものとされています。

# .NETとは
`C#`ではソースコードを実行する前にコンパイルをする必要があります。
`C#`で書いたソースコードをコンパイルすると中間言語（ILコード）が作成され、`.NETアセンブリファイル`に保存されます。
その`.NETアセンブリファイル`を`.NETランタイム`が実行します。

つまり`.NET`とは`C#`などで作成したアプリケーションを実行するための環境のこととも言えます。


イメージ
![スクリーンショット 2025-05-24 9.22.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3813857/65f6ec75-cb70-4911-9389-0b1434de09b1.png)





`.NETランタイム`では`C#`以外にも`F#`や`Visual Basic`という言語もサポートしています。

`C#`と`.NET`の関係を例えるなら
- `C#` => 楽譜
- `.NET` => ピアノ
みたいな感じですかね。

# .NET SDKとは
`SDK`（Software Development Kit）のことで、`.NET`での開発で必要なものがまとまったもので以下のようなものが含まれています。
- .NETランタイム（プログラム実行用）
- コンパイラー（C#コードを中間言語に変換）
- 開発ツール（dotnetコマンドなど）
- 基本ライブラリ（文字列操作、ファイルI/Oなど）

`C#`で開発するのであれば必ず`.NET SDK`をインストールして環境を構築していきます。

# .NETの歴史
かつて.NETには複数の実装がありました：
- **.NET Framework**：Windows専用のアプリケーションプラットフォーム
- **.NET Core**：クロスプラットフォーム対応のアプリケーションプラットフォーム
- **Mono**：軽量・モバイル向けのアプリケーションプラットフォーム

`.NET 5`からこれらが統合されて単に`.NET`となっています。

# .NETのフレームワーク
`.NET`上で作成する様々なアプリモデル（Webアプリ、ゲーム開発、デスクトップアプリなど）に対応したフレームワークが用意されています。

| カテゴリ | フレームワーク名 | 説明 |
|----------|------------------|------|
| **Web** | ASP.NET Core | サーバー側ロジックを作成するためのフレームワーク |
| **Web** | ASP.NET Core MVC | Web ページまたは Web API のサーバー側ロジックを作成するためのフレームワーク |
| **Web** | ASP.NET Core Razor Pages | サーバーで生成される HTML を作成するためのフレームワーク |
| **Web クライアント** | Blazor | ASP.NET Core の一部。2つのモード（サーバー側通信またはWebAssembly）でブラウザのDOM操作が可能 |
| **デスクトップ** | .NET for Mac | ネイティブ UI と API アクセスを使って、Mac デバイス用のアプリを構築 |
| **デスクトップ** | WinForms | Windows で "battleship gray（鈍いグレー）" スタイルのアプリケーションを作成 |
| **デスクトップ** | Windows Presentation Foundation (WPF) | 動的デスクトップアプリケーション構築。豊富なアニメーション機能を提供 |
| **モバイル** | .NET for Android | ネイティブ UI と API アクセスを使って、Android デバイス用のアプリを構築 |
| **モバイル** | .NET for iOS | ネイティブ UI と API アクセスを使って、iOS と iPadOS 用のアプリを構築 |
| **マルチプラットフォーム** | .NET MAUI | 1つの共有コードベースから iOS、Android、Mac、Windows 用のアプリを構築 |

# まとめ
`.NET`とは「プラットフォーム全体」の名前

- プログラミング言語（C#、F#、Visual Basic）
- ランタイム（実行環境）
- 開発ツール（SDK、コンパイラー）
- ライブラリ群（Base Class Library）
- フレームワーク（ASP.NET Coreなど）

Javaと比較すると例えるとこんなイメージ
```
Java = プラットフォーム全体の名前
├── Java言語
├── JVM（実行環境）  
├── JDK（開発キット）
└── Spring等のフレームワーク

.NET = プラットフォーム全体の名前
├── C#言語
├── .NETランタイム（実行環境）
├── .NET SDK（開発キット）
└── ASP.NET Core等のフレームワーク
```

## 参考資料
https://learn.microsoft.com/ja-jp/training/modules/dotnet-introduction/

https://learn.microsoft.com/ja-jp/training/modules/dotnet-introduction/2-what-is-dotnet

https://dotnet.microsoft.com/ja-jp/learn/dotnet/what-is-dotnet

https://qiita.com/kaonyao89/items/48c5dd83efb364c8a5f7
速報！glitchサービス終了？？！

# 速報！Glitchサービス終了？？！
こんにちは！名無しのnです
🚨 **開発者の間で愛され続けたGlitchが終了！？** 🚨  
多くのクリエイターやエンジニアが利用していた**Glitch**が、大きな変革を迎えることが発表されました。このプラットフォームの終了が意味することとは？そして、今後の代替サービスは？詳細を解説します。

---

## 📌 Glitchとは？
Glitchは、ウェブ開発者向けのオンラインコーディング環境であり、**Node.jsアプリや静的サイトを簡単に作成・共有できる**画期的なサービスでした。初心者から上級者まで幅広い開発者が利用し、ブラウザ上で手軽にコードを試したり、共同作業を行うことができました。

Glitchの魅力として、以下の特徴が挙げられます：
- **コードのリアルタイム編集** - 変更を即座に反映！
- **共有・コラボレーション** - チームで簡単に共同開発可能。
- **無料でプロジェクトホスティング** - Node.jsアプリや静的サイトを気軽に公開。

しかし、その利便性を誇るGlitchが今回、大きな決断を下しました。

---

## ⏳ なぜ終了するのか？
公式ブログによると、**Glitchは今後、大幅な変更を迎える**ことが発表されています。この決定の背景には、いくつかの理由があるようです。

### 💰 収益化の課題
Glitchは主に無料で提供されていたため、**持続可能なビジネスモデルを確立することが困難だった**とのこと。運営コストが増加し、サービスの維持が難しくなっていたようです。

### 🔥 競争の激化
近年、**ReplitやCodeSandbox、Vercelといった競合サービスが台頭**。これらのサービスはより高度な機能を提供し、ユーザー層の拡大に成功しています。Glitchはこの競争の中で苦戦を強いられていました。

### 🛠 技術的な課題
開発者のニーズに応じた**新機能追加やインフラ整備が困難**であり、サービスの維持が徐々に厳しくなっていた模様です。

---

## 🔍 今後の代替サービスは？
Glitch終了に伴い、多くの開発者は代替サービスを模索しています。現在、注目されている代替プラットフォームをいくつか紹介します。

| サービス名 | 特徴 |  
|-----------|------------|  
| **Replit** | Webベースの開発環境。豊富な言語サポートとコラボ機能が強み。 |  
| **CodeSandbox** | フロントエンド開発に特化したサービスで、高速なプロトタイピングが可能。 |  
| **Netlify** / **Vercel** | 静的サイトやサーバーレスアプリを簡単にホスティングできるプラットフォーム。 |

---

## 🗣 SNSの反応は？
Glitchの変更発表後、SNS上では驚きや悲しみの声が飛び交っています。以下のような投稿が話題になっています。
## 🎯 まとめ
Glitchの変革は、開発者コミュニティにとって大きな転換点となります。**代替サービスの検討が急務となる一方で、今後の公式発表にも注目が必要**です。

### 📢 あなたの意見は？
Glitchの思い出や、次に使いたいサービスについてコメントで教えてください！

📌 **出典:**  
- [Glitch公式ブログ](https://blog.glitch.com/post/changes-are-coming-to-glitch/)  

🚀 [Qittaの記事へ戻る](https://qiita.com/)
【AIエンジニア向け】RAGとMCPサーバーの違いをわかりやすく解説



## はじめに

近年、AIモデルに外部知識を活用させる技術が注目されています。「RAG」と「MCPサーバー」は、情報取得と回答生成を高度に連携させる手法として使われますが、その違いを理解して使い分けることが重要です。

この記事では、両者の特徴・仕組み・活用シーンの違いを整理し、現場での適用イメージを解説します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3937496/35d0fe9a-fb82-4949-90ca-01ee74c271a2.png)
※RAG(検索拡張生成)です


## RAG（Retrieval-Augmented Generation）

### 概要
RAGは「検索強化生成」とも呼ばれ、AIモデルの回答に対して大量のドキュメントや知識ベースから関連情報を検索し、それをもとに回答を生成します。

### 仕組み
1. ユーザーのクエリを受け取る
2. 事前に用意・インデックス化した文書やデータベースから関連情報を検索
3. 検索結果をAIモデルの入力に加えて回答を生成

### 特徴
- 検索フェーズと生成フェーズが明確に分かれている
- 大量の静的データから効率的に関連情報を取得可能
- 主にオフラインでの文書準備やインデックス構築が必要

### 利用シーン
- FAQチャットボット
- 企業内ナレッジベース検索
- 文書要約やリサーチサポート

## MCPサーバー（Model Context Protocol）

### 概要
MCPサーバーはAIモデルと外部データソースをリアルタイムに連携するための通信プロトコルおよびサーバーです。

### 仕組み
1. AIモデルが追加のコンテキストが必要な際にMCPサーバーへリクエスト
2. MCPサーバーはローカルファイル、API、Web検索など多様な情報源から必要なデータを取得
3. 取得情報をモデルに返し、生成プロセスを補助

### 特徴
- リアルタイムで動的な情報連携が可能
- 多様な情報ソースと連携できる柔軟性
- モデルが必要に応じて能動的に外部情報を取得できる

### 利用シーン
- 最新情報を反映するチャットボット
- 社内ドキュメントや外部APIを連携するエージェント
- 複雑な業務フロー内での情報取得・生成連携

## RAGとMCPサーバーの比較

| 比較項目 | RAG | MCPサーバー |
|---------|-----|------------|
| **情報取得のタイミング** | 回答生成の前段階（検索フェーズ） | 回答生成中にモデルからの要求に応じて取得 |
| **情報ソース** | 主に事前に用意された文書やデータベース | ローカルファイル、API、Web検索など多様 |
| **運用形態** | 静的で準備が必要 | 動的かつリアルタイム連携 |
| **技術的特徴** | 検索＋生成モデルの組み合わせ | プロトコルによる双方向通信サーバー |
| **主な活用例** | 大規模ドキュメント検索、FAQ対応 | リアルタイム情報反映チャットボット、業務連携AIエージェント |

## まとめ

**RAG**は事前準備された情報を効率的に検索し回答を補強する技術であり、大量の文書を高速検索したい場合に適しています。

**MCPサーバー**はAIモデルと多様な外部情報源をリアルタイムに連携する仕組みで、最新のデータやAPI連携が必要なケースに強みがあります。

両者は補完的な関係にあり、状況に応じて使い分けることでより高度で実用的なAIサービスを構築できます。

## 参考リンク

- [Retrieval-Augmented Generation (RAG) について](https://arxiv.org/abs/2005.11401)
- [Model Context Protocol（MCP）ドキュメント（Azure AI Foundry）](https://learn.microsoft.com/azure/ai-foundry/mcp-overview)
「Docker」で簡易的な「Webサーバ」を構築する

# はじめに #
こんにちは、Elieと申します。
今回はコンテナ技術である**Docker**を用いて簡易的なWebサーバを構築する手順をご紹介します。
まず、なぜDockerで構築するのかについてですが、**構築の速さ**や**環境の再現性**などでDockerは優れています。
例えば、**docker run** というコマンド一つでコンテナを構築することが可能ですし、複数コンテナを構築したい場合は**docker-compose**を利用すること簡単に制御可能です。
今回はそういった理由からDockerを用いた構築を採用しました。

# 実行環境 #
・ホストOS：Ubuntu 22.04.5 LTS（VirtualBox上に構築）
・Dockerバージョン：28.1.1
現在のUbuntuのバージョンを確認したい場合は以下のコマンドで確認可能です。
```
$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy
```

Dockerのバージョンは28.1.1です。
Dockerのバージョンは以下のコマンドで確認可能です。
```
$ docker version
Version: 28.1.1
.
.
.
```

# 今回の構成（LEMPとは） # 
今回は、LEMP（Linux + Nginx + MySQL + PHP）構成でWebサーバを構築します。

この構成は非常に多くのWebアプリケーションで使われており、すべてオープンソースのためコストゼロで導入できるのがメリットです。

各コンポーネントの役割は以下のとおりです。

コンポーネント/役割
Nginx/Webサーバ。HTTPリクエストを受け付ける。
PHP/サーバサイドの処理、HTMLページの生成。
MySQL/データベース管理。ユーザ情報などを保持。

それでは早速構築していきましょう！

# プロジェクト構成の準備 #

まず以下のコマンドを実行してください。
```
$ mkdir docker-lemp
$ cd docker-lemp
$ mkdir nginx php mysql
$ touch docker-compose.yml
$ touch nginx/default.conf php/index.php
```
すると以下のようなディレクトリ構成になります。
docekr-lemp/
├── docker-compose.yml
├── nginx/
│   └── default.conf
├── php/
│   └── index.php
└── mysql

docker-compose.ymlは複数コンテナを同時に起動させる際に必要なファイルです。
nginx下のdefault.confはNginxを設定するファイルです。
php下のindex.phpは今回は動作確認のためのファイルです。

次に以下のコマンドを実行し、docker-compose.ymlを編集します。
```
$ vi docker-compose.yml
上のコマンド実行後　i　と入力し、INSERTモードへ移行後以下の文字を記述。
version: '1.0'
services:
  nginx:
    image: nginx
    ports:
      - "8080:80"
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
      - ./php:/var/www/html
    depends_on:
      - php

  php:
    image: php:8.1-fpm
    volumes:
      - ./php:/var/www/html

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: myapp
      MYSQL_USER: user
      MYSQL_PASSWORD: userpass
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:
```
記述したら、Escキーを押してコマンドモードに移行して、:wqと入力後Enterを押して編集終了。
内容を確認したい場合は以下のコマンドを実行。
```
cat docker-compose.yml
```
次にNginx設定ファイルの記述です。(default.conf)
```
server {
    listen 80;
    server_name localhost;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass php:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

```
次にphpディレクトリ以下のindex.phpを編集します。
```
vi php/index.php
<?php
phpinfo();
?>
```
次にコンテナの起動です。
docker-lempディレクトリで以下のコマンドを実行
(pwd　で現在のディレクトリを確認できます)
```
$ docker-compose up -d
```
すこし時間がかかると思いますが、完了後以下のコマンドを実行してください。
```
$ docker ps
```
このコマンドで現在実行されているコンテナを一覧表示します。
Nginx,PHP,MYSQLの３つのコンテナが動作していることを確認してください。
成功していればSTATUSでUPと表示されていればOKです！

そしてWebブラウザで以下のように入力してください。
```
http://localhost:8080
```
これで接続できていればLEMP構成のWebサーバの構築は完了です。

どうだったでしょうか？
初めてDockerを触る方やWebサーバを構築する方には難しく感じたと思います。しかし、このLEMP構成は前述したように非常に多くの場面で使われています。例えば、社内の在庫管理や売り上げ管理といったバックオフィス向けの用途であったり、病院や美容室などの予約・顧客管理システムなどです。この構成が基盤となり様々な用途に発展させることができます。
次回は、この構成をより実用的に発展させたものやセキュリティ設定編などの続編を投稿する予定です。
興味がある方は是非フォローをお願いします！


🙌 最後まで読んでいただきありがとうございました！
【保存版】Excel VBAをPythonに変換するためのChatGPTプロンプト集

# Excel VBA → Python 変換テンプレート集（ChatGPT活用）

業務で使っていた Excel VBA マクロを Python に移行したい方へ。
ChatGPTを使って効率よく変換できるよう、「VBA → Python」のプロンプトテンプレートをGitHubにまとめました。

[VBA(変換元)]
```vba
Range("A1").Value = "Hello"
Range("A2").Value = Cells(1, 1).Value
```
↓
[Python(変換先)]
```python
from openpyxl import load_workbook

wb = load_workbook("sample.xlsx")  # Excelファイルを開く
ws = wb.active                     # アクティブなシートを選ぶ

ws["A1"] = "Hello"                 # A1セルに文字を入れる
ws["A2"] = ws["A1"].value          # A1の値をA2にコピー

wb.save("sample.xlsx")            # ファイルを保存する
```

---

## 🔧 こんな方におすすめ
- VBAマクロの保守から Python化を進めたい
- ChatGPTの使い方がまだよくわからない
- Python初心者だけど、実務で役立てたい
- プロンプトの書き方に悩んでいる

---

## 📚 内容構成

以下のようなVBA処理ごとに、ChatGPTへの依頼文（プロンプト）とPython変換例を掲載しています。

- 01：セルの操作
- 02：ループと条件分岐
- 03：シートの追加・削除・名前変更
- 04以降：ファイル保存、行列操作、書式設定、グラフ作成 etc（順次公開予定）

---

## 📌 GitHubリポジトリはこちら

🔗 https://github.com/mnrj-vv-w/vba-to-python-prompts

スター・改善案・PR大歓迎です！

---

## 💬 補足

すべて `openpyxl`ベースで構成していますが、今後 `pandas` 版や `GUI処理（Tkinter）` も拡充予定です。  
「こういう処理の変換もほしい！」というリクエストも大歓迎です 🙌

---

#Python #VBA #Excel #ChatGPT #openpyxl #業務効率化
テストコードの復習

equire 'rails_helper'
→これはアールスペックの設定を読み込むための記述 　require → 外部のライブラリやファイルを読み込むためのメソッド
　’　’　→ 読み込むものをシングルコーテーションで囲んで書く 
RSpec.descride 今回のテスト名（任意）、 type: :model do end
RSpec.descride  do end → expect内に入れたい内容を記述する　
type : :model do → RSpecがモデルのテストだと認識してくれる　自動的にモデルのテストをする際の色々便利機能が追加される  
Describe　’テスト名(任意)’ do end  →この中にテスト内容を書く context ’任意名’ do end → 開発者の可読性を上げるためのブロック　必須ではないがわかりやすくなるので書いて置くべし
Expect（テストに使う中身）.to be_valid → ここにテスト内容を書く　（）内に使う値を入れる　先にRSpec .describeで作成しているものがあれはそれを言いれる　極論この中に毎回id = 1 みたいなのを入れても動くが長くなりすげるので非推奨　このコードの上に　＠〇〇＝’’ を入れるとその内容のみ変更できる
UbuntuからWindowsへリモートデスクトップ接続

## 目的
ThinkPadのノートパソコンを購入した為、普段使いしているUbuntuからリモートデスクトップ接続できるように設定をしましたのでその過程を備忘録として残します。

## Windowsのバージョン
運よくProが入ってました。
Homeでは公式でない方法を使わないとリモートデスクトップが使用できません。
(中国で購入したため中国語です。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/a5d3d510-2282-4945-a3be-3701117df99a.png)


## Windows側(被接続)
ipconfigにてIPアドレスを確認。

Win + R → sysdm.cplから受け入れを許可する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/96ba82ff-8744-4ee4-99e8-ac6d1ecb7155.png)

## Linux側
### remminaの導入
以下を実行。
```
sudo apt update
sudo apt install remmina remmina-plugin-rdp
```
### Windows端末の情報を登録
この画面で共有フォルダを設定しておくとファイルが共有可能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/c653c414-b2e6-4b0f-8e0d-a7a93fb7448c.png)

WindowsからUbuntuのファイルを参照したい場合は以下の共有フォルダから開く。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4054974/e6f496c9-80c1-444c-9ede-19b64646ae46.png)

### 注意
ThinkPadにログインした状態でないとUbuntuから接続ができない。
一度切断して再接続をしたい場合は一度ThinkPadにログインしないといけない模様。
Geminiでフルートを使う魔法少年を描いてみた。

# 概要

Geminiでフルートを使う魔法少年を描いてみました。

# 実装

プロンプトと実行結果は以下の通りでした。

```
聖なるフルートを使う魔法少年を描いてください。
```

![聖なるフルートを使う魔法少年_20250524.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3192024/1204cea8-0e7a-4546-b015-bfc06eb849a2.png)


# まとめ

何かの役に立てばと。
UART（シリアル）通信でオーバーランエラーが発生する

# 受信割り込み処理が終わる前に、次のデータを受信してしまっている可能性があります
割り込み処理では要因のクリアが重要になってきますが、要因クリアのタイミングに気をつけてください。受信割り込み処理中に次のデータを受信したと仮定した場合、要因クリアのタイミングによっては新しく受信したデータの要因までクリアされてしまい、新しく受信したデータの割り込みが入らない場合があります。

# 受信割り込みよりも優先度の高い割り込みが入ってしまった
受信割り込みの優先度は通常であれば一番高くていいです。

# 結論、通信速度が速い場合に割り込み処理で受信すると取りこぼす可能性が高くなりますのでDMAを使いましょう
UARTはDMAを使わないと上手く行かないケースが経験上殆どです。
DMAは単なるメモリ転送にとどまらず、あらゆる可能性を秘めたデバイスですので使いこなしてみましょう！
[初心者向け] IPアドレスとDNP



## はじめに

IPアドレスとDNPの基礎的なことについてまとめました。
自分の備忘録として書いています。

## IPアドレスとは

IPアドレス（Internet Protocol Address）とは、インターネットに接続された機器（パソコン、スマホ、サーバーなど）に割り当てられる「住所」のようなものです。

インターネットでページを閲覧したり、メールの送受信を行うには、データの送信元や送信先を識別しなくてはなりません。

郵便物を送るときに住所が必要なように、インターネット上で、通信相手を特定するために必要な番号が「IPアドレス」です。

## グローバルIPアドレス・プライベートIPアドレス
IPアドレスは用途と場所によって、グローバルIPアドレスとプライベートIPアドレスの２つに分けられます。

グローバルIPアドレスとは、インターネットで使用されるIPアドレスのことで、世界中で重複がないようにプロバイダーによって割り当てられます。

プライベートIPアドレスとは、オフィス内や自宅などの特定のネットワークで利用される、パソコンなどのデバイスに割り振られたIPアドレスです。

電話番で例えるとグローバルIPアドレスが、外線番号、
プライベートIPアドレスは、内線番号のようなものです。

#### 関係性

スマホで自宅のWi-Fiを使って、インターネットに接続する場合、

Wi-fiのルーターがインターネットへの窓口としてグローバルIPを持ち、スマホはプライベートIPアドレスを持ちます。

スマホに割り当てられたプライベートIPアドレスを経由して、グローバルIPアドレスを持ったルータを通し、インターネットに接続する仕組みです。

## IPアドレスとDNSの関係

インターネットを使っていると、私たちは普段「www.google.com」や「www.yahoo.co.jp」等を使ってWebサイトにアクセスしています。

ここの「www.google.com」や「www.yahoo.co.jp」といった文字列は「ドメイン」と呼ばれます。

IPアドレスの数字は覚えにくく扱いずらいため、ドメインの文字列を利用しています。

わたしたちが認識しやすいように文字列であるドメインが利用されますが、コンピュータ同士は「IPアドレス」によって通信しているため、ドメインを利用してインターネットに接続する場合は、ドメインをIPアドレスに変換する必要があります。

ドメインをIPアドレスに変換する仕組みのことをDNS（Domain Name System）と言います。
DNSのサービスを提供するサーバーはDNSサーバーと呼ばれます。

DNSの仕組みは、登録されている氏名がわかれば電話番号がわかる電話帳のようなものです。

電話帳の氏名　→　人が覚えやすいように表示されたドメイン（例：www.example.com）
電話番号　　　→　機械が理解できるIPアドレス（例：93.184.216.34）

DNSという電話帳のようなシステムを用いると、ドメインからIPアドレスが紐づけられ、明らかになり、インターネットに接続することができます。




#### 参照
[イラスト図解式 この一冊で全部わかるWeb技術の基本](https://www.amazon.co.jp/%E3%82%A4%E3%83%A9%E3%82%B9%E3%83%88%E5%9B%B3%E8%A7%A3%E5%BC%8F-%E3%81%93%E3%81%AE%E4%B8%80%E5%86%8A%E3%81%A7%E5%85%A8%E9%83%A8%E3%82%8F%E3%81%8B%E3%82%8BWeb%E6%8A%80%E8%A1%93%E3%81%AE%E5%9F%BA%E6%9C%AC-%E5%B0%8F%E6%9E%97-%E6%81%AD%E5%B9%B3/dp/4797388811/ref=asc_df_4797388811?mcid=3fbbf2bb8e563902aceef57bc81ce684&tag=jpgo-22&linkCode=df0&hvadid=707442440829&hvpos=&hvnetw=g&hvrand=3669127753798878157&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009292&hvtargid=pla-526274317363&psc=1&gad_source=1)