Next.js + Cloudflareで「サボる」仕組みを作ったら、抱え込みOSの外し方が見えた
この記事の3行まとめ
- ある開発者が公開した「サボるためのWebツール集 neglegere」の設計思想を、一人社長の言葉に翻訳した記事
- 核になる問いは「この処理、本当にサーバーでやる必要ある？」——これを自分用に言い換えると「それ、本当に社長が抱える必要ある？」
- 抱え込みOSから委ねるOSへ切り替える具体的な手順と、私自身がまだ手放せていない荷物の正直な現在地
目次
「この処理、本当にサーバーでやる必要ある？」で手が止まった
ブックマークを整理していたら、一本の技術記事で手が止まりました。ikuosaito1989さん「Next.js + Cloudflareで『サボる』ためのWebツール集を個人開発した」（Zenn）という記事です。
タイトルに「サボる」と入っている時点で、正直、ちょっと身構えた。手抜きの話かなって。
で、読み進めていくうちに、真逆だと分かった。この人が言う「サボる」は、怠けることじゃない。本当に人間がやるべきことを残すために、渡せるものを全部渡すという話でした。
いちばん刺さったのが、記事の中で何度も出てくるこの問いです。
ikuosaito1989氏（Zenn）「この処理、本当にサーバーでやる必要ある？」
私、エンジニアじゃないんだよね。だから最初は「サーバーで処理するかどうか」なんて、自分には縁のない話に見えてた。
でも一晩置いて、この問いの主語を自分に入れ替えてみたんです。「それ、本当に社長が抱える必要ある？」——そう置き換えた瞬間、これは技術の話じゃなくて、私がずっと悩んできた話そのものだと気づきました。
台所に例えると分かりやすいと思う。皮むきも、洗い物も、盛り付けも、全部シェフがやる必要はない。シェフにしかできないのは「今日、誰に、何を出すか」を決めることだけです。
この記事では、この開発者の設計思想を、一人社長のAI活用にそのまま翻訳していきます。
neglegereというツール集——ラテン語で「無視する」
作られたのはneglegere（ネグレゲレ）というWebツール集です。ラテン語で「無視する・軽視する」を意味する言葉から取られています。
名前の時点で、思想が全部乗っている。無視するものを先に決めてある。
コンセプトは、地味に時間を取られる作業を少しだけ任せて、大事なところに力を残すこと。公開されているのは9つのツールです。
AIボイス／鬼ボイス／背景メーカー／画像変換／音読アシスト／手書き電子サイン／ことばレンズ／騒音チェック／コンディションチェック
並べてみると、どれも「大したことないけど、地味に自分の時間を持っていく作業」ばかりだと分かります。背景を切り抜く。画像のサイズを変える。契約書にサインする。文字を読み上げる。どれも1回3分くらい。
でも、その3分が週に何回あるか。
ここが本質なんですよね。大きな仕事を手放すのは怖いけど、小さい作業は「これくらい自分でやるか」で残り続ける。そして残り続けた小さい作業が、社長の頭のメモリを毎日ちょっとずつ食っていく。
私が以前書いた「AIに任せていい仕事、任せたら意味がない仕事｜800年前の禅僧の答え」という記事でも、同じところに行き着いていました。作務（掃除や炊事）は修行そのものだから手放さない、でも記録や計算は道具に渡していい……という線引きの話です。800年前の禅僧と、2026年のWeb開発者が、同じことを言っている。
面白いですよね。
ブラウザ・Cloudflare・GPU。どこで処理するかを毎回問い直す
技術的な中身にも触れておきます。ここ、経営の話に直結するので飛ばさないで。
neglegereは、処理する場所を3つの層に分けています。
①ブラウザ層＝軽い処理・プライバシー重視（画像変換／背景除去／PDF／OCR／音声加工／騒音解析）
②Cloudflare Workers層＝認証・保存・外部API（Next.js／認証／D1／R2／Durable Objects／定期実行）
③GPU層＝大規模AI（音声合成のQwen3-TTS）
使っている道具立ても書いておきます。フレームワークはNext.js 16、UIはReact 19とTypeScript、CSSはTailwind CSS 4。デプロイ先はOpenNext経由のCloudflare Workersで、データベースはCloudflare D1、ファイル置き場はCloudflare R2。
背景除去はIMG.LY Background Removal、PDFはPDF.jsとpdf-lib、文字認識はTesseract.js、画像変換はjSquash。全部ブラウザの中で動く道具です。
つまり、あなたの写真がどこかのサーバーに送られない。速いし、安いし、漏れない。
元記事には、この設計を一行でまとめた表現があります。
ikuosaito1989氏（Zenn）「BrowserでできることはBrowserへ。人間がやらなくていいことは自動化へ。」
これ、厨房の動線設計とまったく同じ発想だと思いました。冷蔵庫の前でできることは冷蔵庫の前で終わらせる。わざわざ火を使う場所まで運ばない。運ぶ距離が長いほど、時間もコストもリスクも増えていく。
会社に置き換えると、こうなります。手元で終わることを、わざわざ社長のところまで持ってこさせていないか。承認・確認・最終チェックという名前で、全部の判断が一箇所に集まってきていないか。
私自身、ここは何度もやらかしてきました……。
以前「AIに全部やらせる前に、役割を渡そう。Claude Code×Google Cloudに学ぶ『委ねるOS』」という記事で書いたとおり、AIに丸投げしても成果は出ません。渡すのは作業じゃなくて役割。neglegereの3層は、まさにその「役割の置き場所」を決めた設計になっています。
開発体制まで「人は失敗したときだけ見る」に振り切っている
私がいちばん唸ったのは、ツールそのものじゃなくて開発体制のほうでした。
この方は、CodexとClaude Code Proという2つのAIコーディングツールを、git worktree（同じプロジェクトを複数の作業場に分けて並行作業する仕組み）で役割分担させて動かしています。同じ大きなファイルを同時にいじらせない、という運用ルールまで決めている。
テストも自動です。Vitestで部品ごとの検査、Playwrightで画面の通し検査、さらに見た目の差分検査。依存ライブラリの更新はRenovateが自動でマージし、エラー監視はSentry、死活監視はBetter Stack。
そして、こう書かれていました。
ikuosaito1989氏（Zenn）「人が見るのは失敗したときだけです」
ここ、マジで線を引きました。人が見るのは失敗したときだけ。
逆に言えば、成功したときは人が見ない。報告も承認もいらない。うまくいっている仕事の報告を全部読んでいる社長は、成功にコストを払っているということになります。
ただ、全部を機械に渡しているわけでもない。元記事にはこういう一行もありました。
ikuosaito1989氏（Zenn）「数値は出せる ≠ 表示してよい」
コンディションチェックのような健康系の機能では、技術的に数値を出せることと、その数値をユーザーに見せていいことは別だ、という線引きです。
これは完全に人間の判断領域。できることと、やっていいことを分ける。自動化を進めれば進めるほど、この線引きだけは誰かが引かなきゃいけない。
私も似た結論に辿り着いていて、失敗から学んだAI指示設計の三原則としてまとめてあります。
田中啓之（AI指示設計の三原則）第一原則：AIに判断させない。判断は人間の仕事。
第二原則：1タスク1エージェント。作るAIとチェックするAIは必ず分ける。
第三原則：外部AIでクロスチェック。別ツール・別モデルで二重三重に検証する。
作る人と検品する人を分ける。飲食店なら当たり前の話ですよね。自分で作った料理を自分だけで味見して合格にしたら、店の味はいつか崩れます。
比較表：3層アーキテクチャと、私の委ねるOS
ここまでの技術用語を、経営の言葉に翻訳しておきます。
そしてもう1枚。元記事の実践と、私が実際にやっていることを並べた表です。
並べてみると、職種が全然違うのに、構造が同じでびっくりしました。
正直な現在地——私が呪縛を手放せたきっかけは、病気でした
ここは正直に書きます。私は自分の意思で「やった方が早い」を手放したわけじゃない。
田中啓之（委ねるOSの転換点）がん発覚を機に「死」を意識し、OSを強制置換した。きっかけは病気であり、「やった方が早い」という呪縛を壊すには、それくらいの衝撃が必要だった。
参考: 20_ナレッジ／委ねるOSフレームワーク（2026年2月11日・自社ナレッジ記録）
闘病中、物理的に手が動かない期間がありました。そこで初めて、抱えていた仕事を人とAIに渡した。渡してみたら、回ったんです。私がいなくても。
ぶっちゃけ、最初はちょっと寂しかった。
でも、そこで分かったことがあります。抱え込みはエゴで、委ねるは信頼だということ。効率化の話じゃなくて、命の時間をどこに投下するかという話だったんだ、と。
最初の委譲は失敗の連続でした。指示が抽象的すぎて、意図しない成果物が返ってくる。そう、丸投げしすぎ問題。今は分身AI（私の思考のクセを学習させたAI）を経由して指示を出すことで、渡す前に意図を揃える形に落ち着いています。
ちなみに私のClaude Code環境には、いま224個のスキル（AIに渡した手順書）が入っています。作業ディレクトリを数えただけの数字ですが……多い。これ全部、最初は私の頭の中にあった手順です。
実際に自分のAI運用を計測した話は、「cclensで自分のClaude Codeを計測したら、9,097トークンの無駄が見えた」という記事にまとめてあります。渡した量が増えると、今度は渡し方の無駄が見えてくる。手放しは1回で終わりません。
エンジニアじゃなくても関係がある理由
「Next.jsとかCloudflareとか言われても、うちには関係ない」と思った方へ。ここが本題です。
今日（2026年8月13日）、私はハーネス設計について研究している軸丸翔さんと対談しました。ハーネスというのは、AIに記憶や人格や手順を持たせる「外側の仕組み」のこと。
そこで私が話したのは、こういうことでした。
田中啓之（2026年8月13日・軸丸翔さんとの対談）LMはいずれ枯れた技術となり、残るのはハーネスのみ。AIはおまけ、本質はデータ（元データが命）。
参考: Google Meet（軸丸翔×田中啓之×タカダヨウヘイ）2026年8月13日・自社ミーティング記録
言い方を変えます。AIモデルそのものは、いずれ電気や水道みたいな「当たり前のインフラ」になる。差がつくのは、その周りに自分が何を組んだか。持っているデータと、渡し方の設計だけが残ります。
軸丸さんの側の話も面白かった。
軸丸翔さん（2026年8月13日・対談より）設計思想は「20年間壊れない」ことを最優先に、テキスト・マークダウン等の枯れた技術のみを採用している。
参考: Google Meet（軸丸翔×田中啓之×タカダヨウヘイ）2026年8月13日・自社ミーティング記録
最新で最速のものを追いかけるんじゃなく、20年壊れないものを選ぶ。この感覚、「もし横井軍平さんがAIビジネスを始めたら？｜『枯れた技術』で作る4つの小さな商売」で書いた枯れた技術の水平思考と、完全に地続きでした。
で、neglegereの話に戻ります。あの人がやっているのも同じ構造なんだよね。Next.js 16やCloudflareという道具の名前は、5年後には別のものに変わっているはず。でも「この処理、本当にサーバーでやる必要ある？」という問いは、5年後も使える。
もう1つ、忘れられない話があります。
AI氣道「自動化は解放の手段」より高崎さんが「インスタを完全自動化した結果、インスタを開きすらしなくなった」と笑っていた。私は最初ちょっと笑ったけど、すぐ気づいた。
笑い話に聞こえるけど、これ、めちゃくちゃ深い。自動化した結果、そのアプリを開かなくなった。つまり、自分にとってそれは「本当は持ち続けたいものではなかった」と分かったということです。
逆もある。手放そうとして、手放せなかったもの。私にとっては毎朝のLIVEでした。何度も自動化を検討したけど、あそこだけは自分の声で話したい。
自動化は、持ち続けたいものを見つけるための道具でもある。渡してみて初めて、自分の輪郭が見えてきます。
今日から試せる、3つの問い直し
専用ツールも予算もいりません。今日、机の上でできることを3つ書いておきます。
- 「それ、本当に社長が抱える必要ある？」を1日3回つぶやく：メール返信、請求書チェック、SNSの投稿……手を動かす直前に一度だけ問う。答えがノーだったものをメモしておく
- 報告を「失敗したときだけ」に絞る：うまくいった報告を毎回読んでいるなら、そこは自動化の余地あり。人が見るのは失敗したときだけ、というラインを一度試してみる
- 1つだけ、小さく渡してみる：いきなり大きな仕事を渡さない。3分で終わる作業を1つ選んで、AIか人に渡す。渡したあと、自分が寂しくなるかどうかを観察する
3つ目が地味に大事です。渡して寂しくなったものは、あなたが本当に持ち続けたいもの。渡してスッキリしたものは、最初から荷物だっただけ。
味見と同じですね。全部の鍋の味を見る必要はない。塩を入れるかどうかを決める瞬間だけ、シェフが立っていればいい。
もっと大きな設計から考えたい方は、「2.3万人の会社の代表から、たった1人へ。川邊健太郎さんに聞く『AI駆動型企業』という経営スタイル」もあわせてどうぞ。規模が違っても、抱えるものを減らしていく方向は同じでした。
ひろくんのコラム——「サボる」という言葉に救われた話
私は長いこと、手放すことに罪悪感がありました。自分が抜けたら失礼なんじゃないか、逃げてるんじゃないかって。
だから「委ねる」という言葉を使ってきました。委ねるなら、信頼の話にできる。前向きに聞こえるから。
でも今回、あえて「サボる」と書いている人を見て、なんだか肩の力が抜けたんです。サボるでいいじゃん、と。
言葉を上品にしすぎると、行動が重くなる。「委ねるOSに移行する」だと決意表明が必要だけど、「これサボろ」なら今日できます。
もちろん、中身は同じです。渡せるものを渡して、自分にしかできないものを残す。ただ、入口の言葉が軽いほうが、人は最初の一歩を踏み出せるんだと思う。
だから今日は、あえてこう言います。もっとサボりましょう。そのぶん、あなたにしか作れない料理を出すために。
よくある質問
- Q1. neglegereは自分で使う必要がありますか？
- いいえ、使わなくても大丈夫です。この記事で紹介したかったのは、ツールそのものより「その処理をどこでやるかを毎回問い直す」という設計の姿勢です。もちろん背景除去や画像変換など、そのまま業務で使える機能もあるので、気になったら触ってみてください。
- Q2. エンジニアがいない会社でも、この考え方は使えますか？
- 使えます。技術用語を全部外すと「手元で終わることを、わざわざ社長まで運んでいないか」という一点に集約されます。これは業種も規模も関係ありません。まず自分の1日の作業を書き出して、社長でなくてもできるものに印をつけるところから始めてください。
- Q3. AIに任せたら品質が落ちませんか？
- 任せ方によります。作る人とチェックする人を分けていない場合は、品質が落ちやすいです。記事を書くAIと、その記事を検品するAIを別にする。可能なら別のAIサービスでもう一度見る。この二段構えを入れるだけで、事故はかなり減ります。
- Q4. 何から自動化すればいいか分かりません。
- 大きい仕事ではなく、1回3分で終わる小さい作業から選んでください。画像のサイズ変更、定型メールの下書き、議事録の整形あたりが入口としておすすめです。小さいので失敗しても被害がなく、渡す感覚をつかむ練習になります。
- Q5. AIのモデルがどんどん新しくなるので、今学んでも無駄になりませんか？
- モデルの操作方法を覚えるだけなら、たしかに古くなります。ただし「何を渡して、何を残すか」という設計と、自社に溜めたデータは残ります。道具が変わっても引き継げるのはこの2つなので、そちらに時間を使うほうが長持ちします。
まとめ：サボるとは、残すものを決めること
ある開発者が、ブラウザで完結するツール集を作った。処理をブラウザ・Cloudflare・GPUの3層に分け、開発も監視も自動化して、人が出るのは失敗したときだけにした。
技術記事として読めば、Next.jsとCloudflare Workersの話です。でも、私にはこう聞こえました。「持たなくていい荷物を、先に決めておけ」と。
AI導入で悩んでいる一人社長に本当に必要なのは、最新モデルの名前じゃない。自分が抱えなくていいものの見極めだと思っています。
そして、その見極めは机の上では終わりません。実際に渡してみて、寂しくなるかスッキリするかで初めて分かる。私の場合、闘病がその強制スイッチでした。できれば皆さんは、もっと軽いきっかけで始めてほしい。
今日、1つだけサボってみてください。それが、あなたにしかできない仕事を見つける最初の一歩になります。
今回の元ネタ。3層アーキテクチャと開発自動化の全体像
実際に公開されているWebツール集。全9種、ブラウザで完結
丸投げではなく役割を渡すという考え方の基本編
渡したあとに出てくる「渡し方の無駄」を実測した記録
手放していいものと、手放してはいけないものの線引き
