おはようございます！ zenncast、MCのマイクです。10月15日、木曜日、朝7時になりました。今日もZennでトレンドになっている記事から、気になる話題をお届けします。朝のコーヒーのお供に、通勤や通学のお供に、どうぞ気軽にお付き合いくださいね。
今日ご紹介する記事は5本です。AIツールの検証から、生成AIの監視、業務システムの設計、データ・AI基盤の改善まで、実際に使うときに役立つ話題がそろっています！
....
それでは1本目です。逆解析ツール「REA」をClaude Codeに接続すると、調査の効率はどう変わるのか。プログラムを動かさずに調べる、静的解析で比較した検証記事です。
今回の検証では、REAを導入した場合と、導入しなかった場合を比べています。課題は、JavaScriptアプリと通信記録の2つです。
結果はというと、正確さは同等だったものの、効率の向上にはつながりませんでした。所要時間は最大2倍、API換算の費用は最大1.67倍になったそうです。新しい道具を追加すれば、そのぶん速く、安くなるとは限らないんですね。
ただし、筆者は検証の限界も示しています。それぞれの条件で試したのは1回ずつ。ですから、この結果だけで、いつでも同じ傾向になると決めつけることはできません。
そのうえで提案しているのが、新しい道具は普段使っている環境から分離し、危険な操作を制限して試すこと。そして、実際に時間や費用を測って、導入するかどうかを判断することです。
便利そう、という期待だけでなく、自分の作業で本当に効果が出るかを確かめる。新しいAIツールを試すときに、覚えておきたい姿勢ですね。
....
続いて2本目です。Claude Codeの使用量を減らすために、ローカルLLMでどこまで開発作業を代替できるのか、比較した記事です。
筆者が使ったのは、開発環境を動かした状態のMacBook Pro。M5搭載で、メモリは32GBです。この環境で、4つのローカルLLMを試しました。
単発の質問ではQwen3.5が安定していて、日本語の文章ではGemma4が自然だったとのこと。ただ、開発作業の代わりとして使うには、速度と確実さが足りなかったとしています。
具体的には、バグ修正に成功したのは4モデル中2つ。しかも、所要時間は5分から7分でした。一方、Claude Codeは18秒。今回の検証では、作業を任せてから結果が返ってくるまでの時間に、大きな差があったわけです。
さらに、RTX 3080を搭載したPCでは、処理が速くなったそうです。このことから筆者は、実用化を考えるならモデル選びだけではなく、メモリからデータを読み出す速さも重要だとしています。
文章を相談するのか、バグ修正まで任せたいのか。用途に加えて、動かすハードウェアも含めて見極める必要がある、というお話でした。
....
ここからは3本目。AWSの生成AIで、処理の記録や監視をどう設計するか、という記事です。
まず大切なのは、サービスごとに、自動で記録できる範囲が違うということ。Bedrockのモデル呼び出し、SageMakerのエンドポイント、そしてAgentCoreは、それぞれ分けて設計する必要があります。
Bedrockでは、処理の記録やトークン数を自動で取得できます。ただし、Python向けのライブラリー2種では、記録に使う属性名が異なります。また、併用すると二重に記録される可能性もあるので、注意が必要です。
一方、SageMakerでは、モデル名やトークン数を自分で追加します。さらに、一連の処理をつなぐ識別情報は、通常のHTTPヘッダーでは届きません。CustomAttributesを使って渡す必要があります。
AgentCoreにも、構成上のポイントがあります。公式の監視構成では、データの中継や加工を行うADOT Collectorは対象外で、ADOT SDKから直接データを送ります。ほかのサービスと同じ構成を、そのまま使うわけではないんですね。
記録する情報の扱いにも工夫が必要です。長いプロンプト本文は外部に保存して、記録には、その保存先を示す参照だけを残します。
そして費用は、トークン数と、別に管理する単価表を使って計算します。ただし、現行の自動取得データだけでは、キャッシュによる割引を反映できません。
自動で取れる情報と、自分で補う情報を分けて考えること。監視だけでなく、費用を把握するときにも大事になってきますね。
....
続いて4本目です。長年運用してきた業務システムを、どう改善していくか。本を読んで得た学びと、実際のコード改善の経験を振り返る記事です。
テストを整備しても、変更の手間がなかなか減らない。その背景には、処理の置き場所の問題があるかもしれません。
筆者が本から学んだのは、判断する処理を、その判断に使うデータを持つクラスに集めること。そして、業務で実際に使っている言葉で名前を付け、小さく改善していくことの大切さです。
ただし、学んだ設計を取り入れれば、必ずうまくいくわけではありません。実際のコード改善では、設計の前提が業務データに合っておらず、かえって処理が重複してしまった経験もあったそうです。
そこから筆者が重視しているのが、設計パターンを使う前に、実際の必要性とデータを確かめること。知識をそのまま当てはめるのではなく、必要なものを少しずつ取り入れるべきだと述べています。
きれいな設計に近づけることだけが目的ではなく、目の前の業務やデータに合っているかを確かめる。改善するときほど立ち返りたい視点ですね。
....
最後、5本目です。データ・AI基盤の品質や運用を、どう整理して改善していくか、という記事です。
データ・AI基盤では、技術的な仕組みづくりに比べて、品質基準や責任者を決めることが後回しになりがちです。でも、利用が広がるほど、あとから整理するのは難しくなります。だからこそ、早めに取り組むことが重要だとしています。
進め方は、診断、仕分け、改善の3ステップです。
まず診断では、データ管理の知識をまとめたDMBOKの11領域を使って、現状を評価します。どこが弱いのか、何から対応するべきか、優先順位を見つけるわけですね。
次の仕分けでは、改善策を「今すぐできること」「社内の合意が必要なこと」「追加投資が必要なこと」に分けます。まずは小さな改善で成果を示し、そこから社内の合意や投資につなげていきます。
改善には、Snowflakeの設計・運用の指針であるWAFを活用します。権限設定やコスト管理などを見直すための指針になりますが、責任者を誰にするか、全社ルールをどうするかは、組織として決める必要があります。
また、Cortex CodeのWAF Skillでは、AIが設定や利用状況を調べ、課題と改善手順をレポートにまとめてくれます。
AIに調査を助けてもらいながらも、組織として決めるべきことは、きちんと決める。技術と運用の両方から、少しずつ改善を進めるお話でした。
....
さて、今日のzenncast、5本の記事を駆け足で振り返りましょう。
REAとClaude Codeの組み合わせでは、新しい道具の効果を実測する大切さ。ローカルLLMの比較では、用途に応じた速度と確実さ、そしてハードウェアの重要性。AWSの生成AIでは、サービスごとに異なる記録と監視の設計をご紹介しました。
さらに、業務システムの改善では実際のデータと必要性を確かめること。データ・AI基盤では、診断、仕分け、改善の3ステップと、組織でルールを決める大切さをお届けしました。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。
そして、番組の感想もお待ちしています。「この話題が気になった」「自分の現場ではこうしている」など、気軽にお寄せください。この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回もお会いできるのを楽しみにしています。今日も、いい1日をお過ごしください。お相手はマイクでした！