Llm

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方 @yousukezan 氏のポストが、AI 駆動開発における秘密情報管理の盲点を端的に指摘しています。 Claudeが社内に広がるほど、.envが危ない。Cowork時代に必要なのは「便利さ」より秘密情報の置き場所 引用元の Qiita 記事では、Claude Code や Cowork が「チャットで質問するだけのツール」から「ローカルファイルに直接アクセスする開発エージェント」へ進化したことで、従来の .gitignore だけでは守りきれない脅威が生まれていると論じています。本記事では、この問題の技術的背景と実践的な対策を掘り下げます。 何が変わったのか — 脅威モデルの転換 従来の開発ワークフローでは、.env ファイルの脅威モデルは明確でした。 脅威 対策 Git リポジトリへの混入 .gitignore に記載 本番環境への漏洩 環境変数やシークレットマネージャで注入 他人のマシンへの流出 ローカルに置く前提なので問題なし ところが、Claude Code のような AI エージェントがローカルファイルを直接読み書きする時代になると、第三の脅威が加わります。 新しい脅威 内容 AI エージェントによる読み取り .env がツールの入力コンテキストに載る 意図しないクラウド送信 読み取った内容が LLM の API リクエストに含まれる 組織内の横展開 Cowork で複数人が同じプロジェクトを触る際の露出 IPA「情報セキュリティ 10 大脅威 2026」でも「AI の利用をめぐるサイバーリスク」が初選出で 3 位にランクインしており、この脅威モデルの転換は業界全体の認識となりつつあります。 Claude Code は .env をどう扱うのか 自動読み込み問題 セキュリティ研究者 Dor Munis 氏の調査によると、Claude Code は .env、.env.local などのファイルを自動的に読み込み、API キーやトークンをメモリに展開していることが判明しています。プロキシ認証情報が意図せず読み込まれ、HTTP 407 エラーとプロキシ料金の異常な高騰として問題が顕在化しました。 ...

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線 Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線 エラー監視ツール Sentry が提供する機能の多くは、Claude Code のようなAI コーディングエージェントで代替できるのではないか — LLM の分析能力が向上した2026年、この疑問は自然なものです。 結論から言えば、分析レイヤーは Claude Code で代替可能（むしろ得意）であり、データ収集レイヤーもスタックがパターン化されていれば自前の共通ライブラリで実装可能です。この境界線を正しく理解することが、最適なエラー監視体制を組む鍵になります。 エラー監視の3層構造 エラー監視は、以下の3つのレイヤーで構成されています。 エラー監視 = データ収集（ランタイム計装） + データ蓄積（基盤） + 分析（判断） レイヤー Sentry Claude Code で代替した場合 データ収集 SDK がランタイムに計装 ??? （ここが問題） データ蓄積 Sentry のイベント基盤 CloudWatch / 自前ログ基盤 分析 Seer / ダッシュボード Claude Code（MCP / バッチ） Claude Code が強力なのは右端の「分析」レイヤーです。しかし、左端の「データ収集」が貧弱だと、分析対象のデータ自体が不足します。 Claude Code で代替できる部分 1. インテリジェントグルーピング → LLM の方が得意 Sentry はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。 ...

クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時 クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時 2026年2月末、AI 業界に衝撃が走りました。Anthropic が米国防総省からブラックリスト指定を受け、Google の Gemini がイスラエル軍に無断提供されていた疑惑が浮上。@wmoto_ai（生ビール）さんのポストは、多くのエンジニアが感じた危機感を端的に表現しています。 「イスラエルの件、Anthropicの件然り一気に物騒になってきたので本気でローカルLLMへの移行先決めとかないとな..」 この記事では、2つの事件の背景と、クラウド LLM 依存が孕むリスクを整理します。 事件1: Anthropic vs 米国防総省 — AI 安全性を巡る全面対立 何が起きたか 2026年2月、米国防長官 Pete Hegseth は Anthropic に対し、Claude の軍事利用におけるセーフガード（安全装置）の全面撤廃を要求しました。 Anthropic が拒否したかったのは、以下の2点です。 米国民に対する大量監視 への Claude の利用 人間の関与なしに発射する自律兵器 への Claude の利用 時系列 日付 出来事 2月16日 Pentagon が Anthropic との関係見直しを示唆 2月25日 ブラックリスト化の第一歩が報道 2月26日 Hegseth が 2/27 17:01 を最終期限に設定。Anthropic CEO Dario Amodei が拒否を表明 2月27日 トランプ政権が Anthropic を「サプライチェーンリスク」に指定、政府業務から排除 2月27日 OpenAI が即座に国防総省との契約を発表 2月28日 シリコンバレー全体への影響が報道される Dario Amodei の声明 “We cannot in good conscience accede to their request.” （彼らの要求に良心に従って応じることはできない） ...

バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディング（Vibe Coding）で AI にUIを作らせると、「動くけどダサい」「素人っぽい」という壁にぶつかる人は多いでしょう。 @7_eito_7（えいと）さんのポストは、この問題に対するシンプルかつ強力な解決策を提示しています。 「バイブコーディングでデザインを20倍よくする裏技。それはUIの種類を覚えること。2,500以上のデザイン例がまとまったThe Component Galleryでデザインの知識を増やす。そして『App Bar + Drawer + Card Grid + Tabs構成で』みたいに構造で指示するだけで一瞬でプロっぽくなる。」 核心は**「見た目」ではなく「構造」で指示する**ことです。 なぜ「きれいにして」では良いUIにならないのか バイブコーディングでよくある失敗パターンを見てみます。 ❌ 曖昧な指示: 「もっとおしゃれにして」 「プロっぽいデザインにして」 「モダンな感じで」 → AI は「統計的に平均的な」デザインを返す → 紫グラデーション、Inter フォント、角丸カードの量産（AI スロップ） ✅ 構造で指示: 「App Bar + Drawer + Card Grid + Tabs 構成で」 「Hero + 3カラム Feature Grid + Testimonial Carousel + CTA Footer で」 「Sidebar Navigation + Data Table + Filter Bar + Pagination で」 → AI はコンポーネントの「正しい組み合わせ方」を知っている → 実在のデザインシステムに基づいた構造が生成される この違いが生まれる理由は明確です。LLM の学習データには Material Design、Fluent UI、Ant Design など実在のデザインシステムのコードが大量に含まれています。コンポーネント名で指示すると、AI はそれらのデザインシステムの「正しい実装パターン」を参照して出力します。 ...

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却 「AI にランディングページを作らせると、どれも同じに見える」 Inter フォント、白背景に紫グラデーション、角丸カード、3カラムのアイコン付きグリッド — いわゆる AI スロップ（AI slop） と呼ばれるこの現象には、明確な技術的原因があります。 @awakia さんのポスト では、Anthropic が公式ブログで解説した 分布的収束（Distributional Convergence） という概念と、その解決策としての Skills アプローチを紹介しています。差を生むのはモデルの性能ではなく「方向付け」だという指摘は、AI を使ったフロントエンド開発に携わる全ての人にとって重要な示唆です。 分布的収束（Distributional Convergence）とは LLM はトークンの出現確率に基づいてテキストを生成します。フロントエンドのコード生成においても同じ原理が働きます。 学習データには膨大な数の Web サイトのソースコードが含まれていますが、その中で 最も頻出する「安全な」選択肢 が統計的に支配的です。結果として、指示なしで「ランディングページを作って」と頼むと、学習データの 中央値 に収束した出力が生成されます。 なぜ「紫」なのか この疑問には具体的な答えがあります。約 5 年前、Tailwind CSS のデフォルトボタンカラーが indigo-500 に設定されました。その後、GitHub 上に大量の Tailwind チュートリアルやサンプルコードが蓄積されました。AI に制約なしで「ランディングページを作って」と指示すると、2019 年から 2024 年にかけてスクレイピングされた Tailwind CSS チュートリアルの中央値を得ることになります。そして、その中央値が紫なのです。 AI スロップの典型パターン 要素 AI スロップの典型 フォント Inter, Roboto, Arial, system fonts 配色 白背景 + 紫/インディゴグラデーション レイアウト 3カラムのカード型グリッド 角丸 控えめだが均一な rounded-lg アニメーション なし、または最小限 背景 単色（白 or 薄いグレー） これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。 ...

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い 紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」 はじめに 2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した: 「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」 AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。 プロンプトエンジニアリング vs コンテキストエンジニアリング 観点 プロンプトエンジニアリング コンテキストエンジニアリング スコープ 1つの入力テキストの書き方 モデルが見る情報の全体設計 焦点 指示の言い回し・構造 情報の選択・順序・形式・量 対象 単発の質疑応答 複雑な推論、マルチターン、エージェント 複雑さ 文章レベル システムレベルのパイプライン 例え 「質問の仕方を工夫する」 「解答に必要な教科書・資料・道具を揃える」 プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。 なぜプロンプトだけでは不十分なのか よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。 原因はプロンプトでも検索でもなく、コンテキストの構造にある。 プロンプトの 3 つの限界 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる） 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる コンテキストエンジニアリングは、この 3 つを体系的に解決する。 コンテキストエンジニアリングの 4 つの柱 1. 構成（Composition）— 何を渡すか タスクに必要な「材料」を選択する: ...

AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の衝撃の研究 紹介ポスト: kosuke_agos 論文: LLMs Get Lost In Multi-Turn Conversation Microsoft Research: 公式ページ はじめに 「AI と長く会話するほど、AI の知能が劣化する」— これは体感ではなく、Microsoft Research と Salesforce Research が 20万件以上の AI 会話を分析 して科学的に証明した事実である。 論文タイトルは “LLMs Get Lost In Multi-Turn Conversation”（LLM はマルチターン会話で迷子になる）。GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro を含む 15 モデル全てで、会話が長くなるほど性能が劇的に低下することが明らかになった。 衝撃の数字 指標 数値 平均性能低下 39% 不安定性（unreliability）の増大 +112% 精度の変化 90% → 約 51% テストしたモデル数 15（大小問わず全て劣化） 最も重要な発見: 高性能モデルも小型モデルも、同じように劣化する。 Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1 といったトップモデルでも 30〜40% の性能低下が観測された。モデルの「賢さ」では回避できない、構造的な問題であることが判明した。 研究チームと手法 著者 名前 所属 Philippe Laban Microsoft Research Hiroaki Hayashi Salesforce Research Yingbo Zhou Salesforce Research Jennifer Neville Microsoft Research テスト対象モデル（15種） OpenAI: GPT-4o-mini, GPT-4o, o3, GPT-4.1 Anthropic: Claude 3 Haiku, Claude 3.7 Sonnet Google: Gemini 2.5 Flash, Gemini 2.5 Pro Meta: Llama 3.1-8B, Llama 3.3-70B, Llama 4 Scout その他: Microsoft Phi-4, AI2 OLMo-2-13B, Deepseek-R1, Cohere Command-A Sharding（シャーディング）— 現実の会話を再現する手法 ユーザーは通常、最初から完璧な指示を出さない。 ...

ペルソナ 生成 AI との融合で素早く深くペルソナを理解する！AI インタビューのご紹介

JWT in AWS Lambda API Gateway- https://gist.github.com/bendog/44f21a921f3e4282c631a96051718619 Controlling access to HTTP APIs with JWT authorizers JWT オーソライザーを使用した HTTP API へのアクセスの制御 API Gateway の JWT オーソライザーで Google ID トークンを検証してみた API Gateway JWT Authorizer メモ API Gateway + Lambda で REST API 開発を体験しよう [10 分で完成編] 【生成 AI】AWS Lambda(Python) と LangChain(LCEL) を使ってストリーミング出力したい https://github.com/aws-samples/bedrock-claude-chat slack と AWS で LLM Chatbot を Serverless で運用する Lambda コンテナ Lambda のコンテナイメージを使用する Lambda コンテナイメージをローカルでテストする コンテナイメージで Python Lambda 関数をデプロイする コンテナイメージを使用して AWS Lambda 関数を作成する

Snowflake Cortex [新機能]Snowflake で Mistral AI・LLaMA 2・Gemma を用いた LLM が関数一つで簡単に使用可能に！Snowflake Cortex LLM Functions を試してみた 2024 年 3 月にリリースされた Snowflake の新機能・変更点のまとめ #SnowflakeDB [COF-C02]Snowpark ML の理解を深めるのに Snowpro Core を受験してみた Snowpark ML で作成した XGBoost モデルの特徴量重要度をテーブルとして保存する パブリックプレビュー版の Snowpark ML Model Registry で、Snowflake での MLOps のポイントを確認してみた