どうも、こんばんは。マイクです。
今日も始まりました「ゼンキャスト」。お聞きの時刻は、二千二十六年八月四日、火曜日の朝七時でございます。
この時間は、技術情報プラットフォーム Zenn に上がっている、今日のトレンド記事をピックアップしてご紹介していきます。

今日はお便りの紹介はお休みで、そのぶんじっくりと記事を見ていきたいと思います。

さて、今日ご紹介する記事はぜんぶで五本です。
AI に業務知識を渡すための新しい仕組みから、Claude Code のスキル活用、Unity の DI、Web セキュリティの基本、そして Vue.js の開発を激速にするツールまで、かなり幅広いラインナップになってます。順番にいきましょう。

まず一本目。
AI に、業務の知識をどうやって正しく渡していくか、その課題にガチっと向き合ったサービスの紹介記事です。

取り上げられているのは、AWS がオープンソースで出している「コンテキスト・オントロジー・アクセラレーター」、略して COA という仕組みです。
これは、業務で使っているデータベースとか、社内ドキュメントなんかをスキャンして、そこから「業務の意味」を表すオントロジーと、ナレッジグラフを自動で作って、AI エージェントに渡してあげるためのプラットフォームになっています。

処理の流れは大きく三段階で説明されています。
まず一つ目が「スキャン」。データベースや文章をざーっとなめて、テーブルの外部キーとか、業務メタデータを AI が推論してくれます。Glue に無い外部キーも、AI が見つけ出して、あとで JOIN に使えた、という実例も紹介されています。

次に二つ目が「モデル」。ここで OWL と R 二エムエル、R二アールエムエルという形式で、オントロジーを提案してくれます。それを人間が確認して承認し、さらに推論エンジンで整合性チェックをして、問題なければ正式なモデルとして確定していきます。

最後三つ目が「サーブ」、つまり提供のフェーズです。
ここでは、自然言語での質問から、まずどんなメトリクスを呼び出すべきかを決めて、それを元に SPARQL や SQL のクエリを自動生成し、ナレッジグラフを検索して答えを出します。この「自然言語 → メトリクス → クエリ → ナレッジグラフ」という三段構成になっているのがポイントですね。

何がすごいかというと、「言葉とテーブル列の対応関係」とか、「売上って、この会社ではどういう定義なんだっけ」といった、本来あいまいになりがちな業務知識を、機械が読めて、しかも検証もできる資産として、ちゃんと明示化してくれるところです。

記事の中では、構造化されたデータと、日本語のドキュメントを、同じ入り口からまとめて問い合わせできる様子とか、「これは分からない」と AI がきちんと答えてくれる、安全寄りの設計なんかも、画面イメージと実測値つきで詳しく紹介されています。
業務で AI を使いたいけど、「用語の意味がチームごとに違う問題」に悩んでいる人には、かなり刺さる内容になっていましたね。

。。。。

続いて二本目。
こちらは Claude Code の「スキル」を、コードを書く拡張機能じゃなくて、「マークダウンで書いた作業手順書を元に動く仕組み」として捉え直して、それをうまく活かしたお話です。

筆者の方は、この性質を利用して、Zenn 記事の下書きを自動で作る「スラッシュ・アーティクル」、スラッシュ記事というスキルを作っています。

このスキルが何をやるかというと、まず今のセッション内容を振り返って、今日の学びを一つ選び出します。そのうえで、機密情報になりそうな部分を削りつつ、Zenn 形式のマークダウンで下書き記事を生成してくれます。
そして最後に、その下書きを GitHub にプッシュするところまで、一連の流れを全部自動でやってくれるようになっています。

ここで大事にしているルールがいくつかあって、まず記事のフロントマターには、必ず「パブリッシュド・フォルス」、つまり非公開フラグを付けること。公開するかどうか、機密情報が入っていないかのチェックは、必ず人間が行うようにしているんですね。

つまり、自動化はあくまでも「面倒な前工程を減らす」範囲にとどめていて、「勝手に公開する」という危ない部分には踏み込まない、という安全設計になっています。

これによって、「とりあえず今日の学びを、下書きという形で残しておくか」くらいの軽いノリで、技術記事のタネをどんどんストックできるようになった、と書かれています。
記事にするハードルがぐっと下がって、アウトプットの量と質を両方上げられそうな、面白い活用例ですね。

。。。。

さあ、三本目。
今度は Unity での DI、依存性注入についての考察と、ライブラリ選びのお話です。

Unity のプロジェクトが大きくなってくると、あちこちで「ゲームマネージャー・インスタンス」とか、「ゲット・コンポーネント」だらけになってしまって、テストしづらいし、実装を差し替えるのも大変、という問題が出てきますよね。
この記事では、DI というのは、依存関係をクラスの外から渡して見える化しつつ、オブジェクトの寿命の境界も含めて整理していく技術なんだ、という説明から入っています。

ただ、Unity には MonoBehaviour や Scene、Prefab という、エンジン特有の仕組みがあるので、何でもかんでも DI に乗せればいいわけではないと。
差し替えや共有が必要になる「通信」「入力」「セーブ処理」みたいな部分に絞って DI を使っていくのが現実的だ、とされています。

具体的には、Scene ごとのスコープをちゃんと切り分けたり、Prefab の生成については、Factory パターンを使って統一してあげる。逆に、コンテナに何でも登録しておいて、あちこちから「リゾルブ」しまくるような、サービスロケータ的な使い方は、失敗例として挙げられています。
同じく、全てのクラスを無理やりインターフェース化するのも、設計が重くなりすぎてよくない、と。

ライブラリの話もかなり具体的です。
まず Zenject は、Unity 向け DI を広めた功績はものすごく大きいものの、二千二十年ごろから更新が止まっていて、豊富な独自機能にベッタリ依存してしまうと、将来の移行コストが一気に上がってしまう懸念があると指摘しています。
とはいえ、今すでに Zenject で安定稼働しているプロジェクトを、スピード面とか、更新が止まっているという理由だけで、無理やり別ライブラリに移す必要はない。残りの運用期間とか、チームに自前でパッチを当てる力があるかどうかで判断しよう、という落としどころです。

一方で、Reflex と VContainer は、Unity シックス系にもきちんと追従しているライブラリとして紹介されています。
Reflex は API がコンパクトで、Scene への注入や Source Generator も備えていて、Zenject より高速に動きつつ、依存関係を漏らしにくい設計を取りやすいのが評価ポイント。
VContainer は、プレイヤーループや UniTask との統合まで含めて、ライフサイクルを丸ごと管理したいケース向けで、機能が広いぶん、やや重装備だという位置づけになっています。

まとめとしては、既存案件で Zenject がちゃんと安定しているなら、そのまま維持で OK。
新しく始めるなら、まずは Reflex を第一候補にして、ゲームループや非同期処理までガッツリ統合したいときは VContainer。
小規模なら、いきなりコンテナに行かず、手動で DI するところから始めよう、という方針を推奨しています。

そして最後に、「DI コンテナは設計そのものの代わりではない」と強調しています。あくまで、依存関係と寿命管理を自動化してくれる道具なので、ライブラリ固有の型をゲームロジック側にべたっと漏らさないようにして、あとから入れ替えできる余地を残しておくことが大事だ、と結論づけていました。

。。。。

四本目。
ここからは Web のセキュリティの基本ど真ん中、「オリジン」「CORS」「セッション」について、丁寧に整理してくれている記事です。

まず、オリジンというのは何かというと、「スキーム」「ホスト」「ポート」、この三つの組み合わせで決まります。
つまり、エイチティーティーピーとエイチティーティーピーエスでスキームが違ったり、サブドメインが違ったり、ポート番号が違ったりすると、それだけで別オリジンとして扱われるわけですね。

ブラウザは、このオリジンごとに強い制限をかけることで、別のサイトのスクリプトから、自分のサイトのデータが勝手に読まれないように守っています。これが「同一オリジンポリシー」です。

ただ、フロントエンドと API サーバーが別ドメインにある現代の構成だと、この制限がそのままだと困るケースが多いので、そこで出てくるのが CORS、クロスオリジン・リソース・シェアリングです。
サーバー側がレスポンスヘッダーで「アクセス・コントロール・アロー・オリジン」などを返すことで、「このオリジンからのアクセスだけは許可しますよ」と、例外的に扉を開けてもらう感じですね。

特に、PUT メソッドを使ったり、カスタムヘッダー付きのリクエストを送る場合には、いきなり本番リクエストを飛ばす前に、「オプションズ」メソッドでプリフライト、事前確認を行います。
そこでサーバーが OK を出したときだけ、本当のリクエストが送られる、という二段構えになっています。

続いてセッションの話。
HTTP は本来「状態を覚えない」プロトコルなので、同じユーザーからの一連のやり取りを識別するために、セッションという仕組みを追加で使います。
実装方法としては、サーバー側に状態を持つセッション ID 方式と、署名付きトークン、いわゆる JWT を使う方式の二パターンがある、と解説されています。

どちらの方式でも、Cookie の設定がものすごく大事で、ここを間違えるとそのまま攻撃につながるおそれがあります。
具体的には、「エイチティーオンリー」「セキュア」「セイムサイト」この三つの属性は必ず付けよう、という話。
さらに、ログイン後にはセッション ID を再発行して、固定セッション攻撃を防ぐ、といった運用面の注意点も挙げられています。

そして最後に、現代のブラウザは、オリジンごとに別プロセスでタブを動かしていて、他サイトのメモリを直接読み取れないように分離している、という話も紹介されています。
このプロセス分離と、同一オリジンポリシー、それから CORS とセッションの設計が組み合わさることで、今の Web 全体の安全性が成り立っているんだ、という全体像が分かる内容になっていました。

。。。。

そしてラスト、五本目。
Vize という、Vue.js 向けの統合ツールチェーンのお話です。これは Rust で作られていて、コンパイラ、リンタ、型チェッカー、フォーマッタなどをひとつの共通基盤で動かすことで、型チェックと Lint を桁違いに高速化できるのが売りになっています。

記事では、TypeScript セブン時代に入って、従来の vue-tsc だけではなかなか得られなくなってきた高速化をどう補うか、という文脈で、社内のリアルなプロダクトに Vize を試験導入してみた結果が紹介されています。

導入手順は意外とシンプルで、エヌピーエムスクリプトと Vite プラグインを差し替えるだけ。
それでいて、型チェックは最大でおよそ八倍、Lint は七十倍以上という、かなりインパクトのある高速化が確認されています。ビルド時間も、少しではあるものの、ちゃんと短くなったそうです。

速度だけじゃなくて、検出できる問題の種類もパワーアップしていて、たとえば HTML の不正なネストとか、props のシャドーイング、あとは XSS やアクセシビリティに関わる問題など、これまでのツールチェーンでは見逃していた指摘も、きちんと拾えるようになっていました。

現時点では、まだ本番運用というよりは、実プロダクトでの試験段階という位置づけなんですが、Vue.js の開発体験を大きく変えうる存在として、今後の成熟と採用拡大に期待したい、という形で締めくくられています。

。。。。

というわけで、今日のゼンキャストでは、
一つ目に、AWS の COA で、業務知識をオントロジーとナレッジグラフとして AI に渡していく取り組み。
二つ目に、Claude Code のスキルを「作業手順書」として活かして、Zenn 記事の下書きを自動生成するスラッシュ記事の話。
三つ目に、Unity での DI 活用と、Zenject・Reflex・VContainer の使い分け方針。
四つ目に、オリジン・CORS・セッションと、ブラウザのプロセス分離をあわせて理解する Web セキュリティの基本。
そして五つ目に、Rust 製の Vize を Vue.js プロダクトに試験導入して、型チェックと Lint を劇的に高速化した事例。
この五本をご紹介しました。

気になる記事があった方は、詳しい内容や元の記事へのリンクを、ショーノートにまとめてありますので、そちらからぜひチェックしてみてください。

番組への感想や、「こんなテーマも取り上げてほしい」といったリクエストも、お待ちしています。あなたの一言が、次回のラインナップを決めるヒントになるかもしれません。

それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回のゼンキャストでお会いしましょう。お聞きいただき、ありがとうございました。