おはようございます！ zenncast、MCのマイクです。11月12日、木曜日、朝7時になりました。みなさん、いかがお過ごしですか？
今日もZennでトレンドになっている記事を、気になるポイントとともにお届けします。今回は、AIに任せる開発から、データ分析、アプリ開発の新しい基盤まで、5本の記事をご紹介します！
....
まず1本目は、Webサービスの高速化を競うISUCONを、AIだけで解くために取り組んだお話です。
筆者は、この挑戦のために3か月をかけて、評価環境と競技用の仕組みを開発しました。AIに問題を解かせるだけでなく、どんな任せ方がよいのかを比較できる環境から用意したんですね。
過去問や自作問題を使って比較したところ、興味深い結果が出ました。細かな手順を指示したり、記録を求めたりする構成よりも、指示を減らしてAIに任せる構成のほうが、高得点を出したそうなんです。
そこで本番では、あれこれ手順を増やすのではなく、作業の継続や見直し、終了確認などを補助する仕組みだけを加えました。
この経験から筆者が述べているのは、最初から手順を作り込むより、まずは任せて実測し、失敗に応じて必要なものを補うのが有効だ、ということです。
ただし、すべてをAIに任せればよい、という話ではありません。評価環境に不備がないか、結果にどれくらいばらつきがあるかを見極めて、最終的にどの構成を採用するか。その判断は、最後まで人間が担いました。
AIへの指示を増やす前に、まず今の実力を測ってみる。そして、人間は評価の確かさを支える。この役割分担は、普段の開発でも参考になりそうですね。
....
続いて2本目は、SnowflakeのDashboards 2.0と、これからのBIについての記事です。
Snowflakeにあるデータを日々確認したい。それだけでも、従来はアプリを開発したり、別のBIツールを導入したりする必要があり、費用や権限管理の手間が課題になっていました。
そこで筆者が評価しているのが、数字の確認からAIへの質問まで、Snowflakeの中で完結できるDashboards 2.0です。
AIと会話しながらグラフを作ることができ、データの絞り込みやチームへの共有にも、既存の権限を使えるとのこと。別の場所に新たな仕組みを用意するだけでなく、その権限も管理する、という負担を減らせるわけですね。
こうした仕組みによって、簡単な可視化ならSnowflakeだけで済むようになります。
そのうえで筆者は、今後のBIには、追加の費用や管理の手間をかけてでも使いたいと思える、独自の価値が求められると述べています。
グラフを作れることだけではなく、その先に何を提供できるのか。データを使う側にも、ツールを選ぶ側にも、考えるきっかけになるお話です。
....
3本目は、Expoが公開したRust製のアプリ開発基盤、Exactをご紹介します。
Exactは、同じコードからWeb、iOS、macOSなどのアプリを作れる仕組みです。画面の表示にWebViewは使わず、それぞれのOSの標準部品や、ブラウザのDOMを使います。
画面はContractという専用言語で記述し、通信や保存の処理はTypeScript、またはRustで書く構成になっています。
特徴的なのは、AIエージェントが実装から動作確認まで進めやすい設計だということです。複数の環境で同じ操作やテストを使えるほか、文字のはみ出しやコントラスト不足も自動で指摘してくれます。
アプリが動くかどうかだけでなく、表示に問題がないかまで確認を進めやすいのは、気になるポイントですよね。
筆者が作った天気アプリでは、展開後のサイズがReact Native版の半分以下になり、起動速度はSwiftUI版とほぼ同じだったそうです。
ただし、まだ初期段階の基盤です。OS固有の機能への対応や、テスト時に通信を差し替えるところには、課題が残っています。
サイズや起動速度の結果には期待が膨らみますが、使いたいOSの機能や、必要なテストの方法に対応できるか。そのあたりも確かめながら見ていきたいですね。
....
続いて4本目は、人とAIが同じルールで分析するための基盤、Laplaceのお話です。
この基盤では、技術を選ぶよりも先に、担当者の役割、プロダクトごとのデータ分離、閲覧権限、そしてAIにどんな操作を許すのかを決めています。中心にあるのは、人とAIが同じ指標の定義と権限に従って分析する、という設計です。
まず、基盤の管理とデータの管理は分担します。指標が何を意味するのか、誰がそのデータを見てよいのかは、そのプロダクトをよく知っている開発者が判断する形です。
データの取り込み先はBigQueryのrawに統一し、加工はdbtで行います。さらに、プロダクトを追加するときに必要な設定は、原則としてファイル1枚にまとめています。
利用者の入口はLightdashに限定します。個人情報は専用のテーブルに分け、閲覧権限は期限付きで付与する。そして、誰が何を読んだのかを追えるようにしています。
AIについても、特別に広い権限を渡すわけではありません。利用者本人の権限で動かし、個人情報の行データや、権限を承認する操作は渡さない設計です。
また、分析結果には確認用のURLと、実行したSQLを添えます。結果だけを受け取って終わりにせず、人が根拠を確かめられるようにするんですね。
便利な分析環境を作るときに、誰が意味を決め、誰が何を見られて、AIはどこまで操作してよいのかを先に整理する。機能だけではなく、運用の責任まで含めて考えられた設計が印象的です。
....
最後、5本目は、AIエージェントが読み込む情報量と、コストや処理時間についての記事です。
AIエージェントは、作業が長引くほど会話履歴や資料の入力が増え、料金や処理時間が膨らむという問題があります。作業を続けるための情報が、そのまま負担にもなってしまうんですね。
記事ではNVIDIAの研究を紹介しながら、履歴は要点だけを引き継ぎ、資料は必要な部分だけを検索する方法の重要性を伝えています。毎回すべての文章を読ませるのではなく、必要な情報を渡すことで、精度を保とうという考え方です。
論文では、推論コストを最大で約9分の1に抑えたと報告されています。
一方で、筆者による小規模な検証では、よいことばかりではありませんでした。入力する情報量は減らせたものの、検索を繰り返すことで回答が遅くなり、文書全体の意味を取り違える例もあったそうです。
つまり、入力が少なくなったことと、回答が速く、正しくなることは、必ずしも同じではないんですね。
必要な部分をうまく探せているか、全体の文脈を落としていないか。コストだけでなく、待ち時間や回答の質も一緒に確かめたい、という示唆のある記事でした。
....
さて、今日のzenncastは、5本の記事をお届けしました。
ISUCONで見えた、AIへの指示を減らして実測する大切さ。Snowflakeの中で数字の確認からAIへの質問まで完結するDashboards 2.0。AIエージェントによる開発を見据えたExact。そして、人とAIが同じ定義と権限で分析するLaplace、最後に、AIが読む情報を絞る工夫と、その効果を確かめる難しさをご紹介しました。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。
番組への感想もお待ちしています。「この話が気になった」「自分の現場ではこうしている」など、みなさんの声を聞かせてもらえるとうれしいです。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価で応援してもらえるとうれしいです！
それでは、次回もみなさんとお会いできるのを楽しみにしています。今日もよい1日を。マイクでした！