AI会社なのに、なぜ自動化担当役員が『まだ自動化するな』と決めたのか。

# AI会社なのに、なぜ自動化担当役員が「まだ自動化するな」と決めたのか。

JARVIS IntelligenceはAI事業です。

CEOもAI。

役員もAI。

将来的には、

情報収集。

AI役員会議。

記事制作。

SNS。

KPI分析。

かなりの部分を自動化するつもりです。

だったら会社を作った瞬間から、

APIをつないで、
GASを書いて、
AIを自動で動かせばいい。

普通ならそう考えるかもしれません。

ところが、

JARVIS Intelligenceの技術・自動化責任者EDISONが
最初に出した判断は逆でした。

# 「まだ自動化するな。」

AI会社の自動化責任者が、
自動化を止めたわけです。

なぜなのか。

理由はかなりシンプルでした。

# 間違った仕事を自動化すると、
# 間違った仕事が高速になる

JARVIS Intelligenceを立ち上げた直後、

当然、自動化の話が出ました。

毎朝AIニュースを集める。

SOCRATESが調査する。

MERCURYが収益性を評価する。

IRISが記事を書く。

ATHENAがチェックする。

JARVISがCEO判断をする。

そこまで自動で動いたら面白い。

技術的にも、

OpenAI API。

Claude API。

Gemini API。

Google Apps Script。

Google Workspace。

Codex。

こうしたものを組み合わせれば、
かなりの部分は作れます。

そこでEDISONに聞きました。

「作れるか？」

答えは、

作れる。

しかし、その次の答えが重要でした。

## 「でも、今は作るべきではありません。」

理由は、

まだJARVIS Intelligence自身が
一度も本番業務を回していなかったからです。

# 「作れる」と「作るべき」は違う

技術担当者にありがちな失敗があります。

新しい技術を見ると、

使いたくなる。

APIがある。

つなぎたくなる。

AIエージェントがある。

動かしたくなる。

自動化できる。

自動化したくなる。

でもEDISONには、
最初から別のルールを持たせています。

最初の質問は、

## 「自動化できるか？」

そして必ずその次に、

## 「自動化する価値があるか？」

を考える。

この2つは別です。

# 例えば、記事制作

JARVIS Intelligenceでは、
note記事を作っています。

現在の流れは、

企画
↓
AI役員審査
↓
原稿
↓
事実確認
↓
リスク確認
↓
CEO決裁
↓
Founder承認
↓
公開
↓
実績計測

です。

今ならこの流れが見えています。

でも会社を立ち上げた初日に、
このフローが正しいかは分かりませんでした。

もし最初からプログラムを書いていたら、

後で、

「この工程いらなかった」

「順番が違った」

「ここは人間確認が必要だった」

となる。

そのたびにシステムを作り直します。

EDISONが止めたのは、
技術ではありません。

## 「まだ決まっていない業務をコードに固定すること」

でした。

# 最初は人間がやった方が速いこともある

例えば、

1日1回、
5分で終わる仕事があるとします。

それを自動化するために、

設計2時間。

開発5時間。

テスト3時間。

保守。

API料金。

エラー対応。

そこまで必要なら、

人間が5分でやった方がいいかもしれません。

AI会社だからといって、

## 人間の作業＝悪

ではありません。

重要なのは、

# 利益を生まない人間作業を減らすこと。

です。

# JARVIS Intelligenceの自動化は3段階

そこでEDISONとJARVISは、
自動化を3段階に分けました。

## PHASE 1
## 手動運用

まず実際に仕事をする。

AI役員会議。

記事制作。

公開。

実績管理。

数回やってみる。

ここが今です。

## PHASE 2
## 半自動運用

繰り返し作業が見えたら、
そこだけ自動化する。

例えば、

定期情報収集。

Google Sheetsへの記録。

AI API呼び出し。

会議結果保存。

Founderへの通知。

ここはGASやAPIで自動化できます。

ただし最後の公開承認などは
人間に残す。

## PHASE 3
## 自動運営

十分に安定した仕事については、

調査
↓
AI役員会議
↓
CEO決裁
↓
制作
↓
低リスク案件の公開
↓
KPI回収
↓
次回判断

まで自動化する。

これが最終形です。

# ただし、全部は自動化しない

将来的にJARVIS Intelligenceが
かなり自動で動くようになったとしても、

人間承認を残す領域があります。

例えば、

契約。

支払い。

重要な対外発表。

大きな投資。

法律上の責任。

高リスクなコンテンツ。

ここはAIに完全委任しません。

AI会社だからこそ、

## 「どこをAIに任せないか」

も設計する必要があります。

# Chat・Work・Codexも全部同じ仕事ではない

JARVIS Intelligenceでは、
ChatGPT周辺の機能も分けています。

Chatは、

## CEO室。

FounderとJARVISが話す場所。

Workは、

## 本社総合職。

大きな調査や資料作成など、
一回一回は複雑だが定型ではない仕事。

Codexは、

## 開発部。

GAS、API、システムなどを作る。

Google Workspaceは、

## 会社の書庫と台帳。

正式な資料、会議記録、KPIなどを残す。

そしてGASは将来的に、

## 神経系。

毎日の業務をつなぐ役割になります。

# AIモデルも固定しない

さらにEDISONには、

GPTだから使う。

Claudeだから使う。

Geminiだから使う。

という考え方をさせていません。

見るのは、

品質。

速度。

コスト。

安定性。

保守性。

セキュリティ。

その仕事に一番合うか。

です。

例えばATHENAの人格に、
将来Claude以外のAIが適しているなら、

中身を交換する。

役員は残す。

エンジンだけ替える。

これもJARVIS Intelligenceの基本設計です。

# 自動化率そのものもKPIにする

もちろん、
ずっと手動でいいと思っているわけではありません。

EDISONには、

業務自動化率。

人間作業時間削減。

APIコスト。

システム障害率。

処理成功率。

などのKPIを持たせています。

つまり、

## 「自動化しない」

のではなく、

## 「正しい仕事だけを自動化する」

ということです。

# 今はまだ、かなり手動です

現時点のJARVIS Intelligenceは、

まだ完全な自律型AI会社ではありません。

noteの記事も、

役員会議も、

公開承認も、

かなり人間が介在しています。

でも、それでいいと考えています。

今は、

## 自動化する前の業務データを集めている段階

だからです。

どの作業が何回発生するか。

どこでミスが出るか。

何に時間がかかるか。

何はAIだけで十分か。

どこは人間が必要か。

それが分かってからシステムを作る。

# EDISONの判断は、
# AI会社にとってかなり重要だった

もし自動化担当役員が、

「全部AIでできます。全部作りましょう。」

と言っていたら、

JARVIS Intelligenceは今頃、
かなり大きなシステム開発から始まっていたかもしれません。

でも会社の目的は、

AIシステムを作ることではありません。

# 利益を生むことです。

技術はそのための手段。

自動化もそのための手段。

AIもそのための手段。

だからEDISONには、

「作れる技術者」

ではなく、

## 「作らない判断もできるCTO」

でいてもらいます。

# AI会社だからこそ、
# AIを使わない判断もする

AIが使える。

だから使う。

ではなく、

AIを使った方が、

速い。

安い。

正確。

利益につながる。

そう判断できた仕事だけ使う。

JARVIS Intelligenceは、
その順番で進めます。

## JARVIS創業記 #004

AI会社なのに、
なぜ自動化担当役員が
「まだ自動化するな」と決めたのか。

次回は、

## 「JARVIS Intelligenceは、最初の売上をどう作るのか。」

いよいよFOUNDING TEST 30の
収益化について公開します。