こんにちは。データサイエンティストの白井です。 今日は、「PPTXやPDFをLLMに読ませるとき、入力をどう刻むと内容理解の精度が変わるのか」を実測した話を紹介します。 1枚ずつ渡すのか、数枚まとめるのか、PDFで丸ごと渡すのか。この違いだけで、精度・処理時間・コストがどう動くかを揃えた条件で比較しました。 先に本記事のポイントを書いておきます。 資料全体を統合した最終的なまとめは、どの刻み方でもほとんど変わりませんでした。 差が出たのは 1ページごとの内容理解の細部 でした。注記や例外条件を拾えるか、グラフの軸や目盛りを正しく読めるか、併記された数値の帰属先を取り違えないか。この記事は、その細部の話です。 はじめに 検証の設計 対象資料と出典 比較する3方式 統制した条件 読み取るべき内容の整理 結果 3方式の総合比較 増えた分に何が入っていたか スライド9 スライド7 使い分けの指針 おまけ：PPTXをPNG化すると画像がズレる おわりに 出典・注意事項 はじめに 私は日々の業務で様々なパワーポイントの資料(PPTX)を目にします。 LLMを業務に活用する場合、LLMにPPTXの内容を理解してもらうことが必須です。 そして、そのコンテキストの上で、LLMと一緒に作業を進めることになります。 社内の提案書や行政資料には、1枚の中にグラフ・注記・用語の定義・分析コメントがまとめて載っているスライドがよくあります。 今回の検証で使った資料の1枚がこれです。 ※出典： RESAS Portal - 地域課題分析ナビゲーション テーマ①　地域の人口減少対策 - （画像化して掲載） 左に散布図、右に分析の視点、下に用語の説明。 そして散布図の上には「鹿児島県薩摩川内市」「全国平均」「説明変数（X軸）38.54」「目的変数（Y軸）78.54」が縦に並んでいます。 この38.54と78.54が どちらに係る値なのか （当該市の値なのか、全国平均の値なのか）は、行間を読まないと分かりません。 実はこの箇所、後述するゴールドデータを人手で作ったときに私自身も一度間違えました。 担当者が分析手順をそのままたどれるように、1枚で「使うデータ」「分析の視点」「用語の定義」まで完結させる構成なのだろうと推測しています。人が手順書として読むには親切ですが、LLMに渡す側から見ると、1枚あたりに読み取るべき情報が多い資料ということになります。 こういう資料をLLMに渡すとき、地味に悩むのが PPTXの渡し方 です。 PPTXが標準オブジェクトだけで作られていればLLMは正確に読めますが、画像貼り付けが使われている場合はvision機能が必要になります。私の周りの大抵のPPTXには画像貼り付けが使われているため、私はいつも全体をPNGにして渡していました。 しかし、ふと、この渡し方で十分だろうか？と疑問が湧き、以下3方式を検証してみようと思いました。 全部まとめてPDFで1回投げるのか 1ページずつ投げるのか 数ページずつブロックで投げるのか 「1枚ずつが丁寧そうだが、リクエスト数が増えて時間もコストも膨らむ」というのは感覚的に分かります。 では、実際にどれだけ細かく読み取れるようになって、どれだけ高くつくのか。 同じ資料・同じプロンプト・同じモデルで3方式を各3試行ずつ回して、その数字を出しました。 方式 リクエスト数 1枚あたり facts件数 処理時間 コスト ① PDF一括 2 2.14 195秒 $0.29 ② 3枚ずつ 9 4.33 573秒 $0.74 ③ 1枚ずつ 21 5.98 816秒 $1.00 1枚ずつは、1スライドから読み取る事実がPDF一括の約2.8倍。ただし時間は約4倍、コストは約3.5倍です。 そして本当の論点は、この「約2.8倍」が中身を伴った差なのかどうかです。件数が多いだけなら意味がありません。記事の後半では、増えた分に何が入っていたかを実際の出力で見ていきます。 検証の設計 対象資料と出典 使ったのは、RESAS Portalで公開されている「地域課題分析ナビゲーション テーマ①　地域の人口減少対策」というPPTXです。 自治体が人口減少の要因を分析する手順を、RESASの実際のグラフを使って解説する資料で、鹿児島県薩摩川内市を例にしています。 全27枚のうち、分析パートである スライド5〜23の19枚 を入力対象にしました。 なお、本記事内でのスライドの利用にあたっては、RESAS Portalのサイトポリシー（政府標準利用規約準拠）を確認したうえで、記事化の可否を問い合わせ窓口にメールで確認し、許諾をいただいています。 出典表記と加工の明示、免責事項は記事末尾にまとめました。 比較する3方式 比較したのは、入力の刻み方だけが違う3方式です。 モデルは全方式で Claude Sonnet 5 を使いました。 ① PDF一括 ② 3枚ずつ ③ 1枚ずつ 入力単位 19枚をラスタライズしたPDF 1本 PNG 3枚ずつ（7ブロック） PNG 1枚ずつ（19枚） 解析リクエスト 1回 7回 19回 最終統合 1回 1回 1回 どの方式も処理は2段階です。 スライド解析 ：渡された画像の主メッセージ・重要な数値・注記・読み取れない箇所をJSONで出させる 最終統合 ：1の結果を全部集めて、資料全体の人口減少要因・優先課題・追加調査事項を整理させる 冒頭に書いたとおり、2の最終統合の出来は3方式でほとんど変わりませんでした。以降で見ていくのは1のスライド解析についてのみです（統合ステップも時間とコストは消費するので、計測には含めています）。 ポイントは、 利用するプロンプトを3方式で完全に同一にしている ことです。 「PDFで渡すときはスライド番号を意識してね」といった補助を足すと、比較しているものが「入力単位の違い」から「プロンプトの違い」に変わってしまうので、あえて共通のまま使いました。 スライド番号のヒントも与えていません。元資料の右下にページ番号が印字されているので、PDF一括でもPNG単体でも、画像から得られる情報量は同じという状態にしてあります。 統制した条件 「入力の刻み方」以外の差は、できるだけ合わせるようにしています。 同じPNG画像を使う ：3方式すべて同一のレンダリング結果。PDFも、そのPNGを結合してラスタライズしたもの 同じプロンプト・同じ出力スキーマ ：解析・統合ともに共通。JSON Schema違反時は1回だけ修復リトライ、という条件も統一 Prompt Cachingは無効 ：キャッシュが効くと「刻み方によるコスト差」が見えなくなるため Batch APIは使わない・並列実行しない ：処理時間を素直に比較するため、逐次実行 temperature等は指定しない ：モデルのデフォルト 各方式3試行 ：LLMの出力はブレるので、1回では判断しない 実行順はランダム化 ：時間帯によるAPIの混み具合が特定方式に偏らないように 最大出力トークンも揃えていますが、ここは1点だけ例外があります。 PDF一括方式は1リクエストで19枚分の解析結果を出す必要があるため、通常の6,000では確実に途中で切れます。 そのためPDF一括の解析のみ32,000を別枠で設定しました。 この統一した条件で、以下の内容をJSONフォーマットとして出力させました。 main_message: スライドのメインメッセージ facts: 読み取った事実 important_numbers: 重要指標 conditions_and_notes: 条件や備考 unclear_points: 不明点 利用したプロンプト(クリックで展開） system_prompt # 役割と目的 あなたは、日本語の行政資料（RESAS Portal「地域課題分析ナビゲーション テーマ①　地域の人口減少対策」）の内容理解を支援するアシスタントです。 この資料は、特定自治体の政策を決定するための完成済み提言書ではなく、RESAS等を用いた地域課題分析の進め方・分析例を示す教材です。あなたの役割は、資料の内容を正確に把握し、人口減少への対応として優先的に検討すべき課題とネクストアクションの叩き台を整理することです。**政策を決定すること自体は行いません。** # 厳守事項 1. **資料に書かれていない事実を補完しない。** 資料から読み取れないことは、推測せず「不確実」「読み取れない」として明示する。 2. **数値・期間・対象地域・年齢区分を正確に区別する。** 自然増減（出生・死亡）と社会増減（転入・転出）を混同しない。 3. **すべての主張に根拠スライド番号を付与する。** 根拠のない主張は出力しない。 4. **出力は「政策決定」ではない。**（後略：政策を断定的に推奨しない） 5. **人口移動や出生に関する分析を、特定の年代・性別・個人の責任として表現しない。** 構造的要因として扱う。 6. **出力は指定されたJSON Schemaに厳密に従う。** # 不確実性の扱い - 数値や文言が読み取れない場合は、無理に推測せず`unclear_points`等の該当フィールドへ記録する。 - 資料内の記載が矛盾する場合は、矛盾として明示し、どちらか一方を勝手に採用しない。 - 資料だけでは判断できない事項は、`limitations`や`cannot_be_decided_from_material`に明示する。 user prompt # スライド／ブロック解析 入力として渡されたスライド（画像、または画像とテキストの組み合わせ）を解析してください。 ## 手順 1. 入力された各スライドについて、主メッセージ・重要な数値・条件や注記・読み取れない箇所を整理する。 2. 複数スライドが同時に入力された場合は、スライド間で関連する内容があれば`cross_slide_findings`に記録する。 3. 資料全体の主張につながりそうな課題の候補があれば`candidate_issues`に記録する（この時点では確定させない）。 4. 疑問点・追加確認したい点は`open_questions`に記録する。 5. **同一スライドについてスライド全体画像に加えて部分拡大画像（crop）が入力される場合**、入力順は「スライド全体」→「左上」→「右上」→「左下」→「右下」（相互に10〜15%重なる）である。cropは細部（小さな数値・注記等）の確認に使い、全体像の把握はスライド全体画像を優先する。 6. **画像に加えて、同一スライドのPowerPointから抽出したテキストが入力される場合**、画像から読み取れる内容とテキストの内容を突き合わせ、食い違いがあれば推測で解決せず`conditions_and_notes`にその旨（どちらの内容がどう異なるか）を記録する。 ## 出力形式 以下のJSON Schemaに厳密に従うJSONのみを出力してください。前置き・後書き・Markdownのコードフェンスは不要です。 { "processed_slides": [5, 6, 7], "slide_findings": [ { "slide_number": 5, "main_message": "", "facts": [ { "statement": "", "evidence": "", "confidence": "high|medium|low" } ], "important_numbers": [], "conditions_and_notes": [], "unclear_points": [] } ], "cross_slide_findings": [], "candidate_issues": [], "open_questions": [] } important_numbers: 資料中の重要な数値を、単位・対象期間・対象地域が分かる形の文字列で記録する（例: "2065年に老年人口割合が約4割へ上昇"）。 conditions_and_notes: グラフの前提条件、注記、例外条件。 unclear_points: 読み取れない・判断できない箇所。推測しない。 cross_slide_findings・candidate_issues・open_questionsの各要素は、オブジェクトではなく1つの文字列にしてください。根拠となるスライド番号を示したい場合は、文字列の中に含めてください。 読み取るべき内容の整理 出力の良し悪しを自分で判断できるように、スライド5〜23の 19枚すべてについて、読み取るべき内容を人手で整理しました （以下、ゴールドデータと呼びます）。 各スライドについて、以下をJSONで記述しています。 main_message ：そのスライドの主メッセージ key_numbers ：重要な数値・定義・対象期間 graph_trends ：グラフの増減・比較関係 notes_and_exceptions ：注記・前提条件・例外 easily_misread_points ：読み違えやすい点 例えば、以下のスライド22は、 ゴールドデータとして以下のjsonを作成しています。 { "slide_number": 22, "main_message": "婚姻件数は令和2年に一時的に減少しているが大きな変動はなく、夫婦の初婚平均年齢も夫30歳前後・妻28歳前後で安定して推移している。", "key_numbers": [ "婚姻件数: 平成25年416件〜令和2年354件（令和元年442件がピーク）", "夫の初婚平均年齢29.2〜30.6歳（最小:平成27年29.2歳、最大:令和元年30.6歳）", "妻の初婚平均年齢28.2〜29.3歳（最小:令和2年28.2歳、最大:令和元年29.3歳）" ], "graph_trends": [ "婚姻件数は416→373→396→392→434→442→354件と増減を繰り返しており単調増加ではない（平成26年・平成28年に一時的な減少）。令和元年442件がピークで、令和2年に354件へ減少", "夫・妻の平均初婚年齢はともに横ばい（変動幅は夫1.4歳・妻1.1歳の範囲内）" ], "notes_and_exceptions": ["出典は鹿児島県「人口動態統計調査」"], "easily_misread_points": [ "左軸（婚姻件数）と右軸（平均年齢）のスケールが異なる二軸グラフのため、棒グラフと折れ線グラフの変動幅を単純比較すると誤解を招く", "夫-平均と妻-平均の2本の折れ線のデータラベルが近接しており、夫の値（令和2年29.4歳）を妻の値と取り違えやすい（本ゴールドデータの初版が実際にこの誤りを犯した）", "分析の視点欄に「婚姻件数は令和2年に一時的に減少しているものの、大きな変動は見られていない」とあるため、実データが増減を繰り返している事実を「単調増加後の減少」と単純化しやすい" ] }, このゴールドはまずLLMに作成させ、その後筆者が結果をレビューし、記載内容が正しいかを確認しました。 特に効いたのは easily_misread_points です。二軸グラフ、単位が%の軸、近接したデータラベル。「ここを外したら読めていないことになる」という点を先に洗い出しておくと、3方式の出力を並べたときに何を見ればよいかが決まります。 結果 3方式の総合比較 3試行の平均値です。 方式 リクエスト数 1枚あたり facts件数 処理時間 入力 トークン 出力 トークン コスト ① PDF一括 2 2.14 195秒 44,896 19,619 $0.29 ② 3枚ずつ 9 4.33 573秒 128,980 48,609 $0.74 ③ 1枚ずつ 21 5.98 816秒 185,388 62,901 $1.00 この結果から、以下が分かります。 1枚あたりに読み取る事実(facts)の件数は ③ > ② > ① の順にきれいに並んだ 。刻みを細かくするほど細かく読む、という素朴な予想通りの結果 ①のfacts件数は明確に少ない 。2.14件は②の約半分、③の約1/3 ②と③の差はほぼ比例 。②→③は件数1.38倍に対し、時間1.4倍・コスト1.35倍。細かく刻んだ分だけコストを払っている 処理速度とコストは　① ＞ ② ＞　③ 。①→③で時間4.2倍・コスト3.5倍 時間・コストの内訳と、比較上の注意（クリックで展開） 上表の内訳は以下です（1試行あたり、API実測値）。 方式 解析ステップ 最終統合 ① PDF一括 1回 133秒 / $0.197 1回 55秒 / $0.089 ② 3枚ずつ 7回 326秒 / $0.471 2回 165秒 / $0.273 ③ 1枚ずつ 19回 520秒 / $0.623 2回 195秒 / $0.377 ②③の統合が2回になっているのは、検証途中で統合ステップの出力上限不足（截断）が見つかり、公平性のため全試行を上限を上げて再実行したためです。失敗した旧リクエストもログに残しているので、②③の計測値には2回分が含まれています（①は上限修正後に実行したため1回）。 統合1回分に揃えて概算すると、時間は195秒 / 409秒 / 617秒、コストは$0.29 / $0.61 / $0.81となり、①→③の倍率は 時間3.3倍・コスト2.8倍 になります。倍率の大小は変わりますが、順序と桁感は変わりません。 処理時間は壁時計ベースです。検証中にPCがスリープした試行があったため、API計測時間との乖離を検知して除外した頑健値を使っています。 料金は検証時点のSonnet 5の導入価格（入力$2.00 / 出力$10.00 per 1M tokens）で計算しています。 増えた分に何が入っていたか 件数の話はここまでです。ここからは、その差が中身を伴っているのかを、実際のスライドと出力内容で見ていきます。 スライド9 まずは、スライド9です。 このスライドは、赤線の総人口だけが右軸で、他の値は左軸で表現されています。 各手法でのimportant_numbers(重要指標)の結果は以下です。 ①＜②＜③と、抽出できた重要指標の数が増えていることが分かります。 特に、①では左右の軸に関する言及はありませんが、②と③ではしっかりと言及がされています。 種別 結果 ① PDF一括 [総人口推計：1995年度〜2045年（実績値・推計値、薩摩川内市）] ② 3枚ずつ ["対象期間：1995年度〜2045年（実績値は〜2020年頃まで、以降は推計値）","総人口軸：右軸、目盛り約65,000〜115,000人","出生・死亡・転入・転出数：左軸、目盛り約1,000〜6,500人"] ③ 1枚ずつ ["対象期間：1995年度頃〜2045年（実績値と推計値を含む、薩摩川内市）","総人口軸（右軸）：目盛65,000人〜115,000人の範囲で表示（薩摩川内市、期間中の推移）","出生数・死亡数・転入数・転出数軸（左軸）：目盛500人〜6,500人の範囲で表示（薩摩川内市、期間中の推移）","2010年度以降、自然減（死亡数が出生数を上回る状態）が拡大傾向（薩摩川内市）","近年、転入・転出ともに増加傾向だが一定の転出超過が継続（薩摩川内市）"] スライド7 次は、スライド7です。 このスライドは、縦軸の単位が%であり、実数ではないことが注意点です。 各手法でのconditions_and_notes(条件や備考)の結果は以下です。 こちらもスライド9同様に①＜②＜③と、抽出した備考の数が増えていることが分かります。 縦軸の単位が%であることに注意を促しているのは、③のみです。 種別 結果 ① PDF一括 ["年少人口＝0〜14歳、生産年齢人口＝15〜64歳、老年人口＝65歳以上（基礎知識欄）。"] ② 3枚ずつ ["グラフは1985年〜2020年頃までが実績値、それ以降が推計値である（グラフ下部の矢印表示）。", "年少人口：0〜14歳、生産年齢人口：15〜64歳、老年人口：65歳以上と定義されている。", "本スライドは自然増減（出生・死亡）と社会増減（転入・転出）の内訳分解には踏み込んでおらず、年齢3区分の増減率のみを扱っている。"] ③ 1枚ずつ ["グラフの縦軸は増減率（%）であり、実数（人数）ではない点に留意が必要。", "2020年以前が実績値、2020年以降（2025年〜2045年）が推計値であることがグラフ下部の矢印で明示されている。", "グラフ上の具体的な数値ラベルは示されておらず、目視での概算読み取りにとどまるため、正確な増減率数値は資料からは確定できない。", "本スライドは特定自治体（薩摩川内市）を用いた「分析例」であり、教材としての位置づけであることがヘッダーのナビゲーション（基礎分析：人口構成→人口増減→自然増減→社会増減→将来人口推計、応用分析：人口構成背景→出生数の増減要因→転入転出要因）から読み取れる。"] これらの結果を見ると、① PDF一括は抽出内容が大雑把になりがちで、一方、②と③は詳細を読み解こうとしていることが分かります。 さらに②よりも③の方が、細かく指標や条件を抽出しようとしていることが分かります。 つまり、facts件数の差は水増しではなく、 軸・単位・注記という「外すと読み違える」項目の差 でした。ゴールドの easily_misread_points に挙げた罠のうち、二軸グラフの識別は②から拾われ、軸の単位まで届くのは③のみ、という並びになっています。 使い分けの指針 結局のところ、 どこまで細部が必要かで選べばよい という話になります。 ① PDF一括 ：大雑把に、早く内容を理解したいとき ② 3枚ずつ ：詳細に把握したいが、完全な細部までは不要なとき ③ 1枚ずつ ：時間をかけても、詳細までしっかり把握したいとき そのうえで、入れておいた方がいい実装上の備えを挙げておきます。 スライド単位の中間出力を必ず持つ 。PDFから直接まとめさせる構成も試しましたが、根拠として引用するスライド番号がズレました（対象外のスライド1〜4を引用する誤りが3試行中2試行で発生）。解析ステップを1段挟むだけで、根拠スライド番号の妥当性は0.886→1.000になりました スライド番号の欠落を機械的に検知する 。まとめて渡す方式は、1リクエストの失敗がブロック全体の欠落になります 出力上限は実測で決める 。当初は解析2,000 / 統合3,000で設定していましたが、実測では1スライドの解析ですら截断されました。最終的に解析6,000 / 統合20,000（PDF一括の解析のみ32,000）です クライアントのタイムアウトを確認する 。PDF一括の解析は128〜136秒かかり、SDKの既定タイムアウト120秒に足りず3回連続で失敗しました。長い入力を1回で投げる方式では、まず疑うべきポイントです 不確実性の明示を許すプロンプトにする 。「読み取れない箇所は推測せず unclear_points に書く」と指示しておくと、スライド11のような罠で断定を回避してくれます おまけ：PPTXをPNG化すると画像がズレる 最後に、LLMに渡す前段でハマった話です。 画像化の処理をLLMに書かせたら、当然のようにLibreOffice（ soffice --headless --convert-to pdf → pdftoppm ）を使う実装が出てきました。ところがこれ、 資料のフォントが環境に無いとフォント代替が起きてレイアウトが崩れます 。今回の資料は Meiryo UI などを使っていて未埋め込みだったため、本文の行数が増え、一部スライドで下の見出し帯にテキストがはみ出して重なりました。入力画像がズレていては、比較検証にすらなりません。 回避するには、 フォントを持っているアプリに描画させる のが確実です。macOSの Microsoft PowerPoint.app はアプリ内部（ Contents/Resources/DFonts/meiryo.ttc ）にMeiryoを同梱しているので、ここを通せば崩れません。 手作業でよければ ：PowerPointから直接PNGエクスポート 自動化するなら ：PowerPointでPDFに書き出してから、 pdftoppm で1枚ずつPNG化 今回は後者を使いました。資料側でフォントを埋め込んでもらえるなら、それが最善です。 おわりに 今回は、情報量の多い日本語行政資料をClaude Sonnet 5に読ませるとき、入力の刻み方だけで読み取りの細かさ・時間・コストがどう変わるかを実測しました。 資料全体を統合したまとめは、どの刻み方でもほぼ同じ。差が出るのは1ページごとの内容理解の細部 その細部の読み取り量は「1枚ずつ > 3枚ずつ > PDF一括」の順で、1枚あたり5.98件 / 4.33件 / 2.14件 増えた分は水増しではなく、軸・単位・注記という「外すと読み違える」項目だった 1枚ずつは最も細かく読むが、PDF一括に比べて時間4.2倍・コスト3.5倍 PDF一括が落とすのは数値そのものより、注記・例外条件・軸の但し書き。しかもこれは出力上限の問題ではなく、モデルが自ら記述を圧縮する挙動 3枚ずつは「まとめて1回」をやめる効果の半分以上を取れる。ただしブロック欠落のリスク管理が必要 図の情報量そのものに起因する誤読は、刻み方を変えても消えない 個人的にいちばん意外だったのは、 方式ごとに強みの質が違った ことです。 細かく刻むと数値の網羅性が上がり、まとめて渡すと資料全体の枠組みを取り違えにくくなる。「精度」という一つの数字に丸めると、この非対称性が見えなくなってしまいます。実運用では、一括入力で全体の枠組みを掴んだうえで、数値の根拠が必要なスライドだけ1枚ずつ精読させる、という組み合わせも十分にありだと思います。 もちろん限界もあります。対象は1つの資料（19スライド）だけで、各方式3試行のみ。中身の確認は筆者の目視です。資料の種類（文字中心の議事録、表中心の財務資料など）が変われば、最適な刻み方も変わるはずです。 それでも、「1ページずつか、まとめてか」を感覚ではなく数字で決めたいときに、当たりをつける材料にはなるかと思います。本記事が、誰かの参考になれば幸いです。 出典・注意事項 出典 出典：RESAS Portal - 地域課題分析ナビゲーション テーマ①　地域の人口減少対策 -（ https://resas-portal.go.jp/region/ ） 加工内容 本記事では、上記資料のスライド5〜23を検証対象とし、PNG画像化・PDF結合・縮小を行った上でLLMへ入力しています。 掲載しているスライド画像は、検証目的での画像化・縮小を行ったものです（RESAS Portalを加工して作成）。 記事化にあたっては、サイトポリシー（政府標準利用規約準拠）を確認のうえ、問い合わせ窓口へメールで確認し、利用の許諾をいただいています。 免責・注意事項 本記事は筆者による技術検証の内容であり、当社での正式な推奨手法や導入事例を示すものではありません。実際の業務適用にあたっては、各組織のガイドラインに従ってください。 本検証はLLMの内容理解支援力を確認する技術検証であり、対象資料や特定自治体の政策を評価・決定するものではありません。 LLMの出力は筆者による技術検証の結果であり、内閣府・RESAS Portal・資料内で言及される自治体の見解ではありません。 資料内に掲載された分析例を、対象地域の最新の人口動態や政策状況として扱わないでください。 人口移動や出生に関する分析結果を、特定の年代・性別・個人の責任として解釈しないでください。 料金は検証時点（2026年8月）のClaude Sonnet 5の価格に基づく実測値です。最新の価格は公式ドキュメントをご確認ください。

はじめに こんにちは。Insight Edgeでデータサイエンティストをしている善之です。 AIでのPowerPoint資料の作成、みなさんも一度は試したことがあるのではないでしょうか。そして、こんな悩みを感じたことはありませんか？ 「生成されたスライドを、手作業で自由に編集できない…」 「デザインがイマイチ…」 「一見かっこいいけど、自分のいつものデザインではないので、編集しづらいし内容も頭に入ってこない…」 私も同じ悩みを抱えながら、AIを使ったスライド生成をあれこれ試してきました。そして試行錯誤の末、 「いつもの自分が作成したかのような」スライドを自動生成する ことで、これらの問題を解決できました。 まず、実際にClaude Codeで作成したスライドの例をお見せします。 ※ 本記事用に用意した架空プロジェクト（食品スーパーの需要予測AI導入検討）のサンプルスライドです どれも私が以前から手作業で作っていたスライドとよく似ていて、「私が手作業で作成した」と言っても気づかない同僚が多いと思います。 「自分のいつものフォーマット」にこだわる理由は2つあります。 内容が理解しやすく、良し悪しをすぐ判断できる ：いつもの自分のフォーマットで出てくるので、自分にとって（おそらく周囲にとっても）内容が理解しやすく、成果物の良し悪しもすぐに判断できます 修正したい時も、いつもの作業ですぐ直せる ：生成物がネイティブなPowerPointオブジェクトで、かつ見慣れたフォーマットなので、テキストの微修正も表の組み替えも普段どおりの操作で完結します 逆に、「他人が作った感」のあるスライドは、一部だけ直したいときにも、どう直せば全体のデザインバランスが保てるのかがすぐにわからず、編集に時間がかかります。 結局AIに修正を頼むことになり、やり取りの往復でさらに時間がかかってしまいます。「それなら最初から自分でゼロから作った方が早かった」というケースもありました。 一般的によく採用されているアプローチには、この観点で限界がありました。 PowerPoint直接生成方式 ：ネイティブなpptxが得られるものの、プロンプトの指示を意図通りに守ってくれないことが多い。デザインの見栄えが良くないケースも多い（この方式でLLMがつまずきやすい具体的な課題は、以前の記事「 LLMによるパワポ自動生成にチャレンジしてわかった課題 」でも解説しています）。 画像生成方式 ：見栄えはそれなりに良いものの、編集できない。「自分の細かな思い」を込められない HTML生成方式 ：見栄えが良くAIによる編集と相性が良いが、自身での編集は難しく、結局AIへの指示に頼ることになる そして、どの方式にも共通するのが、結局「 自分の好み通りのものに仕上げ切るのが難しい 」ということです。 そこでこの記事では、試行錯誤の末に辿り着いた現時点の最適解として、 書式・ルールを全てPythonコードに規定し、Claude Codeのスキルでワークフローを制御する方式 を紹介します。 本記事は、AIによるスライド生成を試したものの「なんか違う」と感じた経験のある方や、自分好みのフォーマットで資料を自動生成したい方に向けた内容となっています。 目次 1. まず試してダメだったこと 2. 辿り着いた最適解：書式・ルールを全てPythonコードに規定する 3. 仕組みの詳細①：デザインをコードに固定する 4. 仕組みの詳細②：品質を担保するワークフロー 5. 仕組みの詳細③：トークン効率 6. 実際に作ったスライドの例 感想・まとめ 1. まず試してダメだったこと 1-1. XML（OOXML）直接編集：Anthropic公式skillをそのまま使う 最初に試したのは、Anthropicが公開している公式skillリポジトリの pptxスキル をそのまま使う方式です。pptxファイルの実体であるOOXML（XML）をAIが直接読み書きします。 結果は、以下の理由で使い物になりませんでした。 デザインが崩壊 ：シェイプの座標・配色・整列といった細かい制御をXMLレベルで正確に行うのは、AIには難易度が高く、デザインが崩壊していました。 コンテキスト消費が激しい ：スライド1枚分のXMLだけでも膨大な量になり、読み書きのたびにコンテキストが圧迫されます。デッキ全体を扱うと、すぐにトークン消費量が膨大になりました。 1-2. 画像生成方式 スライドを画像として生成する方式は、第一印象の見栄えは悪くありませんでした。しかし、 編集できないことが不便でした 。 1文字直すにもAIに指示を出して再生成を待つ必要がありました。 1-3. HTML生成方式 HTML生成は見栄えが比較的良く、編集自体は容易ですが、その編集は基本的にAIへの自然言語指示になります。自分の手で直接修正できず、手触り感がありません。 さらに、デザインの指定も自然言語ベースなので守られないケースがあり、どうしても「HTML感」が出てしまいます。「自分が作った感」のない資料は、レビューも編集もどこか他人事になってしまい、甘くなってしまうことがありました。 1-4. 3方式に共通する敗因 振り返ると、失敗した方式には共通点がありました。 デザインルールを「自然言語のプロンプト」で守らせようとしていた ことです。 「余白は0.3インチ以上」「フォントはMeiryo UI」「この配色を使って」。こうした指示をプロンプトで与えても、AIは毎回少しずつ違う解釈をします。 自然言語での指示に頼る限り、「いつもの自分のフォーマット」の再現性は担保できないと感じました。 2. 辿り着いた最適解：書式・ルールを全てPythonコードに規定する 2-1. コアの発想：デザイン判断をAIから取り上げる 最終的に辿り着いた答えはシンプルで、 デザインをAIに判断させるのではなく、自作ヘルパーライブラリの関数に組み込む というものです。 python-pptxライブラリを活用した、自作のヘルパーライブラリ pptx_helpers.py を構築しました。表を作る make_table 、見出しを置く add_heading 、スライド1枚の中での分割レイアウトを組む draw_split_layout 。これらの関数には、私の「いつものフォーマット」の配色・罫線・フォント・余白が全てハードコードされています。 スキルには、こう明記しています。 関数のデザインこそが承認済みデザイン pptx_helpers.py の make_table ・ add_heading などのヘルパーに組み込まれたビジュアルデザインが承認済みのデザインそのものである。自身の美的判断に合わせて色・罫線・フォント・余白を上書きしてはならない。関数がパラメータを受け付けないなら、それは意図的に固定されている。 AIの仕事は「どの関数を、どのデータで呼ぶか」だけです。自然言語でデザインを守らせるのではなく、そもそも守る以外の選択肢をなくしてしまうのがポイントでした。 2-2. ワークフローはAnthropic公式skillの設計思想を参考に実装 ワークフロー自体はゼロから発想したわけではなく、Anthropic公式のpptxスキルの設計思想を参考にしています。公式skillから以下の考え方を取り入れて、ゼロから自分のskillとして書き起こしました。 参考にした考え方 ：段階的なワークフロー構成、サブエージェントによるレビューの仕組み 独自に実装した部分 ：OOXML直接編集ではなくpython-pptx+自作ヘルパー関数を採用し、自然言語で書かれがちなデザインルールをコードに固定 2-3. リポジトリ全体像 . ├── scripts/ # 共有ライブラリとツール (git管理) │ ├── pptx_helpers.py # スライド構築ヘルパー(全ビルドスクリプトの基盤) │ └── generate_template_images.py # テンプレートから高解像度参照画像を生成 ├── template/ # ベーステンプレート資産 (git管理) │ ├── template.pptx # 「いつもの自分のフォーマット」を体現するベーステンプレート │ └── template_images/ # レイアウト・チャート別の参照画像 ├── output/ # 生成物 (テーマごとに1ディレクトリ) │ └── <theme>/ │ ├── python/ # ビルドスクリプト (git管理。後から修正・再生成可) │ │ └── slideNN_build.py # スライド1枚 = スクリプト1本 │ ├── <theme>.pptx # 生成されたpptx本体 (git管理対象外) │ └── slides/ # AIレビュー用スライド画像 (git管理対象外) └── .claude/skills/ # PowerPoint生成・レビュー用スキル ├── pptx/ │ └── SKILL.md # 中核ワークフロー(作成・編集) ├── pptx_review/ │ └── SKILL.md # 完成デッキのレビュー └── pptx_overall_structure_review/ └── SKILL.md # スライド構成案のレビュー 設計上のポイントは、 スライド1枚をPythonスクリプト1本（ slideNN_build.py ）に対応させ、スクリプトの方をgit管理する ことです。pptx本体はスクリプトからいつでも再生成できるため、git管理していません。 3. 仕組みの詳細①：デザインをコードに固定する 3-1. デザインの原本はPythonコード 私の「いつものフォーマット」の配色・罫線・フォント・余白は、全て pptx_helpers.py の関数の中に実装されています。表なら make_table 、見出しなら add_heading 、分割レイアウトなら draw_split_layout という具合に、スライドの構成要素ごとに専用関数を用意し、スキルには「必ずこれらの関数を使うこと」「関数のデザインを自身の判断で上書きしないこと」を指示しています。 デザインの正解がコードとして1箇所に集約されているので、AIの解釈が揺れる余地がありません。デザインを変えたくなったら関数を直せばよく、以降の生成物全てに反映されます。 3-2. Grand Rules：例外なく守らせる強制ルール スキルの冒頭には「Grand Rules」というセクションを置き、デザイン判断の余地を潰しています。例えば以下のようなルールです。 分割レイアウトは必ず draw_split_layout() を使う コンテンツ領域を左右に分割するスライドで、セクションごとに見出しを個別に置くと、見出しの縦位置がズレるリスクが生まれます。そこで分割とヘッダー配置を1つの関数に閉じ込め、構造的にズレが起きないようにしました。 例えば以下のコードは、コンテンツ領域を「背景」（左1/3）と「課題分析」（右2/3）に分割し、左に前提の箇条書き、右に課題の一覧表を配置して、間を三角コネクタでつなぐものです。 draw_split_layout() が見出し付きの分割エリアとコネクタ用の領域を作って座標を返すので、あとはその座標を使ってコンテンツを描くだけです。 areas, triangle_arrow_areas = draw_split_layout( slide, col_ratios=[ 1 , 2 ], titles=[ "背景" , "課題分析" ], triangle_arrow_width=TRIANGLE_ARROW_WIDTH, ) left_x, content_top, left_w, content_h = areas[ 0 ] right_x, _, right_w, _ = areas[ 1 ] conn_x, _, conn_w, _ = triangle_arrow_areas[ 0 ] add_bullet_list(slide, items=[...], x=left_x, y=content_top, cx=left_w, cy=content_h) add_triangle(slide, x=conn_x + BETWEEN_SHAPE_GAP, y=content_top + TRIANGLE_ARROW_V_PAD, cx=conn_w - BETWEEN_SHAPE_GAP * 2 , cy=content_h - TRIANGLE_ARROW_V_PAD * 2 , direction= "right" , fill=COLOR_BORDER) make_table(slide, ..., x=right_x, y=content_top, cx=right_w, cy=content_h) このコードから生成されるスライドがこちらです。 表は必ず make_table(HeaderCell, BodyCell) で作る 行と列で情報を整理する構造を、シェイプの手動配置で実装することを禁止しています。ヘッダーのスタイル、グループラベルの塗り、セル内箇条書きの体裁は全て関数側で決まり、すべて私好みのデザインにしています。 見出しは必ず add_heading() を使う 文字色と下線色は関数内で固定されており、独自の色を渡すことはできません。 3-3. カラーパレット・タイポグラフィも定数化 色は COLOR_PRIMARY （プライマリの青）、 COLOR_PRIMARY_MID 、 COLOR_PRIMARY_PALE 、 COLOR_ACCENT （強調の赤）などの定数のみ使用可能とし、hexコードの直書きを許容しない形にしています。 単に色を列挙するだけでなく、「Mid Primaryは二次的な塗りの既定色」「Pale Primaryは表の交互行など、背景からかすかに区別できれば足りる場面だけ」といった 使い分けのルール までスキルに規定しています。 タイポグラフィも同様で、フォントはMeiryo UI固定、サイズはスライドタイトル24pt・リード文18pt・Bodyテキスト12〜16ptと決めています。 3-4. スキルに書くだけでは守られない：絶対に守らせたいルールはエラーで止める 運用してみて気づいたのは、 スキルにいくら明確にルールを書いても、AIが守らないことがある という事実です。 象徴的だったのがフォントサイズです。スキルには「Bodyテキストは12pt以上必須」と明記していたにもかかわらず、情報量の多いスライドで「デザイン上、何とか1行に収めたい」と判断したAIが、勝手に11pt以下に下げるケースが見られました。 これは、skillで指示の書き方を強めても根絶できませんでした。 そこで、このルールはプロンプトではなくコードで強制することにしました。共通のフォント設定処理に検証を入れ、12pt未満が渡されたら ValueError を投げて実行そのものを止めます。 MIN_BODY_PT = 12 # Bodyテキストの下限。これ未満はValueErrorにする raise ValueError ( f "フォントサイズ {sz_pt}pt はBodyテキストの下限 {MIN_BODY_PT}pt 未満です。" ) エラーで実行が止まれば、AIは文字数を削る・レイアウトを調整するなど、フォントを下げる以外の道を探すしかありません。これにより、12pt未満のテキストは発生しなくなりました。 4. 仕組みの詳細②：品質を担保するワークフロー デザインの再現性はコードで担保できますが、それだけでは「きれいなだけで中身のないスライド」ができてしまいます。そこでもう1つの柱として、 自分のスライド作成の作法をワークフローとして強制する ことにしました。 4-1. スライド計画：作法を計画段階で強制する スライド作成の起点はAIではなく私です。議事録や過去資料をもとに通常のChat型AIと壁打ちして「何を伝えるか」を固め、その結論を自然言語でスキルに渡すところから始めます。 ただし、その後いきなりスライドをAIに作らせることはしません。実装に入る前に、AIには全スライドについて「Section/Title/Lead text/Layout/Chart type/Body outline」を文字で書き出させます。 どういうスライド設計にするつもりなのかを事前に見える化し、自身の目でレビューしてから作成に取り掛からせることで、「pptxはできあがったけど、全体のストーリーがイマイチなので作り直し」という時間の無駄を避けられます。 この「ストーリーラインを最初に固める」という考え方自体は、以前紹介した「 技術者も知っておくべきプレゼン資料作成術：社内研修会レポート 」の研修内容を、AIのワークフローに応用したものです。 4-2. テンプレートpptx：複製のベースであり、デザインのカタログ template/template.pptx は、私が普段使っているフォーマットをそのまま詰め込んだベーステンプレートです。このテンプレートには2つの役割があります。 1つ目は、 スライドを複製してコンテンツを書き込むためのベース としての役割です。表紙・目次・セクション区切り・標準スライドといった複製元スライドを含んでおり、各スライドはspeaker notesに書いた識別子（ layout_title 、 layout_toc 、 base_template など）で内容を機械的に特定できます。AIはこれをコピーした上にコンテンツを配置していくので、所定のテンプレート（会社テンプレートなど）に沿った体裁が最初から保証されます。 2つ目は、 標準的な視覚デザインをAIに教えるカタログ としての役割です。デザインの原則はPythonコードで規定していますが、「関数をどう組み合わせると、どのような見た目のスライドになるのか」は視覚的に教える必要があります。 そこで、私が普段よく使うレイアウト5種（単一チャート、チャート+左に前提、チャート+右に結論など）とチャート約20種（ツリー、ステップ図、マトリクス、ロードマップ、評価テーブルなど）を参照画像のカタログとして整備し、AIにはこのカタログからデザインを選ばせるようにしました。 4-3. 多段レビュー：「サブエージェントと自分自身によるレビュー」 このワークフローでポイントになるのが、公式skillから踏襲・発展させたレビューの仕組みです。 作成過程のコンテキストを一切持たない新しいサブエージェントを起動し、先入観のない目でレビューさせます。 レビューは2段階あります。 構成レビュー（実装前） ： スライドを作る前に、計画ドラフトを別のサブエージェントがレビューします。レビュアーには自分自身の考え方を踏襲したペルソナを与え、厳しくレビューをするよう指示しています。 さらに、AIのレビューを反映した計画は必ず私自身にも提示され、 私が承認しない限りAIは実装を開始しない フローにしています。スライドを作り込んだ後に構成からやり直すのが最大の時間の無駄なので、実装前の段階で人間のレビューを必ず挟むようにしています。 完成後レビュー ： デッキが完成したら、全スライドを画像化して、別のサブエージェントが目視レビューを行います。要素の重なり、1〜2pxの不整列、低コントラスト、フォントの不統一といったビジュアル品質と、全体のストーリー・各スライドのリード文を全数チェックします。 指摘はMust fix/Nice to fixの優先度付きで返ってくるので、私が最終的に対応する項目を取捨選択し指示を出します。そのうえで、修正が必要なスライドのビルドスクリプトだけを修正・再実行します。 4-4. AI目視レビューのためのレンダリング基盤 AIによる目視レビューにはpptxのスライド画像化が必須です。当初はLibreOfficeで変換していましたが、フォント代替で一部の文字が合成斜体になったり、オブジェクトが欠落したりする問題がありました。 そこでMicrosoft PowerPointのネイティブ変換（macOSはosascript、WindowsはCOM経由）ができるレンダリングCLIを整備しました。 5. 仕組みの詳細③：トークン効率 やってみて想像以上に重要だったのが、トークン効率の設計です。pptx生成は画像・大きなソースコードといった成果物を扱うため、意識しないとメインコンテキストがすぐ溢れ、品質もコストも悪化してしまいます。 そこでスキルには、「品質を落とさずトークンを節約する」ためのルールを明記しました。 ヘルパーライブラリは実装を含めた全文を読ませない ：スキル内の関数リファレンス表とdocstringだけで使用方法が全てわかる設計にする 目視レビューはサブエージェントに委譲する ：全スライドの画像はサブエージェント（独立コンテキスト）側で読み、メインエージェントはテキストの所見だけを受け取る 修正後は変更したスライドだけを再レンダリング・再読込する 6. 実際に作ったスライドの例 冒頭でお見せしたスライドは、いずれも架空の「食品スーパーの需要予測AI導入検討」というテーマで、この仕組みを使って生成したものです。 スライド1枚分のビルドスクリプトがどのようなものか、冒頭2枚目の「需要予測AI導入スケジュール」のスライドを例にお見せします。 import sys from datetime import date sys.path.insert( 0 , "." ) from pptx import Presentation from scripts.pptx_helpers import ( COLOR_BG_WHITE, COLOR_PRIMARY_MID, COLOR_PRIMARY_PALE, COLOR_TEXT_DARK, add_step_arrow, clear_body_shapes, make_schedule_frame, set_base_slide, ) PPTX = "output/techblog_sample/techblog_sample.pptx" # 担当別の塗り色 FILL_OURS = COLOR_PRIMARY_MID # 弊社(白文字) FILL_CLIENT = COLOR_PRIMARY_PALE # 貴社(濃色文字) prs = Presentation(PPTX) slide = prs.slides[ 5 ] # 6枚目のスライド clear_body_shapes(slide) # セクション・タイトル・リード文をまとめて設定 set_base_slide( slide, "導入計画" , "需要予測AI導入スケジュール" , "12月上旬までにパイロット検証を完了し、来期初からの全店展開を目指す4ヶ月の導入計画です" , ) # 年・月・週のヘッダーとタスク分類行を持つスケジュール枠を描画する # (右上の凡例「弊社/貴社」の描画は省略) info = make_schedule_frame( slide, from_date=date( 2026 , 9 , 7 ), to_date=date( 2026 , 12 , 27 ), task_categories=[ "要件定義・データ整備" , "モデル開発・検証" , "導入・展開" ], category_sz_pt= 14 , ) col_xs = info[ "col_xs" ] col_w = info[ "col_width" ] cat_ys = info[ "category_ys" ] cat_h = info[ "category_h" ] # (カテゴリindex, 開始週, 終了週, ラベル, 塗り色)。週は1始まり bars = [ ( 0 , 1 , 3 , "現状分析・KPI定義" , FILL_OURS), ( 0 , 4 , 7 , "販売・気象データの整備" , FILL_CLIENT), # ...残り4本は省略 ] BAR_CY = 520000 for cat_i, w_from, w_to, label, fill in bars: bar_x = col_xs[w_from - 1 ] bar_cx = col_xs[w_to - 1 ] + col_w - bar_x bar_y = cat_ys[cat_i] + (cat_h - BAR_CY) // 2 text_color = COLOR_TEXT_DARK if fill == FILL_CLIENT else COLOR_BG_WHITE add_step_arrow(slide, label, x=bar_x, y=bar_y, cx=bar_cx, cy=BAR_CY, fill=fill, text_color=text_color, sz_pt= 13 ) prs.save(PPTX) デザインに関する記述がほぼないことがわかると思います。座標とデータを渡せば「いつもの自分のフォーマット」で描画される、というのがこの仕組みの本質です。 再掲になりますが、このコードによって生成されたスライドがこちらです。 Plotlyで生成した定量チャートを埋め込むスライドも、同じ仕組みで作れます。 ※本チャートは記事用に作成した架空のサンプルデータであり、当社の実績や導入効果を示すものではありません そして「スライド=Pythonスクリプト」なので、その後の修正は2通りから選べます。大幅に変えたければスクリプトをAIに編集してもらって再実行すればよいですし、文言や表の中身をさっと直したければpptxを開いて普段どおり手で編集できます。 どちらの方法も使える ことが、実運用では非常に便利です。 感想・まとめ 当初の目的は果たせた 今回作った仕組みは、非常に細かいところまで自分の好みに合わせられました。実際にかなり便利で、当初の目的は果たせています。 出てくるスライドは自分にとって読みやすく、大幅な修正が基本的に不要 修正したい時も「いつもの自分のフォーマット」なので、好みの修正がいつもの作業でpptx上ですぐできる 作成時間についても、正確に計測はしていませんが、手作業で作る場合と比べて6割ほど削減できている体感です。 工程 作成時間の削減率 主な担当 構成・ストーリー設計 約5割減 AIが原案、私がレビューと承認 スライド作成 約9割減 AI（ビルドスクリプトの生成と実行） 見直し・手修正 ほぼ変化なし 私 全体 約6割減 削減が効いているのは主にスライド作成の工程で、構成の検討と最後の手修正はそこまで削減できていません。特に手修正がまったく減っていないのは、仕組みが不十分だからではなく、意図的に残している部分です。 減らなかった手修正は、むしろ必要な工程 手修正の中身は、テキストの修正がメインですが、表の項目を大幅に削ったり追加したりすることもあります。 ただ、これはそこまで苦になりません。自分のいつものフォーマットなので修正は楽ですし、「自分が作った感」のあるスライドなので、修正に魂を込めやすいです。 そしてこの手修正は、 最後に人間が自分で語れる資料にするため必要な工程 だと考えています。完全に消すことはできず、最終的にこのスライドをもとに自分の口で説明する以上、消すべきでもないと思っています。 pptxのテイストは企業によって、人によって全然違う これまで様々な企業の資料を見てきて思うのは、pptxのテイストは企業によって本当に違うということです。配色、レイアウトの密度、リード文の書き方、表の使い方など、どれも組織の文化そのものです。さらに言えば、同じ企業の中でも人によって好みが違います。 だからこそ、スライド自動生成は万人向けの汎用サービスで済むものではなく、 個人が自分の好みでカスタマイズできる仕組みであるべき だと思います。テンプレートとヘルパー関数を自分用に作り込むこの方式は、その点で理にかなった仕組みなのではと考えています。 この記事が、自分好みのPowerPointを自動生成したい方の助けになれば幸いです。

こんにちは、Insight Edgeでエンジニアをしている島田です。 現在は社内向けのAIエージェント基盤(名前はLoom)を開発しているため、AIエージェントの開発に携わっている方や社内でエージェント基盤の内製を検討している方へ向けて、エージェント基盤の設計の考え方と内製の判断について紹介したいと思います。 記事を通して書いているのは、汎用エージェントはWebアプリケーションと違ってAPIの形が案件によらず収束するため、案件ごとに変わる部分だけを拡張ポイントとして外に出せば基盤化できる、という話です。 本記事はAIエージェント開発の経験を前提としていないため、前半で汎用エージェントの構造から説明します。実装の詳細にはあまり踏み込まず、設計の考え方や内製の判断に関わるトピックを中心に書いています。 目次 目次 導入背景 汎用エージェントを社内エージェント基盤にする 汎用エージェントの構造 エージェントが基盤化に向いている理由 ワークフロー型から自律型へ 設計パターンの収束 Loomのアーキテクチャと拡張ポイント カスタムツール 基盤に入れるものと入れないものの設計判断 エージェントフレームワークを使うべきか Claude Agent SDK・Managed Agentsと内製基盤 SDKが引き受けるのはハーネスの部分だけ 案件駆動のカスタマイズに即応できる セキュリティ境界を自社内で完結できる 今後の展望と課題 Developer adoption 評価プロセスの型化 モデルの進化と基盤の賞味期限 導入背景 Insight Edgeは住友商事やグループ会社の内製開発組織としてDXコンサルティングやシステム開発をしています。案件は3ヶ月程度のPoC中心で、その後に商用化というパターンがほとんでです。ここ最近の案件はほとんどが生成AI関連で、中でもエージェント案件の比率が上がっています。エージェントの守備範囲と精度が広がってきたことがそのまま案件数に反映されているのだと思います。 一方で開発の実態としては下記のような課題がありました。 APIはFastAPI、フロントはReact、IDaaSはEntra ID/Identity Platform、インフラはCloudRun、エージェントフレームワークはADKなど、案件によって多少違いはあれど似たような技術スタックでゼロから組んでいる PoCで作ったものを商用レベルに仕上げていく過程で、商用レベルのインフラ設計・構築、セキュリティ、オブザーバビリティ、デプロイパイプラインといった非機能面の作り込みを毎回繰り返している 案件にアサインされる開発者は1〜2名程度のため、そこで得た知見が個人の中にしか残らない プロダクト開発であれば同じコードベースに複数人が長期間関わるため自然に知見が溜まっていきますが、1〜2名で3ヶ月のPoCを回して次の案件へというサイクルだと、隣の案件で誰かが同じ実装で同じようにハマっていても気づく機会がありません。私は基盤・ソリューション開発以外の通常案件にも入るため、同じものを何度も作っている感覚が毎回ありました。 汎用エージェントを社内エージェント基盤にする エージェント基盤を作り始めたきっかけは、まだClaude Codeにサブエージェントが登場したくらいの頃にアンケート結果を分析して組織改善の示唆を出すというPoCをClaude Codeで行ったことです。案件固有の作り込みはプロンプトとサブエージェントを軽く用意した程度で、しかもそれ自体もClaude Codeに作らせたものでしたが、アウトプットの質は想定よりかなり高いものでした。汎用のエージェントがそのまま業務のアウトプットに使えるという感触をこのときに持ちました。 上記のPoCもそうですが、弊社のPoCにはユーザーが使うシステムまでは作らず、アウトプットの品質が業務で通用するかどうかだけを検証するものも多いです。Claude Codeの利点はこういった短い期間のPoCでシステム開発をせずに案件の課題解決に集中できることですが、PoCでClaude Codeを使って良い結果が出たとしても、商用化の段階では同等の品質で動くエージェントを自分たちで作らなければなりません。 そんな背景から、社内勉強会で「Claude CodeのCloud版のようなものを作ってみる」という趣旨でプロトタイプを作り、先述のアンケート案件の商用開発に組み込みました。PoCのときに作ったプロンプトやサブエージェントをそのまま移植したところ、Claude Codeと変わらないアウトプットが出てきたため、これを基盤化すれば上記の課題がまとめて解決できるなと思うようになりました。このプロトタイプを案件から独立させ、社内向けのエージェント基盤として開発しているのがLoomです。現在はPdMと私を含めたエンジニア3名弱のチームで開発しています。 汎用エージェントの構造 まず汎用エージェントがどういう仕組みで動いているかを整理しておきます。 Claude Codeのようなものと聞くと複雑なものを想像されるかもしれませんが、コアの部分がかなりシンプルなので自作は思っているより簡単です。実際、汎用エージェントの中核は擬似コードで書くと下記だけです。 # エージェントが使えるツール群。それぞれはただの関数(後述) TOOLS = { "bash" : bash, "read_file" : read_file, "write_file" : write_file} messages = [system_prompt, user_message] while True : # LLMに使用可能なツールの一覧を渡してユーザーの要求に応えるには次にどのツールを使えばよいか考えさせる response = llm.generate(messages, tools=TOOLS) # ツールを呼ばなくなった = 仕事が終わったということ if not response.tool_calls: return response.text messages.append(response) # LLMが返してくるのは実行したいツールの名前と引数だけで、実際に関数を呼ぶのはアプリケーション側 # 例: response.tool_calls == [{"name": "read_file", "arguments": {"path": "/tmp/a.txt"}}] for call in response.tool_calls: result = TOOLS[call[ "name" ]](**call[ "arguments" ]) messages.append(result) ポイントは、LLM自体はツールを実行しないことです。LLMが返すのは呼びたいツールの名前と引数だけで、実際に関数を呼ぶのはアプリケーション側になります。その結果を会話履歴に追加してもう一度LLMを呼び出して考えさせる、というのをツールを呼ばなくなるまで繰り返し、ツールを呼ばなくなった時点がエージェントとして仕事が終わった時点です。 TOOLS に登録する関数も特別なものではなく、下記のような通常の関数です。 def read_file (path: str ) -> str : """指定されたパスのファイル内容を返す""" return open (path).read() この関数の戻り値がそのまま会話履歴に追加され、LLMはその内容を踏まえて次にどのツールを使うか、あるいはもう十分なので回答するかを考えます。 LLMに渡すのは関数の実装ではなく、関数名と引数の定義(シグネチャ)とdocstringだけです。これがそのまま「このツールが何をするものか」の説明になり、ツールの定義はシステムプロンプトと一緒に毎回のリクエストで送られます。つまりLLM側から見えているのは自然言語で書かれた関数の説明の一覧で、エージェントの賢さの本体はモデル側にあります。アプリケーション側が持っているのは上記のループとツール群、それに会話履歴が長くなりすぎたときに要約して詰め直す仕組みくらいです。 もちろん、これを業務で使えるものにするには周辺の作り込みが必要になります。ただし大変なのはループの中身ではなく、その周辺です。ループ自体はClaude Agent SDKのようなものを使えば自分で書く必要すらありませんが、下記は結局自分たちで用意することになります。 誰が使えて、何を実行してよく、いくら使えるのか(認証・認可・利用量の制限) エージェントが実行するコードをどこで動かすのか(サンドボックス) 数分から数十分かかる実行をどう捌くのか(APIサーバーとワーカーの分離、キューイング、オートスケール、進捗をUIへ返す経路) 会話履歴や成果物をどこに保存し、ユーザーごとにどう一覧・再開させるのか(DBとAPI) ユーザーが触るUI そして、これらは案件ごとにほとんど変わりません。 エージェントが基盤化に向いている理由 Web系の案件では共通基盤や社内共通フレームワークの類はあまりうまくいかないという印象を持っています。理由はAPIが案件の要件ごとにバラバラだからです。在庫管理システムと営業支援システムではエンドポイントやドメインモデル、UIまで異なるため、共通化できるのは認証まわりとプロジェクトの雛形くらいで、アプリケーション本体は毎回書くことになります。無理に共通化しようとすると、あらゆる案件の要望を吸収するための設定項目が増え続け、結局誰も把握できないものになりがちです。 一方、汎用エージェントの場合、アプリケーションのAPIは下記のようなものに収束します。 エージェントを実行する スレッド(会話セッション)の一覧・詳細を取得する、再開する 実行中の進捗を受け取る 生成された成果物を取得する 実行を中断する 在庫管理のエージェントでも営業支援のエージェントでも、この形は変わりません。案件ごとに異なるのは「エージェントに何をさせるか」、つまりプロンプト、ツール、ナレッジの部分だけです。 Webアプリケーション 汎用エージェント APIの形 案件ごとに異なる ほぼ同じ形に収束する 案件ごとに変わる部分 アプリケーション全体 プロンプト・ツール・ナレッジ 基盤化できる範囲 認証・雛形程度 API層・実行基盤・インフラのほぼ全部 つまり、API層と実行基盤とインフラを基盤として固定し、案件ごとに変わる部分は拡張ポイントとして外に出したうえで管理画面から設定できるようにすれば、基盤と案件固有部分を分離できます。案件チームは基盤のコードを触らず、管理画面からプロンプトやツールを登録するだけで案件固有のエージェントを組み立てられる、という形が理想です。これがLoomの前提にしている考え方です。 ワークフロー型から自律型へ もう一点、この考え方の前提になっている変化があります。 Loomを作り始めた当時のLLMアプリケーションの主流は、処理の流れをワークフローとして人間が設計し、その一部にエージェントティックな要素を組み込むという作り方でした。当時のエージェントフレームワークも、ワークフローをどう記述するかに主眼を置いたものが多かったと思います。 ただ、開発でClaude Codeを使っているうちに、モデルが賢くなるほど人間がワークフローを組んでやる必然性は下がっていくと感じるようになりました。分岐や手順を人間が固定するのはモデルの判断力を信用しないということなので、モデルの判断力が上がるほどそれ自体が制約になります。逆に自律的な汎用のエージェントループが主体であれば、案件ごとに変わるのはプロンプトやツールの部分だけになります。 とはいえ現場には「この業務は決まった手順で実行させたい」という要求も一定あります。その場合も案件ごとにワークフローをアプリケーションとして作り込むのではなく、フローだけをyamlファイルやコードとして外出しすることで解決できます。今であればdynamic workflowsがそれにあたり、Loomにもこの仕組みを取り込みました。 ※ dynamic workflowsが生まれた背景自体は固定フローの需要ではなく、複雑なタスクを途中で完了にしてしまう・自分が出力の検証が甘い・コンテキスト圧縮を繰り返すうちに当初の目的からずれていく、といったエージェントループの弱点への対処です。ワークフローという言葉が戻ってきてはいますが、フローを書く主体が人間からエージェントに移っている点が従来のワークフロー型とは違います。仕組みとしては同じもので、人間が事前に書いたフローもエージェントがその場で書いたフローも同じように実行できます。 設計パターンの収束 さらに、汎用エージェントの設計パターンが業界的に収束していることも基盤化を後押ししました。 LangChainのDeepAgentsやOpenAIのCodexも、サブエージェントやスキルといったClaude Codeと同じ構成要素を備えており、スキルに至ってはSKILL.mdがオープン仕様として公開され各社のエージェントに採用されるところまで進んでいます。汎用エージェントの構造はある程度一定の形に落ち着きつつあり、設計が収束しているということは基盤としてその構造を固定してもしばらくは陳腐化しないということでもあります。 Loomの設計にあたっては、ManusやAnthropicが公開しているエージェント設計に関する記事を参考にしたり、Claude Codeのシステムプロンプトと挙動の観察から内部の仕組みを推測して取り込むということをやっています。Loomのサブエージェント機構が「サブエージェントを起動するツールが1つある」という形になっているのもこの観察から来ています。 Loomのアーキテクチャと拡張ポイント Loomの構成は下記のようになっています。 Loomアーキテクチャ チャットUIからエージェント実行を投げると、キューを経由してワーカーがエージェントループを回します。エージェントの実行は数分から数十分に及ぶこともあるため、APIサーバーとワーカーを分けて非同期に処理し、進捗はストリーミングでUIに返しています。エージェントがシェルを実行したりファイルを読み書きしたりする場所として、ユーザーごとにサンドボックスを払い出します。インフラはKubernetes上に構築しており、案件ごとにテナントを分離できるようにしています。 基盤としては下記を共通化し、案件開始後にすぐに環境を払い出して利用できるようにしています。 認証 UI API (スレッドやメッセージ取得、サブエージェントやツールのCRUDなど) エージェント インフラ サンドボックス デプロイパイプライン このうちUIは必須でなく、APIだけの利用も可です。案件側で専用のUIを作りたい場合や、既存のシステムからエージェントを呼び出したい場合は、Loomをバックエンドとして使う形になります。 そして案件ごとに変わる部分は、下記の拡張ポイントとして外に出しています。 拡張ポイント 内容 主に作る人 プロンプト 定型プロンプト 案件チーム / ユーザー サブエージェント プロンプトと使用可能ツールのセット 案件チーム / ユーザー Skill Agent Skill 案件チーム / エージェント自身 / ユーザー ワークフロー 決まった手順を固定するためのフロー定義 (スクリプト) 案件チーム / エージェント自身 / ユーザー カスタムツール エージェントに与える案件固有のツール関数 案件チーム MCP 案件固有またはサードパーティMCPサーバー 案件チーム いずれも基盤のコードを変更せず、再デプロイもせずに追加できます。サブエージェントなどはClaude Codeなどのエージェントと基本的に同じため、ここではカスタムツールだけ説明します。 カスタムツール bashやファイルの読み書きなどの基本的なツールはリポジトリに入れてありますが、案件固有の処理を書いたツールは基盤側のリポジトリに入れるべきではないため、外部から拡張可能な形にしています。 下記のような関数を管理画面から登録すると、実行時に動的にツールとして読み込まれます。 def search_product_master (keyword: str ) -> dict : """商品マスタを検索して、該当する商品の一覧を返す""" resp = httpx.get(f "https://internal-api.example.com/products?q={keyword}" ) return { "status" : "success" , "products" : resp.json()} 登録した時点で次のリクエストからエージェントがこのツールを使えるようになり、基盤の再デプロイもプロセスの再起動も不要です。 案件固有のDBや社内APIに繋ぐだけであれば、MCPサーバーを立てるよりこちらのほうが手軽です。MCPの場合はサーバーを実装してデプロイし、その後の運用も抱えることになりますが、カスタムツールは関数を1つ書いて管理画面から登録するだけで済みます。シークレットは別途登録できるようにしており、ツール関数内から参照できるようになっています。 基盤に入れるものと入れないものの設計判断 基盤に何を入れるかの判断基準は案件固有のものかどうかの一点ですが、これは言うほど自明ではなく、そもそも汎用化して取り込める形にできるのか・既存の概念や拡張ポイントに寄せられないか・取り込むだけの価値があるか・将来的に負債にならないか、などを考えなくてはいけません。 ある案件で「エージェントにペルソナを与えてRAGチャットボットとして使いたい」という要望がありました。噛み砕いてみると、基盤だけでは完結しない部分として下記があるとわかりました (他にもありましたがここでは3個だけ)。 ファイル操作やシェルコマンドは必要なく、むしろ塞いだ方がいい ペルソナを持ったエージェントを複数作りたい。UIから質問を投げる(メイン)エージェントを切り替えられるといい ペルソナにナレッジを持たせるためにRAGしたい 1は一見すると特定案件の都合ですが、サンドボックスを使うツールをオフにしてしまえば要件を満たせることがわかり、サンドボックスレスモードを実装しました。こういったモードの分岐は、将来的な機能追加で考慮しなくてはいけない点が増えてしまうデメリットもありますが、今後RAGチャットボット案件もカバーできるメリットの方が大きいと考え基盤に取り込みました。 2は要はメインエージェントを複数定義できるようにしたいという要件です。基盤の機能としてあってもおかしくない機能ですが、取り込み方を工夫しました。既存のメインエージェントとサブエージェントどちらもシステムプロンプト内の <identity> ブロックや末尾につける追加のinstructionだけカスタマイズできればよかったため、既存のサブエージェントテーブルにカラムを追加してメインとして使うかサブとして使うかを判別できるようにしました。概念的には "エージェント" として汎化できたので、複雑さを増やさずに済みました。 3のRAGについては、案件チームが作成したベクトルDBのterraformモジュールをリポジトリに置くだけに留めました。シングルテナントでterraformのワークスペース (HCP TerraformのWorkspace) もテナントごとに分かれているため、ベクトルDBを使いたい場合はそのモジュールを他のテナントでも再利用できます。一方で、ベクトルDBへデータを投入する処理と、エージェントがそこを検索する部分は基盤に入っていません。検索はカスタムツールで繋げば済みますが、投入まで含めると案件ごとの実装が残ります。将来的には下記のように拡張できるかもしれません。 ナレッジをファーストクラスの概念として管理画面から登録できるように ナレッジ登録時にデータをベクトルDBにインポート 各エージェントがどのナレッジを参照できるかを管理画面から選択できるように 何も考えず要望をそのまま機能にしていくと、機能は増えても基盤はどんどんキメラ化していきます。汎用の基盤では、要望をどう実装するかよりも、どういう概念として取り込むかを考え、基盤チームがその判断を担っていくことが大切だと感じています。 エージェントフレームワークを使うべきか LoomはGoogleのADK(Agent Development Kit)というエージェントフレームワークの上に構築されています。作り始めた当時はエージェントループも汎用エージェントの構造も理解していなかったため、フレームワークの実装自体がエージェントの仕組みを理解する教材になりました。 一方、開発・運用していく中でフレームワークが制限になる部分もいくつか見えてきました。例えば、下記についてはADKの機能は使わず自前実装に置き換えています。 コンテキスト圧縮 - 当時はトークンベースの圧縮方式が提供されていなかった サブエージェント - ADKのAgentToolではサブエージェントのセッションやイベントが永続化されない問題あり LLMプロバイダ層(GPT/Claude) - ADKはGemini以外のモデルのサポートが薄い。内部で使っているLiteLLM自体も新モデルへの対応が遅れる場合があった また、ADKはセッションやイベントをADKが管理するテーブルに永続化してくれますが、Loomではそれとは別にスレッドやメッセージの自前テーブルを持っており二重管理になっています。 ADKの機能で使ってない部分も多く、先述の通りエージェントは中核構造がシンプルなことから、独自の永続化層やワークフロー記述まで持ち込む多機能なフレームワークに乗るメリットは思ったより小さいと感じています。長期に育てるアプリケーションであれば、エージェントループの周辺は薄く自前で持つか、後述のClaude Agent SDKのようにハーネスだけを提供するものに寄せるかのどちらかがよいのかなと思います。 一方で、3ヶ月のPoCでゼロから作るのであればフレームワークを使うのが正解かもしれません。動くものに最速で到達できますし、PoCの寿命であればロックインのコストは顕在化しません。 Claude Agent SDK・Managed Agentsと内製基盤 現在は、Claude Agent SDKやManaged Agentsなど、汎用エージェントをアプリケーションに組み込むための選択肢は充実してきています。 一方で、それらを使えば全部解決でプラットフォームが不要になるわけではありません。 SDKが引き受けるのはハーネスの部分だけ Claude Agent SDKが引き受けてくれるのは、エージェントループ、ツール実行、コンテキスト管理、サブエージェントといった、いわゆるエージェントハーネスの部分です。しかしエージェントを組織に提供しようとすると、認証とユーザー管理、テナントごとの分離、利用量の管理と上限設定、スレッドや成果物をユーザーごとに保存して一覧させるDBとAPI、長時間の実行を捌くインフラ、そしてUIが必要になります。エージェントがコードを実行するサンドボックスも自前で用意することになります。 2026年8月時点でManaged Agentsはもう少し広く、サンドボックスのホスティングやセッション状態の管理、イベント履歴の永続化までを引き受けてくれます。それでも、エンドユーザーの認証・認可、自社のユーザーとセッションの紐付け、UI、ブラウザまで届ける最後の区間は自前です。加えて企業のポリシーや扱う情報によっては結局セルフホスト型サンドボックスが必要になったり、そもそもManaged Agents自体が選択肢に入らないこともあります。 公式の選択肢を使えば基盤が不要になるわけではなく、基盤の一部が楽になるというのが正確なところだと思います。 案件駆動のカスタマイズに即応できる ハーネス部分も含めて自分たちの好きなようにカスタマイズしていける点は思ったより大きいです。先述のチャットボット案件のように、案件から出てきた要望を短期間で基盤の機能にするという動き方は内製だからできることです。 セキュリティ境界を自社内で完結できる エージェントは任意のコード実行を伴う仕組みのため、それをどこで動かすのかはセキュリティ上の重要な論点になります。住友商事のようにセキュリティ要件が厳しく、扱う情報の機微度も高い相手に対して、実行環境も含めて自社の管理下の環境で閉じていると言えることはそれ自体が価値になります。 今後の展望と課題 Developer adoption 基盤は作れば使われるというものではなく、社内で自然に使われるようにしていくことが重要です。エンジニアに絞ると、少なくとも下記のようなハードルがあるのかなと思います。 誰かが作ったものを使うより自分で開発したい そもそもLoomが何なのか、どこまでできるのかわからない 基盤やツールで大部分が完結してしまう案件はつまらない 特に3つ目は基盤が目指している状態そのものが裏目に出ています。 これらを解決するには、基盤の開発やLoom案件の対応をLoomチームに閉じず、InsightEdgeの開発者が広く開発に関われる状態を作るのがいいと考えています。基盤を開発した人が自分でもLoomを使った案件にFDE的に入り、そこで得た示唆を基盤の機能やアイデアとして戻す、というサイクルが回れば、上記の3つは同時に解消に向かいます。 この変化はInsightEdgeのエンジニアリング部全体に関わってくる話のため、社内のDevexチームやEM、リードエンジニアにも協力してもらいながら進めています。 評価プロセスの型化 LLMやエージェントの案件では、顧客の求めるアウトプットが出ているかの精度を上げていく作業が中心になります。そこで問題になるのが、同じ入力で毎回同じ品質が出るかという再現性と、プロンプトやスキルを直したときに過去のフィードバックへの対応が壊れていないかという回帰です。これを担保するのが評価で、本来はどの案件でも持つべきものですが、弊社として方法が確立できていません。 まず方法論を固めたうえで、基盤の機能としても組み込めるといいと考えています。基盤で評価すれば自然と弊社標準のプロセスに乗る、という状態が理想です。仕組みとして基盤に置くのが合理的だと思っているのは下記あたりです。 評価用データセットやルーブリックの登録。中身は案件固有でも器を共通にできる点で、他の拡張ポイントと同じ構図 データセットに対する一括実行。キューやワーカー、実行記録、コスト計上はすでにあるので、案件ごとに作るより基盤へ置くのが自然 実行時のモデルやプロンプト、スキルのバージョンを記録し、同じ条件で比較できるようにする 導入背景で挙げた「知見が個人の中にしか残らない」という課題は、アプリケーションの実装だけでなくこの部分にも当てはまります。案件で得た評価の観点が基盤の上に残れば、似た業務の案件で型として再利用できます。 モデルの進化と基盤の賞味期限 エージェント案件が増えている根本の原因は、モデルの守備範囲と精度が広がり続けていることです。これは裏を返せば、モデルの欠点を補うために書いたコードは、モデルが賢くなるほど不要になっていくということでもあります。振り返ると、まずClaude CodeやDeep Agentsのようなハーネスが登場し、今はそこにインフラをバンドルしたManaged Agentsのような形が出てきています。 エージェントを「ビジネスロジック + ハーネス + インフラ」の3層に分けて考えてみると、このうちハーネス層はコンテキスト管理やメモリのようにモデルの欠点を補う性格が強いため、モデル側の進化とともに吸収されていくかもしれません。インフラ層も本記事で書いてきたように収束しているからこそ遠からずコモディティ化していくと思います。 最後まで残るのはビジネスロジック層だと思います。プロンプト・スキル・ツール・評価データセットとして蓄積された業務知識は、モデルがいくら賢くなっても誰も肩代わりできません。そしてAGENTS.mdやskillsといった標準仕様の普及によって、特定のハーネスや基盤から独立したポータブルな資産になりつつあります。 Loomも、将来的にはハーネスとインフラが置き換わり、ビジネスロジック層しか残らないかもしれません。それでも、業務知識を移植可能な形式で蓄積する取り組みを今の時点から続けておけば、実行エンジンが何に置き換わっても資産と運用の型はそのまま持ち越せます。モデルの進化で何が消え、何が資産として残るのかを念頭に、どの層に投資し、どの層はいつでも捨てられるようにしておくかという視点で基盤の戦略を立てていくことが重要だと考えています。 以上、本稿がAIエージェント基盤の設計や内製の判断の一助になれば幸いです。

Insight Edge のデータサイエンティストの中野です。 「最近発売したこの商品、価格を上げたらどれくらい売れ行きに影響がありますか？」。 実務でよくある相談です。ところが頼りになる実績は数週間分しかありません。 こうしたデータにLightGBMのような表現力の高いモデルを当てはめると、 数点の偶然のばらつきをそのまま学習してしまい、 「値上げすると売れやすくなる」といった現実にはありえない結論が出ることもあります。 本記事では、この状況に 階層ベイズ を当てはめます。 店舗×ブランドごとの価格弾力性（値下げの効きやすさ）を題材に、 素直な回帰がどう壊れるかを見たうえで、階層ベイズがそれをどう救うかを見ていきます。 目次 なぜベイズなのか 問題設定：少量データから価格弾力性を推定する 使うデータ 推定したいもの 方法1（個別回帰）：店舗×ブランドごとに個別回帰する 方法2（全体回帰）：全体をまとめて1本の回帰にする 方法3（階層ベイズ）：階層ベイズで両者の間を取る 階層ベイズのモチベーション 階層ベイズの考え方 階層ベイズの実装 収束の確認 モデル診断：予測はどれくらい当たっているか 結果1：ありえない推定値が消えた 結果2：「正解」と比べる 追加実験：縮小の強さはデータで決まる まとめ なぜベイズなのか ベイズ統計は、推定したい値を1つの数値ではなく確率分布として扱う枠組みです。 「知っていること（事前分布）」と「観測されたデータ」を突き合わせて、 「データを見たあとの確からしさ（事後分布）」を得ます。 そのため、データが少ない状況で役に立つことがあります。 ベイズ統計が有効な理由を3つ挙げます。 1. 知っていることを事前分布として入れられる 「値下げすれば売れやすくなる」「1日に売れる量はせいぜい数100個」といった常識を、 モデルにあらかじめ書き下せます。 データが数点しかなくても、常識から外れた推定値に振り切れるのを抑えられます。 これは、データを都合よく歪める操作ではありません。 データが増えるほど事前分布の影響は薄れ、最終的にはデータ側の主張がほぼそのまま残ります。 効くのはあくまで「データが足りず、何も決められない」領域だけです。 2. 他のユニットの情報を借りられる（階層ベイズ） データが少ないユニットの推定値を、他の店舗・他の商品の傾向側に引き戻します。 個別に推定するのと全部まとめてしまうのとの中間にあたり、 しかも引き戻す強さ自体をデータから決められます。 3. 不確実性が事後分布としてそのまま出てくる 実務では期待値だけでなく、上振れ・下振れしたときにどうなるかを知りたいことも多いです。 例えば商品の発注量を決めるとき、品切れを絶対に避けたいのか、売れ残りを抱えたくないのかで、 同じ需要予測からでも選ぶべき発注量は変わります。 前者なら分布の上側を、後者なら下側を見ることになり、期待値1点では判断できません。 ベイズの出力は1点の数値ではなく確率分布なので、確率でも分位点でも、意思決定に必要な形で取り出せます。 問題設定：少量データから価格弾力性を推定する 使うデータ Rの bayesm パッケージに含まれる orangeJuice データを使います。 1990年代前半、シカゴのスーパーマーケットチェーンのデータです。 データ数は、106,139行（83店舗 × 11ブランド × 121週）です。 各行は、「ある店舗の、ある週の、あるブランド」の販売数と価格を表しています。 なお、今回の実験で推定に使うのは、このうち 最初の10週だけ とします。 理由は、「新規出店・新商品投入から10週しか経っていない」というデータが不足している状況を想定するためです。 残りの期間のデータは推定には使わず、後半で「正解」として利用します。 実際に3ユニット（店舗 × ブランド）を取り出して、価格と販売数の関係を見てみます。 データは少ないものの、複数の価格での販売実績が取得できているものもあれば、ほとんど価格が動いていないものもあります。 すべての商品が店舗,ブランド=(052,08)のユニットのように、複数の価格帯でデータが取得できていれば、ある程度の意思決定には利用できます。 しかし、そうでないユニットも多く、実務では「データが少ないから推定できない」となることもあります。 このような状況で、少しマシな推定をするために、本記事では階層ベイズを使います。 推定したいもの 推定対象は、 各店舗・ブランドの価格弾力性 とします。 これは「価格を1%上げたとき、販売数が何%減るか」を表す指標です。 販売数と価格の両方の対数を取って回帰すると、その傾きがそのまま弾力性になります。 そこで販売数と価格の関係を次のようにモデル化します。 この式は、販売数の対数は、店舗 、ブランド ごとに異なる切片 と傾き を持つ正規分布に従うと仮定しています。 この が各店舗・ブランドの価格弾力性です。 一般的には安いほど売れやすくなるため、マイナスの値になります。 方法1（個別回帰）：店舗×ブランドごとに個別回帰する を推定するため、まず最も素直な方法から始めます。 店舗×ブランドの組み合わせごとに独立した回帰を全ユニットでまわすだけです。 これを「個別回帰」と呼びます。 結果を見てみましょう。安定して推定できた例と、そうでない例を並べます。 左図（店舗052×ブランド08）は素直に右下がりで、弾力性 -5.90 と常識的な値になっています。 これは価格を1%値下げすると、販売数が5.9%増えることを意味します。 過学習している感じはありますが、納得感のある結果であり、とりあえず翌週の意思決定には活用しても良さそうに見えます。 問題は右図（店舗131×ブランド09）です。 弾力性 +4.85、つまり「値上げすると売れる」という推定になっています。 図を見れば理由は明らかで、価格がほとんど動いていないところに8点が散らばっているだけです。 ここに無理矢理直線を引けば、たまたま右上がりになることもあります。 常識的に考えれば、「値上げすると売れる」という結論はありえません。 方法2（全体回帰）：全体をまとめて1本の回帰にする 理想的にデータが揃っていない場合でも、意思決定のためには何かしらの情報が必要です。 そこで、逆に店舗差もブランド差も無視して、すべての実績をまとめて1本の回帰にします。 これを「全体回帰」と呼びます。 弾力性は -1.07となりました。 これは価格を1%値下げすると、販売数が1.07%増えることを意味します。 データ量が8,129行あるので当然です。 ただしこの数字は「全店舗・全ブランドの平均」でしかありません。 プライベートブランドもプレミアムブランドも、都心店も郊外店も、すべて同じ -1.07 として扱われます。 どうしてもデータがない場合では、個別回帰よりは多少役に立つ結果ですが、誤った意思決定を導く可能性もあります。 方法3（階層ベイズ）：階層ベイズで両者の間を取る 階層ベイズのモチベーション これまでの結果を整理すると、個別回帰と全体回帰の間には次のようなトレードオフがあります。 方法1（個別回帰） ：ユニットごとの違いは表現できるが、データが足りず推定が不安定 方法2（全体回帰） ：推定は安定するが、ユニットごとの違いが消える なんとか、両者の間を取ることはできないでしょうか。 階層ベイズの考え方 階層ベイズの考え方はシンプルです。 「各ユニットの弾力性はある共通の分布から生まれている」と仮定します。 数式で書くと次のようになります。 各ユニットの弾力性 （店舗 、ブランド ）を、全体平均 と店舗効果 とブランド効果 の和に分解します。 そして店舗効果とブランド効果は平均0の正規分布から生まれると仮定します。 データが少ないユニットは、他の店舗・他のブランドの情報を借りて全体平均側に引き戻されます。 これを shrinkage（縮小）と呼びます。 なお、 は全店舗・全ブランドに共通する弾力性の基準値を表します。データが少ないユニットほど、推定値はこの の近くに引き寄せられます。 また ・ は、弾力性が店舗間・ブランド間でどれだけばらつくかを表します。この値が小さいほど「どの店舗・ブランドも似たようなもの」とみなして強く引き戻し、大きいほど各ユニットの実績を尊重します。 この値自体もデータから推定される 点が重要で、縮小の強さを人が決め打ちしなくて済みます。 と 自体にも事前分布を置きます。 の中心を にしたのは、「値下げすれば売れる（符号は負）」「ただし1%の値下げで販売数が10倍になることはない」という感覚を表しています。 側は、ばらつきが負にならないよう HalfNormal を使っています。 なお切片 も同じように分解しますが、ここでは省略します。 階層ベイズの実装 PyMCで書きます。今回はPyMC 6系を使いました。 以下にコードのモデル部分を示します。前節の数式がほぼそのままコードになります。 sigma_beta_store が店舗間のばらつき です。 ZeroSumNormal は効果の和を0に固定する分布で、これがないと「全体平均を1下げて全効果を1上げる」という変換で尤度が変わらず、両者が別々には決まりません（実際、外すと収束しませんでした）。 with pm.Model(coords=data.coords) as model: log_price = pm.Data( "log_price" , data.log_price, dims= "obs" ) store_index = pm.Data( "store_index" , data.store_index, dims= "obs" ) brand_index = pm.Data( "brand_index" , data.brand_index, dims= "obs" ) # 全体平均（切片と弾力性） mu_alpha = pm.Normal( "mu_alpha" , mu= 9.0 , sigma= 5.0 ) mu_beta = pm.Normal( "mu_beta" , mu=- 3.0 , sigma= 3.0 ) # 店舗間・ブランド間のばらつき（＝縮小の強さを決めるつまみ） sigma_alpha_store = pm.HalfNormal( "sigma_alpha_store" , sigma= 1.0 ) sigma_alpha_brand = pm.HalfNormal( "sigma_alpha_brand" , sigma= 1.0 ) sigma_beta_store = pm.HalfNormal( "sigma_beta_store" , sigma= 1.0 ) sigma_beta_brand = pm.HalfNormal( "sigma_beta_brand" , sigma= 1.0 ) # 店舗効果・ブランド効果（和ゼロ制約つき） alpha_store = sigma_alpha_store * pm.ZeroSumNormal( "a_store" , dims= "store" ) alpha_brand = sigma_alpha_brand * pm.ZeroSumNormal( "a_brand" , dims= "brand" ) beta_store = sigma_beta_store * pm.ZeroSumNormal( "b_store" , dims= "store" ) beta_brand = sigma_beta_brand * pm.ZeroSumNormal( "b_brand" , dims= "brand" ) # 店舗×ブランドごとの弾力性（あとで取り出すため記録しておく） pm.Deterministic( "elasticity" , mu_beta + beta_store[:, None ] + beta_brand[ None , :], dims=( "store" , "brand" ), ) # 尤度：各観測に、その店舗・ブランドの切片と傾きを当てる alpha = mu_alpha + alpha_store[store_index] + alpha_brand[brand_index] beta = mu_beta + beta_store[store_index] + beta_brand[brand_index] sigma = pm.HalfNormal( "sigma" , sigma= 1.0 ) pm.Normal( "log_move" , mu=alpha + beta * log_price, sigma=sigma, observed=data.log_move, dims= "obs" , ) idata = pm.sample(draws= 8000 , tune= 4000 , target_accept= 0.95 ) 収束の確認 計算した結果を可視化して、MCMCがきちんと収束しているかを確認します。 左が事後分布、右がサンプリングの軌跡です。 左の4本の線は、異なる初期値から計算した分布です。 ほとんどのパラメータは4本の線が重なっており、初期値に依存せず同じ分布に収束していることを示しています。 sigma_alpha_brand （切片のブランド間のばらつき）だけが、4本の線が少しずれており、収束がやや不十分です。 右のグラフは、サンプリングの軌跡を表しています。 どのパラメータも、サンプリングが十分に混ざっており、初期値の影響を受けていないことがわかりますが 正直グラフを見ただけでは、収束しているかどうかの判断は難しいです。 sigma_alpha_brand の妥当性を確認するため、 sigma_alpha_brand の有効サンプルサイズ（ESS）を計算したところ、 32,000サンプル（8,000 × 4チェーン）中、314しかありませんでした。経験的に、少ないと感じます。 ブランドが11個しかないことが影響していそうですが、同じ11個から推定している sigma_beta_brand （弾力性のブランド間のばらつき）は ESS 1,700超で問題なかったため、原因の断定はできませんでした。 しかし、今回の推定対象である弾力性891件は、ESS 7,000超と十分問題なかったため、とりあえずこのまま進めます。 モデル診断：予測はどれくらい当たっているか 収束の確認は「MCMCが正しく動いたか」の話でしかありません。 サンプリングが完璧でも、モデルの仮定が現実に合っていなければ推定値は使えません。 そこでモデル自体の妥当性も見ておきます。 予測の幅 このモデルがどれくらいの幅で予測しているのかも見ておきます。横軸に実測値、縦軸に事後予測の平均±1σを取ったのが下の図です（8,129点から400点を抜粋）。 点が赤い破線（予測=実測）の周りに乗っていれば予測が当たっており、 エラーバーの長さがそのままモデルの予測幅 になります。 予測の標準偏差は中央値で 0.49（log空間）でした。元のスケールに直すと およそ1.6倍・1/1.6倍の範囲 ということになります。週に1,000個売れる商品なら、±1σが 610〜1,640個という幅です。 正直なところ、実務で使うには広い幅です。今回は価格しか説明変数に入れていないので、チラシ掲載や陳列の有無といった要因がすべて誤差に回っているためです。ただし この幅を明示できること自体がベイズの利点 でもあります。点推定だけを見て「1,000個売れます」と報告するより、この幅を添えて意思決定してもらうほうが誠実です。 なお±1σの区間に実測値が入る割合は74.8%でした。正規分布なら68.3%なので、やはり予測幅がやや広めであることと整合します。 LOO-PIT もうひとつの手法として使うのは LOO-PIT（Leave-One-Out Probability Integral Transform） です。 ある観測値を1件除いた条件での予測分布を計算し、その予測分布の中で実際の観測値が何パーセンタイルに位置するかを求めます。 これを全観測について行うと、モデルが正しければ結果は一様分布になります。 理屈は単純で、予測分布が当たっていれば、実測値が上位10%に来ることも下位10%に来ることも同じくらいの頻度で起きるはずだからです。 赤い破線が理想（一様分布）です。おおむね平坦で、大きな破綻はありません。 しかし、両端が薄く中央がやや厚いので、これは予測分布がわずかに広すぎる状態です。 逆に両端が厚ければ予測が狭すぎるということで、外れ値を吸収するために正規分布をt分布に置き換えるといった対応（BDA3 17章の頑健推測のモデル）を検討することになりますが、今回はその逆です。 とりあえず、正規分布のままで問題ないと判断します。 結果1：ありえない推定値が消えた まず、方法1（個別回帰）で問題になった2ユニットがどうなったかを見ます。 赤い破線が個別回帰、緑の実線が階層ベイズです。 右図（店舗131×ブランド09）を確認すると、 個別回帰では +4.85、つまり「値上げすると売れる」でしたが、階層ベイズでは -4.40 と素直な右下がりに変わりました。 他の店舗・他のブランドが「オレンジジュースは値下げすれば売れる」と教えてくれた結果です。 左図（店舗052×ブランド08）も -5.90 から -3.77 へと、やや全体寄りに引き戻されています。 こちらはもともと妥当な値でしたが、10点の実績を全面的に信用するのではなく、全体の傾向も加味した値になっています。 残りの891ユニット全体でも同じことが起きています。 以下のフォレストプロットは、縦軸がユニット、横軸が弾力性を表しており、点が事後平均、線が 94%区間です。赤い破線は個別回帰、緑の実線は階層ベイズです。 個別回帰では -128 や +77 という、経済的にありえない値が出ていました。 階層ベイズではすべてのユニットが -8.06〜-0.66 に収まり、符号が正のものは1件もありません。 結果2：「正解」と比べる 最後に、10週ではなく全期間121週のデータで推定した弾力性を「正解」として、 3手法の直線がどれくらい近いかを眺めてみます。 黒が正解（全期間121週で個別回帰した結果）、赤い破線が個別回帰、紫の点線が全体回帰、緑が階層ベイズです。 左（店舗052×ブランド08）では、個別回帰の赤が正解よりかなり急です。10点の実績を信じすぎて値引き効果を過大評価しています。階層ベイズの緑はそこから正解側に寄っており、まずまずの位置に来ています。 右（店舗131×ブランド09）は、赤が右上がりなので論外です。緑は正解より少し急ですが、少なくとも同じ向きを向いています。 全体回帰の紫は、どちらのパネルでも同じ傾きです。当然ですが、これでは店舗ごとの違いは何も分かりません。 「なんとなく良さそうになった」くらいの結論です。 価格弾力性の推定精度では、階層ベイズが全部の点で勝っているわけではありません。 精度測定には誤差のRMSEを測定するなどを行うことになりますが、 今回の実験は個別回帰と全体回帰よりも、観測したデータをある程度説明しつつ、弾力性も現実的な値を出すことができるなど、 納得感のある推定値を出すことができたため、よしとします。 このモデルの良し悪しを判断するには、推定値を何に使うかが重要です。 例えば、商品ごとの金額のバランスを決める場合は、各ブランドの弾力性の相対的な大小関係に整合性が取れていることが重要であり、誤差のRMSEなどの絶対値の精度は一番重要な点ではありません。 一方で単体の商品の利益を最大化する場合は、絶対値の精度が重要になります。 まとめ 10週分のデータから価格弾力性を推定する、という問題を3つの方法で解きました。 個別回帰 ：18%が推定不能、3.9%が「値上げすると売れる」。ユニットごとの違いは出せるが壊れる 全体回帰 ：安定するが全891ユニットが同じ値。店舗差・ブランド差が消える 階層ベイズ ：符号が正のユニット0件、推定不能0件。ユニットごとの違いも残る 階層ベイズが常に最良だと言うつもりはありません。誤差を測れば全体回帰に負ける場面もありますし、収束しきらないパラメータも残りました。それでも、 ありえない推定値を出さず、かつユニットごとの違いを残す という性質は、少ないデータで意思決定をしなければならない場面で効いてきます。 どの手法を選ぶかは、その推定値を何に使うか次第です。全体の値引き方針を決めるだけなら全体回帰で足りるかもしれません。店舗ごと・商品ごとに施策を変えたいなら、全ユニットが同じ値の手法は使えません。今回のように「データが数点しかないが、ユニットごとの判断がしたい」という状況こそ、階層ベイズの出番だと考えています。 参考 bayesm: Bayesian Inference for Marketing/Micro-Econometrics PyMC公式ドキュメント ArviZ公式ドキュメント Gelman et al., Bayesian Data Analysis, Third Edition （BDA3）。モデル診断は6章、頑健モデル化は17章 追加実験：縮小の強さはデータで決まる とは何か ここまで「他のユニットから情報を借りる」と言ってきましたが、借りる量を決めているのが です。 モデルの定義に戻ると、 は 弾力性が店舗間・ブランド間でどれくらいばらついているか を表す値でした。 この値が小さいということは、「どの店舗も似たような値引き効果を持つ」とモデルが考えている状態です。すると各ユニットの推定値は全体平均の近くに強く引き戻されます。自分のデータが多少変な値を示していても、「そんなに店舗差はないはずだ」と却下されるわけです。 逆に が大きければ、「店舗ごとに全然違う」という前提になります。各ユニットは自分のデータを信じてよく、引き戻しは弱くなります。つまり は、全体回帰（全部同じ）と個別回帰（全部バラバラ）の間を調整するパラメータです。 を変えてみる 本当にそうなるかを確かめるため、 を固定値として、弾力性の推定値がどう変わるかを見てみます。 緑の細い線1本が1ユニットの推定値で、60ユニットぶんを抜粋しています。 横軸が 、縦軸が推定された弾力性です。 左端（0.01）では全ユニットの推定値がほぼ1点に集まっています。 右に進むにつれて線が扇状に広がり、各ユニットが自分の値を主張しはじめます。ただし1.4あたりで頭打ちになり、 それ以上は変わりません。データが持っている情報を使い切った状態です。 このつまみの位置を人が決めなくてよい、というのが階層ベイズの利点です。 今回のデータから推定された値は約1.08で、ちょうど広がりきる手前にありました。 「店舗差・ブランド差は確かにあるが、各ユニットの10点をそのまま信じるほどではない」 という位置が、自動的に選ばれたことになります。

はじめに はじめまして、プロジェクトマネージャーの谷澤です。 AIが当たり前になったいまも、プロジェクトの質を左右するのは、結局「チームがどう試行錯誤し、何を学んだか」なのだと感じています。 AIのおかげで、計画づくりのハードルは驚くほど下がりました。 だからこそ余計に「自分たちのチームは、何を積み重ねていけばいいんだろう」と考える時間が増えた気がします。 今日は、そんな私なりの仮説と、実際に試してみた「ふりかえり」の実践を、あわせてご紹介したいと思います。 はじめに 1. 最初のアウトプットだけでは、差がつきにくい 2. 三つの視点で考えてみる (1)「決める」の比重が増す (2) 試行錯誤が財産になる (3) 判断は繰り返し見直す 3. だから、実際にやってみた 実際の進行（3時間想定の場合） ゴールとの接続 4. 学びを、次につなげる さいごに 1. 最初のアウトプットだけでは、差がつきにくい 生成AIの登場によって、要件整理も、スケジュール案も、リスクの洗い出しも、AIに相談すればそれなりのアウトプットがすぐに返ってくるようになりました。 これは素晴らしいことですが、裏を返せば、その時点でのアウトプットの独自性だけでは、プロジェクト間の差がつきにくくなってきているようにも感じています。 プロジェクトの質を左右するのは何か。 私は、実際にプロジェクトを推進する チームのメンバーそのもの と、 推進プロセスの中で何が起き、何を学び、どう変わっていったか という点に、これまで以上に重みが置かれるようになるのではないかと考えています。 2. 三つの視点で考えてみる (1)「決める」の比重が増す 実装にかかる時間が短くなった分、プロジェクト全体に占める意思決定の比重は、相対的に大きくなります。ふりかえりは、その意思決定が結果としてよかったのかを、あとから確かめる場になります。 (2) 試行錯誤が財産になる AIが出すアウトプットをそのまま実行するだけでは、独自の工夫は生まれにくくなります。むしろ、プロジェクトの中でどんな判断を重ねてきたか、その記録自体がチームの財産になっていきます。ふりかえりは、その判断の背景を言葉にして残す場でもあります。 (3) 判断は繰り返し見直す AIの出力は確率的なので、最初から正確なゴールを描くことは困難です。だからこそ小さく試しながら、優先順位や方針を都度見直していくことになります。ふりかえりは、そうして積み重ねてきた判断を振り返り、次の判断の精度を上げていく機会になります。 こうして整理してみると、3つとも「意思決定にどう向き合うか」という一点に集約されるように思います。ふりかえりという営みそのものの価値が、これまで以上に増しているのではないかと考えています。 3. だから、実際にやってみた こうした視点を実際のプロジェクトで試してみようと思い、あるプロジェクトで「ふりかえり」を実施しました。 Insight Edgeが大切にしている「やってみる」という価値観そのままに、まずは試してみることにしました。 採用したのは「セイルボート・レトロスペクティブ」という、海に浮かぶヨットに見立てて状態を整理するアジャイル開発の定番手法です。 *1 数あるふりかえりの手法の中で、なぜこれを選んだのか。 理由の一つに、次の点があります。 「錨（Anchor）＝今の課題」と「岩（Reef）＝将来のリスク」が、最初から別の要素として分かれている点です。目先の問題と、この先ぶつかりそうな問題を混同せずに整理できます。これは、技術的な不確実性が大きいAIプロジェクトの進め方と相性がいいと感じました。 今回はさらに一歩踏み込んで、岩（Reef）を短期・長期に分けて洗い出すという工夫を加えています。標準の手法そのものにこの区分があるわけではなく、今回の実施にあたって加えたアレンジです。 実際にやってみると、この分け方が効いた実感がありました。「今すぐ手を打つべきリスク」と「まだ種の段階だが、放っておくと大きくなりそうなリスク」を、チームではっきり区別しながら話し合うことができました。 要素 意味 ☀️ 太陽（Sun） 入室・事前準備 🌬️ 風（Wind） チームを後押しし、目標達成の推進力になっているもの ⚓ 錨（Anchor） プロジェクトの進行を妨げている慢性的な課題 🪨 岩（Reef） 将来的に顕在化しうるリスクや障害（短期／長期） 🏝️ 島（Island） チームが目指すプロジェクトゴールそのもの 決して目新しい手法ではありません。ただ、個人ワークの時点では「今すぐの課題（Anchor）」だと思っていた項目が、議論を通じて「実は長期的なリスク（Reef）」だったと気づく場面がありました。生成AIプロジェクトのように、状況が動きやすく見通しが立てにくい進め方だからこそ、こうした整理し直しの機会に価値があると実感しています。 実際の進行（3時間想定の場合） 時間 内容 　5分　 入室・事前準備 　20分　 導入・目的共有（本日の目的、手法の説明、プロジェクトゴール＝Islandの再確認） 　50分　 個人ワーク・発表（Part1：Sun・Wind／Part2：Anchor・Reef 短期・長期） 　10分 休憩 　30分 グルーピング・ディスカッション（共感ポイントの共有、主要論点の抽出） 　45分 次フェーズへのアクション化（「何を変えるか」「どう変えるか」の具体化） 　15分 クロージング（各チームから一言） 　5分 退出 ここで意識したのは、 個人ワーク → グルーピング → アクション化 という3段階を必ず踏むことです。いきなり全体討議に入ると、声の大きい人の意見に流されがちです。まず一人ひとりが付箋に書き出す時間を確保することで、全員の意見をフラットに拾い上げられるようにしています。 進行の冒頭では、以下の4つを「進行上のルール」として共有しました。 ① 人ではなくプロセスにフォーカスする ② 発言は平等 ③ 否定ではなく理解 ④ 次につながる議論にする 率直に意見を出し合ってこそ、次の判断の精度が上がっていきます。うまくいかなかったことがあっても「誰の責任か」ではなく「プロセスのどこで何が起きたか」に焦点を当てることで、次に何を見直すべきかが見えやすくなるように感じました。 ゴールとの接続 もう一つこだわったのが、セイルボートの「島（Island）」の扱い方です。プロジェクト開始時のインセプションデッキ（プロジェクトの立ち上げ時に、目的や前提をチームで整理するワークショップです）で作成した「我々はなぜここにいるのか」と、そのまま接続しました。ふりかえりの冒頭でこの問いを共有し直すことで、個人ワークの意見が目先の作業改善だけでなく、そもそもの目的に照らした視点を持ちやすくなったように感じています。 4. 学びを、次につなげる 今回のふりかえりで出てきた課題やアクションは、出しっぱなしにせず、次の2つに接続するようにしています。 後続スプリントのアクションプラン ：Anchor・Reefで挙がった課題を、次フェーズの具体的なタスクや優先順位に落とし込む インセプションデッキのブラッシュアップ ：プロジェクトゴールや前提条件そのものを、得られた学びをもとに見直す 図にすると、こんな循環になります。 計画（インセプションデッキ）→ 実行（スプリント）→ 内省（レトロスペクティブ）→ 計画の更新。このサイクルを回し続けることで、プロジェクトの「軌跡」自体をチームの資産として少しずつ蓄積していけるのではないか、と考えています。 さいごに AIによって「もっともらしい答え」を素早く出せるようになったからこそ、逆説的に、地に足のついた「ふりかえり」の価値が上がっているのかもしれません。もちろん、これは一つの見方に過ぎませんし、時間が経てばまた違う考えに変わっているかもしれません。 少なくとも今回の実践を通じて、次の3つの大切さは、実感として残りました。 チーム全員で同じ景色を見ること 良かったこと・妨げになっていることを、人ではなくプロセスとして正直に出し合うこと そこで得た学びを、次のスプリントとプロジェクトの前提そのものにフィードバックすること 「AIをどう使うか」だけでなく、「チームでどう向き合うか」まで含めて考えていく。 これからも、そんな向き合い方を大切にしていきたいと思っています。 *1 : Sailboat Retro Created by Brody

こんにちは、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の時代に起きているのは、仕事がなくなることではなく、 負荷のかかる場所が移っている ということなのかもしれません。