AI社員の作り方｜監査ログで残す7項目
目次
はじめに
「ログは出ます」と聞いたのに、検収会で見ると日時と成否しかない。誰の依頼か。どの権限を使い、何を変更したか。発注側が知りたいことには答えられなかった。
AI社員の作り方で難しいのはデモではない。顧客データの更新や外部送信を、説明できる仕事として納品することだ。
開発側だけが見る情報では検収できない。項目、改ざん防止、閲覧者、保持、受入条件まで合意する。
AI社員の作り方は監査ログの検収条件から考える
監査ログは、CPUやエラー率を見る監視とは役割が違う。AIエージェントの監視で残す5つのログが本番の変化を見つける設計なら、今回はSIerが顧客へ渡す証拠と合否に絞る。
カナダ政府のAgentic AI利用ガイドは、ツール、操作、承認、主要な入出力を記録し、名称、時刻、結果、パラメータの種類を残すよ う求める。生の値は必要な場合だけにする。
項目表、イベントスキーマ、権限表、保持方針、受入テストを成果物にする。
納品仕様にする7つの記録分類
7分類は、依頼主体、目的・対象、使用権限、判断根拠、操作、承認、結果・追跡情報である。
1. 依頼主体
`requested_by` で依頼した人やシステムを特定する。社員IDやサービスIDを使い、定期実行の責任者は `owner_id` で分ける。
所有者が無効なら、仕事を開始せず再割り当てを待つ。
2. 目的・対象
`purpose` と `target_refs` は、目的と対象を「商談後7日を過ぎた案件の担当確認」のような業務単位で残す。
対象は案件IDや文書IDで参照し、顧客名や本文を複製しない。対象外の案件は拒否し、その記録を残す。
3. 使用権限
`permission_scope` は実際に使った権限を残す。読み取り、送信、削除は分け、`tenant_id` で他社分との混在を防ぐ。
権限境界は社内AIエージェントの権限設計と対応させ、別テナントは参照段階で止まることを試す。
4. 判断根拠
`evidence_refs` は規程や仕様の識別子と版を持つ。`runtime_versions` にはモデル、指示、設定、ツールの版を残す。
長い思考過程は要らない。客観的な参照先を残し、資料更新後も実行時の版を特定できるか試す。
5. 操作
`actions` はツール、操作、対象、時刻、成否を持つ。更新系は `before_ref`、`after_ref`、`rollback_ref` を必須にする。
OWASPのLogging Cheat Sheetは、「いつ・どこで・誰が・何を」と、操作対象、結果、理由、識別子を記録候補にする。AIが使うAPIでも同じだ。
6. 承認
`approval` は承認要否、判断、承認者、内容のハッシュを持つ。却下も残す。
契約送信、支払い、本番変更、個人情報の外部共有は人間へ戻す。AI社員の停止条件と同じ境界を使う。承認後に内容が変われば拒否する。
7. 結果・追跡情報
`outcome` は技術的な成否と業務上の合否を分ける。APIが200でも誤更新なら不合格だ。成果物、エラー分類、復旧状況も結ぶ。
`trace_id` は依頼、根拠、承認、操作、成果物をつなぐ。同じIDで1件の経緯を取得できることを検収する。
そのままレビューできるイベント例
7分類をJSONへ落とす。個人情報や秘密値は入れず、安全な正本を参照する。
{
"trace_id": "job-20260910-0042",
"tenant_id": "tenant-a",
"requested_by": "employee-184",
"owner_id": "sales-ops-manager",
"purpose": "商談後7日経過案件の担当確認",
"target_refs": ["crm-opportunity-8921"],
"permission_scope": ["crm:opportunity:read", "crm:note:write"],
"evidence_refs": ["sales-rule:v3.2", "meeting-note:447"],
"runtime_versions": {
"model": "model-release-2026-09",
"prompt": "sales-followup:v4",
"agent_config": "sales-agent:v7",
"tool": "crm-connector:v2.3"
},
"actions": [{
"tool": "crm",
"operation": "append_note",
"target": "crm-opportunity-8921",
"occurred_at": "2026-09-10T09:04:18+09:00",
"status": "success",
"before_ref": "snapshot-8820",
"after_ref": "snapshot-8821",
"rollback_ref": "rollback-551"
}],
"approval": {
"required": true,
"decision": "approved",
"approved_by": "manager-021",
"decided_at": "2026-09-10T09:03:51+09:00",
"approved_payload_hash": "sha256:example"
},
"outcome": {
"technical_status": "completed",
"business_status": "accepted",
"artifact_ref": "drive-file-551"
}
}必須値が欠けたイベントは保存しない。承認内容と実行内容のハッシュが違えば止める。この制約まで実装する。
非機能要件は4点を別紙にしない
後から書き換えられたり他社分が見えたりすれば監査には使えない。次の4点も同じレビュー対象にする。
| 非機能要件 | 最低限決めること | 検収の例 |
|---|---|---|
| 完全性 | 追記専用、削除権限の分離、改ざん検知 | 過去イベントの更新要求を拒否し警告を残す |
| 時刻 | UTC保存、表示時のタイムゾーン、時刻同期 | APIと承認画面の順序を追跡IDで復元できる |
| 分離 | テナントID、閲覧権限、ログ閲覧自体の記録 | 別テナントの検索結果が0件になる |
| 保持 | 種別ごとの期間、法令・契約、削除手順 | 期限後に詳細値だけ削除し証跡を残す |
MicrosoftのAgent Governance Whitepaperは、時刻、利用者、プロンプト、応答の記録を調査や事故対応に使う。NIST SP 800-92は、生成、送信、保存、分析、廃棄を組織的な管理として捉える。
保存期間は契約、法令、元データの方針に合わせる。マスク済みイベントと制限された原本を分ける。
要件定義から運用までの成果物をそろえる
SIerが「監査ログ対応済み」と言える状態は、実装コードがあるだけでは足りない。工程ごとの合意物をそろえる。
| 工程 | 発注側が決めること | 開発側が示すもの |
|---|---|---|
| 要件定義 | 対象業務、責任者、承認境界、保持根拠 | 7分類の項目表とデータ分類 |
| 基本設計 | 閲覧者、テナント境界、復旧方針 | イベントスキーマ、保存構成、権限表 |
| テスト | 業務上の合否、重大な失格条件 | 正常・拒否・改ざん・越境・復旧の証跡 |
| 運用設計 | 点検頻度、事故時の判断者、廃棄承認 | 検索手順、警告、保持・削除手順 |
許可操作の成功、権限外操作、承認改ざん、別テナント参照、過去ログ変更の拒否、追跡ID検索、復旧参照をテストする。AIエージェントの受入テストと組み合わせ、説明可能性を合否にする。AIエージェントの開発標準にも同じ証跡を渡せる。
経済産業省のAIエージェントの導入に伴うセキュリティリスクへの対応も、役割に応じたリスク評価とガバナンスを論点にする。外部送信、個人情報、金銭、本番変更など、影響が重い仕事から厳しくする。
Atsumellの視点
Atsumellは、職種名より仕事の境界を先に構造化する。何を読み、どの権限で実行し、どこで人間へ戻すか。7分類は、その問いを実装と検収へつなぐ型になる。
「営業AI」「経理AI」という名前だけでは発注も検収もできない。1件の依頼を分け、権限、根拠、承認、結果を結ぶ。改ざん防止、時刻、テナント分離、保持まで決める。
役割や実行境界が曖昧なら、AtsumellではAI業務整理ツール「Kakusill」を使い、業務フロー、要件、権限、実行基盤、受入テストを一緒に整理している。失敗したら困る業務を1件選び、監査ログ仕様から相談してほしい。
