9. ツール¶

9.1. ツールで確かめること¶

ツールの検討は、まず組み込みツールで足りるかどうかを確認するところから始めます。足りない場合に、業務固有の処理はロジックツールで、外部サービスへの接続は MCP で補う、という順序で検討します。

ロジックツールでは、ツールの「指示」（AI 向けの説明）が LLM の選択精度を左右します。何ができるかだけでなく、いつ呼ぶべきかを書きます。組み込みツールと MCP のツールには、指示を書く欄はありません。

9.2. 組み込みツールを割り当てる¶

組み込みツールは、製品にあらかじめ用意されているツールです。エージェント定義の編集画面でツールとして選び、割り当てて利用します（「ツール」）。

組み込みツールは製品ごとに提供されており、一覧に表示されるツールは、導入しているモジュールによって変わります。例えば、IM-Workflow のモジュールを導入している環境では、ワークフロー関連のツールが表示されます。

一覧はカテゴリ・サブカテゴリで絞り込めるほか、ツール名と説明をキーワードで検索できます。ツールを選ぶと、そのツールの説明と、設定できる項目が表示されます。

設定できる項目は 2 種類です。

プロパティは LLM には公開されず、値を設定しなかった場合も LLM が値を決めることはありません。設定した値は、そのエージェントのすべての実行で共通に使われます。各項目の意味は、画面に表示される説明を参照してください。

動作を確認するには、提供元の製品側にデータが必要です。IM-Workflow のツールであれば、対象となるフロー定義や案件をあらかじめ用意してください。

9.3. ロジックツールを作る¶

ロジックツールは、IM-LogicDesigner のロジックフローを、業務固有のツールとしてエージェントに割り当てる機能です。登録する項目は、ツールID、ツール名、カテゴリ、説明（人が読む）、指示（AI 向けの説明）、参照するロジックフローとそのバージョンです。

図：ロジックツールの詳細画面。ツールID・指示・参照するロジックフロー・入力パラメータが並ぶ。

設計するときの勘所は、ツールを API の薄いラッパにしないことです。曖昧な入力を許容する、パラメータを絞る、結果を構造化して返す、副作用を明示する、といった設計判断が必要です。例えば「案件ID を受け取ってフィールド値をそのまま返す」だけのツールにすると、LLM は返ってきた生データをどう解釈すべきか自分で判断しなければなりません。「在庫数」「単価」のように意味のわかる形に整えて返すと、後続の判断の精度が上がります。

入出力の定義はロジックフロー側が正であり、ツール側に写しは持ちません。バージョンは「常に最新」を参照するか、特定のバージョンに固定するかを選べます。「常に最新」にすると、ロジックフロー側の入出力変更がエージェントの動作に無断で影響するため、頻繁に更新されるフローを参照する場合はバージョンを固定し、更新のたびに動作を確認してから切り替える運用を検討します。

ロジックフロー側には、実行制御用の予約パラメータ imcoToolExecutionContext が自動的に付与されるため、入力パラメータの定義でこの名前を使わないようにします。

9.4. MCPサーバに接続する¶

MCP は、外部サービスに接続する選択肢です。判断材料として最も重要なのは、intra-mart Accel Platform の権限コンテキストが引き継がれない点にあります。外部サービス側で誰の権限として動作するかを、別途設計する必要があります。

追加は 3 ステップのウィザードで進みます。

図：MCPサーバ追加ウィザードの Step1。サーバURLと、管理時認証方式（認証なし・OAuth・APIキー）を指定する。

認証は、なし・API キー・OAuth のいずれかを、管理時と実行時で個別に設定できます。OAuth には、ユーザの認可を得てアクセストークンを取得する認可コード（Authorization Code）と、ユーザ操作なしに JWT アサーション（RFC 7523）でアクセストークンを取得するクライアントクレデンシャルの 2 方式があります。管理者が事前に接続確認する場面では認可コードを、エージェント実行時にユーザ操作を挟めない場面ではクライアントクレデンシャルを選ぶ、という使い分けです。接続方式は Streamable HTTP のみです。プライベートアドレス帯のサーバは、既定の URL ブロックリスト設定では接続できません（「MCPサーバのURLブロックリスト設定」）。

Step3 では、取得したツール定義への注意喚起が表示されます。これは「MCPのセキュリティに注意する」で説明する Tool Poisoning・サプライチェーン攻撃を指しており、ツール名と説明を目視で確認してから登録します。

ツール一覧は自動更新されず、更新しても差分は表示されません。人が目視で確認する運用が必要です。

9.5. MCPのセキュリティに注意する¶

MCP には、Tool Poisoning、Tool Shadowing、Rug Pull、間接プロンプトインジェクションといった、この接続方式に固有のリスクがあります。

信頼できる MCP サーバだけを利用すること、追加時・更新確認時にツール名と説明を目視で確認することが、利用者側の基本です。ツール一覧が自動更新されない仕様（「MCPサーバに接続する」）は、裏を返せば Rug Pull を画面の自動反映では検知できないことを意味します。定期的な目視確認を運用に組み込みます。

9.6. 副作用のあるツールの扱い方¶

読み取り専用のツールは自動実行してよいものの、作成・更新・外部送信を伴うツールは、許可の条件を満たす場合に限って実行させる、という考え方が一般的です。ただし、これは設計上の心得であって、製品機能として強制されるものではありません。

実行前に人の承認を挟む仕組みは、実装には存在しません。MCP のプロトコルが持つ「読み取り専用」といったヒントは受信していますが、実行制御には使っていません。実際に実行を止められるのは、ガードレールの検査だけです（「ガードレール」）。副作用のあるツールを扱うエージェントでは、ツール入力の検査位置にガードレールを置き、想定外の引数（例えば承認や送信を伴う操作）を検知したら止める、という組み合わせが現実的な防御策です。

9.7. 困ったときの確認¶