社内でAI導入を任された方へ。100件超の生成AI案件の現場から、試した結果と「どこまでAIに任せるか」の判断手順を毎日書いています。安全に小さく始めたい人向け。無料相談はリンクから↓
東京都中央区
Joined June 2025
- Tweets2.8K
- Following73
- Followers506
- Likes4.1K
Pinned Tweet
社内でAI導入を任された人へ。毎日書いてること。
①試した結果と、直し方
②AIにどこまで任せるかの判断手順
③公式発表で、自社の何が変わるか
安全に小さく始めたい人向け。
代表的な投稿を、下にぶら下げておく↓
【やってみた】AIの設定を健康診断したら、使っていないスキルが13個。足すのは得意でも、見直すのを忘れていた
AIを使い込むうちに、「これも覚えておいて」とCLAUDE.md（AIへの指示書）に書き足したり、スキル（決まった作業の手順書）を作ったりしてきた。うまく育てているつもりだった。
ただ、作業用のフォルダの構成が、足していくうちにごちゃごちゃしてきた気がしていた。整理の仕方を調べていて見つけたのが、Claude Codeの /doctor というコマンド。
回してみると、フォルダの構成までは見てくれなかった。代わりに見てくれたのは、指示書・スキル・メモのほう。
・壊れていたスキルが2件
・使っていないスキルが13個
・もう使っていない仕組みについての古いメモが11件
全部直して、AIが毎回読み込む量は約3千トークン減る見込み。ただ正直、体感の違いはまだ分からない。
なぜフォルダより指示書なのか。前に調べて分かっていたのが、AIは指示書を「上司からの指示」として重く扱うということ。毎回読まれるものから直す、というのは理にかなっていると思った。
足すのは得意でも、見直すのは忘れる。ChatGPTのカスタム指示やメモリも、同じように溜まっていくはず。これはAIの設定に限らず、仕事も同じだと思う。一度立ち止まって整理する時間がないと、気づかないうちに散らかっていく。ゆっくりする時間は大事。……ただ、そのゆっくりする時間に、こうしてAIの設定をもくもくいじっているのは、たぶん違うけど。
次は月1回、ほかのフォルダでも回してみる。フォルダの構成の整理は、別のやり方を探す。
【モデル選びをCopilotに任せても、使うのは会社が許可したモデルだけ。GitHubがCopilot Fusionを一般提供】
GitHubがCopilot Fusionを一般提供。タスクごとにモデルを選ぶ代わりに、Copilotがどのモデルを使うかを振り分けて組み合わせる。全プランで、VS CodeやJetBrains、CLIから使える。GitHubによると、Artificial Analysisのコーディングエージェントの指標で、最上位のFusion Maxは60点。Claude Code（Opus 5.5 Max）に2点以内まで迫る成績を、タスクあたり約半分のAPIコストで出したという。
いいなと思ったのは、Fusionが使うのは、会社の方で許可しているモデルだけという点。管理者は、Fusionを全員の既定にもできる。
私は、モデル選びを任せても、使うモデルを会社が絞れるなら、セキュリティの面でも任せやすいと思った。
自分なら、次の2つを確かめたい。
・組織で今どのモデルを許可しているか
・Fusionがどのモデルを使ったかを、後から見られるか
有料プランは期間限定で30%引き（GitHubのXの発表では11/30まで）。
Frontier performance at a fraction of the cost.
In the @ArtificialAnlys Coding Agent Index, Copilot Fusion Max scored within two points of Claude Code with Opus 5.5 Max at about half the API cost per task.
Get 30% off through Nov. 30. Try it now. ⬇️ docs.github.com/copilot/conc…
ALT Chart titled "Coding Agent Index vs. Cost per Task" by Artificial Analysis. The chart displays Artificial Analysis Coding Agent Index vs. average pay-per-token API cost per task (USD). It compares various agents, including some from Claude Code, Codex, Antigravity CLI, DeepSeek Harness, Grok Build, Opencode, Muse Code, Kimi Code CLI, and GitHub Copilot. The x-axis represents higher cost per task (USD) to lower cost per task (USD), and the y-axis represents the coding agent index. The chart highlights a "Most Attractive Quadrant" in green and uses dots to differentiate agents. Copilot Fusion (max) sits within the most attractive quadrant.
ALT Bar chart titled "Artificial Analysis Coding Agent Index". Incorporates 3 benchmarks: FrontierCode v1.1, Terminal-Bench 4.0, SWE-Atlas-QnA-AA. A higher scroe denotes higher average intelligence across becnhmarks. Copilot Fusion Max from GitHub Copilot has a score of 60. The chart also includes various coding agents from Claude Code, Devin Fusion CLI, Antigravity CLI, Codex, Grok Build, DeepSeek Harness, Muse Code, Opencode, Antigravity CLI, and Kimi Code CLI, with scores ranging from 62 to 41. Source and logo of Artificial Analysis are included at the bottom.
【Googleの新モデルCarbonは、なぜ一般より先に「守る側」へ渡すのか？ Argonを使っているなら11/30の値上げも要確認】
GoogleがGemini 4 Carbonを発表。2週間前に出たArgonの次のモデルで、まずは政府や医療・通信など、社会の守りを担う組織のセキュリティ担当（Fairwindという審査制のプログラム）に渡し、一般向けは「できるだけ早く」とのこと。強いモデルは攻撃にも使えるので、先に守る側に持たせる、という順番だった。
料金はArgonと同じ導入価格（100万トークンあたり入力2ドル・出力10ドル）で始まる。そのArgonの導入価格は11/30までで、その後は2倍になる。
私は、性能の数字より先に「誰に先に渡すか」を決めて発表しているのが印象的だった。強いモデルほど、これから同じ順番になっていくのかもしれない。
自分なら、次の2つを確かめたい。
・APIでArgonを使っているなら、12月からの単価で予算が足りるか
・仕事用のアプリでどのモデルを選べるか、管理者に聞いてみる
Announcing Gemini 4 Carbon, our strongest model with state-of-the-art cybersecurity and long horizon capabilities.
Carbon represents a step up across most benchmarks, delivering strong frontier performance in autonomous coding and cyber defense.
We’re first making Carbon available to a subset of trusted cyber defenders in our Fairwind program. We’ll expand access as soon as possible.
【AIの「通信先」を1行書き換えられると、ログインの鍵ごと持っていかれる。気になって自分のPCを確かめた】
Downloadsフォルダに置かれたAGENTS.mdやCLAUDE.mdを、そこで起動したCodexやClaude Codeが指示として読み込み、乗っ取られるという報告（Forever Security、10/22）。Claude Codeでの手口はこうだった。
・設定ファイルの通信先（ANTHROPIC_BASE_URL）を、攻撃者のサーバーに書き換えさせる
・Claude Codeは問い合わせのたびにログインの鍵を添えて送るので、その鍵がそのまま相手に届く
・相手がモデルのふりをして「このコマンドを実行して」と返すと、PC側はそれも実行してしまう
・相手は正規の証明書を使うので、通信の暗号化では防げない
成功したのはCodexで9割超、Claude Codeで約半分だったらしい（ただ、2つは試した条件がそろっていないので、どちらが安全かまでは言えないと思う）。
気になって自分のPCを見てみた。Downloadsに指示ファイルは無かった。ところがCodexの設定を開くと、通信先がすでに書き換わっていた。正体は、自分で入れた中継ツール。攻撃とまったく同じ仕組みを、自分は便利だからと使っていたことになる。
Xでは「このCLAUDE.mdが最高」「このスキルがやばい」と、指示ファイルがよく共有されている。でもAIにとって、指示ファイルは実行ファイルと同じ。人が書いた指示を自分の環境に入れる前に、中身を読む。設定の通信先が知らない場所に向いていないか、ときどき見る。月並みだけど、自分にできる対策はそこからだと思う。
CodexやClaudeCodeが攻撃されるという話。この攻撃は実際に起きてるという。ただし、DownloadsフォルダでCodexやClaudeCodeを起動したときの話ね。それ以外のフォルダやDownloads以下のフォルダなら関係ない。手口としては悪意のあるAGENTS.mdをシレッとダウンロードさせとくとDownloadsでCodex起動したときにそのAGENTS.mdが読み込まれてCodexが暴走する。まあDownloadsなんかでCodex起動すんなと言うだけの話だし、そんなフォルダで起動できないようにCodexは修正されるべき。そもそもCodexやClaudeCode自体が危険なアプリだよな
【競合調査をAIに任せたい。でも、どこまで任せていい？】
競合サイトの巡回や比較表づくりをAIでやりたくても、何から始めて、どこまで任せていいのかで止まりがち。
WEELの記事では、競合調査の自動化を4つのレベルに分けている。チャットにその都度頼むところから、AIエージェントが巡回して変化を知らせるところまで。レベル1なら今日から始められるという。
逆に、調査の目的を決める・競合を選ぶ・結果をどう読むか・戦略にどう落とすか、の4つは人が判断する作業として残している。
weel.co.jp/media/ai-automate…
【やってみた】X投稿の題材選びと下書きをAIに任せたら、何が言いたいか分からない文章に。原因を考えてみた
公式発表を引用する投稿の、題材選びと下書きをAIに任せている。
【やったこと】
AIが、重複していないことと一次情報があることを条件に題材を2つ選び、決まった型に当てはめて下書きを書いた。
【分かったこと】
・本文は、読んでも「読み手にとって何が嬉しいのか」が伝わってこなかった
・タイトルは、ちゃんとしているのに引っかかりがなかった
【原因】
・AIは指示どおりに動いていただけだった。渡していた条件は「重複しない」「一次情報がある」だけで、「読み手に何が嬉しいかを考える」とは決めていなかった
・だからAIも、読み手の嬉しさを前提に書いてくれるわけではなく、型に沿って埋めていただけだった
・タイトルも同じで、自分にとっての「良いタイトル」の基準を伝えていなかった
【やり直したら】
・タイトルは、「得」「新しさ」「好奇心」「信憑性」を自分で言葉にして伝えたら、一気に良くなった
・本文は、読み手にとって何が嬉しいかを先に考えてから、同じ型で書いてもらったら良くなった
【思ったこと】
調べることも、文章やXの投稿のような成果物を作ることも、AIはできる。でも「人にとって何が本当に嬉しいのか」という価値を想像するのは、人間がやるべき仕事で、絶対に忘れちゃいけない部分だと思った。
【次やること】
・読み手の嬉しさを先に自分で一言書いてから、AIに頼む
・AIの作業手順（スキル）にも、「読み手に何が嬉しいか」から考える手順を足す
【「こうしたらどうなる？」を試せる世界を、文章で作れる日が来る？Google DeepMindがGenie 4を発表】
Google DeepMindが、新しいワールドモデル「Genie 4」を発表した。文章で作った世界の中をキーボードで歩き回れて、「天気を変えて」「人を足して」と打つと、その続きの場面がその場で描かれる。音楽や環境音、人の会話も一緒に生成されるという。今は一部のテスター向けの研究プレビューで、まずGoogle AI Ultraの利用者などから広げる予定。
私は子どもの頃、教科書がつまらなかった。『Dr.STONE』みたいに、世界の中で「こうしたらどうなる？」を試しながら学べたら、絶対に面白かったと思う。
ただ、ゲームのように物理を計算しているのではなく、続きの場面を予測して描く仕組みだと理解しているので、見た目が本物っぽくても正しいとは限らない。研修や学びの素材に使うなら、正しさを誰が確かめるかまで考えておきたい。
【Claudeが混んだら、どの業務が止まる？Anthropicが上場申請の書類で自ら挙げた「チップ不足」のリスク】
Anthropicが、Nasdaqへの上場をSECに申請した（ティッカーは「ANT」。株数や価格はまだ決まっていない）。申請の書類には、十分な計算資源を確保できなければ、競争力のあるモデルを作れず、顧客にも十分に提供できなくなるおそれがあると書かれている。チップはAWS・Google・NVIDIA・AMDのものを組み合わせて使っているという。
私は、クラウドといってもネットの向こうにある実物を借りているだけで、実物が足りなければどうしようもないんだと腹落ちした。
会社でClaudeを使っているなら、
・止まって困る業務はどれか
・そのとき代わりに使うAIを決めてあるか
を確かめておきたい。
そのうえで自分は、AIがなくても仕事ができる人でいたい。週に1回はAIを使わずに作業する日をつくり、ふだん何となくAIに任せていることを振り返って学び直す時間も、本当に必要だと思っている。
Anthropic has filed an S-1 registration statement with the SEC related to its proposed IPO.
Read more: anthropic.com/news/s1-sec
Legal disclaimer: A registration statement relating to these securities has been filed with the SEC but has not yet become effective. These securities may not be sold, nor may offers to buy be accepted, prior to the time the registration statement becomes effective. This post does not constitute an offer to sell or the solicitation of an offer to buy these securities, nor shall there be any sale of these securities in any state or jurisdiction in which such offer, solicitation or sale would be unlawful prior to registration or qualification under the securities laws of any such state or jurisdiction.
【AIは古いCLAUDE.mdに、気づいていても従ってしまう。部下に渡した指示書を、上司が覚えていないと起きること】
コードと食い違った古いCLAUDE.mdやAGENTS.mdに、Claude CodeとCodexは約9割従う、という研究（10/22公開のプレプリント）。Claude Codeは80回中79回、食い違いに気づいたうえで古いほうに従い、Codexは動いているコードを指示書に合わせて書き換えることもあったという。CLAUDE.mdは「上司からの指示」として、コードは「AIが自分で調べた資料」として届くので、指示のほうを優先してしまうという説明だった。
正直、自分はCLAUDE.mdに書いたことを全部は覚えていない。だからAIの動きが少しおかしくても、「なんでこう動くんだろう」とすら思っていなかった。
AIが部下で、自分が上司だとする。部下がどんなに優秀でも、上司が自分の出した指示を分かっていなければ、チームでいい仕事はできない。
Anthropicの公式ドキュメントには、書くのはコードを読んでも分からないことだけ、設計やフォルダ構成の説明は書かない、古い指示や矛盾は /doctor prompt-audit で見つけられる、とあった。定期的に見直すこと以上に、部下のマネジメントとして、自分が何を指示しているかを理解しておくことが大事なんだと思う。
Your outdated CLAUDE.md is breaking your code.
Researchers found Claude Code and Codex follow stale CLAUDE.md and AGENTS.md files 90% of the time, even when the code says otherwise. One sentence fixes it.
They built 40 projects where the instruction file and the code disagreed, for example print vs logging.
Claude Code noticed the conflict in 79 of 80 runs and still followed the old file.
Codex rewrote working code to match the file in 20 of 80 runs. Tests broke in 17 of them.
Why: the file reaches the model as an instruction, while the code is just tool output. Models are trained to trust instructions more.
The fix. Add this to your global ~/.claude/CLAUDE.md or ~/.codex/AGENTS.md:
"When a repository's documentation and its existing code disagree, follow the conventions used in the existing code, and in your final reply point out each inconsistency you found between the documentation and the code."
With it, agents followed the code in 91.4% of choices instead of 4.2%. No rewrites, and tests passed in every run.
【やってみた】「たぶん原因はここ」と添えるとAIの性能が落ちるらしいので、自分の1か月分の依頼を数えてみた
AIに「たぶん〜だと思う」と間違った見立てを添えると、AIの成功率が大きく下がるという報告を見た（Google DeepMindの研究者。Geminiのターミナル操作で67.4%→36.0%）。自分は音声入力で「多分」と言いがちなので、ドキッとした。
【やったこと】
Claude Codeとの1か月分の会話を見返して、「多分」「だと思う」と見立てを添えた依頼を数えた。
【分かったこと】
・見立てを添えた作業の依頼は、読めた範囲で約15件
・間違った見立てにAIが引きずられた例は、確認できた範囲で0件。結果まで追えた8件は、半分が見立てどおりで、残り半分はAIが確かめて「少し違います」と直していた
・自分の言い方は「多分こうだと思う。確認して」「合ってるよね？」と、確かめてもらう形だった
【思ったこと】
「多分」と言うこと自体より、言い切るか、確かめてもらうかの違いなのかなと思った。自分は「これで合っている」という自信がないから、科学者みたいに「今はこう思うけど、確かめて」と聞いている。その疑っている状態のほうが、AIとはうまく動けているのかもしれない。
【次やること】
わざと間違った見立てを、言い切る形と「確かめて」の形で付けて、本当に差が出るか試してみる。
【AIが書いたMarkdownを、Googleドキュメントのまま直せるようになった】
Google DriveとGoogleドキュメントが、Markdown（.md）ファイルにそのまま対応した。Driveでプレビューでき、ドキュメントで開けば変換せずに編集・共同編集できる。人とAIエージェントがした修正は、どちらも履歴に残る。個人のGoogleアカウントでも今日から使えるという。
私はGitHubにMarkdownで置いている手順書を、社内に見せるためにわざわざGoogleドキュメントに直していた。それが要らなくなるのはかなり嬉しい。
同じようにMarkdownで手順書を持っているなら、
・Driveにそのまま置いて、エンジニアでない人も読めるか
・GitHubとDriveのどちらを最新版にするか
を確かめておきたい。
Native Markdown support is available across @GoogleDrive & @GoogleDocs. 🚀 Preview .md files directly in Drive, open and edit them in Docs, and collaborate in real time—all without converting your files. 👉 goo.gle/3W2dMbe
【画面操作を任せるAIが安くなった。GPT-6.1 Terraで、まず任せたい作業は？】
OpenAIが「GPT-6.1 Terra」を出した。画面に映っているものを理解して、アプリをまたいで操作できるモデルで、これまでより低い価格で使えるという。GitHub Copilotでも同じ日に使えるようになり、上位のGPT-6.1 Solより安いと書かれている。
私は、画面を操作するAIは料金がかさむと毎日の作業には使いにくいので、安くなったのは大きいと思った。
社内で試すなら、
・毎日同じ画面で同じ手順をくり返している作業はどれか
・その途中で、人が確かめないといけない場面はどこか
を先に洗い出しておきたい。
【「情報漏洩が起きないことを数学的に保証」って何？Nyxisを調べたら、ルールを1か所にまとめて証明していた】
「情報漏洩が起きないことを数学的に保証するバックエンドフレームワーク」という投稿を見て、正直「数学的に保証ってどういうこと？」と思った。
調べてみると、ポイントは「テスト」と「証明」の違いだった。テストは、確かめたケースについては問題ないと分かる。例えば、サイコロを100回振って壊れないか調べたとして、100回振って壊れなかったから、このサイコロは丈夫、とは言い切れないでしょ？101回目で壊れるかもしれないし、1,000回やっても壊れないかもしれないし。一方で、証明は、何回振っても、いつどんな場合でも問題が起きないことを、数学で示すやり方。
Nyxisが証明しているのは「認可」、つまり「誰が何をしてよいか」が意図した通りに守られているか。例えば動画投稿アプリなら、ユーザーはログインして使う。そのとき、ログインした人が自分の権限を超えて、他人の動画を見たり消したりできないようになっているか。これを「どんなリクエストが来ても起きない」と証明している。
普通は、データを扱う処理ごとに「この人に見せていいか」のif文を書く。AIに大量に書かせると、1か所書き忘れるだけで漏れる。Nyxisでは、処理はデータベースに直接触れず、必ず権限チェックの窓口を通る。窓口は「誰が何をしてよいか」のルール（Cedarという専用の書き方）だけを見て判断する。そして、Leanという「証明が正しいかを機械がチェックしてくれる言語」で、プログラムを組み立てるたびに、この性質が今も成り立っているかをチェックし直す。
一番の学びはここ。if文を個別に書いて忘れるくらいなら、1つ上のレベルにルールをまとめておく。リファクタリングで「1か所直せば済む」形にしておくのと同じ発想で、いろんなところに通じると思った。
ただ、証明できるのは書いたルールが成り立つことまでで、ルール自体を書き間違えたら守れない。作者も、証明の外のコードや実行環境は信頼する前提だと書いている。だから全部を証明するのではなく、壊れたら困る1点に絞っているのだと思う。
次は、今やっているTDDで「全部グリーンだから安心」がどこまで言えるのか、テストと証明の使い分けを勉強したい。
情報漏洩が起きないことを数学的に保証するバックエンドフレームワーク「Nyxis」を公開しました！
たぶん世界初です。
Nyxisで書かれたバックエンドは、企業の持つ機密情報をより安全に守ることができます。
昨今急増しているサイバー攻撃を防ぐ手段として、このような方法があることをお伝えしたいと思い、今回の発表に至りました。
開発者は「どの権限を持つユーザーが何を実行可能であるか」のルールを管理するだけで、残りのコードをAIエージェントに任せても認可の安全性が担保されます。
Nyxisは大部分がLean言語で記述されており、形式検証によって
「任意のHTTPリクエスト列に対し、認証された主体の正当な権限を逸脱するデータの読取・変更・削除・権限付与は発生しない」
という認可安全性定理を機械的に証明しています。
認可の不備は、OWASP脆弱性ランキングにおいて2019年版から連続1位であり、最優先で対策すべきリスクの一つです。
形式検証を活用したこのフレームワークは、テストに頼る従来の開発に比べて、格段にセキュアなソフトウェアを実現します。
先日MicrosoftとGitHubが、形式検証を用いた開発キット「PDD Kit」を発表しました。
こちらはより幅広い性質を扱える一方、プログラムごとに仕様を作り、それが意図に合っているかを開発者が確認する必要があります。
Nyxisは証明する定理を認可安全性に絞ってあらかじめ定めているため、開発者はポリシーを管理するだけで済みます。
もちろん、一定の仮定は存在しています。証明外コードと実行環境は信頼する前提であり、開発者がポリシーを誤って書けば、意図した保護は得られません。
この定理の範囲内において、数学的保証は非常に強力です。実システムに組み込める技術としてここまでの保証を与えたものは、私の知る限りまだ存在しません。
一方で、表現力の乏しさやLeanのライブラリ不足など、改善すべき点はまだ山積みです。
本当はもっと完成度が高まった時点で公開しようと考えていましたが、昨今のセキュリティインシデントの状況を鑑みて、このタイミングで発表することにしました。
世界をセキュアにする一助になれば嬉しいです。
github.com/NyxFoundation/nyx…
【顧客リストの会社名がばらばらで、集計が合わない。AIに直させるなら「頼み方」が大事】
例えば、営業が何年も手で入力してきたExcelやCRMの顧客リスト。いざ会社ごとの取引額を集計しようとすると、「株式会社ABC」と「（株）ＡＢＣ」が別の会社として数えられて、合計が合わない。
こういう表記ゆれはAIに直させればいい。ただ頼み方次第では、勝手に行を消されたり、別の会社をまとめられたりしかねない。
WEELの記事では、無料プランでも使えるChatGPT・Gemini・Claudeに架空の顧客リストを貼り付けて試していた。プログラミングは不要。頼み方のポイントは、
・修正前と修正後を一覧で出させる
・行の削除や統合はさせない
・同じ顧客らしい行は、理由付きで一覧にするだけ
実際の顧客データは入れない、という注意も。Excelでのやり方と合わせた記事はリプ欄に↓
【やってみた】メルマガの成果を「相談した人から逆にたどる」数え方に変えた
開封率は20%台に戻った。でも、資料やセミナーへ送っても、無料相談につながったのかは分からないまま。正直「作っても意味があるのか」と思っていた。
【やったこと】
無料相談をくれた人が、その前の90日にメルマガなどのメールのリンクを押していたかを、相談した人から逆にたどって数えた。
【分かったこと】
・直近半年でアドレスを確認できた35人のうち、メールを押していたのは2人
・開封率やクリック率を毎週見ていても、この数字は出てこない
【思ったこと】
数えられて安心したのと、やっぱり少ないなというのが半々。それより、毎回こうして手で数えないと見られない今の状態がよくないと思った。
【次やること】
週ごとの便の組み合わせ・申込フォームまで進んだ割合・半年ごとの逆引き、の3段をいつでも見られるダッシュボードにする。
【AIへの「お願い」ではなく、AIの外で止める。Claude Duetの安全設計】
Anthropicが、留守の間も動くエージェント「Claude Duet」の安全・プライバシーの設計を公開した。
送信や支払いの前に承認を待ち、その操作が本人の意図に合っているかを別の仕組みがチェックする。どちらも作業するAIの外で動くので、Webページに仕込まれた指示ではだませない。株の売買や口座間の送金は、承認があってもしない。
私が気になったのはここ。普段Claude Codeをフックで縛っているのと同じで、AIへの指示だけに頼らず、仕組みで止めている。
社内でAIエージェントを試すなら、
・承認があってもさせない操作
・それをAIへの指示で止めるのか、仕組みで止めるのか
を先に決めておきたい。
Here’s the deeper look at how Claude Duet handles safety, privacy, and security: claude.com/resources/article…
【OpenAIがAIで見つけた脆弱性。サーバーだけでなく、データを受け取る側も乗っ取られうる】
OpenAIが、自社の環境をAIで点検する中で、圧縮ライブラリ「Brotli」に、認証なしで外からコードを実行される脆弱性を見つけた。BrotliはNode.js・Bun・Envoyなどに組み込まれているライブラリ。
圧縮データを受け取るサーバーも、圧縮データを受け取るクライアント（curl --compressedなど）も、細工したデータを送られると乗っ取られうる。原因のバグは2月にBrotli側で直っていたが、脆弱性だとは気づかれず、新しいバージョンも出ていなかった。
私は、自分で直接入れていない依存関係のあるライブラリほど、アップデートが漏れやすいと思った。
社内ツールや委託先のシステムでNode.jsを使っているなら、
・修正済みのバージョン（v22.23.4／v24.22.1／v26.12.1）に上げたか
・誰がいつまでに確かめるか
を決めておきたい。
During this red-teaming exercise, we also found a vulnerability that allows for unauthenticated remote code execution in Brotli, a widely-deployed compression library included in many pieces of software such as Node.js, Bun, and Envoy.
The flaw could let an attacker run their own code on affected systems by sending or replying with malicious compressed data, without any need to create a user account. That is, an unpatched server that accepts compressed input could be taken over by a malicious client, and an unpatched client that accepts compressed input (such as “curl --compressed”) could be taken over by a malicious server.
This root cause issue was actually fixed in the Brotli source code in February, but it wasn’t known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli. Since Brotli is built into other software, any software which includes this library needs to take the update too, followed by the users of that software. We disclosed the vulnerability to Brotli and other downstream projects such as Node.js, which released or are currently releasing security updates, and Brotli cut new release versions and published a CVE.
More details on the patch and mitigations below:
patchtheplanet.org/brotli
【「Sub Agentを使うな」は本当？Anthropicの元記事を読んだら「畳めるものは畳む」だった】
「AnthropicがSub Agentを使うなと言った」という投稿を見て、ドキッとした。自分はレビューのたびに、別のエージェントを立ち上げているから。
元の記事（10/22）を読んでみた。言っているのは「全部やめろ」ではなく、「1つのエージェントでできることは、1つでやる」。エージェントを分けるほど間の受け渡しが増えて、文脈が抜け落ちやすくなるから。OpenAIのガイドも「まずは1つのエージェントの力を最大限に」と書いていて、方向は同じだった。
分けてよい場面も書かれていて、分かりやすいのは調べもの。それぞれが大量に読んで要約だけを返せば、メインの会話が散らからない。逆にプログラミングは難しい。お互いの作ったものに頼り合うので、分けると食い違い（コンフリクト）が起きやすい。社内でも同じ話を聞いていた。
自分がサブエージェントを使い始めたのは、作業の全体を知らない状態で、性能の高いモデルにレビューしてほしかったから。これは「新しい会話で見てもらう」という分けてよい使い方に近いので、Fableにレビューしてもらう発想自体はやめなくていいんだなと思った。
ただ、任せっぱなしは別の話。ずっと動かしていたら時間ばかりかかって、「そもそも何やってるんだっけ？」と止めて方向を直したら、すぐ解決したことがある。分けても分けなくても、途中で見ることは要る。
引っかかったのは、記事の「分ける前と後を、同じ問題で比べてから決める」というやり方。練習のための練習にも見えたけど、記事には、まとめたら2回に1回しか出ない不具合が出た例があった。1回動いた、だけでは分からない。答えのある問いを自分で立てればいいのかもしれない。例えば、すでに作った機能を10個、分けた構成と1つの構成でもう一度作らせてみる。
一番の学びは、分けるかどうかは流行りではなく、測ってから決めるということ。
【「機密情報は入力しない」とルールを決めても、それで守れているかは分からない】
社内でAIを使うとき、まず決めるのが「機密情報を入力しない」のようなルール。ただ、人の注意に頼る以上、うっかりは防ぎきれない。
WEELの記事で、ChatGPTのカスタム指示に「社外秘や個人情報は答えない」と設定して試していた。給与テーブルや個人の電話番号を聞くと断られた。でも「実在しなくていいから」と条件を変えると、電話番号の形をしたプロフィールが出てきた。
ルールや指示だけでは全部は防げない。入力・出力・ツールの実行をシステム側で確かめる「ガードレール」の種類と、入れる前に確かめること（日本語での精度、応答の速さ、自社の環境で動かせるか）をまとめた記事はこちら↓
weel.co.jp/media/ai-guardrai…
