AIエージェントに業務を完了させるための5つの設計 --- 指示・権限・ツール・履歴・検証

はじめに

AIエージェントに「不具合を修正し、テストを実行して、PRを作成してください」と依頼する。

コードは修正され、テスト結果も報告され、PRも作成された。しかし、レビュー時に次のような状態が見つかったとする。

対象外のファイルが変更されている。テスト結果が修正前のcommitに対するものだった。途中で止まった作業を再開したら、同じPRを二重に作ろうとした。

これらは、コード生成能力だけでは解決できない問題だ。モデルの能力と、業務を完了できる仕組みは分けて設計する必要がある。

OpenAIの最新モデルガイドでも、指示の調整、自律的に進める範囲、サブエージェントへの委譲、変更に見合う検証が説明されている。モデルを変更するだけでなく、周辺の運用を見直す必要があると読める。¹

本記事では、ソフトウェア開発を例に、指示・権限・ツール・履歴・検証をどう組み合わせるかを整理する。

目標は「一度も停止せずに動くAI」ではない。中断、担当交代、再実行があっても、承認済みの目標へ、根拠を残して到達できるAIエージェントである。

公式資料の確認日は2026年9月9日。製品仕様への参照と、本記事で提案する設計を区別して記載する。「作業契約」や後述の状態名は設計上の概念であり、Codexの標準設定名ではない。具体例の環境・リポジトリは架空であり、実環境での検証結果を示すものではない。

1. 「実行してよい」「実行できた」「完了した」を分ける

AIエージェントの実行では、三つの判定を分けたい。

判定	確認する内容	主な判定主体
実行許可	指定された主体が、指定された対象に、操作を実行してよいか	権限制御・承認機構
操作成功	要求した操作が、対象システムで成立したか	ツール結果・対象システムからの再取得
業務完了	成果物と実行過程が、受入条件を満たしたか	検証機構・必要に応じて人

PR作成APIの成功は「操作成功」だ。対象branchが違えば、依頼された業務は完了していない。

テストの正常終了も同様だ。必須のテストが実行されていない、あるいは修正前の成果物を検査していたなら、必要な検証を満たしていない。

本記事では、五つの要素を次の役割で配置する。

要素	役割	不足した場合の問題
指示	目的、対象、範囲、完了条件を定める	何をどこまで行うかが曖昧になる
権限	実行可能な操作範囲を強制する	指示上は禁止でも、技術的には実行できる
ツール	操作し、結果を観測する	成功・失敗・不明を判別できない
履歴	作業状態、判断根拠、証跡を残す	再開時に推測や重複作業が発生する
検証	受入条件との一致を判定する	完了がモデルの自己申告になる

実行の基本形は、五つの要素を接続した閉ループになる。

対象を観測する
  → 作業契約と照合する
  → 次の操作を決める
  → 権限を検査する
  → ツールで実行する
  → 結果を記録する
  → 受入条件を検証する
  → 続行・承認要求・停止・完了を選ぶ

モデルの周辺に、実行環境、情報取得、制約、フィードバックの仕組みを構築する考え方は、OpenAIが説明する「harness engineering」とも重なる。²

重要なのは、モデルが生成した操作候補を、そのまま実行許可や完了判定として扱わないことだ。

2. 指示：依頼を「作業契約」にする

「最後まで進める」では終点が決まらない

次の依頼には、終点がない。

必要な修正を行い、十分にテストして、問題がなくなるまで自律的に進めてください。

「必要」「十分」「問題がなくなるまで」の意味が未確定だからだ。対象外の改善まで始めることも、追加テストを延々と続けることも、文章上は否定されていない。

そこで、目的、対象、実行範囲、受入条件、停止条件をまとめた文書を、ここでは作業契約と呼ぶ。

例えば、次のように依頼を変える。

Issue #42の「データが0件の場合にCSV出力が失敗する不具合」を修正する。変更は指定された実装ファイルと回帰テストに限定する。0件時の期待するHTTP応答とCSV内容、および既存動作の維持を検証する。指定branchのPR準備まで進め、マージと本番反映は行わない。

実装方法の自由度は残しつつ、業務上の終点を固定する。

調査で確定する情報と、人が決める情報を分ける

作業契約に不明点があっても、すべて利用者へ質問する必要はない。

起点commit、既存テスト、対象PRの有無など、承認済みの読み取りで確認できる情報は調査する。一方、仕様変更、費用負担、公開範囲、データ削除、受入条件の引き下げは、責任者の判断として扱う。

モデルが補ってよいのは、承認済み範囲内の実装上の詳細であって、権限や責任ではない。

AGENTS.md、Skills、作業契約を混ぜない

役割は次のように分けると整理しやすい。

情報	記載する内容	更新の単位
AGENTS.md	恒常的なルール、禁止事項、構成、正本への参照	リポジトリ・適用範囲単位
Skills	繰り返し使う手順と適用条件	ワークフロー単位
作業契約	今回の目的、対象、範囲、完了条件	案件単位
作業台帳	進捗、未完了事項、停止理由	実行中の状態変化ごと

Codexでは、グローバル設定とプロジェクト階層の指示が組み合わされ、作業ディレクトリやAGENTS.override.mdの存在によって適用される指示が変わる。リポジトリ直下のAGENTS.mdだけを確認して、実際の指示全体を確認したことにしない。³

Skillsは、名前と説明を入口に、使用時に詳細なSKILL.mdを読み込む仕組みを採る。毎回必要ではない手順の分離に適している。⁴

また、OpenAIの実践例では、AGENTS.mdを巨大な説明書ではなく、詳細な知識へ案内する目次として扱っている。²

本記事でも、案件ごとの進捗や過去ログをAGENTS.mdへ蓄積する構成は採らない。作業契約も、管理者ポリシーや技術的制約を上書きする手段にはしない。

3. 権限：「禁止と書く」と「実行できない」は違う

禁止事項を文章だけに置かない

「本番環境を変更しない」と指示しても、実行アカウントが本番管理権限を持っていれば、技術的には変更可能なままだ。

Codexの公式説明でも、sandboxは技術的な実行境界、approval policyは確認を求める条件として区別されている。⁵

その区別を業務設計へ持ち込み、重要な制約を三層で扱う。

指示で意図を伝える。実行環境で操作範囲を制限する。接続先でも権限を制限する。

例えば、PR準備が担当範囲なら、実装担当へ本番資格情報を渡す必要はない。対象外のリポジトリや本番環境まで操作できる資格情報を渡し、「使わないように」と指示する構成を避ける。

権限を対象と条件まで限定する

「GitHub操作を許可」では範囲が広すぎる。設計上は、次の単位まで具体化する。

実行主体 × 対象オブジェクト × 操作 × 条件 × 有効期間

指定branchへのpushと、別PRのマージは別の権限だ。公開情報の読み取りと、顧客データの読み取りも同じ扱いにはしない。

ツール一覧からマージ機能を外しても、shellから強い資格情報を使って同じ操作ができるなら、マージ禁止は技術的に成立していない。

厳密な制御が必要な場合は、資格情報を専用の実行サービスへ隔離し、対象、操作、承認記録をサービス側で照合する構成にする。モデルが引数にapproved: trueと書いただけでは、承認したことにしない。

自律性を高めるとは、強い権限をまとめて渡すことではない。承認済みの範囲内で、不要な確認を減らすことだ。

4. ツール：「呼べる」より「結果を確定できる」を重視する

型が正しいことと、業務的に正しいことは違う

OpenAIのfunction callingでは、strict modeによって引数を定義済みのスキーマへ適合させられる。⁶

ただし、PR番号が整数であることは、そのPRが作業対象であることを意味しない。パスが文字列として妥当でも、変更禁止ディレクトリを指している可能性がある。

本記事では、ツールの入力検証を、形式の検査と業務上の検査に分ける。

書き込みツールでは、対象ID、作業契約の版、期待する対象の現在の版、必要な承認を実行側で照合する。実行後は、操作ID、変更対象、変更後の状態、証跡参照を返す。

対象の版が変わっていた場合は、古い前提で実行しない。接続先が条件付き更新に対応する場合は、その機能を利用して競合を検出する設計にする。

成功・失敗・不明の三状態を持つ

外部操作では、結果を二値に押し込めない。

状態	意味	次の処理
成功確認済み	要求した操作の成立を確認できた	事後条件を検証する
未成立確認済み	操作が成立していないと確認できた	原因と再試行条件を評価する
結果不明	成立したかどうかを判定できない	対象システムと照合する

例えば、PR作成要求の直後に通信がタイムアウトしたとする。

分かるのは、正常な応答を得られなかったことだ。PRが作成されなかったことまでは分からない。

そのため、まずリポジトリ、head branch、base branchなどを照合して、PRの有無を確認する。APIが冪等性キーを提供する場合は利用し、結果不明の書き込みを無条件に再試行しない。

複数段階の操作では、一部だけ成功した状態も残す。「途中でエラーになったので、最初から全部やり直す」という復旧を標準にしない。

復旧方法もツールの契約に含める

更新ツールだけを用意し、状態照会や復旧経路を後回しにしない。

設定変更なら変更前後の値、データ移行なら進捗と適用範囲、外部送信なら送信済みかを照合する方法を定める。

元に戻せない操作は、取消不能であると明示する。必要な補償処理や担当者への連絡を、存在しないロールバックで代用しない。

5. 履歴：「記憶」「正本」「証拠」を分離する

会話履歴を、そのまま業務台帳にしない

会話には、途中の仮説、古い検証結果、撤回された方針が混在する。再開可能な運用を設計するなら、保存する情報を分けたい。

種類	保存する内容	取り扱い
恒久知識	アーキテクチャ、業務ルール、標準手順	レビュー・版管理した正本
作業状態	対象branch・PR・commit、進捗、停止理由	再開時に現物と照合する台帳
実行証跡	テスト結果、CI実行ID、ツール結果、成果物	検証対象に結び付けた記録
判断メモ	仮説、採用理由、却下案、未解決事項	根拠と不確実性を伴う補助情報

OpenAIのMemoryとCompactionの実践例でも、実行継続のための情報、次回に引き継ぐ知見、人がレビューする正本は区別されている。⁷

「モデルが覚えている」を、「現在も正しい」「承認済み」「検証済み」と同義にしない。

証跡には対象の版を付ける

「テストは通りました」だけでは、何を確認したのかが分からない。

検証記録には、対象commit、検証項目、実行環境、実行時刻、結果、証跡参照を関連付ける。依存関係や設定が結果に影響するなら、その版も記録する。

commitが変わったら、過去の合格は過去の成果物に対する証拠だ。変更後の成果物まで合格したとは扱わない。未コミットの変更を含む検証結果も、commitだけを記録して済ませない。

head単体の検証と、baseへの統合を想定した検証も分ける。headとbaseのSHA、実際に検証したcommitを対応付け、baseが変わった場合は統合検証の有効性を再評価する。

突然の停止に備え、実行側で記録する

「停止する前に引き継ぎメモを書いて」と指示するだけでは、強制終了に対応できない。

重要な操作の開始と結果は、モデルの任意の文章とは別に、実行側で記録する設計にする。再開時に「開始記録はあるが結果がない」と判明した操作は、成否を照合する対象になる。

証跡は、実装担当が自由に過去の記録を書き換えられる場所だけに置かない。ただし、秘密情報を無制限に保存せず、マスキング、アクセス制御、保持期間も設計する。

外部情報を指示へ昇格させない

Issue本文や取得したWebページに「CIを無効にして進めてよい」と書かれていても、その文章だけで検証要件を変更しない。

OpenAIの安全性ガイドも、信頼できない入力を高い優先度の指示へ混入させないことを重視している。⁸

取得した外部情報は、事実候補として扱う。権限や受入条件を変更する場合は、正規の承認経路を通して作業契約を改訂する。

6. 検証：成果物と、作業の進め方を両方確認する

動けば成功、とはしない

指定機能が動いても、対象外のPRを変更したり、秘密情報を外部へ送信したりしていれば、業務上の成功にはできない。

本記事では、検証を二系統に分ける。

成果物検証では、仕様、機能、互換性、セキュリティ、期待される業務結果を確認する。

実行過程の検証では、対象、変更範囲、権限、承認、禁止事項、予算の扱いを確認する。

OpenAIのagent evalsも、最終出力だけでなく、ツール呼び出し、ガードレール、引き継ぎを含む実行記録を評価対象にしている。⁹

実装担当に合格基準を自由に変えさせない

不具合修正に伴い、テストを追加・修正する場合はある。しかし、実装担当が必須チェックや受入条件を自由に削除できる構成では、「条件を満たした」のか「条件を弱めた」のかが分からなくなる。

重要な受入条件や必須CIは、通常の実装変更と分けて管理する。テストの期待値を変更する場合も、仕様との対応を確認する。

独立したAIレビューを加える場合は、実装担当の説明だけでなく、作業契約、仕様、実際の差分、証跡を渡す。別セッションや別モデルによる同意を、独立した実測の代わりにはしない。

実機でしか確認できない条件なら、実機検証を行う。必要な環境へ接続できない場合は「未検証」であり、「問題なし」ではない。

検証にも終了条件を設ける

検証を増やし続ければよいわけでもない。

最新モデルの公式ガイドは、変更に対応したテストと必須チェックを完了し、追加変更、失敗、未解決の懸念がない限り、不必要に検証を広げたり繰り返したりしないよう案内している。¹

認証処理の変更と文書の誤字修正では、必要な検証が違う。実行前に必須検証を定め、検証を追加する理由も説明できる状態にする。

7. 長時間自走は「停止」と「再開」まで設計する

プロセスの終了と、目標の達成を分ける

PR準備までを任せた場合、次の状態は矛盾しない。

エージェントの担当目標：達成
実行プロセス：停止済み
PRのマージ：人の承認待ち
本番反映：未実施

逆に、利用量の上限でプロセスが止まっても、目標を達成したことにはならない。

作業契約でPR準備までと決めたなら、マージしていないことを「未完了」と扱わない。何の工程を完了とするかを分ける。

停止理由ごとに再開条件を変える

停止理由	再開条件
仕様が決まらない	責任者が判断し、作業契約を更新する
権限が足りない	正規の認可、または承認済みの代替経路が成立する
環境・ツールが故障した	環境を復旧し、対象の状態を再確認する
外部書き込みの結果が不明	対象システムで成否を照合する
検証が不合格	原因に対応した修正と再検証を行う
時間・利用量の上限に達した	証跡と未完了事項を保存し、追加予算を承認する
対象branch・PR・commitが変わった	範囲と検証結果の有効性を再評価する

権限不足を、別の強いアカウントへの切替で回避しない。環境障害を、コードの不具合と決めつけて修正しない。

また、停止要求は「新しい操作を開始しないこと」と「実行中の操作を取り消すこと」に分ける。取消できない処理が実行中なら、完了・失敗・結果不明のどこに着地したかを確認するまで管理を続ける。

再開は状態照合から始める

別セッションで再開するときは、前回の説明を読むだけでなく、作業ディレクトリ、branch、PR、commit、未コミット変更、実行中の外部操作、承認の有効性を再取得する。

未知の変更があった場合は、既存作業を削除して整えるのではなく、所有者と意図を確認する。

OpenAI Agents SDKには、承認が必要なツール呼び出しで中断し、状態を保存して承認後に再開する仕組みがある。ただし、承認対象や有効期限などの業務条件は、利用側で設計する必要がある。¹⁰

承認は、対象PR、commit、操作、対象環境、作業契約の版に結び付ける。承認後に成果物が変わった場合は再評価する。実行直前にも対象の版を照合し、古い承認で異なる成果物を操作しない。

並行実行では書き込み担当を一意にする

基本方針を「一つの可変オブジェクトに対し、同時点の書き込み担当は一人」とする。

Git worktreeは作業ツリーを分けられるが、commitやbranchなどのメタデータは共有される。worktreeを分けただけで、すべての状態や権限が独立するわけではない。¹¹

実装担当とレビュー担当を分け、レビュー担当は実装中のbranchを直接変更しない。PR本文、Issue本文、テスト用DB、GUIの操作対象にも書き込み担当を決める。

並列化するのは、独立した調査や検証だ。同じ状態への無調整な更新ではない。

8. 実例：PR準備までを任せる作業契約

以下は、架空のCSV出力サービスを対象にした作業契約の記入例である。実行コマンドやCodex設定ファイルではなく、案件開始前に確定させる情報を示している。

実環境へ適用する場合は、担当者が環境、パス、リポジトリ、branch、PR、検証方法を実在する値に置き換え、作業開始前に照合・承認する。

【案件】
作業ID: CSV-42
リポジトリ: example-org/csv-export-service（架空）
対象Issue: #42
目的: データ0件時のCSV出力エラーを恒久修正する。

【実行者・実行環境】
実装担当: Codex CLI。OSアカウントは agent-worker。
環境: 専用Linux VM agent-dev-01。Ubuntu 24.04、Python 3.12。
作業ディレクトリ: /home/agent-worker/worktrees/csv-export-service/issue-42
独立検証担当: CIサービス。実装担当とは別の実行主体。
承認者: リポジトリ責任者。
前提: Git・Codex CLI・固定済み依存関係・既定CIが利用可能。
実装担当には本番資格情報、管理者権限、マージ権限を渡さない。

【対象branch・PR】
base branch: main
作業branch: fix/issue-42-empty-export
起点commit: 開始前にmainのcommit SHAを取得して台帳へ記録する。
対象PR: 開始時は未作成。作成後は取得したPR番号を台帳へ固定する。
同じhead/baseの既存PRがある場合は、変更を開始せず対象を確認する。

【変更対象】
/home/agent-worker/worktrees/csv-export-service/issue-42/src/export.py
/home/agent-worker/worktrees/csv-export-service/issue-42/tests/test_export.py
追跡対象ファイルの変更は上記2ファイルに限定する。
既定の検証に必要なキャッシュ・一時出力は許可し、commitしない。

【変更禁止対象】
許可した2ファイル以外の追跡対象ファイル。
特に /home/agent-worker/worktrees/csv-export-service/issue-42/.github/workflows/ 以下。
他branch、他PR、受入条件、権限設定、本番環境、秘密情報。

【実行時点・予算】
対象と権限を照合し、作業契約を承認した後に開始する。
初回実行は最大120分。期限到達時は新しい変更操作を開始しない。
実行中の操作は成否を確認し、状態と未完了事項を保存して停止する。
追加実行は、状態再照合と追加予算の承認後に行う。

【期待結果・検証】
データ0件時: HTTP 200、CSV本文は「id,name」とCRLFのみ。
データ1件以上: 既定の仕様と既存テストが維持される。
0件時の回帰テストと既定CIの必須チェックが合格する。
必須テストの未実行・スキップ、失敗の握りつぶしを合格と扱わない。
head・baseのSHAと実際の検証対象commitを対応付け、PRと照合する。
未コミット変更のある成果物は、最終検証の対象にしない。

【証跡】
作業台帳: /srv/agent-runs/CSV-42/state.json
実行証跡: /srv/agent-runs/CSV-42/evidence/
実行基盤が記録し、実装担当には参照用として提供する。
対象commit、実行環境、検証項目、結果、CI実行IDを関連付ける。

【エラー時の分岐・復旧】
対象不一致・未知の変更: 書き込みを停止し、既存変更を保持する。
環境障害: 証跡を残して停止し、環境担当の復旧後に再照合する。
検証不合格: 許可した2ファイル内で修正する。範囲外なら承認を求める。
PR作成の結果不明: GitHub上のPRを照合し、無条件に再作成しない。
セッション中断: 作業ツリーを削除せず、台帳と現物を照合して再開する。
誤変更の復旧: 差分を保全し、承認された自分の変更だけを戻す。
外部変更の取消: 対象と影響を確認し、必要な承認後に実施する。

【今回行う作業・行わない作業】
今回: 調査、恒久修正、回帰テスト、独立検証、PR準備。
一時修正: 原則行わない。必要なら目的と撤去条件を別途承認する。
別セッション: マージ、本番反映、対象外の改善、検証基盤の恒久変更。
終了条件: 受入条件と証跡が揃い、人がPRを判断できる状態。

この契約の重要な点は、実装の方法を細かく固定することではない。

対象と終点を確定し、モデルが自由に判断してよい範囲を明確にすることだ。パスの記載だけでアクセス制御が実現するわけではなく、実行環境側の制約や、差分・証跡の検査と組み合わせる。

PR準備完了の判定は、概念的には次のようになる。

PR準備完了 =
    変更範囲が作業契約に一致する
    AND 必須検証が合格している
    AND 証跡がレビュー対象の成果物に対応している
    AND 未確認の外部操作が残っていない
    AND 未検証事項・残課題が明示されている

必須項目の未検証は、残課題欄へ書くだけでは合格にならない。今回の受入条件に含まれない項目や、正規に承認された例外と区別する。

最終報告も、長い作業日誌ではなく、対象PRとcommit、変更内容、検証結果、未検証事項、残るリスク、人が判断する操作を中心にまとめる。

9. 導入は、作業契約と証跡から始める

最初から大規模なエージェント基盤を作る必要はない。導入段階は分けられる。

最初に行う：依頼と完了報告を固定する

対象、範囲、禁止事項、受入条件、停止条件を依頼に含める。完了報告に対象commitと検証証跡を含める。既存の権限は拡大しない。

単純な文書修正なら、短い作業契約で足りる。外部書き込みや機密情報を扱う案件では、開始前から技術的な権限制御を必要条件にする。

恒久化する：繰り返す問題を自動検査へ移す

対象branchの誤り、禁止ファイルの変更、必須検証の未実施、証跡不足などを機械的に検査する。

AGENTS.md、Skills、CI、権限制御の変更は、実装中の不具合修正へ便乗させず、専用の作業契約とbranch・PRで扱う。

必要な業務で拡張する：承認・再開・外部操作を管理する

複数の外部システムへの書き込みが増えた段階で、専用実行サービス、操作台帳、承認記録、結果照合、再開機構を整える。

評価指標は「何時間自走したか」だけにしない。受入条件を満たした割合、誤った完了申告、人の確認時間、手戻り、禁止操作、停止からの再開成功率を確認する。

費用も、モデルの利用料だけでなく、人のレビューと復旧、やり直しまで含めて評価する。

まとめ

AIエージェントに業務を完了させるには、五つの要素を別々に改善するだけでは足りない。

指示で目的と境界を決め、権限で実行範囲を強制し、ツールで操作と結果を扱い、履歴で状態と証拠を残し、検証で完了を判定する。

その上で、モデルには承認済みの範囲内の判断を広く任せる。

強い「最後まで進める」という指示よりも、何をもって完了とするか、不明・失敗・承認待ちからどう再開するかを、会話の外に固定する方が重要だ。

目指すのは、止まらないAIではない。必要なときに止まり、根拠を失わずに再開し、約束した範囲を完了できるAIエージェントである。

参考資料

1. OpenAI, Model guidance. 自律実行、指示、委譲、検証の調整に関する公式ガイド。 ↩ ↩²

2. OpenAI, Harness engineering: leveraging Codex in an agent-first world. 実行環境、リポジトリ知識、機械的検査の設計例。 ↩ ↩²

3. OpenAI, Custom instructions with AGENTS.md. 指示ファイルの探索と適用範囲。 ↩

4. OpenAI, Build skills. 再利用可能な手順と段階的な読み込み。 ↩

5. OpenAI, Running Codex safely at OpenAI. sandbox、承認、ネットワーク、実行記録の設計例。 ↩

6. OpenAI, Function calling. ツール定義とstrict mode。 ↩

7. OpenAI, Building Reliable Agents with Memory and Compaction. 記憶、実行継続、人がレビューする正本の分離。 ↩

8. OpenAI, Safety in building agents. 信頼できない入力とプロンプトインジェクション対策。本記事では製品固有の操作手順ではなく、安全設計の原則を参照。 ↩

9. OpenAI, Evaluate agent workflows. 実行記録を含むエージェント評価。 ↩

10. OpenAI, Human-in-the-loop — OpenAI Agents SDK. 承認による中断、状態保存、再開。 ↩

11. OpenAI, Worktrees. 作業ツリーの分離と共有されるGitメタデータ。 ↩