どうも、マイクです。おはようございます。八月九日、日曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっとかつガッツリ紹介していきます。通勤中のあなたも、家でゆっくりコーヒー飲んでるあなたも、最後までお付き合いください。
きょうはですね、全部で五本の記事をご紹介していきます。どれも現場でそのまま役に立ちそうな、ちょっとマニアックなんだけど刺さる内容ばかりなので、気になったところがあったらあとでショーノートからチェックしてみてください。
まず一つ目。これは自宅AIサーバー構築のティップス系の記事です。
自宅にあるRTXごーきゅーまる、つまり最新世代のGPUマシンの上で、vLLMを使って「g p t オーエスエス にじゅうビー」というモデルのサーバーを立てて、それをOpen WebUIっていうチャット用のフロントエンドにつないでいます。で、「外から安全に触りたいよね」ということで、ここにTailscaleだけを使って、外出先のスマホからでも安全にアクセスできるようにした手順が、かなり実務的に解説されています。
面白いのが、モデルの使い方だけじゃなくて、「どう運用するか」まで踏み込んでいるところで、Claude CodeのRemote Control機能を使って自宅マシンを遠隔操作しているんですね。で、そこで「dispatcherパターン」というのを取っていて、まずdispatcher用のtmuxセッションが一個あって、そこからタスクごとに、新しいtmuxとClaude Codeのセッションを起動する、っていう形を取っています。こうすることで、長時間走り続けるタスクと、自分の指示出し用の作業スペースをきれいに分離できて、どのタスクがどこで動いているかも把握しやすい構成になっています。
vLLM自体は、GPU作業用のDockerコンテナの中で、「ゆーぶい」のコマンドを使って vllm serve を起動していて、OpenAI互換のAPIとして動かしています。ハードウェアがBlackwell世代のGPUなので、その環境向けにattentionのバックエンドやライブラリパスをちゃんと明示的に指定している点もポイントですね。モデルとして「g p t オーエスエス にじゅうビー」を選んだ理由も書かれていて、「三十二ギガバイトのVRAMがあれば、重みとKVキャッシュを載せてもまだ余裕があるから」という、かなり現実的な選定理由になっています。
ネットワーク構成も一工夫あって、GPU用コンテナとホストマシンが別ネットワークになっていたので、そのままだとOpen WebUIからvLLMに直接つなげないんですね。そこで、socatというツールを使って、ホスト側のローカルホスト、ポートははっぴゃくばんを、コンテナ側のアイピーアドレス、同じくはっぴゃくばんに転送しています。Open WebUIのほうはホスト側で、Dockerを network host オプション付きで起動して、このローカルのポートはっぴゃくばんに向けてつなぐ、という構成にしています。
アクセスの肝になっているのがTailscaleです。スマホと自宅マシンを同じテイルネットに参加させて、インターネットにポートを公開せずに、「httpコロンスラッシュスラッシュ テイルスケールのアイピー アドレス コロン さんぜんばん」に直接アクセスするスタイル。これによって、ドメインを取ったり、Cloudflare Tunnelを張ったりしなくても、閉じたチャット環境を実現できるというのが、この記事の大きなポイントです。自宅LLMサーバーを安全に外から使いたい人には、かなり参考になる構成になっていますね。
。。。。
二つ目の記事は、AIエージェントがなかなか業務で活躍してくれない、その根本原因と、その解決策としての「Context Ontology Accelerator」、略してCOAというAWSのオープンソースを紹介している内容です。
この記事では、「データはたくさんあるのに、『売上』とか『アクティブ顧客』といった業務上の意味がAIにちゃんと伝わっていないこと」が、エージェントがうまく動けない大きな理由だ、と整理しています。単にテーブルやドキュメントを読ませるだけだと、「この会社にとって売上ってどう定義されてるの？」「顧客って誰のこと？」みたいな文脈が伝わっていないわけですね。
そこで出てくるのがCOAです。COAは、データベースや文書をスキャンして、LLMを使ってオントロジー、つまり業務の概念とその関係性のモデルを自動で作ってくれます。それと同時に、ナレッジグラフと、RツーR M Lという「概念と実際のテーブルやカラムの対応表」も生成してくれるんですね。で、それを人間がレビューして、OKを出せるようになっている。承認されたあと、そのオントロジーをもとに、自然言語の質問からSPARQLとかSQLのクエリを自動生成して実行する、という仕組みになっています。
内部の構成としては、Neptuneに概念グラフ、これはスキーマだけ入ったグラフですね、それと、文書から抽出した事実を入れる文書グラフを保持します。さらにOpenSearch側には、検索用のベクトルを持たせておいて、質問に答えるときは三段階で処理する流れです。
まず一段階目は、売上などの「定義済みメトリクス」で答えられるかを試す。
それで足りなければ、二段階目として、オントロジー経由で構造化クエリ、つまりSQLやSPARQLを組み立てて実行する。
それでも足りないときは、三段階目として、文書グラフとテキストをまたいで検索して回答する、という形になっています。
検証の結果もかなり具体的で、日本語の質問から、JOINを含んだ正しいSQLが生成できたケースがいくつもあったそうです。さらに、Glueのカタログには明示されていない外部キー関係を、AIが推測してJOINに使ってくれた、なんていう例もありました。また、返品ポリシーの文書と、用語集の文書をまたいで情報を引っ張ってきて、ちゃんと引用付きで答えを返してくれたケースも確認できた一方で、情報が拾えないときには、ちゃんと「分からない」と答える挙動も観察されています。
COAの特徴として、よく比較されるのがdbtのセマンティックレイヤーや、Snowflake、Databricksのメトリクス定義です。そういった仕組みに比べて、COAは形式オントロジーを使って推論や制約検証ができること、そして生のテーブルだけじゃなくて文書まで含めた意味表現ができること、ここが強みだと説明されています。
なので、たとえば大規模なスキーマでText to SQLの精度が出なくて困っているチームだったり、「売上の定義」が部署ごとに乱立しているのを正したいガバナンス担当の人、あとはエージェントに信頼できるコンテキストをちゃんと渡したい開発者に向いている、とまとめられていました。
。。。。
三つ目の記事は、「社内メンバーだけが使える読み取り専用のMCPサーバー」を、Cloudflare AccessとCloudflare Workersだけで、かなりシンプルに実現する方法を紹介しています。
まずキーになっているのが、Cloudflare Accessの「Managed OAuth」という機能です。ここを使うことで、認証はすべてCloudflare側に任せる構成にしています。ユーザーはまずCloudflare Access経由でログインして、社内のアイディーピー、つまりログイン基盤からIDトークンを受け取ります。このトークンにはカスタムクレームとして、ユーザーが所属する組織IDといった情報が入っていて、Cloudflare Access側のポリシーで、そのクレームをチェックします。
その結果、特定の組織に属しているユーザーだけが、Workers上で動いているMCPサーバーに到達できる、という仕組みになっているわけですね。
この構成の良いところは、MCPサーバー側では認証情報を一切持たなくていい、という点です。権限管理とかトークン検証をアプリ側で実装しなくてよくて、Cloudflare Accessを「ちょっと強めの社内専用ウェブ保護」ぐらいの感覚で使える。その結果として、「社内限定かつ読み取り専用のMCP環境を、すぐに、しかも安全に立ち上げられる」というのが、大きなポイントとして強調されています。MCPに社内データを読ませたいけど、アクセス制御の実装はなるべくシンプルにしたい、というチームには、すごく実用的なパターンだと思います。
。。。。
四つ目は、非エンジニアが自分でデータを触れるようにするために、Snowflake上のデータウェアハウスと直結した「自作BIツール」を作った、という体験談です。
背景としては、社内の分析依頼が、どうしてもエンジニアの「ボランティア対応」になってしまっていて、依頼しても結果が出るまで時間がかかる。既製のBIツールはライセンスや運用コストが高くて導入しづらい。そうすると、重要な分析ほど後回しになってしまう。こうした問題意識から、「じゃあ自分たちで必要な機能だけを備えたBIツールを作ろう」となった、という流れが紹介されています。
作ったツールには、三つの柱があります。ひとつ目が、いわゆるダッシュボード機能。二つ目が、チャットから自然言語で質問して、裏でクエリを投げてくれる機能。三つ目が、与信モデルのシミュレーション機能ですね。フロントエンドはReactなどで実装していて、バックエンドではSnowflake上のDWHと直接つながっています。
データ側の設計としては、レイク、ウェアハウス、マートという三層構造に分けているのがポイントです。で、非エンジニアのユーザーには、いちばん上のMart層だけを見せるようにしています。この設計のおかげで、権限管理が単純化できて、「どの人にどのテーブルを見せるか」が分かりやすくなる。さらに、Martは集約済みで用途がはっきりしているので、表示速度も上がるし、数字の定義がブレない、つまり「売上ってどのカラムを見ればいいの？」みたいな混乱も防げる、と説明されています。
一方で、AIを使ってクエリを組める人だったり、自分でSQLを書けるような上級ユーザーには、もっと生に近いWarehouse層を見せる余地がある、とも述べています。つまり、「DWHのどの層まで見せるかは、その人がどこまでクエリを組み立てられるかで決めるべきだ」という考え方ですね。
また、基盤チームと業務側が同じチームとして動いたことで、業務の現場でどこが具体的に詰まっているのかがよく見えるようになり、その結果として、今後の基盤設計の精度もかなり上がった、というところまでが、重要な成果としてまとめられていました。
。。。。
最後、五つ目は、ウェブのセキュリティとブラウザの仕組みの基礎である、「オリジン」と「CORS」と「セッション」の関係を、かなり丁寧に整理してくれている記事です。
まず押さえるべきなのが「オリジン」です。これはスキーム、ホスト、ポート、この三つの組み合わせのことで、「サブドメインが違う」「ポートが違う」と、それだけで別オリジンになる、という話です。ブラウザは「同一オリジンポリシー」というルールに従っていて、悪意のあるサイトから、別のサイトのデータを勝手に読み取れないようにしています。この同一オリジンポリシーが、いろんな制約の前提になっているんですね。
その上で出てくるのがCORSです。CORSは、このきびしい制限の中で、「この特定のオリジンからのアクセスだけ、特別に許可しますよ」と宣言するための仕組みです。サーバー側がレスポンスヘッダーで「Access Control Allow Origin」などを返すことで、「このオリジンからのJavaScriptなら、このリソースにアクセスしていいよ」と伝えるわけですね。さらに、メソッドやヘッダーが複雑なリクエストについては、ブラウザが自動でプリフライトと呼ばれる事前確認のリクエストを飛ばして、安全かどうかを確かめます。
次にセッション。セッションは「同じユーザーからの一連のリクエスト」をひも付ける仕組みで、サーバー側に状態を持つセッションID方式と、署名付きトークン、たとえばJWTのような方式、大きく二つのパターンがあります。どちらの場合も、CookieやLocalStorageにどう保存するか、そしてXSSとCSRFにどう耐えるか、ここにトレードオフがあるので、きちんと理解して選ぶ必要があります。
実務上の注意点も、いくつか具体的に挙げられていました。たとえば、認証付きのAPIで安易に「Access Control Allow Origin をワイルドカード」にしないこと。CORSとCookie送信を組み合わせる場合は、サーバー側とクライアント側、両方で正しい設定が必要になること。Cookieには必ず「HttpOnly」「Secure」「SameSite」といった属性をつけること。そして、ログイン後にはセッションIDを再発行して、セッション固定攻撃を防ぐ、といったあたりですね。
さらにブラウザは最近だと、オリジンごとにプロセス自体を分離して、メモリレベルでもサイト同士のデータが混ざらないようにしていて、安全性を高めている、というところまで触れられていました。フロントとバック両方書くエンジニアにとって、かなり実践的なまとめになっている記事です。
。。。。
というわけで、きょうのzenncastでは、
自宅のRTXごーきゅーまるでvLLMとOpen WebUIを立てて、Tailscaleだけで安全に外から使う構成の話。
それから、業務の意味をAIに伝えるためのAWSのContext Ontology Accelerator、COAの仕組みとユースケース。
Cloudflare AccessとWorkersで、社内限定の読み取り専用MCPサーバーをシンプルに守る方法。
SnowflakeのDWHとつないだ自作BIツールで、非エンジニアにもデータを開いていく取り組み。
そして最後に、オリジンとCORSとセッションの基本と、実務での落とし穴と対策。
この五本を駆け足でご紹介しました。
気になる記事があった方は、詳しい内容をショーノートにまとめてありますので、ぜひそちらから元の記事も読んでみてください。番組の感想や、「こういうテーマも取り上げてほしい」といったリクエストも、どしどしお待ちしています。
それでは、きょうはこのあたりで。お相手はマイクでした。また次回のzenncastでお会いしましょう。お仕事の方も、お休みの方も、良い一日をお過ごしください。