AIはどこまでいってもAI、人間はどこまでいっても人間
AIと仕事をしていると、こちらの意図をよく理解してくれる同僚のように感じることがあります。相談すれば案が返り、実装を頼めばコードができ、問題を指摘すれば修正が進む。任せられることが増えるほど、人間と同じように仕事を引き受けてくれる相手だと期待したくなります。
ただ、ここには一つ、分けて考えておきたいことがあります。人間の仕事を実行できることと、その人間の立場になることは、同じではありません。
AIは顧客への説明文を作れても、その顧客と約束を交わし、結果を受け止める担当者になるわけではありません。人間も、AIが出した大量の案や実装を、同じ速度で読み、判断し続けられるわけではありません。お互いをそのまま置き換えられる存在として扱うと、仕事の進め方に無理が出ます。
この記事では「AIはAI、人間は人間」という考えを、プロジェクトで役割を分けるための出発点にします。AIの意識や将来の可能性を論じるより、いま一緒に仕事を進めるうえで、誰が何を担うのかを具体的に考えます。
人間は、何を実現したいのかと、その結果を引き受ける
プロジェクトには、作業だけでは決まらないことがあります。
納期を守るために機能を減らすのか。使い慣れた画面を残すのか、運用を変えて効率を上げるのか。一部の利用者が困っていても、全体の都合を優先するのか。こうした選択には、誰に何を約束し、どの負担を受け入れるかという判断が含まれます。
AIに選択肢や影響を整理してもらうことはできます。それを材料に、何を優先し、何を今回は見送るかを決め、関係者に説明する役割は、人間の側に置きます。「AIがそう言ったから」では、選択の理由を説明したことにはなりません。
ここでいう人間の役割は、すべてを一人で考えて正解を出すことではありません。現場の担当者に聞き、技術者に確かめ、必要ならAIにも反論を求める。そのうえで、判断を引き受ける人を明らかにするということです。
NISTのAI RMF Playbook「GOVERN 3.2」でも、人間とAIを組み合わせた運用における役割・責任と、AIシステムを監督する人の役割を明確にすることが扱われています。以下は、この観点を踏まえた本記事の分担案です。
AIには、考える材料を増やし、作業を進めてもらう
責任を人間が持つからといって、AIへの依頼を単純作業だけに絞る必要はありません。調査、設計案の比較、実装、テスト、レビューまで、必要な情報と作業環境を渡せる範囲で任せます。
たとえば、ある仕様に対して「実装してください」と頼むだけでなく、「この仕様が困る利用者は誰か」「既存機能と矛盾しないか」「もっと小さい変更で目的を満たせないか」と検討してもらう。人間が見落としていた論点を探す役割も、AIへ渡せます。
分担の境界は、考えるか、手を動かすかだけでは決まりません。AIにも判断を伴う作業を任せつつ、任せてよい判断の範囲と、人間へ戻す条件を決めることが必要です。
表は横にスクロールできます
| 場面 | 人間が担うこと | AIへ任せること |
|---|---|---|
| 目的・要件 | 誰の何を改善するか、優先順位と完了条件を決める | 聞くべきこと、要件の抜け、矛盾を洗い出す |
| 設計 | 費用・納期・運用負担のどれを優先するか決める | 複数案と影響範囲を調べ、推奨案と理由を示す |
| 実装 | 変更範囲と任せる権限を決め、仕様変更を判断する | 合意した範囲を実装し、既存機能との整合を確認する |
| 検証 | 期待する結果を定め、業務で使えるか確かめる | テストを作成・実行し、結果と未確認事項を報告する |
| 公開・運用 | 公開の可否、顧客への約束、問題発生時の対応方針を決める | 公開手順や復旧手順を準備し、記録の整理と原因調査を支援する |
工程ごとの成果物は、システム開発の工程と成果物でも整理しています。AIが作った成果物にも、同じように確認する人と完了条件を置きます。
人間にも、AIと同じ働き方を求めない
AIとの役割分担では、「AIに何ができるか」だけでなく、「人間がどこまで受け取れるか」も考える必要があります。
短時間に設計案が十個届いても、選ぶ人が比較できなければ先へ進みません。大量のコードができても、意図を確認できなければ安心して公開できません。作る速度だけを上げると、判断待ちやレビュー待ちが積み上がります。
だから、AIへの依頼には、成果物の量と渡し方も含めます。案は有力な二、三個に絞り、推奨案と理由を添える。変更は人が確認できる単位に分ける。報告には変更点、検証結果、未確認事項を揃える。人間が判断できる形で届くところまでを、AIに任せる仕事に含めます。
人間の側も、すべてを記憶し、常に正しく判断できる存在ではありません。決めたことは記録し、繰り返し確認することはテストやチェックリストに移す。疲れているときに大量の承認が必要になるような進め方を避ける。人間がAIになる必要がないように、作業の仕組みを整えます。
例：予約変更機能を作るなら、どう分担するか
ここからは、予約管理システムに「利用者が自分で予約日時を変更できる機能」を追加する仮の例で考えます。
1. 人間が、現場の困りごとと守りたい条件を揃える
最初の依頼が「予約変更を自動化したい」だけでは、何を作ればよいか決まりません。担当者が現場に確認し、「電話対応を減らしたい」「直前の変更はスタッフの調整が必要」「利用者に変更完了が伝わらないと困る」といった事情を集めます。
AIには、ヒアリング項目や想定される例外を先に出してもらえます。その案をもとに実際の担当者へ確認し、たとえば「前日まで本人が変更できる」「当日は電話で受け付ける」「変更後に通知を送る」という条件を、人間が合意します。
2. AIが調査し、人間が未確定の仕様を決める
AIには、既存の予約処理、空き枠の扱い、通知機能、影響する画面を調べてもらいます。実装案には、変更箇所だけでなく、確認できた事実と未確定事項を分けて示してもらいます。
調査中に「前日までとは何時が締め切りか」「変更先の枠を別の利用者が同時に予約した場合はどうするか」が見つかったら、仕様として決めます。AIの推奨を参考にしても、現場の約束に関わる条件を、気づかないうちに実装上の都合で決めないようにします。
3. AIが実装・検証し、人間が業務として確認する
条件が揃ったら、AIには実装とテストをまとめて進めてもらいます。人間が毎行指示するのではなく、合意した変更範囲の中で、必要なファイルの修正や検証を任せます。
完了報告では、変更できる場合に加えて、締め切り後、空き枠が埋まった場合、通知に失敗した場合をどう確認したかを示してもらいます。実行していない確認は、未確認として残します。
人間はその証拠を見たうえで、利用者として操作し、スタッフが現場で対応できるかを確かめます。実装内容に詳しい人が技術面を、業務に詳しい人が運用面を確認するなど、責任に見合う知識を持つ人へ分担します。
4. 公開の判断と、公開後の窓口を人間が持つ
最後に、誰が公開を判断し、問い合わせを受け、問題があれば機能を止めるかを決めます。AIには公開手順や確認項目、元に戻す手順を準備してもらいます。
実行まで任せる場合も、対象と権限を明示します。開発環境で動いたことと、本番で利用者に使ってもらってよいことは、別の確認です。
任せる前に、五つのことを共有する
日々の依頼では、長い指示書を毎回用意するより、まず次の五つを揃えると分担が具体的になります。
- 目的：誰の、どの困りごとを解決したいか。
- 前提：確定した仕様、参照する資料、守るべき制約は何か。
- 権限：どこまで変更・実行してよいか。
- 完了条件：何ができ、どの確認に通ればよいか。
- 相談する条件：どんな不明点や変更が出たら、人間の判断へ戻すか。
予約変更機能なら、「締め切り条件を変える必要がある」「既存予約のデータを書き換える必要がある」「合意した仕様同士が矛盾する」ときは相談し、合意した範囲の実装やテストは進めてもらう、と決められます。
これなら、作業のたびに人間へ確認して進行が止まることも、意図しない変更まで進むことも減らせます。権限や停止条件を運用へ落とし込む際は、AIエージェント導入時の境界の決め方も参考になります。
「最後に人間が見る」を、形だけにしない
人間が最後に承認すればよい、と決めるだけでは役割分担は完成しません。判断する時間も知識もなく、AIの報告にうなずくだけなら、その承認は働いていません。
AIには根拠やテスト結果を示してもらい、人間には確認できる時間と、必要なら差し戻せる権限を用意します。同じAIに「問題ないか」と聞き直すだけで終わらせず、仕様、実行結果、実際の業務と照らして確かめます。詳しい人がいなければ、任せる範囲を狭めるか、確認できる人を加えます。
AIの提案を採用しないことも、人間の最初の考えをAIとの検討で変えることもあってよいはずです。人間が責任を持つことは、人間の直感を無条件に正解にすることではありません。
AIはどこまでいってもAIで、人間はどこまでいっても人間。その前提に立つなら、互いに同じ存在になることを求めず、それぞれが担う仕事を明確にできます。AIには任せられる作業を十分に任せ、人間は目的を確かめ、関係者と合意し、結果を引き受ける。その分担を、プロジェクトの進め方として勧めます。
参考資料の確認日：2026年9月18日。役割分担表と予約変更機能の例は、本記事で提案する進め方です。