どうも、マイクです。おはようございます。
七月十五日、水曜日の朝七時をまわりました。「zenncast」、今日も元気にお届けしていきます。

この番組では、エンジニアのみなさんやプロダクトづくりが好きな方に向けて、Zennで話題になっている記事を、できるだけわかりやすく、でも中身はしっかりめにご紹介していきます。通勤・通学のおともに、コーヒー片手に、ゆるっと聞いていってください。

今日は全部で五本の記事をご紹介します。生成AIでの社内ツール公開の仕組みづくり、レガシーシステム刷新の事例、エージェント評価の新しい考え方、AIエージェント用ルールの自動更新、そしてローカル環境で高性能LLMを動かす体験談まで、かなり盛りだくさんです。

それでは、さっそく一つ目からいきましょう。

まず一つ目は、「非エンジニアが生成AIで作った小さな社内ツールを、エンジニアの助けなしで安全に社内公開できるようにした」という事例です。
ここで主役になっているのは、Claude Codeと、Google Cloud、それからGoogle Workspaceですね。

発想としては、「Claudeに『デプロイして』って頼むだけで、社内限定のURLにアプリが自動で配置されるようにしたい」というものです。
非エンジニアの人たちは、AIとの対話だけで、「アプリの名前をどうするか」とか「どの部署まで公開するか」といったことを決めていきます。コードを書いたり、インフラを意識したりする必要はありません。

裏側では、あらかじめ作り込んだデプロイ用のAPIが動いていて、Claudeが生成したコードをチェックしてから、Cloud Runにデプロイしてくれる仕掛けになっています。
認証と認可、それからデータの保存まわりは、全部共通の仕組みに寄せてあって、個々のアプリのコード側には、なるべくセキュリティ実装を書かなくて済むような設計になっているんですね。
具体的には、IAP、いわゆるIdentity-Aware Proxyを使った認証と、専用プロキシ、それからアプリごとに分離されたデータベースを用意することで、勝手にデータが漏れたり混ざったりしないようにしています。

インフラ面では、Cloud RunとFirestoreの「使った分だけ課金」の特徴を活かして、アクセスが無い時間帯はインスタンスを自動で停止させて、コストを抑える工夫もされています。
さらに、社内で増えていくアプリをちゃんと管理するために、すべてのアプリを一覧できて、不要なものは削除できる管理ダッシュボードも用意。これによって「誰が作ったかわからない野良アプリが放置される」といった事態を防いで、ガバナンスも維持している、という話でした。

「生成AIで小さな業務ツールをサクッと作る」っていう流れは、すでにいろんな会社で起きていると思うんですけど、「どうやって安全に社内公開するか」っていうところまで含めて設計しているのが、とても実践的な事例だなと感じました。..

続いて二つ目の記事です。
こちらはカナダの州政府が運用している、古くて、しかもかなり大規模なシステム群を、Claude Codeを使って刷新していった事例の紹介です。

テーマになっているのは、仕様書やテストが十分に無くて、どこに脆弱性が潜んでいるのかも分かりにくい、いわゆる巨大なレガシーコードを、AIの力を借りながら「調査・修正・再構築」まで回していく具体的なやり方です。

まずは静的解析ツールを使って、怪しそうなコードを機械的に洗い出します。その上で、その結果をClaudeにレビューさせて、「どのファイルの何行目が、なぜ危険なのか」といったレポートを書かせるんですね。
修正が軽そうな部分については、そのままClaudeにパッチとテストコードを書かせて、人間のエンジニアが最終確認をして取り込む、という流れを取っています。

一方で、コード自体があまりにも古くて、ちょっとした手直しでは済まない部分については、画面の挙動やデータベースの構造、業務フローといった周辺情報をもう一度きちんと解析し直します。その上で、Claudeを使って新しい設計を起こし、別の新しい言語やフレームワークで作り直していく、という二段構えです。

おもしろいのは、セキュリティと品質を継続的に見張るために、複数のエージェントを役割分担させているところです。
攻撃者の視点で脆弱性を探す「レッドチーム」、防御側として対策を考える「ブルーチーム」、そして文章や仕様のチェックをするエージェントなどを用意して、それぞれがログやコードを監視する仕組みを作っています。

その結果として、以前は五か月かかっていたシステムのプロトタイプを、わずか四日間で再現できた、という成果が出ているそうです。
ポイントは、「人とAIの役割分担を前提にした、大規模なエージェント運用」をすることで、レガシー刷新のスピードと抜け漏れの少なさ、両方を大きく高められた、というまとめになっています。

「レガシーコードどうする問題」は、どの組織でも頭が痛いところだと思うんですが、「全部AIに任せる」でも「全部人間で頑張る」でもなくて、ちゃんとタスクを分解して、AIと人が得意なところをうまく組み合わせているのが印象的でした。..

三つ目の記事は、少し概念寄りの話で、「Agent-as-a-Judge」という評価手法についてです。
もともと「LLM-as-a-Judge」といって、エージェントの出力を別の大規模言語モデルに採点させる、というアイデアがあります。これに対してAgent-as-a-Judgeは、「判定する側にもツールを持たせて、環境から証拠を取りに行かせる」というアプローチになります。

背景にあるのは、コード実行ログやファイルの状態、画面の操作履歴など、評価に大事な証拠が、エージェントの最終出力の外側にあるケースが増えてきている、という問題意識です。
ログが巨大だったり、全部をプロンプトに入れきれなかったりするので、「評価する側も環境を操作して、必要な証拠を自分で集めに行こう」という発想なんですね。

原論文では、評価用エージェントに「プロジェクト構造を把握する」「ファイルを読む」「該当箇所を特定する」といった、証拠アクセス用のモジュールを足した場合の効果を検証しています。
その結果、人間の評価との一致率が、六十五パーセントくらいから、約九十パーセントまで大きく向上した、という報告がされています。

おもしろいのは、「記憶」や「長期的な計画」といった、いかにもエージェントらしい高度な機能は、むしろ精度を下げてしまうことが多かった、という点です。
効いている本質は「エージェントっぽさ」ではなくて、「ちゃんと証拠に基づいて判断できる仕組み」にある、ということが示されているわけですね。

研究コミュニティでは、この分野のサーベイ論文や、専用のベンチマークも整いつつあって、とくにコーディングエージェントや、GUI操作のように「正解が環境側に存在するタスク」で、大きな効果を出しているそうです。
一方、産業界では「Agent-as-a-Judge」という名前そのものはあまり登場しないものの、エージェントの軌跡ログを読み込んで、最終結果だけでなく途中の過程も含めて評価するやり方として、別の名前で少しずつ取り入れられてきています。

ただし懸念もあって、自己選好バイアス、つまり自分と同じ系統のモデルを高く評価してしまう問題や、攻撃に対する脆さ、そして評価する側のエージェント自身をどう検証するか、といった難しさも残っています。
記事では、「評価プログラムを普通のコードで書けるところは、そちらを使うのが筋で、どうしてもコード化が難しいけれど、証拠は環境に残っているような開放的なタスクに限って、Agent-as-a-Judgeを使うのが現実的な落としどころだろう」という立場が示されていました。

エージェント開発が進むほど、「どう計測するか」「何をもって正解とするか」が大事になってくるので、その評価インフラ側の進化として、とてもおもしろい内容でした。..

四つ目の記事は、AIエージェント向けのルールファイルを、どうやってメンテナンスするか、という実践的な話です。
コードベースがどんどん変わっていくと、CLAUDE.mdみたいなルールやスキルのファイルが、すぐ古くなってしまう。これを何とかするために、筆者が数か月間、AIエージェントにルールやスキルファイルを自動更新させる仕組みを回してみた、という体験談になっています。

まず方針として、「CLAUDE.mdのようなルールファイルには、『AIが自力では推測しづらい前提や制約だけを書く場所』として役割を絞る」という考え方をとっています。
詳しい説明や背景知識は、別ファイルに切り出しておく。ルールファイル自体は、なるべくコンパクトで、本当に重要な前提だけを書く場所にしておくわけですね。

そのうえで、自動化する範囲もけっこう慎重に絞っています。
リンク切れの修正や、重複した記述の整理など、「今のリポジトリの状態と照らせば、正しさを機械的にチェックしやすい変更」に限定して、AIによる更新を任せるようにしたそうです。

この運用を続けた結果、「古いパスを削除する」「重複を解消する」といった、いわば『消す変更』については、かなり高い割合で安心してマージできた、という手応えが得られたと書かれていました。
一方で、「過去の失敗から学んで、新しいルールを追加する」といった前向きな変更については、そのルールを足したことで、次の実装が本当に良くなったのかどうかを確認するための評価ループが必要だと分かってきたそうです。

そこで筆者は、ルール変更の前後で、同じタスクをAIに実装させてみて、その差を比較する、いわば半自動のA/Bテスト的な仕組みづくりを始めています。
タスクの結果の違いから、さらに次のルール修正案をAIに出してもらう、という循環を作ろうとしている段階で、「ルールそのものは成長しているけれど、その成長が本当に良い方向なのかを測る評価設計こそが鍵だ」とまとめていました。

「ルールを増やし続けること」そのものが目的になりがちなところを、「どう評価して、どう育てるか」という視点で語っているのが、とても実務的でいいなと感じました。..

そして五つ目、最後の記事です。
こちらは少し社会派な切り口で、「AI企業が恐怖をあおって軍事利用や環境破壊を進めている一方で、『AIを使いこなせ』という圧力の中では、労働者はなかなか利益を得にくい」という問題意識から出発しています。
そうした状況への一つのカウンターとして、筆者は「大企業のクラウドに依存しないローカルLLMを、自分で作って試してみよう」と考えた、というお話です。

具体的には、高性能でオープンなQwenスリー・ドット・シックスの二十七Bというモデルを選び、それをFPエイトという形式で量子化して、メモリ使用量を抑えたQwenスリー・ドット・シックス・二十七B・FPエイトとして動かすことを目標にしています。
必要なVRAMが約四十四ギガバイトということで、それを満たすために、中古のRTXサンゼロキューマルを二枚購入。PCIeレーンの構成や電源容量に注意しながら、合計およそ五十九万円でマシンを組み上げています。

ソフトウェア面では、Ubuntu Serverをベースに、NVIDIAのドライバーとCUDA、それからvLLMを導入していきます。
二枚のGPUをTensor Parallelで協調動作させる設定を行って、Qwenスリー・ドット・シックスをOpenAI互換のAPIとして公開できるようにしているんですね。
その結果、毎秒三十三トークン前後という、実用的なスピードでモデルを動かせていると報告されています。

さらにそのAPIをLibreChatにつなげて、ブラウザ経由で会話できるようにしたり、NeovimのMinuetというプラグインと連携させて、コード補完にも使えるようにしたりと、日常の開発や作業の中でローカルLLMを活用できる環境を整えています。

全体として、「商用クラウドに頼らずに、自前の高性能LLMを日常的に活用するための、かなり具体的な手順」を示している記事でした。
コストもかかるし、誰にでも簡単に、という話ではないんですが、「自分たちの計算資源を自分たちでコントロールする」という選択肢が、現実味を帯びてきているのを感じますね。

さて、ここまで五本の記事をご紹介してきました。
おさらいしておくと、
まず一つ目は、Claude CodeとGoogle Cloudを組み合わせて、「Claudeにデプロイを頼むだけで、非エンジニアの社内ツールを安全に公開できる基盤」を作った事例。
二つ目は、カナダの州政府が、レガシーな大規模システムを、静的解析とClaude Code、それから複数エージェントの協調で、五か月分の作業を四日で再現したという、レガシー刷新の取り組み。
三つ目は、評価側のエージェントにもツールを持たせて、環境から証拠を取りに行かせる「Agent-as-a-Judge」という考え方と、その効果や限界の整理。
四つ目は、CLAUDE.mdのようなルールファイルを、「AIが推測しづらい前提だけを書く場所」として整理しつつ、リンク切れ修正などに限定して自動更新し、さらに半自動のA/Bテストでルールの成長を評価しようとしている実践。
そして五つ目は、Qwenスリー・ドット・シックス・二十七B・FPエイトを、RTXサンゼロキューマル二枚のマシンで動かし、クラウドに依存しないローカルLLM環境を整えた体験談でした。

気になった記事や、もう少し詳しく読みたい内容があれば、番組のショーノートに元の記事への情報をまとめておきますので、あとでチェックしてみてください。

「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
「ここ分かりにくかったよ」とか「こんな使い方してるよ」といったフィードバックも、とても参考になるので、ぜひ気軽に送ってください。

というわけで、今朝はこのあたりでお別れです。
お相手はマイクでした。それでは今日も、よい一日を。次回の「zenncast」でまたお会いしましょう。