現場に入り 何をすべきかを見極め
必要な手段を選んで実現する
学科では 統計学・機械学習・プログラミングを ビジネスの課題やデータに結びつけて扱うことを学んだ。データを集めて分析するところで終わらせず 意思決定に使える形にするまでを一続きで訓練する学科である。
大学の卒業時期を延ばし その期間を使って AIスタートアップ QuackShift（東京大学松尾研発 / 物流・SCM・製造業に特化したオーダーメイドAI開発）のインサイドセールスチームで実務に従事している。担当は展示会である。出展の準備から当日の運営 / 獲得したリードの追客 / CRMの管理までを一貫して持ち 週次の展示会定例ではオーナーを務めている。
私はエンジニアではない / ビジネス側の人間である。ただし業務に必要な道具が無いときは自分で書く。AIエージェントに業務を任せるためのサーバーを8本内製し 日々の仕事はその上で回っている。
| 学業 | 中央大学 理工学部 ビジネスデータサイエンス学科 — 統計学・機械学習・データ分析 |
|---|---|
| 実務 | QuackShift インサイドセールス — 展示会の運営・追客・CRM管理 |
| 卒業研究 | 2026年1月 提出 — プレミアリーグの負傷要因分析 |
| 卒業見込 | 2027年3月 |
私は特定の分野や道具の専門家ではない。
現場に入り 何をすべきか（課題と方策）を見極め / それに必要な手段を選び / 実現まで届かせる。この「見極めて動かす」判断そのものを専門にしている。
手段は毎回変わった。営業フローの設計 / データ分析 / 自分でコードを書くこと。
以降の3つのケースと卒業研究は 全部この同じ型の実物である。
| 何をしたか | |
|---|---|
| CASE 01 営業フロー設計 | 担当者の感覚で決まっていた追客の優先順位を 誰が付けても同じ結果になる基準に置き換えた |
| CASE 02 データ分析 | その回の反省で終わっていた振り返りを 12本を同じ物差しで並べた基準値に変えた |
| CASE 03 業務自動化 | 「エンジニアに頼むか諦めるか」の二択だった作業を 自分で書いて日次で回る状態にした |
| 卒業研究 統計解析 | 負傷を3つの側面に分けて解析し 予測できる場所とできない場所を切り分けた |
※ 各ケースの実績数値は所属先の営業データにあたるため 本書では概要に留めている
担当者の感覚で決まっていた追客の優先順位を 誰が付けても同じ結果になる基準に置き換えた
展示会1本で獲得するリードは数百件 / 対して追客に使える工数は数人分しかない。それにもかかわらず 誰を優先して追うかは担当者の感覚に委ねられていた。担当が変われば優先順位も変わり / 施策が効いたのかどうかも検証できない状態だった。
設計の主要部は「何をやるか」ではなく「何をやらないかを決めること」にあった。
その回の反省で終わっていた振り返りを 12本を同じ物差しで並べた基準値に変えた
展示会ごとの結果は毎回振り返っていたが 話は単発の回の良し悪しに終始していた。どのレートが構造的に効いていて / どこが毎回詰まるのかを誰も持っておらず 改善案は思いつきの順に並んでいた。
分析の成果は 改善すべき場所を見つけることと同じだけ / 改善しなくていい場所を確定させることにある。
「エンジニアに頼むか諦めるか」の二択だった作業を 自分で書いて日次で回る状態にした
私はエンジニアではない / 営業として現場にいる。業務をAIエージェント（Claude Code）に任せる中で 既製のコネクタでは届かない不便が次々に出た。用途別の共有メールボックスを複数扱えない / 数百件のメモを意味で検索できない / スプレッドシートのCRMを安全に書き換えられない。どれも 頼める相手を待つか 手作業を続けるかの二択になっていた。
MCP（AIエージェントに外部のツールやデータを安全につなぐプロトコル）のサーバーを自分で実装した。現在8本 / うち7本を日次で運用している。あわせて 展示会準備・追客・集計といった業務の型を12本のコマンドに落とし込み エージェントから直接呼べるようにした。
| サーバー | 役割 | 状態 |
|---|---|---|
qs-rag | ローカル知識ベースの意味検索（grepの代替） | 日次運用 |
qs-gmail | 複数のGmailアカウントを識別子で一元操作 | 日次運用 |
qs-slides | ブランド適用済みのスライドを自動生成 | 日次運用 |
qs-docs | ドキュメント本文の読み書き | 日次運用 |
qs-drive | ファイルの操作・整理 | 日次運用 |
qs-crm-gas | スプレッドシートCRMの安全な読み書き | 日次運用 |
qs-forms | フォーム回答の読み取り | 運用中 |
qs-firm | 会社名 → 売上 → 企業ランクの自動判定 | 実装完了 |
道具を作ること自体が目的ではない。目的は現場が回ることで 内製はそのとき最も速い手段だった。
8本それぞれの課題・設計判断・公開ツールは別冊『MCP Portfolio』にまとめている — kazuki-ishizuka.pages.dev/mcp
サッカー選手の負傷を 「発生」「重症化」「負傷の種別」の3つに分けて 解析した。先行研究の多くは「負傷したか否か」という単一の指標に集約していて 現場の負荷管理に使える示唆が出にくいと考えたためである。
リーグ全体の選手を対象に 一般化線形混合モデルでチーム間の差を調整しながら要因を推定し あわせてチームの選手構成によるクラスター分析も行った。
結果として 年齢や体格 直近の出場時間から負傷の発生を予測することはできなかった一方で 直近に出場を継続している選手ほど 負傷しても長期離脱に至りにくいことが示された。発生そのものを当てにいくより 長期離脱の回避に絞ったほうが実務的である というのが結論になる。
効く場所と同じだけ「効かない場所」を確定させた点で この研究は CASE 02 と同じ骨格を持つ。
| 領域 | 内容 |
|---|---|
| 分析・統計 | 一般化線形混合モデル・クラスター分析・仮説検証・データ前処理・可視化 |
| プログラミング | Python（Pandas / NumPy / scikit-learn）／ SQL ／ JavaScript（Node.js） |
| 業務自動化 | GAS ／ Claude Code・MCPサーバー内製 ／ Google Workspace API |
| 業務設計 | 営業フロー設計・CRM設計・リード管理・優先度設計 |