案件の工程ごとに、AIに任せた所と任せなかった所

案件が進むほど、AIを使える場面は増えた。 要件整理、提案、制作、進行管理。どこにAIを入れるかを、そのときの気分で決めていた時期がある。

結果、ある工程ではAIの整理に助けられ、別の工程では確認と修正が増えて、トータルの時間は変わらなかった。

この記事では、要件定義から納品までの工程ごとに、AIに任せた所と任せなかった所を整理する。線引きの基準は、これまでの連載で書いてきた「作業はAIに、判断は自分に」だ。

1. 案件の工程は、大きく5つに分けられる

Webデザイン案件は、次の5つの工程で進むことが多い。

• 要件整理：クライアントの要望を聞き、優先順位を決める

• 提案・設計：課題に対する施策と、画面の構成を決める

• 制作：デザインを作り、実装に渡す

• 進行管理：修正依頼・確認・スケジュールを回し、納品まで運ぶ

• 納品：最終確認を行い、資料をそろえて、クライアントに渡す

工程ごとに、AIに向いている作業と、人間が判断すべき作業は違う。

2. 工程ごとの任せ分け表

表で見ると、AIに任せた作業は「整理・下書き・洗い出し」に集中し、
「判断・確認・責任」は人間に残っていることが分かる。

3. 任せて失敗した工程

失敗は、どれも「判断が絡む部分」で起きていた。

• 制作：FigmaのデザインをAIに実装させたところ、フォントサイズと余白に細かいズレが出た。結局、人間の目で1つずつ確認する工程が必要になり、時間は減らなかった

• 要件整理：要望の要約をAIに任せたところ、要望自体は正しくまとまっていた。ただ、行間の本音や優先順位のニュアンスが抜け、後のミーティングで認識のズレが見つかった

• 進行管理：打ち合わせでは合意したように見えても、議事録上の決定事項を関係者全員が同じように理解していたとは限らなかった

• 納品：AIのコードレビューで「問題ありません」と出た後も、実機で表示崩れやスクロールの不具合が見つかることがある。コード上の確認だけでは、実際の環境の問題は拾えない

• 納品：議事録上は対応済みでも、クライアントが納得しているかは分からない。資料を整理するだけでは、認識のズレは防げない

• 納品：AIのデザイン指摘を全部反映すると、あえて付けた余白の強弱や視線の流れまで消えてしまうことがある

共通点は、「正確に再現できるか」ではなく、「文脈と利害が絡むか」で失敗が起きていたことだ。

4. 任せて役に立った工程

一方で、うまくいった工程もはっきりしている。

• 要件整理：複数の修正依頼を優先度別に分類し、対応漏れを洗い出せた

• 提案・設計：自分が当たり前だと思って省略していた説明を、第三者の視点でチェックしてもらい、関係者に伝わりにくい部分に気づけた

• 提案・設計：CTAの配置の根拠を、AIに問い返されて言語化できた

• 納品：納品前に、ページごとの仕様書や要件定義書を読み込ませて、必須コンテンツの反映・表記揺れ・修正指示の反映漏れを洗い出せた。自分だけでは見落としやすい部分を、別の視点から確認できる

• 納品：仕様書や更新マニュアル、デザインの説明資料のたたき台をAIに作ってもらい、内容の整理に集中できた。最後の事務作業が軽くなった

どれも、AIが答えを出したのではなく、自分の整理・根拠・思考の抜けを見つけるための相手として役立った。

5. 線引きの基準：文脈判断が要るかどうか

工程ごとに線を引くときの基準は、1つだけでいい。

「正確に再現できるか」ではなく、「文脈・利害・意思決定が絡むか」で分ける。

• 絡まない作業（整理、たたき台、洗い出し、チェック）→ AIに任せる

• 絡む作業（優先順位、根拠、実現性、認識の確認）→ AIで下書きし、判断は自分が残す

この基準があると、工程が増えても、案件ごとに線引きがブレにくくなる。

6. 今日からできる、1つのワーク

今進めている案件を1つ選んで、工程表を作ってみてほしい。

1. 案件を「要件整理・提案・制作・進行管理」に分け、各工程でAIに使いたい作業を書き出す

2. 書き出した作業に、「文脈・利害・意思決定が絡むか」で印をつける

3. 印がついた作業は、AIの下書きを使い、判断は自分で行う

工程表を1回作ると、次の案件では「どこにAIを入れるか」を迷わなくなる。

7. まとめ：工程が増えても、判断は人間の仕事として残る

AIを使える工程は、案件が進むほど増えていく。だが、どの工程でも、判断・確認・責任は人間の仕事として残る。

連載の1〜8本目で扱ってきた「任せていい仕事」「壁打ち」「合意形成」は、すべて工程の中に位置づけられる。工程表は、その総まとめとして使えるはずだ。