※本記事は、Stan Tanev による”Long-Term Audit and Operational Insight for Human in the Loop“を翻訳したものです。
原文公開日: 2026年9月15日
※Oracle Integration 3 September 2026 (26.10)のリリース情報は以下の製品ドキュメントをご確認ください。
https://docs.oracle.com/en/cloud/paas/application-integration/whats-new/release-26_10-september-2026.html
承認は、自動化と説明責任が交わるところです。購買オーダーが承認待ちになった場合、経費が否認された場合、またはAIエージェントが実行前に人の判断を仰ぐために一時停止した場合、いずれ誰かが「誰がこれを承認したのか、いつ、そしてなぜ承認したのか」と尋ねることになります。その確認が1週間後に必要になることもあれば、18か月後に監査人から尋ねられることもあります。
26.10では、Oracle IntegrationのHuman in the Loop（HITL）がアクティビティ・ストリームをOCI Log Analyticsに公開できるようになりました。すべてのワークフローおよびタスクの状態変更が構造化されたログ・レコードとして記録され、コンプライアンス・ポリシーで必要とされる期間だけ保持できます。また、Log Analyticsの問合せ言語を使用してログを検索し、事前構築済みのOracle Integration: HITLダッシュボードで監視できます。
この記事では、この機能が重要な理由、設定方法、ログの検索方法、事前構築済みのダッシュボードで確認できる内容について詳しく説明します。26.10全体の概要を確認するには、まずNiallのWhat’s New in Oracle Integration 26.10の新機能（※日本オラクル追記：日本語翻訳版はこちらの記事）をご覧ください。
なぜ重要なのか
1. 監査とコンプライアンスのための長期保持
HITLのランタイム・データはOracle Integration内に保存され、インスタンスのデータ保持設定に従います。デフォルトの保持期間は、StandardおよびEnterpriseエディションのインスタンスでは32日、Healthcareエディションでは184日です。保持期間を延長できるのはEnterpriseエディションのみで、最大6か月まで設定できます。保持期間のカウントは、ワークフローが終了状態に達した時点から開始されます。アクティブなワークフローはパージされませんが、インスタンスがCompleted（完了）、Faulted（フォルト）、Expired（期限切れ）、またはTerminated（終了）のいずれかになると、保持期間の経過後にそのインスタンスとすべてのタスク履歴が削除されます。
日常的な運用には、それで十分です。しかし、監査証跡としては通常、それでは十分ではありません。財務上の承認、人事上の意思決定、規制対象のプロセスでは、ワークフロー自体がパージされた後も、何年にもわたってその経緯を再現できることが求められます。
Log Analyticsは、そのギャップを埋めます。公開を有効にすると、各HITLイベントは、お客様のテナンシ内にあるログ・グループに送信され、保持期間もお客様が設定できます。データはワークフロー・インスタンスが削除された後も保持され、サイロ化されることなく、他のOCI可観測性データとともに管理できます。
2. 承認業務の実態を把握
データ保持はコンプライアンスの観点で重要です。さらに興味深いのは、運用面で得られるインサイトです。すべての状態変更には、ワークフロー、タスク、担当者、承認者、結果、所要時間、期日、優先度など、豊富な情報が記録されるため、次のような問いに答えられるようになります。
- 現在、未完了のタスクはいくつあり、誰が担当していますか?
- どのワークフローが最も多くの承認タスクを発生させていますか?
- ワークフローごとに、タスクの作成から完了までに平均どのくらいの時間がかかっていますか?
- 承認者はどの程度の割合で承認／否認しており、どのようなコメントを残していますか?
- どのインスタンスがフォルトまたは期限切れになり、それはどこで発生しましたか?
これらは、運用チームやビジネス・プロセスのオーナーが知りたい情報です。26.10では、問合せを1つも記述することなく、これらの多くを確認できるダッシュボードが標準で提供されます。
ログに記録される内容
ワークフローとそのコンポーネントの状態が変更されるたびに、アクティビティ・ストリーム・レコードが生成されます。
| コンポーネント | 記録される状態変更 |
|---|---|
| Workflow | Created（作成済み）、Completed（完了）、Faulted（フォルト）、Expired（期限切れ） |
| Start Event | Created（作成済み）、Completed（完了） |
| Task | Created（作成済み）、Unassigned（未割当て）、Assigned（割当て済み）、Withdrawn（取下げ済み）、Completed（完了） |
| End Event | Created（作成済み）、Completed（完了） |
| If Else | Created（作成済み）、Completed（完了） |
各レコードはJSONとして公開され、事前定義済みのLog Analyticsパーサーによって各フィールドに解析されます。たとえば、1つの購買オーダーの承認が作成され、グループに割り当てられ、承認者がそのタスクを引き受け、「Approve（承認）」という結果で完了すると、タイムスタンプ付きの一連のレコードが生成されます。これにより、その承認プロセスの完全な履歴を、必要な期間だけ保持できます。
設定
HITLログの公開は、OCIコンソールからOracle Integrationインスタンスごとに有効化します。この機能は、Oracle Integrationのアクティビティ・ストリーム・ログをLog Analyticsに公開する既存の機能を前提としており、まずそちらを有効にする必要があります。HITLには、専用のトグルと専用のログ・グループが用意されています。完全な手順は、Provisioning and Administering Oracle Integration 3のPublish Human in the Loop Logs to Oracle Log Analyticsに記載されています。大まかな手順は次のとおりです。
ステップ1 — Log Analyticsでログ・グループの作成
OCIコンソールで、オブザーバビリティおよび管理 → ログ・アナリティクス → 管理 → ログ・グループに移動し、ログ・グループの作成をクリックします。HITLログの保存先となるコンパートメントを選択し、ログ・グループの名前と説明を入力して、作成をクリックします。Oracle Integrationのアクティビティ・ストリーム・ログに使用しているログ・グループとは別のログ・グループを使用します。HITLレコードは形式が異なり、専用のパーサーを使用するため、ログ・グループを分けておくことで、どちらのログもより簡単に問合せできます。
作成したら、ログ・グループを開き、そのOCIDをコピーします。ステップ3で必要になります。
ステップ2 — Oracle Integrationにログをアップロードする権限を付与
Oracle Integrationは、リソース・プリンシパルとしてLog Analyticsに認証するため、Oracle Integrationインスタンスを識別する動的グループと、その動的グループにログのアップロードを許可するポリシーが必要です。
Human in the LoopのOCIDを確認します。OCIコンソールで、開発者サービス →アプリケーション統合 → 統合に移動し、Oracle Integrationインスタンスを開きます。インスタンスの詳細ページで、Human in the Loopセクションまでスクロールし、OCIDをコピーします。ここにはアイデンティティ・アプリケーションの値も表示されますが、このステップで必要なのはその値ではありません。
動的グループを作成（または編集）します。アイデンティティとセキュリティ → ドメインに移動し、Oracle Integrationインスタンスが属するアイデンティティ・ドメインを開きます。動的グループタブを選択して動的グループの作成をクリックし、名前と説明を指定して、HITL OCIDに一致する照合ルールを追加します。
ALL {resource.id = ‘<HITL_OCID>’}動的グループを初めて使用する場合は、OCIドキュメントの動的グループの管理で、詳しい手順とルール構文を確認できます。
動的グループがログ・グループにログをアップロードできるようにするポリシーを作成します。アイデンティティとセキュリティ → ポリシーに移動し、ポリシーの作成をクリックします。名前と説明を入力してコンパートメントを選択し、手動エディタに切り替えて次の3つのステートメントを追加します。ここで、<dynamic_group>は先ほど作成した動的グループ、<log_group_compartment>はステップ1で作成したログ・グループが存在するコンパートメントです。動的グループがデフォルト以外のアイデンティティ・ドメインにある場合は、'<domain>’/'<dynamic_group>’の形式で参照します。
allow dynamic-group <dynamic_group> to {LOG_ANALYTICS_LOG_GROUP_UPLOAD_LOGS} in compartment <log_group_compartment>
allow dynamic-group <dynamic_group> to {LOG_ANALYTICS_SOURCE_READ} in tenancy
allow dynamic-group <dynamic_group> to use loganalytics-ondemand-upload in tenancy各ステートメントのスコープは、意図的に異なっています。1つ目のステートメントは、ログ・グループが存在するコンパートメントを対象としており、コンパートメント単位で指定する必要があるのはこの権限だけです。残りの2つのステートメントは、対象となるリソース自体がテナンシ・レベルのため、テナンシ・レベルで指定します。事前構築済みのHITLログ・ソースは特定のコンパートメントには属しておらず、オンデマンド・アップロード・エンドポイントはサービス全体で使用されるリソースです。
一般的な手順については、OCIドキュメントのポリシーの管理を参照してください。
ステップ3 — Oracle Integrationインスタンスでの公開の有効化
OCIコンソールでOracle Integrationインスタンスを開き（開発者サービス → アプリケーション統合 → 統合 → 対象のインスタンス）、設定パネルまでスクロールします。
ここには1つ前提条件があります。HITLの公開を有効にするには、まずOracle Integration自体のLog Analyticsへの公開を有効にしておく必要があります。 設定のOCI Log Analytics行にNot enabled（有効化されていません）と表示されている場合は、Enable（有効化）をクリックし、まずIntegrationのアクティビティ・ストリーム・ログ用のログ・グループを指定します。
この設定が完了したら、OCI Log Analyticsセクションまでスクロールし、Human in the Loop行のEnableをクリックして、ステップ1で取得したHITLログ・グループのOCIDを貼り付けます。設定が完了すると、パネルには両方の公開設定が有効として表示され、それぞれに個別のログ・グループが設定されます。
これで設定は完了です。この時点以降、そのインスタンスで発生するすべてのHITLの状態変更がログ・グループに送信されます。なお、後で公開を無効にしてから再度有効にする場合は、ログ・グループのOCIDを再度入力する必要があります。
ログ・エクスプローラでのログの確認
レコードが届き始めたら、オブサーバビリティおよび管理 → ログ・アナリティクス → ログ・エクスプローラに移動します。デフォルトの問合せでは、レコードがログ・ソースごとにグループ化されます。そのため、Oracle Integrationのアクティビティ・ストリーム・ログも公開している場合は、2つのエントリが並んで表示されます。HITLのログ・ソースは、OCI Integration – HITL Activity Stream Logsです。
ログ・ソースを右クリックしてDrill downを選択すると、個々のレコードが表示され、その上部には時間の経過に伴うログ件数のヒストグラムが表示されます。各レコードは、元のJSON形式で表示されます。
任意のレコードで詳細…をクリックすると、完全なJSONがダイアログで表示されます。次は、担当者によって引き受けられ、その後REJECTという結果で完了したユーザー・タスクの例です。こうしたレコードは、1年後でも検索して確認できるようにしておきたいものです。
レコードの下にあるLog Sourceを展開すると、これらのJSON属性がLog Analyticsの各フィールドにどのように解析されているかを確認できます。
設定不要：ソースとパーサーはOracle定義
これまでに他のログをLog Analyticsに取り込んだことがあれば、通常は最初に、そのログをLog Analyticsが読み取れるように設定する必要があることをご存じでしょう。具体的には、ログの内容と出所をLog Analyticsに示すソースと、各レコードをフィールドに分解するパーサーを定義します。HITLでは、そのステップは不要です。26.10では、Oracle定義のソースであるOCI Integration – HITL Activity Stream Logsと、ログ・レコードの各属性を名前付きのLog AnalyticsフィールドにマップするOracle定義のJSONパーサーOCI Integration – HITL Activity Stream Log Formatが標準で提供されます。公開を有効にすると、どちらもログ・アナリティックス → 管理に表示されます。
ソースとパーサーはどちらも確認でき、追加のフィールドやエンリッチメントが必要な場合は、複製してカスタマイズできます。ただし、標準で必要なマッピングはすでに設定されています。ソースとパーサーの仕組みについては、Log Analyticsの用語と概念を参照してください。
実際に使うフィールド
パーサーは、約35個のJSON属性をLog Analyticsフィールドにマップします。完全なマッピングはドキュメントに記載されていますが、ほとんどの問合せで主に使用するのは次のフィールドです。
| フィールド | 保持するもの |
|---|---|
| Process Name / Version | ワークフロー名とバージョン |
| Process State | ワークフロー・インスタンスの状態 |
| Instance | ワークフロー・インスタンスGUID |
| Event Type / Event | アクティビティ・タイプ(Task、StartEvent、…)とその名前 |
| Event State | Created（作成済）、Assigned（割当済）、Completed（完了）など |
| Assignee / Assignee Type | 現在のタスク担当者と、その担当先がユーザーかグループか |
| Approver | 実際にタスクに対してアクションを実行したユーザー |
| Result | タスクの結果：Approve、Reject、Submit |
| Comment | 承認者のコメント |
| Duration / Event Duration | インスタンス/アクティビティの所要時間 |
| Due Date / Task Priority | タスクのSLAと優先度 |
| Error ID | アクティビティにフォルトが発生した場合のフォルト・コード |
| Project ID | ワークフローが属するOracle Integrationプロジェクト |
まず試したい問合せ
解析されたフィールドの値では、元のJSONと同じ大文字／小文字が使用されます。たとえば、アクティビティ・タイプはuserTaskやstartEvent、状態はASSIGNEDやCOMPLETEDのように記録されます。データにどのような値が含まれているかわからない場合は、次の問合せを使用すると、データ内に存在するすべてのタイプ／状態の組合せを一覧表示できます。
'Log Source' = 'OCI Integration - HITL Activity Stream Logs'
| stats count by 'Event Type', 'Event State'担当者別の未完了タスク — 「現在、誰が担当しているか？」
'Log Source' = 'OCI Integration - HITL Activity Stream Logs' and 'Event Type' = 'userTask' and 'Event State' = 'ASSIGNED'
| stats count by Assignee
| sort -Count過去30日間に否認されたすべてのタスクと、承認者のコメント：
'Log Source' = 'OCI Integration - HITL Activity Stream Logs' and 'Event Type' = 'userTask' and 'Event State' = 'COMPLETED'
| stats avg('Event Duration') by 'Process Name'ビジュアライゼーションをRecords with HistogramからTableに切り替えると、この5列だけが表示され、そのまま否認レポートとして利用できます。
ワークフローごとの平均タスク完了時間：
'Log Source' = 'OCI Integration - HITL Activity Stream Logs' and 'Event Type' = 'userTask' and 'Event State' = 'COMPLETED'
| stats avg('Event Duration') by 'Process Name'フォルトしたすべてのアクティビティ：
'Log Source' = 'OCI Integration - HITL Activity Stream Logs' and 'Error ID' != null
| fields Time, 'Process Name', Instance, Event, 'Error ID'担当者別の問合せで、ビジュアライゼーションをPieチャートに切り替えた例を次に示します。同じデータですが、未処理のタスクが誰のところに集中しているかが一目でわかります。
ここから、問合せの保存、フィールドのピン留め、アラートの設定ができるほか、HITLレコードを、その他のOCI環境の監視にすでに使用しているダッシュボードに取り込むこともできます。使用可能なすべてのコマンドについては、Log Analytics問合せ言語コマンド・リファレンスを参照してください。
Oracle Integration HITLダッシュボード
ログ・アナリティクスのダッシュボードを初めて使用する方のために、まず簡単に説明します。ダッシュボードは、保存して共有できるウィジェットのページです。各ウィジェットは、ログ・アナリティクスの問合せと、円グラフ、棒グラフ、時系列、表などのビジュアライゼーションを組み合わせた保存済み検索です。この仕組みには、ここで重要ないくつかの特徴があります。ダッシュボード全体で1つの時間範囲セレクタを共有するため、1つのコントロールを切り替えるだけで、過去24時間から過去12か月まで表示期間を変更できます。すべてのウィジェットはインタラクティブで、スライスやバーをクリックすると、その問合せを指定したログ・エクスプローラが開き、そこからさらに詳細を掘り下げて確認できます。また、ウィジェットは保存済み検索なので再利用できます。すでに使用しているダッシュボードにHITLウィジェットを追加したり、ダッシュボード全体を複製してカスタマイズしたり、ウィジェットの問合せにスケジュール済みタスクを関連付けて、しきい値を超えた場合にアラートを発生させたりできます。ログ・アナリティクスでは、さまざまなサービス向けにOracle定義のダッシュボードが標準で提供されており、Oracle Integration向けのダッシュボードも複数用意されています。具体的な操作方法については、ダッシュボードの作成ドキュメントを参照してください。また、NiallのOCI Logging Analytics Dashboards for Oracle Integrationでは、OIC向けダッシュボードの作成手順が詳しく紹介されています。
ダッシュボードを表示するには、オブザーバビリティおよび管理 → ログ・アナリティクス → ダッシュボードに移動し、ダッシュボードを開きます。2つのタブがあることがわかります。
Workflow Instanceタブ
| ウィジェット | 表示内容 |
|---|---|
| Instances By Status | 実行時ステータス別のワークフロー・インスタンスを示す円グラフ：Completed、Created、Expired、Faulted |
| Average Completion Time | 完了までの平均時間。ワークフローごとに1本の棒グラフで表示 |
| Active Instances | 現在Created状態にあるインスタンス数をワークフローごとに表示 |
| Completed Instances | ワークフローごとのインスタンス数をCompleted／Expired／Faultedに分けて表示 |
| Created Instances Over Time | 日付およびワークフロー別に、作成されたインスタンス数の推移を表示 |
これは、ワークフローの健全性を確認するためのビューです。円グラフでExpiredインスタンスの割合が増えている、あるいはワークフローの平均完了時間が徐々に長くなっている場合は、承認処理がどこかで滞留し始めている兆候と考えられます。
Taskタブ
| ウィジェット | 表示内容 |
|---|---|
| Tasks By Status | ステータス別のタスクを示す円グラフ：Assigned、Completed、Created、Unassigned、Withdrawn |
| Tasks By Status and Workflow | ワークフローごとに、タスクのステータス構成を積み上げ棒グラフで表示 |
| Pending Tasks By Users/Group | ユーザーまたはグループごとの未処理タスクのワークロード |
| Completed Tasks By Approver | 承認者ごとの完了済みタスクを、タスク・タイプ別に表示 |
| Tasks By Outcome | Approve／Reject／Submitの結果を示す円グラフ |
これは、担当者に着目したビューです。Pending Tasks By Users/Groupでは誰がボトルネックになっているか、Completed Tasks By Approverでは誰が多くのタスクを処理しているか、Tasks By Outcomeでは、そのワークフローが実際に判断を伴うものなのか、それとも形式的な承認になっているのかを確認できます。
レコードを詳しく確認
各ウィジェットは、実際に実行される問合せです。スライスやバー（たとえば、Tasks By Statusのassignedスライス）をクリックすると、該当するレコードが表示された状態でログ・エクスプローラが開き、さらに絞り込むことができます。
ウィジェットは完成形ではなく、出発点として活用できます。各ウィジェットの背後にある問合せは、複製して変更したり、アラートを設定したりできます。
まとめ
- HITLアクティビティ・ストリーム・ログをOCI Log Analyticsに公開できるようになり、監査やコンプライアンスのために、プラットフォームの6か月という保持期間の上限を超えてデータを保持できます。
- すべてのワークフローおよびタスクの状態変更は、ワークフロー、タスク、関係者、結果に関する約35のフィールドを含む、構造化され解析済みのレコードとして記録されます。
- 設定は3つのステップで完了します。ログ・グループの作成、IAM動的グループとポリシーの設定、Oracle Integrationインスタンスでの公開の有効化です。
- ログ・エクスプローラでは、これらのレコードを自由に問い合わせできます。
- 事前構築済のOracle Integration: HITLダッシュボードでは、運用チームやビジネス・プロセスのオーナーが、インスタンスの健全性とタスクのワークロードを一目で確認でき、基礎となるログまで掘り下げて確認できます。
同じデータから、長期監査と日々の運用可視化の両方を実現できます。追加で何かを構築する必要もありません。Oracle Integrationで承認を実行している場合や、AIエージェントが人の判断を仰ぐために一時停止する仕組みを利用している場合は、この機能を有効にする価値があります。