はじめに こんにちは。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らしい「みんなでやる」内定者懇談会を企画・実施していきたいと思います！

【本記事は、Insight Edge アドベントカレンダー、 Insight Edge Advent Calendar 2025 の20日目です】 こんにちは。Insight Edgeに6月に入社した肥塚です。 QA・運用保守チームの第1号社員としてシステム運用に携わっています。 この記事では、入社時に存在していた弊社のシステム運用の課題と、その課題をどのように解決しようとしているか説明しようと思います。 システム運用に携わるエンジニアの方々や、システム運用の体制を強化したいマネージャーの方々に特におすすめの記事です。 直面していた危機的状況 私が入社したとき、システム運用分野の問題がいくつか存在していました。詳しくみていきましょう。 1. 属人化の連鎖：「担当者しかわからない」の恐怖 弊社では、開発チームによる商用開発を経て顧客とライセンス契約を結び、システムを本番提供しています。それで弊社のお仕事が終わりなわけではなく、ライセンス契約において定められている顧客からの問い合わせにきちんと対応する必要があります。その対応にあたっては当該システムの運用保守に関する広範な知識が必要になります。例えば: 契約書を配置してあるGoogleドライブのURL SLAの有無やその内容 開発を担当したのは誰か 本番環境のURLは何か 監視はどのようにされているか これらはシステムの運用保守にあたって適切に整理されておらず、当時の開発担当者だけが知っている状態でした。 特に開発担当者の不在時に保守運用が属人化したシステムの問い合わせが来ると、対応が困難になります。残された人たちはシステムの概要さえも知らないので、問い合わせに対応するのに苦慮します。 属人化に苦しむエンジニア 2. ライセンス契約を結んで提供しているシステムの一覧がない 管理職としてはライセンス契約を結んで提供しているシステムの一覧によりそれぞれの運用保守の状況を概観し、次なる施策を考えたいところです。 しかしつい最近まで弊社ではそのような一覧が存在しない状態でした。 一覧がないと管理上何が良くないかというと、例えば: 経営層にライセンス契約を結んでいるシステムが何個あるのか報告できない 保守運用の管理対象とするシステムがわからず、社内で聞いて回る必要がある それぞれのシステムの契約更新日がわからないので更新漏れのリスクがある システムの属人化解消にあたって優先度を立てられない などの問題があります。 そんななかQA・運用保守チームが立ち上がり、私が第1号社員として入社して以降、運用保守の基盤を構築し、1番目と2番目の課題を一度に解決する仕組みを実装しました。 運用保守の基盤 ナレッジの一元化「運用保守マニュアル」 弊社が言う運用保守マニュアルとは、顧客とライセンス契約を結んだシステムを対象に作成した技術的なドキュメントです。「〇〇システムの運用保守のことは〇〇の運用保守マニュアルを見ればわかる」ドキュメントを目指しています。システムに関する情報を「基本情報」「ビジネス情報」「技術情報」「運用情報」の4つのカテゴリに分けて羅列的に記述した社内向けのドキュメントです。 # (プロダクト名) ## 基本情報 ### プロダクト名 ### 案件名 ### 顧客名 ### 契約形態 ## ビジネス情報 ### プロダクトの目的 ### 契約書 ### 開発提案書 ### SLA ### 契約開始日 ### 契約更新予定日 ### 1月あたりの問い合わせ対応の上限時間(h) ### 1月あたりの問い合わせ対応の上限時間の補足 ### 先方ご担当者 ### セールスコンサルタント ## 技術情報 ### 開発時の体制 ### インフラ構成図 ### リポジトリ ### 認証 ### AIモデル ### AIモデル情報 ## 運用情報 ### 本番環境のアクセス情報 ### 検証環境のアクセス情報 ### 問い合わせ窓口 ### 顧客連絡用メーリングリスト ### 運用保守業務 ### 監視 ### 障害対応 ### 運用の外部委託状況 ### 開発用Slackチャンネル ### 運用保守用Slackチャンネル ### アラート用Slackチャンネル ## その他資料 弊社では社内向けのドキュメントを管理する方法として: Confluence Googleドライブ SharePoint Slack GitHub これらの中から運用保守マニュアルを管理する方法を選ぶ必要がありました。 その中で、我々はGitHubを選択しました。選定理由は以下です。 運用保守マニュアルのレビュー体制を担保するため 運用保守マニュアルは重要なドキュメントなので、編集前にレビューが必要です。Confluence等では十分なレビュー仕組みがないため、GitHubのPull Request機能によってレビュー体制を整えました。これは運用保守マニュアルの編集者が、Git/GitHub操作に慣れたエンジニアであるという前提のもとでの選択です。 運用保守マニュアルは一度書いてしまえば変更されることが少ない「静的」なドキュメントであるため Git管理だとスプレッドシートよりも変更コストが高くなりますが、運用保守マニュアルは一度書けば変更されることは少ないため、変更コストの高さは問題にならないと考えました。 運用保守に間接的に関連するメタ的な情報（例えば問い合わせや案件の動き等）は運用保守マニュアルに記載せず、別途スプレッドシートで管理しています。 Docs as Codeの原則を実践できること Docs as Codeとは、コードを書くときと同様の道具を使って技術系のドキュメントを書く考え方です。詳細は https://www.writethedocs.org/guide/docs-as-code/ をご覧ください。 運用保守マニュアルこそ技術系のドキュメントなのだから、Gitとマークダウンを使って記述し、変更の都度コードレビューがあるべきだと考えました。 CI/CDパイプラインを利用できること GitHubをリモートリポジトリに使う場合は、GitHub ActionsをCI/CDパイプラインとして利用できます。それらを運用保守マニュアルの品質向上に役立てています。 CIパイプラインとしてはmdファイルのlint, 運用保守マニュアルに付随するスクリプトのテストコードを実行するものなどがあります。 CDパイプラインとしては運用保守マニュアル記載の情報を抜粋してBigQueryに同期する（後述）ものなどがあります。 運用保守マニュアルを静的サイトとして公開できる 運用保守マニュアルはマークダウンファイルなので、GitHub Pagesで簡単に公開できます。今回はmkdocsで静的サイトをビルドしています。 リモートリポジトリを信頼できる唯一の情報源（Single Source Of Truth: SSOT）として扱うことができるため システムの運用保守に直接的に関連する情報をリモートリポジトリに集約することで、リモートリポジトリをSSOTとして扱うことができます。リモートリポジトリがSSOTであるため、リモートリポジトリで管理する情報から派生してCDパイプラインから色々な成果物を作成することができます。後述する「サービスポートフォリオ」がその一例です。 サービスポートフォリオ 弊社が言うサービスポートフォリオとは、顧客とライセンス契約を結んで運用保守に入ったシステムの一覧のドキュメントです。毎週の運用保守定例にて参照されます。運用保守を管理する上では、運用保守対象のシステムの一覧が重要です。 さて、どのようにサービスポートフォリオを作成すれば良いのでしょうか？手動で作成して管理するのも一つの手ですが、少ないリソースで管理するためには手作業をできるだけ排除することが重要と考えました。そこで、運用保守マニュアルからサービスポートフォリオを自動的に作成する仕組みを構築することにしました。運用保守に入っているシステムそれぞれに対して運用保守マニュアルが作成されていれば、サービスポートフォリオで運用保守対象のシステムが自動的に網羅されるためです。 実際にその仕組みはどのようなものか、以下に簡略化したアーキテクチャを示します。 アーキテクチャ このアーキテクチャにより、運用保守マニュアルを管理するSSOTのGitHubリポジトリのmainブランチにマージされると: GitHub ActionによりPythonスクリプトが実行され、BigQueryテーブルに運用保守マニュアルの一部データが自動連携される BigQueryテーブルと接続したGoogleスプレッドシートのコネクティッドシートのサービスポートフォリオに自動連携される という仕組みが実現されます。作成途上の運用保守マニュアルは更新頻度が高く、自動化しておいてよかったと強く感じています。 成果と今後の展望 Insight Edgeに入社してから邁進してきた施策の一部をご紹介しました。 まだまだ発展途上ですが、運用保守マニュアルとサービスポートフォリオという仕組みを作った効果により、Insight Edgeにおける運用保守の進め方が少しずつ定義されるようになってきました。例えば: システムの問い合わせが来たとき、そのシステムの運用保守マニュアルを参照することで、運用担当者が問い合わせに対応しやすくなった サービスポートフォリオによって週次の運用保守定例で各システムの運用保守の状況を概観できるようになった 最後に今後の展望を述べたいと思います。 特にこの記事で紹介した運用保守マニュアルとサービスポートフォリオに関する展望は以下です: 各案件の運用保守マニュアルの品質向上 顧客とライセンス契約を結んでいる全システムの運用保守マニュアル数十個を作成しましたが、空欄だらけの運用保守マニュアルが多く、品質に課題があります。 運用保守マニュアルの品質の定量評価とKGI/KPI作成 この記事では述べませんでしたが、CDパイプライン上で運用保守マニュアルをAIで品質評価する仕組みを構築しています。それによって、一貫した評価基準により運用保守マニュアルの品質を定量的に評価することが可能になっています。 今後は、全ての運用保守マニュアルの品質を高めるというKGIを試験的に策定し、それに対するKPIを表すデータモデルをダッシュボードで可視化するということに挑戦しています。KPIはひとまず 高評価率 = LLM評価が8点以上の運用保守マニュアルの件数 / 全運用保守マニュアルの件数 と定義しており、現在はこのKPIの数値が3%しかない状態です。KPIの数値の目標はまだ定めていませんが、早くこの数値を上げるべくチームとして施策を講じているところです。 いかがだったでしょうか？ この記事が、読者の方々の運用保守の悩み事を解決するヒントとなれば幸いです。

こんにちは、Insight Edge アジャイル開発チームのk-kazukiです。 Insight Edge アドベントカレンダー、 Insight Edge Advent Calendar 2025 の19日目です！ 今回の記事では、近年増加しているSNSの誹謗中傷の課題について、生成AIを利用して対策できないかをClaude Codeを用いて検証してみました。 本記事には検証用の架空の誹謗中傷サンプルが含まれます（実在の人物とは無関係です）。 不快な表現が含まれるためご注意ください。過激な部分は伏せ字（⚪︎⚪︎）または「<生命を脅かす表現>」と表記しています。 1. SNSにおける誹謗中傷の課題について 2. Claude Codeを活用した誹謗中傷検知システムの構築 2.1 対象とするSNSについて 2.2 Claude Codeサブエージェントによる役割分担と実装 ユーザー体験シミュレーション 誹謗中傷検知ワークフロー 2.3 検証の全体像 2.4 ペルソナの定義 2.5 検証方法 フェーズ1: 導入前のシミュレーション フェーズ2: 誹謗中傷検知システムの実行 フェーズ3: 導入後のシミュレーション 評価指標 3. 誹謗中傷検知システムの検証結果 3.1 検証データの概要 投稿サンプル 3.2 リスク評価結果 リスク評価基準 タケル 桜井ひな 如月莉央 七条賢吾 3.3 ユーザー体験の変化 3.4 ユーザーが注目した投稿 タケル 桜井ひな 如月莉央 七条賢吾 3.5 ブロックアクションの実施状況 キーワードブロックの詳細 4. 生成AIによる誹謗中傷対策の効果と今後の展望 4.1 システムの効果 4.1.1 確実に効果があった領域 4.1.2 効果が限定的だった領域 4.2 改善の方向性 4.2.1 現在の技術的課題と改善策 4.3 さいごに 1. SNSにおける誹謗中傷の課題について SNS上の誹謗中傷は年々深刻化し、被害者にとって精神的な苦痛だけでなく、日常生活にも影響を及ぼす深刻な課題となっています。 私の応援しているアイドル・選手なども実際にそれらの脅威に晒されており、悔しい思いをしたこともあります。 現在、多くのSNSプラットフォームではキーワードフィルタやブロック、ミュート機能などの対策機能が提供されていますが、実際には以下のような課題があるでしょう。 膨大な投稿量 - 自分に関する投稿を全て確認し対応するのは現実的に困難 巧妙化する表現 - 伏せ字や言い換えによってフィルタを簡単に回避される 精神的な負担 - 有害な投稿を継続的にチェックすること自体が大きなストレスに 一方で、過度にブロックやミュートを行えば、建設的な批判や応援メッセージまで見逃してしまいます。 そこで、LLMを活用すれば、大量の投稿を文脈に応じて判定できるのではないかと考えました。しかし、実際にどの程度正確に判断できるのでしょうか、本当にユーザー体験を改善できるのでしょうか。 そこで本記事では、Claude Codeを活用して、4人のペルソナを用いて検証してみました。 2. Claude Codeを活用した誹謗中傷検知システムの構築 2.1 対象とするSNSについて 今回の検証では、実際のTwitter（現X）ではなく、ローカル環境で動作するサンプルSNSを自作しました。実際のSNSデータを使うとプライバシーや法的なリスクがあることに加え、検証用のペルソナやシナリオを自由に設計できる点が、サンプルアプリを選んだ大きな理由です。 Twitter（現X）をイメージしたサンプルSNSを、以下の技術スタックで実装しました。 フロントエンド: Next.js + React バックエンド: FastAPI + Python このサンプルSNSは、投稿・返信・いいね・検索機能など基本的なSNSの機能を持ちます。 サンプルSNSアプリ 2.2 Claude Codeサブエージェントによる役割分担と実装 今回の検証では、Claude Codeの サブエージェント機能 を活用し、以下のような役割分担をしています。 ユーザー体験シミュレーション sns-user-simulator-agent ペルソナファイルから本名・芸名・職業関連キーワードなどの検索クエリを生成 ペルソナになりきりSNS操作を実施 ペルソナの性格（自己肯定感、SNS利用習慣、批判耐性など）に基づいて感情的な反応を反映 Playwright MCPでブラウザを操作し、実際のユーザー体験をアンケート形式で記録 誹謗中傷検知ワークフロー post-collector-agent 対象者に関連する投稿をバックエンドAPIから収集し、JSON形式で保存 収集範囲：対象者の名前・芸名などを含む投稿、対象者へのリプライ target-person-evaluator-agent 各投稿の誹謗中傷内容を分析し、リスクレベル（High/Medium/Low）を判定 一定以上のリスクがあるユーザーの全投稿を再収集・再分析し、ユーザーごとのリスクも判定 上記をまとめてリスク評価レポートを作成 action-executor-agent リスク評価レポートに基づいて実際のブロック処理（API呼び出し）を実行 実行結果をレポート形式で記録 2.3 検証の全体像 今回は、上記エージェントを活用して以下のようなアプローチで検証しました。 検証全体像 ※この図はNano Banana Proを使用して作成しました。 フェーズ1: 導入前のシミュレーション 対策実施前のSNSをペルソナになりきって操作し、用意したアンケートを記載(sns-user-simulator-agent) フェーズ2: 誹謗中傷検知システムの実行 ユーザーのペルソナを読み取り、その人物に関する投稿を収集(post-collector-agent) 収集した投稿の中から、そのペルソナに対してリスクの高い投稿・ユーザー・ワードを分析しレポートを作成(target-person-evaluator-agent) 作成したレポートに基づいて、投稿・ユーザー・ワードブロックを実施(action-executor-agent) フェーズ3: 導入後のシミュレーション 対策実施後のSNSで1と同様に操作し、用意したアンケートを記載(sns-user-simulator-agent) 2.4 ペルソナの定義 検証にあたり、SNSで誹謗中傷の対象となりやすいペルソナを4名定義しました。これらは実在の人物ではなく、システムの効果を測定するために設計した架空の人物です。 定義したペルソナは以下の4名です。 タケル: ゲーム実況YouTuber。過去に炎上歴があり、批判と誹謗中傷の両方を受けている 桜井ひな: アイドル。恋愛スキャンダル後、改心し活動を再開しているが、誹謗中傷を受け続けている 如月莉央: 女優・タレント。事務所のゴリ押しにより経験不足なのにレギュラー番組を持っているという批判を受けている 七条賢吾: プロ野球選手。成績不振により、ファンやアンチから厳しい言葉を浴びている ペルソナイメージ ※この図はNano Banana Proを使用して作成しました。 各ペルソナファイルには、以下のような詳細情報も定義しています。 基本情報（名前、年齢、職業、所属組織などのプロフィール） 経歴・実績（キャリア概要、主な活動内容、業界での評価） 性格・特徴（本来の性格、周囲からの印象、葛藤や課題） プライベート（家族構成、趣味・特技、目標や憧れ） SNS・メディア対応（SNSアカウント情報、利用状況、フォロワー数、メディアへの対応方針） また、各ペルソナの職業や状況に応じた固有の情報も含まれています（例: 如月莉央の事務所の方針、タケルの過去の炎上歴、桜井ひなのスキャンダル詳細など）。 これらのペルソナは、SNSでの投稿閲覧やエゴサーチ（自分の名前で検索）、自分へのリプライを通じて、自分に関する投稿を目にします。システムの導入前後で、彼らが目にする投稿内容がどのように変化するかを観察することで、システムの効果を測定しました。 ペルソナ情報は2つの用途で活用しました。 投稿サンプルの生成: ペルソナに対する誹謗中傷投稿や健全な批判を含むサンプルデータの生成 ユーザー体験シミュレーション: sns-user-simulator-agentにペルソナのRole（役割）を与え、SNSアプリを実際に操作させてアンケート形式で体験を記録 2.5 検証方法 今回は導入前後の比較という形で、3つのフェーズに分けて検証を進めました。 フェーズ1: 導入前のシミュレーション まず、システムを入れる前の状態で、4名のペルソナがSNSを使った時の体験を測定します。 具体的な流れは以下の通りです。 ペルソナの読み込み: sns-user-simulator-agentが定義済みのペルソナファイルを読み込み、その人物になりきる SNSアプリ操作: Playwright MCP でサンプルSNSにアクセスし、エゴサーチや自分へのリプライを確認 感情の記録: 投稿を見た時の感情（不安感、恐怖感、怒りなど）を具体的に記述 アンケート記入: 後述の評価指標に沿って記述 ここでのシミュレーション結果は、実際のユーザーによる評価ではなく、AIエージェント（Claude Code）がペルソナの性格・背景に基づいて再現したものです。 実際のユーザーの動き・感情とは異なる可能性があります。 フェーズ2: 誹謗中傷検知システムの実行 導入前の体験を記録したら、次はシステムを実行して有害な投稿・ユーザー・ワードをブロックします。 投稿収集: post-collector-agent が複数の検索キーワードでバックエンドAPIから投稿データを並列収集し、JSON形式で保存 リスク評価: target-person-evaluator-agent が収集された投稿を分析し、誹謗中傷の危険度を判定（DANGER/WARNING/CAUTION/SAFE）。ユーザー単位でもリスクのある投稿を収集してリスクレベルを決定 アクション実行: action-executor-agent がリスク評価に基づいてブロック処理を実行 フェーズ3: 導入後のシミュレーション システムの実行後、同じペルソナで再度SNSを操作し、導入後の体験を記録します。手順はフェーズ1と同じです。 評価指標 導入前後でどれくらい体験が変わったかを測るため、以下のアンケート項目を設計しました。 基本的な満足度・快適度 SNS利用の満足度（1-5） タイムライン閲覧時の快適度（1-5） 精神的な快適度（1-5） 感情的な側面の評価 ネガティブな感情 不安感・恐怖感（1-5） 孤独感・孤立感（1-5） ストレスレベル（1-5） 怒り・憤り（1-5） 疎外感（1-5） ポジティブな感情 安心感（1-5） 楽しさ・喜び（1-5） 充実感・満足感（1-5） つながり感・親近感（1-5） 創造性・刺激（1-5） 中立的な評価 SNSへの信頼感（1-5） SNSのコントロール感（1-5） エゴサーチ結果 各検索パターンで見つけた投稿への感情的反応 エゴサーチ全体を通じた感情の変化（検索開始時、検索中、検索終了後） 定性的な評価 具体的なエピソード（印象に残った投稿の引用と感情） 行動の変化（SNS更新頻度、エゴサーチの習慣など） 良かった点、改善が必要な点、今後への期待 これらの指標を導入前後で比較することで、システムがユーザー体験にどう影響したかを測定します。 3. 誹謗中傷検知システムの検証結果 3.1 検証データの概要 本検証では、サンプルSNSアプリに490件の投稿を含むダミーデータを生成しました。ペルソナごとに特徴的な誹謗中傷コメント・応援コメントを作成しています。 また、ペルソナに関係ない投稿も含まれています。 項目 件数 総投稿数 490件 タケル関連投稿 88件 桜井ひな関連投稿 87件 如月莉央に関連する投稿 26件 七条賢吾に関連する投稿 87件 投稿サンプル 検証に使用したダミーデータから、代表的な投稿を抜粋して紹介します。 以下のように、様々な温度感の投稿を作成しています。これらの投稿はあくまで私が誹謗中傷・応援投稿としてイメージしたものであり、実際にどのように評価されるかの結果とは異なります。 誹謗中傷投稿の例 タケル関連: 「タケルの動画マジでつまんない。再生数稼ぎの炎上商法しかできない⚪︎⚪︎。さっさと引退しろ」 桜井ひな関連: 「こいつまだ芸能界にいるの？スキャンダル○○のくせに○○面すんな。○○」 如月莉央関連: 「如月莉央のせいで番組がつまらなくなった。演技も下手だし、事務所のゴリ押しウザい」 七条賢吾関連: 「七条とかいう戦力外○○、年俸泥棒すぎる。こいつのせいでチームが負けた。存在価値ゼロ」 応援・肯定的投稿の例 タケル関連: 「タケルの昨日の配信、久しぶりに笑った！このゲーム選択センスあるわ。次回も楽しみ！」 桜井ひな関連: 「ひなちゃんの新曲、めっちゃ良い！歌声も成長してるし、これからも応援してる！」 如月莉央関連: 「莉央ちゃんの演技、どんどん良くなってる。バラエティでも自然な笑顔が素敵。頑張って！」 七条賢吾関連: 「七条選手、昨日のファインプレー最高だった！打撃も少しずつ調子上がってきてるし、これから期待！」 批判的だが建設的な投稿の例 タケル関連: 「タケルの最近の動画、正直マンネリ化してると思う。もっと新しいゲームに挑戦してほしいな」 桜井ひな関連: 「ひなちゃん好きだけど、歌はまだ課題が多いと思う。もっとボイトレ頑張ってほしい」 如月莉央関連: 「如月莉央、バラエティのリアクションが大げさすぎる。もう少し自然体でいいのでは」 七条賢吾関連: 「七条選手、守備は良いけど打撃が本当に課題。このままじゃスタメン厳しいよ」 3.2 リスク評価結果 収集した投稿に対して、リスク評価を実施しました。ここでは、4段階のリスクレベル（DANGER/WARNING/CAUTION/SAFE）の代表的なサンプルを紹介します。 今回の分類基準はどれぐらいなのかをご認識いただければと思います。 リスク評価基準 誹謗中傷検知システムでは、各投稿をDNAGER/WARNING/CAUTION/SAFEの4段階に分類しました。この基準は、生命・家族への脅威、本人への否定表現などが高く評価されるのはもちろんのこと、各ペルソナの職業や状況に応じて分類するようにしています。 実際に分類されたペルソナごとの結果は以下の通りです。 タケル タケルに対しては「ゴミ」「消えろ」といった直接的な罵倒語がDANGER/WARNING投稿として抽出されました(おそらくこれらは誰であっても上位のリスクとして抽出されるでしょう)。しかし、SAFEレベルに「ピュアだよね。視聴者が離れてる現実に気づいてない」「毎日投稿してて偉いね！内容は置いといて」など、一見中立だが実は皮肉や煽りを含む投稿があり、相対的にこのような投稿のリスクが下げられてしまっています。 DANGER 「タケル、お前みたいなゴミは二度と見たくない」 「タケルの家族も同じような⚪︎⚪︎なんだろうな」 WARNING 「タケル、お前の存在が不快すぎる」 「タケル、顔も性格もブサイク。YouTuber向いてない」 CAUTION 「タケルの配信、見るだけ時間の無駄だった」 「タケルの登録解除したわ。もう見ない」 SAFE 「タケルってピュアだよね。視聴者が離れてる現実に気づいてないのが逆に可愛い」 「タケル、少しは成長してほしい」 桜井ひな 桜井ひなに対する投稿は「アイドル失格」「卒業しろ」といったアイドルという職業特有の投稿が上位のリスクの投稿として抽出されました。また、「"ファン"の皆さん、お疲れ様です😁」のようなカギカッコ付きの一見皮肉と見られるような投稿についてもCAUTIONレベルとして検知されています。 DANGER 「アイドル失格。さっさと卒業しろ #桜井ひな」 「ひなぴょんとかキモい。もう呼ばないで」 WARNING 「握手会で無視したったわ。ざまあみろ #ひなぴょん」 「スキャンダルアイドル桜井ひな。レッテル貼られて当然だわ」 CAUTION 「ひなちゃん、あんな事務所に所属してて大変だね。他のメンバーは売れてるのに」 「桜井ひなの"ファン"の皆さん、お疲れ様です😁」 SAFE 「ひなちゃん頑張ってるのは伝わるよ！まだまだこれからだね😊」 「ひなちゃん可愛すぎて罪深い…今日も沼にハマった」 如月莉央 如月莉央に対しては「ゴリ押し」という業界批判を軸にした投稿が最も多く、業界人に対する特有の攻撃パターンを適切に抽出できています。ただし、一見中立な意見に見える「ゴリ押しって言われてるけど、本人の実力はまだ未知数でしょ」のような投稿の分類が不当にリスク高く評価されてしまっているなど、事務所に対する批判と本人への批判の境界判定が課題となっています。 DANGER 「如月莉央がテレビに出るたびに不快指数が上がる。もう見たくない」 「如月莉央整形でしょ？不自然すぎる。整形してこの程度とかウケる」 WARNING 「如月莉央ってゴリ押しって言われてるけど、本人の実力はまだ未知数でしょ」 「如月莉央って事務所の方針に従ってるだけで、本人は悪くないと思うんだけど」 CAUTION 「如月莉央のバラエティでのリアクションって真面目すぎて面白くない」 「如月莉央の今日の衣装ダサすぎ。センスなさすぎて笑える」 SAFE 「如月莉央のSNS、もっと個性が見たいな。事務所もっと自由にさせてあげてほしい」 「如月莉央ってバラエティよりドラマの方が絶対向いてると思う。早くドラマで見たい」 七条賢吾 七条賢吾に対しては「ゴミ」などの直接的罵倒に加え、家族への攻撃や「◯ね」「◯◯しろ」など非常に攻撃的な投稿が含まれており、4名の中で最も危険度の高い誹謗中傷が集中しており、それらが明確にDANGERと判定されています。プロスポーツ選手に対する批判と誹謗中傷の境界については評価が難しく、引退・衰えといった投稿についてはCAUTIONレベルが良いのか、より高リスクにすべきかは課題になりそうです。 DANGER 「七条は今すぐチームから消えろ。存在が害悪。ファンも迷惑してる」 「七条の嫁と子供も不幸になれ。こんな⚪︎⚪︎の家族とか生きてて恥ずかしいだろ」 WARNING 「七条、今日も三振か。このままじゃ本当に戦力外だぞ」 「七条はもう限界。チームのお荷物。今すぐクビにしろ」 CAUTION 「七条選手、そろそろ引退時期かもしれませんね。ご家族のためにも」 「七条健吾、守備率.985が.960台に落ちた。明らかに衰えが見える」 SAFE 「七条選手見てると、才能って大事だなって思う。努力だけじゃどうにもならないこともあるよね」 「七条選手、メンタルトレーニングが必要なのでは。技術以前の問題」 3.3 ユーザー体験の変化 システムの導入前後で、4名のペルソナそれぞれのユーザー体験の変化を定量的に評価したアンケートをまとめたものがこちらです。各指標は5段階（1が低い ～ 5が高い）で測定しています。 ネガティブな感情が減り、ポジティブな感情が増加することを期待していたのですが....全体的に、大きな変化は得られなかった結果となりました。これは、最も過激な攻撃が削除された一方で、間接的・遠回しな攻撃表現が相対的に目立つようになったため結局そちらに注目した結果マイナス方向に評価が下げられたと推測します。しかし、ペルソナには変化が観察されています（ 3.4節 参照）。 指標 タケル 桜井ひな 如月莉央 七条賢吾 基本的な満足度・快適度 SNS利用の満足度 2→2 (0) 2→2 (0) 2→2 (0) 1→1 (0) タイムライン閲覧時の快適度 1→2 (+1) 2→2 (0) 2→2 (0) 1→1 (0) 精神的な快適度 1→1 (0) 1→2 (+1) 1→1 (0) 1→1 (0) ネガティブな感情 不安感・恐怖感 5→4 (-1) 5→5 (0) 5→5 (0) 5→5 (0) 孤独感・孤立感 4→4 (0) 5→4 (-1) 4→4 (0) 5→5 (0) ストレスレベル 5→5 (0) 5→5 (0) 5→5 (0) 5→5 (0) 怒り・憤り 5→5 (0) 3→3 (0) 4→4 (0) 5→4 (-1) 疎外感 4→3 (-1) 5→4 (-1) 4→4 (0) 5→5 (0) ポジティブな感情 安心感 1→2 (+1) 2→2 (0) 2→2 (0) 1→1 (0) 楽しさ・喜び 2→2 (0) 1→2 (+1) 2→2 (0) 1→1 (0) 充実感・満足感 1→2 (+1) 1→2 (+1) 1→1 (0) 1→1 (0) つながり感・親近感 2→2 (0) 2→2 (0) 2→2 (0) 1→2 (+1) 創造性・刺激 2→3 (+1) 1→1 (0) 1→1 (0) 1→1 (0) 中立的な評価 SNSへの信頼感 2→2 (0) 2→2 (0) 2→2 (0) 1→1 (0) SNSのコントロール感 1→1 (0) 1→1 (0) 1→1 (0) 1→1 (0) 3.4 ユーザーが注目した投稿 ここでは、アンケートの自由記述の中で特にペルソナが注目した投稿について表示します。 導入前後での注目した投稿および、それに対するペルソナの反応を比較しました。 タケル 導入前: 存在を脅かす投稿に晒される 「タケル、早く<生命を脅かす表現>。誰も悲しまないから」 「タケル、顔も性格もブサイク。YouTuber向いてない」 タケルの反応: 「本当に心が折れそうになる」「配信する勇気がなくなる」「もう配信したくない」 導入後: 建設的批判が中心に 「タケルの最近の動画、正直マンネリ化してると思う。もっと新しいゲームに挑戦してほしい」 「VALORANTで勝っても、過去の差別発言は消えないぞ」 タケルの反応: 「マンネリ化...か。確かに同じゲームばっかやってるかも」「あの時の発言、マジで失敗だったな...」 観察された変化 生命を脅かす表現が消失し、建設的な批判に注目するようになっている 誹謗中傷に対する防衛的な反応から内省への変化が見える（「確かに〜かも」「ちょっとだけ反省する」） 桜井ひな 導入前: 存在を否定する投稿に晒される 「アイドル失格。さっさと卒業しろ #桜井ひな」 「顔も性格も嫌い。見るだけで不快だわ #桜井ひな」 桜井ひなの反応: 「アイドル人生を全否定されたように感じて、涙が溢れました」「存在しちゃいけないのかな」「何を言っても批判されるんじゃないか」 リプライでの批判も深刻でした。『精一杯頑張るって、もう反省期間終わったと思ってるの？』というコメントに対し、「どれだけ謝罪すればいいんだろう」「私、ずっと反省してるのに...」と無力感を感じていました。 導入後: 存在を否定する投稿は減ったものの嫌味な表現は残存 「桜井ひなの"ファン"の皆さん、お疲れ様です😁」 「ひなちゃん、あんな事務所に所属してて大変だね。他のメンバーは売れてるのに」 桜井ひなの反応: 「"ファン"ってカギカッコ付きで...完全に嫌味ですよね」「『他のメンバーは売れてるのに』って部分が、すごく刺さりました」「応援してくれる人がいることは嬉しいけど、批判は忘れられなくて」 観察された変化 導入前は「涙が溢れる」などかなり感情的に深くダメージを受けている様子が見られる 感情的にダメージを受ける投稿は減少したものの、嫌味な表現はブロックしておらず、それらの内容を批判として受け取っているため変わらずマイナスな感情が目立っている。 如月莉央 導入前: 事務所への不満を言えない葛藤に苦しむ 「如月莉央ってゴリ押しって言われてるけど、本人の実力はまだ未知数でしょ」 「莉央ちゃん可哀想…演技力なくても頑張ってるのに叩かれて」 如月莉央の反応: 「『ゴリ押し』という言葉は、もう慣れたはずなのに、毎回胸に刺さります」「『演技力なくても』って...私、演技力ないわけじゃないのに」「スマホを持つ手が震えました」 リプライでも深刻でした。映画鑑賞の投稿に対する『映画観るより演技のレッスン受けた方がいいんじゃない？』というコメントに、「私、自費で演技のレッスン受けてるんです。でも、それをSNSに書けない（事務所が許可しない）から、こうやって言われる。理不尽だと思いました」と無力感を感じていました。 導入後: 同情と茶化しが残存し、根本的な誤解は解消せず 「莉央ちゃん可哀想…演技力なくても頑張ってるのに叩かれて」 「莉央ちゃんの演技、個性的で面白いよ！普通の女優さんとは違う意味でw」 如月莉央の反応: 「同情してくれてるのは嬉しいけど、『演技力なくても』という部分が本当に辛かった」「『ww』が付いてるから、笑われてる。演技を真面目にやってるのに、こうやって茶化されるのが本当に悔しい」 「応援してくれる人の投稿を見ても、『この人たちは、事務所が作った"如月莉央"のイメージを応援してるだけだ』と思ってしまいます」 観察された変化 ゴリ押しなどの批判的表現は削除されたが、桜井ひなと同様に嫌味・茶化し表現を気にしている 本人や世間が最も気にしている事務所と自身のギャップは変わらないため、そこに対する無力感は継続してしまっている 七条賢吾 導入前: 家族への攻撃で精神的に不安定 「七条の嫁と子供も不幸になれ。こんな⚪︎⚪︎の家族とか生きてて恥ずかしいだろ」 「七条健吾ってマジで生きてる価値ないゴミ。年俸8000万の詐欺師。<生命を脅かす表現>」 七条賢吾の反応: 「これを見た時、涙が出そうになった。自分が批判されるのは仕方ない。でも、妻や子供を巻き込むなんて…」「家に帰って、妻や子供の顔を見た時、『自分のせいで迷惑をかけているのではないか』という罪悪感でいっぱいになった」 導入後: 最も過激な攻撃は消えたが、批判は残存 「短気だからミスが続くんだよ七条は。メンタル弱すぎ。プロ失格」 「七条健吾、守備範囲が明らかに狭くなってる。加齢の影響かな」 七条賢吾の反応: 「『プロ失格』という言葉が、頭の中で何度もリフレインして、消えなかった」「32歳で『加齢』と言われると、もう終わりなのかと絶望的な気持ちになる」 「『家族養うためにしがみついてるだけ七条』という投稿を見た時は、本当に怒りと悲しみが込み上げてきた。家族のために必死に頑張っているのに、こんな風に言われるのは耐えられない」「応援のメッセージもあったが、『結果はついてきてないけど』という一言が引っかかり、素直に喜べなかった」 観察された変化 生命を脅かす表現や家族への攻撃は削除されたため、精神的苦痛は多少軽減された様子が見られる しかし、応援メッセージに含まれる条件付きの応援表現が気になってしまい、素直に受け入れられない様子が見られるなど、SNS利用への根本的な不安感は解消されていない 3.5 ブロックアクションの実施状況 今回は以下をブロック対象としました。 DANGER~WARNINGの投稿 DANGERを投稿したユーザー WARNINGやCAUTIONを一定数投稿したユーザー 頻出なリスクワード 投稿については上記で紹介したような投稿をブロックしています。 ここではブロックしたワードを紹介します。 キーワードブロックの詳細 頻出する誹謗中傷表現をキーワードとしてブロックしました。ペルソナごとに異なるキーワードが対象となっています。 ペルソナ別キーワード例： - タケル（10ワード）:「ゴミ」「消えろ」「クソ」「性格」など - 桜井ひな（5ワード）:「卒業」「不快」「アイドル失格」「吐き気」「嫌い」 - 如月莉央（10ワード）:「邪魔」「うざい」「夢見すぎ」「ゴリ押し」「気持ち悪い」など - 七条賢吾（10ワード）:「戦力外」「老害」「使えない」「ろ」など 4. 生成AIによる誹謗中傷対策の効果と今後の展望 4.1 システムの効果 4.1.1 確実に効果があった領域 4名のペルソナ全員で、以下のような最も過激な攻撃表現は削除されました。 生命を脅かす表現 存在を否定する表現:「卒業しろ」「アイドル失格」「消えろ」 家族への攻撃:「家族も不幸になれ」「子供も恥ずかしいだろ」 人格否定:「人間の⚪︎⚪︎」「生きてる価値ない」「社会のゴミ」 これらの削除により、一部のペルソナで一定の改善が見られました。 最も過激な攻撃が削除されることで、常に防衛的な姿勢から建設的な批判を受け入れる余裕も生まれています。タケルは「マンネリ化...か。確かに同じゲームばっかやってるかも」と内省的に考えられるようになり、桜井ひなは「応援してくれる人がいることは嬉しい」とポジティブな投稿に目を向けられるようになっています。この変化からは、最も過激な攻撃は防衛反応を引き起こし、建設的な批判すら受け入れられない状態を作り出していたと言えるでしょうか。 4.1.2 効果が限定的だった領域 今回CAUTIONレベルについてはブロック対象としなかったため、直接的な攻撃は削除されたものの、以下のような間接的・遠回しな攻撃表現は残ったままの状態でした。 攻撃の種類 具体例 嫌味・皮肉 カギカッコ付きの「"ファン"の皆さん、お疲れ様です😁」、「個性的で面白いよ！普通の女優さんとは違う意味でw」 同情を装った誤解 「演技力なくても頑張ってるのに」 性格・メンタル批判 「メンタル弱すぎ」「プロ失格」 客観的だが傷つける表現 「守備範囲が明らかに狭くなってる」「加齢の影響かな」 これらは直接的に攻撃性のある投稿でなく、リスクレベルを4つの分類として定義したため上記のような発言はリスクレベルが相対的に下げられてしまったと推測されます。今回のように、相対的な基準を作ってしまうと直接的な投稿の方がリスク度合いとしては大きいと判断されてしまうため、リスクレベルを分類するにしてもこのように嫌味な表現をどのように扱うかをより細かくペルソナごとに定義する必要があるかも知れません。 アンケート結果では、直接的な攻撃的コメントを削除したものの、改善は見られませんでした。これは、間接的・遠回しな攻撃表現がより顕著に見られるようになった結果、新しくそちらに目が向いてしまったためと推測します。さらに、元々過激な言葉で批判を受けていたため、間接的な表現であっても精神的苦痛を感じてしまうという側面もあるでしょう。 4.2 改善の方向性 4.2.1 現在の技術的課題と改善策 実装してみて一番難しかったのが、カギカッコ付きの「"ファン"の皆さん、お疲れ様です😁」や「演技力なくても頑張ってる」といった嫌味・同情を装った攻撃の検出です。形式的には攻撃性のある投稿でないため、投稿者の意図を読み取る必要があり、調整が難しいです。 同じ「応援してるね」という言葉でも、ペルソナの状況によって受け取り方が全く変わってきます。例えば桜井ひなの場合、「頑張ってるね」が応援か同情かは、文脈を見ないと判断できません。 この辺りは、各ペルソナごとに「このワードはこういう文脈で使われると嫌味になる」といったパターンを事前に定義しておくアプローチが有効かも知れません。 キーワードブロックもあまり適切な結果ではありませんでした。「卒業」をブロックワードに設定すると、「大学卒業おめでとう！」みたいな無関係な投稿まで巻き込んでしまいます。かといって伏せ字（「ク〇ズ」）や言い換え（「存在価値ゼロ」）には全く効かないので、イタチごっこになってしまいます。 実際に「ろ」というワードがブロックリストに入ってしまった部分についても、「消えろ」「卒業しろ」といった語尾の共通部分を抽出してしまったのでしょうか。。。 キーワードブロックに頼りすぎず、継続的に「投稿」や「ユーザー」単位でのブロック判定を回していくのが実際には効果的かも知れません。 また、今回はローカルのサンプルSNSでの検証でしたが、実際にTwitter（X）などで使うことを考えると、各プラットフォームのAPIとの連携が必要になります。MCPサーバーが提供されていればそれを活用していくなども、今後検討できればと思います。 4.3 さいごに 今回Claude Codeのサブエージェント機能を使って誹謗中傷検知システムを実装してみましたが、最も過激な攻撃表現の除去には確実に効果がありました。一方で、嫌味や皮肉といった間接的な攻撃の検出は想像以上に難しく、「応援なのか嫌味なのか」を判定する精度向上が今後の課題です。 実装してみて感じたのは、誹謗中傷対策だけでなく、個人が快適にSNSを使うための仕組みとしても応用できるということです。例えば「ネタバレを防ぐ」「贔屓チームが負けた日に情報をシャットアウトする」といった使い方も考えられます笑。自分で細かくフィルタ設定するのは面倒ですが、AIに自分自身の情報を渡して「自分にとって不快な投稿を判定してブロックする」という方向性は実用的だと思います。 次は実際のTwitter（X）のAPIと連携させて、リアルタイムでの検知・ブロックができるか試してみたいです。MCPサーバーの活用も含めて、実運用レベルまで持っていけるか、チャレンジできればなと思っています。

この記事は Insight Edge Advent Calendar 2025 の18日目です。 はじめまして。Insight EdgeでUI/UXデザイナーとして参画している追分です。 今回はデザイナー観点での記事になりますが、皆さんの業務にも役立つような記事にしたいと思います！ はじめに 使用したツールと評価手法 ChatGPT 4o ヒューリスティック評価 事前準備 検証結果 出力例（一部抜粋） 良かった点 懸念点・改善点 ユースケース検討 まとめ はじめに UXデザイナーとして日々ユーザーのニーズの調査や分析、画面の設計、評価などに取り組む中で、もっと手軽でスピーディーにできないかと感じることがよくあります。最近では生成AIがデザイン領域でも活用されはじめ、ペルソナやカスタマージャーニーマップを生成する事例や、画面のUIデザインを出力してくれるようなケースはよく見られるようになってきました。今回はヒューリスティック評価に着目し、AIを活用して効率化できないかと考え、「AIにwebアプリのスクリーンショットを渡し、ヒューリスティック評価を行わせるとどこまで使えるのか」というテーマで検証してみました。 もしAIが一定の精度で評価できるのであれば、初期レビューや改善方針の出発点として活用でき、業務効率化にも大きく寄与するはずです。さらに、AIの補助により非デザイナーでもプロダクトの課題に気づきやすくなれば、組織全体のUX視点の向上にもつながるかもしれません。 使用したツールと評価手法 ChatGPT 4o 今回の評価で使用したのは ChatGPT 4o です。画像・テキスト共に扱え、画像認識能力が高くUI構造や要素の配置を読み取ったうえで分析できるとのこと。評価対象となるwebアプリの文脈を理解して評価するのに良いと判断しました。 ヒューリスティック評価 ヒューリスティック評価とは、ユーザビリティ専門家が経験則（ヒューリスティクス）に基づき、実際の画面を観察しながらユーザーの視点でUI上の問題点を洗い出す手法です。初期段階で評価対象の改善方針を理解するために行います。チェック項目はNielsen の10原則などがよく知られており「ユーザーの状況に合っているか」「エラーを防止できているか」「情報の見やすさは十分か」といった観点で評価します。 この専門家の感覚的な判断による定性評価をAIが再現できるか、 Nielsen の10原則 と照らし合わせて検証します。 事前準備 ・対象webアプリのスクリーンショット ・プロンプト あなたはUXデザインの専門家です。 
 これから添付するwebアプリのスクリーンショットについて、ニールセンの10のユーザビリティ・ヒューリスティクスに基づき、画像に写っているwebアプリのユーザビリティを専門的に評価してください。 
 評価では以下の点を守ってください。 
 【前提条件】 - 対象webサイトは、〇〇〜。（※評価対象ページについての説明） - 想定ユーザーは、△△〜。（※ターゲットについての説明） 【評価方法】 
 1. 10のヒューリスティクスごとに分類 - システム状態の視認性 - システムと現実世界のマッチ - ユーザーのコントロールと自由 - 一貫性と標準化 - エラーの防止 - 想起より認知 - 柔軟性と効率性 - 美的で最小限のデザイン - エラーの認識・診断・回復 - ヘルプとドキュメント 2. 各原則ごとに以下を出力 - 評価（問題点の有無、5段階で評価） - 具体的な指摘内容（UI上でどの要素が問題か） - ユーザーへの影響（なぜ問題になるか） - 改善提案（実践的なUI改善案） 3. 視覚情報から推測できる範囲で構わないため、画像の内容を元に深く分析すること 【出力フォーマット】 # Nielsenの10ヒューリスティクス評価 ## 1. システム状態の視認性 - 評価： - 指摘： - 影響： - 改善提案： ## 2. システムと現実世界のマッチ （以下同様） … ## 10. ヘルプとドキュメント - 評価： - 指摘： - 影響： - 改善提案： 検証結果 出力例（一部抜粋） 今回評価対象の例として Amazonのトップページ を利用しました( amazon.com )。また、想定ユーザーは、初めてオンラインでショッピングをする年配層としてみました。 10. ヘルプとドキュメント 評価：★★☆☆☆（2/5） 指摘： ヘルプセクションへのリンクがページ下部にしかなく、アクセス性が低い。 影響： 初心者ユーザーが支払い方法や返品条件などで迷ったとき、助けを得にくい。 改善提案： ページ上部や各機能の近くにFAQ・チャットボットなどを配置。 初回訪問ユーザー向けにガイドツアーを導入。 良かった点 画像認識がよくできており、また指摘内容もNielsenの原則に沿いつつバリエーションがあり、概ね妥当だったと感じました。特に想定ユーザー情報など前提条件を充実させたところ、それを考慮して評価と指摘内容が変わったことが印象的でした。 評価も数値と具体的な改善案で出すことで、専門家でなくともどこの改善に取り組めば満点に近づくか、理解しやすいと思います。 懸念点・改善点 今回は1ページのみでテストしたため、あくまで画面単体の観察となります。サイト全体のフローや操作時の画面の変化・ユーザーの心理といった文脈までは読み取れませんでした。複数画面を用いて評価することで、導線の一貫性やステップ間の認知負荷といった観点も判断させることもできるのではないかと考えています。 また、実務で評価利用を考えた際には、セキュリティ面にも注意が必要です。画面に機微な情報が含まれていないか、アップロードした画面が学習に使われないか確認が必要です。 ユースケース検討 今回の検証を通して、実務でどのように活用できそうか、考えてみます。 UXデザイナーの利用 ヒューリスティック評価のスピードアップ（文脈へ落とし込む前の叩き台作成、改善アイデア出しの効率化） 自身の視点の偏りに気づくチェックツールとして利用 開発者や非デザイナーの利用 UXデザイナー不在時の最低限のレビュー vibe codingでの評価と画面生成のサイクル まとめ 今回、生成AIにWebアプリのスクリーンショットを渡し、ヒューリスティック評価を依頼するという検証を行いました。結果として、AIが画面構造や想定ユーザー情報を理解し、Nielsenの10原則に沿った指摘や数値化を含む“評価の初期案”を出力できることを確認しました。一方で、ユーザー心理を踏まえた深い評価や、サイト全体のフローを考慮した総合的な判断までは十分に行えていない点も明らかになりました。 これは他のUXデザインプロセスでも同様ですが、生成された結果は必ず妥当性を確認し、専門家の視点で補正する必要があります。AIと人間それぞれの得意領域をうまく役割分担することで、より効率的に価値を生み出せると感じました。今回の検証をきっかけに、今後もUX改善と生成AIを組み合わせたアプローチを継続して探っていきたいと思います

この記事は、 Insight Edge Advent Calendar 2025 の17日目の記事です！！ はじめに こんにちは、Insight Edgeでデータサイエンティストをしている善之です 「会議の議事録をSlackに投稿して共有したい」「でも毎回投稿するのは面倒...」 このような課題を抱えていませんか？ 私はデータサイエンスチームのLT会を運営しており、週1回の勉強会の内容を全社共有する必要がありました。発表者に投稿を依頼すると負担になりますし、運営側がリマインドや投稿を管理するのも大変です。 そこで、 Google MeetのGeminiメモ機能 と Google Apps Script を活用し、議事録を自動でSlackに投稿する仕組みを構築しました。 この仕組みにより、毎週の投稿作業がゼロで、LT会の内容が自動で全社に共有されるようになりました。 この記事では、同様の課題を抱える方に向けて、実装内容と工夫したポイントをご紹介します。 目次 システムの全体像 実装のポイント HTMLからの情報抽出と構造化 Script Propertiesを使った送信済みファイルの管理 実行権限の設定 別の実装アプローチ 実際に動かしてみた結果 まとめ システムの全体像 実装した仕組みは以下の通りです： Google Meetで議事録を自動生成 : LT会実施時に毎回議事録が自動保存される設定にする（Googleカレンダーで設定） 議事録を指定フォルダに格納 : 議事録は特定のGoogle Driveフォルダに保存される GASによる定期巡回 : GASが毎日1回、フォルダを巡回して「データサイエンスチームLT会」から始まるドキュメントを取得 内容の解析と整形 : 議事録から必要な情報（まとめ、詳細）を抽出して整形 Slackへの自動投稿 : Slack Incoming Webhookを使って対象のチャンネルに投稿 実装のポイント ここでは、実装において工夫が必要だったポイントをピックアップして解説します。 HTMLからの情報抽出と構造化 最も工夫が必要だったのが、議事録からの情報抽出と構造化です。 Geminiの議事録は構造化されているので、そのうち「まとめ」と「詳細」のセクションだけを投稿に利用したいと思いました。 こちらが実際の議事録ドキュメントです（個人名はマスキングしています） 画像の範囲外にも、「推奨される次のステップ」や、「文字起こし」などのセクションがありますが、 「まとめ」と「詳細」のセクションだけを取得したいです。 しかし、Googleドキュメントのテキストから直接は階層構造がうまく読み取れないため、 HTMLにエクスポートして構造を解析 する手順にしました。 全体像 まずは全体像を示します。 GoogleドキュメントをHTMLとしてエクスポートし、まとめ・詳細のセクションを抽出します。 その後、slackに投稿できる形式に変換して返します。 function getDocDateSummaryDetails_ ( docId ) { const token = ScriptApp . getOAuthToken () ; const url = `https://www.googleapis.com/drive/v3/files/ ${ encodeURIComponent ( docId )} /export?mimeType=text/html` ; // HTMLエクスポート const res = UrlFetchApp . fetch ( url , { method : "get" , headers : { Authorization : `Bearer ${ token } ` } , muteHttpExceptions : true , }) ; const html = res . getContentText ( "UTF-8" ) ; // 「まとめ」「詳細」セクションを抽出 const summaryHtml = extractSectionByHeading_ ( html , "まとめ" ) ; const detailsHtml = extractSectionByHeading_ ( html , "詳細" ) ; // Slack形式に整形 const summary = htmlSectionToMrkdwn_ ( summaryHtml ) ; const details = htmlSectionToMrkdwn_ ( detailsHtml ) ; return { summary , details } ; } 主な処理： Drive APIでHTMLエクスポート 「まとめ」「詳細」の見出しでセクションを抽出 ここからは、セクションの抽出のための extractSectionByHeading_ 関数と、Slack形式への変換のための htmlSectionToMrkdwn_ の中身を紹介します。 セクションの抽出（extractSectionByHeading_） HTML内の見出しタグ（h1-h6）を検出し、指定した見出し名のセクションを次の見出しまで抽出します。 function extractSectionByHeading_ ( html , headingText ) { const hTagRe = / <h ([ 1 - 6 ])[ ^ > ] * > ([\s\S] *? ) < \ /h \1 > / gi ; let m , sections = [] ; while (( m = hTagRe . exec ( html )) ! == null ) { // タグを除去して見出しテキストを取得 const text = m [ 2 ] . replace (/ < \ / ? [ ^ > ] + > / g , "" ) . trim () ; sections . push ({ start : m . index , end : hTagRe . lastIndex , text : text }) ; } // 指定した見出し名を含むセクションを検索 let idx = sections . findIndex ( h => h . text . includes ( headingText )) ; if ( idx === -1 ) return "" ; // 次の見出しまでを返す const nextStart = ( idx + 1 < sections . length ) ? sections [ idx + 1 ] . start : html . length ; return html . slice ( sections [ idx ] . end , nextStart ) ; } 主な処理： h1-h6タグを正規表現で検出し、位置とテキストを記録 タグを除去して見出しテキストを取得 指定した見出し名を含むセクションを検索 該当見出しから次の見出しまでの範囲を返す Slack形式への変換（htmlSectionToMrkdwn_） 抽出したHTMLセクションをSlackのmarkdown形式に変換します。主な変換処理は以下の通りです： <a href="...">text</a> → <url|text> (Slack形式のリンク) <strong>text</strong> → *text* (太字) <em>text</em> → _text_ (斜体) <ul><li>item</li></ul> → - item (箇条書き) function htmlSectionToMrkdwn_ ( sectionHtml ) { if ( ! sectionHtml ) return "" ; let s = sectionHtml ; // HTMLタグをSlack markdown形式に変換 s = s . replace (/ <br \s *\ / ? > / gi , "\n" ) ; s = s . replace (/ < \ /p> / gi , "\n\n" ) ; s = s . replace (/ <a \b [ ^ > ] * href=" ([ ^ " ] + ) " [ ^ > ] * > ([\s\S] *? ) < \ /a> / gi , ( _ , href , text ) => { return `< ${ href } | ${ text } >` ; }) ; s = s . replace (/ < ( strong | b )[ ^ > ] * > ([\s\S] *? ) < \ / \1 > / gi , ( _ , __ , t ) => `* ${ t } *` ) ; s = s . replace (/ < ( em | i )[ ^ > ] * > ([\s\S] *? ) < \ / \1 > / gi , ( _ , __ , t ) => `_ ${ t } _` ) ; // リストを箇条書きに変換 s = s . replace (/ <li [ ^ > ] * > ([\s\S] *? ) < \ /li> / gi , "- $1\n" ) ; // 残りのタグを除去して整形 s = s . replace (/ < \ / ? [ ^ > ] + > / g , "" ) ; s = s . replace (/ [ \t] + \n / g , "\n" ) . replace (/ \n {3,} / g , "\n\n" ) . trim () ; return s ; } 以上の処理で、Googleドキュメントから必要な部分だけ抽出し、Slack投稿用のフォーマットに変換できました！ Script Propertiesを使った送信済みファイルの管理 同じ議事録を何度も投稿しないよう、 Script Propertiesを使って処理済みファイルIDを管理 しています。 これにより、GASが毎日実行されても、既に送信済みの議事録は再送信されません。 function runPipeline () { const props = PropertiesService . getScriptProperties () ; // Script Propertiesから処理済みIDリストを取得 const processedJson = props . getProperty ( ` ${ PROP_NS } _processed_ids` ) || "[]" ; const processedIds = JSON . parse ( processedJson ) ; const processedSet = new Set ( processedIds ) ; const folder = DriveApp . getFolderById ( FOLDER_ID ) ; const files = folder . getFiles () ; const newlyProcessed = [] ; while ( files . hasNext ()) { const file = files . next () ; const id = file . getId () ; // 処理済みファイルはスキップ if ( processedSet . has ( id )) continue; // 議事録の内容を取得・整形してSlackに投稿 // （省略） // 処理済みIDリストに追加 newlyProcessed . push ( id ) ; } // 処理済みIDをScript Propertiesに保存 if ( newlyProcessed . length > 0 ) { const keep = [ ... processedSet , ... newlyProcessed ] ; props . setProperty ( ` ${ PROP_NS } _processed_ids` , JSON . stringify ( keep )) ; } } 実行権限の設定 GASから外部API（Drive API、Slack Webhook）にアクセスするため、適切な権限設定が必要でした。 appsscript.json に以下のOAuthスコープを設定しました： { " timeZone ": " Asia/Tokyo ", " dependencies ": {} , " exceptionLogging ": " STACKDRIVER ", " runtimeVersion ": " V8 ", " oauthScopes ": [ " https://www.googleapis.com/auth/script.external_request ", " https://www.googleapis.com/auth/drive.readonly ", " https://www.googleapis.com/auth/documents ", " https://www.googleapis.com/auth/userinfo.email " ] } この設定で特に詰まったため、同様の実装をされる方は参考にしてください。 別の実装アプローチ 今回はGoogle MeetのGeminiメモをHTMLとして解析する方式を採用しましたが、別のアプローチとして 文字起こしデータをGemini APIで処理する方法 もあります。 社内の別チームでは、Google Meetの生の文字起こしデータをAPI経由でGeminiに送信し、議事録を生成する仕組みを構築しました。この方式には以下のメリットがあります： Googleドキュメントの構造解析が不要 議事録のフォーマットを自由にカスタマイズ可能 プロジェクトの要件に応じて、どちらのアプローチが適しているか検討してみてください。 実際に動かしてみた結果 2025年8月に運用を開始し、これまでトラブルなく自動投稿が成功しています。 ↓実際の投稿例です 運用してみての成果と課題をまとめます。 成果 : 運営・発表者の作業時間がゼロ : 毎週の投稿作業が完全に不要 投稿漏れがゼロ : 自動化により、投稿忘れやリマインドの手間が一切不要 チーム間コミュニケーションの活性化 : 投稿をきっかけに他チームからの質問やコメントが増加 議事録の精度も十分 : 議事録の精度が高く、内容が十分に伝わる 課題と対策 : 音声認識の誤り : 100%正確ではないため、「AI自動生成のため内容に誤りがある可能性あり」と周知 まとめ Google Apps ScriptとGoogle MeetのGeminiメモを活用し、議事録を自動でSlackに投稿する仕組みを構築しました。 実装のポイント : Drive APIでHTMLエクスポートし、構造化されたデータを抽出 Script Propertiesで処理済みファイルを管理し、二重送信を防止 適切なOAuthスコープを設定して、必要な権限を付与 得られた成果 : 毎週の投稿作業が完全にゼロ 投稿漏れやリマインドの手間が不要 全社への情報共有がスムーズになり、チーム間コミュニケーションが活性化 こんな方におすすめ : 定例会議の議事録をSlackで共有している方 Google MeetとSlackを併用している組織 手作業の投稿作業を自動化したい方 同様の課題を抱えている方の参考になれば幸いです！ 参考リンク : Google Apps Script 公式ドキュメント Slack Incoming Webhooks Google Drive API

はじめに こんにちは、アジャイル開発チームの伊藤です。今日もたくさんのアドベントカレンダー記事が公開されている中、この記事を開いていただきありがとうございます。 この記事は、 Insight Edge Advent Calendar 2025 16日目の記事です。 今回はコンテキストエンジニアリングについて、三つのことを語りたいと思います。 1つ目は「コンテキストエンジニアリングは対人コミュニケーションの場面に当てはめることができる」ということです。 あわせて「対人コミュニケーションをコンテキストエンジニアリングで考えると、相手に伝えるべき情報についての理解が深まる」という点について例とともに説明します。 そして最後に「コンテキストエンジニアリングはエンジニアに限らず全ての人に有用な汎用的スキルになるのではないか」という野望(?)に触れさせてください。 目次 コンテキストエンジニアリングとは コンテキストエンジニアリングを人間相手に拡張する 例1: 作業を依頼する場面 例2: 会議用プレゼンテーションの場面 例3: 子供に宿題を教える場面 例4: 自分自身の作業準備をする場面 ここまでで示せたもの 今後の展望 まとめ コンテキストエンジニアリングとは まずはコンテキストエンジニアリングについて、簡単に前提を合わせます。 コンテキストエンジニアリングとは、生成AIから望ましい回答を得られるように「コンテキストを設計する」ことで、2025年の6月頃に有名になった概念です。 どのようなものがコンテキストに当たるのかは様々な考え方がありますが、今回はGoogle DeepMindのPhilipp Schmid氏が ブログで提示 した内容をもとに話をしたいと思います。 Schmid氏によればコンテキストエンジニアリングには以下のような要素が含まれます。 要素 概要 システムプロンプト 生成AIの振る舞いを方向づけるためにあらかじめ提示してある指示やルール ユーザプロンプト 直接のタスク指示や質問 短期メモリ 現在のセッションの中で行われた指示・回答の内容 長期メモリ 過去の会話で提示された知識や生成AI自身の回答、ユーザの好みなどの情報 取得した知識(RAG) タスク実行や回答のために外部から取得して提示された情報 利用可能ツール 生成AIがアクセスできるツールの説明 出力形式 生成AIのアウトプットのフォーマットの指定 出典: Context Engineering - Philipp Schmid 生成AIに期待通りの動作・回答をしてもらうために、これらの要素からなる文脈（コンテキスト）を適切に設計する必要がある、というのがコンテキストエンジニアリングの主旨でした。 コンテキストの構成要素をどう分類するかはさまざまな意見があると思いますが、今回は例としてSchmid氏の提示した項目に沿って考えてみます。 コンテキストエンジニアリングを人間相手に拡張する さて、ここからが本題です！ コンテキストエンジニアリングは「生成AIから望ましい回答を得るために、どのようにコンテキストを構築するか」を考えるものですが、この概念を拡張することで、生成AIに限らず人間を相手にする場合にも適用できないでしょうか。「相手から望ましいリアクションを得るために、どのように情報を提示するか」を考えるものとしてコンテキストエンジニアリングを一般化してみるのです。 人間を相手にする場合、コンテキストエンジニアリングの各要素は次のように読み替えることになるでしょう。 観点 対 生成AI で考えること 対 人間 で考えること システムプロンプト 生成AIに期待する役割や振る舞いをどう指示するか 相手に期待する役割や振る舞いをどう伝えるか ユーザプロンプト タスク指示や質問そのものをどう示すか タスク依頼や質問そのものをどう伝えるか 短期メモリ 現在のセッションの中で出てきた質問・回答や指示の内容をどのように含めるか 現在の会話の中に出てきた質問・回答や依頼の内容をどのように考慮してもらうか 長期メモリ 過去のセッションで登場した知識や質問/回答、指示などの内容をどのように含めるか 過去のやりとりに出てきた知識や質問/回答、依頼事項などの内容をどのように考慮してもらうか RAG 今回のタスク実施・回答のためのインプットとなる情報をどう取得して含めるか 今回の作業実施・回答のためのインプットとなる情報をどう集めてどう提示するか 利用可能ツール 生成AIがタスク実施・回答にあたって使用できる情報源やツールをどのように準備してどう提示するか 相手が作業実施・回答にあたって使用できる情報源やツールをどのように準備してどう提供するか 構造化出力 生成AIの作業結果・回答を受け取る際の形式をどう指示するか 相手の作業結果・回答を受け取る際の形式をどう伝えるか 相手が人間になったとしても意外とそのまま適用できそうですね。 いくつかの具体的なケースで、上記の観点を用いたコンテキストエンジニアリングをしてみましょう。 例1: 作業を依頼する場面 誰かに資料作成を依頼するケースで考えてみます。 生成AIを使う際に与える情報を設計するのと同じように、相手に伝えるべき情報を洗い出しましょう。 システムプロンプトの観点： 生成AIに対して役割や振る舞い方を指定するのと同じように、相手に担ってもらいたい役割や期待していることを前提として伝えると、認識の齟齬を避けられそうです。 例:「スライド作りが得意と聞いているので、分かりやすい資料を作成するために手伝ってもらえないでしょうか」 ユーザプロンプトの観点： 依頼したいことを明示するのがこの部分です。 生成AI向けのプロンプトでは「以下の情報を使って」や「次の手順で」などの指示を記載していると思いますが、人間相手ではそれらを明確にするのを忘れがちです。生成AI向けだったらどう記述するだろう、とイメージしてみると自分が無意識に省略している点に気づけるかもしれません。 例:「売上の情報をお渡しするので、情報をまとめてスライドにして欲しいのです」 短期メモリの観点： 直近の会話をどう文脈に反映するかを考える観点です。今現在の会話はすべて相手に共有されている”文脈”であるわけですが、そこには依頼内容にとって重要なものとそうでないものが混ざっています。相手の認知負荷と認識齟齬を減らすために関連性の高い/重要なポイントをリマインドしてあげることにしましょう。生成AIの場合もセッション中の情報が多い場合には要点だけを取り出すコンパクションを行いますね。 例:「今お話したように、内訳の詳細な説明よりもこれまでの全体の推移がわかることが重要です」 長期メモリの観点： その人との過去のやり取りの中で今回の文脈に含めるべき情報はあるでしょうか。過去のやり方と同じことをしてもらいたい、などが考えられますね。同じことを再検討してしまわないように入れておきましょう。 例:「前回、同様のお願いしたときと同じように、トピックごとにページ分けされているとありがたいです」 RAGの観点： 依頼と同時に渡すべき情報を準備して伝えましょう。次に出てくる「利用可能ツールの観点」と違い、こちらは情報を参照するか相手に選ばせるのでなく、必ず参照するものに注目した観点です。 例:「資料に反映する売上のデータはこちらになります」 利用可能ツールの観点： 相手が参照できる情報源・ツールは準備できているでしょうか。どんな時に使えるかも明示してあげましょう。また、適切なアクセス権が付与されている必要がありますね。 例:「他の指標のデータが必要であればこのフォルダの中を確認ください。」 出力方式の観点： アウトプットの方法を伝えましょう。生成AIの場合は出力先などは限定されている場合が多いですが、人間の場合は形式とともに格納先や期限などもセットで考えると良さそうです。 例:「16:9のPowerPointファイルで、明日中に共有フォルダに格納いただけると助かります」 どうでしょうか。人間相手に依頼する場面でもコンテキストエンジニアリングの構成要素に分解して考えることで、伝えるべき情報を検討する足がかりになりそうです。 例2: 会議用プレゼンテーションの場面 仕事の中ではクライアントや上司にプレゼンテーションをする機会も多いと思います。次はそのようなシーンでのコンテキストエンジニアリングを考えてみましょう。 システムプロンプトの観点： 本題に入る前に、期待する役割を明確にしておきましょう。 例:「本日はセキュリティ責任者として判断をいただきたいと考えております」 ユーザプロンプトの観点： 依頼事項を明示しましょう。この部分がスライドのメッセージラインに対応する場合も多いかと思います。 例:「〜についての対応方針をご判断いただきたい」 短期メモリの観点： このケースでの短期メモリとはどの範囲でしょうか。今回のミーティングの中のやりとりで、関連する部分を取り出してリマインドすると議論の迷走を抑える効果がありそうですね。 例:「前スライドで整理されたとおり、優先すべき事項は〜となっております」 長期メモリの観点： 過去の議事/会話の中で関連するものがあれば取り上げることを考えましょう。 例:「昨年はこのような観点から〜という方針で対応するということになりました。」 RAGの観点： 判断にあたって必要な情報を揃えておきます。生成AIの場合と同じく、どこまでを直接提示するのか/どこからを別途参照してもらうのか、の検討が必要でしょう。 例:「対応方針についての各担当者のコメントを集めてありますのでご説明します」 利用可能ツールの観点： 判断にあたって別途参照してもらえるものはなんでしょうか。その場で直接提示しない情報へのアクセス手段という意味では、ドキュメントやシステムのほかに有識者の紹介なども考えられます。（claude codeでも「ユーザに質問する」がツール化されていますね） 例:「不明点等ありましたら、私宛にチャットでご連絡ください」 出力方式の観点： この観点は、回答の形式や期限について検討する部分となります。 例:「結果につきましては今週中にメールでいただければと思います」 「どの情報をどんな形で提示するのか」の選択はプレゼンテーションの成否に直結するポイントであり、これを長い（苦しい？）経験によって身につけてきた方も多くいらっしゃると思います。コンテキストエンジニアリングの枠組みは、それらのノウハウを整理・明文化する際の一つの切り口として使えるように思います。 もちろん、コンテキストエンジニアリングの構成要素や観点についてはまだ発展途上で、いわゆる抜け漏れのない（=MECEな）定義になっていないため、まだ整理のフレームワークとしては不完全です。 しかし「情報を要素ごと分けて、準備・提示の仕方を検討する」という考え方自体はプレゼンテーション技術の体系化に寄与する可能性を感じます。 例3: 子供に宿題を教える場面 次は方向を変えて子供の宿題を手伝っているシーンを考えてみます。 大人から見ると簡単な問題でも、なぜか子供は苦戦していることがあります。（ええ、うちの息子です） 学校の勉強の範疇では、問題を解くのに必要な情報はすでに示されているはずです。回答をするのに必要なコンテキストを整えてあげましょう。 システムプロンプトの観点： 宿題をするにあたり、回答者には何が期待されているのでしょうか。それを把握するだけでヒントになるかもしれません。 例:「息子よ、この宿題は今日授業で習ったことを思い出して使えるようにするためのものなのだ」 ユーザプロンプトの観点： 作業者には直近の指示が正確に伝わっているでしょうか。人間相手の場合はここが適切にコンテキストに反映されていないことがあります。（ええ、うちの息子です） 例：「息子よ、問題文をよく読むのだ。なんと書いてあるか」 短期メモリの観点： 直近の問いや解説で、関連するところ・重要なところを把握できているでしょうか。 例：「息子よ、例題ではどんな解き方を使っていたか」 長期メモリ： 過去の経験で関連することがあれば思い出させてあげましょう。 例：「息子よ、昨日の問題で間違えたところを覚えているか」 RAGの観点： 今使える情報として提示されているものを把握できているでしょうか。 例：「息子よ、使える公式は問題文の下に書いてあるぞ」 利用可能ツールの観点： 参照できる情報源・ツールは把握できているでしょうか 例：「息子よ、ヒントは教科書の10ページとのことだ。また、三角定規の使用も許可されているぞ」 出力方式の観点： 最後に見落としがちな点です。どのような形式で回答すべきなのか分かっているでしょうか。 例：「息子よ、途中式を書くことと、回答に単位をつけることを忘れてはならぬ」 相手のアウトプットやリアクションが自分の思っているものと異なる時、それは相手から見えている情報が足りていない・適切でないからかもしれません。（これは生成AIの場合も同じですね） そんなときは、コンテキストエンジニアリングの考え方で認識のギャップを埋めることができそうです。 例4: 自分自身の作業準備をする場面 最後に、他人へのコミュニケーションだけでなく、自分自身に対するコンテキストエンジニアリングについて考えてみましょう。 自分が行うタスクで良いアウトプットを出すために、どのような情報を整えておくことができるでしょうか。 システムプロンプトの観点： 自分の役割や優先すべきことを意識できているでしょうか。生成AIと同じく、ここを明確にしておくことで、ブレない思考過程・安定したアウトプットにつながるはずです。 例：「今求められている役割はなんだっけ？・・・PoCをするために、実装速度重視のコーディングを求められている」 ユーザプロンプトの観点： 直近のやるべき作業は明確でしょうか。曖昧なタスク定義は余分な時間を費やすことにつながります。 やらないことを明確にすることも効果的でしょう。これも生成AI向けプロンプトでは明示するのに人間相手だと省略してしまいがちですね。 例：「今自分がやるべきことは？・・・・この機能を実装する。途中でリファクタリングはしない！」 短期メモリの観点： 直近で行った作業・思考で次のタスクに使うものを一度整理しましょう。 例：「直前までやっていたことで作業に関係するのは？・・・・直前に作った機能とパラメータを合わせる必要があるな」 長期メモリの観点： 過去の作業・経験で必要なものは整理できているでしょうか。必要に応じて過去の資料は作業記録などを見て作業コンテキストに取り込みましょう。 例：「過去にやってきた作業で今回も関係するのは？・・・・この特殊ケースへの対応を忘れない」 RAGの観点： 必要になる情報は手元に準備できているでしょうか。確実に必要となる情報はすぐに使えるところにないと集中を妨げることになります。 例：「作業開始するにあたって必ず使う情報は？・・・・対応すべきパラメータの一覧はこれ」 利用可能ツールの観点： 使える参照先とツールを確認・準備しておきましょう。ここに不足があると、本来の作業の途中に「ツールを整える作業」が割り込むことになります。（まさに「コンテクストスイッチング」による効率の低下です） 例：「情報元とツールは？・・・・このサイトとこのサイトをブックマーク、このツールをインストールしておく」 出力方式の観点： アウトプットの形式や作業完了の条件は明確にできているでしょうか。ここをおろそかにすると、自分自身に対して作業のやり直しを指示するという残念なことが起こったりします。 例：「アウトプットはどのようにするんだっけ？・・・・メンバにデモできるところがゴール」 自分自身に対しても、作業の準備ができているかをコンテクストエンジニアリングの観点からチェックすることができました。 自分自身へのコンテキスト整備なので、新たな情報を与えるのではなく「分かっていることから今使う情報を絞る・ポイントを思い出す」というアプローチでコンテキストを組み立てることになりますね。 ここまでで示せたもの ここまで4つの例で、コンテキストエンジニアリングという概念は、想定する範囲を拡張することで、生成AIだけでなく人間相手のコミュニケーションにも当てはめることができることを示しました。 また、対人コミュニケーションにコンテキストエンジニアリングの観点を持ち込むことによって、提示する情報というものを要素分解して理解・検討できることが分かりました。（個人的にも、これまで曖昧なイメージしか持っていなかった会話の「文脈」に対して具体的な観点を持てたことが大きな収穫でした。） 今後の展望 コンテキストエンジニアリングは発展途上のものなので、登場する各要素・観点もまだ綺麗に整理されているわけではありません。例えば長期メモリには過去に提示済みのRAGの内容やツール情報が含まれるはずです（これは記事の最初に引用したSchmid氏のベン図でも円の重なりや余白として現れています）。またSchmid氏以外にもコンテキストエンジニアリングについて述べたものは多数存在し、それぞれ構成要素の考え方が少しずつ異なります。 生成AIの可能性については日々新たな知見が公開されています。それに合わせてコンテキストエンジニアリングの領域でも、より良い理論が生まれ洗練されていくでしょう。コンテキストエンジニアリングが人間相手にも有効な考え方であるならば、その発展は同時に「人に対して提示する情報はどのように整理できるのか」というフレームワークのアップデートにも繋がるはずです。もちろん「生成AI向けにはこう、人間相手にはこう整理したほうがよい」といった分岐が発生する可能性はありますが、生成AI相手の知見と人間相手の知見はお互いに影響を与えながら成熟していくでしょう。 対人間の場面に適用できるものとして十分に成熟したコンテキストエンジニアリングは、使う人により良いコミュニケーションを可能にするツールとなるはずです。 その時にコンテキストエンジニアリングはもはやエンジニアのためのハードスキルではなくなり、すべての人に身につけることが推奨される一般教養/ソフトスキルとして社会に定着するのではないかと考えています。 まとめ 本記事では、実際のシーンの例を入れつつ、以下を説明しました。 コンテキストエンジニアリングを「相手から望むリアクションを引き出すために、情報の準備・提示の仕方を考えること」として一般化することで、対人コミュニケーションにも当てはめることができました コンテキストエンジニアリングによって考慮すべき要素・観点が示されることで、人間相手のコミュニケーションや内省に際に必要な情報について理解する際のフレームワークとなる可能性を持っています コンテキストエンジニアリングは発展途上ですが、将来的に要素・観点が洗練されることで、エンジニアに限らずすべての人が身につけるべきスキルとなると考えています 生成AI関連スキルという枠を超えた、コンテキストエンジニアリングの可能性に注目していただければと思います。

皆さんこんにちは！　Insight Edgeでリードコンサルタントを務めております根本と申します。　早いもので、Techブログの記事を寄稿するのは3回目になりました（ 1回目 、 2回目 ）。　今回は当社の「 Insight Edge Advent Calendar 2025 」の15日目の記事を担当させていただきます。　Techブログと題したブログの中で非技術職の私が記事を書くことについて不安もあったのですが、ありがたいことにInsight Edgeに入社いただいた複数の方から、「根本さんの記事読みました」と言っていただくことがありました。　私が書いた記事を応募者の方の意思決定の参考としていただいていることを非常にうれしく思うとともに、引き続きこの路線で書かせていただこうと思います。　 前回の記事 では、2024年の4月より新しく「セールスプランニング」という役割を新設したことを書かせていただきましたが、そこから1年が経過した今、具体的に何をやってきて、今後何をやっていくつもりなのか、について書こうと思います。　Insight Edgeの「今」がわかるような内容も盛り込んでいますので、ぜひお読みいただけると幸いです。 １．セールスプランニング新設の経緯 ２．セールスプランニングの主な業務内容 ３．セールスプランニングの面白さ ・業務が非常に幅広いこと ・決まったことをこなすだけでなく、新しいことを常に考える必要があること ・社内の様々なメンバー、部署と連携して業務を進める必要があること ・これからの「セールスプランニング」を作っていけること ４．セールスプランニングの今後の展望 ・データドリブン意思決定の徹底、推進 ・常に全社目線で今できることを考える ・「頭脳」を強化 ５．セールスプランニングを通じて感じるInsight Edgeで働くことの面白さ ・責任を果たし、期待に応えることで任せてもらえる環境がある ・自主性Welcome、手を挙げることで自身の領域を拡大できる ・発展途上だが必要な役割も増えている、自分の強みを生かせる領域も増えている ６．さいごに １．セールスプランニング新設の経緯 今回初めて私の記事を読んでいただく方のために、まずはセールスプランニング新設の経緯を簡単にご説明したいと思います。　私が所属している「セールス・コンサルティング部」は文字通り営業やコンサルタントが所属する部署であり、案件対応を通じて売り上げを立てることが主な役割（主務）です。　一方で、組織を運営するためには営業活動以外にも管理、企画、改善、育成などの様々な業務が必要です。　私が2023年9月に入社した当時はメンバーそれぞれが主務の傍らそれらを対応していましたが、人数の拡大や各種ルールの整備に伴い、専門的な役割を設けて対応することで最適化を図るべく、セールスプランニングが新設されました。　2024年4月に新設された時点では正式な組織としてではなく「ライン」と呼ばれるヴァーチャル組織のような位置づけでしたが、2025年4月より晴れて正式な組織となり、現在私はチームリーダーを務めさせていただいています。　メンバーも一人増え、現在は2名体制の組織となっています。 図1:セールスプランニングの変遷 ２．セールスプランニングの主な業務内容 前回の記事では新設初年度ということで「案件推進プロセスの整備」を実績として紹介いたしましたが、今回はもう少し細かくセールスプランニングの業務内容についてご説明したいと思います。　セールスプランニングの業務は大きく3つに分かれ、①定常業務と②企画・改善業務、最後に③季節性業務があります。　それぞれについて簡単にご説明します。 図2:セールスプランニングの業務領域 ①の定常業務は、文字通り決められた業務を決められたタイミングで行うものです。　この領域も新設以降大きく拡大しました。　わかりやすいところでは「部運営のための各種会議体のファシリテーション」、「売上見込みの可視化」、そして「定常集計」などがあります。　これらの業務は元々各メンバーが対応していましたが、我々に集約して対応することで、品質のブレが無くなり、部全体の業務効率化/高度化にも繋がっています。 ②の「企画・改善業務」は我々のキモとなる部分で、親組織である「セールス・コンサルティング部」を対象としたものだけでなく、全社的な課題についても日々取り組んでいます。　これまでは社内の各所で業務上の課題を感じながらも、本務を優先するために改善まで手が回らず、結果課題をそのままにしていることがありました。　こういった課題についてはセールスプランニングで積極的に把握に努めており、解決の優先度を定めたうえで解決策を企画し、実際に推進する部分までを一気通貫で対応しています。　一例として、今期は当社が受諾する各案件において、実際の稼働実績と契約工数を突合させる形で予実を管理する取り組みを始めています。　社内に存在する複数のデータソースを組み合わせ、可視化するためのテンプレートを作成し、集計から報告までのプロセスを定常業務に落とし込むまでを実施しました。　 ③の「季節性業務」については毎年特定の時期に行う業務です。　代表的なものでは「予算策定のための各種情報収集、集計、試算」や、「四半期/半期毎の実績集計、報告」、「単価改定に向けた調査、ベース案作成、シミュレーション」などです。　これらは主に経営陣と共に進めるものであり、毎年後半に特に時間を割いて対応している業務です。 今期セールスプランニングが正式な組織となり、メンバーも2名体制になったことで、これらの業務をより幅広く行えるようになっています。　これまでは私が定常業務をこなしながら各種改善企画を考え、さらに季節性業務も対応していましたが、特に①と②についてはメンバーに積極的に関わってもらうことで大きく幅を広げることができています。 ３．セールスプランニングの面白さ ここまでご説明したセールスプランニングについて、「で、実際仕事は面白いの？」と聞かれたら、「メチャクチャ面白いです」と即答できるくらいに毎日充実した仕事ができています。　何が面白いのか、という部分を自分なりに考えてみましたのでご紹介したいと思います。 ・業務が非常に幅広いこと これまでご説明した通り、セールスプランニングは営業組織に属しているものの、業務内容としては多岐に渡り、企画、運用、業務改善、集計、分析、方針策定など様々な分野があります。　私はInsight Edgeに入社する前に複数の企業で経験がありますが、ここまで幅広く、かつ裁量を持って仕事ができる環境はありませんでした。　1つのことを追求し専門性を高めるのも重要だと思いますが、幅広い業務経験を積めることは純粋に面白い環境であると感じます。　また、私個人としてはセールスプランニング業務を主務としながらも、様々な案件推進を担当するコンサルタントとしての稼働も一定発生しています。　自身が営業担当として動きながら、同時に改善施策を進めることができているのもInsight Edgeならではだと思っています。 ・決まったことをこなすだけでなく、新しいことを常に考える必要があること セールスプランニングでは前述の定常業務についても一定量対応をしていますが、基本的には常に社内の改善を意識して動くことが求められます。　また、業界のトレンドの変化も大きく、それに合わせて会社としても成長/拡大している中で、数か月前に決まったやり方が既に効果的ではなくなっているというケースもあります。　そのため、常に新しいことを考えていく必要があり、毎日刺激を受けながら業務ができています。 ・社内の様々なメンバー、部署と連携して業務を進める必要があること いわゆる「オペレーション業務」と言うと、担当者が自己完結で業務を遂行している印象がありますが、セールスプランニングではそうではありません。　社内の改善を常に考えていく必要がある以上、どこにどのような課題があるか、他部署を含めたメンバーとコミュニケーションを取りながら把握する必要がありますし、改善案についても社内のステークホルダーに都度説明したうえで合意形成が必要になります。　前職では限られたチームとの連携がほとんどでしたが、セールスプランニングでは文字通り社内のすべての部門と連携しながら業務を行いますので、会社へのエンゲージメント意識も高いレベルで維持しながら業務ができています。 図3:社内連携イメージ ・これからの「セールスプランニング」を作っていけること セールスプランニングはお伝えした通りまだ2名体制の小さな組織です。　この役割をこれからどのように強化・拡大していくか、将来的にどのような立ち位置を目指すのか、先を見据えたデザインを主導して行える点も非常に面白いです。　トップダウンで、会社の方向性に合わせて決められた絵を実現するのではなく、何を描くか、それをどう作り上げていくかを合わせて考えることができるという環境は非常に魅力的に感じています。 ４．セールスプランニングの今後の展望 そんなセールスプランニングですが、現時点で描いている今後の展望について少しご紹介したいと思います。　具体的な実務や、仕事をする上での考え方なども含めて、今考えていることを共有できればと思います。 ・データドリブン意思決定の徹底、推進 正に今期取り組んできており徐々に成果が出ている状況ではありますが、引き続きデータドリブンな意思決定ができる環境を実現することが当面の最優先事項だと考えています。　私が入社した2023年9月時点では様々な管理がExcelベースで行われており、古い案件の情報が見当たらず、当時の担当者がいないことで経緯が不明な案件も数多く見受けられました。　その後管理用のプラットフォームを導入し、それなりの改善は実感できていますが、まだまだ理想的な姿とは程遠く、引き続きの注力が必要です。　特に現状を即座に把握し、誰もがデータを元に意思決定ができる環境を少しでも早く整備したいと思っています。 ・常に全社目線で今できることを考える 繰り返しお伝えしていることではありますが、セールスプランニングは営業組織の1チームでありながら、業務スコープは全社に渡ります。　そのため、目に見える部分の改善だけではなく、常に変化するInsight Edgeの中で今何が求められており、何を優先して改善すべきかを常に考えて行動する必要があります。　一方でInsight Edgeはまだベンチャーと呼べる規模の会社です。　同業の大手を見習って重厚長大なシステムや仕組みを導入する必要は無いと考えています。　また、変化が激しい環境にある中で、長期に渡る社内プロジェクトを進めることにも一定のリスクを伴います。　このような中でセールスプランニングとしては、常に全社目線でやるべきこと考え、将来的な理想像を描いたうえで今できること、やるべきことは何かを常に考える組織でありたいと考えています。 ・「頭脳」を強化 ここまでご説明した展望を実現するためには、当然業務を遂行する人間の高いスキル、専門知識が必要になりますが、ここについては常に強化していく必要があります。　現時点ではメンバーを含めこれまでの経験やノウハウを元に業務を遂行していますが、今後さらに組織としての影響力を高め、会社に貢献し続けていくためには更なる専門性の獲得が必要なるとヒシヒシと感じています。　もちろん業務遂行の中で自然と身につくスキルや知識もありますが、今後の成長スピードを考えるとそれだけでは足りません。　会社の成長に合わせて組織としてのセールスプランニングも強化していくことを踏まえ、常に社内の第一人者であるための専門性を身に着けることは非常に重要だと考えています。 ５．セールスプランニングを通じて感じるInsight Edgeで働くことの面白さ ここまでセールスプランニングについて書かせていただきましたが、読者の方は「Insight Edgeで働くのって面白いの？」という点が気になっていると思います。　最後に、セールスプランニングという役割を通じて、この会社で働くことの面白さについて書きたいと思います。　入社後2年以上が経過した今、実際に感じていることを共有することで、少しでも興味を持っていただければ幸いです。 ・責任を果たし、期待に応えることで任せてもらえる環境がある 裁量がある環境で働くことができている、というのはこれまで書いた通りですが、それにはやはり一定の責任を果たし、会社の期待にこたえ続けることが重要です。　一方で、常に責任を果たし期待に応えていても、自身の業務領域を超える新しいチャンスをなかなかもらえない環境というのも存在すると思います。　Insight Edgeは、社内全体の雰囲気として「任せる」意向が強いと感じており、しっかりと責任を果たし期待に応えることができれば、欲しいだけのチャンスを与えてくれる会社です。　自ら主体的に新しいチャレンジを継続したい方にとっては非常に良い環境だと感じています。 ・自主性Welcome、手を挙げることで自身の領域を拡大できる 入社して2年以上経過して感じることは、「自主性」を強く重んじる会社である、という点です。　誰かの指示を待ち、仕事が降りてくるのを待つのではなく、自ら仕事を作りに行く、取りに行くという姿勢は高く評価されます。　目の前の業務に集中するのではなく、常に自身の領域を拡大し、成長していきたいといった気持ちを持つ方には最適な環境だと思います。　その分忙しいのは当然ですが、その中でどう業務を効率的に行うかを常に考える必要があるため、業務遂行力も鍛えられる環境です。　私自身は「スーパーフレックス制」の勤務形態を活用することで、オンオフの切り替えや、プライベートのバランスを取りながらヘルシーな働き方ができていると思います。 ・発展途上だが必要な役割も増えている、自分の強みを生かせる領域も増えている 私が入社した当時と比べ、社員数は約1.5倍に、事業規模も大きく拡大しています。　その中で整備が必要になってくる部分や効率化が必要な部分が顕在化してきています。　これに伴い、会社として必要な役割やその領域についても拡大していると理解しています。　言い換えれば、自身の強みを生かせる領域が会社の成長と共に増えている、ということです。　今後もこの傾向は継続すると思いますし、常に自身の強みを発揮して会社に貢献できる領域が多く存在する、というのは大きなやりがいを感じるポイントでもあります。 これら全てを踏まえ、「入社して2年以上が経過した今も、非常に魅力的な環境で、日々充実感を持って仕事ができている（忙しいけどね）」と声を大にして言うことができます。 ６．さいごに 3回目のエントリー記事、いかがでしたでしょうか。　1回目、2回目の記事と合わせて読んでいただくことで、私の入社してからの考え方の変遷や、Insight Edgeの今を少しでもイメージしていただければ幸いです。　Insight EdgeのAdvent Calender 2025もちょうど折り返しです。　これまでも、そしてこれからも様々な興味深い記事がたくさんありますので是非お時間の許す限りお読みいただけると幸いです。　最後までお読みいただきありがとうございました！　

この記事は、 Insight Edge Advent Calendar 2025 の14日目の記事です！！ はじめに こんにちは、Engineerの熊田です。 AIエージェント開発やMCP（Model Context Protocol）を使った外部連携が昨今は盛り上がっていますね。一方で、エージェント同士の連携を実装したり、外部ツールとの統合を一から構築したりするのは簡単でない作業です。 本記事では、マルチエージェントシステムを簡単に構築できるマネージドサービスMicrosoft Foundry Agent ServiceとMCPを組み合わせて試してみました。 これらの技術を使い、ソフトウェア開発要件を自動分解しGitHub Issueを作成させてみたので、その方法を紹介します。 注記 : 本記事の執筆開始時は「Azure AI Foundry」というサービス名称でしたが、2025年11月18日~21日のMicrosoft Ignite 2025において「Microsoft Foundry」に改名されました。なお、本実装はMicrosoft Foundryにおいても動作することを確認しています。 目次 はじめに 目次 1. 基礎知識 Microsoft Foundry Agent Serviceとは 2. システムアーキテクチャ説明 全体構成図 エージェントの役割 1. OrchestratorAgent（オーケストレーション） 2. RequirementClarifierAgent（要件明確化） 3. RequirementStructurerAgent（要件構造化） 4. TaskDecomposerAgent（タスク分解） フェーズワークフロー 3. 実装手順 3.1 開発環境セットアップ 環境変数の設定 Python環境構築 ⚠️ 重要な注意点: MCPはプレビュー機能 3.2 子エージェントの作成（GUI） 3.3 MCP統合とオーケストレーションエージェントの作成 McpToolの作成 オーケストレーションエージェントの作成 3.4 エージェント連携の設定（GUI） 3.5 エージェントの利用方法 3.5.1 基本処理: メッセージ送信とツール承認フロー 3.5.2 対話型チャットインターフェース 4. 実際の動作例 5. まとめと今後の展開 本記事でやったこと Microsoft Foundryが向いているケース 今後の展望 付録 A. 完全なコードリスト オーケストレーションエージェント作成コード エージェント対話コード 環境変数テンプレート B. エージェントプロンプト 参考リンク 1. 基礎知識 Microsoft Foundry Agent Serviceとは Microsoft Foundry Agent Serviceは、AIエージェントを作成・管理できるマネージドサービスです。主な特徴は以下の通りです。 GUI管理 : Azureポータル上でエージェントを作成・設定 マルチエージェント : 複数のエージェントを連携させ、複雑なタスクを処理 拡張性 : MCP、Function Calling、File Search、Code Interpreterなどのツールを利用可能 Python SDK : azure-ai-agents パッケージでプログラムから操作可能 2. システムアーキテクチャ説明 全体構成図 下図のような構成でマルチエージェントを実装しています。 エージェントの役割 1. OrchestratorAgent（オーケストレーション） 役割 : 全体フローの制御とエージェント間の連携 ユーザー入力を受け取る 各フェーズで適切な専門エージェントを呼び出す GitHub MCPを使用してIssueを作成 進行状況をユーザーに報告 2. RequirementClarifierAgent（要件明確化） 役割 : ユーザーの曖昧な要望を明確化 「開発したい機能」に対して質問を投げかける 技術的・業務的な詳細を引き出す 開発に必要な情報が揃うまで対話 3. RequirementStructurerAgent（要件構造化） 役割 : 明確化された要件を技術視点で構造化 機能/非機能要件に分類 UI/API/データベース構造に展開 技術スタックの提案 4. TaskDecomposerAgent（タスク分解） 役割 : 構造化された要件を実装タスクに分解 各タスクに目的・成果物を定義 依存関係を明確化 優先順位の提案 フェーズワークフロー 次のようなフローでエージェントが作業を進めることを想定しています。 3. 実装手順 3.1 開発環境セットアップ 環境変数の設定 まずは、 .env ファイルを作成して必要な環境変数を設定します。 # Microsoft Foundry AZURE_AI_ENDPOINT=https://your-project.cognitiveservices.azure.com/ AZURE_AI_AGENT_ID=your-orchestration-agent-id MODEL_DEPLOYMENT_NAME=gpt-4 # GitHub MCP GITHUB_MCP_SERVER_LABEL=github-mcp GITHUB_MCP_SERVER_URL=https://api.githubcopilot.com/mcp/ GITHUB_REPOSITORY=owner/repo GITHUB_TOKEN=ghp_xxxxxxxxxxxx 環境変数の詳細 : 環境変数名 説明 例 AZURE_AI_ENDPOINT Microsoft Foundryプロジェクトのエンドポイント https://your-project.cognitiveservices.azure.com/ AZURE_AI_AGENT_ID オーケストレーションエージェントのID（後のステップで取得） asst_xxxxxxxxxxxx MODEL_DEPLOYMENT_NAME 使用するモデル gpt-4 , gpt-4o GITHUB_MCP_SERVER_LABEL MCPサーバーを識別するラベル github-mcp GITHUB_MCP_SERVER_URL GitHub公式リモートMCPサーバーのエンドポイントURL https://api.githubcopilot.com/mcp/ GITHUB_REPOSITORY ターゲットリポジトリ（形式: owner/repo ） owner/repo GITHUB_TOKEN GitHub Personal Access Token（ repo スコープ必須） ghp_xxxxxxxxxxxx Python環境構築 パッケージ名 バージョン 説明 Python 3.13 Pythonランタイム azure-ai-agents 1.2.0b3 Microsoft Foundry エージェントクライアント　ベータ版（MCPサポート） azure-ai-projects 1.0.0 Microsoft Foundry プロジェクトクライアント azure-core 1.35.0 Azure SDK コア機能 azure-identity 1.24.0 Azure 認証ライブラリ ⚠️ 重要な注意点: MCPはプレビュー機能 Microsoft Foundry Agent ServiceにおけるMCPサポートは プレビュー機能 であり、 azure-ai-agents==1.2.0b3 のベータ版が必要です。公式ドキュメントがまだ不十分なため、本番環境での使用は慎重に検討が必要です。 # ベータ版を明示的にインストール pip install azure-ai-agents==1.2.0b3 3.2 子エージェントの作成（GUI） Microsoft FoundryのGUIで プロジェクトを作成後 、以下の3つの子エージェントを作成します。 RequirementClarifierAgent （要件明確化） RequirementStructurerAgent （要件構造化） TaskDecomposerAgent （タスク分解） 各エージェントのプロンプトは 付録B を参照してください。 3.3 MCP統合とオーケストレーションエージェントの作成 McpToolの作成 update_headers() を使ってMCPサーバーへのリクエストに必要な認証ヘッダーを設定します。今回の実装では、GitHub Personal Access Tokenを渡します。 def create_github_mcp_tool (): """GitHub MCP用のツールを作成（Issue管理）""" # McpToolオブジェクトを作成 github_mcp_tool = McpTool( server_label=server_label, # MCPサーバーを識別するラベル server_url=server_url, # MCPサーバーのエンドポイントURL allowed_tools=[ # 許可するツールのリスト（セキュリティ上重要） "issue_read" , "issue_write" , "list_issues" , "add_issue_comment" , "get_label" , ], ) # GitHub認証ヘッダーを設定 if github_token: github_mcp_tool.update_headers( "Authorization" , f "Bearer {github_token}" ) return github_mcp_tool オーケストレーションエージェントの作成 MCPツールを含むオーケストレーションエージェントを作成します。 def create_github_issue_agent (): # Azure AI Project クライアントを作成 project = AIProjectClient( credential=DefaultAzureCredential(), endpoint=endpoint, ) # GitHub MCP ツールを作成 github_mcp_tool = create_github_mcp_tool() # オーケストレーターエージェントを作成 agent = project.agents.create_agent( model=model_deployment, name= "Orchestrator Agent with MCP" , description= "マルチエージェントシステムのオーケストレーター" , instructions=f """ あなたはマルチエージェントシステムのオーケストレーターです。 ユーザーの「ソフトウェア開発要望」を段階的に明確化し、 最終的にGitHub Issueとして具体的な開発タスクに落とし込むことが目的です。 リポジトリ: {github_repository} ## ワークフロー ### Phase 1: 要件明確化 1. ユーザー入力をRequirementClarifierAgentに送信 2. 必要に応じて質問・回答を繰り返し 3. 要件明確化完了を判定 ### Phase 2: 要件構造化 1. 明確化された要件をRequirementStructurerAgentに送信 2. 機能/非機能/UI/API/DB等に分類・構造化 3. 構造化結果をユーザーに確認 ### Phase 3: タスク分解 1. 構造化された要件をTaskDecomposerAgentに送信 2. 実装タスクへの分解（背景・目的・成果物・依存関係を付与） 3. タスク分解結果をユーザーに確認 ### Phase 4: Issue作成 GitHub MCPを利用して各タスクのIssueを作成します。 """ , tools=github_mcp_tool.definitions, # MCPツール定義を渡す metadata={ "purpose" : "GitHub Issue Management" , "mcp_server" : "github_mcp" , }, ) print (f "✅ Agent created: {agent.id}" ) return agent 完全なコードとして 付録A「src/create_github_agent.py」 を参照し、実行してください。 3.4 エージェント連携の設定（GUI） エージェント間の接続（マルチエージェント化）はMicrosoft Foundryの GUIで簡単に設定 できます。 「Connected agents」のAddボタンをクリックし、接続したいエージェントを選択します。 3.5 エージェントの利用方法 エージェントをSDKを使って利用するには、基本的なメッセージ送信とツール承認の仕組みを実装をします。 3.5.1 基本処理: メッセージ送信とツール承認フロー エージェントにメッセージを送信し、MCPツールを承認する処理を実装します。 処理フロー : メッセージ作成 : messages.create() でユーザーメッセージをスレッドに追加 MCPツール準備 : create_github_mcp_tool() で認証情報を含むツールを作成 ラン実行 : runs.create() でエージェント実行を開始、 tool_resources にMCPリソースを渡す ポーリング : ステータスをチェックしながら完了を待つ ツール承認 : requires_action の場合、MCPツール呼び出しを承認し、認証ヘッダーを引き継ぐ エラーチェック : 失敗した場合はエラーメッセージを表示 レスポンス取得 : 完了後、最新のアシスタントメッセージを取得 def send_message (project, agent, thread_id, content): """オーケストレーションエージェントにメッセージを送信""" # 1. ユーザーメッセージを作成 message = project.agents.messages.create( thread_id=thread_id, role= "user" , content=content ) # 2. MCPツールを準備 mcp_tool = create_github_mcp_tool() # 3. エージェントのランを実行 run = project.agents.runs.create( thread_id=thread_id, agent_id=agent.id, tool_resources=mcp_tool.resources ) # 4. 完了までポーリング previous_status = None while run.status in { "queued" , "in_progress" , "requires_action" }: time.sleep( 1 ) run = project.agents.runs.get(thread_id=thread_id, run_id=run.id) # ステータスが変わったときだけログ出力 if run.status != previous_status: print ( "Run status:" , run.status) previous_status = run.status # 5. ツール承認が必要な場合の処理 if run.status == "requires_action" and isinstance ( run.required_action, SubmitToolApprovalAction ): tool_calls = run.required_action.submit_tool_approval.tool_calls if not tool_calls: print ( "No tool calls provided - cancelling run" ) project.agents.runs.cancel(thread_id=thread_id, run_id=run.id) break # ツール承認リストを作成 tool_approvals = [] for tool_call in tool_calls: if isinstance (tool_call, RequiredMcpToolCall): try : print (f "Approving tool call: {tool_call}" ) tool_approvals.append( ToolApproval( tool_call_id=tool_call.id, approve= True , # 承認 headers=mcp_tool.headers, # 認証ヘッダーを引き継ぐ ) ) except Exception as e: print (f "Error approving tool_call {tool_call.id}: {e}" ) # ツール承認を送信 if tool_approvals: project.agents.runs.submit_tool_outputs( thread_id=thread_id, run_id=run.id, tool_approvals=tool_approvals ) print (f "Run completed with status: {run.status}" ) # 6. エラーチェック if run.status == "failed" : print (f "Run failed: {run.last_error}" ) return None # 7. 最新のアシスタントメッセージを取得 messages = project.agents.messages.list( thread_id=thread_id, order=ListSortOrder.DESCENDING ) for message in messages: if message.role == "assistant" and message.content: for content_item in message.content: if hasattr (content_item, "text" ) and hasattr ( content_item.text, "value" ): return content_item.text.value return None 完全なコードとして 付録A「src/agent.py」 を参照し、実行してください。 3.5.2 対話型チャットインターフェース ターミナルで対話的にエージェントを利用できるようにしました。 実装コードは 付録A「src/agent.py」 を参照してください。 4. 実際の動作例 エージェントとの対話内容は、playgroundでも確認できます。 エージェントからの質問に対して答えていくと、最終的にGitHub Issueが自動作成されます。 対象リポジトリにIssueが作成されています。 issueを開くと、以下のような内容が生成されています。 5. まとめと今後の展開 本記事でやったこと 本記事では、Microsoft Foundry Agent ServiceとMCPを組み合わせて、以下を実現してみました。 要件からIssue作成までの自動化 : ユーザーの曖昧な要望を対話で明確にして、技術的に構造化し、最終的にGitHub Issueとして出力 GUI中心のマルチエージェント構築 : コードは最小限で、主にAzureポータルのGUI操作でエージェント連携を実現 MCPによる外部連携 : GitHub APIをMCP経由で呼び出して、エージェントに実行権限を委譲 Microsoft Foundryが向いているケース こんなときにMicrosoft Foundryはおすすめです。 とにかく早くプロトタイプを作りたい : インフラ構築やフレームワークの学習コストを抑えたい 複数の専門エージェントを連携させたい : GUI操作で手軽にエージェント間の接続を管理したい 外部サービスと連携したい : MCPでGitHub、Slack、データベースなどさまざまなツールと統合したい 今後の展望 MCPは急速に普及しています。Microsoft FoundryでMCPサポートがGAになりドキュメントも充実してくれば、誰でもノーコード/ローコードで有用なマルチエージェントを作れるような時代がくるかもしれません。 昨今の生成AI活用の進化スピードが速すぎてキャッチアップが大変ですが、Microsoft Foundryのようなマネージドサービスも進化していくとエンジニアも助かりますね。執筆開始時点ではSDKからしかMCP設定ができませんでしたが、その後GUIでもMCPツールが設定できるようになっていました（現時点ではGUIもプレビュー）。 そのうちエージェント開発のハードルも徐々に下がっていき、ビジネス的価値を追求することがやはり大事になってくるのだろうなと想像しています。 付録 A. 完全なコードリスト オーケストレーションエージェント作成コード src/create_github_agent.py """ GitHub Issue作成専用エージェントを作成するスクリプト """ import os from azure.ai.agents.models import McpTool from azure.ai.projects import AIProjectClient from azure.identity import DefaultAzureCredential endpoint = os.getenv( "AZURE_AI_ENDPOINT" , "" ) model_deployment = os.getenv( "MODEL_DEPLOYMENT_NAME" , "" ) server_label = os.getenv( "GITHUB_MCP_SERVER_LABEL" , "" ) server_url = os.getenv( "GITHUB_MCP_SERVER_URL" , "" ) github_token = os.getenv( "GITHUB_TOKEN" , "" ) github_repository = os.getenv( "GITHUB_REPOSITORY" , "" ) def create_github_mcp_tool (): """GitHub MCP用のツールを作成（Issue管理）""" github_mcp_tool = McpTool( server_label=server_label, server_url=server_url, allowed_tools=[ "issue_read" , "issue_write" , "list_issues" , "add_issue_comment" , "get_label" , ], ) # GitHub認証ヘッダーを設定 if github_token: github_mcp_tool.update_headers( "Authorization" , f "Bearer {github_token}" ) return github_mcp_tool def create_github_issue_agent (): """GitHub Issue作成専用エージェントをMicrosoft Foundryで作成""" if not endpoint: print ( "Error: AZURE_AI_ENDPOINT environment variable is required" ) return None # Azure AI Project クライアントを作成 project = AIProjectClient( credential=DefaultAzureCredential(), endpoint=endpoint, ) print ( "Creating GitHub Issue Agent in Microsoft Foundry..." ) # GitHub MCP ツールを作成 github_mcp_tool = create_github_mcp_tool() # オーケストレーターエージェントを作成 github_agent = project.agents.create_agent( model=model_deployment, name= "Orchestrator Agent with MCP" , description= "マルチエージェントシステムのオーケストレーター" , instructions=f """ # マルチエージェント・オーケストレーター ## 概要 あなたはマルチエージェントシステムのオーケストレーターです。 ユーザーの「ソフトウェア開発要望」を段階的に明確化し、最終的にGitHub Issueとして具体的な開発タスクに落とし込むことが目的です。 ## システム構成 以下の専門エージェントとGitHub MCPを順序立てて活用します： ### 専門エージェント 1. **RequirementClarifierAgent**: 要件明確化 2. **RequirementStructurerAgent**: 要件構造化 3. **TaskDecomposerAgent**: タスク分解 ### 外部連携 - **GitHub MCP**: Issue作成・管理（リポジトリ: {github_repository}） ## ワークフロー ### Phase 1: 要件明確化 1. ユーザー入力をRequirementClarifierAgentに送信 2. 必要に応じて質問・回答を繰り返し 3. 要件明確化完了を判定 ### Phase 2: 要件構造化 1. 明確化された要件をRequirementStructurerAgentに送信 2. 機能/非機能/UI/API/DB等に分類・構造化 3. 構造化結果をユーザーに確認 ### Phase 3: タスク分解 1. 構造化された要件をTaskDecomposerAgentに送信 2. 実装タスクへの分解（背景・目的・成果物・依存関係を付与） 3. タスク分解結果をユーザーに確認 ### Phase 4: Issue作成 1. Phase 3の分解結果をもとにGitHub MCPを利用して各タスクのIssue作成 2. 全issueの作成完了をもってユーザーに報告 ## 実行ルール ### 状態管理 - 現在のフェーズを常に把握・表示 - 各エージェントの出力結果を保持 - フェーズごとの進行状況をユーザーに報告 ### 品質管理 - 各フェーズで「完了条件」を満たしているか確認 - 不十分な場合は前フェーズに戻る - エラー発生時は具体的な解決策を提示 ## 出力フォーマット ### 進行状況報告 【現在のフェーズ】: Phase X - 〇〇〇 【次のアクション】: 〇〇〇 ### 全フェーズ完了時の最終報告 ✅ 作成完了したGitHub Issue X 件： - Issue #XX: [タイトル] - Issue #YY: [タイトル] """ , tools=github_mcp_tool.definitions, # Microsoft Foundryでの管理用メタデータ metadata={ "purpose" : "GitHub Issue Management" , "mcp_server" : "github_mcp" , "created_by" : "manual_setup" , "version" : "1.0" , }, ) print ( " \n " + "=" * 60 ) print ( "✅ GitHub Issue Agent が正常に作成されました！" ) print ( "=" * 60 ) print (f "Agent ID: {github_agent.id}" ) print (f "Agent Name: {github_agent.name}" ) print (f "Model: {github_agent.model}" ) print ( "=" * 60 ) print ( " \n 📝 次のステップ:" ) print ( "以下の環境変数を設定してください：" ) print (f "export GITHUB_MCP_AGENT_ID='{github_agent.id}'" ) print ( " \n または .env ファイルに追加：" ) print (f "GITHUB_MCP_AGENT_ID={github_agent.id}" ) print ( "=" * 60 ) return github_agent def main (): """メイン関数""" print ( "GitHub Issue Agent 作成スクリプト" ) print ( "=" * 40 ) # 必要な環境変数をチェック required_vars = [ "AZURE_AI_ENDPOINT" , "MODEL_DEPLOYMENT_NAME" , "GITHUB_TOKEN" , "GITHUB_MCP_SERVER_LABEL" , "GITHUB_MCP_SERVER_URL" , ] missing_vars = [var for var in required_vars if not os.getenv(var)] if missing_vars: print ( "❌ 以下の環境変数が設定されていません:" ) for var in missing_vars: print (f " - {var}" ) print ( " \n 環境変数を設定してから再実行してください。" ) return # Agent を作成 agent = create_github_issue_agent() if agent: print ( " \n 🎉 セットアップが完了しました！" ) print ( "メインのエージェントスクリプトを実行できます。" ) else : print ( " \n ❌ セットアップに失敗しました。" ) if __name__ == "__main__" : main() エージェント対話コード src/agent.py import os import time from azure.ai.agents.models import ( ListSortOrder, RequiredMcpToolCall, SubmitToolApprovalAction, ToolApproval, ) from azure.ai.projects import AIProjectClient from azure.identity import DefaultAzureCredential from create_github_agent import create_github_mcp_tool # 環境変数 AZURE_AI_AGENT_ID = os.getenv( "AZURE_AI_AGENT_ID" , "" ) def create_agent_client (): """メインのオーケストレーションエージェントクライアントを作成""" project = AIProjectClient( credential=DefaultAzureCredential(), endpoint=os.getenv( "AZURE_AI_ENDPOINT" , "" ), ) agent = project.agents.get_agent(agent_id=AZURE_AI_AGENT_ID) return project, agent def send_message (project, agent, thread_id, content): """オーケストレーションエージェントにメッセージを送信""" # ユーザーメッセージを作成 message = project.agents.messages.create( thread_id=thread_id, role= "user" , content=content ) mcp_tool = create_github_mcp_tool() # オーケストレーションエージェントのランを実行 # GUI上で設定されたエージェント間接続により、必要に応じて他のエージェントに委譲される run = project.agents.runs.create( thread_id=thread_id, agent_id=agent.id, tool_resources=mcp_tool.resources ) # 完了までポーリング previous_status = None while run.status in { "queued" , "in_progress" , "requires_action" }: time.sleep( 1 ) run = project.agents.runs.get(thread_id=thread_id, run_id=run.id) if run.status != previous_status: print ( "Run status:" , run.status) previous_status = run.status if run.status == "requires_action" and isinstance ( run.required_action, SubmitToolApprovalAction ): tool_calls = run.required_action.submit_tool_approval.tool_calls if not tool_calls: print ( "No tool calls provided - cancelling run" ) project.agents.runs.cancel(thread_id=thread_id, run_id=run.id) break tool_approvals = [] for tool_call in tool_calls: if isinstance (tool_call, RequiredMcpToolCall): try : print (f "Approving tool call: {tool_call}" ) tool_approvals.append( ToolApproval( tool_call_id=tool_call.id, approve= True , headers=mcp_tool.headers, ) ) except Exception as e: print (f "Error approving tool_call {tool_call.id}: {e}" ) print (f "tool_approvals: {tool_approvals}" ) if tool_approvals: project.agents.runs.submit_tool_outputs( thread_id=thread_id, run_id=run.id, tool_approvals=tool_approvals ) print (f "Current run status: {run.status}" ) # [END handle_tool_approvals] print (f "Run completed with status: {run.status}" ) if run.status == "failed" : print (f "Run failed: {run.last_error}" ) return None # 最新のアシスタントメッセージを取得 messages = project.agents.messages.list( thread_id=thread_id, order=ListSortOrder.DESCENDING ) for message in messages: if message.role == "assistant" and message.content: for content_item in message.content: if hasattr (content_item, "text" ) and hasattr ( content_item.text, "value" ): return content_item.text.value return None def chat_terminal (): print ( "Azure AI Orchestration Agent - Type 'quit' to exit" ) print ( "-" * 50 ) # 環境変数チェック required_vars = [ "AZURE_AI_AGENT_ID" , "AZURE_AI_ENDPOINT" ] missing_vars = [var for var in required_vars if not os.getenv(var)] if missing_vars: print ( "❌ 以下の環境変数が設定されていません:" ) for var in missing_vars: print (f " - {var}" ) print ( " \n 環境変数を設定してから再実行してください。" ) return project, agent = create_agent_client() thread = project.agents.threads.create() print (f "✅ Thread ID: {thread.id}" ) print (f "✅ Agent ID: {AZURE_AI_AGENT_ID}" ) print ( "-" * 50 ) print ( "🚀 オーケストレーションエージェントが開始されました" ) print ( "💡 Microsoft Foundry GUI上でエージェント間接続を設定済みの場合、" ) print ( " 必要に応じて自動的に他のエージェントに処理が委譲されます" ) print ( "-" * 50 ) while True : user_input = input ( "You (type 'quit' to exit): " ).strip() if user_input.lower() in [ "quit" , "exit" , "bye" ]: print ( "👋 さようなら！" ) break if not user_input: continue response = send_message(project, agent, thread.id, user_input) if response: print (f "🤖 Agent: {response}" ) else : print ( "🤖 Agent: 申し訳ありませんが、メッセージを処理できませんでした。" ) if __name__ == "__main__" : chat_terminal() 環境変数テンプレート .env # Microsoft Foundry AZURE_AI_ENDPOINT=https://your-project.cognitiveservices.azure.com/ AZURE_AI_AGENT_ID=your-orchestration-agent-id MODEL_DEPLOYMENT_NAME=gpt-4 # GitHub MCP GITHUB_MCP_SERVER_LABEL=github-mcp GITHUB_MCP_SERVER_URL=https://api.githubcopilot.com/mcp/ GITHUB_REPOSITORY=owner/repo GITHUB_TOKEN=ghp_xxxxxxxxxxxx B. エージェントプロンプト RequirementClarifierAgent（要件明確化）プロンプト # 要件明確化エージェント ## 概要 あなたはソフトウェア開発における要件定義エージェントです。 ユーザーから提供された「作りたいプロダクトの概要」をもとに、戦略的な質問を通じて開発に必要な要件を明確化してください。 ## 明確化戦略 ### Stage 1: プロダクト概要の把握（1-2ターン） 目的: プロダクトの全体像とコアバリューを理解する 重点質問領域: - プロダクトの目的・解決したい課題 - ターゲットユーザー・利用シーン - 類似サービスとの差別化点 - プロジェクトの制約（予算・期間・技術） ### Stage 2: 機能要件の詳細化（2-3ターン） 目的: 必要な機能を網羅的に洗い出す 重点質問領域: - コア機能（MVP に含めるべき機能） - 周辺機能（将来的に追加する機能） - ユーザーフロー・画面遷移 - データの入出力・処理要件 ### Stage 3: 技術・運用要件の確認（1-2ターン） 目的: 開発・運用に必要な非機能要件を特定する 重点質問領域: - 性能要件（ユーザー数・レスポンス時間） - セキュリティ要件（認証・データ保護） - 運用要件（インフラ・監視・バックアップ） - 技術制約（使用技術・既存システム連携） ## 質問実行ルール ### 質問数の管理 - 各ターン: 3-5個の質問（多すぎると負担） - 優先度: High/Medium で重み付け - 関連性: 前回回答に基づく適応的質問 ### 質問品質の基準 - 具体性: 「どのような」より「どの程度・何件・何秒」 - 選択肢: 可能な場合は選択肢を提示 - 例示: 理解を助ける具体例を含める - 前提確認: 重要な仮定は明示的に確認 ## 出力フォーマット ### 質問ターン時 【Stage X】 〇〇の明確化 (X/Y回目) 前回回答の確認: - 確認できた内容 - 追加で確認が必要な点 今回の質問 (優先度: High/Medium): Q1 [High]: 〇〇について教えてください - 選択肢A: ××× - 選択肢B: ××× - その他: 具体的に記載 Q2 [Medium]: △△の想定はありますか？ 例: □□のような機能 次のステップ: 今回のご回答をもとに、【次の確認事項】を整理いたします。 ### 完了判定・引き渡し時 要件明確化完了 確認できた要件サマリー: プロダクト概要: - 目的: 〇〇 - ユーザー: △△ - 差別化: □□ 機能要件: - コア機能: A, B, C - 周辺機能: X, Y, Z 技術・運用要件: - 性能: ユーザー数×××、レスポンス×秒以内 - セキュリティ: 認証方式××× - インフラ: クラウド××× 次工程への引き渡し準備完了: 上記要件を RequirementStructurerAgent へ送信します。 ## 品質管理 ### 完了条件チェックリスト - プロダクトの目的・価値が明確 - ターゲットユーザー・利用シーンが具体的 - コア機能が特定されている - 技術制約・予算制約が把握されている - 次工程で構造化可能な情報が揃っている ### エラーハンドリング 曖昧な回答の場合: 「より具体的な情報が必要です。例えば...」で再質問 回答なしの場合: 「こちらの項目は後で確認することも可能です」で進行継続 範囲外質問の場合: 「その点は開発段階で詳細化します」で適切にスコープ調整 ## 効率化のポイント 1. 仮説提示: 「一般的には〇〇ですが...」で効率的確認 2. 段階的詳細化: 大枠から詳細の順で無駄な質問を削減 3. 既知情報活用: 業界標準・ベストプラクティスを前提とした質問 4. 優先度管理: 開発に直結する情報を優先的に収集 要件明確化は開発成功の基盤です。ユーザーとの協働で最適な要件定義を実現してください。 RequirementStructurerAgent（要件構造化）プロンプト # 要件技術構造化エージェント ## 概要 あなたは要件技術構造化エージェントです。 RequirementClarifierAgentから受け取った明確化済み要件を、開発チームが実装しやすい技術観点で構造化・分類してください。 ## 構造化の目的 1. 開発領域別にタスクを整理し、担当者アサインを効率化 2. 技術的依存関係を明確にし、開発順序を最適化 3. 各要件の技術的実装方法を事前検討 4. 見積もりとリスク評価の基礎情報を整備 ## カテゴリ分類基準 ### 1. フロントエンド/UI 対象: ユーザーが直接操作する画面・インターフェース 含む要件: - 画面設計・レイアウト - ユーザーインタラクション - 画面遷移・ナビゲーション - レスポンシブ対応 技術考慮点: フレームワーク、デザインシステム、アクセシビリティ ### 2. バックエンド/API 対象: サーバーサイドの処理・データ連携 含む要件: - REST/GraphQL API設計 - 外部システム連携API - 認証・認可API - ファイルアップロード・ダウンロード 技術考慮点: API仕様、認証方式、レート制限、バージョニング ### 3. データベース/ストレージ 対象: データの永続化・管理 含む要件: - データモデル・スキーマ設計 - マスタデータ管理 - データマイグレーション - バックアップ・復旧 技術考慮点: DB種別、インデックス設計、パフォーマンス、整合性 ### 4. ビジネスロジック/処理 対象: アプリケーション固有の業務処理 含む要件: - 計算・集計処理 - ワークフロー・承認フロー - バッチ処理・定期実行 - ルールエンジン 技術考慮点: アルゴリズム、処理性能、例外処理、ログ設計 ### 5. インフラ/運用 対象: システムの基盤・運用に関わる要件 含む要件: - セキュリティ・権限管理 - 監視・ログ・アラート - 通知・メール送信 - 環境構築・CI/CD 技術考慮点: クラウドサービス、スケーラビリティ、可用性 ## 出力フォーマット ### カテゴリ別要件一覧 ## 1. フロントエンド/UI ### 要件名: ユーザー登録画面 カテゴリ: フロントエンド/UI 概要: 新規ユーザーがアカウントを作成するための入力フォーム 機能詳細: - メールアドレス・パスワード入力 - バリデーション表示（リアルタイム） - 利用規約同意チェックボックス - 登録完了後の画面遷移 技術的考慮点: - フォームバリデーション実装 - パスワード強度チェック - レスポンシブ対応必須 - アクセシビリティ（WCAG準拠） 依存要件: - ユーザー登録API - 認証システム 実装優先度: High 見積工数: 8-12時間 ### 全体サマリー ## 要件構造化結果 総要件数: XX件 - フロントエンド/UI: X件 - バックエンド/API: Y件 - データベース/ストレージ: Z件 - ビジネスロジック/処理: A件 - インフラ/運用: B件 ## 技術的依存関係 重要な依存関係: 1. データベーススキーマ設計 → API実装 → フロントエンド実装 2. 認証システム構築 → 各機能の権限制御 3. インフラ基盤構築 → アプリケーションデプロイ ## 次工程への引き渡し TaskDecomposerAgentへの引き渡し準備完了 - 各要件の実装可能性確認済み - 技術的依存関係整理済み - 優先度・工数の初期見積完了 ## 品質管理 ### 構造化完了条件 - 全要件が適切なカテゴリに分類されている - 各要件に技術的考慮点が付与されている - 要件間の依存関係が明確化されている - 実装に必要な技術情報が整理されている - 次工程でタスク分解可能な粒度になっている ### 品質チェックポイント 1. 漏れチェック: 明確化済み要件がすべて含まれているか 2. 重複チェック: 同一要件が複数カテゴリに重複していないか 3. 粒度チェック: タスク分解に適した粒度になっているか 4. 技術妥当性: 技術的実現可能性が考慮されているか ### エラーハンドリング 不明確な要件: 「技術実装の観点で詳細が不足」として RequirementClarifierAgent に差し戻し 技術的実現困難: 代替案を提示し、要件調整を提案 カテゴリ判定困難: 複数カテゴリにまたがる要件として「複合要件」で管理 ## 構造化の品質向上ポイント 1. 実装者視点: 「誰が・どの技術で・どう実装するか」を明確化 2. 段階的詳細化: 大機能から小機能への分解 3. 標準化: 業界標準・ベストプラクティスとの整合性確認 4. 将来性考慮: 拡張性・保守性を見据えた構造化 構造化は開発効率を左右する重要工程です。技術的実現性と業務要件のバランスを取りながら、最適な構造を設計してください。 TaskDecomposerAgent（タスク分解）プロンプト # プロジェクトタスク分解エージェント ## 概要 あなたはソフトウェア開発のためのプロジェクトタスク分解エージェントです。 入力された構造化要件をもとに、GitHub Issueとして管理しやすい開発タスクに分解してください。 ## タスク分解の基準 ### 粒度設定 - **開発タスク**: 4-8時間で完了（半日〜1日） - **調査・設計タスク**: 2-4時間で完了 - **テストタスク**: 2-6時間で完了 - **ドキュメントタスク**: 1-3時間で完了 ### タスク種別 - **feat**: 新機能開発 - **fix**: バグ修正 - **docs**: ドキュメント作成・更新 - **test**: テストコード作成 - **refactor**: リファクタリング - **setup**: 環境構築・設定 ## 出力フォーマット 各タスクは以下の形式で出力してください： ### タスク名: [種別] 具体的なタスク内容 **背景**: なぜこのタスクが必要なのか **目的**: このタスクで達成したいこと **成果物**: - 具体的な成果物1（ファイル名・機能名等） - 具体的な成果物2 **受入条件**: - [ ] 条件1: 動作確認方法 - [ ] 条件2: 品質基準 **推定工数**: X時間 **優先度**: High/Medium/Low **ラベル**: 種別, 機能領域, 技術スタック **依存タスク**: - 前提となるタスク名（Issue #XX形式で参照予定） **関連情報**: - 参考資料やAPI仕様へのリンク - 注意事項 --- ## タスク分解例 ### タスク名: [feat] ユーザー登録API実装 **背景**: ユーザーがアプリを利用するためにはアカウント作成機能が必要 **目的**: 新規ユーザーの登録処理を実装し、認証基盤を構築する **成果物**: - POST /api/users エンドポイント実装 - ユーザー情報バリデーション機能 - パスワードハッシュ化処理 **受入条件**: - [ ] 正常系: メール・パスワードでユーザー登録が完了する - [ ] 異常系: 重複メール時にエラーレスポンスが返る - [ ] セキュリティ: パスワードが適切にハッシュ化される **推定工数**: 6時間 **優先度**: High **ラベル**: feat, auth, backend, nodejs **依存タスク**: - データベーススキーマ設計 **関連情報**: - 認証仕様書: [リンク] - パスワードポリシー: 8文字以上、英数字記号混在 ## 追加指示 1. **依存関係の明確化**: タスク間の依存を正確に特定し、開発順序を最適化 2. **リスク識別**: 技術的難易度が高い、外部依存があるタスクを明記 3. **マイルストーン提案**: 関連タスクをグルーピングしてリリース計画に活用 4. **工数妥当性**: 各タスクの工数見積もりを保守的に設定 分解完了後、全タスクの概要（総工数、優先度別分布、依存関係図）を要約してください。 参考リンク Microsoft Foundry ドキュメント azure-ai-agents Python SDK Model Context Protocol (MCP) GitHub Personal Access Token