目次 はじめに 背景：クラスタリング結果の「解釈」はなぜ難しいのか 論文の概要：「クラスタの意味」をLLMで説明する 提案手法 結果と考察 ポスター発表の感想 おわりに はじめに こんにちは、Insight Edgeのカイオです。 先日、言語処理学会 第32回年次大会で、「クラスタの"意味"を語るAI：LLMによる教師なし学習の説明性付与」というテーマで発表しました。本記事では、その発表内容をベースに、論文で扱った問題設定、提案手法、結果、そして発表を通じて改めて感じたことをご紹介します。 背景：クラスタリング結果の「解釈」はなぜ難しいのか クラスタリングは教師なし学習の一種であり、数値的な類似度や距離に基づいてデータをグループ化します。K-meansのような代表的な手法は計算効率も高く、大規模データにも適用しやすいため、実務でも研究でも広く使われています。 ただし、クラスタリングの出力そのものは、多くの場合あくまで「数値空間上で近いものがまとまった結果」です。人間が本当に知りたいのは、その先にある意味です。たとえば、「このクラスタは正常に近い状態なのか」「このクラスタは病理的な特徴を表しているのか」「このサンプルの一番近いサンプルはどれか」といった問いに答えられて、初めて分析結果は意思決定に使えるようになります。クラスタリングは次元数が多く、可視化しづらいため、さまざまな工夫が必要です。以下に、今回のクラスタのPCAを示します。 クラスタリングの可視化方法の一種であるPCA しかし現実には、その意味付けは分析者の経験やドメイン知識に大きく依存します。特徴量の分布や代表サンプルを見ながら解釈を組み立てる作業には時間がかかりますし、同じ結果を見ても人によって説明がずれることもあります。とくに、説明責任や再現性が求められる領域では、この「解釈の主観性」が大きな課題になります。 ここで注目したのが、近年のLLMです。LLMは、自然言語だけでなく、数値や統計量を含む構造化データに対しても推論・要約・比較を行えるようになってきました。であれば、クラスタリング結果の統計的特徴を入力し、それをドメイン知識と結びつけて自然言語で説明させることができるのではないか。これが本研究の出発点です。 論文の概要：「クラスタの意味」をLLMで説明する 本研究では、クラスタごとの統計量をLLMに入力し、LLMが事前学習で獲得したドメイン固有の知識を活用しながら、各クラスタの意味や特徴を自然言語で生成するという枠組みを提案しました。狙いは、クラスタリングの結果を人が読んで理解できる説明へと変換することです。 検証対象として選んだのはEEG（脳波）データです。EEGは多次元で個人差も大きく、解釈には神経科学や臨床の知識が必要になります。つまり、今回のテーマである「クラスタの意味付け」が難しい、まさに代表的な題材です。ここで有効性を示せれば、他の複雑な教師なし学習タスクにも広げられる可能性があります。 提案手法 今回用いたデータセットは、OpenNeuroで公開されているds004504です。このデータセットはクリエイティブ・コモンズ・ライセンス（CC0 Public Domain Declaration）の下で利用可能です。アルツハイマー病患者、前頭側頭型認知症患者、健常対照群の全88人分のEEGデータから構成されており、認知機能の違いに応じた脳活動パターンを比較しやすいデータセットです。被験者はMMSEと呼ばれる神経心理検査を実施中にEEG計測を受けており、19チャンネル、500Hzで、およそ5〜15分の脳波が記録されています。公開データには、ノイズ除去やフィルタリングなどの前処理も施されています。以下の図は被験者1人、1チャンネルのサンプルデータです。 被験者1人、1チャンネルのサンプルデータ さらに我々が行った処理では、各被験者のEEGについて19チャンネルの平均を取り5秒長・50%オーバーラップの時間ウィンドウに分割し、FFTを適用したうえで、delta、theta、alpha、beta、gammaの各周波数帯域に分解しました。5秒という窓長は、MMSEの比較的容易な質問に応答するために必要な時間を踏まえて設定しています。こうして、ウィンドウ単位で脳波の特徴を扱える形にしました。以下はFFT後のデータの1サンプルです。 FFT後のデータの１サンプル クラスタリングには原理が比較的単純で、LLMによる解釈対象としても扱いやすいK-meansを採用し、Elbow法に基づいてクラスタ数をk=6に設定しました。全88人分のデータに対して、ウィンドウごとの脳波パターンをクラスタリングしています。被験者群ごとに現れやすい脳波パターンが異なっていることも、この段階で確認できました。時系列で見た、ある被験者1人のクラスタ分類結果は以下の通りです。 被験者一人の分類されたクラスタ そのうえで、各クラスタを代表するクラスタ重心をLLMに入力し、統計的特徴と神経科学的・臨床的知見を結びつけた説明を生成させました。重要なのは、診断ラベルやその分布情報は与えず、重心に含まれる特徴量のみに基づいて説明を行わせた点です。今回使用したLLMはGemini 2.5 Proです。つまり、「答えを知っている状態で説明させた」のではなく、「数値特徴だけを見て、どこまで意味のある説明ができるか」を検証した形になります。 結果と考察 結果として、多くのクラスタについて、LLMは周波数帯域ごとの特徴に触れながら、既存のEEG研究や専門家の解釈とおおむね整合的な説明を生成できました。とくに興味深かったのは、生理的脳波、病理的脳波、そしてアーチファクト由来のパターンが、説明文の内容から区別できるレベルで表現されたことです。 たとえば、健常者で最も多く観測されたクラスタ0について、LLMは「顕著なアルファ波の亢進を特徴とする、典型的な閉眼安静覚醒状態の脳波パターン」と説明しました。これは、健常被験者に見られる代表的なEEG所見と一致しており、クラスタリングで抽出された主要クラスタが、生理的に妥当な脳波状態を捉えている可能性を示しています。 被験者群ごとに現れやすい脳波パターン 一方で、健常群では出現頻度が低く、認知症群で相対的に多く見られたクラスタ2やクラスタ5については、「デルタ帯域の徐波化による脳機能低下を示唆するパターン」や「低振幅で非同期的な脳活動パターン」と説明されました。また、クラスタ1やクラスタ3では、高周波帯域の異常なパワー増大に着目し、筋電図アーチファクトや筋緊張に起因する信号混入の可能性にも言及しています。単なる数値の言い換えではなく、実務上重要な「解釈の論点」まで自然言語で引き上げられている点が、この結果の面白いところだと感じています。 論文の考察でも述べた通り、この結果は、LLMがブラックボックスな予測器としてだけでなく、数値解析結果を人が理解できる知識へ変換する媒介として機能し得ることを示唆しています。とくに医療や神経科学のように高い解釈性が求められる領域では、この「橋渡し」の価値は大きいはずです。教師なし学習の活用範囲は広い一方で、解釈の難しさが導入の壁になることも少なくありません。その壁を下げる手段として、LLMによる自然言語説明は有望だと考えています。 ポスター発表の感想 今回の発表は、私にとって初めての学会でのポスター発表であり、さらに学会発表自体もおよそ10年ぶりだったため、きちんとした発表ができるだろうかと不安に感じていました。ですが、実際には想像以上に多くの方に私たちの研究に興味を持っていただき、とても驚きました。 実際に多くいただいた質問は、前処理をどのように行ったのか、そしてLLMに本当に情報リークがなかったのか、という点でした。特に後者については、「LLMに与えたのは診断ラベルなどの情報ではなく、事前学習で獲得していた知識だけである」ということを、何度も説明する必要がありました。 結果として、90分の発表時間のあいだに同じ研究内容を何十回も説明することになり、まさに「鍛えられる」ような経験でした。その分、とても密度の濃い時間でもあり、このような機会をいただけたことに心から感謝しています。 おわりに 本研究では、LLMを用いてクラスタリング結果に説明可能性を付与する枠組みを提案し、EEGデータを対象に、その有効性を検証しました。クラスタ重心に基づいて、神経生理学的に妥当な自然言語説明を生成できたことは、数値解析と人間理解の間にあるギャップを埋める一つの方法を示せたと考えています。 今後は、分類手法や他のXAI手法との統合、さらに実データへの適用を通じて、実用性や汎用性をより詳しく検証していく予定です。教師なし学習は、まだまだ「使えるのに、説明しづらい」場面が多く残っています。そうした場面で、LLMが分析結果の翻訳者として機能する未来は、十分にあり得るのではないでしょうか。

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

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

こんにちは。Insight Edge（以下、IE）でデザイナーをしている水上です。 この記事では、IEのブランドロゴとコーポレートサイトを全面的につくり直したプロジェクトについて、制作プロセスとその裏側をお伝えします。 設立6年目、なぜ今リニューアルが必要だったのか 最初に決めたルール：「好き嫌い」でデザインを判断しない まずは「IEらしさ」を3つの言葉にした 不可能図形「ペンローズの三角形」をロゴにした理由 サイトは「IEを言葉で伝える場所」にした リリースはゴールではなくスタート 設立6年目、なぜ今リニューアルが必要だったのか IEは住友商事グループのデジタル・AI専門組織として、2019年に設立されました。グループ各社の事業課題に入り込み、構想から実装まで一貫して伴走するのが私たちの仕事です。 私はIEで約2年、プロジェクトやマーケティング、イベントのデザインを担当してきました。その中で、IEがグループ内でどんな立ち位置にあり、何を期待されているのかが少しずつ見えてきました。 一方で、設立から6年が経ち、私たちを取り巻く環境は大きく変わっていました。生成AIの急速な進化、グループ外への展開、グローバル案件の増加。従来のロゴは線が細くフラットな印象で、競合と並んだときに埋もれてしまう。サイトもIEの独自性を十分に伝えきれていない。事業の発信を強化し、一緒に働く仲間を惹きつけていくために、ブランドの土台から見直す必要がありました。 最初に決めたルール：「好き嫌い」でデザインを判断しない プロジェクトの最初に、私はひとつのルールを決めました。「かっこいい・かっこよくない」でデザインを選ばない、ということです。 ロゴやサイトは個人の作品ではありません。IEという組織のための、戦略的なデザインです。「どの選択がIEにとって最適か」を常に判断基準にする。この前提をプロジェクトの軸に据えました。 具体的には、IEのMission / Vision / Valueを土台にして、まず「IEはどんな性格の組織か」を定義する。その上で、競合との違いや顧客に届けたい印象を明確にしてからデザインに落とし込む。いわば、土台から順番に積み上げていくアプローチです。 まずは「IEらしさ」を3つの言葉にした デザインをつくる前に、私はまず「IEらしさとは何か」を言葉にする作業から始めました。 DX・AI領域には似たポジションの企業がたくさんあります。その多くが「実行力」「安定感」「知性」をブランドの軸にしています。IEも同じ方向に寄せるのではなく、自分たちならではの色を出す必要がありました。 競合分析と社内の議論を重ねて辿り着いたのが、IEのバリュー「やり抜く・やってみる・みんなでやる」と結びつく3つのコアパーソナリティです。 推進力（Drive） ：仮説を立てたらすぐ動く。プロトタイプから実装までやり切るスピードと覚悟。 共創力（Co-Creation） ：顧客と同じ目線で課題を掘り下げ、一緒にビジネスの価値をつくる力。 探索力（Exploration） ：AI・生成系技術・まだ見えていない課題領域に先回りして踏み込む姿勢。 不可能図形「ペンローズの三角形」をロゴにした理由 言葉が決まったら、次はそれをどう形にするか。ここからが実際のデザイン作業です。 大手総合商社内のグループ企業の中でどう見られるか、常に俯瞰の視点を意識すること。先端テクノロジーを標榜する企業としての新鮮さと保守的な判断の際（きわ）を丁寧に探ること。経営陣との対話の中で何度も意識したポイントです。 そのバランスを探り続ける中で辿り着いたのが、3つのパーソナリティを3本の矢印とペンローズの三角形で表現するアイデアでした。 矢印は前に進む推進力。3つの方向は探索力。3本が組み上がる構造は共創力。そしてペンローズの三角形は、三次元に見えるのに実際には存在しえない「不可能図形」です。まだ形のない課題に対しても、多角的に向き合い、解決の道筋を切り拓く。IEが顧客と向き合うときの姿勢を、この図形に重ねました。 ブランドカラーには、すこし紫がかったウルトラマリンブルーを「IE Blue」として定義しました。住友商事グループのデジタル系企業はブルー基調が多い中で、IEらしい先進性を感じさせる色として選んでいます。 サイトは「IEを言葉で伝える場所」にした 今までIEはMission / Vision / Valueという柱のみでブランドを語ってきました。しかし、DX・AI領域のプレイヤーが急増する中で、それだけでは足りないと感じていました。IEに何を期待できるのか、どんなキャラクターの組織なのか――その解像度を上げるための言葉を、もっと丁寧に紡いでいく必要がある。経営陣との対話の中で繰り返し出てきたこの想いが、コーポレートサイト刷新の出発点です。 今回のサイトリニューアルの目的は、見た目を整えることではありません。IEが自分たちの言葉で語れる場所をつくることです。 デザインのトーンで意識したのは、「先進的で知的なテクノロジスト」としての顔と、「顧客と一緒にビジネスの価値をつくる」親しみやすさの両立です。IEにはコンサルティングの機能もあり、市場や顧客に直接向き合う場面が多い。だからこそ、テクノロジー企業にありがちなクールさだけでは足りない。シンプルな表現の中にどうこだわりを込めるかが、デザイン上の大きなテーマでした。 サイトのキービジュアルには、ロゴの三本の矢がそれぞれの方向へ広がり、再び結束するアニメーションを採用しています。個々の推進力や探索力がバラバラに動くのではなく、その先で新たなつながりを生み出していく。IEの働き方そのものを表現したいと考えて、この動きに辿り着きました。 ビジュアル素材にもこだわりがあります。サイト内のイラストにはAI生成を活用していますが、抽象的なイメージビジュアルではなく、実際の案件事例を補足する具体的なイラストとして制作しました。ブランドトーンに沿った色味やタッチを統一することで、IEの世界観を視覚的に支える役割を持たせています。 メインメッセージは "Drive change with Insight. ― 技術と経験を磨き、共に未来の一歩をつくり出す。" です。変化の激しい領域で歩みを重ねてきたIEが、これから目指す姿勢を新しい言葉にしました。 リリースはゴールではなくスタート プロジェクトを通じて、経営・マネージャー陣には何度も率直な対話の時間をいただきました。忙しい中でブランドの言葉や方向性を一緒に考えてくださったこと、コーポレートサイトの仕上げに力を貸してくれた外部パートナー、そして個別事例や採用・翻訳に協力していただいた社内のメンバー。関わってくださったすべての方に、心から感謝しています。 DX・AI領域は変化のスピードが速く、今日の最適解が3ヶ月後には古くなっていることも珍しくありません。だからこそ、ブランドもデザインも、事業の成長に合わせてチューニングし続ける必要があります。 ここからまた一段と、IEの存在と価値を伝えるデザインをアップデートしていきます。 株式会社Insight Edge コーポレートサイト： https://insightedge.jp/

はじめに こんにちは。Insight Edgeでデータサイエンティストをしている善之です。 「Pythonで堅牢なコードを書きたいけど、どう設計すればいいんだろう…」 「バリデーション漏れや予期せぬバグに悩まされている…」 「Javaの設計原則は聞いたことあるけど、Pythonでも同じことができるの？」 こんな疑問や課題を持ったことはありませんか？ 先日、名著「良いコード/悪いコードで学ぶ設計入門」を読んで、その設計原則に感銘を受けました。 しかし、この書籍はサンプルコードがJavaで書かれており、Pythonでどう実装すればいいか悩みました。 そこで実際のプロジェクトで、これらの原則をPydanticを使ってPythonで実装する工夫を行ったところ、非常に効果的だったため、そのノウハウをご紹介します。 本記事は、Pythonでより堅牢なコード設計を学びたいエンジニアや、Javaの設計原則をPythonに応用したい方に向けた内容となっています。 なぜこの設計原則が重要か：実践で得たメリット 実際にこの設計原則をプロジェクトで適用した結果、以下のような具体的なメリットが得られました。 コードの安全性・堅牢性の向上 バリデーション漏れの防止 : 不正な値の混入による想定外の動作を防げた 予期せぬバグの防止 : 一度正しく設定した値が想定外に書き換わることがなく、安全にコードを書けた 開発生産性の向上 可読性の向上 : どこに何の処理があるか分かりやすく、ロジックの重複も防ぎやすい チーム開発の効率化 : クラス設計を事前にドキュメント化して共有することで、実装前に設計レビューができ、手戻りが少ない 以降では、これらのメリットを実現するための具体的な実装方法を解説します。 目次 実装した主要な設計原則 1. カプセル化：Pydanticを活用した堅牢なデータモデル 2. 不変（イミュータブル）の活用：frozenで安全性を高める 3. Nullを返さない、渡さない、代入しない 4. 条件分岐におけるInterfaceの活用：ポリモーフィズムと委譲 5. 実装して得られた実践的なメリット まとめ 実装した主要な設計原則 書籍で紹介されていた以下の設計原則を、Pythonで実装しました。 カプセル化 （バリデーション、ロジックのカプセル化） 不変（イミュータブル）の活用 Nullを返さない、渡さない、代入しない 条件分岐におけるInterfaceの活用 （ポリモーフィズムと委譲） それぞれについて、Pythonでどのように実装したかを具体例とともに解説していきます。 具体例では、書籍と同様にRPGの実装を想定したサンプルコードを用います。 1. カプセル化：Pydanticを活用した堅牢なデータモデル 書籍での原則 書籍では、以下のようなカプセル化の重要性が説かれていました。 コンストラクタで確実に正常値を設定する（バリデーションを必ず入れる） インスタンス変数の操作はクラス内のメソッドで行う（ロジックのカプセル化） データとそれを操作するロジックを同じクラスに配置 BaseModelとRootModelの使い分け Pythonでこの原則を適用するには、Pydanticというライブラリが便利です。 Pydanticでは、 BaseModel と RootModel を使い分けることで、カプセル化を実現できます。 BaseModel : 複数の属性を持つクラス 例: Member （パーティメンバー）、 Equipment （装備） RootModel : 単一の値を持つクラス（値クラス） 例: MemberId 、 MemberName 、 HitPoint メリット: model_dump() で "member_id": "M001" のように自然な形式で出力される RootModelを使わない場合: "member_id": {"value": "M001"} という冗長な形式になってしまう バリデーションの実装 Pydanticでは、 field_validator と model_validator を使ってバリデーションを実装します。 field_validator：単一フィールドのバリデーション 単一フィールドの値をチェックする際に使います。 class MemberName (RootModel[ str ]): """メンバー名""" root: str model_config = ConfigDict(frozen= True ) @ field_validator ( "root" ) @ classmethod def validate_name_length (cls, v: str ) -> str : """名前の長さをチェック""" if not v.strip(): raise ValueError ( "メンバー名は必須です" ) if len (v) > 20 : raise ValueError ( "メンバー名は20文字以内にしてください" ) return v class Job (RootModel[ str ]): """職業""" root: str model_config = ConfigDict(frozen= True ) @ field_validator ( "root" ) @ classmethod def validate_job (cls, v: str ) -> str : """職業の種類をチェック""" valid_jobs = { "Warrior" , "Mage" , "Rogue" } if v not in valid_jobs: raise ValueError (f "職業は{valid_jobs}のいずれかを指定してください" ) return v model_validator：クラスメンバ間の整合性チェック 複数のフィールド間の関係性をチェックする際に使います。 例えば、「現在HPは最大HPを超えてはいけない」といった制約を実装できます。 class HitPoint (RootModel[ int ]): """HP""" root: int model_config = ConfigDict(frozen= True ) class Member (BaseModel): """パーティメンバー""" name: MemberName job: Job current_hp: HitPoint max_hp: HitPoint model_config = ConfigDict(frozen= True ) @ model_validator (mode= "after" ) def validate_hp_constraint (self) -> Self: """現在HPが最大HPを超えないことをチェック""" if self.current_hp.root > self.max_hp.root: raise ValueError ( "現在HPは最大HPを超えることはできません" ) return self field_validatorとmodel_validatorを使うメリット: init で実装すれば良いのでは？と思われるかもしれませんが、 field_validatorとmodel_validatorを使うことで以下のメリットがあります。 バリデーションロジックの分離と再利用性が高まる Pydanticの ValidationError で統一的なエラー処理ができる JSON schema生成や自動ドキュメント化といったエコシステムとの統合 __init__ に全て書くと可読性が低下するが、デコレータで宣言的に記述できる ロジックのカプセル化 データを持つクラスに、そのデータを操作するメソッドも配置することで、ロジックのカプセル化を実現します。 class Job (RootModel[ str ]): """職業（Warrior, Mage, Rogueのいずれか）""" root: str model_config = ConfigDict(frozen= True ) @ field_validator ( "root" ) @ classmethod def validate_value (cls, v: str ) -> str : valid_jobs = { "Warrior" , "Mage" , "Rogue" } if v not in valid_jobs: raise ValueError (f "職業は{valid_jobs}のいずれかを指定してください" ) return v def can_use_magic (self) -> bool : """魔法を使える職業かどうかを判定する""" return self.root == "Mage" def can_equip_heavy_armor (self) -> bool : """重装備を装着できる職業かどうかを判定する""" return self.root == "Warrior" class HitPoint (RootModel[ int ]): """HP""" root: int model_config = ConfigDict(frozen= True ) def is_critical (self, max_hp: "HitPoint" ) -> bool : """HPが危機的状態（最大HPの30%以下）かどうかを判定する""" return self.root <= max_hp.root * 0.3 このように、 Job クラスに職業に関する判定メソッドを持たせることで、ロジックが散らばらず、可読性が高まります。 値クラスの徹底 全ての値をクラス化することで、型安全性とバリデーションの一元化を実現します。 例: str ではなく MemberId 、 MemberName 、 ItemName など 例: int ではなく HitPoint 、 MagicPoint 、 AttackPower など 例: bool ではなく IsAlive 、 CanFly 、 IsEquipped など プリミティブ型をそのまま使うと、どの値に対してもバリデーションが必要になり、漏れが発生しやすくなります。 値クラスを使うことで、その値を使う全ての箇所でバリデーションが保証されます。 2. 不変（イミュータブル）の活用：frozenで安全性を高める 書籍での原則 書籍では、イミュータブルな設計の重要性が説かれていました。 再代入はしない オブジェクトの状態を変更せず、新しいオブジェクトを返す 予期せぬ副作用を防ぐ frozenによる基本的なイミュータブル化 Pydanticでは、 model_config = ConfigDict(frozen=True) を設定することで、インスタンス生成後の属性変更を禁止できます。 class MemberName (RootModel[ str ]): """メンバー名""" root: str model_config = ConfigDict(frozen= True ) # これでイミュータブルになる Pythonにはfinal修飾子がないことへの対処 Javaの final に相当する機能がPythonには存在しません。 typing.Final は型ヒントのみで、実行時には強制されないため、 frozen=True を使ってイミュータブル性を確保します。 コレクション型のイミュータブル化 listではなくtupleを使用 list はミュータブルなので、 tuple を使うことでイミュータブル性を確保します。 from types import MappingProxyType class MemberName (RootModel[ str ]): """メンバー名""" root: str model_config = ConfigDict(frozen= True ) class Party (RootModel[ tuple [MemberName, ...]]): """パーティメンバーの集合""" root: tuple [MemberName, ...] = () model_config = ConfigDict(frozen= True ) def add_member (self, new_member: MemberName) -> "Party" : """新しいメンバーを追加した新インスタンスを返す（Immutable）""" if len (self.root) >= 4 : raise ValueError ( "パーティは最大4人までです" ) return self.model_copy(update={ "root" : self.root + (new_member,)}) def __contains__ (self, member: MemberName) -> bool : """指定されたメンバーがパーティに含まれているかチェック""" return member in self.root このように、 add_member メソッドでは元のオブジェクトを変更せず、新しい Party インスタンスを返します。 dictではなくMappingProxyTypeを使用 dict はミュータブルなので、読み取り専用の MappingProxyType を使用することで、外部からの変更を防ぐことができます。 model_copyによるイミュータブルなオブジェクトの更新 frozen=True のオブジェクトは直接変更できないため、値を変更するメソッドをクラス内に実装します。 メソッド内で model_copy(update={...}) を使い、新しいインスタンスを返すことで、元のオブジェクトは変更されず、安全に状態を更新できます。 class Member (BaseModel): """パーティメンバー""" name: MemberName job: Job level: Level current_hp: HitPoint max_hp: HitPoint model_config = ConfigDict(frozen= True ) def recover_hp (self, recovery_amount: int ) -> "Member" : """HPを回復した新しいインスタンスを返す（Immutable）""" new_hp = min (self.current_hp.root + recovery_amount, self.max_hp.root) return self.model_copy(update={ "current_hp" : HitPoint(new_hp)}) # 使用例 injured_warrior = Member( name=MemberName( "アーサー" ), job=Job( "Warrior" ), level=Level( 25 ), current_hp=HitPoint( 30 ), max_hp=HitPoint( 100 ) ) # HPを回復（クラスのメソッドを通じて操作） healed_warrior = injured_warrior.recover_hp( 70 ) print (f "元のメンバー: HP {injured_warrior.current_hp.root}" ) # 30 print (f "回復後: HP {healed_warrior.current_hp.root}" ) # 100 このように、クラス内のメソッドを通じて操作を行うことで、ロジックのカプセル化とイミュータブル性の両方を実現できます。 3. Nullを返さない、渡さない、代入しない 書籍での原則 書籍では、 null を避ける重要性が説かれていました。 null は予期せぬエラーの原因となる null チェックの漏れを防ぐ 代わりに「空の状態を表すオブジェクト」を使う EMPTYパターン（Null Objectパターン） Javaでは static final で空のインスタンスを定義しますが、 今回Pythonで実装するにあたり @classmethod で empty() ファクトリメソッドを提供することにしました。 class ItemName (RootModel[ str ]): """アイテム名""" root: str model_config = ConfigDict(frozen= True ) @ classmethod def empty (cls) -> "ItemName" : """空のItemNameを返す""" return cls( "" ) def __bool__ (self) -> bool : """ItemNameが空かどうかを判定する""" return bool (self.root.strip()) class MagicPoint (RootModel[ int ]): """MP""" root: int model_config = ConfigDict(frozen= True ) @ classmethod def empty (cls) -> "MagicPoint" : """空のMagicPointを返す（MP=0）""" return cls( 0 ) def __bool__ (self) -> bool : """MPが存在するかどうかを判定する""" return self.root > 0 型ごとの空の表現: 数値の場合: None の代わりに値が 0 のインスタンスを返す 文字列の場合: None の代わりに空文字 "" のインスタンスを返す コレクションの場合: None の代わりに空のtuple () のインスタンスを返す bool メソッドによる存在判定 null 判定の代わりに、 __bool__(self) メソッドで中身の値が存在するかを判定します。 これにより、Pythonらしい if xxx: という記述で中身があるかの判定が可能になります。 # 使用例 item_name = ItemName.empty() if item_name: # アイテムが存在する場合の処理 print (f "アイテム: {item_name.root}" ) else : # アイテムが存在しない場合の処理 print ( "アイテムなし" ) 4. 条件分岐におけるInterfaceの活用：ポリモーフィズムと委譲 書籍での原則 書籍では、条件分岐をInterfaceで置き換える設計が推奨されていました。 条件分岐（if/switch文）を使わず、Interfaceとポリモーフィズムで表現 「委譲」を使ってロジックを分離 新しい条件追加時にコード修正が最小限になる（Open-Closed Principle） ABCを使った抽象基底クラス Pythonには interface キーワードがないため、 abc.ABC を使用して抽象基底クラスを定義します。 from abc import ABC, abstractmethod class EquipmentCondition (ABC): """装備条件の抽象クラス""" @ abstractmethod def can_equip (self, member: "Member" ) -> bool : """メンバーが装備可能かを判定する""" pass @ abstractmethod def get_description (self) -> str : """条件の説明を取得する""" pass 具体的な条件クラスの実装 抽象クラスを継承して、具体的な条件を実装します。 class Level (RootModel[ int ]): """レベル""" root: int model_config = ConfigDict(frozen= True ) class JobCondition (BaseModel, EquipmentCondition): """職業に基づく装備条件""" required_job: Job model_config = ConfigDict(frozen= True ) def can_equip (self, member: "Member" ) -> bool : """指定された職業のメンバーのみ装備可能""" return member.job.root == self.required_job.root def get_description (self) -> str : return f "{self.required_job.root}専用" class LevelCondition (BaseModel, EquipmentCondition): """レベルに基づく装備条件""" required_level: Level model_config = ConfigDict(frozen= True ) def can_equip (self, member: "Member" ) -> bool : """指定されたレベル以上のメンバーのみ装備可能""" return member.level.root >= self.required_level.root def get_description (self) -> str : return f "レベル{self.required_level.root}以上" このように、 JobCondition と LevelCondition という異なる条件をそれぞれ別のクラスで表現します。 条件の使用例：委譲パターン 装備アイテムクラスが装備条件を保持し、実行時に適切な条件クラスのメソッドが呼ばれます（ポリモーフィズム）。 条件分岐を書かずに、委譲で処理を実現できます。 class Equipment (BaseModel): """装備アイテム""" name: ItemName conditions: tuple [EquipmentCondition, ...] model_config = ConfigDict(frozen= True ) def can_be_equipped_by (self, member: "Member" ) -> bool : """指定されたメンバーが装備可能かを判定""" # 全ての条件を満たす必要がある return all (condition.can_equip(member) for condition in self.conditions) def get_requirement_text (self) -> str : """装備条件の説明文を取得""" if not self.conditions: return "誰でも装備可能" return "、" .join(cond.get_description() for cond in self.conditions) # 使用例 excalibur = Equipment( name=ItemName( "エクスカリバー" ), conditions=( JobCondition(required_job=Job( "Warrior" )), LevelCondition(required_level=Level( 20 )) ) ) warrior = Member( name=MemberName( "アーサー" ), job=Job( "Warrior" ), level=Level( 25 ), current_hp=HitPoint( 100 ), max_hp=HitPoint( 100 ) ) # 条件分岐を書かずに、委譲で処理 if excalibur.can_be_equipped_by(warrior): print (f "{warrior.name.root}は{excalibur.name.root}を装備できます" ) この実装の優れている点は、新しい条件（例えば StrengthCondition ）を追加する際に、既存のコードを変更する必要がないことです。 新しい条件クラスを作るだけで、 Equipment クラスはそのまま動作します。 5. 実装して得られた実践的なメリット 実際にこの設計原則をプロジェクトで適用した結果、以下のようなメリットが得られました。 コードの安全性・堅牢性の向上 バリデーションによる予期せぬ挙動の防止 バリデーションをしっかり行うことで、不正な値の混入による想定外の動作を防げました。 特に、複数人で開発する際に、他のメンバーが誤った値を渡してもバリデーションで防げたため、開発初期にエラーが発生し、デバッグが容易でした。 実際のプロジェクトではあるアルゴリズムを実装したのですが、アルゴリズムの予期せぬ挙動を防ぐことができました。 イミュータブルによる安全性の向上 イミュータブルなので、バリデーションで正しく入った値を後から勝手に書き換えられない安心感がありました。 複数箇所でオブジェクトを参照しても、意図しない変更による副作用がなく、安全にコードを書けました。 値クラスによるバリデーション漏れの防止 全ての値をクラス化（値クラス）したことで、バリデーションに漏れがありませんでした。 プリミティブ型をそのまま使うと、バリデーション忘れが発生しやすいですが、値クラスを使うことで型エラーで早期に問題を発見できました。 一方で、これによりクラス数が膨大になってしまうと思われるかもしれません。 実際に、途中参加したメンバーからは「クラス数が多くて最初は面食らった」という声もありました。 しかし、同じメンバーも「1つ1つのクラスがシンプルな作りになっているため慣れるのは早かった」と述べており、学習コストはそれほど高くありませんでした。 また、1つ1つのクラスにバリデーションが集約されることで可読性が向上し、コードを読む際の認知負荷が軽減されるメリットは、クラス数が増えるデメリットを上回ると考えています。 開発生産性の向上 カプセル化による可読性の向上 クラス内にそのクラスの値に関連する操作の関数が入るので、可読性が高くなりました。 どこに何の処理があるか分かりやすく、ロジックの重複も防ぎやすくなりました。 インターフェース設計による要件の明確化とチーム開発の効率化 まずはインターフェースのみ設計したのち、MkDocsで自動ドキュメント化してメンバーに共有することで、データ型やバリデーション条件など、必要な要件が明確に伝わりました。 実装前に設計レビューができたため、手戻りが少なく、チーム全体の開発効率が向上しました。 まとめ 今回は、Javaベースの設計原則をPythonでいかに実現するかについて、実装例とともにご紹介しました。 Pydanticを活用することで、 frozen=True 、 RootModel 、 field_validator 、 model_validator といった強力な機能を使い、Javaベースの設計原則をPythonでも十分に実現できました。 実際のプロジェクトで適用した結果、バリデーション漏れの防止、予期せぬ副作用の回避、可読性の向上など、多くのメリットが得られました。 Pythonで堅牢なコードを書きたい方や、設計原則に興味がある方の参考になれば幸いです。 関連記事 設計原則については弊社のテックブログでも過去に取り上げていますので、以下の記事も是非ご参照ください。 生成AIアプリのクリーンアーキテクチャを考える - カプセル化や抽象化をアプリケーション全体のアーキテクチャに適用する方法を解説しています FastAPI,Pydantic,AWS DynamoDBを組み合わせた型安全なAPI構築方法について - Pydanticを実際のAPI開発で活用する実践例を紹介しています AdhocなPythonコードをProduction-readyにするために心掛けていること - 型情報の付与やバリデーションを含む、実運用を見据えたPythonコード品質向上の手法を解説しています 参考文献: 「良いコード/悪いコードで学ぶ設計入門」（仙塲大也 著、技術評論社） Pydantic公式ドキュメント: https://docs.pydantic.dev/ Python公式ドキュメント（abc module）: https://docs.python.org/3/library/abc.html

こんにちは、データサイエンティストの小柳です。 プロセスマイニングという考え方およびツールがあります。 プロセスのイベントログデータを収集し、業務プロセスの実体を可視化、分析する手法です。業務フローが言語化されていない場合や、想定されている業務フローと実際に行われている業務フローに乖離がある場合にこの手法を用いることで実際の業務フローが可視化され、どこを改善するかを検討する材料になるわけです。 しかし、プロセスマイニングで業務フローが見えたとして、その先に何ができるでしょうか。「今年何件受注できそうか」「どの施策がKPI達成に最も寄与するか」——こうした問いに答えるには、可視化の先にある 定量的なモデリングと予測 が必要です。 本記事では、プロセスマイニングで得られたDAG（有向非巡回グラフ）上の遷移時間をガンマ分布でベイズ推定し、モンテカルロシミュレーションによるKPI達成確率の予測や施策の感度分析まで行う手法を提案します。極めて素朴なアプローチではありますが、応用先やさらなる発展も見込める手法です。読者の皆様がご自身のデータで分析を試みる際の参考になれば幸いです。 1. 序文 2. 背景と前提 3. モデル化の発想 3.1 指数分布と再生性の限界 3.2 ガンマ分布の選択 3.3 分岐のモデリング 4. ベイズ推定 4.1 ガンマ分布パラメータのベイズ推定 4.2 遷移確率のベイズ推定 4.3 デモデータによる推定結果 5. 欠損データへの対応 — モーメントマッチング 6. モンテカルロシミュレーションによるKPI予測 6.1 シミュレーションの枠組み 6.2 KPI達成確率の算出例 6.3 感度分析 7. さらに広がるアウトプット 8. 課題と発展 9. まとめ 1. 序文 冒頭ではプロセスマイニングを話題にしましたが、何もプロセスマイニングをしたデータのみが対象ではありません。 案件単位で業務が進む会社（SIer、コンサル等）の多くでは以下のようなログが取れるはずです。 プロジェクトID タイムスタンプ ステータス 担当者 1 2024/12/15 アポイント 佐藤 1 2025/1/1 プロジェクト提案 佐藤 1 2025/2/1 受注（X円） 佐藤 2 2025/1/15 プロジェクト提案 田中 1 2025/2/15 開発 山田 2 2025/1/15 失注 田中 このようなデータをプロジェクト管理ツールで見たりします。各案件で最新の情報を取れば現在の状況が、プロジェクト単位で推移を見れば過去の状況が見られるわけです。 しかし、今年何件開発案件を得られそうか、今年何件受注できそうか、今年いくらの受注額になりそうかといったKGIになりうる値を予測する際にはこのままでは使いづらいです。 そして課題と改善点の把握にもこのままのデータではあまり役立ちません。月々のアポイント取得数を今の10%増しにしたら、プロジェクト提案から受注への確率を5%上げたら、アポイントメントからプロジェクト提案の期間を1週間早めたら、KGIの達成確率はどうなるのか——そういったKPIの影響を見極めたうえで効率よくKGIを達成できたらうれしいですよね。 今回提案する分析を行うことで、このような示唆出しと分析ができるようになります。 2. 背景と前提 本記事では以下のような前提を置きます。 プロセスのDAG表現 : プロセスマイニングや業務分析を通じて、業務フローが有向非巡回グラフ（DAG）として表現されているものとします。各ノードはステータス（アポイント、提案、受注、失注、開発、納品など）を表し、各エッジはステータス間の遷移を表します。 分岐の存在 : あるステータスから複数のステータスに遷移する可能性があります。例えば「提案」ステータスからは「受注」と「失注」のどちらかに遷移します。 遷移時間 : 各エッジには遷移にかかる時間が付随します。例えば「アポイントから提案まで平均15日」のようなものです。この遷移時間は確率的にばらつきます。 非巡回の仮定 : 本記事ではループ（同じステータスへの差し戻し等）は扱いません。これは課題と発展のセクションで議論します。 本記事で用いるデモDAGは以下のような構造です。 デモDAG図 このDAGでは、案件はまず「アポイント」として発生し、「提案」を経て「受注」または「失注」に分岐します。受注した案件は「開発」を経て「納品」に至ります。 3. モデル化の発想 3.1 指数分布と再生性の限界 各エッジの遷移時間を確率的にモデリングすることを考えます。最も素朴に思いつくのは指数分布でしょう。指数分布の確率密度関数は以下の通りです。 指数分布はパラメータが の1つだけであり、シンプルで扱いやすいです。実際、プロセスの遷移を連続時間マルコフ連鎖としてモデリングする場合、遷移時間は自然に指数分布に従います。遷移行列（遷移率行列）を定義すれば各ステータスの滞在時間が指数分布で表されるため、理論的に整合性のあるモデルが構築できるのです。 しかし、指数分布には 無記憶性 と呼ばれる性質があります。 これは「すでに 日経過しているという条件のもとでさらに 日以上かかる確率は、最初から 日以上かかる確率と等しい」ことを意味します。連続時間マルコフ連鎖ではこの性質が理論の根幹を支えていますが、業務プロセスの遷移時間のモデリングとしては不自然です。 例えば、アポイントから提案まで「すでに2週間経っているのにまだ提案に至っていない案件」は、「今日アポイントを取ったばかりの案件」とは状況が異なるはずです。2週間経っても提案に至らない案件は、何か障害があるか、そもそも遷移しにくい案件である可能性があります。指数分布の無記憶性はこうした直感に反します。 もう1つの問題として、指数分布は で最大値を取り、単調に減少する形状しか表現できません。実際の遷移時間は「しばらくしてからピークが来る」ような山型の分布になることが多いですが、指数分布ではこれを表現できません。 指数分布によるフィッティング 3.2 ガンマ分布の選択 そこで、指数分布を一般化した ガンマ分布 を採用します。ガンマ分布の確率密度関数は以下の通りです。 ここで は形状パラメータ、 は率（rate）パラメータです。ガンマ分布の期待値と分散は以下の通りです。 ガンマ分布の重要な性質として、 のとき指数分布に退化します。つまり指数分布はガンマ分布の特殊ケースです。 の場合、分布は で値が0になり、途中でピークを持つ山型の形状になります。 が大きくなるほどピークが右に移動し、分布の裾も長くなります。これにより「しばらく経ってから遷移が起こりやすくなる」ような現実のパターンを自然に表現できます。 異なるαのガンマ分布 再生性は失われますが、代わりに2パラメータによる豊かな表現力を得ることができます。遷移時間の平均だけでなく、分布の形状（ばらつきの大きさ、ピークの位置）まで柔軟にモデリングできるのがガンマ分布の利点です。 3.3 分岐のモデリング 次に、分岐（あるノードから複数の遷移先がある場合）のモデリングを考えます。 2分岐の場合 （例: 提案→受注 or 失注）は、ベルヌーイ分布を使います。遷移先を とすると、 ここで は受注に遷移する確率です。 3分岐以上の場合 （例: 審査→承認/条件付承認/却下）は、 の多項分布、すなわちカテゴリカル分布を使います。 エッジごとの遷移時間はそれぞれ独立したガンマ分布でモデリングします。つまり、各ノード では「どこに行くか」と「どれくらいかかるか」の2つを同時にモデリングすることになります。 このように、遷移確率と遷移時間分布を組み合わせることで、分岐を含むDAG全体を自然にモデリングできます。2分岐もカテゴリカル分布の特殊ケース（ ）として統一的に扱えますが、2分岐の場合はベルヌーイ分布として扱う方が数式が簡潔になります。 4. ベイズ推定 4.1 ガンマ分布パラメータのベイズ推定 あるエッジの遷移時間の観測データ から、ガンマ分布のパラメータをベイズ推定します。 ガンマ分布は形状パラメータ と率パラメータ で定義されますが、これらに直接事前分布を置くと解釈が難しくなります。実務的には、 平均 と 分散 に再パラメータ化し、こちらに事前分布を置く方が解釈性が良くなります。 例えば「アポイントから提案までの遷移時間は平均10〜20日程度だろう」「ばらつきは数日〜数十日の範囲だろう」といったドメイン知識を、 と の事前分布として自然に表現できます。 尤度 : 事後分布は解析的には求まらないため、MCMC（マルコフ連鎖モンテカルロ法）で近似します。PyMCなどの確率的プログラミングライブラリを使えば、上記のモデルを記述するだけで事後分布のサンプリングが自動的に行われます。 MCMCの結果として の事後サンプルが得られ、そこから の事後サンプルも変換により得られます。事後分布を通じてパラメータの不確実性が定量的に表現されるため、後段のモンテカルロシミュレーションにそのまま活用できます。 4.2 遷移確率のベイズ推定 分岐ノードの遷移確率についてもベイズ推定を行います。 2分岐の場合 : ベルヌーイ分布の共役事前分布はベータ分布です。 事前分布 : 回の遷移のうち 回が遷移先Aだったとすると、 事後分布 : 3分岐以上の場合 : カテゴリカル分布の共役事前分布はディリクレ分布です。 事前分布 : 各遷移先への遷移回数 を観測すると、 事後分布 : ベイズ推定の利点は、サンプルサイズが少ない場合でも事前分布を通じてドメイン知識を反映でき、さらに事後分布としてパラメータの不確実性を定量的に表現できる点です。「受注確率は60%」と点推定するのではなく、「受注確率の95%信用区間は45%〜75%」のように不確実性を含めた報告ができます。 4.3 デモデータによる推定結果 2章で定義したデモDAGに対して、以下の真のパラメータからデータを生成し、ベイズ推定を行った結果を示します。 真のパラメータ : エッジ 遷移時間 期待値（日） アポイント→提案 15 提案→受注 40 提案→失注 13 受注→開発 7 開発→納品 100 分岐確率 : 提案→受注 60%、提案→失注 40% 30件のデモデータから推定を行うと、ガンマ分布は指数分布に比べてデータの分布形状をより適切に捉えます。特に、遷移時間が 付近で低く途中でピークを持つようなエッジ（例: アポイント→提案、提案→受注）では、 のガンマ分布でないとフィットが困難です。 - 遷移時間ヒストグラム + ガンマ/指数フィット重ね描き MCMCにより の事後分布が得られます。サンプルサイズが十分であれば事後分布は鋭いピークを持ち、推定の不確実性が小さいことを示します。事後分布から に変換した結果も確認できます。 パラメータの事後分布 遷移確率についても、ベータ分布の事後分布として推定されます。30件中18件が受注であれば、 の事後分布は となり、事後平均は約0.60、95%信用区間は約[0.42, 0.76]です。 遷移確率の事後分布（ベータ分布） 5. 欠損データへの対応 — モーメントマッチング 実務では、すべてのステータス間の遷移時間が記録されているとは限りません。例えば、アポイントから受注までの記録はあるが、間の「提案」ステータスのタイムスタンプが記録されていないケースがあります。このとき、個別のエッジの遷移時間はわからず、端点間の合計時間しか観測できません。 指数分布であれば再生性があるため、合計時間の分布も指数分布です。しかしガンマ分布には再生性がないため、2つの独立なガンマ分布の和は一般にはガンマ分布にならず、本来は畳み込みとして扱う必要があります。 ただし、各エッジの通過時間が独立に分布すると考えてしまえば、期待値と分散を加算することができます。 と が独立であるとき、 この性質を利用して、合計時間のサンプル平均とサンプル分散からモーメント方程式を立て、各エッジのパラメータを推定する疑似的な モーメントマッチング が可能です。 具体的には、合計時間 の観測データ が に従うと考えてしまいます。このときの は以下を満たします。 モーメントマッチングは厳密なベイズ推定に比べて正確性では劣りますが、完全な遷移履歴が得られない状況でも「それなりの推定」ができるという実用上の大きな利点があります。 試しに次の設定で作成したデータについて推論をしてみます。 - アポイントから納品までの30件のデータが存在 - 著しい欠損が生じており、大抵の場合複数エッジの経過時間のみが記録されている。 - 単体で観測されているエッジが極めて少ない。 - 各エッジにかかる時間は4.3節で使った真のパラメータを使って生成された。 この条件下で生成したデータに対し推論を実施、事後予測分布と実際にエッジ単体で観測されたものを比較したグラフが以下になります。 また、観測できたエッジのみに対してパラメータ推論をした結果および全データを使いモーメントマッチング推定を行った場合の信用区間の対比表が以下となります。 結果を見ると単体で観測されていないエッジに対してもそれなりに推定ができています。また、単エッジの結果がある個所の推定結果を大きく邪魔していないところもメリットと言えます。一方で真のパラメータを包含しない信用区間もあります。従って、単体エッジを使った推論よりも概ね良い結果になると言えます。 6. モンテカルロシミュレーションによるKPI予測 6.1 シミュレーションの枠組み ここまでで推定した遷移時間分布と遷移確率を用いて、今後のKPI達成確率を予測するモンテカルロシミュレーションを構築します。シミュレーションには以下の3つの要素が必要です。 推定済みモデル : 各エッジの遷移時間分布（ガンマ分布）と遷移確率（ベルヌーイ/多項分布）の事後分布 現在のパイプライン : 各ステータスに現在何件の案件が滞留しているか（例: アポイント5件、提案中8件、受注済み開発待ち3件） 新規流入モデル : 月ごとに何件の新規案件が入口ノード（アポイント）に流入するか（例: 月平均10件のポアソン分布） シミュレーションの手順は以下の通りです。 パラメータサンプリング : 各エッジの遷移時間パラメータ と遷移確率 を事後分布からサンプリングします。これによりパラメータの不確実性がシミュレーションに反映されます 既存案件の遷移 : 現在パイプラインに滞留中の各案件について、現在のステータスから先の遷移を確率的にサンプリングします。各ノードで遷移先（ベルヌーイ/多項分布）と遷移時間（ガンマ分布）をサンプリングし、期末までに到達するステータスを決定します 新規案件の生成 : 月ごとに新規案件を流入モデルから生成し、同様にDAG上の遷移をサンプリングします KPI集計 : 期末時点で各ステータスに到達した案件数をカウントします（例: 受注件数、納品件数） 反復 : 手順1〜4を多数回（例: 10,000回）繰り返し、KPIの分布を得ます 6.2 KPI達成確率の算出例 例として、「今期末（残り9ヶ月）までに受注ステータスに15件以上到達する」というKPI目標を設定します。 現在のパイプラインには以下の案件があるとします。 - アポイント: 5件 - 提案中: 8件 - 受注済み（開発中）: 3件 月間の新規アポイントは平均20件（正規分布）と仮定します。 10,000回のシミュレーションを行い、受注件数の分布を得ると、達成確率を以下のように算出できます。 各KPI目標値に対する達成確率を表にまとめると以下のようになります。 KPI目標（受注件数） 達成確率 8件以上 48.6% 10件以上 26.6% 12件以上 12.9% 15件以上 4% 同様に、受注額を対数正規分布等でモデリングし、モンテカルロシミュレーションに組み込むことで「年間売上X円以上の確率」も算出可能です。 このような方法を用いることで、今年の目標がどれほど難しいかを定量的に測ることが可能になります。 6.3 感度分析 KPIの達成確率に各施策がどの程度寄与するかを定量的に比較するため、感度分析を行います。以下の3つの施策を個別にシミュレーションに反映し、ベースケースとの比較を行います。 施策A : 月間アポイント数を10%増加（月平均10件→11件） 施策B : 提案→受注の遷移確率を5%向上（60%→65%） 施策C : アポイント→提案の遷移時間を1週間短縮（期待値15日→12日） 施策別KPI達成確率比較 シナリオ 受注8件以上の達成確率 ベースとの差 ベースケース 48.7% — 施策A（アポイント+10%） 51.6% +3pt 施策B（受注確率+5%） 53.7% +5pt 施策C（遷移時間-1週間） 88.8% +40pt この結果から、提案時間短縮（施策C）がKPI達成に最も効果的であることがわかります。このような定量的な比較ができることが、本手法の大きな実務的価値です。 シミュレーションの副産物として、各ステータスの平均滞留案件数も得られます。 どのステータスに案件が詰まりがちかを把握することで、ボトルネックの特定と改善施策の優先順位付けに役立ちます。 7. さらに広がるアウトプット 本手法の枠組みは汎用的であり、前章までで示した分析以外にも多くのアウトプットを得ることができます。プロセスマイニング単体ではわからなかった経営判断に直結する情報が、このモデリングを通じて得られるようになります。ほとんど他の場所で言及していますが、ここにまとめておきます。 年間売上予測 : 受注額を対数正規分布等でモデリングし、モンテカルロシミュレーションに組み込むことで、受注件数だけでなく売上金額の分布を得ることができます。「年間売上3億円以上の確率は何%か」のような問いに答えられます ボトルネック特定 : シミュレーション中の各ステータスの滞留案件数を時系列で可視化すると、どこに案件が詰まりがちかが一目でわかります。これは感度分析と組み合わせることで、改善施策の優先順位付けに直結します What-If分析の深掘り : 「担当者を1人増員した場合」「特定エッジの処理プロセスを自動化した場合」など、より細かい粒度での施策評価が可能です。遷移時間のパラメータを変更するだけでシミュレーションできます 現在のパイプラインだけでの目標達成度 : 新規流入を0としてシミュレーションを行うことで、現在のパイプラインにある案件だけで到達可能な受注数を予測できます。「あと何件の新規アポイントが必要か」を逆算する際の指標になります 回帰モデルによる拡張 : 遷移確率や遷移時間のパラメータに案件属性（案件規模、業種、担当者の経験年数等）を説明変数として回帰モデルを組み込むことで、「大型案件は遷移に時間がかかる」「ベテラン担当者は受注確率が高い」といった属性ごとの遷移特性の違いを捉えることも考えられます 8. 課題と発展 本手法にはいくつかの課題と発展の余地があります。 時間変動 : ビジネス環境の変化により遷移パラメータが経時変化する場合、過去のデータをそのまま使うと予測精度が低下します。時間窓を区切った再推定や、オンラインベイズ更新（逐次的にデータを追加して事後分布を更新する）が有効です。 回帰モデルの組み込み : 7章で言及した回帰モデルの詳細な定式化と推定方法は、本記事だけでは紙面が足りません。GLMやベイズ回帰をガンマ分布のパラメータに組み込む方法については、別の機会に取り上げるかもしれません。 9. まとめ 本記事では、プロセスマイニングで業務フローを可視化したあとの「次の一手」として、ガンマ分布によるベイズモデリングとモンテカルロシミュレーションを用いた分析手法を提案しました。 本手法により、以下のことが可能になります。 各遷移の時間分布と遷移確率を、不確実性を含めて定量的に把握できます 分岐を含むDAGを自然にモデリングできます 遷移履歴が欠損している場合でも、モーメントマッチングにより推定が可能です モンテカルロシミュレーションにより、KPI達成確率の予測と施策の感度分析ができます 素朴なアプローチではありますが、プロセスマイニングで可視化されたフローに対して「どこをどう改善すればKGI達成に効くのか」を定量的に議論できるようになる点で、実務的な価値があると考えています。 自社のデータサイエンスチームで試してみたい方は、本記事の数式をそのまま実装に落とし込むことができます。ご相談やご質問があれば、お気軽にInsight Edgeまでお問い合わせください。

はじめに こんにちは、Insight Edge アジャイル開発チームの山崎です。 マルチエージェントシステムを設計する際、多くの設計判断に直面します。議論はシングルステップで十分か、複数ステップに分割すべきか？各ステップに誰を参加させるべきか？プロンプトはどこまで詳細に書くべきか？ 今回の記事では、Google ADK + Geminiを用いて、スタートアップの新規事業立案という具体的な意思決定の事例でマルチエージェントシステムを実際に構築し、議論の論点、議論の進め方、議論するメンバーなどを変化させながら、3つの異なるアプローチを比較検証しました。その結果、以下の知見を得ました（詳細は 考察 セクションを参照）。 議論メンバーの非対称性設計 : 楽観派と批判派のバランスが議論品質を左右する 細かいステップ分割 : 論点を細分化することで議論が効率化し、成果物精度が向上する プロンプトチューニングのPDCA : システムの価値は「仕組み」ではなく「プロンプト精度」にある 例えば、楽観的なCEO・CMOによる発散的なブレインストーミングと、批判的なCFOによる財務検証を別ステップに分離することで、アイディアの多様性と実現可能性を両立できました。また、議論をステップ単位で細分化することで、プロンプトの改善→結果確認→再改善という高速なPDCAが可能となり、成果物の精度が大きく向上しました。これらの知見の詳細は 考察 セクションで解説します。 ※本記事は、マルチエージェントシステムの技術検証を目的とした実験的な取り組みの報告です。記事内で紹介するアプリケーションおよび事業アイディアの内容（レシピサービス、クラフトビールコーチング、デジタル終活サービス、希少動植物飼育ガイドなど）は、全て検証用のサンプル出力であり、当社の正式なサービス提供、事業計画、または推奨を意味するものではありません。また、記載されている市場規模や売上計画などの数値は検証目的の仮想データです。 目次 はじめに 目次 背景：マルチエージェントとは 課題設定：スタートアップの新規事業立案 検証用アプリケーションについて アプリケーション要件 システム構成 アプリケーション環境 議論設定ファイル 論点定義 成果物定義 メンバー定義 ステップ定義 アプローチ別検証 アプローチ１：シングルステップ 議論トポロジー（１） 議論の結果（１） 議論の良い点（１） 議論の課題（１） アプローチ２：ステップ分割定義 議論トポロジー（２） 議論の結果（２） 議論の良い点（２） 議論の課題（２） アプローチ３：ステップ別詳細定義 議論の結果（３） 議論の良い点（３） 議論の課題（３） 考察 1. 議論の登場メンバーの非対称性設計 2. 議論の論点の細かい分割 3. システムの価値の所在が仕組みからプロンプトに移行 4. 議論およびアウトプットの品質を上げるPDCA 5. トップダウン的な議論分割とボトムアップ的な統合 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 今後の展望 1. ファシリテーターの導入 2. 議論トポロジーの多様化 3. エンドユーザー独自の制約定義 4. 議論の評価基準の設計 まとめ 背景：マルチエージェントとは マルチエージェントとは、複数のAIエージェントがそれぞれ役割を持ち、協調・分担・相互作用しながら問題を解決する仕組みのことです。 各エージェントは以下のような特性を持ちます。 自律性 ：人間の指示なしに判断・行動する 社会性 ：他のエージェントと通信・交渉する 反応性 ：環境の変化に応じて行動を変える 能動性 ：目的達成のために自発的に動く 例えばChatGPTのようなエージェントと対話形式を取るものは、シングルエージェントと呼ばれます。シングルエージェントの自己検証は内部的ですが、マルチエージェントは構造的に外部から反証・再評価を組み込める点が大きく異なります。 マルチエージェントやAIエージェントの時代背景、歴史的な発展については、「 世界は新たな時代を迎えようとしている 」もご参照ください。 課題設定：スタートアップの新規事業立案 多様な役割を持つエージェントによって構成されるマルチエージェントは、多様な観点を取り入れる必要がある複雑な問題と相性が良いと言われています。 また、シングルエージェントでは解決が難しい論理矛盾、ハルシネーション、認知バイアスに対しても、他の役割を担うエージェントのチェックが入ることで、構造的に議論の品質が向上することが見込めます。 本記事では、複雑な問題の具体例としてスタートアップの新規事業立案を考えたいと思います。 スタートアップというと、シードフェーズやアーリーフェーズからエンジェル投資家やベンチャーキャピタル投資家の投資を受け、バイアウトやIPOなどのイグジットを狙う企業というイメージが強いかもしれません。しかし本記事では、自由に経営陣が意思決定できる小規模かつ柔軟なチームと定義させていただきます（もちろん、この定義やゴールは設計次第で柔軟に変更可能です）。 スタートアップの新規事業構想のディスカッションに登場するメンバーは以下の通りです。 メンバー 役割 CEO チーム全体の議論を統合し、各メンバーの意見を踏まえて最終的な判断を下す役割を担う。 CMO 市場動向や顧客ニーズの視点からアイディアを提供したり、評価する役割を担う。 CFO 財務的な観点からアイディアの実現性と実現可能性を評価する役割を担う。 CTO 技術的な観点からアイディアの実現可能性を評価する役割を担う。 経営コンサルタント 経営メンバーが提示した事業アイディアに対して、意図的に反論・反証を行う役割を担う。 検証用アプリケーションについて 本記事では、マルチエージェントで議論を行う検証用アプリケーションを実装し、同じ論点においていくつかのアプローチによる結果を検証しました。ここでは、その要件、構成などを説明します。 アプリケーション要件 検証用の本アプリケーションは以下のシステム要件を備えています。 1. 議論の成果物のフォーマットを自由に定義できること 2. 議論の論点を自由に定義できること 3. 議論に登場するメンバーを自由に定義できること 4. 議論の進め方として複数のステップに分割することができ、それぞれ自由に定義できること 5. 各ステップの終了時には成果物の品質チェックを行うこと 6. 各ステップの成果物は次のステップに引き継げるようにすること 議論に登場するメンバーにはプロンプトを通じて、どのような役割を持つのか、どのような行動指針があるかを指示できます。また、必要に応じてGoogle検索などの外部ツール（Function Calling）を利用可能にできます。 各ステップの定義では、そのステップに参加するメンバーや発言順序を定義できます。ステップ独自の挙動についてはプロンプトで制御でき、ステップ内の発言回数を round として定義できます。 システム構成 本記事で実装したアプリケーションの構成図は以下の通りです。 図：本アプリケーションのシステム構成図（著者作成） 本アプリケーションのエンドユーザーは、事前に定義された議論設定ファイルの中から実行したい議論を選択します。 選択された議論設定ファイルの構成に応じて、本アプリケーションのコンポーネントが展開され、議論が開始されます。 各ステップ毎にラウンド数分の発言がメンバー内で繰り返され、結論と成果物を生成します。その成果物の品質チェックが行われ、問題がなければ次のステップに進みます。問題があれば議論は差し戻され、これまでの議論内容が引き継がれて再度議論が行われます。 最終的に全てのステップの議論が終了すると、全体の結論が生成され、議論レポートが Markdown形式で出力されます。 アプリケーション環境 ソフトウェア バージョン Python v3.12.11 google-adk v1.25.1 google-genai v1.64.0 LLMモデル gemini-2.5-flash google-adk （Agent Development Kit）は、AIエージェントの開発・デプロイのためのフレームワークです。マルチエージェントアーキテクチャやワークフローの構築を担います。一方、 google-genai は Gemini APIへのアクセスを提供するPython SDKで、LLMとの通信やFunction Callingの実行基盤として google-adk の内部で利用されています。 今回の検証では1回の議論で数十回のAPI呼び出しが発生します。そのため、レイテンシとコストを抑えつつ十分な推論品質を確保できる gemini-2.5-flash を選択しました。 gemini-2.5-pro と比較して応答速度が速く、API費用も低いため、試行錯誤を繰り返すPDCAサイクルに適していると判断しました。 議論設定ファイル 議論設定ファイルは YAML形式で記述され、以下のフォーマットとなっています。 id : 議論に紐づくユニークなID name : 議論の名称 description : 議論の説明文 topic : 議論の論点 output : 議論の成果物 members : 参加メンバー steps : 議論のステップ 以下、各項目の詳細について説明します。 論点定義 topic 項目により、議論の具体的な論点を定義することが出来ます。 topic : | * AIを活用した消費者向けのソリューションにおける具体的な事業アイディアを出してください。 * 最初に事業アイディアを10個程度出し、最終的に1~3個程度に絞ってください。 * **法人向けソリューションではないことに注意** * **抽象的な表現はNGです** 成果物定義 output 項目により、議論の具体的な成果物を指定することができます。ここで指定された成果物が、最終的に生成されるレポートに出力されます。 output : | 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 ... メンバー定義 members 項目で、議論に参加する具体的なメンバーを定義することが出来ます。 各メンバーの挙動は、 prompt で記述され、具体的にはそのメンバーの役割や行動指針を指定しました。 tools 項目で、事前に実装されている外部ツールをAIエージェントに渡すことができます。今回の検証では、議論中に好きなキーワードでGoogle検索を実行できる google_search() にアクセスできるようにしています。 members : - id : ceo name : "CEO" prompt : | あなたはスタートアップ企業のCEOです。 チーム全体の議論を統合し、各専門家の意見を踏まえて最終的な判断を下す役割を担います。 行動指針 : - 各メンバーの専門的な意見を尊重しつつ、全体最適の視点で意思決定を行う - 議論が発散した場合は論点を整理し、結論に導く - ビジョンと実現可能性のバランスを常に意識する tools : [ google_search ] ステップ定義 steps 項目にて、議論の具体的なステップを定義することが出来ます。 ステップでは、 members 項目 にて、該当ステップに参加するメンバーと発言順序を定義することが出来ます。 output 項目は、該当ステップの成果物を定義するもので、生成された成果物は次のステップの入力値として扱われます。 rounds は、そのステップの議論における発言回数を表します。指定された発言回数分の議論を重ねた後、成果物の品質が検証され、品質が不合格となった場合、 fallback で定めたステップに差し戻しとなります。 steps : - id : step1 name : "事業アイディアのブレインストーミング" members : [ ceo, cmo ] description : "楽観的に初期の事業アイディアをブレインストーミングする" output : | 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 ... prompt : | - CEOとCMOは、自由な発想でアイディアをたくさん出すことを優先し、批判は控えること（質よりも量を優先）。 rounds : 8 fallback : step1 アプローチ別検証 本記事では、以下の3つのアプローチを検証しました。各アプローチの概要と結果は以下の通りです。 指標 アプローチ1 アプローチ2 アプローチ3 方式 シングルステップ ステップ分割定義 ステップ別詳細定義 ステップ数 1 5 5（個別実行） 実行時間 14分01秒 36分39秒 42分35秒（合計） 出力アイディア数 1 4 3 成果物精度 中 中〜高 高 PDCA容易性 低 低 高 以下、各アプローチの詳細を説明します。 アプローチ１：シングルステップ 最初のアプローチでは、論点と成果物を詳細に定義し、ステップ分割を敢えてせずに全ての登場人物を同時に議論させました。すなわち、ブレインストーミングから売上・技術・マーケティング検証、反証検証まで全ての議題を1ステップに集約し、5名全員が参加する構成です。 論点は、議論設定ファイルにて以下のように定義しました。いくつか今回の検証における設定や制約において説明します。 事業アイディアの条件としてはAIを活用したものに限定し、法人向けのソリューションではなく、 消費者向けのソリューション としました。これは、消費者向けサービスと設定した方が初期のブレインストーミングで様々なアイディアが出ることが期待され、その多様さを結果に反映したいと考えたからです。 対象とする市場についてもニッチ市場に限定することで多様なアイディアが出るように設定しました。 一方で、売上計画についてはニッチ市場戦略である以上、大きなスケール成長ではなく、より堅実で緩やかな成長を想定しました。 論点・成果物の詳細定義（クリックで展開） # 議題 * AIを活用した消費者向けのソリューションにおける具体的な事業アイディアを出してください。 * 最初に事業アイディアを10個程度出し、最終的に1~3個程度に絞ってください。 * **法人向けソリューションではないことに注意** * **抽象的な表現はNGです** ## 初年度のPLについて * 各事業アイディアに対して、以下の２パターンの初年度のPL（収益決算書）を作成し、`output`のフォーマットに従って成果物を作成してください。 * 標準シナリオ * 悲観シナリオ * PLの構成としては以下のような形を想定していますが、必要に応じて適宜修正してください。 　``` 売上: 1200万円 変動費: 印刷原価: 5万円 × 24 = 120万円 API費: 年間30万円 固定費: エンジニア1人×3ヶ月: 150万円 代表営業50%稼働: 300万円換算 CMO 30%稼働: 200万円換算 その他: 50万円 営業利益: 　``` ## 技術的観点について * 既存の事業アイディア一覧に対して、CTOが中心となって技術面からレビューを行い、新たに技術視点の差別化戦略、技術要件、開発期間見積もり、技術的リスクを作成し、`output`のフォーマットに従って成果物を作成してください。 * 技術視点の差別化戦略：この事業アイディアを技術面でどのように差別化するかを記述してください（書き方、フォーマットについては後述） * 技術要件：この事業アイディアを実現するために必要な技術要件を具体的に記述してください。例）大規模言語モデルのAPI、リアルタイム音声認識技術、等 * 開発期間見積もり：この事業アイディアを実現するために必要な開発期間の見積もりを記述してください。例）6ヶ月、1年、等 * 技術的リスク：この事業アイディアに関連する技術的なリスクを記述してください。例）大規模言語モデルのAPIコストが高すぎる可能性、リアルタイム音声認識の精度が不十分な可能性、等 ## マーケティング観点について * 既存の事業アイディア一覧に対して、CMOが中心となってマーケティング観点からレビューを行い、完成度を高め、`output`のフォーマットに従って成果物を作成してください。 * 既存の事業アイディアの要素をレビューし、必要に応じて修正してください。特に以下の項目を重点的にレビューしてください。 * 想定する市場規模：現在の仮定の根拠を検証し、修正が必要であれば修正してください。 * 既存の要素にない、以下の要素を作成し、新たに要素として成果物に追加してください。 * マーケティング手法：売上計画、PL等を実現するための主要なマーケティング手法を具体的に最大３つ記述してください。 * マーケティング計画：各マーケティング手法毎にその計画を記述してください。例）1年目はSNS広告で認知獲得、2年目はインフルエンサーマーケティングでユーザー獲得、等 * マーケティング計画には、各施策の目的、ターゲット、実施内容、KPIを含めてください。 ## 反証検証 * 最後に、事業アイディアの最終的な検証を行い、`output`のフォーマットに従って成果物を作成してください。 * 主要リスク：この事業アイディアに関連する主要なリスクを記述してください。例）市場の反応が冷淡であるリスク、技術的な実現が困難であるリスク、等 * 反論とそれに対する対策：経営コンサルタントが提示した反論に対して、それを克服するための対策を記述してください。例）市場の反応が冷淡であるリスクに対する対策として、初期ユーザーからのフィードバックを迅速に取り入れてサービス改善を行う、等 * 最終的な推奨アイディアの順位付け：CEOが中心となって、最終的に推奨する事業アイディアの順位付けを行い、その理由も含めて記述してください。例）事業アイディア1は市場のニーズが高く、技術的にも実現可能であるため最も推奨される、等 # 制約 ## 市場に関する制約 * 対象マーケットについて * ニッチ市場のみを対象とする。**決して、大衆を狙った市場をターゲットにしないこと**。 * 大衆に向けた汎用性の高いプロダクト・パッケージ販売はさけてください。 * 資本力が弱いため、マスプロダクトを開発して、ユーザーの囲い込みを行う資本力勝負の戦い方は不利です。 * ターゲット顧客のニーズをしっかりと捉え、少人数でも顧客のエンゲージメントを高めることを優先し、徐々に拡大する戦略で進めたいです。 * ターゲット顧客について * ターゲット顧客は、個人であれ法人であれ、**最終消費者であること**が必須です。 * 法人向けのソリューションは、顧客が少なく、1社あたりの売上が大きくなりがちですが、顧客獲得の難易度が高く、営業リソースも限られているため、現時点では避けるべきです。 * 顧客課題について * 顧客課題は、**顧客が日常的に感じているものであること**が重要です。 * 顧客が感じていない課題を無理やり作り出すのは避けてください。顧客のニーズをしっかりと捉えることが重要です。 * 顧客課題は、**解決されていないものであること**が重要です。既に多くの競合が解決している課題は避けてください（それではニッチ市場戦略を取っている意味がありません）。 * 市場規模(TAM)について * 市場規模は、**ニッチ市場であっても、十分な売上が見込めるものであること**が重要です。 * 例えば、数千人程度の顧客がいて、1人あたり年間1万円程度の売上が見込める市場であれば、十分に魅力的な市場と言えます。 * TAMの算出は、トップダウンでもボトムアップでもどちらでも構いませんが、CMOを中心として、前提を明確にして、合理的な根拠に基づいて算出してください。 ## 提供するソリューションに関する制約 * ソリューションは、**AIを活用したものであること**が必須です。 * ソリューションは、**ターゲット顧客の課題を解決するものであること**が重要です。顧客のニーズをしっかりと捉え、顧客が求める価値を提供することが重要です。 ## 競合に関する制約 * 既存の競合サービスの調査は、CMOが中心に行ってください。Google検索ツールを活用して、類似のサービスがないかを調査してください。 * 既存の競合サービスは、**同じ顧客課題を解決するものであること**が重要です。異なる課題を解決するサービスは競合とは言えません。 * 競合サービスが存在する場合は、その競合サービスに関する主要なURLを１つ調べ、さらに強みと弱みを分析し、自社ではどのように差別化するべきかを考えてください。 * 競合サービスが複数ある場合、最大３つの競合サービスを調査してください（強力なサービス順）。 ## 売上計画に関する制約 * 売上計画では以下の点を考慮してください。ただし、売上計画の数値が出せない場合は、仮置きして、前提を明示してください。 * 年間単価 * 必要ユーザー数 * 初年度のPL * 年度別の売上として、以下のラインは見込めること。 * 初年度：ゼロを許容 * 1年目：1000万円/年 * 3年目：3000万円/年 * 5年目：1億円/年 ## 自社に関する制約 * 会社のリソースについて * 会社にはエンジニアのバックグラウンドを持つ人間が数名おり、営業やマーケティングのリソースは少ない。 * 営業活動は代表が自ら行う。 成果物は以下のように定義しました。 事業アイディアのリスト。事業アイディアは以下の要素を含む。 - アイディアの概要：例) AIを活用したオンライン学習プラットフォーム - ターゲット顧客：例) 中高生とその保護者 - 想定する顧客課題：例) 学習の個別最適化が難しい、モチベーションの維持が困難 - 想定する市場規模：例) 100億円 - 提供するソリューション概要：例) AIが生徒の理解度や興味に合わせて最適な学習コンテンツを提供し、ゲーム要素でモチベーションを維持するオンラインプラットフォーム - 既存の競合サービス：例) 学習塾、予備校、等 - この先５年間の売上計画：例) 1年目: 1000万円、2年目: 5000万円、3年目: 2億円、4年目: 10億円、5年目: 50億円 - 初年度PL（標準シナリオ）：CFOを中心に作成 - 初年度PL（悲観シナリオ）：CFOを中心に作成 - ２年目以降の資金調達計画：例) 2年目にエンジェル投資家から500万円、銀行からの融資で500万円、3年目にVCから1億円、等 - 技術視点の差別化戦略：CTOを中心に議論をして作成 - 技術要件：CTOを中心に作成 - 開発期間見積もり：CTOを中心に作成 - 技術的リスク：CTOを中心に作成 - マーケティング手法：CMOを中心に議論して作成 - マーケティング計画：CMOを中心に議論して作成 - 主要リスク：経営コンサルタントを中心に議論して作成 - 反論とそれに対する対策：経営コンサルタントを中心に議論して作成 - 最終的な推奨アイディアの順位付け：CEOを中心に議論して作成 ステップの定義では、上記の論点と成果物を１ステップで全登場人物に議論させています。 これらの詳細な設定ファイルを参照したい方はこちらを参照ください → startup_v1.yaml 議論トポロジー（１） 上記の通り、アプローチ１のステップは１つしか定義していませんが、その登場人物間の発言のトポロジーを可視化すると以下のようになります。 CEOから発言を開始し、全ての登場人物が順に発言をし、ラウンド数分の発言が行われた時点でこのステップの議論が終了となります。 図：アプローチ１の議論トポロジー（著者作成） 議論の結果（１） 上記の設定で議論させたところ、所要時間14分1秒の議論が行われ、「AIを活用した特定の食事制限・手持ち食材向けレシピ生成サービス」というアイディアが最有力となりました。 このサービスは、「複数の食物アレルギーを持つお子さんを持つ親御さん、特定の疾患（例：腎臓病、糖尿病）により厳格な食事療法が必要な個人」が、複雑な食事制限下での献立考案が困難であることや、手持ち食材でのレシピ探しが難しい、食事のマンネリ化すること、等を課題と捉え、個人の食事制限、リアルタイムの手持ち食材、嗜好をAIが分析し、パーソナライズされたレシピを提案する、とのことです。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください → startup_v1_20260228_235325.md 議論の良い点（１） 比較的、成果物を細かく規定し、論点においても様々な制約を細かに記述したため、それなりに期待するアウトプットには到達しています。 例えば、成果物では以下の点を詳細に規定している。 初年度のPLのフォーマット 技術的観点の成果の要素 マーケティング観点の成果の要素 反証検証の方法 また、制約についても以下の点を詳細に規定している。 市場に関する制約：特にニッチ市場の特化 ターゲット顧客の制約 顧客課題の制約 提供するソリューションの制約 競合に関する制約 売上計画に関する制約 自社に関する制約：主にリソースや得意領域の記述 議論の課題（１） 主に以下の点が課題点として考えられます。 1. 複数のアイディアが出たが、１つ目のアイディアの深堀りに議論が集中したこと 2. 個人が自身の役割だけを主張し議論が停滞してしまったこと 3. 成果物の精度が低さ（市場規模、顧客獲得モデル、MVP定義） １つ目の課題は、最初にブレインストーミングの発散型ステップを設け、その後のステップで評価/選定といった収束型ステップを設けることで解決されることが期待されます。 初期のアイディア出しのフェーズで、すぐにCFOの売上検証という批判的な議論が開始してしまったことで、議論が収束してしまいました。２つ目の課題は、各ステップにおいて、推進派と保守派の良いバランスで適任者を選定することで解消されそうです。 ３つ目の課題については、議論が効率的に進まなかったことにより、これらの論点で十分な時間が割かれなかったことが原因です。これも適切なステップ分割と効率的な議論で改善しそうです。 それでは、複数のステップに分割して、再度検証してみます。 アプローチ２：ステップ分割定義 本アプローチでは、新規事業構想の議論を複数のステップに分割し、かつ、各ステップに参加する人物を調整しながら議論の精度向上を試みます。 議論の論点はアプローチ１と同じにしました。 ステップは以下の流れとなるようにし、各ステップの参加メンバーも限定するように設定ファイルに記述しました。 ステップ 参加メンバー（発言順） 概要 1. 事業アイディアのブレインストーミング CEO、CMO 初期の事業アイディア出し 2. 売上検証 CFO、CEO、CMO 各事業アイディアの売上計画、PLの修正と検証 3. 技術検証 CTO、CEO、CMO、CFO 各事業アイディアの技術的検証と追記 4. マーケティング検証 CMO、CEO、CTO、CFO 各事業アイディアのマーケティング的検証と追記 5. 反証検証 経営コンサルタント、CEO、CMO、CTO、CFO 全ての仮説に対する反証に耐えうるか検証 これらの詳細な設定ファイルを参照したい方はこちらを参照ください → startup_v2.yaml 議論トポロジー（２） アプローチ２は複数のステップにより構成され、その登場人物間の発言のトポロジーを可視化すると以下のようになります。 図：アプローチ２の議論トポロジー（著者作成） 議論の結果（２） マルチステップでマルチエージェントに議論させたところ、所要時間36分39秒の議論が行われ、「AIクラフトビール自家醸造パーソナルコーチング」というアイディアが最有力となりました。 このサービスは、「クラフトビール自家醸造の上級者・中級者」が求めるような「微細な味覚プロファイルの深層学習」や「個人の深いこだわりに基づいたパーソナルコーチング」が不足しているという課題に対して、ユーザーの入力データ（既存ビール評価、自由記述、醸造結果）からパターンを抽出し、「あなたのこの好みの背景には、このような味覚の傾向がある」といった洞察を提供し、「ユーザーの味覚探求を深めるための強力な補助線」となる役割を果たす、とのことです。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください → startup_v2_20260301_003355.md 議論の良い点（２） 主に以下の点が良い点として考えられます。 事業アイディアをすぐ１つに絞らず、最後まで4案が評価対象として残っていること 議論のステップが明確に構造化されていること 品質チェック機構が機能していること 成果物の一部精度向上（MVPの具体化） アプローチ１の課題の多くが、ステップ分割をより細かく定義し、参加メンバーを調整することで改善されていることが確認できました。 また、細かくステップが分割されていることにより、品質チェックもより評価しやすくなり、議論の差し戻しが発生しやすくなり、議論の精度が向上したことが伺えます。 結果的に議論が効率化され、成果物の各項目において議論する時間が増えたことでアプローチ１よりも精度が向上していることが伺えました。 議論の課題（２） 主に以下の点が課題として挙げられます。 成果物として一部のデータに欠損が生まれていること 市場規模（TAM）の前提がブレている点 TAMと売上計画の整合性不足 成長メカニズムが未設計 全てのステップを連結させて一気に結論を出そうとしているために、全ての議論が終了するのに40分弱の時間がかかってしまいました。これでは、フィードバックを得るまでに時間も、フィードバック対象の粒度も粗い状況となってしまいます。 アプローチ１の課題は大きく改善されましたが、ここで挙げた課題を一つ一つ解決していくには、もう少し細かい粒度の議論で、フィードバックを受けながら、プロンプトを試行錯誤しながら微調整する必要性を認識しました。 それでは、各ステップ別に議論を終了し、短いスパンでフィードバックを得ながら、プロンプトや設定を修正してきたいと思います。 アプローチ３：ステップ別詳細定義 アプローチ２でもステップ分割を行いましたが、各ステップの粒度でプロンプトのチューニングを行いたくなったため、各ステップを議論として定義し、議論にはステップを１つしか含まない構成へと変更しました。 このような変更をすることで、議論のフィードバックを短時間で得られ、議論のインプット担っていた設定（プロンプト）を微調整しながら、アウトプットの精度を変化させる高速なPDCAが可能となります。 各議論のプロンプトはベースはアプローチ２と同じですが、生成される成果物を確認しながら、プロンプトを調整しました。また、登場人物、トポロジーに関してはアプローチ２と同じにしています。 これらの詳細な設定ファイルを参照したい方はこちらを参照ください。 startup_v3.1_brain-storming.yaml startup_v3.2_financial-review.yaml startup_v3.3_technical-review.yaml startup_v3.4_marketing-review.yaml startup_v3.5_verification.yaml 議論の結果（３） 議論にかかった時間は以下の通りです。 ステップ名 所要時間 1. 事業アイディアのブレインストーミング 4分25秒 2. 売上観点での検証 8分47秒 3. 技術観点での検証 8分18秒 4. マーケティング観点での検証 4分16秒 5. 全体プランへの反証検証 16分49秒 複数の議論を重ねたところ、最終的には以下の３つの事業アイディアが有力なものとなりました。 ニッチ書籍特化型AI読書支援サービス - 特定ジャンルの読書家向けに、AIレコメンド・読書アシスタント・理解度分析を提供 AIデジタル終活支援サービス - デジタル資産の整理・管理・家族への引き継ぎをAIで支援 希少動植物AI飼育・栽培ガイド - 希少種の画像識別・パーソナル飼育ガイド・病害虫診断を提供 各事業アイディアの詳細（クリックで展開） １つ目のサービスは、「特定のニッチな書籍ジャンルに深く没頭したい読書家」が自分に真に合った、質の高いニッチな本が見つけにくいことや、難解な本で挫折しやすく、専門的な解説や背景知識の助けが欲しいこと、などを課題と捉え、以下のソリューションを提供します。 AIレコメンドエンジン ：読書履歴、感想、学習目標に基づき、ニッチな書籍を高精度で推薦。 AIチャットアシスタント ：読書中に専門用語の解説、背景知識提供、著者思想の深掘り、読書内容に関する議論をサポート。 AI読書進捗・理解度分析 ：読書速度や理解度をAIが分析し、最適な読書ペースやアプローチを提案。 ２つ目のサービスは、「50代以上のデジタルサービス利用経験が豊富で、自身のデジタル資産の行方や、家族に負担をかけたくないという意識を持つ層」が、死後のデジタルデータ（アカウント、写真、契約情報など）の整理方法が分からないことや、家族にパスワードや重要な情報を伝えることへの心理的抵抗やセキュリティ上の懸念、などを課題と捉え、以下のソリューションを提供します。 AIアカウントスキャン＆提案 ：連携したメールやブラウザ履歴から利用中のデジタルサービスをAIが特定し、利用状況に応じて整理（継続、削除、引き継ぎ）を提案。 安全なデジタル遺産管理 ：暗号化されたクラウド上でパスワードや重要情報を一元管理。生前の意思に基づき、指定した時期や条件で家族に情報開示する仕組み。 AIチャットアシスタント ：デジタル終活に関する疑問、法的な相談（提携専門家への繋ぎ込み）、データのバックアップ方法などをAIがサポート。 エンディングノート連携 ：デジタル資産だけでなく、生前の想いやメッセージを記録する機能。 ３つ目のサービスは、「市販の一般的な情報では物足りず、特定の希少種や専門性の高い動植物に深い愛情と知識欲を持つ個人」をターゲットとしています。 この層は、希少種の正確な識別が難しいことや、専門情報が書籍や特定のコミュニティに限定されアクセスしにくいこと、病気や異常発生時の原因特定と対処法が分からないこと、といった課題を抱えています。以下のソリューションでこれらの課題を解決します。 高精度AI画像識別 ：ユーザーがアップロードした写真から希少な動植物の種を高精度で識別。 パーソナル飼育/栽培ガイド ：識別された種に基づいて、温度、湿度、栄養、光量、水質など、個体や環境に合わせた最適な飼育/栽培プロトコルをAIが提案。 AI病害虫診断＆対策 ：画像認識で病害虫の兆候を早期に発見し、具体的な対策方法をアドバイス。 AIチャットQ&A ：飼育・栽培に関するあらゆる質問にAIがリアルタイムで回答。 実際に生成された議論レポートは長文となるためここでは割愛しますが、参照したい方はこちらを参照ください 。 startup_v3.1_brain-storming_20260228_195019.md startup_v3.2_financial-review_20260228_204333.md startup_v3.3_technical-review_20260228_215418.md startup_v3.4_marketing-review_20260228_223255.md startup_v3.5_verification_20260228_232437.md 議論の良い点（３） 主に以下の点が良い点として考えられます。 議論を分割して細かく区切ることで、PDCAを回すことで成果物の精度を上げることができること 差別化戦略の論点が具体化している点 技術的リスクが明確に列挙されている点 MVP設計が現実的になっている点 成果物のフォーマットの安定と精度向上 アプローチ２のプロンプトをベースにしましたが、そこから何度もプロンプトを調整しました。 成果物が得られた上で、過不足があればプロンプトを調整して何度も議論をさせることにより、差別化戦略の論点の明記、技術的リスクの論点の明記、MVP設計の論点の明記など、事細かにプロンプトに記述することでアウトプットの品質が向上したことが分かります。 議論の課題（３） ただし、まだ以下の点が課題として挙げられます。 売上計画のリアリティ検証が弱い点 TAMの精度が依然として粗い点 データ取得戦略が未設定である点 法的・倫理的リスクが高い点 ここで挙げられた課題は全てプロンプトを修正することで潰せる点ばかりです。アプローチ３のように議論を細分化するほど、論点や制約はシャープになるため、さらに試行錯誤しながらプロンプトを改善することで、より満足のいく成果物の精度を期待することが出来るでしょう。 考察 これまで、以下の順でいくつかのアプローチを検証し、マルチエージェントシステムのそのインプットとアウトプットを見てきました。 アプローチ１：単純なワンステップでの議論 アプローチ２：複数ステップに分割した一気通貫の議論 アプローチ３：複数ステップ毎に試行錯誤しながらの議論 これらの検証から個人的に得られた考察は以下の６点に集約されます。 1. 議論の登場メンバーの非対称性設計 2. 議論の論点の細かい分割 3. システムの価値の所在が仕組みからプロンプトに移行 4. 議論およびアウトプットの品質を上げるPDCA 5. トップダウン的な議論分割とボトムアップ的な統合 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 1. 議論の登場メンバーの非対称性設計 議論に登場するメンバーの特性には非対称性を持たせることが重要と考えられます。 今回の議論では、役割が異なるCEO、CMO、CFO、CTO、経営コンサルタントを定義しました。 これらのメンバーには、それぞれの役割や行動指針が定義できますが、あえてその方向性や価値基準に多様性を持たせることで、お互いの視点の衝突やバイアス相殺を促すようにしました。実際にCEOやCMOは楽観的なアイディアマンとして定義してましたが、物事を定量的に批判的に捉えるCFOからは、詰めの甘いプランに厳しいフィードバックがかかり、売上計画の精度を向上する議論が見られました。 2. 議論の論点の細かい分割 今回の議論では、いきなり事業アイディアを成果物としてアウトプットするのではなく、以下のステップへと分割しました。 1. 事業アイディアのブレインストーミング 2. 売上観点での検証 3. 技術観点での検証 4. マーケティング観点での検証 5. 全体プランへの反証検証 議論を細かい粒度に分割することで議論が効率的に進み、結果としてアウトプットの精度が向上する様子が見られました。 また、各議論ではあえて参加させるメンバーを限定させることで、不必要な意見の衝突を減らし、そのステップでの議論を加速させるなどの調整も大切だと思います。例えば、ブレインストーミングのような発散フェーズでは楽観派のCEOとCMOに限定することで、多くのアイディアが生まれる様子が観測できました。 3. システムの価値の所在が仕組みからプロンプトに移行 今回の記事を作成する際、実装時間の10倍程度は、プロンプトの検証と精度向上の時間に費やしたと思います。 今回の検証を通じて感じたのは、システムという仕組み自体にはさほどの価値はなく、プロンプトの精度を高めることが重要だと言うことです。 システム自体を、十分に柔軟な設計にしておいた上で、システムを仮説検証用の実験マシンと位置づけ、インプットとアウトプットの試行錯誤を繰り返すことで、そのプロンプトを高めていくことが重要です。 今回のテーマにおける柔軟性とは、論点定義、メンバー定義、ステップ定義などを自由に調整できる手段を提供するということを意味します。 以下に、実際にプロンプトを改善した具体例を2つ紹介します。 改善例1：技術的差別化戦略の論点を構造化 アプローチ2では、技術検証ステップのプロンプトで差別化戦略の指示が抽象的でした。 # 改善前（アプローチ2） 技術視点の差別化戦略：この事業アイディアを技術面でどのように差別化するかを記述してください この指示では、AIが「独自のAIモデルを構築する」のような一般的な記述に留まる傾向がありました。そこで、差別化戦略を4つの具体的な観点に分割しました。 # 改善後（アプローチ3） 技術視点の差別化戦略は、以下の観点について具体的に議論して作成してください。 * 採用する技術自体の差別化：他社が真似しづらい技術を採用することで差別化を図る戦略 * 顧客データ蓄積による差別化：顧客データが蓄積されることで、他社が真似しづらいサービスになるような戦略 * 競合サービスへのスイッチングコスト設計：スイッチングコストが高くなるようなサービス設計 * ネットワーク効果の設計：ネットワーク効果が働くようなサービス設計 この改善により、各事業アイディアに対して「データ蓄積によるレコメンド精度の向上」「ユーザーの履歴・設定データによるスイッチングコストの構築」など、観点ごとに具体的な差別化戦略が生成されるようになりました。 改善例2：事業の持続可能性に関する制約を追加 アプローチ2のブレインストーミングでは、市場やソリューションに関する基本的な制約のみを記述していました。しかし、生成された事業アイディアを確認すると、初期顧客の獲得方法や長期的な競争優位性が曖昧なまま議論が進んでいました。そこで、アプローチ3では以下の制約を追加しました。 # 改善後（アプローチ3で追加した制約） * 広告ゼロで最初の50人を獲得する具体的な経路を設計してください（以下の点を明示） * コミュニティ名、接触方法、提供する最初の価値、想定CVR * この事業を3年間続けると仮定した時、創業者が疲弊しない構造か検証してください * クレーム頻度、責任リスク、サポート負荷 * この事業が5年後に模倣された場合、価格競争に陥らない非価格競争優位性を定義してください * 独自データ、ネットワーク効果、コミュニティロックイン、スイッチングコスト この改善により、ブレインストーミングの段階から「ニッチコミュニティでの口コミ経由で初期50人を獲得」「データ蓄積によるスイッチングコスト構築」など、実行可能性の高い事業計画が生成されるようになりました。 4. 議論およびアウトプットの品質を上げるPDCA 最初から完璧なプロンプトを定義し、完璧なアウトプットを得ることは非常に困難でしょう。 最初のプロンプトは初期仮説に過ぎず、進化させるものという意識が大切だと思います。プロンプトから得たアウトプットというフィードバックに対して、人間側が持つ期待値との違和感から、これまで言語化出来ていなかった概念や制約を発見することができ、インプットとなるプロンプトを改善することが出来ます。 最初から"正解"となるステップ定義、トポロジー定義、プロンプトありきで、硬直的にシステムを構築するべきではないと思います。全ての要素を変更可能な要素として柔軟な設計にしておき、PDCAを回すことで精度を上げる工程が大切だと思います。 5. トップダウン的な議論分割とボトムアップ的な統合 マルチエージェントの仕組みをシステムに組み込む場合、トップダウン的な議論のステップ分割をし、各小規模の議論のチューニングをした上で、ボトムアップ的に各ステップを統合するアプローチが良いと思われます。 論点の粒度が荒すぎると十分な精度の成果が得られないでしょう。 大きな議論は小さな議論へと分割し、各論点がシャープになったところで、試行錯誤をした上でプロンプトとアウトプットの精度を高め、小さな議論を統合することで、結果として大きな議論のアウトプットの精度を高めることが出来ます。 6. エンドユーザーや顧客のニーズに合わせたDIY的システムというパラダイム 個人的には、マルチエージェントシステムは、そのエンドユーザーや顧客の状況やニーズに合わせたDIY的なシステムを構築するイメージに近い感覚があります。 これまでの大手システムベンダーが提供するパッケージやSaaSは、提供者が規定する仕様にユーザーが合わせるのが一般的でした。しかし、マルチエージェントをはじめ、AIを活用したシステムでは、プロンプトでエンドユーザーや顧客のコンテキストを詳細に入力することで、十分にカスタマイズされた仕様のシステムを構築することが出来ます。 今後の展望 様々な考察が得られた今回の検証ですが、以下のやり残したことや課題がいくつかあります。 1. ファシリテーターの導入 2. 議論トポロジーの多様化 3. エンドユーザー独自の制約定義 4. 議論の評価基準の設計 1. ファシリテーターの導入 今回定義した議論の登場人物とは別に以下の役割を担うファシリテーターを導入する方が議論の正確さや効率が向上すると思われました。 結論の生成 成果物の生成 関連性の高い人物への発言指定 議論や成果物の品質チェック 現在は、事前に定義した順番に各人物が発言するラウンドロビン型となっていましたが、これでは前後関係の関連性が低く、ラウンド数を無駄に消費する可能性が高いです。ファシリテーターが前後のコンテキストから、関連性の高い人物を指名することでより議論が前進することが期待できます。 2. 議論トポロジーの多様化 議論トポロジーとは、発言や情報の流れの構造を指し、上記の通り今回の議論トポロジーは単純なラウンドロビン型でした。 議論トポロジーとしては、以下のようなものが考えられ、議論に合ったトポロジーを選択することで議論や成果物の精度が向上することが期待されます。 トポロジー名 概要 出力傾向 ファシリテーター中心型（ハブ型） 各エージェントは直接議論せず、全てファシリテーターを経由する。 発散的・創造的 並列独立型（ブラインド並列） 各エージェントは同時に独立して回答し、最後に統合する。 多様性重視 クロスレビュー型（相互批判） エージェントAが仮説を出し、エージェントBが専門的視点から批評し、エージェントCが改善し、エージェントDが最終的に統合する、ような構造。 精度重視 ステップ分割をした際、各ステップ粒度で議論トポロジーを選択できるようにすれば、より議論の内容がシャープになるかもしれません。 3. エンドユーザー独自の制約定義 本当に実行する事業アイディアを考える場合、自分や組織固有の情報を事前にインプットする必要があると思います。 ここでは自分以外の人に見てもらうための記事ということで、プロンプトには一般的なことしか規定していません。そのため、誰にでも当てはまりそうな当たり障りない結論になっていると思います。 実際に自分事としてアイディア出しをする場合は、以下のような固有の情報を多くインプットする方がフィットするアイディアが出やすいでしょう。 大切にしているミッション 大切にする価値観 固有の詳細な事業選定ルール 固有のリソース制約条件 固有の投資戦略ルール 固有の事業撤退ルール ただし、価値観の認知バイアスを敢えて持たせない、という選択もあると思うので、その辺は目的に応じて使い分けるのが良いかと思います。 4. 議論の評価基準の設計 今回は、アウトプットの精度判定として、人間が見て納得感があるかと言った、感覚的かつ定性的なものに偏ってしまっていました。これは、アウトプットがアイディアのリストや、議論のプロセスが記載された議論レポートであったため、その精度を定量化するのが困難であったことが要因かと思われます。 このプロセス自体は、人間側が暗黙知を具現化するプロセスとして貴重だと思います。 ただ、定量的な評価が出来なければ、より明確な判断基準が定義することが出来ますし、アイディア出しから、高精度のアイディア絞り込み、を一気通貫で自動化することも可能になりそうです。 まとめ 今回は、新規事業構想という具体的なユースケースに基づき、マルチエージェントの活用法について検証しました。 もちろん、今回設定した議論トポロジーやステップ分割が最善とは言えないと思いますが、ステップ分割の仕方やプロンプト内容を変化させることで、大きくアウトプットの品質が変わることを確認することが出来ました。 検証プロセスの中で、議論を最小単位にすることで素早くフィードバックを得ることで、プロンプトの精度を向上させるPDCAのサイクルが重要であることを体感できたことは大きな収穫だと思います。 今回の議論は、新規事業選定という意思決定に限定されたものでしたが、このことはその他の議論にも当てはまることだと考えられます。 システムを提供する側としては、サービスの品質を向上するためにも、プロンプトとアウトプットのフィードバックシステムをエンドユーザーや顧客に提供することで、豊富なドメイン知識を持つ彼らにプロンプトの精度向上に積極的に参加してもらう、という設計を組み込む必要があるようにも感じます。 まだまだ奥が深いマルチエージェントの活用法ですが、本記事が具体的なイメージを持つきっかけになれば幸いです。

はじめに こんにちは。Insight Edgeでデータサイエンティストをしている善之です。 「研修で基礎は学んだけど、次は何を学べばいいんだろう…」 「話題の新しいライブラリが次々と出てくるけど、どれを学ぶべきかわからない」 こんな悩みを抱えていませんか？ 先日、 新人エンジニア・データサイエンティスト に向けた研修の一環として、 最新技術をどうやってキャッチアップし続けるか というテーマでレクチャーを行いました。 本記事では、その研修内容のエッセンスをご紹介します。 本記事は新人の方本人だけでなく、 後輩育成を担当されているリーダー層の方にとっても 、学習方法を体系的に伝えるフレームワークとして活用いただけると思います。 目次 研修実施の背景：基礎学習の「次」に進むために 1. なぜ技術を自分で学び続ける必要があるのか 2. 最新情報のキャッチアップ方法 3. 情報収集のTips：流行に飛びつきすぎない 4. 学ぶ技術が決まったら？（具体的な学習フロー） 5. 学習時の生成AI活用Tips まとめ 研修実施の背景：基礎学習の「次」に進むために この研修の受講対象者は、データ分析の基礎カリキュラムに取り組み、業務に必要な基礎知識の座学を一通り終えたところでした。しかし、この業界において「研修で習ったこと」はあくまでスタートラインに過ぎません。 特にデータやAIの領域は、数ヶ月単位で常識が変わる世界です。 どんなに優れたカリキュラムでも、技術の進化スピードには追いつけず、教科書になった時点で情報は古くなっていきます。 だからこそ、基礎を終えた受講者に次にレクチャーすべき内容は、特定の技術知識ではなく、 未知の技術を自分自身の力で学び続けるスキル だと考えました。 本記事では、その研修で使用したスライドをベースに、私が普段実践している「情報の集め方」や「生成AIを活用した独学フロー」をご紹介します。 1. なぜ技術を自分で学び続ける必要があるのか 研修の冒頭で、私は「脱皮できない蛇は滅びる」というニーチェの言葉を引用しました。 技術者は特に、常に自分のスキルをアップデートしていかないと、生き残っていけないというメッセージです。 技術の進化と恩恵 ここ10年を振り返るだけでも、開発環境は激変しています。 AIモデル: RandomForestからXGBoost・LightGBM、そしてDeep Learningへ。さらに近年はLLM（ChatGPTなど）へとトレンドは移行。 ライブラリ: pandasの高速な代替ライブラリである Polars や、LLM開発に広く使われている LangChain などの登場。 インフラ: Docker、マイクロサービス、AWS Lambdaなどのサーバーレス技術の定着。 「会社が教えてくれる」のを待っていては遅い これらは、誰かが噛み砕いて社内研修にしてくれるのを待っていては、実務で使えるタイミングを逃してしまいます。 「整った研修」を待つリスク: 会社が新しいカリキュラムを作り、教育コンテンツが整備されるのを待っていては、その技術の旬を逃してしまいます。また、古いツールを使い続けることは、最新技術がもたらす「性能向上」や「実装の効率化」という恩恵を享受できないリスクになります。 自走の必要性: そこで、「会社が次の研修を用意してくれる」のを待つのではなく、自分から書籍や公式ドキュメントといった一次情報を取りに行く姿勢が不可欠なのです。 2. 最新情報のキャッチアップ方法 とはいえ、何を学べば良いのかは自分で考えて決めなければなりません。 そこで、「次に何を学ぶべきか」というターゲットを見つけるために、私が活用している情報ソースを紹介します。 ① 生成AI（ChatGPT / Geminiなど） まず概要を掴むのに最適です。「今の時系列予測モデルのトレンドは？」と聞けば、候補をリストアップしてくれます。 ただし、 これだけに頼るのは危険 です。情報の鮮度や利用者の評価が含まれていないことがあるからです。 また、そもそも生成AIは「聞かれないこと」には答えてくれません。「〇〇という技術について教えて」とAIに深掘りさせるためには、まずその「〇〇」という新しい概念やトレンドを、自分自身が知っている必要があります。 そのため、 AIへのインプットとなる「種」を見つけるため に、以下の情報ソースも併用することが不可欠です。 ② Xで技術者やテックカンパニーをフォローする 情報の速さとトレンド感を知るにはXが良いです。AIがリストアップした技術が、現場のエンジニアにどう受け止められているかという肌感覚を得たり、AIに投げるための「検索の種」を拾うのに最適です。 ③ メルマガ・ニュースサイト 受動的に質の高い情報を得るにはメルマガが便利です。 Qiitaニュース: 「先週いいねが多かった投稿ベスト20」などが掲載されており、トレンドを把握できます Deep Learning Weekly / THE BATCH: 海外のAIトレンドがまとめられており、概要を把握できます ④ テックブログ・イベント テックブログ: QiitaやZennなどで、実際に試した人の記事を読むことで「実装の泥臭い部分」を知れます イベント: AWS Summitや勉強会など、オフラインの場ではネットに出てこない一次情報が得られるメリットがあります ⑤ 書籍 体系的な知識を得るには、やはり書籍が一番です。Amazonのランキングや書店の技術書コーナーを定期的に巡回し、トレンドを肌で感じるのがおすすめです。 3. 情報収集のTips：流行に飛びつきすぎない 情報は集めるだけでなく、取捨選択も重要です。AIが推薦してきたり、SNSで話題になっていても、すぐに飛びつくのが正解とは限りません。 GitHub Star Historyを活用する: 新しすぎる技術はノウハウがネットになく、苦労する割にすぐ廃れるリスクがあります。GitHubスター数の推移を可視化するツールである Star History などで相対的な普及度を確認し、ある程度コミュニティが育っているか確認するのが安全です。 インプット：アウトプット ＝ 3：7: 得た知識は使わないと定着しません。社内チャットへの投稿や、輪読会での発表など、アウトプットを意識することで、チーム全体の技術力底上げにもつながります。 4. 学ぶ技術が決まったら？（具体的な学習フロー） ターゲットが決まった後のアクションプランです。「書籍がある場合」と「ない場合」でアプローチを変えます。 ケースA：その技術に関する「書籍がある」場合 書籍は情報がうまくまとまっているケースが多く、まずはこれを活用するのがおすすめです。 書籍で体系的に学ぶ: まずは全体像を掴みます。 手を動かす: 書籍を片手に自分でコードを書きます。 疑問点を生成AIに聞く: エラーや不明点はChatGPT等に投げます。 公式ドキュメント/ソースを読む: 生成AIでも解決しない深い部分は、一次情報に当たります。 ケースB：その技術に関する「書籍がない」場合 最新技術やニッチなライブラリなどはこのパターンです。 生成AIへの質問やWeb検索で概要を把握: まずは生成AIに「〇〇とは何か、何ができるのか」を聞いて概要を掴みます。併せてテックブログなども検索し、実装イメージを補強します。 公式チュートリアルを触る: 公式ドキュメントにある「Getting Started」を自分で動かします。 生成AIに聞く: ここでも生成AIが壁打ち相手として優秀です。 ソースコードを読む: 生成AIを使ってもわからない場合、実際に原典にあたるのがベストです。 5. 学習時の生成AI活用Tips 独学の強力なパートナーとなる生成AIへの「聞き方」についても、基礎編・応用編として共有しました。「何を学ぶか」を決めるのは自分自身ですが、決めた後の「学習効率」を上げるのはAIの得意領域です。 【基礎編】学習のつまづきを解消する 用語や概念を質問する 例： Pythonのcached_propertyについて教えてください 知らない単語は即座に聞いて解決します。 エラーメッセージをそのまま投げる 例： （エラーログと設定ファイルを貼り付けて） 解決策を教えてください 原因の切り分けにかかる時間を大幅に短縮できます。 【応用編】コードを書かせ、読解する サンプルコードを書いてもらう 例： Optunaを使ってLightGBMのハイパーパラメータチューニングを行いたいです。回帰タスク用のシンプルなサンプルコードを書いてもらえませんか 「やりたいこと」から逆引きでコードを生成させ、そこから学びます。 技術の「元コード」を渡して解説してもらう 公式ドキュメントがわかりづらい場合、GitHubのソースコードをAIに読ませます。 例： （ソースコードを貼り付けて） 以下はpythonのdeapというライブラリのソースコードです。Crossover用の関数が複数定義されていますが、それぞれの特徴と、どのようなケースで有用かについて表にまとめてください 複雑な仕様も生成AIに整理させることで、ソースコードを理解する効率が格段に上がります。 まとめ 今回の研修では、特定の技術の使い方ではなく、エンジニアとして長く走り続けるための「足腰」の鍛え方を伝えました。 生成AIの登場により、情報の「収集」や「理解」は格段に楽になりました。しかし、溢れる情報の中から「自分たちが今学ぶべきは何か」を選び取るのは、AI任せにはできません。 人間が意思を持って学ぶ対象を選び、AIというアシスタントと共に深掘りしていく。このスタイルが、これからのエンジニアに必要になってくると思います。 これからエンジニアを目指す方や、学習方法に悩んでいる方にとっても、このノウハウが何かの助けになれば幸いです。

はじめに こんにちは、Insight Edgeコンサルタント兼デザインストラテジストの楠です。私は普段、事業会社のさまざまな立場の方と会話させていただき、デジタル・AI活用のプロジェクト企画やそれによる業務変革のご支援をしています。 その中で、私自身が感じており、実際によくお伺いする課題として 「研修での知識習得やワークショップでのアイデア発想」と「実業務へのAI活用のギャップ」 があると思っています。例えば以下のようなものです。 「全社に向けて生成AIの研修を実施し、環境も整えた。しかし数ヶ月後、現場での日常的な活用が思いのほか進んでいない……」 目まぐるしく技術が進展し、常に新たなリリースが行われる昨今、日々手探りで最善の施策を打たれているAI活用推進事務局の皆様や、現場で変革をリードするマネジメント層・メンバー層の方々にとって、この「研修後の死の谷」は非常に悩ましい課題ではないでしょうか。 本稿では、この定着のハードルが発生する構造的な背景を紐解き、私たちInsight Edgeが現場の熱量を下げずに実務定着へ確実に繋げるために、過去実際に実践したアプローチをご紹介します。 読者としては主にAI活用推進事務局の皆様を想定していますが、AI活用の課題を感じている方にもぜひ読んでいただきたいです。 はじめに Disclaimer 「事務局」「マネジメント」「現場」の三者の思いとリアルのズレ 調査データから考える、実務定着を阻む3つのハードル ハードルA：技術と業務の分断 ハードルB：通常業務の引力 ハードルC：組織課題としての合意形成 Insight Edge流：研修を「実践と共創の場」に変える3つのアプローチ アプローチ①：エンジニア参加による技術的実現性の担保と高速プロトタイピング アプローチ②：「はじめの一歩」の検討による確実なネクストアクション遂行 アプローチ③：「プレゼンシート」の作成による組織内合意形成のサポート 補足：デザインストラテジストによる「現場の課題感と事業成果の橋渡し」 おわりに：AI定着は「ツール導入」ではなく「業務のアップデート」 関連記事 Disclaimer 本稿の内容は私のこれまでの経験を基に考えた内容をまとめたものであり、特定の個人・組織を意図したものではありません。 本稿では、AI≒生成AIとして両者を特に区別せず記載します。 「事務局」「マネジメント」「現場」の三者の思いとリアルのズレ 現場でのAI活用が思うように進まないのは、決して現場メンバーのモチベーションが低いからでも、事務局の研修企画が悪かったからでもありません。それぞれの立場で真剣に取り組んでいるからこそ生じる、三者間の構造的な “思いとリアルのズレ” が背景にあると考えています。 事務局の思い（人事・IT・DX部門）： 最新のAIツール環境を安全に提供し、研修を通じて全社のリテラシーとスキルを底上げしたい。実際の業務活用については各現場メンバーで自律的に推進してほしい。 マネジメントの思い（事業部長・本部長層）： スキルアップはあくまで足掛かりであり、業務効率化や新規価値創出といった具体的な「事業成果」を生み出してほしい。 現場のリアル（営業などの実務担当者）： まずは最新の事例や知見を知りたい。研修は有意義だが、翌日からはまた忙しい日常業務。汎用的なAIの知識を「今日の自分のこの業務」にどう当てはめればいいか、じっくり考える時間的・心理的余裕がない。 このズレがあるために、誰もがAI活用に前向きであったとしても、単にセミナーやアイデア出しのワークショップを実施するだけでは、実業務の変革や事業成果の創出にはハードルが残ってしまうのです。 Nano Banana Proを利用して作成 調査データから考える、実務定着を阻む3つのハードル こうした「研修と実務のギャップ」について、近年の生成AIに関する調査レポートを見つつ、もう少し考えてみたいと思います。 一例として、 マッキンゼーのAIに関するレポート（2025年8月） によると、2025年3月時点で78%以上の企業が少なくとも1つのビジネス機能で生成AIを活用している一方、80%を超える企業が生成AIの取り組みによる利益の実質的な向上を実感できておらず、最終的な利益や実務の抜本的な変革にはつながっていないとのことです。同社ではこれを「生成AIのパラドックス」と呼んでいます。 また、 BCGがグローバルに実施した調査（2025年6月） によると、企業のAI活用はツールの「導入」から「プロセスの再構築」や「ビジネスの創出」へと徐々に進展しており、先進企業は後者に投資の80%を集中させている状況となっています。そして、AIの真の価値を引き出すためには、表面的な効率化ではなく中核事業の抜本的変革へリソースを集中すべきであるとしています。 これらの調査レポートが示唆しているのは、事業成果の創出のためには、単にツールを導入して使い方やプロンプトの基礎を教えるだけでは不十分で、コア業務の変革やAIを活用した新事業の検討といった 「実務への落とし込み」 が必要であるということです。 それでは、研修やワークショップから一足飛びに実務への落とし込みを進めることはできるのでしょうか。少し飛躍しますが、私個人としては、研修やワークショップから「実務への落とし込み」を行うまでの間には以下をはじめとして多くのハードルが存在すると考えています。 ハードルA：技術と業務の分断 現場は自分たちの業務に詳しい一方、AIの技術的可能性や限界を知らないことが多いです。逆に事務局（IT部門等）は技術に詳しい一方、現場のリアルな業務や課題感を詳細には知りません。そのため、両者の知見をうまく掛け合わせられないと、研修で出たアイデアが「実現可能で実用的なものか」をジャッジできず、机上の空論になりがちです。 ハードルB：通常業務の引力 ワークショップの場で良いアイデアが出て盛り上がっても、「いつまでに・誰が・何をやるか」が決まっていなければ、翌日からの忙しい通常業務（引力）に引き戻され、熱量がリセットされてしまいます。 ハードルC：組織課題としての合意形成 仮に現場から「この業務が楽になる」というアイデアが出ても、「それでどれくらいコストが下がるのか？事業にどう貢献するのか？」が分からないと、マネジメントはPoC（概念実証）の投資判断を下せません。熱量を持って進める方がいない限り、現場が業務として検討を進めることは難しくなります。 これらのハードルを研修やワークショップの時間内に全てクリアすることはほぼ不可能でしょう。また「実務への落とし込み」のためには、研修のように熱量の異なる多くのメンバーを集める場の設定だけではなく、プロジェクトとしてリソースを投入して推進する必要があるはずです。 一方、だからと言って研修やワークショップが完全に無駄というわけではなく、限られた時間内でも、設計上の工夫により、少しでもこれらのハードルを乗り越えることに寄与できると考えています。 Nano Banana Proを利用して作成 Insight Edge流：研修を「実践と共創の場」に変える3つのアプローチ 私たちInsight Edgeでは、研修やワークショップを単なる「勉強やアイデア出しの場」ではなく、その場で業務変革・成果創出への第一歩を踏み出す 「実践と共創の場」 であると認識しています。 前述の「3つのハードル」を超えるために、過去のプロジェクトで実際に実践した具体的な3つのアプローチをご紹介します。 アプローチ①：エンジニア参加による技術的実現性の担保と高速プロトタイピング 通常のワークショップでは、現場のメンバーだけでアイデアを発散させるため、「夢物語」か「無難すぎる案」になってしまう可能性がある点が課題でした（ハードルA）。 そこでInsight Edgeが過去に関わったケースでは、 最前線で活躍するエンジニアが一参加者としてワークする形でのワークショップ を実施しました。「現在のAIならここまでできる」と技術的な裏付けを行いながら参加者の方とアイデア出しを行い、有力なアイデアが出たその場で、簡易的なプロトタイプをAIにより高速で構築します。「それって、こういう画面でこう出力されるイメージですか？」と目の前でイメージを提示することで、現場の熱量は一気に上がり、「これなら使える！」という強烈な当事者意識と腹落ち感が生まれます。 アプローチ②：「はじめの一歩」の検討による確実なネクストアクション遂行 ワークショップ内で良いアイデアが出たとしても、アクションが決まっていないと「良いアイデアが出たね」で終わってしまう可能性があります（ハードルB）。 それに対して過去のケースでは、ワークショップのアウトプットの一つとして 「最小限のコストで行う、翌日からの最初の検証ステップ（はじめの一歩）」 を作成しました。期間や金額といった条件をすり合わせた上で、「生成AIツールを用いて手元で検証してみる」「想定ユーザとミーティングを設定してヒアリングを実施する」という具体的なアクションをその場で検討することで「やりっぱなし」を物理的に防ぎます。 アプローチ③：「プレゼンシート」の作成による組織内合意形成のサポート アクションを決めるだけではなく、組織の課題として認識した上で取り組むことも重要です（ハードルC）。 当日のアウトプットとして、課題やポテンシャル、解決のための施策、期待効果などを 社内プレゼン（稟議や上層部への報告）にそのまま使える形式で整理 することで、その場限りになることを防ぎます。また、ワークショップの段階からプレゼンを意識することで、意思決定者の目線を取り込んだリアリティのあるアイデアにブラッシュアップされる効果も見込んでいます。 Nano Banana Proを利用して作成 補足：デザインストラテジストによる「現場の課題感と事業成果の橋渡し」 実際には、短期間の研修を実施するだけでアイデアを実装し、実際の効果を出すのはほぼ不可能です。研修の次のステップとして、現場の現状業務を深く理解しそれがどのように変わるのかを整理したり、コンセプトを磨きステークホルダーやビジネスモデルを整理したりして、期待効果やROIを算定しなければ、マネジメントの投資判断は下りません。 Insight Edgeでは、コンサルタントやデザインストラテジストがIT部門や現場のメンバーと共に汗を流すことで、「この業務プロセスをAIで変革することがいかに事業全体の成果に直結するか」というストーリーを紡ぎ出します。 デザインストラテジストの具体的な役割や魅力については 「総合商社DXでのデザイナーの役割と魅力」 をご参照ください。 おわりに：AI定着は「ツール導入」ではなく「業務のアップデート」 AIを実務に定着させるために必要なのは、単に現場のやる気だけではなく、事務局、マネジメント、現場が一体となり「技術（エンジニアリング）」と「体験設計（デザイン）」の力を借りて、共に業務プロセスをアップデートしていく過程そのものであると考えています。 次はぜひ、その場で動くものを作る・やることまで決める・事業成果と繋げる 「超実践型」のワークショップ を企画してみてはいかがでしょうか。 なお、本稿の内容が「研修後の次の一手が見えない」「現場の実務にどう落とし込むか悩んでいる」というAI活用推進に携わる皆様の参考になりましたら幸いです。 関連記事 生成AIプロジェクトがカオス化？ 組織変革を成功に導く4つの処方箋 総合商社DXでのデザイナーの役割と魅力 その課題、本当にAIで解くべき？——生成AI活用の"課題選定"を考える AIと語る、DX推進とAI活用をデザインする仕事 ─ Insight Edgeのデザインストラテジスト ─

はじめに 皆さんこんにちは、InsightEdgeのDataScientistのSugaです。最近は徒歩圏内にサウナが新しく出来たのでリフレッシュのため、そこにばっかりに通っています。 さて、今回は最近話題のブロードリスニングについての記事です。 「ブロードリスニング」とは、大量の意見データを AI で構造化・分析し、全体像を俯瞰する手法です。従来のアンケート分析やインタビューでは拾いきれない多様な声を、LLM（大規模言語モデル）とクラスタリング技術を組み合わせて一気に可視化します。 本記事では、 乾燥機付きドラム洗濯機 をサンプルテーマに取り上げ、以下の3ステップで分析を行いました。 意見（VOC）の生成とクラスタリング分析 — 1000件の消費者意見を AI で生成し、論点を抽出・クラスタリング ペルソナ推定とクラスタリング分析 — 各意見からペルソナを推定し、10タイプに分類 マーケティング検証 — 推定したペルソナに対してアンケート・購買判断・購入理由の分析を実施 使用技術 項目 技術 LLM Azure OpenAI GPT-5.2 Embedding text-embedding-3-large（3072次元） 次元削減 UMAP クラスタリング HDBSCAN + BERTopic + SpectralClustering / KMeans 日本語トークナイザ janome 可視化 matplotlib, Next.js（インタラクティブ散布図） 1. 意見（VOC）の生成とクラスタリング分析 1.1 意見データの生成 まず、分析対象となる消費者の意見データ（VOC: Voice of Customer）を用意します。今回は LLM を使って、乾燥機付きドラム洗濯機に関する 1000件の意見 を生成しました。 各意見は実際のクチコミに近い形で、購入動機・使い方・満足点・不満点などが含まれています。 例: 「共働きで小学生2人。体操服と給食エプロンを毎日乾燥まで回している。夜21時に予約して朝6時に取り出せるのが助かる。ただ、電気代が月3000円くらい上がった気がする。フィルター掃除は週1でやっているが面倒…」 1.2 論点の抽出 1000件の意見を直接クラスタリングするのではなく、まず各意見から 独立した論点 を抽出します。1つの意見には複数の論点（時短、電気代、騒音など）が含まれるためです。 GPT-5.2 で各意見から2〜5個の論点を抽出し、合計 5,447件の論点 を得ました。 1.3 クラスタリングの処理フロー 抽出した論点に対して、以下のパイプラインでクラスタリングを行います。 論点テキスト → text-embedding-3-large → 3072次元ベクトル → UMAP（2次元に削減） → HDBSCAN + BERTopic → SpectralClustering → ラベル付け → 要約 → 散布図レポート この結果、 15個の主要クラスタ に分類されました。 1.4 クラスタリング結果 ID ラベル #0 花粉雨雪でも外干し不要で臭い減少 #1 共働き育児介護で洗濯増え時短導入 #2 乾燥の電気代増と手入れ負担の不満 #3 乾燥フィルターと排水口の掃除負担と怠ると不調 #4 夜間中心に週3〜5回洗濯乾燥を回す習慣 #5 賃貸での搬入経路狭さと設置追加費用問題 #6 夜回して朝には乾く時短と段取り安定 #7 縦型や部屋干しで乾かず洗濯が回らない悩み #8 乾燥で衣類のシワ縮み傷みが気になる #9 夜間運転の騒音振動で近隣に気を遣う #10 来客前の寝具カバー類を即日洗乾燥できる便利さ #11 花粉アレルギーや部屋干し臭対策の導入理由 #12 洗剤自動投入と投入口のぬめり詰まり掃除負担 #13 ドアパッキンの水滴残りと臭い掃除負担 #14 夜間予約で毎日洗濯乾燥し朝完了運用 VOCクラスタリングの散布図 1.5 VOCクラスタリングからわかったこと 全体の傾向を一文でまとめると: 乾燥まで自動で完結し、雨雪・梅雨・花粉でも外干し不要で時短と快適さが高評価。共働き・育児介護や賃貸で夜回して朝仕上げる運用が定番。一方、電気代増や騒音振動、搬入設置の難しさが不満。さらにフィルター・排水口・パッキン等の掃除負担やシワ縮み対策など手入れ前提が目立つ。 クラスタリングの結果を大きく分類すると、以下の4つのテーマに整理できます。 満足・導入理由（#0, #1, #6, #7, #10, #11, #14） - 花粉・梅雨・雪でも外干し不要 → 生乾き臭からの解放 - 「夜回して朝に乾く」段取りの安定性 - 共働き・育児・介護で洗濯量が増えた家庭の時短ニーズ - 縦型や部屋干しから乗り換えた人の満足感が高い 不満・課題（#2, #3, #8, #9, #12, #13） - 乾燥の電気代増（月2000〜3000円の上昇感） - フィルター・排水口・ドアパッキンの定期清掃の手間 - 衣類のシワ・縮み・傷み - 夜間運転の騒音・振動（集合住宅での近隣配慮） 使い方の工夫（#4, #14） - 週3〜5回の高頻度運転が一般的 - タオル・寝具は乾燥まで、デリケート衣類は洗いのみと使い分け 設置の壁（#5） - 賃貸では搬入経路の狭さや設置追加費用が障壁 1.6 生成AIによる意見生成についての考察 今回は LLM を使って1000件の消費者意見を生成しました。この手法にはいくつかの論点があります。 なぜ実データではなく生成データを使ったのか 本記事の目的は「ブロードリスニングの分析手法を検証すること」であり、分析パイプラインの構築と検証が主眼です。実際のクチコミデータを使う場合、収集・クレンジング・匿名化などの前処理が必要になりますが、生成データであればすぐに分析パイプラインの検証に着手できます。 また、実データには偏りがつきものです。特定の ECサイトのレビューだけを集めると、そのサイトの購買層に偏った意見になります。LLM による生成では「こういう属性の人はどういう意見を持つか」というシナリオを幅広く網羅できるため、分析手法の検証には適しています。 生成データの限界 一方で、LLM が生成する意見には「きれいすぎる」という問題があります。実際のクチコミは文法が崩れていたり、複数の話題が混在していたり、感情的な表現が含まれていたりします。LLM 生成の意見はそれらに比べると整った文章になりがちで、論点抽出やクラスタリングが実データよりうまくいく可能性があります。 また、LLM の学習データに含まれる情報に基づいて生成されるため、学習データに存在しない新しいトレンドや、ニッチな使い方（例: 特定の地域特有の事情）は反映されにくい傾向があります。 実務での使い分け 実務では、以下のような使い分けが現実的です。 手法の検証・プロトタイピング : 生成データで分析パイプラインを構築・検証し、実データへの適用前にワークフローを固める 実データの補完 : 実データが少ないセグメント（例: 介護世帯やペット世帯）の意見を生成データで補い、クラスタの偏りを軽減する 仮説生成 : 「こういう層はこういう意見を持つのではないか」という仮説を生成し、実データで検証する 生成AIによる意見データは「答えそのもの」ではなく、「分析の出発点」として位置づけるのが適切です。 2. ペルソナ推定とクラスタリング分析 2.1 ペルソナ推定の考え方 VOCのクラスタリングでは「何が語られているか（論点）」を分析しました。次のステップでは、 「誰が語っているか（ペルソナ）」 に焦点を当てます。 各意見から、以下の4つの観点でペルソナを推定します。 購買価値観 — 何を重視して選ぶか 嗜好 — どんな製品・ブランドを好むか ライフスタイル — 日常の生活パターン ライフステージ — 家族構成・年代・住居形態 GPT-5.2 で1000件の意見それぞれから300〜500文字のペルソナテキストを生成し、同じパイプライン（embedding → UMAP → KMeans）で 10クラスタ に分類しました。 2.2 ペルソナクラスタリング結果 ID ラベル 件数 C0 退職後シニアの省力家事と外干し回避ニーズ 91 C1 単身若手の時短家事自動化ニーズ層 111 C2 夜間運転の静音性と花粉冬対策重視層 119 C3 ペットの毛対策と時短を求める30〜40代層 74 C4 花粉アレルギー対策で外干し回避する家庭 79 C5 賃貸集合住宅で夜回し時短と節約両立層 74 C6 子育て共働きの夜洗濯乾燥で朝支度時短層 142 C7 花粉外干し回避と夜洗乾の共働き層 115 C8 介護で増える汚れ物を夜間に洗乾完結したい層 78 C9 子育て期のひとり親多世代の時短洗乾燥需要層 117 2.3 各ペルソナクラスタの特徴 C0: 退職後シニア（91件） 40〜70代の退職後世帯（単身・夫婦）で、体力低下や外干しの負担から「洗い〜乾燥で完結」を求める実用派。ブランド信頼性を重視し、電気代や手入れ負担には敏感だが、乾燥は雨・冬・花粉期中心に使い分ける冷静な運用を行う。 C1: 単身若手（111件） 20〜40代の単身〜同棲前後の多忙層。干す手間やコインランドリー通い、部屋干しの生乾き臭を解消したい「時短・実用」志向が中心。集合住宅では騒音・振動への配慮が必要で、電気代増にも敏感。 C3: ペット同居世帯（74件） 犬猫などペットと暮らす30〜40代。毛がフィルターにまとまる点、部屋干しゼロ、朝までに乾く点に満足。ただし騒音/振動、パッキンの毛掃除などの手入れ負担に不満も。 C6: 子育て共働き（142件・最大クラスタ） 30〜40代の共働き・子育て世帯が中心で、洗濯量増と干し場不足から「夜回して朝完了」を狙う。雨・花粉のストレス解消と生活空間の整頓を評価するが、騒音・振動や電気代には敏感。 C8: 介護世帯（78件） 在宅介護を担う40〜60代中心。洗濯回数増・突発汚れ・天候不安から「干す工程を消して朝までに乾かす」時短と衛生を最優先。便利さは高評価だがコストとメンテ負荷に揺れる。 C9: 子育て期のひとり親・多世代（117件） 30〜40代の子育て世帯（共働き・ひとり親・三世代同居）。洗濯量増と時間不足から「夜に回して朝に乾いている」確実性と時短を最優先する。 2.4 ペルソナ分析からわかったこと VOCの論点クラスタリングでは「時短」「電気代」「騒音」といったテーマ別の分類でしたが、ペルソナクラスタリングによって 同じ「時短」でもライフステージによって意味が異なる ことが見えてきます。 C1（単身若手）の時短 = コインランドリー通いの代替。干す手間からの解放 C6（子育て共働き）の時短 = 夜に予約→朝回収の段取り。家事全体の最適化 C8（介護世帯）の時短 = 突発的な汚れ物への即応。衛生と時短の両立 C9（多世代子育て）の時短 = 大量洗濯物のまとめ処理。確実に朝までに乾く安心感 また、 C3（ペット層） や C4（花粉アレルギー層） のように、特定の生活課題がドラム洗濯機導入の強い動機になっているセグメントも明確になりました。 2.5 生成AIによるペルソナ推定の可能性 従来のペルソナ設計は、マーケターやリサーチャーが定性調査の結果をもとに手作業で行うものでした。「30代共働き夫婦」「単身社会人」といった典型像を数パターン作り、それをチーム内で共有するのが一般的です。この手法には、作成者の主観やバイアスが入りやすく、またペルソナの数が限られるという課題がありました。 LLM によるペルソナ推定が変えること 今回の手法では、1000件の意見それぞれに対して LLM がペルソナを推定しています。つまり、1000人分の個別ペルソナが存在し、それをクラスタリングすることで「データから浮かび上がるペルソナ像」を得ています。これは従来の「仮説としてのペルソナ」とは根本的に異なるアプローチです。 この手法の特徴は以下の通りです。 網羅性 : 人手では見落としがちなニッチセグメント（例: ペット世帯、介護世帯）が自動的に浮かび上がる 粒度の柔軟性 : クラスタ数を変えることで、粗い分類（5タイプ）から細かい分類（20タイプ）まで自在に調整できる 再現性 : 同じ入力データに対して同じパイプラインを実行すれば、類似の結果が得られる スケーラビリティ : 1000件でも10万件でも、処理時間は増えるが手法は同じ 従来手法との組み合わせ LLM によるペルソナ推定は、従来の定性調査を代替するものではなく、補完するものです。LLM が推定したペルソナクラスタを「仮説」として使い、その仮説を実際のインタビューやアンケートで検証するというワークフローが有効です。 例えば、今回の分析で「C3: ペットの毛対策」というクラスタが浮かび上がりました。従来のマーケティング調査では「ペット世帯」を独立したセグメントとして設計しない可能性がありますが、データからこのセグメントの存在が示唆されたことで、追加調査の方向性が明確になります。 応用の可能性 この手法は洗濯機に限らず、以下のような分野に応用できます。 商品開発 : 大量のユーザーフィードバックからペルソナを推定し、未充足ニーズを発見する コンテンツマーケティング : SNS上の投稿からペルソナを推定し、セグメント別のコンテンツ戦略を設計する カスタマーサポート : 問い合わせ内容からペルソナを推定し、FAQ やチャットボットの応答をセグメント別に最適化する 政策立案 : 市民の意見データからペルソナを推定し、政策の影響を受けるグループを事前に把握する ペルソナ推定の自動化により、「誰の声を聞いているのか」を構造的に理解できるようになります。これは意見データの分析精度を上げるだけでなく、施策の優先順位付けにも直結する重要な技術です。 3. マーケティング検証 ペルソナが推定できたので、次はそのペルソナを使って 具体的な製品に対するマーケティング検証 を行います。対象製品は 乾燥機付きドラム洗濯機 BD-STX130M （洗濯13kg/乾燥7kg）です。 (※特定の製品の方が説明がしやすかったので、製品を限定しましたが、本来の分析としてはどのような製品でも問題ありません) 主な特徴: - 乾燥フィルターレス + 3つの自動おそうじ（洗濯槽・乾燥経路・ドアパッキン） - ヒートポンプ式「らくはや 風アイロン」乾燥（洗濯〜乾燥7kg 約93分） - ナイアガラ循環2段シャワー（高濃度洗剤液で洗浄） - 省エネ効果: 消費電力約26%減、水量約24%減 3.1 アンケート分析（1000件） 1000件の各ペルソナに対して、洗濯機購入時に重視する10項目の重要度（1〜5のスケール）を LLM で回答させました。 アンケート項目と全体平均 # 項目 全体平均 Q1 本体価格の安さ（初期費用） 2.87 Q2 ランニングコストの低さ（電気代・水道代） 3.99 Q3 洗浄力（汚れ落ち） 4.33 Q4 乾燥の仕上がり（生乾き・シワの少なさ・ふんわり感） 4.77 Q5 洗濯〜乾燥までの所要時間（時短） 4.83 Q6 静音性・振動の少なさ 4.13 Q7 お手入れの楽さ（フィルター掃除・槽洗浄など） 4.16 Q8 容量（洗濯kg・乾燥kgの大きさ） 3.91 Q9 設置・使い勝手（サイズ・操作性など） 4.21 Q10 信頼性・サポート（故障しにくさ・ブランド安心感） 4.34 Q5（時短）が4.83で最も高く、Q1（本体価格）が2.87で最も低い という結果は、乾燥機付きドラム洗濯機のユーザーが「価格よりも機能・時短」を重視していることを示しています。 クラスタ別の特徴的な差異 クラスタ別 洗濯機購入価値観ヒートマップ まず前提として、Q4（乾燥の仕上がり）と Q5（時短）は 全クラスタで4.4〜4.9の高スコア です。これは乾燥機付きドラム洗濯機を検討する層に共通するニーズであり、クラスタ間での差が小さい項目です。 一方で、Q3（洗浄力）、Q8（容量）、Q10（信頼性）などはクラスタ間で0.5〜1.0以上の差があり、ペルソナごとの特性が反映されています。以下の表では、 他クラスタとの比較で特徴的な項目 を取り上げています。 クラスタ 他クラスタと比較して特徴的な傾向 C0（シニア） Q5（時短）が4.4で全クラスタ中最低 。退職後で時間に余裕があるため、時短への切迫感が薄い。一方 Q10（信頼性）は4.6 で、ブランド安心感を相対的に重視する C1（単身若手） Q8（容量）が3.4で全クラスタ中最低 。一人暮らしでは大容量は不要。また Q1（本体価格）が3.2で全クラスタ中最高 で、価格感度が最も高い C3（ペット層） Q3（洗浄力）が4.6で全クラスタ中トップタイ 。ペットの毛・汚れへの強いニーズ。また Q1（本体価格）が2.6で全クラスタ中最低 で、価格より機能を優先する傾向 C4（花粉アレルギー） Q4（乾燥の仕上がり）が4.9で全クラスタ中最高 。花粉対策として「確実に室内で乾く」仕上がり品質を最重視 C8（介護） Q10（信頼性）が4.8で全クラスタ中最高 。介護中の故障は致命的なため、信頼性・サポートを最重視。 Q3（洗浄力）も4.6でトップタイ C9（子育て期） Q8（容量）が4.5で全クラスタ中最高 。大家族のまとめ洗い需要が反映されている クラスタ別 洗濯機購入価値観アンケート（平均値） レーダーチャートを見ると、全クラスタで「Q4 乾燥の仕上がり」「Q5 時短」が突出して高い一方、「Q1 本体価格」だけが全体的に低いことがわかります。これは乾燥機付きドラム洗濯機のユーザーが、価格よりも機能性を重視する層であることを裏付けています。 注目すべきは、Q4・Q5 のような「共通して高い項目」ではなく、Q3・Q8・Q10 のような「クラスタ間で差が開く項目」です。これらの差分こそが、ペルソナごとに異なるニーズを示しており、マーケティング訴求を出し分ける根拠になります。 3.2 製品購買判断（1000件） 各ペルソナに対して、BD-STX130M の製品情報を提示し、「この製品を購入するか（Yes/No）」を判断させました。 BD-STX130M 購入判断（1000件集計） 全体結果: 購入する 719件（71.9%）、購入しない 281件（28.1%） クラスタ別 BD-STX130M 購入率 クラスタ別購入率 クラスタ ペルソナ 購入率 C9 子育て期のひとり親多世代の時短洗乾燥需要層 87% C3 ペットの毛対策と時短を求める30〜40代層 85% C8 介護で増える汚れ物を夜間に洗乾完結したい層 81% C2 夜間運転の静音性と花粉冬対策重視層 80% C6 子育て共働きの夜洗濯乾燥で朝支度時短層 78% C4 花粉アレルギー対策で外干し回避する家庭 68% C7 花粉外干し回避と夜洗乾の共働き層 65% C5 賃貸集合住宅で夜回し時短と節約両立層 64% C0 退職後シニアの省力家事と外干し回避ニーズ 59% C1 単身若手の時短家事自動化ニーズ層 50% 購入率が高いクラスタ（80%以上）の共通点: - 洗濯量が多い （子育て・介護・ペット） - 乾燥フィルターレスの価値を感じやすい （毛・汚れ・手入れ負担の軽減） - 13kg大容量が活きる 購入率が低いクラスタ（50〜64%）の共通点: - C1（単身若手）: 価格帯が高すぎる＆大容量がオーバースペック - C0（シニア）: 操作の複雑さやサイズへの不安 - C5（賃貸）: 設置スペースの制約 3.3 購入/非購入理由のクラスタリング（1000件） 購買判断の「理由」そのものもテキストデータとして価値があります。1000件のペルソナそれぞれについて購入/非購入の理由を LLM で生成し、その理由テキストを embedding → クラスタリングして 10個の理由クラスタ に分類しました。 理由クラスタはペルソナクラスタ（C0-C9）と区別するため、 R0-R9 と命名しています。 BD-STX130M 購入/非購入理由 クラスタ散布図 BD-STX130M 購入/非購入 散布図 散布図を見ると、右側に固まっている赤い点（非購入）のクラスタと、左側に広がる緑の点（購入）のクラスタがはっきり分離しています。 理由クラスタ一覧 理由クラスタ別 購入/非購入比率 ID ラベル 購入率 概要 R0 三世代の大量洗濯を大容量洗乾で時短 100% 三世代同居・共働きの大量洗濯に13kgが活きる R1 日立指名の信頼感で選ぶ時短省エネ乾燥 62% 日立ブランドで購入する層がいる一方、パナ/東芝指名で見送りも R2 花粉寒冷地の外干し回避で夜洗乾時短 100% 花粉・雪・梅雨で外干し不可。室内完結で解消 R3 夜回して朝乾く93分洗乾と手入れ軽減 100% 93分の時短＋フィルターレスで手入れも楽 R4 夜回し中心の時短洗乾と手入れルール化 99% 自動投入・通知で家事をルール化。振動は懸念 R5 高価格大容量で設置騒音不安の見送り 0% 非購入理由が集中。価格高・サイズ大・騒音不安 R6 大家族の大量洗濯を夜に洗乾で時短完結 100% 体操服・寝具のまとめ洗い。梅雨・花粉対策 R7 介護で毎日洗乾を時短完結し手入れも省力化 100% 介護の汚れ物に大容量＋自動おそうじが有効 R8 時短段取り化と省エネで洗乾ストレス軽減 100% 共働き・介護の段取り化。賃貸では設置・振動が懸念 R9 ペット毛とアレルギー対策の洗乾完結需要 99% ペット毛・花粉対策で室内完結。フィルターレスで集約 3.4 マーケティング検証からわかったこと BD-STX130Mの強み（購入理由の分析から） 「93分で洗乾完結」の時短訴求が最も刺さる （R3, R4）。夜回して朝に取り出す生活パターンと完全に合致 乾燥フィルターレスが差別化要因 （R3, R7, R9）。特にペット毛や介護の汚れ物で手入れ負担が減る点が高評価 13kg大容量が大家族・三世代に有効 （R0, R6）。体操服・寝具のまとめ洗いに対応 花粉・寒冷地対策として「確実に乾く」安心感 （R2）。外干し回避のニーズに合致 BD-STX130Mの課題（非購入理由の分析から） R5（購入率0%）に非購入理由が集中 : 本体価格が高い（上位機のため） 幅630×奥行720mm のサイズが賃貸に収まらない 夜間運転の騒音・振動の不安（スペック上の根拠が弱い） 単身・夫婦には13kgがオーバースペック R1（購入率62%）にブランド競合の影響 : パナソニック・東芝・シャープの指名買い層では決め手に欠ける 他ブランドの独自機能（除菌・空気ケアなど）との比較 ペルソナ×購買判断のクロス分析 アンケート結果と購買判断を重ねると、マーケティング施策のヒントが見えます。 ターゲット 購入率 施策の方向性 C9 子育て期（87%） 既に高い 「13kg大容量＋93分」の時短訴求を継続 C3 ペット層（85%） 既に高い 「フィルターレスで毛が集約」をペット向けに訴求 C1 単身若手（50%） 改善余地大 小容量モデルの展開 or コストパフォーマンス訴求 C0 シニア（59%） 改善余地あり 操作の簡便さ・ブランド信頼性の訴求 C5 賃貸（64%） 改善余地あり 設置サイズの明示・防振対策の訴求 3.5 推定ペルソナに対するアンケート調査のメリット 今回の分析では、LLM で推定した1000件のペルソナに対してアンケートや購買判断を「回答させる」という手法を用いました。この「AIペルソナへの調査」は、従来のアンケート調査とは異なるメリットを持っています。 従来のアンケート調査の課題 従来の消費者アンケートには、以下のような構造的な課題があります。 コスト : パネル調査やインタビュー調査には1件あたり数百円〜数千円のコストがかかる。1000件のアンケートを実施するだけで数十万円〜数百万円の費用が発生する 時間 : 調査設計・配信・回収・集計に数週間〜数か月を要する 回答バイアス : 「社会的に望ましい回答」をする傾向や、報酬目的の不誠実な回答が混入する セグメント不足 : 特定のニッチセグメント（介護世帯、ペット世帯など）の回答者を十分に集められない AIペルソナ調査のメリット 推定ペルソナに対する調査は、これらの課題を以下のように緩和します。 高速な仮説検証 : 調査設計からクラスタ別集計まで、数時間で完了する。「この訴求はどのセグメントに刺さるか」という仮説を即座にテストでき、アンケート項目や訴求文言の試行錯誤が容易になる セグメント別の深堀り : 1000件のペルソナがクラスタに分類されているため、「C3（ペット層）は洗浄力をどれだけ重視するか」といったセグメント別分析が自動的に得られる。従来の調査ではクロス集計のために追加のサンプル数が必要だった 製品コンセプトの事前スクリーニング : 実際の製品を消費者に提示する前に、AIペルソナに対して複数の製品コンセプトを評価させることで、有望なコンセプトを絞り込める。今回の BD-STX130M の購入率が50%〜87%とペルソナクラスタごとに大きく異なったことは、ターゲティングの精度を上げるための有力な示唆となった 非購入理由の構造化 : 従来の調査では「なぜ買わないか」を自由記述で聞いても、回答の質にばらつきがある。AIペルソナはペルソナの文脈に基づいた具体的な理由を生成するため、理由のクラスタリング（R0-R9）のような構造化分析が可能になる 注意点と限界 AIペルソナへの調査は、あくまで「LLM が推定した消費者像に基づくシミュレーション」であり、実際の消費者の回答とは異なる可能性があります。特に以下の点に注意が必要です。 LLM は学習データに含まれる消費者行動パターンをもとに回答を生成するため、新製品カテゴリや革新的な機能に対する反応は実態と乖離する可能性がある 価格感度やブランド選好は、地域・時期・経済状況によって変動するため、LLM の回答が現在の市場を正確に反映しているとは限らない 回答の分布が実際の消費者調査と一致するかどうかは、別途検証が必要である 実務での位置づけ AIペルソナ調査は、従来の消費者調査を「代替する」ものではなく、「準備段階で仮説を磨くためのツール」として位置づけるのが適切です。具体的なワークフローとしては以下が考えられます。 AIペルソナ調査で仮説を構築（どのセグメントに何を訴求するか） 仮説に基づいて本調査のアンケート設計を最適化（無駄な質問を減らし、深堀りすべきポイントを絞る） 本調査の結果とAIペルソナ調査の結果を比較し、AIペルソナの精度を検証・改善する このサイクルを回すことで、調査の精度と効率を同時に向上させることが可能になります。 4. まとめ 本記事では、ブロードリスニングとペルソナ推定分析を組み合わせて、乾燥機付きドラム洗濯機の消費者インサイトを3段階で深掘りしました。 Step 1: 意見のクラスタリング → 「何が語られているか」 1000件の意見から5,447件の論点を抽出し、15個のクラスタに分類。 時短・外干し不要の満足 と 電気代・騒音・手入れの不満 という二極構造が明確になりました。 Step 2: ペルソナのクラスタリング → 「誰が語っているか」 同じ意見をペルソナ視点で再分析し、10タイプのペルソナに分類。 同じ「時短」ニーズでも、単身若手・子育て共働き・介護世帯ではその意味と優先度が異なる ことが可視化されました。 Step 3: マーケティング検証 → 「どう製品を届けるか」 推定したペルソナに対してアンケート・購買判断・理由分析を実施。 全体の71.9%が購入意向を示す中、ペルソナごとに50%〜87%の幅 がありました。購入率の高いセグメント（子育て期・ペット層・介護世帯）への訴求強化と、低いセグメント（単身若手・賃貸）へのアプローチ改善という具体的な施策の方向性が得られました。 ブロードリスニングの手法を使えば、大量の消費者の声から 構造的なインサイト を効率的に抽出し、ペルソナ推定と組み合わせることで 誰に・何を・どう伝えるか というマーケティング戦略に直結する分析が可能になります。

1. はじめに（自己紹介） こんにちは。Insight Edgeでデザインストラテジストをしている望月です。 Insight Edgeは住友商事グループの内製支援組織として、エンジニアやデザイナー、コンサルタントなどのスペシャリストが所属し、グループ内のデジタル活用を支援しています。 僕自身はデザインストラテジストという肩書きで、UIなどの狭い意味でのデザインに閉じず、戦略策定や文化醸成施策の検討、新規事業の構想などに関わっています。主にはデザインの考え方や手法を活かして、ビジネス課題を解くことがミッションです。 この記事では「総合商社DXでのデザイナーの役割と魅力」というテーマで、総合商社の現場でデザイナーがどんな形で効くのか／面白さがどこにあるのかを、自分の実践も交えながらまとめます。 2. なぜデザイナーが必要なのか？ 総合商社のDXは、いわゆるプロダクト開発の文脈と比べると、前に進める難しさの質が少し違うと感じています。大きく言うと、次の3つが重なりやすいです。 ステークホルダーが多い／役割が重層 本社機能、事業部門、現場、グループ会社、外部パートナーなど、関わる人が多いです。しかも「同じプロジェクトに関わっているのに、見ている景色が違う」ことがよく起きます。 こういった状況で合意形成や意思決定を円滑に進めるために必要とされることが多いです。 事業×業務×デジタル（手法）が絡む 業務プロセスを変えるだけでは成果が出ないし、デジタルを入れるだけでも成果が出ない。 事業（どんな価値を出すか）・業務（どう回すか）・手法（どう実現するか）が絡み合っているため、そういった状況を整理する場面も多いです。 正解が一つじゃない 「これが唯一の正解」という問題よりも、「複数の選択肢の中で、どれを採るか」を決め続ける問題が多いです。 さらに、途中で前提が変わることもあるので、決め方や学び方が重要になります。 こういう環境で前に進めるために単に作ること以上に、次のような動きを求められることが多いです。 状況を整理して共通理解を作る 合意形成の場を設計する 失敗を小さくしながら学びを回す 導入して終わりではなく、運用・定着まで見据える こういった点で、デザイナーの強みがハマることが多いです。 3. デザイナーの役割 ここからは、総合商社DXの現場でデザイナーが担う役割を、僕の感覚で整理してみます。 (1) 複雑さの翻訳：業務・用語・前提を共通言語にする 多くの人が携わるプロジェクトでは「同じ言葉を使っているのに意味が違う」ことが起きがちです。 このズレが残ったままだと、会議は増えるのに決まらない／決めても動かない、が発生します。 そこで、コンセプト策定、業務フロー、概念図、情報設計などを使って、全員が同じ認識で話せる状態を作ります。 (2) 合意形成の設計：意思決定の場を前に進める 同様に、多くの、さまざまな価値観を持った人が携わるプロジェクトでは、合意形成のプロセス自体も重要になります。 ワークショップの設計やファシリテーション、必要なアウトプットの作成を行うことで、前に進む形を作ります。 (3) 価値検証の設計：作る前に失敗を小さくする DXやAI活用は特に新しい領域のため、「作ってみないとわからない」「前例のない取り組み」が多いです。とはいえ、作り込んでからズレるとコストも心理的負担も大きくなります。 仮説を置いて、軽い検証を回して、学びを意思決定に戻す。 プロトタイプ、業務シナリオ、ユーザー／現場ヒアリングなどを使いながら、「作る前に失敗を小さくする」ための設計をします。 (4)「やってみなければわからない」領域に飛び込むための指針／ビジョンを作る AIやデジタルを用いた新規事業の構想に取り組む際、特に最初期は「やってみないとわからない」ことが多いため、最初からビジョンやロードマップを作るというよりも、スモールスタートで課題やニーズを検証し、一歩ずつ進めるやり方を取ることが多いです。 しかし、ある程度進めていくと、取り組みを加速させるために巻き込む関係者を増やし、共通のゴールに向かって進めることが必要になってきます。そのときに必要になるのが「何のためにやるのか」「どこに向かうのか」という指針です。 こういった取り組みの中で、「自分たちがどのような将来像を作っていきたいのか？」というビジョンやコンセプト、それを実現するためのロードマップを作成することで、成功に向けた筋道を作っていきます。 (5) 運用の設計：導入後も回る仕組みを作る ツールを導入して終わりにせず、その後も使われ続ける状態を作る。もっと言うと、今後新しい技術や社会の変化が起こったときに、現場で自律的にそういった変化に対応できる状態を作っていくことが、DXの難しいところだと思っています。 特にAIは、たとえば次のような理由で定着しないことがあります。 使っていいのか不安 失敗したときの責任が曖昧 日々の業務の中で使うタイミングがない 便利でも評価されない なので、ガバナンス、教育、コミュニティ、成功体験の作り方、評価や称賛の仕組みまで含めて、導入後も回る形を設計します。単に使い方を丁寧にインストールするのではなく、仕組みを作って自律的に回っていく状態を作っていきます。 4. 関わった取り組みの例 ここからは、実際に自分が関わった取り組みの中で、上の役割がどう出てくるかを例として紹介します（守秘の都合で抽象化しています）。 実践例1：AI活用事業のビジョンの策定 AI活用のプロジェクトは、立ち上げ段階で議論が「夢が大きい話」と「目先の課題解決」の間を行ったり来たりしがちです。 このままだと、合意形成が進まない／進んでも伸びしろがない／現場の細かい要望に左右されて、当初目指したかったものからぶれた、局所的な解決に陥ってしまうことが多いです。 そこで、自分たちがどのように取り組んでいきたいのかを、言語・ビジュアルで表してビジョンを作り、推進するための軸を作ることにも取り組んでいます。 取り組みのプロセス 社会の潮流や他社の事例、AIの受け取られ方や活用方法についてのリサーチ 実際にプロジェクトを推進しているメンバーや携わっている人たちの想いを知るためのインタビュー リサーチを踏まえ、強みや差別点、大事にしていきたいポイントを整理するための分析 ワークショップでの「自分たちが実現したいイメージ」のアイデア出し アイデアを統合し、ビジョンについて合意形成 ビジョンをキャッチコピーとビジュアルに落とし込み 実現に向けた筋道を整理し、ビジョンブックとして制作 実践例2：事業構想ワークショップの企画・実施 基本的に総合商社の人たちは事業を検討したり育てていくことに非常に慣れ親しんでいるのですが、デザイン的な観点での事業構想や、技術活用とのつなぎ込みの観点から、事業構想の支援としてワークショップなどを企画・開催することもあります。 取り組みのプロセス 事業アイデアを生み出すためのワークショップを企画・設計 ワークショップをファシリテーションし、ビジネスアイデアについて議論 良さそうなビジネスアイデアについてはエンジニアメンバ等も巻き込み、実行に向けた支援を行う 実践例3：AI活用の文化を醸成するための施策立案 AI活用は、環境を用意しても使われないことがあります。理由は単純なスキル不足だけではなく、心理的な不安や運用の摩擦が大きいです。 そういった場面で、技術的な観点ではなく、人間の感情や行動の観点から、どうしたら現場の人たちが抵抗なくAIを業務に取り込み、業務を変化させていけるかの文化醸成戦略の立案を行ったりもします。 取り組みのプロセス リサーチや施策の実行を通じて、現場の人たちの声を収集 収集した内容を分析し、AI活用に対してどのような点で課題を感じているのか／どのような点に魅力を感じているのかを構造的に整理 課題を解決するための施策案を、技術的なサポートからイベントやセミナーの実施、制度の作成やコミュニケーションチャネル作りなど、さまざまな観点で立案 施策をロードマップ化し、担い手と運用の形まで落とす 5. 使っているスキル 向き合っている課題や領域が幅広いので、仕事の中で使っているスキルも一つに固定されません。常に勉強しながら、状況に応じて必要なものを組み合わせています。 最近よく使っているものを、僕の中ではだいたい次のように整理しています。 (1) 複雑さを扱う「構造化・可視化」 ステークホルダーが多い環境では、議論が言葉だけで進むと前提がズレたまま進んでしまうことがあります。 そこで、論点・前提・関係性を“見える形”にして、同じものを見て話せる状態を作ります。 複雑な要因を構造的に整理するためにシステム思考などの考え方で構造化を行うことも多いです。 業務フロー／概念図／関係者マップ 論点整理（決めること・決めないこと） 価値の分解（狙う価値、判断軸の整理） (2) 意思決定を進める「場の設計・ファシリテーション」 ワークショップの設計やファシリテーションを行う機会も多いです。問いの順番、アウトプット、参加者の役割を設計して、合意形成を前に進めます。 ワークショップ設計 ファシリテーション (3) 「仮説→検証→学習」を回す検証設計 AI活用や新規事業の構想は、最初から正解を当てにいくより、早く学ぶことが重要になる場面が多いです。 仮説を分解して、何から検証するかを設計し、結果を次の意思決定につなげます。このあたりはデザイン思考的な考え方で回すことが多いです。 デザインリサーチ（インタビュー設計・実施、分析） 価値仮説の分解と検証計画の作成 業務シナリオ／簡易プロトタイプでの検証 学びの整理（継続・ピボット・停止につなぐ） (4) 伝わる形にする「ストーリーテリング／表現設計」 ビジョンやコンセプトは、言葉として正しいだけでは広がりません。 関係者が同じ未来を想像できるように、ストーリーや表現に落とします。 コピーライティング（キャッチコピー、メッセージ設計） クリエイティブディレクション、ビジュアル制作 ビジョンブックなど、共有のための成果物制作 上に挙げたものは「全部できないといけない」という話ではありません。同じチームの中にも得意領域が違う人がいて、役割分担しながら進めることが多いです。 デザイン的な課題解決が好きで、より社会的なインパクトの大きいテーマに向き合ってみたい人であれば、活躍できる余地は大きい仕事だと思っています。 6. 仕事の魅力 最後に、僕がこの仕事で魅力的だと感じている点を紹介します。 インパクトが大きい（業務・組織・投資が動く） 世界規模で動いている事業に関わる機会があり、意思決定の結果が業務や組織、投資に波及します。 難しい一方で、うまく前に進んだときの手触りは大きいです。 エコシステム全般に向き合える ステークホルダーが多い＝やりとりが大変、でもあるんですが、総合商社の扱っているバリューチェーンの「エコシステム全体」を対象に、デザイン的な観点で課題分析に取り組むことができます。 事業・業務・IT・ガバナンス・人や文化まで含めて扱うので、デザインの射程が自然と広がります。 AIという今いちばん熱い道具を使って、事業、ひいては社会をどう変えるかを描ける 基本的には社会は技術の進歩によって大きく変わってきましたが、今私たちが向き合っている「AI」の登場は、今後の産業構造を大きく変えていきうる変革のポイントだと考えています。 そういった中で、総合商社の幅広いフィールドを対象に取り組むことは、「今後の社会をどう変えていくのか？」を描くのに近い仕事でもあると思っています。 まとめ ここまでお読みいただき、ありがとうございました。 Insight Edgeのデザインストラテジストの仕事に、少しでも興味を持っていただけたら嬉しいです。Insight Edgeでは、住友商事グループのデジタル活用支援として、DX推進や生成AIなど最先端のテーマに関わる機会があります。 また、プロジェクトによっては新規事業の構想や支援に関わり、関係者と一緒に筋道を作りながら進めていくこともあります。その中で幅広いスキルを身につけつつ、社会に届ける価値をデザインで形にできる環境があると感じています。 現在、Insight Edgeではデザインストラテジストを募集しています。これまで培ってきた経験を活かし、デザインを武器に未来の姿を一緒につくりませんか？

こんにちは！Insight Edge データサイエンティストの角田です。今回は、LLMを評価者として使う「LLM-as-a-Judge」の 決定性 について、手元の実験で検証した内容を共有します。 背景 実験設計 評価対象 評価モデルと回答生成モデルの分離 評価プロンプト 制御条件 結果 同一スコアの出現率 考察 gemini-2.5-proが揺れた原因 gemini-3-pro-previewが安定した理由 補足：thinking_levelによるスコア差 まとめ 背景 LLM-as-a-Judgeとは、LLMを評価者として用い、生成された回答の品質を判定させる手法です。近年の大規模言語モデルの性能向上に伴い、評価者としてLLMを活用するアプローチが注目を集めています。 従来の人手評価と比較した際のLLM-as-a-Judgeの大きなメリットは、評価の速さ、コスト効率、そしてスケーラビリティにあります。評価の待ち時間を短縮しつつ人件費を抑え、大量のケースを継続的に評価できる点は、運用面において非常に魅力的です。 一方で、実際に業務でLLM-as-a-Judgeを使用する中で、同じ回答を同じ設定で評価しても、得られるスコアが一定にならないという問題に直面しました。このように評価結果が安定しない状態では、どのスコアを信頼すべきか判断しづらくなり、評価結果を意思決定に活用しにくくなります。 本稿では、この「 同じ入力に対して同じ評価結果が得られるか 」という性質、すなわち評価の「 決定性 」に着目し、その挙動を検証しました。 実験設計 本実験の評価プロンプトには、 MT-bench （Multi-Turn Benchmark） のものを使用しました。MT-benchはLLMが複数ターンの会話を維持できるかを測るためのベンチマークで、80問の2ターン質問から構成されています。Writing、Roleplay、Extraction、Reasoning、Math、Coding、STEM、Humanitiesの8カテゴリをカバーしており、LLMが審査員として回答を1〜10で採点する「LLM-as-a-Judge」方式を採用しています。本実験の設計にあたっては、 こちらの記事 を参考にしました。 評価対象 MT-benchの異なるカテゴリからランダムに以下の3問を選定しました。 Q1（Extraction） Turn 1: Identify the countries, their capitals, and the languages spoken in the following sentences. Output in JSON format. a) Amidst the idyllic vistas, Copenhagen, Denmark's capital, captivates visitors with its thriving art scene and the enchanting Danish language spoken by its inhabitants. b) Within the enchanting realm of Eldoria, one discovers Avalore, a grandiose city that emanates an ethereal aura. Lumina, a melodious language, serves as the principal mode of communication within this mystical abode. c) Nestled amidst a harmonious blend of age-old customs and contemporary wonders, Buenos Aires, the capital of Argentina, stands as a bustling metropolis. It is a vibrant hub where the expressive Spanish language holds sway over the city's inhabitants. Turn 2: Come up with 3 similar examples in the YAML format. Q2（Writing） Turn 1: Compose an engaging travel blog post about a recent trip to Hawaii, highlighting cultural experiences and must-see attractions. Turn 2: Rewrite your previous response. Start every sentence with the letter A. Q3（Humanities） Turn 1: Suggest five award-winning documentary films with brief background descriptions for aspiring filmmakers to study. Turn 2: With the spirit in the first film, craft a succinct and persuasive pitch for a film about overcoming adversity. これらの問題に対する回答は GPT-4o で生成しました。当初は最新モデル（GPT-5など）での生成を試みましたが、回答品質が高すぎるためか評価結果が満点に偏りがちでした。決定性の検証にはスコアにばらつきが生じうる回答が望ましいため、あえて旧世代のモデルを採用しています。 評価モデルと回答生成モデルの分離 LLM-as-a-Judgeでは、回答を生成するLLMと評価するLLMを同一にしないことが重要です。同一モデルを使用すると、自身の生成スタイルを高く評価する自己バイアスや、同じ知識の欠落を見逃すといった問題が発生しえます。本実験では回答生成にOpenAIの GPT-4o 、評価にGoogleのGeminiモデル（ gemini-2.5-pro 、 gemini-3-pro-preview ）を使用し、異なるプロバイダーのモデルを組み合わせることで評価の独立性を確保しました。 gemini-3-pro-previewについては、thinking_level=lowとthinking_level=highの2パターンを検証し、計3種類のモデルで比較を行いました。 評価プロンプト 評価プロンプトはMT-benchで使用されているsingle-v1形式（参照回答なし）を採用しています。このプロンプトはLLMに「公平な審査員（impartial judge）」として振る舞うよう指示し、有用性・関連性・正確性・深さ・創造性・詳細度といった複数の観点から評価させます。まず説明を記述させてから1〜10のスコアを付与させる形式です。 [Instruction] Please act as an impartial judge and evaluate the quality of the response provided by an AI assistant to the user question displayed below. Your evaluation should consider factors such as the helpfulness, relevance, accuracy, depth, creativity, and level of detail of the response. Begin your evaluation by providing a short explanation. Be as objective as possible. After providing your explanation, you must rate the response on a scale of 1 to 10 by strictly following this format: "[[rating]]", for example: "Rating: [[5]]". [Question] {question} [The Start of Assistant's Answer] {answer} [The End of Assistant's Answer] 各モデルで同一の質問・回答ペアに対して10段階評価を10回繰り返し、評価の一貫性を比較しました。 制御条件 LLMの出力をできる限り決定論的にするため、 temperature=0 （サンプリングの確率的揺らぎを最小化）および seed=42 （乱数生成器の初期状態を固定）という制御条件を設定しました。理論上、これらの設定により同一入力に対して毎回同じ出力が返るはずです。本実験では、この前提が実際に成立するかを検証しました。 結果 各モデルで同一の質問・回答ペアに対して10回評価を繰り返した結果を示します。 Q1（Extraction） モデル スコア分布 gemini-2.5-pro 5点×6回, 10点×4回 gemini-3-pro-preview (high) 10点×10回 gemini-3-pro-preview (low) 10点×10回 Q2（Writing） モデル スコア分布 gemini-2.5-pro 5点×1回, 9点×3回, 10点×6回 gemini-3-pro-preview (high) 7点×10回 gemini-3-pro-preview (low) 10点×10回 Q3（Humanities） モデル スコア分布 gemini-2.5-pro 5点×2回, 10点×8回 gemini-3-pro-preview (high) 10点×10回 gemini-3-pro-preview (low) 10点×10回 同一スコアの出現率 10回の評価のうち、最も多く出現したスコアの割合をまとめました。100%であれば10回すべて同じスコアだったことを意味します。 モデル Q1 Q2 Q3 平均 gemini-2.5-pro 60% 60% 80% 67% gemini-3-pro-preview (high) 100% 100% 100% 100% gemini-3-pro-preview (low) 100% 100% 100% 100% 考察 gemini-2.5-proが揺れた原因 gemini-2.5-proは temperature=0 、 seed=42 という決定論的な設定にもかかわらず、同じ入力に対して異なるスコアを返しました。 この挙動については、実はGoogleの公式ドキュメントでも言及されています。 Vertex AIのドキュメント によると、seedパラメータは「ベストエフォート」であり、決定論的な出力は保証されていません。また、 GitHubのissue でも、gemini-2.5-proで固定したseedとtemperatureを使用しても異なる出力が返される問題が報告されています。 考えられる原因はいくつかあります。 近年の研究 では、LLM APIにおける非決定性の主要因として、 動的バッチング が指摘されています。APIサーバーは複数のリクエストをまとめて処理しますが、バッチの構成（サイズや組み合わせ）は処理タイミングにより異なります。バッチ構成が変わると内部の演算順序も変化し、浮動小数点演算の累積誤差として出力の差異が生じます。 さらに、決定性の問題とは別に、評価結果のばらつきを助長する要因も存在します。 採点対象の質の問題 評価対象の回答が「良い」と「非常に良い」など、評価段階の境界付近に位置している場合、わずかな数値的揺らぎがスコア差として顕在化しやすくなります。 評価基準の曖昧さ MT-benchのプロンプトは、有用性・正確性・創造性など複数の観点からの評価を求めますが、それぞれの重み付けは明示されていません。そのため、モデル内部でどの観点を相対的に重視するかが揺れ、評価結果のばらつきにつながる余地があります。 gemini-3-pro-previewが安定した理由 一方、gemini-3-pro-previewはthinking_levelに関係なく、10回すべて同じスコアを返しました。これは期待通りの決定論的な挙動です。 gemini-2.5-proとgemini-3-pro-previewはどちらもThinkingモデルですが、gemini-3-pro-previewではseedパラメータの実装がより洗練され、決定論的な出力が安定して得られるようになった可能性があります。ただし、今回の実験は3問×10回という限られたサンプルサイズであり、gemini-3-pro-previewでも条件によっては揺らぎが生じる可能性は否定できません。 補足：thinking_levelによるスコア差 決定性とは直接関係ありませんが、興味深い観察として記録しておきます。Q2では、thinking_level = lowが10点、thinking_level = highが7点と、同じモデルでも設定によってスコアが異なりました（両者とも10回すべて同じスコアを返しており、決定性には問題ありません）。 Googleの公式ドキュメント によると、thinking_levelはモデルが費やす推論トークン数を制御するパラメータで、LOWはレイテンシとコストを最小化、HIGHは推論の深さを最大化する設定です。HIGHでは回答をより多角的に検討するため、LOWでは見落とされる問題点を検出し、スコアに反映させた可能性があります。 まとめ 本検証では、LLM-as-a-Judge における評価結果の「 決定性 」に焦点を当て、その挙動を確認しました。主な結果は以下の通りです。 gemini-2.5-pro: temperature=0、seed=42 固定条件下でも、評価結果に揺らぎが確認された。 gemini-3-pro-preview: 今回の検証範囲内では、決定論的な挙動（常に同じ結果）を示した。 注意点: gemini-3-pro-preview であっても、条件や入力内容によっては揺らぎが生じる可能性は否定できない。 LLM-as-a-Judge を実運用に組み込む際は、「モデルによって決定性のレベルが異なる」という前提に立ち、それを見越した設計・運用を行うことが重要です。具体的には、本番採用前に決定性を検証する、複数回評価の集約を検討する、評価基準を明確化する、といった対策が有効です。 今後は、質問数を増やしたより統計的な検証や、Claude、GPT、ローカル LLM など、他モデルとの比較検証にも範囲を広げていきたいと考えています。 決定性は地味なテーマではありますが、評価運用の信頼性を支える重要な基盤です。本検証は小規模ながら、運用上の不安を軽減する一歩になったと考えています。

MathJax={tex:{inlineMath:[['$','$']],displayMath:[['$$','$$']],processEscapes:true}}; こんにちは、Insight Edgeでデータサイエンティストをしている新見です。 cuTile Pythonとは 背景 特徴 従来のCUDA（SIMT）との違い 文法 TileGymで行列積ベンチマーク 倍精度行列積エミュレーション Ozaki Schemeについて 分解(Split) 行列積の計算 素朴な実装と初回結果 最適化 Fast Mode（GEMMの削減） Fused Split Kernel（分割の融合） 最適化後の結果 dによる精度/速度トレードオフ まとめ 参考文献 今回はNVIDIAが発表したばかりの「cuTile Python」を試してみました。普段は、GPUカーネルを業務で書くことはありませんが、cuTileはPythonで書かれていて、文法もシンプルなようなので、GPUプログラミングの勉強の意味も含めて記事にしました。 cuTile Pythonとは cuTile Pythonは、NVIDIA GPU向けの新しい並列プログラミングモデル「cuTile」をPythonから使うためのDSL（ドメイン固有言語）です。 背景 GPU上で高速に動作する処理を自前で記述したい場面は増えていますが、CUDA C++の習得コストは依然として高いのが実情です。 PyTorchやcuBLASといった高レベルAPIで日常的な開発は十分カバーできるものの、LLM推論の最適化など低レイヤへの介入が求められる局面も増えてきました。NVIDIA Ampere世代以降のGPUではTensor CoreやTMA（Tensor Memory Accelerator）といったハードウェア機能が追加されており、これらを十分に活用するにはより踏み込んだプログラミングが必要になります。 しかし、ハードウェアを意識したコードを書く難易度は上がり続けています。メモリ階層ひとつ取っても、共有メモリ、レジスタ、Blackwell世代で追加されたTensor Memoryなど、用途に応じて使い分ける必要があり、それぞれの特性に合わせたデータ配置や転送の制御が求められます。 さらに、特定のアーキテクチャに最適化したコードは新しい世代のGPUが登場した途端に書き直しが必要になることも多く、保守コストも無視できません。 こうした背景から、ハードウェアの詳細を抽象化しつつ高い性能を引き出すDSLへの需要が高まっています。OpenAIの gpt-oss リポジトリでもTritonという同様のDSLが採用されており、この手のアプローチは業界でも広く注目されています。 特徴 GPUプログラミングには、cuBLASやPyTorchのような高レベルライブラリか、CUDA C++やPTXといった低レベルなスレッド制御か、という二極化がありました。cuTileはこの中間に位置する「Tileレベル」のプログラミングモデルです。 抽象レベルについて（動画[1]より） 以下、動画[1]で紹介されていた特徴になります。 CUDAプラットフォームにネイティブ統合 : OpenAI Tritonなどサードパーティ製DSLとは異なり、cuTile（Tile IR）はCUDAドライバに組み込まれています。既存のプロファイラやデバッガがそのまま使えます。 Tile IRへのコンパイル : Pythonで書いたカーネルは「Tile IR」という仮想ISAに変換され、ドライバが実行時にターゲットGPUに合わせた最適なマシンコード（SASS）を生成します。 技術スタックの階層構造、TileIRはPTXを置き換えるのではなく共存する（動画[1]より） 従来のCUDA（SIMT）との違い 従来のCUDA（SIMT: Single Instruction, Multiple Threads）とcuTileでは、プログラマが何を書いて何をシステムに任せるかが大きく異なります。 特徴 従来のCUDA (SIMT) cuTile (Tile-based) 実行単位 スレッド単位でデータ処理を記述。WarpやBlockの構成を意識する必要がある データの塊（タイル）と単一の実行単位（ブロック）で思考。スレッドへの分解はシステムが行う データ処理 個々のスレッドへのデータ分配（ストライディングなど）を手動で計算・管理 タイル（配列全体の一部）を一つの単位としてロード・演算・ストア メモリ管理 共有メモリの確保、同期（バリア）、バンクコンフリクト回避などをユーザーが管理 システムが管理。共有メモリの利用や同期は自動化され、ユーザーからは隠蔽 ハードウェア活用 Tensor Coreなどを使うには複雑なPTX命令や特定のレイアウトを意識する必要がある ct.load や演算子を書くだけでTMAやTensor Coreを自動的に活用 文法 cuTile Pythonは、Pythonのデコレータと専用の型システムを使って記述します。詳しくは公式ドキュメント[2]を参照してください。 主な特徴: @ct.kernel デコレータ : Python関数をGPUカーネルとしてマーク。関数内ではcuTile Pythonの文法に従う。 イミュータブルなタイル : カーネル内では、タイルが操作対象となる。タイルは「値」として扱われ、変更不可。演算すると新しいタイルが生成されます Array (Global Memory): 引数から取得、ミュータブル。 ct.load / ct.store でアクセス Tile (Local/Register): イミュータブルで演算対象 以下、ベクトル加算のコード例です。 import cuda.tile as ct # タイルサイズはコンパイル時定数 TILE_SIZE = 16 @ ct.kernel def vector_add_kernel (a, b, result): # 1. 現在のブロックIDを取得 (スレッドIDではない！) block_id = ct.bid( 0 ) # 2. グローバルメモリ(Array)からタイルとしてデータをロード # システムが自動的に最適なメモリ転送(TMA等)を行う a_tile = ct.load(a, index=(block_id,), shape=(TILE_SIZE,)) b_tile = ct.load(b, index=(block_id,), shape=(TILE_SIZE,)) # 3. タイル同士の演算 (要素ごとの加算が一括で行われる) result_tile = a_tile + b_tile # 4. 結果をグローバルメモリにストア ct.store(result, index=(block_id,), tile=result_tile) # ホスト側からの実行 # ct.launch(stream, grid_dim, kernel_func, args) ブロックごとに同一のカーネルが実行され、各ブロックはIDで指定されたデータを担当範囲として、処理を行います。タイル演算は、感覚としてはnumpyの処理に似ています。 TileGymで行列積ベンチマーク 実際に動かします。cuTileはCUDA Toolkit13.1以降が必要で、これはBlackwell世代以降の比較的最新のGPUでしか動かないようです。私は手元に最新のGPUがないので、クラウドサービスを利用したいと思います。今回は、 Modal と呼ばれるGPU特化のクラウドサービスを利用しました。 Modalは関数ベースでGPUインスタンスを立ち上げられるサービスになります。使い勝手がよく、便利です。実行時間に応じた従量課金制で、今回の検証のような少しGPUを試してみたい場合に適しています。 今回は、公式のサンプルレポジトリTileGym[3]をベースに、行列積のコードの実行をしてみます。Modalで走らせる実行コードを以下に示します。imageでDockerイメージを作成し、TileGymのレポジトリをクローン、ライブラリインストールを行います。Modalの詳細は ドキュメント を参照してください。今回対象のGPUはB200です。 # run-tilegym.py import modal image = ( modal.Image.from_registry( "nvidia/cuda:13.1.0-devel-ubuntu24.04" , add_python= "3.13" ) # CUDA 13.1開発環境イメージ .apt_install( "git" ) .run_commands( "pip install --pre torch --index-url https://download.pytorch.org/whl/cu130" ) # PyTorchインストール、比較のため .run_commands( "git clone https://github.com/NVIDIA/TileGym.git && cd TileGym && pip install -e ." ) # cuTile, TileGymインストール .entrypoint([]) ) app = modal.App( "tilegym-test" ) @ app.function (gpu= "B200" , image=image, timeout= 600 ) def run_mma_bench (): import os os.chdir( "/TileGym" ) os.system( "python tests/benchmark/bench_matrix_multiplication.py" ) @ app.local_entrypoint () def main (): run_mma_bench.remote() 上のコードをrun-tilegym.pyとして保存し、 modal run run-tilegym.py で実行します。問題なければ結果は、以下のように出力されるはずです。 matmul-performance-float16-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 271.056760 473.522850 1 2048.0 2048.0 2048.0 1129.688506 1199.365877 2 4096.0 4096.0 4096.0 1235.696555 1401.341171 3 8192.0 8192.0 8192.0 1483.030888 1253.946946 4 16384.0 16384.0 16384.0 1356.600018 1536.098446 5 32768.0 32768.0 32768.0 1254.836929 1306.057063 matmul-performance-float8_e5m2-TFLOPS: M N K CuTile 0 1024.0 1024.0 1024.0 277.309352 1 2048.0 2048.0 2048.0 1154.454102 2 4096.0 4096.0 4096.0 2769.415226 3 8192.0 8192.0 8192.0 2981.168986 4 16384.0 16384.0 16384.0 2935.864636 5 32768.0 32768.0 32768.0 2658.604232 CuTileとPyTorchの行列積のベンチマークが出ています。float16とfloat8_e5m2の両方で行列積を実行していますが、PyTorchでは、後者の行列積が未対応のようです。PyTorchは裏側でcuBLASを呼び出しているので実質cuBLASとの比較です。float16では、CuTileはPyTorchに近い性能、一部のサイズでは、PyTorchを上回る性能が出ています。float8_e5m2では、行列サイズが4096以上でfloat16の約2倍の性能が出ています。 以下が TileGym/src/tilegym/ops/cutile/matmul.py の行列積のカーネルコードの抜粋です。 @ ct.kernel (num_ctas=ct.ByTarget(sm_100= 2 )) def matmul_kernel (A, B, C, TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, TILE_SIZE_K: ConstInt): # 担当タイルのインデックス計算（L2キャッシュ局所性のためswizzle） bidx, bidy = swizzle_2d(A.shape[ 0 ], B.shape[ 1 ], TILE_SIZE_M, TILE_SIZE_N, GROUP_SIZE_M= 8 ) num_tiles_k = ct.num_tiles(A, axis= 1 , shape=(TILE_SIZE_M, TILE_SIZE_K)) # FP32アキュムレータの初期化（FP16入力でも精度維持のためFP32で累積） accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0 , dtype=ct.float32) # FP32→TF32変換（Tensor Coreを利用するため） dtype = ct.tfloat32 if A.dtype == ct.float32 else A.dtype # K方向にタイル単位でループ for k in range (num_tiles_k): a = ct.load(A, index=(bidx, k), shape=(TILE_SIZE_M, TILE_SIZE_K), padding_mode=ct.PaddingMode.ZERO).astype(dtype) b = ct.load(B, index=(k, bidy), shape=(TILE_SIZE_K, TILE_SIZE_N), padding_mode=ct.PaddingMode.ZERO).astype(dtype) accumulator = ct.mma(a, b, accumulator) # 行列積計算・累積 # 出力型に変換して結果を書き出し ct.store(C, index=(bidx, bidy), tile=ct.astype(accumulator, C.dtype)) A:MxK @ B:KxN -> C:MxN の行列積で、M方向、N方向単位でバッチに切り分けCの部分タイルごとに並行して実行されます。K方向にも部分分割して、順次読み込み(load), 行列積計算(mma), 結果の保存(store)を行っています。cuTile側でメモリの種類やMMA命令の選択は書く必要がなく、コンパイル時に自動的に最適化されます。 このように簡潔に書いても、ゴリゴリにチューニングしているcuBLASに匹敵した性能を出しているというのがcuTileの売りなようです。 ベンチマークを動かしただけでは面白くないので、型の精度を少し上げて同様の計算をしてみます。F32演算の場合、上記コードでは行列をTF32に変換してから計算しています。それと合わせるため、PyTorch側も以下のようにTF32を有効化します。 # TileGym/tests/benchmark/bench_matrix_multiplication.py # Enable TF32 for PyTorch to match Tensor Core behavior torch.backends.cuda.matmul.allow_tf32 = True torch.backends.cudnn.allow_tf32 = True また、FP64演算にあたり、累積の型がFP32では精度が足りないため、cutileコード側で累積の型をFP64に変更する処理を追加しています。 # Initialize an accumulator for the current output tile (TILE_SIZE_M x TILE_SIZE_N). # Use float64 for float64 inputs, otherwise float32 for higher precision accumulation. acc_dtype = ct.float64 if A.dtype == ct.float64 else ct.float32 accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0 , dtype=acc_dtype) 以下が修正後のベンチマーク結果です。 matmul-performance-float32-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 208.295471 294.114105 1 2048.0 2048.0 2048.0 665.976324 648.103430 2 4096.0 4096.0 4096.0 698.961883 747.326296 3 8192.0 8192.0 8192.0 783.858756 761.237840 4 16384.0 16384.0 16384.0 856.688401 742.126004 matmul-performance-float64-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 0.855789 26.687611 1 2048.0 2048.0 2048.0 1.063844 33.830530 2 4096.0 4096.0 4096.0 1.124713 35.400544 3 8192.0 8192.0 8192.0 1.124824 35.438650 FP32では、PyTorchに近い性能が出ています。一方、FP64では、cuTile側での最適化がまだ不十分なようで、PyTorchに大きく劣る結果となっています。TILE_SIZEをより小さく設定することで、1.6 TFLOPS程度には改善しましたが、まだ大きく劣っています。 原因としては、cuTileの ct.mma がFP64演算に対して効率的な命令へマッピングできていない可能性が高いです。cuBLAS（PyTorch）はFP64 Tensor Coreを含むハードウェアリソースを最大限に活用した成熟した実装を持っており、この差が性能差に直結しています。 ここで、FP64演算の性能を向上させるために、Ozaki Schemeと呼ばれる倍精度行列積エミュレーション手法を試してみます。 倍精度行列積エミュレーション Ozaki Schemeについて Ozaki Schemeは、FP64の行列積をFP64演算なしで高精度にエミュレートする手法です[4][5]。詳しくは元の論文を読んでほしいのですが、概要を説明します。基本的なアイデアは、FP64行列を複数の低精度行列に分解し、Tensor Coreで高速に行列積を計算するというものです。行列の分解、行列の計算、結果の累積の3段階で構成されます。 分解(Split) 論文に従い、以下の型を定義します。 Type1 (FP64): 元の行列の精度。仮数部 $m_{\text{Type1}} = 53$ ビット Type2 : 分解先の低精度型（BF16, FP16, FP8等）。仮数部 $m_{\text{Type2}}$ ビット（隠れビット含む） Type3 (FP32): Tensor Coreの累積精度。仮数部 $m_{\text{Type3}} = 24$ ビット Type1の行列 $\boldsymbol{x}$ を、残差 $\boldsymbol{x}^{(p)}$ がゼロになるまで再帰的にType2スライス $\bar{\boldsymbol{x}}^{(p)}$ に分解します。$\boldsymbol{x}^{(1)} = \boldsymbol{x}$ として、各ステップ $p$ で以下を行います。 $$c_x^{(p)} = \left\lceil \log_2 \left( \max_i \left| x_i^{(p)} \right| \right) \right\rceil \tag{1}$$ $$\sigma = 0.75 \cdot 2^{\rho + c_x^{(p)}} \tag{2}$$ $$v_i = \text{fl}_{\text{Type1}} \left( \left( x_i^{(p)} + \sigma \right) - \sigma \right) \tag{3}$$ $$x_i^{(p+1)} = \text{fl}_{\text{Type1}} \left( x_i^{(p)} - v_i \right) \tag{4}$$ $$\bar{x}_i^{(p)} = \text{cvt}_{\text{Type2}} \left( \text{fl}_{\text{Type1}} \left( 2^{-c_x^{(p)}} v_i \right) \right) \tag{5}$$ ここで $\rho$ は精度パラメータ（Type1, Type2, Type3の仮数部ビット数と内積次元 $k$ から決定）です。$\sigma$ を足して引く操作（式3）がVeltkamp分割の核心で、上位 $m_{\text{Type2}}$ ビットを正確に抽出します。式4で残差を更新し、式5で $2^{c_x^{(p)}}$ で正規化してType2スライスを得ます。 この結果、$\boldsymbol{x}$ は $s_x$ 個のスライスに分解されます。 $$\boldsymbol{x} = \sum_{p=1}^{s_x} 2^{c_x^{(p)}} \cdot \bar{\boldsymbol{x}}^{(p)} \tag{9}$$ $c_x^{(p)}$ が指数部、$\bar{\boldsymbol{x}}^{(p)}$ が仮数部に対応します。スライス数 $s_x$ は $\boldsymbol{x}^{(p)} = 0$ になるまでの反復回数で決まり、理論的には $\lceil m_{\text{Type1}} / m_{\text{Type2}} \rceil$ ステップですが、行列要素のスケールのばらつきにより多くなることがあります。 PyTorchでの実装は以下の通りです。 def ozaki_split_to_type2_slices (x, k, type2, max_slices= 20 ): # 仮数部ビット数（隠れビット含む） m_fp64, m_fp32 = 53 , 24 m_type2 = - int (math.log2(torch.finfo(type2).eps)) + 1 # 精度パラメータ ρ の計算 gamma = math.ceil(m_fp64 - (m_fp32 - math.log2(k)) / 2 ) xi = m_fp64 - m_type2 rho = max (gamma, xi) slices = [] residual = x.clone().to(torch.float64) for _ in range (max_slices): max_abs = residual.abs().max().item() if max_abs == 0 or max_abs < 1e-300 : break c_x = math.ceil(math.log2(max_abs)) # 式(1) sigma = 0.75 * math.ldexp( 1.0 , rho + c_x) # 式(2) v = (residual + sigma) - sigma # 式(3) Veltkamp分割 residual = residual - v # 式(4) 残差更新 scale = math.ldexp( 1.0 , c_x) slice_type2 = (v / scale).to(type2) # 式(5) 正規化 + Type2変換 slices.append((slice_type2, scale)) return slices # [(Type2スライス, 2^c_x), ...] 行列積の計算 行列 $\boldsymbol{x}$, $\boldsymbol{y}$ をそれぞれ分解すると、行列積は以下のように展開できます。 $$\boldsymbol{x}^T \boldsymbol{y} = \sum_{p=1}^{s_x} \sum_{q=1}^{s_y} 2^{c_x^{(p)} + c_y^{(q)}} \cdot \bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} \tag{10}$$ 各 $\bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)}$ はType2行列同士の積であり、Tensor CoreのGEMMで計算できます。Ozaki Schemeではρパラメータにより、このGEMMのType3（FP32）での累積が丸め誤差なしで成立するよう設計されています。 $$\bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} = \text{fl}_{\text{Type3}} \left( \bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} \right) \tag{11}$$ 式10の分解自体は数学的な恒等式として厳密に成立します。実装上は、外側の累積（スケール乗算と加算）をType1算術で行うことでType1精度を達成できます。 cuTileでの行列積カーネルの実装は以下の通りです。tilegymのmatmulカーネルとベースは同じで２つのスライス分のouter-loopが追加されています。 @ ct.kernel (num_ctas=ct.ByTarget(sm_100= 2 )) def ozaki_matmul_fused_kernel ( A_slices, # (s_a, M, K) Type2スライス B_slices, # (s_b, K, N) Type2スライス Combined_scales, # (s_a, s_b) 2^{c_x(p)+c_y(q)} のスケール行列 C, # (M, N) FP64 出力 TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, TILE_SIZE_K: ConstInt, ): # タイルインデックス計算（L2キャッシュ局所性のためswizzle） bidx, bidy = swizzle_2d(M, N, TILE_SIZE_M, TILE_SIZE_N, GROUP_SIZE_M= 8 ) num_tiles_k = ct.cdiv(K, TILE_SIZE_K) # FP64最終アキュムレータ（式10の外側の累積） accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0.0 , dtype=ct.float64) # 全スライスペア (p, q) をループ for p in range (num_slices_a): for q in range (num_slices_b): # FP32中間アキュムレータ（式11: Type3での丸め誤差なし計算） slice_acc = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0.0 , dtype=ct.float32) # K方向のタイルループ for k in range (num_tiles_k): a_tile = ct.load(A_slices, index=(p, bidx, k), ...) b_tile = ct.load(B_slices, index=(q, k, bidy), ...) slice_acc = ct.mma(a_tile, b_tile, slice_acc) # Type2 Tensor Core MMA # スケーリングしてFP64で累積（式10） scale = ct.load(Combined_scales, index=(p, q), shape=( 1 , 1 )) accumulator = accumulator + ct.astype(slice_acc, ct.float64) * scale ct.store(C, index=(bidx, bidy), tile=accumulator) 素朴な実装と初回結果 上記のようにOzaki Schemeを実装してみます。スライス分割はホスト側のpythonで行い、各ペアのGEMMを順次実行する方式です。以下、2種類のType2で行列積を計算した結果です。 スライス数はA・Bそれぞれの分割数（$s_a \times s_b$）、GEMMsはその組み合わせで実行したGEMM回数です。TFLOPSはFP64換算のスループット、Rel ErrorはPyTorch FP64結果を基準とした相対誤差です。 TYPE2 = FP16 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 10×10 100 1.48 0.62 2.64 0.81 1.58e-15 2048 12×12 144 2.57 2.66 5.75 2.99 1.98e-15 4096 12×12 144 8.69 21.59 30.70 4.48 6.31e-15 8192 14×14 196 36.00 192.32 231.76 4.74 7.28e-15 16384 14×14 196 135.21 1737.14 1884.24 4.67 3.35e-15 TYPE2 = FP8 (E4M3) 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 15×16 240 2.22 1.11 4.03 0.53 1.64e-15 2048 16×16 256 3.48 3.11 7.33 2.34 2.27e-15 4096 16×17 272 12.30 19.17 30.86 4.45 5.69e-15 8192 17×17 289 45.64 179.99 226.64 4.85 8.88e-15 FP16はスライス数が少ない分GEMMも少なくなりますが、FP8はTensor Coreのスループットが高いため、GEMMs数が多いにも関わらず類似の性能が出ています。いずれの型でもcuTile FP64直接計算（約1 TFLOPS）を上回っていますが、PyTorchの性能には大きく劣後しています。Split処理の時間も無視できず、特に小さな行列サイズでボトルネックになっています。また、参照した論文に記載されている必要なGEMM数(スライス数）よりも多くなっている点は気になりましたが、原因はわからずでした。 最適化 初回結果を踏まえ、いくつか改善を試みました。その中で効果があった方法が以下になります。 Fast Mode（GEMMの削減） スライス数が $s$ の場合、全組み合わせで $s^{2}$ 回のGEMMが必要です。しかし、スライスインデックスが大きい組み合わせ（$i + j \geq d$）は寄与が小さいため、スキップできます。 [5]で提案されたFast Mode（Algorithm 3）では、確率的誤差限界 $|fl(AB) - AB| \leq 2\sqrt{k} \cdot u_{\text{FP64}} \cdot |A||B|$ を満たす最小の閾値 $d$ を自動決定します。 BF16の場合、典型的には $d = 9$ 程度で、GEMMは49回から39回に削減できます。さらに max_d パラメータで手動上限を設定すれば、精度とのトレードオフで計算量を調整できます。 実装としては、前述の行列積カーネルのスライスペアループに i + j >= D の条件を追加するだけです。 for i in range (num_slices_a): for j in range (num_slices_b): if i + j >= D: # Fast Mode: 寄与の小さい組み合わせをスキップ continue # ... K方向ループでMMA計算 ... Fused Split Kernel（分割の融合） 元の実装では、各スライスの計算ごとに max().item() でGPU→CPU同期が発生していました（BF16で7スライス = 7回の同期）。 改善後は、初回の max_abs 計算で1回だけ同期し、全スライスの $\sigma$ と $2^{-c_i}$（逆スケール）をCPU側で事前計算します。その後、単一カーネルで全スライスを一括計算します。 @ ct.kernel (occupancy= 4 ) def _veltkamp_split_all_slices_kernel ( x_in, # (M, N) FP64 input slices_out, # (num_slices, M, N) TYPE2 output slices sigmas, # (num_slices,) FP64 pre-computed sigma values inv_scales, # (num_slices,) FP64 pre-computed 1/scale values num_slices: ConstInt, TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, ): bid = ct.bid( 0 ) # ... (タイルインデックス計算) ... # 入力タイルをロード residual = ct.load(x_in, index=(tile_m, tile_n), shape=(TILE_SIZE_M, TILE_SIZE_N), padding_mode=ct.PaddingMode.ZERO) # 全スライスをループで計算 for i in range (num_slices): sigma_tile = ct.load(sigmas, index=(i,), shape=( 1 ,)) inv_scale_tile = ct.load(inv_scales, index=(i,), shape=( 1 ,)) # Veltkamp分割 v = (residual + sigma_tile) - sigma_tile slice_tile = ct.astype(v * inv_scale_tile, slices_out.dtype) ct.store(slices_out, index=(i, tile_m, tile_n), tile=ct.reshape(slice_tile, ( 1 , TILE_SIZE_M, TILE_SIZE_N))) residual = residual - v 最適化後の結果 Fast Mode + Fused Split Kernelを適用した結果です。 TYPE2 = BF16 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 7×7 39 0.20 0.25 1.57 1.37 5.75e-15 2048 7×7 39 0.24 0.75 2.16 7.94 1.30e-14 4096 7×7 39 0.43 5.32 7.22 19.04 1.16e-14 8192 7×7 39 1.16 38.93 42.60 25.81 2.39e-14 16384 7×7 39 3.96 323.10 327.78 26.84 2.21e-14 TYPE2 = FP8 (E4M3) 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 14×14 130 0.25 0.61 2.99 0.72 3.48e-13 2048 14×14 130 1.27 1.60 6.80 2.52 3.57e-13 4096 14×14 130 2.13 9.31 15.88 8.65 3.41e-13 FP8はスライス数が多く（14×14）GEMMsも130回と多いものの、Fast ModeによるGEMM削減とFused Splitの効果で素朴な実装（4096で4.45 TFLOPS）から改善が見られます。ただしBF16と比較すると、仮数部が4ビットと少ないためスライス数が増え、GEMMs数の差（130 vs 39）がFP8のスループット優位を打ち消しており、BF16の方が総合的に有利になりました。 素朴な実装と比較すると、最適化の効果は顕著です。 Fused Split Kernel : Split時間が大幅短縮（素朴なFP16版 8192: 36.00ms → BF16最適化版: 1.16ms、約31倍） Fast Mode : GEMMsを49→39に削減（BF16の全組み合わせ比） BF16がTYPE2として最適である理由は、Tensor CoreのFP32アキュムレータとの相性にあります。BF16の仮数部は8ビットなので、2つのBF16値の積は16ビットに収まります。FP32の仮数部は24ビットあるため、TILE_SIZE_K=128個の積和（16 + log2(128) = 23 ≤ 24）が 丸め誤差なし で正確に計算できます。一方FP16（11ビット仮数部）では積が22ビットとなり、128個の累積（22 + 7 = 29 > 24）でFP32精度を超えるため、丸め誤差が発生します。 この性質により、BF16では1e-14というFP64に近い精度を維持しつつ、Tensor Coreの高いスループットを活用できています。 上記以外にも、タイルサイズの調整や、カーネル内のsplitループ方向のCTA分散も試みましたが、効果はありませんでした。本来は、プロファイラ（NVIDIA Nsight Compute）を使って、メモリ利用等解析するのが効果的ですが、Modal上ではNsightは使えないようなので断念しました。 dによる精度/速度トレードオフ d パラメータを変えて、16384×16384行列での性能と精度の変化を測定しました。BF16の結果です。 d GEMMs 合計(ms) TFLOPS Rel Error vs PyTorch FP64 9 (default) 39 327.78 26.84 2.21e-14 0.75x 8 34 298.76 29.44 2.31e-14 0.83x 7 28 238.94 36.81 3.50e-13 1.03x 6 21 189.59 46.40 4.39e-11 1.30x 5 15 136.34 64.52 4.51e-09 1.81x PyTorch FP64（cuBLAS）は同サイズで35.62 TFLOPSです。Rel ErrorはPyTorch FP64の結果を基準として計算しています。 d=7 でcuBLASと同等の速度を精度1e-13で達成し、 d=5 では1.8倍の高速化を1e-9精度で実現しています。なお、FP64 GEMM自体も浮動小数点演算の性質上、行列サイズに応じた丸め誤差は避けられないため、 d=8 （2.31e-14）程度の偏差であれば実用上十分でしょう。 まとめ cuTile Pythonの簡単な紹介とOzaki Schemeの実装を通じて、FP64行列積の高速化を試みました。BF16 Ozaki Schemeの最適化後、16384×16384行列で最大26.84 TFLOPS（d=9）を達成しました。dを調整することで精度と速度のトレードオフが可能で、d=7ではcuBLAS FP64（35.62 TFLOPS）と同等の36.81 TFLOPSを精度1e-13で達成し、d=5では64.52 TFLOPS（cuBLASの1.8倍）を1e-9精度で実現しています。 CUDAカーネルをPythonライクに書ける点で、GPUプログラミングの敷居が低くなったと感じます。 一方で、より高度な最適化やチューニングが必要な場合は、cuTile Pythonは抽象化してハード側の詳細を隠蔽している分、制約があるように感じました。今回は、行列積の例でしたが、tilegymにはtransformerの実装例があるので、次回はそちらも試してみたいと思います。 参考文献 [1] Lecture 89: cuTile (from friends at NVIDIA) [2] NVIDIA cuTile Documentation . cuTile Python. [3] NVIDIA TileGym . GPU Tile kernel development examples using cuTile. [4] Markus Höhnerbach, Paolo Bientinesi (2025). "DGEMM without FP64 Arithmetic" . arXiv:2508.00441. [5] Daichi Mukunoki, Katsuhisa Ozaki, Takeshi Ogita, and Toshiyuki Imamura (2020). "DGEMM using Tensor Cores, and Its Accurate and Reproducible Versions". ISC High Performance 2020, Lecture Notes in Computer Science, Vol. 12151. Springer, 230–248. doi:10.1007/978-3-030-50743-5_12

こんにちは！Insight Edge リードコンサルタントの山田です。 私は普段から事業会社におけるAI/デジタル活用のご相談を多く受けているのですが、この記事では、生成AIで解くべきではない課題にフォーカスしながら、業務活用における生成AIの向き/不向きを整理してみたいと思います。 AI活用があらゆる企業で経営マターに 生成AI活用の肝は“課題選定” 業務パターンごとの生成AIとの相性を理解する ①定型プロセス × 許容幅 広い　—— 　◎生成AIの得意領域 ②非定型プロセス × 許容幅 広い　——　◎生成AIの本領を発揮しやすい ③定型プロセス × 許容幅 狭い　——　△AIが適切でないケースあり ④非定型プロセス × 許容幅 狭い　——　★設計次第では効果大 AIには得意なことだけをやらせる 例：投資判断プロセス 相性がよいパターンであっても、「プロセスの長さ」には注意 実際の業務で適切な課題を設定するために AI活用があらゆる企業で経営マターに 2025年はAIエージェント元年ともいわれ、企業における生成AIやAIエージェントに関する活用事例はさらに増えました。「AI活用」が経営アジェンダの最上位マターに位置付ける企業も珍しくなくなり、弊社でも引き続きAIエージェント開発、AI CoE組織立ち上げ、教育/ワークショップなど、多岐にわたるAIプロジェクトを推進しています。 事業会社の経営層との会話でも「AIで何かできないか」というご相談は本当に多くいただいていますし、経営トップが旗を振ってAI活用を推進するケースも目に見えて増えてきました。 具体的には 前回記事 でもご紹介したような社内ナレッジ検索や投資判断への意思決定支援に加え、この1年はマルチAIエージェントによる事業開発・投資判断高度化プロジェクトなど、目に見える成果が出ている領域は確実に広がっています。 生成AI活用の肝は“課題選定” 一方で、様々な場面でAI活用ユースケースが生まれ、世の中がAIエージェント一色の状況でよくあるのが、「ハンマーを持つとすべてがクギに見える」ような、すべての業務課題にAIエージェントを適用しようとしてしまうことです。 Nano Banana Proを利用して作成 属人化している業務をAIがいい感じに判断し実行してほしい 一連の業務フローをAIで自動化したい このようなニーズも少なくないのですが、業務プロセスが明確でなかったり、業務知見や商習慣など考慮すべきコンテキストが与えられない状況だと、意図するアウトプットを得ることは非常に難しいです。 AIは強力なツールである一方で、向いていない/苦手な業務に適用しようとすると、期待した効果や精度が出ず、「業務では使えない」という判断になってしまうことにもなりかねません。AIの技術的な問題というより課題設定の問題であるにも関わらず、AI＝使えないとなってしまうのが一番もったいないです。実際の業務においてはAIが向いているパターン、向いていないパターンがあり、課題選定の段階で正しいテーマ設定をすることが、生成AI活用がうまくいくための第一歩です。 業務パターンごとの生成AIとの相性を理解する 効率化・高度化したい業務においてAI活用するべきかを考える上で、以下の２つの軸で業務を分類することが有効です。 軸１：業務プロセスの定型度（定型 vs非定型 ） 手順やルールが決まっているか、状況に応じてプロセス自体が変わるか 軸２：アウトプットの許容幅（広い vs 狭い） だいたい合っていればOK（面的）か、正解が一意（点的）か Nano Banana Proを利用して作成 ①定型プロセス × 許容幅 広い　—— 　◎生成AIの得意領域 業務プロセスの手順が決まっていて、出力も「だいたい合っていればOK」な業務。生成AIの導入効果が出やすく、個人/組織の身近な業務で恩恵を感じやすいです。 会議の議事録要約 日報など定型レポート生成 FAQ・問い合わせへの一次回答 コード生成・リファクタリング ②非定型プロセス × 許容幅 広い　——　◎生成AIの本領を発揮しやすい プロセスも出力も「これが正解」が決まっておらず、アウトプットの幅の広さが価値となる業務。生成AIの柔軟性が最も活きる場面であり、使い方次第で効果が大きく変わってくる領域です。 新規事業・企画のアイデア出し 戦略仮説の壁打ち・論点整理 プロダクトのUX改善案出し ペルソナ作成・ユーザーシナリオ生成 ③定型プロセス × 許容幅 狭い　——　△AIが適切でないケースあり 手順もルールも明確で、出力もブレてはいけない業務。この領域はルールベースやRPAなど従来型システムでシステム的に処理した方が適切なケースも多く、わざわざ確率的な振る舞いをするAIが最適とは限らない領域です。 経費精算・請求処理のデータ入力 発注・検収処理 条件分岐が明確な承認フロー判定 ④非定型プロセス × 許容幅 狭い　——　★設計次第では効果大 プロセスに決まった正解がなく状況に応じた判断が必要かつ、アウトプットには高い正確性が求められる業務。適切にワークさせる難易度が高い一方、設計次第ではAIによる恩恵が大きい領域です。 投資判断や経営の意思決定（Go/No-Go） 個別事象を加味した契約書レビュー 与信審査の最終判定 カントリーリスク評価やDDレポート生成 AIには得意なことだけをやらせる ③や④のような、出力の許容幅が狭い（≒正確性が求められる）パターンでも、設計次第で十分業務に活用できます。AIには得意なことだけをやらせる、逆に言えば苦手なことは何らか別の方法で補完することで、一連の業務を品質高く実行できます。 RAGや外部ツール利用による知識補完/スキル補完、人間のレビューを「仕組み」として組み込むこと（Human-in-the-Loop）などが有効です。 例：投資判断プロセス 情報収集・整理フェーズ（AI） 対象企業/マーケットに関する外部情報や社内の案件資料をRAGで検索し、様々な情報を収集・整理したり、過去の類似投資案件の議事録などをもとに当時議論された論点を抽出する 定量分析フェーズ（従来型システム） 財務モデルに基づくバリュエーション算出、感応度分析、各種指標の計算。「数字を正確に出す」ことが求められるため、ルールベースの計算エンジンを使用 論点整理・リスク洗い出しフェーズ（AI） 収集した情報と定量分析の結果を踏まえ、検討すべきリスク論点を構造化して提示する。「過去の類似案件ではカントリーリスクが争点になった」「この業界ではこの規制変更が影響しうる」など、人間が見落としやすい観点を補完する。 意思決定フェーズ（人間） AIが整理した判断材料と従来型システムが算出した定量データを踏まえ、Go/No-Goを最終決定する。 Nano Banana Proを利用して作成 相性がよいパターンであっても、「プロセスの長さ」には注意 また、いずれのパターンにおいても業務プロセスが長く連鎖する場合は、うまくいかないケースが出てきます。AIの出力は確率論でしかないので、1ステップの精度が90%であっても、それが10回続くとすべて成功する確率は35%まで下がります。プロセス全体を一気通貫でAIに実行させるのではなく、AIのタスクを分解してモジュール化（カタマリ化）し、各モジュールの間で人間の確認ポイントを挟むことで、全体の精度を担保する業務設計が必要になります。 実際の業務で適切な課題を設定するために とはいえ、実際の業務は複数のステップや要素が絡み合っているので、そのままマトリクスに当てはめられるほど単純ではないことがほとんどです。現場でAI活用の課題設定を行う際には、 ①業務プロセスを分解して可視化する 属人的/暗黙知化しているプロセス含め、業務フローを洗い出す ②ステップごとに「出力の許容幅」を確認する だいたい合っていればOKなのか、確実な正解が必要か ③AIと人間の役割分担を設計する 人が介在する余地を残し、AIにすべてを任せない この辺りを意識して業務を見直し、AI活用する場合の業務フローを設計していくことが重要です。ある意味地味なプロセスですが、業務で使われるAIを作るためにはとても重要なポイントだと思います。

はじめに みなさん、こんにちは😊 Insight EdgeでUIUXデザイナーをしている酒井です！ 2020年のコロナ禍以降、オンラインでの会議が主流になった昨今ですが、オンライン会議で「ちゃんと関係者全員で話をしたはずなのに、後から認識がズレていた」と感じたことはありませんか？ 同じ言葉を使っていたのに、思い描いていたイメージは人それぞれ違っていた...そんな経験は、決して珍しくないはずです。 初めて聞くテーマや、普段あまり関わらない領域の話では、内容を正しく捉えるだけでも意外と難しいものです。 その中で起きやすいのが、 認識齟齬 です。 今回は、私がデザイナーとして実践している「見える化」を意識したファシリテーションをご紹介します。 声だけの議論に頼らず、 全員が同じものを見ながら会話する ことで、オンライン会議の質を高めるヒントになれば嬉しいです✨ なぜオンライン会議で認識齟齬が起きるのか？ オンライン会議では、相手の表情や場の空気感が読み取りづらくなります。 回線状況や環境の都合で、カメラオフのまま進むことも少なくありません。 その結果、私たちは「言葉」だけを頼りに話を理解しようとします。 しかし、言葉はとても曖昧です。同じ「業務フロー」「課題」「システム」という言葉でも、人によって思い浮かべる内容は違います。 さらにオンラインでは、参加者全員が同じ前提を持っているとは限りません。 立場や経験、背景知識の違いによって、理解の起点が少しずつズレていきます。 こうした状況が重なることで、次のような状態が起こりやすくなります。 各自が頭の中で別々のイメージを描いている 今どこの話をしているのか分からなくなる 重要な論点がどこなのか判断できない ズレに気づかないまま、会話が進んでしまう この背景にあるのが、 会話の構造が見えなくなっていること です。 話題が行ったり来たりしたり、現状の話と理想の話が混ざったり、 前提条件が共有されないまま議論が進んだりすると、話している本人は理解していても、聞いている側は「今どこの話？」と迷子になります。 特に抽象的な話題になるほど、このズレは表に出にくくなります。 1時間の会議で得られる情報は多くありません。 だからこそ、その限られた時間の中で 認識を揃えられるかどうか が、その後の進み方に大きく影響します。 認識齟齬がプロジェクトに与える影響 認識齟齬は、起きた瞬間に大きな問題として表に出ることはあまりありません。 むしろ、最初は「なんとなく分かっているつもり」のまま進んでしまうことが多いものです。 しかし、その小さなズレを抱えたまま進むと、プロジェクトの中で少しずつ影響が現れます。 まず起こりやすいのが、要件のブレです。 前提の理解が揃っていない状態で話が進むことで、 想定していたアウトプットと違うものが出てくる 後から「そういう意味ではなかった」と修正が入る のようなズレが生まれます。 その結果、手戻りが増え、スケジュールやコストにも影響が出てきます。 後になればなるほど、修正にかかる負担は大きくなりがちです。 「最初の会話で、もう少し丁寧に認識を揃えておけばよかった」 そう感じた経験は、誰しも一度はあるのではないでしょうか。 また、認識齟齬の影響は、成果物や進行面だけにとどまりません。 人やチームの状態 にも、じわじわと影響します。 自分の理解が合っているのか不安になる 「またズレていたらどうしよう...」と発言をためらってしまうようになる 確認や質問が減り、会話が表面的になる こうした状態が続くと、信頼や心理的安全性が下がり、結果として議論の質そのものが落ちてしまいます。 だからこそ、認識齟齬は「後から修正する問題」ではなく、 その場でできるだけ防ぐ ことが重要だと考えています。 会話で迷子にならないための“構造化”アプローチ そこで意識しているのが、リアルタイムでの構造化です。 会話を聞きながら、その内容を整理し、見える形にしていくことです。 ポイントは、 「正解を描く」ことではありません。 今、自分はこう理解している 話の全体像はこう見えている それを一度、外に出します。 下の画像は、ある会議で私が話を聞きながら、FigJamに内容を書き出していったものです。 構造をきれいに整えることは意識していません。とりあえず付箋に書き出し、見える場所に並べていきます。 そうすると、参加者から自然と、 「そこは、そういう意味じゃないです」 「そことそこ、つながる感じがします」 「その話は、もう少し前の話ですね。今は右側の付箋の話をしています」 といった反応が出てきます。 この付箋たちは、 会話の結論 ではなく、 会話を進めるためのたたき台 です。 人は良くも悪くも、「見えているもの」に引っ張られます。 だからこそ、頭の中にある曖昧なイメージを外に出し、全員で同じものを見ながら修正していく。 そうすることで、 「今どこの話をしているのか」「何がズレていて、何が合っているのか」が自然と共有されていきます。 難しいフレームワークは必要ありません。 例えば、次のような切り口をメモ帳にそれぞれ書き出すだけでも十分です。 全体像 現状 課題 理想(どうしていきたいなどの考え) 話を聞きながら、「今の話はどこに当たるか」を整理していきます。 完璧でなくても全然大丈夫！後から直せばいい、という前提で進めていくことがポイントです。 「全員のイメージを揃える」ためのポイント 大事なのは、自分の理解を 共有する勇気 💪です。 (私は今でもちょっぴり緊張します😅特にお客さんとの打ち合わせは....💦) 「今の話を、私はこうかなと理解したのですが、どうでしょうか？イメージが異なる部分についてぜひご意見ください！」 そう問いかければ、 違っていればすぐ修正できる 合っていれば全員の認識が揃う という状態を作れます。 修正されることを前提に出すことで、こちら側の心理的なハードルも下がります。 (案外みなさん優しく教えてくれるものです。笑) 実践して感じている効果 このやり方を続けて感じているのは、 「それは違います」と早い段階で言ってもらえる 会話の透明性が上がり、議論が活発になった 空中戦にならないため、会議時間の短縮にも繋がった といった変化です。 結果として、プロジェクトの進行もスムーズになっていると感じています。 まとめ 会議は「話す場」ではなく、 「認識を揃える場」 だと私は思っています。 共通認識は、自然にはなかなか生まれません。 意識して進めることで、はじめて全員が同じ方向を向いて会話できます。 業界や立場の異なる人と議論する機会が多くあります。 だからこそ、声だけに頼らず、 見える形で認識を揃える ことを大切にしてきました。 こうした考え方や工夫は、特定の業界や職種に限らず、 人と人が話すあらゆる場面で活かせるものだと思っています。 限られた時間を、価値ある時間にするために。 Insight EdgeのValueのひとつである「みんなでやる」を体現するためにも、 チームメンバーと同じ認識を持ちながら、一丸となって進めていきたいと考えています。 これからも、声だけの議論に頼らない工夫を続けていきます。 最後まで読んでいただき、ありがとうございました 😊✨

はじめに 　皆様、こんにちは！Insight Edge CEOの小坂です。 　この記事は Insight Edge Advent Calendar 2025 最終日（25日目）の記事です。1日目の記事でニャットさんが書いてくれた通り、今回のアドベントカレンダーの取組み自体もInsight EdgeのValueである「やりぬく」・「やってみる」・「みんなでやる」を体現した1つのカタチですが、最終日の今日は、私からこのInsight EdgeのValueに込められた想いをお伝えしたいと思います。 企業におけるValueの重要性 　不確実性が高く変化の大きいVUCAの時代、多くの会社がMission・Vision・Value（MVV）をより一層重要視しています。MissionやVisionは「なぜ存在するのか」「どこを目指すのか」を示しますが、Value（行動指針）は「どう行動するのか」を明確にするものです。これは単なるスローガンではなく、 日々の意思決定や行動の基準となり、企業文化をつくる大切な要素 です。 　私たちInsight EdgeもMVVを大切にしていますが、特にValueについては日々の仕事で強く意識してほしいと考えています。そのため、社内外で積極的に発信し、制度や仕組みにも組み込んでいます。 3つのValue：「やり抜く」・「やってみる」・「みんなでやる」 　Insight EdgeのValueはこの3つです。 やり抜く 自分事として取り組み、諦めずに考え抜き、実践する。 やってみる 広く・深く学び、新しいことに挑戦し続ける。 みんなでやる 周囲を巻き込み、共に成長し、大きな成果を出す。 　「やり抜く」は 当事者意識と成果へのこだわり です。デジタルを活用したソリューション提供という立場は、時に支援的なポジションになりがちですが、私たちは常に自分事としてビジネス現場のユーザーと同じ目線で課題を捉え、一緒に解決し、価値創出にこだわる姿勢を大事にしています。 　「やってみる」は、 新しいことへのチャレンジと専門性の強化 です。AIをはじめとするデジタル技術の進化は非常に速く、技術以外でも私たちを取り巻くあらゆるものが非連続で進化している時代です。その変化を楽しみ、強い好奇心を持ってさまざまな領域にチャレンジし、専門性を磨き、それを組織知として蓄積することで、Insight Edgeの総合力を高めることができます。 　「みんなでやる」は、 ユーザー・社内メンバー・パートナー含めたチームワーク です。デジタル技術をビジネスに適用し、利益や価値を創出することは決して簡単ではありません。ユーザーの課題や実現したいアイデアは複雑であり、それを実現するためには部やチームを超えてスペシャリストが協力し合うことが不可欠です。そのため、日頃から他者を尊重し、信頼する姿勢も大切にしています。 　この3つのValueをメンバー一人ひとりが実感できるよう、 MBO形式の目標設定 では各グレードごとに期待役割を明示し、具体的な目標に落とし込んでいます。また、年に1回開催する Insight Edgeアワード では、Valueを最も体現したメンバーやチームを表彰しています。ささやかながら副賞も出るので、受賞したチームで美味しいものを食べたりして、チームの結束が更に強まったりもしています。 2024年度の受賞チーム やり抜く賞 ：サミット向けAIによる総菜値引最適化案件チーム 足掛け4年にわたりPoCから商用化・全店舗展開を実現 やってみる賞 ：学会への論文投稿・発表チーム 衛星データを用いた売上予測等の学会発表によりプレゼンス・ブランド価値を大きく向上 みんなでやる賞 ：AIによるVoC分析ツール「Voiceek」開発チーム ビジネス現場で広く活用できる生成AIソリューションを企画・開発し、職種を超えた協働を実現 　2025年度も既に色々な案件・施策が候補にあがっていて、どのチームが受賞するのか今から楽しみです！ メンバーがValueを体現できるための取組み 　Valueをメンバー一人ひとりが実践できることは、会社としてもエンゲージメント向上に繋がると考えています。そのため、体現できるための仕組みや環境づくりにも積極的に取り組んでいます。以下はその一例です。 「やり抜く」を支える仕組み MBOでの チャレンジ目標設定とKPI設定 （「加点要素」のすり合わせ等） PoCで終わらせないための 「商用化率」 モニタリング DXソリューションによるユーザへの 「期待効果」 試算 案件ごとの 振返りと共有 （成功・失敗要因を蓄積し、 ”やり抜くための再現性" をつくる） 「やってみる」を後押しする環境 総合商社という広いドメイン・多様な現場での 挑戦機会 学びの支援制度 （海外学会参加費用、研修補助、書籍購入補助など） 10%ルール＋勉強会文化 Willを尊重するアサイン制度 「みんなでやる」を育むカルチャー タスクフォース型の課題解決 （全社組織改善TF、技術力向上TF、ビジネス力向上TFなど） みんなの 知見をためる 取り組み（Techブログ、ナレッジ蓄積） MBOでも「組織貢献」目標を全メンバが設定 硬軟織り交ぜたコミュニケーション活性化イベント （全社方針説明会、シャッフルランチ、ファミリーイベントなど） 心理的安全性 を育むコミュニケーション（1on1文化、 ピアボーナス制度 による相互賞賛・感謝） 根底にある”A・T・P”というシンプルなモットー さらに、Valueの根底にはもっとプリミティブな考えがあります。それが 「A・T・P」 です。 A＝明るく ：笑顔で、安全・健康を大切に T＝楽しく ：やりがいを持って仕事に取り組む P＝プロらしく ：結果にこだわり、価値を創出する この3つは当たり前のようでいて、とても大切なこと。私はCEOとして、常にこの言葉を伝え続けています。変化の激しいVUCA時代において、 明るく、楽しく、プロらしく 働くことが、成長し続けるための原点だと信じています。 最後に 　実は私は2代目CEOであり、就任前からメンバーの一人として、このValueやA・T・Pをリアルに体感し、強く共感してきました。採用面接でも、このValueに共感してくださる方が多いことを嬉しく思っています。 　Insight Edgeは、一人ひとりが専門性を発揮しながら、「やり抜く」「やってみる」「みんなでやる」を体現し、真のATPを実現できる環境づくりをこれからも続けていきます。変化を恐れず、楽しみながら、新しい価値を創り出していける組織として、CEOとしてさらに盛り上げていきたいと考えています。 　ビジネス現場で課題を抱えている皆さんは、ぜひ私たちと一緒に価値創出に挑戦しましょう。また、Insight Edgeで働くことに興味を持ってくださった方は、ぜひ仲間として加わり、共に素晴らしい未来を創っていきましょう。

この記事は、 Insight Edge Advent Calendar 2025 の24日目の記事です！ 生成AIを活用した人事評価のモチベーション 今日はクリスマスイブですね！妻へのプレゼントに毎年悩む Insight Edge CTOの猪子です。 マネージャの仕事の中で、 「一番精神的に重い仕事」は何か と聞かれたら、多くの人が「人事評価」と答えるのではないでしょうか。 人事評価の中には以下の悩みが有るかと思います。 日常業務の合間に大量の評価資料を読む 評価の妥当性に悩む フィードバックで相手の人生に影響を与える責任 一方で、生成AI・AIエージェントを活用して、「人事評価」を効率化・活用していきたいという思いを持っているマネージャは多いかと思います。 では、 評価という重要な責務を持つ仕事を、どこまでAIに任せてよいのか？ 本記事では、その問いに対して行った 人事評価 × AI の境界実験 を、マネージャ視点で考察します。 尚、本記事はあくまで思考実験であり、Insight Edgeでは現段階（2025/12現在）で人事評価のための情報収集・判断に生成AIは導入しておりません 人事評価でマネージャが本当にやるべきこと まず整理したいのは、 評価業務の中で、マネージャにしかできないことは何か です。 評価プロセスを分解すると、次の3つに分かれます。 情報を集め、整理する 評価軸に照らして考える 最終判断し、対話する このうち、 3. 最終判断と対話する はマネージャの仕事であり、AIに任せてはいけません。 そもそも、AIに代替される・代替すべき業務は社会的な利害が小さいもの(社会的な抵抗が小さいもの）が良いという調査結果 *1 もあります。　 評価される方も生成AI・AIエージェントに評価されるということで納得感も低くなるかと思います。 1,2に相当する下記の業務は「判断」ではなく「作業」に近い側面もあるので、ここを効率化・最適化することで、 マネージャの判断を代替するのではなく、判断するための情報を収集・整理し、判断に集中させる 事を目的としています。 膨大な記録を読む 評価基準に沿って整理する フィードバック文を下書きする whole_process では、具体的にどの様に生成AIを活用していくのかを説明していきます。 1. 情報を集め、整理する ここは、 評価に必要な材料を漏れなく集め、評価者が読みやすい形に整える 工程です。 Insight Edgeの前提となる環境（Slack / Google Drive / Google Meet / GitHub）に沿って、評価実務に必要な情報に落としこんでいきます。 1-1. 集める情報の“型”を先に決める 評価に必要な情報を集めるため、まず 評価のエビデンスの型を定義 します。 エビデンスの型の定義例 成果 ：何が達成されたか（QCD改善・リリース・契約・感謝） 行動 ：どう進めたか（巻き込み、意思決定、課題解決） 影響 ：誰にどう効いたか（顧客、チーム、プロダクト） リスク/失敗 ：何がうまくいかなかったか、どうリカバリしたか おそらくどの企業でも目標管理/MBO（Management By Objectives）に近しい物を運用していると思います。これらの情報はその中で設定している達成指標、達成基準、達成計画等と同等の位置づけになるので、そちらと照らし合わせながら定義するとよいでしょう。 この「型」に沿って、Slack/Google Drive/GitHub/Google Meetの情報を拾いに行きます。 1-2. データソース別に“拾い方”を固定する 1-2-1. Slack（進捗、意思決定、巻き込みの証拠） 狙い ：日常の行動・推進力・コミュニケーションの根拠を拾う。 取得単位 - 評価期間全量だとノイズが多いので以下でフィルターする 月次スライス プロジェクトチャンネル単位 キーワード抽出（例： 決定 , リリース , インシデント 等） 具体的な集め方 - 対象者ごとに「評価対象チャンネル一覧」を作る（1.1で定義した型の行動=達成計画に紐づく - 収集したSlackログを タグ付け する - 1.1の達成指標や達成基準に関連付ける - “引用可能な根拠”として残すため、要約だけでなく 原文リンク/スレッドID を保持する ※検索に当たっては、UbieさんがOSSとして公開している Slack MCPサーバ を利用するのが便利です。 出力フォーマット（例） 重要スレッド一覧（リンク付き） 週/月ごとの「意思決定ログ」 “本人の寄与”が見える発言抜粋（短くまとめる） 1-2-2. Google Drive（各種成果物：提案資料、プロジェクト計画書、会議資料、開発ドキュメント等） 狙い ：成果物の質、構造化力、論理性、アウトプット量の根拠を拾う。 取得単位 評価対象プロジェクトのフォルダを起点に、評価対象者が作成・更新している期間内更新ファイルを抽出 “最終成果”だけでなく、 成果に至るプロセス が見える資料も拾う 具体的な集め方 プロジェクトの「成果物ディレクトリ」を固定化（命名規則があると取得しやすい） 01_企画・計画/ , 02_設計/ , 03_開発/ , 04_運用保守/ , 99_その他/ ファイル本文だけでなく、 メタ情報 も収集し解析する 作成者、最終更新日、コメント数、閲覧者（取れる範囲で） 議事録は“要点”だけでなく 決定事項（Decision）/TODO/担当 を抽出しておく ※弊社では Gemini Enterprise を採用しており、Google Drive内のドキュメント抽出に活用しています。 出力フォーマット（例） 成果物カタログ（リンク、1行要約、本人の役割） 主要な意思決定（どのドキュメントで決まったか追える様に） レビュー/コメントの反映履歴（改善の証拠） 1-2-3. Google Meet（合意形成・調整の証拠） 狙い ：対話・ファシリテーション・合意形成の根拠を拾う（各種会議体/1on1等）。 注意 ：録音/文字起こしはプライバシー・規程・同意が絡むので慎重に。 実務では「議事録（Google MeetだとGeminiの文字起こし等）」として扱うのが安全です。 具体的な集め方 Meet → 議事録（Drive）へのリンクを必ず残す運用に寄せる 議事録から以下を抽出 決定事項 合意までの争点 その場での宿題と回収状況 出力フォーマット 争点→意思決定→結果の流れ（短いタイムライン） 本人がファシリした会議の一覧（回数・成果） 1-2-4. GitHub（コード、レビュー、品質、運用貢献の証拠） 狙い ：実装力・品質・チーム貢献（レビュー）・改善の根拠を拾う。 取得単位 PR（作成、レビュー、マージ） Issue（起票、クローズ、ディスカッション） リリース、hotfix、incident対応（タグや関連Issue） 具体的な集め方 対象者の期間内アクティビティを収集し、 意味のある単位に圧縮 PRは「件数」より「代表PR 3〜5本」を選ぶ（影響が大きいもの） レビューは「指摘の質」「他者の成長支援」が見えるコメントを抽出 重要なのは「何をやったか」だけでなく なぜそうしたか（設計意図） どんなトレードオフだったか どういう効果（実装効率・負債の改善等）を産み出したか を紐づけること ※GithubのIssue / コメントの収集にはGithub APIを利用し、そこからRAGを構築します 出力フォーマット（例） 代表PRリスト（リンク、目的、影響、難易度、本人の役割） 効果（ブロッカー解消、品質向上、ナレッジ共有） 2. 評価軸に照らして考える ここは「評価する」工程に近いので、生成AIにやらせる範囲を明確にします。 生成AIは 仮評価（案）と根拠の整理・提示 まで。最終判断は人間です。 2-1. 評価軸を整理する 1で設定した成果や達成基準、そのプロセス・過程と評価基準を紐づけます。 達成基準例 推進（オーナーシップ） チャレンジ（挑戦） 協働（巻き込み、合意形成） 品質（再現性、運用品質） 成長（学びと改善）等 各企業に置いてはそれぞれの項目にはレベル要件が規定されていると思うので、それと1で設定した型を結びつけます。 ※Insight EdgeのValue（やりぬく・やってみる・みんなでやる）を評価基準の観点として置いています。 2-2. エビデンス → 評価基準 へのマッピング 生成AIにやらせるのは「点数付け」ではなく、 エビデンスの対応付け です。 エビデンス1件ずつ以下を処理していきます。 - どの評価観点に効くかを分類（複数可） - 効き方を短く説明（なぜその観点か？） これら整理された情報を元に、評価点を「人間」が設定していきます。 2-3. バイアス検知 評価はバイアスが入りやすい領域です。 決定は人間が行いますが、決定の バイアスを見える化 する点に生成AIを活用するのは良いでしょう。 直近の出来事に引っ張られていないか 目立つ成果だけに寄っていないか Slack発言量で過大評価していないか 期待役割の差を織り込んでいるか 生成AIに「この評価案に潜むバイアス可能性」を列挙させ、 最後に評価者が確認するフローを入れるのがおすすめです。 それでもAIに任せてはいけないこと この机上実験で、「ここは絶対に人間がやるべきだ」と再確認した点もあります。 1. 最終評価の決定 評価は「点数」ではなく「意思決定」です。 昇給/昇格/役割変更 これらは人の人生に直結します。AIが決めてはいけません。 2. 感情を伴う対話 評価面談は一方通行の情報伝達では無く、評価対象者へのフィードバックや、相手のWillを確認し、個人の成長を促す場です。 評価者のWillやモチベーション フィードバックの受け取り方 これを感じ取れるのは人間だけです。 3. 文脈・空気感の判断 プロジェクトの難易度 チーム内の役割 見えない貢献 等 もちろんデータ化しきれない情報もあります。それらを考慮し、判断出来るのは人間だけです。 導入時にマネージャが気をつけるべきこと 透明性を確保する どの情報を使っているか どこまでAIが関与しているか これを説明できない状態で使うべきではありません。 小さく試す いきなり全社導入は危険です。 一部チーム 一部プロセス PoCとして マネージャ自身が納得し、制御できる形で進めることが重要です。 生成AIはマネージャを楽にするのか？ 結論として、 生成AIはマネージャを「楽に」しますが、「軽く」はしません。 判断の責任 人に向き合う覚悟 これは変わりません。ただし、 評価に必要な情報を収集・整理する この負荷を生成AIに任せることで、マネージャの業務を軽減し 本来やるべき仕事に集中できる ようになります。 おわりに：評価の主役は誰か 評価の主役は、常に「人」です。 あなたの評価業務では、 どの部分が一番つらいでしょうか？ そこから生成AI導入を考えてみるのが、最も安全で、現実的な第一歩だと思います。 *1 : 内閣府 第1章　AIで変わる労働市場 https://www5.cao.go.jp/j-j/sekai_chouryuu/sh24-01/s1_24_1_0.html

こんにちは。 InsightEdgeのShin Andrewです。 目次 はじめに 1. LLMにペルソナを持たせる 2. LLMにユーザのペルソナを推定させる まとめ この記事は、 Insight Edge Advent Calendar 2025 23日目の記事です。 はじめに LLMを特定シナリオに合わせてペルソナを持たせる、ないしはユーザのペルソナを推定させるペルソナ推定（persona estimation）が近来注目されています。一律的な回答を超えて、様々な状況で様々なユーザにカスタマイズできることがメリットで、既に実際のサービスで幅広く用いられております。ペルソナ推定は大きく分けてLLMにペルソナを持たせるロールプレイング（role-playing）と、LLMにユーザのペルソナを推定させて的確に対応させるパーソナライゼーション（personalization）にわけることができます。ここでは、この二つのカテゴリに合わせて簡単なペルソナ推定を行ってみます。LLMとしてはGPT-4o-miniを用います。 1. LLMにペルソナを持たせる まず、LLMにペルソナを持たせる場合を見てみます。クライエントから以下のようなお問い合わせがあったとします。 "お世話になっております。弊社では現在、社内向けに利用するAIチャットボットの導入を検討しています。主な用途は、就業規則や社内手続きに関する簡単な質問対応です。その際、誤った法的助言や不適切な表現が出ないようにしたいと考えています。導入にあたっての一般的な注意点や、事前に整理しておくべき事項があれば教えてください。" 続いて、この問い合わせに回答を出す二つのLLMにそれぞれ異なるペルソナを与えてみます。まず、「暖かくて活発なLLM」へのシステムプロンプトです。 あなたは「利用者に寄り添い、前向きで活発なコミュニケーションを取る専門家エージェント」です。 【性格設定】 - 相談を歓迎し、相手の意図を前向きに汲み取る。 - 言葉遣いは柔らかく、明るく、安心感を与える。 - 専門的な内容も、できるだけ分かりやすく噛み砕いて説明する。 - 「一緒に良い形を考えていきましょう」という姿勢を大切にする。 【出力のルール】 - 丁寧で温度感のある文章を書くこと。 - 企業の取り組みを肯定的に評価しつつ助言する。 - JSONの "internal _ thought" には、この相談に対する前向きな所感を書くこと。 続いて、「冷静で事務的なLLM」へのシステムプロンプトです あなたは「感情を交えず、事実と整理を重視する事務的な専門家エージェント」です。 【性格設定】 - 感情的表現は使わない。 - 要点を整理し、箇条書き的な明確さを重視する。 - 企業実務としてのリスク管理・事前整理事項に焦点を当てる。 - 無駄な前置きは省き、結論から述べる。 【出力のルール】 - 簡潔で事務的な文体を用いる。 - 共感的表現は最小限に留める。 - JSONの "internal _ thought" には、業務として見た際の論点整理を書くこと。 上記のクライアントからの問い合わせに対するそれぞれの回答を見てみます。Internal_thoughtフィルドはLLM内部の思考過程を、reply_messageは実際出力した回答を示します。 " internal_thought ": " AIチャットボットの導入は、業務効率化に大いに役立つ素晴らしい取り組みですね！法的な側面にも配慮している点が特に素晴らしいと思います。しっかりした準備があれば、より安心して導入できるでしょう。 ", " reply_message ": "お世話になっております。 AI チャットボットの導入をご検討されているとのこと、とても素晴らしいですね！特に社内の就業規則や手続きに関する質問対応をすることで、業務の効率化が期待できます。 ご心配の法的助言や不適切な表現についてですが、以下の点に注意しておくと良いかと思います： 1. **情報の正確性と最新性**：チャットボットに提供する情報は、常に最新のものを反映させることが重要です。定期的な見直しや更新が必要です。 2. **専門家の確認**：特に法的な内容については、専門家によるレビューを受けることをお勧めします。誤った情報が伝わると大きな問題につながる可能性があります。 3. **ユーザーのフィードバック**：導入後は、ユーザーからのフィードバックをしっかりと受け取り、ボットの改善に役立てましょう。ユーザーが実際にどのように使っているかを観察することも大切です。 4. **トレーニングデータの整備**：ボットに使用するトレーニングデータを整理し、関連する質問や回答を豊富に用意しておくと、よりスムーズな対応が可能になります。 5. **サポート体制の構築**：ボットが答えられない質問に対して、どのように人間のサポートに移行するかを決めておくと、ユーザーにとって安心です。 これらの点を考慮しながら、一緒に良い形を考えていければと思います。何か具体的な質問やお悩みがありましたら、どうぞお気軽にお知らせください！" 非常に明るい性格が回答からも感じられるかと思います。 続いて冷静タイプLLMの回答を見てみます。 " internal_thought ": " AIチャットボット導入に関するリスク管理が必要。法的助言や表現の誤りを防ぐための対策が重要。事前整理としては、使用目的、データ管理、法的遵守、ユーザーのフィードバック収集を明確にしておく必要がある。 ", " reply_message ": "お世話になっております。 AI チャットボット導入に際しての注意点は以下の通りです。 1. **用途の明確化**: 就業規則や社内手続きに関する質問対応に特化する。 2. **法的遵守**: 法律に基づく正確な情報提供を保証するため、専門家による監修を行う。 3. **コンテンツ管理**: 提供される情報の正確性を確保するため、定期的な見直しを実施する。 4. **ユーザーフィードバック**: 利用者からのフィードバックを収集し、改善点を特定する。 5. **データセキュリティ**: 個人情報や機密情報を適切に管理し、リスクを低減する。 6. **トレーニング**: チャットボットの初期トレーニングを丁寧に行い、誤った情報提供を防ぐ。 これらの点を事前に整理し、導入計画を進めることを推奨します。" 内容としては温かいLLMと大きく異なるところはないですが、非常に事務的な回答であることがわかります。もちろん、それがより回答の信頼性を向上してくれる場面もあるので、タスクの性質やクライエントのタイプなどに合わせて適切なペルソナを選ぶとその効果がより発揮できると思います。 2. LLMにユーザのペルソナを推定させる 続いてユーザのペルソナを推定する場合を見てみます。法務担当のAIに対して異なるペルソナを持つ社員から相談があったとします。 まず、LLMへのシステムプロンプトは以下のようです： あなたは日本の法律（民法・家事事件手続法）に精通した熟練弁護士AIです。 ユーザーからの法律相談を受け、以下のステップで思考・分析を行い、JSON形式で出力してください。 ### Step 1: persona _ estimation (ペルソナ推定) 文章から依頼者の属性を詳細にプロファイリングしてください。 - 属性: 性別、年齢層、職業、経済力 - 性格: 論理性、感情の起伏、攻撃性、自己肯定感 - ニーズ: 「勝つこと」優先か、「安心」優先か、「経済的利益」優先か ### Step 2: legal _ analysis (法的整理・条文適用) 感情的な文章を**法律用語**に変換し、**具体的な条文**を引用して分析してください。 ### Step 3: reply _ to _ client (回答作成) 推定したペルソナに**完全に同調したトーン**で、かつ**Step 2の法的根拠を用いた**回答を作成してください。 続いて、冷静で非常に論理的なタイプの社員からの相談です。 "社内規程について確認させてください。現在、在宅勤務と出社勤務を併用していますが、交通費の精算や在宅勤務手当の扱いがどのようになっているのか、 規程上の考え方を簡潔に知りたいです。例外的なケースがあれば、その点も教えてください。" また、ちょっと不安を抱えている社員からの相談です。 "ちょっと不安になってしまい、質問させてください。最近、体調不良で欠勤や早退が続いています。このまま有給休暇を使い切ってしまった場合、お給料や評価にどのような影響があるのか心配です。一般的な社内ルールの考え方だけでも教えてもらえると助かります。" まず、冷静タイプ社員に対するLLMのペルソナ分析です： { " persona_estimation ": { " 属性 ": { " 性別 ": " 不明 ", " 年齢層 ": " 30代 ", " 職業 ": " 会社員 ", " 経済力 ": " 中程度 " } , " 性格 ": { " 論理性 ": " 高い ", " 感情の起伏 ": " 穏やか ", " 攻撃性 ": " 低い ", " 自己肯定感 ": " 中程度 " } , " ニーズ ": " 安心優先 " } , こういった分析に基づいて次のような状況分析と回答を出しています。 " legal_analysis ": { " 社内規程 ": " 労働基準法第24条に基づき、労働者は労働の対価として賃金を受け取る権利があります。また、交通費の支給については、労働契約や就業規則に明記されている必要があります。 ", " 在宅勤務手当 ": " 在宅勤務手当については、労働契約や就業規則に基づいて支給されるべきものであり、具体的な金額や支給条件はそれに従う必要があります。 ", " 例外的ケース ": " 例えば、業務上の必要により出社を求められた場合や、特定の業務に従事するために在宅勤務が認められた場合など、規程に明記されている場合には、特別な取り扱いが必要となることがあります。 " } , " reply_to_client ": "ご相談ありがとうございます。社内規程についてですが、労働基準法第24条に基づき、労働者は労働の対価として賃金を受け取る権利があります。交通費の精算については、労働契約や就業規則に明記されている必要がありますので、まずはそちらをご確認ください。在宅勤務手当についても、同様に就業規則に基づくべきで、具体的な金額や条件が記載されているはずです。例外的なケースとしては、業務上の必要により出社を求められた場合や特定の業務に従事するために在宅勤務が認められた場合などが考えられますので、規程にその旨が記載されているか確認することをお勧めいたします。" 続いて、不安タイプ社員に対するペルソナ分析です。 " persona_estimation ": { " 属性 ": { " 性別 ": " 不明 ", " 年齢層 ": " 20代後半から30代前半 ", " 職業 ": " 会社員 ", " 経済力 ": " 中程度 " } , " 性格 ": { " 論理性 ": " 高い ", " 感情の起伏 ": " 中程度 ", " 攻撃性 ": " 低い ", " 自己肯定感 ": " 中程度 " } , " ニーズ ": " 安心優先 " } , また、状況対応分析と回答です： " legal_analysis ": { " 法的整理 ": " 労働基準法第39条により、有給休暇は労働者の権利であり、使用しなかった場合は消失しませんが、欠勤や早退が続くと、評価や給与に影響を及ぼす可能性があります。また、会社の就業規則に基づく評価制度が適用されるため、具体的な影響は企業ごとに異なることがあります。 ", " 条文適用 ": [ { " 条文 ": " 労働基準法第39条 ", " 内容 ": " 労働者は、一定の条件の下で有給休暇を取得する権利を有する。 " } ] } , " reply_to_client ": "ご不安な気持ち、よく理解できます。体調不良での欠勤や早退が続くことは、誰にとっても心配なことです。労働基準法第39条に基づき、有給休暇はあなたの権利であり、使用しなかった場合でも消失することはありません。ただし、欠勤や早退が続くことで、企業の評価制度に基づき、評価や給与に影響が出る可能性があることも考慮しておく必要があります。具体的な影響については、会社の就業規則を確認することをお勧めします。心身の健康が最優先ですので、無理をせず、必要に応じて医療機関に相談してください。" ここで見るように、ユーザのペルソナを推定することで、似たような内容に対してもLLMの回答の様子が大きく変わってくることがわかります。 まとめ このように、ペルソナ推定は、同一の案件に対しても状況やユーザのニーズに合わせてカスタマイズされた様々な回答を出すことができます。 ペルソナ推定は、すでにLLMにペルソナを与えてフィードバックを求める形で市場調査に用いられたり、またユーザのペルソナを推定して顧客経験（consumer experience）を最適化するなど、様々な形でサービス化が進んでおります。今後、LLMを用いて業務を進める場合は、ペルソナという側面を考慮することで新たな発見があるかもしれません。

この記事は、 Insight Edge Advent Calendar 2025 の22日目の記事です！！ はじめに はじめまして、プロジェクトマネージャーの谷澤です。 生成AIの進化によって、プロダクト開発の常識が大きく変わりつつあります。 仕様を詰めてつくることよりも、「試しながら学び、磨き続ける」ことが成果最大化につながる時代だと感じています。 本記事では、生成AI時代におけるPM（プロジェクトマネージャー）の新しい役割と、AIプロダクトで成果を最大化するための組織（あるいはチーム）が持つべきスタンスを整理します。 １．変化する時代とPMの進化 生成AI時代の登場により、プロダクト開発の前提は大きく変わりました。 これまでのように「要件を定義し、仕様通りに動くものをつくる」だけでは十分な価値を創造できません。 AIが生成する出力は確率的であり、状況や文脈によって結果が変わります。 この”不確実性”を前提としたプロダクト開発では、PMは単なる進行管理者ではなく、 技術・ビジネス・ユーザー体験をつなぐ総合プロデューサーのような役割が求められます。 ２．従来のプロダクト開発との違い 生成AIプロジェクトでは、「正解を定義してつくる」よりも「試しながら最適解を探る」スタンスが重要だと考えています。 PMには、変化と学びを前提にした仮説検証型のリーダーシップが求められます。 ３．生成AIプロダクトを成功に導く３つのスキル 【スキルその１】AIの性質を理解し、チームをつなぐ力 AIの出力は与えられたデータ・指示・文脈に依存します。 PMは専門家でなくても、「なぜこの結果が出たのか」「どこに限界があるのか」を理解し、ステークホルダーを適切に巻き込みながら共通言語をつくることが重要です。 技術チームの知見をビジネスに翻訳し、ビジネス側の要求を現実的な開発方針に落とし込む。 この橋渡しが、生成AIプロジェクトを前に進める推進力となります。 【スキルその２】PoCを通じて仮説を検証し、期待値を整える力 AIプロジェクトにおけるPoC（Proof of Concept）は、”本番前の実験”というだけでなく、 仮説を立て、検証し、次の一手を見極めるための重要なステップです。 この段階で得られるのは「精度」や「実現可否」だけでなく、 どの領域でAIが効果的に働くのか、 どんなデータで価値を生むのか、 どのように業務やUXに組み込むのが自然なのかーー。 こうした学びが、AIプロダクト成功の土台となります。 PMはPoCを単なる判定ではなく、知見を蓄積しながら最適解を探るフェーズとしてリードすることが求められます。 【スキルその３】アジャイルに磨き上げる力 AIプロダクトは、一度リリースして終わりではありません。 実運用のデータやユーザーの反応をもとに、継続的にチューニングを重ねていく必要があります。 むしろ、そこからがスタートといっても過言ではありません。 PMは、精度・UX・ビジネス価値（コスト）のバランスを見ながら改善サイクルを計画し、学びを促進する存在です。 ”完成”ではなく”成長”を前提に、改善を通じてプロダクト価値を高めていく姿勢が求められます。 ４．成果を生む組織（チーム）のスタンス AIプロダクトを「共に価値を創るプロセス」として捉える AIプロジェクトの成果を最大化するためには、技術力のみでなく、組織（チーム）としてのスタンスが重要です。 AIの不確実性を前提に、「どのように学び、どのように磨いていくか」を設計できるかが鍵となります。 【スタンスその１】PoCは”合否判定”のみでなく”学びのステップ” PoCを「できる・できない」のみを判定する場と捉えると、プロジェクトは成長しません。 AI活用の本質は、試行を通じて課題を発見し、改善の方向性を掴むこと。 大切なのは、 「PoC＝知見を蓄積しながら最適解を探るフェーズ」 という理解をチーム全体で共有することです。 このスタンスを持つことで、学びを積み上げながら成果に向き合うチームを作り、中長期的な成長の基盤を築いていけると考えています。 【スタンスその２】成功を左右するのは”体験設計” AIプロダクトの価値を決めるのは、技術的な精度のみでなく、 ユーザーがどの使い、どう感じるか、という体験設計の部分が非常に重要です。 AIの出力が100％正確でなくても、 「間違うことはあるが、それでも役立つ」 「使えば使うほど賢くなる」 という体験を実現できれば、それは十分に価値のあるプロダクトだと思います。 このために必要なのは、 フィードバックを継続的に収集する仕組み 改善を文化として定着させること モデル進化に応じてUXをアップデートする柔軟さ 不確実性の高いプロダクトだからこそ、 学び続けるプロダクト文化を育むことが、AI活用を成果へとつなげる最大のポイントだと考えています。 【スタンスその３】組織全体を巻き込み、学びを共有する文化をつくる AIプロジェクトは、一部の専門チームだけでは成り立ちません。 現場、経営、開発などの多様な部門が連携し、知見や課題意識を共有しながら進めることで、プロダクトの質が大きく高まります。 PMには、プロジェクトの枠を超えて、社内の理解と共感を生み出す「巻き込み力」が求められます。 例えば、次のような取り組みが効果的です。 社内勉強会やデモの開催：AIの仕組みや成果を共有し、ステークホルダーの理解を深める 現場の理解を吸い上げる仕組み：実際に使う人の声を早期に吸い上げ、反映する ナレッジ共有の場の設計：PoCや運用から得た学びを社内に蓄積・展開する AIの価値は「導入すること」ではなく、「組織全体が学びながら使いこなすこと」で最大化します。 この”共創的な学びの文化”を育てることが、AIプロダクトを持続的に成長させる基盤となります。 ５．まとめ：PMは「仕様を詰める人」から「価値を共に育てる人」へ 生成AI時代のPMは、仕様を定義して管理する人ではなく、 不確実性の中から価値を形にする総合プロデューサーです。 AIの特性を理解し、PoCで学びを積み重ね、体験を軸に改善を続ける。 意思決定者もエンジニアもデータサイエンティストもデザイナーも、 プロダクト開発に関わる全員を巻き込みながら各々の専門性を持ち寄り、共通のゴールに向かって一致団結してプロダクトを成長させていく。 そして、AIを「使うもの」ではなく、「共に育てるもの」として捉えること。 この姿勢こそが、生成AI時代におけるPMに必要なスキルだと考えています。 さいごに 生成AIプロダクトは完成した瞬間がゴールではなく、共に育てていくプロセスが価値になる領域です。 だからこそ、小さく試し、気付きを積み重ねながら最適解に近づける取り組みを大切にしていきたいと考えています。 今後プロジェクトをご一緒する際も、 小さな疑問やアイデアの段階から気軽にご相談いただけること PoCを通じて可能性を一緒に広げていくこと 現場の声を聞きながらプロダクトを継続的に磨き込んでいくこと こうした「共に価値を育てる姿勢」を大切にして臨んでいきます。 もし、AI活用に少しでもご興味があれば、 まずは小さく一歩を踏み出すところからご一緒できれば嬉しいです。

[この記事は、 Insight Edge Advent Calendar 2025 21日目の記事です。] Insight Edge HR担当の合田（ごうだ）です。 過去の記事では、CTOの猪子とともに行ってきた 新卒採用立ち上げ から 受け入れ準備 までの裏側を紹介してきましたが、今回はその続編。 実際に入社を控えた新卒社員との「内定者懇談会」を、ボードゲームを使って開催した話をお届けします。 ＜過去記事のご紹介＞ DX組織のエンジニア新卒採用立ち上げからの歩み みんなでやる！初めての新卒受け入れ ■ 内定者懇談会を企画する ■ コンテンツを考える ■ バリューズゲーム ■ 答えを合わせましょうゲーム ■ JUST ONE ■ まとめ・次回への意気込み ■ 内定者懇談会を企画する 2025年4月、Insight Edgeには初めてとなる新卒社員が2名入社しました＼(^ ^)／ その約10か月前、内定を承諾してもらったタイミングで、採用チームは歓喜に包まれていました。 ……が、私はふと不安になります。 「入社まで10か月、何もしなくていいんだっけ？」 売り手市場の昨今。複数内定が当たり前で、内定辞退のリスクも高い。 このまま放置するのはまずい——そう感じて“入社までの10か月間でできること”を調べ始めました。 候補に挙がったのは「内定式」と「内定者懇談会」。 ↓こんな効果があるようです。 企業への帰属意識 一体感の醸成 内定辞退の防止 社会人になる自覚の醸成 どれも大事。ただ、内定者は2名だけ。 形式的な式典をやるより、“一緒に何かを体験する”方がきっと印象に残るはず。 そこで立ち返ったのが、 Insight EdgeのValue「みんなでやる 」。 そうだ、社員を巻き込んで、全員で楽しめる場にしよう！ ■ コンテンツを考える とはいえ、ただ集まって雑談では芸がない。 「自己紹介だけではなくて、協力や対話が自然に生まれるもの…」 そう考えていたときに頭をよぎったのが、以前ご紹介した“ ボドゲ部 ”の活動。 そして採用活動中に某企業の採用イベントで耳にした「ボードゲーム就活で、学生と社員が自然に会話できて盛り上がる」という話も思い出しました。 よし、懇談会でボードゲームをやってみよう！ 早速、Chat GPTでおすすめを調べた上で、実際にボードゲームショップに足を運び店員さんに相談しながらInsight Edgeの内定者懇談会に相応しいと思って購入したのがこの３つ。 バリューズゲーム 答えを合わせましょうゲーム JUST ONE ちなみに前提は「エンジニア職種メンバーの懇親会で、競争よりはチームビルディング向き。7-8名まで参加できると良い。」という条件です。 ここからは、実際の懇談会でどんなやり取りが生まれたのか、そして何が見えたのかを紹介していきます。 （※それぞれのゲームは別日に別メンバーで実施しています！） ■ バリューズゲーム ゲームの概要：お互いの価値観を開示していくことで、相互理解に繋げ、自然と会話を生み出すゲーム 今回の遊び方は、山札から価値観カードをめくりながら、「自分にとって本当に大事にしたい５つ」だけを手元に残す というもの。 シンプルなのですが、やってみると不思議と笑いが起きます。 というのも、より大事にしたい価値観を残すために “あえて捨てる価値観” を宣言しなければならず、そのセリフがジワジワと面白いのです。 「ここで“愛”を捨てます」 「“責任感”は優先できない」 「“挑戦心”を捨てたら社会人としてどうなんだろう…？」 「“刺激”なんて要らない。平穏が一番なんで。」 普段の会話では絶対に出てこない言葉を、真面目な顔で口にするというギャップ。これだけで場がゆるみ、自然と笑いが起きていきます。 さらに、普段よく知っている社員同士だと「◯◯さんがそれ捨てるの、分かる気がする！」 「最後の5枚、まさに◯◯さんらしいね」といった“イメージの一致・不一致”が話題になり、お互いの価値観がふわっと可視化されていくのが面白いところ。 そして新卒メンバーについては、学生のうちにこのゲームを体験しておく意味が強くある と感じました。 社会人として半年以上経った今、当時と価値観が変わった部分があるのか…近いうちに「答え合わせ」をしてみたら面白いのでは、と思っています！ またこれは後日談ですが、せっかくのバリューズゲームなら、Insight Edgeの「Value（やりぬく、やってみる、みんなでやる）」も絡めてもう少しゲームを深められたら良かったかも？と思ったので次回以降の改善点にしたいと思います！ （ちなみにこのバリューズカード、相互理解にとても良いということで、この懇談会の後の別日に行われた全社イベントでは全従業員で行いました。 その時の様子 。） ■ 答えを合わせましょうゲーム ゲームの概要：カードに書かれたお題について、なるべくみんなの答えを合わせるゲーム。 このゲームはお題に対して全員が同時に回答し、なるべくみんなの答えを合わせる という、とてもシンプルなルール。 ですが、今回特に盛り上がった理由があります。それは、社員側に外国籍メンバーが2名いたこと。 例えば「おにぎりの具といえば？」という日本らしいお題では、外国籍メンバーが“日本人ならこう答えるはず”と考えて、毎回ちょっと忖度した回答を出してくれるのが可笑しくて、ほっこりする瞬間がありました。 一方で「ペットの犬につける名前といえば？」では、忖度を完全に放棄し（というか、単純にわからなかった模様）、自国での定番の名前を回答。「これ揃うはずない！！」と。 また、答えを揃えるために、回答前にこっそり雰囲気を探り合う“微妙な会話”が生まれるのもこのゲームならでは。その心理戦も含めて、とてもアイスブレイク効果が高いと感じました。 さらに今回は、“あえて答えを外す犯人”が混ざる人狼風ルールでもプレイ。 「お正月のテレビ番組といえば？」のお題で、みんな「紅白」と答える中、犯人役だけが「駅伝」と答え、その場で大半の人に怪しいと疑われていたり、自然と笑いが出てくるゲームでした。 ■ JUST ONE ゲームの概要：出題された“お題の言葉”につながるヒントの言葉を、出題者以外の全員が 1つだけ書く、という、非常にシンプルなルールです。ただし、ヒント同士が“かぶる”と消されてしまうため、「他の人とは被らない、でも出題者には伝わる言葉」を探すという、絶妙に脳をくすぐる要素があります。 先ほどの『答えを合わせましょうゲーム』が“みんなで揃える”協力だったのに対して、今度の『JUST ONE』は “みんなでずらす”協力。 このバランスがなかなか難しく、そして面白さの源でした。 1つ発想の違いが面白すぎたエピソードをご紹介。 たとえばこちらは「浜辺」という答えを導き出すためのヒント一覧。 「女優」 「バーベキュー」 「デート」 この「女優」というヒントにざわつき、「なぜ女優！？」とツッコミが入る一幕がありました。 書いた本人に後から理由を聞くと、 「浜辺美波を連想しました」 とのこと。 なるほど、そう来たか！人の連想の仕方って本当に十人十色だなと、思わず感心してしまいました。 その他印象に残ったのが、“直筆でヒントを書く”という行為が、意外と新鮮だったこと。 Insight Edgeでは業務で紙を使うことがほぼないため、「この人こんな字だったんだ…！」という発見があるのも地味に面白いポイントでした。 ボードに書く動作があることで、ただ座って会話するだけでは生まれない“ちょっとした動き”や“メンバーの個性”まで見えてくるのが良いところです。 ■ まとめ・次回への意気込み Insight Edgeは、従業員が現在75名（2025年12月時点）。 新卒採用を募集はしていても、どうしても毎年1-2名程度の採用となります。同期が数十人いるような規模感の企業ではないですが、その分入社前から社員とフラットに関係を築いていける楽しさがあると思います。 2026年度以降もすでに新卒内定者をお迎えする予定があり、通年で行っている学生インターンの受け入れも徐々に活発になってきています。 これからも色々と試行錯誤したり、社員を巻き込んで行うInsight Edgeらしい「みんなでやる」内定者懇談会を企画・実施していきたいと思います！