どうも、こんばんは。マイクです。
今日も「zenncast」をお聞きいただきありがとうございます。
二千二十六年八月一日、土曜日の朝七時をまわりました。ここからの時間は、Zennで今トレンドになっている記事を、ラジオ感覚でゆるっと、でも中身はガッツリめにご紹介していきます。
今日はお便り紹介はお休みで、そのぶん記事をたっぷりめにいきたいと思います。
さて、今日ご紹介する記事は全部で五本です。
モデル運用のプロンプト設計から、バッチ処理の壊れ方と直し方、AIスキル運用のノウハウ、AIコードレビューのコスト設計、そしてClaude Codeをシークレットモードっぽく使うテクニックまで、かなりバラエティ豊かなラインナップになっています。
それじゃあ、さっそく一つ目の記事からいきましょう。
。。。。
一つ目は、Claudeの「Opus ふぁいぶ」に切り替えたら、急に説明がフラットな長文になったり、原因を深掘りしなくなったり、評価軸も出てこないし、質問にちゃんと返事せずにすぐツールを実行しちゃう、みたいな、「あれ、なんか思考浅くなってない？」という振る舞いが出てしまった、という話です。
最初は「rules 側が劣化したのかな？」と思いがちなんですが、筆者が調べていった結果、原因はそうではなくて、「Claude ふぁいぶ 世代になったときに、本体の system prompt が大幅に簡略化されたこと」にあったんですね。
これまで本体側にいろいろ細かい「こう書きましょう」「こう説明しましょう」というお作法が入っていたのが、ふぁいぶ 世代では、ほとんど「まず動け」「とにかく推薦を出せ」という方針だけが残って、応答の書き方に関する規定がごっそり消えていた。
一方で、旧来の rules は、その“お作法込み”の前提で書かれていたので、土台が変わったのに上物だけ古いまま、みたいなズレが起きていたわけです。
そこで筆者は対策として、まず「本体のプロンプトの原文」をちゃんと引用した上で、「ここに書いてある方針よりも、こちらのルールを優先してください」と、優先順位を明示するようにしました。
そのうえで、ありがちな「〜するな」という禁止ベースではなく、「こういうふうに考えてから答えてほしい」「こういう構造で説明してほしい」といった、望ましい振る舞いをかなり具体的に書き直していきます。
さらにおもしろいのが、「指示をどこで注入するか」も見直したところですね。
従来どおり context の先頭に、でっかい rules をドーンと置くだけだと、「ツール実行しようかな」とモデルが行動する直前には、そのルールの影響が薄れてしまう。
そこで、UserPromptSubmit というフックを使って、ユーザーが毎回プロンプトを送るタイミングで、「ツールを実行する前に、この発話への返答をちゃんと文章で書いてね」といった短い指示を差し込むようにした。
つまり、「行動直前の位置」に、コンパクトな行動ルールを毎ターン仕込むことで、実際の挙動をかなり確実に変えられる、というわけです。
モデルの世代が変わったことで「本体のシステムプロンプトがスリムになった」という前提をきちんと押さえ、そのうえで上書きの優先度と、注入する“場所”を工夫する。
単に「思考深くして」とお願いするのではなく、設計で制御しにいく、というところがとても実践的な記事でした。
。。。。
続いて、二つ目の記事です。
こちらは、同期バッチ処理がデータ量の増加とともに、どんな順番で壊れていくのか。そのたびに、どう直していけばいいのかを、段階的に積み上げていく Tips 系の記事です。
まずスタート地点は、いちばん素朴な実装。
「全件を一気に取得して、そのまま変換して、まとめて保存する」というやつですね。
これは少ないデータなら問題ないんですが、データ量が増えてくると、メモリを大量に食ってしまって、あっさりメモリ不足で落ちる。
そこで、対策の第一歩として「ページ単位に区切って処理する」というやり方が出てきます。
一定のページサイズごとにデータを取得し、そのページだけ変換して保存することで、一度に抱えるデータ量を「ページサイズ分」に抑えて、メモリ使用量を安定させるわけですね。
ところが、これでメモリはよくなっても、今度は実行時間の問題が出てきます。
直列でダラダラ処理していると、一ジョブの最大実行時間の上限を超えてしまう。
そこで次の改善として、「IDを列挙する部分」と「実際の処理」を分離します。
まず対象データのIDだけを全部洗い出して、それをデータベースに記録し、メッセージキューに積む。
そして、複数のワーカーがキューからIDを拾って、並列で処理していく、という形にするわけです。
ただ、それでも「重いデータが固まっている」と、一つのワーカーが担当するバッチだけ時間オーバーになってしまうことがあります。
ここで出てくるのが、「ワーカーごとの持ち時間」、いわゆるソフトリミットを決める、という工夫です。
ワーカーは自分の残り時間を意識して、残りが少なくなってきたら、その時点でまだ処理していないIDを、新しいメッセージとしてキューに戻して、きちんと正常終了する。
こうすることで、「あのワーカーだけ時間切れで落ちてた」という状態を防ぎつつ、重いデータも少しずつ片づけていけます。
さらに、壊れたデータや、外部API側の障害があると、「一件の失敗」のせいでバッチ全体が何度も止まる、というつらい状況になります。
これに対しては、エラーを三種類に分けるという整理が提案されています。
「恒久エラー」、もう何度やっても直らなそうなもの。
「一時的エラー」、ネットワーク不調とかで時間を置けば直りそうなもの。
そして「時間切れ」。
時間切れと一時的エラーについては、専用のキューに逃がして、そこで一件ずつ丁寧に処理する。
しかも、その再試行回数にはちゃんと上限を設けて、無限リトライにならないようにする、というのがポイントです。
最後に、メッセージキュー特有の問題として、「少なくとも一回は届ける」という性質があるがゆえに、同じメッセージが再配信されて、二重処理が起きるリスクがあります。
これを防ぐために、対象アイテムに状態を持たせて、「ペンディング」から「プロセッシング」への遷移を、条件付き更新で行う。
つまり、「まだペンディングだったらプロセッシングに変える」という形で更新して、うまく確保できたものだけ処理する。
それでも、ペンディングやプロセッシングのまま長時間放置されているものが出るので、それらを「フェイルド」に倒していくスイープ処理を別途用意して、取りこぼしをなくしていく、という構成です。
素朴な全件処理から始まって、ページング、キューと複数ワーカー、ソフトリミット、エラー分類と専用キュー、重複配信への対策とスイープ処理まで、
「バッチ処理が壊れたら、次に何を足すべきか」が順を追って説明されていて、実運用で悩んでいる方にはかなり刺さる内容でした。
。。。。
三つ目は、「AIスキルを五十個くらいまで増やしたところで、一度も使われないスキルが出てきた」というところから始まるお話です。
最初、筆者は「さすがにスキル増やしすぎて、トークン消費が重くなってるんじゃないか」と考えたんですが、実際に計測してみたら、五十スキル分のメタデータって、全体のゼロ点五パーセントくらいしか占めていなかった。
つまり、「トークンを節約したいからスキルを間引く」という発想は、数字上まったく成り立たない、ということが分かったんですね。
では何が問題だったのかというと、「いつそのスキルを使うのか」の説明、いわゆる when_to_use の記述が薄くて、似たようなスキル同士で発火条件がかぶっていた、という点です。
ルーティングのときに、どれを選ぶか票を集めるイメージなんですが、似たスキル同士で票の取り合いが起きて、結果としてあるスキルはずっと静かに選ばれないまま、という「弁別性不足」が、本当の課題だったと。
そこで筆者は、「一度ルールを決めて終わり」ではなく、実際の利用状況をちゃんと計測して、回し続ける運用に切り替えます。
OpenTelemetry と BigQuery を使って、どのスキルがどれくらい使われているのかを計測し、
スキル作成前のチェックとして四つの質問を用意したり、命名規約を整えて弁別しやすい単語をつけるようにしたり、
さらに「導入以来一度も発火していない」「連続十週ゼロ回」といった基準で棚卸しをしていく、というループ型の運用です。
使われていないスキルも、雑に「いらないから削除」で終わらせず、「発火していないだけなのか」「そもそも出番がない機能なのか」「作るべきではなかったのか」の三つに分けて扱う。
そのうえで、統合したほうがいいものは統合し、記述を改善すればよくなりそうなものは書き直す。
そうやって、機能としては守りつつ、候補の数を整理していくべきだ、と述べています。
AIスキルをどんどん足していった結果、「なんかごちゃごちゃしてきたな」と感じている方には、「トークン削減より、弁別性と運用ループが大事ですよ」という視点をくれる、実務寄りの記事でした。
。。。。
四つ目は、AIによるコードレビューの「やる場所」と「お金のかかり方」を工夫して、プルリクエストの数を増やしつつ、AIレビュー費用とは切り離していこう、というお話です。
もともと筆者のチームでは、CI上でだけAIレビューを回していました。
このときの問題は分かりやすくて、プルリクエスト一件ごとに数ドルかかってしまうので、たくさん回せば回すほど費用が増えていく。
その結果、開発の途中では気軽に再実行しづらいし、指摘がマージ直前にドバッと集中してしまう、という状態になっていました。
そこで、同じレビュー基盤を「三つの場所」で動かす構成に変えます。
一つ目はこれまで通りの CI、ここは従量課金です。
二つ目は開発者のローカル環境。
三つ目がクラウド上での定期実行で、こちら二つは開発者が入る定額サブスクの枠で動かす。
ローカルや定期実行のほうで既にレビュー済みであれば、CIでは重たい処理を省略することで、CI側の従量コストを抑えていく構成ですね。
大事なポイントは、「LLMの推論そのものは、必ずサブスク側で行う」という設計にしているところです。
クラウドのコネクター的な部分は、あくまで GitHub との橋渡し役に限定して、重たい生成処理はローカルや routine エージェント側で実行する。
こうすることで、従量課金とガッツリ向き合うのではなく、「定額の中でどれだけ活用するか」という発想に切り替えています。
この仕組みによって、例えばマージ後に軽い指摘を自動で直してくれるフォローアップのプルリクを出したり、
夜間にリポジトリ全体をなめて、「ファイルごとの役割インデックス」を作るような実験的な重い処理を回したりといった、「従量課金ならちょっとためらうタスク」も、サブスクの枠内で気楽に回せるようになりました。
現時点でのROI、投資対効果としては、ゼロ点七三とまだ赤字なんですが、
これを改善するためのテコとして、「もっと定額側に寄せていくこと」と、「自動承認できる範囲を広げて、レビュー後の手作業を減らしていくこと」の二本立てで考えているそうです。
そして何より筆者が強調しているのが、「レビューを何回回すかで、いちいち迷わなくてよくなる自由度」こそが、最大の成果だという点ですね。
コストを気にして「ここで回すのはもったいないかな」とブレーキを踏むのではなく、「気になったらすぐ回せる」状態を設計で作りにいく、その発想が印象的な記事でした。
。。。。
最後、五つ目の記事です。
こちらは Tips 系で、Claude Codeを「シークレットモード」みたいな感じで使う方法、つまりメモリも履歴も残さない状態で起動するテクニックを解説しています。
まず、「メモリも履歴も残さない起動方法」として紹介されているのが、特定の環境変数をつけてコマンドを実行するやり方です。
具体的には、オートメモリを止めるものと、プロンプト履歴をスキップするものを両方オンにした状態で、Claude Codeを起動すると、そのセッションでは過去のメモリを参照せず、会話ログも保存されない。
つまり、そのターミナルを閉じたら跡が残らない、インコグニートなセッションになるわけですね。
毎回長いコマンドを打つのが面倒な場合は、シェルにエイリアスを登録しておいて、例えば「クロード・インコグニート」みたいな短い名前で呼び出せるようにしておくと便利だ、と紹介されています。
次に、「無効化できる記憶の種類」も丁寧に整理されています。
一つは `CLAUDE.md` のような、プロジェクト用の指示ファイルですね。
これは専用の環境変数をオンにすると、読み込みを完全に止めることができます。
二つ目が auto-memory、いわゆる自動学習メモ。
これも、専用の環境変数で参照と書き込みの両方を止められますし、設定ファイルのなかで「常にオフ」にしておくことも可能です。
三つ目がセッション履歴、トランスクリプトと入力履歴ですね。
これは、別の環境変数をオンにすることで、保存されなくなります。
似たようなオプションとして `claude --bare` という起動方法もあるんですが、こちらはオートメモリを無効にしてくれる代わりに、hooks やスキルといった、他の便利な機能まで全部切れてしまう。
なので、「メモリだけを止めたい」「履歴だけを残したくない」といった、ちょっとピンポイントなシークレットモードを使いたい場合は、環境変数での制御のほうが向いている、と解説されています。
そして最後に大事な補足として、「ここで扱っているのは、あくまでローカルファイルとしての履歴やメモリだけですよ」という点が強調されています。
つまり、「端末のどこに何が保存されるか」を制御している話であって、Anthropic側へのデータ送信や、その学習利用のポリシーとは別物です、と。
ローカルの痕跡を減らすための工夫として、どういうオプションがあるのかを整理してくれている、実践的な Tips 記事でした。
。。。。
というわけで、今日は全部で五本の記事をご紹介しました。
Opus ふぁいぶ 世代でシステムプロンプトが変わったことを踏まえたプロンプト設計と、行動直前のフック活用の話。
それから、同期バッチ処理がデータ増加で壊れていく過程と、そのたびにどんな対策を積み上げていけばいいかという設計の話。
三つ目は、AIスキルが五十個になった世界で、「トークンじゃなくて弁別性と運用ループがボトルネックだった」という気づきと、その運用改善。
四つ目は、AIコードレビューの場所と課金の設計を工夫して、「レビューを何回回すか迷わなくてよくなる自由度」を手に入れようという話。
そして五つ目は、Claude Codeをシークレットモードっぽく使う、メモリと履歴まわりの細かなテクニック、というラインナップでした。
気になった記事があれば、このあとショーノートに詳しい情報を載せておきますので、ぜひそちらから元の記事も読んでみてください。
「zenncast」では、番組の感想や、「こういうテーマを取り上げてほしい」といったリクエストもいつでも募集しています。
日々の開発でモヤっとしていることや、最近ハマっている技術ネタなんかも、ぜひラジオネームをつけて送ってください。
それでは、今朝はこのへんで。
お相手はマイクでした。次回の配信でまたお会いしましょう。
バイバーイ。