どうも、マイクです。おはようございます。
九月十日、木曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。通勤・通学の準備しながら、コーヒー飲みながら、耳だけ貸してもらえたらうれしいです。
さて、きょう紹介する記事は、ぜんぶで五本です。
LLMの賢い使い方から、開発をガンガン効率化してくれるツール、それからお財布を守るクラウドの話、最後はReactのハマりポイントまで、技術者の心に刺さるネタが揃ってますよ。
それでは、さっそく一つ目からいきましょう。
まず一つ目は、LLMを使うときの「コスパ」と「性能」をどうバランスさせるか、その実践的なコツをぎゅっとまとめたTips系の記事です。
ポイントは、いきなり一番高いモデルをドーンと使うんじゃなくて、「最新かつ安めのモデルをまず試してみる」ところからスタートしよう、という考え方なんですね。そこから、必要に応じてエフォートの調整をしたり、上位モデルに切り替えたりして、自分の用途にとっての「必要十分な性能」を探していく。簡単なタスクに、いつも最上位モデルを使いすぎないのが、コスト面でも大事だよ、というお話です。
それから、プロンプトの書き方も、昔のノウハウを一回リセットしたほうがいいんじゃないか、という指摘があります。各社が出している最新のガイドラインをちゃんと読み込んで、プロンプトはできるだけ短く、シンプルに。不要な指示をだらだらと詰め込むと、逆に性能もコストも悪化してしまう、というのは耳が痛い人も多いかもしれません。
会話の組み立て方も重要で、モデルやエフォートを会話の途中で頻繁に変えないこと、それから「キャッシュ」を切らさないように工夫するのがポイントになっています。たとえば、固定の指示はメッセージの先頭に置いて、リクエストごとに変わる情報は後ろに置く。キャッシュの有効期限切れにも注意しながら、なるべく同じ指示部分を再利用できるように設計すると、レスポンスも安定しやすいし、料金も抑えられると。
APIから使う場合のテクニックも具体的で、たとえば共通の資料部分だけをキャッシュさせておいて、そこに対して質問を投げる形にするとか、一度だけ先行リクエストを流してキャッシュを書き込んでから、本番の処理を並列実行するとか、「キャッシュの書き込み」と「読み出し」を意識した設計が紹介されています。
さらに、検証やフィルタリング、集計といった「プログラムで自動チェックできる処理」は、できるだけLLMに任せず、コードやテストでやりましょう、というスタンスです。ツールの説明や検索結果も、前処理やCLIツールであらかじめ絞り込んでおいて、本当に必要な情報だけをLLMに渡す。無駄に長い入力を食べさせないことで、品質もコストも両方守る、という発想ですね。
会話履歴の要約、いわゆるコンパクションについても、「常にコンテキスト上限ギリギリまで伸ばそうとしない」ことを推奨しています。要約は区切りの良いところでだけ行う。長すぎる履歴は、料金がかさむだけじゃなくて、逆に出力品質を落とすこともあるんだよ、という注意喚起です。
あとは、Batch APIの活用とか、中国系の安価で高性能なモデルを、レスポンスを急がない処理や、機密度が低い用途で使っていく、というアイデアも出てきます。リアルタイム性がそこまで要らないバッチ処理なんかでは、「別ルート」を検討するだけで、大きなコスト削減につながるかもしれないよ、と。
最後に効いてくるのが、「エックスとかのインフルエンサー情報は鵜呑みにしない」というスタンスです。派手なノウハウよりも、公式ドキュメントと、手元のモデルを使って、自分の用途前提でちゃんと検証してみる。そのほうが、結局は速くて正確なことが多い、とまとめられています。
LLMを実戦投入しているチームにとっては、運用ルールを見直すいいチェックリストになりそうな記事でした。
。。，。。
続いて二つ目。こちらは「Claude Code Desktop」、このデスクトップクライアントの今の使い勝手を、開発環境目線で詳しく紹介している記事です。
以前は「重いし、機能も少なくてちょっと微妙だな」と筆者は感じていたそうなんですが、いまはガラッと変わっていて、エディタ一体型の開発環境としてかなり使いやすくなっている、という内容になっています。
特徴として、チャット画面のすぐ横でファイルの編集や、差分の確認までできちゃうんですね。さらに、ターミナルやブラウザ、それからiOSシミュレータまで、同じウィンドウの中に並べて配置できる。レイアウトも自分好みにカスタマイズできるので、「エディタとAIアシスタントと実行環境を一つの“机”の上に並べる」みたいな感覚で開発が進められます。
セッションを分割して表示したり、コマンドラインのセッションをスラッシュデスクトップというコマンドで引き継いだりと、CLIとデスクトップをまたいだ作業もスムーズです。プルリクエストの作成や、AIの使用量確認も、スラッシュユージッジというコマンドや、GUIメニューからボタン一発で行えるので、「ちょっとPR出して」「いまどのくらい使ってるっけ？」みたいなことが、ツールを切り替えずにすぐできるのが気持ちいいところですね。
出力のスタイルを変えられたり、マーケットプレイスから拡張機能を追加できたり、チャットとコーワークのモード切り替えができたりと、日常的な開発フローを途切れさせないための工夫も盛りだくさんです。画像や表、コードブロックの表示も見やすく作られていて、通知機能もあるので、「いつのまにかAIの返信を見逃していた」みたいな心配も減ります。
筆者自身、最初は「これはちょっと…」と思っていたそうなんですが、ここ最近の改善スピードがかなり速くて、しかもVS Codeの開発者が参加していることもあって、「これは今後も継続的に進化していきそうだ」と評価しています。
ふだんVS Codeメインの人でも、一度このClaude Code Desktopを、開発用のデスクトップクライアントとして試してみる価値は大いにあるよ、と強くおすすめしている記事でした。
。。，。。
三つ目は、モバイルアプリ開発で「エージェント」を本格的に使っていくための、かなり実践的な手順と工夫をまとめたTips系の記事です。React Nativeアプリを題材にしていて、仕様の策定から検証、プルリクエストの作成までを、ほぼエージェントに任せて回していくワークフローが紹介されています。
まず仕様決めのところでは、Superpowersとかgrill‑meといったブレスト系のLLMを使って、要件を文章としてきちんと固めてしまう、というステップがあります。ここで仕様をちゃんと決めてしまうことで、その後の工程で人間が口を挟む回数をぐっと減らすわけですね。
UIづくりのフローも特徴的で、いきなり画面全体から作るんじゃなくて、先にStorybookでコンポーネントを作り込んでいきます。play関数を使ってインタラクションテストも書いておく。こうすることで、「Storybookでコンポーネント単体を徹底的に詰める役」と「agent‑deviceで実機に近い環境の統合確認をする役」を分けられるんですね。エージェントとツールの役割分担を明確にすることで、開発が安定する、という発想です。
プロジェクトに置くCLAUDEドットエムディーも工夫されていて、中に細かいルール本文を全部書くのではなく、「この作業のときに読むドキュメントの一覧」だけを載せておく形にします。実際のルールは別ファイルに切り出しておいて、ESLintなどの静的解析で機械的にチェックさせる。こうすることで、人間のレビュー負荷を下げつつ、ルールの徹底も図れる、というわけですね。
さらに、「コンポーネントの作り方」や、「計測用のイベントを実装と同時に入れる」「Figmaとのデザイン差分の確認」といった、人が口頭で何度も繰り返し指示していたようなことは、Skillとして定義して、エージェントに手順として渡します。人のノウハウを、エージェントが読める形式のチェックリストに移していくイメージです。
アーキテクチャ面では、ビジネスロジックをUIから切り離した純粋関数にしておいて、コンポーネントは必要なプロップスだけを受け取るように設計します。こうしておくと、テストやStorybookでの確認がかなりやりやすくなって、「実機でないと分からない部分」の検証にエネルギーを集中できるんですね。
実機確認にはagent‑deviceを使って、iOSシミュレータやAndroidエミュレータをエージェントに操作させます。その際、roleとかlabel、testIDといった属性を丁寧に付けておくことで、画面上の要素を名前で安定して指定できるようになり、誤タップが減らせるよ、というノウハウも紹介されています。
バグの再現手順についても、ただメモを残すだけではなくて、ドットエーディーというスクリプトにして保存しておきます。修正後はreplayコマンドで、まったく同じ手順を自動で再実行できる。これを溜めていくと、そのままエンドツーエンドのテストスイートとして活用できる、というのが面白いところです。
プルリクエストはエージェントに書かせるものの、「人が読みやすい形」をあらかじめフォーマットとして指定します。たとえば要約や、状態遷移の図、検証に使ったスクリーンショット、それからエージェントだと見落としがちなチェック項目のリストなどですね。人間のレビュアーが一目で状況を掴めるように、テンプレートを整えるイメージです。
最終的に人が何をやるかというと、コードレビューと、実機での触り心地、細かい見た目の違和感といった、「エージェントでは拾いにくい細部の仕上げ」に集中します。エージェントにお任せするところと、人間が責任を持つところの線引きを、かなりクリアにしているのが印象的です。
そしてこのループは、EASとかクラウド上のシミュレータ、EAS Simulatorと組み合わせることで、CI環境でも、さらにはMacがない環境でも回せるようになっていく、と記事では述べられています。これによって、モバイル開発が、もっと多職種の人に開かれていく可能性がある、と。モバイル開発チームにとって、エージェント活用の実用的な青写真になりそうな内容でした。
。。，。。
四つ目は、Amazon Bedrockの料金に上限をかける仕組みを、「AWS Budgets Actions」と「IAM」だけで実現する方法を解説した記事です。
公式ドキュメントでは、API Gatewayなどを挟んで、かなり柔軟な制御をする構成も紹介されているんですが、「とにかく一定額を超えたらBedrockを一旦使えなくしてほしい」という、もっとシンプルなニーズに応えるためのテンプレートになっています。CloudFormationで、サクッと導入できるのが売りですね。
仕組みとしては、月額コストがあらかじめ決めたしきい値を超えたタイミングで、Bedrockを呼び出すIAMユーザーやロールに対して、ベッドロックコロンアスタリスクをデナイする、つまりBedrockへの全アクションを拒否するポリシーを自動でアタッチします。
このとき、どのIAM種別を対象にするか、ユーザーなのか、ロールなのか、グループなのか。そしてその名前、上限の金額、メールの通知先、さらにこの拒否ポリシーを自動で適用するかどうか、といった項目をパラメーターとして指定できるようになっています。
テンプレートを一度デプロイすると、Bedrock専用の拒否ポリシー、Budgets Actionsを実行するためのロール、Bedrockのコストだけを監視する予算、それから予算超過時に拒否ポリシーを付け外しするアクション、これらがまとめて作られます。
上限金額に到達したときにはメールで通知されて、拒否ポリシーは翌月になると自動で外れるようになっているので、「気づかないうちに青天井で課金されてしまうのは避けたいけど、あまり大げさな構成は組みたくない」というケースに、非常に手軽に使える仕組みになっています。
Bedrockを試し始めたばかりのチームとか、予算ガードレールをまずは最低限でも入れておきたいという人には、ありがたいテンプレートですね。
。。，。。
そして最後、五つ目の記事です。これは、複数のReactアプリを抱えたpnpmプラスViteのモノレポで、一部のアプリだけReactナインティーンに上げたところ、「Minified React error ナンバーごひゃくにじゅうご」というエラーが出た、というトラブルシュートの話です。
調査の結果、原因はかなりややこしくて、「ライブラリ内部のインポートリアクトフロムリアクトが、アプリ側のReactナインティーンではなくて、pnpmが作った共通の参照先に置かれているReactじゅうはちを拾ってしまっていた」というところにあった、というオチでした。
ここには、Viteのモジュール解決の仕組みと、pnpm特有のnode_modules構成が絡んできます。Viteは、あるファイルがあるディレクトリから親ディレクトリに向かって、node_modulesを順番にたどっていきます。一方でpnpmは、node_modulesの中にドットpnpmというディレクトリを作って、依存をうまく共有させつつ、解決できない依存を「ホイスト」、つまり共通の場所に持ち上げる仕組みを持っています。
この二つが組み合わさることで、Reactがバージョン違いで複数共存しているときに、「どのReactを共通参照先にするか」がpnpm内部の処理順によって変わってしまう。必ずしも新しいReactナインティーンが選ばれるとは限らないんですね。その結果、アプリ本体はReactナインティーンを使っているのに、ライブラリの中だけReactじゅうはちを見に行ってしまい、二バージョン共存状態からエラーが発生する、という状況が起きていました。
この記事で紹介されている対策は、Viteの設定でresolve.dedupeに、リアクトを指定する、というものです。こうすることで、「Reactの解決は必ずプロジェクトルート、つまり対象アプリのほうから行う」と約束させることができます。その結果、ライブラリも含めて、最終的には必ずReactナインティーンを参照するようになり、不具合はきれいに解消した、というわけです。
教訓としては、「Reactのバージョンをまたぐエラーが出たときには、アプリ側の依存だけじゃなくて、ライブラリがどのReactを参照しているか、そしてビルドツールのモジュール解決設定がどうなっているか、そこまで含めて確認しよう」ということですね。モノレポやpnpmを使っている現場には、かなり刺さる事例だと思います。
。。，。。
というわけで、きょうのzenncastは、このへんでお時間となりました。
きょうは、
安いモデルから攻めてキャッシュも意識しよう、というLLM運用のTips、
エディタ一体型でかなり使いやすくなったClaude Code Desktop、
React Native開発をエージェントメインで回すための実践ワークフロー、
AWS BudgetsとIAMだけでBedrockのコスト上限をかける方法、
そして、pnpmとViteのモノレポでReactのバージョン違いが起こしたエラー事例と、その直し方、
この五本を駆け足でご紹介しました。
気になった記事があれば、詳しい内容は番組のショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんなテーマを扱ってほしい」といったリクエストも、いつでもお待ちしています。あなたの現場での悩みや気づきが、次回のトークのタネになるかもしれません。
それでは、きょうも良い一日を。お相手はマイクでした。
また次回のzenncastでお会いしましょう。