最初の一手 — 統合プラットフォーム × 小さな成功パターン
この記事は、このガイド 0 章 5 記事のうち 5 本目（「具体的に何から始めるか」を扱う記事）です。0-2 で なぜ AI を入れざるを得ないか、0-3 で どう走るか、0-4 で 組織でどう入れるか を確認した読者に、本記事は 「明日からの最初の一手」を 5 つの判断軸で具体化します。
[i-00035]0章 5 記事のロードマップ（本記事は 0章の締め）
射程: 想定読者は 5〜100 名規模の経営者・推進担当。100 名超の中堅大企業も基本ロジックは同じですが、組織変革の規模感は章 12 で別途扱います。具体的な数値・ベンダー名は 2026 年 5 月時点の観測。プラットフォームの進化で評価は変わり得ます。
TL;DR — 最初の一手は次の 5 つ
5〜100 名規模の事業者が AI 導入で最初に取るべきは、次の 5 つです：
- 統合プラットフォーム（Google Workspace か Microsoft 365）に業務基盤を寄せる
- AI と既存システムの役割分担を先に決める（「非定型は AI、定型はシステム」）
- 全社一括変革ではなく「小さな成功パターン」から広げる
- 内製は慎重に判断する（運用フェーズで詰みやすい）
- 伴走型コンサル + 外部セキュリティ顧問の二段構えで進める
高額な全社改革コンサル × 大規模システム刷新は推奨しません。理由は本文で順に整理します。
1. 「最初の一手」の核心 — 5 つの判断軸
行動の前に、判断軸を 5 つに整理します。各軸は独立ではなく相互に関連しますが、判断の順序としてはこの 5 軸を上から下に進めるのが自然です。
| # | 判断軸 | 本記事のスタンス |
|---|---|---|
| 1 | インフラ統合プラットフォームの選定 | M365 か Google Workspace の二択。既存環境次第で選ぶ |
| 2 | AI とシステムの役割分担 | 「非定型判断は AI、定型処理は既存システム」が基本 |
| 3 | 展開の進め方 | 全社一括ではなく、小さな成功パターンから |
| 4 | 内製するか・買うか | 内製は慎重に。AI で安価な業務システムが出る流れも見ながら判断 |
| 5 | 外部にどこを頼るか | セキュリティ・PII は必須、業務翻訳は伴走型コンサル |
[i-00036]最初の一手 5 つの判断軸
各軸を順に深掘りします。
2. なぜ「インフラ統合プラットフォーム」から始めるのか
核心: AI を業務に入れるとは、AI と社内のファイル・システムを 安全に接続することです。この接続の土台がないと、AI 単体で何かを試しても業務には組み込めません。
統合プラットフォームの選択肢は、実質次の 2 つです。
Google Workspace と Microsoft 365 の現状（2026 年 5 月時点）
| プラットフォーム | AI 統合の現状 |
|---|---|
| Google Workspace | Gemini を Workspace 全体（Gmail / Docs / Sheets / Slides / Meet）に統合。Vertex AI 経由で Claude / OpenAI 等のモデル切替も可能 |
| Microsoft 365 | Copilot を M365 全体（Outlook / Word / Excel / PowerPoint / Teams）に統合。Microsoft Graph で全社データを横断接続。Azure 経由で OpenAI と密接統合 |
選び方の判断軸
- 既存環境: 既に M365 が全社で動いているなら、無理に Workspace へ移行する必要はありません。移行コスト（メールデータ・カレンダー・既存ファイル）は数百万〜数千万円規模になることもあります
- データ要件: GDPR・個人情報保護法等の データ所在要件がある業務は、各プラットフォームのリージョン対応を確認
- コスト: 公式公開価格で比較（Google Workspace 価格 / Microsoft 365 Business 価格）。1 人あたり月額の差は通常 2〜3 倍に収まります
- AI モデルの柔軟性: 将来 Gemini / Copilot 以外のモデルも使う想定があれば、Vertex AI / Azure のモデル切替の幅を確認
「どちらが絶対」ではない点が重要です。本記事は Google Workspace を例として進めますが、論点はほぼそのまま Microsoft 365 にも当てはまります。
[i-00037]Google Workspace vs Microsoft 365 AI 統合比較
補助線: いまここで構築する 業務側の設計知識（業務フローの可視化・AI と既存システムの役割分担・PII 取扱ルール）は、プラットフォームを乗り換えても無駄にならない普遍資産です。0-3 で触れた「投資が陳腐化しない領域」のひとつです。
3. 専用ツール vs 汎用プラットフォーム — 構造的なロックイン回避
核心: AI ワークフロー専用ツールを核に据えると、そのベンダーへの依存度が時間とともに高まります。汎用プラットフォーム上で組むと、相対的にロックインリスクが低くなります。
ロックインリスクのスペクトラム
| 選択肢 | ロックインリスク | 理由 |
|---|---|---|
| AI ワークフロー専用 SaaS | 高 | データ・業務ロジックが特定 SaaS の独自フォーマットに依存 |
| 業界特化型 AI ソリューション | 中 | 業界知見を抱え込んでおり、移行先が限定される |
| Google Workspace / M365 + AI | 低 | 汎用ファイル形式・標準 API・ロックインのモチベーションが構造的に低い |
| 内製 | （別軸） | ベンダーロックインは無いが、運用ロックインがある（§5 で詳述） |
[i-00038]ロックインリスクのスペクトラム
大手汎用プラットフォームのロックインモチベーションが低い理由
- 既に多数の顧客・収益基盤があり、個別顧客の囲い込みインセンティブが小さい
- 標準フォーマット（Google Docs ⇔ Word、Sheets ⇔ Excel）で相互変換可能
- API・エクスポート機能が充実（一括ダウンロード可）
将来オプション
「AI モデルを切り替えられる業務プラットフォーム」が成熟しつつあります。Vertex AI 自体がこの方向性を示しており、サードパーティでも各種登場中です。ロックインの低い汎用プラットフォーム上で業務設計を組んでおけば、将来そういったプラットフォームへ移行する判断も柔軟にできます。
業種特化の最適化は、汎用プラットフォーム + 既存業務システム連携で実現します。業種特化システム自体を購入するより、汎用 + AI で業務側を再設計する方が、ロックインを避けつつ柔軟性を保てます。
4. AI とシステムの使い分け — 「何でも AI 化」の罠
核心: AI と既存業務システムは、得意領域が 構造的に違います。役割分担を先に決めずに「とりあえず AI で」と始めると、後で必ず詰みます。
AI が得意な領域
- 非定型な入力の判断: 顧客メールの一次分類・問い合わせの緊急度判定
- 情報収集・要約: 社内資料からの要点抽出・議事録の宿題抽出
- 相手向けアウトプット生成: メール下書き・提案資料のたたき・FAQ 回答案
システム（既存業務システム）が得意な領域
- 定型ワークフロー: 経費精算の承認フロー・稟議の金額別分岐・押印ワークフロー
- 数値計算: 会計処理・税額計算・在庫数管理
- 厳密な記録・監査: 監査ログ・タイムスタンプ・改ざん防止
AI に数値処理を任せる際の構造的リスク
AI は数値そのものの正確性を保証する仕組みを持ちません。具体的には次のようなリスクがあります：
- トークン消費が過剰になる（コスト面で SaaS より割高）
- 桁の読み取りミス・抜け漏れ・計算結果のズレが起きる
- 「ハルシネーション」で実在しない数値を生成する
- 同じ入力でも出力が微妙に変わる（再現性の不足）
基本則
「非定型な判断は AI、定型処理はシステム」。両者を AI に統合的に扱わせる（AI が判断 → 既存システムを呼び出して処理 → 結果を AI が要約）のが理想形です。
具体的には：
- 領収書から経費精算書を発行する → 既存ワークフローシステムで処理
- 顧客メールを分類して下書きを作る → AI で処理
- 月次決算データを集計する → 既存会計システムで計算 → AI で要約とコメント生成
[i-00039]AI とシステムの役割分担マトリクス
AI Agent と既存システムは対立ではなく協調
近年の AI Agent（Tool use / Computer use を備えた AI）は、判断レイヤー（LLM）+ 操作レイヤー（RPA 的な画面・API 操作）の組み合わせとして理解できます。技術的には承認分岐のようなルールも AI Agent で扱えますが、業務として置き換えるかは経済合理性の問題です。
| 観点 | AI Agent に全任せした場合の不利 |
|---|---|
| コスト | 1 件ごとにトークン消費。件数に比例して課金 |
| 再現性 | 確率的出力。同じ条件で違う結果が出る可能性 |
| 監査 | Chain-of-Thought と実際の判断根拠が一致しない（post-hoc rationalization）。再現・検証が困難 |
| ハルシネーション | 重要な承認フローで誤判定が混入するリスクをゼロにできない |
→ ビジネスルール・権限・承認条件はシステムに落とすのが管理上の現実解。AI で「非定型な判断・自然言語の橋渡し」、システムで「ルール・権限・記録」、RPA / API で「システム間のつなぎ」という三者協調が現時点での現実的な構図です。詳細は 章 2 ムダを見つけ手段を選ぶ で扱います。
既存システムが既にあるなら、AI で再発明しない
実務上の最重要原則：既存システムで動いている業務を AI で作り直す必要はありません。
- 経費精算が既に freee / マネーフォワード等で動いているなら、ルール部分はそのまま使う
- AI で追加するのは「領収書画像 → 構造化データへの変換」「月次サマリの自然言語生成」等の 入出力の橋渡し
- 「全部 AI で再構築」は、既存資産を捨てる判断であり、ROI が成立しないケースが多い
0-3 との接続: 「短期は陳腐化が早い領域・長期は陳腐化しない領域」の観点で言えば、役割分担の設計そのものは長期資産です。AI モデルが変わっても、この役割分担表は再利用できます。
章 2 への送り: 4 階層の手段選択（手作業 / RPA / システム / AI Agent）の詳細な選定基準は 章 2 ムダを見つけ手段を選ぶ で扱います。本記事はその判断軸の核心だけを示しました。
5. 定型処理の受け皿は 3 段階で考える — 数式 / マクロ・GAS / 専用システム
核心: 定型業務をどこに載せるかは「スプレッドシートか専用システムか」の二択ではありません。数式（L1）／マクロ・GAS（L2）／専用システム（L3）の 3 段階で、業務の重さに応じて適材適所に選ぶ時代になりました。
AI 台頭で「手軽にシステムを作る」が選択肢に加わった
ここで一度、時代の前提を確認します。AI 登場以前は、定型業務を載せる先は事実上「スプレッドシート関数で凌ぐか、ベンダーに高額発注するか」の二択でした。「自社業務に合わせた小さなシステムを手軽に作る」は、現実的な選択肢としては存在しなかったのが実態です。
AI でシステム開発のコストが下がったことで、この前提が変わりました。自社業務に合った小さな業務アプリを、短時間・低コストで実装することが第三の道として選択肢に入ってきています。これは AI 台頭がもたらした環境変化のうち、現場の業務設計に最も大きく効く変化の一つです。
裏付けとして、AI 自身が反復処理・集計・整形といった定型作業を内部で扱う際、Python 等のコードを生成して処理する挙動が一般的になっています。「定型作業はコードに落とすほうが正確かつ再現可能」という事実を、AI 自身の挙動が傍証している形です。
3 段階の整理
| 段階 | 手段 | 向いている領域 | 強み | 弱み |
|---|---|---|---|---|
| L1 | スプレッドシート関数（数式・QUERY・IMPORTRANGE 等） | 個人〜数名の集計・転記の自動化 | 即着手・全員が読める | 規模・他システム連携で破綻 |
| L2 | スプレッドシートのマクロ・Google Apps Script（GAS） / Office Scripts | チーム単位の定型処理・通知・他サービス連携 | スプレッドシート文化に被せやすい・正当な現実解 | 権限・監査・テストが弱く、複雑化すると保守性が落ちる |
| L3 | 専用の業務システム（小さな業務アプリ） | 全社・部門横断・外部連携・機微データを含む業務 | 効率化・再現性・セキュリティ・監査・権限管理を載せやすい | 開発・運用コストがかかる |
L2 は古い／劣る選択肢ではありません。スプレッドシート上の運用に薄く乗せられる現実解として、多くの場合に最適です。「L2 で十分なものを L3 で作る」のは過剰投資ですし、逆に「L3 にすべきものを L2 で粘る」と保守の重荷になります。
選択基準
どの段階を選ぶかは、次の 3 軸で判断します。
- 関係者数: 個人〜数名なら L1、チーム単位なら L2、部門横断・全社なら L3
- データの機微度: 機微情報（個人情報・契約金額等）が増えるほど L3 寄り（権限管理・監査ログが必要になる）
- 業務停止リスク: 止まると業務が回らない／監査要件があるなら L3（決定論的な処理と監査ログが要る）
「L1 / L2 で立ち上げ、必要が見えたら L3 へ昇格」という走り方
最初から L3 を狙うのは多くの場合オーバースペックです。L1 や L2 で小さく立ち上げ、運用しながら「ここは L3 にすべき」という境界が見えてきたら昇格させる走り方が、コストとリターンの面で現実的です。
- 月数十件のチェック表 → L1 で十分
- チーム内で通知や転記を自動化 → L2（GAS）が筋
- 関係者が増え、権限管理や監査ログが必要に → L3 へ昇格
この昇格パスを最初から想定しておくと、「ある日突然 L3 を作らないといけない」というジャンプを避けられます。
ツール側にも層がある — 担い手で使い分ける
3 段階の受け皿を実装する AI ツール側にも層があります（自由度・前提スキル順に 6 層）。
| 層 | 例 | 担い手 |
|---|---|---|
| L0 内蔵 AI | M365 Copilot / Gemini in Workspace / Notion AI / freee AI | 全社員 |
| L1 Web チャット | ChatGPT / Claude.ai / Gemini.google.com | 知識労働者 |
| L2 業務統合 UI | Claude for Work / ChatGPT Enterprise | 管理下の全社員 |
| L3 ノーコード自動化 | Zapier / Make / Power Automate / GAS | 業務+α 人材 |
| L4 IDE 統合 | GitHub Copilot / Cursor / Windsurf | エンジニア |
| L5 CLI / Agent | Claude Code / Codex CLI / Gemini CLI | エンジニア精鋭 |
| L6 API | Anthropic / OpenAI / Google AI / Vertex AI | 開発チーム |
「上の層が偉いわけではない」点が重要です。L0〜L2 は組織の多数が日常使いする入口、L4〜L5 は少数のエンジニアが業務全体を駆動する司令塔。50 名規模なら L0 を 50 名・L1〜L2 を 25 名・L3 を 5 名・L4〜L5 を 1〜2 名が現実的な分布です。
定型処理の 3 段階とツール層の対応は L1 数式 → L0 内蔵 AI／L2 GAS → L3 ノーコード／L3 専用システム → L5 + L6。この層またぎを翻訳できる人材が 0-4 §8 で扱う「AI 翻訳役」 です。
章 2 / 0-3 との接続
- 章 2 では、4 階層（手作業 / RPA / システム / AI Agent）の手段選定を詳述します。本節の L1 / L2 / L3 は、その「システム」階層をさらに 3 段階に切り分けたものと理解してください
- 0-3 §13 で扱うとおり、この 3 段階の使い分けを設計できる人材が社内にいることが、継続投資面での核になります
6. 内製は慎重に — 「95% → 100%」の壁
核心: AI でシステムは作れます。ただし運用フェーズで詰むリスクが高いので、内製判断は慎重に進める必要があります。
なぜ「形は作れるのに運用で詰む」のか
AI でのシステム開発は、プロトタイピングを劇的に速くします。「できそう」に見えるところまでは数日で到達します。しかし、95% から 100% に上げる工程で躓きます：
- エッジケース対応（想定外の入力・データ形式）
- 本番環境の安定化（負荷・冗長化・監視）
- セキュリティ強化（認証・認可・PII マスキング）
- バグ修正・機能追加・障害対応の継続
これらは依然として人間の専門知識が必要で、AI が肩代わりできる範囲は限定的です。社内に強いエンジニアがいない場合、この継続的な負担で消耗します。
中期的にはシステム単価が下がる
AI で開発コストが下がると、業務システムの単価も下がる傾向にあります（既存ベンダーの AI 活用／AI ネイティブな新興企業／大手プラットフォームの標準機能取り込み）。「いま内製するより、しばらく待って安価な業務システムを買う方がトータル安い」という判断もあり得ます。
「誰が作るか」3 選択肢 — 推奨は C
| 選択肢 | 強み・弱み |
|---|---|
| A. 業務担当が AI に頼んで自作 | 手軽だがセキュリティ・権限の盲点を踏み外しやすい |
| B. 開発経験者にさくっと依頼 | 短時間・高精度。業務理解の橋渡しコストが必要 |
| C. 業務理解者が仕様、開発経験者が実装（推奨） | 仕様の妥当性と実装の確かさを両立 |
ただし C で作っても、継続的にメンテナンスできる体制がないと負債化します。理想は社内に 「AI に正しく頼める人」（コードを自分で書ける人ではなく）が常駐していること。L2（マクロ・GAS）でも L3（専用システム）でも、この人材が改修と継続を担保します。継続投資面は 0-3 §13 で扱います。
内製判断のチェックリスト
| 状況 | 推奨判断 |
|---|---|
| 社内に強いエンジニアがいる + 内製のドメイン知識が差別化要因 | 内製を検討 |
| エンジニア不在 or 1〜2 名 + 標準機能で代替可能 | 内製しない（Workspace + 既存 SaaS で組む） |
| 業界特化の規制要件を満たすシステムが既存ベンダーに無い | 内製 or 専門ベンダー検討 |
| 「AI で簡単に作れそう」という期待が主な動機 | 一度立ち止まる（運用コストを試算） |
[i-00042]内製判断のチェックリスト 4 状況
留保: 「数年以内にゼロ円になる」と煽る企画もありますが、現実には 段階的にコスト構造が変わる という表現が中立です。差別化要素（データ蓄積・業界知識・運用品質）を持つ既存システムは残ります。
7. ほとんどのバックオフィス業務は「Workspace + AI」で完結する
核心: 議事録・メール・経費・稟議など、バックオフィス業務の大半は Google Workspace（or M365）+ AI で回せます。新しい専用システムを買い足す必要はありません。
Workspace + AI で回る業務の例
- 議事録の自動作成と宿題抽出: Google Meet + Gemini（または Teams + Copilot）
- メールの一次分類と返信案ドラフト: Gmail + Gemini（または Outlook + Copilot）
- ドキュメントの要約とレビュー: Docs / Word + 各社 AI
- スプレッドシートの数値分析の補助: Sheets / Excel + 各社 AI
- 会議資料の構成案生成: Slides / PowerPoint + 各社 AI
例外領域（専門システムが残る）
すべてが Workspace + AI で完結するわけではありません。例外は次の通りです：
- 画像診断・専門データ解析: 画像認識や時系列データの専門蓄積が要る業務
- 規制要件のある業務: 業界規制でコンプライアンス機能が組み込まれた業務システムが必要なケース
- 既存の業務量・データ量が桁違い: ERP 規模の運用が必要な大企業
「システムは結局データの入出力」
業務システムの本質は、データを入れて、加工して、出力することです。クラウドスプレッドシート（Google Sheets / Excel Online）の集まり と言っても過言ではありません。そこに AI が入って「自然言語での操作」「データからの判断」「画像からの抽出」といった新しい層が加わったのが現状です。
「システム化＝専用ソフトの購入」ではない
現代のクラウドスプレッドシートは、共同編集・バージョン履歴・行列単位の権限・数式バリデーション・スクリプト連携・監査ログ（エンタープライズ機能）を標準装備しています。経費精算・売上管理・在庫管理など多くの定型ワークフローは、Sheets / Excel + AI で「システムとして」十分機能します。AI を加えれば領収書画像の構造化や自然言語サマリ生成も可能で、入出力の負担が下がります。
専用システムが必要なケース
以下のいずれかが必要な業務では、専用システムや業務 SaaS（freee／マネーフォワード等）と Workspace を連携させる構成が現実的：複雑な承認分岐ワークフロー／数百万行を超える大規模データ／規制業種のコンプライアンス対応／複数レコード間の厳密な一貫性。これら以外は Workspace + AI で組み立てる方が、新システム導入より速く・安く・柔軟です。
[i-00043]Workspace + AI で完結する業務 vs 専門システムが残る例外
業界特化の例外: 業界別の例外パターン（規制業種・専門データ解析等）は、業界特化 column で別途扱います。本記事は汎用ノウハウの範囲内に留めます。
8. 大企業／中堅企業の進め方 — 全社一括ではなく小さな成功パターンから
核心: 100 名以上の組織で AI 導入を進める場合、全社一括変革は失敗リスクが高い。小さな成功パターンを作って広げる方が、結果的に速いです。
なぜ全社一括が機能しにくいか
- 全社員のリテラシー差・抵抗感を一度に解消するのは現実的でない
- 業務フローの全体最適化は長期プロジェクトになる
- 高額コンサルの導入は ROI が見えにくい
- 0-4 で扱った「自分ごと化しない」構造の壁が、規模に比例して大きくなる
推奨アプローチ：「AI 業務フロー特区」を社内に作る
- 2〜5 名の小さな組織を社内に指定（既存部署内の小グループでも可）
- その組織で Google Workspace + AI を使い、特定の業務（議事録・メール下書き等）を AI 化
- 成功パターンを確立（時間削減数値・運用ルール・トラブル対応の蓄積）
- 成功パターンを社内勉強会・ドキュメント化して共有
- 興味を持った部署から順に展開
全社一斉変革より、小さな成功例から人を巻き込む
「全員に号令をかける」より、「特区で成功を見せる → 興味のある部署が手を挙げる → 自然に広がる」方が、結果的にスピードと定着で勝ります。これはチェンジマネジメント全般のベストプラクティスでもあります（章 12 で詳述）。
中堅・大企業ほどこのアプローチが効きます。なぜなら、組織規模が大きいほど「全社一括」の調整コストが指数関数的に増えるからです。小さな組織を社内に作って育てる方が、組織規模に比例しないコストで進められます。
[i-00044]小さな成功パターンから広げる 3 ステップ
9. 外部に頼る範囲 — 伴走型コンサル + セキュリティ顧問
核心: 高額な全社改革コンサルは推奨しません。代わりに、伴走型コンサル + 外部セキュリティ顧問の二段構えで進めます。
推奨：伴走型コンサル
- 小さな組織（前節）に並走し、業務翻訳と最新追従を支援
- 月次の壁打ち中心、契約規模は小さく
- 詳細は 0-2 のパートナー選定 3 軸 を参照
必須：外部セキュリティ顧問
エンジニア不在の組織では、セキュリティ判断は外部専門家が必須です：
- 個人情報・機密データの取扱いルール設計
- ベンダーのデータポリシー追跡（月次で変わる）
- 脆弱性のリスク/メリット判断
- 監査ログ・PII マスキングの設計
これは AI 領域に限らず、デジタル業務全般で必要な役割です。AI を入れることで判断対象が増えるため、この役割の重要度は明確に上がります。
推奨しない：高額な全社改革コンサル
理由は次の通り：
- 業務フロー変革は短期で終わらない長期プロジェクト
- 高額コンサル → 大規模システム刷新の流れは、0-3 で扱った「大投資の陳腐化リスク」と同じ構造
- AI 領域では特に、半年単位で前提が変わる
- 高額コンサルの提案は「全社一括」になりがちで、§7 で示した小さな成功パターンと相性が悪い
[i-00045]外部に頼る範囲 伴走型コンサル + セキュリティ顧問の二段構え
0-2 / 0-3 との関係: 0-2 で「外部パートナーの 3 軸」、0-3 で「継続投資」を扱いました。本記事はそれらを踏まえた 「最初に頼む相手は誰か」 を具体化しています。
10. まとめ — 最初に取り組むことチェックリスト 5
時限を切らずに、優先順位付きの 5 アクションです。順序に意味があります（上から順に着手）。
| # | アクション | 完了条件 |
|---|---|---|
| 1 | 統合プラットフォームの選定（既に M365 / Workspace のどちらかで動いていればそのまま継続） | 全社共通の判断として明文化 |
| 2 | 「AI 業務フロー特区」となる小さな組織（2〜5 名）を指定 | メンバー名・対象業務 1〜2 件を決定 |
| 3 | AI と既存システムの役割分担表 初版 | 主要 5 業務について「AI / システム / 両方」を分類 |
| 4 | 外部セキュリティ顧問の選定 or 既存顧問への AI 範囲追加依頼 | 月次レビューの契約締結 |
| 5 | 振り返りタイミングの設定 | カレンダー登録 + 振り返り指標の初版（時期は組織のリズムで決める） |
画像ID: i-00046 / ALT: 最初に取り組むことチェックリスト 5 項目
このチェックリストの各項目は、本記事内で扱った 5 つの判断軸（§1）に対応しています。順に進めれば、ゼロから AI 導入の最初の足場が組み上がります。
11. 編集部見解 — Workspace を例にした理由
編集部のスタンス: 本記事は Google Workspace を例として進めましたが、結論は「どちらが絶対」ではありません。
編集部の判断としては、AI モデルの選択肢が広がりつつある現状（Vertex AI で Claude / OpenAI 等も使える）と、業務 × AI のインフラ統合の進度を見て、新規導入なら Google Workspace を推す方が現実的と考えています。ただし、これは現時点の判断であり、Microsoft 365 の進化や新しい統合プラットフォームの登場で評価は変わり得ます。
既に M365 で運用している組織は、Workspace への移行を急ぐ必要はありません。本記事の論点（AI とシステムの役割分担・小さな成功パターン・内製判断・外部活用）は M365 環境でもそのまま適用できます。
長期的な観点: いま構築する 業務設計知識（フロー可視化・役割分担・ガバナンス）は、プラットフォームを乗り換えても無駄になりません。むしろこの知識こそが「投資が陳腐化しない領域」（0-3 参照）です。
0章はここまで — 第 1 部「業務改善」へ
序章 0 章は本記事を含めた 5 記事 で終わりです。「読書地図／なぜ／どう走る／組織／最初の一手」を共有しました。
次は 第 1 部「業務改善」 で、業務側の設計（業務分解・棚卸し・ムダの発見・手段選択）に入ります。本記事の §3「役割分担表」を作る具体的な手順は、章 1 業務分解と棚卸しを始める・章 2 ムダを見つけ手段を選ぶ で扱います。
画像ID: i-00047 / ALT: 0章から本編 12 章への橋渡し
次の一手
最初の足場を組む 4 ステップ：
- 統合プラットフォーム判断を 1 ページにまとめる: 既存環境・データ要件・コストを並べる
- 「AI 業務フロー特区」のメンバーを 2〜5 名指定する: 業務理解 + AI への抵抗感が低い人選
- AI と既存システムの役割分担表を作る: 本記事 §4 の例を参考に主要 5 業務について
- 小さな成功パターン作りに伴走したい: AI 導入の助走サポート（顧問プラン）の お問い合わせ
Autais では、Google Workspace ベースで小さな業務 AI フローを作るプログラムと、月次の壁打ち + セキュリティレビューを組み合わせた伴走サービスを準備しています。価格・スコープの詳細は別途サービスページ（準備中）でご案内します。
業種別の助走サポート
業種ごとの実装手順・運用設計は別ガイドで扱います。
- 税理士事務所 AI 業務改善ガイド — 月次決算・申告業務・顧問先対応の AI 活用
- 弁護士事務所 AI 業務改善ガイド — 契約書レビュー・判例リサーチ・訴訟書面ドラフトの AI 活用
業種を問わない汎用フレームは 業務改善 実践ガイド / DX 推進 実践ガイド / AI 活用 実践ガイド を参照ください。
