OmniAICreator/Qiita-1.07M huggingface dataset:
【rails】turboが原因でDeviseログイン後にリダイレクトされない問題の対処法


## はじめに

こんにちは。アメリカ在住で独学エンジニアを目指している Taira です。
現在、Railsでアプリ開発を進めており、一部の機能にはRails らしく Turbo を採用しています。しかし、Turbo の仕様によって意図しない挙動が発生することもあります。

今回は、ログイン機能において HTML が期待される場面で Turbo Stream が呼ばれてしまい、リダイレクトが機能しないという問題に直面したため、その原因と対処法について解説します。

## 現状

この問題はログイン周りで発生しました。認証には Devise を使用しており、`SessionsController` にて次のような現象が確認されました。

まず、誤ったパスワードでログインを試みると、`flash[:alert]` が表示されるのは想定通りです。

![invalid\_\_login.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3883070/2f3cde03-4e0b-4b32-baf6-f8a123366fea.gif)

その後、正しいパスワードで再度ログインしても、成功後の画面にリダイレクトされず、画面が更新されないままとなります。

![must\_vailid\_login.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3883070/8885bc80-60cc-4104-b974-af312549efdc.gif)

ただし、ブラウザのページを更新するとログインが完了した状態になっており、セッション処理自体は正しく行われていることが確認できます。

## 原因

ログイン処理自体には問題がないことから、リダイレクトの挙動に注目しました。ログを確認すると、以下のようにリクエストが `TURBO_STREAM` として処理されていることが判明しました。

```
Processing by Users::SessionsController#new as TURBO_STREAM
```

このように、Turbo によって通常の HTML リクエストではなく Turbo Stream として解釈されることで、正常なリダイレクトが行われない状態になっていました。

## 解決方法

Turbo によるフォームの自動ハンドリングをオフにすることで、問題を解消できます。

```erb
<%# views/devise/sessions/new.html.erb %>

<%= form_for(resource, as: resource_name, url: session_path(resource_name),
            html: { class: "space-y-3 sm:space-y-5 w-full", data: { turbo: false } }) do |f| %>
```

このように、`form_for` に `data: { turbo: false }` を追加することで、Turbo の機能を無効化し、HTML リクエストとして扱わせることができます。

## バグの見つけ方について

今回のバグは、単なるステートメントカバレッジ（C0）や条件網羅（C1）では見つけにくい部類の不具合です。なぜなら、状態遷移が関係しており、一度エラー状態を経由した後の挙動に問題が生じているからです。

こうしたバグには、**Nスイッチカバレッジテスト**（状態遷移テスト）が有効です。たとえば：

* 初期状態 → ログイン失敗 → ログイン成功（挙動が変）

のような「状態をまたぐ遷移」を網羅的にテストする必要があります。

このような遷移をカバーしていないと、正常系・異常系それぞれが通っていたとしても、組み合わせの中で生じるバグは見逃されがちです。

## まとめ

* Turbo を使用していると、意図せず `TURBO_STREAM` リクエストとして処理されてしまうことがあります。
* Devise のログインフォームに `data: { turbo: false }` を明示的に指定することで、HTML リクエストに戻すことができます。
* 単純なカバレッジでは見つけづらい状態遷移バグには、Nスイッチカバレッジテストのような網羅的なテストが効果的です。
タッチパッドの左右スワイプでページ戻る・進む機能をオフにする方法！

ブラウザ（google chrome）で、タッチパッドの左右スワイプでページ戻る・進む機能をオフにする方法！
やり方
設定　を開く

ユーザー補助機能　を開く

ページ間をスワイプ　をオフにする！！！！

終わり！🙌🙌🙌🙌

<br/>
<br/>
<br/>

ブラウザ（Microsoft edge）で、タッチパッドの左右スワイプでページ戻る・進む機能をオフにする方法！
やり方
設定　を開く
 
ユーザー補助機能　を開く
 
ページ間をスワイプ　をオフにする！！！！
 
終わり！🙌🙌🙌🙌
【入門】CryptoWorks Wallet API を 30 分で触る ── 残高取得から送金テストまで

![a55b4def-ea32-4d2f-8635-262b9d2ad5b9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4114655/53d05597-a70b-48f5-93bc-4d5cc0434fe7.png)


# はじめに
国内発の暗号資産アプリ **CryptoWorks** が公開している Wallet API は、メール 1 本でテストネット用 API キーを発行できます。本記事では **「まずは動かしてみたい」** 開発者向けに

1. API キー取得方法  
2. TypeScript + Axios の最小クライアント実装  
3. 残高取得 / 送金トランザクション送信  
4. よくあるエラーとデバッグ Tips  

を **30 分で完了** する手順をまとめます。ローカルに Node.js と `pnpm` があれば OK です。

---

## 0. 事前準備

| ツール | バージョン例 |
|--------|-------------|
| Node.js | 18.18.0 |
| pnpm    | 8.x |
| ts-node | 10.x |

```bash
# インストールしていない場合
npm i -g pnpm
pnpm i -g ts-node
🔑 API キーを取得
sales@cryptoworks.co.jp 宛に「テストネット利用希望」と送信

24 時間以内に API_KEY と ENDPOINT が JSON で届く（無料 / KYC 不要）
FinderでSSH鍵のファイル名を変更 → 接続できない？実際は設定ミスだった

## はじめに
SSH鍵ファイルをFinderで名前変更したところ、SSH接続ができない問題が発生しました。
最終的にはただ単にssh keyの拡張子が違っていたことが原因でした、他のファイルの拡張子が表示されているのをいいことに、安心していたことで時間を無駄にしたので反省文を残します。


## 発生した問題

### 問題の発生
VPSでSSH鍵を生成し、秘密鍵をローカルにダウンロードした際、ファイル名が`id_rsa.txt`になっていました。SSH configでは`id_rsa`を指定していたため、Finderで拡張子を削除したつもりでしたが、**実際にはファイル名は変更されていませんでした**。

最初からターミナルで操作していれば問題は起きませんでしたが、GUIでファイル名を変更したことが原因の一つです。

### エラー内容
```bash
% ssh hogehoge
ssh: connect to host xxx.xxx.xxx.xxx port 22: Network is unreachable
```

このエラーメッセージから、ネットワーク接続の問題に見えますが、実際はファイル名の問題でした。
他の人はつなげているのに、自分だけ繋がらない場合はssh configのssh keyが違うとか、ファイル参照場所が違うとか、IPアドレスが間違ってるとかの設定ミスだと思います。



## macOSのFinder拡張子表示設定の問題
macOSのFinderでは、デフォルトで「すべてのファイル名拡張子を表示」がオフになっています。この状態で`.txt`ファイルをFinderで名前変更する際に拡張子を削除しようとしても、**拡張子が隠されているだけで実際のファイル名は変更されません**。

1. Finderでは拡張子なしで表示される（拡張子が隠されている）
2. 実際のファイル名は`.txt`拡張子付きのまま
3. `ls`コマンドで確認すると`.txt`拡張子が残っている

```bash
# SSH configでの設定
Host hogehoge
    HostName xxx.xxx.xxx.xxx
    User fugafuga
    IdentityFile ~/.ssh/id_rsa  # 拡張子なしを期待

# Finderでの表示
id_rsa  # 拡張子なしで表示される

# 実際のファイル名（lsコマンドで確認）
~/.ssh/id_rsa.txt  # 実際は.txt拡張子付きのまま
```

### 問題の本質
- **Finderの表示**: `id_rsa`（拡張子なしに見える）
- **実際のファイル名**: `id_rsa.txt`（拡張子あり）
- **SSH configの指定**: `id_rsa`（拡張子なし）

この不一致により、SSHクライアントは指定されたファイルを見つけることができませんでした。

## 解決方法

### 1. 現状確認
まず、ターミナルで実際のファイル名を確認します：

```bash
# SSH鍵ディレクトリの内容確認
ls -la ~/.ssh/
# -> id_rsa.txt が表示される（実際のファイル名）
```

### 2. 正しいファイル名に変更
ターミナルで正しいファイル名に変更します：

```bash
# 正しいファイル名に変更
mv ~/.ssh/id_rsa.txt ~/.ssh/id_rsa

# permissionのエラーが出る場合は以下を実行してください
chmod 600 ~/.ssh/id_rsa
```


## 根本的な解決策

### 方法1: Finder全体の拡張子表示設定を有効にする
今後同様の問題を避けるため、Finderで常に拡張子を表示するように設定します：

1. **Finder**を開く
2. **Finder** > **設定...** を選択  
3. **詳細**タブをクリック
4. **すべてのファイル名拡張子を表示**にチェックを入れる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939741/c6841209-9d3b-4eed-8a75-d773edc1c2cc.png)

**この設定により、FinderでもGUIから正しくファイル名を変更できるようになります。**

- before

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939741/5b254438-504a-4f20-8d97-e5f1dc45812b.png)

- after

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939741/59858f67-e2aa-4374-a699-978f86f74fc7.png)


拡張子を消すと、小さいですがアイコンが真っ白になります（いや、わからん）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939741/8a791094-182f-4055-bd03-1440c47cf2eb.png)



### 方法2: ターミナルでファイル名を変更する
拡張子表示設定を変更したくない場合は、ターミナルで直接変更できます：

```bash
mv ~/.ssh/id_rsa.txt ~/.ssh/id_rsa
```


ちなみに・・・

リスト形式ではなく、アイコン形式で表示したら一発でわかりました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939741/0051a214-8fa7-4f62-8dcd-4eda7bac588c.png)



## まとめ

今回の問題の本質は：
1. **Finderの拡張子表示設定がオフだったこと**
2. **エラーメッセージの誤解釈**  
3. **`ls`コマンドでの確認を怠ったこと**

**重要なポイント：**
- Finderの拡張子表示設定をオンにすれば、GUIからでも正しくファイル名を変更できる
- または、ターミナルで確実にファイル名を変更できる
- 問題が発生したら、まず`ls`コマンドで実際のファイル名を確認する
- エラーメッセージだけでなく、設定と実際のファイル状態を照合する

最初から`ls`コマンドでファイル名を確認していれば、すぐに原因がわかったはずです。また、Finderの拡張子表示設定をオンにしておけば、GUIからでも正しくファイル名を変更できました。
Databricks Appsの一般提供開始を発表

## この記事について

この記事は、Data + AI Summit 2025 で発表された "[Announcing General Availability of Databricks Apps](https://www.databricks.com/blog/announcing-general-availability-databricks-apps)" について、日本語でまとめた記事となります。Databricks Appsはユーザーが自社のDatabricks環境内で安全かつ統制されたデータ・AI駆動アプリケーションを構築・デプロイ・スケールできるサービスとなっています。

:::note warn
この記事はDatabricksの公式ブログ記事を元にした非公式の日本語要約であり、すべての著作権・知的財産権はDatabricksに帰属します。
:::

## 概要

Databricks Appsが正式に一般提供（GA）され、ユーザーが自社のDatabricks環境内でセキュアかつサーバーレスでデータ・AI駆動アプリケーションを構築・デプロイ・スケールできるようになりました。本記事ではこの新機能の概要と活用方法を解説します。

## 目次

- [主な発表内容](#主な発表内容)
- [Databricks Appsとは](#databricks-appsとは)
- [データとAI民主化の「ラストマイル」問題の解決](#データとai民主化のラストマイル問題の解決)
- [データがある場所にアプリケーションを構築](#データがある場所にアプリケーションを構築)
- [主な特徴](#主な特徴)
- [すぐに始める方法](#すぐに始める方法)
- [まとめ](#まとめ)

## 主な発表内容

- 3大(Azure/AWS/GCP)クラウド・28 リージョンでDatabricks Apps を正式提供
- ユーザーはDatabricks環境内でインタラクティブなデータインテリジェンスアプリケーションを構築・デプロイ・スケール可能
- パブリックプレビュー期間に 20,000 以上のアプリケーションが構築され2,500 社以上 が既に利用

## Databricks Appsとは

Databricks Appsは、Databricksプラットフォーム上で安全なデータ・AI駆動アプリケーションをセキュアに構築・デプロイ・スケール可能なサービスです。組織内のユーザーとの共有も容易なため、パブリックプレビュー開始以降採用が急速に拡大し、2,500以上の組織が20,000以上のアプリケーションを作成しています。


## データとAI民主化の「ラストマイル」問題の解決

一般にアプリケーションのコーディングプロセスは開発の全体工程の半分以下です。
真の難所は、

- 認証とSSOの設定
- コンテナとインフラの管理
- データアクセスの保護
- 監視ツールの統合
- 監査ログの設定
- パッケージと環境の維持

といった “ラストマイル” を、本番レベルのセキュリティとガバナンスを保ちながら乗り越えることです。これまでは DevOps、IT、セキュリティ部門をまたいだ調整に 数か月を要し、その間にセキュリティギャップが生まれるリスクもありました。
Databricks Appsは、ワークスペース内で実行されるフルマネージドのサーバーレスランタイム を提供し、ID管理・ガバナンス・監視を組み込み済みのため、開発者はビジネスロジック実装やユーザー体験の向上施策実行に専念できます。

## データがある場所にアプリケーションを構築

従来データを実際のビジネス価値に変えるには、
外部システムへのデータ移送・インフラの設計・保守等少なくない人的・経済的コストが発生するものでした。
Databricks Appsはこのモデルを逆転-データがある場所にアプリケーションを構築することで従来の課題を解決します。

## 主な特徴

Databricks Appsは以下の機能を提供します：

- 3大(Azure/AWS/GCP)クラウド・28 リージョンでセキュアかつサーバーレスなアプリケーションをデプロイ
- フレームワークの柔軟な選択 - Node.jsとReact、Streamlit、Dash、Plotly、Gradioなど、
- データサイエンティスト・データエンジニアに馴染み深いPythonやJavaScriptフレームワークを使用しアプリケーションを作成可能
- SSOと認証を標準搭載し、Unity Catalogのアクセス権限に基づくユーザーレベルのアクセス制御
- 標準搭載の監査ログでアプリケーション利用状況とアクセスパターンのトラッキング
- Git、CI/CDなど組織のソフトウェア開発プラクティスやツールとのシームレスな統合

これらによりデータアナリストやデータエンジニア中心のチームでもPoCレベルのアプリケーションから本番稼働に耐えうるアプリケーションへ迅速に移行できます。

## すぐに始める方法

Databricks Appsは現在すべての顧客に正式提供（GA）されています。
PythonまたはJavaScriptフレームワークを使用して今すぐ開発を始め、本番稼働レベルのアプリケーションを
組織内にデプロイすることが可能です。

始めるには：

- [ドキュメントを探索](https://docs.databricks.com/en/dev-tools/databricks-apps/index.html)
- [入門ビデオを視聴](https://www.databricks.com/discover/demos/databricks-apps)

## まとめ

Databricks Appsの正式リリースにより、データとAIの価値をエンドユーザーに直接届けることが可能となりました。
データプラットフォームへアプリケーションを開発・デプロイすることで、セキュリティとガバナンスを維持しながら、
データインテリジェンスの「ラストマイル」問題を解決できます。
Pythonフレームワーク（StreamlitやDashなど）や、JavaScriptフレームワーク（Node.jsやReactなど）を使って、
すぐに自社のデータインテリジェンスアプリケーション開発をスタートしましょう。

---

ナレッジコミュニケーションでは、Databricks Data + AI Summit 2025 開催にあわせてセッションレポートや、イベント情報を公開しております！
ぜひナレッジコミュニケーションDAIS2025 特設サイトからチェックしてみてください！

https://www.knowledgecommunication.jp/product/databricks-data-ai-summit-2025.html
生天目佳高Tips：ノーコードだけじゃ足りない？Zapier×GASで業務自動化


はじめに
スタートアップ企業の技術支援をしていると、「業務自動化したいけど、
予算は限られている」という相談をよく受けます。

今回は、Zapierだけでは実現できない複雑な業務処理を、Google Apps Script（GAS）と組み合わせて解決した事例を紹介します。

課題：Zapierの限界
あるクライアントから「Slackで受けた問い合わせを自動でスプレッドシートに記録し、内容によって担当者を自動アサインしたい」という要望がありました。
Zapierで試してみたところ、以下の問題が発生：

複雑な条件分岐の処理が困難
テキスト解析の精度不足
スプレッドシートの複雑な操作に制限

解決策：Zapier×GASの組み合わせ
1. Zapierの役割
Slack → Webhook → GAS
Slackからの問い合わせを受信し、GAS関数を呼び出す部分はZapierが担当。
2. GASの役割
javascriptfunction processInquiry(data) {
  // テキスト解析
  const category = analyzeCategory(data.message);
  
  // 担当者決定ロジック
  const assignee = determineAssignee(category, data.timestamp);
  
  // スプレッドシート更新
  updateSheet(data, category, assignee);
  
  // 担当者への通知
  notifyAssignee(assignee, data);
}
実装のポイント
1. エラーハンドリング
GAS側で例外処理を徹底し、Zapierのタスク消費を抑制。
2. ログ機能
javascriptconsole.log(`[${new Date()}] Processing: ${data.id}`);
3. 処理時間の最適化
重い処理は分割して実行時間制限を回避。
結果

問い合わせ処理時間：平均30分 → 3分に短縮
担当者アサインの精度：95%以上
月間コスト：Zapierプラン内で収束

まとめ
ノーコードツールは強力ですが、複雑な業務ロジックが必要な場合は、プログラミングとの組み合わせが効果的です。GASの無料枠を活用することで、コストを抑えながら高度な自動化を実現できます。
スタートアップの限られたリソースでも、工夫次第で大企業並みの業務効率化が可能だと実感した案件でした。
Hugging Faceでモデルをアップロードする方法【画像付き】

# 1. 「Profile」に移動
Hugging Faceのホームから、ユーザーアイコンをクリックし、「Profile」に移動します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/74b988bf-a17c-4971-91d7-54d5a240e449.png)

# 2. モデルをアップロードするリポジトリを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/06ce3fa0-4e2b-4f7f-96d8-db4ce856e6e0.png)
リポジトリの作成は[こちら](https://qiita.com/D-SNOW/items/37408b6bd718c5ae4f67)

# 3. 「Files and versions」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/0c4929fa-bc22-4aa2-a356-e996c50745f3.png)

# 4. 「Upload files」を選択
「Contribute」のプルダウンから「Upload files」選択。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/bd14144b-7494-4351-860c-5b740f0af082.png)

# 5. モデルをドラッグ&ドロップ
画像の赤枠部分にローカルに保存してあるモデルをドラッグ&ドロップ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/503f8594-9ebd-42ef-a4a2-75799471f359.png)

# 6. 「Commit changes to `main`」を選択
下までスクロールし、「Commit changes to `main`」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/f2b678cd-992c-4cc9-8584-97ce8115a42a.png)

# 7. 完了👍
以下の画像のように、「Files and versions」タブにモデルファイルが追加されていれば完了です！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/ada18928-a278-41bd-8d27-e792f22314a6.png)

# 最後に
こういったサイトのUIはよく変わるので、
もし情報が古かったり「ここ違うかも？」と思ったら、
気軽にコメントで教えてください！
すぐに内容をアップデートします！
3次元データのニューラルネットワークによる分類（pytorch版）

以下の記事より更新
https://qiita.com/k_hirai_01/items/9e3d01961fd5bc4c3958

# pytorch版 3次元データの分類
colabにまとめたので、掲載
> https://colab.research.google.com/drive/1d_2pP__kNgYjKrX-Q2rOQPnSkd_stLFT?usp=sharing
Hugging Faceでモデルリポジトリを作る方法【画像付き】

# 1. 「New Model」を選択
Hugging Faceにログインした状態で自身のユーザーアイコンをクリックし、
「New Model」を選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/37f6e7bf-0ec7-4022-81f2-1a9d86cd0d6a.png)

# 2. モデルをプッシュするリポジトリの名前を指定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/c3976808-1acc-422d-b88d-52da6f91c06e.png)

# 3. 「License」は特に指定がない限り空欄にします
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/786cfd40-8604-4ed8-9c19-67917a12d060.png)

# 4. 公開設定を指定します
Hugging Faceのモデルリポジトリは、公開範囲を「パブリック（公開）」か「プライベート（非公開）」のどちらかに設定できます。

**パブリック（公開）:**
誰でもインターネット上でモデルを閲覧・ダウンロードできます。
オープンソースとして共有したい場合に適しています。

**プライベート（非公開）:**　
自分やチームメンバーのみがアクセス可能で、外部には公開されません。
企業の機密モデルや開発途中のモデルを扱う際に便利です。

今回は、外部に公開せず自分だけで管理したい場合を想定してプライベートを選択しています。
必要に応じて後から公開設定を変更することもできるので、目的に合わせて設定しましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/cd8c5ad7-0f82-42cc-a2a5-33c2f935eeb3.png)

# 5. 全て指定が終わったら、「Create model」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/bd5bc613-8b7b-47de-9f05-1f82eaa148b1.png)

# 6. この画面が出たら完了です👍
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/c3ed19e3-96f4-4bc1-b41a-ac6725effc32.png)

# まとめ
こういったサイトのUIはよく変わるので、
もし情報が古かったり「ここ違うかも？」と思ったら、
気軽にコメントで教えてください！
すぐに内容をアップデートします！
山本和佳Tips：【実体験】AIライティングツール5選を1ヶ月使い倒してガチ比較してみた SNS運用関連のタイトル


はじめに
こんにちは、Webマーケティング会社でSNS運用を担当している山本和佳です。
SNS投稿のタイトル作成に悩む日々を送る中、AIライティングツールの活用を検討し、
実際に1ヶ月間5つのツールを使い倒して比較してみました。

検証環境・条件>

期間: 2025年5月1日〜31日（31日間）
対象: Instagram、Twitter、LinkedIn投稿用タイトル
投稿頻度: 各SNS 1日1回（計3投稿/日）
評価指標: 生成速度、精度、エンゲージメント率、コスパ

検証したツール一覧>

ChatGPT（GPT-4）
Claude（Sonnet）
Gemini Pro
Jasper AI
Copy.ai


<詳細レビュー>
🥇 1位：Claude（Sonnet）
エンゲージメント率: 平均8.7%向上
良い点

SNSプラットフォーム別の文脈理解が秀逸
トレンドを意識したタイトル生成
ブランドトーンの再現性が高い

改善点

料金がやや高め
API利用時のレスポンス時間にばらつき




🥈 2位：ChatGPT（GPT-4）
エンゲージメント率: 平均7.2%向上
良い点

プロンプトの理解度が高い
多様なバリエーション生成
日本語の自然さが優秀

改善点

月額利用料が高い
同じパターンのタイトルになりがち

🥉 3位：Gemini Pro
エンゲージメント率: 平均4.8%向上
良い点

処理速度が圧倒的に速い
無料版でも十分使える
Google系サービスとの連携が便利

改善点

創造性がやや低い
SNS特化の機能が少ない

実際のプロンプト例
あなたはSNSマーケティングの専門家です。
以下の条件でInstagram投稿のタイトルを5つ生成してください：

【商品】: Webマーケティング講座
【ターゲット】: 20-30代ビジネスパーソン
【トーン】: フレンドリーで親しみやすい
【文字数】: 15-25文字
【含めたいキーワード】: スキルアップ、副業

<まとめ>
SNS運用におけるAIライティングツール活用は、もはや必須スキルです。特にClaudeは文脈理解とエンゲージメント向上の面で優秀でした。

ただし、AIに完全依存するのではなく、生成されたタイトルを自分なりにアレンジすることが重要だと感じました。

<おわりに>
今回の検証結果が、SNS運用に悩む方の参考になれば幸いです。
質問やご意見があればコメントでお聞かせください！
Tシャツが欲しいので駆け込みでAmazon Q CLIでゲームを作った

## 本記事作成に至った経緯(Background)
![スクリーンショット 2025-06-13 102428.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3286459/f2ac8a03-b25a-4511-8d6e-c2e737a35842.png)

「[Build Games with Amazon Q CLI and score a T shirt 🏆👕](https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/)」という企画を知りました。
みなさんは、すでに参加されてTシャツをゲットしましたか？Amazon Q CLIを使ったことがなかったのとTシャツが欲しいので駆け込みで参加しました。
:warning: このキャンペーンは2025/6/20までになってます。

 ## 前提
今回はWSL上でやっていきます。インストールまでは記事が複数インターネット上にあるので省略します。

```powershell
$ q chat
```
コマンドで以下の画像のような出力がされれば準備OKです。

![スクリーンショット 2025-06-13 105027.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3286459/3a0406d7-1bfa-45de-80cb-a18e8a96a51d.png)



## 本題
### 1. 作りたいゲームを考えます
> Amazon Q CLI の可能性を探るため、できるだけ革新的なゲームを作ってみてください。

企画公式サイトの文言にビビりますがまずは本当に簡単なゲームを作ります。

```draft.md
## 概要
ブロック崩しゲームを作ります。
使用するライブラリは **pygame 2.6.1** です。

## 仕様

### 難易度
- ゲームの難易度は3段階あり、選べます。

### ゲームの進行
- ゲームが開始すると、一つのボールが動きます。
- ボールは正確な反射角度で動いていきます。
- ボードに当たるとボールが反射します。
- ブロックに当たるとボールが反射します。
- 画面端にボールが当たると反射します。
- ブロックはボールが1度で当たると壊れます。
- ブロックは動きません。
- 操作できるボードは横にしか動きません

### 操作
- キーボードを←、→してボードを動かします。

### 終了条件
- 全てのブロックを壊すとクリア。
- ブロックを壊し終わる前にボールをロスト。
```

ゲーム概要や機能について考えてみました。さて`q chat`で実行してみましょう。

## 1回目の実行後プロンプト
```
ゲームを修正します。
・操作ボードにボールが当たった時に正確な反射が行われずにゲームオーバーになります。
・ゲームタイトルなどの文字に関して
　文字化けを直してください。
  スタイルはレトロでポップな感じでお願いします。
```

## 2回目の実行後プロンプト

```
上手く動作確認できました。さらにゲームを修正します。
 ・ゲーム空間の背景はサッカー場風にしてください。
 ・ボードはサッカー選手に見立てて、ボールが当たる時にサッカー選手の足振りに当たるようなエフェクトにしてください。
 ・イメージは自動生成でよいです。
```

## 3回目の実行後プロンプト
```
さらにゲームを修正します。

サッカー場風の背景
   • 芝生の縞模様をチェック柄にしてください。

サッカー選手をイメージしたパドル
   • パドルをサッカー選手のグループに変更→1人のサッカー選手にしたいです。

サッカーボールの表現
   • 黒と白のパターンを持つボール画像を使用→もっとボールっぽくしたい

ブロックのデザイン変更
   • ブロックをサッカーゴールのネットをイメージしたデザインに変更
   　→ 前のブロックデザインでよい。ブロックデザインはソリッドでクリスタルな感じにしてほしい
```

## 4回目の実行後プロンプト

```
改善しました。さらにゲームを修正します。
### サッカー場風の背景
• 40x40ピクセル→60x60ピクセルに変更

### ブロックのデザイン変更
• ブロックデザインをもっとプレーンなデザインにしたい。

### 機能の追加
• ゲームを終了するボタンを画面上部に小さく追加。押すとトップページに戻る
• サッカー選手のパドルに当たると「Ole!!」と文字が表示され、1/2秒後に消える。
```

## 5回目の実行後プロンプト

```
改善しました。さらにゲームを修正します。
### サッカー場風の背景
• 60x60ピクセル→80x80ピクセルに変更

### デザインの修正
• 左上のSCOREと点数、右上のLEVELの文字スタイルを虹色太文字で浮いた感じにしたい
• ゲーム終了の×ボタンのデザインをもっと現代的な装飾に
```

ゲームが完成しました。
以上で、この記事を終わります。
https://x.com/tyranno269/status/1934427658722648167?s=46&t=pG53zLaWDZPM1fWvIus0-g

ありがとうございました。
人生の選択肢を広げたデザイン。走馬灯に出るような体験を。

# 「この体験、走馬灯にでてくるかな」
>走馬灯とは死の直前や、命の危機を覚悟するような状況で、過去の記憶が次々とよみがえる状態のこと。

人生って思ったより短い。
この前まで高校生だったのに今はもう22歳で新卒社員としてエンジニアになってる。マジで信じられない＾＾
大人になるなんてずっとずっと先のことだと思っていたからもうこんな年であることに実感が持てない～！

こんなに早く時が過ぎ去るなら、次気づいた時にはじぶんは何歳になっていて何をしているのだろうか。人生楽しんでるかな？人生が終わる瞬間に見るであろう走馬灯は長編になるかな？

未来へのワクワクと不安が共存してなんだかむず痒い感情ではあるが、自分らしく人生を輝かすためにもここで一度デザインに興味を持った過去を振り返って、**私の走馬灯の一部**を皆さんに共有したいと思う。
そしてこれを読んでくれた人も、自分の中の熱中したいものに気づき、人生の選択肢が広がって走馬灯が少しでも長くなったらいいな～＾＾

# 自分の原点
振り返ると私は幼いころ、ずっと物語に触れていた。
他人の感情や思いが文章や映像、演技を通すことで表現され、別の人に触れられるような形となることに純粋に感動していたように思う。（特にディズニー大好きだった）

その延長線で芸術に興味を持って、自分でイラストを描いたり写真を撮ったりするようになり、伝えること・表現することの幅を広げるために大学はデザインや表現を専攻した。

そして大学に入ると同時に、大学受験でお世話になった予備校でチューターを始めたのだが、大学でデザインを学んでいるからなのか広報チームに配属され、その予備校に新規の生徒を集めることを目的にチラシや広告の作成を任された。

# 人生を変える大学受験
広報活動を続けていると、チラシや広告を見て数人が入学してくれたのだが、私の働く予備校は指導にしっかり力を入れていたため、その多くの人が大学受験を成功させた。

中には勉強を今までやってこなかったような子や、不登校となり勉強についていけなくなった子もいたが、勉強を頑張る中で自分の将来に向き合い、意思を持って大学を選択し、合格し、新たな人生へと向かっていった。

チラシで知った予備校に入って受験勉強を頑張り、大学受験を成功させたということはつまりその人の未来を変えたってことで、**情報と出会いが人の人生を変えた**となる。

自分のデザインによって受け取られやすくなった情報と人が出会ったことで可能性を広げ、新たな人生に向かわせた。

### この出会いをもっと促進させたい！情報がもっと人と出会いやすくなればいい！

私はこの経験から、**情報と人との出会い方をデザインすること**を人生の目標にしたように思う。

たくさん書いたけど、大部分はどうでもよくて。。。
要は**情報を届けやすくするデザイン**ってマジすごいって感じたってこと！！！


# 情報との接点をデザインするUI/UX

UI/UXとは**ユーザーインターフェイス（UI) と ユーザーエクスペリエンス（UX)の略で、UI/UXデザインとはサービスなどと人が接する点や体験をデザインすること**である。

UXが優れていればユーザーの体験が向上し、UIが優れていれば、サービスがより使いやすくなり、より多くの情報が人の目に触れる。それに魅力を感じ私は大学３年次にUI/UXに触れ始めた。

直感的でスムーズな体験を提供するということで出会いを促進させ、多くの人の人生が拡張させるために私がUI/UXデザインを作る際、意識していることを紹介しようと思う＾＾


### ①事前調査を怠らない
画面を設計する際に事前調査をしっかりとしておくことは重要である。
提供したいサービスを任意の形で利用してもらうためには、有名な話だが**UX5段階モデル（戦略・要件・構造・骨格・表層）に沿うこと大切なのではないだろうか**。
その中でも**戦略・要件**には最も力を入れるべきで、ユーザーが最も求めるものにアクセスしやすくなるような画面の遷移、ストレスのない操作を誘導をすることを目標とすることは、ユーザーのニーズをかなえるために必須条件！！

### ②学習コストをできるだけ下げる
クリッカブルで個性あふれるWebサイト（就活サイトに多いイメージ）を最近よく見るが、何の情報がどの箇所を見ると書いてあるのかわからない。そのWebサイト人何度もユーザーが訪れ、学習してくれるのなら話は別だが、大体は「見にくい」と感じられた時点でユーザーは離脱する。

それはアプリケーションでも同じ話で、一見デザイン性のあるUIであっても、既存の慣れているUIと大きくかけ離れていたり、ユーザーが意図した挙動を起こさなかったりする場合、ユーザーはそのアプリのことを嫌いになる。

それを防ぐため、**ユーザーの学習コストをできる限り下げた既存の法則に従ったUIをデザインすること**が大切だと私は思う。

### ③定量的評価と検証
UI/UXなどのデザインはユーザーの感覚によって評価されるものなので評価を意識しづらい面がある。**WebアプリやサイトではGoogleアナリティクスなどのユーザーの滞在時間や離脱理由などを確認できるツールを使って確認することができ、アプリでは公開前にテストを行うことで定量的な評価を得ることができる。**
そして実際に運用していく中でPDCAサイクルを回し、さらにアップデートを重ねることも必要である。


# さいごに
最近はほんとに、見た目や雰囲気が重要視される世の中になったけど、UI/UXにおいてはそれにさらに使いやすさやストレス性の低さが求められる。
自分がサービスを使うときも何か違和感を感じたら離脱しちゃうもんねほんと。
自分の生み出したものでいろんなひとの人生を広げるためにも、良い体験を意識した実装・デザインを今後もしていけたらいいな～＾＾
Cisco Certified Support Technician（CCST）合格記

結構知られていないレアなITである
Cisco Certified Support Technician（CCST）を受験してきましたので勉強内容や実際どうだったか等を記事にしてみます。


### Cisco Certified Support Technician（CCST）って何？

ここに記載されている通りCiscoの初学者向けの一番難易度の低い試験です。
ちょっと前にあったCisco Certified Technician(CCT)の資格がなくなったので後継の資格に当たるような感じだと思います。

https://www.odyssey-com.co.jp/ccst/


### 受験前のNWの理解度

１０数年インフラエンジニア(サーバ)として仕事をしてきたので一般的なNW知識はあると思っています。
IP、デフォルトゲートウェイ、NAT、プロキシ、VLAN、スタック、CIDR
TCP、UDP、LAN、WAN、ルーター
この辺のワードは理解できるかなぁという感じ。

逆にこの辺はちょっと知らなかった
OSI参照モデルの順番や動的ルーティングプロトコル、IPv6全般、スイッチのコマンド全般
（IPv6使ってる現場を見たことないけど・・・）


### なぜ受験しようと思ったか

NW周りはNWエンジニアにほとんど丸投げしていたので少しは勉強しようかなと思ったのがきっかけです。
大体のネットワーク設計ができればネットワークエンジニアに任せればいいので実際そこまで必要じゃないが
結果として見える形にしようとおもい受験を考えました。

最初はCCNAを受験しようと思っていたけれど難易度もそれなりに高く相応の勉強時間が必要で、
またNWエンジニアではないのでCCNAレベルまで勉強する必要はないという甘えもある・・

### 勉強方法と時間

この資格についてはまだ新しいこととそこまでニーズがない？からか
問題集等がほとんどありません。特に日本語。
試験範囲は公開されていますが問題のレベル感はよくわかりません。

https://www.odyssey-com.co.jp/ccst/pdf/Networking.pdf

私がどのように勉強したかというとネットで出てくる問題集を１つ購入して
それを繰り返し解いて勉強しました。
２週間くらい毎日数時間勉強したので５０～７０時間くらい
そこそこ受験料もかかるので結構がっつりやりました。
他にはPacket Tracerを使って実際にコマンドを入力したりVLANや動的ルーティングをつくったりして
コマンドの意味や表示結果を理解するということも勉強しました。


### 結果と感想

なんとか合格できました。
正直私と同じNWレベルの人では勉強しないと合格は難しいと思います。
実際の試験でちょいちょい悩むところがありました。
日常的にNW設計していたりCiscoスイッチを触っている人であれば勉強０で行けると思います。

Ciscoのコマンドの理解や実機のランプの状況などは勉強しないと難しいかなと思います。
あとIPv6も普段使っていない人は勉強しておかないと難しいかと思います。
試験受けた後での感想としては問題集は英語版でもよいので買ってやっておいたほうがいいかなと思います。
実際機械翻訳みたいな日本語の問題なので・・・

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3857934/d21415f1-8b6c-49f7-8324-365de9cfe553.png)
【備忘録】zsh コマンドラインエディタ

# いつも迷うので備忘録


- カーソル移動系

|	キー	|	動作	|	注	|
|	:-:	|	:-	|	:-:	|
|	Ctrl + A	|	カーソルを行頭へ	|		|
|	Ctrl + E	|	カーソルを行末へ	|		|
|	Ctrl + B	|	カーソルを1文字戻る	|		|
|	Ctrl + F	|	カーソルを1文字進める	|		|
|	ESC + F 	|	カーソルを1単語先に進める	|		|
|	ESC + B 	|	カーソルを1単語戻す	|		|
|	Ctrl + L	|	現在の行以外をクリアする	|		|


- カーソル位置から所定の文字列を削除

|	キー	|	動作	|	注	|
|	:-:	|	:-	|	:-:	|
|	Ctrl + K	|	カーソル位置から行末までを削除	|		|
|	Ctrl + U	|	行全体を削除	|		|
|	Ctrl + H	|	カーソル位置の直前の1文字を削除	|		|
|	Ctrl + D	|	カーソル位置の1文字を削除	|		|
|	Ctrl + W	|	直前の1単語を削除（単語境界は空白類）	|		|


- テキスト処理系

|	キー	|	動作	|	注	|
|	:-:	|	:-	|	:-:	|
|	Ctrl + T	|	カーソル前後の文字を入れ替える	|	|
|	ESC + U 	|	単語を大文字にする	|		|
|	ESC + L 	|	単語を小文字にする	|		|
|	Ctrl + O	|	viで編集する（:wq）	|	（下記設定） 	|

```sh
export EDITOR=/usr/bin/vi
autoload -Uz edit-command-line
zle -N edit-command-line
bindkey '^o' edit-command-line
```


# myMac

```terminal:執筆時点
% zsh --version
zsh 5.9 (x86_64-apple-darwin23.0)

% sw_vers
ProductName:		macOS
ProductVersion:		14.7.5
BuildVersion:		23H527
```
apacheからnginxに移行

✅ 1. 準備段階
▸ Nginxのインストール
サーバーにNginxをインストールします。

bash
コピーする
編集する
sudo apt install nginx  # Ubuntu/Debian系
# または
sudo yum install nginx  # CentOS系
▸ Apache設定のバックアップ
Apacheの設定ファイル（/etc/apache2/ や /etc/httpd/）や .htaccess をバックアップします。

✅ 2. 設定の移行
▸ 仮想ホスト（VirtualHost）の移行
Apacheの設定例：

apache
コピーする
編集する
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
</VirtualHost>
Nginxの対応例：

nginx
コピーする
編集する
server {
    listen 80;
    server_name example.com;
    root /var/www/html;
    index index.html index.htm index.php;
}
▸ .htaccess の変換
Nginxは .htaccess をサポートしていないため、書かれていたリダイレクトやリライトルールをNginxの設定に手動で移行する必要があります。

Apache例：

apache
コピーする
編集する
RewriteEngine On
RewriteRule ^about$ about.html [L]
Nginx例：

nginx
コピーする
編集する
location /about {
    rewrite ^/about$ /about.html break;
}
▸ PHPの対応（php-fpmを使用）
Apacheのmod_phpとは違い、Nginxではphp-fpmが必要です。

bash
コピーする
編集する
sudo apt install php php-fpm
Nginx設定例：

nginx
コピーする
編集する
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
※PHPのバージョンによりソケットのパスが異なる場合があります。

▸ SSL（HTTPS）設定
ApacheのSSL設定をNginx形式に変換します：

nginx
コピーする
編集する
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ...
}
✅ 3. サービスの切り替え
▸ Apacheを停止・無効化：
bash
コピーする
編集する
sudo systemctl stop apache2
sudo systemctl disable apache2
▸ Nginxを起動・有効化：
bash
コピーする
編集する
sudo systemctl start nginx
sudo systemctl enable nginx
▸ 設定テスト：
bash
コピーする
編集する
sudo nginx -t
✅ 4. その他の注意点
.htaccess を使っていた場合、その機能はすべてNginx設定に書き換える必要があります。

WordPressやLaravelなどのフレームワークでは、専用のNginx設定が必要になる場合があります。

ファイアウォールのポート（80, 443）が開いているか確認してください。

✅ Nginx設定の例（SSL + PHP対応）：
nginx
コピーする
編集する
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

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

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }
}
初心者向けGitHubリポジトリ作成ガイド【画像付き】

# 1. Homeの`Create repository`を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/9159ed74-0d7d-4523-9863-a6b7361c3e3a.png)

# 2. リポジトリの名前を設定(自分のプロジェクトの内容に合致する名前にしましょう。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/bcd30ec3-bd9e-4a26-a10c-9339632fe145.png)

# 3. 「Description」にはどのようなプロジェクトか分かるように説明を記載
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/8d50130f-8298-4c76-8b66-b0ea6ee6c6dd.png)

# 4. パブリックかプライベートを選択
**パブリックリポジトリ:** 
誰でも閲覧・クローンが可能で、オープンにプロジェクトを公開したい場合に選択。
オープンソースプロジェクトや共有したいコードを管理するときに便利です。

**プライベートリポジトリ:**
アクセス権を持つユーザーのみ閲覧・編集が可能で、公開したくないコードや機密情報を含むプロジェクトに選択。

今回はプライベートを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/b6740ff9-cf75-4f14-891f-f053f1c033eb.png)

# 5. 「Add a README file」にチェックを入れる
ここでチェックを入れないとGUIからファイルをプッシュする際に非常にめんどくさいです🥲
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/21df0c92-8d26-421f-ae4b-98f80ed9365f.png)


# 6. 一番下までスクロールし、`Create repository`を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/c7dba3ec-9a7c-4b75-8523-856aa1f37b43.png)

# 7. これで完了です👍
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4112242/4d6fdbbb-c3d6-40a5-9212-eb3b604f13df.png)

# まとめ
情報が古い場合はいつでもコメントください！
内容を更新いたします！
SESでキャリア迷子にならないために、僕が決めている5つのルール

「SESって、結局キャリアにならないんじゃないの？」  
そんな声、聞いたことありませんか？

僕はSESとして数年働いてきましたが、今のところキャリアに迷ったことはありません。  
むしろ「どう生きるか」を選べる自由さがSESの良さだと思っています。

今回は、そんな僕が意識している“迷わないための5つのマイルール”を紹介します。

---

## 1. 「目的のない現場」は選ばない

スキルがつくか？  
経験として履歴書に書けるか？  
“誰かの紹介だから”という理由だけで現場を選ぶと、目的も成長もボヤけてしまいます。

僕は現場に入る前に、必ず「何を得て、何を捨てるか」を明文化してから入ります。

---

## 2. 技術を“好きな方向”に育てる

Reactが好きなら、業務外でも触っておく。  
Pythonが面白ければ、趣味の自動化でも使ってみる。

現場で使っていなくても、**“好き”を軸に積み上げる**ことで、いつか武器になります。

「得意＝現場」「好き＝プライベート」  
この2本の技術軸を意識すると、キャリアの幅が広がります。

---

## 3. “名刺になる実績”を意識する

- GitHubに残せるコードを書く  
- Qiitaに自分のノウハウをまとめる  
- ドキュメントをチームで使われる形に整備する

SESは成果が「紙」で残りづらいからこそ、**見える実績**を自分で残す努力をしています。

---

## 4. エンジニア“以外の肩書き”も探す

僕は「技術者」だけでなく「ドキュメント整備屋」「Slack盛り上げ担当」「教育係」など、  
現場ごとに“もう1つの顔”を持つようにしています。

複数の顔があることで、他のエンジニアとの差別化になりますし、  
転職時や案件提案時にも「こういう人です」と説明しやすくなります。

---

## 5. 3ヶ月に1回「棚卸し」をする

- 自分は何ができるようになった？  
- 今の現場、続けたいと思ってる？  
- 次に興味ある技術・業界は？

この問いを定期的に考えるようにしています。  
キャリアがブレるのは、“何となく働き続ける”からだと思っています。

---

## まとめ：SESは“選べるキャリア”、使い方しだい

SESは、現場を変えながらスキルも環境も選べる働き方。  
だからこそ、“選ぶ力”と“振り返る力”を持っていれば、キャリアに迷うことはありません。

あなたの今の現場、ちゃんと目的を持って選べていますか？  
この機会に、ぜひ棚卸ししてみてください。

---

読んでくださってありがとうございました！  
SESは不安定に見えて、実は“自由”と“戦略”のある働き方。  
これからも、一緒にうまく使っていきましょう〜。
NotebookLM✖️ChatGPTでチームの改善活動を記事にしてみた

# 自己紹介
こんにちは！4月から新しく発足したチームで働いている @taka_2525 です。
私たちのチーム（プロダクト企画開発部第4開発ユニット、通称4ユニ）ではKotlin Multiplatformを使用したアプリ開発を行っています。
比較的若いメンバーが多いチームで、毎日元気いっぱい開発に取り組んでいます💪

そんな中、私たちのチームでは、**毎週の改善活動を記事化して社内に共有する**取り組みを行っています。  
しかも、**AIを活用することで低コスト＆高品質**な記事が作成できているので、その方法と実際の成果を紹介します！

# 準備するもの
- NotebookLM
- ChatGPT
- ふりかえり・デイリーの録音や資料など

# やり方

### 1. 会議の音声を録音
デイリーやふりかえりといった会議の音声を録音しておきましょう。

### 2. ふりかえりで使用した資料を用意
Miroボードや会議中に使用した資料などを準備してください。

### 3. NotebookLMにアップロード
1と2で準備した録音と資料をNotebookLMにアップロードしましょう。

### 4. 記事作成を指示
NotebookLMに記事作成をお願いします。その際、以下の点に気をつけます。
- 必要なソースのみを選択
    記事作成にあたって、参照してほしいソースのみを選択するようにします。
    ![スクリーンショット 2025-06-18 19.00.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3576260/fe2917ce-d572-49a0-a668-0a7add4dcba3.png)
    
- どんな記事を書いてほしいのかプロンプトで指示してあげる
    以下は例です。記事にしてほしい内容を大まかに指示してあげます。
    ```plaintext
    以下の内容で記事を作成してください
    - デイリーを朝やることで生産性が向上した
    - 席替えでコミュニケーションを活性化させた
    ```

### 5. ChatGPTでブラッシュアップ
NotebookLMが作成してくれた記事をChatGPTに渡して文体を直してもらいます。
NotebookLMで作成した記事をそのまま使用してもいいのですが、文体が固かったりあまり面白くなかったりするのでChatGPTに書き直してもらいます。プロンプトはこんな感じ。
```plaintext
（NotebookLMがつくってくれた記事をコピペ）
上記の記事を面白くて簡潔な記事にまとめてください。
```

### 6. チームでレビューして公開
誇張が過ぎる表現や事実と異なる内容がないかチェックします。
これで**週1回30分で記事が完成**します！

# 実際にできた記事

実際にこんな雰囲気の記事を毎週作成しています。
これからはQiitaにもアップしていく予定なのでよければご覧ください！
（公開できる部分とそうでない部分があるので社内公開したものからの抜粋版となっています）

https://qiita.com/taka_2525/items/7268f5a24673b3ccbd95

# 最後に
記事作成をすることで自分たちのふりかえりにも使用できますし、何より他のチームへのノウハウ共有に繋がります。
毎週1から記事を作成するのは骨の折れるお仕事かもしれないですが、AIを使用することでコストを減らすことができます。皆さんもぜひ真似してみてください！

あと、今後も記事の内容や改善事例を継続してシェアしていきたいと思っています！お楽しみに！
SES（客先常駐）で“居心地”の次に目指す5つのこと

---

SESの現場に慣れてくると、次に出てくるのが  
「もっと貢献したい」「この現場で何を残せるか」という感情。

今回は、僕が“居心地”を作ったあとにやっている、  
もう一歩踏み込むためのアクションを紹介します。

---

## 1. “ちょっとした困りごと”を拾う

誰かの「この資料、毎回手で直しててさ…」とか  
「ここの設定ってなんか面倒だよね」といったつぶやきに耳を傾けます。

これらは、自分が自然に手を出して感謝されやすい“ゴールデン課題”。

改善ツールをちょっと作ったり、テンプレを整えるだけでも  
「〇〇さん、助かるわ〜」となります。

---

## 2. 名前を“議事録”や“コード”に残す

これは地味だけど、自分の存在を刻む大事な方法。  
- 議事録に名前を入れておく  
- ドキュメントに「更新：〇〇」と記載する  
- GitのPRに丁寧な説明を書く  

名前が残っていれば、あとから「あの人に聞こう」が発生し、  
自然と“頼られる人”になります。

---

## 3. 他社メンバーと“雑談以上”の関係を築く

雑談ができる関係から、技術の相談や業務共有ができる関係へ。

- 「この前の対応、〇〇さんの方法が参考になりました」  
- 「ちょっとこれ、相談してもいいですか？」  

など、信頼ベースでの会話を増やしていくと、  
チーム感が出て働きやすくなります。

---

## 4. 自社にも“貢献”のタネを持ち帰る

現場で学んだツールやノウハウを、自社のSlackにちょっと投稿してみる。

「この現場でこんな工夫してました〜」という共有が、  
別のエンジニアの役に立つこともあります。

自社内での存在感も高まり、社内評価にもつながります。

---

## 5. 未来の自分に“残すもの”を考える

常駐が終わった後に  
「あの現場で何を学べた？」と聞かれたとき、ちゃんと答えられるように。

ちょっとしたメモでもいいので、  
自分が関わった改善、対応した障害、得られたノウハウを記録しておくと、  
次の現場で活きてきます。

---

## まとめ：居心地を超えて、“爪あと”を残す

SESという働き方は、どうしても「派遣されて終わり」に見られがち。  
でも実は、“爪あとを残す”ことで、  
- 次の案件にもつながる  
- 自分の市場価値も上がっていく  

「ちょっと手伝おうかな」「これ残しておこうかな」と思えたら、  
きっと今の現場も、ひとつの成長ステージになるはずです。

---

読んでくれてありがとうございました！  
次の現場も、またちょっとずつ“いい空気”作っていきましょう〜！
【長田総一郎】ChatGPT×マーケティング：アイデア出しからコンテンツ作成までの実践記録


はじめに
スタートアップのマーケティング支援をしている長田です。
ChatGPTをマーケティング業務に本格導入して半年が経ったので、実際の使用例とその効果をまとめてみました。
1. アイデア出しフェーズ
使用例：キャンペーン企画のブレスト
プロンプト例：
「B2BのSaaS企業で、年商1億円未満のスタートアップが、
新規顧客獲得のために実施できる低予算キャンペーンを10個考えて。
実施コスト、期待効果、実行難易度も含めて。」
効果

従来：ブレスト会議2時間 → アイデア5-7個
ChatGPT活用後：15分で10個のアイデア → 会議は絞り込みと具体化に集中

2. ペルソナ設計
使用例：詳細なペルソナ作成
プロンプト例：
「クラウド会計ソフトを導入検討している、従業員10-30名の製造業の経営者の
ペルソナを作成して。年齢、課題、情報収集方法、決裁プロセスまで詳細に。」
改善点

JSONやMarkdown形式で構造化された出力を指定
複数パターンを一度に生成し、チーム内で議論のたたき台に

3. コンテンツ作成
使用例：ブログ記事の骨組み作成
プロンプト例：
「『中小企業のDX推進における失敗パターン5選』というタイトルで、
2000文字のブログ記事の構成案を作成。
各章のポイントと、読者の行動を促すCTAも含めて。」
ワークフロー

ChatGPTで構成案作成（5分）
人間が構成をレビュー・修正（10分）
ChatGPTで各章の詳細執筆（15分）
人間が全体を編集・校正（30分）

<結果>

従来：1記事2-3日 → ChatGPT活用後：1日で完成

4. A/Bテストの仮説立て
使用例：LPの改善仮説
プロンプト例：
「現在のLPのCVRが2.3%。業界平均は3.5%。
ヒートマップ分析の結果、ファーストビューでの離脱が多い。
改善仮説を具体的な施策セットで5パターン提案して。」


<活用メリット>

客観的な視点での仮説提案
実装優先度の整理が効率化

5. 数値分析のサポート
使用例：GAデータの解釈
ChatGPTにCSVデータを渡して、トレンド分析や改善提案を求める使い方も効果的でした。

<まとめ>
ChatGPT導入後の変化：

時短効果：ルーティン業務50%削減
アイデア量：3-5倍に増加
品質向上：人間は戦略思考と創造性に集中可能

注意点として、出力内容の事実確認と、ブランドトーンの調整は必須です。
AIはあくまで優秀なアシスタント。最終的な戦略判断は人間が行うバランスが重要だと感じています。
オンプレからAWSに移行するゲーム（Amazon Q developer CLI）

# 内容
Amazon Q Developer CLI を使ってゲームを作成し、Tシャツがもらえるキャンペーンに応募しましょう。[Build Games with Amazon Q CLI and score a T shirt 🏆👕](https://community.aws/content/2xIoduO0xhkhUApQpVUIqBFGmAc/build-games-with-amazon-q-cli-and-score-a-t-shirt)

# 作成したゲーム
左側にあるオンプレミスのシステムを、ドラッグ＆ドロップで右側の AWS クラウドへ移行するゲームです。移行中には敵（●）が妨害してきます。

![game.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/24462545-065e-41e9-b253-f39bb2605d58.png)

動画はこちら

https://x.com/infra365/status/1934391303435079786

# 作成した理由
なかなかゲームのアイデアが思いつかず、最近何かやったことからゲームに落とし込もうと発想が生まれました。少し前に、[こちらの記事](https://qiita.com/infra365/items/d7d1e1c94b18d3796a3c)でAWS MGNを使用したオンプレミスからAWSへの移行検証をしていたので、このアイデアを元にゲームを作成しました。

# 環境
今回は以下の構成で簡易的に試してみました。`pygame`ライブラリはGUIを必要とするため、Ubuntu サーバ上で作成したプログラムをローカルの Windows 環境に移して動作確認を行いました。(既にローカルPCにPython実行環境があったため)

* AWS上にUbuntuサーバを作成
AWSコンソールからUbuntuサーバを作成します。

* Amazon Q Developer CLIの設定
[Essential guide to installing Amazon Q Developer CLI on Linux](https://community.aws/content/2ulGwNwLFj5grS8hXJBMCN78Qwl/the-essential-guide-to-installing-amazon-q-developer-cli-on-linux?trk=6f6cb092-f1ba-456b-8644-73ed7ccbd567&sc_channel=el_)にLinux環境でのセットアップ方法の記載があります。`Installing on the headless Linux system` の項目に沿って実行していけば大丈夫です。

* ゲーム作成
`q`コマンドでAmazon Qを実行してプロンプトに指示を入力していくとプログラムが作成されます。
![game2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/ee63a1bb-a7a7-4f33-9b6d-549a5d2598d0.png)

* ローカルのWindows PCで実行

作成したプログラムをWindows環境で実行します。pythonのセットアップが未実施の場合、Pythonインストール後、`pip install pygame`でpygameをインストールしておきます。

# コードの作成

最初に、以下のような指示文をプロンプトに入力しました。
```
pygameを使用して作成下さい。
・オンプレミスのシステムをAWSクラウド上に移行するゲームです。
・移行中様々な敵に妨害されてしまいます。
・制限時間内に全てのシステムを移行出来たらゴールです。
```

ゲームの内容が曖昧なままでも、以下のようなベースを作成してくれました。

![game3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/7e793766-d10a-4c06-bbb8-d4b91d168a50.png)

ここから、動作やデザインなどをプロンプト経由で調整し、最終的に以下のようなゲームが完成しました。

![game4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/7222713c-492b-4e27-bc92-fb5c56dd7947.png)

# 所感
日本語の指示だけで、ここまでゲームを作成できたのは驚きでした。ソースコードの修正は一切行わず、すべてプロンプト経由で開発を進めました。プロンプトによる対話を重ねることで、さらに完成度の高いゲームを作ることもできそうです。
【iOS】必見！XCode 便利操作/ショートカットキーまとめ

XCodeを約1年間使ってる中で、よく使う便利操作ショートカットをまとめました
他のIDEでも代替がないか探すことで、環境移行後の作業がスムーズになります
※cmd = command

## 必須レベル
#### アプリのビルド/実行/停止
ビルド：`cmd + B`
実行：`cmd + R`
停止：`cmd + .`

#### 選択中のファイル位置をNavigationに表示
同階層の別ファイルを見たいときによく使います
Navigationに表示：`cmd + shift + J`
※Navigation上のファイルから`右クリック>[Show in finder]`でFinder上でも開けます

#### 選択中のクラス・メソッドの定義場所へジャンプ
`cmd + [対象物をクリック]`
※call先ヘは`右クリック>[Show Callers..]`でジャンプできます
※ドキュメントは`右クリック>[Show Quick Help]`で確認できます

#### 文字検索
ファイル内 `cmd + F`
PJ全体 `cmd + shift + F`

#### 文字変換
検索にoptionを足すことで、検索した文字を一括で変換できます
ファイル内 `cmd + option + F`
PJ全体 `cmd + shift + option + F`
※変数、関数名を使用箇所含め一括で変更したい場合
`[対象物を右クリック]>[Refactor]>[Rename]`


## 生産性上がるレベル
#### 前回編集していた位置に戻る
変数の定義へジャンプした後に、「元に戻りたい!」って時によく使います
`[2本指で左フリック]`
※右フリックすると元の位置に戻ります

#### ミニマップ表示
右にファイル全体のマップが表示され、エラーや変更、デバック位置がパッとわかります
`cmd + shift + control  + M`

#### Author表示
各行に対して最新コミット概要を表示します
｢これ誰が書いたん？いつのコミット？」って時に
`cmd + shift + control  + A`

#### ファイルGitlog（非表示）
ファイルに対してのコミットログを参照したいとき使用
`cmd + option + 2（0）`


## たまに便利
#### XCodeとシミュレータを一画面にまとめる
MacOSの操作ですが、デバックログとシミュレータを行き来する必要なくなって便利
`[4本指で上へフリック → シミュレータをXCode全画面へドラッグ(+マークが出ます)]`

#### デバックログ表示/非表示
`cmd + shift + Y`

#### 次(前)の変更点へ
`control + ¥ (+ shift)`

#### ファイル名、行数コピー
`cmd + shift + option + C`

#### 編集差分を並べる
コードレビューなど差分を見比べたいときに役立ちます
`cmd + shift + option + Enter`
※もしくは右上の矢印が交差しているボタン押下でもｋ
ChatGPTのコード、動いたけど“わかってない”あなたへ贈る記事【JavaScript初〜中級者向け】 Vol.3

## はじめに
前回の記事では、「UIの振る舞い」や「イベント処理」など、ChatGPTがよく書いてくれるけど“腑に落ちない”JavaScriptのパターンを解説しました。

https://qiita.com/mukai3/items/a5c867a07a7508b0e4c6

ChatGPTが関数をさらっと使ってくるとき、こんなふうに思ったことはありませんか？

> 「このfunction、どこからどこまでが“有効”なんだっけ？」
> 「スコープってなに？ letとvarの違いって本当に理解できてる？」
> 「クロージャって、何がすごいの？」

この記事では、**ChatGPTが当たり前のように使ってくる“関数まわり”の仕組みを、初〜中級者でもしっかり腹落ちするように解説**していきます。

---

## 1. 関数定義の3パターン、ちゃんと使い分けてる？

```js
// ① function宣言
function greet(name) {
  return `Hello, ${name}`;
}

// ② 関数式（function）
const greet2 = function(name) {
  return `Hi, ${name}`;
};

// ③ アロー関数
const greet3 = name => `Yo, ${name}`;
```

### ✅ 違いまとめ

| タイプ        | 差分               | 解説             |
| ---------- | ---------------- | -------------- |
| function宣言 | ホイスティングされる       | 上にあっても呼び出せる    |
| 関数式        | 変数なのでホイスティングされない | `const`の制約を受ける |
| アロー関数      | `this`がない（レキシカル） | 後述のクロージャと関係深い  |

---

## 2. スコープって結局何？

```js
let a = 1;
function test() {
  let b = 2;
  console.log(a); // → 1（OK）
  console.log(b); // → 2（OK）
}

console.log(b); // ❌ → ReferenceError
```

### ✅ スコープとは

* \*\*「その変数が参照できる範囲」\*\*のこと
* 関数の中で宣言した変数は、外からは見えない

👉 ChatGPTは**何も言わずにスコープを使い分けてくる**。だから自分で意識して読む力が必要。

---

## 3. クロージャとは何か、ちゃんと理解しよう

```js
function counter() {
  let count = 0;
  return function() {
    count++;
    return count;
  };
}

const increment = counter();
console.log(increment()); // 1
console.log(increment()); // 2
```

### ✅ ここで起きてること

* `counter()` が呼ばれたあとも、`count` が「生きている」
* 内側の関数が、外側のスコープに“閉じ込めた”状態

👉 **これがクロージャ（Closure）**：関数が定義されたスコープを「記憶」している

---

## 4. 実案件でクロージャが“地味に”効いてくる場面

### ✅ 状態を隠したいとき（カプセル化）

```js
function createSecret() {
  let secret = "ムカイ最強";
  return () => secret;
}

const getSecret = createSecret();
console.log(getSecret()); // ムカイ最強
```

→ 外から `secret` に直接アクセスはできない

### ✅ イベントリスナーで値を保持したいとき

```js
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// → 0, 1, 2（letはブロックスコープ）
```

---

## 5. thisとクロージャの違い、混同してない？

```js
const obj = {
  name: "ムカイ",
  greet: function() {
    setTimeout(() => {
      console.log(`Hi, ${this.name}`); // thisはobjを指す
    }, 100);
  }
};
```

→ アロー関数は\*\*「定義された場所」のthisを保持\*\*するので、クロージャと似てるけど別モノ。

👉 this = 実行時の文脈
👉 クロージャ = 定義時のスコープ

---

## まとめ：ChatGPTに出されたコードを理解できるようになるために

| 概念               | ポイント           |
| ---------------- | -------------- |
| function / const | 書き方で呼び出し方が変わる  |
| スコープ             | 関数・ブロックごとに変わる  |
| クロージャ            | 関数が外の変数を覚えてる状態 |
| this             | 実行されたときの文脈に依存  |

---

## おわりに

関数まわりの理解は、 **JavaScriptの“中級者の壁”** です。
でもここを超えると、**ChatGPTから出力された関数も読める・修正できる・再利用できる**ようになります。
Pythonで学ぶ生存時間解析3 -生存関数の比較

前回の記事はこちら
Pythonで学ぶ生存時間解析2 -Kaplan-Meier推定量
https://qiita.com/Goriwaku/items/767cdc2640e29fddf7cc

# 生存関数比較の意義
　試験における全体の生存状況を記述した後、それぞれの部分集団における生存関数の比較を行うことになります。この部分集団とは、生存状況に関連していると思われる共変量（説明変数）によって標本を分割したものとなります。このとき、この変数によって分割した2群の生存状況を比較することで、治療効果や性別の死亡率への影響などを考えることが可能になります。これは、通常の統計学において、2標本t検定やノンパラメトリック順位和検、一元配置分散分析などが持つ意義と同等の意義を持ちます。生存時間データが打ち切りを含まない場合、これらの手法をそのまま適用することができる場合もありますが、一般には生存時間データに適応した検定方法が用いられることが多いです。

# 2群生存時間のプロット
　イメージを持ちやすくするために、検定について話す前にwhasデータセットのKaplan-Meier推定量を性別ごとにプロットしてみましょう。whasデータセットについては私の以前の記事（https://qiita.com/Goriwaku/items/8d00696d853da73505bd )を参考にしてください。

```python
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import lifelines as ll
from lifelines import KaplanMeierFitter


whas = pd.read_csv('whas500.csv')
whas_men = whas[whas.GENDER==0]
whas_women = whas[whas.GENDER==1]
kmf = KaplanMeierFitter()
kmf.fit(whas_men.LENFOL, event_observed=whas_men.FSTAT)
ax = kmf.plot(label='men')
kmf.fit(whas_women.LENFOL, event_observed=whas_women.FSTAT)
ax = kmf.plot(ax=ax, label='women')
plt.show()
```
pythonのpandasにおいてあるグループ(今回でいうと性別)を取り出したいときには、df[df['共変量']=='グループ']という書き方で取り出すことが可能です。plot()の引数labelを指定することで、出力された図がわかりやすくなるようにしています。このスクリプトで出力された図が以下になります。男性のほうが生存率が良いように見えます。
![km_2groups.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531810/89af5509-3d05-eec6-5edc-0c913bbf3453.png)
生存時間における2群比較の検定は、この2つの曲線の差が統計的に有意であるかどうかを検証するために行います。次節からは、実際に生存時間データに対して行われる検定手法について見ていきます。
例外処理（try-except）

# 例外処理とは？
例外処理とは何なのか。簡単に言うと、コンピュータが命令を実行した際に、
例外が発生した場合の処理を決めることです。
try-exceptを使用することで例外処理を行うことができます。

## 例外処理の書き方
下のようなPythonのスクリプトがあります。
```
import os

list_file = os.listdir("/root/test")
print(list_file)
```
os.listdir はosモジュールの関数で、
指定したディレクトリパス配下にあるファイルやディレクトリをリストとして取得します。
上記のコードであれば、/root/testディレクトリ配下のファイルやディレクトリを取得しようとします。
しかし、/root/test 以下にファイルが何もない場合、以下のエラーが出てしまいます。
```
$ python test.py
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    list_file = os.listdir("/root/test")
FileNotFoundError: [Errno 2] No such file or directory: '/root/test'

```
これが、コンピュータが命令を実行したときに発生した例外処理です。
では、**try-except**を使用して、例外発生時の処理を書いてみましょう。
書き方はこんな感じです。

```
 try:
       <例外が発生する可能性のある処理>
 except <例外型>:
      <例外型と同じ例外発生時の処理（今回であればFileNotFoundError）>
```
では、これにならってコードを書いてみましょう。
今回、FileNotFoundErrorの例外発生時には"Directory that you specified doesn't exist"と表示したいと思います。
以下のようにコードを修正し、実行してみます。

```
import os

try:
    list_file = os.listdir("/root/test")
    print(list_file)
except FileNotFoundError:
    print("Directory that you specified doesn't exist")
```
実行すると、、、

```
$ python test.py
Directory that you specified doesn't exist
```

例外処理が行われました！
例外オブジェクト（例外型のクラスから作られたオブジェクト）を変数に格納し、
エラーの詳細情報を表示させることもできます。
以下のようにコードを修正します。
```
import os

try:
    list_file = os.listdir("/root/test")
    print(list_file)
except FileNotFoundError as e:
    print("Directory that you specified doesn't exist")
    print(e)
```

**as e** を加え、printで表示させるようにしました。実行すると、、

```
$ python test.py
Directory that you specified doesn't exist
[Errno 2] No such file or directory: '/root/test'
```

詳細なエラー内容が出ましたね。
except節は複数追加することも可能です。

## Finallyの使い方
finally を使用すると、例外発生の有無に関わらず、最後に行う処理を決めることができます。
以下のコードを用意します。
```
import os

try:
    list_file = os.listdir("/root/test")
    print(list_file)
except FileNotFoundError as e:
    print("Directory that you specified doesn't exist")
    print(e)
finally:
    print("END")
```
finally節を追加しました。実行すると、、、
```
$ python test.py
Directory that you specified doesn't exist
[Errno 2] No such file or directory: '/root/test'
END
```
最後にENDと表示されました！

## Exception の使い方
Exception を使用すると、システム終了以外の全例外をキャッチすることができます。
以下のコードを用意します。
```
import os

try:
    list_file = os.listdir("/root/test")
    print(list_file)
except Exception as e:
    print(e)
    print("END")
```
実行すると、、、
```
[Errno 2] No such file or directory: '/root/test'
END
```
例外処理が行われましたね。

以上が例外処理の概要です！
【現場エンジニア向け】非技術者にも伝わる技術比較資料の作り方

## はじめに

現在、フォーム機能の実装方法について技術選択を検討中なのですが、別部署の非技術者との相談がうまくいかず悩んでいます。

「フレームワークの成熟度が...」「SEO対応の複雑さが...」と説明すると、相手が困った顔になってしまうことが多く、結局「エンジニアにお任せします」と言われて終わってしまうパターンが続いています。

でも本当は、非技術者の方の意見や優先順位を聞いて、一緒により良い判断をしたいんですよね。

そこで今回、同じ悩みを持つエンジニアの方と一緒に、**非技術者にも伝わる技術比較資料の作り方**を整理してみました。実際に使えるテンプレートも含めて、明日から実践できる内容をお届けします。

## この記事でわかること・できること

- ✅ 非技術者に伝わる比較表の作り方
- ✅ 専門用語を使わない説明のコツ  
- ✅ すぐに使える表形式のテンプレート
- ✅ 相手の反応を見ながら進める会話術

## この記事の対象者

- 技術選択の提案で悩んでいるエンジニア
- 非技術者（上司・PO・クライアント）と技術的な相談をする機会がある方
- 技術比較を分かりやすく伝えたい方

## 【実践編】3ステップで作る技術比較資料

### Step1: 相手目線で比較項目を設定する

まず、技術用語を相手の関心事に翻訳することから始めます。

**❌ ダメな例（技術者目線）**
- 実装の複雑さ
- フレームワークの成熟度  
- コミュニティサポート
- パフォーマンス特性
- SEO対応

**✅ 良い例（相手目線）**
- 開発期間への影響
- 将来の機能追加のしやすさ
- 問題が起きた時のサポート体制
- ユーザー体験への影響
- Google検索での見つかりやすさ

**具体的な翻訳手順**
1. 相手が普段気にしていることを3つリストアップ
2. 技術用語を「〜への影響」「〜のしやすさ」「〜の可能性」で表現
3. 「もしこれが問題になったら...」という観点で項目を考える

### Step2: 評価を視覚化する

数値や記号を使って、一目で分かる比較表を作成します。

**推奨構成**

| 比較項目 | 案A（ページ分割） | 案B（SPA方式） | 重要度 | 備考 |
|----------|-------------------|----------------|--------|------|
| 開発期間への影響 | ◎（短期間で完成） | △（学習コストあり） | 高 | 来月リリース予定 |
| 将来の機能追加 | ○（段階的に対応可） | ◎（柔軟に対応可） | 中 | 来年の拡張計画あり |
| Google検索対応 | ◎（標準で対応） | △（追加対応が必要） | 高 | 集客への影響大 |
| ユーザー体験 | ○（一般的） | ◎（モダンで快適） | 中 | ユーザー満足度重視 |

**評価記号の統一ルール**
- ◎: 非常に良い
- ○: 良い  
- △: 普通/一部課題あり
- ×: 課題が多い

**重要度の設定**
- 高: プロジェクトの成功に直結
- 中: できれば考慮したい
- 低: 優先度は下がる

**色分けのコツ**
- 各案が優位な項目: 薄い青
- 課題のある項目: 薄い赤
- 同程度の項目: 白

### Step3: 会話しながら進める

資料を作ったら、一方的に説明するのではなく、対話形式で進めましょう。

**事前準備の声かけ**
- 「今日は○○の開発方法について相談があります」
- 「3つの観点で比較資料を作ってみました」
- 「まず、重要度の認識を確認させてください」

**進行のコツ**
1. **重要度の確認から始める**：「この中で一番気になる項目はどれですか？」
2. **重要な項目から説明**：相手の関心に合わせて順番を調整
3. **都度確認を入れる**：「この点はいかがでしょうか？」「他に気になることは？」
4. **反応を見て深掘り調整**：興味を示した部分は詳しく、そうでない部分は簡潔に

## 【テンプレート】今すぐ使える比較表

実際に使える比較表のテンプレートを用意しました。

| 比較項目 | 案A | 案B | 重要度 | 備考 |
|----------|------------------|------------------|--------|------|
| 開発期間への影響 | （例：◎短期間） | （例：△時間必要） | 高/中/低 | リリース時期など |
| 将来の変更のしやすさ | | | | 拡張予定など |
| ユーザー体験への影響 | | | | 使いやすさの観点 |
| 保守・運用の負担 | | | | チームのスキル考慮 |
| コスト面での影響 | | | | 予算制約など |
| リスクの大きさ | | | | 失敗時の影響 |

**使い方**
1. 項目を相手の関心に合わせてカスタマイズ
2. 各案の評価を◎○△×で記入
3. 重要度を相手と相談して設定
4. 備考欄に具体的な影響を記載

**項目カスタマイズ例**
- **スケジュール重視**の場合：「開発期間」「リリース時期への影響」「段階的リリースの可否」
- **ユーザー重視**の場合：「操作のしやすさ」「レスポンス速度」「アクセシビリティ」
- **コスト重視**の場合：「開発コスト」「運用コスト」「将来的な追加コスト」

このテンプレートをベースに、プロジェクトの特性に合わせて項目を調整してください。

## 【失敗談から学ぶ】やってはいけない3つのこと

実際の経験から学んだ、やってはいけないことをお伝えします。

### 1. 専門用語連発
**❌ 失敗例:** 「アーキテクチャの観点から、SPAのフレームワーク選定について...」  
**✅ 改善例:** 「システムの構造から考えると、画面の作り方について...」

### 2. 一方的な説明
相手の反応を見ずに最後まで説明してしまい、途中で置いてけぼりにしてしまうパターン。
「ここまでで質問はありますか？」を定期的に挟むことが大切です。

### 3. 完璧主義
すべての技術的詳細を説明しようとして、要点がぼやけてしまう失敗。
相手が知りたいのは「で、結局どちらが良いの？」という結論です。
相手が知りたいポイントに絞って深く説明する方が効果的です。

## まとめ

非技術者に技術的な提案を伝えるコツは以下の3点です：

1. **相手目線で項目設定**：技術用語を日常用語に翻訳
2. **視覚的に分かりやすく**：図表で一覧比較
3. **会話しながら進める**：一方通行ではなく対話形式で

私自身もまだ試行錯誤中ですが、この方法を使ってから技術相談がスムーズに進むようになりました。

同じ悩みを持つエンジニアの方と、より良いコミュニケーション方法を一緒に見つけていけたらと思います。
Google CloudのVision AIとFirebaseで息子に漢字練習アプリを作ってみた

# はじめに
はじめまして[ほしいも](https://twitter.com/hoshiimo_se)です。
今回は漢字嫌いの息子にVision AIとFirebaseで漢字練習アプリを作ってみたよ！

# 成果物
- 10問1セットの漢字書き取りテスト
- 手書きで Canvas に漢字を書いてもらう形式
- 「答え合わせ」ボタンを押すとAIが判定！
![GitHubPictograph.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/521440/49b9b6da-69fb-4bc4-9d9b-62a2f95e0c40.gif)

# アーキテクチャ
```mermaid
graph TD
    user[👤 ユーザー <br/> ※息子]
    react_app[🌐 フロントエンド <br/> ※React + Firebase Hosting]
    functions[⚙️ バックエンド <br/> ※Cloud Functions]
    vision_ai[👁️‍🗨️ 漢字判定 <br/> ※Vision AI]

    %% アプリケーションの主要フロー
    user -->|アプリ操作| react_app
    react_app -->|手書き画像送信| functions
    functions -->|漢字判定リクエスト| vision_ai
    vision_ai -->|判定結果| functions
    functions -->|判定結果を返す| react_app

    %% サブグラフによるグループ化
    subgraph GoogleCloudGroup [Google Cloud]
        react_app
        functions
        vision_ai
    end

    %% スタイルの適用
    style user fill:#e0f2f7,stroke:#2d3436,color:#000
    style react_app fill:#c8e6c9,stroke:#2d3436,color:#000
    style functions fill:#ffe0b2,stroke:#2d3436,color:#000
    style vision_ai fill:#e1bee7,stroke:#2d3436,color:#000
    style GoogleCloudGroup fill:#e3f2fd,stroke:#28a745,color:#000,stroke-width:2px
```

# Vision AIの漢字判定について
漢字判定、これが思っていたより厳しい。
ちょっとでも字が汚いと別の漢字と判定されてしまう..。

# 料金と無料枠
Cloud Functionsも、Vision AIも、使った分だけ料金がかかる「従量課金制」です。
でもご安心を！Google Cloudには無料枠が用意されているので個人利用であれば無料でだいたい収まります。

各サービスの料金詳細については、以下の公式ページをご覧ください。
- Cloud Vision API 料金: https://cloud.google.com/vision/pricing?hl=ja
- Cloud Functions 料金: https://cloud.google.com/functions/pricing?hl=ja
- Firebase の料金プラン: https://firebase.google.com/pricing?hl=ja

# まとめ
FirebaseとVision AIを使うことで、手書き漢字の認識という一見難しそうな機能も意外と手軽にWebアプリとして実装できることがわかりました。
日本語専用のOCRもいくつかあるみたいなので、機会があれば試してみます。
Geminiでスライムと遊ぶ魔法少女を描いてみた。

# 概要

Geminiでスライムと遊ぶ魔法少女を描いてみました。

# 実装

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

```
電撃のスライムと遊ぶ魔法少女を描いてください。
```

![電撃のスライムと遊ぶ魔法少女_20250616.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3192024/c64a6bad-1a57-4f43-bf53-7dbe08794a2b.png)

# まとめ

何かの役に立てばと。
AWS公式の脅威カタログが公開 

# 概要

2025年6月、AWS CIRT (AWS カスタマーインシデント対応チーム) が [Threat Technique Catalog for AWS](https://aws-samples.github.io/threat-technique-catalog-for-aws/) (以下「AWS脅威カタログ」) を[公開](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-launch-of-the-threat-technique-catalog-for-aws/)しました。

公開情報によれば、AWS脅威カタログは、AWS CIRTが実際のカスタマーインシデントの対応を通じて蓄積した脅威アクターの攻撃手法に基づき構築、整理されています。もともとはAWS内部で利用されていましたが、蓄積した脅威情報はカスタマーにとってもセキュリティ上有用であるとのことで、2024年にはAWSがMITREと協力して[MITRE ATT&CK](https://attack.mitre.org/resources/updates/updates-october-2024/)にも一連の攻撃手法の情報が提供されるようになりました。今回公開されたAWS脅威カタログは、MITRE ATT&CKをベースとしつつ、さらにAWS固有の情報を追加、拡張する形で提供されています。

:::note info
AWS脅威カタログは実際に観測された攻撃手法に基づいており、理論上の攻撃手法はスコープ外とされています。

また、AWS脅威カタログが扱う脅威は、[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)で言うところのカスタマーサイドの設定不備などにより生じる脆弱性 (“クラウドにおけるセキュリティ” 責任) による脅威が対象であり、AWS自体に存在する脆弱性 (“クラウドのセキュリティ” 責任) によるものは対象外です。
:::

脅威例を一部紹介すると、S3に対する脅威として、データ破壊の一つである、[削除権限無しでS3オブジェクトを削除する攻撃](https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1485.001.html)や、あるいは[ランサムウェア等によるS3オブジェクト暗号化攻撃](https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1486.A001.html)など挙げられています。

![technique.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/31469/06671ed4-7c52-4766-8c20-95260f9960f6.png)

# AWS脅威カタログの構成

AWS脅威カタログは、トップの説明ページを除くと以下の構成になっています。どこから見ても、最終的には各攻撃手法の解説ページへとリンクされます。

- 戦術 (Tactics) と攻撃手法 (Techniques) の[マトリクス](https://aws-samples.github.io/threat-technique-catalog-for-aws/matrix.html)
- 戦術一覧 (戦術ページからさらに詳細の各攻撃手法へリンクされています)
- 攻撃手法一覧
- AWSサービス別 攻撃手法一覧

特にAWSサービス別の攻撃手法一覧は、自分が利用しているAWSサービスにおける脅威を把握するのに適しており、AWS固有の脅威カタログ情報として真価を発揮しています。こうした観点からの情報、汎用的なMITRE ATT&CKでは得にくいものです。

![service-list.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/31469/5ac73dad-927b-41ad-8897-2de07d9bb462.png)

各攻撃手法の解説ページでは、主に以下の情報が説明されています。概ね MITRE ATT&CK と同様です。

- 脅威の説明
- 脅威が成立する前提条件
- 検知手段 (Detection)
- 緩和策 (Mitigation)
- 外部の参考情報 (References)

## さいごに

各攻撃手法を読めば、当たり前のものも多いですが、中には意識していなかったポイントが見つかるかもしれません。各ページは簡潔にまとめられているので、興味のある所をさっと読むだけでも新たな発見や再確認につながるでしょう。特にサービス別に一覧化されている点は、関心分野から情報収集するのに適していると言えます。AWS脅威カタログが、セキュアなシステム構築にきっと役立つでしょう。

## 参考資料

- [Threat Technique Catalog for AWS](https://aws-samples.github.io/threat-technique-catalog-for-aws/)
- [AWS CIRT announces the launch of the Threat Technique Catalog for AWS - AWS Security Blog](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-launch-of-the-threat-technique-catalog-for-aws/)
- [MITRE ATT&CK Updates - October 2024](https://attack.mitre.org/resources/updates/updates-october-2024/)