Slackから依頼し、専用PC上のAIエージェントへ仕事を任せる構成は作れます。ただし、既製のSlack連携やRemoteで足りる場合もあります。利用できる方式を選び分けたうえで、待ち行列、隔離、仕事、承認、復旧を実装する順番に説明します。
既製連携と自作を選び分ける
2026年8月時点で、SlackやスマートフォンからAIへ仕事を渡す方法は三つあります。
OpenAIの公式Slack連携は、@Codexへの依頼からCodexのクラウド会話を起動し、GitHubリポジトリと実行環境を選んでコーディング作業を進めます。実行場所はCodexのクラウドであり、自宅や社内の専用PCをSlackから直接操作する仕組みとは別物です。1
Codex Remoteは、スマートフォンから接続済みのMacまたはWindows PCを選び、そのPC上でコーディング作業を開始、誘導、承認、確認する仕組みです。変更ファイル、変更差分、テスト結果まで確認できるため、目的が自分のPC上のコーディング作業なら、Slackボットを自作する前にこちらで足りるかを確かめます。利用可否は提供状況と組織の設定に依存します。2
自作のSlack＋専用PCが必要なのは、記事制作、社内データ処理、変換道具、独自業務システムなど、既製連携の範囲外を一つの仕事として動かす場合です。自由度と引き換えに、送信者確認、待ち行列、隔離、秘密、承認、監査、復旧を自分で持ちます。
| 方式 | 実行場所 | 向いている仕事 | 自分で持つ範囲 |
|---|---|---|---|
| Codex in Slack | Codexのクラウド会話 | GitHub上のコーディング作業 | 実行環境とリポジトリ設定 |
| Codex Remote | 接続した自分のPC | 手元環境を使うコーディング作業 | PCの接続と権限 |
| 自作Slack実行機 | 専用PC／VM | 独自の道具を使う業務 | 入口から監査・復旧まで |
Slackを指示面に限定する
自作する場合も、Slackの役割は指示面に限ります。人が依頼を渡し、追加情報を与え、承認し、状態と結果を受け取る窓口であり、エージェントが実際に仕事をする場所は専用PC側です。専用チャンネル、明示的なメンション、依頼可能利用者の許可一覧、スレッド単位の仕事番号を入口で確定します。DMと共有チャンネルの履歴を同じ実行状態へ混ぜません。
Events APIでは、アプリが購読したイベントだけを受け取り、見えるイベントはOAuthの権限範囲と結び付きます。Socket Modeなら専用PC側からWebSocketを張るため、公開HTTP受信口を用意せずに始められます。ただし接続は数時間ごとに更新され得るため、切断と再接続が前提です。34
イベントを受け取った処理の中で長いAI処理を始めてはいけません。SlackはHTTP方式で3秒以内の応答と待ち行列への分離を推奨し、Socket Modeでも各受信単位の受信確認が必要です。event_idまたはenvelope_idを保存して重複を除き、受信確認後に仕事の待ち行列へ渡します。Slackへ返すのは状態、要約、成果物への参照だけにし、秘密や長大な記録を自動掲載しません。
専用PCを実行面として隔離する
専用PCには、CLIエージェント、作業リポジトリ、隔離ブラウザ、変換道具を置きます。専用機にする理由は、常時起動に加えて、普段使う個人PCからファイル、Cookie、SSH鍵、クラウド認証、失敗時の影響を切り離すことにあります。
最低限、専用OSの専用利用者と専用作業領域を使います。個人のホームフォルダ、写真、パスワード管理ソフト、通常ブラウザプロファイルは見せません。ブラウザは業務専用プロファイルか仕事ごとに破棄できる環境にし、シェルの書き込み先を作業領域へ限定します。ネットワークも必要な接続先ドメインとHTTPメソッドだけへ絞ります。
Codexの非対話実行はcodex execとして自動処理や定期処理から起動できます。2026年8月時点の公式文書では既定が読み取り専用の隔離環境で、編集にはworkspace-writeを明示します。JSONLでコマンド、ファイル変更、MCP経由の道具の呼び出し、エラーなどのイベントを取得でき、構造化出力も形式で固定できます。5 自動化しやすいことと、端末全体を自由に操作させてよいことは別です。
一つのボットを役割ごとに分ける
構成は指示面、実行面、権限面、監査面の四つです。
- 指示面：Slackアプリ、メンション、スレッド、依頼者の識別
- 実行面：専用PC、CLIエージェント、ブラウザ、作業領域、仕事の待ち行列
- 権限面：OSの専用利用者、道具の利用規則、OAuthの権限範囲、ネットワーク、承認
- 監査面：依頼、計画、参照元、コマンド、変更差分、承認、結果
Slackイベントを受けた管理機構は送信者とチャンネルを検証して仕事を待ち行列へ入れます。実行機は仕事ごとに新しい作業領域を作り、必要なスキルと道具だけを読み込みます。成果物はファイルとして保存し、元スレッドへ返すのは要約と確認事項だけです。
公開、送信、削除、購入のような副作用は、Slackのボタンや明示的な返信で再承認された後、別の実行として行います。調査の仕事が持つ読み取り権限と、公開の仕事が一度だけ使う書き込み権限を分けます。
この形の利点は、エージェントをCodexから別のCLIや実行環境へ替えても、入口、待ち行列、権限、監査の設計を残せることです。製品名よりも、仕事の管理機構と規則を自分で保持していることに価値があります。
仕事を状態機械として保存する
仕事を安全に再開するには、Slackのスレッドの会話履歴とは別に、仕事そのものの記録が必要です。仕事の記録には、仕事番号、依頼者、スレッド、スキルの版、入力成果物、現在状態、試行回数、予算、作業領域、生成成果物、承認待ちの外部操作、最終結果を保存します。
状態はreceived、queued、running、needs_input、needs_approval、succeeded、failed、cancelled程度へ明示し、実行機が落ちてもrunningのまま放置せず、処理権の期限切れで待ち行列へ戻します。外部操作には二重実行を防ぐ識別子を付けるため、再試行してもメッセージ送信や公開は二重になりません。
Slackのスレッドの時刻印は会話の参照、event_idは受信イベントの重複排除、仕事番号は業務実行の追跡に使います。三つは同じIDへ潰さず、対応表で結ぶ別々の識別子です。
| 状態 | 意味 | Slackへ返す内容 |
|---|---|---|
queued | 実行待ち | 受け付けた／仕事番号 |
running | 専用PCで処理中 | 現在の工程／中止方法 |
needs_input | 情報不足 | 不足項目だけ質問 |
needs_approval | 外部操作の直前 | 対象・差分・公開範囲 |
succeeded／failed | 完了または失敗 | 成果物／原因／再試行可否 |
一件の記事更新を専用PCで追う
利用者がSlackで「指定した三つの公式発表を確認し、記事の古い数字を直して」と依頼したとします。入口は送信者、チャンネル、添付URLを検証し、仕事番号を返してqueuedへ入れます。専用PCが空いたら仕事ごとの作業領域を作り、渡すのは記事の現在版、許可された三つのURL、編集スキルだけです。
実行機は原文と根拠を保存し、数字を構造化して照合し、記事の変更差分と確認メモを成果物へ出します。URLの一つへ接続できなければ、推測で埋めずneeds_inputへ移し、取得できなかった資料と必要な対応だけを元スレッドへ返します。PCが途中で切断しても、取得済み資料と変更前の版が残っているため、別の実行が同じ仕事番号から再開できます。
差分が完成しても、公開権限はありません。Slackには変更した数字、根拠、見出し、差分への参照を出し、needs_approvalで止めます。人が承認した正確な差分だけを別の公開仕事へ渡します。承認後に記事が他の人によって更新されていれば、その版の違いを検出して再承認へ戻し、古い差分を上書きしません。
この一件から分かるのは、Slackの会話とAIの推論は全体の一部だということです。入力の固定、専用作業領域、成果物、版の照合、状態遷移、承認対象の固定まで揃って、初めて離れたPCへ仕事を委任できます。ボットが「できました」と返すことではなく、根拠と差分から人が完了を検証できることが終了条件です。
スキルと成果物で仕事を再現する
AI編集者やAI調査員という職務名だけでは、挙動を再現できません。スキルには、受け取る入力、利用できる資料、工程、判断基準、成果物の形式、停止条件を書きます。記事調査なら、一次情報を優先し、事実と推測を分け、確認日とURLを残し、公開前に人の確認を待つところまで定義します。
中間結果の置き場所はSlack本文ではなく、作業領域またはオブジェクトストレージです。調査メモ、引用候補、差分、テスト結果、最終ファイルを成果物として分けて保存し、ハッシュ値と作成仕事を記録します。スレッドには成果物への参照と短い要約だけを返します。
スキルは作業手順であり、強制境界ではありません。版とハッシュ値を固定し、仕事の記録へ残します。実行を止めるのはOS権限、隔離環境、道具の利用規則、承認です。7
秘密と外部操作を実行機から外す
よくある誤りは、.envやブラウザのCookieを実行機が自由に読める場所へ置くことです。Slackボット用トークン、CMS、GitHub、メールは用途別に分け、管理機構または認証情報の仲介機構が保持します。調査の仕事には読み取りだけ、公開承認後の実行には短時間の書き込み権限だけを渡します。
調査、手元ファイル生成、テスト、差分作成は隔離環境内で自動にできます。外部メッセージ送信、記事公開、顧客データ更新、削除、権限変更はneeds_approvalで停止します。承認表示には、誰の依頼で、何を、どこへ、どの差分と公開範囲で行うかを示し、承認後に引数が変わったら再承認へ戻します。
Web、メール、Slackへ貼られた文面は未信頼入力です。読む仕事と書く仕事を分け、元の未信頼文を公開処理用の実行機へそのまま渡しません。ネットワークも接続先ドメインとHTTPメソッドを絞り、外部からのプロンプトインジェクション、認証情報の流出、悪意ある依存関係の取得をモデルの注意力だけに任せません。67
小さな仕事から運用を始める
運用は、成功条件が明確な小さな仕事から始めます。指定した一次情報源の更新候補を出す、出典付き調査メモを作る、問い合わせを分類して返信案だけ作る、修正変更差分をテスト結果と一緒に確認へ出す、といった仕事が出発点で、最初から万能な常駐ボットを目指す必要はありません。
各仕事には最大実行時間、道具の最大使用回数、費用上限、停止条件、再試行回数を持たせます。監査記録で結ぶのは、Slackイベント、スレッド、仕事、スキルの版、参照元、実行操作、成果物、承認者、外部の最終結果です。中止、PCの切断、ネットワーク障害、実行機の停止、承認期限切れを実際に起こし、再開と二重実行防止を確認します。
AI社員の正体は人格ではなく、管理された委任です。誰が指示できるか、どの環境で、何を読めるか、どこまで自動で動くか、どの証跡を残すかに答えられる構成なら、仕事を安全に増やせます。ずっと動くことより、一件の仕事を後から説明し、止めて再開できることの方が重要です。
自作を維持しない条件
専用PCの運用では、OSと依存関係の更新、Slack接続の再確立、認証情報の更新、ディスク容量、スリープ復帰、失敗した仕事の確認、監査記録の保管を購入後も持ち続けます。夜間に動くことが価値でも、翌朝に失敗を説明できる担当者は必要です。
既製連携へ戻すか、クラウドの管理実行へ移すかは、次の条件で判断できます。対象がGitHub上のコーディングに限定され既製連携で要件を満たす、専用PC固有の道具を使わない、接続停止が業務の期限を頻繁に超える、認証と監査の保守時間が人の手作業時間を上回る、複数利用者の分離が一台では難しい場合です。
反対に、社内ネットワーク内の装置、ローカルの大容量データ、特定OSのアプリ、物理的な機器へ接続する必要があり、その境界を自社で管理したいなら専用PCの理由が残ります。その場合も、入口と仕事の記録はPCの外へ置き、機械が壊れても別の実行機へ仕事を移せるようにします。
自作の採否はAI利用料だけで比較しません。月ごとの保守時間、失敗から復旧する時間、期限内完了率、手動介入率、使われていない待機時間を記録します。専用PCが目的ではなく、独自の仕事を必要な境界で実行することが目的です。既製機能が同じ境界と証跡を提供するようになれば、構成を小さくする方がよい場合があります。
