開発を始める前の基礎学習記事全11節Concept
何をAIに任せ、何を人が検証し、何を人が決めるかを役割表にする
この記事で身につくこと「AIを使って開発する」場面で、AIに任せる作業・人が検証する方法・AIの権限の限界・人が引き受ける判断の4つを区別して説明できる。
記事内目次（22項目）
この記事の会社・人物・役割表はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。この教材全体を通じて、どの作業をAIに任せ、どの方法で人が検証し、AIにはどこまでの権限を与え、最終的に何を人が決めるかを、役割表にする話です。
なぜ必要か。「AIに任せる」と「AIが確認した」を区別しないと、AIが下書きしたものを、AI自身にもう一度確認させただけで「検証済み」だと思い込んでしまう危険があります。
この記事を読むとできるようになること。
- AIに任せる作業・人が検証する方法・AIの権限の限界・人が引き受ける判断の4つを区別して説明できる
- 題材アプリの要件整理を例に、人とAIの役割表を作れる
- AIの自己確認と人の独立した確認の違いを説明し、どの作業にどの確認を求めるかを判断できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（4つの区別と誤解）→第4節（判断すること）→第5.2〜5.3節（役割表と越えてはいけない範囲）→第9節。ここまでで、これから先の記事で繰り返し出てくる「任せる・検証する・決める」の区別が分かり、自分の開発の役割表を埋め始められます。
- 作って確かめる：上に加えて第5.4節（AIに役割表の下書きを頼む）→第6節（下書きに混ざる危険な提案の見つけ方）→第7節。
- 設計判断を深める：上に加えて第8節（失敗の影響と確認の費用から、どの作業にどの確認を求めるか）。
1. 今回の業務課題と完成するもの
この記事でやることは、依頼・承認管理アプリの要件整理を例に、AIに任せる作業と、人が検証する方法、AIが越えてはいけない範囲、最終的な判断者をまとめた「人とAIの役割表」を作ることです。
00-03で工程全体の地図を見ましたが、その多くの工程でAIとの協働が登場します。00-01で「AIがコードを書けても、決めることと確かめることは人に残る」と整理しました。この記事では、その前に「AIと人の役割分担そのもの」を先に決めておきます。
この記事を読み終えると、次のものが手元にできます。
- 人とAIの役割表（作業、任せる範囲、検証方法、証拠、最終判断者）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
AIへの指示
一言でいうと、AIに何を作ってほしいかを伝える文章です。たとえば、「要件一覧の下書きを作ってください」という指示です。
検証
一言でいうと、AIが作ったものが、実際に求めていた条件を満たしているかを確かめることです。たとえば、AIが作った要件一覧を、聞取りメモと1行ずつ照合します。
これがないと、「AIが作った」ことと「要件を満たしている」ことを混同してしまいます。
承認
一言でいうと、その内容で進めてよいと、人が最終的に認めることです。たとえば、要件一覧の内容で開発を進めてよいかは、人が承認します。
システム開発では、この教材のすべての工程で「AIに何を任せ、何を人が検証し、何を人が承認するか」という同じ構造が繰り返し出てきます。
読む順路：工程全体の地図は00-03が該当します。この記事で作る役割表は、07-04（操作権限・停止・引継ぎの条件を決める）でAI実行ルールの原型として使い、07-01（AIへ渡す情報）・07-03（指示と検証）で作業ごとに具体化します。
3. 理解する：4つの区別
3.1 「AIに任せる」と「AIが確認した」は別
| 区別 | 内容 | 例 |
|---|---|---|
| AIに任せる作業 | AIが下書きや案を作る作業 | 要件文の下書き、テストケースの候補 |
| 人が検証する方法 | AIが作ったものを、人（または独立した仕組み）が確認する方法 | 聞取りメモとの照合、要件との対応確認 |
| AIの権限の限界 | AIに与えてはいけない操作の範囲 | 秘密情報を外部へ送る、承認を代行する |
| 人が引き受ける判断 | 最終的に人が決めること | この要件一覧で進めてよいかの承認 |
3.2 よくある誤解
「AIにもう一度確認させれば、検証したことになる」。同じAIが自分の出力をもう一度見ても、独立した確認にはなりません。人による確認、または要件から独立して定めた期待結果との照合が必要です（記事Bで詳しく扱います）。
「AIは何でも任せてよい」。秘密情報の扱いや、承認のような人の責任が伴う判断は、AIに任せません（第4.2節）。
「役割分担は工程ごとに毎回考えればよい」。基本の考え方を先にこの記事で決めておくことで、07以降の各記事で繰り返し議論する手間を減らせます。
4. 判断すること
役割表を作るときに人が判断することは、次の4つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 各作業を「任せる」か「任せない」か | 任せる基準が無いと、作業ごとに毎回迷うか、なし崩しに全部任せる | 可（失敗の影響が小さい作業は「任せる」で仮置きし、第8.1節の基準で見直す） | 承認ルールの決定のような業務上の判断まで任せ、「AIがそう言ったから」が決定の根拠になる |
| 任せる作業を、どう検証し、何を証拠に残すか | 「AIに任せる」と「AIが確認した」を分ける唯一の手段。証拠が無いと後から説明できない | 不可。任せる作業には必ず検証方法と証拠を書く | AIの「できました」がそのまま完了報告になり、要件を満たしていない成果物が次工程へ渡る |
| AIが越えてはいけない範囲（禁止事項） | 文書に書いていない禁止は守られない。07-04の実行ルールの元になる | 不可。秘密情報の外部送信・本番接続・承認の代行は最初から禁止に置く | 実データがAIサービスへ送られる。業務上の承認がAIの判断で行われる |
| 最終判断者は誰か | 「AIが作った」ものに責任を持つ人が決まっていないと、問題が起きたとき誰も説明できない | 可（架空の題材では総務課長・検証担当で仮置き。実際の業務では体制を確認して書き直す） | 誰も承認していない成果物が使われる |
勝手に決めてはいけないこと：秘密情報の外部送信、本番環境への接続、承認の代行を、AIに任せる作業に含めません。最終的な承認・判断は、人（この記事の題材では総務課長・担当者）が行います。AIに委ねません。
AIに任せる範囲（この記事自体について）：役割表の一般的な項目候補（作業の種類、検証方法の一般例）の提示はAIに任せられますが、実際にどの作業をどこまでAIに任せるか、何を禁止するかは、この教材の方針として人が決めます。AIが「この作業も任せられます」と提案しても、それは提案であって決定ではありません。
5. 作って確かめる：人とAIの役割表を作る
5.1 準備
00-03の工程地図（各工程でAIとの協働が登場すること）を確認します。
5.2 人とAIの役割表
| 作業 | 任せる範囲 | 検証方法 | 証拠 | 最終判断者 |
|---|---|---|---|---|
| 要件文の下書き作成 | AIに任せる（聞取りメモをもとに下書き） | 聞取りメモ・制約と1行ずつ照合する | 照合結果の記録（02-01） | 要件を承認する人（架空：総務課長） |
| 承認ルールの決定（自己承認禁止など） | AIに任せない（人が決める） | — | 決定の記録（記事A・設計書5.2） | 総務課長（架空） |
| テストケースの候補出し | AIに任せる | 要件・受入条件との対応を確認する | 対応表（09-01・09-02） | 検証担当（架空） |
| 実際のテスト実行と結果の記録 | AIに任せる（実行はAIが行ってよい） | 実行結果を期待結果と照合する。AI自身の「できた」という報告だけで済ませない | 実行記録（09-02） | 検証担当（架空） |
| 秘密情報・実データの外部送信 | AIに任せない（禁止） | — | — | — |
| 依頼の承認そのもの（業務上の承認） | AIに任せない（禁止） | — | — | 承認者（記事Aの役割） |
この表の「作業・任せる範囲・検証方法・証拠・最終判断者」という列は、この教材全体で人とAIの責任分界を表すときの共通の形です。07-01（渡す情報）・07-03（指示と検証）・記事B（テストで確かめる）は、この表の行を作業ごとに具体化したものにあたります。
5.3 AIが越えてはいけない範囲
- 秘密情報・実データを外部（AIサービスを含む）へ送信すること
- 本番環境や実際のデータベースへ接続すること
- 業務上の承認（依頼の承認など）を代行すること
これらは、07-04（操作権限・停止・引継ぎの条件を決める）で、より具体的なAI実行ルールとして扱います。
5.4 AIに役割表の下書きを頼む
一般的な役割分担の項目候補をAIに出させます。渡す情報と渡さない情報を先に決めます。
| 渡す情報 | 内容 | 渡さない情報と理由 |
|---|---|---|
| 作業の例 | 要件文の下書き、テストケースの候補出し、実際の承認判断（架空の題材） | 実際の社内体制・担当者名（架空の役割名だけを使う） |
| 役割表の列 | 作業・任せる範囲・検証方法・証拠・最終判断者 | — |
| してはいけないこと | 秘密情報の外部送信・承認の代行を「任せてよい」と提案しないこと | — |
指示文は次のとおりです。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。
AIを使ってシステム開発を進める際の、人とAIの役割分担表を作りたいです。作業の例として、要件文の下書き、テストケースの候補出し、実際の承認判断があります。
依頼：
1. 各作業について、AIに任せてよいか、人が検証する方法の候補を挙げてください。
2. AIに任せてはいけない作業の一般的な例も挙げてください。
してはいけないこと：
- 秘密情報の外部送信や、業務上の承認をAIに任せてよいとは提案しないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 「承認ルールの決定もAIに任せられます。効率的です」と、業務上の承認判断をAIに任せる案として記載していた
- 「AIが自分でテスト結果を確認すれば十分です」と、独立した検証を省略する案を記載していた
6.2 見つけ方と直し方
下書きの各行を、第3.1節の4つの区別と、第4節の禁止事項に1行ずつ照合します。見るところは2つです。「任せる」と書かれた作業が、業務上の判断（承認ルール）や禁止事項（秘密情報・承認の代行）に当たらないか。「検証方法」の欄が、AI自身の確認だけになっていないか。
| 問題点 | なぜ問題か | どう見つけるか | 誰が判断するか | どう直したか |
|---|---|---|---|---|
| 「承認ルールの決定もAIに任せられます。効率的です」 | 自己承認を認めるかは、この会社の統制のルール。AIの一般論を決定にすると、後から「誰が決めたか」を説明できない（第4節） | 「任せる」と書かれた行の作業が、記事AのQ表のような「仮置き不可」の業務上の決定に当たるかを見る | 業務の責任者（架空：総務課長） | 「AIに任せない（人が決める）」に修正し、証拠を「決定の記録」にした |
| 「AIが自分でテスト結果を確認すれば十分です」 | 実装したAIと同じ前提で確認しても、思い込みは検出できない（第3.2節） | 「検証方法」の欄に、AI以外の主体（人）または要件から独立した基準（期待結果との照合）があるかを見る | 検証担当（架空） | 「実行結果を期待結果と照合する。AI自身の報告だけで済ませない」に修正した |
「効率的です」のような、根拠ではなく利点だけを添えた提案は、判断を急がせる形になりやすい箇所です。利点があっても、第4節の禁止事項に当たるなら採用しません。
AIへの修正指示は次のとおりです（説明用の例）。
指摘：
1. 承認ルールの決定はAIに任せません。人が決める作業として記載し、証拠は「決定の記録」としてください。
2. テスト結果の確認は、AI自身の確認だけでなく、要件から独立した期待結果との照合にしてください。
変えないこと：
- 役割表の列（作業・任せる範囲・検証方法・証拠・最終判断者）は変更しないでください。6.3 修正後の役割表
修正後の役割表は、第5.2節のとおりです。採用したのは「この教材でのAIと人の分担の型」であり、実際の開発体制では担当者名・責任者を確認して書き直します（第8.2節）。
7. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 作業ごとに「任せる／任せない」と理由がある | 第5.2節の全行に記載 |
| 検証方法と証拠の欄が空でない | 任せる作業の行にはすべて記載 |
| AIが越えてはいけない範囲が明記されている | 第5.3節に3項目を記載 |
残る制限：この役割表は架空の題材に基づく一例です。実際の業務では、担当者・責任者の名前や体制を確認して書き直す必要があります。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 どの作業にどの確認を求めるか
| 観点 | 内容 |
|---|---|
| 失敗の影響が大きい作業（承認ルールの決定など） | 人が最初から関わり、AIには任せない |
| 失敗しても直しやすい作業（要件文の下書きなど） | AIに任せ、人が照合して直す |
| 費用（確認にかかる手間）が大きい作業 | 独立した検証の頻度・範囲を、失敗の影響とのバランスで決める（09-02〜09-04で扱う） |
失敗した場合の影響が大きい作業ほど、AIの自己確認ではなく、人による、またはAIから独立した方法での検証を求めます。
8.2 適用限界
この役割表は、架空企業「みらい業務サービス」の小規模な社内アプリ開発を前提にしています。開発体制の規模や、扱うデータの機密性が変わる場合は、役割表を見直す必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 人とAIの役割表ひな形（作業、任せる範囲、検証方法、証拠、最終判断者） | templates/00-04-human-ai-roles_template.md | templates/00-04-human-ai-roles_example.md |
自分の業務に使うときの手順は次のとおりです。
- 自分の開発で発生する作業を挙げる
- 各作業について、AIに任せてよいかを判断する
- 任せる場合は検証方法と証拠を書く
- AIが越えてはいけない範囲を明記する
10. 次工程への受渡し
次へ渡すもの：人とAIの役割表、AIが越えてはいけない範囲。
次工程での使われ方：01-01（利用者と業務の現場を知る）では、この役割表の「人が判断する項目」を引き継ぎます。07-04（操作権限・停止・引継ぎの条件を決める）では、この役割表を原型にAI実行ルールを作ります。
前工程へ戻る条件：この役割表の内容が、実際の工程で足りないと分かったら、この記事に戻って見直します。
11. 根拠と更新情報
- この記事の会社・人物・役割表はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- AIの自己確認と人による独立した確認を区別する考え方は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第6.1節（VERIFY段階の考え方）に基づきます。 - 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 役割表の列（作業・任せる範囲・検証方法・証拠・最終判断者）は、
docs/content/LEARNING_UNIT_SPEC_V1.md第6節（人とAIの責任分界）の表に対応させています。 - 2026-09-20（Phase 5B-2A）：読む順路（3つの深さ）、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響）、第5.4節の渡す情報の表、第6.2節のレビュー観点の表、記事間の参照を追加した。役割表の内容・完了条件は変えていない。
- 未確認事項：この役割表は架空の体制に基づく一例であり、実際の開発体制での運用は確認していません。