Claude-Code

「Claude Ads」の正体 — Anthropic 公式ではない個人開発スキルが日本でバズった構造を解剖する @lapper_s_high 氏のポストが、「Claude Ads」の名前が引き起こした混乱を端的に指摘しています（いいね 482）。 開発者も日本でこんなに話題になるなんて思わなかったのでは・・ Claude Adsなんて名前つけるから。。 引用元の @ryottaman 氏のポスト（表示 27万、ブックマーク 390）が拡散の起点となり、日本の SNS では「Anthropic が広告運用ツールを出した」という誤解が広がりました。 実際には、Claude Ads は **Anthropic の公式製品ではなく、個人開発者が GitHub に公開した Claude Code 向けのスキル（拡張機能）**です。本記事では、なぜこの混乱が起きたのか、Claude Ads の実態は何なのか、そして Claude Code のスキルシステムがどのように機能するのかを解説します。 なぜ混乱が起きたのか — 3つの偶然の重なり 偶然1: Anthropic のスーパーボウル CM 2026年2月、Anthropic はスーパーボウル第60回大会で CM を放映しました。キャッチコピーは 「Ads are coming to AI. But not to Claude.」（広告は AI にやって来る。だが、Claude には来ない）。OpenAI が ChatGPT への広告導入を発表した直後のタイミングで、「Claude は広告を入れない」と宣言する内容でした。 この CM は大きな話題となり、OpenAI の Sam Altman CEO が「面白いが明らかに不誠実」と反論する事態にまで発展しています。 偶然2: 「Claude Ads」という名前 その直後、個人開発者の Daniel Agrici 氏が GitHub に公開したのが claude-ads です。これは Claude Code で広告アカウントを監査するスキルであり、「Claude を使って Ads（広告）を分析する」という意味での命名でした。 ...

「Claude Codeが無料で使える最強AIエージェント」は本当か — Accomplish の実態とAI煽りの再来 ガガロットAI(@gagarotai200)氏のポストが604いいね、764ブックマーク、約42,000表示と大きな反響を呼んでいます。 『Claude Code』が無料で使える最強AIエージェントが登場したww Accomplishっていうローカルで動くAIエージェントがGitHubに上がってたから共有する。これ入れれば、Claude Codeレベルの AIエージェントがサブスク購入なしで永遠に使えるwww — ガガロットAI(@gagarotai200) この投稿者は、以前「OpenClawで5人解雇」という根拠不明の煽りポストでも注目を集めた人物で、AIスクールを運営しています。今回も「最強」「無料」「永遠に使える」というキーワードが並んでいますが、主張はどこまで正確なのでしょうか。Accomplish の実態を公式情報から検証します。 Accomplish とは何か Accomplish は2026年1月13日に公開されたオープンソース（MITライセンス）のデスクトップ AI エージェントです。GitHub Stars 9.6k、Forks 1k、コントリビューター31名と、一定の支持を集めています。 基本情報 項目 内容 開発元 accomplish-ai ライセンス MIT 技術スタック Electron + React + TypeScript 対応OS macOS（Apple Silicon / Intel）、Windows 11 最新バージョン 0.3.10 内部構造 OpenCode CLI を node-pty 経由で起動 主要機能 ブラウザ自動化: Web検索、フォーム入力、データ抽出 ファイル管理: フォルダ整理、ファイル名変更、コンテンツベースの分類 ドキュメント作成: レポート作成、要約、メール下書き ワークフロー自動化: 反復タスクの自動化 対応 AI モデル カテゴリ プロバイダー クラウドAPI Anthropic（Claude）、OpenAI、Google AI、xAI、DeepSeek、Moonshot AI 等 クラウドインフラ Amazon Bedrock、Azure Foundry、OpenRouter、LiteLLM ローカル Ollama、LM Studio 主張の検証 主張1: 「Claude Codeレベルの AIエージェント」 検証結果: 大幅に誇張 ...

「Figma は 100% 不要」宣言の真意 — Claude Code が溶かすデザインとコードの境界 @kawai_design 氏が X で公開した記事が議論を呼んでいます。 Claude Code を使えば使うほど、Figma を開く理由が消えていく。これは私だけの感覚ではありません。今、世界中のデザイナーが同じ疑問を抱えています。私の結論は明確です。Figma は 100% 不要。 同時期に UX Collective に掲載された Michael Buckley 氏の記事「Figma はデザインツールではない。コードを避けるためのピタゴラスイッチだ」も世界のデザイナーを震撼させました。本記事では、この「Figma 不要論」の構造と、Figma 自身の対応、そして AI 時代のデザインワークフローの変化を技術的に整理します。 「ピタゴラスイッチ」批判 — 何が問題なのか UX Collective の記事が突いた急所 Michael Buckley 氏の記事は、Figma でのデザイン作業を**ルーブ・ゴールドバーグ・マシン（ピタゴラスイッチ）**に例えました。 Figma でボタンを作る作業: 1. Auto Layout を設定する 2. パディングを調整する 3. ホバーステートを作る 4. インタラクションを設定する 5. プロトタイプモードで動作確認する 6. 開発者に引き渡す 7. 開発者がコードで再実装する 開発者が同じボタンを作る作業: <button className="btn-primary">送信</button> → 5 分で完了。ホバー、アクセシビリティも含めて 「パンケーキを返すためにピタゴラスイッチを作るようなもの」— この比喩が刺さったのは、多くのデザイナーが無意識にこの非効率を受け入れていたからです。 本質的な問題: デザインとコードの「翻訳」 Figma の存在意義はデザインとコードの間の翻訳レイヤーにあります。 従来のワークフロー: デザイナーの意図 → Figma でビジュアル化（翻訳 1） → デザインスペック作成（翻訳 2） → 開発者がコードに変換（翻訳 3） → 実装結果をデザイナーがレビュー（逆翻訳） 翻訳のたびに情報が劣化する: - ピクセルのズレ - インタラクションの解釈違い - レスポンシブ挙動の不一致 - アクセシビリティの抜け漏れ AI がデザインの意図を理解し、直接コードを生成するようになれば、この翻訳プロセス自体が不要になります。@kawai_design 氏の「翻訳の元データである Figma ファイルも要りません」という指摘は、ここに根ざしています。 ...

「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由 @neurostack_0001 氏のポストが、AI にテストを書かせる際の決定的な違いを指摘し、大きな反響を呼んでいます（いいね 267、ブックマーク 222）。 3ヶ月AIにテストコード書かせてわかったこと。 「テスト書いて」と「テスト駆動で実装して」は全く別物だった。 3ヶ月間の実体験から導き出された結論は明快です。AI に「テストを書いて」と頼むのと「テスト駆動で実装して」と頼むのでは、出力されるテストの品質が根本的に異なる。本記事では、なぜこの違いが生まれるのか、その構造的な理由と実践的なワークフローを解説します。 「テスト書いて」が失敗する構造 テスト後付けバイアス ポスト主が最初に経験した失敗パターンは、多くの開発者に共通するものです。 最初はClaude Codeに「この関数のテスト書いて」と頼んでた。構文は完璧。でも実行すると半分以上落ちる。テスト対象もモックしてたり、存在しないメソッド呼んでたり。「テストっぽいもの」を量産してただけ。 この問題はテスト後付けバイアスと呼ばれる LLM の構造的な弱点に起因します。LLM が実装コードを見てからテストを生成する場合、テストは「コードが何をすべきか」ではなく「コードが何をしているか」を検証するものになりがちです。 具体的に発生する問題は以下の通りです。 問題 説明 テスト対象のモック化 テストすべき関数自体をモックしてしまい、実際のロジックを検証していない 存在しないメソッド呼び出し LLM のハルシネーションにより、実在しない API やメソッドをテストで使用する 実装への密結合 内部実装の詳細に依存するテストが生成され、リファクタリングで壊れる 網羅性の欠如 エッジケースや異常系のテストが不足し、正常系のみカバーする なぜ LLM は「テストっぽいもの」を量産するのか Codemanship の記事が、この問題の本質を指摘しています。 The more things we ask models to pay attention to, the less able they are to pay attention to any of them. LLM は「次の最も確率の高いトークン」を予測する仕組みです。既存の実装コードをコンテキストに含めてテストを生成すると、モデルは実装の構造を模倣したテストを生成します。テストとしての妥当性ではなく、「テストとして見た目がそれらしいもの」を出力するのです。 これは LLM の根本的な限界であり、プロンプトの工夫だけでは解決できません。 「テスト駆動で実装して」が品質を変える理由 テストファーストが生む構造的な違い ポスト主が発見した転機は、TDD のループを AI 自身にやらせることでした。 ...

「作れること」の価値が消える AI 時代に、SRE / プロダクション・エンジニアリングの重要性が上がる理由 integrated1453氏のポストが、すてぃお（@suthio_）氏の note 記事「『作れること』の価値が消えていくAI時代にソフトウェアエンジニアは何をやるべきか」に対して、SRE の視点からコメントし、98いいね、81ブックマーク、約12,600表示と反響を呼んでいます。 エンジニアにとって、より高度にSREをやっていくことの重要性が上がるという話だと思った。プロダクションで起こっている問題をデバッグして修正して再発防止するとか、それらを再現性高く実行できる仕組みを作るとか、SREがやる運用のエンジニアリングそのもの。まずは障害対応100本ノックしよう！笑 — integrated1453 元のすてぃお氏の投稿は552いいね、759ブックマーク、約87,900表示とさらに大きな反響です。すてぃお氏は adding Inc. 代表取締役で、元スタートアップ CTO。Claude Code の登場以降、AI 時代のエンジニア像について一貫した発信を続けています。 すてぃお氏の主張 — 「作れる」から「動かし続ける」へ 核心のテーゼ すてぃお氏の一連の記事を横断する主張は明確です。 Claude Code を使い始めてから、僕の開発方法は根本的に変わりました。以前は「この処理を実装するのに3日くらいかかるな」と見積もっていたものが、今は適切な指示を出せば30分で形になる。 実装スキル単体の市場価値が低下し、求められるのは以下の能力だという主張です。 低下する価値 上昇する価値 コードを書く能力 コードを読んで検証する能力 実装の速さ 仕様・制約の設計力 個別機能の開発 自己修復・自己改善するシステムの設計 技術力単体 技術力 × ビジネス力 すてぃお氏の提案する3つの方向性 「勝手に動き続ける仕組み」を作る: 修正する人ではなく、自己修復・自己改善するシステムの設計者になる コードは「読めるけど書けない」でいい: エンジニアの主要業務が「書く能力」から「読む能力」へ転換 事業成長にコミットする: 技術へのコミットメントよりも事業成長へのコミットメントが重要 integrated1453 氏の洞察 — これは SRE の話だ integrated1453 氏のコメントの核心は、すてぃお氏の「動かし続ける仕組みを作る」という主張を、SRE（Site Reliability Engineering）のコンテキストに接続したことです。 SRE が担う「動かし続ける」 すてぃお氏の表現 SRE の対応する実践 自己修復するシステム Self-healing infrastructure、自動ロールバック 自己改善するシステム ポストモーテムからの自動ガードレール生成 再現性高く実行できる仕組み Infrastructure as Code、ランブック自動化 プロダクションの問題をデバッグ オブザーバビリティ、分散トレーシング 再発防止 SLO/SLI 定義、エラーバジェット管理 「作れること」の価値が下がるなら、「動かし続けること」の価値が相対的に上がる。これは論理的に自然な帰結です。 ...

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン @gyakuse（逆瀬川）氏のポストが、Anthropic 公式の skill-creator を分析した記事を公開し、大きな反響を呼んでいます（いいね 330、ブックマーク 372）。 Anthropicのskill-creatorがめちゃくちゃいいスキルだったので、中身を分析して、今後どういうふうにAgent Skillを作るべきかまとめました。Orchestrator系のSkillはみんなが無意識に作りつつありますが、意識的に作ると結構便利な気がします。 引用元は逆瀬川氏のブログ記事「skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方」。Anthropic が GitHub で公開している skill-creator の内部構造を詳細に分析し、Skills の設計パターンを体系化した記事です。 本記事では、skill-creator の設計思想、7つのベストプラクティス、2つのオーケストレーションアーキテクチャ、そして未解決の課題を解説します。 skill-creator とは何か 「スキルを作るためのスキル」 skill-creator は、Claude Code の Skills を作成・テスト・改善するためのメタスキルです。Anthropic が公式リポジトリ anthropics/skills で公開しています。 4つのモードで Skills の開発ライフサイクル全体をカバーします。 モード 機能 Create インタビュー → SKILL.md ドラフト作成 → テストケース生成 Eval 並列評価（スキルあり版 vs ベースライン版を同時実行） Improve 採点・分析 → HTML ビューアでレビュー → フィードバック反映 Benchmark 統計集約 → Description 最適化 → パッケージング 4つの専門エージェント skill-creator は内部で4つのサブエージェントを使い分けています。 エージェント 役割 Executor Skills を実際に実行してテスト Grader（224行） 出力を期待値と照合して採点 Comparator（203行） スキルあり版とベースライン版を盲検比較 Analyzer（275行） 結果を分析して改善提案を生成 注目すべき数値があります。SKILL.md 本体は 480行のフロー制御ですが、サブエージェントのプロンプトは合計 700行以上。オーケストレーターよりも専門家プロンプトの方が分量が多いのです。 ...

Claude Code Agent Skills を強化する三銃士 — scripts / references / assets の使い分け @shuhei_ohno 氏が X で投稿した、Claude Code の Agent Skills を強化するディレクトリ構造の解説が注目を集めています。 Agent Skill をもっと強くする三銃士！scripts / references / assets の使い方 Claude Code の Skills 機能は SKILL.md 1 ファイルで完結するものと思われがちですが、実際には scripts / references / assets の 3 つのサポートディレクトリを活用することで、はるかに強力な自動化が可能になります。本記事では、この 3 つのディレクトリの役割と設計パターンを、公式ドキュメントの知見を交えて解説します。 Agent Skills の基本構造 SKILL.md がすべての起点 Claude Code の Skill は、.claude/skills/ ディレクトリに配置された SKILL.md ファイルを起点として動作します。 .claude/skills/ └── my-skill/ ├── SKILL.md ← エントリポイント（必須） ├── scripts/ ← 実行可能なコード ├── references/ ← 参照ドキュメント └── assets/ ← テンプレート・バイナリ SKILL.md は Markdown 形式で記述し、オプションの YAML フロントマターでメタデータを設定します。 ...

Claude Code Skills × 自己完結スクリプト — MCP/CLI の先にある「トークン効率」設計 gunta85 さんが、Claude Code の Skill において自己完結スクリプト（Self-contained Scripts）の活用を推奨するポストを投稿しています。 Skill は MCP でも CLI ツールでもなく、Self-contained Script がおすすめ。 外部ライブラリの依存を 1 ファイル内で宣言でき、MCP に比べてトークン消費を劇的に削減できる。 https://x.com/gunta85/status/1929915853508456604 この発言の背景には、mizchi さんによる「MCP はただの CLI/API ラッパーに過ぎない」という指摘もあります。MCP のツール定義だけで数万トークンを消費する問題が顕在化するなか、Agent Skills 仕様が提供する「自己完結スクリプト」は、より効率的な選択肢として注目されています。 Agent Skills とは何か Agent Skills は、AI エージェントにドメイン知識と実行能力を付与する仕様です。agentskills.io で公開されており、Claude Code をはじめとする複数のエージェントが対応しています。 ディレクトリ構成 .claude/skills/my-skill/ SKILL.md # スキルの説明と使用手順 references/ # 参考ドキュメント（必要時のみ読込） scripts/ # 自己完結スクリプト templates/ # テンプレートファイル プログレッシブ・ディスクロージャ Agent Skills の設計思想の核心は「段階的な情報開示」です。 段階 内容 トークン目安 メタデータ frontmatter（名前・説明・引数） ~100 トークン 指示文 SKILL.md 本文 <5,000 トークン リソース references/ 配下のファイル 必要時のみ MCP サーバーがツール定義だけで大量のトークンを消費するのに対し、Skills は必要な情報を段階的に読み込むため、コンテキストウィンドウを効率的に使えます。 ...

Claude Code で日常業務を「半自動化」する設計思想 — 経費精算から月末定常業務まで 岩瀬義昌氏（@iwashi86）が、minorun365 氏の Qiita 記事を引用して次のように投稿しています。 経費精算のところ、とても良いフロー — iwashi86 引用元の記事「Claude Code ですべての日常業務を爆速化しよう！」は、Claude Code をコーディングではなく日常の雑務に全面活用する実践記録です。125 いいね、97 ブックマークを集め、多くのエンジニアの共感を呼びました。 「優秀な後輩が 4 人入社した」という発想転換 minorun365 氏は Claude Code の位置づけをこう表現しています。「優秀な後輩が 4 人フルリモートで入社した」感覚で使う、と。コーディングツールとして見るのではなく、業務アシスタントとして捉え直すことで、活用範囲が一気に広がります。 重要なのは「完全自動化」ではなく「半自動化」という設計思想です。すべてを AI に丸投げするのではなく、最も手間がかかる部分だけを自動化する。人間の判断が必要な箇所は残し、定型的で退屈な作業を AI に任せるアプローチです。 経費精算フローの実例 iwashi86 氏が「とても良いフロー」と評した経費精算の自動化は、以下のように設計されています。 従来のフロー（30 分以上） MoneyForward で明細を確認 Gmail で領収書メールを検索 freee に手入力で登録 申請 Claude Code 導入後のフロー（5〜10 分） Claude Code に「今月の経費精算やって」と指示 MoneyForward の CSV を自動解析 Gmail の領収書を自動検索・照合 取引先・金額・勘定科目を自動マッピング Markdown 形式で出力（freee にコピペ） ポイントは vendor_map.json による勘定科目の自動分類です。取引先と勘定科目の対応を JSON ファイルで管理し、毎月の精算で再利用します。一度設定すれば、翌月以降は学習済みのマッピングが適用されるため、精度が上がり続けます。 1 2 3 4 5 { "Amazon.co.jp": { "account": "消耗品費", "note": "書籍・備品" }, "AWS": { "account": "通信費", "note": "クラウドインフラ" }, "スターバックス": { "account": "会議費", "note": "打ち合わせ" } } 「プチ仕様駆動開発」で雑務をエンジニアリングする minorun365 氏は、雑務にも「仕様駆動」のアプローチを導入しています。4 つのドキュメントで業務の文脈を構造化します。 ...

Claude Code の生成コードをローカル LLM でレビューする 3 つの構成パターン Claude Code は強力なコード生成能力を持ちますが、生成されたコードを別の視点でレビューしたい場面があります。クラウド API にコードを送りたくない場合や、コスト削減のためにローカル LLM を活用したい場合です。 この記事では、Ollama + Qwen3（ローカル LLM）と OpenHands（オープンソースのコーディングエージェント）を組み合わせて、Claude Code の生成コードを自動レビューする 3 つの構成パターンを紹介します。 前提となる構成 以下のツールがインストール済みであることを前提とします。 ツール 役割 インストール Claude Code コード生成（エージェント） npm install -g @anthropic-ai/claude-code Ollama ローカル LLM 実行（ランタイム） ollama.com Qwen3 レビュー用 AI モデル（LLM） ollama pull qwen3:14b OpenHands レビュー実行（エージェント）※パターン 2・3 pip install openhands-ai 構成図で示すと、Claude Code（クラウド）が書いたコードを、ローカル環境でレビューする構造です。 Claude Code（Anthropic API） ↓ コードを生成・編集 ローカルリポジトリ（あなたの PC） ↓ レビュー依頼 OpenHands / Git フック ↓ Ollama（ローカルランタイム） ↓ Qwen3（ローカル LLM）→ レビュー結果を出力 パターン 1：Git フック + Ollama 直接呼び出し（最もシンプル） OpenHands は不要です。Claude Code がコミットするタイミングで、Git の pre-commit フックが Ollama に差分を送り、Qwen3 にレビューさせます。 ...