OmniAICreator/Qiita-1.07M huggingface dataset:
【ChatGPT】“三人寄れば文殊の知恵”で議論させてみるPromptです。


　どうも、カーブミラーです。

　今回は、“三人寄れば文殊の知恵”で議論させてみるPromptです。

:::note info
本記事は、ChatGPT（Plus版）
で行なっております。
画像はあります。　あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)
***
　こちらも載せますね。
　　[ChatGPTが使えない？ログインできない・反応しない原因やエラー時の対処法を解説](https://aismiley.co.jp/ai_news/chatgpt-error-resolution-explanation/)
***
　著作権法については
　　こちらを参照するのが
　　　良いのではないかと。

　文化庁レポートをもとにした
　　著作権法についての動画（約20分）
　　　[かいちのAI大学　【警告】ChatGPTの画像生成は危険です...【4o Image Generation】](https://youtu.be/8VLUnG-iyo0?si=rAfjMboqmNqppDGq)
***
　まずは、【ニュース】です。

　ChatGPTの
　　リリースノートが
　　　更新されました。

　[ChatGPT — Release Notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes#h_acfe64e63a)

　まず、
　　Advanced Voice Modeに
　　　追加されていた“Mandy”が
　　　　5月1日に終了しました。

　次に、
　　ChatGPTのiOS/Androidアプリの
　　　操作UIが変わりました。

　　入力枠のボタンですね。

　　ファイルの指定は
　　　そのままですが、
　　　　機能別のボタンがなくなり、
　　　　　ひとつのメニューに
　　　　　　まとめられました。
![Screenshot_20250507-171325~2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457238/949227eb-3362-4580-919a-29e06ec66273.png)
![Screenshot_20250507-171413.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457238/0a065418-b345-4996-b600-f0eb9c647e1d.png)



　　なお、
　　　『より深く思考する』を
　　　　オンにすると、
　　　　　OpenAI o4-mini が
　　　　　　選択された
　　　　　　　状態になります。
***
　では、【本題】です。

　今回は、
　　“三人寄れば文殊の知恵”で
　　　議論させてみるPromptです。

　“三人寄れば文殊の知恵”は
　　凡人でも三人集まって相談すれば、
　　　素晴らしい知恵が出るものだ、
　　　　ということわざですね。

　でも
　　三人とも
　　　愚昧な人間では
　　　　たいした意見も出ません。

　そこで、
　　Web検索での
　　　検証役を入れました。

　＊＊＊に
　　知恵を絞ってもらいたいことを
　　　入力して送信してください。

```Text:三人寄れば文殊の知恵Prompt
“三人寄れば文殊の知恵”を実行して、“＊＊＊”を議論形式で求めよ。ひとつの題材の議論はセッションを続けて結論まで導き出してください。ワンターンで終わるのは議論ではない。最後まで続けてください。

ただし、ひとりはWeb検索でふたりの意見の信憑性を確認する係として、参加させてください。
```

　ただ、
　　これをやっても
　　　最後までやってくれることが
　　　　ありませんでした。

　　途中で止まり、
　　　こちらに続けるかを
　　　　確認してきます。

　　私は、
　　　“最後までやって”と
　　　　送信してやりましたが😅

　こうして、
　　ひとつのことを
　　　三つの視点から
　　　　考えさせるのは
　　　　　面白いですね。

　みなさんの
　　作品制作の糧に
　　　なれば、幸いです。

　今回は、ここまで。
【WSL2+Warden】MySQL WorkbenchでMagentoに接続

MySQL Workbenchのダウンロードから設定方法までの忘備録です。
[以前書いた記事](https://qiita.com/ky_0/items/cc369713690c3cdc5eb2)の最新版で、MySQL8.4.5を使用しています。

# 目次
[MySQL8.4.5のインストール](#mysql845のインストール)
[MySQL workbenchのインストール](#mysql-workbenchのインストール)
[MySQL Workbenchの設定](#mysql-workbenchの設定)

# MySQL8.4.5のインストール
前回はより簡単にインストールできる方法で、MySQL8.0を使用していました。
今回は8.4.5(LTS)をインストールしていきたいと思います。
[こちら](https://dev.mysql.com/downloads/mysql/)から
Windows (x86, 64-bit), MSI Installerをダウンロードしていきます。
ログインを求められたら下部にある「No thanks, just start my download.」をクリックして進めていきます。
ダウンロードができたらファイルを開き、設定をしていきます。
規約などを確認しながら「Next」で進んでいきます。
こちらは「Typical」を選択します。
![スクリーンショット 2025-05-08 113321.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2512649/06cb7dcd-7f7a-4b1d-835b-24c543d03ba7.png)
その後、「Install」をクリックします。
最後に「Run MySQL Configurator」にチェックを入れたまま終了します。

MySQL Configuratorが立ち上がったら、「Accounts and Roles」まではデフォルト設定でOKです。
ここではパスワードを設定します。設定したら下部のアカウントの追加は行わず、次に進みます。
![スクリーンショット 2025-05-08 114642.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2512649/e4073c3b-2c02-47ec-bbae-17d2483f7e03.png)

「Apply Configuration」までデフォルトで進めます。
こちらでは「Execute」をクリックし、セットアップが終了したら「Next」→「Finish」で終了です。
![スクリーンショット 2025-05-08 115926.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2512649/7836c180-34ee-4ba3-a1bb-b0f46ea7e26c.png)

# MySQL workbenchのインストール
[こちら](https://dev.mysql.com/downloads/workbench/)からWindows (x86, 64-bit), MSI Installerをダウンロードし、開きます。
設定はデフォルトのまま、インストールまで進みます。
最後に「Launch MySQL Workbench now」にチェックしたまま終了します。
![スクリーンショット 2025-05-08 120807.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2512649/fa16db79-2a66-4ce4-9a2a-4b490a71c99d.png)

# MySQL Workbenchの設定
設定に関しては[以前の記事](https://qiita.com/ky_0/items/cc369713690c3cdc5eb2)とほぼ一緒なのでそちらを参照してください。
SSH Key Fileが
\\wsl$\Ubuntu-20.04\home\[USER].warden\tunnel\ssh_key
から
\\wsl$\Ubuntu\home\[USER].warden\tunnel\ssh_key
に変更していただけでした。

以上です
【Redeemer】HTB Writeup的な

## 攻略というよりも周辺知識などをまとめたい。
### nmapについて

・`-p-`は全ポートスキャン
・`--min-rate`は最低スキャン速度を指定する事が出来る。
→ `--min-rate　5000`はnmapが1秒間に送信するパケットの最小レートを指定するオプション。
この場合1秒間に少なくとも5000パケットを送信しようと試みる。

`--max-rate`というのもある。

・`apt-get update`インストールが現在出来るパッケージマネージャーのリストを更新する。
・`apt-get upgrade`インストール済みのパッケージの更新を行う。（既存にあるやつの話）

### redisのコマンド

`info`
該当のredisに関する情報を取得出来る。

`keys *`
redisに保存されているkeyをすべて取得出来る。

### TTLはOSごとに違う。
| OS | TTLの初期値 |
|:-:|:-:|
|  linux |  64 |
|  windows | 128  |
| Cisco  | 255  |
|  solaris/AIX | 255  |

:::note info
TTL(Time to Live)の初期値はOSのよって異なる。
ネットワーク上でパケットが通過出来る最大のルーター数を示している。
ループ防止に使われている。
初期値-ルーター通過数　で出来る。
つまり、値が小さいほど遠いという意味になる。
:::



### RedisとMySQLを連携させる事が出来る！？
・キャッシュとしてのRedis
頻繁にアクセスされるデータをキャッシュすることでMySQLへのクエリ数を減らし、応答時間を短縮することがある。

・セッション管理
ユーザーセッション情報をRedisに保存することでセッションの読み書きが高速され、UX向上（これは聞いた事がある。）

・メッセージキューとしてのRedis
Redisは、メッセージキューとしても利用され、タスクのキューイングや非同期処理に活用される。システムのスループットが向上。

・データの同期・統合
RedisとMySQL間でデータを同期・統合するためにETL/ELTツールを使用する。
例として、CData Syncを利用すると、RedisのデータをMySQLに複製出来る。

**メリット**
・やっぱりインメモリデータベースなので読み書きがかなり高速。
・スケーラビリティの向上、Redisをキャッシュに活用することでシステムの付加分散が可能になる。
・データの整合性の確保、MySQLは永続的に、Redisは一時的なデータ処理。






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

https://app.hackthebox.com/37addf3f-232e-4e64-9e69-8d2ae856e962

https://qiita.com/keinko/items/60c844bcf329bd3f4af8

https://www.php.cn/ja/faq/756846.html

https://www.alibabacloud.com/help/ja/cloud-migration-guide-for-beginners/latest/messagequeue#:~:text=%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%AD%E3%83%A5%E3%83%BC%E3%81%A8%E3%81%AF%E3%80%81%E5%9F%BA%E6%9C%AC,%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82

https://qiita.com/kaminuma/items/95ea764a3657ef2f0fb9

https://zenn.dev/ikkik/articles/ffa45ed1fe5a1a

https://blog.cles.jp/item/14249
ESP32 vs STM32：どちらが優れている？用途別の選び方ガイド

組み込みシステムの世界において、ESP32とSTM32のマイコンは、それぞれ異なる利点と用途を持つ2大巨頭として存在しています。Espressif Systemsが開発したESP32は、Wi-FiとBluetoothを内蔵し、IoT開発やコスト重視のプロジェクトに最適です。一方、STMicroelectronicsのSTM32シリーズは、多用途で信頼性が高く、産業用オートメーションや車載電子機器の分野で広く使用されています。

ESP32とは
ESP32は、Espressif Systemsが開発した高性能なSoCマイコンで、Wi-FiおよびデュアルモードBluetooth機能を統合しています。最大230 MHzで動作し、デュアルコアのXtensa LX6またはLX7、もしくはシングルコアのRISC-Vプロセッサを搭載。最大600 DMIPSの演算性能を誇ります。電圧スケーリングや省電力モード、細かなクロック制御といった高度な機能を備え、40nmプロセスで製造されています。

さらに、電力増幅器、低雑音増幅器、フィルタ、電源管理モジュール、アンテナ、RFバランなどの主要コンポーネントも内蔵されています。

ESP32の主な特徴
プロセッサ: デュアルコアまたはシングルコアのXtensa LX6、超低消費電力のコプロセッサ搭載

メモリ: 520 KiB RAM、448 KiB ROM

無線通信: 802.11 b/g/n Wi-Fi、Bluetooth v4.2 (BR/EDR & BLE)

周辺機能: 34個のGPIO、12ビットADC（最大18チャネル）、8ビットDAC×2、タッチセンサー×10、SPI/I²C/UART/CANなど

セキュリティ: WPA/WPA2/WPA3、セキュアブート、フラッシュ暗号化、暗号ハードウェア（AES、SHA-2、RSA、ECC、RNG）

電源管理: 内蔵LDO、ディープスリープ時5μA、GPIO・タイマー・ADC・タッチによるウェイクアップ対応

用途例
IoT機器：センサーノードやコントローラーなど低消費電力で多用途

スマートホーム：家電や照明、セキュリティ機器の制御

ウェアラブル端末：フィットネストラッカー、スマートウォッチ

産業用自動化：機器制御、予知保全システム

スマート農業：土壌モニタリング、灌漑システム制御

STM32とは
STM32は、STMicroelectronicsが開発した32ビットARM Cortex-Mシリーズをベースとするマイコン製品群です。Cortex-M0/M0+/M3/M4F/M7F/M33Fなど複数のコア構成があり、用途に応じて柔軟に選択可能。ST独自の周辺回路と統合されており、STM32F103などのシリーズでは72MHzで動作し、RAMや周辺機能が充実しています。

STM32の主な特徴
プロセッサ: Cortex-M0～M7F（最大550MHz）、一部デュアルコア構成

メモリ: 最大192KBのSRAM、最大2MBのフラッシュ、OTPメモリ

周辺機能: USB 2.0（HS/FS）、CAN 2.0B、SPI、I²C、UART、ADC、DAC、RTC、DMA、温度センサーなど

無線通信: 一部シリーズでWi-Fi、Bluetooth、イーサネット、カメラインタフェース対応

セキュリティ: セキュアブート、暗号処理（DES/TDEA/AES/SHA/MD5）、TRNG

電源管理: LDO内蔵、超低消費スリープモード、豊富なウェイクアップソース

用途例
産業用制御：モーター制御、センサー読み取り、リアルタイム制御

IoT機器：スマート家電、環境モニタリングなど

車載電子機器：ADAS、エンジン制御、インフォテインメントシステム

民生機器：家電、オーディオ、ゲーム機

医療機器：患者モニター、診断装置、ウェアラブル医療機器

ESP32 vs STM32：主な違い
| 特徴      | ESP32                    | STM32                  |
| ------- | ------------------------ | ---------------------- |
| 用途      | IoT、スマートホーム、ウェアラブル向け     | 産業、車載、医療、民生機器など幅広い     |
| プロセッサ構成 | LX6/LX7（デュアルコア）またはRISC-V | Cortex-Mシリーズ（最大デュアルコア） |
| 無線通信    | Wi-FiとBluetooth内蔵        | 一部シリーズに限定的             |
| 周辺機能    | GPIOと通信機能が限定的            | USB、CAN、イーサネット等豊富      |
| 消費電力    | IoT向けに最適化された低消費電力        | シリーズによって異なる            |
| 開発難易度   | Arduino環境で簡単に開発可能        | 高機能ゆえに設定が複雑な場合も        |
| 価格      | 機能集約で低コスト                | 機能によって価格変動あり           |

Read more: https://www.lisleapex.com/blog-esp32-vs-stm32-which-is-better
綺麗なコードはなぜ必要か──AI時代におけるプログラマの意義

私たちプログラマは、コードと向き合い、戦ってきました。クラウドシステムや分散システムなどのWeb技術が発展する中で、システム構築手法も進化してきました。CI/CDやDevOpsによってサービスのデリバリが加速すると同時に、リファクタリングやTDD（テスト駆動開発）、オブジェクト指向・関数型プログラミングといった開発パラダイムも磨き上げられ、私たちはより良い「綺麗なコード」を追い求めてきました。

では、AIが普及し始めた今、その「綺麗なコード」の意義はどうなるのでしょうか。「もうコードはAIに任せればいいじゃないか」と考える方も増えています。

## 綺麗なコードとは、"誰"のためのものか

コードは本来、コンピュータへの命令を記述するものです。しかし、コンピュータにとって、コードが読みやすかろうと読みづらかろうと、動作や性能に差はありません。むしろ、無駄な最適化を多用するとリソース消費が増え、処理速度が低下することさえあります。
それでも私たちが綺麗なコードを追求する理由は、コードが最終的に「人」に向けられたコミュニケーション手段だからです。

綺麗なコードは、開発効率を上げ、共同作業を円滑にし、運用・保守性を担保します。バグの発見が早まり、リリースは安定し、プロジェクトは持続可能になります。

「なぜそのコードが必要なのか」「何の役割を果たすのか」を考え抜き、適切に抽象化・分解し、意図をコードに込めます。彼らはまるで機械と対話してると錯覚しがちですが、実はその対象は、人です。彼らは自身が見ていた世界を、人に伝えるために「綺麗なコード」を記述していたのです。

言い換えれば、「綺麗なコード」とは、コンピュータを媒介として人と人をつなぐ、「人のためのインターフェース（IF）」なのです。


## 人の限界

生成AIは十分に整った情報をインプットしないと、抜け漏れや齟齬が発生しやすい存在でした。しかし、対話型インターフェース（Chat）の登場により、継続的なやりとりで複雑なコンテキストを交換できるようになりました。つまり、革新をもたらしたのは AIそのものではなく、**「AIと人をつなぐインターフェースのあり方」** なのです。

今、AIエージェントという言葉もありますが、「人 → AI → システム」 という新たなインターフェースが開かれつつあります。人がAIに指示を与え、AIがシステムと対話する。IFの拡張と捉えれば、とてもシンプルに理解できます。

さて、どんなにAIが賢くなっても判断を委ねる裁量は今のところ人が持っています。逆に言えば、現状のAIはあくまでも人の依頼を遂行する存在で、AIの性能が向上したところでこの関係性は崩れません。**※**
これまでは、AI側のコンテキスト限界が課題でしたが、これからは 「人類側のコンテキストの限界」 がボトルネックになるでしょう。膨大な情報を適切に分解し、整理して抽象化するのは人間の役割です。

言い換えれば、AIが進化するほど、「人の意味を抽象化し、AIとの境界を分解・定義」が重要になります、即ち「人とAIつなぐインターフェース」 がより重要になるのです。

**※** 将来的に自律的AIが登場すれば状況は変わるかもしれませんが、現状ではまだディストピア

## 「分解」と「継続」って、それ

「巨大なものを分解し、作業単位に落とし込む」──これは多くの仕事に共通する本質です。その中でも、プログラマは人とソフトウェアの境界を探りながら、ソフトウェアを駆使して巨大な構造物を実現してきました。さらに、ソフトウェアとして柔軟性を持たせ、継続的に進化させてきました。

AIという新たな役割者が参戦しても、プログラマはいなくなる とか言われても、なぜか違和感を覚えないのは、境界を探り、価値ある単位に落とし込み、長期的に維持・改善することが重要になるわけで、ぶっちゃこれってねえ？

その根底にあるのは「意味を抽象化し、境界を分解・定義し、手渡すインターフェースとする」なのです。"システム"に向ければ巨大な構造物に、"開発手法"に向ければ継続的な進化となります。そして、それを"コード"に向ければ「綺麗なコード」になるわけです。

つうわけで、プログラマほどAIとは地続きな存在は、修練として新規参入するのはまだまだ全然悪くない手だったりするかな。という話で始めたあれです。この辺りがバッドプラクティスになるぐらいAIが進化すると面白いですね！！


おまけ AIさんは気に食わなかった様子
```
論理の飛躍
「AIが進化するほど人の抽象化スキルが重要になる」という論は興味深いですが、前提となる「人がAIに指示を出す構造は変わらない」という断定にはやや疑問が残ります。

提案：この主張には、もう少し限定条件や補足（例：「汎用AIが登場するまでは」）を入れると説得力が増します。
```
統計情報の収集を手動で実施したい

Oracle Databaseにおいて、統計情報の収集を手動で実施したい場合は、`DBMS_STATS`パッケージの`GATHER_*`プロシージャを利用します。

プロシージャの一覧については、以下のドキュメントを参照してください。

https://docs.oracle.com/cd/E96517_01/arpls/DBMS_STATS.html#GUID-F04388AD-E984-42C9-8489-05B84CD050E2__I996857

**例: HRスキーマの統計情報を収集する**

```
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'HR');
```

**環境情報**

- Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
【2025年版】ChatGPTなどの生成AIのクローラーBotを拒否する方法

https://qiita.com/nokonokonoko/items/24073022b42d6c35a5b1
この記事に触発されて書きました

2025年最新版です

ChatGPTに出力させています

## OpenAI
- GPTBot
- ChatGPT-User - ChatGPTが検索するとこのUAを使います

## Microsoft
- CopilotBot - 公式非発表、不明
- Copilot-User - 公式非発表、不明
- Bingbot - 検索機能から連携している場合、可能性あり よって避ける必要がないと思う

## Google
-  Google-Extended

## Anthropic-ai
- Anthropic-ai
Claudeのトレーニングに利用される可能性のあるBot（まだ詳細は少ない

## CCbot
- CCBot
多くのLLM開発企業（OpenAIやAnthropicなど）が使っているオープンなWebクロールデータを提供する団体のBot。

## Amazon
- Amazonbot
一部では生成AIにも利用されている可能性あり。

## StabilityAI
- StabilityAI
- python-requests
- curl
現状回避困難なUAもあり

## Anthropic
- ClaudeBot
- Claude-User
- Claude-SearchBot

Yahoo知恵袋でも採用されているAIです

## robots.txt
```robots.txt
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CopilotBot
Disallow: /

User-agent: Copilot-User
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-Agent: Amazonbot
Disallow: /

User-Agent: StabilityAI
Disallow: /

User-Agent: python-requests
Disallow: /

User-Agent: curl
Disallow: /

User-Agent: ClaudeBot
Disallow: /

User-Agent: Claude-User
Disallow: /

User-Agent: Claude-SearchBot
Disallow: /
```

## .htaccess
```.htaccess
<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} GPTBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ChatGPT-User [NC,OR]
RewriteCond %{HTTP_USER_AGENT} CopilotBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Copilot-User [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Google-Extended [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Anthropic-ai [NC,OR]
RewriteCond %{HTTP_USER_AGENT} CCBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Amazonbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} StabilityAI [NC,OR]
RewriteCond %{HTTP_USER_AGENT} python-requests [NC,OR]
RewriteCond %{HTTP_USER_AGENT} curl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ClaudeBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Claude-User [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Claude-SearchBot [NC]
RewriteRule .* - [F,L]
</IfModule>
```
【セキュリティ】SQLインジェクション


# はじめに

こんにちは。アメリカに住みながら、独学でエンジニアを目指している Taira です。
現在セキュリティについて、徳丸本を使用しながら学習中ですが、そこで出てきた SQL インジェクションについてまとめてみようと思います。

## SQL インジェクションとは？

SQL インジェクション（SQL Injection）は、**ユーザーからの入力値がアプリケーションによって適切に検証・エスケープされずにそのまま SQL クエリとしてデータベースに渡されることで、悪意のある SQL 文が実行されてしまう脆弱性**です。

### 攻撃者の目的

- ログインをバイパスする
- 本来見られない機密データを抽出する
- データの改ざん・削除を行う
- データベースサーバーに対して DoS 攻撃を仕掛ける

### 仕組みの概要

通常、アプリケーションでは以下のようにユーザーの入力をもとに SQL 文を生成して、データベースへ問い合わせを行います。

```ruby
User.where("name = '#{params[:name]}'")
```

このとき、`params[:name]` に `"' OR '1'='1"` というような値を与えると、次のような SQL 文が生成されてしまいます：

```sql
SELECT * FROM users WHERE name = '' OR '1'='1'
```

このクエリは常に真となる条件を持つため、すべてのユーザー情報を取得してしまう危険性があります。これが SQL インジェクションの基本的な攻撃原理です。

このような攻撃は、データの漏洩、改ざん、アカウントのなりすまし、さらにはアプリケーション全体の制御権の奪取にまでつながる可能性があります。

## 安全な書き方（推奨）

Rails では、\*\*バインドパラメータ（プレースホルダ）\*\*を使用することで、SQL インジェクションを防ぐことができます。

```ruby
User.where("name = ?", params[:name])
```

このように書くことで、`params[:name]` の値は SQL 文に直接埋め込まれず、適切にエスケープ処理された上でクエリに渡されます。その結果、不正な入力が SQL 文の構造を壊すことができなくなり、安全に値を扱うことができます。

Active Record では他にも以下のような安全な記述が可能です：

```ruby
User.find_by(name: params[:name])
```

これらの記法は内部でプレースホルダを使用しており、安全性が保たれています。

```ruby
User.where("name = ?", params[:name])
```

## まとめ

SQL インジェクションは、ユーザー入力を適切に扱わないことで発生する重大な脆弱性です。特に Web アプリケーションでは、入力値をそのまま SQL 文に組み込むのは非常に危険です。

- 危険な例：`where("name = '#{params[:name]}'")`
- 安全な例：`where("name = ?", params[:name])`

Rails のようなフレームワークを使う場合でも、常に「プレースホルダ」や「安全なメソッド」を使うことで、SQL インジェクションを防ぐことができます。
linuxぱんぱん with docker

```bash
df -h

sudo du -h --max-depth=1 /var/lib 2>/dev/null | sort -hr

sudo find /var/lib/docker/containers/ -name '*-json.log' -exec sudo truncate -s 0 {} \;

```

```bash
docker system df
sudo docker system prune -a --volumes
sudo docker container prune
sudo docker image prune -a
sudo docker volume prune
sudo docker network prune
```

```
{
  "key": "ctrl+tab",
  "command": "workbench.action.nextEditor"
},
```
【Rails初学者】ログアウトできない RoutingErrorにハマった話

# ログアウトできない。RoutingErrorにハマった話

こんにちは、Rails学習中の者です。  
転職用のポートフォリオを作成している中で、Deviseを使った認証機能を実装していたところ
「ログアウトボタンを押したらRoutingError」
という落とし穴にハマりました。
この記事では、実際に経験したエラーとその原因、その際の解決方法をまとめておきます。

---

## 発生したエラー

```erb
<%= link_to 'ログアウト', destroy_user_session_path, method: :delete, class: 'btn btn-pink btn-sm' %>
```
### このコードを使っていたとき、ログアウトリンクをクリックした際にエラー表示
```erb
Routing Error: No route matches [GET] "/users/sign_out"
```

## エラーの原因
リンクが`method: :delete`で`DELETE /users/sign_out`を送るように指定しているのに、
実際のブラウザ上では`GET`リクエストが送られてしまっていた ことが原因です。

### なぜ`GET`に変わってしまった？
Railsでは`method: :delete`を使ったリンクは、内部的に`JavaScript（UJSまたはTurbo`が必要です。
- ページに必要なJavaScriptが読み込まれていない
- または、`turbo`が有効で`link_to`では`method: :delete`が効いていない

このどちらかが原因で、意図した`DELETE`が送れず`GET`にフォールバック → ルーティングエラー になっていました。

## 一時的な対策：`button_to`を使う
```erb
<%= button_to 'ログアウト', destroy_user_session_path, method: :delete, class: 'btn btn-pink btn-sm' %>
```
これでフォームとして`DELETE`リクエストが送られるため、確実にログアウトが動作しました。
ただ、ボタンの見た目が変わることがありました。

## 最終的な解決策：`link_to`+`Turbo`対応
```erb
<%= link_to 'ログアウト', destroy_user_session_path, data: { turbo_method: :delete }, class: 'btn btn-pink btn-sm' %>
```
Rails7以降、`Turbo`が標準になったことで`method: :delete`単体では動作しないケースがあるそうです。
そのため、`data: { turbo_method: :delete } `を明示的に指定することで対応できました。

## 学んだこと
- `link_to`に`method: :delete`を使う場合、JSが必要（UJS or Turbo）
- Rails7では`Turbo`が効いてるので、`data: { turbo_method: :delete } `を忘れない
- よくわからないときは`button_to`にするのも手

## 最後に
今回の件は、「Railsのルーティングが悪い」のではなく、JavaScriptとHTTPメソッドの連携の理解不足が原因でした。
初心者のうちは`method: :delete`と書いただけで安心しがちですが、ブラウザ側で実際にどう動くのかまで見てみると理解につながるため、引き続き注意していきたいです。
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️メタバースとAIの倫理的課題




## メタバースとAIの倫理的課題：仮想空間における設計責任と実装知見

---

## 1️⃣ はじめに：メタバース × AI、その設計に潜む“見えないリスク”

近年、**メタバース**という仮想空間上に、**AIアバターやAIエージェント**が統合されるケースが増えています。

たとえば：

* 🧍‍♀️ 学習サポートを行うAIキャラクター（VR学校など）
* 🧑‍⚖️ 法律・行政サービスを提供するAI NPC
* 🛍️ 営業・接客対応を自動化する仮想店員AI

しかし、この「AIとの仮想的な対話」には、次のような**倫理的懸念**が伴います。

* 仮想空間の中で、ユーザーが気付かずにAIから心理的操作を受けてしまう
* AIの発言が差別的・偏見的でも、“現実じゃないから”と見逃されてしまう
* データ収集や行動記録の透明性がなく、プライバシー侵害が起きうる

> **「現実ではNGでも、仮想ならOK」は通じるのか？**
> 技術者に求められるのは、ただ作ることではなく「どう作るか」への責任です。

---

## 2️⃣ 技術背景：メタバースにおけるAI統合の仕組みとは？

### 🕶️ メタバースで使われるAIの主な構成

```plaintext
[ユーザー] → [VR/ARクライアント] → [3D空間] ←→ [AIサーバー（会話 / 感情 / 判断）]
                                                 ↑
                                        [クラウドデータ / 行動ログ]
```

### 主な技術スタック

| 技術                     | 説明       | 使用例       |
| ---------------------- | -------- | --------- |
| Unity + C#             | 仮想空間構築   | AIアバター配置  |
| OpenAI API / LangChain | 会話生成     | NPC対話AI   |
| Firebase / Supabase    | データログ・認証 | 行動追跡・制限   |
| AWS / GCP / Azure      | スケーラビリティ | 高負荷対応     |
| NLP + 感情解析             | エモーション対応 | ユーザー反応の記録 |

---

## 3️⃣ 実装例：AI接客アバターに倫理的制限を組み込む（Unity + OpenAI + Firebase）

### ✨ ユースケース：仮想ショッピングモール内で接客するAI店員

要件：

* 会話内容をOpenAIで生成
* ユーザーの感情反応を分析（例：ネガティブワード）
* 不適切な発言・長時間対話をブロックする仕組み

---

### 🔧 実装ステップ概要

1. Unity上に3Dアバターを配置
2. ユーザーの音声入力 → OpenAIに送信
3. 返答とログをFirebaseに記録
4. 会話の回数/感情スコアをチェックし、制限超過で会話ブロック

---

### 🧩 Unity側 C# スクリプト（抜粋）

```csharp
if (userSession.TimeElapsed > MAX_ALLOWED_TIME || emotionScore < NEGATIVE_THRESHOLD)
{
    ShowWarning("少し休憩しませんか？");
    return;
}

var response = await OpenAIClient.GetChatResponse(userMessage);
DisplayAvatarSpeech(response);
FirebaseLogger.LogConversation(userId, response, emotionScore);
```

---

### 📦 Firebase Firestore でログ管理（構造）

```json
{
  "userId": "abc123",
  "timestamp": "2025-05-08T12:34:56",
  "userMessage": "ちょっと疲れた",
  "aiResponse": "大丈夫ですか？少し休んでもいいですよ。",
  "emotionScore": -0.4
}
```

---

## 4️⃣ 実務Tips：倫理的なAI統合のベストプラクティス

### ✅ おすすめ設計

| 対策            | 実装方法                                       |
| ------------- | ------------------------------------------ |
| ✋ 発言フィルター     | Profanityチェック / 差別ワード除外（例：HuggingFaceのモデル） |
| 🧠 セッションリミット  | 会話時間・頻度で制御（タイマー / カウンター）                   |
| 👁️‍🗨️ 可視化   | Firebaseログ + Grafanaで管理者可視化                |
| 📢 ユーザーへの説明責任 | 利用前に「AIとの対話であること」を明示（ISO/IEC 23894参照）      |

---

### ⚠️ よくある落とし穴

* ✖️ Unity内のAI実装に一貫性がなく、ログがバラバラ → クラウド側で整理・集約必須
* ✖️ 会話生成がユーザーを“煽る”ようになってしまう（AIが感情強調しすぎる）
* ✖️ 「AIだからミスしてもいい」という姿勢 → 信頼性低下とトラブルのもと

---

## 5️⃣ 応用編：AIによる仮想空間モデレーションの設計（NLP + Alert）

### 🛡️ モデレーションシステム構成

1. ユーザーとAIの会話ログをリアルタイムで収集
2. HuggingFaceのtoxicityモデルで発言評価
3. スコアが一定値を超えたらSlack通知 & 自動遮断

---

### 🖼️ 図版（最大10枚対応可能）

* 図1：Unity上でのAIアバターとの対話例
* 図2：Firebaseログ構造と分析フロー
* 図3：AIの感情解析とスコア分類図
* 図4：メタバースAIエージェントの構成図
  （※ご希望あれば画像生成可能です）

---

## 6️⃣ 結論：倫理をコードに落とし込めるのは、エンジニアだけ

### ✅ メリット

* メタバース × AIは次世代UXの中核
* 正しく設計すれば、教育・医療・接客に革新をもたらす

### ❗ リスク

* AIと仮想空間の“無責任な融合”は、現実より危険になりうる
* エンジニアは「自由に作れる」存在ではなく「意図を持って設計する」存在である

---

## 🧭 最後に：コードで守る、仮想空間の人間性

メタバースは「自由な世界」ではありますが、だからこそ**設計における倫理の重要性**は現実以上です。
エンジニアとして、私たちは“技術”と“社会”の接点を設計する立場にあります。
**次の仮想社会を構築するなら、「どう設計するか」から始めましょう。**
「やらない理由が減る」と人は動き出す話

## はじめに

初めまして！
Qiita初投稿ということで、気合いを入れて…というよりは、ゆるっと書いてみます。  
技術記事というより雑記寄りですが、もし誰かの背中をちょっとでも押せたらうれしいです。

## 朝起きられない、でも…

最近まで、朝なかなか起きられませんでした。  
目覚ましを止めて二度寝、三度寝、結果的にギリギリの時間にバタバタ。  
「自分は意志が弱いなあ」と自己嫌悪する毎日。

でもある日、「布団の横に水を置く」っていうのをやってみました。

そしたら、変わったんです。  
起きたらまず水を飲む → 頭がシャキッとする → ベッドを抜け出せる。  
この流れができたことで、朝起きるのがちょっとだけ楽になりました。

## 人は「やらない理由」が多いと動けない

「起きられない＝やる気がない」と思ってたけど、違いました。  
たぶん、「起きたくなる環境が用意されてなかった」だけだった。

気づいたのは、**人って “やらない理由” がたくさんあると動けない** ってこと。

- 着替えが面倒 → すぐ取れる位置に置く  
- 作業が始められない → 机に物が多い → 片づける  
- 書きたい記事が思いつかない → ネタ帳作っとく  

やらない理由を潰すと、気づけば「動き始めてる自分」がいる。

## 技術にも応用できる（って言ったらQiitaっぽくなる）

別にエンジニアじゃないけど、Gitの最初の設定が面倒だったときも同じでした。  
SSHとかトークンとか、最初の壁が高いと心が折れる。  
でも、一度だけ丁寧に設定を済ませて、`.gitconfig`書いといたら、それ以降はスッと動けた。

つまりこれも「やらない理由」をひとつ減らした結果なんですよね。

## まとめ

- 「やる気」はいつも出るわけじゃない  
- でも「やらない理由」を1つずつ減らしていけば、自然と動ける  
- 水を飲むだけでも、人生はちょっとだけ前に進む

---

## おまけ：最近減らした「やらない理由」

- PCの電源コード、机の裏に回してた → 表に出した 
- 夜ふかし → iPhoneのブルーライト自動カットON

---

この記事が「やる気で悩んでる誰か」に、ちょっとでも届いたらうれしいです。
初投稿でしたが、読んでいただきありがとうございます！🙇‍♂️
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️子供たちにおけるAI依存症リスク



## 1️⃣ はじめに：AIは「デジタルおやつ」になっていないか？

今や子供たちはYouTube、TikTok、生成AIアシスタント、スマートおもちゃなど、AIを搭載したテクノロジーに日常的に触れています。

便利な反面、以下のような状況が問題視されています：

* 🎯 会話型AIにハマり、現実世界との交流が減る
* 🎮 ゲームやAI動画に没頭しすぎて注意力が持続しない
* 🧠 記憶や思考をAIに依存し、自発的な学習をしなくなる

> 子供たちにとってAIは「知的補助」ではなく「知的麻酔」になっていないか？

この課題に対し、**エンジニアとしてどう技術的に向き合えるか？** 本記事では、AI依存リスクの構造を紐解きながら、技術的アプローチによる予防策や実装例をご紹介します。

---

## 2️⃣ 技術背景：依存を促進するAIの設計とは？

以下は、AIが依存を引き起こしやすい構造的特徴です。

| 特徴             | 内容                  | リスク                  |
| -------------- | ------------------- | -------------------- |
| 強化学習ベースの報酬設計   | ユーザーの反応に応じて出力内容が変わる | Dopamine（報酬）中毒に近い状態に |
| パーソナライゼーション    | 興味・好みに最適化           | 飽きることなく使い続けてしまう      |
| 無限スクロール / 自動生成 | コンテンツが尽きない          | 時間の制御が困難             |

これらの要素は大人でもハマる仕掛けですが、**自己制御能力が発達中の子供には過剰に働く**リスクがあります。

---

## 3️⃣ 実装例：AIとのインタラクションにタイムガードを入れる（Python + Streamlit）

### 🧸 想定ユースケース

会話型AIを使った教育アプリに、**使用時間制限と依存検知機能**を導入する例を紹介します。

---

### 💻 使用ライブラリ

```bash
pip install streamlit openai
```

---

### 📦 コード例（簡易版）

```python
import streamlit as st
import openai
import time

# OpenAI APIキー設定
openai.api_key = "sk-..."

# セッション開始時間を記録
if 'start_time' not in st.session_state:
    st.session_state['start_time'] = time.time()

# タイマー制限（例：15分）
MAX_SESSION_TIME = 15 * 60  # 秒

# 残り時間計算
elapsed = time.time() - st.session_state['start_time']
remaining = MAX_SESSION_TIME - elapsed

if remaining <= 0:
    st.warning("使いすぎに注意！今日はここまでにしましょう。")
    st.stop()

# チャットインターフェース
st.title("こどもAIアシスタント")
user_input = st.text_input("なにを知りたい？")

if user_input:
    with st.spinner("考え中..."):
        response = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            messages=[
                {"role": "system", "content": "こども向けにやさしく答えてください"},
                {"role": "user", "content": user_input}
            ]
        )
        st.write(response.choices[0].message.content)

# 残り時間表示
st.info(f"残り時間: {int(remaining)//60}分")
```

---

### 📸 出力例（図1〜2）

* 図1：残り時間表示付きチャットUI
* 図2：使用時間を超えた後のアラート画面

---

## 4️⃣ 実務Tips：依存を防ぐ設計のために

### ✅ 実践的なコツ

| 対策        | 技術的手法                               |
| --------- | ----------------------------------- |
| セッション制限   | 時間ベースのガード処理（上記例）                    |
| コンテンツ制御   | 会話の深さ・速度を制限する                       |
| ペアレンタルログ  | 保護者に使用履歴を通知（Firebase + LINEなどで実装可能） |
| 自己評価プロンプト | 一定時間ごとに「今の気持ち」を尋ねることで自己認識を促す        |

---

### ⚠️ よくある落とし穴

* ✖️ タイマーを設けても、裏タブで再起動されるケースあり → クッキーやセッションの永続化が必要
* ✖️ ガチガチに制限すると逆効果 → **「やめ時を教える」対話的アプローチ**が有効

---

## 5️⃣ 応用編：AI依存リスク検知システム（ベータ版）

次のような構成で「依存傾向を可視化する仕組み」も開発可能です。

### 🧠 アーキテクチャ例（図3）

* **収集**：会話ログ（内容・回数・感情ワード）を保存
* **分析**：依存スコアをMLモデルで判定（例：Scikit-learn + FastAPI）
* **通知**：SlackやLINE Notifyで保護者に送信
* **可視化**：Grafanaで時間帯別利用傾向を表示

---

## 6️⃣ まとめ：AI時代の「使い方を教える技術者」へ

### 🎯 メリット

* 適切に設計すれば、AIは子供の学習パートナーになる
* 会話ログから心理的な状態を把握するツールにもなる

### ❗ リスク

* AI自身が「依存症を助長するアルゴリズム」であることを忘れてはいけない
* 技術者は「中立」ではなく「設計者」として責任を持つ立場

---

## 🧭 おわりに：AIを子供に与えるなら、設計責任を果たそう

AIは、正しく設計すれば、未来の教育・創造性を飛躍させる力を持ちます。
しかし同時に、「時間を奪う存在」になりうることも事実。
**私たち技術者は、“倫理をコードで表現する”立場であるべき**です。
【Rails初学者】Railsでログイン後に表示内容を変えてみる(復習)

## Railsでログイン後に表示内容を変えてみる

こんにちは。
railsを学習中の者です。
転職に向けてポートフォリオ作成と並行して、CRUD操作などの復習をしています。
Railsでユーザー認証を導入したあと、  「ログインしている人にだけ特定のメニューや情報を表示したい！」と思い、実装しようと思いました。
備忘録のため、Rails初学者の自分が実際に試してうまくいった「ログイン状態による表示切り替え」の方法をまとめます。

------

## 使っている認証ツール：Devise

Deviseを使って以下の機能は導入済み：
- ログイン／ログアウト
- 新規登録
- パスワードリセット

以降ではこの状態を前提に進めます。

---

## ログイン状態の確認方法：`user_signed_in?`

Deviseを使っていると、**以下のヘルパーメソッド**が自動で使用可能。

- `user_signed_in?`：ログインしているかどうか（真偽値）
- `current_user`：現在ログインしているユーザー情報（`User`モデルのインスタンス）

---

## 実際に試した表示切り替えの実装

### 例：ログインしている人だけに「マイページ」リンクを表示したい

```erb
<!-- app/views/layouts/application.html.erb や ナビゲーションの部分 -->
<nav>
  <% if user_signed_in? %>
    <%= link_to "マイページ", user_path(current_user), class: "text-blue-600" %>
    <%= link_to "ログアウト", destroy_user_session_path, method: :delete %>
  <% else %>
    <%= link_to "ログイン", new_user_session_path %>
    <%= link_to "新規登録", new_user_registration_path %>
  <% end %>
</nav>
```

## 実装のポイント
`user_signed_in?`を使うだけで、ログイン状態に応じた分岐が可能
`current_user`を使えば、ログインユーザーの情報（名前やID）も使える

 ## 応用：ログイン時だけダッシュボード風の表示を出す
```erb
<!-- app/views/pages/home.html.erb などトップページ -->
<% if user_signed_in? %>
  <h2 class="text-xl font-bold">ようこそ、<%= current_user.name %>さん！</h2>
  <p>あなた専用のメニューはこちら</p>
<% else %>
  <p>この機能を使うにはログインしてください。</p>
<% end %>
```

## 未ログインで`current_user`を使うとエラーになることがある
ログインしていない状態で`current_user.name`などを直接呼び出すと`nil`に対してメソッドを呼ぶことになり、`NoMethodError`が出てしまうことがある。
`user_signed_in?`で存在確認してから使うのが安全。

## 補足：controller内でログイン状態を使う
ビューだけでなく、コントローラでもログイン状態に応じた処理の分岐が可能。
```ruby
# app/controllers/articles_controller.rb

def index
  if user_signed_in?
    @articles = current_user.articles
  else
    @articles = Article.all.limit(5)
  end
end
```
- `user_signed_in?`
Deviseが提供しているメソッドで、「ユーザーがログイン中かどうか」を`true/false`で返す。
- `current_user`
ログインしているユーザー（Userモデルのインスタンス）を返す。未ログイン時は`nil`。

## 学んだこと
 - deviseを使うと`user_signed_in?`と`current_user`が使える
 - ERB内で分岐して、ログイン状態によって表示内容を変えられる
 - ちょっとした分岐でUXが大きく変わる

## こんな場面に使えるらしい
- ログインユーザー専用の「マイ記事一覧」
- 未ログインユーザー向けの「新着紹介」や「登録を促すUI」
- 管理者と一般ユーザーで別の情報を表示する　など

## 最後
今回紹介した方法は、Rails初学者の自分が実際に「やってみてうまくいった」ログイン状態による表示切り替えの一例である。
最初のうちは `current_user` をどう扱うのか、`nil` のときにどう対処するのかで悩みました。
だからこそ、こうした基本的な仕組みをしっかり理解して応用できるようになりたいと感じています。

※初学者のため、知識が浅いです。
間違えていたら、すいません。
【弱小Qiitaアカウントでもここまで伸びた】投稿から13か月半、総閲覧数12万を突破した記録

こんにちは。2024年3月22日からQiitaで記事を書き始めた、**弱小アカウント代表**の私ですが、今回はちょっと驚きのデータが出たので、記録としてまとめておこうと思います。

## はじめに：あくまでも“弱小”です

まず最初に明記しておきたいのは、**私はQiitaの人気ユーザーではありません**。  
これまでにいただいた「いいね」は**125件**、ストックは**90件**ほどです。  
Qiita界隈での存在感はほぼゼロといってもいいくらいの、**本当に弱小アカウント**です。

## それでも「総閲覧数12万」を突破

記事を書き始めてから約13か月半（1年と1か月半）。  
大きなバズはほとんどありませんでした。

それでも、地道に積み重ねてきた結果、**総閲覧数は12万回を超えました。**


数値の要点


- 総閲覧数：**120,000回以上**
- 総いいね数：**125件**
- 総ストック数：**90件**

## 閲覧傾向：地味でも着実に読まれる記事たち

過去の記事を振り返ると、以下のような傾向があります：

- **500閲覧を超えている記事がほとんど**
- **全体の約3割が1,000閲覧以上**
- **投稿を休止していた期間でも閲覧数はコンスタントに伸び続けていた**

これは、**検索経由での流入**や、**ニッチでも需要があるテーマの積み重ね**による効果だと感じています。

## 詳細データはこちら

記事ごとの閲覧数や「いいね」などの分析データは、下記のGoogleスプレッドシートにまとめています。

📊 [Qiita閲覧数データ分析シート](https://docs.google.com/spreadsheets/d/1hGxCOcq872ay8_kHBlCjMdv2Ui9Tn96Fa_xDf16LK2A/edit#gid=279393869)

このスプレットシートは
下記の URL から拝借しております。
便利なツールを公開頂き感謝します。

https://qiita.com/Ryo-Nakano/items/0d794018eb22f3c88fba

## おわりに：いいねが少なくても、ちゃんと届いている

Qiitaを始めたばかりの方や、「いいねが少ないから意味がないのでは…」と悩んでいる方にお伝えしたいのは：

> **いいねが少なくても、確実に読まれているし、届いています。**

続けること、積み重ねることが一番の力になります。  
バズらなくても、評価されなくても、**“役に立つ”情報はちゃんと生きていく。**

私の記事もまさにそんな存在であったと信じています。

END

***

追記

この記事は書いた後に ChatGPT で添削しています。

元の文章から大幅に修正頂いたため
生成 AI で記事を書くのが嫌いな人には
申し訳ありません。

過去の記事を見て頂ければ分かると思いますが
生成 AI の添削が無い私の文章は
読みにくいと思いますので
申し訳ありませんが、これから投稿する記事は全て
生成 AI による記事の添削を
行っていこうと考えています。

何卒ご容赦下さい。
NEC IX ルーターで VLAN を設定する trunk & acces port

# 目的
大きな L3 スイッチを引っ張り出してこなくても、小さな IX ルーターでトランクで引っ張ってきた VLAN をアクセスポートに分割したい。

# 構成 (IX2215 <ix2215-ms-10.10.29>を使用)
Gi0.0 : DHCP (ブロードバンドルーター～インターネットへ)
Gi1.0 : 未使用
Gi2.0 port1 : access : untag vlan 10 ... (192.168.10.1/24)
Gi2.0 port2 : access : untag vlan 20 ... (192.168.20.1/24)
Gi2.0 port3 : access : untag vlan 30 ... (192.168.30.1/24)
Gi2.0 port4～7 : access : untag vlan 1 ... (192.168.1.1/24)
Gi2.0 port8 : trunk : taged vlan 10,20,30 / untage vlan 1

# ブリッジを使います
```
bridge irb enable
```
これを忘れると動きません。(何度も嵌った...ので記事にしておく)

# Gi2 のポートを分割します
```
device GigaEthernet2
  vlan-group 1 port 1
  vlan-group 2 port 2
  vlan-group 3 port 3
  vlan-group 4 port 4 5 6 7
```
アクセスポートにグループ番号を付けます。
※トランクポートを vlan-group にしても動きますが、インターフェース名が長くなるのでやってません。

# vlan 1 を作ります
```config:vlan1
interface BVI1
  ip address 192.168.1.1/24
  bridge-group 1
  no shutdown
  
interface GigaEthernet2.0
  bridge-group 1
  no shutdown

interface GigaEthernet2:4.0
  bridge-group 1
  no shutdown
```
BVI というのはブリッジインターフェースと言って、ブリッジ用の仮想インターフェースで、スイッチ SVI のブリッジ版です。 (Cisco にも SVI, BVI がある)
BVI を使わなくても動きますが、IP アドレスを振っているポートがダウンすると巻き込まれて他のポートも通信ができなくなる可能性があります。

Gi2.0 👉 Gi2 のデフォルト (untag)
Gi2:4.0 👉 Gi2 の vlan-group 4

# vlan 10 を作ります
```config:vlan10
interface BVI10
  ip address 192.168.10.1/24
  bridge-group 10
  no shutdown

interface GigaEthernet2.1
  encapsulation dot1q 10
  bridge-group 10
  no shutdown

interface GigaEthernet2:1.0
  bridge-group 10
  no shutdown
```
Gi2.1 👉 Gi2 の taged vlan 1つ目
Gi2:1.0 👉 Gi2 の vlan-group 1

# vlan 20, 30 も同様に
```config:vlan20
interface BVI20
  ip address 192.168.20.1/24
  bridge-group 20
  no shutdown

interface GigaEthernet2.2
  encapsulation dot1q 20
  bridge-group 20
  no shutdown

interface GigaEthernet2:2.0
  bridge-group 20
  no shutdown
```
Gi2.2 👉 Gi2 の taged vlan 2つ目
Gi2:2.0 👉 Gi2 の vlan-group 2

```config:vlan30
interface BVI30
  ip address 192.168.30.1/24
  bridge-group 30
  no shutdown

interface GigaEthernet2.3
  encapsulation dot1q 30
  bridge-group 30
  no shutdown

interface GigaEthernet2:3.0
  bridge-group 30
  no shutdown
```
Gi2.3 👉 Gi2 の taged vlan 3つ目
Gi2:3.0 👉 Gi2 の vlan-group 3

設定後に保存して再起動が必要なので、忘れない。
```
Router(config)# wr m
Building configuration...
% Warning: do NOT enter CNTL/Z while saving to avoid config corruption.
Router(config)# reload
Notice: The router will be RELOADED. This is to ensure that
        the peripheral devices are properly initialized.
Are you sure you want to reload the router? (Yes or [No]): y
```

# 更に vrf を掛ける
これに vrf を掛けることも可能。
```config:vlan30
interface BVI30
  ip vrf forwarding VLAN30
  ip address 192.168.30.1/24

ip route vrf VLAN30 default 192.168.30.254
```
BVI にだけ `ip vrf forwarding` を書けば良い。
vrf を追加すると IP アドレスが消えるので、再設定を忘れない。
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️ソーシャルメディアにおけるAIボット問題


## 1️⃣ はじめに：SNSは「AIの戦場」になりつつある

私たちが日常的に利用するソーシャルメディア（Twitter/X、Facebook、Instagram など）は、今や単なる「つながりの場」ではなく、情報戦・心理戦の最前線でもあります。
特に問題視されているのが**AIによって大量生成されたボットアカウントの存在**です。

* ディスインフォメーション（偽情報）の拡散
* 意図的なトレンド操作
* 世論形成の誘導（選挙など）

> 🤖「え、AIってそんなことまでやってるの？」
> 👉 はい、しかも *プログラム数行レベル* で作れてしまいます。

この記事では、**AIボットの技術構造とリスク、そしてそれを検出・対処する技術的手段**を、実装例とともにわかりやすく解説します。

---

## 2️⃣ AIボットとは？：構造と生成技術の裏側

AIボットとは、人工知能によって生成されたコンテンツを自動的に投稿・返信・いいね・フォローするプログラムのことです。
以下はその代表的な機能と使用技術です：

| 機能        | 使用されるAI技術                 | 実装例              |
| --------- | ------------------------- | ---------------- |
| テキスト投稿    | GPT系モデル (例: GPT-4, LLaMA) | トレンドワードに反応してツイート |
| 自動返信      | 文脈理解 + NLP生成              | 質問への返答、会話維持      |
| 画像生成投稿    | Stable Diffusion 等        | ミームや煽動画像の投稿      |
| 多重アカウント管理 | Selenium + Botnet構造       | 同時操作、異常検出困難      |

---

## 3️⃣ 実装例：Twitter風AIボットを自作してみる（※倫理的に安全な環境下）

**⚠️ 注意：以下はあくまで「理解目的」のサンプルです。実サービスでの無断利用は利用規約違反になります。**

### 📦 使用技術

* LLM：OpenAI GPT-3.5 または HuggingFace LLaMA
* 投稿：Mock Twitter API（PostgREST + SQLite）
* Bot制御：Python + Schedule

### 🧪 ボットのコア部分

```python
import openai
import random
from datetime import datetime

def generate_post(topic):
    prompt = f"『{topic}』についてSNS向けに140文字以内でポストしてください。"
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[{"role":"user", "content": prompt}]
    )
    return response.choices[0].message["content"]

topics = ["生成AIの危険性", "地震速報", "著作権とAI", "AIによる監視社会"]
print(generate_post(random.choice(topics)))
```

### 🛠️ Botスケジューリング

```python
import schedule
import time

def job():
    post = generate_post(random.choice(topics))
    print(f"{datetime.now()} - 投稿: {post}")
    # ここでAPI POST すれば実際の投稿に繋がる

schedule.every(30).minutes.do(job)

while True:
    schedule.run_pending()
    time.sleep(1)
```

---

## 4️⃣ 現場Tipsと落とし穴：ボット検出のポイント

### 💡 技術者が知っておくべき観点

#### ✅ ボット検出に役立つ特徴量（feature）

| 指標         | 内容             |
| ---------- | -------------- |
| 投稿間隔の規則性   | 分単位で同じパターンは要注意 |
| コンテンツの類似度  | 他アカウントと同じ文言    |
| フォロワー比     | フォロー数 ≫ フォロワー数 |
| エンゲージメント比率 | Like/RTが極端に少ない |

### 🧠 Bot検出モデルの例（Scikit-learn）

```python
from sklearn.ensemble import RandomForestClassifier

# botか否かの学習データ
# X: 特徴量ベクトル, y: bot=1, human=0
model = RandomForestClassifier()
model.fit(X_train, y_train)

# 推論
y_pred = model.predict(X_test)
```

---

## 5️⃣ 応用例：クラウド・大規模運用・可視化との統合

### 🌐 構成イメージ（図1）

* **ログ収集**：SNS API → Pub/Sub
* **バッチ検出**：GCP Cloud Functions / AWS Lambda
* **AI分析**：BigQuery + VertexAI（推論）
* **可視化**：Looker Studio / Grafana

👉 **リアルタイムBot可視化ダッシュボード** を組めば、セキュリティチームとの連携もスムーズになります。

---

## 6️⃣ まとめ：AIは「便利」だけでは済まされない

### ✅ 利点（正しく使えば）

* カスタマーサポートの自動化
* コンテンツ生成の補助
* イベント通知・翻訳など

### ❌ 課題・リスク

* 偽情報やプロパガンダの拡散
* オーガニックな議論の破壊
* 倫理的・法的責任の所在が曖昧

---

## 🔮 最後に：技術者こそ「使われ方」に敏感になるべき

AIボットの問題は、単に「悪用」されるか否かだけではありません。
**「どんな環境でも誤用され得る」という前提に立って、安全設計・監視体制を組み込むことが、AI時代のエンジニアに求められています。**

---

📌 次回予告：「メタバースとAIの倫理的課題」
【在宅エンジニア向け】これだけは買っておけ！仕事効率＆健康が爆上がりする神アイテム5選

こんにちは、在宅勤務歴2年目のインフラエンジニアです。
今回は「在宅勤務するエンジニアならこれだけは揃えておけ！」という超厳選アイテム5選を紹介します。

「仕事がはかどる」「体が楽になる」「QOLが上がる」この三拍子が揃ったものだけをピックアップしました。
とにかく体が資本なエンジニア生活、ぜひ参考にしてください！

1.[FLEXISPOT 電動式スタンディングデスク (幅120×奥行60, メモリー機能付き) 昇降デスク 高さ調節デスク パソコンデスク 人間工学 ゲーミングデスク EF1 セット (ブラック, 120×60)](https://amzn.to/42L1uVw)

✅ 特徴
メモリー機能付きの電動昇降式

幅120cm×奥行60cmで在宅ワークにぴったり

座り・立ち作業をスムーズに切替

💬 感想
長時間座りっぱなしで腰が痛い…という方に本気でおすすめです。午後の集中力も段違いにアップします。

2.[SIHOO Doro C300 オフィスチェア 椅子 デスクチェア 人間工学 テレワーク 疲れない 人体工学椅 メッシュチェア](https://amzn.to/4jRfSBQ)

✅ 特徴
自動適応ランバーサポート＋4段階調整S字背もたれ

4Dアームレスト／3Dヘッドレストで細かく調整可能

リクライニング最大130度＆通気性抜群のメッシュ構造

💬 感想
まさに「長時間作業に耐えられる椅子」。
腰も背中も楽になり、集中できる時間が明らかに伸びました。

3.[ REALFORCE RC1 キーボード 70% ブラック 日本語配列 キー荷重 45g Bluetooth 有線 バッテリー コンパクト C1HJ11](https://amzn.to/44vof16)

✅ 特徴
荷重45g、Bluetooth／有線両対応

日本語配列＆70%コンパクト設計で省スペース

長時間タイピングでも疲れにくい静電容量無接点方式

💬 感想
「仕事が楽しくなる」打鍵感。REALFORCEは価格以上の満足感があるので、毎日タイピングする人は投資する価値大です。

4.[ソニー ワイヤレスノイズキャンセリングイヤホン WF-1000XM5【VGP2025金賞】完全ワイヤレス／圧倒的ノイズキャンセリング／小型軽量／Alexa搭載／IPX4防滴](https://amzn.to/4m4uoHK)

✅ 特徴
業界最高クラスのノイズキャンセリング

Web会議でも安心のマイク性能

軽量で耳が疲れないフィット感／最大8時間再生

💬 感想
周囲の生活音や雑音を完全に遮断。自宅でもカフェ並みに集中できます。
集中タイム＆通話両方に大活躍！

5.[ [モニターアームセット]【Amazon.co.jp限定】アイリスオーヤマ モニター 23.8インチ + モニターアーム 幅50cm スチールタイプ（スピーカー内蔵）](https://amzn.to/4m6Wmme)

✅ 特徴
スピーカー内蔵のフルHD 23.8インチモニター

USB×2＋HDMI×2と接続性も◎

モニターアーム付きでデスクが広く使える

💬 感想
コスパ最強モニターセット。画面サイズも十分で、机のスペースも無駄なく活用できるのがありがたいです。

✅まとめ
[FLEXISPOT 昇降デスク EF1セット](https://amzn.to/42L1uVw)
[SIHOO Doro C300 チェア](https://amzn.to/4jRfSBQ)
[REALFORCE RC1 キーボード](https://amzn.to/44vof16)
[ソニー WF-1000XM5 イヤホン](https://amzn.to/4m4uoHK)
[アイリスオーヤマ モニター＋アームセット](https://amzn.to/4m6Wmme)

📝あとがき
在宅勤務の作業環境は、「椅子と机にいくらかけられるか」で全然違います。
最初はちょっと勇気がいるかもしれませんが、自己投資としてのリターンは本当に大きいです。

迷っている方は、まず1つから取り入れてみてください！
プログラミングは「設計」か「量産」か？～誤解を解き、エンジニアが目指す真の効率化～

ビジネスの現場では、「もっと多くの機能を、もっと早く開発してほしい」という期待を耳にすることがあります。
これは、プログラミングを工場での製品製造のような「量産」作業と捉えていることから生じる誤解かもしれません。

一方で、エンジニア自身も「もっと効率的に、質の高いソフトウェアを届けたい」と常に考えています。

この記事では、まずプログラミングがなぜ単純な「量産」ではないのか、その「設計」としての側面を解説します。
そして次に、エンジニアがその「設計」を工夫することで、いかにして「量産しやすい状態」、つまり真の効率化を目指せるのかを掘り下げていきます。

### なぜプログラミングは単純な「量産」ではないのか？ ～エンジニア以外の方へ～

ソフトウェア開発の現場では、しばしば「人や機械を増やせば生産性が上がる」という工場モデルの発想が当てはまらないことがあります。
それは、プログラミングが本質的に以下の特性を持つ「設計」活動だからです。

#### 思考と創造のプロセス:
 
プログラミングは、キーボードを叩く単純作業ではありません。
与えられた課題を深く理解し、それを解決するための論理を組み立て、最適な構造を設計し、そして初めてコードという形に落とし込む、一連の思考と創造のプロセスです。
 目に見える機能の裏側には、無数の判断と選択が隠されています。
 
#### 見えない部分の重要性:
 
ユーザーが直接触れることのない部分、例えば、将来の変更に耐えうる柔軟なアーキテクチャ、効率的なデータ処理、セキュリティの担保、そして他のエンジニアが理解しやすいコードの書き方など、これら「見えない部分」の設計がソフトウェアの品質や寿命を大きく左右します。
安易に「量産」を求めると、この見えない部分が疎かになり、後々大きな問題（技術的負債）となって跳ね返ってくることがあります。

#### 変化への対応:
 
ビジネス環境やユーザーの要求は常に変化します。ソフトウェアもそれに合わせて進化し続けなければなりません。
そのためには、変更に対して柔軟に対応できる「設計」が不可欠です。場当たり的な修正を繰り返す「量産」的なアプローチでは、すぐに限界を迎え、改修が困難な、いわゆる「塩漬け」のシステムを生み出してしまいます。

つまり、プログラミングにおける「設計」とは、単に見た目や機能を作るだけでなく、将来にわたって価値を提供し続けるための土台作りなのです。

### エンジニアが目指す「賢い量産」とは？ ～エンジニアの皆さんへ～

プログラミングが「設計」であることは論を俟ちません。
しかし、私たちエンジニアは、その「設計」を工夫することで、開発プロセスを大幅に効率化し、「量産しやすい状態」を作り出すことも可能です。
これは、前述した単純な工場モデルの「量産」とは異なり、知的な工夫に基づいた「賢い量産」と言えるでしょう。

その鍵となるのは、やはり**「設計」**です。

#### ルール化とパターン化によるスコープの限定:
 
コーディング規約の整備、共通処理のライブラリ化、デザインパターンの適用など、開発における「ルール」を明確にし、「パターン」を見出すことで、個々のエンジニアが考えるべき範囲（スコープ）を限定します。これにより、判断に迷う時間が減り、個々のタスクに集中しやすくなります。

#### 自動化の徹底:

パターン化された箇所や反復作業は、積極的に自動化の対象とすべきです。

#### コード生成:

Laravelのようなフレームワークが提供する`artisan`コマンド（例: `php artisan make:controller TaskController --resource --model=Task`）は、定型的なコードの雛形を瞬時に生成し、開発の初速を上げます。
※Laravelではbladeを使うことで簡単に自動生成コマンドを作成することができます（別記事で詳細を書きます）

#### テスト自動化:

パターン化された機能は、テストケースもパターン化しやすくなります。
単体テスト、結合テスト、E2Eテストを自動化することで、品質を担保しつつ、回帰テストの負担を大幅に軽減できます。一般的なテスト観点については、AIの方が網羅的な知識を持っている可能性もあり、将来的にはDevinのようなAIがテスト作成を支援することも期待されます。

#### CI/CD (継続的インテグレーション/継続的デリバリー):

ビルド、テスト、デプロイのパイプラインを自動化することで、手作業によるミスを防ぎ、迅速かつ安全なリリースを実現します。

 **生成AIの活用**:
 
単純なコードスニペットの生成、ドキュメント作成の補助、あるいは新たな視点でのアイデア出しなど、生成AIを賢く活用することで、開発の様々なフェーズで効率化を図れます。
これらの取り組みにより、「設計」という創造的な活動の質を維持しつつ、開発プロセス全体を効率化し、ある種の「量産体制」を構築することが可能になります。
これにより、エンジニアは単純作業から解放され、よりドメイン知識が求められる高度な課題解決や、新しい技術の探求といった、本質的な業務に集中できるようになるのです。

### まとめ

#### エンジニア以外の方へ:

プログラミングは、目に見える機能だけでなく、その裏にある複雑な「設計」によって支えられています。
短期的な開発量だけでなく、長期的な視点での品質や保守性をご理解いただけると幸いです。

#### エンジニアの皆さんへ:

私たちは「設計者」であると同時に、その設計を活かして「賢い量産」を実現する工夫も求められています。
ルール化、パターン化、そして自動化を推進し、より生産性の高い開発を目指しましょう。

プログラミングの「設計」としての側面と、「量産」を可能にする工夫。この両輪を理解し、それぞれの立場から協力し合うことで、私たちはより良いソフトウェアを、より効率的に世に送り出すことができるはずです。

---
### 今日の一言
 
 Sentry導入したいなぁ
 デバッグの効率が大幅に上がる未来が見える
初心者がフリーランスエンジニアになるまでのステップ

Udemyを中心に、初心者から高単価案件に参画できるフリーランスエンジニアになるまでのそれぞれのフェーズを一覧にまとめてみました。
今あなたはどのフェーズにいて、どんな悩みがあって、どのように解決していけばいいのかをまとめたので参考になれば嬉しいです。
JavaScriptの学習をメインに書いています。
もし、ここは違うんじゃない？みたいに感じた方はコメントをいただけると幸いです。


| フェーズ             | 主な学習内容                  | よくある困難             | アクション                 |
| ---------------- | ----------------------- | ------------------ | --------------------- |
| 1. 基礎理解          | JavaScriptの基本文法、環境構築    | 用語が理解できない、コードが動かない | 基本単語を調べ、動くまで試す        |
| 2. 用語習得          | コールバック、クロージャー、Promiseなど | 説明を読んでも理解できない      | 分かりやすい解説を探し、自分なりにまとめる |
| 3. 概念理解          | 基本アルゴリズム（配列操作、条件分岐）     | ロジックが思いつかない        | サンプルコードを動かして理解する      |
| 4. コード模倣         | Udemyのコードをそのまま実装        | 実行エラーで詰まる          | 解答と自分のコードを比較し原因分析     |
| 5. 基本問題解決        | 簡単な演習問題に挑戦              | 解答が思いつかない          | 問題を細かく分解して考える         |
| 6. 解答分析          | 解答を見てコードを理解             | 理解した気になっている        | コメントをつけてコードを再度書き直す    |
| 7. 自力解答          | 同様の問題を次の日に解く            | 前日理解したはずが忘れる       | 毎日解いて定着させる            |
| 8. 応用力強化         | 少し難しい問題やプロジェクト形式        | パターンが違うと解けない       | 公式ドキュメントを読んで他の解法を模索   |
| 9. 実践練習          | 個人アプリを作成                | 何から手をつけるかわからない     | 小さな機能単位で実装する          |
| 10. 自作アプリ公開      | GitHubに公開、Qiitaに解説      | コードが雑で不安           | 他者のフィードバックをもらう        |
| 11. 応募用ポートフォリオ作成 | CRUDアプリ、認証機能付き          | 他との差別化が難しい         | 自分の強みを活かす機能を追加        |
| 12. 技術面接対策       | よく聞かれる技術的質問を準備          | 具体例を聞かれると詰まる       | 実際に作ったアプリを説明できるように    |
| 13. 面接実践         | エージェント経由で面談を受ける         | うまくアピールできない        | 成果物のプレゼン資料を用意する       |
| 14. 初案件獲得        | フリーランスとしてデビュー           | 仕様が曖昧で混乱           | クライアントと密にコミュニケーション    |
| 15. 高単価案件参画      | 大規模プロジェクト経験を積む          | 設計力や技術選定で苦戦        | アーキテクチャ設計の学習を深める      |
猿でもわかるAIの倫理・リスクシリーズ 🐵⚠️AIアイデンティティ盗用問題

 

 

## 「AIアイデンティティ盗用問題」と開発者が知っておくべきリスクと対策

---

## 1️⃣ はじめに：AIが“あなた”になる時代？

最近、生成AIの進化により、「誰かに成りすますAI」が急増しています。

* 他人の顔を使った**ディープフェイク動画**
* 有名人の声で話す**AIボイスクローン**
* SNSで自動応答する**AI人格ボット**

こうした技術は一見面白く、有用にも見えますが、\*\*「アイデンティティの盗用」\*\*という深刻な倫理問題を孕んでいます。

> 💡 本記事では、技術者として知っておくべき「AIによるアイデンティティ盗用」の仕組みと対策について、実装例を交えつつ掘り下げます。

---

## 2️⃣ 技術背景：「盗用」はどこで起きるのか？

以下の技術が組み合わさることで、\*\*“誰かになりすますAI”\*\*が構築されます：

| 技術領域          | 具体例                      | リスク           |
| ------------- | ------------------------ | ------------- |
| 音声合成          | Tortoise TTS, ElevenLabs | 有名人の声模倣、詐欺通話  |
| 顔生成           | StyleGAN, DeepFaceLab    | フェイクポルノ、偽証明写真 |
| NLP + Chatbot | GPT, RAGベース人格AI          | SNSでの“偽人格”運用  |
| データ学習         | Scraping + Fine-tuning   | プライバシー侵害、人格盗用 |

特に**公開されている音声・画像・テキストデータ**から個人の「キャラクター」を再現できてしまう点が問題です。

---

## 3️⃣ 実装例：「AIボイスクローン」の危険性を体験する

ここでは、**Tortoise TTS**を使って特定の声を再現する手順を紹介します。
※あくまで**教育・倫理啓発目的**での実験です。

### ⚠️ 注意：無許可の音声再現は違法または倫理的問題があります。

---

### 💻 セットアップ

```bash
git clone https://github.com/neonbjb/tortoise-tts.git
cd tortoise-tts
pip install -r requirements.txt
```

---

### 🧠 音声再現のサンプルコード

```python
from tortoise.api import TextToSpeech
from tortoise.utils.audio import load_voice

tts = TextToSpeech()

# 事前に収録した音声を使って個人の話し方を学習
voice_samples = load_voice('my_target_voice')  # 自分の声であることが前提

# クローン生成
output = tts.tts_with_preset(
    text="こんにちは、これはAIが話しています。",
    voice_samples=voice_samples,
    preset="fast"
)

output.save("clone_voice.wav")
```

### 🔊 結果例（図1：波形表示、図2：スペクトル比較）

実際に再現された音声は**非常にリアル**で、第三者には本物かAIかの判別が難しいレベルになります。

---

## 4️⃣ 実務での注意点と対策

### ✅ 現場での注意事項

| 項目             | 対策                                |
| -------------- | --------------------------------- |
| 音声や顔を扱うAIプロダクト | 利用規約に明記＋ユーザー同意                    |
| 公開APIの設計       | 再学習や人格模倣を防ぐ制限設計（Rate Limit, 出力検査） |
| 社内教育           | AI倫理トレーニング、責任共有のルール作り             |
| RAG型人格AI       | リアル人物との混同を避け、注意書き必須               |

---

### ⚠️ よくある落とし穴

* 「音声は公開されてるから使ってOK」→✖️人格権の侵害にあたる可能性あり
* 「出力はAIだから免責」→✖️開発者にも連帯責任が問われるケースあり（例：ボイス詐欺）
* 「オープンソースだから自由」→✖️使用目的によっては訴訟対象に

---

## 5️⃣ 応用：AI同意マネジメント × インフラ構成

企業でAIを扱う際には「**Consent Layer（同意管理層）**」を構築することが重要です。
以下はその一例です：

### 🏗️ インフラ構成例（図3）

* 🎙️ 音声/顔/テキストの入力
* 🧠 AI生成：TTS / GAN / GPT系モデル
* 📄 同意チェック：Consent DB + 判定ロジック
* ☁️ 保管：S3 + 署名ログ（CloudTrail or GCP Audit）

> これにより、AI生成の前後で「**利用者の人格に関する合意が得られているか**」を追跡可能になります。

---

## 6️⃣ まとめ：AIが“誰かを模倣する”ことの責任

### ✅ メリット

* 声や姿の再現でバリアフリーなUXが実現可能（例：読み聞かせアプリ）
* キャラクターIP展開（VTuberなど）で新たな市場が広がる

### ❌ リスク

* プライバシー侵害・人格権侵害
* フェイクニュース・詐欺への悪用
* 開発者が意図せず訴訟対象になる可能性

---

## 🎯 終わりに：技術者こそ、人格を守る最前線に立とう

生成AI時代の今、我々エンジニアに求められるのは「技術力」だけでなく、**倫理を設計できる力**です。

開発者が「これは危ないかも」と一歩引いて考えることが、未来の安全なテクノロジーの礎になります。

---

 
ご希望であれば、以下の図（最大10点）を含むビジュアル資料も提供可能です：

* 音声波形とAI音声の比較図
* Tortoise TTSフロー図
* AI生成同意管理のインフラ構成図
* ユースケース比較チャート（倫理的 vs 悪用）
Pythonのバージョン管理にHomebrewとpyenvを使用する流れ

```php:homebrewの確認
brew -v
```
```php:pyenvの確認
pyenv -v
```

https://brew.sh/ja/
```php:Homebrewのインストール
/bin/bash -c 
"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

```php:pyenvのインストール
brew install pyenv
```

```php:権限の対応
#You should change the ownership of these directories to your user.
sudo chown -R <ユーザー名> /usr/local/share/zsh /usr/local/share/zsh/site-functions

# And make sure that your user has write permission.
chmod u+w /usr/local/share/zsh /usr/local/share/zsh/site-functions
```

```php:シェルの環境変数などの定義を追加
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
echo 'export PATH="$PYENV_ROOT/shims:$PATH"' >> ~/.zshrc
echo 'eval "$(pyenv init -)"' >> ~/.zshrc
source ~/.zshrc
```

```php:pyenvのリスト確認
pyenv install --list
```

```php:今回は3.12.10を使用
pyenv install 3.12.10
```

```php:警告が出るので先にやっておいた方が良いライブラリインストール
brew install xz
```

```php:バージョン確認
python --version
```

```php:バージョンの選択
pyenv global <バージョン指定 例：x.xx.xx>
```

```php:バージョンが変わらない場合の対応　パスの設定　
eval "$(pyenv init --path)"
```
「ソースはReddit」はNG！Qiita CLIのQiitaForbiddenOrBadRequestErrorエラーへの対処

## はじめに
QiitaとZennへ並行して投稿していると小さな違いに苦戦することはないでしょうか？
今回はZenn CLIでは投稿できた記事が、Qiita CLIでは「QiitaForbiddenOrBadRequestError」で失敗する原因と対処法をゆるく共有します。

## 発生したエラー
Qiita CLI（ver. 1.6.2）を使っていつも通り投稿を試みました。
```
npx qiita publish my-article.md
```

すると`Qiita APIへのリクエストに失敗しました` が表示され投稿できませんでした。

このメッセージやスタックトレースのQiitaForbiddenOrBadRequestErrorからは一体何がダメなのか判断できません。ソースコード（ `node_modules\@qiita\qiita-cli\dist\commands\publish.js` ）も確認しましたがAPI側が返すエラーメッセージそのもので手がかりは見つかりません。
```
Qiita APIへのリクエストに失敗しました
  記事ファイルに不備がないかご確認ください
  または、Qiitaのアクセストークンが正しいかご確認ください
```

<details><summary>スタックトレース全体</summary>

```
QiitaForbiddenOrBadRequestError: {"message":"Forbidden","type":"forbidden"}
    at Object.publish (***\node_modules\@qiita\qiita-cli\dist\commands\publish.js:113:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async exec (***\node_modules\@qiita\qiita-cli\dist\commands\index.js:41:9) {
  [cause]: QiitaForbiddenError: {"message":"Forbidden","type":"forbidden"}
      at QiitaApi.request (***\node_modules\@qiita\qiita-cli\dist\qiita-api\index.js:83:23)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async QiitaApi.post (***\node_modules\@qiita\qiita-cli\dist\qiita-api\index.js:107:16)
      at async QiitaApi.postItem (***\node_modules\@qiita\qiita-cli\dist\qiita-api\index.js:171:16)
      at async ***\node_modules\@qiita\qiita-cli\dist\commands\publish.js:94:28
      at async Promise.all (index 0)
      at async Object.publish (***\node_modules\@qiita\qiita-cli\dist\commands\publish.js:108:9)
      at async exec (***\node_modules\@qiita\qiita-cli\dist\commands\index.js:41:9)
}
Qiita APIへのリクエストに失敗しました
  記事ファイルに不備がないかご確認ください
  または、Qiitaのアクセストークンが正しいかご確認ください
```
</details>

## 回避策と原因の特定
不思議なことに `private: true` に限定共有記事に設定すると投稿できました。
そのためQiitaのWeb画面で公開設定を「全体公開」に変更しようとしました。
やはりエラーにはなるのですが、手がかりとなるエラーメッセージが表示されました。
> 本文に投稿禁止の内容が含まれています。限定共有投稿後、サポートにお問い合わせください。  
> Expanded link urlsに投稿禁止の内容が含まれています。

なるほど...どうやら記事内のリンク（Expanded link urls）にQiitaの投稿ポリシーに抵触するものが含まれていた可能性があります。今回は**Markdown中のRedditのURLを記載したリンクを削除**すると、CLIから全体公開で投稿できるようになりました。

ちなみに投稿に失敗したのはこちらの記事です。画像も含まれず基本的なMarkdowm記法のみですが、ページ最下部にRedditへのリンクを情報源として掲載していました。
- [Zenn版「UEFI Shellへ入れない！？Minisforum MS-01のBIOSアップデート」](https://zenn.dev/tsukimi_site/articles/homelab_server_update_minisforum_ms-01_bios_1_26)
- [Qiita版「UEFI Shellへ入れない！？Minisforum MS-01のBIOSアップデート」](https://qiita.com/tsukimi_site/items/14352396215f9b7f892b)

## まとめ：Qiita CLIで心当たりのないエラーが出たときのチェックリスト
1. Qiita CLIでは`private: true` にして限定共有記事として投稿してみる。
2. 投稿に成功したらWeb画面へ移り「全体公開」へ変更してみる。
3. 表示されたエラーメッセージを参考に修正していく。

## 感想
Qiitaのエラーメッセージ、Webのほうがちょっとだけ親切です。
例外処理の作り込みは本当に大変だと思います。CLIもがんばれ！  
「ソースはReddit()」だったのが悔やまれますが、笑って済ませましょう。
【イベントサマリ】マルチテナントSaaS設計の落とし穴と成功の鍵：実践者の声から学ぶ

# はじめに

『マルチテナントSaaSアーキテクチャの構築』を題材に開催したウェビナーの内容を簡単ですが、以下のようにまとめました。[アーカイブ配信](https://info.tc3.co.jp/saas-architecture-aws-tc3-webinar-0417) も実施されていますので、ぜひ合わせてご確認ください！

## SaaS開発は今、転換期に
- 生成AIや複数プロダクト戦略の影響で複雑性が増大
- 必要なのは「技術知識」ではなく  
  🧩 チームで共有できる共通言語  
  🔧 スケールができ、ユーザー体験を補助する設計思想

🎤 登壇：AWS Japan 河原氏 × TC3 須藤氏
📘 書籍『マルチテナントSaaSアーキテクチャの構築』をフィーチャー
👉 [視聴ページへアクセス](https://info.tc3.co.jp/saas-architecture-aws-tc3-webinar-0417)

# ウェビナーハイライト

## :one: SaaS開発の“基本思想”を共有しよう
- SaaSの本質は「技術」ではなく「ビジネスモデル」
- 「摩擦のないサービス提供」が前提
- 書籍第1章「SaaSマインドセット」がチームの共通言語に
- 部門を超えた“視点の統一”が成否を分ける

## :two: スケーラビリティを支える設計視点
- アーキテクチャ基礎：  
  アプリケーションプレーンとコントロールプレーン
- コントロールプレーンを疎かにすると運用で詰まる
- オンボーディング設計が体験を決める
- SaaS Identity設計はB2Bに不可欠

## :three: マルチテナント設計の実践論
- リソース分離モデル：サイロ vs プール vs 混合型
- ティアリング戦略は価格ではなく構造の話
- 共通アカウント基盤の重要性  
  → TC3「Tactna」が提供する価値とは？

# まとめ：SaaS成功の鍵は“共通言語”
- 技術選定よりも構成理解と認識の統一が第一歩
- 本ウェビナーでの学び：
  - アーキテクチャは体験をより良くする重要な要素
  - チーム全体の視点統一が設計の出発点

📘 書籍：『マルチテナントSaaSアーキテクチャの構築』    
👉 [視聴ページへアクセス](https://info.tc3.co.jp/saas-architecture-aws-tc3-webinar-0417)