FDE（Forward Deployed Engineer：顧客の現場に入り業務理解と技術実装をつなぐ技術者）が関与するAI導入案件では、日々のタスク分担だけでなく「誰がどの条件で決定するか」をあらかじめ定義しておく必要があります。業務範囲の承認、プロンプトやモデルの実装、アクセス権限の付与、異常時の停止と再開は、それぞれ評価の観点と責任範囲が異なります。本稿では、これらを曖昧にまとめず、各行で最終判断者（A）を1名に固定した決定台帳を用いて判断の滞留を防ぐ手順を整理します。
役割分担表で整理する意思決定の範囲
AIシステムを業務へ導入する現場では、業務プロセスの整理からモデル選定、外部連携の実装まで多岐にわたる検討が並行します。タスク一覧表を作成するだけでは、仕様の変更要望が生じた際や想定外の回答が出現した際に「誰の承認で止めるのか」「どのような技術確認を経て再開するのか」が曖昧になり、現場の作業が停止します。試行期におけるルールの未整備による作業停止を防ぐには、中小企業のAI導入 失敗パターン7選に照らして判断基準を事前に取り決めます。
本稿で扱う役割分担表は、契約上の法的な損害賠償責任を確定する書類ではなく、案件開始時や仕様変更時に現場の関係者が迷わず合意形成を進めるための実務ツールです。FDEの業務範囲は企業ごとに異なり、例えばLayerXの公式採用解説でも触れられているように、前後の業務プロセスや暗黙知を理解し、ログ解析からAIワークフロー実装へ接続する実務像が示されています。だからこそ、どの判断を利用部門の責任者が行い、どの検証を技術側が担うのかを明確に区別しなければなりません。
本設計では、日常的な作業の割り振りから離れ、「業務利用の妥当性」「システム実装の採用」「参照権限の付与」「異常時の停止と再開」という決定領域に絞って役割を配置します。
対象業務の整理を進める入口として、AI自動化診断をご活用いただけます。
少人数でも判断の役割を分ける設計規則
RACI（レイシー）は、業務に関わる関係者の責任の度合いを整理するフレームワークです。一般には、実行責任者（R: Responsible）、説明・結果責任者（A: Accountable）、助言者（C: Consulted）、報告先（I: Informed）の4文字で表されます。本稿のテンプレートでは、意思決定の滞留を防ぐため、この一般的な記法に以下の運用規則を加えて適用します。
- 1行1Aの原則：1つの判断事項に対し、Aを担う役割は必ず1役に限定します。共同責任として複数人にAを割り振ると、判断遅延時の責任所在が曖昧になるためです。
- 原則としてのR/A分離：即時性が求められる緊急停止（D04）の例外を除き、同一行でのR/A併記は認めません。
- 意思決定専任行のR空欄：現場運用の再開可否など、純粋な意思決定のみを扱う行（D06）ではRを空欄とし、決定後の実作業担当は別途指定します。
少人数の体制では1人の担当者が複数の役割を兼任することがあります。ここで注意すべきは、「表上の記号配置」と「実在の人物による独立性の担保」を混同しないことです。例えば、表上ではFDE実装担当にR、技術承認者にAと分かれていても、同一人物が両方の役割を兼務していれば実態は自己承認になります。自ら作成したプロンプトや連携構成を自ら承認しては客観的な技術審査が機能しません。そのため、判断行ごとに実名対応表を照合し、当該実装を担当していない別の技術確認者（社内の別エンジニア等）がAを担う体制を確保します。代理者を立てる場合も同様に自己承認の発生を防ぎます。
本稿では、関係者を以下の4つの役割に分類します。
- 業務責任者：利用部門の責任者。業務の受入基準を満たしているか、現場への展開を許可するかを判断します。
- FDE実装担当：顧客の業務プロセスを理解し、プロンプト調整やAPI連携などの実開発と現場検証を担当します。なお株式会社ネオシステムのサービス紹介では、同社独自の体制例としてFDEをビジネス側と開発側に分ける分担例が示されていますが、これは同社固有の例であり業界普遍の標準ではありません。職種としての役割定義や目指し方については、FDEのキャリア解説記事で詳しく整理しています。
- 技術承認者：システム全体の構成案、API連携、セキュリティ設定などを審査し、所定の技術観点と証拠を確認して承認するエンジニアです。なお、技術承認は所定の観点や証拠を確認する役割であり、将来の安全性や無障害を万能に保証するものではありません。
- 権限管理者：社内規程に沿った情報開示範囲であるかを審査し、データ保管場所のアクセス権を管理する担当者です。
役割分担表でAに指定されたからといって、システムの操作権限が自動的に付与されるわけではありません。役割表は合意形成の取り決めであり、実際のシステムアクセス権限は権限管理者が正式な手続きを経て個別に付与します。
案件開始時の意思決定を整理した記入例
架空の案件として「社内規程問い合わせ支援システム」を題材にします。この仕組みは、従業員からの規程に関する問い合わせに対し、AIが回答候補と根拠規程の該当箇所を画面上に提示し、窓口担当者が内容を目視確認して返信する小規模な社内ツールです。AIによる自動送信や自動承認は行いません。
以下に主要な判断事項の分担例を示します。表中の条件は提案テンプレートであり、実在の案件で合意された確定事項ではありません。また、実際の社内担当者名は公開表には含めず、別途管理します。
| 判断事項（ID） | 業務責任者 | FDE実装担当 | 技術承認者 | 権限管理者 | 成立条件（提案） |
|---|---|---|---|---|---|
| 業務範囲承認（D01） | A | R | C | I | 窓口担当者による全件目視確認を前提とし自動送信を行わない設計案であること |
| 技術実装承認（D02） | C | R | A | C | 応答遅延が許容範囲内でありAPIキーが安全に管理されている構成案であること |
| 参照権限承認（D03） | C | R | C | A | 参照対象が全社公開規程のみに限定され部外秘規程が含まれていないこと |
| 緊急停止実行（D04） | I | R/A | I | I | 事前合意された停止条件（誤回答率や異常検知）に該当すること |
| 再開技術確認（D05） | C | R | A | C | 原因となった設定またはプロンプトの修正検証が完了していること |
| 業務再開判断（D06） | A | （空欄）* | C | I | 再開技術確認（D05）が完了し窓口の受入態勢が整っていること |
業務範囲の承認（D01）では業務責任者が最終判断（A）となります。一方、技術実装の承認（D02）では技術承認者がAとなります。業務利用の許可と技術実装の承認は別の判断として分離することで、技術的なリスクを業務側の都合で見切り発車させない構造を作ります。
表中の成立条件を実案件で設定する際は、抽象表現を具体的な確認証拠へ落とし込む必要があります。例えばD02の「許容範囲内」「安全に管理」は、測定対象（95パーセンタイル応答時間など）やシークレット管理方式の設計書を提示条件とします。D04の「誤回答率や異常検知」も、測定対象・分母・集計期間・判定者・停止閾値、検知事象と確認方法が未設定のままでは機能しません。D05の「修正検証が完了」についても、テストケースの実行ログや再現確認結果といった合意証拠が必要です。
D06（業務再開判断）においてRが空欄となっているのは、現場での運用再開を許可するかどうかの「意思決定のみ」を定義しているためです。役割表でAに指定されたとしてもシステムの変更権限が自動付与されるわけではありません。業務再開の承認が下りた後は、実際のシステム設定変更や画面公開を行う操作担当者、必要な操作権限、実施ログの管理先を別途台帳で確定して作業を進めます。
仕様変更・緊急停止・業務再開と承認者不在時の扱い方
AIシステム運用中には、仕様変更の要求や予期せぬ回答の発生といった事態が生じます。現場の混乱を防ぐため、通常の仕様変更と異常時の停止・再開それぞれについて決定手順を事前に合意しておきます。
日常の運用で新たな参照文書の追加や回答ロジックの調整といった仕様変更を受け付けた場合は、以下の手順で進めます。すべての軽微な変更に一律の再承認を義務づけるのではなく、影響度に応じて見直すべき判断行を特定します。
- 1. 変更要求の記録：変更内容、理由、要求元を意思決定台帳に起票します。
- 2. 影響判断行の特定：回答スコープが変わるなら業務範囲（D01）、モデルやAPI構成が変わるなら技術実装（D02）、参照規程が広がるなら参照権限（D03）を再判断対象として抽出します。
- 3. 成立条件の充足と承認：該当する判断行の成立条件に基づき、証拠（テスト結果や規程開示許可）を添えて各承認者（A）の確認を受けます。
- 4. 実施担当への引渡しと版管理：承認完了後、FDE実装担当へ作業を引き渡します。合意内容と設定の版（バージョン番号）を台帳に記録します。
次にシステムの緊急停止についてです。事態の悪化を防ぐため、本案件の提案として、事前合意された停止条件に該当した時点で現場のFDE実装担当者が単独で緊急停止を実行（R/A）できる権限設定を置いています。ただし、この停止権限は本設計における提案であり、普遍的な規則ではありません。停止条件・対象機能・通知先が事前に合意されていない場合は、本番運用を開始してはなりません。停止を実行した後は、関係者へ速やかに結果を通知（I）します。
システムの再開は停止と異なり、2段階の判断ゲートを設けます。第1段階は「再開技術確認（D05）」であり、技術承認者が修正内容を確認してAとして承認します。第2段階は「業務再開判断（D06）」であり、D05の承認完了を前提として、業務責任者が現場運用の再開を決定します。技術確認を経ずに現場判断だけで再開させることは認めません。実際の再開操作や現場への引き渡し手順については、運用引継ぎにおける操作試験と完了条件で整理しています。
- 合意済み停止条件への該当時 緊急停止の実行（D04） 事前に合意した停止条件（誤回答率や異常検知）に該当した場合に限り、FDE実装担当者が単独で緊急停止を実行（R/A）し、業務責任者・技術承認者・権限管理者へ速やかに通知（I）する。
- 停止後 原因調査と修正検証 FDE実装担当者が設定やプロンプトの不具合原因を特定し、修正と検証ログを整備する。
- 検証完了時 第1段階：再開技術確認（D05） 技術承認者が修正検証ログを確認して承認（A）。未充足または承認者が不在かつ代理なしの場合は停止を継続。
- 技術承認後 第2段階：業務再開判断（D06） 業務責任者が受入態勢を確認して再開を判断（A）。D05未完了や条件未充足なら停止継続。不在時は合意済み代理が担当。
- 業務承認後 再開操作の実施と記録 別途指定された操作担当者が所定の権限でシステム設定変更・画面公開を実施し、ログを記録する。
技術確認（D05）または業務判断（D06）で否認、あるいは未合意・代理不在の場合は停止を継続します。承認権限とシステム操作権限は分離されています。
承認者が不在となる場合の臨時代理についてもルールを定めます。代理を立てる場合は、無制限に権限を与えるのではなく「対象となる判断事項」「代理を務める役割」「有効期間」「代理発動の条件」を事前に合意します。代理適用時は元のAを置換して単一のAを維持し、二重Aにしてはなりません。事前の合意がないまま現場の裁量で代理を立てることは禁止し、合意済みの代理者がいない場合は判断を保留とします。
合意に至っていない事項については、曖昧なまま作業を進めず「未合意」として台帳に記録し、保留期間中に制限される実務の範囲を定義します。なお合意形成後も、否認時や条件付承認における未充足条件がある場合は制限を維持し、合意済イコール一律の制限解除とは扱いません。例えばD03（参照権限承認）が未合意の段階では、架空データまたは利用許可取得済みデータを用いた検証のみを許可し、参照権限が未合意の実データは開発環境であっても一切使用を禁止します。
CSVテンプレートを使った会議の進め方
役割分担表をプロジェクトに導入する際は、関係者が集まる会議の場で配布テンプレートを投影しながら項目を確定させていきます。
手順1：参加者の確定と兼務関係の確認
・各役割の実名・連絡先を台帳とは別に一覧化する
・兼務がある場合、自作実装の自己承認など独立性を欠く配置がないか確認する
手順2：判断事項ごとの1行1Aの割り当て
・各判断事項について、最終決定権（A）を1役割に限定して指定する
・作業を担当する者（R）、事前に意見を求める者（C）を整理する
手順3：成立条件の明文化
・どのような客観的証拠が揃えば判断を下せるのかを言語化する
手順4：未合意事項と保留影響の台帳登録
・その場で決定できない事項は、確認担当・期日・保留中の実務制限を台帳に記録する
要件の合意形成においては、IPA『ユーザのための要件定義ガイド第2版』に基づく解説であるDX SQUARE「要件定義とは？」（IPA）に示されているように、ビジネス要求とシステム化要求を文書化して関係者と合意を形成するプロセスが参考になります。ただし同記事が参照するガイドのコラムでも指摘されている通り、要求と要件に普遍的な標準定義があるわけではないため、本表の成立条件も関係者間での合意形成枠組みとして運用します。判断基準の前提となる業務要件の整理手順は、FDEによる要件ヒアリングの進め方を参照してください。
配布資材の構成とダウンロード
本稿で解説した役割分担の設計ルールを実務で利用できるよう、空欄テンプレート、架空案件の記入例、未合意事項を追跡する意思決定台帳をまとめた資材を用意しました。なお、配布資材はファイル構成および初期状態を実物照合済みですが、個別の実案件における運用効果を検証した確定仕様ではなく、現場の状況に応じた調整を前提とする設計雛形です。
- responsibility_blank.csv：列定義のみを記載した空欄の役割分担表テンプレート（6列）です。
- responsibility_example.csv：架空案件に基づいた記入例（6列）です。各行1Aの原則に基づき、D04の緊急停止（FDE実装担当のR/A併記）やD06の業務再開判断（FDE欄空欄）を含む初期設定を収録しています。
- decision_log.csv：未合意の判断事項、確認担当、期限、実務制限などを記録する意思決定台帳の雛形（12列6行）です。初期状態ではD01〜D06の全行が状態「未合意」、判断記録「未記入」、確認担当・期限・代理関係が「未設定」となっています。
- README.md：編集部作成・実案件未検証である旨の明記、RACI記法、代理規則、兼務対応表の運用ルールを記載した説明書です。
資材一式は以下のリンクからダウンロードできます。
FDE役割分担表テンプレート資材一式（ZIP）をダウンロードする
よくある質問
少人数のチームで同じ人が複数の役割を兼任できますか？
本表の設計ルール上、体制の制約から1人が複数役割を兼任することは可能です。ただし表上の役割列は統合せず、実務担当者との対応表を別途管理してください。実装者が自ら技術承認を行う自己承認は禁止し、客観的なチェックを行う別担当者を立てる必要があります。
業務側と技術側の両方を最終承認者（A）に設定できますか？
本表の設計ルールでは、1つの判断事項に複数のAを配置することはできません。合意が割れた際の責任の所在が曖昧になるためです。業務面と技術面の双方が重要な場合は判断行を2つに分割し、技術確認の完了を業務受入の前提条件とする二段階の設計にしてください。
承認者が不在のときは誰が代わりに決定を下しますか？
意思決定台帳で代理役割、適用条件、有効期間が事前合意されている場合のみ代理判断が可能です。代理適用時は元のAが置換され二重Aを防ぎます。事前合意がない場合は緊急時であっても代理権限は発生せず、判断は保留扱いとなります。
この役割分担表を作成すれば契約上の責任も確定しますか？
本表は現場の合意形成と意思決定の停滞防止を目的とした実務ツールであり、契約上の法的責任を確定するものではありません。法的責任の所在については、別途締結する契約書などの正式な合意文書で定めてください。
参考資料
本稿の役割分担モデルの作成にあたり参照した一次資料は以下の通りです（確認日：2026-10-08）。
- 株式会社ネオシステム FDEサービス：同社独自の体制例としてFDEをビジネス側と開発側に分けた分担が記載されています。同社固有の分担例であり普遍的標準ではありません。
- 株式会社LayerX FDE採用解説：業務プロセスや暗黙知を理解しAIワークフロー実装へつなぐFDEの役割が解説されています。
- DX SQUARE 要件定義とは？（IPA）：「ユーザのための要件定義ガイド第2版」に基づく解説記事であり、要求とシステム化要求の合意形成プロセスについて参照しました。
自動化を進める対象業務を整理したい方は、まずはAI自動化診断をご利用ください。
