AI 社員 ─ エージェントに「身元」を持たせる話
はじめに
前回までの記事で、既存の .NET 資産を AI から呼び出せる形にし、サーバーとして常時稼働させる構成ができました。
しかし実際に動かし始めてすぐ、ある問題に気づきます。
「これ、誰がやったの？」
メールが届いた、ファイルが更新された、会議の招待が来た。そのアクションの主体が曖昧なままだと、受け取った側が戸惑います。
エージェントを「ツール」として扱う限り、この問題は解決しません。解決策は、エージェントを社内に身元を持つ「メンバー」として扱うことでした。
「ツール」と「メンバー」の違い
エージェントを「高機能な自動化スクリプト」として扱うと、アクションの主体は常に「誰かの代理」になります。
| 扱い方 | メールの送信者 | カレンダー招待の主催者 |
|---|---|---|
| ツールとして | 担当者 A さんの名前で送る | A さんのカレンダーを操作する |
| メンバーとして | エージェント自身の名前で送る | エージェントが主催者になる |
「メンバー」として扱うと、受け取った側は「AI からの連絡だ」と明確に分かります。A さんに「頼んだっけ？」と聞かなくてよくなります。
専用アカウントを作る
エージェントに身元を持たせる最初のステップは、専用アカウントを作ることです。
メールアドレス : ai-agent@example.com
表示名 : AI エージェント（または業務に応じた名前）
カレンダー : 上記アカウントに紐づく
チャット : 同アカウントで参加
このアカウントは、社内の通常メンバーと同じように各サービスに登録します。
- メール: 送受信できる状態にする
- カレンダー: 会議を作成・招待できる状態にする
- チャット: グループに参加でき、返信できる状態にする
「AI っぽい名前にするか、普通の名前にするか」という選択があります。実際に使ってみて、AI だと分かる名前の方が受け取る側の混乱が少ないという判断に落ち着きました。
プロジェクトのメンバーとして参加させる
専用アカウントができたら、業務で使う共有フォルダやプロジェクトスペースにもメンバーとして追加します。
共有ドライブ（Google Drive / SharePoint）
→ 編集者権限でメンバー追加
プロジェクトチャット
→ メンバーとして参加
会議室カレンダー
→ 予約できる状態にする
これにより、エージェントが「共有フォルダにファイルを置く」「会議を作って招待する」「チャットに返信する」といったアクションを、自分のアカウントで自然に行えるようになります。
人間のメンバーと同じ権限体系に乗せることで、既存のアクセス管理の仕組みをそのまま流用できる点も利点でした。
「誰がやったか」を残す
エージェントが自律的に動くほど、操作の追跡可能性（トレーサビリティ） が重要になります。
設計したのは次の3層です。
① 外部サービス上の記録
─ メール送信履歴（送信者: ai-agent@example.com）
─ ファイルの更新者（AI エージェント）
─ カレンダーイベントの主催者（AI エージェント）
② 完了記録（done.md）
─ 何を・いつ・誰の依頼で・何を成果物として実行したか
─ メッセージID・ファイルID・イベントIDで実在裏付け
③ 実行ログ（logs/）
─ Skill 名・入力パラメータ・実行結果・エラー詳細
特に「成果物のIDで実在裏付け」は重要です。「送りました」「作りました」という報告だけでは、本当に実行されたかが確認できません。メッセージID・ファイルIDなど、外部サービスが返す一意のIDを記録に残すようにしました。
注意点
権限は最小限に絞る
エージェントが「何でもできる」状態にするのは危険です。業務に必要な範囲の権限だけを付与し、それ以外はアクセスできない設計にします。
付与する | 付与しない
─────────────────────────────────
メール送受信 | 他のメンバーのメールを閲覧
会議の作成 | 他のメンバーのカレンダーを直接編集
共有フォルダの読み書き | 機密フォルダへのアクセス
「一度権限を広げると戻しにくい」という経験から、最初は狭く設定して、必要になったら広げる方針にしました。
「なりすまし」と明確に区別する
エージェントが人間の名義でメールを送ったり、人間のカレンダーを操作したりするのは「なりすまし」です。
今回の設計では、エージェント自身のアカウントで動かすことを原則にしており、人間の名義を使うケースは原則なしにしています。
受け取った側が「AIからの連絡か、人からの連絡か」を判別できる状態を保つことが、信頼の基盤になると考えています。
監査対応
エージェントのアカウントを通常メンバーと同じ権限体系に乗せているため、既存の監査ログにそのまま記録されます。「誰が（AI エージェントが）、いつ、何をしたか」が追跡できる状態を、追加の仕組みなしに確保できています。
まとめ
エージェントに「身元」を持たせることで、次のことが変わりました。
- ✅ 受け取った側が「誰からの連絡か」を即座に判断できる
- ✅ 操作の追跡可能性が確保される
- ✅ 既存のアクセス管理・監査ログの仕組みをそのまま使える
- ✅ 「A さんが頼んだのか確認しよう」という無用な混乱がなくなる
「ツールとして動かす」から「メンバーとして参加させる」への転換は、技術的な変更は小さいですが、運用上の効果は大きいと感じています。
次回は、このエージェントアカウントが各サービスに実際にどう接続するか ─ 認証の仕組みについて書きます。