どうもこんにちは。今回は以下のイベントに参加した時について、備忘録としてまとめました。

私の手元のメモを元に作成をしました。資料はconnpassもしくは登壇者様のXに上がると思いますので、正確な内容および詳細につきましてはそちらをご参照ください。

この記事の結論

今回のイベントで語られていた肝は、次の1点であると考えました。

AI導入の成否は、ツールの性能よりも「業務プロセスの設計」と「組織内で自然に使われる仕組み」で決まる。

「便利なAIツールを配る」だけでは、現場の生産性はほとんど変わりません。実際に成果につながっていたのは、以下のような取り組みでした。

AI前提で業務フロー自体を作り直す
ガバナンスや運用を事前に埋め込み、現場の手間を減らす
小さな成功体験を共有し、横展開が自然に起きる状態を作る
個人の活用をチームの資産に変換する仕組みを持つ

1. AIツールを使うのその先へ、AI Nativeなワークフローを探求して

登壇者: https://x.com/Fumiya_Kume

印象的だったのは、「導入」と「定着」を明確に分けていた点です。

社内勉強会、ハッカソン、Meetup会場提供などで機運は作れた
ただし、日常業務への定着は別問題だった
理由は、既存プロセスの上にAIを載せただけで、プロセス自体が変わっていなかったから

発表では、開発生産性2倍を目標に、AI前提でプロセス再設計する流れが示されました。

Stage1: AIと考える
Stage2: AIと決める
Stage3: AIに任せる

特に Agent Spec Driven Development の考え方は実践的でした。

人間が「何を作るか」を定義する
AIが「どう作るか」を設計・実装する

ツール導入ではなく、役割分担を再設計する発想のように考えました。

2. 保険会社におけるAIエージェント推進

登壇者: https://x.com/tel_shi の代役の方

規制業界ならではの難しさが非常に具体的でした。

ルール遵守のため、運用設計にコストがかかる
PoC後も利用率が伸びない（10人中3人利用）
原因は、現場任せの設定や運用が多く、ガバナンスと両立しにくかったこと

対策として、Gemini CLIをForkした独自版（Lemini CLI）を用意し、設定を固定化。

認証・リージョンなどを利用者が迷わない形にする
危険な操作モードを封印し、非エンジニアでも使える前提を作る

非エンジニアの方もCLIを使うのかという驚きがありました。

今後の視点として、AIが自律的にタスクをこなす体験を意思決定層に体験してもらう ということが必要なるとのこと。

3. AIの前に、やることがある — 医療データ企業の4フェーズ

登壇者: https://x.com/dtaniwaki

「AI活用以前に、まずデータ基盤」という順序を4フェーズで説明していたのがわかりやすかったです。

データ基盤一元化
データの民主化
全社展開
AIエージェント適用

特に重要だと感じた点は以下です。

データが分散している状態では、AIの効果検証すら難しい
基盤整備と布教活動を同時に進める必要がある（布教活動は理解や興味を示してくれるメンバーを巻き込んでスモールスタート）
SlackBotのような低摩擦な導線で、部門横断の利用を促進できる

「小さく使われる仕組み」を作り、効果実感を積み上げた結果として推進が強まる流れは、とても勉強になりました。SlackやTeamsなどの普段から使用しているツールに違和感なく組み込むことができるように実装するのが意外と早いのかもしれないなと思いました。

4. 「生産性2倍」はなぜ現場に響かないのか？

登壇者: https://x.com/_yasuko__Bass__

ここは、AI推進が失敗するパターンの共有としてとても勉強になりました。

ヒアリングなどを実施し、高品質な商談評価レポートを作るAIエージェントを構築しても、現場で活用されない
失敗要因は2つ
- 課題設定が現場の悩みとずれていた
- 既存ワークフローを変える負荷を考慮できていなかった

結論として、いきなり大きな変化を狙うのではなく、

小さな改善
信頼構築
余裕の創出
大きな施策

の順で進めるべきという話でした。

「2倍」という目標は旗として持ちつつ、現場に届ける価値は「5分が10秒になる体験」という表現でエンドユーザに伝えた方がイメージが湧くのかと感じました。

5. AI推進のためにとった戦略は、「全部やること」ではなく、「勝手に広がる仕組み」を作ること

登壇者: https://x.com/peter_0123

AI推進者だけでAI推進の壁を越えるには、以下のような黄金パターンがあるようです。

遊べる余地を残す
誰でも触れる
中身が見える

この3点を揃うと、社内で二次創作が起き、想定外のユースケースが増えるとのこと。そして、誰かが作成したAIエージェントをパクってAIエージェントを作ることで様々なAIエージェントが生まれていく仕組みができていました。

印象的だったのは、成功の中間指標として「自分の知らない事例が増えること」を置いていた点です。これは、現場でAIが使われ始めているということを認識するための重要な指標だと感じました。

6. 「便利だから使ってね」では、生産性は変わらなかった — カスタマーサポートが目指す、自然と AIが使われる仕組みづくり

登壇者: https://x.com/naka54_t

プロンプト配布やツール紹介だけでは成果が頭打ちになる理由が整理されていました。

利用が一部メンバーに偏る
リテラシー依存で成果が不安定
個人の知見がチーム資産にならない

ここからの転換が重要でした。

個人の効率化（点）
チーム生産性（線・面）

を分けて考え、ナレッジ追加・更新が自動蓄積されるパイプラインを作る。AI導入を「個人技」ではなく「組織学習」に接続するようにしていました。

7. 内製ツールの「作る」「作らない」〜「作らない」の判断軸と、「作る」の設計戦略〜

登壇者: https://x.com/kato_ai_ops

AI-Opsの実務として非常に現実的だったのが、内製判断の話です。

依頼が増えるほど、何でも作る方向に流れやすい
ただし作りすぎると、社員の自力解決力を奪う

一方で、作るべき領域もある。

汎用ツールで届かないドメイン特化領域
変数を固定して品質・速度・コストを最適化できる領域

要するに、「作る/作らない」は機能要件ではなく、個人のリテラシーや組織能力への影響まで含めて判断すべきという学びでした。

全体を通じた学び

今回の発表群から、AI推進の実践原則は次の5つに整理できると感じました。

AI導入の主語は「ツール」ではなく「業務設計」
現場任せを減らすために、ガバナンスを仕組みに埋め込む
効果が見える小さな導線から始める
個人の工夫を組織資産に変換するパイプラインを持つ
内製は「短期効率」だけでなく「長期の自走力」で判断する

まとめ

イベントを踏まえ、まず着手すべきは次の3点だと整理しました。

現場の業務フローのどこをAI前提で再設計できるかを考える
設定済み・安全設計済みの使いやすい実行環境を用意する（SlackBotなど）
巻き込んだ少数の人たちの中である程度活用できるようなったら、再利用しやすい構成を作る（Slack運用やナレッジ基盤）

AI活用を「便利ツールの導入」から「組織の運用設計」に引き上げることが、次の打ち手だと再確認できたイベントでした。

以上