どうもー、おはようございます。マイクです。「zenncast」朝いちばんの時間、ただいま六月二十五日、木曜日の朝七時をちょうどまわったところです。
この番組では、エンジニアやクリエイターのみなさんに向けて、Zennに上がっているトレンドの記事を、ラジオ感覚でゆるっと、でも中身はぎゅっと詰めてお届けしていきます。今日も、最新の技術ネタや開発の知見をまとめてチェックしていきましょう。
今日は、ぜんぶで五本の記事を紹介していきます。ボリュームたっぷりなので、コーヒーでも飲みながら耳だけ貸してください。
まず一つ目。
テーマは「AI時代の社内ナレッジ管理をどう整えるか」というお話で、Google Cloud が提案している「OKF」というフォーマットが出てきます。
この OKF というのは何かというと、社内のドキュメントを「AIにも人にも扱いやすい形でそろえましょう」というルールなんですね。
やることはすごくシンプルで、Markdownファイルの先頭に、YAML形式のメタデータをちょこっと書き足すだけ。いわゆるフロントマターです。
しかも、全ファイルで必須なのは「タイプ」、つまり「これは仕様書です」とか「これは手順書です」といった種類を示す `type` くらいに絞っていて、あとはフォルダ構成もかなり自由。ガチガチの情報システム部ルール、みたいな感じにはしていません。
おもしろいのは、「ファイルパスそのものを、概念のIDとして扱う」という考え方です。
たとえば「product/feature-a/spec.md」みたいなパスが、そのまま「feature-a の仕様」という概念のIDになる。で、そのID同士をリンクでつないでいくことで、ナレッジ全体がグラフ構造みたいに見えてくるんですね。
この記事では、架空の企業のナレッジをこの OKF 形式で実際に組んでみて、そのリンク構造を可視化したり、複数のファイルをまたぎ読みしながら答えてくれる Q&A エージェントのデモも紹介されています。
完全自動でナレッジをつくると、「質の低いドキュメントが量産される」「書き方が人ごとにバラバラになって、後からAIも人も読みにくい」といった問題が起きがちですよね。
そこで筆者が強調しているのが、「人間とAIの両方が扱いやすい、最低限の共通フォーマットだけは決めておこう」という考え方。
書き方を細かく縛るのではなくて、
・どのファイルにも `type` は必ず入れよう
・パスをIDとみなしてリンクでちゃんとつなごう
といった、すごくコアな決まりだけを整える。そのぐらいライトなルールでも、AIがまたぎ読みしやすい社内ナレッジの土台はつくれるんだ、という事例になっています。
これから「社内WikiをAI対応させたいな」と考えているチームには、かなり参考になる内容でした。
。。.。。.。。.
続いて二つ目。
こちらは「AI駆動開発をチーム全体のしくみに落とし込んだ話」です。
もともと筆者のチームでは、各メンバーがそれぞれ好きなようにAIを使って開発していたそうなんですが、その結果、プロンプトの質や開発スピードに結構な差が出てしまっていたそうです。
さらに、人間が「AIの出力をレビューして、ダメならまたプロンプトを調整して……」という、いわば「ループを回す係」になっていたことも大きな課題だったと。
そこで考えたのが、調査・インタビュー・計画・実装・レビューまでを一本の流れとして自動で回してくれる、`interview-dev-loop` という共通スキルを作って、チーム全員で共通利用しよう、というアプローチです。
このスキルを使うと、人間がやることはかなりシンプルになります。
・AIからの質問に答える
・AIが作った計画を承認する
・仕上がったものの動作確認をする
基本的にはこの三つに集中して、それ以外の細かい部分、たとえば仕様の肉付けや、インタビュー結果を踏まえたタスク分解、レビュー用の観点出し、といったところは、エージェントが自律的にループを回すようになっているんですね。
そのために工夫したポイントもいろいろ紹介されています。
たとえば、曖昧な点をなんでもAIに質問させるのではなくて、「実装方針やテスト内容が変わりうるような重要なあいまいさ」だけを質問の対象に絞ることで、やり取りを減らしつつ質は落とさないようにしています。
また、実装そのものは別のエージェントに任せて、「このループでは何を作るか・どう確かめるか」という思考側だけを扱うようにすることで、前提をすっきり切り分けているのもポイントです。
効果のところでは、導入前後でプルリクエストのレビューコメントを比較していて、変更行数は増えているのに、行数あたりの指摘コメントは大きく減少した、というデータも紹介されています。
つまり、PRが出てくる前の段階で問題をだいぶ吸収できるようになってきた、ということですね。
最終的に筆者は、この `interview-dev-loop` を「人間の時間を『何を作るか』『どう確かめるか』『ユーザーにとって何が正しいか』といった本質的な判断に振り向けるための開発ループ」だと位置づけています。
この仕組みの汎用版はGitHubで公開されていて、今後はさらに前後の工程、たとえば要件の整理からリリース後の振り返りまで含めた、自動ループへの拡張にも取り組んでいるそうです。
チームでAI開発を標準化したい方には、かなり刺さる内容だと思います。
。。.。。.。。.
三つ目。
ここからは、ローカルで動く小型LLMを「問い合わせラベル分類」に特化させるファインチューニングのお話です。
題材になっているのは、カスタマーサポートの問い合わせに、自動でラベルを振っていくタスク。
これを、Appleの MLX と LoRA を使って、Mac上で動く小さめのモデル `gemma-3n` にファインチューニングしていく手順が、一通り実践されています。
教師データはおよそ百八十件程度からスタートして、SFT、いわゆる教師ありファインチューニングをかけていく流れです。
データづくりが工夫されていて、まずは少量を人手で丁寧にラベリングします。
そのうえで、その小さな手作業データをもとに、Claude などの大規模モデルを使って合成データを一気に増やしていきます。
ただ増やすだけではなく、別のLLMを「品質ゲート」として使って、誤ったラベルや重複したデータを自動で弾いているのがポイントです。
データ分割も考え抜かれていて、train と valid は合成データが中心。一方で test データは人手で作ったものだけに絞っています。
そうすることで、評価に使うデータに「teacher モデルの癖」が混ざらないようにして、本当にモデル自身の実力を測れるようにしているんですね。
LoRA の話も具体的に出てきます。
LoRA では、ベースモデルの重みそのものは変えずに、小さな行列A・Bだけを追加で学習していきます。
今回は、そのLoRAをアテンション周りの層に限定して差し込むことで、追加されるパラメータは全体の〇・一パーセント未満という、ごくわずかな増加に抑えながら、分類タスクに最適化しているそうです。
学習の結果、精度はかなり劇的に改善していて、accuracy が七五パーセントから一〇〇パーセントまで向上。
ラベルにない値を出してしまうような「ラベル外出力」も発生せず、さらに混同行列やラベル別の F1 スコアなどもちゃんと確認して、どのラベルで強い・弱いといった挙動も丁寧にチェックしています。
学習し終えたLoRAは、そのままMLXのサーバ機能、つまりOpenAI互換のAPIとして立ち上げて、HTTP経由で問い合わせ分類に使えるようにしています。
さらに一歩進めて、そのLoRAをベースモデルに「融合」してしまって、GGUF形式に変換。
これを llama.cpp ベースの「LLM for Unity」に読み込ませることで、iPhone上のUnityアプリでも、同じ分類モデルをそのまま動かしています。
これによって、「カスタマーサポートのラベル付け」みたいな狭いタスクであれば、クラウドに繋がなくても、ローカルの小さなLLMで、高速かつ低レイテンシに、十分実用的な性能が出せる、ということを実証しているわけですね。
オンデバイス推論や、UnityアプリでのLLM活用に興味がある方には、かなり実践的な内容です。
。。.。。.。。.
四つ目の記事は、ちょっと変わり種の事例です。
Tauri の内部ライブラリとして知られている wry と tao を、ふつうのデスクトップGUIアプリではなく、「GUIを持たないCLIツールの実行エンジン」として流用した、というお話。
筆者が作ったのは、Mermaid 記法で書かれたコードブロックを SVG に変換するための Pandoc フィルター「gazu」と、その中核となる Mermaid → SVG 変換エンジン「sekien」。どちらも Rust で実装されています。
通常、Mermaid のレンダリングにはChromiumを同梱したツールを使うことが多いですが、それだとどうしても重くて、起動も遅くなってしまいますよね。
この事例では、Tauriの部品である wry・tao をうまく使うことで、Chromiumを丸ごと抱え込まずに、ブラウザエンジン相当の機能だけを軽量に使っているのがポイントです。
ただし、Mermaid はブラウザ向けのJavaScriptを前提にしたツールなので、完全な「ヘッドレス」実行は難しいところがあります。
そこで Linux では、Xvfb を内部から起動して仮想ディスプレイを用意し、macOS と Windows では画面の外側に小さなウィンドウを配置してしまうことで、ユーザーからは見えないけれど、内部的にはちゃんとウィンドウが存在する状態にしているんですね。
見かけ上はヘッドレスに動いているように見える、というわけです。
さらに、GPU関連の警告やアクセシビリティ周りの警告がログに出てノイズにならないように、各種環境変数を設定して抑制している、といった細かいノウハウも紹介されています。
筆者が強調しているのは、この方法が万能というわけではなく、Mermaid というツールが
・テキストを入力にとる
・テキスト、つまりSVGを出力する
・ブラウザ向けJavaScriptが必須
という三つの条件をすべて満たしているからこそ、うまくハマったニッチな解決策だ、という点です。
それでも、「Chromiumを同梱したくはないけれど、ブラウザエンジンの力は借りたい」という、ちょっと困ったニーズに対して、wry・tao をCLIツールのエンジンとして流用する、というのはかなりおもしろいアプローチですよね。
静的サイト生成や技術ドキュメントのビルドを高速化したい方には、発想のヒントになりそうです。
。。.。。.。。.
そして最後、五つ目の記事。
これは日本語や中国語の文字列を、「見た目の文字」ではなく、発音や読み方の近さで比べられる編集距離ライブラリ、`mòine` を作った話です。
ふつうのレーベンシュタイン距離だと、「酒」とカタカナの「サケ」、あるいは「きめつのやいば」と「鬼滅の刃」みたいなペアは、まったく違う文字列として扱われるので、距離が大きくなってしまいます。
でも、実際にはどちらも読みは同じですよね。
`mòine` では、こういった問題に対して、「読みの候補をグラフ状、いわゆるラティス構造として表現して、その上で編集距離を計算する」という方法を取っています。
これによって、発音が同じなら距離ゼロ、つまり「同じもの」として扱えるようになるわけです。
ライブラリ自体は Python と Rust の両方から利用できるようになっていて、日本語に関しては UniDic 版と SudachiDict 版の辞書を選べるようになっています。
SudachiDict 版は最新の固有名詞に強いのが特徴で、「呪術廻戦」と「ジュジュツカイセン」といった、新しめの作品名でも、きちんと同じ読みだと認識してくれます。
用途として挙げられているのは、検索クエリの誤入力から「これのことかな？」という候補を出してあげる処理だったり、固有名詞の表記ゆれを読みベースで正規化してあげるような処理です。
普通の文字ベースの距離だと拾いきれない「読みが近いもの」を見つけたいときに、とても役立ちそうなライブラリですね。
日本語・中国語圏向けの検索や、音声入力との連携など、「読み」を扱うシステムとの相性も良さそうです。
。。.。。.。。.
というわけで、今日の zenncast は、全部で五本の記事を駆け足でご紹介しました。
まずは、Markdownの先頭にYAMLメタデータを追加するだけで、AIにも人にも扱いやすい社内ナレッジを作れる「OKF」というフォーマットの話。
次に、調査からレビューまでを一つの自動ループにまとめた `interview-dev-loop` で、チーム全体のAI駆動開発を底上げした取り組み。
三つ目は、Apple MLX と LoRA を使って、小型LLM `gemma-3n` をカスタマーサポートのラベル分類に特化させ、Mac や iPhone 上でサクサク動かしてしまう実践記録。
四つ目は、Tauri の wry・tao をGUIなしのCLIエンジンとして流用して、Mermaid → SVG を高速・軽量にこなす Rust 製ツールの事例。
そして最後が、日本語や中国語の文字列を「読み方の近さ」で比較できる編集距離ライブラリ `mòine` のお話でした。
気になった記事があれば、詳しい内容やリンクは番組のショーノートにまとめてありますので、ぜひそちらから元の記事もチェックしてみてください。
この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストもいつでも募集しています。
開発で悩んでいることや、AI活用の工夫、最近読んでよかった技術記事なんかも、ぜひシェアしてください。
それでは、そろそろお時間です。
今日も一日、いいコードといいアウトプットに恵まれますように。
お相手はマイクでした。また次回の zenncast でお会いしましょう。