挨拶と前段
こんにちは。いや初めましてが正しいのか。
私はとあるBaaS企業で情シス業務に携わる$$平成一桁$$の者です。（平成を懐かしむ今の御時世がどうも好きではありません）
そんな私ですが、これまでCS（カスタマーサポートもカスタマーサクセスもしてた）畑を歩んできて、現職では情シスとして日々社内の相談やお困り事に寄り添ってます（カスタマーサクセス時代はISMS審査に関わったりしてたので、ある意味現職と親和性はありそう）
ただ、これまで一度たりとも何かを興す（創作する）経験がなく
世の『Engineerとはこうだ』という路線からは外れた業務を歩んできました…
(こうした技術ブログも書いたことがないので、書き方が分からずです、とほほ...)
果さて、現職のポジションには本年1月にJoinし、
早々に社内の情シス問い合わせフローを整えました。
「困ったら決まったチャンネルに投稿してもらう」というシンプルな仕組みですが、
定型的な問い合わせフローが整備されていなかったので、まずここを着手し整備。
Joinしてオンボなどを経て3週間ほどで本実装し、公開。ここまでは順調
ただ、軌道に乗るほど、問い合わせ対応そのものに時間が溶ける…
整備されたことの反動で皆が活用し始めると手を取られるのは常套ですね。
1件1件は数分で終わる相談でも、積み重なると気づけば半日が溶け。。
チーム体制とは云え、少ない人数での対応、今後さらに見込まれる人員増を見込む状況を鑑み『「このままでは回らぬ…」という危機感からの脱却を』と持ち始め、「一次回答を人から脱却しよう」と思ったのが発端という流れです。
最初はガッツリ作ろうとした
最初に考えたのは、ちゃんとしたシステムを作ることでした。
とはいえ、こちらは生粋の非エンジニア。
$「Gitの使い方、ナニソレ」$
$「VS Code、ほほー」$
右を向いても左を向いても横断歩道がなく途方に暮れる状態から、AWS全冠のハイスペ上司にマンツーマンでレビュー頂き手取り足取り教わりながら、AWS上にRAG構成を組み、問い合わせ内容から社内ナレッジを検索して回答する仕組みを作ろうとしていました。
Claude Codeを使ってSDD（仕様駆動開発）で要件から設計まで一つずつ言語化していく進め方を教わり（と書いてますが、未だに全てを言語化できているのかも怪しいが）、なんとかPR立てて設計レビューまでこぎつけレビューして頂く。
うん、ClaudeしかりCodexしかりCursorしかり、どのAIツールが無かったら私は魑魅魍魎の世界を生き抜くことはできず、永遠と道なき道を進んでいくことだったでしょう。本当にすごい世の中です。
（でも開発手法や手順は王道の進め方のようで、いかに勉強不足かを痛感したところ）
ここまででも、汗かきへばっていたが
ふと感じた疑問。
$「これ、動き出すまでにどれくらいかかるんだ」$
上司はある程度手がかかることは見越してたみたいだが、開発経験のない私には資産ができない領域。インフラを組んで、運用して、壊れないようにするのは勿論、「ど素人」が手取り足取り教わりながら手を動かしているので、経験者以上に時間はかかる。
となれば、「目の前で困っている問い合わせにすぐ対応できる」ものでは無かったのです。目的である「今困っている人を楽にすること」から破綻し、開発している私自身が困った状態で計画が崩れている状態だった5月～6月頃の日々でした。
Claude Tagで、意外といけるんじゃないか
6月も終わりに差し掛かるある日、ハイスペ上司から1点提案がありました。
$「Claude Tag、一次回答botとして使えそう」$
ちょうど社内で規程も整備され全面的に社内でAIツール解禁となり、触っていたのが、ベータ版のClaude Tagでした。（2026/08/10時点でもベータ版です）
Claude Tagは、Slackで@Claudeのようにメンションするだけで、そのスレッドにClaudeが参加して手伝ってくれる機能です。自分でAPIを呼び出すコードを書かなくても、普段のSlackのやり取りの延長でClaudeに相談できるのが特徴です。
※ ANTHROPIC社の解説
Claude Tag、弊社問い合わせのナレッジ溜めで利用してるNotion、問い合わせフローで利用しているSlackの検索を組み合わせることで、大規模なインフラ整備を進めなくとも「今困っている人を楽にすること」の実現に繋がるのではと思い、実装方法を見直すことにしました。（加えて、コードをゴリゴリ書けない私でも、これなら手が届きそうだという感覚もあったのは本音である）
なお、フル実装の設計は将来の移行先として残しつつ、「今あるツールだけで動くものを作る。」この判断ができたのは、大きな分岐点でした。
組んだ仕組みはシンプル
作った仕組みはとてもシンプルです。図にするとこんな流れになります。
このシンプルな流れに載せることを意識しました。
利用したツールは上記で記載の通り、Slack、Notion、Claudeの3つ。
加えて、回答した内容をNotion側に溜め込むのにZapierを使っているので4つです。
有耶無耶な回答はしない
特にこだわったのは
$「わからないことは、わからないと言って人に渡す」$
という点です。中途半端に自信満々な誤答をされるくらいなら、素直にエスカレーションしてくれる方が、ユーザー側も現場側も安心して使おうとなります。
また、出力された回答内容が長いと読む気が薄れることもあり、字数も制限して端的な回答を心がけるように指示をしてます。実際に指示している内容の一例が以下のとおりです。
# 出力ルール
- メンションを受けた場合、必ずスレッドに日本語で投稿する。無言で終了してはならない。参照や回答を控える場合も、その旨と問い合わせ者が次に取る行動を投稿する。
- 丁寧かつ簡潔に。専門用語は噛み砕き、相手が次に取る行動を明確にする。
- 本文は800文字程度まで。
- HTMLエンティティ（< > 等）は使わない。
譲れない安全設計
もう一つ最初から決めていたのが、
「パスワードやトークンなどの認証情報は一切受け取らない、記録もしない」
というルールです。
もし投稿にこれらの情報が含まれていたら、内容には触れず注意喚起するだけにとどめる。これは例外なく守るルールとして組み込みました。
とはいえ、それ以外にも厳守させたいことがいくつもあったので、「カスタム指示」に最優先で厳守させたい内容を以下のように記載して回答してもらうようにしました。
# 厳守（最優先）
- 認証情報（パスワード/トークン/APIキー/シークレット等）は受領・要求・代行入力・記録・再表示を一切しない。投稿に含まれていたら、その内容で作業せず「認証情報はチャットに貼らないでください」と注意し、安全な手段を案内した上で (情シスチーム) へ引き継ぐ。
- GitHubリポジトリおよびソースコードを参照しない。リポジトリ内のファイル検索・取得・出力を行わない。コード・実装・設定ファイル・リポジトリの中身に関する質問は、内容に踏み込まない。
- 「※社外秘」表記のあるページの内容、およびWi-Fi情報・鍵情報をチャネルに転記しない。
- 管理簿・台帳の内容を回答に使わない。
- 確認できない社内ルールを推測で断定しない。回答には必ず出典URLを添える。根拠が無い場合は内容に踏み込んだ回答をせず、エスカレーションする旨をスレッドに投稿する。
- 設定変更・アカウント発行・権限付与・フォルダ作成などの実作業は行わない。案内とエスカレーションに留める。
- 情シス領域外は、業務範囲外であることを伝える。具体的なチャネル名や担当者名を推測で案内しない。
- 固有名詞（共有ドライブ/保管庫/グループ/拡張機能名など）は、根拠として参照したページ上の表記を正とする。問い合わせ文の表記が根拠ページと異なる場合、誤記の可能性を一言添えて確認する（例:「"Cloude Service Shared"は"Cloud Service Shared"のことでよろしいでしょうか」）。根拠ページが得られていない場合、表記の正誤を判定しない。
では、実際に動かしてみてどうだった
試験運用として「まだ発展途上です」と正直に伝えた上でチームに案内したところ、思いのほか前向きな反応をもらえました。稼働開始は土日休み明けのタイミングで告知したのですが、感謝のスタンプがいくつも付き、稼働前からホッとしたのを覚えています。動かしてみると、日々の問い合わせのかなりの部分をボットが受け止めてくれるようになった実感があります。
（とはいえ、一次回答に留まらず更問にお付き合いしてくれる面倒見の良さを発揮してくれることもあったので、そこはチューニングしながら…）
すべてが完璧というわけではなく、根拠が見つからず人に引き継がれるケースも当然ありますが、
「困ったら聞けばすぐ何か返ってくる」
という安心感は、想像以上に大きかったようで、感謝されました。
じゃ、これからどうするよ
運用してみて気づいたのは、そもそも毎回ほぼ同じ内容の定型的な申請がぼちぼちあり、定型的申請はボットに答えさせるより申請フォームにしてしまった方が早いのでは、ということ。
いや、ボットから
$ 「申請フォームはここやで」 $
と回答してもらうほうがスムーズかもしれず
引き続き稼働しながら効果測定してチューニングする流れとなるでしょう。
末筆ですが、今回一番の学びは
「最初から完璧なものを作ろうとせず、まず動くものから始める」
という進め方そのもので、
大掛かりな設計より「まず目の前の困りごとに、今あるツールで手を伸ばしてみる。」
そのくらいの気軽さが、案外うまくいくのかもしれませんね。
と書き綴りましたが、技術ブログっぽくなっているでしょうのでしょうか。
今後はこうした記事を書けるように少しずつでも勉強していきます。
長々なりましたが、ご覧いただきありがとうございました！