こんにちは、Insight Edgeの齊藤です。 Google Trendsにおける「ontology」の検索関心の推移（日本、2004年以降） AIエージェントの実用化が進むなかで、オントロジーが再び注目を集めています。国内の検索動向でも、2026年に入ってから「ontology」への関心が大きく伸びています。 Palantir や Microsoft など、AIエージェントの基盤にオントロジーやナレッジグラフの考え方を取り入れる動きも広がっています。背景にあるのは、LLM（大規模言語モデル）がWeb上の一般的な知識を持つ一方で、企業や業務に固有の概念、関係、制約までは持っていないことです。この不足は、ベクトル検索を使った一般的なRAGでも埋めきれない場合があります。 そこで今回は、業務の概念や関係をナレッジグラフとしてデータ側に持たせ、その構造を先に定義するためにオントロジーの考え方を取り入れました。架空のスマートフォンと周辺アクセサリのカタログを題材に、対応関係の列挙や構成の判定に答えるGraphRAGを構築します。 なお、本記事は実務で行った内容をもとにしていますが、案件を特定できないよう、題材やデータは説明用に置き換えています。 目次 用語の整理 今回のケースと実現したい回答 なぜオントロジーを取り入れたのか 今回のGraphRAGの全体像 1. 答えたい質問を具体化する 2. 質問からオントロジーを設計する 3. ナレッジグラフを構築する 4. GraphRAGとして検索・回答する 実際の動き 5. 質問を受け入れテストにする やってみて分かったこと まとめ 参考文献 用語の整理 本題に入る前に、本記事で使う用語を簡単に整理します。 オントロジー ざっくりいうと「対象とする領域（ドメイン）で使う概念と、概念同士の関係を定義したもの」です。たとえば、「スマートフォン」「アクセサリ」「充電規格」という概念を定義し、アクセサリはスマートフォンへ、充電器は充電規格へ対応する、といった関係を定義します。必要に応じて、必須属性や制約も含めます。 オントロジー設計の代表的な入門資料として、スタンフォード大学の Ontology Development 101 があります。人やソフトウェアエージェントの間でドメイン知識の共通理解を持つことなどが、オントロジーを作る目的として挙げられています。 ナレッジグラフ オントロジーに沿って、個別の事実をノードと関係のグラフとして格納したものです。オントロジーが「型」、ナレッジグラフがその型に沿った「個別の事実」にあたります。 用語 持つもの 例 オントロジー 概念と関係の型 「アクセサリはスマートフォンへ対応する」 ナレッジグラフ 型に沿った個別の事実 「クリアケースAはスマートフォンAへ対応する」 GraphRAG 検索対象を文書からナレッジグラフへ置き換えたRAGです。 一般的なRAGは、質問と意味の近い文書を類似度の上位から数件取り出す仕組みのため、次のような質問が苦手です。 「対応する製品をすべて」のような網羅的な列挙：上位数件しか取得せず、全件そろったことを保証できない 複数の事実をまたぐ関係の判定：必要な事実が別々の文書に散らばっていると、1回の類似検索では集めきれない GraphRAGでは、ナレッジグラフ上の関係をたどって検索するため、こうした質問にも答えやすくなります。 なお、GraphRAGという言葉からは、Microsoftが公開している Microsoft GraphRAG を思い浮かべる方も多いかもしれません。Microsoft GraphRAGは、文書から対象と関係を自動抽出したグラフを作り、コミュニティ単位の要約で文書全体の俯瞰に応える実装です。一方、本記事のGraphRAGは特定の実装ではなく、ナレッジグラフを検索対象にする仕組み全般を指します。今回の構成との違いは次のとおりです。 観点 Microsoft GraphRAG 今回の構成 起点 文書全体 答えたい質問 グラフ 文書から対象と関係を自動抽出 オントロジーに沿って構築 主な用途 文書全体の俯瞰、テーマ探索、要約 全件列挙、関係探索、条件判定 どちらが優れているという話ではなく、起点と主な用途が異なります。本記事でも、俯瞰的な質問への回答にはMicrosoft GraphRAGの考え方を補助的に取り入れています。 今回のケースと実現したい回答 今回の題材は、スマートフォン本体、ケース、充電器、ケーブルなどを掲載した架空の製品カタログです。このカタログをもとに、単に製品説明を検索するのではなく、次の3種類の回答を実現します。 回答の種類 質問例 網羅的な列挙 スマートフォンAに対応するケースをすべて教えて 関係探索 スマートフォンAを30Wで充電するために必要な構成は 補助的な全体要約 このカタログでは、どのような互換性上の制約が多いか なぜオントロジーを取り入れたのか この3種類のうち、網羅的な列挙と関係探索は、用語の整理で触れたとおり一般的なRAGが苦手とする質問です。さらに今回のケースでは、単に「関連して言及されている」のか「実際に対応する」のかを区別する必要もありました。そのため、製品や規格の関係を構造として持つナレッジグラフを採用しました。 ただし、文書から関係を自動抽出するだけでは、この区別や、適合条件・対象範囲・根拠までは扱えません。何を表現すべきかは、答えたい質問から決める必要があります。そこで、必要な概念、関係、制約を先に定めるため、オントロジーを使いました。 今回のGraphRAGの全体像 処理の流れは、LLMが質問を解釈して定義済みの検索ツールを選び、ナレッジグラフから取得した事実をアプリケーション側で条件判定し、検証済みの結果だけをLLMが説明する、というものです。 本記事では、このGraphRAGの構築を次の5つのステップで説明します。 答えたい質問を具体化する 質問からオントロジーを設計する ナレッジグラフを構築する GraphRAGとして検索・回答する 質問を受け入れテストにする 1. 答えたい質問を具体化する オントロジーを設計するにあたり、最初にノードや関係を考えるのではなく、「この仕組みで答えたい質問」を整理しました。オントロジー設計では、このような質問をCompetency Questionsと呼びます。「そのオントロジーが答えられるべき質問」で、設計範囲や必要な情報を確認するために使います。 この進め方は、用語の整理で紹介したOntology Development 101に沿っています。同資料は、Competency Questionsでドメインと範囲を決め、重要な用語を挙げてクラスと関係を定義し、最後に個別の事実（インスタンス）を作る、という手順を示しています。本記事の1〜3は、この流れをGraphRAG構築へ当てはめたものです。 今回は、質問文だけでなく、対象範囲、入力条件、期待結果までを一組として定義しました。 たとえば、元の質問が次の内容だったとします。 スマートフォンAに対応するケースをすべて教えてください。 このままでは、「対応する」や「すべて」の範囲が曖昧です。そこで、対象範囲と条件を含む質問へ具体化し、テスト時に比較できる情報と一組で管理します。 質問：指定した端末モデルについて、対象カタログに有効な対応関係が登録され、 禁止条件に該当しないケースを、重複なくすべて取得できるか 対象端末：スマートフォンA データ範囲：対象カタログ 判定条件：有効な対応関係があり、禁止条件に該当しない 期待結果：正解として定めたケースの一覧 充電構成の探索や全体傾向の把握といったほかの質問も、同じように具体化しました。その際、列挙や構成判定では期待する集合を、俯瞰質問では要約に含める観点と根拠情報への追跡可能性を、合格条件にしています。 具体化した質問には、次の役割を持たせました。 オントロジーが扱う範囲を決める 必要な概念、関係、属性、制約を見つける 回答に使わない過剰なモデリングを避ける 構築後の受け入れテスト、データ更新時の回帰テストに使う 質問は最初に作って終わりではありません。実際のデータへ当てはめ、答えられなければ質問の条件またはモデルを見直す、というループを小さく回しながら、必要な範囲だけをモデリングしました。Ontology Development 101でも、オントロジー開発は本質的に反復的なプロセスだとされています。 2. 質問からオントロジーを設計する 具体化した質問から、オントロジーの構造を考えていきます。 「対応するケースをすべて取得する」「充電できる構成を判定する」といった質問から、次の概念が必要だと分かりました。 端末モデル 周辺アクセサリ ケース、充電器、ケーブルなどの種類 コネクタ 充電規格 対応する電力 適合条件 根拠となる文書箇所 主な関係は次のように整理しました。 上図は、質問に必要な関係だけを抜粋したものです。関係は、RDFのトリプル表現を参考に「主語・述語・目的語」の形で整理しました。「クリアケースA」―「対応する」→「スマートフォンA」のように、無条件に対応するケースはこの単純な関係だけで表現できます。 一方で、「厚さ3mm以下なら対応する」「特定部品とは同時に利用できない」のような条件付きの互換性は、単純な関係では表現しきれません。そこで、「適合条件」という独立した要素を用意し、複数の条件や根拠情報を関連付けました。 ここまでで、質問に必要な概念と関係を、AIエージェントから利用できる共通の形に整理できました。 3. ナレッジグラフを構築する 設計したモデルへ、製品カタログや仕様書からデータを登録します。 構築パイプラインは、次の段階に分けました。 ナレッジグラフ構築パイプライン 文書からの候補抽出にはLLMを使い、確定や検証はルールとプログラムで処理しています。 LLMに任せた処理 ルールとプログラムで行った処理 製品、規格、仕様、関係の候補抽出 型番や製品コードによる識別子の確定 同義語や別名の候補生成 単位と表記の正規化、重複の判定 根拠となる記載箇所の候補抽出 参照先と値域のチェック 定義した構造に収まらない記述の分類 カタログ版、有効期間、質問に必要な関係の確認 俯瞰質問向けには、登録後のグラフから関連の強い製品群を見つけ（コミュニティ検出）、主要な製品、関係、根拠情報をもとに要約します。厳密な列挙とは別の検索経路です。 抽出結果が「関連する」のような曖昧な関係に流れないよう、オントロジーで定義した概念と関係を抽出時のルールとして渡し、ルールに合わない結果はレビュー対象にしました。 また、LLMの出力をそのままNeo4jへ登録しないことも意識しました。オントロジーと検証ルール、具体化した質問に基づくテストを通った事実だけを採用することで、抽出にLLMを利用しつつ、ナレッジグラフの品質を保てるようにしています。 4. GraphRAGとして検索・回答する グラフを作っただけでは、GraphRAGとして利用できません。ユーザーの質問を、適切な検索方法へ接続する必要があります。 用意した検索ツールは次のとおりです。 質問に含まれる端末を特定する 対応するアクセサリを列挙する 条件を満たす構成を探す 利用できない理由を調べる 回答の根拠となる文書箇所を取得する 製品群ごとの傾向を要約する LLMは質問から製品名や条件を取り出し、網羅的な列挙、構成の探索、全体の俯瞰のどれを求めているかを判定して、利用するツールを選びます。 網羅的な列挙 「スマートフォンAに対応するケースをすべて」という質問では、対象モデル、カタログ版、有効期間、検証状態を条件にします。検索には、Neo4j用のクエリ言語であるCypherを使います。 ベクトル類似度の上位から数件を返すのではなく、管理対象内で条件を満たす集合を取得します。期待集合と比較できるため、欠落や余計な候補もテストできます。 関係探索 「30Wで充電するために必要な構成」では、端末、充電器、ケーブル、コネクタ、充電規格の関係をたどります。 グラフから候補を取得した後、電力や組み合わせ条件はアプリケーション側で判定し、LLMには検証済みの結果だけを説明させます。 製品群全体の要約（補助） 「カタログ全体ではどのような互換性上の制約が多いか」といった質問では、関連の強い製品群ごとに内容を要約します。 この要約は製品群ごとの傾向をつかむためのもので、事実を1件ずつ挙げる用途ではありません。詳細を確認したい場合のために、要約のもとになった事実と文書箇所も一緒に返しています。 実際の動き ここまでの処理を、「スマートフォンAをケースを付けたままワイヤレスで充電したい。必要なものを教えて」という質問で追ってみます。ワイヤレス充電器自体にも給電が必要なため、たどる関係が増えます。 質問の解釈 ：対象を「スマートフォンA」、条件を「ワイヤレス充電」「ケースを装着したまま」、意図を「構成の探索」とLLMが判定し、使うツールを選ぶ グラフ探索 ：端末が受電できる充電規格から対応する充電器をたどり、さらに充電器が必要とする給電規格から電源アダプタとケーブルまで広げる 条件判定 ：電力、ケースの厚さ、マグネット式の位置合わせへの対応をアプリケーション側で判定する 回答生成 ：検証を通った組み合わせと根拠情報だけをLLMへ渡し、説明文を生成する 最終的な回答は、次のような形になります。 スマートフォンAをワイヤレスで充電するには、次の組み合わせが必要です。 - ワイヤレス充電器E（規格Yに対応、最大15W） - 電源アダプタB（規格Xに対応、最大45W） - ケーブルC（規格Xに対応、最大60W） ワイヤレス充電器Eは動作に規格Xの給電を必要とするため、 電源アダプタBとケーブルCが必要です。 ケースを装着したまま充電するには、厚さ3mm以下、かつ マグネット式の位置合わせに対応していることが条件です。 - クリアケースA（2.0mm、マグネット対応）：装着したまま充電できる - 薄型ケースD（1.5mm、マグネット非対応）：位置合わせができず、安定しない - 耐衝撃ケースB（4.5mm）：取り外しが必要 根拠：スマートフォンA仕様書、ワイヤレス充電器E仕様書 5. 質問を受け入れテストにする 具体化した質問は、オントロジーの設計だけでなく、GraphRAGの受け入れテストにも利用しました。テストは、ナレッジグラフ、検索結果、最終回答の3層で行います。 5-1. ナレッジグラフの品質をテストする 必要なノードや関係、識別子、値・単位、有効期間、根拠情報が正しく登録されているかを確認します。 5-2. 質問に対する検索結果をテストする 具体化した質問で検索し、期待結果と比較します。 特に「対応するケースをすべて」のような列挙では、正解を一部含むだけでは不十分です。適合率・再現率に加え、期待する集合との完全一致、重複、根拠情報の有無を確認しました。 5-3. 最終回答をテストする 最後に自然言語の質問を入力し、検索結果が回答へ正しく反映されているか、グラフにない製品や条件を追加していないか、根拠を正しく説明できているかを確認します。 このように、同じ質問を設計とテストに使うことで、「グラフの内容」「検索結果」「最終回答」を一貫した基準で確認できました。 やってみて分かったこと 実装と評価を通じて、特に次の点が重要だと感じました。 オントロジーを抽出・検索・テストの共通言語にする オントロジーで、「対応する」「必要とする」「搭載する」などの関係の意味を先に定め、その定義をLLMによる抽出、グラフへの登録、検索、テストまで一貫して使いました。また、具体化した質問をもとに、必要な概念・関係・制約を整理し、何をモデル化するかを判断しました。 これにより、抽出・検索・テストの間で関係の意味がずれることを防ぎつつ、質問に必要のない構造を過剰に作り込むことも避けられました。テストが失敗した場合も、オントロジー、データ抽出、検索、最終回答のどこに原因があるかを切り分けやすくなりました。 ナレッジグラフを、回答だけでなく質問選びにも使う 「充電器がほしい」のように条件が足りない要望では、候補を1つに絞りきれません。この場合は、ユーザーへ追加の質問を返しながら候補を絞り込みます。 この質問選びをLLMだけに任せると、候補がほとんど減らない条件から確認してしまい、やり取りが長くなることがあります。そこで、ナレッジグラフから取得した候補に対して、どの条件で候補が大きく分かれるかを計算し、情報利得の大きい条件から確認するようにしました。 たとえば、「有線とワイヤレスのどちらを希望するか」と聞けば候補を大きく絞れます。一方、「ケーブルの色はどれがよいか」と聞いても、互換性にはほとんど影響しないため候補はあまり減りません。 これはナレッジグラフによって候補を構造化された集合として取得できるためですが、その前提には、製品の属性や関係がオントロジーによって共通の意味で定義されていることがあります。今回、オントロジーに沿って作った構造は、検索や判定だけでなく、「次に何を確認すれば候補を効率よく絞れるか」を決めるためにも利用できました。 まとめ 本記事では、答えたい質問からオントロジーを設計し、それに沿ってナレッジグラフを構築したGraphRAGの事例を紹介しました。その結果、管理対象内の全件列挙と、複数の関係をたどる構成判定を実行でき、必要に応じて製品群ごとの傾向も補助的に要約できるようになりました。 重要だったのは、自動生成を使うかどうかではなく、抽出する事実と関係の意味を先に定めることでした。オントロジーによって、抽出、検索、判定、テストで同じ定義を使えるようになりました。 一方で、この進め方はモデリングと検証に手間がかかります。答えたい質問がはっきりしない段階では、まず自動生成で全体を眺め、必要な範囲が見えてから構造を定義する方が早い場面もあると感じました。 オントロジーを使ったナレッジグラフの構築を検討されている方の参考になれば幸いです。最後までお読みいただき、ありがとうございました。 参考文献 Ontology Development 101（オントロジー設計の入門資料） Microsoft GraphRAG公式ドキュメント

こんにちは。Insight Edgeの小林と古野です。 私たちは先日、社内の月次対面イベントで「生成AI時代のエンジニア像」をテーマに、エンパシーサークルを企画・実施しました。 はじめに、本記事は会社としての公式見解を示すものではありません。社内の一部署・有志メンバーによる取り組みのレポートとして、当日の対話で出た意見や、運営を通じて得た気づきをまとめたものです。生成AIやエンジニアの将来について、唯一の答えを提示することも目的としていません。 この記事では、イベントを企画した背景、エンパシーサークルの進め方、参加者の対話から見えてきた論点、そして次回に生かしたい運営上の学びを紹介します。 なぜ「生成AI時代のエンジニア像」を話したのか 生成AIを使う開発が急速に身近になりました。調査からドキュメント作成まで、エンジニアのさまざまな仕事が変わり始めています。アイデアを短時間で形にできます。その一方、AIが出した成果物をどう確かめるのか、技術を学ぶ意味はどう変わるのか、といった問いも生まれました。 こうした変化については、普段の仕事の中で断片的に話すことはあります。しかし、立場や経験によって感じ方が異なるテーマを、結論を急がずに聞き合う機会は多くありません。 そこで今回は、賛成・反対を競う「議論」よりも、まず互いの考えを理解する「対話」に時間を使うことにしました。その方法として選んだのが、エンパシーサークルです。 エンパシーサークルとは エンパシーサークルは、一人が話した内容を聞き手が自分の言葉で返す対話の方法です。聞き手は理解を確かめ、共感した点を伝えます。 今回の進め方では、話し手がテーマについて話した後、指名された聞き手が「このように受け取りました」と要約し、共感した点も伝えます。話し手は、理解が合っているかを伝え、必要なら補足します。聞き手はすぐに評価や反論、助言をするのではなく、まず相手が何を考え、どのように感じているのかを受け取ることに集中します。 会議では、発言の早い人や声の大きい人の意見が中心になりがちです。エンパシーサークルには、順番に話す時間を設けることで全員の発言機会を作り、普段は表に出にくい迷いや価値観にも耳を傾けやすくする特徴があります。 当日の流れ 当日は、最初から本題に入らず、次の順番で進めました。 Good & Newで、直近にあった良かったことや新しい出来事を共有する 短い模擬セッションで、話し手と聞き手の動きを確認する 「生成AI時代のエンジニア像」をテーマに本番のサークルを行う 終了後、対話の内容と進め方の両方について振り返る Good & Newを入れたのは、参加者が声を出しやすい雰囲気を作るためです。模擬セッションでは、話を聞いて要約し、共感した点を伝え、話し手に理解を確認するところまでを実際に試しました。その後の本番では、それぞれが生成AIへの期待、不安、自分たちの役割がどう変わると考えているかを話しました。 この順序にしたことで、形式を説明するだけで終わらず、全員が一度動きを体験してから本題に入れました。一方で、やってみたからこそ見えた難しさもありました。これについては後半で触れます。 対話から見えてきたこと 生成AI時代のエンジニア像 実装が速くなるほど、品質保証の重みが増す 参加者の間では、生成AIによって調査や実装の速度が上がり、作れるものの量が増えるという見方が多くありました。これまで時間がかかっていた試作を早く形にできることは、大きな可能性です。 ただし、出力が速くても、成果物が正しいとは限りません。一見もっともらしいコードでも、要件を満たしていなかったり、例外への配慮が足りなかったり、セキュリティ上の問題を含んでいたりする可能性があります。作る量が増えれば、確認する量も増えます。 そのため、AIが生成した成果物には妥当性の評価が必要です。テストやレビューを通して品質を保証する役割は、従来以上の重要性を持つのではないかという意見が共有されました。AIへ「任せた」からといって、品質責任が消えるわけではありません。最終的に利用者へ届ける側には、根拠に基づく説明と責任が求められます。 これは、テストコードを書けば十分という話でもありません。何を正しい状態とみなすのか、どこにリスクがあるのか、利用者にどのような影響が及ぶのかまで考える必要があります。AI時代の品質保証には、実装の確認だけでなく、設計や要件に立ち返る視点も求められそうです。 具体的な取り組みとして、アーキテクチャ上のルールに反する実装をリンターで検出することが挙がりました。テストカバレッジを高め、未検証のコードを減らすことも挙がっています。別の参加者からは、AIを使えば自分の能力を超えたものまで作れてしまうからこそ、良し悪しを自分で言語化できなければ評価できないという発言もありました。そのために、ソフトウェア工学やデザインパターンなどの基礎を改めて学び直しているそうです。 技術だけでなく、ビジネスを理解する力が問われる 生成AIによって、職種の境界がこれまでより曖昧になるという意見もありました。エンジニア以外の人が自分で試作品を作る場面が増え、エンジニアも企画や業務設計に関わりやすくなります。 そのとき、エンジニアの価値は「依頼されたコードを速く書くこと」だけでは測れません。曖昧な相談から本当に解くべき課題を見つけること、業務や利用者を理解して要件へ落とし込むこと、複数の選択肢から目的に合うものを選ぶことが、より重要になります。 AIは、与えられた問いに対する選択肢を増やしてくれます。しかし、そもそも何を問うべきか、どの成果を価値と呼ぶのかは、事業や現場の文脈を理解しなければ判断できません。技術とビジネスの間を行き来し、作ることを成果につなげる力が、今後のエンジニアに求められるのではないかと考えました。 エンジニアの価値は下がるのか、仕事は広がるのか この点については、参加者の意見が分かれました。一方では、AIが調査や実装を担うようになることで、既存の技術スキルやシステムエンジニアの社会的な価値が下がるのではないかという不安が語られました。「新しい技術を知り、それを使って早くものを作ること」に楽しさを感じてきた参加者からは、その過程をAIが担うようになったとき、エンジニアリングの楽しさをどこに見いだすのかという問いも出ました。 一方では、AIによってソフトウェアを作るコストが下がれば、これまで費用対効果の面から見送られていたアイデアも実現しやすくなり、ソフトウェアの需要はむしろ増えるという見方もありました。作られるものが増えれば、品質を保証し、複雑さを管理する仕事も増えます。その結果、エンジニアの仕事がなくなるのではなく、役割の重心が変わり、担う範囲が広がっていくという考えです。 実装そのものにかかる時間が短くなれば、設計、検証、意思決定、他職種との協働に使える時間は増えます。アイデアを素早く試せるため、エンジニアが企画の初期段階から価値検証に参加する機会も広がります。 対話の中で1つの結論に決めたわけではありません。ただし、どちらの立場からも、AIの出力を評価するための基礎的な技術知識が必要だという意見が出ました。仕組みを理解していなければ、間違いに気づくことも、より良い選択肢を示すことも難しくなります。コードを書く量が減ったとしても、技術を理解する必要がなくなるわけではない、という点は共通していました。 便利さの裏側にある懸念も扱う 生成AI活用の主な懸念 対話では、生成AIを前向きに捉える意見だけでなく、実務で使い続けるうえでの懸念も挙がりました。 1つは、AIへの依存によって、自分で考え、試行錯誤する機会が減るのではないかという不安です。答えを早く得られることは便利ですが、出力をそのまま受け入れていると、なぜその答えになるのかを理解する過程が抜け落ちます。学習の速度を上げる使い方と、思考を手放してしまう使い方を区別することが重要です。 もう1つは、利用コストや特定サービスへの依存です。モデルの性能だけでなく、継続的な費用、データの扱い、代替手段の有無を含めて判断しなければなりません。また、私たちの周囲でAI活用が日常になっていても、すべての組織が同じ前提に立っているとは限りません。利用環境やガバナンス、予算の違いを踏まえ、目の前の状況を一般化しすぎない姿勢も必要です。 生成AIを使うか使わないかという二択ではなく、どの仕事で、何を任せ、どこを人が確かめるのかを具体的に設計することが大切だと感じました。 エンパシーサークルを運営して学んだこと エンパシーサークルの学び 全員が話し、互いの考えを知る場になった もっとも良かったのは、参加者全員に話す時間があったことです。通常のディスカッションでは結論に近い意見が優先されがちです。今回は不安や迷いを含めて、その人が今どのように捉えているかを聞けました。 また、聞き手に役割があることで、自分の発言を準備しながら待つのではなく、相手の言葉に集中する時間が生まれました。理解した内容を言い返す過程では、同じ言葉でも人によって受け取り方が違うことに気づきます。相手の考えを知るだけでなく、自分の理解の癖を振り返る機会にもなりました。 聞き手の役割は、想像以上に難しい 一方で、「相手の話を正確に要約すること」と「相手に共感を示すこと」のバランスには難しさがありました。一言一句を聞き漏らさないようにすると、目線やうなずきといった自然な反応が減ります。反対に、自分の解釈を加えすぎると、要約ではなく評価や意見になってしまいます。 振り返りでは、共感をルールとして求めること自体についても意見が分かれました。「反論や助言をせず、共感する」というルールがあると、相手が本当に共感しているのか分かりにくいという指摘です。ルールに従って否定しないだけかもしれない、という懸念も示されました。一方で、発言をすぐに否定されないと明示することが、率直に話すための心理的な安全につながるという見方もありました。 このやり取りから、形式に沿って共感の言葉を返すだけでは十分でないと気づきました。相手の意見に全面的に賛同することと、経験や背景の中から本当に共感できる点を見つけることは異なります。聞き手には、理解した内容を返すだけでなく、自分がどこに共感したのかを誠実に言葉にすることが求められます。 次回は、聞き手の基本動作をより具体的にしたいと考えています。たとえば、「発言内容と、その背景にあると受け取った価値観を短く言い換え、共感した点を伝える。最後に『この理解で合っていますか』と確認し、評価、反論、助言はしない」といった目安です。話し手が補足や訂正をすることを前提にすれば、聞き手が最初から正確な要約を目指す負担も減らせます。 テーマを絞り、対話と議論を分ける 「生成AI時代のエンジニア像」は、多様な意見を引き出すには良いテーマでした。しかし、品質、コスト、学習、キャリア、職種の境界などに論点が広がり、一つひとつを深掘りする時間は足りませんでした。 次回は、「AI生成物の品質を誰がどう保証するか」「AI時代に技術をどう学ぶか」のようにテーマを絞ると、対話を深めやすくなりそうです。また、エンパシーサークルで相互理解に集中した後、別の時間に共通点や相違点を整理し、具体策を話し合う構成も試したいと考えています。 対話の前後で変わったこと、変わらなかったこと 企画前、私たちはエンパシーサークルを、異なる意見を理解し合うための対話の形式として捉えていました。実際に行い、共感をルールにすることへの違和感を聞いたことで、手順に沿うだけでは相互理解にはならないと気づきました。相手の発言から本当に共感できる点を探し、自分の言葉で返すこと自体が1つのスキルです。生成AIによって職種の境界が曖昧になる中で、利用者や他職種と協働するエンジニアにとっても、この力は重要になるのではないかと考えるようになりました。 仕事への向き合い方についても、問いの置き方が変わりました。以前は「AIにどの仕事を任せられるか」に目が向きがちでしたが、対話を経て、「AIによって生まれた時間を何のために使うのか」「誰の課題を解き、どのような価値につなげるのか」まで考える必要があると捉えています。実装の速度だけでなく、品質を保証し、事業や利用者の文脈を理解して周囲を巻き込み、成果へつなげるところまでがエンジニアリングです。 一方で、AIの成果物を評価し、品質に責任を持つのは人であるという考えは変わりませんでした。基礎的な技術知識が必要だという考えも同じです。むしろ、異なる立場の参加者からも品質や学習の重要性が語られたことで、その確信は強まりました。これからもAIを積極的に使いながら、出力を採用する根拠を説明できるかを問い、テストやレビューなどの仕組みで確かめる姿勢は変えずにいたいと思います。 まとめ 今回のエンパシーサークルでは、生成AIによって実装や試作が速くなるほど、成果を確かめる人の役割が重要になるという認識が見えてきました。その人には、目的に合うかを判断し、成果に責任を持つ姿勢も求められます。エンジニアに必要なものは、実装力だけではありません。設計、検証、判断、ビジネス理解、他職種との協働を組み合わせ、AIを含む開発全体を前へ進める力へと広がっています。 同時に、これは今回参加したメンバーの対話から得た一時点の見方です。生成AIの技術も、それを取り巻く仕事も変わり続けています。だからこそ、一度の結論を固定するより、異なる考えを持つ人同士で定期的に話し、自分たちの前提を確かめ直すことに意味があると感じました。 エンパシーサークルは、すぐに答えを出すための手法ではありません。しかし、相手の言葉を急いで評価せずに聞くことで、普段の会議では見えにくい期待や不安を共有できます。今回得た運営上の学びも生かしながら、テーマや進め方を調整し、これからも対話の機会を作っていきたいと思います。

はじめに こんにちは、InsightEdgeのPMの中村です。先日、ある案件の説明資料を作成しようと、盛り込みたい内容を箇条書きにして生成AIに入力してみました。すると5分ほどで、決定事項・宿題・担当者・期限まで整理された形にまとまって出てきました。率直に言って、筆者が自分で作るより読みやすい仕上がりでした。似たような経験をお持ちの方は、多いのではないでしょうか。 本記事では、この体験を入り口に、生成AI時代のPM(プロジェクトマネージャー)の仕事がどう変わっていくのかを、現役PMの視点から考えてみたいと思います。 はじめに 第1章 実は「雑務」こそがPMの武器だったのではないか 第2章 AIは情報を「作りすぎる」 第3章 「よくできた資料」は、もう褒め言葉にならない 第4章 あらためて、AI時代のPMの仕事とは 第1章 実は「雑務」こそがPMの武器だったのではないか AIが普及した今、「議事録や進捗集計はAIに任せ、PMは本質的な業務に集中すべき」という主張は広く語られており、私も基本的には同意見です。 ただ一方で、PMの影響力は実はその雑務から生まれていたのではないか、とも感じています。たとえば議事録に「やります」と書かれていても、それが前向きな「やります」なのか、渋々の「やります」なのかは、文字面だけでは判断できません。AIの文字起こしで「やります」という結論が正確に残っていても、発言者の温度感までは見えないのです。 また、議事をまとめる際には、多少の解釈で行間を補ったうえで発行し、それをもって関係者全員の合意を取る——現場では、そうした進め方が機能してきた面もあると思います。雑務は面倒な作業であると同時に、こうしたニュアンスも含めて情報が最も集まる特等席でもあったのです。 これらをAIに委ねれば、透明性は高まります。それ自体は歓迎すべきことです。ただ、プロジェクトを運営するうえでの強みは失われます。雑務から解放されて身軽になったつもりが、武器も一緒に手放していた——導入の際には、この点を自覚しておく必要があると考えています。 第2章 AIは情報を「作りすぎる」 「AIで時間が浮けば、本質的な思考に充てられる」。これも魅力的な話ですが、一概にそうとは言えない面があると筆者は考えています。 生成AIは、依頼した以上に関連資料や文脈を補い、大量の情報を提示してくれます。それ自体はAIの強みですが、判断に必要な水準を超えた情報が積み上がり、かえって意思決定が重くなる懸念もあります。せっかく浮いた時間が、増えた情報をさばく時間に置き換わってしまっては本末転倒です。 AI時代のPMには、出力された情報を盲信するのではなく、以下の2つのアプローチが重要になると感じています。 情報の引き算 : AIが「作りすぎた」ノイズを削ぎ落とし、本質だけを残す コンテキストの付与 : AIには見えていない「現場のコンテキスト（文脈）」を人間が補足する AIの出力を 「どこまで使い、どこから捨てるか」を見極める力（情報の編集力） が、これまで以上に問われるようになるでしょう。 第3章 「よくできた資料」は、もう褒め言葉にならない 生成AIを使えば、体裁の整った計画書を短時間で作成できます。その結果起きるのは、「よくできた資料」の価値の低下です。 正直に申し上げると、筆者は資料作成が得意ではありません。ですので、AIが整った資料を作ってくれること自体には大賛成です。 ただ、そもそも資料の目的は「相手に伝わりやすくすること」にあります。第2章で述べたとおり、AIには情報を作りすぎる傾向がありますから、資料においても過剰な情報は不要ですし、本来の趣旨から外れた内容が紛れ込んではいけません。資料作成が楽になった分、 「余計なものが入っていないか」を見極めるという新たなチェックポイントが増えた 、と捉えるべきだと考えています。 第4章 あらためて、AI時代のPMの仕事とは ここまでの話を整理すると、進捗集計や資料の骨子作成、機械的なファシリテーションといった「定型的な管理業務」としてのPMの仕事は、近い将来AIに完全に置き換えられていく（＝なくなる）と予測されます。しかし、これは悲観すべきことではなく、むしろ歓迎すべき変化だと捉えています。資料作成や調整業務から解放されること自体は、望ましいことだからです。 では、人間のPMには何が残るのでしょうか。筆者は、以下の2つのコア領域こそが、これからのPMの存在価値になると考えています。 感情の機微を汲み取った「合意形成」と「意思決定」 （第1章・第2章で触れた、AIには見えない行間やコンテキストを補う領域） 「PMエージェントAI」をプロジェクトごとにカスタマイズ・最適化する役割 （新たな技術を現場の武器として乗りこなす領域） 仕事とは、社会から求められることに対して対価をいただき、貢献することです。そうであるならば、従来型のプロジェクトマネジメントスキルそのものは不要になるかもしれません。しかし、変化を恐れるのではなく、次のロールを見据えて動き始めること。 私たち Insight Edge では、こうした生成AIをはじめとする先端技術を社会やビジネスの現場に正しく届ける（DX）営みを日々行っています。たまたま現時点でその技術が生成AIであり、筆者のロールがPMであるに過ぎません。そして、その両方はこれから大きく変わっていく可能性があります。 AIの資料作成力に驚かされた経験は、同時に次の役割を考えるきっかけを与えてくれたのだと思っています。

商社系DX組織3社（Digital Experts様、MBKデジタル様、Insight Edge）が集まり、AI活用戦略から組織改善の取り組みなど互いの知見を共有する情報交流会を開催しました。 ※本記事では、企業名を併記する際は、Insight Edge以外をアルファベット順に記載しています（各社の取り組みLTは発表順）。 今回はInsight Edgeが発起し、CTO猪子のリードのもと、この記事の筆者の肥塚が共有会の企画や運営を行わせていただきましたので、共有会を企画するに至った経緯、共有会の内容、企画・運営した際の学びを共有させていただきます。 Insight Edgeについて Insight Edge（弊社）は、住友商事グループのDX内製組織として https://insightedge.jp/business/ で紹介されている通り、総合商社のDX施策を非常に幅広い面から支援・実装しています。 ソフトウェアエンジニア、データサイエンティスト、プロジェクトマネージャー、コンサルタント、デザイナーなど幅広い人材が所属し、価値を共創していることが特徴です。 今回の交流会の企画に至った経緯について 弊社は、住友商事グループのDX内製組織ですが、他の総合商社グループにも技術面から価値創造を行っている企業様がいらっしゃいます。 それらの企業様と組織改善のヒントを互いに伝え合う手段が欲しいという声が上がったため、丸紅グループのDigital Experts様、三井物産グループのMBKデジタル様と共に、今回の「商社系企業情報交流会」の企画に至りました。 交流会の概要について 以下の要領にて実施しました。 場所: MIRAI LAB PALETTE 日時: 2026年5月21日 参加企業: Digital Experts様、MBKデジタル様、Insight Edge 参加人数: 42名 ※参加企業は、Insight Edge以外をアルファベット順に記載しています。 アジェンダ 以下のアジェンダにて実施しました。 オープニング 弊社CTO猪子からご挨拶 各社の概要紹介 各社の取り組みLT 立食 クロージング 弊社CEO小坂からご挨拶 立食形式にて皆さんにご歓談いただきましたが、大変盛況でした！ 立食の様子。写真は参加者の許可を得て掲載しています。 各社の取り組みLTについて アジェンダの中でも、各社の取り組みLTでは各社のカラーがよく出ていたので、ご紹介いたします！ ※本記事に記載されている他社製品情報は公開情報です ※各社の取り組みLTは、発表順に記載しています。 MBKデジタル様のご発表 MBKデジタル様のCTO岩尾様から 「AI モデルが賢くなるほど強くなる組織をつくる — 情報資産・プロダクト・プロセスの設計 —」 という題にてご発表いただきました。 従来はAIの新しいモデルやツールを個別に追いかけるのが主流でしたが、MBKデジタル様では会社としてAIの進化を享受しやすいように、以下の点にて整備を行っているということでした。 情報資産 議事録、案件情報、商談履歴などのデータをAIが読める形に蓄積し、後でAIが活用しやすくする プロダクト AIの進化を会社の提供価値とするべく、データからAIが自然言語で示唆出しを行う「BI Suite」や、業務に特化したAIアプリをGUIで構築できる「AI Craft」を開発・外販している 開発・業務プロセス 実装などの開発プロセス、資料づくりなどの業務プロセスを人間が最初からやるのではなくAIに実行させ、人間は「判断・検証・説明責任」に寄せる Digital Experts様のご発表 Digital Experts様の技術部長の松原様から 「組織強化の観点から見るDigital Experts の取り組み - 制度・技術・人財」 という題にてご発表いただきました。 「内製組織」と「外部展開」の2つを支える軸として「組織強化」を据え、以下の観点についてご共有いただきました。 社内プロセス改善 制度をプロダクトとして捉え、継続的にアップデートする トップダウンではなく、全員がフラットに議論してその場で決める、現場発の意思決定 技術カルチャー 2週間に1回の頻度で持ち回りでLT会を行う AIを業務に導入。有志でプロトタイプ開発を行い、効果検証後に標準化 丸紅グループ全体に展開されたMarubeni Chatbot 外部展開体制の強化 内製したプロダクトの外販を行う。限られたリソースで運用するべく自動化や生成AIの利用を徹底すると共に、商社の幅広い販売チャネルを活用 FTO調査や自社特許の取得促進などの知財戦略の強化 採用 生成AIを活用した自走力の高い方を採用する一方、心理的安全性を担保する組織づくり Insight Edge 弊社では「みんなでやる」精神のもと、市川とニャットの2名にて発表を行いました。 市川からは「技術向上WGの取り組み」、ニャットからは『「やってみる?」のひとことから始まった、初めてのアドベントカレンダー』という題で発表いたしました。 技術向上WGの取り組み 業務で利用するLLM周辺領域をテーマに、ケイパビリティ向上や認知拡大、客観的な技術力の証明を目的とした取り組みを紹介しました。 特に言語処理学会第32回年次大会（NLP2026）においては、Insight Edgeは大手企業を上回る7件の発表（参加企業中5位、社内集計より引用）を行い、注目を集めました。 「やってみる?」のひとことから始まった、初めてのアドベントカレンダー 2025年度にテックブログのアドベントカレンダーに挑戦した時の取り組みを紹介しました。記事のレビューエージェントや企画を盛り上げるSlackボットなど、ユニークな施策のもとアドベントカレンダーを無事に完走し、Insight Edgeのバリューである「やってみる」「みんなでやる」「やり抜く」を体現した企画でした。詳細は こちら からご覧ください。 交流会実施の結果 実施後、Insight Edgeの参加者に対してアンケートを行いました。 発表や食事含めて大変好評でした。 Insight Edge社内アンケート結果（2026年5月実施） いくつかの声をご紹介します。 Digital Experts様、MBKデジタル様が推進している自社プロダクトの外販について興味を示す声が多いのが印象的でした。 各社の変遷やその中での課題についてInsight Edgeと通ずるものがあり参考になりました。 生成AIの社内業務活用の例をもっと聞きたかったです。 このように、各社の多彩な取り組みに興味を示す声がとても多く寄せられました。 個人的には、LTをお聞きし、OAMチームの一員として保守運用における生成AI活用深化や社内事例の整備を行っているので、とても参考になりました。 ご参加いただきましたDigital Experts様、MBKデジタル様につきましても、情報交換する中で刺激になったためまたご相談させてほしいという声や、同業他社でありながら異なる規模の会社の話を聞けて面白かったという声をいただきました。 交流会実施の感想 今回の商社系企業情報交流会では、CTO猪子のリードのもと、自分が運営全般業務や司会を担当しました。 Insight Edge内外の皆さんが、準備や後片付けに快くご協力くださり、大変ありがたく感じました。 また、発表時やご歓談時は大変盛り上がり、商社らしいなあと感じました。 特にLT発表会では、「AI技術をどう使い、自社、ひいては自社グループの価値創造に貢献するか？」という点に各社それぞれのカラーが出ていて興味深かったです！ 次回実施する機会があれば、またぜひ運営に参加したいと思います。 一緒に価値を創る仲間を募集しています 今回の交流会を通じて改めて感じたのは、生成AIの進化によって技術そのものは急速に変化していく一方で、組織として学び続け、挑戦し続ける文化こそが競争力になるということです。 技術を磨くだけではなく、 新しい技術を実際の事業価値につなげたい方 生成AI時代のエンジニアリングやデータ活用のあり方を一緒に切り拓いていきたい方 そんな方とぜひ一緒に働きたいと考えています。 少しでもInsight Edgeに興味を持っていただけた方は、ぜひ採用ページもご覧ください。カジュアル面談も歓迎しています。 👉 https://herp.careers/v1/insightedge 今後も、このような企業間の交流を通じて得られた知見を積極的に発信し、日本全体のDX・AI活用の発展にも貢献していきたいと思います。

こんにちは！DSチームの ヒメネス（Jiménez） です! 前回投稿 からほぼピッタリ丸一年経ちました（364日経過）！ 今回は、2025年度にDSチーム内で実施した「ビジネス力向上TF」の取り組みと、その第1回「問題発見力」のセッションで活用したMy GPTsについてお話しします。 目次 ビジネス力向上TF DSに求められるビジネス力 顧客役を果たすMy GPTs 作成方法 良し悪し 振り返り まとめ ビジネス力向上TF DSチームでは、技術力だけでなく ビジネス力 も重要だと考えています。ビジネス力とは、企業が抱える課題を理解し、技術的ソリューションに変換し、技術者でない人にも説明できる力です。そこで、2025年度に「ビジネス力向上TF（タスクフォース）」という取り組みを開始しました。 DSに求められるビジネス力 Insight Edgeでは、ビジネス力を特に重視しています。その理由は、クライアントと直接向き合い、ビジネス要件を理解し、データサイエンスの知見を活かした提案を行う必要があるためです。技術力だけでは不十分で、ビジネスの文脈を理解し、課題を発見・解決できる力が、チームメンバーに不可欠なスキルとなっています。 これは私たちの組織だけの考えではありません。 データサイエンティスト協会が規定するビジネス力 も同様の重要性を強調しており、9のスキル項目で構成されています: No. スキル TF実践 1 行動規範 × 2 論理的思考 ○ 3 プロセス ○ 4 データの理解・検証 ○ 5 データ入手 ○ 6 意味合いの抽出、洞察 ○ 7 解決 ○ 8 事業に実装する ○ 9 活動マネジメント × このTFでは、 問題発見力、調査分析力、説明力、提案力 という4つのコアスキルを軸に、上記の○印がついた項目を実際のビジネスシーンを想定した演習を通じて実践的に学ぶことを目指しました。 第1回のテーマは「 問題発見力 」でした。架空の企業「LiveWell」という健康・ウェルネスプラットフォームを題材に、ユーザー登録フォームの完了率が低下しているという課題に対して、メンバー全員がその原因を探る演習を実施しました。 しかし、ここで一つの壁にぶつかりました：演習では 私自身が顧客役を演じるか他メンバーに演じてもらう 必要がありました。そこで、以下のような課題が現れました: 全メンバーの質問に同時に対応できない（いずれの場合でも、担当者数は受講者数より圧倒的に少ない） 細かい質問をされても、すべての背景情報を把握できるわけではない 顧客として一貫性のある回答を保つのが難しい 私担当でも他メンバー担当でも、事前準備（勉強）に必要な時間が発生する そこで思いついたのが、 My GPTsを使って「顧客役」を演じさせる というアイデアでした。 顧客役を果たすMy GPTs My GPTs は、OpenAIが提供するChatGPTのカスタマイズ機能です。特定の役割や知識を持たせることで、自分専用のGPTを作成できます。今回は、LiveWell社のプロダクトオーナーとして振る舞うMy GPTを作成しました。 このMy GPTを使うことで、 各メンバーが自分専用の「顧客」を持つ ことができ、いつでも質問できる環境を実現しました。演習では、メンバーは各自このMy GPTと対話しながら、LiveWellのユーザー登録フォームの問題について情報を収集し、原因を特定していきました。 作成方法 My GPTの作成には、以下の2つの要素を用意しました: 1. プロンプト（指示） My GPTに対して、どのような役割を演じるかを明確に指示しました。主なポイントは以下の通りです: 役割定義 ：LiveWell社のプロダクトオーナーとして振る舞う 回答の制約 : 事実に基づいて正直に答える 原因分析や仮説立てはしない（それは演習参加者の仕事） 知らないことは「把握していません」と答える 振る舞い ：ChatGPTのようにすべてを知っている存在ではなく、情報の一部しか知らない一人の社員として振る舞う 特に重要だったのは、「 自ら推測して答えることは避けてください 」という指示です。これにより、My GPTが勝手に原因分析をしたり、存在しない情報を作り出すことを防ぎました。 2. コンテキスト（背景情報） My GPTに「知識」として与える背景情報を文書にまとめました。例えば: LiveWell社の事業内容やビジネスモデル 観測されている問題の兆候（登録完了率の低下、離脱率の高さなど） ユーザーからのフィードバック（アプリストアのレビュー、SNSの言及など） 社内で把握している状況（データ分析の有無、開発チームの優先順位など） プロダクトオーナーとしての視点（問題には気づいているが、原因は特定できていない） このような情報をMy GPTにアップロードすることで、顧客として現実的な知識レベルを持たせました。 セッションで使用したMy GPTとの会話例 良し悪し My GPTを使った演習には、明確な 強み と 弱み がありました。 強み スケーラビリティ ：各メンバーが同時に自分専用の「顧客」と対話できる。 完全なコンテキストカバー ：人が一人では把握しきれない細かい背景情報を基に対応可能。 品質担保 ：人間と違い、My GPTは文書化された情報を常に参照するため、 演習の品質を一定に保つ ことができる。 一貫性のある役割演技 ：プロンプトで「知らないことは知らないと答える」や「推測はしない」と指示することで、現実的な顧客の振る舞いを再現できる。 楽しさとエンゲージメント ：メンバーからは「AIと対話する形式が面白かった」という声が多数。 弱み 回答の一貫性は保証されない ：同じ質問でも、聞き方やタイミングによって微妙に異なる回答が返ってくる。 文書にない情報への対応 ：コンテキスト文書に記載されていない事柄（過去のデータ、他の施策など）を聞かれた場合、My GPTが勝手に回答を「創作」してしまう。 なお、予想通りDSメンバーの中にはMy GPTに与えたコンテキストやプロンプトを暴こうと「ハック」を試みる人もいましたが、幸い指示が十分に堅牢だったため、役割を逸脱させることはできませんでした！ 振り返り 2025年度の取り組みの効果を測定するため、年度初めと年度末にメンバーへアンケートを実施しました。その結果、 参加メンバー全員のビジネススキルに対する自信が向上 していることが確認できました。チームとして、確実に成長していることを数値で示すことができました。 この成果を踏まえ、メンバーのビジネス力を継続的に向上させ、実践の場を提供することの重要性を再認識しました。スキルは一度学んだだけでは定着しません。 継続的な練習と実践を通じてこそ、真に身につく ものです。そこで、2026年度もビジネス力向上TFを継続し、 さらなる成長を目指す ことを決定しました。 その中で、My GPTは 顧客とのインタラクションをシミュレートする手段として非常に有効 であることがわかりました。My GPTを使うことで、メンバーは実際の対話に近い感覚を得ながら、自分のペースで演習に取り組むことができ、高いエンゲージメントを維持できました。 2026年度では、昨年度の経験を活かし、コンテキスト情報をより詳細にして深い質問にも対応できるようにしたほか、ガイドラインをより厳格にすることで、メンバー自身が適切な質問を考える思考プロセスを促すようにしました。このように改善を重ねながら、 ビジネス力向上TFを継続展開 しています。 まとめ 2025年度、DSチームの「ビジネス力向上TF」第1回セッションにおいて、My GPTsを活用して顧客役を演じさせる試みを実施しました。TF全体では、問題発見力、調査分析力、説明力、提案力という4つのコアスキルを段階的に学ぶカリキュラムを用意しましたが、特に最初の「問題発見力」のセッションでMy GPTsが大きな効果を発揮しました。各メンバーが自分専用の「顧客」と対話しながら、真の課題を見つけ出すスキルを磨くことができました。 My GPTsには、スケーラビリティや網羅性といった強みがある一方、完全な一貫性を保証できないという弱みもあります。しかし、適切な設計と運用によって、これらの弱みを最小限に抑えつつ、教育・トレーニングの場面で大きな価値を発揮できることがわかりました。 この成功を受けて、 2026年度も同じ手法を採用し、さらにブラッシュアップしながらビジネス力向上TFを継続していきます 。技術の進化によって、学習やスキル開発の方法も変わってきています。My GPTsのようなツールを活用することで、より効果的で楽しい学びの場を作ることができます。皆さんの組織でも、ぜひMy GPTsを使った新しい取り組みを試してみてください。

この記事で伝えたいこと この記事では、PMやデザイナーがGitの細かい操作を覚えなくても、要件定義書やmockupの変更をGitHub上の変更として扱えるようにした取り組みを紹介します。 ポイントは、Gitをなくしたことではありません。Gitの履歴、Pull Request、CI、レビュー可能性は残しつつ、branch切り替え、commit、push、PR作成、auto-mergeといった操作をAIエージェントとスクリプトの裏側に寄せたことです。 近年、AIエージェントはコードを書くためだけの道具ではなくなってきました。 自然言語で作業を依頼し、ローカルファイルの読み取りやコマンド実行、GitHub連携まで進めることで、これまでエンジニアだけが担っていた「変更を安全に届ける」作業の一部を肩代わりできます。 一方で、何でもAIに任せればよいわけではありません。 今回の取り組みでは、AIエージェントが判断する部分と、shell scriptやCIで機械的に守る部分を分けました。 この分担こそが、非エンジニアにもGit管理の恩恵を広げる上で重要だったと考えています。 想定読者 PM、デザイナー、PdMなど、Gitを日常的には使わないがプロダクト開発の成果物を更新する人 非エンジニアの作業成果を、GitHubの履歴やPRに載せたいエンジニア AIエージェントを、単なるコード生成ではなくチームワークの基盤として使いたい人 目次 はじめに 対象リポジトリで実際に起きていたこと 何ができるようになったのか 利用者から見える体験 裏側で起きていること 同じ仕組みを作るなら何を実装するか なぜこれが嬉しいのか 実際の利用者コメント AIエージェント時代の非エンジニアの作業はどう変わるのか エンジニアとして気をつけたこと 作りながら感じたこと 今後やりたいこと まとめ はじめに こんにちは、Insight Edgeの古野です。 プロダクト開発では、ソースコードだけでなく、要件定義書、画面mockup、仕様メモ、検証結果など、多くの成果物が日々更新されます。 これらはエンジニアだけのものではありません。 PMが要件を更新し、デザイナーが画面案を調整し、それをもとにエンジニアが実装します。 ところが、成果物をGitHubで管理しようとすると、非エンジニアにとって急にハードルが上がります。 cloneとは何か branchはいつ切り替えるのか commit messageには何を書くのか pushしてよいbranchはどれか PRを作ったあと何を見ればよいのか conflictと表示されたら何をすればよいのか これらはエンジニアにとっては日常的な操作です。 しかし、要件やデザインを更新したい人にとっては、本来の仕事とは別の認知負荷です。 そこで、PMとデザイナーが担当領域の変更をGitHubに反映するためのAIエージェント向けコマンドを整備しました。 PMは次のように実行します。 /pm merge デザイナーは次のように実行します。 /dsn merge これだけで、裏側ではcommit、push、Pull Request作成、auto-merge設定まで進みます。ユーザーはbranchを切り替えません。 git add や git push も打ちません。 対象リポジトリで実際に起きていたこと この仕組みは、思いつきで作ったものではありません。 対象リポジトリでは、PMが扱う要件と、デザイナーが扱うmockupの更新が継続的に発生していました。 執筆時点で、2026年6月以降の履歴を確認すると、mockup更新のcommitは34件、要件定義書や要求機能一覧の更新commitは8件ありました。 確認には、例えば次のようなログを見ています。 git log --since=2026-06-01 --oneline --grep= 'chore(mockup)' | wc -l git log --since=2026-06-01 --oneline --grep= 'docs(requirements)' | wc -l つまり、これは単発の手作業を楽にするための仕組みではなく、今後も繰り返し発生する「content更新」を安全に回すための仕組みでした。 実装の変遷も、最初から完成形だったわけではありません。 2026年6月3日: 非エンジニア向けの /d skillとcontent PR gateを追加 同日: /d をcheckとmergeに分け、mergeを引数不要に変更 同日: Figma / AI Studio exportの取り込みをmergeに内包 同日: developer向けのdev roleを追加し、要件とmockupの両レーンを自動判定 2026年6月4日: recoverコマンドやallowlist検証の強化 2026年6月17日: 一時worktreeベースに変更し、利用者の作業branchを切り替えない形へ補正 2026年7月3日: /d を役割別窓口の /pm と /dsn に分離し、共通処理をcontent-coreへ集約 この履歴から分かるのは、単にGitコマンドをラップしただけでは足りなかったということです。 実際に運用しながら、利用者が覚える手順を減らし、エンジニアが安全性を担保しやすい形へ寄せていきました。 何ができるようになったのか 今回の仕組みでは、役割ごとに触れる領域を分けました。 役割 主に扱うもの コマンド 反映先 branch PM 要件定義書、要求機能一覧 /pm merge content/requirements デザイナー mockup /dsn merge content/mockup エンジニア PM / デザイナーの代行、両レーン対応 /d git-merge 変更内容に応じて自動判定 PMは要件の変更を、デザイナーはmockupの変更を、それぞれ自分の窓口から反映します。 デザイナー向けには、FigmaやAI Studioからexportしたmockupの取り込みも /dsn merge の中に含めました。 別途importコマンドを覚える必要はありません。 新しいexportがあればその場所を伝え、なければ「なし」と答えるだけです。 この設計にした理由は、非エンジニア向けの導線では「手順を増やさない」ことが重要だからです。 便利なコマンドが複数あっても、どの順番で打つのかを覚える必要があるなら、結局Git操作を覚えるのと同じ構造になってしまいます。 利用者から見える体験 初回セットアップでは、GitHub CLIへのログインやリポジトリのcloneは必要です。 この部分は残しています。GitHubに安全にpushするための認証は必要だからです。 具体的には、最初に次のような準備をします。 対象リポジトリへのGitHub招待を受け、write権限を持つ Claude Codeを使える状態にする git と gh をインストールする gh auth login でGitHubにログインする 対象リポジトリをcloneする 例えば、macOSであれば次のような流れです。 brew install git gh brew install --cask claude-code gh auth login gh repo clone < repository > cd < repository > 今回の仕組みで重要なのは、反映用の merge だけを用意することではありませんでした。 実際にチームで使うには、最初に必要なものがそろっているかを確認する導線、しばらく触っていない間にエンジニアが更新したスキルや手順を取り込む導線、途中で止まったときに状態を診断する導線も必要になります。 そのため、利用者に見せる入口は次のように整理しました。 タイミング PM デザイナー 何をするか 初回セットアップ /pm check /dsn check 必要ツール、GitHub認証、push権限、役割設定を確認する 作業前の最新化 /pm sync /dsn sync 最新のmainを取り込み、エンジニアが更新したスキルや手順に追従する 反映 /pm merge /dsn merge 担当領域の変更をcommit、push、PR作成、auto-mergeまで進める 困ったとき /pm recover /dsn recover 状態を診断し、エンジニアに渡せる情報を出す init と呼びたくなる初期化の領域は、今回の実装では check に寄せました。 初回だけ使う入口を別に増やすより、「準備OKかどうかを見る」という言葉に寄せた方が、PMやデザイナーにとって意味が伝わりやすいと考えたためです。 sync も地味ですが重要です。エンジニアが /pm や /dsn の中身を直したり、安全性のチェックを強くしたりしても、利用者がGitのpullやrebaseを理解する必要はありません。 作業前に /pm sync や /dsn sync を実行すれば、最新のmainを取り込み、更新されたレールに乗り直せます。 ここでもpushは行わず、あくまで手元を最新化するだけにしています。 つまり、日々の運用ではGitの詳細を意識しません。 初回だけ、PMまたはデザイナーの窓口で準備状態を確認します。 /pm check # または /dsn check しばらく作業していない場合や、エンジニアがスキル側を更新したあとには、作業前に最新化します。 /pm sync # または /dsn sync 担当ファイルを編集したあとの反映は、mergeだけです。 /pm merge # または /dsn merge 実行後は、反映されたファイル一覧とPR URLが表示されます。 CIが通れば自動でmainに取り込まれます。 裏側で起きていること 利用者からは /pm merge や /dsn merge の1コマンドに見えますが、裏側では複数のGit操作が動いています。 処理の大枠は次の通りです。 PMとデザイナーがGit操作を意識せずPRまで進む処理フロー（図：筆者作成） 特に重視したのは、次の3点です。 1つ目は、一時worktreeを使うことです。 ユーザーの作業branchは切り替えません。PMやデザイナーがmain上で作業していても、反映処理は裏側の一時worktreeで進みます。 これにより、「今どのbranchにいるか」を利用者が意識しなくて済みます。 2つ目は、allowlistです。 PMは要件ディレクトリ、デザイナーはmockupディレクトリだけを反映できます。 対象外のファイルが混ざっていても、スクリプトはそれをcommitしません。 簡略化すると、裏側では次のような考え方で対象を絞っています。 # 実際のコードを説明用に簡略化した例 case " $role " in pm) allow= "docs/product/requirements" ;; designer) allow= "mockup" ;; esac git -C " $worktree " add -- " $allow " git -C " $worktree " diff --cached --name-only 3つ目は、CIで同じ制約をもう一度確認することです。 ローカルスクリプトだけでは、将来の変更や想定外の操作に弱くなります。 そのため、GitHub Actions側でも content/requirements branchは要件ディレクトリだけ、 content/mockup branchはmockupディレクトリだけ、というルールを検証しています。 # 実際の workflow を説明用に簡略化した例 case "$HEAD_REF" in content/requirements) ALLOW="docs/product/requirements/" ;; content/mockup) ALLOW="mockup/" ;; *) exit 0 ;; esac git diff --name-only "origin/${BASE_REF}...HEAD" AIエージェントに任せる部分はありますが、最終的な安全性はpromptの約束ではなく、shell scriptとCIで担保します。 同じ仕組みを作るなら何を実装するか ここまでだと考え方の紹介で終わってしまうので、同じような仕組みを作るなら何を実装すればよいかも整理します。 最小構成は、次のように分けるのが扱いやすいです。 .claude/skills/ pm/SKILL.md dsn/SKILL.md content-core/ scripts/ check.sh sync.sh merge.sh .github/workflows/ content-pr-guard.yml ポイントは、AIエージェント側のskillにGit操作を直接書きすぎないことです。 /pm や /dsn は利用者向けの入口にして、実際のGit操作はshell scriptへ寄せます。 例えば、skill側はこのくらい薄くできます。 # /pm - ` /pm check ` は ` bash .claude/skills/content-core/scripts/check.sh pm ` を実行する - ` /pm sync ` は ` bash .claude/skills/content-core/scripts/sync.sh ` を実行する - ` /pm merge ` は ` bash .claude/skills/content-core/scripts/merge.sh ` を実行する - Gitが途中で止まったら、利用者に直接 ` reset ` や ` stash pop ` を案内せず、エンジニアへ共有する デザイナー向けの /dsn も同じで、roleだけを designer に固定します。 /pm init や /dsn init という名前を用意してもよいですが、今回の実装では「初回に準備OKかを見る」という意味を優先して check に寄せました。 大事なのは名前ではなく、初回検証、最新化、反映、復旧の入口が分かれていることです。 check: 必要ツールと権限を確認する check では、利用者がGitの状態を読めなくても、作業できる前提がそろっているかを機械的に確認します。 #!/usr/bin/env bash set -euo pipefail role= " ${1:?role is required: pm or designer} " ok= 1 pass() { printf ' ✅ %s\n' " $1 " ; } fail() { printf ' ❌ %s\n' " $1 " ; ok= 0 ; } command -v git > /dev/null 2>&1 && pass "git found" || fail "git not found" command -v gh > /dev/null 2>&1 && pass "gh found" || fail "gh not found" git rev-parse --is-inside-work-tree > /dev/null 2>&1 \ && pass "inside git repository" \ || fail "run this in cloned repository" gh auth status > /dev/null 2>&1 \ && pass "gh authenticated" \ || fail "run gh auth login" can_push= " $( gh api 'repos/{owner}/{repo}' --jq '.permissions.push' 2> /dev/null || echo false ) " [ " $can_push " = "true" ] && pass "push permission ok" || fail "no push permission" case " $role " in pm|designer) printf '%s' " $role " > " $( git rev-parse --git-dir ) /content-role" ;; *) fail "unknown role: $role " ;; esac [ " $ok " = "1" ] || exit 1 echo "準備OK。以降は sync / merge を使えます。" ここで .git/content-role のようなファイルにroleを保存しておくと、 merge 側で毎回「PMですか、デザイナーですか」と聞かずに済みます。 sync: エンジニアが更新したレールに追従する sync は地味ですが、運用上かなり重要です。 エンジニアがskillやscriptを更新しても、利用者に git pull や rebase を説明したくありません。 そこで、利用者には /pm sync や /dsn sync だけを見せ、裏側で最新の main を取り込みます。 #!/usr/bin/env bash set -euo pipefail repo_root= " $( git rev-parse --show-toplevel ) " cd " $repo_root " git fetch origin --quiet stashed= 0 if [ -n " $( git status --porcelain ) " ]; then git stash push -u --quiet stashed= 1 fi if ! git rebase origin/main --quiet; then git rebase --abort > /dev/null 2>&1 || true [ " $stashed " = "1" ] && git stash pop --quiet > /dev/null 2>&1 || true echo "最新mainの取り込みで衝突しました。エンジニアに連絡してください。" >&2 exit 1 fi if [ " $stashed " = "1" ]; then git stash pop --quiet || { echo "退避した変更の復帰で衝突しました。エンジニアに連絡してください。" >&2 exit 1 } fi echo "最新mainを取り込みました。pushはしていません。" sync はpushしません。あくまで手元を最新化するだけです。 反映は次の merge に寄せます。 merge: allowlistだけを一時worktreeへ転送する merge が一番重要です。利用者の作業branchは切り替えず、一時worktree上でcontent用branchを作り、担当領域だけをstageします。 説明用に簡略化すると、中心は次のような処理です。 #!/usr/bin/env bash set -euo pipefail repo_root= " $( git rev-parse --show-toplevel ) " git_dir= " $( git rev-parse --git-dir ) " role= " $( tr -d '[:space:]' < " $git_dir /content-role" ) " case " $role " in pm) branch= "content/requirements" allow= "docs/product/requirements" type = "docs(requirements)" ;; designer) branch= "content/mockup" allow= "mockup" type = "chore(mockup)" ;; *) echo "unknown role: $role " >&2 exit 1 ;; esac git fetch origin --quiet base= "origin/main" if git show-ref --verify --quiet "refs/remotes/origin/ $branch " ; then base= "origin/ $branch " fi tmp= " $( mktemp -d ) " wt= " $tmp /worktree" git worktree add --detach " $wt " " $base " --quiet cleanup() { git worktree remove " $wt " --force > /dev/null 2>&1 || true rm -rf " $tmp " } trap cleanup EXIT if [ " $base " = "origin/ $branch " ]; then git -C " $wt " merge --no-edit origin/main fi while IFS= read -r -d '' entry; do xy= " ${entry:0:2} " path= " ${entry:3} " case " $xy " in *D*) rm -f " $wt / $path " ;; *) mkdir -p " $wt / $( dirname " $path " ) " cp -p " $repo_root / $path " " $wt / $path " ;; esac done < < (git status --porcelain -z -uall --no-renames -- " $allow " ) git -C " $wt " add -- " $allow " この時点では、まだcommitしません。 先にstageされたファイルがallowlist配下だけかを確認します。 outside= " $( git -C " $wt " diff --cached --name-only | while IFS = read -r file ; do case " $file " in "$allow"|"$allow"/*) ;; * ) printf '%s \n ' " $file " ;; esac done )" if [ -n " $outside " ]; then echo "対象外の変更が含まれています:" >&2 echo " $outside " >&2 exit 1 fi if git -C " $wt " diff --cached --quiet; then echo "反映する変更はありません。" exit 0 fi ここまで通って初めてcommit、push、PR作成へ進みます。 summary= " $( git -C " $wt " diff --cached --name-only | head -5 | awk 'NR == 1 { out = $0; next } { out = out ", " $0 } END { print out }' ) " git -C " $wt " commit -m " $type : 更新: $summary " --quiet git -C " $wt " push --force-with-lease origin "HEAD: $branch " --quiet if [ " $( gh pr list --head " $branch " --base main --state open --json number --jq 'length' ) " = "0" ]; then gh pr create \ --base main \ --head " $branch " \ --title " $type : 更新" \ --body "content mergeによる自動作成。対象は $allow / のみ。" fi gh pr merge " $branch " --auto --squash gh pr view " $branch " --json url --jq .url この実装で、利用者はbranchを切り替えず、 git add や git push を打ちません。 一方で、GitHub上にはPRと履歴が残ります。 CI: ローカルと同じ制約をサーバ側でも見る ローカルのshellだけに寄せると、将来の変更で抜け道ができます。 GitHub Actionsでも同じallowlistを確認します。 name : content-pr-guard on : pull_request : branches : [ main ] jobs : content-scope-check : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 with : fetch-depth : 0 - name : Check content scope run : | case "${GITHUB_HEAD_REF}" in content/requirements) allow="docs/product/requirements/" ;; content/mockup) allow="mockup/" ;; *) exit 0 ;; esac git diff --name-only "origin/${GITHUB_BASE_REF}...HEAD" | while IFS= read -r file; do case "$file" in "$allow" *) ;; *) echo "out of scope: $file" exit 1 ;; esac done このように、AIエージェントに任せるのは「どの入口を呼ぶか」までに留めます。 安全性は、shell scriptとCIで同じルールを二重に確認します。 なぜこれが嬉しいのか この仕組みで嬉しかったことは、単に「Git操作を自動化できた」ことではありません。 一番大きいのは、PMやデザイナーの成果物を、エンジニアの成果物と同じ流れで扱えるようになったことです。 履歴・レビュー・CIの対象として確認できます。 これまでは、要件やmockupの受け渡しが次のようになりがちでした。 Slackにファイルを貼る zipを共有する 「最新版はこちらです」と口頭で伝える エンジニアが手元で取り込んでcommitする この形だと、どれが最新版なのか、いつ何が変わったのか、なぜその変更が入ったのかが追いにくくなります。 エンジニアが代理でcommitする場合も、変更の主体とGitHub上のauthorがずれやすくなります。 今回の仕組みでは、PMやデザイナーが自分の作業として変更を反映できます。 PRが残るため、後から差分を確認できます。 CIも通るため、対象外ファイルやsecret混入を防げます。 PMやデザイナーにとってのモチベーションは、「GitHubを使えるようになること」そのものではありません。 自分が責任を持つ成果物を、自分の作業として履歴に残せることです。 PMであれば、要件変更の背景や優先順位を、実装と同じ場所で追えるようになります。 あとから「この要件はいつ、どの判断で変わったのか」を確認しやすくなります。 デザイナーであれば、mockupの更新をzipや画像共有で終わらせず、実装側が追える変更として渡せます。 「この画面を更新しました」という連絡だけでなく、GitHub上のPR URLを起点に会話できます。 使ってみて感じたのは、価値の中心が「Git操作が簡単になった」ことよりも、「変更の置き場所がチームでそろう」ことにあるという点です。 Gitの知識が少ない人でも、PRという同じ単位で変更を共有できると、会話が「誰が取り込むか」から「何が変わったか」「どう確認するか」に移ります。 エンジニアにとってもメリットがあります。 非エンジニアの作業を毎回手作業で取り込む必要が減ります。 さらに、取り込まれた変更はPRとして見えるため、必要なときにレビューできます。 GitHub上に履歴が残るので、後から実装との対応関係も追いやすくなります。 実際の利用者コメント この記事では、仕組みを作った側だけでなく、実際に使う側の目線も入れたいと考えました。 そこで、PMやデザイナーに「本プロジェクトでGit操作をしてみた感想」を一言ずつもらいました。 次の画像では、氏名、アイコン、メンション、投稿時刻をマスキングしています。 PMとデザイナーからもらった利用者コメントのスクリーンショット（図：利用者コメントをもとに筆者作成） この画像を入れる目的は、「便利になりました」という感想を載せることだけではありません。GitHub上に変更を届ける体験が、PMやデザイナーにとって本当に本来業務の邪魔にならないかを見るためです。 Git操作を覚えることが目的になってしまうと、非エンジニアにとっては負担が増えます。一方で、「自分の成果物を自分の責任範囲で届けられる」「変更の所在がチームで共有される」という実感があれば、GitHubを使う理由が自然に伝わります。 AI エージェント時代の非エンジニアの作業はどう変わるのか AIエージェントが入ると、非エンジニアができることは増えます。 以前なら、GitHubに変更を載せるにはGitの操作を覚える必要がありました。今は、AIエージェントに「この変更を反映して」と依頼すると、裏側でコマンドを実行できます。 ただし、ここで大切なのは「非エンジニアもエンジニアと同じことを全部やる」ことではないと考えています。 PMは、要件の妥当性、業務上の優先順位、ユーザー価値に責任を持つ。 デザイナーは、画面体験、情報設計、操作性、表現品質に責任を持つ。 エンジニアは、実行境界、権限、CI、rollback、保守性に責任を持つ。 AIエージェントは、その間にある手作業や翻訳作業を支援する。 この分担を崩さないことが重要です。AIエージェントが使えるからといって、PMやデザイナーにconflict解消やbranch戦略の判断まで任せる必要はありません。逆に、エンジニアがすべてを代行し続ける必要もありません。 役割の境界を曖昧にするのではなく、それぞれが責任を持つ領域を明確にした上で、境界をまたぐ作業をAIエージェントに手伝ってもらう。この考え方が、今回の取り組みの中心にあります。 エンジニアとして気をつけたこと 非エンジニア向けの仕組みを作るとき、つい「簡単にする」ことばかり考えがちです。 しかし、簡単に見える導線ほど、裏側の安全設計が必要です。 今回、特に気をつけたことは次の4つです。 1つ目は、対象ディレクトリの外を絶対に反映しないことです。 AIエージェントへの指示だけで「対象外は触らないで」と書いても十分ではありません。誰であっても間違える可能性があります。そこで、スクリプトでは対象だけをstageします。CI側でも対象外変更を落とすようにしました。 2つ目は、利用者にGitの復旧操作をさせないことです。 stash 、 checkout 、 reset 、 rebase --abort などは、慣れていない人にとって危険です。途中で止まったときは、利用者が自分で直す必要はありません。診断結果をエンジニアへ渡せるようにしました。 3つ目は、手順を増やさないことです。 デザイナー向けにはmockup exportの取り込みもmergeに含めました。アーカイブ、import、commit、pushのようにコマンドを分けすぎると、利用者は結局オペレーションを覚える必要があります。 4つ目は、エンジニア向けの代行ルートも用意することです。 PMやデザイナーだけでなく、エンジニアが要件やmockupの反映を代行する場面もあります。そのときに通常の開発branchから直接対象ディレクトリを触ると、CIの条件や必須チェックの設計と衝突することがあります。そのため、エンジニア用の /d git-merge も同じcontent branch経由に寄せました。 作りながら感じたこと この取り組みを進めていて感じたのは、AIエージェントによって「誰がリポジトリに変更を届けられるか」の範囲が広がっているということです。 これまでは、GitHubに変更を載せること自体がエンジニア寄りの作業でした。今後は、PMが要件を更新し、デザイナーがmockupを更新し、それが自然にPRとして現れる状態が増えていくと思います。 一方で、AIエージェントがいるからこそ、エンジニアリングの重要性はむしろ上がります。 自然言語で依頼できる体験を作るには、裏側に明確な実行境界が必要です。どのファイルを触ってよいのか。どのbranchにpushしてよいのか。どのCIを通すのか。失敗したときに誰が対応するのか。 こうした境界を設計するのは、やはりエンジニアの仕事です。 AIエージェント時代のチームワークでは、エンジニアがすべてを直接作業するのではなく、他の職種が安全に作業できるレールを作る場面が増えるのではないかと思います。 今後やりたいこと 今後は、次のような改善が考えられます。 PR上のレビューコメントをもとに、AIエージェントが修正候補を出す mockupと実装の差分を自動で検出する 要件変更と実装タスクの対応関係を追えるようにする テックブログやドキュメント更新にも同じ考え方を広げる 特に、mockupと実装の差分検出は重要です。デザイナーがmockupを更新できるようになると、次に必要になるのは「その変更が実装に反映されたか」を追う仕組みです。GitHubに変更履歴が残っていれば、そこを起点に自動レビューや差分検出を組み合わせやすくなります。 まとめ PMやデザイナーがGitを知らなくてもGitHubに変更を届けられるようにする取り組みを紹介しました。 今回実現したことは、Gitを使わない世界ではありません。 むしろ、Gitの履歴、PR、CI、レビュー可能性を活かすために、Git操作の難しさをAIエージェントとスクリプトの裏側へ移した取り組みです。 AIエージェントは、非エンジニアの作業範囲を広げます。ただし、そのためには安全な実行境界が必要です。 AIに任せる部分と、shell scriptやCIで機械的に守る部分を分けることで、チーム全体がGitHubをより自然に使えるようになります。 Gitを覚えてもらうのではなく、Gitの価値をチーム全員が使えるようにする。 今回の仕組みは、そのための小さな一歩だったと思います。

はじめに こんにちは、Insight Edge の日下です。 ここ最近のコーディングAIエージェントの進化は目覚ましく、以下のような光景が当たり前になってきました。 プロダクトオーナーやUXデザイナがAIツールでプロトタイプを作る 議事録・仕様書・設計メモといったドキュメント系の成果物もAIで作成しgitで管理する 特にバイブコーディングの広がりで、エンジニア以外もソースコードの形で成果物を作ることが増えました。弊社では AIが文脈を理解しやすいように、プロダクトのソースコードだけでなくデザイン成果物や設計ドキュメント、意思決定の経緯などもGitやGitHubに集約しています 。こうしてソースコードとドキュメントの両面から、 Gitリポジトリを触るエンジニア以外のメンバー が増えてきています。 このとき、従来からGit/GitHubを使うエンジニア側と、新たに使い始めた側のそれぞれに悩みが生まれます。 エンジニア側 — 開発フローの説明や救援作業（作業支援、誤コミットの修正）など、エンジニア以外のメンバーが慣れるまでサポート負荷が高くなる 開発に参加するメンバー側 — Git/GitHubの作法や開発フローを学ぶ負担と、それを意識することによるアイデア具現化スピードの鈍化 「AIに任せればベストプラクティスが守られるのでは？」と思いきや、そうでもありません。最近のAIモデルはGitやGitHubの良い作法を知っていますし、インターネットを探せば素晴らしいスキルも多々あります。しかし、開発するプロダクトの特徴やフェーズ、チームの大きさなどに応じて、現場に適した開発フローは様々であり、そこに開発チームの工夫が表れます。だからこそ、 自分のチームに適した開発手順を言語化してスキルに固める 必要がありました。 本記事では、エンジニア以外のメンバーも含む開発チームで、バイブコーディングの速さや気軽さも尊重しつつ、GitやGitHubをお行儀よく活用した開発フローを実現するために私が作り育てたClaudeスキルを題材に、その設計思想と中身、実際の使い勝手を ニールセンのユーザビリティ10原則 に照らし合わせて紹介します。 ※本記事は Claude Code の Skill 機能 を前提としています。また、 /d の動作には git コマンドと GitHub CLI （ gh コマンド）がセットアップ済みであることが必要です。 目次 はじめに 設計の3本柱 /d スキルの構造 動かしてみる：2つの典型シナリオ スキル改善の経緯と考え方 おわりに 設計の3本柱 /d の d は develop からとっています。 このスキルの設計には3つの軸があります。共通するのは、 作業者が意識して開発フローに合わせるのではなく、スキルを使っているだけで自然にルールを守れる という発想です。 A. バイブコーディングの手を止めない アイデアを高速に具現化する人の手を、複雑な開発プロセスで遅くしない。 お行儀のためのチェックリストや規約を増やすほど、利用者は「考える前に手順を思い出す」モードに入ります。これは思いつきを高速に形にするUXデザイナやプロダクトオーナーには致命的です。 /d スキルは 思考のリズムを止めない ことを最優先にします。 具体的には、手順を覚えてもらうのではなく スキル側がすべて代行する 設計にしました。たとえば、利用者が /d issue 42 と打つことでIssueに着手するときの定型作業を実行し、作業ブランチ作成・push・方針コメント投稿まで自動で走ります。 B. 使いながらGit/GitHubの作法に慣れる 細かい作法を習ってから使うのではなく、使いながら徐々に作法を体得する。 ブランチ・コミット・PR・rebase…とGitの概念を最初に全部説明されると、それだけで利用者は挫折します。一方で「教えなくていい」とすると、利用者はずっと作法を知らないまま、エンジニアの救援が必要な状態が続きます。 /d スキルは 「必要最低限のコマンドを使うだけで、結果としてお行儀よく作業できていた」 状態を作りつつ、 裏で何が起こったかは可視化する 設計にしました。 /d issue 実行時に「ブランチを作りました」「PRを作成しました」とログが出るので、利用者は使い続けるうちに「これはブランチを切っていたのか」「これがDraft PRか」と自然に理解していきます。また、issueやcommitなど重要な用語はGit/GitHubのエコシステムに合わせることで、エンジニアと同じ言語で開発に参加できるようにしています。 C. 覚えなければならない知識を減らす 使う側が頭の中に抱える「知識量」をできる限り減らす。 利用者の負担は 「次に何のコマンドを打つか」「どのスキルを呼ぶか」を毎回思い出すこと にあります。これを減らすために2つの仕掛けを入れました。 個別スキルではなくサブコマンド方式 — /d todo /d issue /d commit …といった操作を /d 1つのスキルに統合することで、利用者は最低限 /d だけ覚えればよく、 /d 42番のIssueに着手 のように自然言語で意図を伝えるだけでも適切なサブコマンドが実行されます 次のアクションは選択肢で提示 — スキル実行の終わりには必ず次の候補を出すことで、利用者は「次に何をすればよかったっけ」と考えずに済みます（後述する「再生より再認」） 結果として、利用者が頭に抱える「Git作法 + コマンド体系 + チーム運用ルール」の知識セットが大幅に圧縮されます。 覚えるべきは /d という入口だけ という状態が、参加ハードルを最小化します。 /d スキルの構造 スキル本体は ~/.claude/skills/d/SKILL.md 1ファイルです。フロントマター + サブコマンドごとの手順記述で構成されます。全文は以下に折りたたんで載せておきます。 SKILL.md 全文（クリックで展開） --- name: d description: GitHub Issue・Pull Request・ブランチ操作・コミット等の作法を定義した開発ワークフロースキル argument-hint: " < todo |new|issue|commit|pr|review|improve|help> [args...]" allowed-tools: Bash, Agent, Read --- GitHub を起点とした開発ワークフローをサブコマンドを指定して実行する。引数なしで ` /d ` と実行された場合は ` /d help ` として動作した上で、次の行動を提案する。 サブコマンドが指定されずに文が続く場合（例: ` /d 42番のIssueに着手して ` ）は、テキスト内容から利用者の意図を解釈し、適切なサブコマンドにマッピングして実行する。利用者は厳密なサブコマンド名を覚えていなくてもよい。 ## 出力ルール ### yes/no 質問 AIによる「〜してよいですか？」「〜しますか？」のような closed questionや許可確認の末尾には ` (y/n) ` を付け、ユーザの回答負荷を軽減する。「他に修正はありますか？」のような実質的Open Questionには付けない。 ### 表・箇条書きへの識別子付与 表・箇条書き・選択肢など、複数項目が並ぶ出力には必ず連番や記号の識別子を振る。Issue番号やPR番号など既存の識別子がある場合はそれを使い、無い場合は左端に ` No ` 列を追加する。これにより、後の会話でユーザが番号で行を指定できるようにする。 ### 次のアクションの提示 サブコマンドの終わりには、可能な限り次のアクションの候補を選択肢として提示する。利用者に「次に何をすればよいか」を思い出させるのではなく、提示された選択肢から選ばせる（再生より再認）。 ## 不満・改善提案の案内 利用者が ` /d ` スキルの挙動に不満を表明した場合: ` /d improve <内容> ` でスキル改善Issueを起票する。 ## 共通ルール ### 並列実行 依存関係のない複数のコマンド・API呼び出しは常に並列実行する。逐次実行しない。独立したコマンドを見つけたら積極的に並列化する。 ### ブランチ切り替え前の確認 ` git checkout ` の前に ` git status --porcelain ` で未コミット変更を確認する。変更がある場合は選択肢を提示: 1. **コミットして続行** 2. **worktree で並列作業** — ` git worktree add ../<リポ名>-<新ブランチ> -b <新ブランチ> origin/main ` → 別セッションを案内 3. **中断** ### main 最新取り込み 作業ブランチで ` /d issue ` （既存ブランチ checkout 時）または ` /d commit ` （push 前）に実行する。originのmainブランチに対する遅れを確認し、遅れがあれば ` git merge origin/main ` を提案する。 ### ブランチ命名規則 ` CLAUDE.md ` に命名規則の定義があればそれに従う。なければデフォルトとして ` <prefix>/<issue番号>-<英語kebab-case 5語以内> ` を使用する。prefix はIssueのラベル・内容から判断: - ` feat/ ` — 新機能 - ` fix/ ` — バグ修正 - ` nf/ ` — 非機能（インフラ等） - ` doc/ ` — ドキュメント - ` process/ ` — 開発プロセス関連（CI、Claudeスキル等） - ` misc/ ` — その他 Issue 番号がない場合は ` <prefix>/<英語kebab-case 5語以内> ` とする。 ### PR マージ確認 PR が Ready かつ最新コミットに対するレビューでマージ可能と判定されている場合、 ` gh pr merge <PR番号> --merge --delete-branch ` を提案する。適用タイミング: ` /d commit ` で Ready PR 作成後、 ` /d review ` で Ready 化後、 ` /d pr ` で Ready 化後。 ### レビュー実行 レビューは **Claude のレビュー用サブエージェント** で実行する。実装したコンテキストとは別のサブエージェントで実行することで、客観的な指摘を得る。 他人の PR をレビューする場合は先に対象ブランチを取得する。 チェックアウト前に元ブランチ名を退避し、ダーティーツリーでないことを確認する: ```bash ORIG_BRANCH=$(git branch --show-current) git status --porcelain # 出力ありなら未コミット変更あり ``` 未コミット変更がある場合は「ブランチ切り替え前の確認」を適用する。クリーンな状態を確認したら既存ローカルブランチを破壊しない方法で取得する: #### レビュー手順 1. ` COMMIT_SHA=$(git rev-parse HEAD) ` で SHA を取得。 ` git fetch origin main ` 後、 ` git diff origin/main...HEAD ` + ` git log origin/main..HEAD --oneline ` を取得。 ` OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) ` で owner/repo も取得 2. Agent ツールでレビュー用サブエージェントを起動する（ ` run_in_background: true ` ）。プロジェクトの設計基準やレビューガイドライン（ ` CLAUDE.md ` 、レビュー用エージェント定義、 ` docs/ ` 配下のガイドライン等があれば参照）に従ってレビューさせる。プロンプトに ` diff ` , ` commits ` , ` commit_sha ` , ` owner_repo ` , ` pr_number ` , ` pr_author ` , ` is_own_pr ` , ` is_draft ` , ` post_to_pr=false ` , ` defer_ready=true ` を渡す 3. 完了を待ち、結果を会話に表示（指摘一覧 + 総合判定） 4. 自分の PR の場合は各指摘の妥当性を評価する 5. ` post_to_pr=true ` の場合は次の「PR への投稿」を実行 #### PR への投稿 ( ` post_to_pr=true ` ) skill 側で投稿する（レビュー用サブエージェントは二重投稿回避のため ` post_to_pr=false ` ）: - **総評コメント**: ` gh pr review <PR番号> --comment --body "<本文>" ` （自分の PR）/ ` --approve ` / ` --request-changes ` （他人の PR） - **インラインコメント**: ` gh api repos/{owner}/{repo}/pulls/<PR番号>/comments ` を使用。各コメントに ` commit_id ` (= ` COMMIT_SHA ` ), ` path ` , ` line ` , ` side ` が必須 投稿後、自分の Draft PR でマージ可能（高指摘なし）なら Ready 化: 1. PR タイトルから ` WIP: ` 削除 2. 本文を ` Summary / Related Issue / Test plan ` テンプレートに更新（ ` Closes ` / ` Refs ` は「Related Issue とクローズ判定」に従う） 3. ` gh pr ready <番号> ` ### 変更確認 ` git status --porcelain ` 、 ` git diff ` 、 ` git diff --cached ` を3つ並列実行する。変更がなければエラー。 ### ステージング判断 以下の懸念がないか確認する: - ` .env ` 、クレデンシャル系（ ` credentials.json ` 、 ` cred-* ` 、 ` *.pem ` 、 ` *.key ` 等） - ` .gitignore ` すべきファイル（ ` node_modules/ ` 、 ` dist/ ` 、 ` __pycache__/ ` 、 ` .venv/ ` 等） - ブランチ名から推測される作業内容と無関係なファイル 懸念がなければ全ファイルを自動ステージング（確認不要）。懸念があれば明示してユーザーに確認する。 ### コミットメッセージ生成 変更内容から日本語で簡潔に自動生成する（確認不要）。ブランチ名に Issue 番号があれば ` #<番号> ` を含める。 ## サブコマンド ### ` /d todo ` 自分が対応すべきものを表示する。 現在作業中のタスクがあるかどうかと、GitHub上でアサインされたIssue、メンション、レビュー依頼を確認する。 1. **2つを並列実行**: - (A) gitコマンドで現在の作業状況を確認 ` git fetch origin && git branch --show-current && git status --porcelain ` - (B) ghコマンドでGitHubを確認。GraphQL で一括取得: ```bash OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) gh api graphql -f query="{ assignedIssues: search(query: \"repo:${OWNER_REPO} assignee:@me is:open is:issue\", type: ISSUE, first: 20) { nodes { ... on Issue { number title labels(first: 5) { nodes { name } } updatedAt } } } reviewRequested: search(query: \"repo:${OWNER_REPO} review-requested:@me is:open is:pr\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number title author { login } updatedAt } } } mentions: search(query: \"repo:${OWNER_REPO} mentions:@me is:open\", type: ISSUE, first: 20) { nodes { ... on Issue { number title updatedAt } } } myOpenPRs: search(query: \"repo:${OWNER_REPO} is:open is:pr author:@me\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number headRefName isDraft } } } }" ``` 2. **fetch 完了後の確認**: - 現在のブランチが main なら ` git rev-list HEAD..origin/main --count ` で同期状態を確認。作業ブランチなら ` gh pr view --json number,title,state,mergedAt,url ` で PR 状態を確認 - アサイン済み Issue について ` git branch -r ` を1回実行し、各 Issue 番号に対して ` origin/*/<issue番号>-* ` のパターンでブランチを探す → ` myOpenPRs ` から PR 有無を判定 → 未着手 / ブランチあり / PR #番号 (Draft|Ready) 3. **出力フォーマット**: ``` ## 現在のブランチ - ⚠️/✓/🔧 の状態表示 ## アサイン済み Issue | # | タイトル | 状態 | ラベル | 更新日 | ## レビュー依頼 | # | タイトル | 作成者 | 更新日 | ## メンション | # | タイトル | 更新日 | ``` 4. **次のアクション提案**: 優先度の高い順に次にやるべき作業を提案する。「main に戻りましょう」は提案しない（作業ブランチで ` /d issue ` を実行すれば自動的に origin/main ベースのブランチが作成されるため） ### ` /d new <タイトル> ` 新しい Issue を起票する（自分が取り組むとは限らない）。 1. 引数を要約してタイトルにする（なければユーザーに聞く） 2. ` gh issue list --state open --json number,title ` で既存の類似 Issue をチェック 3. 説明文の案を生成してユーザーに提示（経緯・現状・期待効果を含める） 4. ` gh label list --json name,description ` で適切なラベルを判定 5. ` gh issue create --title "..." --body "..." --label "..." ` で作成 6. URL を表示 7. **次のアクションを必ず選択肢として提示**（省略不可）: 1. 自分をアサインして今から取り組む → ` /d issue ` の処理を続行 2. 自分をアサインして作業に戻る → ` gh issue edit <番号> --add-assignee "@me" ` のみ 3. 他の人をアサインする（対象者を指定） 4. アサインせず終了 ### ` /d issue <番号またはURL> ` （エイリアス: ` /d i ` ） 既存 Issue に自分が取り組む。ブランチ作成・プッシュで着手を宣言してから方針コメントを投稿する。 1. Issue 番号を特定し、内容取得 + 自分をアサイン: ```bash gh issue view <番号> --json title,body,labels,assignees gh issue edit <番号> --add-assignee "@me" ``` 2. ` git fetch origin && git branch -a --list "*/<issue番号>-*" ` で既存ブランチを確認: - **あり**: 他人のコミットがあればユーザーに確認。なければチェックアウト + 「main 最新取り込み」を実行 - **なし**: Issue からブランチ名を生成（「ブランチ命名規則」参照）。**確認不要で** 作成・push する: ```bash git checkout -b "<prefix>/<番号>-<説明>" origin/main git push -u origin HEAD ``` 3. 方針・実装計画をユーザーに提示 → 承認後 ` gh issue comment ` で投稿（投稿の確認不要） **ここがポイント**: ブランチを push してIssueコメントを残すことで、他メンバーに「自分が #<番号> に着手中」が見えるようになる。重複着手を未然に防ぐ。 ### ` /d commit ` 変更をコミット・プッシュし、PR が未作成なら Draft PR も作成する。 **ブランチ判定:** - **`main` の場合**: 変更内容から prefix を判断し、ブランチ名を生成 → ` git checkout -b "<prefix>/<説明>" ` → 次の手順へ - **作業ブランチの場合**: そのまま次の手順へ **手順:** 1. 変更確認（共通ルール） 2. ステージング判断（共通ルール） 3. ブランチ名から Issue 番号を抽出（ ` feat/123-xxx ` の ` / ` の後の数字） 4. コミットメッセージ生成 → ` git add && git commit ` 5. main 最新取り込み（共通ルール） 6. ` git push -u origin HEAD ` 7. ` gh pr list --head <ブランチ> --json number,title,isDraft,url,author ` で PR 確認 8. **レビュー実行**（ ` is_own_pr=true ` , ` post_to_pr=true ` ）: - **PR がない場合**: ` /d pr ` に従ってDraft PR 作成 → レビュー実行 — 初回レビューは精度優先 - **PR が既存の場合**: 追加コミットの差分をレビュー 9. PR マージ確認（共通ルール） 10. 結果表示: コミットハッシュ・メッセージ、プッシュ先、PR URL、レビュー結果 ### ` /d pr ` Pull Requestを作成。または、作成済のPRに対して必要なアクションをする。 1. ブランチが ` main ` ならエラー 2. ` gh pr view --json number,title,isDraft,url ` で既存 PR 確認 3. **PR あり**: PR コメント確認 → 未対応あれば対応 4. ` git fetch origin main ` → ` git log origin/main..HEAD --oneline ` + ` git diff origin/main...HEAD --stat ` で差分取得 5. PR タイトル（70文字以内）と本文を生成（ ` 概要 / 関連Issue / やったこと / やっていないこと ` 。 ` 関連Issue ` は共通ルールに従い ` Closes ` / ` Refs ` ） 6. ` git push -u origin HEAD ` → PR なしなら Draft 作成、あればタイトル・本文を更新 7. レビュー実行（ ` is_own_pr=true ` , ` post_to_pr=true ` , ` effort=high ` ）→ 結果表示 8. URL 表示 9. PR マージ確認（共通ルール） ### ` /d review ` 作業ブランチの変更をレビュー。PR があればレビューとして投稿可能。 1. ブランチが ` main ` ならエラー 2. ` gh pr view --json number,title,url,isDraft,author ` で PR 確認。 ` gh api user --jq .login ` と ` author.login ` を比較して ` is_own_pr ` を決定 3. レビュー実行（ ` is_own_pr=<判定> ` , ` is_draft=<取得値、なければtrue> ` , ` post_to_pr=false ` , ` effort=high ` ）→ 結果表示 4. **PR あり**: 投稿するか確認 → 投稿する場合は「PR への投稿」を実行（ ` post_to_pr=true ` ）。Draft かつマージ可能なら Ready 化が走る 5. PR マージ確認（共通ルール） ### ` /d improve <改善内容> ` ` /d ` スキル自体の改善提案を Issue 起票する。 1. 引数があればそれを改善内容にする。引数がない場合は直前の会話の文脈（不満や違和感の表明、うまくいかなかった操作など）から推測する 2. 改善内容をもとに簡潔な Issue タイトル（日本語）を生成 3. Issue を作成: ```bash gh issue create --title "<タイトル>" --body "$(cat <<'EOF' ## 改善内容 <スキル改善内容> ## 代替案 <claudeの設定など、スキル自体の改善以外で実現可能な代替案> EOF )" ``` 4. 作成した Issue の URL を表示 ### ` /d help ` 以下をそのまま出力する: ``` ## 開発プロセス ### (1) アサインされたタスクに取り組む 1. `/d` で自分のタスクを確認する 2. `/d issue <番号>` で Issue に着手する（アサイン→ブランチ作成→方針コメント） 3. 実装する 4. `/d commit` でコミット・プッシュ・PR作成 5. `/d review` でレビュー・Ready化 ### (2) 新しい課題を起票する `/d new <タイトル>` で Issue を作成する。自分で取り組むかどうかはその場で選択できる。 ### (3) Issue を立てずに実装する 1. 実装する（main ブランチ上でも `/d commit` が自動でブランチを作成する） 2. `/d commit` でコミット・プッシュ・PR作成 3. `/d review` でレビュー・Ready化 ### (4) このスキルの改善リクエスト `/d improve <不満点や改善案>` で改善提案を Issue 起票する。 ## コマンド一覧 | コマンド | 説明 | |---|---| | `/d` | `/d help` と同じ（サブコマンド省略時） | | `/d todo` | 自分のアサインタスク・メンション・レビュー依頼を一覧 | | `/d new <タイトル>` | 新規 GitHub Issue を起票 | | `/d issue <番号>` (`/d i`) | 既存 Issue に着手（アサイン→ブランチ作成→方針コメント） | | `/d commit` | コミット→push→Draft PR作成→AIレビュー | | `/d pr` | PR 作成・更新 | | `/d review` | 作業内容のレビュー | | `/d improve <内容>` (`/d imp`) | スキル自身の改善提案を Issue 起票 | | `/d help` | このヘルプを表示 | ## ヒント - 厳密なサブコマンド名を覚えていなくても、`/d 42番のIssueに着手して` のように自然言語で指示すれば適切なサブコマンドが実行される - 困ったら `/d` だけ打って、表示された選択肢から選べばよい ``` サブコマンド一覧 サブコマンド 役割 /d （引数なし） /d help と同じ /d todo 自分のアサインタスク・メンション・レビュー依頼を一覧 /d new <タイトル> 新規Issueを起票 /d issue <番号> 既存Issueに着手（アサイン→ブランチ作成→push→方針コメント） /d commit コミット→push→Draft PR作成→AIレビュー /d pr PRの作成・更新 /d review 作業内容のレビュー /d improve <内容> スキル自身の改善提案をIssue起票 /d help 全コマンド一覧と典型フローを表示 個別スキルではなくサブコマンド方式にしたことで、利用者は 「困ったら /d に続けてやりたいことを伝える」だけ で、スキルで規定したルールに則れます。 主役は /d todo / /d issue / /d commit / /d review の4つ 主役サブコマンドは、 作業者がもともと意識している作業アクション に対応します。 自分のタスクを確認する 着手する 成果物を提出する レビューする いずれも Git/GitHubとは無関係に作業過程に存在するアクション です。これらを主役に据え、ブランチ作成・PR作成・mainブランチ取り込みといったGit/GitHub起因の操作は内側に隠してAIが自動化します。 さらに /d todo はIssueのアサイン情報に基づいて着手すべきIssueを提案し、 /d commit はコミットからPR作成、AIレビューまでまとめて実行するため、 典型フローで利用者が実際に打つのは /d todo → /d commit の2つで済むことも多い です。 動かしてみる：2つの典型シナリオ 入口は2通りありますが、 どちらも最後は /d commit に合流し、PRベースの開発フローが進む のがポイントです。 シナリオA：Issue駆動で開発を進める場合 UXデザイナの佐藤さんに「ログイン画面の入力欄の余白を調整してほしい」という Issue #58 がアサインされた。 Step 1: /d todo で確認し、そのまま着手する > /d todo スキルは「現在のブランチ・アサイン済みIssue・レビュー依頼・メンション」を並列取得して整形表示し、 最後に「次に何をすべきか」まで提案します 。 ## 現在のブランチ - ✓ main（クリーン） ## アサイン済み Issue | # | タイトル | 状態 | ラベル | |----|---------------------------------------|--------|--------| | 58 | ログイン画面の入力欄の余白を調整したい | 未着手 | feat | （レビュー依頼・メンションはありません） --- 未着手の Issue が1件あります。優先度の高い #58 から着手しますか？ （アサイン → ブランチ作成 → push → 方針コメント まで実行します） (y/n) /d todo は一覧を並べて終わりではなく、 「未着手の #58 から着手しますか？」と次の一手まで提案 します。利用者は表を眺めて「次に何をしよう」と考える必要がありません。ここで y と答えれば、着手処理がそのまま走ります。 # 「はい」と答えた後にスキルが実行する内部処理 gh issue edit 58 --add-assignee "@me" git checkout -b "feat/58-login-margin" origin/main git push -u origin HEAD gh issue comment 58 --body "<実装方針>" ブランチがpushされた瞬間、GitHubの他メンバーには「佐藤さんが #58 着手中」が見えます。 これだけで重複着手を大きく減らせます。 着手の入口は2通り、どちらでもよい — Issue番号が最初からわかっているなら、 /d todo を経由せず /d issue 58 を直接打っても同じ着手処理に入ります。「 /d todo の提案に乗る」か「 /d issue を直接打つ」かは、利用者が好きな方を選べます。 Step 2: 実装 → /d commit 佐藤さんはClaude Codeに実装を任せ、完了したら /d commit を実行。 コミット → push → Draft PR → AIレビュー → Ready化 → マージ → Issueクローズ までが一気に流れます。 結局、利用者が打つのは /d todo （提案に乗って着手）→ /d commit の実質2コマンドだけ。ブランチ名やコミットメッセージ、PR本文を書く場面はありません。 補足：Issueがまだ無いときは /d new で起票する シナリオAはアサイン済みの Issue #58 から始めましたが、そもそも取り組みたいことがまだIssueになっていないこともあります。その場合は /d new に概要を渡すだけで起票できます。 > /d new ログイン画面の入力欄の余白を調整したい スキルは既存の類似Issueを確認したうえで、タイトル・説明文・ラベルの案を生成して起票し、作成後に 「誰が取り組むか」を選択肢で提示 します。 Issue #59 を作成しました： https://github.com/<owner>/<repo>/issues/59 続けてどうしますか？ 1. 自分をアサインして今から取り組む（そのまま着手処理へ） 2. 自分をアサインして後で取り組む 3. 他の人をアサインする 4. アサインせず終了 1 を選べば、そのまま /d issue 相当の着手処理（アサイン → ブランチ作成 → push → 方針コメント）に流れます。 「起票 → 着手」がコマンドを打ち替えずに一本でつながる のがポイントです。起票だけして他の人に任せたい（ 3 ）、あとで自分でやる（ 2 ）といった分岐も、その場で選ぶだけで済みます。 また /d new は、機能追加のようなきちんとしたIssueだけでなく、 「このドキュメントを直してほしい」「Claudeのスキルを修正して」といったちょっとした作業依頼 にも気軽に使えます。口頭やチャットで流れがちな細かい依頼もIssueとして残り、依頼のハードルが下がります。さらに 受けた側が /d issue で着手するときには、AIがIssue本文（背景・経緯・期待する結果）を文脈として読み取れます 。チャットの断片的なやり取りと違い、要件がまとまっているぶん、AIは意図を汲んだ実装や方針コメントを返しやすくなります。これは冒頭で触れた 「AIが文脈を理解しやすいようにGit/GitHubへ集約する」 流れに、気軽な起票がそのまま乗る形です。 シナリオB：Issueを立てず、思いついた改善案をいきなり作り始める場合 UXデザイナの佐藤さんは、ふと思いついたUIの改善案をその場でClaude Codeに作らせてみた。Issueも立てず、ブランチも main のままローカルに修正案ができあがっている。仕上がりが良かったので、そのまま /d commit を実行する。 > /d commit このとき、スキルは変更内容を確認し、 変更内容から適切なブランチ名（ fix/update-signup-form-warning-message など）を判断 自動でブランチを切ってから コミット そのブランチをpushし、Draft PRを作成 続けて AIレビューが走り 、変更内容に問題がなければReady化 シナリオAと同じく、 /d commit の先はDraft PR作成からAIレビュー・Ready化まで一気に流れます。佐藤さんは「ブランチを切り忘れた」「Issueを立て忘れた」と慌てる必要がなく、思いついた改善案を形にすることだけに集中できます。 「アイデアを止めずに作り、後から正しい形に整える」 ── バイブコーディングのリズムを保ったまま、結果的にお行儀の良い形に着地します。 スキル改善の経緯と考え方 /d は最初から今の姿だったわけではありません。初期はもっと細かく「ブランチを作る」「Pull Requestを作る」といった Gitの操作にも1つずつコマンドを紐づけており、個々の操作をAIで補完しているだけでした。エンジニアにとっては違和感がなくとも、エンジニア以外の利用者から見ると どのコマンドを打つか選ぶ時点でGitの知識が必要 で、開発フローの作法を覚える負担が残っていました。 そこで 「ツールではなく目的中心でスキルのあり方を決める」 ことを強く意識し、使いやすさを追求して改善を重ねました。判断軸として参照したのが、UX設計の古典である ヤコブ・ニールセンのユーザビリティ10原則 です。スキル開発は「自分が便利な機能を足す」方向に流れがちですが、10原則に照らすことで「これは利用者目線の仕様になっているか？」を問い直せました。 10原則は以下のとおりです（和訳は本記事での表記）。 Visibility of system status / 状態の可視性 Match between the system and the real world / 現実世界との調和 User control and freedom / ユーザーコントロールと自由 Consistency and standards / 一貫性と標準 Error prevention / エラー予防 Recognition rather than recall / 再生より再認 Flexibility and efficiency of use / 柔軟性と効率性 Aesthetic and minimalist design / 最小限デザイン Help users recognize, diagnose, and recover from errors / エラー回復 Help and documentation / ヘルプとドキュメンテーション この章では、特に大きく効いた 4つの改善 を、対応する原則とともに紹介します。 改善1：コマンドを「Git操作」から「作業アクション」へ（原則2 現実世界との調和） 最大の改善が、コマンド体系そのものの組み替えです。 Before — ブランチ作成・コミット・PR作成…と、Git/GitHubの操作を利用者が1つずつ呼び出す体系 After — /d todo （見る）・ /d issue （着手）・ /d commit （提出）・ /d review （レビュー）の4つ。ブランチ作成やPR作成はこの内側に隠れる 原則2「現実世界との調和」は、 利用者が現実世界から類推するイメージにシステムを合わせよ という原則です。タスクを見る・着手する・成果物を提出する・レビューする ── いずれもGit/GitHubに関係なく開発の作業過程に存在するアクションであり、利用者が説明されなくてもする行動です。ここに揃えたことで「開発ツールの使い方を学ぶ」という壁が解消されました。 改善2：「誰が何をやっているか」が自然に見える（原則1 状態の可視性） 原則1「状態の可視性」は、 システムの状態を利用者に常に見えるようにせよ という原則です。 /d ではこれを個人の画面にとどめず、 チームに対する作業状況の可視化 に広げました。改善1で「着手」の内側に束ねた一連の操作が、そのまま 着手宣言プロトコル として機能します。 /d issue 58 を実行した時点で、 アサイン + 作業ブランチのリモートpush + 方針コメントの投稿 が走ります。コミットがまだ無くても「私が #58 やってます」が周囲に見えるようになります。地味ですが、これだけで 実装を二重に進めてしまう事故 を大きく減らせます。自分から「やってます」と声を上げなくても着手した時点で自然に共有され、チーム全体での作業状況が見えやすくなります。 改善3：誤操作は注意ではなく仕組みで防ぐ（原則5 エラー予防） 原則5「エラー予防」は、 丁寧な注意喚起よりも、そもそもエラーが起きない設計を優先せよ という原則です。Gitを使っていて起きがちな失敗に対して、「気を付けてね」と促すのではなく仕組みで潰します。 /d スキルを使いながら取り入れた予防の仕組みをいくつか紹介します。 # 起きがちな失敗 スキルでの解決 1 同じ内容のIssueを重複起票 起票前に既存Issueとの類似をチェック 2 mainで作業して直push 変更を検知し、自動でブランチを切ってからコミット 3 test tmp 等でブランチ名が乱立 Issue・変更内容から命名規則に沿って自動命名 4 同じIssueを別ブランチで重複着手 着手時に既存ブランチを確認、他人のコミットがあれば確認 5 .env ・ node_modules 等を誤commit ステージング前に自動検知して確認 6 Issueと無関係なファイルが混入 ブランチ名から推測した作業内容と照合して警告 7 未コミット変更を抱えたままcheckout 切り替え前に確認し、コミット/中断を提示 8 ローカルのmainが古いまま進めてconflict地獄 作業着手時やpush前にmainとの差を自動チェックし取り込みを提案 9 Issue・コミット・PRの説明の作文が面倒で省略・雑になる 変更内容からAIがタイトル・本文・コミットメッセージ・PR説明を自動作文 改善4：思い出させない・迷わせない（原則6 再生より再認） 原則6は、認知科学でいう 「再生（recall）より再認（recognition）の方が遥かに楽」 という性質に基づく原則です。「次に何をすべきか」を利用者が思い出す（再生）必要をなくし、 提示された選択肢から選ぶ（再認） だけで正しい手順を歩めるようにします。 「次にやること」を選択肢で提示する サブコマンドの終わりには、必ず 次の候補アクションを選択肢で提示 します。 /d todo の最後 → 優先度の高い順に次のタスクを提案 /d new で起票後 → 「自分をアサインして取り組む / アサインのみ / 他の人にアサイン / アサインしない」 /d commit のレビュー完了後 → 「マージしますか？ (y/n)」 利用者は「次に何をすればよかったっけ」と考える必要がなく、選ぶだけで正しい手順に乗れます。 リスト出力に必ず識別子を振る 「選ぶだけ」のやり取りを支えるため、表・箇条書き・選択肢など複数項目が並ぶ出力には、 必ず連番や記号の識別子を振る ルールにしました。Issue番号のような既存IDがあればそれを使い、無ければ連番を振ります。たとえば実装前に手順の計画を出させると、こうなります。 実装計画: 1. 入力欄コンポーネントの余白を変数化 2. ログイン画面へ適用 3. モバイル表示のスタイル調整 4. 他画面のフォームへ横展開 5. 不要になった旧スタイルの削除 どこまで進めますか？ 地味ですが効果は大きく、利用者は 「一旦3まで進めて」「4と5は不要」 のように番号だけで指示できます。AIとのチャットでは対象を言葉で説明し直したり長い引用をコピペしたりが負担になりがちですが、識別子があるとやり取りが一気に短くなります。 10原則ダイジェスト：残りの原則も設計に対応づける 改善1〜4で使った原則（1・2・5・6）以外も、 /d の設計判断のあちこちに対応しています。残り6つをダイジェストで紹介します。 原則3 ユーザーコントロールと自由 — Issue起点のフローに限定せず、mainでの思いつき着手も許容。破壊的操作の前には必ず (y/n) 確認 原則4 一貫性と標準 — issue commit などの用語は技術側に合わせ、利用者の用語習得やエンジニアとの意思疎通を重視 原則7 柔軟性と効率性 — 初心者は /d todo の提案に乗るだけで着手まで進み、慣れたら /d issue を直接打つ・エイリアス（ /d i ）を使うなど効率化できる。さらに /d improve でスキル自体を進化させられる 原則8 最小限デザイン — 覚えるべきコマンドを少なくし、自然言語でも動くようにすることで、スキルの使い方をシンプルに 原則9 エラー回復 — ワークフロー操作をAIが実施することで、エラー時もAIが能動的に調査・回復できる。使いづらさがあれば /d improve で不満を改善案としてIssue化できる 原則10 ヘルプとドキュメンテーション — /d help で全コマンドと典型フローを表示 おわりに 本記事では、Git/GitHubを使った開発フローをエンジニア以外のメンバーと協働して進めるためのスキルについて紹介しました。エンジニア以外のメンバーとともに開発するチームで、 全員が安心して開発できる環境づくりの一助になれば幸いです。 「こうしたらもっと良くなる」「自分のチームではこうしてる」などがあれば、是非コメントください！

こんにちは。Chief Innovation Officer(CINO)の森です。 最近、Forward Deployed Engineer(以下、FDE)という職種が、IT業界で盛り上がっています。 当社でも、5月からFDEのポジションを新設しました。本記事では、当社がFDE職を新設した背景や狙いについてご紹介したいと思います。 目次 背景 なぜFDEが注目されているか FDEの類型 当社におけるFDEの役割 これまでの反響とこれから 背景 ここ数ヶ月で、FDE(Forward Deployed Engineer)に関する記事を非常に多く見るようになりました。 FDEは、元々アメリカのパランティア・テクノロジーズ(Palantir Technologies)の独自の職種です。 PalantirのFDEは、「 顧客の現場に常駐し、事業課題の特定からシステムの運用・定着までを一貫して担うエンジニア 」と定義されています。 Palantirという強力なプラットフォームを前提に、コンサルティングとエンジニアリングを高いレベルで両立する専門職種が、もともとのFDE像だと捉えています。 現在、多くの企業がFDEを謳っていますが、必要十分な人材を確保できていない企業が大半だと考えています。 FDEの役割や定義は各社各様で、元のFDE像とは異なってきています。また、FDEと類似する役割で、新しい職種名を定義するパターンも出てきており、カオスな状況です。 すでに「FDE」という言葉は一般名詞化しつつあり、Palantir発の定義を超えて、より広い概念として使われ始めています。 ※本記事では、これらの色々な概念をすべてまとめて"FDE"という単語で表現します。 FDEを取り巻くIT業界の動き なぜFDEが注目されているか？ FDEが注目されている理由は、企業現場のAI活用の中心が「 技術検証 」から「 ビジネス実装と成果創出 」に移っているためです。 AIの性能が高まる一方、それを業務にどう組み込むか、どの業務から変えるべきか、どのように成果を測るかは、依然として高いハードルがあります。そこで、事業課題とテクノロジーを橋渡しし、AI実装から成果まで創出する役割の重要性が上がっています。 特に、ここ最近のコーディングAIの進化は圧倒的で、事業のあらゆるシーンに組み込むことができるポテンシャルを感じています。 AI技術が多くの業務に適用できるが故に、FDEに対して、下記のような期待値が混在している状況だと思います。 従来の個別システム開発を、より短期間・低コストで実現することへの期待 これまで費用対効果が合わずシステム化されてこなかった、現場の小さな業務をAIで仕組み化することへの期待 FDEに対する期待値 FDEの類型 本来のFDEは、巨大なプラットフォームビジネスを活動の原資としていますが、ほとんどの企業では、そのような原資がありません。 例えば、従来のセールスエンジニアのような営業に近い役割のFDEもいれば、業務コンサルタントに近い立場のFDEも定義されています。 FDEは期待値が先行し、ひと昔前のデータサイエンティストのような状況ですが、今後FDEに求められるスキルや役割が定義されていくと思います。 FDEの類型 no 類型 キャッチフレーズ 説明 1 プラットフォーム型FDE プロダクトを、顧客の現場で使える形にする 自社プロダクトを顧客環境に合わせて設定・拡張・実装する 2 プリセールス型FDE 商談段階から、プロトタイプで勝ち筋をつくる 商談段階で技術提案、デモ、PoC設計を担う 3 カスタマーサクセス型FDE 導入後の活用を、成果につなげる 導入後の活用定着、改善提案、利用拡大を支援する 4 SIer型FDE 顧客ごとの要件に合わせて、運用まで届ける 顧客ごとの要件に合わせて、個別開発・運用まで担う 5 価値創出型FDE 戦略から実装まで、AIで事業変革を実現する 戦略策定からAI実装、成果創出までを一気通貫で担う 当社におけるFDEの役割 当社は、 住友商事グループの事業群に対し、最先端のデジタル技術をスピーディーにビジネス実装する役割を担う組織 として設立されました。 当社の目指す姿とFDEの期待役割には高い親和性があります。FDEの新設といっても、まったく新しい役割をゼロから作ったというより、従前から当社が担ってきた役割を、生成AI時代に合わせてより明確に定義したものです。 当社のFDEは、住友商事グループの広大なビジネスフィールドを一つの大きなプラットフォームと捉え、そのアセットや知見をレバレッジしながら、AIによる価値創出を現場で実装していく役割です。 先日、住友商事から「 デジタル・AI白書 2025 」が公開されました。当社はこの中で紹介されている多くの事例に携わっています。 当社のFDEポジションには、住友商事のデジタル・AI戦略(DAIS)の先頭に立って、社会や産業の変革をリードいただきたいと考えています。 マネジメント層や事業現場、パートナー企業など、多くのステークホルダーとやりとりしながら、最先端のコーディングAIを駆使して主体的に取り組み、プロジェクトの中心として推進を担う役割を期待しています。 総合商社のデジタル推進企業である当社のFDEには、エンジニアリング力だけではなく、一定のビジネス推進力も期待します。 ただし、なんでもできるスーパーマンを期待しているわけではなく、他職種のメンバーと連携し、役割を補完し合いながら推進いただきたいと思っています。 住友商事グループの規模の大きな事業に携わることができ、非常にやりがいがあり社会的意義も感じることができるポジションだと思います。 最新のAI技術を追いかけても、ビジネス現場では使いどころがないという話をよく聞きますが、当社は全く違います。新しい技術を駆使し、積極的にビジネス活用をしていきたい方には、特にオススメできるポジションです。 これまでの反響とこれから FDEの世の中の盛り上がりは凄まじく、ポジションを オープン してから、非常に多くの反響をいただいています。 当社は、多くのポジションで積極採用中です。FDE以外のコンサルタントやエンジニア、デザイナーのポジションであっても、携わることができるプロジェクトに違いはありません。 FDEポジションに興味がある方はもちろん、コンサルタント、エンジニア、デザイナーとしてAIのビジネス実装に関わりたい方も、ぜひ一度お話できればと思います。カジュアル面談からでも大歓迎です。

MathJax = {tex: {inlineMath: [['$', '$']]}}; 目次 LLMが苦戦する数独を解くHRMとは？ 言語処理学会で発表した検証結果を解説 目次 はじめに なぜHRMが注目されているのか HRMをざっくり理解する 検証方法 データセット 評価モデル 評価指標 実験結果 結果の考察 まとめ はじめに Insight Edgeのデータサイエンティストの唐澤です。 今回は、話題の「HRM（Hierarchical Reasoning Model）」を、数独ベンチマークSudoku-Benchで検証した結果について記載します。 なお、本内容は先日開催された言語処理学会第32回年次大会（NLP2026）でも発表した内容となっています。 なぜHRMが注目されているのか LLMはChain-of-Thought等で推論能力が向上しましたが、数独のような制約充足問題では依然として苦戦することが報告されています。 2025年、Sapient IntelligenceからHRM（Hierarchical Reasoning Model）という新しい推論モデルが提案されました。HRMは脳の階層構造に着想を得たモデルで、このような制約充足問題で高い性能を示しました。 数独は曖昧さがなく、ルールが明確で正解が一意に定まるため、AIの推論能力を測るベンチマークとして理想的です。 そこで、数独データセットSudoku-Bench（nikoli_100）を用いてHRMを実際に評価し、最新LLMと比較しました。 HRMをざっくり理解する HRMは、脳のメカニズムに着想を得たモデルで、異なる時間スケールで動作する2つのリカレントモジュールにより構成されます。 High-levelモジュール：ゆっくり動作し、問題全体を俯瞰 Low-levelモジュール：高速に動作し、細部を処理 この2つのモジュールは協調動作します。Low-levelモジュールがT回状態を更新すると、High-levelモジュールがその結果を受け取り、High-levelモジュール側の内部状態を更新します。この処理をNサイクル繰り返します。 より厳密には、1回の推論プロセスは以下の数式で表されます。全タイムステップを $i = 1, ..., N \times T$ とするとき、Low-levelモジュールの状態更新は： \[ z_L^i = f_L(z_L^{i-1}, z_H^{i-1}, \tilde{x}; \theta_L) \] ここで、$z_L^{i-1}$ は自身の前の状態、$z_H^{i-1}$ は現在のHigh-level状態（サイクル内では固定）、$\tilde{x}$ は入力表現です。 High-levelモジュールは、$T$ ステップごとにLow-levelモジュールの更新結果を受け取り、自身の状態を更新します： \[ z_H^i = \begin{cases} f_H(z_H^{i-1}, z_L^i; \theta_H) & \text{if } i \equiv 0 \pmod{T} \\ z_H^{i-1} & \text{otherwise} \end{cases} \] 最後に、全 $N$ サイクル（計 $NT$ ステップ）終了後のHigh-level状態から、出力層を介して最終的な予測を生成します： $$\hat{y} = f_O(z_H^{NT}; \theta_O)$$ 数独の場合、$\tilde{x}$ は入力された盤面（初期状態）、$\hat{y}$ は解答（81マスの数字）に対応します。この階層構造により、HRMはトークンを生成せず、潜在空間で状態を反復更新して推論を行います。 検証方法 データセット 数独ベンチマークとして知られるSudoku-Benchのnikoli_100を使用しました。HRMの提案論文では使われていないデータセットであり、未知データに対する汎化性能を検証できます。 nikoli_100はNikoli社がSudoku-Benchのために提供した手作り数独の難問100問で構成されています。nikoli_100では、初期状態において全81マスのうち平均約56マスが空欄として設定されています。 評価モデル 評価にはHRMの公開チェックポイントと、最新のLLM（Claude Sonnet 4 / 4.5、Gemini 2.5 Pro）を使用しました。LLMは外部ツールを使わず、純粋な推論のみで評価しました。Sudoku-Benchの提案論文との比較可能性を保つため、公式リポジトリで提供されているプロンプトを使用し、2つの設定で検証しました。Single-shotは解答を一括出力させるモード、Single-stepは1マスずつ配置させ段階的思考を促すモードです。 評価指標 モデルの性能は、以下2つの指標で評価します： 完全正解率：パズル全体の81マスがすべて正解と一致した割合 平均正解配置数：Single-step設定において、最初の誤答が出るまでに何手目まで正しく配置できたかの平均値（最大値は空欄数の約56）。モデルが推論をどこまで維持できたかの指標 実験結果 HRMは数独に特化したデータで学習されたモデルです。本評価では、nikoli_100がHRMの学習データと重複していないことを事前に確認した上で評価を行いました。 モデル 設定 平均正解配置数 完全正解率 HRM -- -- 98.0% Claude Sonnet 4 Single-shot -- 0.0% Claude Sonnet 4 Single-step 2.24 1.0% Claude Sonnet 4.5 Single-shot -- 0.0% Claude Sonnet 4.5 Single-step 4.87 4.0% Gemini 2.5 Pro Single-shot -- 2.0% Gemini 2.5 Pro Single-step 0.60 0.0% nikoli_100での評価結果を見ると、HRMは98.0%という極めて高い完全正解率を達成しました。一方、最新のLLMは全て低迷し、完全正解率は0-4%に留まりました。特に注目すべきは平均正解配置数です。最も性能が高かったClaude Sonnet 4.5は平均4.87手で誤答しており、残り50マス以上を埋める前に誤答しています。 結果の考察 今回の検証でLLMの完全正解率が0-4%に留まった結果は、Sudoku-Benchの提案論文での報告とも整合します。提案論文では、当時のSOTAモデル（Claude 3.7 Sonnet、GPT-4.1等）のSingle-shot正答率は0%、推論特化モデルo3-mini-highも最大2.9%に留まったことが報告されています。今回、後継モデル（Claude Sonnet 4/4.5、Gemini 2.5 Pro）を用いても結果は同様であり、厳密な制約充足を要する論理パズルの解決が依然として極めて困難な課題であることを示しています。 一方、HRMは98%という極めて高い正答率を達成しました。HRMは数独に特化したデータセットで学習されたモデルであり、LLMのような汎用的な学習とは異なります。しかし、今回使用したnikoli_100は、HRMの学習には含まれていない完全な未知データです。つまり、HRMは特化型の学習を行いつつも、学習時には見たことのない問題パターンに対して98%という高精度で対応できたことになります。 まとめ 今回、HRMをSudoku-Bench（nikoli_100）で検証しました。その結果、HRMは98%という高い正答率を達成し、未知データに対する汎化性能の高さを示しました。一方、最新のLLM（Claude Sonnet 4/4.5、Gemini 2.5 Pro）は0-4%に留まりました。 HRMの階層的推論アーキテクチャは、すでに2つの方向に発展しています。1つ目はTRM（Tiny Recursive Model）で、HRMの階層構造を単一ネットワークに簡素化したモデルです。2つ目はHRM-Textで、HRMアーキテクチャを自然言語タスクに拡張した1Bパラメータのテキスト生成モデルです。 これらの発展により、階層的推論アーキテクチャが制約充足問題だけでなく、自然言語処理など幅広いタスクへの応用が期待されます。

  はじめに こんにちは。Insight Edge(以下IE)でセールスコンサルタントをしている石高です。 この記事では、Insight Edgeが住友商事における生成AI活用促進支援の一環として実施したバイブコーディング研修(生成AI研修)についてご紹介します。 Insight Edgeは技術集団としてこれまで住友商事グループ企業に対して幅広いデジタルソリューションの提供を行ってきましたが、IEの支援領域は技術提供・導入にとどまらず、デザインストラテジストやワークショップデザイナーをはじめとする専門性を持ったメンバーを中心に、戦略策定や文化醸成施策の検討、ビジネス課題の解決支援などにも携わってきています。 本研修は2025年度に住友商事のあるグループ（以下、「当該グループ」）を対象に開催され、研修内容の設計および実施をInsight Edgeが担当しています。   生成AI x 業務効率化を目指す研修設計 研修全体像 Why バイブコーディング？ 研修の成果 まとめ     生成AI x 業務効率化を目指す研修設計 住友商事では既に全社横断でCopilotをはじめとした生成AIツールが積極的に利用されており、それに伴う社内研修やワーキンググループの活動が活発に行われているだけではなく、中期経営計画の重要方針「デジタルで磨き、デジタルで稼ぐ」を具現化するための全社戦略「Digital and AI Strategy (DAIS)」が推進されています。 https://www.irwebcasting.com/20260527/4/b134e14786/mov/main/index.html こうした環境の下、当該グループとの企画設計の結果、本研修では、生成AIリテラシーの底上げ及び、生成AI活用による業務効率化を目的に据えました。具体的には、業務での生成AI活用のイメージを持てるようになることや、自身の業務改善を題材に具体的な検討を行い、生成AIを活用して、業務効率化・改善を経験すること等です。 目的実現のため、本研修を通じて参加者が身に付けるべきスキルは以下2点であると考えました。 1. 課題発見(業務理解) 各自が担当する事業環境や業務プロセスを深堀りし、本質的課題の特定ができる   2. 解決具体化（テクノロジー理解） 生成AI技術の特性を正しく理解し、特定された課題に対して実現可能かつ効果的な手段を選択できる   研修全体像 研修は大きく3つのフェーズで実施しました。 フェーズ1：生成AI勉強会(全5回) 生成AIの基本的な利用経験(Copilotを活用した対話形式での利用)があることを前提に、より発展的な活用事例・最新動向を学ぶことを目的としたセミナー形式の勉強会です。IEエンジニアによる事例紹介やハンズオンに加え、住友商事社内で先行して積極活用している社員の方にも登壇いただくことで、参加者にとっても実践のハードルを下げ、生成AI活用のユースケースを身近に感じてもらい、関心を引き出すことができました。   フェーズ2：業務課題探索〜解説会 参加者には事前課題として、各自の業務プロセスおよび抱えている課題の棚卸を行ってもらいました。加えて、各自の課題に対して、それぞれの課題を生成AIで解決するのか、あるいはSaaSサービス等の別手段で解決するのかといった、具体的な解決策の検討にも取り組んでもらっています。その後、IEによる解説会を開催。IEの生成AIエンジニアやデータサイエンティストの目線から、適切な技術選定基準、および解決方法についての解説を行いました。   フェーズ3：Copilot道場・バイブコーディング道場(解決策具体化) フェーズ2で整理した業務課題と想定される解決方法のアイデアを持ち寄り、生成AIツール(Copilotと周辺サービス群等)を使った課題解決とバイブコーディングによるアプリケーション実装を体験しました。     Why バイブコーディング？ フェーズ3における道場の実施背景および進め方について少し詳細を説明します。IEの経験としても、汎用的な既製品のAIツールだけでは対応しきれない業務課題も存在し、ユーザーが自らの業務に合わせてアプリケーションやツールを個別に開発・調整して解決するケースが出てきます。一方、具体検討を進める上での業務担当者と開発者とのコミュニケーション負荷は大きく、構想段階で描かれる「全自動化」や「完全な自律型思考」といった理想の姿と、現在の技術水準やデータ環境において「現実的に実装可能なスコープ」との間にはギャップが生じがちです。 本道場では、実際にバイブコーディングを体験するプロセスを通じて、生成AIの最前線を肌で感じながら実現性への"勘所"を掴んでもらうことを狙い、プロトタイピング（アイデアのクイックな可視化と仮説検証）という手法を採用しました。   研修の成果 本研修は、実際の業務課題を題材に生成AIを活用するプロセスを自ら体験し、業務への取り入れやすさや効果を確かめることを目的として進めました。研修後、参加者からはアンケートを通じて以下のような声が寄せられました。   生成AIありきではなく、まず業務のボトルネックを丁寧に掘り下げ、自身の考えを言語化する能力の大切さを実感した   一度で完璧な成果物は出ないが、壁打ちを繰り返すことで精度を高められると感じた   計画に時間をかけるよりまず手を動かす方が有効で、「作る→試す→直す」のサイクルを回す姿勢を業務でも続けたい   8割まではすぐ作れるが、それ以上の完成度を求めると倍の時間がかかる、という費用対効果の勘所を、手を動かしたからこそ実感できた   主要ベンダー各社のツールに実際に触れたことで、各社の得意・不得意やセキュリティ上の制約を感覚的に理解できた これらの気づきは、本研修を端緒として、今後以下のような力・スキルへと通じていくものと考えています。   【言語化する突破力】 曖昧な理想を形にする「構造的対話スキル」   自分の構想やニーズを、相手（AIやエンジニア）に伝わる言葉に落とし込むスキル   現場の課題を丁寧に掘り下げ、実際に使う人の目線から本質的な解決策を考えるスキル   日常業務の中からAIで改善できそうなポイントを見つけ出し、課題として整理するスキル   意図を正確に伝えるプロンプト制御スキル   曖昧な指示をなくし、精度の高いアウトプットを引き出すために具体的に書くスキル   一発で完結させようとせず、壁打ちを繰り返しながら少しずつ精度を上げていくスキル   【形にする突破力】 まず作って試す「爆速プロトタイピングスキル」   作ったものに執着せず、必要とあればゼロから作り直せる柔軟さとスピード感   「作る→試す→直す」のサイクルを素早く回して、仮説の精度をどんどん上げるスキル   最初から完璧を目指さず、アイデアをさっさと形にして試してみるスキル 生成AIの特性を見極める設計スキル   一定以上の完成度を目指すとコストが急増することを念頭に置き、リターンに見合った落としどころを判断できるスキル   余分な機能を削ぎ落とし、本当に必要な価値に絞って作り上げるスキル   個別に開発すべきかどうかの判断も含め、既存ツールで代替できる可能性も踏まえた適切な技術選定の感覚   【繋がる突破力】 AIやエンジニアと対等に話せる「共通言語と翻訳スキル」   既存の自動化ツールと生成AIを、場面に応じてうまく組み合わせられる構成力   セキュリティの制約を前提条件として受け入れた上で、安全な使い方を考えられる力   主要ベンダー各社のツール特性を自らの手で触って理解し、状況に応じて使い分ける現場感覚   まとめ 生成AIのトレンドは目まぐるしく変わっており、ビジネス部門であっても新しいツールに触れ、「何ができて、何が難しいのか」を自ら試してみることは大切です。今回の研修でもハンズオンの時間を多く設け、まずはツールへの理解を深めてもらいました。 同時に私たちが意識したのは、ツールの習熟を進める中で、「自分の課題を言葉にし、素早く形にし、専門家と対話できる力」も一緒に育んでもらうことです。「実際にツールを動かす手」と「課題を具体化する思考」の双方が組み合わさることで、激しい技術トレンドに左右されず、どのようなツールが登場しても応用が利く本質的なスキルになると考えています。 また、今回はIEのメンバーが一体となって企画から運営まで携わりました。特に技術面で深い知見を持つエンジニアやデータサイエンティストが関わることで、参加者が持ち寄った業務課題に対し、実務に直結した技術的なフィードバックを届けることができたと感じています。本稿で解説した「3つの突破力」は、技術とビジネスの現場が交わるこの研修を通じてInsight Edgeなりに言語化したものです。 Insight Edgeには、エンジニアやコンサルタント、ワークショップデザイナーなど、多様なプロフェッショナルが在籍しています。総合商社が持つ広大なビジネスフィールドを舞台に、テクノロジーを通じて新たな価値を創出することに興味がある方は、ぜひカジュアル面談からお気軽にお問い合わせください。  

はじめに はじめまして、泉川と申します。2026年1月にInsight Edgeに入社し、現在はセールス・コンサルティング部で働いています。気づけば入社から半年が経ちました。 今回は、Insight Edgeに興味を持たれた方に向けて、「Insight Edgeってどんな場所？」という問いに半年間で見えてきた答えを書いてみたいと思います。 実は私自身、転職活動中にInsight Edgeに興味を持ち、ビジネス職として働く方の記事を中心によく読んでいました。 当時知りたかったのは、 どのような経緯でInsight Edgeに来た人がいるのか 実際の仕事内容と、そこに自分の経験が活かせそうか ここで働くと、どのような経験ややりがいが得られるのか ということでした。なので、当時読んでいた頃を思い出しながら、答え合わせのように書いていければと思います。 はじめに どのような経緯でInsight Edgeに来たのか なぜ転職したのか なぜInsight Edgeだったのか 実際にどんな仕事をしているのか 住友商事本体の新規事業におけるAI活用支援 事業会社のAX/DX推進力を高める支援 仕事を通じて感じた、ビジネス職に必要な力 半年働いてみて感じた、Insight Edgeで得られる経験とやりがい 「価値を問われる」環境で、事業や組織に向き合う エンジニア・データサイエンティストとワンチームで働く 組織や仕組みづくりにも関われる おわりに どのような経緯でInsight Edgeに来たのか なぜ転職したのか 私は大手SIerで約8年間、AI活用やDX推進に関する提案・共創活動に携わってきました。 エンタープライズ企業への大型提案、中小企業向けの量販事業、異業種とのコラボレーションなど、多種多様な業界のお客様・パートナー様と向き合いながら、さまざまなビジネスに関わる機会をいただきました。 扱っていたテーマも、AI活用、データ基盤構築、需要予測、DX人材育成に加え、ネットワークセキュリティやITインフラまで幅広く、DXに関わる多くの経験を積むことができました。 新卒で入社し、右も左もわからない若手の頃から、手厚いサポートのもとでさまざまなチャンスをいただき、とても充実した時間を過ごしていました。 一方で、こうした経験を重ねる中で、強く感じるようになったことがありました。 それが「内製化」の流れです。 ノーコード・ローコードツールの普及や生成AIの進化によって、以前のように「すべてSIerに作ってもらう」形から、企業が自分たちで使いこなす方向への移行が進んでいます。AI活用を経営計画に取り入れたり、AI人材の育成・採用を強化したりする動きも広がる中で、外から提案する立場としては、難しさを感じる場面もありました。 もちろん、だからといってSIerの役割がなくなるとは思っていたわけではなく、むしろプラットフォーム、インフラ、セキュリティ、技術提供といった領域では、専門性を持つSIerの価値は引き続き大きいと考えていました。 一方で、AIやデジタルをどう業務に取り入れるか、どう事業価値につなげるかといった領域は、今後さらに事業会社自身が主体的に考え、進めていくようになるのではないかと感じていました。 そのときに、自分はどちらの領域に軸足を置きたいのかを考えました。 プラットフォームやインフラを支える側よりも、事業に近い場所で、AIやデジタルをどう価値につなげるかを考える側に立ちたい。 そう思うようになったことが、転職を考えるきっかけの一つでした。 なぜInsight Edgeだったのか 転職活動を始めた当初は、事業会社のDX部門を中心に見ていました。 外からDXを提案する立場から、実際に事業や組織の中で推進する側に立ちたいと考えていたためです。 一方で、前職で総合商社向けにDXやAI活用の提案をしていたこともあり、Insight Edgeの存在は以前から知っていました。 そんな中、転職活動の中でキャリアコンサルタントの方からも偶然Insight Edgeをご紹介いただき、話を聞く機会をいただきました。 カジュアル面談などを通じて魅力を感じるようになったのは、住友商事グループというフィールドの広さと、テクノロジーに近い環境の両方があることです。 SIer時代から、特定の業界だけではなく、さまざまな業界のお客様と向き合うことに面白さを感じていました。 そのため、ひとつの事業だけを深掘りするよりも、幅広い事業領域におけるAI活用やDX推進に関わりたいという思いがありました。 一方で、事業に近い立場に移ったとしても、テクノロジーから離れたいわけではありませんでした。 むしろ、AIやデータの進化が速いからこそ、エンジニアやデータサイエンティストと近い距離で働きながら、テクノロジーをどう事業価値につなげるかを考えたいと思っていました。 Insight Edgeであれば、総合商社グループの多様な事業課題に向き合いながら、技術職のメンバーとも一緒にAI活用やDX推進に取り組める。 その両方を経験できることに、大きな魅力を感じました。 実際にどんな仕事をしているのか 私はセールス・コンサルティング部に所属し、コンサルタントとして働いています。 役割としては、営業とコンサルティングの両方に近く、提案活動からプロジェクト推進まで幅広く関わっています。 営業としては、顧客や関係者の課題をヒアリングしながら提案を作成し、案件化や受注につなげる活動を行っています。 一方で、まだ課題や進め方が明確になっていない段階の案件に、コンサルタントとして参画することもあります。プロジェクトマネジメントに近い役割を担いながら、顧客と議論を重ね、方向性を整理していくような活動です。 そのうえで、入社後は大きく二つの領域の仕事に関わっています。 ひとつは、住友商事本体の新規事業におけるAI活用支援です。需要予測や事業計画の検討など、事業そのものに近いテーマに向き合っています。 もうひとつは、事業会社のAX/DX推進力を高める支援です。AXはAI Transformationの略で、AI活用による変革を指しています。 人材育成、ソリューション企画、案件推進におけるサポートなどを通じて、事業会社自身がAIやデジタルを活用したビジネスを企画し、推進していける状態を作るための支援を行っています。 前職のSIer時代も、AI活用やデータ活用、需要予測、人材育成といったテーマには関わっていました。その意味では、扱っているテーマ自体が大きく変わったわけではありません。 一方で、同じようなテーマに見えても、実際に向き合う論点は少し違います。 住友商事本体の新規事業におけるAI活用支援 住友商事本体の新規事業におけるAI活用支援では、単に「予測モデルを作る」「データを分析する」という話だけでは終わりません。 その予測は、何の意思決定に使われるのか。 事業計画にどう関係するのか。 どのような判断材料として使われるのか。 そもそも、何を成果とすべきなのか。 こうした問いに向き合う場面があります。 印象に残っているのが、とある大規模な新規事業開発における需要予測案件です。 当初は、需要予測モデルを作ることを一つの方向性として検討していました。ただ、実際に議論を進めていくと、単にモデルを作ればよいわけではないことが見えてきました。 新規事業では、過去データが十分にそろっていない場合もあります。また、予測結果をどう使うのか、どの判断を支援するのか、どの程度の精度があれば意思決定に使えるのかといった論点もあります。 そのため、検討の中では、需要予測モデルそのものを作るだけでなく、AIを使って人の判断やレビューを支援する方向も含めて、複数の活用方法を並べながら検討しました。 この経験を通じて感じたのは、新規事業におけるAI活用では、「何を作るか」よりも先に、「どの意思決定を支援するのか」を考えることが重要だということです。 需要予測という言葉だけを見ると、予測モデルを作ることがゴールに見えます。しかし実際には、事業計画や投資判断の中で、どのような不確実性を減らしたいのか、どの判断を前に進めたいのかによって、AIの使い方は変わります。 モデルを作るのか、判断材料を整理するのか、人のレビューを支援するのか。 事業の状況やデータの状態に応じて、適切な使い方を見極める必要があります。 また、大規模かつ長期にわたる新規事業のプロジェクトでは、技術やデータの状態だけでなく、事業環境やプロジェクト全体の状況も時間とともに変化していきます。 検討時点では妥当だと思っていた方向性でも、その後の状況変化によって、改めて別の方向を検討する必要が出てくることもあります。 だからこそ、ひとつの進め方だけを前提にするのではなく、複数の可能性を考えながら進めることが重要だと感じました。 このあたりは、前職でAI活用や需要予測の提案をしていたときとは違う難しさであり、同時に面白さでもあると感じています。 事業会社のAX/DX推進力を高める支援 もう一つの領域である、事業会社のAX/DX推進力を高める支援では、前職のSIer経験がかなり活きていると感じています。 ここでいう支援は、Insight Edgeが代わりに案件を進めるというよりも、事業会社がAIやデジタルを活用したビジネスを伸ばしていくために、必要な力を一緒に高めていくものです。 具体的には、人材育成、ソリューション企画、案件推進におけるサポートなど、複数の面から支援しています。 この領域で特に活きていると感じるのは、SIer時代に大きな組織の中で、営業部門、技術部門、企画部門など、さまざまな関係者と連携しながら仕事を進めてきた経験です。 大きな組織では、部門ごとに役割や課題感があり、同じテーマでも立場によって見え方が変わります。 前職では、営業が何を実現したいのか、企画部門がどのような方向に進めたいのか、技術部門が何を懸念しているのかをコミュニケーションしながら汲み取り、施策の立て付けや提案の進め方、実行体制を考える場面が多くありました。 その経験があるからこそ、事業会社がAX/DX領域のビジネスを進める際にも、どの組織が何に困りやすいか、どこでつまずきやすいかを想像しながら支援に入れる場面があります。 この領域では、SIer時代に経験してきたDX課題の理解、組織課題の理解、営業、企画、プリセールスの経験が、形を変えて活きていると感じています。 ここまで書いた二つの仕事に共通しているのは、外から提案するだけではなく、住友商事グループの中で、組織や事業に入り込みながらAI活用やDX推進に向き合っていることです。 Insight Edgeは、AIやデジタルの機能を提供する立場ではありますが、実際には住友商事本体や事業会社と同じ目線で、AIやデータを使ってどう事業価値につなげるかを日々考えています。 その中で、前職時代よりも「AIをどう使うか」ではなく、「AIでどう価値を出すか」を考える比重が大きくなったと感じています。 仕事を通じて感じた、ビジネス職に必要な力 入社前は、AIやデータに強い会社だからこそ、技術知識が足りないと苦労するのではないかと思っていました。統計学や機械学習を改めて勉強していたのも、その不安があったからです。 もちろん、AIやデータに関する知識は重要です。ただ、実際にプロジェクトに入ってみると、それだけで前に進むわけではないこともすぐに分かりました。 プロジェクトでは、技術的な議論に入る前に、「そもそも何を解くべきなのか」「成果をどう定義するのか」「誰と合意を取ればプロジェクトが動くのか」といった問いに向き合う場面が多くあります。 ビジネス職として特に求められるのは、AIの専門知識だけではなく、課題設定、合意形成、そしてプロジェクトを前に進める力です。AIの知識は、実務を通じて学び続けることができます。一方で、関係者の認識をそろえ、何を目指すのかを定義し、プロジェクトを動かしていく力は、すぐに必要になります。 AIやデータサイエンスに特化して仕事をしてきたわけでもなく、いわゆるコンサルタントとしてキャリアを積んできたわけでもない自分が通用するのか。これは、転職前に持っていた不安のひとつでした。 ただ半年働いてみて、ビジネス職として必要な力は、業界が変わっても大きくは変わらないと感じています。まだまだ上司や周囲のメンバーから日々勉強中ではありますが、前職で経験してきた、課題設定、仮説提案、合意形成、事業推進の経験は、Insight Edgeでもかなり活きています。 半年働いてみて感じた、Insight Edgeで得られる経験とやりがい 「価値を問われる」環境で、事業や組織に向き合う 前職でも、提案した内容がお客さまにとって価値があるのかは常に考えていました。 一方で、Insight Edgeに入ってからは、「価値を出す」という言葉の重みが少し変わったと感じています。 案件ごとに、売上としての大きさだけでなく、その取り組みが本当に事業や組織にとって意味があるのかを考える場面があります。 たとえば、事業ドメイン、予算規模、DXの成熟度、相手先の体制、将来的な広がり方は案件ごとに異なります。売上が大きい案件だから価値が大きいとも限りませんし、逆に小さく始まる取り組みでも、事業会社のAX/DX推進につながる重要な意味を持つことがあります。 そのため、単に「受注できるか」「売上になるか」だけではなく、相手先にとって何が前に進むのか、住友商事グループとしてどのような意味があるのか、今取り組むべき理由は何かを考える必要があります。 このあたりは、前職で提案活動をしていたときとの大きな違いです。 外から提案する立場では、提案内容の良さや受注に向けた進め方を考えることが中心でした。Insight Edgeでは、住友商事グループの中にいる立場として、その取り組みが本当に価値につながるのかを、より当事者として考えることになります。 簡単ではありませんが、だからこそ面白いとも感じています。 売上だけでは測れない価値も含めて、事業や組織にとって本当に意味のある取り組みを考え抜く。その難しさと向き合えることが、Insight Edgeで働くやりがいの一つです。 エンジニア・データサイエンティストとワンチームで働く ビジネス職として入社して感じたことのひとつが、エンジニアやデータサイエンティストと日常的に同じチームで働けることの素晴らしさです。 SIer時代も社内にエンジニアはいましたが、ビジネス職との距離は必ずしも近いとは言えませんでした。Insight Edgeでは、プロジェクト単位でエンジニア・データサイエンティスト（DS）とビジネス職が一緒に動くため、技術トレンドや新しいツールの情報が自然に入ってきます。 この環境は、ビジネス職としてかなりありがたいと感じています。 入社直後のオンボーディングでは、過去議事録をAIで読み解きながら、プロジェクトの経緯を追っていました。 今では、提案資料や定例会の資料作成だけでなく、お客さま向けのデモアプリ開発にもClaude Codeを使っています。ほぼすべての業務をAI中心に回し始めている、というのが現在地です。 これができているのは、技術職のメンバーが先行して環境を整え、ナレッジを社内に展開してくれているからです。新しいツールを試したいと思ったときに、すぐに相談できるエンジニアやデータサイエンティストが同じチームにいることは、大きな強みだと感じています。 単に「AIを活用しましょう」と言われるだけではなく、実際にAIをどう業務に組み込み、どう使いこなすかを、チームの中で学びながら実践できる。 この環境があるからこそ、ビジネス職であっても、テクノロジーを遠いものとしてではなく、自分の仕事の武器として使えるようになっていると感じています。 組織や仕組みづくりにも関われる 入社前は、住友商事グループの事業に近い立場でAI活用やDX推進に関われることに魅力を感じていました。 一方で、入社してみてから意外と大きな学びになっているのが、組織や仕組みを作る側にも関われることです。 Insight Edgeは中途採用中心で、多様なバックグラウンドを持つメンバーが集まっています。また、会社としても拡大している途中であり、新しい組織や役割が生まれたり、事業環境や案件の状況が変わったりすることもあります。 その中で、「どうすれば再現性を持って成果が出せるか」「どうすれば多様なバックグラウンドやロールを持つメンバーが納得感を持って動けるか」「より高い品質で支援を提供するにはどうすればよいか」といった問いを、日常的に議論しています。 会議体の設計、意思決定の進め方、役割の定義、ナレッジ共有の仕組み——こうしたテーマが、プロジェクトと並行して現場レベルで議論されています。 正直、転職前はこうした経験をそこまで強く意識していたわけではありませんでした。 ただ実際に働いてみると、プロジェクトを進める力だけでなく、組織として継続的に成果を出していくための仕組みを考えることも、とても重要な経験だと感じています。 自分も組織の一員として、どうすればよりよい形で仕事を進められるのか、どうすればナレッジを共有しやすくなるのか、どうすれば成果の質を高められるのかを考え、意見を出す機会があります。 また、こうしたInsight Edge内での試行錯誤は、事業会社への支援にも活きていると感じています。たとえば、AIを活用した仕事の進め方やナレッジ共有の仕組みについて、自分たちが実践していることを事例として紹介し、支援先に価値を感じていただく場面もあります。 自分たち自身も試行錯誤しながら組織としての働き方を改善し、その経験を事業会社の支援にもつなげていけることは、Insight Edgeに入ってよかったと感じているポイントの一つです。 こうした半年間の経験を踏まえて、最後に冒頭の問いに戻りたいと思います。 おわりに 冒頭の問いへの今の自分なりの答えは、Insight Edgeは「住友商事グループのAX/DX推進にチャレンジしながら、自分自身の経験や学びも広げていける、最高の場所」だということです。 SIerやITベンダーでAI活用・DX推進に関わっていて、「次はもっと事業に近い立場で価値を出したい」と考えている方にとって、この記事が少しでも参考になればうれしいです。 Insight Edgeに少しでも興味を持っていただけた方は、ぜひ採用情報やカジュアル面談もご覧ください。

こんにちは。InsightEdge（以下、IE）でPMをしている川島です。 この記事ではSIerで基幹系システムのPMを実施していた私が、InsightEdgeに転職して感じたことを書かせて頂きます。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んで欲しいです。 目次 どうしてこのブログを書くか なぜSIerを離れたか ― 30代中半で感じた違和感 InsightEdgeとはどんな組織か 同じこと ― 環境が変わっても通用したもの 違うこと ― 想像以上のカルチャーギャップ 大規模PMの経験が意外と活きた場面 おわりに 1. どうしてこのブログを書くか 前職はインフラ系SIerで大規模システム構築のPMをやっていました。電力・通信などの基幹系システムの構築を行ってきました。数十社のベンダーと調整しながら、ひとつの障害が社会インフラの停止に直結するような仕事をしてきました。そこからAIを活用した内製開発組織に転職しました。「なんでまた？」とよく聞かれます。この記事はその問いへの、今の自分なりの答えです。 2. なぜsierを離れたか―30代中半で感じた違和感 SIerの中で立場が上がるにつれて、ある矛盾をじわじわと感じるようになりました。組織の目標が「人を抱え続けること」になるほど、クライアントへの提案が「本当に必要なシステム改善」ではなく「次の案件を生むための提案」になっていきます。最初はそれに気づかないふりをしていました。でも30代半ばを過ぎたあたりから、「自分はいったい誰のために仕事をしているんだろう」という問いが、頭から離れなくなってしまいました。SIerという業態を否定したいわけではありません。ただ、立場が上がるほどその構造から抜け出せなくなります。「事業会社のIT組織として、ビジネス起点でシステムを考える側に行きたい」という気持ちが固まっていきました。 問題は「じゃあどの事業会社へ？」です。ここが正直、一番悩みました。特定の業界を選ぶと、前職の経験が活きる場面が偏ります。かといって明確な「やりたい業界」があるわけでもありませんでした。そこで行き着いたのが「総合商社の内製化組織」という選択肢でした。住友商事は金融・流通・エネルギー・メディアなど、幅広い商流とグループ企業を持っています。その内製開発組織であるInsightEdgeなら、特定の業界に縛られることなく、分野を横断して価値を提供できるんじゃないか ――「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われています。「業界を選ばなくていい事業会社」という逆転の発想が、転職先を決めた理由でした。 3. InsightEdgeとはどんな組織か InsightEdgeは、住友商事グループのDX・内製開発を担う組織です。AIや機械学習・データ分析を使って、グループ各社の業務課題を解くPoC（概念実証）を高速で回し続けることが主な仕事になります。外部SIerへの発注ではなく、内製であることの意味は大きいです。プロジェクトの動機が「次の案件を取る」ではなく「グループ事業の価値を上げる」であること。これが、前職で感じていた矛盾をそのまま解消してくれました。 4. 同じこと ― 環境が変わっても通用したもの 転職して最初に驚いたのは、PMの仕事の骨格が思ったより変わらないことです。ステークホルダー管理の本質はどこでも同じでした。相手が電力会社の設備部門長でも、製造業の経営企画部長でも、「相手が何を求めているか」を正確に把握して、「届けられるもの」との乖離を早期に埋める ―― これはPMの核心として変わりません。数十社を同時調整した経験は、そのまま活きました。 リスクを早めに言語化して共有する習慣も変わりませんでした。インフラ系では「リスクを見落とすことが社会的インシデントに直結する」という文化の中にいたので、潜在リスクを早期に共有することが骨まで染みついています。 PoC環境でも「このモデルの精度が出なかった場合、どこまで巻き戻るか」を事前に言語化しておくのは全く同じPMの仕事です。 「やらないことを決める」スコープ管理も普遍でした。 どちらの世界でも、スコープを守る力が最重要PMスキルのひとつであることは変わりません。 5. 違うこと ― 想像以上のカルチャーギャップ 環境は変わらないと思いきや、文脈の違いは想像を超えていました。 【成功の定義】 前職での成功は「リリース日を守ること」「止まらないこと」でした。 InsightEdgeでは「学びを最大化すること」「次のフェーズに繋げること」が成功です。 モデルの精度が出なかった＝失敗ではなく、「精度が出ないと分かった＝重要な学び」として扱われます。 【失敗の許容】 ここが最もカルチャーショックでした。 インフラ系では「失敗は許されない」が全ての行動原理です。 PoC環境では「失敗から学ぶ」が前提で、失敗を恐れて実験を遅らせる方が問題とされます。頭では分かっていても、長年染みついた「失敗回避」の反射はそう簡単に書き換えられませんでした。 【計画の粒度】 InsightEdgeでは短期間で仮説を回し続けることが基本です。 最初のプロジェクトで丁寧な計画書を持参したら、データサイエンティストに 「試してみないと何も言えませんよ」と静かに返されました。緻密に計画を立てることに価値を感じていた自分の価値観を変えるまで、時間がかかりました。 【業務知識の役割】 前職では、ドメイン知識は自分が主体的に深めるべきものでした。 PoC環境では、業務知識はクライアント側が持つものであり、こちらは「引き出す問い」と「データから示唆を出す技術」を持ち込む側です。「知っている自分」から「引き出す自分」への転換も必要になってきます。 6. 大規模PMの経験が意外と活きた場面 前職の経験が武器になった場面も多くあります。 PoC→本番移行の「谷」を渡れることが、今の自分の最大の強みだと思っています。 PoCが成功して「では本番に組み込もう」となった瞬間、セキュリティ・運用体制・既存システムとの連携という、まさに前職の世界が戻ってきます。 この「谷」を渡り切れずにPoC成果が塩漬けになるケースを、入社後何度も目撃しました。「PoC段階から本番を見据えて設計する」視点は、今では自分のPoC PMとしてのアイデンティティになっています。 複雑なステークホルダー折衝も強みになっています。グループ企業の経営層から現場部門まで利害が複雑に絡み合う構造は、前職の「数十社ベンダー＋複数の発注者部門」に構造が似ています。「誰に何を・いつ・どう伝えるか」のコミュニケーション設計は、そのまま通用しました。 7. おわりに 正直に言うと、転職は「完璧な答えを見つけてから動いた」わけではありません。 「このままSIerにいていいのか」という違和感と、「事業会社に行きたいけどどこへ？」 という迷いを抱えたまま、えいやっと決めた部分が大きいです。その選択は間違っていなかったと思っています。 「業界を選ばなかった」結果として、これまで触れてこなかった業務ドメインに次々と関われており、成長を感じさせてくれています。 PMという仕事の本質は「人と目標をつなぎ、不確実性を前に進む力に変える」ことです。スピードが速くなっても、確実性が下がっても、それは変わりません。大規模SIの経験しかないのにAI・事業会社に踏み出せるか不安なら、この記事を読んでほしいです。

はじめに こんにちは。デザインストラテジストの松迫です。 「AIツールを導入したが、その後定着しない」——こんな経験はないでしょうか？ 本記事では、行動科学に基づいた「ハビットデザインメソッド」を使って、 ツール定着の壁を乗り越える具体的な方法をお伝えします。 私は習慣化を促すUXデザインの研究や実践を通じて、この方法論を体系化し、 書籍『あのサービスはなぜ継続率が高いのか？』で紹介しています。 今回は、その内容から「社員のAI・デジタルツール利用の習慣化」というテーマに絞って、習慣化のメカニズムやそのコツをお伝えしていきたいと思います。 一度使い始めたツールも、習慣にならないと元に戻る 便利で効率化につながるAI/DXツールであったとしても、導入初期を過ぎると使われなくなってしまう現象はよく起きます。 このような現象が起きやすい大きな理由の一つは、 「古い習慣の力は非常に強く、気を抜くとすぐに元の行動パターンへ戻っていく」 という人間の特性です。 たとえば、 ChatGPTを導入したが、結局検索はGoogle検索に戻る ナレッジ共有ツールを入れたが、口頭確認に戻る ToDo管理ツールを導入したが、入力をしない元の状態に戻る といったケースです。 特にAIツールは、便利だけれど「なくても仕事はできる」Nice to haveツール（あればうれしいけど必須じゃないツール）になりやすい特徴があります。 基幹システムのようなMust haveツール（必須ツール）は、なければ仕事ができないので半強制的に使われます。 しかし、AIアシスタントや情報整理ツールなどが社員の中でNice to haveなものだという認識のままだと、なかなか利用が定着しません。 そのため、特に「なくても仕事はできる」ツールであるほど、“習慣になるまで支援をする設計”が必要なのです。 習慣になるまでは平均66日かかる そもそも人の行動が習慣になるまでどのくらいかかるのでしょうか？ ロンドン大学のPhilippa Lally らによる研究（2009）では、人が行動を習慣化するまでには平均66日かかるとされています（内容によって定着までの日数にはばらつきがあります）。 これを念頭におくと、AIツール導入後にすぐに利用が定着するということはほぼなく、2ヶ月くらい利用を継続して初めて習慣になっていくということです。 そして、習慣化するまでは前述の通り、古い習慣の引力が働くので、元の行動に戻りやすい期間でもあります。 そのため、「1週間くらいは使ってたけど、そこから使わなくなっちゃったな」ということが誰にでも起きやすいのです。 だからこそ、この期間に、 繰り返し触れる 使うきっかけがある 面倒なく使える 小さな成功体験がある というような、繰り返し使いやすい状態をつくれないと、習慣化の壁を超えられません。 習慣は、「〇〇したら□□する」という脳内の紐づきでできています。 習慣化した状態とは「〇〇したら□□する」という紐づいた行動が“自然に”行われる状態です。 そのため、約2ヶ月間の間に、「〇〇したら□□する」という紐付きを育てていく必要があるのです。 たとえば、 会議後 → AIで議事録整理 提案前 → AIで文章チェック 営業準備 → AIで仮説作成 のように、AIを使った行動を既存業務行動と結びつけていくことで、その行動が次第に脳の“デフォルト行動”になっていきます。 重要なのは、最初～約2ヶ月間の「便利だから使う」という意識的に使う状態を経て、ほぼ無意識的に「自然と使っている状態」をつくることです。 そうなると古い習慣が新しい習慣にアップデートされた状態になります。 35のハビットデザインメソッド 私は、習慣化を促すための具体的な方法を「35のハビットデザインメソッド」として体系化しています。 35のハビットデザインメソッドの一覧（著者作成） まず、習慣化しやすい体験を作るには 1. 準備 2. きっかけ 3. 行動 4. 報酬 というサイクルをつくることが重要です。 比較的習慣化しやすいシンプルな行動は必ずしもサイクルを全て網羅する必要はありませんが、習慣化の難易度の高い行動ほど、丁寧に各サイクルでサポートすると習慣化がしやすくなります。 ここでは、35個すべてをご紹介はできませんが、特に重要な15個のコアメソッドの概要をご紹介します。 「準備」 1.チェーンプランニング ：「〇〇したら□□する」と既存習慣に新行動を紐づける 2.具体ゴールセッティング ：目標を具体的に設定し、達成への行動を具体化する 3.簡単スタートセッティング ：行動を始める手間を極限まで小さくする 「きっかけ」 7.欲求プラス ：やる気が出る他の行動を、新行動の前や中にプラスする 8.クエスト＆リワード ：達成すべきクエストと報酬を用意し、継続意欲を高める 9.損失回避アクティベート ：損したくない心理を刺激して、行動を促す 10.予約・約束セッティング ：予約や約束をすることで確実な実行を促す 「行動」 18.超ミニマムゴール ：絶対できるレベルの小さな行動をゴールにする 19.エブリデイハビット ：毎日触れることで自然な習慣になることを促す 20.楽しさドリブン ：楽しい体験でやる気をアップさせる 21.親切フォローアップ ：親切なフォローで「親切に応えたい」気持ちを引き出す 「報酬」 27.簡単レコード ：実施記録が簡単につけられて、実績が目に見えるようにする 28.すぐさまごほうび ：行動直後にごほうびを与える 29.ほめちぎりモチベート ：行動できたらほめちぎって、継続意欲を高める 30.ちょっとずつサクセス ：小さい単位で成功体験を得られるようにする 習慣化しやすい体験をつくるには、これらのメソッドから、習慣にしたい新しい行動と相性がよさそうなものを選んで、施策やUXデザインに落とし込んでいきます。 習慣化の難易度の高そうな行動については、複数のメソッドを組み合わせてサイクルをできるだけ丁寧に回すようにするとよいです。 ポイントは、「やる気に頼らない」ことです。 やる気だけに頼ってしまうと、やる気が十分にない人は続かなくなってしまいます。 もちろんやる気を高めることも重要ですが、それ以上に「やる気に頼らずとも続けやすい仕組みをつくる」ことを意識して施策や設計を考えることが大切です。 能動ドライブと受動ドライブ 人の習慣化を促すハビットデザインの方向性には、大きく2種類あります。 それは「能動ドライブ」と「受動ドライブ」です。 35のハビットデザインメソッドも、明確に分類が難しいものもありますが、それぞれこのどちらかに分類されます。 能動ドライブ その人の「やりたい」という気持ちを後押しして行動を促す方法です。 例： - 達成したい - 継続したい - 成果を出したい - 新しいAIを使いこなしたい 受動ドライブ 「やらなきゃいけない」状態をつくり行動を促す方法です。 例： - AIを使わなければならないルールにする - 上司への報告が必要 - AIを使わないと次工程に進めない 私のおすすめは、まずは「能動ドライブ」に該当するメソッドを検討して、それだけではなかなか定着させることが難しいと感じる場合は「受動ドライブ」のメソッドも活用するという順序です。 それは、「受動ドライブ」はある種の強制力を使うので、社員がストレスを感じることも起きやすく、できるだけその人の能動性を活かす「能動ドライブ」で習慣化できる方が理想的だからです。 とはいえ、能動ドライブだけではうまく定着しないということが仕事の現場ではよく起きるので、業務では、適切に受動ドライブを組み込むことも必要です。 最初はルールなどを設定して“半強制”でも、繰り返すことで自然な習慣へ変わっていきます。 社員の習慣化を促す2つのアプローチ それでは、実際にハビットデザインを実装していく方法についてです。 方法として「開発を伴わない仕組み化」と「開発を伴う仕組み化」の2つのアプローチがあります。 ① 開発を伴わない仕組み化 まずおすすめなのが、システム開発などをせず、すぐにできる仕組みづくりです。 既存のツールをうまく使ったり、ルールや仕掛けを導入するだけでも、習慣化しやすい体験をつくることが可能です。 たとえば： 週次会議で新しいAI活用事例を1分共有（厳密デッドライン） 「AIで調べてから質問する」ルール化（チェーンプランニングなど） 報告書に「AI推敲」の実施チェック欄をつける（約束・予約セッティング） などです。 特に重要なのは、「使うタイミングを固定すること（チェーンプランニング）」です。 「好きな時に使ってください」は、実は習慣化しにくい設計です。 それよりも「会議前にAI議事録機能をONにする」、「顧客メール送付前にAIに文章チェックをしてもらう」など、具体的な用途と使うタイミングをおすすめし、そのタイミングで使うことを繰り返すことが習慣化への近道です。 ② 開発を伴う仕組み化（UXデザイン） 次に重要なのが、UXレベルでの設計です。 こちらは、ツールの体験そのものに組み込めるため、より強力です。 自社でソフトウェアを開発する際や、クライアント企業向けに開発を行う場合などは、ぜひ習慣化しやすい体験を組み込みましょう。 たとえば： AIを使うまでのクリック数を極限まで減らす（簡単スタートセッティング） 連続記録機能をつける（損失回避アクティベート） AIの活用実績でレベルアップしていく（クエスト＆リワード） などです。 ソフトウェアのUXに組み込む場合は、本当にいろんな仕組みを取り入れることができます。 極限まで使い始める手間を小さくしたり、ごほうび要素を用意したり、使わないと損するような仕組みを取り入れたりと、いろんなアプローチが可能です。 35のメソッドをうまく組み合わせ、習慣化しやすい体験を丁寧につくり上げていくことができます。 「能動/受動ドライブ」と「開発を伴わない/伴う仕組み」を掛け合わせて4象限をつくると下図のようになります。 （著者作成） 一番取り入れやすいおすすめは左上の「手軽で後押しする方法」ですが、より強力な方法にしたい場合は“右”に移動し、より丁寧なUXをつくりたい場合は“下”に移動していくイメージです。 具体的なハビットデザインアイデア 先ほど少しハビットデザインの施策例を紹介しましたが、より具体的にハビットデザインメソッドを使ってどんな施策やUXデザインが可能かの一例を紹介します。 これはほんの一例なので、「どんなことを習慣化してほしいか」に合わせて、皆さん自身でハビットデザインメソッドから施策やUXデザインのアイデア出しをして、実装していってください。 ①「開発を伴わない仕組み化」でのアイデア例 1. よく使うブラウザアプリの隣りにAIアプリを配置 　（能動ドライブ：簡単スタートセッティング） AIを立ち上げるボタンが階層の深いところにあったり、すぐにクリックできない場所にあると、そもそも使うことが面倒になるため、いつも使うアプリの横など、使うことが自然に促される場所にAIアプリを配置するように促します。 2. “まずAIで調べる”という行動指針をつくる 　（能動ドライブ：チェーンプランニング） 質問前に「（AIでわかることは）まずAIで調べる」を行動指針化することで、質問する前のAI活用の定着を促します。 3. AI活用目標の設定 　（能動ドライブ：具体目標セッティング、受動ドライブ：だれかにコミットメント） 各個人がAI活用目標を設定し、上司への進捗・達成の共有をルール化すると、取るべき具体的な行動が明確になり行動に移りやすくなります。 4. AI議事録の自動ON設定 　（能動ドライブ：簡単スタートセッティング） オンライン会議ツールの設定で、デフォルトでAIが議事録を取る設定がある場合はONにしておくと、自動的にAIで議事録を取るようにできます。 5. AIの業務削減効果を共有 　（能動ドライブ：損失回避アクティベート） 「○○の用途にAIを活用すると、平均30%の業務時間削減効果があります」というように、具体的な用途での定量効果を見せることで、“使わない”ことの損失を意識させて、利用を促します。 ②「開発を伴う仕組み化（UXデザイン）」でのアイデア例 1. AIを業務フローの中に埋め込む 　（能動ドライブ：簡単スタートセッティング） 別アプリではなく、既存業務で使うソフトウェアの中にAIを統合することで利用率が上がります。ただAIボタンをつけるだけでは不十分で、利用者のソフトウェア上の業務動線を意識して、パッと使いやすい場所に配置することが重要です。 2. AIでの業務削減効果の参考値が毎回表示される 　（能動ドライブ：すぐさまごほうび） AIを使ってもどれだけ業務効率が上がったかなどがわかりにくいと、脳が報酬を受け取れません。AIを使うたびに、すぐにその行動でどれだけ業務削減効果に繋がったかの参考値を表示することで、報酬になり「効率化したならまた使おう」というモチベーションにも繋がります。 3. 利用記録を可視化する 　（能動ドライブ：簡単レコード） 連続利用日数や毎日の利用状況を表示すると、自身の利用実績が見えること自体がごほうびになり「使い続けたい心理」が働きます。これは学習アプリなどでもよく使われる強力な手法です。 4. AI使おうリマインドメール 　（受動ドライブ：親切フォローアップ） 毎月の請求書を作成する時期が来たら、「AIで請求書を作成しよう」というフォローメールとワンクリックで請求書作成画面に飛べる仕組みをつくります。 これまでの手動の方法でつい作ってしまうことを防ぎ、自然にAIでつくる流れを生みます。 5. ベタ褒めしてくれるキャラ設定 　（能動ドライブ：ほめちぎりモチベート） AIを使う体験の中にほめられる要素がないと、気分よく使ってもらえません。 効率化だけでなく、しっかり使っている中でベタ褒めしてくれるキャラを用意することで、よりAIを使うことにごほうび要素を感じて、使いたい気持ちを高めます。 手軽で効果の高い方法から始めよう AI/DX定着で大切なのは、いきなり大きなことをしようとするより、小さなやりやすいことから始めることです。 ハビットデザインメソッドを使った「開発を伴わない仕組み化」からまず始めることをおすすめします。 AIを使うタイミングを決める（〇〇したらAIを使う） 毎日1回使うだけで成功とする 5分だけAIを使ってみる時間をつくる ごほうび要素を用意する 小さなルールを決める といった、すぐできる工夫からでOKです。 社員（自社/クライアント先）に対して、こういう小さな施策から取り組んでもらい、そこから施策やUXデザインを拡大していくとよいでしょう。 まずは自分自身が、うまく継続して使えてなかったツールを、小さな仕組みを取り入れて継続するところから始めてもよいかもしれません。 注意点としては、「ハビットデザインメソッド」は定着のための万能アイテムというわけではありません。 そもそも、AIツールであれば、AIを使う価値をしっかり伝えることが重要ですし、どういうユースケース（用途）があるのかを伝えることも重要です。 また、カスタマーサクセスの領域ですが、そのツールを迷いなく使い始めることができるようにオンボーディングを丁寧に行うことや、細かい使い方のTipsをシェアすることも大切です。 こういった基本的な取り組みに、ハビットデザインを取り入れると、より自然に行動を定着させていくことができます。 また、ハビットデザインメソッドを使った施策やUXを考える時は、実験や検証をしながら、効果を確かめながら適切に体験を調整したり、場合によっては別のメソッドを使った施策を追加したり、入れ替えたりすることも重要です。 この施策は有効そうだと仮説を立てても、うまくいかないことはもちろん起きえます。大切なことは、科学に基づく習慣化のメソッドを拠り所にして、試行錯誤してよい方法を探っていくプロセス自体です。 アイデアは一人で考えてももちろんよいですが、複数人が集まってブレストして、いいアイデアをピックアップしていくと幅広い施策を考えられます。 AI時代に重要なのは、「便利で高機能なツールを導入すること」に加えて「社員が自然と使い続ける状態をつくること」です。 特にNice to haveなツールには、その視点は必須といってもよいでしょう。 ぜひ、社員のAI/DX活用を習慣化の視点から何かできることはないかと検討し、習慣化を促す施策やUX設計を考えてみてください。

1. はじめに こんにちは、私は現在26歳、社会人5年目で、Insight Edge に入社して半年が経ちました。PMとして働いていて、会社の中では最年少のPMです。 前職は大手企業の情報システム部にてSE・PMとして働いていましたが、同じPMでも転職してから働き方も立ち位置、会社の雰囲気や扱う案件・技術がガラッと変わりました。この記事では、「女性・若手・入社半年」という今の自分だからこそ書ける視点で、Insight Edge で働いて感じたことをお伝えできればと思います。 選考プロセスの話というより、実際に働いてみて感じた前職との違いや、入社半年で気づいたことを中心に書いていきます。少しでもIEに興味のある方や若手PMとして働かれている方に読んでいただければ嬉しいです！ 2. なぜ転職したのか 前職は事業会社にて、エンタープライズシステムのSEやC向けモバイルアプリのPMとして働いていました。 大企業ならではの大規模なシステムや多くの人に触ってもらうプロダクトに関わることで、IT業界の基礎、PMとしての土台になるような部分を学ぶことができました。ありがたい経験を積めたと思います。 一方で、もっとスピード感のある環境で、自分の裁量を持って動きたいという気持ちがありました。新しい技術に関わりたい、レベルの高いエンジニアと同じ立場で一緒に働きたい、他のドメインにも知見を広げたいという思いも強くなっていきました。 そんな中で Insight Edge は少数精鋭でスピード感があり、エンジニアの技術関心度が高く、単なるSIerとは違ってお客さんと同じ立場で「会社を良くする」という目標で動ける環境だと伺い、応募をすることに。実際にカジュアル面談の中で業務内容やこれまでの提案例を聞いて、「ここなら自分がやりたいことができるかもしれない」と感じました。 3. 転職して変わった5つのこと 3.1 エンジニアの立ち位置 - お客さんと同じ目線で 一番前職と大きく異なると感じたのは、エンジニアの立ち位置です。 前職では手を動かしてもらうことが最も大きな価値と捉えていたエンジニアが、Insight Edge では同じPJメンバ・グループの仲間として、お客さんと同じ立場で会話できます。「住友商事グループ全体を良くする」という共通の目標のもとで、エンジニアからも自立的に意見を出しながら動けるのが、すごく新鮮でした。 エンジニアが前面に立って提案できる文化があり、お客さんも挑戦を喜んで受け入れてくれます。前職では開発メンバが主管部の前に立たないことが多かったので、この変化には驚きました。 例えば、入社して最初に担当した採用効率化のプロジェクトでは、主管部との定期的な会議の中で、お客さんが自然に要望を口に出してくれたり、こちらも技術的に難しいことを素直に話すことができました。職種の壁や会社の壁を感じさせず、同じ住友商事グループのメンバとして、フラットに議論できる環境は、とても働きやすいと感じています。 3.2 スピード感と裁量 - 少数精鋭だからこそ この半年で私が参画しているPJでは実働3〜6人のチームで動くことが多く、意思決定がとにかく速いです。（これは自分の担当案件の大きさ次第な部分もあると思いますが） 自分たちで決められることが多くて、これには本当にびっくりしました。前職では承認フローが長く、1つのことを決めるまで・リリースするまでに時間がかかっていたので、このスピード感は衝撃的です。少数精鋭だからこそ、一人ひとりの意見が尊重され、裁量も大きくなります。 例えば、最初のプロジェクトでは、主にPM・データサイエンティスト・エンジニアの3人体制で動いていました。毎日デイリースクラムのように会話しながら、進捗確認や不安の解消を行うスタイル。こうしたやり方も、PJやチームごとに自分たちで選んで採用できる柔軟性があります。前職では大企業特有の長い承認フローや自分の喋らない定例会議が多かったのですが、IEではそういったストレスが少なく、本当に必要なコミュニケーションに集中できる環境です。 一方で、裁量が大きい分、自分の力不足を実感する部分でもあります。PMとして、IEのエンジニアが輝けるように、顧客によりバリューを届けられるように、プロジェクト進行ができるようになりたいと思っています。 PMの先輩方を見て学んでいるところですが、先輩方の多くも他の会社で多種多様な経験を積んできた方が多く、その経験値を間近で見られるのは良い経験になっています。 3.3 技術への姿勢 - みんなホットトピックを持っている エンジニアの技術関心度が高く、みんなホットトピックを持っています。 「やってみたい」「取り入れてみたら」というエンジニアの提案が通りやすい文化があって、技術への探究心が活発です。自己研鑽の時間を10%取っていい制度があったり、学会参加している人も多くいたりと、技術を好きな人には本当に良い環境だと思います。 実際、最初のプロジェクトでは、AIを使ったプロンプトベースのブラウザを操作しての業務を自動化するという、知ってはいてもIE内では業務利用としてはまだ誰も実装したことがない技術に挑戦しました。「IE・住友商事グループの知見として貯める」という意味も込めて、技術的にチャレンジングなことにも取り組ませてもらえる環境です。 3.4 女性・若手としての働き方 - フラットに扱われる環境 女性だからといって変な貴賤がなく、フラットに扱われます。 会議での発言も、任される仕事も、過度な遠慮等もなく、等しく扱ってもらえていると感じます。これまでの様々な環境の中で、時には過度に遠慮されてしまうこともあったので、この環境は本当にありがたいです。 技術的な会社である以上、女性が少ないというのはどこにでもあることだと思います。だからこそ、気兼ねなく話せることが大事だと考えていて、IEでは女性社員同士でランチに行ったり、お土産を交換したり、仲良くしてくれる人が多く、話しかけやすい環境です。女性に限らず、海外出身の人ともフラットに仲良くしています。まだ私はあまり参加できていないのですが、サークル活動やTGIFなど、同じプロジェクト以外の人とも交流する機会も用意されています。 子育て世代も本当にたくさんいて、保育園の送り迎えの時間はスケジュールブロックしたりと、ワークライフバランスを意識した働き方ができているように見えています。今後のことを考えると、とても心強い環境です。 また、これも驚いたこととして若手もしっかりと1戦力として扱われる環境であることが挙げられます。私自身、入社してわずか2-3週間後に、プロジェクトの担当PMとしてキックオフを任され、0→1の経験が少なかったので緊張しましたが、周りのサポートもあり、初めてのキックオフを何とかこなすことができました。責任も大きいですが、その分やりがいもあるなと改めて感じています。 3.5 PMとしての役割 - 工数管理を超えて PMの役割の広さにも驚きました。 ただの工数管理だけの人は求められていません。提案、エンジニアアサイン、技術的理解、コードを読むこともある、折衝、その後のメンテ系…それらを自分で方向性を決めていく必要があり、それらが難しくも楽しいと感じています。 4. 入社半年で気づいたこと 半年働いてみて、前職では出来上がった環境で動いていたことに気づきました。 Insight Edge ではPoC案件が多く、プロジェクト期間も短いです。技術的に未来が不透明なプロジェクトを動かすことが多く、スピード感のある開発サイクルに戸惑うこともあります。 例えば、住商グループ会社の海外拠点との購買業務に対するAIエージェントのPoCプロジェクトでは、入社してすぐの立場ながら、キックオフのためにアジアに3日間出張させてもらい、先方との関係性構築を大事にするというIEの考え方を体感できる良い機会でした。サプライチェーンの工場見学もさせていただき、調達の流れを生で見ることができましたし、現地で友達もできました。商社の仕事の広さを実感し、「様々な業界にデジタル技術で革命を起こせる」というワクワク感を覚えました。 一方で、PoCフェーズならではの難しさもあります。技術検証として取り組むプロジェクトなので、不確定要素が多い中でお互いに満足のいく成果を出すことの難しさを実感しました。期待通りに動かないこともありますが、それがわかったことも成果として、柔軟に対応していく必要があります。 自分自身の成長余地でもありますが、頑張っていきたいところです。 一方で、半年経って改めて思うのは、技術を好きな人には本当に良い会社だということ。思っていた通り、新しい技術への関心度が高く、スピード感早く取り組んでいます。自分のやりたかった「色々な分野・技術に挑戦する」ことができて、本当に楽しく働けています。 5. おわりに Insight Edge に入社して半年、今までとは全く違う環境で、日々新しい発見があります。 少数精鋭でスピード感があり、技術への関心度が高く、エンジニアが前面に立って提案できる。女性・若手もフラットに扱われる環境です。 まだ自信が持てていないところもありますが、技術が好きで、自分で環境を作っていきたい人には、とても良い会社だと感じています。 IEに興味を持ってくださった方にとって、この記事が少しでも参考になれば嬉しいです。

― 作業は減るが、判断力は求められ、責任はより重くなる ― 目次 はじめに 生成AIによって、PMの「作業」は確かに減る むしろ、判断は難しくなる 負荷は「作業」から「認知」と「判断」に移る 生成AI時代に、PMが磨くべきもの 1. 論点を設定する力 2. 優先順位を付ける力 3. 出力を疑う力 4. 判断を引き受ける力 おわりに はじめに こんにちは。Insight EdgeでPM業務をしている小林です。 今回は、「生成AIの活用によってPM業務は楽になったのか」というテーマで整理してみます。 ※本記事は著者の個人的な経験と見解に基づくものであり、Insight Edgeとしての公式な見解ではありません。 生成AIの活用は、非常に速いスピードで広がっています。 その影響は、プロジェクトマネジメントの現場にも確実に及び始めています。 要件整理、議事録作成、資料のたたき台作成、リスクの洗い出し。 これまでPMが時間をかけて行っていた作業の一部は、生成AIによって効率化できるようになりました。 この変化だけを見ると、「PMの仕事は楽になる」と考えたくなります。 実際、作業単位で見ればその認識は間違っていません。 ただ、プロジェクト全体を前に進めるという観点で見ると、話はそれほど単純ではありません。 本記事では、生成AIによって何が軽くなり、逆に何が重くなるのかを整理しながら、 PMの仕事は減らず、むしろ判断と責任が重くなっていく という構造について考えます。 生成AIによって、PMの「作業」は確かに減る まず前提として、生成AIがPM業務の一部を効率化すること自体は間違いありません。 例えば、以下のような領域ではすでに有効に機能しています。 要件整理のたたき台作成 会議アジェンダや議事録の作成 想定リスクや論点の洗い出し 顧客説明資料や進捗報告資料の初稿作成 これらは、既存情報をもとに論点を整理し、一定の形式でアウトプットする仕事です。 生成AIは、この種の「整理する仕事」を比較的得意としています。 そのため、PMが手を動かしていた作業時間は、今後も一定程度削減されていくはずです。 一方で、ここで押さえておきたいのは、 作業が減ることと、仕事が減ることは同じではない という点です。 PMの仕事は、単に情報を整理することではありません。 実際には、以下のような役割が含まれています。 何を論点として扱うかを決める どの情報を採用し、どの情報を捨てるかを決める スコープ・納期・品質の優先順位を決める 関係者の期待を調整し、合意形成する 最終的な判断を引き受ける 生成AIは選択肢を提示することはできますが、 どの選択肢を採るべきかを、責任を持って決めることはできません。 つまり、生成AIが減らすのはあくまで前処理です。 PMの中心的な仕事である「決めること」は、引き続き人が担う必要があります。 むしろ、判断は難しくなる 生成AIの導入によって、判断の難易度が下がるわけではありません。 むしろ、難しくなる場面も増えているように感じます。 従来、PMは情報不足の中で判断することが多くありました。 一方で、生成AIを使うと、短時間で大量の論点や選択肢を得ることができます。 これは一見望ましい変化です。 ただ、別の見方をすれば、 判断すべき候補が増える ということでもあります。 結果として、PMは次のような難しさに直面します。 選択肢が多すぎる 論点が広がりすぎる 何を優先すべきかが見えにくくなる さらに厄介なのは、「正しそうな間違い」が増えることです。 生成AIの出力は、多くの場合きれいに整理されており、一見すると妥当に見えます。 しかし実務で問題になるのは、 一見正しそうだが、この案件では使えない という出力です。 例えば、要件定義の粒度についてAIに相談すると、「品質を担保するために詳細な粒度で統一すべき」という一般的なベストプラクティスが返ってきます。論理としては正しいですが、実際のプロジェクトでは、納期重視の顧客要望があり、粗い粒度の要件定義で進めるべき案件かもしれません。PMはこの文脈の違いを見極めなければならないのです。 一般論としては正しい 論理としては整っている しかし顧客や現場の文脈には合っていない このような出力が増えることで、PMは従来以上に、出力を評価し、取捨選択しなければならなくなります。 負荷は「作業」から「認知」と「判断」に移る こうした変化を整理すると、PMの負荷はなくなるのではなく、別の場所へ移っていると考えられます。 項目 従来 生成AI導入後 作業負荷 高い 低い 判断負荷 高い さらに高い 認知負荷 中程度 非常に高い この表が示しているのは、生成AIによってPMの負荷が単純に減るわけではない、ということです。 手を動かす負荷は確かに減ります。 一方で、情報を読み解き、見極め、優先順位を付け、判断するための負荷はむしろ増えていきます。 つまり、PMの仕事は軽くなるというより、 より認知的で、より判断依存の仕事へ移っていく と整理できます。 生成AIは提案を行いますが、責任は負いません。 出力の正否に関わらず、その結果を引き受けるのはPMです。 例えば、 AIが整理した要件を採用した AIが提示した論点で顧客説明をした AIが出したリスク一覧を前提に計画した その結果として認識齟齬や判断ミスが起きたとしても、 「AIがそう言ったから」は責任の所在にはなりません。 むしろ、生成AIを使って効率化できるようになったからこそ、 最終的には それでも、なぜその判断をしたのか が、これまで以上に問われるようになります。 作業をAIに委ねられるようになった分だけ、 人間が担うべき判断と責任は、より明確になり、相対的に重くなっていく とも言えます。 生成AI時代に、PMが磨くべきもの では、この環境でPMに求められるものは何でしょうか。 生成AIを使いこなすこと自体も重要です。 ただ、それ以上に重要なのは、次のような力だと考えています。 1. 論点を設定する力 生成AIは、与えられた問いには答えられます。 しかし、何を問うべきかまでは決めてくれません。 どこが本当の争点なのか。 何を明らかにすればプロジェクトが前に進むのか。 この論点設定は、引き続きPMに求められる役割です。 2. 優先順位を付ける力 生成AIは選択肢を増やします。 しかし、限られた時間と予算の中で何を優先するかは、人が決めなければなりません。 選択肢が増えるほど、優先順位付けの重要性はむしろ高まります。 3. 出力を疑う力 便利であるがゆえに、AIの出力はつい信用したくなります。 しかし実務では、鵜呑みにせず、前提を確認し、文脈に照らして疑う姿勢が欠かせません。 特に「一見正しそうな間違い」を見抜く力は、これまで以上に重要になります。 4. 判断を引き受ける力 最終的には、ここに尽きます。 判断し、その結果を引き受けること。 これは作業ではなく、PMという役割そのものに近いものです。 生成AIが広がるほど、この役割の重要性はむしろ際立っていくように思います。 おわりに 生成AIによって、PMが担ってきた作業の一部は確実に効率化されます。 その意味で、手を動かす負荷は今後も減っていくはずです。 ただし、PMの仕事そのものが軽くなるわけではありません。 むしろ、生成AIによって情報整理や初稿作成が容易になるほど、 PMには「何を信じるか」「何を捨てるか」「なぜそう判断するか」が、より直接的に問われるようになります。 プロジェクトを前に進めるという意味では、 仕事は減らず、判断と責任はむしろ重くなる。 生成AIの時代に起きているのは、仕事がなくなることではなく、 負荷のかかる場所が移っている ということなのかもしれません。

第35回 人工知能学会 金融情報学研究会（SIG-FIN）発表レポート リードデータサイエンティストの市川です。 今回は、昨年10月に発表した内容について説明させていただきます。 第35回 人工知能学会 金融情報学研究会（SIG-FIN）発表レポート イベントの概要 本邦中古スマートフォン市場における買取価格形成の分析概要 1. 発表の位置づけ 2. 研究の目的 3. 使用データ 4. 分析方法 4.1 発売からの経過時間と買取価格の関係 4.2 為替変動の影響分析 4.3 XGBoostによる予測分析 5. 分析結果 5.1 経過時間は最も重要な価格形成要因 5.2 Apple製品は高い価格維持力を持つ 5.3 為替変動の影響は限定的ですが、iPhoneでは遅れて表れる可能性がある 5.4 XGBoostモデルは高い予測精度を示す 5.5 ストレージ容量の影響は非線形 5.6 モデルタイプの影響は相対的に小さい 6. 実務上の示唆 7. 社会的意義 8. 今後の課題 9. まとめ イベントの概要 人工知能学会 金融情報学研究会（SIG-FIN） は、人工知能学会の第二種研究会です。SIG-FIN は、ファイナンス分野における人工知能技術の応用を促進する研究会であり、機械学習、データマイニング、テキストマイニング、市場シミュレーション、投資支援、行動ファイナンスなど、金融に関わる幅広い研究テーマを対象としています。 詳細は上記リンクに譲るのですが、金融市場や金融実務に関わる課題に対して、人工知能分野の研究者と金融市場の現場で活躍されている方々が交流する、かなりユニークな研究会という認識です。近年、ファイナンス分野におけるAI活用への関心が高まっていることもあり、発表テーマもかなり幅広くなってきている印象です。 スケジュールは以下の通りでした。 日時：2025年10月11日（土）～12日（日） 開催形式：会場およびオンライン（Zoom使用）のハイブリッド開催 会場：慶應義塾大学日吉キャンパス 来往舎1階シンポジウムスペース 今回の第35回研究会は、土日の2日間にわたって開催されました。参加人数はおおよそ200人程度で、J-STAGE上では第35回金融情報学研究会として25件の研究会資料が公開されており、かなり発表数が多かったです。 こちらの研究会はありがたいことに、 各発表の研究会資料がJ-STAGEで公開されています 。 第35回は、人工市場、投資戦略、テキストマイニング、データマイニング、機械学習、生成AI・LLM活用など、金融とAIの接点にある多様な研究が発表されていました。 全体としては、従来からSIG-FINらしい人工市場・市場制度設計に関する研究に加えて、有価証券報告書、適時開示、決算説明、J-REIT物件情報などの金融テキストを対象にした研究が目立っていた印象です。また、LLMを用いた利益予測や決算サプライズ抽出、サステナビリティ記述の分類など、生成AI・LLMを金融データ分析に応用する研究も複数あり、金融分野でもLLM活用がかなり広がってきていると感じました。 本邦中古スマートフォン市場における買取価格形成の分析概要 今回発表してきました、「本邦中古スマートフォン市場における価格形成に対する機種ブランドと為替レートの影響」の概要を以下の通りまとめさせていただきます。 1. 発表の位置づけ 本発表は、日本の中古スマートフォン市場において、端末の買取価格がどのような要因によって形成されているのかを、実データに基づいて定量的に分析した研究です。特に、機種ブランド、とりわけApple製品とその他メーカー製品の違い、さらに米ドル／円為替レートの変動が中古スマートフォンの買取価格に与える影響に焦点を当てています。 スマートフォンは、現在では日常生活や家計に欠かせないインフラとなっています。個人保有率や世帯保有率はいずれも高い水準にあり、多くの人にとってスマートフォンは生活必需品となっています。一方で、近年は半導体価格の上昇、円安、インフレなどを背景に、新品スマートフォンの価格が上昇しています。その結果、消費者にとって端末購入にかかる負担は大きくなっており、新品の代替手段として中古スマートフォン市場の重要性が高まっています。 中古スマートフォン市場の拡大は、消費者に安価な端末選択肢を提供するだけではありません。企業にとっては、買取価格の設定、在庫評価、リース会計、将来価格の見積りなどの実務に関わる重要なテーマでもあります。また、端末が中古市場で再流通することで製品寿命が延び、新品製造や廃棄に伴う環境負荷の低減にもつながります。そのため、中古スマートフォンの買取価格がどのように推移し、またその価格がどのような要因によって変動するのかを明らかにすることには、実務面でも社会面でも大きな意義があります。 2. 研究の目的 本研究の目的は、日本の中古スマートフォン市場における買取価格の形成要因を明らかにすることです。具体的には、次のような問いに答えることを目指しています。 発売からの経過時間は、中古スマートフォンの買取価格にどのような影響を与えるのか。 Apple製品とその他メーカー製品では、買取価格の維持傾向にどのような違いがあるのか。 米ドル／円為替レートの変動は、中古スマートフォンの買取価格に影響を与えるのか。 iPhoneの買取価格を予測する際、どのような特徴量が重要になるのか。 先行研究では、中古スマートフォン価格の形成要因として、製品ランク、ストレージ容量、SIMロック、ネットワーク利用制限などの影響が分析されてきました。また、販売サービス間の価格差や、海外市場における中古スマートフォンの再販価値に関する研究も行われています。 しかし、日本市場を対象に、業者の買取価格を中心に据え、複数ブランド・複数機種を横断的に分析し、さらに為替レートのようなマクロ経済要因を組み込んだ研究は十分ではありませんでした。そこで本研究では、業者の月次買取価格を主な分析対象とし、ブランド、発売からの経過時間、為替変動、ストレージ容量、モデルタイプなどが買取価格にどのような影響を与えるのかを検証しています。 3. 使用データ 分析に用いられたデータは、一般社団法人リユースモバイル・ジャパンが公表した「主要端末の買取平均額の推移」です。対象期間は2018年1月から2024年6月までで、正会員9社の実績に基づく月次の平均買取価格が用いられています。 対象となる端末は、A・B・Cランクの使用済みかつ使用可能な個人向け買取端末です。未使用品や破損品は除外されています。元データにはスマートフォン以外のタブレットやウェアラブル端末も含まれていますが、本研究では端末名に基づいてスマートフォンのみを抽出しています。また、同一モデルであってもストレージ容量が異なる場合は、別系列として扱っています。 為替レートについては、FREDのデータを用いて、同期間のUSD/JPY月次平均レートを取得しています。これにより、端末ごとの月次買取価格データと、為替レートの時系列データを組み合わせて分析しています。 本研究では、中古スマートフォンの価値を把握するために、対象月の平均買取価格に注目しています。買取価格は、中古端末事業者が実際の需給、端末状態、在庫回転、検品基準、保証コストなどを踏まえて決定する価格であり、中古市場における実勢を反映しやすい指標です。小売価格やオークションの掲示価格と比べても、事業者側の実務的な判断が反映されている点に特徴があります。そのため、買取価格の分析は、中古スマートフォン市場の価格形成を理解するうえで有用です。 4. 分析方法 本研究では、大きく三つの観点から分析が行われています。 4.1 発売からの経過時間と買取価格の関係 第一に、発売からの経過月数と買取価格の関係を分析しています。各端末について、発売年月から対象年月までの経過月数を計算し、経過時間が長くなるほど買取価格がどのように変化するのかを可視化しています。 また、製品特性による違いを確認するため、Apple製品とその他メーカー製品を分けて比較しています。これにより、ブランドによって買取価格の維持傾向に差があるかどうかを検証しています。 4.2 為替変動の影響分析 第二に、米ドル／円為替レートの変動が買取価格に与える影響を分析しています。ここでは、単純に為替レートと買取価格を比較するのではなく、月次の買取価格の変化に注目しています。 これは、新製品の投入によって平均的な価格水準が見かけ上変動する影響を取り除くためです。具体的には、連続する2か月の両方に存在する製品群のみを対象とし、その製品群における平均買取価格の変化を算出しています。この方法により、製品構成の変化ではなく、既存製品の価格変化そのものを捉えようとしています。 為替については、過去1か月から6か月までの変化量を計算し、それが1か月から4か月のラグを置いて買取価格の変化にどのように関係するのかを検証しています。 4.3 XGBoostによる予測分析 第三に、iPhoneの買取価格を対象として、XGBoostによる予測分析を行っています。説明変数には、発売からの経過月数、3か月前の1か月間の為替変動、ストレージ容量ダミー、モデルタイプダミーが用いられています。 さらに、SHAPを用いることで、予測モデルにおいて各特徴量がどの程度重要であり、どの方向に影響しているのかを解釈しています。これにより、単に予測精度を確認するだけでなく、買取価格形成のメカニズムを説明することも試みています。 5. 分析結果 5.1 経過時間は最も重要な価格形成要因 発売からの経過月数と買取価格の関係を可視化した結果、全体として明確な右肩下がりの傾向が確認されています。これは、発売から時間が経過するほど、中古市場における端末の買取価格が低下することを示しています。 スマートフォンも一般的な製品と同様に、時間の経過とともに市場価値が減少していくことが確認されています。したがって、中古スマートフォン市場における最も基本的な価格形成要因は、発売からの経過時間であると考えられます。 5.2 Apple製品は高い価格維持力を持つ Apple製品とその他メーカー製品を分けて比較すると、両者の間には明確な違いが見られています。同じ経過月数で比較した場合、Apple製品はその他メーカー製品よりも高い買取価格を維持する傾向が示されています。 つまり、Apple製品、特にiPhoneは中古市場において価格が下がりにくく、高い価格維持能力を持っています。この背景には、Appleブランドの強さ、iPhoneに対する中古需要の安定性、OSアップデート期間の長さ、周辺アクセサリやエコシステムの充実などが関係している可能性があります。 5.3 為替変動の影響は限定的ですが、iPhoneでは遅れて表れる可能性がある 為替変動の影響については、Apple製品とその他メーカー製品で異なる結果が得られています。 Apple製品については、「3か月ラグ×1か月為替変化」および「3か月ラグ×2か月為替変化」において、5％水準で有意な正の相関が確認されています。これは、為替の直近1〜2か月の変動が、約3か月後のiPhoneの買取価格変化に弱い正の相関を持つことを示しています。 言い換えると、円安方向への為替変動はすぐに中古価格へ反映されるわけではありませんが、一定の遅れを伴って中古iPhoneの買取価格を押し上げる可能性があります。 一方、Apple以外の製品については、有意な相関は確認されていません。相関係数も全体的に小さく、Apple製品に比べて為替変動の影響を受けにくいことが示されています。 この違いの背景としては、Apple製品はグローバルな価格体系や米ドル建ての価格設定の影響を受けやすい一方で、Android端末では国内メーカーや多様な価格戦略が混在していることが考えられます。そのため、為替変動の影響がApple製品ほど明確には表れにくいと考えられます。 5.4 XGBoostモデルは高い予測精度を示す iPhoneの買取価格を対象として構築したXGBoostモデルは、高い予測精度を示しています。テストデータに対する決定係数R²は0.898、平均二乗誤差MSEは0.0020となっています。 これは、発売からの経過月数、為替変動、ストレージ容量、モデルタイプといった特徴量によって、iPhoneの買取価格を高い精度で説明できることを示しています。 SHAPによる特徴量重要度の分析では、最も重要な特徴量は経過月数となっています。経過月数は他の変数を大きく引き離しており、スマートフォンの中古価格を決める最大の要因が発売からの時間であることを改めて裏付けています。 次に重要な特徴量は為替変動であり、その後にストレージ容量、特に64GBであることが続いています。一方で、Pro、Pro Max、SE、mini、Plus、無印といったモデルタイプの影響は、経過月数や為替、容量に比べると限定的です。 5.5 ストレージ容量の影響は非線形 ストレージ容量については、単純に容量が大きいほど買取価格が高くなるわけではないことが示されています。 64GBのような低容量モデルは、現在のアプリや写真・動画利用に対して容量不足と見なされやすく、中古市場での評価が低くなりやすい傾向があります。一方で、512GBや1TBのような高容量モデルも、買取価格という観点では必ずしも有利ではありません。 発売時価格が高いため、絶対的な買取価格は高くても、購入時の価格差に見合うほど中古市場で高く評価されるとは限らないためです。中古市場の購入者は、高容量に対して新品時と同じだけの価格プレミアムを支払うとは限りません。 そのため、128GBや256GBのような中容量モデルが、中古市場において需要と価格のバランスが取りやすい容量帯として機能している可能性があります。 5.6 モデルタイプの影響は相対的に小さい モデルタイプについては、ProやPro Maxは買取価格にやや正の影響を与える一方、SEはやや負の影響を与える傾向が見られます。 ただし、モデルタイプの影響は全体として小さく、iPhoneの中古価格形成においては、モデル名の違いよりも、発売からの経過時間、為替、容量の方が重要であると考えられます。 6. 実務上の示唆 本研究の結果は、中古端末事業者、消費者、制度設計のそれぞれにとって有用な示唆を持っています。 中古端末事業者にとっては、買取価格の設定や在庫評価を行う際に、発売からの経過時間、ブランド、為替変動、ストレージ容量を考慮することの重要性が示されています。特に、Apple製品は価格維持力が高く、為替変動の影響も一定の遅れを伴って表れる可能性があるため、価格改定や在庫管理において注意すべき要素となります。 消費者にとっては、購入・売却のタイミングや機種選択を考える際の判断材料になります。たとえば、iPhoneは中古市場で価格が下がりにくい傾向があるため、購入後の売却価値を重視する消費者にとって有力な選択肢となり得ます。また、ストレージ容量については、必ずしも大容量モデルが中古市場で有利とは限らないため、価格と需要のバランスを考慮した選択が重要です。 制度設計の観点では、リース会計や端末購入プログラムにおいて、市場実勢に基づく価格見積りの重要性が示されています。中古端末の買取価格は、実際の市場で形成される価格を反映しているため、将来価格を見積もるうえで有用な参照情報となります。 7. 社会的意義 中古スマートフォン市場の拡大は、単に安価な端末を提供するだけでなく、循環型経済の推進にもつながります。端末が中古市場で再流通することで、製品寿命が延び、新品製造や廃棄に伴う環境負荷の低減が期待できます。 その意味で、本研究は金融、会計、消費者行動、環境政策の接点に位置づけられるものです。中古端末の価格形成メカニズムを明らかにすることは、事業者の価格設定や消費者の意思決定を支援するだけでなく、持続可能な資源循環を促進するうえでも意義があります。 8. 今後の課題 今後の課題としては、より詳細なデータを用いた精緻な分析が挙げられます。たとえば、端末状態、販売チャネル、地域差、在庫状況、需要動向などを組み込むことで、より実態に即した価格形成メカニズムを明らかにできる可能性があります。 また、本研究ではiPhoneを中心に詳細な予測分析を行っていますが、今後はAndroid端末に特化した分析も重要です。Android端末はメーカーやモデルの多様性が高く、価格形成の構造もApple製品とは異なる可能性があります。 さらに、スマートフォンは中古端末として再販売されるだけでなく、部品や材料としてリサイクルされる経路もあります。そのため、将来的には再販売市場とリサイクル市場の双方を含めた価値形成メカニズムの分析へ発展していくことが期待されます。 9. まとめ 本研究により、日本の中古スマートフォン市場における価格形成について、次の点が明らかになっています。 第一に、買取価格は発売からの経過時間によって強く規定されています。発売から時間が経過するほど買取価格は低下し、経過時間は中古スマートフォンの価格形成における最も重要な要因です。 第二に、ブランドの影響も大きく、Apple製品はその他メーカー製品よりも高い買取価格を維持しています。特にiPhoneは中古市場において価格が下がりにくく、高い価格維持能力を持っています。 第三に、為替レートの影響は存在するとしても限定的です。ただし、iPhoneについては、為替変動が約3か月程度の遅れを伴って買取価格に影響する可能性があります。 第四に、ストレージ容量は単純な線形関係ではなく、中容量帯が相対的に安定した価値を持ち、低容量・超高容量では価格が低下しやすいという非線形な構造があります。 以上の結果から、中古スマートフォン市場の買取価格は、発売からの経過時間を中心に、ブランド、為替、容量といった複数の要因によって形成されていることが示されています。これらの知見は、中古端末事業者の価格設定、消費者の購買・売却判断、制度設計、さらには循環型経済の推進において有益な情報となります。

はじめに こんにちは。Insight Edgeの松嵜です。 私は入社時から一貫してアジャイル開発のエンジニアとしてプロジェクトに携わってきましたが、今後のキャリアを考える中でのステップアップとして、プロジェクトマネージャー（以下PM）にも挑戦してみたいと考えるようになりました。 そして機会に恵まれ、昨年の約1年間、生成AIを用いた不確実性の高い案件を中心にPMとしてプロジェクトに関わる経験をさせていただきました。 本記事では、その経験をもとに得た気づきを3つご紹介させていただきます。 目次 １. PMは「最適解の探索」と「意思決定」をし続ける仕事 ２. 密なコミュニケーションがより良い意思決定をつくる ３. 先を見据えた意思決定の重要性 チャレンジを支えたInsight Edgeの環境とマインド おわりに １.PMは「最適解の探索」と「意思決定」をし続ける仕事 PMを経験してまず感じたのは、 PMの本質は 「 価値の最大化に向けて、最適解の探索と意思決定を重ねていくこと 」にあるのではないか、ということです。 当初イメージとのギャップ 私はこれまでエンジニアという立場としてアジャイル開発に携わっていたため、不確実性の高いプロジェクトにおいて、「仮説検証と改善を繰り返し、価値を積み上げていく」という進め方自体には馴染みがありました。 ただ、実際にPMとして現場に立つと、その過程は想像以上に「 思考 」と「 判断 」の連続でした。 実際のプロジェクトでは軌道修正の連続 特に生成AIを用いたプロジェクトでは、出力が確率的であるため、最初から正確なゴールイメージを描くことは困難です。 そのため、実際のプロジェクトでは、まず小さく速く形にし、仮説検証とユーザーフィードバックをもとに改善を短いサイクルで繰り返しながら進めていきました。 ただ、検討した改善方針で必ずしも思うような結果が得られるとは限りません。 実際に、進行する中で新たな課題が発生することもあり、その都度「 最適解 」を模索しながら、以下のような見直しや判断を行いました。 優先順位の再定義 プロダクトの核となるため、新機能のUI作り込みよりも精度改善に注力する 改善方針の見直し 出力精度を上げるため、改善方針を繰り返し見直す 仮説検証サイクルの前倒し 不確実性を早期に解消するため、当初の予定よりも仮説検証サイクルを前倒しする 特に改善方針は技術的な内容を含むため、エンジニアと対話を重ねながら、「LLMに与えるコンテキストの渡し方」や「処理フローをどうするか」など、具体的な実現手段も含めて検討しました。 また、プロジェクトの意思決定においては、関係者それぞれが納得感を持つことも重要です。 そのため、各種判断においては、顧客やプロジェクトメンバーと密に対話を重ねていきました。 その積み重ねが、最終的に顧客に満足いただけるプロダクトにもつながったと考えています。 試行錯誤を通じて見えた、PMに求められること プロジェクトにおける意思決定を改めて振り返ると、 「顧客への価値を最大化する」という観点から 「 顧客が本当に求めている価値（言語化されていない期待値）は何か 」 「 アプローチ方法は正しいのか、より適した方法がないか 」 を常に考えながら判断していたと感じます。 正直、エンジニアとして参画していた頃は、 最適な実現方法を考えることに注力してしまっており、 「価値」や「課題」に対して十分に意識を向けることができていませんでした。 今回PMを経験したことで、「 価値や課題そのものを問い直すことの重要性 」に改めて気づくことができたと感じています。 このような経験を通じて、 あるべき姿を問い直し、意思決定をし続けること こそが、プロダクトの価値を最大化するためのPMの役割であり、難しくもやりがいのあるポイントなのではないかと考えています。 ２.密なコミュニケーションがより良い意思決定をつくる 先述した「 意思決定 」を速く、そして精度高く進めていくためには、 関係者間での高頻度かつ深い対話、すなわち 「密なコミュニケーション」 が重要だと感じました。 メンバーを適切に巻き込む プロジェクトにおける意思決定においては、一人で考え続けるだけでは視野が狭くなり、判断材料や選択肢が限られてしまいます。 特に業務改善システムのようにドメイン知識が重要な領域では、顧客の意図や業務理解が曖昧なまま進めると、判断の前提がずれ、手戻りにつながりやすくなります。 一方で、最初からすべてを把握することは現実的ではありません。 だからこそ、 対話を重ねて解像度を上げながら、意思決定に必要な情報を揃えていくこと が不可欠でした。 対顧客・対エンジニアとのコミュニケーション その前提のもと、実際のプロジェクトでは以下のような点を意識しながらコミュニケーションを取っていました。 対顧客：要望の「背景」を深掘りする 要望をそのまま受け取るのではなく、背景にある意図や真の課題まで深掘りする 週次定例に加えチャットも活用し、意思決定に必要な情報をタイムリーに確認する 対面の場では、オンラインでは拾いきれない現場の温度感や補足情報を含めて把握する 対エンジニア：「なぜ」を含めて認識を揃える 日次の共有会を設け、顧客からのフィードバックや課題解決の方針について認識を揃える プロジェクトの中で「何をするべきか」だけではなく、「なぜそれが必要なのか」「何のためにやるのか」といった理由や目的も共有する こうしたコミュニケーションの積み重ねが、実際の意思決定においても大きく活きていました。 例えば、当初考えていた方法で思うような結果が出なかった場合には、 定例を待たずにチャットで関係者に共有・相談を行う ことで、別のアプローチでの検証を素早く進めることができました。 また、コミュニケーションはPM対顧客・PM対エンジニアの個別のやり取りだけではありません。 顧客との定例にエンジニアも同席する ことで、技術的な観点も踏まえた議論ができ、優先順位や進め方をその場で決められる場面も多くありました。 より良い判断は、対話から生まれる こうした連携の結果として、意思決定における大きな認識のずれを抑えながら、プロジェクトを前に進めていくことができたのではないかと感じています。 また、エンジニアとしてプロジェクトに携わっていた頃は、意思決定に迷った際、技術ドキュメントやコードを調べることが解決の糸口になる場面が多くありました。 一方でPMとしては、 早い段階から関係者と対話を重ね、多角的な視点やアイデアを得ること が、より良い判断につながったと感じる場面が多かった印象です。 このような経験から、 関係者と密に対話を重ねていくこと こそが、プロジェクトの重要な意思決定の質を高める鍵なのではないかと考えています。 ３.先を見据えた意思決定の重要性 さらに、技術の進化が非常に速い現代において、顧客への価値を最大化するためには、「 将来の変化を見据えた意思決定 」が重要だと感じました。 生成AIの進化は速い このように感じた背景には、特に生成AI領域における技術やサービスの進化の速さがあります。 作っている機能や仕組みが短期間で陳腐化したり代替される、そんなことも珍しくありません。 実際のプロジェクトでも、 独自開発で実現しようとしていた機能の一部が、Microsoft Copilotなどの標準プロダクト側に追加される これまで課題となっていた精度や挙動が新しいモデルの登場によって解決される ということが発生し、技術の進化によって前提が変わる場面を何度も経験しました。 将来目線での価値を考える このように、前提が大きく変わりうる環境下では、単に目先の課題に対する解決策を考えるのではなく、 最終的に何を実現したいのか という全体像から逆算し、 今取り組むべきことは何か を判断していく必要があります。 その際には、プロダクト全体の観点から 持続的な価値や差別化要素を見極めていくこと 加えて、将来的な拡張性やAI活用を見据えたデータ基盤の整備などの 土台となる仕組みそのものに目を向けること の重要性も感じています。 PMに求められる「未来視点」の役割 このような先を見据えた視点は、PMだけでなくプロジェクトメンバー全員が持つべきものでもあります。 これまでエンジニアとして携わる中でも、技術的な進化やその影響を踏まえながら解決策を考えてきました。 一方でPMには、技術面の変化も踏まえながら、プロダクトのあるべき姿や今後の変化を見据え、中長期的な価値の観点から顧客の意思決定を支援していく役割が求められるのではないかと感じました。 このように、目の前の課題に対してだけでなく、 将来を見据えて判断すること が、真の課題解決や価値創造において重要だと考えています。 チャレンジを支えたInsight Edgeの環境とマインド ここまで、PMを経験して感じた3つのことについて紹介してきましたが、 今回の挑戦にあたっては、Insight EdgeのValueである 「 やり抜く 」 「 やってみる 」 「 みんなでやる 」 を体現する環境とマインドに大きく支えられました。 ※Insight EdgeのValueについては こちらの記事 をぜひご覧ください。 正直なところ、初めての役割を担う中では、進め方を含め判断に迷う場面が何度もありました。 ただ、周囲にはプロフェッショナルな専門性や多様な経歴を持ったメンバーがいたり、上長と気軽に相談できる1on1の場があったりしたため、「 やってみる 」を後押ししてくれる、挑戦しやすい環境があったと感じています。 また、Insight Edgeでは特定の役割に閉じることなく、「 みんなでやる 」という姿勢でプロジェクトを進めていく文化があります。 実際のプロジェクトにおいても、当事者意識を持って取り組むメンバーと一緒に何度も議論を重ねたことで、自分だけでは気づかなかったアイデアや視点を得ることができました。 このように、挑戦を支える環境や組織のマインドがあったからこそ、新しい役割にも前向きに取り組み、「 やり抜く 」ことができたのではないかと感じています。 おわりに PMを経験してみて、エンジニアとしてプロジェクトに携わっていた頃よりも、より広い視点と将来を見据えた視点で、プロジェクトやビジネスのあり方を考えるようになりました。 特に本記事で紹介した3つのこと 「最適解の模索と意思決定」 「関係者との密なコミュニケーション」 「未来視点」 は、今回の経験を通して改めて得た学びであると同時に、職種を問わず重要な点であると感じています。 まだPMとしては新米ですが、今後もこうした学びを大切にしながら、より良い意思決定や価値創出につなげられるよう邁進していきたいと思います。

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

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

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