月間150億トークンを使う私が、自分では“やらないこと”

広木大地（@hiroki_daichi）と申します。株式会社レクター代表取締役として、複数企業の技術経営をサポートしています。今回の寄稿で、やらなくなったこと／やめたことを教えてください、と言われて少し困りました。多すぎて思い出せないからです。

メールを自分で読むのをやめました。ツイートを自分で書くのをやめました。コードを自分で書くのをやめました。文章を自分で書くのをやめました。既製のソフトウェアを使うのもほとんどやめました。AIに直接指示を出すことすら、だいぶ減りました。

こう並べると極端に聞こえるかもしれませんが、別にサボっているわけではありません。仕事全体をAIエージェント前提で組み直した結果、「自分の手で触る作業」のほうが例外になっただけです。

具体的には何をやめたのか

少し詳しく説明します。

メールを読むこと。受信トレイは毎時AIが巡回し、要対応のものだけがSlackに通知されます。「誰から」「何の件で」「返信が必要か」まで分類済みで届くので、私が受信トレイを開く場面はほぼありません。契約関連のメールが来たら自動でTODOに登録されますし、会議後のフォローアップもAIが議事録から抽出して起票してくれます。メールを開いて「これは対応が要るな」と判断する工程そのものが消えました。

ツイートすること。クライアントとの打ち合わせの発言録から、AIが知見（インサイト）を自動抽出し、そこからツイート案を生成してくれます。生成されたものは別のプロセスのブランディング担当エージェントによるモデレーション（品質判定）を経て、投稿可能な状態になります。私がやるのは、最終的に「これは出していい」と確認するだけです。ちなみにこの記事の打ち合わせ中の私の発言からも、すでにインサイトが2件抽出されています。打ち合わせをすること自体がコンテンツの原材料になっています。

コードを書くこと。業務で使うソフトウェアはほぼ自作していますが、コーディング自体はAIエージェントがやります。名刺管理、自分のためだけの編集部がいるニュースアプリ、僕のインサイトを抽出してくれる議事録管理、ブログCMS、タスク管理、SNS予約投稿、プレゼン編集。10個近いWebアプリが自分のために動いています。「自分でつくっているのにコードは書かない」というのは矛盾に聞こえるかもしれませんが、判断は自分で、実装はAIで、という分業がすでに成立しています。

それだけではありません。これらのアプリを操作するためのCLIツールも10個ほど自作しました。Slack操作、X（Twitter）投稿、YouTube文字起こし、スマートホーム制御。AIエージェントがコマンドとして呼び出せるようにしてあります。人間がGUIを操作するのではなく、AIがCLIで操作します。このインターフェースの転換が、自動化の幅を一気に広げました。

自分のスマホトップは自作アプリで埋まってしまった

SaaSを使うこと。全部が全部ではないのですが、ほとんどの業務ツールは自作で回しています。ありもののSaaSで「だいたい合ってるけど微妙に違う」を我慢するより、完全に自分の業務に合ったものを持つ方が、結果的にストレスが少ないです。しかもAIがコードを書く時代には、自作のコストが劇的に下がっています。以前なら一つのアプリをつくるのに数週間かかっていたものが、今は数時間で動くものができます。「既製品を買う」より「自分用につくる」方が速い場面が増えてきました。

自作アプリはすべてAPI Firstで設計しています。各アプリは GET /api/openapi.json でOpenAPI仕様を返すようにしてあるので、AIエージェントはこの仕様を読むだけで、そのアプリの全機能を自律的に操作できるようになります。人間がドキュメントを読んでAPIを叩くのではなく、AIがOpenAPIスキーマを解釈して自分で判断してリクエストを組み立てます。直接使うのは私じゃなくて、AIエージェントだということを徹底しています。

同じ発想でCLIツールもCLI Firstで設計しています。--help を叩けばAIが使い方を理解できるように、サブコマンドとオプションを整理してあります。GUIは人間には便利だが、AIにとってはCLIのほうがはるかに操作しやすいです。API FirstとCLI Firstの2層を用意しておくことで、定期実行のワークフロー（API経由）にもリアルタイムの対話操作（CLI経由）にも対応できます。

文章を書くこと。NewsPicks連載の記事は、会議での私の発言からインサイトが抽出され、ニュース記事のスクラップと組み合わせてテーマが提案され、承認するとドラフトが生成されます。以前は年に1、2本がやっとだった記事執筆が、今は月に10本以上のペースで出せています。数十年前に多くの人が手書きで文章を書くのをやめたようにごく自然な成り行きとしてAIによって拡張されて記事を書いていくことは当たり前になります。契約書の雛形の修正やチェックすら、直接は行いません。

AIに直接指示すること。これが一番意外かもしれません。私はAIに「これやって」と頼む頻度がかなり少ないです。代わりに何をしているかというと、判断の方針を議論して保存しています。「おはようと言われたらメールとカレンダーとTODOを横断で確認しろ」「Slack投稿の前に内容を提示して確認を取れ」「10件以上の連続操作は途中で報告しろ」。AIはこのファイルを読んで、自分で判断して動きます。私が指示を出すのは、新しい方針を定義するときだけです。

「やめる」の本質はポリシーの設計

ここまで具体的にやめたことを並べてきましたが、個別の仕組みより大事なのは、これらに共通する考え方のほうです。

私は「やらないこと」を一つずつリストにして管理しているわけではありません。意思決定そのものをポリシー（方針・原則）として定義し、AIがそのポリシーに従って動ける状態をつくっています。個々の自動化は、すべてこのポリシー設計の結果として生まれたものです。

たとえば、「この発言パターンにはこのツールを使え」「副作用のある操作は事前に内容を提示してから実行せよ」「メール確認はデフォルトでINBOXの未読のみ」といったルールが、22パターンの判断ルーティング表として定義されています。

これは何をやっているかというと、都度の意思決定を一つ一つポリシーに昇華させているのです。

一度「メールはこう処理する」と決めれば、その判断は以後何百回でも自動で再現されます。一度「ツイートのモデレーション基準はこう」と決めれば、毎回「これ出していいかな」と悩む必要がなくなります。私はこれを「意思決定の射程を広くする」と表現しています。一回の判断が、できるだけ長く、繰り返し効くようにします。

逆に言えば、毎回AIに「これやって」「あれやって」と個別に指示しているうちは、判断のコストは人間側に残ったままです。AIを便利な道具として使っているだけで、仕事の構造は変わっていません。

面白いのは、このポリシーは人間に対しても同じように機能することです。私のAIエージェントは、Slackでアシスタントからのメッセージにも応答します。ただし権限が違います。私には全操作を許可し、アシスタントには検索と確認だけを許可している。「誰に」「何を」「どこまで」任せるかをポリシーとして定義しておけば、人間もAIも同じ仕組みの中で動ける。

たとえば会議中に「この件、アシスタントに予定調整をお願いしておいて」と言えば、AIが議事録からその文脈を拾い、アシスタントのSlackに必要な情報を添えて連絡する。私が会議後にわざわざメッセージを書く必要はありません。会議中の発言がそのままアクションになります。これもポリシーが動線を定義しているから可能になっています。

生成と評価を分離する

もう一つ、仕組みの設計で意識していることがあります。「つくる工程」と「評価する工程」を明確に分けることです。

ツイート生成を例にすると、朝6時にAIが会議のインサイトからツイート案を作ります。その6時間後、別のAIプロセスが「独立したモデレーター」として品質を判定します。生成側は「とにかく候補を出す」に集中し、判定側は「出していいか」だけを見ます。

なぜ分けるかというと、自分でつくったものを自分で評価すると甘くなるからです。これは人間でもAIでも同じで、生成バイアスを構造的に排除するためにプロセスを分離しています。

こういう「工程の設計」ができるのは、既製品ではなく自分でシステムを持っているからです。SaaSの機能に合わせて業務を変えるのではなく、自分の判断基準に合わせてシステムをつくります。この順序が逆転しないことが大事だと思っています。

同じ発想は他にもあります。議事録から翌朝にTODOが自動起票されるが、その際に「同じ会議IDのTODOがすでに存在しないか」を毎回確認します。一度実行しても二度実行しても結果が変わらない設計（冪等性と呼びます）を組み込んでおくことで、「動かしっぱなしで壊れない」状態をつくっています。自動化はつくって終わりではなく、放っておいても安全に回り続けることが本当のゴールだ。

裏側で何が動いているか

具体的にどれだけの自動化が動いているか、ある1日のタイムラインで見てみましょう。

私の環境では、GitHub Actionsで22本、n8nで28本、合計50本のワークフローが稼働しています。それぞれが決まった時刻やイベントをトリガーに、勝手に動いています。n8nはすべて設定ファイルがソースコードとして管理され、GUIでの修正はもうやめています。

ポイントは、これらのほとんどが「Claude Codeをcronで起動する」という同じパターンで動いていることです。GitHub Actionsのスケジュールトリガーでリポジトリをチェックアウトし、CLIツールとAPIを使って情報を集め、AIが判断して結果を書き込みます。n8nのほうは主にGmailやGoogleカレンダーとの連携など、Webhookやポーリングが必要な処理を担当しています。

一つ一つは単純な処理ですが、50本が毎日並行して動くことで、私が朝起きた時点ですでに「昨日の会議のTODOが起票済み」「契約メールの確認依頼がTODOに入っている」「ツイート案が3件レビュー待ち」「調査レポートが1本上がっている」という状態になっています。

変わったこと、変わらなかったこと

仕事の構造を変えた結果、生活はかなり変わりました。家族と過ごす時間が増えました。平日でも凝った料理をつくる余裕があります。先日はクエ鍋をつくりました。あくせく働いて夜遅くまでパソコンに向かう、という働き方からはだいぶ遠くなりました。

仕事だけではありません。妻との買い物リストを共有するアプリや、レシピを提案してくれる仕組みも自作しました。「電気つけて」とAIに言えば自宅の照明がつきますし、「エアコン消して」と言えば消えます。業務と生活の境界なく、自分の判断をシステムに預ける範囲が広がっています。

一方で、変わらないこともあります。考えることの総量はむしろ増えています。「何をAIに委ねるか」「どんなポリシーを定義すべきか」「この判断は本当に自動化していいのか」。設計者としての思考は、以前よりも密度が上がりました。

ちなみに、私個人で月間150億トークンほどのAI処理を走らせています。ただ、量が多いこと自体には意味がありません。大事なのは、その処理が「都度の指示」ではなく「ポリシーからの導出」で動いていることです。寝ている間も、会議をしている間も、システムは判断し続けています。

アウトプットの構造も変わる

この仕組みが回り始めると、アウトプットの出し方も変わります。

NewsPicks連載では、私が書いた記事をCMSに保存すると、自動でNewsPicksのトピックスに投稿されます。コメントが付けば、その内容もAIが分析してフィードバックループに組み込まれます。「書く→出す→反応を見る」のサイクルが、人手を介さずに回っています。

昨年出版した書籍『AIエージェント 人類と協働する機械』（リックテレコム）も、この仕組みのような方法で書きました。書籍執筆用のアプリを自作し、会議での議論やインサイトを原材料にしながら、AIと協働して16章・約35万字の本を完成させました。本の中で紹介している「しらせ君」というAIアシスタントは、まさにこの記事で述べている仕組みそのものです。意思決定をポリシー化し、知識創造のプロセスを自動化します。本ではこれを「SoK（System of Knowledge Generation）」と呼んでいます。

やらないことの先にあるもの

「やらないことリスト」をつくろうとすると、つい「何を削るか」という引き算の発想になります。しかし私がやっていることは引き算ではありません。仕事全体の構造を見直して、「人間がやるべきこと（本質的な課題解決）」と「システムに委ねること（付随的な課題解決）」の境界線を引き直す作業です。

その境界線を引くための道具がポリシーであり、ポリシーを実行するための基盤が自作のソフトウェア群であり、定期的に回すための仕掛けがワークフロー自動化です。

結局のところ、「やらないこと」を決めるとは、自分が何の設計者でありたいかを決めることに等しいです。作業を手放すのは簡単だが、判断の構造を設計するのは簡単ではありません。それでも、一度つくった構造は長く機能し続けます。

あなたが今日やった仕事の中で、明日もう一度同じ判断をするものはいくつあるでしょうか。その判断を一度だけ行い、以後はシステムに任せられるとしたら、あなたの時間には何が残るでしょうか。

ちなみにだが、もちろんこの記事も、打ち合わせの議事録をAIが読み取り、リポジトリの中にある実装の工夫を調べ上げ、下書きを生成したものをベースにしています。記事を自分で書くことも、やめたことの一つです。

※「150億トークン」はClaude Code(API / サブスク合計)、OpenAI API（Codex）、Grok、Gemini APIおよび CLIの月間利用量を合算した値で、プロンプトキャッシュの読み込み分を含む実効処理量の総量です。同じシステムプロンプトやファイル内容を繰り返し参照する処理が大半を占めるため、新規に処理されるトークン（input / output / cache creation）はこの総量の数%程度にとどまります。それでも、システム全体としてどれだけの情報処理を回しているかの目安として、この数値を採用しています。