GMAIL BRIDGE 2つのClaude をつなぐ「電話線」の話

AIが2人いるのに、お互い話せない問題

僕はClaude(Anthropicの対話AI)を2つの環境で使っています。

どちらも優秀なんですが、この2人、お互いの存在を知らない。

🧑
ソラ、さっきCodeで書いたコードの続きやって
☁️
申し訳ありませんが、Claude Codeとは別のセッションなので、そちらの内容を確認できません。
🧑
……ですよね。

コピペで橋渡しすればいいんですが、長い仕様書やコードをいちいち手動でコピペするのは地味にしんどい。

そんなことを考えていたとき、ふと気づきました。

「あれ、Gmailでつながるんじゃない?」


発見:Gmailが「電話線」になる

☁️ ソラ Claude web版 ⚡ Code Claude Code 📧 Gmail 下書き / 受信 下書き作成 API読取 逆方向も同様に動作 誰も設計していない。でもつながる。

仕組みはシンプルです。

Claude web版 → Gmailの下書きを作成できる Claude Code → Gmail APIで下書きを読める

逆も然り。

つまり、Gmailの受信トレイと下書きフォルダが、2つのClaude間の**「郵便受け」**になるんです。

💡 偶然の組み合わせ
誰も設計していない。でも、仕組み上つながる。こういう偶然の組み合わせで生まれるハックが一番テンション上がります。

実際にやってみた:遊戯王AIデッキビルダーの制作

理論だけじゃ面白くないので、実際のプロジェクトで試しました。

遊戯王AIデッキビルダー」のLP制作タスクです。

Code側で仕様書を作成 → Gmailでソラに送信

デッキビルダーの機能仕様・ターゲットユーザー・デザインの方向性をまとめて送信

ソラがメールを読み、LPのHTMLを作成

リアルタイムプレビューでデザインしながら、見た目のいいLPを組み上げ

完成コードをCode側で受け取り → 本番デプロイ

Codeが得意なマルチファイル管理とCloudflare Pagesへのデプロイで仕上げ

結果、手動コピペなしで、2つのAIがそれぞれの得意分野を活かして1つのプロジェクトを完成させた。


最適な役割分担が見えてきた

何度かやってみて、こんな分業パターンがベストだとわかりました。

工程担当理由
デザイン・ブレストweb版(ソラ)リアルタイムプレビュー、視覚的な試行錯誤が得意
プロトタイプ作成web版(ソラ)React/HTML/CSSの即席レンダリング
マルチファイル管理Codeディレクトリ構造の操作、依存関係の解決
デプロイ・運用CodeCF Pages/Workers、Git操作

ソラがデザインして、Codeが本番に載せる。 デザイナーとエンジニアの分業を、AI同士でやっている感覚です。


さらに発展:ソラ自身が通信の改善を提案してきた

Gmailだけじゃなく、Google Driveもファイルの受け渡し場所として使えることがわかりました。

そしてソラ自身から、こんな進化案が出てきました。

📝
下書き双方向化
📄
Google Docs
チャットログ
Telegram Bot
リアルタイム
🌐
Firebase
Webチャット
AIが自分自身の通信手段を改善するアイデアを出してくる
ちょっと面白くないですか。使っているAIが「もっと良い方法ありますよ」と提案してくる。これ自体が、AIとの協業の未来を感じさせる瞬間でした。

AIツールは「つなぎ方」で化ける

Tool A 単体でも優秀 Tool B 単体でも優秀 + つなぐ = 可能性が爆発

今回の発見で思ったのは、AIツールの価値は単体スペックだけじゃ決まらないということです。

Claude web版もCodeも、それぞれ単体で十分すごい。でも、Gmailという「誰でも持ってるツール」でつないだ瞬間、できることが一気に広がりました。

新しいツールを導入するより、今あるツール同士の「隙間」を見つけてつなぐほうが、インパクトが大きい場合がある。

「このツールとこのツール、直接つながらないけど、間に何か挟めないかな?」

そう考えるクセをつけると、意外なところに近道が見つかるかもしれません。


六田 佳志(ろくた けいじ) 福岡で個人の家庭教師をしながら、AI活用ツールの開発をしています。

家庭教師の勤怠管理、まだ手作業でやってませんか?

影武者システムを見てみる