Claude-Code

ハーネスエンジニアリング入門 — 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% を達成しました。同じモデルでも、ハーネスの設計次第で性能が倍近く変わります。 ...

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 チェック プロジェクトルートで以下を確認する: ...

組織の課題管理から個人のタスク整理と優先度づけへ — 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 エージェント 一言で言えば： ...

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 自身が書く、作業を通じた学習メモです。 ...