はじめまして！Data Scientistの市川です。 今回は、先日第34回 人工知能学会 金融情報学研究会（SIG-FIN） に行ってきましたので、そのレポートをさせて頂ければと思います。 イベントの概要 発表の概要 SIG-FIN UFO-2024 タスク(6件) (01) 有価証券報告書の表を対象としたUFO-2024コンペティション (02) 表構造の理解と表項目の説明文生成に基づくTable QAタスクへの挑戦 (03) 有価証券報告書の表質問応答を対象としたSIG-FIN UFO-2024タスクにおけるUTUtLB25チームの性能評価 (04) 二値分類モデルに基づく有価証券報告書を対象とした表解析手法の提案 (05) 有価証券報告書の表理解タスクに対する解法の提案 (06) 類似した質問と表に基づく表検索及び大規模言語モデルを用いたOne-shot表質問応答 人工市場・投資戦略(5件) (08) 人工市場を用いた規制を考慮したETF・原資産市場間のショック伝搬の分析 (09) LLMベースのエージェントによる人工市場シミュレーションの構築 (10) 重み付きTsallisエントロピー正則化に基づくリスクパリティ・ポートフォリオの一般化 (11) 推薦システムにおける多様性を利用したアセットアロケーション 金融市場(6件) (12) 人工知能学会 金融情報学研究会(SIG-FIN)の歴史 - AIと金融の技術史の一部として議論 - (13) 経済状況に応じてベーシックインカムがもたらす変化 (14) 経済フェルミ推定問題: 因果構造推論による推定の改善 (15) 東京証券取引所の市場再編における売買高への影響について (16) 資産価格のジャンプとグラフによる資産の関係性の異常検知手法の提案 (17) アート資産の分散投資効果の実証分析 テキストマイニング・LLMs(5件) (18) 金融テキストを対象とした強弱を捉えることができるセンチメントモデル開発のためのデータセット構築方法の検討および分析 (19) 景気ウォッチャー調査のデータセット構築と物価センチメント分析 (20) 決算短信を用いた業種ごとの年間レポートの自動生成 (21) LLMを用いた情報系企業のESG評価についての一考察 (22) LLMによる大量保有報告書における担保契約等重要な契約に関する情報の構造化 機械学習1(5件) (23) 多様なテンプレートと合成データを用いた大規模言語モデルの業種区分予測における知識抽出 (24) 機械学習による企業業種分類の定量評価と応用 (25) 機械学習を用いたクロスセクション予測における株価および業績シグナルの比較分析 (26) Multi-step Utility Lossを用いた深層学習モデルよる動的ポートフォリオ最適化 (27) ボラティリティ推定機能を持つ条件付き拡散モデルによる金融時系列生成 機械学習2(5件) (28) ベイズ推定における事前分布の作成にChatGPTを用いた暴落時の日経平均株価の予測 (29) 深層生成モデルによる金融市場の注文板の生成 (30) 機械学習モデルを用いたシミュレーション分析：地方債市場における会計情報の寄与 (31) KANベース自己符号化器を用いた国債イールドカーブのファクターモデルの構築 (32) 有価証券報告書と統合報告書を活用したESG投資のためのオントロジー構築と生成AIによる情報抽出 雑感 イベントの概要 人工知能学会 金融情報学研究会（SIG-FIN） は人工知能学会の第二種研究会です。 詳細は上記リンクに譲るのですが、近年より広い方々の金融市場への関心が高まっています。このような背景で、ファイナンス分野への人工知能技術の応用を促進するための研究会になります。人工知能分野の研究者や金融市場の現場の技術者が参加する、大変ユニークな研究会になっています。 最近、かなり発表量が増加傾向にあり、聴いているだけでも忙しい研究会です。例年、土曜日の1日のみの開催でしたが、発表数の増加に伴い、土日を両方使う研究会となりました。 概要は以下の通りです。 * 日時：2025年3月1日(土) および 3月2日(日) * 開催形式：会場およびオンライン（Zoom使用）のハイブリッド開催 * 会場：KPMGコンサルティング 第34回研究会 発表の概要 こちらの研究会はありがたいことに 各発表の概要pdfが公開されています 。 以下、著者の敬称略とさせて頂きます。 SIG-FIN UFO-2024 タスク(6件) (01) 有価証券報告書の表を対象としたUFO-2024コンペティション 木村 泰知, 佐藤 栄作 (小樽商科大学), 門脇 一真 (日本総合研究所), 乙武 北斗 (福岡大学) UFO-2024のタスクの概要 https://sites.google.com/view/ufo-2024/ データセット https://github.com/nlp-for-japanese-securities-reports/ufo-2024/ 有価証券報告書の37%が通常の機械判読では難しい複雑な表と言われている。 UFO-2024 では、TOPIX500の有報を対象とした表検索(Table Retrieval)タスクと表質問応答(Table QA)タスクがある。 このセッションでは、コンペの上位者の解法をシェアする場になっている。 (02) 表構造の理解と表項目の説明文生成に基づくTable QAタスクへの挑戦 髙砂 爽, 秋葉 友良 (豊橋技術科学大学) アプローチの大きな特徴は、表を「見出し部分（ヘッダ）」と「データ部分」に分割し、セルをテキスト化することで自然言語処理技術（BERTやBM25など）を適用可能にしている点です。 表の前処理と正規化 - HTML形式の有価証券報告書から表を抽出し、セルの文字列を正規化（全角・半角や日付の統一、通貨・数値の単位変換など）します。 - 行全体・列全体・表全体にかかる単位を検出して数値をスケーリングし、セル単体の単位も検出して処理する仕組みを導入しています。 TDE（Table Discriminative Explanation）を用いた表構造解析 - 各セルを「Metadata」「Header」「Attribute」「Data」の4種に分類するタスク（NTCIR-17 UFOのTDEサブタスク）をBERT分類器で実装し、その結果をもとにテーブルを「上側（見出し）」「左側（見出し）」「右下（データセル）」の領域に分割します。 - 分割の際は、見出し部分をHeader/Attribute/Metadataセル、データ部分をDataセルとしてスコア（TSS）を最大化する分割位置を探索します。これにより、多くの場合は上数行×左数列が見出し、残りがデータとして認識されます。 表のテキスト化（文章生成） - 分割後のテーブルから、見出しセルとデータセルの組合せをテンプレート「XのYはZです。」で文章に変換します（Xは上側見出しの結合、Yは左側見出しの結合、Zはデータセルの値）。 - たとえば「第44期」「売上高」「458140」の3セルが対応していれば「第44期の売上高は458140です。」のように文章化。これにより、テーブルの中身を自然言語の文書として扱えるようになります。 TableRetrievalタスク - 論文IDごとに抽出した各表をテキスト化した文書にまとめ、BM25によるベクトル検索を用いて「質問文に最も合致する表」を探す、という構造になっています。 - 実験ではNTCIR-18 UFOデータやSIG-FIN UFO2024データを用いて検証が行われ、工夫としては「表上部にある説明文を追加する」「空セルの扱いを工夫する」などの改善により、精度を向上させています。 TableQAタスク - 与えられた表ID（TableRetrievalによって特定されたもの、またはタスクで指定されたもの）と質問文をもとに、「どのセルが答えか」を見つけて値を抽出します。 - 具体的には、質問文と各セル（テキスト化した文章）をBERT分類器で2値分類（適合／不適合）し、適合と判断されたセルを回答候補とします。 - 学習にはNTCIRやSIG-FIN UFO2024で提供されたクエリ（質問）と正解セルのデータを使い、さらに空文字セルなどは除外するといった最適化を行うことで、座標および値の正解率を向上させています。 実験結果と考察 - TableRetrievalタスクでは正解率0.341程度、TableQAタスクではセル座標の正解率0.743、値の正解率0.701といった成果を得ています。従来のベースラインやGPT-4モデルを用いた手法と比べても、TableQAの値抽出精度が上回るなどの有望な結果が示されています。 - 一方で、表が複雑に結合されているケースや、セル内に長文が記載されているケースなどは文章化が難しく、さらなる精度向上には「より柔軟な表分割手法」「Text-to-Text生成の活用」などが必要であるとしています。 (03) 有価証券報告書の表質問応答を対象としたSIG-FIN UFO-2024タスクにおけるUTUtLB25チームの性能評価 司 龍, 張 引, 王 小天. 宇津呂 武仁 (筑波大学) SIG-FIN UFO-2024タスクのうち「表質問応答（Table QA）」サブタスクを対象としています。 LLMを用いて課題解決を試みています。 データセット 対象データ EDINETから取得したTOPIX100企業の有報（HTML形式）をもとに、HTML→CSVへ変換した表データを使用し、自然言語の質問文を生成して構築。最終的に合計496文書・8,116表・13,675件の質問文（訓練・検証・テスト）に分割している。 質問文の生成 CSV形式の表に対するテンプレートを作り、ChatGPTを用いて様々な言い回しの自然言語に変換することで、多様性のある質問文を作成。 表質問応答手法 タスク設定 - 入力: 質問文、および該当する表ID（Table ID） - 出力: 質問への解答としてセルの座標（Cell ID）またはセルの値 - 評価: 解答が正答と一致するかどうかのAccuracy（正解率） LLMを用いた表QA - プロンプト設計 - システムプロンプト・ユーザープロンプトにおいて、回答フォーマットや出力を厳密に指定。 - Temperatureを0にするなど、確率的な変動を抑えて安定した出力を得る。 - Zero/Few-shot学習 - サンプルとして提示する質問・回答例（ショット数）を変化させ、精度がどう向上するかを調査。 実験結果 - GPT-4・Claude 3.5・Gemini・Grokなど複数LLMを用い、検証用データに対する「Cell ID」と「Value」それぞれの正解率を測定。 - 最も高精度 だったのはAnthropic社の「Claude3.5-Sonnet」で、セル座標の正解率90%、値の正解率93%を達成。 - 多くのモデルでFew-shot学習によって精度が向上するものの、ショット数を増やしすぎると逆に精度が落ちる場合もあり、適切なショット数の選択が重要となる。 - 誤り分析では、ハイフンを「0」と解釈する誤りや単位のミスなどがショット数増加で減る一方、セルを取り違える誤りは残存した。 NTCIR U4タスクとの比較 - SIG-FIN UFO-2024と同様に有報の表QAを扱うNTCIR-18 U4タスクでも同手法を適用しており、ClaudeやGrokなど複数モデルで高精度を実現。詳細は別の論文で議論しているが、U4とUFO-2024を通じて、LLMが大規模な日本語表QAにおいて高い性能を発揮することを確認。 結論 LLMを用いた日本語有報の表質問応答で高精度が得られることを示し、特にFew-shot学習は精度向上に大きく貢献する。一方でセルの取り違いなど特定種の誤りはまだ残っており、追加対策の必要性が示唆される。 (04) 二値分類モデルに基づく有価証券報告書を対象とした表解析手法の提案 藤田 優希, 水島 陵太, 乙武 北斗, 吉村 賢治 (福岡大学) それぞれに対して二値分類モデルを中心とした手法を提案しています。 Table Retrievalの場合 1つの有報内に多数存在する表の中から、与えられた質問（自然言語）に対して「答えが含まれる表」を特定するタスク。膨大な候補表へのアプローチとして、 二値分類モデル を最終ステップに用いるが、データの不均衡や計算量の問題を解決するために以下の多段階処理を導入。 ルールベースの前処理 - HTMLのtableタグ内のth/tdからテキストを抽出し、数字・一般的な語（「百万円」「合計」など）や記号の削除、日付表記の正規化などを行う。 質問文からセクションを予測して絞り込み - 有報は第一部・第二部など複数のセクションに分かれており、質問文から「どのセクションに属するか」を多クラス分類モデル（BERT）で予測し、該当セクションの表だけに候補を絞る。 Embeddingモデル（多言語E5）によるコサイン類似度でさらに候補削減 - 質問文と表の埋め込みを取得し、コサイン類似度が高い上位100件を残す。 Rerankモデル（ruri-reranker）を適用 - 類似度上位100件をさらにスコア順に並び替え、上位最大50件を候補とする。 二値分類モデル（BERT） - 候補となった最大50件を正例（答えを含む表） or 負例（含まない表）に分類。最終的にスコア最大の表を回答とする。 - 分類層の構造（全結合層数、質問と表の連結方法など）を比較し、一部構成を変更したモデルが最も高い精度（約0.84）を達成。 結果 - Publicスコア（Accuracy）で約0.84を得て、ベースライン（約0.21）を大きく上回る高精度を達成。 - 前処理が著者の主観に依拠しており、より客観的・体系的なルール構築が必要。 Table QA - 与えられた質問文に対して、該当する「セルの位置（Cell ID）」および「セル内の値（Cell Value）」を特定する。 - 有報の表はセル結合（rowspan, colspan）が多様で、単位や数値表記もまちまちであるため、フラットなテキスト化だけでは構造が十分に捉えられない。 表の構造解析（RCI） - HTML表を行・列ごとに分割し、行・列それぞれが質問に対してどの程度関連するかを二値分類モデルで判定。最も関連度が高い行と列の交点をセルの位置とみなす。 - モデルとしてはDeBERTa V3を採用。 値の正規化（T5） - 抽出したセルに含まれる数値・単位のズレを「T5」による生成タスクで正規化。 - たとえば「1,000千円」や「△302 百万円」などを共通の表現に変換する。 結果 - Cell IDの特定精度は約0.91、Cell Value（単位考慮）の正解率は約0.87を達成。 - GPT-4など大規模LLMベースラインの値予測精度（最大0.74前後）を上回る。 結論 - Table Retrieval : 一連の多段階フィルタリング＋二値分類モデルで、高い正解率（約0.84）を実現。 - Table QA : 表の行・列それぞれへの二値分類モデル（RCI）でセル位置を特定し、T5で値を正規化する分割アプローチが、LLM単体を用いた方法より高精度を示す（Cell Value約0.87）。 (05) 有価証券報告書の表理解タスクに対する解法の提案 別木 智也 (MTEC) 特徴としては、有報内のヘッダタグ（h1～h6）を活用した「目次データベース」を学習データから構築し、質問文のキーワードやLLM（GPT-4o-mini）を段階的に組み合わせて候補表を絞り込む点にあります。 データセット - 対象はTOPIX500の企業が2023年7月～2024年6月に提出した有報（HTML形式）。 - 学習データ・評価データ・テストデータに分割され、計493社・約13,673件の質問文が用意されている。 - 各HTMLには複数の <table> 要素が含まれ、一意のtable-idが振られている。 提案手法の概要 著者の手法は「目次情報（h1～h6）を使った段階的な絞り込み」と「質問文のキーワード抽出」「LLMによる最終的な判定」という3ステップで構成されています。 目次データベースの作成 - 学習データ（企業と、その企業のHTML内のtableに対する正解表）を使い、各テーブル（table-id）を含むHTMLのh1～h6タグ情報（ヘッダー）と紐づけて「目次データベース」を構築。 - 例えば「S100RX3W-0101010-tab2」はh1：第一部企業情報、h2：企業の概況 …などの見出しを持つ、というようにJSON形式で保存。 目次を利用した絞り込み 1.キーワード抽出 - 質問文は「○○年度の●●決算における『▲▲、△△』は？」など画一的 - 鍵括弧内の語や「連結決算／個別決算」などをキーワードとして抽出 2.学習データから同じキーワードを含む質問を検索し、当該質問の正解table-idに対応する目次情報を取得 - 当該ヘッダー情報（h1～h6）と一致するテーブルだけを候補とする。 - 目次段階での絞り込みにより、不要なテーブルを大幅除外。 キーワードを利用した絞り込み - 目次段階で候補が複数残った場合、それら候補テーブルのヘッダー・セルテキスト中の「キーワード出現数」がもっとも多いtable-idを選ぶ。 - 出現数が同数の場合は複数残す。 LLMを利用した絞り込み - table-idが一意に絞れない場合に、GPT-4o-miniを用いて最終決定を行う。 - 質問文を自然な形へリライトし、各テーブルのテキストとともにLLMに投げ、最適なtable-idを構造化出力させる。 評価 - 検証データでの段階的絞り込みごとの再現率（Recall）を計測。 目次 ：約99.7% キーワード ：約96.3% LLM ：約75.1%（=最終Accuracy） - LLMステップで大きく精度が落ちる理由として「経営指標等」など多義的表現が複数テーブルに該当したり、自然言語変換時に情報が省略・誤訳されるケースが挙げられる。 (06) 類似した質問と表に基づく表検索及び大規模言語モデルを用いたOne-shot表質問応答 田中 麻由梨 (JPX総研), 土井 惟成 (日本取引所グループ) 類似した質問と表を活用した検索 質問文の埋め込みと類似質問の取得 - 事前学習済みモデル（RoBERTa）を利用し、学習データ（Trainセット）の質問文をベクトル化。 - テストデータ（Testセット）の質問文を同モデルで埋め込み、Trainセットとコサイン類似度を計算して最も近い質問を選ぶ。 BLEUスコアを用いた表類似度計算 - 得られた「最も類似するTrainの質問」に紐づいている表（1つ）をテキスト化（角括弧の二重リスト形式など）し、Testセットに含まれる各表のテキスト化結果とのBLEUスコアを計算。 - 最もBLEUスコアが高い表を最終的な解答とする。 このプロセスにより、まず似た質問文を介して関連表を当たりをつけ、その上でテキスト化した表同士の類似度をBLEUで評価する多段階検索を実現している。 表質問応答タスクの提案手法 LLMを用いたOne-shotプロンプティング - Testセットの各質問に対し、同じく「最も類似するTrainの質問」を検索し、その質問＋正解セルを含む表のペアを「One-shotのサンプル」としてLLM（ChatGPT-4o）に与える。 - プロンプト中では「サンプル質問＆表 → 正解セルID」を示し、同じフォーマットでTest質問に対応するセルIDを出力させるよう誘導。 - まずセルIDを抽出し、その後に値を取り出す手順を取ることで、LLMが正確なセルを指定しやすくする狙いがある。 実験 - データ : SIG-FIN UFO-2024のTrain・Testセットを使用。 - 表検索 : Accuracy=0.7320。役員個人名などTrainに登場しない固有情報への対応が弱点。 - 表質問応答 : - Zero-shot（サンプルなし）: セルID正解率=0.6727、値の正解率=0.1462。 - One-shot（サンプル提供）: セルID正解率=0.7326、値の正解率=0.1776。 - One-shotによりセルIDの精度が向上しており、適切なサンプルを提示する効果が確認された。一方、値の正解率が低いのは単位や数値の表記揺れに対処していないためと考えられる。 人工市場・投資戦略(5件) (08) 人工市場を用いた規制を考慮したETF・原資産市場間のショック伝搬の分析 遠藤 修斗 (工学院大学), 水田 孝信 (スパークス・アセット・マネジメント), 八木 勲 (工学院大学) ETF（上場投資信託）とその原資産市場（2つの原資産市場）を人工市場シミュレーションで構築し、そこに誤発注やファンダメンタル価格の下落といった「ショック」が発生した際に、裁定取引を通じて市場間でどのように価格下落が伝搬するかを分析しています。さらに値幅制限を代表とする規制の有無がショック伝搬の程度にどのような影響を与えるかを調査する点が特徴です。 目的と背景 - ETFと、それを構成する複数の原資産市場との間では裁定取引が行われるため、一方の市場でショックが起こると他方へも価格変動が波及する可能性が高い。 - リーマン・ショックやフラッシュ・クラッシュのような急激な下落を防止するために、証券取引所などでは値幅制限・サーキットブレイカーといった規制が導入される。しかし市場によって規制導入の状況は異なる。 - 過去の実証データだけでは各規制の直接的な効果を明確に切り分けるのが難しいため、マルチエージェント・シミュレーション（人工市場）を用いて規制の影響を定性的に分析する。 主な結果 - ショック伝搬の確認 : いずれの場合も、裁定取引によってショックを受けた市場の価格下落が他市場へ伝わることを確認。 - 値幅制限の影響 - 原資産市場側にショックが起こった場合は、原資産市場への値幅制限導入で自市場やETF市場の下落幅が小さくなるケースが多い。 - 一方でETF市場への誤発注ショックの際は、原資産市場に値幅制限があると価格差が拡大してしまい、かえってETF市場側の下落が抑えられにくい場面が見られた。 - 原資産市場1のファンダメンタル価格下落時は、当該市場に値幅制限があれば下落が緩和される一方、ショックを受けていないもう一方の原資産市場が値幅制限を導入していると、その市場はかえって他市場から伝わる下落が大きくなる場合があった。 - 総括 : 「どの市場にいつ値幅制限を導入するか」でショックの拡大・抑制効果が変わることが示唆された。特に、ある市場の下落が裁定取引を介して他市場の価格をも押し下げる過程で、規制の有無がダイナミクスを複雑化させる。 (09) LLMベースのエージェントによる人工市場シミュレーションの構築 平野 正徳 (PFN) 大規模言語モデル（LLM）を利用したエージェントを人工市場シミュレーションに導入し、伝統的な“ノイズトレーダーモデル”では再現しにくい金融市場特有の性質（いわゆるスタイライズド・ファクト）をどこまで再現可能かを検証した研究です。 背景と目的 - ChatGPTやGPT-4といったLLMの登場により、人間のようにテキストを入出力できる「思考を持ったかのような」振る舞いが一部可能になっている。これをエージェントとみなし、各種シミュレーションへの応用が期待されている。 - 既存の人工市場シミュレーションはエージェントの振る舞いを数式化する場合が多いが、それだと実際の投資家の複雑な意思決定を忠実に表現するのは難しい。そこで、言語モデルを用いたエージェントを導入することで、より人間らしく複雑な意思決定をする株式トレーダーを実装できないかを探る。 人工市場モデルの構築 エージェントの種類 LLMエージェント 大規模言語モデルにプロンプト（市場情報・過去価格・ファンダメンタル等）を与え、指値または成行の売買判断を行う。 LLMへのプロンプト内容（ファンダメンタル・ポジション情報・プロスペクト理論の考慮など）を複数パターン用意して効果を比較。 ノイズエージェント 買い/売り価格をランダムに決める。外部要因による取引をモデル化するためのエージェント。 実験設計 実験パラメータ LLMエージェントの割合：0%, 10%, 20% LLMエージェントのプロンプト構成：ファンダメンタル、ポジション、プロスペクト理論の3要素をオン/オフ → 全8通り それぞれの条件下で100回のシミュレーションを行う。 評価指標 : 金融市場の典型的特徴（スタイライズド・ファクト）の一部に着目 リターンの平均がほぼ0（もしくは極めて小さい正） 尖度（ファットテール度合い）が大きい（>3） 歪度が負（下落側に厚みをもつ分布） 実験結果 - ノイズエージェントのみではファットテール性をはじめ多くの要素が再現困難。先行研究と同様、ランダム注文だけでは価格分布が正規分布に近くなり、尖度が小さい。 - LLM導入による改善とプロンプトの影響 - LLMエージェントを追加すると、尖度が増大し歪度も負になる傾向が出てくる。 - ただし「どのようなプロンプトを与えるか」が非常に重要で、些細な変更で結果が大きく変わる。 - 実験では以下のような一般傾向が見られた： 1. ポジション情報をプロンプトに含める ： 歪度が負になるケースが多い（LLMが自分の持ち高を理解し、売りポジションを取りやすくなる）。 2. ファンダメンタル価格を含める ： 価格が大きく動いた際にファンダメンタルへ回帰する意識が働くようで、リターンの分布裾が重くなり、尖度が大きくなる。 3. プロスペクト理論の記載を含める ： リスク回避度合いが変わり、下落局面でボラティリティを増す動きが生じる場合がある。 - 結果として、 ファンダメンタル・ポジション・プロスペクトの3要素をすべて含むプロンプト を与えたLLMエージェントが存在する場合に最もスタイライズド・ファクトに近い分布になった。 (10) 重み付きTsallisエントロピー正則化に基づくリスクパリティ・ポートフォリオの一般化 中川 慧 (野村アセット/大阪公立大学), 土屋 平 (東京大学) 従来の平均分散法やリスクベースのポートフォリオ構築における課題を克服するため、 重み付きTsallisエントロピー を正則化項として組み込んだ新たなポートフォリオ最適化手法を提案しています。特に、通常のリスクパリティやリスクバジェッティング・ポートフォリオは期待リターンを考慮しないため、リターン面で非効率になりやすいという問題に対し、Tsallisエントロピーを用いて銘柄分散と期待リターンの両方をバランスよく取り入れる点が本研究の特徴です。 (11) 推薦システムにおける多様性を利用したアセットアロケーション 星野 知也 (三井住友銀行) 推薦システムにおける多様性（diversity）の概念を資産配分（アセットアロケーション）に適用し、集中投資によるリターン追求と分散投資によるリスク低減を両立させる新たなポートフォリオ構築手法を提案しています。推薦システムの分野では、利用者の選好に合うアイテムを提示する一方、類似アイテムばかりを冗長に提示すると満足度を下げてしまうため、関連性（relevance）と多様性（diversity）のトレードオフが重要視されます。これを「投資家の見通し（リターン追求）と資産間の類似度（分散投資）」の問題に対応づけて、以下の2つの代表的手法を活用しています。 手法の概要 行列式点過程（Determinantal Point Process, DPP） - フェルミ粒子系のように「要素間に斥力（repulsion）が働く」点過程モデル。 - 離散集合から部分集合を選択する際、要素間の類似度が高い組合せが同時に選ばれにくくなる性質をもつ。 - 各資産への「見通し」スコア（類似度の対角成分に対応）と、資産間の相関などの類似度（非対角成分）を行列 ( L ) に組み込み、行列式を最大化することで関連性と多様性を両立できる。 周辺関連性最大化（Maximal Marginal Relevance, MMR） - 情報検索や推薦システムでよく使われる再ランキング手法。 - 「利用者クエリとの関連度」と「既に選択したアイテムとの非類似性」を線形結合してスコアを定義し、アイテムを段階的に選んでいく。 - アセットアロケーションにおいては、投資家の見通し（関連性）と資産間の類似度（非類似性を大きくして多様化）をバランスよく組合せる。 実証分析のポイント 対象銘柄 : S&P 500構成銘柄（2015～2024年の10年データ） 比較対象 : 最小分散ポートフォリオ (MV) 逆ボラティリティ (IV) 等ウェイト (EW) モメンタム上位銘柄 (Mom) ブラック-リッターマン・モデル (BL) 手法 : DPP: 資産間の相関行列やグラフラプラシアンを用いて多様度を制御。 MMR: 資産を1つずつ貪欲に追加し、多様性を確保。 まとめと意義 - 新しい視点の導入 : 推薦システムで検討されている「関連性 vs. 多様性」の枠組みをアセットアロケーションに応用し、銘柄選択でリターン追求とリスク分散を同時に考慮する。 - 理論的背景 : DPP・MMRは元々情報検索・機械学習の分野で研究が進んでおり、多様性に特化した優れた性質を持つ。これを資産間の相関構造や投資家の見通しに組み合わせることで、新たなポートフォリオ最適化を提案。 - 実証的評価 : S&P 500銘柄を対象とした検証では、従来のリスクベースやモメンタム戦略に対し、リスク調整後のパフォーマンス向上やドローダウンの抑制といった優位性が見られた。 金融市場(6件) (12) 人工知能学会 金融情報学研究会(SIG-FIN)の歴史 - AIと金融の技術史の一部として議論 - 水田 孝信 (スパークス・アセット・マネジメント) 人工知能学会 金融情報学研究会 (SIG-FIN) の創設から約16年余りの歴史を振り返りながら、金融とAI（人工知能）の歩みを概観したものです。2008年の研究会発足当初は参加者が少ない時期もありましたが、第3次AIブームに連動して発表件数や参加者数が急増し、さらにコロナ禍でオンライン化を経験して現在まで継続してきた経緯を整理しています。金融情報学研究会が日本におけるAIと金融の発展にどのように寄与してきたかが、時代ごとの出来事とともに記されています。 (13) 経済状況に応じてベーシックインカムがもたらす変化 高島 幸成 (白鴎大学), 八木 勲 (工学院大学) 研究の背景と目的 ベーシックインカム（BI）は、全ての人に無条件で一定の所得を給付する制度であり、貧困対策や社会保障の簡素化などの観点から近年注目を集めています。一方で、BIを全面的に導入した際の労働意欲（労働供給）が低下する懸念や、社会・経済全体に及ぼす影響が不確実とされ、従来は実証実験や限定的な理論研究に留まっていました。 本稿では、このような不確実性を解消する一手段として、相対的な所得に対する効用（他者との所得格差を意識した労働意欲の変化）を取り入れた複層的なフィードバック構造を持つエージェントベース・マクロ経済モデルを構築し、景気の好調期や低迷期など“経済状況の違い”によってBIの効果がどのように変化するかを分析しています。 (14) 経済フェルミ推定問題: 因果構造推論による推定の改善 安田 卓矢, 村山 友理, 和泉 潔 (東京大学) 経済フェルミ問題（Economic Fermi Problems: EFPs）において、複数のLLMにより回答と評価を一貫して実行する仕組みを提案し、さらに 因果構造推論（Causal Structural Reasoning） を組み込むことで推定精度を高めることを目指しています。 (15) 東京証券取引所の市場再編における売買高への影響について 丸山 博之 (拓殖大学) 東京証券取引所では、2022年に東証一部・二部・マザーズ・JASDAQ（Standard/Growth）の4区分を、プライム市場・スタンダード市場・グロース市場の3区分へ再編しました。本研究では、この市場区分の変更が個別銘柄（本稿では水産・農業関連銘柄）における 売買高 の変化に影響を与えた時期を特定することを目的とし、 閾値自己回帰モデル（Threshold Autoregression） を用いて分析を行っています。 データ - 日次ベースの売買高などをJPXデータクラウドから取得。 - 市場再編の実施日を基準に前後3か月（計6か月）のデータを対象。 - 水産・農業セクターの銘柄をサンプルとして使用。 閾値自己回帰モデル : - 時系列データ x_t に対し、ある閾値 c を境にパラメータが異なる2つの回帰式を適用する。 - 本研究では y_t = t / T (t: 時点、T: 全期間) を閾値判定に用い、売買高の対数平均値についてモデルを推定。 主な結果 3つのグループいずれにおいても実際の市場区分が変更される“前”に売買高に明確な変化が確認されました。具体的な閾値（状態が変化した日）は以下の通りです。 東証一部→プライム市場 : 2022年2月2日に閾値を境に状態変化 東証一部→スタンダード市場 : 2022年2月16日に状態変化 JASDAQスタンダード→スタンダード市場 : 2022年3月11日に状態変化 実際の市場再編が行われたのは4月4日ですが、 早い銘柄では2月初旬から売買高の変化が起きている と推定されました。 市場再編の公式実施日より前に、投資家は区分変更を見越した売買・資金移動を行った可能性が高い。 東証一部からプライム市場へ移行した銘柄が最も早く状態変化が生じ、JASDAQスタンダード→スタンダード市場の銘柄はやや遅れて変化が起きている。 これは市場区分ごとに投資家からの注目度や事前の思惑の度合いが異なることを示唆する。 (16) 資産価格のジャンプとグラフによる資産の関係性の異常検知手法の提案 中田 喜之, 吉野 貴晶, 杉江 利章 (ニッセイアセットマネジメント), 関口 海良, 劉 乃嘉, 大澤 幸生 (東京大学) 背景と目的 資産運用においては、複数資産のリターンの関係（相関）をもとに配分（ポートフォリオ構築）を行うリスクベース戦略がよく用いられます。しかし、市場環境によって資産間の関係は大きく変化するため、そうした変化をいち早く検知できないと運用パフォーマンスの低下やリスク増大を招きます。本研究は、 資産価格のジャンプ（不連続な価格変動）が同時に発生する資産の集合をグラフとして表現 し、そのグラフ構造と直近の関係性の差異から、資産間の関係を変化させるようなイベント（サプライズ）を早期に検知する手法を提案しています。 ジャンプ 資産価格の ジャンプ （突発的な急騰・急落）は、市場に大きな影響を与えるイベントやサプライズなニュースで生じる可能性が高いと言われています。そこで以下の手順でジャンプを検知します。 Lee and Mykland (2008) の手法を用いて、5分足データから価格変動率が異常に大きい箇所を非パラメトリックに判定。 有意水準を非常に厳しく設定（例: 0.01%）することで、明確なイベントに起因する大きなジャンプのみを抽出。 検出されたジャンプには正（上昇）・負（下落）の方向が付与される。 グラフ分析と領域間相互作用 - 直近120日間の日次リターンに基づき主成分分析を行い、主成分の符号（プラス／マイナス）が同じ資産同士を一つの“領域”として区分。 - ある5分間隔で複数の資産が同時にジャンプし、なおかつジャンプ方向が同じ資産同士をエッジで結んだグラフを構築。 - グラフが上記“領域”をまたいで接続が生じているほど、直近の相関構造（資産関係）とは異なる反応と見做し、 領域間相互作用（Inter-domain linkage） という指標で定量化。 - この指標が高いほど「既存の関係性から逸脱した同時ジャンプ」が起きたと判断し、資産間関係に影響を与えるイベントが発生した可能性が高いとみなす。 検出したイベントの影響評価 - 直近120日の日次リターンで推定した共分散行列が、イベント検知後どれくらい変化するか（平均二乗誤差・対数尤度など）を観察。 - また、共分散行列を用いたリスクベース戦略（最小分散ポートフォリオ、リスクパリティなど）を組んだ場合、イベント後のパフォーマンスがどの程度悪化するかを統計的に検証。 データと設定 - 対象資産: 為替（ドル円・ユーロドル）、主要先物（米・独・日国債、米・欧・日株価指数、金、原油）計10種類。 - 5分足の気配値データ（約20年分）に対してLee & Mykland手法でジャンプを検出し、日次リターンを使って共分散行列を推定。 イベント検知 - ジャンプのうち、 領域間相互作用 が高いケース（既存の資産関係と異なる反応を示すジャンプ）が確認された。 - 実際にそうしたジャンプが検知された時刻を調べると、 米国金融当局（FRB、FOMC）や主要経済指標の発表 、または日銀やECBの政策発表など、マーケットに大きな影響を与えるイベントが多く対応。 - 逆に領域間相互作用が0に近いジャンプは、既存の相関構造に沿った動き（例: 通常のリスクオフで株と原油が下落し、債券が上昇など）に留まるケースが多い。 共分散行列とリスクベース戦略への影響 - 領域間相互作用が高いジャンプ発生後の10〜20営業日において、過去の推定共分散行列との乖離が大きく、また対数尤度が低下している（= 共分散行列が急変している）傾向を確認。 - 同期間中に、最小分散ポートフォリオ（MV）などリスクベース戦略の平均リターンが有意に低下しており、これらのイベントが資産の関係性を変え、運用パフォーマンスを悪化させるリスクを早期に示唆している。 考察 - 大枠の知見 : 領域間相互作用の高い同時ジャンプは、既存の資産相関構造と異なる動きを示す可能性が高く、その後の相関変化とリスクベース戦略パフォーマンス低下に繋がり得る。 - 人間の運用判断との連携 : いつ・何が原因でこうしたジャンプが起きたかを時刻ベースで把握できるので、ファンドマネージャが定性情報を参照して、迅速なポートフォリオ見直しを検討する材料になる。 (17) アート資産の分散投資効果の実証分析 森田 梨加, 町田 奈津美 (慶應義塾大学/パリ政治学院), 山本 康介 (慶應義塾大学), 中川 慧 (野村アセット/大阪公立大学), 星野 崇宏 (慶應義塾大学/理研AIP) アート作品を「アート資産」としてとらえ、伝統的な金融資産（株式・債券・為替・コモディティなど）に組み入れることで得られるポートフォリオ分散効果を検証することを目的としています。これまでアート資産のポートフォリオ導入効果に関する研究は数多く行われていますが、アート資産特有の流動性リスクや、価格変動の非対称性・長期依存性などを同時に考慮した実証分析は限られています。 データ アート資産 - リピートセールス回帰法を用いて算出される ArtDAI 社の月次アート指数を採用。 - アートの流動性に注目し、流動性の高・中・低の3種類に区分したアート指数を用意（High Liquidity Art, Middle Liquidity Art, Low Liquidity Art）。 伝統的資産 - 株式：S&P500、日経225、EURO STOXX - 債券：米国10年債先物、ユーロ（ドイツ）10年債先物 - 為替：米ドル/ユーロ、米ドル/円 - コモディティ：WTI原油先物、金先物 - 期間：1998年11月〜2023年12月の月次データ 分析 (1) 各資産の月次対数収益率を用いて、まずベクトル自己回帰（VAR）モデルを推定。 (2) その残差系列に対して、非対称性や長期依存を考慮した多変量GARCHモデル（GJR-GARCHやFIGARCHと、DCCもしくはADCCを組み合わせた合計6種類）を比較し、AICやSBCなどの情報量基準が最良となる「最適モデル」を選択。 (3) ボラティリティ（変動）どうしの連動を示す「ボラティリティ波及効果」や「条件付きクロス効果」を推定。 (4) 見積もった共分散行列を用いて、ポートフォリオの最適ウェイトとヘッジ比率を算出し、アート資産の分散投資効果を評価。 結果 1. ボラティリティ波及効果・長期依存 - 低流動性アート指数において、他資産からのボラティリティの影響が大きく（正の波及効果が統計的に有意）、アート価格変動が外部ショックを受けやすいことが示唆された。 - 一方、アート資産自体のボラティリティは長期的に持続しやすい（FIGARCHモデルの係数が有意に正）。アート価格の変動が一度高まると、比較的長い期間にわたってその影響が続く特徴が確認された。 資産間の動的相関（条件付きクロス効果） 「全体」「高流動性」「低流動性」のアート指数はいずれも、DCC/ADCCモデルの推定結果でプラスの条件付きクロス効果が確認された。これは市場ショックが発生した場合、アートと他資産の相関が一定程度上昇・変動しやすいことを意味する。 ただし、相関の“非対称性”は今回のデータでは大きくは見られず（ADCCの非対称係数が有意でなかった）。 ポートフォリオ最適ウェイト・ヘッジ比率 いずれの流動性のアート指数を組み込んでも、WTI原油先物、日経225、EURO STOXXなどがアート資産との組み合わせにおいて高いウェイトが得られやすかった。これらを組み合わせることでリスク低減が期待できる可能性が示唆された。 一方、債券（米国債、ユーロ債）や米ドル/円といった資産は、アートとのポートフォリオ内での最適ウェイトが相対的に小さくなる傾向が見られ、アートとの相性は低いと考えられる。 ヘッジ比率の点では、S&P500や日経225、EURO STOXXをロングしている投資家がアートを一定量ショートする（あるいは逆の立場で保有する）ことで、リスク低減が見込める可能性が示された。 考察と意義 - 流動性の異なるアート指数を用いることで、低流動性アートほど市場ショックの影響を受けやすく、ボラティリティが高まると持続しやすいことが明確になった。 - それでも、株式やコモディティの一部とは比較的低い相関を保つため、アートを組み合わせることによる分散投資メリットを得られる可能性が示唆された。 - 一方、流動性リスクも大きいため、特に低流動性アートの組み入れには注意が必要であることが読み取れる。 テキストマイニング・LLMs(5件) (18) 金融テキストを対象とした強弱を捉えることができるセンチメントモデル開発のためのデータセット構築方法の検討および分析 高野 海斗 (野村アセット) 目的 - 資産運用業務ではニュースやレポートなど多くのテキスト情報を分析する必要がある。これを効率化するために、テキストから市場の「センチメント（ポジティブ・ネガティブなどの感情指標）」を抽出し、投資判断に活用する取り組みが進んでいる。 - 従来の研究では「ポジティブ／ネガティブ／ニュートラル」の三値分類が中心で、より細やかな「強弱を考慮した連続的な値」を出力するモデルや、それを評価するデータセットが不足している。 データセットの構築方法 景気ウォッチャー調査の先行きコメント - 内閣府が毎月実施する景気ウォッチャー調査の「景気の先行き」に対するコメント（2000年1月〜2024年12月）を対象とし、5段階評価が均等になるよう100件をサンプリング。 人手と大規模言語モデルを組み合わせて絶対評価（Pointwise）・相対評価（Listwise）の2種類のラベル付けを実施し、相関係数や誤差から分析した。その結果、 相対評価（Listwise）の方が一貫した強弱を捉えやすい ことや、 GPT4系モデルは人間の平均スコアと高い相関を示す一方、スコアの水準感がずれる場合もある ことが明らかになった。また「コメント内の時間軸の混在」や「ポジ・ネガ要因の併存」がアノテーションを複雑化することを示し、金融におけるセンチメント定義の難しさと、その定義を活用目的に即して厳密化する重要性を指摘している。 (19) 景気ウォッチャー調査のデータセット構築と物価センチメント分析 鈴木 雅弘 (東京大学/日興アセット), 坂地 泰紀 (北海道大学) 景気ウォッチャーのデータを作成した https://github.com/retarfi/economy-watchers-survey データ - 2000年1月〜2024年5月までの景気ウォッチャー調査結果（現状・先行き） - 必要な列（地域/業種など）を整形し、最終的に 現状約31万件・先行き約33万件 を構築。 - 毎月公開される最新データを取り込み、GitHub Actionsを使いPull Requestで差分を管理→人手確認後マージ→Hugging Face Hubに自動アップロード。 (20) 決算短信を用いた業種ごとの年間レポートの自動生成 竹下 蒼空, 酒井 浩之 (成蹊大学) 投資判断を行う上で、業種別に市況動向や業績の変遷を把握できるレポートは有用である。しかし企業数・業種数が膨大であり、手作業でレポートを作成するには大きなコストがかかる。 決算短信中に記載される「業績要因文」を業種ごとに分類し、これらの文をもとにChatGPT-4oを用いて 年別かつ業種別の自動レポート生成 を試みる。 データと抽出 - 対象データ: 2022年分の決算短信9,933件。 - 抽出: 既存の研究(酒井ら)の手法を用いて、決算短信から「業績の要因が記載されている文(業績要因文)」を抜き出し、合計49,605文を得る。 業績要因文について - 業種：日本標準産業分類(小分類530)を採用 - テキスト埋め込みモデル：OpenAIの「Text-embedding-3-small」(ベクトル次元1,536)を用いて、業績要因文および業種名をベクトル化し、意味的な類似度(コサイン類似度)を計算。 - 3種類の分類手法を比較 1. 階層型クラスタリングのみ - 業績要因文49,605文をクラスタ数530に分割(Ward法・ユークリッド距離)。 - 各クラスタの平均ベクトルと業種名の類似度により小分類業種を割り当て。重複する業種は統合し、最終的に139業種を生成。 階層型クラスタリング + 最近傍法の併用 業績要因文の中に「部門」「セグメント」など5種類の単語を含むもののみでクラスタリング。 それを除く文はクラスタの平均ベクトルとの類似度が最も高いところへ最近傍法で割り当て。 重複業種を統合後、最終的に131業種。 最近傍法のみ 小分類530業種の業種名それぞれをベクトル化し、各業績要因文が最も類似度の高い業種へ直接割り当て。 文数が少ない業種を中分類レベルに統合し、最終的に435業種を生成。 評価方法 : 3手法のいずれでも生成された共通業種のうち5業種をランダムに選び、分類結果(業績要因文→業種)を人手で正解/不正解判定。 業績要因分の結果 : いずれも約85〜90%前後の精度 考察：業種推定精度 どの分類手法もおおむね高い精度(0.85〜0.87)で業種を推定可能。 ただし業種の粒度を細かくすると、より適切な業種があり得るケースが発生するなど、厳密な正解づけが難しい。 考察：レポート生成の質 実際の決算短信中の業績要因文を取り込むため、「売上」や「需要」への具体的な言及が含まれやすく、記事に近い内容の文が生成される。 比較手法(業種名のみ)だとこうした具体的文言が出ないことも多く、結果的に類似度が下がる。 一方、ChatGPTへのプロンプト次第で内容が左右され、またChatGPT-4oが一部の入力文を無視する場合もあるなど、生成制御には課題が残る。 本研究の自動生成手法は、決算短信ベースでの詳細な業種別レポートを効率的に作成する手段として有望であることが示された。 (21) LLMを用いた情報系企業のESG評価についての一考察 島津 雛子 (青山学院大学), 濱崎 良介, 大塚 浩 (富士通), 飯島 泰裕 (青山学院大学) 企業の ESG（環境・社会・ガバナンス） への取組みが年々重要になり、欧州では2024年から「欧州サスティナビリティ報告基準（ESRS）」に基づく情報開示が始まっている。 日本でも財務・非財務情報を統合した報告書（統合報告書）の発行が進み、その「トップメッセージ（CEOメッセージ）」は企業の価値創造ストーリーやESGへの姿勢を簡潔に示す重要な部分とされる。 しかし、トップメッセージを定量的に評価する手法はまだ確立されていない。本研究では LLM（大規模言語モデル） を用いて定量的かつ容易にESG評価する手法を探る。 ChatGPTの「MyGPT」機能を利用 - 専門的なLLMやプログラミング知識を要しない形で、ESGに特化したLLMを準備し、企業のESG分析を行う。 評価対象 : 情報系日本企業の10年分の統合報告書トップメッセージ（2013〜2024年） 評価方法 : - トップメッセージを E(環境) , S(社会) , G(ガバナンス) , O(その他) の4カテゴリに分類し、どのカテゴリの言及が多いかを可視化。 - ESGのフレームワークとして、 GRIスタンダード や ESRS基準 をChatGPTに知識として与え、「企業情報」と「ESG知識」の2つのデータベースを作成。 - トップメッセージ中の各文を4つのカテゴリに自動分類し、その正確性と企業のESG姿勢の変遷を分析。 1年分（2023年）のテスト - ChatGPTの分類結果と人手で付与したラベルを突合したところ、一致率は約98.2%と高い精度を示した。 - キーワード単純照合ではなく文脈からE/S/G/Oを判断していることが確認され、有用性が示唆された。 10年分の分析（2013〜2024年） - トップメッセージ各年の文章を分類し、ESG言及数の推移を可視化。 - 分析対象企業の特徴 - 年ごとのESG言及割合は一定の増加ではなく、経営体制の刷新やサステナビリティ戦略の導入タイミングで上下。 - 社会（S）への言及が他のE・Gより際立って多い。これは人的資本経営や社会的課題への積極的対応を示唆し、近年のトレンドを取り込みやすい企業と推察される。 - 一方で環境（E）への言及は少なく、同社が環境対応についてあまり言及・公表していない可能性が示唆される。 考察と意義 - 従来研究ではBERTやRAG等のLLMモデルをプログラミング込みで扱う事例が多かったが、本研究ではChatGPTのGUI機能とプロンプト設計のみで企業のESG言及を高精度に分類できることを実証。 - 投資家や企業関係者などが プログラミング不要 で簡便にESG評価に活用できる可能性を示した。 (22) LLMによる大量保有報告書における担保契約等重要な契約に関する情報の構造化 高橋 明久, 戸辺 義人 (青山学院大学) 「5％ルール」によって上場企業の発行済株式を5％以上保有した個人・法人は、取得から5営業日以内に大量保有報告書を提出する義務がある。 報告書には、保有株式数や取得目的、担保契約などの重要な契約情報が記載されるが、自由記述形式のため機械的な情報抽出が困難。 課題 : 多種多様な自然言語記述で記載される「担保契約等重要な契約」を自動的に抽出・分類し、構造化する手法が求められている。 目的 : 最新の自然言語処理技術（BERTやLLM）を用いて、大量保有報告書の自由記述欄から契約種別や契約内容を抽出し、構造化するための基礎的アプローチを確立する。 データ : 2023年1月〜12月にEDINETで公開された大量保有報告書990件から取得。 担保契約等重要な契約の記載がある778件を対象にし、そこに含まれる複数の契約文章を分割・整形して 合計1298文 の契約データを整備。 ラベル付け ：契約種別の分類（貸借契約、担保契約、その他契約）、契約内容の抽出（契約相手方、契約株数、開始日、終了日）。すべて人手でアノテーションし、学習・評価データを作成。 契約種別の分類タスク - 東北大学の日本語BERTをベースにfine-tuning。3クラス（貸借/担保/その他）分類のクロスエントロピー学習を実施。 契約情報の抽出タスク（QA形式） - 「契約相手は？」「開始日はいつ？」「株数は？」などの質問形式を設定し、BERTの質問応答モデルを構築（SQuAD類似の枠組み）。 - 各質問に対し、文章内の該当箇所を抽出（開始位置・終了位置を予測）。 加えて、OpenAIのGPT-4oを使用し、上記の分類タスクを行うことも試した。 BERT および GPT-4o のいずれも、貸借契約/担保契約/その他契約の3クラス分類で Accuracy=100% の結果。 情報抽出タスク - 評価指標: QAタスクで一般的なExact Match(EM)とF1スコアを採用。 - BERTのQAモデル：項目によりばらつきが大きく、「契約相手方」抽出でEM=0.16と低調、「契約終了日」ではEM=0.62。F1スコアでも最大0.62程度に留まる。 - LLM(GPT-4o)：全項目(契約相手方,株数,開始日,終了日)で EM=0.82〜0.92 と非常に高い。表記ゆれや文章構造の違いにも柔軟に対応し、高いスコアを達成。 機械学習1(5件) (23) 多様なテンプレートと合成データを用いた大規模言語モデルの業種区分予測における知識抽出 矢野 一樹 (東北大学), 平野 正徳, 今城 健太郎 (PFN) 金融業界ではLLMを活用したデータ分析や業務効率化が進んでいるが、日本特有の金融知識（例：JPXの業種区分）を適切に活用できるかが課題。 業種区分（JPXの33業種分類）は投資判断やポートフォリオ構築に重要な指標であり、LLMが適切に学習・活用できるかが問われる。 一般的なLLMは業種区分の知識を十分に学習・活用できていない（金融特化LLMであっても予測精度が低い）。 ファインチューニング（微調整）による知識抽出の最適な方法が未確立。 既存研究では知識を多様な表現で学習させることで精度向上が可能とされるが、最適なデータセット設計についての体系的な検証が不足。 目的 - LLMが持つ金融知識（特に業種区分）をより適切に抽出・活用するためのファインチューニング手法を探る。 - テンプレートを用いた多様な表現とルールベースおよびLLMによる合成データを活用し、業種区分予測精度を向上させる。 - パープレキシティと予測精度の関係を明らかにし、効果的なデータセット設計の指針を提供。 (24) 機械学習による企業業種分類の定量評価と応用 屋嘉比 潔 (大阪公立大学), 中川 慧 (野村アセット/大阪公立大学) 東証33業種分類やGICS（Global Industry Classification Standard）などの従来の業種分類は、企業の多角化、M&A増加、新興産業の誕生に伴い正確性が低下するという課題を抱えている。 Gradient Boosting Machine（GBM）を用いた機械学習モデルで、新しい業種分類を提案。 従来の業種分類と比較し、企業間の類似性をより正確に評価できるか検証。 機械学習ベースの業種分類が投資戦略（会計発生高アノマリー戦略）に応用可能かを評価。 データセット - 2001年～2018年の日本の上場企業データ（NEEDS-FinancialQUEST）。 - 特徴量: 財務指標（売上高、ROA、研究開発費比率、営業利益率、総資産回転率など）、市場データ（β、時価総額、株価変動率など） 目的変数 : 時価簿価比率（market-to-book ratio）を対数変換したものを用いる。 GBM（Gradient Boosting Machine）を利用し、企業間の類似度を学習。業種コードを基準とせず、財務・市場データをもとに動的に企業間の類似性を算出。 RMSE（Root Mean Squared Error）を用いて予測精度を測定。 (25) 機械学習を用いたクロスセクション予測における株価および業績シグナルの比較分析 小田 直輝 (慶應義塾大学), 中川 慧 (野村アセット/大阪公立大学), 星野 崇宏 (慶應義塾大学/理研AIP) 株式市場ではクロスセクション予測（複数銘柄のリターンを同時に予測する手法）が広く用いられるが、従来の手法ではリターンの非線形な変動や相互作用を十分に捉えられない。 従来の研究では、将来の株価リターンの相対順位をラベルとする「株価シグナル」が主に利用されてきたが、決算期には企業の業績情報が集中して開示され、市場の変動が大きくなるため、「 業績シグナル（企業業績や成長率の相対順位） 」が重要となる可能性がある。 株価シグナル ：将来の株価リターンの相対順位をラベルとする（過去リターンを正規化）。 業績シグナル ：次期の企業業績（売上高、営業利益、経常利益、純利益）およびその成長率の相対順位をラベルとする。 結論 - 業績シグナル単体は株価シグナルには劣るが、リスク抑制に有効 - 決算期以外では株価シグナルの方が優れた予測精度を示す - 決算期には株価シグナルと業績シグナルを組み合わせることで、予測精度が向上 - 最適な業績シグナルは「純利益」であり、特にリッジ回帰（RR）モデルで高パフォーマンスを示す (26) Multi-step Utility Lossを用いた深層学習モデルよる動的ポートフォリオ最適化 久保 健治 (東京大学/松尾研究所), 中川 慧 (野村アセット/大阪公立大学) ポートフォリオ最適化と機械学習の応用 - ポートフォリオ最適化は金融分野で重要な課題であり、従来の線形モデル（CAPMやマルチファクターモデル）では市場の非線形な特性を十分に捉えられない。 課題 - 既存の手法は「銘柄間の相関構造（クロスセクション）」と「時間方向の変動（時系列）」を別々に扱っており、両方を同時に考慮する手法は発展途上。 - 多くのポートフォリオ最適化手法は取引コストを考慮していないため、実際の運用環境ではパフォーマンスが劣化する可能性がある。 目的 - 取引コストを考慮した新たな損失関数「Multi-step CARA型損失関数（MS-CARA Loss）」を提案 - 時系列方向とクロスセクション方向を同時に考慮する「Dual Attention」モデルを導入 - S&P 500のデータを用いた実証分析で、従来手法よりも有効なポートフォリオ最適化が可能か検証 (27) ボラティリティ推定機能を持つ条件付き拡散モデルによる金融時系列生成 吉田 凌也 (東京大学), 平野 正徳, 今城 健太郎 (PFN) 金融市場の取引戦略の評価には金融時系列データが必要不可欠だが、過去のデータのみでは、未来の様々な市場環境を想定した戦略評価が難しい。そこで、シミュレーションデータを用いた戦略評価の重要性が高まっている。 これまでの金融時系列生成には主にGAN（Generative Adversarial Networks）が用いられてきた。近年は、拡散モデル（Diffusion Model）がGANよりも安定した学習と高品質なデータ生成を実現し、金融時系列の生成にも活用されている。 金融時系列の生成とボラティリティの推定を同時に行う条件付き拡散モデルを提案。 機械学習2(5件) (28) ベイズ推定における事前分布の作成にChatGPTを用いた暴落時の日経平均株価の予測 石井 成來, 堀田 大貴 (茨城大学) リーマンショック（2008年）やコロナショック（2020年）などのように、金融市場では大きな下落（暴落）が突発的に発生することがある。これらの暴落下での株価予測は、投資家のリスク管理およびリターン最大化において非常に重要である。 ChatGPTを利用してガウス過程回帰における事前分布を構築し、暴落時の日経平均株価を予測する新たなデータ分析の枠組みを提案する。 2024年の「植田ショック」を事例として、事前分布の生成やベイズ推定を行い、予測精度を検証する。 データ - 植田ショック（2024年8月）の日経平均株価 - 2024年7月31日の金利引き上げ発表後、市場が急落（3営業日で約20%下落）。 - 予測対象期間：2024年8月2日15:00～8月5日14:00（1時間足の終値）。 (29) 深層生成モデルによる金融市場の注文板の生成 高橋 友則 (総合研究大学院大学), 水野 貴之 (国立情報学研究所) 研究背景 株式市場など金融市場の構造を再現するシミュレーション手法として、高頻度取引データから「実際らしい」注文情報を生成できるモデルが注目されている。 従来は価格時系列データ自体の生成（GANなど）や、注文発生を表す点過程モデル（Hawkes過程）などが研究されてきたが、より直接的に「注文板全体を構成する注文の流れ（時系列）」を生成する方法の需要が高まっている。 モデルの概要 著者らは注文情報（新規or取消、売or買、注文形式、指値価格、数量）を文字列化（トークン化）し、自己回帰型言語モデルとして扱う手法を提案。 具体的には、 Transformer ベースの GPT アーキテクチャ 状態空間モデル (SSM) を応用した MAMBA アーキテクチャ この2種類をそれぞれスクラッチから学習した。 トークン化には、平仮名・片仮名・アルファベットの文字を組み合わせる独自の方式を用いている。これにより、整数値（指値価格・数量）とカテゴリ（新規/取消など）をまとめて「文字列」として符号化している。 データと実験 学習データとしては、2021年1月の東京証券取引所のトヨタ自動車株（銘柄コード7203）前場（9:00～11:30）のザラバに発生した注文情報を使用。 ザラバ中の売買・新規/取消・指値価格・数量などを連続するトークン系列とみなし、GPTとMAMBAを訓練。 生成結果として、実際の注文推移と類似した連続的な「売買注文の流れ」が再現可能であることを示している。 (30) 機械学習モデルを用いたシミュレーション分析：地方債市場における会計情報の寄与 原口 健太郎, 丹波 靖博 (西南学院大学), 池田 大輔, 阿部 修司, 大石 桂一 (九州大学) 日本の地方債市場を事例として、会計情報が債券金利（対東京都債のスプレッド）にどのような影響を与えているかを、機械学習モデルおよびシミュレーション的手法を用いて分析した研究です。従来の回帰分析（OLS）が非線形関係を捉えにくく、また機械学習モデル単独では「他の説明変数を固定してテスト変数を変動させる」分析が困難であるという課題を踏まえ、 仮想グリッドデータ と SHAP を組み合わせる新たなフレームワークを提案ています。 機械学習モデル（XGBoost）を訓練したうえで、そのモデルに仮想グリッドデータを入力することで、「一部の説明変数（テスト変数）だけを段階的に変化させ、他の説明変数（コントロール変数）を固定する」シミュレーションを可能にする手法を提案。さらに、モデルの解釈にはSHAPを用いることで、予測に対する各変数の寄与度合いを可視化する。 結果と考察 - 本研究では、「機械学習モデルで学習→仮想グリッドデータでシミュレート→SHAP で解釈」という枠組みを提案し、日本の地方債市場における会計情報の非線形かつ強力な寄与を実証した。 - 暗黙の政府保証があるとされる地方債であっても、財政状態の悪化は金利上昇に結びつくことを示唆しており、投資家が「クレジットリスク」をある程度織り込んでいる可能性がうかがえる。 - この枠組みは会計・ファイナンス以外でも「定式化が難しいが非線形関係が疑われる」現象分析に広く応用できる。機械学習モデルの評価・精度検証の際には、試行回数を増やし、平均収束を確認する手順が重要である。 (31) KANベース自己符号化器を用いた国債イールドカーブのファクターモデルの構築 水門 善之 (野村證券/東京大学), 米田 亮介 (野村證券) 国債イールドカーブを表す三因子モデル（レベル・スロープ・カーヴァチャー）を、自動符号化器（オートエンコーダ）の枠組みで構築し、さらにその中核モデルとして Kolmogorov-Arnold Network (KAN) を活用する手法を提案しています。 国債イールドカーブ: 短期から超長期までの国債利回りを連続的につないだもの。マクロ経済や需給要因などが複合的に影響し、日々変動する。 三因子モデル: イールドカーブは大きく「水準（レベル）」「傾き（スロープ）」「曲率（カーヴァチャー）」の3種類の因子（ファクター）によって概要を捉えられるという考え方が広く知られている（例：Nelson-Siegelモデル）。 Kolmogorov-Arnold表現定理: 多変数の連続関数を一変数関数の重ね合わせで表現できるという定理。KAN は、この重ね合わせを多層化して表現力を高めたネットワーク構造。 自己符号化器構造 - 入力層: 2, 5, 7, 10, 15, 20年など主要年限の国債利回り（週次データ）。 - 中間層: 3ノード（圧縮表現によりイールドカーブを3次元空間に写像）。 - 出力層: 元のイールドカーブ（入力と同じ次元）。 - 学習データ: 1992年7月～2024年12月までの週次国債利回り。 三因子との対応 - 学習を終えた中間層の3ノードを時系列で可視化すると、それぞれ「水準（2年債利回りに近い動き）」「傾き（長短金利差に近い動き）」「曲率（バタフライスプレッド等に対応）」を表していることがわかる。 - 従来のニューラルネットワークによる自己符号化器でも同様の結果が得られるが、KAN を使うことで中間層のノードを計算する関数の構造を可視化し、その解釈をより直接的に確認できる。 KAN固有の利点: 関数形の解釈 - KAN は「入力層 → 中間層」「中間層 → 出力層」を結ぶ近似関数をスプラインなどで明示的に定義する。 - 実際に得られた関数形を調べると、水準ノードは全年限の金利とほぼ比例関係、傾きノードは短期と長期で符号が反転、曲率ノードは中期と超長期に対して反転、といった形が確認できる。 - これらのパターンが「実際のイールドカーブにおける水準・傾き・曲率の変曲点」と整合しており、モデルの解釈性を高める。 まとめ 提案手法の有効性 KAN を自己符号化器として用いることで、日本国債イールドカーブの動きを自動的に3ファクター（レベル・スロープ・カーヴァチャー）に分解できる。 従来のオートエンコーダでも同様の因子抽出は可能であったが、KAN の「関数形状を直接確認できる」という特長により、学習後の解釈がさらに明確になる。 今後の応用可能性 イールドカーブだけでなく、他の金融時系列や複数の説明変数をもつ現象に対しても、「KANベース自己符号化器を使ってファクターを抽出し、そのファクターと入力との関数関係を可視化する」手法が適用できる可能性がある。 (32) 有価証券報告書と統合報告書を活用したESG投資のためのオントロジー構築と生成AIによる情報抽出 大堀遼介 (ulusage) 企業が開示するサステナビリティ関連情報（有価証券報告書、統合報告書、ニュース記事など）をもとに、環境・社会・ガバナンス（ESG）に関わる情報を一元的に活用するためのナレッジグラフと質問応答（QA）システムの構築手法を提案しています。 有価証券報告書や統合報告書などに分散するESG関連情報をナレッジグラフとして統合し、さらにGNN・LLMを活用して知識補完とQAを高度化する方法論を示しました。構築されたGraphRAGシステムにより、ESG投資のための情報を一貫して検索・推論し、根拠の明確な回答を提供できる基盤技術が確立されつつあるといえます。 雑感 上記の通り、テキスト情報の扱いが増加しています。LLMの出現以降、その流れが加速しているように思います。 この研究会の歴史をまとめた発表もありましたが、規模が大きくなり2日間の開催が定着してきましたね。注目度がより高まっていることがわかります。

Insight Edgeのデータサイエンティストの山科です。 今回はタイトルにもある通り、画像に対する異常検知結果を大規模言語モデル(LLM)で解説させることで説明性を付与できるか検証を行いましたので、その結果について記載したいと思います。 なお、本内容は先日、長崎で開催された自然言語処理学会（NLP2025）でも発表した内容（ 自然言語での異常解釈:LLMを用いたAI説明モデルの提案 ）となっています。 目次 はじめに なぜ異常検知タスクで説明性が必要なのか 提案アプローチ 実験 まとめ はじめに 異常検知は製造業や医療分野で不可欠であり、迅速かつ正確な判断が求められていますが、その出力が抽象的で理解しづらいことがあります。そこで、画像処理アルゴリズムによって検知された異常をLLMを用いて自然言語で説明ことで、より解釈しやすくする新しいアプローチ、言語駆動型説明可能AI（Language-Driven Explainable AI）を提案し、異常検知結果の信頼性と透明性の向上を図ります。また、その出力が実業務に有用であるかも検証しました。 なぜ異常検知タスクで説明性が必要なのか 近年、深層学習技術の進展に伴い、画像認識における異常検知の精度は飛躍的に向上しています。特に製造業や医療分野において、製品の欠陥検出や病変の早期発見など、様々な応用が期待されています。しかし、異常は一般的に発生しにくい事象であるため、正常データに比べて異常データの収集に課題があります。また、異常のパターンは多様で明確に定義することが難しく、各異常は異なる特徴を持つため、一貫して検出するためのモデル設計も困難です。さらに、ラベリングが複雑で誤りが発生しやすく、アノテーションコストが高いことも課題となっています。このため、異常検知の精度向上に向けた多方面での研究が引き続き行われています。 また、既存の深層学習モデルはブラックボックスであることが多く、異常と判断した根拠を人間が理解することが困難なケースも見られます。このため、現場での実運用の場面では、検知結果を信じてプラントを停止すればよいのか、あるいは、大したことのない異常なのでそのまま流せばよいのか、といったように最終決定をする作業員が判断に迷うことがあります。このため、AIの判断に対する信頼性の担保や、さらなる性能向上のために、AIの意思決定プロセスを説明可能なものにする Explainable AI(XAI、説明可能なAI)技術 が注目されています。 しかし、XAIの手法で生成される説明が専門家でないと解釈が難しい場合や、説明が多すぎて重要な情報が埋もれたり、逆に詳細に欠けることがあります。これにより、適切な情報量のバランスを取ることが難しいという課題があります。 一方で、近年のLLMの発展はXAIの可能性を大幅に広げています。例えば、画像キャプション生成タスクのように、画像に対する異常検知結果をLLMの入力として説明文を生成することで、画像内の異常の理由を人間が理解しやすく自然な言葉で説明できます。さらには、異常検知結果が誤っていた場合にもその間違いを正すことで異常検知精度の向上が期待できます。また、異常の種類や発生箇所から発生要因をフィードバックすることで、異常検知後の作業の優先順位を指示することも期待できます。 提案アプローチ 説明性付与のアプローチとして、画像に対する異常検知結果を LLM へのインプットとすることで説明性を付与する言語駆動型説明可能 AI(Language-Driven XAI)を提案します。 異常検知モデルとしては、例えば、多クラス分類やセグメンテーション、物体検知モデルなどを想定しています。 提案アプローチ 実験 実験設定 データセットとして、産業用異常検出のベンチマークとしてよく評価されているMVTec ADを用いました。 MVTec AD は、合計5354枚の15のクラスの画像で構成されており、各クラスは特定の製品に対してさまざまな欠陥タイプを持つ異常データとなっています。今回は、テストデータである1725枚を対象に評価しました。 異常検知モデルとしては、正常か異常かの二値分類、欠けや印刷ミスといった複数の異常の種類を分類する多クラス分類、画像内の異常箇所をピクセルレベルで評価しヒートマップで表すセグメンテーション、画像内の異常箇所をバウンディングボックス(bbox)で示す物体検知、の4種類を適用して、これらの手法によるキャプション生成の結果を比較評価します。 今回検証に用いた各異常検知種法のモデルは以下の通り。なお、各パラメータに関しては、誤検知や検知漏れの結果に対しても評価するため、ある程度ランダムとしました。 異常検知モデル また、モデル毎に出力される結果も異なるので、モデル毎に下表の通り指示文（プロンプト）を調整しています。 また、LLMにはgpt-4o(OpenAI)を用いました。 モデル毎のプロンプト例 評価としては、LLMで生成された説明のキャプションの正確性、個数や位置、大きさ、形状などの詳細度、異常のバリエーションに対する柔軟性、を評価項目としました。キャプションの生成結果は定量的に評価する手法も提案されていますが、ここでは、設定した5段階の 評価スケールを用いて人間による定性的な評価としました。「正確性」と「詳細度」は一枚一枚採点し、その平均点を算出し、「柔軟性」は異常のバリエーションに対する評価となるので各手法での全結果を鑑みて採点することとしました。 実験結果 二値分類 まず、異常検知モデルとして二値分類モデルを用いた場合について示します。入力画像と異常検知結果、生成されたキャプション例は以下の通りです。亀裂と割目から異常であることを正確に説明できており、また、保存状態にも言及することができていますが、位置や傷の数などについての説明はなく詳細度はやや低い結果となりました。 二値分類モデル結果例 多クラス分類 次に多クラス分類モデルを用いいた場合の結果を示します。入力画像と異常検知結果、生成されたキャプションは次の通りです。 多クラス分類モデル結果例 異常の種類としてはsqueeze（へこみ）が正しいのですが、crack（割れ）と誤分類してしまったケースになります。しかし、生成されたキャプションでは、右側に凹みがあることを説明しており、誤判定である可能性があることを説明してくれています。また、「右側」や「オレンジ色の部分」といっ位置の情報も示されており詳細度が高く、ユーザーも理解がしやすく、検知精度向上へのフィードバックにも活用が期待できる結果を得られました。 セグメンテーション 次にセグメンテーションモデルについてです。セグメンテーションモデルへの入力画像と異常検知結果は次のようになりました。 セグメンテーションモデルの入出力 見えにくいですが赤枠の箇所に縦のほつれがありますが、セグメンテーション結果では、ほつれ付近の異常度が高くなっているものの左上と左下が特に異常度が高い結果となっています。LLMへの入力画像と生成されたキャプションを見ると、ほつれだけでなく色ムラや擦り傷の可能性についても言及できていますが、ヒートマップで元の画像が判断しにくくなっているためか、上から下にわたってほつれがあることまでは言及できませんでした。しかし、異常度が高い箇所以外にも言及できており詳細度は高い結果と言えます。 セグメンテーション結果例 物体検知 物体検知結果と生成したキャプションの例を示します。異常箇所2箇所のうち、1箇所を検知漏れしているのですが、キャプションではもう1箇所についても異常であることを言及してくれています。 検知できている異常箇所に対しては、テクスチャ、色、形の違いなど、様々な要因から異常の理由を詳述しており、検知漏れの箇所に関しても同様の要因から異常であることを言及しています。生成されたキャプションは異常の理由を多角的に説明できており、正確性と詳細度が高い結果となりました。 物体検知結果例 実験結果まとめ 他のクラスなど全テストデータに対して検証を行った評価結果は下表のとおりです。 評価結果 二値分類や多クラス分類では異常画像をそのまま入力としているため か、より詳細な説明をしやすく、また、誤検知や誤分類の際に訂正するようなキャプションを生成できるケースが多く見られました。異常の種類や発生要因についても言及できており、全体的に高い評価結果となっています。セグメンテーションでは、正しく検知できている場合は異常箇所の位置や個数なども詳述できているケースが多く得られました。しかし、ヒートマップを重ねているためか異常の種類について詳細に説明することが難しく、また、ヒートマップがあることによって検知漏れしている場合に検知漏れ箇所を言及できているケースも少なく、全体的にやや劣る結果となりました。物体検知では、異常箇所の位置や個数に関して言及するケースが多く、検知漏れしている場合でも異常箇所を指摘できていたりと、正確性、詳細度、柔軟性とも高いキャプションが生成されやすい結果がえられました。しかし、bboxによっては異常箇所と重なってしまい、異常の種類を間違えてしまったり、検知漏れしている場合に、bboxが無いのにあるような説明をしてしまったりと、プロンプトの改善などが必要なケースもいくつか確認できました。 しかしながら、いずれの異常検知手法においても正しく検知できている場合には正確性、詳細度 が高いキャプションが生成できており、誤検知や検知漏れしている場合にも訂正したり、保存や輸送状態に起因するなどと言った異常の発生した要因についても言及したりと、詳細かつユーザビリティが高いキャプションが生成でき、本アプローチの有効性を確認することができました。 まとめ 本記事では、画像に対する異常検知結果に説明性を付与するLanguage-Driven XAIを提案し、産業用異常検出のベンチマークとしてよく用いられているMVTecADを対象に評価を行いました。異常についての説明だけでなく、発生要因や誤検知時に訂正できることも確認でき、よりユーザビリティの高い検知システムに寄与できることを確認できました。今後は、以下についても引き続き検証を進めたいと思っています。 複数の異常検知結果を入力とすることでより安定性の高いキャプションの生成可否 マニュアルや事故事例集をRAGに活用して、作業工程へのフィードバックや、設備へのメンテナンスへのフィードバックの可否 実データを対象とした検証 参照 [1] 自然言語での異常解釈：LLMを用いたAI説明モデルの提案 https://www.anlp.jp/proceedings/annual_meeting/2025/pdf_dir/Q5-9.pdf [2] 私のブックマーク「機械学習における解釈性（Interpretability in Machine Learning）」 https://www.ai-gakkai.or.jp/resource/my-bookmark/my-bookmark_vol33-no3/ [3] The MVTec anomaly detection dataset https://www.mvtec.com/company/research/datasets/mvtec-ad

はじめに こんにちは、Insight Edgeの関です。今回は、2025年2月21日（金）に大手町で開催された、住友商事グループ（SBU/事業会社、コーポレート）向けのInsight Edge主催リアルイベントについてご紹介します。 はじめに イベント開催目的 イベントコンテンツ詳細 ノベルティ イベント開催結果 まとめ イベント開催目的 Insight Edge（以下、IE）のミッションである「技術の力で世界を“Re-Design”する」から、「Re:design」をキーワードとして、IEの技術力を体感していただくイベントを開催しました。今は、「デジタルでともにNo.1事業群へ」をテーマに、事例展示・体験ブースやトークセッションを実施。DX推進の具体的なイメージをアップデートするとともに、その実現に向けた武器の一つとして、IEの伴走事例や最新技術の動向、さらにはIEが提供する価値や魅力を持ち帰っていただくことを目的としました。 イベントコンテンツ詳細 イベントでは、大きく以下3つのコンテンツを企画・実施しました。 コンテンツ①「事例展示・体験ブース」 Insight Edgeが過去1年間に取り組んだ案件の中から、7つの事例をパネル展示でご紹介しました。また、一部の案件ではデモを通じて、実際に触れて体感していただく機会も設けました。 展示企業 事例タイトル メディア系 データ活用組織の立ち上げ・育成・実践 エネルギー系 電力需給管理システム開発を通じた包括的支援 弊社 事業改善のタネを発見する！顧客の声・従業員の声分析ツール【 Voiceek 】 小売販売系 AIを活用した値引システムの開発 通信系 自律的にデータサイエンスタスクを遂行するマルチAIエージェント開発 介護系 デザインで介護事業に新たな価値を 投資系 生成AIを活用した投融資意思決定支援ツールの開発 コンテンツ②「トークセッション」 弊社CEO小坂らで住友商事グループのDXについて語るオープニングセッションを皮切りに、4つのトークセッションを実施しました。プロジェクト実担当者とのパネルディスカッションや、弊社データサイエンティストによる生成AI情報トレンドセミナーを実施しました。 キーワード 概要 住友商事グループのデジタル 本イベント開催にあたってのご挨拶と、住友商事グループのデジタルによるさらなる成長に向けたKeynoteセッションをお届け。 生成AI最新動向 現在の生成AIの流行に惑わされることなく、AIエージェントの背景を正しく理解し、情報を適切に評価するための基礎知識をご提供。 デザインと事業開発 UI/UXデザインが介護における事業開発のスピードを大きく加速させた事例を紹介。総合商社におけるデザインの新たな可能性を探った。 データ活用の全社推進 メディア系の事業会社におけるデータ活用のプロジェクトの全体像とその成果を紹介。コアメンバーが登壇しパネルディスカッションを通しデータ活用の最前線をお届け。 自律型AIエージェント データサイエンスタスクを自律的に遂行するAIエージェントの開発プロジェクトの詳細とその成果を紹介。最新の技術トレンドやAIエージェント活用に向けたヒントをお届け。 コンテンツ③「懇親会」 今回のイベントでは、事例展示会場にて懇親会も開催しました。参加者の皆さまには、展示事例を見ながらフランクに会話を楽しみつつ、DX推進の取り組みに関する情報交換の場としてご活用いただきました。また、定時中にご都合がつかない方にも参加いただける貴重な機会となりました。 ノベルティ Insight Edgeのロゴやイベントキービジュアルをあしらったノベルティ（トートバッグ、スクリーナークロス）も配布しました。 イベント開催結果 イベント当日は、延べ257名の方にご来場いただきました。事例展示では、「デモを見ながらの説明が分かりやすかった」「活用できるユースケースを持ち帰れた」といった声が寄せられました。 また、トークセッションでは、「事例を詳しく知ることができた」「AIの知識がなくても理解しやすかった」と好評をいただきました。 さらに、懇親会では「IE社員との交流を通じて、技術力だけでなく、人柄や仕事への情熱も伝わった」との感想も寄せられました。 まとめ 今回の記事では、Insight Edge主催のリアルイベント 「Insight Edge Re:design 2025 〜デジタルでともにNo.1事業群へ〜」 についてご紹介しました。IEでは「みんなでやる」というバリューを大切にしており、準備段階からイベント当日まで、その精神を体現できる場となったと感じています。 IEの提供する技術にご興味のある方、またはIEでの働き方に関心をお持ちの方は、ぜひお気軽にご連絡ください。 最後までお読みいただきありがとうございました。

はじめに こんにちは。２０２３年１２月からInsight Edgeに参画したData Scientistのカイオと申します。 入社してから幅広い分野のAIや機械学習だけでなく、API構築やクラウドと関わり海外出張までする機会があって非常に感謝しています。 最近、LLMを使ってPPTXを生成する案件に携わり得た知識を共有しようと思ってこの記事を書きました。 目次 PPTXファイルの構成 PythonによるPPTXライブラリ(python-pptx) わかった課題 まとめ PPTXファイルの構成 皆様ご存知だと思いますが、PowerPointが世界一使われている発表資料です。OpenOffice等のオープンソースアプリも存在しますが人気度がそこまで高くありません。 PowerPointは２００７においてPPTからPPTXフォーマットに変わってその中身の仕様は大きく変わりました。中身は非常に複雑なため短いブログに書き切れません。そのため、今回はスライドレイアウトとプレースホルダーにフォーカスします。 PythonによるPPTXライブラリ(python-pptx) Pythonを使ってPPTXを操作したいならpython-pptx一択です（内部のXMLを直接いじるのもできるがおすすめできません）。 PPTXの使える機能は一部しかできませんが結構パワフルなツールです。 もちろん新規ファイルの作成だけでなく、既存のファイルを開いたり編集できたりします。 ただ、もっと複雑な処理（スライドのコピー等）はpywin32でしかできなくて環境がWindowsに限られる場合があります。 わかった課題 １：スライドレイアウト 普段あまり触ることはないかもしれませんが、PPTX発表に少なくとも１つのスライドマスターが存在します。 マスタースライド デフォルトではスライドマスターに11枚のスライドレイアウトが存在します。 １つのスライドレイアウトに複数のプレースホルダーがあってそれぞれ番号が振ってあります。以下は「Two Content」レイアウトの一例です： Two contentプレースホルダー プログラムで自動的に書き込む場合、次の課題があります。 どのプレースホルダーが左でどれが右か番号でのみわからない。 「真ん中の左のプレースホルダーに書き込んでください」のような指定ができない。 更に、ユーザや会社によってスライドレイアウトを編集したい場合があります。試しにプレースホルダーを２つ追加してみましょう： Two content編集後 気づきましたか？右と左が逆になりました。 それは私が最初に右側のプレースホルダーを作ったからです。 更に、右のプレースホルダーを削除しても番号は変わりません。 他人が作ったスライドレイアウトは見た目が同じでも過程が違うとPythonのコードも違って非常に手間がかかります。 わかった課題：一番ご理解いただきたいのは、LLMはその配置情報を知っていないことです。カスタムのレイアウトでLLMの出力をそのまま利用すると分かりづらい発表になるかもしれません。 ２：日本語対応 今回、LLMで生成されたスライドを紹介しますが上記の課題もあってデフォルトのレイアウトに限ります。 任意の話題についてプレゼンファイルをこれから作ります。３つのステップで進めてみます： ユーザが入力したスライド枚数とテーマについてページごとの要約をLLMに依頼する def create_presentation_summary (user_theme: str , num_of_pages: int ) -> list [ str ]: system_prompt = f """You are an assistant for helping users create a PowerPoint presentation. Based on the theme on user input, return a summary of what each page of the slide should talk about. Therefore, your response should be a list of JSON strings. No matter what the user input is, the response should contain {num_of_pages} pages. You should write several sentences for each page. The language of your response should be the same as the user input. """ messages = [{ "role" : "system" , "content" : system_prompt}] messages.append({ "role" : "user" , "content" : user_theme}) スライド１枚の要約から適切なスライドレイアウトを選択する def get_appropriate_layout (summary_list: list [ str ]) -> list [ str ]: summary_list = json.dumps(summary_list, indent= 4 , ensure_ascii= False ) system_prompt = f """You are an assistant for helping users create a PowerPoint presentation. The user input will be a list of JSON strings, where each string represents a summary of each page of the slide. Based on the summaries, return a list of JSON strings, where each string represents the most appropriate layout for each page. The response should contain the same number of pages as the input. The language of your response should be the same as the user input. The layout options should be the ones available by default in PowerPoint. """ messages = [{ "role" : "system" , "content" : system_prompt}] messages.append({ "role" : "user" , "content" : summary_list}) スライドレイアウトと要約から箇条書きの中身をLLMが出力し、python-pptxを使って実際にPPTXファイルを作成する def get_placeholder_content (summary, layout): slide = prs.slides.add_slide(slide_layouts.get_by_name(layout)) num_of_placeholders = len (slide.shapes.placeholders) system_prompt = f """You are an assistant for helping users create a PowerPoint presentation. The user input will be a summary of the contents of a slide. The layout is {layout}. Based on the summary and layout, return the content that should be placed in each placeholder of the slide. The response should be a list of JSON strings, where each string represents the content of a placeholder. Each placeholder can have multiple paragraphs of text. Each paragraph should be separated by a newline character. There are {num_of_placeholders} placeholders in the slide layout. The first placeholder is the title placeholder. """ messages = [{ "role" : "system" , "content" : system_prompt}] messages.append({ "role" : "user" , "content" : summary}) response = openai_client.beta.chat.completions.parse(messages=messages, model=azure_deployment, n= 1 , temperature= 0 , response_format=StringList).choices[ 0 ].message.content response = json.loads(response)[ 'strings' ] for i, content in enumerate (response): for paragraph in content.split( " \n " ): p = slide.shapes.placeholders[i].text_frame.add_paragraph() p.text = paragraph 実行してみたらこんな結果になりました： 日本語フォント フォントサイズが大きすぎて大幅に枠を超えてしまいました。python-pptxにfit_text()関数があって、枠に入るように調整してくれるのですが日本語だとエラーになります。 色々頑張って調べましたがどうしても解決できなくてとりあえずフォントサイズを手動で小さくしてみました。 ところで英語のみだと以下のように上手くフォントサイズを調整してくれます： 英語フォント つまり、日本語対応がそこまで追いついていなくてLLMの出力には気をつけていただきたいのです。LLMに文字数や文章の長さを制限するのをお勧めします。 ３：フォーマット指定 翻訳前 今回は少し違うタスクをやってみましょう。デフォルトのレイアウトだけだと制限が多すぎるので入力した 任意 のPPTXファイルのテキストをLLMで翻訳して同じ配置で出力してみます。 固定のプレースホルダーだけでなく、後で追加されたTextBoxにも対応したいのでshapesを使う： for shape in prs.slides[ 0 ].shapes: if shape.has_text_frame is True : shape.text_frame.text = translate(shape.text_frame.text) 翻訳後 色やボルド情報はもちろん、フォントサイズまで勝手に変わりましたね。 実は、デフォルト以外の形式情報はrunという変数の中に格納されています。 １つのtext_frameに１つ上のparagraphがあり、１つのparagraphに複数のrunがあります。 異なるrun 翻訳や要約など、文脈が必要なタスクはLLMに依頼するとき以下の方法のどれかを選ばないといけない： フォント情報を諦めてデフォルトのままにする（難易度が低い） JSON化して、paragraph全体の情報を渡すのと同時にrun毎の情報も渡す（難易度が高い） 2を実装するとしたら以下のよう構造化して渡すといいです（あくまで一例）： [ { " text ": " a ", " color ": [ 255 , 0 , 0 ] , " bold ": true , " italic ": false , " underline ": false } , { " text ": " r ", " color ": [ 255 , 255 , 255 ] , " bold ": false , " italic ": true , " underline ": false } , { " text ": " t ", " color ": [ 0 , 0 , 255 ] , " bold ": false , " italic ": false , " underline ": true } ... ] そして、リスポンスを以下のように指定する： [ { " text ": " 人 ", " color ": [ 255 , 0 , 0 ] , " bold ": true , " italic ": false , " underline ": false } , { " text ": " 工 ", " color ": [ 255 , 255 , 255 ] , " bold ": false , " italic ": true , " underline ": false } ... ] もちろん、ChatGPTの構造化出力を使うと便利です。 しかし、複雑な処理になればなるほどLLMが細かいミスをする可能性が増えます。 まとめ このように、LLMを活用してパワポファイルの自動生成について述べました。PPTX形式は色々な制約があり、ある程度フォーマットにこだわりがなければLLMを上手く活用できます。 この記事に書いた内容はユーザがある程度形式をコントロールしたい想定です。python-pptxのコードまでLLMに生成させる方法も存在して こちら の記事は参考になります。

目次 はじめに PoCとアーキテクチャ PoCと本番システム開発の違い アーキテクチャとは PoCにおけるアーキテクチャ設計 品質(Quality)観点での検討 機能適合性 使用性 互換性 信頼性 セキュリティ 保守性 保守性:再利用性 保守性:解析性 保守性:修正性 保守性:試験性 保守性:モジュール性 性能効率性 移植性 品質特性に対するまとめ コスト(Cost)・納期(Delivery)も考えると 既存システムからの流用 共通機能の整備 まとめ はじめに こんにちは、Insight Edgeでエンジニアをしています伊藤です。 「これよくできているな」と言ってもらえるような設計・仕組みを目指して日々のエンジニアリングに取り組んでいます。 今回の記事では私の好物であるシステムアーキテクチャについてPoC(概念実証)の観点から考察してみたいと思います。 Insight Edgeは最先端技術をビジネスに活かすための技術者集団です。 そのため、プロジェクトではPoC(概念実証)としてプロトタイプを作成し、実際の現場・ユーザに試していただくことが多いです。 PoCをすることによって 想定しているテクノロジーの使い方で実際にビジネスを変えることができるか 役立てるために埋めなければいけないギャップは何か 適切にギャップをカバーすることで実際に使えるものができるか といった観点を確認し、最終的にどんなシステムを作るべきかについての学びを得た上で次のステップへと進みます。 本記事では、本番システムの開発とは異なるPoCならでは特性を品質面を中心に整理しつつ、アーキテクチャに求められる要素について考えてみたいと思います。 PoCとアーキテクチャ PoCと本番システム開発の違い PoCの実装もシステム開発の一種であるとはいえ、本番稼働するシステムの開発とは異なる面があるので簡単に整理しておきます。 下記はInsight Edgeでのケースですので、組織やプロジェクトによって状況は異なるでしょう。 PoC 本番システム開発 目的 どうすれば効果的なシステムになるかの学びを得る ビジネスに対して効果を出す 優先事項 早く検証しフィードバックを得る 費用対効果 利用期間 数週間〜数ヶ月 数年 運用する人 Insight Edge内のPoC開発メンバ 納入先の担当者 アーキテクチャとは アーキテクチャとは、あるシステム(広義のシステム=系)を ある観点 から見た場合の 構成要素 ・ 要素同士の関係 をモデル化して表現したものです。 本記事では、アプリ内やインフラ構成だけでなく、開発標準やルールといった開発プロセスも含んだ範囲をアーキテクチャとして扱っています。 PoCにおけるアーキテクチャ設計 ソフトウェアシステムのアーキテクチャを設計する目的についてはさまざまな捉え方がありますが、 今回はプロジェクトのQCD(Quality=品質、Cost=コスト、Delivery=納期)の観点から以下の位置づけとしておきます。 システム開発・運用・保守において、 Qualityの最大化、Costの最小化、Deliveryの迅速化を目的にアーキテクチャを定義すること PoC作成もシステム開発プロジェクトの一種ですので、QCDを考慮する必要があります。 PoCならではの考慮事項があるか、それはアーキテクチャを検討する際にどういった影響があるかをQuality面を中心に検討してみます。 品質(Quality)観点での検討 システムの製品品質についてはISO/IEC 25000シリーズ "SQuaRE" による定義がありますので、これをベースを検討します。 SQuaREの詳細についてはIPA(情報処理推進機構)の 「つながる世界のソフトウェア品質ガイド」 などを参照していただくとして、ここでは概要だけ紹介します。 ※IPA:「つながる世界のソフトウェア品質ガイド」より抜粋 それぞれの特性の内容は以下のようになります。 品質特性 説明 機能適合性 必要な機能を十分に、正しく提供できるか 性能効率性 システム側のリソースを効率よく使えているか 互換性 他システムと円滑に連携できるか 使用性 ユーザが容易に理解・操作できるか 信頼性 安定して動作し、障害から迅速に回復できるか セキュリティ 不正利用・情報漏洩の防止・追跡ができるか 保守性 変更や修正が容易に行えるか 移植性 異なる環境へ容易に適用・移行できるか それでは、それぞれの品質特性についてPoCの場合を掘り下げてみます。 説明の都合上、取り上げる順序は上記から入れ替えています。 機能適合性 要求された機能を十分に・正しく提供できるか、という観点での品質特性です。 以下の3つの副特性に分けて考えることができます。 副特性 説明 機能完全性 必要な機能が備わっているか 機能適切性 機能・プロセス・手順が無駄のないものになっているか 機能正確性 正確に処理・出力しているか PoCでは 機能完全性と機能適切性は、機能に過不足がないかという観点の副特性なので、 PoCでは必ずと言っていいほど検証の対象になります。 また機能正確性はPoCの目的により優先度が変わる副特性ですが、 Insight EdgeではLLMや数理モデルを用いたPoCが多いため 「実用上十分な精度を出せるか」という検証は優先度を高くすることが多いです。 しかし今述べた2点については本番システムの一部を切り出して検証しているだけで PoCだから求められる特性というわけではありません。 機能の面で考に、本番システムにはなくPoC開発時だけ求められるものとしては、 ユーザがどのような操作をしたかを後から確認できるようにする 操作後にテストユーザがフィードバックを入力できるようにする といったものが考えられます。 これらの機能が過不足なく備わっているかどうかが、PoC環境ならではの機能適合性といえるでしょう。 アーキテクチャへの影響 上記のPoC環境としての機能適合性を満たすため、アーキテクチャとしては UIフレームワークに操作トラッキングの仕組みを組み込んでおく WebAPIアクセス時のURLやパラメータを自動的に記録する 操作記録用のログストレージを通常のログとは別に用意する といった基盤機能の検討が必要になります。 使用性 ユーザが容易に理解・操作できるかという観点です。 PoCでは 使用性は機能適合性と並んで、PoCで頻繁に検証・フィードバックのポイントとなる観点です。 ただし使用性も「本番システムを設計する際の検討事項を一部抜き出し/先取りして検証する」という性質のものなので、PoC時のみに求められる要素は少ないと考えています。 PoC開発時には使用性分析のために、ユーザ操作やフィードバックを記録する機能が欲しくなると思いますが、それらの機能が備わっているかは、前項の機能適合性の観点に含まれます。 互換性 他システムと円滑に連携できるかという観点です。 PoCでは PoC用のシステムでは、本番システムで予定してる外部連携のうち、検証に必要な部分だけを実装しますが、 テストユーザが多い場合や組織内の権限情報を検証に使いたい場合は、PoC時のみ特定の認証基盤とのユーザアカウントの連携が必要になることがあります。 外部の認証基盤を利用する前提でも、開発者としては外部の認証基盤を使わずに、スタンドアロンでユーザ作成・権限設定・ログインができる仕組みを設けて、素早い動作確認等ができるようにしたくなると思います。 PoCの場合はそのようなバックドア的な仕組みを設けることが許容（というよりも推奨）されるという点も本番システム開発と異なる点です。 その際には、外部認証基盤とスタンドアロンの認証機能がお互い干渉せずに使えるか、も互換性という観点で検討すべき品質となります。 アーキテクチャへの影響 外部のアカウントをテストユーザとして利用する場合は、Microsoft Entra ID(旧 Azure Active Directory)やその他のOAuth2/Open ID Connect対応サービスとの連携を組み込む必要があります。 認証基盤を自前で実装することはほぼなく、クラウドサービス/SaaSを使うことになると思いますが、 前述の通り外部認証基盤とは別にスタンドアロンでのユーザ登録・権限操作をできる必要があり、 PoCシステムの認証基盤選定時には外部認証基盤連携とシステム内ユーザ管理の両方に対応しているかを考慮して検討することになります。 信頼性 安定して動作し、障害から迅速に回復できるかという観点です。 副特性として以下が含まれます。 副特性 説明 成熟性 テスト・もしくは使い込みにより、どの程度正常に動作すると言える状態になっているか 可用性 どの程度の時間、利用可能か 障害許容性 障害発生時にどの程度正常に動くか 回復性 中断もしくは故障時にユーザののぞむ状態に復元できる度合い PoCでは PoCでは作成したプロトタイプ自体に高い安定性が求められることは稀ですが、 検証中に入力したデータが障害によって失われてしまうと、そこまでの検証が無駄になってしまう可能性があるので、 データの回復性についてはある程度確保する必要があります。 言い換えると、PoCではRTO(目標復旧時間)に比べRPO(目標復旧時点)の優先度が高いということになります。 またPoCでは通常のシステムと使って操作の期間を指定できる場合もあり、保全すべきデータ断面が本番システムより限定的と言えます。 アーキテクチャへの影響 データ回復性の要件をアーキテクチャに反映しようとすると、 ユーザがPoCを操作する日時を指定できるのであれば適切なタイミングでバックアップを取る仕組みを検討することになります。 また指定できない場合は十分な頻度の自動バックアップをアーキテクチャに組み込む必要があります。 いずれの場合もクラウド上のDB/ストレージサービスであればある程度カバーされていることが多いので、 入力データの重要性・コストのバランスを考えて取得タイミング・バージョン数を追加設定することになるでしょう。 セキュリティ セキュリティ関連の品質の副特性としては以下が定義されています。 副特性 説明 機密性 アクセス権限に沿ったデータ開示ができているか インテグリティ システムが不正アクセス・改ざんを防止できるか 否認防止性 入力・操作が行われたことを後から証明できるか 責任追跡性 誰が行った操作であるか追跡できるか 真正性 人・メッセージ・サービス等が本物であることを証明できるか PoCでは PoCでは信頼できるユーザに限られた環境・期間で操作をしてもらうことが多く、その場合はセキュリティについては本番システム開発よりも要求レベルが低くなりますが、 個人情報や部外秘の情報を検証に用いる際には、機密性だけ本番相当の高いレベルを求められる可能性があります。 アーキテクチャへの影響 機密性を確保するためには、大まかに2点、PoC環境自体へのアクセス制御と、ユーザごとのアクセス範囲の管理がアーキテクチャ上の関心事となります。 PoC環境へのアクセス制御については前述のユーザ認証のほか、アクセス元IPアドレスによる制限などが考えられます。これは本番システム構築時に検討する内容と同様です。 PoC時点でユーザ権限別にデータ/機能を制限する必要がある場合は、PoC環境を複数作り同じ権限のユーザ群ごとに別環境を提供することも選択肢となります。 複雑な権限管理を実装せずに済むため、その分の労力を本当に検証したいことに充てることができます。 保守性 保守性は以下の副特性に分解されますが、それぞれPoCでのポイントが考えられるので、個別に検討していきたいと思います。 副特性 説明 再利用性 作ったシステム・構成要素が他の目的にも利用できるか 解析性 不具合の原因を特定しやすいか 変更性 コードを修正する際に不具合・機能低下のリスクを低く抑えられるか 試験性 システムのテストをしやすいか モジュール性 適切にモジュール化されているか 保守性:再利用性 作ったシステム・構成要素が他の目的にも利用できるか、という観点になります。 PoCでは PoCで開発するシステムの再利用性には2つの観点があります。 1つは、PoCで作った機能を本番向けシステムに持っていけるかという点です。 特に数理モデルを構築してのPoCなどは検証したロジックに変更を加えることなく本番システムに反映する必要があり、重要な品質特性となります。 もう1つは、他のPoCを実施する際に流用できるかという点です。 こちらは前者ほどシビアになる必要ありませんが、将来のPoC実施時のコスト低減・実装期間短縮に寄与します。 アーキテクチャへの影響 本番システムへの再利用性を確保するためには、ソフトウェア内のレイヤ分け・コードのディレクトリ分けなどを開発標準として整備し、再利用したいロジックがモジュールとして独立した状態にする必要があります。 Insight Edgeではデータサイエンティストとエンジニアの混成チームで取り組むことがありますが、 このような場合は、事前にメソッドの切り方や引数・戻り値まで定めておくことで、 お互いの作成するロジックに影響を与えることなくスムーズに分担できるようになります。 また、他のPoCで再利用できるようにするという観点では、PoCでよく使う機能・構造を部品やテンプレートとして用意しておくことが考えられます。 その際は、本記事でそれぞれの品質特性に対して検討した内容がテンプレートに取り込む要素の候補になるでしょう。 保守性:解析性 不具合の原因を特定しやすいか、という観点です。 PoCでは PoCでは予定していなかった操作・入力データに出会い、それを分析することが重要な要素です。 通常、使用状況の把握/不具合の調査に使える情報の量とログ保管容量/コストはトレードオフの関係になりますが、 PoCは本番システムに比べるとデータ量が少ないため、分析のトレーサビリティに振り切るという選択が可能です。 アーキテクチャへの影響 機能適合性についての検討でユーザ操作の記録をPoC環境の基盤機能として検討しましたが、不具合時の解析性ではリソース使用状況のメトリクスとログも重要な情報となります。 メトリクスについてはクラウドサービスを使っている場合はCPU/メモリ等のリソース使用状況を取得する設定ができると思いますので、PoCに合わせた設定値を検討して環境構築時に確実に適用できるよう管理しましょう。 ログについては効果的なログの取得タイミングが開発ガイドラインとして整備されていると良いでしょう。 またログのフォーマットとしては構造化ログを採用しましょう。主要なクラウドのログ管理サービスは構造化ログに対応していますので、適切にフィールドを使えば、多量のログの中からでも必要な情報を見つけやすくなります。 Insight Edgeではカスタムのログライブラリを作成し、ログの取り扱いの労力を減らしています。 保守性:修正性 コードを修正する際に不具合・機能低下のリスクを低く抑えられるかという観点です。 PoCでは PoCでは「フィードバックをもとに改修を加えて再度検証する」というサイクルを何回か実行することがあり、素早く安全に修正できることが求められるますが、本番システムも同様に素早く安全に修正できるべきなのでPoC開発だけの品質要件というわけではありません。 保守性:試験性 試験性はシステムのテストをしやすいかという観点です。 PoCでは PoCでは2つの面から試験性を捉えることができます。 1つは開発者が修正した内容を素早く確認でき、PoC環境へデプロイ可能な状態にもっていけるかという点です。 これはPoCに限らず本番システム開発でも求められる特性となります。 もう1つは、PoC自体が一種のテストなので 検証したい内容を正しく実施・検証できるようになっているかという点です。 検証に必要な機能が備わっているかという、機能適合性について検討することでカバーされます。 保守性:モジュール性 適切にモジュール化されているかという観点です。 PoCでは 適切なモジュール化はこれまで述べてきた保守性の全ての副特性に関わる要素です。 PoCごとにそれぞれの副特性の観点で検討することにより「適切なモジュール化」が決まります。 モジュール化を目的とするよりも、それによって達成したい特性からどのようなモジュール構造にするべきかを検討し、アーキテクチャへ反映する形となります。 性能効率性 システム側のリソースを効率的に使用できているかという観点です。 PoCでは PoC段階で検証の主役になることはあまりないでしょう。 移植性 移植性には下記が含まれます 副特性 説明 適応性 多様な環境をターゲットにしている場合に適用できるか 設置性 インストール・アンインストールのしやすさ 置換性 別の製品で置き換えられるか PoCでは PoCはそもそも本番に向けて細部・周辺を更新することを前提としているので、 完成品を他の環境に持っていけるかというでPoC開発時に検討する意味は薄いと考えられます。 品質特性に対するまとめ ここまでSQuaREで定義された製品品質ごとにPoC用システムで求められる要件・アーキテクチャについて考察してきました。 PoCという一時的な取り組みのためのシステム開発であっても、それぞれの製品品質の観点で検討することで、本番開発と異なる点を発見しアーキテクチャ設計時の考慮事項を言語化できたように思います。 コスト(Cost)・納期(Delivery)も考えると ここまで品質:Qualityの面で検討しましたが、PoCはプロジェクトとして実行されるので、当然コスト・納期も重要な要素となります。 上記の品質面で検討した内容と、コスト・納期のバランスを取るにはどのようなアーキテクチャ設計上の判断が可能でしょうか。 既存システムからの流用 1つには、チームメンバがよく知っているアーキテクチャパターンを採用、もしくはチームが管理している他のシステムから流用することが考えられます。 ここまで品質面から検討してきたアーキテクチャの要素と一致しない部分も出るためPoCとしての要件に対して最適ではない可能性もありますが、 短期間・検証目的というPoCの位置付けを考えると、品質の妥協によるデメリットよりもコスト・時間を省力できるメリットの方がインパクトが大きいと考えられます。 また品質に関しても、すでに理解が進んでいるインフラ・アプリ構成となることで 既存システムに関わるチームメンバにとっては 保守性が高い状態となりますので、トレードオフ検討時にはその点も考慮に入れる必要があります。 共通機能の整備 もう1つ、組織としてPoCを頻繁に行うならば、PoCに特化したアーキテクチャ部品を再利用可能な形で持っておくことが考えられます。 システム全体のアーキテクチャのうち、Dev(Sec)Opsにあたる部分、 CI/CDの仕組み 監視の仕組み モニタリングの仕組み などはPoCの内容が変わっても共通であることが多いです。 これらを意識的に再利用し適宜アップデートをして整えていくことで、 PoC時には検証したい機能・UI等の実装にリソースを集中できるようにすると良いでしょう。 まとめ 今回は各品質特性についての考察を中心にPoCならではの特性・アーキテクチャ設計時の考慮事項を検討してみました。 元々なんとなくプロトタイプの設計時に対応していたものも多いですが、 言語化したことで抜け漏れなく検討できるようになったように思います。 それぞれの企業、チーム、プロジェクトによって状況などは異なると思いますので、 アーキテクトの皆様の検討の枠組み・叩き台として参考になれば幸いです。

こんにちは、Insight Edgeでリードデータサイエンティストを務めている ヒメネス（Jiménez） です！ 前回の投稿 から丸1年経ちましたが、改めて皆さんと知識共有できればと思います。今回は、話題のOpen Source LLM（Llama, Mistral, DeepSeek等）をローカルで実行する方法を紹介します。 目次 LM Studioの紹介 LLMをローカルで実行 準備 Pythonプログラムから実行 単体実行 OpenAIを通した実行 活用例：討論する哲学者 哲学者の定義 討論内容の定義 討論の実施 討論の要約 まとめ LM Studioの紹介 LM Studioは、ローカル環境で大規模言語モデル（LLM）を簡単に実行できるプラットフォームです。GUIベースで操作できるため、エンジニアだけでなく、非エンジニアでも手軽に試すことができます。 【特徴】 直感的なUI ：モデルの管理やプロンプト実行を簡単に操作可能。 多様なモデル対応 ：Llama、Mistral、DeepSeekなど、さまざまなモデルをサポート。 ローカル実行 ：APIを通じてローカルで高速にモデルを実行可能。 LLMをローカルで実行 準備 まずは 公式サイト からLM Studioをダウンロードし、インストールしましょう。アプリを開くと、以下の画面が表示されます。下のメニューから、 Power User モードを選択します。すると、左側のメニューが現れます。 モデルをダウンロードするために、左メニューの4つ目の選択肢、「検索」をクリックします。このデモで利用するモデルは、 日本語にファイチューニングされた 「Llama-3-ELYZA-JP-8B-GGUF」と言います。検索バーで「elyza」を記入し、モデルを選択し、ダウンロードしましょう。 ⚠️ 補足 ：「なんでも答えてくれる」モデルもありますが、利用目的に合ったモデルをダウンロードした方がより適切な回答を得られます。例えば、Metaが公開しているLlamaをそのまま使用しても日本語で答えてくれますが、質問の意図を理解できない、無関係の回答が返されることもあります。 モデルに期待できる回答の確認をするために、左メニューの1つ目の選択肢、「チャット」をクリックすると、そのままダウンロードしたばかりのモデルと対話できます。 ⚠️ 補足 ：初回の実行だけ、モデルがダウンロードされていてもメモリ上でロードされるまで少し時間がかかります。 Pythonプログラムから実行 Pythonプログラムから利用するために、左メニューの2つ目の選択肢、「開発者」をクリックします。表れるメニューのURL情報を記録します。 以下のようにPythonで登録します。 local_url = 'http://127.0.0.1:1234' LM Studioでダウンロード済みのモデルの内部名称を確認するために以下の関数を使います。 import requests, json response = requests.get(f '{local_url}/v1/models' ) models = json.loads(response.text) print ([m[ 'id' ] for m in models[ 'data' ]]) 出力はこのようになります： [ 'llama-3-elyza-jp-8b' ] 利用するモデルと、投稿したいメッセージを定義します： model = 'llama-3-elyza-jp-8b' messages = [{ 'role' : 'system' , 'content' : 'あなたは便利なAIアシスタント。' }, # チャットボットの役割 { 'role' : 'user' , 'content' : 'こんにちは！' }] # ユーザーの質問・コメント # データをjson形式として保存 data = { 'model' : model, 'messages' : messages} 単体実行 では、いよいよチャットボットから回答を求めましょう！ # 回答を求める response = requests.post(f '{local_url}/v1/chat/completions' , json=data) response_content = json.loads(response.text) print (response_content[ 'choices' ][ 0 ][ 'message' ][ 'content' ]) # 辞書として中身を取得 実行結果： こんにちは！話を聞くことが大好きなAIアシスタントです！どうぞよろしくお願いします。 OpenAIを通した実行 OpenAIのAPIを使って、モデルを呼び出すことも可能です。 from openai import OpenAI # クライアントを作成 client = OpenAI(base_url=f '{local_url}/v1' , api_key= 'lm-studio' ) # 回答を求める response_content = client.chat.completions.create(**data) print (response_content.choices[ 0 ].message.content) # オブジェクトとして中身を取得 実行結果： こんにちは！話しかけてくれてありがとうございます！私はあなたの便利なAIアシスタントです。何でも相談したり、質問してくださいね！ ⚠️ 補足1 ：1回目の実行は 単体実行 より実行時間が長いが、2回目以降は同じ速度で回答が返ってきます。 ⚠️ 補足2 ：辞書を引数として展開する方法に慣れていない方は、 **data の代わりに以下を使用してください。 response_content = client.chat.completions.create( model=data[ 'model' ], messages=data[ 'messages' ] ) 活用例：討論する哲学者 ローカルで複数のLLMを走らせられるため、LLM同士の討論をシミュレートできます！ 哲学者の定義 哲学者には以下の機能を求めます： 1. LMStudioのLLMが使える 2. プロンプトに回答できる 3. 会話の履歴を記憶できる class Thinker : """哲学者のクラス""" def __init__ (self, local_url, model): """初期化""" self.local_url = local_url self.model = model def set_system (self, name, system_prompt): """チャットボット（哲学者）の役割を設定、文脈共有""" self.name = name # チャットボットの名称 self.history = [{ 'role' : 'system' , 'content' : f 'あなたは{name}です。{system_prompt}' }] # 会話履歴を初期化 def reply (self, user_message): """ユーザーの質問に回答""" # 会話履歴にユーザーの質問を追加 self.history.append({ 'role' : 'user' , 'content' : user_message}) # 回答を求める response = requests.post(f '{self.local_url}/v1/chat/completions' , json={ 'model' : self.model, 'messages' : self.history}) response_content = json.loads(response.text)[ 'choices' ][ 0 ][ 'message' ][ 'content' ] # 会話履歴に回答を追加 self.history.append({ 'role' : 'assistant' , 'content' : response_content}) # ここでassistantは自分のことを指す（userの反対） # 回答を返す return response_content 討論内容の定義 テーマ、役割や回答形式など定義します。Insight Edgeはせっかく生成AIを活かす企業なので、今回の討論テーマは「 生成AIの普及によって、データサイエンティストの仕事がなくなると思いますか？ 」にしたいと思います。哲学者はそれぞれ、「 仕事がなくなっていく 」派と、「 生成AIを有効に活かせる 」派のデータサイエンティストにします。 # 討論内容と哲学者の考えを定義 topic = { 'question' : '生成AIの普及によって、データサイエンティストの仕事がなくなると思いますか？' , 'thinkers' : [ '生成AIのせいで仕事がなくなると強く思うデータサイエンティスト' , '生成AIのおかげで仕事の効率が上がると強く思うデータサイエンティスト' ]} # 哲学者から求める細かい共通振る舞い common_instructions = """あなたは討論に参加しています。合理的でありながら、可能な限り自分の視点を擁護しなければなりません。あなたの言語スタイルは丁寧です。 あなたは非常に強い意見を持っており、何があっても自分の視点でユーザーを納得させる必要があります。 はい/いいえの質問に答えるとき、**必ず**「はい」または「いいえ」で始めてから、考えを説明してください。もし反対意見がある場合は、はっきりと示してください。回答は80文字以内に制限してください。""" 討論の実施 哲学者を定義し、合意に至るまでループに入れます。 # 哲学者2人を作成 thinker1 = Thinker(local_url, model) thinker2 = Thinker(local_url, model) # 哲学者の役割を設定 thinker1.set_system(topic[ 'thinkers' ][ 0 ], common_instructions) thinker2.set_system(topic[ 'thinkers' ][ 1 ], common_instructions) # 会話履歴を初期化 history = [topic[ 'question' ]] # 最初の意見 answer1 = thinker1.reply(history[- 1 ]) + 'あなたは賛成しますか？' history.append(answer1) thinker1_agrees = False # 最初の意見だけ、一人しか話していないので賛成とは言えない i = 1 print (f '（{i}）哲学者1の意見が出ました。' ) # 合意が得られるまで、交互に質問と回答を繰り返す while True : # thinker2の回答 answer2 = thinker2.reply(answer1) + 'あなたは賛成しますか？' history.append(answer2) thinker2_agrees = True if answer2[ 0 ] == 'は' else False # 賛成するかどうか。「はい」の1文字目で確認 i += 1 print (f '（{i}）哲学者2は、哲学者1の意見に対して{"同意" if thinker2_agrees else "反対"}しました。' ) if thinker1_agrees and thinker2_agrees: break # thinker1の回答 answer1 = thinker1.reply(answer2) + 'あなたは賛成しますか？' history.append(answer1) thinker1_agrees = True if answer1[ 0 ] == 'は' else False # 賛成するかどうか。「はい」の1文字目で確認 i += 1 print (f '（{i}）哲学者1は、哲学者2の意見に対して{"同意" if thinker1_agrees else "反対"}しました。' ) if thinker1_agrees and thinker2_agrees: break print ( '哲学者が合意しました。' ) 実行結果 LLMの細かいパラメーターを調整していないため、結果が実行する度に変わります。以下は1回の実行で得られた討論です。 （1）哲学者1の意見が出ました。 （2）哲学者2は、哲学者1の意見に対して同意しました。 （3）哲学者1は、哲学者2の意見に対して反対しました。 （4）哲学者2は、哲学者1の意見に対して同意しました。 （5）哲学者1は、哲学者2の意見に対して同意しました。 哲学者が合意しました。 この実行で、討論は5ステップで収束しました！ 討論の要約 討論の履歴を全部読むのが場合によって大変かもしれませんので、内容を要約する新しい哲学者を定義します。 # 会話の内容を簡潔にまとめる考案者を作成 thinker3 = Thinker(local_url, model) thinker3.set_system( '討論の目撃者' , f """元の質問は「{topic['question']}」でした。 これが彼らの最終的な発言です: {history[-2:]}""" ) # 内容をまとめるために、最後の2つの発言だけ参照 conclusion = thinker3.reply( '最終的に双方は合意に至ったようです。彼らは何に合意しましたか？' ) print (conclusion) 内容のまとめはこちらです： 彼らが合意したのは、生成AIの普及によって、データサイエンティストの仕事がなくなるということではなく、その専門性や創造性を活かす機会が減少することは反対で、人間特有の判断や洞察を必要とする高度な分析や戦略立案などは、AIに置き換えられない分野であり、これらのスキルを身に着けることで、我々データサイエンティストの価値を高めることができるという点です。 最後に、履歴の中身を確認したい場合は、 history をそのままプリントすれば良いです。 for text in history: print (text) まとめ LM Studioは、ローカルで大規模言語モデルを手軽に試せる強力なツールです。ローカルだからこそ複数のエージェントを定義でき、対話型のシミュレーションにも応用できます。プライバシーを重視しつつ、LLMの可能性を広げるために、ぜひご活用ください！ ¡Hasta pronto!

はじめに こんにちは、Insight Edgeで営業・コンサルタントを担当している楠です。 普段は主に住友商事グループの事業会社向けのDX案件の企画・推進に携わっております。 今回の記事では、私が参加させていただいた社会人向け研修プログラム「Technology Creatives Program（通称テックリ）」の内容や学びについてご紹介いたします。デザイン思考に関心のある方や、テックリへの参加を検討している方への参考になれば幸いです。 なお、テックリの受講期間は3月までなのですが、本記事の内容は執筆時点（2月中旬）のものとなる点、あらかじめご留意ください。 目次 はじめに Technology Creatives Program(テックリ)とは 参加動機・きっかけ プログラムの内容・学び まとめ Technology Creatives Program(テックリ)とは 本題に入る前にTechnology Creatives Program(通称：テックリ)の概要について触れておきたいと思います。 テックリは、東京科学大学・多摩美術大学・一橋大学という、日本を代表する三大学が共同で提供する社会人向けの教育プログラムです。Technology Creatives Programという名前の通り、テクノロジー、クリエイティブ、及びビジネスの観点を俯瞰・統合し、これまでになかった製品・サービス開発を通して新たな価値創造を実現する人材を育成することを目的としています。 テックリについて知りたい方は 公式HP をご覧ください。 参加動機・きっかけ 弊社はMissionとして「To “Re-design” the world with the power of technology; 技術の力で世界を“Re-design”する」を掲げており、主に住友商事グループ企業のDX化を主軸に、グローバルの多種多様な事業と向き合い、テクノロジーで課題を解決するサポートを行なっています（参考： 採用 - Insight Edge ）。 私も上記Missionに基づき日々業務にあたる中で、複雑な課題を解決するためには粘り強さと柔軟な思考が不可欠であると感じており、テックリでアート思考やプロトタイピング手法を学ぶことで、日々の業務に活かせるヒントを得たいと考えました。 また、後述の通り、テックリでは他の様々な会社・職種の参加者の方とチームを組んで一緒にワークすることが多いため、異なるバックグラウンドや価値基準を持つ方々と協業して成果を上げる経験や交流の機会が得られると考えました。 加えて、テックリは今年度で3期目となっており、弊社のデザインストラテジストが過去に参加していたことも大きなきっかけの一つです（当該メンバの過去記事は こちら ）。 プログラムの内容・学び テックリは大きく「導入モジュール」「パーパスモジュール」「探索モジュール」「旅立ちモジュール」の4つのモジュールで構成されています。プログラムの内容説明は 公式HP に記載がありますが、ここでは自分の経験に基づき、記載のない部分について、私個人の学びと併せて少し補足したいと思います。約半年強のプログラムでの実施内容や学びはとても多く、全てを書ききることは難しいので、少しでも気になった方は是非受講を検討してみてください。 なお、今後実施されるテックリの内容については、最新の情報をご確認ください。また、コンテンツの権利保護に配慮し内容面の詳細な記述は避けています。 導入モジュール 概要 多摩センター周辺の研修施設にて2日間の合宿形式で、講師の方々による講義やワークを実施。 ワークでは、自治体職員の方からお題をいただいた上で、多摩センターで活動されている方々（地域住民やボランティアの方など）へのインタビュー及びフィールドワークを実施し、課題解決につながるソリューションのアイデア発想及び提案を行った。 印象的だった点・学び テックリの採用するアプローチ ソリューション検討では、インタビューに基づいてエクストリームユーザーのインサイトを抽出した上で、スケッチや段ボールなどでの簡単なプロトタイピングを行うアプローチをとりました。また、作成したプロトタイプを用いて自らスキット（寸劇）を行い、具体的なソリューションイメージの検討やすり合わせを行った点も印象的でした。 プロトタイプ・スキットの重要性 プロトタイプやスキットは、ソリューションのイメージを端的に伝える手段としてだけではなく、ソリューションについて考えを詰め切れていない部分に気づくための手段としても有効であると感じました。チームメンバでスキットを実施する中で「○○の機能はどうなってるんだっけ？」といった会話が生まれることで、検討できていなかった詳細な項目に気づく場面が何度もありました。 パーパスモジュール 概要 テックリ講師陣によるオンライン講義を受講。 多摩美術大学にて、博報堂ブランド・イノベーションデザイン様及びARS ELECTRONICA FUTURE LABの小川秀明氏による講義及びワークショップを実施。 Cooking Slam（調理実習型ワークショップ）を実施。各チームにあらかじめ設定と食材が割り振られた状態でオリジナルの料理を作成した。 印象的だった点・学び 「写真を撮る際は影が映らないように」 オンライン講義の一つでスケッチのレクチャを受けた際のことです。受講者が事前提出したスケッチの写真に対して講師の先生からフィードバックをいただく場面で私の番になった際、一通りスケッチに関する指導をいただいた後、「写真を撮る際は影が映らないように」というコメントをいただきました。曰く、影に気を取られるとメインである絵の方に集中できなくなってしまうとのこと。また、デザイナーの世界では、ミーティング後にスケッチを共有することがあるそうですが、その際も影や余計なものの映り込みはないようにしているとのことでした。普段から意識されている方にとっては当たり前のことかもしれませんが、私はあまり気にしていない部分だったので、大きな気づきとなりました。別の場面にはなりますが、プロトタイプを作成する際ワークショップの際にも「早く簡単に作ることと雑に作ることは違う」というコメントをいただいており、印象に残っています。プロトタイプは実際の製品とは異なり精巧に作りすぎる必要はないものの、ユーザ検証など一定の目的を達成するために丁寧に作る必要があると感じています。 実際の写真。タイトルは「出る杭は打たれる。ただし、出過ぎた杭は打たれない。」 調理とプロジェクトの共通性 Cooking Slamでは、限られた食材の中でオリジナルの料理を作成し、設定に沿ったストーリーと併せて発表しました。時間や使える食材が限られている中、チームで協力しながら素早く手を動かして完成品を作る行為は、仕事におけるプロジェクトワークと似ていると感じましたし、後の探索モジュールにも通じる部分がありました（ちなみに、ワークの中では調理中に様々な制約が追加されるのですが、私のチームは途中から包丁の使用を禁止されました…！）。 探索モジュール 概要 他の参加者と4名程度のチームを組み、パートナー企業様からのお題に対してプロトタイプ付きのソリューション提案を実施（導入モジュールの長期間版）。プロジェクト期間は約4か月で、この間にユーザ候補者へのインタビューやプロトタイピングを何度も繰り返して実施。最終成果物についてはポスター展示やプレゼンを実施。 印象的だった点・学び 「問い」の重要性 お題は抽象度の高いものが多く、初めにインタビューを通じて自分たちが想定するユーザや解決したい課題およびHMWQ（テックリでは解決したい課題に対するアプローチ方針をHow Might We Questionと呼ばれる「問い」の形で表現していました）を定義する必要があったのですが、これが相当大変な作業でした。広すぎる・狭すぎる・インサイトを捉えきれていない・テックリのアプローチでの解決が困難（例：医療処置など）など、講師陣のフィードバックを受けながら、インタビュー結果のメモを眺めて何度も検討しました。この部分が詰め切れていないと、必要とされないソリューションや実現不可能なソリューションができてしまうので、やはり「問い」の設定が最も重要な工程であると感じました。 「手を動かすこと」の重要性 探索モジュールに限らずテックリ全体を通した最大の学びがこちらになるのですが、情報収集・アイデア発想・ソリューション検討いずれにおいても、頭だけではなく手を動かして素早くプロトタイプを作成することが重要であると感じました。今回、チーム全員が社会人メンバで通常業務と並行して探索モジュールのプロジェクトを進める必要がある中、チームでの話し合いの時間は、どうしても日程調整・タスク整理・役割分担といったプロジェクト管理的なトピックであったり、アイデアを並べて「どれが良いか」を考える議論に割かれがちでした。しかし、インタビューを実施して、テーマや自分たちのソリューションに関する生の声を収集したり、アイデアやユーザ体験の絵を描いたり、実際のモノを作ったりしなければ、自分たちのソリューションに自信を持つことができません。なぜなら「答え」はユーザが持っているからです。私たちのチームは初期にこの「ワナ」にはまり苦労しましたが、終盤ではインタビュー時にプロトタイプを見せるようになり、ユーザから返ってくるフィードバックの質や量が大幅に改善されました。 旅立ちモジュール ※3月実施予定につき割愛 まとめ 今回の記事では、私が参加させていただいた社会人向け研修プログラム「Technology Creatives Program（通称テックリ）」の内容や学びについてご紹介いたしました。 体系化された知識というよりは自分自身の経験を通した学びが多かったですが、何某か皆様の参考になりましたら幸いです。自分自身も、今後業務を進める際の糧としていきたいと思います。 プログラム内容が盛りだくさんだったこともあり、書ききれていないことが多数あるのですが、ご興味のある方は是非受講を検討してみてください！

こんにちは! Insight Edge分析チームの梶原(悠)です。 最近ひょんな経緯で量子計算用のQmodという言語のフィジビリ兼ゆる勉強会に顔を出しています。 Qmod言語 1 はclassiq社という量子ベンチャーが提供している 無償 有償ツール※で、簡便に量子アルゴリズムを実装できる高水準言語をうたっています。 私は量子計算について何も知らない素人ですが、基本的なpythonと線形代数の知識があれば使えるとのことで、量子畑の人たちにあれこれ教えていただきながら、すこし触ってみました。 量子計算に興味や前提知識はないが、技術動向はある程度把握しておきたいと考える技術者の読み手を想定して、言語仕様の一部やツールに触れてみた感想などを書きます。 ※ 2025.3.7 classiq社様より無償ツールの記述は誤りであるとのご連絡を頂いた為訂正しました。公式サイト中の"free for non-comercial purpose"の記載に基づき無償ツールと解釈していたのですが、最近有償化されたそうです。この誤りを含む複数のご指摘に感謝申し上げます。 目次 はじめに Qmod言語の仕様調査 回路生成の試行 感想 はじめに 量子計算とは 古典的なコンピュータにおけるCPUのレジスタは一刻にひとつの状態しか取れません。 これは重ね合わせ状態の崩れた物理系を利用して実装されているためです。 一方、重ね合わせ状態にある物理系でレジスタを実装すれば、指数的に多くの状態を並列して時間発展させることができます。 量子計算では、指数的に大きな並列処理を利用して、複雑な計算を高速に実行します。 ただし結果の観測などに強い制約があり、どんな問題でも指数的に速く解けるわけではありません。 実用化に向けた現状 IBM社のロードマップ 2 ではエラーの影響なく量子計算を実行できるデバイスの提供は2029年以降とされています。 classiq社のセミナー講師の方の話では、量子計算には実ビジネスで意味のある活用例はまだ存在しないようです。 何かのイベントの質疑応答で理研の研究者の方も「量子乱数は実用されているが、最適化などの文脈で意味のある活用例はまだない」と回答されてました。 これらの話を聞くと、量子技術を付加価値にして実社会に役立つものづくりをすることは現時点で難しいように思えます。 しかし、興味深いベンチャーも出てきています。 量子計算が実用化すると楕円曲線暗号を現実的な時間内に解けるようになるため、既存の暗号通貨が攻撃される懸念があります。 BlocQ 3 というベンチャー企業では、暗号生成部分のみ量子計算を利用したブロックチェーン技術を採用し、 量子技術の実用化が進んでも進まなくてもワークする量子readyな暗号通貨を開発しているようです。 量子に限らず、まだ早すぎる技術をどう売るか考える際に、〇〇readyな〜という切り口は学ぶ処がありそうに感じました。 量子回路モデル Qmodは量子回路という計算モデルの記述言語です。 量子回路を提案したD.Deutschは計算器を次のように説明しています。 4 直感的には, 計算器とは, 系の動的な発展で入力状態の集合から出力状態の集合へと遷移する任意の物理系です. 各状態には, なんらかの自然なラベルがつけられていて, マシンは指定された入力ラベルの状態で準備されます. そして, いくらかの動作を経たのち, 出力状態のラベルが観測されます. 古典計算では、入出力のラベルやレジスタの状態は01列で表されていました。 量子計算でもラベルは01列ですが、レジスタは複素ベクトルで表されます。 古典計算の時間発展はレジスタの状態をコピーや論理演算子などでくりかえし変換して記述されました。 量子計算はレジスタにゲートと呼ばれるユニタリ行列をくりかえし作用させて時間発展を記述します。 時間発展は可逆でなければならず、状態のコピーはできません。 レジスタに作用させるゲートを並べた系列を量子回路 5 といいます。 下記の表に量子回路による計算の構成要素をまとめます。 用語 説明 キュビット (qubit) 大きさが1の2次元複素空間のベクトル をキュビットという. 量子レジスタ 大きさが1のn次テンソル空間のベクトル を長さnの量子レジスタという. キュビットの状態 6 トレースが1の半正定値なエルミート行列を密度行列という. キュビット で定まる密度行列 をキュビットの状態という. 量子レジスタの状態 量子レジスタ で定まる密度行列 を量子レジスタの状態という. 量子ゲート 量子レジスタ上のユニタリ行列を量子ゲートという. 量子回路 長さ のレジスタ上の量子ゲート は自然に長さ のレジスタ上のユニタリ行列 に拡張できる. 量子ゲート を長さ のレジスタ上に拡張したユニタリ行列の列 を𝑛ビット量子回路とする. 観測可能量 冪等 (すなわち ) な行列 を、部分空間 への射影作用素という. エルミート行列 を 番キュビットのオブザーバブルという. オブザーバブル の固有値 に対応する固有空間へのエルミートな射影作用素を とかく. 測定 量子レジスタ の キュビットの状態の測定とは以下の1. 及び2. を行うことである. 1. (統計公式) ビット列のサンプリング を行う. ただしビット列 に対応する射影作用素を とした. 2. (射影仮説) レジスタの状態を密度行列 から に変える. 量子回路は下図のような直感的なダイアグラムで記述することができます。 横線はキュビットを表し、四角い箱はゲートを表します。 横線の左端がキュビットの初期状態に対応し、左から順にゲートを作用させていくことで時間発展を記述します。 Qmod言語の仕様調査 コンパイル階層 量子計算を実行する物理デバイスによってキュビットの結合状況や利用できる基本ゲートの種類は異なります。 qmodツールは抽象的な量子回路を物理デバイス上で実行可能な量子回路へとコンパイルします。 qmodのコンパイル階層 7 の詳細は不明ですが、概ね上図のような流れと想像されます。 QNum型 qmodにはいくつかのQuantum型が定義されています。 QBit型はキュビットに対応します。 QNum型は量子レジスタに実数の固定少数点表現として解釈するためのメタ情報を付与したものと思われます。 いくつかのパタンを実験した限りでは基底ベクトルと実数は下記のように対応するようです。 量子レジスタの解放 qmodは量子レジスタの領域の割当や解放を自動的に行います。 Quantum型の変数に割り当てられた領域を明示的に解放させる方法として少なくとも以下の3通りはあるようです. bind(src,dst)関数のsrc側の引数にする. qfuncデコレータのついた関数のinput修飾子のついた引数にする. within_apply(within,apply)関数のwithin部で宣言、初期化する。 ライブラリ関数の例: 標準ゲート関数(X, Y, Z) X,Y,Z関数はそれぞれ以下で定義されるパウリ 演算子を表します。 # 分類・名称 記号 定義 基底 についての行列表示 1 パウリX演算子, NOT 2 パウリY演算子 3 パウリZ演算子 ライブラリ関数の例: linear_pauli_rotations関数 linear_pauli_rotations関数は以下の形で呼び出します。 (ただし、 はパウリ行列を指定するenum。) この関数は以下のようにレジスタ を変化させます. Input Output (ただし は引数basesで指定したパウリ行列.) linear_pauli_rotations関数はキュビットを行列 で変換する関数だとわかりました。 そこで行列 による変換が何を意味するかを考えてみます。 写像 を で定め、ホップ写像と呼びます。 ホップ写像を の単位球に制限すると の単位球への全射を与えます。 この全射の像をブロッホ球と呼びます。 キュビット を行列 で変換すると、ブロッホ球上の点 は点 へ動きます。 ホップ写像の定義式にパウリ行列 の指数を三角関数で表した を代入すると次の関係が導かれます。 したがって、行列 はブロッホ球を 軸周りに 回転させます。 また、 をそれぞれ にぐるりと入れ替えて同様の議論を繰り返せば、 行列 が 軸周りの 回転を引き起こすことがわかります。 同様にして、行列 は 軸周りの 回転を引き起こすことがわかります。 回路生成の試行 量子モンテカルロという手法で積分 の値を推定する回路を題材に、回路生成を試行してみます。 量子モンテカルロでは、積分値の推定問題をユニタリ行列の固有値問題に帰着して解きます。 大まかなアイディアとしては、まず推定したい積分値の情報を固有値として持つユニタリ行列を構成します。 次に位相キックバックというトリックを用いて固有値をキュビットの位相として取り出します。 最後に、位相を量子フーリエ変換の逆変換等で振幅に反映させて観測すれば、興味のある積分値を高速に推定できるという流れです。 推定したい積分値の情報を固有値として持つユニタリ行列を構成するには2つの材料が必要です。 ひとつめは、求めたい積分値に応じた角度 だけ初期ベクトルを回転させながらある実2次元部分空間 に送り込む作用素(state_loading)です。 ふたつめは、部分空間 を第一軸について鏡映する作用素(good_state_oracle)です。 これらの材料を掛け合わせることでGroverOperatorという作用素を構成できます。 GroverOperatorは空間 を 回転させるため、固有値が積分値の情報を持つ作用素を作れたことになります。 実装上は、材料となる2つの作用素(state_loading及びgood_state_oracle)を qmodの組み込み関数amplitude_estimationに与えるだけで、 qpeによる量子モンテカルロの回路を作成できます。 以下は上記の積分値を推定する回路を生成してtranspile前後の回路をOpenQASMという形式で取得する実装例です。 from classiq import * # バージョン 0.67.0 で試行. n_qpe = 5 D = 2 n_prn = 5 a = 2.0 * (math.pi / 6.0 ) / ( 2 ** n_prn) b = 0.0 def good_state_oracle (state: QNum[QBit]): x = QNum( "x_" , n_prn*D) q = QBit( "q_" ) bind(state, [q, x]) Z(q) bind([q, x], state) return state def state_loading (state: QNum[QBit]): x1 = QNum( "x1" , n_prn) x2 = QNum( "x2" , n_prn) q = QBit( "q" ) bind(state, [q, x1, x2]) hadamard_transform(x1) linear_pauli_rotations( bases=[Pauli.Y.value], slopes=[a], offsets=[b], x=x1, q=q # sin((ax+b)/2) ) hadamard_transform(x2) linear_pauli_rotations( bases=[Pauli.Y.value], slopes=[a], offsets=[b], x=x2, q=q # sin((ax+b)/2) ) bind([q, x1, x2], state) return state @ qfunc def main (phase: Output[QNum]): state = QNum[QBit]( "state" ) allocate(n_prn*D+ 1 , state) allocate_num(n_qpe, False , n_qpe, phase) amplitude_estimation( oracle=good_state_oracle, # S_psi space_transform=state_loading, # A phase=phase, packed_vars=state ) model = create_model(main) model = set_constraints( model, Constraints( max_width= 25 , optimization_parameter=OptimizationParameter.DEPTH )) model = set_preferences(model, Preferences( optimization_timeout_seconds = 3600 , timeout_seconds = 3600 * 2 , qasm3= True , custom_hardware_settings = CustomHardwareSettings( basis_gates=[ "rz" , "cx" , "sx" , "x" ], ), transpilation_option= "intensive" , optimization_level = 3 , debug_mode= False )) qprog = synthesize(model) circuit = QuantumProgram.from_qprog(qprog) qasm_transpiled = circuit.transpiled_circuit.qasm qasm_raw = str (circuit.qasm) 上記の回路生成を回路幅の制約や最適化有無を切り替えながら何度か実行してみました。 synthesize関数が生成したtranspile前後の回路の幅(キュビットの個数)と深さ(時間発展のステップ数)の関係のグラフを示します。 最適化なしの設定ではすべての回路が同じ幅になりました。最適化ありの設定で生成したtranspile後の回路には幅と深さのトレードオフが見られます。 一方、transpile前の回路で幅の制約を緩めていくと、深さはそのままで幅だけが広がっていくことが観察されました。 これは敢えて幅を広げた冗長な回路にすることで、transpile後の回路がより圧縮されるように準備しているものと想像します。 transpile後の回路の深さは幅23ほどで改善が頭打ちになり、その後はゲート数だけが悪化しています。 仕様上、幅と深さは同時に最適化できないため、最適な回路を生成するためには、ユーザ側で回路幅の適切な制約を探索する必要がありそうです。 感想 今回は量子計算用のqmod言語の仕様を調査しました。 個人的にはwithin_apply関数の仕様が特に興味深いと感じました。 回路最適化やシミュレーションの実行はサーバ側で走りますが、同時に複数プロセスから呼ぶとエラーになるようでした。 これはバリエーション検証をする上で不便だと感じました。 差別化の観点では、生成された回路サイズがqiskitより非常に小さくなることは印象的だと感じました。 qmodのベンダが保有する特許情報 8 を見ると、回路最適化の他にも誤り訂正やデバッグに関するものがあるようです。 これらの要素が今後どのようにツールの機能に反映されていくのか興味を覚えました。 参照 [1] Qmod in classiq python sdk https://docs.classiq.io/latest/classiq_101/registration_installations/#python-sdk-installation [2] IBM Quantum roadmap https://www.ibm.com/quantum/blog/ibm-quantum-roadmap-2025 [3] BlocQ, lnc. https://www.blocqinc.com/blocq-selected-for-prestigious-ict-startup-league/ [4] Deutsch, D. (1985). Quantum theory, the Church–Turing principle and the universal quantum computer. Proceedings of the Royal Society of London. A. Mathematical and Physical Sciences, 400(1818), 97-117. [5] 小澤正直, & 西村治道. (1998). 量子コンピュータの計算量 (応用函数解析の研究). 数理解析研究所講究録, 1039, 64-80. [6] 小澤正直. (2012). 量子測定理論入門 (講義, 第 56 回物性若手夏の学校 (2011 年度) 研究と人生の指針-Beyond the CoMPaSS of your field.-, 講義ノート). 物性研究, 97(5), 1031-1057. [7] Sahu, H., & Gupta, H. P. (2023). Quantum Computing Toolkit From Nuts and Bolts to Sack of Tools. arXiv preprint arXiv:2302.08884. [8] Justia Patents https://patents.justia.com/assignee/classiq-technologies-ltd

こんにちは、Insight EdgeでDeveloper兼テックブログ運営担当をしているMatsuzakiです。 今回は、私が担当している本テックブログ「Insight Edge Tech Blog」運営担当業務における業務効率化・高度化兼自己研鑽の一貫として現在テックブログレビューエージェントを試作中ですので、そちらの開発経緯や内容をお話ししていきたいと思います。 目次 開発背景 システム構成 レビューの流れ 開発内容 レビュー観点の洗い出し 処理フロー 実装 ステートの定義 グラフの定義 ノードの追加 エントリーポイントの追加 エッジの追加 コンパイルと実行 成果物について 今後の期待 おわりに 開発背景 本テックブログ「Insight Edge Tech Blog」は、2022年10月に開設し、2025年2月現在で2年以上継続しています。（先日記事も100本を超えました！🎉） しかし、テックブログを安定して運営し続けるのは難しいですよね。そこで弊社では、「テックブログ運営チーム」(以下運営チーム)としてエンジニア2名、データサイエンティスト2名の計4名でチームを組み、スケジュール管理、進捗管理、記事レビュー、投稿などの業務を担当しています。 その中でも、特にコストがかかり、担当者によってばらつきが出やすいのが記事のレビュー作業です。 さらに、近年AIエージェントが盛り上がっている状況を踏まえ、技術のキャッチアップも兼ねて、「レビュープロセスをAIエージェントで自動化できないだろうか？」と考え、開発に至りました。 ※現在は試作段階です。 システム構成 システムの構成は以下の通りです。 弊社のテックブログは記事をMarkdownファイルで執筆し、各々ブランチを作成してGitHub上で管理しています。 現在の運用では、作成されたプルリクエストに対してレビューを行っており、システム導入後も同様に、プルリクエスト単位でレビューを実施します。 レビューの流れ 以下に本システムのレビューの流れを示します。 執筆者がGitHubにプルリクエストを作成 GitHub Actionsがプルリクエスト作成・更新をトリガーとして起動 GitHub ActionsがLambdaを起動 GitHubのAPIを使って記事内容を取得 記事内容とプロンプトを元にBedrockを通じてモデル（Claude 3.5 Sonnet）を呼び出す モデルのレスポンスを元にレビュー内容を作成 GitHubのAPIを使ってレビュー内容をプルリクエストに投稿 後述しますが、5についてはモデルとの1回のやり取りでレビュー内容を作成するのではなく、レビュー観点ごとに段階的に呼び出しを行い最終的な結果を出力させます。 以上が一連の流れとなります。 開発内容 今回の開発の軸となるところは、上記の「レビューの流れ」のうち、5-6に値する生成AIを使ったレビュー処理フローの部分となります。 そのために、まずはレビュー観点を整理して洗い出し、その後処理フローへの落とし込み、最終的に実装へ繋げています。 レビュー観点の洗い出し まず、テックブログレビューにおける重要な観点を整理しました。(現状の運用ではレビュー観点として整理されているものはなく、個々人に委ねられている部分があるため、これを機に体系的な整理を進めたいところです！) 一つ一つ見ると細かいですが、大きな観点としては3つで、「1.構造の正確さ、2.内容の適切さ、3.文章の品質」です。 1. 構造の正確さ ・見出しの整理 　・見出し（h1, h2, h3 など）が階層的に整理されているか。 　・見出しと内容が対応しているか。 ・論理構成 　・文章や論理構成に問題がないか。 2. 内容の適切さ ・技術的正確性 　・専門用語の誤用がないか。 ・独創性・独自性 　・具体的な事例が含まれているか。 　・他の記事と差別化できているか。 　・本記事ならではの工夫ポイントがあるか。 ・網羅性 　・他に記述すべき観点がないか。 ・内容の質 　・簡単すぎる内容になっていないか。 　・単なるマニュアルの模倣になっていないか。 　・読者がすぐに見つけられるような内容だけではないか。 ・倫理性・適切性 　・他者に誤解や不快感を与える表現がないか。 　・会社に不利益をもたらすような内部情報や公開すべきでない情報が含まれていないか。 3. 文章の品質 ・誤字脱字 　・誤字や脱字がないか。 ・読みやすさ 　・複雑な文構造を避け、平易な言葉になっているか。 ・冗長表現の整理 　・繰り返し表現や冗長な記述がないか。 ・表記揺れ 　・言葉の表記が統一されているか。 ・スタイルの一貫性 　・一人称と三人称が混在していないか。 洗い出してみると、結構多くの観点がありました。 処理フロー 上記で洗い出した観点、中でも大項目レベルの「1.構造の正確さ、2.内容の適切さ、3.文章の適切さ」を主軸とし、 Agentic Workflow の手法を用いて処理フローを作成しました。 ※ Agentic Workflowとは、「LLMの出力結果に基づいて、次の処理を分岐したり、分岐によってLLMを呼び分けたりする」手法です（ LLMマルチエージェントのフローエンジニアリング（Agentic Workflow）実践ガイド より）。 一部の項目については、Web検索APIを組み合わせるなど、LLM単体ではなく他のアプローチを併用するのが適切な場合もあります。ただし、試作段階としてまずはシンプルに、プロンプト内で対応可能な範囲に絞った処理フローを作成しました。 実際の処理フロー（※現時点）は以下です。 ※一つ一つの水色の四角はLangGraphのノードと対応しています。（後述） 処理の流れは以下の通りです。 「構造の正確さ」観点でのレビュー結果を生成(structure_check) 「内容の適切さ」観点でのレビュー結果を生成(content_check) 「文章の品質」観点でのレビュー結果を生成(quality_check) 1~3で生成されたレビュー結果を統合(review_integration) 統合後レビュー結果に対して、意図した結果となっているか評価(self_reflcection) 5の結果が'NG'であればリトライ数4回未満の範囲で'OK'になるまで4を繰り返す 観点ごとにプロンプトを分けて結果を生成し、更に統合結果に対してセルフリフレクションで評価・再生成ループを繰り返すことで一定の品質を維持できるようにしています。 実装 今回実装にあたっては、フローの可読性が高く、条件分岐・ループが実装しやすい LangGraph を使用しています。 上記処理フロー図内の水色の四角で表されている部分がそれぞれノードとして独立しています。 ここでは、LangGraphで実装したグラフの構造を中心に実装の一部を紹介します。 LangGraphでは、共通のステートを定義した上で、ノード（処理）とエッジ（処理の流れ）を組み合わせ、グラフを構築・実行します。 そのため、まずはワークフロー全体で利用するステートを定義します。 データ構造は Pydantic のBaseModelクラスを用いて定義します。 ステートの定義 from pydantic import BaseModel, Field class ReviewResults (BaseModel): structure_check: str = Field(default= "" , description= "構造" ) content_check: str = Field(default= "" , description= "記事内容" ) sentence_quality_check: str = Field(default= "" , description= "文章の質" ) class ReflectionResults (BaseModel): judgement: str = Field(default= "" , description= "OK/NG判断" ) feedback: str = Field(default= "" , description= "改善提案" ) retry_count: int = Field(default= 0 , description= "リトライ数" ) # State class State (BaseModel): article: str = Field(default= "" , description= "記事内容" ) review_results: ReviewResults = Field( default_factory=ReviewResults, description= "レビュー結果" ) review_summary: str = Field(default= "" , description= "レビュー統合結果" ) reflection_result: ReflectionResults = Field( default_factory=ReflectionResults, description= "内省結果" ) LangGraphにおけるステートとは、ワークフローで実行される各ノードによって更新された値を保存する仕組みです。ワークフロー内で読み書きするデータはステートとして定義しておきます。 グラフの定義 次に、グラフのインスタンスを生成し、グラフを定義します。 StateGraphはグラフ構造の定義のために使われるクラスであり、これに対してノードやエッジを追加することで処理を構成していきます。 workflow = StateGraph(State) ノードの追加 次に、ノードを追加していきます。 それぞれのノードの中でLLM呼び出しを行い結果を生成します。 # ノードの追加 workflow.add_node(structure_check) # 構造観点のレビュー workflow.add_node(content_check) # 内容観点のレビュー workflow.add_node(quality_check) # 文章の質観点のレビュー workflow.add_node(review_integration) # レビュー結果統合 workflow.add_node(self_reflection) #　統合結果の評価 ノードは以下のように定義します。 ここでは、content_checkノードとself_reflectionノードの実装例を記載しています。 ※プロンプトは今後改善予定です from typing import Any from langchain_aws import ChatBedrock from state.state import State from langchain_core.output_parsers import StrOutputParser from langchain.prompts import PromptTemplate from settings import config def content_check (state: State) -> dict [ str , Any]: article = state.article llm = ChatBedrock( model_id={モデルIDを入力}, region_name={リージョン名を入力}, ) prompt = PromptTemplate( input_variables=[ "article" ], template= """ あなたはプロフェッショナルな技術ブログの校正・校閲者です。 あなたのタスクは記事内容について、以下の5つの観点に基づき、「評価ポイント」と「改善点」を出力する ことです。 # レビュー観点 1. **技術的正確性** - 専門用語の誤用がないか。 2. **独創性・独自性** - 具体的な事例が含まれているか。 - 他の記事との差別化ができているか。 3. **網羅性** - 他に加えるべき観点がないか。 4. **内容の質** - 一般的な情報のなぞりになっていないか。 - 内容が簡単すぎないか。 5. **倫理性・適切性** - 誤解や不快感を与える表現がないか。 - 企業の機密情報やブランドを損なう内容がないか。 # 留意事項 - 「改善点」は具体的に記述してください - 改善点がない場合は「改善点」の欄に「なし」と明記してください - 文章は「です・ます」調で統一してください # 記事内容 {article} # 出力フォーマット **観点1: 技術的正確性** - **評価ポイント**: {{良い点を一文で記載}} - **改善点**: - {{改善点がある場合は記載し、ない場合は「なし」と記載}} **観点2: 独創性・独自性** - **評価ポイント**: {{良い点を一文で記載}} - **改善点**: - {{改善点がある場合は記載し、ない場合は「なし」と記載}} **観点3: 網羅性** - **評価ポイント**: {{良い点を一文で記載}} - **改善点**: - {{改善点がある場合は記載し、ない場合は「なし」と記載}} **観点4: 内容の質** - **評価ポイント**: {{良い点を一文で記載}} - **改善点**: - {{改善点がある場合は記載し、ない場合は「なし」と記載}} **観点5: 倫理性・適切性** - **評価ポイント**: {{良い点を一文で記載}} - **改善点**: - {{改善点がある場合は記載し、ない場合は「なし」と記載}} """ , ) parser = StrOutputParser() chain = prompt | llm | parser # 実行して結果を取得 result = chain.invoke({ "article" : article}) state.review_results.content_check = result return state from typing import Any from langchain_aws import ChatBedrock from state.state import State from langchain.prompts import PromptTemplate from langchain_core.output_parsers import JsonOutputParser def self_reflection (state: State) -> dict [ str , Any]: """ review_integrationの結果を評価し、フォーマットと改善点の抽出が適切か判断する Args: state (State): アプリケーションの状態 Returns: dict[str, Any]: 評価結果を含む辞書 """ llm = ChatBedrock( model_id={モデルIDを入力}, region_name={リージョン名を入力}, ) review_result = state.review_summary content_check_result = state.review_results.content_check sentence_quality_check_result = state.review_results.sentence_quality_check structure_check_result = state.review_results.structure_check base_prompt_template = """ あなたはプロフェッショナルなレビュー統合結果を評価する品質管理者です。 あなたのタスクは、レビュー結果を評価し、以下の評価観点が満たされているかを判定することです。 # 前提 レビュー結果は統合元レビュー結果を元に生成されています。 # 評価観点 1. フォーマットの統一性 - 【内容について】【文章の品質について】【構造について】の3セクションがある - 観点は1から始まっている - 各セクションに「観点」と「改善点」が含まれている 2.文章のスタイルが適切か - 「評価ポイント」に否定的な表現が含まれていない - 文章の文体が「です・ます」調で統一されている 3. 改善点の抽出が適切か - 「なし」以外の改善点が漏れなく抽出されている - 改善点の内容が元のレビュー結果から変更されていない # 判定ルール - 全ての評価観点を満たしている場合 → "OK" - いずれかの評価観点を満たしていない場合 → "NG" + その理由と改善案 # レビュー結果 {review_result} # 統合元レビュー結果 ### 構造について {structure_check_result} ### 内容について {content_check_result} ### 文章の品質について {sentence_quality_check_result} # レビュー対象記事 {article} # 出力フォーマット {{"judgement": "OK" or "NG", "feedback": "評価観点が満たされていない理由、改善案"}} """ # プロンプトの作成と実行 prompt = PromptTemplate( input_variables=[ "review_result" ], template=base_prompt_template, ) output_parser = JsonOutputParser() chain = prompt | llm | output_parser # 評価の実行 result = chain.invoke( { "review_result" : review_result, "content_check_result" : content_check_result, "sentence_quality_check_result" : sentence_quality_check_result, "structure_check_result" : structure_check_result, } ) # retry_countの更新 current_retry_count = int (state.reflection_result.retry_count or 0 ) if result[ "judgement" ] == "NG" : current_retry_count += 1 # 結果を状態に保存 return { "reflection_result" : state.reflection_result.model_copy( update={ "judgement" : result[ "judgement" ], "feedback" : result[ "feedback" ], "retry_count" : current_retry_count, # 更新されたカウントを保存 } ) } エントリーポイントの追加 次にエントリーポイント(最初の処理)を設定します。今回structure_checkノードから処理を始めるため、エントリーポイントにstructure_checkノードを追加します。 workflow.set_entry_point( "structure_check" ) エッジの追加 次に、処理同士を接続するためにエッジを追加します。 workflow.add_edge( "structure_check" , "content_check" ) workflow.add_edge( "content_check" , "quality_check" ) workflow.add_edge( "quality_check" , "review_integration" ) workflow.add_edge( "review_integration" , "self_reflection" ) 条件分岐が入る部分については、条件付きエッジを定義します。 from langgraph.graph import END # 条件付きエッジの追加 workflow.add_conditional_edges( "self_reflection" , branch_on_reflection, { "continue" : "review_integration" , "end" : END}, ) ここでは、self_reflectionノードの処理の後、branch_on_reflection関数の戻り値によって次のノードを定義しています。 LangGraphでは組み込みでENDノードが用意されており、branch_on_reflectionノードの結果が"end"だった場合は処理を終了させます。 branch_on_reflection関数は以下の通りです。 def branch_on_reflection (state: State) -> str : """リフレクション結果に基づいてフローを分岐""" reflection_result = state.reflection_result if reflection_result.judgement == "NG" and reflection_result.retry_count < 4 : return "continue" return "end" コンパイルと実行 最後にここまでのワークフローをコンパイルして実行可能なインスタンスになります。 compiled = workflow.compile() これを以下のようにinvoke関数で実行することで処理が走ります。 article_content = {GitHubから取得した記事内容} initial_state = State(article=article_content) result = compiled.invoke(initial_state) ※GitHubとのやりとり部分（記事内容の取得とコメントの投稿）は、グラフの実行前後に行っています。 成果物について 本システムを動かした結果が以下となります。 こちらは、本記事（初稿段階）のプルリクエストに対するレビューコメントです。 やや冗長ですが、、必要な観点は抑えられているのではないでしょうか。 日付など一部指摘に誤りが見られる点は課題ですが、特に表記揺れや構成など、自分で気づけていなかった誤りを適切に指摘してくれています。 実際に今回の記事はこのレビュー結果を取り入れつつ作成しました。 なお、レビューコメントの投稿には GitHub Apps で作成した techblog-review を利用しています。 GitHub Apps を作成し、組織レベルでの管理とすることで、アクセス権を限定し、特定のユーザーに依存せずにシステムを運用することができます。 参考 GitHub Apps の作成や認証方法については、以下の記事を参考にしました。 組織アカウントで作成する場合は、各種 ID やシークレットをリポジトリオーナーに発行してもらう必要がある点にご留意ください。 組織の管理者でもない僕が、組織のプライベートリポジトリにGitHub Appsを使ってPRでreviewdogにコメントさせるまで GitHub Appを使ってGitHub APIを叩く (Python) 今後の期待 今回まずは試作としてテックブログレビューエージェントを作成しましたが、まだまだ改善すべき点は多くあります。 個人的には、例えば以下の点についてアップデートをしていきたいと考えています。 出力精度(品質)の向上 処理フローの改善 統合結果だけでなく各レビューに対してもセルフリフレクションを取り入れる 記事内容に基づいて対象読者（ペルソナ）を作成し、ペルソナの視点からレビューを行う 内容チェックでWeb検索を取り入れ、類似記事の参照や比較ができるようにする レビューにSEO観点を取り入れ、検索流入を意識したキーワードやタイトルの提案を行う プロンプトの改善 出力の冗長さの改善 「文章の品質」の部分に関しては全体コメントの中ではなく以下例のようなSuggestion機能を利用したコメントをできるようにする プロンプトを改善し適切なフォーマットにする おわりに 本記事では、テックブログレビューエージェントの開発過程を紹介しました。 成果物としてのレビューコメントには課題もあるものの、適切な指摘が多く含まれており、今後社内で活用していけそうだと感じました。 また、今回の開発を通じてLangGraphやGitHub Appsなどの新しい技術に触れることができ、技術的なキャッチアップとしても貴重な機会となりました。 現在、本テックブログレビューエージェントはまだ実運用を行っていないため、今後は社内での運用を開始し、得られたフィードバックを反映しながら、継続的に改善していきたいと思います！

はじめに 実装関連 まとめと感想 参考文献 はじめに こんにちは。InsightEdgeのデータサイエンティストの小柳です。 本記事では昨年発売された『データ駆動型回帰分析　計量経済学と機械学習の融合』の3、4章を実装しました。 普段ノンパラメトリック、セミパラメトリックなモデルを組むことがほとんどないため、練習のようなものですが読者の方の参考になるところがあるかもしれません。 どの手法が実装時に重たそうかはぱっと見だとわからないので、実装することにも意義ががあるかなと思いました。 実装内容は以下です。 3章 カーネルを使った回帰、Nadaraya-Watson回帰、Local-Polynomial回帰、 バンド幅の最適化 シリーズ法回帰、シリーズ長の最適化 回帰不連続デザインによる平均処置効果(ATE)推定 4章 部分線形モデルとそのRobinson推定量 シングルインデックスモデルとそのIchimura推定量 回帰調整法、IWP法、Hahnの推定法、Hiranoの推定法によるセミパラメトリックATE推定 実装関連 公開しているノートブックは以下のリンクからColabで実行できます。 同じものを画面に埋め込んだものが以下です。実行はできませんが結果だけなら御覧になれます。 まとめと感想 コード化したことで、教科書で省略されているところを含め理解が深まりました。 全体的に用意したデータが結構単純だったため、さほど手法により回帰性能に差が出にくかったのは予想外でした。 また、ノンパラの部分で最適バンド幅を出したはずなのに適当なバンド幅と比べてもそこまで真の関数に近づかなかったのも意外でした。 セミパラの方でもATE推定の際に、どの手法でも大して値が変わらないかと思いきやHiranoの手法での推定値が他の値と大きく異なり、因果効果の推定の難しさを感じました。 参考文献 末石直也 データ駆動型回帰分析 日本評論社 2024 実装コードリポジトリ: https://github.com/submergedcube/non-semipara

こんにちは、Insight Edge開発チームの綱島です。 今回の記事では、私がここ最近従事しているプロダクト開発についてお話ししたいと思います。 一般的なプロダクト開発に関する有用な知識・ノウハウは世の中にたくさんありますので、少しテーマを絞って、「少数精鋭（≒限られたリソース）」のチームでプロダクト開発を進めるにあたって、重要だなと思うポイントをお話ししていきます。 Insight Edgeにおけるプロダクト開発 「少数精鋭」チームでプロダクト開発を進める際のポイント チーム全体で顧客理解を深める体制 「やらないこと」を明確にする優先順位付け 「型化」の余地を探り続ける さいごに Insight Edgeにおけるプロダクト開発 本題に入る前に、Insight Edgeにおけるプロダクト開発について触れておきたいと思います。 Insight Edgeは、2019年に住友商事グループのDX内製化組織として設立された会社で、各ビジネス“現場”における課題指向なアプローチを重視しています。そのため、以下のDX推進プロセス図のように、顧客やユーザーと対話しながら現場の業務課題を分析し、各顧客に合わせたアプローチでDXプロジェクトを企画・推進するケースが多いです。 DX推進プロセス ただ、最近では、さまざまな現場のDX案件を通じて蓄積された経験やノウハウをもとに、汎用的な課題に対応するソリューション/プロダクトを企画・展開する取り組みも生まれています。 その一例として、「カスタマーセンター×AI」をテーマとしたプロダクト『Voiceek』があります。企業のカスタマーセンターやCX部署に寄せられるVoC（顧客の声や問い合わせ）を、生成AIを活用して分類・分析・レポーティングするツールであり、BtoCの事業会社を中心にニーズがあるソリューションです。 Voiceekイメージ 本プロダクトに関する詳しい情報は こちら を参照ください。 about.voiceek.com 上記ようなプロダクトの開発・展開においては、まず少人数のチームを組成して取り組みを開始し、徐々にスケールさせることを目指しています。立ち上げ期の小規模チームの活動において重要だと感じるポイントについて、次章からお話ししたいと思います。 「少数精鋭」チームでプロダクト開発を進める際のポイント ここから本題ですが、少人数でプロダクト開発を進める場合、リソースが限られる分、チームの強みを最大限に活かし、効率的に動くことが求められます。そこで、実際の取り組みを通じて感じた重要ポイントを3つ紹介します。 チーム全体で顧客理解を深める体制 プロダクト開発には、カスタマーサクセス（CS） *1 、エンジニア、PM、デザイナーなど、さまざまなロールのメンバーが関わります。少人数チームでは、職種を超えてコミュニケーションを密にし、全員が顧客理解を深める体制を意識することが重要です。 実践のポイント エンジニアが顧客の声を直接聞く場を作る 通常、エンジニアはPMやCSを介して顧客要望を受け取ることが多いですが、それでは伝言ゲームのようになり、細かいニュアンスが失われる可能性があります。エンジニアが直接、顧客との打合せやイベント（展示会など）に参加することで、ユーザーの実際の課題や使い方を肌で感じることができ、プロダクトに反映しやすくなると思います。 上段でご紹介したVoC分析ツール『Voiceek』においても、当該ポイントを実践することで、エンジニアの顧客理解度が高まり、CSやPM等のフロントメンバーとのコミュニケーションがスムーズになっていると感じています。 PMとCSを一体化させて顧客課題の共有を円滑化 これは立ち上げ時期ならではの取り組みかもしれませんが、PMロールと、CSロールを一体化することで、迅速な意思決定やフィードバック対応が可能になると思います。 一般的にPMはプロダクト導入におけるプロジェクト推進を担当し、CSは顧客の利活用支援や問い合わせ対応を行いますが、立ち上げ期においては、これらの役割を統合することで、顧客からの問い合わせやフィードバックをリアルタイムで共有し、プロダクトの改善スピードを加速させることができ、メリットがあると感じています。 「やらないこと」を明確にする優先順位付け 少人数チームでは、すべての要望に応えることは現実的ではないため、リソースを最適化するために、「やること」だけでなく「やらないこと」を明確にすることが不可欠です。 実践のポイント 「ないとどうなるか？」を整理し、必須要件を絞り込む 開発機能を選定するにあたっては、「この機能がないとどのような影響があるのか」を具体的に評価することが重要だと思います。「ユーザーが目的を達成するために必須の機能であるか」、「他の手段で代替できるか」といった視点で検討しながら、リソースの状況と機能の価値とのバランスを考慮することがポイントになります。 ニーズを複数回深掘りして、本当に必要な機能をあぶり出す ユーザーの要望をそのまま受け入れるのではなく、「なぜその機能が必要なのか」を繰り返し問い直すことが大切です。表面的な要望の背後には、より根本的な課題が隠れていることが多いため、何度も掘り下げていくことで本質的なニーズを特定できます。この問い直しを通じて、実はA機能ではなくB機能のほうが適しているというように、本質的なニーズを基にした機能を開発することができます。そして、提供者とユーザー双方にとってWin-Winな結果につながると思います。 「型化」の余地を探り続ける プロダクト開発に限らず言えることですが、限られたリソースを有効活用するため、個別対応が必要な部分とテンプレート化できる部分を適切に切り分け、継続的に効率化を図る意識が重要です。 実践のポイント よくある問い合わせのFAQ化 まず、ユーザーからの頻出質問をFAQやガイドラインとして整理し、可能な限りサポートの負担軽減を図りたいところです。仮にユーザー向けに公開しない場合でも、チーム内のメンバーが「誰でも」「迅速に」「同一の品質」でユーザー対応できる仕組みを構築することで、サポート業務の効率化につながります。 トライアルや事前検証フェーズのテンプレート化 プロダクトのトライアル期間は、顧客が導入を決定する重要なプロセスですが、個別対応が多くなりがちです。そのため、トライアルにおける顧客満足度とリソース配分のバランスを考慮しつつ、共通ステップを定め、ガイドラインなどを整備することが重要と感じます。 さいごに 少人数チームでのプロダクト開発を通して重要性を感じたポイントとして、３つ（「チーム全体で顧客理解を深める」「やらないことを明確にする」「型化の余地を探り続ける」）の視点を紹介してきました。 今後は、こうしたフェーズを経て、プロダクトをスケールさせていくための戦略についてもまとめていきたいと考えています。 なお、Insight Edgeでは本記事で言及しているようなプロダクト開発から、個別具体のビジネス現場におけるDX案件等、様々なプロジェクトを経験できます。興味がある方は、カジュアル面談から是非お気軽にお問い合わせいただければと思います。 最後までお読みいただきありがとうございました。 *1 : カスタマーサクセス（CS）：提供する製品やサービスを顧客が最大限に活用し、成功体験を得られるようにサポートする役割。

はじめに こんにちは、Insight Edgeでソフトウェアエンジニアをしている田島です。 入社から1年と少しが経過し、一貫して、生成AI関係のプロジェクトに携わっています。 その中の1つとして、RAGの精度向上のための施策をしており、ドキュメント解析のライブラリを開発したので、その内容について紹介します。 RAGの精度向上 はじめにRAGとは、Retrieval-Augmented Generationの略で、検索結果を元に文章を生成する技術を指します。 プライベートなドキュメント情報を比較的容易にLLMに入力できるため、多くのケースで活用されています。 実際にInsight Edgeでも、RAGを用いた複数のアプリを住友商事グループ向けに提供しており、その精度向上のために様々な施策をしています。 LLMのロングコンテキスト化している現在においても、データソースが大規模であるケースや精度面の利点などから、依然としてRAGの重要度は高いです。 RAGの精度向上には、おおまかに 検索結果性能 と 生成部の質向上 の2つの改善手法があります。 検索結果性能の向上には検索エンジンの改善やデータソースへのメタデータ付与、 生成部の質向上にはプロンプトエンジニアリングや エージェントアーキテクチャの採用 などの施策が考えられます。 ここでは前者の中でも元データの前処理に関する施策について紹介します。 問題:検索が困難なデータソース マルチモーダルLLM の登場により、RAGの検索対象となるデータソースは多様化しています。 画像をマルチモダールLLMに入力することで、画像に関する情報を自然言語で抽出することが可能になりました。 ただし、前段で検索にヒットさせる必要は依然あり、検索が困難な場合は上述のご利益を享受できません。 一般的に、データソースが非構造化データ（PDFやWordなど）の場合は、テキスト抽出したものを検索対象にすることが多いです。 ただし、レイアウト情報が複雑なPDFや、画像だけで構成されたPDFでは、単純なテキスト抽出だけでは不十分な場合が多くあります。 ※ 2025/1時点で画像とテキストの両方を同一のベクトルにする方法多くはありません。 ドキュメント解析ライブラリの開発 Insight Edgeでは住友商事グループの様々な業種向けに技術支援しており、個々のドメインに対するドキュメント処理が必要になります。 一方で、ドメインごとに技術開発をするリソース確保は難しく、汎用的に利用できるドキュメント解析ライブラリを開発する必要がありました。 ライブラリの想定ユースケース ドキュメント解析ライブラリのユースケースは以下になります。 データソースが大規模でRAGが必要となるケース データソースに図表やフローチャートなどの非構造データが含まれ、OCRのみでは対応できないケース ドキュメント解析ライブラリ「Exparso」 📑 対応ドキュメント 本ライブラリでは以下のドキュメントをPDF化した上で、マルチモーダルLLMによる解析をします。 今後、HTMLや動画ファイルなどの対応も予定しています。 コンテンツタイプ 拡張子 📑 ドキュメント PDF, PowerPoint, Word 🖼️ 画像 JPEG, PNG, BMP 📝 テキストデータ テキストファイル, Markdown 📊 表データ Excel, CSV インストール 以下でライブラリをインストールします。 ※現在は開発中のため、PyPIには公開していません。弊社プライベートレポジトリのみの公開となります。 pip install exparso Officeドキュメントを解析するために libreoffice をインストールしておく必要があります。 # Ubuntu sudo apt install libreoffice # Mac brew install --cask libreoffice 使い方 コードは以下のように利用します。 model はLangChainの BaseChatModel を継承したクラスを指定し、 context は解析対象のドキュメントに関する説明を入力します。 from exparso import parse_document from langchain_openai import AzureChatOpenAI llm_model = AzureChatOpenAI( "gpt-4o" ) text = parse_document( path= "path/to/document.pdf" , model=llm_model, context= "このドキュメントは..." ) 対応LLM マルチモーダルLLMの実行方式はLLMによって異なるため、 BaseChatModel を継承したLLMにおいても限られたモデルのみに対応しています。 AzureChatOpenAI, ChatOpenAI ChatVertexAI ChatAnthropic, ChatAnthropicVertexAI アルゴリズム アルゴリズムで現時点では簡易的なもので、ページ毎に以下のフローでドキュメントを解析します。 アルゴリズムフロー ドキュメント種別の判別 ドキュメントのプロパティを取得し、テキストのみの場合は次のページの処理に進みます。 利用トークンの節約のために画像を圧縮したうえで、マルチモーダルLLMによる判別をします。 各プロパティに即したプロンプトを生成し、マルチモーダルLLMに入力します。 言語 グラフ テーブル 画像 ページテキストの読み込み ドキュメントのメタ情報を含むコンテキスト情報と、ドキュメントのプロパティを反映したプロンプトを作成します。 このプロパティとページ内容をマルチモーダルLLMに入力し、ページ内容を取得します。 以下、プロンプトの例です。 あなたは画像から文書を読み取る専門家です。与えられた画像の内容を正確に書き起こしてください。 ## Constraints - ユーザーが文章を入力します。ドキュメントをより正確にするために修正してください。 - 画像に存在しない内容は回答しないでください。 - Document Type はデータを読み込むときの参考情報として提供されます。 - Document Context はドキュメントの参考情報として提供されます。 ## Document Type ### Text - 画像内のすべてのテキストを正しく抽出してください。 ### Flowchart - フローチャートの情報を説明してください。 - フローチャートをMermaid形式に変換してください。 - 出力にフローチャートの概要を追加してください。 #### Example - Input: ケーキ作りのプロセスを示すフローチャート。 - Output:このフローチャートはケーキ作りのプロセスを示しています。 (略) コンテキスト情報の更新 読み込んだテキスト内容から、コンテキスト情報を更新します。 トークンの節約のため、内容が5-7文程度に収まるようにしています。 評価 ライブリの評価フローも構築しており、以下のフローでLLM-as-a-Judgeにて評価します。 ライブラリの出力をコンテキスト情報として、質問に対する回答を取得 回答を正解データと比較し、評価結果を取得 評価フロー 評価データセット データセットは以下の属性を持つデータ群(PDFファイル)を用いています。 属性 詳細 フローチャート 手順書、アルゴリズム設計書 グラフ 棒グラフ、円グラフ、折れ線グラフ テーブル 単純テーブル、結合テーブル 要OCRテキスト 手書きテキスト、非構造テキスト、デジタルデータのスクリーンショット フローチャートとテーブルの例を以下に示します。 フローチャートの例 テーブルの例 参考: 【フローチャートの例】出典：営業時間短縮に係る 感染拡大防止協力金 - 東京都( https://www.town.nishiaizu.fukushima.jp/uploaded/attachment/7016.pdf ) 【テーブルの例】出典：デジタル社会の実現に向けた重点計画( https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/5ecac8cc-50f1-4168-b989-2bcaabffe870/b24ac613/20230609_policies_priority_outline_05.pdf ) 質問データセット 質問内容は一問一答&クローズド形式とし、1つのデータセットにつき複数の質問を用意します。 現在は手動で作成していますが、将来的には自動で生成する予定です。これにより、任意のデータ群に対して、容易に評価を行えるようになります。 ex. Q. フローチャートにおけるAからBへの矢印の意味は？ A. APIリクエスト ex. Q. テーブルの中でも最も身長が高い人物は？ A. Aさん ベンチマーク対象 Azure Document Intelligence pymupdf4llm : pymupdfを用いたドキュメント抽出ライブラリ、OCR対応はなし docling ：ドキュメント解析ライブラリ、テーブル抽出に強み、日本語OCRは非対応 結果 以下は Exparso を gemini-1.5-pro-002 で実行した結果です。データセットの属性毎に、正解率を示しています。 評価結果 結果から、以下のような特徴が確認できした。 フローチャートやカラフルな図表などのハイコンテキストなデータを読み込み 折れ線グラフや円グラフのテキスト化 一方で以下に課題がある状況です。 紙面に情報量が大きい場合の出力安定性 マルチモーダルLLMのトークン節約 今後の展望 Exparso は、今後も機能追加や精度向上を目指す予定です。その上で、OSS化を進める予定です。 OSS化について 2025年1月現在、本ライブラリはInsight Edge社内のプライベートレポジトリに配置し利用を限定していますが、OSS化を検討しています。 OSS化することで他社や個人の方にも活用してもらい、多くのフィードバックを得られると考えています。 実際にMicrosoftも　 同様のライブラリ をOSSとしてリリースしており、SNS上で大きな反響が確認されました。 さらに、コミュニティ運営を正しく行うことで、Insight Edgeの採用や会社の認知度向上にも繋がると考えています。 近日OSSとしてリリースする予定なので 、ご興味がある方はぜひ開発への参加やFBをいただけると幸いです。 ✅ 2025/05/30 追記：OSSとして公開しました！ この記事で紹介したツール／ライブラリを、GitHub にてOSSとして公開しました。 実際のコードや利用方法、セットアップ手順などは以下のリポジトリをご覧ください。 👉 GitHub リポジトリ: https://github.com/InsightEdgeJP/exparso もし使ってみてフィードバックやアイデアがあれば、Issue や Pull Request 大歓迎です！ 引き続き改善・発展させていければと思っています。

こんにちはCTO猪子です。年も開け、2024年度もそろそろ後数ヶ月を残すのみとなってきました。一年間もあっという間ですね。 会社によっては4月から入社する新卒採用の受け入れ準備真っ只中な人たちもいるのではないでしょうか？弊社でも今年の4月から初めての新卒の受け入れ準備を進めています。 本記事ではなぜ新卒採用を始めたか？そして、新卒の受け入れに向けてどの様な準備を進めているかの概要をご紹介します。他の企業で今後新卒採用を始めようとしている方の参考になれば幸いです なぜ新卒採用を始めるのか 現在弊社のエンジニアは大体40名ほどいますが、その全てが中途採用、若しくは住友商事関連会社からの出向者で占められており、新卒採用者は0です（一部業務委託の方もいます）。現在、弊社は設立から5年経過しており、過去新卒採用を検討した時期もあったのですが、検討の結果取りやめています。理由は 「採用、育成コスト」 です。 設立初期〜数年は人数も少なく、その少ない人数の中で案件をQCD最適な状態で進め、実績を積み重ねていく事が最重要でした。その中で新卒採用にかけられるコストが限定的になるのであれば、受け入れる新卒メンバ・我々相互が不幸になると考え、しばらく新卒採用は実施していませんでした。 その後、新卒採用に踏み切った理由と新卒採用活動については、 こちらの記事 に弊社合田が執筆しているのでご参照下さい。 新卒の受け入れ準備 ここからは主に新卒入社後の受け入れ、特にスキル要件・育成メニューの整備についてフォーカスして説明したいと思います。 スキル要件・育成メニューの整備に於いて実施したのは、以下のステップです。 ゴールの設定 スキル要件の定義 教育メニューの設計 ゴールの設定 先ずはゴール設定です。今回採用するのは開発エンジニアとデータサイエンティストなので、それぞれの短期（1年後）・中期的（3年後）に期待する役割・スキルのイメージを設定します。 ※3年以上の長期でのゴール設定は不確定要素が高いため設定しませんでした。 例えば以下の様なものを設定します。 1年後：レビュを受けながら開発業務を自律的に遂行することができる 3年後：テックリード（技術責任者）として、各プロジェクトの技術的な意思決定者としての役割を果たすことができる このゴールは企業によっても異なりますし、職種によってももちろん異なるので、組織の戦略等に紐づけて設定する必要があると思います。 若しくは以下の図の様に育成コストが貢献価値（利益）を上回る = 1人前のエンジニアとなるレベルをゴールとするという考え方も良いかと思います。 ※今回は3年後が1人前のエンジニアとなる想定でゴールを置きました。 育成コストと貢献価値のバランス スキル要件の定義 次に、設定したゴールに必要なスキル要件を詳細に定義します。 Insight Edgeでは、国内外の様々なスキルフォーマットを参考にスキル要件を定義しました。 スキル要件 = スキル項目 x 段階的な基準 となるので、先ずはスキル項目の定義・分類から開始します。 スキル項目の定義 スキルの分類ですが、”テクニカルスキル”、”ポータブルスキル”、”スタンス・マインド”の3種類で各分類毎に要件を細分化していきました。ベースとなるのはスタンス・マインドです。意思決定の一貫性・迅速性や、組織文化の根幹となるものを基本とし、そこからポータブルスキルを紐づけて整理していきました。ポータブルスキル、スタンス・マインドは職種横断的なスキルになっています。 ここに企業として独自の要素を加えていきます。例えば、Insight EdgeがターゲットとするプロジェクトはPoCがメインの為、少人数でコミュニケーションコストを減らし迅速にプロジェクトを推進することが求められます。そのため、テクニカルスキルについてはマルチスタックなエンジニアとしての項目を定義しています。 このあたりは企業の特性が出る部分になるかと思います。 スキル分類のピラミッド さらなるスキル項目詳細化に於いては主にIPAの デジタルスキル標準v1.2 を参考にしています。デジタルスキル標準はIT業界のスタンダードであり、スキルの洗い出しが漏れなく検討出来る事もメリットですが、今後他社の教育サービスを活用する際にも対応関係が取りやすい事も利点と考えています。又、今後メンバがInsight Edgeを卒業して他社に転職する際にも同様のフォーマットを活用出来る可能性が高いので、出来るだけデファクトに合わせるのが良いと考えています。 デジタルスキル標準内では有り難いことにロール（職種）、スキルリスト、及びその対応例が整理されているので、これを参考にInsight Edgeとしてのスキル項目詳細をまとめています（これを無料で提供してくれているIPAに感謝です！）。 尚、デジタルスキル標準の”ビジネス変革”、”データ活用”、”テクノロジー”、”セキュリティ”を”テクニカルスキル”、”パーソナルスキル”を”ポータブルスキル”にマッピングしていますが、網羅的に定義されたスキル項目全てを取り込むのはToo Muchなため、必要なものをピックアップし独自のスキル項目一覧として定義しました。 このあたりのスキル項目定義は元々概要として整理はしていたのですが、今回の新卒採用にあたり、詳細分類を精緻化しています。 参照：デジタルスキル標準ver.1.2（概要編）： https://www.ipa.go.jp/jinzai/skill-standard/dss/t6hhco0000011cr5-att/gaiyou.pdf P11 参照：デジタルスキル標準ver.1.2（概要編）： https://www.ipa.go.jp/jinzai/skill-standard/dss/t6hhco0000011cr5-att/gaiyou.pdf P12 参照：デジタルスキル標準ver.1.2（概要編）： https://www.ipa.go.jp/jinzai/skill-standard/dss/t6hhco0000011cr5-att/gaiyou.pdf P13 各スキルカテゴリ内のスキル詳細は 共通スキルリスト 内に定義されています。 ここ最近で外せないのは 生成AI に関する項目でしょう。最新版のデジタルスキル標準v1.2には生成AIに関する学習項目も記載されており、これを元に生成AIに関するスキル項目も定義しています。 スキル要件としての基準の整理 項目として整理した後は要件として定義するために、習熟の基準を定義していきます。これまで存在しなかった新卒向けの基準を主に定義しています。 以下はポータブルスキルの一部抜粋ですが、各スキル毎にレベル（基準）と達成条件を記載して行きます。 スキルのレベル（基準）と達成条件例 教育コンテンツの整備 スキル要件が定義出来たら教育コンテンツの整備です。各スキル要件の基準、達成条件を満たすために必要な書籍、研修をリストアップしていきます。研修は既に社内で外部向けに作成してあったものもあったので、社内の資産も活用しつつ、推奨図書や推奨外部研修（Udemy等）については社内メンバのおすすめを集めるとともに、外部評価が高いものについては自分含む研修コンテンツ整備担当者が全て一読・受講し、評価して推奨リストに加えていきました（結構たいへんですが協力して読了しています！）。 ポータブルスキル推薦図書一覧 ただ、コンテンツについては準備コストはかかりますが出来るだけ社内で講師を募るようにしています。複数の講師を募ることで、新卒育成を全社で取り組む文化の醸成に繋がりますし、新卒メンバが既存メンバと自然に接点を持つ効果が出てくることを期待しています！ その他の準備 ここまでスキル要件・育成メニューについて実施した内容を解説しました。ただ、育成環境における準備はこれだけでは有りません。 その他、育成計画の策定方法、新卒育成におけるメンター・上長の役割定義等も合わせて定義しています。 現在は4月から開始する新卒研修スケジュールの策定や、実際のメンターとの役割のすり合わせを実施しているところなので、結果については別記事で纏められればと思います。 まとめ ここまで読んで頂きありがとう御座いました。新卒社員にとって、最初の教育はその後の成長を大きく左右します。効果的な教育コンテンツは、単なるスキルの習得だけでなく、チームや企業へのエンゲージメントを高める重要な要素です。当社では、個々の成長を支援する教育プログラムを通じて、新卒社員が自らの可能性を最大限に発揮できる環境を提供したいと考えています。 総合商社の幅広いドメイン領域で「共に成長し続ける人材になりたい」と考えているあなた。ぜひ、私たちと一緒に新しい一歩を踏み出しましょう！先ずはカジュアル面談からお気軽にお問い合わせ頂ければと思います。

デザインシンカー、そしてワークショップデザイナーの飯伏です。 「デザインシンカーってなんだ」と思った方は、前回のブログをぜひご覧いただけるとうれしいです！ techblog.insightedge.jp さて、今回はワークショップについて書いていきます。 というのも、昨年 ワークショップデザイナー育成プログラム - 青山学院大学 （通称：WSD）を受講し、ワークショップを学び直した結果、タイトルにある「ワークショップとは、付箋とペンを持って集まればいいわけじゃない」ということを改めて伝えたいと想ったからです。 この想いと内容については、実はWSDの最終課題でまとめていまして、今回はそのレポートを加筆更新してお送りします。 *1 ワークショップとは何か？ 普段の仕事の中では「AIを使う方法を教えてほしいのでワークショップを…」「技術活用のアイデア出しをワークショップで…」「組織の意思疎通を図るためワークショップを…」といった相談から、ワークショップ実施を検討することが多いです。 それらのワークショップとは「付箋とペンを用意して、フリーディスカッションすればOK」と考えている方が多いかもしれません。ワークショップの定義に正解があるわけではなく、それも一つの答えと言えます。 しかし、ワークショップは実はもっと奥深いものなのです。筆者がワークショップデザイナーとして学び、実践する中で考えた「ワークショップとは、付箋とペンを持って集まればいいわけじゃない」を題材に、今回はワークショップのゴール・目的とは何か、ワークショップを構成する場面は何か、参加者視点とデザイナー視点から見たワークショップの特徴や専門性とは何かを説明します。 なお、ワークショップについては、いろいろな先生方が書籍や講義でご説明くださっています。それらを学びつつも、ここではあくまで飯伏が仕事をする中で考えるものとして説明します。そこからワークショップの本質と魅力の一端でも伝われば嬉しいです。 ワークショップのゴール・目的 まず、ワークショップのゴール・目的について説明します。 ワークショップ当日のゴールは、情報やノウハウを一方的に伝達するだけではなく、参加者同士の会話や作業をとおして、次の３つを実現することと考えています。 発散：特定のテーマに対する新たな気づきを得たり、アイデアを発想したりする 収束：参加者から持ち寄られた意見をまとめたり、重要な事柄を抽出したりする 合意形成：発散や収束の成果を「みんなで考え出した、その場での答え」として合意する また、ワークショップの目的は、前述のような“ワークショップ当日のゴール”の達成だけではなく、その後の（個人や企業の）判断や行動や習慣に、より良い変化を起こすことと考えています。 冒頭のWSDで学んだ言葉を用いると、ワークショップは「〇〇を創ることで（活動目標）、〇〇を学ぶ（学習目標）」という2つの目標を持っています。活動目標が非日常的かつ内発的な楽しさを持つものであり、学習目標が参加者にとって日常的に意味をもたらすもの（他者理解、合意形成、仲間づくりなど）です。 具体的なゴール・目的は依頼内容などで異なるものの、当日とその後、活動目標と学習目標といった2つの視点が重要になっています。 参加者視点：ワークショップの特徴 次に、ワークショップに参加する側から見た特徴を整理してみましょう。 1. 参加・体験・相互作用 ワークショップでは、プログラムの進行役と活動主体の参加者がいるだけで、一方的に教える先生や講師はいません。そのため、自ら主体的にプログラムに【参加】していく姿勢が必要です。 また、言葉を使って頭で考えるだけでなく、①やってみる②観てみる③考えてみる④まとめる・次を考える、という循環した【体験】での学びを重視されます。 そして、体験を共にしたり、喧々諤々しながら意見をすり合わせたり、感じたことをシェアリングしたりすることで他者から学びあう【相互作用】が起こります。 情報を受け取るだけの講義とは異なり、参加者が自ら意見を出し合い、手を動かし、他の参加者と協力・衝突しながら創造する。この過程が、新しい学びを生むのです。 2. 非日常、よろこびがある ワークショップでは、普段とは異なるメンバーや関係性、テーマやアプローチ、環境や状況で取り組む【非日常】が大切です。 たとえば、普段とは異なるメンバーや関係性で取り組んだ場合、同じ会社の中でも様々な視点や価値観に触れることができたり、日頃は隠れている「実は想いが違っていた」「意外に考えが同じだった」などに気づけたりすることができます。 他にも、普段とは異なるテーマやアプローチとして、紙飛行機を使ったワークで社会人が無邪気に盛り上がり、自己開示が進んだ実施経験もあります。 このような、新しい発見や合意形成、日常と違う体験によって得られる【よろこび】も特徴です。 3. 日常に変化をもたらす ワークショップの意義は、非日常の場限りのよろこびにとどまりません。参加者が得た学びを日常生活や仕事に生かし、行動や考え方など【日常に変化をもたらす】きっかけとなります。 これは、参加・体験・相互作用により、「自分たちが考えた・作った納得した答え」「自分がその答えの一部」といった当事者意識が非常に高まるためです。 デザイナー視点：ワークショップの背後にある専門性 さらに、ワークショップデザイナーの視点から、その背後にある専門性を整理します。 1. プログラムデザイン ワークショップデザイナーは、当日の目に見える成果物だけではなく「何を学ぶか」というコンセプトから決めます。そこでの目標から逆算してメインワークを考え、前後の流れを組み立てます。 そのうえで、安心・安全性を担保するための仕掛けや、参加者の協働を増幅するための仕掛けを足し引きします。 これらのデザインによって、安心・安全な場で対話が深まり、共創や協働が促進されるのです。 2. ファシリテーション ファシリテーターは、ただ予定していたプログラム通りに進行する存在ではありません。場の観察しながら、状態を見極め、適宜追加説明したりプログラム自体をテコ入れしたりします。 元々の目標に向かって参加者同士で自走できるような状態に持っていけるよう、リアルタイムにプログラムをその場にフィットさせていく存在なのです。 ワークショップのまとめ 参加・体験・相互作用、非日常とよろこび、日常に変化をもたらすなどの特徴があり、その価値をしっかりと発揮するためには、プログラムデザインとファシリテーションを「そこまでやるか」というくらい考え抜き、妥協せずに行う必要があります。 プロのワークショップデザイナーが準備を整えたワークショップは、参加者にとって簡単で楽しいものに見えます。ワークショップに参加する機会があれば、その裏側にある努力を感じ取りつつ、難しいことは考えずにぜひ積極的に楽しんでください！ Insight Edgeでの事例 前回のブログでも書いていましたが、ChatGPTの活用アイデアを発想するためのツールとワークショップを作っています。 具体的にはChatGPTを3系統9種類のキャラクターとして擬人化したカード＝ChatGPTキャラクターカードと、それを材料に業務での活用アイデアを発想するワークショップを企画・設計・作成しました。 ワークショップとしては様々な進め方がありますが、例えば「参加者が普段やっている業務」×「すべてのキャラクター」の組み合わせを土台に、参加者全員で強制発想に取り組むことをしています。 ご興味がありましたら、ぜひお問い合わせください！ ChatGPTキャラクターカード さいごに 前回のブログ時点では、 テックリプログラム - Technology Creatives Program という東京科学大学・多摩美術大学・一橋大学で組成する教育プログラムの経験や学びについて記載しようと考えていましたが、これは別メンバーが書く予定なので変えました！こちらはこちらでぜひお楽しみに～。 それでは、また。 *1 : WSDの講義・授業を受けて学んだこととしてまとめているため、刈宿先生や中尾根先生など、様々な先生からお教えいただいた言葉・用語を使わせていただいています。

こんにちは！Insight Edge リードコンサルタントの山田です。本記事では住友商事グループの生成AI活用における直近の取り組みをご紹介できればと思います。過去に 2023年9月の記事 でもご紹介していますが、そこから約1年が経過し、Big techを中心にグローバルでの凄まじい技術進展もさることながら、住友商事グループでの活用度合いもかなり高まってきています。是非最後までご覧いただけると幸いです。 （ちなみに本記事が弊社テックブログの100記事目らしいです。めでたい！） 総合商社×生成AI活用の２年半 生成AI活用に関する最近のトレンド 業務効率化のためのRAG活用は一巡、事業開発や価値創造のユースケース創出にシフト PoCフェーズから、実現効果創出のフェーズ 住友商事グループの生成AI活用 Copilot for Microsoft 365のグローバル全社導入 社内FAQやナレッジDBの共通UI化 経営の意思決定支援ツール 今後の展望 おわりに 総合商社×生成AI活用の２年半 2023年3月にGPT-4がリリースされて以降、Insight Edgeが手掛けるプロジェクトのうち生成AI関連の案件数は継続して増え続けています。住友商事ではグループ内の生成AI CoE組織として「SC-Ai Hub」が2023年5月に発足し、Insight Edgeはそのコアメンバーとして、これまで累計相談140件以上、プロジェクトも40件以上実施してきました。 グループ事業会社の経営層や担当者と日々接する中でも、生成AI活用に関する話題や相談はとても多く、これまで経営層・役職員向けのセミナーやワークショップも多数実施してきました。特に、経営トップが生成AI活用に強くコミットする事業会社も増えており、1年前とは比較にならないほどの変化を実感しています。 昨年度は多くの企業がPoCに取り組むフェーズでしたが、今年度はPoCを超え、本格的なビジネス価値の創出を目指す動きが加速しています。特に、個人レベルの生産性向上を目指すアプローチから、業務特化型の生成AIツールの開発へと進化している点が大きなポイントです。 生成AI活用に関する最近のトレンド 住友商事グループだけでなく日本企業全体で生成AI活用度合いは高まっています。PwC Japanが公開している 「生成AIに関する実態調査2024春」 によると、自社で生成AIを活用中・推進中・検討中の企業の割合は24年春で90%を超えており、約20%だった1年前と比較すると、企業への浸透レベルは着実に高まっています。 住友商事グループでも体感として同等以上の各社関心度ですが、個人的な直近のトレンドとしては以下２点あるかなと思います。 生成AIに関する実態調査2024 春 | PwC Japanグループ 業務効率化のためのRAG活用は一巡、事業開発や価値創造のユースケース創出にシフト 後述の事例紹介でも触れますが、生成AI活用のユースケースは個人レベルの業務効率化から始まり、徐々に組織・ビジネスレベルでの活用にシフトしてきました。また、組織・ビジネスレベルでの活用においては、社内情報も組み合わせて回答を生成するRAG（Retrieval-Augmented Generation）の活用が多くを占めています。 （余談ですがRAGという言葉も、デジタルやITを主務としていないビジネスサイドでも理解している方が増えてきており、マス層への浸透を実感しています） このニーズは今後もしばらくは継続し、キャズム理論でいうアーリー/レイトマジョリティにも一気に普及していき、標準機能として各業務に組み込まれていくと思います。 一方で、イノベーターやアーリーアダプター層においては、RAGによる単なる情報検索のようなユースケースは良くも悪くも新鮮さが無くなり、社内の業務効率化に閉じない、事業開発や価値創造のユースケース創出にシフトしていると感じます。例えばコンタクトセンター業務の場合、生成AIによる顧客問合せ対応の半自動化/効率化、収集したVoC（Voice of Customer）の分析、そこから見える改善アクションの提案といった、業務プロセス全体にわたって生成AIを適用することで、顧客満足度向上や業務品質向上が期待できます。さらにはそれをトータルパッケージとできると、それ自体が新しいサービスになる可能性もあります。 業務プロセスの一部分に対する活用から、今後は業務プロセスやビジネスモデル全体への適用、ひいては最初から生成AIベースでの業務設計やBPRなども増えてくると思われ、より広範な活用が進んでいくと思います。 PoCフェーズから、実現効果創出のフェーズ Insight Edgeではこれまで数多くのプロジェクトを実施し、住友商事や事業会社向けに複数の生成AIシステムを本番導入しています。昨年度までは、ある意味で先端技術としての生成AIをいちはやく業務に取り入れることにも一定の価値があり、それによるポジティブな効果を期待して導入を進めてきた面も一部ありますが、今後は導入後の定量的な実現効果も示していくことが経営層からより求められるようになってきていると感じます。 ユースケースによっては定量効果を試算することが難しいケースもあり、いかに数字としてビジネスインパクトを生み出していくかが重視されるようになっていると思います。 住友商事グループの生成AI活用 これまで実施してきたプロジェクトを一部ですが類型化したものが以下の図になります。縦軸に個人レベルの用途か業務/ビジネスレベルでの用途か、横軸に業務効率化か新規ビジネス創出かでユースケースをプロットしています。当初は下側の個人レベルの用途からはじまり、次第に上側にシフトしてきています。具体的な活用事例もいくつかご紹介します。 住友商事グループにおける生成AI活用ユースケース Copilot for Microsoft 365のグローバル全社導入 個人単位での生成AI共通インフラとして、住友商事ではCopilot for Microsoft365を日本企業で初めてグローバル全従業員向けに8.800ライセンスを配布しました。社内での活用促進や啓蒙活動といった、入れて終わりではなく、日常的に使ってもらい、効果を創出していくための各種施策や伴走支援等も、住友商事のIT企画推進部やMicrosoft等と連携しながら取り組んでいます。 www.microsoft.com 一方で、Copilot for Microsoft365は強力なツールであるものの、あくまで汎用ツールの位置づけであり、それだけでは完結しない複雑な要件や業務特化のソリューションが必要なケースも多くあります。そのようなユースケースにおいては、Insight Edgeが企画構想から参画し、技術検証やプロトタイプ開発を行い、本番導入まで一気通貫で支援しています。 住友商事グループではこのような特定用途にしたバーティカル（垂直）な活用と、従業員が日常業務で利用するホリゾンタル（水平）の２つの観点で生成AI活用を推進しており、特にInsight Edgeが注力するバーティカル観点のユースケースをいくつかご紹介します。 社内FAQやナレッジDBの共通UI化 生成AIの代表的なユースケースの一つに、RAGによるFAQチャットボットや業務ナレッジデータベース構築があります。Insight Edgeでもこれまで複数の生成AIベースの情報検索チャットボットの構築を行ってきました。一方で、クラウドサービスやOSSを含め、従来よりも簡易にRAGシステムを構築できるようになってきており、エンジニアを介さずともビジネスサイドで簡易なRAG構築ツールを提供すれば、業務特化型の生成AIツールの開発がより加速するのではないかと考えています。 また、元々社内には各部署がそれぞれ用意・提供する様々なFAQチャットボットが点在しており、ユーザーから見るとどのチャットボットがどこにあるかが分かりづらいことが課題となっていました。そこで、それらチャットボットを共通UIから利用でき、ユーザーは適切なチャットボットを選択あるいは自動振り分けにより質問ができる仕組みも検討しています。 簡易にRAGシステムを作る機能と、それを共通UIで全社員が利用できる機能を持った基盤システムの構築を進めています。 共通UIと簡易RAG構築基盤のイメージ 経営の意思決定支援ツール 総合商社のビジネスモデルとして、多角的な事業ポートフォリオの構築とグローバルでの事業投資が肝であり、他業界と比較して投資機会が非常に多く、投資対象も多岐にわたります。それゆえ投資判断を行う全社投融資委員会も頻繁に行われており、社内には過去の委員会における数十年分の議事録が蓄積されていました。言うなれば住友商事グループの投資活動のエッセンスが詰まっており、この情報を生成AIで有効活用することで、投資意思決定のサポートツールができないかと、検討を開始しました。 23年度からリスクマネジメント組織とPoCを実施し、①議事録の検索、②議事録内容の深堀、③議事録の論点抽出の３つの機能を有するプロトタイプを開発し、実用性検証を行いました。ユーザートライアルを経て本番導入が決まり、現在商用システムとしてのUI/UXの磨き込みも含めたシステム開発を進めており、25年1月にリスクマネジメント組織向けにリリース予定です。今後も継続的な機能拡張を予定しており、意思決定支援ツールとしてブラッシュアップし続けていきます。 投融資委員会の議事録検索ツールのイメージ 意思決定支援の活用ではほかにも、日々世界中で生じる地政学上のイベントに対して、関連する社内外のデータソースを収集し、カントリーリスクレポートを自動生成するシステムも開発・運用しています。このような情報のキュレーションとレポート生成も、生成AIの代表的なユースケースかつ、総合商社の業務と相性が良いものの一つです。 今後の展望 現在Insight Edgeが力を入れている領域の一つがAIエージェントです。AIエージェントは与えられた目標やタスクの達成に向けて、状況に応じて高度な推論をしながら自律的に意思決定を行うことができます。単一ないし複数のAIエージェントを組み合わせることで、例えば前述の投資の意思決定支援の取り組みにおいては、過去議事録の情報抽出に加え、投資ポートフォリオの最適化やリスクシナリオ分析などにも応用できます。 また、社内の投資判断に関する各種ドキュメントや投資規律などを参照し、財務、人事、ESG、IT、マーケティングなどの各種専門家エージェントを互いに自律的に思考させることで、投資判断時における有用な示唆出しをする仕組みができるかもしれません。 AIエージェントは技術的な磨き込みはもちろんですが、適用するユースケース選定や深い業務理解に基づくエージェント設計が最も重要と感じます。その意味で、多種多様なビジネスドメインを持ち、それぞれに現場がある総合商社においては、業務課題に立脚し、その業界特化のAIエージェント開発がしやすい環境にあると思います。総合商社のビジネスと生成AIを掛け合わせることで、業界および産業界全体に大きなインパクトを与える取り組みを一つでも多く創出するべく、これからも頑張っていきたいと思います。 おわりに ここまで読んでいただきありがとうございました。生成AIまわりの技術進展はとにかく早く、すぐに知識や事例も陳腐化してしまいますが、最新技術は常に追いかけながら、それをどうビジネス実装していけるかを常に考えていきたいと思います。 総合商社という広大なビジネスフィールドで、生成AIをはじめテクノロジーで新たな価値を創出することに興味がある方は、カジュアル面談から是非お気軽にお問合せいただければと思います。

Insight Edge(以降IE)でデータサイエンティストをしております市川です。技術部の分析チームと、戦略企画部に属しております。この12月現在で入社7ヶ月が経過しましたので振り返りと学びをシェアできればと考えております！ 自己紹介と入社のきっかけ 自己紹介 私の経歴を簡単に紹介しますと、 転職は3回目ですが、途中兼務などで計6社を経験しており、一貫して金融機関で働いてきました。直近は取締役や事業責任者のキャリアが長いのですが、一貫してデータ分析に従事してきました。 基本的には市場・相場分析をしてきており、株・債券・為替・コモディティ、果ては暗号資産の運用に携わってきました。 データ分析のつながりで、オンライン証券のデジタルマーケティングのデータドリブン化にも取り組んだことがあります。 入社のきっかけ 昔の話になりますが、私は新卒の頃、相場師を夢見て就職活動をしておりました。結果として金融機関に入社したのですが、総合商社もトレーディング業務がありますので、就職活動で回っておりました。 当時の印象ですと、商社といえば猛烈に働き、夜はお客さんに接待するイメージが強く、金融機関でデータ分析の仕事をし始めて以降は全く関係のない会社だと思っていました。 ところが2023年の人工知能学会の全国大会に行ったところ、総合商社に知り合いが勤めていました。彼は学生時代、私が当時勤めていた会社にインターンに来てくれた方でデータ分析に長けた方です。よくよく話を聞いてみると、今は昔と違い、総合商社は競い合ってデータ利活用を進めているとのこと。元々多岐にわたる総合商社のビジネスの巨大さには魅力を感じていたので、いろいろと話を聞いてみることに。話を聞かせてもらううちに、IEにご縁があり入社に至った、という経緯になります。 入社からの7ヶ月間の経験と学び 入社して以降は、主にオルタナティブデータ利活用の取り組みですとか、技術者としてビジネス拡大に資する業務、マーケティング関連の取り組みに携わらせていただきました。総じて、ある程度皆さん忙しいこともあって、いろいろとやらせてもらった印象です。 特に2つほど大きなトピックがありましたので、シェアさせていただきます。 学会発表の経験 入社して以降、いくつかの学会に発表をさせていただきました。どれも大きな括りではオルタナティブデータの取り組みとなります。 一つは、 Asano, Y. Ichikawa, K. Nakagawa and K. Takano, "Analysis of Investment Behavior of Individual Investors in the FX Market: Influence of FOMC and Beige Book Information," 2024 16th IIAI International Congress on Advanced Applied Informatics (IIAI-AAI), Takamatsu, Japan, 2024, pp. 373-378, https://doi.org/10.1109/IIAI-AAI63651.2024.00075. でして、こちらはFOMCやBeige Bookのテキストデータから、相場や相場参加者の動向を予測するという取り組みです。 また、 市川 佳彦, 伊達 裕人, 那須田 哲也, 高野 海斗, 中川 慧, SAR衛星画像を用いたテーマパーク来場者数推定および売上予測, 人工知能学会第二種研究会資料, 2024, 2024 巻, FIN-033 号, p. 61-67, 公開日 2024/10/15, Online ISSN 2436-5556, https://doi.org/10.11517/jsaisigtwo.2024.FIN-033_61 こちらでは衛星写真の画像データから、駐車場の入り具合を計算し、テーマパークの売上や来場者数予測を行ったというものになります。 このように、オルタナティブデータの取り組みの中で、様々なユースケースへの適用可能性を探る研究をやっております。下期からは会社としてもより高い技術力を獲得すべくタスクフォースが発足するなど、動きが加速しております。私も、時間を見つけながら対応していきたいです。 10月の海外出張 10月の中旬に、インド・シンガポール・マレーシア・ベトナムに出張に行ってきました。2つほど目的があり、 AIのベンチャーとin personで会い、彼らの技術水準を確認すること 既に住友商事が出資している会社と面談し、収益力を向上すべくデータ分析の観点から取り組めそうな課題を探すこと でした。住友商事のグローバルに広がるネットワークの力を理解することができました。本当に総合商社の力というのは凄いなと感じました。個人的にはどの国も初めて行ったので、とても良い経験になりました。 会社の課題と今後の目標 7ヶ月会社にいますと、いろいろな部分が見えてきます。このブログは採用活動も兼ねておりますので、現在の課題と自身の目標について記載してみます。 対応リソース 当社は住友商事の内製DX集団と位置付けられています。オフィスも共通ですし住友商事のメールアドレスももらって業務をしているなど、いわゆる身内です。そのためカジュアルに住友商事の多種多様なセクションから課題が持ち込まれる状況です。 ただ、IEはまだ100人に満たない組織であり、リソースが十分に足りているわけではありません。課題を持ち込まれたとしてもIEがリソース不足で解決できない局面もあります。そのため、会社としてはあの手この手でリソースをしなければならない状況であり、今後の会社の課題だと考えています。もちろん、ひとり一人の生産性を高めることも重要だと思います。 グローバル案件への対応 住友商事は国内だけではなく、グローバルに強固なネットワークを築いています。そのため、国内同様海外にも多様なDXの課題があります。IEは既に海外の案件は多く取り扱っておりますが、対応できる人員は十分ではありません。こちらもリソースの話になりますが、課題になると考えています。また、私自身も語学が堪能ではありません。もうそれなりに良い歳ですが、通勤時間の英語学習、頑張って継続しようと思います。 おわりに 私自身は、以前の金融機関に在籍しているだけでは経験できなかった、多種多様な産業のデータ分析が可能なことですとか、海外も含めた大きいフィールドのビジネスにアプローチできる立場で、日々楽しく仕事をしております。もし入社を検討されている方がいらっしゃれば、ぜひお気軽にカジュアル面談などお越しください。お待ちしております！

はじめに はじめまして、5月に入社したデータサイエンティストの白井です！ 入社して半年ほど経ち、会社や仕事のことが少しずつ見えてきたこのタイミングで、改めて転職時の思いの振り返りと、実際働いてみた上でのInsight Edgeについて、書いてみようと思います。 Insight Edgeでは”入社エントリ”という形で記事を作るのは初めての試みなので、少し緊張していますが、張り切っていきます！ こんな方に見ていただきたい Insight Edgeに興味がある人 総合商社✖️DXが気になる人 自己紹介 まずは簡単に自己紹介をします。 1社目：独立系システムインテグレーター 基幹系システムの開発を担当し、概要設計からテスト、リリースまでの一連のプロセスを担当。 2社目：大手Web系企業 機械学習プロジェクトのリードとして、Deep Learning（特にCNN）を活用した画像解析サービスの導入を推進。 3社目：エッジAIベンチャー 協働研究のグループマネージャーとして、複数業界にわたる企業と共に画像解析技術を用いたプロトタイプ開発を推進。 4社目：フリーランス 機械学習エンジニアとして、ドライブレコーダー動画や医療CT画像のプロトタイプ開発を実施。 5社目：大手人材会社 求人サイトでの推薦システムを開発し、候補者に最適な求人を提案。 様々な企業に属してきましたが、2社目以降で一貫しているのは、データ活用によるビジネス貢献を仕事としてきたことです。（2012年から、約12年になります！）。 転職時に重要視したこと 今からちょうど1年前くらいに転職を考え始めました。 転職活動時に、重要視したことは以下です。 データを用いてビジネス貢献ができる 多様な業界に関わることができる 組織の成長に貢献できる それぞれ簡単に紹介します。 1. データを用いてビジネス貢献ができる 仕事でデータ活用をし始めたのは2社目からなのですが、その際に事業のKGI/KPIに貢献することの大切さを叩き込んでもらいました。 Deep Learningを使って事業貢献を目指していましたが、2012年当時はまだDeep Learningを事業活用している事例も少なく、R＆Dのような位置付けでした。 しかしその中でも、ビジネス貢献を目指すスタンスは一貫して意識するように周囲から支援をいただきました。 結果、多くの失敗をしながらも、技術でビジネスに貢献することの楽しさと重要性が染み付き、今に至るまで、私が仕事で大切にするポイントを形作っています。 2. 多様な業界に関わることができる この観点を大切にする理由は、私の過去の所属企業の特徴と、その中での仕事の特徴から来ています。 まず、私の過去の所属企業は、複数の業界の方とデータ活用をする機会が多くありました。 例えば、半年間はある業界、次の半年は別の業界、といった形での仕事です。 そのため、ビジネス課題を持つ複数の方々と、できることを考えて実行したり、役に立てないかとヒアリングに行くこともありました。 この動き方は、色々な業界の困っていることや課題を知り、それに対して自分の知識・力で役に立てられるところで価値が発揮できる点が好きです。 また、データ活用は世の中の様々なシーン・業界で活用できると思っています。 LLMの登場で改めて思うのですが、例えばUbieは医療で活用をしていますし、turingは自動運転に活用しようとしています。 特定の業界に閉じずに非常に幅広く、色々なビジネス活用事例が今後も多く生まれていくと確信しており、複数の業界に携われる環境に身を置きたいと思っています。 3. 組織の成長に貢献できる 約12年、データ活用を仕事にしてきて感じることは、この分野はまだまだ成長途中にあるということです。 データ活用は、新しい技術や事例が今後生まれていく余地が多分にあり、これが成果を出すための型化を難しくさせているように思います。 そのため、様々な企業・人が思考を凝らし、成功と失敗を繰り返して良い組織のあり方や姿を探っているのでは、と推察しています。 私が過去所属した企業も同様でした。 みんな、継続的なビジネス貢献のために思慮や工夫を凝らしていました。 その中で私自身が振り返って考えた時に、最も大切なのは、”周囲との建設的な議論”だと思っています。 技術やトレンド、ビジネスの状況は常に流動的であるため、変化する状況に対して臨機応変に会話し続けることが重要だと感じています。 自分自身も、うまくやりきれていないと何度何度も反省するのですが、この部分に少しでも貢献できたらと思っており、組織の成長について考え・それに貢献できるような会社に入りたいと思いました。 以上3つの観点が、転職活動時に大切にしたことでした。 Insight Edgeについて Insight Edgeは2019年に設立された、住友商事グループのDXを加速するための技術専門会社です。 住友商事グループは、約900社の事業会社で構成されており、幅広い事業を展開しています。 それらビジネスに対して、DXという手法を用いて貢献をする内製技術家集団がInsight Edgeです。 転職時に重要視したことと照らし合わせて、特にこの3点が良いなと思っている点です。 みんなでビジネス貢献を目指す 多様な業界でデータ活用をしている 組織作りのためのコミュニケーションが活発 1. みんなでビジネス貢献を目指す 入社前のInsight Edgeを調べていて好きだったポイントが2つありました。 １つは、Tech Blogで、もう１つがValueの中の「みんなでやる」です。 Tech Blogは是非一度、記事のタイトルだけでも見ていただきたいのですが、様々な職種の人が書いています。 分析の話だけでなく、採用・エンジニアリング・ビジネスデザイン・社内イベント・プロジェクトマネジメントと、本当に多様です。 （しかも毎週投稿されていて、会社全体で力を入れている感じが凄かった！） データ活用でビジネス貢献をする際、どうしても分析に目が行きがちなのですが、価値を届けるところに、Tech Blogからかなりの熱量を感じました。 価値を届けるためには、プロジェクトの仕立て・提供方法・組織や雰囲気作りと色々な観点が大切になります。 それをみんなでやっている印象でした。 実際に仕事をし始めても、この点は強く感じています。 例えば私が実施しているプロジェクトでは、プロジェクトマネジメント・ビジネスデザイン・分析アドバイザー・データ活用の組織内自走を目指す人たちとワンチームになって動いています。 各メンバーの強みが異なる中、ビジネス貢献を目的に全員で協働ができており、良い環境で仕事ができています。 Insight Edgeのvalueは「やり抜く、やってみる、みんなでやる」です。 転職を検討する際、色々な会社のvalueを見たのですが、「みんなでやる」を掲げている会社は他の二つ（やり抜く、やってみる）と比べて少なく、興味を持つきっかけとなりました。 これまで書いてきたように実際にこれを体現している就業環境で、入社して良かったと思っています。 2. 多様な業界でデータ活用をしている 住友商事には、グループ企業が約900社あり、事業部門ごとに9つのグループ分けがされています。 9つのグループは、鉄鋼、自動車、輸送機・建機、都市総合開発、メディア・デジタル、ライフスタイル、資源、化学品・エレクトロニクス・農業、エネルギートランスフォーメーションと非常に幅広いものです。 現在私は、メディア・デジタルグループのプロジェクトを担当しています。 過去の仕事がWeb系だったこともあり、多少親和性のあるところで仕事ができているのが幸いだと思っています。 入社後のオンボーディングの１つとして、在籍しているすべてのデータサイエンティストの方に現在の案件のお話を聞かせていただいたのですが、様々なシーンでのデータ活用をしていて、とても興味深かったです。 このように、同じ会社内ですが多岐にわたる産業分野のプロジェクトがあることで、広く社会に貢献できることを実感できるところが良いと思っています。 また、海外の会社との仕事の機会がある点も良いと思っています。 私と同じタイミングで入社した方は、現在東南アジアへ出張に行っています。 このように、携われる産業分野の幅が広く、更に国内だけに閉じずにグローバル案件にも関われる環境は、総合商社のDX推進を行うInsight Edgeならではの凄い所だと感じています。 3. 組織作りのコミュニケーションが活発 Insight Edgeは、設立してから5年ということもあり、ルールを整備している箇所がまだまだあるフェーズです。 その中で、コミュニケーションを非常に大切にしていると感じます。 例えば、3ヶ月に1回の頻度でTGIFという全社イベントを実施しています。 前回のイベントでは、会社のミッション・ビジョンの浸透に関わる話と、それを踏まえて5年後にどうなりたいかを話し合うためのワークショップを実施しました。 データサイエンティストだけでなく、他の職種の方とグループを作って会話させてもらい、色々な人のそれぞれの視点の考えを知ることができて、個人的にとても良かったです。 また、現在私は育成タスクフォース(TF)のメンバーとなり、今後入社する新卒者や若手社員などを対象とした育成施策を検討しています。 育成計画をどう立てるか？どうアセスメントするか？などを複数の方と会話するのですが、自分自身のこれまでのキャリアを振り返りつつ、どうすると良いかを考えるのが非常に難しく、また同時に楽しい時間になっています。 さらに、部活と呼ばれる複数の（趣味の）集まりがあり、私はこの半年でテトリスと麻雀に参加しました。（部活に関するブログもあるので、ご興味のある方はぜひご覧ください） コロナ禍に突入してからこのような機会がめっきり減っていたのですが、改めて共通の趣味をしつつ会話できる機会は良いものだなーと思いました。 最近は”#otemachi-chill”という、大手町オフィスに出社しているメンバーの中でランチやコーヒーブレイクに一緒に行く人を誘うSlackチャンネルなどもあり、実際に私も複数回参加しています。 これら全てのコミュニケーションを土台から支えているのが、コミュニケーションの丁寧さだと感じています。 様々なバックグラウンドの中途採用のメンバーが大半で、平均年齢が35歳を超えているからかもしれないですが、相手を慮る発話が多いと感じております。 ここがInsight Edgeの最も好きな点かもしれません。 おわりに ここまで読んでいただき、ありがとうございました。 本エントリでは、私の転職時の思いと、それと照らし合わせたInsight Edgeの良さを書いてみました。 Insight Edgeに興味がある方や、総合商社でのDXに興味がある方が、少しでも仕事のイメージが沸いたり興味を持っていただけたら幸いです。

Insight Edge HR担当の合田（ごうだ）です。 当社は2019年に“住友商事のDX推進のためのプロフェッショナル集団”として創業し、これまで中途採用100%で採用を進めてきました。なぜ今回新卒採用を開始したのか、その想いや実際の立ち上げから行なってきたことをアウトプットしておきたいと思い、ここにまとめることにします。 当社のように、これから新卒採用を立ち上げる際の採用担当者様の参考にもなれば幸いです！ なぜ新卒採用をするのか 新卒採用プロジェクトタスク一覧 採用ペルソナ策定〜求人票作成 新卒市況感リサーチ 採用目標人数設定 選考フローと評価項目策定〜面接官選出 採用チャネル検討 実際の選考推移 最後に なぜ新卒採用をするのか 新卒採用をスタートさせる時に、まずは“なぜ新卒採用をするのか”、”新卒採用に期待することは何か”という前提整理をしっかり時間をとって議論しました。 新卒採用を受け入れる理由は会社ごとに異なると思いますが、Insight Edgeとしては2024年夏に5年目の節目を迎え、今後の5年10年先の中長期的な会社の未来を考え「その時会社の中核となる人材を獲得し、社内で育成する必要がある」という所に着地しました。 これまで中途採用だけで成り立ってきたInsight Edgeは、ある程度社会人経験があり手厚い育成の必要がない人材だけで構成されており、裏を返せば現在の当社は育成する力が弱い状況です。新卒採用を受け入れるのであれば、社内の育成体制を整えておくことが絶対条件、というのが新卒採用チーム全員の想いで、採用チームとは別に技術部のエンジニア達による育成タスクフォースを立ち上げ、受け入れ体制の準備も同時並行で進めてきました。 以上より、Insight Edgeで新卒採用をする目的は下記２点と定義しました。 ① 将来のリーダーに入ってもらうこと ② ①に付随して、会社全体の育成力の向上を図ること 新卒採用プロジェクトタスク一覧 新卒採用の目的を共通認識としてキックオフ後、実際の募集開始に至るまでは下記のタスクが発生しました。 採用ペルソナ策定〜求人票作成 新卒市況感リサーチ 採用目標人数設定 選考フローと評価項目策定〜面接官選出 採用チャネル検討 求人票作成 評価項目の整理 採用ペルソナ策定〜求人票作成 新卒採用の目的を整理したら、その目的を達成するためにはどのような学生にアプローチをすればいいのか、採用ペルソナ策定を進めました。検討の上では下記の項目に分けてどの項目をより重視するかを数値化して進めました。そして採用チームの中で湧いてきたイメージを言語化したものが 現在の求人票 となります。 【学歴】 学業（専攻科目） 学業外活動 海外経験 【職歴】 インターンシップへの参加 アルバイト等就業経験 【パーソナリティ】 長所 短所 【就職活動】 キャリア志向性 併願企業 新卒市況感リサーチ 上記と同時に、近年における新卒採用に関する知見がなかったため、全体的な市況感やスケジュールについては、新卒専門の人材エージェントさん数社にお話を伺ってリサーチを行いました。 ①現在の新卒採用は圧倒的な売り手市場であること（特にエンジニアの需要は高く、1人の学生を6〜10社で取り合う状況であるとお聞きました） ②新卒採用スケジュールとしては、大学3年の夏のインターンから勝負は始まっており、大手企業は年内に採用活動を終了しているケースも多い（※後ほどのデータですが、大学4年のGW明けには約8割の学生が最低1社の内定を獲得していたようです） この話を聞いたのが既に2023年の12月末でしたので、「私たちが獲得したい2025年卒の学生は既に就職活動を終えている可能性が高い＝相当厳しい戦いになるだろう」、ということを強く認識しました。 採用目標人数設定 Insight Edgeはまだ60名程度と小規模な組織であることと、せっかく入社してもらうからにはしっかりとケアをしたいという点を鑑み、目標人数（というよりも、受け入れ可能上限人数）は3名と定めました。絶対に3名獲得するというよりは、これまでに定めた採用目的、採用ペルソナは妥協せず、ワーストケースとして採用人数0名でも結果を受け入れること、と決めました。 選考フローと評価項目策定〜面接官選出 次は新卒採用の選考フローを決めました。 エンジニア採用となるため、ハード面（技術素養や思考力）のチェックも必要であり、そのためにコーディングテストやSPIなどの試験を実施するかが争点となりましたが、新卒採用初年度としては一旦見送りとなり、面接での口頭確認としました。 合わせて、各面接毎にチェックする評価項目の整理と、それに合わせて誰が面接官をするかの選定を行いました。 採用チャネル検討 採用チャネルとしては大きく下記の３つが挙げられます。 ①自社サイト ②新卒サイト（ダイレクトリクルーティングでのスカウト運用） ③新卒採用専門エージェント 採用をスタートさせる時期が比較的遅く、 ①自社サイト だけの運用だけでは心許ないという点を踏まえ、最初にリサーチでお話を伺った ③新卒採用専門エージェント にご協力をお願いし、 ②新卒サイトのスカウト運用 については、次年度以降で検討することとしました。 求人票を自社の採用サイトにUPしたのが2024年1月31日で、ただでさえ厳しい市場の中でスロースタートを切った自覚はありましたが、エージェントの方から 「エンジニア人材の学生は納得出来るまで長く就職活動を続ける傾向が強いのと、最後まで進学と就職を迷っている学生もいるので、春先まではチャンスあります！」 とコメントをいただき、実際にたくさんの候補者を紹介いただいたことは本当に感謝です。 実際の選考推移 2月に入り、自社サイトからの応募やエージェントさん経由でのご紹介が少しずつ増え、実際に内定受諾もしていただくことができました。想定していた以上に多くの学生の方とお話しする機会に恵まれたことは、私としても大変貴重な時間となりました。 エージェントさんからも聞いていて想定した通り、春先の4月中旬頃から新規応募者数も減少していき、Insight Edgeとしても夏を一旦の区切りとして2025年卒の新卒採用をクローズし2026年度の採用に切り替えることを決断しました。 今は2025年卒の採用実績データを元に2026年の新卒採用に向けて動いている所です。 最後に 先日、2025年度の新卒入社予定者をオフィスに招いて内定者懇親会を実施することができました。当日は当社の若手社員に協力してもらい、簡単なワーク時間と昼食時間を設けて、交流を図りました。その様子もまたどこかでご紹介したいと思います！ 当社では今年の9月からは学生のインターンの参画受け入れも開始しており（ インターン生のブログ記事 ）、学生の方と交流する機会は以前に比べるとかなり増えています。 また、今回の記事では新卒採用開始からの私自身の動きについて記載しましたが、ここに至るまで、大学を訪問しての講義やセミナーの実施、インターン受け入れ時の対応等、採用チーム以外の現場のメンバーが多様な対応していたという背景があります。 違うロールのメンバーの様々な働きかけによって新卒採用プロジェクトが進んだ点は、当社のValueの１つである ”みんなでやる” が体現された良いエピソードになったと感じています。 また2026年卒の新卒採用もオープンしておりますので、ご興味のある方はぜひエントリーいただければ幸いです！ recruit.insightedge.jp

皆さんこんにちは、Insight Edgeでコンサルタントを務めております根本と申します。　 前回寄稿したブログ では新入社員として感じたことを中心に書かせていただきましたが、それから約1年が経過した現在の仕事を皆様にお伝えすることで、少しでもInsight Edgeの内側が伝われば幸いです。　実は現在、いわゆる「コンサルタント」とは少し毛色の異なる業務を主務としています。　今回の記事ではその主務である「セールスプランニング」についてご紹介したいと思います。 目次 １．セールスプランニングとは ２．セールスプランニングに求められること ３．これまでの実績紹介 ４．セールスプランニングの面白さ ５．現在取り組んでいる課題、今後の展望 ６．さいごに １．セールスプランニングとは Insight Edgeでは、今年の4月より、セールスプランニングという役割を営業組織内に新設しました。　元々営業組織の中にはコンサルティング、アライアンス、サービスデザイン、マーケティングといった役割を持つチームが存在していましたが、5つ目のチームとして新たに立ち上げたものです。 皆さんはセールスプランニングと聞いてどのような職種を思い浮かべるでしょうか。　日本企業であれば「営業企画」や「営業戦略」、外資系企業であれば「セールスオペレーション」や「セールスストラテジー」を思い浮かべる方が多いのではないかと思います。 私の前職はグローバル企業で、Insight Edgeと比べて遥かに大きな組織であったため、役割に応じた細かいチームが組成され、複数の部署が様々なアプローチで営業部隊を支援していました。　 例えば売上や案件管理については営業管理部隊、会議の企画やファシリ、業務改善についてはオペレーション部隊、そして戦略立案は戦略部隊という形で細分化されていました。 Insight Edgeはご存じの通りまだまだ規模が小さく少数精鋭の会社ですので、現状これらの業務をひとまとめにセールスプランニングという営業組織の中の1チームが担っています。　具体的には「売上管理」、「案件管理」、「各種会議体の企画およびファシリテーション」、「営業活動における業務/プロセス改善」、「組織戦略立案支援」、そして「全社横断の改善企画立案・推進」などが主な役割です。 これまでこれらの課題に対して、既存メンバーが主務の傍ら対応していましたが、より効率的かつ高い品質で行うべく、2024年4月より専門チームを新設しました。 チーム組成当初に作成した業務範囲と具体タスク案 Planning、Operation、Enablementの3軸で整理したもの。 ２．セールスプランニングに求められること Insight Edgeは順調に組織・事業規模ともに拡大傾向にあり、様々な部分で常に大きな変化が起きています。　これらの急な変化に伴い、これまで顕在化していなかった様々な課題が見えてきている状況です。 前述の通りセールスプランニングでは、非常に幅広い範囲の業務を担当していますが、潤沢なリソースの元、細かい部分にまで手が回っているかというと決してそうではありません。　少数精鋭ということからもお察しいただけるかと思いますが、セールスプランニングについてもごく少数のメンバーで構成されています。 そんな中でセールスプランニングに求められていることは大きく2つあります： 経営陣のサポート：経営陣が正しく現状を把握し、今後の計画を立てるための右腕となりバックアップすること。 課題解決：会社の拡大に伴う種々の課題に対して能動的に動き、他部署と連携して解決を進めること。 前者については、IE内の各種意思決定がデータを元に効率よく行える状態にすべく、インフラとしてデータ周りを整備、データを活用できる状況を整えた上で、各種意思決定に必要なデータ、インサイト提供を行うことが求められています。　今後の方向性を議論するためには現状を正しく把握する必要がありますが、現在正にこの部分に取り組んでいるところです。 後者については、セールスプランニングは営業組織内のチームではありつつも、行う業務のほとんどが組織横断的に行うものであり、全社的な課題解決への貢献を期待されています。 自部署における課題だけでなく、会社全体を見通し、どういう課題があり、どういう優先度で解決すべきかを常に考えることが求められています。 ３．これまでの実績紹介 ここで、今期取り組んできた取り組みの一部をご紹介したいと思います。 「案件推進プロセス整備」という業務改善企画がその一つです。　Insight Edgeでは多くの案件を様々なメンバーで推進していますが、初期相談から前捌き、顧客への提案から社内合意形成、契約締結までの一連のプロセスが可視化/整備されていない状況でした。 これにより、案件推進の品質が属人化してしまい品質にバラつきが出てしまう、必要な合意形成がされていない状況で顧客と諸条件を握ってしまうなど、実際にいくつかの問題が生じていました。　案件推進は営業部隊だけでなく技術チーム、管理部、経営陣を含めた全社的な関与で進むものですので、部署横断での取り組みが必須な状況でした。 この状況を改善すべく、セールスプランニングが主導する形で、新しい案件推進プロセスの整備に取り組みました。　まずは案件創出からクロージングまでの一連の流れを可視化し、フェーズごとに必要なアクションを定義、いくつかの文書フォーマットや会議体などを新設するという企画を立案しました。　その企画を元に社内の合意形成を得たうえで、実際に運用を行う部分もセールスプランニングが担い、軌道に乗せることで前述の課題解決に貢献しました。 この他にも、営業組織においてメンバー間の議論をより頻繁に行うための会議体の新設や、契約実務プロセスの最適化など、大小さまざまな改善を進めています。 案件推進プロセス整備の際に用いたBeforeAfter図。 既存のプロセスに新たな仕組みを追加する形で整備を行った。 ↓ 案件推進プロセス整備の際に用いたBeforeAfter図。 既存のプロセスに新たな仕組みを追加する形で整備を行った。 ４．セールスプランニングの面白さ 現在主務として取り組んでいるこのセールスプランニングの領域ですが、個人的には非常に面白い仕事だと思っています。　もちろん業務量も多く、解決すべき課題も非常に多い状況ではありますが、どの課題解決に取り組むか、それをどのように解決していくか、大きな裁量をもって業務にあたれる点が非常に魅力的な部分だと感じます。 また、業務の幅がとても広い点も、個人的に面白いと感じる要素の一つです。　会社が大きくなればなるほど、自身の業務範囲が定義され、基本的にはその範囲内で業務を行うことになりますが、Insight Edgeでは必然的に部署横断の取り組みが多く、扱う課題のカテゴリも経営直結の重要度が高いものからオペレーション/プロセス整備、会議体の企画、テンプレートの整備などビジネス全体に渡ります。 営業組織内のチームでありながら、全社横断的な動きを取っている点もユニークです。　営業組織単体の課題解決を行うだけでなく、組織横断で課題解決に取り組むため、Insight Edgeが抱えるエンジニア、データサイエンティスト、プロジェクトマネージャーといった技術メンバーとも深い関わりを持ち、一丸となって業務改善に取り組んでいます。　そういった改善活動においては営業目線だけでなく、技術者の視点でも改善策を考える必要があり、自分が持っていない視点/視座で考えることは自己成長にもつながります。 また、前回のブログでも書きましたが、Insight Edgeは外部環境・内部環境共に変化が大きい会社です。　当然その変化に合わせて解決すべき課題、求められるものも変わってきますので、都度変化するニーズに対応しながら会社全体の改善に貢献できることは仕事をするうえで大きなやりがいになっています。 ５．現在取り組んでいる課題、今後の展望 今回取り上げた実績は、セールスプランニングで対応する業務範囲のごく一部に過ぎず、解決すべき課題はまだまだ無数に存在します。　例えば直近では、1つの案件推進において、フェーズが切り替わるタイミングで担当チームが替わることがありますが、その引継ぎをいかに効率よく行うか、またそれをするためには案件の走り出しのタイミングでどういう整理が必要か、という議論が進んでいます。 また、新しい相談があった際、会社としてその案件に取り組むべきかどうかの判断基準や、複数の案件が同時進行する中で工数差配の優先度付けなど、ビジネスの根幹となる部分でも多くの課題があるのが現状です。　セールスプランニングでは、これらの課題に対して費用対効果やインパクトなど、様々な点を踏まえて優先度を付け、順次対応を進めているところです。 引き続き様々な領域で改善を進めていくことになりますが、担当者としてはやはり専門性の造成が必須であると感じています。　全方位的なスペシャリストが揃っているわけではないため、新たな領域へチャレンジする際には実際に業務を進めつつその領域の専門性を社内の誰よりも持つ必要があります。　それには実務だけではなく自己研鑽による知識習得が必要になりますが、業務バランスを保ちつつこの時間をどう捻出するかが直近の課題です。 ６．さいごに いかがでしたでしょうか。　技術者集団であるInsight Edgeの中でもこういう役割で仕事をしているメンバーがいる、ということが少しでも皆様に伝わり、興味を持っていただければ幸いです。　技術職以外でも活躍いただけるフィールドは多くありますので、カジュアル面談のご相談お待ちしています！

はじめに Insight EdgeのLLM Engineerの藤村です。 昨今、企業のDX推進に伴い、社内に蓄積された大量の画像データや文書の効率的な活用が求められています。弊社では、実務でLLMを活用する際、画像や表形式、複雑な図を含むドキュメントの理解が大きな課題となっています。この課題は多くの企業でも同様に直面していると考えられ、その解決は業務効率化において重要な意味を持ちます。 例えば： PowerPointの表やグラフの内容理解 手書きのホワイトボード写真からの情報抽出 複雑な組織図の階層関係の把握 スキャンした文書の図表部分の解釈 これらの課題に対して、以下の2点を検証しました： 最新のマルチモーダルLLMでどこまで対応できるのか GPT-4oのファインチューニングによってどの程度改善できるのか 目次 はじめに 目次 マルチモーダル大規模言語モデルとは 1. 主要マルチモーダルLLMの性能検証 検証方法 検証データ サンプル例 評価方法 モデル評価 LLM as a judge 検証結果 答えられなかった問題 現状の課題 2. GPT-4oのファインチューニングによる改善検証 ファインチューニングとは？ ファインチューニング手順 1. ファインチューニング用の学習データを用意 2. Azure OpenAI上でファインチューニングを実行 3. ファインチューニング後のモデルを使用して、テストデータを評価 改善結果 質問種別ごとのスコア 正解できるようになった問題 まとめと今後の展望 おわりに 参考文献・引用元 マルチモーダル大規模言語モデルとは 　近年、テキストだけでなく動画像も扱うことができる、対話型LMM (大規模マルチモーダル言語モデル)の開発が盛り上がりを見せている中で、ビジネスシーンにおける利用に焦点が当てられています。 例えば、LMMを組み込んだRAG (Retrieval-Augmented Generation)を用いることで、表や図、パワポスライド、文字ドキュメントなどの大量にある社内画像データから、ピンポイントに知識を手早く得ることができます。LMMには以下の図のような能力が備えられていることが期待されています。 マルチモダールLLM 画像認識能力 写真・図表・ドキュメントなど様々な形式の画像に対する汎用性と配置への理解力 外部知識 一般知識 (固有名詞、普通名詞などへの知識)、オントロジー的意味理解、数学、言語等 言語認識能力 多数言語に対する汎用能力、プログラミング言語も 指示対応力 質問で要求された通りの回答が出せるか 1. 主要マルチモーダルLLMの性能検証 検証方法 本検証では、実務での活用を想定し、以下の3つの観点から総合的な評価を行いました 画像認識精度 文字認識の正確性 図表要素の識別能力 空間的な配置の理解 文脈理解力 業界用語の適切な解釈 図表間の関連性把握 暗黙知の理解 応答品質 回答の正確性 説明の論理性 出力形式の一貫性 今回、Insight Edgeでも利用頻度が高い以下の3つのモデルで比較検証を実施します。 Google: Gemini 1.5 Pro OpenAI: GPT-4o Anthropic: Claude 3.5 Sonnet 検証データ 実際のビジネス利用シーンを想定して、様々なユースケースにおける質問を用意しました。 業務用文書画像8枚 質問23問（画像の内容理解、関係性の把握など） 画像名 質問 質問種別 ガートナー曲線図 特定フェーズに位置する要素を時系列順に抽出 データ抽出 ガートナー曲線図 所要期間が特定条件を満たす要素を抽出 データ抽出 顧客アンケート1 情報公開の同意状況の確認 選択読取 顧客アンケート1 回答者の基本的な個人属性情報の確認 属性理解 顧客アンケート1 自由記述から感情や評価傾向を分析 内容分析 顧客アンケート1 フォームの設問と回答の完全な書き起こし 全文読解 顧客アンケート2 情報公開の同意状況の確認 選択読取 顧客アンケート2 フォームの設問と回答の完全な書き起こし 全文読解 アイデア板書 企画・催事の正式名称を特定 データ抽出 アイデア板書 必要物品や参加者の数量・規模の確認 数値理解 アイデア板書 企画の主要テーマとコンセプトの把握 内容分析 診療報告書 服薬・治療に関する指示事項の確認 内容分析 診療報告書 ケアの実施スケジュールと頻度の確認 数値理解 診療報告書 医療サービスの提供方法の確認 属性理解 組織図 特定部門の構成員一覧の確認 構造把握 組織図 特定ユニットの下位組織一覧を抽出 構造把握 組織図 組織間の階層・指揮命令系統の確認 構造把握 都道府県別分布図 特定条件での上位地域を順に抽出 データ抽出 都道府県別分布図 特定地域の順位グループ分類を確認 数値理解 都道府県別分布図 特定地域の順位グループ分類を確認 数値理解 スキルマトリクス メンバーの各スキル習熟度を確認 属性理解 スキルマトリクス 今後の育成方針の重点項目を特定 内容分析 スキルマトリクス 評価未記入の項目を特定 データ抽出 サンプル例 以下は検証で使用した画像データの例です。 Gartnerのコクテッド・インダストリ・テクノロジのハイプ・サイクル図 幻滅期のテクノロジーを時間が早い順に全て列挙してください 採用するまでの年数が10年以上かかる技術を全て列挙してください Gartner、「日本におけるコネクテッド・インダストリ・テクノロジのハイプ・サイクル：2023年」 画像選定意図：密集した丸を識別し時系列に並べられるのか、凡例を理解した上で画像認識できるのか 都道府県防災会議における委員に占める女性の割合 15%以上〜20％未満に属する都道府県を全て答えよ 埼玉県は何%の帯域に属するか 都道府県防災会議における委員に占める女性の割合 画像選定意図：都道府県の位置関係の知識を有しているか、ヒートマップの色の違いを認識できるのか 評価方法 評価手法には大きく、コード評価(CE)　モデル評価(ME)　人手評価(HE)があります。 今回はモデル評価(ME)を採用しました。 LLM as a judge ともよばれる手法です。 理由としては、規模に強く指示文で採点カスタマイズ可能だからです。 Yang Liu et al., "Datasets for Large Language Models: A Comprehensive Survey", arXiv:2402.18041, 2024年2月 https://arxiv.org/pdf/2402.18041 モデル評価 LLM as a judge 採点用のモデルは GPT-4o を使用しました。 モデル評価にあたり使用したプロンプトは以下の通りです。 # 指示 あなたはテストの採点者です。採点ルールに従って、回答文と正解文の類似度のスコアとその理由を思考過程も合わせて日本語で出力してください。 # 入力情報 入力情報: 「画像説明」、「質問」、「回答文」、「正解文」 # 採点ルール 評価基準: 「画像説明」と「質問」を参考に、「回答文」が「正解文」にどれだけ類似しているかを評価する。回答文がで減点しない。順番も問われている問題は、順番を間違えていると、0.25減点。 スコア配分: 部分点に応じて0.25点刻みで採点。 理由部分の採点: 回答文が理由部分で画像から文字を引用している場合、その引用部分が間違えていると0点。 # 文字起こし 句読点や記号のミスやスペース・改行のズレがあっても減点しない。それ以外では、文字が完全に一致していない場合は0点。誤記がある場合は0点。 # 単体単語回答: 正解文が1単語の時、回答文の中に同じ単語があれば1点。正解文にない単語を回答文が答えているとき0点。さらに、理由部分が画像説明や質問に正しく沿っていないと0点。 数字問題では正解文の内訳が回答文になくても減点しない。 # 複数単語回答: 正解文が複数単語の時、回答文の中で、全ての単語を答えられていたら1点。回答文が正解文の単語を一部答えられていて、正解文にない単語も答えていない場合は、合っていた割合に近い点数を部分点として与える。 さらに、1つでも正解文に存在しない単語を回答すると0点。ただし、「・」はついていてもいなくても減点対象としない。 さらに、回答が正しく、理由が画像説明や質問に正しく沿っていると1点。理由が画像説明や質問に正しく沿っていないと0点。 # 文章回答: 回答文が画像説明に沿った回答をし正解文と意味が等しい時、1点。回答文の意味が画像説明や正解文と全く異なると、0点。 # 図表推論問題: 画像説明や正解文にある通り、回答文が正しく情報が読み取れていたら1点。根拠が正しくないときは0点。 今回は実際のビジネス利用を想定して、 ハルシネーション（嘘の回答）が含まれていたら強めに減点する ようにかなり厳しめに採点ルールを設けています。このプロンプトによって採点の基準をカスタマイズできるのがLLM as a judgeの利点ですね。 また、LLMの仕様上、毎回同じ点数を安定して出力できないので、 3回以上実行して平均点を算出することで、安定した評価 を行うように工夫しています。 検証結果 検証結果は以下の通りでした。 モデル スコア GPT-4o 6.58 Gemini 1.5-Pro 8.31 Claude 3.5 Sonnet 6.61 *23点満点 Gemini 1.5 Pro が最も高いスコアとなりました。 問題によっては完全回答ができず、部分点のみの回答となったり、回答理由部分が間違っていると0点となることもありました。 満点が23点なので、問題設定の難易度が高いこともありますが、どのモデルもあまりいい結果とは言えないですね。 各モデルの特徴は以下の通りです。 Claude 3.5 Sonnet 組織図の階層関係理解が優れている 日本語テキストの認識精度が高い 文脈を考慮した自然な回答 GPT-4o 表形式データの解析が得意 一般的な画像認識で安定した性能 複雑な図表での誤認識が時々発生 Gemini 1.5 Pro 複雑な図表の理解力が高い 処理速度が比較的速い 手書き文字の認識にやや課題 答えられなかった問題 質問：幻滅期のテクノロジーを時間が早い順に全て列挙してください 正解：図のオレンジで囲われたテクノロジーを左から順に答える オレンジの枠内が正解 誤答内容： スマート・ロボット, 2. AR, 3. LPWA, 4. 次世代リアル店舗 原因考察： 幻滅期の中でも群が2つあり、片方しか認識できていない。 丸が幻滅期に属していても文字の位置が別のグループに跨っていて正しく認識できていない。 現状の課題 検証で明らかになった主な課題： 認識の不安定さ 画像品質による性能のばらつき 複雑な表構造の誤認識 手書き文字の認識精度の変動 文脈理解の限界 業界特有の用語や略語の誤解 図表間の関連性の把握ミス 暗黙知的な情報の見落とし 2. GPT-4oのファインチューニングによる改善検証 ファインチューニングとは？ ファインチューニングとは、事前学習済みのLLM（大規模言語モデル）に対して、特定のタスクや領域に関する追加データで学習を行い、モデルの性能を改善する手法です。これは転移学習の一種で、モデルの基本的な能力を保持しながら、特定の用途に特化させることができます。 ファインチューニングのメリット マルチモーダルLLMの業務文書認識における課題を解決できる ビジネスユースケースに即した適切な学習データを用意することで、さらなる性能向上が期待できる ファインチューニングを行うことで、検証で使用したモデルの課題を解決できることを期待します。 ファインチューニング手順 Azure OpenAIが提供するGPT-4oのファインチューニング機能を使用します。この機能は、既存のモデルを特定のタスクや領域に特化させることができ、今回のようなマルチモーダルタスクにも適用可能です。 fine-tuningの実施手順についてはAzure公式の以下のドキュメントを参考にしました。 learn.microsoft.com 1. ファインチューニング用の学習データを用意 今回のファインチューニングでは上記の検証で使用したデータは評価データとして使用するので、学習用に別途、類似のデータを用意しました。 (画像は省略します) 学習データ： 業務文書画像10枚 質問と回答のペア27セット 様々なタイプの図表や手書き文書を含む 学習データは以下のようなJSON形式で用意する必要があります。 今回画像を含んだデータを使用するので、画像のURLを指定しています。 { " messages ": [ { " role ": " system ", " content ": " あなたは画像認識のスペシャリストで、どんな図表やグラフでも詳細に分析できるAIアシスタントです。 " } , { " role ": " user ", " content ": " この組織図における部門の数と階層構造を教えてください。 " } , { " role ": " user ", " content ": [ { " type ": " image_url ", " image_url ": { " url ": " https://blob.example.com/images/sample1.jpg " } } ] } , { " role ": " assistant ", " content ": " 営業、開発、マーケティングの3つの主要部門があり、それぞれ2-3の下位部門を持つ3層構造になっています " } ] } 上記のJSONを複数用意し、以下のようにJSONL形式で保存します。 { " messages ": [{ " role ": " system ", " content ": " あなたは画像認識のスペシャリストで、どんな図表やグラフでも詳細に分析できるAIアシスタントです。 " } , { " role ": " user ", " content ": " この組織図における部門の数と階層構造を教えてください。 " } , { " role ": " user ", " content ": [{ " type ": " image_url ", " image_url ": { " url ": " https://blob.example.com/images/sample1.jpg " }}]} , { " role ": " assistant ", " content ": " 営業、開発、マーケティングの3つの主要部門があり、それぞれ2-3の下位部門を持つ3層構造になっています " }]} ...(省略)... { " messages ": [{ " role ": " system ", " content ": " あなたは画像認識のスペシャリストで、どんな図表やグラフでも詳細に分析できるAIアシスタントです。 " } , { " role ": " user ", " content ": " 各部門の人員規模と報告ラインの特徴を分析してください。 " } , { " role ": " user ", " content ": [{ " type ": " image_url ", " image_url ": { " url ": " https://blob.example.com/images/sample1.jpg " }}]} , { " role ": " assistant ", " content ": " 営業部門が最大で150名、開発部門が120名、マーケティング部門が80名の構成です。各部門長は直接CEOに報告し、部門内は最大でも3段階の報告ラインとなっています " }]} 2. Azure OpenAI上でファインチューニングを実行 AzureのAzure AI Foundry上でファインチューニングを実行します。 公式の手順に従ってプロジェクトを作成します。 左パネルの「微調整」を選択します。 モデル選択画面からGPT-4oを選択します。 そのあとは画面の手順に従って、学習データをアップロードして、ファインチューニングを実行します。 実行時間は今回のデータ量だと50分ほど要しました。 トレーニングが完了したら、「デプロイ」を選択して、ファインチューニング後のモデルをデプロイします。 3. ファインチューニング後のモデルを使用して、テストデータを評価 Azure OpenAI上でもPlaygroundを使用して、ファインチューニング後のモデルを使用してテストデータを評価できます。 今回はLangChainを使用して、ファインチューニング後のモデルを使用してテストデータを評価しました。 # ファインチューニング実装例 from langchain_openai import AzureChatOpenAI import os # モデルの初期化 # temperature: 値が低いほどランダム性の低い出力になります（0.0-1.0） temperature = 0 fine_tuned_llm = AzureChatOpenAI( openai_api_key=os.getenv( "AZURE_OPENAI_API_KEY" ), # fine-tuning後に発行されたAPIキー model= "gpt-4o" , azure_deployment= "gpt-4o-finetune" , #azureで設定したモデル名 api_version= "2024-02-15-preview" , azure_endpoint=os.getenv( "AZURE_OPENAI_ENDPOINT_FINETUNE" ), # fine-tuning後に発行されたエンドポイント temperature=temperature, ) # モデルの呼び出し # 画像を含むメッセージの作成 messages = [ { "role" : "user" , "content" : "この組織図における部門の数と階層構造を教えてください。" }, { "role" : "user" , "content" : [{ "type" : "image_url" , "image_url" : { "url" : "https://blob.example.com/images/sample1.jpg" }}]} ] # 推論の実行 response = fine_tuned_llm.invoke({ "messages" : messages}) 改善結果 モデル スコア GPT-4o 6.58 GPT-4o-finetune 10.75 未学習のGPT-4oと比較して、正解スコアが約 65% 向上しました。この改善は特に以下の3つの観点で顕著でした 文脈理解の向上 業界特有の用語や略語の正確な解釈 図表間の関連性の把握精向上 空間認識能力の改善 複雑な図表での位置関係の理解 色彩や形状の正確な識別 回答精度の向上 より具体的で正確な数値の抽出 多段階の推論を要する質問への対応 質問種別ごとのスコア また、質問種別によるスコアの変化は以下の通りです。 質問種別 GPT-4o GPT-4o-finetune データ抽出：特定条件での情報抽出 0.5 0 .75 選択読取：選択肢の判別 2.0 2.0 属性理解：基本属性の把握 0.75 1.0 内容理解：文脈や意図の理解 0.0 2.0 全文読解：文書全体の把握 0.0 0.75 数値理解：数値情報の解釈 1.0 2.0 構造把握：関係性の理解 2.25 2.25 正解できるようになった問題 例えば、以下の画像の問題では、未学習のGPT-4oは不正解でしたが、ファインチューニング後は正解となりました。 都道府県防災会議における委員に占める女性の割合 埼玉県は何%の帯域に属するか GPT-4o: 15%以上〜20％未満 (不正解) GPT-4o-finetune: 20%以上〜40％未満 (正解) 色の違いや県の位置関係を理解しているかを問う問題です。 学習データには日本地図の画像は含んでおりませんでしたが、ファインチューニングにより、画像の空間把握能力が向上したと考えられます。 まとめと今後の展望 ファインチューニングによって、マルチモーダルLLMの業務文書認識における課題をある程度解決できることが確認できました。特に注目すべき点として 画像認識精度の向上 複雑な図表の理解力が65%向上 空間的な関係性の把握能力の改善 業務特化型の処理 特定業務領域での高い精度 カスタマイズ可能な応答形式 今回は合計27セットの学習データを使用しましたが、実際のユースケースを想定して、適切な豊富な学習データを用意することで、さらなる性能向上が期待できます。 今後の展開 より多様な業務文書での検証 学習データの質と量の最適化 他のマルチモーダルLLMとの組み合わせ検討 実務でのマルチモーダルLLM活用において、ファインチューニングは有効な手段となることが分かりました。各組織の特性に合わせた適切な学習データを用意することで、より実用的なソリューションを構築できると考えています。 また、今回LLM-as-a-judgeを用いて、採点の自動化を行いました。人手による採点プロセスを大幅に効率化できたのはメリットだと感じました。一方で、採点基準の定義を言語化してプロンプトに反映させたり、LLM特有の出力のブレをいかに抑えるかなど、採点精度の向上における課題は改善の余地があるように感じました。 おわりに 「1. 主要マルチモーダルLLMの性能検証」では、インターン生の田中知可良さん（東京科学大学大学院（旧東工大））にもご協力いただきました。ありがとうございました！ 当社では、新卒採用について26年度採用もオープンしているため、興味のある方はぜひともエントリー頂けると幸いです！ recruit.insightedge.jp 参考文献・引用元 ガートナー、「日本におけるコネクテッド・インダストリ・テクノロジのハイプ・サイクル：2023年」、2023年10月 https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231003 内閣府、「令和5年版 防災白書」、図表1-10-1 都道府県防災会議における委員に占める女性の割合 https://www.bousai.go.jp/kaigirep/hakusho/r05/zuhyo/zuhyo1-01_10_01.html Yang Liu et al., "Datasets for Large Language Models: A Comprehensive Survey", arXiv:2402.18041, 2024年2月 https://arxiv.org/pdf/2402.18041