技術より先に「業務を絞る」——AIJS法人実証レポート
はじめに——なぜ「1時間半」で動いたのか?
AIワークフローの構築に、数週間かけてシステム開発をした話をよく聞く。しかし今回の実装は約1時間半で本番稼働した。
理由は技術が優れていたからではない。始める前に、業務そのものを徹底的に絞ったからだ。
これがAIJS（AI判断セキュリティー）の本質だ。AIを導入する前に、何をAIに委ねるかを設計する。その設計の出発点は、技術ではなく業務の整理にある。
AIJSの順序——「AI」より先に「業務設計」
多くのAI導入が失敗する理由は、ツールを先に選ぶからだ。
「ChatGPTを使えば何かできるはずだ」「AIチャットボットを入れよう」——このアプローチでは、広範な業務に汎用AIを当てることになる。結果として判断が拡散し、AIの出力は的外れになり、人間の確認コストが増える。
AIJSはその逆の順序で動く。
Step 1：顧客と協議して「対象業務」を絞る
Step 2：その業務の「判断パターン」を分析する
Step 3：判断パターンをAIへの指示（プロンプト）として設計する
Step 4：既存ツールでワークフローを構築する
Step 5：人間とAIの両方で判断を管理する構造を作るAIを入れる前に業務を整理する。これがAI判断セキュリティーの本来の順序だ。
今回の「絞り込み」の実際
今回の対象は以下の通り明確に絞った。
| 業務の軸 | 業務内容 |
|---|---|
| 顧客 | 関西の某宗教法人（1社のみ） |
| 業務ドメイン | Microsoft 365の技術サポート |
| 対象チャネル | メール対応のみ |
| AIの役割 | 返信下書きの生成のみ |
| 人間の役割 | 下書きの確認と送信 |
BPOのように「あれもこれも自動化する」ではない。1顧客・1業務・1チャネルに絞ることで、AIへの指示が具体化し、判断の精度が上がった。非効率にみえるが、人間ではなく、AIという文脈を使うことで、これは非効率ではなく、精度をより上げることになった。
この絞り込みは技術的な判断ではなく、顧客との協議によって決まる。「何が一番負担か」「どこが繰り返し作業になっているか」——この対話なしに、AIワークフローは設計できない。
セグメントを絞ることで起きた3つの効果
1. 過去データ分析の精度が上がった
対象を1顧客に絞ったことで、過去メール50件以上を「顧客専用」として分析できた。
結果として以下が明確になった。
- 問い合わせカテゴリの上位：ログイン・メール転送・共有設定・ドメイン管理・契約関連
- 顧客の文体特性：IT用語への不慣れさ、丁寧だが簡潔なトーン
- 緊急パターン：「届かない」「ログインできない」「重複」などのキーワード
これが汎用的な「メール対応全般」であれば、分析は拡散して使えなかった。
2. プロンプトの判断軸が具体化した
分析結果をもとに、AIへの指示を設計した。
【緊急度の判定】
「届かない」「遅延」「ログインできない」「エラー」
「出来ない」「見逃し」「重複」が含まれる場合は
文頭に「【至急確認】」を付けて優先対応を示す
【返信の構成】
1. 状況の確認・共感（1〜2文）
2. 解決策または次のアクション（箇条書き）
3. 不明点があれば選択肢形式で質問
4.「ご不明な点はお気軽にご連絡ください」で締めるこれは「返信を書いて」という指示ではない。担当者が毎回行っていた判断そのものを言語化し、AIに委ねる設計だ。
3. 人間とAIの役割分担が明確になった
人間が判断すべきことと、AIに委ねられることを明確に分けた。
| 役割 | 担当 |
|---|---|
| 顧客との関係構築 | 人間 |
| 緊急度の一次判定 | AI（キーワード検知） |
| 返信文の生成 | AI（Gemini） |
| 内容の最終確認 | 人間 |
| 送信の意思決定 | 人間 |
完全自動化ではない。AIが下書きを作り、人間が承認する。この構造が「判断のセキュリティー」を保つ。
AIに全て任せると、誤った判断が顧客に届くリスクがある。人間が全て対応すると、時間コストが削減されない。その中間点を設計することがAIJSの仕事だ。
構築したワークフロー
全体の流れ
顧客からメール受信
↓
Gmailが自動でラベル付与・チケット管理システムへ転送
↓
Zoho Deskに案件が自動起票（担当者が可視化できる。加えてエスカレーションの管理も容易）
↓
Google Apps Scriptが5分ごとに未処理メールを検知
↓
Gemini AIが返信下書きを自動生成
↓
担当者にアラート通知・Gmailに下書き保存
↓
担当者が確認・修正・送信（1〜2分で完了）使用ツールと費用
| 役割 | ツール | 費用 |
|---|---|---|
| メール受信・振り分け | Gmail | 既存コスト |
| チケット管理 | Zoho Desk | 既存コスト |
| 自動処理 | Google Apps Script | 無料 |
| AI生成 | Gemini API | 月数百円〜 |
新規システム開発ゼロ。追加費用はほぼゼロ。既存のSaaSを組み合わせるだけで構築できた。
これもセグメントを絞ったことの効果だ。対象が広ければ広いほど、必要なシステムは複雑になる。1顧客・1業務に絞ったことで、既存ツールの範囲内で完結した。
費用対効果
時間コストの削減
| 作業 | 従来 | 導入後 |
|---|---|---|
| メール確認・分類 | 2〜3分/件 | 0分（自動） |
| チケット起票 | 3〜5分/件 | 0分（自動） |
| 返信文作成 | 10〜15分/件 | 1〜2分（確認のみ） |
| 処理済み管理 | 1〜2分/件 | 0分（自動） |
| 合計 | 約15〜25分/件 | 約1〜2分/件 |
月30件の問い合わせなら、従来は7〜12時間かかっていた作業が30〜60分に圧縮される。削減率は約95%。負担換算で約1/20だ。
人件費換算
時給3,000円のITサポート担当者が月30件対応する場合、従来は月2〜4万円相当の工数が「メール返信」に消えていた。導入後は月1,500〜3,000円相当に削減。
Gemini APIの費用（月数百円〜数千円）と比較すると、ROIは初月からプラスになる。
数字に現れないコストの削減
- 判断疲労の解消：毎回ゼロから考える返信作成のストレスがなくなる
- 対応漏れの防止：自動ラベル管理により、返信忘れが構造的に起きなくなる
- 品質の均一化：担当者の体調や時間帯に関わらず、一定品質の返信が生成される
- 属人化の解消：プロンプトに判断基準が明文化されているため、担当者が変わっても同じ品質を維持できる
AIJSが解決する本質的な問題
日本のAI導入が進まない理由は、ツールの問題ではない。
「何をAIに判断させるか」を設計できていないからだ。
そしてその前段として、「何の業務に絞るか」を顧客と協議できていないからだ。
AIJSは、この2段階の設計を体系化したメソドロジーだ。
- 業務設計：顧客と協議し、対象をセグメントとして最小化する
- 判断設計：データ分析から判断パターンを抽出し、プロンプトに落とし込む
技術は最後だ。設計さえできれば、実装は速い。今回は1時間半で動いた。
こんな組織に効果が高い
- 特定顧客への定期的なメール対応が発生しているIT支援・コンサル・士業事務所
- 複数担当者が同じ顧客に対応しており、品質にバラつきがある組織
- 既存のGmailとZohoなどのSaaSを持っており、新規開発コストをかけたくない組織
- AI導入を検討しているが「どこから手をつければいいかわからない」担当者がいる組織
特別なシステム開発は不要。既存ツールの組み合わせと、業務設計の整理だけで構築できる。
おわりに
AIは「使う」ものではなく「設計する」ものだ。
そしてその設計は、技術から始まらない。顧客との対話から始まる。
何が本当の負担か。どこが繰り返しの判断になっているか。その業務は本当に必要か。——この問いなしに、AIを入れても効果は出ない。
AIJSは、その問いを持ち続けるメソドロジーだ。
今回の実証は、その考え方を1時間半で形にした一例に過ぎない。同じ構造は、採用問い合わせ・カスタマーサポート・社内ヘルプデスク・営業フォローアップなど、あらゆる「繰り返し判断が発生する業務」に応用できる。
導入を検討したい方は、まず「どの業務を絞るか」という対話から始めましょう。
株式会社美文化計画 / AIJS 東山 純也
