こんな経験、ありませんか？
- Claude CodeやCodexを全社に入れて少し楽にはなったけど、ワークフロー自体は昔とあまり変わらない。
- Notion・JIRA・SlackでいろんなAIを使っているのに、AIの効果をいまいち実感できない。
- 世の中の「AI Native」が何なのか、だんだん分からなくなってきた。
私も、ある会社のチームをAI Native化していたとき、まったく同じことを感じていました。
でも今年の6月ごろ、AI Nativeが進むべき方向に確信が持てて、今は「未来はこれしかない」と本気で思っています。
この記事は、そのときの経験のシェアです。
0. 注意点
先に断っておくと、これは「SaaS is Dead」みたいな話ではありません。
最近話題の photocraft のように、既存のSaaSをリバースエンジニアリングしてコピーし、タダで使おうという話でもないです。
言いたいのは、こういうことです。
AI時代のツールは「働く人」ごとに個人化され、「チームのProtocol」で通信する。 このアーキテクチャが新しい時代のツールになり、ワークフローに革命を起こせる。
1. 世の中の「AI Native」は、なぜ効かなかったのか
最初は私も、よく言われる「AI Nativeな会社のつくり方」をひととおり試しました。
| よく聞く AI Native | 中身 |
|---|---|
| AIツールの積極導入 | Claude Code・Codexなどをみんなで使う |
| AIサービスによる自動化 | 複数のAIサービスをつないで、業務を自動で流す |
| MCPで自動化 | Slackに通知が来たらAIが何か動く、など |
結果は、たぶんみなさんと同じです。
- 経費だけが上がった。 AIサービスを足すたびに、サブスク代が積み上がる。
- 工数はあまり減らなかった。 AIが速くなっても、仕事全体のスピードは変わらない。
- クオリティも、思ったほど上がらなかった。
要するに、よくあるやり方ではダメだったんです。
2. 問題は「既存のツール」
最近「AI時代は人間がボトルネックだ」という話をよく聞きます。
でも、ボトルネックは「人間」ではありません。人間が使っている既存の「汎用ツール」です。
今のLLMの限界を肌で感じた人なら分かると思いますが、理想は 「人間」を「AI」に置き換えることではなく、「人間」が「AI魔法」を使えるようになること です。
ところが、その魔法を邪魔しているものがあります。
- 動画編集なら Premiere Pro
- Slack、Notion、Excel、TeamSpirit
- 実は Claude Code や Codex のようなAIコーディングツールも（これは今のところ仕方ないですが）
- Chrome
- もっと言えば Windows も
どれも「誰でも使える」ように作られた汎用ツール。裏を返せば、どの個人にも、どのプロジェクトにも最適化されていない ということです。
たとえば「モバイル向けクリッカーゲームの開発チーム」と「ゲームフレンドのマッチングアプリの開発チーム」では、必要なツールの形がそもそも違いますよね。
人間 ──▶ [ 汎用ツールという“決まった型” ] ──▶ 型どおりの仕事しか出てこない
AI ──▶ [ 中身の見えない Blackbox ] ──▶ 公開された範囲の中でしか動けない
つまり、自作じゃないツール ＝ AIがコントロールできないBlackboxを抱えた既存SaaSは、全部AI Nativeの邪魔になっている。これが私の問題意識です。
3. 2つの原則 ― ツールは作る、データはAIに渡す
そこで私が担当したAI Nativeチームでは、原則を2つ決めました。
3-1. ツールは全部、AIがコントロールしやすい自作ツールに
核心：既製のSaaSを「契約して使う」のをやめて、「作って使う」に切り替える。
できる限り、ツールは全部自作に置き換えました。
| これまで | いま |
|---|---|
| Slack | 自作チャット |
| Notion | 自作ドキュメント |
| JIRA | 自作ボード |
| Google Calendar | 自作カレンダー |
| Premiere Pro | 自作の動画編集ツール |
| Chrome | AIエージェントと社内プロジェクトに特化した自作ブラウザ |
| …ほか多数 | ほとんど自作 |
3-2. 全ツールのデータを、AIが参照・管理できるようにする
核心：自作だからこそ、全データを1か所に集めてAIに渡せる。
ツールが自作なら、溜まるデータも全部自分たちのもの。
全ツールのデータが1か所に集まって、AIがまるごと参照・管理できます。
既製SaaSの場合：
Slack のデータ → Slack社のサーバー
Notion のデータ → Notion社のサーバー
JIRA のデータ → Atlassian社のサーバー
→ AIはそれぞれのAPIの範囲でしか覗けない
自作ツールの場合：
チャット / ドキュメント / ボード / カレンダー
→ すべて1つのデータ基盤に集約
→ AIがロジックもデータも丸ごと把握できる
たとえば、AIのほうから「メッセンジャーではこう言ってましたけど、大丈夫ですか？」と確認してくれる機能。これはメッセンジャー・ボード・編集ツールの データが1か所にあって初めて できることです。別々の会社のMCPを3つ挿しても、grep一発では済みません。
4. ツールの新しい形、アボカドツール
「ツールを全部自作」と聞くと、「みんながバラバラに作ったら収拾がつかなくない？」と思いますよね。なので私たちは、自作ツールを アボカドみたいな構造 で設計しています。
╭─────────────────────────────╮
│ やわらかい部分（果肉） │ ← 社員が AI と一緒に自由に改良する
│ │
│ ╭───────────────╮ │
│ │ 種 = Core │ │ ← ほぼ変えない。変えるならエンジニアと相談
│ ╰───────────────╯ │
│ │
╰─────────────────────────────╯
構造はシンプルで、種 と やわらかい部分 の2つだけ。
みんなで共有するのは「Protocol」と「Base」で、そのBaseとProtocolさえ満たしていれば、それぞれ別々の個人化ツールとして成り立ちます。
4-1. 種
種はツールの「コア」、全体を支える土台です。
エンジニア向けに言うと、「Server」＋「クライアントの基本ベース」 です。
- 基本的には変えない 前提で作る。
- どうしても変えたいときは、エンジニアと相談。
- Coreのアップデートでコンフリクトが出たら、個人の側がCoreに合わせて直す。
4-2. やわらかい部分
核心：ここをいじって、自分にいちばん合うツールに変えていく。
本当に大事なのは、こっちです。
社員は「Core＋やわらかい部分のベース」を受け取って、やわらかい部分を自分にいちばん合う形に改良 していきます。画面のレイアウトも、機能も、ワークフローも、ここで自由に変えてOKです。
4-3. 結果 ― 誰よりも「使う人」に個人化された道具になる
こうしてツールは、それを使う本人に、誰よりも最適化 されていきます。
| 汎用ツール | アボカドツール | |
|---|---|---|
| 誰向けに作られているか | 「みんな」 | 「使う本人」 |
| 機能が足りないとき | ベンダーのロードマップを待つ | 自分で足す |
| AIから見た中身 | Blackbox | ロジックもデータも全部見える |
| 時間がたつと | 変わらない | どんどん本人に馴染んでいく |
種がしっかりしているから、果肉がどれだけ柔らかくても形は崩れない。だから「アボカドツール」なんです。
5. なぜ「MCPやComputer Useで十分」ではないのか
ここまで読んで、こう思った人もいるはずです。
「対話でツールを操作させたいなら、Computer UseかMCPで十分じゃない？」
実際、私たちも最初はそうしていました。でも、どちらも結局は限界にぶつかります。
Computer Use：
画面を見る → マウスを動かす → ボタンを押す → スクショ → 推論 → …
→ 人間向けの UI を AI が真似しているだけ（＝効率の問題）
MCP + 既存 SaaS：
AI → MCP → 相手の会社が公開している API の範囲
→ 足りないフィールドは作れない／データは相手の製品の中（＝所有権の問題）
自作ツール（アボカドツール）：
AI → 関数呼び出し1回、データ1行の修正
→ ロジックもデータも、全部自分たちのもの
Computer Use は、AIからするとほぼ「サーカス」です。作業1つにスクショが数十枚、クリックのたびに推論。手でつまめばいいものを、わざわざ箸を渡して「これでつまんで」と言っているようなものです。頑張れば箸でもつまめますが、手のほうが簡単。モデルがどれだけ良くなっても、この構造的な非効率は消えません。
MCP はずっとマシな方法で、実は私たちのツールも内部ではMCPの形でAIにつながっています。問題はMCPそのものではなく、その先にあるツールが誰のものか です。チームに必要なフィールドが1つ足りなくても、作れない。「この機能、今すぐ欲しい」と言われても、相手の会社のロードマップ待ち。しかも溜まったデータは、自分たちのサーバーではなく相手の製品の中にあります。
つまり、大事なのは「どうつなぐか」ではなく、「つなぐ先が誰のものか」 なんです。
6. デメリット ― 2つの壁
もちろん、いいことばかりではありません。壁は大きく2つあります。
6-1. AIそのもの
核心：依存先がない ＝ 言い訳できる先もない。
AIが賢くなるほど、既存のハーネスを越えて何か問題を起こす可能性 も出てきます。
1. 枠の中 ：AI はハーネスの内側で動いている
2. 枠を越える ：AI が賢くなり、想定していた枠をはみ出す
3. 枠を作り直す：エンジニアがハーネスを組み直し、監視する
しかも自作ツールなら、責任は 全部自社。「Slack社のセキュリティの問題で……」という言い訳は通用しません。依存先がないので。
だからエンジニアは、このリスクをちゃんと分かった上で、次の2つをやる必要があります。
- AIを監視するシステムやハーネスを作る
- 新しいモデルが出たら、慎重にテストしてから入れる
6-2. マインド
核心：「ツールはもらって使うもの」という認識を変える。
2つ目は、社員のマインドを変えないといけないことです。
| 職種 | これまで | これから |
|---|---|---|
| 企画・デザイン | もらって使う | 自分で作る |
| エンジニア | 機能を作る | 守る・見張る |
プランナーやデザイナーも、必要なものは自分で作って使う意識に変わる必要があります。一方エンジニアは、ベースの安全性・ハーネスの改善・AIの監視 へと役割がシフトします。
これはツールに限った話ではありません。お客様向けのプロダクトでも、プランナーやデザイナーがどんどん開発に入ってくるようになります。そうなると、バージョンが上がるたびにセキュリティやアーキテクチャを管理するのも、エンジニアの役割 になっていきます。
7. よくある質問
この話をすると、だいたいこんな質問が来ます。
Q1. 作れる人がいません。開発リソースが足りないんですが？
まさにその前提が、今回崩れたんです。ツールを作るのがエンジニアである必要はなくなった ― これがこの変化の核心です。業務をいちばんよく知っている実務者が自分で作ったほうが、むしろ正確なツールになります。開発チームの役割は「全部作る」から「作れる土台を用意する」に移るべきだと思っています。
Q2. 自作ツールって、汎用ツールより品質が落ちませんか？
見る角度次第です。汎用性は確かに落ちます。でも大した問題ではありません。結局ツールを使うのは個人で、時間がたつほど、その人にとって完璧に近いツールになっていくからです。
Q3. どうせ外部のAI APIにデータを送るなら、同じでは？
違いは 「通り過ぎるか、溜まるか」 です。推論1回でデータが通り過ぎるのと、自分たちの活動履歴が相手の製品の中に構造化されて溜まっていくのとでは、まったく別の話。しかも自作なら、モデルを差し替えることも、機密な部分だけローカルに切り出すこともできます。汎用ツールの中では、そもそもその選択肢がありません。
Q4. 作ったのに使わなかったら、ムダになりませんか？
それこそ「ツール＝買う資産」だった時代の発想です。半日かけて作ったものを捨てるのはムダじゃありません。合わないツールを3年間サブスクし続けるほうが、よっぽどムダです。それに、ツールを捨てても、その間に溜まったデータは残ります。