確率論の世界では、ソフトウェア工学の当たり前がこう変わる
ここから澁井氏は、LLMやAIエージェントをソフトウェアに組み込む際の具体的な設計に踏み込む。エージェントもLLMも、使う側から見れば単なるREST APIか、自前のGPUサーバーで動くモデルに過ぎず、リクエストを送ってレスポンスを受け取るという点では通常のソフトウェアと変わらない。ただし挙動が自然言語かつ確率的であることを踏まえると、通常のソフトウェア工学における「インターフェース」「データ」「テスト・レビュー」「外部サービス連携」は、LLM・AIエージェントの世界では「インターフェース／プロンプト」「コンテキスト／メモリー」「Eval」「ツール／MCP」という4つのコンポーネントに対応すると澁井氏は整理する。
まずインターフェースについて。「自然言語で返ってきたものでもできる限り自然言語のままでは持ちたくない、というのがLLMが世の中に出てプログラムに組み込むときに人類が最初に直面した課題」と澁井氏は語る。この課題にOpenAIやAnthropicが提示した解決策が構造化出力だ。LLMの出力をJSONスキーマに沿ったデータクラスとして強制的に返させる仕組みだが、澁井氏が強調するのは、この構造化出力のためのスキーマ設計を、人間だけでなくコーディングエージェントにも同じルールで実践させる必要があるという点だ。データ領域についても同様で、自然言語ならテキストファイル、構造化データならJSONやデータベースといった使い分けをデザインカタログとしてハーネスに落とし込み、データの出所やリネージを明確にすることをコーディングエージェントに守らせるという。
ツール／MCPについては、LLMが数学的な計算を苦手とする弱点への対処が語られた。「10桁くらいの計算をやらせてみると、意外と間違えたりする」ため、論理的に解ける処理はFunction CallingやMCPを通じてLLMの外部に委託する。その際に重要になるのが、ツールが持つ副作用の分類だ。読み取りのみで副作用のないもの、書き込みを伴うが可逆なもの、外部送信のように不可逆なもの、というように、これらをあらかじめ整理し、いつ使ってよく、いつ使ってはいけないかをコーディングエージェントに明示することがハーネスの役割になる。
AIエージェント時代の失敗パターンの蓄積が、次の方法論になる
最後に語られたのがテストと評価だ。LLMの呼び出しコストは通常の関数呼び出しの100倍程度に達するといい、コーディングエージェントが良かれと思ってテストを全件実行し、「いつの間にか50ドルぐらい」かかっていたという失敗談も披露された。澁井氏は機械学習の時代から存在する「Predictive Test Selection」という手法を引き合いに、変更に対する重要度でテストを優先順位付けし、全件ではなく1割程度に絞って実行させることを提案する。
こうした個々のプラクティスは、増やせば増やすほどルールが複雑になり、選びきれなくなる。澁井氏が最後に示したのは、こうしたハーネス群をさらに整理し、必要なときに必要なものを選べるようにする「ハーネスに対するメタハーネス」を作るという視点だ。「技術は今までのソフトウェアと全然違うことをやっていかなければいけないが、そういった当たり前が変わっていくからこそ、新しいことを提唱してそれを実践していくという世界観になってきているのではないか」。
長年ソフトウェアを書き、数々の失敗と知見を積み重ねてきたエンジニアだからこそ、コーディングエージェントやLLMが陥りやすい失敗のパターンをもとに信頼を作るメソドロジーを提唱できる。それこそが、変化のただ中にいるエンジニアの仕事だと澁井氏は締めくくった。
