1. AIスタートアップから Insight Edgeへ 2. AIスタートアップでのAIビジネスの関わり方 3. Insight Edgeで働いて感じた面白さ 3.1 住商内製組織ならではのスピード感と知見獲得のサイクル 3.2 多様なドメインに触れることで広がる視野 3.3 技術トレンドの変化とAIビジネスのダイナミズム 3.4 コンサル×技術×デザインによる価値提供の広がり 3.5 デジタル組織連携による今後の可能性 4. AIビジネスへの関わり方の違い 5. まとめ 1. AIスタートアップから Insight Edgeへ こんにちは。Insight Edgeでセールスコンサルタントをしている飯野です。 入社してちょうど1年が経ったタイミングで、これまでの働き方を振り返ってみたいと思います。 AIスタートアップから、住友商事のデジタルCoE組織である Insight Edgeに転職して、最も大きく変わったのは「AIビジネスへの関わり方」でした。 私はこれまで、AIスタートアップで営業／コンサルタントとして、主に予測・最適化といった技術を軸にしたソリューションの提案に携わってきました。 特定の技術領域に強みを持ち、それをもとに顧客の課題解決を行う、いわゆる“技術ドリブン”なビジネスに関わってきた形です。 一方で、前職ではAIや業務最適化の提案・プロジェクト推進を通じて成果を出してきた中で、より顧客の事業や組織の変化にまで踏み込んだ形で価値を出していきたいという思いも強くなっていきました。 そのため、特定の技術を前提とした提案にとどまらず、技術の進化も取り入れながら、より広い視点でコンサルティングの幅を広げていきたいと考えるようになりました。 実際に働いてみると、AIビジネスへの関わり方そのものが大きく変わったと感じています。 本記事では、AIスタートアップとの比較も交えながら、Insight Edgeで働く中で感じている「面白さ」について整理してみます。 2. AIスタートアップでのAIビジネスの関わり方 AIスタートアップでの仕事は、特定の技術領域を中心に価値提供を行うものでした。 予測モデルの構築 最適化アルゴリズムの適用 特定ユースケースへのソリューション提供 といった形で、技術そのものが価値の中心にあり、 「どの技術で課題を解くか」が重要な意思決定になります。 このような環境では、 技術の強さがそのまま競争力になる 提供価値が比較的明確である 特定領域での専門性が深まる といった面白さがありました。 また、もともと私は、業界知識と技術知見の両方を使いながら、顧客の業務や課題を深く理解して提案することに面白さを感じていました。 だからこそ、特定のソリューションを届けるだけでなく、より広い文脈で顧客課題に向き合える環境に魅力を感じるようになったのだと思います。 一方で、関われる領域や課題の幅という観点では、どうしても一定の制約があることも事実でした。 3. Insight Edgeで働いて感じた面白さ Insight Edgeに来て最も感じているのは、 AIビジネスへの関わり方がより広く、かつ動的であるという点です。 ここでは、特に印象的だったポイントをいくつか挙げます。 3.1 住商内製組織ならではのスピード感と知見獲得のサイクル Insight Edgeは住友商事グループの内製組織として、グループ内の事業会社と近い距離でプロジェクトを進めることが多い環境です。 この関係性により、 信頼関係を前提に議論が進む 課題の解像度が高く、必要に応じて現場の状況もフランクに確認しやすい 意思決定から実行までのスピードが速い といった特徴があります。 こうした環境では、案件の立ち上がりから実行までのサイクルが比較的短く、 結果として 短いサイクルで経験と知見を積み重ねていける という実感があります。 例えば、グループ内案件では契約に至るまでのリードタイムが短く、現場担当者や意思決定者へのアクセスも比較的取りやすいため、提案から実行までをスピーディに進めることができます。 その結果、仮説を持って提案し、フィードバックを踏まえてすぐに改善するというサイクルを高速で回すことができ、実践を通じて知見を高速に蓄積していける環境になっていると感じています。 セールスコンサルタントとしても、単なる提案にとどまらず、実際の価値創出まで関われるため、学習の密度が高い点に面白さを感じています。 3.2 多様なドメインに触れることで広がる視野 Insight Edgeでは、住友商事が関わる多様な事業領域に接点があります。 例えば、 エネルギー 物流 製造 小売 といった領域ごとに、課題の構造や業務プロセスは大きく異なります。 スタートアップ時代は、特定領域にフォーカスすることで専門性を深めていましたが、 Insight Edgeでは 業界横断で「AIがどのように使われるか」を考える機会 が増えます。 これは単に知識が増えるというだけでなく、異なる業界の課題を横断的に捉える視点や、応用の引き出しの多さにつながっていると感じています。 また、ある業界で得た視点や課題の捉え方を、別の業界に応用して考えられることも、この環境ならではの面白さだと感じています。 3.3 技術トレンドの変化とAIビジネスのダイナミズム 近年の大きな変化として、生成AIの登場があります。 Insight Edgeでは、新しい技術に対して前向きに取り組む文化があり、生成AIも実際の案件の中で積極的に活用されています。 その結果、 提供するソリューションの形が変わる 顧客への提案内容が変わる 価値の出し方自体が変わる といった変化が起きています。 スタートアップ時代はコア技術がある程度固定されていたのに対し、 Insight Edgeでは 技術の進化に応じて提供価値が変わり続ける という特徴があります。 個人としても、この環境にいることで、常に新しい技術に触れながら仕事ができる点に面白さを感じています。 さらに、こうした変化の中で、生成AIの普及によりプログラムやアルゴリズムといった技術そのものによる差別化は相対的に難しくなってきているとも感じています。 その一方で、さまざまなアセットを組み合わせて新たな価値を生み出していく重要性が高まっており、そのような動き方が求められる環境である点にも面白さを感じています。 3.4 コンサル×技術×デザインによる価値提供の広がり Insight Edgeでは、コンサルティング・技術・デザインといった複数のケイパビリティを組み合わせて、顧客に価値提供を行います。 そのため、 事業構想の整理 業務プロセスの設計 AI・システムの実装 現場への定着 デジタル組織の立ち上げや内製化支援 まで、一貫して関わるケースも少なくありません。 単にソリューションを導入するだけでなく、 継続的に価値を生み出せる体制そのものを作るという点も特徴的だと感じています。 このような環境では、セールスコンサルタントとしても 「何を売るか」ではなく「何を実現するか」から考える ことが求められます。 また、単に技術を提案するのではなく、その提案が顧客の事業や業務にどう位置づくのか、どのような価値や変化につながるのかまで含めて構想できることにも面白さを感じています。 結果として、 提案できる領域が広がる 関われるフェーズが増える 顧客への価値提供の解像度が上がる といった変化があり、仕事としての面白さの幅が広いと感じています。 3.5 デジタル組織連携による今後の可能性 今後の展開として、Insight Edgeはこれまでも住友商事グループ内の各デジタル組織と連携しながら価値提供を行ってきましたが、近年の体制変化（例：SCSKの完全子会社化など）もあり、その連携がさらに強化・拡大しつつあると感じています。 異なる強みを持つ組織との連携により、例えば これまで以上に上流から実装・運用まで一貫した支援が可能になること 技術・データ・事業アセットを組み合わせたソリューションの高度化 が期待されます。 また、こうした連携を前提として、住友商事グループとしてのシナジーを活かしながら、グループ内で培った知見やアセットをもとに、グループ外の企業に対してもワンチームで価値提供していくような動きが今後さらに広がっていくと感じています。 こうした変化の中で、個人の視点でも、 これまでに得た知見をもとに、より広いフィールドで価値発揮していく機会 が増えていく可能性があり、今後の広がりにも面白さを感じています。 4. AIビジネスへの関わり方の違い ここまでの内容を踏まえると、 AIスタートアップとInsight Edgeでは、AIビジネスへの関わり方に違いがあります。 スタートアップでは、特定技術を軸に価値を最大化する面白さがありました。 一方でInsight Edgeでは、 技術 ビジネス（現場の業務や意思決定を含む） を横断しながら、 AIを「どのように使うか」を考える面白さ があると感じています。 どちらにも異なる魅力がありますが、現在はより広い視点でAIに関われる点に、仕事としての面白さややりがいを感じています。 5. まとめ Insight Edgeで働く中で感じている面白さは、 多様なドメインに触れられること 技術の進化がそのまま仕事に反映されること 現場に近い距離で価値創出に関われること 提案できる領域の広さ といった点にあります。 AIの活用が広がる中で、 「どの技術を使うか」だけでなく、 「どのように使うか」を考える重要性は今後さらに高まっていくと思います。 その中で、さまざまな領域にまたがりながらAIビジネスに関われる環境は、個人としても非常に刺激的であり、面白いと感じています。 もしInsight Edgeでの働き方に興味を持っていただけた方は、ぜひ以下の採用ページもご覧ください。 https://herp.careers/v1/insightedge/V3eGbCLwh8Jy

皆さんの多くと同じく、私も親です。そして、皆さんと同じように、自分の子どもたちのために築いている世界について考えています。これが、私たちの多くにとって 2026 年 3 月 31 日のリリースが重要な理由の 1 つです。同日、 AWS Sustainability コンソール のリリースを発表いたしました。これは、すべての AWS サステナビリティレポートとリソースを 1 か所に統合するスタンドアロンサービスです。 2019年、Amazon は The Climate Pledge (クライメイト・プレッジ) により、2040 年までに事業全体でネットゼロカーボン (温室効果ガス排出量実質ゼロ) を達成するという目標を設定しました。この取り組みが、AWS によるデータセンターとサービスの構築方法を形作っています。さらに、AWS は、お客様が自身のワークロードの環境フットプリントを測定し、削減できるよう支援することにも努めています。AWS Sustainability コンソールは、その方向への最新の 1 歩です。 AWS Sustainability コンソールは、 AWS 請求コンソール 内にある Customer Carbon Footprint Tool (CCFT) に基づいて構築されており、お客様からご要望のあった新しい機能セットを取り入れています。 これまで、二酸化炭素排出量データにアクセスするには請求レベルのアクセス許可が必要でした。その結果、実際的な問題が生じていました。サステナビリティの専門家や報告チームが、コストや請求データにアクセスできない (またアクセスすべきではない) ことがよくあったのです。適切な人が適切なデータにアクセスできるようにするには、持続可能性のワークフローを念頭に置いて設計されていない許可構造とうまく折り合いをつける必要がありました。AWS Sustainability コンソールには、請求コンソールから独立した独自のアクセス許可モデルがあります。サステナビリティの専門家が排出量データに直接アクセスできるようになったため、請求へのアクセス許可の付与も必要ありません。 コンソールには、お客様の AWS の使用状況に起因する スコープ 1、2、3 の排出量 が含まれており、AWS リージョンやサービス ( Amazon CloudFront 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) など) 別の内訳が表示されます。基盤となるデータと手法は、今回のリリースで変わっていません。これらは CCFT が使用しているものと同じです。変更したのは、データへのアクセス方法と操作方法です。 サステナビリティ報告の要件がますます複雑になるにつれ、チームには排出量データへのアクセスと操作をより柔軟に行う必要が生じています。これを受け、コンソールに Reports ページを追加しました。このページでは、市場ベースの手法 (MBM) とロケーションベースの手法 (LBM) の両方のデータを対象とする、事前設定済みの月次および年次の炭素排出量レポートをダウンロードできます。含めるフィールド、時間粒度、およびその他のフィルターを選択し、カスタムのカンマ区切り値 (CSV) レポートを作成することも可能です。 組織の会計年度が暦年と一致しない場合は、レポート期間に合わせてコンソールを設定できるようになりました。これを設定すると、すべてのデータビューとエクスポートに会計年度および四半期が反映され、財務チームとサステナビリティチームが並行して作業する際の共通の摩擦点がなくなります。 新しい API または AWS SDK を使用して、排出量データを独自のレポートパイプライン、ダッシュボード、またはコンプライアンスワークフローに統合することもできます。これは、データエクスポートを設定せずに多数のアカウントにおいて特定の月のデータを引き出す必要があるチームや、既存の AWS Organizations 構造と一致しないカスタムアカウントグループを確立する必要がある組織に役立ちます。 リリースされた最新の機能や手法の更新については、 [詳細] タブの「 リリースノート 」ページをご覧ください。 実際の動作を見てみましょう Sustainability コンソールをお見せするために、 AWS マネジメントコンソール を開き、画面上部の検索バーで「サステナビリティ」を検索しました。 [炭素排出量] のセクションでは、二酸化炭素換算量 (MTCO2e) をメートルトン単位で推定できます。これは MBM と LBM で表されたスコープ別の排出量を示しています。画面の右側では、日付範囲を調整したり、サービスやリージョンなどでフィルターしたりできます。 なじみのない方のために説明すると、スコープ 1 には所有または管理されている発生源からの直接排出 (データセンターの燃料使用など) 、スコープ 2 には購入したエネルギーの生産による間接排出 (MBM はエネルギー属性証明書を考慮し、LBM は地域の平均グリッド排出量を使用する)、スコープ 3 にはサーバー製造やデータセンター建設など、バリューチェーン全体にわたるその他の間接排出が含まれます。詳細については、サードパーティーのコンサルタントである Apex が独自に検証 した 当社の手法に関するドキュメント をご覧ください。 API または AWS コマンドラインインターフェイス (AWS CLI) を使用して、プログラムで排出量データを取得することもできます。 aws sustainability get-estimated-carbon-emissions \ --time-period='{"Start":"2025-03-01T00:00:00Z","End":"2026-03-01T23:59:59.999Z"}' { "Results": [ { "TimePeriod": { "Start": "2025-03-01T00:00:00+00:00", "End": "2025-04-01T00:00:00+00:00" }, "DimensionsValues": {}, "ModelVersion": "v3.0.0", "EmissionsValues": { "TOTAL_LBM_CARBON_EMISSIONS": { "Value": 0.7, "Unit": "MTCO2e" }, "TOTAL_MBM_CARBON_EMISSIONS": { "Value": 0.1, "Unit": "MTCO2e" } } }, ... ビジュアルコンソールと新しい API の組み合わせにより、引き続き利用可能な データエクスポート に加えて、データを操作する方法が 2 つ追加されました。コンソールでホットスポットを調べて特定し、ステークホルダーと共有したいレポートを自動化できるようになりました。 Sustainability コンソールは成長するように設計されています。お客様とともにコンソールの機能を拡張し、引き続き新機能をリリースする予定です。 今日から始めよう AWS Sustainability コンソールは、追加費用なしで本日からご利用いただけます。AWS マネジメントコンソールからアクセスしてください。履歴データは 2022 年 1 月まで記録されているため、すぐに排出量の傾向を調べることができます。 今すぐ コンソール の使用を開始しましょう。持続可能性に対する AWS の取り組みについて詳しく知りたい場合は、「 AWS の持続可能性 」ページをご覧ください。 – seb 原文は こちら です。

Insight Edgeのデータサイエンティストの山科です。 今回は、画像に対する異常検知結果をLLMで解釈させることに加えて、RAGを組み込むことでアクション提案まで行う手法について検証を行いましたので、その結果について記載したいと思います。 なお、本内容は先日開催された言語処理学会第32回年次大会（NLP2026）でも発表した内容となっています。 また、本研究は 以前ご紹介したLanguage-Driven XAI の続編となっており、前回の手法を発展させた内容となっています。前回記事で説明性を付与する手法を提案しましたが、今回はそれにRAGを組み合わせることで、より実務的な意思決定支援を実現しています。 目次 はじめに なぜアクション提案まで必要なのか 提案アプローチ 実験 はじめに 前回ご紹介したLanguage-Driven XAIでは、画像異常検知の結果をLLMで自然言語化することで説明性を付与する手法を提案しました。異常の種類や発生箇所を人間が理解しやすい形で説明できることを確認し、また誤検知時にその間違いを正すことができることも確認しました。 しかし、実際の現場では「異常を理解する」だけでは不十分で、「次に何をすべきか」を判断することが求められます。例えば、製造ラインで異常が検出された場合、作業員は以下のような判断を迫られます： この異常は直ちにラインを停止すべきレベルなのか 継続して監視すれば良いのか どのような確認作業を優先すべきか マニュアルではどのように対応することになっているのか 前回の手法では、異常内容の説明は生成できても、これらの実務的な判断や後続アクションまでは十分に提示できませんでした。また、提案される対応策は一般論に留まりやすく、組織固有のマニュアルや規定に基づいた具体的な根拠を示すことができませんでした。 そこで本研究では、前回のLanguage-Driven XAIを発展させ、 Retrieval-Augmented Generation（RAG） を導入することで、マニュアルや過去事例といった外部知識を参照しながら、具体的なアクション提案までを一貫して生成する手法を提案します。 RAGとは、LLMが応答を生成する際に、外部のデータベースや文書から関連情報を検索（Retrieval）し、その情報を基に回答を生成（Generation）する技術です。これにより、LLMの事前学習で得た一般的な知識だけでなく、組織固有のマニュアルや最新の技術文書など、特定のドメイン知識を活用した応答が可能になります。 なぜアクション提案まで必要なのか 前回の記事でご紹介したように、LLMを用いることで異常検知結果を自然言語で説明することができました。しかし、実運用の現場では、 「異常を理解する」ことと「適切に対応する」ことは別の問題 です。 例えば、風車のブレードにクラックが検出されたとします。前回のLanguage-Driven XAIでは「ブレード表面に亀裂があり、保存状態に起因する可能性がある」という説明を生成することができます。しかし、現場の運転・保守担当者が本当に知りたいのは以下のような情報です： 緊急度の判断 ：今すぐ運転を停止すべきか、次回の定期点検まで様子を見るべきか 確認すべき項目 ：どのような追加検査や確認作業が必要か 対応の優先順位 ：限られたリソースの中で、何から着手すべきか 手順の妥当性 ：社内規定やメーカーのガイドラインに従った対応になっているか つまり、異常の説明だけでは「次のアクション」が明確にならず、結局は経験豊富な担当者の判断に依存することになります。特に、新人や経験の浅い作業者にとっては、説明を受けても「だから何をすればいいのか」が分からないという課題があります。 LLM単独での3つの限界 この課題に対して、LLM単独で対応策を生成しようとすると、以下の限界があります： ドメイン知識の不足 特定の産業における保守規程や安全基準 組織固有の運用ルールや判断基準 装置固有の点検手順や対応マニュアル 根拠の不透明性 提案されたアクションが「なぜ必要なのか」の根拠が不明確 「どのマニュアルの何ページに基づいているか」が示されない 監査や事後検証の際に、判断プロセスを追跡できない 最新情報への対応困難 マニュアルの改訂や規制の変更に追随できない 過去の類似事例や教訓を活用できない 組織内で蓄積されたノウハウを反映できない その結果、LLMが生成する対応策は「一般的にはこうすべき」という助言に留まり、「この組織では、このマニュアルに従って、こういう手順で対応すべき」という具体性や根拠を欠いてしまいます。 RAGによる知識駆動型アクション提案 そこで本研究では、 Retrieval-Augmented Generation（RAG） を導入します。RAGは、LLMと外部知識ベースの検索を組み合わせることで、正確性および文脈整合性の高い応答を生成する手法です。 前回の記事でも今後の展望として「マニュアルや事故事例集をRAGに活用して、作業工程へのフィードバックや、設備へのメンテナンスへのフィードバック」について触れましたが、本研究ではこれを検証しました。 RAGを用いることで、以下が実現できます： 異常原因の推定 ：過去の類似事例に基づく原因特定と、その根拠となる文書の明示 対応方針の決定 ：マニュアルや規定に基づく判断と、参照ページの提示 アクション提案 ：具体的な対応手順の提示と優先順位付け、実施理由の説明 特に製造業や保守点検の領域では、装置固有の知識や詳細な手順書が重要です。RAGを用いることで、これらの専門知識を体系的に活用し、 「説明できるAI」から「行動を導くAI」へ と進化させることができます。 提案アプローチ 本研究の提案アプローチは、前回ご紹介したLanguage-Driven XAIに RAGを組み込むことでアクション提案まで行う 枠組みです。全体構成は以下の2つのフェーズで構成されます。 提案アプローチ フェーズ1：説明付加（自然言語解釈の生成） 前回の記事でご紹介したように、複数の異常検知モデル（二値分類、多クラス分類、セグメンテーション、物体検知）の結果をLLMに入力することで、異常内容を自然言語で説明しました。その結果、異常検知モデルの種類によって生成されるキャプションの特性が異なることもわかりました。 二値分類・多クラス分類 ：異常の種類や発生要因について詳しく説明できるが、「どこに」異常があるのか位置情報については言及しにくい セグメンテーション ：異常箇所の位置や個数を詳述できるが、ヒートマップが重なると元画像が見づらく、異常の種類の特定が難しい 物体検知 ：位置情報と異常の種類をバランスよく説明できるが、バウンディングボックスの箇所に注目しがちで、見逃しがある場合に補正できないケースも有る このように、各手法には得意・不得意があります。単一のモデルだけに頼ると、以下のような問題が生じる可能性があります： 過剰反応のリスク ：特定の特徴に過敏に反応し、実際には問題ない箇所を異常と誤認する 見逃しのリスク ：モデルが注目していない領域の異常を検出できない ハルシネーション ：LLMが限られた情報から推測で説明を生成し、事実と異なる内容を出力する 例えば、セグメンテーションモデルだけでは異常箇所の位置は分かっても、その異常が「どういう種類の問題なのか」が不明確です。逆に、二値分類だけでは「異常がある」ことは分かっても「どこに」「どれだけの範囲で」異常があるのかが分かりません。 そこで本研究では、これらを組み合わせた「 アンサンブル異常検知 」により、各手法の長所を活かしつつ短所を補完し、多角的視点から異常内容を説明できるようにアップデートを行いました。具体的には、各モデルでの異常検知結果に対して解釈を生成し、それらを統合した解釈を行わせることで、 相互に補完し合い、誤った推論を相殺 するようにしました。これにより、LLMのハルシネーションを抑制し、より安定した説明を実現できます。 フェーズ2：アクションレコメンド（RAGによる行動提案） フェーズ1で生成された異常解釈文は、「異常がどのような状況にあるか」を説明するものの、実務上求められる具体的な対応方針や作業手順までは含まれていません。 そこで、フェーズ2では以下のプロセスでアクション提案を行います： 検索クエリの生成 ：フェーズ1で生成された異常解釈文をクエリとして使用 関連文書の検索 ：外部知識ベース（マニュアル、ガイドブック等）から関連情報を取得 アクション生成 ：取得した情報と異常の文脈を統合し、LLMで具体的な対応アクションを生成 マルチモーダルRAGの実装 保守マニュアルには図や表が多く含まれるため、本研究では以下のアプローチを採用しました： 図表を一旦LLMで自然言語化し、テキスト情報として知識ベースに格納 検索はテキストベースで実施 ただし、アクション生成時には図表を含むPDF原文全体をLLMに入力 これにより、テキストで検索しつつ、視覚情報も活用したマルチモーダルなアクション生成が可能になります。 評価指標 本研究では、前回と同様に人手評価（5段階のLikert scale）を採用し、以下の2つを評価します： Correctness（正しさ） ：参照文書に基づいているか、根拠が明確か Helpfulness（有用性） ：現場で活用可能か、優先度が明確か 実験 実験設定 提案手法の有効性を検証するため、風車翼の保守点検を対象とした実験を行いました。 データセット 前回はMVTec ADを用いましたが、今回は実際の保守点検を想定し、以下のデータセットを使用しました： MIAD（風車翼異常データ） ：屋外設備の保守点検を対象としたデータセット。風車翼のクラック、欠損などの構造的異常を対象 参考資料（RAGの知識ベース） NEDOの風力発電ガイドブック（2008年版、2018年版）を使用しました。これらのガイドブックには異常発生後の対応手順が直接記載されているわけではなく、日常点検の項目や手順が中心となっているため、本研究では、異常が検出された際に「日常点検としてどのような確認を行うべきか」という観点でアクション提案を生成します。 異常検知モデルと評価手法 異常検知モデルとしては、二値分類、多クラス分類、セグメンテーション、物体検知の4種類のモデルを使用し、前述の通り、これらをアンサンブルすることで多角的な異常解釈を生成しました。LLMには gpt-4o を用いました。評価は5段階のLikert scaleによる人手評価で、Correctness（正しさ）とHelpfulness（有用性）を採点しました。 実験ケース Case 異常種類 RAG 狙い 1 ひび割れ なし ベースライン（RAGなし） 2 ひび割れ あり RAGの効果を検証 3 正常 あり 正常画像への対応を検証 実験結果 3つのケースで実験を行った結果の概要を示します。各ケースの入力画像と生成されたアクション提案の例を以下に示します。 Case1: RAGなしのアクション提案（ベースライン） まず、RAGを用いずLLMのみでアクション提案を生成した場合の結果を示します。入力画像、異常検知結果、異常解釈結果、生成されたアクション提案は以下の通りです。 Case1: RAGなしのアクション提案結果 ブレード損傷時に一般的な日常点検項目（望遠目視点検、異音確認、SCADA振動監視など）が優先度付きで提示されており、実務的な観点が含まれています。しかし、特定のマニュアルに基づくものではなく、出典が示されていないため、Correctnessは3/5、Helpfulnessは4/5と評価しました。情報量は十分ですが、判断根拠の透明性には課題があります。 Case2: RAGありのアクション提案 次に、RAGを組み込んだ場合の結果を示します。同じ異常画像に対して、NEDOガイドブックを参照してアクション提案を生成しました。 Case2: RAGありのアクション提案結果 RAGを用いた場合、各確認項目に情報源（例：「風力発電導入ガイドブック、p.145」）が明示され、文書に準拠した手順が提示されました。対応手順が文書根拠と結び付き、判断過程の透明性が大きく向上したため、CorrectnessとHelpfulnessともに5/5と評価しました。 前回の記事で示したように、LLMは異常内容を理解し説明できますが、RAGを組み合わせることで、その説明に基づいた 規定準拠型のアクション提案 が可能になることが確認できました。 Case3: 正常画像への対応 Case3では正常画像に対する検証を行いました。 Case3: 正常画像への対応結果 正常画像に対しては「構造的破損は認められない」とする適切な判断が生成され、参照文書に基づく確認手順が優先度順に整理されました。 前回の記事でも誤検知時の訂正ができることを確認しましたが、RAGを組み込むことで、誤検知時の過剰反応を抑制しつつ、必要な確認は行うというバランスの取れた提案が得られています（Correctness, Helpfulness ともに 5/5）。 結果のまとめ RAGを用いることで、参照文書に基づく根拠が提示され、Correctness・Helpfulness ともに高い評価となりました。特に、以下の点が確認できました： 透明性の向上 ：各アクションの根拠となる文書とページが明示される 汎用性 ：異常画像だけでなく正常画像に対しても適切に機能 実務適用性 ：現場でそのまま活用可能な具体的な提案 まとめ 本記事では、前回ご紹介したLanguage-Driven XAIを拡張し、RAGを組み込むことで異常検知結果に対する説明生成とアクション提案を一貫して生成する手法を提案しました。 実験の結果、以下のことが確認できました： RAG導入の効果 透明性の向上 ：各アクションの根拠となる文書とページが明示され、判断の追跡可能性が向上 正確性の向上 ：LLM単独では困難であった組織固有の規定や業界標準に準拠した提案が可能に 実務適用性 ：現場でそのまま活用可能な具体的な提案を生成 前回の記事では異常内容の説明にとどまっていましたが、RAGを組み込むことで、マニュアルや規定に基づいた 具体的なアクション提案 まで実現できることを確認しました。また、異常時だけでなく正常画像に対しても適切な対応を提示でき、誤検知時の過剰反応を抑制できることも確認できました。 今後の展望 前回の記事でも触れた今後の展望として、以下について引き続き検証を進めたいと思っています： 参照文書の種類や構造の最適化 実運用データを対象とした検証 マルチモーダルRAGへの拡張（画像をクエリとした検索手法など） 今回用いたドキュメントには検査対象画像は含まれていなかったためテキストを基に検索しましたが、参照するドキュメントに検査対象画像が含まれている場合には、画像をクエリとして用いた検索も有効と考えられます。テキスト知識と視覚的情報を統合したマルチモーダルRAGの実現により、より文脈に即した提案が期待できます。