AIを使っていると、だんだんこう思うようになります。
「このAIで考えた指示を、別のAIアプリにそのまま送れたら便利なのに」
たとえば、Claudeで設計を考える。
その設計をCodexに渡して実装させる。
さらにAntigravityに送って、別の角度から爆速で試す。
こういう使い分けをしたい場面はかなりあります。
ただ、現実には毎回コピペが必要です。
Claudeで作った長い指示文をコピーして、Codexを開いて貼り付ける。
Antigravityに渡したいときも、またコピーして貼り付ける。
これだけならまだいいのですが、長いプロンプトを何度もやり取りしていると、元のチャット欄がプロンプトだらけになります。
ファイルに一度書き出して、それを別のAIに渡すこともできますが、それも少し面倒です。
そこで今回、僕は「AIエージェントから別のGUIアプリへプロンプトを送るだけ」の小さなMCPサーバーを作りました。
名前は、Okihiro App Hub MCPです。
今回はClaude Codeを司令塔側の環境として使うイメージですが、本文では読みやすさを優先して「Claude」と呼びます。
これは巨大な自動化システムではありません。
まずは、人間が手でやっていた「別アプリへのプロンプト受け渡し」だけを、最小限で自動化するための仕組みです。
この記事で作ったMCPを使って、Claude・Codex・Antigravityを全自動で会話させた様子を動画にしています。読む前に動きを見たい方はこちらからどうぞ。
1. この記事で話すこと
この記事では、細かいコード解説よりも、次のような考え方を中心に書きます。
- なぜこのツールを作ろうと思ったのか
- AIアプリ同士をどう役割分担させるのか
- MCPを使うと何ができるのか
- エージェントにどんな指示を出して作っていったのか
- なぜ最初は「送信専用」にしたのか
- なぜ自動送信より「貼り付けのみ」が安全なのか
- 将来的にAI同士の議論リレーへどうつながるのか
この記事を読むと、AIツールをただ使うだけではなく、「AI同士をつなぐ道具を作る」という発想が少し見えてくると思います。
2. きっかけは、AIアプリ間のコピペが面倒だったこと
僕は普段、複数のAIツールを使い分けています。
たとえば、思考力が必要な設計はClaudeに相談する。
実装やコード修正はCodexに投げる。
Antigravityでは、別の開発環境として素早く試す。
こういう使い分けをしていると、AIごとに得意な役割があることがわかってきます。
ただ、問題があります。
それぞれのAIは別アプリ、別画面、別チャットです。
Claudeで考えた指示をCodexに渡したいときは、結局コピペするしかありません。
Codexに渡す指示をClaudeに考えてもらっても、その指示文を手でコピーして、Codex側に貼り付ける必要があります。
Antigravityに渡すときも同じです。
これが何回も続くと、かなり面倒になります。
しかも、Claude側のチャット欄が「Codexに渡すためのプロンプト」で埋まっていきます。
本当はClaudeには、設計や判断に集中してほしい。
でも実際には、別AIへ渡すための長文指示がチャット欄に残り続ける。
これが気になりました。
そこで考えたのが、
「Claudeに『この指示をCodexへ送っておいて』と言えば、実際にCodexへ貼り付けられる状態を作れないか？」
という発想です。
3. 司令塔AIと実行AIを分ける
今回のポイントは、AIを1つだけで完結させないことです。
僕の中では、AIをこう分けています。
- 司令塔AI
- 実行AI
- 検証AI
- 高速処理AI
たとえば、Claudeのような思考が得意なAIは、司令塔に向いています。
全体設計、方針決め、プロンプト設計、リスク確認などを任せやすい。
一方で、Codexのような環境は、実装やファイル編集、コード修正に向いています。
Antigravityのような環境は、また別の角度で高速に試す場所として使えます。
つまり、
「全部を1つのAIにやらせる」
のではなく、
「司令塔AIが考え、実行AIに仕事を振る」
という形にした方が自然です。
人間のチームでも同じです。
企画を考える人、実装する人、チェックする人、量産する人が分かれている方が動きやすい。
AIでも同じことができます。
ただし、そのためには「AIから別のAIへ指示を渡す通路」が必要になります。
今回作ったMCPは、そのための小さな通路です。
4. 最初に司令塔AIへ相談した内容
今回、いきなりコードを書き始めたわけではありません。
まずは司令塔になるAIに、こういう相談をするところから始めました。
複数のAIアプリを連携させたいです。
具体的には、Claudeで考えた指示をCodexやAntigravityなどの別アプリへ渡せるようにしたいです。
人間が毎回コピペするのではなく、AIエージェント側から「このプロンプトをこのアプリへ送って」と指示できるようにしたいです。
返答取得まで完全自動化する必要はありません。
まずは、入力欄にプロンプトを貼り付けるだけでも構いません。
MCPを使う前提で、どういう構成にすれば安全で現実的かを設計してください。最初の段階で大事なのは、いきなり完成形を求めないことです。
「AI同士を完全自動で会話させたい」
とだけ言うと、構想が大きくなりすぎます。
そこで、最初のスコープをかなり絞りました。
- 返答取得はしない
- 送信専用にする
- GUIアプリの入力欄へ貼り付けるだけでよい
- 自動送信は後回しでもよい
- まずは安全に動く小さい仕組みにする
こうすると、AIも現実的な設計を出しやすくなります。
5. MCPを使えば、AIからツールを呼び出せる
今回の仕組みでは、MCPを使っています。
MCPはかなりざっくり言うと、AIエージェントから外部ツールを呼び出すための仕組みです。
今回でいう外部ツールは、
「指定したGUIアプリへプロンプトを送るツール」
です。
具体的には、次のようなツールを用意しました。
send_prompt_to_appこのツールに対して、以下のような情報を渡します。
app: 送り先のアプリ
prompt: 送りたい文章
submit: 自動送信するかどうか
confirm_token: 自動送信用の確認トークン
timeout_sec: タイムアウト秒数送り先のアプリは、たとえば以下のようなものです。
antigravity
claude
codexつまり、AIエージェント側から見ると、
この文章をClaudeへ送って
この文章をCodexへ送って
この文章をAntigravityへ送ってという操作を、ツール呼び出しとして扱えるようになります。
6. 実際にやっていることはかなりシンプル
中でやっていることは、実はかなりシンプルです。
大まかな流れはこうです。
1. MCPクライアントが send_prompt_to_app を呼び出す
2. 送り先アプリとプロンプト本文を受け取る
3. 安全設定を確認する
4. 機密情報っぽい文字列がないか確認する
5. 対象アプリのウィンドウを前面に出す
6. クリップボードにプロンプトを入れる
7. Ctrl+Vで貼り付ける
8. 条件を満たす場合だけ送信キーを押すつまり、AIがアプリの内部APIを直接操作しているわけではありません。
人間が普段やっている、
「アプリを開く」
「入力欄に貼り付ける」
「必要なら送信する」
という操作を、薄く自動化しているだけです。
ここが重要です。
最初から複雑な自動化を狙うと、壊れやすくなります。
でも、人間が手でやっていた一部分だけをMCP化するなら、かなり現実的です。
7. 最初は「貼り付けのみ」にした
今回かなり大事にしたのが、安全性です。
AIアプリへプロンプトを渡すとき、いきなり自動送信までやると危ない場面があります。
たとえば、
- 間違ったアプリへ送ってしまう
- まだ確認していない文章を送ってしまう
- 機密情報を含んだプロンプトを送ってしまう
こういうリスクがあります。
なので、初期設定では自動送信しないようにしました。
つまり、AIがツールを呼び出しても、まずは対象アプリへ貼り付けるだけです。
貼り付けられた状態を人間が確認できます。
問題なければ、人間がEnterを押して送ればいい。
これだけでも、かなり便利です。
コピペの手間はなくなる。
でも最後の送信判断は人間が持てる。
このバランスが、最初の実用ラインとしてちょうどいいと思いました。
8. 自動送信は3段階で制御する
もちろん、自動送信したい場面もあります。
たとえば、決まった形式の指示をCodexへ送るだけなら、毎回人間がEnterを押すのも面倒です。
そこで、自動送信のモードを分けました。
safe : 貼り付けのみ。自動送信は禁止。
token : 確認トークンが一致したときだけ自動送信。
open : 自動送信を許可。初期設定は safe です。
つまり、間違って submit:true を指定しても、自動送信されません。
自動送信を使いたい場合は、設定を明示的に変える必要があります。
この設計にした理由は、AIアプリへの誤送信を避けたいからです。
AI連携は便利ですが、暴走すると面倒です。
だから最初は、
「便利さより、安全性を優先する」
という設計にしています。
9. シークレット検出も入れた
もう1つ入れたのが、シークレット検出です。
プロンプトの中に、APIキー、秘密鍵、.env、password、tokenのような文字列が含まれている場合、クリップボードへ入れる前に止めるようにしています。
これはかなり重要です。
AIアプリ間でプロンプトを渡す仕組みを作ると、うっかり機密情報を別アプリへ投げてしまう可能性があります。
特に開発作業では、環境変数やトークンが文章に混ざることがあります。
そのまま貼り付けると危険です。
なので、送る前に一度止める。
完璧な検出ではないとしても、何もないよりはかなり安全です。
10. 返答取得まではやらない
今回の仕組みは、送信専用です。
つまり、相手アプリの返答は取得しません。
ここも意図的にそうしています。
将来的には、Claudeへ送って、Claudeの返答を取って、それをCodexへ渡して、さらにCodexの返答を戻す、という完全自動リレーも考えられます。
ただ、最初からそこまでやると難易度が上がります。
対象アプリごとにUIが違う。
返答欄の取得も不安定になりやすい。
ブラウザやデスクトップアプリの内部状態を読む必要も出てきます。
そこで今回は、まず「送る」だけにしました。
返答取得まではしない。
この割り切りがあるから、ツールとして小さく作れます。
そして、小さく作れるから、壊れにくくなります。
11. エージェントにはこう指示して作っていった
実際にこういうツールを作るときは、最初から細かいコードを書かせるより、段階的に詰めていく方がうまくいきます。
僕なら、まず司令塔AIにこう伝えます。
GUIアプリ間でプロンプトを受け渡すための、最小MCPサーバーを作りたいです。
目的は、Claude、Codex、AntigravityのようなAIアプリへ、別のAIエージェントからプロンプトを貼り付けることです。
最初は返答取得は不要です。
クリップボード経由でプロンプトを貼り付け、必要ならEnterまたはCtrl+Enterで送信できる構成にしてください。
ただし、安全性を重視したいので、初期状態では自動送信を禁止し、貼り付けのみで止めたいです。
また、APIキーや秘密鍵のような機密情報が含まれている場合は、クリップボードへ入れる前にブロックしてください。
Node.jsとMCP SDKを使う前提で、ファイル構成、設定ファイル、実装手順を設計してください。この指示で、まず全体設計を出してもらいます。
次に、実装担当のAIへこう渡します。
以下の設計に従って、ローカルPC上のGUIアプリへプロンプトを送るためのMCPサーバーを実装してください。
要件:
- ツール名は send_prompt_to_app
- app, prompt, submit, confirm_token, timeout_sec を受け取る
- app は config/apps.json で管理する
- safety は config/safety.json で管理する
- safe / token / open の3モードを用意する
- 初期設定は safe
- safe では submit:true でも貼り付けのみ
- token では confirm_token が一致した場合のみ送信
- open では自動送信を許可
- APIキー、秘密鍵、.env、password、token らしき文字列がある場合はブロック
- PowerShellで対象ウィンドウを前面化し、クリップボード経由で貼り付ける
- 返答取得はしない
- 初回テストは submit:false で行う
READMEも作成してください。こういうふうに、司令塔AIで設計し、実装AIに渡す。
これがかなり実務的です。
12. この仕組みの面白いところ
この仕組みの面白いところは、単にコピペを自動化しただけではないところです。
AIを「単体のチャット」として使うのではなく、役割分担できるようになります。
たとえば、
Claude:
全体設計を考える
Codex:
実装する
Antigravity:
別環境で高速に試すこのように分けられます。
そして、Claudeにこう言えるようになります。
この内容をCodexに送って、実装方針を確認させてください。または、
この修正案をAntigravityに送って、別案を出させてください。もちろん、現時点では返答は自動で戻ってきません。
でも、プロンプトを送る手間が減るだけでも、AIアプリの使い分けはかなり楽になります。
13. 将来的にはAI同士の議論リレーもできる
今回の仕組みは送信専用ですが、考え方としては、AI同士の議論リレーにも発展できます。
たとえば、ClaudeからCodexへプロンプトを送る。
そのプロンプトの最後に、こう書いておく。
この内容について回答したあと、要点をClaudeへ返すための短いまとめも作ってください。さらに人間がそのまとめをClaudeへ戻す。
または、自動送信の範囲を広げて、決められた回数だけAI同士で議論させる。
たとえば、
ClaudeとCodexで3往復だけ議論してください。
3往復したら、最後に結論をまとめて終了してください。このような運用も考えられます。
ただし、ここは慎重に扱うべきです。
AI同士の自動リレーは面白いですが、無制限に回すと危険です。
だから回数制限をつける。
最後に必ずまとめを書かせる。
途中で止められるようにする。
こういうルールが必要になります。
現時点では、まずは送信専用で十分です。
小さく始めて、安全に使いながら、必要に応じて広げる。
この順番が大事だと思っています。
14. これは「AIを使う側」から「AIをつなぐ側」へ行くための一歩
今、多くの人はAIツールを単体で使っています。
Claude Codeを使う。
Codexを使う。
Antigravityを使う。
それぞれ単体でも十分便利です。
でも、実務で使っていると、そのうちこうなります。
「このAIに考えさせた内容を、別のAIに渡したい」
「設計と実装を分けたい」
「重い思考は高性能モデルに任せて、実装や検証は別の環境に回したい」
「チャット欄を汚さずに、裏側でプロンプトを送れるようにしたい」
ここまで来ると、AIを使うだけではなく、AI同士をどう接続するかが重要になります。
今回作ったOkihiro App Hub MCPは、そのための小さな実験です。
15. 注意点
この仕組みは便利ですが、万能ではありません。
できることは、あくまでプロンプトを対象アプリに渡すことです。
相手アプリの返答取得まではしません。
入力欄以外の複雑なUI操作も保証しません。
対象アプリのウィンドウタイトルが合っていないと、失敗することもあります。
また、自動送信を使う場合は注意が必要です。
最初は必ず貼り付けのみでテストする。
機密情報を含むプロンプトは送らない。
自動送信を使う場合は、なぜ使うのかを明確にする。
このあたりは守った方がいいです。
AI連携は便利ですが、安全設計なしでやると危険です。
だからこそ、最初は小さく、送信専用で、貼り付け確認を挟む。
これが現実的だと思っています。
16. まとめ
今回は、Claude Code、Codex、AntigravityのようなAIアプリへ、AIエージェントからプロンプトを送るための小さなMCPサーバーを作った話をしました。
ポイントは以下です。
- AIアプリを使い分けると、プロンプトの受け渡しが面倒になる
- 司令塔AIと実行AIを分けると、AI制作フローを組みやすくなる
- MCPを使うと、AIエージェントから外部ツールを呼び出せる
- 最初は返答取得まで狙わず、送信専用にするのが現実的
- 自動送信より、まずは貼り付けのみが安全
- safe / token / open のように送信モードを分けると運用しやすい
- 将来的にはAI同士の議論リレーにも発展できる
今回作ったのは、巨大な自動化システムではありません。
人間が毎回やっていた「プロンプトを別アプリへ渡す」という小さな作業を、MCPで道具化しただけです。
でも、この小さな橋があるだけで、AIアプリの使い分けはかなり楽になります。
AIを使うだけではなく、AI同士をどうつなぐか。
これからのAI制作フローでは、ここがかなり重要になると思っています。
コメント