はじめに はじめまして。介護/障害福祉事業者向け経営支援「カイポケ」の事業部でCS職（カスタマーサクセス/サポート）をしているTSUNOです。カイポケに携わって10年以上になります。 エンジニアではありません。プログラミングの経験もありませんでした。 そんな私がAIを活用して業務自動化ツールを開発した結果、 月17.7時間の工数削減 と 購買判断の適正化 を実現しました。 この記事は、非エンジニアのCS職がAIで業務自動化を進めた実践記です。AIでここまでできるんだ、という実感を持ってもらえたら嬉しいです。 なぜやろうと思ったのか カイポケのCSでは、お客様からの問い合わせ対応だけでなく、カイポケを利用するうえでの事務手続きまで、お客様の業務を幅広く支えています。 2024年11月、業務体制の変更にともない、新たに業務を引き継ぐことになりました。 この業務は完了までに多くのステップがあります（下図）。引き継いだのはそのフェーズ2の部分でした。 複雑な作業を、ひたすら繰り返す。通常業務にこれらが上乗せされる状況では、とてもではないですが手が回りません。ちょうどその頃、無料版のChatGPTで簡単なGoogle Apps Script（GAS）を書く体験をしていました。もっと本格的にプログラムで業務を改善できるのではないか——そう考え始めたのが、すべての出発点です。 AI活用のステップアップ 最初から有料ツールを使っていたわけではありません。 無料ツールで小さく始めて、成果が出たら次のステップへ。その繰り返しで、気がつけば本格的な開発環境が整っていました。 大事なのは、 最初から大きな投資をする必要はない ということです。 時期 やったこと きっかけ 2024年1月〜 無償版ChatGPTでAI活用を開始 AI活用への興味 2024年11月〜 GASで業務自動化に着手 業務効率化の必要性が高まった 2025年1月頃 Google Workspace標準搭載のGeminiを活用 会社の環境変化 2025年11月 Claude Codeで本格的な開発へ AIツールの比較・検証を経て 2025年12月 Claude MAXプランへグレードアップ ROIを上司に提示して承認 ※ 各時期は筆者が知った・使い始めたタイミングであり、サービスのリリース時期とは異なります。 AI活用の情報収集は多方面から行いました。 X YouTube Google CloudユーザーコミュニティのJagu'e'r ※ Jagu'e'r （ジャガー） とは、Google Cloudユーザー企業が企業の垣根を超えて最新技術やノウハウを共有し合い、クラウド活用の変革を推進する公式コミュニティです。 特にJagu'e'rの無料ハンズオンセミナーでVertex AIに触れたことが、「APIを通じてAIを使う」というイメージを掴むきっかけになりました。この体験が後述するデータ移行支援ツールの技術選定につながりました。こうした外部の学びの場に加え、最近では社内エンジニア主催のClaude Code活用ナレッジ共有会にも参加しました。 よくわからなくても飛び込んでみると、新しい発見があるものです。 生成AIを使った3つの取り組み ここからは、AIを活用して取り組んだ3つの事例を紹介します。 # 事例 概要 1 GAS + 業務フローの見直し 6時間→2時間に圧縮 2 介護保険請求の事務手続きRPA※ 月17.7時間の工数削減 購買判断の適正化 3 AI駆動で開発中のデータ移行支援ツール 帳票の自動解析とデータ整形 ※ RPA（Robotic Process Automation）：人がブラウザやアプリ上で行う操作をプログラムで自動化する技術 1．最初の成功体験 — GASで6時間の業務を2時間に AI活用で最初に取り組んだのは、GASによる業務自動化です。 コードは主にChatGPTで生成・修正しました。自分でゼロから書いたわけではなく、「こういう処理がしたい」とAIに伝えて、出てきたコードを実行し、うまくいかなければエラーメッセージをAIに貼って修正する——このサイクルを回すことで、コードは着実に動くものになっていきました。 結果、1日あたり約6時間かかっていた業務が約2時間に圧縮されました。ただし、これはGASによる自動化だけの効果ではなく、業務フロー全体の見直し（不要な手順の廃止や作業順序の組み替え）との合算です。GAS単体の削減効果として切り出せる数字ではありませんが、ツールを作ること自体が業務を棚卸しするきっかけになったという意味で、大きな一歩でした。 2．介護保険請求の事務手続きRPA — 業務自動化の本格展開 前述の業務見直しの過程で「GASでは解決できない業務」も浮き彫りになりました。業務の中には、介護保険の請求手続きに使う外部システム上で、ログイン・画面操作・帳票出力といったブラウザ操作を行う工程が含まれていました。 このシステムには外部からプログラムで連携するための仕組み（API）が提供されておらず、ブラウザを人の手で操作するしかありません。こうしたブラウザ操作はGASの守備範囲外であり、自動化するにはブラウザそのものを操作するRPAが必要でした。 なお、外部システムをRPAで操作するにあたっては、利用規約の確認や社内のリスクマネジメント部門への事前相談を行ったうえで開発を進めています（詳細は後述の「外部システムを操作する上での配慮」で触れます）。 介護事業所がカイポケを通じて介護保険を請求するには、このシステム上で各種手続きを行う必要があります。これらの作業は、全都道府県にわたる多数のアカウントに対して日々行われます。 以前にもこの業務を自動化するRPAツールが作られたことがありました。しかし、運用環境の変化に対応しきれなくなり、最終的に役割を終えていました。業務は再び手作業に戻っていたのです。 GASで積み重ねた成功体験が、「自分で作ろう。エラーが出ても、AIに聞きながら対処できる」という確信を支えていました。 成果①：月17.7時間の工数削減 RPAによる自動化で、月に17.7時間（稼働日20日/月換算で、1日あたり53分）の業務時間が削減されました。2026年1月時点の実績です。これらの業務はお客様の増加とともに件数が増える傾向にあり、今後さらに削減効果が拡大する見込みです。 数字には表れない変化もあります。以前はルーチン対応で手一杯でしたが、時間が生まれたことで、お客様への進捗報告をより適切な頻度で届けられるよう設計し直す余裕ができました。自動化の本当の価値は、 削減した時間そのものではなく、その時間で何ができるようになるか にあると感じています。 成果②：購買判断の適正化 工数削減以上にインパクトが大きかったのが、購買判断の適正化です。 従来の運用では、外部システムにログインして処理件数を一つひとつ確認する必要があり、全体の正確な把握が困難でした。そのため、実態より多めにアカウントを購入せざるを得ない状況が続いていました。 RPAがこのログインと件数取得を自動で行うようになったことで、実際の利用状況が正確に見えるようになり、不要なアカウント購入を回避してコスト適正化を実現しました。 こうした削減効果の見込みをROIとして上司に提示し、AIツールの上位プランの利用承認を得ました。承認後の実績データでもその効果が裏付けられています。「ツールの利用料に対して、これだけの時間が浮く」という説明は、社内で予算を取るうえで有効でした。 データが見えるようになると、正確な判断ができる と実感した出来事でした。 3．AI駆動で開発中のデータ移行支援ツール データ移行支援ツールは、RPAと並行して開発を進めてきたもう一つのプロジェクトです。現在は検証フェーズであり、RPAのような確定した成果はまだありません。ここでは「完成していなくても、非エンジニアがAIと一緒にここまで到達できる」という過程をお伝えします。 何を解決するツールか カイポケを導入いただく際、お客様がこれまで蓄積してきたデータを、カイポケに登録したいというニーズがあります。その際、帳票（PDF）を目視で読み取り、手作業で転記する。これは時間がかかるだけでなく、ミスが起きやすい作業です。 データ移行支援ツールは、この帳票をAI（Geminiをチャット画面ではなくAPI経由で利用）で自動解析し、カイポケに取り込める形式に変換する仕組みです。 Geminiアプリから始まり、Claude Codeで成長した 最初はGeminiアプリのチャット画面上で、1つのプログラムファイル（.py）にコードを書いていく形でスタートしました。「この帳票のこの項目を読み取って」「エラーが出たから直して」とやり取りしながら、少しずつコードを育てていきました。 しかし、コードが1,600行を超えたあたりで限界が来ました。チャットが一度に扱える文脈の範囲（コンテキスト）にコード全体が収まりきらなくなり、修正のたびに前後関係が途切れるようになったのです。 そこで切り替えたのが「Claude Code」という、テキスト入力で操作する開発ツールでした。プロジェクト全体のファイルを把握しながら、エージェントのように自律的にコードを編集・実行してくれます。 Claude Codeに切り替えてからは開発速度が大幅に上がり、1,600行の単一ファイルだったコードは、役割ごとにファイルを分けた9,300行超の構成にまで成長しています。 時点 規模 開発環境 初期 約1,600行・単一の.pyファイル Geminiアプリのチャット画面 現在 約9,300行 + テスト約1,800行・複数ファイル構成 Claude Code AIに任せる部分と、任せない部分 開発を進める中で、正確性の高いデータソースを優先する設計にたどり着きました。介護保険の請求データは、仕様書でCSV形式として定義されています。これらはCSVから確実に取得し、CSVでは得られない情報だけを帳票PDFからAIに読み取らせる「ハイブリッド方式」を採用しています。 CSV形式で確実に取得できるデータを、あえて精度にばらつきのあるAI読み取りに回す理由はありません。AIは帳票の読み取りで誤認識を起こすことがあるため、確実な手段があるならそちらを優先する。どのデータをどの方法で取得するかの線引きにも、ドメイン知識が活きています。 ※ 個人情報を含むデータのAI処理にあたっては、エンタープライズ向けのセキュアなサービスを利用しています。 現在地 開発環境での検証を経て、クラウド上で動くWebアプリとして構築し、ブラウザからアクセスできる状態にまで持ってきました。前述のハイブリッド方式は、実データを用いた検証でも一定の精度で動作することを確認しています。現在は様々なパターンのプロンプト（AIへの読み取り指示）を調整しながら、対応できる帳票の種類を増やしているところです。自分以外のメンバーが使える状態にすることは今後の課題です。 完成にはまだ時間がかかりますが、非エンジニアによる業務改善の新しい可能性を示せたと考えています。ここからは、3つの事例を通じて得た実践的な学びを共有します。 非エンジニアがAI駆動開発を進めるためのプラクティス 非エンジニアがAIを活用して成果を出すためには、具体的な手法の前に、まずベースとなる「心構え」からお伝えします。 まず押さえておきたい4つの心構え 1. プログラミング経験より、深い業務フロー理解 業務を深く理解し、常に改善点を模索すること。 2. 人間は「要件定義と判断」、AIは「実装担当」 「何を作るか」「どんなエラーが危険か」「どのデータをAIに任せてはいけないか」。こうした判断は人間の役割です。具体的な指示を出し、AIをコントロールすること。 3. AIの出力は「たたき台」として受け取る AIは自信満々に間違えることがあります。コードの中身をすべて理解するのは難しくても、「この修正で何が変わった？」「意図した設計になっている？」とAIに確認することはできます。複数のAIにクロスチェックさせるのも有効です。鵜呑みにせず、自分の言葉で問いかける習慣を持つこと。 4. 小さく始めて、成果を積み重ねる 小さな自動化の成功体験が、次の挑戦への自信と原動力になりました。まずは手を動かしてみること。 実践＆組織で進めるための6つのプラクティス 心構えを土台として、私が実際にやってきた中で「これは他の人にも再現できる」と感じた具体的なアクションを6つにまとめました。 カテゴリ # プラクティス ひとことポイント 実践 1 AIへの指示は「業務の言葉」でいい 専門用語より「何を・なぜ・どうしたいか」 2 エラーは壁ではなく、手がかり エラーメッセージをAIに貼るだけで前に進める 3 テストもAIに書いてもらう ただし「業務的に正しいか」は人間が考える 4 環境構築は「AIに聞く → 裏取り → セキュリティ確認」 シャドーITを避ける手順を省かない 組織 5 成果を数字で見せて、リソースを得る ROIで上司の承認を得る 6 外部システムを操作する上での配慮 利用規約・社内承認・負荷配慮 1. AIへの指示は「業務の言葉」でいい プロンプトエンジニアリングだと身構える必要はありません。大事なのは、 業務の文脈を丁寧に伝えること です。データ移行支援ツールの開発初期に私がAIに伝えたのはこんな内容でした。 専門用語は一切使っていませんが、「何を・なぜ・どうしたいか」が明確なので、AIはセキュリティ設計、並列処理、エラーハンドリング、コスト表示まで一度に提案してくれました。「個人情報はログに出ないようにして」——こうした発想は、業務で日常的に個人情報を扱い、その重みを知っているからこそ生まれるものです。AIの出力品質を左右するのは、プログラミングの知識ではなく業務の知識です。 ただし、AIに任せきりでいい部分と、人間が厳密に設計しなければならない部分はあります。外部システムの仕様書を読み込み、帳票にどのような値が入ってくるのかを整理した上で読み取りのロジックを設計する——ここは業務を知っている人間が責任を持つ領域です。 2. エラーは壁ではなく、手がかり 非エンジニアにとって最大の壁は、エラーが出たときの対処です。でもやることは簡単で、 エラーメッセージをそのままAIに貼る だけです。実際の開発では、エラー対処を段階的にレベルアップさせていきました。 まず貼る — エラーメッセージをAIに貼って「これどうすればいい？」と聞く。大抵はこれで解決策が返ってくる 戦略を作る — エラーの種類ごとの対処方針をAIと一緒に設計する 仕組み化する — エラー発生時に画面キャプチャやHTML、処理ログを自動取得し、原因特定を容易にする ひとつ注意しておきたいのは、エラーは自分のコードだけから起きるわけではないという点です。Pythonのバージョンアップをしたところ、コードを一切変えていないのに、ライブラリが未対応でツールが動かなくなった経験もあります。「動いているものを維持する」難しさも学びでした。 3. テストもAIに書いてもらう 「このコードが正しく動くか確認するテストを書いて」とAIに頼めばテストコードは生成してくれます。ただし、AIが自動生成するのは「コードが技術的に正しいか」の確認です。 「業務的に正しいか」を確認するテストは人間が考える必要があります 。 たとえば「処理が中途半端な状態のまま放置されていないか」というテストシナリオは、実際の運用リスクを知っている人間にしか発想できません。AIに「こういうケースをテストしたい」と伝えれば、コード自体は書いてくれます。 4. 環境構築は「AIに聞く → ネットで裏取り → セキュリティ部門に確認」 必要なライブラリやセットアップ手順をAIに聞き、全体像を把握します。次にライセンス形態や開発元の信頼性をネットで裏取りします。その上で、社内のセキュリティ部門に「このツールを導入してよいか」確認します。 たとえばライブラリ導入時は、ライセンスが商用利用可能であること、開発元が信頼できることを確認した上で社内の専門部署に確認を取る——この手順を省かず、シャドーIT（会社の管理部門を通さずにツールを導入すること）を避けることが、長く使える仕組みにするための土台になります。 5. 成果を数字で見せて、リソースを得る 非エンジニアが業務時間を使って開発を進めるには、上司の理解が不可欠です。前述のとおり、削減効果を数字で示すことで上位プランの承認を得ました。 段階的にスケールし、各段階で成果を見せていくことで、次のチャレンジへの許可を得やすくなります。 6. 外部システムを操作する上での配慮 RPAの開発着手前に、以下の確認・配慮を行いました。 利用規約の確認 — RPAによる自動操作が明示的に禁止されていないことを確認 robots.txtの確認 — 対象システムにrobots.txt（RPAによるアクセス範囲を示すファイル）は設置されていないことを確認 社内承認 — リスクマネジメント部門に事前相談し、問題ないとの確認を取得 負荷への配慮 — 人間が操作するのと同等の速度で動作させ、未知のエラー発生時には自動停止する設計 おわりに — 属人化しない自動化を目指して 「あなたがいなくなったらどうなるの？」 ——避けられない問いです。実際、過去に社内で作られたRPAも引き継ぎがうまくいかず使われなくなった経緯があります。だからこそ、トラブルシューティングガイドや運用手順書といったドキュメントを整備するようにしています。そして何より、 AIがメンテナンスの「通訳」になれる 可能性に期待しています。コードを読めなくても、AIにエラーメッセージを貼れば対処法が返ってくる。作った人がいなくなっても回せる仕組みを作ること——その「属人化しない自動化」を目指して、今も試行錯誤を続けています。 データ移行支援ツールはまだ完成していません。模索中のことも多くあります。でも、非エンジニアだからこそ「使う側の目線」で作れる強みがある。業務を深く理解した人間にしか書けない要件定義がある。そしてAIが、その要件定義をコードに落とし込んでくれる。 自分で作るようになって、大きな気づきがありました。先述のPythonアップデートで動かなくなった経験を通じて、社内のエンジニアがフレームワークや基盤の更新に日々取り組む大変さを、身をもって理解できました。大規模なシステムを止めずに改善し続けるエンジニアの仕事に対する解像度が上がったことで、協業の質も変わったと感じています。非エンジニアが自分で作る経験は、エンジニアとの共通言語を増やすことにもつながるのです。 この記事を読んで、「自分もやってみよう」と思ってくれる方が一人でもいたら、書いた甲斐があります。最初の一歩は、「AIで何ができるか」を考えることではありません。「こんな作業が大変なんだよね」と、AIに壁打ちしてみること。そこに、活用のヒントがあるかもしれません。 追伸： 実はこの記事自体も、大部分をAIに書いてもらっています。構成案の作成、文章の推敲、さらには実際のプログラムと記事の内容に食い違いがないかの確認まで、AIと一緒に進めました。 ただし、「何を伝えたいか」「どんなストーリーで読者に届けるか」——その核となる設計は、自分の頭で考えました。AIは優秀な道具ですが、魂を込めるのは人間の仕事です。ツール開発もブログ執筆も、そこは変わらないと思います。

1. はじめに 昨今、生成AIの進歩が加速しており、Web検索や調査に生成AIを利用することは日常では最早当たり前の光景となっています。Web検索はChatGPTをはじめ、多くの生成AIツールで利用できる機能です。一方、ブラウザやWebサイト操作については、あらかじめユーザーが設定した操作を実行させるRPAツールやHTML構造を解析して情報を取得するスクレイピングツールが主流となっています。定型的な作業であれば、RPAツールやスクレイピングツールを利用すれば一見問題なさそうに見えます。しかし、Webページの構造は変化する可能性があり、変化した際はその都度設定を変更する必要があります。

こんにちは！Insight Edge リードコンサルタントの山田です。 私は普段から事業会社におけるAI/デジタル活用のご相談を多く受けているのですが、この記事では、生成AIで解くべきではない課題にフォーカスしながら、業務活用における生成AIの向き/不向きを整理してみたいと思います。 AI活用があらゆる企業で経営マターに 生成AI活用の肝は“課題選定” 業務パターンごとの生成AIとの相性を理解する ①定型プロセス × 許容幅 広い　—— 　◎生成AIの得意領域 ②非定型プロセス × 許容幅 広い　——　◎生成AIの本領を発揮しやすい ③定型プロセス × 許容幅 狭い　——　△AIが適切でないケースあり ④非定型プロセス × 許容幅 狭い　——　★設計次第では効果大 AIには得意なことだけをやらせる 例：投資判断プロセス 相性がよいパターンであっても、「プロセスの長さ」には注意 実際の業務で適切な課題を設定するために AI活用があらゆる企業で経営マターに 2025年はAIエージェント元年ともいわれ、企業における生成AIやAIエージェントに関する活用事例はさらに増えました。「AI活用」が経営アジェンダの最上位マターに位置付ける企業も珍しくなくなり、弊社でも引き続きAIエージェント開発、AI CoE組織立ち上げ、教育/ワークショップなど、多岐にわたるAIプロジェクトを推進しています。 事業会社の経営層との会話でも「AIで何かできないか」というご相談は本当に多くいただいていますし、経営トップが旗を振ってAI活用を推進するケースも目に見えて増えてきました。 具体的には 前回記事 でもご紹介したような社内ナレッジ検索や投資判断への意思決定支援に加え、この1年はマルチAIエージェントによる事業開発・投資判断高度化プロジェクトなど、目に見える成果が出ている領域は確実に広がっています。 生成AI活用の肝は“課題選定” 一方で、様々な場面でAI活用ユースケースが生まれ、世の中がAIエージェント一色の状況でよくあるのが、「ハンマーを持つとすべてがクギに見える」ような、すべての業務課題にAIエージェントを適用しようとしてしまうことです。 Nano Banana Proを利用して作成 属人化している業務をAIがいい感じに判断し実行してほしい 一連の業務フローをAIで自動化したい このようなニーズも少なくないのですが、業務プロセスが明確でなかったり、業務知見や商習慣など考慮すべきコンテキストが与えられない状況だと、意図するアウトプットを得ることは非常に難しいです。 AIは強力なツールである一方で、向いていない/苦手な業務に適用しようとすると、期待した効果や精度が出ず、「業務では使えない」という判断になってしまうことにもなりかねません。AIの技術的な問題というより課題設定の問題であるにも関わらず、AI＝使えないとなってしまうのが一番もったいないです。実際の業務においてはAIが向いているパターン、向いていないパターンがあり、課題選定の段階で正しいテーマ設定をすることが、生成AI活用がうまくいくための第一歩です。 業務パターンごとの生成AIとの相性を理解する 効率化・高度化したい業務においてAI活用するべきかを考える上で、以下の２つの軸で業務を分類することが有効です。 軸１：業務プロセスの定型度（定型 vs非定型 ） 手順やルールが決まっているか、状況に応じてプロセス自体が変わるか 軸２：アウトプットの許容幅（広い vs 狭い） だいたい合っていればOK（面的）か、正解が一意（点的）か Nano Banana Proを利用して作成 ①定型プロセス × 許容幅 広い　—— 　◎生成AIの得意領域 業務プロセスの手順が決まっていて、出力も「だいたい合っていればOK」な業務。生成AIの導入効果が出やすく、個人/組織の身近な業務で恩恵を感じやすいです。 会議の議事録要約 日報など定型レポート生成 FAQ・問い合わせへの一次回答 コード生成・リファクタリング ②非定型プロセス × 許容幅 広い　——　◎生成AIの本領を発揮しやすい プロセスも出力も「これが正解」が決まっておらず、アウトプットの幅の広さが価値となる業務。生成AIの柔軟性が最も活きる場面であり、使い方次第で効果が大きく変わってくる領域です。 新規事業・企画のアイデア出し 戦略仮説の壁打ち・論点整理 プロダクトのUX改善案出し ペルソナ作成・ユーザーシナリオ生成 ③定型プロセス × 許容幅 狭い　——　△AIが適切でないケースあり 手順もルールも明確で、出力もブレてはいけない業務。この領域はルールベースやRPAなど従来型システムでシステム的に処理した方が適切なケースも多く、わざわざ確率的な振る舞いをするAIが最適とは限らない領域です。 経費精算・請求処理のデータ入力 発注・検収処理 条件分岐が明確な承認フロー判定 ④非定型プロセス × 許容幅 狭い　——　★設計次第では効果大 プロセスに決まった正解がなく状況に応じた判断が必要かつ、アウトプットには高い正確性が求められる業務。適切にワークさせる難易度が高い一方、設計次第ではAIによる恩恵が大きい領域です。 投資判断や経営の意思決定（Go/No-Go） 個別事象を加味した契約書レビュー 与信審査の最終判定 カントリーリスク評価やDDレポート生成 AIには得意なことだけをやらせる ③や④のような、出力の許容幅が狭い（≒正確性が求められる）パターンでも、設計次第で十分業務に活用できます。AIには得意なことだけをやらせる、逆に言えば苦手なことは何らか別の方法で補完することで、一連の業務を品質高く実行できます。 RAGや外部ツール利用による知識補完/スキル補完、人間のレビューを「仕組み」として組み込むこと（Human-in-the-Loop）などが有効です。 例：投資判断プロセス 情報収集・整理フェーズ（AI） 対象企業/マーケットに関する外部情報や社内の案件資料をRAGで検索し、様々な情報を収集・整理したり、過去の類似投資案件の議事録などをもとに当時議論された論点を抽出する 定量分析フェーズ（従来型システム） 財務モデルに基づくバリュエーション算出、感応度分析、各種指標の計算。「数字を正確に出す」ことが求められるため、ルールベースの計算エンジンを使用 論点整理・リスク洗い出しフェーズ（AI） 収集した情報と定量分析の結果を踏まえ、検討すべきリスク論点を構造化して提示する。「過去の類似案件ではカントリーリスクが争点になった」「この業界ではこの規制変更が影響しうる」など、人間が見落としやすい観点を補完する。 意思決定フェーズ（人間） AIが整理した判断材料と従来型システムが算出した定量データを踏まえ、Go/No-Goを最終決定する。 Nano Banana Proを利用して作成 相性がよいパターンであっても、「プロセスの長さ」には注意 また、いずれのパターンにおいても業務プロセスが長く連鎖する場合は、うまくいかないケースが出てきます。AIの出力は確率論でしかないので、1ステップの精度が90%であっても、それが10回続くとすべて成功する確率は35%まで下がります。プロセス全体を一気通貫でAIに実行させるのではなく、AIのタスクを分解してモジュール化（カタマリ化）し、各モジュールの間で人間の確認ポイントを挟むことで、全体の精度を担保する業務設計が必要になります。 実際の業務で適切な課題を設定するために とはいえ、実際の業務は複数のステップや要素が絡み合っているので、そのままマトリクスに当てはめられるほど単純ではないことがほとんどです。現場でAI活用の課題設定を行う際には、 ①業務プロセスを分解して可視化する 属人的/暗黙知化しているプロセス含め、業務フローを洗い出す ②ステップごとに「出力の許容幅」を確認する だいたい合っていればOKなのか、確実な正解が必要か ③AIと人間の役割分担を設計する 人が介在する余地を残し、AIにすべてを任せない この辺りを意識して業務を見直し、AI活用する場合の業務フローを設計していくことが重要です。ある意味地味なプロセスですが、業務で使われるAIを作るためにはとても重要なポイントだと思います。