はじめに 実装関連 まとめと感想 参考文献 はじめに こんにちは。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

開発チームの塚越です。Insight Edgeに加わって1年が経ちました。開発業務に携わらせていただき、日々楽しく過ごしています。 目次 1. 概要 2. PMへの挑戦を決めた経緯 3. 押さえたい初歩的PMポイント 3.1. 顧客とプロジェクトの方向性を一致させる 3.2. 成功する見込みがあるプロジェクトか確認する 3.3. 内部のコミュニケーション量を増やす 4. おわりに 1. 概要 私はこれまで開発ロールに専念していましたが、最近PMへ挑戦する機会に恵まれました。この記事では、挑戦するに至った経緯と、PMとして実践しようと考えている重要なポイントを共有します。 「PMに挑戦した経緯」の章では、なぜ私がPMロール担当しようと思ったのか、その背景と理由を説明します。 「押さえたい初歩的PMポイント」の章では、PMとして案件を遂行するために重要だと考える基本的な要点をまとめました。これらは、私自身が学び、実践しようとしているポイントです。 なお、この記事の内容は私個人の経験と見解に基づいています。組織や状況によって最適なアプローチは異なる可能性がありますので、ご了承ください。 2. PMへの挑戦を決めた経緯 自身のキャリアを考える中で、開発スキルに加えて別の強みも持ちたいと考えました。特に、PMの役割も担える開発者というキャリアパスに興味を持ちました。開発者としてのスキルだけでなく、プロジェクト全体を成功に導くための視点や力を養いたいと考えています。自分がリードする立場になり、プロジェクトに関わる人たちの力を引き出しながら成功を目指すという役割に魅力を感じました。 Insight Edgeはメンバーの成長を重視し、組織全体の能力を引き上げる文化が根付いていると感じています。この文化の中で、私も上司や同僚に相談を重ねる中で、PMを兼任する形での挑戦が実現しました。 PMを専任する選択肢もありましたが、PMと開発の齟齬を少なくするために、兼任可能な案件規模でのPM兼任開発者を希望しました。本記事では、この体制下でPM兼任開発者として成功するために重要だと考えるポイントをまとめています。 ここで紹介するポイントは主にPMとしての観点に焦点を当てており、開発者の視点を活かしたプロジェクト運営の利点も反映されていますが、強調するものではありません。重要なのは、前述の経緯を念頭に置きつつ、PMとしての役割を効果的に遂行することです。より効果的で満足度の高いプロジェクト遂行の実現に向けた取り組みの一部として、この経験を共有させていただきます。 3. 押さえたい初歩的PMポイント 3.1. 顧客とプロジェクトの方向性を一致させる プロジェクトの成功には、顧客との方向性の一致が不可欠です。方向性がズレると顧客の期待値を超えることは困難になります。この問題を防ぐために、以下の2つの重要なポイントに注目しました。 3.1.1. 顧客はITのプロではないことを認識する 最初に意識したいのは、顧客がITの専門家ではないということです。これは当たり前のように思えることですが、実務の中ではつい忘れてしまいがちです。私自身、技術的な背景を持つ立場から話してしまい、結果的に顧客との間で認識のズレを生むことがありました。この点を克服するため、私は以下の取り組みを行おうと考えています。 重要性と潜在的な問題： コミュニケーションギャップにより、認識のズレが生じやすい ズレに気づくのが遅れると、修復困難や手戻り、顧客の不満につながる 適切に対応すれば、プロジェクトの円滑な進行と顧客満足度の向上が期待できる 対策と実践のコツ： 会議や報告の前に、この点を自己確認する 専門用語を避け、わかりやすい言葉で説明する 技術的な説明には具体的な例や比喩を用いる 顧客からの質問を歓迎し、理解度を把握する機会とする 3.1.2. プロジェクトの目的を常に問い続ける プロジェクトの進行中に目的がぼやけてしまうことはよくある問題だと思います。その結果、顧客の期待に応えられない成果物ができてしまうリスクを防ぐため、私は目的意識を常に持つことを意識していきたいと考えています。 リスクと影響： 他の製品との差別化が曖昧になり、競争力が低下する 実際には使われない、または活用されない製品が完成する 表面的には要件を満たしているが、顧客満足度や費用対効果が低い プロジェクトの成果が組織の戦略やビジョンと乖離する 対策と実践方法： 定期的に「何のためにこのプロジェクトを始めたのか」を問い直す 方向性に違和感を感じたら、顧客自身に目的を語ってもらう チーム内でも同様のアプローチを取り、ときには他メンバーに顧客の前で語ってもらう 3.2. 成功する見込みがあるプロジェクトか確認する プロジェクトの成功とは、私の見解では以下のいずれかを達成することだと考えています： 顧客の期待値を超えること 費用対効果が十分に得られること プロジェクトにアサインされる段階で、以下の要素を慎重に評価することが重要です： 顧客側の期待度（案件の要件スコープ） 予定している工数 プロジェクト期間 アサインされるチームメンバー これらの要素を総合的に検討し、与えられた条件で顧客の期待を超えることができるか、または十分な費用対効果が得られるかを判断したいと思います。 もし、現状の条件でプロジェクトの成功が難しいと判断した場合、以下のアクションを取ることを検討します： 早期の情報収集： 契約提案段階から、営業部門と顧客とのやりとりを注意深く確認する 必要に応じて、追加情報の収集や不明点の明確化を要求する 上司との相談： プロジェクトの成功に懸念がある場合、早期に上司へ相談し、対策を検討する 工数、期間、またはチーム編成の見直しの必要性を議論する 契約締結前の調整： 情報収集と上司との相談結果に基づき、以下の調整を提案する： 顧客の期待値を適切なレベルに調整する 契約内容（スコープ、期間、予算など）の再交渉する プロジェクト体制の見直しを行う このように、プロジェクトの初期段階で成功の可能性を見極めることもPMとして重要な役割だと感じています。各要素を慎重に確認し、条件が揃っていない場合は早めに調整をすることでプロジェクトの成功率を高めたいと考えています。 3.3. 内部のコミュニケーション量を増やす 3.3.1. 阿吽の呼吸を生み出す プロジェクトは計画通りに進まないことが多々あると思っています。台本のなくなった講演会を想像してみました。そのような状況では、メンバー間の阿吽の呼吸で講演を進める必要があります。コミュニケーションが活発なチームほど、台本なしでも「講演」を続けられる可能性が高くなると思いました。 実践方法： 定期的なチームミーティングを設ける 内面を深く知る対話の機会を創出する（例：ランチミーティング） プロジェクトの進捗や課題を共有する場を頻繁に設ける これらの方法を通じて、チームメンバー間の理解を深め、予期せぬ状況にも柔軟に対応できる「阿吽の呼吸」を育みたいと思います。 3.3.2. 火種に気づいて炎上を防ぐ プロジェクト内の小さな問題（火種）は、放置すると必ず大きな問題（炎上）に発展すると思っています。コミュニケーションが活発なほど、火種に気付ける可能性が高くなるため、まずは単純に情報流通量を増やすことが大切だと思いました。 実践方法： メンバー全員が課題や違和感を容易に口に出せる場所を作る（例：Slackの雑談チャンネルを設置する） 言いやすい環境づくりをする（例：心理的安全性に関する書籍を読み、実践する） 4. おわりに この記事によって、私自身がPM兼任の役割を担うにあたっての心構えができました。完全に自分のための記事になってしまいましたが、同じような状況に直面している方々にとって、何かしらのヒントになれば幸いです。 謝辞 この記事を作成するにあたり、以下の方々からの貴重なインプットがありました： チームリーダーの方々 経験豊富なPMロールの方々 皆さんの洞察と助言が、この記事の内容をより良くしてくれました。 参考文献 また、オフィスで見つけた以下の本からも多くの学びを得ました。これらの知見は記事の随所に反映されています。 新装版 外資系コンサルが教えるプロジェクトマネジメント（山口周） PMとしての役割を理解し、効果的に遂行するポイントを知る上で非常に有益でした。興味のある方は、ぜひ参照してみてください。

はじめに こんにちは！昨年9月からInsight Edgeの開発チームに参画した広松です。Insight Edgeでは生成AI案件を担当しています。 2024年11月現在でも生成AIの進化は止まらず、日に日に技術的な課題を克服しています。各社のLLMが頻繁に大型アップデートされるので付いていくだけでも大変な日々を送っています。 さて、前回は 生成AIエージェントを使ったデータ分析の記事 を書いたので、今回は生成AIエージェントを使ったシステム開発について書こうと思います。ただ、この技術は非常に進化が早くすぐに記事が古くなり役に立たなくなってしまうので、2024年11月現在で実現できていることと、長期的な将来像の考察について論文紹介も含めて書いていきます。 昨今では、生成AIがコーディングの補助をしてくれることが常識になりつつありますが、システム開発の様々な工程をAIエージェントがどの程度自動でやってくれるのでしょうか？その点を確認しつつ、解決されるべき課題についても記載していきます。 目次 はじめに 目次 概要 現在（※2024年11月）までの生成AIでのシステム開発補助の経緯 チャット形式でコード生成をさせる時代 AIエージェントでコーディング計画を立てたりエラーの自己解決を試みる時代 現在のAIエージェントによるシステム開発が抱える課題 課題1. 論理的な思考が難しい 課題2. 推論や対話を繰り返すと指示を忘却してしまう 課題3. ハルシネーションが連鎖する 課題4. 人間と協業しづらい 課題5. 様々な専門家ロールの視点によるチェックがない AIエージェントを使ったシステム開発の将来 複数ロール（例：PM、アーキテクト、エンジニア、品質管理者）のマルチエージェントでシステム開発をする時代 MetaGPTとは 最後に 参考文献 概要 2024年11月現在までの生成AI及び生成AIエージェントによるシステム開発の補助について説明し、長期的な将来、生成AIエージェントがシステム開発にどう関わるのかについての予想を論文をベースに説明します。 現在（※2024年11月）までの生成AIでのシステム開発補助の経緯 チャット形式でコード生成をさせる時代 2023年までのシステム開発での主要な生成AIの活用方法は、チャットベースで生成AIに質問を投げるだけでした。 ChatGPTやGitHub Copilotに実装したい内容を伝えてコードを生成させる使い方がほとんどでした。コーディング補助以外ではドキュメント作成に使われることが大半でした。要求分析や要件定義、設計などでドキュメント作成に活用していた方もいると思いますが、方法が確立されておらずコーディング補助のように劇的な効果は得られていなかったと思います。 ただ、生成AIはそもそも論理的な思考ができないので、複雑な内容や中規模以上のコードを一気に生成させることは現実的ではありませんでした。 複雑な内容やある程度の規模のコードをまとめて生成させた事がある方は、それっぽいでたらめなコードが生成されるのを見てきたと思います。 また、生成AIはコードを生成するだけで、出力されたコードを実行して結果を確認する作業は人間の開発者が行なっていました。 AIエージェントでコーディング計画を立てたりエラーの自己解決を試みる時代 上述したような課題から、AIエージェントを使ったサービスが出てきました。 推論を繰り返すことで論理的な思考を誘導したり、コードの実行環境を操作できるようにしてエラーを自己解決させるアプローチが取られ始めました。 具体的なサービスだと、GitHubがissueからAIエージェントにコーディング計画を立てさせてコーディングをさせる GitHub Copilot Workspace が発表された他、フロントエンド開発をAIエージェントで支援する bolt.new などがリリースされました。 現在のAIエージェントによるシステム開発が抱える課題 課題1. 論理的な思考が難しい 生成AIは確率的に出力を生成しているので、論理的な思考ができません。推論を繰り返すことで論理的な思考のような出力を誘導させる事が限界です。2024年前半までは CoT（段階的に思考させて論理的な出力を誘導する手法） や ReAct（推論・実行・結果の観察をループさせることで論理的な出力を誘導する手法） が有力な手法でしたが、精度としてはそれほど高くありませんでした。 しかし、現在はこの論理的な思考のような出力を誘導させる技術が飛躍的に進歩しており、OpenAIが最近発表した o1-preview などは理系博士課程の学生に匹敵もしくは超えるほど高難度の問題が解けるようになっています。 推論を繰り返す方法は非常に威力があるので今後、この方法が進化していけば大抵のソフトウェアエンジニアよりも"論理的"な思考が出力されるようになるかもしれません。 課題2. 推論や対話を繰り返すと指示を忘却してしまう 課題1の論理的思考は今後の技術的な進歩である程度問題ないように思えます。しかし、推論を繰り返すことで別の問題が生じます。 それは推論を繰り返すうちに内容が要約されて、詳細な内容や初期の指示が忘れられてしまうことです。そのため詳細な長文の仕様などを伝えても正確な指示が残らない事があります。 課題3. ハルシネーションが連鎖する エージェントは内部でかなりの推論や対話を繰り返すので、一度のハルシネーションが連鎖して大きな混乱を発生させ、最終結果に大きな影響を与えてしまいます。 課題4. 人間と協業しづらい エージェントが自律的にどんどん開発を進めてしまうため、人間が介入しづらいです。 エージェントから必要な情報を人間に問うようなサービスもありますが、エージェントが勝手に判断してあらぬ方向に開発をどんどん進めてしまうことも多々あります。 課題5. 様々な専門家ロールの視点によるチェックがない エージェントは設計からテストまで自動で行ってくれますが、様々な専門家ロールの視点でチェックしてくれるわけではありません。 PM、アーキテクト、エンジニア、品質管理者など様々な視点で成果物をチェックしてくれるわけではありません。 AIエージェントを使ったシステム開発の将来 複数ロール（例：PM、アーキテクト、エンジニア、品質管理者）のマルチエージェントでシステム開発をする時代 先ほどあげた課題の中で、課題1, 課題2はLLMそのものの問題です。課題3, 4, 5については仕組み自体を工夫することで解決できると思います。 今回はシステム開発としては必須となるであろう課題5についての解決策とその未来について考察しようと思います。 実際のシステム開発ではPM、アーキテクト、エンジニア、品質管理者など様々なロールの専門家が協力してシステム開発を行います。 この実際のシステム開発のやり方を踏襲したアプローチで代表的なものが2つあります。 MetaGPT や ChatDev と呼ばれる手法です。 今回はより実際のシステム開発会社での開発に近いMetaGPTについて紹介します。 MetaGPTとは MetaGPT とは以下の図のように各専門家のエージェントをマルチエージェントで動かし、協業してシステム開発を行う手法です。 MetaGPTの概要の図 この手法で特徴的なのは、エージェント同士の会話でハルシネーションを連鎖させないために、SOP（標準化された作業手順書）を使用していることです。これはシステム開発会社などで用いられている実際の手順書を用いています。例えばウォータフォールであれば、要件定義、設計、実装、テストなどの一連の作業の流れを標準化したものです。 これにより標準化されたやり方でタスクを細分化でき、ハルシネーションの連鎖を発生させにくくできます。 また、このような人間によるシステム開発の標準に沿っているため各ロールのエージェントの成果物も人間が確認しやすいものとなっています。 例えば、アーキテクトのエージェントが出力するものは以下で、人間のアーキテクトやエンジニアでも簡単にレビューできるものとなっています。 アーキテクトのエージェントが出力したクラス図 アーキテクトのエージェントが出力したシーケンス図 上記だけでなくMetaGPTの興味深いところは、冗長な会話をする事なく知識の共有ができることです。 各エージェントが様々な情報を共有（Publish）しておき、他のエージェントは共有された情報を検索して必要な情報を取得（Subscribe）します。このPub/Sub形式での知識の共有を行うことで効率的で効果的な開発が可能になっているようです。 ロールごとに成果物の形式を標準化したり、知識のPub/Sub形式での共有は、人間による開発とかなり似ていますね。 最後に 生成AIの進化は凄まじいですが、システム開発の現場においてはコーディング補助以上に適用する方法はまだまだ確立されていないのが現状です。 しかし、要求分析から要件定義・設計・実装・テスト・品質チェックまでをマルチエージェントで自動で行う手法なども登場しています。各専門家ロールのエージェントが人間と同じ形式の成果物を出力して作業を進めていくので人間にもトレースでき、協業することも難しくないでしょう。 今後は同じロールの人を大勢集めたチームで働くのではなく、各ロールの専門家を集めた比較的小規模のチームでの開発が主流になっていくのではないでしょうか？そのためには今以上に他のロールの視点を理解しながら仕事をしていく必要がありそうですね。 参考文献 Jason Wei, Xuezhi Wang, Dale Schuurmans, et al., "Chain of Thought Prompting Elicits Reasoning in Large Language Models," arXiv, 2022. DOI: https://doi.org/10.48550/arXiv.2201.11903 Shunyu Yao, Jeffrey Zhao, Dian Yu, et al., "ReAct: Synergizing Reasoning and Acting in Language Models," arXiv, 2022. DOI: https://doi.org/10.48550/arXiv.2210.03629 Sirui Hong, Mingchen Zhuge, Jiaqi Chen et al., "MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework," arXiv, 2023. DOI: https://doi.org/10.48550/arXiv.2308.00352 Chen Qian, Wei Liu, Hongzhang Liu, et al., "ChatDev: Communicative Agents for Software Development," arXiv, 2023. DOI: https://doi.org/10.48550/arXiv.2307.07924

はじめに 開発経緯 作成したアプリの構成および議事録作成手順 構成 議事録作成手順 半年間運用して得られた学び 議事録自動生成の精度がどうだったか？ 使用したモデルおよびコストについて モデル コスト 安全フィルターについて プロンプトおよび生成過程について VertexAI Geminiの凄さについて 議事録を投稿できるまでの手順の制限について まとめと今後の期待 はじめに こんにちは、Insight Edgeで開発エンジニアをしているニャットです。 入社から1年以上が経ちましたが、まだまだ学ぶことが多く、日々、社内の勉強会やリソースをフル活用して新しい技術の習得に挑戦し続けています。 今回は、勉強会の時間を活用しつつ「社内用の議事録自動作成アプリ」を少しずつ開発し、半年間社内で運用しながら改善を重ねたので、その開発経緯と得られた学びを紹介します。 開発経緯 2024年5月頃、Google社が発表した「Gemini 1.5」モデル（Pro/Flash）は動画文字起こしの精度と速度が大幅に改善されたことから、SNSや様々なプラットフォームで話題となり、当社メンバーの間でもこのモデルの可能性に対する関心が非常に高まりました。 また、当社では多数のプロジェクトや勉強会、R&Dが同時進行しており、情報を社内全体に共有することが文化として根付いていますが、オンライン会議はGoogle Meetを使用しており、現時点ではMicrosoft Teamsのような標準機能としての日本語対応の文字起こし機能(※英語は対応可能)や自動議事録生成機能がないため、情報を共有したい場合は手動で議事録を作成して共有するしかない状況です。たくさんある会議から会議ごとに議事録を作成して展開する作業はメンバーにとって大きな負担となっており、何かいい方法がないかと常にメンバー間で模索していました。 こうした状況の中、ある日に当社のリードエンジニアTさんが開発チームのSlackチャンネル上で「会議後に自動で議事録を作成し、Slackに投稿できるアプリがあれば効率的なのでは？」と呟き、このアイデアに挑戦するメンバーを募り始めました。 私自身、当時は生成AIを活用するプロジェクトに関わる機会が少なかったため、Geminiを用いたアプリを一から構築してみたいと思いはじめ、 かつ、「やってみる」という弊社のValueの1つを実現できることをアピールしたく、Tさんの募集に挙手したのが開発のきっかけになります。笑 作成したアプリの構成および議事録作成手順 作成したアプリの構成と動作について紹介します。 構成 作成したAI議事録生成アプリ構成 このアプリでは、フロントエンドにNext.js（App Router）、バックエンドにFastAPIをフレームワークとして使用しております。 FastAPIのバックエンドアプリ内では、Vertex AI SDK for Pythonを用いて議事録生成処理を行い、Slack SDKを使って、生成された議事録をSlackに自動投稿できるようにしています。議事録生成はGemini APIを直接利用することも可能ですが、社内の会議データを扱うため、データが学習に使われないVertex AI経由で利用しました。 議事録生成に使用するファイルはGoogle Cloud Storageにアップロードし、VertexAIから参照しています。この理由は、Vertex AIのプロンプトに直接7MB以上のファイルを挿入できず、一旦Cloud StorageにアップロードしてからプロンプトからCloud Storageからインポートする方法しか使えないからです。 なお、フロントエンドのフレームワークとして、Next.jsのApp Routerを選んだ特別な理由はありませんでしたが、ちょうどその時期に私が主催するNext.js（App Router）の勉強会を開催していたため、実践も兼ねてNext.jsを使って開発することにしました。勉強会の参加メンバーに「現在検証中の議事録自動生成アプリでApp Routerを一緒に試してみませんか？」と提案したところ、協力を得られたため、勉強会のメンバーで開発を進めました。 議事録作成手順 会議の録画 社内のあらゆる会議で、会議の主催者に会議開始時から録画してもらうように依頼しました。 会議終了後には録画データおよびチャット履歴ファイルは会議の主催者の個人ドライブに届くため、私がダウンロードできるように主催者にデータを共通ドライブに移動してもらっています。 なお、私がカレンダーの主催者である場合は、共通ドライブに移動しなくてもダウンロード可能ですが、データの一元管理を目的として、すべてのデータを共通ドライブに移動する運用としました。 ファイルのアップロードと議事録の投稿 フロントエンドアプリを使って議事録の作成と投稿を行います。操作は至って単純ですが、主に以下の流れで行います。 アプリ画面・議事録投稿手順 ① 会議のファイル選択、会議情報入力 録画動画、チャット履歴ファイル、会議中にメンバーが共有したメモファイルなどを選択します。これらのファイルは後、Google Cloud Storageにアップロードされ、議事録生成に使用されます。 議事録をSlackに送信する場合は、Slackチャンネルも選択します。 日付、会議名、Google Drive（共通ドライブ）のURLなど、会議に関する基本情報も入力します。日付や会議名は議事録作成時の補完に使われ、Google DriveへのURLはSlack通知の際に動画の視聴リンクとして付け加えています。 ② 生成ボタン押下 画面上では生成ボタンを押すだけで議事録が自動的に生成され、Slackチャンネルに送信されますが、裏側ではFastAPIアプリへのAPIリクエストが行われています。具体的な処理は FastAPIアプリにAPIリクエストを送信し、各ファイルをGoogle Cloud StorageにアップロードするためのPresigned URLを生成します。 PresignedURLを取得できた後、FrontendアプリからPresignedURLを使ってGoogle Cloud Storageへアップロードをアップロードします。 ファイルアップロード完了後、再度FastAPIにリクエストを送り、議事録をVertex AIで生成し、生成された議事録をSlackに投稿します。 といった流れになっています。 プロンプトに関してはまだ最適案ではないですが、以下のようなものを使用しました。 あなたはプロフェッショナルな会議議事録作成者です。 あなたのタスクは、インプットデータを使用して、会議の議事録を作成することです。 # インプットデータ - 会議の録画動画: 会議中に録画された動画ファイル。 - チャット履歴: 会議中に送信されたチャットメッセージの履歴を含むPDFファイル。各メッセージには発言者名とタイムスタンプが含まれています。 - メモ: 会議中に作成されたメモ - その他資料: 会議中に使用されたその他の資料 会議の録画動画: [録画動画のURI] チャット履歴:[チャット履歴のURI] メモ: [メモのURI] その他資料: [その他資料のURI] # Steps 1. **会議内容の把握:** 会議の録画動画、チャット履歴、メモなどを参照し、会議の内容を把握してください。 - 会話と会議録画に投影された内容から主なトピックを特定し、内容を抽出してください。 - チャット履歴、メモ、その他資料を参照して、会議の内容を理解してください。 - トピックが変わるタイミングを検知し、トピックごとに発話内容を発言者に紐づけてグループ化してください。 - 決定事項やアクションアイテムを特定してください。 2. **情報の整理**: 抽出した情報をわかりやすいセクションに整理します。関連する情報をひとつのセクションにまとめて、読みやすさを優先します。 3. **議事録の作成**: Markdown形式で議事録を作成します。重要なポイントを適切な階層の見出し(#)で整理し、段落や箇条書きなどを活用して情報を明瞭に表現します。 4. **レビューと修正**: 完成した議事録を確認し、誤りや不足があれば修正してください。 # Output Format - 議事録はMarkdown形式で出力してください。 - タイトルやセクションには見出し(#)を使用し、適切な階層を設定する - 箇条書きや番号付きリストを適宜使用し、情報を整理する ③ 議事録を確認 : 生成された議事録はSlackに送信されると同時に、画面上でも表示されます。Slackへの送信したイメージは以下です。 Slack議事録投稿 半年間使用する中で、自動生成された議事録に調整が必要と感じる部分が多かったため、次の2つの方法で対応しました。 Slackへの自動送信機能を使用せず、画面上に表示された議事録をコピーし、VSCodeなどのエディターで修正してから正式な議事録を展開する。 Slackへの自動送信機能で議事録を自動的に送信し、送信後のスレッド上で内容を修正する。 半年間運用して得られた学び 議事録自動生成の精度がどうだったか？ 今回、プロンプト設計についての深い調整は行いませんでしたが、ある程度質の高い議事録が生成できたと感じています。 生成AI特有のハルシネーション（生成AIによる誤情報や虚偽の提示）も一部見られましたが、会議に参加していなかったメンバーでも、会議で交わされた内容が把握できるレベルの議事録が生成されました。また、アクションアイテムや次回の予定も概ね正確だったと思います。 さらに今回は、音声データを使用するだけではなく、録画動画やチャット履歴ファイル、その他のメモファイルの情報を全て合わせてインプットし、マルチモーダルAIによる議事録生成を行ったため、会議中に投影された資料やチャット内容も参考情報として使用され、いい感じに議事録に統合されました。そのため、議事録の正確性がかなり向上できたと思います。 使用したモデルおよびコストについて モデル 検証開始時は議事録生成にマルチモーダル対応の Gemini-1.5-Pro-001 モデルを使いました。 Gemini 1.5 Flash と Gemini 1.5 Pro モデルの主な違いはコンテキストウィンドウの大きさ、処理速度、コストにありますが、その中で Gemini 1.5 Pro が優れているものが コンテキストウィンドウの大きさだけ だと思います。 Gemini 1.5 Pro は最大200万トークンのコンテキストウィンドウに対応しているのに対し、 Gemini 1.5 Flash は、100万トークンまでしか対応していないのです。 今回検証で使用した会議はほぼ30分や1時間の会議のため、 Gemini 1.5 Flash を使うとどうしても上限の100万トークンに引っかかってしまい、動画の分割などを行わないとそのまま使えませんでした。一方で、 Gemini 1.5 Pro を使うと、トークン上限にかかることがほぼなく、精度に関してもそこそこ良い結果のものが得られたので、今回はコスト面を多少無視して、 Gemini 1.5 Pro を使いました。ちなみに、1時間の会議で試した場合、約101万トークン( Flashモデルの上限に対して、約1万トークンオーバー )がかかりました。 また、2024年9月にGoogle社が Gemini-1.5-Pro-002 と Gemini-1.5-Flash-002 の新バージョンをリリースした時も、即座に Gemini-1.5-Pro-002 に切り替えて運用してみました。001バージョンとはしっかり比較できていないですが、生成速度および生成された議事録の質が多少改善されたように感じています。 コスト Gemini-1.5-Pro-002 を使った場合のコストについてですが、例えば1時間の会議の議事録を取得する場合、1時間の動画入力( 録画動画 )、1枚の画像( チャット履歴等のファイルをPDF化したもの、PDFは画像としてカウントされるため )、1000文字のテキスト入力( プロンプト等 )、3000文字のテキスト出力( 議事録の結果 )が必要になります。 VertexAIの料金 に基づいて、以下のように計算できます。 動画入力: 1時間（3600秒）× $0.00263/秒 = $9.468 画像入力: 1枚 × $0.00263/枚 = $0.00263 テキスト入力: 1000文字 × $0.0025/1000文字 = $0.0025 テキスト出力: 3000文字 × $0.0075/1000文字 = $0.0225 合計で、 約$9.50（約1,500円程度） が1回の議事録の生成にかかっていることが分かりました。 これを見ると、1回の議事録の生成に約1,500円もかかることは正直少し高く、コスパが悪いと感じました。今回は学習目的も含めて社内検証のために使用していたため、このコストは許容範囲内でしたが、実運用に移行する際には、コスト面も考慮しなければならないと感じました。 一方で、もしインプットデータのサイズが100万トークン以内に収まることができたら、 Gemini 1.5 Flash を使用し、コストをビックリするほど削減できます。 動画入力: 1時間（3600秒）× $0.00004/秒 = $0.144 画像入力: 1枚 × $0.00004/枚 = $0.00004 テキスト入力: 1000文字 × $0.0000375 /1000文字 = $0.0000375 テキスト出力: 3000文字 × $0.00015/1000文字 = $0.00045 なんと、合計で 約$0.145（約22円程度） しかかからないのです。このコストであれば、すごく魅力的だと思いました。 安全フィルターについて 検証初期には、 安全フィルター の基準が高く、社内の会議で使用している動画が安全フィルターの「少量をブロック（ BLOCK_ONLY_HIGH ）」設定でも PROHIBITED_CONTENT エラーに引っかかり、何度か議事録生成に失敗しました。当初、公式のドキュメントには「ブロックなし（BLOCK_NONE）」レベルの設定も可能とありましたが、設定しても 400 Bad Request エラーが発生し、VertextAIのコンソール画面上でもこの選択ができない状態を確認しました。 その後、2024年9月の Gemini-1.5-Pro-002 がリリースされた時点と同時期に、 BLOCK_NONE が設定できるようになったという情報を受け、この設定で運用したところ問題なく生成が成功するようになりました。 プロンプトおよび生成過程について 検証初期から、特別にプロンプト設計を意識するや、「文字起こしをしてから議事録を生成する」や「議事録生成後に事実チェックを行う」といった複数ステップの手順は導入せず、ほぼ一発で議事録を生成する方法を試してきました。この手順でも、社内での情報共有用途としてはある程度機能しましたが、半年にわたり様々な会議で試したところ、やはりハルシネーションが多少目立つように感じています。内容の90%程度は正確であるものの、残り10%に誤情報が含まれていると、議事録の信頼性が損なわれてしまうため、社内利用はできるものの、複数のステークホルダーに展開するプロジェクト議事録として使用するには難しいと感じました。 こうした点からも、プロンプトの調整やステップを踏むプロセスの重要性を実感しています。現在は、生成AI案件を多く手がける社内メンバーや、生成AIに特化した技術研究チームのメンバーにも意見を聞きながら、このプロンプトを改善し、さらに信頼性を高めた生成過程を模索していきたいと思っています。 VertexAI Geminiの凄さについて 今回、コスト面ではまだ改善されるべきなところもありますが、何よりもVertex AI Geminiの凄さを実感できました。 通常、議事録生成には音声データテキスト変換(文字起こし) を行い、そのテキストデータを元に議事録の生成処理をする必要がありますが、Vertex AIではこの変換を個別に行う必要がなく、録画動画やチャット履歴、メモなどをそのままインプットでき、直接議事録を生成できる点から、特に複雑なシステムを構築する必要がなく、簡単な構成とプロンプトで議事録を生成できる点が大きなメリットだと感じました。 録画動画から会議中に投影された資料の内容も参照されて、議事録作成に使用されるで議事録の内容がよりリッチになっていることも、とても感動しました。 議事録を投稿できるまでの手順の制限について 今回のアプリができたことによって、議事録を展開するところまでは少し楽になりましたが、主催者でない人が操作する場合、録画動画を共通ドライブに移動(または権限変更)しなければならない点や、各種ファイルを一度ダウンロードしてから、アプリを使って再度アップロードする手順がかなり手間と感じました。会議終了後、誰でもアプリから該当のカレンダー予定を指定するだけで、あとは自動的に処理されることが理想ですが、Google Meetでは録画がカレンダー主催者のマイドライブに保存される点や、Vertex AIがCloud Storageのみ参照できる点がボトルネックになってしまっています。 Google Workspace APIを使用して、Google Calendar、Google Meet、Google Driveと上手く連携できる仕組みを早く構築しなければと感じました。 また、Cloud Storageの料金もかかりますので、コスト面も配慮しなければならないですね。 まとめと今後の期待 VertexAI Geminiを使って社内用AI議事録生成アプリの開発と個人的に学んだことについて紹介させていただきました。 半年運用してみた結果、実用性のある成果を得られましたが、まだ改善点が多いと感じています。今後は以下の点を意識しながらアプリの向上を目指したいと思います。 プロンプトおよび生成過程の改善による精度向上 Google DriveやGoogle Calendarとの連携によるアプリ操作簡略化 社内のエンジニアだけでなく全メンバーが使えるようなホスティング環境とアクセス制限の整備 まだまだやることが多いですね。笑 やるべきことは多いですが、正直のところ、そのうちにGoogle Workspaceのコアサービスとしてこの機能がリリースされるのではないか！とその日をずっと期待しています。 標準機能のリリースを期待しつつ、せっかくある程度開発できたので、まずは社内での活用を広げ、改善を重ねていきたいと思います。

目次 1. はじめに 2. ログデータの収集 GCP インフラ構成の説明 各サービスの設定 ディレクトリ構成 共通リソースの作成 個別プロジェクトリソースの作成 3. ログデータの可視化 4. まとめ 1. はじめに こんにちは。Insight Edge で Developer をしている熊田です。 普段システム開発を進める上で、システムの利用者数や頻繁に利用されている機能を調べたいと思うことはありませんか？ 特にPoC検証やシステム運用フェーズにおいては、そのようなニーズが多くあるのではないでしょうか。 そのようなニーズに応えるためには、ログを収集する必要があります。また、上記のようなニーズはプロジェクト共通のものであることが多いかと思います。 これら要望に応えるために、GCP の複数プロジェクトにまたがるログ収集及び可視化をするためのロギング基盤を検証構築してみたので、その紹介をしたいと思います。 2. ログデータの収集 GCP インフラ構成の説明 まず、インフラ構成図は以下の通りです。 簡単に構成を説明します。 ① 各プロジェクトにて Cloud Logging にログを出力することを前提としています。 ② ログ Sync を作成しフィルタ機能を利用して必要なログのみ、ログ収集用プロ 　ジェクトの Cloud Storage(以下GCS) にログを転送します（1時間毎）。 ③ Eventarc を利用して、GCS にログが転送されたことをトリガーに Workflows を 　起動します。 ④ Workflows にて、定義済みの Dataflow を実行し、ログを BigQuery に格納します。 　なお、Dataflow 実行時に必要なファイル群は GCS に格納しています。 ⑤ BigQuery に格納されたログデータを Looker Studio で可視化します。 各サービスの設定 基本的には Terraform コードを利用し、一部は GCP コンソール作業やシェルスクリプト作業をしています。以下に実装詳細を記載します。 ディレクトリ構成 . ├── BQ │ └── create_table.sql ├── logger_sync │ ├── sample_service_A │ │ └── create-sync.sh │ └── sample_service_B │ └── create-sync.sh └── terraform ├── env │ ├── dev │ │ ├── common │ │ │ ├── common.tfvars │ │ │ ├── dataflow_config │ │ │ │ ├── schema │ │ │ │ │ └── usage_log.json │ │ │ │ └── udf │ │ │ │ └── transform.js │ │ │ ├── main.tf │ │ │ ├── variables.tf │ │ │ └── workflow.yaml │ │ ├── sample_service_A │ │ │ ├── main.tf │ │ │ ├── sample_service_A.tfvars │ │ │ └── variables.tf │ │ └── sample_service_B │ │ ├── main.tf │ │ ├── sample_service_B.tfvars │ │ └── variables.tf │ └── prd └── modules ├── aws ├── azure └── gcp ├── eventarc │ ├── main.tf │ └── variables.tf └── gcs ├── main.tf ├── output.tf └── variables.tf 共通リソースの作成 まずは、共通で利用するリソースを以下の通り作成していきます。 BigQuery 今回は BigQuery テーブルをコンソールから作成していきます。 データセットを作成し、その後クエリエディタに以下のステートメントを入力および実行してテーブルを作成します。 ./BQ/create_table.sql CREATE TABLE `[project].sample_dataset.usage_log` ( timestamp TIMESTAMP NOT NULL OPTIONS(description= " ログ日時 " ), service_name STRING NOT NULL OPTIONS(description= " サービス名 " ), user_id STRING NOT NULL OPTIONS(description= " ユーザID " ), activity_name STRING NOT NULL OPTIONS(description= " アクティビティ名 " ) ) PARTITION BY TIMESTAMP_TRUNC( timestamp , DAY) 各種 Terraform ファイル ./terraform/env/dev/common/common.tfvars project_id = [ ロギング基盤プロジェクトのプロジェクトID ] default_region = "asia-northeast1" prefix = "logging-common" env = "dev" ./terraform/env/dev/common/variables.tf variable "project_id" {} variable "default_region" {} variable "prefix" {} variable "env" {} ./terraform/env/dev/common/main.tf ## Provider ## provider "google" { project = var.project_id region = var.default_region } locals { dataflow_config_files = [ "schema/usage_log.json" , "udf/transform.js" ] } ## GCS ## resource "google_storage_bucket" "bucket" { name = "dataflow-config-$ { var.env } -$ { var.prefix } " location = var.default_region project = var.project_id storage_class = "STANDARD" public_access_prevention = "enforced" uniform_bucket_level_access = true force_destroy = true } ## Uplaod dataflow config files to GCS ## resource "google_storage_bucket_object" "dataflow_config_files" { for_each = toset (local.dataflow_config_files) name = each.value bucket = google_storage_bucket.bucket.name source = "$ { path.module } /dataflow_config/$ { each.value } " } ## Workflows ## resource "google_workflows_workflow" "dataflow_workflow" { name = "dataflow-$ { var.env } -$ { var.prefix } " description = "Workflow for dataflow" project = var.project_id region = var.default_region source_contents = file ( "$ { path.module } /workflow.yaml" ) } GCS 上記 main.py の通り、GCS を作成し Dataflow で利用する スキーマ定義ファイル、UDF スクリプト（ユーザ定義関数）を GCS にアップロードします。 ./terraform/env/dev/common/dataflow_config/schema/usage_log.json { " BigQuery Schema ": [ { " name ": " timestamp ", " type ": " TIMESTAMP ", " mode ": " REQUIRED ", " description ": " ログ日時 " } , { " name ": " service_name ", " type ": " STRING ", " mode ": " REQUIRED ", " description ": " サービス名 " } , { " name ": " user_id ", " type ": " STRING ", " mode ": " REQUIRED ", " description ": " ユーザID " } , { " name ": " activity_name ", " type ": " STRING ", " mode ": " REQUIRED ", " description ": " アクティビティ名 " } ] } ./terraform/env/dev/common/dataflow_config/udf/transform.js function transform ( data ) { const record = JSON . parse ( data ) ; // timestampをBigQueryで扱える形式に変換 timestamp = record . jsonPayload . timestamp . replace ( "T" , " " ) . replace ( "+0900" , "+09:00" ) ; // 新しいJSONオブジェクトを作成 const transformedRecord = { project_id : record . jsonPayload . project_id , timestamp : timestamp , service_name : record . jsonPayload . service_name , user_id : record . jsonPayload . user_id , activity_name : record . jsonPayload . activity_name , } ; // 変換後のJSONオブジェクトを文字列にして返す return JSON . stringify ( transformedRecord ) ; } Workflows 上記 main.py の通り、Dataflow ジョブを作成するワークフローを定義します。 その際に、下記の Dataflow 定義 yaml ファイルを参照しています。 ./terraform/env/dev/common/workflow.yaml # Dataflowのジョブを作成するワークフロー main : params : [ event ] steps : - init : assign : - project_id : ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")} - location : ${sys.get_env("LOCATION")} - input_bucket_name : ${event.data.bucket} - input_file : ${event.data.name} - service_name : ${sys.get_env("SERVICE_NAME")} - config_bucket_name : "dataflow-config-dev-common" // 設定ファイルを配置したバケット名 - bq_dataset : "sample_dataset" // BigQueryのデータセット名 - table_name : "usage_log" // BigQueryのテーブル名 - event_log : call : sys.log args : text : '${"input_bucket_name: " + input_bucket_name + ", input_file: " + input_file}' - create_dataflow : call : googleapis.dataflow.v1b3.projects.locations.templates.create args : projectId : ${project_id} location : ${location} body : jobName : dataflow parameters : javascriptTextTransformGcsPath : ${"gs://" + config_bucket_name + "/udf/transform.js" } JSONPath : ${"gs://" + config_bucket_name + "/bq_schema/" + table_name + ".json" } javascriptTextTransformFunctionName : transform outputTable : ${project_id + ":" + bq_dataset + "." + table_name} inputFilePattern : ${"gs://" + input_bucket_name + "/" + input_file} bigQueryLoadingTemporaryDirectory : ${"gs://" + config_bucket_name + "/temp" } gcsPath : gs://dataflow-templates-asia-northeast1/latest/GCS_Text_to_BigQuery result : output 個別プロジェクトリソースの作成 次に、各プロジェクト毎に必要なリソースを作成していきます。 Terrafom コードは以下の通りです。 ./terraform/env/dev/sample_service_A/sample_service_A.tfvars project_id = [ ロギング基盤プロジェクトのプロジェクトID ] default_region = "asia-northeast1" env = "dev" workflow_name = "dataflow-dev-logging-common" eventarc_service_account_email = [ Eventarc のサービスアカウント ] service_name = "sample-service-A" # サービスごとに変更 ./terraform/env/dev/sample_service_A/variables.tf variable "project_id" {} variable "default_region" {} variable "env" {} variable "workflow_name" {} variable "eventarc_service_account_email" {} variable "service_name" {} ./terraform/env/dev/sample_service_A/main.tf ## Provider ## provider "google" { project = var.project_id region = var.default_region } locals { prefix = "$ { var.env } -$ { var.service_name } " } ## GCS ## module "google_storage_bucket" { source = "../../../modules/gcp/gcs" project_id = var.project_id default_region = var.default_region prefix = local.prefix } ## Eventarc ## module "eventarc" { source = "../../../modules/gcp/eventarc" project_id = var.project_id default_region = var.default_region prefix = local.prefix service_account_email = var.eventarc_service_account_email gcs_bucket_name = module.google_storage_bucket.bucket_name workflow = "projects/$ { var.project_id } /locations/$ { var.default_region } /workflows/dataflow-dev-logging-common" } GCS 他プロジェクトから転送されるログを格納する GCS を作成します。 ./terraform/modules/gcp/gcs/main.tf # GCS resource "google_storage_bucket" "bucket" { name = "log-bucket-$ { var.prefix } " location = var.default_region project = var.project_id force_destroy = true } ./terraform/modules/gcp/gcs/variables.tf variable "project_id" {} variable "default_region" {} variable "prefix" {} ./terraform/modules/gcp/gcs/output.tf output "bucket_name" { value = google_storage_bucket.bucket.name } Eventarc GCS にログが転送されたことをトリガーに Workflows を起動するための Eventarc を作成します。 ./terraform/modules/gcp/eventarc/main.tf # Create an Eventarc trigger, routing Cloud Storage events to Workflows resource "google_eventarc_trigger" "default" { name = "workflows-trigger-$ { var.prefix } " location = var.default_region # Capture objects created in the specified bucket matching_criteria { attribute = "type" value = "google.cloud.storage.object.v1.finalized" } matching_criteria { attribute = "bucket" value = var.gcs_bucket_name } # Send events to Workflows destination { workflow = var.workflow } service_account = var.service_account_email } ./terraform/modules/gcp/eventarc/variables.tf variable "project_id" {} variable "default_region" {} variable "prefix" {} variable "gcs_bucket_name" {} variable "workflow" {} variable "service_account_email" {} ログ Sync の設定 サービスが配置されるプロジェクト(構成図での A プロジェクト)にて、ログ Sync を作成します。 フィルタ機能を利用して必要なログのみ、ログ収集用プロジェクトの GCS にログを転送します（1時間毎）。 今回の例では、 jsonPayload.usage_monitoring: true のログのみを転送するように設定しています。 スクリプト内容は以下の通りです。 ./logger_sync/sample_service_A/create-sync.sh SERVICE_NAME =sample-service-A # サービス名 DESTINATION_PROJECT_ID = [ project_id ] # ログ出力先のプロジェクトID DESTINATION_BUCKET_NAME =log-bucket-dev-sample-service-A # ログ出力先のバケット名 SINK_NAME = $SERVICE_NAME -sink-to-logging-project SINK_DESTINATION =logging.googleapis.com/projects/ $DESTINATION_PROJECT_ID /locations/global/buckets/ $DESTINATION_BUCKET_NAME \ gcloud logging sinks create $SINK_NAME $SINK_DESTINATION --log-filter ' jsonPayload.usage_monitoring: true ' ログの出力 別途 Cloud Function や Cloud Run 等を構築し、構造化ログを Cloud Logging に出力します。 今回は下記のようなログが JSON ペイロードで出力されることを前提としています。 { jsonPayload : { " usage_monitoring ": True ,　 // ログ収集用のフラグ " timestamp ": " 2024-10-01T00:00:00 ", // ログ日時 " service_name ": " service1 ", // サービス名 " user_id ": " test@example.com ", // ユーザID " activity_name ": "act1_start" // アクティビティ名 } } 3. ログデータの可視化 収集したログデータを可視化するために、Looker Studio を利用しました。 選んだ理由は、お手軽にダッシュボードを作成できるからです。 というのも、Looker studio は 単純な集計であれば 直感的に UI 操作のみで可視化ができるため、専門的なスキルがなくても扱えます。 例えば、以下のようなアクティビティ及びユニークログイン数を集計したグラフを、ブラウザ操作のみで作成することができます。 Looker Studio 操作方法等については 公式ドキュメント をご参照ください。 4. まとめ 以上、ロギング基盤構築のご紹介でした。なお、構築はできたものの最低限の機能であり、まだまだ改善の余地があります。 今のところは共通プロパティのみの集計でしたが、実用性を考えると各プロジェクトで個別で集計したいプロパティもあると思うので、そちらも集計できるように改修したいと思っています。 また、今回は検証ということで GCP 環境のみを対象にしていましたが、当社では、AWS、Azure も使ってシステム開発を行っています。 今後は、マルチクラウドに対応したロギング基盤の構築にも取り組んでいきたいと考えています。また、ディレクトリ構成についても、より適切な構成を検討していきたいです。

Insight Edgeのデータサイエンティストのki_ieです。 数理最適化の専門家として、これまでさまざまな課題を数理最適化問題としてモデリングしてきました。 モデリングはアルゴリズム設計と比べて注目を集めることが少ないようですが、 実際には技術的な知見・調査を要求する骨の折れるタスクです。 このタスクを簡単にしたいとは日々思っていたところですが、最近 OpenAI o1 というモデルの論理的推論能力が高いらしいという聞きました。この賢いLLMがモデリングのお手伝いをしてくれたら嬉しいですね！ 今日は数理最適化問題(混合整数計画問題)のモデリングをどれだけLLMに任せられるのか、簡単な実験結果をご紹介します。 数理最適化問題とは 数理最適化問題と混合整数計画問題の基礎知識がある方はこの節はスキップしましょう(面白いことは一つも書いてありません)！ 数理最適化問題とその実行可能解・最適解 数理最適化問題とは「変数・制約・目的関数」が与えられたときに、 「制約を守るなかで最も目的関数を小さく(または大きく)する決定変数を選ぶ」 という問題です。 数理最適化問題は、一般に以下の形で表現できます: 数理最適化問題 変数 : $x \in D \ \ (\subseteq \mathbb{R}^n)$ 変数 $x$ は $D$ の中から選べる 制約 : $g_i(x) \leq b_i \ \ (i \in I)$ $x$ は $g_i(x) ≤ b_i$ がすべての $i \in I$ について成り立つように選ぶ 目的関数(最小化) : $\min f(x)$ 上記ルールを守ったうえで $f(x)$ を最小化したい。 上手に $D$, $g_i$, $f$ を設計してやることで、配送計画から証券ポートフォリオの最適化まで幅広い問題が 数理最適化問題として表現できることが知られています。 たとえばコンビニの店長の立場でおにぎりの仕入れ量を適正化する問題を単純化すれば、以下のような最適化問題としてモデル化できます: 例: おにぎりの仕入れ量の適正化 変数: おにぎりに仕入れ量 $x \in \mathbb{Z}_+$ 制約: おにぎりが店から溢れない $x \leq 100$ 目的関数: $\max f(x)$ $f(x)$ : おにぎり $x$ を仕入れたときの期待利益 $D$ の要素で制約をすべて守るものはその問題の実行可能解と呼ばれます。 実行可能解のうち目的関数を最小にするものは数理最適化問題の最適解(または解)と呼ばれます。 数理最適化問題で課題をモデリングする目的は、最適解を得ることにあります。 たとえばおにぎりの仕入れ量の適正化の文脈では最も利益があがる仕入れ量が $70$ であれば、$x=70$ が最適解です。 これが計算で求められれば、このコンビニでは利益を最大化する仕入れの意思決定ができるようなってハッピーです。 一方、問題によっては最適解を求めることが極めて難しいことがあります。 おにぎりの仕入れ量の適正化問題は$x=0, 1, 2 \cdots 100$ を全探索すれば簡単に最適解が求まりますが、 もっと複雑な問題ではそうはいかないこともしばしばあるのです。 そのような場合は「目的関数値の良い」実行可能解が求まったらそれでよしとすることが実務上は一般的です。 おにぎりの仕入れ量の問題で言えば、$x=68, 71$ といった解が見つかって、$x=70$ が見つけられなかったら、 $x=68, 71$ をとりあえずの答えとして採用するというイメージです。 この場合でも、あてずっぽうで仕入れ量を決定するコンビニよりは利益を大きくできるわけです。 混合整数計画問題 数理最適化問題の中でも特別に重要な問題クラスとして、混合整数計画(MIP; Mixed Integer Programming)問題があります。 これは実行可能領域 $D$ を$\mathbb{R}^n \times \mathbb{Z}^m$ として、制約・目的関数を線形なものに限定したものです。 混合整数計画問題 変数 : $x \in \mathbb{R}^n \times \mathbb{Z}^m$ 制約 : $a_i^\top x \leq b_i \ \ (i \in I)$ $a_i^\top$ を行ベクトルとして集めた行列を$A$, $b_i$ を集めたベクトルを $b$ としたら、まとめて $Ax ≤ b$ と書ける。 目的関数(最小化) : $\min c^ \top x$ 変数に別途上下限を許す場合も、等号制約を許す場合もある。いずれもここで示した形に容易に変形できる この問題クラスの重要性を説明するために、まず数理最適化を利用した課題解決の一般的な流れを説明します。 さまざまなタイプの数理最適化問題に対して、最適解または最適解ではないにせよ目的関数値の良い実行可能解を求めてくれるプログラムが作られています。これらのプログラムはよく「ソルバー」とよばれます。数理最適化の考え方とソルバーを利用して現実の課題を解くときの流れは以下のようになります。 課題の整理 課題を数理最適化問題としてモデル化 数理最適化問題をソルバーで求解する 得られた最適解(または目的関数値の良い実行可能解)を現実世界で採用する 課題を数理最適化問題に落とし込むことにも技術的な難しさがありますが、 その数理最適化問題を解くソルバーを設計・実装することもまた大変に難しいことです。 そのため、できれば既存のソルバーを用いて求解できるような範囲でモデル化をしたいというのが数理最適化エンジニアの本音です。 MIPによるモデリングはこの観点で大変すぐれています。MIPは多様な問題を表現でき、さらに優れたソルバーが存在するからです。 MIPは制約・目的関数が線形に限定されているため一見すると限られた表現力しかないように見えますが、0, 1の値しかとらないバイナリ変数を巧みに使うことで複雑な論理関係を表現でき、幅広い問題を表現可能です。表現できる問題の幅広さゆえ、学術的にも深く研究され、ソルバーの研究が積み重ねられてきました。その結果、優れた商用・OSSのソルバーが存在するのです。 このような背景から、MIPによるモデリングは数理最適化の実務においてなくてはならない基本技術となっています。 LLMに混合整数計画問題をモデリングさせたいモチベーション 課題のMIPモデリングというのはなかなか骨の折れる作業です。 論理的に正しいというだけではなくソルバーにとって解きやすいモデルを作ることが求められるため、 難しい課題の場合は最適化モデルの試行錯誤・調査の1サイクルだけで数日かかってしまう、ということも稀ではありません。 この作業、なるべくサボりたいですね。性能向上の著しいLLMに手伝ってもらえれば、 まるごと作業代替とはならなくとも効率化できるのではないか？というのが、本記事で検証したいポイントです。 数理最適化エンジニアとして確認したい具体的なポイントは以下の3つです。 有名問題をモデル化できるか / 有名定石を利用できるか？ 有名問題に簡単な要件を追加してもモデル化がうまくいくか？ 複雑な要件を上手にモデル化できるか？ LLM に 1. ができたら、数理最適化初心者/学習者にはLLMによる補助が有用だと考えられるでしょう。 数理最適化問題のモデリングにはさまざまな「定石」が登場します。 例えば、0/1変数 $x, y \in \{0, 1 \}$ の論理積をMIPの枠組みで考えたいときには、補助変数 $z \in \{0, 1 \}$ を導入して 制約 $z ≤ x, z ≤ y, x+y-1≤z$ を加えれば $z$ は $x, y$ の論理積(AND)となる、というテクニックがあります。 知っていれば簡単に使えるテクニックですが、自分で思いつくのは難しいです。 初心者がこれをLLMに教えてもらえるなら、学習効率は上がりそうですね。 ある程度経験のある数理最適化エンジニアにとっても、モデル化方法の検討がつかないときのサーベイの代替として LLMに聞くというのが有用になるかもしれません。 2.ができたら、実務的なモデリングの補助としても使えそうです。 実際の問題は有名定石単体で解けないケースのほうが多く、 そのような場合定石を組み合わせたり、自分でテクニックを作ってモデル化する必要があります。 ここまでLLMがやってくれるなら、実務的なモデリングの補助として十分有用でしょう。 3.は、ここまでできたらモデリングの初手はLLMとの対話になりそうですね。 これで毎回完璧な答えが出てきたら私達は冷や飯を食わされることになりそうですが…どこまでできるか見てみましょう。 LLM に数理最適化問題をモデリングさせる 現在利用可能な o1 モデルの o1-mini モデルを利用して実験を行います。 確認したいポイントに対応させて、3つのレベルに分けて実験を進めましょう。 1. 有名問題をモデル化できるか/有名定石は使えるか？ まずは有名問題・有名定石のモデリングをさせてみましょう。毛色の違う2つの有名問題を解かせてみます。 巡回セールスマン問題 o1-mini へ次の質問を投げました: 次の課題を混合整数計画問題としてモデル化してください。 「10個の都市をすべて回って出発地点に返ってくる必要がある。移動時間を最短化したい。」 結果は「パラメタ」「決定変数」「制約」「目的関数」の4セクションに分けてください。 これは巡回セールスマン問題という有名問題で、特殊なモデリングの技法が使われていますが「知っていれば書ける」タイプの問題です。 o1-mini の出力を見てみましょう。見出しのレベルだけ編集で本文に合うように揃えている点以外、出力そのままです。 パラメタ $ N = \{1, 2, \dots, 10\} $: 10個の都市の集合。 $ t_{ij} $: 都市 $ i $ から都市 $ j $ への移動時間（$ i, j \in N $, $ i \neq j $）。 決定変数 $ x_{ij} \in \{0,1\} $: 都市 $ i $ から都市 $ j $ へ移動する場合に1、そうでない場合に0。 $ u_i $ （連続変数）: 都市 $ i $ の訪問順序を表す補助変数（サブツアー除去のため）。ここでは都市1を出発地点とし、$ u_1 = 1 $ とする。 制約 各都市からちょうど1つの都市へ出発する $$\sum_{\substack{j \in N \\ j \neq i}} x_{ij} = 1 \quad \forall i \in N$$ 各都市へちょうど1つの都市から到着する $$\sum_{\substack{i \in N \\ i \neq j}} x_{ij} = 1 \quad \forall j \in N$$ サブツアーを防止するための順序変数に関する制約（ミラー・タミルゾーラックの制約） $$u_i - u_j + 10 \cdot x_{ij} \leq 9 \quad \forall i, j \in N, \, i \neq j$$ 順序変数の範囲制約 $$2 \leq u_i \leq 10 \quad \forall i \in N \setminus \{1\}$$ 目的関数 総移動時間を最小化する： $$\min \sum_{i \in N} \sum_{\substack{j \in N \\ j \neq i}} t_{ij} \cdot x_{ij}$$ このモデルは、10個の都市を全て一度ずつ訪問し、出発地点に戻る巡回経路（ツアー）を見つけるための混合整数計画問題として定式化されています。制約条件により、各都市の出発と到着が一度ずつ行われることを保証し、順序変数を用いることでサブツアーの発生を防いでいます。目的関数は、全体の移動時間を最小化することを目指しています。 正しく巡回セールスマン問題がモデリングできているようですね！ 人名だけ間違っているようです。 制約 3., 4. は Miller-Tucker-Zemlin (MTZ) 定式化などと呼ばれます(正確には制約3., 4.を含むこのモデル全体を指す言葉だと思います)。 o1-mini の出力では「ミラー・タミルゾーラック」という知らない人の名前が出てきましたが、これはMTZの人名が日本語で書かれることが稀であるから起きる間違いかもしれませんね。 ちょっと怪しい言葉が登場してしまいましたが、o1-mini は巡回セールスマン問題を「知っている」ということがわかりました。 クラス分け問題 別の有名問題、クラス分け問題を定式化をしてみましょう。 o1-mini へ次の質問を投げました。 次の課題を混合整数計画問題としてモデル化してください。 「120人の学生を3つのクラスに分けたい。3つのクラスの人数は等しくしたうえで、クラス間の成績のばらつきを最小に抑えたい。」 結果は「パラメタ」「決定変数」「制約」「目的関数」の4セクションに分けてください。 次の結果が返ってきました: 以下に、指定された課題を混合整数計画問題としてモデル化します。 パラメータ $ N = 120 $ 学生の総数。 $ C = 3 $ クラスの数。 $ s_i $ 学生 $ i $（$ i = 1, 2, \dots, 120 $）の成績。 $ M $ 大きな定数（必要に応じて使用）。 決定変数 $ x_{i,c} $ バイナリ変数。 $$ x_{i,c} = \begin{cases} 1 & \text{学生 } i \text{ がクラス } c \text{ に割り当てられる場合} \\ 0 & \text{それ以外の場合} \end{cases} $$ ここで、$ c = 1, 2, 3 $。 $ \mu_c $ クラス $ c $ の平均成績（連続変数）。 $ \delta $ クラス間の成績のばらつきを表す変数（連続変数）。最小化対象。 制約 各学生はちょうど1つのクラスに割り当てられる。 $$ \sum_{c=1}^{3} x_{i,c} = 1 \quad \forall i = 1, 2, \dots, 120 $$ 各クラスの学生数は40人である。 $$ \sum_{i=1}^{120} x_{i,c} = 40 \quad \forall c = 1, 2, 3 $$ クラスの平均成績を定義する。 $$ \mu_c = \frac{1}{40} \sum_{i=1}^{120} s_i x_{i,c} \quad \forall c = 1, 2, 3 $$ クラス間のばらつきを定義する（例として最大の平均成績差を用いる）。 クラス間の平均成績差を表すために、以下の制約を導入します。 $$ \mu_c - \mu_{c'} \leq \delta \quad \forall c, c' = 1, 2, 3 \text{ かつ } c < c' $$ $$ \mu_{c'} - \mu_c \leq \delta \quad \forall c, c' = 1, 2, 3 \text{ かつ } c < c' $$ 目的関数 クラス間の成績のばらつきを最小化する。ここでは、最大の平均成績差 $ \delta $ を最小化します。 $$\text{Minimize } \delta$$ モデルの概要 目的 : クラス間の平均成績差を最小化することで、成績のばらつきを抑える。 制約 : 各学生が1つのクラスに割り当てられ、各クラスに40人の学生が配置される。 決定変数 : 学生のクラス割り当てを表すバイナリ変数と、各クラスの平均成績およびばらつきを表す連続変数。 パラメータ : 学生数、クラス数、および各学生の成績。 このモデルにより、120人の学生を3つのクラスに均等に分けつつ、クラス間の成績のばらつきを最小化する最適な割り当てを求めることができます。 おおむね問題のないモデリングですね！ 「クラス間の成績のばらつきを最小に」というあいまいな言葉を「最大の平均成績差 $ \delta $ を最小化」と解釈してMIPモデルを作っているのは、よくあるテクニックですが素晴らしいです。 なぜか $M$ という謎のパラメタが導入されていますが無視してあげましょう。 平均成績を変数+制約で定義するのは正しいですが少し無駄のあるモデルにも思えます。これは4セクションに分けてくださいという指示があるため仕方ないかもしれません。 2. 有名問題に簡単な要件を追加してもモデル化がうまくいくか？ 有名な問題は知っている/モデリングできるということがわかったので、先程の2問題に少し要件を加えてみましょう。 巡回セールスマン問題 + α 巡回セールスマン問題に要件を加えた問題を投げてみます。 下線部 が追加要素です。 次の課題を混合整数計画問題としてモデル化してください。 「10個の都市をすべて回って出発地点に返ってくる必要がある。移動時間を最短化したい。 ただし、特定の3都市を先に訪問し、残りの7都市を後に訪問したい。 」 結果は「パラメタ」「決定変数」「制約」「目的関数」の4セクションに分けてください。 結果は次の通りです(数式の開始終了記号が一部変だったので見やすいよう手作業で修正しています): 以下に、課題を混合整数計画問題としてモデル化しました。 パラメタ（Parameters） $N$: 都市の集合、$ N = \{1, 2, \ldots, 10\} $。 $S$: 先に訪問すべき特定の3都市の集合、$ S \subseteq N $（例：$ S = \{1, 2, 3\} $）。 $t_{ij}$: 都市 $ i $ から都市 $ j $ への移動時間（$ i, j \in N $, $ i \neq j $）。 決定変数（Decision Variables） $x_{ij}$: バイナリ変数。都市 $ i $ から都市 $ j $ への移動が選択された場合に 1、そうでない場合に 0（$ x_{ij} \in \{0,1\} $）。 $u_i$: 順序変数。都市 $ i $ が訪問される順序を表す連続変数（$ u_i $ は 1 から 10 の整数）。 制約（Constraints） 出発点からの移動 : 出発地点（例えば都市 1）から出る経路は1つ。$$ \sum_{j \in N, j \neq 1} x_{1j} = 1$$ 各都市の出入り : 各都市から出る移動はちょうど1つ。$$ \sum_{j \in N, j \neq i} x_{ij} = 1 \quad \forall i \in N$$ 各都市に入る移動はちょうど1つ。$$ \sum_{j \in N, j \neq i} x_{ji} = 1 \quad \forall i \in N$$ 巡回路の排除（サブツアー排除） : ミラー・タム・ゾメラック（MTZ）制約を適用。$$ u_i - u_j + 10 x_{ij} \leq 9 \quad \forall i, j \in N, i \neq j$$ 訪問順序の制約 : 特定の3都市 $ S $ は、出発点から最初の3つの訪問都市でなければならない。$$ u_i \leq 4 \quad \forall i \in S$$ 残りの7都市は、訪問順序4より後でなければならない。$$ u_i \geq 5 \quad \forall i \in N \setminus S$$ 出発点の順序固定 : 出発地点（例えば都市 1）の順序を1に固定。$$ u_1 = 1$$ 目的関数（Objective Function） 移動時間の最小化 :$$ \min \sum_{i \in N} \sum_{j \in N, j \neq i} t_{ij} x_{ij}$$ 以上のモデルにより、10都市をすべて回って出発地点に戻る際に、特定の3都市を先に訪問しつつ、総移動時間を最短化する経路を求めることができます。 これもほぼ正しそうですね！ 良い点も気になるところもあるのでコメントしておきます: 先に訪問すべき都市を$N$の部分集合 $S$ として定義しているのは、見通しがよく素晴らしい。 制約 1, 2 を分けているのが不思議。 2 で統一したらよさそう。 1 での「入る移動」を省略をしているのは、数学的には間違いとはいえない(残りの 1, 2 の制約から導かれる) が、それで意味のある高速化がおきるのかは不明。普通は 2 で統一する気がします。 $ u_i $ が連続変数なのか整数変数なのかよくわらかない書き方になっている。技術的には「$[1, 10]$ の連続変数として定義したら結果的に整数変数になってくれる」というタイプの変数なので、連続変数と書くのが適切。 制約4の $≤4, \: ≥5$ は、正しくは $≤3, \: ≥4$ であるべき。 定数ミスは慣れてる人でもしてしまう軽微な問題。 しかし $≤|S|, \:\: ≥ |S|+1$ みたいな書き方だったらミスが発生しないのだから、せっかくならそう書いてほしい。 人力の確認と修正が入る前提であれば、それなりに有用な出力を出せていると思います。 クラス分け問題 + α クラス分け問題の発展編も解かせてみましょう。 o1-mini へ次の質問を投げます。LLM に喧嘩を防いでもらいましょう。 次の課題を混合整数計画問題としてモデル化してください。 「120人の学生を3つのクラスに分けたい。3つのクラスの人数は等しくしたうえで、クラス間の成績のばらつきを最小に抑えたい。 ただし、何対かの喧嘩をしてしまう生徒ペアがあるため、それらのペアの生徒は必ず別のクラスにしてほしい。 」 結果は「パラメタ」「決定変数」「制約」「目的関数」の4セクションに分けてください。 次の結果が返ってきました: パラメタ $ S $ : 学生の集合、$|S| = 120$。 $ C $ : クラスの集合、$ C = \{1, 2, 3\} $。 $ P_i $ : 学生 $ i $ の成績。 $ K $ : 喧嘩をしている学生ペアの集合、$ K \subseteq S \times S $。 決定変数 $ x_{i,c} $ : バイナリ変数。学生 $ i $ がクラス $ c $ に割り当てられる場合は1、そうでなければ0。$$ x_{i,c} \in \{0, 1\}, \quad \forall i \in S, \forall c \in C$$ $ F_c $ : クラス $ c $ の総成績。$$ F_c = \sum_{i \in S} P_i x_{i,c}, \quad \forall c \in C$$ $ M $ : 最大クラス成績。$$ M \geq F_c, \quad \forall c \in C$$ $ m $ : 最小クラス成績。$$ m \leq F_c, \quad \forall c \in C$$ 制約 各学生はちょうど一つのクラスに割り当てられる ：$$ \sum_{c \in C} x_{i,c} = 1, \quad \forall i \in S$$ 各クラスの人数が40人である ：$$ \sum_{i \in S} x_{i,c} = 40, \quad \forall c \in C$$ 喧嘩をしている学生ペアは同じクラスに割り当てられない ：$$ x_{i,c} + x_{j,c} \leq 1, \quad \forall (i,j) \in K, \forall c \in C$$ クラス成績の定義 ：$$ F_c = \sum_{i \in S} P_i x_{i,c}, \quad \forall c \in C$$ 最大および最小クラス成績の定義 ：$$ F_c \leq M, \quad \forall c \in C$$ $$ F_c \geq m, \quad \forall c \in C$$ 目的関数 クラス間の成績のばらつきを最小に抑えるため、最大クラス成績と最小クラス成績の差を最小化する。$$\text{Minimize } Z = M - m$$ このモデルにより、120人の学生を3つのクラスに均等に分けつつ、クラス間の成績のばらつきを最小限に抑え、喧嘩をしている学生ペアが同じクラスに割り当てられないようにすることができます。 すごい、完璧ですね。$F_c, M, m$ の定義がなぜか繰り返されていますが軽微な問題です。 そもそも補助変数が登場する問題はこちらが指定した4セクションに分けた記述になじまないので、出題者側の問題もありそうです。ごめん。 3. 複雑な要件を上手にモデル化できるか？ ここまで、有名問題に毛が生えた程度の問題であれば o1-mini はそれなりに正しくモデル化してくれることがわかりました。 最後にしっかりと複雑な要件を与えて、モデル化できるか見てみます。 o1-mini へ次の質問を投げます。 次の課題を混合整数計画問題としてモデル化してください。 「拠点にある一台の車を使ってすべての店舗を回って拠点に戻る計画を立てたい。拠点と各店舗にはそれぞれタイムウィンドウが設定されている。各店舗のタイムウィンドウは最大3つであり、作業開始時間がいずれかのタイムウィンドウに入っていれば許されるものとする。拠点のタイムウィンドウは1つであるが、出発時刻・帰還時刻のいずれもここに収まる必要がある。巡回中のいずれかのタイミングで1度だけ拠点への報告業務を行うため、ここで一定の時間を使う必要がある。報告業務はいずれかの地点での作業終了直後に行うものとする。報告業務を行うことができるタイムウィンドウは1つ指定されているものとする。各店舗での作業時間・地点間の移動時間・報告業務の時間はパラメタで与えられる。」 結果は「パラメタ」「決定変数」「制約」「目的関数」の4セクションに分けてください。 結果は次の通りです: パラメータ $ N $: 拠点および店舗の集合。拠点を0、店舗を1,…, $ n $ とする。 $ TW_0 = [a_0, b_0] $: 拠点のタイムウィンドウ。 $ TW_i = \{ [a_{i1}, b_{i1}], [a_{i2}, b_{i2}], [a_{i3}, b_{i3}] \} $（最大3つ）: 店舗 $ i $ の各タイムウィンドウ。 $ TW_R = [a_R, b_R] $: 報告業務を行うタイムウィンドウ。 $ t_{ij} $: 地点 $ i $ から地点 $ j $ への移動時間。 $ s_i $: 店舗 $ i $ での作業時間。 $ t_R $: 報告業務に要する時間。 $ M $: 十分に大きな定数（ビッグM）。 決定変数 $ x_{ij} \in \{0,1\} $: 車が地点 $ i $ から地点 $ j $ へ移動する場合に1、そうでない場合に0。 $ t_i \geq 0 $: 地点 $ i $ に到着する時刻。 $ y_i \in \{0,1\} $: 地点 $ i $ で報告業務を行う場合に1、そうでない場合に0。 $ w_{ik} \in \{0,1\} $: 店舗 $ i $ がタイムウィンドウ $ k $ （$ k = 1,2,3 $）を使用する場合に1、そうでない場合に0。 制約 各店舗の訪問 各店舗は一度だけ訪問される：$$ \sum_{j \in N} x_{ij} = 1 \quad \forall i \in N \setminus \{0\}$$ 拠点から出発する経路：$$ \sum_{j \in N} x_{0j} = 1$$ 拠点に帰着する経路：$$ \sum_{i \in N} x_{i0} = 1$$ タイムウィンドウの選択と遵守 各店舗はいずれかのタイムウィンドウを選択する：$$ \sum_{k} w_{ik} = 1 \quad \forall i \in N \setminus \{0\}$$ 到着時刻が選択されたタイムウィンドウ内にある：$$ a_{ik} \leq t_i \leq b_{ik} + M(1 - w_{ik}) \quad \forall i \in N \setminus \{0\}, \forall k$$ 報告業務の実施 報告業務は一箇所で行われる：$$ \sum_{i \in N} y_i = 1$$ 報告業務を行う時刻が指定のタイムウィンドウ内：$$ a_R \leq t_i + s_i \leq b_R + M(1 - y_i) \quad \forall i \in N$$ 報告業務の開始時刻が作業終了直後である：$$ t_R = t_i + s_i \quad \text{if } y_i = 1$$ これを線形化するために以下の制約を追加：$$ t_R \geq t_i + s_i - M(1 - y_i) \quad \forall i \in N$$ $$ t_R \leq t_i + s_i + M(1 - y_i) \quad \forall i \in N$$ 時間の整合性 時間の流れを維持する：$$ t_j \geq t_i + s_i + t_{ij} - M(1 - x_{ij}) \quad \forall i,j \in N, i \neq j$$ 拠点のタイムウィンドウ遵守 出発時刻が拠点のタイムウィンドウ内にある：$$ a_0 \leq t_0 \leq b_0$$ 帰還時刻が拠点のタイムウィンドウ内にある：$$ a_0 \leq t_{end} \leq b_0$$ ここで、$ t_{end} $ は拠点への最終帰還時刻とする。 サブツアーの排除 順序変数 $ u_i $ を用いたMTZ制約：$$ u_i - u_j + n x_{ij} \leq n - 1 \quad \forall i,j \in N \setminus \{0\}, i \neq j$$ ここで、$ u_i $ は地点 $ i $ の訪問順序を示す連続変数であり、$ 1 \leq u_i \leq n $。 目的関数 総移動時間の最小化：$$ \min \sum_{i \in N} \sum_{j \in N} t_{ij} x_{ij} + \sum_{i \in N} s_i + t_R$$ ※ 他の目的（例：総移動距離の最小化）を設定することも可能。以上のモデルにより、10都市をすべて回って出発地点に戻る際に、特定の3都市を先に訪問しつつ、総移動時間を最短化する経路を求めることができます。 なんとなくそれっぽくてすごい！のですがよく見ると変なところが目立ちますね。見ていきましょう。 タイムウィンドウ関係の制約は正しく書けていません。「2. タイムウィンドウの選択と遵守」の「到着時刻が選択されたタイムウィンドウ内にある」という制約で「$a_{ik} \leq t_i \leq b_{ik} + M(1 - w_{ik}) \quad \forall i \in N \setminus \{0\}, \forall k$ 」とあります。このままでは左辺の値が常に有効になってしまって、最も遅いタイムウィンドウのみが使われるようになってしまいます。正しくは左辺を $a_{ik} - M(1- w_{ik})$ などとするべきでしょう。「報告業務を行う時刻が指定のタイムウィンドウ内」でも同様のミスがみられます。 「3. 報告業務の実施」の「報告業務の開始時刻が作業終了直後である」という制約は意味不明なものになっています。他の制約にも報告業務による時間経過を妥当な形でモデリングしている箇所はないので、本モデルでは報告業務は無視されていると考えていいでしょう。 $t_{end}$ に関しても変数定義などの準備が足りていないのはいただけませんし、「時間の整合性」を与えている以上「MTZ制約」は不要です。また不要な「MTZ制約」中でも係数が$n$地点の場合のものが書かれているところと (実際には地点数は$n+1$)、拠点の$u_0=0$が関与しない書き方になっているところも良くないですね。 これくらいしっかりと間違えていると、 LLM が答えてくれたモデルを修正して正しいモデルを作るというのが効率の良い作業なのか疑問になってきます。 まとめ 実験結果のまとめです: 有名問題をモデル化できるか / 有名定石を利用できるか？　▶　できる 有名問題に簡単な要件を追加してもモデル化がうまくいくか？　▶　ちょっとできる 複雑な要件を上手にモデル化できるか？　▶ できない o1-mini は有名問題の知識をもっており、これに簡単な改変を加える程度の思考であればある程度やってくれそうです。 一方で、見たことがないような複雑な要件を与えると、意味不明なモデリングを行ってしまうようです。 現時点では以下の2つの使い方ができそうです: 数理最適化初心者が簡単なモデルを作りたいとき・学習したいとき 簡単なモデルは作ってくれる ただし正誤判断は自分でできる必要があるため、 教科書で基本的な勉強をしたうえで利用する 中級者~上級者レベルの人のモデリング補助 LLMの知識の幅は圧倒的。調査・検討をしたいときに「ダメもとで聞いてみる」のには意味がありそう たとえば、定石をしらない問題がでてきたときに(枝葉の要件を削って)モデル化させてみて、良さそうなもの使う and/or 出典を調べて調査する、など LLMを使って面白いモデルを書いていきましょう！ MathJax = {tex: {inlineMath: [['$', '$']]}};

イントロダクション：スーパーマーケットの3つの課題 ナレッジグラフとは ナレッジグラフの活用事例 Google検索 Amazon ECサイトのレコメンドシステムCOSMO ナレッジグラフに関連した論文 Yu et al., COSMO: A large-scale e-commerce common sense knowledge generation and serving system at Amazon[4] Shi et al., LLM-Powered Explanations: Unraveling Recommendations Through Subgraph Reasoning[1] Wang et al., Multi-level recommendation reasoning over knowledge graphs with reinforcement learning[3] 3つの課題の解決策 チラシを用いた宣伝 パーソナライズしたおすすめ商品の選定 店頭POPによる宣伝 その他の活用アイデア ドラッグストアでの活用 生活習慣の改善 求人マッチングサービス まとめ 参考文献 イントロダクション：スーパーマーケットの3つの課題 東京大学大学院数理科学研究科博士課程2年の安達充慶です。2024年9月の一ヶ月間、インターン生としてお世話になっています。 今回私は小売業界におけるLLMの活用を提案する業務を行いました。その成果をここでご紹介したいと思います。なお、ここでは小売業界の中でもスーパーマーケットに焦点を当てて話を進めます。 スーパーの特徴は、個々の商品の単価が低く利益率も低いことです。したがって、利益を最大化するためには、できるだけ客単価を向上させ、売上高を伸ばすことが重要です。この目標を達成する手段は色々ありますが、今回は以下に示す３つの方法を考えます。 チラシを用いた宣伝 パーソナライズしたおすすめ商品の選定 店頭POPによる宣伝 チラシを用いた宣伝では、狭い紙面を無駄にせず商品をアピールすることが求められます。具体的には、核となる商品を決めたのち、その商品と一緒に売れる可能性の高い商品を載せること（いわゆるクロスセル）が有効であると考えられます。この一緒に売る商品として最適なものを見つけることが課題です。 パーソナライズされたおすすめ商品の選定も売り上げ向上に寄与すると考えられます。しかし、お客様一人一人のおすすめ商品を人手で選定することは非現実的であるため、システムによる自動化が必須である点が課題です。 店頭POPによる宣伝では、POPに書く宣伝文が重要な要素となります。しかし、宣伝文を考える作業は時間がかかるため、店舗従業員に負担が重くのしかかります。従業員の負担を減らしつつ、効果的な宣伝文を作る仕組みを整えることが重要です。 これらの課題に対し、今回私はナレッジグラフとLLMを組み合わせたレコメンドシステムによる解決策を提案しました。以下、ナレッジグラフとは何なのか、それを使ってどのように上記の課題が解決できるのかを説明します。 ナレッジグラフとは ナレッジグラフとは、さまざまな知識を連結してグラフとして表現したものです。形式的には以下のデータから構成されます。 ノード：ユーザーや商品などのエンティティ一つにつき一つのノードを割り当てる。 エッジ：関係のあるノード同士を結ぶ向きのついた矢印。 ラベル：エッジが表す関係性を表現する文。一つのエッジにつき一つのラベルが用意される。 例えば、「あるユーザーAが商品Bを購入した」というデータをナレッジグラフで表現する場合は以下のようにします。まず、ノードとして「ユーザーA」と「商品B」の二つを用意します。そして「ユーザーA」から「商品B」にのびるエッジを一つ用意し、このエッジに「購入した」というラベルをつけます。 上記の例では、「ユーザー」や「商品」のようにいかにもエンティティらしさのあるものがノードに現れました。しかし、それ以外にも「甘い」のように感覚を表す語彙をノードで表現することも可能です。これによってユーザーの嗜好を表現したり、食品の味を表現したりすることが可能になります。どこまでをノードとして追加するかは、ナレッジグラフの活用目的に合わせて決めるべきであると考えられます。 以下、スーパーにおける課題の解決策に入る前に ナレッジグラフの活用事例 ナレッジグラフに関連した論文 を紹介します。 ナレッジグラフの活用事例 Google検索 Google検索を行うと、右側に表示されるボックスに検索対象についての情報が表示されることがあります。以下は「Insight Edge」と検索したときのボックスの一部です。 出典：Google検索 Insight Edgeに関連する情報として所在施設と所在地が表示されていることが分かります。このボックスを生成する目的でナレッジグラフが活用されています。ナレッジグラフの内部が実際にどうなっているかは分かりませんが、以下の図のように「Insight Edge」というエンティティと所在施設などの情報が関連付けられていると推測できます。 Amazon ECサイトのレコメンドシステムCOSMO ナレッジグラフはAmazonのECサイトでも活用されています。最近発表されたCOSMO[4]というレコメンドシステムでは、人間が持っている暗黙の常識をレコメンドに反映させるための役割をナレッジグラフが担っています。このシステムにより、おすすめの精度は最大で60%向上したとのことです。そしてナレッジグラフに暗黙の常識を追加させる作業の段階でLLMが活用されています。ここではLLMが推論能力を獲得しているという性質を活用しています。 論文で挙げられている例を使って説明します。妊娠している人が靴を買いたいと考え、「妊婦用の靴」と検索したとします。この場合、商品説明に「妊婦」が含まれている靴を探すよりも、妊婦の用途に合った性質（「すべりにくい」など）を持つ靴を探す方が筋がいいと言えます。したがって、そのような暗黙の常識をナレッジグラフで保持することでおすすめの精度が向上すると考えられます。 出典：Yu et al.[3] COSMOでは、ユーザーのサーチクエリとその後の購買行動を注意深く観察することでナレッジグラフに追加する情報を生成しています。ここで注意が必要なのは、サーチクエリとその後の購買行動が全く無関係である可能性が否定できないところです。「妊婦用の靴」と検索したユーザーがすべりにくい靴を購入した場合は、確かにその購入履歴から「妊婦用の靴はすべりにくい方が好ましい」という暗黙の常識を獲得できます。一方、「妊婦用の靴」と検索したユーザーがどういうわけかサンダルを購入したとしても、「妊婦用の靴はサンダルが好ましい」とは言えません。 ここで登場するのがLLMです。LLMは膨大な資料による学習の過程で、世の中についての知識や簡単な推論を行う能力を身につけているとされています（例えばHuang et al.[1]）。そこで、LLMに「このサーチクエリと購買履歴の間にはどのような関係がありますか」と聞けば、背後にある暗黙の常識を取り出すことができると考えられます。 ナレッジグラフに関連した論文 ナレッジグラフを活用したレコメンド技術に関連する論文を3つ紹介します。 Yu et al., COSMO: A large-scale e-commerce common sense knowledge generation and serving system at Amazon[4] Amazonのナレッジグラフ活用事例で紹介したAIシステムCOSMOについての論文です。前節ですでに説明したので詳細は省略します。 Shi et al., LLM-Powered Explanations: Unraveling Recommendations Through Subgraph Reasoning[1] 本論文の目的は、ユーザーの購買履歴と口コミ履歴から、ユーザーが次に買いたいと思う商品のレコメンドを行うことです。本研究で構成されたナレッジグラフには各ユーザーを表すノードと各商品を表すノードがあります。（それ以外のノードもあります。）ユーザーのノードを一つ選んだとき、ナレッジグラフから好ましい商品のノードを一つ選択するアルゴリズムを構築することが目的です。本論文では、ナレッジグラフとLLMを活用したレコメンドシステムにおいて2つの工夫を提案しています。 一つ目の工夫は、ナレッジグラフに口コミ由来の情報をLLMを通して追加する点です。この論文では初期状態のナレッジグラフは次のデータから構成されています。 エンティティはユーザーと商品 エッジは各ユーザーが購入した商品への矢印 ラベルは「購入した」という関係 これだけではナレッジグラフとしては貧弱なので、著者らは口コミデータを利用してナレッジグラフを拡張することを提案しました。例えば、あるユーザーが「このタオルは手触りがいい」と書いたとすると、「手触りの良さ」というノードが追加され、タオルから「手触りの良さ」に向かうエッジに「材質」というラベルがつきます。「私は甘いものが好きなので」という口コミがあれば、ユーザーと「甘い」というノードの間に「味覚の好み」というラベルのついたエッジがつきます。 二つ目の工夫は、ナレッジグラフから情報を取り出す際、重要度が高いと推察される情報からなる部分グラフを抽出してから処理を行う点です。一般にナレッジグラフは大規模になることが多く、情報を取り出す際に巨大なコンピュータリソースを使います。この論文では、ユーザーを起点として、そのユーザーと関連性の高い情報だけからなる部分グラフを構成する手法を提案しています。以下のアルゴリズムで部分グラフを作ります。以下、$N$と$M$はあらかじめ与えられた自然数です。 はじめに選択したユーザーのみからなる部分グラフ$G_0$を構成する。 選択したユーザーと関連性の高いエッジを$N$本選び出し、それらを$G_0$に追加した部分グラフ$G_1$を作る。 $G_1$と関連性の高いエッジを$N$本選び出し、それを$G_1$に追加した部分グラフ$G_2$を作る。 この操作を$M$回繰り返して得られる部分グラフ$G_M$が求めるものである。 「関連性」はある一定の計算方法で求めます。その計算の中にはパラメータが入っており、その値は事前の学習で求めておきます。$N$と$M$はハイパーハラメータです。 以上の方法でエッジの数が$NM$本のサブグラフが抽出できました。このあと、はじめに選択したユーザーに最もおすすめの商品が一定のアルゴリズムで決定されます。このアルゴリズムに含まれるパラメータも事前の学習で決めておきます。 論文のタイトルにもある通り、この手法はレコメンドの根拠を説明できるシステムの構築を目指しています。最後の「ユーザーにおすすめな商品を決定する」プロセスでは、ユーザーから商品までたどり着くまでの一本の道が生成されます。その道は商品のおすすめ理由を含んでいると考えられるので、それをLLMに渡すことで人間に理解しやすい形でレコメンドの根拠が示されることになります。 Wang et al., Multi-level recommendation reasoning over knowledge graphs with reinforcement learning[3] 本論文ではナレッジグラフを階層化することを提案しています。論文における図では、ナレッジグラフが3層に分かれており、その上部の層に行くにつれてノードが抽象的な対象を表すようになります。 出典：Wang et al.[2] ナレッジグラフの最下層は具体的な商品名がノードになっています。一方、最上層では「化粧品」や「高級ブランド」といった抽象度の高い語彙がノードになっています。「ユーザーが次にほしがる商品をおすすめしたい」という観点に立ったとき、「プラダの化粧バッグを購入した」という情報から「プラダ」や「化粧バッグ」という語彙だけに注目するのは得策でない可能性があります。それよりも、プラダから連想される「高級ブランド」や「化粧品」といった抽象化された属性の方がユーザーの好みを反映しているかもしれません。ナレッジグラフの階層化は、こうした抽象化を行う目的に適していると考えられます。 3つの課題の解決策 ナレッジグラフとLLMを組み合わせたシステムによって冒頭で述べた課題がどのように解決できるか、私の考えを述べます。 チラシを用いた宣伝 ナレッジグラフの情報をもとにクロスセル（セット売り）を実施する際の商品選定に利用することができます。例えば以下の図のようなナレッジグラフがあったとします。 このとき、システムに「Item 1とセットで販売するといい商品は？」と聞くと「Item 1を購入する顧客はItem 2をセットで購入する傾向にあるため、Item 2をおすすめします。」と返事が来るはずです。Item 3もItem 1と関係がありますが、「Item 3を購入する顧客はItem 1も購入する」という逆向きの関係なのでおすすめされません。LLMは内在化された推論能力によりこのような判断を自分で行うことができます。 パーソナライズしたおすすめ商品の選定 具体的に提供可能なサービスの一例として、AIによるレシピ提案システムが考えられます。この場合、ナレッジグラフに レシピの情報 味覚や食感などの情報 ユーザーごとの好みの情報 を登録しておきます。味覚や食感などの情報はレシピの提案者から、ユーザーごとの好みの情報は過去のレシピ選択の履歴から取得します。 例えば、以下の図のようなナレッジグラフがあったとします。 この状況でユーザーが「今日は中華料理の気分だ」のようにLLMに話すと、LLMは「麻婆豆腐はいかがですか？辛いもの好きのあなたにおすすめです。」と返してくれるでしょう。また、情報の粒度を調節することで、「唐辛子の辛さが特徴の麻婆豆腐」と「山椒のピリピリ感が特徴の麻婆豆腐」を区別できるようにすることも可能です。これによって、よりユーザーの好みに合ったレシピを提案できる可能性が高まります。 店頭POPによる宣伝 店頭POPにLLMを活用する動きはすでに成果を出しています。例えば、西鉄ストア[5]では、購買履歴の情報と通販サイトの口コミデータの情報を使って生成AIにPOPの売り文句を作成させる取り組みを行いました。この結果、取り組み対象となったカレー商品の売り上げは他店舗の売り上げ増加率を1%上回る結果となりました。イオン[6]でも生成AIを「店舗に掲示する文書のひな型作成」や「店内放送のひな型文書作成」に応用しています。 上記の取り組みにナレッジグラフを活用することを考えてみます。ナレッジグラフの強みは商品やユーザーの購買行動などが体系的に管理されているところです。したがって、商品の特性やアピールしたい層についての情報を的確に取り込んだPOP文を作成できると期待されます。 その他の活用アイデア ナレッジグラフとLLMの組み合わせを活用できそうな他のアイデアをいくつか述べたいと思います。 ドラッグストアでの活用 患者さんの健康上の悩みに対してアドバイスを行うシステムに活用します。 患者さんの症状と、予防策や対処法をノードとして管理し、それらの間の関係性をエッジとして管理します。 生活習慣の改善 ユーザーの生活習慣改善に役立つアドバイスを行うシステムに活用します。 ユーザーの生活習慣、それによって現れる種々の症状、改善方法をノードとして管理します。 求人マッチングサービス 求職者に最適な求人やキャリアパスの提案を行うシステムに活用します。 求職者の経歴・スキル、求人情報をノードとして管理します。 まとめ ナレッジグラフとLLMは相互補完的な関係にあります。ナレッジグラフは事実関係を正しく整理する目的に最適です。LLMは正しくない情報を生成してしまうという問題（ハルシネーション）が知られていますが、ナレッジグラフはその弱点を補うことができます。一方、ナレッジグラフから取り出した事実関係を利用する作業はLLMの得意とするところです。 現在、スーパーマーケットでの応用を念頭に、Customer Decision Treeのアイデアをもとにナレッジグラフを構築できないか検討中です。（参考URLとして[7]を挙げます。） Customer Decision Treeとは、顧客のニーズを階層化して表現したものです。最上層では最も大雑把なニーズが定義され、階層を下るごとにニーズが細分化していきます。個々の商品は、Customer Decision Treeの最下層で提示されたニーズと結びつくはずです。 スーパーで取り扱う食品などの商品の場合、同じ商品であっても顧客によって全く違うニーズから購入に至るケースがあります。したがって、一つの商品に対して複数のニーズが該当するケースがあると考えられます。このような状況をナレッジグラフとして捉えるところから始めることで、説明力の高いレコメンドシステムが構築できるのではないかと期待しています。 最後にインターンの感想を書いて締めたいと思います。このインターンは「LLMを事業に活用する方法を検討する」ということだけが決まっており、それ以降のことは私が自由に考えることができました。自由度の高さゆえ、次に進むべき方向が分からなくなってしまうこともありましたが、その度にメンターの森さんが軌道を指し示してくださいました。その際、「この事業の特性を考えると」といつもおっしゃっていたのが印象的でした。相手が求めることを的確に想像することが努力の方向性を間違えないために必要なことだと実感しました。 メンターの森さんをはじめ、たくさんの方にお世話になりました。この場を借りて感謝申し上げます。一ヶ月間お世話になりました。 参考文献 [1] Huang, J., Chang, K. (2022). Towards Reasoning in Large Language Models: A Survey. Findings of the Association for Computational Linguistics: ACL 2023 (pp. 1049–1065). [2] Shi, G., Deng, X., Luo, L., Xia, L., Bao, L., Ye, B., ... & Li, Y. (2024). LLM-Powered Explanations: Unraveling Recommendations Through Subgraph Reasoning. arXiv preprint arXiv:2406.15859. [3] Wang, X., Liu, K., Wang, D., Wu, L., Fu, Y., & Xie, X. (2022). Multi-level recommendation reasoning over knowledge graphs with reinforcement learning. In Proceedings of the ACM Web Conference 2022 (pp. 2098-2108). [4] Yu, C., Liu, X., Maia, J., Li, Y., Cao, T., Gao, Y., ... & Li, Z. (2024). COSMO: A large-scale e-commerce common sense knowledge generation and serving system at Amazon. In Companion of the 2024 International Conference on Management of Data (pp. 148-160). [5] 日本経済新聞、「西鉄ストア、生成AIが『売り文句』　POP実験で販売好調」、 https://www.nikkei.com/article/DGXZQOJC0695Y0W4A600C2000000/ （2024/9/17アクセス） [6]エクサウィザーズ、「イオンデジタルアカデミーが『exaBase 生成AI』を採用」、 https://exawizards.com/archives/26831/ （2024/9/17アクセス） [7] PR TIMES, 「消費者ニーズのさらなる深掘りが可能に！『カスタマーデシジョンツリー分析」のサービス内容を拡充（株式会社True Data）」、 https://prtimes.jp/main/html/rd/p/000000048.000039871.html （2024/9/19アクセス） MathJax = {tex: {inlineMath: [['$', '$']]}};

こんにちは、k-kzkです。私はInsight Edgeに参画して早2年が経ちました。 今回の記事では、私が初めて取り組んだETL開発プロジェクトと、そこで選択したツールであるDataformについてお話しします。 目次 1. はじめに 1.1 ETL 開発とは 1.2 Dataform の選定理由 2. Dataform を利用した ETL 開発のライフサイクル 2.1 リポジトリ作成 2.2 ワークスペースの使い方について 2.3 ディレクトリについて 2.4 テーブル構成 2.5 Dataform のテストについて 2.6 リリース方法について 3. その他開発における Tips 3.2 データセット作成時のエラーについて 4. まとめ 1. はじめに プロジェクトに参画するまで、データをメインに扱う開発経験がほとんどなかった私にとって、「ETL」という言葉も聞き馴染みが無いものでした。 正直、最初は「ETLって何？」という状態でしたが、データの抽出、変換、格納といった一連のプロセスを効率的に行うためのツール選びから始めることになりました。 この記事ではDataformを用いた開発プロセスを、私の経験を元に順に説明していきます。 1.1 ETL 開発とは まず、ETLとは何か。ETLとは、データを抽出 (Extract)、変換 (Transform)、格納 (Load) する一連のプロセスのことです。 大量のデータを扱い、それを適切に加工して最終的な形にするための作業と言えます。 ETLの処理はSQLさえ書ければ基本的にどのプログラミング言語でも対応できますが、プロセスをより簡単に、そして管理しやすくするためには適切なツールが必要です。 そこで私たちのチームが注目したのはDataformでした。 1.2 Dataform の選定理由 Dataformを選定した最大の理由は、BigQueryとの親和性です。 BigQueryは私たちのプロジェクトの基盤となるデータベースであり、同じくGoogle CloudのサービスであるDataformはBigQueryに直接アクセスし、SQLを使ってスムーズにデータを操作できます。 また、グラフによる可視化機能もあるため、データの依存関係を直感的に理解しやすく、レビューやデバッグもしやすいです。 Dataformについては、 公式のガイド を試すことによって理解を深めることができました。 他のETLツールであるdbtも検討に上がりましたが、今回はBigQueryとの親和性を重視し、特に比較検証を行わずDataformの利用に決定しました。 2. Dataform を利用した ETL 開発のライフサイクル 2.1 リポジトリ作成 まず始めに、Dataformのリポジトリを作成します。作成方法に特に制限はなく、コンソールから手動で作成する方法やTerraformでの自動化など、さまざまな方法が考えられます。Dataformを扱う場合は、GitHubなどのGitリポジトリと接続するケースが一般的です。 このGitリポジトリの接続については、 手順書 も公式に公開されていますが、以下の点に注意が必要です。 注意ポイント : Dataform側のSSH認証の設定作業にて、手順の中でホストのSSH公開鍵のKey-Valueを設定する必要があります。 このホストのSSH公開鍵については、 GitHub の SSH 公開鍵情報のページ から取得すればよく、例えば ssh-ed25519 を扱う場合は以下を設定すればよいのですが... ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl GitHub の SSH 公開鍵情報のページ のページには、以下のようにホスト名が入っておりこのままではGitHubとの接続に失敗してしまいます。 github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl このように、そのままコピペすると上手くいかないなど罠があるので、ガイドはしっかり隅から隅まで読みましょう。 2.2 ワークスペースの使い方について Dataformでは、1つのリポジトリ内で複数のワークスペースを作成できます。 開発者はGitHubのブランチのようにワークスペースを作成して作業を進めます。 このとき、データセット(スキーマ)の接尾辞を設定することで、ワークスペースごとに独立した環境が作成され、開発環境の競合を防ぐことができます。 設定することで、ワークスペースごとにデータセットが生成されるため開発環境の競合が発生しません。 注意ポイント : ワークスペースを削除してもデータセットやテーブルは削除されません。 BigQuery上に不要なテーブルが増えないよう、管理に工夫が必要です。 2.3 ディレクトリについて ワークスペースの準備が整ったら、Dataform用のSQLXソースコードをどのように管理するか考えます。 Dataformを開発する上で必要なディレクトリとファイルは以下の通りです。 ディレクトリ/ファイル 目的 /definitions sqlx ファイルを格納するディレクトリ /includes 再利用可能な JavaScript の スクリプトを格納するディレクトリ workflow_setting.yaml Dataform の設定ファイル これら以外のディレクトリやファイルはDataformに影響を与えません。 TerraformやCloud Workflowsの設定ファイルなど、他のソースコードと同じリポジトリで管理可能です。 2.4 テーブル構成 プロジェクトでは以下の目的でテーブルを定義しました。 ETLの各処理を目的ごとに定義することで、ロジックを明確に分割し、管理を容易にしています。 今回は、Dataformで管理するテーブル以外を外部データと定義します。 テーブル一覧 目的 マスタテーブルの DDL マスタテーブルを定義する Extract ビュー 外部データを取得する Transform ビュー マスタテーブルと外部データを結合する Incremental テーブル データの蓄積を目的とする I/F ビュー Load に必要なデータのみを格納する Dataformでは、各コードがテーブルとして生成されます。 このように分割することでデータの読み書き回数が増えるため、コストの考慮が必要です。しかし、管理しやすくするために分割するのが良いでしょう。 特にTransform処理は複雑なロジックになることが多いので、分割するべきです。 2.5 Dataform のテストについて Dataformで作成したテーブルのテストは アサーション 機能を利用して実施します。 アサーションの記載は簡単で、以下のようにconfigを定義するだけでテストが実行されます。 config { type: "view", name: "dataform_name", tags: ["daily"], assertions: { uniqueKey: "key", nonNull: ["key", "column1", "column2"] } } 注意ポイント : 全体スキャンを毎回実行するとアサーションによるBigQueryの処理が過剰に発生し、 課金の発生に繋がる ため、注意が必要です。適量なアサーションを心がけましょう。 2.6 リリース方法について プロジェクトでは、Google Cloudのプロジェクトを開発・検証用と本番用に分けています。 開発・検証用には、開発環境（開発者ごとに構築される環境）、PR環境（PR起票時に構築される環境）、検証環境があり、本番用には本番環境の計4種類を構築しています。 今回のリリース対象はマスタとそれ以外に分かれます。 マスタのリリースは手動とし、それ以外のデーブルはGoogle Workflowsによって構築としました。 手動構築の場合には リリース構成 を作成しておくのが望ましいです。 リリース構成を定義し、Gitブランチやコンパイル変数などを設定しておくことで環境の再構築や複製を簡単に準備できます。 Google Workflowsによるリリースの場合は、 APIを通じてコンパイルを実行します。 APIガイドは こちら です。 リリース構成と同じように、引数などを設定可能です。 - createCompilationResult: try: call: http.post args: url: ${"https://dataform.googleapis.com/v1beta1/" + dataform_repository + "/compilationResults"} auth: type: OAuth2 body: gitCommitish: main codeCompilationConfig: schemaSuffix: ${schema_suffix} vars: { "TARGET_DATE": "${target_date}" } result: compilationResult Dataformの実行は こちら を用います。 ここでタグを指定して実行が必要なDataformコードを指定しています。 - createWorkflowInvocation: try: call: http.post args: url: ${"https://dataform.googleapis.com/v1beta1/" + dataform_repository + "/workflowInvocations"} auth: type: OAuth2 body: compilationResult: ${compilationResult.body.name} invocationConfig: includedTags: - ${tag} result: workflowInvocation 3. その他開発における Tips 3.環境ごとの分岐処理を作成する場合 DataformではJavaScriptを利用することで環境による分岐処理を実装できます。 以下は、特定の環境でのみ実行したい処理を記述する例です。 今回のプロジェクトでは、開発環境のマスタテーブルのデータについては検証環境からコピーするといった処理を追加しました。 例えば、以下のJavaScriptコードはSTG環境以外の環境はSTG環境のテーブルをコピーするような処理となります。 このように環境ごとに異なる処理を定義する場合はJavaScriptで定義できます。 function insertIfNotExists(table_name, schema_name) { const STG_SCHEMA_NAME = dataform.projectConfig.vars.STG_SCHEMA_NAME; const STG_DATASET_NAME = dataform.projectConfig.vars.STG_DATASET_NAME; if (schema_name != STG_SCHEMA_NAME) { return ` DECLARE record_exists BOOL DEFAULT FALSE; SET record_exists = ( SELECT EXISTS ( SELECT 1 FROM \`${schema_name}.${table_name}\` LIMIT 1 ) ); IF NOT record_exists THEN BEGIN INSERT INTO \`${schema_name}.${table_name}\` SELECT * FROM \`${STG_DATASET_NAME}.${STG_SCHEMA_NAME}.${table_name}\`; EXCEPTION WHEN ERROR THEN END; END IF; ` } } module.exports = { insertIfNotExists }; 3.2 データセット作成時のエラーについて Dataformでは、テーブル生成時に対象となるデータセットが存在しない場合、自動的に生成されます。 ただし、複数のETL処理を並行して実行する場合、一方の処理でデータセット生成が行われている間に、他の処理でデータセットが未作成のままテーブル生成を試みる可能性があり、その際エラーが発生します。 私もベストプラクティスを持っていないのですが、暫定的な回避策としては以下のようにconfigのdependenciesを設定することで、処理の順序を制御できます。 config { type: "operations", name: "sampleB", hasOutput: true, tags: ["master"], dependencies: ["sampleA"] } データセットが存在しない場合のみなので運用時には影響がないものですが、この回避策は開発中に有効であり、環境の整合性を保ちながら進行できます。 4. まとめ 今回は初めてDataformに触れ、どのように準備し開発を進めているかについてお話ししました。 ETLツールを用いるのは初めてでしたが、基本的な操作は非常に簡単で、個別の機能についても十分にガイドや記事が出回っているため進めやすかったです。 Dataformを用いた開発の進め方やベストプラクティスについてはまだ模索中ですが、この記事が他の開発者の参考になれば幸いです。 Reference https://cloud.google.com/dataform?hl=ja https://cloud.google.com/bigquery?hl=ja https://www.ashisuto.co.jp/eai_blog/article/201811_etl.html https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

こんにちは。前年以上に暑い日が続いておりますが、皆様はいかがお過ごしでしょうか？ (私はプライベートで熱中症になってしまいました‥本当に危ないので是非皆様もお気をつけください‥) 本日は当社での採用活動の取り組みの紹介と、採用活動に従事する中で私が感じた面接に対する所感やTipsを記載できればと思います。 新卒採用の開始 当社では今年度より新卒採用を開始しております。 これまでについては、原則として中途採用を基本としており、若手を中心とした採用というよりも、ある程度の年次を重ねた経験者の採用を中心としておりました。 今般、設立５年を迎えたことを契機に、今後の組織拡大や成長戦略も鑑み、25年卒を対象に新卒採用を行なっております。 今後も継続的に新卒採用については注力したい、且つ、今年度については新卒採用開始の初年度ということもあり、全てが万全にスタートできた訳ではないので、今年度の反省点も活かしつつ、対応できればと考えております(今後の採用戦略についてはまた別の機会に触れられればと思います‥！)。 私が新卒採用に臨んでいた時代の話 前職でも経験あったものの、実際に新卒採用に携わるのは数年ぶりだったので、物凄く新鮮な気持ちで臨めました。 今でこそ、学生の売り手市場だと思いますが、私が就活に臨んでいた時代は深刻な就職氷河期の真っ只中でした。信じられないかもしれないですが、エントリーから数十社は当たり前で、人によっては100社超のエントリーを行っている人もいました。 それでも企業の採用予定人数は相当数絞られていたので、書類選考やテスト、各種面接で相当数が篩にかけられていました。 そのため、誰しもが数社内定を保有しているという状況は非常に稀有でした(複数内定が出た上で入社先を検討する、という行為自体がとても困難な状況でした)。 いつの時代も企業は「優秀」な学生が欲しい あれから十数年経過し、新卒採用を受ける側から採用する側に回って、非常に感慨深いものを感じます。 そして今だからこそ感じるのは、時代背景は異なれど、企業が学生に求めるものは変わってはいないということです。 端的に言えば、それは「優秀」な学生が欲しいということにはなるのですが、括弧書きにしている通り、ここでいう「優秀」とは何でしょうか？ 当時の私は学業で優秀な成績を収めている、または学外の活動でも秀でた経験を積んでいることを「優秀」と考えておりましたが、実のところは全く違いました。 採用する立場になって思うのは、「再現性」の有無＝「優秀」かどうか、という点です。 もちろん、上記の記載事項もとても大事です。企業の社風や特性に応じても求められる事項は多少の変化はあるかもしれません。 ただ、採用する立場としては、入社いただいた上でその会社でも面接時に語っていた経験や実績同様の成果を挙げて欲しい＝過去、達成した成果や乗り越えた苦難に対して、本人が実行したプロセスや技能・考えを、その会社の業務でも十分に活かせるように再現して欲しい、ということが一番に求める事項になります。 振り返ると、面接に通過した学生や優秀と思える学生は、皆この点が共通しており、面接の中でも十分にそれらを感じられる応対をしていたと思います。 面接を通じて感じること 一方で上記の再現性を感じる前に、または感じても採用に至らないケースもあります。 面接を行う中でも「とても惜しいな‥」と思う瞬間も多々あり、中途採用でも同様に感じる部分もあるので、最後にどうした部分に該当するのかを数点記載したいと思います。 1.コミュニケーションに関して 面接を行なっている中で、面接官の質問に恐らく準備していただいた回答を纏めて回答するケースが散見されます。 例えば、自己紹介をお願いしたケースで、所属や趣味等の自己紹介に留まらず、志望理由や転職理由を述べてしまうケースがこれに該当します。 このような回答をしてしまうケースが割合少なくなく、特に私がもったいないと感じてしまいます。 面接というと、厳格なシチュエーションを想定され、相応に緊張もしてしまうので、このような状況になってしまうのも無理はないとは感じます。 ただ、面接官としては面接という試験ではあるものの、会話というコミュニケーションを通じて候補者の適性や評価を行いたい気持ちが強いため、いかに回答内容が素晴らしくとも、そもそも上記のようなコミュニケーションを取られてしまうと、難色を感じずにはいられなくなってしまうのです。 2. 回答に関して やや１とも共通する話ではあるのですが、面接官の質問に「答え過ぎてしまう」回答を行うケースも散見されます。 例えば、志望動機を確認しているケースで、就職に踏み切った背景や転職理由を述べてしまうケースです。 これも気持ちは物凄く分かります。候補者の中では、それら事項と志望動機の因果関係があるので、背景から語りたいと考えているのだと思います。 しかし、冷静に考えると、求められている質問に対する回答とは異なる回答をしてしまう時点で、正しく回答出来ているという評価にはなりません。例えるのであれば、数学の筆記試験で問題文に対しての回答と、その回答に至った見解まで回答しているようなものなのです(証明問題ならまた別かもしれませんが‥)。 加えて、先程も記載した通り、面接は会話というコミュニケーションを通じての試験になるので、先のケースであれば志望動機を確認した上で、その回答の背景も確認したいのであれば、面接官より追加の質問がなされます。 そうした会話を通じて回答されれば全く問題ないのですが、質問に望まれる回答を回答出来ないケースも多々見受けられ、これもまたもったいないと感じる瞬間の一つです。 理想の面接とは 少し辛口な記載になってしまい、恐縮ながら、では逆に面接を通じて良かったと思える瞬間はどのような瞬間なのでしょうか？ それは「会話を楽しんでいる」、ということです。上記、偉そうに記載しておりますが、面接官も実際は物凄く緊張して臨んでおり、評価という場であることも相まって、色々なことを考え、気をつけながら面接を行っています。 例えば、どのような質問をすれば、候補者の魅力や強みを最大限引き出せるか？であったり、実務を想定した際にどのような職責が適切か、または案件毎に異なるステークホルダーと良好な関係性を築けるかであったり、何より候補者の価値観や将来のキャリアパスと弊社の方向性が合っているか、等です。 採用はともすれば、候補者の今後の人生を左右しかねない重要なイベントであるからこそ、面接官も本気で、かつ慎重に判断をしなければならないプレッシャーと戦いながら、面接に臨んでいます。故の緊張であったりするのですが、こうした状況下でも当人のパフォーマンスは最大限発揮しながら、各種質問にも楽しみながら、意見交換や考えをぶつけていただき、双方がWin-Winで面接を終えられる状態が理想だと思っています。 最後に いかがでしたでしょうか？当社の新卒採用開始の話題から始まり、もし当社への入社を検討されている方や次年度以降の新卒採用に興味がある方もいれば、ぜひ本記事も参考に面接対策を講じていただければ幸いです。 なお、新卒採用についても26年度採用もオープンしているため、興味ある方はぜひとも積極的なエントリーをお願いいたします。 recruit.insightedge.jp

こんにちは！Insight Edgeで営業を担当している塩見です。 今回は、私が生成AIと協力してWEBアプリ開発に取り組んだことについてお話しします。 私はエンジニアとしての業務経験がなく、フロントエンドとバックエンドのシステム開発に関する理解を深めることを目的に、個人でアプリ開発を行いました。 本記事にも記載していますが、生成AIを活用することで、エンジニアとしての業務経験の無い私でも、それほど時間をかけずアプリをゼロから開発することが出来ました。 どのような流れで開発を進めたかの情報を簡単にですが纏めていますので、気軽に読んでいただけますと大変うれしいです。 生成AIと協力して開発したアプリ アプリ概要 システム構成 開発の流れ 手描きイラストからページデザインを生成 ChatGPTと協力しながらアプリを開発 分からないところは生成AIに質問し学びを得る 開発の過程で得た学び 学習効率が高い ノーコードより柔軟・高速・簡単にアプリが開発可能 ChatGPTと正確に対話する技術が必要 まとめ 生成AIと協力して開発したアプリ アプリ概要 今回、下図のようなアプリを開発しました。 アプリのスクリーンショット 主に、以下のような機能があります。ユーザ登録が必要になりますが、各機能を自由に使用できる状態にしています。 チャット機能：複数名のペルソナを用意しており、各ペルソナと生成AIを使用したチャットでの会話ができます。 掲示板機能：掲示板のスレッドを作成することができ、作成したスレッドに対して、様々なペルソナがコメントを返します。 開発期間は約2ヶ月間で、週5-10時間程、開発方法を学習しながら実装を進めていました。 システム構成 システムの構成は下図のような内容になっています。 システム構成 各ツール/技術の概要は以下の通りです。 各ツール/技術の説明 これらの開発をChatGPTとの対話を通して行いました。 Next.jsやReactなど、初めて使用する技術要素が大半だったため、ChatGPTに質問しながら情報を得て実装を進めました。 開発の流れ 手描きイラストからページデザインを生成 アプリ開発を始めた当初、何もない状態からプログラムを書き始めることは、初学者にとって非常にハードルが高いと感じていました。 そこで、tldraw makerealというツール使用し、手描きのイラストからWEBアプリのデザインを作成することで、作業を開始しました。 tldraw makerealでは、手描きのイラストを基に、生成AIが自動的にデザインとHTMLを作成してくれます。 tldraw makerealの作業画面 tldraw makerealでは、ブラウザ上で作成したラフのイラストから、リアルなUIデザインを生成してくれます。 自然言語でコメントを入れることで、それに沿った内容もデザインに反映してくれます。 また、手描きイラストではなく、画像からデザインを生成することも可能です。 例えば、参考にしたいWEBアプリやサービスがある場合、その画面をキャプチャし、tldraw makerealにインプットすれば、それに近いデザインを出力してくれます。 初学者の方は、イラストを描くより、こちらの方が手軽で良いと思います。 tldraw makerealでは、デザインのHTMLも出力してくれるため、アプリ開発で必要な土台となるデザインのコードはこれで入手することが出来ます。 ある程度、自分の作りたいアプリのデザインが作成できたら、以降はChatGPTを使って作業を進めていきます。 tldraw makerealを使ってみたい方は、 こちらのページ が参考になるかと思います。 generativeinfo365.com ChatGPTと協力しながらアプリを開発 ここからは、ChatGPTと協力しながら、アプリ開発を進めていきます。 それほど特別な作業はしておらず、自分の理解度に応じて、ChatGPTへの質問を実直に繰り返していきます。 この取り組みでは、コーディング作業の多くをChatGPTに対応してもらいました。 作業者とChatGPTの関係 ChatGPTに質問を繰り返しながら環境構築を進め、環境構築後はtldraw makerealで作成したHTMLをベースにしながら、アプリのトップページ開発を開始しました。 上図のような流れで、実現したい機能や動作をChatGPTに伝え、コードの作成はChatGPTが実施し、コードの実行結果を私が確認するといった流れで対応を進めました。 ChatGPTが優秀なエンジニアとして一緒に作業を進めてくれたおかげで、私の理解度が限られている中でも非常に速いスピード感で開発を進めることが出来たと思います。 一方で、ChatGPTとの対話が長くなると、過去の会話内容を忘れてしまうことがあるため、定期的に新しいスレッドを作成し、最初から状況を説明する必要がありました。 また、開発が進むにつれて、共通処理をコンポーネント化したり、様々なAPIを作成したりすることが増え、参照するファイルが複数に渡ることも多くなったため、それらを全て説明するのも大変でした。 これらの作業が発生する点は、ChatGPTを活用してアプリ開発を進める上での課題感のように思います。 分からないところは生成AIに質問し学びを得る 今回は学習目的でアプリ開発を進めているため、実装を進める上で分からないところは正しく理解していきたいというモチベーションがあります。 ChatGPTは教育者としても非常に優れています。私はChatGPTが作成したコードについて、よく分からない箇所には全て解説のコメントを追記するよう指示し、それを確認することで、理解を深めました。場合によっては、ChatGPTの一次回答だけでは理解しきれない箇所もありますが、それについても深ぼって質問を行い、自身が理解できるまで対話を繰り返しました。 この作業については、ChatGPT上で実施するのではなく、Visual Studio Code等のエディタ上にてGitHub Copilotを活用すると、さらに学習効率が高まると思います。GitHub Copilotでは、不明なスクリプトを範囲選択し、すぐにコードの説明を出力させることが出来るので、ChatGPT上で質問する手間が少ないです。 開発の過程で得た学び 学習効率が高い 上記と少し重複しますが、生成AIと協力したアプリ開発は、学習効率がとても高い印象があります。 先ず、自分が作ってみたいアプリを開発しながら学習を進めることができるので、楽しみながらシステム開発に関する理解を深めることが出来ました。 また、コーディング作業が途中詰まり、長時間作業が進まないといったことも起こりづらく、進行スピードが速いので、途中で学習が挫折する可能性も低そうです。 その上、自分が理解したい箇所への深堀質問がいつでも気軽に出来る点も非常に有益です。プログラミング学習に関連する教育サービスは世の中に多くあり、いずれのサービスでもQA対応を行っていると思いますが、回答が来るまで時間がかかり、また回答の品質も講師に依存します。加え、何度も質問することを躊躇してしまうケースが多々あるかなと。こういった問題をChatGPTは解決しており、学習者の学習効率を高めてくれる作用があるものと思います。 ノーコードより柔軟・高速・簡単にアプリが開発可能 非エンジニアのアプリ開発を助けてくれる手段として、ノーコードツールがあります。私もBubbleなどのツールを使用した経験はありますが、それらと比べて、生成AIを活用したアプリ開発は、柔軟・高速・簡単に開発が出来るという印象を持ちました。 ノーコードツールも手軽にアプリ開発を行うことは出来ますが、まずはツールの使い方に関する理解が必要です。加えて、自分のアイデアをアプリに反映させたい場合、柔軟に内容を変更することが出来ず、ノーコードツールの出来ることからアイデアを考えていくといった動き方になりがちだと思います。 一方、生成AIを活用したアプリ開発では、自分のやりたいことを生成AIに伝えるだけで、コードをゼロから即座に作成してくれます。ノーコードツールの機能に制限されることなく、自分のアイデアを反映させることができ、また自然言語でのコミュニケーションだけで開発を進められます。 ChatGPTと正確に対話する技術が必要 ChatGPTと協力して開発を進める場合、正確な情報をChatGPTに伝える必要があります。回答が意図しないものになっている場合、こちらが伝えるべき情報が不足していたり、またはやり取りが長期化しChatGPTが過去のやり取りを忘れている可能性があります。 私がChatGPTによく伝えていた情報としては、アプリのディレクトリ構成と関連するコードの全量です。アプリの全体像について、ChatGPTが正しく理解出来ているほど、回答の内容が私の期待に近いものになる傾向がありましたので、可能な限り全体像を理解してもらうように対応していました。 しかし、ChatGPTは会話の量が増えると過去のやり取りを忘れてしまう点がやはり大きな課題でした。定期的にスレッドを切り替えるのですが、都度、ChatGPTに現況を説明する作業を行うのは手間があり、この点を解消したいとは考えていましたが、良い方法は思いつかず。今後、ChatGPT等の生成AIが覚えていられるテキスト量が増えてくれば、この課題も少しずつ改善してくるものと思います。 まとめ 以上が、私が生成AIと協力してアプリを開発したときのお話でした。 非エンジニアでも、自身のアイデアをWEBサービスとして実現出来る世の中になってきたと強く感じました。 また、プログラミング等の学習方法も変わってきていると思います。 プログラミング教室では、QA対応を講師が行っているケースが多いかと思いますが、即座に回答してくれて気兼ねなく質問できるChatGPT等の生成AIの方が、利便性は高い印象です。 今後は、学習のモチベーターやスケジュール管理をしてくれるような教育人材の重要度が高まるかもしれません。 今回は主にChatGPTを活用してアプリ開発を行ってきましたが、まだまだ不便な点は多くあります。 そんな中で、生成AIを活用したアプリケーション開発のプラットフォームも様々なものが出てきています。 例えば、 create というサービスでは、生成AIを活用することで、自然言語処理でアプリ開発が出来ます。 www.create.xyz 従来のGUIベースでのノーコードツールではなく、createのように、自然言語ベースで構築可能な新しいノーコードツールの人気は今後高まってくるかもしれませんね。 個人的には、アプリ開発の一式ファイルを自動で参照してくれて、各ファイルの修正や新規ファイル作成等を行ってくれるツールが出てくると、アプリケーション開発の市民化が一気に加速化する気がします。直近の生成AIに関する進化スピードを踏まえると、数年以内に解決しそうな気もします。 今回開発したアプリでは、まだ実現できていないアイデアがいくつかありますので、今後も順次開発を進めていきたいと思います。生成AIを上手く活用しつつ、様々な機能実装を通して、自身の学びを深めていきたいと思います。