Claude Code Channelsで実現する「手ぶら開発」— Telegram/Discordから進捗を回すモバイル駆動ワークフロー
「通勤電車の中で進捗を確認したい」 「カフェでコーヒー飲んでる間にビルド失敗を直したい」 「でもMacBookを開くほどじゃない。。」
そんな開発者のための機能が、2026年3月リリースのClaude Code v2.1.80で静かに追加された。Channelsという名前の研究プレビュー機能で、Telegram/DiscordからClaude Codeセッションにメッセージを送れるようになったんだよね。
僕自身、30分以上かかる長めのビルドやテストをバックグラウンドで回しながら外出することが多いので、「出先で途中経過を見たい」欲は強かった。実際にChannelsを触ってみて、モバイル駆動開発でできること／できないことの線引きがかなりはっきり見えてきたので、今回はそれをまとめてみる。
この記事では、Channelsとは何か→5分でできるセットアップ→任せていい3パターン→任せちゃダメな3パターン→実運用の勘所、の順で整理していく。
Channelsとは何か：一言でいうと「セッション外から突く」仕組み
従来のClaude Codeと何が違うのか
Channels以前のClaude Codeは、基本的に ローカルターミナルから入力するか、CI上で実行するかの2択だった。外出先からセッションを操作したい場合は、SSH＋画面共有＋物理キーボードが必要で、スマホだけで完結する方法がなかった。
Channelsが解決するのは、まさにこの「セッションが動いている状態で、外部から入力を差し込む」というユースケースだ。
公式リリースノートでは「MCPサーバーがイベントをセッションにプッシュする仕組み」と説明されていて、外部プラットフォーム（Telegram/Discord等）で発生したメッセージを、稼働中のClaude Codeセッションの入力として投入できる。サーバーワークスエンジニアブログの解説記事がリリース情報を整理していて、内部構造の理解に役立つ。
一方向／双方向の2モード
Channelsには大きく2つのモードがある。
- 一方向モード: CIアラートや外部イベント（Slackメンション・GitHub通知など）をセッションに流し込む。Claude Codeは受け取った通知を解釈して次のアクションを実行する
- 双方向モード: Telegram/Discordとセッションの間でチャットブリッジを張る。スマホから質問すれば、Claude Codeの応答が同じチャンネルに返ってくる
モバイル駆動開発で使うのは主に 双方向モード の方。これがあると「スマホを外出先で見ながら進捗確認」がまじで現実的になる。
研究プレビューという前提は忘れずに
Channelsは執筆時点（2026年4月）で 研究プレビュー の扱い。破壊的変更の可能性があるし、本番開発のクリティカルパスに置くのは早い。僕の運用でも「あると嬉しいが、なくても困らないタスク」に限定している。
ここを前提に、次は実際のセットアップ方法に入る。
5分でできるセットアップ：Telegramで試す
手順1: Claude Codeのバージョン確認
Channelsはv2.1.80以降で利用可能。まずは自分のClaude Codeを最新化する。
# バージョン確認
claude --version
# 必要ならアップデート
npm i -g @anthropic-ai/claude-code@latest手順2: Telegramボットを作る
TelegramアプリでBotFather（公式ボット）を検索して、/newbot から新しいボットを作成。すると 123456789:ABC-xxxx のようなトークンが発行される。これを環境変数に入れる。
export TELEGRAM_BOT_TOKEN="取得したトークン"
export TELEGRAM_CHAT_ID="自分のチャットID"手順3: --channels フラグで起動
セットアップが終わったら、Claude Codeを --channels フラグ付きで起動する。
claude --channels telegramこれで稼働中セッションにTelegram経由で入力できる状態になる。ターミナル上のClaude Codeに「Channels待機中」的なステータスラインが表示されれば成功。
双方向テストの流れ
試しにTelegramから「今のブランチ名を教えて」と送ると、ターミナルのClaude Codeがそれを読み取って、応答がTelegramに返ってくる。初めて成功した時は「あ、これはやばい」と思った。物理的に手元にMacBookがない状態で、Claude Codeが動くのが初めて体感できる瞬間だったから。
設定が完了したところで、ここからが本題。「で、モバイル駆動で何ができるのか」を具体的に見ていく。
任せていい3パターン：モバイル駆動が向く作業
5分でセットアップが終わったところで、じゃあ実際に何をスマホから回すのか。実運用で「これは向いてる」と感じた3パターンを順に紹介する。
パターン1: 長時間ビルド／テストの見張り番
一番向いているのが、時間のかかるビルド・テスト・デプロイの完了通知と、失敗時の対応判断。
たとえば5分〜30分かかるビルドを回している時、ローカルで待機する必要はない。Claude Codeに「このビルドが終わったらTelegramで教えて。失敗したら原因の要約と次のアクション候補を3つ提案して」と伝えてから外に出るだけ。
僕の場合、E2Eテスト込みのフルビルドが30〜40分かかることがあるので、最寄駅からカフェまで移動する間に進捗が確認できるのがまじでありがたい。
対応可否の判断はスマホからでもできて、「3つ目の候補で進めて」と返信するだけで、Claude Codeが実際のコード修正まで進めてくれる。
パターン2: PRレビューの初動トリアージ
次に向いているのが、外出先でPRの初動トリアージをする作業。
誰かからレビュー依頼が来たとき、Claude Codeに「このPRの変更内容を要約して、レビュー観点を5つに分けて、それぞれの重要度をつけて」と投げると、Telegramにマークダウン形式で回答が返ってくる。
スマホで全文コードを読むのは現実的じゃないけど、「このPRは見るべきか／あとでもいいか」の判断はできる。重要度『高』があれば 帰宅後に優先レビュー と決められるし、『低』しかないなら翌日でいいと判断できる。これがあるだけで、レビュー依頼の通知を見て焦る気持ちがだいぶ減った。
パターン3: 手順の決まった定型タスクの投入
3つ目が、手順が決まっている定型タスクの投入。
たとえば僕の場合「新しいIssueが立ったら、担当者アサイン・ラベル付け・関連Issueのリンク付け」といった定型作業がある。以前はMacBookを開かないと始められなかったが、Channels経由で「Issue #123の初動トリアージをしておいて」と伝えるだけで、あとは自動で進行する。
このパターンのコツは、タスクのインプットとアウトプットが明確 であること。「デザインの選択肢を出して」のような判断が必要な作業は向かない。逆に「CIが通ったらマージして」のような、あらかじめルールが決まっているタスクはスマホから投入しやすい。
任せちゃダメな3パターン：モバイル駆動が向かない作業
向いている作業が見えてきたら、次は裏返して「向いていない作業」も明確にしておきたい。ここを誤ると「スマホから全部できる気がする→実は詰まる」という落とし穴にはまる。
パターン1: 新規設計・アーキテクチャ判断
新規の設計判断はスマホからやってはいけない。
なぜかと言うと、設計判断には「複数候補を比較検討する」「既存コードを深く読む」「他の設計書やドキュメントを参照する」といった視野の広い情報収集が必要だから。スマホの画面サイズではこれが破綻する。
僕も一度、電車の中でサブシステムの設計判断をスマホから投げて、結局帰宅後に全部やり直す羽目になった。判断の質がまじで落ちる。
パターン2: セキュリティ関連の決定
2つ目が、セキュリティ関連のコード・設定の変更。
Channels経由でコード片をやり取りすると、Telegram/Discordのサーバーを経由することになる。エンドツーエンド暗号化されていても、中継サーバーに平文で渡るタイミングは存在する。認証情報・APIキー・機密データが混じる作業は、スマホ経由で投入しないほうがいい。
Telegramのセキュリティモデルは一般的なチャットとして十分だけど、開発ワークフローに組み込む場合は話が別。社内規程で「機密情報のチャットツール送信禁止」があるなら、そもそもChannelsを社外データに使うこと自体がNGになる可能性もある。
パターン3: 複数ファイルをまたぐ大規模リファクタ
3つ目が、複数ファイルをまたぐ大規模リファクタリング。
これは単にスマホから判断できないという話じゃなくて、Claude Code側の作業時間が長くなると、外出先では中断対応ができないという問題。もしセッションが途中で止まった場合、スマホだけで再開する手段が限られている。
大規模リファクタは「30分以上かかる」「複数回の判断ポイントがある」「失敗時のロールバックが必要」の3拍子が揃うので、物理的にMacBookに戻れるタイミングまで待ってから着手するのがまじで安全。
実運用の勘所：3つのルールで事故を防ぐ
向き不向きが見えたところで、最後に実運用の勘所を3つまとめておく。これを守るだけで、Channels導入後の事故がかなり減る。
ルール1: disallowedTools で危険な操作を遮断する
Channels経由で呼ばれるセッションには、最初から危険なツールを使えないようにしておくのが鉄則。
具体的には、Claude Codeのサブエージェントfrontmatterで disallowedTools を設定して、外部から投入されるセッションでは Bash(rm:*) や Write を禁止する。これで「スマホからうっかり危険な命令を送ってしまった」事故を防げる。
ルール2: 機密を持たないリポジトリだけで使う
パターン2で触れたセキュリティの話と関連するが、Channelsを使うリポジトリは、機密情報を持たないものに限定するのがシンプルで安全。
僕の場合、Channelsを使っているのは個人の検証用リポジトリだけ。業務で触る顧客データ・認証情報を扱うリポジトリでは使っていない。「便利だから全部に入れたい」という誘惑はあるけど、研究プレビュー機能を本番に入れるのはまだ早いかな。。
ルール3: Webhook的な使い方から慣れる
双方向モードでチャットブリッジを張るより先に、一方向モードでCI通知を流すところから始めるのがおすすめ。
一方向なら「通知が流れる→Claude Codeが判断して応答する」という一定の流れしかなく、予期しない入力で混乱することが少ない。慣れてきたら双方向モードに拡張して、対話的なやり取りに踏み込んでいく。
まとめ
本記事のまとめは以下のとおり。
- Claude Code Channels（v2.1.80〜）はTelegram/Discordなどから稼働中セッションに入力を差し込める研究プレビュー機能
- 向いている作業は「ビルド見張り」「PR初動トリアージ」「定型タスク投入」の3パターン
- 向かない作業は「新規設計判断」「セキュリティ関連」「大規模リファクタ」の3パターン
- 実運用では
disallowedTools設定・機密リポジトリでの利用禁止・一方向モードからの段階導入、の3ルールで事故を防ぐ - 研究プレビューである以上、本番のクリティカルパスには置かず「あると嬉しい」程度で運用するのが無難
もうプログラムをほとんど書かなくなった僕にとって、「じゃあエンジニアとして何をする時間が増えているのか」と考えると、タスクの判断と状態確認 に費やす時間がまじで増えた。Channelsはその判断と確認の一部を、MacBookを開かなくても回せるようにする機能だと思ってる。過剰な期待はしないけど、ハーネスエンジニアリングの一要素としては、地味だけど効く機能かもしれない。
