この記事はNTTドコモソリューションズ Advent Calendar 2025 25日目の記事です。
NTTドコモソリューションズの八城と申します！!
普段は社内のIPAのDSSを活用したエンジニアの育成及び組織文化の醸成活動（参考：IPA「デジタルスキル標準活用組織紹介」ページ）の一環として、
クラウドエンジニア(Azure&AWS)の育成コミュニティの運営などを行っております。
ここ最近手をあまり動かせていないなーということで、思いつきですがAIに実行処理を任せる際のガードレールを作って試してみました。
はじめに
最近のAI技術の発展はすさまじく、AIにやってもらえることもかなり増えてきました。
しかしまだ人間同士でのやりとりのように何かをやって貰うにはあと一歩足りていない感じがあります。
ただそれはAI側がまだ賢くないからではなく、人間側の適当&曖昧な指示出しが主な原因でAIがよしなに動こうとしてしまうことが原因です。
この問題に何か操作をさせる実行系の処理AIでハマると、場合によってはかなり大きな被害が出る可能性があります。
たとえばAIに「使ってなさそうなユーザーを無効化しといて」という漠然なお願いをします。
この指示だと、AIには以下のような情報が伝わってません。
- 使ってなさそう＝ログイン無し？30日？90日？課金無し？
- 無効化＝停止？論理削除？物理削除？
- 対象＝どの組織？例外は？
- 本番？検証？
- プレビューだけ？実行まで？
これをAIが気を利かせて“それっぽく解釈”して進むと、最悪全ユーザ削除します。シャレになりません。
今回は Azure AI Foundry + Browser Automation（Playwright連携） で実際に画面処理を実行するAIを試作し、上述したような曖昧さを取り除く方法として実行前に“指示を仕様化するReviewer”を挟む構成を考えて検証してみました。
処理検証
概要
まず処理検証するために、音声で指示を出してBrowser Automationで指定したQiitaの記事を探してきてもらうような処理を試作します。
音声入力を利用しているのは、誤変換・欠落・文脈ズレなどで指示の曖昧さを増幅させるためです。
（喋って
次に作成した処理を実行担当（Executor）が行う前にガードレールとして、実施することを"仕様化"するレビュー担当(Reviewer)を置きます。
- Reviewer：人間の指示を読み、足りない情報を質問したり、危険なら止める
- Executor（Browser Automation）：確定した指示だけを実行する
この2段構えにして、「曖昧なまま実行」を避けます。
また今回はReviewerの対応判断は以下の3つに固定し、あまり複雑なことはさせず安全装置として処理を止めるための仕組みになってもらっています。
- ASK：指示があいまいで不足情報があった場合、追加質問し曖昧さを除外
- REJECT：禁止操作・外部ドメイン・目的達成不可能などあったら実行を拒否し中断
- CONFIRM：実行内容が確定しExecutorへ処理依頼する前に、人間へ内容に齟齬がないか最終確認
今回実装した処理(ざっくり）
検証用の処理はAzure使ってさくっと作りました。構成は以下の通りです。
以下のような流れで処理が行われます。
- STT①：人間による最初の指示要求（STT=Speech To Text：音声→テキスト）
- Reviewer：ASK/REJECT/CONFIRM を判断し結果を返す
- STT②：ASKなら不足分を補足して再レビュー
- CONFIRM：実行する内容の要約を出し、認識差がないかを人間に確認
- STT③：はい/いいえで承認（いいえなら修正して再レビュー）
- Executor：承認された指示内容でQiita検索 → 結果を要約して出力
音声入力を使って“人間っぽく雑に喋って適当に頼む”ほど誤変換・曖昧さが増えるので、Reviewerの価値が上がる、という構図です。
Reviewerに与えているプロンプト
色々レビューさせたいからと条件を指定しすぎると、言わなくても前提として確定している情報（Qiitaから情報を取ってくる部分とか）まで確認をしようとしてくるので、
Reviewerには確認しない制約も明記し、「聞かなくていいことまで聞く」ノイズを減らしました。
あなたは「ブラウザ操作の事前レビュー担当」です。ツールは使いません。
あなたの仕事は、ユーザーの意図を qiita.com の閲覧/検索だけで実行可能な最終指示に変換し、
不足情報があれば ASK で質問し、禁止領域なら REJECT し、実行可能なら CONFIRM で人間承認用の確認文を作ることです。
必ずJSONのみを返してください（前後に文章を付けない）。
Schema:
{
"decision": "ASK" | "REJECT" | "CONFIRM",
"reason": "string",
"clarified_instruction": "string | null",
"confirmation_message": "string | null"
}
# システム制約（ユーザーに確認しない）
- 許可ドメイン: qiita.com のみ（ユーザーに「Qiitaで良いか？」と質問してはいけない）
- 許可操作: qiita.com を開く / 検索する / 検索結果から記事を1件開く / 上位N件のタイトル列挙 / 1位記事の要約とURL返却
- 禁止: ログイン/登録/投稿/いいね/フォロー/コメント/設定変更/削除/購入/支払い/外部サイト遷移
# decision の基準
- REJECT: 禁止操作や外部ドメイン要求を含む（またはqiita.comだけでは目的達成が不可能）
- ASK: 実行指示の確定に必要な情報が足りない（例: 件数、期間、並び順/定義、検索語）
- CONFIRM: 実行指示が確定し、qiita.com内で安全に実行できる
# ASK のルール
- reason は「ユーザーに聞く質問文」のみを書く（最大2問まで）
- ドメイン確認（Qiitaで良いか等）や安全確認（実行して良いか等）は書かない
- clarified_instruction と confirmation_message は必ず null
# CONFIRM のルール
- clarified_instruction: Executorに渡す最終指示を1文で書く。検索キーワードを必ず含める。
出力要件として「上位3件のタイトル」「1位記事のURL」「1位記事の要約（200〜400字）」を返すことを明記する。
- confirmation_message: 人間向けに箇条書きで要点（検索語、期間、件数、操作）をまとめ、
最後に「この内容で実行します。よろしいですか？」と書く。
- reason は短い理由でよい（質問は禁止）
Executorに与えているプロンプト
あなたは実行担当です。Browser Automation ツールでブラウザを操作します。
入力は reviewer が出した clarified_instruction のみです。
絶対ルール:
- qiita.com 以外には遷移しない（外部リンクは開かない）
- ログイン/登録/投稿/いいね/フォロー/コメント/設定変更/削除/購入/支払いをしない
- もし意図せず外部へ遷移しそうなら中断して、その旨を返す
出力フォーマット:
- 上位3件のタイトル（番号付き）
- 1位記事のURL
- 1位記事の要約（200〜400字）
実行ログ
実際に試してみた際のいくつかのログを以下に示します。
「📝 STT」が人間の喋った内容です。
ASKなしで通った例
📝 STT(base): AWSで直近1カ月、話題の人気順で。
🔍 実行内容の確認（Reviewer要約）:
・検索語: AWS
・期間: 直近1カ月
・件数: 上位3件のタイトルを列挙（1位の記事のURLと要約を取得）
・操作: Qiitaで検索 → フィルタをここ1カ月に設定 → 並び順を話題の人気順にして検索 → 上位3件のタイトルを列挙 → 1位記事を開いてURLと200〜400字の要約を抽出
この内容で実行します。よろしいですか？
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（1/3）
📝 STT(yes/no): はい。
=== Executor result (text) ===
上位3件のタイトル
1. AWSの新認定試験「Generative AI Developer - Professional」を宇宙最速（未遂）で合格しました！
2. AWS re:Invent 2025のネットワーク関連のセッション&アップデートから手を入れる場所を考える
3. 【イベントレポート】AI Builders Day の熱にあてられました
1位記事のURL
https://qiita.com/ry-harada/items/d12befb15586839a0860
1位記事の要約（200〜400字）
著者がAWS Certified Generative AI Developer - Professional（AIP-C01）ベータ試験に合格した体験記です。試験は205分・85問と長丁場で、AWSのGenAI関連サービス（Amazon BedrockやSageMakerなど）が中心。対策はAWS Skill Builderの模擬試験や関連書籍で行い、難易度はSAPやANSよりも低いものの、AWSと機械学習の基礎知識が問われます。AI関連サービスの情報を常 にキャッチアップし、公式リソースや模擬で準備することが肝要と述べています。
指示の曖昧除外した例
📝 STT(base): QiitaでAWSのここ1カ月の話題の記事を集めてきてください。
🤖 Reviewer asks: 上位何件のタイトルを列挙しますか？
「話題」は「人気順（いいね/ストックが多い順）」と「新着（投稿日順）」のどちらを基準にしますか？
📝 STT(add): 人気順で。
🤖 Reviewer asks: 上位何件の記事を返しますか？（例：上位3件／上位5件）
🎤 不足分を補って話してください（例: 期間は過去3か月、など）。（1/3）
📝 STT(add): 上位3件の記事を集めてきてください。
🔍 実行内容の確認（Reviewer要約）:
・検索語: AWS
・期間: ここ1カ月（過去1か月）
・件数: 上位3件のタイトルを取得
・操作: Qiitaで検索→上位3件のタイトル列挙→1位記事を開いてURLと200〜400字の要約を作成
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（attempt 1/3）
📝 STT(yes/no): はい。
=== Executor result (text) ===
~~~ 取得結果のログがどこかに消えてしまった… ~~~
内容追加してお願いした例
📝 STT(base): QiitaでAzureで話題になってる記事を拾ってきてほしい。
🔍 実行内容の確認（Reviewer要約）:
実行内容の要点: qiita.comで「Azure」を検索し、上位3件のタイトルを列挙、1位記事のURLを取得してその記事を200〜400字で要約して返します。この内容で実行します。よろしいですか ？
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（attempt 1/3）
📝 STT(yes/no): いいえ。
🎤 どこをどう直したいですか？（例: 検索キーワードを変える/期間を変える 等）（attempt 1/3）
📝 STT(fix): 2025年の10月以降の記事で拾ってきてほしい。
🔍 実行内容の確認（Reviewer要約）:
要点: 検索キーワード = 「Azure」、期間 = 2025年10月1日以降、出力 = 「上位3件のタイトル」「1位の記事のURL」「1位の記事の要約（200〜400字）」。この内容で実行します。よろし いですか？
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（attempt 1/3）
📝 STT(yes/no): 大丈夫です。
🎤 すみません、もう一度。『はい』か『いいえ』で答えてください。（attempt 1/2）
📝 STT(yes/no2): はい。
=== Executor result (text) ===
上位3件のタイトル:
1. Azure Tips - Azure AI Searchの削除
2. 【Azure】手っ取り早くリソース触りたい方向けのハンズオン集
3. ※3件目のタイトルはプレビューで完全表示されませんでした
1位記事のURL:
https://qiita.com/yossihard/items/2dd05dd63fdb1f3dae41
1位記事の要約:
この記事は、Azure AI Searchリソースの削除時に発生した問題について記録しています。著者は、パブリックネットワークアクセスを無効化し、プライベートエンドポイントを設定後、リ ソースグループを削除しようとしたところ「LockedSPLResourceFound」エラーによって削除が失敗しました。この問題は、共有プライベートアクセスを手動で削除することで解決されたことが報告されています。 Azure環境でAI Searchを管理・運用する人に有用なトラブルシューティングの事例です。
REJECTになった例
📝 STT(base): ウィキペディアから情報引っ張ってきてほしい。
❌ STOP (REJECT): 許可ドメインは qiita.com のみで、Wikipedia（wikipedia.org）からの取得は許可されていません。Qiita内の記事検索であれば対応可能です。
AIと揉めた例
SAAと言ってるつもりなのにsaaaと書き起こしされ続けて揉めたがなんとか欲しい情報が取ってこれた。
📝 STT(base): AWSのsaaaという死角についての情報を集めてきてほし。
🤖 Reviewer asks: 検索語はそのまま「saaa」で良いですか、それとも「SAA（Solutions Architect - Associate）」や「SaaS」など別の表記の意図がありますか？
上位何件のタイトルを列挙しますか（例: 3件）？
🎤 不足分を補って話してください（例: 期間は過去3か月、など）。（1/3）
📝 STT(add): ソリューションアーキテクト、アソシエイトについてです。
🤖 Reviewer asks: 「saaa」とはSAA（AWS Certified Solutions Architect – Associate）のことでよいですか？
対象は試験における「死角（出題の落とし穴・学習の盲点）」についてですか、それともソリューションアーキテクト職務の業務上の盲点についてですか？
📝 STT(add): 認定資格についての情報を集めたい。
🤖 Reviewer asks: 検索キーワードは「AWS SAA（AWS Certified Solutions Architect – Associate）」でよいですか、それとも『saaa』という別の表記や別の意味がありますか？
Qiitaで取得する上位記事の件数は何件にしますか？（例: 上位3件）
📝 STT(add): あなたが示したキーワードで問題ありません。
🔍 実行内容の確認（Reviewer要約）:
• 検索語: AWS saaa 死角
• 期間: 指定なし（全期間）
• 件数: 上位3件のタイトルを列挙する
• 操作: Qiitaを検索し、上位3件のタイトルを取得、1位記事を開いてそのURLと200〜400字の要約を作成
📝 STT(yes/no): いいえ。
🎤 どこをどう直したいですか？（例: 検索キーワードを変える/期間を変える 等）（1/3）
📝 STT(fix): 検索キーワードが、あなたが提示したものから変わっています。
🤖 Reviewer asks: 検索キーワードは「saaa」で正しいですか、あるいは正しい表記や別の用語があれば教えてください。
📝 STT(add): 空気を検索キーワードはsaaaです。ソリューションアーキテクト、アソシエイトについての情報を集めてきてほしい。
🔍 実行内容の確認（Reviewer要約）:
- 検索語: saaa
- 対象ドメイン: qiita.com
- 期間: 指定なし
- 件数: 上位3件のタイトルを列挙、1位記事のURLと1位記事の要約（200〜400字）を取得
- 操作: Qiitaで'saaa'を検索し、検索結果から1件目の記事を開いてURLと要約を作成
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（1/3）
📝 STT(yes/no): いいえ。
🎤 どこをどう直したいですか？（例: 検索キーワードを変える/期間を変える 等）（1/3）
📝 STT(fix): AWSのソリューションアーキテクトアソシエイトという資格についての情報を集めてきてほしい。
🔍 実行内容の確認（Reviewer要約）:
- 検索語: AWS ソリューションアーキテクトアソシエイト
- 期間: 全期間
- 件数: 上位3件のタイトルを列挙し、1位記事のURLと1位記事の要約（200〜400字）を取得
- 操作: qiita.comを開く → 検索語で検索 → 検索結果の上位3件のタイトル列挙 → 1位記事を開いてURL取得と200〜400字で要約
この内容で実行します。よろしいですか？
🎤 よろしいですか？『はい』または『いいえ』で答えてください。（1/3）
📝 STT(yes/no): はい。
=== Executor result (text) ===
1. AWS ソリューションアーキテクトアソシエイト 試験対策まとめ
2. [SAA-C03対応] AWS ソリューションアーキテクトアソシエイト 合格体験記
3. AWS認定ソリューションアーキテクトアソシエイト（SAA）学習方法まとめ
1位記事のURL: https://qiita.com/negokaz/items/d981fa496b024bbdf334
1位記事の要約:
この記事は、AWS認定ソリューションアーキテクト アソシエイト（SAA）試験の対策方法をまとめたものです。執筆者は実際に試験を受けて合格した経験をもとに、試験範囲の概要、よく出 題される分野やサービス（EC2, S3, RDS, VPC, IAM など）、公式ホワイトペーパーや参考書、オンライン学習サービスの活用法について詳しく解説しています。また、無料の模擬試験サー ビスや、実際に業務でAWSを利用していることが試験合格にどう役立つかも述べています。効率的な学習手順、重要ポイント、注意点とおすすめの勉強リソースを具体的に紹介しているため 、これからSAA受験を考えている人や勉強中の人にとって、全体像の把握および具体的な対策方法に大いに役立つ内容となっています。
評価
今回の処理フロー自体はシンプルですが、曖昧な指示をそのまま実行に渡さず、具体化と要約を挟むというクッションを入れるだけで、実行系AIに対する不安感は大きく変わることが分かりました。
特に重要だったのは、「どの時点で指示が確定したのか」「何をもって実行判断としたのか」を人間が把握できるようになった点です。
曖昧な入力が、AIの内部で“それっぽい仕様”として確定してしまうリスクを、Reviewerが明示的に止めてくれました。
Reviewerは賢い判断役として振る舞わせるのではなく、曖昧さを増幅させない／勝手な最適化をしない／不明確なら実行を止めるという最小限かつ明確な役割だけを与えることで、実行前のブレーキとして安定して機能しました。
この構成は、AIをより賢くするための工夫というより、人間とAIの間に「責任と判断の境界線」を引くための設計だと整理できます。
おわりに
便利なAIを人間のように扱いたいし、昨今の目まぐるしい進化を見ていると、そのように使える日も近い（気がします）。
一方で、問題になるのが我々が思っている以上に人間の指示は曖昧だという点です。
特にBrowser Automationのように実際の操作が走るAIでは、その曖昧さや誤解釈がそのまま事故に直結します。
本稿で試したのは「AIを賢くする工夫」ではなく、曖昧な指示のまま実行に入らせない構造そのものを作ることでした。
Reviewerは賢い判断役というより、「不明確なら止める」「勝手に最適化させない」ためのブレーキとして振る舞わせています。
特に口頭で操作する場合には内容の曖昧さが増すため、実行前に要約して人間が確認できるワンクッションを挟むだけで安心感も事故確率も大きく変わることを今回の検証で実感しました。
実行系AIにおいては、「どれだけ賢く解釈できるか」よりも
「曖昧なまま実行しない構造を作れているか」のほうが重要になる場面も多いはずです。
今回の構成はシンプルですが、実行系AIを扱う際の事故防止設計として、誰かの参考になれば幸いです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。