はじめに みなさん、こんにちは😊 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

この記事は Insight Edge Advent Calendar 2025 の13日目の記事です！ 自社初のアドベントカレンダーもいよいよ中間地点ということで、後半戦もどんな記事が出てくるのか楽しみにしています！ はじめに こんにちは！エンジニアリングマネージャーの筒井です。 Insight Edgeにはアジャイル開発チームの中に2つのサブチームがあり、その1つでチームリーダーをしています。 サブチームではコミュニケーションや知見共有などを目的として、週次の定例会を設けていますが、特にエンジニアはリモートワークの利用率が高いこともあり、月に1回を目安にこの定例会を対面で実施することにしました。 チーム発足から1年が経ち、ある程度運営も安定してきた今年度。せっかく月に1回集まるなら意義のある時間にしたいなぁという思惑もあり、対面開催時の企画・運営を2人1組でチームメンバーに実施してもらうことを提案しました。 負荷にならないよう「普段の定例会を対面でやるだけでもOK！」とハードルを下げたつもりなのですが、蓋を開けてみれば毎回、Insight EdgeのValueである 「みんなでやる」「やってみる」 を体現する企画を皆が考えてくれました。 今回は、そんなエンジニアたちの遊び心と主体性が詰まったチームイベントの数々を、アドベントカレンダーの枠を借りて紹介したいと思います。 Vibe Coding会 記念すべき最初の対面イベント企画はVibe Coding会でした。 時代の潮流に合わせたぴったりの企画で、今思うとこの企画がこの後の流れを決めたかもしれません。 2人目に踊る人が大事なんですよね。本当にありがたい。 ルールは以下のようなもので、とにかくAIに指示を出すだけでものづくりをしてねというものです。 禁止事項：プログラミング言語を使った手動コーディング（コマンド実行やインフラ構築はOK） 利用モデル・ツール：自由 作業時間：1時間 チーム人数：2-3人。分業or集中開発は自由 自分のチームで作ったSlack風恋愛シミュレーションゲームのタイトルがAIにより「恋愛商事」になったのがツボで終始ニヤニヤしていたのですが、他のチームでも ラーメン店検索アプリ リモートワーク集中サポーター 3Dモデルと会話するアプリ 人狼ゲームプラットフォーム など、たった1時間でバラエティ豊かなプロトタイプが作られており。とても面白かったです。 「AIにどう指示すれば意図通り動くか」というプロンプトエンジニアリングの実践知も共有でき、開催後には他チームからも「うちでもやりたい！」と声がかかるほどでした。 当日の写真とSlackへの開催報告 NASAゲーム 続いて開催されたのが、コンセンサスゲームとして知られているNASAゲームです。 私はこういうものがあること自体全然知らなかったのですが、よく見つけてきてくれるなぁと感心します。 Vibe Coding会が技術の話だったのに対して、この回はソフトスキルを学ぶイベントとなりました。 NASAゲームの設定は「月面に不時着した際、手元のアイテム（酸素ボンベ、水、星座表など）にどう優先順位をつけるか」です。 重要なのはその結果や模範解答との近さではなく「チームで合意形成をするためのプロセス」だということでした。 2チームに分かれ、宇宙という誰も知見を持たないテーマの中、お互いの意見を擦り合わせてチームとしての意見をまとめていくプロセスを体験しました。 私のチームでも「助けを待つのか」「基地へ向かうのか」というそもそもの戦略から意見が割れていましたが、振り返りのパートで「前提（目的や価値観）を揃えることが合意形成に重要である」ということを学び、悪くない着眼点で会話ができていたなと感じました。 この回の少し前に新規参画したメンバーもおり、コミュニケーション促進の観点からもちょうど良いタイミングで開催をしてくれたなぁと思います。 アーキテクチャ大喜利 アーキテクチャ大喜利は、別のチームが以前実施していたものを輸入する形で企画されました。与えられた要件に対して時間内にポイントを押さえたシステム設計をしよう、というイベントです。 （アドベントカレンダー11日目の記事 エンジニアの交流促進に最適！アーキテクチャ大喜利のすすめ - チームビルディング事例 で詳細が紹介されていますので、ぜひこちらもご覧ください！） 短い時間で設計を検討し切るのは難しい部分もあったと思いますが、皆集中して取り組み、非同期処理やキャッシュ活用など、各チームから「なるほど」と思わせる設計上のポイントが共有され、お互いに知見の共有や良い刺激になったなと思います。 4つのチームのシステム基盤がAWS、Google Cloud、Azureに分かれていたことにInsight Edgeらしさを感じました。 なお、私自身は頭の中に「こういうシステム構成にすれば良さそうだな」というのは浮かぶものの、それを言語化・可視化するのに手間取ってしまい、最近マネジメント業務が多く設計等を考える機会が少なかったな...と改めて気付かされました。 自力コーディング会 昨今のAIコーディングブームへのアンチテーゼとして開催されたのが、自力コーディング会です。 配布された開催要項の冒頭には 「たまには自分でコードを書いてみよう」 との煽り文句があり、社内のAIコーディング浸透率の高さが伺えます。 内容はAtCoderから選出された数問を、制限時間内に自力で解くというもの。 問題文を読み込むというのが何だか学生の頃に戻ったような気分で、久しぶりにAI補完すらないエディタに向かうと、脳の普段使っていない部分が熱くなるのを感じました。 最後の共有タイムでは、単に問題が解けたということだけでなく、「こんな工夫をして計算量が減らせる」「こんな標準ライブラリがある」など、さまざまな知見も得ることができました。 どちらかというとおじさん達が「こんなワンライナーで書けるぜ」的なところで喜んでいたかもしれません（私です）。 AI画像生成大会 直近で開催されたのが、画像生成AIを活用した「可愛い猫ちゃん画像コンテスト」です。 目的は、AIを用いた画像生成の体験と、プロンプトによる細かい出力のコントロールの難しさを体感すること。 企画メンバーが審査員となり、その独断と偏見によって採点が行われるのですが、 かわいさ お題の正確性 ユニーク性 と採点項目が分かれていることに加え、審査員ごとの好みも 三毛猫ブーム。毛がフサフサで丸いフォルムが好き リアル猫派。顔の可愛さと面白さ、生成の凄さ などが共有されており、その中でどうポイントを取りに行くのかというゲーム性が作り込まれていました。 お題画像が4枚あったので、ルールに従って高得点を狙いつつも、隙あらば「ひと笑い」入れようとする攻めの姿勢を皆から感じました。 プロジェクトの数としては少ないものの、画像生成AIを活用する案件がちょうど始まるタイミングでもあり、実務的な観点からも良い知見が得られたイベントでした。 Slackへの開催報告 おわりに 以上、今年度メンバーが企画、開催してくれた対面イベントについて紹介しました。 今年度はアジャイル開発チームとして「自分の殻を破ろう」ということをテーマとして掲げていますが、これらのイベント企画のように直接自分の参画プロジェクトに関係が無い活動についても、組織やチーム全体のことを考えて取り組むことができるというのは本当に素晴らしいと感じます。 回数を重ねていくとアイディア出しが難しくなってくるはずなので、引き続きハードルは低く保ちたいと思いつつ、今後もメンバーの主体的、積極的な取り組みに期待と感謝をしながら、みんなでInsight Edgeを盛り上げていきたいと思います！

この記事は、 Insight Edge Advent Calendar 2025 の12日目の記事です！ はじめに こんにちは、Insight Edgeでエンジニアをしている東です。 この記事では、自社プロダクト Voiceek の開発を題材に、「エンジニアとデザイナーがどうやってうまく協力しているか」を紹介します。 Voiceek（ボイシーク）とは、顧客の声・従業員の声の分析を効率化・高度化できるテキスト分析ツールです。 以前には、 UI/UXデザイナー視点の記事 もあるので、そちらもぜひご覧ください。 普段からフロントエンドやプロダクト開発をしていると、 デザインの意図が読み切れない 動きや細かい挙動のすり合わせに時間がかかる といった経験をしたことがある方も多いのではないでしょうか。 Voiceekの開発でも、同じような課題にぶつかりました。 また、今回はデザイナーが専任ではなく複数プロジェクトを兼務していたため、プロダクトに対する共通認識が取りづらいという課題もありました。 そこで今回は、 少人数かつ兼務前提のスクラムチームで、どうやってデザイナーと連携しているか どんなルール設計にしたらスピードと品質を両立できたか デザイン実装を支えるAIツールの活用法 について書いていきます。 目次 はじめに 目次 Voiceek開発のチーム体制 デザイナー連携でぶつかったリアルな課題 1. 機能の認識合わせの難しさ 2. 「動き」「ユーザー操作」など見落としがちな仕様のズレ 3. デザインレビュー待ちによる開発フローの停滞 課題解決のための3つのアプローチ 1. デザイナーをデイリースクラムに招待して認識ズレを減らす 2.フローの整理でレビュー待ちを防ぐ 3. 生成AIツールでデザインから実装への橋渡しを効率化 実践して分かった、デザイナー連携の3つの重要ポイント 1. 高頻度のコミュニケーションを優先する 2. デザイナーの視点を積極的に取り入れる 3. 責務分離しつつイメージは共有する まとめ 関連記事 Voiceek開発のチーム体制 エンジニア：3名（私を含む） デザイナー：2名 プロダクトオーナー（PO）：1名 といった構成で、全員が他プロジェクトと兼務しながらスクラムを回しています。 Voiceek全体としては、基盤開発に加えて顧客ごとのカスタマイズ開発も行っており、時期やフェーズによってチーム構成は変化しながら、プロダクトを成長させています。 関連記事: 少数精鋭チームのプロダクト開発で大事なことを考えてみた デザイナー連携でぶつかったリアルな課題 今回の開発では、Voiceekの分析結果を「見るだけ」で終わらせず、そこからさらに深掘れるように、対話形式のチャット機能を実装しました。 このチャット機能をデザイナーと連携しながら開発を進める中で、特に次の3つのポイントで課題が見えてきました。 1. 機能の認識合わせの難しさ チャットボット機能では、 ユーザーにどんな体験を提供したいか それをどんな技術で実現するか をそろえておく必要がありました。 そのようなイメージを、デザイナーに短い時間で伝えるのが難しく、「この機能で何を達成したいのか」をそろえるまでに意外と時間がかかりました。 2. 「動き」「ユーザー操作」など見落としがちな仕様のズレ もう1つ大きかったのが、「動き」に関する解釈のズレです。 Figmaは静的なので、アニメーションやトランジションのニュアンスが定義されない デザイン時には想定外のユーザー挙動の仕様が決まっていない チャット画面のようなインタラクティブなUIでは、 ローディングの出し方 メッセージの追加・スクロールの動き など、細かい部分でユーザー体験がかなり変わります。 ここをすべて事前にFigma上で決め切るのは現実的ではなく、一方で何も決めないと後から大きな手戻りになりがちです。 3. デザインレビュー待ちによる開発フローの停滞 もう1つは、デザインレビューが開発フローのボトルネックになる懸念です。 デザイナーがスポット参加で、レビューにすぐ入れないことがある レビュー待ちのままタスクがクローズできず、スプリントの終わりが見えづらくなる といった状況が懸念され、「どこまでを1つのタスクの完了とみなすか」の線引きに苦労しました。 課題解決のための3つのアプローチ 上記のような課題に対して、Voiceekの開発では次の3つのアプローチを組み合わせて対応しました。 1. デザイナーをデイリースクラムに招待して認識ズレを減らす まず取り組んだのが、デザイナーにもできるだけデイリースクラムに参加してもらうことです。 特に効いていると感じるのは、「デイリーでの短い対話」です。 毎日10〜15分の中で「今ここまでできている」「ここがまだふわっとしている」という認識を合わせることで、結果的に手戻りが減りました。 さらに、「動き」の課題に対しては、デイリースクラムの中で仮実装を見せながら決めていくようにしました。 具体的にいうと、 デザイナーに大まかなイメージをFigmaで作ってもらう エンジニア側でイメージに沿って仮実装する デイリースクラムで動いている画面を見てもらい、問題ない点と調整したい部分を一緒に確認する 問題がなければそのまま仕様として確定し、気になるところが出てきた場合はデザイナー側で再検討してもらう この方法だと、 完璧な仕様が出るまで待たずに、とりあえず前に進める 実際の動きを見ながら議論できるので、認識のズレが少ない POも巻き込みやすく、意思決定が早い というメリットがありました。 2.フローの整理でレビュー待ちを防ぐ 次に決めたのが、「デザインレビューをタスクのクローズ条件にしない」というルールです。 基本のフローはとてもシンプルです。 デザイナーがFigmaでデザインを作成 エンジニアが実装 POが確認してOKならタスクをクローズ デザインレビューのタイミングについては、エンジニアからデザイナーに対して実装完了後にレビュー依頼をする形を取っています。デザイナーはその依頼を受けて実装画面を確認し、気になる点があればフィードバックします。 ここでポイントなのが、デザイナーによるデザインレビューの扱いです。 デザインレビューは タスクのクローズ条件には含めない レビューで修正が必要と判断されたら、 新しいタスクとして起票 修正は次のスプリント以降で対応する こうすることで、 「レビューが終わらないとスプリントが終わらない」という状況を避ける とはいえ、デザイン観点の改善はきちんと別タスクで回し続ける というバランスを取ることができます。 デザインレビューをしっかりしつつも、「止める工程」にしないというのが今回の工夫でした。 3. 生成AIツールでデザインから実装への橋渡しを効率化 AIツールの活用も、実装時に大きな助けとなりました。 具体的には、 Figma MCP と Claude Code を組み合わせています。 この組み合わせによって、実装スピードが大きく向上しました。 Claude CodeからFigma MCPを経由してデザインデータを取得することで、 レイアウトの骨組みとなるコードを、Figmaの構造に近い形で自動生成 余白・サイズ・配色なども、Figmaの指定にかなり近い状態で反映 もちろん細かい調整は必要ですが、「骨組みがすでにできている状態」からスタートできるため、レイアウト調整にかけていた時間を減らし、アプリケーションロジックやアニメーションなどの実装に集中しやすくなりました。 実践して分かった、デザイナー連携の3つの重要ポイント 上記のアプローチを実践する中で、デザイナーとの連携について特に重要だと感じたポイントを3つ紹介します。 1. 高頻度のコミュニケーションを優先する デザイナーにデイリースクラムへ参加してもらい、毎日少しでも会話するようにしたことで、 イメージの共有が早くなる 仕様の解釈違いが早期に見つかる 手戻りに気付いたときの被害が小さくなる という効果がありました。 「話す時間を減らしたほうが開発は早く進む」と思いがちですが、実感としてはむしろ逆で、 短くても高頻度で話したほうが、結果的にスピードが出る と感じています。 2. デザイナーの視点を積極的に取り入れる エンジニアはどうしても、「実装しやすさ」や「パフォーマンス」を優先して考えがちです。 一方デザイナーは、「ユーザーがどう感じるか」「この画面の体験は気持ち良いか」を軸に考えてくれます。 エンジニア視点：この実装のほうが早い・シンプル デザイナー視点：その挙動だとユーザーが迷う・不安になる といった場面で、デザイナーの意見が入ることで、ユーザー体験としてのバランスが取れるようになりました。 3. 責務分離しつつイメージは共有する 責務の分離自体はとても大事です。 デザインの最終判断はデザイナー 実装方針の最終判断はエンジニア という線引きは保ちつつも、「お互いの頭の中のイメージ」はできるだけ共有するようにしました。 デザイナーからは、コンポーネントの意図や、ユーザーに持ってほしい感情を言語化してもらう エンジニアからは、実装上の制約や、他画面との整合性を共有する この「任せる」と「共有する」のバランスが取れてくると、チームとしてのスピードやクオリティを上げやすいと感じています。 まとめ ここまで、Voiceekの開発で実践してきた「デザイナーとのうまい連携」を紹介してきました。 毎日5分でもデザイナーと話す時間をつくる デイリースクラムに参加してもらう 参加が難しければ、短いスタンドアップやSlackハドルなどでもOK 「デザインレビュー待ちで止めない」ルールを決める デザインレビューはタスク完了条件に含めず、修正は別チケットで扱う 「いつまでに何が決まっていれば実装を進めてよいか」をチームで言語化する Figmaなどのデザインや実装画面を一緒に触る場をつくる Figmaと実装画面の両方を見せながら、「ここはどう感じるか？」「他の案はあるか？」をその場で話す あわせて、Voiceekのチームとしては、今後次のような点もさらに試していきたいと考えています。 デザインタスクが薄い時期のデザイナー参加をどうするか 常にデイリーに参加してもらうべきか、集中時間を優先すべきか スクラムイベントへの関わり方の最適なバランス サービスデザイン観点での関わり方 画面単位ではなく、サービス全体の体験設計にどう入ってもらうか 小さな工夫の積み重ねではありますが、こうした取り組みを続けていくことで、より良いプロダクトを育てていけると感じています。 この記事が、みなさんのチームでのデザイナー連携を見直すきっかけになればうれしいです。 関連記事 上記のVoiceekチーム・プロダクトを育てていく過程で、合宿を実施しました。よかったら合わせてお読みください。 企業における合宿の価値考察

この記事は、 Insight Edge Advent Calendar 2025 の11日目の記事です！！ はじめに こんにちは。アジャイル開発チームでエンジニアリングマネージャーをしている三澤です。本記事では今年実施したチームビルディング施策をご紹介します。 弊社Insight Edgeは、住友商事グループ各社のDXを推進するためにプロジェクト単位でチームを組成するスタイルをとっています。 そのため、「これまで一緒のプロジェクトに入ったことがないメンバーと次のプロジェクトでチームを組む」という状況が発生します。 だからこそ、プロジェクトをまたいでコミュニケーションを取り、互いの思考や技術観を知ることが重要となります。そこで今回実施したのが「アーキテクチャ大喜利」 です。 ここからは、実施背景から実施までに準備したこと、当日の様子、そして実際にやってみて分かった知見をご紹介します。 目次 なぜアーキテクチャ大喜利をやることにしたのか 当日までに準備したこと 当日の進め方 やってみて得られた効果と改善点 今後の展開と応用の可能性 なぜアーキテクチャ大喜利をやることにしたのか 企画のきっかけとなったのは、昨年読んだFindy Toolsの記事「 アーキテクチャ大喜利『もし、⚪︎⚪︎な仕様のサービスを立ち上げるなら、あなたはどんなアーキテクチャを組みますか？』 」でした。 著名なエンジニアが同じ仕様をテーマにそれぞれの視点から設計案を語る形式となっており、読み物としても非常に面白いものでしたが、これを読んだ時にふと思いました 「この形式、社内コミュニケーションにも使えるのでは？」 と。 同じ技術課題に対して人によってどう発想が分かれるのかを見ることは、それだけで相互理解と技術向上につながります。 そこで、この記事のコンセプトはそのままに、以下の2つを目的としたチーム活動として実施することに決めました。 実施の目的 普段関わらないメンバー同士のコミュニケーション促進 技術力の底上げ（特にアーキテクチャ思考） 当日までに準備したこと チーム活動としてのアーキテクチャ大喜利の成否は「お題」で9割決まると言っても過言ではありません。ゆえに、参加者が楽しみながらも、技術的な思考を深められるような絶妙なバランスのお題を作る必要がありました。 そのために今回はChatGPTと対話を重ねながらお題をブラッシュアップしていく方法を取りました。 具体的には 1. 議論の方向性を揃えるための「制約」 2. 個性を引き出す「設計の余白」 3. 2時間で完結させるための「スコープ管理」 の3つのポイントを意識しながら作成しました。 1. 議論の方向性を揃えるための「制約」 お題に制約がないと注目すべき論点がバラバラになり比較がしづらくなります。よって共通の論点を確実に着目させるための仕組みが必要になります。そこで今回は以下のような制約を設定しました。 テーマ: LLM（AIエージェント）での大規模ドキュメント要約 時間的制約: 1件約1分の個別要約を最大20件、さらに3分の統合処理を経て、全体を15分以内に返す。 負荷要件: 10〜30件の並行リクエストに耐えられること。 技術的課題: 共通APIから取得できるのはメタ情報のみ。PDFやテキストなどのドキュメント本体は自前で解析・抽出する必要がある。 LLMの応答遅延や失敗を考慮したリトライ処理が必須。 このような制約を設けることにより、単純な逐次処理のアーキテクチャでは不可能になります。これにより、参加者は「並列・非同期処理」「スケーラビリティ」といった論点を議論することが可能になります。 2. 個性を引き出す「設計の余白」 一方で制約をガチガチに設定すると正解が一つに近づいてしまい大喜利としての面白さが薄れます。 そこで今回は同じ要件でも複数の解き方が存在する状態を作りました。 データ前処理の流儀 ドキュメント形式がバラバラなため、「どこまで丁寧に前処理するか」でチームの個性が出る はず です。「最初にすべてを共通フォーマットに変換する堅実派」や「プロンプトエンジニアリングで吸収する柔軟派」など、アプローチが分かれることを狙いました。 UX要件の解釈を委ねる 「ユーザが進捗を見られること」とだけ定め、具体的な方法は問いませんでした。これにより、「WebSocketでリアルタイム性を追求するチーム」や「ポーリングでシンプルさを選ぶチーム」など、何を大切にするかで技術選定が変わってくる はず です。 （余談ですが、最終的には似た構成に寄ったのですが、それはそれで「Insight Edgeの設計文化の一貫性」が見えて面白かったポイントです。） 3. 2時間で完結させるための「スコープ管理」 最後に、2時間という限られた時間で議論が脇道に逸れないよう考えなくていいことを明確にしました。 あえて周辺要件をシンプルに データソースを「共通リポジトリ1箇所」に限定し、複雑な認証などをスコープ外に。これにより、参加者は「AIエージェントの非同期並列処理」という本丸に集中できます。 議論の道標を提示 お題の最後に「考慮すべき観点」としてヒントを提示し、議論が迷子にならないよう工夫しました。 以下が実際にイベントで使用したお題です。 作成したお題 # アーキテクチャ大喜利：大規模リサーチ用「ドキュメント要約・統合エージェント」 以下の前提・要件を満たすシステムを **どんな技術スタックで** 構成するかを議論・発表してください。 2時間の検討時間内で、クラウドサービスやミドルウェアを含めた設計アイデアをまとめましょう。 --- ## 前提（シナリオ） - **企業規模 / 利用者：** - 研究者・アナリスト・社員など数百～数千名がいる大企業を想定。 - 彼らが、日常的にドキュメント（PDF, テキスト, スライド等）を参考にして新しいリサーチやレポートをまとめるニーズがある。 - **目的：** - ユーザがまとめて指定した複数のドキュメントを、**AIエージェント（LLM）** で自動的に要約したい。 - 個別要約だけでなく、最終的に **全体を統合したサマリ**（重複排除や結論の集約）を作成して返す。 - **ドキュメント保管：** - 各部署が作成したファイルは **1つの共通リポジトリ**（S3や企業内ストレージ）に集約されている前提で**共通APIでアクセスできる**ものとします。 - ただし、**共通APIから取得できるのは“インデックス（メタ情報）”のみ**で、実際のドキュメントは**PDFや生テキストのまま**格納されており、システム側でテキストの解析・抽出が必要になる。 （例：PDFパーサーやテキスト抽出、OCRなど。どう実装するかは自由） - APIではカテゴリとファイルの種類、件数を指定することでメタデータを取得することができる - カテゴリは1,000種類 --- ## 要件 1. **処理時間の制限** - 依頼から **15分以内** に、最大20件のレポート要約と統合要約を完了し、ユーザへ結果を返すこと。 2. **1レポート要約にかかる時間** - 1件あたり **約1分** を想定（テキストであればという前提）。 3. **複数ユーザからの同時リクエスト** - 1度に **10～30件** 程度の並行リクエストが来る可能性がある（高負荷を想定）。 4. **ドキュメントの検索・抽出** - 共通APIから取得できるのはレポートのメタ情報（タイトル、更新日、URL等）のみ。 - 実際のドキュメントコンテンツはPDFやテキストのまま別途ダウンロードし、**自前で必要な箇所を抽出・解析**する必要がある。 5. **進捗表示 / 結果受け取り** - ユーザが「何件終わったか」「残りの所要時間は？」などのステータスを確認できる仕組みを用意する。 - 全要約完了後、最終的な統合サマリを取得できる（Web UI / PDF / JSON など形式は自由）。 6. **AIエージェント（LLM）の利用** - 外部API（例：OpenAI）や自前GPUクラウド（Kubernetes上のモデルなど）、いずれでも可。 - セキュリティ・コスト・性能を考慮し、採用理由を示すこと。 7. **再実行** - 異なるユーザが同じレポートを指定する可能性がある。 8. **統合要約の工程** - 個別要約がすべて揃った後、重複・矛盾を排除し **最終レポート** を生成。 - この統合要約工程に **約3分** かかる想定。 --- ## 考慮すべき観点 - **並列実行と非同期フロー** - 1件1分×20件 + 3分 = 23分をどう15分以内に短縮するか？ - オートスケーリング／キュー＆ワーカー/並列化など。 - **モニタリング・運用** - 高負荷時にどのようにスケールさせる？ - LLM呼び出しが遅延した／失敗したときのリトライ＆エラーハンドリングは？ - LLMOpsはどうする？ - **コスト / セキュリティのトレードオフ** - 外部LLMだと開発が簡単だが機密データや費用は？ - 自前LLMの場合はGPUリソース管理が必要。 - **ユーザビリティ / 部分的可視化** - レポートの一部が要約完了した時点で結果を先行表示するか、すべて終わってから返すか。 - 進捗状況をどう把握してユーザに通知するか（WebSocket, Push, Polling等）。 --- ## 大喜利のお題 - **目的**: 「どんな技術スタックやクラウドサービスで、上記要件を満たすシステムを作るか」 - **ゴール**: - 2時間の検討時間内に、「自分たちならこう作る！」というアーキテクチャ案をまとめ、**構成図・主要コンポーネント・フロー**など発表頂きます。 - 発表では **なぜその技術スタック・構成を選んだのか**、**どのように時間・高負荷・ドキュメント解析の課題を解決するか**、**コストやセキュリティとのトレードオフ** など、考えたことを自由に語ってください。 - **ポイント**: - 「どんなクラウドサービス・技術を使ってこの要件を満たすか？」 - 「どのように15分以内で最大20件の要約と統合要約を処理するか？」 - 「複数ユーザの同時依頼をどうさばくか？」 - 「進捗表示やエラー処理をどのように実装するか？」 当日の進め方 当日は、最大3人の小規模チームを複数つくり、チームに分かれて2時間の検討＋1時間の発表という合計3時間のスケジュールで実施しました。 ポイントは、ジュニアとシニアをバランスよく混ぜたチーム編成にしたことです。 また、今回はあえて事前にお題は共有せず、時間制限のある中で考えてもらう形式としました。 そのようにすることで、 シニアの思考プロセスを間近で学べる ジュニアの柔軟な発想が議論に新しい視点をもたらす 普段同じPJにいないメンバー同士で自然に役割分担が生まれる という効果が期待できます。ただし、事前にお題を共有しない点については、終了後アンケートで事前共有しても良かったのではないか、とのコメントもあったため、目的と手段のバランスはしっかりと考える必要があります。 また、このアーキテクチャ大喜利は「技術発表会」ではないので、 正解よりもなぜその構成を選んだのかという思考を明らかにすること 人によるアプローチの違いがあること を理解して進めることが重要です。事前にそのような目的をメンバーに伝えることで、より適切な議論が生まれてくると考えます。 やってみて得られた効果と改善点 実施後のアンケート結果を見ると、参加者の満足度は非常に高いものとなりました。 今回の取り組みは楽しかったですか？：平均 4.7点 / 5点 またこのようなイベントはやりたいですか？：平均 4.7点 / 5点 勉強になりましたか？：平均 4.5点 / 5点 時間は十分でしたか？：平均 3.2点 / 5点 難易度はどうでしたか？：平均 2.8点 / 5点 （本設問のみ3がちょうど良いレベルと設定） この結果を見ると、「楽しさ」と「学び」が高水準で両立できており、イベントとしては成功だと考えられます。一方で、「時間は十分でしたか？」という質問に対する点数は低く、運営上の課題も見えました。 以下、具体的にもらったコメントを交えて良かった点と改善点を振り返ります。 良かった点 普段関わらないメンバーの 技術のクセ が分かった 「この人はユースケースから考えるんだ」「この人はデータ構造を先に固めるタイプだ」など、発想の違いがよく見えました。実際に以下のようなコメントがありました。 メンバごとの得意領域が異なるおかげでそれぞれをカバーしながら議論をしつつ、メンバの考えも理解することができて有意義だった 普段一緒に仕事していないメンバーとアーキテクチャ設計の議論できて、それぞれが持っている知識、業務からの知見、日々感じている課題を共有できた。共通言語がまた一つ増え、今後一緒に仕事したら役に立ちそうだと思った これらの結果は、実際のプロジェクトでチームを組むときのコミュニケーションコストを下げることができると考えます。 思考過程の共有で学びが多い アーキテクチャ設計は結果だけ見ても学べる量が限られます。 しかし検討中のコミュニケーションや大喜利形式での発表を通じて、トレードオフの優先順位など、普段は見えにくい部分を明らかにすることができました。実際に以下のようなコメントがありました。 普段使わないもの(AWS ※1)で設計できたので勉強になってよかった 議論を通じて、自分が知らない部分、他のチームメンバーもあまり分かっていない部分を把握できるようになり、今後しっかり調べて、情報発信すべきポイントなども掴むことができました このように、単に設計知識を得ただけでなく、お互いにどこが分かっていて、どこが分からないか、を更新できたことは大きな収穫でした。 ※1 弊社はプロジェクト毎にクラウドを使い分けており、普段Google CloudやAzureをメインで使っているメンバもいます。 改善点 設計にばらつきが出なかった 事前に「個性が出る仕掛け」を用意したつもりでしたが、結果的にはどのチームも似た構成になってしまいました。実際に以下のようなコメントがありました。 各チーム似たりよったりになったので、LLM自前みたいな普段やらないような制約があるともっとおもしろくなるかなと思いました これは先にも書いた通り、ある意味弊社メンバのスキルが安定していると言うことも意味しますが、大喜利としての幅・技術力向上という意図に対してはもう少し広げたかったところです。 時間配分と事前準備 「時間は十分でしたか？」の回答は平均3.2点でしたが、内訳を見ると「2（足りなかった）」と「4（十分だった）」に意見が割れました。 当日は30分延長することになったため、時間内に収める工夫が必要と考えられます。実際に以下のようなコメントがありました。 お題を先に共有して、それぞれ事前にリサーチして持ってくるのも良いではないかと思います。ある程度調べられて事前準備がある状態だと議論もよくなり、より良い設計もできるのではないかと思いました 日々の業務を進める中で事前準備の時間を作るのも難しいかもしれませんが、事前準備をすることで議論に深みや幅を持たせられる可能性があり、今後検討していきたいと考えています。 これらの結果を踏まえると、今回のお題設定における①議論の方向性を整える制約と②個性が出る余白、そして③時間内で深めるスコープ管理はまだ改善の余地があったと言えます。 そのため、次回に向けては、 明確に複数の方向性があり得るお題 要件に明らかな矛盾を仕込む（例：コスト最優先 vs 精度最優先） 技術選定の自由度が高いテーマ（その場合には事前調査時間を作る） などを混ぜたいと考えています。そうすることで今回でなかったバリエーションを増やせそうだと感じました。 ただ総じて交流イベントとしては成功だったと考えています。 今後の展開と応用の可能性 アーキテクチャ大喜利の考え方は他の場面にも応用可能だと考えています。 今後のアイデア例 新人・若手向けの設計トレーニング お題形式だと、ハンズオンより「思考の深さ」が見えやすい。 プロジェクト開始前のキックオフでのアイスブレイクアクティビティ 「この人はこう考えるんだ」が最初に掴めると、初動が圧倒的に速い。 今後もテーマを変えながら継続し、Insight Edgeの文化として根付かせていければと考えています。 この記事が、皆さんのチームや組織のコミュニケーションを活性化させる、何かのヒントになれば幸いです。

この記事は Insight Edge Advent Calendar 2025 の10日目です。 こんにちは、Insight Edgeの齊藤です。 生成AIサービスの進化は著しいものがあります。「会話しながらアプリを作る」「文章で要件を書くだけで構造を提案してくれる」といった体験が、いよいよ現実の選択肢になってきました。 私自身は普段エンジニアとしてコードを書いていますが、「ノーコード／ローコードでどこまで実現できるのか」「どの領域からは従来どおりコードを書いた方がよいのか」を見極めることが、技術の目利きや自身の価値の把握、さらにはキャリアを考えるうえでも重要だと感じています。 そこで今回は、その試金石としてCopilot StudioとDataverseだけで、ノーコードでデータ分析エージェントを作成してみました。 Power Platform と Copilot Studio の概要 データ分析エージェントの作成にあたり、利用したサービスについてご紹介します。 Power Platform Microsoft Power Platformは、ざっくりいうと「業務アプリをノーコード／ローコードで作るためのプラットフォーム」です。 Power Apps：業務アプリを作る Power Automate：ワークフロー／RPAを作る Dataverse：アプリの裏側で動くデータベース Power BI：可視化・ダッシュボード Copilot Studio：生成AIエージェントをローコードで作るツール 参考： 公式ドキュメント（Microsoft Learn） Copilot Studio Copilot Studioは、Power Platform上で動作する「生成AIエージェントをローコードで作るためのツール」です。主に下記の内容を実現可能です。 会話フローの設計 ： GUIでトリガー・質問・条件分岐などをつなげて、業務に沿った会話フロー（トピック）を定義できます。 ナレッジを使った回答（RAG） ： Dataverse、SharePoint、ドキュメント、Webサイトなどをナレッジソースとして登録し、それらを元にした生成AI回答を行えます。 各種サービスとの連携・アクション実行 ： Power Platformのコネクタやプラグインを通じて、Microsoft 365や外部SaaS、自社APIにアクセスし、データの参照・更新まで行えます。 Microsoft 365 / 各チャネルへの展開 ： 作成したエージェントは、Microsoft 365 Copilotの拡張としてTeams / Outlookなどから呼び出せるほか、WebサイトやPower Appsなどにも公開できます。 Copilot Studioのエージェント設定画面 Power Apps のプランデザイナー Power Appsは、業務アプリをノーコード／ローコードで構築するためのツールです。今回はその中の「プランデザイナー（Plan designer）」だけを使い、Dataverseのテーブルとエージェントを短時間で準備しました。 「解決したいビジネス課題」を文章で入力すると、「要件エージェント」「プロセス エージェント」「データ エージェント」「ソリューション エージェント」が、Power Platform製品群をどう組み合わせるかを含めて具体案に落とし込んでくれます。内容が想定と違う場合も、生成AIに追加で指示することで修正できます。 今回はPower Appsのアプリ本体は作らず、プランデザイナーだけを使ってテーブルとエージェントを短時間で準備しました。 プランデザイナーの初期画面 データ分析エージェント作成 それでは実際に、データ分析エージェントを作成していきます。 今回は次の構成で、ダミー案件情報からグラフを可視化するエージェントを作ります。 データ：Dataverse（案件・担当者・工数記録・予実） 実行：Copilot Studio ＋ コードインタプリタ（Python集計・描画） 出力：グラフとサマリをチャット出力 1. プランデザイナーにプロンプト入力 Power Appsのプランデザイナーを開き、下記だけ入力しました。 これによりプランデザイナーが要件定義からデータ定義、システム構成まで案を作成してくれました。 copilot studioとDataverseを使って、案件に関する予実や工数を確認するデータ分析エージェントを作りたい プランデザイナーへの初期入力 2. Dataverse確認 プランデザイナーが作成したDataverseを確認します。 ユーザ側で修正可能ですが、テストデータ含め問題なさそうなので次に進みました。 Dataverseテーブルの関連図 Dataverse案件データの例 3. システム構成の調整 プランデザイナーからは、データ分析エージェント以外に「工数記録サポート」「工数集計ダッシュボード」なども提案されました。 今回はMVPを意識し、「コードインタプリタを使うのでBIダッシュボードは不要」「エージェントは１つにして」と指示しました。 プランデザイナーへ修正を指示する例 これにより案件・担当者・工数記録・予実テーブルと単一エージェントだけに整理されました。 修正後のシステム構成 4. エージェント設定変更 プランデザイナーにより、Copilot Studioを用いたエージェントについて、プロンプト案やDataverseへの接続はすでに作成されています。 今回は以下だけ設定変更しました。 エージェント設定を最初にオンにする 「設定」＞「はい、利用できるツールやナレッジを適宜使用し、応答を動的にします。」をオン 「コードインタプリタ」をオン プロンプト修正 プロンプトは 「案件、担当者、工数記録、予実データのテーブルを活用し、グラフとサマリを返答するエージェント。」 としました。 結果１ ここまでの手順だけで、 Dataverse＋Copilot Studioのデータ分析エージェント 条件入力 → 集計 → グラフ画像をカード表示 という流れを、ほぼノーコードで形にできました。 完成したエージェントに実際に質問した際の挙動は下記の通りです。 案件と工数の関係を可視化 一方で挙動は安定せず、「案件ごとの予定工数vs実績工数」という質問の回答は失敗しました。 Dataverse自体は参照できているものの、エージェントはスキーマの関係性を十分に理解できていないことが推測されます。 失敗例 修正：テーブル定義をプロンプトに渡す Power Appsのテーブル定義画面からスクリーンショット画像を取得し、生成AIでテキスト化した「テーブル項目説明」をそのままプロンプトに追記しました。 追記した定義文（抜粋） 案件、担当者、工数記録、予実データのテーブルを活用し、グラフとサマリを返答するエージェント。 ##### データベーステーブル項目説明 ## 1. 案件テーブル - 案件名: プロジェクトの名称（案件A、案件B等） - 開始日: プロジェクトの開始予定日 - 終了日: プロジェクトの終了予定日 - ステータス: 案件の進捗状況（進行中、完了、計画中、中止） - 担当者数: 案件に割り当てられている担当者の人数 ## 2. 予実データテーブル - 案件名: 対象案件の識別名 - 案件ID: 案件テーブルとの紐付けキー - 予算工数時間: 計画上の作業時間 - 実績工数時間: 実際に費やした作業時間 - 予算金額: 計画上の予算額 - 実績金額: 実際にかかった金額 - 計画との差異: 予算と実績の差額（正値は予算オーバー、負値は予算内） ## 3. 担当者テーブル - 担当者名: 社員の氏名 - 役割: 職務上の役職（経営者、プロジェクトマネージャー、現場担当者等） - メールアドレス: 連絡先メールアドレス ## 4. 工数記録テーブル - 工数記録名: 作業記録の識別名 - 担当者ID: 作業を行った担当者の識別ID - 案件ID: 作業対象の案件識別ID - 作業日: 作業を実施した日付 - 工数時間: 作業に費やした時間数 - 作業内容: 具体的な作業内容（設計作業、開発作業、テスト作業等） 結果2 テーブル定義をプロンプトに定義した後は、予定vs実績の棒グラフや担当者×案件のヒートマップなど、複雑な集計もプロンプトだけで生成できるようになりました。 主な改善点は次のとおりです。 Joinが案件↔予実↔工数記録の粒度・方向で正しく組まれるようになった 予算工数・実績工数など抽出項目の取りこぼしや取り違えが減った Pythonコード（集計・可視化）の生成精度が上がり、そのままコードインタプリタで実行できるケースが増えた 予算工数と実績工数の比較グラフ 担当者×案件の工数ヒートマップ エージェントの挙動変化と現状の限界 2025/11/25時点では「生成オーケストレーションモード」をオンにするとエージェント自身が回答を返せていました。 その後2025/12/3時点の確認では、回答が一瞬生成されたあとすぐ消え、システムがデフォルトのフォールバックである「会話の強化」トピックへ自動切替する挙動になっていました。 その結果、少なくとも私の環境ではうまくグラフを生成できなくなってしまいました。 より安定的に動かすのであれば、「ユーザーから条件を聞く → Dataverseからデータを取得 → Pythonで集計・グラフ生成 → 結果を返す」といった流れを、Copilot Studioのトピック（会話フロー）として明示的に組む必要があります。 参考：Power Platformコミュニティの類似報告 https://community.powerplatform.com/forums/thread/details/?threadid=0c090dac-098e-f011-b4cc-000d3a1b2a56&utm_source=chatgpt.com また、その他にも下記のような制約が明らかになりました。 ローコード特有の制約：細かいカスタマイズが難しい／作成したロジックの再利用・移植に工数がかかる／環境分離やバージョン管理がコードベースより煩雑 Copilot Studio特有の制約：Reflection（自己評価ループ）など複雑なフローを組みづらい／エージェント実行が約2分を超えると失敗するため、複雑なタスク実行に不向き これらの情報は日々のアップデートにより変わる可能性も大きいため、公式のドキュメントを確認いただければと思います。 まとめ 今回の検証では、Copilot Studioを含むPower Platform環境により、10分程度でデータ分析エージェントを構築できました。初回の試行錯誤を含めても1時間ほどでグラフ生成まで完了できました。 一方で、内部の設定はブラックボックスな部分も多く、挙動もサービス更新によって変わる可能性があります。安定的な動作やカスタマイズ性などが重要な場合は、現状はスクラッチでの開発が無難だと感じました。 最後に、記事執筆中にもGoogle Workspace Flowsが発表されるなど、生成AI関連のローコードツールの進化は目まぐるしいものがあります。今後も「ノーコードでどこまで任せるか／どこからコードで実装するか」を継続的にキャッチアップしていきたいと思います。

こんにちは！データサイエンティストの白井です。 今日は、私が第35回人工知能学会金融情報学研究会(SIG-FIN)で発表した LLMs による利益予測の分析とアウトオブサンプル評価 について紹介します。 本記事は、 Insight Edge Advent Calendar 2025 の9日目の記事となっております。 また Advent Calendarの7日目 には、35回SIG-FINの包括的なレポート記事もありますので、ご興味があれば覗いてみてください！ はじめに EDINETについて 有価証券報告書の紹介 データについて EDINET-BENCHについて EDINET-BENCHでの予測方法 LLMでの未来予測の検証における注意点 LLMを用いたアウトオブサンプル評価 おわりに はじめに 今回は、「LLMを用いた、企業の1年後利益の増減予測」に関する、LLMのナレッジカットオフ以前と以降の精度を確認する内容です。 LLMを用いた未来の予測は、企業の利益だけでなく、色々な場面での活用余地があるかと思いますので、何かのご参考になれば幸いです。 記事全体の流れは以下です。 EDINETについて EDINET-BENCHについて LLMを用いた未来予測における注意点 アウトオブサンプル評価について EDINETについて EDINETとは、金融庁が運営する有価証券報告書等の提出・閲覧システムです。 有価証券報告書は、上場企業などが金融庁（EDINET）を通じて提出する、事業内容や財務状況などを報告するための書類です。 有価証券報告書の紹介 有価証券報告書の例は以下です。 ※1 利益や売上、従業員数などのデータが、直近5年などでまとめられている形式が多いです。 各企業がどんな売上や利益の推移をしているかなどが、確認できるようになっています。 また、有価証券報告書は、上記のような財務指標だけでなく、事業リスクのような数値で表せないテキスト情報も含まれています。 ※1 データについて EDINETは、上記の有価証券報告書等を保管しており、そのデータはAPI Keyを登録することで、無料で取得できます。 XBRLという形式で保管されており、これを理解するのはなかなかハードルが高いのですが、2024年4月以降はCSV形式でダウンロードできるようになり、かなり扱いやすくなっています。 CSVファイルは、以下のような形式です。 ※1 値の意味や対象時期、連結か単体か、などが整理されて格納されており、APIで取得できるためシステム連携もしやすくなっています。 また、数値データだけでなく、テキスト情報も格納されています。 ※1 このように、企業の活動内容が、数値とテキストの両方で確認できるデータとなっています。 EDINET-BENCHについて EDINET-BENCH は、Sakana AIが2025年6月9日に発表した、EDINETを用いた金融向けのベンチマークデータセットです。 EDINET-BENCHは、上記で説明したEDINETのデータと、3種類のラベル（不正会計・利益増減・業種）で作られています。 ※2 これらのラベルを予測するモデルを複数作り、どのモデルが良いかを横並びで比較できるベンチマークとなっています。 EDINET-BENCH内では、ロジスティック回帰や複数のLLMでの精度評価をしており、LLMにテキストデータも含めて予測させると、予測精度が上がったことが報告されています。 ※2 EDINET-BENCHでの予測方法 タスクの一つ、企業の利益増減予測を対象にした、LLMでの予測は、以下のプロンプトテンプレートで実行します。 Please predict whether the "親会社株主に帰属する当期純利益" (Net income attributable to owners of the parent) in the next fiscal year's securities report will increase compared to the current fiscal year, based on the information available in the current year's securities report. - The input is extracted from a Japanese company's securities report. - Some information may be missing and represented as "-" due to parsing errors. - Some attributes are missing and the total does not equal the sum of the parts. Respond in the following format: JSON: `json` { "prob": float (between 0 and 1, probability that the profit will increase), "prediction": int (0: Decrease, 1: Increase), "reasoning": "string", The current year's extracted securities report is as follows: {report_values} 来年の当期純利益が増加するか減少するかを、JSON形式で確率(0〜1)・予測結果(1:増加、0:減少)、理由を返すというプロンプトになっています。 コンテキストに{report_values}を渡せるようになっていて、これは具体的には以下のような形式です。 bs: {"現金及び預金": {"Prior1Year": "2090173000", "CurrentYear": "2045720000"}, "現金及び現金同等物": {"Prior2Year": "1330697000", "Prior1Year": "2090173000", "CurrentYear": "2045720000"}, cf: {"当期利益": {"Prior1Year": "217213000", "CurrentYear": "285490000"}, "税引前当期純利益": {"Prior1Year": "330891000", "CurrentYear": "399227000"}, "減価償却費及び償却費": {"Prior1Year": "9126000", "CurrentYear": "9933000"}, " pl: {"売上高": {"Prior1Year": "6146959000", "CurrentYear": "6233729000"}, "売上原価": {"Prior1Year": "4806251000", "CurrentYear": "4844096000"}, "売上総利益又は売上総損失（△)": {"Prior1Year": "1340708000", "CurrentYear": "1389632000"}, text: {“沿革”: “xxxxxxxxxxx”, “事業リスク”: “yyyyyyy”, "...": "....."} EDINET-BENCH内で指定した、PL(損益計算書)・BS(貸借対照表)・CF(キャッシュフロー計算書)・text(テキスト項目)を、それぞれキーが項目名、値が値のJSON形式で入力します。 これを実行すると、以下のようなresponseが得られます。 { "prob": 0.65, "prediction": 1, "reasoning": "To predict future profit trends, I'll analyze several key factors from the financial data:\n\n1. Revenue and profit trends:... } このprobやpredictionと、実際の増減のラベルを使うことで、ROC-AUCやAccuracyが計算できるようになっています。 LLMでの未来予測の検証における注意点 LLMを用いた予測を実施する際、注意すべき観点があります。 それは、「LLMにとって、既知な内容であるかもしれない」ということです。 LLMの学習では、Web上のテキストや電子書籍、ニュース記事など膨大なテキストを利用しています。 そのため、予測する内容によっては、LLMにとって既知であることがあり得ます。 例えば、EDINET-BENCHの利益増減予測で最高精度が確認されたClaude 3.7 Sonnetに、2022年のトヨタの利益は前年に比べて増加したか?を聞いてみましょう。 Q: トヨタの2022年の利益は前年に比べて増加しましたか？ A: トヨタ自動車の2022年3月期（2021年4月〜2022年3月）の決算情報によると、 営業利益は前年比36.3%増の3兆円、純利益は26.9%増の2.85兆円となり、 前年と比較して増加しました。 今度は、2025年に変えて聞いてみます。 Q: トヨタの2025年の利益は前年に比べて増加しましたか？ A: 申し訳ありませんが、2025年のトヨタの利益に関する情報は現時点では持っていません。 2025年はまだ到来していないため、その年の財務結果はまだ発表されていません。 トヨタの最新の財務情報や将来の予測については、トヨタの公式ウェブサイト、投資家向け情報、 または信頼できる経済ニュースソースで確認されることをお勧めします。 2022年に対しては「増加した」と回答しており、2025年に対しては「分からない」と回答しています。 これは、LLMの学習データの最終日付（ナレッジカットオフ日）が影響していると考えられます。 Claude-3.7-sonnetのナレッジカットオフ日は2024/10/31で、この日までにwebなどで公開されたテキストはLLM自体の学習に利用されていると考えられます。 よって、2022年の利益の増減は学習データに入っているため、LLMにとっては既知の内容で、回答ができます。 一方、2025年の利益の増減は学習データに入っていないため、LLMにとっては未知の内容で、回答ができないということです。 LLMを用いた未来の予測は、本来は知り得ない内容を予測したいのですが、バックテストでは上記の点を考慮しないと本当に計測したい精度が確認できない可能性があります。 これが、LLMを用いた未来の予測における注意点です。 LLMを用いたアウトオブサンプル評価 EDINET-BENCHは日本企業を対象とした、金融向けベンチマークとしてとても貴重な内容です。 しかし、目的はベンチマークの構築で、ナレッジカットオフを考慮した評価は報告されておりません。 そこで、EDINET-BENCHの利益増減予測をアウトオブサンプルで評価するとどうなるかを確認してみます。 以下が、アウトオブサンプル評価のイメージです。 利用するモデルは、Claude 3.7 Sonnetを用います。 ナレッジカットオフ日は2024/10/31です。 この日以前に公開された情報に対する予測をインサンプル評価、2025/6/1〜2025/8/31に公開された情報に対する予測をアウトオブサンプル評価とします。 そして、この2つの精度を比較することで、予測精度の汎化性能を確認しました。 インサンプルはEDINET-BENCHのテストデータで予測ができた447件、アウトオブサンプルは対象期間で予測ができた2212件です。 結果は以下です。 アウトオブサンプルにおいても、大幅な精度劣化は見られないという結果となりました。 予想に反し、アウトオブサンプルにて精度が上がっています。 ただし、こちらの比較は、以下の点であまり良い比較ができていないと思っております。 評価の対象数が5倍ほど異なる。 評価の対象年度がインサンプルは2020年〜2024年と幅があるが、アウトオブサンプルは2025年6月〜2025年8月の3ヶ月間のみ。 LLMの予測結果はブレがあり（完全再現せず）、本来は何回か実行してその平均を取るのが良いのですが、今回は予測実行は1度のみ。 これらのことから、精度が上がったというよりも、「大幅な精度劣化が見られなかった」という程度で受け止めています。 また、2024/10/31がカットオフ日であることも、厳密なアウトオブサンプル評価となっておりません。 例えば、2025年3月期決算の会社は、2024年9月に半期の結果なども公開しており、ここに通期予測などが比較的確度の高い情報として記載されているはずです。 これらのことから、今後は以下を考慮した評価をしたいと思っています。 インサンプルとアウトオブサンプルの期間/件数の統一 半期報告書などが提出されていない、本当の意味で1年後が未知な状態での比較 おわりに 今回は、LLMを用いた1年後の利益増減予測のアウトオブサンプル評価を紹介しました。 LLMでの未来予測は、様々な利用シーンが考えられます。 その際に、予測精度を検証する場合は、ナレッジカットオフに注意しないと検証時と運用時で異なる精度となってしまうことが想定されます。 本記事が、誰かの参考になると幸いです。 出典 ※1 : 金融庁EDINET ※2 : Sakana AI「EDINET-BENCH」

こんにちは、Insight Edgeの小林まさみつです。本記事は Insight Edge Advent Calendar 2025 の8日目の記事です。 最近は生成AIをソフトウェア領域に応用した開発をしていますが、今回は趣向を変えてハードウェアと組み合わせたシステムを作成してみたので紹介します。 目次 1. はじめに 1.1 なぜ作ったのか 1.2 完成システムの紹介 1.3 この記事で分かること 2. システム概要 2.1 全体構成図 2.2 使用技術スタック 2.3 動作の流れ 3. ハードウェア編：振動モーター制御回路 3.1 必要な部品リスト 3.2 回路図と配線 3.3 動作確認とコード 4. ソフトウェア編：姿勢判定システム 4.1 カメラ設置とPythonでの画像取得 4.2 生成AI(Bedrock Claude Sonnet 4)との連携 4.3 Arduino との通信(シリアル通信) 4.4 統合プログラム 5. 実際に使ってみて 5.1 効果を実感した点 5.2 振動の強さについて 5.3 生成AIの判定精度 6. 今後の展望 7. まとめ 1. はじめに 1.1 なぜ作ったのか 長時間のデスクワークで肩こりや腰痛に悩まされ、「姿勢を良くしなければ」と思いつつも、集中していると姿勢のことなど忘れてしまいます。 市販の姿勢矯正グッズも検討しましたが、高価なものが多く、効果も不透明。そこで「技術で解決できるのでは？」と考え、自作することにしました。 当初はエアバッグで物理的に姿勢を矯正する構想もありましたが、コストと複雑さを考慮し、 振動で姿勢の悪化を通知する シンプルなシステムに方針転換しました。 従来の画像認識ライブラリでは、照明条件や服装の変化で精度が不安定になりがちです。一方、生成AIであれば自然言語で評価基準を定義でき、より柔軟な判定が期待できます。そこで 生成AIで姿勢を評価し、振動で身体に直接フィードバックする 実験的なシステムを構築しました。 1.2 完成システムの紹介 システムは以下の3つの要素で構成されています： Webカメラ : 横から姿勢を撮影 PC : 生成AIで姿勢評価 Arduino+振動モーター : 姿勢の悪い箇所をユーザーに通知 Arduino とは、電子工作を簡単に始められる小型のコンピューター基板(=マイコン)です。 姿勢が悪くなると、該当する部位が振動して通知されます。例えば猫背なら腰が、左に傾いていれば左太ももが振動する仕組みです。 動作イメージは以下の通りです。 Webカメラが5分ごとにユーザーの姿勢を撮影 左の画像は良い姿勢、右は悪い姿勢の例です。左足が浮いており、腰も前傾していることがわかります。右側のように姿勢が悪くなったタイミングで振動モーターを動作させます。 結果に応じてArduinoに指示を送り、振動モーターを動作 結果に応じて、左足・右足・腰のいずれか、または複数が振動して姿勢の悪化を通知します。これを人の足にテープなどで固定して使用します。 1.3 この記事で分かること 本記事では、以下の内容を解説します： 生成AI活用 : AWS Bedrock Claude Sonnet 4による姿勢評価の実装方法 ハードウェア制御 : Arduino + 振動モーターの制御回路の設計と配線 システム統合 : Webカメラ ⟷ PC ⟷ Arduino間の通信の実装 2. システム概要 2.1 全体構成図 システムの全体像は以下の通りです。 カメラで撮影した画像をPCで取得し、生成AIに送信して姿勢を評価。その結果に基づいてArduinoに指示を送り、適切な振動モーターを動作させます。 各コンポーネントは疎結合で、それぞれ独立してテスト・改善できる構成になっています。 2.2 使用技術スタック システム全体で使用した技術は以下の通りです。 レイヤー 技術 用途 言語 Python 3.13 システム全体の制御 AI推論 AWS Bedrock Claude Sonnet 4 姿勢評価 画像取得 OpenCV (Python) カメラ制御 通信 pySerial PC-Arduino間 マイコン Arduino Uno モーター制御 また、利用したツールは以下の通りです。 ツール 用途 Arduino IDE Arduinoコード開発/マイコンへの書き込み Tinkercad 回路設計とシミュレーション Webカメラ こちら を参考にiPhoneをWebカメラ化しました 2.3 動作の流れ システムの動作フローは以下の通りです： 画像取得 ：Webカメラが5分ごとにユーザーの姿勢を撮影する AI評価 : PythonでAWS Bedrock(Claude Sonnet 4)に画像を送信し、姿勢を評価 コマンド送信 ：評価結果に応じてシリアル通信でArduinoに指示 各部位のスコアをもとに、振動すべき箇所を3ビットで表現する 左足・右足・腰の順番に0/1とし、問題がある箇所を 1 に設定 例： 000 (全て良好)、 100 (左足が悪い)、 111 (全て悪い) モーター制御 ：Arduinoが該当する振動モーターを動作させる ループ ：1に戻り、継続的に監視 評価頻度は5分に1回としました。 当初は30秒ごとの評価も検討しましたが、以下の理由で5分間隔を選択しました。 APIコストの削減 姿勢改善には継続的な意識づけが重要で、頻繁すぎる通知は逆効果になるため 3. ハードウェア編：振動モーター制御回路 3.1 必要な部品リスト 回路の構築に用いた部品は以下の通りです。 部品名 型番・仕様 個数 用途 マイコン Arduino Uno 1 モーター制御 振動モーター FM34E 3 触覚フィードバック トランジスタ DTC143EL 3 スイッチング 抵抗 1kΩ 3 ベース電流制限 ダイオード 1N4007 3 逆起電力保護 ブレッドボード 標準サイズ 1 配線用 ジャンパーワイヤー オス-オス 11本 回路の接続用 ジャンパーワイヤー オス-メス 6本 振動モーター接続用 ジャンパーワイヤー (必要に応じて) オス-メス 任意の本数 振動モーター延長用 振動モーターを延長する場合は、オス-メスのジャンパーワイヤーを追加で24本程度用意することを推奨します。 3.2 回路図と配線 回路図の作り方 回路設計の経験が無かったため、生成AIに回路図の作成を依頼しました。 出力された回路図をもとに、 Tinkercad でシミュレーションと配線図の作成をしました。 初心者でも簡単に始められ、無料で利用できるため非常に便利です。 基本回路(1個のモーター) まず、1個の振動モーターを制御する基本回路を説明します。 回路の動作原理： Arduinoのデジタルピン(D3)から信号を出力し、抵抗を経由してトランジスタのベースに接続します。トランジスタはスイッチとして機能し、ベースに電圧がかかるとコレクタ-エミッタ間が導通し、モーターに電流が流れます。 ダイオードはモーターと並列に逆向きで接続され、モーター停止時の逆起電力を吸収します。これにより、Arduinoや他の回路が逆電圧で破損することを防ぎます。 PWM制御の必要性： 使用する振動モーターの定格は3Vですが、Arduinoの出力は5Vです。そのまま接続すると過電圧になるため、PWM(Pulse Width Modulation)制御を使って実効電力を調整します。具体的には、 analogWrite(pin, 153) とすることで、約60%のデューティサイクル(153/255)で動作し、平均電圧を約3Vに下げることができます。 完全な配線(3個のモーター) 次に、3個のモーターを制御する完全な回路です。 配線した回路 配線時の重要な注意点： トランジスタの向き ：平らな面を手前に向けて挿入します。左からエミッタ(E)、コレクタ(C)、ベース(B)の順です。 ダイオードの向き ：銀色の帯のある方がカソード(+側)で、モーターのプラス側に接続します。逆に接続すると短絡の原因になります。 PWM対応ピンの使用 ：Arduino Unoでは、D3/D5/D6/D9/D10/D11がPWM対応です。今回はD3/D5/D6を使用しています。 3.3 動作確認とコード Arduino IDEのシリアルモニタから手動でコマンドを送信して、動作を確認できます。 Arduinoコード // ピン定義 const int LEFT_LEG_PIN = 3; // 左脚用振動モーター const int RIGHT_LEG_PIN = 5; // 右脚用振動モーター const int WAIST_PIN = 6; // 腰用振動モーター // 振動設定 const int VIBRATION_DURATION = 5000; // 振動時間（ミリ秒） const int VIBRATION_INTENSITY = 153; // PWM値（0-255） 5V電源をモーターに約3Vで供給するため153に設定 String receivedData = ""; bool dataComplete = false; void setup() { // シリアル通信を開始（9600 baud） Serial.begin(9600); // ピンを出力モードに設定 pinMode(LEFT_LEG_PIN, OUTPUT); pinMode(RIGHT_LEG_PIN, OUTPUT); pinMode(WAIST_PIN, OUTPUT); // 初期状態：全モーター停止 analogWrite(LEFT_LEG_PIN, 0); analogWrite(RIGHT_LEG_PIN, 0); analogWrite(WAIST_PIN, 0); // 起動確認用フラッシュ startupFlash(); } void loop() { // シリアルデータが利用可能かチェック if (Serial.available()) { String receivedString = Serial.readString(); if (receivedString.length() > 0) { receivedData = receivedString; dataComplete = true; } } // データ受信完了時の処理 if (dataComplete) { processPostureFeedback(receivedData); receivedData = ""; dataComplete = false; } } void processPostureFeedback(String data) { // 3桁のバイナリ文字列を期待（例："101"） if (data.length() != 3) { Serial.println("Error: Invalid data format. Expected 3 digits."); return; } // 各桁をチェックして対応する振動を制御 bool leftLegVibrate = (data.charAt(0) == '1'); bool rightLegVibrate = (data.charAt(1) == '1'); bool waistVibrate = (data.charAt(2) == '1'); // 振動パターンを実行 executeVibrationPattern(leftLegVibrate, rightLegVibrate, waistVibrate); } void executeVibrationPattern(bool leftLeg, bool rightLeg, bool waist) { // 全モーター停止 stopAllMotors(); // 振動が必要な部位があるかチェック if (!leftLeg && !rightLeg && !waist) { return; } // 対象部位を振動 if (leftLeg) { analogWrite(LEFT_LEG_PIN, VIBRATION_INTENSITY); } if (rightLeg) { analogWrite(RIGHT_LEG_PIN, VIBRATION_INTENSITY); } if (waist) { analogWrite(WAIST_PIN, VIBRATION_INTENSITY); } // 振動時間待機 delay(VIBRATION_DURATION); // 全モーター停止 stopAllMotors(); } void stopAllMotors() { analogWrite(LEFT_LEG_PIN, 0); analogWrite(RIGHT_LEG_PIN, 0); analogWrite(WAIST_PIN, 0); } void startupFlash() { // 起動時に全モーターを短時間点灯してテスト Serial.println("System test - All motors flash"); for (int i = 0; i < 3; i++) { analogWrite(LEFT_LEG_PIN, VIBRATION_INTENSITY); analogWrite(RIGHT_LEG_PIN, VIBRATION_INTENSITY); analogWrite(WAIST_PIN, VIBRATION_INTENSITY); delay(200); stopAllMotors(); delay(200); } Serial.println("System test completed"); } 4. ソフトウェア編：姿勢判定システム 4.1 カメラ設置とPythonでの画像取得 前提：姿勢を表すためのモデル定義 以下のPydanticモデルを用いて、生成AIからの姿勢評価を受け取りArduinoに送信する形式へ変換します。 姿勢評価のPydanticモデルコード from pydantic import BaseModel, Field POSTURE_THRESHOLD = 0.7 # 姿勢スコアの閾値 class FeedbackModel (BaseModel): left_leg_score: float = Field(..., description= "左脚の姿勢スコア" , ge= 0.0 , le= 1.0 ) right_leg_score: float = Field(..., description= "右脚の姿勢スコア" , ge= 0.0 , le= 1.0 ) waist_score: float = Field(..., description= "腰の姿勢スコア" , ge= 0.0 , le= 1.0 ) remarks: str = Field( "" , description= "スコア評価の備考" ) def to_should_vibrate (self) -> str : """ 振動フィードバックが必要かどうかを判定 3桁の0, 1の組み合わせで返す。 左足・右足・腰の順番 例： - 000: 全て良好 - 100: 左足が悪い - 111: 全て悪い """ res = "" res += "1" if self.left_leg_score < POSTURE_THRESHOLD else "0" res += "1" if self.right_leg_score < POSTURE_THRESHOLD else "0" res += "1" if self.waist_score < POSTURE_THRESHOLD else "0" return res Pythonでの画像取得 OpenCVを使ってカメラから画像を取得します。 画像取得のコード import cv2 from datetime import datetime # Webカメラのキャプチャを開始 cap = cv2.VideoCapture( 0 ) # キャプチャがオープンしている間続ける while (cap.isOpened()): ret, frame = cap.read() if ret: # カメラ映像を表示 cv2.imshow( 'Webcam Live' , frame) # 's'キーが押されたらスクリーンショットを保存 if cv2.waitKey( 1 ) & 0xFF == ord ( 's' ): timestamp = datetime.now().strftime( "%Y%m%d_%H%M%S" ) filename = f "screenshot/screenshot_{timestamp}.png" cv2.imwrite(filename, frame) # 'q'キーが押されたらループから抜ける if cv2.waitKey( 1 ) & 0xFF == ord ( 'q' ): break else : break # キャプチャをリリースし、ウィンドウを閉じる cap.release() cv2.destroyAllWindows() ポイント： cv2.VideoCapture(0) の引数は環境によって異なります。複数のカメラが接続されている場合は、番号を変えて試してください。 動作確認用のため、 's' キーでスクリーンショットを保存するようにしています。最終的には5分ごとに自動で保存するロジックを追加します。 4.2 生成AI(Bedrock Claude Sonnet 4)との連携 AWS Bedrockのセットアップ AWS Bedrockを使用するには、事前にAWSアカウントとCLIの設定が必要です。 必要な準備： 1. AWSアカウントの作成 2. IAMユーザーの作成(Bedrock実行権限付与) 3. AWS CLIのインストールと設定( aws configure ) 4. Bedrock APIへのアクセス権限の確認(リージョンは ap-northeast-1 など) 姿勢評価の実装 Claude Sonnet 4に画像を送信して姿勢を評価するクラスを実装します。 Claudeを呼び出し姿勢を評価するコード import json import boto3 from model import FeedbackModel MODEL_ID = "" # Bedrockで使用するモデルIDを指定してください。 class BedrockClient (): def __init__ (self): self.client = boto3.client( 'bedrock-runtime' ) # 姿勢評価 def evaluate_posture (self, img_bytes: bytes ): system_prompt = ( "ユーザーから提供されるbase64エンコードされた画像を解析し、姿勢評価を行ってください。 \n " "画像横から撮影した人が映っています。座り姿勢が良いか悪いかを判定し、以下のJSON形式で返してください。 \n\n " "1. left_leg_score: 左脚の姿勢スコア（0-1のfloat、1が最良） \n " "2. right_leg_score: 右脚の姿勢スコア（0-1のfloat、1が最良） \n " "3. waist_score: 腰の姿勢スコア（0-1のfloat、1が最良） \n\n " "JSON形式の例: {{ \" left_leg_score \" : 0.8, \" right_leg_score \" : 0.9, \" waist_score \" : 0.7}}" ) messages = [{ "role" : "user" , "content" : [ { "image" : { "format" : "png" , "source" : { "bytes" : img_bytes } } } ] }] response = self.client.converse( modelId=MODEL_ID, system=[{ "text" : system_prompt}], inferenceConfig={ "temperature" : 0 }, messages=messages, toolConfig={ "tools" : [ { "toolSpec" : { "name" : "extract_Feedback_Model" , "description" : "inputSchemaに沿ってFeedbackというPydanticモデルを出力するツール" , "inputSchema" : { "json" : FeedbackModel.model_json_schema()} } } ], "toolChoice" : { "tool" : { "name" : "extract_Feedback_Model" } } } ) # Bedrockのレスポンスから姿勢評価結果のJSONを抽出し、FeedbackModelに変換して返す tool_res = response[ "output" ][ "message" ][ "content" ][ 0 ][ "toolUse" ][ "input" ] if isinstance (tool_res, str ): tool_res = json.loads(tool_res) return FeedbackModel(**tool_res) ポイント ユーザーから提供される画像を読み取り、バイト列としてClaude Sonnet 4に送信します。 BedrockにおけるClaudeはtoolConfigを利用することで、Pydanticモデルを用いたJSONレスポンスを受け取ることができます。一方、必ず意図した形式で返ってくるとは限らないため、必要に応じてエラーハンドリングを追加してください。 4.3 Arduino との通信(シリアル通信) シリアル通信の基礎 PythonからArduinoに指示を送るには、シリアル通信を使用します。pySerialライブラリをインストールする必要があります。 Arduinoコントローラーの実装 姿勢評価結果に基づいてArduinoに適切なコマンドを送信するクラスを作成します。 Arduinoコントローラーのコード import serial from model import FeedbackModel def run_vibration_feedback (arduino: serial.Serial, feedback: FeedbackModel) -> None : """ Arduinoを使用して振動フィードバックを提供する関数 """ # 1. フィードバックを解析 should_vibrate = feedback.to_should_vibrate() # 2. フィードバック信号をArduinoに送信 arduino.write( bytes (should_vibrate, encoding= "ascii" )) # 生成AIからのフィードバックをモック化 feedback = FeedbackModel( left_leg_score= 0.4 , right_leg_score= 0.6 , waist_score= 0.7 , remarks= "Test feedback" ) # Arduinoのシリアルポートとボーレートを設定。環境に応じて適切に変更してください。 ARDUINO_PORT = '/dev/cu.usbmodem114301' ARDUINO_BAUDRATE = 9600 # Arduinoに接続する arduino = serial.Serial(ARDUINO_PORT, ARDUINO_BAUDRATE) # 振動フィードバックを実行 run_vibration_feedback(arduino, feedback) # 接続を閉じる arduino.close() ポイント 1. 振動フィードバックの実行には、Arduinoが接続されている必要があります。 2. Arduinoのシリアルポートやボーレートは環境によって異なります。後述の確認方法を参考に適切に設定してください。 COMポートの確認方法： Windows : デバイスマネージャーで「ポート(COMとLPT)」を確認。 COM3 , COM4 など。 Mac : ターミナルで ls /dev/cu.* を実行。 /dev/cu.usbserial-XXXX など。 Linux : ターミナルで ls /dev/ttyUSB* または ls /dev/ttyACM* を実行。 Arduino IDEのシリアルモニタを開いている場合は、ポートが占有されているため、Pythonから接続できません。必ず閉じてから実行してください。また、ポート番号はArduino IDEで確認すると便利です。 4.4 統合プログラム すべてのコンポーネントを統合し、システム全体を動作させるメインプログラムです。 コード全文 main.py # main.py from datetime import datetime import cv2 import time import serial from bedrock import BedrockClient from model import FeedbackModel # Arduinoのシリアルポートとボーレートを設定。環境に応じて適切に変更してください。 ARDUINO_PORT = '/dev/cu.usbmodem114301' ARDUINO_BAUDRATE = 9600 interval_sec = 300 def get_image (frame) -> bytes : """OpenCVのフレームを画像バイトに変換して返す""" timestamp = datetime.now().strftime( "%Y%m%d_%H%M%S" ) filename = f "screenshot/screenshot_{timestamp}.png" # スクリーンショットを保存 cv2.imwrite(filename, frame) res: bytes = b "" # 画像をバイトに変換 with open (filename, "rb" ) as img_file: res = img_file.read() return res def run_capture_analysis (frame): # -> Feedback: """ OpenCVでキャプチャしたフレームを元に姿勢分析を行う関数 """ # 1. frameをbyteで送信 img_bytes = get_image(frame) # 2. Bedrockに送信して姿勢推定 bedrock_client = BedrockClient() return bedrock_client.evaluate_posture(img_bytes) def run_vibration_feedback (arduino: serial.Serial, feedback: FeedbackModel) -> None : """ Arduinoを使用して振動フィードバックを提供する関数 """ # 1. フィードバックを解析 should_vibrate = feedback.to_should_vibrate() # 2. フィードバック信号を送信 arduino.write( bytes (should_vibrate, encoding= "ascii" )) def main (): # ウェブカメラのキャプチャを開始 cap = cv2.VideoCapture( 0 ) arduino = serial.Serial(ARDUINO_PORT, ARDUINO_BAUDRATE) # キャプチャがオープンしている間続ける while (cap.isOpened()): time.sleep(interval_sec) ret, frame = cap.read() if not ret: break # デバッグ用にフレームを表示 cv2.imshow( 'Webcam Live' , frame) feedback = run_capture_analysis(frame) run_vibration_feedback(arduino, feedback) # 'q'キーが押されたらループから抜ける if cv2.waitKey( 1 ) & 0xFF == ord ( 'q' ): break # キャプチャをリリースし、ウィンドウを閉じる cap.release() cv2.destroyAllWindows() arduino.close() if __name__ == "__main__" : main() bedrock.py # bedrock.py import json import boto3 from model import FeedbackModel MODEL_ID = "" # Bedrockで使用するモデルIDを指定 class BedrockClient (): def __init__ (self): self.client = boto3.client( 'bedrock-runtime' ) # 姿勢評価 def evaluate_posture (self, img_bytes: bytes ): system_prompt = ( "ユーザーから提供されるbase64エンコードされた画像を解析し、姿勢評価を行ってください。 \n " "画像横から撮影した人が映っています。座り姿勢が良いか悪いかを判定し、以下のJSON形式で返してください。 \n\n " "1. left_leg_score: 左脚の姿勢スコア（0-1のfloat、1が最良） \n " "2. right_leg_score: 右脚の姿勢スコア（0-1のfloat、1が最良） \n " "3. waist_score: 腰の姿勢スコア（0-1のfloat、1が最良） \n\n " "JSON形式の例: {{ \" left_leg_score \" : 0.8, \" right_leg_score \" : 0.9, \" waist_score \" : 0.7}}" ) messages = [{ "role" : "user" , "content" : [ { "image" : { "format" : "png" , "source" : { "bytes" : img_bytes } } } ] }] response = self.client.converse( modelId=MODEL_ID, system=[{ "text" : system_prompt}], inferenceConfig={ "temperature" : 0 }, messages=messages, toolConfig={ "tools" : [ { "toolSpec" : { "name" : "extract_Feedback_Model" , "description" : "inputSchemaに沿ってFeedbackというPydanticモデルを出力するツール" , "inputSchema" : { "json" : FeedbackModel.model_json_schema()} } } ], "toolChoice" : { "tool" : { "name" : "extract_Feedback_Model" } } } ) # Bedrockのレスポンスから姿勢評価結果のJSONを抽出し、FeedbackModelに変換して返す tool_res = response[ "output" ][ "message" ][ "content" ][ 0 ][ "toolUse" ][ "input" ] if isinstance (tool_res, str ): tool_res = json.loads(tool_res) return FeedbackModel(**tool_res) model.py # model.py from pydantic import BaseModel, Field POSTURE_THRESHOLD = 0.7 # 姿勢スコアの閾値 class FeedbackModel (BaseModel): left_leg_score: float = Field(..., description= "左脚の姿勢スコア" , ge= 0.0 , le= 1.0 ) right_leg_score: float = Field(..., description= "右脚の姿勢スコア" , ge= 0.0 , le= 1.0 ) waist_score: float = Field(..., description= "腰の姿勢スコア" , ge= 0.0 , le= 1.0 ) remarks: str = Field( "" , description= "スコア評価の備考" ) def to_should_vibrate (self) -> str : """ 振動フィードバックが必要かどうかを判定 3桁の0, 1の組み合わせで返す。 左足・右足・腰の順番 例： - 000: 全て良好 - 100: 左足が悪い - 111: 全て悪い """ res = "" res += "1" if self.left_leg_score < POSTURE_THRESHOLD else "0" res += "1" if self.right_leg_score < POSTURE_THRESHOLD else "0" res += "1" if self.waist_score < POSTURE_THRESHOLD else "0" return res motor.ino // ピン定義 const int LEFT_LEG_PIN = 3 ; // 左脚用振動モーター const int RIGHT_LEG_PIN = 5 ; // 右脚用振動モーター const int WAIST_PIN = 6 ; // 腰用振動モーター // 振動設定 const int VIBRATION_DURATION = 5000 ; // 振動時間（ミリ秒） const int VIBRATION_INTENSITY = 153 ; // PWM値（0-255） String receivedData = "" ; bool dataComplete = false ; void setup () { // シリアル通信を開始（9600 baud） Serial. begin ( 9600 ); // ピンを出力モードに設定 pinMode (LEFT_LEG_PIN, OUTPUT); pinMode (RIGHT_LEG_PIN, OUTPUT); pinMode (WAIST_PIN, OUTPUT); // 初期状態：全モーター停止 analogWrite (LEFT_LEG_PIN, 0 ); analogWrite (RIGHT_LEG_PIN, 0 ); analogWrite (WAIST_PIN, 0 ); // 起動確認用フラッシュ startupFlash (); } void loop () { // シリアルデータが利用可能かチェック if (Serial. available ()) { String receivedString = Serial. readString (); if (receivedString. length () > 0 ) { receivedData = receivedString; dataComplete = true ; } } // データ受信完了時の処理 if (dataComplete) { processPostureFeedback (receivedData); receivedData = "" ; dataComplete = false ; } } void processPostureFeedback (String data) { // 3桁のバイナリ文字列を期待（例："101"） if (data. length () != 3 ) { Serial. println ( "Error: Invalid data format. Expected 3 digits." ); return ; } // 各桁をチェックして対応する振動を制御 bool leftLegVibrate = (data. charAt ( 0 ) == '1' ); bool rightLegVibrate = (data. charAt ( 1 ) == '1' ); bool waistVibrate = (data. charAt ( 2 ) == '1' ); // 振動パターンを実行 executeVibrationPattern (leftLegVibrate, rightLegVibrate, waistVibrate); } void executeVibrationPattern ( bool leftLeg, bool rightLeg, bool waist) { // 全モーター停止 stopAllMotors (); // 振動が必要な部位があるかチェック if (!leftLeg && !rightLeg && !waist) { return ; } // 対象部位を振動 if (leftLeg) { analogWrite (LEFT_LEG_PIN, VIBRATION_INTENSITY); } if (rightLeg) { analogWrite (RIGHT_LEG_PIN, VIBRATION_INTENSITY); } if (waist) { analogWrite (WAIST_PIN, VIBRATION_INTENSITY); } // 振動時間待機 delay (VIBRATION_DURATION); // 全モーター停止 stopAllMotors (); } void stopAllMotors () { analogWrite (LEFT_LEG_PIN, 0 ); analogWrite (RIGHT_LEG_PIN, 0 ); analogWrite (WAIST_PIN, 0 ); } void startupFlash () { // 起動時に全モーターを短時間点灯してテスト Serial. println ( "System test - All motors flash" ); for ( int i = 0 ; i < 3 ; i++) { analogWrite (LEFT_LEG_PIN, VIBRATION_INTENSITY); analogWrite (RIGHT_LEG_PIN, VIBRATION_INTENSITY); analogWrite (WAIST_PIN, VIBRATION_INTENSITY); delay ( 200 ); stopAllMotors (); delay ( 200 ); } Serial. println ( "System test completed" ); } プログラムの構成： 初期化フェーズ ：カメラとArduinoを初期化 メインループ ： 5分待機 カメラから画像を取得 AIで姿勢評価 Arduinoにコマンド送信 終了処理 ：終了時リソースを適切に解放 5. 実際に使ってみて システムを1週間使用した結果、以下のような効果と課題が見えてきました。 5.1 効果を実感した点 最初はほぼ毎回振動させられ、そのたびに「ハッとして」姿勢を直していました。振動というフィードバックは、視覚や聴覚と比べて邪魔にならず、作業を中断させない点が良かったです。 4日目くらいから、少しずつ姿勢が改善され、振動される頻度が減ってきました。座り姿勢を意識する習慣がついたように感じます。 5.2 振動の強さについて 使用した3V振動モーターは、服の上からでもはっきりと分かるため、通知としての役割は十分果たせています。 一方で、長時間使用すると慣れてしまい、振動に対する感度が下がる傾向も見られました。振動パターンをランダム化する、または強弱をつけるなどの工夫が必要かもしれません。 5.3 生成AIの判定精度 Claude Sonnet 4の姿勢評価は想像以上に精密で、「確かにその通り」と思える判定が多くありました。 特に、微妙な体の傾きや脚の位置なども的確に指摘してくれるため、自分では気づかない姿勢の問題を発見できました。 6. 今後の展望 このシステムは実験的なプロトタイプですが、以下のような発展性があります。 複数部位への拡張 : 現在は3箇所ですが、首、肩、背中など5〜7箇所に増やすことで、より細かい姿勢の矯正が可能になります。 モーターの種類変更 : 振動モーター以外に、エアポンプとエアバッグを利用することで良い姿勢に矯正させることができます。 バッテリー駆動化 : USB給電からバッテリー駆動に変更し、ケーブルレスで使用できるようにできます。 同様の「自然言語での評価基準定義 + 物理フィードバック」のパターンは、評価が主観的になりがちな他の分野でも参考になるかもしれません。 7. まとめ 本記事を書くにあたり、大学以来久しぶりに電子工作をしました。生成AIを活用して回路図を作成し、シミュレータで動作確認をすることで、初学者でも簡単に取り組めました。ソフトウェアアプリケーションの領域だけでなく、ハードウェア制御の分野にも生成AIを活用できることを実感し、自身で取り組める範囲が広がったと感じています。本記事が、同様の課題を持つ方々の参考になれば幸いです。

はじめまして！Data Scientistの白井と市川です。 今回は、先日第35回 人工知能学会 金融情報学研究会（SIG-FIN） に行ってきましたので、そのレポートをさせて頂ければと思います。 イベントの概要 発表の概要 人工市場(4件) (01) 人工市場を用いた取引単位の違いが裁定取引に与える影響の分析 (03) 人工市場を用いた決済期間が異なる市場間での裁定取引が各市場に与える影響の分析 (04) 人工市場を用いたサーキットブレーカーの性能調査 投資戦略(4件) (05) 米国経済指標の集団的変動と産業セクター間の関係性の分析 (06) 多資産ネットワーク分析が示す暗号資産の独立性とポートフォリオ分散効果 (07) 長期相関を持つ成行注文流と価格インパクトのミクロモデル化に基づく株価の予測困難性の説明 (08) 戦略多様性と平方根則を取り入れた一般化LMFモデル テキストマイニング(5件) (09) 金融テキストごとの特徴分析とポートフォリオ評価 (10) 有価証券報告書テキストを用いた配当政策データの構築と分析 (11) LLMsによる利益予測の分析とアウトオブサンプル評価 (12) 適時開示テキスト埋め込みを用いたイベントスタディにおける累積異常リターンの予測 (13) 大規模言語モデルを用いたアンサンブル手法による J-REIT物件情報データセットの効率的な構築方法 データマイニング(4件) (14) トランザクションレンディングにおける法人のデフォルト分析 (15) Fiedlerベクトルと情報エントロピーを用いた株式ネットワークの構造変化検知 (16) 暗黙の政府保証を加味した国内地方債スプレッドの評価 (17) 本邦中古スマートフォン市場における価格形成に対する機種ブランドと為替レートの影響 機械学習(5件) (18) 事前エクスポージャー情報を活用した部分空間正則化付き主成分分析 (19) 財務諸表監査のための逐次検定：試査手続の統計学的な定式化と理論保証 (20) 学習期間が異なる株価予測機械学習モデルのアンサンブル学習による投資戦略の構築 (21) マルチモーダルデータを用いた機械学習モデルによる企業の業績修正予測 (22) 生成AIを用いた決算説明サプライズの定量化手法の提案 機械学習/テキストマイニング(4件) (23) 指値配分を連続確率分布化した深層学習によるマーケットメイキング (24) 3値ポートフォリオ最適化に対するQAOAミキサーの性能比較 (26) LLM-PEAD.txt：日本株式市場におけるLLMを用いたサプライズ抽出と決算後ドリフトの実証分析 (27) 有価証券報告書のサステナビリティ記述に関する分類および体系化 雑感 この記事は、 Insight Edge Advent Calendar 2025 7日目の記事です。 イベントの概要 人工知能学会 金融情報学研究会（SIG-FIN） は人工知能学会の第二種研究会です。 詳細は上記リンクに譲るのですが、近年より広い方々の金融市場への関心が高まっています。このような背景で、ファイナンス分野への人工知能技術の応用を促進するための研究会になります。人工知能分野の研究者や金融市場の現場の技術者が参加する、大変ユニークな研究会になっています。 余談ですが、今回も別業界の方がいらっしゃるなど、なかなか出会えない方とお話しすることができました。 最近、かなり発表量が増加傾向にあり、聴いているだけでも忙しい研究会です。例年、土曜日の1日のみの開催でしたが、発表数の増加に伴い、土日を両方使う研究会となりました。 概要は以下の通りです。 * 日時：2025年10月11日(土) および 10月12日(日) * 開催形式：会場およびオンライン（Zoom使用）のハイブリッド開催 * 会場：慶應義塾大学日吉キャンパス 来往舎1階シンポジウムスペース 第35回研究会 発表の概要 こちらの研究会はありがたいことに 各発表の概要pdfが公開されています 。 以下、著者の敬称略とさせて頂きます。 人工市場(4件) (01) 人工市場を用いた取引単位の違いが裁定取引に与える影響の分析 則武 誉人 (三井住友DSアセットマネジメント), 八木 勲 (工学院大学), 水田 孝信 (スパークス・アセット・マネジメント) 取引単位が異なる2つの先物市場間で行われる裁定取引について、小さい単位で取引できるミニ先物の取引単位の大きさが、裁定取引の発生にどのような影響を与えるかを、人工市場モデルを用いて分析した研究です。 研究の背景と目的 現実の金融市場では、同じ資産を対象としながら取引単位の異なる複数の先物市場が存在します。これら市場間で価格差が生じた際に、裁定取引が行われることが指摘されていますが、取引単位の小口化が裁定取引に与える具体的な影響は十分に解明されていません。これは、現実の市場では裁定取引の観測が困難であることや、多くの外部要因が価格に影響を与えるため、取引単位の違いだけを分離して分析することが難しいことが理由です。そこで本研究では、マルチエージェント型の人工市場を構築し、ミニ先物の取引単位を変化させることで、その影響を明らかにすることを目的としています。 分析モデル この研究では、取引単位が大きい「ラージ市場」と、小さい「ミニ市場」の2つの市場をモデル化しています。それぞれの市場には注文を出す「標準エージェント」が存在し、さらに両市場間で裁定取引を行う「裁定エージェント」を1体設定しています。 裁定エージェントは、以下の2つの要件が満たされた場合にのみ取引を実行します。 価格要件: 一方の市場の最良買い気配価格が、他方の市場の最良売り気配価格を上回る。 利益要件: 実際に売買を行った際に、売却代金が買い付け代金を上回る。 →　成行注文で成立することのみを考えている ラージ市場の取引単位を1に固定し、ミニ市場の取引単位（ ）を9段階に変化させてシミュレーションを行いました。 分析結果 シミュレーションの結果、以下の点が明らかになりました。 取引単位の小口化と発注行動の変化: ミニ市場の取引単位（ ）が小さくなると、価格要件は満たしても、ミニ市場側の最良気配の注文数量がラージ市場の取引単位に満たないため、利益要件を満たさずに裁定エージェントが発注を見送るケースが増加しました。図1は、 の例で、ラージ市場の最良買い気配（価格104）がミニ市場の最良売り気配（価格103）を上回っていますが、ラージ市場の取引単位1に合わせてミニ市場で買い付けると、次の価格帯（105）からも調達する必要があり、結果的に損失が出るため利益要件が成立しない状況を示しています。 利益要件を満たす機会の増加: 一方で、 の小口化はミニ市場のビッドアスクスプレッド（売値と買値の差）を縮小させる効果がありました。これにより、利益要件を満たす機会が相対的に増加し、結果として裁定取引の発注割合は の小口化とともに緩やかに増加し、一定の水準で収束することが示されました。具体的には、 の場合と比較して、 が小さくなるほど、価格要件と利益要件の両方を満たして発注される数量の割合が増加する傾向が見られました。 結論 取引単位の小口化が裁定取引に与える影響を明らかにしました。取引単位が小さくなると、最良気配の数量不足から裁定取引が見送られるケースが増える一方で、ビッドアスクスプレッドの縮小により利益機会が増え、全体としての裁定取引の割合はわずかに増加して安定することが示されました。この結果は、取引単位という制度設計が市場間の裁定取引の量に影響を与えることを示唆するもの。 (03) 人工市場を用いた決済期間が異なる市場間での裁定取引が各市場に与える影響の分析 著者：福家 緋莉（工学院大学）、水田 孝信（スパークス・アセット・マネジメント）、八木 勲（工学院大学） 目的／背景 T+N（遅延決済）と即時決済が併存する環境では、両市場間の裁定には株式借入が必要となるパターンがあり、貸株コストや供給制約があると裁定が働きにくい。 そこで、人工市場で外生要因を排し、借株コストが価格水準・流動性・裁定取引回数に与える影響を定量評価する。 アプローチ - 即時決済市場とT+N市場の2市場を仮定し、各市場にエージェントでの売買を発生させて、連続ダブルオークションでシミュレーション環境を構築。 - 各市場に一般投資家エージェントをそれぞれ1000体配置し、市場横断の裁定エージェントを配置してシミュ - 裁定パターン（6種）： - i. 即時決済市場で買い、T+N市場で売りが発生。 - ii. T+N市場で買い、即時決済市場で売り（借株コストC: 価格×係数α）。 - iii/iv T+N側に指値で買いと売りを発生。 - v/vi 即時決済側に指値で買いと売りを発生。 - 実験設定 - コスト係数 α ∈ {0, 1e-4, 1e-3, 1e-2, 0.1} - 各条件30試行。 - 評価指標は各市場の平均的な最良気配/価格乖離/板の厚み（Depth：最良気配±100ティックの累計）/裁定発注回数（パターン別）。 価格水準の固定化：αが大きいほど、T+Nは割安・即時決済は割高に固定化。 例：平均最良売り— T+Nの SF はα上昇で低下（10,005.26→9,998.19）、即時市場の SL は上昇（10,005.26→10,012.97）。価格乖離は |SF−SL|, |BF−BL| ≈ 0.05→14.7 付近まで拡大、α≥0.01 で頭打ち。 板構造の非対称化： T+N市場：SellDepth > BuyDepth へ（売り厚↔下押し＝割安化）。 即時市場：SellDepth < BuyDepth（買い厚↔上押し＝割高化）。 裁定機会の蒸発：α上昇で全パターンの発注回数が減少。特にコスト付き（(ii),(v),(vi)）は α≥0.01 でほぼ消滅。結果、価格乖離を修正するはずのフローが細り、価格偏りが固定化。 所感／示唆 - 「速さ」の陰のコスト：即時決済を極端に推し進めると、借株依存の裁定が詰まりやすく、価格水準のバイアスが残存・固定化する。制度設計では、決済短縮と貸株市場の厚みをセットで議論すべき。 - 実務アルゴへの示唆：コストを内生化した条件式（式(3)(5)(7)）での発注可否判定は必須。α感応度が高いパターン（特に(ii),(v),(vi)）は在庫・貸株の確保やヘアカット前提でロジックを分岐させるのが良い。 - ポリシー面：T+1 移行や即時化の議論では、「裁定の自己修復力」を損なわないために、貸株供給や清算インフラ（在庫移動・担保受渡）の整備が鍵。 (04) 人工市場を用いたサーキットブレーカーの性能調査 著者：早瀬 竜希（工学院大学大学院）、水田 孝信（スパークス・アセット・マネジメント）、八木 勲（工学院大学） 目的／背景 サーキットブレーカー（CB）の「参照期間（過去価格を参照する窓）」Tr1 と「停止期間（取引停止の長さ）」Tr2 を切り分け、誤発注ショック下での価格下落抑制と回復スピードへの影響を人工市場で定量評価する。 アプローチ - シミュレーションに使う環境は、ザラバ方式の連続ダブルオークションを利用。 - ノーマルエージェント n=1000 が、ファンダメンタル／テクニカル／ノイズの3戦略を重み付きで発注。 - ティックサイズ δP=1、ファンダメンタル価格 Pf=10000と設定。 - 誤発注ショック：期間 tms=30000〜tme=60000、確率 pm=15% で成行売りに置換。 - CBルール：過去 Tr1 の価格から Pr=100 以上の下落（または上昇）で発動し、Tr2 の間は新規注文・キャンセル停止。 - パラメータ走査：Tr1∈{1000,2000,5000,10000}、Tr2∈{2000,5000,10000,20000} などの組合せで20試行平均。 - 評価指標は「最大下落幅」と「Pf への回復時刻」。 実験＆結果 - 下落抑制：Tr1・Tr2 を大きくするほど最大下落幅は縮小した。（例：小さめ設定の Tr1=1000, Tr2=2000 で約955、対して大きめ設定の Tr1=20000, Tr2=10000 で約203）。 - 回復スピード：一般に Tr1・Tr2 を大きくすると Pf への回復は遅延（例：Tr1=1000, Tr2=2000 で約86,410時刻後、Tr1=20000, Tr2=2000 で約117,122時刻後に復活）。 - 参照期間Tr1を拡大するだけでも、下落は抑制された。ただし Tr1 がある閾値を超えると、初回発動タイミングはほぼ同じになり、効果は頭打ち。 - Tr1>>Tr2 だと連続発動が発生する。(停止期間終了後の判定が「下落前の高い価格」を参照し続けるため、実質的な停止が長引く)。 - 組合せ最適化の兆し：Tr1=5000 の列では Tr2=2000→5000 にすると、下落抑制と停止回数の減少が両立し、Pf への回復時刻が短縮するケースが観察された。 所感／示唆 - 設計トレードオフ：Tr1/Tr2 を大きくすれば下落は抑えられるが、回復は遅くなる。 - 初動抑制と回復スピードのバランス設計が要点。 - 実務の指針： - 短すぎる Tr2 は反動・連続発動を招きやすい一方、長すぎる Tr2 は回復遅延を招く。 - ショック終了見込みや清算工程を踏まえ、イベント窓に整合する中庸の Tr2 を探索する必要がある。 - Tr1 は「発動感度」を決めるダイヤルの役割を果たしている。そのため、市場のノイズ水準や誤発注頻度に合わせて、発動感度の頭打ち領域を超えない範囲で調整するのが重要。 - 監視・運用面では、Tr1>>Tr2 の連続発動リスクを常時モニタし、非常時は一時的にパラメータを切替えられる運用ルールが有効。 投資戦略(4件) (05) 米国経済指標の集団的変動と産業セクター間の関係性の分析 著者：北浦 崇弘（旭化成）、稲垣 祐一郎（旭化成ホームズ）、松浦 大将（みずほリサーチ&テクノロジーズ）、越山 祐資（みずほリサーチ&テクノロジーズ）、西野 洋平（みずほリサーチ&テクノロジーズ）、家富 洋（立正大学） 目的／背景 米国の主要な産業セクターレベルの経済指標とマクロ経済指標を対象に、複素ヒルベルト主成分分析（CHPCA）と多因子分析（MFA）を組み合わせた新しい分析フレームワークを提示。目的は、経済指標群が示す集団的な変動と景気循環の関係を明らかにすること、そして産業セクター間や指標間の先行・遅行関係を定量的に把握することである。 アプローチ - 複素ヒルベルト主成分分析（CHPCA）とMultiple Factor Analysis（MFA）を統合し、集団モードと位相を同時に推定。 - データ：FRED等から82指標（NAICS上位10セクター＋マクロ指標）、期間1993/02〜2024/12。 - 有意モード判定にRRS（Rotational Random Shuffling）を採用。 - 安定性：特徴量のランダム削除、15年ウィンドウのスライディングで検証。 実験＆結果 - 有意モードは3つ。寄与率は第一0.31、第二0.07、第三0.06。第一モードは景気後退期と整合し、累積強度はGDP下落率と近い関係。 - 安定性が高く、第一モードは特徴量9割削除でもcos類似度の中央値>0.9。 - 位相関係：労働時間（AWH）が雇用者数（AE）に先行／在庫売上比（ISR）→売上（SA）→在庫（TI）の順。 - セクター：小売（RT）が先行し、総合（TOT）が続く傾向。 - イベント別：ドットコムは集団運動が限定的、リーマンとCOVID-19は広範な波及。リーマンは後半で集団性が顕在化。 所感／示唆 - 第一モードは「景気の集団運動」の実用的proxy。景気後退の規模感比較や産業別波及の把握に有効。 - 実務では、雇用・在庫関連の合理的順序（AWH→AE／ISR→SA→TI）を前提に、サプライチェーンの先行把握と在庫調整のタイミング設計に活用可能。 - 分析は長期データとセクター網羅性に依拠するため、他国・最新系列への継続適用で頑健性をモニタリングしたい。 (06) 多資産ネットワーク分析が示す暗号資産の独立性とポートフォリオ分散効果 著者：水門 善之（慶應義塾大学） 目的／背景 暗号資産（ビットコイン）が伝統的資産（株・債券・コモディティ・為替）と比べてどの程度独立しているかをネットワークで可視化し、分散投資の有効性（Sharpe／Sortino）を検証する。 アプローチ - 週次リターンの相関行列からネットワークを構築（相関0.2〜0.3で閾値化）。 - 中心性（Degree／Eigenvector／Betweenness／Closeness）で構造把握。 - 主要株価指数・コモディティ先物・主要通貨・暗号資産を対象。 - モンテカルロで9資産（主要ETF群＋BTC）の無空売りポートフォリオを1万通り生成し、Sharpe／Sortino最大点を探索（2020/01〜2025/04）。 実験＆結果 - ネットワークではBTCが周縁に位置し、中心性が総じて低い＝独立性が高い。相関閾値0.3ではBTCは他資産から切断されるケースも。 - 銅（Copper）は異市場を含めても中心性が一貫して高い（景気指標性）。 - Sharpe ratio：Sharpeが0.086→0.160に改善、BTCウエイト約0.29。 - Sortino ratio：0.19→0.32に改善、BTCウエイト約0.13（下方リスク配慮で比率は抑制）。 所感／示唆 - BTCは「低相関な衛星資産」として、総合リスク当たり収益を押し上げ得る。ただし下方リスク耐性を重視する運用では配分抑制が妥当。 - マクロ連動性が相対的に薄い局面で寄与が期待できる一方、制度・流動性イベントへの感応度が高いため、ガバナンス・流動性管理とセットで配分設計したい。 - コモディティでは銅の中心性が高く、景況変化の早期把握に有用なモニタ対象となる。 (07) 長期相関を持つ成行注文流と価格インパクトのミクロモデル化に基づく株価の予測困難性の説明 著者：佐藤 優輝、金澤 輝代士（京都大学） 目的／背景 成行注文流は長期記憶性により予測可能だが、価格は予測困難というパラドックスを、ミクロモデルで説明する。 アプローチ - Lillo–Mike–Farmer（LMF）型の注文分割行動モデルと、価格インパクトの平方根則 I(Q)=c√Q を結合した理論モデルを構築。 - 注文符号の自己相関 C(τ)∝τ^{-γ}(0<γ<1) を前提に、価格ダイナミクスの厳密解を解析。 実験＆結果 - トレーダが分割執行を継続することで注文流は長期記憶を示し、平均的なインパクトは√Qに比例。 - その一方で、価格系列は拡散的（ランダムウォーク状）になりやすく、注文流の予測可能性と価格の予測不可能性が同居する条件を理論的に提示。 - モデルは市場横断で観測される経験則（長期記憶の符号系列、普遍的な平方根インパクト）と整合。 所感／示唆 - 注文流シグナルの活用は、インパクト・流動性制約を踏まえた実装でなければ超過収益に直結しにくい。 - 最良執行や最適発注（POV／TWAP等）の設計では、平方根インパクトと分割行動が生む自己相関を同時に考慮すべき。 - マーケットメイク／リスク管理では、長期記憶を前提にヘッジ頻度・在庫上限の調整が有効。 (08) 戦略多様性と平方根則を取り入れた一般化LMFモデル 著者：藤原 俊太（京都大学）、佐藤 優輝（京都大学）、金澤 輝代士（京都大学） 目的／背景 価格インパクトの平方根則 は普遍的とされる一方、比例係数 c の解釈・無次元化の妥当性が十分に整理されていない。 本研究は、近年の理論モデルを基に c の定義付けと統計解析手法の妥当性を検証し、取引コスト指標としての c の位置づけを明確化する。 アプローチ - 価格インパクトの定義を再確認し、出来高 VD・ボラティリティ σD による無次元化を前提に理論整備。 - 近年提案モデルを採用し、日次出来高・日次ボラの解析計算および数値計算を併用して c と無次元化の関係を導出。 - 既往研究（各市場で δ≈0.5 の検証）との差分整理：指数 δ と係数 c の役割分担を明確化。 - 実務上の取引コスト（流動性・板厚・スプレッド等）との対応づけを検討。 実験＆結果 - べき指数 δ は既報通り 0.5 付近で安定。一方で c は市場横断に一定ではなく、無次元化の前提に依存して変動。 - モデルから、c は「価格応答の強さ＝実効的な取引コストに比例」する関係が定量化され、銘柄・日付を跨いだ比較可能性の条件（VD・σD によるスケーリングの前提）を提示。 - 統計手法の検証：従来の無次元化に理論的根拠を与えつつ、過度な一律適用には注意が必要という結論。 所感／示唆 - 係数 c は「市場インパクトのコスト・メーター」とみなせる。運用実装では c の時系列推定（流動性レジーム検知）を組み込むと良い。 - 監視指標としては δ よりも c のドリフト／レジーム転換が重要。板厚・ボラ・回転率と併せた多次元モニタリングが有効。 - 企業横断や市場横断の比較では、無次元化の条件充足（VD・σD の安定性）を確認してから指標化すべき。 テキストマイニング(5件) (09) 金融テキストごとの特徴分析とポートフォリオ評価 著者：高野 海斗（野村アセットマネジメント） 目的／背景 ファンドマネージャーが投資判断に用いる決算短信やアナリストレポートなどの金融テキスト情報について、その定性的な情報を定量的な数値に変換し、資産運用戦略への活用可能性を探ることを目的とする。特に、従来のセンチメント分析が抱える課題（センチメント定義の曖昧さ、分類タスクによる限界など）を踏まえ、「将来の見通し」に焦点を当てた独自のセンチメント分析モデルを構築し、テキストの種類による特徴の違いを明らかした。 アプローチ - 対象テキスト：バイサイド／セルサイドのアナリストレポート、ニュース、四季報（業績記事コメント・材料記事コメント）。 - センチメント推定：辞書法と BERT ベース（回帰タスク、-2〜+2 の連続値）。同日複数文は平均化し、過去90日・半減期20日で時間加重。 - 検証： - イベントスタディ：テキスト公開日を起点に ±60 営業日で累積リターンとの相関。 - 分位ポートフォリオ：月末に5分位（Strong Neg.〜Strong Pos.）、等ウェイト／時価総額ウェイトで評価（AR/TE/IR/MaxDD/TR）。 実験＆結果 - カバレッジ：四季報は銘柄数ベースほぼ常時100%、セルサイドは時価総額ベースで高水準。 - 事前の値動きとの整合：t 時点のセンチメントと t−60 営業日のリターンに正相関（事前の上昇＝ポジ、下落＝ネガが多い）。 - 公開後 60 営業日の相関は総じて小さい。 - アナリスト系は公開直後の短期で差が出やすい。 - ニュースは当日に反応するが持続は弱い。 - 四季報の公開後10営業日超で、ネガティブ分位が相対的に切り返す「リバーサル」傾向が見られた。 - ポートフォリオ： - アナリスト（Strong Pos.）で良好な ARが観測された。 - ニュースは Neutral を除き概ねプラスに寄与している。 - 四季報はネガ側の AR がプラス、売買回転率は低水準となっていた。 所感／示唆 将来の見通しに着目したセンチメント分析モデルを用いることで、金融テキストの種類ごとに異なる特性を明確化し、資産運用への実用的な示唆を与えました。特に、一般的に避けられがちな四季報のネガティブコメントが、逆張りの投資戦略において有効なシグナルとなり得る可能性を示した点は、大きな発見。今後は、本研究で得られたセンチメントスコアと財務指標などを組み合わせた、より高度な投資戦略の検討が期待される。 (10) 有価証券報告書テキストを用いた配当政策データの構築と分析 著者：竹下 蒼空（成蹊大学）、高野 海斗（野村アセットマネジメント）、仁科 慧（成蹊大学）、酒井 浩之（成蹊大学） 目的／背景 企業の配当政策に関する方針が主に有価証券報告書などのテキスト情報として記述されている点に着目し、これを自然言語処理技術（BERTやLLM）を用いて体系的にデータ化することを目的とする。手作業での分析や単純なキーワード検索では困難だった、大規模かつ高品質な配当政策データの構築手法を提案し、そのデータを用いて、企業の配当政策が投資パフォーマンスにどのような影響を与えるかを分析・検証した。 アプローチ - 文抽出：BERTopic＋ModernBERT を組み合わせ、配当政策に有益な文を段階的に抽出する。 - マルチタグ付与：LLM few-shot で「増配（INC1〜9）」「減配（RED1〜6）」を文単位に多重ラベル化。(structured outputs で一貫性確保)。 - 評価：各タグで人手適合率を測定。 - 投資検証：2017/04〜2025/03、TOPIX500 対象。 - 増配系（increase）、非減配系（no reduction）、両方（progressive）のポートフォリオを月次で構築（等ウェイト／時価総額ウェイト）。 実験＆結果 - タグ頻度：近年は増配志向が強まり、とくに「増配の意図（INC7）」と「累進配当採用（INC3）」が増加。 - コロナ期に一時的な減配言及（RED5/RED6）が増。 - 文分類性能：一部の時点判定タグ（当期導入・当期減配）は文単体では難しく適合率が低下するが、他は概ね良好な結果であった。 - パフォーマンス（例）： - 等ウェイト：progressive の AR≈+4.1%、increase の AR≈+3.5%。 - 時価総額ウェイト：progressive の AR≈+3.3%。回転率は年1回の開示反映が中心で比較的低位。 - 特性：DY/DOE の中央値は True/False 間でたびたび交差し、単純な高配当指標では代替困難＝テキスト固有情報を含む。 所感／示唆 - 開示テキストは「将来の配当方針」を直接反映するため、数値財務だけでは拾いにくいシグナルを提供。 - 実装の肝は「抽出→多ラベル化→保守的集計（月次）」の一貫パイプライン化。タグの時点解釈は企業内時系列（例年文）を併置して精度向上を図りたい。 - 運用面では、progressive/increase/no reduction を補助シグナルとしてバリュー・クオリティ因子と組み合わせると頑健化が見込める。 (11) LLMsによる利益予測の分析とアウトオブサンプル評価 著者：白井 祐典（Insight Edge, Inc.）、市川 佳彦（Insight Edge, Inc.）、中川 慧（大阪公立大学） 目的／背景 EDINET-BENCH を用いて、日本上場企業の「次期純利益の増減方向」予測における LLM の特性を検証。どの企業・業種で精度が出やすいか、また学習後に出現した未知データに対して汎化（アウトオブサンプル：OOS）できるかを評価する。 アプローチ - 予測方法：EDINET-BENCHを流用。 - モデル：Claude 3.7 Sonnet／カットオフ 2024-10-31を利用。 - インサンプルデータ：EDINET-BENCH の利益増減ラベル（テストは 2021–2024 年が中心）。 - OOSデータ：2025-06-01〜2025-08-31 に EDINET 提出の有報（学習後公開）を対象。 - 指標：ROC-AUC を「売上規模四分位」「東証17業種」別に算出し、インサンプル（IS）と OOS を比較。 - 事前検証：カットオフ後の自然現象を問うプロンプトで「後知識混入」兆候の有無をチェック。 実験＆結果 - IS 全体 ROC-AUC：0.6075。売上下位 25%で低め（例：0.5330）など規模依存が示唆。業種間ばらつき大。 - OOS 全体 ROC-AUC：0.6327とインサンプルに対して減少せず。 - 業種差：銀行は OOS で大幅改善（+0.2899）、一方で「金融（銀行除く）」「鉄鋼・非鉄」などは低下。 所感／示唆 - LLM の利益予測は OOS でも一定の汎化を確認。ただし業種・規模で異質性が大きく、追加特徴の導入（業種特化のテキスト・数量情報）が鍵。 - 実務利用は「銘柄横断の一律モデル」より、業種別や規模別のハイブリッド設計（テキスト＋数値＋事前分布）でのチューニングが有効なのではないかとの示唆。 - 正真正銘の OOS を厳密化するため、評価ウィンドウとカットオフ設計（予測対象の1年前基準など）の標準化が望ましい。 (12) 適時開示テキスト埋め込みを用いたイベントスタディにおける累積異常リターンの予測 著者：伊藤 央峻（日興リサーチセンター） 目的／背景 企業の適時開示情報（TDnet）の「タイトル」から生成した高次元のテキスト埋め込み（テキストの数値ベクトル表現）が、開示直後の短期的な株価下落リスクを予測する上で有効な情報となるかを検証することを目的とする。従来のセンチメント分析など、テキスト情報を少数の指標に集約する手法では失われがちな微妙なニュアンスを、高次元の埋め込みを直接利用することで捉え、予測精度が向上するかを評価した。 アプローチ - データ：2020/04〜2025/04 の開示約69万件（タイトル・公開項目コード）を利用。 - 特徴量：日本語特化埋め込み ruri-v3-310m（768次元）、価格系ベース特徴、業種ダミー、公開項目コード。 - モデル・検証：LightGBM／Purged K-fold（K=5）、PR-AUC 最適化。クラス不均衡はアンダーサンプリングで調整。目的変数を「CAR(0,3)が分布の下位5%に入るか（＝短期的な下落リスクの発生）」とする二値分類問題と設定。 - 可視化：PCA＋クラスタリングで埋め込み空間の整合性と季節性を確認。SHAP で特徴寄与を解釈。 実験＆結果 - 性能：Base（価格＋業種）の F1=0.235・PR-AUC=0.164 → 埋め込み追加で F1=0.265・PR-AUC=0.192 に改善。 - 単独比較：Emb 単独は Code 単独より全指標で優位。Base+Emb と Base+Emb+Code は同水準＝埋め込みがコード情報を内包。 - 構造：PCA 可視化で決算／ガバナンス／PR 等の意味的分離と季節パターンを確認。SHAP では直近リターンと埋め込み成分が上位に並ぶ。 所感／示唆 - タイトル埋め込みは「短期下落リスクの早期検知」に有効。 - 公開項目コードの事前カテゴリを超える情報を保持。 - 運用では、価格モメンタム／リバーサル系の簡便特徴に埋め込みを重ねる構成が費用対効果良。 - 次の改善は、本文・添付資料の統合、分位回帰など連続予測化、埋め込み次元の安定化の検討。 (13) 大規模言語モデルを用いたアンサンブル手法による J-REIT物件情報データセットの効率的な構築方法 著者：田中 麻由梨（日本取引所グループ）、土井 惟成（日本取引所グループ） 目的／背景 J-REIT 有報の物件情報は表・テキストが混在し自動構造化が難しい。報告書に記載される物件情報は、フォーマットが統一されておらず、テキストと表が混在しているため、自動でのデータ化が困難。 複数 LLM の Few-shot 出力をアンサンブルし、高精度な JSON 変換と人的修正の最小化を目指す。 アプローチ - 対象：J-REIT の「保有資産」等の HTML 断片（表＋注記テキスト）。 - 前処理：style系の削除で構造を保持しつつトークン削減。Few-shot で JSON 仕様と注記取扱いを明示。 - モデル：ChatGPT-4o／Gemini 2.5 Pro／Claude 3.7 Sonnet、temperture=0で実施。 - アンサンブル方法：複数モデルの予測結果の3/3一致なら「採用」、2/3一致なら「多数決」、不一致なら単体精度最大モデルを採用。 - 改変検知：キー>20文字や値の過長などをルールで警告し、修正箇所を特定。 実験＆結果 - Few-shot 効果：Zero→One→Two-shot で Accuracy が 32.7%→96.9%→98.37% に向上。 - LLM 単体（Two-shot）：Accuracy は 98.37〜99.03%。 - 一致度別：3/3一致は 99.991%、2/3一致は 98.350%、全不一致は各モデル 86〜89%。 - 最終アンサンブル：全体 Accuracy 99.222%。不一致は約5%のみで人的確認対象を大幅に圧縮。 所感／示唆 - 「3/3または2/3一致は自動確定、0/3のみ人手確認」の運用が現実解。注記の表記揺れは正規化ルールで吸収可能。 - データセット拡張時も Few-shot 事例の管理とルール検知をセットにすれば、精度と省力化を両立できる。 - 表＋注釈の混在ドキュメントにおける汎用的な構造化パターンとして他ドメインへの横展開が期待できる。 - 作成されたデータセットは、GitHubで公開される予定。 データマイニング(4件) (14) トランザクションレンディングにおける法人のデフォルト分析 著者：小林 司（東京大学）、山本 竜也（GMOあおぞらネット銀行）、成末 義哲（東京大学）、森川 博之（東京大学） 目的／背景 従来の財務諸表に基づく融資とは異なり、口座の取引履歴を基に審査を行う「トランザクションレンディング」における法人のデフォルト（債務不履行）要因を分析した。インターネット専業銀行の実際の融資データを用いて、法人の属性や取引情報がデフォルト率にどう影響するかを検証している。 アプローチ - 対象データ：インターネット専業銀行の契約18,199件（契約後1年のデフォルトを評価）。 - 属性軸：設立年数（3年未満／以上）、代表者の事業経験（初回／法人設立経験／個人事業主経験）、業種。 - 取引軸：入金先の集中度（顧客依存の強さ）をハーフィンダール・ハーシュマン指数(HHI)で定義。 - 比較：各セグメントのデフォルト率（LOW／MEDIUM／HIGH）と統計的有意性を検証。 実験＆結果 - 設立3年未満の法人は、3年以上よりデフォルト率が有意に低い。 - 代表者が個人事業主経験・法人設立経験を持つ場合は相対的に低水準。 - 業種：デザイン／教育など“ソフト面”依存の業種で低水準、食品・飲料や小売・製造で高水準の傾向。 - 顧客集中：HHIが高いほどデフォルト率上昇。年数に依存せず一貫。 所感／示唆 - 「若い×経験あり」プロファイルを過度に抑制せず、顧客集中の分散度を厳格モニタする設計が有効。 - スコアリングは属性（年数・経験）×取引集中（HHI）の二軸で早期に差別化。与信額より行動指標に着目。 - 業種の“ソフト依存度”を補助変数化し、審査・モニタリングの優先順位に反映したい。 (15) Fiedlerベクトルと情報エントロピーを用いた株式ネットワークの構造変化検知 著者：星野 知也（株式会社三井住友銀行） 目的／背景 相関に基づく株式ネットワークの“構造変化点”を頑健に捉え、レジーム転換の早期兆候を検出。Minimum Spanning Tree(最小全域木)の、ショック時の不自然連結の限界を補う枠組みを提示。 アプローチ - 提案：階層的Fiedler疎性化（Hierarchical Fiedler Sparsification;HFS）で疎グラフ構築（Fiedlerベクトル×二分割×交差エッジ選択）。 - 指標：Fiedlerエントロピー[均質性]とワッサースタイン距離[構造差異]で変化点検知。 - データ：米国S&P500の49業種（日次、直近12週ロール、週次更新）。MST・Absorption Ratioと比較。 実験＆結果 - 構造表現：コロナ期（2020/3）はHFSで業種クラスタが明瞭、MSTは直感に反する隣接が散見。 - 変化点：2020/2上旬（下落前）、3月後半（底形成期）、11月（選挙・ワクチン報）で検知が整合。 - 収益との関係：エントロピー↑の週は平均超のリターン、距離↑の週は低下傾向。上昇/下落トレンド別でも意味ある差分。 所感／示唆 - リスク上昇の前兆は「エントロピー低下＋距離上昇」の組み合わせで早期拾い。監視ダッシュボードに組込みやすい。 - 相関ノイズに強く、業種構造の解釈性が高い。日本市場や個別銘柄粒度にも横展開が期待できる。 - 運用ではMST等との併用で“ショック依存の誤配線”を回避し、レジーム検知の信頼度を底上げ可能。 (16) 暗黙の政府保証を加味した国内地方債スプレッドの評価 著者：石原 龍太（みずほ第一フィナンシャルテクノロジー） 目的／背景 一般的に、日本の地方債は地方財政制度を通じた政府の支援により、信用リスクは低いと認識される。しかし、この政府保証は法的な根拠を持つものではなく、その信頼度（市場の信認度）を観測することは困難。過去には、国の補助金削減などを背景に地方財政への懸念が高まり、スプレッドが拡大した事例もあった。本論文では、国内地方債の発行スプレッドに内在する「暗黙の政府保証」の強さを定量推計し、説明力の向上と市場整合性を検証した。投資家・引受側・政策当局の判断材料を提供。 アプローチ - モデル：スプレッド＝α＋β₁×{実質公債費比率×(1−政府保証信頼度)}＋β₂×{国債マイナス金利幅}。 - 推計：遺伝的アルゴリズムで「政府保証信頼度（月次）」を同月の都債との差分二乗誤差と平滑化で最適化。 - データ：2006/4–2024/3の市場公募地方債（10年）、都道府県の実質公債費比率、国債利回り。 実験＆結果 - 信頼度の時系列：2006–2008年に低下局面（制度改革・スプレッド拡大と整合）、以降は高水準で安定。 - 当てはまり：政府保証信頼度を入れると決定係数R²が0.169→0.308に改善。 - 係数解釈：保証が消滅した極端仮定では、実質公債費比率20%の団体でスプレッドがおおよそ+20bp拡大。 所感／示唆 - 地方債の“準安全資産”性は制度と市場信認の産物。信認低下シナリオのストレス計測に有用。 - 実務では、保証信頼度のモニタ（時系列）×団体別ファンダ（実質公債費比率）で相対価値評価を高度化。 - 将来の制度変化や人口動態ショックに対し、信頼度推計を早期警戒指標として活用できる。 (17) 本邦中古スマートフォン市場における価格形成に対する機種ブランドと為替レートの影響 著者：市川 佳彦（Insight Edge, Inc.）、平野 友貴（住友商事）、居村 裕平（住友商事）、中條 悠介（住友商事）、桑本 奈緒（住友商事）、堤 鴻志郎（住友商事）、中川 慧（大阪公立大学） 目的／背景 中古スマホ市場の価格形成メカニズムを、実勢に近い「買取価格」を用いて定量検証。ブランド差や米ドル/円の為替変動が残価率にどう効くかを明らかにする。 アプローチ 2018–2024年の機種・容量別の月次買取価格（RMJ）から残価率（RVr）を定義し、①経過月数とRVrの関係（線形回帰/可視化）、②為替変動のラグ効果（1–6か月ウィンドウ×1–4か月ラグの相関）、③iPhoneを対象にXGBoost＋SHAPで特徴量重要度を評価。 実験＆結果 - 価格を最も規定するのは「発売からの経過月数」。Appleは他社に比べ減価が緩やか。 - 為替は短期の同時点では効きにくいが、iPhoneでは「過去1–2か月の為替変化が約3か月後のRVr変化と弱い正相関」。 - XGBoostの予測精度は高水準（R²≈0.898、MSE≈0.0020）。SHAPでは「経過月数」が圧倒的に重要。容量は非線形で、64GBはマイナス寄与、128/256GBは中立、512GB/1TBは相対的に不利。 所感／示唆 経過月数とブランド差（特にApple優位）を前提に、在庫評価や買取価格のガイド可。為替は即時反映ではなく遅行気味のため、為替ショック観測後の数か月先を見た在庫ポジション調整が有効。容量ミックスは「中容量を主軸」に設計するのが合理的。 機械学習(5件) (18) 事前エクスポージャー情報を活用した部分空間正則化付き主成分分析 著者：中川 慧（大阪公立大学・MONO Investment）、加藤 真大（みずほ第一フィナンシャルテクノロジー・大阪公立大学）、今村 光良（筑波大学） 目的／背景 資産運用で広く用いられる主成分分析（PCA）の安定性を向上させる新しい手法「部分空間正則化付き主成分分析」を提案。 株式や債券など複数の資産（マルチアセット）の価格変動を説明するために、マクロ経済指標と関連付けられるリスクファクター（マクロファクター）が利用される。このファクターを抽出する代表的な統計手法が主成分分析（PCA）となる。しかし、過去の一定期間のデータを用いて分析を逐次的に繰り返す「ローリングPCA」では、推定される主成分（ファクターへの各資産の感応度を示すエクスポージャー）が時間とともに大きく変動してしまう問題がある。この不安定性は、ファクターの経済的な解釈を一貫して行うことを困難にし、分析の信頼性を損う。 この課題を解決するため、本研究では「部分空間正則化付き主成分分析」を提案。この手法は、標準的なPCAの最適化問題に、利用者が経済的知見に基づいて事前に設定した「望ましいエクスポージャー構造（事前エクスポージャー情報）」を正則化項として加えるものである。 アプローチ ユーザが与える「事前エクスポージャー（US）」の張る部分空間への射影を正則化項として導入し、標本共分散との凸結合S_LS＝λ(USUSᵀ)+(1−λ)Sに対するPCAとして解く。実証では6資産（月次、1997–2025）でk=3因子、Procrustes距離で安定性を評価し、リスク分解で説明力を確認。 実験＆結果 - λを上げるほど主成分空間の時系列安定性が大幅改善（平均Procrustes距離：λ=0で2.46 → λ=0.9で0.12）。 - 説明力（Adj.R²やリスク分解の寄与）はおおむね維持され、安定性と説明力の両立を確認。 - 事前因子は「成長/リスクオン・実質金利・インフレ」に対応する構造で解釈可能。 所感／示唆 - 「解釈可能な因子構造を維持したまま」戦術配分やリスク管理に使える因子を安定抽出できる。 - 運用現場ではλをハイパラとして運用目的に合わせて調整し、安定性重視のモニタリングやアロケーション説明に有効。 (19) 財務諸表監査のための逐次検定：試査手続の統計学的な定式化と理論保証 著者：加藤 真大（大阪公立大学・みずほ第一フィナンシャルテクノロジー）、中川 慧（大阪公立大学） 目的／背景 財務諸表監査における「試査」と呼ばれるサンプリング調査の慣行に、統計学的な理論保証を与えるための新しい手法を提案している。現代の財務諸表監査では、膨大な量の勘定科目を全て調査する「精査」は非現実的であるため、一部を抜き出して調査する「試査」が行われている。実務では、一度のサンプリングで判断できない場合、判断がつくまで追加でサンプリングを続ける慣行があるが、これは経験則に頼っており、誤った判断を下す確率（誤判断確率）が数学的に保証されていなかった。 本研究では、統計的保証のある逐次検定として整備し、誤判断確率（第一種・第二種）を管理可能にする。 アプローチ 有限母集団からの非復元抽出（超幾何分布）を前提に、停止・決定ルールを閾値列（上限κᵣ(t)、下限κᵣ_(t)）で定義。最悪母逸脱率（r±θ）でモンテカルロにより閾値を逐次的に設計し、所望のα・βを満たすよう誤判断確率を制御。拡張として片側検定、検出力制約つき片側、二段階検定、打ち切り付き逐次検定を提示。 実験＆結果 - 無関心領域外で誤判断確率が目標（例：α=β=0.05）以内に制御されること、想定レンジで期待停止時刻が算定可能であることを数値実験で確認。 - 現場フローに合わせた設計（初回サンプル後の追加試査や打ち切り）にも対応可能。 所感／示唆 「どこで止めるか／どちらと判定するか」を事前に設計できるため、監査品質の説明責任を強化。許容逸脱率や無関心領域、α・βを文書化しておくと、監査計画・レビュー時の合意形成がスムーズになる。 (20) 学習期間が異なる株価予測機械学習モデルのアンサンブル学習による投資戦略の構築 著者：西村 征馬（三井住友トラスト・アセットマネジメント） 目的／背景 機械学習による株式リターン予測では「学習期間（履歴の長さ）」が結果に大きく影響するが、最適期間は一意に決めにくい。 本研究は、学習期間だけが異なる複数モデルをアンサンブルし、期間選択を機械化して予測力と運用成績を高めることを目指す。 アプローチ - ベースモデル：LightGBM（回帰、損失はMSE）。学習期間を36〜120か月まで12か月刻みで8本作成。 - 検証設計：将来/同時点情報漏洩を避ける時系列交差検証でvalidationを統一化。 - アンサンブル： - スタッキング（線形回帰／Elastic Net） - ブレンディング（逐次二次計画法[SLSQP]で非負・和=1の重み最適化でのブレンド） - バックテスト：TOPIX採用のうち時価総額上位60%、2015/07–2025/06。予測に基づく分位（5分位・10分位）およびロングショートを評価。 実験＆結果 - 損失：Validation最小化で得た重みはTest lossも概ね改善。OLSスタッキングは過学習傾向、Elastic Netとブレンディングが安定。 - 収益性：アンサンブル由来のポートフォリオが単体モデルより一貫して高い超過リターン（5分位・10分位、ロングのみ/ロングショートの別を問わず）。 - ロバスト性：学習期間差に依存せず、重み学習により未知データでの標準偏差（test_std）も抑制。 所感／示唆 - 学習窓の最適化は“選ぶ”より“混ぜる”が実務的。Elastic Net系や非負和=1ブレンドは過学習を抑えつつ汎化に寄与。 - 年次リバランス等の軽量更新でも効果が出る設計で、既存のファクターモデルに期間多様性アンサンブルを上乗せする価値が高い。 (21) マルチモーダルデータを用いた機械学習モデルによる企業の業績修正予測 著者：田代 雄介（MTEC）、鈴木 彰人（MTEC）、山口 流星（MTEC）、宮澤 朋也（データアナリティクスラボ）、亀田 希夕（データアナリティクスラボ） 目的／背景 企業の財務報告書（決算短信）のテキストデータと、株価の時系列データを組み合わせた「マルチモーダルな機械学習モデル」を構築し、将来の業績修正を予測するタスクに取り組んだもの。 長文テキストと時系列情報を統合した機械学習フレームワークを構築し、企業の業績修正（上方修正、下方修正、修正なし）を予測するモデルの有効性を検証することを目的とする。 アプローチ - テキスト：ModernBERT（長文対応、最大4096トークンで学習）。 - 時系列：Transformerエンコーダ（過去250営業日の対TOPIX超過リターン）。 - 結合：単純結合／Gated Fusion／Cross Attention を比較。 - データ：東証プライムの2018年以降。クラス不均衡は1:1:1のアンダーサンプリング。Train=2018–2022、Test=2023–。指標：AUROC, F1。 実験＆結果 - ベースライン：テキスト単独 AUROC=0.656, F1=0.458；時系列単独 AUROC=0.555, F1=0.345。 - マルチモーダル：Cross Attentionが最良（AUROC=0.671, F1=0.493）、Gated Fusion/単純結合もテキスト単独を僅かに上回る。 - 長文効果：4096 vs 512トークンで大差なし（重要情報は先頭に集中する可能性）。 - 実務適合性：予測確率に基づく10分位分析で、最上位分位の上方修正率53.2%とシグナル妥当性を確認。 所感／示唆 - テキストが主、時系列は補助。ただし結合部の設計（Cross Attention等）で安定改善。 - 運用では、確率スコアの分位連動でアナウンス前のポジショニングや監視銘柄選定に転用可。モデルの軽量化・更新性と併せて実装のしやすさが高い。 (22) 生成AIを用いた決算説明サプライズの定量化手法の提案 著者：辻 晶弘（DaNeel Insight株式会社） 目的／背景 従来のサプライズ指標SUE（EPS実績−予想）だけでは説明会の質やIR文脈が捉えにくい。生成AIによるペア比較＋GlickoレーティングでEarnings Callの相対評価（rating）を構築し、価格反応（day1）とその後のドリフト（day2–5）への説明力を検証する。 アプローチ - ユニバース：日本上場企業（SCRIPT Asia等のコール要約／トランスクリプトを整備）。 - 指標：SUE_cs（コンセンサスEPS変化）、SUE_cb（会社ガイダンス変化）を定義。 - 生成AI：LLMでコール要旨をペア比較し、Glicko法で一体化スコア（rating）へ。 - 目的変数：TOPIX超過のday1（reaction）とday2–5（drift）。単回帰・重回帰でp値/R²・標準化係数を評価。 実験＆結果 - day1反応：SUE_csが最も強い（R²≈0.093、p<0.001）。SUE_cb, ratingも有意だが相対的に小。 - day2–5ドリフト：説明力はratingが優位で、日を追うごとにR²は逓減しつつも正の寄与を維持。数値サプライズのみでは説明しきれない質的情報の寄与を示唆。 - 相関・面回帰のクロスチェックでも、即時は数値、持続は質という役割分担が概ね一貫。 所感／示唆 - 決算説明会の質（言語情報）は短期の方向づけより継続リターンに効く。イベント後のフォローではratingの活用が有効。 - 実務実装は、SUE（数値）×rating（質）の二軸でイベント選別とエントリー/エグジットを設計。トランスクリプト整備と時点合わせが精度のカギ。 機械学習/テキストマイニング(4件) (23) 指値配分を連続確率分布化した深層学習によるマーケットメイキング 著者：久保 健治（東京大学・株式会社松尾研究所）、中川 慧（大阪公立大学・株式会社松尾研究所） 目的／背景 深層学習（DL）を用いた効率的なマーケットメイキング手法を提案するもの。特に、価格変動が大きい市場において複数の指値注文を管理する際の、行動空間の爆発的な増大という課題に対処している。 指値の数量配分を離散的なものではなく、連続確率分布を用いて緩和する点が研究の中心。具体的には、複数の正規分布を混合した混合正規分布を使い、指値数量の分布を表現した。これにより、ニューラルネットワークが出力すべきパラメータの数を大幅に削減し、高次元の行動空間の問題を回避して効率的な学習を可能にする。 アプローチ 指値数量の「配分」を連続確率分布（混合正規の切断・再正規化）で緩和し、行動空間を圧縮。StockMixerに時刻特徴量とポジションを拡張して方策ネットを構成し、CARA効用で学習。約定は高値/安値と分布の積分で近似し、離散化との誤差を検証。 データ／実験設定 米国上場の主要ETF5銘柄（GLD, IWM, QQQ, SPY, TLT）・5分足（2021–2024）。Nm=3の混合正規、ラグL=78、T=24、γ=1。学習は前半期間の7-fold、テストは後半期間でバックテスト。 結果 テストで年率リターン約5%、ASR≈1.62、MDD≈2.98%、CR≈1.52。連続緩和は収益をやや過大評価するが、離散実装との差は限定的。ポジションは各銘柄・合計ともに偏り小さくリスク管理が機能。 所感／示唆 複数価格・複数銘柄のマーケットメイクで「数量配分を連続化」する設計は、RL実装の安定化と可搬性（離散実装への落とし込み）を両立する実務的トレードオフ。 今後は緩和誤差の制約化とネットワーク設計の最適化（例：執行コスト・流動性制約の内生化）が有効。 (24) 3値ポートフォリオ最適化に対するQAOAミキサーの性能比較 著者：山村 真太郎（東京理科大学）、渡邉 聡（KDDI総合研究所）、國見 昌哉（東京理科大学）、斉藤 和広（KDDI総合研究所）、二国 徹郎（東京理科大学） 目的／背景 量子コンピューティングの一分野であるNoisy Intermediate-Scale Quantum（NISQ）デバイス向けの量子アルゴリズム、Quantum Approximate Optimization Algorithm（QAOA）を金融工学の重要課題であるポートフォリオ最適化問題に応用した研究。 現実の運用では「保有・非保有・空売り」の3状態が自然。3値（−1,0,1）のポートフォリオ最適化をQAOAで解き、ミキサー選択が性能に与える影響を比較する。 アプローチ 2量子ビット/資産で3値を符号化し、Standard/XY系（Ring, Parity Ring, Full, QAMPA）を比較。 p層の初期値設計・古典最適化（SLSQP/Nelder-Mead）を工夫し、ノイズ（depolarizing）環境でも評価。 データ／実験設定 DAX30からn=5/8のサブセット（主にn=5, B=2を提示）。 Statevector/Qasm/DensityMatrix Simulator、ショット数3,000/8,192、p=1,3,5,7。評価は平均近似率rと最適解確率P。 結果 無ノイズではXY Full/QAMPAが高水準（r>99%級、Pも高い）。 一方、ノイズ下ではパラメータの頑健性と探索容易性の差が顕在化し、層数pの増加は必ずしも有利に働かない。 初期値・古典最適化設定が品質に与える影響も大きい。 所感／示唆 3値最適化では、ノイズ環境を前提としたミキサー選定＋初期化戦略が鍵。 小規模問題でも層数の過剰増加は避け、頑健性重視のハイパラ設計で実運用への橋渡しが現実的。 (26) LLM-PEAD.txt：日本株式市場におけるLLMを用いたサプライズ抽出と決算後ドリフトの実証分析 著者：種村 賢飛 (東京大学/松尾研究所), 久保 健治 (東京大学/松尾研究所), 中川 慧 (大阪公立大学/松尾研究所) 目的／背景 近年の日本株式市場を対象に、企業の決算発表後に株価がサプライズの方向に継続して動く「決算後ドリフト（Post Earnings Announcement Drift;PEAD）」という現象を再検証したもの。特に、従来からの数値情報に基づくサプライズと、大規模言語モデル（LLM）を用いてテキスト情報から抽出したセンチメント（市場心理）を組み合わせることで、この現象がどのように変化するかを分析。 アプローチ - 決算資料から、数値に基づくサプライズ指数 SUE と、LLM によるテキストベースのサプライズ指数 LES を構築。 - PEAD の検出：決算発表後の超過リターンがサプライズ方向に継続するかを検定。 - LES は辞書極性ではなく LLM により文脈を評価し、“数値では拾えない含意”を抽出。 データ／実験設定 - 日本上場企業の決算発表（TDnet/決算短信等）を対象。 - 発表当日以降の短期〜数日スパンの超過リターンでドリフトを評価。 - SUE 単独、LES 単独、SUE×LES の条件別に比較。 結果 - SUE 単独・LES 単独では一貫したPEADを確認できず。 - SUE×LES の組合せ条件下（例：SUE 高×LES 低など）では、サプライズ方向へのドリフトを観測。 - LES は辞書極性とは独立に、発表後リターン変動の一部を追加説明。 所感／示唆 - 「数値×言語」の相互条件でPEADが表れやすい。 - 決算イベントのシグナル設計は、SUEとLLMテキスト要約（LES）の同時利用が有効。 - 実装面では、LESを単独スコアとして使うより、SUEで事前に候補を絞りLESで精緻化する二段構えがコスト対効果良。 - モデル監査の観点では、LESが辞書法以上の“文脈”を捉えていることを前提に、説明変数の直交性チェックとリーク検証を継続すべき。 (27) 有価証券報告書のサステナビリティ記述に関する分類および体系化 著者：梅原 武志 (総合研究大学院大学/日経リサーチ), 武田 英明 (国立情報学研究所/総合研究大学院大学) 目的／背景 有価証券報告書に記載された企業のサステナビリティに関する具体的な取り組みを抽出し、分類・可視化することを目的とする。 さらに、抽出した重要語とSDGsオントロジー（SDGsの目標や関連用語を体系化した知識ベース）を関連付けることで、企業の活動がどのSDGs目標に貢献するのかを体系化することを試みている。 アプローチ - テキストマイニングでサステナビリティ施策の記述を抽出し、カテゴリ分類とキーターム抽出を実施。 - 企業・業種別に分布を集計し、可視化（マップ化）で取り組みの差異を分析。 - 義務化以後の開示様式に合わせ、比較可能性を高めるための構造化ルールを設計。 データ／実験設定 - 日本企業の有価証券報告書（「サステナビリティ関連財務情報」欄）。 - 産業分類・企業属性（規模など）で層別し、記述の濃淡や用語の出現頻度・共起を分析。 結果 - 企業横断での共通語彙と業種固有語彙が抽出され、E（環境）・S（社会）・G（ガバナンス）の重点の置き方に業種差。 - 義務化以降の開示では、定型表現が増える一方で施策の具体性にはばらつきが残存。 - 体系化（分類＋用語辞書）により、多社比較の自動集計・可視化が可能に。 所感／示唆： - レポーティングは「定型＋自由記述」の二層で運用されるため、用語辞書と分類スキーマのガバナンスが重要。 - 投資家向けには、業種ごとの“力点”の違いを踏まえたベンチマーク・指標化が有効。 - 企業実務では、次年度以降の継続改善に向け、社内KPIと開示テキストの紐づけ（用語統一・具体性の担保）を進めたい。 雑感 Sig-finではテキスト分析が完全に定着しました。会場で様々な方と話をしましたが、今後もこの流れが継続するものと考えています。 暗号資産や量子コンピューターのテーマまで幅広く扱われているのが印象的で、実際に来場された方も金融業界に限らず多くの方がいらっしゃっていました。