どうも、マイクです。おはようございます。
六月十九日、金曜日の朝七時を回りました。今朝も「zenncast」、張り切ってお届けしていきます。

今日は、テック好き・プロダクト好きのみなさんに刺さりそうな、Zennのトレンド記事を五本まとめてご紹介していきますよ。AIエージェントからハッカソンのアイデア、スライド作りの裏技、Unicodeの深〜い話、そして最新RAG論文の実践ネタまで、幅広くいきますので、通勤・通学のお供にぜひ最後までお付き合いください。

さて、きょう紹介する記事は、ぜんぶで五本です。
一つずつ、じっくりいきましょう。

まず一つ目。
テーマは「マルチエージェント時代の土台になるかもしれない、Databricks発のオープンソース『Omnigent』」というお話です。

Omnigentは、「メタハーネス」と呼ばれている仕組みで、Claude Codeとか、Codex、自作のエージェントたち、バラバラなAIエージェントをひとつの土台からまとめて呼び出したり、組み合わせたり、制御したり、さらにチームで共有したりできるようにするためのフレームワークなんですね。

使い方としては、YAMLで「どのハーネスを使うのか」「どのモデルをつなぐのか」「そのエージェントにどんな役割を与えるのか」といった設定を書いていきます。さらにポリシー設定で、ファイルシステムやネットワークへのアクセスをどこまで許すか、コストの上限、人間による承認フローが必要かどうか、そういった制御も細かく管理できるようになっています。

記事の中では、WSL、いわゆるWindows Subsystem for Linuxの上にOmnigentをインストールして、Claude ProとCodexを接続し、サンプルエージェントの「Debby」を動かしています。
このDebbyに質問を投げると、裏側ではClaudeとCodexが同時に回答を作って、それをDebbyが比較して要約してくれる、という動きをしてくれます。さらに「スラッシュディベート」というコマンドを使うと、ClaudeとCodexがお互いの回答を批評し合って、その議論を踏まえた改善版の回答を自動で生成する、そんなちょっと面白い体験も紹介されています。

筆者は、このDebbyそのものがすごいというよりも、「Debbyはあくまで入口で、本質は、自分たちの業務用にマルチエージェント構成を簡単に組める点」にある、と強調しています。
たとえばDatabricksが、複数クラウドに散らばったデータやワークロードの複雑さをうまく隠して、ユーザーが本当にやりたい分析や機械学習に集中できるようにする「抽象化レイヤー」になっているのと同じように、Omnigentは、いろんなエージェントやAPI、接続方式のごちゃごちゃした複雑さを吸収してくれる、そんなメタな土台だ、という位置づけなんですね。

今後、MCPとかAツーエーのような共通プロトコルで、エージェント同士やツールとの通信がどんどん標準化されていく一方で、その運用や制御、共有の仕組みは、むしろますます複雑になっていくと見られています。
そういう未来を見据えたときに、「エージェントの実行・制御・共有を上から束ねるメタハーネス」という考え方が、近未来のAIエージェント活用のカギになるんじゃないか。筆者はそんな風にまとめていて、Omnigentがその先駆け的な存在になるだろう、と結んでいます。

エージェントを増やす前に、その“土台”をどうするか、という目線で読み応えのある記事でした。

。。。。

続いて二つ目。
こちらは、ちょっとオピニオン寄りのサービス紹介の記事です。テーマは「気象情報とバーチャル試着を掛け合わせた服装予報アプリ『FitCast』」。

筆者はとあるハッカソンで、毎朝とか旅行前に誰もが感じる「今日なに着たらいいかわからない」という、めちゃくちゃ普遍的な悩みに対して、「FitCast」というアプリを開発して賞を受けたそうです。
このアプリの特徴は、二つのポイントがありまして、ひとつは天気に合った服装を自動で提案してくれること。もうひとつが、その服を着た自分の姿を、AIでバーチャル試着して見せてくれることです。単に「長袖がいいですよ」じゃなくて、「自分が着たらこう見えますよ」と視覚的に見せてくれるので、朝の意思決定がすごくしやすくなるアイデアですね。

実装の構成としては、フロントエンドをリアクトネイティブ、バックエンドをノードジェイエスで分けています。ユーザーが都市名を入力すると、その場所の天気情報を取得して、シンプルなルールベースで「カジュアル」「アウター必要」「フォーマル寄り」などの服装カテゴリを決める仕組み。
そのうえで、ユーザーの顔写真や体型情報などをもとに、「ユーカム」というAPIを使ってバーチャル試着の画像を生成します。

開発の過程では、APIごとに仕様が違ったり、画像のサイズやフォーマットの要件が細かかったり、処理が終わるまでポーリングで待たなきゃいけなかったりと、技術的な課題が山ほどあったそうです。
そこで筆者は、「とにかく処理の役割をしっかり分ける」ことを意識して、天気取得、服装判定、画像生成、それぞれをきちんとモジュール化して、どこで問題が起きているのかデバッグしやすいように設計した、と振り返っています。

メッセージとして強調されているのは、「ただAPIを呼ぶだけでは価値にはならない」ということ。
ハッカソンのような場では特に、「革新性」と「本当に存在する悩み」、この二つを両立させるコンセプト設計が大事だとしています。
そのためには、まず「自分や身の回りの人が、実際になにに困っているのか」からスタートして、完璧じゃなくてもいいから、とにかくプロトタイプとして形にしてみる。それが結果的にアイデアを育てる一番の近道だ、と筆者は主張しています。

ハッカソンに出てみたい方や、新規プロダクトのアイデアを考えたい方には、かなり刺さる内容だと思います。

。。。。

三つ目の記事です。
こちらは、「AIを使ったスライド作成の実践的なコツ」をまとめたTips系の記事になっています。

話のポイントは、「いきなりAIに『スライド作って』と丸投げしない」というところです。
そうではなくて、「構成」「見た目」「仕上げ」という三つのフェーズに分けて、それぞれに合ったAIの役割を割り振ることで、社内でちゃんと使えるレベルの資料を、安定した品質で作れるようにしよう、という提案になっています。

まず最初のフェーズは「構成」。ここでは、Codexに対して、スライドの目的、想定している読者、伝えたいメッセージ、これらをしっかり入力したうえで、「五枚構成のアウトラインを作って」とお願いする、という流れです。
Codexには、各ページのタイトルと、そのページで伝えるべき一番大事なメッセージを出してもらいます。それを人間がチェックして、「この順番で伝えるので良いか」「抜けている論点がないか」を確認しながら、構成を固めていきます。

次のフェーズは「見た目」。
ここがちょっと工夫ポイントで、まず社内で使っているデザインルールを、マークダウン形式で「プレゼンテーション・スタイル・ガイド」としてまとめ直すんですね。
色づかい、フォント、余白の取り方、レイアウトのパターン、避けたい表現やNGワードなど、社内ルールをテキストとして整理しておきます。
そのうえで、このスタイルガイドをもとに、「画像生成AIに渡すプロンプトを、Codexに書かせる」という流れをとっています。

このプロンプトを、GPTイメージツーのような画像生成モデルに渡して、五枚分のスライドのサムネイルを一覧で生成してもらう。ここでは、文字の正確さはそこまで気にせずに、「全体のトーンやレイアウト、雰囲気がイメージとあっているか」を早い段階で確認することを重視しています。

最後のフェーズが「仕上げ」です。
Codexのプレゼンテーション・スキルを使って、「決めたスライド構成」「スタイルガイドのマークダウン」「画像イメージの情報」、この三つを入力にして、編集可能なパワーポイントファイルを生成させます。
最終的には、人間がメッセージの細かい表現や、レイアウトの微調整をおこなって完成させる、という形ですね。

こうやって役割分担をはっきりさせることで、社内のPoC説明用スライドとか、勉強会の資料とかにも、そのまま流用しやすくなるし、「誰が作っても大きくブレないクオリティ」を目指せる、というのがこの記事のポイントになっています。

「AIに全部やらせる」ではなく、「AIをうまく“チームメイト”として使う」という感じのワークフローで、すぐ実践できそうなTipsがまとまっています。

。。。。

四つ目の記事です。
ここからは、ちょっとマニアックで面白い話題。「JavaScriptで日本語の識別子に『中点・』を使ったら、Node.jsでは動くのにDenoではエラーになった」という事例から、Unicodeの歴史にまで踏み込んで解説している記事です。

まず前提として、JavaScriptで変数名や関数名などの識別子に使える文字は、Unicodeで定義されている「アイディー・スタート」と「アイディー・コンティニュー」というカテゴリーに基づいて決まっています。
日本語のひらがなやカタカナも、この分類に入っているので識別子に使えるんですが、「中点・」については、ちょっと特殊な歴史があるんですね。

もともと、「中点・」はIDコンティニューの方に入っていて、識別子の途中に使える扱いでした。ところが、ユニコードのバージョン四点一のタイミングで、誤ってこのカテゴリから外されてしまいます。
そしてなんと、その誤りが十八年間も放置されたままになって、ようやくユニコード十五点一で復帰する、という、かなり珍しい経緯をたどっています。

これが何を引き起こすかというと、TypeScriptやJavaScriptランタイムが、どのバージョンのユニコードに対応しているかによって、「中点・を識別子に使えるかどうか」がバラバラになるんですね。
TypeScriptはバージョン五点五からユニコード十五点一に対応したので、「中点・」を識別子に使えるようになりました。
Node.jsやブラウザも、それぞれ内部で使っているUnicodeテーブルが新しければ使えるし、古ければ使えない、という状態になっています。

記事のケースでは、新しめのNode.jsでは「中点・」入りの識別子が普通に動くのに、Denoではエラーになる、という現象が起きました。
調べていくと、Denoが依存していた「ユニコード・アイディー・スタート」というライブラリが古くて、さらにそのライブラリ側のパッチで、「中点・」をわざわざ除外していた、ということがわかったそうです。
最終的には、このライブラリのバージョンを上げるだけで問題は解決した、というオチなんですが、たどり着くまでがなかなか大変だったと。

筆者は、こういう歴史的なUnicodeまわりの事情を、人力だけで追いかけるのは本当に骨が折れるけれども、AIをうまく使って調査を進めたことで、短時間で原因の特定と修正案にたどり着けたと振り返っています。
「AIは、複雑な仕様や長い歴史が絡んでくるような調査作業を助けてくれる、実用的な道具になりつつある」という実感を綴っていて、仕様を追いかけるエンジニアにとって心強い話になっています。

JavaScriptで日本語の識別子を使っている方や、Deno／Nodeの挙動差に悩んだ経験がある方には、かなり興味深い内容だと思います。

。。。。

そして最後、五つ目の記事です。
こちらもTips系で、テーマは「State-Aware RAG」という論文を、AWS環境に実装してみた話です。

論文「ステートアウェア・ラグ」は、RAGでマルチホップ質問、つまり「いくつかの情報をまたいで考えないと答えにたどり着けない質問」に答えるときの工夫として、「検索結果をそのまま積み上げない」というアプローチを提案しています。
代わりに、「ワーキングメモリ」というメモ帳のようなものを用意して、そこに要点だけを整理しながら推論していく仕組みです。

基本的な構成としては、RetrieverとGeneratorは既存のモデルをそのまま使い、Extractorという役割だけを学習して、「抽出」「要約」「追記」の三つの操作でワーキングメモリを管理します。
つまり、Retrieverでドキュメントを取ってきて、Extractorが「関連／非関連」を判断しつつ、関連部分だけを抜き出してメモ帳に書き込んでいく。Generatorは、そのメモ帳を見ながら最終的な回答を組み立てる、というイメージですね。

記事の筆者は、この仕組みを論文通りに再実装したわけではなくて、Extractorをわざわざ学習し直すのをやめて、その役割をClaude Sonnet四点五にやってもらっています。
具体的には、Retriever、Generator、Judge、全部をClaude Sonnet四点五でまかなって、Retriver部分だけはAmazon Bedrock Knowledge Basesを使う構成にしています。
埋め込みモデルにはTitanブイツー、ベクトルの保存先にはAmazon Sスリー・ベクターズを選んで、すべてAWS上で完結する形ですね。

実装のポイントとしては、論文の付録に載っている「Extractプロンプト」を流用していて、各ドキュメントごとに「この質問に関連しているかどうか」と、もし関連していれば「どの部分が重要か」をClaudeに判定させたうえで、ワーキングメモリを更新しています。
さらに、推論のスタイルとして、ふたつのプランナーモードを用意しています。
ひとつは、ソクラテス式のAワンプラスAファイブ、もうひとつは、AワンからAファイブまでと共有メモリを組み合わせたMCTSモード。これらをBedrockのConverse API経由で動かす構成になっているそうです。

評価としては、小さめのマルチホップ質問や、Claudeの事前知識だけでは解けないような架空のエンティティを使ったQA、それからBamboogleベンチマークの一部でテストしています。
すると、ワーキングメモリをオンにしたときには「百パーセント正解」だったのに、メモリ更新やExtractorの処理をオフにすると「ゼロパーセントに落ちてしまう」というケースが出てきた、という結果が報告されています。
これは、論文の中で主張されていた、「Extractorを外すと性能が崩壊する」という話と、ほぼそのまま対応する挙動になっていて、「AWS環境で、Claudeを使った場合でも同じ傾向が確認できたよ」という再現報告になっていました。

RAGを実務で使っていて、「マルチホップの質問が苦手だな」と感じている方や、「とりあえず検索結果を全部突っ込んでるけど、もっと賢くまとめたい」という方には、かなりヒントになる内容だと思います。

。。。。

ということで、きょうの「zenncast」でご紹介したのは、
まず一つ目、Databricks発のメタハーネス「Omnigent」で、マルチエージェントをひとまとめに管理するという話。
二つ目が、天気とバーチャル試着を組み合わせた服装予報アプリ「FitCast」で、「本当にある悩み」からアイデアを起こそう、というハッカソン体験談。
三つ目は、構成・見た目・仕上げにAIの役割を分担させて、安定して使えるスライドを作るためのワークフロー。
四つ目が、「中点・」ひとつで挙動が変わる、Unicodeの歴史とNode.js／Denoの違いをAIで調査したお話。
そして最後五つ目が、State-Aware RAGをClaudeとAWS上に移植して、ワーキングメモリの効果を検証したTips記事でした。

気になる記事があった方は、ぜひショーノートをチェックして、元の記事もじっくり読んでみてください。テクニカルな部分や、実際のプロンプトの書き方なんかは、そちらのほうが詳しく載っています。

「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」というリクエストも大歓迎です。
日々の開発での気づきや、この記事面白かったよ、なんて一言でもかまいませんので、ぜひ気軽に送ってください。

それでは、そろそろお時間です。
きょうも良い一日をお過ごしください。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。