どうも、マイクです。おはようございます。
2026年5月22日、金曜日の朝7時をまわりました。今日も「zenncast」、最新のZennトレンド記事をゆるっと、でもしっかりご紹介していきます。
今日はお便りコーナーはお休みで、そのぶん技術記事をたっぷりめにお届けします。
さて、きょう紹介する記事は全部で5本。DDDの話から、ローカルAI、Claudeのskill運用、Web標準、そしてBedrockのマルチテナント設計まで、なかなか濃いラインナップです。
まず1本目。
タイトルは「複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事」。
DDDやってると、「このユースケース、3つの集約一気に更新したいし、全部同じDBトランザクションで包んじゃえ！」って発想、つい出てきますよね。でもこの記事は、それはだいぶ危険なシグナルだよ、と教えてくれます。もし「一度の更新で全部そろってないと不変条件が守れない」状態なら、そもそも集約の切り方がおかしいかもしれない。1つの集約としてモデリングし直すか、途中の中間状態を定義して「結果整合」でつなごうよ、という提案です。むやみにトランザクションを広げると、MVCCの履歴肥大やロック競合、デッドロックの温床になるし、読み取り側も「たまたま同一トランザクションに乗ってる前提」で暗黙依存を持ちがち。代わりに「1集約1アクター」やプロセスマネージャー、いわゆるサーガパターンを使って、ACIDじゃなくACD、補償と結果整合を前提にしたプロセスとして設計する。そのうえで読み取りモデル側では「確定済みだけ見せる」「処理中は別ビューに回す」みたいに公開範囲をコントロールして、強整合は集約の内側に閉じ込めておこう、という実践的な指針がまとまっています。
。。。。
続いて2本目。
タイトルは「Local Coding Agent が身近なタスクをどれくらいこなせるのかを検証した」。
ローカルで動くコーディングエージェント、どこまで実務で使えるの？という検証記事です。環境はMacBook Pro M3 Max 64GB 上で、Qwen3.6-27Bを4bit量子化してMLX＋OpenCodeで動かす構成。対象はTypeScript／React／Honoで書かれた、自社プロダクト相当のリポジトリです。タスクはUI調整やクエリ正規化、URLからの会議ツール判定、トピック数チェック、部署フィルタ付きAPIの三層同期、テンプレートのCRUDとUI実装まで、かなり“現場感”のある6つ。事前に「失敗するテスト」を仕込んでおいて、ちゃんと全部パスできるかを確認しているのが良いですね。結果として、自己修正もできるし、複数レイヤーにまたがる変更もこなせたんですが、タスク1つあたり7〜45分と、とにかく時間がかかる。一方で、Claude Code + Sonnet 4.6 だと同じタスクが約20倍速い6分ほどで終わり、コストも1.39ドル程度。ローカルは無料でデータも外に出ない安心感があるけど、現状は速度が実務投入のネックだね、という冷静なまとめです。今後、モデルの小型化やハードウェアの進化で、ローカル環境がどこまで追いつけるか、楽しみになる検証でした。
。。。。
3本目。
タイトルは「Claude Code の skill-creator で既存 skill を検証してみた」。
Anthropic公式のAgent Skillsリポジトリに入っている「skill-creator」を使って、Zenn向けの「zenn-blog-writing」というスキルを定量評価した、という内容です。skill-creatorは、スキルの作成・改善・評価までを面倒見てくれるツールで、evalタスクを実行して「スキルあり／なし」のスコア差を見える化してくれます。この記事では3種類のevalを2イテレーション回していて、1回目はskillありで94.4%、なしで77.8%。2回目にはスキル改善の効果で、skillありがなんと100%に到達。特に差が出たのは、Zenn固有のルール、たとえばtopicsは小文字にするとか、frontmatterのクォートスタイルとか、一般的なMarkdownの知識だけだと「そこまで厳密には気にしてくれない」部分です。逆に「AIっぽい表現を減らす」とかは、スキルなしでもけっこうちゃんとできていた。つまりスキルの本当の価値は、モデルが知らない一般知識を教えるというより、「サービス固有の慣習を、毎回ブレずに適用させること」にある、と整理しているのが印象的です。また、ベンチマークは単なるスコア競争じゃなくて、「どんなFAILなのか」、ルールの書き漏れなのか仕様理解の問題なのか、そこを切り分けて改善ポイントを明確にするための道具。モデルや要件が変わっていく中で、スキルが“なんとなく”じゃなく“意図どおり”動いてるかを定期的に確かめ続けよう、というメッセージが刺さります。
。。。。
4本目。
タイトルは「dialogやPopover APIは『お前ら開発者に任せておけねえ』というWeb標準からのメッセージなのでは？」。
タイトルはちょっと挑発的なんですが、内容としてはとてもバランスの良い視点です。最近ブラウザに入ってきた`<dialog>`タグやPopover API、`inert`属性なんかって、モーダルやポップアップを作るときの共通処理を、JavaScriptで毎回がんばって実装しなくてもいいようにしてくれる仕組みですよね。前面に出す、背景の操作を無効化する、フォーカスをトラップする、スクリーンリーダー対応をする…これを毎回ゼロからやるのはしんどいし、どこかでバグも生まれやすい。この記事では、それを「開発者に任せてられない」というより、「壊れやすいところをブラウザ側に戻して、責任を再分配していこう」という流れだと説明しています。開発者はUIの“意味”をHTMLやARIAで表現して、「浮かせて表示する」「閉じる」といった共通のふるまいはブラウザにやってもらう。さらにOpen UIという取り組みで、ブラウザ組み込みの堅牢なUIと、フルカスタムのUIのあいだの“いいとこ取り”を目指している。全部を開発者に任せるのでも、全部ブラウザに握らせるのでもない、その中間を探っているんだ、というWeb標準の思想を丁寧に解説してくれる記事です。
。。。。
そして5本目。
タイトルは「SaaS で AI Agent を提供するあなたへ贈る、Bedrock AgentCore マルチテナント実装 - Runtime 編」。
これはインフラ・SaaS設計寄りの記事ですね。Amazon Bedrock AgentCore Runtimeを例に、マルチテナントSaaS、とくにサイロモデルでどう設計するかを解説しています。マルチテナントのデプロイモデルにはサイロ・プール・ブリッジ・ハイブリッドがあって、Runtime単体ではサイロかプールを選ぶことになる。この記事ではサイロモデルを取り上げていて、テナントごとにRuntimeリソースを分けつつ、API GatewayとLambda、DynamoDBでテナント別のエンドポイントやセッションを管理していきます。認証パターンも2つあって、JWTではHTTPで直接Runtimeを叩き、トークン属性をもとにDynamoDBでルーティング。IAMパターンでは、テナント共通のロールを用意して、AssumeRole時のsession policyでテナントごとの権限に絞り込むことで、テナント数ぶんRoleを増やさなくていい設計を紹介しています。RuntimeのセッションはMicroVM単位で分離されていて、`X-Amzn-Bedrock-AgentCore-Runtime-Session-Id`や`Mcp-Session-Id`で制御するんですが、あくまで「セッション単位」であって、「テナント単位」ではない。なのでアプリ側で、ビジネスセッション、つまり会話やチケットとRuntimeセッションを2階建てで設計して、DynamoDBなどでマッピングしつつ、有効期限も管理する必要があります。特にidle 15分、最大8時間という制約があるので、そのライフサイクル設計が重要。セッションIDにテナントIDを含めておくと、ログ分析やクロステナントの検知にも役立つよ、という実践的なTipsも載っていて、SaaSでAIエージェントを提供したい人にはかなり刺さる内容になっています。
。。。。
というわけで、きょうのzenncastでは、
・DDDにおける集約とトランザクション境界の整理の記事
・ローカルCoding Agentの実務タスク性能検証
・Claude Codeのskill-creatorでskillをちゃんと評価する話
・dialogやPopover APIに見るWeb標準と責任分担の変化
・Bedrock AgentCore Runtimeでのマルチテナント実装（サイロモデル編）
この5本をご紹介しました。
気になる記事があれば、番組のショーノートに詳しく書いておきますので、ぜひそちらから元の記事も読んでみてください。
zenncastでは、番組の感想や「こんなテーマ取り上げてほしい！」というリクエストも大歓迎です。Zennで見つけたおすすめ記事なんかも、教えてもらえると嬉しいです。
それでは、そろそろお時間です。
きょうも良い一日をお過ごしください。お相手はマイクでした。
また次回のzenncastでお会いしましょう。