AIエージェントで基本設計を討議した記録｜決めるのは、やはり人でした

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

作ったのは、社内の申請業務をワークフロー化する社内システムの基本設計です。動かしたのは当社のPMOコンサルタント1人で、実装と承認は別ラインが担当しました。

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

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

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

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

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

1-2. AI側に作ったもの ── ロール定義のMarkdownと7段階

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

進行役が分科会メンバーを1人ずつ呼び出すようなものです。今回は毎回新規に起動し、必要な前提はそのつど渡しました。

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

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

回し方は7段階です。同じロールを段階ごとに呼び直すので、ロールの種類数より起動の回数は多くなりました。

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

⑦を分担させなかったのは、章ごとに割り当てたら文体と粒度が割れたからです。

制約も見えました。今回は起動を重ねた時点で、一度に扱える分量の上限に触れて処理が止まりました。製品の固定上限ではありません。各段階の結果を保存していたので、段階実行へ切り替えて復旧できました。

1-3. 結果 ── 決定事項・課題・リスクへの構造化と、人に残った判断

討議を統合した結果は、決定事項・課題・リスクに構造化され、人が判断すべき事項が残りました。最終確認は人が行っています。

決定事項の一覧と、人の判断を要する事項の一覧は別々の管理表です。一方から差し引いた残りをAIが決めた、という関係にはありません。

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

人に残った判断の中身は書けませんが、種類なら4つです。本記事では、次の4種類に整理します。

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

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

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

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

それでも、判断すべき事項のほうは残っています。直近の案件で、4種類の判断は結局どなたの手元に残っていたでしょうか。

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

1枚の定義ファイルに書いたのは、役割・保有スキル・必須出力項目の3項目です。ロールを分けただけでは、何も起きません。3つ目の必須出力項目が、いちばん効きました。

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

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

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

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

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

運用担当の定義本文は、1枚こうなります。

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

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

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

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

置いたのは次の3行です。

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

この3行を、定義ファイルすべての冒頭に置きました。本記事の実感では3行目が効きました。正しさが失敗になり得ると先に宣言すると、「堅くすべき」ではなく「この人数で回せる範囲で堅くする」に寄ります。

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

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

サブエージェントは、前提を渡さずに走らせると、各ロールは学習時点の一般論で語り始めることがあります。怖いのは、議論が噛み合って見えることです。前提が違えば、実装で崩れます。

事実カードの中身は次の3点です。

• 事実
• 出典URL
• この設計への含意

3つ目が肝でした。事実だけ配ると、各ロールが自分の都合で解釈します。「設計に何を強制するか」まで書いたところ、解釈のぶれが減りました。

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

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

何をAIに入力してよいかも、討議前に決め切りました。

この表は、当社が考える初期運用の一例です。実際の取扱いは、自社規程、顧客との契約、AIサービスの利用規約とデータ取扱条件、法令に従ってください。

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

合意を疑う役は、討議の後段に独立した工程として埋め込みました。相互レビューの出力には反論が多く並んでいたのに、前提そのものを壊しにいく指摘が1件もなかったからです。

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

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

今回は、品質を上げる力は働いても、合意を疑う力は働きませんでした。専門ロールが議論した結論はそれらしく見えるだけに、危うさが残ります。

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

3-2. 3体に与えた任務と、覆った結論

討議の後段に置いたのが敵対的検証です。敵対的検証とは、合意済みの結論に対し、あえて反証側から前提を突き崩す工程です。

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

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

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

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

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

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

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

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

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

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

統合役のPMOエージェントにさせたのは、全ロールの出力を5つの形に構造化することです。AIを増やしても、PMOの仕事は残りました。討議の量が増えるほど、何を人の判断に上げるかを決める作業が重くなります。

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

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

課したことは次の4つです。

• 重複を排除する
• 対立を裁定する
• 玉虫色で逃げない
• 判断軸の順位に従う

「まとめて」と頼むと要約が返り、論点が絞り込まれません。

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

決定事項・課題・リスク・人が判断すべき事項の4つは、同じ母集団の内訳ではなく、別々の一覧として出力させています。行き先を先に決めると、統合が「分類」になります。

いちばん重いのは、人が判断すべき事項です。ここへ上げるかの判定こそ、この設計の要でした。

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

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

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

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

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

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

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

判断軸は、討議の前に5段階の優先順位として文書で確定させました。軸を並べるだけでは足りません。2案がどちらも軸を満たすと、順位がなければ議論が止まります。

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

AIを人の組織にどう組み込むかの設計論はAIエージェント時代のPMO｜人と自律型AIの分業・ガバナンス設計にまとめました。

• 1

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

• 2

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

• 3

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

• 4

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

• 5

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

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

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

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

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

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

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

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

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

IPA「DX動向2026」によると、AI導入で効果があったと答えた企業のうち、最も多い回答は「業務が効率化・迅速化した」で91.6%、「売上や利益が向上した」は3.9%でした。

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

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

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

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

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

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

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

明日から試すなら、次の7項目の確認から始めてください。

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

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

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

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