AI/LLM

QwenVoice — Mac でボイスクローニング・感情表現・音声デザインを完全オフラインで実現する Qwen3-TTS アプリ @ai_hakase_ 氏が X で紹介した、Mac 向け音声生成アプリ「QwenVoice」が注目を集めています。 【Mac で革命】Qwen3-TTS 搭載の最強音声生成アプリ「QwenVoice」。ボイスクローニングや感情表現が Mac で爆速！Apple Silicon 最適化でオフライン動作も完璧です。面倒な設定なしでプロ級のナレーションを生成可能。 QwenVoice は、Alibaba Cloud の Qwen チームが開発したオープンソース TTS モデル「Qwen3-TTS」を Apple Silicon Mac でネイティブに動かす GUI アプリです。Python のインストールもターミナル操作も不要で、ドラッグ & ドロップだけで使い始められます。本記事では、QwenVoice の機能と Qwen3-TTS の技術的な仕組みを解説します。 QwenVoice の概要 何ができるのか QwenVoice は 3 つの音声生成モードを提供します。 モード 機能 使い方 Custom Voice プリセット音声で読み上げ 4 種類の英語話者（Ryan, Aiden, Serena, Vivian）から選択 Voice Design 自然言語で新しい声を作る 「落ち着いた男性の低い声」のようにテキストで指示 Voice Cloning 既存の声を複製 5〜10 秒の音声サンプルから声を再現 3 つのモードすべてが 100% オフラインで動作します。音声データがクラウドに送信されることはありません。 システム要件 要件 スペック OS macOS 14.0（Sonoma）以上 プロセッサ Apple Silicon（M1 / M2 / M3 / M4） メモリ 8 GB 以上推奨 インストール手順 1 2 3 4 5 # 1. GitHub Releases から QwenVoice.dmg をダウンロード # 2. /Applications にドラッグ # 3. 検疫属性を解除（署名なしのため） xattr -cr "/Applications/QwenVoice.app" # 4. アプリを起動 → Models タブ → モデルをダウンロード → 生成開始 Python 環境の構築やライブラリのインストールはアプリが自動で行います。ユーザーが触るのは GUI だけです。 ...

Rust の仕事が増えていく理由 — インフラコスト削減の圧力と LLM が学習コストを消し去る構造変化 @helloyuki_ 氏のポストが、Zenn の記事を紹介し反響を呼んでいます（いいね 177、ブックマーク 124）。 前職の同僚がなんか書いてた。広告配信でRustを採用した際のインフラ費の話を聞いた気がするんだけど、たしかにRustにするとこんなに削減できるのかと思った記憶がある🤔 引用元は yukinarit 氏による Zenn 記事「Rustの仕事が増えていく理由」。地図・ゲーム・証券・広告・メッセージングと多様な業界で Rust を使ってきたエンジニアが、なぜ Rust の仕事が増えていくのかを構造的に分析した記事です。 本記事では、元記事の論点を整理し、企業の実績データとLLM時代の変化を加えて解説します。 Rust 採用の構造的理由 — 2軸モデル 性能要求 × 開発コストの2軸 元記事が提示するフレームワークは、言語選定を性能要求と開発コスト許容度の2軸で整理するものです。 高性能要求 ↑ 領域D | 領域C Rust / C++ | ML研究等 | ───────────────┼───────────────→ 高コスト許容 | 領域B | 領域A Go / Java | Ruby / Python | TypeScript 低性能要求 領域 言語 典型的なプロダクト A（低性能・低コスト） Ruby, Python, TypeScript Web アプリ、管理画面、MVP B（中性能・中コスト） Go, Java, C# マイクロサービス、API サーバー C（低性能・高コスト） Python + CUDA 機械学習研究 D（高性能・高コスト） Rust, C++ HFT、ゲームエンジン、広告配信 領域 B → D への圧力 重要なのは、クラウドの普及が領域 B のプロダクトを領域 D に押し上げていることです。オンプレミス時代はサーバーを買い切りだったため、CPU やメモリの使用効率が直接コストに響きにくかった。しかしクラウドでは CPU 時間・メモリ量が従量課金されるため、「Go/Java で十分」だったサービスがコスト削減のために Rust を検討するフェーズに入っています。 ...

Skills の自動最適化 — TextGrad を応用して提案書生成スキルを「学習」させる実験と過学習の発見 @yusuke_post 氏が、Claude Code の Skills を深層学習の手法で自動最適化する実験を公開し、大きな反響を呼んでいます。 最初のポスト（いいね 1,226、ブックマーク 2,265）では TextGrad を応用した Skills 最適化の概念を紹介し、続報のポスト（いいね 126、ブックマーク 132）では追加実験の結果として以下の知見を報告しています。 わかったのは、 ・３イテレーションくらいで過学習する。 ・１回だけでなく、3回くらいイテレーションを回すことで徐々にスコアが改善する。 ・学習を始めて最初の方は、「提案書に何を書くか」を学び出して、最後の方では「提案書のそれぞれの項目をどう書くか」を自動で学習する。 特に「全体最適→局所最適の順番で AI が自動で学んだ」という発見は、深層学習の訓練過程と同様の振る舞いが Markdown のプロンプトでも起きることを示唆しています。本記事では、この実験の背景・手法・発見を解説します。 TextGrad とは何か 「テキスト版の誤差逆伝播」 TextGrad（論文: arXiv 2406.07496）は、Stanford 大学の Zou グループが開発し、Nature に掲載されたフレームワークです。深層学習における誤差逆伝播（backpropagation）の概念を、テキストに適用します。 [深層学習の最適化] 入力 → ニューラルネット → 出力 → 損失関数 → 勾配計算 → パラメータ更新 ↑ 数値の勾配 [TextGrad の最適化] 入力 → LLM → 出力 → 評価（LLM） → テキスト勾配 → プロンプト更新 ↑ 自然言語のフィードバック 従来の深層学習では数値的な勾配を計算してパラメータを更新しますが、TextGrad では LLM が自然言語で「どう改善すべきか」をフィードバックし、それを「テキスト勾配」としてプロンプトを更新します。 ...

SoR から SoA へ — エージェント時代に業務ソフトウェアの「どの層」が死ぬのか Yuichiro Ito(@110110110110) 氏（Finatext CFO）が、AIエージェント時代における業務ソフトウェアの構造変化を分析した note 記事を公開しました。 「SaaS is Dead」の議論が盛り上がっていますが、「死ぬか死なないか」の二者択一ではなく、もっと本質的な構造変化が起きていると思っています。UIレイヤーの価値は消滅し、SoRが長年築いてきた Moat も弱体化し、独占寡占が当たり前だった SoR 市場に、千載一遇のチャンスが生まれています。 — @110110110110 元記事: 【SoR→SoA】エージェント時代に訪れる千載一遇のチャンス 「SaaS は死ぬのか？」という問いは不毛です。正しい問いは「業務ソフトウェアのどの層の価値が、どう変わるのか？」です。本記事では、伊藤氏の論考を軸に、SoR（System of Record）から SoA（System of Action）への構造変化を解説します。 「SaaS is Dead」論争の経緯 2026 年に入り、「SaaS の終焉」を巡る議論が急速に加熱しています。 時期 出来事 2024 年末 Microsoft CEO ナデラ氏が「AIエージェントが主流になれば従来型 SaaS が崩壊する可能性」に言及 2025 年 YC パートナー Jared Friedman 氏が「Vertical AI Agents は SaaS の 10 倍の市場規模になる」と予測 2026 年 1 月 Anthropic が Claude Opus 4.6 と Cowork を発表。SaaS 銘柄が急落し、約 43 兆円の時価総額が消失 2026 年 2 月 OpenAI CEO Sam Altman がシスコ AI サミットで「SaaS is Dead」を宣言 2026 年 3 月 英語圏で「SaaSocalypse（SaaS の黙示録）」という新語が登場 Sam Altman が提示したのは「Software as a Service」から「Service as Software」への反転です。人間がソフトウェアを操作するのではなく、AI が主体的にサービスを提供する世界への転換を意味しています。 ...

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する @dify_base 氏のポストが、Claude Code の Subagent と Agent Teams の違いを図解で整理しています。 Claude Code の「Subagent」と「Agent Teams」の違い、意外と知らない人が多いので、図解で整理しました👇 ✅Subagent → 調査して結果を返すだけの部下 ✅Agent Teams → 複数AIが議論・協力する自律チーム この2つの機能は名前が似ていて混同しやすいですが、設計思想が根本的に異なります。本記事では、公式ドキュメントと Qiita の設計レイヤ分析記事を基に、両者の違いを構造的に解説します。 一言で言う違い Qiita の記事が最も端的に表現しています。 Subagent は「働くエージェント」、Agent Teams は「議論するエージェント」 Subagent Agent Teams 一言で 調査して結果を返す部下 議論・協力する自律チーム 比喩 上司に報告するだけの社員 横で相談し合うプロジェクトチーム 構造的な違い — 通信モデルが本質 Subagent: スター型（親子通信のみ） メインエージェント ／ ｜ ＼ Subagent Subagent Subagent (Explore) (Plan) (general) Subagent はメインエージェントの単一セッション内で動作します。結果をメインエージェントに返すことしかできず、Subagent 同士は直接通信できません。 Agent Teams: メッシュ型（全方向通信） リード（チームリーダー） ／ ｜ ＼ Teammate Teammate Teammate (API) (UI) (Test) ＼ ｜ ／ 共有タスクリスト Agent Teams のメンバーは完全に独立したセッションとして動作し、互いに直接メッセージを送受信できます。リードを介さずに横の連携が可能です。 ...

Trivy VS Code 拡張が改ざんされ、ローカル AI エージェントが認証情報を窃取 — hackerbot-claw の全貌 セキュリティ研究者のyousukezan氏が、Aqua Security の脆弱性スキャナー「Trivy」の VS Code 拡張が改ざんされ、開発者のローカル AI コーディングツールを悪用して認証情報を窃取するサプライチェーン攻撃を紹介しています。 Aqua Trivy VS Code拡張が改ざんされ、AIコーディング支援ツールを悪用する異例のサプライチェーン攻撃が発覚した。正規機能を装いながら裏で認証情報を収集する手口で、被害はGitHubリポジトリの乗っ取りにも及んだ。 — yousukezan この事件の異例な点は、従来のマルウェアやバックドアではなく、開発者のマシンに既にインストールされている AI コーディングツールを武器として利用したことです。Claude、Codex、Gemini、GitHub Copilot CLI、Kiro CLI を最大権限で呼び出し、自然言語プロンプトで機密情報を探索させるという、AI 時代に固有の新しい攻撃ベクターです。 事件の全体像 この攻撃は、hackerbot-claw と名乗る自律型 AI ボットによる大規模キャンペーンの一部です。2026年2月21日〜28日の間に、Microsoft、DataDog、CNCF プロジェクトなど少なくとも7つの主要リポジトリが標的となりました。 影響を受けたリポジトリ リポジトリ Stars 攻撃手法 結果 aquasecurity/trivy 25k+ pull_request_target 悪用 PAT 窃取、リポジトリ乗っ取り avelino/awesome-go 140k+ Go init() 関数にペイロード注入 GITHUB_TOKEN 窃取 microsoft/ai-discovery-agent - ブランチ名コマンドインジェクション RCE 達成 DataDog/datadog-iac-scanner - ファイル名ベースのインジェクション RCE 達成（9時間で修正） ambient-code/platform - CLAUDE.md プロンプトインジェクション Claude が検出・拒否 project-akri/akri (CNCF) - curl | bash 直接インジェクション RCE 達成 RustPython/RustPython 20k+ Base64 ブランチインジェクション 攻撃試行 hackerbot-claw の正体 hackerbot-claw は GitHub 上で自らを「autonomous security research agent powered by claude-opus-4-5」と名乗り、暗号通貨の寄付を募っています。README には9クラス・47サブパターンの「脆弱性パターンインデックス」を持ち、47,391リポジトリをスキャン済みと記載されています。 ...

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差 まさお(@AI_masaou) 氏が、Claude Code のハーネス（開発基盤）をテーマにした約 80 分の対談形式勉強会のまとめ記事を公開しました。 新しい note を公開しました！ハーネスエンジニアリングに向き合う上で、実践的にはどうしているのか？の勉強会を行いましたのでそのまとめを記事にしました — @AI_masaou 元記事（ハーネスエンジニアリングの実践知を共有！【質問/勉強会のまとめ】）は有料コンテンツのため、本記事ではテーマであるハーネスエンジニアリングの実践知について、公開情報をもとに技術的な背景と具体的な手法を解説します。 ハーネスエンジニアリングとは 「ハーネス」とは馬具のことです。馬の力をそのまま放置すれば暴走しますが、ハーネスで制御すれば有用な仕事に変わります。AI エージェントも同じです。LLM の推論能力をそのまま使うのではなく、適切な制御基盤（ハーネス）で囲むことで信頼性の高い成果に変換するのがハーネスエンジニアリングです。 コンピュータの構成に対応させると、位置づけがわかりやすくなります。 コンピュータ AI エージェント CPU LLM（推論エンジン） OS エージェントハーネス（制御・管理基盤） アプリケーション AI エージェント（実行層） CPU がどれだけ高速でも、OS が適切に管理しなければアプリケーションは動きません。同様に、LLM がどれだけ賢くても、ハーネスの設計が悪ければエージェントの出力品質は上がりません。 コンテキストエンジニアリングとの関係 Andrej Karpathy が X で提唱した「コンテキストエンジニアリング」 は、ハーネスエンジニアリングの中核概念です。 Context engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy LLM のコンテキストウィンドウを「RAM」と捉え、次のステップに必要な最適な情報だけを入れる技術です。ハーネスエンジニアリングはこのコンテキスト管理の仕組み全体を包む上位概念にあたります。 ハーネスエンジニアリング（全体設計） ├── コンテキストエンジニアリング（何を LLM に渡すか） ├── 権限制御（何を許可・禁止するか） ├── ライフサイクル自動化（いつ何を実行するか） └── 並列実行・隔離（どう安全に並列化するか） 「環境設計 > モデル能力」— OpenAI Codex チームの実証 ハーネスエンジニアリングの重要性を最も説得力をもって示したのが、OpenAI のエンジニアリングチームによる 5 ヶ月間の実験です。 ...

ローカル LLM を金融取引の意思決定サポートに応用する — コードレビュー 4 段階カスタマイズの転用 前回の記事では、ローカル LLM（Ollama + Qwen3）を社内コードレビューに特化させる 4 段階のカスタマイズ手法を紹介しました。この仕組みは金融取引の意思決定サポートにもそのまま応用できます。 個人投資家が株式や BTC などの売買判断を行う際に、ニュース分析・テクニカル指標の解釈・リスク評価を自分の PC 上で、自分の投資ルールに基づいてAI に補助させる構成です。 なぜローカル LLM が金融取引に向いているのか 金融取引は、AI の活用にローカル環境が特に適している分野です。 利点 説明 プライバシー ポートフォリオ・売買履歴・資産額をクラウドに送信しない コスト 毎日の市場分析やニュース要約を API 課金なしで実行可能 カスタマイズ 自分の投資スタイル・リスク許容度に完全に特化できる 速度 ネットワーク遅延がなく、市場の急変時にも即座に分析可能 独立性 API 障害やサービス停止の影響を受けない 2024 年末時点で個人がビットコインの発行上限の約 69% を保有しており、個人投資家にとって自分だけの分析ツールを持つ意義はますます大きくなっています。 コードレビューから金融取引への対応表 前回の記事の 4 段階がどのように転用できるかを整理します。 レベル コードレビュー 金融取引サポート 1. Modelfile コーディング規約を教える 売買ルール・リスク管理ルールを教える 2. RAG 障害報告・設計書を検索 決算短信・ニュース・四季報を検索 3. Few-shot 過去のレビュー事例を見せる 過去の売買判断の成功/失敗事例を見せる 4. LoRA PR レビュー履歴で再訓練 金融センチメント分析データで再訓練 レベル 1：投資ルールを「教える」 ← すぐできる レベル 2：市場情報を「渡す」 ← 1〜2日 レベル 3：売買パターンを「見せる」 ← 数日 レベル 4：金融の頭脳を「鍛える」 ← 1〜2週間 レベル 1：Modelfile に投資ルールを埋め込む（即日導入） 自分の投資ルール・リスク管理基準をシステムプロンプトとして設定します。 ...

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み Claude Code で生成したコードをローカル LLM（Ollama + Qwen3）でレビューする構成を前回の記事で紹介しました。しかし、汎用モデルのままでは「受注ステータスの遷移ルール」や「金額計算に float を使ってはならない」といった社内固有のルールを知りません。 この記事では、Qwen3 を社内業務に特化させ、特定のコーディング規約・業務ルール・過去の障害パターンを踏まえたレビューができるようにする 4 段階のカスタマイズ手法を紹介します。 全体像：4 段階のカスタマイズ レベル 手法 導入期間 効果 専門知識 1 Modelfile（システムプロンプト） 即日 ルールベースの指摘 不要 2 RAG（社内ドキュメント検索） 1〜2 日 文脈を踏まえた指摘 Docker の基本 3 Few-shot（レビュー事例の学習） 数日 パターン認識の向上 不要 4 LoRA ファインチューニング 1〜2 週間 モデル自体の精度向上 Python・ML の基本 レベル 1：ルールを「教える」 ← すぐできる レベル 2：資料を「渡す」 ← 1〜2日 レベル 3：お手本を「見せる」 ← 数日 レベル 4：頭脳を「鍛える」 ← 1〜2週間 推奨: レベル 1 から順に導入し、効果を確認しながらステップアップしてください。多くの場合、レベル 1 + 2 で十分な精度が得られます。 ...

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...