私は以前、会社の状況を確認するたびに、社内チャット、共有資料、開発履歴、顧客・案件の管理、アクセス解析を順番に開いていました。
数字や記録はすでに存在しています。ただ、それぞれ別の場所にあるため、最後は自分で集め直さなければなりません。経営判断より前に、情報収集へ時間を使っていました。
そこでBeekleでは、日々の仕事から残る記録を生成AIから確認できるようにし、経営者には対応が必要なものだけを知らせる仕組みを作っています。
社長の時間を作る経営DXでは、判断を自動化する前に、判断の準備を減らすことが重要です。
最初に自動化したのは、日々の確認でした
Beekleでは、毎日のマーケティング確認に、アクセス解析、検索結果、ページ内行動、顧客・案件の記録を使っています。以前は、それぞれの画面から数字を集め、どこが問題かを考えていました。
現在は、生成AIに複数の情報源を確認させ、「有効な問い合わせを増やすために、今日もっとも直す価値がある一つは何か」まで圧縮させています。閲覧数や検索表示回数を並べるだけではなく、問い合わせ、商談、案件、受注につながったかを顧客・案件の記録まで追います。
生成AIが経営を代わりに行うわけではありません。私がしているのは、数字の取得、比較、欠損確認、仮説整理を任せ、最後に一つの判断材料だけを受け取ることです。
この運用によって、私は各画面を順番に確認する作業より、どのページを直すか、どの商品を伸ばすかへ時間を使えるようになりました。
日報は、既存の記録から自動で作るようにしました
日報は、仕事が終わった後に、その日に行ったことをもう一度書き直す作業になりやすいものです。しかし、社内チャットには判断の経緯が残り、共有資料には更新内容が残り、開発履歴には実際の変更が残っています。
Beekleでは、これらの記録を組み合わせて、その日に進んだこと、止まったこと、次に確認すべきことをまとめる運用を試しています。共同作業者が更新した内容は、私自身の成果と分けて扱います。単に更新件数を数えるのではなく、誰が何を進めたかを区別するためです。
日報を書く人の記憶へ頼ると、忙しかった仕事だけが強く残り、細かな進捗や他者の作業が混ざります。既存の記録から作れば、少なくとも「何が起きたか」の確認はしやすくなります。
人に新しい入力を増やす前に、すでに残っている記録を使えないかを見る。これが、私が経営DXを考える時の基本になっています。
経営者の時間を奪う仕事は、四つに分けると見つけやすい
実際の仕事を見直すと、社長の時間を奪う作業は、次の四つに分けられます。
- 集める仕事:複数の画面、資料、担当者から情報を集める
- 写す仕事:すでにある情報を、別の表や報告書へ転記する
- 追う仕事:期限、請求、返信、更新を覚えて催促する
- 全部見る仕事:問題のない案件まで含め、毎回全件を確認する
これらは、経営者の経験や責任が必要な判断とは異なります。情報の場所と判定条件を決めれば、かなりの部分を仕組みに任せられます。
反対に、投資、採用、値決め、撤退、重要顧客との関係などは、会社の状況を踏まえた意思決定が必要です。経営DXの目的は、ここまで自動化して社長を不要にすることではありません。
機械に任せやすい確認作業を減らし、社長にしかできない判断へ時間を戻すことが目的です。
生成AIには文章を整理させ、金額と期限は決めた規則で判定します
会社の情報を生成AIへ集めれば、すべて自動で正しく判断できるわけではありません。文章の整理と、金額や期限の判定は分けた方が安全です。
たとえば、商談の記録から顧客の課題、関係者、次の行動を抜き出す処理は、生成AIと相性があります。一方、「請求予定日を七日過ぎた」「粗利率が会社の基準を下回った」「十三週間以内に現金残高が最低基準を割る」といった判定は、会社で決めた規則を使います。
社内チャット・会議・資料・顧客情報・会計情報
↓
文章から顧客、案件、判断、期限の候補を整理
↓
会社の規則で金額と期限を判定
↓
根拠と元データを付けて人に提示
↓
人が確定・修正・判断
生成AIの回答には、もっともらしい誤りが含まれることがあります。そのため、元の記録を確認できることと、人が確定する段階を残すことが必要です。
経営者の画面には「今日決めること」だけを表示します
経営者向けの管理画面に情報を増やしすぎると、確認する仕事が増えます。私が欲しいのは、会社のすべてを一覧できる画面ではなく、今日判断が必要なものです。
たとえば、次のような形です。
今週の確認事項は三件です。
・六週間後の現金残高が社内基準を下回る見込み
・一件の開発案件で、見積もり時より粗利率が低下
・契約更新が近い顧客のうち、長期間接点がない会社が一社
この出力には、何が起きているか、なぜ警告されたか、元の数字はどこにあるか、次に誰が何を確認するかを付けます。
経営者が全件を見ないことは、管理を弱めることではありません。通常の案件を仕組み側で処理し、異常へ早く注意を向けるための設計です。
では、実際にどう始めるのか。最初に決めるのは一つの出力です
「社内データを生成AIにつなぐ」から考えると、対象が広すぎて動けません。最初に決めるのは、毎日または毎週、社長に何を知らせるかです。
次の四点を一文で書きます。
- 誰が見るか:社長、営業責任者、経理担当者など
- いつ見るか:毎朝九時、毎週月曜、月末三営業日前など
- 何を警告するか:期限超過、空欄、基準未達、長期間更新なしなど
- どこへ返すか:Google Chat、Teams、Slack、メールなど
たとえば、次の程度まで具体化します。
毎週月曜9時に、営業案件のうち「次の行動が7日以上未設定」「見積有効期限が14日以内」「顧客からの返信待ちが5営業日以上」の案件だけを、理由と元データのリンク付きで社長に送る。
この一文が書ければ、必要なデータ、判定規則、通知先が決まります。反対に、この一文が書けない段階でRAGやデータ基盤の製品を選んでも、何を作れば完成なのか決まりません。
手軽に始めるパターン。既存ツールの中で一つの確認だけ自動化する
最初の検証では、専用のデータベースや大規模なRAGを作らなくても構いません。一つの部署、一つか二つの情報源、一つの定期確認に絞ります。
- データは、現在使っている表、顧客管理、カレンダー、共有資料に置いたままにする
- 期限、金額、空欄、更新日などは、表計算や自動化ツールの規則で絞る
- 議事録やメールなどの長文だけ、生成AIに要約・分類させる
- 警告理由と元データのリンクを、普段使うチャットかメールへ送る
- 元データの更新や顧客への連絡は、最初は人が行う
今使っている業務ツール
↓
決めた時刻に読み取る
↓
規則で対象を絞り、必要な文章だけ生成AIで整理
↓
理由と元データのリンクを通知
↓
人が確認して対応
最初から自動更新まで行わず、読み取り専用で始めるのが安全です。誤った要約や条件漏れがあっても、元データを書き換えないためです。二週間ほど運用し、見逃し、誤警告、削減できた確認時間を見てから範囲を広げます。
Google Workspace中心の会社で手軽に始める場合
Google Workspaceでは、主な情報源はGoogle Drive、Gmail、Google Calendar、Google Sheetsです。Google Chatは、結果を受け取る場所として使えます。
- 正式な資料は、個人のマイドライブではなく共有ドライブまたは共有フォルダへ寄せる
- 案件や確認事項はGoogle Sheetsに置き、「顧客」「担当」「次の行動」「期限」「金額」「元資料URL」など最低限の列を決める
- Apps Scriptや自動化サービスを使い、毎朝または毎週、期限超過や空欄だけを抽出する
- 議事録やメール本文を生成AIで短く整理し、規則で抽出した結果へ添える
- Google ChatまたはGmailへ、警告理由と元のDrive・Sheetsへのリンクを送る
Drive・Gmail・Calendar・Sheets
↓
Apps Scriptまたは自動化サービス
↓
期限判定・空欄確認+文章要約
↓
Google ChatまたはGmail
この構成なら、新しい管理画面を作らずに始められます。GoogleはApps ScriptからGmail、Calendar、Driveなどを扱えるため、Google Workspace内で完結する一業務の自動化と相性があります。
生成AIへ読ませる範囲は、対象フォルダ、対象ラベル、対象カレンダーなどに限定します。全社員のメールや全社Driveを最初から横断させる必要はありません。
Microsoft 365・Teams中心の会社で手軽に始める場合
Microsoft 365では、Teamsだけを見ても正式なデータの場所は分かりません。Teamsのチャネルに置いたファイルはSharePoint、チャットで送ったファイルは送信者のOneDrive for Businessに保存されます。Outlook、Microsoft Lists、Plannerなども別の情報源です。
そのため、「Teamsを生成AIに読ませる」ではなく、何をSharePoint、Lists、Outlook、Plannerから読むかを決めます。
- 正式な資料はTeamsのチャネルに紐づくSharePointに置き、個人チャットの添付ファイルを正本にしない
- 案件や確認事項はMicrosoft Lists、既存のExcel、Dynamicsなどのうち一つを正本にする
- Power Automateで、期限超過、未入力、更新停止などを定期的に抽出する
- 会議記録やメールなどの文章だけ、Copilotまたは生成AIで要約・分類する
- Teamsへ、元データへのリンクとともに通知する。必要なら承認ボタンや対応済みボタンを付ける
SharePoint・Lists・Outlook・Planner
↓
Power Automate
↓
期限判定・空欄確認+文章要約
↓
Teams
Teamsは、データを全部保存する箱というより、社員が結果を受け取り、対応する入口として使う方が整理しやすくなります。

ガッツリ作るパターン。複数システムをつなぎ、会社の規則まで実装する
手軽な構成では足りないのは、営業、会計、案件、勤怠、マーケティングなどを横断して判断したい場合です。たとえば、「受注予定と入金予定から十三週間の資金繰りを予測する」「開発履歴と工数から案件別の粗利低下を警告する」「失注理由とWeb流入をつなげて商品改善を提案する」といった処理です。
この段階では、チャットへ生成AIを置くだけではなく、次の設計が必要です。
- 正本を決める:顧客はCRM、請求は会計、予定はカレンダーなど、項目ごとに元データを一つ決める
- APIやMCPで接続する:各システムから必要なデータを継続取得する(画面のコピーは使わない)
- 識別子をそろえる:会社名の表記揺れではなく、顧客ID、案件ID、請求IDで結び付ける
- 構造化データを蓄積する:期間比較や予測が必要な数字は、データベースやデータ基盤へ履歴を残す
- 文章処理と規則判定を分ける:生成AIは要約・分類・仮説整理、金額・期限・権限は決めたロジックで処理する
- 権限を引き継ぐ:元の資料を見られない人に、生成AI経由で内容が漏れないようにする
- 根拠と監査履歴を残す:どのデータから、どの規則で警告したかを後から確認できるようにする
- 更新は承認制にする:CRMの変更、請求処理、顧客への送信などは、人の承認後に実行する
Google Workspace中心でガッツリ作る構成例
Drive・Gmail・Calendar・Sheets・CRM・会計・アクセス解析
↓
Google Workspace API・各SaaS API・MCP
↓
BigQueryまたはPostgreSQLなどのデータ基盤
↓
会社の規則による判定+RAG・生成AIによる文章整理
↓
Google Chat・Slack・ChatGPT・専用画面
Google Workspace内の情報だけでなく、顧客管理、会計、広告、開発管理まで横断する場合は、Apps Scriptだけにすべてを載せず、API連携とデータ基盤を分けます。定期集計や履歴分析はデータ基盤、利用者とのやり取りはGoogle Chatなどへ分けると、運用と修正がしやすくなります。
Microsoft 365・Teams中心でガッツリ作る構成例
SharePoint・OneDrive・Outlook・Teams・Lists・Dynamics・基幹システム
↓
Microsoft Graph・Power Platform・各SaaS API・MCP
↓
Dataverse・Microsoft Fabric・Azure SQL・PostgreSQLなど
↓
会社の規則による判定+RAG・生成AIによる文章整理
↓
Teams・Copilot Studio・専用画面
Microsoft 365では、Microsoft Graphを使うと、SharePoint、OneDrive、Outlook、Planner、Teamsなどへ共通の認証基盤から接続できます。ただし、取得できる範囲を広げるほど、Microsoft Entra IDの権限、管理者同意、監査設計が重要になります。
Teamsの会話をすべて正本にするのではなく、会話から確定した案件、期限、判断をCRM、Lists、Dataverseなどに反映する設計にします。チャットは経緯、業務システムは確定情報、と役割を分けるためです。
Google WorkspaceとTeamsが混在している場合
Google DriveやGmailを使いながら、社内連絡だけTeamsという会社もあります。この場合、最初からMicrosoft 365かGoogle Workspaceのどちらかへ全面移行する必要はありません。
まず、データを置く場所と通知を受け取る場所を分けます。
Google Drive・Gmail・Google Calendar・CRM
↓
API連携または自動化サービス
↓
規則判定・文章要約
↓
Teamsへ通知
同じ正式資料を、Google DriveとSharePointの両方に置かないでください。両方に最新版らしいファイルがあると、生成AI以前に、人間もどちらを信じればよいか分からなくなります。
混在環境では、次の三点を先に決めます。
- 顧客、案件、請求、資料ごとの正本はどこか
- GoogleアカウントとMicrosoftアカウントを、どの社員として対応付けるか
- 生成AIが取得した要約から、元データの権限を超えて内容が漏れないか
最初は、Google側のデータを読み取り、Teamsへ元データのリンク付きで知らせるだけにします。自動更新や双方向同期は、正本と権限が固まってから追加します。
手軽なパターンとガッツリ作るパターンの選び方
判断項目 | 手軽に始める | ガッツリ作る |
|---|---|---|
対象 | 一つの定期確認、一部署 | 複数部署、経営全体 |
情報源 | 一つか二つ | 三つ以上を横断 |
データの場所 | 既存ツールに置いたまま | 正本を定義し、必要な履歴をデータ基盤へ集約 |
生成AIの役割 | 要約、分類、候補抽出 | 複数データを踏まえた仮説整理、対話型の確認 |
金額・期限の判定 | 少数の固定規則 | 版管理された会社の規則、予測、例外処理 |
元データの更新 | 人が手作業 | 承認後に自動更新 |
権限・監査 | 元ツールの権限を利用 | 横断権限、操作履歴、漏えい防止まで設計 |
開始までの目安 | 数日から二週間程度 | 一か月から三か月以上 |
一文で出力を定義でき、情報源が一つか二つなら、手軽なパターンから始められます。複数システムの数字を結び付ける、元データを自動更新する、社員ごとに見せる範囲を変える場合は、ガッツリ作る側です。
ただし、給与、人事評価、資金移動、契約判断など、誤りや漏えいの影響が大きい業務は、情報源が一つでも権限、承認、監査を含む本格設計が必要です。
実際に減ったかは、機能数ではなく時間と再確認回数で測ります
経営DXは、システムを導入しただけでは成功とは言えません。新しい管理画面が増え、結局すべてを社長が確認するなら、仕事を増やしただけです。
Beekleでは、次のような数字で効果を見るようにしています。
- 社長が情報収集と転記へ使った時間
- 同じ質問へ再回答した回数
- 期限を過ぎてから気づいた件数
- 全案件を確認した回数と時間
- 生成された候補を人が大きく修正した割合
- 警告から意思決定までにかかった時間
まだすべての業務で効果を測り切れているわけではありません。現在も、情報源の違い、重複、入力漏れを直しながら運用しています。
それでも、最初から大きな基幹システムを作るより、毎週繰り返している一つの確認作業を減らし、前後の時間を測る方が改善しやすいと考えています。
社長の時間を作る仕組みは、小さな一つから始められます
最初に対象にするのは、頻度が高く、情報がすでにどこかに残り、社長が毎回関わっている仕事です。
商談後の次の行動を抜き出す。請求予定日の遅れだけ知らせる。同じ質問へ過去の判断を出す。毎日のマーケティング数字を一つの提案へ圧縮する。これらは、会社全体を作り替えなくても試せます。
既製サービスで解決できるなら、それを使います。既存の道具をつなげば済むなら、連携だけ作ります。会社固有の判断が残る部分だけ、専用の仕組みにします。
Google WorkspaceでもMicrosoft 365・Teamsでも、相談時に必要なのは「現在使っているツール」と「毎週、社長が確認している一つの仕事」です。最初から全面移行や全社データ統合を行う必要はありません。
経営DXの成果は、導入した機能ではなく、社長の予定表から何時間消えたかで測る。
私はこの基準で、自社の管理、営業、開発、マーケティングの仕組みを作り直しています。
同じテーマの記事
- 元の資料を直しても、仕様には反映されなかった。PM on Railsに判断と変更の流れを作った
- 任せた仕事を取り戻していた。進捗報告ではなく「動いた証拠」を見るようにした
- 既存顧客への追加提案を担当者の記憶に頼らない。顧客管理と社内知識を分けてつないだ
- 求人を出す前に、社長の仕事を分解する。実際の業務から採用すべき役割を決める
- 紹介に頼り切らない営業。紹介者の説明を会社の資産に変える
参考資料
- Google Workspace for Developers
- Google Apps Script overview
- Microsoft Support: File storage in Microsoft Teams
- Microsoft Graph overview
- Microsoft Power Automate documentation
- 田所雅之『増補改訂版 起業の科学 スタートアップサイエンス Ver.2』
- 入山章栄『世界標準の経営理論』
