ChatGPTとClaudeからSlack経由でdotsへ依頼する運用を組み立てる

この記事自体もdotsが執筆しています。dotsが本文と全5画像を制作し、私は事実整理、手元での独立検収、Zenn・Qiita・noteへの公開を担当する分担です。2026年10月4日時点の手元の運用記録と公式資料をもとに、再現するための手順をまとめます。

何を作るか

ChatGPTまたはClaude Codeで依頼を整理し、SlackのDMからdotsへ渡します。dotsは許可されたGitHubの指示書を読み、別の実行環境で作業し、branchとPR、同じ会話への報告を返します。ここで扱うdotsは私の環境の作業相手です。利用条件や内部の仕組みを推測して紹介する記事ではありません。

目標は、どちらのAIを使っても同じ仕事を追える形にすることです。そのため、会話だけに状態を持たせず、次の役割を割り当てています。

• 案件番号: 会話をまたいで対象を特定する
• 固定commitの指示書: 依頼時の要件と権限を特定する
• PROGRESS.md: 現在の工程、証跡、次の一手を示す
• Slackの同じスレッド: 依頼、受付、質問、修正をつなぐ
• 独立レビューと手元検収: 成果を受け取れるか確かめる

外側にはGitHubを読み取り専用で見る停滞監視を置きます。この監視で分かるのは更新の有無で、作業者の内部状態ではありません。

1. 案件番号と指示書を準備する

私の採番台帳では、repoと案件keyの組み合わせに番号を付けています。同じ組み合わせには同じ番号を返し、一度使った番号は再利用しません。GitHubのIssue/PR番号とは別です。「前の件」では対象が曖昧なので、短い番号を会話の頭に付けます。

対象repoには、次のような構成で文書を置きます。これは一般化した例で、そのままの名前を使う必要はありません。

docs/bot/<task-slug>/
├── README.md
├── REVIEW.md
└── PROGRESS.md

README.mdには目的、対象範囲、禁止事項、提出先branch、完了条件を書きます。たとえば文書制作なら、必要な原稿、画像の役割、出力形式、公開担当まで指定します。コードを依頼するなら、実装だけでなく試す条件と確認できない環境の扱いも必要です。

REVIEW.mdは独立して確認する観点です。実装者の自己申告だけではなく、別の担当が指示と成果の差分を見られるようにします。PROGRESS.mdは、次の列を持つ看板にしています。

工程 | 担当 | 状態 | 証跡 | 次の一手

「実装中」だけでなく、何を試してどうなったか、次に何をするかを残します。テストを通したcommit、実行したコマンドと結果、CI、未確認の範囲が証跡になります。看板へ認証情報や生ログを貼る必要はありません。

指示書をpushし、commitを固定します。依頼では固定commitのREADMEと、成果branchで更新される看板を別々に渡します。前者は読んだ版の照合に、後者は現在地の確認に使います。要件変更があれば新しい基準を明示し、会話の流れだけで古い基準を失効させないようにします。

2. ChatGPTからSlackへ送れるようにする

公式ヘルプに沿って、ChatGPTから接続したSlackを使う経路を設定します。Slack内で@ChatGPTに話しかける経路とは異なります。過去に私が操作した画面の記録はないため、以下は現在の公式案内と、送信を確かめるための手順です。経路の違い

1. ChatGPTの設定で「Plugins」、画面によっては「Apps」を開き、Slackを選びます。「Install plugin」がある場合は内容を確認して導入し、「Connect」へ進みます。接続手順
2. 投稿に使う本人のSlackアカウントと、dotsとのDMがあるワークスペースを選び、要求権限を確認して認可します。管理された環境ではSlackと必要なアクションが有効かも確認します。Slack側のポリシーにより、管理者承認や追加スコープの再認可が必要になる場合があります。Slackの設定と権限
3. ChatGPTの会話で、必要なら「@」や「＋」からSlackを指定します。自分宛てDMへ「ChatGPTからの送信テスト」を1通送るよう依頼し、確認画面が出たら宛先と本文を確認します。会話での使い方
4. 返されたリンクを開いて本文と投稿者を見て、ChatGPTにも読み戻してもらいます。その後、既に利用できるdotsとのDMへ1通送り、投稿のスレッドで返答を読みます。この順序は本記事で提案する動作確認です。

接続済みや検索成功だけで、投稿可能とは判断しません。私の環境では本人名義で送れましたが、読者の契約や組織で同じアクションが使えることまでは保証できません。

3. Claude CodeからSlackへ送れるようにする

Claude Code CLIが使え、対象Slackで連携が許可されていることを前提に、動作を確認できた公式MCPプラグインを使います。Slack公式の前提条件

1. 端末で claude plugin install slack を実行します。これは私が使ったコマンドで、Slack公式にも掲載されています。接続先は公式MCPサーバー https://mcp.slack.com/mcp です。導入手順
2. 導入後のClaude Codeで /mcp を開き、Slackサーバーを選んでOAuth認証を進めます。ブラウザでアカウント、ワークスペース、権限を確認します。私の画面では plugin:slack:slack と表示されました。MCP認証
3. 接続と利用できるツールを確認します。私の試行では認証前から開いたセッションにツールが出ず、新しいセッションで使えました。公式には新しい起動や /reload-plugins による読み込みが案内されています。プラグインの反映
4. 自分宛てDMへ1通送り、リンクと読み戻した本文を照合します。次に既に使えるdotsとのDMへ1通送り、返信スレッドを読みます。Slack MCPは送信と履歴・スレッド読み取りを提供しますが、使える範囲は認可に従います。MCPの機能

提供元まで明記する別の導入方法は、セッション内の /plugin install slack@claude-plugins-official です。どちらか一方の方法で導入します。現在の公式プラグイン

私の試行では追加の管理者承認は出ませんでした。ただし、必要な承認は各ワークスペースのポリシーや承認済みの範囲によって異なります。Slackのアプリ承認

最初に試したclaude.aiのSlackコネクタは、私の環境ではClaude Codeに現れず、原因は未特定です。公式にはclaude.aiのMCP接続を使う経路もあります。一般的に使えない仕様とはせず、今回は動作したプラグイン経路を紹介しています。公式の接続説明

4. 短い依頼を送り、受付を読む

接続を確認したら、Slackで「#番号 案件名」という親メッセージを作ります。以下は依頼に含める項目の例です。実際には自分の公開してよい情報だけを入れます。

#番号 案件名
対象repo、固定commitの指示URL、更新される看板URL
今回の範囲と触らない範囲、成果branch、PRのbase
指示を読んだcommitと、環境の実確認結果を受付で返す
成果SHAと証跡を同じスレッドで報告する

実際のURLやIDをこの記事に掲載しなくても、仕組みは説明できます。作業に必要な相手にだけ渡す情報と、記事として公開する説明は分けています。

受付の確認項目は、番号衝突、読んだcommit、必要な実行環境、提出先、実行できない工程です。「使えます」という一般的な返答だけでなく、依存取得やブラウザなど、その仕事で必要な経路を実際に試してもらいます。

私は送信成功、受付、テスト成功を別の証跡として扱っています。送信した本文を読み戻せても、作業の受付までは確認できません。受付の返信が来ても、その後の検査が通ったことにはなりません。区切りごとに確認した事実を増やしていきます。

dotsからの返信は、手元の観察では投稿したスレッドに付きました。トップレベルの履歴を取るだけでは見落とします。後続の質問も同じスレッドへ送り、番号に加えてrepoやIssueを指定します。ChatGPTから始めた仕事をClaude Codeで確認するときも、この参照先を引き継ぎます。

Slack上では、私の投稿として届き、利用した入口が「@ChatGPT」「@Claude」と表示されました。これはこの環境での送信結果です。表示の違いを権限の違いだと決め付けず、許可された宛先と操作を接続時に確認します。

5. 更新がないときは事実を見てから聞く

進捗は対象repoのPROGRESS.mdを確認します。それとは別に、非公開repoの読み取り専用スクリプトで、GitHub上のbranchの進み、開いているPR、CI、対象ラベルのIssue、直近の取り込み時刻を見ています。

既定では60分動きがないrepoを停滞として出します。この値は私の運用上の目安です。GitHub更新がない間に調査が進んでいることも考えられますし、承認や依存取得で待っているかもしれません。外側の監視だけで原因を確定しません。

停滞を見つけたら、次の順で確認します。

1. 対象branchに新しいcommitがあるか、PRやCIがどうなっているか読む。
2. 看板の最終更新と次の一手を照合する。
3. 同じ案件スレッドで、どの工程が何を待っているか尋ねる。
4. 補完が必要な場合はその工程だけを切り分け、再開先を決める。

監視から自動で同じ依頼を再送すると、まだ実行中の仕事と重複する可能性があります。まず状態を聞くようにしています。mergeやreleaseも、依頼に含めない限り進めません。

2026年10月2日から4日の運用では、依存パッケージを取得できず手元で補ったことや、大きいIssueで2時間以上PRが出なかったことがありました。これをサービス全体の制限や標準所要時間とは扱っていません。私の対処として、30〜60分を目安に終えられる単位に分ける方針にしています。

6. 成果SHAを固定して検収する

提出されたbranchの最新版だけを眺めるのでなく、報告されたSHAを基準にレビューします。指示どおりの範囲か、証跡と成果が同じ版か、未確認の環境が残っていないかを、作業者とは別の担当が確認します。

手元ではWindows実機や画面、本番に関わる部分を別に確かめます。別環境でテストが通ったことと、こちらで受け入れられることを一つにしません。修正が必要なら同じ案件番号で指摘し、新しい成果SHAを受け取り直します。

今回の記事も、原稿・画像の提出、制作側の独立レビュー、手元の検収、3媒体への公開、公開後の表示確認を分けています。dotsの担当は原稿と画像の制作および検収指摘への修正までです。公開は私が行い、投稿先repoへのpushや投稿用の認証をdotsには依頼していません。

この運用で重視しているのは、依頼を変えずに渡すことと、確認できた範囲を記録することです。入口を追加する前に、小さい一件で「送る、受付を読む、成果を見る、独立して検収する」まで通すと、不足している項目を見つけやすくなります。

関連記事: Rust候補を30リポジトリへ導入して、追加検査を15件保留にした理由

---

※ ヘッダー画像とインフォグラフィックの絵は AI（画像生成）で作成しています。

※ 本文の挿絵も AI（画像生成）で作成しています。

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。