どうもー、おはようございます。マイクです。
時刻は朝七時を少し回ったところ、今日は二千二十六年九月十五日、火曜日です。
ここからの時間は「zenncast」、きょうも最新のテックトピックをゆるっと楽しく追いかけていきましょう。
このあと、この時間は Zenn に載っているきょうのトレンド記事をピックアップしてご紹介していきます。
さて、きょうご紹介する記事はぜんぶで五本です。
トークン効率化のテクニックから、Lambda のタイムアウト延長の話、開発体験を変えそうな Claude Code Desktop、ARG のソース閲覧の考え方、そして法律事務所の現場でエージェントをどう組み込んでいくか、というかなり幅広いラインナップになってます。
それぞれじっくり、でもラジオらしくフランクにお届けしていきますね。
まず一つ目は、トークン効率化に関する Tips 系の記事です。
「どうやったら LLM を安く、そして賢く使い回せるのか？」という、開発者やプロダクト側の人が気になるポイントをかなり実務寄りにまとめてくれています。
キモになっているのが、最新モデルをちゃんと使いつつ、タスクごとにグレードや effort を使い分ける、という考え方なんですね。
簡単なタスクに、いちばん高性能で高価なモデルを毎回ぶつける必要はない一方で、難しいタスクを安いモデルで何回もリトライして失敗するくらいなら、最初から高性能モデルで一発で決めたほうが、むしろ安く上がることもある。
「高いモデルは悪、安いモデルは善」みたいな単純な話じゃなくて、タスクの難易度と試行回数をちゃんと見たほうがいいよ、というスタンスです。
それから、会話の途中でモデルや effort を頻繁に変えると、キャッシュが切れてしまって、過去の履歴をまた最初から高いお金を払って読み直すことになる、という注意点も紹介されています。
同じセッションの中では、できるだけモデルと effort は固定しておいて、どうしても変えたいときは「ここで設計が一段落した」とか「タスクを切り替えよう」というタイミングで、履歴要約、いわゆる compaction を挟んでからモデルを変えるのがいい、という話ですね。
良くやりがちなアンチパターンとして、system prompt の先頭に毎回日付やリクエスト ID を書いてしまうとか、過去メッセージを後から書き換えてしまう、というのも挙げられています。
キャッシュって「先頭からどこまで同じか」で効いてくるので、先頭のほうをちょこちょこ変えると、せっかくのキャッシュが全部無効になっちゃうんですよね。
なので、毎回変わる情報や質問はメッセージの末尾側に寄せておいて、固定の指示とか、よく使う資料、ルールみたいなものはメッセージの先頭に置くと、キャッシュ効率が上がるよ、という実践的なアドバイスが載っています。
さらに、MCP や tool をたくさんつなげると、その説明文が毎ターン先頭にドンと乗ってしまって、これもコスト増になるという指摘もあって。
使っていない tool は思い切って外してしまうとか、検索結果やログはアプリ側で事前にしぼり込んでから LLM に渡す。
どうしてもたくさんの情報が必要なときは、Programmatic Tool Calling を使って、LLM 自身に「要約だけ」を会話に戻してもらう、といった設計が紹介されています。
あと、履歴要約の compaction をなんでもかんでも自動で毎ターンかけるのは良くない、という話もおもしろくて。
長い履歴を読んで要約するにも、当然トークンコストがかかるわけで、「設計が固まった」とか「調査フェーズが終わった」みたいな、大きな区切りだけで実行したほうが良いと。
そのうえで、決定事項とか、失敗した案なんかは別ファイルに残しておいて、同じ調査を毎回最初からやり直さないようにしよう、という運用の話にも触れています。
それから、コンテキストが長くなりすぎると、「ちょっと超えた分だけ高くなる」のではなくて、「リクエスト全体が、上の料金テーブルに乗り換わる」タイプのモデルもあるので注意が必要だと。
料金表の閾値を意識しながら、「せっかくだから上限まで全部コンテキスト突っ込もう」ではなくて、「今のタスクに本当に必要な情報だけを残す」ほうが、コスト的にも、むしろ出力の品質的にも安定しやすい、と説明しています。
最後に、大量処理の話もあって、「今すぐ結果が欲しいわけじゃないバッチ処理」については、OpenAI や Anthropic の Batch API みたいな仕組みに回すと、おおよそ半額くらいまでコストを抑えられるケースがあると。
しかもそれをキャッシュ割引と併用できることもあるので、ターン数、リクエスト数、トークン数を分解して可視化しながら、どこに無駄があるのかを継続的にモニタリングすることが重要だよ、という、かなり現場感のある締めくくりになっていました。
LLM をプロダクションで回しているチームには刺さりそうな内容ですね。
。。。。
続いて二つ目の記事です。
こちらも Tips 系で、AWS Lambda のタイムアウトが九十分まで伸びた、という話題を検証したレポートになっています。
今回伸びたといっても、対象はちょっと限定的で、Lambda の LMI、つまり自分の VPC 内の EC2 で動かすモード上の関数で、なおかつ非同期実行か、ESM 起動のときに限って、一回の実行時間の上限が、従来の十五分から九十分まで伸びた、という話なんですね。
なので、普通の同期呼び出しとか、通常のオンデマンド Lambda は、引き続きタイムアウト十五分のままです。
そしてこれがポイントなんですが、「Timeout を五千四百秒に設定するだけで、はい九十分 OK」という単純な話ではないところ。
LMI を使うには、NAT や VPC エンドポイントを用意して外向き通信の経路をきちんと確保したり、メモリを最低二ギガバイトにしておいたり、関数バージョンを発行したうえで、Capacity Provider の設定をしておいたりと、インフラ側で結構しっかり準備が必要だよ、という点が記事でまとめられています。
おもしろいのが、S三イベント、たとえば PutObject みたいな非同期トリガーでも、この九十分枠がそのまま効くというところ。
つまり、「S三にファイルがアップロードされたら、その場で重い変換処理を一関数で最後まで回してしまう」というパターンが、Step Functions を使わずに Lambda 一つで実現できる、というのを、実測で確認しているんですね。
ステップファンクションでのワークフロー設計がいらない分、小さいチームにはかなりうれしいところかもしれません。
さらに durable functions と組み合わせたケースの話も出てきます。
durable functions 全体としてのワークフローの最長期間が一年、という制限自体は変わらないんですが、一ステップに詰め込める連続処理の長さが、これで九十分まで伸びる。
ただ、LMI の仕様として「タイムアウトになってもコードがぴたりと止まるわけではない」ので、ステップ間で明示的に wait を挟んで、中断と再開のタイミングを自分で制御するほうが安全、といった注意点も書かれています。
運用面のポイントもいろいろ整理されていて、まず LMI は「呼ばれていなくても EC二相当のコストがかかる」という、いわば常駐型に近い料金になるところ。
それから、SQS をトリガーにする場合は、キューの可視性タイムアウトを関数の実行時間より短く設定してしまうと、同じメッセージで複数の長時間処理が並走してしまう危険があるので、そこは気をつけよう、という話。
長時間動かすがゆえの罠として、NAT のアイドルタイムアウト、データベース接続の切断、一時的な認証情報の有効期限切れなどにも配慮が必要だとしています。
そして、非同期リトライが絡むと、最悪九十分の処理が何度も走ってしまう可能性があるので、処理の冪等性、リトライ設計はかなりしっかり考えましょう、というところまで押さえられていました。
「十五分を超えるならコンテナに逃がすしかない」と思っていたところに、選択肢がひとつ増えるかもしれない、そんなアップデートですね。
。。。。
三つ目は、Claude Code Desktop の紹介記事です。
最初のころは「ちょっと重いし、機能もまだまだ」という印象だったのが、最近のアップデートでかなり化けてきた、という内容になっています。
今の Claude Code Desktop は、エディタ、ターミナル、ブラウザ、そして AI が、一体化した開発環境として、かなり実用的に使えるレベルになってきたと。
チャットのすぐ横で、そのままファイルを編集できたり、ペインやセッションを自分の好みに合わせて自由にレイアウトできたりするので、「編集画面と AI の行き来で迷子になる」感じがだいぶ減っているようです。
同じディレクトリをカレントにしたターミナルがその場で動かせたり、内蔵ブラウザや iOS シミュレータまで起動して、そのプロジェクト用に一つの空間が作れる、というのもポイント。
要するに、「エディタ開いて、別ウインドウでチャット開いて、さらにブラウザ開いて……」というのを一個にまとめてくれるので、作業のコンテキストスイッチングが少なくなるんですね。
細かいところでは、AI によるコード変更の差分確認が見やすくなったり、ワンクリックでプルリクエストを作成できたり、スラッシュコマンド系の機能である usage や config、mcp の情報が GUI で分かりやすく表示されるようになったりと、操作性もかなり改善されたと紹介されています。
出力スタイルの切り替えや MCP マーケットプレイスの利用、通常の Chat モードと Cowork モードのタブ切り替え、CLI セッションをそのまま引き継いで使えるといった機能もあって、「単なるチャットクライアント」から「ちゃんとした IDE 寄りのツール」に近づいてきている印象ですね。
Markdown の表や画像の表示、通知機能、セッションをグループごとにまとめたり、別ウインドウに分離したりといった UI 周りも充実してきていて、「VS Code にだいぶ近い使い勝手になってきた」と著者は評しています。
そのうえで、いまは CLI よりも、こちらの Claude Code Desktop を好んで使っている、とまで書いていて、今後のアップデートにもかなり期待している様子でした。
AI と一緒に開発するスタイルが、また一歩進化してきた感じがしますね。
。。。。
四つ目は、ちょっと毛色が変わって、Web 探索型 ARG における「ソース閲覧」をどう扱うか、というお話です。
「ページのソースを見るのは裏ワザだから禁止」という考えではなくて、そもそも Web を舞台にしたゲームなら、ソース閲覧はギミックにもなり得るし、リスクにもなり得る、前提条件として設計に組み込むべきだ、という主張になっています。
記事のなかでは、昔ながらの「隠しリンク探しゲーム」から、最近のリアルタイム ARG まで、具体的な例がいくつか紹介されています。
たとえば、HTML のソース内コメントにヒントを埋め込むパターンや、ちょっと脆弱なログイン実装をあえて用意して、そこを解析すると次のステップに進めるようにするもの、YouTube の埋め込みタグに細工をしておくものなど。
こうした仕掛けを通じて、「ソースを読むことそのものを、正攻法の解法として組み込む」手法を整理しているんですね。
一方で、個人戦とか、常設でいつでも遊べるタイプのゲームの場合、「ソースをチラっと見た瞬間に答えが丸見えになってしまって、没入感が一気に冷める」という問題もある、と指摘しています。
そういうケースでは、実装を堅牢にしておくか、シナリオ側で「ソース見なくても解けるように誘導する」か、あるいは「ソース不要です」とあらかじめ明示しておく、といった対策が必要だろうと。
特に、大人数で一緒に解く全体戦や、「これは現実だ」と感じさせる TINAG を重視する本格派 ARG では、プレイヤーがソースを見ることを前提に、「見られても破綻しない設計」をしておくことが大切だとまとめています。
そのうえで、運営側としては、ソース閲覧を「ズル」ではなく、正当なプレイスタイルの一つとして受け止める姿勢が望ましい、というのがこの記事のメッセージですね。
技術的な観点では、答えや次の問題につながる情報をフロントエンド側に直接埋め込まないこと。
判定はきちんとバックエンドで行って、ネットワークタブからも余計な情報が見えないように、返すデータを必要最小限に絞ること。
こうした Web アプリ開発としての基本的な分割や実装のポイントを押さえておくことで、「ソースを見られても困らない ARG」を設計しやすくなる、と解説しています。
ゲームデザインとセキュアコーディングの話がクロスしていて、なかなか読み応えのある内容でした。
。。。。
そして五つ目、最後の記事は、法律事務所の企業法務の現場で、Claude などのエージェントを本格的に組み込むための、エンジニアリング事例の紹介です。
キーワードは「オフィス前提の世界で、どう AI を実務に溶け込ませるか」。
Word、Excel、PowerPoint といった Office ファイルを前提に動いている現場で、複数ファイルをまたいで安全に自動編集しつつ、弁護士と AI が同じ文書を同時に見ながら協働できる仕組みをどう作るか、というチャレンジが語られています。
この記事では、その解決策として、ローカルの MCP サーバーと COM 操作を組み合わせた構成が採用されています。
Office の世界って、API 周りがなかなかクセも強くて、Office.js や OOXML だけでやろうとすると、協働性の確保とか、安全性の担保、操作の分かりやすさ、いわゆる UX にいろいろ課題が出てくると。
そこで、COM を使うにしても、「安全な API だけを叩けるように絞り込んだ JavaScript 実行環境」から操作する設計にして、あくまでコントロールされた形で Word たちを動かしているんですね。
さらに、契約書のような法律文書で重要になってくるのが、「変更履歴を壊さない、最小限の差分編集」です。
AI が勝手に全部書き換えてしまって、トラッキングがめちゃくちゃになると、レビューができなくなっちゃいますからね。
そのために、特定の段落を取得したり、一部だけを削除・挿入したりする専用ツールを用意して、狙ったポイントだけをきれいに編集できるようにしている、というのがこの事例の肝になっています。
加えて、Google Drive 上に散らばっている大量のファイルや、PDF で配布されている各種ガイドラインを横断検索するツールも整えているそうです。
これによって、エージェントが「この事務所の過去の契約書」や「社内ルールの PDF」なんかをまたぎながらドラフトを作り込んでいけるようになる。
結果として、「エージェントが契約書のドラフト作業をかなりの部分まで担ってくれて、弁護士は内容の判断と指示に専念できる」という構造に、だいぶ近づいてきているとまとめられていました。
AI をただのチャットボットではなく、「現場のチームメンバー」に寄せていくための、かなりリアルなエンジニアリングの工夫が見える記事でした。
。。。。
というわけで、きょうの「zenncast」、お届けしてきた内容をざっとおさらいしていきましょう。
まず一つ目は、LLM のトークン効率化の第一歩として、最新モデルと effort の使い分け、セッション内でのモデル固定、キャッシュを意識したプロンプト設計、そして Batch API まで含めたコスト最適化の話。
二つ目は、Lambda の九十分タイムアウト拡張について、LMI モードでの条件やインフラ要件、S三イベントや durable functions との組み合わせ、それから長時間実行ゆえの運用上の注意点を確認しました。
三つ目では、Claude Code Desktop が「エディタ、ターミナル、ブラウザ、AI」が一体になった開発環境としてかなり使いやすくなっていて、VS Code に近い感覚で使えるようになってきている、というアップデートを。
四つ目は、Web 探索型 ARG におけるソース閲覧を、禁止すべき裏ワザではなく、前提条件として捉えて設計しよう、という話と、そのための Web 実装の基本。
そして最後五つ目は、法律事務所の企業法務にエージェントを組み込むための、MCP＋COM を使った Office 連携と、安全な差分編集や横断検索の実装事例をご紹介しました。
気になる記事があった方は、番組のショーノートに元の記事の情報をまとめておきますので、ぜひそちらからじっくり読んでみてください。
この番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
日々の開発や仕事の現場で感じているモヤモヤや発見なんかも、ぜひ気軽に送ってください。
それでは、きょうはこのへんでお別れです。
お相手はマイクでした。次回の配信でまたお会いしましょう。
それでは、いってらっしゃい。