「AIの完成度は7割8割」ITコンサル会社代表が語るAI導入の落とし穴

〜AIが仕上げる7割8割の先、残りを誰が埋めるのか〜

AIを入れれば、その分だけ仕事が減る。そう期待して相談に来る企業は少なくありません。ですが、企業の基幹システム導入を手がけるITコンサルティング会社の代表・青井真吾氏によれば、AIが出してくるものは「7割8割ぐらいの完成度」です。残りを埋めるのは人で、そこを見積もっていないプロジェクトほど、あとから揉めます。

企業がAIを業務に組み込むとき、期待と現実はどこでずれるのか。青井氏が挙げたのは、期待値をそろえるためのPoCとスモールスタート、AIが取りこぼす業務側の条件、そしてAIに読ませる社内文書の管理でした。発注する側にも、受ける側にも、転ぶ手前で確かめられることがあります。

青井真吾

AOIS Consulting株式会社 代表取締役。青井 真吾（あおい しんご）。大学卒業後はIT企業に入社。システムエンジニアとして大手企業向けのERPシステム開発を経験。その後独立し、人材派遣、不動産、自動車、ファッション、エネルギーなど多くの業界でDX推進などのITプロジェクトに従事。現在はAOIS Consulting株式会社を設立し、エンタープライズシステムの開発・導入を支援するITコンサルティングサービスを展開している。

「7割8割でいい」と最初に言う——期待値がずれる理由

AIは、業務システムを使う側だけの話ではなくなっています。青井氏が扱うERP（会計や人事、在庫などを一元的に扱う基幹業務システム）では、導入する側の作業にもAIが入り込んでいます。

ERPだと、例えばSAPはもうAIを標準搭載しています。業務の自動化でも使われますし、ERPのアドオン機能の開発や設定を自動でやってくれるツールも出ていて、そういった機能を使って導入を進めます。業務だけではなく、ERPの導入自体もAIである程度効率化できるというのが、進化している部分かなと思います。

ところが、この「効率化できる」という感触が、発注する側に伝わるときに膨らみます。導入すれば人手が要らなくなる、という期待に置き換わってしまいます。青井氏が繰り返し口にしたのは、その膨らみをどう戻すか、という話でした。

分かりやすい例として挙がったのが、議事録です。青井氏が見てきたプロジェクトでは、議事録の作成はほぼAIに置き換わっています。1時間かかっていたものが5分になります。ただし、できあがったものをよく見ると、重要な決定事項やToDoが抜けていることがあります。録音の音声が悪い、といった原因もあります。文章としては整っているので、抜けているほうに気づきにくいのです。

AIのアウトプットは、多分7割8割ぐらいの完成度だと思ったほうがいいです。その上で、7割8割を100%にするのは人になると思っています。AIに議事録を作らせても7割ぐらいの完成度なので、残りの30%は自分たちでレビューして、追記したり修正したりして100%に持っていきます。完全に自動化というよりは、業務効率化の程度に考えたほうがよいということを、期待値のコントロールも兼ねて説明しています。

「完全な自動化」ではなく「業務効率化」。この言い換えを、青井氏は導入の前に、客先で明示的に伝えています。あとから言い訳として持ち出すのではなく、最初の説明として置いておきます。ここで見積もりに入れておくべきものは、次のあたりです。

• ・AIの出力をレビューする人と、その時間
• ・抜けやすい項目（決定事項、担当者、期限）の確認手順
• ・入力側の品質（会議の録音環境、元になる資料の状態）

「大金をかけて異常に期待させて転ぶ」前に——PoCとスモールスタート

期待値をそろえる方法として、青井氏が挙げたのは2つでした。どちらも目新しい言葉ではありませんが、AIの案件では効き方が違います。

注意すべきことというか、コツに近いかもしれないんですけど、2つあって。PoCを確実にやることと、スモールスタートで始めることだと思っています。AIを導入するとなると、お客さんの期待値が上がっていることがすごく多くて、それは私も現場でかなり感じています。実際にはお客さんが期待しているほどの成果にならないことが結構あります。なので、まずサンプルの検証をして、お客さんと一緒に、この程度のことならできるというのを具体的に肌で感じてもらいます。

資料で説明するのではなく、一緒に動かして見てもらいます。ここが要点です。できることの説明よりも、できないことを先に体験してもらうほうが、あとの揉め方が小さくなります。

すごいお金をかけて、異常に期待させて転ぶよりは、最初にこの程度はできます、この程度はできませんというのを分かってもらったほうがよいので、PoCをすることとスモールスタートが重要だと思っています。

期待値を膨らませるのは、発注側だけではありません。青井氏は自社についても、「営業がちょっと過剰コミットというか、お客さんのハードルをあまりにも上げてしまって、開発側から営業に文句を言ったりということも実はあるんです」と明かします。売る側と作る側が別の期待値を持ったまま契約が進むと、そのずれはプロジェクトの中で表に出てきます。開発部と営業部の連携が必要になる、というのはそういう意味です。

発注する側にも、できることがあります。まず全額を投じず、段階を区切って進める形です。最初の区切りでここまで作り、成果を見て次に進むかを決めます。この進め方について尋ねると、青井氏は「おっしゃる通り」と応じました。発注側が確かめておきたいのは、次の3つです。

• ・契約前に、PoCの範囲と、そこで何が分かれば次に進むのかを決める
• ・「できません」と説明された内容を、営業ではなく開発側の言葉でも聞いておく
• ・最初の区切りで払う金額と、そこでやめられるかどうかを確認する

技術的には正しいのに、業務としては間違う——申し込みをウェブにした提案

期待値がそろっていても、成果物が業務に合わないことがあります。AIは企業ごとの事情を知らないまま、正しい設計を出してくるからです。青井氏が実際に試した例があります。

AIは企業特有の条件が分かっていないので、そこが考慮できないことで、技術的には正しいが業務的には間違うという例が起こります。実際にやってみたこともあるのですが、顧客からのサービス申し込みを受けて、ERPに登録して会計業務を効率化したい、という提案をしてほしいと依頼したときに、AIはサービス申し込みをウェブでさせて、ウェブからAPIでERPに連携するという提案をしてきたんです。ただ実際には、そのサービスは、お年寄りでITに使い慣れていない方が使っている場合もありますので、そういった考慮をしないで提案をしてきていました。

設計としては、ウェブ申し込みからAPI（システム同士がデータをやりとりする窓口）連携までまっすぐ通っています。技術的には正しい。けれども、申し込む人がウェブフォームを使えなければ、その入り口は動きません。紙やコールセンターからの入力が残る前提だったなら、設計そのものを組み直すことになります。

青井氏によれば、「ITに慣れていない人もサービスのお客さんです」と前提を置いて依頼し直せば、出てくる提案の質は上がります。つまり、抜けているのはAIの能力ではなく、業務側の条件を言葉にして渡す作業のほうです。そしてその作業は、もともと人がやってきた仕事でもあります。

仕事としては、業務側とシステム側の担当者の間に立って、業務とシステムの通訳みたいなイメージですかね。業務側の要件をうまく吸い出して、それをシステム側に伝えるという仕事をしています。

業務側の担当者は、自分たちの前提を当たり前だと思っているので、聞かれなければ言いません。AIはその前提を聞き返しません。誰かが吸い出して渡さないかぎり、業務の条件は設計に入らないままになります。

社内文書を読ませても嘘が減らない理由と、「AIを育てる」という仕事

自社の文書をAIに参照させれば、でたらめな回答は減ります。そう考えて社内向けのAIを作る企業が増えています。ところが、参照させたのに間違いが出る、という相談も同時に増えています。

RAGを参照しているのにハルシネーションが起きるという件は、大抵はRAGに設定していた社内文書の情報が古かったり、間違っていたりする場合だと思います。100%とは言えないのですが、かなり多いと思います。インプット情報を正確に渡せている、それを把握できている、AIが何をインプットにしているのかを把握しているということが、注意すべき点かなと思っています。

つまり、原因は多くの場合AIの側ではなく、読ませている資料の側にあります。古い規程、更新されていない手順書、内容が食い違ったままの2つの文書。人間なら「これは古いやつだ」と気づくものを、AIは同じ重みで読みます。

そうなると、これは開発する側だけで閉じる問題ではなくなります。青井氏は、社内文書について「それを管理されているところ、どの部署かはその企業によると思うんですけど、そことの連携や確認が重要になってくる」と話します。文書を持っている部署が動かないかぎり、読ませる資料は整いません。開発を請ける側には、そのリスクを企業に伝える責任がある、という点にも青井氏は同意しました。

資料を整えるのは、後ろ向きな片づけではありません。青井氏はこれを「AIを育てる」と呼び、自社で実践しています。

AIは育てるもので、AIが参照するインプットを作ったりします。私の会社でもやっているのですが、議事録は、社内用語がどこの会社でもあると思うんです。社内用語をAIに教えるために、AIに読ませる用の用語集を作っているんです。それはAIを育てることにもなっていて、AIは議事録を作るときにその用語集を見て、会社オリジナルの言葉も分かった上で議事録を作ってくれるので、より正確な議事録が作れます。

用語集を1つ作るだけで、出てくる議事録の精度が変わります。派手さはありませんが、AIに何を読ませるかを設計する仕事は、ここから始まります。社内でこれから手をつけるなら、次の順番が現実的です。

• ・AIに読ませている資料を一覧にして、最終更新日を確認する
• ・内容が食い違っている文書を突き合わせ、どちらが正かを決める
• ・社内用語や略語をまとめた用語集を作り、AIに読ませる
• ・資料を管理している部署を決め、更新の担当を割り当てる

AIの導入で転ぶ場所は、技術の側にはあまりありませんでした。期待値がそろっていない、業務側の条件が渡されていない、読ませる資料が古い。どれも、人と組織の側で起きています。だからこれから求められる力として青井氏が挙げたのも、「AIにうまく依頼できる力、育てられる力、成果物を検証できる力」でした。小さく試して、渡すものを整えます。AI導入の成否は、その地味な作業の量で決まります。

AIが返してきたものを一人ひとりがどう確かめるか、という話は、別記事「ITコンサルタントに聞く、AIが勝手に置く前提と検証の順番」にまとめています。AIが自分で置いてしまう前提の見つけ方から、公式ドキュメントや検証環境をたどる確認の順番まで、青井氏に伺いました。

取材日：2026年8月19日