どうもー、おはようございます。マイクです。
時刻は朝七時、二千二十六年九月二十七日、日曜日。
ここはZennのトレンド記事をゆるっと深掘りしていく「zenncast」。
この時間は、きょうZennで話題になっている記事をまとめてご紹介していきます。
きょうはお便りはお休みなので、そのぶんじっくり記事を追いかけていきましょう。
さて、きょうご紹介する記事はぜんぶで五本です。
ゲームAIから、Vercelのちょっとモヤっとする挙動、Claudeのクラウド環境活用術、プロンプト監査ツールのTips、そして「数字だけ返すAI」で問い合わせをさばく話まで、かなり幅広いラインナップになってます。
まず一つ目。
ゲームAIにJevを使うのって本当にアリなの？という検証と考察の記事です。
この筆者の方は、マリオのデモ用ハーネスを自分で改良して、そのうえでJevとDeepSeekという二つのモデルに「ワールド一の一」をプレイさせて、ちゃんと比較しているんですね。
で、その結果がかなりハッキリしていて、Jevはリアルタイムプレイだと一度もクリアできなかった。ゲームの進行を止めながら考えさせる、いわゆるゲーム停止方式にしても、クリア率がだいたい五十五パーセントくらいにとどまったそうです。
一方のDeepSeekは、同じくゲーム停止方式でプレイさせると、クリア率が九十パーセントまで跳ね上がる。
そこで筆者は、「じゃあこのDeepSeekが出した操作を正解ラベル扱いにして、古典的な機械学習モデルに蒸留してみたらどうなるか？」という発想で、LightGBMに学習させてみたんですね。
するとどうなったか。
まず推論速度が、JevのAPIと比べて、およそ千倍速くなった。
しかも、それだけスピードを上げても、リアルタイムでマリオを百回連続クリアできた、という結果になったそうです。
つまり、LLMにいきなりゲーム操作を全部やらせるより、「強いLLMで方針を出させて、それを教師データにして古典的な機械学習モデルを育てる」というパターンのほうが、速くて安くて、そして精度も高いよね、という話。
さらにJevについては、「タイプセーフAI」で、Calibrated Probability、つまり確率の信頼性をちゃんと出せるところに意義があるんだけど、ゲームAIのように、そもそも入力が自然言語じゃないケースでは、その強みがあまり活きない。
規約面の制約もあって、「確率の信頼性が特にいらない用途」なら、無理してJevを使う必然性はあんまりないんじゃないか、という結論に落ち着いています。
ゲームAIやリアルタイム制御をやっている方には、けっこう示唆の多い記事ですね。
。。。。
続いて二つ目。
こちらはVercelがGitHubリポジトリに対して送ってくる、「このリポジトリ、Vercelにインポートできますよ」という案内メールが、一体どういう条件で飛んでくるのかを検証したTips系の記事です。
まず分かったのが、「トリガーはリポジトリの作成そのものではなくて、pushイベント」であるということ。
リポジトリを作っただけでは何も起こらなくて、コミットをpushしてから、およそ五秒後くらいにメールが飛んでくる。
おそらくGitHub App側が、このpushをきっかけにリポジトリの中身を走査しているんだろう、と筆者は見ています。
で、このメールを送るかどうかの判定が、かなりザックリしている。
たとえば、package.jsonが壊れていても、存在しないバージョンを指定していても、どうやっても失敗するbuildスクリプトが書かれていても、とにかく「依存関係のところにNextとか、Viteとか、SvelteKitとか、そういう有名フレームワークの名前が文字列として含まれていれば」案内メールが来ちゃう。
ちゃんとJSONとしてパースしているというより、テキスト検索に近いノリで見ているんじゃないか、という指摘です。
トリガーになるのは、Nodeならpackage.json、Pythonならrequirements.txtとかpyproject.toml、Goならgo.modといった、「実行環境の設定ファイル」が置かれているディレクトリ。
ここにNext、Vite、SvelteKit、Remix、Flask、FastAPI、Goといった名前が依存として書かれていると、メール対象になるようです。
逆に、next.config.jsとかvite.config.ts、wrangler.jsoncみたいな設定ファイルだけ、あるいはDockerfileとか、HugoやJekyllの設定だけではメールは来ない。
RubyやRust系のスタックも検出自体はされているっぽいんだけど、少なくとも現状は通知の対象にはなっていないかもしれない、という話です。
おもしろいのが、ディレクトリの深さにもほとんど制限がなくて、「六階層下のpackage.json」なんていうのも普通に検出された、という点。
しかもprivateリポジトリも対象で、インストール済みのVercel GitHub Appに与えた権限の範囲内で、中身がきちんと読まれている。
こういう判定の仕組みって、利用規約的にはグレーゾーンではあるけど、ストレートに違反と言い切るのも難しいライン。
ただ、「デプロイのために渡した権限を使って、インポートしていない他のリポジトリまで勝手に読んで、Vercelへの誘導メールに使っている」という点は、ユーザーの感覚的にはプライバシーや期待値からだいぶ外れているんじゃないか、と筆者は問題提起しています。
対策としては、Vercel GitHub Appをインストールするリポジトリを「選択したものだけ」に絞るとか、不要なOrganizationからAppを外してしまうとか、通知設定を見直す、といった、権限とスコープをちゃんと管理するのが大事だよね、という締めになっていました。
。。。。
三つ目の記事は、Anthropicの「Claude Code クラウドセッション」についての詳しい解説とTipsです。
これ、名前のとおりコード向けなんですが、かなり便利な機能になっています。
何ができるかというと、「手元のPCを閉じちゃっても、クラウド上のVMで処理が動き続けてくれて、どの端末からでも同じセッションを再開できる」というもの。
対象のGitHubリポジトリをクローンして、Ubuntuベースの環境、スペックでいうと四つのvCPU、メモリ十六ギガ、ストレージ三十ギガくらいのVM上でコードを実行できます。
しかもPro、Max、Teamといった有料プランであれば、追加料金なしでこのクラウドセッションが使えるのがポイントです。
使い方のざっくり三ステップも紹介されていて、
まず一つ目が、対象のGitHubリポジトリにClaude GitHub Appを入れておくこと。
二つ目が、`.claude/`ディレクトリ以下に、そのプロジェクト専用のスキルや設定をコミットしておくこと。
三つ目が、デスクトップアプリ、ブラウザ、スマホのいずれかから、「クラウド環境」を選んでセッションを開始する、という流れです。
環境ごとに細かく設定ができて、ネットワークアクセスは「なし」「Trustedだけ」「フルアクセス」「カスタム」というように、どこまで外部に出ていいかをモードで選べる。
環境変数もそこでまとめて指定できますし、セットアップスクリプトも用意できるので、必要なツールやライブラリのインストールを自動化することもできます。
便利なポイントとしては、まず「ローカルセッションをクラウドに引き継げる」というところ。
手元でやっていた対話やコンテキストを、そのままクラウド側に持っていけるので、マシンをまたいだときの断絶が少ない。
さらに、APIキーを直接VMに渡さずに、プロキシ経由で安全に扱えるようになっていたり、アクセスを許すドメインをすごく細かく制限できたりと、セキュリティ面の気配りもかなり効いています。
日本のユーザーに嬉しいところとしては、タイムゾーンを`Asia/Tokyo`に設定しておける、みたいな実務的なTipも書かれていて、ログの時間がズレないのはありがたいですよね。
それから、セットアップスクリプトで好きなツールを入れておいたり、SessionStartフックを使って、ローカルとクラウドの両方で同じ初期処理を走らせる、といったテクニックも紹介されています。
さらにおもしろいのは、「用途ごとに環境を分ける」という運用の提案です。
たとえば、ルーティンのバッチ的な処理を走らせる環境では、アクセス先ドメインをRSSフィードのドメインだけに絞っておく。
一方で、人間との対話を重視する環境では、ネットワークはフルアクセスにしておく。
こうやって、プロンプトインジェクションなどのリスクを意識しながら、外部アクセス範囲を環境単位でちゃんと管理するスタイルを推奨しています。
リポジトリベースでこの設定を丸ごと管理できるので、「どの端末から触っても、同じ開発体験が再現できる」というのが、このClaude Code クラウドセッションの大きな魅力なんだ、というまとめでした。
。。。。
四つ目は、これまたClaude関連のTips系記事で、「/claude-api prompt-audit」というコマンドを中心に、モデル指定やeffort設定、ルールファイルの落とし穴なんかを一気に整理してくれている内容です。
まずメインの「`/claude-api prompt-audit`」というツール。
これは、プロジェクト内のskillsとか、CLAUDE.md、それから各種プロンプトやルール、コードまでをまとめて洗い出してくれて、古い書き方の指摘だけじゃなくて、「文章に書いてあることと、実際の挙動のズレ」まで指摘してくれる、というのがポイントです。
gitの履歴も踏まえながら、「なんでこういう設定や文言になっているのか」という理由付きで、修正案のdiffを出してくれる。
不要そうな指示を削除候補としてあげるときも、「本当に消して大丈夫か」を、挙動テストまで含めてチェックしてくれるので、プロンプトやルールのリファクタリングをするときにかなり心強いツールになっています。
次に、モデル指定の話。
`opus`みたいな別名、エイリアスでモデルを指定していると、気づかないうちに裏側で「Opus五点五」とか、新しい実モデルに切り替わっていることがあります。
なので、`claude -p --model opus --output-format json`を実行して、そのレスポンスに含まれる`modelUsage`の情報をチェックして、「いま実際にはどの実モデルIDを使っているのか」を必ず確認した方がいいよ、という注意喚起です。
effort、つまり思考量の設定も、ハマりポイントとして紹介されています。
効く場所は三つだけで、
一つ目が`settings.json`の全体`effortLevel`、
二つ目が`modelSettings`配下の「実モデルIDごとの設定」、
三つ目がCLIでの`--effort`フラグ。
エージェント定義の中に`effort:`と書いても、あるいは`--agents`で何か指定しても、そこではeffortは変わらない。
しかも、どの値が最終的に効いているかが起動ログには出てこないので、`~/.claude/projects/<プロジェクト名>/*.jsonl`のログを`"effort":`で検索して、実際にどの値になっているか確認する必要がある、という具体的な方法まで載っています。
ルールファイル周りでよくあるのが、`paths:`で既に消えているファイルを指し続けていたり、不要なAPIキーが残っていたり、「現在地」の説明テキストと実際の運用が食い違っていたり、自分自身を待ち続けるシェルループみたいな不具合が、設定と実物の不一致としてゴロゴロ出てくる問題。
これに対しては、grepと設定ファイルを組み合わせて、「文章に書いてあること」と「コードや実行環境で本当に起きていること」をきちんと突き合わせて確認しよう、という提案がされています。
もうひとつ印象的なのが、CLAUDE.mdから「事故防止用のチェック項目」を消すときの話。
例えば「禁止を、そのまま不可能とは受け取らないようにする」といった項目を消すかどうかを判断するには、消した版と残した版の両方で、同じ課題を何度か解かせて比較する。
記事の中の例だと、その「禁止を不可能とみなさない」という項目だけは、有無で結果がはっきり変わってしまったので、その項目だけは残す判断をした、というエピソードが紹介されています。
最後に、JSONを返させるときのベストプラクティス。
プロンプトに「JSONで返してください」と書き連ねるよりも、CLIの`--json-schema`を使って、スキーマを渡してしまうほうが、安全に構造化された出力を受け取れる。
このとき、ルートは必ず「object型」にしておいて、結果は`result.structured_output`から読むようにする。
もし間にプロキシなどの中継サービスを挟んでいる場合は、そのプロキシ側がスキーマ情報をちゃんと維持してくれているか、途中で捨ててないかにも注意しよう、という、かなり実務寄りのTipsがまとまっていました。
。。。。
そして五つ目。
これはLLMそのものではなく、「数字だけ返すAIを使って、社内の問い合わせを自動で振り分ける」という試みについての解説と考察の記事です。
筆者が使っているのは、TypeSafe AIのJevという仕組みで、普通のチャットボットのように文章を生成するのではなく、「定義された質問に対して、確率やスコアといった数字だけを返してくる」タイプのモデルです。
具体的には、問い合わせの文章を入力すると、
「ドキュメントを読めば自力で解決できそうかどうか」、
「エンジニアが調査しないと解決できなさそうか」、
「カスタマーサポートで一次対応できそうか」、
「緊急度はどのくらいか」、
といった、五つの質問に対する確率やスコアだけをJevから受け取ります。
そのうえで、その数値をPython側のルールで解釈して、
「ドキュメントへの案内でよさそう」「CSで一次対応に回そう」「開発チームへのエスカレーションが必要」といった三つのパターンのどれに自動振り分けするかを決めている、という仕組みなんですね。
Jevの良いところは、文章を生成しないぶん、処理が安くて速いこと。
それから、出力形式が最初から固定されているので、システム側から扱いやすい、という点もあります。
ただし、その代わりに、「なぜそう判断したのか」という説明は返ってこない。
なので、こちら側の質問の設計とか、スコアのしきい値の設計を間違えると、モデルの判断そのものは妥当でも、最終的な結論の振り分けがズレる、ということが起こりやすい。
記事では、八件分のテストを通じて検証した結果が紹介されていて、誤判定の多くは、モデル側の性能というよりは、ルール設計のまずさに起因していた、という分析になっています。
特に、「緊急度」や「確信度、コンフィデンス」をどういうしきい値で扱うかが重要で、どこからを「緊急」とみなすか、どこまでならCSで頑張るのか、その境界線のチューニング次第で、成果がガラッと変わる。
つまり、「数字だけ返すAI」は扱いやすくて魅力的だけれども、システム側のルール設計をきめ細かくやらないと、せっかくのCalibratedな確率情報をうまく活かせないし、現場感覚ともズレてしまうよ、という教訓が語られていました。
問い合わせの自動振り分けを検討しているチームには、かなり実践的なヒントになる内容だと思います。
。。。。
ということで、きょうのzenncast、お届けしてきた内容をサッとおさらいしていきましょう。
まず一つ目は、マリオの一の一でJevとDeepSeekを比較して、「強いLLMで方針を出してからLightGBMに蒸留したほうが、速くて安くて高精度」というゲームAIの検証記事。
二つ目は、VercelのGitHub Appが、pushイベントをトリガーにリポジトリの中身を走査して、「有名フレームワーク名が依存に書いてあるとインポートできますメールを送ってくる」という、ちょっとグレーな挙動と、その対策についてのTips。
三つ目は、AnthropicのClaude Code クラウドセッションで、クラウド上のUbuntu環境を活用して、どの端末からでも同じ開発体験を再開できる、その使い方とセキュリティ意識した環境分割の話。
四つ目は、`/claude-api prompt-audit`を軸に、プロンプトやルールのズレを洗い出す方法、モデルIDとeffort設定の落とし穴、JSONスキーマ活用のベストプラクティスなど、Claude運用の実践Tips。
そして最後五つ目が、Jevのような「数字だけ返すAI」を使って、社内問い合わせをドキュメント案内・CS一次対応・開発エスカレーションの三択に自動振り分けする試みと、その成否を分けるのはルール設計、とくに緊急度や確信度のしきい値だよ、というお話でした。
それぞれの記事の詳しい内容や図解、具体的な設定例なんかは、この番組のショーノートにリンクをまとめてありますので、気になったトピックがあれば、ぜひそちらから元記事をチェックしてみてください。
このzenncastでは、リスナーのみなさんからの感想や、「こんなテーマを扱ってほしい」「この技術がいま熱いよ」といったお便りも随時募集しています。
日々の開発での気づきや、Zennで読んだおすすめ記事なんかも、ぜひシェアしてもらえると嬉しいです。
それでは、きょうはこのへんで。
お相手はマイクでした。
次回のzenncastで、またお会いしましょう。
良い日曜日をお過ごしください。