Claude

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する @dify_base 氏のポストが、Claude Code の Subagent と Agent Teams の違いを図解で整理しています。 Claude Code の「Subagent」と「Agent Teams」の違い、意外と知らない人が多いので、図解で整理しました👇 ✅Subagent → 調査して結果を返すだけの部下 ✅Agent Teams → 複数AIが議論・協力する自律チーム この2つの機能は名前が似ていて混同しやすいですが、設計思想が根本的に異なります。本記事では、公式ドキュメントと Qiita の設計レイヤ分析記事を基に、両者の違いを構造的に解説します。 一言で言う違い Qiita の記事が最も端的に表現しています。 Subagent は「働くエージェント」、Agent Teams は「議論するエージェント」 Subagent Agent Teams 一言で 調査して結果を返す部下 議論・協力する自律チーム 比喩 上司に報告するだけの社員 横で相談し合うプロジェクトチーム 構造的な違い — 通信モデルが本質 Subagent: スター型（親子通信のみ） メインエージェント ／ ｜ ＼ Subagent Subagent Subagent (Explore) (Plan) (general) Subagent はメインエージェントの単一セッション内で動作します。結果をメインエージェントに返すことしかできず、Subagent 同士は直接通信できません。 Agent Teams: メッシュ型（全方向通信） リード（チームリーダー） ／ ｜ ＼ Teammate Teammate Teammate (API) (UI) (Test) ＼ ｜ ／ 共有タスクリスト Agent Teams のメンバーは完全に独立したセッションとして動作し、互いに直接メッセージを送受信できます。リードを介さずに横の連携が可能です。 ...

Trivy VS Code 拡張が改ざんされ、ローカル AI エージェントが認証情報を窃取 — hackerbot-claw の全貌 セキュリティ研究者のyousukezan氏が、Aqua Security の脆弱性スキャナー「Trivy」の VS Code 拡張が改ざんされ、開発者のローカル AI コーディングツールを悪用して認証情報を窃取するサプライチェーン攻撃を紹介しています。 Aqua Trivy VS Code拡張が改ざんされ、AIコーディング支援ツールを悪用する異例のサプライチェーン攻撃が発覚した。正規機能を装いながら裏で認証情報を収集する手口で、被害はGitHubリポジトリの乗っ取りにも及んだ。 — yousukezan この事件の異例な点は、従来のマルウェアやバックドアではなく、開発者のマシンに既にインストールされている AI コーディングツールを武器として利用したことです。Claude、Codex、Gemini、GitHub Copilot CLI、Kiro CLI を最大権限で呼び出し、自然言語プロンプトで機密情報を探索させるという、AI 時代に固有の新しい攻撃ベクターです。 事件の全体像 この攻撃は、hackerbot-claw と名乗る自律型 AI ボットによる大規模キャンペーンの一部です。2026年2月21日〜28日の間に、Microsoft、DataDog、CNCF プロジェクトなど少なくとも7つの主要リポジトリが標的となりました。 影響を受けたリポジトリ リポジトリ Stars 攻撃手法 結果 aquasecurity/trivy 25k+ pull_request_target 悪用 PAT 窃取、リポジトリ乗っ取り avelino/awesome-go 140k+ Go init() 関数にペイロード注入 GITHUB_TOKEN 窃取 microsoft/ai-discovery-agent - ブランチ名コマンドインジェクション RCE 達成 DataDog/datadog-iac-scanner - ファイル名ベースのインジェクション RCE 達成（9時間で修正） ambient-code/platform - CLAUDE.md プロンプトインジェクション Claude が検出・拒否 project-akri/akri (CNCF) - curl | bash 直接インジェクション RCE 達成 RustPython/RustPython 20k+ Base64 ブランチインジェクション 攻撃試行 hackerbot-claw の正体 hackerbot-claw は GitHub 上で自らを「autonomous security research agent powered by claude-opus-4-5」と名乗り、暗号通貨の寄付を募っています。README には9クラス・47サブパターンの「脆弱性パターンインデックス」を持ち、47,391リポジトリをスキャン済みと記載されています。 ...

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差 まさお(@AI_masaou) 氏が、Claude Code のハーネス（開発基盤）をテーマにした約 80 分の対談形式勉強会のまとめ記事を公開しました。 新しい note を公開しました！ハーネスエンジニアリングに向き合う上で、実践的にはどうしているのか？の勉強会を行いましたのでそのまとめを記事にしました — @AI_masaou 元記事（ハーネスエンジニアリングの実践知を共有！【質問/勉強会のまとめ】）は有料コンテンツのため、本記事ではテーマであるハーネスエンジニアリングの実践知について、公開情報をもとに技術的な背景と具体的な手法を解説します。 ハーネスエンジニアリングとは 「ハーネス」とは馬具のことです。馬の力をそのまま放置すれば暴走しますが、ハーネスで制御すれば有用な仕事に変わります。AI エージェントも同じです。LLM の推論能力をそのまま使うのではなく、適切な制御基盤（ハーネス）で囲むことで信頼性の高い成果に変換するのがハーネスエンジニアリングです。 コンピュータの構成に対応させると、位置づけがわかりやすくなります。 コンピュータ AI エージェント CPU LLM（推論エンジン） OS エージェントハーネス（制御・管理基盤） アプリケーション AI エージェント（実行層） CPU がどれだけ高速でも、OS が適切に管理しなければアプリケーションは動きません。同様に、LLM がどれだけ賢くても、ハーネスの設計が悪ければエージェントの出力品質は上がりません。 コンテキストエンジニアリングとの関係 Andrej Karpathy が X で提唱した「コンテキストエンジニアリング」 は、ハーネスエンジニアリングの中核概念です。 Context engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy LLM のコンテキストウィンドウを「RAM」と捉え、次のステップに必要な最適な情報だけを入れる技術です。ハーネスエンジニアリングはこのコンテキスト管理の仕組み全体を包む上位概念にあたります。 ハーネスエンジニアリング（全体設計） ├── コンテキストエンジニアリング（何を LLM に渡すか） ├── 権限制御（何を許可・禁止するか） ├── ライフサイクル自動化（いつ何を実行するか） └── 並列実行・隔離（どう安全に並列化するか） 「環境設計 > モデル能力」— OpenAI Codex チームの実証 ハーネスエンジニアリングの重要性を最も説得力をもって示したのが、OpenAI のエンジニアリングチームによる 5 ヶ月間の実験です。 ...

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み Claude Code で生成したコードをローカル LLM（Ollama + Qwen3）でレビューする構成を前回の記事で紹介しました。しかし、汎用モデルのままでは「受注ステータスの遷移ルール」や「金額計算に float を使ってはならない」といった社内固有のルールを知りません。 この記事では、Qwen3 を社内業務に特化させ、特定のコーディング規約・業務ルール・過去の障害パターンを踏まえたレビューができるようにする 4 段階のカスタマイズ手法を紹介します。 全体像：4 段階のカスタマイズ レベル 手法 導入期間 効果 専門知識 1 Modelfile（システムプロンプト） 即日 ルールベースの指摘 不要 2 RAG（社内ドキュメント検索） 1〜2 日 文脈を踏まえた指摘 Docker の基本 3 Few-shot（レビュー事例の学習） 数日 パターン認識の向上 不要 4 LoRA ファインチューニング 1〜2 週間 モデル自体の精度向上 Python・ML の基本 レベル 1：ルールを「教える」 ← すぐできる レベル 2：資料を「渡す」 ← 1〜2日 レベル 3：お手本を「見せる」 ← 数日 レベル 4：頭脳を「鍛える」 ← 1〜2週間 推奨: レベル 1 から順に導入し、効果を確認しながらステップアップしてください。多くの場合、レベル 1 + 2 で十分な精度が得られます。 ...

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...

.env の代わりに lkr で LLM API キーを安全に管理する — セットアップから Claude Code 連携まで AI エージェントがローカルファイルを読み書きする時代、.env に平文で置いた API キーが LLM のコンテキストに載るリスクが現実のものになっています。前回の記事ではこの問題の全体像を、aws-vault の記事では AWS 認証情報の保護を解説しました。 本記事では、LLM Key Ring（lkr）を使って LLM API キーを安全に管理する具体的な手順を解説します。aws-vault が AWS 認証情報に特化しているのに対し、lkr は OpenAI・Anthropic・Google など LLM API キーの管理に特化したツールです。 lkr が解決する問題 .env に LLM API キーを置くリスク 多くの開発者は .env ファイルに API キーを平文で保存しています。 1 2 3 # .env（平文で保存されている） OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx このファイルには4つの攻撃ベクトルがあります。 攻撃ベクトル 説明 Git への混入 .gitignore に頼るヒューマンエラー。うっかりコミットは後を絶たない シェル履歴への漏洩 export OPENAI_API_KEY=sk-... が ~/.bash_history に残る プロセス情報への露出 ps コマンドで環境変数が見える AI エージェントによる抽出 Claude Code がファイルを読み取り、LLM の API リクエストに含まれる 4番目が AI 時代に特有の脅威です。Claude Code は.env ファイルを自動的に読み込むことが確認されており、API キーが意図せず Anthropic のサーバーに送信されるリスクがあります。 ...

「AIが覚醒する魔法の言葉」は本当に効くのか — プロンプトエンジニアリングの実態と公式ガイドの教え @fit_youtubead 氏のポストが、Claude と ChatGPT で使える「魔法のプロンプト」を紹介し、大きな反響を呼んでいます。 「最高の専門家として、思考プロセスを分解し、初心者にも再現できる形で5ステップで出力してください」 これだけ。なぜ強いのか？理由は3つ。 役割を与える → AIの精度が跳ね上がる 思考を分解させる → 中身が薄くならない 再現性を指定する → 実用的で使えるアウトプットになる 確かに、雑な指示よりも構造化された指示の方が良い結果を得られるのは事実です。しかし「魔法の言葉」と呼ぶには、いくつか知っておくべきことがあります。本記事では、ツイートで紹介された3つのテクニックを、Anthropic と OpenAI の公式ガイドおよび研究論文に照らし合わせて検証します。 テクニック1: 役割を与える（ロールプロンプティング） 「最高の専門家として」のように、AI に特定の役割やペルソナを与えるテクニックです。 公式ガイドの見解 Anthropic はプロンプトエンジニアリングのベストプラクティスで、ロールプロンプティングを推奨テクニックの1つとして挙げています。「法律アドバイザー」「データアナリスト」「カスタマーサポート担当」のように、具体的な文脈に合わせてモデルの声とふるまいを調整する手法です。 OpenAI も公式ガイドでシステムプロンプトによる役割設定を推奨しています。 研究が示す実態 ところが、学術的な研究を見ると、ロールプロンプティングの効果は「場合による」というのが正確な答えです。 研究 結果 対象モデル Better Zero-Shot Reasoning with Role-Play Prompting AQuA データセットで精度が53.5%→63.8%に向上（+10.3pt） GPT-3.5 ExpertPrompting 詳細な専門家ペルソナが単純なペルソナを大幅に上回る 複数モデル When “A Helpful Assistant” Is Not Really Helpful 追加のペルソナは性能を向上させない 4モデルファミリー Persona is a Double-edged Sword GPT-4ではペルソナの有無で差は最小限 GPT-4 PromptHub の検証記事は、これらの研究を総合して以下のように結論づけています。 創作的なタスク（文体の調整、トーンの統一）では効果がある 精度ベースのタスク（分類、計算、ファクトチェック）では、新しいモデルほど効果が薄い 「天才ペルソナが愚か者ペルソナより劣る」という矛盾した結果も報告されている つまり、「専門家として」と付けるだけで「精度が跳ね上がる」わけではありません。効果があるのは、役割指定によってモデルの出力スタイルや視点が適切に制約されるケースです。 ...

「上位 1% の Claude Skills 構築方法」を技術的に読み解く — スキルの構造・設計パターン・組織展開 @sales_muscle 氏が X で投稿した、Claude Skills の構築ガイドが反響を呼んでいます。 上位1%のClaude Skills構築方法 投稿では、AI 活用の基準が「プロンプトのうまさ」から「AI にスキル（専門能力）を組み込み、組織の資産にできるか」へ移行したと主張しています。本記事では、この投稿の内容を Claude Code の公式ドキュメントと照らし合わせ、スキルの技術的な構造と実践的な設計パターンを掘り下げます。 Claude Skills とは何か プロンプトからスキルへの進化 投稿の核心は「指示（プロンプト）からスキルへ」という転換です。これは技術的に正確な指摘です。 従来の AI 活用: ユーザー → プロンプトを毎回書く → AI が回答 問題: 知識がチャットセッションに閉じる、再現性がない スキルベースの AI 活用: ユーザー → /skill-name で呼び出す → AI がスキルの手順に従って実行 利点: 再現性あり、共有可能、自動呼び出し対応 Claude Code 公式ドキュメントによると、スキルは「SKILL.md ファイルに指示を書き、Claude のツールキットに追加する」仕組みです。Claude は関連するタスクで自動的にスキルを読み込むか、/skill-name で直接呼び出せます。 スキルの技術的な定義 スキルは単なるプロンプトテンプレートではなく、以下の要素を持つ構造化されたモジュールです。 要素 役割 YAML フロントマター 名前、説明、呼び出し制御、許可ツールなどのメタデータ Markdown 本文 Claude が従う具体的な手順・ルール サポートファイル テンプレート、例、スクリプトなどの補助リソース 文字列置換 $ARGUMENTS、$0、${CLAUDE_SESSION_ID} などの動的値 スキルは Agent Skills オープン標準に準拠しており、Claude Code 固有の機能ではなく、複数の AI ツールで動作する標準仕様です。 ...

2 人で 100 人に勝つ — AI を「自分の分身」に変える実務活用の 6 つの原則 @taichi_we（長谷川氏 / Levela CTO）が「有益、AIの本質」とコメントして共有した、@sales_muscle（OneBiz / Levela）の投稿が注目を集めています。 ブックマーク 100 超、閲覧 3.5 万という反応は、「少人数で AI を使いこなし、大企業に匹敵する生産性を出す」というテーマへの関心の高さを示しています。本記事では、投稿で紹介された 6 つの原則を掘り下げつつ、2026 年の AI 活用の現実と照らし合わせます。 原則 1: 汎用 AI が専用 AI より優秀な理由 投稿の最初のポイントは、業務特化の SaaS ツールより Claude のような汎用 AI の方が優れているという主張です。 これは一見、直感に反します。専用ツールの方が精度が高いのでは? しかし、少人数チームの文脈では論理が逆転します。 専用 AI の限界: 業務ごとにツールが分断される（営業は A、経理は B、マーケは C） ツール間の連携が手動で発生する 各ツールの学習コストが積み重なる 「自分の判断基準」を各ツールに教え込む手間が N 倍になる 汎用 AI の強み: 1 つのインターフェースで全業務を横断できる 自分の思考プロセスを一度教えれば、全業務に適用される コンテキストが途切れない 少人数チームにとって最も貴重なのは「コンテキストスイッチのコスト」です。5 つの専用ツールを使い分けるより、1 つの汎用 AI に自分の判断基準を教え込む方が、トータルの生産性は高くなります。 原則 2: AI にスキルを覚えさせる — 思考プロセスの外部化 投稿の核心は「AI に自分のスキルを教え込む」ことです。これは単なるプロンプトエンジニアリングではなく、自分の思考プロセスの構造化と外部化を意味します。 ...

AI が書いた CLAUDE.md は逆効果 — 「コンテキストファイルの自動生成は精度を下げる」という研究 @at_sushi_（門脇敦司）氏が X で投稿した、AI 生成のプロンプトファイルに関する記事が注目を集めています。 CLAUDE.md のようなプロンプトファイルを AI に生成させると「逆に精度が下がる」という研究です。AI 文書は冗長で、AI 自身を混乱させます。では、どうすればいいのか？ というと、「本当に重要な情報だけを、開発者が書く」というのが現在の正解です 元記事は Zenn の解説記事で、ETH Zurich と LogicStar.ai の研究チーム（Gloaguen et al.）による論文「Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?」を日本語で紹介しています。本記事では、この研究の実験データを詳しく読み解き、CLAUDE.md / AGENTS.md の書き方への実践的な示唆を整理します。 研究の概要 — 何を検証したのか 背景 CLAUDE.md、AGENTS.md、CURSORRULES — これらの「コンテキストファイル」は、AI コーディングエージェントにリポジトリの慣習や制約を伝えるための指示書です。Anthropic、OpenAI、Cursor はいずれもこれらのファイルの作成を強く推奨しています。 しかし、「コンテキストファイルは本当にエージェントの性能を向上させるのか?」 という基本的な問いに対して、厳密な検証はこれまで行われていませんでした。 実験設計 ETH Zurich の研究チームは、3 つの条件で比較実験を実施しました。 条件 内容 なし（None） コンテキストファイルなし（ベースライン） LLM 生成 エージェント開発者の推奨に従い LLM に自動生成させたファイル 人間作成 開発者がリポジトリにコミットしたファイル 評価対象モデル: Claude Code（Sonnet 4.5）、Codex（GPT-5.2 / GPT-5.1 mini）、Qwen Code（Qwen3-30b-coder） ...