AI/LLM

SaaS の終焉（SaaSpocalypse）— 自律エージェントが Seat 課金を破壊し、ソフトウェア業界を再編する @shoji_hq 氏が X で共有した、Insight Partners 共同創業者による「SaaS の終焉（Apocalypse）」Podcast の備忘メモが注目を集めています。 AIの津波はまだこれから。本丸は「Autonomous Agents（自律エージェント）」であり、これが今からやってくる。これが浜にぶつかった瞬間、大きな津波になる。 この警告は予言ではなく、すでに現実になりつつあります。2026 年 2 月、ソフトウェアセクターは「SaaSpocalypse」と呼ばれる大暴落を経験し、1 兆ドル超の時価総額が消失しました。本記事では、何が起きているのかを構造的に整理します。 Insight Partners が語った 5 つの構造変化 @shoji_hq 氏のメモは、Podcast の要点を 5 つに整理しています。それぞれを掘り下げます。 1. 自律エージェントが本丸 自律的にタスクを分解し、ツールを選び、実行し、報告する存在。これが世の中の構造を変える。 Insight Partners 自身も「million-Agent problems」という表現を使っています。協調する複数のエージェントが、一晩かけて自律的に作業を完了し、翌朝には成果物が揃っている世界です。Deloitte の予測では、自律型 AI エージェント市場は 2026 年に 85 億ドル、2030 年に 350 億ドルに達するとされています。 重要なのは、これが単なるチャットボットの延長ではない点です。CUA（Computer-Using Agent）は複雑なソフトウェアインターフェースを人間より上手に操作できるレベルに達しており、「デジタル従業員」として機能し始めています。 2. API の応答速度が UI より重要になる 人間は400msで遅延を感じる。エージェントは80msを最適化する。美しいUIより、APIの応答速度が大切。 エージェントが主要なユーザーになると、設計のプライオリティが逆転します。 指標 人間向け設計 エージェント向け設計 遅延の閾値 400ms 80ms 重視する点 UI/UX の美しさ API のレスポンス速度 インターフェース グラフィカル プログラマティック 同時接続 数百〜数千 数万〜数百万 稼働時間 営業時間 24 時間 365 日 Insight Partners の Ryan Hinkle 氏は「ナレッジワーカーが仕事に不可欠とするシステムは AI の大きな恩恵を受ける。ただのファイリングキャビネットは脅威にさらされる」と述べています。 ...

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い 前回の記事で OpenClaw による 13 体 AI チーム構築を紹介しました。OpenClaw では SOUL.md というファイルでエージェントの「人格」を定義しますが、これは本当に「自分の分身」と呼べるのでしょうか。Second Me というプロジェクトは、まったく異なるアプローチで「AI による自分の分身」を実現しようとしています。 SOUL.md の限界 — 「指示書」は「分身」ではない OpenClaw の SOUL.md は Markdown で書かれた設定ファイルです。エージェントの名前、性格、役割、制約を自然言語で記述します。 1 2 3 4 5 6 7 8 9 10 --- name: sales-agent model: claude-sonnet-4-6 --- あなたは営業チームの一員です。丁寧に話してください。 ## 役割 - リード情報の整理と優先順位付け - 提案メールの下書き作成 これは強力な仕組みですが、あくまで外から与える指示書です。「営業エージェントをこう振る舞わせたい」という設計者の意図を反映したものであり、「この人ならどう考えるか」を再現するものではありません。 ...

ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく「周辺設計」で決まる 朱雀氏のポストが、Claude Code や Codex の仕組みを理解するうえで「ハーネス」の概念が重要だと紹介しています。2026 年に入り、AI エージェント開発の焦点は「どのモデルを使うか」から「モデルの周囲をどう設計するか」に移りました。この周辺設計を指す言葉がハーネスエンジニアリングです。 Claude CodeやCodexの仕組みを詳しく理解したい人にはこれがおすすめ。「ハーネス」について詳しく解説してくれている。 ハーネスとは何か ハーネスとは、AI モデルを囲む運用インフラのことです。Phil Schmid 氏の解説では、コンピュータに例えて次のように整理しています。 コンピュータ エージェント CPU モデル（推論エンジン） RAM コンテキストウィンドウ（作業メモリ） OS ハーネス（コンテキスト管理、ツール処理、起動シーケンス） アプリケーション エージェント（ユーザー固有のロジック） モデルが CPU なら、ハーネスは OS です。どれだけ高性能な CPU を積んでも、OS が貧弱では実用的なアプリケーションは動きません。 具体的には、ハーネスは以下の要素を管理します。 会話・コンテキスト管理: セッション間の記憶、コンテキストウィンドウの最適化 ツール呼び出し層: MCP/SDK ツールの提供と制御 権限管理: 実行可能な操作の制御 セッション・ファイルシステム状態: 作業ディレクトリ、Git 状態の管理 ループ制御・エラーハンドリング: リトライ、ガードレール、検証 観測性: ログ、メトリクス、テレメトリ モデルではなくハーネスが性能を決める 2026 年に入ってから、ハーネスの重要性を示す数値データが相次いで公開されています。 ハーネス変更だけで性能が 10 倍に ベンチマーク結果によると、ツール形式を変えただけで 15 モデルすべてのスコアが改善しました。最も劇的だったのは Grok Code Fast 1 で、6.7% から 68.3% に跳ね上がり約 10 倍でした。モデルの重みには一切手を加えていません。 同じモデルでもスキャフォールドで倍近い差 Claude Opus 4.5 は、あるスキャフォールドで 42%、別のスキャフォールドで 78% を達成しました。同じモデルでも、ハーネスの設計次第で性能が倍近く変わります。 ...

オープンソース AI は「無料」でも「民主化」でもない — 重みの公開と推論コストの間にある物理法則の壁 @kubotamas 氏が X で共有した、Anthropic CEO Dario Amodei の発言が議論を呼んでいます。 AIのオープンソース化は無料でも民主化でもない。モデルの重みをダウンロードすることは出来ても、実際に推論するのにコストがかかる。AIは従来のオープンソースとは本質的に異なる。重みを手に入れても計算資源がなければ、解釈・改変することはできない。オープン化という約束は物理法則の壁で制限されている この投稿は、@r0ck3t23 氏（Dustin）のツイートを引用しています。Dustin 氏は Amodei の動画インタビューから「オープンソース AI は無料ではなかった。一度もそうだったことはない」とまとめ、1,200 以上のいいねを集めました。 本記事では、この「オープンソース AI の幻想」の構造を掘り下げます。 Amodei の主張 — 「これは Linux ではない」 Dario Amodei はインタビューの中で明確に述べています。 “It’s not free. You have to run it on inference and someone has to make it fast on inference.” （無料ではない。推論を実行する必要があり、誰かがそれを推論で高速にする必要がある） “This is not Linux. You can’t see inside.” （これは Linux ではない。中身は見えない） 従来のオープンソースソフトウェア — Linux、PostgreSQL、React — は、ソースコードを読み、理解し、フォークし、改変できます。ノートパソコン 1 台で動かせます。しかし AI モデルの「重み」は、数百ギガバイトの数値の羅列です。ソースコードのように「読んで理解する」ことはできません。 ...

name: security-check description: Claude Code 利用における情報漏えいリスクをチェックする。 Auto Memory や CLAUDE.md への機密混入、.env の gitignore 漏れ、機密ファイルの存在などを検査する。 Claude Code の利用に関する情報漏えいリスクをチェックしてください。 チェック対象 以下の 4 カテゴリを順番に検査する。 1. Auto Memory の機密スキャン ~/.claude/ 配下の memory ファイルを検査する: 以下のパスを Glob で列挙する: ~/.claude/projects/*/memory/*.md ~/.claude/projects/*/memory/**/*.md 各ファイルを Read で読み込み、以下のパターンを Grep で検出する: API キー・トークン: (?i)(api[_-]?key|secret[_-]?key|access[_-]?token|bearer)\s*[:=]\s*\S+ パスワード: (?i)(password|passwd|pwd)\s*[:=]\s*\S+ AWS 認証情報: (?i)(AKIA[0-9A-Z]{16}|aws[_-]?secret) 接続文字列: (?i)(mysql|postgres|redis|mongodb):\/\/\S+ 個人情報パターン: メールアドレス、電話番号、マイナンバーらしき数字列 金額・契約情報: (?i)(契約金額|単価|請求|売上)\s*[:：]\s*[\d,￥¥$]+ 顧客 ID の具体値: (?i)(顧客id|customer[_-]?id|ユーザーid|user[_-]?id)\s*[:=：]\s*\d+ 検出があれば、ファイルパス・行番号・該当箇所を報告する 2. CLAUDE.md の機密スキャン プロジェクトの CLAUDE.md およびグローバルの ~/.claude/CLAUDE.md を検査する: 両ファイルを Read で読み込む チェック 1 と同じパターンで Grep 検査する 加えて、以下も確認する: URL にトークンやキーが含まれていないか（?token=, ?key=, ?secret=） 内部 IP アドレスやホスト名が含まれていないか CLAUDE.md はリポジトリにコミットされるため、検出時は即時対応を推奨として強調する 3. 機密ファイルの gitignore チェック プロジェクトルートで以下を確認する: ...

東京大学が無料公開した「思考の解像度を上げる」全118スライド – 深さ・広さ・構造・時間の4軸フレームワーク @MacopeninSUTABA（かずなり｜生成AI×ビジネスハック）氏のポストが話題です。 東京大学が無料公開した「思考の解像度を上げる全ノウハウ」が凝縮された資料が有益。「解像度が低い＝深さ・広さ・構造・時間の不足」という定義から、分析を劇的に深めるテクニック、そして「実装可能」なレベルまで鮮明にする方法まで、余すことなく学べる。 東京大学 FoundX ディレクター・馬田隆明氏が SpeakerDeck で公開しているスライド「解像度を上げる」は、累計 570 万回以上閲覧された「神スライド」として知られています。本記事では、このスライドの核心である「4つの視点」と「48の実践パターン」を掘り下げます。 「解像度」とは何か ビジネスの現場で「あの人は解像度が高い」という表現を耳にすることが増えました。馬田氏はこの「解像度」を次のように定義しています。 顧客の状況や課題、次に取るべきアクションが鮮明に見えている状態 逆に、解像度が低いとは「思考や事実認識が粗い」状態です。つまり、課題を構成要素に分解できておらず、各要素の理解が浅い状態を指します。 重要なのは、解像度は単に「知識量が多い」ことではないという点です。情報を持っていても、それを構造化し、深く掘り下げ、時間軸で捉えられなければ、解像度は低いままです。 4つの視点 スライドの中核をなすのが、解像度を構成する 4 つの視点です。 視点 問い 低い状態 高い状態 深さ なぜそうなるのか？ 表面的な症状だけを見ている 根本原因まで掘り下げている 広さ 他にどんな可能性があるか？ 1つのアプローチしか検討していない 複数の視点・手法を比較している 構造 要素間の関係はどうか？ 情報がバラバラで整理されていない 因果関係と優先順位が明確 時間 過去から未来へどう変化するか？ 現在のスナップショットだけ 経時変化とプロセスを捉えている 馬田氏が繰り返し強調するのは、4 つの視点のうち最も不足しがちなのは「深さ」であるという点です。多くの人は課題を広く浅く捉えることはできても、1 つの課題を徹底的に掘り下げることが不十分だと指摘しています。 問題と解決策の両面で解像度を上げる このフレームワークのもう一つの特徴は、解像度を問題側と解決策側の 2 軸で捉える点です。 問題の解像度 解決策の解像度 深さ 根本原因の特定 実装の具体性 広さ 顧客セグメントの網羅 代替手段の検討 構造 課題間の因果関係 アーキテクチャ設計 時間 課題の変遷 ロードマップ ビジネスで価値を生むには、「顧客の課題」と「それに対応する解決策」の両方の解像度を上げる必要があります。どちらか一方だけでは不十分です。 48 の実践パターン 書籍版では、4 つの視点ごとに具体的なアクションが「型」として整理されています。「情報 × 思考 × 行動」を組み合わせた 48 のパターンです。代表的なものを紹介します。 ...

組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ 各システムの役割と利用者 システム 主な利用者 目的 Backlog 利用者側の責任者・管理部門 利用者が課題を把握・確認するため Asana 開発会社の PM・経営者 開発会社の責任者が状況を把握するため GitHub 開発担当者 作業担当者が実装・コード変更を管理するため 3層の責任構造 利用者（顧客） 開発会社（経営・PM） 開発会社（作業担当） │ │ │ Backlog Asana GitHub 課題確認会で 経営判断・ Issue/PR で 進捗レビュー リソース配分 実装を管理 各システムは異なるステークホルダーが、それぞれの責任範囲で状況を把握するために存在する。 これは冗長ではなく、報告先ごとに適切な粒度・視点で情報を提供するための構造。 担当者の課題: 「今何をすべきか」の判断 3システムはどれも他者への報告用であって、担当者が「自分が次に何をやるか」を整理する場所ではない。 システム 読者 自分の優先度確認に使えるか Backlog 利用者の責任者 △ 顧客視点の優先度であって自分の作業順ではない Asana 開発会社の経営・PM △ 経営視点のフィルタがかかっている GitHub (epm-server) 作業担当者 △ Issue は技術タスク単位で、全体俯瞰しにくい 解決策: Claude Code でタスクトリアージ → プライベートリポジトリの Issue に記録 タスクトリアージ（状況分析と優先度づけ）は Claude Code セッションで行い、結論の記録先は社内プライベートリポジトリの GitHub Issue に置く。 ...

AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」 AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」 「AI エージェント」という言葉が溢れる2026年。しかし、本当に「エージェント」と呼べるものはどれだけあるのでしょうか。 @kgsi（こぎそ）さんのポストで紹介されていた、元 Meta ソフトウェアエンジニア Vasuman Moza 氏の「AI Agents 101」は、コードを書く前に理解すべきエージェントの本質を明快に整理しています。 “If you want to learn how to build AI Agents, read this before you write a single line of code.” （AI エージェントの構築を学びたいなら、コードを1行書く前にこれを読め） この記事では、Vasuman 氏のガイドの要点と、エンジニアが押さえるべきポイントを解説します。 オートメーション vs エージェント — 根本的な違い 最も重要な区別は、指示（instructions） と 目標（goals） の違いです。 オートメーション エージェント 入力 事前に決められた手順（指示） 達成すべきゴール（目標） 動作 ルール通りに実行 状況を観察しながら自律的に判断・行動 例外処理 ルール外は停止 or エラー 文脈を理解して適応 代表例 RPA、cron ジョブ、IFTTT Claude Code、Devin、カスタム AI エージェント 一言で言えば： ...

Anthropic が Wealth Management 向け AI ツール「Claude CoWork」を発表 — Agentic AI 時代の幕開け 元記事: Agentic AI 101 for Advisors as Anthropic Launches Wealth Management Tools 記事概要 Anthropic が、ウェルスマネジメント（資産管理）業界向けの Claude CoWork プラグイン を発表した。これは金融アドバイザー向けに設計された AI ツールで、ポートフォリオ分析や税務分析、リバランス推奨など、従来人手で行っていた業務を自動化する。 Anthropic は設立5年で従業員約3,000名、シリーズGラウンドで300億ドルを調達し、評価額は3,800億ドルに達している。LPL Financial との関係拡大も発表されており、金融業界への本格参入が明確になった。 Agentic AI の定義 — 4つの要素 Vestmark CTO の Freedom Dumlao 氏は、真の「エージェント」を構成する4つの継続的機能を定義している: 要素 説明 認識（Sense） 環境のコンテキストを認識する — 利用可能なツール、現在のシステム状態 思考（Think） 目標と現在の理解に基づいて、次のステップを独立して推論する 行動（Act） ツールの使用、データの変更、ワークフローのトリガーなど、観察可能な効果を実行する 記憶（Remember） インタラクション間で情報を保持し、将来の行動を改善する 「システムが4つ全てを行うなら、それはエージェントです。2つか3つなら、便利なツールかもしれませんが、エージェントと呼ぶのは満たせない期待を設定することになります」 — Freedom Dumlao, Vestmark CTO この定義は、単なるチャットボットや RAG システムと真のエージェントを区別する明確な基準として有用だ。 Claude CoWork の主要機能 ポートフォリオ分析の自動化 顧客のポートフォリオを自動で分析し、リスク配分やパフォーマンスの洞察を提供する。 ...

Claude Code が「汎用AIエージェント基盤」へ進化 — Auto Memory・Remote Control・Scheduled Tasks の全貌 2026年2月、Anthropic は Claude Code に3つの重要なアップデートを投入しました。これらを組み合わせると、オープンソースの自律AIエージェント OpenClaw に近い体験が、公式機能だけで実現できる可能性が見えてきます。 参考ツイート: @Fujin_Metaverse 3つのアップデート概要 機能 概要 リリース Auto Memory AIが自分で学習内容を記憶・蓄積する 2026年2月 Remote Control スマホからPCのClaude Codeを操作 2026年2月25日 Cowork Scheduled Tasks 指定時間に自動でタスクを実行 2026年2月24日 1. Auto Memory — AIが自分でメモを取り、セッションを超えて記憶する 仕組み Claude Code がプロジェクトごとに MEMORY.md ファイルを自動作成し、以下のような情報を蓄積していきます。 プロジェクトのビルドコマンド、コードスタイル アーキテクチャの決定事項 デバッグで解決したトリッキーなバグ ユーザーのワークフローやコミュニケーションスタイル 技術的な詳細 項目 内容 保存場所 ~/.claude/projects/<encoded-path>/memory/MEMORY.md 読み込み セッション開始時に最初の200行をシステムプロンプトに自動注入 Git ローカル保存のみ。Git にはコミットされない 管理 /memory コマンドで確認・編集 無効化 設定ファイルまたは環境変数でオフ可能 CLAUDE.md との違い CLAUDE.md → ユーザーが手動で書くルール・指示書（チーム共有可能） MEMORY.md → AIが自動で書く学習メモ（ローカル個人用） 両方を併用するのがベスト。CLAUDE.md でプロジェクトのルールを明示し、MEMORY.md でAIの学習知見を蓄積します。 ...