運用ドキュメント / 2026-08-03
外出先の Lark チャットから、手元の PC の AI エージェントへ作業を頼める仕組みです。 AI が何かを書き換えようとするたび、実行前にチャットへ確認カードが届き、 本人が承認するまで先へ進みません。
利用者はチャットへ依頼と承認を送り、ブリッジがそれを AI エージェントへ取り次ぎ、結果が同じチャットへ返ります。この 3 つだけで完結し、別途サーバーを用意する必要はありません。
本人と Bot の 1 対 1 チャット。ここに依頼を書き、ここへ確認カードと結果が返ります。
チャットを待ち受け、届いた依頼を AI エージェントへ取り次ぎます。結果も同じ経路で返します。
依頼を解釈し、ファイル操作やコマンド実行を行います。実行の直前に必ず確認の関門を通ります。
書き換えを伴う操作が 1 回含まれる場合の、標準的な 1 往復です。
普通の日本語で構いません。特別なコマンドや記号は不要です。
依頼の本文がそのまま AI エージェントへ渡されます。受け付けた印としてメッセージにリアクションが付きます。
ファイルを読む、内容を検索するといった、何も書き換えない操作はここで済ませます。この段階では確認は入りません。
これから実行する内容をカードに載せてチャットへ送り、そのまま待機します。承認されるまで実行には進みません。
ボタンを押すだけです。読まずに時間が過ぎた場合は、実行されずに中止されます。
承認したカードが「実行しました」に変わります。カードの書き換えでは通知音が鳴らないため、完了メッセージも別に届きます。
ここまでで 1 往復です。書き換えが複数あれば、その回数だけ 4 から 6 を繰り返します。
依頼を出してから結末が返るまで、誰が何をするかを時系列で並べたものです。書き換えが 1 回含まれる場合を示しています。
この時点で返信カードが作られ、以降その場で内容が更新されます
報告が 2 か所に出るのは意図したものです。上の返信カードは作業中ずっと更新され続け、下の完了カードは終わったことを一番下で示すために送られます。確認カードが 1 枚も出なかった場合、完了カードは送りません。
ファイルを見るだけの操作まで毎回尋ねていては作業が進みません。実行の直前に、次の順で振り分けています。
判断がつかないものは、通す側ではなく確認する側に倒します。新しく増えたツールや想定外の入力を、黙って許可することはありません。
確認カードを出すこと自体が適切でない領域があります。ここが設計の要です。
鍵や認証情報を扱ってよいかどうかは、技術的な知識がなければ判断できません。 それを承認カードで尋ねると、意味の分からないまま「よく分からないが押す」が起きます。 これでは確認したことになりません。
そこで、次のものに触れる操作はカードを出さず、その場で中止します。 利用者に是非を尋ねません。
| 種類 | 対象 |
|---|---|
| 鍵・認証情報 | SSH 鍵、署名鍵、クラウドの認証情報、保存された資格情報 |
| 設定ファイル | 環境変数ファイル、各種ツールの認証設定 |
| システム領域 | OS が管理する領域、キーチェーン |
中止されると、AI は「この対象は保護されているので実行できない」と利用者へ伝えます。 利用者が自分の言葉でその対象を名指しして改めて指示した場合に限り、 確認カードを出したうえで実行できるようになります。
解除の根拠になるのは利用者自身の発言だけです。 AI が「必要です」と言っても解除されません。 名指しの表現が一致しなければ、中止されたままになります。 うまく解除できないことはあっても、意図せず通ってしまうことはありません。
技術的な安全性の判断はこちらが引き受け、利用者には 「それはご自分が頼んだことですか」だけを尋ねる形になります。 これなら知識がなくても判断できます。
実際の例で示します。左の区分が、そのままチャットに届くカードの枚数になります。
| 区分 | 対象 | 例 |
|---|---|---|
| 確認なし | 読む・探す・一覧するだけの操作 | ls / cat / grep / git status / git log |
| カード 1 枚 | ファイルの作成や編集、パッケージ導入、外部への送信、Lark の Base・Drive・Docs・カレンダーなどの操作 | ファイル書き込み / npm install / Base のレコード追加 / メールの下書き作成 |
| 警告つきカード | 取り消せない可能性がある操作 | rm -rf / git push --force / Base のレコード削除 / 公開範囲の変更 |
「読むだけ」の判定は、コマンド名だけを見ると簡単にすり抜けられます。次のものは読み取りとは見なしません。
env、command、xargs など）で始まるものsort -o、tree -o など）や、外部プロセスを起動できる指定承認とは「見たものに同意する」ことなので、表示と実行内容が食い違わないようにしています。
{
"app_token": "TESTBASE0000",
"table_id": "tblTEST00000",
"record_id": "recTEST00000"
}送られたカードは、次のいずれかで必ず決着します。押さずに放置した場合も実行されません。
カードを送れなかったとき、判定できなかったとき、確認の仕組み自体が動かせなかったときも、すべて実行しない側へ倒します。
ボタンを押したことが、待機している側へどう伝わるかの説明です。
ボタンを押すと、Lark から常駐しているブリッジへ通知が届き、ブリッジは受け取った内容を自分の記録に残します。 待機している側はその記録を見て、自分が送ったカードへの応答だけを拾います。 新しい接続を増やさずに済むため、Bot もサーバーも追加不要です。
| 条件 | 防いでいること |
|---|---|
| カードごとに使い捨ての識別子を発行し、一致を確認する | 別の確認カードへの応答を取り違えること |
| そのカード自体の ID とも一致を確認する | 識別子だけが合う別経路の応答を拾うこと |
| カードを送った時点より後に記録された分だけを見る | 過去の応答を再利用してしまうこと |
| 承認と拒否が両方あれば、拒否を採用する | 押し間違いの取り消しが無視されること |
| 操作 1 回ごとに記録を分けて保持する | 複数の操作が同時に進んだとき、結果が別のカードへ書き込まれること |
仕組みは 4 つの部品でできています。それぞれが動くきっかけと役割です。
共通の処理（カードの組み立て、送信、応答の照合、危険度の判定）は 1 か所にまとめてあり、4 つの部品はそれを呼び出しています。挙動を変えたいときは設定ファイルを書き換えるだけで済みます。
チャットの基盤には、ボタンの応答を安全に受け取るための正式な仕組みが用意されています。それを使わずに別の方法を採った理由です。
基盤側には、カードのボタンに署名を添えて送り、応答が本物かを検証する手順があります。 本来はこれを使うのが筋です。しかし、外から差し込む形の関門からは使えませんでした。理由は 2 つあります。
| 制約 | 内容 |
|---|---|
| 通知の受け口は 1 本しか持てない | チャット基盤は、1 つのアプリにつき通知の受け口を 1 本しか許しません。常駐しているブリッジがそれを占有しているため、関門が自分で受け口を開こうとしても必ず失敗します。 |
| 署名はブリッジ自身にしか作れない | 署名は、ブリッジが「いま処理中の作業」に対して自ら発行するものです。署名に使う鍵はブリッジの内部にあり、外部のプロセスからは作れません。付け替えの手段も公開されていません。 |
そこでブリッジ自身が残す記録を読む形にしました。 ボタンが押されると、その事実はブリッジに届き、ブリッジは受け取った内容を自分の記録に書きます。 関門はその記録を見て、自分が送ったカードへの応答だけを拾います。 受け口を増やす必要がなく、ブリッジ側に手を入れる必要もありません。
署名による検証を使えない分は、照合を重ねることで補っています。 カードごとに使い捨ての識別子を発行し、そのカード自体の ID とも一致を確認し、 カードを送った時点より後に記録された分だけを見ます。 承認と拒否が両方あれば拒否を採ります。
記録を読む方式である以上、ブリッジ側が記録の書き方を変えると読めなくなるという弱点は残ります。 実行されてしまう方向には倒れないため危険はありませんが、 放置すると「押しても実行されない」状態のまま気づけないおそれがあります。 これに対しては 2 段構えで備えています。
1. 読み方そのものを、書き方の変化に強くしています。 欄の名前や構造がどうなっているかは見ず、 使い捨ての識別子と、送ったカードの ID が同じ行に現れることだけを条件にしています。 欄の名前が変わっても、構造が入れ子になっても、JSON をやめて別の書き方になっても、 この 2 つが同じ行にありさえすれば読み取れます。 承認と拒否の取り違えを防ぐ強さは、これまでどおり保っています。
2. それでも読めなくなった場合に備え、確かめて直す機能を用意しています。 実際にカードを 1 枚送って往復させ、正常に戻るかを確認する仕組みです。 戻らない場合は、押された形跡が無いのか、形跡はあるのに読み取れないのかを切り分けて示します。 ブリッジを更新した後や、様子がおかしいと感じたときに実行する想定です。
なお、読み取り条件を緩めれば復旧できる場面もありますが、 緩めすぎると別のカードへの応答を取り違えるおそれが出てきます。 そのため機能を変える場合は自動では行わず、危険性を示したうえで判断を仰ぐようにしています。
本来あるべき形は、ブリッジ側に応答の受け渡し口を用意してもらうことです。 そうすれば記録を読む必要がなくなり、署名による検証も使えるようになります。 現状はその手前の、実用に耐える備えとして位置づけています。
「気づかないうちに実行されていた」を防ぐために、次の 5 点を守る作りにしています。
運用しながら調整できるよう、よく変える項目は設定ファイルに出してあります。スクリプトを書き換える必要はありません。
| 項目 | 既定 | 説明 |
|---|---|---|
| 高リスク操作の確認方式 | 1 段階 | 赤い警告カード 1 枚で確認します。警告カードで先へ進むかを尋ね、承認後に内容カードで最終確認する 2 段階にも切り替えられます。確実性は上がりますが、承認の回数が倍になります。 |
| カード 1 枚あたりの待ち時間 | 240 秒 | この時間を過ぎると、実行せずに中止します。 |
| テキスト返信の確認間隔 | 60 秒 | ボタンではなく文字で「OK」と返した場合を拾う間隔です。短くすると Lark への問い合わせが増え、混雑時に弾かれやすくなります。ボタンでの承認はこの設定に影響されません。 |
カードを送ったのに応答が反映されない、といった様子が続く場合は、動作確認を実行します。 カードを 1 枚送って実際に往復させ、正常かどうかをその場で判定します。 正常に戻らない場合は、原因の切り分け情報とあわせて示されます。
何を守るためのものか、そして守らないものは何かをはっきりさせておきます。
本人しか使わないチャットと、本人の PC の間で完結する仕組みです。 外部からの攻撃者が確認をすり抜けようと細工してくる状況は想定していません。 守ろうとしているのは、AI が意図しない変更や削除を行おうとしたときに、 本人が実行前に気づいて止められる状態です。
守り方は 2 段構えです。 鍵や認証情報など知識がなければ判断できない領域は、尋ねずに止めます。 それ以外の書き換えは実行前に尋ねます。 後者は承認すれば実行されるので、読まずに押せば確認は形だけになります。 ただし尋ねる内容は「安全かどうか」ではなく 「ご自分が頼んだことか」なので、技術知識がなくても判断できるはずです。
応答しなければ実行されない、という性質もあわせて理解しておく必要があります。 安全側ではありますが、席を外している間は書き換えを伴う作業が進みません。