DISPATCH №0730 / 2026-07-30 / MORNING EDITION / 07 ITEMS / BUILD 20260730.0752 / LIVE / CURATED BY 泉水亮介
VCB News & Post Headline
JST · 07:52 · WED
MORNING DISPATCH · WEDNESDAY · JULY 30, 2026

2026.07.30

Claude · OpenAI · 〈実測〉Claude · 〈知見〉モデル別 07 ITEMS · READ 7 min
📰 セキュリティ / AI研究 / ANTHROPIC RESEARCH / NEWS

Claude Mythos が暗号アルゴリズムの新しい弱点を発見 — 耐量子署名 HAWK の実効鍵長を60時間で半減

Claude Mythos が暗号アルゴリズムの新しい弱点を発見 — 耐量子署名 HAWK の実効鍵長を60時間で半減

Anthropic が 2026-07-28、非公開モデル Claude Mythos Preview を使った暗号研究で2件の新しい攻撃を発見したと公表した。1件は NIST 評価中の耐量子署名候補 HAWK に対するもので、格子に潜む自明でない自己同型を突いて HAWK-256 の完全鍵復元コストを 2^64 → 2^38 に落とし、実効鍵長を半減させた。もう1件は7ラウンドに削減した AES-128 に対する「Möbius Bridge」で、既知最良の中間一致攻撃より 200〜800倍速い。いずれも実運用システムには影響せず、変更が必要な製品ソフトウェアは無いと Anthropic 自身が明記している。

キーポイント

  • HAWK-256 の完全鍵復元の期待コストが 2^64 → 2^38 に低下(実効鍵長が半減)。より大きな HAWK 鍵は依然として攻撃非現実的
  • HAWK は2年間・2ラウンドの専門家レビューを通過していたスキームで、その間この対称性は見つかっていなかった。Mythos は約60時間・API コスト約10万ドルで到達し、人間の入力は「プロジェクト管理」程度に限られた
  • AES 側は 7/10 ラウンドの AES-128 が対象。「Möbius Bridge」=より洗練されたフィンガープリンティングで列挙要件を 256倍削減し、既知最良の中間一致攻撃比で 200〜800倍高速
  • AES の結果はほぼ完全に自律的な発見。研究者が用意したのは足場と3日間で3回の実質的なプロンプトだけで、Claude は数十億トークンを生成した
  • 実世界への影響は無い。HAWK は候補段階で未配備、AES 攻撃は削減版のみで完全な AES は安全(実装には数億ドル規模のコストがかかる)。どちらも多項式時間ではなく指数時間の攻撃にとどまる
  • 検証が律速だった。AES の結果は2人の研究者が正しさに確信を持つまでほぼ1か月を要し、研究者はモデルの主張を検証できるだけの暗号研究を学ぶのに数百時間を費やした
  • 責任ある開示手順を踏み、学術者に相談のうえ米政府・業界パートナーへ事前共有。HAWK は結果公開と同時に NIST の公開メーリングリストへ調整開示された
「AI が新しい数学的知見を出せるか」という議論が、査読を2度通ったスキームの穴を実際に見つけるという形で一段進んだ。ただし持ち帰るべきはむしろ非対称のほうで、モデルはほぼ自律で60時間走ったのに人間側の検証には1か月と数百時間かかっている — 生成が速くなるほど検証がボトルネックになるという構図は、そのまま自分のループ設計に返ってくる。
📰 技術業界ニュース / 🔧 セキュリティ / OPENAI (@OPENAI) / BOOKMARK

OpenAI が Codex Security CLI をオープンソース公開 — 実行をまたいで検出結果を追跡し、修正まで検証する

OpenAI が Codex Security CLI をオープンソース公開 — 実行をまたいで検出結果を追跡し、修正まで検証する

OpenAI が Codex Security CLI をオープンソースとして公開した。リポジトリのスキャン、実行をまたいだ検出結果の追跡、修正の検証、CI/CD へのセキュリティチェックの追加ができる CLI で、`npm install @OpenAI/codex-security` または `npx @OpenAI/codex-security@latest --help` で使える。告知前に Hacker News に見つけられたことを OpenAI 自身がポストの書き出しに使っており、early release だと明言してフィードバックを募っている。

キーポイント

  • できることは4つ — リポジトリのスキャン / 実行をまたいだ検出結果の追跡(track findings across runs)/ 修正の検証(verify fixes)/ CI/CD へのセキュリティチェックの追加
  • 導入は `npm install @OpenAI/codex-security`、まず試すなら `npx @OpenAI/codex-security@latest --help`。ソースとドキュメントも公開されている
  • 本命は「毎回全件報告」からの脱却。一般的な静的解析は毎回ゼロから全件を出すので既知の未対応項目とノイズが毎回同量出てきて、結果として誰も見なくなる
  • 実行間で findings を追跡できれば「前回から増えた分だけ」を見られるので CI に入れても運用が破綻しない。修正の検証がセットなのは「直したつもり」を潰すため
  • OpenAI 自身が early release と明記しており、対象言語・ルール数・既存ツール(Semgrep 等)との比較データは公開されていない
  • 守備範囲はコード内容のスキャン。後述の「4段防衛線」でいう4段目にあたるので、入れることは「守った」ではなく「コードの中身も一応見る」を足すことになる
Codex を日常的に使っているなら `npx` で1回走らせるコストは低く、出力を見てから CI 組み込みを判断できる。ただし同じ週に「4段目だけ入れても上流が開いていれば意味が薄い」という実測が出ているので、これ1本で守った気にならない使い方が前提になる。
🔧 インフラ・セキュリティ / 💻 AI開発ツール / TATSUKI | CLAUDE CODE活用支援 (@NOBEL_824) / BOOKMARK

〈実測〉Claude Code のセキュリティは4段ある — 公式プラグインだけ入れても出番が来ない

〈実測〉Claude Code のセキュリティは4段ある — 公式プラグインだけ入れても出番が来ない

公式セキュリティプラグイン `security-guidance` を2ヶ月動かして動作ログ 17,385 行を全解析したところ、25本ある検知ルールのうち実際に発火したのは1本だけで、しかもその1本は唯一コード内容を検査しないルールだった。ただし著者の結論は「プラグインが悪い」ではなく「入れる順番が逆」。Claude Code のセキュリティは公式ドキュメント上で4段(サンドボックス→権限ルール→スキャン→プラグイン)に整理されており、プラグインは最下流の4段目なので、上流を置かないとそもそも出番が来ない。

キーポイント

  • ログ実測の内訳 — ターン終了時レビュー起動 416回 / レビュー対象なしの空振り 322回(77%)/ LLM レビューまで走った 38回(全体の9%)/ そのレビューの指摘 0件 / 鳴ったルール種類は 25種中1種
  • 唯一鳴った `github_actions_workflow` は 25本中で唯一コード内容を見ないルール。`.github/workflows/` 下の yml を触った事実だけで発火する(危険なコードを書いたからではなくファイルを開いたから鳴った)
  • サンドボックスは初期状態で無効。`/sandbox` → Mode タブで auto-allow を選ぶ。macOS は標準搭載の Seatbelt を使うので追加インストール不要、Linux/WSL2 は `bubblewrap` と `socat`、Windows は WSL2 内で動かす
  • 穴1 — 公式ドキュメントに「There is no built-in credential deny list, so only the files and variables you list are restricted.」と明記されている。実測では `~/.ssh` はブロックされたが `~/.config/gh/hosts.yml`(GitHub CLI が平文でトークンを置くファイル)は読めたまま
  • 穴2 — 公式は「新規ドメインは初回に許可を求める」と書くが、auto-allow では5ドメインすべてに到達し一度も許可を聞かれなかった。つまり書き換えは止まるが持ち出しは止まらない
  • サンドボックスが囲うのは Bash とその子プロセスだけで、`Read`/`Edit`/`Write` は権限ルール側が効くため両方書く必要がある。また `network.strictAllowlist` はユーザー設定・管理者設定・CLI `--settings` からしか効かず、リポジトリの `.claude/settings.json` に書いても無視される
  • 公式25ルールの守備範囲は JS/TS・Python・Go のみ(PHP・Ruby・Java・Rails は0本)。正規表現層にハードコード認証情報検知も SQL インジェクション検知も入っておらず、レビュー対象は Claude が自分でコミットしたときだけ
「一番目立つ・一番新しい・一番宣伝されている対策が、実は最下流だった」という構造の具体例で、個人・小規模なら1段目と2段目を置くだけで守りの大半が完成する。組み込みの拒否リストが無いという仕様は誰の環境にも当てはまるので、`~/.config/gh` や API キーを入れた `.env` は自分で書かない限り読めたままになる。
🧠 コンテキストエンジニアリング / 💻 AI開発ツール / やぎ(八木 利生太郎)/ LAST SCENE代表 (@YAGIRYUUU) / BOOKMARK

〈知見〉モデル別 Anthropic 公式プロンプトガイドの差分 — まずやるべきは指示の追加ではなく削除

〈知見〉モデル別 Anthropic 公式プロンプトガイドの差分 — まずやるべきは指示の追加ではなく削除

Anthropic がモデルごとに出している公式プロンプトガイド(Fable 5 / Sonnet 5 / Opus 5)を全部読み込み、共通ルールとモデル別の差分に整理した記事。核心は進化方向の定式化で、旧世代は「放っておくと変なことをするから禁止と手順で縛る」、現世代は「勝手に検証し勝手に気を利かせるからスコープと判断基準だけ渡して任せる」。だから旧世代向けの「必ず検証して」「徹底的にやって」は現世代では過剰トリガーになり、まずやるべきは指示の追加ではなく削除だと結論している。

キーポイント

  • 公式ガイド自身が「CRITICAL: You MUST〜みたいな強い言葉は普通のトーンに戻せ」と書いている
  • 資料が先、指示は最後。2万トークンを超える長文では質問を末尾に置くだけで回答品質が最大30%向上したテスト結果がガイドに載っている。「回答の前にまず関連箇所を引用させる」を足すと長文で迷子にならない
  • Opus 5 — 「ダブルチェックして」は逆効果(言われなくても検証するので二重に走る)。回答が長いのは effort では直らない(effort は思考量で出力量ではない)。サブエージェントは「数手で終わる仕事は振るな」「1体で済むなら1体」。コンテキストは100万トークンが標準で、effort は low/medium でもバグ発見の精度が維持される
  • Sonnet 5 — 罠は「指示を守りすぎる」。「重大な問題だけ報告して」と書くと同じ深さで調べてバグを見つけた上で基準未満と判断して黙るので、公式推奨は「全部報告させ、信頼度と重大度を添えさせ、絞り込みは別工程」
  • Sonnet 5 の移行トラップ — `temperature` が使えなくなった(設定するとエラー)、トークナイザー変更で同テキストが約30%増、effort は medium が旧 4.6 の high 相当
  • Fable 5 — 「報告する前に各主張を今セッションのツール実行結果と突き合わせろ。未検証なら未検証と言え」で、捏造を誘発するように設計されたテストですら虚偽報告がほぼゼロになった。メモリの運用ルールもガイドに載っている(「1ファイル1教訓、重複は更新、間違いは削除」)
  • 見直しの優先順は ①「ダブルチェックして」を消す ②「重大なものだけ報告」を「全部報告→後で絞る」に ③長さは effort ではなく言葉で ④資料が先・指示が後 ⑤MUST/CRITICAL を普通のトーンに。著者は「1と4だけでもコストと精度が目に見えて変わる」としている
自分の `CLAUDE.md` / `AGENTS.md` / `SKILL.md` をそのまま健康診断できる。ただし全部消すのが正解ではなく、過去に実際に事故が起きて書かれた行と念のため書いた行を分けるのが本筋。「発見と選別を分ける」(全部出させてから別工程で絞る)はレビュー系スキルの設計に直接効く。
📖 AI研究 / コンテキストエンジニアリング / ARXIV 2607.23809(META / CMU) / NEWS

ACM: Agentic Context Management — 「いつ圧縮するか」をエージェント自身に決めさせる(Meta / CMU)

ACM: Agentic Context Management — 「いつ圧縮するか」をエージェント自身に決めさせる(Meta / CMU)

Meta と CMU の研究者による、長期タスク向けのコンテキスト管理フレームワーク ACM の論文(arXiv 2607.23809、2026-07-26 投稿)。本番のエージェントは1ターンごとにコンテキストを積み上げるが、既存の圧縮手法は「トークン数がしきい値に達したら圧縮して残りを捨てる」という硬直的なルールで発火するため、いま取り組んでいる作業と無関係な理由で発火してしまう。ACM はエージェントに専用のコンテキスト編集ツールを渡し、いつ圧縮するかをエージェント自身に決めさせ、捨てる内容は外部メモリへ退避して必要になったときに問い合わせる。

キーポイント

  • 論文タイトルは「ACM: Agentic Context Management for Long Horizon Tasks」、arXiv 2607.23809、投稿は 2026-07-26
  • 著者は Xiaochuan Li / Ryan Ming / Meng Chu / Shuai Shao / Rong Jin / Chenyan Xiong(Meta・CMU)
  • 問題設定は「既存の圧縮手法は必然的に情報損失を伴い、硬直的なヒューリスティックルールで発火する」こと。しきい値方式はタスクの区切りと無関係なところで記憶を切る
  • 仕組みは3点 — 専用のコンテキスト編集ツールでロスレスな管理を行う / エージェントが自律的に圧縮タイミングを決める / 捨てた内容を外部メモリへ退避し必要時に取り出す(人間の記憶とのやり取りに着想)
  • 効果的なコンテキスト管理の実演をもとにしたポストトレーニングのパイプラインも構築している
  • 分析で示されたのは、ピーク時のトークン圧力が下がること・より長い探索が可能になること・独立した試行間でより一貫した解が出ること
  • 査読前のプレプリントで、abstract には定量的なベンチマーク数値が示されていない(効果は定性的な記述にとどまる)
「コンテキストが溢れたら圧縮」を自動でやっているエージェント運用にそのまま効く指摘。しきい値方式はタスクの区切りと無関係なところで記憶が切れるので、長い作業の途中で話が繋がらなくなる原因になる。圧縮タイミングをエージェント自身に持たせ、捨てたものは外部に置いて引ける状態にするという設計は、`/compact` やメモリファイルの運用を見直すときの下敷きになる。
📖 開発ツール / エコシステム / SKILLS.SH(VERCEL) / NEWS

〈知見〉skills.sh — Agent Skills のオープンなエコシステム、1コマンドでエージェントに能力を足す

〈知見〉skills.sh — Agent Skills のオープンなエコシステム、1コマンドでエージェントに能力を足す

Vercel が運営する Agent Skills のディレクトリ。やりたいことを検索して `npx skills add <owner>/<repo>` の1コマンドでエージェントに能力を追加できる。Anthropic・Microsoft・Supabase・Firebase といった各社の公式スキルと、独立開発者のスキルが同じ場所に並び、リーダーボードの累計インストール数は 1,026,775 件に達している。対応クライアントは20以上で、Claude Code で入れたスキルの資産が Cursor や Codex 側でも効く。

キーポイント

  • 運営は Vercel(サイトのフッターに「Made with care by Vercel」)。スキル自体は GitHub 上でオープンソース
  • リーダーボードの累計インストール数は 1,026,775 件
  • 主な公開元は Vercel Labs / Anthropic / Microsoft(Azure 系)/ Matt Pocock / LarkSuite・Feishu / Supabase / Firebase / HeyGen
  • 導入コマンドは `npx skills add <owner>/<repo>` の1行
  • 対応クライアントは20以上(Claude Code / Cursor / GitHub Copilot / Windsurf / Gemini / Cline / VS Code / Zed ほか)
  • 特定のスキルは URL で直接指せる(例: skills.sh/anthropics/skills/skill-creator、skills.sh/mattpocock/skills/grill-me)
  • 導入は外部リポジトリのコードを取り込む行為なので、入れる前に SKILL.md を読むのが前提になる
「必要な能力が無いとき、自分で書く前にまず探す」を安く実行できる場所。スキルを1本自作する前に既存のものを1コマンドで入れて動かし、中の SKILL.md を読んで書き方を学ぶという導入経路が使える。複数クライアントに対応しているので、入れたスキルの資産がツールを乗り換えても効くのも選定理由になる。
🎨 デザイン・UI/UX / 💼 マーケティング / アプリマーケティング研究所 (@APPMARKELABO) / BOOKMARK

〈知見〉お問い合わせページに実績ロゴを置いたら CVR が12%改善 — 効くのは集客ではなく最終段の離脱防止

〈知見〉お問い合わせページに実績ロゴを置いたら CVR が12%改善 — 効くのは集客ではなく最終段の離脱防止

お問い合わせページ(=コンバージョン直前のページ)に導入企業の実績ロゴを追加しただけで、コンバージョン率が 12% 改善したという取材事例。効いた理由の仮説は「お問い合わせまであと一歩の人たちの不安の緩和」で、集客の改善ではなく離脱の防止として働いている。投稿者は一般化して「コンバージョン直前のページに信頼性を高めるような情報を置くだけでも、お問い合わせや申し込みの数が増える可能性がある」としている。

キーポイント

  • 変更内容は「お問い合わせページに実績ロゴを追加」の1点のみで、結果はコンバージョン率 +12%
  • 効いた理由の仮説は「お問い合わせまで『あと一歩』のひとたちの不安の緩和」=集客ではなく離脱の防止として働いている
  • 一般化すると「コンバージョン直前のページに信頼性を高めるような情報を置くだけでも、お問い合わせや申し込みの数が増える可能性がある」
  • LP 上部には実績や導入企業ロゴを載せていても、フォームページに遷移した瞬間にそれが消える構成は多く、そこが手つかずで残っている
  • 変更点を1つに絞れば因果が読めるので、フォームページの表示→送信率を先に取っておけば12%級の変化は十分検知できる
  • 同アカウントは併せて AI 検索対策(「AI 検索の影響」の把握方法・今日からできるコンテンツ施策)の取材記事も更新している
工数がほぼゼロで効果が単独で測れる改修で、申込フォーム・ウェビナー登録・資料ダウンロードにそのまま横展開できる。特に判断コストが低い代わりに離脱も軽いウェビナー申込では、直前ページの信頼シグナルが相対的に効きやすい。
📄 PDFをダウンロード 🧵 X スレッドで読む