業務をAIに任せて自動化したいと思ったとき、多くの人がまず思い描くのは「これさえ整えば、あとは全部AIがやってくれる」という完成形。私自身も、Claude Codeを使い始めた頃、まさにこの発想でつまずきました。
最初から100点の設計図を描こうとするのではなく、今の自分がどうやって業務の自動化を積み上げてきているかを改めて振り返ってみると、実はかなり地味な積み重ねの連続だったと気づきます。
池田朋弘『Claude 最強のAI自動化術』（芸術新聞社）を参考にして。
全自動化を目指して、立ち止まった話
「これさえあれば」で動けなくなる
Claude Codeを使い始めた頃、私は「業務をまるごと自動化したい」と考えていました。
記帳もチェックも、報告書作成も、請求書発行も、全部つながった一つの仕組みにできたら理想的だろう、と。
ところが、いざ「では何からどうしよう」と考え始めると、途端に手が止まりました。
どこから手をつければ全体が動くのか、途中の工程は何個必要なのか、想像すればするほど途方もなくて見えなくなるのです。
最初の一歩は、驚くほど小さかった
結局、最初にClaude Codeに任せたのは、全体からするとごく小さな作業でした。
証憑（領収書や請求書などの書類）のファイル名を、内容に合わせて整える。手元のデータを、決まったフォーマットのCSVに変換する。
そんな、Claude Codeで最初に紹介されるような、ごく地道な作業からのスタートでした。
ただ、その1つが安定して動くようになると、次に隣の作業を任せたくなります。
そうやって1つずつ小さな仕組みを積み重ねていった結果、組み上げるようにして自動化のペースが見えてきました。
最初から思い描いていた完成形とは、正直かなり違う印象ではあります。
「1〜100」ではなく「1〜10」を積み上げる
重要なことは、自動化の設計は、「最初から全体の最終形を描いて作り始める」のが理想ではあるものの、そこまで全体像を思い描ける人は多くないということ。
だからこそ実務的には、まず1つ目のアウトプットを成立させ、それを土台に2つ目を作り、というふうに「動くチェーンを少しずつ伸ばしていく」やり方のほうが現実的です。
「設計図を完成させてから着手する」のではなく、「動くところから伸ばしていく」。
この順番の発想の逆転が、自動化をうまく進めるためのポイントになります。
最初にできたスキルによる自動化の仕組みを使いながら目視で確認しているうち、次の工程もスキル化し、かつ、それらを繋げたいという欲が出てきて、繋げていく。
さらに別のタイミングで、別スキルによる自動化が別ルートでできあがり、それを本流に合流させる。
そんなふうにして、後から後から必要な部分を継ぎ足していった結果として、いわゆる自動化といわれるほどの仕組みになるということ。
チェーンの伸ばし方には、2つの型がある
書籍では、この「チェーンの伸ばし方」には大きく2つのパターンがあると整理されていました。
1つ目は、前工程のアウトプットが、そのまま次工程のインプットになっていく、「リレー式」の伸ばし方。
2つ目は、1つのアウトプットが、複数の後続処理へと枝分かれしていく「ハブ&スポーク型」の広がり方。
リレー式の実例：請求書業務の積み上げ
自分の業務を振り返ると、これはまさに毎月の請求書発行業務の育ち方そのものでした。
最初に作ったのは、請求書作成だけを行う小さな仕組みでした。
それが安定して動くようになったところで、次に「発行した請求書をPDF保存し、なおかつ、クライアント別フォルダに振り分けて、連絡の準備をする」という工程を後付けしました。
さらにそのあとで、自社経理として、「売掛金や預り金として正しく計上されているか」を確認する工程を継ぎ足しています。
1つひとつは別々のタイミングで作ったスキルなのに、気づけば前工程の出力が次工程の入力になる、1本のリレーとしてつながっていました。
ハブ&スポーク式の実例：複数の顧問先を同時に処理する
一方で、月次の記帳業務には、もう一つの広がり方が現れました。
最初は、顧問先1社ごとに順番に対応するしかありませんでした。
ところが後から、「一度に指示を出せば、担当する顧問先の数だけ処理が枝分かれして、それぞれ独立に進み、最後にまた一つの報告としてまとまって返ってくる」という仕組みを追加しました。
1つの号令（インプット）が複数の処理へと同時に広がり、また一つに集約されて戻ってくる。
これは、ハブ&スポーク型の伸び方に近い形です。
積み上げた先に見えてきた「俯瞰」
こうして個別の仕組みが増えていくと、ある時点で「これとこれをつなげれば、もっと大きな一つの流れにできる」と気づく瞬間がやってくることに気づきました。
事務所の中でも、いくつかの業務では、個別に育ったスキルを後からひとまとめにして呼び出せるようにした、いわば「まとめ役」の仕組みが生まれています。
面白いのは、その「まとめ役」を最初から設計しようとはしていなかった、という点です。
もし最初の段階で「複数の業務を一括で動かす大きな仕組みを作ろう」と意気込んでいたら、おそらく最初の一歩さえ踏み出せなかったように思います。
個々のチェーンがそれぞれ十分に育ってから、後付けで全体を見渡す視点が自然に生まれてくる。
この順番は、実務で自動化を組み上げていくうえでの一番の実感かなとも思います。
冒頭で感じていた「全体を俯瞰できないと動けない」という思い込みは、むしろ逆で、俯瞰は積み上げの結果として後からついてくるものだったのです。
人間が示すのは、入口と出口だけでいい
書籍の中では、この積み上げ型の自動化を続けるうえで、人間が果たすべき役割についても触れられていました。
人間は途中の仕組みをどう組み立てるかまですべてを把握しておく必要はない、という考え方です。
人間がやるべきことは、「どんな状態から始めて、どんな状態に持っていきたいか」という入口と出口を示すこと。
途中の工程をどう設計し、どのツールをどう組み合わせるかは、AIエージェントのほうが自分自身のできることを熟知しています。
これは、私が証憑リネームから始め、請求書業務や月次記帳へと少しずつ広げてきた実感とも重なるものです。
最初から、途中の仕組みまで全部を理解していたわけではなく、「この作業をこういう形にしたい」という入口と出口さえ示し、あとは動かしながら次の一歩が自然と思い浮かんでいきました。
業務の自動化は、完成形を描いてから動き出すというものではなく、動くところから少しずつ育てていくものなのだと改めて感じます。
