SIer向けAIエージェントの開発標準｜6つのゲート
目次
案件Aで作った評価表を案件Bへ持ち込むと、顧客固有の用語と権限が合わない。そこで担当者が表をコピーし、独自の列を足す。半年後には似た雛形が十数個でき、どれが現行版か分からない。SIerでAIエージェントを横展開すると、実装より先にこの問題が起きる。
個別案件の本番化チェックだけでは解けない。共通部分と案件固有部分を分け、標準そのものを版管理し、例外を承認し、改善を全案件へ戻す仕組みが要る。
SIer向けAIエージェントの開発標準は、実装方法を一つに固定する規約ではない。案件ごとに設計を変えつつ、通過条件と証拠をそろえる共通基盤である。六つ の品質ゲートと、その標準を運営する仕組みに分けて考える。
SIer向けAIエージェントの開発標準は通過条件をそろえる
AIエージェントは、質問へ文章を返すだけではない。検索し、外部ツールを呼び、データを更新し、次の処理を選ぶ。だから、従来の画面・API中心の標準へプロンプトの書式を足すだけでは足りない。
NISTのAI Risk Management Frameworkは、AIリスク管理を Govern、Map、Measure、Manage の四機能で整理し、ライフサイクル全体を対象にしている。モデル精度だけでなく、責任、用途、測定、変更管理をつなげる必要がある。
標準化するのは特定のLLMや基盤ではない。各工程の入力、合格条件、成果物、承認者である。会社共通の「コア標準」と、顧客の規制や業務に合わせる「案件プロファイル」を分ける。レビュー観点は保ちつつ、不要な統制まで押し付けずに済む。
開発標準で確認する6つのゲート
案件ごとに同じ6つのゲートを通し、合格条件と証跡を残す。ゲート名だけを置かず、誰が何を確認すれば次工程へ進めるかまで決める。
ゲート1：用途とリスク階層を一枚で合 意する
最初に「何ができるか」ではなく、「どの業務で、誰に、どんな影響を与えるか」を決める。低リスクの社内検索と、顧客へ回答を送るエージェントを同じ審査にかけると、前者は重すぎ、後者は軽すぎる。
企画時は一枚の用途票が扱いやすい。目的、利用者、対象データ、操作、誤りの影響、業務責任者、停止権限者を書く。閲覧、下書き、人の承認後に実行、自動実行の四段階で自律度を示す。この分類表は標準側で管理し、案件側は選んだ階層と根拠だけを記録する。
Microsoftの責任あるAIガイドも、人や重要な処理へ影響するエージェントには本番前の評価ゲートを求める。全案件を同じ深さで審査せず、影響が大きい案件ほど証拠を増やす。
ゲートを通すには、業務責任者と開発責任者が用途、禁止用途、自律度に署名する。責任者が「AIチーム」のような組織名だけなら差し戻す。
ゲート2：正本データと権限境界を固定する
次に決めるのは、エージェントが何を信じ、どこまで見られるかだ。情報源を増やすほど賢くなるとは限らない。古い規程と最新版が同時に検索されれば、もっともらしい誤答が増える。
情報源ごとに、正本、更新者、更新頻度、機密区分、参照者を表にする。検索結果には文書IDと版を残す。本人が開けない資料をエージェントだけが読める構成にもしてはいけない。
権限は閲覧、作成、更新、削除を分ける。外部送信、金銭、契約、個人情報、本番データの変更は、人の承認がない限り実行させない。標準には権限パターンを置き、案件プロファイルには採用理由と差分を残す。
この考え方は、AIエージェントの要件定義で整理した入力・判断・出力・権限・停止条件にもつながる。合格の証拠は、情報源台帳、権限表、データフロー図である。
ゲート3：ツール呼び出しを契約として設計する
AIエージェントの事故は、回答文よりツール実行で大きくなる。曖昧な引数を補完して顧客データを更新したり、再試行で同じ注文を二重登録したりするからだ。
各ツールには、入力型、必須項目、許容値、実行前確認、失敗時の扱い、再試行回数、重複防止キーを定義する。「よしなに更新する」のような自由度は残さない。更新処理には差分表示と取り消し手段も要る。
OWASP Top 10 for Agentic Applicationsは、Agent Goal Hijack、Tool Misuse、Identity & Privilege Abuse、Cascading Failuresなどを挙げる。プロンプト対策だけでなく、ツールが安全側に失敗するかを試験する。
合格条件は、許可された操作と禁止された操作が機械判定でき、失敗時に途中状態を追跡できること。API仕様だけでなく、業務上の承認条件まで契約へ入れる。
ゲート4：評価データと合格閾値を実装前に作る
「回答が自然だった」「担当者の評判がよかった」だけでは検収できない。AIの出力は揺れるため、正解文の完全一致より、業務上の合格を測る。
問い合わせ分類なら、精度に加え、重要案件の見逃し率、根拠の提示率、禁止回答率、処理時間、費用を見る。ツールを使うなら最終回答と途中の軌跡を分ける。結果が正しくても、権限外のデータを読んだなら不合格だ。
Microsoft Foundryのエージェント評価ガイドは、テストデータ、評価器、合格閾値をCI/CDへ組み込む流れを示す。閾値は例示値を借りず、損失と人手確認の容量から決める。
テストデータには、正常例だけでなく、情報不足、矛盾 、権限外、長文、表記ゆれ、外部サービス停止を含める。AIエージェントの評価設計で扱ったように、失敗例を蓄積して回帰テストへ戻す。合格条件は、評価データの版、指標、閾値、未達時の判断者がそろっていることだ。
ゲート5：攻撃と障害を入れて止まり方を試す
平常系の精度が高くても、本番準備は終わらない。外部文書に「これまでの指示を無視せよ」と書かれている。APIがタイムアウトする。途中で権限が変わる。モデルが同じツールを繰り返す。こうした状況を意図的に作る。
試験では、入力改ざん、機密情報の要求、権限昇格、ツールの連続失敗、無限ループ、コスト上限到達を扱う。見るべきは「必ず正答するか」ではない。安全に停止し、担当者へ引き継げるかだ。
このゲートの成果物は、脅威モデル、攻撃テスト結果、停止条件一覧、復旧手順である。重大な失敗の原因を特定できず、修正後の再試験で解消を確認できない場合は本番へ進めない。失敗を隠すフォールバックは、停止より危険だ。
ゲート6：リリース後の観測と引き継ぎを先に決める
モデル、データ、利用者の行動は変わる。案件終了後にSIerが抜けても、顧客側で説明、停止、改善 ができなければ運用品質は続かない。
Google CloudのAI・ML向け性能最適化ガイドは、試作から本番へ移すには標準化された評価プロセスが必要であり、評価の自動化が再現性と拡張性を支えるとしている。開発時の評価指標を捨てず、運用監視へ接続することが肝になる。
最低限、リクエストID、情報源の版、ツール呼び出し、承認者、実行結果、待ち時間、費用、評価結果を追えるようにする。ログの保存期間と閲覧権限も決める。
引き継ぎ物には、構成図、プロンプトとツール定義の版、評価データ、既知の制約、監視項目、停止手順、変更承認フローを含める。合格条件は、運用担当者が開発者なしで異常を検知し、停止と一次切り分けを実演できることだ。
標準を腐らせない五つの運営ルール
六つのゲートは、文書化しただけでは形骸化する。標準を社内プロダクトとして運営する。
| 運営ルール | 決めること | 案件に残す証拠 |
|---|---|---|
| オーナー | 改定責任者、技術・品質・法務のレビュー役 | 適用した標準の版 |
| テーラリング | 省略できる項目と、省略できない最低線 | 採用・非採用の理由 |
| 例外申請 | 期限、補完策、承認者、解消条件 | 例外IDと失効日 |
| 監査 | 抽出する案件、確認頻度、是正期限 | ゲート証跡と是正記録 |
| 再利用 | 共通ツール、評価データ、失敗事例の登録条件 | 利用した資産の版と差分 |
標準オーナーは、モデル更新、事故、監査所見を受けて標準を改定し、変更点と移行期限を知らせる。進行中案件へ即時適用するか、次 回リリースから適用するかも決める。
案件プロファイルでは、共通項目を黙って削除しない。「既存監査で代替」「閲覧専用なので更新系試験は対象外」のように理由を書く。例外には失効日を置く。期限のない例外は標準変更と同じだ。
再利用資産も、置くだけでは危ない。ツール定義には標準版と所有者を付ける。評価データには匿名化条件と対象業務を付ける。失敗事例は原因、検知方法、回帰テストまで一組で登録する。これで案件Aの学びが案件Bの品質へ変わる。
最初の試行は、単一の低〜中リスク案件に絞る。四週間は最小版を一巡させる目安である。規制業種、多数の外部連携、自動実行を含む案件には当てはめない。未達なら前工程へ戻り、更新した証拠で再判定する。
標準の指標には、レビュー時間、差し戻し率、重大障害、同じ失敗の再発数、再利用率を置く。使われない項目を削る方が標準は強くなる。
SIerの強みを「案件知識」から「再利用できる品質」へ変える
SIerには、顧客業務を読み解き、検収可能な成果物へ落とす力がある。外部ツールまで動かすAIエージェントには、この力が欠かせない。
ただし、知見が担当者の頭に残ったままでは横展開できない。用途、権限、ツール、評価、安全性、運用の六つをゲート化すると 、案件固有の工夫と共通品質を分けられる。フレームワークを替えても、確認すべき問いは残る。
株式会社Atsumellでは、業務フロー、AIが読める要件・仕様、評価設計、AIエージェントの実装までを支援している。案件ごとの作り直しを減らしたいなら、まず一案件の六つのゲートを一緒に棚卸ししたい。相談はお問い合わせフォームから受け付けている。
