AIエージェントを会社へ入れたいけれど、何から決めればよいのでしょうか。動かし始めた後の担当や、止める判断も気になる所です。
AIエージェントの導入は、計画から使い終わりまでの6工程で進め、人が確かめて次へ進みます。
- 使う前に、誰が止めるかと、人が確かめる操作を決めます。
- 最初は一つの仕事から小さく始め、記録を残します。
- 年一回の点検に加え、変更や事故の時も点検します。
目次
AIエージェントの導入は何から始める?会社に入れる6工程
目的を決め、一つの仕事で試してから、運用と使い終わりまで設計します。事例と費用は別記事に分け、ここでは進め方、社内の決め事、運用を扱います。

なぜ今、決め事が要るか
AIエージェントは、目標を受けて道具を使う担当のようなAIです。質問へ答えるだけでなく、外のシステムを操作する場合もあります。基本の意味は、AIエージェントとはで整理しています。
開発元OpenAIの公式は2026年10月、EUの企業利用の調査を紹介しました。
OpenAIの調査では、企業・ビジネス顧客の利用の半分以上にエージェント型の道具が含まれます。自社でも、使う道具だけでなく、任せる操作を先に書き出します。
IPAは、情報処理推進機構という情報技術の公的な機関です。10大脅威2026では、AI利用のリスクが組織向け3位です。今回初めて選ばれた項目です。
6工程の全体像
IPAのサイトで公開された手引書で、導入の工程を見る画面です。

- 1ライフサイクルの定義の文(6工程と、導入者〈業務部門等〉・管理者〈運用部門等〉・支援部門の関わりを表3-1に定める)
- 2図3-1「AIシステムのライフサイクル」(1企画→2調達→3技術検証・設計→4運用前準備→5運用→6廃棄)
- 3工程を移る時の決まり(関係者が協議し、リスクが許容範囲内であることと残るリスクの扱いを文書にして次へ進む。外部顧客向け・機密や個人情報・自動判断や外部システムの操作では、管理者とセキュリティ部門を含めて成果物の承認を必須にするのが望ましい)
赤枠2の6つの箱が廃棄で終わり、赤枠3に文書と承認の条件があることを確かめます。自社の担当者と、各工程で承認する物を書き出します。
この手引書は、中核人材育成プログラム第9期生の卒業プロジェクトです。IPAのサイトで公開されていますが、IPAの公式ガイドラインそのものではありません。この記事では、進め方を整理する資料として使います。
最初の企画では、何のために使うかを決めます。次の調達は、必要な製品や提供元を選ぶ段階です。その後の技術検証・設計は、試運転と設計図づくりに当たります。
運用前準備は、開店前の点検にたとえられます。動かす設定と担当をそろえ、運用へ進みます。最後の廃棄は、使い終わる時の対応まで含めた工程です。
手引書は、工程を移る際に関係者が協議する形を示します。リスクが許容範囲かと、残るリスクの扱いを文書にします。動いたという結果だけでなく、次へ進む判断を残す進め方です。
外部顧客向け、機密や個人情報、自動判断や外部操作は、特に承認が関わります。手引書は、管理者とセキュリティ部門を含む承認が望ましいとします。誰へ渡すかを、試す前に決める理由です。
事例と費用の送り先
具体的な使い道は、AIエージェントの活用事例で扱います。費用は、AIエージェントの導入費用へ整理しています。このページでは、会社で誰が何を決めて進めるかを中心にします。

AIエージェント導入で国のガイドラインは何を求める?
国の指針は、リスクを見て目標を決め、運用と評価を回す考え方です。AI全般の指針で、エージェント専用の導入手順書ではありません。

回し続ける考え方
AI事業者ガイドラインで、運用を回す考え方を見る画面です。

- 1「E. AI ガバナンスの構築」の説明(ルールや手続を事前に固定せず、「環境・リスク分析」「ゴール設定」「システムデザイン」「運用」「評価」のサイクルを回し続ける「アジャイル・ガバナンス」が重要)
- 2①「環境・リスク分析」を実施する/②開発・提供・利用するかを判断し、ポリシーの策定などを通じて「AI ガバナンス・ゴール」を設定する(経営上のゴールと整合させる)
- 3③ゴールを達成するための「AI マネジメントシステムの設計」を行い、「運用」する(外部のステークホルダーへの透明性・アカウンタビリティを果たす)
赤枠1に回し続ける説明があり、赤枠2・3で目標から運用へ続くことを確かめます。自社の計画にも、導入後に評価して直す工程を入れます。
総務省・経済産業省の第1.2版は、アジャイル・ガバナンスを示します。これは、走りながら道を見て運転を直す考え方にたとえられます。環境やリスク、目標、設計、運用、評価を回し続けます。
AIガバナンスは、AIを使うための管理の決まりです。事前に一度だけ文書を作り、そのまま動かす考え方ではありません。使う対象や周囲の条件が変われば、再び見直します。
国の指針の環境・リスク分析では、使う状況から考えます。次に、開発、提供、利用するかを判断し、目標を定めます。その目標は、経営上の目標とも整合させる考え方です。
その後は、目標を達成する管理の仕組みを設計し、運用します。評価して直し、運用開始後にも環境を分析します。指針の一連の流れは、手引書の各工程を回す土台として使えます。
3つの資料は誰向けか
| 資料 | 出した所 | 誰向けか | 使う所 |
|---|---|---|---|
| 国のガイドライン | 総務省・経済産業省 | AIの開発・提供・利用 | 運用を回す考え方 |
| 手引書 | IPAサイトで公開 | 会社のAI活用 | 工程・担当・点検 |
| 源内基準 | デジタル庁 | 政府職員 | 公的機関の統制の例 |
資料の対象を分けると、自社へ使う範囲も見えます。源内基準は、民間の会社への法的な義務ではありません。手引書の実務の例と、国の指針を組み合わせて考えます。

AIエージェントの導入で誰が何を決める?
導入する担当と、運用して見張る担当を分けます。工程ごとに、成果物を誰が承認するかを決めておきます。

工程ごとの役割と承認
手引書の役割分担表で、工程と担当を見る画面です。

- 1工程の列(1.企画/2.調達/3.技術検証・設計/4.運用前準備/5.運用/6.廃棄)
- 2企画の工程で、支援部門の欄の「AI管理者:企画内容の確認、フェーズ成果物の承認」
- 3運用の工程の主担当「AI管理者」が受け持つ5つ(定期的な固有リスク評価/定期的な対策の実効性評価/変更管理の記録/脅威・脆弱性情報の継続的収集と評価/AI開発者・AI提供者の定期的な評価)
赤枠3で、運用の主担当がAI管理者であることを確かめます。赤枠2の企画の承認も読み、自社の担当を表に入れます。
手引書の表3-1は、主担当と支援部門を分けています。運用はAI管理者が主担当です。定期的なリスク評価、対策の評価、変更の記録などを受け持ちます。
支援部門には、セキュリティ、情報システム、法務、調達が関わります。製品を買う判断と、業務へ入れる判断、運用する判断は違います。一つの部署の便利さだけで決めないための分担です。
AI管理者の運用の役割には、脅威や脆弱性の情報収集も含まれます。脆弱性は、守りに空いた弱い穴にたとえられます。AI開発者や提供者の定期的な評価も、表に挙がっています。
| 工程 | 主担当の整理 | 承認・確認 |
|---|---|---|
| 企画 | 導入者〈業務部門等〉 | AI管理者が企画を確認 |
| 調達 | 導入者〈業務部門等〉 | 工程の成果物を承認 |
| 技術検証・設計 | 導入者〈業務部門等〉 | 工程の成果物を承認 |
| 運用前準備 | 導入者〈業務部門等〉 | 工程の成果物を承認 |
| 運用 | AI管理者 | リスクと対策を評価 |
| 廃棄 | — | — |
手引書は、自動判断や外部操作などの場面も説明しています。管理者とセキュリティ部門を含めた承認が望ましい用途です。先へ進む時は、残ったリスクの扱いも文書にします。
止める権限を先に文書に
手引書の責任者の説明で、停止の権限を見る画面です。

- 1責任者を置く意義(責任者が不在だと、各部門の独自判断でリスクが偏り、責任の所在が不明確なまま対応が後手に回る。意思決定の最終権限を持つ責任者〈CAIO〉を設置することが望ましい)
- 2権限の観点「AI利活用および統制施策の実行判断」(深刻なセキュリティ脅威が確認された場合に、対象システムの一時停止や外部AIシステムの利用禁止を命じる権限があると望ましい。あらかじめ権限を明文化しておく)
- 3権限の観点「経営層へのAIリスクの共有」(重大なインシデントとその兆候などを、取締役会や経営会議を通して経営層に定期的に報告する)
赤枠2に、一時停止や利用禁止の権限を事前に文書化する記述があることを確かめます。事故が起きる前に、命じる人と連絡先を文書に入れます。
CAIOはChief AI Officerで、AIの責任者を指します。船の進路や停止を決める責任者にたとえられます。手引書は、一時停止や利用禁止を命じる権限の明文化を勧めています。
手引書は、責任者が不在だと部門の判断が偏るおそれを説明します。重大な事故と、その兆候を経営へ報告する役割も示します。止める権限と、経営へ知らせる経路を一緒に決める形です。
デジタル庁の調達・利活用ガイドライン第2.0版は、2026年6月12日承認です。各府省庁にCAIOを置く規定を、手引書は脚注で紹介しています。政府の組織の例と、自社の体制は分けます。
Microsoftの会長兼CEO、Satya Nadellaは2026年10月、管理の考え方を発信しました。
モデルは、AIの中で言葉を読み書きする頭に当たります。管理の役割を、その頭の外にも置く考え方です。
Microsoftの発表では、権限、監視、封じ込めをモデルの外側で受け持ちます。自社でも、AIへの頼み方だけに停止の役割を任せない設計を考えます。
人が少ない会社の場合
手引書は、人数が少ない会社での兼ね方を示していません。私たちWEBMARKSの考えでは、役職名より判断の役割を分けることが先です。同じ人が兼ねる場合も、何を承認するかを記します。
たとえば、仕事を頼む人と、外へ出す判断をする人を分けます。難しい場合も、作業の記録と確認の条件を残します。少人数だから停止の責任者を空欄にする、という進め方にはしません。

AIエージェントを導入する前に決める5つとは?
権限、承認、入れる情報、記録、止め方の5つです。何を任せるかと、どこで人へ戻すかを同じシートへ書きます。

権限の範囲
権限は、開ける部屋を決める鍵束にたとえられます。調べる仕事に、送信や削除まで必要とは限りません。源内基準は、利用目的と実行する権限を限定する考え方です。
たとえば、社内向けの要約を作る担当なら、対象の資料を決めます。外へ送る操作まで同じ依頼に含めるかは、別の判断です。源内基準の限定という項目を、自社の業務の言葉へ直す例です。
AI企業Cohereの公式は2026年10月、隔離した試験環境の出来事を報告しました。
報告は、モデルの外部送信を環境が止めた件で、原因は調査中です。悪意とは断定されず、送信も成功していないため、自社では操作の範囲と隔離を点検します。
AIの情報を発信するgota_baraは2026年10月、関連資料を紹介しました。
投稿は、AnthropicのZero Trust for AI agentsを勧める紹介です。資料の中身を推測せず、権限を最初から広げる必要があるかを考えます。
承認が要る操作
承認は、大事な操作の前に人がOKを出す仕組みです。源内基準は、重要な処理の前の確認と承認を挙げています。自社の仕事でも、外へ送る時や重要な変更をする時を具体化します。
源内基準の利用者の責務では、更新や削除も本人が判断します。異常が起きたら停止し、管理者へ報告する考え方です。普段の確認と、異常時の連絡を別の条件として書きます。
Claudeの開発者向け公式は、会社のIDで一括認可する例を紹介しています。認可は、どの部屋の鍵を渡すかを決めるイメージです。使う人が増える時も、権限の管理を先に考えます。
入れてよい情報
AI事業者ガイドライン第5部は、利用者の事項を示しています。個人情報や機密情報を、不適切に入力しないことが含まれます。資料の場所だけでなく、内容を渡す条件も決めます。
記録
記録は、何をしたかを後から見られる作業日誌です。ログとも呼び、源内基準はその保存を統制の一つとしています。保存先と、その記録を見る担当を一緒に決めます。
手引書の運用は、変更管理の記録も挙げています。どの設定を変え、どの条件で使うようになったかを追うためです。以前の評価が、今の状態にも当てはまるかを見直せます。
止め方
手引書は、停止を命じる権限を事前に文書化する考え方です。止める人と連絡先、対象の作業を決めます。私たちの停止・確認ルールも、止まる場所を先に決める話です。
| 決め事 | 決める中身 | 根拠の例 |
|---|---|---|
| 権限 | 触る道具と範囲 | 源内基準 |
| 承認 | 人が確認する操作 | 源内基準 |
| 情報 | 入れる・入れない物 | 国のGL第5部 |
| 記録 | 保存先と見る人 | 源内基準 |
| 止め方 | 止める人と連絡先 | 手引書2.2.1 |
私たちの役割カードは、頼む範囲を見える形にします。担当の役割と、触ってよい物を明確にする考え方です。次のシートへ、必要な条件をまとめられます。
導入前の決め事シート 任せる仕事: 触れてよい範囲(権限): 人の承認が要る操作: 入れてよい情報・入れない情報: 記録の置き場と見る人: 止める人・止め方・連絡先: 責任者:

AIエージェント導入の最初の1業務はどう選ぶ?
出来上がりが確認でき、影響を戻しやすい仕事を一つ選びます。試す条件と結果を決めてから、広げる判断へ進みます。

小さく試す(PoC)
PoCは、本番へ入れる前の小さな試運転です。私たちWEBMARKSは、最初に任せる仕事の選び方を紹介しています。いきなり会社全体へ広げず、一つの対象で試す考え方です。
たとえば、公開済み資料から下書きを作る仕事です。元の資料と出来上がりを、人が比べられます。外の相手へ送らず、社内で結果を見る形から始められます。
この試運転では、完成形を先に書きます。誰が何を発表したかを、出典と一緒に返すといった条件です。元の資料を見て、達したかを本人が確かめられる形にします。
手引書の工程の考え方では、試した結果から次の判断へ進みます。動作だけでなく、残るリスクも関係者で扱います。試す対象を広げる時は、入力する情報や外部操作の条件も変わるかを見ます。
途中で人に確かめる仕組み
Claudeの開発者向け公式は、TasksとElicitationsを紹介しています。前者は長い仕事を任せる、後者は途中で人へ入力を求める仕組みです。受付票で仕事を追い、必要な時に質問が戻る形と考えると分かります。
途中の確認は、毎回何でも聞く設定だけではありません。重要な操作に確認が届き、内容を人が読めることが必要です。源内基準の承認も、操作の重さと合わせて考えます。
広げる順番
Google Cloudの投稿は、社員が自分のエージェントを作る事例です。投稿の数字は同社の紹介として読み、自社の予測には置き換えません。一つの業務で確認した後に、担当や範囲を広げます。
作る方法へ進む場合は、AIエージェントの作り方で扱います。ここでは、何を満たしたら次へ進むかを決めます。動いたことだけでなく、使う人と確認する人が判断できる状態にします。

公的機関はAIエージェント導入をどう統制している?
源内基準は、限定、承認、ログ、停止、評価、責任を示します。政府職員向けの基準で、会社の法的義務ではありません。

源内基準のリスク
デジタル庁の源内基準で、リスクと統制を見る画面です。

- 1AIエージェントを導入した場合のリスク(誤った判断の連続実行・作業ファイルの誤消去・改変・権限を超えた処理・機密情報の不適切な取扱い等)と、使う人に必要なリテラシー
- 2統制措置(利用目的及び実行権限の限定・重要な処理における職員の確認・承認・ログの保存・利用停止機能・定期的な性能評価・スキルの審査・責任主体の明確化)
- 3民間のAIエージェント関連サービスは、事業者が定める機能・権限・ログ・モデル・データ管理の範囲で使うのが基本で、中の動きが見えにくくなるおそれや、仕様・料金が事業者の判断で変わる可能性がある、という注意
赤枠1に誤消去などのリスク、赤枠2に承認や停止の対策が並ぶことを確かめます。自社で使う製品でも、権限と記録の条件を確認します。
源内基準は、誤判断の連続実行や、ファイルの誤消去・改変を挙げています。権限を超える処理、機密情報の不適切な扱いも対象です。AIが自分で進む時に、影響が続くことへ備える内容です。
限定・承認・ログ・停止・評価・責任
源内基準は、利用目的と実行権限を限定します。重要な処理の前に人が確認し、ログと停止機能を用意します。定期的な性能評価や、責任を持つ主体も明確にします。
源内基準の管理者の責務は、個人の注意だけに頼らない考え方です。教育と周知、リスク評価、事故対応の手順を含みます。使う人が分かっているはず、と期待するだけではない運用です。
利用状況と費用の把握も、同基準の確認点です。仕事の量や利用者が増えた時は、管理する対象も変わります。会社へ置き換える場合も、誰が状況を把握するかを決める材料になります。
私たちWEBMARKSは2026年10月、立場別のルールを提案しました。
自社投稿は、源内の利用者・管理者・開発者の分担を紹介しています。会社でも、立場ごとに何を判断するかを書き出します。
源内基準は、民間サービスの機能や権限が提供元の範囲に従う点も挙げます。仕様や料金が変わり、中の動きが見えにくくなる可能性があります。導入時の設定を、そのまま永続の条件とは扱いません。

AIエージェントを導入した後の運用は何を点検する?
定期点検に加え、モデル更新や事故、利用拡大の時にも点検します。許容できる範囲を超えたら、縮小や停止も検討します。

定期点検
手引書の運用の節で、定期と臨時の点検を見る画面です。

- 1臨時点検(年1回程度の定期点検だけでなく、重要な変更・事故・脆弱性の公表・モデルの更新・利用範囲の拡大などを契機にして点検し、リリース条件や利用条件も見直す)
- 23.5.1 定期的な固有リスク評価(ビジネス要件の変更・対象利用者の拡大・想定と違う使い方・法令の変更で導入時の評価が妥当でなくなる。許容水準を超えたら、対策の見直し・提供範囲の縮小・利用の停止を検討する)
- 3実効性評価の観点の例(監視・検知〈重要なシステムでは毎日、人が確認することが望ましい〉/設定・権限〈設定棚卸し・アクセス権レビュー〉/運用実績〈インシデント対応記録・教育実施状況〉)
赤枠1に、年一回程度の定期点検だけでなく臨時でも点検する文があることを確かめます。年の予定と、変更時の点検を両方記録します。
手引書は、年一回程度の定期点検だけで終えないよう示します。重要なシステムは、毎日人が確認するのが望ましいという記述です。監視、設定と権限、運用の実績を分けて見ます。
臨時点検のきっかけ
| 点検 | きっかけ | 見る物 |
|---|---|---|
| 定期 | 年一回程度 | リスクと対策の実効性 |
| 臨時 | モデルの更新 | 利用条件・出力 |
| 臨時 | 事故・脆弱性の公表 | 対策と影響 |
| 臨時 | 利用範囲の拡大 | 権限と対象者 |
| 臨時 | 重要な変更 | リリースの条件 |
脆弱性は、守りの弱い所を指します。以前の確認が通っていても、使う範囲や製品が変われば評価をやり直します。手引書は、利用条件も合わせて見直す考え方です。
手引書は、業務の要件や対象利用者の変化も点検の理由に挙げます。想定と違う使い方や、法令の変化もあります。モデルが変わらなくても、使う側の条件が変われば評価へ戻ります。
実効性の評価では、事故対応の記録と教育の実施も見ます。設定やアクセス権の棚卸しと、運用の実績を分ける形です。機能が動くかの試験だけでなく、人の運用も点検の対象です。
許容を超えたら縮小・停止
手引書は、許容水準を超えた場合の対策の見直しを示します。提供範囲の縮小や、利用の停止も検討します。止める人を事前に決める意味が、ここでつながります。
OpenAIの2026年10月の発信は、社内の監視を広げる話です。モデルを作る会社の内部の話として、考え方の参考にします。自社の規模へそのまま当てはめず、確認が届く条件を決めます。

WEBMARKSはAIエージェントの導入後をこう回している
私たちWEBMARKSでは、指示書と完了の条件を渡し、機械と別のAIが点検します。作った担当の返事と、実物の判定を分けます。

社長→統括→部署→担当AI+監査役
統括が全体の指示を出し、部署から担当へ範囲を渡します。担当が作り、監査役が条件へ照らして差し戻します。代表の鈴木が、公開してよいかを判断します。
調べはGrokと下調べのAIです。設計はClaudeのAPI、本文はOpenAIの会話の担当Codexです。APIは、外からAIを呼ぶ受付のような仕組みです。
図解は、キャラクターの原版をGPT Imageへ渡して描きます。点検は機械と、書き手とは別の会社のAIの採点です。85点未満は差し戻します。
全体の指示と見本の確認は、統括のAIであるClaudeが受け持ちます。
指示書の型
WEBMARKSの指示書の型を見る画面です。

- 1上から決める3段(CEOの指示の原文/統括の目的と完成形/部長の部署と受け持ち)
- 2AI担当がやること1〜5(読む物・1本ごとの調べ方・保存先・点検・書き換えない管理表)
- 3完了の条件と監査役の判定(条件がそろえば合格・途中なら同じ会話へ差し戻し・公開やWordPressへの入稿・pushはしない〈本人の許可が要る〉)
赤枠1の上からの3段と、赤枠3の完了条件・差し戻し・公開しない線を確かめます。〈A0xx〜A0yy〉は型の空欄なので、自分の担当範囲へ置き換えます。
公開、WordPressへの入稿、pushは、許可の必要な操作として分けています。pushは、手元の変更を共有先へ送る操作です。記事制作の完了と、外への反映を一つにしない形です。
指示書の型 目的と完成形: 担当の範囲(ほかに触らない): やってはいけないこと: 完了の条件: 止まる所(本人の許可が要る操作): 差し戻し先:
機械の点検と差し戻し
WEBMARKSの機械の監査役の、試し判定を見る画面です。

- 1点検のコマンドと判定結果(「不合格」)
- 2合格の項目(字数〈6000-12000の範囲で 9047〉・タイトルに主キーワード・リードに主キーワード・H2の数・図解・X埋め込み など)
- 3基準に届かない項目(吹き出し 0/8・公的・準公的な出典〈4以上に対して 0〉・冒頭は結論の箱1つ)
赤枠3に×が一つでもあると、赤枠1の全体判定が不合格になることを確かめます。自社の点検も、何を満たしたら合格かを先に決めます。
画面は、H001の試し判定の一回分です。現在の本文の合否ではなく、記事品質の点検の例です。会社のAIの安全そのものを点検した画面ではありません。
画面の試し判定では、字数や題のキーワードは合格しています。一方で、吹き出しや公的出典、冒頭の形に足りない所がありました。一部の項目が合格でも、全体は不合格となる例です。
私たちの指示書は、担当する番号の範囲を限定しています。ほかの番号へ触らず、管理表も変えないという条件です。作業の目的だけでなく、触る対象を絞って渡す例として示しています。
私たちのnoteの5条件も、完了の判断を扱っています。動いた返事だけでなく、条件と実物を見る考え方です。指示と採点をつなぎ、足りない物を直します。

AIエージェント導入のよくある質問
Q. AIエージェントの導入に国の決まりはありますか?
AI事業者ガイドラインは、AI全般の指針です。源内基準は政府職員向けで、会社の法的義務ではありません。対象を分け、会社で決める条件へ落とし込みます。
Q. 小さな会社でもCAIOが要りますか?
手引書は、少人数での兼ね方を示していません。まず止める権限を持つ人を、文書にすることが要点です。私たちの考えでは、役職名より判断の役割を明確にします。
Q. 社員が入れてはいけない情報は何ですか?
国のガイドライン第5部は、個人情報や機密情報の不適切な入力を避ける内容です。提供者の留意点も踏まえます。自社の資料を使う前に、入力してよい範囲を決めます。
Q. 点検は年一回でよいですか?
手引書3.5は、変更や事故、利用拡大の時にも点検する考え方です。モデル更新や脆弱性の公表も、きっかけに含みます。定期と臨時の両方を用意します。
Q. 途中で人が確認する仕組みはありますか?
Claudeの開発者向け公式は、Elicitationsを紹介しています。途中で人へ入力を求める仕組みです。源内基準も、重要な処理の前に確認・承認する考え方を示しています。
まとめ:AIエージェント導入で今日からやる3つ
AIエージェントは、企画から廃棄までの6工程で考えます。工程の承認、止める人、導入後の点検を最初から設計します。小さく始め、変わった時にも評価を回す進め方です。
- 導入前の決め事シートを一枚埋めます。
- 消しても困らない控えの仕事を一つ選びます。
- 臨時点検のきっかけを四つ書き出します。









