日本の「人手不足×知識承継」問題に、次の一手：エージェンティックAIで「業務が回る仕組み」を作る

採用が難しい。若手が定着しない。ベテランが高齢化し、暗黙知が現場に残ったまま——。
この状況で「現場の頑張り」や「教育回数を増やす」だけでは、限界が見え始めています。

いまグローバルで起きている変化は、AIを「相談相手」として使う段階から、AIを「業務の担い手（デジタル労働力）」として組み込む段階への移行です。
これを実現する考え方が エージェンティックAI（Agentic AI）。単なるチャットボットではなく、AIが「状況を理解し」「次の作業を計画し」「必要な情報を探し」「社内システムを操作して」「結果を記録する」——つまり 業務プロセスを前に進めるアプローチです。

先進企業は、どこで成果を出しているのか（実例）

事例1：問い合わせ対応を“解決率”で改善し、業務負荷を構造的に下げる

OpenAIと協業したKlarnaは、AIアシスタントが導入初期に2/3のカスタマー対応チャットを処理したと公表。さらに、解決時間の短縮や反復問い合わせの減少なども示しています。
ポイントは「AIが回答する」ことではなく、「問い合わせ→意図判定→根拠（ナレッジ）参照→解決/エスカレーション」という一連の流れを、KPI（解決率・再問い合わせ率・処理時間）で管理している点です。

引用：クラーナ

Klarna AI assistant handles two-thirds of customer service chats in its first month | Klarna International

※Klarnaは、後払い（BNPL）を中心とした決済サービスを提供するスウェーデン発のフィンテック企業で、近年はAIを活用してカスタマーサポートや業務運営の高度な自動化を進めている先進企業です。

事例2：会議後の「面倒な事務作業」を、AIが成果物まで作って記録する

Morgan Stanleyは、クライアント同意を前提に、面談後の要約・アクション抽出・フォローアップメール下書きを作成し、Salesforceへ記録する仕組みを発表しています。
「議事録を作る」だけで終わらず、次に必要な仕事（メール・CRM記録）まで進める。ここに「エージェント性」があります。

引用：モルガンスタンレー
Launch of AI @ Morgan Stanley Debrief | Morgan Stanley

事例3：繁忙期の波を、AIで吸収する（季節雇用に頼らない）

SalesforceはAgentforceの顧客事例として、1-800Accountantで繁忙期のチャットの70%を自律解決した旨を紹介しています。
繁忙期のたびに人員を増やすのではなく、AIが一次対応と定型作業を担い、人は高度判断へ集中する設計です。

引用：セールスフォース

1-800Accountant will resolve 70% of inquiries with Agentforce. | Salesforce

日本企業が導入でつまずく理由（そして解決策）

エージェンティックAIは、PoCで動いても「本番で怖い」「責任が曖昧」「情報漏洩が心配」で止まりがちです。
だから最初にやるべきは、モデル選定ではなく ガバナンス設計です。

• 誰が責任者か（業務オーナー・IT・監査/法務）
• AIに許す操作範囲（閲覧のみ／下書きまで／登録まで 等）
• 人の承認が必須な行為（対外送信、発注、マスタ更新、支払関連など）
• 監査ログ・変更管理（プロンプト・ツール定義の更新履歴）

この考え方の土台として、NISTのAI RMF（AI Risk Management Framework）は、統治（GOVERN）から測定（MEASURE）まで整理されており、社内合意を作りやすい枠組みです。

※１：NIST

Artificial Intelligence Risk Management Framework (AI RMF 1.0)

※NISTは、米国商務省に属する国立研究機関で、AIやサイバーセキュリティを含む先端技術について、世界中の企業や政府が参考にする信頼性・安全性の標準ガイドラインを策定している組織です。

また、OWASPの LLM/GenAI向けTop 10は、プロンプトインジェクションや機密漏洩など「ありがちな落とし穴」をチェックリスト化するのに有効です。

引用：OWASP

OWASP Top 10 for Large Language Model Applications | OWASP Foundation

※OWASPは、世界中の専門家が参加する非営利団体で、WebやAIを含むソフトウェアの代表的なセキュリティリスクと対策（Top 10）を整理し、企業が安全にシステムを運用するための実践的指針を提供しています。

導入の流れ（PoC→パイロット版→本番）を、最短で回すロードマップ

Phase 0：ガバナンス（最初の2週間で決め切る）

• 権限マトリクス（AIに許す操作）
• 承認ポイント（重要操作は必ず人が承認）
• 監査ログ要件（誰が・いつ・何を・なぜ実行したか）

Phase 1：ユースケース選定（最初の勝ち筋を1つに絞る）

最初に当てやすいのはこの3つです。

1. 問い合わせ一次対応＋起票（例：品質・保全・購買・情報システム）
2. 資料探索→要約→成果物化（議事録、手順書の差分整理、稟議下書き）
3. 定型ワークフローの下書き作成（申請・承認・登録の「前段」）

Phase 2：パイロット版（部門限定で運用し、KPIで磨く）

• KPI例：一次完了率、処理時間、再オープン率、承認待ち時間、誤起票率
• 重要：ログを見て、権限とツールを調整する（一発で完成させない）

Phase 3：本番（段階的に自律化の範囲を広げる）

• 「提案→承認→実行」から始め、安定したら一部を自動承認へ
• ただし発注・対外送信などは最後まで“人の関与”を残すのが現実的

具体技術：非エンジニアでも分かる「3点セット」

エージェンティックAIを「業務化」する技術は、実はシンプルに3つです。

引用：OpenAI
a-practical-guide-to-building-agents.pdf

(1) RAG：社内ナレッジを根拠として参照する

手順書・規程・過去のトラブル対応・FAQ・議事録などを整備し、AIが根拠を引いて回答・提案できる状態にします。
「知識承継」の第一歩は、ここを作ることです。

(2) Tool Calling：AIが社内システムを操作できるようにする

AIは単体では社内システムを更新できません。そこで、AIが「この操作を実行したい」とツール（関数/API）を呼ぶ仕組みを入れます。

※Tool Callingとは、AIが会話するだけでなく、あらかじめ定義されたAPIや業務機能（起票・検索・更新など）を安全なルールのもとで呼び出し、実際の業務を前に進める仕組みのことです。

イメージは「AIが作業指示を出し、アプリ側が実行する」。これにより、

• チケット起票
• 台帳検索
• 稟議下書き作成
• 日報の下書き・登録
  など“前に進む”動きが可能になります。

引用：OpenAI Platform

Function calling | OpenAI API

(3) ワークフロー制御：業務の分岐・例外・中断再開を設計する

業務は例外だらけです。そこで、状態（進捗）と分岐（条件）を管理する仕組みが必要になります。
たとえばLangGraphは、エージェント/ワークフローの設計パターンを整理し、デバッグや運用をしやすくする考え方を提示しています。

引用：LangGraph

Workflows and agents - Docs by LangChain

※LangGraphは、AIの判断や処理を業務フローのように分岐・状態管理しながら進められるようにするための、エージェンティックAI向けワークフレームワークです。

怖さを潰す具体策：DLP・承認・監視

データ漏洩を防ぐ（DLP）

MicrosoftのCopilot Studioでは、データ流出防止のためにデータポリシー（DLP）を設定し、接続できるコネクタや扱えるデータを制御する考え方が示されています。

参考：Microsoft Copilot Studio

Configure data policies for agents - Microsoft Copilot Studio | Microsoft Learn

※DLP（Data Loss Prevention）とは、機密情報や個人情報が社外に漏れたり不正に持ち出されたりしないよう、データの利用・共有・送信をルールで制御・監視する仕組みのことです。

重要操作は承認を通す（Approvals）

同じくCopilot Studioでは、マルチステージ承認やAI承認（プレビュー）など、重要判断は人がコントロールする設計が説明されています。

参考：Microsoft Copilot Studio

Multistage and AI approvals in agent flows - Microsoft Copilot Studio | Microsoft Learn

ガードレールと監視（Monitoring）

Amazon Bedrockでは、ガードレールのメトリクスをCloudWatchで監視する考え方が示されています（どれだけブロックされたか、など）。

参考：AWS

Monitor Amazon Bedrock Guardrails using CloudWatch metrics - Amazon Bedrock

※Amazon Bedrockは、AWSが提供する生成AI基盤で、複数の高性能AIモデルを安全管理や業務連携（エージェント化）とあわせて、非エンジニア企業でも使いやすく導入できるサービスです。

また上述したOpenAIのガイドでも、安全・予測可能・効果的に動かすための実践ポイント（ユースケース選定、ツール設計、評価）が整理されています。

まず何から始めるべきか（最短の提案）

もし、あなたの会社が「今年、現実的に一歩進める」なら——おすすめはこの順番です。

1. 対象業務を1つに絞る（問い合わせ一次対応＋起票、が最短で効果が出やすい）
2. ナレッジ（手順書・FAQ）をRAG化し、根拠のある回答にする
3. ツール実行（起票・検索）を最小権限で追加（承認前提）
4. KPI（一次完了率・処理時間・再問い合わせ率）でパイロット版を運用し、拡張

エージェンティックAI導入の「最初の一手」を一緒に設計しませんか

貴社の業務（品質／保全／購買／生産管理／情シス等）を題材に、AI戦略フレームワークにて、

• 最初のユースケース候補（3案）
• 権限・承認・監査の設計
• RAG対象の優先順位
• API（ツール）定義の最小セット
  

を、短期間で「実装可能な形」に落とし込みます。

お問い合わせはこちら