ゲーム

イベント

技術ブログ

2026年11月12日

業務部門が自分で改善できる AI Ready Data を作る ― AI がどれだけ賢くなっても解決できないこと

このブログでは、IHI 様と AWS プロフェッショナルサービスチームが、業務部門の悩みを AI で解決するため、初期構築とその後の運用体制をともに検討した取り組みをご紹介します。AI に任せられることがどこまでだったのか（I）、任せられない分を知識の整備でどう補ったのか（II）、整えたものを誰が持ち続け、発展させるのか（III）という三つの問いを通じて、お客様が組織として AI とどう関わるかを決めていく過程をご紹介します。顕在化しつつある属人化リスク私たちがよくいただくご相談は、これまで社内の詳しい方に聞いていた質問を AI に聞けるようにしたい、というものです。具体的にはこのような例です。設備設計の担当者が、過去に同じ部品を使った案件を参考にしようとして、資料を探しています。その部品は図面では「HX-2」という社内の符号で書かれているので、「二次加熱器」で検索しても、肝心の資料が出てきません。社内に文書は揃っているのに、担当者は自分では見つけられないので、その分野に詳しい方に設計作業そのものを相談することになります。 AI にどこまで肩代わりさせるべきかここだけ見ると、詳しい方の代わりに AI が設計の相談に乗らなければならないように見えます。ただ、この例なら、担当者に該当する資料を網羅的に渡すだけでも解決できるはずです。解決の糸口はもっと手前にあるようです。では、AI は担当者の代わりに、資料をもれなく見つけることができるでしょうか。最初の段階で、AI はつまづきます。「HX-2」が「二次加熱器」を指すことは社内でしか使われていない符号なので、AI が学習した公開情報のどこにも書かれていません。モデルがどれだけ大きくなっても、公開されていない情報からは学べないので、固有用語に関しては基盤モデルだけでは検索システムに適切な検索キーワードを入れることができません。企業内部の非公開情報をつかって独自に継続的事前学習を行えば、AI はもっといろいろなことに回答できるかもしれません。AI が設計の相談に乗れるようにもなりそうです。しかし、いっきにそこまで踏み込めるお客様は多くはありません。最初の糸口として私たちが引いた線は、 AI の内部に業務知識を学習させるのではなく、社内固有の語彙を引けるようにして、適切に検索できるようにすることでした（I）。 AI が資料を探し当てるまでの道筋をたどる私たちは、担当者が問いを入れてから AI が正しく検索して結果を返すまでの流れを設計しました。そこには越えなければならない関門が四つあることがわかりました。最初の関門は、知りたいことを担当者が言葉にできていることです。何を知りたいのかが曖昧なままでは、どんな仕組みでも答えは決まりません。ただ、システムが検索可能なジャンルをユーザーに伝えることができれば、問いは立てやすくなります。そこはシステムの側から示す設計としました。二つ目は、担当者の質問文の中から AI が検索に必要なキーワードを漏れなく拾えることです。「2023年の二次加熱器の点検記録」と入力されたら、「2023年」「二次加熱器」「点検記録」をそれぞれ検索キーワードとして取り出す必要があります。何が検索キーワードなのかを判断するためには、AI はシステムが検索可能なジャンルを知っている必要があります。もしもジャンルの外について訊かれたら、探す前に検索できない旨と検索可能な質問例を返答する設計としました。三つ目は、AI が拾った言葉を、データベースが採用している正式な名称もしくは記号に置き換えられることです。例えば、同じ部品が、図面では「HX-2」、見積書では「二次加熱器」と書かれています。字面が重ならないので、二つが同じ部品だとデータベースに登録されていなければ、資料にたどりつけません。四つ目は、AI がその名称や記号を持つデータへ到達するための検索経路や、データ自身の属性を参照できることです。部品と設備がどんな関係で結ばれ、設備と工事がどうつながっているか。工事に実施日という項目があり、その型が日付であること。数を数えられる項目はどれか。こうした構造を参照できなければ、「2023年」や「3件以上」という条件を検索文に組み立てられません。図：AI が資料を探し当てるまでの四つの関門上記のように探し当てるまでのステップを四つに分けておくと、AI はどこで壁に当たったのかを返せるようになります。扱っていないジャンルだと分かった時点で、「それは検索できません」と返せます。正式な名称や記号に置き換えられなければ、「その呼び方は登録されていません」と返します。置き換えたうえで探して出てこなければ、データベース上に記録が本当に無いということです。そもそもジャンルの外なのか、呼び方を知らないのか、知っていて記録が無いのかを、分けて返せます。返ってきた答えで、どこを直せばよいかも決まります。対応可能なジャンルを増やすのか、呼び方を足すのか、記録そのものを足すのかが、そこで分かれます。関門を越える仕組みを、どう組むか二つ目から先の関門は、既存の検索システムに検索語を一語渡すだけの連携では越えられません。対応可能なジャンルを返答し、呼び方の対応を引き当て、データの構造を参照し、どこで壁にあたったのかを返す仕組みを、自分たちで作り上げる必要があります。そのためには、探す先のデータベースが、自分に何がどんな構造で入っているかを答えられなければなりません。呼び方や部品・設備・工事の関係を追加しながら構造を変えられ、構造情報そのものも問い合わせ対象として登録できる必要があります。この要件に適するデータベースとして、私たちはグラフデータベースを採用しました。グラフデータベースは様々な情報とその関係性を知識グラフとして保持できるからです。さらに、グラフデータベースをマネージドサービスとして運用できる点を重視し、Amazon Neptune を採用することにしました。 Amazon Bedrock 上の大規模言語モデルは、ユーザーからの質問を受けて、関門ごとに必要な検索文を組み立てることができます。まず知識グラフにどのジャンルが入っているかを問い合わせて、答えられる範囲を把握します。次に質問から検索キーワードを拾ってジャンルを特定し、その範囲の中かどうかを判断します。範囲の中なら、それぞれが正式な名称や記号のどれに当たるかを問い合わせます。そのうえで、たどる経路を決め、必要なら絞り込み条件を付けて、検索文にして発行します。この設計では、Amazon Bedrock から Amazon Neptune への問い合わせが何度も発生します。手順そのものは固定的なので、問い合わせ先の知識グラフが用途別に分かれていた方が、構築も保守もしやすくなります。そこで私たちは、知識グラフを三つに分けました。自分自身の構造情報、業務知識の語彙情報、個別の文書から抽出した情報です。私たちは、知識グラフのこの作り方を SVD アーキテクチャと呼んでいます（II）。構造（Schema）・語彙（Vocabulary）・業務知識（Domain）の頭文字です。三つをまとめた組を、部門ごとに持ちます。Amazon Neptune のクラスタは部門ごとに分かれる設計であるため、ある部門が知識グラフを変更しても、他の部門には何も起きません。では知識グラフの中身はどうやって詰めるのか業務の具体的な内容や、検索したいことは、会社や部門ごとに違います。知識グラフが検索できることを決めたり、登録すべきデータを特定できるのは、その業務をしている方だけです。ただし、その負担は軽くできます。私たちは、対話しながら設計を進める道具として Kiro を使うことにしました。はじめに決めるのは、検索したいことと、そのデータ源です。探せるようにする検索対象ジャンルを、私たちはアスペクトと呼んでいます。どのアスペクトを扱うかは業務部門の方に決めていただき、それに紐づく呼び方と、対象になる文書がどのデータ源にあるのかを、一緒に洗い出します。ここで Kiro は相談相手になります。次は語彙グラフの構築です。データ源を前処理して、それぞれのアスペクトを構成する言葉と、アスペクトそのものの情報を入れます（二つ目の関門）。続いて、同じものを指す異なった呼び方（エイリアス）を入れます（三つ目の関門）。前処理のスクリプトは Kiro が書きます。業務知識グラフの構築では、それぞれの業務文書に対して前処理を行い、文書構造を反映したグラフを登録します。このとき、語彙グラフに登録済みの語彙を識別して登録する必要もあります。このための加工と登録のスクリプトも Kiro が書きます。最後は構造グラフです。できあがった語彙グラフと業務知識グラフのそれぞれの構造と、その関係を入れます（四つ目の関門）。ここも Kiro が登録を支援できます。この問題において、業務部門は単なるユーザーの立場ではいられないビジネスは常に変化しながら動いているため、知識グラフの中身もそれに合わせて拡大する必要があります。立ち上げ期には私たちのような外部のメンバーに頼ることは可能ですが、いつまでもその状態を続けることは現実的ではありません。知識グラフの拡大には事情を知る方が関わらなければ成立しないので、業務部門が主体になるほかありません（III）。 IHI 様との取り組みでは、次のように役割を分けました。検索システムのオーナーとなるプロダクトマネージャーは、業務部門の中から立てていただきました。何を検索できるようにするか、同じものに対してどのような呼び方があるのか、知識グラフの範囲をどのように発展させていくのかを決めていただくリーダー役です。ただし、初期段階では目の前の業務の範囲を検索できるようにするだけで十分です。SVD アーキテクチャでは知識グラフを逐次的に発展させることが可能な設計となっているからです。 DX 推進部門には、環境とアプリケーションの維持、そして SVD アーキテクチャの社内理解を引き受けていただきました。何を検索できるようにするか、どの呼び方が同じものかは、各業務部門が決めます。一方、部門をまたいで共通にする設計原則や運用方法は、一つの業務部門だけでは決められません。 DX 推進部門が各部門の判断をつなぎ、組織として AI にどう関わるかを組み立て、他部門への横展開を主導します（III）。 AWS プロフェッショナルサービスチームは、立ち上げ期における知識グラフの構築、呼び方の対応の初期整備、検索アプリケーションの実装を担当しました。プロダクトマネージャーを務める真山様に、何に悩み、どう進めてきたかを伺いました。「AI を文章作成の支援ではなく業務プロセスに取り込むのは初めてで、どう進めればよいかという戸惑いや、AI がどこまで課題を解決できるのかを十分にイメージできない不安がありました。重視したのは、課題を正確に伝えることと、メンバーが長く使える仕組みにすることです。ただ、メンバーの繁忙期と重なり、検討の時間を確保するのに苦労しました。そこでトライアル版の段階から使う人に展開し、フィードバックを受けて業務に合う形に近づけようとしています。進むスピードが想定より速く、理解が追いつかない場面もあったのは、今後に活かす点です。すべての技術を自分で理解するのは現実的ではないので、専門家に頼るところは頼りつつ、課題と業務の背景を共有して進めることが重要だと感じています。」（株式会社IHI 資源・エネルギー・環境事業領域カーボンソリューションSBU ライフサイクルマネジメント部設計グループ（主機・サービス設計担当）主幹真山浩晃様）体制を決めて、何が変わったかを確かめる体制を決めて、最初に変わったのは要望でした。業務部門からプロダクトマネージャーが立つと、誰かが代理で聞き取って翻訳するのではなく、決める人が直接語ることになります。何を検索したいのかが、そこで具体的に出てきます。DX 推進部門が、これなら役に立つだろうと推測して作る必要もなくなりました。発注する側と受ける側という形ではなく、ワンチームで進められる形が実現します。私たちは、初期構築の相談役として Kiro を使えるように、これまでの知見をプレイブックにまとめました。プレイブックがあるので、判断に要ることだけを伺えばよく、業務部門に投げる質問の数が減ります。前処理などのコードを書く手間も軽くなります。文書からの抽出と投入は、Amazon SageMaker で実行しました。業務部門には、初期構築の間はおひとりあたり、週に2〜4時間を4〜8週いただきました。初期構築のあと、業務部門からいただく時間は減る見込みです。運用では、新しい呼び方を検索アプリケーションから記録し、新しい文書を初期登録で確立した経路から登録する計画です。業務部門が新しい呼び方の承認や新しい文書の登録の確認に要する時間は週1時間程度を見込んでいます。検索可能なジャンルを増やしたり、検索可能な文書の形式を増やすなどの大きな変更が必要になったときは、業務部門の依頼を受けて DX 推進部門がプレイブックに沿って対応します。知識グラフの中身は業務部門、知識グラフの大きな変更は DX 推進部門という分担が、保守にもそのまま出ます。初期構築では過去の資料を数千件規模で登録し、探せることを確かめました。使っていただいた業務部門の方から、こうした言葉をいただきました。「自分だったら絶対に見つけられなかった部品を見つけられた」資料を見つけることだけが、この仕組みの価値ではありません。検索結果から、扱っていないジャンル、登録されていない呼び方、記録そのものの不足のうち、どこを直すべきかが分かります。業務部門が不足している呼び方や記録を追加し、検索対象や構造を変えるときは DX 推進部門が支援します。変更を次の検索に反映することで、使いながら知識グラフを改善できます。登録した呼び方の対応は個人の記憶に閉じず、部門で管理し、AI が参照できる記録として残ります。 DX 推進部門に、組織としてどう関わるのかを伺う同様のニーズがある社内部門は多く、必要な知識グラフは部門ごとに異なります。横展開の担い手になるのは、DX 推進部門です。デジタルトランスフォーメーション推進部の鈴木様に、この取り組みをどう捉えているかを伺いました。「今回の取り組みを単なる生成 AI の導入ではなく、現場とともに事業・業務の価値創出を目指すモデルケースと捉えています。これまでは個別の業務課題に対して、ボトムアップで生成 AI を試す進め方が中心でした。今回は、初期段階から幹部を巻き込み、事業と業務の視点からテーマを選んでいます。あわせて、生成 AI の回答を100％正しいものとして扱わず、人による確認を前提に、AI が担う部分と人が判断する部分を分けました。横展開の具体策は今後の課題ですが、業務知識やノウハウを生成 AI が活用できる形で蓄積・構造化する重要性は見えてきました。知識グラフを含むナレッジ基盤の整備が、鍵の一つになると考えています。得られた知見を活かし、基盤整備とセキュリティ・ガバナンスの確保を進め、安心して生成 AI を活用できる環境を整えることで、最終的には AI を前提とした業務そのものの再設計につなげていきたいと考えています。」（株式会社IHI 資源・エネルギー・環境事業領域デジタルトランスフォーメーション推進部チーム長鈴木千佳史様）横断的に AI 活用を進めることは、DX 推進部門のミッションです。ただ、業務知識は業務部門の中にあるので、何が役に立つのかは外から見えません。業務上の中身は各部門が決めます。一方、知識グラフの設計原則、登録手順、運用基盤は部門をまたいで共通です。DX 推進部門がこれらを維持することが、各部門が自部門の業務知識を持ったまま、同じ進め方を他部門へ広げる足場になります。 SVD アーキテクチャでは、部門ごとにクラスタを分けることができるので、全社共通の命名ルールが揃うのを待つ必要はありません。部門の中で登録が進めば、その部門では AI が言葉を扱えます。部門をまたいで呼び方のルールを揃える作業は、そのあとに回せます。同じ作り方なので、ある部門で採用している呼び方のルールを別の部門で再利用することもできます。網羅的な手順書は作れるのか私たちはこの取り組みを、重工業とゲームと IT の3業界で実施してきました。業界が変わると、アスペクトの考え方や業務知識の形式が全く変わります。当初は初期構築のパターンを網羅した厳密な手順書を作るつもりでしたが、扱えないものに繰り返し当たるうちに、プレイブック方式へと方針を変えることにしました。プレイブックは、外してはいけない設計原則と手順だけを定めて、細かいところは Kiro と相談しながら決める形です。この形にしたのは、お客様が自分で他部門の初期構築へ進めるようにするためです。組織として、AI とどう関わるのかこの取り組みで整理したのは、AI にどこまで任せるか（I）、任せない部分をどう整えるか（II）、整えたものを誰が持ち続け、発展させるか（III）の三つです。今回、AI には業務知識そのものを持たせず、社内固有の語彙を引いて適切に検索する役割を任せました。AI に任せなかった社内固有の語彙、文書から抽出した業務知識、データ構造は、知識グラフとして AI の外に置いています。図：AI に任せる範囲、AI の外に整えるもの、持ち続ける主体誰が何を担当すべきなのかは、担当するのに必要な知識を誰がもっているかで決まります。何を検索できるようにするか、どの呼び方が同じものかを判断できるのは業務部門です。一方、知識グラフの設計や大きな変更の手順、基盤の保守は部門をまたいで共通なので、DX 推進部門などの横断部門が持つのが自然です。業務部門が日々変わる呼び方と文書を追加し、検索対象や構造を変えるときは DX 推進部門が支援する分担です。私たちが重工業、ゲーム、IT の3業界で取り組んできた範囲では、上の整理は共通でした。業務部門が中身を持ち、横断する部門が作り方を持つ分担は、業務が変わっても応用できると見ています。この分担なら、全社で用語を揃えるのを待たず、一つの部門から始められます。部門内で用語や知識の登録が進むと、検索できる範囲が広がり、追加した呼び方や記録が次の検索に反映されます。部門ごとに同じ作り方で整えていけば、部門をまたいで束ねる作業は、そのあとに回せます。業務知識を AI Ready Data にする方法には、検索要件から始める方法のほか、オントロジーの作成から始める方法もあります（注 1）。どの方法でも、AI に任せる範囲、整えるもの、持ち続ける主体を決める必要があります。必要な業務知識は動き続けます。そこに AI を連れていけるのは、その仕事をしている人だけです。ただ、AI との関わり方のすべてを、その方が担う必要はありません。注 1：業務知識を AI Ready Data にする入口は、ほかにもあります。オントロジーの作成から入る道として、 Context Ontology Accelerator  がオープンソースで公開されています。OWL や R2RML といった W3C の標準に沿って作れます。著者/開発者紹介池田　拓史 (Hirofumi Ikeda) AWS プロフェッショナルサービスのシニアデータサイエンティスト。素粒子実験物理学で博士号を取得後、データサイエンス・コンサルティングに従事。現在は、機械学習や生成 AI を活用したお客様の業務変革と、データサイエンスの内製化を支援しています。近年は、生成 AI を業務で活用するための AI Ready Data の整備や、業務部門が自ら改善を続けられる仕組みづくりに取り組んでいます。中島　信也 (Shinya Nakajima) AWS プロフェッショナルサービスのデータサイエンティスト、デリバリコンサルタント（AI/ML）。製造業・建設業を中心に、様々な業種のお客様のDX化を支援しています。最近は生成AIの業務活用を支援させていただくとともに、安心安全なAWSアーキテクチャ設計の在り方を提案しています。