AIエージェントから
「報告を受ける場所」を作る

それが、

「AIから、どうやって報告を受けるのか？」

という問題です。

AIに仕事を任せるなら、「何をやらせるか」だけではなく、仕事が終わったあと、どこへ報告させるのかまで考えておく必要があります。

1. AIから報告を受ける場所がない、という問題

Claude CodeやCodexなど、対話セッションを中心に使うAIは、AI側から継続的に報告してくる仕組みが弱いという問題があります。

たとえば、

「この件を調査しておいて」

「エラーの原因を調べて」

「処理が終わったら報告して」

と依頼すると、

「承知しました。完了したら報告します」

と返してくることがあります。

しかし、そのやり取りをしていたセッションを閉じてしまえば、通常、そのAI担当者が後から勝手に新しいセッションを立ち上げて、

「先ほどの調査、終わりました」

と呼びに来るわけではありません。

結局こちらから新しいセッションを開いて、

「あの件どうなった？」

と確認することになります。

もちろん、現在はChatGPTの「スケジュール」のように、指定した時刻や条件で処理を実行し、後から通知を受け取れる機能もあります。またCodexには別にAutomationsがあります。

ただ、普段AI担当者へ仕事を依頼する対話セッションそのものに、会社の報連相のような仕組みが自動的に備わっているわけではありません。

本格的にAIエージェントを業務へ組み込むなら、

「AIから人間への報告経路」

を用意する必要があります。

2. AIの報告先には何を使えばいいのか

候補はいろいろあります。

• Gmail
• LINE
• Chatwork
• Slack
• Teams
• Discord
• 自社システム
• 専用の管理画面

どれが正解というわけではありません。

会社ですでに使っているツールや、AIをどの程度業務へ組み込みたいかによって変わります。

簡単に比較すると、こんな感じです。

以前よく使われていたLINE Notifyは、2025年3月31日にサービスを終了しています。現在LINEから自動通知するなら、LINE公式アカウントのMessaging APIなどを利用する形になります。

ChatworkにもWebhookがあるので、外部システムと連携して通知やBotの仕組みを構築できます。

GmailにもAPIがありますが、AI担当者と頻繁に会話する「仕事場」というより、重要通知や正式な報告を受け取る用途の方が向いていると思います。

3. 当社はSlackを選んだ ── AI社員が働くオフィスにする

当社では、AI担当者との報連相の場所としてSlackを選びました。

考え方は単純です。

人間の社員がSlackで、

「作業完了しました」

「確認お願いします」

「この件どうしましょう？」

と報告するのであれば、

AI担当者にも同じことをさせればいい。

という発想です。

現在、当社では11人のAI担当者が動いています。

Amazon担当、楽天担当、受注担当、経理担当、本店担当、発注担当、商品担当、Yahoo担当、情シス担当、マネージャー、素材担当です。

さらに、この11人とは別系統で、AIの仕事をチェックする監査担当も存在します。

そして担当ごとに、

• #ai-amazon
• #ai-受注
• #ai-情シス

といった専用チャンネルを持たせています。

11の担当チャンネルに加えて、全体用の#ai-全体もあります。

つまりSlackを、

「AI社員が働くオフィス」

のように使っています。

4. AI担当者に名前と顔アイコンを持たせる

当社では、すべての報告を同じBot名で表示するのではなく、AI担当者ごとに名前と顔アイコンを表示しています。

これは機能的には必須ではありません。

しかし実際に運用すると、かなり重要でした。

Slackを見た瞬間に、

「経理担当からの報告だ」

「Amazon担当から警告が来ている」

と視覚的に分かるからです。

単なる、

SYSTEM BOT

からの通知が大量に並ぶより、ずっと理解しやすくなります。

AI担当者を擬人化すること自体が目的なのではなく、

誰の担当業務から来た報告なのかを、一瞬で識別するためのUI

として機能しています。

ここは、実際に同じ仕組みを作ろうとすると少し注意が必要です。

SlackアプリのIncoming Webhookでは、投稿ごとに表示名やアイコンを自由に上書きすることは基本的にできません。AI担当者ごとに名前やアイコンを切り替えて投稿するなら、chat.postMessageを利用し、chat:write.customizeの権限を設定する方法があります。

当社が作った5つの仕組み

Slackへ投稿できるようにするだけなら、それほど難しくありません。

しかし、それだけでは、

「AIから通知が飛んでくる仕組み」

でしかありません。

AI担当者として運用するため、当社ではそこから5つの仕組みを作りました。

最初に決めたのが、

「いつ報告するのか」

です。

当社では大きく3種類あります。

適時報告

指示された仕事が一区切りしたら、その都度報告します。

何件も仕事をためて、最後にまとめて報告することは禁止しています。

人間の社員と同じで、

「そこまで終わっていたなら早く教えてよ」

をなくすためです。

日次報告

その日行った仕事を、1日1回まとめます。

定期報告

一部の担当については定期報告もあります。

Amazon担当は毎週月曜日、取引先との共有チャンネルにも週報を出します。

AI担当者からの報告が増えてくると、Slackが投稿だらけになります。

そこで当社では、新規投稿とスレッド返信を使い分けています。

• 定時報告・新しい承認依頼
  → 新規メッセージ
• その案件についての途中のやり取り
  → スレッド返信
• 作業完了・人間の判断が必要な重要事項
  → スレッド返信＋チャンネルにも表示

というルールです。

これによって、一つの案件に関する会話がバラバラになりにくくなります。

AIに自由にSlackへ報告させると、かなり読みにくくなります。

たとえば、

「Process completed successfully. rc=0」

「○○というファイルを実行しました」

などと報告されても、普通の社員にはほとんど意味がありません。

そこで当社では、

「Slackを読むのは非エンジニアの社員」

という前提で報告ルールを作りました。

基本は、

1行目に結論。本文は原則5行以内。

さらに、

• コマンドを書かない
• ファイルパスを書かない
• 長いエラーログを貼らない
• 専門用語をできるだけ使わない
• 略語は正式名称で書く
• 数字には単位と意味を付ける

というルールにしています。

たとえば、

「116」

ではなく、

「受注116件」

と書かせます。

絵文字も状態を示す目印程度です。

• ✅ 正常
• ⚠️ 注意
• 🚨 異常
• 🔔 確認依頼

人が書く投稿だけでなく、スクリプトからの自動通知も同じルールにしています。

失敗通知だからといって大量のログをSlackへ貼らず、原則4行以内で人間に分かる内容へ変換します。

以前は「読み飛ばしていい詳細」というブロックも作っていましたが、現在はやめました。

読み飛ばしていい情報なら、最初から送らない。

という考え方です。

AIが出した情報を人間が解読する時間も、立派な業務コストだからです。

ここまでなら、

という一方通行です。

さらに当社では、

も作りました。

担当チャンネルでBotをメンションして、

「昨日の受注件数を調べて」

と書くと、受付プログラムが投稿を検知し、その担当のAIが動き始めます。

つまりSlackそのものが、

AI担当者への仕事の依頼窓口

になります。

単に通知を受ける場所ではなく、仕事を渡して、回答を受け取る場所になっています。

SlackからAI担当者へ仕事を依頼できるようになると、次に問題になるのが、

AIにどこまで勝手に実行させるか

です。

当社でも導入初期は、まず読み取り専用から始めました。

調査する。

数字を数える。

分析する。

こうした作業だけを行わせ、実際のデータや設定を変更する作業は人間が行います。

そこから運用を進め、現在は、

危険な領域だけ人間の承認を必要とする

方式にしています。

たとえば、

「先月のAmazon広告費を調べて」

なら、そのままAI担当者が調査します。

しかし、

「この広告を止めて」

となると、勝手には止めません。

まず、

[要承認]

として、

• 何をするのか
• どこに影響するのか
• 金額はいくらなのか
• 何件対象なのか
• 元に戻せるのか

などを報告します。

人間がSlackのスレッドで承認すると、初めて実行します。

また、「承認」という文字が入っていれば何でも実行するわけではありません。

「○○のみ」

「○○ではなく」

など、範囲変更や訂正が含まれている返信は承認とはみなしません。

以前、範囲を狭めるための訂正を承認と誤読しかけたためです。

承認依頼についても、1スレッド1件を基本としています。

運用して分かったこと

実際にSlackをAI担当者の仕事場として使ってみると、通知を飛ばせるようにしただけでは分からなかった問題も見えてきました。

何でも承認制にするとAIを入れた意味がなくなる

安全だからといって、

「AI担当者が何かするたび全部承認」

にすると、人間が毎回確認することになります。

これではAIを導入したのに仕事が減りません。

そこで当社では、承認を必要とする領域を5つに絞っています。

• 削除
• お金
• 社外への発信
• 会社方針
• 仕組みそのものの変更

逆に、

調べる。

数える。

分析する。

下書きを作る。

といった作業は原則としてAI担当者だけで進めます。

目指しているのは、

AIを止める仕組みではなく、危ないところだけ人間が握る仕組み

です。

Slack経由で「かみ合わない」のはコンテキストの問題

これも実際に作ってみて分かりました。

Claude CodeやCodexを直接開いて会話している場合と比べて、SlackからAI担当者へ指示すると、

「少し遅い」

「会話が微妙にかみ合わない」

と感じることがあります。

仕組みとしては、

という経路になります。

しかし、

Botを挟むからAIの能力そのものが落ちる

という理解は正確ではありません。

重要なのは、

AIへ何の情報を渡しているか

です。

AIを直接使っているときには、

直前の会話。

作業中の情報。

過去の指示。

現在の状態。

など、さまざまなコンテキストをAIが参照できる場合があります。

ところがSlackから、

「さっきの件、それでお願いします」

という一文だけをAIへ渡しても、AIには「さっきの件」が分かりません。

つまりSlack連携で重要なのは、

Slackの文章をAIへ転送することではなく、仕事に必要なコンテキストまで一緒に渡すこと

です。

ここを作り込むほど、直接AIと会話している感覚に近づいていきます。

Slackでの指示をAIの恒久ルールへ反映する

もう一つ重要なのが記録です。

Slackから、

「今後、この処理では○○してください」

とAI担当者へ指示したとします。

ところが、そのSlack上の会話だけで終わってしまえば、次回また同じ間違いをする可能性があります。

そこで当社では、Slackで受けた指示と、その後の対応も記録します。

そして、

「今後は必ずこうする」

という恒久的な指示については、担当AIのマニュアルへ反映します。

つまり、

という構造です。

ここまで来るとSlackは単なる通知ツールではありません。

AI社員を育てる場所

にもなってきます。

ただし、誰でも恒久ルールを書き換えられるのは危険です。

そのため当社では、恒久ルールを変更できる人間を制限しています。

「正常です」は通知しない

AI担当者や自動化が増えてくると、今度は通知だらけになります。

たとえば毎時間、

• ✅ サーバー正常
• ✅ バックアップ正常
• ✅ API正常
• ✅ データ取得正常

と送っていたら、そのうち誰もSlackを見なくなります。

そこで当社では、

正常なものは基本的に通知しない

という方針にしています。

異常が起こったときだけ鳴らします。

担当AIが日報で報告している内容を、別の自動プログラムから重ねて通知することもしません。

ただし、一つだけ例外があります。

毎朝の起動点検です。

これは正常でも1本だけ通知します。

なぜなら通知がまったく来なかった場合、

「正常だから通知がない」

のか、

「通知する仕組みそのものが死んでいる」

のか区別できないからです。

この朝の1本だけは、

見張り役そのものが生きていることを確認する生存信号

として残しています。

そのほか、設定の差分チェック、API期限の点検、共有リポジトリの見張りなどについても、基本的には問題があるときだけ通知する考え方です。

初心者はいきなりここまで作らなくていい

ここまで読むと、

「AIエージェント導入って大変そう」

と思うかもしれません。

しかし、最初から当社のような仕組みを全部作る必要はありません。

私は3段階で作ればいいと思います。

まず、

だけ作ります。

「作業完了」

「エラー発生」

「確認が必要」

これだけ届けば十分です。

最初は一方通行で構いません。

次に、

にします。

SlackでAI担当者へ仕事を頼み、回答を受け取れるようにします。

ここで、

チャンネル。

スレッド。

報告フォーマット。

といったルールを整えていきます。

最後に、

担当制。

権限管理。

承認ゲート。

履歴。

記憶。

日報。

異常監視。

などを追加します。

ここまで来ると、

「AIを使っている」

というより、

AIが会社の業務フローの中にいる

状態になります。