AIそのものは難しい。でも、AI「システム」なら話は違う
1. はじめに
AIそのものは、確かに難しいです。LLMの内部構造、学習、推論、Attention、Embeddingなど、モデルそのものへ踏み込めば簡単な話ではありません。
でも、AI「システム」になると話は少し違います。
LLM、Agent、Tool、Skill、MCP、RAG。AIシステムでは新しい言葉が次々に登場します。「今からこんな新しいことを覚えるのか」「これまでの知識はもう役に立たないのか」そんなふうに思っている人はいませんか。
システムを長くやってきた人なら、ここで少し違う見方ができます。**「これ、昔の何に近いんだ？」**と考えることです。
たとえば、
- LLM → Rule Engine / Inference Engine
- Context → Working Memory / Input
- Tool → Function / API
- Agent → Workflow Engine / Orchestrator
- Skill → Runbook / Playbook
- MCP → Protocol / 共通I/F
- RAG → Search + 後続処理へのデータ受け渡し
と置いてみると、急に見覚えのある構造になります。
もちろん、これらは同じものではありません。ここで比較しているのは内部実装や動作原理ではなく、システム全体の中で担っている役割です。
AIによって新しく加わった性質はあります。でも、AIシステムを構成する考え方のすべてが新しくなったわけではありません。
僕たちはこれまで、
- 処理をどう分けるか
- 判断をどこへ置くか
- Interfaceをどう切るか
- Stateをどこで持つか
- 外部機能をどう呼ぶか
- 権限をどこで制御するか
を考えてきました。その知識は、AIシステムになったから突然無価値になるものではありません。むしろ、既に持っている概念へAIで増えたものを足し、少しアレンジするだけで話せることがたくさんあります。
僕たちは、すでにそのための材料を持っています。 それは、これまでシステムを作ってきた経験の中で積み上げた財産です。その財産を「AIは新しいから」と全部捨ててしまうのは、少しもったいない。
そして、この記事で特に見たいのは、AIによって何が不要になったかではありません。
AIが減らしたのは、仕組みそのものというより、人間が事前に明示しなければならなかった領域です。
Workflowがなくなったわけではない。Ruleがなくなったわけでもない。検索も、認証も、認可も、State管理も残ります。一方で、すべての分岐、すべての判断条件、すべての入力形式を、人間が事前に列挙して実装する必要は少しずつ減らせるようになりました。
この記事では、AIシステムを構成する概念について、
- 何を表すものなのか
- 従来と変わらない役割は何か
- AIによって何が変わったのか
- 人間が明示的に作る範囲をどこまで減らせるのか
- 何に注意する必要があるのか
を見ていきます。
前の記事では、LLMからTool、Agent、Skill、MCPまでを順番に整理しました。今回はその補足として、従来のシステムを知っている側からAIシステムを見ていきます。そのため、API、Protocol、Workflow、Rule Engine、Runtimeなどの言葉にある程度馴染みがある人を想定しています。
新しい言葉を覚えるための辞書ではなく、システム屋がAIシステムの構造をつかむための地図を作ってみます。なお、本稿でいう「減らせるもの」は、その仕組み自体が不要になるという意味ではありません。人間が事前に明示的に設計・実装する範囲を減らせるものという意味で使います。
2. まず地図を置いてみる
最初に全体を並べます。完全な1対1対応ではありません。ここでも比較しているのは内部実装ではなく、AIシステム全体の中で担うアーキテクチャ上の役割です。
| AIシステムの概念 | 従来システムで近いもの | 変わらない役割 | 変わった機能 | 起源・普及のきっかけ |
|---|---|---|---|---|
| LLM | Rule Engine / Inference Engine | 入力から判断・出力を得る | 自然言語や非構造情報を判断材料にできる | Transformer以降のLLM研究、GPT系列など |
| Context | Working Memory / Facts / Input | 判断材料を渡す | 会話、文書、Tool結果などを広く扱える | 一般的な計算機・NLP用語 |
| Tool | Function / API / Command | 外部機能を利用する | 利用するCapabilityをLLMが選択できる | Function Callingなどで普及 |
| Function Calling / Tool Calling | RPC / API Call Request | 処理と引数を指定する | 呼び出す処理をLLMが選択できる | OpenAI Function Calling、2023 |
| Agent | Workflow Engine / Orchestrator | Stateを参照・更新しながら処理を進める | 次のActionをLLMへ判断させられる | Agent概念自体は古く、LLM時代にはReActなど |
| Skill | Runbook / Playbook / 業務手順 | 仕事の進め方を再利用する | 判断基準までLLMへ渡せる | 製品・Frameworkごとに異なる |
| MCP | Protocol / 共通I/F | 接続境界を共通化する | AI Host向けにTool、Resource、Promptなどを共通に扱える | Anthropic、2024 |
| RAG | Search + 後続処理へのデータ受け渡し | 外部情報を取得して利用する | 取得した情報をLLMの判断材料として利用できる | Lewisら、2020 |
| Guardrail / Policy | Validation / Authorization / Policy Engine | 実行可能範囲を制御する | Instructionによる柔らかい制御を組み合わせられる | 単一の起源なし |
この表を、処理の流れを単純化した概念図として別の角度から見ると、こんなふうにも整理できます。
もちろん、すべてが実行時判断へ移るわけではありません。Authorization、Validation、Audit、State、強制Policyなど、人間が設計時に明確に決め、システムとして守らせる領域は残ります。
つまり、設計時に人間が決めることがなくなったのではなく、設計時に事前確定しなければならない範囲を小さくできるようになった、という見方です。
2.1 用語の起源・普及について
- Function Calling / Tool Calling：OpenAIが2023年にFunction CallingをAPIへ導入し、広く知られるようになった
- Agent：Agent自体は古くからあるAIの概念。現在のLLM AgentにはReActなどの研究が影響している
- Skill：単一の標準仕様で定義された用語ではなく、製品やFrameworkによって意味や実装が異なる
- MCP：Anthropicが2024年にModel Context Protocolとして公開
- RAG：Patrick Lewisらが2020年にRetrieval-Augmented Generationとして提案
- Guardrail / Policy：単一の提唱元を持つ用語ではない
3. LLM ― 判断を担当するもの
AIシステムの中でLLMは、入力された情報から判断や出力を生成する部分に位置します。なお本稿では便宜上、入力に応じて後続処理に利用する出力を生成することを広く「判断」と呼びます。
従来システムで近い役割を持つものとして、
- Rule Engine
- Inference Engine
- Expert Systemの推論部
などがあります。
ここでも似ているのは役割です。Rule Engineが明示された規則を決定論的に評価するのに対し、LLMはまったく異なる仕組みで出力を生成します。
3.1 変わらない役割
- 入力された情報をもとに判断結果を返す
- 後続処理で利用できる出力を生成する
3.2 変わった機能
- 自然言語をそのまま扱える
- 非構造情報を判断材料にできる
- 判断条件をすべて事前に列挙しなくてもよい
- 曖昧な入力にも対応できる範囲が広がった
3.3 減らせるもの
- 判断条件をすべて明示的なRuleとして記述する範囲
- 自然言語を事前に細かく分類・構造化する処理
- 個別パターンごとの分岐ロジック
LLMによってRule Engineそのものが不要になるわけではありません。減らせるのは、曖昧な判断まで含めて、すべてを人間が事前にRuleとして列挙する範囲です。
3.4 注意事項
- 強制したいRuleは従来通りシステム側で持つ
- 再現性が必要な判断までLLMへ任せる必要はない
- LLMとRule Engineは内部の実現方式が大きく異なる
4. Context ― 判断材料を渡すもの
Contextは、その時点でLLMの判断に利用させる情報を表します。従来システムで近いものは、
- Working Memory
- Facts
- Request
- Session Data
です。
4.1 変わらない役割
- 判断する処理へ必要な情報を渡す
- その時点の処理条件を提供する
4.2 変わった機能
- 会話を判断材料として利用できる
- 文書を判断材料として利用できる
- Toolの実行結果を判断材料へ加えられる
- 検索結果やInstructionなど、異なる種類の情報からContextを構成できる
4.3 減らせるもの
- 判断前にすべての情報を構造化する範囲
- 文書から項目を抽出するためだけの個別処理
- 入力形式ごとの変換ロジック
従来は、後続処理が扱える形式へ入力を変換するためだけの処理をかなり書いていました。LLMは非構造情報を扱えるため、その事前構造化の範囲を減らせます。
4.4 注意事項
- ContextとStateは分けて考える
- Contextへ入れられる量には制約がある
- 必要な情報を何でも入れればよいわけではない
- 同じContextを構成する情報でも、Instruction、User入力、Tool結果、外部文書では信頼境界や優先順位が異なる
「Contextに入っている」というだけで、すべての情報を同じ信頼度で扱えるわけではありません。この境界はAIシステムでも設計対象として残ります。
5. Tool ― 外部Capabilityを利用するもの
Toolは、AIシステムから利用できる外部Capabilityを表します。実体としては、
- API
- Function
- Command
- Database Access
- File操作
などがあります。
5.1 変わらない役割
- 外部機能を呼び出す
- 外界から情報を取得する
- 外界へ処理を実行する
5.2 変わった機能
- どのToolを使うかをLLMが判断できる
- 自然言語による依頼から利用するCapabilityを選択できる
- Toolの実行結果を次の判断へ利用できる
5.3 減らせるもの
- Tool選択をすべてApplication Logicへ記述する範囲
- 条件ごとに呼び出し先を固定する分岐
- Userの依頼をAPI単位へ変換する個別処理
APIやFunctionは当然残ります。変わるのは、それを**「いつ使うか」までApplication Logicへ固定的に書く必要性**です。
5.4 注意事項
- Toolの実行主体はRuntime側に置ける
- ToolはAPIという実装方式だけを意味しない
- 読み取りと更新など、Capabilityごとの権限制御は必要
6. Agent ― 目的に向かって処理を進めるもの
Agentは、AIシステムの中で目的に向かって状況を判断しながら処理を進める論理的な実行主体を表します。従来システムで近いものは、
- Workflow Engine
- Orchestrator
- Application Runtime
です。
6.1 変わらない役割
- Stateを参照・更新しながら処理を進める
- 複数の処理を順番に実行する
- 実行結果を確認する
- 条件によって次の処理を変える
Stateの物理的な保持場所はAgent自身とは限りません。Runtime、Session Store、Checkpoint、外部Storeなどに置く構成もあります。ここでいうAgentは、状態を引き継ぎながら処理を進める論理的な主体として捉えています。
6.2 変わった機能
- 次のActionをLLMへ判断させられる
- ObservationをもとにPlanを変更できる
- 事前に想定していない状況へ対応できる範囲が広がった
- 利用するToolを実行時に選べる
6.3 減らせるもの
- すべての分岐をWorkflowへ事前定義する範囲
- 例外パターンごとの個別実装
- 処理順序を完全に固定する必要性
つまり、Workflowを消すのではなく、Workflowの「事前確定部分」を小さくできます。
6.4 注意事項
- 重要な制御までAgentの判断へ委ねる必要はない
- Actionの実行可否はRuntime側でも制御する
- 自律性を高くするほど権限管理や監査が重要になる
7. Skill ― 仕事の進め方を再利用するもの
Skillは、AIシステムの中である仕事をどう進めるかという再利用可能な手順や知識を表します。従来システムで近いものは、
- Runbook
- Playbook
- 業務手順
- 運用標準
です。
7.1 変わらない役割
- 標準的な仕事の進め方を再利用する
- 利用する機能を整理する
- 判断基準や注意事項を共有する
- 異常時の対応方法を定める
7.2 変わった機能
- 判断基準をLLMへそのまま渡せる
- 曖昧さを含む業務手順を扱える
- 実行時の状況に応じて手順を変えられる
- 自然言語で手順を記述できる
7.3 減らせるもの
- 業務手順をすべて固定Workflowとして実装する範囲
- 細かな例外ごとの分岐定義
- 手順書をApplication Logicへ変換する作業
手順書が消えるのではなく、「手順書 → Application Logic」という翻訳作業の一部をLLM側へ移せます。
7.4 注意事項
- Skillという語には単一の標準仕様がない
- 製品やFrameworkによって意味や実装が異なる
- 絶対に守る制御はSkillだけに任せずRuntime側でも強制する
8. MCP ― Capabilityとの接続方法をそろえるもの
MCPは、AIシステムにおけるAI Hostと外部Capabilityとの接続境界を共通化するProtocolです。従来システムで近いものは、
- Protocol
- 共通I/F
- Connector Interface
です。
8.1 変わらない役割
- 異なる実装間の接続方法を共通化する
- 接続先ごとの個別依存を減らす
- 境界の両側を独立して変更しやすくする
8.2 変わった機能
- AI HostからToolを共通の形式で扱える
- Resourceを共通の形式で扱える
- PromptなどAI向けの要素も接続境界上で扱える
- 接続先が提供するCapabilityをHost側から発見できる
8.3 減らせるもの
- HostとCapabilityの組み合わせごとの個別接続実装
- AIサービスごとの専用Connector
- 外部機能ごとの独自Tool定義
ここで減るのはCapabilityではありません。HostとCapabilityの組み合わせごとに専用の接続方式を用意する範囲です。
8.4 注意事項
- MCPそのものはCapabilityではない
- 成果へ直接効くのは接続先のToolやResource
- 認証・認可・権限管理は別途必要
- MCP対応だけで異なるHost上の動作が完全に同一になるわけではない
TCP/IPを使ったから成果物が詳しくなるわけではありません。その通信を使って、
- どこへ接続したのか
- 何を取得したのか
- 何を実行したのか
が成果へ効きます。MCPも同じように、Protocolと、その先のCapabilityは分けて考えると整理しやすくなります。
9. RAG ― 外部情報を判断材料へ加えるもの
RAGは、AIシステムの中で外部から取得した情報をLLMのContextへ加えて生成に利用する構成を表します。従来システムで近いものは、
- Search
- Database検索
- 情報取得
- 後続処理へのデータ受け渡し
です。
9.1 変わらない役割
- 必要な情報を検索する
- 外部から情報を取得する
- 取得した情報を後続処理へ渡す
9.2 変わった機能
- 検索・取得した文章を、構造化データへ変換せずLLMの判断材料として利用できる
- 文書の内容をLLMが解釈できる
- 取得した情報を生成時の判断材料として利用できる
9.3 減らせるもの
- 検索結果を個別のApplication Logicで解釈する範囲
- 文書を処理用データへ変換する個別実装
- 情報源ごとの専用解析処理
検索処理自体がなくなるわけではありませんし、実際のRAGではChunking、Ranking、Reranking、Filtering、Context Constructionなどが入ることもあります。変わったのは、取得した文章をすべて構造化データへ変換してから後続処理へ渡すことが必須ではなくなった点です。
9.4 注意事項
- 取得した情報の正しさは別途考える必要がある
- Retrievalの品質が生成結果へ影響する
- RAGによる情報取得とModelの学習は別の処理
10. Guardrail / Policy ― 判断できる範囲を制御するもの
本稿ではGuardrailやPolicyを、AIシステムの中でLLMの判断やToolの実行を、許容された範囲へ制約する仕組みの総称として扱います。従来システムで近いものは、
- Validation
- Authorization
- Policy Engine
- Approval Gate
です。
10.1 変わらない役割
- 禁止された操作を止める
- 権限を確認する
- 入力を検証する
- 必要な承認を要求する
10.2 変わった機能
- LLMへ自然言語で判断基準を与えられる
- 固定Ruleにしにくい注意事項もInstructionとして渡せる
- 状況に応じて人間へ確認する判断をLLMへ任せられる
10.3 減らせるもの
- 曖昧な業務判断をすべて固定Ruleとして実装する範囲
ここでは、柔らかい判断の一部をLLMへ寄せられるようになった、と考えると分かりやすいです。一方で、認可や金額上限のような強制条件は従来通りシステム側で守ります。
10.4 注意事項
- 認可や金額上限など強制条件は従来通りシステム側で守る
- Promptに書くことと、システムとして強制することは分ける
- LLMに任せる判断とPolicyとして固定する判断の境界を設計する
11. まとめ ― 持っている財産を捨てる必要はない
AIそのものを理解しようとすれば、確かに難しい。でも、AIシステムを構成する要素をここまで並べると、かなり普通のシステムに見えてきます。
従来システムにも、
- 判断するもの
- 判断材料
- 外部機能
- Workflow
- 業務手順
- Protocol
- 検索
- Policy
はありました。
AIによって変わったのは、
- 自然言語をそのまま扱える
- 非構造情報を判断材料にできる
- 条件分岐をすべて事前に書かなくてもよい
- 利用するCapabilityを実行時に選べる
- ObservationによってPlanを変更できる
- 曖昧な業務手順を実行時に解釈できる
といった部分です。
そして、その結果として減らせるようになったのは、
- 事前に列挙するRule
- 固定的な条件分岐
- 入力を構造化するためだけの処理
- Tool選択の個別ロジック
- 例外ごとのWorkflow定義
- Hostごとの個別接続
- 文書を解釈するためだけの専用処理
です。
ここで重要なのは、これらの仕組みそのものが消えたわけではないということです。
AIが大きく変えたのは、従来システムを丸ごと置き換えたことではなく、人間が事前に明示しなければならなかった領域を縮めたことだと考えると、かなり整理しやすくなります。
言い換えると、設計時に人間が決めていたことの一部を、実行時の解釈や選択へ移せるようになった。その一方で、何を実行してよいのか、どこまで任せるのか、何を必ず守らせるのかは、依然として設計しなければなりません。
だから、
- 認証
- 認可
- 強制Rule
- Validation
- State管理
- Audit
- Protocol
- Interface
- 責任境界
といったものは残ります。この辺りはAIシステムになっても、やはり普通のシステム設計です。
繰り返しになりますが、これまでに積み上げたシステム設計の知識や経験は、AIになったから突然使えなくなるものではありません。むしろ、
- Interfaceをどう切るか
- Stateをどこで持つか
- Ruleと実行をどう分けるか
- 権限をどこで制御するか
- Workflowをどう組むか
- 外部Serviceとどう接続するか
といった考え方は、そのままAIシステムを理解する材料になります。
新しく増えた部分だけを足し、必要なところを少しアレンジすればいい。これまでに積み上げた知識や経験は、僕たちの財産です。
AIが出てきたからといって、その財産を捨ててしまうのはもったいない。
新しいAIシステムの概念が出てきたら、まず**「これは従来システムの何に近いのか」**を見る。そのあとに、
- 変わらない役割は何か
- 何が変わったのか
- 何を減らせるのか
- どこに注意するのか
を確認する。
名前や実装は次々に変わります。でも、その下にあるシステムの役割は、案外見覚えがあります。
AIそのものは難しい。でもAI「システム」なら、僕たちがこれまで積み上げてきた知識から話を始められるのです。