おはようございます。マイクです。
朝七時を回りました。二千二十六年八月二十日、木曜日の朝です。
今日も「zenncast」、ゆるっと始めていきましょう。
この番組では、Zennで話題になっているトレンド記事を、ラジオ感覚で一緒にキャッチアップしていきます。通勤通学の準備中の方も、これからお仕事という方も、コーヒー片手にお付き合いください。
さて、きょう紹介する記事は、ぜんぶで五本です。
フロンティアモデルに頼り切らないローカルLLMの話から、機密データをAIに見せない工夫、AIエージェントにUI実装を任せるための仕組みづくり、三千七百以上のフォントを一個に詰め込む変態的な実験、そしてAIエージェントの「行動履歴」を使った新しいポリシー言語まで、かなり濃いラインナップになっています。
それでは一つ目から、さっそくいきましょう。
まず一つ目は、「フロンティアモデルに仕事道具を握られないために、ローカルLLMをどう活かすか」という実験的な記事です。
オープンエーアイとかAnthropicみたいな、いわゆるフロンティアモデルって、性能はものすごく高いんですけど、その代わりにレート制限だったり料金だったり、ある日突然の方針変更だったりと、「自分の仕事道具を誰かに握られている」不安がどうしてもつきまといますよね。
そこで筆者は、「誰にも取り上げられない道具」として、ローカルで動かせるLLMに注目しています。
題材にしているのは、約九万行もあるTypeScript製のCLIツールに機能追加する、というかなり骨太なタスクです。ここで「TAKT」というマルチエージェントのオーケストレータを使って、実装担当、レビュー担当、補佐役、みたいな役割を持ったモデルをいろいろな組み合わせで編成して試しています。
品質の評価には、二十四項目のチェックリストを用意して、それをGPTハイフンファイブ点シックスハイフンソルというモデルで、三回ずつ採点させるという、けっこうガチなやり方をしています。
その結果どうなったかというと、ディープシークブイフォー・フラッシュと、Gemmaフォーのサーティワンビー、この二つを中心にしたローカルLLMの編成が、「フロンティアモデル一発でコードを書かせる」パターン、つまりGPTファイブ点シックスソル一発よりも、むしろ高得点を出したんですね。
ポイントになったのは、「最初にちゃんと計画して境界ケースを洗い出す」「複数のエージェントでレビューと修正のループを回す」「決まったことを補佐役がちゃんと引き継ぐ」といった、チームとしての構造です。モデル一体あたりの賢さを、チーム編成で補っているイメージですね。
一方で、「全部の役割をソルで固める」という、フロンティアモデルフル投下の編成も試していて、これはわずかに最高品質を達成したものの、コストと時間がディープシーク編成の数倍以上かかってしまって、現実的には厳しい、という結論になっています。
筆者はここから、「コーディングみたいに正解を定義できて検証もしやすい領域では、最前線モデルだけがやる仕事って、いずれほとんどなくなるだろう」と述べています。
つまり、「安いモデルで実装とレビューをぐるぐる回して、本当に難しい判断だけ、強いモデルに少しだけやってもらう」──そういう構成のほうが、経済的にも、現場の運用としても理にかなっていると。
もちろん、量子化の精度とか、推論速度の問題はまだ残っているんですが、Gemmaフォーサーティワンビーとかディープシークブイフォーフラッシュ級のオープンウェイトモデルであれば、手元マシンや安価なクラウドでもなんとか再現可能です。
フロンティアAIへの依存を弱めつつ、それにかなり迫る品質を出せる──この「ローカルLLM＋マルチエージェント構成」の実験が示したのは、まさにそこだ、という内容でした。
「全部クラウドの超強いモデルに丸投げ」から、「自分たちで組み合わせて育てていく」方向へのシフトを感じる記事ですね。
。。。。
では二つ目。
こちらは、機密データを扱う現場で、「AIにデータ本体は絶対に読ませない」ための仕組みづくりを、かなり丁寧に設計している記事です。Claude Codeを使って分析コードを書かせたいんだけど、どうしてもAIに見せられない機密データがある、という状況を想定しています。
この人がとっている方針は、とにかく徹底していて、「データの中身は一切AIに読ませない。その代わり、スキーマ情報、つまり列名や型だけと、統計サマリだけをAIに渡す。コードの生成とテストはダミーデータで行って、実データでの実行は人間がやる」というやり方です。
機密データそのものは、リポジトリの外側、ホームディレクトリ配下の「ディーエス・datasets」という場所に一カ所に集約しておいて、どこからも勝手に参照されないようにします。
さらに、環境変数ファイル、ドットイーエヌブイで「ダミーデータを指すのか」「機密データを指すのか」を切り替えられるようにしておいて、開発中は基本ダミーを向かせておく。
Claude Codeの側では、「permissions」「sandbox」「hooks」という、三種類の仕組みを重ねがけして防御していきます。
permissionsで「このパスは読んじゃダメ」とかを明示的にdenyして、sandboxでOSレベルの権限を絞り込み、さらにhooksで「ドットイーエヌブイの中身」とか「ノートブックの出力」をチェックする。
これによって、
一つ目、ファイルを直接読む。
二つ目、BashやPython経由で読む。
三つ目、ノートブックの出力やログとして吐き出す。
四つ目、人間が間違ってコピペする。
五つ目、外部ツール、MCP経由で漏れる。
六つ目、IDE連携からにじみ出る。
こういった漏洩経路を、一個ずつ潰していくアプローチです。
さらに凝っているのが、フックの設計です。
たとえば、「ドットイーエヌブイがダミー以外を指している状態では、Bashの実行とかファイルの書き込み、編集を全部ブロックする」フックを入れたりします。
また、「出力済みの実データが残っていそうなJupyterノートブック、ドットアイピーワイエヌビーには、AIからアクセスさせない」ようにするフックとか。
加えて、「sandboxが無効になっていないか」「hooksが外されていないか」「deny設定が抜けていないか」「実行権限がいつのまにかゆるくなっていないか」といった、設定そのものの“劣化”を検出するスクリプトも用意していて、ユーザーが操作するときも、CIを回すときも、毎回チェックするようにしています。
ねらいは、「一つの防御ラインが破られても、ほかの層で止まるようにしておく」こと。
そのうえで、「AIには機密データをそもそも読ませない状態」を、できるだけ堅く維持したい、というわけですね。
「AIに見せちゃダメ」と口で言うだけじゃなくて、ツールの設定とディレクトリ構成、そしてCIのチェックまで含めて具体的に固めていく、そのプロセスがかなり参考になる内容でした。
。。。。
三つ目の記事は、「AIコーディングエージェントにUI実装を任せると、なんか微妙に違うUIになっちゃう問題」を、MOSHというサービスでどう改善していったか、という事例です。
「ちゃんとデザインシステムあるんだけどなあ…」という組織、けっこうあると思うんですが、それでもAIに任せると「これじゃない感」のある画面が出てくる。その背景を整理しています。
MOSHでは、デザインの定義と実装が、まずバラバラに管理されていました。
Figmaにデザインがあって、Notionにガイドラインがあって、実際の実装はStorybookにある、みたいな感じですね。
しかも、Reactへの移行時に、市販のUIライブラリをそのまま使った影響で、実装とデザインがどんどんズレていってしまい、AIエージェントからすると、「どれが本当の仕様なの？」と正しい情報にたどり着けない状況になっていたと。
そこでやったのが、「Storybookを真ん中に据えて、ここから全部に紐づける」という整理です。
具体的には、Storybookの各コンポーネントに、FigmaとNotionのURLをJSDocコメントとしてひも付けておきます。これによって、「このコンポーネントの元デザインどこ？」「対応するガイドラインどこ？」が、コードから一発で追えるようになります。
加えて、AIエージェント用に三種類のSkillを用意しています。
一つ目が「design-hyphen-context」、これは「どう実装すべきか」を文脈込みで教えるスキル。
二つ目が「design-hyphen-review」、これはデザインガイドラインから見たレビューを行うスキル。
三つ目が「design-hyphen-principles」で、より抽象的なデザイン原則を踏まえたアドバイスをするスキルです。
これらを通じて、AIが一貫した基準でUIを実装したりレビューしたりできるようにした、というわけですね。
さらに、「何回もレビューで指摘されるやつ」は、ESLintのカスタムルールにして、自動で弾くようにしています。
例えば、「このコンポーネントは必ずこのプロップとセットで使ってね」とか、「この色はこの場面では使っちゃダメ」といったルールを、コードレベルで機械的にチェックできるようにする。
それに加えて、一覧画面とかフォーム画面など、「よくある画面レイアウト」は、Plopというテンプレートツールを使って、「アドドットルート」コマンドでテンプレートから自動生成できるようにしています。
最初から「ガイドライン準拠の基本形」が出てくるので、そこからAIに肉付けさせれば、だいぶブレなくなりますよね。
こうした取り組みの結果、エージェントがワンショットで生成する画面の品質が底上げされて、「テンプレートを複製して」「実装して」「専用Skillでレビューする」という一連の流れで、安定したUIが作れるようになってきたそうです。
今後は、Figma側のデザインモックも、コード側を「正」として扱えるようにしていって、エンジニア以外の人でも、「こういう画面を作りたいんだよね」という意図を、コードに近い形で表現できる環境を目指している、という展望も語られていました。
デザインと実装とAIエージェント、その三者をどうつなぐか、という意味でとても示唆に富んだ内容です。
。。。。
四つ目は、ちょっと技術オタク心をくすぐる変態系の実験です。
Google Fontsにある三千七百九十三個のフォントを、TrueType Collection、通称TTCという形式で、「一つの巨大フォントファイルに全部ぶち込んでみた」という記事。
TTCって、複数フォントを一ファイルにまとめる形式なんですが、それを極限までやってみたらどうなるの？というお話です。
ツールとしては、PythonのfontToolsを使って、まずは素直に全部結合してみたところ、二つ大きな問題にぶつかります。
一つ目が、「TTCの中に、一個でも不正なフォント含まれていると、WindowsがそのTTC全体を無効扱いにしてしまう」という問題。
二つ目が、「TTCのサイズが、Windows側の二ギビバイトの制限を超えてしまう」というサイズ問題です。
これに対して記事の中では、まず「不正なフォント」の検出と修正を行っています。
具体的には、一部のフォントに足りていなかった識別情報、Nameアイディーサン、という項目を自動的に補ってあげることで、Windowsにとってちゃんとしたフォントとして認識できるようにする。
さらに、HarfBuzzのサブセット機能を使って、文字そのものは削らずに、ヒンティングなどの補助情報だけを大胆に削っていきます。
これによって、ファイルサイズを約一・九三ギビバイトまで圧縮することに成功しました。二ギビのラインぎりぎり、って感じですね。
この調整の結果、Windowsのフォントビューアーで、この巨大TTCをちゃんと開けるようになり、インストールもできたそうです。
実際にインストールすると、一気に二千フォント以上がドンと追加されるという、なかなか見たことのない光景になった、と書かれています。
フォント一覧を開いたらスクロールバーが豆粒みたいになってそうですよね。
ただし、ここには大きな落とし穴もあります。
Google Fontsに含まれるフォントは、SIL OFLやApache、Ubuntuライセンスなど、さまざまなライセンス条件が混ざっていて、「名前の付け方の制限」とか、「再配布するときの条件」がそれぞれ違います。
それらを全部きちんと満たしながら、「全部入りTTC」を配布するのは現実的ではない、ということで、このファイルそのものの公開は断念しています。
つまり、「やってみたけど、個人実験として楽しんでください」というスタンスですね。
また、「Google Fontsがこれ以上増えていくと、二ギビバイト制限を超えてしまうので、『Google Fonts全部入りTTC』が現実的に作れるのは、今がギリギリだ」という示唆も得られた、と締めくくられています。
技術的には面白いけれど、ライセンスとプラットフォーム制約の現実もしっかり見える、そんな実験でした。
。。。。
そして最後、五つ目の記事です。
これはDogwoodという、新しいポリシー言語の紹介で、ジャンルとしてはサービス紹介に近い内容ですね。
テーマは、「AIエージェントのツール呼び出しを、『過去の振る舞い』も踏まえて制御できるようにしよう」というものです。
もともと、Cedarというポリシー言語がありますが、これは基本的に「一回ごとのリクエスト」を見て、許可か拒否かを判断するスタイルです。
そのため、「承認されてから一時間以内だけ実行していいよ」とか、「機密情報を読んだ後は、外部への送信は禁止」とか、「送金は一時間に五回まで」といった、履歴や順序に依存する制約は、素直に表現しづらい、という課題がありました。
Dogwoodは、そこを拡張していこうという取り組みです。
Cedarとの互換性を維持しつつ、イベント履歴を参照できるtemporalな条件を追加しています。
キーワードとしては、「formerly」とか「count underscore within」といった条件が用意されていて、これを使うと、「過去に何が起きたか」「一定時間内に何回起きたか」を踏まえて、ポリシーを宣言的に書けるようになります。
記事では、Rustで実装された参照実装のCLIをローカルで動かしながら、「機密ドキュメントを読んだ後のメール送信を禁止する」ポリシーを、replayというコマンドで検証する例が紹介されています。
同じ「SendEmail」というリクエストでも、それ以前に「機密ドキュメント閲覧イベント」があるかどうかで、判定結果が変わる、という挙動を確認しています。
これによって、これまではアプリケーションコードの中に条件分岐として埋めがちだった「ガードレール」を、外出しのポリシーとして記述して、しかもツールで検証できる、というメリットがあると説明されています。
本番環境では、Amazon BedrockのAgentCore Gatewayのtemporal policiesとして利用できるようになっていて、既存のCedarポリシーとも共存可能です。
一方で、履歴を扱うぶん、認可の仕組みがステートフルになりますし、Cedarが強みとしていた形式検証ツールは、今のところtemporal条件には十分には効かないなど、制約もしっかり整理されています。
それでも、「AIエージェントが今まで何をしてきたか」を前提にして動きを制御する、というのは、これからのセキュリティやコンプライアンスにとって重要なピースになりそうだな、と感じる内容でした。
。。。。
ということで、きょうのzenncastは五本立てでお送りしました。
ローカルLLMを編成してフロンティアモデルに迫る実験の話。
機密データをAIにそもそも読ませないための、権限とディレクトリとCIを組み合わせたガチガチの仕組み。
AIコーディングエージェントにUIを任せても「これじゃないUI」にしないために、Storybook中心でデザイン情報を統合していく取り組み。
三千七百九十三フォントを一つに詰め込んだ、Google Fonts全部入りTTCの変態実験。
そして、AIエージェントの行動履歴まで考慮できる、新しいポリシー言語Dogwoodのお話。
どれも、実験と現実的な制約のせめぎ合い、みたいなテーマが共通していた気がします。
気になる記事があった方は、このあとショーノートから元の記事もチェックしてみてください。ここでは触れきれなかった細かい実装やコード例なんかも、そちらに載っています。
この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
通勤中の一言メモレベルでも大歓迎なので、ぜひ気軽に送ってください。
それでは、そろそろお時間です。
お相手はマイクでした。
きょうも一日、いい日になりますように。
また次回のzenncastでお会いしましょう。