AIログ分析で改善ポイントを見つけ運用改善につなげる実践手順

ログは取れているのに、次に何を直せばいいのかが分からないんです

ある製造業の会議室で、DX推進部の森田さん(仮名)がそう言いました。テーブルの上には、AIチャットの利用回数、部門別のアクセス数、プロンプトログの一覧が並んでいました。数字は確かにあります。グラフも作られています。けれど、会議室の空気はどこか重いままでした。

情シスの担当者は「利用は増えています」と報告します。一方で、現場部門のマネージャーは「うちのチームでは、まだ使い方が分からない人が多い」と言います。営業部門からは「提案書の下書きには使えるけれど、出力の品質にばらつきがある」という声も出ていました。

筆者はこの場面を見ながら、AI活用が次の段階に入ったことを感じました。導入初期は「まず使ってもらうこと」が課題です。しかし、一定数のAI利用ログが溜まり始めると、次に必要になるのは「使われ方から学ぶこと」です。

同社では半年前にKANATA AIのAIチャットやAI要約を導入し、AI利用ログやプロンプトログを収集していました。しかし、月次会議で確認していたのは、主に利用回数の推移でした。「営業は使っているが、品質管理では定着していない」「同じ失敗事例がSlackで何度も共有される」といった声があっても、具体的な改善施策には落とし込めていなかったのです。

そこで直近90日間、対象12部門・1,842件の利用ログを、質問内容、失敗パターン、ユーザー行動、部門別セグメントに分けて確認しました。その結果、回答の再生成が多い業務、途中離脱が多いプロンプト、利用が伸びているチームの共通点が見えるようになりました。現在は、月1回のAI改善サイクルの中で、優先順位付きの改善施策に落とせる状態になっています。

この記事では、AI ログ分析を通じて、ログ可視化 AIやベンチマークをどう使い、AI 運用 改善のPDCAにつなげるかを整理します。目指すのは、ログを眺めるだけでなく、次の教育、プロンプト改善、業務設計に反映できる状態です。ただし、ログ分析だけで全てが解決するわけではありません。現場ヒアリングや運用ルールの見直しと組み合わせて初めて、再現性のある改善につながります。

AI利用ログは改善活動の「結果」ではなく「材料」です

生成AIを導入した企業では、まず利用率が注目されます。

何人が使ったのか。何回質問されたのか。どの部門で利用が多いのか。これらは、AI活用の広がりを把握するうえで重要な指標です。

しかし、利用回数だけを見ても、業務AIが本当に役に立っているかは分かりません。

筆者がAI導入支援の現場でよく見るのは、「利用回数が増えているから順調です」と報告されているものの、現場の満足度はあまり高くないケースです。数字上は使われています。しかし実際には、何度も聞き直していたり、回答をそのまま使えずに人が大きく修正していたりすることがあります。

たとえば、ある部署でAIの利用回数が多かったとしても、それが「便利だから何度も使われている」のか、「うまく答えが出ずに何度も聞き直されている」のかは、ログを深く見なければ判断できません。

逆に、利用回数が少ない部署でも、数回の利用で業務に大きな効果が出ている可能性もあります。月に数回しか使っていなくても、重要な提案書作成や経営会議資料の整理に使われているのであれば、業務インパクトは小さくありません。

AI利用ログは、単に活用状況を報告するための数字ではありません。現場のつまずき、業務設計のズレ、教育不足、プロンプト改善の余地を見つけるための材料です。

重要なのは、「どれだけ使われたか」だけでなく、「どこで詰まったか」「なぜ継続利用されなかったか」「どの使い方が成果につながったか」を見ることです。

AIログ分析で見るべき基本観点

AI ログ分析を始めるときは、最初から細かく見すぎる必要はありません。ログを前にすると、つい全てを分析したくなります。しかし、あまりに細かく見すぎると、かえって次の打ち手が見えなくなります。

まずは、利用頻度、プロンプトログ、失敗事例、ユーザー行動、セグメント分析の5つに分けて確認すると、改善ポイントを見つけやすくなります。

利用頻度：誰が、どの業務で使っているか

最初に見るべきは、AIの利用頻度です。

ただし、「全社で何回使われたか」だけでは不十分です。部門別、職種別、業務別に分けて確認することで、AI活用の濃淡が見えてきます。

たとえば、営業部門では提案書のたたき台作成に使われている一方で、管理部門では規程確認や問い合わせ対応に使われているかもしれません。開発部門では仕様整理、マーケティング部門では記事構成や広告文案の作成に使われていることもあります。

このとき大切なのは、利用が多い部署を単純に「優秀」と見なさないことです。AIの利用頻度は、部署の業務特性にも左右されます。文章作成が多い部門では使いやすく、現場作業が中心の部門では使う場面が見えにくいこともあります。

改善の第一歩は、利用が多い理由と少ない理由を分けて考えることです。利用が多い部署には成功パターンがあります。利用が少ない部署には、業務導線、教育、心理的ハードルのどこかに課題がある可能性があります。

プロンプトログ：どの質問が成果につながっているか

次に見るべきは、プロンプトログです。プロンプトログとは、ユーザーがAIに入力した指示や質問の記録を指します。

プロンプトログには、社員がAIにどのような依頼をしているかが残ります。ここには、現場の悩みや業務のクセがそのまま表れます。

たとえば、次のような質問が多い場合、背景にある課題はそれぞれ異なります。

• この文章を分かりやすく直して
• 議事録を要約して
• この顧客向けに提案書を作って
• 社内規程に沿って回答して
• 上司向けに短くまとめて

一見すると、どれも一般的なAI活用に見えます。しかし、ログを集計すると、文章作成に偏っているのか、要約に偏っているのか、社内ナレッジ検索に使われているのかが見えてきます。

プロンプトログを見るときは、うまくいかなかった質問だけでなく、うまくいった質問も確認します。成果につながったプロンプトには、共通点があることが多いためです。目的が明確で、前提情報があり、出力形式が指定されているプロンプトほど、実務で使いやすい出力につながりやすくなります。

たとえば、「議事録を作って」よりも、「以下の会議メモを、決定事項、TODO、未決事項、次回確認事項に分けて、社内共有用にまとめてください」と依頼した方が、利用者の期待に近い出力になりやすいでしょう。

Kanataのように、よく使う指示文をプロンプトライブラリとして保存・共有できる環境では、成果につながったプロンプトを個人の工夫で終わらせず、組織の共通資産にしやすくなります。これは、他のAIツールでもテンプレート管理やナレッジ共有の仕組みがあれば同様に実践できます。

失敗事例：どこで回答品質が落ちているか

AI運用改善で特に重要なのが、失敗事例の分析です。

失敗事例とは、単に「AIが間違えた回答をした」ケースだけではありません。たとえば、次のようなログも改善対象になります。

• 何度も同じ質問を言い換えている
• 回答後にすぐ再生成している
• 出力結果をコピーせずに離脱している
• 「違います」「そうではなく」と追加で指示している
• 最終的に人へ確認している

これらは、AIの回答がユーザーの期待に届いていない可能性を示すサインです。

筆者は、失敗ログこそ価値のあるログだと考えています。なぜなら、失敗ログには、ツール、業務、教育、データ設計のどこにズレがあるかが表れやすいからです。

ただし、失敗ログを見てすぐに「AIの精度が悪い」と判断するのは早計です。原因は、AIモデルそのものではなく、プロンプトの曖昧さ、参照データの不足、業務ルールの未整備、ユーザー教育の不足にあることも多いからです。

たとえば、「社内規程についてAIに聞いたが、一般論で返ってきた」という失敗が多い場合、規程資料がAIの参照対象になっていない、または回答時に出典を明示させる指示が設定されていない可能性があります。

Kanataでは、社内資料やFAQ、業務ルールを学習データとして整理し、AIチャットやAI要約で参照しやすくする運用ができます。ただし、資料を登録すれば自動的に全てが解決するわけではありません。古い資料や矛盾した資料が混ざっていないか、誰が更新責任を持つのかまで決めておく必要があります。

ユーザー行動：回答後に何が起きているか

AI利用ログを見るときは、質問内容だけでなく、回答後のユーザー行動も確認します。

AIの回答をユーザーがコピーしている場合、その回答は一定の実用性があった可能性があります。一方で、回答後すぐに別の質問へ移ったり、再生成を繰り返したりしている場合は、期待した答えに届いていないかもしれません。

見るべき行動は、次のようなものです。

• 回答をコピーしたか
• 続けて質問したか
• 再生成したか
• 会話を途中で離脱したか
• 同じテーマで別のチャットを立てたか
• どの時間帯に利用が集中しているか

特にBtoBの業務AIでは、「使われたか」よりも「業務の次の行動につながったか」が重要です。回答がコピーされたのか、社内共有されたのか、議事録や提案書に転用されたのかを見ることで、AIが業務の中でどの位置に入っているかが分かります。

たとえば、AI要約のログで、出力後にコピーされる割合が高い場合、その要約フォーマットは現場に合っている可能性があります。逆に、要約は生成されているもののコピーされていない場合、見出し構成や粒度、トーンが実務に合っていない可能性があります。

ログは数字として冷静に見ます。しかし、その数字の向こう側には、必ず人の行動があります。筆者は、ログ分析の会議ではいつも「この数字の裏で、現場の人は何をしていたのか」を問い直すようにしています。

セグメント分析：部門・役職・業務ごとの差を見る

全社平均だけでAI利用ログを見ると、改善ポイントを見落としやすくなります。

たとえば、全社平均の利用率が30％だったとしても、営業部門では70％、管理部門では15％、製造現場では5％かもしれません。この場合、全社平均だけを見て「まだ活用が足りない」と判断しても、適切な施策にはつながりません。

営業部門には成功パターンの横展開が必要かもしれません。管理部門には社内規程やFAQの学習データ整備が必要かもしれません。製造現場には、PC操作を前提にしたAI活用ではなく、スマートフォンや定型フォームを使った導線が必要かもしれません。

セグメント分析では、最低でも次の切り口を確認します。

• 部門別
• 役職別
• 業務別
• 利用歴別
• 利用頻度別
• 成功プロンプトの有無
• 教育受講の有無

このように分けて見ることで、「誰に、どの改善施策を届けるべきか」が明確になります。

筆者が支援する現場でも、同じAIツールを導入しているのに、部門ごとにまったく違う結果が出ることがあります。その差は、ツールの差ではなく、業務への組み込み方、上司の関与、成功事例の共有、入力ルールの明確さによって生まれていることが多いです。

【ログ可視化】AIは改善判断の共通言語になる

AI利用ログは、CSVや管理画面の一覧で眺めるだけでは改善に使いにくいものです。そこで役立つのが、ログ可視化 AIやダッシュボードです。

ただし、可視化すれば自動的に改善ポイントが見つかるわけではありません。きれいなグラフを作ることと、改善の意思決定ができることは別です。筆者も、何度も「ダッシュボードはあるのに、誰も次の打ち手を決められない」という現場を見てきました。

ログ可視化では、まず指標を絞ることが大切です。最初から全てのログを見ようとすると、かえって何を改善すべきか分からなくなります。

共通して押さえておきたい基本指標は、次の5つです。

ここで大切なのは、単一の数字だけで判断しないことです。

利用回数が多くても、再生成率が高ければ、ユーザーは不満を抱えている可能性があります。利用回数が少なくても、コピー率や継続利用率が高ければ、特定の業務ではすでに効果が出ている可能性があります。

ログ可視化 AIは、数字をきれいに見せるためのものではありません。現場が次に何を直すべきかを話し合うための共通言語です。

Kanataのように、チャット、要約、学習データ、プロンプトを同じ業務基盤の中で扱える環境では、ログから見えた課題を改善施策に戻しやすくなります。たとえば、再生成が多いプロンプトはテンプレート化する。一般論の回答が多い領域は学習データを整備する。利用が少ない部門には、その部門向けのユースケース研修を設計する。このように、ログと改善施策をつなぐことが重要です。

AI改善サイクルは分析して終わりにしない

AI ログ分析でよくある失敗は、分析レポートを作って満足してしまうことです。

月次でダッシュボードを確認し、「営業部門の利用が多い」「要約機能の利用が増えている」「一部部署では利用が少ない」と報告するだけでは、AI 運用 改善にはつながりません。

重要なのは、ログ分析をPDCAに接続することです。PDCAとは、計画、実行、確認、改善を繰り返す管理手法です。筆者は、AI活用を定着させるうえで、派手な施策よりもこの地味なPDCAの方が大切だと考えています。

分析目的を決める

まず、何を改善したいのかを決めます。

たとえば、目的は次のように分けられます。

• 利用率を上げたい
• 回答品質を安定させたい
• 特定部門での定着率を上げたい
• 失敗事例を減らしたい
• 成功プロンプトを横展開したい
• 問い合わせ対応時間を短縮したい

目的が曖昧なままログを見ると、数字を眺めるだけで終わります。最初に改善テーマを決めることで、見るべきログが絞られます。

たとえば、「AI活用をもっと進めたい」では広すぎます。「営業部門で提案書作成に使われているAIチャットの再生成率を下げたい」と言えれば、見るべきログも改善策も具体的になります。

対象期間と対象ログを決める

次に、対象期間と対象ログを決めます。

たとえば、「直近30日間の全社ログ」なのか、「直近90日間の営業部門ログ」なのか、「研修実施前後の2か月比較」なのかで、見えるものは変わります。

数値を扱う場合は、必ず期間、対象部門、対象件数を明確にします。

悪い例

AI利用が増えました。

良い例

2026年1月1日から3月31日までの90日間で、営業部門のAIチャット利用回数は月412件から月689件に増えました。

このように条件を明確にすることで、改善活動の検証ができるようになります。

筆者は、AIログ分析では「数字そのもの」よりも「比較できる状態」を重視しています。比較軸がなければ、増えたのか、減ったのか、改善したのか、悪化したのかを判断できないからです。

失敗パターンを分類する

次に、失敗ログを分類します。

代表的な分類は、次のとおりです。

この分類ができると、AIの改善を「モデルの問題」だけで考えなくなります。改善すべき対象が、教育なのか、プロンプトなのか、学習データなのか、業務フローなのかを切り分けられます。

ここで重要なのは、失敗を個人のスキル不足にしないことです。「社員がうまく聞けていない」で終わらせると、組織として改善できません。なぜうまく聞けないのか。テンプレートがないのか。業務例がないのか。入力してよい情報の線引きが曖昧なのか。そこまで掘る必要があります。

優先順位をつける

改善施策は、一度に全て実行しようとしないことが大切です。

優先順位をつけるときは、次の2軸で考えると整理しやすくなります。

• 改善インパクトが大きいか
• 実行しやすいか

たとえば、全社共通で使われている議事録要約のプロンプトを改善する施策は、比較的実行しやすく、影響範囲も広い可能性があります。一方で、基幹システムとの連携や大規模な権限設計変更は、効果が大きくても実行難易度が高くなります。

まずは、「効果が見えやすく、実行しやすい施策」から始めるのが現実的です。

筆者は、AI活用の現場では「大きな改革」よりも「小さな改善の連続」を重視しています。1つのプロンプトを直す。1つの学習データを更新する。1つの部門向けに使い方を共有する。その積み重ねが、数か月後に大きな差になります。

翌月のログで検証する

最後に、改善施策を実行したあと、必ず翌月のログで検証します。

たとえば、議事録プロンプトを改善した場合、見るべき指標は次のようになります。

• 議事録要約の利用回数は増えたか
• 再生成率は下がったか
• コピー率は上がったか
• 利用者の所属部門は広がったか
• Slackや会議での不満コメントは減ったか

ここまで見て初めて、AI 改善 サイクルが回っていると言えます。ログ分析は、分析レポートを作るためではなく、次の改善を判断するためにあります。

よくある失敗事例と改善の方向性

AI利用ログを分析すると、多くの企業で似た失敗事例が見つかります。ここでは、共通して押さえておきたい代表例を紹介します。

利用回数は多いが、再生成も多い

利用回数が多い部署を見ると、一見するとAI活用が進んでいるように見えます。しかし、再生成率が高い場合は注意が必要です。

ユーザーが何度も回答を作り直している場合、最初の回答が期待とずれている可能性があります。

この場合の改善策は、プロンプトテンプレートの整備です。

「何を出してほしいか」だけでなく、「誰向けか」「どの形式か」「何文字程度か」「どの情報を使うか」を入力できるようにします。Kanataでは、成果につながったプロンプトをライブラリに登録し、社内で再利用できる形にしておくと、個人ごとの聞き方の差を減らし、出力品質を安定させやすくなります。

一部の人だけが使っている

AI活用が一部の社員に偏ることもよくあります。

この場合、使っていない人を責めても定着しません。ログを見ながら、「なぜ使われないのか」を分解する必要があります。

理由はさまざまです。

• どの業務で使えばよいか分からない
• 使う時間がない
• 入力してよい情報の判断が怖い
• AIの回答を信頼できない
• 上司やチームが使っていない

この場合は、部門別のユースケース提示や、入力してよい情報、いけない情報のルール整備が必要です。AI活用の定着には、ツールの導入だけでなく、安心して使える運用ルールが欠かせません。

筆者の経験では、AIを使わない理由の多くは「興味がない」ではありません。「使って失敗したくない」「何を入れてよいか分からない」「上司がどう評価するか分からない」という不安です。だからこそ、ログ分析と同じくらい、現場の心理的ハードルを見ることが重要です。

成功プロンプトが共有されていない

ある社員はAIをうまく使っているのに、別の社員は使いこなせていない。この差が広がると、AI活用は属人化します。

ログを見ると、成果につながっているプロンプトには共通点があります。前提情報が具体的で、出力形式が明確で、判断条件が書かれていることが多いです。

成功プロンプトを見つけたら、個人の工夫で終わらせず、チームのテンプレートにします。たとえば、議事録、提案書、問い合わせ対応、週報、1on1準備など、繰り返し使う業務からテンプレート化すると効果が出やすくなります。

Kanataでは、よく使う指示文をチームで再利用できる形にし、業務ごとにプロンプトを整理しておけます。AIに慣れている人だけが成果を出す状態から、チーム全体で一定の品質を出せる状態へ移行したい場合に有効です。

AIが一般論しか返さない

「AIに聞いても、一般論しか返ってこない」という声もよくあります。

この場合、AIそのものの問題ではなく、参照できる社内データが不足している可能性があります。

社内規程、商品資料、FAQ、過去提案書、議事録、研修資料などを学習データとして整理しておくと、AIは自社の文脈に沿った回答をしやすくなります。

ただし、何でも登録すればよいわけではありません。古い資料、矛盾した資料、機密性の高い資料が混ざると、かえって回答品質が下がることもあります。学習データは、定期的な棚卸しと更新が必要です。

筆者は、学習データの整備を「AIに資料を入れる作業」ではなく、「会社の知識を整える作業」と捉えています。AIが答えられない領域は、そもそも社内でも情報が整理されていない領域であることが少なくありません。

Kanataを使う場合はログと改善施策を同じ流れで扱いやすい

AI運用改善を進める際には、利用するツールの選択肢はいくつもあります。汎用的な生成AIサービス、社内チャットボット、BIツール、ログ分析基盤、ナレッジ管理ツールなどを組み合わせる方法もあります。

その中でKanataを使う場合の特徴は、AIチャット、AI要約、プロンプト管理、学習データ管理、学習コンテンツを、業務運用の中でつなげやすい点にあります。

たとえば、AIチャットのログから「議事録要約の依頼が多い」と分かった場合、次に行うべきことは、議事録用のプロンプトを整備することです。さらに、そのプロンプトをプロンプトライブラリに登録し、全員が同じ型で使えるようにします。

また、社内ルールに関する質問が多い場合は、規程やFAQを学習データとして整理し、回答時に根拠を示す運用に変えることができます。

さらに、同じ失敗事例が繰り返されている場合は、短い学習コンテンツや社内勉強会に反映し、社員向けのミニ研修として展開できます。

つまり、ログ分析の結果は、次の4つの改善に接続できます。

• プロンプト改善
• 学習データ整備
• 業務フロー見直し
• 社員教育

ログを見て終わりにせず、日常業務で使うAI環境に戻していくことで、AI運用改善は継続しやすくなります。

筆者がKanataのような業務AI基盤に期待しているのは、単にAIを使えることではありません。現場のログから課題を見つけ、プロンプトを直し、学習データを整え、教育につなげ、またログで検証する。この循環を、ひとつの業務基盤の中で回しやすいことです。

AI活用は、導入して終わるものではありません。むしろ、導入後にようやく本当の改善が始まります。

AIログ分析を定着させるには月次レビューが有効です

AI ログ分析は、一度だけ実施しても大きな効果は出にくいものです。運用改善につなげるには、月次レビューとして定着させる必要があります。

月次レビューでは、次のような流れが現実的です。

1. 前月の利用ログを確認する
2. 利用が増えた業務・減った業務を見る
3. 再生成率や離脱が多いログを確認する
4. 成功プロンプトと失敗事例を共有する
5. 改善施策を3つ以内に絞る
6. 翌月の検証指標を決める

ここで大切なのは、情シスやDX推進部だけで完結させないことです。ログの数字だけでは、現場で何が起きているか分からないことがあります。

たとえば、ある部門で利用が減っていたとしても、AIが不要になったわけではなく、繁忙期で使う余裕がなかっただけかもしれません。逆に、利用が増えていても、現場では「仕方なく使っているが精度には不満がある」という状態かもしれません。

数字と現場の声を合わせて見ることで、ログ分析は初めて改善活動になります。

筆者が月次レビューでよく使う問いは、次の3つです。

• このログから、現場のどんな困りごとが見えるか
• 来月までに、何を1つだけ変えるか
• その改善が効いたかどうかを、どのログで確認するか

この3つに答えられれば、AIログ分析は報告資料ではなく、運用改善の道具になります。

AI利用ログを扱うときは監視ではなく改善を目的にする

AI利用ログは便利ですが、扱い方には注意が必要です。

まず、ログを社員の監視に使わないことです。誰が何回使ったか、誰のプロンプトが未熟かを指摘するためにログを見ると、社員はAIを使わなくなります。ログ分析の目的は、個人を評価することではなく、業務と環境を改善することです。

次に、ログだけで現場を判断しないことです。ログには行動の痕跡は残りますが、その背景にある事情までは分かりません。利用が少ない理由が、ツールへの不満なのか、業務上の必要性が低いのか、繁忙期なのか、心理的な不安なのかは、現場に聞く必要があります。

また、ログに含まれる情報の取り扱いにも注意が必要です。プロンプトログには、顧客名、案件情報、社内資料の内容などが含まれることがあります。分析時には、アクセス権限、閲覧範囲、匿名化、保存期間を明確にしておく必要があります。

日本では、経済産業省・総務省がAI事業者ガイドラインを公表し、AIを活用する事業者に対して、リスクの認識、ライフサイクル全体での対策、関係者との連携などを促しています。また、NISTのAI Risk Management Frameworkや、OECD AI Principlesでも、AIの信頼性、リスク管理、人間による監督の重要性が示されています。

AI運用改善は、便利さと安全性の両立が欠かせません。ログを見る範囲、見る目的、改善への使い方をあらかじめ明確にしておくことが、社員の信頼を守るうえでも重要です。

まとめ：AI利用ログは現場改善の地図になる

AI利用ログは、単なる利用実績ではありません。

どの業務でAIが使われているのか。どこでつまずいているのか。どのプロンプトが成果につながっているのか。どの部門に教育が必要なのか。どの学習データを整備すべきなのか。

これらを見つけるための、現場改善の地図です。

ただし、ログだけを見ても答えは出ません。ログはあくまで、改善ポイントを見つけるための手がかりです。現場ヒアリング、業務設計、プロンプト改善、学習データ整備、教育施策と組み合わせて初めて、AI 改善 サイクルは回り始めます。

筆者は、AI導入の現場でいつも「使わせる」よりも「使われ方から学ぶ」ことを重視しています。AIは導入した瞬間に完成するものではありません。現場で使われ、失敗し、直され、また使われることで、ようやく業務に馴染んでいきます。

ログを取りっぱなしにせず、月に一度でも見直す場を作る。小さな改善施策を決める。翌月のログで変化を見る。この繰り返しが、AIを一時的なツールではなく、業務に定着する仕組みに変えていきます。

Q&A：AIログ分析と運用改善でよくある質問