AIで自分の作業を効率化するのをやめました──「AIが働けるように人が支える」に切り替えた1日の記録

今日から、AIの使い方の考え方を変えることにしました。
人が自分の作業を効率化するためにAIを使うのではなく、AIが仕事をできるように人がサポートする
言葉にすると小さな違いですが、実際にやることが変わります。この記事では、なぜ切り替えたのかと、実際に今日1日の仕事がどう変わったかを、10プロジェクト・30セッション分の作業記録から書き出してみます。
「自分を効率化する」には天井がある
これまでのAI活用は、「自分の作業を速くする」という発想でした。調べものをAIに投げる、コードのたたき台を書いてもらう、メールの下書きを作ってもらう。たしかに速くなります。
ただ、この形には2つの限界があります。
1つ目は、自分が起点であること。 自分が「これをAIに投げよう」と思いつき、Claude Codeを起動して、依頼内容を書く。この最初の一歩が毎回必要なので、仕事の量は結局「自分が思いつける量」「自分が指示を書ける量」に縛られます。1日に4画面も並行して動かすと、もう自分の処理能力のほうが先に頭打ちになります。
2つ目は、自分でもできてしまうこと。 自分でやれる作業だから、忙しいときほど「説明するより自分でやったほうが早い」となる。そうして手を動かすほど、AI側に仕組みが残らず、翌週も同じ手作業をしています。
主語が「自分」である限り、この2つからは抜けられません。
主語を「AI」に置き換えると、やることが変わる
そこで主語を入れ替えます。AIが仕事の実行主体で、人はAIが詰まらないように環境を整える側。
これは、人に仕事をお願いするときと同じ考え方です。新しく入った人に仕事を任せるとき、私たちは無意識にこうしています。
- 必要なシステムのアカウントを発行する(鍵)
- その人が使える環境・ツールを用意する(道具)
- 前提や過去の経緯を共有する(文脈)
- 失敗しても戻せる状態にしておく(安全網)
AIに対しても、やることは変わりません。そして面白いのは、この4つを人が先に用意すると、「頼めること」が急に増えるという点です。
以下、今日1日で実際にあったことを、この4つに沿って並べてみます(お客さま名は伏せています)。
1. 鍵を渡す──認証情報を先に用意しておく
クラウドAI基盤のアクセスキーを渡した例。 ある案件で、AIチャットボットの動作環境を別のクラウドアカウントに移す作業がありました。私がやったのは、発行したアクセスキーとシークレットキーを .env に貼って「貼り付けました」と伝えただけです。そこから先は、リージョンの変更、使用モデルの切り替え、.env.sample の更新、プルリクエスト2本の作成まで、AI側で完了しました。私が最後にやったのは、PRを開いて中身を見てマージすることだけです。
顧客リポジトリのアクセストークンを渡した例。 お客さまのGitHubに出したプルリクエストへの指摘に気づくのが遅れる、という課題がありました。~/.bashrc にトークンを1行足して「読み込んで試してみて」と伝えたところ、指摘を検知して通知する機能がブランチ作成からPRまで出来上がりました。
最初の認証だけ人がやった例。 月末が近いので、ある案件の原価(クラウド利用料)と売上(請求書)を突き合わせて、利益が出ているか知りたい。ここで人がやったのは、請求管理サービスへのログインと、クラウドのSSOでのサインイン。この2つだけです。実際の集計と黒字/赤字の判定はAI側で完結しました。しかも同じ調査は毎月必要なので、そのままスキルとして手順を固定してもらいました。次の月も、人がやるのは最初の認証だけです。
鍵を渡す前は「見積もりを取るのも一苦労」だったものが、鍵を渡した瞬間に「頼めば終わる仕事」に変わります。渡せていない鍵は、そのままAIに頼めない仕事のリストになっている、という見方ができます。
2. 道具を替える──AIが動ける構成にする
VPNを乗り換えた例。 業務用のVPNにつなぐと、AIのAPIへの接続が失敗して作業が止まる、という問題が続いていました。原因は、VPNクライアントが全通信とDNSを社内側へ持っていってしまうこと。そこで、必要な社内セグメントだけをVPN経由にできる別のクライアントに乗り換えました。
これは「人の作業を速くする」改善ではありません。人が使う道具を、AIが同時に働ける道具に替えたという改善です。この視点がないと、「VPNをつないでいる間はAIが使えないもの」として、そのまま我慢し続けることになります。
権限を先に渡した例。 今日1日で、3つの別々のセッションで「オートモードを解除したので、もう一回やってみてください」というやり取りがありました。AIが止まっていた理由は能力ではなく、権限設定が実行をブロックしていただけです。AIが詰まったとき、まず能力を疑いがちですが、実際には人が渡し忘れている権限であることがかなり多いです。
並行して働ける置き方にした例。 複数の修正を同時に進める案件では、作業をgit worktreeで分けています。人ひとりが順番に作業する前提なら不要ですが、AIが並行で走る前提だと、作業場所が衝突しない置き方そのものが必要な準備になります。
3. 文脈を置く──覚えておいてほしいことを常設する
今日、save-learnings(そのセッションで得た知見をメモリやスキルに書き戻す作業)を14回実行しました。ほぼすべてのセッションの終わりに1回、という頻度です。
これは自分のためのメモではありません。次に立ち上がるAIが、同じことを聞かずに済むようにするための引き継ぎです。人の新人教育でいえば、口頭で教えた内容をマニュアルに落としておくのに近い作業になります。
文脈の整備は、うまくいかなかったときにも発生します。今日は、あるレガシーシステムの仕様書を自動生成する仕組みで、実装にはあるのに仕様書に載っていない挙動が見つかりました。ここで直すべきは、出来上がった仕様書だけではありません。「次も同じ漏れ方をする」ので、生成の手順そのものを直す必要があります。修正プランを先に出してもらってから、手順側を改善しました。
同じ日に、月次の原価調査もスキルとして固定しました。1回きりの作業として消費するか、次から呼び出せる形にして残すか。後者を選ぶだけで、来月の自分は同じ説明をしなくて済みます。
4. 安全網を張る──任せる前に、戻せるようにしておく
今日いちばん「これが本質かもしれない」と思ったのが、この4つ目でした。
ある案件で、お客さまが起票した課題を管理表に書き込んでいく作業をAIに任せたい、という話になりました。読み取りはすでに任せています。ただ、書き込みは話が別です。間違って上書きしたら、元に戻せません。
そこで、書き込みを任せる前に、その管理表の日次バックアップを先に用意しました。VPS上のcronで毎日取得する形にして、スキルとしても固定。バックアップが動き出してから、書き込みの相談に進んでいます。
同じ日に、Mac標準のメモアプリに書き溜めているタスクメモについても、「データが消えたら終わりなので怖い」という理由で日次バックアップを組みました。
AIに任せられる範囲は、能力ではなく「戻せるかどうか」で決まっている場面がかなりあります。逆に言えば、復旧手段を1つ用意するだけで、任せられる仕事が一段増えます。安全網は、AIを縛るためではなく、任せる範囲を広げるために張るものです。
人に残るのは、判断と承認と責任
ここまで書くと「全部AIに投げるのか」と見えるかもしれませんが、そうではありません。今日の記録を見返すと、人がやったことははっきりしています。
- プルリクエストの中身を見てマージする
- 記事や修正を公開する
- お客さまや協力会社の方に連絡する
- どちらの仕様が正しいかを決める
そして今日、私からAIに強めに伝えたことが1つあります。バックアップの設計を相談していたとき、AIが「必要だと思うので、こちらの構成も足しておきます」と勝手に範囲を広げようとしたので、こう返しました。
必要かなと思って勝手に追加しないでください。必ず確認をします。
サポートするというのは、丸投げすることではありません。環境は人が広げる、範囲は人が決める。この線引きがないと、支えているつもりが制御を手放しているだけになります。
1日の数字
今日1日の作業記録を数えてみました。
- 動いたプロジェクト: 10
- セッション数: 30
- 私が入力した回数: 282回
- AIが実行したツール操作: 約2,300回
自分が282回話しかけたのに対して、実際の操作は約2,300回。8倍です。この差が、そのまま「人が起点でなくなった分」だと考えています。
もし「自分の作業を効率化する」という発想のままだったら、この2,300回のうち大半は自分の手で打っていたはずで、そもそも10プロジェクトを同じ日に動かすことはできませんでした。
これから
近いうちに自宅のマシンを1台、常時稼働の作業用マシンとして立ち上げる予定です。目的は、こちらがノートPCを閉じていても、移動中であっても、AI側の仕事が止まらない状態を作ることです。今は自分のノートPCの上でAIが動いているので、蓋を閉じた時点で全部止まります。
そのときに必要になるのは、結局この記事の4つと同じでした。鍵(認証情報が揃っているか)、道具(そのマシンで動く構成か)、文脈(過去の経緯を引き継げるか)、安全網(失敗しても戻せるか)。
「自分の作業をどう速くするか」ではなく、「AIが最後まで走りきれない理由は何か」を探す。 今日1日やってみて、この問いのほうが具体的な打ち手が出てくる、というのが実感でした。手が空くのを待つより、詰まりを1つ外すほうが効きます。
AIの活用がどのレベルにあるかを整理したAI活用には「4つのレベル」があるという記事も書いています。今回の話は、その最上段である「束ねる」を、日々の判断基準まで下ろしたものです。あわせて、管理画面の手作業はAIに渡せないという理由でドメイン管理を乗り換えた話も、「道具を替える」の実例になっています。
