AI/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 アクセス時の追加のパスワードプロンプトが少なくなります。 ...

.env の代わりに lkr で LLM API キーを安全に管理する — セットアップから Claude Code 連携まで AI エージェントがローカルファイルを読み書きする時代、.env に平文で置いた API キーが LLM のコンテキストに載るリスクが現実のものになっています。前回の記事ではこの問題の全体像を、aws-vault の記事では AWS 認証情報の保護を解説しました。 本記事では、LLM Key Ring（lkr）を使って LLM API キーを安全に管理する具体的な手順を解説します。aws-vault が AWS 認証情報に特化しているのに対し、lkr は OpenAI・Anthropic・Google など LLM API キーの管理に特化したツールです。 lkr が解決する問題 .env に LLM API キーを置くリスク 多くの開発者は .env ファイルに API キーを平文で保存しています。 1 2 3 # .env（平文で保存されている） OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx このファイルには4つの攻撃ベクトルがあります。 攻撃ベクトル 説明 Git への混入 .gitignore に頼るヒューマンエラー。うっかりコミットは後を絶たない シェル履歴への漏洩 export OPENAI_API_KEY=sk-... が ~/.bash_history に残る プロセス情報への露出 ps コマンドで環境変数が見える AI エージェントによる抽出 Claude Code がファイルを読み取り、LLM の API リクエストに含まれる 4番目が AI 時代に特有の脅威です。Claude Code は.env ファイルを自動的に読み込むことが確認されており、API キーが意図せず Anthropic のサーバーに送信されるリスクがあります。 ...

「AIが覚醒する魔法の言葉」は本当に効くのか — プロンプトエンジニアリングの実態と公式ガイドの教え @fit_youtubead 氏のポストが、Claude と ChatGPT で使える「魔法のプロンプト」を紹介し、大きな反響を呼んでいます。 「最高の専門家として、思考プロセスを分解し、初心者にも再現できる形で5ステップで出力してください」 これだけ。なぜ強いのか？理由は3つ。 役割を与える → AIの精度が跳ね上がる 思考を分解させる → 中身が薄くならない 再現性を指定する → 実用的で使えるアウトプットになる 確かに、雑な指示よりも構造化された指示の方が良い結果を得られるのは事実です。しかし「魔法の言葉」と呼ぶには、いくつか知っておくべきことがあります。本記事では、ツイートで紹介された3つのテクニックを、Anthropic と OpenAI の公式ガイドおよび研究論文に照らし合わせて検証します。 テクニック1: 役割を与える（ロールプロンプティング） 「最高の専門家として」のように、AI に特定の役割やペルソナを与えるテクニックです。 公式ガイドの見解 Anthropic はプロンプトエンジニアリングのベストプラクティスで、ロールプロンプティングを推奨テクニックの1つとして挙げています。「法律アドバイザー」「データアナリスト」「カスタマーサポート担当」のように、具体的な文脈に合わせてモデルの声とふるまいを調整する手法です。 OpenAI も公式ガイドでシステムプロンプトによる役割設定を推奨しています。 研究が示す実態 ところが、学術的な研究を見ると、ロールプロンプティングの効果は「場合による」というのが正確な答えです。 研究 結果 対象モデル Better Zero-Shot Reasoning with Role-Play Prompting AQuA データセットで精度が53.5%→63.8%に向上（+10.3pt） GPT-3.5 ExpertPrompting 詳細な専門家ペルソナが単純なペルソナを大幅に上回る 複数モデル When “A Helpful Assistant” Is Not Really Helpful 追加のペルソナは性能を向上させない 4モデルファミリー Persona is a Double-edged Sword GPT-4ではペルソナの有無で差は最小限 GPT-4 PromptHub の検証記事は、これらの研究を総合して以下のように結論づけています。 創作的なタスク（文体の調整、トーンの統一）では効果がある 精度ベースのタスク（分類、計算、ファクトチェック）では、新しいモデルほど効果が薄い 「天才ペルソナが愚か者ペルソナより劣る」という矛盾した結果も報告されている つまり、「専門家として」と付けるだけで「精度が跳ね上がる」わけではありません。効果があるのは、役割指定によってモデルの出力スタイルや視点が適切に制約されるケースです。 ...

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック ガガロットAI(@gagarotai200)氏のポストが拡散されています。 「Open Claw」を使い始めた企業では既に5人以上の人間が解雇になっている。仮想オフィスでAIエージェントを擬似的に社員の様に働かせて進捗を確認できる様になったことで人間がタスクをこなす必要性がなくなっている — ガガロットAI(@gagarotai200) さらに「今後5年で中小企業の30%はAI社員に置き換わる」「GPTやGeminiしか触ってない人は残り3ヶ月程度で不要になる」と煽っています。この主張はどこまで事実に基づいているのでしょうか。国際機関の統計とセキュリティ研究者の報告をもとにファクトチェックします。 主張を検証する 主張1: 「OpenClaw導入企業で5人以上が解雇」 検証結果: 根拠不明 この「5人以上の解雇」について、具体的な企業名、業種、時期、情報源は示されていません。投稿者のプロフィールを確認すると、ガガロットAI氏は「スキルエンジン」というAIスクールを運営し、SNS運用代行を50社に提供しているとのことです。つまり、OpenClawの普及が自身のビジネスに直接利益をもたらす立場にあります。 TechCrunch の報道では、AI専門家が「AIリサーチの観点から見て、これは何も新しいものではない」と指摘しています。 主張2: 「集客・提案書作成・顧客対応は完全AI化」 検証結果: 大幅に誇張 Cobus Greyling氏のMedium記事は、OpenClawが実際に失敗するケースを分析しています。「高い能力を持つという評判」と「messy, unpredictable reality（混沌とした予測不能な現実）」の間にはギャップがあり、実用には人間の監視が不可欠です。 具体的な暴走事例も報告されています。 事例 内容 iMessageループ エンジニアChris Boyd氏の環境で確認メッセージを繰り返し送信。再試行ロジックに停止条件がなかった 批判ブログ自動公開 matplotlibメンテナーがコード提案を却下後、自身を批判するブログ記事が自動公開された デーティングサイト暴走 想定以上に広範な自動行動が発生し、制御不能に 「完全AI化」どころか、監視なしでは予期せぬ行動を起こすリスクが確認されています。 主張3: 「今後5年で中小企業の30%はAI社員に置き換わる」 検証結果: 出典なし。国際機関の予測と乖離 この「30%」という数字の出典は示されていません。実際の国際機関の予測と比較してみましょう。 機関 予測内容 OECD (2023) 27%の職業が自動化のリスクが高い（「置き換え」ではなく「リスクがある」） ILO (2023) 事務業務の24%が高度に曝露、58%が中程度に曝露（「解雇」ではなく「影響を受ける」） Gartner 2027年までにエージェント型AIプロジェクトの40%以上が失敗する JILPT (2024) 日本の雇用者のうちAIが使用されている者は12.9%、生成AIを自ら利用している者は6.4% 注意すべきは、OECD や ILO の予測は「影響を受ける」「曝露される」であり、「置き換わる」「解雇される」ではないことです。さらに、日本の中小企業（10人未満）のAIエージェント導入率は10%以下という現状を考えると、「5年で30%置き換え」は根拠のない数字と言えます。 主張4: 「GPTやGeminiしか触ってない人は残り3ヶ月で不要」 検証結果: 煽り文句 具体的な根拠はなく、不安を煽ってAIスクールへの誘導を意図した表現と見られます。 OpenClawの実態 — セキュリティリスクの深刻さ 「AIが人間を置き換える」と煽る前に、OpenClaw自体が抱えるセキュリティリスクを確認すべきです。 悪意あるスキルの蔓延 セキュリティ企業Koi Securityの監査によると、ClawHub（OpenClawの公式スキルストア）に登録された2,857スキルのうち341件（約12%）が悪意あるコードを含んでいたことが判明しています。 ...