AIエージェントを延べ33体、PMO1人で回した｜それでも人に残った11の判断

1. 当社が社内でやったこと ── 何を作り、AIに何を作らせ、どうなったか

先に全体を出します。作ろうとしたのは、社内の申請業務をワークフロー化する社内システムの基本設計です。

動かしたのは当社のPMOコンサルタント1人。ただし賄ったのは基本設計の検討で、実装も承認も別ラインです。

1-1. 作ろうとしたもの、動かした人

基本設計は、要件定義で決まった「何を実現するか」を「どういう構造で実現するか」へ落とす工程です。コードを書く詳細設計と実装は、この後に続きます。

実際に扱ったのは、社員が申請し、上長が承認し、管理部門が確認し、完了履歴を残す流れです（具体は伏せます）。通常なら各担当が観点を持ち寄り、分科会を何度も回す規模になります。

その検討役を分けたのが、AIエージェントです。AIエージェントとは、目的を与えると自分で手順を分解し、道具を使って作業を進めるAI。1往復で答えを返すチャットとは違います。

賄ったのはシステムそのものではなく、設計を決めるための検討リソースです。

PMOという言葉も、決定ではなく決定を支える枠組みを整える役の意味で使います（混同されがちなPMOとPMの違いと連携）。

1-2. AI側に作ったもの ── 13枚のMarkdownと7段階

使ったのはClaude Code のサブエージェント機能。親の進行役から個別タスクを与えられて起動する子エージェントです。

進行役が分科会メンバーを1人ずつ呼び出すようなもの。ただし呼ぶたびに新しく席に着くので、前の会議の話は持っていません。

作り方は拍子抜けするほど単純です。Markdownファイル1枚が、1ロール。13の役割を13枚のテキストに書き分け、.claude/agents/ に置くだけで呼び出せます。

正確には、冒頭に YAML frontmatter（名前や説明を書くメタ情報）を置き、その下の本文に中身を書きます。今回はその定義本文を、役割・保有スキル・必須出力項目の3つに絞りました。

回し方は7段階。同じロールを段階ごとに呼び直すので、13ロールでも起動は延べ33回です。

①から③は1体ずつ順番にではなく、並列で同時に走らせています。8つの観点が一度に出そろうため、往復待ちがありません。PMO1人で分科会相当を賄えたのは、ここが大きい。④の調停役も14番目のロールではなく、統合ロールの先行登板です。

⑦が0体なのは、章ごとに割り当てたら文体と粒度が割れたからです。材料出しまでを任せ、まとめは分けない。

制約も見えました。起動が延べ33回に達した時点でセッションの上限（一度に扱える分量）に触れ、処理が止まったのです。各段階の結果を保存していたので、段階実行へ切り替えて復旧できました。

1-3. 結果 ── 決定140件・課題75件・リスク30件、人の判断11件

数字の範囲を先に閉じます。以下は基本設計工程における当社内の実測カウントで、第三者の検証を経た値ではありません。件数は対象業務の複雑さで変わります。

単位も分けておきます。ロールは役割定義の種類数、体は1回ぶんの起動。33体が同時に走ったわけではありません。

討議を統合した結果は、決定事項140件・課題75件・リスク30件に構造化されました。最終確認は人が行っています。そして「人が決めるしかない」と判定された事項が、11件です。

11件の中身は書けませんが、種類なら4つ。本記事ではまとめて「11の判断」と呼びます。

誰を巻き込むか。情報システム部門だけで決めるか、業務部門の課長まで通すか。AIは巻き込むべき部署を列挙できます。ただし誰の顔を立てるか、どこで揉めるかは組織の事情。列挙と選択のあいだに、越えられない線があります。

いつから動かすか。期初に合わせるか、繁忙期を外して半年遅らせるか。技術的にはどちらも可能で、長短の整理までは返ってきます。決め手は他施策との重なりと、現場が変更を受け止められる時期。どちらも設計書の外にあります。

どれだけ工数を割けるか。運用に1日30分を充てられるのか、週1回が限界なのか。ここが決まらないと、点検や監視をどこまで載せるかが決まりません。人の空き具合は他業務との綱引きで、設計の中からは導けません。

どこまで許容するか。手作業の残る運用を受け入れるか、作り込んで自動化するか。AIは選択肢と代償を並べます。どこまでの不便を引き受けるかは、引き受ける人が決めること。他人が決めた設計は、運用開始後に覆ります。

日程調整も読み合わせも議事起こしも宿題待ちも、この進め方では発生しませんでした。それでも、判断すべき事項のほうは残っています。

直近の案件で、この4種類は結局どなたの手元に残っていたでしょうか。

2. 定義ファイルに何を書いて渡したか

ロールを13に分けただけでは、何も起きません。分けた先の1枚に何を書くか。書いたのは3つで、3つ目の必須出力項目がいちばん効きました。

2-1. 1ロールの中身は3項目 ── 役割・保有スキル・必須出力項目

役割は1〜2行。「何を見る人か」だけを書きます。長いほど焦点がぼやけ、どの観点にも薄く触れる出力になります。

保有スキルは箇条書きで4〜5点。「何を知っている前提の人か」を並べます。書かないと発言が一般論に下がり、書きすぎると範囲の外を見なくなる。

必須出力項目は、何を必ず返させるかの指定。全ロール共通で1項目を足しました。「過剰設計の指摘」です。自分の提案だけでなく、他ロールの案が重すぎないかを毎回指摘させます。

これがないと、8つの「最善」が足し算になります。セキュリティ役は最も堅い構成、運用役は最も手厚い監視、データ設計役は最も汎用的なモデル。合計すると回りません。

書き下ろすと、1枚はこうなります。運用担当の定義本文です。

共通の必須出力を1つ足すだけで、互いに重さを指摘し合う関係ができました。削るべきもの15項目が挙がっています。指摘を3つ。

3つに共通するのは、正しさの指摘ではないこと。どれも「正しいが、この現場では回らない」形です。1体に全部聞けば答えは返りますが、立場が1つなので衝突しません。皆さまの現場では、誰がこの観点を持っていますか。

2-2. 全ロールに同じ3行を課す ── 最上位制約

今回は、放っておくと必ず重い側へ振れました。もう1つ打った手が最上位制約。全ロール共通で課す、破ってはならない前提条件です。

趣旨はこうです。少人数で運用する仕組みである。大規模組織向けの設計を持ち込まない。運用できない設計は、正しくても失敗である。

この3行を、13枚すべての冒頭に置きました。効いたのは3行目です。正しさが失敗になり得ると先に宣言すると、「堅くすべき」ではなく「この人数で回せる範囲で堅くする」に寄ります。

なお、運用に割ける人手はプロジェクトの前提であり、PMOが決めた制約ではありません。

2-3. 討議の前に配る「事実カード」

呼ぶたびに新しく席に着く相手です。前提を渡さずに走らせると、各ロールは学習時点の一般論で語り始めます。怖いのは議論が噛み合って見えること。前提が違えば、実装で崩れます。

これを防ぐため、討議前に全ロールへ短い資料を配りました。事実カードと呼びます。一般的な手法名ではなく、この案件でそう呼んだ社内用語です。

中身は3点セット。事実、出典URL、この設計への含意です。3つ目が肝でした。事実だけ配ると各ロールが自分の都合で解釈します。「設計に何を強制するか」まで書けば、ぶれが消えます。

確認できなかったものは「未確認」と書き、確認方法をセットで残します。土台が未確認だと見えていれば、そこから結論は出ません。

相互レビューの指示文にも禁止事項を入れました。「すでに出ている指摘の焼き直しは書くな」「反論には必ず対案を」の2つ。これがないと、言い換えだけの出力で議論が水増しされます。

何をAIに入力してよいかも、討議前に決め切りました。走りながらだと境界が緩みます。

実際の線引きは、自社の情報セキュリティ方針を優先してください。

3. 合意を疑う役を、工程として埋め込む

相互レビューの出力を読んで、気づいたことがあります。反論はたくさん出ているのに、前提そのものを壊しにいく指摘が1件もなかったのです。

3-1. 専門ロールの討議は「良い設計を作る」方向にしか働かない

反論はすべて「こう直せばもっと良くなる」形でした。当然です。各ロールには「良い設計を作れ」という目的があり、前提を壊せば自分の提案も崩れます。

品質を上げる力は働いても、合意を疑う力は働きませんでした。起動を重ねても出てこない。8体が議論した結論は、それらしく見えます。見えるからこそ危ない。

予防的に品質を作り込む発想は、プロジェクト管理で確立されています（PMOが実践する品質管理・品質保証の体系的アプローチ）。同じ発想を討議へ持ち込みました。

3-2. 3体に与えた任務と、覆った4件

そこで、討議の後段に検証専用の工程を置きました。敵対的検証です。合意済みの結論に対し、あえて反証側から前提を突き崩す工程を指します。

置いたのは3ロール。まず1枚目の定義本文です。形は運用担当と同じ3項目、必須出力だけが違います。

直し方まで書かせると、破り方の説明が甘くなります。攻める側と直す側を、同じ1体に兼ねさせない。

残る2ロールの任務です。

結果、合意済みだった結論のうち4件が覆りました。うち1件は設計の骨格を変えるもの。討議では、8ロールの誰も引っかからなかった箇所です。

4件の中身は書けませんが、共通する性質なら書けます。どれも「設計が間違っている」のではなく、「設計が想定していない状況」を突かれたものです。

型はこうです。正常に使う人だけを前に置いた設計に、わざと外れた使い方をする人を立たせる。1度で終わる前提の手続きに、途中で人が入れ替わる状況を置く。3か月後に振り返る想定の記録に、その場で説明を求める相手を置く。

いずれも設計の中身は否定していません。「そんなことは起きない」と黙って置かれていた前提のほうを、外側から崩しています。改善を競い合う限り、想定は誰の攻撃対象にもなりません。

この4件は「4件も間違えていた」ではなく、実装に入る前に4件を拾えた、という事実です。実装後なら、手戻りの規模はまったく違いました。

3-3. 1人で回すからこそ、レビュアーを「構造」で用意する

設計レビュー会があれば、他部署の誰かが「その前提おかしくないですか」と言ってくれます。人数の価値は、視点の数より疑う人がいること。1人で回すとこの目が消えます。

だから、意志ではなく工程で解決しました。討議の後に必ず通す順序として固定する。埋め込めば、疲れていても飛ばせません。ご自身の結論を、自分で壊しにいったことはあるでしょうか。

4. PMOエージェントに何をさせたか

AIを増やしても、PMOの仕事は残りました。討議の量が増えるほど、何を人の判断に上げるかを決める作業が重くなる。それをさせたのが13枚目、統合役のPMOエージェントです。

4-1. 何を渡し、何を禁じ、何の形で返させたか

入力は全ロールの出力すべて。初回分析から敵対的検証まで、段階ごとにファイルへ落としたものをまとめて読ませました。

課したことは4つ。重複を排除する、対立を裁定する、玉虫色で逃げない、判断軸の順位に従う。「まとめて」と頼むと要約が返り、論点が絞り込まれません。

いちばん効いたのは出力の形の指定。返してよい形を5つに固定しました。

この4つは同じ母集団の内訳ではなく、別々の一覧として出力させています。行き先を先に決めると、統合が「分類」になります。決めずに頼むと、決着した話と未決の話が混ざります。

いちばん重いのは4つ目。ここへ上げるかの判定こそ、この設計の要でした。

境目は、追加で調べれば答えが出るかどうかに置きました。調べれば出るものは課題へ回し、担当と期限をつける。調べても出ないもの、誰かが責任を引き受けないと動かないものだけを4つ目へ上げます。

「判断が難しいから」ではなく「情報を足しても解けないから」で分ける。難易度で分けると、調べれば済む話まで人の手元に積み上がるからです。

4-2. 課した2つの縛り

1つ目は玉虫色の決定の禁止。どちらとも読める曖昧な決着です。2案の良いところを並べ、どちらも尊重する。読むと納得しますが、何も決まっていません。

2つ目は、受け入れるデメリットの明記。「書け」だけでは足りず、書式まで指定しました。決定の中身、デメリットの中身、想定頻度、起きたときの対処。この4つで1件とします。

頻度と対処まで書かせるのは、省くと記載が免罪符になるからです。「承知のうえです」の一行では、何をどこまで承知したか分かりません。

4-3. 判断軸に順位をつける

AIを人の組織にどう組み込むか。その設計論はAIエージェント時代のPMO｜人と自律型AIの分業・ガバナンス設計にまとめました。本記事はそれを社内案件で走らせた記録です。

走らせて分かったのは、軸を並べるだけでは足りないこと。2案がどちらも軸を満たすと、順位がなければ議論が止まります。

そこで、討議前に5段階の優先順位を文書で確定させました。中身を発明したわけではありません。運用に割ける人手も追加費用の許容範囲もプロジェクトの前提で、裁定に使える形へ書き起こしただけです。

• 1

  必須要件を満たすか。満たさない案は、他がどれだけ優れていても採らない

• 2

  少人数で運用できるか。重い設計を自動的に不利にするため、あえて2番目に置いた

• 3

  追加コストが不要か。費用が発生する案は、しない案に劣後する

• 4

  内製で実装可能か。外部に依存すると、変更のたびに時間と費用がかかる

• 5

  将来の拡張性。4つで並んだときの、最後の判定材料に置いた

順位を先に決めると、裁定が速くなります。「どちらが良いか」ではなく「どちらが上位の軸を満たすか」を見るだけで済みます。

順位そのものも、PMOが独自に決めたわけではありません。

4-4. PMOの仕事は「決めること」ではなく「決める対象を絞ること」

統合ロールにさせたのは、決めることではありません。140件の決定にも11件の判断にも、最終確認は人が入っています。基本設計を確定させる権限は、業務オーナーと所管部門にあります。

PMOが提供したのは、論点と判断軸と決定記録の枠組みです。統合ロールは、それを機械的に当てはめる役でした。

絞り込みの本質は、判断を減らすことではなく判断に上げるものを選ぶことです。11件が並んだから楽になったのではなく、11件に向き合う準備が整った。いまのプロジェクトで、決める順序は文書になっていますか。

5. 結論：AIが増やせるのは検討の量であって、決める人ではない

先に、この記録で言えないことを書きます。AIを使わなかった場合に人の判断が何件だったかは、測っていません。比較する相手がない以上、「人の判断は減らない」とまでは言えない。言えるのは、延べ33回動かしても11件が残った、というところまでです。

そのうえで、見立ては書けます。残った4種類は、どれも調べれば答えが出る類ではなく、責任の引き受け方に紐づいています。だから起動回数を増やしても消えないだろう、と見ています。実証ではなく、見立てです。

公的な調査も見ておきます。IPAの「DX動向2026」は、AI導入で効果があったと答えた企業に内容を尋ねています。最も多いのは「業務が効率化・迅速化した」で91.6%、「売上や利益が向上した」は3.9%でした。

IPAはこの結果を、AI導入の効果が業務の効率化・迅速化に集中し、外向きの成果創出は限定的だと整理しています。今回も、AIが増やしたのは検討の量でした。

両者は同じものを測ったデータではありません。片方は企業への調査、片方は当社1件の内部カウント。重なるのは、AIを入れただけでは最終成果まで自動的に生まれない一点です。

5-1. 1人で回ったのは才能ではない

設計検討を賄えたのは、個人の処理能力が高かったからではありません。ロール構成、実行順序、裁定の判断軸。この3つを走らせる前に組んだからです。

ロール設計ができた理由も、AIの知識ではありません。どの観点が抜けると設計が破綻し、どの対立が後で火を噴くか。案件を回してきた経験が、13という顔ぶれを決めています。

ただ、経験がなければ組めない話でもありません。顔ぶれは手元の資料から引けます。設計レビュー会の出席者名簿、過去案件の課題管理表、リスク登録簿の分類項目。外せないのは13という数字ではなく、事実収集 → 専門 → 検証 → 統合の順序のほうだと考えています。

5-2. 明日から試すなら、この7つから

まず確認していただきたい項目です。

• ☐ 破ってはならない前提条件を、全ロールに同じ文言で置いたか
• ☐ 「過剰設計の指摘」のような共通の必須出力項目を課したか
• ☐ 一次情報から確定事実を集める工程を、討議の前に置いたか
• ☐ 合意された結論を壊す役を、後段の工程として置いたか
• ☐ 判断軸に順位をつけ、討議前に文書化したか
• ☐ その順位を、業務オーナーと合意しておいたか
• ☐ 各段階の結果を保存し、再開できる形にしたか

厚みの置き方は案件次第です。規制の厳しい領域なら検証側を、利用者が多い業務ならUI側を厚くする。ロール構成の調整もご相談ください。どの1つから試されますか。

最後にもう一度。AIを延べ33回動かしても、人が判断しなければ前に進まない事項は11件残りました。発生しなかったのは、そこへたどり着くまでの日程調整と読み合わせのほうです。AIが増やせるのは検討の量であって、決める人ではありません。

まずは1件、小さな検討から順序を組んでみてください。