Claude

Claude Code スキルの自動最適化 — テキスト勾配で「職人芸プロンプト」を工学に変える 「プロンプトは職人芸」——そんな時代が終わりつつあります。 @yusuke_post さん が発表した X 記事 では、プロンプトエンジニアリングを自動化する研究を応用して Claude Code の Skills を自動最適化する手法が紹介されています。ヒアリングメモから SaaS 導入提案書を生成するスキルを題材に、4 イテレーションで 13.6 点のスコア改善を達成しました。 @kgsi さん も「この取り組みすごい、ナレッジが溜まっている企業や組織ほどこの仕組みで効果が出そう」と反応しています。 全体像：何がどう繋がっているのか この記事で扱う内容を先に俯瞰します。 課題 Claude Code の Skills（SKILL.md）は、タスクの手順を定義する「指示書」です。しかし、良い指示書を書くのは難しく、試行錯誤が属人的になりがちです。 graph LR A["人間が SKILL.md を書く"] --> B["実行"] B --> C["結果がイマイチ"] C --> D["🤔 勘で修正<br/>（= 職人芸）"] D --> B style D fill:#f9c74f,color:#000 解決策：テキスト勾配による自動改善ループ 深層学習がパラメータを自動で最適化するように、SKILL.md を自動で最適化するのがテキスト勾配です。 graph TD A["① SKILL.md（現在の指示書）で実行"] --> B["② 出力を正解データと比較<br/>（人間の過去の成果物）"] B --> C["③ AI が差分を分析し改善点を言語化<br/>= テキスト勾配"] C --> D["④ テキスト勾配に従って<br/>SKILL.md を改訂"] D --> E["⑤ 改訂版で再実行"] E --> B C -.- F["例: 優先度の整理ステップが欠如している"] style C fill:#4ecdc4,color:#000 style F fill:#f0f0f0,color:#555,stroke-dasharray: 5 5 4 回繰り返すだけで 13.6 点のスコア改善を達成。 ...

Claude Code の /simplify と /batch — AI コーディングは「書く」から「整える・並列で移す」へ Tsukasansan 氏のポストが、Claude Code v2.1.63 で追加された 2 つの新スキル /simplify と /batch を紹介しています。この 2 つのスキルは、AI の役割を「コードを書く補助ツール」から「品質を整え、大規模な変更を並列実行する分業チーム」へと変える転換点です。 /simplify — PRに出す前の「仕上げ」を自動化 /batch — 大規模マイグレーションを並列で一気に実行 Claude Code の開発者 Boris Cherny 氏も、この 2 つのスキルについて「毎日使っている」と述べています。 /simplify: 3 つのエージェントによる自動コードレビュー /simplify は、実装完了後に実行する「仕上げ」コマンドです。git diff で最近の変更を検出し、3 つの専門レビューエージェントを並列実行します。 3 つのレビュー観点 エージェント 検出対象 具体例 コード再利用 重複ロジック、既存ユーティリティで置き換え可能なコード 同じバリデーションが 3 箇所にコピペされている コード品質 冗長な状態管理、パラメータの肥大化、リーク抽象化 引数が 8 個ある関数、使われていない変数 効率性 不要な処理、並列化の機会、ホットパス内の重い処理 ループ内での毎回の DB クエリ、不要な再レンダリング 3 つのエージェントが問題を検出するだけでなく、修正まで自動的に適用します。従来のリンターと異なり、高レベルのアーキテクチャ上の問題に対応するのが特徴です。 使い方 1 2 3 4 5 6 7 # 基本: 変更ファイルを自動レビュー・修正 /simplify # 特定の観点にフォーカス /simplify focus on memory efficiency /simplify check for unnecessary dependencies /simplify focus on security patterns in the auth flow 実践的なワークフロー 実装完了後、PR を出す前に /simplify を実行するだけです。 ...

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術 — スキルが複利で効く構造をつくる gura 氏の投稿が、Claude Code を使った PM 業務の知見を共有しています。2 ヶ月間の実運用で最も効いた設計判断は、Skill（処理レイヤー）と CLAUDE.md（ドメイン知識レイヤー）の分離だったとのことです。この考え方は、Claude Code の公式アーキテクチャとも一致する設計パターンです。 問題：なぜ全部入りの設定は破綻するのか Claude Code を使い始めると、多くの人が CLAUDE.md にあらゆる情報を詰め込みます。プロジェクトの規約、処理手順、ドメイン知識、スタイルガイド。しかしこの「全部入り」アプローチには構造的な問題があります。 コンテキスト汚染: CLAUDE.md はセッション開始時に全文がロードされるため、情報量が増えるほどトークンを圧迫します Lost in the Middle: 長大なコンテキストの中間部分が軽視される現象が発生します 再利用不能: プロジェクト固有の知識と汎用的な処理手順が混在し、別プロジェクトへの横展開ができません SO Technologies 開発者ブログの分析によると、全部入り CLAUDE.md はセッション開始時にコンテキストの 40〜50% を占有するケースもあったと報告されています。 2 つのレイヤーを分離する gura 氏が提唱するのは、明確な 2 層構造です。 Skill = 処理レイヤー 「どのフォルダから何を読んで、どう加工して、どこに出すか」を定義する Skill は入力と出力が明確な、小さな処理単位です。 Skill の例 入力 出力 議事録の文字起こし 音声データ テキスト議事録 外部向け議事録変換 内部議事録 フィルタリング済み議事録 Slack 共有 文書 Slack メッセージ レポート生成 各種データ フォーマット済みレポート Skill は どのプロジェクトでも処理の骨格は同じ です。ファイルの場所は .claude/skills/<skill-name>/SKILL.md に配置し、YAML フロントマターで名前と説明を記述します。 ...

Claude Code ベストプラクティス — 成果を安定させる 7 つの鉄則と公式ガイドの設計思想 qiitapoi 氏のポストが、Qiita 記事「Claude Code ベストプラクティス – 成果を安定させる 7 つの鉄則」を紹介しています。この記事は、Claude Code の公式ベストプラクティスを実務者の視点で 7 つのルールに凝縮したもので、「具体的に頼む」「必ず検証する」という基本から、セッション管理やコスト意識まで、日々の運用に直結する指針をまとめています。 本記事では、この 7 つの鉄則を公式ドキュメントの設計思想と照らし合わせながら、なぜそのルールが効くのかを掘り下げます。 公式ベストプラクティスの根本原則: コンテキストウィンドウ Claude Code 公式ベストプラクティスは、冒頭で明確に述べています。 ほとんどのベストプラクティスは 1 つの制約に基づいています。Claude のコンテキストウィンドウはすぐにいっぱいになり、満杯になるにつれてパフォーマンスが低下します。 Claude Code の 200K トークンのコンテキストウィンドウには、すべてのメッセージ、読み取ったファイル、コマンド出力が蓄積されます。コンテキストが埋まるにつれて、初期の指示を「忘れる」、ミスが増えるといった品質低下が起きます。7 つの鉄則のほぼすべてが、この制約への対処法として理解できます。 7 つの鉄則と公式ガイドの対応 nogataka 氏の Qiita 記事が提案する 7 つの鉄則を、公式ドキュメントの推奨事項と対応させて整理します。 鉄則 内容 公式ガイドの対応セクション 1. 具体的に頼む 5W1H で指示を明確にする プロンプトで具体的なコンテキストを提供する 2. 必ず検証する diff、テスト、コストの 3 点確認 Claude に自分の作業を検証する方法を与える 3. CLAUDE.md でルール言語化 プロジェクト固有の規約を明文化する 効果的な CLAUDE.md を書く 4. セッション短く保つ 1 タスク 1 セッション セッションを管理する 5. 計画→実行の 2 段階 5 分ルールで判断 最初に探索し、次に計画し、その後コーディングする 6. コスト意識 /cost で定期確認 コンテキストを積極的に管理する 7. 自動化への次ステップ Hooks, MCP, Agent Teams 自動化とスケール 7 つの鉄則は、公式ガイドの膨大な内容を実務者が日常的に参照できる形に圧縮したものと位置づけられます。 ...

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方 @yousukezan 氏のポストが、AI 駆動開発における秘密情報管理の盲点を端的に指摘しています。 Claudeが社内に広がるほど、.envが危ない。Cowork時代に必要なのは「便利さ」より秘密情報の置き場所 引用元の Qiita 記事では、Claude Code や Cowork が「チャットで質問するだけのツール」から「ローカルファイルに直接アクセスする開発エージェント」へ進化したことで、従来の .gitignore だけでは守りきれない脅威が生まれていると論じています。本記事では、この問題の技術的背景と実践的な対策を掘り下げます。 何が変わったのか — 脅威モデルの転換 従来の開発ワークフローでは、.env ファイルの脅威モデルは明確でした。 脅威 対策 Git リポジトリへの混入 .gitignore に記載 本番環境への漏洩 環境変数やシークレットマネージャで注入 他人のマシンへの流出 ローカルに置く前提なので問題なし ところが、Claude Code のような AI エージェントがローカルファイルを直接読み書きする時代になると、第三の脅威が加わります。 新しい脅威 内容 AI エージェントによる読み取り .env がツールの入力コンテキストに載る 意図しないクラウド送信 読み取った内容が LLM の API リクエストに含まれる 組織内の横展開 Cowork で複数人が同じプロジェクトを触る際の露出 IPA「情報セキュリティ 10 大脅威 2026」でも「AI の利用をめぐるサイバーリスク」が初選出で 3 位にランクインしており、この脅威モデルの転換は業界全体の認識となりつつあります。 Claude Code は .env をどう扱うのか 自動読み込み問題 セキュリティ研究者 Dor Munis 氏の調査によると、Claude Code は .env、.env.local などのファイルを自動的に読み込み、API キーやトークンをメモリに展開していることが判明しています。プロキシ認証情報が意図せず読み込まれ、HTTP 407 エラーとプロキシ料金の異常な高騰として問題が顕在化しました。 ...

Claude Cowork 入門ガイド — プロンプトを頑張る時代の終わり、「仕組み化」で AI と働く新しいスタイル 長谷川氏（@taichi_we）が投稿した「Claude Cowork の始め方ガイド」が X 上で大きな反響を呼んでいます。ブックマーク数 14,850、いいね 6,021、閲覧数 300 万超という驚異的な数字です。 プロンプトを頑張る時代は、もう終わりに近い。これから必要なのは、「AIに何を渡せば仕事が進むか」を整えることです。 この記事では、元ポストの内容をベースに、公式ドキュメントや技術解説記事の情報を加えて、Claude Cowork の全体像と実践的な始め方を解説します。 Claude Cowork とは何か Claude Cowork は、Anthropic が提供する 非エンジニア向けの自律型 AI エージェント機能 です。Claude Desktop アプリに統合されており、「Chat」「Code」と並んで「Cowork」タブから利用できます。 もともと Claude Code はエンジニア向けのコマンドラインツールとして提供されていましたが、ファイル整理やスプレッドシート作成など、コーディング以外の用途にも多く使われていることに Anthropic が気づきました。実際、Claude Code でも業務タスクは十分に実行できます。ただし、ターミナル操作は非エンジニアにとってハードルが高いという課題がありました。Cowork は Claude Code と同等の能力を GUI で包み、誰でもアクセスできるようにしたものです。 項目 Claude Chat Claude Code Claude Cowork 対象ユーザー 全般 開発者中心（だが業務タスクも可能） 非エンジニアを含む全職種 インターフェース Web / アプリ ターミナル（CLI） Desktop アプリ（GUI） ファイル操作 アップロード / ダウンロード ローカル直接アクセス ローカル直接アクセス 自律実行 なし あり あり 差別化ポイント 手軽な対話 Bash 実行、Git 操作、MCP、スキル プラグイン、コネクター、スケジュール実行 前提スキル 不要 ターミナル操作に慣れている必要あり 不要 本質的な違いは「何ができるか」ではなく「誰がアクセスしやすいか」です。Claude Code でもレポート作成やファイル整理といった業務タスクは問題なくこなせます。Cowork はその能力を、ターミナルに馴染みのないユーザーにも開放したものと考えるのが正確です。 ...

Claude Opus 4.6 がゼロデイ脆弱性を500件発見 — AI推論がセキュリティ業界を揺るがす @neurostack_0001 氏のポストが、Anthropic の衝撃的な発表を紹介しています。Claude Opus 4.6 が、ファジングやカスタムツールを使わず、コードの推論だけで500件以上のゼロデイ脆弱性を発見したという内容です。 AnthropicがClaude Opus 4.6で「ゼロデイ脆弱性を大規模に発見できる」と発表。500件以上の高重大度脆弱性を検出・検証済み。ファジングやカスタムツール不要で、コードの推論だけで脆弱性を見つけている点が注目。 この発表は、CrowdStrike や Cloudflare の株価を8%以上下落させるほどのインパクトを持ちました。セキュリティ業界に何が起きているのか、技術的な背景から掘り下げます。 ファジングとは何か ファジング（Fuzzing）は、プログラムに対して無効なデータ、予期しないデータ、ランダムなデータを大量に入力し、クラッシュや異常動作を引き起こすことで脆弱性を検出するテスト手法です。1988年にウィスコンシン大学の Barton Miller 教授が考案し、現在ではセキュリティテストの標準手法となっています。 ファジングの種類 ファジングは、テスト対象の内部構造をどの程度把握しているかによって3つに分類されます。 分類 内部構造の把握 特徴 ブラックボックス なし 入出力のみを観察。実装が不明でも実行可能 グレーボックス 部分的 コードカバレッジを計測し、入力生成を最適化 ホワイトボックス 完全 ソースコードを解析し、制約条件を満たす入力を生成 また、入力データの生成方法でも分類できます。 ミューテーションファジング: 既知の有効な入力（シード）に対して、ビット反転やバイトの挿入・削除・置換などの変異を加えてテストケースを生成します。実装が容易で汎用性が高い手法です ジェネレーションファジング: 入力データの構造や文法を定義し、仕様に基づいて有効な形式でありながらも不正な値を含むテストケースを生成します。プロトコルやファイルフォーマットのテストに有効です カバレッジガイドファジング — AFL の登場 2014年に登場した AFL（American Fuzzy Lop）は、ファジングの実用性を大きく向上させました。名前はウサギの品種に由来しています。 AFL の革新は「カバレッジガイド」の概念です。テスト対象プログラムをインストルメント（計測コードの埋め込み）し、各入力がどの実行経路を通ったかを記録します。新しい経路を発見した入力を優先的にミューテーションすることで、コードの未探索領域へ効率的に到達します。 [シード入力] → [ミューテーション] → [実行・カバレッジ計測] ↑ ↓ └── [新しい経路を発見？] ──┘ Yes → キューに追加 No → 破棄 この手法はグレーボックスファジングとも呼ばれ、AFL の後継である AFL++ や Google の libFuzzer など、多くのツールが同様のアプローチを採用しています。 ...

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

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