レポート目次 Report contents 第3章 Chapter 3

R-CCSの有人サポート業務へのAskDonaの導入効果 Effects of Introducing AskDona into R-CCS's Human Support Operations

生成AIチャット「AskDona」の導入は、利用者の自己解決を促進するだけでなく、「富岳」サポートサイトにおける有人サポートの動向にも明確な変化をもたらした。本章では、従来、サポート担当者が人手で対応していたフォーム作成による問い合わせ(チケット)の発行数がAskDona導入後にどう変化したかを分析し、その導入効果を考察する。ここで言う「チケット」とは、利用者が問い合わせシステムを通じて発行する、個別の問い合わせ件数を指す。

本章のデータを評価する上で、「富岳」の利用者数が2022年度から約1割増加しているという利用者増のトレンドを念頭に置く必要がある。通常、利用者数が増えれば、それに比例して問い合わせ件数も増加することが想定される。また、「富岳」の利用には研究プロジェクトの開始時期などに伴う季節性もあるため、単純な月次推移だけでなく、前年同月との比較が、導入効果を測る上でより客観的な指標となる。この利用者数の推移は、図3に示す。「富岳」は2021年3月9日から共用を開始し、全ノード(158,976ノード)を課題採択された利用者に提供している。

図3 「富岳」の登録利用者数及び課題数

3.1 有人対応チケット数の推移

AskDona導入による最も直接的な効果は、有人対応チケット数の変化に現れている。本節では、まず長期的な傾向を四半期ごとの推移(図3.1-1)で示し、次いで前年同月比(図3.1-2)でその変化を詳細に分析する。

図3.1-1は、2022年Q2(4月-6月)以降の新規チケット発行数の四半期推移をカテゴリ別に示したものである。AskDonaは、特に「質問」カテゴリの問い合わせに対する一次対応を担う。図を見ると、2024年7月にAskDonaを導入した後も、「質問」チケット数は四半期あたり200件未満で安定して推移していた。しかし、2025年2月に質問フォーム(チケット作成)をAskDona経由に変更して以降、チケット数に大きな変化が見られた。2025年Q1(1月〜3月)の「質問」チケット数は約120件で、前年同期比で約40%減少し、2025年Q2は約100件で、前年同期比で約53%の減少となった。

図3.1-1 新規チケット発行数の四半期推移

この減少傾向をより詳細に分析するため、質問カテゴリのチケット数を前年同月比で示したものが図3.1-2である。導入直後の併用期間(2024年7月〜12月)においては、削減効果は限定的であり、前年同月比で微減から微増の範囲で推移した。これは、多くの利用者が従来の有人サポートを選択したためと考えられ、新しいツールが提示されても、利用者の行動変容には一定の時間を要することを示している。

チケット作成をAskDona経由に変更した2025年2月以降、チケット数が明確に減少した。具体的には、2025年2月は前年同月比で約42%減、3月は約51%減、そして4月には約61%減と削減効果がみられた。

図3.1-2 有人問い合わせ件数と前年同月比増減率の推移

3.2 対応時間と効率からみる有人と生成AIの役割分担

AskDonaの導入は、3.1節で示した有人対応の「件数」削減だけでなく、問い合わせ対応の「効率」にも変化をもたらした。本節では、具体的な問い合わせ事例を基に、AskDonaが対応時間をどのように短縮し、サポート業務の効率化に貢献するかを示す。

AskDonaは、特に過去に回答例がある質問や、マニュアル等の文書に記載されている情報を探索するタイプの問い合わせにおいて、その効果を最大限に発揮する。以下の事例は、こうした問い合わせにおけるAskDonaの時間短縮効果を具体的に示すものである。

事例:AskDonaによる時間短縮が期待される問い合わせ例

質問

バッチジョブ投入時に cannot execute binary file のエラーが出て実行できません。コンパイル済みのC言語プログラムとスクリプトを添付します。原因と、ディレクトリ設定に関する注意点を教えていただけますか?

有人対応回答例 対応時間:回答まで要した時間 約4時間

【1】Exec format errorの原因。富岳ではログインノード(x86_64)と計算ノード(A64FX)でCPUアーキテクチャが異なるため、互換性のないバイナリを実行するとExec format errorが発生します。ログインノードの /bin/gcc などでビルドされた実行ファイルは、計算ノードでは動作しません。

対応策:計算ノード用バイナリは、下記のようにfccpxを使ってビルドしてください。

fccpx in.c

【2】使用可能ディレクトリについて。以下のディレクトリが使用可能です:

  • ホームディレクトリ(最大20GiB)
  • 課題データディレクトリ(大容量データ処理向け)
  • 課題間シェアディレクトリ

容量・パフォーマンスの観点から、データディレクトリの利用を推奨します。

AskDona回答 対応時間:回答まで要した時間 約5秒

考えられる原因

  • 実行ファイルのアーキテクチャの不一致:計算ノード(A64FX)上でx86_64バイナリが実行されている可能性があります。富岳の計算ノードで実行するためのバイナリは、適切なコンパイラを使用して作成する必要があります [1]。
  • カレントディレクトリの問題:ジョブ投入時のカレントディレクトリにグループデータ領域パスが含まれていない場合、エラーが発生することがあります [1]。
  • コンパイルコマンドの誤り:ジョブスクリプト内でコンパイルを行う場合、ログインノード用のクロスコンパイラではなく、計算ノード用のネイティブコンパイラを使用する必要があります [1]。

ディレクトリ設定に関する注意点

  • データ領域からのジョブ投入:ジョブは、ジョブ投入時に指定するグループのデータ領域から投入する必要があります。カレントディレクトリがデータ領域に含まれていない場合、エラーが発生します [1]。
  • データ領域の場所の確認:データ領域の場所は、accountd -E コマンドで確認できます [1]。
  • データ領域外からのジョブ投入:データ領域外からジョブを投入する場合は、--no-check-directory オプションを指定する必要があります [1]。
  • ホーム領域の制限:ホーム領域の容量には制限(20GiB、200,000 i-node)があります。データの出力先をホーム領域にしている場合は、データ領域を使用するように変更してください [1]。

その他の注意点

  • コンパイラ:計算ノード上でコンパイルを行う場合、FCCpxではなくFCCとして実行してください [1]。
  • リソースグループ:投入権限がないリソースグループにジョブを投入しようとすると、エラーが発生します。利用可能なリソースグループを確認してください [1]。

参考文献 [1] 富岳サポートサイト記事.csv

この事例が示すように、従来であれば担当者が調査し回答を作成するまでに約4時間を要していた問い合わせに対し、AskDonaはわずか数秒で情報網羅性の高い回答を生成できる。

このような定型的な、あるいは情報探索が中心となる問い合わせをAskDonaがリアルタイムに解決することで、利用者は迅速に回答を得られるようになった。同時に、サポート担当者は問い合わせ対応の負荷軽減にもつながり、RAGデータソースにない情報に関する問い合わせや、個別の利用状況に応じた複雑な判断が求められる、より高度な問い合わせ対応に注力することが可能となり総合的に問い合わせ対応の軽減につながっている。

3.3 ユーザーからのフィードバック評価

サポート品質を評価する上で、ユーザーからのフィードバックは重要な指標である。ここでは、チケット対応(有人対応)とAskDonaそれぞれで収集されたフィードバックについて説明する。

まず、チケット対応では、解決・終了時に満足度サーベイを送信している。図3.3-1に示す通り、AskDona導入期間中(2024年7月〜2025年5月)の顧客満足度(Satisfaction score)は97.5%と非常に高い水準を維持した。これは、AskDona導入後も有人サポートが高いレベルで提供され続けていることを示している。(作成されたチケット総数に対してユーザーがフィードバック評価を行った割合は37.4%であった。)

図3.3-1 チケット対応における顧客満足度とフィードバックの内訳

次に、AskDonaチャットボットが質問単位で収集するユーザーフィードバック「いいね」および「よくない」の状況を図3.3-2に示す。

図3.3-2 AskDonaチャットボットの質問単位フィードバック

2024年7月9日から2025年5月までの総回答済み質問数7,434件に対するAskDona個別の評価である。この期間で「いいね」が116件、「よくない」が77件であった。総回答済み質問数7,434件に対して、このフィードバック件数(合計193件)は全体の約2.6%にあたる。フィードバックの母数は限定的であるものの、このデータはAskDonaの回答品質に対するユーザーからの直接的な評価を反映している。

2024年7月のリリース時においては、ユーザーに「Bad」評価をしてもらうことでRAGデータソースに不足している情報を特定しようと試み、富岳の利用者への周知も行った。しかし、結果としてフィードバックが提供される割合は低く、フィードバック機能を活用した「RAGデータ不足」の特定は困難だと判断した。その事実も踏まえ、チャット履歴を自動分析してRAGのデータソースに情報がないため回答を提供できなかった質問と回答のペアを特定する「RAGデータ不足分析機能」を当社が開発した。

The introduction of the generative AI chat AskDona not only promoted user self-service but also brought clear changes to the human-support side of the Fugaku Support Site. This chapter analyzes how the number of inquiry tickets — issued via form submission and traditionally handled by human staff — shifted after AskDona's deployment, and considers the resulting effects. “Ticket” here refers to an individual inquiry issued by a user through the inquiry system.

In evaluating the data, it should be noted that Fugaku's user base has grown about 10% since FY2022. Normally, an increase in users would also increase inquiries proportionally. Fugaku usage also has seasonal patterns tied to research-project start dates, so year-over-year comparisons — not just month-to-month — provide a more objective gauge of deployment impact. The user-base trend is shown in Figure 3. Fugaku began shared operation on March 9, 2021, providing all 158,976 nodes to users whose projects have been approved.

Fig. 3 — Fugaku registered users and project count

3.1 Trend in Human-Handled Ticket Volume

The most direct effect of AskDona's deployment shows up in the human-handled ticket count. This section first presents the long-term trend by quarter (Figure 3.1-1), then a year-over-year breakdown (Figure 3.1-2).

Figure 3.1-1 shows the quarterly new-ticket count by category from Q2 FY2022 onward. AskDona primarily handles first-line response for the “question” category. After AskDona was deployed in July 2024, “question” tickets remained stable at under 200 per quarter. After the inquiry intake (ticket creation) was routed through AskDona starting February 2025, a clear change appeared: Q1 2025 (Jan–Mar) saw about 120 “question” tickets — a ~40% YoY decrease — and Q2 2025 saw about 100 — a ~53% YoY decrease.

Fig. 3.1-1 — Quarterly trend in new-ticket issuance

For finer detail, Figure 3.1-2 plots question-category tickets as YoY change. During the coexistence period right after deployment (July–December 2024), the reduction effect was limited, with YoY movement ranging from slight decrease to slight increase — many users initially chose the traditional human-support path, showing that user behavior change takes time even when a new tool is offered.

Once ticket creation was routed through AskDona in February 2025, the drop became unmistakable: February was ~42% lower YoY, March ~51% lower, and April ~61% lower.

Fig. 3.1-2 — Human-inquiry counts and YoY change rate

3.2 Time-to-Response and the Division of Labor Between Humans and Generative AI

AskDona's deployment changed not just the volume of human-handled tickets (Section 3.1) but also the efficiency of inquiry response. This section uses a concrete case to show how AskDona shortens response time and contributes to operational efficiency.

AskDona shows its full effect on questions that have prior answer examples or that involve information discovery from manuals and other documents. The case below concretely demonstrates the time-savings impact in such inquiries.

Case: an inquiry where AskDona is expected to compress response time

Question

When I submit a batch job, I get a cannot execute binary file error and the job won't run. A compiled C program and its script are attached. Can you tell me the cause and any directory-setup notes I should be aware of?

Human-handled response example Time required: ~4 hours

[1] Cause of the Exec format error. On Fugaku, the login nodes (x86_64) and compute nodes (A64FX) have different CPU architectures; executing an incompatible binary produces an Exec format error. Executables built with /bin/gcc on the login node will not run on compute nodes.

Workaround: Build compute-node binaries using fccpx, as shown below.

fccpx in.c

[2] Available directories:

  • Home directory (up to 20 GiB)
  • Project data directory (for large-volume processing)
  • Inter-project shared directory

From a capacity-and-performance standpoint, the data directory is recommended.

AskDona answer Time required: ~5 seconds

Likely causes

  • Binary architecture mismatch: an x86_64 binary may be running on a compute node (A64FX). Binaries for Fugaku's compute nodes must be built with the appropriate compiler [1].
  • Current directory issue: if the current directory at job submission doesn't include the group data-area path, the error can occur [1].
  • Wrong compile command: when compiling inside a job script, you must use the native compiler for compute nodes, not the cross compiler intended for login nodes [1].

Directory-setup notes

  • Submitting from a data area: jobs must be submitted from the data area of the group specified at submission. If the current directory isn't inside the data area, an error will occur [1].
  • Confirming the data-area location: use the accountd -E command [1].
  • Submitting from outside the data area: pass the --no-check-directory option [1].
  • Home-area limits: home capacity is limited (20 GiB, 200,000 inodes). If outputs are landing in the home area, switch them to the data area [1].

Other notes

  • Compiler: when compiling on a compute node, invoke FCC rather than FCCpx [1].
  • Resource groups: submitting to a resource group you don't have permission for will produce an error. Check the resource groups you can use [1].

References [1] Fugaku Support Site articles.csv

As this case shows, an inquiry that would have required staff about four hours to investigate and answer is handled by AskDona in seconds, with comprehensive coverage.

By resolving these routine, discovery-oriented inquiries in real time, AskDona delivers fast answers to users while reducing the response burden on staff. Staff can then concentrate on more advanced inquiries — questions about information not in the RAG data source, or those requiring complex judgement specific to a user's situation — which contributes to an overall reduction in support load.

3.3 User Feedback Evaluation

User feedback is an important signal for evaluating support quality. We describe feedback collected for both ticket-based human support and AskDona below.

For ticket-based support, a satisfaction survey is sent at resolution/close. As shown in Figure 3.3-1, customer satisfaction during the AskDona deployment period (July 2024 – May 2025) was an extremely high 97.5%, indicating that human support continued to be delivered at a high level after deployment. (The share of created tickets for which users left feedback was 37.4%.)

Fig. 3.3-1 — Customer satisfaction and feedback breakdown for ticket-based support

Next, Figure 3.3-2 shows the per-question feedback (“good” / “bad”) collected by the AskDona chatbot.

Fig. 3.3-2 — Per-question feedback on the AskDona chatbot

This is the per-question evaluation of AskDona against 7,434 total answered questions from July 9, 2024 through May 2025. During this period, there were 116 “good” and 77 “bad” ratings — a combined 193 feedback responses, about 2.6% of the 7,434 answered questions. The sample is limited, but the data reflects direct user evaluation of AskDona's answer quality.

At launch in July 2024, we tried to surface RAG-data gaps by asking users to mark “bad” responses, and we communicated this to Fugaku users. However, the share of users actually providing feedback was low, and we concluded that identifying RAG data gaps via the feedback feature alone is difficult. In light of this, we developed a RAG Data-Gap Analysis feature that automatically analyzes chat history and identifies question-and-answer pairs where an answer could not be provided due to missing information in the RAG data source.