カバー画像

最近、「もっといろんな人と直接会って、アットウェアのことを知ってもらう機会を増やしたいな」と考えていました。手っ取り早いのは、技術系やビジネス系の交流会に顔を出すこと。……なのですが、いざやろうとすると「そもそも、ちょうどいい交流会をどうやって探すの？」という地味な壁にぶつかります。

毎週いろんなサイトを巡回して、開催日と場所と参加者層をチェックして……というのは、正直なかなか骨が折れます。この「探す」の部分をまるっとAIに任せて、毎週月曜の朝に候補をSlackに届けてもらえないか？ と思って作ってみたのが、今回の仕組みです。

📝 手順を一通り載せたので、そこそこの長さになっています。気になるところは目次から拾い読みしてもらえればと思います！

目次

  1. 今回つくる仕組みの全体像
  2. 設計で悩んだ3つのこと
  3. つくってみる（ハンズオン）
  4. 「良い交流会」をどう採点するか
  5. やってみての気づき
  6. まとめ

1. 今回つくる仕組みの全体像

やりたいことはシンプルで「毎週決まった時間に、条件に合う交流会を探して、Slackに投げてほしい」。

今回の主役は Claude Code の Routines（以下、ルーティン） という機能です。ざっくり言うと「プロンプトとリポジトリとスケジュールを登録しておくと、Anthropicのクラウド上でClaude Codeを定期実行してくれる」仕組み。自分のPCやサーバーを常時起動しておく必要がありません。

全体の流れはこんな感じです。

週次バッチの処理フロー：毎週月曜8:00にクラウドで起動し、通知済みリストを読み込み、Web検索で交流会を探し、4つの観点で採点し、既出を除いて上位に絞り、Slackに投稿し、通知済みリストを更新して記録する

起動 → 通知済みを読む → 探す → 採点 → 絞る → 投稿 → 記録

「探して・見極める」というふわっとした部分はClaudeに任せ、「重複を消す・投稿する・記録する」という手続き的な部分もまとめて1回の実行の中でやってもらう。これが今回の狙いです。

2. 設計で悩んだ3つのこと

作り始める前に、決めておかなければならないことが3つありました。

  • 交流会の情報をどこから取ってくるか
  • どこで動かすか（実行環境）
  • 「前回どこまで通知したか」をどう覚えておくか（状態の持ち方）

順に見ていきます。

どこから取ってくるか — 交流会の情報は、意外と「散らばっている」

技術系の勉強会だと情報がまとまっている場所がありますが、ビジネス系の交流会は情報がバラバラなんですよね。商工会議所、自治体や産業振興系のイベント、各種の交流会サイト……と、あちこちに散っていて、きれいに一覧で取れるAPIがあるわけでもない。

なので今回は「特定のサイトを1つずつスクレイピングする」のではなく、Claudeに毎回Web検索させて、公式ページを見つけてもらう方式にしました。サイト構成の変化に強く、保守もしやすくなります。

どこで動かすか — クラウドならサーバーの世話がいらない

最初は「自宅のRaspberry Piでcronを回そうかな」とも考えました。でも今回のように週1で軽く回すだけなら、クラウドで完結するルーティンの方が手軽でした。マシンの起動もキーの管理も不要です。

どう覚えておくか — 「状態」の持ち方に一工夫

ルーティンはクラウド上で、毎回まっさらな環境で動きます。便利な反面、「前回どのイベントを通知したか」をローカルに貯めておけないという制約があります。これがないと、毎週同じイベントが何度も流れてきてしまう。

そこで、通知済みリスト（状態）はGitHubリポジトリに置くことにしました。実行のたびにそこを読み書きすれば、クラウドで動いていても記憶が引き継げます。しかもGitのコミット履歴が、そのまま「いつ何件流したか」の実行ログにもなる。一石二鳥です。

3. つくってみる（ハンズオン）

STEP 1. リポジトリを用意する

まず、設定と状態を置くための専用リポジトリ（event-discovery）をGitHubに作ります。社内向けの情報を扱うので Private にしました。

main ブランチには、次の3ファイルを置きます（README.md は説明用なので本筋には関係ありません）。

  • config.json … 探索条件（地域・期間・しきい値・通知先など）
  • prompt.md … Claudeへの指示書（今回の頭脳）
  • events.schema.json … 出力するイベント情報の型

GitHubリポジトリのファイル一覧

config.json はこんな感じです。ここが後々のチューニングの主戦場になります。

{
  "regions": ["東京", "神奈川", "横浜", "川崎", "さいたま", "千葉"],
  "months_ahead": 3,
  "offline_only": true,
  "score_threshold": 60,
  "max_notify": 5,
  "slack_channel": "#event-discovery",
  "slack_channel_id": "XXXXXXXXXXX",
  "queries": [
    "{region} 製造業 経営者 交流会",
    "{region} ものづくり DX セミナー",
    "{region} 中小企業 経営者 交流会",
    "{region} 商工会議所 交流会 製造業",
    "{region} 産業振興 ビジネスマッチング 製造業",
    "{region} 補助金 DX セミナー 中小企業"
  ]
}

regions に「神奈川」と「横浜」「川崎」が並んでいるのは重複のようですが、これは意図的です。県名だけだと市単位のイベント告知が拾えないことがあったので、主要な市を明示的に足して検索を厚くしています。

📝 slack_channel と slack_channel_id は、実際には社内の専用チャンネルを指定していますが、この記事では伏せています。チャンネルIDは Slack でチャンネル名をクリックすると、詳細パネルの一番下に表示されます。

STEP 2. 状態用のブランチを分ける

「設定（main）」と「状態（通知済みリスト）」を混ぜたくないので、状態は専用の claude/state ブランチに置きます。

# main から切り離した、空のブランチを作る
git checkout --orphan claude/state
git rm -rf .

mkdir state
echo '{}' > state/seen.json   # 通知済みリスト（最初は空）
git add state
git commit -m "init state branch"
git push -u origin claude/state
git checkout main

GitHubリポジトリのブランチ一覧

claude/ で始まるブランチ名にしているのには理由があります。ルーティンから GitHub への書き込みは claude/ プレフィックスのブランチに限定されるため、この命名にしておけば main を誤って書き換える心配がありません。設定を置く main には触らせず、状態だけをここに積んでいく形です。

STEP 3. 指示書（prompt.md）を書く

prompt.md に、やってほしいことを手順として全部書き切ります。クラウドの実行は毎回「記憶ゼロ」からのスタートなので、自己完結していることが大事です。抜粋するとこんな流れです。

1. claude/state の seen.json（通知済み）を git fetch で読む
2. config.json の条件でWeb検索し、今月〜再来月の交流会を探す
3. 各候補を4軸（商材接点/参加者層の合致度/物理条件/コスト・規模）で採点
4. 既出を除き、しきい値以上の上位N件に絞る
5. Slackにダイジェストを投稿する
6. 通知した分を seen.json に追記して claude/state にコミット

STEP 4. Claude の GitHub App をインストールして、リポジトリを渡す

ルーティンが event-discovery をクローンできるように、Claude の GitHub App をインストールして、このリポジトリへのアクセスを許可します。

ここは Claude の設定画面からは辿り着けないので、App のページを直接開くのが早道です。

  1. ブラウザで github.com/apps/claude を開く
  2. Install / Configure から、対象アカウントを選ぶ
  3. Repository access で event-discovery を追加して Save
  4. github.com/settings/installations で、そのリポジトリが許可されているか確認

私は「Claudeの設定画面でGitHub連携をONにすればOKでしょ」と思い込んでこの手順を飛ばしてしまい、次のルーティン作成でリポジトリが選べずに詰まりました。

STEP 5. Slackコネクターをつなぐ

通知先のSlackを、Claudeのコネクターとしてつないでおきます。すでに接続済みなら、この手順は飛ばしてOKです。

Claudeの設定 →「コネクター」から Slack を接続します。ここでひとつだけ実務的な注意があって、ルーティンが投稿先チャンネルに書き込める状態にしておく必要があります。専用チャンネルを作った場合は、そのチャンネルにコネクター（Slackアプリ）を参加させておくか、自分がそのチャンネルのメンバーであることを確認しておきましょう。ここが漏れていると、次のRun nowで「チャンネルに投稿できない」というエラーになりがちです（もしなったら、チャンネルにアプリを招待すれば直ります）。

STEP 6. ルーティンを作る

claude.ai/code/routines から新しいルーティンを作成します。設定するのは、

  • モデル：探索と採点は考える量が多いので、上位モデル（今回は Opus 5）を指定
  • リポジトリ：event-discovery
  • コネクター：Slackだけ残して、不要なものは外す（渡すツールは最小限に）
  • スケジュール：毎週月曜 8:00
  • 指示：prompt.md を全文貼るのではなく、「main の prompt.md を読んでその通りに実行して」の一行だけ

指示を一行にしておくのがちょっとしたコツです。こうすると、以降のチューニングはリポジトリの prompt.md を編集するだけで済み、ルーティンの設定画面を触らずに育てられます。

ルーティン作成フォーム

STEP 7. まずは手動で回す（Run now）

作成後はまず「今すぐ実行」で1回手動実行して結果を見ます。プロンプトは動かしながら育てるものなので、初回のログを見てから調整するのが安全です。

ルーティンページ（実行前）

実行前。「まだ実行がありません」の状態

ルーティン実行画面（実行後）

実行後。検索から Slack 投稿、claude/state への push までのログが残る

そして……無事、Slackにダイジェストが届きました！🎉 検索して、採点して、重複を消して、投稿して、記録する。設計した流れが端から端まで一気通貫で通った瞬間で、これはなかなか気持ちよかったです。

とはいえ、上の実行ログをよく見ると Claude が「今日このルーティンが走るのは2回目のようだけれど、スケジュール設定が1日2回発火していないか確認した方がいい」と親切に指摘してくれています。手動実行とスケジュール実行が重なっただけだったのですが、こういう気づきがログに残るのはありがたいところです。

Slack画面

4. 「良い交流会」をどう採点するか

今回いちばん工夫したのが、この採点の部分です。

というのも、ひとくちにビジネス交流会といっても中身は本当に幅広く、名刺交換そのものが主目的の会も数多くあります。それが悪いということでは全くないのですが、今回私たちが会いたいのは製造業の経営層・DX担当や、中小企業の経営者の方々。目的が違えば合う会も変わるので、単に「交流会」を集めるだけでは候補が絞り込めません。

そこで、Claudeに次の4軸で採点してもらうようにしました。

観点 見るところ
商材接点 製造業DXやマシンビジョン（カメラ画像をAIで解析して検査や計測に使う技術）など、アットウェアの得意領域と近いか
参加者層の合致度 会いたいと思っている層が集まりそうか
物理条件 首都圏・オフラインで、参加しやすい日時か
コスト・規模 小規模（顔が見える規模）を優先

あわせて、「商工会議所・産業振興系が主催」「タイトルに「製造業」「ものづくり」「経営者」を含む」などは加点、「名刺交換のみの会」「副業・フリーランスの方が中心の会」「オンラインのみ」などは今回の目的とは層が異なるため減点・対象外、というルールも渡しています。

そして良いのは、この採点基準がただのテキストであること。prompt.md を書き換えてpushするだけで、次の実行から反映されます。最初はざっくり始めて、届いた結果を見ながら「この会は要らなかったな」と少しずつ調整していけばいい。まさに育てていく運用ができます。

5. やってみての気づき

  1. 「探す」はAIが得意な仕事：条件を言葉で伝えるだけで、散らばった情報の中から候補を集めて、良し悪しまで判断してくれます。人間がやると気が重い作業ほど、任せる価値がありそうです
  2. 状態管理の逃がし方が肝：クラウド実行でも、GitHubを記憶役にすれば継続的な処理が作れます。コミット履歴がそのままログになるのも地味に便利でした
  3. 思い込みで手順を飛ばすとハマる：GitHub App のインストールのように、「たぶんこれで大丈夫だろう」で進めた箇所ほど後から効いてきます。どこで止まっているのかを切り分けられるかが大事だなと再認識しました
  4. 完璧を目指さず、まず動かす：採点の精度は後からいくらでも調整できます。細い線を1本通してしまうのが結局いちばん早いと感じました

6. まとめ

できたこと

  • ✅ 毎週月曜の朝、首都圏の交流会候補が自動でSlackに届く
  • ✅ 「ただ集める」ではなく、会いたい人がいそうかを採点して上位だけ通知
  • ✅ サーバー管理なしのクラウド実行（Claude Code Routines）
  • ✅ 状態はGitHubに逃がして、重複通知を防止＆実行ログ化
  • ✅ 採点基準はテキストなので、運用しながら育てられる

「行くべき交流会、AIに探しておいてもらう」。言葉にするとシンプルですが、実際に毎週勝手に候補が届くようになると、「最初の一歩」のハードルがぐっと下がりました。あとは私が「行く」と決めるだけ。この「決めるだけの状態」を作れたのが、いちばんの収穫だったと思います。

同じように「定期的にやりたいけど、探すのが面倒で続かない」という作業をお持ちの方は、ルーティンで自動化してみると相性が良いかもしれません。

アットウェアでは、こういう「業務のちょっとした面倒」をAIで軽くする取り組みを、日々あれこれ試しています。「うちのこの作業も自動化できる？」「試してみたいけど、やり方が合っているか見てほしい」など、気になることがありましたらお問い合わせページからお気軽にご連絡ください。

この記事が役に立ったら、シェアしていただけると嬉しいです。質問やご指摘もお待ちしています！