どうも、マイクです。おはようございます。
八月二十六日、水曜日の朝七時になりました。「zenncast」今日も元気にお届けしていきます。

今日はこのあと、Zennで今日トレンドの記事をいくつかピックアップしてご紹介していきます。技術よりの話が多めなんですが、なるべくかみ砕いて、ラジオっぽくゆるくお届けしますので、通勤・通学のお供にゆったり聴いていってください。

今日は記事をぜんぶで五本、ご紹介していきます。なかなか情報量多めなので、気になったところはあとでショーノートから原文もチェックしてみてくださいね。

まず一つ目。
建築業向けの社内ERP、つまり会社の中で使う業務システムを題材に、「どこに境界を引くかで、中規模から大規模のシステムの保守性をどう確保するか」というテーマで書かれたオピニオン記事です。

著者の方は、TanStack Start、それからHono、oRPC、Cloudflare Workers、といった比較的新しめのスタックを組み合わせて、ウォーターフォール前提の、EVM付きのERPを作ったそうです。
全部をCloudflareの上に載せながらも、書き込みが多い業務システムということで、Cloudflare D1はあえて使わずに、PostgreSQLとHyperdriveを採用。プロジェクト単位でロックをかけられるようにして、同時書き込みをしっかりさばけるように設計している、というのがポイントになっています。

中でもおもしろいのが、「API契約」を、データベースとかサーバの実装から切り離して、専用パッケージにまとめているところです。さらに、EVM、つまり業務ロジックの計算の部分を、「入出力だけが決まった副作用のない関数」として共有している。
これによって、フロントエンドとサーバ、そしてAIエージェントからも、同じ契約・同じ計算を共通で使い回せるようにしているんですね。結果として、利用する場所や人数が増えていっても、変更の影響範囲を小さく保ちやすい構造になっている、と語られています。

さらに一歩踏み込んでいて、モジュール間の依存関係の向きをCIで強制しているそうです。
「どのモジュールがどこに依存していいか」をルール化して、自動でチェックすることで、時間が経ってもアーキテクチャが崩れにくいようにしている、と。加えて、データベースが保証してくれない値のチェックや、キャッシュをどこまで効かせるかといったルールを、「境界」のところで一元管理している。
画面数やAPIエンドポイントの数がどんどん増えていきがちな業務システムでも、破綻しにくい設計にしているのが、この「境界の引き方」なんだ、という話でした。アプリが育ってから「依存関係カオス問題」に悩まされがちな人には刺さりそうな内容です。

。。，、。

続いて二つ目。
これは、学会のポスターを作るときに、Claude Designというツールを使ってみた実例レポートです。「どこが得意で、どこが苦手なのか」をかなり冷静に整理しているのがおもしろい記事になっています。

Claude Designが特に強いのは、原稿からゼロからイチで「それっぽいレイアウト」を一気に作るところ。
章ごとのブロックの配置とか、数値や図をどう見せるか、さらには所属している組織のブランドイメージに沿った基本デザイン、こういったあたりは、人間の素人が一からがんばるより、かなりいいレベルに仕上がる、と書かれています。

一方で弱いのは、「どの情報を削るか」とか「どこを強調するか」といった、内容面での取捨選択や、視線の誘導、文字サイズのメリハリ、配色に込める意味づけ、こういった“表現の意図”の部分。
そのまま使うと、「パッと目を引くポスター」というよりは、「ちゃんと読めばわかる資料」寄りになりがちだと分析しています。

実務的には、Claudeでまずたたき台を作って、そのあと人間やデザイナーがイチからヒャクまでブラッシュアップしていく、という使い方が現実的とのこと。
ゼロからイチまでの工数が大きく削れたことで、全体の制作時間はおおよそ半分くらいになったそうです。レイアウト地獄からの解放ですね。
最後は、こうしたツールにアクセスできるかどうかで、今後、学会ポスターみたいなアウトプットの品質に、目に見える格差が出てきそうだ、と締めくくられています。デザイン苦手な研究者の方には、かなり勇気付けられる内容かもしれません。

。。，、。

三つ目。
こちらはガッツリ数理寄りの話で、時系列データを扱う状態空間モデルにおける、「Filtering」と「Smoothing」の違いを、数式レベルできれいに整理した記事です。

Filteringというのは、過去から現在までの観測データだけを使って、「今この瞬間の状態」を逐次的に推定していく方法。
状態方程式を使って一歩先を予測する「予測ステップ」、そして観測方程式に基づいて、その予測をベイズ更新するステップ。これを、時刻が進むごとに前向きに繰り返していきます。いわば「リアルタイムで追いかけていく」やり方ですね。

一方のSmoothingは、全期間の観測データを使って、各時刻の状態を「後からまとめて推定し直す」方法です。
まずは前向きにFilteringをしておいて、その結果をベースに、今度は時間を逆向きにたどりながら、「未来の観測がどれくらいもっともらしいか」という、後ろ向きの尤度情報を伝播させて、各時点の事後分布を更新していきます。
なので、「未来の情報も含めて振り返って、あの時点の状態をもっと賢く推定し直す」のがSmoothing、というイメージです。

記事の中の数値実験では、SmoothingはFilteringと比べて、RMSE、つまり二乗平均平方根誤差と、不確実性の幅、この両方がだいたい一九パーセントくらい改善した、という結果が示されています。
同じ被覆率、同じ「当たりやすさ」を保ちながら、より精度の高い推定ができるというわけですね。

さらにKaggleのROGIIコンペの事例では、FilteringとSmoothingが「違う間違い方」をすることを利用して、この二つの推定値をアンサンブル、つまり組み合わせることで、精度をさらに上げられたと報告されています。
まとめとしては、「未来も含めた全観測を使うSmoothingはやっぱり強い。でも、Filteringも合わせて使うと、実務上もっと有利になる」という、かなり実践的な示唆が紹介されていました。オンライン処理とバッチ処理をどう組み合わせるか、悩んでいる人にはヒントになりそうです。

。。，、。

四つ目。
これはちょっと変わった実験レポートで、人間がGitHub Copilot CLIの“背後”に入り込んで、「LLM役として実際に返答してみることで、エージェントの中で何が起きているかを体感的に理解した」という話です。

筆者の方は、`youarellm` という、OpenAI互換のローカルプロバイダーを自作して、モデル名を「human」として接続します。
そして、人間が、systemメッセージやツール定義、これまでの履歴、ツール実行の結果をすべて読んだうえで、自分の手でメッセージやtool callを返す、というロールプレイをやったわけですね。

これをやってみることで何がわかったか。
まず、tool callは「コマンドの実行そのもの」ではなくて、「クライアントに対して、そのコマンドを実行してほしいと依頼する指示」に過ぎない、ということが、体感としてよくわかる。
さらに、会話の履歴っていうのは「サーバー側が覚えてる記憶」ではなくて、毎回クライアント側から送り直されている状態なんだ、という、エージェントの役割分担の構造が見えてきた、と書かれています。

トークン削減についても触れられていて、ツール定義の数や書き方を工夫することで、ある程度トークンを減らせる一方で、根拠や確認範囲まで削りすぎてしまうと、結局やり直しが増えて効率が落ちる、ということも実感したそうです。
最終的なまとめとしては、エージェントに渡す情報を、「決定」と「その根拠」、「まだ確認していないこと」、「次にやる行動」、「完了とみなす条件」、こういったものに整理して渡すのが大事だ、という結論に至っています。

単にドキュメントを読むだけじゃなくて、「自分がLLMだったらどう返すか」を一度体験してみると、プロンプト設計とかツール設計の感覚がかなり変わりそうだな、と思わせてくれる記事でした。

。。，、。

そして五つ目、最後の記事です。
これは、マイクロサービス間で一つのリクエストが複数のサービスをまたいでいくときの、「認可コンテキストの伝搬問題」について、標準化中の仕組みと社内実装を比較しながら解説している内容です。

どういう問題かというと、入り口のサービスでユーザー認証をして、「この人はこのデータを見てよいですよ」と判断したとしても、その情報が途中のサービスにはちゃんと伝わらないことがある。
すると後続のサービスは、「呼び出し元が『この人は見てよい』って言ってるから、そうなんだろう」と、自己申告を信じるしかない。ここが、セキュリティ上かなり危ういポイントなんだ、という説明から始まります。

この課題に対して、いまIETFで標準化が進められているのが、「Transaction Tokens」という仕組みだと紹介しています。
これは、短い寿命の署名付きトークン、いわゆるJWTに、「誰が」「どんな環境から」「どんな処理をしようとしているのか」といった情報を詰め込んで、マイクロサービス間でバトンのように渡していくことで、「改ざんされていない認可コンテキスト」を伝搬しようとするものです。

一方で、記事の筆者が所属するバクラク社内では、同じ課題を解くために「Capability Assertion」という独自トークンを実装している、と。
こちらは、どのサービスが、どのユーザーについて、どのリソースIDの閲覧を許可したのか、そこだけにフォーカスした情報を、短命のトークンとして後続サービスに渡す仕組みだと説明されています。

両者には、共通する設計思想があります。
「自己申告にしないこと」、「トークンは寿命を短くして、権限の範囲もぎゅっと絞ること」、そして「認証そのものとは分けて考えること」。このあたりは、どちらも同じ方向を向いている。
ただし違いとして、Transaction Tokensは、リクエスト全体の処理内容についても改ざん防止を狙っているのに対して、Capability Assertionは、「閲覧を許可済みのリソースIDを、ちゃんと安全に伝搬すること」に用途を絞っている。
この「どこまで守るか」「どのユースケースをターゲットにするか」の違いが、とても重要なんだ、とまとめられています。

マイクロサービスが増えてくると、「認証」はちゃんとしているのに、「認可の伝え方」があいまいで危ない、というケースが本当に増えてくるので、そこをどう標準的に、あるいは自社の事情に合わせて設計していくか、すごく考えさせられる記事でした。

ということで、きょうのzenncastは五本立てでお届けしてきました。
ざっとおさらいすると──
一つ目は、建築業向けERPを題材に、API契約や業務計算を専用パッケージとして切り出し、境界の引き方で保守性を確保していくアーキテクチャの話。
二つ目は、Claude Designで学会ポスターのゼロからイチを一気に作り、制作時間をおよそ半分にしつつ、人間がイチからヒャクのブラッシュアップをするワークフロー。
三つ目は、状態空間モデルのFilteringとSmoothingを比較し、全観測を使うSmoothingが精度面で優位だけれど、両方をアンサンブルすることでさらに精度を上げられる、という実践的な知見。
四つ目は、人間がLLM役を演じることで、tool callの意味や履歴の扱いなど、エージェントの内部構造を体感的に理解した、という実験レポート。
そして五つ目は、Transaction TokensとCapability Assertionを比較しながら、マイクロサービス間で短命トークンを使って、認可コンテキストを安全に伝搬する設計について考える記事でした。

気になった記事があれば、詳しい内容や元のリンクはショーノートにまとめておきますので、そちらからじっくり読んでみてください。
この番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。仕事や勉強の合間に聞いているよ、なんて一言だけでも、とっても励みになります。

それでは、きょうはこのへんで。
お相手はマイクでした。また次回のzenncastでお会いしましょう。いってらっしゃい。