ReAct

テキスト生成だけのLLMに手足を与えるReActの推論と行動の統合

LLMは単体ではただの巨大な辞書にすぎない。プロンプトに対して確率的に尤もらしい文字列を返すだけである。しかしReActの概念を組み込むことで、この辞書は手足を持つ。

ReasoningとActingを交互に行う。これがReActの正体である。

例えば現在の東京の天気を聞かれたとき、従来のモデルは学習データ内の古い情報を返すか、分からないと答える。ReActを実装したエージェントは天気を知る必要があると推論し、外部の天気APIを叩くという行動に出る。この違いは大きい。

観察を起点とする無限のループ構造

ReActのプロセスは、思考、行動、観察のループで構成される。AIはまず何をすべきか思考し、APIを叩いたりデータベースを検索したりする。そしてその結果を観察し、次の思考へと繋げる。

ここで現場の落とし穴がある。

APIのレスポンスが想定外だった場合、AIはどう動くか。エラーメッセージを観察し、パラメータを変えて再実行する。まるで人間がデバッグしているかのような振る舞いを見せる。だが、このループが意図せず暴走することもある。無限ループに陥り、OpenAIのAPI利用料が数分で跳ね上がる光景を私は何度も見てきた。どこでループを断ち切るかの設計は、常に悩ましい。

物流や法務における実務適用と実装のリアル

エージェント構築といえば特定の有名フレームワークがもてはやされた時期があった。だが、スピードと精度を競う業務では使う気にはならない。ブラックボックス化が激しく、本番環境でのトラブルシューティングが地獄だからである。現在、実務で耐えうるのはDifyやSemantic Kernelを用いた独自実装だろう。

例えば物流部門。配送ルートの最適化において、天候APIや交通渋滞のデータベースをReActで連携させる。AIが雪の予報が出ていると推論し、別ルートの距離を計算する行動をとる。

法務部門の契約書審査でも同じである。過去の判例データベースを検索し、該当する条文と照らし合わせる。この一連のプロセスを自律的に回す。ただ、どのツールを選ぶかは現場のスキルセットによって判断が分かれる。

トークン消費の増大とトレードオフ

ReActの最大の恩恵は、LLM単体では到達できない精度の高い回答を得られること。外部の事実データにアクセスするため、ハルシネーションを起こすリスクは物理的に減る。

しかし、代償もある。

トークン消費量が桁違いに増えるのである。思考プロセスをプロンプトに含め、外部ツールの実行結果をコンテキストに積み上げていくため、あっという間にコンテキストウィンドウの上限に達する。

Claude 3.5 Sonnetのような高性能モデルを使えば精度は上がるが、コストも跳ね上がる。安いモデルを使えば、今度は推論能力が足りず、見当違いのAPIを叩き続ける。このバランスをどう取るか。

導入の是非を決める冷徹な評価基準

すべての業務にReActが必要なわけではない。

単なる文章要約や翻訳なら、従来のプロンプトエンジニアリングで十分である。外部システムとの連携が必須で、かつ手順が固定化されていない動的なプロセスにのみ、ReActの真価が発揮される。

経理部門の領収書処理を考えてみよう。OCRで読み取り、会計システムに入力するだけならRPAの領域である。だが、摘要欄の曖昧な記述から勘定科目を推論し、過去の類似取引を社内DBから検索して照合するなら、ReActの出番となる。

自社の業務プロセスが、AIの推論と行動のループを回すだけの価値があるのか。システムの運用コストと天秤にかけ、冷徹に見極めてほしい。