前回のVol.2 「AIに頼めばいい」は、なぜ効率化にならないのか では、AIに都度頼んでいるだけでは、仕事はそこまで減らないという話をしました。業務が軽くなるのは、仕事を固定フローに落とせたときです。

では、その固定フローは何で支えるのか。

ここで次にぶつかるのが、ツール選びです。

DXや自動化の話になると、つい「どのAIツールがいいか」「どの自動化サービスが便利か」という見方になりがちです。ですが、実際に会社の業務を回すうえで重要なのは、単体で便利なツールを選ぶことではありません。それぞれの役割に合ったツールを、つながる形で置けるかどうかです。

同じ数のツールを使っていても、速い会社と遅い会社があります。違いは数ではなく、役割分担と接続の設計にあります。

自動化は「万能ツール探し」ではなく、役割分担で考える

まず前提として、会社の業務は1つのツールで全部きれいに解決しません。

請求書を受け取る。内容を読む。保存する。会計処理につなぐ。必要な人に知らせる。あとで検索する。こうした流れは、実際には複数の役割に分かれています。

にもかかわらず、ここを1つのツールで全部やろうとすると、どこかで無理が出ます。逆にツールを場当たり的に増やすと、今度は情報が分断されて人が橋渡しをすることになる。

だから、自動化に向く会社は最初に役割を分けて考えます。Fluxxでも、ざっくり次のようなドメインで見ています。

• 受け取り・通知 — 依頼や情報が入ってくる場所、関係者へ伝える場所
• 保存 — ファイルや証憑を残す場所
• 構造化データ — 後から検索、集計、活用できる形で情報を持つ場所
• 会計 — 請求、入金、支払などお金の流れを扱う場所
• AI処理・実行 — 曖昧な作業を分解したり、決まった処理を横断して実行する場所

見るべきは「どれが一番高機能か」ではなく、「この役割に対して何が向いているか」です。

ツール選びで見るべきは、機能ではなく3つの基準

Fluxxがツールを選ぶとき、細かな機能差より重視している基準は次の3つです。

1. 他のツールとつながるか。
APIや外部連携の窓口があるか。人がコピペしなくても、次の工程へ情報を渡せるか。ここが弱いツールは、後から必ず詰まります。

2. 情報が整理された形で残るか。
出力はできても、後から検索できない、一覧で見られない、再利用できないなら弱い。自動化は1回ラクになることではなく、あとから何度も使える状態を作ることです。

3. 後から広げられるか。
今の業務だけ便利でも、別のフローに広げられないなら将来また組み直しになります。最初から拡張しやすいほうが、長期的には安いです。

この3つを満たさないツールは、短期的には便利でも、会社全体では速度を落としやすいと考えています。

ドメインごとに、見るべきポイントは違う

ここで重要なのは、ツールの良し悪しはドメインによって変わるということです。同じ「便利そう」でも、受け取りに向くツールと、構造化データに向くツールは違います。

受け取り・通知のツールで見るべきこと
個人に閉じないか。チームで同じ情報を見られるか。通知先として集約できるか。あとから自動投稿や自動通知を載せやすいか。
この役割では、単なる連絡手段より、共有の窓口になれるかが大事です。

保存のツールで見るべきこと
置けるかどうかではなく、探せるか、ルールを揃えやすいか、権限管理しやすいか。証憑やファイルは、あとで見つからないと価値が落ちます。
この役割では、保存容量より運用の揃えやすさが重要です。

構造化データのツールで見るべきこと
人が読むだけでなく、一覧、検索、絞り込み、関係付けができるか。つまり、情報がデータベースとして持てるか。
文章を書くのに向くツールと、あとで再利用するためのツールは別です。

会計ツールで見るべきこと
記帳だけでなく、請求、入金、支払までつながるか。外からデータを渡せるか。逆に、会計画面の中だけで完結する作りだと、自動化の起点になりにくい。
この役割では、会計知識より業務フローの入口になれるかが重要です。

AI処理・実行のツールで見るべきこと
単に会話がうまいかではなく、他のツールやファイルをまたいで処理できるか。曖昧な依頼を分解したあと、そのまま業務フローへ接続できるか。
この役割では、チャットの快適さより横断力が重要です。

Fluxxが実際に選んでいる組み合わせ

ここまでの基準で、Fluxxでは次のように役割を分けています。

• Slack — 受け取りと通知のハブ。依頼、共有、例外連絡、自動通知の集約先
• Google Drive — 証憑やファイルの保存先。あとから探せて、チームで同じルールに乗せやすい場所
• Notion — タスク、顧客、ナレッジ、議事録などの構造化データを持つ場所
• freee — 請求、入金、支払を扱う会計基盤
• Claude Code — 曖昧な業務の分解と、複数ツールをまたぐ処理の実行役

ここで大事なのは、どれか1つが最強という話ではないことです。もっと言うと、1つの情報を複数の場所で“それっぽく管理できてしまう”状態がいちばん危ないということです。

たとえば、顧客情報を営業はスプレッドシートで持ち、制作はNotionで持ち、請求先情報はfreeeにあり、やり取りの履歴はSlackやメールに散っている。しかも各部署がそれぞれを「うちのマスター」と呼んでいる。この状態はかなりよくあります。

でも実際には、マスターが複数ある時点でマスターではありません。会社名の表記揺れ、担当者名の更新漏れ、請求先情報の差分、タグやステータスのズレが起きるたびに、人が確認して埋めるしかなくなります。自動化が止まるだけでなく、判断も遅くなる。

Slackは会計の正本にはなりませんし、freeeはナレッジの中心にはなりません。Notionは証憑保管の本丸ではありませんし、Driveは構造化データの起点にはなりにくい。つまり、各ドメインで向いている仕事が違う。だからこそ、役割を混ぜず、「どこが正なのか」を最初に決めるほうが全体は速くなります。

なぜFluxxはその組み合わせにしているのか

たとえば受け取りと通知をメール中心にすると、依頼や情報が個人に閉じやすくなります。誰に来たかで始まりが決まり、あとから追いづらい。自動通知を増やしても、集約先が散っていると見落としやすい。

その点、Slackはチームの窓口として使いやすく、通知ハブにもなります。だから「受け取る」「知らせる」の役割には合っています。

また、ファイル保管と情報管理を同じツールで済ませたくなりますが、ここも分けたほうが運用しやすいことが多いです。Driveはファイルを置き、共有し、検索する場所として強い。一方で、あとから一覧化したり関係付けたりしたい情報はNotionのほうが扱いやすい。

会計も同じです。請求や入金を扱う基盤は、最初からその用途に強いツールを置いたほうが速い。Fluxxではfreeeを使っていますが、見ているのは「会計ソフトとして有名か」より、請求や入金の流れを業務フローにつなげやすいかです。

AI処理についても、単なるブラウザ上のチャットだけだと、会話はできても業務に接続しにくい。FluxxでClaude Codeを中心にしているのは、曖昧な依頼を分解するだけでなく、ファイルやデータ、ほかのツールにまたがる処理までつなげやすいからです。

逆に、どんな組み方だと会社は遅くなるのか

ここまでの裏返しとして、次のような構成はかなり詰まりやすいです。

1. 受け取りが個人に閉じている。
依頼や情報が個人メール、個人DMに散ると、そこがボトルネックになります。

2. 保存先と管理先が曖昧。
ファイルはあちこち、正しい一覧は別、最新情報は人に聞く。この状態はかなり遅いです。

3. 構造化されていない。
文章では残っていても、あとで検索、集計、再利用できないなら、自動化は広がりません。

4. AIが会話で止まっている。
その場の相談相手にはなっていても、業務フローにつながっていないなら、会社全体はあまり変わりません。

5. 同じ情報に、複数の“正”がある。
これが一番厄介です。部署ごとに顧客マスター、案件マスター、請求先マスターのような似たデータを持ち始めると、更新のたびに差分が発生します。しかも当事者はそれぞれ「自分たちの表が正しい」と思っているので、ズレに気づくのは問題が起きた後です。

この状態になると、ツールが増えたこと自体より、照合作業が増えることが痛い。営業はAを見て、制作はBを見て、経理はCを見る。会議のたびに「どれが最新ですか？」が発生するなら、その会社はすでに遅くなっています。

まとめ：良いツールより、良い組み合わせを選ぶ

ツールを増やすほど速くなる会社もあれば、遅くなる会社もあります。その違いは、良いツールを引いたかどうかではありません。役割を分けて、つながる形で置けているかです。

自動化の前提になるのは、固定フローです。そして固定フローを支えるのは、受け取り、保存、構造化データ、会計、AI処理という各ドメインに合ったツールの組み合わせです。

Fluxxでも、単体の便利さより、あとから業務フローに乗せやすいかを優先して選んでいます。だからこそ、後から請求書処理にも、情報管理にも、営業にも広げやすい。

続けて読むなら、次は Vol.4 月初に仕事が止まる会社、止まらない会社 です。この組み合わせの上で、実際に月初業務をどう止めなくしているかを具体的に見ていきます。