社内AIエージェント導入｜90日で進める5段階

はじめに

「AIエージェントを入れよう」と決まった翌週、いきなり全社向けの説明会を開く。よくある始め方だが、ここで話せるのはツールの機能くらいだ。誰のどの仕事を任せるのか。どこから人が確認するのか。失敗を何で見つけるのか。肝心な運用はまだ決まっていない。

社内AIエージェントの導入は、アカウントを配れば終わるソフトウェア導入ではない。業務の一部を担う「新しい実行主体」を組織へ入れる仕事である。最初の90日を、利用者数を増やす期間ではなく、役割と管理方法を確かめる期間として設計したい。

パーソル総合研究所の2026年調査では、正規雇用者の生成AI業務利用率は54.3%まで伸びた。一方、組織課題の上位には「AIの教育・サポートが正式な業務や評価に位置づけられていない」32.5%、「データが部署ごとに分断」31.9%、「手順が人ごとに異なり、例外が多い」31.0%が並ぶ。利用機会を作るだけでは、業務成果につながらない理由がよく見える。

そこで、AIエージェントの社内導入手順を、最初の90日・5段階に分ける。期間は目安だ。次の段階へ進む条件を満たさなければ、日付が来ても広げない。

90日計画の新しさは、予定表ではなく「合意する成果物」にある。各段階で、業務仕様、権限仕様、評価仕様、導入仕様、運用仕様を一つずつ残す。SIerへ開発を委託する場合も、この5点が顧客との受け入れ条件と保守範囲になる。

1〜2週目：対象業務を一つに絞る

最初に選ぶべき業務は、派手なものではない。入力、判断、出力を観察でき、失敗しても人が戻せる仕事がよい。

候補を出すときは、次の5項目を一枚に書く。

• 誰から、どんな依頼を受けるか
• 参照してよい情報は何か
• AIエージェントが行う判断は何か
• 成果物を誰が確認するか
• 間違えたとき、どこまで戻せるか

たとえば「会議議事録を作る」だけでは粗い。「録画と参加者メモを読み、決定事項・未決事項・担当者・期限を下書きし、会議主催者が確認して共有する」まで具体化する。入力と出口が見えるので、誤りも測りやすい。

反対に、初回から避けたいのは、送金、契約締結、人事評価、顧客への自動送信など、間違いの回収が難しい仕事だ。複数部署の未整理データを横断する業務も早い。まず一つの業務で、AIへ渡せる手順が本当に存在するかを確かめる。

業務を絞る前に「何でもできる社内AI」を作ると、評価基準も責任者も曖昧になる。AI社員の役割分担を3層で整理した記事も、担当範囲を切り出す際の補助線になる。

次へ進む条件は、業務責任者が一人決まり、入力・判断・出力・確認者を一枚で説明できることだ。これを業務仕様の初版とし、SIerは解釈を足さずに試作できるか確認する。

3〜4週目：権限と停止条件を先に実装する

試作品が動くと、つい機能を増やしたくなる。だが、この時期に増やすべきなのは能力ではなく境界だ。

社内AIエージェントには、少なくとも四つの権限を分ける。

1. 情報を読む
2. 下書きを作る
3. 社内データを更新する
4. 社外へ送信する

「閲覧できる人なら更新もできる」とは限らない。AIエージェントも同じである。最初は読み取りと下書きまでに限定し、更新や送信は人の承認を通す。利用するアカウント、対象フォルダ、接続先、実行時間帯も明記する。

AIセーフティ・インスティテュートの評価観点ガイド第1.20版は、AIエージェント固有の観点として「観測と制御」を追加した。自律的な挙動や外部環境との相互作用を扱う以上、「うまく動くか」だけでなく「見えるか、止められるか」が評価対象になる。

停止条件は文章で残す。入力が欠けている、参照先が特定できない、候補が複数ある、個人情報を含む、予定コストを超える。こうした条件では自動的に人へ戻す。エラー時に黙って別案を試す挙動は、業務では事故を隠す。

権限設計の具体例は社内AIエージェントは権限設計からでも整理している。

次へ進む条件は、許可された操作、禁止された操作、承認が必要な操作、緊急停止の担当者がテストで確認できることだ。仕様変更で権限を増やす場合は、誰が承認し、どの評価を再実行するかも記録する。

5〜6週目：正答率ではなく業務結果を測る

AIエージェントの評価を「回答が自然だった」で終わらせない。業務導入では、成果物の品質と人の負担を同時に見る。

初期評価には、次の指標が使いやすい。

比率だけでなく、失敗事例そのものを残す。「顧客名を取り違えた」「古い規程を参照した」「担当者が不明なのに推測した」のように、入力・判断・出力のどこで壊れたかを分類する。記録項目を具体化するときは、AIエージェントの監視で残す5つのログも参考になる。

NISTのAIリスク管理フレームワークは、AIの設計、開発、利用、評価へ信頼性の観点を組み込む枠組みを示している。評価を公開直前の検査にせず、運用中も更新する考え方が大切だ。

テストは成功例だけで組まない。空欄、矛盾、重複、権限不足、古い情報、悪意ある入力を混ぜる。AIエージェントのPoCを本番へ渡す条件も、評価セットを作るときに参照してほしい。

次へ進む条件は、業務責任者が合格ラインを承認し、失敗を再現できる評価セットが残っていることだ。この評価セットが受け入れ試験の共通言語になる。SIerだけで正解を決めず、顧客側が許容範囲を署名できる形にする。

7〜9週目：利用者を少人数へ広げる

ここでようやく利用者を増やす。ただし全社展開ではない。対象業務を日常的に行う3〜10人程度へ広げ、使わなかった理由まで集める。

研修は長い機能説明より、実際の依頼を3本処理するほうが効く。利用者には次の四つを伝える。

• 何を頼めるか
• 何を頼んではいけないか
• 出力のどこを確認するか
• 困ったとき、誰へ戻すか

利用ログだけでは定着を判断できない。使われない理由が「知らない」「入力が面倒」「結果を信用できない」「人へ頼むほうが早い」では、対策が全部違う。週1回、15分で構わないので、利用者・業務責任者・開発担当が失敗例を一緒に見る。

パーソル総合研究所の同調査では、AI環境で有効なマネジメントとして、仕事の枠を示す、裁量を提示する、思考の深さを問う、学びへ接続するといった行動が挙げられている。AIエージェントだけを調整するのでは足りない。人への依頼方法と確認方法も仕事として整える。

次へ進む条件は、対象者の過半が継続利用し、不採用の理由と修正工数を週次で説明できることだ。導入仕様には研修資料だけでなく、問い合わせ先、回答期限、仕様へ戻す不具合の条件を含める。

10週目〜90日目：継続、縮小、停止を決める

90日目の会議で「便利だった」という感想を集めても、投資判断にはならない。開始時の業務と比較し、三つの判断から選ぶ。

• 継続：品質、安全、工数の基準を満たし、担当者と運用費を置ける
• 縮小：一部の入力や判断だけ不安定で、対象範囲を狭めれば価値が残る
• 停止：人の確認負担やリスクが減らず、改善仮説も弱い

継続する場合も、すぐ別部署へ横展開しない。先に、責任者、仕様、評価セット、変更履歴、障害対応、費用の上限を運用台帳へまとめる。費用はモデル利用料だけでなく、人の確認や再評価も含めて考える。AIエージェントの費用を5つに分けた記事で内訳を確認できる。Microsoftの実装ガイダンスも、計画、実装、導入、管理、改善を連続したライフサイクルとして扱い、稼働後の利用監視、フィードバック、分析による改善を求めている。

縮小や停止は失敗ではない。90日で「任せないほうがよい範囲」を発見できたなら、大きな事故や固定費を避けたことになる。むしろ危ないのは、担当者不在のまま「せっかく作ったから」で動かし続けることだ。

完了条件は、次の90日に使う予算、担当者、対象業務、改善項目が決まり、決まらない場合は停止日が設定されていることだ。運用仕様には、問い合わせ、障害、モデルやデータの変更、再評価、費用超過を誰が引き取るかまで書く。

AIエージェントの社内導入手順を一枚にする

社内AIエージェントの導入手順は、分厚い計画書にしなくてよい。次の項目を一枚にまとめれば、経営、現場、開発が同じ判断材料を持てる。

AIエージェントは、導入した瞬間に社員になるわけではない。役割を与え、権限を制限し、仕事ぶりを観測し、改善か停止を判断できて初めて、組織の一員として扱える。

株式会社Atsumellでは、対象業務の分解から要件定義、権限・承認設計、評価セット、運用までを一緒に整理している。90日計画を自社の業務へ落とし込みたい場合は、お問い合わせから相談してほしい。

関連記事

• AI社員とは？導入前に見る3つの違い
• 社内AIエージェントは権限設計から
• AIエージェントのPoC｜本番へ渡す5条件