本文へスキップ
SNAMO Logo
SNAMO
町工場の技術者が、ChatGPTなどのAIツール活用やプロンプトエンジニアリングを意識し、ソクラテス式対話を取り入れたAIエージェント用の入力フォームを設計している様子

AIエージェントへの依頼を整えた町工場の入力フォーム設計物語

19 min read

朝の光が青葉サービスのサポートデスクに差し込むころ、青木あおいの画面には、AIエージェントへの依頼が次々と並んでいた。「このお客様に丁寧に返事して」「必要なら返金もお願い」「急ぎで対応」。短い言葉の下には、対象のチケット番号も、参照する知識データも、返却する場所も書かれていない。

「この“お客様”は、どの問い合わせですか?」

隣の席の声に、あおいはServiceNowの画面を何度も開いた。AIエージェントは文章を整えるだけではない。顧客情報を探し、規程を読み、Outlookの下書きを作ることもある。けれど、自由記述の依頼では、実行する操作や権限、確認者まで毎回変わってしまう。あおいは、AIエージェントへの依頼を安全に標準化するには、目的や処理対象、トリガー、知識データ、出力形式を分けて入力できるフォームが必要だと感じ始めていた。

この記事の答え

  1. 結論AIエージェントへの依頼は目的や対象、権限、承認を分けた入力フォームで標準化する
  2. 根拠項目を分けて指定すれば誤参照や誤送信を防ぎ、依頼と承認の履歴も残せる
  3. 最初の一歩まず目的、対象、参照データ、出力、権限、確認者の入力欄を作る
01

第1章 空欄だらけのAIエージェント依頼フォーム

ServiceNowとOutlookの画面を確認する町工場のサポート担当者

第1章 空欄だらけのAIエージェント依頼フォーム - 本文

机の上で、問い合わせ画面が何枚も重なっていた。朝の光が青葉サービスのサポートデスクに差し込み、ServiceNowの通知が青く点滅している。あおいはマウスを握ったまま、ひとつの画面から次の画面へ目を走らせた。

依頼欄には、短い文が並んでいた。「このお客様に丁寧に返事して」「必要なら返金もお願い」「急ぎで対応」。どの文にも、問い合わせ番号や顧客名、参照する規程の場所は書かれていなかった。

あおいは、その依頼をAIエージェントに渡していた。問い合わせの内容を短くまとめ、返事の案を作る仕事だ。忙しい朝には、頼れる小さな助手のように思えていた。

「この“お客様”は、どのチケットですか?」

隣の席の健太が、画面をのぞき込んだ。あおいは返事をしようとして、指を止めた。依頼文のどこにも、対象を示す番号がなかった。

「えっと……今朝届いた、部品交換のお問い合わせです」

「今朝の問い合わせは、三件あります。名前が同じ会社のものもありますよ」

あおいはServiceNowの一覧を開いた。未対応の行がいくつも並び、同じ会社名の下に、納期遅れ、部品の破損、請求金額の確認が分かれている。通知の時刻だけを手がかりにして、ひとつずつ開いていった。

そのとき、AIエージェントから返事が届いた。画面には、問い合わせの要約と、Outlookで作られた返信の下書きが表示されていた。文章は丁寧で、冒頭には「このたびはご不便をおかけし」と書かれている。

けれど、本文の中央に、あおいの知らない一文があった。

「確認のうえ、返金手続きを進めます」

「返金は、まだ決めていません」

あおいの声が少し高くなった。依頼欄には「必要なら返金もお願い」とあるだけだった。返金の条件を定めた社内規程を読むように、とも、確認が必要な場合は下書きで止めるように、とも書かれていない。

健太が、下書きの宛先を見た。そこには、別の担当者が以前使った共有アドレスが入っていた。顧客への返信先なのか、社内確認用なのかも、画面だけでは分からない。

「このまま送信ボタンを押したら、誰に届きますか?」

「……分かりません」

あおいは慌ててOutlookの下書きを閉じた。ServiceNowのチケットをもう一度開くと、返金ではなく部品の再発送を求める記録が残っていた。AIエージェントは、別の問い合わせにあった返金の話を拾い、今回の返事に混ぜていたのだ。

「どうして、別の内容まで入ったの?」

「依頼の対象が決まっていないからかもしれません。AIは文章を直すだけでなく、必要なデータを探します。指定があいまいだと、似た情報をつないでしまうことがあります」

健太は、画面の二つのチケットを指で示した。片方は部品の破損、もう片方は請求金額の確認だった。会社名と担当者名が似ていたため、検索結果の近くに表示されていた。

あおいは、胸の奥がきゅっと縮むのを感じた。AIエージェントは、答えを返す箱ではない。顧客情報を探し、社内の知識データを読み、返信案を作り、設定によっては外部のツールを操作する。

「つまり、“丁寧に返事して”だけでは、足りないんですね」

「はい。どのチケットか。何を参照するか。どこまで実行してよいか。返事をどの形で返すか。それぞれ決まっていないと、毎回判断が変わります」

あおいは依頼欄を見つめた。ひとつの自由記述の箱に、目的も、処理する対象も、実行の指示も、してはいけないことも、欲しい出力も押し込んでいた。空欄が多いのに、書き込む場所だけは広すぎた。

別の通知が点滅した。「急ぎで対応」と書かれた新しい依頼だった。あおいはすぐに開かず、紙のメモを一枚取り出した。

「まず、“何をしたいか”を書く欄を作ります。それから、対象のチケット番号。参照する知識データ。AIに任せる操作と、止める条件も分けます」

健太がうなずいた。

「返信案だけなのか、Outlookの下書きまで作るのかも、選べるようにしましょう。送信は、確認する人が決まるまでできないように」

あおいは、白いメモの上に線を引いた。左側に「目的」、その下に「対象」。右側には「参照する情報」と「返す形式」と書いた。まだ項目は少なく、紙の余白が大きく残っていた。

画面の中では、さきほどの誤った下書きが静かに閉じられている。あおいは正しいチケットを開き、部品の再発送についての返信案を作り直した。今度は宛先も、参照した規程も、確認する担当者も、ひとつずつ見える場所に置いた。

02

第2章 「いつものお客様」が迷子になった朝

ServiceNowの返金案を確認するサポートデスク

第2章 「いつものお客様」が迷子になった朝 - 本文

朝の光が青葉サービスのサポートデスクに差し込んだころ、青木あおいは、AIエージェントへの依頼欄に「先ほどの返金問い合わせに、前回と同じように返事して」と入力した。急いでいたため、チケット番号も、対象のお客様の名前も書かなかった。

「これなら、すぐに返信案ができるはず」

あおいは、画面の送信ボタンを見ながら小さく息をついた。添付ファイルには、注文の明細とお客様とのやり取りが入っていたが、どのページを確認するのかも指定していなかった。

ServiceNowの中で、AIエージェントが動き始めた。過去の問い合わせを探し、似た言葉が並ぶ記録を見つけると、前回の対応例と返金規程を組み合わせて返信案を作った。画面には、ほどなくして「確認待ち」と表示された。

「もうできたんだ」

あおいが返信案を開くと、冒頭には丁寧なあいさつが並んでいた。文章は自然だったが、返金についての一文で、あおいの指が止まった。

「商品到着から三十日以内であれば、全額返金を承ります」

今回のお客様が申し込んだ契約には、その条件がなかった。返金できるのは、別の種類の契約だけだった。AIエージェントは、問い合わせの文章がよく似ていた別のお客様の記録を見つけ、その契約条件を今回の返信に使っていた。

あおいは、慌てて元の画面に戻った。検索結果には、いくつものチケットが並んでいたが、どれが今回の問い合わせなのかを示す印はなかった。添付ファイルの中にも、契約番号が複数あり、見るべき場所を決める手がかりは少なかった。

「この“前回”は、どの前回ですか?」

隣の席の佐伯が、画面をのぞき込んだ。あおいは、「先月の似た問い合わせです」と答えかけて、言葉を止めた。似ているだけでは、同じお客様とは限らない。

「たしかに、これではAIが迷っても不思議ではないですね」

佐伯は、返信案の下にある操作履歴を指した。AIエージェントは、ServiceNowの問い合わせを検索し、顧客情報と契約データを参照していた。文章を整えただけではなく、次に使う情報まで自分で選んでいた。

そのとき、返金担当の美咲が席へ来た。彼女はOutlookの下書き画面を開き、作られた返信案を見て眉を寄せた。

「これは、返信を作るだけですか? それともOutlookから送信までしてよいのですか?」

「あ……依頼には、そこまで書いていません」

あおいは入力欄を見返した。目的は「返事をする」とだけ書かれていた。対象のチケット番号も、参照してよいデータも、AIエージェントが使える機能も、誰が最後に確認するのかも書かれていなかった。

「送信まで任せるなら、間違った相手にメールが届くかもしれません。下書きだけなら、人が確認してから送れます」

美咲の声は静かだった。けれど、その言葉は机の上に置かれた重い箱のように、みんなの間へ落ちた。

あおいは、返信案をもう一度見た。文章だけなら、前回の例に近くても問題はないかもしれない。だが、顧客情報を探し、契約条件を読み、返金の案内を作り、Outlookへ渡すまでを任せるなら、どこまで動いてよいかを先に決めなければならない。

「AIが速くても、確認する場所が増えたら、仕事は軽くなりませんね」

佐伯がそう言うと、あおいはうなずいた。AIエージェントが参照するデータ、使えるツール、実行できる操作、返す形が決まっていない。速さより先に、人が確かめる作業が増えていた。

あおいは、送信ボタンの上で止めていた指をゆっくり離した。今回の返信は、送らずに済んだ。けれど、サポートデスクには「このままでは任せられない」という空気が広がった。

午後になっても、誰も次の依頼をAIエージェントへ渡そうとはしなかった。あおいは、空白の多い入力欄を見つめながら、紙に四つの言葉を書いた。「目的」「対象」「参照する情報」「返すもの」。その下に、「実行してよいこと」と「人が確認すること」を加えた。

「自由に書くのではなく、最初から分けて聞けばいいのかもしれない」

あおいの声に、佐伯と美咲が顔を上げた。まだ、どんな画面にすればよいのかは分からない。それでも、迷子になった“いつものお客様”を、今度は正しく見つけられる道を作ろうと、あおいは初めて思った。

03

第3章 始まる合図をフォームに描く

Copilot Studioを使いAI依頼フォームを設計する会議室

第3章 始まる合図をフォームに描く - 本文

牧野は、Copilot Studioの画面を映したノートパソコンと、白いホワイトボードを会議室の机に並べた。あおいは、AIエージェントが動き始める条件を、初めて一つずつ言葉にしようとしていた。

「今日は、何でもできる担当者を作る日ではありません。条件がそろった依頼を、安全に処理する担当者を作ります」

牧野がボードの中央に、ひとつの依頼を書いた。

「返金について調べて、お客様への返信案を作る」

その短い一文から、牧野は線を四方へ伸ばした。

「まず、目的・期待成果です。何を達成するのか。誰が使うのか。何ができたら成功なのかを書きます」

あおいは画面に入力欄を作った。「問い合わせ担当者が、返金規程に沿った返信案を確認できること。お客様に送る前の下書きができれば成功」と入力する。

「次は、依頼内容。実行すること、条件、禁止事項、優先順位を分けます。たとえば、返金額を勝手に確定しない。規程にない判断は、担当者へ戻す。返信案を作る前に、契約条件を確認する、です」

ボードには、赤い線で「送信しない」と書かれた。

あおいは少し迷ってから、処理対象の欄に移った。ServiceNowのチケット番号、顧客情報、添付された注文書、問い合わせにひもづく契約レコードを、別々の入力欄にする。

「ここを自由記述に戻したら、また“このお客様”になりますね」

「そうです。対象は、名前ではなく、確かめられる番号で指定します。添付ファイルも、全部ではなく、選んだものだけを渡します」

次に牧野は、ボードの上に小さな丸を描いた。

「これはトリガーです」

「トリガー?」

「AIエージェントが動き出す合図です。担当者がボタンを押すのか、新しい問い合わせの登録をきっかけにするのかを決めます。今回は、担当者が確認してから押すボタンにしましょう」

あおいは、フォームの下に「依頼を実行する」というボタンを置いた。問い合わせが登録されただけでは、AIは動かない。チケット番号と対象顧客がそろい、担当者が押したときだけ始まる仕組みだ。

「知識・データも必要です」と牧野が続けた。「参照する場所、更新日、使ってよい範囲、アクセス権を書きます」

あおいは、返金規程の保存場所をSharePointに指定し、契約データは対象チケットの顧客に限ると記した。古い規程を参照しないよう、「最新版を優先し、更新日を出力に含める」と依頼内容にも加えた。

牧野はCopilot Studioの指示欄を開き、Google Cloudの構造化プロンプトの例を見せた。データと指示を区切る考え方を使い、フォームの項目も混ざらないように整える。

「自由な文章をなくす必要はありません。ただ、データと指示を同じ箱に入れないことが大切です」

さらに、ツールと権限の欄が加わった。ServiceNowは読み取りまで。Outlookは下書きの作成まで。送信、返金処理、契約情報の更新は許可しない。

あおいが「必要なら返金もお願い」と入力しようとすると、牧野がそっと手を止めた。

「“必要なら”は、誰が決める言葉ですか?」

「……担当者、です」

「では、AIには返金条件を表示させるだけにします。承認は人が行います」

フォームの最後に、出力形式・品質基準を置いた。返信案、参照した規程名と更新日、判断できない項目、エラー内容を、決めた順番で返す。根拠が見つからないときは、「確認が必要」と表示し、推測で埋めない。

結果を返す場所は、チャネルで指定した。最初はサポート画面だけ。メール本文へ直接入れず、Outlookには下書きのリンクだけを返す。

「人間の関与とガバナンスも、入力欄にしましょう」

牧野は確認者、承認条件、履歴、変更理由の欄を加えた。誰がボタンを押し、誰が下書きを確認したかが、依頼の履歴に残るようにする。

「ここまで分けると、複数のエージェントに任せたくなりますね。分類担当、検索担当、返信担当、と」

あおいがそう言うと、牧野は首を横に振った。

「先に一つで試します。分類の入力は何か。検索の出力は何か。最後に残す成果物は何か。それが見えないまま、エージェントをつなぐと、どこで間違えたか分からなくなります」

二人は、ひとつのエージェントに、分類、情報検索、返信案の作成だけを設定した。依頼フォームから渡す入力は、チケット番号、対象レコード、添付ファイル、参照範囲、出力形式に絞った。

最初のテストで、あおいはチケット番号を空欄のままボタンを押した。画面は動いたが、ServiceNowの検索結果には似た顧客名がいくつも表示された。

「止めるべきでした」

「今、止まりました。成功です」

牧野が画面を指した。エージェントは検索を実行せず、「処理対象のチケット番号が必要です」と返していた。あおいは必須設定を確認し、顧客名だけでは送信できないよう入力形式を変えた。

二度目のテストでは、返信案がOutlookの下書きに作られた。しかし、規程の更新日が本文の末尾に置かれ、担当者が見落としそうだった。

「品質基準に、位置まで書きましょう」とあおいが言った。「最初に結論。次に根拠。最後に確認が必要な点です」

牧野は出力欄を直し、もう一度実行した。画面には、対象チケット、返金可否の根拠、規程の更新日、確認者の名前が順番に並んだ。Outlookには送信されていない下書きだけが残った。

会議室の窓から、夕方の光が差し込んだ。あおいは、フォームの先頭にある「自由記述」欄を小さくし、その隣に「目的」「対象」「合図」「参照先」と書かれた箱を並べた。

「AIに何でも頼むのではなく、頼める形にしてから渡すんですね」

「ええ。依頼が整えば、AIも人も、次に何を確認するか分かります」

翌朝、サポート画面には新しい依頼フォームが開いていた。あおいがチケット番号を選び、確認者を指定し、ボタンを押すと、エージェントは決められた範囲だけを読み、送信前の返信案を静かに返した。

04

第4章 権限を一つずつ置いていく

Copilot Studioの入力フォームと確認画面を見つめる町工場の担当者

第4章 権限を一つずつ置いていく - 本文

入力フォームの運用が始まってから、青葉サービスの朝の空気は変わった。以前は、自由記述の短い依頼が画面に並び、あおいはServiceNowの中を何度も行き来していた。今は、依頼が届く前に、必要な情報がそろう仕組みになっている。

あおいはCopilot Studioを開いた。画面には、達成したい成果、対象ユーザー、成功基準、実行指示の欄が並んでいる。その下には、処理対象、開始条件、知識データ、利用可能なツール、実行前の確認、返却チャネルが続いていた。

「前は、“顧客対応よろしく”の一言で始まっていたんですよね」

隣で牧野がうなずいた。あおいは、以前の画面を思い出した。対象チケットが分からず、どの返金規程を見るかも決まらず、返信を誰が確認するかも、そのたびに人へ聞いていた。

「今は、成果を“返信案を作成する”と選びます。対象はサポート担当者。成功基準は、対象チケットと一致し、参照元が表示され、必須項目がそろうことです」

その日の依頼は、返金についての問い合わせだった。あおいは対象チケットを指定し、顧客情報と添付ファイルを確認対象にした。開始条件は担当者による起動で、知識データには社内ナレッジ、返金規程、契約情報を登録し、それぞれの更新日時と利用範囲も選んだ。

利用できるツールは、ServiceNowの検索と社内ナレッジの参照、それからOutlookの下書き作成だけだった。外部送信、返金処理、顧客情報の変更には、実行前の確認が必要だと画面に表示されている。あおいはその表示を見て、肩の力が抜けるのを感じた。

AIエージェントが返した内容は、自由な文章ではなかった。返信案、参照元、確認が必要な点、実行状態が決められた項目に収まり、JSON Schemaで指定した型と許容値に沿っていた。空欄のまま進めてよい項目と、人の確認が必要な項目が、同じ画面で見分けられた。

「これなら、返事の中身だけでなく、どこを見て作ったかも確認できますね」

牧野はOutlookの下書きを開いた。文面は作られていたが、送信ボタンを押せる状態ではない。Entra IDの権限とフォーム上の操作範囲を読み取りと下書き作成に絞ったため、AIエージェントが顧客へ直接送ることはできなかった。

以前なら、下書きを見つけた人が、そのまま送る可能性もあった。今は、確認が必要な点に返金条件が示され、担当者が内容を確かめてから次へ進む。会話の中で曖昧さを埋めるのではなく、フォームの前で曖昧さが見えるようになっていた。

午後には、新しい依頼が入った。担当者が対象チケットを選ばずに送信しようとすると、画面に静かな案内が出た。

「対象チケットを指定してください。参照する知識データと、実行してはいけない操作も入力してください」

あおいはその文を見て、最初のテストで自分が入力した言葉を思い出した。指示欄を必須にし、対象チケットを別の欄に分け、禁止事項と優先順位を独立させた。その小さな変更が、依頼の入口で迷いを止めていた。

フォームの状態も記録されるようになった。DraftからReview、Approved、Deployedへ進むたびに、変更日、承認者、変更内容が履歴に残る。誰かの記憶に頼っていた運用が、あとからたどれる記録に変わっていた。

牧野は画面の流れを声に出して確かめた。入力された依頼を読む。対象情報を確認する。知識データを参照する。返信案を作る。そして、人間に確認を求める。順番が一つずつ見えると、AIエージェントの動きも、担当者の役割も落ち着いて見えた。

夕方、サポートデスクに残る依頼は、以前のような短い言葉の山ではなかった。対象と目的を持ち、参照元と返却先を備えた依頼が並んでいる。あおいは画面を閉じる前に、Outlookの下書きと確認欄をもう一度見た。

「“よろしく”だけでは届かなかったものが、今はちゃんと手渡せますね」

牧野は小さく笑った。AIエージェントに任せる範囲を狭めたことで、人が確認する場所がはっきりした。青葉サービスのサポートデスクには、急いで答えを出す空気ではなく、確かめてから進める静かな安心が広がっていた。

05

第5章 確認欄のそろった返信

ServiceNowとOutlookの返信案を確認するサポート担当者

第5章 確認欄のそろった返信 - 本文

朝のサポート画面に、新しいフォームから依頼が届いた。AIエージェントは、対象チケットの確認から返信案の作成までを終えている。あおいは、迷わず承認画面を開いた。

フォームの上には、依頼の道筋が静かに並んでいた。対象はServiceNowのチケット番号、目的は返金に関する問い合わせへの返信、参照先は社内ナレッジと返金規程、禁止事項は返金処理と外部送信、返却先はOutlookの下書き欄だった。

「これなら、最初に見る場所がわかるね」

あおいが画面を下へ動かすと、AIエージェントが読んだチケットは一件だけだった。別の顧客情報や、似た問い合わせを勝手に広げて読むことはない。フォームに書かれた対象の範囲が、細い線のように処理を導いていた。

出力欄も、ひとつの長い文章にはなっていなかった。問い合わせの分類、要約、参照した情報、返信案、判断できない点、承認の要否が、別々の欄に分かれている。あおいは、文章の中から大切な箇所を探し回らずに済んだ。

参照情報の欄には、社内ナレッジの記事名と返金規程の該当箇所が表示されていた。返信案には、「規程上、返金の可否は確認が必要」と書かれている。判断できない点には、購入日の記録がチケット内にないことが残っていた。

「わからないところを、わからないまま置いてくれている」

あおいは、少しだけ肩の力を抜いた。AIエージェントは返金を実行していない。顧客へのメールも送っていない。Outlookには、返信案が下書きとして置かれ、画面の端には確認待ちと表示されていた。

隣の席では、亮が別のフォームを開いていた。対象には別のチケット番号を入れ、依頼のきっかけには「解約希望の連絡」を選んでいる。返却先は同じOutlookでも、参照する規程と、確認を求める担当者が違っていた。

「同じフォームなのに、動く範囲が変わるんだね」

「うん。何をきっかけに動くかと、どのデータを見るかを変えているの。形は同じだから、確認する順番は迷わないよ」

亮の画面にも、分類と要約が現れた。けれど、解約に関する依頼には、別の承認者が表示されている。フォームは依頼を小さな箱に閉じ込めるのではなく、必要な道だけを選び直していた。

あおいは自分の画面に戻った。対象はこの顧客だけ。参照先はこの規程だけ。処理したのは返信案の作成までで、禁止された操作はしていない。最後の送信を決めるのは、画面の向こうの人だった。

承認ボタンが、静かに点灯している。あおいは返信案を読み、判断できない点を担当者への確認文に直した。それから、ボタンを押してOutlookの下書きを顧客へ送信した。

送信後、依頼内容と承認者の名前が履歴に残った。いつ、どのチケットを対象にし、どの情報を参照し、どこまでAIエージェントが処理したのかも、同じ画面でたどることができた。

昼前になっても、サポートデスクに慌ただしい声はなかった。新しい依頼が届くたび、あおいはフォームの欄を上から順に確かめた。画面に差し込む光は、朝の青さから、机の上の紙をやわらかく照らす色へ変わっていた。

「前は、文章の中で迷っていたんだね」

あおいはそうつぶやき、次の依頼の対象チケットを選んだ。空欄のないフォームと、確認を待つ返信案が、静かな画面に並んでいた。

06

第6章 朝のフォームに残る足あと

ServiceNowの入力フォームを囲む町工場のサポートデスク

第6章 朝のフォームに残る足あと - 本文

朝の光が、青葉サービスのサポートデスクにやわらかく差し込んだ。以前なら、あおいの画面には短い頼み事が重なっていた。今はServiceNowの同じ入力フォームが、机の上の小さな道しるべになっている。

依頼欄には、「対象」「目的」「開始条件」「参照先」「権限」「出力形式」が並んでいた。対象にはチケット番号を入れる。参照先には規程や知識データを選ぶ。出力形式には、返信案やOutlookの下書きなど、次に受け取る形を指定する。

「前より、画面が静かですね」

入ったばかりの水野が、フォームを見ながら言った。あおいはうなずき、空欄の少ない画面を指でなぞった。

「会議の要約だけなら単一モデルの処理でよさそうです」

「外部ツールを使うなら、単一エージェントにします」

隣で佐伯が答えた。「ひとつの担当が、決められた範囲でツールを使います。要約だけなら文章をまとめる処理で足りますが、予定表を読んだり、下書きを作ったりするなら、実行する担当が必要です」

水野は「なるほど」と言い、開始条件の欄に「会議終了後」と入力した。フォームの裏側には、項目の型や必須条件を決めるJSON Schemaがある。だから、必要な欄が抜けると、画面がやさしく止めてくれる。

次の依頼は、市場調査だった。検索をする担当、情報を比べる担当、報告書を整える担当に分けるため、フォームにはそれぞれの入力と出力が表示された。最終成果物は「調査報告書」と書かれ、人間が確認する場所には、出典と判断の欄が置かれていた。

「ソフトウェア開発の依頼も、同じように書けます」

水野が言った。「仕様を読む担当、コードを作る担当、テスト結果を見る担当。最後に、人が確認してから提出する、と」

「そうです。マルチエージェントにするなら、役割と順序も決めます」

あおいは画面を開いた。「エラーが出たら、前の担当へ戻す。三回戻ったら止める。どこまでも繰り返さないように、戻り先と終了条件を先に置きます」

フォームの選択肢には、入力と出力の組み合わせが残った。誰が何を渡し、次の担当が何を返すのかが、細い線のようにつながっている。人間の確認欄には、必要なところだけ赤い印がついていた。

しばらくして、佐伯が「急ぎでお願い」と入力しかけた。けれど、その下には対象チケットも、希望する出力形式も入っていなかった。画面の案内が、空いている二つの欄をそっと囲んだ。

「急ぎ、だけでは始められないんですね」

「急ぐからこそ、何を急ぐのかを残します」

佐伯はチケット番号を選び、「返信案を作成」と入力した。開始条件には「本日十六時までに承認」と入れ、送信前の確認欄を開いた。

あおいは履歴の画面を確認した。昨日、権限の項目を変えた人の名前が残っている。その変更を承認した人も、参照先を追加した時刻も、ひとつの記録に並んでいた。依頼はもう、声だけで渡す頼み事ではなかった。

「誰が変えて、誰が確かめたか。あとから見ても分かります」

あおいはそう言って、送信前の確認欄を閉じた。次の依頼フォームを開くと、画面の左には昨日の変更履歴、右には今日の新しい依頼が並んだ。

そのとき、小さな通知音が鳴った。AIエージェントの処理が終わった合図だった。画面には整えられた返信案と参照先が表示され、その下で、人間の承認を待つ欄だけが静かに光っていた。あおいは手を止め、朝の光の中で、ひとつずつ内容を確かめた。

関連キーワード

AIエージェント
入力フォーム
自由記述
ServiceNow
Outlook
入力フォーム設計
返金問い合わせ
Copilot Studio
ガバナンス
JSON Schema

著者について

鈴木信弘(SNAMO)

鈴木信弘(SNAMO)- 静岡県を拠点に活動する総経験19年のフルスタックエンジニア。AI時代の次世代検索最適化技術「レリバンスエンジニアリング」の実装者として、GEO(Generative Engine Optimization)最適化システムを開発。2024年12月からSNAMO Portfolioの開発を開始し、特に2025年6月〜9月にGEO技術を集中実装。12,000文字級AI記事自動生成システム、ベクトル検索、Fragment ID最適化を実現。製造業での7年間の社内SE経験を通じて、受注システム自動化による業務時間の短縮や検品作業のデジタル化など、現場の課題を技術で解決してきた。富山大学工学部卒、基本情報技術者保有。

プロフィールを見る

よくある質問

Q1AIエージェントへの依頼を自由記述だけで行うと、どのような問題が起きますか?
依頼の目的や対象、参照する情報、実行権限、確認者などが曖昧になり、別の問い合わせ情報や顧客の契約条件を誤って参照する可能性があります。その結果、誤った返金案の作成や誤送信につながるおそれがあります。
Q2AIエージェント用の入力フォームには、どのような項目を設けるべきですか?
少なくとも、依頼の目的、対象、トリガー、参照データ、実行権限、出力内容、確認者や承認者を分けて入力できるようにします。必要に応じて、禁止事項や監査・履歴に関する項目も設けます。
Q3AIエージェントが別の顧客情報を参照してしまうのはなぜですか?
自由記述の中で対象となる顧客や問い合わせが明確に指定されていなかったり、参照してよい情報の範囲が定義されていなかったりするためです。対象と参照データをフォーム上で明確に分けることで、誤参照を防ぎやすくなります。
Q4AIエージェントに実行権限を持たせるときの注意点は何ですか?
AIエージェントがどこまで実行できるのかを明確にし、返金案の作成と実際の返金処理、返信案の作成と送信などを区別することが重要です。送信や処理の実行前に、人が内容を確認・承認する仕組みも必要です。
Q5AIエージェントの出力を人が確認する際は、何を確認すべきですか?
対象となる顧客や問い合わせが正しいか、参照情報が適切か、禁止事項に触れていないか、依頼した目的に沿った内容かを確認します。特に、返金条件や返信内容など、顧客対応に直接影響する部分は承認者が確認してから実行します。
Q6AIエージェントへの依頼履歴や承認履歴を残すメリットは何ですか?
どのような依頼を行い、AIエージェントが何を出力し、誰が確認・承認したのかを後から確認できます。誤りが起きた場合の原因調査や再発防止にも役立ち、担当者が安心してAIエージェントを利用できるようになります。
Q7AIエージェントの入力フォームを導入する際、どのようにテストすればよいですか?
正しい対象を指定したケースだけでなく、対象が曖昧なケース、別顧客の情報が混在するケース、権限外の処理を依頼するケースなどを用意して検証します。AIエージェントが対象確認や承認待ちを適切に行い、依頼と結果の履歴が残るかも確認します。