上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。
問いから始めます。人工知能(AI)による開発を、私はなぜ恐れたのでしょうか。
答えははっきりしています。AIは開発ができて、そのうえ休まないからです。
AIには労働基準法がありません
人は休みます。労働基準法があります。夜は眠ります。週末も要ります。連続で働けば体をこわします。だから、人が一日に進める仕事には上限があります。この上限を、私たちは長いあいだ当たり前と思ってきました。
でもAIには労働基準法がありません。夜も動きます。週末も動きます。指示を一度出せば、朝まで手を止めません。疲れたと言いません。休憩を挟みません。同じ品質のまま、何時間でも作業を続けます。
この差は、便利という言葉では収まりませんでした。私が感じたのは恐怖です。便利な道具が一つ増えた、という話ではありません。仕事の速さの土台が、根っこから変わる、という話でした。
Claude Codeが世に出たのは、いまからおよそ1年半前です。そのときに私は理解しました。24時間回した会社が先行者利益(first advantage)を取ります。そして、資金で殴れる会社が勝ちます。これは意地悪な見立てではありません。ごく当たり前の帰結です。
先に出した者が有利になる、という話は、いまに始まったものではありません。市場に早く入った者が場所を押さえます。標準を握ります。後から来た者は、その差を追いかけ続けます。AIは、この先行の差を一日単位で広げます。夜に十時間先へ進んだ会社と、夜に止まっていた会社は、翌朝には十時間ぶん離れています。差は毎日積み上がります。
人を増やせば追いつけるのでしょうか。追いつけません。人の採用には時間がかかります。募集を出し、面接をし、教えて、慣れてもらう。ここまでに何か月もかかります。そのあいだにも、相手のAIは夜通し進みます。人を増やす速さでは、AIを増やす速さに追いつけません。だから、人の数で殴り合う土俵に乗った時点で、中小企業は負けます。乗ってはいけない土俵でした。
金で殴れる会社が勝つのは、当たり前でした
なぜ資金の勝負になると言い切れるのでしょうか。増やし方に上限がないからです。
実装を担うAIは、あとからいくらでも増やせます。外部サービスを呼び出す接続鍵、いわゆるAPIのキーを一本足すだけで、働き手が一人また一人と増えていきます。人の採用のような時間はかかりません。求人を出す必要も、面接も、研修もありません。キーを足せば、その日から夜通し働きます。資金がある会社は、この働き手を好きなだけ並べられます。
もう一つの当たり前もあります。計算資源を余らせている会社が強い、という当たり前です。ビットコインの採掘(マイニング)のために画像処理装置(GPU)を大量にそろえた会社があります。相場が下がれば、その装置は余ります。余った装置はAIの計算に回せます。持っている側は、持っていない側より安く、長く、AIを動かせます。買い足す必要がないからです。
ここまでを並べると、絵はきれいにそろいます。資金でAIの数を増やせる会社。余った計算資源でAIを安く回せる会社。この二つを持つ会社が、夜通し開発を進めます。そして先行の差を毎日広げます。私はこの絵を、恐ろしいと思いました。中小企業の側に立っていたからです。
中小企業に残された資源は、余った契約の枠だけでした
ここで多くの人は肩を落とします。資金の勝負なら、中小企業に勝ち目はない、と。
でも私はそこで止まりませんでした。問い直したからです。中小企業が使い切れていない資源は、本当に何もないのでしょうか。
ありました。契約(サブスクリプション)の枠です。
月ぎめの契約には、使える枠がついています。多くの会社は、その枠を昼の数時間しか使いません。夜は誰も触りません。週末も止まっています。枠は毎月あるのに、大半を捨てているのです。これは資金がないという問題ではありません。持っているものを使っていない、という問題です。
工場には稼働率という言葉があります。同じ設備でも、動かした時間が長いほど、一台あたりの元が取れます。半分しか動かさない工場と、めいっぱい動かす工場では、同じ投資でも成果が変わります。契約の枠も同じです。すでに支払いは終わっています。使っても使わなくても、費用は変わりません。それなら、使わない手はありません。使わない枠は、稼働率の低い設備と同じです。もったいない、では済みません。競争で負ける理由になります。
ここに気づいたとき、最重要課題が決まりました。余った枠を使い切ることです。言い換えると、契約を24時間動かし続けることです。これをやらなければ、世の中から遅れます。AI化の波に溺れます。この波に溺れないために作り始めたのが、最初のきっかけでした。
歴史も同じことを教えています。産業革命のさなか、綿工場は昼しか動けませんでした。夜は暗くて糸が見えないからです。ところがガス灯が入り、やがて電灯が入りました。工場は夜も動けるようになりました。すると、夜も回した工場が昼だけの工場を追い抜きました。設備は同じです。人の数も似たようなものです。違いは、動かした時間の長さだけでした。持っている設備を、何時間動かすか。勝負を分けたのは、そこでした。
経済学にはジェボンズの逆説という有名な観察があります。1865年、ウィリアム・スタンレー・ジェボンズは、石炭を使う効率が上がるほど石炭の消費はかえって増える、と指摘しました。効率が上がって安くなると、人はもっと使うからです。AIも同じです。安く便利になったAIは、減らす対象ではありません。もっと使うべき対象です。だから、枠を残す理由はどこにもありません。残った枠は、使わなければただ消えます。翌月には戻ってきません。使い切らない枠は、捨てた枠と同じです。
判断はローカルに、実装はクラウドに回します
とはいえ、24時間ただ回せばよいわけではありません。夜通し動かすなら、間違いも夜通し積み上がります。人が見ていない時間に、見当違いの実装が進むこともあります。ここを塞がないと、朝に後悔だけが残ります。
矛盾は放置しない。仕組みで塞ぐ。これが私の一番の決めごとです。気合いで乗り切る、という言葉を私は信じません。仕組みで塞げないなら、その仕組みは未完成です。
そこで作ったのが、手元のローカルの大規模言語モデル(LLM)を判断役に据えたAI開発オーケストレーターです。名前はlocal-commanderです。役割は司令ではなく、仕分けです。何をどこで処理するか。それを最初に決めます。
投げられたタスクを、この仕組みはまず三つに仕分けます。
- ローカルで済むもの
- クラウドが要るもの
- 承認が必須のもの
仕分けの判断は、手元のLLMがやります。ここが肝です。判断のたびに外部へ問い合わせると、枠も費用も削れます。手元で決められることは手元で決める。そのほうが速く、安く、静かです。判断役を手元に置いたのには、もう一つ理由があります。判断は回数が多いからです。回数の多い処理を外に出すと、そこが一番の重荷になります。だから、いちばん多く走る判断を、いちばん安い場所に置きました。
判断のあとは流すだけです。実装が要るものは、CodexやClaude Codeへ渡します。人の目が要らない工程は、そのまま先へ進めます。変更の取り込み(マージ)、プルリクエスト(pull request)の作成、レビュー、そして取り込み後のタスク反映まで、一続きで自動化してあります。人は、承認が必須のものにだけ手を出します。それ以外は、仕組みが最後まで運びます。
夜に働かせ、朝には承認だけを積みます
一日の流れはこうなります。
夜、私は指示を残して離れます。仕組みは自律で回ります。ローカルで済むものはローカルで片づきます。クラウドが要るものはCodexやClaude Codeが実装し、変更の送信(push)、プルリクエスト、レビュー、取り込みまで進めます。承認が必須のものだけは、その手前で止まります。止めたまま、朝を待ちます。勝手に進めません。ここで勝手に進めると、朝に取り返しのつかないものが残るからです。
朝、私の前に積まれているのは、承認が必須の一点だけです。夜のあいだに終わった作業ではありません。人でなければ決められない、その一点です。私はそこだけを見て、可否を返します。
これで枠は夜も動きます。そして、朝の私の仕事は判断だけになります。作業は返ってきません。時間が返ってきます。私が効率化に求めているのは、まさにこれです。速さそのものではありません。返ってくる時間です。返ってきた時間で、私は次に何を作るかを考えます。人にしかできないのは、そこだからです。
思い出してください。私は最初、AIが休まないことを恐れていました。でもいまは、休まないAIに夜を任せています。恐れの対象を、そのまま働き手に変えたのです。休まないという性質は、変わっていません。変えたのは、その性質をどう使うか、という一点でした。
勘で買わない。DGX Sparkは16ケースの実測で決めました
24時間動かすと決めると、次の問いが来ます。手元の計算資源は足りるのか、という問いです。判断役のLLMを手元で夜通し動かすには、相応の装置が要ります。ここで私が候補にしたのが、DGX Sparkでした。
でも、ここでも私は勘で買いませんでした。よさそうだから買う、という買い方をしません。買っていいと自分に言うには、証拠が要るからです。特に、一度きりで戻せない買い物ほど、証拠を厚くします。
そこで16のケースを組み、実測しました。数字を並べ、判断の根拠を数字に置きました。感想では買いません。実測で買います。
なぜここまでやるのでしょうか。判断の質を、勘の水準に落とさないためです。私は、人間の仕事は判断にあると考えています。作業はAIに渡せます。でも、何を作るか、何を買うか、どこで人が止まるか。この判断だけは人に残ります。判断が勘に流れれば、24時間の仕組みごと崩れます。土台が勘なら、その上に積んだ自動化も勘の産物になるからです。だから購入という一度きりの判断こそ、数字で固めます。
矛盾は、放置せず仕組みで塞ぎます
ここで、よく返ってくる問いに先に答えておきます。
「夜通しAIに任せて、品質は保てるのか」。この問いには、仕分けで答えます。人の目が要る工程は、承認が必須のものへ回します。任せているのは、人の目が要らない工程だけです。全部を任せているわけではありません。
「間違ったまま朝まで進んだら、事故になるのではないか」。この問いには、停止点で答えます。承認が必須のものは、実装の手前で止まります。戻せない一歩の前で、必ず人を待ちます。夜に進むのは、戻せる範囲だけです。
「手元のLLMで、判断の質は足りるのか」。この問いには、役割分担で答えます。手元のLLMがやるのは、仕分けという軽い判断です。重い実装はCodexやClaude Codeが担います。難しい承認は人が担います。手元には、手元でこなせる判断だけを置いています。背伸びをさせていません。だから、質が足りないという事態が起きません。
「24時間動かせば、費用がかさむのではないか」。この問いには、順番で答えます。まず使い切るのは、すでに支払った契約の枠です。枠の中で動くかぎり、追加の費用は出ません。枠を超える前に、手元とクラウドの仕分けが効きます。安く済むものは手元で片づくからです。費用が増えてから節約を考えるのではありません。増えない設計を先に置いています。
どの答えも同じ形です。困りごとを気合いで越えていません。仕組みで塞いでいます。矛盾を見つけたら放置しない。これが、この記事でいちばん伝えたいことです。
この考え方の実際の中身は、関連記事「AI開発の半分をローカルLLMへ。役割で振り分けた話」に書いてあります。役割で振り分けるとは何か。どこまでをローカルに任せるのか。その具体は、そちらを読んでいただければと思います。
最後に一つだけ。24時間動かす仕組みは、大企業だけのものではありません。むしろ、枠を捨てている中小企業こそ、いちばん伸びしろがあります。資金では殴れません。でも、余らせている枠は使い切れます。溺れる側にいる必要は、もうありません。
この local-commanderについての記事は、どう実装したか・どんな機能があるかを、順次シリーズとして公開していきます。
興味のある方は、ぜひ「いいね」と記事の購読をお願いいたします。
また、このシステムを DGX サーバーに載せて、社内に置いて動かせる形でのご提供（販売のご相談）もしています。
ご希望の方は、弊社の Web ページ https://www.eln.ne.jp からお問い合わせください。
筆者について
上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。
また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。
EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。
→ EarthLink Network が自社でつくっている18のプロダクト
会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。
🔗 この記事は Zenn に掲載した記事の再掲です。正規版（canonical）はこちら: https://zenn.dev/chooser/articles/run-ai-subscription-24h