AI同士の伝言は、置き場ではなく相手に渡す ― 2台のMacで別々のAIを動かして分かったこと

共有フォルダに置いただけの伝言は、届きません。誰かが「伝言ある？」と聞くまで、そこにあるだけです。届けるには、相手の「いま動いている会話」に直接渡す必要がありました。

この記事は、2台のMacでそれぞれAIを動かしている1人会社が、AI同士のやりとりで踏んだ2つの失敗と、そこから決めたことの記録です。

なぜ2台に分けているか

弊社のAI（Claude）は、自宅の端末と持ち出し用の端末の2台で動いています。役割は分けています。

• 自宅の端末には、クラウドの鍵（認証情報）と、社内アプリの実体を置きます。定期実行の仕事もここで回します
• 持ち出し用の端末には、鍵を置きません。書ける範囲を絞り、必要なら自宅側に頼みます

鍵を1台に閉じ込めるのは、持ち出す端末を失くしたときの被害を小さくするためです。その代わり、持ち出し側のAIが「自宅側でやってほしいこと」を抱えます。ここに伝言の仕組みが要ります。

最初の形：共有フォルダの伝言板

最初は、クラウド同期のフォルダに伝言板を作りました。「自宅宛」「持ち出し宛」「処理済み」の3つの箱を用意し、定型の依頼は機械が読める形式で、自由な相談は文章で置きます。安全な作業は相手のAIがそのまま実行し、危ない作業は社長に確認してから実行する、という決まりも入れました。

形としては悪くありません。ただ、届きませんでした。

失敗1：5日間、誰も見なかった

9月10日に持ち出し側から置いた依頼が、5日間そのままでした。自宅側のAIは、社長が「伝言ある？」と聞いたときだけ箱を見に行きます。誰も聞かなければ、誰も見ません。置いた側は「置いた」で安心し、受ける側は「聞かれていない」で止まります。人の組織で回覧板が止まるのと、同じ構図です。

さらに、受け口の名前を取り違える事故もありました。持ち出し側のAIが自分宛の箱ではなく別の名前の箱を見て「新着なし」と報告したのです。箱が増えるほど、こういう間違いは増えます。

変えたこと：置いたら、相手を呼ぶ

そこで、伝言を置いたら終わりにせず、相手の端末で動いている会話を探して、直接メッセージを送ることにしました。

これは、AI（Claude Code）に組み込まれたセッション間連携の機能です。同じ端末の会話同士なら端末の中で直接届きます。別の端末の会話へは、提供元のサーバーを経由して届きます。受け取った側のAIは、作業の合間か次の手番でそれを読みます。

送るときの決まりも作りました。

• 1行目で用件が分かるように書きます。相手側では最初の1行しか見えません
• 置き場のフルパス、ファイル名、要点、注意点を本文に入れます
• 「読むだけお願いします。実行は社長の指示があってから」と明記します。相手の設定を書き換える依頼は、勝手に走らせません
• 同期に間があるので「見えなければ少し待って」と添えます

社長の評価は「それはいい伝言の方法だ」でした。以来、伝言が止まることはなくなりました。

組み込みの連携と、置き場の使い分け

組み込みの連携ができたなら、置き場は要らないのでは、と思うかもしれません。両方使っています。役割が違うからです。

組み込みの連携で送れるのは、文章だけです。ファイルも、送り手の会話の中身も渡りません。相手の端末が止まっていれば、届くのは相手が再びつながったときです。受け手の設定によっては、人の承認待ちで保留になります。送った側からは、相手が読んだかどうかまでは分かりません。

一方、置き場に置いたものは残ります。ファイルも添えられ、相手がいつ起きても読めて、後から経緯を追えます。

そこで、次のように分けました。

• 知らせるのは組み込みの連携。1行目で用件、本文に置き場のパス
• 中身と記録は置き場。依頼の本文、添付のファイル、処理済みの控え
• 実行するかどうかは、受け手の側の社長が決める

組み込みの連携にも、同じ考えの決まりが最初から入っています。別の会話から届いたメッセージは、人の承認の代わりになりません。受け手の設定を書き換える根拠にもなりません。「読むだけ。実行は社長の指示があってから」と書いてきた決まりは、機能の側でも守られています。

失敗2：クリップボードは共有の資源だった

もう1つ、別の種類の失敗があります。

8月22日、ブログのアイキャッチ画像を差し替える作業で、AIが画像をクリップボードに載せ、ブラウザで貼り付ける手を使いました。載せた直後には画像しか入っていないことを確認していました。ところが貼り付いたのは、画像ではなく、その時点でクリップボードに入っていたパスワードらしき文字列でした。貼り付けの操作が30秒ほど待ちに入っている間に、クリップボードが別の内容で上書きされたとみられます。

結果、ブログの下書きと、その版の履歴に認証情報が書き込まれました。公開前の下書きで、外からは見えない状態でしたが、本文を消すだけでは足りません。履歴に残るので、投稿ごと完全に削除し、その値も変更しました。

教訓は単純です。クリップボードは人とAIが共有している資源で、中身は保証できません。ファイルはファイルとして渡します。どうしてもクリップボードを使うなら、貼った直後に中身を読んで確かめてから次に進みます。

まとめ：AIの間にも、確実な経路が要る

2つの失敗に共通するのは、「置いた」「載せた」で安心し、届いたか・正しく届いたかを確かめていなかったことです。原因はどちらもAIの欠陥ではなく、こちらの運用の設計でした。

1. 伝言は置き場に置くだけでなく、相手の会話に直接渡す
2. 1行目で用件、本文に置き場と注意点、実行は社長の指示後
3. 共有の資源（クリップボード）を経路にしない。使ったら直後に確かめる

AIが複数になると、AI同士の連絡も業務設計の対象になります。人の組織で決めてきたことが、そのまま要りました。

関連する話として、置き場が2つあると片方が片方を巻き戻す件（https://data-parade.com/dpcore-one-source-of-truth/）と、起票するAIと直すAIの間に台帳を置く件（https://data-parade.com/batonboard-two-ais-one-board/）も書いています。あちらは案件の記録の置き方で、こちらは端末間の軽い伝言の届け方です。

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。