AIコーディングツール導入でMCC乗っ取り被害 — Antigravity・Claude Codeの脆弱性とシャドーAI対策

AIコーディングツール導入でMCC乗っ取り被害 — Antigravity・Claude Codeの脆弱性とシャドーAI対策 広告運用の現場に衝撃が走っています。広告の裏側(@hassii_ad)氏のポストによると、ある代理店がAIコンサルの支援で Claude Code と Google Antigravity を導入した結果、Google Ads の MCC(マネージャークライアントセンター)アカウントが乗っ取られ、被害額は8桁後半に達したとのことです。 知り合いの代理店がとあるAI導入したらMCCが乗っ取られて桁違いの損害でてて震えた。こういうのこれから増えそうですね。 — 広告の裏側(@hassii_ad) 2026年2月17日 この事態を受けて、まな(@ADHDHSP249834)氏は「AIコンサルがClaude CodeとAntigravityの導入を進めたんですかね?その時点で大問題です」と指摘しています。 基本は3大LLMとCopilot程度に止めるべきです。またシャドーAI対策を進めていなかったことも想定されますね。セキュリティ対策をせずに、ローカルファイルにアクセスできるAIツールを導入するのはNGです! — まな(@ADHDHSP249834) MCC乗っ取りの推定原因 @hassii_ad 氏は乗っ取りの原因として4つの可能性を挙げています。 原因 概要 悪意あるWebサイト指示 プロンプトインジェクションによりAIの動作を乗っ取る 配布プロンプトへの悪意ある指示混入 AIコンサルまたは社員が使用したプロンプトに仕込まれた攻撃 MCPツールの悪用 Model Context Protocol ツールを経由した不正操作 トークン流出 自動化過程でAPIトークンや認証情報が漏洩 特に深刻なのは、MCCが正規の権限で操作された場合、通常の操作と区別がつかず「補償は絶望的」という点です。Google Ads の MCC アカウントは複数の広告アカウントを一元管理する仕組みのため、一度乗っ取られると被害が連鎖的に広がります。 Google Ads のセーフガードはなぜ機能しなかったのか Google Ads には予算制限やセキュリティ機能が存在しますが、正規権限で操作された場合にはほとんど機能しません。 既存のセーフガード一覧 機能 内容 乗っ取り時に有効か 日予算の上限 1日の費用は日予算の2倍まで 攻撃者が日予算自体を変更可能 月間費用上限 月間費用は日予算 x 30.4 まで 同上 アカウント予算 アカウント全体の費用上限を設定可能。上限到達で全広告停止 攻撃者が上限を変更・解除可能 異常な予算変更の確認 大幅な予算変更時(例: $100→$1,000)に確認ダイアログ表示 UI操作のみ。API経由なら確認なし 不審なアクティビティの検知 Google が異常を検知すると一時的な日次支出制限を適用 「正規権限」の操作は異常と判定されにくい 自動ルール 一定額到達でキャンペーンを一時停止するルール設定が可能 攻撃者がルール自体を削除可能 セーフガードが無力化される理由 今回の事件の核心は、攻撃者が MCC の正規の管理者権限を取得している点です。 ...

2026年3月2日 · 2 分

Claude Code スキルで AI ワークフローを自動化する — Ralph Loop + YAML 宣言的定義の実践

Claude Code スキルで AI ワークフローを自動化する — Ralph Loop + YAML 宣言的定義の実践 kenfdev さん(@kenfdev)が、Claude Code のスキル機能を活用した AI エージェントのワークフロー自動化について、実践的な技術記事を公開しています。 Claude Code のスキルを中心に、AIエージェントのワークフローを自動化してみた話を書きました。 bash の while ループで claude -p を繰り返す Ralph Loop と、YAML でワークフロー定義を組み合わせて、plan → implement → review → finalize を自律的に回す仕組みです。 TAKTほどの精度には及ばないのですが、それなりに自分のワークフローでは活用できています。 — kenfdev (@kenfdev) 記事の核は「Ralph Loop」と「YAML ワークフロー定義」という 2 つの技術を Claude Code スキルで統合し、plan → implement → review → finalize を自律的に回す仕組みです。 Ralph Loop とは何か 起源 Ralph Loop(正式には Ralph Wiggum Loop)は、Geoffrey Huntley が考案した AI 開発自動化パターンです。名前はシンプソンズのキャラクターに由来しますが、仕組み自体は極めてシンプルです。 基本構造 1 2 3 4 5 6 7 while true; do result=$(claude -p "プロンプト") # 完了判定 if [[ "$result" == *"COMPLETE"* ]]; then break fi done bash の while ループで claude -p(ヘッドレスモード)を繰り返し呼び出す、たったこれだけです。-p フラグは Claude Code を非対話モードで実行し、結果を標準出力に返します。 ...

2026年3月2日 · 5 分

Claude Code スキルで「穴場市場」を自動発掘 — コードを書かない AI エージェント活用術

Claude Code スキルで「穴場市場」を自動発掘 — コードを書かない AI エージェント活用術 「Claude Code はプログラミング支援ツール」——そう思い込んでいませんか? @koder_dev さんのポスト で紹介された Zenn 記事(s4kura 氏) が話題になっています。Claude Code の スキル機能 を使って「穴場市場を探させる」という、コーディングとは全く異なる使い方です。 「Claude Code にスキル自作させて穴場市場探させるって Zenn の記事めっちゃ面白かった。いや本当自分の周りも自作 skill でプログラミング作って色んな作業やらせてる、無限に応用効くからなー」— @koder_dev Claude Code スキルとは何か 基本概念 Claude Code のスキルは、SKILL.md ファイルに指示を記述することで Claude の機能を拡張する仕組みです。いわば 「プロンプトエンジニアリングのパッケージ化」 です。 スキルなし: 毎回 → 「こういう手順で」「こういう基準で」「こういう形式で」と指示 結果 → 指示漏れ、品質のばらつき スキルあり: 毎回 → /skill-name と入力するだけ 結果 → 事前定義した手順・基準・形式が自動適用 スキルの構造 スキルは SKILL.md を中心としたディレクトリです。 my-skill/ ├── SKILL.md # メイン指示(必須) ├── references/ # 判断基準・リファレンス(任意) ├── templates/ # テンプレート(任意) ├── scripts/ # 実行スクリプト(任意) └── examples/ # サンプル出力(任意) SKILL.md は YAML フロントマターとマークダウンコンテンツの 2 部構成です。 ...

2026年3月2日 · 4 分

Claude Code スキルの自動最適化 — テキスト勾配で「職人芸プロンプト」を工学に変える

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 点のスコア改善を達成。 ...

2026年3月2日 · 5 分

Claude Code ベストプラクティス — 成果を安定させる 7 つの鉄則と公式ガイドの設計思想

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 つの鉄則は、公式ガイドの膨大な内容を実務者が日常的に参照できる形に圧縮したものと位置づけられます。 ...

2026年3月2日 · 3 分

Claude Cowork 入門ガイド — プロンプトを頑張る時代の終わり、「仕組み化」で AI と働く新しいスタイル

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 はその能力を、ターミナルに馴染みのないユーザーにも開放したものと考えるのが正確です。 ...

2026年3月2日 · 3 分

NotebookLM に「40 人の天才の思考」をストックする — AI を多角的な思考パートナーに変える方法

NotebookLM に「40 人の天才の思考」をストックする — AI を多角的な思考パートナーに変える方法 「AI に自分の浅い考えしか入力できなくて、薄い回答しか返ってこない」 この問題に対する解決策が SNS で話題になっています。@ai_jitan さん が提案する手法は、孫子、アドラー、ドラッカーなど 40 人の天才の思考法を NotebookLM にストックし、AI を「多角的な思考パートナー」に変えるというものです。 @karasu_ai さん も「40 人の天才の思考をプロンプトとしてストックするって発想がすごい」と反応し、大きな反響を呼びました。 コア・アイデア:入力の質がAI出力の質を決める 問題:「自分の浅い考え」がボトルネック AI に質問するとき、多くの人は自分の知識の範囲内で入力を行います。 ユーザー: 「売上を伸ばすにはどうすればいい?」 AI: 「マーケティングを強化しましょう。SNS広告や...」 汎用的で薄い回答しか返ってきません。入力が浅ければ、出力も浅いのです。 解決策:天才の思考フレームワークを注入する 同じ質問でも、複数の偉人の思考法をコンテキストとして与えると: 孫子(戦略家): 「敵(競合)を知り己を知れば百戦危うからず。 まず市場と競合の徹底分析から始めよ」 ドラッカー(経営学者): 「顧客は何に価値を見出しているか? それを問うことが出発点」 アドラー(心理学者): 「顧客の劣等感や承認欲求に着目せよ。 人は理想の自分に近づくために消費する」 1 つの課題に対して、戦略・経営・心理という 3 つの異なる角度からアプローチが得られます。これが「多角的な視点での課題解決」の正体です。 NotebookLM を使う理由 NotebookLM の特性 Google が提供する NotebookLM は、アップロードした資料(ソース)をもとに回答を生成する AI ツールです。通常の ChatGPT や Claude との決定的な違いは: ソースに基づいた回答: 学習データ全体ではなく、アップロードした資料に基づいて回答する 引用の透明性: 回答の根拠となるソースを明示する ペルソナカスタマイズ: AI の役割や視点を詳細に設定できる(最大 10,000 文字) なぜ「ストック」が重要か ChatGPT に「孫子になりきって答えて」と毎回指示するのと、NotebookLM に孫子の著作や思考法をソースとしてアップロードしておくのでは、回答の深さが根本的に異なります。 ...

2026年3月2日 · 2 分

Prompt Request — Pull Requestの次の形:コードを書く時代から「意図を書く時代」へ

Prompt Request — Pull Request の次の形:コードを書く時代から「意図を書く時代」へ @The_AGI_WAY(ハヤシシュンスケ)氏のポストが話題です。 コードを書く時代から、意図を書く時代へ。GitHub Issue にこう書く。「[auto] ユーザー認証のエラーハンドリングを追加しろ」 引用元は @Shuns_AI 氏が X で公開した長文記事「Prompt Request — Pull Request の次の形」です。AI エージェントが GitHub Issue を読み取り、ブランチ作成から実装・テスト・PR 作成・マージまでを自律的に完了するワークフローを提案しています。92 タスクで 95% の成功率を達成したという実績とともに、「良い Issue を書く能力」こそが開発者の最重要スキルになるという主張が注目を集めました。 「Prompt Request」とは何か 「Prompt Request」は、従来の Pull Request(PR)に代わる新しい開発パラダイムを表す概念です。 項目 Pull Request Prompt Request 開発者の作業 コードを書いて PR を作成する GitHub Issue に意図を書く 実装の担い手 人間の開発者 AI エージェント レビュー 人間がコードレビュー AI がピアレビュー + 人間が最終確認 マージ 人間が判断してマージ 条件を満たせば自動マージ 所要時間 数時間〜数日 5〜15 分 PR がコードの差分を中心とした「成果物の提出」であるのに対し、Prompt Request は「意図の伝達」が起点になります。開発者が書くのはコードではなく、何をしたいかという自然言語の指示です。 ワークフローの全体像 記事で提案されているワークフローは次のとおりです。 ...

2026年3月2日 · 4 分

Claude Code が汎用AIエージェント基盤へ進化 — Auto Memory・Remote Control・Scheduled Tasks の全貌

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の学習知見を蓄積します。 ...

2026年3月1日 · 2 分

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

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 フィールド、入出力スキーマが全て含まれます。 ...

2026年3月1日 · 4 分