IPAが整理したAIエージェントのリスクを、要件に落とす

客先の要件定義の場で、AIエージェントの話が出ることが増えました。問い合わせの一次対応を任せたい。社内の申請を読み取って、基幹システムへの登録まで進めてほしい。こうした要望が、業務要件の一行として、ほかの要望と同じ並びで出てきます。

そのとき上流の担当者が迷うのは、リスクをどの言葉で、どの細かさで客先と話すかです。なんとなく危ない、と言っても議論は進みません。かといって、セキュリティ部門に丸ごと預けると、要件定義が終わったあとで前提が崩れます。

2026年の秋、情報処理推進機構（IPA）から、AIエージェントのリスクを整理した資料が出ました。この記事では、その動きを手がかりに、ITコンサルやPMOとして参画している人が、AIエージェントのリスクを要件定義の論点にどう落とすかを考えます。

IPAが続けて出している、AIとセキュリティの整理

IPAは、AIのセキュリティに関する動きをまとめた「AIセキュリティ短信」をWebで公開しています。2026年10月号では、AIエージェントの逸脱、攻撃への悪用、情報漏えいといったリスクが整理されたと報じられています。

同じ10月には、IPAが「情報セキュリティ白書2026」のPDF版を公開したことも報じられました。能動的サイバー防御やAI、サプライチェーン対策が扱われています。さかのぼると、2026年版の「情報セキュリティ10大脅威」では、AIの利用をめぐるサイバーリスクが初めて選ばれています。

それぞれの資料の中身は、原文で確かめてください。この記事で扱うのは、資料の解説ではありません。公的機関がAIエージェントのリスクを分けて名前を付けた、という事実を、上流の現場でどう使うかです。

AIエージェントは、文章を返すだけの道具ではありません。ほかのシステムを読み、書き、動かします。そうなると、リスクの多くは利用者の心がけでは防げず、要件と設計で決めることに変わります。つまり、上流の仕事の範囲に入ってきます。

「逸脱」は、権限と承認の線引きとして決める

まず、AIエージェントが想定と違う動きをする場面です。この記事では、逸脱をそう読み替えて話を進めます。生成AIの出力は、同じ入力でも毎回同じとは限りません。チャットで答えを返すだけなら、人が読んで捨てれば済みます。ところがエージェントは、その出力をもとに次の操作へ進みます。

たとえば、経費精算の差し戻し理由を読み取り、申請者に修正依頼のメールを送る機能を考えます。読み取りを誤れば、関係のない人にメールが飛びます。差し戻しではなく承認として処理すれば、お金が動きます。要件定義の段階で決めておくべきなのは、AIの精度ではありません。どこまでをAIに実行させ、どこから先は人が確かめるか、という線です。

要件定義書には、機能ごとに次のことを書いておくと、設計とテストに引き継げます。

• AIが読み取ってよいデータと、書き込んでよいデータ
• 人の承認を挟む操作（送信、登録、削除、支払い）
• 一度に処理してよい件数や金額の上限
• 止めるときの手順と、止める判断をする人

気をつけたいのは、承認を挟みすぎることです。全部の操作に人の確認を入れると、AIを入れた意味がなくなります。客先の担当者も、そのうち中身を見ずに承認ボタンを押すようになります。間違えたときに取り返しがつくかどうかで操作を分け、取り返しがつかないものにだけ承認を置く。この切り分けを、業務部門と一緒に一つずつ決めていきます。

「攻撃への悪用」は、AIに読ませるものの範囲として決める

次に、AIエージェントが攻撃に悪用される場面です。業務システムの要件定義では、利用者は社員で、入力は画面から来る、という前提で考えがちです。AIエージェントは、その前提を崩します。社外から届いたメール、取引先の添付ファイル、Webページ。エージェントが読みにいくものの中に、悪意のある指示が紛れ込むことがあります。

上流でできるのは、AIに読ませるものの範囲を、業務フローの上で明らかにすることです。たとえば、受注メールを読んで受注データを仮登録する業務なら、メールの送り主は社外の人です。誰でも送れる経路から入ってきた文章を、AIが読み、社内のシステムを操作する。この構図を、業務フロー図の上で客先と一緒に指でなぞります。

そのうえで、社外から来たものを読む処理と、社内のシステムを動かす処理を同じエージェントに持たせるかどうかを論点として出します。分けるのか、間に人の確認を挟むのか、操作できる範囲を仮登録までに絞るのか。答えは業務によって変わります。上流の担当者が決めきる必要はありません。ただ、論点として課題一覧に載せずに要件定義を閉じることは避けます。

ここで気をつけたいのは、具体的な攻撃手法の説明に時間を使いすぎないことです。業務部門の人に技術の細部を話しても、判断の材料にはなりません。誰でも送れる経路から来た文章でシステムが動く、という一点が伝われば足ります。細かい対策の検討は、客先のセキュリティ部門や基盤の担当と別の場を設けます。

「情報漏えい」は、データの流れ図に線を足して決める

三つめは情報漏えいです。生成AIの利用ルールで、入力してよい情報を定めている客先は多いと思います。ただ、AIエージェントでは、人が入力するのではなく、エージェントが自分でデータを取りにいきます。人が入力しないので、利用ルールの外側でデータが動きます。

上流でやることは地味です。システム間のデータの流れを描いた図に、AIのための線を足します。エージェントがどのシステムから何を読み、どの外部サービスに送り、結果をどこに残すか。基幹システムの刷新で現行の連携を洗い出すときと同じやり方です。線が一本増えるだけですが、この線が図にないと、あとで誰も責任を持てません。

たとえば、問い合わせ対応のエージェントが、回答を作るために顧客マスタと受注履歴を読む、という要件があるとします。その場面で確かめることを並べます。

1. 読むのは、問い合わせてきた本人のデータだけに絞れるか
2. 読んだデータは、どの外部サービスに送られるか。その契約で、送ったデータはどう扱われるか
3. 会話の記録やログに、個人情報がそのまま残らないか。残るなら、誰が見られるか
4. 回答の中に、別の顧客の情報が混ざらない仕組みがあるか

二つめの外部サービスの扱いは、契約や規程の話になります。上流の担当者が判断するものではありません。客先の法務・情報セキュリティの担当に確認する項目として、課題一覧に載せます。個人情報の扱いは法令にもかかわるので、最終的な判断は専門家に確かめてもらうよう、客先に伝えておくと安全です。

要件定義の会議で、どう切り出すか

三つのリスクを論点に落とせても、会議でうまく出せなければ意味がありません。AIエージェントの導入は、多くの場合、客先の経営層や業務部門の期待を背負っています。そこにリスクの話を持ち込むと、ブレーキ役に見られがちです。

切り出し方として使いやすいのは、公的機関の整理を借りることです。たとえば、定例会議の最後に、次のように話します。IPAがAIエージェントのリスクを三つに分けて整理しています。今回の機能について、それぞれ誰が何を決めるかを、次回までに一枚にまとめてお持ちします。こう言えば、反対ではなく、進めるための段取りとして受け取ってもらえます。

その一枚は、機能ごとの行と、逸脱・悪用・漏えいの三つの列でできた一覧で構いません。マス目には、決めることと、決める人と、期限を書きます。空いたマス目がそのまま未決事項になります。業務部門が決めること、情報システム部門が決めること、法務やセキュリティが決めること。この振り分けができるだけで、会議の空気は変わります。

気をつけたいのは、外部の資料の権威で押し切らないことです。公的機関の資料は、判断の観点を示すものです。客先の業務にどこまで当てはめるかは、客先が決めます。資料を持ち出すのは、話を始めるきっかけまでにとどめます。

サプライチェーンの話として、外部サービスを見直す

情報セキュリティ白書2026では、AIと並んでサプライチェーン対策も扱われています。この二つを、上流の現場ではつなげて考えたほうが実務に合います。AIエージェントは、ほとんどの場合、外部のAIサービスやクラウドの上で動きます。つまり、客先のシステムの一部が、新しい取引先に頼る形になります。

大手メーカーのプロジェクトでは、取引先の管理や委託先の審査の仕組みが、すでに社内にあることが多いはずです。ところが、AIサービスの利用は、部署ごとの小さな契約やトライアルから始まりがちです。その結果、本番の業務に組み込まれる段階になっても、委託先として審査されていないことがあります。

要件定義の段階で、使う予定のAIサービスを洗い出し、客先の調達や委託先管理の手続きに乗っているかを確かめます。PoCで使ったサービスをそのまま本番に持ち込む計画なら、なおさらです。モデルの更新で動きが変わる可能性、サービスが止まったときに業務をどう回すか。こうした点も、非機能要件の一つとして書き出しておきます。

AIの導入を、ITの新機能ではなく、新しい委託先との取引として見る。この視点を持っているだけで、確かめるべき相手と手続きが見えてきます。

次の定例までに、AIの権限一覧を一枚作る

AIエージェントのリスクの話は、まだ答えが固まっていない領域です。公的機関の整理も、今後、内容が更新されていく可能性があります。だからこそ、上流の担当者に求められるのは、正解を知っていることではありません。決めるべきことを、決められる人の前に、決められる形で並べることです。

いま参画しているプロジェクトに、AIを使う機能が一つでも入っているなら、次の定例までに一枚の一覧を作ってみてください。行に機能、列に逸脱・悪用・漏えい。マス目には、AIに許す操作と、人が確かめる操作、決める人を書きます。空いたマス目が、そのまま次の会議の議題になります。IPAの資料は、その一覧を作るための観点として、手元に置いておくと役に立ちます。