- 生成AIは、指示に応じて文章・画像・表を作って終わります。その先は人が使います。
- AIエージェントは、ひとつの仕事を受け取り、情報を調べ、システムを開き、与えられた権限の範囲で最後まで片づけます。
- エージェンティックAIは、計画を立て、仕事を分け、複数の工程とシステムを束ねる仕組みです。範囲と承認の場所は人が決めます。
- まず最初の段を正確にし、一段ずつ上がります。上の段ほど、権限と、結果に責任を持つ人が必要になります。
三つの違いは「次の一手を誰が打つか」
新しく入った三人の社員を想像してください。一人目は手紙の下書きが上手ですが、書き終えると机に置いていきます。二人目は「注文はいつ届くか」といった用件をひとつ受け取り、システムを開いて在庫を確認し、お客様に返事をするところまで片づけます。三人目はチームリーダーで、大きな目標を受け取り、細かく分けてメンバーに渡し、進み具合を追い、自分の権限を超える件だけを持ってきます。この三人が、生成AI、AIエージェント、エージェンティックAIです。定義は会社によって揺れています。本稿では、開発チームがシステムを設計するときの定義を使います。
生成AIは、指示から新しいものを作るAIです。文章、画像、表、コード。中核にあるのはLLM（大規模言語モデル）です。
AIエージェントは、ひとつの目標を受け取り、どこを調べ、どのシステムを呼び、何工程踏むかを自分で決めて仕事を終えるソフトウェアです。動けるのは、与えられたツールと権限の範囲内です。エージェントがシステムを開く仕組みをTool Calling（ツール呼び出し）と呼びます。
エージェンティックAI（エージェント型AIとも呼ばれます）は、システム全体の設計思想です。AIが計画を立て、仕事を分け、複数のエージェントやシステムを束ね、人が決めた範囲の中で次の一手を自分で選びます。全体を束ねる層がオーケストレーションです。エージェンティックはシステムの性質を指し、エージェントはその部品のひとつです。
生成AIは答えを作って終わる
向いているのは、もともと人が確認してから使う仕事です。たとえばLINE公式アカウント（LINE OA。タイの企業が販売や顧客対応に最もよく使うメッセージ窓口）でのお客様への返信を下書きし、担当者が送る。結果はあくまで、人を待つ下書きです。
用意するものは、明確な指示と、正しい社内文書です。よく使われる方法がRAG（検索拡張生成）で、答える前に自社の文書を検索させます。よくある失敗は、データがないのに自信を持って答えることです。トラックの配車表を見たことがないのに納品日を答える、今日の在庫や未回収残高を知らない、といったことが起きます。
AIエージェントはひとつの仕事を最後まで片づける
エージェントの動きは一巡の繰り返しです。目標を受け取り、ツールを選び、実行し、結果を見て、続けるか、止めて人に聞くかを決めます。
タイの企業が最初に任せるのは、質問は毎回同じなのに、答えるにはシステムを開く必要がある仕事です。LINE OAで注文状況を聞かれたら、ERPで注文番号を探し、納品日と追跡番号を返す。メールで届いたタイ語の請求書を読み取り、発注書と突き合わせ、支払いを起票して承認待ちにする。どちらも開くシステムは少なく、間違えても取り消せます。
追加で必要なのは、ERP・CRM・会計ソフトへのAPI、仕事に必要な最小限の権限、明確な承認ポイント、そして本番前に試すための、自社の仕事の実例です。よくある失敗は、誤ったデータでツールを呼ぶ、同じ処理を繰り返す、仕事に対して権限が広すぎる、そしてお客様のメッセージに紛れた指示にシステムが従ってしまうPrompt Injection（プロンプトインジェクション）です。続きはAI社員についての記事をご覧ください。
エージェンティックAIは多工程・多システムを人の決めた範囲で動かす
エージェンティックAIは、「この注文を受注から入金まで完了させる」といった大きな目標を受け取り、細かく分け、それぞれを得意なエージェントやシステムに渡し、進み具合を追い、範囲を超える件は人に上げるシステムです。
例は部門をまたぐ仕事がほとんどです。受注から入金まで：LINE OAで注文を受けるエージェント、与信枠を確認するエージェント、トラックの配車枠を押さえるエージェント、そしてe-Tax Invoice（タイの電子税務インボイス）を発行する工程。与信枠を超える注文は人の承認待ちになり、各工程は何をどのデータで行ったかを監査ログに残します。
失敗の仕方は下の段と違います。最初のエージェントの誤りが、誰も見ないまま次へ流れます。結果が誤っていても「システムがやった」ことになり、責任者がいません。お客様の個人データも複数のシステムを通ります。どの工程で社外に出るのか、タイの個人情報保護法（PDPA）を満たしているのかを答えられなければなりません。社外に出せない場合は、自社環境で動かすプライベートLLMという選択肢があります。続きはマルチエージェント業務基盤の記事をご覧ください。
| 生成AI | AIエージェント | エージェンティックAI | |
|---|---|---|---|
| 何をするか | 文章・画像・表・コードを作って終わる | ひとつの仕事を受け、システムを呼び、最後まで片づける | 計画し、仕事を分け、複数のエージェントとシステムを束ねる |
| 御社に求めるもの | 明確な指示、正しい文書 | API、最小限の権限、承認ポイント、試すための実例 | 業務フロー図、監査ログ、停止ボタン、結果の責任者 |
| どこで失敗するか | データがないのに自信を持って答える、今日の状態を知らない | 誤った入力でツールを呼ぶ、繰り返す、権限が広すぎる、プロンプトインジェクション | 誤りが連鎖する、コストが膨らむ、誰も結果に責任を持たない |
| タイ企業での例 | LINE OAの返信を下書きし、担当者が送る | ERPから注文状況を答える、請求書を読んで支払いを起票する | 与信確認と配車を通した受注から入金まで |
| 一般的なチャットボットの位置 | 文書から答えるだけならここ | システムを開いて動いた日からエージェント | 大きなシステムの窓口のひとつ |
架空のケース
サムットプラカーン県の建材卸売業者（社名も詳細も架空です）は、小売店からの注文をLINE OAで受けており、一日に数十件のメッセージが届きます。営業チームは一日中同じ質問に答え、注文は手入力です。第一段階として、生成AIにカタログから返信を下書きさせ、担当者が読んで送るようにしました。ただ「在庫はありますか」には、やはり人がシステムを開く必要がありました。モデルは今日の在庫を知らないからです。
第二段階で、開発チームはエージェントを在庫と受注のシステムにつなぎ、在庫の質問に答え、担当者が確定する発注書の下書きを作らせました。最初の失敗は、トラックが満杯だと知らずに納品日を確約したことです。チームは配車枠を確認するツールを追加し、納品日は配車表からしか取らないというルールを置きました。第三段階は、第二段階が安定してからです。与信確認、配車、税務インボイス発行までをシステムが束ね、与信枠を超える注文は営業マネージャーの承認待ちになります。
多くの企業が上る三段のはしご
エージェントを実際に動かしている企業は、だいたい同じ道を通ります。各段には、次へ上がる前に揃えるべき証拠があります。
三段のはしご
- 第1段 正確に答える。 社内文書から答え、人が送ります。証拠：本番前に自社の仕事の実際の質問で試し、何を合格とするかを上長と決めてあること、そして人が直した答えの割合。
- 第2段 取り消せる仕事をひとつ行う。 エージェントが少数のシステムを開き、取り消しや修正ができる仕事をします。証拠：すべてのシステム呼び出しの記録と、人が承認しなかった回数。
- 第3段 複数の仕事を束ねる。 エージェント間で仕事を受け渡し、お金に関わる場所には承認ポイントを置きます。証拠：漏れのない監査ログ、押す訓練を済ませた停止ボタン、結果の責任者の名前。
上がる基準： 人の修正回数が下がり続け、責任者が決まったら次の段へ。基幹システムにまだAPIがなければ、先にデータの置き場所をひとつにします。
自律の度合いをさらに細かく分けた経営者向けの道筋は、チャットボットからAIアプリへのロードマップにあります。
チャットボットで足りるとき、エージェンティックがまだ早いとき
一般的なチャットボットは、チャット画面のついた生成AIです。システムを開いて動いた日からエージェントになります。チャットボットで足りるのは、質問が繰り返しで、答えが自社で維持できる文書にあり、答えた後にシステムで何もしなくてよいときです。答えた後に毎日システムでの作業があり、間違えても直せるなら、AIエージェントに進むときです。
エージェンティックAIがまだ早いのは、正とするデータがまだ散らばっている、基幹システムにAPIがない、業務の責任者がいない、あるいは誤ったときにどう止めるかをまだ答えられないときです。最初の仕事の選び方は、AIをどこから始めるかの記事にまとめています。
発注前に開発会社へ確認する質問
どの会社も「うちのシステムはエージェンティックです」と言います。次の質問で、中身が実際に何かが見えます。スライドより実際の画面で答えてもらってください。
- 提案されたシステムは三段のはしごのどの段にあり、なぜ私たちの仕事にその段が必要なのか
- エージェントはどのシステムを呼べるのか、権限は誰が与えるのか
- どこで人の承認が先に入るのか、それを私たち自身で変えられるのか
- 誤ったとき、すぐに止められるのか、どう取り消すのか
- 後から、何をどのデータで行い、誰が承認したかを確認できるのか
- お客様の個人データはどの工程で社外に出るのか、PDPAをどう満たすのか
- 来年AIモデルを変えるとき、どこを作り直す必要があるのか
開発チーム向け · Tool Calling、オーケストレーション、ガードレール
Tool Calling：関数を要求するのはモデルですが、実行前にシステム側のコードがスキーマ、呼び出し元の権限、冪等性を検証します。読み取りツールと書き込みツールを分け、書き込みツールはすべて設定可能な承認ポリシーを通します。オーケストレーション：ジョブの状態はモデルの外に持ち、完了した取引を二度と繰り返さないタイムアウトと再試行を設定し、ジョブあたりの反復回数に上限を置きます。ガードレール：実行前に入力をフィルタしてプロンプトインジェクションを検査し、実行後に結果を業務ルールと照合し、停止して人を呼ぶ条件を定義します。監査ログには入力、ツール呼び出し、出力、承認者、プロンプトのバージョンを残します。
タイ企業の中で動くエージェントを私たちはこう作る
AIエージェントが守るべきルールは、その仕事を毎日している人の頭の中にあります。DNA Makerはまず、御社の営業・経理・倉庫の担当者と一緒に座り、業務フロー図、判断ポイント、人が承認すべき場所を書き出します。そのうえで、まだエージェントにすべきでない仕事は、そうはっきりお伝えします。
御社と働くのはDNA Maker自身のチームで、外注はしません。毎週デモをご覧いただけます。すでにお使いのLINE OA、Web、アプリの上にエージェントを作り、ERP・CRM・会計ソフトにつなぎ、御社が決めた工程に承認ポイントを置きます。データを社外に出せない場合は、御社の環境でプライベートLLMを動かします。範囲と価格は着手前に確定し、ソースコードは範囲に沿って納品します。500件以上の実績には、銀行、病院、タイの大手企業グループの仕事が含まれます。AIエージェント＆チャットボットのページから、またはチャットページのDreamにご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| 生成AI | 指示から文章・画像・コードを作って終わるAI | お客様への返信を下書きし、担当者が送る | 答えは当社の文書から来ているのか、モデルの一般的な記憶からなのか |
| AIエージェント | ひとつの目標を受け、ツールとデータを使い、仕事を終えるソフトウェア | ERPで注文を確認し、納品日を知らせる | このエージェントはどのシステムに触れられ、誰がそれを許可したのか |
| エージェンティックAI | AIが計画し、仕事を分け、人の決めた範囲で複数のエージェントを束ねるシステム | 与信枠超えは人が承認する、受注から入金までの流れ | 流れ全体の結果に誰が責任を持つのか |
| オーケストレーション | 多くの工程とシステムを束ね、続行・再試行・人への引き渡しを判断する層 | 与信確認から配車へ注文を渡す | 途中の工程が失敗したら、済んだ工程はどう戻すのか |
| 監査ログ | 誰が、または何が、いつ、どのデータで何をしたかの記録 | エージェントがどの配車表から納品日を答えたかをマネージャーが確認できる | 流れ全体を後から追えるか、どのくらいの期間残るのか |