データ分析・AI導入において、コンサルティング（業務課題特定・要件整理）からアルゴリズム開発までをリードしている。最近では、消費財メーカーにおける棚割自動化や製造業における大規模言語モデルの活用を推進。数理最適化、ベイズ統計、深層学習（画像処理、言語処理、強化学習）と幅広い領域で経験を持つ。特に、数理最適化の領域を専門としている。（2024年1月時点）
23年に早稲田大学を卒業し、LTSに入社。入社後からデータサイエンスの領域に足を踏み入れ、現在は製造業における大規模言語モデルの活用支援や、不動産業におけるデータ活用支援を行っている。（2024年1月時点）
ハッカソンの実施内容
テーマ
ハッカソンでは「製造業」、「教育」、「ヘルスケア」、「銀行/金融」、「ソフトウェア」のドメインが提示され、各チームはいずれかのドメインを選択し、ビジネス課題を解決するためのLLMを用いたPoC構築を行います。単に技術的に優れているだけでなく、特に「実世界の問題解決」、また事業として成り立つのか―という点が重要視されます。そのため、各ドメインにどのような課題が存在するのか、深掘りすることが求められます。
チームのメンバー構成
チームはFPTとLTS混合で6チーム、各5名のメンバーで構成されます。各チームには、ビジネス、AI、フロントエンド、バックエンド、インフラの役割を持つコンサルタントとエンジニアが割り当てられました。また、各チームにはFPTとLTSのシニアマネージャークラスのメンターが一人ずつ付き、アドバイスを得ることができます。
評価観点
評価項目は「技術優位性」「創造性」「チームワーク」「プレゼンテーション」の4点。技術主導のハッカソンとは異なり、先述したよう「実世界の問題解決」が重要視され、評価項目でもそれが強調されている点がユニークです。FPTとLTS共同開催ということもあり、もちろんチームワークも重視されます。
スケジュール
ハッカソンのキックオフは開催の約3週間前。各チームは事前ミーティングをオンラインで開催することができます。ベトナムではHOLA PARK（FPT Software）の敷地内で活動し、キャンパスのゲストハウスに宿泊しました。2日間でアプリケーション開発を行い、最終日には、各チームが20分のプレゼンテーションと15分のQAを行いました。我々チームの具体的なスケジュールが下図です。
現地での様子
チームビルディングのための市内観光
ハッカソン中の議論
プレゼンテーション
セレモニー
優勝チームのアウトプット
テーマ
プロダクト名：”KnowledgeX”
製造業における操作マニュアル、技術文書、トラブルシューティングレポートといった社内文書、非構造化データから知識を抽出し活用するプロダクト。
背景・課題
私は以前、製造業のお客様から「PDFやPPTの技術文書から知識を抽出したい」という要望を頂いたことがありました。その時はLLMを一般的に利用可能することができなかったため、言語解析からアプローチしました。しかし、言語解析では単語分析やドキュメント分類しかできず、「知識」を抽出することは極めて困難でした。
現在、LLMの登場により企業文書から知識を迅速に検索し、この知識に基づいたQ&A作成や、創造的なアイデア出しができるようになってきました。また、LLM（Large Language Models）が会社内の最新かつ特定のドメイン情報に基づいて回答する手法、RAG（Retriever-Augmented Generation）のアーキテクチャもあります。
とは言え、企業文書にはしばしばPDFやPPT形式で図や表が含まれ、これらの情報をベクターDBに取り込むこと、さらにこの情報をベクターDBの意味のあるチャンク（データの塊）に分割することは困難です。製造業の現場では、操作マニュアル、技術文書、トラブルシューティングレポートに埋め込まれた知識を活用するための課題が浮き彫りになっているのです。
解決策
そこで私たちは、PDFやPPTのような非構造化データソースを、構造化された解釈可能な形式に変換する方法を検討しました。図や表をどのように情報として保存し、検索するかは非常に重要な問題です。そのためのアプローチの一つに、画像をテキストに変換するためのマルチモーダルモデル（言語＆画像）の使用があります。さらにもう一つ重要なのは、単にチャンクを作るのではなく、意味のあるまとまりとしてデータを保存することです。単なる言語の塊は、あくまでデータに過ぎず知識とは呼べません。
私たちは「知識とは何か？」を考えたときに、意味のある情報の塊と、そのつながりだと解釈しました。例えば、技術文書であれば、「背景」「実験方法」「実験結果」「考察」の情報がセットとして存在することで、知識として整理されているわけです。
ミッション
”KnowledgeX”のミッションは、企業内の非構造化データに埋もれた知識の活用です。非構造化データは企業データの80％から90％を占めていると推定され、残念ながら多くのデータが知識として活用されていないと言われています。将来的には、画像だけでなく音声やビデオコンテンツも含めた範囲を拡大し、複数のフォーマットのデータをまとめて処理するマルチモーダルモデルの強みを活用することを目指しています。
デモンストレーション
デモンストレーションとして、自動車に関するトラブルシューティングをサポートするプロトタイプを作成しました。データソースとして、自動車メーカーのトラブルシューティングガイドのPDFを利用しました。こだわった点は、単なるQ&Aではなく、「ユーザーを解決に導くアシスタント」という機能です。PDFを前処理で加工して「問題」と「解決策」のペアとして保存することで、問題を報告されるとそれに紐づく解決策を提示できるようになります。また、視覚的にわかりやすい出力を意識し、解決までのフローダイアグラムとマニュアルの図を出力できるようにしております。レスポンスとして、視覚情報（図や表）を出力できるアプリは、現時点ではほとんどないため、技術的な優位性もあります。
当日のプレゼンではストーリーボードを作成して、アプリがどのような場合に使えるのか、ユースケースを具体的に伝えるようにしました。余談ですが、ストーリーボードの図はDALL·E 3で生成されています、FPTのメンバー1人がわずか1～2時間で作成し、生成AIの新しい使われ方に驚きました。
テクニカルアーキテクチャ
実装では、PDFのような非構造データの中にある「図」の情報も、先述したRAGで取り扱えるように工夫しています。以下、「テキスト」「表」「図」を含むPDFのような非構造データに対するRAGの手法について説明します。
図の左側の前処理部分では、まず Unstructured という非構造化データを解析するツールを用いてPDFを「テキスト」「表」「図」に分解しています。その後、「テキスト」「表」「図」それぞれに説明文として要約を付与する処理を行っています。「図」に対する説明文の付与は、マルチモーダル・モデルを適用することで実現します。ハッカソン時はまだOpenAIのマルチモーダル・モデルにはアクセスできなかったため、LLaVAと呼ばれるモデルを利用しています。
「テキスト」「表」「図」を含むPDFのような非構造データに対するRAGの手法
LangChainのCookBookより参照：Semi_structured_and_multi_modal_RAG.ipynb
図の右側では、登録した「テキスト」「表」「図」の情報を検索し、回答に利用している様子を表しています。これは一般的なRAGと同じアーキテクチャとなっています。事前に「表」や「図」に対して説明文をつけており、その文章に対してベクトル検索することで「表」や「図」も回答に追加できます。これにより、デモンストレーションでは図を出力として含めることができました。また、フローチャートで表示できるようにMermaidの形式に出力を加工しています。
ハッカソンを通じた学び
今回のハッカソンで最も求められたことが、「LLM」を用いて「実世界の問題解決」することでした。そのため、事業ポテンシャルのあるLLMの活用方法とは？という問いを深く考えさせられました。また、ビジネスアイデアを具体的なアプリとして短期間で実装する経験から、以下のような学びを得ることができました。
1：LLMはったん忘れて顧客の「ペイン」から考える
LLMは汎用性が高く、活用先のアイデアはいくらでも出てくるでしょう。さらに、LLM周辺の技術は非常に速いスピードで整備されており、誰でも簡単にアクセスできます。先日もOpenAIのカンファレンスDevDayにて、ユーザーが自由に専用のGPTを作成する「GPTs」の構想が発表されました。すでに「GPT Builder」の機能を用いれば、ノーコードで、自然言語の指示だけで自分専用のGPTを作成できます。LLMありきのアイデアやプロダクトは、だれでも思いつく上に技術的優位性を確立できないためすぐに模倣されてしまいまいます。例えば、王道の活用事例として、MicrosoftのCopilot等プラットフォーム側の機能として組み込まれていくことがあります。LLMはこれまでできなかったことを簡単に実現できる一方、技術へのアクセスが容易なため、競争優位性のあるビジネスを確立することは非常に困難なのです。
LLMのユニークな活用方法を検討するには、逆にLLMのことはいったん忘れ、顧客の悩み・ペインにフォーカスすることからスタートした方が良いのではないでしょうか。LLMはその汎用性の高さから、どのような問題設定であっても何かしら活用の余地があります。
2：従来のAI開発とは開発方法が大きく違う
LLMを用いたアプリ開発と従来のAI開発とは大きく違うのは、AIモデル自体を作る必要はなく、活用するところからスタートできることです。これは、LLMが基盤モデルであり、汎用性を持ったモデルであるためです。開発プロセスの違いについては、IPA（情報処理推進機構）とデータサイエンティスト協会が作成した「タスクリスト」で分かりやすく整理されています。図の右側がLLMを活用する場合のタスクリストです。
参考：2023年度スキル定義委員会活動報告（2023年度版スキルチェック＆タスクリスト公開）
https://www.datascientist.or.jp/common/docs/10thsymp_skill.pdf
ポイントは、ビジネス側との相互作用が速い段階で行われること、継続的に行われていることです。ハッカソンでも2日あればプロトタイプを作れたように、顧客に速い段階でプロトタイプを提示することが可能です。また、LLMは、定量的な評価が難しい言語という出力を取り扱うため、顧客側からの継続的な評価が欠かせません。従来のAI開発は、3～6ヶ月のPoCが上手くいってからシステム開発を行い、ようやく実務で検証する―という流れでした。一方、LLMのアプリ開発では、素早くプロトタイプを作って、顧客側からの評価を得るアジャイル開発と親和性が高いのです。
AI開発のPoCは多くのものが3～6ヶ月で実行されていましたが、LLM活用では、アジャイル開発でプロジェクト組成する必要があり、これまでとは全く違うプロジェクトの進め方、メンバーづくりが必要となります。また、アジャイル開発だけでなく、今回のハッカソンのような場も、検証方法の一つとして有望だと感じました。
所感と今後の展望
新卒1年目のメンバーは
今回のハッカソンは私にとって、初めての出張、経験でした。参加決定から終了まで、不安や上手くいかない現実と向き合う場面もたくさんありました。自分の能力不足も身に染みて感じることができ、悔しい思いをする場面もありました。その過程で、周りの方々の支えに改めて気付くことができ、「いいプロダクトをつくりたい」と一丸になったチームや周囲のメンバーからの刺激によって、最後までやり遂げることができました。反省点は多々ありますが、優勝できたことは大変嬉しく、セレモニーの場では思わず涙が出そうになってしまいました。
改めて気付いたのは「どれだけ難しそうに見えたとしても、自分自身の興味関心には逆らわず、それらをやり遂げようとする」ことの大切さです。また、FPT-AICのメンバーの技術力の高さを目の当たりにしたことで、協業を通した可能性の拡がりも実感することができました。
今後は、参加者としてはもちろんですが、運営側としての役割も担っていきたいと考えています。すでに第2回LTS×FPTのハッカソンが日本で開催されることが決まり現在、準備にも携わっています。ハッカソンを長く開催できるように、第2回を成功させ、多くの社員がこのような経験をできるようにするのも、私の目標です。
共創の場としての可能性
FPTとのハッカソンは、国際コミュニケーションや技術力を短期的に伸ばす人財育成の場としても非常に有用です。参加者全員が、国際コミュニケーションや先端技術の実装をやり切ることで自信を付け、次のステージへの目標を設定できたように感じます。
目標はハッカソンを継続的に開催し、国際的に活躍できるエンジニア、データサイエンティストとして視座を高めること。次回ハッカソンでは実際の顧客も巻き込んで実施することが決定しており、共創の場としての可能性を非常に感じております。いまはFPTとLTSのコラボレーションですが、その関係だけに閉じず、ビジネス課題を持つ会社と技術力を持つ会社を巻き込んでいければと考えています。
