どうも、こんばんは。マイクです。
今日も「zenncast」をお聴きいただきありがとうございます。

今日は二千二十六年八月十一日、火曜日の朝七時台。
この時間は、Zennで話題になっているトレンド記事を、ラジオ感覚でゆるっと、でも中身はしっかりめにご紹介していきます。

さて、きょうは全部で五本の記事を紹介していきます。
ローカルLLM、マイクロソフトのエージェントフレームワーク、業務スキル自動生成アプリ、AIへの指示の出し方、そしてエージェントプラグイン標準仕様と、わりと“AIエージェント寄り濃いめセット”になってます。コーヒーでも飲みながら、肩の力抜いて聞いてください。

まず一本目。
これはローカルLLMと Cloudflare OS を組み合わせた、かなりガチめの実験記、しかもオピニオン強めの体験談です。

筆者の方は、ビデオメモリ八ギガのゲーミングPCを使って、Cloudflare OS を完全ローカルで動かしています。そのうえで、Ollama と qwenスリーというモデルをつないで、「三目並べゲームを作らせて、実際に遊ばせてみる」というチャレンジをしたんですね。
結果として、五ラウンド遊ぶのに、なんと約一時間半かかってしまった、という経緯がかなり細かく追われています。

途中のトラブルも生々しくて、まずWindowsの起動スクリプトがうまく動かない問題があったり、Ollamaのデフォルトコンテキスト長が四千九十六トークンしかないことで、「長くなったシステムプロンプトが、何も言われずにちょっとずつ削られていって、モデルが徐々にポンコツ化していく罠」にハマったりします。
さらに、VRAMって公称で八ギガあっても、実効で使えるのはもう少し少ないんですよね。そこにコンテキスト拡張をかけていくと、一気にメモリ的に苦しくなってしまう。ローカル環境ならではのボトルネックが、具体的な数字や現象と一緒に描かれています。

一方で、Cloudflare OS 側の設計もかなりクセがあって面白いです。
Gadget と Gatekeeper という構成になっているんですが、「クライアントからの fetch は禁止」「Gadget は外部と直接通信できない」といった感じで、いわゆるふつうのWeb開発の常識を、あえて徹底的に封じています。Cloudflare OS専用の厳しい規約に従わせる設計になっているんですね。
その結果、エージェントは“ふつうに”やろうとするとすぐ失敗するんですが、その失敗を通して、「このOSはどういう前提で設計されているのか」が逆に浮き彫りになる、という視点です。

ただ一方で、失敗してもちゃんと止める仕組みはまだ弱い、とも指摘されています。
ループを外から検知して、中断する“ハーネス”的な部分が弱くて、「エージェントは、詰まっても自力で助けを呼べない部屋に閉じ込められているような状態」になりがちだと。
ローカル実行ならではのリソース制約と、Cloudflare OS独自の制約設計、その両方に真正面からぶつかった実験レポートになっています。
ローカルLLMで遊んでる方や、Cloudflare系のエージェント設計に興味ある人には、かなり刺さる内容だと思います。

。。.。。.。..

続いて二本目。
こちらは Microsoft Agent Framework を使って、「gptファイブ・ドット・シックス・ソル・リーズニング・ハイ」というモデルに、ユーザーが『ウルトラ』と入力したら、なんとかして『ソウル』と言わせたい、という、ちょっと遊び心のある検証記事です。
この“ウルトラ→ソウル”を実現するために、いろいろな実装テクニックを段階的に試していく構成になっています。

まずは、システムプロンプト、いわゆる Instructions でモデルの性格づけをして、「こういうときにはこう答えてね」と事前にクセを与えるやり方。
次に、ツール関数を用意して、ユーザーの意図を裏から教えるようなことをします。たとえば、「ユーザーがこう言ったときは本当はこうしてほしいんだよ」というのをツール経由で伝える、みたいな“裏口”ですね。

さらに、AIContextProvider という仕組みを使って、あとから指示やツールを追加で差し込むテクニックも紹介されています。
加えて、ファイルストアにあらかじめ「こうしなさい」という指令を書いておいて、それを file_access系のツールでモデルに読ませる、という“ファイルに仕込んだ指示”パターンも試しています。

それでもまだ足りないときには、CompletionMarkerLoopEvaluator と LoopAgent を使って、「ソウル」という単語がちゃんと出るまで、フィードバック付きで自動的に繰り返させる、というループ構成も出てきます。
いわば、プロンプトの工夫だけじゃなくて、ツール、文脈、ファイル、ループ制御、ありとあらゆる“チート”的なやり方で、モデルの出力を望みどおりに近づけていく、という実験です。

観測・可視化の部分もちゃんと押さえられていて、OpenTelemetry と Aspire を組み合わせて、プロンプトの内容やツール呼び出しの様子をトレースする方法も解説されています。
そのうえで、Foundry や Aspire と統合したホスティング構成、さらに Responses API や Chat Completion API 経由で外部に公開して、DevUI のチャット画面から挙動を確認する、という一連の流れも説明されています。

最後の仕上げとして、Agents Skill という仕組みを使います。
AgentInMemorySkillsSource と AgentInlineSkill を使って、「oracle」というスキルを定義しちゃうんですね。そのスキルのなかに、「ユーザーが『ウルトラ』と入力したときだけ、『ソウル』という答えを返す」というロジックを埋め込む。
ここまでくると、もはや“プロンプトで頑張る”というより、「エージェントフレームワーク側の多層構造を総動員して、挙動を完全にコントロールしている」感じです。

筆者はまとめとして、「Microsoft Agent Framework は、プロンプト、ツール、スキル、ファイル、ループ……と、いろんなレイヤーでAIの挙動を制御できる柔軟な枠組みだ」と評価しています。
単にモデルに投げるだけじゃなくて、フレームワークの設計全体で“どう鍛えるか”を考える、すごくいい教材になっている記事ですね。

。。.。。.。..

三本目。
ここからはサービス紹介系で、「Skill Recorder」というデスクトップアプリの話です。
これは、ローカルPC上で実際に自分が作業している様子と、そのときの音声実況をまとめて録画し、その内容から、AIエージェント用の業務スキル定義、いわゆる SKILLドットエムディー を自動生成してくれるツールになっています。

仕組みとしては、画面キャプチャとナレーションをローカルで処理して、その情報を GitHub Copilot に送ります。
Copilot側で、「この業務は何を目的にしているのか」という“業務の意図”と、「具体的にどういう手順でやっているのか」という“手順”を文章として整理してもらう、という流れですね。
これによって、めんどうだった業務の棚卸しや、「ちゃんとした手順書を作る作業」の負担を、かなりガツンと減らせるのがポイントです。

しかも、ただの座標クリック型のRPAみたいに、「この位置を押して、この位置を押して……」といった、一回きりのマクロを作るのではなくて、ghコマンドラインツールや Web API を呼び出すような、再利用性の高い“スキル”として出力できるのが特徴です。
つまり、「人間がやっていた定型業務を、そのままエージェントに引き継げる形で文章化するツール」として使える、と。

利用するためには、前提条件がいくつかあって、Nodeジェイエス二十四以降が必要です。
さらに、GitHub Copilot へのアクセス権も必須になります。
そして、このアプリはローカルアプリとしての本格活用を想定しているので、業務でちゃんと使うには Microsoftサンロクゴ、マイクロソフト・スリーシックスファイブとの連携が必須になります。

扱うデータが、かなり機密性の高い業務情報になりがちなので、セキュリティ面も意識されています。
筆者としては、機密データを扱う場合は、GitHub Copilot Business もしくは Enterprise の契約環境下で使うのが推奨だとしています。
「どうやって社内の業務ナレッジをエージェントに覚えさせるか」というテーマに悩んでいる方には、なかなか現実的なアプローチを示してくれるサービス紹介でした。

。。.。。.。..

四本目。
これは、AIにリポジトリのアーキテクチャ説明をさせようとしたときにありがちな、「なんとなくそれっぽいけれど、次の作業に進めないくらい抽象的な説明で止まってしまう問題」をどう解決するか、という話です。

筆者は、「これはAIがサボっているというより、人間側が“どのくらい具体的に書いてほしいか”を指定していないことが原因だ」と考えています。
そこで、Claude Code の Skill を設計するときに、指示文のなかに実物の例を埋め込む工夫をしています。

具体的には、「悪い例」として抽象的すぎる文章をそのまま入れて、「これはダメ。ここままだと次の作業に進めない」と示します。
そして「良い例」として、筆者が実際に欲しい“具体性レベル”の説明文をきちんと書いて、「このくらいまで詳しく書いてあればオーケー」というラインを、AIに対して明確に見せるんですね。
あわせて、「読み終わったあと、自分が実装者として振る舞えるくらいの理解を得られていること」といった、最終的に満たしてほしい状態も、指示文のなかにハッキリ書いておくようにしています。

さらに、リクエストの流れとか、テーブル間のリレーションのように、文章だけだとどうしても読みづらい情報については、mermaid記法のER図や、ASCIIアートでの図として出力することを“必須”にしています。
ここがポイントで、「文章か図か好きな方で出してね」とAIに選ばせるのではなく、「この種類の情報は、かならず図で描いてください」と、出力形式まできちんと縛るんですね。

筆者は、こういった工夫は特定の案件のキャッチアップだけに使えるテクニックではなく、「AIに何かをまとめさせる、説明させる、すべての場面で応用できる」と述べています。
「ちゃんと」「わかりやすく」みたいな、あいまいなお願いをするのではなくて、具体的な悪い例・良い例を見せたり、図で出すべきところを形式まで指定したり。
そうやって、モヤモヤの少ないアウトプットにつなげていくのが大事だよ、という、お仕事にもすぐ使えそうな実践的なノウハウでした。

。。.。。.。..

最後、五本目。
これは、AIエージェント拡張の新しい標準仕様「Agent Plugins バージョンいち・てん・ぜろ・ぜろ」を解説した、オピニオン強めの技術解説です。

ここで標準化しようとしているのは、「Agent Skills」と呼ばれるスキル本体の記述と、「MCP」、外部ツールへの接続仕様の、そのさらに上の層です。
つまり、「中身のスキル」と「外部接続」はそれぞれの仕組みを使うとして、それらをひとつのフォルダにまとめて配布する“箱の形式”だけを、なるべく小さく標準化しようとしている、というのがポイントです。

最小構成としては、プラグインのメタ情報を書いた pluginドットジェイソン、それから skillsディレクトリ、さらに mcpドットジェイソン、という三つがあればひとまず成立する、というシンプルな仕様になっています。
スキーマはクローズドで、拡張の余地をかなり絞った作りですし、`PLUGIN_ROOT` と `PLUGIN_DATA` を分けることで、「配布パッケージ」と「実行時に貯まるデータ」をきちんと分離できるようにしてあります。
パス指定も `./` 以下に制限したり、シークレット情報をプラグインの中に直接持ち込むのは禁止したりと、セキュリティやポータビリティを意識したルールが多く入っています。

狙いとしては、各社のクライアントやプラットフォームがすでに持っている“プラグイン機能”のうち、最大公約数だけを共通化して、それ以外の差別化ポイントは extensions や独自メカニズムに逃がす、という設計です。
なので、「全部同じになる」というより、「コアの箱の部分だけ足並みをそろえて、残りは好きにやっていいよ」というバランス感覚なんですね。

その一方で、hooks やサブエージェント、マーケットプレイス、認可や秘密情報の管理といった部分は、あえて標準化の対象外にしています。
筆者は、「今後は署名、権限、監査といった“信頼とガバナンス”のレイヤーが、次の争点になっていくだろう」と見ています。

標準仕様の運営も特徴的で、OpenAIが仕切るのではなく、Vercel 主導を含む五社が担っている形です。
一方で、Anthropic は「中身の標準」である Agent Skills 側には深く関わっているのに、この“箱の標準”である Agent Plugins には、まだ参加していないという、ちょっとねじれた状況も指摘されています。

筆者のまとめとしては、「いま開発者が投資すべきは、各クライアントで再利用できるスキルの記述のほうであって、プラグイン形式の違いは、この標準によってだんだん薄まっていくだろう」という見立てです。
つまり、「箱のフォーマットより、中身のスキルをちゃんと書けるようになろう」というメッセージですね。

。。.。。.。..

というわけで、きょうの「zenncast」、五本駆け足でご紹介してきました。
ローカルLLMとCloudflare OSで三目並べを動かした実験記、
マイクロソフトの Agent Framework で「ウルトラ→ソウル」を言わせるための多層チューニング、
PC操作と音声をもとに SKILLドットエムディー を自動生成してくれる「Skill Recorder」、
AIにアーキテクチャを説明させるときの“悪い例・良い例＋図の指定”という工夫、
そして、Agent Plugins いち・てん・ぜろ・ぜろでプラグインの“箱”をどう標準化していくか、という話でした。

気になった記事があれば、詳しい内容や元の記事へのリンクは、番組のショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。

この番組「zenncast」では、感想や「こんなテーマ取り上げてほしい」といったリクエストも大歓迎です。
ラジオネームを添えて送ってもらえると、番組の中でご紹介させていただくこともあります。

それでは、そろそろお別れの時間です。
きょうも聴いてくださって、ありがとうございました。マイクでした。
また次回、お会いしましょう。