AIエージェントの入力設計は何から決めるべきか
# AIエージェントの入力設計は何から決めるべきか
AIエージェントを業務に入れる話になると、会話はすぐに「何のツールにつなぐか」に寄りやすい。Slack、Gmail、CRM、社内Wiki。つなげる先を増やすほど、いかにも仕事が進みそうに見えるからだ。
でも、現場で本当に差がつくのはそこではない。先に決めるべきなのは、何を読ませるかではなく、何を渡さないかだ。入力が広すぎると、AIは都合よく補完する。補完できないところまで勝手に埋めると、動きはしても安心して任せられない。
OpenAI の A Practical Guide to Building Agents でも、エージェントは機能を増やすほど複雑になりやすいので、ガードレールや評価を先に置くべきだと整理されている。OpenAI Frontier の Business Context も同じで、業務の文脈をつなぐ前提がないと、エージェントは組織の情報をうまく使えない。
最初に決めるのは「入力」ではなく「境界」
AIエージェントの入力設計は、入力欄を埋める作業ではない。境界を決める作業だ。
たとえば、顧客返信の下書きを作るAIエージェントを考える。必要なのはメール本文だけではない。案件の進捗、相手との関係性、直近のやり取り、送ってはいけない情報、社内承認の条件も必要になる。
ここで、全部を同じ重みで渡すとまずい。公開してよい情報と、内部だけで持つべき情報が混ざるからだ。OpenAI の プロンプトインジェクションに耐性のある AI エージェントの設計 でも、攻撃や誤誘導を防ぐには、入力の境界をはっきりさせることが重要だと示されている。
つまり、入力設計で先にやることは次の3つだ。
- 目的を決める
- 制約を決める
- 参照してよい文脈を決める
この順番を飛ばすと、どれだけ立派なプロンプトテンプレートを作っても、あとから壊れる。
AIエージェント 入力設計は3層で考える
入力を3層に分けると、現場でかなり扱いやすくなる。
| 層 | 役割 | 例 |
|---|---|---|
| 目的 | 何を達成したいかを決める | 「商談後の返信下書きを速く作る」 |
| 制約 | 何をやらないかを決める | 「外部送信しない」「金額変更しない」 |
| 参照文脈 | 何を見て判断するかを決める | 「直近メール」「案件メモ」「承認ルール」 |
OpenAI の Workspace agents では、共有された反復作業ほど、エージェントの得意領域になりやすいと説明されている。逆に言うと、共有されていない前提を勝手に読ませると、AIは外しやすい。
MCP の Resources と Tools を分ける発想も、入力設計のヒントになる。読むための文脈と、実行するための手段を混ぜないことだ。ここが曖昧だと、AIは「分かっているふり」をしやすい。
1. 目的
目的は、AIに何を勝ち筋とみなさせるかだ。
「要約して」とだけ言うと、要約は返る。だが、業務でほしいのは要約そのものではなく、次の判断に使える形だ。たとえば「返信の下書きを作る」「次アクションを3つに絞る」「人間が確認すべき点を先に列挙する」といった形にすると、実務に近づく。
2. 制約
制約は、AIが踏み越えてはいけない線だ。
ここを曖昧にすると、AIは出力を増やす方向に寄る。けれど業務では、出力が多いことより、危ない操作をしないことのほうが大事な場面が多い。たとえば、外部送信前に止める、承認が必要な更新はしない、機密情報は要約しない、といった線引きが必要になる。
OpenAI の Safety in building agents でも、ガードレールは完璧ではないが、最初の防波堤として有効だとされている。制約は「面倒だから省く」ものではなく、入力設計の芯だ。
3. 参照文脈
参照文脈は、AIが判断するために見てよい情報の集まりだ。
ここで重要なのは、文脈が多ければ多いほどよいわけではないことだ。OpenAI Frontier の Enterprise Frontier Program が示すように、業務文脈は接続先を増やすことより、何を信頼できる文脈として扱うかが先に来る。
実務では、次のように整理すると迷いにくい。
- 参照してよいもの
- 参照してはいけないもの
- 参照したうえで、AIが判断してよいもの
- 参照しても、最終判断は人間に戻すもの
この切り分けがないと、入力が増えるほど結果は不安定になる。
現場で使うなら、このテンプレートで十分
難しい理屈より、実際のテンプレートに落としたほうが早い。
目的:
このAIエージェントは何を速くするのか。
制約:
やらないこと、止める条件、承認が必要な操作は何か。
参照文脈:
どの情報を読んでよいか。どの情報は読ませないか。
出力:
AIは何を返すか。下書き、要約、候補、差分のどれか。
停止条件:
どの状態なら人間に戻すか。この5行があるだけで、AIエージェントの入力設計はかなり締まる。逆に、ここがないまま実装に入ると、「入力は入っているのに、なぜか業務に効かない」状態になりやすい。
OpenAI の A Practical Guide to Building Agents でも、エージェントは一度動けば終わりではなく、評価と改善のループが必要だとされている。だから入力設計は、実装前に終わる仕事ではない。評価しながら少しずつ 詰める仕事だ。
壊れやすいのは、入力が多いときではなく、曖昧なとき
AIエージェントの入力設計で怖いのは、情報量そのものではない。曖昧さだ。
たとえば、指示の中に「できれば」「なるべく」「適宜」が増えると、AIは空気を読む方向へ行く。人間同士なら通じる曖昧さでも、AIはその曖昧さを補完してしまう。補完の結果、想定外の文脈を拾うことがある。だから、AIエージェント 入力設計では曖昧さを減らすほど安定しやすい。
OpenAI の ChatGPT エージェント でも、ログイン情報や高リスク操作には注意が必要だと案内されている。これは単なる安全啓発ではない。入力の境界が曖昧なままだと、エージェントは危ない操作に寄るという実務上の話だ。
だから、入力設計では次の3点を先に固める。
- 目的は1文で書けるか
- 制約は反対側から読んでもブレないか
- 参照文脈は「見せるもの」と「見せないもの」に分かれているか
この3つが揃うと、AIエージェントはやっと「なんとなく賢い道具」から「業務の一部」になる。
Atsumellの視点
Atsumellが見ているのは、AIエージェントを増やすことそのものではない。AIが読める形に業務を整えることだ。
Kakusill の役割もそこにある。要件定義や設計書を、AIが理解しやすい構造へ正規化する。入力設計が弱いままエージェントを増やしても、文脈が散らばるだけで効きにくい。逆に、入力を3層で整理できると、AIエージェントはかなり扱いやすくなる。
関連する考え方としては、AIエージェント要件定義は評価設計から と 社内AIエージェントは権限設計から が近い。さらに、止め方まで含めて考えるなら AI社員の停止条件はどう決めるか もつながる。
入力設計は、派手さはないが効く。ここを詰めると、AIエージェントはようやく業務の中で安定して回る。
