Reasoning Engine とは何か？ — AIの知性を支える「思考・判断・行動」の制御機構

こんにちは。エンジニアの竹田です。

今回は社内のナレッジを公開いたします。フレクトでは社内には「Fラボ」という仕組みがあり、様々な技術やノウハウを共有したり自己学習したりできるようになっています。

本記事では、社内のエンジニア向けに作成した AI 基礎トレーニング資料の中から「Reasoning Engine」の章を抜粋して公開します。最新のAI Agentを理解するために欠かせないReasoning Engineを理解するためのものです。

フレクト内のエンジニアがAI Agentを作るために学んでほしくて作ったものですが、一般のエンジニアにも有益だと思いますので、ぜひご一読ください。

以降、本編となります。

はじめに

ChatGPTの登場以来、LLM（大規模言語モデル）の性能はそのパラメーター数の向上と内部アーキテクチャの進展によって急速に向上してきました。しかし我々がいつも使っているサービスとしてのAIがあれほど優秀な理由は、単純にモデルとしてのLLMの性能が高いからというわけではありません。近年特に業務利用という観点においてLLMが成果を上げている背景には、Reasoning Engineの存在があります。

本記事では、Reasoning Engineの概念から実装例、そして Salesforce Agentforce における位置づけまで、できるだけわかりやすく解説します。

なお、Reasoning Engineという言葉はまだ人によって解釈が違う曖昧なところがあり、大きくは次の2種類の意味で使われることがあるようです。

LLMの内部的な仕組みとして段階的に深く考えて回答を返す仕組み
そもそも何をすべきかを考え必要に応じてWeb検索などのツールを使い、結果を振り返りながら最適な回答を返す仕組み

今回はReasoning Engineを後者の意味と捉えて解説していきます。

Reasoning Engine とは何か？

Reasoning Engine（推論エンジン） とは、LLM が「何を・いつ・どのように考えるか」を制御するフレームワーク・アーキテクチャの総称です。LLMそのものではなく、LLMを制御するシステムといってもいいかもしれません。

「推論エンジン」という訳語について Reasoning Engine を「推論エンジン」と訳すことが多いですが、この言葉は実態を少し狭く捉えてしまう面があります。「推論」という言葉のイメージは「情報から結論を導く」という認知的な処理に限定されがちです。しかし実際の Reasoning Engine は、推論にとどまらず、外部ツールの呼び出し・実行、状態の保持と管理、行動計画の立案、自己評価とリトライなど、いわば「考えて・動いて・振り返る」という一連の思考全体を担っています。本記事でもそのような意味で "Reasoning Engine" という言葉を使っています。

LLM単体は、与えられたテキスト（プロンプト）に対して考え妥当なテキストを返すという処理をするだけです。これだけだと企業の業務タスクにおいてできることは限られます。人間が業務タスクを進めるときのことを考えてみましょう。たとえば「商品マスタ 1レコードを登録する画面を設計して」と依頼を受けたとします。そうするとこんな仕事の進め方をするかもしれません。

どんな商品を扱うか確認する
設計書として書かなければいけないことを洗い出す
商品マスタとして登録すべき値をDB定義書から考える
設計書として書きだすことを整理する
既存の設計書を見て、他の機能との整合性を確認する
考慮が足りないところがあったら再度何を書くべきか考える
これまでに考えたことを設計書として記載する

人間が業務を進めるときにはこのように1つ1つのタスクにおいて判断したりコンピュータを操作したり何かを参照しながら業務を進めます。また人間は業務を進めるために（ちょっとした）計画を立て、次に何をすべきか判断し、またタスクの実行結果に応じてすべきことを見直します。

さてこれらの人間が行う業務タスクのうち、LLMに任せられるところはどこでしょうか？これらの中の一つ一つのタスクにおける思考・判断（確認するなど）については、LLMでもできますね。でも「設計書ファイルを見る」「（ファイルに）コードを書く」「（ファイルを開いて）コードを確認する」といったことはテキストを出力することしかできないLLMにはできません。また、何をすべきか判断するというところはLLMでできるかもしれませんが、その上でこれら一連のタスクを実行するということはできません。また、タスクの実行結果に応じて見直すということもLLM単体ではできません（誰かがタスクの実行結果を渡してあげないといけない）。

Reasoning Engineが担うのはLLMだけでは実現できないこのような部分です。

簡単に言ってしまうと次の2点になります。

LLMではできない操作であるTool（ファイルを読む・書く、Web検索する、OSコマンドを読むなど）を提供する
何をすべきかをLLMに判断させ、それに従ってLLMの思考やToolの実行など一連のタスク実行を制御する

言葉だけだとわかりづらいので、もう少し整理したうえで、Reasoning EngineとLLMの関係を図示してみましょう。

かなりシンプルに表現していますが、ここに記載されていることがReasoning Engineとしての肝になる部分といっていいでしょう。

Reasoning Engineのサンプルコード

次にReasoning Engineのために、LangChainを使った（とても簡易な）サンプルコードを載せておきます。先ほどの図と比べながら読むと、プログラミング的にしなければいけないことがつかめるのではないかと思います。

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, SystemMessage, ToolMessage

# ─── ツール（Reasoning Engine が呼べる「道具」.今回はシンプルな2つだけ）───────────────────────────────
def search(query: str) -> str:
    if "天気" in query:
        return "東京は晴れ、最高気温 25℃"
    return f"「{query}」の検索結果"

def calculate(expression: str) -> str:
    return f"{expression} = {eval(expression, {'__builtins__': {}})}"

TOOLS = {"search": search, "calculate": calculate}

tool_definitions = [
    {"type": "function", "function": {
        "name": "search", "description": "Web を検索する",
        "parameters": {"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]},
    }},
    {"type": "function", "function": {
        "name": "calculate", "description": "数式を計算する",
        "parameters": {"type": "object", "properties": {"expression": {"type": "string"}}, "required": ["expression"]},
    }},
]

llm       = ChatOpenAI(model="gpt-4o", temperature=0).bind_tools(tool_definitions)  # ループ用
llm_plain = ChatOpenAI(model="gpt-4o", temperature=0)                               # 計画用

question = "今日の東京の最高気温を調べて、華氏（℉）に変換してください"

# ─── ① 問題の分解・計画（Plan-and-Execute パターン）─────────────────────────
#     Reasoning Engine が LLM に計画を立てさせる
plan = llm_plain.invoke([
    SystemMessage(content="タスクを実行ステップに分解し、各ステップで使うツールを挙げてください。"),
    HumanMessage(content=question),
])
print("【① 計画】\n", plan.content, "\n")

# ─── ②〜④ Reasoning Loop（ReAct パターン）───────────────────────────────────
#     LLM が思考・判断 → Reasoning Engine がツールを実行 → 結果を LLM へ返す を繰り返す
#     計画を SystemMessage として渡すことで、LLM が計画に沿って実行する
messages = [
    SystemMessage(content=f"以下の計画に従って実行してください:\n{plan.content}"),
    HumanMessage(content=question),
]

while True:
    response = llm.invoke(messages)       # Reasoning Loopにおけるこれまでの履歴を踏まえて、LLM が「次に何をすべきか」を判断（テキスト出力のみ）
    messages.append(response)             # 状態管理：会話履歴・中間結果を保持

    if not response.tool_calls:           # ツール不要と判断 → ⑤ へ
        break

    for call in response.tool_calls:      # Reasoning Engine がツールを実際に実行
        result = TOOLS[call["name"]](**call["args"])
        print(f"[ツール実行] {call['name']}({call['args']}) → {result}")
        messages.append(ToolMessage(content=result, tool_call_id=call["id"]))

# ─── ⑤ 最終回答の生成 ────────────────────────────────────────────────────────
#     これまでの実行結果を踏まえて LLM が最終回答を生成する
print("\n【⑤ 最終回答】", response.content)

これを実行すると次のログが出るはずです。

【① 計画】
 ステップ1: search ツールで東京の今日の気温を検索する
 ステップ2: calculate ツールで摂氏→華氏の変換式（℃ × 9/5 + 32）を計算する

[ツール実行] search({'query': '東京 今日の天気'}) → 東京は晴れ、最高気温 25℃
[ツール実行] calculate({'expression': '25 * 9/5 + 32'}) → 25 * 9/5 + 32 = 77.0

【⑤ 最終回答】 今日の東京の最高気温は 25℃（77℉）です。

（補足）Reasoning Engine の主な実装アプローチ

一般的にReasoning Engineは複数の実装パターンを組み合わせて構成されます。以下はその代表例です。性格の異なるものが混在していますが、いずれも「LLM の思考・行動をどう設計するか」ということを実現しています。

アプローチ	主な役割	概要
Chain-of-Thought (CoT)	思考品質の向上	ステップバイステップの思考を明示的に生成させる。LLM の回答精度を上げるための手法
ReAct	思考と行動の統合	Reasoning（思考）と Acting（行動）を交互に繰り返す。思考とツール実行を一体化した設計。先ほどのコード例におけるパターン
Plan-and-Execute	計画と実行の分離	まず全体計画を立て、順番に実行する。長いタスクや複雑なワークフローに向く
Tree of Thoughts (ToT)	解候補の並列探索	複数の思考経路を木構造で探索し最適解を選ぶ。回答の網羅性が必要な場面で有効
Self-Reflection / Reflexion	自己評価と改善	自分の回答を自己評価し、改善を繰り返す。エラーリカバリや品質向上に寄与

先ほどのサンプルコードでもこのうちのReAct, Plan-and-Executeを使っています。

これからの AI は「LLM 単体の性能 × Reasoning Engine の性能 × データ」で決まる

ここまでReasoning Engineの概要を説明してきました。前述した図やサンプルコードはサンプルとしてわかりやすくするため極めてシンプルな内容にしていますが、本物のReasoning Engineはもっと複雑です。何をすべきか考えるときには、そもそもどのような問題であるか分解したり、Tool実行結果を見て整合性を確認したりといったことまでやっています。何をもって最終的な回答が妥当か判断するというのも難しいですが必ず必要な処理です。

サンプルコードを見てもわかる通り、Reasoning EngineはLLMに大きく依存します。何らかの判断をする部分はLLMに任せているわけなのでその判断結果の質がLLMに依存するのは当然です。結果的にAI Agentの性能はLLMの性能とReasoning Engineの性能の掛け合わせで決まるといっていいでしょう。

さらに業務向けに考えを広げると、そこにデータ・Toolの質と種類が加わります。（本質的にはデータ自体が重要ですが、それを参照・操作するためにはToolが必要であるためセットにしています）つまり、単純に考えるのであれば、

AI Agentの性能 = LLM の性能 × Reasoning Engine の性能 × データ・Toolの質・種類

となるわけです。

LLM の性能が低ければ、いくら優れた Reasoning Engine とデータがあっても、基礎的な言語理解・生成の品質が低く、正しい判断ができません。

Reasoning Engine の性能が低ければ、強力な LLM とリッチなデータがあっても、複雑なタスクを適切に分解・実行できず、業務への適用範囲が狭まります。

データ・Toolの質・種類が乏しければ、LLM がどれだけ賢くReasoning Engineが優れていても正確な回答はできません（質の低いデータからは質の低い結果しか返らない）。

さて、業務を行うための実際にAI Agentを開発する場合を考えてみましょう。 GPT や Claude などの最先端 LLM は、契約すればAPI を通じて誰でも利用できます。つまり、使える金額次第ではあるものの、LLM 単体の性能は所与のものと考えていいでしょう。

一方で、Reasoning Engine の設計とデータ・Toolの整備は、AI Agentの設計において大きな差がつく領域です。ゆえに、我々がAI Agentを開発する場合にはこれら2つの領域をよく考えなければいけません。

Agentforce開発の場合

Salesforce の Agentforce が重要なのは、まさにこの「3要素の掛け算」を Salesforce プラットフォームの上で実現しようとしているからです。

LLM: Agentforceからアクセス可能なホストされたLLM
Reasoning Engine: Atlas Reasoning Engine + 開発者の作り込み（Topic & Action, Agent Script）
データ・Tool: Salesforce に蓄積された CRM データ（顧客、商談、活動履歴など）、及びSalesforce内でのFlow/Apex開発、MuleSoftなどでのAPI提供、既存の外部システムMCPの提供

ここでAI Agentの開発者にとって、設計の肝になる部分がReasoning Engineです。Agentforceの核ともいえるAtlas Reasoning Engineだけでも動作はしますが、そこに対してAgent ScriptでReasoning Engineを拡張するという意識をもってinstructionとtoolの提供を設計するわけです。 Agent Scriptの登場でAgentforceの制御方法はよりきめ細かなことができるようになっています。

先ほどのサンプルコードを思い出してください。もちろんAtlas Reasoning Engineの中であのコードそのものが動いているわけではなく、内部の実装は公開されているわけでは無いので想像するしかありませんが、おおよそどのような仕組みでAtlas Reasoning Engineが動作するのかは想像できると思います。

単なるブラックボックスとしてではなくReasoning Engineの挙動を理解して想定しながら、Agent Scriptを書いたりTool類を整備したりデータを整えると、より性能の高いAI Agentの構築ができるようになります。

まとめ

本記事の要点3点です。

Reasoning Engine = 「考えて・動いて・振り返る」制御機構。LLM単体では実現できないツール実行・結果評価・次の判断を担います。
AI Agentの性能は LLM × Reasoning Engine × データ・Tool の掛け算。3つの要素を高めることでAI Agentの性能は向上します。
開発者が差をつけるのはReasoning Engineとデータ・Toolの設計。Atlas Reasoning Engineの動作原理を理解したうえでAgent ScriptやToolを設計することが、業務で使えるAI Agentへの近道です。

LLMの性能の性能は所与のものとして、Reasoning Engineへの理解を深めることが、これからのAI Agent開発において重要になってきますね。