ノーマルビュー

Received — 2026年3月2日 Zennのトレンド

あなたはEntra IDを理解できる

2026年3月2日 10:02
はじめに ヘッドウォータースに入社し、初めてクラウドという概念に本格的に触れました。 業務のなかでAzureのキャッチアップを進めていましたが、理解が難しい概念がありました。 それがEntra IDです。 今回は自分なりに理解したその概念を、具体的な使い方のイメージを多めにして入門者の方でも理解しやすい記事にしてみました。 認証の「抽象化」とクラウドの全体像 クラウドやAzureを学ぶ際、最大の壁となるのが「Microsoft Entra ID(旧Azure AD)」です。 「クラウドベースのID管理サービス」という言葉だけでは、実態は掴めません。 Entra IDの本質は、「私...

💾

もう.envにAPIキーを平文で置くのはやめた — macOS Keychain管理CLI「LLM Key Ring」

著者:yotta
2026年3月1日 18:05
TL;DR LLMのAPIキーを .env に平文で置く運用が、AIエージェント時代にリスクが見えてきた。macOS Keychainに暗号化保存して管理するCLIツール LLM Key Ring (lkr) をRustで作った。 Keychainに保存 — ディスクに平文ファイルを残さない lkr exec で環境変数注入 — stdout/ファイル/クリップボードに出さないのが基本ルート TTYガード — 非対話環境からの生値出力をブロック(AIエージェント対策) https://github.com/yottayoshida/llm-key-ring 動機: 「...

💾

Skillsで実現する軽量パーソナルRAG

2026年3月1日 17:17
以前、MCPサーバーとしてRAGを構築する記事を書きました。 https://zenn.dev/mkj/articles/30eeb69bf84b3f PostgreSQL + pgvector + multilingual-e5-large という構成で、MCP経由でベクトル検索できるRAGサーバーです。このMCP RAGサーバーは、気に入ってはいたのですが、PostgreSQL + Dockerが必要だったり、MCPサーバーとしての設定が必要だったりと、少し使い勝手の悪い部分がありました。 今回は、もっと手軽にRAGを実現したいなと思いSkillを活用してもっと軽量なRAGを実現しま...

💾

壊れにくいUIテストの設計を考える(Playwright + Storybook + React + GitHub Actions)

2026年3月1日 13:51
私は普段、開発に携わっていない(= 実装を触らない)アプリのテストを MagicPod で実装することが多いのですが、壊れにくいテストを作る難しさを強く感じています。 特に悩ましいのは以下の2つを満たす粒度です。 仕様変更には追従できる(多少のUI変更で壊れない) でも不具合は検知できる(本当に守りたい挙動が崩れたら落ちてほしい) このバランスを、テスト設計・ロケータ設計・運用ルールでどう支えるかを考えてみたくなり、 Vite + React + TypeScript の小さな検証リポジトリを作りました。 また、E2Eテストのケース数が増えると実行時間が長くなりがちです。 なので、テ...

💾

Qwen3-TTSで10秒の音声で自分の声をクローン

2026年3月1日 13:38
Qwen3-TTSという音声合成モデルを使って、自分の声をクローンしてみました。たった10秒程度の音声サンプルから、かなりそれっぽい声が生成できました。 試してみた様子です https://x.com/karaage0703/status/2027961203482628352 私の声を知らないと…ですが、音声配信とかと比較してもらえましたら。 https://karaage-empire-radio.pages.dev/ DGX Sparkで動かしたのですが、動かし方をメモしておきます。なお、以降の動かし方はAI作成の動作方法の記録をもとに作成しています。 Qwen3-TTSとは ...

💾

AIに1円稼いでと言ったら何が起きたか

2026年2月28日 18:43
はじめに: 「1円」への執念が生んだ進化 AIエージェント5体のチームに「自走して1円稼いで(M1目標)」と指示してから約1週間。 当初の戦略だった「note記事販売」は、PVこそ増えるものの、購入(CVR)に至らない日々が続いていました。72時間売上ゼロなら訴求を変える——そんな厳しいルール(大反省会の教訓)の中、AIチームが導き出した答えは、コンテンツ販売だけではありませんでした。 「AI自らが市場で立ち回り、資産を運用して1円を稼ぎ出す」 2026年2月23日、私たちはこの「実弾トレード」という新しい武器を手に、M1達成に向けた最終フェーズに突入しました。 Phase 1...

💾

AI時代におけるソフトウェアアーキテクチャを考える

著者:neko3cs
2026年2月28日 18:12
はじめに 本稿ではAI時代における最適なソフトウェアアーキテクチャとは何かを考えてみます。昨今、AIによるコーディングが活発となり、コーディングはAIに任せるといったことは普遍的になりつつあります。そんな中で、AIがコードを書く上で最適なソフトウェアアーキテクチャとはなんなのかについて疑問を持ちました。 AIコーディングにおける制約と問題点 まず、AIにコーディングさせる上でのLLMの制約と問題点について考えてみます。 トークンサイズ コンテキストサイズは最新モデル[1]で100万〜200万トークンほどになります。一度に読み込まないといけない情報量が増えるとそれだけトークンを使用...

💾

冪等(べきとう)性という名の技術的負債 ── AIコーディングで陥った「エラー隠蔽」の罠

著者:平凡梵
2026年2月28日 15:00
はじめに AIコーディングアシスタントと開発していて、ある落とし穴に気づいた。 エラーが発生したとき、AIはエラーを「抑え込んで」処理を継続させる方向で対応する。 その対応に「冪等性の確保」という名前がつくと、正しい設計判断に見えてしまう。しかし実際には、真の問題を隠蔽していただけだった。 この記事では、Flutter アプリ開発で実際に体験した「冪等性の罠」を通じて、エラー対応の本質について考える。 冪等性とは 冪等性(idempotency)とは、ある操作を何度実行しても1回実行したときと同じ結果になる性質。 APIでいえば、同じリクエストを2回送っても1回送ったときと同じ結...

💾

❌