1人で100人分の仕事をする。そう考えてきたのに、どこか腑に落ちないままだった。
今朝、その答えが出た。
Before：私がずっとやっていた「間違い」
「AIを使えば生産性が上がる」は正しい。でも私がやっていたのは、実態としてはこうだった。
- 記事を書くとき → Claudeに指示を出す
- 画像を作るとき → ChatGPTにプロンプトを投げる
- ブログを投稿するとき → スクリプトを手動で動かす
全部、私が指示を出すことで動いていた。
これでは「AI＋私」が1人で動いているに過ぎない。100人分どころか、私が手を動かせる時間の分しか仕事は進まない。
転機：画像生成の自動化を考えていて気づいたこと
きっかけは小さな疑問だった。
補聴器店のクライアント向けブログを定期更新しているのだが、今は「画像生成用のプロンプト」を書き出して、それを手動でChatGPTに貼り付けている。
「これ、スキルが直接APIを叩けばいいのでは？」
そう考えた瞬間に気づいた。LocalLLMをバックグラウンドでフル活用することが、AIソロプレナーの実装形態だ、と。
画像生成だけではない。私のWindows機ではすでにローカルLLMが常時稼働している。テキスト生成も、RAG検索も、¥0で動いている。
あとは「スキルを自律的に動かす設計」があれば、私が寝ていても仕事が進む。
「接続されたものすべてをスケールさせる」
同じ朝、Anthropic CEOダリオ・アモディのインタビュー記事を読んだ。
AIは一つの技術がスケールするのではありません。AIに接続されたものすべてをスケールさせるのです。
この言葉が、気づきをさらに深めた。
記事では「AIの社会的インパクト」を掛け算で表現していた。
インパクト ＝ 能力 × 普及率 × 複製数 × 自律度 × 投下資本
これを自分の環境に当てはめるとこうなる。
私のスケール ＝ LocalLLM能力 × スキル数 × 並列実行数 × 自律完結度 × ¥0
コストが¥0に近いほど、「自律度を上げること」だけに集中できる。
これが私の環境の構造的な強みだと、初めて明確に見えた。
After：オーケストレーションの再定義
「オーケストレーション」という言葉は知っていた。複数の処理を順序通りに自動連結する仕組み、だと。
でも今朝の気づきで、意味が変わった。
オーケストレーションとは、スキルが自律的に最後まで完結して動き、結果を指定された場所に残し続けるループのことだ。
ブログ更新を例にとると：
- スケジュールが来る
- スキルが記事テーマを判断する
- LocalLLMが下書きを生成する
- LocalLLMが画像プロンプトを生成し、画像生成モデルが動く
- ブログに下書き投稿される
- 結果がSupabaseに記録される
私は承認するだけ。あるいは完全自動にする選択肢もある。
これが「1人で100人分」の正体だった。私が指示を出すのではなく、スキルが眠っている間も動き続ける設計を作ることが仕事だった。
「依存させない、自走させる」を自分自身に
私はクライアントに対して「依存させない、自走させる」をテーマに伴走している。
でも今朝気づいたのは、それを自分自身の環境にまだ適用できていなかったということだ。
スキルがあっても、私が呼ばないと動かない。それは「依存」だ。自分がAIに依存している状態。
本当の自走は、スキルがスケジュールとトリガーに従って自律的に動き、私は結果だけを確認する構造。
外販よりも先に、自分の環境でそれを完成させる。
それが今朝の結論だった。
「会社のOS」の観点から
私がクライアントに作っている「会社のOS」は、業務の流れをスキルとスケジュールで自動化し、人は判断と承認だけをする設計だ。
その設計を、自分のビジネスにまず適用する。
LocalLLMが常時稼働しているWindows機と、Claudeのスキル群と、Gatewayが揃っている。
部品はすでに全部ある。あとは「つなぎ方の設計」だけだ。
こういう人はどの規模の会社にも1人はいる。
「ツールは入っているのに、結局自分が動かさないと何も進まない」という経営者。
AIが自律的に動く設計を最初から作るか、後から入れ直すか。その差が、3年後の生産性の差になると思っている。
伊藤晴通 / humac
AI活用顧問・「依存させない、自走させる」伴走型コンサルタント
