どうも、マイクです。
時刻は朝七時を少し回ったところ、二〇二六年九月十一日、金曜日の朝です。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。コーヒー片手に、通勤通学のおともに、ゆるりとお付き合いください。
きょうはお便りはお休みなので、その分しっかり記事を紹介していきますね。
さて、きょう紹介する記事はぜんぶで五本です。
ドメインモデルの設計から、AIエージェント、データベースのメモリ管理、エージェントスキル設計、そしてWebフォントの話まで、なかなか幅広いラインナップになっています。順番にいきましょう。
まず一つ目。
テーマは、ドメインモデル実装のときに出てくる「完全性・純粋性・性能」のトリレンマ、という話です。
業務ルールをちゃんとモデルに全部書きたい、一方で外部の入出力に依存しない「純粋」な形も保ちたい、でもパフォーマンスも捨てたくない、という三つの要望を同時に満たすのは難しいよ、という問題を取り上げています。
この記事の筆者は「Souther」という専用言語を使っています。
業務ロジックの分岐とか、「こういう条件なら許可」「こういう条件なら拒否」みたいな判断は、`read`といった振る舞い、ビヘイビアの中に全部書きます。一方で、データベースからの取得とか、外部へのアクセスは、`followership`みたいな別のビヘイビアに切り離して、外側の実装、たとえばJavaのコードに任せているんですね。
こうすることで、モデルの中に書かれた手続きそのものは、外部I/Oに依存しない「純粋」な形を保つけれど、実行全体としては、「外の世界」とはきれいに切り離さない。つまり、モデル内の純粋さは守りつつ、システム全体の純粋性はあえて捨てる、という落としどころにしているのがポイントです。
もう一つおもしろいのが、結果の扱い方です。
業務として起こりうる結果、たとえば「Allowed」「Refused」みたいな状態は、戻り値の型ですべて表現します。一方で、データベース障害みたいな技術的な失敗は、Javaの例外として別ルートで扱います。ここを混ぜないことで、「ビジネス上の結果」と「技術的な事故」がごっちゃにならないようにしているわけですね。
さらに、このSoutherでは、ビヘイビアの入出力の関係を `ensures` で「契約」として書けます。
「このビヘイビアは、こういう入力を受け取ったら、こういう状態を保証しますよ」というのを明文化する感じです。
それに加えて、`example` で具体的なケースを列挙しておくと、「adequacy」という仕組みで、ケースの不足を自動で検出してくれる。つまり「このパターンのテストケース、抜けてますよ」と教えてくれるわけです。
さらに、外部のJava実装についても、同じ `example` とか、モデル側に用意した `fake`、擬似実装を使ったテストで比較して、仕様とのズレを機械的にあぶり出していきます。
こうすることで、ドメインモデルそのものを「合成しやすくて検証しやすいものにしていく」というアプローチが示されています。
トリレンマって言われると難しそうですけど、「純粋さはモデルの中に閉じ込めて、外の世界との折り合いは設計でつける」という実践的な話、設計好きの方には刺さる内容だと思います。
。。.。。.。.
続いて二つ目。
こちらはAIエージェント系のサービス紹介的な内容で、かなり未来感のある話です。
PC操作に強い「GPTシックス・Astra」というモデルを使って、「Unityを操作して、仕様書どおりの三D障害物ゲームを作ってください」とだけ指示しちゃう、という実験が紹介されています。
ポイントは、MCPとか専用プラグインみたいなものを使わずに、Unityをそのまま直接操作させているところです。
用意したのは、ゲームの仕様書とユーザーインターフェイスのサンプル、それから中身が空っぽのUnityプロジェクト。この三つを渡しただけで、だいたい二十分ほどで、プレイヤー操作ができて、障害物もあって、BGMや効果音まで入った、「普通に遊べる三Dゲーム」が自動生成されちゃった、という報告になっています。
面白いのが、環境トラブルへの対応です。
開発の途中で、使っているMacがロックされちゃう場面があるんですが、そこでAstraが、自動でプロジェクトのコピーを作って、コマンドラインからUnityを起動して、テストや検証を続けちゃうんですね。
つまり、画面操作が制限されたら、「じゃあ別の手段でやるか」と、自分で手順を切り替えて作業を継続していく。このあたりが「ただの自動化」ではなくて、「エージェントらしさ」が出ているポイントです。
気になるコストは、使ったトークンが約五百七十四万トークンで、金額にするとだいたい八ドル四十セントぐらい。
記事では、「これから性能がもっと上がっていけば、開発者がUnityエディタをほとんど触らないまま、ゲーム制作の大部分をAIに任せられるんじゃないか」という未来も見えてきた、とまとめています。
ゲーム開発に関わっている方は、うれしいような、ちょっとドキッとするような、そんな内容かもしれません。
。。.。。.。.
三つ目の記事は、データベース好きにはたまらない、DuckDBの話です。
テーマは、「メモリに収まりきらない大きなグループバイをどう処理するか」。一般的な仕組みの説明と、実際の計測結果がセットになっている解説記事です。
グループバイをハッシュ集約でやるときって、グループの数に比例してハッシュ表をメモリに持つことになりますよね。
この記事では、「メモリを食う一番の原因は、このハッシュ表そのものだ」と説明しています。
で、そのハッシュ表がメモリに載りきらないような大規模データのときはどうするか。
キーのハッシュ値を使ってデータをいくつかのかたまりに分けて、一時ファイルとしてディスクに書き出しておきます。あとから、そのかたまりごとに読み戻して集計する、という「二段階の外部ハッシュ集約」を行います。
DuckDBでは、このやりとりを「バッファマネージャ」が面倒見ています。
データを「ページ」という単位で扱っていて、`memory_limit`、メモリの上限に近づいてきたら、使っていないページから順にディスクへ退避していく仕組みです。
著者は、別のセッションから `duckdb_memory()` を使ってメモリの状態を見たり、ファイルシステムのログを眺めたりしながら、本当にそう動いているのかを確認しています。
メモリ上限をかなりきつめに絞っても、ハッシュテーブルがディスクに退避されながら、二段階処理でちゃんとクエリが最後まで完走している、というのを数値で示してくれています。
一方で、「どこまででも退避できるわけではないよ」という注意点もあります。
退避できないメモリ領域、たとえば `ALLOCATOR` と呼ばれる部分とか、スレッドごとに確保される作業用のメモリが上限にぶつかると、Out of Memoryで落ちてしまう、ということも実験で見せています。
このあたりを踏まえて、実運用では、「本番と同じスレッド数で事前に計測しておきましょう」とか、「`memory_limit` は余裕を持って設定しておきましょう」というまとめになっています。
なんとなく `memory_limit` を小さくしておけば安全、というよりは、「どこがディスクに逃がせて、どこが逃がせないのか」を理解したうえでチューニングするのが大事だよ、というお話ですね。
。。.。。.。.
四つ目は、エージェントスキルの設計の話です。
エージェントに仕事を任せるときの「スキル」をどう書くか、というテーマなんですが、一つのスキルの中に、具体的な手順も、判断基準も、ぜんぶ詰め込んでしまうと、あとからのメンテナンスがものすごく大変になる、と指摘しています。
たとえば、「この観点をレビューに追加したいな」とか、「このステップはもう不要だから外したいな」と思ったときに、スキルの説明文、日本語の文章をまるごと書き換えないといけなくなる。
そこで筆者は、スキルを二つに分ける設計に切り替えています。
一つは「振る舞い」。これは「どう動くか」、作業の流れそのものです。
もう一つは「ナレッジ」。これは「どこを見るか」「どう判断するか」という観点や基準です。
具体例として、プルリクエストのレビューをするエージェントを考えます。
PRの取得の仕方とか、レビューをどう進めていくか、といった流れは SKILLドットエムディーに書く。
一方で、コードレビューの観点、「セキュリティをこうチェックする」「パフォーマンスはここを見る」といった基準は、guidelinesのような別ファイルに分けていきます。
こうやって分離しておくと、チームメンバーが自分の知見をどんどんナレッジ側に追加しやすくなります。
たとえばフロントエンドエンジニア用の観点、バックエンド用の観点、SRE向けの観点、といった具合に、職種ごとに見てほしいポイントだけ差し替えて、同じスキルの振る舞いを共有できるようになります。
さらに大事なのが、「振る舞いのほうに、特定のツール名を埋め込まない」という方針です。
たとえば `gh` コマンドみたいな具体的なツール名を、振る舞いの文章にガチガチに書いてしまうと、環境が変わったとき、ツールを乗り換えたときに、スキルの定義ごと直さなきゃいけなくなります。
そうではなくて、「GitHubのPRを取得する」とか、「レビュー結果をコメントする」といった、もう少し抽象度の高い書き方をして、実装手段には依存しないようにしておく。
これによって、環境の違いや将来の変更にも強い、長持ちするスキルになるんだ、という話になっています。
エージェントをチームで運用していくときの「きれいな分離の仕方」の参考になりそうです。
。。.。。.。.
そして五つ目。
こちらはWeb制作の現場で「あるある」な、OS標準フォントをどう指定するか、というテーマの考察と提案の記事です。
筆者はまず、各OS、ブラウザ、言語設定ごとに、`sans-serif` と `system-ui` を指定したときに、実際にはどのフォントが使われるのかを調べています。
結果として、多くの環境では、Noto Sans、ヒラギノ、Roboto、メイリオ、Segoe UI、San Franciscoといった、「まあ無難だよね」と言える標準フォントに落ち着く、ということがわかってきます。
そのうえで、「OSの標準フォントを使いたいだけなら、わざわざ細かくフォント名を並べなくても、`sans-serif` か `system-ui` だけを指定して、あとはブラウザとOSに任せる、というので実用上ほぼ足りるんじゃないか」と主張しています。
いわゆる、「長いフォントファミリーの指定、そこまでがんばらなくてもいい場面、けっこうあるよね」というスタンスですね。
もう一つ触れているのが、漢字の字形の問題です。
日本語ページを翻訳したときに、「海」みたいな漢字が、日本語の字形のまま残ってしまう、といった、日中間での字形の食い違いです。
これをきれいに解決しようとすると、`lang` 属性や言語設定に合わせてフォントを切り替える、といった実装が必要になるんですが、これがかなり大変だ、と説明しています。
最終的な結論としては、ケースバイケースだけれども、ユーザーがブラウザで設定しているフォントを尊重したい場合とか、実装・保守のシンプルさを重視したいプロジェクトでは、`sans-serif` または `system-ui` を単独で指定してしまう、という割り切りも有力な選択肢だよね、というまとめになっています。
デザインのこだわりと、開発コストと、ユーザーの設定尊重、このあたりのバランスをどう取るか、考えさせられる内容です。
。。.。。.。.
というわけで、きょうの「zenncast」は、
ドメインモデルの「完全性・純粋性・性能」のトリレンマに挑むSoutherの設計の話、
Unityをほぼ丸投げで三Dゲームを作ってくれるGPTシックス・Astraのエージェント実験、
DuckDBが大きなグループバイを二段階の外部ハッシュ集約でさばく仕組みと、メモリ制限との付き合い方、
エージェントスキルを「振る舞い」と「ナレッジ」に分けて、チームで育てやすくする設計、
そして、WebでOS標準フォントを使うときの `sans-serif` / `system-ui` 指定の割り切り、
この五本を駆け足でお届けしました。
気になった記事があれば、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、そちらからゆっくりチェックしてみてください。
番組への感想や、「こんなテーマも取り上げてほしい」というリクエストも、いつでも募集中です。
あなたの開発現場でのモヤモヤや、最近ハマっている技術の話なんかも、ぜひ教えてください。
ということで、きょうはこのへんでお時間です。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。
それでは、いってらっしゃい。