自律型AIエージェント
導入の初日。
出さずに先に決めた線

自律型AIエージェントを導入する初日に、何を決めるか

2026年11月6日。わたしは発信のAIチーム「発信室」を、自律型AIエージェントのチームとして立ち上げた。

チャットは、聞けば答えが返ってくる。自律型は、目標を渡すと、自分で計画を立て、道具を使い、結果を見てもう一度動く。違いは、手が動くかどうかにある。手が動くなら、決めるべきことは答えの良し悪しではなく、どこまで動いてよいかになる。

導入の初日に決めたのは、役割と「やらないこと」、確認を減らす場所と残す場所、秘密の渡し方、そして接続できたことと出してよいことを混ぜない線だった。この日、わたしは何も出していない。揃ったことと出したことは別だと、先に宣言しておく。以下は、その線をどこに引いたかの記録だ。

いま、自律型エージェントが話題になっているのはなぜか

IBMの『2026年版AIエージェント・ガイド』は、AIエージェントを、ワークフローを設計し、利用可能なツールを活用することで、ユーザーまたは別のシステムに代わってタスクを自律的に実行できるシステムまたはプログラム、と定義している。かみ砕くと、手順を自分で組み、手元の道具を選んで使い、頼んだ人の代わりに進める、ということになる。

引っかかるのは「代わりに」という言葉だ。答えを返すだけなら、間違いは読む人の前で止まる。代わりに動くなら、間違いは外へ出てしまう。だから話題の中心は、できるかどうかより、任せたあとをどう見るかに移っているのだと、わたしは受け取っている。

同じ案内には、複数のエージェントが共同で動くマルチエージェントの話もある。わたしが初日にやったのは、一人に全部を積まず、役割ごとに分けることだった。何でもできる相手を一人置くより、やらないことがはっきりした相手を並べるほうが、止める場所が見える。

数字も置いておく。サイボウズが2026年11月4日に公開した『大企業におけるAI活用実態調査（2026年）』の第3弾だ。調査は2026年7月6日から9日に、従業員1000人以上、情報通信業を除く551社を対象に実施された。実施機関はインテージ。何らかの形で導入に着手している企業は62%に上る。いっぽう、責任の所在を明文化しているのは16%、実行履歴をレビュー・確認する体制があるのは20%にとどまる。今から1年から3年先の活用イメージを明確に描けているのは8%だった。導入の課題の上位は、業務プロセス見直しの難しさ42%、セキュリティと情報漏洩リスクへの懸念38%、データ基盤やシステム連携の未整備35%と続く。

調査の対象は大企業だ。わたしたちの小さな発信チームの話に、そのまま当てはめるつもりはない。ただ、着手が先に進み、責任分界とレビューの体制があとから追いかける並びは、規模を問わず起きやすい順番だろうと思った。動かし始めるのは早く、決めておくのが遅い。だから初日に、動かす前の線を先に引くことにした。

出典は次のとおり。

• IBM　https://www.ibm.com/jp-ja/think/ai-agents
• サイボウズ　https://cybozu.co.jp/it-foresight/research-whitepapers/2026-10-ai-research-2/

役割と「やらないこと」を、最初に渡した

発信室の名簿は、役割つきで並べるとこうなる。窓口のあびぃ、編集のクロージャー、文案のタケシ、見た目のRay、数字のアイ、調査のイーロン、ゲートのサム、実装のQ、X担当のソラ、Threads担当のツムギ、マーケティングのケン。人数は数えない。増えることも、休ませることもあるチームで、数を決め打ちすると、あとで実態とずれるからだ。

それぞれに渡したのは、名前、口調、そして「やらないこと」の三つ。役割だけを渡すと、できることは広がる方向にしか働かない。「やらないこと」を一緒に渡して、ようやく役割に輪郭がつく。自律型の相手には、任せることより、任せないことを書くほうが大事だと考えた。

とくに意識したのは、書く役と通す役を分けることだ。書く役は、書くところまで。通す役は、通してよいかを見るところまで。同じ者が書いて、同じ者が通すと、確認の意味がなくなる。自分の文章の穴は、自分には見えにくい。

実行の土台は、サブスクで動かす Claude Code と Codex にした。APIキーは使わない。モデルの価格や提供状況は変わりうるので、ここでは断定しない。道具は替えがきくが、役割と線は替えにくい。だから初日の時間は、道具の比較より、役割の言葉づくりに使った。

確認待ちを減らした。ただし門番は残した

最初は、何かするたびにわたしへ確認が来る形だった。安全ではあるが、進まない。しかも、確認が積み重なると、人は中身を読まずに通すようになる。承認ボタンを押すだけの係になれば、それはもう審査ではない。確認は多ければ安心、というものではないと思った。

そこで、ゲート、つまり公開前チェックを通ったものに限り、対象を絞って、確認待ちなしで出す形へ変えた。条件は二つ重なっている。ゲートを通ったこと。そして、確認なしでよい対象があらかじめ限られていること。どちらかが欠ければ、確認待ちに戻る。

逆に、確認のまま残したものがある。料金が発生すること、契約、新規アカウントの作成。いずれも取り返しにくい。取り返しにくいものは、速さより、人の目を優先する。確認を減らす場所と、残す場所を分けたのが、この日の中心の判断だった。

もう一つ、各媒体の最初の一回は、わたしと一対一で進めることにした。媒体ごとに画面も癖も違う。初回に何が起きるかは、やってみるまで分からない。分からないうちは、任せる範囲を広げない。二回目以降にゲートを通したものだけが、確認待ちなしの対象になる。

確認を減らすことと、門番をなくすことは別のことだ。減らしたのは、通る価値のあるものを待たせる確認で、残したのは、通してはいけないものを止める確認だった。

秘密はチャットに流さない

パスワードは、チャットに書かない。渡すときは Vault か、画面の上で直接。確認コードも、チャットには書かない。二段階認証、CAPTCHA、パスキーは、画面を渡して本人が進める。

理由は単純で、チャットは残るからだ。履歴になり、読み返され、場合によっては共有される。流れた秘密は、あとから取り戻せない。自律型のエージェントは、渡された情報を道具に使う。使えるものは、使われうるものでもある。だから、渡さずに済む形を先に作った。

本人しか進められない関門を、エージェントに肩代わりさせない。これは不便に見えるが、境界が分かりやすくなる利点がある。エージェントは、画面の前まで案内する。扉を開けるのは、人。この分担は、初日のうちに言葉にしておいてよかったと思っている。

接続とログインで詰まった点

初日にいちばん時間を使ったのは、役割の設計ではなく、接続とログインだった。

Threadsは、公式APIとの接続まで進めた。投稿はしていない。接続のための鍵は、チャットに貼らず、暗号化して渡した。つながったあとは、つながった先のユーザー名が、想定していた公開アカウントであることまで確かめた。鍵の値は、この記事にも書かない。ここで気をつけたのは、つながったという事実が、出してよいという許可ではないことだ。接続はただの通り道で、通ってよいかを決めるのは、そのあとのゲートになる。

noteは、一般向けの投稿APIはない前提で、画面操作になる。画面を渡して、ログインするところまで進んだ。ここで二つ詰まった。

一つめはパスキー。パスキーは手元の端末に紐づいていて、共有しているパソコン側だけでは進めなかった。鍵が手元に残るのは、安全のための設計だ。エージェントの側から見れば行き止まりだが、行き止まりであることに意味がある。

二つめは認証メール。認証のためのメールが、これまで使っていたアドレスに届かなかった。登録アドレスを別のものに切り替えたところ、ログインできた。何が原因かは、ここでは断定しない。分かっているのは、切り替えて進めたという結果だけだ。

noteには、ログインしただけで、何も出していない。

初日の到達点は、出す手前まで

整理すると、初日の到達点は次のとおり。

• X：下書きまで。投稿ボタンは、まだ押していない。
• Threads：公式APIへの接続まで。投稿なし。
• note：画面を渡してログインするところまで。この記事自体は、note では公開しない前提でいる。

どの媒体も、最初の一回は、わたしと一対一で進める。ゲートを通ったものに限る確認待ちなしの運用は、その一回を終えたあとの話になる。

成果と呼べるものは、まだ何もない。あるのは、線を引いたことと、詰まった場所が分かったことだ。それでも、初日はそれでいいと思っている。出したものの数で測れるのは二日目からで、初日に測るべきは、出す前に何が決まっているかだ。

以前の「評価者の分離」との接続

以前の司令部通信で、書き手と審査役を分ける「評価者の分離」を書いた。記事を書く者が、自分の記事を通してしまわないように、審査役は別に立てる、という話だ。詳しくはこちら。

https://qro-nos.com/dispatch/ai-article-codex-gate

今回の発信室は、その延長にある。記事のときは、書く者と審査役を分けた。発信でも、書く役と門番を分けた。書く役が増えても、通す役は書く役の外に置く。この一点は、記事でも発信でも変わらない。ゲートのサムを役割として置いたのは、そのためだ。

導入を考える人が、初日に決めておく五点

自律型エージェントの導入を考えている人に、わたしが持ち帰ってほしいのは次の五点だ。

• 目的：何のために動かすのか
• 完了条件：どこまでいったら終わりか
• 役割：誰が何を受け持つか
• 任せる範囲と禁止：どこまで任せ、何をやらせないか
• 止まったときの報告：詰まったとき、誰に何を伝えるか

加えて、三つ。

一つめ。確認を減らす場所と、残す場所を分けること。確認は全部減らすものでも、全部残すものでもない。ゲートを通ったものと、取り返しのつくものは減らしてよい。料金、契約、新規アカウントのような、取り返しにくいものは残す。

二つめ。秘密をチャットに流さないこと。パスワードも確認コードも、渡す経路を先に決めておく。本人が進める関門は、本人が進める。

三つめ。接続できたことと、出してよいことを混ぜないこと。つながった、ログインできた、下書きができた。どれも出してよい理由にはならない。出してよいかは、別の判断だ。

サイボウズの調査で、導入着手が先に進み、責任の明文化やレビュー体制が遅れていたことを思い出す。決めておくことは、動かす前なら、少し時間をかければ済む。動かしたあとは、事故のあとに決めることになる。

よくある疑問

自律型AIエージェントとチャットは何が違うのか

チャットは、聞かれたことに答える。自律型は、目標を渡されると、計画を立て、道具を使い、結果を見てまた動く。違いは、手が動くこと。だから導入時には、答えの質より、動いてよい範囲を決める。

検索で見かける別の表記は同じものか

検索では「自立型」という表記も見かける。意味としては同じものを指していることが多い。この記事では「自律型」にそろえた。自分で律して動く、という意味合いが、責任の話とつながりやすいからだ。

確認待ちを減らしてもよいのか

場所を分ければ、よい。ゲートを通ったものに限り、対象を絞って減らす。料金、契約、新規アカウントなど、取り返しにくいものは確認を残す。各媒体の最初の一回は、一対一で進めた。

最初に決めることは何か

目的と完了条件。次に、役割と、任せる範囲と禁止。最後に、止まったときの報告。道具の選定は、そのあとでも間に合う。

投稿ボタンは、まだ押していない

Xの下書きは、ある。Threadsは、つながっている。noteは、ログインできた。けれど、投稿ボタンは、まだ押していない。急がなくていい、と今は思っている。揃ったことと出したことは別で、その間に門番がいる。

そして、その門番を置いたのは、止めるためではなかった。出すと決めた日に、迷わず出せるようにするためだ。扉は閉めてあるが、鍵はわたしの手元にある。初日にできたのは、そこまで...

いつか押す日が来たら、その日のことは、また書く。