Claude-Code

Anthropic が公開した「The Complete Guide to Building Skills for Claude」という 33 ページの PDF ガイドが話題になっています。このガイドをそのまま Claude Code のメモリに読み込ませてスキル構築に活用しようとする人もいますが、実は公式の skill-creator プラグインを使う方がはるかに効率的です。 skill-creator はガイドの内容をすべて反映しているだけでなく、テスト・最適化・トリガー精度改善といった仕組みも組み込まれています。PDF をメモリに入れるとコンテキストウィンドウを圧迫するリスクもあるため、新規スキル作成には skill-creator を導入するのがおすすめです。 Claude Code のスキルとは スキルとは、Claude に特定のタスクの実行方法を教える 指示・スクリプト・リソースのフォルダ です。SKILL.md ファイルに YAML フロントマターと指示を記述するだけで作成できます。 Claude Code は 3 段階の情報ロードシステム（Progressive Disclosure）を採用しています。 起動時: インストール済みスキルの名前と説明文のみをシステムプロンプトに読み込む（スキルあたり約 50〜100 トークン） 判定時: ユーザーの入力に関連するスキルがあるかを判定 実行時: 該当スキルの全内容をロード この仕組みにより、多数のスキルをインストールしてもコンテキストウィンドウを無駄に消費しません。 skill-creator プラグインのインストール skill-creator は Anthropic 公式マーケットプレイスに含まれています。Claude Code 内で以下のコマンドを実行するだけでインストールできます。 1 /plugin install skill-creator@claude-plugins-official インストール後、プラグインを有効化します。 1 /reload-plugins なお、/plugin コマンドで Discover タブを開き、GUI からインストールすることも可能です。プラグイン機能を利用するには Claude Code バージョン 1.0.33 以上 が必要です（claude --version で確認できます）。 ...

Claude Code の設定ファイル CLAUDE.md に「こう書け」「これは禁止」「この順番で処理しろ」とルールを追加していったら 300行を超え、AI の出力品質がどんどん落ちていった——そんな経験を経て「99%消した。残したのは、哲学だけ。」という結論に至った話が X で話題になっている。 なぜルールを増やすと AI の性能が落ちるのか コンテキストウィンドウの競合 LLM はコンテキストウィンドウ内のすべての情報を処理する。CLAUDE.md のルールが増えるほど、実際の作業に使える「注意力」が奪われる。コンテキストが埋まるにつれてパフォーマンスが低下するのは、LLM の根本的な特性だ。 指示の上限問題 IFScale ベンチマークの研究によると、フロンティアモデルは 150〜200個の指示 を超えたあたりから選択的注意のバイアスがピークに達し、それ以降は均一に失敗するパターンに収束する。Claude Code のシステムプロンプト自体がすでに約50個の指示を含んでいるため、ユーザーが使える枠は実質100〜150個。200行の詳細なルールを書いた時点で、すでに予算オーバーだ。 指示追従バイアス LLM はプロンプトの 先頭と末尾 の指示に従いやすい傾向がある。中間に埋もれたルールは見落とされがちだ。ルールが増えるほど、重要な指示が中間に埋もれて無視されるリスクが高まる。 具体的に何が起こるか 例えば「見出しは H2 を必ず4つ使え」「セクションは5つ構成にしろ」というルールを設定したとする。すると AI は、本来3セクションで十分な内容でも無理やり5セクションに引き伸ばし、冗長な文章を生成してしまう。 ルールに 従うこと自体が目的化 し、最適な出力を考える余地がなくなる。これは人間の組織でも起こる現象だ。過剰なルールがかえって生産性を下げる。 「哲学だけ残す」アプローチ 細かいルールではなく方針を伝える 悪い例: - 見出しは H2 を4つ使うこと - 各セクションは200〜300文字 - コードブロックには必ず言語指定をつけること - 箇条書きは最大5項目まで 良い例: - 読者が最短で理解できる構成を優先する - 冗長さよりも明確さを重視する Anthropic 公式の推奨 Anthropic の公式ドキュメントでも、CLAUDE.md について以下のように推奨している: 肥大化した CLAUDE.md は、実際の指示を AI に無視させる原因になる Claude がすでに正しくやっていることについては、わざわざルールを書かない 削除できるものは削除し、自動化できるものはフックに変換する Progressive Disclosure パターン すべての情報を CLAUDE.md に詰め込むのではなく、情報の見つけ方 を教える方法が効果的だ。 ...

VS Code マーケットプレイスにおける AI コーディングアシスタントの日次インストール数を示すグラフが話題になっている。GitHub Copilot のインストール数が急激に落ち込む「崖」が鮮明に表れており、SaaS 事業者やプロダクトマネージャーにとって示唆に富む内容だ。 グラフが示すもの 「Daily Install Counts of AI Coding Assistants in Visual Studio Code」と題されたグラフには、以下の 3 つの AI コーディングアシスタントの日次インストール数（30日移動平均）が描かれている。 GitHub Copilot（オレンジ）：2021年末から着実に成長し、2025年後半には日次 150,000 インストール近くまで到達。しかし 2026年に入って急落し、現在は 60,000 前後まで落ち込んでいる Claude Code（シアン）：2025年後半に登場し、直近で急速に伸長。日次 60,000 近くまで上昇 OpenAI Codex（イエロー）：同じく直近で伸びを見せているが、Claude Code よりやや控えめ 注目すべきは、GitHub Copilot のインストール数がピークから半分以下に急落している点だ。この「崖」は、競合の台頭と GitHub Copilot 自体の変化の両方が要因と考えられる。 急落の背景 GitHub Copilot の課金モデル変更 GitHub Copilot は 2024年12月に無料ティアを導入し、月 2,000 回のコード補完と 50 回のチャットリクエストという制限付きで提供を開始した。同時に、有料プランの価格体系も複雑化している。 Free：月 2,000 補完 / 50 チャット Pro：$10/月 Pro+：$39/月 Business：$19/ユーザー/月 Enterprise：$39/ユーザー/月 無料ティアの導入は新規ユーザー獲得を狙った施策だが、既存の有料ユーザーが無料枠で十分と判断して解約するケースもあり得る。また、Microsoft は従来の IntelliCode を廃止し、AI 支援を Copilot に一本化する戦略を取っている。 ...

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。 仕組み PR がオープンされると、Code Review は以下のステップを実行する: エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す 検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする 深刻度ランキング — 検出された問題を重要度順に並べる レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。 検出精度 Anthropic 社内でのテスト結果: PR サイズ 指摘ありの割合 平均指摘数 大規模（1,000行以上） 84% 7.5件 小規模（50行未満） 31% 0.5件 特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。 なぜ必要なのか Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。 Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。 利用条件 対象プラン: Team / Enterprise（Research Preview） 料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25 レビュー時間: 約 20 分 セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要 組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。 ...

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。 仕組み PR がオープンされると、Code Review は以下のステップを実行する: エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す 検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする 深刻度ランキング — 検出された問題を重要度順に並べる レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。 検出精度 Anthropic 社内でのテスト結果: PR サイズ 指摘ありの割合 平均指摘数 大規模（1,000行以上） 84% 7.5件 小規模（50行未満） 31% 0.5件 特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。 なぜ必要なのか Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。 Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。 利用条件 対象プラン: Team / Enterprise（Research Preview） 料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25 レビュー時間: 約 20 分 セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要 組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。 ...

Anthropic が公開した「The Complete Guide to Building Skills for Claude」は、Claude Code のスキル機能を本格的に活用するための 33 ページにわたる公式ガイドです。この記事では、ガイドの要点を日本語でまとめます。 Skills とは何か Skills は、Claude に特定のタスクやワークフローを教えるための 再利用可能な指示セット です。フォルダにパッケージ化され、一度作れば Claude.ai、Claude Code、API のすべてで動作します。 従来のように毎回プロンプトで細かく指示する代わりに、Skills を使えば「一度教えて、何度でも使える」ようになります。 Skills のファイル構造 my-skill/ ├── SKILL.md # メインの指示ファイル（必須） ├── scripts/ # 補助スクリプト ├── references/ # 参考資料 └── assets/ # アセットファイル 重要なルール: メインファイルは必ず SKILL.md（大文字小文字を区別） フォルダ名は kebab-case（例: notion-project-setup） README.md は含めない YAML フロントマターの設計 SKILL.md の冒頭に YAML フロントマターを記述します。ここがスキルの「顔」になります。 1 2 3 4 --- name: deploy-checker description: "本番デプロイ前のチェックリストを実行する。デプロイや本番リリースの話題が出たときに使用する" --- description には 何をするか と いつ使うか の 2 つを含めることが重要です。Claude はこのメタデータだけでスキルの使用タイミングを判断します。 ...

Claude Codeでツール実行のたびに「パスワード漏洩リスク: 0%」「悪意あるコード実行リスク: 0%」のようなセキュリティリスクのパーセンテージを表示させるCLAUDE.mdの設定がSNSで話題になった。これに対し、セキュリティエンジニアから「それは対策ではなくお気持ち表示」という指摘が上がり、議論を呼んでいる。 話題になった「パーセンテージ表示」 @wan_line_（ワン@AIのお兄さん）氏が2026年3月9日に投稿したポストでは、CLAUDE.mdに以下のようなルールを記述することが提案されていた: ツール実行のたびに パスワードが外に漏れる可能性: ○% 外部サーバーにデータが送られる可能性: ○% 悪意あるコードが動く可能性: ○% PCの設定が書き換わる可能性: ○% Claude Codeで「yes連打」してしまうユーザー向けに、実行前にリスクを可視化してくれるという趣旨だ。 セキュリティ専門家の反論:「お気持ち表示」 この投稿に対し、@sudachikawaii（シンジ☁Shinji）氏が反論した: セキュリティ屋から言うと、これは「対策」ではなく「お気持ち表示」です。LLMはコードの安全性を静的解析していないので、表示されるパーセンテージに技術的根拠がありません。 「0%」を見てyes押すのは、yes連打と同じです。 指摘のポイントは明快だ: LLMは静的解析エンジンではない — LLMが出すパーセンテージは、コードを構文解析して脆弱性を検出した結果ではなく、「それっぽい数値」を生成しているだけ 偽の安心感を与える — 「0%」という表示を見てユーザーが安心してyesを押すなら、結局yes連打と変わらない 技術的根拠がない — 実際のセキュリティリスク分析には、静的解析ツール（SAST）、依存関係チェック、ネットワーク通信の監視などが必要 Claude Codeに本当に効くセキュリティ対策 Claude Codeには、CLAUDE.mdの「お気持ちルール」よりもはるかに実効性のあるセキュリティ機能が組み込まれている。公式ドキュメントに基づき、本当にやるべき対策を整理する。 1. サンドボックスを有効にする 最も重要な対策。Bashコマンドの実行をOSレベルで隔離し、ファイルシステムやネットワークへのアクセスを制限する。 macOSではSeatbelt、LinuxではBubble Wrapが使用される /sandbox コマンドで有効化 2. denyルールで危険なコマンドをブロック permissions.deny に実行禁止コマンドを明示的に設定する。評価順は deny → ask → allow で、denyが最優先。 1 2 3 4 5 6 7 8 9 { "permissions": { "deny": [ "Bash(command:rm -rf *)", "Bash(command:curl *)", "Bash(command:wget *)" ] } } 3. 機密ファイルへのアクセスを遮断 .env やシークレットファイルへのアクセスをブロックする。 ...

ゼロトピック（Zero Topic）の #337「Claude Code時代の仕様書の役割」 が話題になっている。10X の矢本氏が、生成 AI が開発プロセスに与える影響と、仕様書の役割がどう変わるかを整理した回だ。 バイブコーディングの限界と仕様駆動開発 Claude Code のようなAIコーディングエージェントの登場で、コード生成速度は飛躍的に向上した。しかし「バイブコーディング」— AI に任せて探索的にコードを生成するアプローチ — には問題がある。 検証負債の蓄積: AI の生成速度が人間の理解・検証速度を上回る 意図不明なコード増殖: 内部構造を精査せず先に進み、誰も理解していない領域が広がる デバッグ困難化: コードの意図が不明では根本原因の特定が難しい こうした課題に対する解が 仕様駆動開発（Spec-Driven Development: SDD） だ。Thoughtworks Technology Radar Vol.32（2025年4月）で Trial に採用されたこの手法は、「仕様を先に定義し、その仕様に基づいて AI にコードを生成させる」という原則に立つ。 仕様書の役割の変化 従来の設計書は人間同士のコミュニケーションツールだった。AI との協働では「AI への指示書」としての側面が加わる。 SDD における仕様書の構成は、Kiro が提唱する3層モデルが分かりやすい: ファイル 役割 requirements.md ユーザーストーリーと受け入れ基準 design.md アーキテクチャ、シーケンス、設計上の注意 tasks.md 実装計画とタスク分解 重要なポイントは、仕様は 「唯一の情報源（Single Source of Truth）」 として機能し、プロセス駆動はルールブック（プロセスルール）が別途担当するという区別だ。 Claude Code での実践 基礎レベル: CLAUDE.md + ステアリングファイル CLAUDE.md に制約・規約・コンテキストを定義 .steering/ 配下に作業バッチフォルダを作成 要件定義書・設計書・タスクリストを生成・保存 タスクに沿ってコード生成・テスト実施 応用レベル: カスタムコマンドの活用 2026年1月に plansDirectory 設定が追加され、/plan モードで作成した計画書を Git 管理できるようになった。さらにカスタムコマンドを使えば、ドメイン知識を埋め込んだ独自のワークフローを構築できる。 ...

minicoohei 氏（@minicoohei）が、freee の公式 MCP サーバーと Claude Code を組み合わせて確定申告の仕訳1,428件をわずか20分で完了させた事例を公開した。手作業なら4〜5時間かかる Amex のクレジットカード明細の仕訳登録を、AI が自動化した。 ワークフローの概要 Amex の取引明細（1,428件）を入力データとして用意 — 通常の手作業では1件ずつ勘定科目を判断して登録する必要がある AI が70以上の分類ルールを自動生成 — 取引内容のパターンを分析し、勘定科目の振り分けルールを構築する 対話的なルール調整 — 人間との会話を通じてルールを精緻化する。税務リスクのある取引を事前に特定し、適切な処理方法を提案する 並列バッチ処理で一括登録 — freee API 経由で全件をエラーゼロで登録する freee MCP とは freee は公式の MCP サーバー（freee-mcp）を OSS として公開している。会計・人事労務・請求書・勤怠・販売の5領域にわたる API を、AI エージェントから操作可能にするインターフェースだ。 Claude Code や Claude Desktop から接続すると、「この請求書を発行して」「今月の経費を集計して」といった自然言語の指示で freee の業務を実行できる。 なぜ効果的なのか 従来の会計ソフトの自動仕訳機能は、事前に設定したルールに基づく単純なパターンマッチングだった。Claude Code を使うアプローチには以下の利点がある: 文脈理解による分類精度 — 取引先名や摘要の自然言語を理解して勘定科目を判断する。「AWS」なら通信費、「タクシー」なら旅費交通費、といった判断を人間と同等の精度で行える 対話による例外処理 — 判断に迷うケースを人間に確認し、その回答を以降のルールに反映する バッチ処理の効率 — MCP 経由で freee API を直接操作するため、GUI での手作業が不要 実務での注意点 freee MCP を Claude Code と組み合わせる場合、いくつかの実務的な考慮点がある: ...

Andrej Karpathy が公開した autoresearch は、AI エージェントが自律的に ML 実験を繰り返すツールだ。寝ている間に AI が 100 回実験し、朝起きたらモデルが賢くなっている——そんな研究スタイルを 630 行の Python コードで実現する。 autoresearch とは nanochat（軽量 LLM 学習コア）をシングル GPU・1 ファイルに凝縮し、AI エージェントが自律ループで学習コードを改善していく仕組み。 基本構造はシンプル: 人間が .md ファイル（プロンプト）を設計する AI エージェントが .py（学習コード）を自律的に改善する 各実験は ちょうど 5 分間 のトレーニングで構成され、1 時間あたり約 12 回、一晩で約 100 回の実験が自動で回る。 人間: program.md を設計（研究の方針・制約を定義） ↓ AI エージェント: 学習コードを修正 ↓ 5分間のトレーニング実行 ↓ 結果を評価（validation loss） ↓ 改善されていれば git commit → 次のイテレーションへ 技術的な特徴 630 行のミニマル設計 autoresearch の核心は「小さく始めて、エージェントに任せる」という哲学にある。 シングル GPU で完結（マルチ GPU 不要） ニューラルネットワークのアーキテクチャ、オプティマイザ、ハイパーパラメータすべてを AI が調整 git feature ブランチ上で動作し、改善があれば自動コミット MIT ライセンスで公開 「コードを書く」のではなく「プログラムをプログラムする」 Karpathy が強調するのは、研究者が Python ファイルを直接触るのではなく、Markdown でエージェントへの指示を設計するというパラダイムシフトだ。 ...