AIと進める作業の設計学習記事全11節Design
「承認処理」を4つの作業に分け、依存関係と衝突しやすい箇所を書く
この記事で身につくこと一回の変更と確認の範囲を明確にする理由と、並行作業で衝突が起きる仕組みを説明できる。
記事内目次（24項目）
この記事の会社・人物・作業例はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。「承認処理」という1つのまとまった作業を、状態の確認→権限の判定→状態変更と履歴追加→重複対策という4つの小さな作業に分け、依存関係と確認方法を決める話です。
なぜ必要か。作業を大きなまま進めると、どこまで確認すればよいかが分からなくなったり、複数人（またはAIと人）が同じファイルに同時に手を入れて衝突しやすくなったりします。この「開発作業の衝突」は、アプリの利用者が同じ依頼を同時に更新する「利用時の競合」とは別の問題で、この記事では前者だけを扱います。
この記事を読むとできるようになること。
- 一回の変更と確認の範囲を明確にする理由と、並行作業で衝突が起きる仕組みを説明できる
- 「承認処理」を4つの作業に分解し、依存関係と確認方法を作業分解表に書ける
- 作業の粒度を、確認のしやすさ・手戻りの大きさ・衝突から判断できる
- 「開発作業の衝突（コード）」と「利用時の競合（データ）」が別の問題であることを説明し、それぞれをどの記事で扱うか言える
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（分ける理由と、2種類の「衝突」の違い）→第4節（判断すること）→第5.2節（作業分解表）→第9節。ここまでで、作業を「入力・出力・確認方法・依存」で区切る形が分かります。AIへの依頼は出てきません。
- 作って確かめる：上に加えて第5.3節（開発時に衝突しやすい箇所）→第5.4節（AIに下書きを頼む）→第6節（初稿に混ざる2種類の衝突の混同と、依存の循環の見つけ方）→第7節。
- 設計判断を深める：上に加えて第8節（作業の粒度の比較、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、03-04の開発計画にある「承認処理の実装」という作業を、状態の確認・権限の判定・状態変更と履歴追加・重複対策という4つの小さな作業に分解し、それぞれの入力・出力・確認方法・依存関係を書くことです。
07-01ではAIへ渡す資料を絞り込みましたが、その資料をどの単位の作業に対して使うかはまだ決めていません。この記事では、その作業の単位を決めます。
この記事を読み終えると、次のものが手元にできます。
- 作業分解・依存関係表（作業、入力、出力、確認方法、依存する作業、同時に触れる範囲）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
作業の粒度
一言でいうと、1回の変更と確認をどれくらいの大きさで区切るかです。たとえば、「承認処理全体」を1つの作業にするか、「状態の確認」「権限の判定」のように分けるかです。
並行作業の衝突（開発時）
一言でいうと、複数の作業者（人やAI）が同じファイルや関数に同時に手を加えることで、片方の変更が失われたり、つじつまの合わない組み合わせになったりすることです。
たとえば、AIが approval.js の権限判定を書き換えている間に、人が同じファイルの状態判定を直すと、どちらかの変更が消えるか、両方を合わせたときに動かなくなります。
これがないと、作業の範囲があいまいなまま進み、どこまで確認すればよいか分からなくなったり、AIと人、あるいは複数の作業者が同じ部分を同時に変更して衝突したりします。
読む順路：AIへ渡す情報セットは07-01、変更の記録と分岐（branch）の考え方は06-03が該当します。この記事の作業分解は、07-03（指示・検証・修正の手順）の指示単位、08（実装）の実装単位になります。利用者どうしの同時更新は05-02・09-03で扱います。
3. 理解する：なぜ作業を小さく分けるか
3.1 分けないとどうなるか
| 分けない場合 | 分けた場合 |
|---|---|
| 「承認処理」全体を一度に確認しようとして、どこに問題があるか分かりにくい | 4つの作業ごとに確認でき、問題の場所を絞り込みやすい |
| 複数の作業者（人・AI）が同時に承認処理全体のコードに触れ、衝突しやすい | 同時に触れるファイル・関数の範囲が明確になり、衝突を避けやすい |
3.2 よくある誤解
「作業は細かく分けるほどよい」。細かすぎる分割は、依存関係の管理が煩雑になります。第8節で、適切な粒度を判断します。
「依存関係は気にせず、思いついた順に進めればよい」。依存関係を無視すると、まだ確認していない前提の上に次の作業を進めてしまい、手戻りが起きます。
「作業を分ければ、利用者どうしの同時更新も防げる」。作業分解は開発中の衝突を減らすものです。利用者が同じ依頼を同時に承認・再提出する問題は、アプリの設計（状態条件）で防ぐもので、別の問題です（第3.3節）。
「依存する作業でも並行して進めれば速い」。作業2（権限の判定）は作業1（状態の確認）の結果に依存します。並行して進めると、前提が崩れた状態で判定してしまう可能性があります。
3.3 「開発時の衝突」と「利用時の競合」は別の問題
結論から言うと、この記事で扱う「衝突」は、作るときに起きるコードの衝突です。使うときに起きるデータの競合は、別の場所で別の方法で防ぎます。2つは言葉が似ているため混同されやすく、混同すると「作業を分けたから同時更新も大丈夫」という誤った安心につながります。
| 観点 | 開発時の衝突（この記事） | 利用時の競合（05-02・09-03） |
|---|---|---|
| 誰が | 開発者どうし、または人とAI | アプリの利用者どうし（承認者と依頼者など） |
| 何に対して | 同じファイル・同じ関数（コード） | 同じ依頼のデータ（保存先の1件） |
| いつ起きるか | 実装している最中 | アプリが動いている最中 |
| 例 | 2人が approval.js を別々に直し、あとで合わせると片方の変更が消える | 承認者が承認する操作と、依頼者が再提出する操作が入れ違い、承認済みの依頼が提出済みに戻る |
| どう防ぐか | 作業を分け、同時に触れるファイルを分ける。変更の記録と分岐（06-03）で合流時に差分を確認する | 保存先の状態条件（更新前の状態が期待どおりのときだけ更新する）。05-02の状態遷移表、09-03の確認 |
| 防げなかったときに見えるもの | 合流時の差分の衝突（merge conflict）、動かないコード | 二重承認、消えた再提出、承認履歴の欠落 |
開発時の衝突は「作業の進め方」で減らせます。利用時の競合は「アプリの作り」で防ぎます。この記事の第5.3節は前者だけを扱い、後者は作業4（重複対策）の確認方法として09-03へ渡します。
4. 判断すること
作業を分けるときに人が判断することは、次の4つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| どの粒度で区切るか（1回の変更と確認の大きさ） | 大きすぎると問題の場所が絞れず、小さすぎると依存の管理が煩雑（第8.1節） | 可（この記事では4つ。実装しながら分け直してよい） | 「承認処理」を一度に頼み、返ってきたコードのどこが要件に反するか分からない |
| 各作業の確認方法を、どの要件に結びつけるか | 「動けばよい」では確認にならない。確認方法は要件（REQ-006・007）から書く | 不可。確認方法の無い作業は分解が終わっていない | 状態変更と履歴追加が片方だけ成功しても「動いた」ことになる（REQ-007違反） |
| 依存関係をどう決めるか（何が終わってから何を始めるか） | 依存を無視すると、未確認の前提の上に次の作業を積む | 不可。循環があれば分け方を見直す | 権限判定を状態確認より先に作り、状態が提出済みでない依頼を承認する経路が残る |
| 同時に触れてよいファイル・関数の範囲 | 開発時の衝突（第3.3節）は、同じファイルに同時に手を入れるときに起きる | 可（この記事では「1つの関数につき同時に1人」で仮置き。体制に合わせて06-03で見直す） | AIと人が同じ関数を同時に直し、合流時にどちらかの変更が消える |
勝手に決めてはいけないこと：03-04の開発計画にない作業を、この記事で新しく作りません。05-02の状態遷移表・05-03の権限表にない条件を、この記事で追加しません。利用時の競合（同時更新）をどう防ぐかは、この記事で決めません（05-02・09-03で扱います）。
AIに任せる範囲：作業の分解案、入力・出力・確認方法の下書き、依存関係の図示はAIに任せられます。しかし、粒度の決定、確認方法が要件に結びついているかの確認、依存に循環が無いかの確認、同時に触れてよい範囲の決定は人が行います。AIの分解案は、開発時の衝突と利用時の競合を1つの表に混ぜてくることがあります（第6節）。
5. 作って確かめる：作業分解・依存関係表を作る
5.1 準備
03-04の開発計画、07-01の情報セット（状態遷移表・権限表を含む）を用意します。
5.2 作業分解・依存関係表
| 作業 | 入力 | 出力 | 確認方法 | 依存する作業 |
|---|---|---|---|---|
| 1. 状態の確認 | 依頼の現在の状態 | 「提出済みかどうか」の判定結果 | 提出済み・下書き・承認済みなど各状態を入力して判定結果を確認する | なし |
| 2. 権限の判定 | 操作者の役割、割当情報 | 「割当承認者かつ自己承認でないか」の判定結果 | 割当外・自己承認のケースで拒否されることを確認する | 1（状態が提出済みであることが前提） |
| 3. 状態変更と履歴追加 | 判定結果（1・2が正常な場合） | 状態の更新、履歴の追加 | 状態変更と履歴追加が両方完了すること、片方だけで終わらないことを確認する（REQ-007） | 1、2 |
| 4. 重複対策 | 同一操作の識別情報 | 二重処理の防止結果 | 同じ操作を2回実行し、履歴が1件のままであることを確認する（REQ-006）。利用者どうしの入れ違いは09-03で確認する | 3 |
依存関係は1→2→3→4の一方向であり、循環はありません。
5.3 並行作業時（開発時）に衝突しやすい箇所
ここで扱うのは、開発中に人とAI（または複数の開発者）が同じコードに手を入れることで起きる衝突です（第3.3節）。承認処理を実装するファイルを approval.js（判定）と storage.js（保存）の2つと仮定して整理します。
| 箇所 | なぜ衝突しやすいか | 対処 |
|---|---|---|
作業1と作業2（同じ approval.js の判定関数） | 状態の確認と権限の判定を、同じ関数に別々の作業者が同時に足すと、条件の順序や戻り値がかみ合わなくなる | 作業1を先に終えて確認してから作業2に着手する。同じ関数に同時に2人（人とAI）が手を入れない |
作業3と作業4（同じ storage.js の保存処理） | 状態変更と履歴追加の保存処理に、重複対策を同時に足すと、「1回の書き込み」の約束（REQ-007）が崩れる | 作業3が完了し、REQ-007の確認（片方だけで終わらないこと）が済んでから作業4に着手する |
| AIに複数の作業を一度に頼む場合 | AIは指示された範囲を超えて隣の作業のコードも書き換えることがあり、人の変更と衝突する | 1回の指示は1つの作業に限定し（07-03）、変更されたファイルの差分を人が合流前に確認する（06-03） |
同時に触れてよい範囲の基準：1つの関数につき同時に1人（人またはAI）。別のファイルなら並行してよいが、合流時に差分を確認する。
利用者どうしの同時更新（承認と再提出の入れ違いなど）は、ここには書きません。それは作業4の確認対象であり、09-03で保存先の状態条件として確かめます。
5.4 AIに作業分解の下書きを頼む
材料（開発計画、状態遷移表、権限表、要件ID）がそろうと、作業分解表の下書きをAIに頼めます。AIがするのは、作業を表の形に分けて入力・出力・確認方法・依存を埋めることです。粒度・依存・同時に触れる範囲の決定は人が行います。
| 渡す情報 | 内容 | 渡さない情報と理由 |
|---|---|---|
| 分解する作業 | 03-04の開発計画の「承認処理の実装」 | 開発計画の他の作業（今回は承認処理だけ） |
| 設計資料 | 05-02の状態遷移表（提出済み→承認済み）、05-03の権限表（承認者の行）、REQ-003・006・007 | 秘密情報・実データ（07-01の除外一覧と同じ） |
| 表の列と用語 | 作業・入力・出力・確認方法・依存する作業。「衝突」は開発時のコードの衝突を指す、と定義して渡す | — |
指示文は次のとおりです。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。
架空企業「みらい業務サービス」の依頼・承認管理アプリで、「承認処理の実装」という作業を、確認できる単位に分解した表の下書きを作ってください。
材料：
- 状態遷移表のうち「提出済み → 承認済み（承認）」の行
- 権限表のうち「承認者」の行（割当承認者のみ。自己承認は禁止：REQ-003）
- REQ-006（同じ承認を2回しても効果は1回分）、REQ-007（状態変更と履歴追加を片方だけで終わらせない）
表の列：作業・入力・出力・確認方法・依存する作業
条件：
- 各作業の「確認方法」は、上の要件IDのどれに対応するかが分かる形で書いてください。
- 「依存する作業」は、その作業の結果が無いと始められない作業だけを書いてください。
- あわせて、開発中に複数の作業者（人とAI）が同じファイルに同時に手を入れると衝突しやすい箇所を挙げてください。ここでいう衝突は、開発中のコードの衝突のことです。アプリの利用者が同じ依頼を同時に更新する問題は、この表には含めないでください。
してはいけないこと：
- 状態遷移表・権限表にない条件を追加しないでください。
- 作業の粒度を勝手に細かくしすぎないでください（目安は3〜5個）。
返し方：
- 表だけを返してください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
第5.4節の指示に対して、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではなく、教えるために不備を入れた説明用の例です）。問題のある部分を抜き出します。
作業分解表（抜粋）：
| 作業 | 確認方法 | 依存する作業 |
|---|---|---|
| 1. 状態の確認 | 提出済みの依頼で判定が通ることを確認する | 4（重複対策の結果を使うため） |
| 4. 重複対策 | 同じ操作を2回実行しても壊れないことを確認する | 3 |
衝突しやすい箇所（抜粋）：
| 箇所 | 衝突の内容 |
|---|---|
| 承認処理の保存 | 承認者が承認する操作と、依頼者が再提出する操作が同時に届くと、状態が食い違う |
6.2 見つけ方と直し方
見るところは3つです。依存の矢印をたどって元に戻らないか（循環）。確認方法が「動く」ではなく要件に結びついているか。衝突の表の主語が「開発者・AI」か「利用者」か。
| 問題点 | なぜ問題か | どう見つけるか | 誰が判断するか | どう直したか |
|---|---|---|---|---|
| 作業1が作業4に依存し、作業4が作業3に、作業3が作業1に依存している（循環） | どの作業も「先に終わるべき作業」が終わらず、着手できない。完了条件「循環していない」を満たさない | 依存の列を矢印でたどり、出発点に戻る経路が無いかを見る（1→…→1 になったら循環） | 作業を分ける人（架空：開発担当） | 作業1の依存を「なし」に直した。状態の確認は他の作業の結果を必要としない |
| 「壊れないことを確認する」 | 何が壊れることなのかが決まっておらず、確認の合否を判定できない。REQ-006は「履歴が1件のまま」という具体的な期待結果を持つ | 確認方法に「何を見て、どうなっていれば合格か」があるかを問う。要件IDが対応付けられるかを見る | 開発担当と、要件の責任者 | 「同じ操作を2回実行し、履歴が1件のままであることを確認する（REQ-006）」に直した |
| 衝突の表の主語が「承認者」「依頼者」（利用者） | 利用時の競合（データ）を、開発時の衝突（コード）の表に混ぜている（第3.3節）。この表で「対処済み」にすると、アプリの作り（状態条件）で防ぐべき問題が抜け落ちる | 表の各行の「誰が」が開発者・AIか、利用者かを見る。利用者なら別の問題 | 開発担当 | 衝突の表からその行を外し、「利用者どうしの同時更新は作業4の確認対象として09-03で扱う」と書いた。開発時の衝突は、同じファイルに同時に手を入れる箇所として書き直した（第5.3節） |
AIへの修正指示は次のとおりです（説明用の例）。
指摘：
1. 依存関係が循環しています（1→4→3→1）。作業1（状態の確認）は他の作業の結果を必要としないので、依存を「なし」にしてください。
2. 作業4の確認方法を、REQ-006に対応する具体的な期待結果（同じ操作を2回実行し、履歴が1件のまま）で書いてください。
3. 衝突しやすい箇所の表から、利用者どうしの同時更新（承認と再提出の入れ違い）を外してください。この表は、開発中に人とAIが同じファイルに同時に手を入れる衝突だけを扱います。
変えないこと：
- 4つの作業の分け方と、状態遷移表・権限表の条件は変更しないでください。6.3 修正後の作業分解表
修正後の作業分解表と衝突しやすい箇所は、第5.2〜5.3節のとおりです。依存は1→2→3→4の一方向で、衝突の表の主語はすべて開発者・AIです。
6.4 最終判断
修正後の表を採用します。採用したのは「承認処理」の分け方であり、他の作業（依頼の作成、一覧の表示）は別に分解します（第8.2節）。利用時の競合をどう防ぐかは、この記事では決めておらず、05-02の状態遷移表と09-03の確認に委ねます。
7. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 各作業に確認方法がある | 第5.2節の全行に記載 |
| 依存関係が明示され、循環していない | 第5.2節の依存関係は1→2→3→4の一方向 |
| 並行作業時の衝突しやすい箇所が書かれている | 第5.3節に3件記載（いずれも開発時のコードの衝突。利用時の競合は含めず、09-03へ委ねた） |
残る制限：この作業分解は架空の作業例に基づく一例です。実際に複数人・AIが並行して作業した場合の衝突は、この記事の時点では確認していません。利用者どうしの同時更新は、この記事の範囲外です（09-03で状態条件として確認しています）。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではありません。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 作業の粒度を比較する
| 選択肢 | 確認のしやすさ | 手戻りの大きさ | 並行作業の衝突 |
|---|---|---|---|
| 承認処理を1つの作業にする | 低い（どこに問題があるか分かりにくい） | 大きい（修正のたびに全体を見直す） | 同じファイルに全員が触れ、衝突すると影響範囲が大きい |
| 4つの作業に分ける（採用） | 高い（作業ごとに確認できる） | 小さい（問題のある作業だけ見直す） | 衝突する範囲を限定できる |
| 作業をさらに細かく分ける（例：条件式ごと） | 非常に高いが、依存関係の管理が煩雑になる | 非常に小さい | 管理の手間が増える |
4つ程度への分割が、確認のしやすさと管理の手間のバランスとして適切と判断します。
8.2 適用限界
この作業分解は、架空企業「みらい業務サービス」の承認処理という一例です。他の作業（依頼の作成、一覧の表示など）は、それぞれ別に分解する必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 作業分解・依存関係表ひな形（作業、入力、出力、確認方法、依存する作業、同時に触れる範囲） | templates/07-02-task-breakdown_template.md | templates/07-02-task-breakdown_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（開発計画、情報セット）を用意する
- まとまった作業を、確認できる単位に分解する
- 各作業の入力・出力・確認方法・依存関係を書く
- 開発時に衝突しやすい箇所（同じファイル・関数に同時に手を入れる箇所）を書く。利用者どうしの同時更新は、アプリの設計・検証の記事へ分ける
10. 次工程への受渡し
次へ渡すもの：作業分解・依存関係表、開発時に衝突しやすい箇所と同時に触れてよい範囲の基準。
次工程での使われ方：07-03（指示・検証・修正の手順を決める）では、この作業分解を指示の単位にします。08（実装）では、この作業分解を実装の単位にし、08-01が作業1・2、08-02・08-04が作業3に当たります。利用者どうしの同時更新は09-03で確認します。
前工程へ戻る条件：作業分解が03-04の開発計画と食い違う場合は、03-04に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・作業例はすべて架空の設定です。
- 作業分解の内容（状態の確認、権限の判定、状態変更と履歴追加、重複対策）は、05-02の状態遷移表・05-03の権限表に基づきます。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 開発時の衝突（同じファイルへの同時変更）と利用時の競合（同じデータへの同時更新）を分ける整理は、
docs/PHASE1_REVISION_ADDENDUM.md第2節（同時操作の本格的な検証は行わず、保存先の状態条件を独立した小さなテストで確認する）と整合させています。 - 第5.4節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 2026-09-20（Phase 5B-2A）：受入監査で「開発作業の並行衝突（コード）と利用者による同時更新（データ）を混同している」と指摘された。第3.3節で2つを分離し、第5.3節を開発時の衝突（同じファイル・関数への同時変更）に限定し、利用時の競合は05-02・09-03へ委ねる形に改めた。あわせて読む順路、第4節の判断項目、第5.4節「AIに作業分解の下書きを頼む」、第6節の初稿（混同と循環）→レビュー観点の表→修正指示→最終判断、記事間の参照を追加した。旧第7節「よくある勘違い」は第3.2節に統合した。作業分解表・完了条件は変えていない。
- 未確認事項：実際に複数人・AIが並行して作業した場合の衝突は、この記事の時点では確認していません。