この記事はウェブクルー Advent Calendar 2025の14日目の記事です。
昨日は@youngjae_wonさんの「生成AIは開発者に取って代わることができるか？」でした。
はじめに
私、この会社でもう16年目になるベテラン選手で、現在はマネージャーをしています。
元々はフロントエンド（というかマークアップ）畑の人間でしたが、紆余曲折ありまして、CTO直下のアプリ開発室を新設し、Flutterでのアプリ開発を主導してきました。
そして現在、会社からの新たな指令を受け、「Innovators Hub Group」という組織を発足させました。
ここは単なるシステム開発部隊ではありません。
生成AIを研究することはもちろん、各部署に潜むイノベーターたちをまとめ上げ、社内に知識を伝承し、実用的なツールを提供する…まさに社内変革の「ハブ」となることを目的としたグループです。
日々「生成AIとは」を学び、最新ニュースを社内にリリースし、社内専用チャットツールを開発してはプロンプトを配る。そんな「AIのエージェント」のような日々を送っています。
「そろそろAIでお金を生み出せ」というプレッシャーも心地よく感じ始めた矢先、ある現場の業務改善に関わることになりました。
結論から言うと、そこで役に立ったのは「最先端のLLM（大規模言語モデル）」ではなく、「泥臭い人間同士の対話機能」 でした。
今回は、Innovators Hub Groupのマネージャーとして直面した、「技術以前のエンジニアリング」の話をしようと思います。
1. 現場で起きていた「Human Power」による解決
弊社は比較サイトビジネスを運営しており、おかげさまで参加企業様も順調に増えています。
しかし、ビジネスの拡大は、往々にしてオペレーションの負荷増大を招きます。
- 膨大になる月次の請求作業
- リストに対する無効精査作業
これらが雪だるま式に膨れ上がり、営業担当者が「月の○分の1を事務作業に費やす」という本末転倒な状況が発生していました。
営業なのに、お客様のところへ行く時間がない。
しかし、現場のメンバーは優秀です。
優秀であるがゆえに、この理不尽な業務量を「気合」と「根性」と「熟練の手作業」でカバーしてしまっていました。
システム化の遅れを、高い人間力（Human Power）で解決していたのです。
しかし、それも限界を迎えていました。「あー！死ぬー！」という悲鳴は、ヒューマンエラーではなく、明らかにシステムエラーの兆候でした。
{
"workflowName": "月次請求＆精査カオスフロー",
"version": "最終版_v99_修正_final_本当に最後.json",
"maintainer": null, // メンテナー不在
"steps": [
{
"name": "データ取得",
"description": "秘伝のExcelマクロを実行し、祈りながら待つ",
"requiredSkills": ["Excel VBA（古代語）", "忍耐力"]
},
{
"name": "データ加工（人力）",
"description": "マクロが出力した謎のCSVを、担当者が目で見て手で直す",
"actions": [
{ "type": "copy_paste", "count": 1000, "note": "指紋消失の危機" },
{ "type": "visual_check", "note": "担当者の勘が頼り" }
]
},
{
"name": "物理的転記リレー",
"description": "フロアの端にあるレガシー端末まで歩いて移動し、手入力する",
"subSteps": [
{ "system": "LegacySystemA", "note": "二重打ち必須" },
{ "action": "pray", "note": "エラーが出ないように祈る" },
{ "system": "LegacySystemB", "note": "APIなし" }
]
},
{
"name": "最終出力",
"method": "FAX", // まさかのFAX
"note": "送信エラーが出たら最初からやり直し（絶望）"
}
]
}
2. 発動した人間機能 その１：「強制的な割り込み（Interrupt）」
限界が近づく中、現場のマネージャーがファインプレーを見せます。
「週次で、開発と営業が相談する時間を強制的に設ける」という決断をしてくれたのです。
通常、多忙な現場に会議を増やすのは悪手とされがちです。しかし、AIやプログラムが「無限ループ」に入った時に必要なのが「強制終了」であるように、人間にも 「強制的な一時停止」 が必要でした。
私たちInnovators Hub Groupも、その場に「ファシリテーター（壁打ち相手）」として参加しました。
私のチームのメンバーは優秀なエンジニアたちです。彼らは会議が始まるやいなや、
「APIで連携できますか？」
「そのデータのフォーマットは？」
と、エンジニアとして 「正しく、かつ技術的な解決策」 を次々と提案してくれました。
頼もしい限りです。
しかし、私はそこで少し違和感を覚えました。「ボタンの掛け違い」が起きている気がしたのです。
そこで私は、優秀な彼らの横で、あえて「空気を読まない質問」をする役割に徹することにしました。
3. 発動した人間機能 その２：「ド直球の問い（Fundamental Question）」
議論が技術的な詳細（APIがどうこう、CSVの形式がどうこう）でヒートアップする中で、私はあえてその熱狂に水を差すように、手を挙げて質問を投げかけました。
「ごめん、技術的な話の前に聞くんだけど。営業としてやるべき仕事を『10』だとしたら、今みなさんが抱えている事務作業は、数字で言うといくつくらい？」
それは、エンジニアからすれば「今さら何を聞いているんだ？」と思われかねない、あまりに初歩的で、感覚的な質問でした。
しかし、AIは複雑な計算は得意ですが、こうした 「大局的な現状認識（肌感）」 を問うことはできません。
この質問の効果は劇的でした。
「……7、いや8くらいかもしれません」
現場からその数字が出た瞬間、会議室の空気が優しく変わりました。
「APIでどう繋ぐか」という議論から、「我々は業務の8割を占める異常事態をどうにかしなければならない」という共通の課題認識へと、視座が一気に揃った気がしたのです。
さらに深掘りしていくと、衝撃的な事実が明らかになりました。
とある集計の最終確認作業となるSMS送信業務において、「スマホ実機を使って、1件ずつ手動で送信している」というのです。
現場の方からはこんなジョークが飛び出しました。
「これ、親指の指紋なくなるかと思ってました（笑）」
私は笑いつつも背筋が伸びる思いでした。
指紋が磨り減るほどの単純作業を、優秀な人間に強いていた。これは我々システム側の敗北です。
// 現場で実行されていたレガシーなアルゴリズム（通称：人海戦術）
Future<void> _executeManualOperation() async {
// 指紋の耐久値を設定（個人差あり）
double fingerPrintDurability = 100.0;
while (employee.isAlive && taskList.isNotEmpty) {
try {
// 1件ずつ手動送信（超高負荷処理）
await sendSmsOneByOne(target: taskList.removeFirst());
// スタミナと指紋が摩耗する
employee.stamina -= 10;
fingerPrintDurability -= 0.5;
// UIスレッドをブロックしないように気休めのawait
await Future.delayed(Duration(milliseconds: 100));
} catch (e) {
// エラーハンドリング：気合で乗り切る
print("Error: ${e.toString()} but don't stop. Just do it.");
}
if (fingerPrintDurability <= 0.0) {
throw FingerprintNotFoundException("生体認証エラー：指紋が消失しました。ログインできません。");
}
}
4. 解決策：AIは出番なし（Context Matching）
課題がクリアになれば、話は早いです。
実は社内では既に「ユーザー認証用のSMS送信システム」を導入していました。
「あれ？ これを流用して、リストをCSVで食わせれば一発で終わるのでは？」
現場が欲しかったのは、高度な推論能力を持つAIエージェントではなく、単に 「大量のリストをさばいてくれる既存の仕組み」 だったのです。
AIを使うまでもなく、既存資産の転用で解決する話でした。
これで一件落着、開発スタート！…となりかけたところで、私はもう一度だけ空気を止めました。
5. 発動した人間機能 その３：「未来の失敗観測（Pre-mortem）」
「CSVで一括送信機能を作ろう！」と盛り上がるメンバーたちに対し、私は少し意地悪な質問をしました。いわゆる「プレモータム（死亡前解剖）」です。
「仮にこの機能をリリースしたとして、もし大エラーが出て大騒ぎになるとしたら、どんなことが起きた時だと思う？」
人間は「こうなったらいいな」という希望的観測には弱いですが、「こうなったら最悪だ」という不安のシミュレーション能力には長けています。
現場からは即座に具体的な恐怖が語られました。
「宛先リストの列がズレて、全く関係ない別の人に大量誤送信することですね…」
「連打してしまって、同じ人に100通届くことですかね…」
「送信禁止リストの人に送っちゃうと、クレームで営業停止になりますね…」
出るわ出るわ、背筋が凍るようなシナリオの数々。
しかし、この「恐怖」こそが、堅牢なシステムを作るための最も重要な要件定義でした。
結果、AIに頼らずとも、見過ごしてはならない「本当に必要なガードレール」が次々と決まっていきました。
6. AIプロンプトの前に、人間プロンプトを
今回の件で痛感したのは、「相談する機会（コンテキストの共有）」さえあれば、現場からは解決につながるアイデアがバンバン出てくるということです。
彼らは解決策を知らなかったわけではありません。
「忙しすぎて、何が課題なのかを整理して誰かに伝える時間」がなかっただけなのです。
これは、生成AIへのプロンプトエンジニアリングと全く同じ構造です。
- Interrupt: 強制的に立ち止まり、
- Define: 「ド直球な質問」で課題のサイズを測り、
- Simulation: 「最悪の未来」を想像してリスクを潰す。
この手順（人間同士のプロンプトエンジニアリング）を踏まずに「とりあえずAIでなんとかして」と投げ込むのは、整理されていない部屋にルンバを放つようなものです。
def deploy_ai_agent(environment):
"""
AI（ルンバ）を現場に投入する関数
"""
# ケース1：整理されていない部屋（カオス）に投入
if environment.status == "GOMI_YASHIKI":
# 開始3秒で床に落ちていた靴下を吸い込んで停止
raise SystemError("異音検知：ブラシが詰まりました。助けてください。")
# ケース2：整理された部屋（整地済み）に投入
return "生産性爆上がり 🚀"
おわりに
現在、私たちのチームは、この業務改善のフェーズを経て、いよいよ本格的なAI活用（例えば、精査業務の自動化など）に着手しようとしています。
人間同士の対話によって業務フローが整理され、課題が明確になった今、そこはAIが最も力を発揮できる「整地された土壌」に変わり始めています。
職務上の私の肩書きは「AI推進担当」ですが、私個人のスタンスとしては、「現場の課題が解決するなら、手段はなんだっていい」 と思っています。
それが最新の生成AIだろうが、枯れた既存システムだろうが、極論を言えばFAXやモールス信号だって構いません。
みんなが楽になれば、それでいいのです。
ただ、どの道具を選ぶにせよ、その手前で必要なスキルは共通しています。
それは、Gemini Code Assistを叩く技術よりも、「困っている人の話を親身になって聞き、時にあえて空気を読まずに質問する」 という、極めてアナログな人間機能なのです。
もし皆さんの周りで「あー！死ぬー！」という声が聞こえたら、まずはAIを勧める前に、「解決策を探すのは後にして、まずは『何が大変か』を話す時間を作りませんか？」 と聞いてみてください。
そこから始まる革命が、きっとあります。
明日は@wc_sangenさんです！よろしくおねがいします！