<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ブログ on BlueSquadron — AI システムのためのセキュリティエンジニアリング</title><link>https://bluesquadron.dev/ja/posts/</link><description>Recent content in ブログ on BlueSquadron — AI システムのためのセキュリティエンジニアリング</description><generator>Hugo -- gohugo.io</generator><language>ja-jp</language><managingEditor>florent.batard@gmail.com (Florent Batard)</managingEditor><webMaster>florent.batard@gmail.com (Florent Batard)</webMaster><lastBuildDate>Mon, 31 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://bluesquadron.dev/ja/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>AI-DLC を安全にする — プロセスの健全性は、プロダクトのセキュリティではない</title><link>https://bluesquadron.dev/ja/posts/securing-the-ai-driven-development-lifecycle/</link><pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/securing-the-ai-driven-development-lifecycle/</guid><description>AI-DLC は、私が見てきたどの方法論よりも強いプロセスの健全性を与えてくれます。承認ゲート、監査証跡、要素レベルのトレーサビリティ。しかしそのどれも、コードが安全であることを示しません。別の主張であり、その隙間をフェーズごとに埋めるのが仕事です。</description></item><item><title>AI エージェントのためのセキュリティコーチ</title><link>https://bluesquadron.dev/ja/posts/security-coach-for-ai-agents/</link><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/security-coach-for-ai-agents/</guid><description>「モデルを信頼できるか」を議論しているチームは、すでに重要な決定を済ませています — 境界をどこに置くか、です。プロンプトは約束、ツールインターフェースは制約。両者を見分けるための 4 つのパターン。</description></item><item><title>Sitadel — ディストリビューションが自分のツールを収録した後に負うもの</title><link>https://bluesquadron.dev/ja/posts/sitadel-what-you-owe-your-users/</link><pubDate>Tue, 18 Aug 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/sitadel-what-you-owe-your-users/</guid><description>8 年、179 コミット、そして Kali と BlackArch に収録 — 計画したことではなく、そして「壊してよいもの」の範囲を変えた出来事。検知カバレッジより指摘の品質、実際の端末でしか起きなかったハング、そして誰も頼んでこない片付けについて。</description></item><item><title>Watari — 一度も有効になっていなかったセキュリティ統制</title><link>https://bluesquadron.dev/ja/posts/watari-a-control-that-was-never-on/</link><pubDate>Tue, 11 Aug 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/watari-a-control-that-was-never-on/</guid><description>Watari の看板は PostgreSQL Row-Level Security によるテナント分離です。そのポリシーは数か月前からスキーマに存在し、一度も効いていませんでした。有効にするには同時に着地させる必要のある 4 つの変更が必要で、そのどれもポリシーを書くことではありませんでした。</description></item><item><title>Secrust — コアを増やしたら遅くなった話</title><link>https://bluesquadron.dev/ja/posts/secrust-when-adding-cores-made-it-slower/</link><pubDate>Tue, 04 Aug 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/secrust-when-adding-cores-made-it-slower/</guid><description>単一プロセスで動く Rust の Sigma 相関エンジン。8 回の最適化で現実的なワークロードは 301% 速くなり、その後スレッドを 4 にしたら 2 より 23% 遅くなりました。なぜそうなったのか、既定値に何を選んだのか、そして作らないと決めたもの。</description></item><item><title>ノイズを 90% 削る — エージェント駆動のセキュリティオペレーション</title><link>https://bluesquadron.dev/ja/posts/agent-driven-security-operations/</link><pubDate>Wed, 08 Jul 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/agent-driven-security-operations/</guid><description>量が人員に収まるまで検知をチューニングするのは、可視性を人員数で決めることです。答えはアナリストの増員ではなく、トリアージの 3 層を「何について誤ってよいか」で分けることでした。</description></item><item><title>40 時間から 8 時間へ — AI 開発ライフサイクルにセキュリティを設計として組み込む</title><link>https://bluesquadron.dev/ja/posts/designing-security-into-the-ai-development-lifecycle/</link><pubDate>Tue, 16 Jun 2026 00:00:00 +0000</pubDate><author>florent.batard@gmail.com (Florent Batard)</author><guid>https://bluesquadron.dev/ja/posts/designing-security-into-the-ai-development-lifecycle/</guid><description>先送りした判断のすべてがオプションではありません。行使価格がカレンダーとともに上がるものは負債です。そしてセキュリティは、予算の大半をその負債の利払いに使っています。</description></item></channel></rss>