19 6月 2026 6 min read

非エンジニアの PdM が自ら手を動かす社内 Claude ボット開発を全力支援して大成功した話

こんにちは！私は株式会社オプティマインドという物流業界に対して配車システムを提供している会社でプロダクトエンジニアをしております。今日は、社内メンバーからの仕様や使い方に関するお問い合わせに Claude（生成AI）が回答する Slack（チャットツール）ボットを、非エンジニアのプロダクトマネージャーが自ら手を動かして開発するのを全力支援して大成功した経験談をシェアしたいと思います。

なぜ社内 Claude ボットを開発するのか

私のチームが開発している「Loogia配車作成」は 2018 年にリリースされた自動配車システムで、現場に即した 40 以上の細かい制約条件で、「何台のトラックが、どんなルートで、訪問先を回れば効率的なのか」という問題を組合せ最適化の技術で解いています。

仕様が把握しにくい問題

ソリューション提案やオンボーディングを担当している営業、カスタマーサクセス部隊（ビジネスチーム）が、プロダクトの最新仕様を把握するのに以下の課題が存在しています：

物流という複雑な領域を扱っており、2018年のリリース以来、現場の多様かつ高度な要望に応え続けてきた結果、そもそも機能や制約条件が非常に高度になっている
長年、機能拡張を重ねてきたプロダクトの宿命として、ロジックが複雑に絡み合っており、非エンジニアが直感的に仕様を把握するのが難しくなっている
プロダクトの進化スピードが速いため、常に最新の状態に保たれた網羅的なドキュメントを用意しきれていない

そのため、ビジネスチームが仕様や使い方に不明な点があった時は

「開発チームに問い合わせ→開発側で調査→回答」

というのが基本的なフローです。

お問い合わせ対応の工数と「遠慮しがち」問題

もちろんこれで回っていないわけではありませんが、

お問い合わせ対応できる正社員メンバーが少人数のため貴重な工数を割かないといけない
→そのことをビジネスチームも意識してくれているからこそ、「こんな細かいことをわざわざお問い合わせしないほうが良いかも」、「もう夕方だしまた明日またするか」と、問い合わせを遠慮しがち
→ビジネスチームがせっかく吸い上げた現場の声が残らなくなる・伝達が遅くなる

と、深堀っていくと意外と大きな課題になっていました。

実はコードベースを Claude が漁って回答する仕組みが既にある

当社では 2025 年から開発チームを中心に Claude や Google Cloud の AI プラットフォームなど、生成 AI プロダクトを積極的に業務に取り入れています。

私のチームでは、コード管理ツール（GitHub）上でコメントで指示するだけで、Claude が自動でプログラムの仕様を調査したり、簡単な修正を行ってくれたりする仕組み（Claude Code GitHub Actions）をすでに活用しています。

しかし、ビジネスチームは普段 GitHub にアクセスしておらず、使い慣れていないツールを用意しても業務フローとして定着しない懸念がありました。

そこで、「だったら、その壁に穴を開けて、社内で誰もが使っているチャットツール『Slack』に繋げば、誰もが使える社内 Claude ボットができあがるのでは？」と、担当 PdM がひらめいたのです。

ゴールも挑戦の熱量も揃った

Slack には投稿されたメッセージを自動で届けてくれる通知の仕組み（Webhook）があります。その自動通知を受け取れるプログラムを用意すれば、メッセージの内容を GitHub に転送し、既存の Claude Code の仕組みが調査して回答してくれるので、その回答を再度 Slack に投稿すれば良いのです。

これができれば、以下のような理想的な体験が実現します。

社内の誰もがSlackでメンションするだけで気軽に質問できる
人が少ない夕方や夜間でも、遠慮なく問い合わせが可能になる
実際のコードを調査するため、ドキュメント化されていない仕様にも正確に回答できる

ゴールもかなり明らかになってきたし、挑戦するモチベーションも湧いてきました。

どのように支援したのか

これで、非エンジニアのプロダクトマネージャー（以下PdM）は「よし、作ろう」になったのですが、その途中でいくつかの現実的な壁にぶつかり、それをエンジニアの私と一緒に対策していきました。

それでは、具体的にどんな課題があったのか、エンジニアとしてどのようなマインドセットで支援したのか、振り返ってみたいと思います。

「制約のない遊び場」を切り拓く

前に紹介した仕組みの通り、Slack からの通知を受け取り、その内容をGitHubに転送するプログラムが必要になります。

担当 PdM は当初、ローコード的に使える Google Apps Script のようなツールでの自動化を試みていました。AI のサポートを借りてプログラム自体は形になったものの、いざ Slack の通知をシームレスかつ安全に受け取ろうとすると、現在のセキュリティ基準を保ったまま実現するのは困難でした。

そこで私は「開発VPSを使ったらどうでしょう」と提案してみました。

VPSというものに馴染みがない方もいらっしゃると思いますが、言い換えるとクラウドサーバーのことです。あくまで生リソースのため、何をデプロイしようが制限は基本的にありません。（もちろん環境構築やセキュリティ設定などが必要です。）

具体的には、生成 AI を活用すれば、非エンジニアでも効率的に回せるワークフローができるようになります：

担当 PdM に VS Code（コードエディター）をインストールしてもらう
エディターを VPS にリモート接続する
エディター上で Claude Code に指示を出してプログラムを作成・修正してもらう

サーバー上で直接コードを書き換えているため、「デプロイ（本番環境への反映作業）」という難しい概念を覚える必要もありません。公開したい時にその場ですぐに試せる、非エンジニアにとってもフィードバックループを回しやすい環境が整いました。

実は、この開発 VPS の環境は、今回のボット開発のためにわざわざ用意したものではありません。他の開発や検証目的で、数ヶ月前から私がコツコツと準備を進めてきたものでした。ISMS（情報セキュリティマネジメントシステム）のルールに基づいた社内利用申請などの申請に関する準備作業はすでに終わっていました。

振り返ってみると、前もってこの「制約のない遊び場」をチーム内に切り拓いておいたからこそ、PdM がせっかくひらめいた素敵なアイデアが途中でつぶれてしまうのを防げたのだと、強く実感しています。

必要な時だけのピンポイント支援

私は今回、実際に手を動かしてボットを作るという PdM の熱いモチベーションを削がないことを最優先にしました。「代わりにやってあげたい」というエンジニアとしてのエゴを抑え、当社の価値観でもある「他者への配慮や思いやり（謙虚力）」を持って接することを意識しました。そのため、「自力で進められているうちはあえて手を出さず、致命的なボトルネックやセキュリティの壁にぶつかった時だけサポートする」というマインドセットで伴走しました。

VS Code から直接 Claude Code が使える今の時代、多少遠回りになっても、AIと対話しながら自力で一歩ずつ進むこと自体が最高の成功体験になるからです。

実際、担当 PdM は「Slackの通知を受け取る → GitHubに転送する → 回答状況を監視してSlackに返す」という一連のバックエンドの処理を、Claudeと一緒に実装して動かすところまで自力で到達しました。

各種トークンの発行や権限設定、環境変数に切り出すなど、インフラの知見やセキュリティ観点が必要なところは、PdM に画面共有をしてもらうなど、一緒に進めていましたが、具体的な仕様やコードは何の指示も出していません。だからこそ、一通り動いた時の成功体験が最高になったと思います。

しかし、そのまま完了してボットが出来上がったかというとそうではありませんでした。手こずる問題が一つありました。

プログラムによって質問が GitHub に投稿された後、裏側で Claude Code が調査に動きます。それにある程度時間がかかります。

ユーザー体験としては、以下のようなスムーズな流れを目指していました。

ユーザー： Slack 上で @claude-bot をメンションして質問を投げる
システム： 通知を受け取ってGitHubに転送し、すかさず「Claudeが回答次第お知らせします」とSlackに中間返信を返す
システム： 裏側での回答が終わったタイミングで、回答全文を Slack に転送する

ここで大きな壁となったのが、「裏側でAIの回答が終わったタイミング」を、プログラムが直接検知する方法がないということでした。最初の実装では、Claude Codeがまだ調査中（思考中）であるにもかかわらず、ユーザーからは意味不明な「Claude Code is working…」といったログやTodoリストのテキストが、そのまま Slack に垂れ流されてしまう状態になっていたのです。

もちろん PdM も Claude を使って解決しようと試行錯誤していました。しかし、「適切な非同期のアーキテクチャ設計」は、現在の生成 AI が最も苦手とする分野の一つです。そのため、AIがもっともらしい嘘をつく「ハルシネーション」が頻発し、泥沼にハマりかけていました。

こうしたボトルネックこそ、エンジニアが専門知識を活かして解決すべき領域です。

私はコードを直接いじるのではなく、GitHub の仕様を調べ、「ワークフローの終了を特定できるイベント通知を、GitHub から直接受け取る仕組み（Webhook の活用）」という設計のアイデアを提案しました。

驚いたことに、担当 PdM はその提案をもとに Claude へのプロンプト（指示文）を組み立て、見事にプログラムを修正してしまったのです！これによってようやく、「一旦、社内メンバーにテスト公開してみよう」と言えるクオリティに達しました。

社内ボットの効果

このような形で、以前ならエンジニアがまとまった工数を割いて開発しなければならなかった仕組みを、非エンジニアの PdM がわずか 5 営業日という凄まじいスピードで、アイデアからテスト公開まで形にしてしまいました。

テスト公開後、社内の Slack 上の times（分報）や開発チームの振り返りは、このボットの話題で盛り上がり、ビジネスチームからは、こんなに嬉しい反響が届きました。

「この時間（定時後）に問い合わせしていいだろうか……とか気にしなくていいのは、本当にありがたい！（基本疑い深い私は、子供の頃『自動販売機って実は裏で人がモノを出してるだけでは？』と疑っていたくらいなので、実は裏でミッツさん（PdMのあだ名）が必死に手動で回答してたらどうしよう、とか考えてる笑）」
「Claudeへの仕様お問い合わせチャンネル、Bizのメンバーがそれぞれどう四苦八苦してるかが一元化して確認できるのもとても良いよね」

運用を始めてみると、「お問い合わせとして正式に起票して開発に伝えるほどではないけれど、現場がちょっと気になっている細かい疑問」が、GitHub 内のチケットとして自然に蓄積されていくという、予想外の嬉しい効果もありました。

さらに、公開から約 2 週間後、GitHub のチケットと Slack での反応を突き合わせ、ボットの回答パフォーマンスを簡易評価してみました。

ポジティブ（約66% / 31件）：明確に「助かった」「合っている」とリアクションがあったもの、次のアクションに繋がったもの
ポジティブではない（約34% / 16件）：その他や反応なし

初めて非エンジニアが作ったプロトタイプ、しかもドキュメント化されていない複雑な仕様を扱うボットでありながら、全体の3分の2でユーザーをしっかり満足させられるという、驚異的な結果を叩き出したのです。

結び

いかがでしたでしょうか。

生成 AI の進化によって、今まさに開発の現場は激変しています。しかしその特性を正しく理解し、完璧を求めない検証プロジェクトや、今回のような社内ツールの開発であれば、非エンジニアであっても驚くほど簡単に形にできる時代がやってきました。まさに「開発の民主化」です。

世間では「AIにエンジニアの仕事が奪われるのではないか」という議論も耳にします。しかし、今回の経験を通じて私は、全く逆の未来を確信しました。

エンジニアとしての真の価値は、コードを書くことだけではありません。AIという強力な武器をチームに馴染ませ、彼らの可能性を広げて最大の価値を出すために「周囲をエンパワーメント（支援）していくこと」。これこそが、これからも変わらない、私たちが進むべき方向性なのだと改めて強く実感できました。

もし皆さんの周りにも「こんなのあったらいいな」と目を輝かせている非エンジニアの仲間がいたら、ぜひ小さな「制約のない遊び場」をプレゼントして、一緒に最初の一歩を踏み出してみてください。きっと、想像もしなかった素晴らしい景色が待っているはずです！