AIエージェント業務自動化の仕組み、5つの要素で先に予算を付けるのは1つ

「AIエージェント 業務自動化 仕組み」で検索して返ってくるのは、動作原理の図解と「パターン6選」「活用事例13選」である。エージェントが計画を立て、ツールを呼び、実行するという流れの説明としては正しい。だが全社導入を終えた組織の経営層・マネージャーにとって、この説明は投資の意思決定に何も与えない。知りたいのは動作原理ではなく、「うちで動かすには何を先に整えるのか、その費用は誰の予算から出るのか」だからだ。

結論を先に置く。本番で動いているエージェントの仕組みは、5つの要素に分解できる。5つとも経営の関心事だが、エージェント開発より先に予算を付けなければならないのは1つだけである。本稿は海外の本番運用の元記事を起点に、その1つを特定する。

なぜAIエージェントの業務自動化はPoCで止まるのか

止まる理由をモデルの性能に求める議論は、事実と合わない。

Everyのメールアシスタント Cora を開発する Kieran Klaassen は、複数エージェントが自律的に協調する「スワーム」を3か月かけて試し、失敗している。エージェントを増やしても速くならず、10体が同時に仕上げてきた時点で、どれを信用できるか判断する文脈が人間の側に足りなくなった。転機は、より賢い統制層を探すのをやめ、実際に仕事をしているものに目を向けたことだった。それは彼がすでに持っていた、CLAUDE.md・スキル定義・数か月分の蓄積を収めたプロジェクトフォルダであり、Klaassen はこれ自体がエージェントだと述べる。同じモデルでも ~/cora/ に向ければ Rails の規約を守るエンジニアになり、~/cora-agent/ に向ければインシデント履歴とサービス構成を把握した運用担当になる。フォルダ間の振り分けは、Ruby の常駐プロセスとファイルベースのメッセージングによるディスパッチレイヤーに任せ、現在は複数のプロジェクトで44個のフォルダエージェントを運用している（複数 AIエージェント運用が挫折する理由と、フォルダベースコンテキスト戦略で詳述）。専門性を作っていたのはモデルではなく、フォルダに積まれた記録だった。

もう一方の失敗の型は「作りすぎ」である。Devin を開発する Cognition の Builder in Residence である Jared Zoneraich は、チームが最初のエージェントに細かいルールと決定論的な指示を詰め込みすぎると指摘する。同氏によれば重要なのはプロンプトエンジニアリングではなくツールエンジニアリング、つまりコードを検索し、ログを読み、テストを実行する手段をモデルに与えることだ（AIエージェントはどう作り、どう管理するのが正しいのか ― 「作りすぎない」設計とツールエンジニアリングの原則で取り上げた原則）。

対照的なのが、元記事が $1.25B 規模の企業と紹介するLinearである。ただしこの元記事は告知文で、中身の情報はPeter Yangがまとめた要点の冒頭にとどまる。本番で動く AIエージェントはどう作るのか — Linear が「Slack の依頼からコード提出まで6分」を実現した5つのルールで扱ったとおり、Linear Agent はSlackで受けた依頼をコードの提出まで持っていく工程を、デモでは6分で進めている。そしてこの回を紹介するPeter Yangの要点の1つは、モデル選定にもエージェント構成にも触れず、次の一文だけを言う。

“Give agents tools to find context instead of stuffing context into the prompt.”

訳: コンテキストをプロンプトに詰め込むのではなく、コンテキストを見つけるためのツールをエージェントに与えよ。

出典: Behind the Craft by Nan Yu & Jacob Shumway, 2026-08-09

3つの事例が同じ方向を指している。PoC と本番を分けているのは、エージェントが自分でコンテキストを取りに行けるかどうかである。

動くエージェントを支える5つの要素とは何か

海外の本番運用事例を突き合わせると、仕組みは次の5つの要素に整理できる。

第一に入口。 エージェントを別のチャットボットとして立てるのではなく、仕事が実際に始まる場所に置く。元記事の要点にも「仕事がSlackで始まるなら、別のチャットボットを使わせずSlackを入口にせよ」とある。Linearのデモも Slack を起点にしている。Slack にClaude Codeを接続した運用例では、チャンネル＝プロジェクト、スレッド＝タスクという構造で複数のエージェント作業を一元管理している（AIエージェントをSlackに常駐させる前に何を決めるべきか——実行権限とガードレールの設計で扱った設計）。入口の選定は利便性の話ではなく、依頼と結果が同じ場所に記録されるかという設計判断である。

第二にコンテキスト置き場。 エージェントが判断に必要な情報を自分で取得できる状態にしておく要素で、Linear の設計ルールと Cora のフォルダが指しているのはここだ。具体的な成果物は2つある。業務ごとに「この情報についてはこのシステムが正である」と指定した一覧と、エージェントがそこを読みに行ける経路（API・検索ツール・参照用のドキュメント置き場）である。プロンプトに詰め込む方式は業務が少し複雑になると破綻し、この2つを用意する方式だけが残る。

第三に権限境界。 OpenAIのCodexチームのDevExエンジニアJason Liuは、1つのスレッドを参謀役に見立て、9時・13時・17時に Slack・メール・Twitter DM・Linear を横断レビューさせ、優先事項と返信の下書きを返させている。なお記事が読者向けに示す設定用プロンプト例には「私の承認なしには何も送信しないこと」という一線が入っている（AIエージェントに秘書業務をどこまで任せるか——OpenAI社員の「Chief of Staffスレッド」と承認境界の引き方で取り上げた運用）。閲覧のみ・下書きまで・実行まで、をツール単位で切り分けるのが権限境界の実装形である。

第四に評価。 エージェントの出力が使えるかを判定する基準である。元記事の目次には「評価はリリース後に作るべき理由」という項目が挙がっている（理由の中身は未取得）。本稿はこれを、評価基準は運用が始まってから作る前提の要素と読む。

第五に配置。 Brex CEO の Pedro Franceschi は、エージェントを「AI従業員」として、良い従業員に与えるのと同じ4つの制約——Job（1つの明確な成果）、Skills（具体的な指示と制約）、Manager（不明ならエスカレーション先の人間）、Budget（成果の価値に見合ったトークン予算）——で設計せよと主張する。同社のAI採用担当 Jim は、候補者のソーシング、応募の絞り込み、分析を担当しつつ、判断に迷えば人間に上げる（AIを「万能エージェント」ではなく「配置人事」として設計するにはで詳述）。万能アシスタントを1体作るのではなく、職務を切って配置する発想だ。

5つの要素のうち経営が先に予算を付けるのはどれか

先に予算を付けるべきは第二の要素、コンテキスト置き場である。

ここで問うているのは「経営が関与するか」ではない。5つの要素はいずれも経営の関心事だ。権限境界がスピードと統制のトレードオフを取る経営判断であることはAIエージェントに社員と同じ権限を渡せるか ― 権限境界設計を経営の意思決定に引き上げるで扱い、Budget はトークン原価の管理と、Manager はエスカレーション先の組織設計と直結する。つまり権限境界は「ルールとして制度化する対象」であり、こちらの結論はAIエージェント導入、成功事例だけでは決められない ― 失敗パターンと組織実装のリアルで既に出している。本稿が問うのは別の軸、すなわち予算を付ける順番である。

順番を決める軸は1つに絞れる。後から入れ替えたとき、既に動いている案件をやり直す必要があるか。 この軸で5つの要素を見ると、非対称がはっきりする。承認境界を「下書きまで」から「送信まで」に緩めても、直すのはその業務の権限設定であり、エージェント本体は作り直さない。ただし逆方向には例外がある。インシデント後に全社で「外部送信は一律禁止」と締めれば、送信を前提に組んだエージェントはやり直しになる。交換できる要素と言えるのは、当該業務の範囲で戻せる変更に限られる。入口を Slack から別のツールに移すのも接続先の差し替えで済む。入口に溜まるのは依頼と結果のログであって、判断に使う正のデータではないからだ（両者が同じシステムなら、それは入口ではなくコンテキスト置き場として扱うべきものになる）。評価基準は先の章題のとおり運用後に作る前提なので、そもそも後から足す要素である。配置は職務定義なので、書き換えれば反映される。いずれも交換できる要素だ。

コンテキスト置き場だけが違う。「この情報についてはこのシステムが正である」という指定を後から変えると、そのシステムを読みに行っていたエージェントは全部、取得経路から作り直しになる。ここが交換できる要素でないのは、それが1つの業務のための設定ではなく、複数のエージェントが同じ経路を共有する土台だからだ。元記事の要点は、エージェントを作る最初の一歩として、どこで仕事が始まり、どのシステムがコンテキストを保有し、どの操作で仕事が完結し、何をもって完了とし、どこに人間のレビューが要るかという5項目を地図にすることだと述べる。このうち「どのシステムがコンテキストを保有するか」だけが、業務をまたいで効いてくる。

ここで Cora の事例を正しく位置づけておく必要がある。Cora のフォルダ資産は、経営の先行投資ではなく開発者本人がプロジェクト単位に積み上げたものだ。つまり単一プロダクト・少人数の範囲では、ボトムアップの積み上げで足りる——というより、それが最短である。ただし Cora の成立条件を取り違えないほうがいい。Cora も多数の外部システムに依存している。効いているのは参照先の数が少ないことではなく、.claude/skills/ を操縦席（cockpit）として、依存する外部システムごとに「どう話すか」を書いた参照ファイルを1か所に集めた構造である。つまり集約されているのは情報そのものではなく、取得経路だ。これは本稿が第2節で挙げたコンテキスト置き場の成果物そのものであり、規模が大きい組織で難しくなるのはこの集約の一元管理である。顧客情報が CRM と担当者の受信トレイに分かれ、設計仕様が複数世代のドキュメントツールに散り、進捗が2つのタスク管理ツールで二重管理されている組織では、取得経路の一覧を誰が保守するのかが決まっていない。各案件が同じ配線を独自に組むことになり、その費用は案件ごとの予算に紛れるので、合計額が誰の目にも見えない。これは本稿の推論であり、だからこそ次節の1本目で実測すべき数字になる。

決めるべきことは1文で書ける。どの社内システムを「エージェントが参照する正のデータソース」として位置づけ直し、その整備を個別のエージェント開発より先に予算化するか。そして誰（CIO・データ責任者）がその指定の所有者になるか。この順序を逆にすると、案件が増えるほど立ち上げ期間が伸び、現場は「エージェントは筋が悪い」と結論する。

最初の1業務をどう選ぶか

削減工数が最大の業務から選ぶのをやめる。選ぶべきは、仕事の起点と記録が既に同じシステムに一致している業務である。

Linear のデモは、仕事が実際に Slack で始まる場面を扱っている。Codex の参謀役スレッドの対象は、個人の受信トレイ・Slack・タスク管理という、既に集約された領域だった。Cora のフォルダも、1か所に文脈が積まれている前提で動く。どの事例も、コンテキストが散っていない領域を選んでいる、と本稿は読む。

判定は3問で足りる。第一に、その業務はどこで始まるか。口頭や会議での依頼が起点なら、エージェントには渡せない。第二に、判断に必要な情報は何系統のシステムに散っているか。2系統までなら配線できるが、3系統以上あるなら記録の集約が先行タスクになる。第三に、完了したかどうかを人に聞かずに機械が判定できるか。できないなら、評価基準を作る手がかりが運用後も得られない。

この3問を通る業務は、多くの組織で「経営が期待している業務」とは一致しない。稟議・与信審査・調達のように金額インパクトが大きい業務は、たいてい起点が口頭で記録が複数系統に散っている。逆に3問を通るのは、開発チームの課題対応、問い合わせの一次切り分け、定例レポートの作成といった、記録が最初から1か所に溜まっている業務だ。ここから始めるのは規模を諦めることではない。1本目で得たいのは削減工数ではなく、5つの要素を通しで動かした経験と、コンテキスト置き場の整備に実際いくらかかったかという実測値である。その数字がなければ、2本目以降の予算をどこに付けるべきかを議論できない。

まとめ: 仕組みの理解は投資順序の決定に使う

AIエージェントによる業務自動化の仕組みを5つの要素に分解する意味は、動作原理を理解することではない。入口・権限境界・評価・配置は後から入れ替えても既存案件をやり直さずに済むが、コンテキスト置き場だけは複数エージェントが共有する土台であり、指定を後から変えると走った案件すべてに作り直しが発生する。Linear のデモの6分と Cora の3か月の失敗が示しているのはこの非対称性である。次の稟議で問うべきは「どの業務にエージェントを入れるか」ではなく、「エージェントが参照する正のデータソースをどのシステムに定め、その整備をエージェント開発より先に予算化するか、そして誰がその指定を所有するか」だ。