9.1.3 Agent の発展の歴史

学習目標

この節を終えると、次のことができるようになります。

Agent は突然現れた新しい概念ではないと理解する
ルールシステム、ワークフロー、現代の Agent の進化の関係を説明できる
「なぜ大規模言語モデルによって Agent が本当に使えるようになったのか」を理解する
小さな例を通して、各段階のシステムの違いを体験する

より広い AI の流れを見たい場合は、A.3 AI 発展史：15 段階と重要論文と合わせて読むと理解しやすくなります。この節では Agent の流れだけに絞ります。

スクリプトから現代の LLM Agent までのシステム系譜図

この図は下から上へ読むとわかりやすいです。固定スクリプトは安定したタスクを処理し、ワークフローは構造を加え、ツールを使う LLM システムは判断を加え、現代の Agent は目標・ツール・記憶・フィードバックループをまとめて扱い始めます。

Agent の前にも、自動化はすでに存在していた

最初期の自動化は「固定スクリプト」に近かった

大規模言語モデルがなかった頃から、多くの自動化システムはすでに動いていました。

定時実行タスク
フォームの自動処理
ルールエンジン
RPA のフロー型ロボット

これらのシステムには価値がありますが、共通する特徴は次の通りです。

進む道は、基本的にあらかじめ決め打ちされている。

ルールベースのロボットは「台本どおりに厳密に演じる」ようなもの

たとえば、ある問い合わせ対応ロボットは次のように動くかもしれません。

ユーザーが「返金」と言ったら、返金条件を返す
ユーザーが「証明書」と言ったら、証明書の説明を返す

ただし、実際に考えたり、柔軟に方針を変えたりするのはあまり得意ではありません。

ワークフローの時代：ルールより強いが、まだ固定的

ワークフローは「組み合わせ可能な固定フロー」

その後、システムは少しずつ複雑になり、次のようなものが登場しました。

条件分岐
複数ステップの連結
ツールの組み合わせ

たとえば、次のような流れです。

ユーザーの意図を判定する
データベースを参照する
テンプレートを使って返信文を生成する

これは純粋なルールよりも強力ですが、多くの場合、やはり「事前に設計された道」を進むだけです。

なぜワークフローは今でも重要なのか？

理由は次の通りです。

安定している
制御しやすい
デバッグしやすい

そのため、今は Agent が注目されていても、実際のプロジェクトではワークフローが大量に使われています。

なぜワークフローは今でも古くならないのか？

それは、エンジニアリングで最も現実的な次の 3 つを満たすからです。

安定
制御可能
監査可能

だからこそ、多くの初学者は後になって次のことに気づきます。

「より Agent らしい」システムが、必ずしもワークフローより価値が高いとは限らない

実際の多くの場面で、
ワークフローは昔の名残ではなく、
むしろ次のような存在です。

Agent 時代でも、依然としてとても重要な土台。

大規模言語モデルの登場前、なぜ汎用 Agent は難しかったのか？

そもそも「タスクを理解する」ことが難しかったから

以前のシステムが得意だったのは次のようなことです。

ルールに従って実行する
構造化されたフィールドを処理する

しかし、得意ではなかったのは次のようなことです。

自然な文章の指示を読み取ること
不確実な状況で次の行動を判断すること

だから多くのシステムは「自動化」はできても、「エージェント化」は難しかった

やれることはあっても、主に処理していたのは次のようなものです。

固定されていて、明確で、構造化された作業

一方で、次のような作業は苦手でした。

あいまいさがある
文脈を読む必要がある
状況に応じて動的に判断する必要がある

大規模言語モデルは何を変えたのか？

「自然言語 -> 実行可能な動作」への橋渡しが強くなった

大規模言語モデルの最も重要な変化の一つは、単に会話がうまくなったことではありません。次のようなことがより得意になったことです。

曖昧な指示を理解する
構造化された出力を生成する
ツールを選ぶ
中間ステップを組み立てる

つまり、システムはついに次のように動けるようになりました。

毎ステップを人間が全部固定しなくても、モデルの助けを借りて次の一手を決められる。

これが現代 Agent が一気に広まった理由

大規模言語モデルが次の能力を持ったときです。

指示追従
ツール呼び出し
長いコンテキストの扱い
より強い計画能力

ようやく Agent は、概念から実用へと進みました。

なぜ多くの人がこれを「本当の壁を越えた瞬間」と見るのか？

大規模言語モデル以前の自動化システムは、多くの場合次のようにしか動けませんでした。

テンプレートどおりに進む
固定された構造どおりに進む

一方で、大規模言語モデルは初めて明確に次の能力を強化しました。

曖昧な指示を理解する
構造化された動作を生成する
あいまいな条件でもタスクを進める

その結果、多くの人は強くこう感じるようになりました。

システムはもはや「手順どおりに動くだけ」ではなく、「目標に向かって自分で手順を組み立てる」ように見え始めた。

「進化版」の小さな例

ここでは、同じタスクを使って、3 つの段階の実装イメージを見てみましょう。

ルールベースのロボット

def rule_bot(query):
    if "返金" in query:
        return "返金ポリシーをご確認ください。"
    if "証明書" in query:
        return "証明書の説明をご確認ください。"
    return "申し訳ありませんが、質問を理解できませんでした。"

print(rule_bot("どうやって返金しますか"))
print(rule_bot("証明書はどうやってもらえますか"))

期待される出力：

返金ポリシーをご確認ください。
証明書の説明をご確認ください。

ワークフローシステム

def workflow_bot(query):
    if "返金" in query:
        doc = "返金ポリシー：7 日以内、かつ学習進捗が 20% 未満なら返金可能です。"
        return f"ナレッジベースによると：{doc}"
    if "証明書" in query:
        doc = "証明書の説明：プロジェクトを完了し、テストに合格すると証明書を取得できます。"
        return f"ナレッジベースによると：{doc}"
    return "フローのノードに一致しませんでした。"

print(workflow_bot("どうやって返金しますか"))

期待される出力：

ナレッジベースによると：返金ポリシー：7 日以内、かつ学習進捗が 20% 未満なら返金可能です。

簡略化した Agent

def tool_search_policy(keyword):
    docs = {
        "返金": "返金ポリシー：7 日以内、かつ学習進捗が 20% 未満なら返金可能です。",
        "証明書": "証明書の説明：プロジェクトを完了し、テストに合格すると証明書を取得できます。"
    }
    for k, v in docs.items():
        if k in keyword:
            return v
    return "関連するポリシーが見つかりませんでした。"

def simple_agent(query):
    steps = []
    steps.append("まず質問の種類を判断する")

    if "返金" in query or "証明書" in query:
        steps.append("ポリシー検索ツールを呼び出すと決める")
        evidence = tool_search_policy(query)
        steps.append(f"証拠を取得：{evidence}")
        answer = f"検索したポリシーに基づく回答は次の通りです：{evidence}"
    else:
        steps.append("今は適切なツールを判断できない")
        answer = "申し訳ありませんが、まだこのタスクは処理できません。"

    return steps, answer

steps, answer = simple_agent("あまり学習していない場合、返金できますか？")
print(steps)
print(answer)

期待される出力：

['まず質問の種類を判断する', 'ポリシー検索ツールを呼び出すと決める', '証拠を取得：返金ポリシー：7 日以内、かつ学習進捗が 20% 未満なら返金可能です。']
検索したポリシーに基づく回答は次の通りです：返金ポリシー：7 日以内、かつ学習進捗が 20% 未満なら返金可能です。

この例では、Agent はまだ簡略版ですが、「判断 -> ツール選択 -> 結果の利用」という構造が見えます。

AutoGPT ブームから今日まで

初期のブームは何をもたらしたのか？

当時、多くの人は大規模言語モデルによって次のことができると気づきました。

自分で計画を立てる
自分でツールを呼び出す
自分でループ実行する

その結果、「完全自動の Agent」を目指す試みが大量に生まれました。

その後、より現実的になった

実践してみると、次のことがわかりました。

完全に自由な Agent は、必ずしも安定しない
複数ステップのシステムは誤りが積み重なりやすい
コストと遅延が大きくなりやすい

そのため、業界は少しずつより成熟した方向へ進みました。

ワークフローで Agent を制約する
ツール呼び出しで安定性を高める
評価と観測で制御しやすくする

これは、「熱狂からエンジニアリングへ移る」過程だと言えます。

なぜこの歴史は初学者にとって特に大事なのか？

それは、よくある誤解を避けられるからです。

Agent は、自由であればあるほど優れていると思ってしまう

でも、現実はそうではありません。
本当に価値が高いのは、次のような性質です。

安定
説明可能
復元可能
再実行可能

だからこそ、AutoGPT の歴史で一番覚えておくべきなのは熱狂そのものではありません。
むしろ、業界全体で行われた公開実験のようなものだった、という点です。

まず可能性が見え、そのあと現実によってエンジニアリング上の制約に引き戻された。

今日の Agent はどんなものに近いのか？

「無限の自律」ではなく「有限の自律」

より成熟した Agent システムは、通常次のようにします。

明確な目標範囲を与える
使えるツールを制限する
中間状態を記録する
タイムアウトと安全ガードを設定する

それは「フロー制約付きの知的実行器」に近い

だから今、多くのチームは「最も自由な Agent」を目指すのではなく、次をより重視しています。

安定
再実行可能
監査可能

初学者がよくする誤解

Agent の歴史は ChatGPT から始まったと思う

違います。
ChatGPT や LLM は、Agent を新しい段階へ進めたにすぎません。

古いシステムは全部遅れていると思う

ルールシステムやワークフローは、今でも多くの産業現場で主力です。

自律性が高いほど進んでいると思う

実際の開発では、「賢く聞こえること」よりも、制御しやすさのほうが重要なことが多いです。

残す証拠

このページを終えたら、この証拠カードを残します。

エージェント境界: これが chatbot や固定ワークフローとどう違うか
目標/状態/行動: 目標、現在の状態、次の行動、観測
アーキテクチャ要素: planner、tools、memory、guardrails、evaluator
失敗確認: 自律性が高すぎる、あいまいな目標、状態不足、または trace がない
次の行動: 追跡可能な最小の single-agent ループを構築する

まとめ

この節で最も重要なのは次の理解です。

Agent は突然生まれた新種ではなく、自動化システムが大規模言語モデル時代に能力を大きく伸ばしたものだ。

歴史を理解すると、次の判断が落ち着いてできるようになります。
いつ Agent を使うべきか、いつワークフローだけで十分か。

練習

simple_agent() に、例えば「計算機」のようなツールを追加してみましょう。
ルールベースのロボット、ワークフロー、Agent の違いを自分の言葉でまとめてみましょう。
考えてみましょう。なぜ多くのチームは Agent プロジェクトでも、最後までたくさんの固定フローノードを残すのでしょうか。

プロジェクト参考とレビュー観点

計算機ツールは数値計算タスクだけにルーティングし、入力を検証し、構造化された結果または明確なエラーを返すべきです。
ルールベースのボットは固定条件に一致させます。ワークフローは事前定義された手順を実行します。Agent は目標、文脈、observation に基づいてツールや行動を選びます。
固定ノードは、テスト、監査、権限管理、復旧がしやすいため今でも有用です。実際の Agent システムでは、決定的なワークフローと柔軟な Agent ステップを混ぜることがよくあります。