ZENBU ／ 社内AI
Larkの中にいて、案件の照会・資料の読み込み・数字の確認・文章の下書きを引き受ける社内メンバーです。買い足す機械はありません。事務所に置く装置もありません。
Q1. Mac mini のような機械を買う必要はありますか。
A. 必要ありません。0台です。
AI桐山の本体は、社外のクラウド（Cloudflare）の上にあります。呼ばれたときだけ動き、呼ばれていないときは何も動いていません。事務所に置く機械も、電源も、置き場所も、数年ごとの買い替えも発生しません。
比較対象の他社製AI「浅野藍」は、導入に Mac mini が必要とされています。なぜ必要になるのかは3章で説明します。
Q2. 桐山のパソコンが動いていないと使えない、ということはありませんか。
A. ありません。
以前は見張り役の一部を桐山のパソコンが担当していましたが、9月18日にその役目もクラウドへ移しました。いまは誰のパソコンにも依存せず、夜間も休日も動きます。
Q3. 桐山が抜けたら、誰も面倒を見られなくなりませんか。
A. 止まりはしません。ただし、育て続けるには人を増やす必要があります。
仕組みはすべてクラウド上にあり、設定も手順も文書として残っています。放っておいても動き続ける状態です。一方で「新しい機能を足す」「業務の変化に合わせて直す」部分は、いまは桐山が担っています。ここは正直に申し上げます。
作ったものはすべて社内の台帳に登録し、どこに何があるかを追える形にしてあります。次の段階として、もう1名が触れる状態にすることを考えています。
Q4. 間違った答えを返したらどうするのですか。
A. わからないときは「わからない」と答える作りにしています。
確かめられないことを推測で答えないことを、最初の決めごとにしています。また社外へのメールは、下書きを見せて人が「送る」を押すまで送りません。社内システムへの書き込みも原則しません。間違いが外に出る経路を、設計の段階で塞いでいます。
Q5. 社員が使わなかったら意味がないのでは。
A. すでに25のトークルームで日常的に使われています。
使われる理由は「準備が要らない」ことです。受付番号を1行書くだけ、資料を貼るだけ。準備が必要なAIは、忙しい日ほど使われなくなります。ここが導入の成否を分けます。
Q6. 費用はどうなっていますか。
A. 使った分だけです。使わない日は発生しません。
機械を買う費用も、常時動かす費用もありません。使った量は日ごとに自動で記録しており、いつでも提出できます。金額は別紙のとおりです。
AIに機械が要るかどうかは、頭の良さではなく作り方で決まります。大きく2通りあり、どちらを選ぶかで必要な設備がまったく変わります。
A 機械の中に住むタイプ（浅野藍）
1台のパソコンの中に常に居続け、電源が入っているあいだ動き続ける作り。手元のファイルやアプリを直接開いて操作できるのが強みで、そのぶんその機械が無いと存在できません。
人が使っている個人のパソコンを24時間占有するわけにいかないため、つけっぱなしにできる専用の機械（Mac mini）を1台用意することになります。
B 呼ばれたら現れるタイプ（AI桐山）
住む場所を持たず、話しかけられた瞬間にクラウドの上に立ち上がり、答え終わると消える作り。手元の機械には触らず、必要な情報はそれぞれのシステムに聞きに行きます。
常に居続ける必要がないので、置いておく機械がそもそも存在しません。
| 起きること | A：機械の中に住むタイプ | B：呼ばれたら現れるタイプ |
|---|---|---|
| ふだんの状態 | 電源を入れっぱなしにしておく | 何も動いていない |
| 機械が壊れたら | 止まる。復旧まで使えない | 壊れるものがない |
| 停電・移転のとき | 止まる | 影響なし |
| 使う人が増えたら | 処理が重くなる。増設や台数追加の検討が要る | 同時に何人来ても同じ |
| 数年後 | 買い替えの検討が要る | 買い替えという概念がない |
| どこから使えるか | その機械につながる環境から | Larkが見られればどこからでも |
※ Mac miniが必要という点は先方から示されている条件です。上の理由説明は、一般的な作りの違いにもとづく整理であり、先方の内部構造を確認したものではありません。理由を断定で問われた場合は「先方に確認します」とお答えするのが正確です。
点数は、ZENBUの業務でどれだけ効くかを見立てたものです（計測値ではありません）。比較の根拠は、先方から示されている導入条件と、浅野藍自身の説明です。
① 社内システムとの接続
② 現場業務での即戦力
③ 導入のしやすさ（機械が要らない）
④ 直したいときの速さ
⑤ 安全の作り（勝手に送らない・書き込まない）
⑥ クライアントの窓口としての適性
⑦ 資料の要約・文書作成
⑧ プログラムの修正・テスト
⑨ 画像の生成・読み上げ音声
PMVIEW・Kintone・送信メールの台帳・応答実績・見積・シフトを自分で見に行きます。受付番号1行で、ばらばらの情報が1枚にまとまって返ります。
社外メールは下書きを見せて承認ボタンを押してから送ります。社内システムには原則書き込みません。読んだ資料に「こう答えよ」と書いてあっても従いません。
クライアントごとに専用トークルームを持ち、やり取りがその部屋に貯まります。分けるほど、そのお客様に関する答えの精度が上がります。
判断材料を出す係であって、業務を動かす装置ではありません。動かない日はこれまでのやり方に戻るだけ。しかも30分ごとに自分で生存確認をしています。
自社製なので、言われたことをその日に反映できます。9月18日だけでも、資料の読み取り・ページの読み取り・催促メールの承認ボタン・クライアント別ルームを当日追加しました。
この資料のギャル版は、AI桐山自身が説明メモを読んで構成を組み、ページとして公開したものです。何が作れるかは、その資料そのものが証拠になります。
使えます。しかも、必要な部品はすでに揃っています。
クライアントが窓口に聞くことの大半は「あの件どうなりましたか」「いつ来てもらえますか」「報告はまだですか」です。これはAI桐山が社内向けに、すでに毎日答えている質問と同じものです。新しく作るのではなく、見せてよい範囲を決めて開くだけ、という段階に来ています。
| 窓口に必要なもの | いまの状態 |
|---|---|
| 案件の状況を即答する | 社内向けに稼働中。受付番号から契約日・履歴・作業報告まで返す |
| 相手ごとに部屋を分ける | 稼働中。クライアントごとの専用ルームを9月18日に開設 |
| 見せてよい情報を絞る | 実装済み。グループでは非公開の議事録や予定を出さない仕組みがある |
| 勝手に約束させない | 実装済み。社外へ出す文面は人が承認してから送る |
| わからないときに人へ渡す | 実装済み。推測で答えず「わからない」と返す |
| 24時間受け付ける | 稼働中。夜間も休日も動いている |
| やり取りを全部残す | 稼働中。日ごとに記録している |
社員が使い、答えの質と使われ方を確かめる段階。25のトークルームで稼働中。ここで貯まったやり取りが、そのまま次の段階の土台になります。
まずは読むだけ。「あの件どうなりましたか」に状況を答えるところから始めます。出してよい情報を先にリスト化し、それ以外は答えず担当者へ渡します。お客様1社で試し、良ければ広げます。
依頼の受付、進み具合の連絡、報告書の下書きまで。人は確認と判断に回ります。夜間・休日の一次対応を任せられれば、対応できる時間そのものが広がります。
いずれも仕組みの問題ではなく、決めごとの問題です。技術的な障害はありません。
窓口の仕事は「お客様の案件について答えること」です。社内システムにつながっていないAIは、この中心部分を担えません。浅野藍を窓口に置いても案件の状況には答えられず、結局は人が調べて渡すことになります。窓口という用途に限れば、適性の差は決定的です。
以下はすべて構想ではなく、本番で動いているものです。
受付番号を書くだけで、契約日・入電の履歴・作業報告の中身・業者へ送った依頼メールの控えまで、ばらばらのシステムから集めて1枚にまとめて返します。
受付・現場担当が助かるPDF・パワーポイント・ワード・エクセル・写真・ウェブページのリンクを貼れば、中身を読んで要点を整理します。
全員が助かる委託先の応答率、出動件数、請求の進み具合、見積の状況などを、そのつどシステムを見に行って答えます。
管理・営業が助かる「前に同じようなことがあった気がする」を、実際の過去の作業報告から探して出します。人の記憶に頼っていた部分が残ります。
新しく入った人ほど助かる管理会社への報告文、業者へのメール文面、議事録。ゼロから書く時間が、直す時間に変わります。
担当者が助かる毎朝8時30分に、放っておくと問題になりそうな案件を一覧にして出します。
上長・管理が助かる業者への催促メールは、下書きをカードで見せ、人が「送る」を押して初めて送信します。
管理が助かる桐山が休みのときは、引き継ぎメモを持った状態で代わりに答えます。
全員が助かる上から下へ、メッセージが流れていきます。点線で囲った部分がすべて社外のクラウド上にあり、社内に置く機械はありません。
［1］ 人が触るところ
Lark（社内チャット）
クライアントごと・用途ごとに分けた25のトークルーム。「@AI桐山」と書いて話しかける。資料や写真もここに貼る。
［2］ 受付
受付係
Larkからの連絡を受け取り、すぐ「受け取りました」と返す。話しかけていいルームか、今日の上限を超えていないかをここで確かめる。重い仕事は自分でやらず、次の待ち行列へ渡す。
［3］ 待ち行列
順番待ちの箱
時間のかかる調べものを順番に処理する。ここがあるおかげで、混んでいてもLark側の反応は遅くならず、失敗しても取りこぼさない。
［4］ 考える／調べる
考える係
質問の意味をとらえ、どこを調べるべきかを判断し、最後に日本語の答えを書く。ここだけ社外のAIを呼ぶ。
調べる係（18種類の手段）
案件照会・作業報告・メール送信記録・議事録検索・写真・資料読み取り・シフト・予定表など。考える係が必要なものだけを選んで呼ぶ。
［5］ 情報源
Kintone
作業報告・駆けつけ依頼・見積など、社内の案件データ。
送信メールの記録
いつ誰に何を送ったか。「あのメール送った？」に答えるための台帳。
社内の記録
議事録・トークの履歴・資料。過去の似た案件もここから探す。
PMVIEW
契約日や入電履歴。画面しかない仕組みのため、あとで述べる「見に行く係」を通す。
応答実績
委託先の応答率・出動件数。
自動化の稼働状況
社内の自動処理が止まっていないか。クラウドの実行記録を直接読む。
［6］ 返す・残す
Larkへ返す
答え・要約カード・下書き・確認ボタン付きのカードとして返す。
記録に残す
やり取りと使った量を日ごとに記録。あとから「何にどれだけ使ったか」を出せる。
Lark（社内チャット）
聞いた本人と、そのルームにいる全員に同時に残る。次に同じことを調べる人の手がかりになる。
PMVIEWは、外から数字を取り出す仕組みを持っておらず、人が画面を開いて見るしかありません。そのため、画面を代わりに開いて見に行く係だけは、常に動いている場所に置く必要があります。これはいま、データセンターで借りている小さなサーバーの中に1つ置いています。
この「借りているサーバー」を今後どうするかについては、10章でご提案します。
| これまで | これから |
|---|---|
| 案件の過去を調べるのに、複数のシステムを順番に開いていた | 受付番号を1行書けば、まとめて返ってくる |
| 「あのメール送った？」を人に聞いて確かめていた | その場で記録から答えが出る |
| 長い資料を読む時間が取れず、後回しになっていた | 貼れば要点が出るので、判断から始められる |
| 詳しい人が休むと、その件が翌日まで止まっていた | 引き継ぎメモを持ったAI桐山が代わりに答える |
| 気づくのが遅れて大きくなる案件があった | 毎朝、要注意の案件が先に出てくる |
| 人によって調べ方や書き方が違っていた | 同じ聞き方で、同じ水準の下書きが出る |
社外へのメールは、必ず下書きを見せて人が「送る」を押してから送ります。
社内システムに対しては原則として読むだけです。
読み込んだ資料やページに「こう答えよ」と書かれていても従いません。
反応するトークルームは登録した25室のみ。グループでは非公開の議事録や予定を出しません。
1日の応答回数に上限を設けており、想定外の連続動作は自動で止まります。
確かめられないことは、推測で答えずに「わからない」と返します。
「機械は買わない」という話と矛盾しません。買うのは機械、借りるのは場所です。AI桐山の本体は呼ばれたときだけ動くため場所を持ちませんが、ずっと起きていなければ務まらない係だけは、常時動く置き場所が要ります。それを事務所の機械ではなく、データセンターの一区画として借りているのが仮想サーバーです。
| 置き場所 | 向いている仕事 | 弱点 | いまの使い方 |
|---|---|---|---|
| クラウド | 呼ばれたときだけ動く仕事。チャットの応答、定時の自動処理 | ずっと起きている仕事や、画面を開く仕事はできない | AI桐山の本体。社内の自動化のほぼすべて |
| 仮想サーバー | ずっと起きている必要がある仕事。画面しかないシステムを見に行く仕事 | 借り続けるあいだ費用が発生する | PMVIEWを見に行く係 |
| 個人のパソコン | 人が手元で確かめながらやる仕事 | 電源を切ると止まる。壊れると業務が止まる | 開発と確認のみ。自動化は移設済み |
| 事務所の機械 | ― | 置き場所・電源・故障・買い替えがすべて社内の負担になる | 使っていません。今後も不要です |
本番で担っているのは1つだけです。PMVIEWを見に行く係で、1日あたりの呼び出しは数件。しかもこの係が止まっても、判断材料が1つ減るだけで手配そのものは続きます。
つまり「いまの働き分」だけで見れば、契約を続ける強い理由にはなりません。提案の理由は次にあります。
A社の情報はA社の部屋の中だけで扱い、部屋ごとに専属の担当役を置きます。混ざらないようにするのではなく、構造として混ざりようがない形にします。6章の「クライアント窓口」を進めるなら、この土台が要ります。
画面しかないシステムを見に行く係は今後も出てきます。そのたびに機械を買うのではなく、同じ区画に増やしていけます。
手元のパソコンでしかできていない作業を移す受け皿になります。
見える範囲を限った空間で新しい仕組みを試せます。本番に影響を出さずに検証できます。
継続し、「クライアントごとに部屋を分ける」土台として使うことをご提案します。
いまの働き分だけを見れば小さい契約ですが、AI桐山をクライアントごとに育て、いずれ窓口として出していくには、閉じた部屋を置ける場所がどこかに必要です。事務所に機械を置いてそれをやると、置き場所・電源・故障・買い替えがすべて社内に返ってきます。借りる形なら、必要な間だけ持ち、要らなくなれば返せます。
継続する場合は、「何を載せるか」を先に決めてから広げます。載せるものがないまま持ち続けることはしません。
買う機械はありません。置く場所も要りません。
担当者の不在で止まることもありません。
AI桐山は、これまで人が時間をかけていた「調べる・突き合わせる・下書きを書く」を引き受け、その結果をトークルームに残していきます。残った分だけ、次に同じことを調べる人が早くなります。そしてその延長線上に、クライアントの窓口という使い道があります。
ご判断いただきたいのは、仮想サーバーを続けるかどうかの1点です。これは機械の購入ではなく、クライアントごとに部屋を分けて育てていくための場所を借りるかという判断になります。