おはようございます。マイクです。
九月二十一日、月曜日の朝七時になりました。今日も「zenncast」始めていきましょう。
この時間は、技術メディア Zenn に載っているトレンドの記事を、ラジオ感覚でゆるっと、でも中身はしっかりめにご紹介していきます。
今日はお便りはお休みということで、そのぶん記事紹介をたっぷりいきますね。
きょうは全部で、五本の記事をピックアップしています。
では、さっそく一つ目からいきましょう。
今回最初にご紹介するのは、Amazon Bedrock の AgentCore Runtime、新しいプラットフォームバージョン、ブイツーのお話です。
このブイツーで何が変わるかというと、「AI エージェントの実行環境」をあらかじめ一回だけ初期化して、その状態をスナップショットとして保存しておきます。で、新しくマイクロブイエム、microVM を立ち上げるときは、そのスナップショットからサッと復元する、という仕組みになりました。
これによって一番インパクトがあるのが、いわゆるコールドスタートの時間です。
これまでのブイワンだと、コンテナのイメージサイズだったり、同時実行数が増えているかどうかで、起動時間がかなりブレていたんですね。
それがブイツーでは、「イメージサイズにほぼ依存しない」「おおむね二秒前後」という、かなり安定したレイテンシーに収まることが検証されています。AI エージェントの応答を早くて一定にしたい、っていうユースケースにはかなり効きそうです。
使い方もシンプルで、CodeZip でもコンテナでも、プラットフォームバージョンにブイツーを指定するだけで、この仕組みが有効になります。
セッションごとのハードウェア分離だったり、ゼロスケールができて、使ったぶんだけお金がかかる従量課金、といった従来のメリットはそのままキープされています。
その一方で、ランタイムを新しく作るときや更新するときは、スナップショットを準備するぶん、これまでより時間がかかるようになります。なので、頻繁にデプロイするような環境では、CI／CD パイプラインをどう組むかとか、「スナップショットに焼き込んでおく処理」と「リクエストごとに毎回やる処理」をどう分けるか、こういった運用・実装面の設計がポイントになってきます。
立ち上がりは二秒でキビキビ動かしつつ、デプロイのリズムも崩さない、そのバランスをどう取るかが腕のみせどころ、という感じですね。
。。。。
続いて二つ目は、Anthropic が出した Claude の新機能、Claude Docs / Slides / Design を実際に触ってみたレポートです。ジャンルでいうと、サービス紹介寄りの記事になっています。
まずメインは Claude Docs。これは Claude に組み込まれた共同編集ドキュメント機能で、イメージとしては Google ドキュメントにかなり近いです。
表を作れたり、チェックリスト、見出し、コメントなども付けられて、普通にドキュメントツールとしてそこそこ使えます。
おもしろいのは、チャットや Claude Code から、そのまま文脈つきでドキュメントを起こせるところです。会話の流れをそのまま「文書にまとめて」とお願いできて、さらにドキュメントの中で、アットマーク・クロード、みたいな感じで「アット Claude」と呼び出して、レビューや追記を頼めます。
エクスポートも結構充実していて、ワードや PDF、Markdown に加えて、Google Docs や Notion にも書き出せるのが特徴です。
既存のワークフローとつなぎやすいので、「まず Claude Docs でガーッと書いて、仕上げは Google Docs や Notion でやる」という使い方がしやすそうです。
一方で、まだちょっと弱いところもあって、現時点だとバージョン履歴の機能がありません。誰がどこをいつ変えたか、っていう履歴を追うのは難しい状態ですね。
さらに、Free、Pro、Max、Team といったプランごとに、共有できる範囲がかなり違っていて、特に Max プランでは、現状ほとんど他人と共有できず、自分用メモに近い使い方に限られます。チームコラボをガッツリやりたい人は、プランと制限をちゃんとチェックしておく必要があります。
残りの Slides と Design については、完全な新サービスというより、「既存のデザイン機能を整理して、呼び出しやすくした」位置づけです。
Slides はプレゼン資料を作る専用ツールとして切り出されたもの、Design は、もともとあったデザイン生成機能を、チャットの中からサクッと呼べるようにしたもの、という形で、純粋に新しいのは Claude Docs だけだね、という評価になっています。
ドキュメント周りを Claude でまるっと回したい人には、かなり気になるアップデートですね。
。。。。
三つ目は、一気にローカル LLM の話にいきます。
Mワンプロ、メモリ十六ギガバイトの MacBook Pro で、二ビット量子化された二十七ビーのモデル「Ternary Bonsai ２ ２７ビー」を動かす手順をまとめた、ティップス記事です。
もともと Ollama で動かそうとしたところ、「テンソル・アウトプット・ウェイト・サイズ・オーバーフロー」というエラーが出てしまって、うまく動かなかったそうです。
そこで方針を変えて、PrismML 公式の llama.cpp のフォークを、自分のマシンでビルドして動かす、という方法を採用しています。
流れとしては四つのステップに整理されていて、
まず一つ目が、PrismML 版の llama.cpp のリポジトリをクローンして、Metal に対応したオプションを付けて CMake ビルドすること。Apple シリコンの GPU をちゃんと活かす形ですね。
二つ目が、Hugging Face のコマンドラインツール、エイチエフを使って、指定された PQ二・ゼロ形式の GGUF ファイルだけをダウンロードし、SHA二五六のハッシュで検証しておくこと。ここでちゃんとファイルの整合性を確かめておきます。
三つ目が、llama-cli で推論を実行して、日本語のプロンプトを投げて、短い応答が返ってくるか確認すること。
四つ目が、起動オプション一式をまとめたシェルスクリプトを作っておいて、対話モードにするかどうか、reasoning 表示をオン・オフするか、といった切り替えを簡単にできるようにしておく、という流れです。
実行結果としては、単発のテストで一秒あたり八・一トークンくらい、対話モードでは九・六トークン前後の速度が出ていて、メモリ十六ギガバイトの Mac でも、二十七ビー級のモデルをローカルで動かせることが確認されています。
もちろん、本格的な性能評価だったり、日本語の質、コード生成の品質の検証はこれからの課題なんですが、「そこそこ普通のスペックの Mac でも、このクラスが回る」という実験結果は、ローカル LLM 派にはうれしい報告ですね。環境構築の具体的な工夫もまとまっているので、同じ構成で試したい人にはかなり参考になりそうです。
。。。。
四つ目は、「Jev」という識別モデルを使って、自然文ベースで分類タスクを切り替える方法を解説した記事です。
ポイントは、「質問」と「基準説明」を自然言語で渡すだけで、ぜロショット的にいろんな分類タスクを切り替えられる、というところです。
配送問い合わせの例では、同じ問い合わせ文でも、
「この問い合わせは社内のどの部署に回すべきか」という質問と、
「お客さんが望んでいる対応は何か」という質問を、それぞれ別々に定義します。
そのうえで、候補ラベルごとに、「こういう内容が書いてあったらこのラベルにする」という説明文を自然言語で用意しておきます。
Jev に問い合わせ文と、質問、それから各ラベルの説明を渡すと、「どのラベルに当てはまりそうか」を確率つきで返してくれる、というイメージです。
実験報告書の検索の例では、
「触媒について書いていない」と「触媒は変えていない」という、似ているけど違う二つを、別ラベルとしてきちんと定義しています。
このとき、どんなラベルを用意するか、ラベルごとの説明文で境界をどう書き分けるか、ここが精度に響いてくる、と説明されています。
Jev の特徴として、確率のキャリブレーション、つまり「その確率がどれくらい信頼できるか」という部分をかなり重視している点があります。
これによって、「この確率以上なら自動処理に回す」「このレンジは人が確認する」といった、しきい値の設計がしやすくなるのがメリットです。
従来のゼロショット分類や、LLM に「候補から選んで」とお願いするやり方と違って、あらかじめ「型の決まった判断」と、その判断ごとの確率を、並列に返すように設計されているので、複数の判定を高速に回せるのもポイントです。
今後の方向性としては、DSPy や GEPA といったフレームワークを使って、質問文や候補ラベルの説明文そのものを自動で改善していきたい、としています。
Jev の重み自体は変えずに、外側の「基準テキスト」だけをチューニングしていくことで、誤分類や、人による確認が必要な件数、検索の漏れや誤ヒットを、どこまで減らせるか試したい、という展望ですね。
モデルをいじるんじゃなくて、「ルールテキスト」を洗練させる、という発想が印象的な記事です。
。。。。
そして五本目、最後は「既存の勤怠管理システムを AI エージェント化してみた」という検証記事です。
Playwright で画面操作を自動化しつつ、人間が無意識にやっている確認作業を LLM で補う、という構成になっています。
環境としては、Docker と noVNC の上に、Playwright（Python）と MCP サーバー（Node.js）を同居させています。
MCP のほうで、実際のブラウザ操作を記録して、セレクタの取得とか、画面遷移の流れを自動生成してくれるようにしておいて、そのコードを Claude Code で調整したり、細かい実装を加えていく、という開発スタイルです。
ただ、Playwright 単体だと、「いま開いているのは本当に意図した日付の詳細画面か」とか、「開始時刻と終了時刻はちゃんと入っているか」といった、文脈をふくんだ判断まではできません。
そこで、Bedrock をガードレールとして組み込みます。
具体的には、HTML の断片と画面キャプチャを LLM に渡して、マルチターン、つまり何段階かのやりとりで画面を解析させます。その際、temperature をゼロにして、出力のブレを抑えているのもポイントです。
その結果として、全部で千四百ステップくらい、開発時間は約六時間で、一日あたり四十五秒程度の自動打刻フローができあがっています。成功率は九十三・三パーセントと報告されています。
ただし、これだけの仕組みを作ると、コード量もそれなりに増えますし、どこで人が介入するか、いわゆる HITL、ヒューマン・イン・ザ・ループの設計も必要になるので、理解コストは決して軽くはありません。
特に重要なのが、「どこにガードレールを置くか」です。
どこまでを自動に任せて、どのタイミングで LLM にチェックさせて、どこで人が最終確認をするのか。
ここをうまく設計するには、業務の流れも、システムの制約も、両方ちゃんとわかっているエンジニアが必要だ、と述べられています。
「AI エージェント化すれば全部おまかせ」ではなくて、現実的なコストとリスクを見ながら、タスクを分解していくプロセスが、かなり具体的に描かれている記事でした。
。。。。
ということで、きょうの「zenncast」は、五本の記事をご紹介しました。
ざっとおさらいすると、
まずは Amazon Bedrock AgentCore Runtime ブイツーで、スナップショット復元によってコールドスタートがおおよそ二秒前後に安定した、という話。
次に、Anthropic の Claude Docs / Slides / Design を実際に使ってみて、特に Docs が新しくて、コラボやエクスポート周りの使い勝手、そしてプランごとの共有制限がポイントだよ、という話。
三本目は、メモリ十六ギガの Mワンプロ Mac で、二十七ビー級モデル「Ternary Bonsai ２ ２７ビー」を、PrismML 版 llama.cpp を自前ビルドしてローカル実行した手順と、その実測スピード。
四本目は、Jev という識別モデルを使って、「質問」と「基準説明」を自然文で渡すだけで分類タスクを切り替えられる、確率キャリブレーション重視のワークフロー。
そして最後は、既存の勤怠システムを Playwright と LLM を組み合わせてエージェント化し、Bedrock をガードレールにして九十三パーセント強の自動打刻を実現した、という検証記事でした。
それぞれ、もっと細かい手順やサンプル、著者さんの工夫ポイントなんかは、ショーノートにリンクをまとめておきますので、気になった方はぜひ元の記事もチェックしてみてください。
この番組「zenncast」では、感想や、「こんなテーマの記事を取り上げてほしい」といったリクエストも歓迎しています。
ラジオネームをそえて送ってもらえると、番組内でご紹介させていただくかもしれません。
というわけで、そろそろお時間です。
お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。それでは、いってらっしゃい。