生成AIを試したことのある企業は増えました。一方で、試した結果が業務の形を変えたという話は、まだあまり聞きません。
この段差はどこにあるのか。公開されている調査を手がかりに整理すると、詰まっている場所はモデルの選び方ではないことが見えてきます。この記事では、AIエージェントを業務へ組み込むときに決めるべきことと、委託の進め方をまとめます。
AIエージェントとチャットボットの違い
まず言葉を揃えます。両者の違いは、賢さの程度ではなく、行動するかどうかです。
チャットボットは、聞かれたことに答えます。出力は文章で、その文章をどう使うかは人が決めます。
AIエージェントは、目的を受け取って、途中の手順を自分で決めながら処理を進めます。社内の文書を検索し、基幹システムから値を取り、条件に合えば申請を起票する。出力は文章ではなく、システムの状態の変化です。
この違いが設計を分けます。文章を返すだけなら、間違いの影響は読んだ人が気づけば止まります。行動する仕組みでは、間違いがそのまま記録として残ります。だからAIエージェントの開発では、どこまで任せるかという線引きが、モデルの選定より先に来ます。
AIエージェントそのものの定義は、AIエージェントとは何かを解説した記事とAIエージェントの定義で扱っています。
日本で詰まっているのはモデル選定ではない
情報処理推進機構（IPA）が公表したDX動向2025は、日本・米国・ドイツの3か国を比較した調査です。調査期間は2025年2月上旬から3月下旬までとされています。この調査から、日本の立ち位置が読み取れます。
生成AIについて前向きな取組みをしている企業の割合は、米国で8割弱、ドイツで7割弱でした。日本は5割弱にとどまっています。ここでいう前向きな取組みとは、「導入している」「現在、試験利用をしている」「利用に向けて検討を進めている」の合計です。
規模別に見ると差はさらに開きます。日本の従業員100人以下の企業では、「関心はあるがまだ特に予定はない」と「今後も取組む予定はない」の合計が8割近くになりました。同じ区分で米国は2割強、ドイツは4割弱です。一方で日本の1,001人以上の企業は、3か国の中で「導入している」割合が最も高いとされています。
より示唆的なのは、具体的な利用状況です。「個人や部署で試験利用している」「個人で業務利用している」については3か国とも回答率が高い傾向にあります。しかし「部署の業務プロセスに組み込まれている」については日本の回答率が低く、業務全般や全社的な活用には至っていないとされています。
つまり、多くの企業は試すところまでは来ています。止まっているのは、その先の組み込みです。
人材の面でも傾向が出ています。同調査では、日本はAI関連人材が種別を問わず不足しているとされます。さらに「先端的なAIアルゴリズムを開発したりできるAI研究者」で56.4%、「AIを活用したソフトウェアやシステムを実装できるAI開発者」で40.7%の企業が「自社には必要ない」と回答しました。自社で開発して使うのではなく、業務への適用に活用していく傾向がうかがえます。
この構図は、委託先に何を求めるかを決めます。必要なのはモデルを作れる相手ではなく、業務の手順を理解して、システムに安全に接続できる相手です。
最初の対象業務をどう選ぶか
最初の1件で成否がほぼ決まります。選ぶ基準は3つです。
判断の根拠が明文化されていること。規程やマニュアルがある業務は、エージェントに渡す条件を書き下せます。担当者の勘で回っている業務は、まず人の手で基準を言語化する作業から始まります。
結果を検証できること。処理したあとで、正しかったかどうかを誰かが確認できる業務を選びます。確認の方法がない業務では、改善の手がかりが得られません。
間違えたときに取り返しがつくこと。下書きの作成、分類、要約、一次応答は、間違えても人が止められます。入金処理や対外的な確定通知から始めるのは、設計が固まってからです。
逆に、避けたほうがよいのは件数が少なくて例外ばかりの業務です。効果が見えにくく、ルールも作りにくいためです。
候補が複数あるときは、現在その業務に何時間かかっているかを先に測ってください。導入後に比べる基準がないと、効果の議論が印象論になります。処理件数、1件あたりの所要時間、差し戻しの件数。この3つを2週間分そろえておけば、最初の報告で使えます。
設計で決める4点
業務が決まったら、次の4点を先に決めます。この4点が決まっていない開発は、動くものはできても運用に乗りません。
権限。エージェントがどのシステムに、どの範囲で接続できるかを決めます。人の権限をそのまま借りるのではなく、エージェント専用の権限を作って最小限から始めます。参照だけで始めて、書き込みは後から足すのが安全です。
人の承認。どの操作に人の確認を挟むかを決めます。金額、件数、相手先といった条件で線を引き、その線を越える処理は必ず止めて人に回します。線引きは後から動かせるようにしておきます。
ログ。何を入力として、どの情報を参照し、何を実行したかを残します。AIエージェントの出力は毎回同じとは限らないため、後から説明するにはログが唯一の手がかりになります。どの版のプロンプトと設定で動いていたかも記録します。
評価。正しく動いているかを測る方法を、開発の前に決めます。実際の業務から事例を集めて正解を用意し、変更のたびに同じ事例で確認します。この仕組みがないと、改善したつもりで悪化していても気づけません。
エージェントに任せる範囲は、一度決めたら固定するものではありません。運用を始めると、想定していなかった例外が必ず出てきます。最初の3か月は、例外が出るたびに記録し、ルールに落とすか人の判断に戻すかを決める作業が続きます。この作業を見込んでおくと、運用の立ち上がりが安定します。
社内データの扱いとRAG
社内の文書を参照させる方法として、RAGと呼ばれる構成がよく使われます。質問に関連する文書を検索し、その内容を根拠として回答させる仕組みです。
ここで効くのは、モデルよりも手前の部分です。検索対象の文書が整理されていなければ、古い規程と新しい規程の両方が根拠として出てきます。実務では、次の点を先に決めておくと精度が安定します。
どの文書を対象にするか。版管理されていない文書は対象から外すか、版を付けてから入れます。
誰がどの文書を参照できるか。人によって見てよい範囲が違う場合、検索の段階で絞り込みます。権限を無視して検索すると、回答経由で情報が漏れます。
回答に出典を付けるか。出典が示されていれば、利用者が自分で確かめられます。確認の手間を人に残すことは、品質の面ではむしろ利点になります。
運用ルールをどう作るか
IPAの同じ調査は、生成AIを業務で活用する上での課題も挙げています。効果やリスクに関する理解の不足と、利用を管理するルールや基準の作成の難しさは、3か国とも高い傾向にあるとされています。加えて、誤った回答を信じて業務に利用してしまうというリテラシー面の課題は、日本が突出しているとされます。
ルール作りの出発点としては、経済産業省と総務省が示しているAI事業者ガイドラインが参考になります。公開されている文書に沿って、自社で決めるべき項目を洗い出す進め方が現実的です。
社内向けには、長い規程よりも短い運用手順のほうが機能します。使ってよい業務と使ってはいけない業務。入力してよい情報の範囲。出力をそのまま使ってよい場面と、人の確認が必要な場面。問題が起きたときの連絡先。この5項目が1枚にまとまっていれば、現場は迷いません。
社内で持つ役割と、委託する役割
AIエージェントを入れた企業が運用でつまずく理由は、担当が決まっていないことです。作って引き渡した時点で、誰のものでもなくなる例をよく見ます。
社内に残しておきたい役割は3つあります。
業務の責任者。その処理の結果に責任を持つ人です。どこまでエージェントに任せるかを決め、承認の線引きを動かす判断もこの人が行います。
評価の担当。定期的に出力を点検し、集めた事例を更新します。専任である必要はありませんが、誰の仕事かは決めておきます。
データの管理者。参照させる文書の版と公開範囲を保つ役割です。ここが崩れると、精度は静かに落ちていきます。
委託側が担うのは、接続の実装、権限とログの仕組み、評価の基盤、そして変更のたびの検証です。この分担を最初に決めておくと、引き渡しのあとも運用が続きます。
委託するときの進め方
AIエージェントの開発は、通常のシステム開発と違う部分があります。仕様を固めてから作るのではなく、動かしながら精度を上げる工程が必ず入ります。
そのため、最初の契約で全機能の完成を約束する形は向きません。対象業務を絞り、評価の仕組みを先に作り、そこで測りながら範囲を広げる進め方が現実的です。契約の形としては、工程を区切って進めることになります。
委託先を見るときは、モデルの知識よりも、既存システムへの接続と運用設計の経験を確認してください。AIエージェントの価値は、基幹システムや社内文書につながって初めて出ます。
MOHAは自社でAIプロダクトを開発し、運用しています。要件定義書を分析する「SpecLens」と、設計チェックリストとテストケースを自動生成する「Design Checklist」があります。サーバーログを監視する「AMI Bot」と、オンライン会議を支援する「MIA」も自社開発です。受託では、自治体向けのAIチャットボットや工場のリスク管理AIを手がけてきました。AIによる請求書読み取りアプリやAI-OCRの実績もあります。自社の開発工程にAIを組み込んで運用している立場から、現場に載る形をご提案します。公開事例は導入事例に掲載しています。
MOHAへの質問事項
ご検討の際は、次の点を直接お尋ねください。
対象業務の候補を挙げたとき、どれを最初に選ぶか。その理由は何か。
既存システムへの接続をどう設計するか。権限をどう分けるか。
評価の仕組みをどう作るか。何を正解として測るか。
ログとして何を残すか。問題が起きたとき、どこまで遡れるか。
体制はどうなるか。日本側の窓口は誰か。
ご相談にあたって
AIエージェントの開発で差が出るのは、モデルの選択ではなく、権限と承認とログと評価の設計です。この4点が決まっていれば、対象業務を広げるときの判断も速くなります。
ご相談の際は、対象にしたい業務と、いま手作業で行っている手順をお聞かせください。お問い合わせ・ご相談から承ります。サービスの詳細はAIコンサルティング・AI開発、開発体制についてはシステム受託開発のページもご覧ください。
