複数PCのAIへ仕事を渡すために「かな」の窓口と記憶を作り直している
目次
複数台のPCで使っているAIへ、一つの会話から仕事を任せたい。
あるPCのCodex、別のPCのClaude Code、ローカルモデルにつないだエージェント実行基盤のPiなどを、対象のプロジェクトや作業に応じて使う。作業の権限と担当、使うモデルも自分で決め、その指示と進捗、確認事項、できたものを同じ窓口へ戻す。これが、ブラウザ窓口・記憶・作業台帳・実行層を束ねる自作ゲートウェイ「かな」で進めている仕組みだ。
複数のAIと実行環境を選び、仕事の順序や受渡し、状態を管理することを、ここではオーケストレーションと呼ぶ。
複数PCへの作業配分まで一気に組むのではなく、まずは手前に必要な会話窓口、記憶、作業の受付と状態管理を整え、手元のMac上にある担当AIへ作業を渡すところを試している。
前回のかなチャットはブログ制作に寄せて作っていた。
今回のブログ記事、画像生成、Backlogなどの接続は、作業の入口と結果の戻し方を具体的な用途で確かめるためにも使っている。ここから各PCにある作業環境へ対象を広げていく。
どのPCの、どのAIに仕事を任せるか
たとえば「開発PCにあるプロジェクトをCodexで直して」「別PCのPiでこのファイルを整理して」と頼みたい。
ただ、いま別PCへこうして仕事を投げられる状態まで完成しているわけではない。
PCごとにあるファイル、実行環境、ログイン済みのAI、プロジェクトの処理ルールは異なる。
窓口からPCへ接続できることに加えて、指定したAIを正しい場所で動かし、確認が必要ならチャットへ戻し、終了したかを判断できる仕組みがいる。
flowchart TD
U["ブラウザの会話窓口<br/>かな"]
Q["PiとQwen<br/>相談と指示内容の整理"]
G["Mac上の実行層<br/>対象照合・受付・状態管理"]
D["HDD上の記憶と作業台帳"]
M["このMacの担当CLI<br/>Codex・Claude・Antigravity"]
A["別PCのCodexやClaude<br/>今後の接続対象"]
B["別PCのPiとローカルモデル<br/>今後の接続対象"]
R["結果・確認事項・成果物"]
U <--> Q
Q <--> G
G <--> D
G --> M
G -.-> A
G -.-> B
M --> R
A -.-> R
B -.-> R
R --> G
G --> U
classDef future stroke-dasharray: 5 5;
class A,B future;実線は手元のMac内で接続を進めた部分、破線はこれからの複数PCへの展開を表している。
ブラウザを別PCから開けることと、そのPC上のAIへ作業を渡せる状態は別で、前者が動くからといって後者まで整ったわけではない。
作業権限と実行担当の分離
PCを選ぶだけでなく、どの作業をどのAIへ任せ、どこまで許可するかも切り替えられるようにしたい。
調査、実装、確認、公開で担当を分けることもあれば、指定したAIに一つの作業を通して任せることもある。窓口のQwenと、タスクを実行するエージェントの役割も分ける。
たとえば調査担当には読取まで、実装担当には対象フォルダの編集とテストまで、公開担当には今回の成果物の公開操作までを任せる。
今の実行経路でも、記事の作成ではCodexの計画からClaudeの執筆へ渡す、といった接続済みの分担がある。
最終的には、対象プロジェクトの規則と今回の指示内容に合わせ、実行するPC、担当エージェント、モデル、許可する操作を自分で選べるようにする。
AIの選択と作業権限は別の条件として持たせ、担当を変えたことで編集や公開の許可まで一緒に変わる仕組みにはしない。
Muse、dots、Coworkとの比較
会話から指示を出し、バックグラウンドで作業を進め、結果を受け取る使い方は既存製品にもある。
一本の継続会話や進捗表示も含め、かな固有の機能というわけではない。
公式資料で確認できる接続の範囲と、今回つなぎたい対象を並べるとこんな感じになる。
| 製品・構成 | 公式資料で確認した範囲 | 今回の目的に照らして確認がいる部分 |
|---|---|---|
| Meta Muse | 専用のコンピューター、ターミナル、ブラウザを持ち、継続会話とバックグラウンド作業を扱う | 手元の複数PCにある既存CLIと作業規則を、どうやってまとめるか |
| OpenAI dots | クラウドのコンピューターに加え、個人PCを同時に1台接続できる。ローカルのWork・Codexタスクの作成や既存Codexタスクの継続に対応 | 複数PCを横断し、ClaudeやPiなども含めて担当と実行条件を選ぶ接続 |
| Claude CoworkのDispatch | 継続会話からデスクトップへ仕事を渡す。開発作業はClaude Codeで実行する | 別PCのCodexやPiも含む、自分の各環境への受渡し |
| 今回のかな | Mac上の窓口、共通の記憶と作業台帳、同じMacの複数AIへの限定した作業指示 | 別PCの実行先を接続し、承認・中断・復旧まで通すこと |
Cowork全体にはクラウドで動く使い方もあり、上の比較はローカル実行に関係するDispatchを取り出したものだ。
手元の複数PCと異なるCLIをそのまま束ねる条件までは、今回確認した資料の範囲では整っていないと判断している。
接続先の権限管理も既存製品にある。
たとえばdotsはアプリの既存権限を引き継ぎ、メールの読取と送信を分けられる。Museも、メール送信や購入などで確認を入れる設計を説明している。承認機能の有無に加えて、その権限で取得した情報がどこへ渡るかまで確認しておく。
実行モデルと推論設定の記録
手元でdotsからCodexへ指示したときには、そのCodexがどのモデルで動いているのか分からなかった。
Codexに任せたことが分かっても、使いたいモデルや推論設定で実行されたかを手元で把握できない不便がある。ここは自分で組むなら確認できるようにしたい。
そのため、かなの作業台帳には担当AIの名前に加えて、設定したモデル、推論の強さを指定するreasoningなどの値、実行時に取得できたモデル情報を分けて残している。
現在のMac内の接続でも、Codexへ渡したモデル・推論強度の引数と、担当の実行ログを保持している。
Claudeのモデル名は起動イベントから取得し、設定上の推論強度と実行時に確認できた値を区別する。実行イベントに値がなければ、設定どおりだったはずという推測では埋めない。
これによって、指定した担当、モデル、実際に確認できた実行情報を作業ごとに辿れる。
複数PCへ広げるときにも、この区別を保ったまま渡せるようにしておく。
OpenClawとの重複と固有の要件
OpenClawにも、別マシンでコマンドを動かすノードや、エージェントごとのモデル・作業領域・利用ツールを設定する仕組みがある。
モデルや作業領域、利用ツール、遠隔実行先を分ける機能は、かなで必要としている要件と共通している。
そのうえで今回の実装で詰めているのは、自分がすでに使っているPC、各AIのCLI、認証、プロジェクトの規則をどう割り振るかだ。
作業ごとに対象と担当を確定し、既存の変更を保ち、実際の処理結果を戻す。指定されたAIが使えないときに、勝手に別のAIへ切り替えないこともここに含まれる。
いまはPiを窓口の実行基盤に選び、既存の環境に合わせた接続を一つずつ増やしている。
音声サーバーから引き継いだ長期記憶
HDDへ会話を残す仕組みは、今回の窓口から始めたわけではない。
音声チャットへ長期記憶を付ける設計で、セッションを切っても以前の会話を探せるようにし、必要なときだけ元の発言へ戻る構成を考えていた。その後、音声サーバーへの組込みと聞き返しの試験も行ってみた。
今回の記憶は、その続きにある。
音声で話したことを覚えておくという課題から、ブラウザのかなや各PCのAIと話した内容も、モデルのセッションをまたいで参照できるように広げた。
複数のAIへ作業を割り振るなら、以前に決めた条件や指示の原文を取り戻せるようにしておく必要がある。
特定のモデルが会話中に覚えていることだけに頼るのではなく、どこでの会話かと原文を残す考え方を引き継いでいる。HDDは、その共通の原文と作業記録を保持する場所として使っている。
音声側のベクトルDBであるQdrantを使った記憶検索に対して、今回の通常会話はまずSQLiteの原文保存と部分一致検索を使う。長期記憶として解決したい課題はつながっているが、検索方式と接続の範囲は分けて実装している。
外部AIへの情報境界
複数のAIをつなぐと、アプリへの接続許可だけでは情報の行き先が定まらない。
取得するプログラム、会話をするQwen、実作業をするCodexやClaude、自分が見る画面のそれぞれについて、必要な内容を整理した。
認証トークンをモデルへ渡さなくても、APIで取得した本文をツールの返り値に含めれば、その本文はモデルに入力される。
また、HDDに原文を保存していても、必要な部分を検索して会話へ戻すときにはQwenへ送信する。保存場所がローカルなことと、推論に使う情報がローカルから出ないことは別だ。
現在の実装での線引きはこんな感じになっている。
| 情報 | 現在の扱い | AIへ渡る範囲 |
|---|---|---|
| 接続用トークンや認証ファイル | サーバーや各CLIの認証処理で使う | 値そのものを会話やモデルへの指示文へ入れない |
| 作業先の名前・識別子・パス | 対象の選択と照合に使う | 対象一覧のプロジェクト名や作業パスなどはQwenへ返る。接続先の情報をすべて隠しているわけではない |
| 普通のチャットと検索した過去の会話 | HDDへ保存し、必要な原文を会話に戻す | 直近の会話と、検索して取得した原文をQwenへ渡す |
| 読取対象の添付 | 原本を保存し、本文抽出や画像参照を行う | 内容を扱う作業では、対象の本文や画像をAIへ渡す |
| Backlog・ChatWork | 設定済みの対象から課題やメッセージを実際に取得 | 回答や作業に必要な取得内容をQwenや担当AIへ渡す |
| Gmail | 検索結果や本文を専用の保存先から画面へ表示 | 件数や取得状態などをQwenへ返し、本文は渡さない |
| GA4・Search Console・AdSense | 取得したレポートをチャット内の専用表示へ出す | アクセス解析のGA4などを含め、取得状態だけをQwenへ返し、数値は渡さない |
| 要約を指定した録音 | 原本を保持し、バックグラウンドで文字起こしと要約を行う | 音声と認識テキストを推論基盤のModelScopeへ送る。後日の検索でも候補原文をQwenで照合する |
| リポジトリの作業ファイル | 担当CLIが指定した場所で読み込んで編集する | クラウドモデルを使う担当なら、読んだコードや資料はその担当の推論先へ渡ることがある |
Gmailやレポートの欄は、今回の実装で本文や数値をモデルへ返していない設定だ。
自分がそれをチャットへ貼り付ければ、通常の入力としてQwenへ送られる。接続して画面で読めることを、そのままAIの要約や分析まで許可した設定にはしていない。
一方、BacklogやChatWorkは内容を参照して回答するため、本文がモデルへ渡る。
すべての接続先を一律に隠す構成ではなく、本文を渡さない接続では内容に踏み込んだ回答ができず、渡す接続ではその送信先を含めて判断する。
PC上でCLIが動くとしても、そのCLIがクラウドモデルを使えば推論は外部で行われる。ローカルモデルを使うPiの経路は別途確かめる形にして、現在のかな全体はローカル完結ではない。
会話・記憶・作業台帳の基盤
窓口の会話には、クラウドAPIのQwen3.7-Plusとエージェント実行基盤のPiを使っている。
PiのRPC（遠隔呼出）モードをPythonのサーバーから呼び、記憶検索、添付参照、作業受付など、用途を絞ったツールを提供する。Qwenへ任意のシェル実行や既存リポジトリの編集を直接開放する形にはしていない。
Webアクセス用の画面はこのMacで動かし、プライベートネットワーク経由でローカルWebを安全に開けるTailscale Serveで手元の端末から開く。
画面は一続きのやり取りで、端末やブラウザを変えても同じ会話へ戻る。作業の担当や更新時刻、成果物は別タブの専用ページで確認できる。
会話テキストと作業状態は、外付けHDD上のSQLiteへ保存している。
通常は直近の会話を読み、不足があれば原文を検索する。導入済みの各AIの保存フックからも、発言元・端末・セッションを区別して会話を登録し、サーバーへ送れない分は各PCのキューに保持する。
作業台帳では、受付、担当の開始、処理中、確認待ち、完了、失敗を分ける。
かなが返答で安請け合いしただけでは受付にせず、今回の指示と紐づく保存済みの作業IDを手がかりにする。画面の文字列抽出に頼るのではなく、構造化イベント、セッションID、終了コード、成果物で判定する。
「今どうなっている？」には、Qwenが台帳の現在状態を取得して答える。
以前の返答に残る「実行中」を現在の状態へ読み替えない。終了を確認できない作業は状態不明として保持し、再起動を理由に同じ書込や公開処理をやり直さない。
Mac内の複数AIへの受渡し
実行先を別PCへ増やす前に、このMacで具体的な作業を通してみた。
Qwenが相談を受け、実行の指示と条件が整ったら担当へ渡す。裏での作業中も、チャット側では別の話を続けられる。
| 試した連携 | 確認したこと |
|---|---|
| 日本語の記事ドラフト | Codexの計画、Claudeの調査・執筆、保存、Codexによる出典照合 |
| 保存済み記事の英訳 | Antigravity（AGY）の全文英訳保存とQwenの読者視点確認 |
| 単独HTMLの試作 | Codexの計画、Claudeの実装、確認と修正1回、操作確認、プレビュー・ZIP取得 |
| 検証用リポジトリでの作業 | 実課題の読取調査と、検証用リポジトリでの実装・差分確認 |
| Backlog全体の処理 | 対応先の規則をCodexが読み、実課題を取得し、終了時に再走査して通知 |
| 時間指定と反復 | 状態確認2回の終了、通知の取消、単発の担当起動 |
この分担では、Qwenがすべての工程を直接動かすのではなく、Pythonの実行層が担当CLIの起動と保存を管理する。
記事と個別実装では計画・実作業・確認を分け、Backlog全体の処理では対象リポジトリのCodexが、その場所の規則に従って課題の選別から終了確認まで担当する。
状態を確認する問い合わせと、実際に仕事を動かす指示も分けた。
「Backlogが来ている？」は読取だけで、「確認して処理して」は作業指示になる。予約にもその種類と対象、元の指示文を保存し、予定時刻には保存した条件を使う。終わりの条件のない反復を勝手に無期限では登録しない。
添付の内容読取や画像生成、録音の文字起こしも別の接続として試している。
画像はバックグラウンドで生成して元の会話へ戻し、録音は原本と文字起こしした発話区間を保持する。
複数PC接続に向けた課題
次の段階では、実行先のPCとプロジェクトを確定し、そのPCにあるAIを既存の設定で起動して、結果を元のチャットへ戻す必要がある。
全PCの認証や作業環境を一つに置き換えるのではなく、既存の環境をそのまま活かして接続する。
| 確認する対象 | 複数PCで必要になる確認 |
|---|---|
| 実行先 | 指定されたPCとプロジェクトに到達し、別の場所で処理しないこと |
| 担当AI | 指定したCLI・モデルが使え、警告や確認なしで代替しないこと |
| 作業権限 | 担当を切り替えても、対象フォルダと許可する操作を保てること |
| 情報の受渡し | 窓口と担当のそれぞれへ、何を送ったか説明できること |
| 継続と中断 | 実際のセッションを識別し、確認事項や中断結果を窓口へ返せること |
| 障害後の状態 | PCや通信が止まっても、完了・失敗・終了不明を区別し、書込を重複実行しないこと |
別PCでの短い作業指示から途中確認、結果の受け取りまで通すことが、次のステップになる。