おはようございます、マイクです。
「zenncast」、七月四日・土曜日の朝七時を回りました。みなさんいかがお過ごしでしょうか。
この時間は、Zennで話題になっているトレンド記事を、ラジオ感覚でゆったり紹介していきます。
今日はお便りコーナーはお休みで、そのぶんたっぷりと記事を紹介していきますね。
さて、今日ご紹介する記事は全部で五本です。
AIエージェント時代のターミナルツールから、MoonBitの高速化ノウハウ、ローカルLLMと一緒に作るCLI、AgentCoreでの本番運用、そしてAWSでの非同期処理パターンまで、かなり盛りだくさんです。それでは順番にいきましょう。
まず一つ目。
「herdr」という、複数のAIコーディングエージェントを、ひとつのターミナルからまとめて管理することに特化したターミナルマルチプレクサを紹介する記事です。
イメージとしては、tmuxの操作感をほぼそのまま保ちながら、エージェント時代向けの新しい機能を足した、次世代ターミナルって感じですね。
tmuxと同じように、セッションを永続化できたり、Ghosttyみたいな既存のターミナル上で動かしたりできます。構造も、ワークスペース・タブ・ペインという三階層で、キーバインドもコントロールビーをベースにしているので、日頃からtmuxを使っている人は、ほとんど違和感なく乗り換えられるようになっています。
一番の違いは、AIエージェントの状態を自動で検知してくれるところです。
Blocked、Working、Done、Idleといった状態を拾って、サイドバーに一覧表示してくれたり、通知を出してくれたりします。これは単にプロセスの状態や画面出力のパターンを推定しているだけでなく、一部のエージェントとは公式なインテグレーションで直接つながっていて、特別な設定をしなくても、すぐに状態管理が効くようになっています。
さらにおもしろいのが、CLIとUNIXソケットのAPIです。
ワークスペースやペインを作ったり、完了を待ったり、出力を取得したりといった操作を、コマンドから行えるようになっていて、スキルを読み込んだAIエージェント自身が、herdrを経由してペインを分割したり、サーバーを起動したり、テストを実行したりと、自律的にターミナルを操れるようになっています。
プラグインの仕組みも用意されていて、これもCLIベースなので、特定の言語に縛られずに実装できます。マーケットプレイスには、コードレビュー支援、リモート操作、レイアウトの自動構築など、いわゆる従来のtmuxではなかなか難しかった、「エージェント中心のワークフロー」を広げてくれるプラグインが色々公開されているそうです。
「AIが自分でターミナルを分割して、テストまで回してくれる」みたいな未来にワクワクする方は、要チェックな内容ですね。
。。。。
続いて二つ目。
こちらはプログラミング言語 MoonBit の標準ライブラリを題材に、「推測ではなく、計測に基づいて高速化する」という考え方を、具体例と一緒に紹介している記事です。
著者の方は、ムーンベンチと読むであろう `moon bench`、それから `moon run` や `moon test` に付けるプロファイルオプション、自作のメモリプロファイラ、それに汎用的なベンチツールの hyperfine を組み合わせて使っています。
指標として見ているのは、一秒あたりの実行回数、メモリの消費量、ビルドサイズといったもの。これらをちゃんと計測しながら、チューニングしていくスタイルです。
実例もかなり具体的で、たとえば BigInt、大きな整数の乗算アルゴリズムの分岐を見直した話。条件分岐の仕方を変えることで、性能がガツンと良くなったケースが紹介されています。
他にも、JSONパーサでヒープ領域の確保を減らす工夫をしたり、配列ソートのときに、不要な境界チェックを省略して速度を上げたりと、スピードアップとメモリ削減を両立した改善がいくつも出てきます。
MoonBitのバージョンゼロ・テンで入った V一二八型、いわゆる一二八ビットのベクトル型によるSIMD対応にも触れています。WebAssemblyとネイティブ、両方の世界で、五倍から二十五倍クラスの高速化の余地がある、新しい機能として、かなり強調されていますね。
最後の締めとしては、「自分のコードをプロファイルして、moonbitlang/core 由来のボトルネックを見つけよう」と呼びかけています。
その上で、AIに最適化案や別のアルゴリズムを提案させながら、オーエヌじじょう、二乗オーダーのループを減らしていくとか、FixedArray、バリュータイプ、ArrayViewといった仕組みを活用して改善していこう、と。
なんとなく速くなっている気がする…ではなくて、ちゃんと測って、ボトルネックを潰していく姿勢が伝わる内容でした。
。。。。
三つ目は、AIと一緒にローカルLLM向けのシェル支援CLI、「ask」を作った記録を通して、「AIと人間がどう仕事を進めると、本当に役に立つのか」を描いている記事です。
筆者の方は、毎回うろ覚えになりがちなbashやPowerShellのコマンドを、LANの中に立っているローカルLLMに、自然な文章で聞ける小さなCLIツールを作りました。
ただ、記事の主役は、このツールそのものというよりも、その過程でAIがどう振る舞ったか、という部分です。
登場するのは、Claude Codeの fable5 というエージェント。
このfable5は、与えられた前提を鵜呑みにせず、「その前提って本当に妥当なの？」と疑うところからスタートします。既存のプロジェクトをちゃんと読み込み、実際のマシン側の制約も考慮に入れつつ、評価用の問題集を自分で作り、モデルを実測で比較していく。
それを通じて、「どこまでAIに任せられて、どこからは人間が確認した方がいいのか」という線引きを、実験ベースで明らかにしていきます。
たとえば、「Claude Code経由でローカルLLMに繋ぐ」という案は、一見楽そうですが、fable5はレイテンシやプロンプトサイズの問題からその案を却下します。代わりに、OllamaのネイティブAPIに直接つなぐ、余計なものを挟まない最小構成を提案するんですね。
さらに、シェルのQ&A専用に五十問の評価セットを作って、モデルごとの正答率を見るだけではなく、「危険な誤答」や「もっともらしい嘘」がどのくらい出るか、その質までチェックして、デフォルトで使う標準モデルを選んでいきます。
パイプラインのような、複雑なコマンドの合成では失敗が多く起こる、ということも実測でわかってきます。そこから、「モデルのサイズよりも、推論、いわゆるシンキングモードの有無がボトルネックになっている」という切り分けにたどり着きます。
その結果、通常は高速モードでサクッと答えさせて、必要なときだけダブルハイフンシンクのオプションを付けて、じっくり考えさせる、二段変速のユーザーインターフェースになりました。
CLI側も、安全性に気を配った設計になっています。コマンドを勝手に自動実行せず、人間が自分でヘルプを参照するなどして裏取りする前提です。
bash版とPowerShell版の両方に対応しつつ、利用者向けと保守者向け、二種類のドキュメントを用意。まだ検証しきれていない部分や、安全に使うための境界も、ちゃんと明示されています。
筆者はこの一連の経験から、「AIは正解を一発で出してくれる魔法の箱」ではなくて、「何を調べるか、どこを測るか、どこで立ち止まるか」を一緒に考えながら、仕事を前に進めてくれる相棒になりつつある、と感じたそうです。その実録が、この「ask」開発記事、というわけですね。
。。。。
四つ目にいきましょう。
ここからは、AgentCoreを使ってAIエージェントを本番運用するための実装ノウハウをまとめた記事です。題材になっているのは、AWS Specialist Agent というデモ実装なんですが、その中で紹介されている工夫は、かなり汎用的に使えそうな内容になっています。
背景としてあるのは、企業システムとしてエージェントを動かすときの、典型的な悩みごとです。
たとえば、閉じたネットワークだけで使いたい、ユーザーごとに権限を分けたい、レスポンスの遅延を減らしたい、会話履歴をちゃんと管理したい、などなど。こういう要件を満たしながら、実運用できるエージェントに仕上げていくための設計が整理されています。
バックエンド側では、モデルをひとつに決め打ちではなく、ClaudeとGPTファイブ系を、ユーザーインターフェースから切り替えられるマルチモデル対応が紹介されています。
さらに、複数のMCPサーバーを、AgentCoreのゲートウェイ機能でひとまとめに集約して扱えるようにしています。
権限管理のところがけっこうポイントで、ユーザー属性に基づいて、どのツールが使えるかを制御する仕組みとして、CedarによるABAC、属性ベースアクセス制御が使われています。
また、S三ファイルをNFSでマウントして、スキルをスラエムティー・スキルズというパスから読み込む構成も紹介されています。こうすることで、スキルの配布や更新を、ファイルシステムレベルで行えるようにしているわけですね。
ネットワーク面では、VPCの中から外への通信を、すべてVPCエンドポイント経由にすることで、NATを使わずに完全な閉域網を実現しています。
さらに、ユーザーが入力している間に、軽めのウォームアップリクエストを先に投げておいて、マイクロブイエムをあらかじめ起動しておくことで、コールドスタートによる待ち時間を減らす工夫もされています。実運用ならではのチューニングです。
フロントエンド側も、会話履歴の扱いがよく考えられています。
会話の本文そのものはAgentCoreのメモリ側に保存して、一覧表示に必要なタイトルや日時だけをDynamoDBに持つ、二層構成で履歴を実装しています。最初の発話からタイトルを要約生成するのには、Haikuが使われています。
フィードバックAPIも用意されていて、評価とコメントをDynamoDBに保存しつつ、ユーザーIDは必ず検証済みのJWTから取り出す設計にしています。これによって、なりすましを防いでいるわけですね。
この記事で紹介されている設計や工夫は、特定のこのデモに限らず、AgentCoreで本番向けエージェントを作る多くのケースで、指針として再利用できるとまとめられています。
。。。。
最後、五つ目の記事です。
非同期処理の構成パターンを整理して、AWS環境でどう使い分ければいいかを考察している内容になっています。
前提として、業務向けSaaSのアーキテクチャがあって、ドメイン知識はECS上のAPIサーバーに集約したい、という方針がまずあります。
なので、Lambdaはあくまで「呼び出し役」にとどめて、処理の本体は常にECSコンテナで動かす、というスタイルを取っています。
具体的なパターンとしては、まず短時間で終わる処理については、SQSからLambda、そしてECSへとバトンを渡す、パススルー構成を使います。
一方で、処理時間が読めなかったり、トラフィックのスパイクが起きやすい、いわゆる「突き放し処理」については、ECSのワーカープロセスがキューをポーリングする、Worker Pull方式へ移行します。ここでは、キューの長さに応じてスケールさせたり、スパイクをキューでいったん受け止めて、レートを制御する仕組みが重要になってきます。
大量データの処理については、実行時間に上限のないAWS Batchに任せる、という切り分けです。
さらに、外部APIからの取り込みのように、多段で待ち合わせやリトライが必要な処理は、Step Functionsでフローを組み立てる、といった使い分けが紹介されています。
それぞれの方式には、タイムアウトの扱い、重複実行が起こる可能性、リアルタイム性の高さ、運用コストのかかり方、などなど、トレードオフがあります。
記事の結論としては、「処理時間」「リアルタイム性」「流量制御」「管理コスト」このバランスを見ながら、どのアーキテクチャを選ぶかを決めることが大事、というメッセージで締めくくられています。
単に「Lambdaが流行っているから全部Lambdaで」ではなく、自分たちの業務の性質と、運用チームの負荷まで含めて、構成を選び分けましょう、ということですね。
。。。。
というわけで、今日の「zenncast」、お届けしてきた内容を駆け足でおさらいします。
一つ目は、複数のAIコーディングエージェントを一つのターミナルから扱える、tmux互換の新世代マルチプレクサ「herdr」。
二つ目は、MoonBit標準ライブラリを題材に、「推測ではなく計測で高速化する」実例と、V一二八によるSIMD最適化の話。
三つ目は、ローカルLLM向けシェル支援CLI「ask」を通じて、AIと人間がどう協調すると真に役立つのかを探った実録。
四つ目は、AgentCoreとAWS Specialist Agentを例に、本番運用を意識したエージェント基盤の設計ノウハウ。
そして五つ目が、AWSでの非同期処理パターンを整理して、処理時間やリアルタイム性、流量制御、運用コストのバランスでアーキテクチャを選ぼう、というお話でした。
気になった記事があった方は、ぜひショーノートをチェックして、元の記事もじっくり読んでみてください。今日お話しした内容より、さらに深掘りがたくさん載っています。
この番組「zenncast」では、感想やご質問もいつでも募集しています。
「こんなテーマを取り上げてほしい」「ここ、もっと詳しく聞きたい」などありましたら、ぜひ気軽にお便り送ってください。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回お会いできるのを楽しみにしています。
良い一日をお過ごしください。