Claude Code

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 エージェント 一言で言えば： ...

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 はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。 ...

非エンジニアでも安心！Claude Code を安全に使うための 2 つの設定ファイル Claude Code は強力なツールですが、ファイルの削除やシステムコマンドの実行など、意図しない操作が起きる可能性もあります。@tetumemo さんのポスト では、非エンジニアが Claude Code を安全に使うために設定すべき 2 つのファイルが紹介されています。 「包丁」に例えると、settings.local.json は安全カバー（物理的に危険な操作を防ぐ）、CLAUDE.md は『危ないから気をつけて』という声かけ（AI に判断基準を与える）。両方揃って初めて安全性が確保されるという、分かりやすい整理です。 1. settings.local.json — 「仕組みとして」操作を制限する settings.local.json とは Claude Code の権限設定ファイルです。AI がどのコマンドを実行でき、どのコマンドを実行できないかを JSON で定義します。 設定ファイルは .claude/settings.local.json に配置します。.local が付くファイルは自動的に .gitignore に追加されるため、個人の設定がチームに影響しません。 基本構造 1 2 3 4 5 6 7 8 9 10 { "permissions": { "allow": [ "許可するコマンドやツール" ], "deny": [ "禁止するコマンドやツール" ] } } 非エンジニア向け推奨設定 @tetumemo さんが紹介しているのは、以下のような設定方針です。 ...

Claude Code の Auto Memory（MEMORY.md）を理解する — CLAUDE.md との使い分け Claude Code には「メモリ」と呼ばれる仕組みがセッション間で情報を引き継ぐために用意されています。最近 SNS でも話題になっている Auto Memory（MEMORY.md） について、CLAUDE.md との違いや実践的な活用法を整理します。 きっかけ：SNS での反応 @L_go_mrk さんのポスト では、Claude Code の Auto Memory 機能について「かなり気が利いている」と評価されていました。ポイントは以下の通りです： 「これ覚えておいて！」と指示するだけで、Claude が自動的に重要情報を記憶してくれる CLAUDE.md（ルール特化）と MEMORY.md（学習・記憶特化）で情報が適切に分離されている プロジェクトごとに独立した記憶で、他プロジェクトに影響しない セッション間で記憶が維持される この指摘はまさにその通りで、CLAUDE.md と MEMORY.md は目的が異なる二つの記憶層として設計されています。 二つの記憶層：CLAUDE.md vs MEMORY.md CLAUDE.md — 「指示書」 CLAUDE.md はあなたが書いて Claude に従わせるルールです。 コーディング規約、ビルドコマンド、テスト手順 プロジェクトのアーキテクチャや設計方針 チーム全体で共有する約束事 # プロジェクトルール - テストは pytest で実行: `pytest -xvs` - コミットメッセージは Conventional Commits に従う - API 変更時は必ず OpenAPI スキーマを更新する CLAUDE.md はリポジトリにコミットしてチームで共有することが想定されています。 MEMORY.md — 「学習ノート」 MEMORY.md はClaude 自身が書く、作業を通じた学習メモです。 ...

【2026年最新】世界一わかりやすい Agent Skills 完全ガイド — まとめ 元記事: 【2026年最新】世界一わかりやすいAgent Skills完全ガイド（株式会社AIworker） 紹介ポスト: Fujin(@fujin_metaverse) Agent Skills とは？ 一言で言うと、「AIエージェントに渡す新人研修マニュアル」。 会社の新入社員にマニュアルを渡すのと同じ要領で、SKILL.md というテキストファイルに「やり方」を書いて所定のフォルダに置くだけ。AIエージェントが自動的にそれを見つけて読み込み、指示通りに仕事をしてくれる。 2025年12月に Anthropic がオープンスタンダードとして公開 Claude, GitHub Copilot, OpenAI Codex, Cursor など主要AIツールが対応 2026年2月時点でマーケットプレイス登録数は20万件超 なぜ Agent Skills が必要か — プロンプトの3つの限界 従来のプロンプト運用には以下の限界があった。Agent Skills はこれらを全て解決する。 限界 問題 Agent Skills での解決 毎回同じ説明が必要 技術スタック、規約、コミットルールを毎回ゼロから伝える 一度書けば繰り返し使える チーム共有できない 優れたプロンプトがチャット履歴に埋もれる Git で管理・共有可能 コンテキスト圧迫 毎回全情報を読み込むと、肝心のタスクの余裕が減る 必要な時に必要な分だけ読み込む「段階的開示」 Claude Code のセットアップ手順 Agent Skills を使う最も一般的な環境は Claude Code（Anthropic 提供のターミナル型AIコーディングツール）。ブラウザ版の Claude.ai と違い、PCのファイルを直接読み書きできるのが特徴。 1 2 3 4 5 6 7 8 9 10 11 12 # 1. Node.js の確認（v18.0.0 以上が必要） node --version # 2. Claude Code のインストール（Mac / Linux） curl -fsSL claude.ai/install.sh | bash # 3. 確認 claude --version # 4. 初回起動（ブラウザでログイン画面が開く） mkdir ~/my-project && cd ~/my-project claude SKILL.md の書き方 SKILL.md は YAMLフロントマター + Markdown 本文 の2部構成。 ...

Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代 Anthropic 公式記事: How Anthropic teams use Claude Code 再現記事: Claude Code で広告バナー200本を15分で作る手順 紹介ポスト: commte はじめに Anthropic が「自社のチームが Claude Code をどう使っているか」を公式ブログで公開した。注目すべきは、エンジニアリングチームだけでなく、マーケティング、法務、データサイエンス、デザインといった非技術部門が、コードを1行も書かずに高度な自動化を実現している点。 特にマーケティングチームの事例は、ツイートでも「えぐい広告手法」として話題になり、実際に再現して15分で広告バナー200本を生成した記事も登場した。 マーケティングチーム — たった1人で10倍の成果 チーム構成 驚くべきことに、Anthropic のグロースマーケティングチームはエンジニアがゼロの1人チーム。担当の Austin Rau 氏は、元々ターミナルの開き方すら知らなかったという。 それが、非技術者向けガイドを見てから1週間で、Figma プラグインと広告コピー生成ワークフローの両方を構築した。 4つの自動化事例 1. Google Ads の広告コピー生成（2時間 → 15分） 数百件の既存広告 CSV を Claude Code に読み込ませ、パフォーマンスの低い広告を自動特定。改善案をサブエージェント方式で生成する。 サブエージェント設計のポイント: エージェント 専門 制約 headline-writer 見出し生成 30文字以内 description-writer 説明文生成 90文字以内 1つのプロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分けることで、文字数制約を守りつつ品質を維持する。 2. Figma プラグインでバナー一括生成（数時間 → 0.5秒） Claude Code で自作した Figma プラグインが、テンプレートのテキストノードを CSV データで自動差し替え。最大100パターンのバナーを一括生成する。 ...

Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用 関連ポスト: hiragram リポジトリ: hiragram/claude-docker はじめに Claude Code を使っていると、ファイル編集やコマンド実行のたびに「これを実行してもいいですか？」と確認を求められる。安全設計として正しいが、反復的な作業では毎回の承認が煩わしくなる。 そこで登場するのが --dangerously-skip-permissions フラグ。通称「YOLO モード」。YOLO とは “You Only Live Once”（人生は一度きり） の略で、「結果を気にせず、とにかくやってしまえ」というネットスラング。安全確認を一切スキップして全操作をぶっ通しで実行させる様子が、まさに「後先考えずに突っ走る」YOLOの精神そのものであることから、コミュニティでこう呼ばれるようになった。 便利だが、名前の通り危険も伴う。このフラグの本質と、安全に使うための Docker 活用について整理する。 --dangerously-skip-permissions とは Claude Code の全てのパーミッションチェック（権限確認プロンプト）をバイパスし、完全に自律動作させるフラグ。 1 claude --dangerously-skip-permissions 3つの動作モードの比較 モード 挙動 ユーザー介入 通常モード ファイル変更・コマンド実行のたびに承認を要求 毎回必要 Auto-Accept (Shift+Tab) UI上で承認を自動化 介入可能 dangerously-skip-permissions 全ての安全ガードレールを除去 一切不要 なぜ「dangerously」と名付けられているのか Anthropic が意図的に「危険」という語を含めている。実際にリスクは深刻で、以下のような報告がある。 Wolak 事件（2025年10月）: Ubuntu/WSL2 上で Claude Code が rm -rf / を実行し、/bin、/boot、/etc などシステムディレクトリを破壊 eesel AI の調査によると、このフラグ使用者の 32% が意図しないファイル変更を経験、9% が実際のデータ損失を報告 主なリスク リスク 具体例 破壊的コマンドの無確認実行 rm -rf、git reset --hard、設定ファイル上書き スコープクリープ 指定範囲外のファイルを「親切心」で変更・削除 資格情報の漏洩 ホストの全資格情報にアクセス可能な状態 連鎖的被害 1つの誤った解釈が次々と問題を引き起こす それでも YOLO モードが必要な理由 危険だが、以下のユースケースでは事実上不可欠。 ...