最近、AIがますます進化して、日常生活から仕事まで、いろいろな作業をサポートしてくれるようになっています。
AIの使い方について少し振り返ってみると、以前は「プロンプトエンジニアリング」という言葉がよく使われていました。AIから良いアウトプットを得るには、役割を指定し、手順を細かく説明し、出力形式や制約条件まで明示した、ある程度複雑で長大なプロンプトを書くことが推奨されていたわけです。
AIへの指示は人間に仕事を依頼することと共通する部分もあるため、「良いプロンプトを書くには管理職経験が必要」なんて話もありました。
ところが、最近は少し様子が変わってきています。AIの能力が向上したことで、以前ほど細かな指示を与えなくても、十分な品質のアウトプットを得られるようになってきました。その一方で、高度なAI活用の現場では「コンテキストエンジニアリング」や「ハーネスエンジニアリング」といった言葉が注目されています。
プロンプトは簡単になっているのに、AIへ渡す情報や実行環境の設計は重要になっている。一見すると矛盾しているようですが、私はこの変化を、AIが自律的に仕事を進められるようになったことで「要件定義」の必要性が強まっている、と考えると理解しやすいのではないかと思っています。
複雑なプロンプトはどこへ行ったのか
以前のAI活用では、何をさせたいのかだけでなく、どう作業するのかまで説明することが重要でした。例えば市場調査レポートなら、調査対象を整理し、市場規模を調べ、競合企業を比較し、分析結果をまとめるといった手順を人間が指定していました。
ところが最近の高性能なAIは、こうした手順自体を考えられるようになっています。特にAIエージェントの環境では、目標に応じて計画を立て、検索やファイル操作などのツールを使い、途中の結果を踏まえて次の作業を選択できます。複数のエージェントを連携させ、情報収集や分析、検証を分担させる仕組みも登場しています。
もちろん、すべてのAIが自律的に動くわけではありませんし、正確な手順の指定が必要な業務もあります。それでも、以前は人間がプロンプトに書き込んでいた「作業の進め方」の一部を、AI自身が引き受けられるようになったことは大きな変化です。複雑な手順が消えたのではなく、手順を組み立てる役割が人間からAIへ移り始めたわけです。
これは、仕事を依頼する相手が「一人の部下」から「一つのチーム」に変わってきている、と捉えることもできそうです。
一人の担当者に作業を教えるのであれば、具体的な手順を伝えることも必要でしょう。しかし、経験豊富なプロジェクトチームに仕事を任せる場合には、個々の作業手順まで指示することは通常ありません。プロジェクトの目的や制約条件、期待する成果を伝え、具体的な進め方はチームに考えてもらいます。
AIも、こうした仕事の任せ方に近づいてきているのだと思います。
AIが自分で考えるなら、何を決めておくべきか
ここで少し、人間の仕事に置き換えて考えてみます。
例えば経験豊富な担当者に「新規事業のパートナー候補を調査してほしい」と依頼したとします。調査の進め方や比較表の作り方まで教える必要はないでしょうが、何のためにパートナーを探しているのかを説明しなければ、期待した結果にはならないはずです。
新しい技術を獲得したいのか、新しい顧客基盤を得たいのか。短期的な売上を重視するのか、将来の共同開発を重視するのか。例えば売上規模の大きな企業を優先した調査結果が出てきても、実際に求めていたのが技術を一緒に育てられる企業だったとすれば、調査の手順に問題がなくても、成果物は期待とずれてしまいます。
AIも同じです。情報収集や比較の方法を考えられても、何をもって「良いパートナー」と評価するのかが示されなければ、一般的な基準や推測に頼ることになります。しかも、AIが自分で進め方を選べるようになるほど、その選択を何に基づいて行うのかが重要になります。
ここが、今回考えてみたかったところです。
AIが賢くなれば、曖昧な指示でも意図を推測し、適切に対応できる範囲は広がります。ところが、計画から実行までをAIに任せるようになると、途中で人間が判断を補う機会は相対的に少なくなります。実行方法をAIに委ねるほど、その判断基準を共有する必要性が高まるという関係です。
そこで出てくるのが、要件定義です。
ITシステム開発でいう要件定義では、何を実現したいのか、対象はどこまでか、どのような制約があるのか、何を満たせば完成とするのかを明らかにします。AIに仕事を任せる場合にも、これに近い考え方が必要になっているように思います。
ただし、毎回詳細な仕様書を作るという話ではありません。何を達成したいのか、何を優先するのか、どこまで任せてよいのか。そうした業務要件を明らかにすることが、AIに仕事を任せる際の重要な前提になるわけです。
要件定義、コンテキスト、ハーネスはどうつながるのか
では、最近注目されているコンテキストやハーネスは、この要件定義とどういう関係にあるのでしょうか。
これらは同じものではありませんし、単純な上下関係でもありません。ただ、AIに仕事を任せるための仕組みとして考えると、それぞれの役割が見えてきます。
先ほどのパートナー調査を例にしてみます。
まず要件定義では、「共同開発が可能な企業を重視する」「候補を5社まで絞り、技術面と事業面で比較する」「情報源を明示する」「企業への対外連絡は人間の承認後に行う」といった条件を決めます。これは、何を実現したいのか、何を成功とするのか、どこまで任せるのかという業務上の意思決定です。
次に必要になるのがコンテキストです。
AIが候補企業を評価するためには、自社の技術方針、既存事業との関係、過去の協業事例、候補企業に関する公開情報などが役立ちます。ただし、社内に資料が保存されているだけでは、AIがそれを利用できるとは限りません。必要な情報を検索・取得し、実際にAIが推論する際に参照できる状態にする必要があります。
コンテキストエンジニアリングとは、こうした情報を適切に選択し、AIが利用できるようにするための設計です。何でも大量に読み込ませればよいわけではなく、必要な情報を必要なタイミングで渡せることが重要になります。
一方、ハーネスはAIエージェントの動作を支える仕組みです。具体的には、ツールの利用、作業状態の管理、情報へのアクセス、実行結果の検証などを含み、必要に応じて権限制御や承認の仕組みも組み込まれます。なお、ハーネスという言葉が指す範囲は、利用するエージェント環境によって多少異なります。
例えばパートナー調査であれば、外部情報を検索するツールや、社内資料を読み取り専用で参照する仕組みを用意する。候補企業へのメール送信には承認を要求し、調査結果に出典が付いているかを検査する、といった設計が考えられます。
つまり、要件定義で決めた内容の一部はAIが判断するためのコンテキストとなり、別の一部はハーネス側の制御や検証の仕組みに反映されるわけです。
Anthropicは2025年9月に公開した記事で、AIエージェントに与える情報を適切に選択・管理するコンテキストエンジニアリングの考え方を説明しています。またOpenAIも2026年2月、Codexを使ったソフトウェア開発の実践例として、エージェントが必要な情報を参照できるようにするだけでなく、制約を機械的に検証し、結果をフィードバックできる環境を整えることの重要性を紹介しています。
これらは直接、業務要件定義の重要性を主張しているわけではありません。ただ、AIの能力を十分に引き出すために、人間が指示文を書くこと以外にも、整備すべきものが増えていることは分かります。
自律化が生む「要件を明示せよ」という圧力
ここで注目したいのは、文書化や可視化が大事だという、以前からある話ではありません。
AIが自分で計画し、仕事を進められるようになることで、これまで曖昧なままでも済んでいた判断基準を、明らかにせざるを得なくなる場面が増えているという点です。
まず、AIに委ねる判断の範囲が広がります。細かな作業手順を指定している間は、調査対象をどう絞るか、何を優先するかといった判断も人間が引き受けています。しかし計画から任せる場合には、そこもAIの判断になります。前提が曖昧でもAIは作業を進められますが、それだけに依頼者の意図とは違う方向へ、効率よく進んでしまう可能性もあります。
もう一つは、作業の並列化と高速化です。
複数のエージェントが企業調査や技術評価、事業性分析を同時に進める環境では、人間がその都度前提条件を補う運用には限界が生じます。技術評価では共同開発の柔軟性を重視し、事業性分析では売上規模を重視してしまえば、それぞれの報告がもっともらしくても、最後に統合すると一貫した結論にならないかもしれません。
人間同士のプロジェクトでも起きる問題ですが、AIによって作業が高速化・並列化されると、こうした前提の不一致が短時間で広がる可能性があります。だからこそ、共通の目的や評価基準をあらかじめ共有する必要が出てくるわけです。
さらに、AIが実際のシステムを操作するようになると、曖昧さの影響はレポートの品質だけにとどまりません。調査結果をまとめるだけなら後から修正できますが、候補企業へメールを送ったり、顧客情報を外部サービスへ渡したりする処理には、取り消しにくいものもあります。
そこで、どこまで自律的に実行してよいのか、どの段階で人間の承認が必要なのかを明確にし、必要な制約は実行環境でも担保することになります。
もちろん、すべての仕事について最初から詳細な条件を決めるべきだという話でもありません。例えば未知の市場を探索するときには、途中で仮説を変えること自体が重要ですし、あえて自由度を残した方がよい場合もあるでしょう。ただ、その場合でも、AIが自由に探索してよい範囲や、人間に判断を戻すべき場面は決められます。
要件定義とは、AIの行動をすべて事前に決めることではなく、何をAIに委ね、何を人間が判断するのかを決めることでもあるのだと思います。
日常利用では、その圧力を感じにくい
ここまで読むと、「普段AIを使うときには、そこまで要件を定義していないけれど困っていない」という人もいると思います。
実際、日常的な会話ではAIの推論能力が曖昧な指示を補うこともありますし、メモリー機能が利用者の好みや過去のやり取りを参照する場合もあります。例えば普段から技術的な背景まで説明してほしいと伝えていれば、毎回その条件を繰り返さずに済むことがあります。
利用者が明示していなくても、過去のやり取りから得られた情報が、暗黙の前提条件として働いているわけです。これは比喩的には「暗黙の要件定義」とも呼べそうですが、メモリーは正式な業務要件を保証するものではありませんし、すべての情報を正確に保持・参照するわけでもありません。
また、日常利用であれば、回答を見てその場で修正を頼むこともできます。一方、複数のエージェントが継続的に仕事を進めるような環境では、人間が逐次判断を補うやり方だけに頼れなくなります。
日常利用で不便を感じていないことと、組織の業務で要件を明確にする必要性が低いことは、別の問題なのだと思います。
組織のボトルネックはどこに移るのか
企業のAI導入では、社内文書や業務マニュアルをAIに読ませることがよく議論されます。しかし、業務マニュアルに書かれているのは主に「どう作業するか」という手順であり、「なぜその仕事をするのか」「何を優先するのか」「例外をどう判断するのか」といった内容は、経験豊富な担当者や管理職の頭の中にしかないこともあります。
これまでは、人間が経験や組織内の共通認識でその曖昧さを補いながら仕事を進めてきました。しかしAIが調査や分析を短時間でこなせるようになると、今度はその結果をどの基準で評価し、どこまで実行に移すかという判断が、仕事を止める要因になってきます。
ここは、製造業の生産工程などで起きる、ボトルネックの移動に似ていると思います。
ある工程の処理能力が向上すると、それまで問題にならなかった別の工程が、全体の処理能力を制約するようになります。AIによって調査や分析、資料作成が高速化した結果、仕事の目的や判断基準を決める部分が、相対的に大きな制約として現れてくるという考え方です。
もちろん、すべての組織で同じことが起きるとは限りません。それでも、AIが仕事を十分にこなせるようになったとき、今度は人間や組織が何をしたいのかを定義できていないことが問題になる、という構造は十分に考えられます。
そこで重要になるのが、企画書や業務定義書、業務要件定義書のような情報です。
ただし、こうした文書を大量に作れば問題が解決するわけではありません。AIが必要な情報を参照できること、要件として定めた条件が実際の判断や実行に反映されること、そして期待と異なる結果が出たときに原因を確認できることが重要です。文書化そのものよりも、組織の意図をAIの動作につなげられるかどうかが問われるのだと思います。
ここで一つ、別の見方もできます。AIがそこまで賢くなったのであれば、不足している要件もAI自身が質問し、整理できるのではないか、というものです。
実際、それは可能です。パートナー調査を依頼されたAIが、「技術獲得と販路拡大のどちらを重視しますか」と質問したり、複数の評価軸を提示したりすることはできます。要件を明確にする必要性が高まることと、人間が要件定義書を書く負担が増えることは、同じではありません。
ただ、AIが選択肢を整理できたとしても、どれを優先するかという事業上の意思決定まで、勝手に確定してよいわけではありません。AIが曖昧さを発見して質問し、人間が方針を決め、その結果を次の実行に反映する。要件定義そのものもAIと協働して進められるようになると、人間には作業方法を指示することよりも、目的や判断の責任を引き受ける役割が求められるようになるのでしょう。
AI協働時代の要件定義
これまで人間は、曖昧な指示や不完全な要件を、経験や組織内の共通認識によって補いながら仕事をしてきました。しかし、AIが計画から実行までを担うようになると、そうした暗黙の調整に依存したままでは、仕事を任せられる範囲に限界が生じます。
AIに任せられる仕事が増えるほど、今度は人間や組織が、何を実現したいのか、何を優先するのかを決められるかどうかが問われるようになります。
考えてみれば、要件定義は人間同士の仕事でも本来必要だったものです。これまでは不十分な要件を人間の経験や能力によって補うことができましたが、AIの自律性が高まることで、その前提が変わり始めているのだと思います。
AI協働時代に要件定義が重要になるのは、文書化の価値が新しく発見されたからではなく、仕事を任せる仕組みそのものが変わり始めているからではないでしょうか。
参考資料
Anthropic — Effective context engineering for AI agents（2025年9月29日）
OpenAI — Harness engineering: leveraging Codex in an agent-first world（2026年2月11日）
コメント