AIエージェントを採用する前に決めるべき“インターフェース契約”

月曜の朝会議。経理の森さんは請求例外を、営業の阿部さんは翌日の商談メモを、カスタマー担当は初回返信案を、各自AIエージェントに依頼していました。資料は短時間でそろい、上長は『今日は楽だな』と頷きます。問題はそのあとです。どのデータを根拠に決裁ルートを通したのか、誰が最終実行権限を持つのか、誤結果だったときどこで止めて誰に戻すのかが、画面上に残っていませんでした。

この現場は、AIエージェント導入の現実そのものです。OpenAIやAnthropicの資料は、単発のチャット機能から、長尺タスク、ツール実行、共有コンテキストを持つエージェント運用へ流れが進んでいることを示しています。Google ADKの構成はビルド、インタラクト、評価、デプロイという4段階を前提に、業務が生んだ履歴を残すことを前提に設計されています。MCPはAIアプリとデータ・ツール・ワークフローを接続するUSB-Cのような標準で、接続先が増えるほど、契約条件の曖昧さは事故の起点になります。NIST AI RMF 1.0が重視するTrustworthinessも、設計・開発・運用・評価の全段で成立しなければなりません。

[IMAGE:opening]

> ALTOS LABの判断: AIエージェント導入の第一優先は、性能比較ではなく、入力定義、承認トリガー、回復ルートを先に定義することです。

先に定義すべきは“コンテキストの入口”

AnthropicのBuilding Effective AI Agentsは、ワークフロー（固定手順）とエージェント（動的な探索）を切り分ける重要性を示しています。つまり、まずは各作業が決まった手順で回るのか、状況を読みながら分岐するのかを分ける。ここで曖昧なままだと、エージェントは速く動くのに責任が薄いままになります。

運用目線では、入力は「利用許可されたデータセット」「禁止データ」「更新日時」「参照ログ保持」の4つで最低限固定します。これを明文化すると、営業会議で出た数値がどこから来たか、あとで即座に追跡できます。

実行と承認の境界を決める

OpenAI Agents SDKはアプリ側にオーケストレーションと状態管理を置ける設計で、実行と監督の分離が前提です。現場ではここを、承認なしで実行可能な操作と承認必須の操作に分解してください。

特に危険な領域は、お金、契約、顧客通知、システム変更です。これらはエージェントへ「起案」「草稿保存」「人間の最終送信」を分けるのが安全です。Google ADKの評価設計と整合させるなら、評価フェーズで常に「証拠付きログ」「失敗時の説明可能性」「回収コスト」を検証項目に入れておきます。

[IMAGE:mechanism]

ALTOS LABの現場チェックリスト（30分で回せる）

実務チェックとして今夜から使える項目を1セット提示します。 1. コンテキスト定義: どのシステム・どの期間・どの粒度のデータをエージェントに渡すか、一覧表にする。 2. ツール権限制御: 参照専用、作成のみ、承認後実行など、操作レベルを明示する。 3. リスク分岐ルール: 影響が大きいタスクは「人が最終承認」を必須化し、低リスクタスクは自動再試行と限定自動化を許可する。 4. 証跡保存: 実行前提条件、外部呼び出し、理由説明、結果、失敗時の戻し手順を必ず記録する。 5. 引き継ぎルート: エージェントが失敗した場合の担当窓口、監査期限、再実行手順をSLAsに含める。

今週の運用はこの5項目だけで十分です。導入失敗の9割はアルゴリズムではなく、境界線がない運用で起きます。AIエージェントに求めるのは“賢さ”だけではなく、事故が起きても会社が止まらない設計です。