AI開発のプロジェクト管理請求書の下書きまで
追う3層構成

AI開発のプロジェクト管理では、仕様、品質、変更、検収、請求を同じ案件単位で追う必要があります。

ここでいうAI開発は、AIを使って受託ソフトウェアを作る仕事です。

AIシステムそのものの開発管理は扱いません。

実装が短くなっても、人の判断や確認が自動で終わるわけではありません。

この記事では、読者が手元の完了済み案件を1件選び、30日で仕様、チケット、見積、検収、請求書の下書きを照合する方法を示します。

新規案件が30日で検収を終えるという約束ではありません。

手作業が残る箇所と、AIへ許可してはいけない更新操作を見つけるための試行です。

この記事で分かること

• AIには記録と照合を任せ、金額・納期・優先順位の確定は人が持ちます
• 案件ID、見積項目、タスク、追加要望、請求状態の5つを同じ案件へ結べる状態にします
• エージェントが作る進捗報告は社内向けの下書きにし、対外連絡は担当者が確定します

AIを使う開発で
管理が難しくなる3つの理由

理由は3つあります。

1. 工数見積の前提が変わる。 実装だけが短くなり、レビュー、テスト、検収が同じ比率では短くならないと、人月ベースの見積とWBSが実態からずれる
2. タスクが細かくなる。 AIエージェントへ渡せる単位まで作業を分解すると、チケット作成と完了確認の負担が増えやすい。手動で書く工程が新しい待ち時間になる
3. 並行案件が増える。 1人が同時に持てる案件数が増えるので、個人の頭の中の管理が先に限界を迎える。開発が速くなったのに、請求漏れや検収の抜けでお金の回収が遅れる、という逆転現象が起きる

実装が速くなるほど、確認待ちや請求待ちも見落とせません。

AIを使う開発では、タスクとともに案件ごとの見積・検収・請求を追います。

実務で機能する
3層の管理フロー

案件の記録を次の3層に分けると、どこで判断が止まっているか確認できます。

第1層: 仕様と分解（ドキュメント層） 要件をAIに読める形で文書化します。

ポイントは「人間向けの提案書」と別に「エージェント向けの仕様（受け入れ条件付き）」を作ること。

ここが曖昧なままエージェントに投げると、速く間違ったものができあがります。

第2層: チケット駆動の実装（タスク層） 分解したタスクをチケット化し、Claude CodeなどのエージェントにMCP経由でチケットを読ませて実装させます。

進捗の記録もエージェント自身に書かせるのがコツで、人間は「完了報告を読んで検収する」側に回ります。

第3層: 案件と収支（案件層） クライアント・見積・納期・請求を案件単位で束ね、進行と金額を照合します。

表計算でも始められますが、案件IDと見積項目をタスク・請求書へ結べる必要があります。

TASKULの公式サイトには案件・クライアント・見積書・請求書の管理機能が掲載されています。

筆者はTASKULの運営に携わっています。

工程・品質・変更・リスクは
どこで管理する？

3層はツールの置き場所であり、管理項目を減らす考え方ではありません。

各項目の責任者と完了条件を次のように分けます。

AIは期限切れや条件不足の候補を抽出できますが、優先順位、公開、追加費用の確定は人が行います。

自動化するのは記録と照合であり、責任そのものではありません。

受注から請求書の
下書きまでの流れ

読者は自社で完了済みの案件を1件選び、記録を追試します。

以下はWeb制作案件を仮定した手順例で、実在顧客の結果ではありません。

1. 受注: 依頼内容から見積を作り、範囲・金額・支払条件への顧客合意を残して案件を起こす。過去案件の見積項目と実績を参照できれば、ゼロから作る手間を減らせる
2. 仕様化: 提案書とは別に、受け入れ条件付きの仕様ドキュメントを残す。エージェントに曖昧な箇所を指摘させ、人が着手前に条件を確定する
3. チケット起こし: 仕様からのタスク分解をエージェントにやらせ、人間は粒度と受け入れ条件だけ直す。見積書の項目とチケットを対応させておくのがこの後の請求のための布石
4. 実装: エージェントがチケットを読んで実装し、進捗と完了報告を記録する。人が社内レビューとマージを判断し、顧客検収の結果は別に残す
5. 追加要望: 依頼をチケット化し、見積外の可能性を記録する。人が範囲・費用・納期を確認し、顧客の合意を得る
6. 請求: 当初見積、追加変更への合意、顧客検収、契約上の請求条件を照合し、請求書の下書きを作る。金額の確定、発行、送信は人が行う

受注・追加要望・請求に当たる1・5・6は、完了した作業を売上へつなげる接点です。

実装だけでなく、この3つの待ち時間も案件ごとに確認します。

タスク管理だけでは
案件収支が分からない

実装時間が短くなって並行案件を増やす場合、必要になるのは案件をまたぐ管理です。

• 案件Aの検収待ちの間に案件Bの見積を出し、案件Cの追加要望を請求に反映する
• パートナー（外部エンジニア・デザイナー）を案件ごとに入れ替える
• 月末に全案件の請求書をまとめて発行する

タスク管理だけで、見積項目から請求書の下書きまで追えるかはツールと設定次第です。

JiraやBacklogを使い続ける場合も、見積・請求の記録を別に用意して案件IDで結ぶ方法があります。

必要な機能を先に洗い出してから、連携か追加ツールかを選びます。

TASKULの公式サイトでは、案件情報からの見積書作成、見積金額を反映した請求書作成、パートナーへのタスク共有を案内しています。

MCP連携は一般向けの提供条件を公式サイトで確認できないため、導入条件として数えず、利用可否を個別に確認してください。

今のタスク管理ツールを
MCPで接続できるか

次の表は、2026年9月22日時点で公式MCPの提供有無だけを確認したものです。

見積・請求機能、料金、認証方式、書き込み範囲を比較した表ではありません。

採用判断では各社の公式ドキュメントで、認証と利用できる操作を必ず確認してください。

公式MCPがあっても、接続方法と許可される操作は異なります。

Notion公式は認可した利用者がアクセスできる内容の読み取りと更新を案内し、Asana公式はOAuth対応クライアントを必要とします。

製品ごとに接続アカウント、対象データ、更新操作を確認してください。

接続後に完了とみなす3つの条件

1. 検証用の環境または低権限アカウントで認証し、利用できる操作の一覧を確認できる
2. 検証用案件のチケットを1件だけ読み、案件IDと受け入れ条件を正しく取得できる
3. 更新・削除・送信などの操作に対し、利用するAIクライアント側の制限や実行承認を確認できる

この3点が揃うまでは、本番案件の更新をエージェントへ任せません。

MCP対応の有無だけでは、料金、案件収支、権限管理の適否は判断できないためです。

導入は何から始めれば
いいか（30日の目安）

完了済みの案件を1件選び、記録を再現するなら検収日を待たずに試せます。

30日は作業順を示す目安であり、実運用の完了期限ではありません。

• 第1週: 完了済み案件の仕様、合意済み見積、チケット、顧客検収、請求の記録を集める。個人情報を除いた複製を検証用環境へ置き、接続操作と権限を確認する
• 第2週: 仕様からチケット候補を作り、元のチケット・受け入れ条件と照合する。差分を人が記録する
• 第3〜4週: 完了チケット、顧客検収の記録、追加要望への合意、見積項目を照合し、請求書ドラフトを元の請求書と比べる。差額と根拠を残し、本番更新や請求書の発行・送信はしない

AIが作ったチケット候補の抜け、請求書ドラフトの差額、担当者が確認した時間を残せば、どの作業を任せられるか判断できます。

結果が合わなければ本番へつながず、元の記録と指示を直します。

AI駆動開発の管理で
起きやすい5つの失敗

• 作業の分解に時間がかかるのに、方法を見直さない。 AIによるチケットの下書きも選択肢です。人が書いたほうが早い仕事まで自動化せず、仕様の抜け、担当、完了条件を確認できる方法を選びます。
• 検収の基準を後から決める。 実装が速いため、基準がないと「できたものを見てから考える」が多発して手戻りが増える。チケットに受け入れ条件を書いてから着手する
• 収支を月末にまとめて計算する。 案件数が増えた状態で月末精算をすると、追加対応分の請求漏れが起きやすい。案件単位でリアルタイムに見える場所を作る
• ツールを一気に替える。 現行ツールと見積・請求記録を案件IDで結べるか試し、不足分だけ補う
• エージェントの成果を検収せずに積む。 「動いた」と「受け入れ条件を満たした」は別物。検収を飛ばすと、速く作った分だけ速く技術的負債が積み上がる

人とAIの責任分界は
どう決める？

AIには記録と照合を任せ、金額・納期・優先順位の確定は人が持ちます。

境界を決めないまま自動化すると、誰が決めた数字なのか追えなくなります。

見積と請求では、下書きと対外的な確定を別の操作にします。

この分け方なら、エージェントが間違えても下書きの段階で止められます。

誰が承認したか、どのチケットを根拠にしたかを記録へ残せるため、後から説明するときにも困りません。

管理が追いついているか
何を測ればいい？

実装時間だけを測ると、AI駆動開発の管理負荷を見落とします。

案件単位で、仕様確定から請求までの待ち時間と手戻りを追います。

最初から細かなKPIを増やさず、次の5項目を毎週確認してください。

週次で見る数値は、完了チケット数、レビュー待ち時間、手戻り件数、見積外タスク数、請求未反映件数です。

数字の大小を他社と比べる必要はありません。

前週よりレビュー待ちが伸びた理由を特定し、仕様・チケット・案件のどの層で止まっているかを直します。

複数案件を同時に
回すための週次運用

週次確認ではタスク数ではなく、案件を止めている理由と請求の状態を並べます。

実装が速くなっても、検収や顧客との調整に時間がかかれば、担当できる案件数が増えるとは限りません。

案件ごとの進捗だけを見ていると、検収待ち、クライアント回答待ち、請求待ちが別々の場所に散らばり、着手できる案件と止まっている案件を取り違えます。

月曜日に案件の状態をそろえる

工程は「仕様確認中」「実装中」「検収中」「完了」から選びます。

回答待ちなどの停止理由と、請求の状態は別欄にします。

検収中でもクライアントの回答を待つことがあり、請求済みでも入金待ちの場合があるためです。

エージェントには、更新が止まっている案件と、期限が近いのに受け入れ条件がないチケットを一覧にさせます。

状態の更新には根拠を残す

工程を「検収中」へ動かすときは、対象チケットと確認結果を一緒に残します。

請求状態を「ドラフト」へ動かすなら、納品日と合意済みの追加対応を記録します。

状態だけを変える運用では、月末に根拠を探し直すことになります。

金曜日に見積外と
請求待ちを確認する

週末には、その週に増えた見積外タスクと、検収済みなのに請求へ進んでいない案件を確認します。

エージェントが候補を集め、人が追加費用と請求時期を判断します。

毎週確認すれば、月末に根拠を探し直す負担を減らせます。

ただし、後から変わった合意や記録漏れは、請求を確定する前に確認します。

案件を止めている理由とお金の状態を同じ一覧にすると、次に動かすべき仕事が見えます。

開発者の稼働率だけを上げるのではなく、検収と請求まで完了した案件を増やすのが週次運用の目的です。

ツールを増やす前に
そろえるデータ

案件ID、見積項目、タスク、追加要望、請求状態の5つを同じ案件へ結べる状態にします。

データが表計算、チャット、タスク管理に分かれていても構いません。

新しいツールを契約する前に、5つの情報がどこにあり、誰が更新しているかを確認します。

案件IDを共通の軸にする

見積書とタスク管理で案件名の表記が違うと、エージェントは安全に突合できません。

案件IDを一つ決め、見積、仕様書、チケット、請求書のすべてへ入れます。

顧客名だけで結ぶと、同じ顧客から複数案件を受けたときに混ざります。

追加要望を通常タスクと分ける

追加要望は、依頼日、依頼内容、見積内か見積外か、回答状況を持たせます。

依頼を受けた時点では金額を確定せず、見積外の候補として記録します。

確定前の金額を請求データへ書き込まないことで、エージェントの誤判断が対外文書へ出るのを防げます。

請求状態を段階で持つ

請求状態は「未確認」「ドラフト」「承認済み」「発行済み」「入金済み」に分けます。

ドラフトと発行済みを同じ「請求済み」にすると、人の承認を飛ばしても判別できません。

状態ごとに誰が進められるかを決め、発行と送信は人だけが行える権限にします。

社内報告と
クライアント連絡を分ける

エージェントが作る進捗報告は社内向けの下書きにし、対外連絡は担当者が確定します。

チケットの変更履歴から自動生成した文章には、未確定の納期や担当者の推測が混ざる可能性があります。

社内では詳細なブロッカーを共有し、クライアントには決定済みの進捗、次の確認事項、回答期限だけを伝えます。

連絡文を作るときは、完了した項目、確認中の項目、クライアントへ確認したい項目、次回連絡日を分けます。

エージェントが参照したチケット番号も下書きに残しておけば、人が内容を確かめやすくなります。

未確定の数字を
対外文書へ出さない

追加費用、納期、公開日は、担当者が承認するまで「候補」です。

自動生成した報告で確定した表現へ変えないよう、金額や日付を含む文面は送信前に必ず人が確認します。

利用するツールで権限を分けられるなら、AIには下書き作成だけを許可します。

分けられない場合は、送信機能を接続せず、承認後に人が送ります。

チケットに最低限何を
書けばいい？

AIエージェントが読むチケットには、背景説明を長く書くより、作業範囲と受け入れ条件を分けて書きます。

以下の型なら、人が読んでもエージェントが読んでも、完了判定がぶれにくくなります。

目的:
問い合わせフォームの入力内容を管理画面で確認できるようにする

作業範囲:
- 入力値の保存
- 管理画面の一覧表示
- 送信失敗時の記録

受け入れ条件:
- 必須項目が空なら送信されない
- 正常送信した内容が管理画面に1件表示される
- 同じ送信を再実行しても二重登録されない

対象外:
- 自動返信メールの文面変更
- 顧客への自動送信

「動くこと」ではなく、正常時・失敗時・再実行時の条件まで書くのが要点です。

チケットを作ったエージェントとは別に、実装前のチェック役を置くと、仕様の抜けをコードを書く前に止められます。

AI開発の管理では、実装が速くなった後に残る「決める・確かめる・請求する」を記録へつなげる必要があります。

まず完了済み案件の記録を1件選び、検証用環境でチケットと請求書ドラフトを照合してください。

案件の収支が見えていない場合は、案件管理ツールTASKULの料金ページで無料プランの条件を確認できます。

本記事の執筆者はTASKULの運営に携わっています。他社ツールの機能・MCP対応状況は2026年9月22日時点の各社公式サイトの記載に基づいています。