再現性の問題
同じエージェントに同じタスクを2回実行させると、異なる結果が返ってくることがあります。モデルが異なる単語を選び、異なるツール呼び出しを判断し、異なる推論経路を辿るかもしれません。この非決定性は言語モデルの一つの特徴(これによって創造性や自然な出力が生まれます)ですが、予測可能な挙動を必要とする本番システムにとっては課題となります。
顧客から「エージェントが誤った結果を出した」という報告を受けたとき、その問題を再現したいと考えます。しかしエージェントが2回続けて同じ挙動を見せないなら、再現は困難になります。バグが2回目には現れず、診断も修正もできない状況に陥りかねません。
非決定性の発生源
非決定性の主要な発生源は、モデルのtemperatureパラメータです。temperatureがゼロのとき、モデルの出力はほぼ決定的になります(浮動小数点演算の差異により完全な決定的ではありませんが)。temperatureが高くなるほど、実行ごとの出力のばらつきは大きくなります。
ツールの結果も非決定性をもたらし得ます。エージェントがデータベースに問い合わせ、前回の実行以降にデータが変わっていれば、エージェントは異なる情報を受け取り、異なる判断をするかもしれません。Web検索は時刻によって異なる結果を返します。実行間でファイル内容が変わることすらあります。
コンテキストの順序も影響します。複数のMCPサーバーが結果を返す場合、それらがコンテキストにどんな順序で現れるかがモデルの判断に影響することがあります。コンテキスト順序のわずかな変化が、異なる推論経路につながり得るのです。
決定性が重要なとき
すべてのエージェント用途に決定的な挙動が必要なわけではありません。創造的タスク、探索的研究、ブレインストーミングはばらつきから恩恵を受けます。実行のたびに異なるアプローチを取れるモデルの能力は、決定的なシステムでは見逃されてしまう洞察をもたらしてくれます。
決定性が重要になるのは、エージェントの出力が下流システムに流れる場合、結果に監査可能性が要求される場合、そして一貫性がユーザーの期待となっている場合です。財務計算、レポート生成、データ処理パイプライン、そして「昨日は動いたのに今日は違う結果」が許容されないあらゆるタスクが、決定的なエージェント挙動から恩恵を受けます。
一貫性を高める手法
temperatureをゼロ(かそれに近い値)に設定するのが最も直接的な方法です。これによってモデルは各ステップで最も確率の高いトークンを選ぶようになり、出力のばらつきが減ります。トレードオフは創造性の低下であり、ユースケースによって問題になることもならないこともあります。
構造化された出力フォーマットは、モデルが生み出せるものを制約することでばらつきを減らします。自由記述のテキスト応答ではなく、エージェントには下流システムが安定して解析できる構造化データ(JSON、特定のテンプレート)を出力させましょう。
ツール結果のキャッシュは、繰り返し実行で同じデータが見えるようにします。エージェントがステップ3でデータベースに問い合わせるなら、その結果をキャッシュすれば、同じタスクの後続実行は同一データを見ることになり、ばらつきの一因が取り除かれます。
実行前の明示的なプランニングも、エージェントを早い段階で特定のアプローチに固定する点で有効です。プランが定まれば、実行ステップはより制約され、結果として一貫性が高まります。
非決定的システムのテスト
エージェントベースシステムのテストには、決定的なソフトウェアとは異なるアプローチが必要です。完全一致でチェックするのではなく、出力の性質をテストしましょう。結果に必要な情報は含まれているか? 正しいフォーマットになっているか? 品質基準を満たしているか?
同じテストケースを複数回実行し、成功率が閾値を満たすかを確認する統計的テストは、単発の合否テストよりも適しています。エージェントが100回中95回正しい結果を出すという情報は、たまたま合格または不合格だった単発実行よりも多くを物語ります。