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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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