少し前に、「AIすげぇ。生産性が上がるとか言うてる場合じゃなくなってきた」という記事を書いた。
複数のAIに作業を頼んでみると、人間が自分で手を動かすときとは、ずいぶん違う感覚になる。そんな話やった。
その後、趣味でさらにいじっていたら、次の段階まで来た。
AI同士をつないで、直接相談できるようにしてみた。
使っているのは、CodexとGitHub Copilot。
今回の手元の構成では、Codex側がGPT6.1 Sol、Copilot側がClaude Sonnet 5.5や。
この二つの間に、自作のローカルMCPサーバーを挟んだ。
……こう書くと、なんか難しいことをやってる感じがする。
やりたいことは単純や。
「Codex、お前が迷ったところ、Copilotにも聞いてみてくれ」
これである。
ワイがコピペするの、そろそろやめたい
別々のAIを使っていると、片方の回答を、もう片方に見せたくなることがある。
こっちで出た案を、あっちにも確認してもらう。
あっちの指摘を、こっちに持ち帰る。
それ自体は便利なんやけど、毎回人間が間に入ると、だんだんこうなる。
AIは賢い。
AIは速い。
その間でワイが、文章をコピーして貼り付けている。
最先端のAIを二つ使って、人間がクリップボードを担当している。
何かがおかしい。
そこで、CodexからCopilotに依頼を送り、返ってきた回答を受け取れる橋を作った。MCPは、その橋をCodexから使うための仕組みとして利用している。
これで少なくとも、相談文を運ぶところまでワイが毎回担当する必要はなくなる。
地味やけど、ここがつながると、できることが変わってくる。
つながっただけでは、まだ面白くない
ただ、二つのAIをつなげば、それだけでうまくいくわけでもない。
何を相談するのか。
いつレビューを頼むのか。
指摘が返ってきたら、どう扱うのか。
そのへんを決めないと、回答が一つ増えるだけで終わってしまう。
そこで、AGENTS.mdに連携のルールを書いた。
ソースの変更がある程度まとまったら、Copilotにレビューを頼む。テストの結果も見てもらう。実装方針に迷ったときには、ワイに聞く前に、まずCopilotにも相談する。
そして、ここははっきりさせている。
進行と判断を担うのはCodex。Copilotの指摘を全部採用する必要はない。
指摘が正しいか、ソースや条件と照合する。採用するなら反映する。採用しないなら、その理由を残す。
二つのAIに同じことを言わせて、「ほら、二人とも賛成してるから正しい」と安心したいわけではない。
違う見方が入ったときに、そこから判断を進めてほしいんや。
趣味でAIをつないでいたはずが、気づいたらAI同士の付き合い方まで文章にしていた。
ケーブルつないで終わり、とはいかんらしい。
実際に、研究計画を相談させてみた
今回の記録に残っているのは、競馬を題材にした機械学習の研究計画についての相談や。
実装を始める前に、検証の進め方に落とし穴がないか、CodexからCopilotに確認している。
競馬に詳しくなくても、話の中心は分かると思う。
過去のデータで予想の仕組みを作って、別の期間で試す。そのとき、後から分かった結果を、うっかり予想に混ぜてしまわないか。何度も調整して、たまたま良かったものだけを拾っていないか。
そういう確認や。
実際の依頼と回答、Codexの判断を短く要約すると、こんな流れになる。
Codexの相談
調整する期間と、最後に評価する期間を分けたい。予想と買い目を固定してから結果を照合する。この計画の落とし穴や、試行数の数え方を確認してほしい。
Copilotの助言
当時は使えなかった情報が混ざらないようにすること。最後の評価結果を見ながら調整しないこと。失敗や中断を含め、試した構成を記録すること。回収率だけで結論を出さないこと。
Codexの判断
検証期間の分離や、予想を固定する方針は採用する。ただし、失敗した試行の記録と、ユーザーが指定した有効な調整回数は区別する。
これ、ちゃんと条件を突き合わせている。
Copilotの助言を受け取って、Codexが元の依頼に照らし、扱いを決めている。
ワイが二つの回答を並べて比較するところから、AI間のやり取りを見て、その判断を確認するところまで進んできた。
「10回試した」の中身まで確認してくる
今回、特に面白かったのは、試行数の扱いや。
Copilotは、試した構成を全部記録するように助言した。失敗したものや、中断したものも含めてや。
これは、何をどれだけ試したのかを残すという意味では納得できる。
一方、ワイが指定していた「10回以上の調整」は、失敗した処理を10回並べたら達成、という意味ではない。
そこをCodexは区別した。
失敗や中断もログには残す。でも、有効な調整回数を失敗だけで満たしたことにはしない。
こういうところが、ただ回答を受け取るだけとは違う。
「10回やりました！」
「うち何回、ちゃんと調整できたん？」
ここを曖昧にしたくないのは、人間でもAIでも同じやな。
ほかにも、Copilotの提案をそのまま決めず、実際の結果状態や仕様を確認してから扱いを決める項目があった。
相談相手の回答を尊重しつつ、丸のみにはしない。
そういう判断まで記録に残っているのが、今回の面白いところや。
なお、この対話は実装前の設計相談である。競馬予想が当たるようになったという報告ではない。
そこまで一気に話を飛ばすと、AIの連携実験が、いつの間にか必勝法の広告になってしまう。
まだそこには行ってない（笑）。
Copilotは毎回、別セッションで呼んでいる
今の運用では、Copilotへの依頼は一回ずつ別セッションにしている。
そのため、Copilot側の同じ会話に、過去のやり取りが積み上がっていく形にはなっていない。
ここは悩ましい。
同じセッションで続ければ、前に相談した経緯を踏まえて話せる。その便利さはある。
ただ、以前の前提や判断まで引きずる可能性もある。条件が変わったのに、古い話の続きとして考えてしまうのも困る。
なので、いったん今は、毎回必要な情報を渡して相談する方式にしている。
たとえるなら、毎回まっさらな紙を渡して、「今回はこの条件で見てくれ」と頼む感じや。
毎回説明する手間はある。
その代わり、前の話にどれだけ影響されているかを気にしながら進める必要は減る。
どっちがええかは、もう少し使ってみないと分からん。
今は、知見をどう引き継ぐかも含めて実験中や。
AIが二つになっても、勝手に正解にはならん
ここは、使っていて忘れたくないところでもある。
AI同士が相談したからといって、正しさが保証されるわけではない。
同じ勘違いをする可能性もあるし、渡した前提が足りなければ、もっともらしい回答が二つ並ぶこともある。
だから、残しているのは「AIが何か相談していた」という雰囲気だけではない。
何を依頼したか。
どんな回答が返ったか。
Codexが何を採用し、どこを保留したか。
そのやり取りを、後から読める形にしている。
今回の対話記録でも、確認できるのは送信した依頼、受け取った回答、Codexの判断や。Copilot内部の思考まで見えているわけではない。
それでも、判断の経緯が残ると、次に見直すときの材料になる。
趣味の実験でも、「なんかうまくいった気がする」で終わると、次に同じことをやったとき困るからな。
50代、AI同士の橋を作って遊ぶ
「MS-DOSから生成AIへ。今度は僕たちが淘汰される時代がやってきた」という記事では、新しい技術についていこうとする、50代の自分の話を書いた。
今回も、その続きではある。
ただ、危機感だけで触っているわけでもない。
自分で橋を作る。
AIから別のAIに依頼が届く。
回答が戻ってくる。
その回答を踏まえて、次の判断が進む。
これが、普通に面白い。
「お、返ってきた」
「そこ指摘するんか」
「お前、それはそのまま採用せんのやな」
ログを見ながら、そんなことを思っている。
便利なものを使う楽しさもあるけど、自分でつないだ仕組みが動く楽しさは、また別や。
昔から、コンピューターをいじっていて好きだったのは、こういう瞬間やった気がする。
扱うものは変わったけど、やってる本人はあんまり変わってないのかもしれん。
コーヒーを飲む前に、もう一つ試したくなる
AIに任せたら、のんびりできるかなと思っていた。
ところが、つないでみると、次に試したいことが出てくる。
この条件も渡したらどうなる？
指摘を修正した後、もう一度見てもらったら？
毎回の相談で得た知見を、次にうまく渡すには？
結局、また触っている。
AIのおかげで空いた時間を、AIの実験に使っている。
趣味としては、まあ正しい使い方やと思う。
今のところ、CodexとCopilotの間には橋ができて、相談と判断が回り始めた。
次は、そのやり取りから得たものを、どう次の実験につなげるかやな。
……その前に、コーヒー入れてこよう。
戻ってきたら、またログを読むと思うけど。