どうも、マイクです。おはようございます。
十月六日、火曜日の朝七時を少し回ったところです。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。AIとか開発とか好きな方は、ぜひコーヒー片手にお付き合いください。

きょうは全部で、五本の記事を紹介していきます。どれもAI時代の開発フローとか、安全性の話、UIデザインまで、かなり幅広くて面白いラインナップですよ。

まず一本目。
これは、AIを使ったプログラミングとか開発フローの回し方についての「考え方」と「テクニック」をまとめた記事です。

この筆者が一番強調しているのが、「人間の役割ってどこにあるのか」というところなんですね。
モデルに全部やらせるんじゃなくて、人間はまず「モデルの限界を見極める」こと。それから、どんな数値を良くしたいのかという「評価指標」をちゃんと決めて、その指標をベースに「AIがぐるぐる回るループそのもの」を設計してあげる。で、AIの行動ログとかテスト・CIの結果を見ながら、「この改善サイクル自体」をチューニングしていくのが人間の仕事だ、という説明がされています。

仕事をAIに任せるときの考え方も、すごく具体的でわかりやすいです。
順番としては、まず「そもそも任せられる仕事かどうか」。次に、「完了の定義を数値で測れるかどうか」。たとえばパフォーマンス何パーセント改善とか、lintの警告ゼロにするとかですね。さらに「その仕事は自動化できるワークフローになっているか」。最後に、AIが失敗したとき「なぜ失敗したのか」を、文脈不足なのか、権限不足なのか、モデル性能の不足なのか、という切り口で振り返ることを勧めています。

プロンプトの話も出てきます。
よくある「あなたは優秀な〜です」みたいなおまじないプロンプトって、だんだん陳腐化して意味が薄れてくるよね、と。そこで筆者は、「グローバルプロンプト」にはあれこれ詰め込まずに、「選択肢があるときの判断基準」だけを書くのがいいと主張しています。
たとえば「Nodeのバージョンはこういう理由でこれを優先する」「Rustのクレートはこの方針で選ぶ」みたいな、判断の物差しですね。一方で、世界知識についてはOSSとか、モデルがもともとよく知っている前提に寄せると効率がいいよ、という話もあります。

ちょっと攻めたテクニックとしては、「スラッシュゴール」に「イシューを全部潰して」みたいな目的を渡して、エージェントに自律的にループさせていく、というやり方も紹介されています。ただし、dspyとかRLMみたいなフレームワークとか、マルチエージェント構成は、まだまだ実験的な要素が強いので、本番のワークフローが固まってから慎重に使ったほうがいいよ、という冷静な線引きもしています。

改善タスクを洗い出すときも工夫があります。
「SREの視点で怪しいところを全部挙げて」とか、「セキュリティ攻撃者視点で穴になりそうなところをリストアップして」といった形で、「どの視点から見るか」をAIに指定して出させる。それを人間がまとめて「アンブレライシュー」に整理しておいて、「スラッシュゴール」で順番に処理させていく。自分の専門外の部分は、ちゃんと別の人間にレビューを回すなど、人間とAIの役割分担をクリアにする運用が紹介されています。

評価指標のところも、かなり具体的です。
たとえば、パフォーマンスの数値とか、RSSメモリの使用量、lintの警告の数、ミューテーションテストのキル率、ビジュアルリグレッションテストの一致率、こういった「客観的な数値」をできるだけ用意しないと、毎回人間が出て行って「これで良い／悪い」を判断しなきゃいけなくなるよ、と警告しています。

コード理解のサポートにAIをどう使うか、という話もあって、ここも実践的です。
Eツーイーのテストケース名やテストの中身、関数シグネチャみたいに、「このコードがどう振る舞うか分かる情報」を中心にAIに要約させる。さらに、説明用の図や画像を自動で作らせて、プルリクエストに添付しておく、といったドキュメント生成の使い方もしています。

そして、さらに一歩進んだ手法として、TLAプラスやQuint、Zスリー、Lean、Alloyといった「形式手法」のツールをAIに使わせる話も出てきます。仕様がそもそも実現可能なのか、キャッシュ制御や権限設計に抜けがないかを、こうした形式手法で検査して、見つかった反例をテストケースに落とし込んでいく。AIにコードを書かせるだけじゃなくて、「仕様レベル」のチェックにまで活かそう、という野心的なワークフローが紹介されている記事でした。

。。。。

つづいて二本目。
こちらはRAGまわりのティップス系の記事です。ポイントは、「普通のRAGの限界」と、それをどう乗り越えるかというところですね。

まず前提として、いまの大規模言語モデル、LLM単体だと、「最新情報」に弱かったり、「すごく長い文章を丸ごと読んで、その全体から推論する」のが苦手だったりします。そこで、外部データを検索して補ってあげる仕組み、いわゆるRAG、リトリーバル・オーグメンテッド・ジェネレーションが大事になっているんですが、この記事では「そのRAGにも弱点があるよ」と整理しています。

一般的なRAGだと、全文検索とかベクトル検索で「それっぽい一部の文」を拾ってきます。でも、「離れた場所に書いてある二つの事実をつないで推論する」とか、「この本全体として何が言いたいのか」といった、もっと高いレベルの理解は苦手なんですね。

そこで出てくるのが「ナレッジグラフ」です。
文章の中に出てくる「人」「場所」「出来事」とか、それらの関係をノードと線で表現して、グラフ構造にしておく。これを検索の対象にすることで、「複数の事実をつなげた推論」がしやすくなる。このナレッジグラフを裏側で使ったRAGを「GraphRAG」と呼びます。

ナレッジグラフを作るときに重要なのが、「オントロジー」と呼ばれる設計ルールです。
どんな種類の概念があるのか、どんな種類の関係を許すのか、という「型」をあらかじめ決めておくことで、表記揺れを減らして、「関係性をきちんと整理した、推論しやすい知識構造」を作ることができます。

昔は、このグラフを手で作るのがとにかく大変で、あまり現実的じゃなかったんですが、いまはLLMを使ってテキストから「エンティティ」と「リレーション」を自動抽出できるようになってきました。これによって、ナレッジグラフを大規模に構築するのも、それなりに現実的になってきた、というわけですね。

記事の中では、Microsoftの「MS GraphRAG」も紹介されています。
これは、ナレッジグラフとRAGを組み合わせるだけじゃなくて、そのグラフを「コミュニティ」、つまりつながりの強い塊ごとに分けていって、そこから多段階の要約、いわゆるコミュニティレポートを作ります。そうすることで、「この本のテーマは何？」みたいな、かなり抽象的な質問にも、ベクトル検索なしで答えられる「グローバル検索」の機能を提供しているんですね。

実装の流れも、丁寧に説明されています。
テキストをまずチャンクに分割して、それぞれをLLMで解析して、エンティティとリレーションを抽出する。それを使ってグラフを構築する。さらに、そのグラフをコミュニティごとに分割して、階層的な要約を作っていく。こうしてインデックスを用意しておいて、実際の問い合わせのときには、「近いチャンクを拾うローカル検索」と、「グラフ構造と要約を使うグローバル検索」を使い分ける、というアーキテクチャになっています。
普通のRAGで物足りなくなってきた人には、かなり刺さる内容だと思います。

。。。。

三本目の記事です。
テーマは「Claude Mods」。Claude Codeの動きを拡張する、公式の拡張機能ですね。

このClaude Modsは、TypeScriptとかJavaScriptで書いた関数を通じて、単にツール呼び出しやプロンプトの中身を変えるだけじゃなくて、「画面レイアウト」まで差し替えられる、というのが大きな特徴です。
settings hookとか、MCPみたいな外側からの拡張と違って、Claude Code本体の中で動くので、エディタのペインを新しく追加したり、入力欄の見た目を装飾したり、もともと入っているコマンドを置き換えたり、といったことができます。

記事では、具体的な三つのmodが紹介されています。
ひとつ目が「prompt-rail」。これは、長く続いている会話の中で、自分が出した指示だけを「レール」みたいに一覧できる機能です。「あれ、さっき何頼んだっけ？」ってスクロールするの、結構大変だったりしますよね。それを、指示の流れが線路のように並ぶことで、一目で振り返れるようにする、というアイデアです。

ふたつ目が「md-prompt」。
これは、入力欄に書いたマークダウンを、その場で色付けしてくれるmodです。見出しやリストが、入力中からちゃんとマークダウンとしてハイライトされるので、「プロンプトも一種のドキュメント」としてきれいに書きたい人にはかなり便利そうです。

みっつ目が「qa-guide」。
これは、Claudeからの質問に対して、背景説明と「選択肢ごとの影響」を添えてくれるmodです。たとえば、「どのアーキテクチャにしますか？」と聞かれたときに、それぞれの選択肢がパフォーマンスや保守性にどう影響するのかを、あらかじめガイドとして出してくれるようなイメージですね。なので、単に答えを選ぶだけじゃなくて、「なぜそれを選ぶのか」が整理しやすくなります。

一方で、このmodsはかなり強い権限を持てます。
ユーザーと同じ権限でファイルの読み書きができたり、プロセスを起動したり、ネットワーク通信まで行えたりするので、セキュリティ面は要注意です。記事では、導入するときの安全な手順が、かなり詳しく説明されています。

具体的には、「claude plugin validate」というコマンドを使って、そのmodが「どのイベントをフックしているのか」とか、「どのAPIを使おうとしているのか」、たとえばファイルの読み書き、プロセスの起動、モデル呼び出しなどを事前に一覧で確認するやり方ですね。
これを挟むことで、「このmodって何ができて、どこまで触れるの？」というのを見える化してから導入できるので、安全性と便利さのバランスを取りやすくなる、という内容でした。

。。。。

四本目。
こちらは、画像生成AIを安全に使うための仕組みづくりについての記事です。キーワードは、「危ないプロンプトを外部モデルに送る前に止める」、そして「拒否されて課金だけされるリクエストを減らす」というところですね。

この仕組みでは、TypeSafeのJevというモデルと、CloudflareのClefというモデルを組み合わせて、二段構成で判定しています。
まず最初の段階では、Jevを使って「テキストだけ」を見ます。プロンプトの内容を、四十六問の「ディシジョンモデル」というかたちで細かく判定していって、一定のスコア以上、つまり危険度が高そうだと判断されたものは、ここで遮断してしまう。ここまでは、まだ画像は扱いません。

このテキストチェックを通過したリクエストだけ、次の段階に回します。
そこでCloudflareのClef Flashに対して、縮小した画像を最大四枚まで、解像度は百九十二ピクセルに落として送ります。あわせてプロンプトのテキストも渡して、「画像中心の十二問」で再度判定する、という流れになっています。この二回目のチェックは、「実際の画像内容」をしっかり見る段階ですね。

既存の対策としてよくあるのは、NGワードで一気にBANしたり、OpenAIのModeration APIをそのまま使ったり、あるいはブラウザ側でNSFWJSを動かしたり、というやり方です。でも記事では、そういう方法は精度が足りなかったり、「どこまでNGか」を外部サービス側の基準に委ねることになってしまったり、クライアント側の負荷が大きかったりといった理由で、採用していません。

その代わりに、自分たちのサービスに合わせて「ルール」と「しきい値」を細かく調整できるディシジョンモデルを選んでいる。ここがポイントになっています。
Jevはテキスト読解が得意なので、プロンプトのニュアンスをちゃんと汲み取って判定してくれる。一方で、Clefは画像の情報が入ってくると精度がぐっと上がる。特にGrokみたいなモデルとの相性や特性の差も意識しながら、それぞれの得意分野を生かすかたちで組み合わせているそうです。

さらに、ただ二つのモデルをつなぐだけじゃなくて、「どんな質問を投げるか」というプロンプト設計や、スコアの計算方法、キャッシュ戦略や画像の縮小処理まで工夫することで、コストを抑えつつ、誤検知、いわゆる誤爆もコントロールしながら、NSFW検知の性能を高めている。
単なるモデレーション機能というより、「安全性とコスト、ユーザー体験の三つをどうバランスさせるか」という実践的な話としてまとまっていました。

。。。。

そして五本目。
最後は、「AIエージェント時代のUI設計」をテーマにしたオピニオン記事です。これはけっこう思想寄りなんですが、実例もあって読みごたえがあります。

AIに「もっと見やすくしてください」とか、「いい感じのUIにしてください」といった、ふんわりした指示だけ出していると、どうしても場当たり的なUI修正になりがちだ、という問題意識から話が始まります。ボタンがちょっと大きくなるとか、色が変わるだけで、本質的には使いやすくなっていない、みたいなやつですね。

そこで筆者は、『オブジェクト指向UIデザイン』という考え方をベースにして、「AIに渡すための設計原則」をちゃんと手順化しようとしています。
その原則として挙げられているのが、「名詞から動詞へ」「オブジェクトが見えて直接触れる」「一覧と詳細の対応」「モードレス」の四つです。
これを、Claude Codeが参照できる「Agent Skill」としてまとめておいて、UIを生成するときに必ず見るチェックリスト、みたいな形にしているんですね。

記事では、社内文書検索システムの管理画面を題材にして、「Skillあり」と「Skillなし」の二パターンで、HTMLのUIをAIに生成させて比較しています。結果として、どちらのUIも「できること」、つまり機能の数自体はほとんど変わらなかったそうです。ただ、Skillを使ったほうでは、メニュー構造が「文書」や「利用者グループ」といった対象ごとに整理されていたり、「一覧を開いたまま詳細を切り替えられる」ようになっていたりして、画面構造が、よりオブジェクト中心でモードレスな方向にそろってきた、というのが面白いポイントです。

筆者は、「すべてのUIをオブジェクト指向UIにすべきだ」とは言っていません。
ただ、対象が複数あって、あちこち行ったり来たりするような管理画面では、次の三つの問いを意識するといいと提案しています。
ひとつ目は、「最初に並ぶのは『もの』か『やること』か」。
ふたつ目は、「対象を選んだあとにアクションが出てくるか」。
みっつ目は、「作業中でも、他の対象へ自由に移れるか」。

この三つの視点で、「タスク偏重」のUIになっていないか見直してみる。さらに、AIが自動生成した画面をレビューするときにも、この軸をチェックリストとして使うといいよ、という話で締めくくられています。エージェントにUIをどんどん作らせる時代に、人間側が持っておきたい「物差し」をどう用意するか、という問題提起でもありますね。

。。。。

というわけで、きょうのzenncastでは、
一つ目に、人間の役割を「評価指標と改善ループの設計」として捉え直した、AI時代の開発フローの話。
二つ目に、ナレッジグラフやMS GraphRAGで、従来のRAGの限界を越えようというGraphRAGのティップス。
三つ目に、Claude Modsで、ツール呼び出しだけじゃなく画面レイアウトまで拡張できる、開発体験のカスタマイズ。
四つ目に、JevとClefを組み合わせて、NSFWな画像生成リクエストを「送る前に止める」安全設計の実践。
五つ目に、オブジェクト指向UIデザインをAgent Skillとして組み込んで、AIエージェント時代のUIをどうレビューするかというオピニオン。

この五本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容はショーノートにまとめてありますので、ぜひそちらから原文をチェックしてみてください。
そして、この番組の感想や、「こういうテーマ取り上げてほしい」なんてリクエストも、いつでも募集しています。AIまわりで気になっている疑問なんかも、ぜひ送ってください。

それでは、きょうはこのへんで。
お相手はマイクでした。また次回のzenncastでお会いしましょう。お仕事や勉強、今日もゆるっと頑張っていきましょう。