従来の自動化は決められた指示に従い、単純なチャットボットは目の前のメッセージに対して応答するだけです。ゴールベースエージェントの仕組みは異なります。まず望ましい成果を起点に、そこへ到達するために必要な行動を計画します。そしてタスクが進むにつれて新しい情報を評価していきます。この記事では、その概念と、それを支えるアーキテクチャ、主なユースケースについて説明します。また、ゴールベースエージェントを他のAIエージェントの種類と比較し、目標指向のタスク実行を実際に体験できる方法としてKimi Agentを紹介します。
ゴールベースエージェントとは
ゴールベースエージェントとは、定義された目標を軸に判断と行動を行うAIシステムです。現在の状態を評価し、次に取り得るステップを検討したうえで、望ましい結果に近づく行動を選択します。エージェントはツールを使い、進捗を追跡し、新しい情報によって状況が変われば計画を見直すことができます。
例えば、カスタマーサポートのエージェントは一つの質問に答えるだけかもしれません。しかしゴールベースエージェントは、顧客の問題全体を解決する方向で動きます。アカウントの履歴を確認し、承認済みのナレッジベースを参照することもできます。そのうえで問題を診断し、解決策を用意したり、証拠が不十分な場合はケースをエスカレーションしたりします。
ゴールベースエージェントはどのように機能するのか
ゴールベースエージェントは通常、繰り返しのループに従って動作します。まず望ましい成果を定義し、現在の環境を観察します。次に計画を立て、行動を選択し、その結果を評価します。結果がタスクを前進させていない場合、エージェントは計画を立て直したり、助けを求めたりすることができます。
目標の定義
このプロセスは、成功を明確に定義することから始まります。目標には複数の関連条件が含まれる場合がありますが、各条件は検証可能であるべきです。また、期限、承認済みのデータソース、支出上限、必要な承認、禁止される行動といった制約を含めることもできます。言語モデルは曖昧な要求を具体的なサブゴールに変換することができますが、最終的な成功基準はワークフローの担当者にとって見える状態を保つべきです。
環境と状態の認識
エージェントは、ユーザーからの要求、外部システム、ファイル、データベース、API応答、システムイベントなどから現在の状態に関する情報を収集します。ロボットの環境では、センサーが近くの物体や変化する状況についての情報を提供します。状態には、完了したタスク、承認待ちの事項、失敗した前提も記録されるべきです。明確なエラー値と状態値は、エージェントが続行するか、再試行するか、エスカレーションするかを判断する助けになります。
計画立案とタスクの分解
計画モジュールは、目標を実行可能な道筋に変換します。広範な目的をより小さなタスクに分解し、タスク間の依存関係を特定します。従業員のオンボーディングであれば、計画はまず書類の収集と確認から始まり、その後アカウント申請の準備と役割に基づく承認待ちへと進むかもしれません。安定したプロセスでは固定の計画を使えますが、変化するワークフローでは段階的に計画を見直すための判断ポイントが必要になります。
行動の選択と実行
計画を立てた後、エージェントは次に承認された行動を選択します。システムに問い合わせたり、文書を検索したり、レコードを更新したり、不足している情報を人に尋ねたりすることがあります。各行動には明確な入力と期待される結果が定義されているべきです。エージェントはステップを完了とマークする前に結果を検証しなければならず、影響の大きい行動は人による承認を待って一時停止すべきです。
フィードバックと計画の見直し
実行は一方通行のプロセスではありません。エージェントは最新の結果を目標と照らし合わせ、計画が依然として妥当かどうかを確認します。新しい証拠は、現在の道筋を裏付けたり、障害を明らかにしたり、より安全な代替案を生み出したりします。
このループは次のように表せます。
目標は変わらないまま、道筋だけが変わることがあります。倉庫内のロボットは、障害物を検知した後に別の経路を選ぶことができます。リサーチエージェントは、最初の情報源が質問に答えられない場合、別の情報源を検索することができます。ターン数、ツール呼び出し、再試行、時間などに対する実行予算は、無期限の動作を防ぎ、性能を測定しやすくします。
ゴールベースエージェントアーキテクチャの主要コンポーネント
ゴールベースエージェントアーキテクチャは、目標を状態、計画、ツール、監督と結びつけます。実装の詳細は場合によって異なりますが、各コンポーネントには明確な役割があるべきです。
目標と成功基準
目標レイヤーは望ましい状態を定義します。エージェントが何を達成すべきか、何をもって完了とみなすかを説明します。また、実行全体を通じて適用される失敗条件や制約を特定することもできます。
例えば、文書のワークフローでは、レコードを提出する前にすべての必須項目を検証する必要があるかもしれません。ワークフローが完全な検証を求めている場合、不完全なレコードは部分的な成功とはみなされません。明示的な基準は、エージェントが適切なタイミングで停止する助けになります。
ワールドモデルとナレッジベース
ワールドモデルは、エージェントに環境の作業用の表現を与えます。これには、現在のシステム状態、利用可能なリソース、既知の関係性、行動によって起こり得る結果などが含まれる場合があります。ナレッジベースは、エージェントが判断を下す必要があるときに裏付けとなる情報を提供します。
ワールドモデルが有用なのは、エージェントが目標だけから計画を立てることはできないためです。ワークフローが現在どの段階にあるかを理解する必要があります。また、一時的なタスクの文脈と、より長く保持される知識とを区別する必要もあります。検索は、データ集合全体をアクティブなコンテキストに置くのではなく、関連する情報だけを提供すべきです。
きちんと管理された状態記録は、完了したステップ、保留中の依存関係、失敗した試み、承認状況を示すことができます。後で使用するために保存されるものはすべて、アクセス規則とデータの出所によって管理されるべきです。
計画モジュール
計画モジュールは、目標に向かう道筋を作成し、更新します。行動の連続を生成したり、専門のエージェント間で作業を分担したり、次のステップを動的に選んだりすることができます。
優れた計画立案は、依存関係と不確実性を考慮に入れます。すべてのツールが期待どおりの結果を返すとは想定しません。フォールバックの経路、検証ステップ、エスカレーション条件を含めることができます。新たな証拠によって次に取るべき最善の行動が変わり得る間は、計画は暫定的なものであり続けるべきです。
ツールとアクション層
ツールを使うことで、エージェントはモデルの外にあるシステムとやり取りできます。代表的な例として、検索、データベースへの問い合わせ、ファイル処理、ブラウザ操作、業務用API、レコード更新などが挙げられます。
すべてのツールには、明確な契約が必要です。契約では、有効な入力、期待される出力、権限、エラー、副作用を定義すべきです。可能であれば、読み取り操作と書き込み操作は分離します。機微な操作には、より厳格な検証と承認ルールを適用すべきです。
実行、評価、ガードレール
実行層は選択されたアクションを実行します。評価層は、その結果を計画と成功基準に照らして確認します。ガードレールは、エージェントが何をできるか、いつ停止すべきかを定義します。
本番稼働するワークフローでは、判断内容、ツール呼び出し、観測結果、状態の変化を記録すべきです。この記録は、デバッグや人によるレビューに役立ちます。取り消しのきかない操作、外部への連絡、金銭に関する変更、本番環境の更新の前には、承認ゲートが特に重要になります。
ゴールベースエージェントと他の種類のAIエージェントの違い
ゴールベースエージェントは、AIエージェント設計における幅広い分類の一つにすぎません。カテゴリーは重なり合うこともありますが、それぞれ意思決定の方法が異なります。
| エージェントの種類 | 意思決定の方法 | 計画能力 | 適した用途 |
|---|---|---|---|
| 単純反射エージェント | 現在の入力に反応する | ほとんど、または全くない | 固定ルールと即時反応 |
| モデルベース反射エージェント | 内部状態モデルを用いる | 限定的 | 基本的な記憶を必要とする環境 |
| ゴールベースエージェント | 定義された目標に向かう行動を選択する | あり | 経路は変化するが目標が明確な場合 |
| 効用ベースエージェント | 最も価値の高い結果を選ぶ | 高度なトレードオフ分析 | 複数の相反する目標 |
| 学習エージェント | 経験やフィードバックから改善する | 時間とともに進化しうる | 適応によって効果が高まるタスク |
リアクティブエージェントは、今見えているものに反応します。一方ゴールベースエージェントは、あるアクションが将来の状態にどう影響するかを考慮します。この先を見据えた振る舞いにより、目的は一定でも経路が定まっていない場合には、ゴールベースのシステムのほうが適しています。
効用ベースエージェントは、これとは異なる意思決定の問題を解きます。起こりうる結果を比較し、それぞれに価値を割り当てます。例えば、カスタマーサービスシステムでは、対応を選ぶ際に解決速度、返金コスト、顧客満足度のバランスを取ることがあります。ゴールベースエージェントは通常、目標とする条件が達成されたかどうかに焦点を当てます。ワークフローが必要とする場合、ゴールベースのシステムに学習要素や効用ベースの要素を組み込むこともできます。
ゴールベースエージェントとタスクベースエージェントの違い
タスクベースエージェントとゴールベースエージェントは、どちらも有用な作業を自動化できます。両者の違いは、システムが指示を受け取り、成功を測定するレベルにあります。
| 評価軸 | タスクベースエージェント | ゴールベースエージェント |
|---|---|---|
| 起点 | 特定の指示 | 望ましい結果 |
| 範囲 | 定義された1つのタスク | 連携するワークフロー |
| 次のアクション | 通常はユーザーまたはワークフローによって指定される | エージェントが選択する |
| 成功の基準 | タスクの完了 | ゴールの達成 |
| 適応性 | 多くの場合限定的 | 条件が変化した場合に再計画できる |
| 人による入力 | 各ステップで必要になる場合がある | 通常は境界や例外時に必要 |
タスクベースエージェントは、実行すべきアクションがすでにわかっている場合に有効です。ゴールベースエージェントは、達成すべき結果は明確でも、その道筋が変わり得る場合に有効です。タスクベースのシステムは、文書からフィールドを抽出できます。ゴールベースのシステムは、その抽出結果を、情報を検証し例外を振り分けるより大きなプロセスの一ステップとして利用できます。
この違いは、ワークフローに対する責任の範囲に関するものであり、エージェントの数ではありません。単一のエージェントが広範なゴールを追求することもあれば、複数のエージェントが、より大きな計画を共有せずにそれぞれ別々のタスクを実行することもあります。
ゴールベースエージェントのユースケース
ゴールベースエージェントは、到達すべき地点は明確でありながら、タスクが終わるまでの間に状況が変化しうる環境に適しています。
ロボティクスと倉庫の自動化
倉庫内のロボットは、荷物を出荷エリアへ移動させるというゴールを与えられることがあります。荷物を特定し、経路を計画し、障害物を避け、自身の位置を監視しなければなりません。他のロボットが計画していた経路をふさいだ場合、エージェントは代替経路を評価できます。
ゴール自体は変わりません。アクションの手順は、環境に応じて変化します。この点で、ロボティクスは、直近の障害物に反応するだけでなく、将来の状態に向けて計画を立てる好例といえます。
カスタマーサポートと問題解決
サポート業務のワークフローでは、正確で承認済みの回答によって顧客の問題を解決することを、成功として定義する場合があります。エージェントは会話内容を読み取り、アカウント情報を取得し、ナレッジベースを参照したうえで、問題をエスカレーションすべきかどうかを判断できます。
システムは、返信の下書きを作成しただけで成功と見なすべきではありません。その回答が問題に対応しているか、必要なアクションが完了しているかを確認すべきです。機微な変更については、人による承認ステップを経る必要があります。
従業員のオンボーディング
従業員のオンボーディングには、役職、勤務地、入社日、承認状況によって関連し合う複数のタスクが伴います。ゴールベースエージェントは、個々の依頼を独立したアクションとして扱うのではなく、より大きな成果を追跡できます。
書類を収集し、情報を検証し、アカウント発行の申請を準備し、上長の承認を待つといった処理を行う場合があります。必須項目が不足している場合、エージェントは処理を一時停止するか、不足している情報を求めることができます。計画を先に進めるために、権限ルールを回避すべきではありません。
リサーチとコンテンツ制作のワークフロー
リサーチ業務のワークフローは、信頼できる根拠に基づいた構造化レポートを作成するというゴールから始まる場合があります。エージェントは、問いをサブトピックに分割し、承認済みの情報源を検索し、調査結果を整理し、不足している点を特定できます。
情報源がある主張を裏付けていない場合、エージェントは調査計画を見直すことができます。レビューのステップでは、最終レポートが当初の問いに答えているかどうかを確認できます。レポートが重要な意思決定の材料となる場合、人によるレビューは依然として重要です。
インシデント対応とオペレーション
インシデント対応エージェントは、サービス障害の原因を特定する作業に取り組む場合があります。ログを調査し、直近のデプロイを確認し、依存関係をチェックし、システム間で証拠を突き合わせることができます。
新しいシグナルが現れれば、ワークフローは変化することがあります。エージェントはロールバックや設定変更を推奨する場合がありますが、本番環境に影響を与える操作には承認が必要です。ゴールベースのループは、調査を整理する助けにはなりますが、推奨がそのまま制御されない実行に変わることはありません。
ゴールベースエージェントのメリット
複数ステップの作業をより適切に処理できる
ゴールベースエージェントは、最終結果を軸に関連する複数の操作をまとめて整理できます。ワークフローの境界が明確であれば、低リスクなステップをすべて指示する必要はありません。
ルールベースの自動化より柔軟
固定ルールは安定した条件下ではうまく機能します。ゴールベースのシステムは、入力が変化したり想定していた操作が失敗したりした場合に、別の承認済みの経路を選択できます。
成功基準がより明確
明確なゴールを定めることで、評価の意味がより明確になります。応答の長さや流暢さで成功を測るのではなく、意図した結果に到達したかどうかをシステムが確認できます。
ワークフローの継続性が向上
エージェントはタスクの状態を保持し、何が未完了かを把握できます。これは、承認を待ってワークフローが一時停止したり、別のシステムからの情報を待ったりする場合に重要です。
人への権限委譲がより有効に機能する
人は結果、制約、承認ポイントを設定できます。エージェントはその運用範囲内で日常的な判断を管理し、例外や影響の大きい判断は人が担当します。
信頼できるゴールベースエージェントの設計方法
信頼できる設計は、モデルではなくワークフローから始まります。タスクを安全に完了できる最小のアーキテクチャを使用してください。
測定可能なゴールを1つ定義する： 評価者が検証できる完了条件を書き出します。
成功条件と失敗条件を設定する： エージェントが続行すべきか、停止すべきか、エスカレーションすべきかを説明します。
ゴールをサブタスクに分解する： 各サブタスクに明確な出力と依存関係を持たせます。
ツールへのアクセスを制限する： 現在の役割に必要なツールのみを提供します。
読み取り権限と書き込み権限を分ける： 情報の取得と状態を変更する操作を区別して扱います。
承認ゲートを追加する： 機密性の高い操作や取り消せない操作の前には確認を必須にします。
実行内容を記録する： 計画、ツール呼び出し、結果、状態変化を記録します。
実行の上限を設定する： 時間、ターン数、再試行回数、コストの上限を設けます。
ワークフロー全体をテストする： 個々のモデル応答だけでなく、結果を評価します。
段階的に拡張する： まずは単一のエージェントから始め、実際の必要性が確認できてから連携を追加します。
実践的なルールは単純です。ワークフローを確実に完了できる、最も複雑度の低いアーキテクチャを使うことです。より高い自律性が役立つのは、それが特定の運用上の課題を解決する場合に限られます。
今すぐ使えるゴールベースエージェント、Kimi Agentのご紹介
このガイドで説明した計画ループは、単なる理論ではありません。これはKimi Agentが実際のタスクを実行する仕組みそのものです。結果を一文で伝えるだけで、Kimiはそれをサブタスクに分解し、組み込みのツールを使って各ステップを実行します。そして最終的な出力を提供する前に、結果を評価します。オーケストレーション層を構築する必要も、ワークフロー用のコードを維持する必要もありません。
ゴールを伝えるだけで、成果物が得られる
Kimi Agentは、ゴールベースエージェントのあるべき姿で動作します。手順ではなく目標を与えるだけです。経路は自ら計画し、そのまま使える成果物を生み出します。
引用元付きの調査レポートを、Kimi Deep Researchで作成
簡単な要件から作られた、実際に動作する複数ページのウェブサイト
そのまま編集できるPPTプレゼンテーション、ドキュメント、またはスプレッドシート
元となる資料として一度に最大50件のファイルをアップロードできるため、既存のPDF、スライド、画像もすべてタスクのコンテキストに組み込まれます。
長時間のタスクも自力で完了する
ゴールベースのエージェントは、複数のステップを要する作業でこそ真価を発揮します。Kimi 徹底的な調査は通常1タスクにつき10〜25分ほど実行され、バックグラウンドで処理を続けるため、ページを離れても戻ってきたときには完成したレポートが用意されています。エージェントは、毎ステップで指示を待つのではなく、自ら進捗を管理します。
1つのゴールを数百の並列タスクへと拡張する
1つのエージェントでは規模に対応しきれない場合、Kimi Agent Swarmがゴールを100を超えるサブエージェントに分割し、最大1,500件の並列ツール呼び出しをサポートします。大規模な検索、長文の執筆、バッチ処理向けに設計されており、同じゴールベースのループを何倍にも増幅させたものです。
境界線を決めるのは、あなたのまま
ゴールベースの設計では、成果に対する主導権は人が握り続けます。Kimiも同じ考え方で動きます。ゴールと制約を定めるのはあなたであり、その後に計画と成果物を確認します。重要な事実や影響の大きい判断は、常に人によるレビューの対象です。自律性が担うのは経路の選択であり、判断はあなたに委ねられています。
限界と課題
ゴールベースのエージェントは固定的な自動化よりも柔軟性が高い一方で、新たな失敗のパターンも生み出します。目標が曖昧だと、エージェントが誤った結果に向かってしまうことがあり、選択肢の多い状況では計画立案のコストが大きくなります。環境が変化すれば、計画そのものが古くなってしまうこともあります。優先事項が競合する場合には、単純な完了判定ではなく、効用に基づく推論や人による判断が必要になることもあります。ツールの失敗や古いデータはさらなるリスクを生み、特にエージェントが外部システムを変更できる場合は注意が必要です。したがって、信頼性の高い運用のためには、検証済みのツール結果、計画の再作成に対する制御、権限の制限、可視化されたログ、そして影響の大きい操作に対する人による承認が欠かせません。
まとめ
ゴールベースのエージェントは、直近の入力にただ応答するのではなく、定めた成果に向けて動きます。計画と行動を結びつけるループを用い、観測された結果を評価してから次の一手を選びます。このアプローチは、目的地は明確でも経路が変わり得るワークフローに適しています。まずは明確な成功基準と限定的な権限から始め、必要になった時点で複雑さを追加していきましょう。Kimi Agentは、ゼロからエージェントアーキテクチャを構築することなく、ゴール志向のタスク実行を試すための実践的な手段です。