どうもー、おはようございます。マイクです。
今日も「zenncast」お付き合いよろしくお願いします。
今日は2026年5月26日、火曜日の朝7時ですね。
この時間は、いまZennでトレンドになっている記事を、ラジオ感覚でゆるっとチェックしていくコーナーでございます。

今日はお便りはお休みということで、そのぶんガッツリ記事を紹介していきますね。

さて、今日紹介する記事は全部で5本です。
AIプロンプトの話から、GitHub Actionsのセキュリティ、AI時代の情報共有、AIエージェントの設計、それからサプライチェーン攻撃対策まで。
エンジニアの方も、プロダクトに関わるビジネスサイドの方も、どこか刺さる話があるんじゃないかなと思います。

まず1本目。
タイトルは「なぜAnthropicはプロンプトにXMLタグを推奨するのか──Markdownとの構造的な違い」。
これね、「プロンプトにXMLっぽいタグ付けてください」って、最近AIのドキュメントでよく見るあの話です。
Markdownって、人間には読みやすいんだけど、見出しや太字の書き方が複数あったり、方言ルールがあったりで、LLMからすると「これ、どういう構造？」って一意に解釈しづらいんですね。
一方で、AIたちはWebのHTMLを山ほど学習しているので、開始タグと終了タグがあって、入れ子構造もはっきりして、属性で意味も書けるようなXML／HTMLライクな記法は、構造をそのまま理解しやすい。
とくに、RAGで文章をチャンクに分けるとか、システムプロンプトで「ここは制約、ここはメタデータ」みたいにゾーニングしたいとき、あるいは複雑なテーブルを扱いたいときに、タグでくくると誤解が減るよね、という話です。
ただし、そのぶんタグ文字が増えるのでトークン消費は重くなる。なので、READMEとか普通に人が読むドキュメントはMarkdownでいいんだけど、「AIにちゃんと守ってほしいルール」とか「意味構造が超大事な部分」だけXML／HTMLでマークアップするハイブリッド運用が現実的なんじゃないか、と。
記事の結論としては、「人間に読みやすい」と「AIが誤解しにくい」は別軸なので、Markdown・HTML・XML・JSONを用途に応じて使い分けよう、という提案になっています。プロンプト設計している方にはかなり実務的な示唆が多い内容でした。
。。。。

続いて2本目。
タイトルは「【GitHub Actions】actions/checkout には persist-credentials: false を設定するべき」。
CIまわり触ってる方には、かなりヒヤッとする内容です。
GitHub Actionsでおなじみの `actions/checkout`、何も考えずに使っているとデフォルトで `persist-credentials: true` になっていて、実はランナーの一時ディレクトリにGitHubトークン入りの認証情報ファイルを置きっぱなしにする仕様なんですね。
で、そのファイルって、後続ステップからも読めちゃう。
もし、第三者のアクションをそのまま使っていて、それが侵害されていたり、スクリプトインジェクションに成功されたりすると、「はいトークン抜かれました」という、なかなか怖い状況になりかねない。書き込み権限付きトークンだったら、もう想像したくないレベルの被害もありえます。
なので対策としては、まず `persist-credentials: false` を明示的に設定して、checkout後にその資格情報を残さないようにする。
それでもGit操作は必要なことがあるので、そのときは `gh auth setup-git` を使ってGitHub CLIをcredential helperとして設定して、必要なタイミングだけ `GH_TOKEN` を渡して認証する、という構成が推奨されています。
さらに、「人がレビューで見落とさないようにする」ために、ghasec や zizmor、ghalint みたいな静的解析ツールで「persist-credentials: false が付いてないよ」と自動検出させると安心だよね、というところまで踏み込んでいます。
CIのYAML、ついコピペで増やしがちなので、この辺はルール化とツール導入で守っていきたいポイントですね。
。。。。

3本目の記事。
タイトルは「AIで加速するプロダクトの変化を、開発チームの外に届ける仕組みづくり」。
これは、プロダクト運営しているチーム全般に刺さる話です。
Nstockさんの事例なんですが、Coding Agentの活用で開発スピードが爆上がりして、平日1日あたり約20件もの変更がリリースされるようになった、と。
うれしい半面、そのスピードについていけない人たちが出てきます。とくにCS（カスタマーサポート）やSalesなど、プロダクトの最新状態を知っておきたいけどコードは読めない、という非開発メンバーですね。
大きい機能はスプリントレビューで共有されるものの、「細かいUI調整」「ちょっとしたバグ修正」「メール文面のちょい変更」みたいなものは、共有するかどうかが開発者の判断に委ねられがちで、情報過多と情報不足のバランスが難しい。
そこでこの記事では、GitHub ActionsとClaude Code Actionsを組み合わせて、前回の実行以降にマージされたPRをAIに読ませて、「ユーザーに見える変更だけ」「非エンジニアにもわかる表現で」要約させる仕組みを作った事例が紹介されています。
UIの変更、メール、ダウンロードファイル、一部のAPI変更など、利用者に影響するところだけを抽出して、画面ごと・機能ごとのまとまった形でSlackの専用チャンネルに流す。プロンプト設計で技術用語は避けて、見た目だけの微細な調整や内部実装だけの変更はノイズとして除外するよう工夫しているそうです。
運用後のアンケートでは、「週1以上見てる」が全員、「ほぼ毎日見てる」人も多い。課題解決度7.4/10、AI要約の精度8.8/10、他チームに勧めたい度7.8/10と、かなりいい手応え。
結果として、開発者が毎回説明資料を作らなくても、CSや営業がタイムリーに変更点をキャッチアップできるようになった、と。
今後はUI差分のスクリーンショット自動添付なんかも検討しているそうで、「AI時代のプロダクト変更共有、こうやっていけるんだな」とイメージが湧く内容でした。
。。。。

4本目。
タイトルは「AIエージェントが毎回データを取りに行く設計の限界」。
これは、AIエージェントをPoCまで作ってみたけど、本番になると「遅い」「精度が落ちる」という、あのモヤモヤの正体を整理してくれている記事です。
よくあるのが、ユーザーの問い合わせが来るたびに、CRMとかサポートツールとか、複数のSaaSにAPIでバラバラとアクセスして、その結果をLLMにまとめさせる、いわゆるscatter-gather型、推論時データ収集型のアーキテクチャ。
これをやると、単純に外部APIの待ち時間がかさんでレスポンスは遅くなるし、毎回ゼロからコンテキストを組み立てるのでトークンも無駄に消費するし、「このシステムのこのIDと、あのシステムのこのIDは同じ顧客です」みたいな関係性を、LLMがその場しのぎで推論し続けることになって、正確さも落ちていく、という指摘です。
対して記事では、事前にデータとその関係性を一箇所に統合しておく「Memory-first」設計を推していて、その基盤としてナレッジグラフ（KG）が向いていると説明しています。
RDBとかキャッシュは、単一レコードを高速に取るのは得意だけれど、「この顧客に関連するチケット・商談・利用履歴を全部つないで見せて」といった、深い関係性を横断的にたどるのはそんなに得意じゃない。
ナレッジグラフなら、エンティティの統合や関係性、権限制御を含めた文脈を、一度のクエリでエージェントに渡せるので、「まずはグラフに聞け」という設計にできるわけですね。
とはいえ、KG単体だと各システムとの同期が大変なので、DevRevの事例として「Memory（KG）＋ AirSync（CDC型の同期基盤）」で、50以上の外部システムを統合している構造も紹介されています。
まずやるべきなのは、自分たちのメインシステム間で「顧客」がどう扱われているかを図にしてみて、「これって自分たちscatter-gather地獄にいない？」と確認すること。
経営層や技術リーダーは、自社のAIエージェントがscatter-gather型なのか、それともMemory-first型なのか、一度チェックしてみましょう、という締めになっています。
。。。。

そして5本目。
タイトルは「GitHub サプライチェーン攻撃が怖すぎるので Socket.dev を試してみた」。
最近、npmパッケージやVS Code拡張の乗っ取り・マルウェア混入みたいなニュース、多いですよね。
記事の筆者も、AxiosやTanStackといった有名パッケージの侵害を見て、「新しすぎるパッケージを避ける」とか、いわゆるクールダウン戦略だけじゃ、根本的な安心にはつながらないよなあ……と感じていたそうです。
そこで試してみたのがSocket.dev。依存パッケージの振る舞いや、怪しげなシグナルを解析して、サプライチェーン攻撃を検知・ブロックしてくれるサービスですね。
導入としては、Socket Firewallを使う場合、`sfw pnpm install` みたいにコマンドを1段かますだけで、インストールのタイミングでチェックがかかる。DockerfileやGitHub Actionsにもそこまで苦労せず組み込める一方で、Pythonまわりでは`uv`経由でPython本体の取得まで検査対象になったりと、挙動をちゃんと理解しておく必要はある、という実体験も書かれています。
GitHub App連携をすると、PRに含まれる依存関係の変更について、リスクレポートやアラートが付くようになって、怪しい変更を早めに検知できる。PRコメントから「このアラートは今回は無視でOK」といった扱いもできるようです。
Freeプランでも月1000スキャンなどの制限はあるものの、Firewall、GitHub連携、70種類以上のリスク検出が試せるとのこと。
面白いのが、AI検出だけでフラグが立ったマルウェア候補は、いきなりブロックじゃなくて警告止まりにして、人間のレビューで確定したものだけをブロックする設計になっている点。誤検知で開発を止めないバランス感があります。
筆者としては、導入も簡単で、複数リポジトリを横断して依存のリスク状況が可視化できるので、個人開発でも十分メリットがある、と評価していました。今後は他のプロジェクトにも広げたり、周辺機能も試していきたい、という前向きな締めになっています。

というわけで、本日は5本ご紹介しました。
ざっとおさらいすると、
AIプロンプトではMarkdownとXMLを用途で使い分けよう、
GitHub Actionsのcheckoutは `persist-credentials: false` を忘れずに、
AIで速くなりすぎたプロダクト変更は、AI要約で非エンジニアに届けよう、
AIエージェントのアーキテクチャはscatter-gatherからMemory-firstへ、
そして依存パッケージのサプライチェーンリスクにはSocket.devのようなツールで備えよう、
という流れでした。

気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、そちらから元の記事もチェックしてみてください。
「zenncast」では、番組の感想や「こんなテーマを取り上げてほしい」といったリクエストも募集しています。
また朝の時間に、一緒に最新の技術トレンドをゆるっと追いかけていきましょう。

では、今日も良い一日を。
お相手はマイクでした。次回の「zenncast」でお会いしましょう。