AIエージェントを増やす前に、役割と「止める人」を決める

月曜の朝、AIが作成した三つの成果物が届いたとします。競合調査の要約、週次レポートの草稿、顧客向けメールの文案です。文章は整っています。しかし、競合価格の取得日はなく、数値の出典も見つかりません。誰が確認し、誰が送信を許可するのかも書かれていません。

この状態でAIエージェントを増やすと、処理は速くなっても、確認すべき場所が増えていきます。先に必要なのは、各エージェントの役割分担を決めることです。

読み終えた時点で手元に残るテンプレートは、次の三つです。

• B2Bコンテンツ制作を例にした四つの役割の記入例
• 自社の業務にコピーできる「AI役割設計シート」
• 継続・設計変更・中止・判断保留を分ける2週間の試行方法

「何をするか」だけでは、役割を定義したことにならない

2026年8月、GitHubで職能別のAIエージェント定義を集めたmsitarzewski/agency-agentsが注目を集めました。リポジトリ内の定義は、役割、作業手順、成果物、評価の観点などを組み合わせています。2026年8月11日時点で14万件を超えるスターが付いていますが、これは開発者コミュニティの関心を示す数字です。企業での採用実績、セキュリティ、本番運用への適合性を示すものではありません。

このリポジトリから企業が参考にできるのは、定義ファイルを一括導入することではなく、役割を構造として書き出す考え方です。ただし、役割、作業手順、成果物だけでは足りません。企業の業務では、少なくとも次の六項目が必要です。

1. 受け取ってよい入力
2. 返すべき成果物
3. やってはいけないこと
4. 人間側の責任者
5. 次の工程へ渡す前の承認
6. 処理を止め、差し戻す条件

特に、禁止事項と停止条件が重要です。「競合情報を調べる」という役割だけでは、出典のない数字を作らないことや、取得日を確認できない情報を草稿へ渡さないことまでは伝わりません。

四つの役割に分けると、どこで人が判断するかが見える

B2Bコンテンツ制作を例に、四つの役割を記入すると次のようになります。最初の三つはAIが支援できますが、最後の公開判断は人が担います。

役割を分ける目的は、AIを増やすことではありません。出力に問題があったとき、「どこで止めるか」「誰が判断するか」「どの工程へ戻すか」を追えるようにすることです。

コピーして使える「AI役割設計シート」

次の項目をコピーし、自社で繰り返している一つの業務に当てはめてください。最初から多くの業務を対象にせず、週次報告、社内FAQの更新、公開前の情報整理など、結果を人が確認できる業務から始めます。

記入するときは、次の順番にすると議論が進みやすくなります。

1. 「やってはいけないこと」と「停止条件」を先に書く
2. 停止した出力を確認する人を一人決める
3. 承認済みの入力と、返すべき成果物を具体的に書く
4. 最後に、AIが支援できる範囲を決める

人間側の責任者を書けない工程は、まだAIへ任せる準備ができていない可能性があります。「担当部署」ではなく、少なくとも役職または判断を引き受ける一人を定めます。

2週間の試行では、速さより「戻せるか」を測る

役割設計が機能するかは、短い試行で確かめられます。以下は測定を始めるための設計例であり、AMELAの実績値や一律の合格基準ではありません。業務量に合わせて件数を調整してください。

開始前

• リスクが低く、成果物を目視確認できる業務を一つ選ぶ
• 直近の成果物から、確認時間、主な差し戻し理由、出典不明の件数を記録する
• AIが支援する役割は二つまでにする
• 公開・送信・承認の権限は人に残す

1週目

すべての出力を人が確認し、停止条件が何回発動したか、どの役割へ差し戻したかを記録します。処理時間だけでなく、確認にかかった時間も測ります。

2週目

1週目で最も多かった差し戻し理由に対し、役割定義または停止条件を一つだけ変更します。複数の条件を同時に変えると、何が効いたのか判断しにくくなります。

終了時の判断例

どの業務から試すかは、事故時の影響で決める

この役割設計は、さまざまな業務に応用できます。ただし、以下は導入実績ではなく、構造を当てはめた例です。

• マーケティング・広報： 情報収集、草稿、根拠確認を分け、公開は人が判断する。価格や数値の取得日を停止条件にする
• 調達・購買： 候補収集、条件比較、社内規定との照合を分け、最終承認は購買責任者が担う。判断基準が未定なら開始しない
• カスタマーサポート： 問い合わせ分類と回答案の作成までをAIが支援し、契約・返金・個人情報を含む回答は人へ引き継ぐ
• ソフトウェア開発： タスク整理、実装支援、テストを分け、受入・リリースは人が判断する。テスト基準と復旧手順がなければ自動実行しない

最初の対象には、誤りが顧客、契約、決済、法令、機密情報へ直結しない業務を選びます。影響が大きい業務では、役割表だけでなく、権限、監査ログ、フォールバック、法務・セキュリティ確認が必要です。

GitHubの定義を企業へ持ち込む前に確認すること

agency-agentsは、役割を考えるための参考になります。一方で、READMEの「本番対応」「実戦検証済み」といった表現は開発者の説明であり、第三者検証ではありません。また、リポジトリにはMarkdown形式の定義だけでなく、インストールや変換に使うシェルスクリプトも含まれます。

企業で利用を検討する場合は、少なくとも次を確認してください。

• MITライセンスの表示条件を満たすか
• 実行するスクリプトと依存関係をレビューしたか
• 定義内に意図しない指示やプロンプトインジェクションの危険がないか
• 入力データ、利用モデル、外部送信、保存、権限、ログの条件を決めたか
• 問題時に停止し、人の手順へ戻せるか

リポジトリのセキュリティポリシーも、実行スクリプトの確認と、不審なエージェント定義への注意を促しています。全定義を一括導入するより、自社の一つの業務について六項目を書き出し、必要な役割だけを試す方が、影響範囲を確認しやすくなります。

次に増やすのは、停止条件を書ける役割だけ

AIエージェントの導入では、役割の数が成熟度を示すわけではありません。入力、成果物、禁止事項、人間側の責任者、承認、停止条件を一行ずつ書けることが、試行を始める条件です。

まず、公開・送信・承認を含まない一つの業務を選び、AI役割設計シートの「やってはいけないこと」と「停止条件」を埋めてください。書けない欄があれば、エージェントを追加する前に、その判断を誰が持つかを決めます。

AIエージェントの実装全体を検討している方は、先にAIエージェント導入の実際と成功条件をご覧ください。データ、権限、誤情報への対策は、生成AIガバナンスの実務で整理しています。

AMELAの関連情報は、AI Enterpriseの記事一覧とAI活用支援で確認できます。業務に合わせた役割設計や試行計画が必要な場合は、DXコンサルティングの支援範囲をご確認ください。

掲載内容は2026年8月11日時点の情報です。リポジトリの状態、外部サービス、法令、価格などの変動情報は、リンク先の一次情報もあわせてご確認ください。