📢 アップデート版を公開しました（2026/05/01） この記事のあと、3スキル体制に分割 + テストハーネスで検出率100%を達成 しました。最新の使い方は以下の記事をどうぞ。 👉 claude-security-scanを3スキル体制にアップデートしたら月$1未満で検出率100%を達成した話🎯 はじめに こんにちは、Sabakanです。 今回、Claude Code 用のセキュリティ診断スキル claude-security-scan を作って公開しました。 正直、自分でもびっくりするくらい実用的なものができたので、紹介させてください。 リポジトリはこちら → https://github.com/sabakan0123/claude-security-scan こんな気持ち、ありませんか？ 「セキュリティ診断、ちゃんとやりたいけど Burp Suite の使い方よくわからん」

こんにちは！株式会社エーアイセキュリティラボのはるぷと申します。 一般ユーザーがコマンド一発でrootを取れてしまうLinuxカーネルの脆弱性、CopyFail (CVE-2026-31431) が話題になっています。AIによって発見された論理バグで、汚しても問題ないEC2環境を作って実際に検証してみました。 この脆弱性は、 一般ユーザーがroot権限に昇格できる というものです。実行条件がとても簡単なので話題になりました。ざっくり仕組みを言うと、algif_aead・authencesn・splice() システムコールの組み合わせによって、メモリ上のページキャッシュを直接書き換えられてしまう、というものです。 脆弱性の発生原理は元記事の解説に任せ、ここではPoCで何が起きているのか中心に解説します。 TL;DR PoC を動かすと、一般ユーザーから1コマンドで root が取れる ディ

Claude Code Skills を使って投資分析システムを構築・進化させてきたシリーズです。自然言語で話しかけるだけで、銘柄探索・分析・ポートフォリオ管理・リスク評価が自動実行されます。 シリーズの流れ スクリプトによる 自動化 から始まり、GraphRAG による 学習、高度な分析機能の追加を経て、6つの AI エージェントが自律的に連鎖する マルチエージェントオーケストレーション に到達。さらに Vol.5 では 4つの異なるAIが結論を反証し考え直す DeepThink を実装しました。 記事一覧 Vol.1: 株スクリーニングを自動化した話 テーマ: スクリプトで 自動化 Python × yfinance × Claude Code Skills で、株式スクリーニングからポートフォリオ管理まで投資分析を自動化。4つのスクリーナーエンジンとヘルスチェック機能を実装。 Vol

りゅーいち @doragon10822 決済業界に25年いて、いくつもの詐欺手法を見てきましたが、最近のフィッシング詐欺は「注意してても引っかかる」レベルまで進化しています。「怪しいメールは開くな」なんてアドバイスはもう古い。絶対に覚えてほしい誰もが一瞬ヒヤッとする「フィッシング詐欺の手口」５選をリプ欄で紹介します⤵︎ 2026-04-28 06:50:00 りゅーいち @doragon10822 ① QRコード詐欺（クイッシング） これ、今一番怖いです。 街中のポスターや駐車場の精算機、 あるいはメールに添付された「QRコード」 「スマホで読み取って決済」という慣れを 利用し、偽サイトに飛ばします。 メールのフィルターは「文章」をチェック しますが、画像であるQRコードは すり抜けてくる。 「QRコード＝安全」という思い込み、 今すぐ捨ててください。 読み取った先のアドレス確認は必須です

もぎ @mogi_invest 退去の立ち会いで管理会社に「クリーニング代5万＋壁紙張替え8万＋鍵交換2万で合計15万円です」と言われた友人が「払いません」と答えたら「は？契約書に書いてありますよ？」と怒られたので、『国交省のガイドライン知ってますか？』と言った途端に起きたことを見て↓↓↓ 2026-04-12 06:10:01 もぎ @mogi_invest 管理会社「15万円です。サインお願いします」 友人「すみません、内訳を1つずつ確認させてください」 管理会社「はぁ…（面倒くさそうに）」 友人「まず壁紙の張替え8万円。何年住んだかご存知ですよね？」 管理会社「…7年ですね」 友人「壁紙の耐用年数は6年。国交省のガイドラインでは、6年で残存価値は1円です。つまり"張り替える理由があっても"入居者の負担は1円ということですよね？」 管理会社「…………」 2026-04-12 06:10

1週間の気になる生成AI技術・研究をいくつかピックアップして解説する連載「生成AIウィークリー」から、特に興味深いAI技術や研究にスポットライトを当てる生成AIクローズアップ。 今回は、Webブラウザだけで日本語OCR（光学文字認識）が完結するツール「NDLOCR-Lite Web AI」（MITライセンス）を取り上げます。 国立国会図書館が開発したOCRエンジン「NDLOCR-Lite」をベースに、橋本雄太氏（国立歴史民俗博物館）がWeb移植した「ndlocrlite-web」を、小形克宏氏（一般社団法人ビブリオスタイル）がフォークしてAI校正機能を追加しました。宮川創氏（筑波大学）によるダークモードや画像前処理などのUI拡張も統合されています。 ▲NDLOCR-Lite Web AIの画面。左パネルに元画像（芥川龍之介『蜘蛛の糸』）、右パネルにOCR結果が表示されている

はじめに 2026年3月31日、npmパッケージ「axios」が乗っ取られました。 axiosはJavaScriptで最も使われるHTTPクライアントです。 週間ダウンロード数は1億回を超えます。 私自身、ほぼすべてのNode.jsプロジェクトで使っています。 事件を知ったとき、まず自分のプロジェクトを確認しました。 package-lock.jsonを開き、axiosのバージョンを探しました。 幸い影響を受けるバージョンではありませんでした。 しかし「もし週末にデプロイしていたら」と思うとぞっとしました。 この記事では事件の全容と技術的な仕組みを解説します。 そして「自分のプロジェクトは大丈夫か」を確認する手順を示します。 事件の時系列 攻撃は周到に準備されていました。 以下がUTC（日本時間に変換するには+9時間）での時系列です。 時刻 (UTC) 出来事

Anthropic Claude Codeのnpmパッケージにソースマップが含まれ、1,902ファイル・51万行超のTypeScriptソースが公開状態に。未公開プロジェクト「KAIROS」や107個のフィーチャーフラグなど、内部コードの全貌を解説する。 Anthropicが「うっかり」自社ツールの中身を全公開した Anthropicが提供するAIコーディングツール「Claude Code」の中身が丸見えになった。 ハッキングされたわけではない。Anthropicが自分でnpm（JavaScriptのパッケージ管理システム）にコードを公開するとき、「ソースマップ」という本来含めてはいけないファイルを一緒に入れてしまった。いわば設計図を製品と一緒に箱に入れて出荷してしまったようなものだ。 発見したのはセキュリティ研究者のChaofan Shou氏。対象は @anthropic-ai/clau

2026年3月31日、HTTP クライアントライブラリ axios の npm パッケージが侵害されました。攻撃者はメンテナの npm アカウントを乗っ取り、マルウェアを含むバージョン 1.14.1 および 0.30.4 を公開しました。axios は npm エコシステムで週間約1億ダウンロードを誇る主要パッケージです。本記事では公開情報をもとに、事象の概要を記録します。また、対応指針を示します。 TL;DR - 対応指針 axios への直接依存に限らず、間接依存（transitive dependency）でも postinstall フックは発火します。 自身のプロジェクトが axios を直接利用していなくても、依存ツリーのどこかに axios が含まれていれば影響を受け得ます。npm ls axios で確認してください。 npm ls axios や lockfile により

はじめに LLMの推論コストを支配する要因のひとつが KVキャッシュ（Key-Value Cache） のメモリ消費である。コンテキスト長が伸びるほどKVキャッシュは線形に膨張し、GPUメモリを圧迫してバッチサイズやスループットを制限する。 2026年3月25日、Google Researchは新しい圧縮アルゴリズム TurboQuant を公式ブログで発表した。KVキャッシュを 3ビットに圧縮しながら精度損失ゼロ を実現し、メモリ使用量を 6倍削減 、NVIDIA H100上で注意機構の計算を 最大8倍高速化 する。論文は ICLR 2026 で発表される。 この記事では、TurboQuantの技術的な仕組みからベンチマーク結果、コミュニティ実装を使った導入方法までを解説する。 この記事で学べること KVキャッシュがLLM推論のボトルネックになる理由 TurboQuantの2段階圧縮アル

はじめに こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。 2026 年 3 月 24 日、Google Research が TurboQuant を発表しました（ICLR 2026）。LLM の推論中に蓄積される KV キャッシュ（過去のトークン情報を保持するメモリ領域）を 3 ビットに圧縮して、そのメモリ使用量を最大 6 分の 1 に削減する手法です。モデル本体の VRAM が減るわけではなく、あくまで推論時のキャッシュ部分に効く技術ですが、キャリブレーション不要、ファインチューニング不要、どんな Transformer にも後付けできるという点が目を引きます。 LLM の推論では、コンテキストが長くなるほど KV キャッシュがメモリを圧迫します。大きなモデルを載せているとなおさらで、KV キャッシュに使える余裕が限られるのは多くの環境に共通する悩みです。ここを 6

Anthropicは2026年3月19日のQCon Londonで、ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告しました。「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており、SREの完全代替には至らないと自社が認めた形です。AIにエラーログやアラートを読ませて原因を特定しようとしたことがある方には、直接関係する話です。 何を試みて、何が分かったか AnthropicはClaudeを使ってClaudeのインフラ障害を修復する、いわば「AIがAIを管理する」構成を試みていました。ログやメトリクスを読ませ、警告アラートの原因を特定させ、修復アクションを実行させるという流れです。 結果として明らかになった問題は、警告の表面パターンは認識できるが、障害の根本原因を特定できないという点でした。たとえば「メモリ使用量が急増した後にレスポンスタイムが

1. はじめに 実務では、画面設計書が Excel や PowerPoint、Word で管理されていることが多いです。 それ自体は珍しくありませんし、提出物としては都合が良い場面もあります。 ただ、開発の現場で実際に使う設計資料として見ると、つらいことが多いです。 どこが変わったのか差分が追いづらい レビューで変更点に集中しづらい 実装と設計書の同期が崩れやすい コピー運用で古い記述が残る 画面ごとに表現がばらつきやすい その結果、画面設計書が「あるけど信用されない文書」になってしまうことがあります。 自分は最近、画面設計書をもっとドキュメントベース、できれば Markdown ベースで書く文化を浸透させたいと考えています。 今回はその理由を整理してみます。 2. なぜ今の画面設計書運用がつらいのか 画面設計書は、多くの現場で Excel / Word / PowerPoint などの

本稿は、お客様から「貴社ドメインからSPF/DKIM認証が失敗しているメールがある」とご連絡をいただき、原因調査を行った際の知見を共有致します。 メールの仕組みって奥が深い。 内村でございます。 （知らないことを知れるのは楽しいですね） お客様がDMARC（Domain-based Message Authentication, Reporting and Conformance）のポリシー強化を進められる中で、弊社ドメインに関連するSPF/DKIM認証失敗の報告を受けました。 結論として、原因は「弊社内でのメール転送」でした。なりすましでもシステムの不具合でもありません。 しかし、この結論に辿り着くまでの調査プロセスと、そこで得た知見は、同じような問い合わせを受けた方のお役に立つかと思い、記事にまとめました。 内容についての諸注意 お客様からのお問い合わせ内容 DMARCとは（おさらい）

Claude Codeに実装させた後、毎回自分でコードレビューして突っ込みを入れるのが大変だった。そこで、実装後に自動でセルフレビューと修正をする仕組みを作ったので紹介する。 課題: Claude Codeで出力されたコードの品質が自分の基準を満たさない Claude Codeで一気に実装ができるようになった反面、出力されたコードの品質が自分の基準を満たさないことが多かった。そのため、変更のたびに毎回ツッコミを入れていて、かなりの手間がかかっていた。プランモードで事前にちゃんと設計したとしても、コードレベルでは満足いかないことが多かった。 じゃあサブエージェントやCodex CLIで先にレビューして直し切ってもらってから確認すれば良いのでは？と思ってやってみた。しかし、AIのレビュー指摘には的外れなものや過剰なものも混じるため、全部対応させるとかえってコードが散らかってしまうこともあった。

はじめに 業務自動化Pythonエンジニア。バイブコーディング歴1年 ≒ エンジニア歴。 数百ファイル規模の社内ナレッジを検索して回答する Slack チャットボットを作った。200ページ超の Google Sites を、RAG パイプラインなしで検索・回答できる。 これは RAG ではない。Retrieval パイプライン（Embedding、ベクトル DB、リランキング）は存在しない。LLM が Grep と Read で直接ファイルを検索・読み込み・統合して回答する。エージェンティックサーチとでも呼ぶべきアプローチで、RAG パイプラインを丸ごと捨てた実装レポート。 前提条件: この方式が有効なのは数百ファイル規模のナレッジ。数千〜数万ドキュメントには従来 RAG の方が適している。 1つ目の営業ナレッジ Bot（211ページ、9カテゴリ）は 約3時間 で完成した。スクレイピングか

はじめに 以前、Claude Codeスキルで実現する仕様駆動開発という記事で、AIの暴走を防ぎつつ一貫性のある開発を実現する手法を紹介しました。 今回、この手法を既存プロダクトに導入するためのスターターキットを公開しました。 仕様駆動開発の基本思想 このスターターキットが前提とする役割分担は以下の通りです。 人間の役割: 仕様の決定、レビュー、テストによる品質担保 AIの役割: 仕様に基づくコードの実装、ドキュメントの生成・更新 人間がコードを直接書くのではなく、仕様（ドキュメント）を通じてAIに意図を正確に伝え、その出力をテストで検証するのが基本の開発サイクルです。 テストでバグを見つけた場合も、人間が直接コードを修正するのではなく、AIに修正を指示します。バグの原因が仕様にあればドキュメントの修正から、コードにあればバグ内容を伝えてAIに修正させます。 スターターキットの内容 2つの

Google Stitch、話題になってますよね。 ただ、デザイナーじゃない自分からすると 「すごそうだけど、結局なにができるの？」 がよくわからなかった。触ってみたいけど、何から手をつければいいかもわからない。 同じように感じている人、けっこういるんじゃないかと思います。 なので、非デザイナーの私が実際に触りながら「こういうやれば、だいたいわかる」というハンズオンマニュアルを作りました。 あくまで"だいたい"です！！ この記事の通りに手を動かしてもらえれば、Google Stitch がどんなものか、なんとなーく掴めると思います。よければ使ってください。 そもそも Google Stitch って何が話題なの？Google Stitch のすごいところは、簡単にいうと3つだと私は思っています。 AIネイティブなデザインキャンバス: テキストや音声で指示するだけで、無限キャンバス上にUIデ