- 近い将来に起きるのは、人が置き換えられることよりも、1人の社員がシステムに任せた複数の仕事の流れを監督する形です。
- 危ないのは、社員が中身をよく見ないまま、一日中承認ボタンを押すだけの役になってしまうことです。そうならないように仕事を設計する必要があります。
- 対策は、リスクのある案件だけをシステムが人に上げるようにすることです。そうすれば、人がすべての案件に目を通さずに済みます。
1. 「1人で複数のエージェント」という働き方はどう生まれたか
6台の機械を同時に受け持つ班長を思い浮かべてください。班長はすべての機械の前にずっと立っているわけではありません。制御盤を見て、異常の信号が出た機械にだけ足を運びます。複数のAIを監督するときも、考え方は同じです。
開発チーム向け · 技術的な詳細
これまでの知的労働は直列で進んでいました。1人が情報を調べ、書き、分析し、体裁を整えるところまで、1段階ずつこなしていたのです。エージェントなら、その一部を同時に進められます。たとえばResearch Agentが根拠を集め、Analysis Agentがシナリオを比較し、Content Agentが下書きを作ります。利用者の役割は、目標を決め、結果をつなぎ合わせ、最終的な答えに責任を持つことに変わります。
とはいえ、仮想の社員をいくらでも増やせるわけではありません。エージェントは誤ったデータを使ったり、同じ作業を重複してこなしたり、確認が必要な成果物を出したりします。仕組みを整えずに数だけ増やすと、利用者はレビューに追われます。職務記述書のないまま新しい部下を大勢抱えた上司と同じ状態です。
2. 毎回ゼロから作らず、機能ごとにエージェントのポートフォリオを整える
よくある失敗は、1人の社員に、互いに関係のない複数のシステムを受け持たせることです。担当者は一日中頭を切り替え続けることになり、何ひとつきちんと確認できなくなります。1人にまとめて任せる仕事は、同じ系統のものにすべきです。
開発チーム向け · 技術的な詳細
エージェントをPersonal、Team、Enterpriseに分けます。Personal Agentは個人の仕事を手伝うもので、重要な権限は持たせません。Team Agentはチームで共有するワークフローとナレッジを使います。Enterprise Agentは基幹システムにつながるため、本格的なガバナンスが必要です。
開発チーム向け · 技術的な詳細
各エージェントのSponsor、Version、Data、Tools、Cost、SLAを記載したカタログを作ります。各チームは同じものを作り直さず、承認済みのエージェントから選ぶようにします。そうすれば、回答の水準がばらつくリスクも、コストがあちこちに散らばるリスクも減らせます。利用者や責任者がいなくなったエージェントは廃止します。
| エージェント | 役割 | 自律性の範囲 |
|---|---|---|
| Research（調査） | 出典つきで検索し、要約する | 読み取りのみ |
| Drafting（文書作成） | テンプレートから書類を作る | 下書きの作成まで |
| Operations（業務処理） | ルールに沿ってシステムを更新する | 範囲を限った書き込み |
| Customer（顧客対応） | 回答する、または回答を用意する | 低リスクの案件だけ送信 |
3. キューを整理し、人がボトルネックにならないようにする
優先順位は、金額、期限、リスクで決めます。エージェントが何でも人に承認を求めるようでは困ります。定型的なケースは人を介さずに最後まで流し（自動完結）、似た仕事はまとめてレビューし（バッチレビュー）、人の作業に割り込むのは重要な事態のときだけにします。キューの画面には長い出力を全部並べず、判断が必要な点だけを表示します。
開発チーム向け · 技術的な詳細
Objective、Context、Constraints、Deliverable、完了の定義（Definition of Done）を備えたワークパッケージ（Work Package）を使います。長い仕事では、エージェントが予算を使ったりツールを大量に呼び出したりする前にチェックポイントを設けます。「市場全体を分析する」のような広い目標を、どんな判断に使うのかという問いを添えずに任せるのは避けてください。
人のチームと同じように、同時に進める仕事の上限（WIP制限）を決めます。利用者がエージェントに20件の仕事を同時に任せても確認が追いつかなければ、サイクルタイムは延び、状況も混乱します。ダッシュボードでは、レビュー待ちの仕事、キューに入ってからの経過時間、使ったコストが見えるようにします。
4. すべてを同じ熱心さで読まず、リスクに応じてレビューする
開発チーム向け · 技術的な詳細
事実（Fact）、計算（Calculation）、判断（Judgment）、文体（Style）を分けます。事実には出典を示し、数字は計算システムで出し、判断には前提を明記させます。文体は抜き取りで確認すれば十分です。人の手に渡る前に、チェックリストと自動評価で抜け漏れがないかを確かめます。
手本となる回答例（Golden Examples）と、誤りの分類（Failure Taxonomy）を作ります。分類の例は、出典の誤り、古いデータ、計算ミス、ポリシー違反、不適切な言葉づかいなどです。レビューのときは誤りの種類を記録し、その成果物だけを直して終わらせずにシステムの修正につなげます。確信度（Confidence）は、文章がどれだけ自信ありげに見えるかで決めず、根拠があるか、ルールを満たしているかで決めます。
5. エージェントを並行して動かすときに必要な制限
- エージェントごとの専用IDと、人間のスポンサー
- 読み取り、下書き作成、実行を分けた最小権限
- タスク、エージェント、利用者ごとのレート制限とコスト上限
- お金、個人データ、公開、削除に関わる操作の承認
- 同じ送信や作成が二重に起きないようにする冪等性（Idempotency）
- タスク、ツール呼び出し、結果を結びつけたログ
- キルスイッチと、手作業での代替手段
プロンプトだけを統制の手段にしてはいけません。重要なポリシーは、モデルの外側にあるシステムで強制します。エージェント同士が互いを呼び出せるようにすると、問題が連鎖するリスクが高まります。呼び出しの深さ、使えるツール、予算に上限を設け、終わらないループが起きていないかも監視します。
6. 「Manager of Agents」として働く社員の1日
朝、マネージャーは受信トレイの代わりに成果ダッシュボード（Outcome Dashboard）を開きます。エージェントが夜のうちに処理した仕事から上がってきた例外を3件確認し、定型的なレポートをまとめて承認し、特別な事情のある顧客の案件に対応します。そのあと、価格の判断に備えて、3つの調査を同時にエージェントに任せます。
開発チーム向け · 技術的な詳細
エージェントが働いている間、マネージャーは顧客と会い、チームのミーティングに出ます。午後は根拠をまとめた要約（ブリーフ）を確認してシナリオを選び、Drafting Agentに書類の作成を続けさせます。承認が済むと、Operations Agentが業務データを更新します。1日の終わりには、マネージャーが失敗のパターンを確認し、ナレッジを1か所直して翌日の例外を減らします。
人の価値は、すべての工程を自分でこなすことから、方向を決め、根拠を選び、判断し、システムを改善することへ移ります。ですから、仕事の中にシステム改善のための時間を確保しておく必要があります。浮いた時間をすぐに新しい仕事で埋め尽くしてはいけません。
7. エージェントの誤った使い方を助長しないKPI
開発チーム向け · 技術指標
これに品質（Quality）、成果1件あたりのコスト（Cost/Outcome）、サイクルタイム、顧客への影響（Customer Impact）を加えます。エージェントの数、プロンプトの数、エージェントの稼働時間を目標にしてはいけません。チームが価値を増やさないまま、仕事とコストばかり増やすおそれがあるからです。再利用（Reuse）と改善（Improvement）も測り、同じ問題が減っているかを確かめます。
安全に受け持てる量の範囲を決めておきます。1人がいくつのエージェントを監督できるかは、仕事のリスクと種類の多さによって変わるので、1つの比率をすべてに当てはめることはできません。営業と財務でも事情は違います。実際のキューとレビュー時間をもとに試して決めます。
8. 45日でチームの新しい形を試す
- 優秀な社員1人と、繰り返し作業の多い業務の成果を1つ選びます。
- 2〜3種類の役割のエージェントを作り、最初は読み取りと下書き作成の権限だけを与えます。
- アウトプット、作業時間（Touch Time）、品質のベースラインを記録します。
- WIP制限とレビューキューを設けて、並行作業を試します。
- 評価に合格したら、定型的なケースに限って権限を広げます。
- 処理能力を比べ、職務記述書を作り直します。
まとめ：各エージェントの仕事がはっきりしていて、キューが優先順位をつけ、レビューがリスクに応じて行われ、統制の仕組みがシステムに組み込まれていれば、1人の社員が複数のエージェントを指揮できます。これからの役割は成果と品質を管理することで、プロンプトを打ち込む作業はその一部にすぎません。会社は、人員削減の計画に使う前に、1人が受け持つ比率をデータで検証すべきです。
社員1人が、ボタンを押すだけの係にならずに複数の仕事の流れを受け持てるようにする
どの仕事を先に確認すべきで、どの仕事はそのまま通してよいかを知っているのは、社内のチームリーダーやベテラン社員です。私たちは、その知識をシステムが判断に使えるルールに変えるお手伝いをします。仕事の種類ごとのリスクの基準、キューの優先順位、システムが止まって人を待つべき条件、合格とみなせる成果物の形などです。ルールがはっきりすれば、社員の負担は、すべての案件に目を通すことから、システムが上げてきたものだけを判断することに変わります。
複数のエージェントを受け持つ人のための、1画面で完結するシステム
私たちがよく作るのは、複数のエージェントの仕事を1つのキューにまとめ、リスクと期限の順に並べて表示する管理画面です。承認ボタンと差し戻しボタンがあり、その理由は意思決定ログ（Decision Log）に記録されます。1件あたりの金額上限や1時間あたりの最大処理件数といった制限も、あらかじめ設定しておきます。おすすめは、仕事の範囲が最もはっきりしている2〜3のエージェントから始めることです。本番で使う前にシャドーモードで動かして人の結果と比べ、そのあと1つずつ増やしていきます。チームの中に、いくつものツールから同時に仕事を受けている社員がいるなら、その人の机から始めてみてください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、自動化された複数の仕事の流れを、確認できる状態に保ちながら管理するためのものです。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Queue | 処理や人の判断を待っている仕事を、優先順位をつけて並べた待ち行列 | リスクの高い仕事がキューの先頭に回される | キューはどんな基準で並べられていますか？誰がその順番を変えられますか？ |
| Decision Log | 誰が何を、どんな理由で決めたかを、後から振り返れるように残した記録 | 上司がある提案書を却下した理由を残しておく | 判断の理由はどこに保存していますか？それを改善にどう使っていますか？ |
| Rate Limit | 一定時間内の仕事やリクエストの数に上限を設け、システムが動きすぎないようにすること | エージェントが1時間に送れるメールの数に上限を設ける | 上限に達したら、システムは止まりますか？それともキューに入れますか？誰に通知されますか？ |
| Shadow Mode | システムを並行して動かして人の結果と比べるが、まだ実際の操作はさせないこと | エージェントが回答案を横に並べて示し、社員が2週間比べる | どの数字が基準を超えたら、シャドーモードを終えますか？ |
| Kill Switch | 問題が見つかったときに、システムをすぐに止めるボタン | 誤りが見つかったら、顧客にメッセージを送るエージェントをすべて止める | 停止ボタンを押す権限は誰にありますか？押した後、処理途中の仕事はどう扱いますか？ |