Oracle APEXのAIエージェントによるインサイトからアクションへの移行 (2026/05/14)
Oracle APEXのAIエージェントによるインサイトからアクションへの移行 (2026/05/14)
https://blogs.oracle.com/apex/ai-agents-in-oracle-apex
投稿者：Chaitanya Koratamaddi | Director of Product Management / Strategy, Oracle APEX | Database Tools
Oracle APEXは、データ中心でワークフロー主導型のエンタープライズアプリケーションを簡単に構築できるツールとして長年親しまれてきました。AIエージェントの導入により、APEXはさらに大きな進化を遂げます。開発者は、ユーザーが自然言語で質問できるだけでなく、アプリケーションがコンテキストに基づいて推論し、ビジネスデータを取得し、ツールを通じてアクションを実行できるアプリケーションを構築できるようになります。
これは、基本的なチャットベースのAI体験からの大きな進化です。生成型AIをテキスト生成や静的な質問応答に限定するのではなく、APEXのAIエージェントは、アシスタントが実際のアプリケーションワークフローに直接参加できる、よりリッチなインタラクションモデルを実現します。
この記事では、AIエージェントとは何か、エージェント型AI、関数呼び出し、エージェントループといった基本的な概念がどのように連携するのか、そしてOracle APEXがこれらの機能を日常的に開発する開発者にとってどのように実用的なものにするのかを探ります。全体を通して、営業担当者が「 次に何をすべきですか？」と尋ねるという具体的なCRMシナリオを使用します。
AIアシスタントからAIエージェントへ
従来のAIアシスタントは、主にプロンプトへの応答を目的として設計されています。コンテンツの要約、テキストの書き換え、入力内容の分類、あるいは既に利用可能な情報に基づいた質問への回答などが可能です。これは便利な機能ですが、同時に限界もあります。
AIエージェントはさらに先へ進む。
エージェントは単に質問に答えるのではなく、目標達成に向けて業務に取り組みます。典型的なエージェントのワークフローは次のようになります。
- ユーザーの意図を理解する
- 必要な情報を決定する
- アプリケーションからコンテキストを取得する
- 1つ以上のアクションを実行する
- 結果を観察する
- 有益な結果が得られるまで続ける
このより広範なパターンは、しばしば エージェント型AIと表現される。
実際には、エージェント型AIは、アプリケーションが次の段階に進むことを可能にするものです。
以下にいくつかの情報を示します。
に：
現状、阻害要因、そして次に取るべき行動について説明します。
企業向けアプリケーションにおいては、その違いがすべてを左右する。ユーザーが求めているのは単なる答えではなく、タスクの進捗状況であることが多い。
AIシステムを「エージェント型」にする要素とは何か？
エージェントシステムは、3つの主要な機能を組み合わせたものである。
1. ユーザーの意図に関する推論
AIモデルはリクエストを解釈し、リクエストが曖昧であったり、抽象的な内容であっても、ユーザーが実際に何を達成しようとしているのかを判断します。
2. 外部機能へのアクセス
このモデルは、アプリケーション定義の関数やツールを呼び出して、ユーザーに代わってデータを取得したり、アクションを実行したりすることができます。
3. 反復実行
このシステムはループ処理で動作できます。コンテキストを要求し、ツールを呼び出し、結果を検査し、タスクが完了するまでこれを繰り返します。
ここから、現代のAIアプリケーション設計が面白くなってきます。モデルはもはや独立したテキストエンジンとして扱われるのではなく、アプリケーションロジックの上に構築されるオーケストレーターとなるのです。
Function calling：AIエージェントの基礎
AIエージェントの基本的な構成要素は Function callingであり、これはツールとも呼ばれます 。
大規模な言語モデルは、アプリケーションデータ、顧客記録、承認ルール、ビジネスプロセスなどをネイティブに認識するわけではありません。これらの情報とやり取りするための、安全で構造化されたメカニズムが必要です。関数呼び出しはまさにそれを提供します。
Oracle APEXでは、この機能を ツールを通じて提供しています。開発者はAIエージェントの下にツールを定義でき、それらのツールはサーバー側またはクライアント側で実行できます。また、モデルが必要と判断したときにオンデマンドで実行するように構成したり、ユーザーがプロンプトを送信するたびに新しいコンテキストを挿入してシステムプロンプトを事前に拡張するように構成することもできます。
設計の重要な原則は、 モデルがテーブルを直接クエリしたり、任意のコードを実行したりしないことです。代わりに、宣言的に公開される厳選された機能リストに基づいて動作します。これにより、開発者はモデルが実行できる操作を正確に制御できると同時に、統合が自然で拡張しやすい状態を維持できます。
Oracle APEXのエージェントループ
ツールが定義されると、やり取りは単一の要求と応答の交換ではなく、ループ状になる。
仕組みは以下のとおりです。
- ユーザーがメッセージを送信します。
- APEXには、会話のコンテキスト、システムプロンプト、および利用可能なツールが含まれます。
- モデルは、直接回答できるかどうか、あるいは1つ以上のツールを呼び出す必要があるかどうかを判断します。
- APEXはそれらのツールを実行します。
- ツールの結果は会話に反映されます。
- モデルは、さらにツール呼び出しを行うか、最終的な応答を生成することによって、処理を継続します。
そのループこそが、この機能を単なる会話型ではなく、主体性のあるものにしているのだ。
Oracle APEXにおけるAIエージェント
Oracle APEXは、開発者が既に使い慣れている宣言型アプローチでAIエージェントをプラットフォームに統合します。AIエージェントを共有コンポーネントとして作成し、AIアシスタントのチャットエクスペリエンスにアタッチし、ツールを定義し、パラメータを設定するだけで、エージェントの準備は完了です。ビジネスロジックはPL/SQLで記述され、データはOracle Databaseに格納されます。ツールは、それぞれの本来の場所で実行されます。サーバー側のコードはデータベースで、クライアント側のコードはブラウザで実行されます。
つまり、開発者はAPEXビルダーから離れることなく、アイデアから動作するエージェントまで作成できるということです。
- ツールを宣言的に定義する — SQLクエリ、PL/SQLブロック、JavaScriptスニペット
- 実行ポイントの設定 — コンテキスト表示にはシステムプロンプトを拡張し、アクション実行にはオンデマンドで設定する
- パラメータを型と検証で設定します — APEX は JSON スキーマを処理します
- エージェントをAIアシスタントコンポーネントにアタッチします。
注： 以前のリリースにおけるAI構成は、AIエージェントと呼ばれるようになりました。既存の構成は自動的に引き継がれます。名称変更は、ツールや複数ステップのオーケストレーションなど、機能が拡張されたことを反映したものです。
ツールモデルの理解
APEXにおけるAIエージェントについて考える上で役立つのは、それらが2種類の機能を組み合わせたものであるという考え方です。
拡張システムプロンプト
Augment System Promptツールは、新しいメッセージごとに実行されます。その結果は、システムメッセージとして会話履歴に挿入されます。これらのツールを使用すると、現在のユーザー名や現在の日時などのコンテキスト情報を含めることができます。RAG（Retrieval-Augmented Generation：検索拡張生成）は、現在のユーザープロンプトまたはチャット履歴全体をプログラムで分析し、必要に応じてデータを含めることで実現できます。
注： 以前のリリースでRAGソースを使用していた場合、それらは自動的にAugment System Promptツールに移行されます。動作は同じです。既存のRAG統合は引き続き機能し、統合されたツールモデルの一部として動作します。
オンデマンド
オンデマンドツールは、AIサービスが応答生成中に呼び出した場合にのみ実行されます。これらのツールはパラメータを持つことができ、AIサービスにデータを返したり、単にタスクを実行したりできます。AIサービスは必要なときにのみデータを要求するため、RAG（検索拡張型生成）はより自然に実現されます。
APEXには、以下の組み込みツールタイプが用意されています。
- データの取得
- サーバーサイドコードを実行する
- クライアント側コードを実行する
「サーバー側コードの実行」と「クライアント側コードの実行」は、ほとんどのタスクを実行できる汎用ツールですが、「共有コンポーネント」の下に、カスタムで再利用可能な生成型AIツールプラグインを作成することもできます。これらのプラグインは、組み込みオプションと並んでツールタイプのリストに表示されるため、エージェントやアプリケーション間でツールの実装を簡単に標準化して共有できます。
この組み合わせが強力なのは、最も一般的な企業パターンを網羅しているからです。
- コンテキストに応じたビジネスデータを取得する
- アプリケーションロジックを実行する
- 必要に応じてブラウザと対話する
ツールの種類の詳細
それぞれのツールタイプと、それがどのような用途向けに設計されているのかを見ていきましょう。
データの取得
モデルに対するSQLクエリの結果を返します。これは最も一般的なツールタイプで、エージェントがスコープ付きの読み取り専用クエリを通じてアプリケーションデータにアクセスできるようにします。
拡張システムプロンプトツールとして 、データ取得ツールは、メッセージごとに現在のユーザーのプロファイルを返す可能性があります。
select u.username,
u.email,
r.description as role
from app_users u
join app_roles r on r.role_id = u.role_id
where u.user_id = :APP_USERオンデマンドツールとして 、モデルが必要と判断したときに検索結果を返す場合があります。ここでは、モデルが SEARCH_TERM パラメーターを渡し、APEX がバインドする前にそれを検証します。
select product_id,
product_name,
category,
list_price,
in_stock_flag
from products
where lower(product_name) like ‘%’ || lower(:SEARCH_TERM) || ‘%’
order by list_price
fetch first 20 rows onlyパラメータは SEARCH_TERM ツールインスタンス内で宣言的に定義されます。APEXはそれらをJSONスキーマにコンパイルし、ツール定義の一部としてモデルに送信し、クエリにバインドする前に返された値を検証します。開発者はパラメータ処理コードを記述する必要はありません。
サーバーサイドコードを実行する
データベース内でPL/SQLブロックを実行します。エージェントがデータを読み取るだけでなく、レコードの作成、ステータスの更新、通知の送信など、何らかのアクションを実行する必要がある場合に使用します。
例えば、ITヘルプデスク担当者はサポートチケットをエスカレーションする場合があります。
begin
support_pkg.escalate_ticket(
p_ticket_id => :TICKET_ID,
p_reason => :REASON,
p_user_id => :APP_USER
);
apex_ai.set_tool_result(
p_result => ‘Ticket ‘ || :TICKET_ID || ‘ escalated.’,
p_notification_message => ‘Ticket escalated’,
p_notification_type => ‘success’
);
end;ビジネスロジックはPL/SQLパッケージ内に記述されています。ツールはプロシージャを呼び出し、確認応答を返します。 apex_ai.set_tool_result デフォルトのツール応答を上書きし、チャットウィジェットでユーザーに通知を表示します。
クライアント側コードを実行する
ユーザーのブラウザでJavaScriptを実行します。ブラウザの状態読み取り、確認ダイアログの表示、UIアクションのトリガーなど、クライアント側のみが持つ機能を実行する場合に使用します。
Augment System Promptツールとして 、クライアント側のコードスニペットは、メッセージごとにユーザーのタイムゾーンを取得する可能性があります。
return Intl.DateTimeFormat().resolvedOptions().timeZone;戻り値（例えば、 America/Chicago ）は、モデルのコンテキストに自動的に追加されます。その後、モデルが何かをスケジュールする必要があるサーバーサイドツールを呼び出す際、ユーザーのタイムゾーンは既に取得されているため、ユーザーに尋ねる必要はありません。
オンデマンドツールとして 、クライアント側のコードは、モデルが必要とするあらゆるブラウザ側の操作（領域の表示/非表示、ダイアログの表示、ユーザー入力の要求など）を実行できます。たとえば、機密性の高い操作の前に確認ダイアログを表示する場合などです。
return new Promise( resolve => {
apex.message.confirm( this.data.MESSAGE, okPressed => {
resolve( okPressed ? "confirmed" : "denied" );
} )
} );
これは重要なパターン、つまりエージェントのワークフロー内に人間のチェックポイントを設けるというパターンを導入するものです。モデルは自律的に推論、データ取得、アクションの準備を行うことができますが、アクションが境界を越える場合（同僚への通知、メール送信、共有レコードの更新など）、アプリケーションは続行する前に明示的なユーザーの同意を求めることができます。
すべてをまとめると
3種類のツールすべて、2つの実行ポイント、および分析からユーザー確認、アクションまで、単一の会話内での完全なシナリオで連携して動作するエージェントループ全体を確認するには、関連投稿「 Oracle APEXを使用したCRM AIエージェントの構築」をお読みください。
APEX開発者にとってこれが重要な理由
APEX開発者にとって特に魅力的なのは、プラットフォームの強みを直接活用している点です。APEXアプリケーションは既に以下の機能を一元化しています。
- Oracle Database内のビジネスデータ
- PL/SQLのルール
- 宣言型コンポーネントとJavaScriptにおけるUIの動作
- アプリケーションレベルの認証スキームと条件におけるセキュリティ
AIエージェントは、開発者が既存のアセットをAIモデルに公開するための構造化された方法を提供します。データモデルを再設計したり、ビジネスロジックを移動したりする必要はありません。既存のシステムの上に、AIネイティブなワークフローを段階的に導入できます。
そして、それこそがOracle APEXにおけるAIエージェントの真の可能性なのです。単に話すAIではなく、ユーザーの業務遂行を支援するAIなのです。
RAGからツールへの自然な流れ
APEXのブログ記事「AIエージェントとRAGソース」では、開発者が共有構成、サーバー側の条件、および取得ロジックを使用して、ビジネス固有のコンテキストでAIとのやり取りを強化する方法について説明しました。このモデルは、応答をデータに基づいて構築する上で非常に優れています。
AIエージェントはその基盤をさらに発展させる。
単に尋ねるのではなく、
「モデルはどのような情報を見るべきでしょうか？」
これからは次のような質問をすることができます。
「モデルにはどのような機能が必要でしょうか？」
それは、検索機能を強化したチャットから、アクションを実行できるアプリケーションエージェントへの飛躍を意味する。
まとめ
Oracle APEXのAIエージェントは、エンタープライズアプリケーション開発に強力な新機能をもたらします。開発者はAIエージェントを使用して、アプリケーションが次のような対話型エクスペリエンスを構築できます。
- ユーザーの意図を理解する
- コンテキストを動的に取得する
- ツールを安全に呼び出す
- ビジネスロジックを実行する
- タスクが解決するまで反復処理を続ける
それが、アプリケーションプラットフォームにおけるエージェント型AIの本質です。
CRMの例は、これがなぜ重要なのかをよく示しています。実際のビジネスワークフローにおいて、ユーザーが求めているのは、生成されたテキストの段落などではありません。ユーザーが求めているのは、作業を進めるためのサポートです。アプリケーションが、何が重要で、何が障害になっているのか、そして次に何をすべきかを教えてくれることを期待しているのです。
Oracle APEXのAIエージェントを使用すると、これはカスタム統合ではなく、ネイティブな設計パターンになります。
コメント
コメントを投稿