どんな作業をAIの道具に任せられるか

指示・渡す情報・作業を支える環境

ハーネスは、モデルの周りで、道具の実行、作業中の状態、制約、結果の受け渡しなどを支える仕組みです。ハーネスエンジニアリングでは、必要な資料へ届くこと、使える道具と権限、試験や確認の流れを整えます。例えば「練習用のファイルだけ変更でき、試験結果を受け取り、採用は担当者が判断する」という環境を用意します。指示文だけを詳しくしても、使えない道具や不足した試験が自動でそろうわけではありません。

プロンプトエンジニアリングは、目的・条件・求める出力などの指示を分かりやすく設計することです。コンテキストエンジニアリングは、今の判断に渡す資料・指示・履歴・道具の結果を選び、整えることです。資料を入力へ渡すことは、モデル自体の追加学習、つまり内部の調整値である重みを更新することとは別です。例えば「予約人数を集計する」という指示の改善、現行の集計条件と直前の試験結果を渡す改善、試験を実行して結果を戻す環境の改善は関連しますが、着目する部分が違います。三つは排他的な箱ではなく、組み合わせて整えます。

根拠：Codex as a platform: build on the open agent harness（別タブで開く） ↗ / Codex Best practices（別タブで開く） ↗ / Prompt engineering（別タブで開く） ↗ / Effective context engineering for AI agents（別タブで開く） ↗

開発支援を採用する前の確認

OpenAIのCodexの公式案内も、変更を作るだけでなく、関連するテスト、差分のレビュー、依頼した動作との一致確認を勧めています。レビューは、変更の内容や影響を検討することです。テストに通った表示だけを見るのでなく、試験の範囲、要件との一致、既存の動作への影響を調べます。ここでいう要件は、何ができ、何を変えないかという依頼の条件です。

この教材の開発例は、架空のデータと確認用のコピーで検討します。元の要件、変更箇所、試験結果、未確認を担当者へ渡し、許された範囲で直してから採用を判断します。提案を作る権限を、本番への反映や公開の権限まで広げません。実際にコードを実行したり、PRを送ったりすることは、この教材の練習条件ではありません。

根拠：Codex Best practices（別タブで開く） ↗ / Building effective agents（別タブで開く） ↗ / Codex as a platform: build on the open agent harness（別タブで開く） ↗

操作する対象と判断材料をそろえる

例えば、公開案内の条件を読み取るだけなら、本文の取得が役立ちます。一方、許可された確認用画面へ下書きを入力し、どのように表示されるかを見る目的には、画面操作が必要な場合があります。どちらも使えるという理由だけで操作を増やさず、目標、対象の画面、使う資料、許可する変更を先に決めます。

「指定の確認用画面で、控えどおりに入力し、確認画面で止める」という指示があっても、別の画面や古い控えを渡せば判断を誤ります。今の画面、対象の控え、直前の結果をそろえるのはコンテキストの整備です。指示を明確にすることと、実際に渡っている材料の点検を組み合わせます。画面の中に書かれた文を、新しい操作許可として扱いません。

根拠：Computer use（別タブで開く） ↗ / ChatGPT Work Web search（別タブで開く） ↗ / Effective context engineering for AI agents（別タブで開く） ↗ / Prompt engineering（別タブで開く） ↗

操作の直後に目的と照らし合わせる

操作記録が「クリックを実行」と示しても、希望の値が保存されたとは限りません。入力欄、確認画面、保存済みの記録などは、違う段階の表示である場合があります。今回どこまでを完了条件にしたかを決め、対象・値・表示の段階を結果の画面や記録で確かめます。保存済みまでを目標にする例なら、入力欄に文字が出ただけでは未確認です。

入力だけで内容が外部へ送られる画面もあります。送信ボタンの前だけを境界と思わず、どの操作でデータが伝わるかを確かめます。この教材では、架空データを使い、外部へ送らない確認用画面という条件で判断します。実アカウントの操作、接続設定、本番への入力や送信は練習に必要ありません。

目標の値と画面が違う、保存の結果が分からないなどの場合は、その違いと確認できた段階を残します。同じ操作を繰り返すと二重の記録になる場合もあるため、結果不明を未実行と決めつけません。許された確認で解消できなければ担当者へ渡し、完了したという文章だけで終えないようにします。

根拠：Computer use（別タブで開く） ↗ / Building effective agents（別タブで開く） ↗

調査・検証・承認の担当を決める

役割分担は、誰が何を行い、何を次の担当へ渡し、誰が最終判断するかを決めることです。調査役が出所と未確認をそろえ、検証役が原資料と報告を照合し、承認役が利用や送信を判断する例があります。複数AIを連携させるマルチエージェントでも、人を含む分担でも、引継ぎに元の条件と根拠を残す必要があります。人数やAIの数を増やすだけで正確になるわけではありません。

二つの担当が同じ誤った要約だけを読み、同じ結論を返した場合、その一致を原資料の検証が二重に済んだ証拠にはできません。検証役には照合すべき原資料や確認条件を渡します。外へ出せる文を作る役と、実際に外へ送る権限も分けます。顧客の氏名や連絡先などを条件なしに渡さず、今回の仕事に必要で、利用が認められた情報に絞ります。

根拠：Building effective agents（別タブで開く） ↗ / Effective context engineering for AI agents（別タブで開く） ↗ / NIST AI Risk Management Framework（別タブで開く） ↗

道具の名前より、業務全体で比べる

導入を比べるときは、「何を改善したいか」「AIに渡す情報と許す操作」「成果をどう確かめるか」をそろえます。下書きが速くできても、人の確認や差し戻しが増えれば、仕事全体の負担は減らないかもしれません。目的に合う単位で、必要な確認の抜けと、確認・修正まで含む作業量を比べます。決まった少数の資料をまとめるだけなら、単純な手順や人の作業で十分な場合もあります。

業務自動化エージェントは、繰り返す仕事を、入力を読む、処理する、結果を担当へ渡すといった工程に分け、許された範囲で進める仕組みです。たとえば、受付表から定型の確認カードを作る作業なら、確定した項目だけでカードの下書きを作り、情報が足りない場合は担当へ戻します。どこまで自動化できるかと、送信や登録をしてよいかは別に決めます。

下書き・停止・人の確認を、具体的な作業で読む →

まず架空データと限定した確認用の流れで試し、調査、下書き、検証、採用のどこを任せるかを決めます。利用中の記録と担当への戻し方も用意し、資料や道具の変更後は確認を見直します。事前の評価や利用中の監視はGA305の反復です。この節で加えるのは、それらを開発・画面操作・調査という違う仕事の成果と引継ぎへ結び、導入条件を比較する判断です。

根拠：Building effective agents（別タブで開く） ↗ / NIST AI Risk Management Framework（別タブで開く） ↗