東京大学が無料公開した「思考の解像度を上げる」全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 エージェント 一言で言えば： ...

AIチャットボットにあなたのプライバシーは存在しない — スタンフォード大学が暴いた構造的欠陥 スタンフォード大学の研究チームが、米国の主要AIチャットボット6社のプライバシーポリシーを体系的に分析した論文 “User Privacy and Large Language Models” を発表しました。その結論は明確です——全6社がユーザーの会話データをデフォルトでモデル学習に利用しており、実効的な保護は極めて限定的です。 論文概要 項目 内容 タイトル User Privacy and Large Language Models: An Analysis of Frontier Developers’ Privacy Policies 著者 Jennifer King, Kevin Klyman, Fotis Gaspelos, Tiffany Saade, Victoria Bhatt 所属 Stanford University 発表 2025年10月（AAAI AIES 掲載） 論文 arXiv:2509.05382 対象6社 企業 チャットボット Amazon Nova Anthropic Claude Google Gemini Meta Meta AI Microsoft Copilot OpenAI ChatGPT 1. データの「統合」—— 会話が資産として再利用される構造 全6社がデフォルトでモデル学習に利用 Anthropic は長らく「消費者の会話データを学習に使わない」と差別化していましたが、2025年9月にオプトイン → オプトアウトへ転換。これにより全6社がデフォルト学習利用に揃いました。 ...

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の学習知見を蓄積します。 ...

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的 Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。 @SuguruKun_ai さんのポスト と @shinzizm2 さんのポスト でこの問題が指摘され、大きな反響を呼びました。 MCP のトークン消費問題とは スキーマ注入の仕組み MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。 MCP サーバー接続時の処理: 1. tools/list でツール一覧を取得 2. 各ツールの名前、説明、パラメータ定義を取得 3. 全てのスキーマをプロンプトに注入 ← ここで大量消費 4. ユーザーの質問に回答 あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。 具体的な数値 MCP サーバー ツール数 トークン消費量 GitHub MCP サーバー 93 ツール 約 55,000 トークン Notion サーバー 15+ ツール 約 8,000 トークン ファイルシステム 10 ツール 約 4,000 トークン 平均的なツール定義 1 ツール 300〜600 トークン GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。 ...

Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで 「バグが起きたら Sentry が検知し、AI が分析して修正案を出す」— そんなワークフローが現実になっています。 @riku720720（Rikuo）さんのポストは、この流れを端的にまとめています。 「アプリ開発する上でsentryは必須。sentry APIをskillsにすればユーザーのバグとか不具合とか全部分析できる。claudecodeの新機能/batchで一気に改善してもらう」 この記事では、Sentry の全体像から Claude Code との連携、そして実践的なワークフローまでを解説します。 Sentry とは Sentry は、開発者ファーストのエラートラッキング＆パフォーマンス監視プラットフォームです。100以上のプラットフォーム・フレームワーク、30以上のプログラミング言語に対応しています。 単なるエラーログではない Sentry が他のログ監視ツールと異なるのは、エラーの文脈（コンテキスト）を自動収集する点です。スタックトレースだけでなく、ユーザーのセッション情報、パフォーマンスデータ、リリースバージョンなど、デバッグに必要な情報を一元化します。 Sentry の主要機能 1. Error Monitoring（エラー監視） Sentry の中核機能です。 リアルタイム検知：エラー発生を即座にキャッチ インテリジェントグルーピング：同じ原因のエラーを自動的に1つの Issue にまとめる アラート通知：Slack、メール、PagerDuty 等と連携 1 2 3 4 5 6 7 8 # Django での導入例 import sentry_sdk sentry_sdk.init( dsn="https://xxx@xxx.ingest.sentry.io/xxx", traces_sample_rate=1.0, profiles_sample_rate=1.0, ) 2. Performance Monitoring（パフォーマンス監視） 分散トレーシング：リクエストの流れをフロントエンドからバックエンドまで追跡 トランザクション分析：遅いエンドポイントやクエリを特定 Web Vitals：LCP、FID、CLS などフロントエンドのパフォーマンス指標 3. Session Replay（セッションリプレイ） ユーザーのセッションをビデオのように再生できる機能です。 ...

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.” （彼らの要求に良心に従って応じることはできない） ...