AIエージェントを企業業務へ組み込むと、AIは回答を生成するだけでなく、社内データを参照し、APIやMCPを通じてシステムを操作し、複数の処理を連続して実行するようになります。

このとき重要になるのが、AIの判断だけに任せず、「どのデータを使えるか」「どの操作を許可するか」「どこで承認を求めるか」「異常時にどう止めるか」を実行時に制御する仕組みです。

GBSでは、AIモデルやAIエージェントの外側で、権限、ツール利用、承認、実行回数、利用量、ログ、停止などを制御する仕組みを「AIハーネス」として整理し、PoCから本番運用へ移行するための実行制御を設計します。

このようなお悩みはありませんか

  • AIエージェントを既存システムにつないだ後、どこまで操作を許可すべきかわからない
  • 参照は許可したいが、登録・更新・削除まで自由に実行させるのは不安がある
  • AIが誤ったツールやAPIを呼び出した場合の制御方法を決めていない
  • 同じ処理やAPI呼び出しを繰り返した場合、自動で止められるようにしたい
  • 重要な処理だけ人の承認を通してから実行させたい
  • AIがいつ、どのデータ・ツールを利用し、何を実行したのか後から確認したい
  • トークン、API呼び出し、外部サービス利用などのコストを実行時に制御したい
  • PoCでは動いているが、本番環境へ接続するための安全策が不足している

AIエージェントを本番システムへ接続する前の実行制御からご相談いただけます

現在のAIエージェント、利用ツール、接続先システム、権限、エラー処理などを確認し、本番運用で必要になる制御ポイントを整理します。

AIハーネス・実行制御について相談する →

AIハーネスは、AIエージェントの「実行境界」をつくる

AIエージェントへ「この操作をしてはいけない」とプロンプトで指示することはできます。しかし、本番業務では、重要な制御をAI自身の判断だけに依存させないことが重要です。

例えば、「削除は禁止」とAIへ指示するだけでなく、削除機能そのものをAIから利用できないようにする。「10万円以上の処理は承認が必要」と伝えるだけでなく、その条件に該当した処理を実行前に停止し、人の承認へ回す、といった仕組みをAIの外側に設けます。

AIエージェント

目的に応じて情報を取得し、判断し、必要なツールを選びながら業務を進めます。

AIハーネス

AIエージェントが要求した操作に対して、権限、条件、利用量、承認状態などを確認し、許可・拒否・停止・エスカレーションを制御します。

既存システム・データ

PLM、ERP、CRM、情報共有基盤、データベース、Webシステムなど、実際の業務データと処理を提供します。

AIハーネスは、AIを賢くするための仕組みというより、AIの実行を企業システムの中で扱える状態へ整えるための制御層です。

プロンプトによる指示と、システムによる強制制御を分ける

AIエージェントでは、プロンプトや業務ルールによって「何をするか」を指示します。一方で、本番運用では、守る必要がある条件をシステム側でも制御することが重要です。

AIへ指示するルール

  • この情報を優先して参照する
  • この条件では担当者へ確認する
  • この形式で結果を返す
  • 情報が不足している場合は追加確認する

システム側で強制するルール

  • 許可されていないデータへアクセスさせない
  • 許可されていないツールを実行させない
  • 権限を超える更新処理を拒否する
  • 承認が完了していない処理を実行させない
  • 利用量や実行回数が上限を超えた場合に停止する

特に、情報更新、外部送信、削除、承認、重要な業務処理などは、AIへの指示だけでなく、実行前にシステム側で条件を確認できる構成を検討します。

AIが使えるツールを、業務ごとに限定する

MCPやAPIによって多数の機能をAIから利用できるようにしても、すべてのAIエージェントへすべてのツールを公開する必要はありません。

例えば、製品情報を検索するAIエージェントには参照系ツールだけを公開し、変更申請を作成するAIエージェントには申請作成までを許可する、といった形で利用可能な機能を分けます。

ツール利用制御で確認すること

  • どのAIエージェントが利用できるツールか
  • どの利用者からの依頼で利用できるか
  • 参照・登録・更新・削除のどこまで許可するか
  • 実行できる対象データを限定する必要があるか
  • 入力できるパラメータを制限する必要があるか
  • 一度に処理できる件数を制限する必要があるか
  • 外部サービスへの送信を許可するか

AIへ強い権限を一括して与えるのではなく、対象業務で必要な操作だけを公開することを基本とします。

利用者の権限を、AI経由でも引き継ぐ

AIエージェントを利用するときに注意したいのが、「人が直接システムを利用した場合には見られない情報を、AI経由なら見られてしまう」という状態です。

AIエージェント自体が強い共通権限を持つ構成では、利用者本来のアクセス権を超えて情報を取得してしまう可能性があります。

実行時に確認する権限の例

  • 利用者が対象データを参照できるか
  • 対象部門・プロジェクトの情報へアクセスできるか
  • 更新処理を実行できる役割か
  • 対象システム側の権限と整合しているか
  • AIエージェント固有の権限が必要か
  • 代理実行した利用者を記録できるか

可能な場合は、既存システムが持つ認証・権限の仕組みを活かしながら、AI経由でも利用者の権限境界を維持できる方法を検討します。

重要な処理は、実行直前で人の承認を求める

AIが処理案を作成することと、その処理を本番システムへ反映することは分けて考えられます。

影響の大きい操作では、AIが必要な情報を揃えて処理内容を準備し、実際の実行だけを人の承認後に行う構成が有効な場合があります。

承認を入れることを検討する処理

  • 正式データの更新
  • 設計・仕様・BOMなどへの変更反映
  • データ削除
  • 外部への情報送信
  • 高額な処理や発注
  • 多数のデータを一括変更する処理
  • 通常とは異なる例外処理

承認ポイントは一律に増やすのではなく、業務への影響度に応じて設定します。低リスクな処理は自動実行し、高リスクな処理だけ人へ戻すことで、自動化の効果を損なわない設計を目指します。

AIのツール実行前に、入力内容を検証する

AIが適切なツールを選択していても、渡す値が適切とは限りません。

そのため、重要なツールについては、AIが生成したパラメータをそのまま既存システムへ渡すのではなく、実行前に形式や値を検証する仕組みを設けることを検討します。

実行前チェックの例

  • 必須項目が揃っているか
  • データ型や形式が正しいか
  • 許可された値の範囲か
  • 一度に処理する件数が上限内か
  • 対象となるIDやデータが存在するか
  • 利用者に対象データの操作権限があるか
  • 危険な文字列や想定外の命令が含まれていないか

AIの出力を信用する・しないという二択ではなく、通常の業務システムと同様に、外部から受け取る入力として検証する考え方が重要です。

繰り返し実行や異常動作を、実行側から止める

AIエージェント自身にも終了条件を設けますが、本番環境では、それとは別に外側から強制的に停止できる仕組みも重要です。

AIが想定どおり停止しない場合や、外部サービス側の障害によって同じ処理を繰り返す場合でも、実行基盤側で上限を超えた処理を遮断できるようにします。

実行制御で設定する上限の例

  • 1回の業務あたりのツール実行回数
  • 同一APIの連続呼び出し回数
  • 一定時間内のリクエスト数
  • 連続エラー回数
  • 最大処理時間
  • AIモデルへの最大問い合わせ回数
  • 最大トークン利用量
  • 1処理・1日・1利用者あたりのコスト

設定した条件を超えた場合には、処理を停止する、一定時間待機する、人へ通知する、別の処理へ切り替えるなどの動作を決めます。

外部サービス障害を、AIの暴走につなげない

AIエージェントは、AIモデルだけでなく、API、MCPサーバー、データベース、外部SaaSなど複数のサービスへ接続する場合があります。

接続先が一時的に応答しない場合、AIが同じ処理を繰り返すだけでは、障害を悪化させたり、不要な利用コストを増やしたりする可能性があります。

障害時の制御例

  • 一定回数の失敗後に呼び出しを停止する
  • エラー内容によって再試行するか判断する
  • 再試行までの間隔を空ける
  • 障害中のサービスを一時的に利用対象から外す
  • 代替手段がある場合のみ別経路へ切り替える
  • 復旧できない場合は人へエスカレーションする

AIエージェント側の判断だけでなく、接続・実行層でも障害を検知し、不要な処理を増やさない構成を検討します。

トークン・API・外部サービスの利用量を実行時に管理する

AIエージェントは、一つの業務を完了するまでに複数回AIモデルや外部ツールを呼び出すことがあります。

少数のPoCでは問題にならなかった利用量でも、多数の利用者や定期処理へ展開すると、トークン、API、検索、画像処理などの利用量が大きくなる場合があります。

利用量として把握する項目

  • AIモデルの呼び出し回数
  • 入出力トークン量
  • MCP・API・ツール実行回数
  • 処理時間
  • 外部サービスの利用量
  • AIエージェントごとの処理件数
  • 利用者・部門ごとの利用量
  • 業務1件あたりの実行コスト

把握するだけでなく、必要に応じて上限値を設定し、異常な利用量を検知した場合に停止・通知できるようにします。

AIの実行を、後から追跡できるログに残す

本番業務では、「AIが最終的に何を回答したか」だけでは、問題が発生したときに原因を確認できない場合があります。

どのAIエージェントが、誰の依頼で、どのツールを呼び出し、どの処理を実行したのかを追跡できることが重要です。

記録を検討する情報

  • 実行日時
  • 利用者・実行元
  • AIエージェントの種類・バージョン
  • 利用したAIモデル
  • 利用したツール・API・MCP
  • ツールへ渡した主要な実行条件
  • 実行結果・エラー
  • 承認・拒否の履歴
  • 停止・エスカレーションの発生
  • トークン・APIなどの利用量

機密情報をすべてログへ残せばよいわけではありません。調査に必要な情報と、記録すべきでない情報を整理しながらログ設計を行います。

「何が起きているか」を運用側から確認できるようにする

ログを保存するだけでなく、AIエージェントの稼働状態を運用担当者が把握できることも重要です。

監視する指標の例

  • 実行件数・成功件数・失敗件数
  • 平均処理時間
  • ツールごとのエラー率
  • 停止・拒否された処理件数
  • 承認待ち件数
  • 外部サービスの応答状況
  • トークン・API利用量の増加
  • 通常とは異なる実行パターン

AIの出力品質を見るだけでなく、AIエージェントを一つの業務システムとして監視できる状態を目指します。

一括停止できる仕組みを用意する

個々のAIエージェントが持つ停止条件とは別に、運用者側からAIの実行を停止できる仕組みも検討します。

システム障害、予期しない大量処理、接続先の仕様変更など、本番運用では設計時に想定していなかった事象が発生する可能性があります。

停止単位として検討するもの

  • 特定のAIエージェントだけを停止する
  • 特定ツールの利用だけを停止する
  • 更新系処理だけを停止する
  • 特定の外部システムとの接続を停止する
  • 特定利用者・部門の利用を停止する
  • 必要に応じてAIエージェント全体を停止する

すべてを一括して止めるだけでなく、問題が発生している範囲だけを切り離せる設計にすることで、影響範囲を限定しやすくなります。

MCP・APIで「つなぐ」、AIハーネスで「実行を制御する」

AIエージェントと既存システムを接続する方法と、接続後の実行を制御する方法は分けて考えます。

MCP・API・既存システム連携

AIから利用するデータや機能を整理し、既存システムと接続できる形をつくります。

AIハーネス・実行制御

接続されたデータ・機能を、誰が、どの条件で、どの範囲まで実行できるかを制御します。

既存システムとの接続方法について

MCP、API、既存データベース、スクラッチシステム、レガシーシステムなどとの接続方式については、専門ページで詳しくご紹介しています。

MCP・API・既存システム連携について詳しく見る →

PLMなど重要な業務システムほど、操作単位で制御する

PLM、ERPなど企業の重要な業務データを扱うシステムでは、「AIからアクセスできるか」だけでなく、実行する操作の影響度を考える必要があります。

例えばPLMへ接続する場合

  • 品目・BOM・文書を検索する処理は自動実行する
  • 変更内容の下書き作成はAIへ任せる
  • 変更申請の登録は対象条件を確認して実行する
  • 正式な変更反映は人の承認後に実行する
  • 大量更新や削除はAIから直接実行できないようにする
  • すべての更新処理について実行者とAIの操作履歴を残す

どこまで自動化できるかは対象業務やシステムによって異なります。GBSでは、操作の影響度に応じて実行範囲を分けることを重視します。

PoCから本番へ移るときに、実行制御を追加する

PoCでは、対象ユーザーやデータを限定し、手動で監視しながらAIエージェントを動かせる場合があります。

しかし本番では、利用者数、処理件数、接続システム、実行時間が増えるため、人が常に監視する運用では継続しにくくなります。

本番移行前に確認する実行制御

  • 本番データへのアクセス権
  • 利用者権限の引き継ぎ
  • ツール・操作単位の許可設定
  • 入力値の検証
  • 更新処理の承認
  • 実行回数・利用量の上限
  • エラー時の停止・再試行
  • 運用者による強制停止
  • 実行ログ
  • 稼働状況の監視

GBSでは、PoCで確認したAIエージェントをそのまま本番へ公開するのではなく、本番環境で必要になる実行制御を整理してから段階的に適用します。

PoCは動いたが、本番システムへ接続できずに止まっている場合もご相談ください

AIモデルやプロンプトを作り直すことだけを考えるのではなく、権限、ツール公開範囲、承認、停止、ログ、監視など、本番利用に不足している実行制御を整理します。

AIエージェントの本番実行制御について相談する →

GBSのAIハーネス・実行制御支援の進め方

1.AIエージェントの実行内容を確認する

利用しているAIエージェント、接続先システム、ツール、実行する操作を整理します。

2.操作ごとの影響度を整理する

参照、作成、更新、削除、外部送信などを分け、誤実行した場合の影響を確認します。

3.実行許可の条件を決める

利用者、AIエージェント、対象データ、ツール、操作単位で、許可する条件を整理します。

4.実行前チェックと承認を設計する

入力値の検証や、人による承認が必要な処理を整理し、実行前に確認する仕組みを設計します。

5.実行量と異常時の制御を決める

実行回数、処理時間、エラー回数、トークン、API利用量などの上限と、停止・再試行・エスカレーション方法を決めます。

6.ログと監視を設計する

何を記録し、どの状態を運用担当者が確認する必要があるかを整理します。

7.本番に近い条件で検証する

正常系だけでなく、権限不足、不正な入力、接続障害、連続エラー、利用量超過などのケースも確認します。

8.段階的に自動実行範囲を広げる

最初からすべての操作を自動化するのではなく、運用結果を確認しながら自動実行できる範囲を広げます。

GBSがAIハーネス設計で重視すること

AI自身の判断だけに安全制御を任せない

重要な制御は、プロンプトによる指示だけでなく、AIの外側にある実行基盤でも確認できる構成を検討します。

最小限のツール・権限だけを公開する

接続できる機能をすべてAIへ公開するのではなく、対象業務で必要な操作に限定します。

AI経由でも既存の権限境界を崩さない

利用者が直接利用した場合のアクセス権を、AIを経由することで迂回しない設計を重視します。

止められることを前提にする

個々のAIエージェントの終了判断だけに依存せず、利用量超過や異常時に外側から停止できる仕組みを設けます。

ログを「監査のためだけ」にしない

障害分析、利用状況の把握、実行制御の見直しなど、本番運用の改善にも利用できるログを設計します。

既存システムの仕組みを活かす

認証、アクセス権、承認、監視など既存システムに利用できる仕組みがある場合は、それらを活かし、AI専用の仕組みを増やしすぎないようにします。

AIエージェントの設計と、AIハーネスの役割を分ける

AIエージェント側では、「何の業務を担当するか」「何を判断するか」「どのツールを利用するか」といった仕事の進め方を設計します。

AIハーネス側では、そのAIエージェントが本番環境で実行しようとする操作を確認し、許可、拒否、承認待ち、停止、記録などを行います。

AIエージェントそのものの業務設計について

業務の選定、完了条件、プロンプト、コンテキスト、オーケストレーション、業務ループ、人とAIの役割分担などについては、AIエージェント導入・業務自動化支援ページで詳しくご紹介しています。

AIエージェント導入・業務自動化支援について詳しく見る →

よくある質問

AIハーネスとは何ですか?

GBSでは、AIモデルやAIエージェントの外側で、利用できるデータ・ツール・権限、承認、実行回数、利用量、ログ、異常時の停止などを制御する仕組みをAIハーネスとして整理しています。

AIを賢くするためのモデルではなく、AIエージェントを企業の本番業務で実行するための制御層です。

AIエージェントページで説明しているAIハーネスとは何が違いますか?

AIエージェント導入・業務自動化支援ページでは、AIエージェントを成立させる設計要素の一つとしてAIハーネスを紹介しています。

このページでは、本番環境でAIがツールやシステムを実行するときの権限、入力検証、承認、実行回数、停止、ログ、監視など、実装・運用上の実行制御を詳しく扱っています。

MCPを導入すればAIハーネスは不要ですか?

いいえ。MCPはAIとデータ・ツールを接続するための方式の一つです。接続されたツールをどのAIや利用者へ公開するか、どの操作を許可するか、どこで承認・停止するかは別途設計する必要があります。

プロンプトで「実行しないで」と指示するだけでは不十分ですか?

重要な操作については、AIへの指示だけに依存せず、ツール自体を公開しない、権限を限定する、実行前に条件を検証するなど、システム側で強制できる制御を組み合わせることを検討します。

既存システムのユーザー権限をそのまま利用できますか?

利用できるかは既存システムや接続方式によって異なります。可能な場合は、既存の認証・アクセス権を活かし、AI経由でも利用者本来の権限を超えない構成を検討します。

AIが同じAPIを何度も呼び出す場合に止められますか?

実行基盤側で、同一APIの連続呼び出し回数、一定時間内の実行回数、連続エラー回数、処理時間などに上限を設定し、条件を超えた場合に停止する構成を検討できます。

AIの利用コストにも上限を設定できますか?

利用するAIモデルやサービスの仕様によりますが、トークン量、API呼び出し回数、処理回数などを計測し、設定値を超えた場合に停止・通知する仕組みを検討できます。

AIハーネスは特定の製品を導入するものですか?

GBSでは、AIハーネスを特定の製品名としてではなく、AIエージェントの実行を制御するために必要な仕組みとして整理しています。

既存の認証・API管理・監視・ワークフローなどを活用できる場合もあるため、現在のシステム構成を確認して実現方法を検討します。

PoCのAIエージェントを本番へ移行するときだけ相談できますか?

はい。既にPoCやプロトタイプがある場合、その構成を確認し、本番環境で不足している権限、実行制御、承認、停止、ログ、監視などを整理するところからご相談いただけます。

AIを自律的に動かすなら、「外から止められる」仕組みもつくる

AIエージェントの自律性を高めるほど、AI自身が適切に判断することだけでなく、企業側が実行範囲を制御できることが重要になります。

GBSでは、既存システムや既存の認証・権限を活かしながら、AIエージェントのツール利用、更新処理、承認、利用量、ログ、異常停止などを実行時に制御し、本番業務へ組み込みやすい仕組みを設計します。

AIエージェントを本番システムへ安全につなぐための実行制御をご相談ください

「PoCまではできたが本番環境への接続が不安」「更新権限をAIへどこまで与えるべきかわからない」「異常なAPI実行やコスト増加を自動で止めたい」といった段階から、必要なAIハーネスを整理します。

AIハーネス・実行制御についてGBSに相談する →