AIエージェントの作り方｜合意する5つの仕様

AIエージェントの試作画面を見た顧客から、「これなら来月には本番へ入れられますか」と聞かれる。そこでSIerが言葉に詰まる。

ところが、社内で毎日使える状態にするまでが長い。顧客を取り違えたらどうするか。情報が足りないときに止まれるか。外部送信の前に誰が確認するか。失敗後にどこから再開するか。デモでは隠れていた論点が一気に出てくる。

モデルは動いている。だが、見積条件、責任分界、受入基準、障害時の担当が決まっていない。コードがあるのに、契約と検収へ渡せる仕様がない状態だ。

AIエージェントの作り方は、発注者とSIerが業務境界、ツール入出力、承認シーケンス、受入基準、運用引継ぎの5成果物に合意するところから始まる。ここでは実装手順の紹介ではなく、見積・契約・検収へ渡せる仕様の作り方を整理する。

AIエージェントの作り方は、普通の自動化と分けるところから

すべての業務にAIエージェントが必要なわけではない。

入力と処理が固定でき、毎回同じ答えを返せるなら、通常のプログラムやRPAの方が安定する。AIエージェントが向くのは、文書や会話のような非構造データを読み、状況に応じて次の行動を選ぶ業務だ。

OpenAIの実践ガイドでは、エージェントを「利用者に代わって、一定の自律性を持ってタスクを完了するシステム」と位置づけている。LLMが文章を返すだけではなく、業務の進行を判断し、必要な道具を選び、完了や中断を決める点が違いになる。

候補業務は、次の3条件で見るとよい。

判断や非構造データがほとんどなく、処理を固定できる部分は通常のプログラムへ残す。エージェントに任せる範囲を狭くすると、見積と責任の境界も明確になる。

仕様1：業務境界定義書で開始と完了を合意する

最初の失敗は「営業を自動化する」「バックオフィスを任せる」のように、範囲を大きく取りすぎることだ。これでは入力も完了条件も決まらない。

1体目は、開始と終了を一文で書ける単位に切る。

たとえば営業支援なら、「商談議事録を受け取り、CRM更新案とお礼メール下書きを作り、担当者の確認待ちにする」と書ける。ここには開始条件、使う情報、成果物、終了状態が入っている。

対象業務を切るときは、次の5項目を業務境界定義書へまとめる。

1. トリガー：何をきっかけに始めるか
2. 入力：どの情報を読むか
3. 判断：何を分類・照合するか
4. 出力：何を作るか
5. 完了：どの状態になれば終わりか

役割分担は次の形にする。

この段階ではモデル名を決めなくてよい。先に業務の合格状態を固定する。AIエージェントの導入を小さく始める方法でも触れた通り、対象を狭くすると、失敗の原因を切り分けやすい。

仕様2：ツール入出力仕様でデータ契約を決める

AIエージェントは、道具を持つと仕事ができる。一方で、道具の説明が曖昧だと、もっともらしい引数で誤実行する。

OpenAI Agents SDKの公式文書では、エージェントを指示、道具、ハンドオフ、ガードレール、構造化出力などで構成する。実装で重要なのは、道具の数より一つひとつの入出力契約だ。

各道具には、最低限次を持たせる。これがツール入出力仕様になる。

たとえば会社検索の道具が複数候補を返したとき、AIに一社を推測させない。「候補が一意でない」と構造化して返し、人間へ確認を求める。これだけで誤更新の危険はかなり下がる。

データも同じだ。CRMの会社名、メールドメイン、Driveの顧客フォルダが食い違う場合、どれを正とするかを決める。発注者は正本と例外時の業務判断を示し、SIerはそれをスキーマ、エラーコード、再試行条件へ変換する。共同レビューでは、複数候補、対象なし、権限不足の返却例まで確認する。

仕様3：承認シーケンスで権限と停止を図にする

「危ない操作はしないで」と指示に書くだけでは、権限管理にならない。安全境界は、AIの返答ではなく実行基盤で強制する。

権限は4段階に分けると扱いやすい。

• 読む：文書、メール、CRMを参照する
• 作る：要約、更新案、下書きを作る
• 更新する：社内データを確定変更する
• 外へ出す：メール送信、公開、契約、課金を行う

初期範囲を「読む・作る」までに置く案なら、更新や外部送信は人間の承認後に限定する。社内AIエージェントの権限設計で整理したように、Read、Write、Executeを一つの権限にまとめない。

停止条件も先に決める。

• 必須入力がない
• 対象候補が複数ある
• 権限が足りない
• 金額や宛先に矛盾がある
• 再試行回数を超えた
• 外部副作用の承認がない

停止条件は、文章だけでなく承認シーケンス図へ置く。発注者は金額、宛先、契約、顧客影響など承認が必要な業務条件を決める。SIerは認証主体、権限チェック、承認待ち状態、タイムアウト、再開処理を図にする。共同で「誰が、何を見て、どの操作を承認するか」を確認する。

止まった後の引き継ぎ先と再開条件も必要だ。「何が足りないか」「誰が判断するか」「何を受け取れば再開するか」を成果物に残す。

仕様4：異常系を含む受入基準を作る

デモが一度成功しても、本番投入の根拠にはならない。AIエージェントは入力によって判断が変わるため、同じ評価セットを繰り返し実行できる形にする。

評価ケースには、正常系だけでなく業務リスクに応じた異常系を十分に入れる。

測る指標も、回答の正しさだけでは足りない。対象の取り違え件数、止まるべき場面で止まれた割合、人間の修正項目数、完了時間、実行コストを追う。

OpenAI Agents SDKのクイックスタートは、単体エージェントから道具、ハンドオフ、トレース確認へ進む流れを示している。トレースは開発者向けの飾りではない。どの入力で、どの道具を呼び、どこで判断を誤ったかを評価へ戻す材料になる。

受入基準では、発注者が許容できない誤りと業務影響を決める。SIerは入力データ、期待結果、停止条件、証跡をテストケースへ変換する。共同で検収用データを確定し、誰が合否を判定するかを明記する。

評価表は検収後も残す。指示、モデル、道具、参照データを変えたら同じケースを再実行する。これが回帰テストになる。

仕様5：運用引継書で変更と復旧の責任を分ける

AIエージェントは、公開した日が完成日ではない。業務ルールが変わり、APIが変わり、参照文書が増え、モデルも更新される。

運用開始前に、次の担当を決める。

Microsoft Agent FrameworkのGo版入門は、2026年7月時点でパブリックプレビューだが、最初のエージェント、道具、会話状態、記憶、ワークフロー、ホスティングを段階的に扱う。採用技術にかかわらず、コードが動いた後に状態と実行基盤の設計が必要になる。

最低限、実行ID、依頼者、参照データ、呼び出した道具、結果、停止理由、成果物、承認履歴を追えるようにする。失敗を「AIが間違えた」で終わらせず、入力、道具、権限、指示、モデルのどこに原因があったか分ける。

運用の成否は、自動化率だけでは決まらない。安全に止まり、人間が短時間で直し、同じ失敗を次の版で減らせることが重要だ。

5つの仕様を見積・契約・検収へつなぐ

AIエージェントの開発着手前に、次の5点をそろえる。

1. 業務境界定義書：開始、入力、判断、出力、完了
2. ツール入出力仕様：型、失敗分類、副作用、再試行
3. 承認シーケンス：権限、承認者、停止、再開
4. 異常系受入基準：テストデータ、期待結果、合否
5. 運用引継書：変更、監視、復旧、問い合わせ先

業務境界とツール仕様は見積範囲へ、承認シーケンスは責任分界とセキュリティ条件へ、受入基準は検収条項へ、運用引継書は保守範囲へ接続する。画面イメージやモデル名だけで見積もるより、追加費用が発生する条件も説明しやすい。AIエージェントの開発現場で見えた条件を検討するときも、成果物単位で工数を分けられる。

Kakusillで5つの仕様を構造化すれば、要求ID、ツール、承認条件、テスト、変更履歴を同じ根拠で追える。人間の合意資料で終わらず、AIや開発者が参照できる仕様へ渡せる点が重要だ。

株式会社Atsumellでは、業務フローの可視化から、要件、権限、評価、運用を含むAIエージェントの設計・構築を支援している。AIエージェントをデモで終わらせず、日々の業務へ組み込みたい場合は、お問い合わせから相談してほしい。

関連記事

• AIエージェントの導入、最初の一歩はどこから？
• 社内AIエージェントは権限設計から
• AIエージェントの要件定義は評価設計から