AIが「作る」時代に、人は何を設計するのか
「AIがコードを書くようになったら、人間は何をするのでしょうか」
生成AIの話をしていると、よく出てくる問いです。
少し前なら、
AIが作り、人間が考える。
と分けることもできたかもしれません。
ただ、いまのAIは、コードを書くところだけにとどまりません。
要件を整理し、設計案を出し、テストケースを作る。レビューやデータ分析を行い、複数の選択肢を比較する。
AIエージェントでは、与えられた目的からタスクを分解し、次に何をするかを選び、ツールを使って処理を進めるところまで対象が広がっています。
IPAも、AIを用いたソフトウェア開発の活用場面として、要件定義、コード生成、レビュー、テスト、テストデータ作成などを挙げています。
つまり、AIを「コードを書く機械」とだけ考えるのは、すでに狭くなっています。
では、人間には「考える仕事」が残るのでしょうか。
これも、少し違う気がします。
AI自身が分析し、評価し、次の行動まで選ぶようになるなら、「考えるのは人、作るのはAI」という境界も固定できません。
むしろ、人間が考えるべきなのは、
AIを、どのような条件で仕事へ参加させるのか。
なのではないでしょうか。
何を目的にするのか。何を知った状態で仕事をさせるのか。何をしてはいけないのか。
何を良い結果とし、どこまで自分で進めてよいのか。どの条件で人へ戻し、間違えたときには、どう止めて戻すのか。
AIによって成果物を作る時間が短くなるほど、人が設計する対象は、成果物そのものから、成果が生まれる仕組みへ広がっていくのかもしれません。
たくさん作れることと、良いものを作れることは違う
分かりやすく、少し極端な例を考えてみます。
これまで、人が1日に10個の成果物を作っていたとします。
10個生成
↓
10個確認
↓
採用
ここへAIを入れたことで、1日に100個作れるようになったとします。
100個生成
↓
100個を人が確認？
↓
評価がボトルネック
もちろん、10個と100個は思考実験です。
ただ、生成工程だけを高速化すると、別の場所に待ち時間が移るという問題は現実に起こり得ます。
IPAのソフトウェアモダナイゼーションに関する報告でも、AIによって個々の工程が高速化する一方、工程間の調整や人による意思決定が全体のボトルネックになり得るという方向が論じられています。
生成速度を上げた次に問題になるのは、何を採用するかを決める速度です。
だからといって、「では人間が全部レビューしましょう」では解決しません。
AIで生成量を10倍にして、人間のレビュー量も10倍になったなら、ボトルネックを生成工程からレビュー工程へ移しただけです。
必要なのは、生成量を増やす設計だけではありません。
評価量を減らす設計です。
AIへ答えを求める前に、「何を良い結果とするか」を決める
たとえば、社内の問い合わせ対応へ生成AIを導入するとします。
目的を、
問い合わせをAI化する。
とだけ置いたら、何をもって成功とするのでしょうか。
回答時間を短くしたいのか。担当者への問い合わせ件数を減らしたいのか。夜間にも回答できるようにしたいのか。
回答品質のばらつきを抑えたい、担当者の負荷を減らしたいという目的も考えられます。
目的によって、必要なシステムは変わります。
さらに、一つの指標だけを良くすればよいとは限りません。
たとえば、人へのエスカレーション率を下げることだけを目標にすると、本来は人へ確認すべき質問までAIが無理に回答するかもしれません。
回答速度だけを追えば、根拠確認が弱くなる可能性があります。反対に、正確性を求めすぎてほとんどの質問を人へ戻せば、AIを導入した意味が薄くなります。
つまり、何を最大化するかだけでなく、何を犠牲にしてはいけないのかまで決める必要があります。
NISTのAI Risk Management Frameworkと生成AI向けプロファイルでも、AIシステムの目的や利用状況、想定される影響、リスクを把握し、それに応じて管理する考え方が示されています。
AIを導入すること自体ではなく、どの目的と条件の下で使うのかが出発点になります。
AIに何をさせるかより前に、なぜAIを使うのかを設計する。
そして、AIへ答えを求める前に、どんな答えなら採用するのかを決めておく。
ここから、AIシステムの設計は始まります。
AIに「何を知った状態で」仕事をさせるか
同じAIモデルを使っていても、与えられている情報が違えば、結果は変わります。
一般的な質問へ答えるだけなら、モデルが持っている知識だけで対応できることもあります。
ところが、企業の業務ではそうはいきません。
社内独自の業務ルールやシステム仕様、顧客固有の用語、過去の問い合わせ、FAQ、社内規定、既存コード、これまでの変更経緯。
AIは、それらを最初から知っているわけではありません。
たとえば、
このエラーには、どう対応すればよいですか。
と聞いても、その会社で過去にどのような対応をしたのか、どのシステムと連携しているのか、担当者がどこまで操作してよいのかを知らなければ、一般論しか返せません。
そこで必要になるのが、AIへどの情報を渡すかという設計です。
RAGを使って社内文書を参照させる。Knowledge Graphによって情報同士の関係を持たせる。必要なデータだけを検索できるようにし、コードベースを参照させる。
重要なのは、技術名ではありません。
AIモデルだけでなく、そのAIが何を知った状態で仕事をするのかも設計対象になる。
ということです。
ディーシステムでも、Knowledge GraphとLLMを組み合わせた文献探索や、ETL、LLMの回答精度改善などに取り組んできました。
そこでも、モデルを呼び出せば終わりではありません。
何を情報として与え、どのような回答を期待するのか。出てきた回答をどう確認し、その結果を見ながら何を改善するのか。
生成AIの性能だけではなく、その周囲にある情報環境まで含めて設計する必要があります。
AIにできることと、やらせてよいことは違う
情報を与えれば、AIにできることは増えていきます。
ただし、できることと、やってよいことは別です。
たとえば、AIエージェントへ社内システムの操作権限を与えるとします。
提案だけさせるのか。下書きまで作らせるのか。テスト環境なら実行させるのか。一定の条件では、本番でも処理させるのか。
他システムへのデータ書き込みや、顧客への自動回答まで許可するのかによって、リスクは大きく変わります。
特に本番環境では、個人情報や機密情報、法令、業界規制、セキュリティ、社内規定、既存システムとの責任分界まで考えなければなりません。
AIの能力が上がれば、制約設計の重要性は下がるのでしょうか。
むしろ逆かもしれません。
できることが増えるほど、何をさせないかを決める必要も増えます。
AI時代の役割分担は、「これは人の仕事、これはAIの仕事」と固定的に線を引くことではありません。
どの判断と行動までAIへ渡すのかを決めることです。
Human-in-the-loopは「全部人が見る」ことではない
AIへ一定の権限を渡すと、
最後は人が確認すれば安全なのでは。
という考えも出てきます。
もちろん、人の判断を組み込むことが重要な場面はあります。
Google Cloudも、生成AIを使った自動化ワークフローでは、重要な意思決定段階に人間を含めるべきかを検討するよう案内しています。
ただし、
すべてAIが処理したあと、全部人が見る。
だけがHuman-in-the-loopではありません。
たとえば、
AIが処理
↓
自動評価
↓
条件を満たす
→ 自動処理
条件を外れる
→ 人へエスカレーション
という設計もできます。
一定金額以上の処理だけ人へ戻す。規制対象のデータだけ人が見る。評価スコアが閾値を下回った回答だけ確認する。
例外処理だけ担当者へ送り、本番変更だけ承認を求めることもできます。
この場合、人間は全件を確認する人ではありません。
人が見るべき場所そのものを設計しています。
AI時代のHuman-in-the-loopとは、人を何となくループへ残すことではなく、人が必要になる条件を設計することと考えた方が、実務には近いでしょう。
評価すること自体も、AIへ任せられる
さらに進めると、
AIが作り、人間が評価する。
という役割分担も固定ではありません。
テストや静的解析は自動化できます。ルールに合っているかを機械的に判定し、AIに評価観点を作らせたり、別のAIに生成結果を一次評価させたりすることもできます。
Microsoft Foundryでも、生成AIアプリケーションやAIエージェントに対して、組み込みまたは独自のEvaluatorを使った評価、継続評価、品質・安全性の監視といった仕組みが提供されています。
すると、流れは次のようになるかもしれません。
AIが生成
↓
自動テスト
↓
ルール判定
↓
AIによる一次評価
↓
リスクや例外を検出
↓
必要なものだけ人が確認
ここでも、人間の仕事がなくなるわけではありません。
見る対象が変わります。
どのテストを通し、どの評価指標を使うのか。AI評価をどこまで信用し、どの閾値で止めるのか。
サンプリングで何を確認し、異常が出たら誰へ知らせるのかを考えます。
つまり、評価する人になるのではなく、評価の仕組みを設計する人になる。
という役割も出てきます。
もちろん、評価システム自身が間違う可能性もあります。
だから、その評価方法が妥当なのかを継続的に見る必要があります。
生成AIを導入したことで、人の評価が不要になるのではありません。
評価の階層が一段増えるのです。
本番では「AIが間違えたとき」まで設計する
ここまでは、AIが期待どおりに動く場合を中心に考えてきました。
でも、本番システムでは、それだけでは足りません。
誤った回答をする。外部AIサービスが停止する。モデルの更新で挙動が変わる。参照データが古くなる。想定していなかった入力が来る。
他システムへの処理に失敗することもあります。
AIも、AIを取り巻くシステムも、正常に動き続けるとは限りません。
そのため、ログや監視、通知、エスカレーション、手動処理への切り替え、AI機能の停止、ロールバック、問い合わせ窓口、インシデント対応といった仕組みも必要になります。
NISTの生成AI向けリスク管理プロファイルでも、AIシステムを継続的に監視・評価し、インシデントや変更へ対応することがリスク管理の一部として扱われています。
これは、従来のシステム運用と切り離された話ではありません。
本番環境で設定を変更するなら、変更前の状態を確認し、証跡を残す。変更後の状態を見て、問題が起きたときには元へ戻せるようにする。
障害が起きれば、ログから何が起きたのかを確認します。
AIが設定変更案を生成できるようになっても、
本当にこの環境で実行してよいか。
問題が起きたら戻せるか。
誰が何をしたのか追跡できるか。
という運用上の問いは残ります。
AI導入とは、AIが正しい答えを出せる仕組みを作ることだけではありません。AIが間違えても、業務が壊れない仕組みを作ることでもあります。
生成可能と、業務利用可能は違う
生成AIを使うと、コードや文章、画像、設計案、分析結果、テストケースなどを、驚くほど早く作れることがあります。
ですが、AIが作れることと、その成果物を業務で使ってよいことは別の問題です。
コードなら、動くだけでは足りません。
要件を満たしているか。セキュリティ上の問題はないか。保守できるか。既存環境と共存できるか。障害時に対応できるか。
文章であれば、事実や根拠、社内規定との整合性、公開可否、読み手へ誤解を与えないかを確認します。
これは、AIの現在の品質が低いから必要なのではありません。
AIの性能がさらに高くなったとしても、企業が何を業務利用可能と判断するかには、自社の目的と制約が関係するからです。
「良い成果物」は、モデル単体では決まりません。
その企業が何を良いと考えるのかによって決まります。
人が設計するものを整理すると
ここまで扱ってきたものは、大きく四つにまとめられます。
1．何を目指すか
何を達成し、何を最適化するのか。
反対に、何を犠牲にしてはいけないのかを決めます。
2．どんな条件でAIを動かすか
どの情報を与え、どのシステムやデータへアクセスさせるのか。
何を禁止し、どの法令、規定、セキュリティ条件を守るのかを決めます。
3．何を任せ、どう評価するか
AIは提案だけするのか、実行まで行うのか。
何を良い結果とし、何を自動評価するのか。どの条件で人へ戻し、AIによる評価をどう監視するのかを設計します。
4．失敗したらどうするか
何を監視し、どの状態で止めるのか。
誰へ通知し、手動へどう切り替え、どう戻すのか。問題が起きたあとに何を記録し、どう改善するのかまで考えます。
こうして見ると、AI時代に人が設計するものは、プロンプトだけではありません。
目的、情報環境、制約、評価、権限、介入条件、監視、回復まで含む業務の仕組みです。
ディーシステムのAI案件でも、「生成」で仕事は終わらない
ディーシステムでは、生成AIアプリ、Copilot、社内GPT、製薬領域の生成AI文書アプリなど、AI・データ領域の案件に取り組んでいます。
確認されているAI・データ案件17件のうち、9件は製薬・医療系です。
ただ、実際の支援で行っているのは、AIモデルへプロンプトを渡すことだけではありません。
要件を整理し、設計する。必要な情報を準備してAIを組み込み、回答精度を改善する。
テストやセキュリティ確認を行い、本番へリリースする。利用開始後には運用し、レビューし、ドキュメントも整えます。
モデルが何かを生成するところは、工程の一部です。
特に、Knowledge GraphとLLMを組み合わせた取り組みでは、「どのモデルを使うか」だけではなく、AIへどの情報を渡し、どう回答へつなげるかが仕事になります。
製薬・医療のように、根拠や正確性、品質、セキュリティが重要になる領域では、「AIが答えたから使う」とはいきません。
何を業務利用できる状態と考えるのか。そのために、どのような情報、評価、レビュー、運用が必要なのか。
実務で見ると、AIを導入する仕事は「生成する機能を作ること」より、もう少し広いところにあります。
AI時代、人間は「作らない人」になるわけではない
ここまで読むと、
これから人間はコードを書かず、AIを管理するだけになるのか。
と思われるかもしれません。
そういう話ではありません。
人もコードを書きます。資料も作ります。設計も分析もします。AIと一緒に成果物を作る場面も増えるでしょう。
変わる可能性があるのは、人が作る対象の範囲です。
これまでは、コード、設計書、テスト、資料といった成果物そのものを作ることが中心でした。
そこへ、AIに与えるコンテキスト、評価用データ、自動テスト、Evaluator、ガードレール、AIエージェントの権限、エスカレーション条件、ワークフロー、監視、復旧手順といったものも加わります。
これらも、人が作るものです。
「作る仕事」がなくなるのではありません。人が作る対象が、成果物から、成果が生まれる仕組みへ広がっていきます。
そして、ここにはもう一つ課題があります。
AIがコードの初稿を書き、テストを作り、調査を支援するようになったとき、そのAIの成果物を評価できる人は、どこで経験を積むのでしょうか。
コードを評価するにはコードを理解する必要があります。本番での判断には運用経験が必要で、業務要件を判断するには業務を知る必要があります。
これは、AI時代の人材育成として、別に考えなければならない問題です。
人が設計するのは、AIが成果を出せる環境
AIは、これからさらに多くのものを作れるようになるでしょう。
分析や評価、判断、実行まで、AIへ任せられる範囲も広がっていく可能性があります。
だから、「AIが作り、人が考える」という分け方だけでは足りません。
「AIが作り、人が全部確認する」という形でも、生成量が増えれば限界が来ます。
必要なのは、何を目的とし、何をAIへ知らせ、何を許さないのかを決めることです。
何を良い結果とし、何を自動で評価するのか。どこまでAIへ権限を渡し、どの条件で人へ戻すのか。
そして、間違えたときに、どう止め、どう戻すのか。
AIが成果物を作る時間を短くするほど、人間は、一つひとつの成果物を作ることだけに時間を使わなくてもよくなるかもしれません。
その代わり、人が作るものは増えます。
コンテキストを作る。評価の仕組みを作る。ガードレールを作る。AIと人のワークフローを作る。権限を設計し、監視と回復の仕組みを作る。
成果物だけではなく、成果が生まれる環境そのものを作る。
AI時代に人が設計するのは、「良い成果が生まれ、悪い成果を止められる環境」なのかもしれません。
では、その設計や評価ができる人は、どこで経験を積んで育つのでしょうか。
次の記事では、AIが初級の実装やテストを担うようになったときの、人材育成について考えます。
次に読む記事
AIで「下積み」がなくなったとき、若手はどう育つのか
参考資料
IPA｜AIを用いたソフトウェア開発
https://www.ipa.go.jp/digital/ai/software-engineering.html
IPA｜2025年度 ソフトウェアモダナイゼーション委員会報告書
NIST｜Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Microsoft Learn｜Microsoft Foundry の生成AI可観測性
https://learn.microsoft.com/ja-jp/azure/foundry/concepts/observability
Microsoft Learn｜生成AIアプリ・エージェントの評価
https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluate-generative-ai-app
Google Cloud｜Human-in-the-Loop
https://cloud.google.com/discover/human-in-the-loop
Google Cloud｜生成AIアプリケーション開発
https://docs.cloud.google.com/docs/ai-ml/generative-ai/develop-generative-ai-application
