Reflection
読み: リフレクション
リフレクションとはAIの自己修正機能
AIが自身の回答を評価し自律的に修正を繰り返す自己振り返り機構。ハルシネーションを低減し出力の精度を大幅に高める中核技術。
かんたんに言うと
料理人がスープの味見をして、塩が足りなければ足し、再度味見をするように、AIが自分の出力をチェックして修正するプロセス。
ハルシネーションを単発推論で防げない現実とReflectionの自己修正ループ
LLMは息を吐くように嘘をつく。ハルシネーションを完全に排除することは現行のアーキテクチャでは不可能に近い。プロンプトエンジニアリングで出力形式を縛り付けても、中身の論理破綻までは防げない。
そこでReflectionの出番となる。出力した結果を別のプロンプト、あるいは別のモデルに評価させ、基準を満たさなければ修正して再出力させる仕組み。
GPT-4oにスクリプトを書かせ、それをサンドボックス環境で実行する。エラーが出たらそのスタックトレースをプロンプトに含めて再度GPT-4oに投げ返す。
このループを回すことで、単発の推論とは比べ物にならない精度を叩き出す。
ただの自己評価ではない。失敗から学び、その場で軌道修正する泥臭いプロセス。
法務や経理における実務適用とツールの選定
法務の契約書レビューや経理の請求書突合において、一発出しの推論結果をそのまま信じる実務家はいない。
DSPyのようなフレームワークを使えば、過去の契約書データから抽出した条項の妥当性を評価するパイプラインをプログラム的に組める。
Difyのワークフロー機能も使い勝手がいい。抽出ノードの直後にLLMによる評価ノードを配置し、スコアが閾値を下回れば再抽出のノードへループさせる。
MetaGPTを使って、作成者エージェントとレビュアーエージェントに相互批判させるアプローチも実用的である。
どこまでループを許容するか。実務に組み込む際、この設定は常に悩ましい。
処理時間の増加とAPIコストの高騰という代償
精度は上がる。だがタダではない。
Reflectionを組み込むと、裏でAPIが何度も叩かれることになる。入力トークンと出力トークンが雪だるま式に膨れ上がり、請求額に直結する。
AnthropicのClaude 3.5 Sonnetで5回ループを回せば、それだけで数秒から十数秒待たされる。
バッチ処理なら問題ない。だが、営業が顧客の目の前で使うタブレット端末のアプリに組み込むとどうなるか。レスポンスの遅さに現場からクレームが来る。
無限ループに陥るリスクも忘れてはならない。上限回数をハードコードしておかないと、一晩でAPIの利用枠を食いつぶす。現場でよく見る落とし穴である。
実運用に向けた評価基準と見極め
結局のところ、自社の業務プロセスにReflectionを組み込むべきか。
スピードと精度のどちらを優先するかのトレードオフになる。
物流の配送ルート計算で、数分の処理時間を許容できるなら組み込めばいい。計算ミスによるトラックの空走ロスに比べれば、APIのトークン代など誤差の範囲である。
モデルの基礎能力が上がれば、一発出しの精度が向上し、Reflectionの出番は減るかもしれない。
それでも、現時点のLLMを業務で使い物にするには、この評価と修正のループ機構から逃げることはできない。どこで妥協点を見出すか、現場の判断が分かれる。
当社の見解
当社ではClaude Code・Antigravity・Codexの3つのAIエージェントを日常業務で併用している。記憶を共有しているため、別のAIに同じ説明を繰り返す必要がない。ただし、記憶共有だけでは足りなかった。一方のAIが他方の成果物を勝手に修正して壊す事故が起きた。これを受けてファイル所有権制度を導入し、どのAIがどのファイルを所有するかを定義した。AIの自主性に頼らず、仕組みで上書きや巻き戻りを防いでいる。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。