Atsumell
AI導入

【第8部】成果物・安全性・観測性でAIエージェントを社内導入する

株式会社Atsumell|8分で読めます
成果物・安全性・観測性でAIエージェントを社内導入する

# 【第8部】成果物・安全性・観測性でAIエージェントを社内導入する

> 連載「Slack AIエージェント基盤を作る」全8部の第8部。

第7部までで、Slackから依頼でき、サーバーで動き、並行処理し、記憶し、定期実行するAIエージェント基盤が見えてきた。最後に問われるのは、社内で安心して使えるかだ。第8部では、成果物の保存、安全境界、観測性、人間の承認点をまとめ、試験導入を超えるための条件を整理する。

前後で読む

AIエージェントをSlackから使えるようにすると、最初は反応の速さに目が行く。依頼すると調べてくれる。文章を書いてくれる。コードも直してくれる。

でも社内導入で本当に問われるのは、その後だ。何を作ったのか。どこに保存したのか。誰が承認したのか。失敗したとき、どこを見れば原因が分かるのか。AIエージェントの安全性は、モデルの能力だけでは決まらない。

この基盤では、Slack、CLI実行、記憶、定期実行、成果物管理を分けて扱っている。これは実装をきれいにするためだけではなく、社内で運用できる責任線を作るためだ。

成果物をSlackの返信だけに閉じ込めない

AIエージェントの出力をSlackの返信だけで済ませると、後から探しにくい。長い調査結果、生成した記事、修正案、ログ、画像、レポートは、Slackスレッドの中で流れてしまう。

成果物管理では、次のように分ける。

  • Slackへ返す短い要約
  • 保存先に置く詳細な成果物
  • 後から参照するメタデータ
  • 実行ログ
  • 失敗時の診断情報

Slackには判断に必要な内容だけを返し、詳細は保存先へ置く。これにより、ユーザーはすぐ判断でき、管理者は後から追跡できる。生成物が記事や提案書なら、完成版、下書き、検証結果を分けると扱いやすい。

AIエージェントの安全性は権限設計から始まる

AIエージェントの安全性を考えるとき、プロンプトだけに頼るのは危ない。

「危ない操作をしないで」と書くだけでは、権限の境界にならない。実際に実行できるコマンド、読めるファイル、書ける場所、外部送信できる先を制御する必要がある。

社内導入では、次のような境界を持たせる。

  • ユーザーごとの実行権限
  • チャンネルごとの許可範囲
  • プロジェクトごとの作業領域
  • 書き込み可能な保存先
  • 外部通信の許可条件
  • 破壊的操作の確認フロー
  • 機密情報の検出とマスキング

共有する設計情報には、権限設定名、社内URL、トークン名、保存先の実パスを直接出さない。代わりに、どの境界を設けるべきかを書く。攻撃に使える情報を避けながら、設計の考え方は十分伝えられる。

OpenAIのコード生成ガイドでも、AIにコード作業を任せる際は文脈と評価が鍵になる。社内導入では、そこに権限と監査の層を重ねる必要がある。

観測性がないAIエージェントは運用できない

AIエージェントが失敗したとき、「なぜそうなったか」が分からないと運用できない。

観測性とは、単にログを残すことではない。ジョブの流れ、ツール呼び出し、判断理由、成果物、失敗分類を後から追える状態にすることだ。

最低限、次の情報は残したい。

  • ジョブID
  • 依頼元
  • 実行したスキル
  • 使用したCLI
  • 開始時刻と終了時刻
  • 成功または失敗
  • 失敗分類
  • 成果物の保存先
  • ユーザーへ返した要約

これにより、チームはAIエージェントをブラックボックスとして扱わずに済む。何が多く失敗しているか、どのタスクが時間を使っているか、どのスキルがよく使われるかも見える。

人間の承認をどこに置くか

AIエージェントを社内導入するとき、すべてを自動化する必要はない。むしろ、承認点をうまく置くほど使いやすくなる。

たとえば、調査、要約、下書き作成は自動でよい。外部送信、削除、契約に関わる文面、費用が発生する操作は承認を挟む。コード変更も、直接本番へ反映するのではなく、差分として提示し、人間が確認する流れにする。

Slack Bolt for JavaScriptを使えば、Slack上で確認ボタンや返信フローを作れる。ただし、確認UIを増やしすぎると使われない。リスクの高いところだけ明確に止めるのが現実的だ。

承認点は、後から監査できる形で残す。誰が、どの成果物を、どの理由で承認したのかが分かるだけで、AIエージェントの提案を業務フローへ入れやすくなる。逆に承認履歴がSlackの会話だけに埋もれると、月末の振り返りや事故調査で追えない。成果物IDと承認ログを対応づける設計は地味だが、社内導入では効いてくる。

失敗談として価値があるのは復旧できる設計だ

成果物生成は、うまくいったデモだけを見ると簡単に見える。実務で難しいのは、途中で崩れたときにどこまで戻れるかだ。PPTXの文字があふれる。PDF変換に失敗する。Slack添付が失敗する。外部SaaSの画面が変わる。AIエージェント基盤は、こうした失敗を前提に作る。

だからartifact record、render QA、approval store、structured event、shutdown recoveryを同じ話として扱う。成果物の安全性は、promptに「注意して」と書くことではなく、実行基盤側で検査し、止め、記録し、再配送できるようにすることだ。

AIがきれいな成果物を出せるだけでは足りない。壊れたときに追える、止められる、直せる。この運用品質こそ、エンタープライズで効く。

成果物は生成ファイルではなくartifact recordとして扱う

AIエージェントが作る成果物は、Slack返信、Markdown、PPTX、画像、PDF、CSV、Git diff、PR、外部SaaSの下書きなど多様になる。これを単なるファイルとして扱うと、後から追えない。

そこで、成果物にはartifact recordを持たせる。

{
  "artifactId": "art_...",
  "jobId": "job_...",
  "kind": "proposal_deck",
  "storage": {
    "type": "workspace-file",
    "path": "masked-artifact-path"
  },
  "status": "ready_for_review",
  "qualityGate": {
    "rendered": true,
    "linkChecked": true,
    "securityScan": "passed"
  },
  "approval": {
    "required": true,
    "state": "pending"
  }
}

Slackには要約とリンクだけを返す。詳細なログ、元データ、生成途中のファイル、検証結果はartifact recordへ紐づける。これにより、ユーザーはSlackで判断でき、管理者は後から監査できる。

safety gateはpromptではなく実行基盤に置く

AIに「危ない操作をしないで」と指示するだけでは不十分だ。安全性はpromptではなく、実行基盤のgateとして置く。

read-onlyや内部下書きは自動実行できる。外部送信、公開反映、契約、請求、削除、PR mergeは承認を挟む。ブラウザログインや2FAも人間が操作し、認証情報をSlackや長期記憶へ保存しない。ここまで実行基盤で止めるから、AIエージェントを社内に入れられる。

observabilityはevent schemaから始める

運用で必要なのは、LLMの最終回答だけではない。どのrouteを選んだか、どのworkerで動いたか、どのtoolを呼んだか、どのquality gateで止まったかを追える必要がある。

{
  "event": "agent.job.completed",
  "jobId": "job_...",
  "route": "normal-cli-agent",
  "workerId": "masked-worker",
  "threadKey": "masked-thread",
  "durationMs": 482000,
  "tools": ["file-write", "browser-check", "image-generation"],
  "artifacts": ["art_..."],
  "memoryWrite": "summarized",
  "result": "success"
}

このevent schemaがあると、失敗率、平均実行時間、よく使われるスキル、承認待ちで止まる比率、成果物の再生成率を見られる。AIエージェント基盤は、作って終わりではない。観測できるから改善できる。

品質ゲートは成果物ごとに変える

記事なら表現品質、AI定型句チェック、リンク確認、サムネイル寸法確認が必要になる。PPTならレンダリング、ページ崩れ、画像欠落、フォント、PDF化の確認が必要になる。コードならテスト、型チェック、差分レビューが必要になる。

成果物の種類ごとにquality gateを持たせると、AIエージェントは「出力したら終わり」ではなく「検証してから返す」動きになる。ここが、社内PoCと実運用の差になる。

提案資料生成はartifact pipelineとして扱う

成果物生成で一番危ないのは、最後のファイルだけを見て成功扱いにすることだ。提案資料のような成果物は、構成、本文、ビジュアル方針、PPTX、レンダリング画像、目視QA、修正版、最終添付までをpipelineとして扱う。

段階検査するもの
storyline読み手、目的、勝ち筋、ページ構成
content matrix各ページの主張、根拠、図表、話す内容
visual planトーン、レイアウト、画像、禁則
render QA文字あふれ、重なり、画像欠け、ページ抜け
deliverySlack添付、再添付用manifest、説明文

これにより、AIがPPTXを出しただけで終わらない。レンダリングして崩れを見る。必要なら再生成する。最終成果物だけでなく、中間artifactも残す。後から「どの段階で品質が落ちたか」を追える。

shutdown時にも監査線を切らない

AIエージェントは長時間動く。デプロイ、プロセス停止、CLIの異常終了は必ず起きる。shutdown handlerでは、active requestをinterruptedとして保存し、Slackへ停止通知を出し、復旧可能なrecordを残す。

このとき大事なのは、失敗をきれいに隠さないことだ。途中で止まったなら、どのrequestが、どのrouteで、どのworker上で、どのartifactまで進んだのかを残す。完全な監査DBでなくても、JSONL、recovery store、thread directory、artifact manifest、Slack threadをつなげれば実運用ではかなり追える。

安全性は「禁止事項を増やすこと」だけではない。止まったときに戻れる、間違ったときに追える、外部副作用の前で人間に渡せる。この3つが揃うと、AIエージェントを業務の中へ入れやすくなる。

関連記事

連載「Slack AIエージェント基盤を作る」

  1. 第1部 Slackを業務OSにする
  2. 第2部 CLIをサーバーに上げる
  3. 第3部 並行実装を回す
  4. 第4部 Slack発言をジョブ化する
  5. 第5部 意図理解で振り分ける
  6. 第6部 記憶を設計する
  7. 第7部 定期実行で運用する
  8. 第8部 安全性と観測性を固める
  9. まとめ Slack AIエージェント基盤の全体設計

あわせて読みたい既存記事

#AIエージェント#社内導入#安全性#観測性#成果物管理

成果物管理と安全ゲートを整えませんか？

Atsumellは成果物レコード、承認フロー、観測イベントまで含めて、社内導入できるAIエージェント基盤を支援できます。

相談する

関連記事

定期実行で動くAIエージェントの運用設計

【第7部】定期実行で動くAIエージェントを運用する

AIエージェントの要件定義で停止条件を権限・状態・不確実性で整理した図

AIエージェントの要件定義で停止条件はどう決めるか

AI社員の役割分担を示す図

AI社員の役割分担は3層で決める

← BLOG一覧に戻る