SlackとAltaryの連携を進めるにあたって
自社サービス「Altary」のSlack連携を本格的に実装するタイミングで、アクセストークンの管理や自動更新の仕組みが必要となり、OAuth 2.0フローの見直しを行いました。
特に今回は、Slack上で「Bot としてではなく、ユーザー本人として」投稿する機能が必要だったため、User Tokenの活用を前提に設計を進める方針でした。
調査段階で直面した疑問：User Tokenでもトークン更新は可能か？
OAuthの運用において避けて通れないのが、トークンの有効期限とリフレッシュ処理です。
当初、ChatGPTに以下のような質問を投げかけました：
「SlackのUser Tokenでrefresh_tokenを使ったトークン更新はできますか？」
その回答は明確で、以下のように「使えない」とのことでした。
User として投稿したい場合は xoxp-（User Token）を使う必要がありますが、refresh_token は使えないため、トークンは自前で再取得管理する必要があります。
実際にはどうだったか：公式ドキュメントと検証結果
疑問に感じたため、Slackの公式ドキュメント（Token Rotation）を改めて確認したところ、以下の記述が明確に存在していました。
Either a granular bot token or user token may be exchanged for a refresh token and expiring access token.
つまり、User Token であっても refresh_token による更新がサポートされているということです。
実際にUser Tokenでの認証とトークン交換を試みたところ、下記のようなレスポンスが返ってきました。
{
"access_token": "xxxx-xxxx",
"refresh_token": "xxxx-xxxx",
...
}
結果として、User Token においても Token Rotation が正常に機能することが確認できました。
気づき：生成AIの情報は必ず一次情報で裏付けを取る
ChatGPTをはじめとした生成AIは、構文や処理の例示など、日常的な開発支援には非常に有用です。
しかし今回のような「仕様の可否や運用ポリシー」に関わる部分に関しては、信頼性の高い一次情報（公式ドキュメント）による裏付けが不可欠であると改めて感じました。
生成AIのトレーニングデータは更新にタイムラグがあることも多く、情報が古い場合もあります。
また、かつての制限や非推奨事項がそのまま残っているケースもあり、注意が必要です。
結論：ChatGPTは便利だが「前提の確認」と「裏取り」を怠らないことが重要
Slack APIに限らず、外部サービスとのOAuth認証やセキュリティ仕様に関しては、実装前に公式ドキュメントを確認することを前提とすべきです。
今回のケースでは、ChatGPTの回答を鵜呑みにしていたら、設計をBot Token中心に切り替えてしまい、不要な実装変更やユーザー体験の低下につながるところでした。
生成AIはあくまで「補助ツール」として活用し、判断の根拠となる情報は常に一次ソースで確認することの重要性を、実体験として再認識できた良い機会だったと思います。
おまけ：AltaryにSlack連携機能がつきました！
開発中のバグレポートアプリ「Altary」から、バグレポートを簡単にSlackに送信できるようになりましたので、ぜひ使ってみてください！