AIとの壁打ちが、そのままコードになる世界へ - バックグラウンドエージェントが変える開発体験

この記事をシェア

朝のスタンドアップミーティングにて

「昨日のキャッシュ周りのバグ、結局どうやって解決したの？」

チームリーダーの質問に、私は少し困った顔をしました。確かに解決はしたのですが、その過程でClaudeと交わした長い議論の内容を、今この場で正確に説明するのは難しい。Cursorのチャット履歴を開こうとしましたが、昨日は自宅のPCで作業していたため、今すぐには見られません。

「えーっと、Redisのエビクション戦略を見直して...」

言葉を探しながら説明を始めた私を見て、隣の席の同僚がニヤリと笑いました。

「それ、Slackで議論してたら良かったのにね」

開発者の日常に潜む「もったいない」

私たちエンジニアは、日々さまざまなAIツールを使って開発を進めています。特にCursorの登場以降、AIとの対話を通じてコードを書くことが当たり前になりました。しかし、ふと気づくのです。

AIとの貴重な技術議論が、個人のローカル環境に閉じ込められているということに。

考えてみれば、私たちがAIと交わす会話の多くは：

アーキテクチャの設計検討
バグの原因究明
パフォーマンス改善のアイデア出し
新技術の調査

など、チーム全体にとって価値のある内容ばかりです。でも、これらの会話はCursorを閉じた瞬間、アクセスしづらくなってしまう。モバイルから確認することもできないし、他のメンバーと共有するのも一苦労です。

Slackという、もう一つの開発環境

ある日、ふとした思いつきから始まりました。

「SlackでClaudeと話せたら、チーム全員で知見を共有できるんじゃない？」

最初は単純な発想でした。でも実際に作ってみると、想像以上の可能性が見えてきたのです。

朝の通勤電車で

スマートフォンのSlackアプリを開き、昨夜のデプロイで発生した問題について、Claudeに相談を始めます。


@claude 本番環境でメモリリークが発生しているようです。

Node.jsアプリケーションで、24時間でメモリ使用量が3GBまで増加しています。

考えられる原因を教えてください。

電車の中でも、Claudeは丁寧に可能性を列挙してくれます。イベントリスナーの解放忘れ、グローバル変数への参照保持、ストリームの適切なクローズ...

オフィスに着く頃には、調査すべきポイントが明確になっていました。

チームメンバーとの自然な協業

「お、メモリリークの件、もう調査始めてるんだ」

Slackのスレッドを見た同僚が声をかけてきます。

「実は前のプロジェクトでも似た問題があってさ、その時は...」

AIとの会話に、人間のチームメンバーが自然に参加してくる。これこそが、私たちが本当に求めていた開発スタイルでした。

そして、魔法のような瞬間

午後になり、いよいよ実装に取り掛かります。Cursorを開いて、コードを書き始める時...


@Cursor 今朝のSlackでのメモリリーク調査の会話を参考に、

修正コードを実装してください

これだけです。

Cursorは朝の通勤電車での会話、同僚からのアドバイス、Claudeとの詳細な議論、すべてを理解した上で、的確な修正コードを提案してくれます。

朝の思考が、そのまま午後のコードになる。通勤時間の議論が、実装時のコンテキストになる。チームの知見が、個人の開発に活きる。

これが、Slack×Claude×Cursorが生み出す新しい開発体験です。

変わり始めた開発チームの日常

1. 議事録が不要になった設計会議

金曜日の設計会議。ホワイトボードに描いたアーキテクチャ図をSlackに投稿し、Claudeと議論を始めます。

「このマイクロサービス構成だと、サービス間通信がボトルネックになりそうだけど、どう思う？」

Claudeの指摘に、チームメンバーが次々と意見を追加していきます。会議が終わる頃には、Slackのスレッドが完璧な議事録になっていました。

そして翌週、実装担当者はCursorで @slack "マイクロサービス設計会議" と入力するだけで、すべての文脈を把握できるのです。

2. 新人エンジニアの成長速度

「先輩たちがClaudeとどんな会話をしているか、全部見られるんですね！」

新しく入ったジュニアエンジニアの目が輝いていました。

ベテランエンジニアがどのように問題にアプローチし、どんな質問をAIに投げかけているか。その思考プロセスがすべて可視化されているのです。これ以上の教材はありません。

3. 障害対応の知識ベース

深夜2時、本番障害のアラートで起こされました。

しかし慌てることはありません。Slackで過去の類似障害の対応履歴を検索し、当時のClaudeとの会話を確認。前回の解決策を参考にしながら、今回の状況に合わせた対応を進めます。

障害対応の経験が、チームの資産として蓄積されていく。同じ失敗を繰り返さない組織が、自然に作られていきます。

開発文化の進化

このシステムを導入してから、私たちのチームに起きた変化は技術的なものだけではありませんでした。

「AIと話すことが恥ずかしくない文化」が生まれたのです。

以前は、基本的な質問をAIにすることに抵抗を感じる人もいました。「こんな初歩的なこと聞いていいのかな」という遠慮です。

でも、SlackでオープンにAIと会話することが当たり前になると、その心理的障壁が消えました。ベテランエンジニアが基礎的な質問をしている姿を見て、ジュニアメンバーも安心して質問できるようになったのです。

未来への展望

ある日の夕方、チームで雑談をしていた時のことです。

「最近、コードレビューの質が上がった気がしない？」

確かに、PRのコメントが以前より的確になっています。それもそのはず、レビュアーは実装者がSlackでClaudeと交わした設計議論を読んでから、コードを見ているのです。背景や意図を理解した上でのレビューは、自然と質が向上します。

「次は画像での議論もできるようにしたいね」

UIデザインやアーキテクチャ図をClaudeと議論し、その内容をCursorで参照できたら...

「GitHubのIssueとも連携できたら最高だな」

可能性は無限に広がっています。

技術編：Slack×Claudeボットの構築

ここからは、実際にこのシステムを構築したい方のための技術解説です。コードを交えながら、詳細な実装方法をご紹介します。

実際のSlack×Claudeボットの動作例

実際のSlackでClaudeと技術的な議論を行っている様子

システムアーキテクチャ

まず、全体構成から説明します。このシステムは、AWSのサーバーレスアーキテクチャを採用しています。

各コンポーネントの役割：

Slack App: ユーザーインターフェース
API Gateway: HTTPリクエストの受信とルーティング
Lambda Function: ビジネスロジックの実行
DynamoDB: 会話履歴の永続化（24時間保持）
Anthropic API: Claude-3.5-Sonnetによる応答生成

前提条件

構築を始める前に、以下を準備してください：

AWS アカウント（Lambda、DynamoDB、API Gatewayが利用可能）
Slack ワークスペース（アプリ作成権限あり）
Anthropic APIキー
AWS CLI（設定済み）
AWS SAM CLI
Docker（SAMビルド用）

Slack App設定

1. アプリの作成

Slack APIにアクセスし、新しいアプリを作成します。

2. 権限設定（OAuth & Permissions）

Bot Token Scopesに以下を追加：


app_mentions:read  - メンションを読み取る権限

chat:write         - メッセージを投稿する権限

commands          - スラッシュコマンドを使用する権限

3. イベント設定（Event Subscriptions）

Enable Events: ON
Subscribe to bot events: app_mention
Request URL: デプロイ後に設定

4. スラッシュコマンド（Slash Commands）

以下のコマンドを追加：

/claude-clear: 会話履歴をクリア
/claude-status: ボットの状態確認

環境構築とデプロイ

1. 完全なソースコードの入手

本システムの完全なソースコード、設定ファイル、デプロイスクリプトなど、すべてのファイルは以下から入手できます：

🎯 完全版ソースコード・設定ファイル全文の入手

実装に必要なすべてのファイルが含まれています

Note.comで入手する

2. 環境変数の設定

cp .env.template .env

.envファイルを編集：

SLACK_BOT_TOKEN=xoxb-your-bot-token
SLACK_SIGNING_SECRET=your-signing-secret
ANTHROPIC_API_KEY=sk-ant-your-api-key
AWS_REGION=ap-northeast-1

3. デプロイ実行

chmod +x deploy.sh
./deploy.sh

デプロイ完了後、表示されるAPI Gateway URLをSlack Appの設定に使用します。

DynamoDBスキーマ設計

会話履歴を効率的に管理するため、以下のスキーマを採用しています：

{
    "channel_id": "C1234567890",      # パーティションキー
    "timestamp": 1625097600,          # ソートキー
    "user_id": "U1234567890",
    "role": "user|assistant",
    "content": "メッセージ内容",
    "thread_ts": "1625097600.123456", # スレッド管理
    "ttl": 1625702400                 # 自動削除（7日後）
}

ソースコード全文

ここからは実際のコードを見ていきましょう。紙面の都合上、主要な部分を抜粋してご紹介します。

メインのLambda関数（src/app.py）- 抜粋

import json
import boto3
import requests
import os
import logging
from datetime import datetime, timedelta
from slack_bolt import App
from slack_bolt.adapter.aws_lambda import SlackRequestHandler

# Slack Bolt アプリの初期化
app = App(
    token=os.environ["SLACK_BOT_TOKEN"],
    signing_secret=os.environ["SLACK_SIGNING_SECRET"],
    process_before_response=True  # 非同期処理を有効化
)

# DynamoDB リソースの初期化
dynamodb = boto3.resource('dynamodb')
table_name = os.environ.get('DYNAMODB_TABLE_NAME', 'slack-claude-conversations')
table = dynamodb.Table(table_name)

@app.event("app_mention")
def handle_mention(event, say):
    """Slackでメンションされた時の処理"""
    channel_id = event['channel']
    user_id = event['user']
    thread_ts = event.get('thread_ts', event['ts'])
    
    # メンション部分を削除
    user_message = event['text']
    bot_user_id = app.client.auth_test()['user_id']
    user_message = user_message.replace(f"<@{bot_user_id}>", "").strip()
    
    # ユーザーメッセージを保存
    save_message(channel_id, user_id, "user", user_message, thread_ts)
    
    # 会話履歴を取得
    history = get_conversation_history(channel_id, thread_ts)
    
    # Claude用のメッセージ形式に変換
    messages = format_messages_for_claude(history)
    
    # Claude APIを呼び出し
    claude_response = call_claude_api(messages)
    
    # Claudeのレスポンスを保存
    save_message(channel_id, bot_user_id, "assistant", claude_response, thread_ts)
    
    # Slackに返信（スレッドで）
    say(text=claude_response, thread_ts=thread_ts)

完全なソースコードはNote.comで配布中です。実装に必要なすべてのファイルが含まれています。

トラブルシューティング

よくある問題と解決方法

Slack Events が受信されない
- API Gateway URLが正しく設定されているか確認
- Slack Appの権限設定を再確認
- CloudWatch Logsでエラーを確認
Claude API エラー
- APIキーの有効性を確認
- レート制限に達していないか確認
- リクエストペイロードのサイズを確認
DynamoDB アクセスエラー
- IAMロールの権限を確認
- テーブル名が正しいか確認
- リージョン設定を確認

ログの確認方法

# Lambda関数のログを確認
sam logs -n SlackClaudeFunction --stack-name slack-claude-bot --tail

# CloudWatch Logsで特定のエラーを検索
aws logs filter-log-events \
  --log-group-name /aws/lambda/slack-claude-bot-SlackClaudeFunction \
  --filter-pattern "ERROR"

カスタマイズのポイント

会話履歴の保持期間を変更

環境変数で調整可能：

CONVERSATION_HISTORY_HOURS: 取得する履歴の時間範囲（デフォルト: 24時間）
CONVERSATION_TTL_DAYS: DynamoDBでのデータ保持期間（デフォルト: 7日）

Claudeモデルの変更

CLAUDE_MODEL環境変数で切り替え可能。最新モデルへの更新も簡単です。

会話の文脈長調整

MAX_CONVERSATION_MESSAGESで、Claude APIに送信する最大メッセージ数を調整できます。

おわりに

Slack×Claude×Cursorの連携は、単なる技術的な仕組み以上の価値を生み出します。それは、チームの知識を共有し、AIとの対話を資産化し、開発効率を飛躍的に向上させる新しい開発文化の基盤となるのです。

朝の通勤電車でのひらめきが、午後のコードに。深夜の障害対応の経験が、チームの財産に。個人の学びが、組織の成長に。

これこそが、バックグラウンドエージェントが実現する「AIとの壁打ちが、そのままコードになる世界」です。

ぜひ、あなたのチームでも試してみてください。きっと、新しい発見があるはずです。

技術的なご質問・導入のご相談はお気軽に

Slack×Claude×Cursorの導入支援や、カスタマイズのご相談を承っております。

お問い合わせ

この記事が役に立ったらシェアしてください

AIとの新しい開発体験を、あなたのチームにも広めてみませんか？

Facebookでシェア X (Twitter)でシェア

この記事を書いた人

野口真一

フリーランスエンジニア・ITコンサルタント

業界歴30年のフリーランスエンジニア。AI開発、システムコンサルティング、レガシーシステム刷新を専門とする。