エージェントを「使わない」設計判断
澁井氏が最初に示した鉄則はシンプルだ。「不確実なものに対処するときの鉄則は、局所化して制限して評価すること。これを徹底することだと私は思っております」。LLMが登場する前から確率的な世界で10年ほど仕事をしてきた澁井氏は、エージェントという便利な存在をソフトウェアに組み込むにあたって、その役割を可能な限り最小化することを提案する。決定論的に解ける部分を先に作り込み、そこから漏れるエッジケースや、自然言語という曖昧さを扱わなければならない領域にだけエージェントを使うという発想だ。
この考え方を裏付けるのが、澁井氏が過去に手がけた商品レコメンデーションシステムの事例である。商品の推薦は基本的にロングテールになる。よく売れる主要商品はログデータが豊富でルールベースの推薦がしやすいが、アクセスもログもほとんどない商品は、データがないまま存在し続ける。澁井氏はこの領域に、商品説明とユーザープロフィールを自然言語として読み取れるLLMエージェントをあて、意味的な側面から推薦する手法を採った。運用を続けるうちにマイナー商品のアクセスログが蓄積され、ルールベースや機械学習でカバーできる範囲は徐々に広がっていく。「最終的にLLMが使われる範囲を完全にエッジケースに落とし込んでいく」というのが、澁井氏が実際にうまくいったと語る設計の型だ。決定論の領域を増やし、エージェントが担う部分を減らしていくことこそが、ソフトウェアエンジニアリングとして安定し、信頼を作るやり方だと澁井氏は結論づける。
レビューを減らす「ハーネス」という発明
コーディングエージェントに何をどう作らせるかを規定する制御ルールを、澁井氏は「ハーネス」と呼ぶ。ただし、その完璧なルールはいきなり書けるものではないという。「コーディングエージェントがこういう挙動をするとか、こういうところで間違えるよね、という経験則がある程度あるかもしれませんが、経験則に頼ってはいけないというのはソフトウェア自体が長年言われてきていること」。そこで澁井氏が提案するのは、観測し、制御し、フィードバックするというDevOpsと同様のサイクルをハーネスの改善に適用することだ。ハーネスを改善しながらコーディングエージェントの出力を改善していく、この構造こそが「ループ」と呼ばれるものの本質だという。
改善の指標としては、リリースの頻度・リードタイム・変更失敗率といったメトリクスに加え、もう一歩手前の「レビュー」自体をメトリクス化することも重要になる。「エージェントが世の中に広まっていって、人間よりも生産性が高い状態においては、やはり一番重要なリソース、貴重なリソースは、経験のあるシニアなエンジニア」だと澁井氏は語る。だからこそ、シニアエンジニアがレビューする量やコーディングする量を最小化するようにハーネスを磨き込み、それを企画のリポジトリやドキュメントを通じて、コーディングエージェントを使う全員に配っていくという運用が現実に行われているという。
