どうもマイクです。おはようございます。
今日は二〇二六年十月一日、木曜日の朝七時になりました。
ここからの時間は「zenncast」、きょうはZennで話題になっているトレンド記事をがっつり紹介していきます。通勤通学のお供に、ゆるっとテック情報仕入れていきましょう。
さて、きょうはお便りはお休みということで、そのぶん記事紹介にたっぷり時間を使っていきます。
きょうご紹介する記事は、ぜんぶで五本。事故の失敗談から、AIエージェントの効率的な使い方、バックエンドのテスト戦略、ローカルで動く翻訳モデルの最適化、そしてAI時代の設計の話まで、かなりバラエティ豊かです。
まず一本目。
これはですね、経験十一年のエンジニアさんが、「本番データベースをうっかり初期化してしまった」という、聞くだけで胃がキュッとなるような失敗談と、その対策をまとめた記事です。
やってしまった流れとしては、連休前にPrismaの `DATABASE_URL` を本番環境を指したままにしてしまって、連休明けにそのことをすっかり忘れて、「ローカルの開発用データベースをリセットするつもりで」 `prisma migrate reset` を実行してしまった。結果、本番DBを初期化してしまった、という事故ですね。
ただ、ここで救いだったのが、NeonというサービスのBackup & Restore機能があったことと、サービスがまだ初期で、データ量が少なかったこと。
これによって、一日前の状態までなんとか復旧することができたそうです。これがサービス成長後、データが増えたタイミングで起きていたら、本当に致命傷だった、と振り返っています。
じゃあ、どう防ぐか、という話もこの記事はしっかり書いてくれていて、いくつかポイントがあります。
ひとつは、破壊的なコマンドを実行する前に、 `DATABASE_URL` がちゃんとローカルホスト、つまり開発用の環境を指しているかどうかをスクリプトでチェックしてしまうこと。人間の注意力に頼らず、自動でガードをかけるわけですね。
それから、本番用のURLを、ローカルの `.env` ファイルに置かない運用にすること。物理的に手元の環境から本番に直アクセスできないようにしておくと、こうした「うっかり」が起きにくくなります。
さらに、NeonのようなマネージドDBを使うときは、バックアップの保持期間がプランごとにどうなっているかを、ちゃんと把握しておくこと。いざという時に「二日前には戻せないじゃん！」みたいなことにならないようにするわけですね。
あと地味だけど効くのが、連休前とか長く作業を中断する前に、「いま何をやっていて、どこまで進んでいるか」をメモにして残しておくこと。
「たぶん覚えてるだろう」は、だいたい覚えてない、という話です。
面白いのが、最近のAIエージェントも絡めた対策も挙げているところで、「本番URLを環境変数に書かない」「破壊的なコマンドを勝手に実行しない」といった禁止ルールを、AI側にもちゃんと設定しておくべきだ、と。
人間だけじゃなくて、AIにも「ここは絶対触るな」というレールを敷いておくのが大事だよ、という教訓になっている記事でした。エンジニアの方は、自分ごととしてゾクッとしつつ、対策を見直すきっかけになると思います。
。。.。.。
続いて二本目は、ClaudeのCodeやCodexみたいなAIエージェントを使うときの、「トークン消費の実態」と「賢い運用TIPS」を解説している記事です。
これ、なんとなく使っていると気付きにくいんですけど、読み出し専用に見えるキャッシュ済みトークンも、実は完全にタダじゃないんですね。
記事によると、キャッシュ済みのトークンも、通常のだいたい一割くらいの重みで上限にカウントされるそうです。
長いセッションで、過去の会話履歴を何度も何度も送り直していると、「そんなに使ってないつもり」でも、けっこう上限を削ってしまう。著者の計測だと、トークン消費の約三分の二が、キャッシュの読み取り由来だった、という結果も出ていて、これなかなかインパクトあります。
さらに、Claude CodeとかCodexのエージェントは、ツールを一回呼ぶたびに、「それまでの会話全履歴プラス新しい結果」を毎回まるごと送る設計になっている。コンテキストが大きくなるほど、一リクエストあたりの送信トークンがどんどん増えていって、コンテキスト使用率が九十パーセント近辺まで膨らむと、五十パーセント未満だったときの、約二倍くらいの消費になってしまうそうです。
自動のコンパクト機能もあるんですが、これが動き始めるのが「だいたいコンテキスト九十パーセントに達してから」。
その手前の、「やたら履歴だけ大きい状態」でリクエストを重ねると、ムダが大きくなる。著者のログだと、コンパクトが走ったあと、一リクエストあたりの消費が約四十五パーセントまでガクッと下がっていて、「もっと早めに履歴を切ったほうがお得じゃない？」という話になっています。
さらに、プロンプトキャッシュ自体にも時間制限があって、Claude Codeではおおむね一時間、Codexでは三十分を超えるとキャッシュが切れる、という観測も紹介されています。
つまり、時間を空けて同じセッションを再開すると、その大きなコンテキスト全体が、非キャッシュ扱いで再計算されてしまって、一気に上限をガリッと消費してしまう、と。
こうした挙動を踏まえて、著者が提案している運用のコツが三つあります。
ひとつ目は、コンテキスト使用率が七十パーセントくらいになったら、ひとつの目安としてセッションを切り替えること。
ふたつ目は、テスト結果とかログみたいな、長い出力はサブエージェント側に持たせて、メインのコンテキストには要約だけを入れること。
みっつ目が、最後のリクエストから一時間以上空いたら、Codexなら三十分ですね、その古い大きなセッションを無理にリジュームせずに、新しいセッションを作り直すこと。
料金や上限にシビアなチームほど効いてくる知見なので、日々AIツールをガンガン回している方は、一度自分たちの使い方と照らし合わせてみると、かなり節約できるかもしれません。
。。.。.。
三本目は、バックエンド開発のテスト戦略、特に「APIテスト」を中心に据え直した、というお話です。
もともとこのチームでは、UT、いわゆるユニットテストはたくさん書いているんだけれども、API全体としてちゃんと仕様どおりに動いているのか、そこに自信が持てない、という状況があったそうです。
UTだけだと、どうしてもAPI全体の振る舞いを直接確かめることが難しくて、仕様が層ごとのテストに分散してしまう。
アーキテクチャをちょっと変えただけで、大量のユニットテストが壊れてしまう、といった問題もあって、「テストはあるけれど安心できない」という、モヤっとした状態になっていたんですね。
特に、単純なCRUD中心のAPIから、もっと複雑なビジネスロジック中心のAPIに変わっていく中で、「API仕様どおりに動いていること」を保証するテストが足りていない、というのが大きな課題だったと振り返っています。
そこで著者たちは、品質保証の軸を、「各層のユニットテスト」から、「APIテスト」に切り替える、という方針をとります。
UTは、複雑なロジックが集まるドメイン層だけにグッと絞って、それ以外のところは、APIの振る舞いを通してチェックするようにした、というわけですね。
具体的には、runnというツールを使ってAPIテストを書いています。
Go側でテスト用DBとしてSpanner Emulatorを立ち上げて、テスト用のサーバーもセットアップする。その上で、HTTPリクエストと、レスポンス、そしてDBの状態の検証内容を、YAMLで記述していく構成です。
さらに、各APIごとに専用のテスト用DBを作って、テストが終わったらそのDBを削除する、という運用にすることで、テストの並列実行もできるようにしています。
runnのシナリオには、「仕様の説明を書いてから、API呼び出し、続いてDBの期待値の確認」といった流れを、縦にスッと読めるように並べて書くので、テストがそのまま仕様書のような役割も果たします。
加えて、READMEでテストケース一覧を表形式にまとめておくことで、「どんなケースをカバーしているのか」を一目で把握できるようにした、という工夫も紹介されています。
この結果、コードレビューのときに、仕様を追いかけやすくなって、「このAPIはこういう振る舞いをする」というのがテストからも分かるようになった。
リファクタリングしたあとも、「とりあえずAPIテストが全部通っているかどうか」で安心して判断できるようになったそうです。
数十パターンある正常系・異常系のテストが、常にCIで自動実行されていて、落ちたらすぐに分かる。
その結果として、「このAPIは仕様どおりに動いている」とチーム全体がはっきり言えるようになったことが、最大の成果だった、とこの記事では述べています。
APIのテストどうしようかな、と悩んでいるバックエンドチームには、かなり参考になる内容です。
。。.。.。
四本目は、オンラインゲーム中のチャット翻訳のために、Gemmaスリー系の翻訳特化モデル、MiLMMTフォーティシックスを、「ゲーミングPCでも動くように、極限まで軽くしてみた」という、かなり攻めた最適化の手順をまとめた記事です。
前提として、ゲームをしながら同じマシンで翻訳モデルも動かしたいので、GPUのVRAMはゲームと奪い合いになる。
その中で、一ビリオン、四ビリオン、十二ビリオンといったサイズの翻訳モデルの品質と負荷を比較して、メインターゲットとしては、四ビリオンのモデルを中心に最適化を進めています。
具体的な軽量化のステップがかなり面白くて、まずは画像入力用のモジュールをばっさり削除します。
チャット翻訳用途なので、画像入力はいらないよね、という割り切りですね。
次に、日本語・英語・韓国語のチャット翻訳で、ほとんど使われないトークンを、大規模なコーパスから統計的に洗い出して、ボキャブラリ自体を縮小します。
「この言語セットではまず出てこない記号とか、単語とかは抜いちゃう」というイメージです。
そのうえで、imatrixベースの量子化という手法を使って、重要な重みほど細かく残すようにしながら、ビット数を落としていきます。
Qフォー・ケー・エスというレベルまでビット数を下げても、FLORESプラスというベンチマークで、元のモデル比およそ九九点八パーセントの翻訳精度を維持できている、という結果が出ていて、かなり攻めた量子化なのに精度が落ちていないのがポイントです。
さらにソフトウェア側でも攻めていて、llama.cppの設定で、マイクロバッチをぐっと小さくして、KVキャッシュなどが使うVRAMを削っていきます。
CUDAランタイムも、必要なカーネルだけを含むようにカスタムビルドして、不要な依存ライブラリを外すことで、ランタイムのサイズもぐっと絞り込んでいます。
その結果として、モデルファイルは約十ギガバイトから約二点一ギガバイトへ、プロセスが使うVRAMは約九ギガバイトから約二点七ギガバイトへ、ランタイムは八百四十三メガバイトくらいから、なんと約十一メガバイトまで圧縮できたと報告されています。
このおかげで、二〜三ギガバイトくらいのVRAMでも、ゲームと翻訳モデルを同時に動かせる環境が実現できた、ということで、「ゲームしながらリアルタイム翻訳したい勢」には夢のようなお話ですね。
ローカルLLMを実運用に近い形で動かしたい人にとっても、かなり参考になるテクニックが詰まっています。
。。.。.。
そして五本目。
これは、「AIがコードを書くのは当たり前になってきた今、ボトルネックはどこに移っているのか」という、設計の話です。
いまやAIがコードを書くこと自体は珍しくなくなってきていて、むしろ開発で一番時間がかかるのは、「何をどう作るか決める設計」の側に移りつつある。
AIは、あいまいな依頼の中にある「仕様の空白」を、それっぽくキレイに埋めてしまうので、意図していない挙動がまぎれこんでも、気付きにくいのが問題だ、という指摘から始まります。
筆者は、設計を「要求をちゃんと理解して、それをコードの構造に落とし込むこと」と捉えています。
これまでは、なぜその順番で関数を呼ぶのか、なぜそのデザインパターンを採用したのか、といった設計判断が、コードの中や、開発者の頭の中に暗黙的に埋まっていることが多かった。
でもAI時代は、それをコードの外に、明示的な「仕様」として書き出すべきだ、と述べているんですね。
OpenAPIとか型定義みたいに、機械で検証できる成果物はすでにたくさんあるんですが、内部処理の順序とか、細かい振る舞いについては、コードを読んで逆算するしかないことが多い。
そのせいで、人手によるレビューがどんどん重くなっていく、という問題があります。
そこで筆者が提案しているのが、Mermaidで書いたシーケンス図を「実行順序の仕様」と見なしてしまう、というアイデアです。
テスト中に、Pythonの実行監視機能を使って、関数呼び出しのトレースを取っておきます。
そのうえで、「図に書いた呼び出しの順番が、実際の呼び出し列の中に、部分列としてきちんと現れているか」を、決定的なプログラムで検証する、小さな仕組みを紹介しています。
これをやると、「最終的な結果のアサートだけだと見逃してしまう、『処理の順序が変わってしまった』問題」を、自動で検知できるようになります。
しかも、そのシーケンス図自体が、そのまま設計ドキュメントとして人間にも読みやすい、というのがポイントです。
筆者は、AIには仕様や図の「下書き」と、コード生成をどんどん手伝ってもらう一方で、仕様とコードがきちんと一致しているかどうかを調べる部分は、人間の目ではなく、決定論的なテストやツールに任せたほうがいい、と主張しています。
そのうえで、人間のレビューは、「この仕様で本当にいいのか」「ドメインの理解やトレードオフの説明は妥当か」といった、本質的な判断に集中させるべきだ、と。
AI時代になっても、ドメインを理解したり、なぜこの仕様にしたのかを説明したりする設計の仕事は、やっぱり人の役割であり、それを外に表現した仕様として残すことが、これからますます重要になる、と締めくくっていました。
コードレビューや設計レビューのあり方をアップデートしたい方には、かなり刺さる内容だと思います。
。。.。.。
というわけで、きょうの「zenncast」は、
本番DBを消してしまった恐怖の失敗談とその対策、
AIエージェントのトークン消費の裏側と節約のコツ、
APIテストを軸にしたバックエンドの品質保証の話、
ゲーミングPCでも動くように翻訳モデルを極限まで軽くした工夫、
そして、AI時代の設計と仕様のあり方、
この五本を駆け足でご紹介してきました。
気になった記事の詳細は、番組のショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。
番組への感想や、「こんなテーマを扱ってほしい」といったリクエストも、ぜひぜひお待ちしています。あなたの現場での悩みが、次回のトピックになるかもしれません。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。