おはようございます！ zenncast、マイクです。10月10日、土曜日、朝7時。週末の朝、みなさんいかがお過ごしでしょうか。
今日もZennでトレンドになっている記事から、気になる話題をお届けします。今回は、AIエージェントの使い分けから、データの扱い、クラウド環境の運用、そしてセキュリティまで、5本の記事をご紹介します！
....
まず1本目は、サブエージェントに仕事を任せるときの、モデルと報告形式の選び方です。
ポイントは、すべての仕事を同じモデルに任せるのではなく、役割に合わせて選ぶこと。テストやビルドを実行して、その結果を整理する仕事は、安価なHaiku 5.5に任せます。一方で、判断が必要な実装や、変更後の確認を伴う仕事はSonnetに残す、という使い分けです。
コード調査については、筆者の比較では、HaikuでもSonnetと同等の回答品質が得られたそうです。ただし、速くなったわけではありません。費用を優先したいのか、それとも待ち時間を優先したいのか。ここによって、選ぶモデルは変わってきます。
そして、モデル選びと同じくらい大切なのが、報告の仕方です。調査結果では、確認できた事実と、そこから考えた推論を分けて書いてもらいます。根拠になったファイルと行番号、どんな方法で検索したか、まだ確認できていない範囲も示してもらうんですね。
さらに、サブエージェントを呼び出した側が根拠を確認する運用に変えたところ、Haikuが必要以上に調べすぎることを抑えられたそうです。
コマンドの実行結果では、「実行して失敗した」のか、「そもそも実行していない」のかを、きちんと区別します。実装を任せる場合も、変更した内容だけでなく、省いた作業や、確認できなかったことまで報告してもらう。こうした報告の設計が、見落としを減らすことにつながります。
任せる相手だけでなく、何をどう報告してもらうかまで決める。AIとのチームづくりでも、大事なところですね。
....
続いて2本目は、JSONの読み取り結果が、実装によって変わるというお話です。
JSONは仕様がシンプルなので、同じデータなら、どこで読んでも同じ結果になりそうですよね。でも実際には、言語やデータベースによって違いがあります。この記事では、その差を3つの観点から比較しています。
まずは数値です。整数と小数をどう区別するか、どの範囲まで保存できるか、そして、どのように丸めるかが異なります。大きな数を読み込んだとき、ある実装ではエラーになり、別の実装では無限大になることもあります。負のゼロの扱いにも差があるんです。
次に、Unicode文字の表現に使われるサロゲートです。これが片方だけ現れた場合、エラーにする実装もあれば、そのまま残す実装、別の文字に置き換える実装もあります。同じ入力でも、処理の結果が分かれるわけですね。
そして3つ目は、オブジェクトのキーです。同じキーが重複していると、最初の値を採用する場合、最後の値を採用する場合、エラーにする場合があります。また、キーの並び順も、必ず保存されるとは限りません。
こうした違いを減らすための仕様として、I-JSONがあります。ただ、それですべてが解決するわけではない、という点にも注意が必要です。
異なる環境同士でデータを交換するときは、「JSONだから大丈夫」で終わらせず、数値、文字、キーがそれぞれどう扱われるかを確認したいですね。
....
3本目は、AIエージェントにFabricを操作してもらうための、ツールとスキルの組み合わせです。
ここでいうスキルは、使い方をAIに教える文書のこと。実際に操作するツールと、その使い方を伝えるスキルを組み合わせて利用します。
基本操作にはFabric CLIを使い、SQLや障害調査にはSkills for Fabricを使う、というのが記事で紹介されている使い分けです。CLIは、IDの取得や、実行が完了するまで待つ処理を、決まった手順で進めます。AIが毎回その処理を組み立てるより、誤りを減らせるんですね。
安全面では、書き込みや削除を実行する前に、人が確認する設定にします。ただ、本番環境への誤操作を確実に防ぐなら、確認の設定だけに頼らず、本番の書き込み権限を持っていないアカウントを使うことが重要です。
接続先の確認も欠かせません。Fabric CLIとAzure CLIが接続する組織をそろえ、作業対象のワークスペースを明示します。さらに、認証トークンが入ったファイルは、AIに読ませないようにします。
Gitで変更を管理している場合は、環境を直接書き換えるのではなく、Git経由で反映する方針を決めておきます。
記事では、Lakehouseの作成、CSVの取り込み、SQLでの集計まで、実際の動作を確認しています。便利に動かすための手順と、触ってよい範囲を決める仕組み。この両方を用意することが、安心して任せるための土台になりそうです。
....
続いて4本目は、Custom AMIを使った環境で、Slurmを安定して運用するための注意点です。
まず気をつけたいのが、ソフトウェアの導入済み判定です。すでにインストールされていると判断されたことで、必要な初期設定まで省略される場合があります。そのため、インストールと設定の処理を分け、Slurmが起動する前に、必要な設定を確実に適用することが大切です。
ノードを追加するときには、初期化処理とSlurmへの登録が、お互いの完了を待ってしまうこともあります。これに備えて、登録を後から再試行できる仕組みを用意します。
また、独自に入れた設定は、更新処理や設定生成スクリプトによって変わる場合があります。検証するのは新規作成のときだけではありません。ノードの追加、置換、更新も試して、設定が保たれているか、ジョブが実行できるかまで確認します。
AMIの更新時には、初期化スクリプトが再実行されます。AMIとスクリプトのバージョンをそろえ、まずは少数のノードから試す進め方が紹介されています。
終了したジョブのプロセスが残ってしまう問題には、proctrack/cgroupを使ってプロセスを追跡します。資源制限も導入する場合は、自動復旧機能との互換性を確認する必要があります。
さらに、メモリ制限はジョブ単位で設定するだけでは不十分です。実測値からOSが使うための余裕を差し引き、割り当てるメモリの総量も制限します。なお、記事ではGPU側の調整はまだ完了していないとのことです。
作れたら終わりではなく、増やしたとき、入れ替えたとき、更新したときにも動くか。運用の中で起こる変化まで見据えた検証が大切ですね。
....
最後、5本目は、ClaudeのWindows版や通信、セッションの扱いを調べた、セキュリティのお話です。
まず、インストーラーの電子署名からは、発行元と、改ざんされていないかを確認できます。今回調べたClaudeのWindows版では、Anthropicの有効な署名が確認できたそうです。
ログインについては、メールアドレスだけではログインできません。一方で、Cookieの中にあるsessionKeyは、ログイン済みであることの証明になります。これが漏れると、本人としてアクセスされる危険があります。不審なセッションがあれば、設定から終了できます。
通信がHTTPSで暗号化されていても、その暗号化が守る範囲には限界があります。今回調べた環境では、通信を検査するESETも、本文を読める位置にありました。HTTPSだから、あらゆる場所で内容を読まれないとは限らない、ということですね。
ファイルのプレビューURLについても確認しています。調べたURLは、知っているだけではファイルを取得できませんでした。同じアカウントでは表示できましたが、別のアカウントでは拒否されたそうです。
そして、Incognitoでの会話も、サーバー上には一定期間保存されます。会話を削除したあとにAPIから取得できなくなったとしても、それだけで保存データが即座に消えた証拠にはなりません。公式説明では、個人向けClaudeの会話は30日以内に削除されるとされています。
署名が確認できること、セッションが本人の証明になること、そして、画面やAPIで見えなくなることと、保存データが消えることは別だということ。それぞれを分けて理解しておきたいですね。
....
さて、今日のzenncastは、5本の記事をご紹介しました。
サブエージェントは、役割に合わせたモデル選びと報告の設計が大切。JSONは、実装による数値や文字、キーの扱いの違いに注意。FabricのAI操作では、ツールとスキルを組み合わせて、権限や接続先をしっかり管理する。Custom AMIとSlurmの運用では、追加や更新まで含めた検証を。そしてClaudeのセキュリティでは、署名、セッション、暗号化、データ保存の範囲を分けて考える、というお話でした。
詳しい内容はショーノートに書いてありますので、気になった記事はぜひチェックしてみてください。
番組の感想もお待ちしています。「この話題が気になった」「自分の環境ではこうだった」など、ぜひ気軽にお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回またお会いできるのを楽しみにしています。素敵な土曜日をお過ごしください。お相手はマイクでした！