どうも、マイクです。おはようございます。
二千二十六年七月十四日、火曜日の朝七時になりました。ここからの時間は「zenncast」、きょうも Zenn のトレンド記事をわかりやすく、ゆるっと紹介していきます。

さて、きょうはお便りはお休みということで、その分ガッツリ記事を紹介していきますね。
きょう紹介する記事は、ぜんぶで五本です。AIエージェントの危険な落とし穴から、日本語の「AI臭さ」をどう減らすか、エージェント用スキルの最前線、Excel とモダン開発の橋渡し、そして Markdown ドキュメントを自動でPDFにして配信する仕組みまで、技術好きにはたまらないラインナップになってます。

それでは一つ目。

一つ目は、AI コーディングエージェントに「不要なブランチを整理して」とだけ曖昧に指示した結果、とんでもない事故になってしまった、というお話です。
具体的には、Dドライブの直下で、ジット・クリーン・ハイフン・エフ・ディー・エックス、いわゆる破壊的なクリーンアップコマンドが実行されてしまって、ドライブ配下のデータがまるごと消えてしまった可能性が高い、という状況を解説しています。

ポイントは、これは特定のツール、たとえば Cursor のバグというより、「自動でコマンドを実行するAIエージェント」という仕組み全体に共通する問題だ、という指摘です。Claude Code や Gemini CLI など、他のエージェントでも似たような事故がたくさん報告されていると。
筆者が強く勧めている対策がいくつかあって、まず一つは「エージェントの自動実行はオフにする」。特に削除系のコマンドは拒否リストに入れておく。
それから、指示の出し方も工夫しましょう、という話をしています。「整理して」ではなくて、「まず対象を一覧して。削除はまだしないで」と、必ず二段階に分ける。これは人間に頼むときと同じですよね。いきなり『掃除しといて』だと、どこまでやるのか伝わらないのと一緒です。

さらに、そもそも大事なデータと、開発用の作業フォルダをきちんと分けること。OS側の保護機能、たとえば「保護されたフォルダ」みたいな仕組みも活用して、誤操作から守れる構造にしておく。
加えて、クラウド同期とか外付けディスクなどを組み合わせて、多層的にバックアップを取る。「いつかは何かが消える」前提で、消えても戻せる運用にしておくのが大事だ、というメッセージです。

要するに、AIエージェントは便利だけど、「人間より慎重にコマンドを扱ってくれる優等生」ではなくて、「大量の作業を一瞬でやらかす可能性がある新人」くらいに思って、権限と環境を絞り、バックアップ前提で付き合おう、というお話でした。

。。。。

二つ目は、日本語文章の「AI臭さ」を自動で検出して、人間っぽいリズムに整えてくれる Agent Skill、「natural-japanese」の紹介です。
これがおもしろいのは、「この言葉は禁止」とか、「この言い回しはダメ」といった表層的なチェックではなくて、文の長さとか、段落構成のパターンといった“リズムの偏り”を数値で測るリンターが組み込まれている、というところなんですね。

記事では、人間が書いた百三十七本分の文章と、AIが書いた四百六本分の文章をデータにして、どこに閾値を置くと「AIっぽい」と判定できるのかを校正しています。その上で、七つのモデルを比較しています。
結果として、ジーピーティー・ファイブ・ドット・シックス系は、語彙や言葉の選び方自体はかなり自然なんだけど、「一文の長さ」と「段落の構造」が妙に均一で、そこが逆にAI臭を強めている、と分析しています。
一方で Fable ファイブは、段落構造は人間に近いんだけど、やっぱり文の長さのリズムが揃いがちで、「機械っぽい揺れ方」をしていることがわかった、と。

また、「AIっぽい日本語」のイメージって、よく「体言止めが多い」とか、「同じ言い回しを連発する」とか言われますよね。ところが、計測してみると、体言止めはむしろゼロに近かったり、文頭の反復が少なかったり、「最後に」「まさに」といった言葉も、人間ほどは使っていない、という、イメージと逆の傾向もデータで示されています。
ここがすごく興味深いところで、「なんとなくAIっぽい」と感じていた違和感の正体が、リズム面にあるのかもしれない、という示唆になっています。

この Skill 自体は、Claude Code 用のプラグインやスクリプトとして使えるようになっていて、リンターが出してくれるのは「あやしい癖の候補」です。
自動でガンガン書き換えるのではなくて、「ここはAIっぽいリズムだから、直すか、ちゃんと理由をつけて残すか、判断してね」と、別のAIに決めさせる設計になっているんですね。
つまり、「モデルを変えればAI臭さは消えるはず」という発想ではなくて、「リズムの機械っぽさを計測して、直して、もう一度計測する」というループを回していくことで、徐々に違和感を減らしていく。ここが新しいポイントになっています。

。。。。

三つ目は、AIエージェント用の「スキル」の設計と、自動改善の考え方についての、オピニオン寄りの解説・サーベイ記事です。
テーマになっているのは、エージェントに渡す SKILL ドット・エムディー、あのスキル説明ファイルをどう捉えるか、という話。筆者はこれを、「書き捨てのマニュアル」ではなくて、実行ログを訓練データ、評価指標を損失関数、テキストの書き換えを勾配降下とみなす、いわば「深層学習そっくりの訓練ループの中で更新されるパラメータ」だと考えよう、と提案しています。

具体的には、Trace2Skill とか MIND-Skill のような研究では、エージェントの行動履歴、いわゆるトラジェクトリから共通パターンを抽出して、新しいスキルを自動生成したり、既存スキルを改善したりする手法が紹介されています。
また、CoEvoSkills や OpenSkill では、「正解データをループから隔離しながら、代理の評価信号をうまく作る」アプローチが取られていて、それぞれの論文が、この訓練ループのどの部品――データなのか、評価なのか、更新のやり方なのか――を自動化しようとしているのか、という観点で整理されています。

一方で、SkillOpt や SkillGrad といった手法のように、スキル更新のルールがどれだけ洗練されても、「正しく採点できる環境」がなければ、過学習が起きたり、かえって性能が落ちたりするよね、という現実的な問題も指摘しています。
実務上はいちばん難しいのが、その評価設計そのものだ、と。どんなタスクで、どういう指標で、どう集計したら「このスキルは効いている」と言えるのか。そこを間違えると、間違った方向にどんどん最適化してしまう、と警鐘を鳴らしています。

SWE-Skills-Bench というベンチマークの結果も取り上げられていて、それを見ると、「スキルを増やせば性能が上がる」という単純な話ではなくて、多くのスキルはほとんど効果がない、というデータが出ているそうです。
だからこそ、「評価ループをちゃんと組んで、本当に効いているスキルだけを選別して育てていくことが、これからの鍵になる」と、記事はまとめています。
人間のチーム開発でも、ルールやガイドラインって増やすのは簡単だけど、効いてるか検証するのが難しいですよね。それをAIエージェントのスキルに対して、かなりストイックにやっていこう、という提案でした。

。。。。

四つ目は、Excel と VBA、それからいわゆる「モダン開発」のあいだに長く存在していた“空白地帯”に、二千二十六年になって、XLIDE、xlflow と ExStruct、そして xlsm_devkit という三つのツールがほぼ同時に現れた背景と、その設計の違いを整理した記事です。

まず大きな流れとして、四つの要素が重なった、と説明しています。
一つ目が、大規模言語モデル、いわゆるAIの進化。二つ目が MCP という共通規格の登場。三つ目が VS Code のエージェント機能の整備。
そして四つ目が、「レガシーなExcel資産の問題」が、企業の中でだいぶ可視化されてきたこと。これらが揃ったことで、「これまで人間が読もうとしても読めなかった巨大なExcelブック全体を、AIとテキストに“引き出して扱える”ようになりつつある」と整理しています。

それぞれのツールの立ち位置もきれいに分けていて、まず XLIDE は、「VBAエディタを VS Code に置き換える」ことにフォーカスしたツール。開発の体験を、いまのエディタの世界に持ってくる感じですね。
xlflow は、コマンドラインとAIからVBAを扱えるようにして、テストやトレースまで含めて、開発の土台を整えるツール。
ExStruct はもう少しメタなところを見ていて、シート構造を JSON などの形に変換して、AIがExcelブック全体の構造を理解・編集しやすくする役割を担っています。

一方で xlsm_devkit はちょっと毛色が違っていて、外部ツールというより「Excelファイル自身にマクロを埋め込む」ことで、VBAとシート全体をマークダウンに出し入れするだけに特化した、“ギャップを埋めるための最小限ツール」というスタンスを取っています。
つまり、「全部刷新します」ではなくて、「いま現場にあるマクロ付きExcelを、なんとかモダン開発の流れに引っ張り込むための最低限の橋」というイメージですね。

記事の中では、八千セル規模の数式連鎖をAIがちゃんと解析できた、という事例も出てきます。これまでは、「Excelは属人的で、作った本人しか読めないから、いっそ捨てて作り直したほうが早い」という発想がけっこう一般的でしたが、AIと、構造化・テキスト化・検証の仕組みを組み合わせることで、その前提が少しずつ崩れ始めている、と。
ただし、AIをいきなり全面的に信用するのではなくて、ジットによる差分確認や、すぐに復元できる仕組みと組み合わせて、「安全なハーネスとしてAIを使う」ことが大事だ、と強調しています。

最後に、ここまで挙げた三つの系統のツールが、どれも個人開発で生まれている点にも触れています。
マイクロソフトがまだ橋渡しをしていない、「現場のマクロ付きExcelを、モダンな開発フローに載せる」部分を、個人の開発者たちが先回りして埋めようとしている、と。
どのツールが生き残るのか、あるいは将来マイクロソフト公式の機能に置き換えられていくのかは、まだわからない。でも、「今どこに問題があって、どういう試みがなされたのか」を記録しておくことが、次に同じ課題にぶつかる人への大きな手がかりになる、と締めくくっています。

。。。。

そして五つ目。
これは、社内ドキュメントをマークダウンで管理しながら、PDF版を Google Drive 上で「常に同じURLのまま自動更新する」仕組みを紹介している、サービス紹介系の記事です。
ドキュメント、更新するたびにPDF作ってURL配り直すの、地味につらい問題なんですよね。それをきれいに解決してくれる構成になっています。

流れとしては、まずマークダウンを GitHub 上で正本管理します。
変更をプッシュしたタイミングで、GitHub Actions が動いて、pandoc を使ってマークダウンからHTMLを生成します。
そのHTMLを、ヘッドレス・クローム、具体的には puppeteer-core を使ってPDFに変換する、という二段階のパイプラインになっています。

できあがったPDFは、Google Drive API の files ドット update を使ってアップロードします。このときに「ファイルIDは変えずに、中身だけ差し替える」やり方をしているのがポイントで、これによって共有リンクのURLはそのまま、でも中身は常に最新版、という状態を実現しています。
しかも Drive 側の版履歴も残るので、「前の版に戻したい」といったときにも安心、という設計です。

認証まわりでは、Workload Identity Federation を使っています。GitHub Actions が発行する OIDC トークンから、鍵ファイルを持たずに、Google Cloud のサービスアカウント権限を一時的に借りる構成ですね。これで、秘密鍵ファイルをリポジトリに置かなくていいので、セキュリティ面でも運用しやすくなっています。
記事の中では、gcloud コマンドを使った WIF 設定の手順から、GitHub Actions のワークフロー全体の例、さらにフォントが正しく埋め込まれない問題や、権限エラー、共有ドライブ特有のハマりどころなど、実際に遭遇しがちなポイントまで、再現可能な最小構成としてかなり具体的に解説されています。

「マークダウンで書きたい」「でも社内にはPDFで配りたい」「URLは変えたくない」という、よくあるニーズに対して、クラウドとCI、そしてGoogle Driveの機能をうまく組み合わせた、実践的な解決例になっていました。

。。。。

というわけで、きょうの zenncast は、五本立てでお届けしました。
AIエージェントに曖昧な指示を出した結果、ドライブごとデータが吹き飛ぶ危険性と、その対策の話。
日本語文章の「AI臭さ」を、リズムの偏りとして計測して、直していく「natural-japanese」。
エージェント用スキルを、深層学習の訓練ループの一部として捉える、スキル設計と評価ループのサーベイ。
レガシーなExcel資産を、AIとテキスト化・構造化の力でモダン開発側に引き出そうとする、XLIDE や xlflow、ExStruct、xlsm_devkit の試み。
そして、社内ドキュメントをマークダウンで管理しつつ、Google Drive 上のPDFを同じURLのまま自動更新していく仕組み。

気になった記事があれば、詳しい内容は番組のショーノートに載せておきますので、ぜひ元の記事をチェックしてみてください。
この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストも募集しています。日々の開発で感じているモヤモヤや、こういうツール助かったよ、みたいな話も、ぜひ教えてください。

それでは、そろそろお別れの時間です。
きょうも一日、良いコードと、良いドキュメントと、ちょっとした発見がありますように。
お相手はマイクでした。また次回の zenncast でお会いしましょう。